Re: [Tinycc-devel] github

[Michael Matz]

Hello,

On Sun, 19 Apr 2020, Giovanni Mascellani wrote:

> > TinyCC is great because it supports so much configurations (3 OSes, even
> > more CPU archs).
> >
> > But the downside is, that nobody can ensure that his change wont break
> > any of these configurations.
> > (Probably most of us are testing only on their own PC, which is one OS
> > with probably x86-64).
> >
> > How about a CI?
>
> I am not a core dev, but I set up a CI for tcc:
>
>  https://gitlab.com/giomasce/tinycc/pipelines
>
> Unfortunately it is currently broken. I believe the CI is broken, not
> tcc, because it wasn't broken before my last round of CI script
> maintenance. I'll try to fix them as soon as I have some time, but if
> someone wants to check them out in the meantime I won't complain.

Yeah, I've seen the breakages, but had no bright idea, see below.

> Currently armhf fails with "Illegal instruction", and I don't know if
> the problem is QEMU emulation or tcc itself, because the same commit did
> work before I did my last round of changes.

Yeah, I figured something must be up with the emulator.  No way TCC is 
generating genuinely illegal instructions :)  It would be helpful if the 
emulator would give some hint of the instruction bytes it thinks are 
illegal :)  (One guess of mine was that the emulator is run in a mode 
where e.g. Neon instructions are invalid?)

> riscv64 has a failing test, and that could be a genuine tcc bug. If so, 
> it is probably introduced by recent "win32: long double as distinct 
> C-type" commit. Broken test is "70_floating_point_literals", see the 
> log[1].

Yeah, but I don't think there's a TCC problem.  The failure in riscv64 is 
random (i.e. changes place from test to test, when the pipelines are 
re-triggered by unrelated changes, just browse the different fails).  I've 
looked at one of the testcases claimed to be failing and it's definitely 
correct code.

> [1] https://gitlab.com/giomasce/tinycc/-/jobs/507946108
>
> As soon as I have some time, I'd like to fix these problems and 
> eventually support Windows and macOS too. I believe this architecture 
> with QEMU running in GitLab CI can work, but suitable Windows and macOS 
> images have to be prepared and compilation scripts adapted. QEMU TCG 
> emulation is slowish, but if we prepare images with a snapshot so that 
> the VM doesn't have to go through the whole boot sequence it might be 
> reasonable.

Are there macOS images?  Because if so, I could probably look at adding 
Mach-O support on a rainy day.  Without access to MacOS that's going to be 
difficult :)


Ciao,
Michael.