github

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

github

Robert Hölzl
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 would be happy to add the corresponding scripts, so that at least
windows (x86 and x64), linux (x64) and macos (x64) are tested.
I did not investigate yet, but it could be even possible to utlitze qemu
to test all cpu archs (not only x86, x64).

But to make this work I need the repo to be homed at github or gitlab.
It seems that on github there is already an organization "TinyCC".
Bit it seems not to be supported by the core devs.
In fact the guy which created this repo even started some CI scripts.

@the core devs: Please point our your thoughts.
Are you interested in a CI (even it might need a switch to
GitHub/GitLab/...)

greets,
Robert


_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Reply | Threaded
Open this post in threaded view
|

Re: github

Christian Jullien-3
Hi,
For sure I would like to have a CI.
I personally test about every commit on Windows x86/x64, Linux arm32/arm64 and a little bit less often on Linux x64/Alpine x64.
I definitively would like to test Linux/rsicv64 too but I lack access to a machine having this cpu.

GitHub has another advantage, it perhaps more stable than current repository.

Why don't you setup a pure mirror on GitHub just for CI and without the possibility to commit on it? This mirror will synchronize, say, every 4 hours and launch non-regression tests for all supported os/system.

C.

-----Original Message-----
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=[hidden email]] On Behalf Of Robert Hölzl
Sent: Saturday, April 18, 2020 21:05
To: [hidden email]
Subject: [Tinycc-devel] github

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 would be happy to add the corresponding scripts, so that at least
windows (x86 and x64), linux (x64) and macos (x64) are tested.
I did not investigate yet, but it could be even possible to utlitze qemu
to test all cpu archs (not only x86, x64).

But to make this work I need the repo to be homed at github or gitlab.
It seems that on github there is already an organization "TinyCC".
Bit it seems not to be supported by the core devs.
In fact the guy which created this repo even started some CI scripts.

@the core devs: Please point our your thoughts.
Are you interested in a CI (even it might need a switch to
GitHub/GitLab/...)

greets,
Robert


_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel


_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Reply | Threaded
Open this post in threaded view
|

Re: github

Giovanni Mascellani
In reply to this post by Robert Hölzl
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 <[hidden email]>
Postdoc researcher - Université Libre de Bruxelles


_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

signature.asc (235 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: github

Christian Jullien-3
Hi, I can just say that armhf is not broken on a real (RPi 4) plateform.

-----Original Message-----
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=[hidden email]] On Behalf Of Giovanni Mascellani
Sent: Sunday, April 19, 2020 08:29
To: [hidden email]
Subject: Re: [Tinycc-devel] github

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 <[hidden email]> Postdoc researcher - Université Libre de Bruxelles



_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Reply | Threaded
Open this post in threaded view
|

Re: github

Michael Matz-4
In reply to this post by Giovanni Mascellani
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.

_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Reply | Threaded
Open this post in threaded view
|

Re: github

Michael Matz-4
In reply to this post by Robert Hölzl
Hello Robert,

On Sat, 18 Apr 2020, Robert Hölzl wrote:

> How about a CI?

See also https://gitlab.com/giomasce/tinycc/pipelines .

> I would be happy to add the corresponding scripts, so that at least windows
> (x86 and x64), linux (x64) and macos (x64) are tested.
> I did not investigate yet, but it could be even possible to utlitze qemu to
> test all cpu archs (not only x86, x64).
>
> But to make this work I need the repo to be homed at github or gitlab.
> It seems that on github there is already an organization "TinyCC".
> Bit it seems not to be supported by the core devs.
> In fact the guy which created this repo even started some CI scripts.
>
> @the core devs: Please point our your thoughts.
> Are you interested in a CI (even it might need a switch to GitHub/GitLab/...)
I think a CI is worthwhile to have, if people look at it at least semi
regularly.  But a mirror is enough to have a CI running.


Ciao,
Michael.
_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Reply | Threaded
Open this post in threaded view
|

Re: github

Christian Jullien-3
In reply to this post by Michael Matz-4
> 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 :)

Wouah! I'd love to have it.

-----Original Message-----
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=[hidden email]] On Behalf Of Michael Matz
Sent: Tuesday, April 21, 2020 16:05
To: [hidden email]
Subject: Re: [Tinycc-devel] github

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.

_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel


_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Reply | Threaded
Open this post in threaded view
|

Re: github

Federico Bianchi-2
In reply to this post by Michael Matz-4
How about Darling?

https://darlinghq.org/

Regards
--
Federico Bianchi
polo 4 @ SID UniPI.IT

On Tue, 21 Apr 2020, Christian Jullien wrote:

>> 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 :)
>
> Wouah! I'd love to have it.
>
> -----Original Message-----
> From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=[hidden email]] On Behalf Of Michael Matz
> Sent: Tuesday, April 21, 2020 16:05
> To: [hidden email]
> Subject: Re: [Tinycc-devel] github
>
> 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.
>
> _______________________________________________
> Tinycc-devel mailing list
> [hidden email]
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
>
>
> _______________________________________________
> Tinycc-devel mailing list
> [hidden email]
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel

_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel