In i686-linux bootstrap/regtest, I see:
                === gdc tests ===


Running target unix
FAIL: gdc.dg/compilable.d   -O0  (test for excess errors)
FAIL: gdc.dg/compilable.d   -O0 -frelease  (test for excess errors)
FAIL: gdc.dg/compilable.d   -O0 -frelease -g  (test for excess errors)
FAIL: gdc.dg/compilable.d   -O0 -g  (test for excess errors)
FAIL: gdc.dg/compilable.d   -O1  (test for excess errors)
FAIL: gdc.dg/compilable.d   -O1 -frelease  (test for excess errors)
FAIL: gdc.dg/compilable.d   -O1 -frelease -g  (test for excess errors)
FAIL: gdc.dg/compilable.d   -O1 -g  (test for excess errors)
FAIL: gdc.dg/compilable.d   -O2  (test for excess errors)
FAIL: gdc.dg/compilable.d   -O2 -frelease  (test for excess errors)
FAIL: gdc.dg/compilable.d   -O2 -frelease -g  (test for excess errors)
FAIL: gdc.dg/compilable.d   -O2 -g  (test for excess errors)
FAIL: gdc.dg/compilable.d   -O3  (test for excess errors)
FAIL: gdc.dg/compilable.d   -O3 -frelease  (test for excess errors)
FAIL: gdc.dg/compilable.d   -O3 -frelease -g  (test for excess errors)
FAIL: gdc.dg/compilable.d   -O3 -g  (test for excess errors)
FAIL: gdc.dg/compilable.d   -Os  (test for excess errors)
FAIL: gdc.dg/compilable.d   -Os -frelease  (test for excess errors)
FAIL: gdc.dg/compilable.d   -Os -frelease -g  (test for excess errors)
FAIL: gdc.dg/compilable.d   -Os -g  (test for excess errors)
FAIL: gdc.dg/simd.d   -O0  (test for excess errors)
FAIL: gdc.dg/simd.d   -O0 -frelease  (test for excess errors)
FAIL: gdc.dg/simd.d   -O0 -frelease -g  (test for excess errors)
FAIL: gdc.dg/simd.d   -O0 -g  (test for excess errors)
FAIL: gdc.dg/simd.d   -O1  (test for excess errors)
FAIL: gdc.dg/simd.d   -O1 -frelease  (test for excess errors)
FAIL: gdc.dg/simd.d   -O1 -frelease -g  (test for excess errors)
FAIL: gdc.dg/simd.d   -O1 -g  (test for excess errors)
FAIL: gdc.dg/simd.d   -O2  (test for excess errors)
FAIL: gdc.dg/simd.d   -O2 -frelease  (test for excess errors)
FAIL: gdc.dg/simd.d   -O2 -frelease -g  (test for excess errors)
FAIL: gdc.dg/simd.d   -O2 -g  (test for excess errors)
FAIL: gdc.dg/simd.d   -O3  (test for excess errors)
FAIL: gdc.dg/simd.d   -O3 -frelease  (test for excess errors)
FAIL: gdc.dg/simd.d   -O3 -frelease -g  (test for excess errors)
FAIL: gdc.dg/simd.d   -O3 -g  (test for excess errors)
FAIL: gdc.dg/simd.d   -Os  (test for excess errors)
FAIL: gdc.dg/simd.d   -Os -frelease  (test for excess errors)
FAIL: gdc.dg/simd.d   -Os -frelease -g  (test for excess errors)
FAIL: gdc.dg/simd.d   -Os -g  (test for excess errors)
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
FAIL: runnable/eh.d -O2   execution test
FAIL: runnable/eh.d -O2 -shared-libphobos   execution test
FAIL: runnable/nulltype.d   execution test
FAIL: runnable/nulltype.d -O2   execution test
FAIL: runnable/nulltype.d -O2 -shared-libphobos   execution test
FAIL: runnable/nulltype.d -g   execution test
FAIL: runnable/nulltype.d -g -O2   execution test
FAIL: runnable/nulltype.d -g -O2 -shared-libphobos   execution test
FAIL: runnable/nulltype.d -g -shared-libphobos   execution test
FAIL: runnable/nulltype.d -shared-libphobos   execution test
FAIL: runnable/template1.d   execution test
FAIL: runnable/template1.d -O2   execution test
FAIL: runnable/template1.d -O2 -frelease   execution test
FAIL: runnable/template1.d -O2 -frelease -shared-libphobos   execution test
FAIL: runnable/template1.d -O2 -shared-libphobos   execution test
FAIL: runnable/template1.d -frelease   execution test
FAIL: runnable/template1.d -frelease -shared-libphobos   execution test
FAIL: runnable/template1.d -g   execution test
FAIL: runnable/template1.d -g -O2   execution test
FAIL: runnable/template1.d -g -O2 -frelease   execution test
FAIL: runnable/template1.d -g -O2 -frelease -shared-libphobos   execution test
FAIL: runnable/template1.d -g -O2 -shared-libphobos   execution test
FAIL: runnable/template1.d -g -frelease   execution test
FAIL: runnable/template1.d -g -frelease -shared-libphobos   execution test
FAIL: runnable/template1.d -g -shared-libphobos   execution test
FAIL: runnable/template1.d -shared-libphobos   execution test

                === libphobos tests ===


Running target unix
FAIL: libphobos.unittests/phobos/shared/std.math
FAIL: libphobos.unittests/phobos/shared/std.typecons

The compilable.d/simd.d FAILs is something fixable through passing in -Wno-psabi (the failures are because the compiler warns that -mmmx and/or -msse or -msse2 changes ABI of some of the functions).  Guess one can reproduce that even on x86_64 with --target_board=unix/-m32/-mno-sse/-mno-mmx .
The other FAILs are the same as yours, except for the libphobos tests.

Author: jakub
Date: Thu Nov  1 11:14:08 2018
New Revision: 265713

URL: https://gcc.gnu.org/viewcvs?rev=265713&root=gcc&view=rev
Log:
	PR d/87824
	* lang.opt (Wpsabi): New option.

	* gdc.dg/simd.d: Add -Wno-psabi.
	* gdc.dg/compilable.d: Likewise.

Modified:
    trunk/gcc/d/ChangeLog
    trunk/gcc/d/lang.opt
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gdc.dg/compilable.d
    trunk/gcc/testsuite/gdc.dg/simd.d

(In reply to Jakub Jelinek from comment #1)
> In i686-linux bootstrap/regtest, I see:
>                 === gdc tests ===
> 
> 
> 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

This would be dependent on available C++ libraries I guess.  I couldn't reproduce locally, I'll try in a more controlled environment.


> FAIL: runnable/eh.d -O2   execution test
> FAIL: runnable/eh.d -O2 -shared-libphobos   execution test

On x86, the EH handling is unable to determine that two independently thrown exceptions should be chained together.

Currently this is determined by comparing the LSDA, but this doesn't work when a function is partitioned into hot and cold blocks.


> FAIL: runnable/nulltype.d   execution test
> FAIL: runnable/nulltype.d -O2   execution test
> FAIL: runnable/nulltype.d -O2 -shared-libphobos   execution test
> FAIL: runnable/nulltype.d -g   execution test
> FAIL: runnable/nulltype.d -g -O2   execution test
> FAIL: runnable/nulltype.d -g -O2 -shared-libphobos   execution test
> FAIL: runnable/nulltype.d -g -shared-libphobos   execution test
> FAIL: runnable/nulltype.d -shared-libphobos   execution test

This is related to returning null associative array types - internally, a struct{void *ptr}.

Returning {.ptr=NULL} instead of {} is enough for the unoptimized tests to pass.  For the optimized tests, also setting TYPE_TRANSPARENT_AGGR seems to be required as well.

It does make sense as part of the D language to treat associative arrays as just a void*, though I wouldn't know why not setting TYPE_TRANSPARENT_AGGR would have an affect on returning {} in an apparent wrong way.


> FAIL: runnable/template1.d   execution test
> FAIL: runnable/template1.d -O2   execution test
> FAIL: runnable/template1.d -O2 -frelease   execution test
> FAIL: runnable/template1.d -O2 -frelease -shared-libphobos   execution test
> FAIL: runnable/template1.d -O2 -shared-libphobos   execution test
> FAIL: runnable/template1.d -frelease   execution test
> FAIL: runnable/template1.d -frelease -shared-libphobos   execution test
> FAIL: runnable/template1.d -g   execution test
> FAIL: runnable/template1.d -g -O2   execution test
> FAIL: runnable/template1.d -g -O2 -frelease   execution test
> FAIL: runnable/template1.d -g -O2 -frelease -shared-libphobos   execution
> test
> FAIL: runnable/template1.d -g -O2 -shared-libphobos   execution test
> FAIL: runnable/template1.d -g -frelease   execution test
> FAIL: runnable/template1.d -g -frelease -shared-libphobos   execution test
> FAIL: runnable/template1.d -g -shared-libphobos   execution test
> FAIL: runnable/template1.d -shared-libphobos   execution test
> 

This is caused by misalignment of long.  Will send a patch for this.


> FAIL: libphobos.unittests/phobos/shared/std.typecons
> 

std.typecons failed for same reason as runnable/template1.d

(In reply to Iain Buclaw from comment #3)
> (In reply to Jakub Jelinek from comment #1)

> > FAIL: runnable/eh.d -O2   execution test
> > FAIL: runnable/eh.d -O2 -shared-libphobos   execution test
> 
> On x86, the EH handling is unable to determine that two independently thrown
> exceptions should be chained together.
> 
> Currently this is determined by comparing the LSDA, but this doesn't work
> when a function is partitioned into hot and cold blocks.
> 
> 

Having -fno-reorder-blocks-and-partitions the default is also enough for exception chaining to work as expected.

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.

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

On Sun, 11 Nov 2018, johannespfau at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87824
> 
> Johannes Pfau <johannespfau at gmail dot com> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                  CC|                            |johannespfau at gmail dot com
> 
> --- Comment #5 from Johannes Pfau <johannespfau at gmail dot com> ---
> 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.

To check other variants you have to do sth like

make -jN -k check RUNTESTFLAGS="--target_board=unix/\{,-m32\}"

if you have a x32 runtime you can add ,-mx32 as well.

Thanks to both of you for the advice. So we should probably enable 32bit multilib testing on semaphore or buildkite then.

Back to this bug report:
---------------------
FAIL: libphobos.shared/loadDR.c -ldl -pthread -g execution test 
---------------------

This is fortunately only a test-setup problem:
---------------------
set libphobos_run_args "$objdir/../src/.libs/libgphobos.so"
---------------------
https://github.com/D-Programming-GDC/GDC/blob/stable/libphobos/testsuite/libphobos.shared/shared.exp#L97

This references the wrong library ([...]/objdir/x86_64-pc-linux-gnu/libphobos/testsuite/../src/.libs/libgphobos.so) for multilib builds. I guess there should be some variable which properly considers the multilib setup?

Fix for the loadDR failure: https://github.com/D-Programming-GDC/GDC/pull/767

(In reply to Johannes Pfau from comment #9)
> Fix for the loadDR failure: https://github.com/D-Programming-GDC/GDC/pull/767

Could you post that to gcc-patches?

Should probably get write after approval for you as well.

Author: ibuclaw
Date: Sat Nov 17 11:01:00 2018
New Revision: 266234

URL: https://gcc.gnu.org/viewcvs?rev=266234&root=gcc&view=rev
Log:
Fix wrong alignment returned by .alignof property.

The D language expects the value to be the minimum alignment required
for the type, not the preferred alignment.

gcc/d/ChangeLog:

2018-11-17  Iain Buclaw  <ibuclaw@gdcproject.org>

	PR d/87824
	* d-target.cc (Target::alignsize): Return min_align_of_type.

Modified:
    trunk/gcc/d/ChangeLog
    trunk/gcc/d/d-target.cc

Iain: Can the bug be marked as resolved?

On Tue, 20 Nov 2018, marxin at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87824
> 
> --- Comment #12 from Martin Liška <marxin at gcc dot gnu.org> ---
> Iain: Can the bug be marked as resolved?

I still see FAILs.

Author: ibuclaw
Date: Thu Nov 22 06:14:47 2018
New Revision: 266366

URL: https://gcc.gnu.org/viewcvs?rev=266366&root=gcc&view=rev
Log:
libphobos/ChangeLog:

2018-11-22  Johannes Pfau  <johannespfau@gmail.com>

	PR d/87824
	* testsuite/libphobos.shared/shared.exp: Set proper path to phobos
	library for multilib builds.

Modified:
    trunk/libphobos/ChangeLog
    trunk/libphobos/testsuite/libphobos.shared/shared.exp

Still to do are:

- runnable/cppa.d: (Remove struct __c_{u}long detection and tests)
- runnable/eh.d: (Have -fno-reorder-blocks-and-partitions default for D)
- runnable/nulltype.d (Set TYPE_TRANSPARENT_AGGR for D associative arrays)

I'm still unsure about setting TYPE_TRANSPARENT_AGGR, it seems like its more masking something else on x86.  Though as I've said, associative arrays are just a `struct{void*}` and treated as if it were a pointer anyway.

Created attachment 45231 [details]
Patch for cppa.d with non-default multilib failure

(In reply to Iain Buclaw from comment #6)
[...]
> > 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.

I'm seeing the same not only on Linux/x86_64, but also on Solaris/x86, only
for the non-default multilib.

The failure is the same however:

In file included from runnable/extra-files/cppb.cpp:36:^M
/vol/gcc/src/hg/trunk/dist/gcc/testsuite/../../libstdc++-v3/libsupc++/exception:37:10: fatal error: bits/c++config.h: No such file or directory^M


Looking at the -I flags passed, it's obvious that they are wrong: on Linux/x86_64 there is

-I/var/scratch/gcc/regression/trunk/4.17.3-gcc-gas-gld/build/x86_64-pc-linux-gnu/32/libstdc++-v3/include/32

while on Solaris/x86 it's

-I/var/gcc/regression/trunk/11.3-gcc-gas/build/i386-pc-solaris2.11/amd64/libstdc++-v3/include/amd64

neither of which exist: the last component should be $target_triplet instead
of $target.  Fixing this as in the attached patch lets the test PASS for me
on both x86_64-pc-linux-gnu and i386-pc-solaris2.11 (32 and 64-bit each).

Author: ibuclaw
Date: Wed Jan 16 20:40:21 2019
New Revision: 267985

URL: https://gcc.gnu.org/viewcvs?rev=267985&root=gcc&view=rev
Log:
[D] Fix failing EH execution test on i386.

Turn off partitioning unless it was explicitly requested, as it doesn't
work with D exception chaining, where personality routines use LSDA to
determine whether two thrown exceptions are in the same context.

The following distills what was failing in the D testsuite.
```
try {
  try {
    fn();  // throws "1"
  }
  finally {
    throw new Exception("2");
  }
}
catch (Exception e) {
  assert(e.msg == "1");
  assert(e.next.msg == "2");
}
```

gcc/d/ChangeLog:

	PR d/87824
	* d-lang.cc (d_post_options): Disable implicit
	-forder-blocks-and-partition.

Modified:
    trunk/gcc/d/ChangeLog
    trunk/gcc/d/d-lang.cc

On another look, (In reply to Iain Buclaw from comment #15)
> Still to do are:
> 
> - runnable/cppa.d: (Remove struct __c_{u}long detection and tests)
> - runnable/eh.d: (Have -fno-reorder-blocks-and-partitions default for D)
> - runnable/nulltype.d (Set TYPE_TRANSPARENT_AGGR for D associative arrays)
> 
> I'm still unsure about setting TYPE_TRANSPARENT_AGGR, it seems like its more
> masking something else on x86.  Though as I've said, associative arrays are
> just a `struct{void*}` and treated as if it were a pointer anyway.

On another look, the D language implementation is treating `typeof(null) function()` as being covariant with `int[int] function()`.

The former is a function that returns `void*`, the latter returns `struct{void*}`.

There is no difference on x86_64, but on others the difference is subtle.

---
ret_typeof_null:
        mov     eax, 0
        ret

ret_aa_null:
        mov     eax, DWORD PTR 4[esp]
        mov     DWORD PTR [eax], 0
        ret     4
---

I'm going to send a change upstream that these types should not be covariant, rather than changing the ABI of associative arrays by setting TYPE_TRANSPARENT_AGGR.

(In reply to Rainer Orth from comment #17)
> (In reply to Iain Buclaw from comment #6)
> [...]
> > > 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.
> 
> I'm seeing the same not only on Linux/x86_64, but also on Solaris/x86, only
> for the non-default multilib.
> 
> The failure is the same however:
> 
> In file included from runnable/extra-files/cppb.cpp:36:^M
> /vol/gcc/src/hg/trunk/dist/gcc/testsuite/../../libstdc++-v3/libsupc++/
> exception:37:10: fatal error: bits/c++config.h: No such file or directory^M

I'd like to propose an alternative patch. The testsuite harness should simply ask libstdc++ for correct include paths, like in the to be attached patch.

(This is how libstdc++ testsuite determines correct include flags.)

Created attachment 45786 [details]
Patch for libstdc++ multilib include issue

(In reply to Uroš Bizjak from comment #20)
> 
> I'd like to propose an alternative patch. The testsuite harness should
> simply ask libstdc++ for correct include paths, like in the to be attached
> patch.
> 
> (This is how libstdc++ testsuite determines correct include flags.)

Seems reasonable.

Filtering out flags not recognized by D would mean there's no need to touch libstdc++.


# For the tests that mix C++ and D, need to know where headers are located.
set odir [lookfor_file ${gccpath} libstdc++-v3]
if { ${odir} != "" } {
    set cxxflags [exec sh ${odir}/scripts/testsuite_flags --build-includes]
    set idx [lsearch $cxxflags "-nostdinc++"]
    append flags [lreplace $cxxflags $idx $idx]
}

(In reply to Iain Buclaw from comment #22)
> (In reply to Uroš Bizjak from comment #20)
> > 
> > I'd like to propose an alternative patch. The testsuite harness should
> > simply ask libstdc++ for correct include paths, like in the to be attached
> > patch.
> > 
> > (This is how libstdc++ testsuite determines correct include flags.)
> 
> Seems reasonable.
> 
> Filtering out flags not recognized by D would mean there's no need to touch
> libstdc++.
> 
> 
> # For the tests that mix C++ and D, need to know where headers are located.
> set odir [lookfor_file ${gccpath} libstdc++-v3]
> if { ${odir} != "" } {
>     set cxxflags [exec sh ${odir}/scripts/testsuite_flags --build-includes]
>     set idx [lsearch $cxxflags "-nostdinc++"]
>     append flags [lreplace $cxxflags $idx $idx]
> }

Yes, this would also work; there are some additional include directories that look specific to libstdc++ testing, but won't hurt here.

So, do you want me to officially propose the above patch or do you want to take it from here?

Author: ibuclaw
Date: Sun Mar 10 21:55:30 2019
New Revision: 269561

URL: https://gcc.gnu.org/viewcvs?rev=269561&root=gcc&view=rev
Log:
    PR d/87824
d/dmd: Merge upstream dmd fcc235e8e

Associative arrays are value types, which are not covariant with the
pointer type typeof(null).

Updates https://gcc.gnu.org/PR87824

Reviewed-on: https://github.com/dlang/dmd/pull/9435

Modified:
    trunk/gcc/d/dmd/MERGE
    trunk/gcc/d/dmd/mtype.c
    trunk/gcc/testsuite/gdc.test/runnable/nulltype.d

Author: uros
Date: Tue Mar 12 18:37:31 2019
New Revision: 269625

URL: https://gcc.gnu.org/viewcvs?rev=269625&root=gcc&view=rev
Log:
	PR d/87824
	* lib/gdc.exp (gdc_include_flags): Find C++ headers by calling
	libstdc++v3/scripts/testsuite_flags.  Filter out unsupported
	-nostdinc++ flag.


Modified:
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/lib/gdc.exp

I think r269625 was the last one to do in the list.