Hi Rainer,
I suspect the two testsuite regressions (compared to a build with
dlpi_tls_modid present) I mentioned are exactly of the kind you mention:
e.g. the gdc.test/runnable/testaa.d failures are like this
core.exception.rangeer...@gdc.test/runnable/testaa.d(410): Range violation
----------------
/vol/gcc/src/hg/trunk/local/libphobos/libdruntime/core/exception.d:496
onRangeError [0x80f0d2c]
/vol/gcc/src/hg/trunk/local/libphobos/libdruntime/core/exception.d:672
_d_arraybounds [0x80f132f]
??:? void testaa.test15() [0x80d7ae4]
??:? _Dmain [0x80dd3fc]
before test 1
and gdc.test/runnable/xtest55.d fails like so:
core.exception.asserter...@gdc.test/runnable/xtest55.d(19): Assertion failure
----------------
/vol/gcc/src/hg/trunk/local/libphobos/libdruntime/core/exception.d:441
onAssertError [0x7fff55dd3b56]
??:? _Dmain [0x418959]
7FFFBEB00000 7FFFBEB00000
If you want to verify whether it's really a GC problem, you can add this
in the main function to disable GC collections:
import core.memory;
GC.disable();
This should be fine for the test suite. If you want to do this for the
unit tests it's slightly more complicated as the main functions is
executed _after_ all unit tests. IIRC adding it in a shared static
this() module constructor would work there.
Best regards,
Johannes
