https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87824
--- Comment #6 from Iain Buclaw <ibuclaw at gdcproject dot org> ---
(In reply to Johannes Pfau from comment #5)
> Iain, is there a specific reason why we don't have i686 on the GDC/buildkite
> CI? We could simply run a QEMU/KVM VM on a x86_64 host for this.
>
> And when running the testsuite on multilib, is it now running all tests
> (test suite and druntime, phobos) for all multilib variants? I think last
> time I checked, multilib testing tested only the main variant for some
> reason.
Just need to add i686 to the list of test configurations, and then adjust CI
script to run make check with
RUNTESTFLAGS="--target_board=unix/-m32/-mno-sse/-mno-mmx". This is already
done for ARM.
However... there should be more servers thrown into the build farm, and not
just Linux VPS boxes. Running QEMU probably warrants getting dedicated
hardware instead.
> Running target unix
> FAIL: runnable/cppa.d execution test
> FAIL: runnable/cppa.d -g execution test
> FAIL: runnable/cppa.d -g -shared-libphobos execution test
> FAIL: runnable/cppa.d -shared-libphobos execution test
Have now reproduced, the test checks old behaviour that I dropped support for
long ago. The first failed attempt to have a type that maps to C 'long' and
'unsigned long' had a 'struct __c_long' type that expected the compiler to
magically pass it around as the correct integer type. This had passed/gone
unnoticed on x86_64 because 'struct{long}' and 'long' are passed in the same
way.
Support should have been removed from the dmd front-end when it was dropped
from the library, but it still lives on in the testsuite.
