Re: [Tinycc-devel] github

[Giovanni Mascellani]

Hi,

Il 18/04/20 21:05, Robert Hölzl ha scritto:
> hey guys,
> 
> 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.

The thing is currently set up with an automatic script on a server of
mine that periodically checks for new commits and sends them to the
repository on GitLab (branch "test"). Those scripts automatically
compile and run tcc's tests in the native GitLab CI environment and on
five different Debian systems of different architectures by mean of QEMU
whole system emulation (i386, amd64, armhf, arm64 and riscv64).

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. 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].

 [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.

HTH, Giovanni.
-- 
Giovanni Mascellani <address@hidden>
Postdoc researcher - Université Libre de Bruxelles

signature.asc
Description: OpenPGP digital signature