https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89255
--- Comment #4 from Iain Buclaw <ibuclaw at gdcproject dot org> ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #3)
>
> * On Linux/x86_64, I see a few failures on i686:
>
> Running target unix/-m32
> FAIL: ../libdruntime/core/thread.d -fversion=Shared -shared-libphobos (test
> for excess errors)
>
> Excess errors:
> /vol/gcc/bin/gld-2.32: warning: type and size of dynamic symbol
> `fiber_switchContext' are not defined
>
> FAIL: ../libdruntime/core/thread.d -fversion=Shared -shared-libphobos
> execution test
>
I saw that when checking -m32. The linker gives the hint, the assembler
implementation of fiber_switchContext has neither type or size, and a segfault
occurs calling the function at run-time. I added .type @function to resolve,
intended to push that later.
> WARNING: ../src/std/net/curl.d -fversion=Shared -shared-libphobos execution
> test program timed out.
> FAIL: ../src/std/net/curl.d -fversion=Shared -shared-libphobos execution test
> WARNING: ../src/std/parallelism.d -fversion=Shared -shared-libphobos
> execution test program timed out.
> FAIL: ../src/std/parallelism.d -fversion=Shared -shared-libphobos execution
> test
>
> Those are PR d/89254, where the first had been fixed already in the old
> setup. The std.parallelism one may be related to the fact that I'm
> running the bootstrap on an 8-socket system with 10 cores each and
> hyperthreading, i.e. 160 cores.
>
> Those two are especially unfortunate since they hang indefinitely until
> I manually kill them, thus always require manual intervention.
>
Are they not killed after the timeout? I think it's 600 seconds by default.
> * On Solaris 11/x86, results are not too bad:
>
> === libphobos tests ===
>
>
> Running target unix
> FAIL: ../libdruntime/core/sync/mutex.d -fversion=Shared -shared-libphobos
> execution test
>
> This one existed before:
>
> core.exception.AssertError@/vol/gcc/src/hg/trunk/local/libphobos/testsuite/..
> /libdruntime/core/sync/mutex.d(381): unittest failure
>
---
// Verify that the underlying implementation has been destroyed
// by checking that locking is not possible. This assumes
// that the underlying implementation is well behaved
// and makes the object non-lockable upon destruction.
// The Bionic and Musl C runtimes and DragonFly don't appear to do so, so skip
this test.
version (CRuntime_Bionic) {} else
version (CRuntime_Musl) {} else
version (DragonFlyBSD) {} else
assert(!mtx.tryLock_nothrow());
---
This is starting to look silly, but adding version (Solaris) to the growing
list may be required.
> FAIL: ../libdruntime/core/thread.d -fversion=Shared -shared-libphobos (test
> for excess errors)
>
> Excess errors:
> warning: Text relocation remains referenced
> against symbol offset in file
> fiber_switchContext 0x4505 /var/tmp//ccYMWL0c.o
> fiber_switchContext 0x4b98 /var/tmp//ccYMWL0c.o
>
> This code should be compiled with -fpic/-fPIC to avoid this.
>
threadasm.S is already be compiled with -fPIC for the pic_object. But not I
see for the non_pic_object unlike all *.d sources. But it doesn't look like
it's the static library test that's failing here.
> FAIL: ../libdruntime/rt/minfo.d -fversion=Shared -shared-libphobos execution
> test
>
> No indication in the logs what happened.
>
More alignment woes with ModuleInfo?
> FAIL: ../src/std/base64.d -fversion=Shared -shared-libphobos (test for
> excess errors)
>
> Excess errors:
> ld: warning: symbol
> '_D3std8internal7cstring23__T11tempCStringTaTAyaZ11tempCStringFAyaZ3Res6__ini
> tZ' has differing sizes:
> (file /var/tmp//ccN7CxXc.o value=0x18; file
> /var/gcc/regression/trunk/11.5-gcc-gas/build/i386-pc-solaris2.11/libphobos/
> src/.libs/libgphobos.so value=0x108);
> /var/tmp//ccN7CxXc.o definition taken
>
> There are several more testcases affected by this issue, all involving
> one of
>
> std.internal.cstring.tempCString!(char,
> const(char)[]).tempCString(const(char)[]).Res
> std.internal.cstring.tempCString!(char,
> const(char)[]).tempCString(const(char)[]).Res
> std.internal.cstring.tempCString!(char,
> immutable(char)[]).tempCString(immutable(char)[]).Res
> std.internal.cstring.tempCString!(char,
> immutable(char)[]).tempCString(immutable(char)[]).Res
> std.internal.cstring.tempCString!(char,
> inout(char)[]).tempCString(inout(char)[]).Res
> std.internal.cstring.tempCString!(char,
> inout(char)[]).tempCString(inout(char)[]).Res
>
> AFAIK there's no way to disable this warning.
>
---
version (unittest)
{
// smaller size to trigger reallocations
enum buffLength = 16 / To.sizeof;
}
else
{
// production size
enum buffLength = 256 / To.sizeof;
}
To[buffLength] _buff; // the 'small string optimization'
---
The library should not be doing that...
> FAIL: ../src/std/datetime/systime.d -fversion=Shared -shared-libphobos
> execution test
>
> core.exception.AssertError@/vol/gcc/src/hg/trunk/local/libphobos/testsuite/..
> /src/std/datetime/systime.d(732): Value given: -1998-Jan-01 01:59:59
>
Timezone is incorrect?
> FAIL: ../src/std/datetime/timezone.d -fversion=Shared -shared-libphobos
> (test for excess errors)
>
> Excess errors:
> /vol/gcc/src/hg/trunk/local/libphobos/testsuite/../src/std/datetime/timezone.
> d:299: error: static assert "The location of the UTC timezone file on this
> Posix platform must be set."
>
That probably confirms it.
Looking quickly at upstream, I see this patch in master that looks to be
needing a backport.
https://github.com/dlang/phobos/commit/9f8482a5ac6bfc963e7f4c4814f2982f1500e501
> UNRESOLVED: ../src/std/datetime/timezone.d -fversion=Shared
> -shared-libphobos compilation failed to produce executable
> FAIL: ../src/std/experimental/allocator/building_blocks/stats_collector.d
> -fversion=Shared -shared-libphobos (test for excess errors)
> FAIL: ../src/std/experimental/logger/core.d -fversion=Shared
> -shared-libphobos (test for excess errors)
> FAIL: ../src/std/experimental/logger/filelogger.d -fversion=Shared
> -shared-libphobos (test for excess errors)
> FAIL: ../src/std/experimental/logger/filelogger.d -fversion=Shared
> -shared-libphobos execution test
> FAIL: ../src/std/experimental/logger/multilogger.d -fversion=Shared
> -shared-libphobos (test for excess errors)
> FAIL: ../src/std/file.d -fversion=Shared -shared-libphobos (test for excess
> errors)
> FAIL: ../src/std/file.d -fversion=Shared -shared-libphobos execution test
>
> core.exception.AssertError@/vol/gcc/src/hg/trunk/local/libphobos/testsuite/..
> /src/std/file.d(1040): unittest failure
>
Also related to clock/timezone problems?
> FAIL: ../src/std/format.d -fversion=Shared -shared-libphobos execution test
>
> core.exception.AssertError@/vol/gcc/src/hg/trunk/local/libphobos/testsuite/..
> /src/std/format.d(4288): unittest failure
>
---
formattedWrite(stream, "%a %A", 1.32, 6.78f);
assert(stream.data == "0x1.51eb851eb851fp+0 0X1.B1EB86P+2");
---
It should use snprintf() under the hood if I recall correctly.
> FAIL: ../src/std/mmfile.d -fversion=Shared -shared-libphobos (test for
> excess errors)
> FAIL: ../src/std/net/curl.d -fversion=Shared -shared-libphobos (test for
> excess errors)
> WARNING: ../src/std/net/curl.d -fversion=Shared -shared-libphobos execution
> test program timed out.
> FAIL: ../src/std/net/curl.d -fversion=Shared -shared-libphobos execution test
> FAIL: ../src/std/parallelism.d -fversion=Shared -shared-libphobos (test for
> excess errors)
> FAIL: ../src/std/parallelism.d -fversion=Shared -shared-libphobos execution
> test
>
> core.exception.AssertError@/vol/gcc/src/hg/trunk/local/libphobos/testsuite/..
> /src/std/parallelism.d(3955): unittest failure
>
---
poolInstance.priority = Thread.PRIORITY_MAX;
assert(poolInstance.priority == Thread.PRIORITY_MAX);
poolInstance.priority = Thread.PRIORITY_MIN;
assert(poolInstance.priority == Thread.PRIORITY_MIN);
---
The first passes, but the second doesn't?
> FAIL: ../src/std/process.d -fversion=Shared -shared-libphobos (test for
> excess errors)
> FAIL: ../src/std/process.d -fversion=Shared -shared-libphobos execution test
>
> /vol/gcc/src/hg/trunk/local/libphobos/testsuite/../src/std/process.d:1027:
> Warning: Couldn't find any way to check open files
> core.exception.RangeError@/vol/gcc/src/hg/trunk/local/libphobos/src/std/file.
> d(3096): Range violation
>
---
immutable len = core.stdc.string.strlen(fd.d_name.ptr);
_name = buildPath(path, fd.d_name[0 .. len]);
---
Definition of `struct dirent` on Solaris:
---
struct dirent
{
ino_t d_ino;
off_t d_off;
ushort d_reclen;
char[1] d_name = 0;
}
---
So the only accessible parts of the array are [0 .. 1]. Apparently there is
nothing wrong with the definition, as far as I can tell by looking up, Solaris
has a dynamically allocated size for d_name, so a special case is required to
bypass bounds checking.
> FAIL: ../src/std/range/package.d -fversion=Shared -shared-libphobos (test
> for excess errors)
> FAIL: ../src/std/socket.d -fversion=Shared -shared-libphobos (test for
> excess errors)
> FAIL: ../src/std/stdio.d -fversion=Shared -shared-libphobos (test for excess
> errors)
> FAIL: ../src/std/stdio.d -fversion=Shared -shared-libphobos execution test
>
> std.exception.ErrnoException@/vol/gcc/src/hg/trunk/local/libphobos/testsuite/
> ../src/std/stdio.d(1028): Could not seek in file
> `/tmp/deleteme.dmd.unittest.pid16148-детка.stdio.d.1037' (Invalid argument)
>
There's no backtrace, so don't know which unittest it came from, what are the
reasons why fseeko may return invalid argument on Solaris? Specifically
anything that differs from other implementations.
> FAIL: libphobos.shared/finalize.d -shared-libphobos -ldl execution test
> FAIL: libphobos.shared/finalize.d -shared-libphobos -ldl execution test
> FAIL: libphobos.shared/finalize.d -shared-libphobos -ldl execution test
> FAIL: libphobos.shared/finalize.d -shared-libphobos -ldl execution test
> FAIL: libphobos.shared/finalize.d -shared-libphobos -ldl execution test
> FAIL: libphobos.shared/finalize.d -shared-libphobos -ldl execution test
> FAIL: libphobos.shared/finalize.d -shared-libphobos -ldl execution test
> FAIL: libphobos.shared/finalize.d -shared-libphobos -ldl execution test
> FAIL: libphobos.shared/finalize.d -shared-libphobos -ldl execution test
> FAIL: libphobos.shared/finalize.d -shared-libphobos -ldl execution test
>
> compilation is run 10 times in exactly the same way!?
>
Maybe something is missing in the part copied from GCC_RUNTEST_PARALLELIZE. I
did see problems copying gcc_parallel_test_run_p and other procedures locally
to the libphobos testsuite, it looked like it replaced itself incorrectly.
