[Bug bootstrap/92002] [10/11 regression] -Wuninitialized warning in gcc/wide-int.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92002 Rainer Orth changed: What|Removed |Added URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2021-March/5 ||66180.html --- Comment #17 from Rainer Orth --- Workaround patch installed for GCC 11.1.
[Bug gcov-profile/99385] New: [11 regression] gcc.dg/tree-prof/indir-call-prof-malloc.c etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99385 Bug ID: 99385 Summary: [11 regression] gcc.dg/tree-prof/indir-call-prof-malloc.c etc. FAIL Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: gcov-profile Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: marxin at gcc dot gnu.org Target Milestone: --- Target: *-*-solaris2.11 Between 20210302 (f8e4d7a6597fa81ff927156a5f5d10b7fdaa0bc0) and 20210303 (39d7eb8a73d5f8c09db20926a98181181d9dd2c2), two tests began to FAIL on Solaris (sparc and x86, 32 and 64-bit): +UNRESOLVED: gcc.dg/tree-prof/indir-call-prof-malloc.c compilation, -fprofile-use -D_PROFILE_USE +FAIL: gcc.dg/tree-prof/indir-call-prof-malloc.c execution, -fprofile-generate -D_PROFILE_GENERATE +UNRESOLVED: gcc.dg/tree-prof/indir-call-prof-malloc.c execution, -fprofile-use -D_PROFILE_USE +UNRESOLVED: gcc.dg/tree-prof/pr97461.c compilation, -fprofile-use -D_PROFILE_USE +FAIL: gcc.dg/tree-prof/pr97461.c execution,-fprofile-generate -D_PROFILE_GENERATE +UNRESOLVED: gcc.dg/tree-prof/pr97461.c execution,-fprofile-use -D_PROFILE_USE The first failure is a regression, the second test is new from commit 00d79dc4be0b86ec564cfa2b32c47de6c07449e6 Author: Martin Liska Date: Wed Jan 13 11:17:03 2021 +0100 gcov: use mmap pools for KVP. The failure looks like this: Thread 2 received signal SIGSEGV, Segmentation fault. [Switching to Thread 1 (LWP 1)] 0xfeb7d464 in _malloc_unlocked () from /lib/libc.so.1 (gdb) where #0 0xfeb7d464 in _malloc_unlocked () from /lib/libc.so.1 #1 0xfeb7d318 in do_malloc () from /lib/libc.so.1 Running the test under truss shows [...] mmap64(0x, 131072, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANON, 0, 0) Err#22 EINVAL Incurred fault #6, FLTBOUNDS %pc = 0xFEC546B0 siginfo: SIGSEGV SEGV_MAPERR addr=0xFF3FFFA8 Received signal #11, SIGSEGV [default] siginfo: SIGSEGV SEGV_MAPERR addr=0xFF3FFFA8 Every single mmap64 call fails with EINVAL. According to Solaris mmap(2), this is due to MAP_ANON was specified, but the file descriptor was not -1. Linux mmap(2) also documents MAP_ANONYMOUS The mapping is not backed by any file; its contents are initial- ized to zero. The fd argument is ignored; however, some imple- mentations require fd to be -1 if MAP_ANONYMOUS (or MAP_ANON) is specified, and portable applications should ensure this. The and indeed changing the fd arg in the mmap call to -1 lets the tests PASS. However, I believe there's more: imagine the mmap calls fails for other reasons: I don't think the code should simply SEGV then, but I didn't easily see where to do proper error handling for this case.
[Bug gcov-profile/99385] [11 regression] gcc.dg/tree-prof/indir-call-prof-malloc.c etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99385 Rainer Orth changed: What|Removed |Added Target Milestone|--- |11.0
[Bug gcov-profile/99406] New: [11 regression] MAP_ANONYMOUS undeclared in libgcov.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99406 Bug ID: 99406 Summary: [11 regression] MAP_ANONYMOUS undeclared in libgcov.h Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: gcov-profile Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: iains at gcc dot gnu.org, marxin at gcc dot gnu.org Target Milestone: --- Target: *-apple-darwin11 The unconditional use of MAP_ANONYMOUS in libgcov.h broke Mac OS X 10.7/Darwin 11 bootstrap: In file included from /vol/gcc/src/hg/master/darwin/libgcc/libgcov-merge.c:26: /vol/gcc/src/hg/master/darwin/libgcc/libgcov.h: In function 'malloc_mmap': In file included from /vol/gcc/src/hg/master/darwin/libgcc/libgcov-merge.c:26: /vol/gcc/src/hg/master/darwin/libgcc/libgcov.h: In function 'malloc_mmap': /vol/gcc/src/hg/master/darwin/libgcc/libgcov.h:420:30: error: 'MAP_ANONYMOUS' undeclared (first use in this function); did you mean 'MAP_ANON'? 420 |MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); | ^ | MAP_ANON /vol/gcc/src/hg/master/darwin/libgcc/libgcov.h:420:30: note: each undeclared identifier is reported only once for each function it appears in I haven't checked which macOS version introduced MAP_ANONYMOUS as alias for MAP_ANON, but macOS 11/Darwin 20 has it.
[Bug gcov-profile/99406] [11 regression] MAP_ANONYMOUS undeclared in libgcov.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99406 Rainer Orth changed: What|Removed |Added Target Milestone|--- |11.0
[Bug target/99422] [11 Regression] ICE in extract_constrain_insn building glibc pthread_create
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99422 Rainer Orth changed: What|Removed |Added CC||ro at gcc dot gnu.org --- Comment #12 from Rainer Orth --- Unfortunately, I'm still seeing the ICE reported in PR target/99432 on i386-pc-solaris2.11.
[Bug sanitizer/98920] [10/11 Regression] uses regexec without support for REG_STARTEND with -fsanitize=address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98920 Rainer Orth changed: What|Removed |Added CC||ro at gcc dot gnu.org --- Comment #17 from Rainer Orth --- As I'd reported upstream, the new test FAILs on Solaris: +FAIL: c-c++-common/asan/pr98920.c -O0 (test for excess errors) +UNRESOLVED: c-c++-common/asan/pr98920.c -O0 compilation failed to produce executable +FAIL: c-c++-common/asan/pr98920.c -O1 (test for excess errors) +UNRESOLVED: c-c++-common/asan/pr98920.c -O1 compilation failed to produce executable +FAIL: c-c++-common/asan/pr98920.c -O2 (test for excess errors) +UNRESOLVED: c-c++-common/asan/pr98920.c -O2 compilation failed to produce executable +FAIL: c-c++-common/asan/pr98920.c -O2 -flto (test for excess errors) +UNRESOLVED: c-c++-common/asan/pr98920.c -O2 -flto compilation failed to produce executable +FAIL: c-c++-common/asan/pr98920.c -O2 -flto -flto-partition=none (test for excess errors) +UNRESOLVED: c-c++-common/asan/pr98920.c -O2 -flto -flto-partition=none compilation failed to produce executable +FAIL: c-c++-common/asan/pr98920.c -O3 -g (test for excess errors) +UNRESOLVED: c-c++-common/asan/pr98920.c -O3 -g compilation failed to produce executable +FAIL: c-c++-common/asan/pr98920.c -Os (test for excess errors) +UNRESOLVED: c-c++-common/asan/pr98920.c -Os compilation failed to produce executable Excess errors: /vol/gcc/src/hg/master/local/gcc/testsuite/c-c++-common/asan/pr98920.c:17:66: error: 'REG_STARTEND' was not declared in this scope; did you mean 'REG_EPAREN'? It should either be restricted to glibc targets if that's what it requires, or to those that do support REG_STARTEND.
[Bug target/99422] [11 Regression] ICE in extract_constrain_insn building glibc pthread_create
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99422 Rainer Orth changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org --- Comment #18 from Rainer Orth --- With the two patches for PR 99454, a i386-pc-solaris2.11 bootstraps succeeds. Thanks. Unfortunately, on the SPARC side I still get the ICE reported in Comment 17.
[Bug d/99812] New: [11 regression] Many libphobos.druntime_shared etc. tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99812 Bug ID: 99812 Summary: [11 regression] Many libphobos.druntime_shared etc. tests FAIL Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: d Assignee: ibuclaw at gdcproject dot org Reporter: ro at gcc dot gnu.org Target Milestone: --- Target: *-*-solaris2.11 Between 20210326 (6081d8994ed1a0aef6b7f5fb34f091faa3580416) and 20210328 (d21001c793e97d88013d05226a8ea93a149726b1), many libphobos tests started to FAIL: +FAIL: libphobos.druntime_shared/core/atomic.d (test for excess errors) +FAIL: libphobos.druntime_shared/core/sync/barrier.d (test for excess errors) +FAIL: libphobos.druntime_shared/core/sync/condition.d (test for excess errors) +FAIL: libphobos.druntime_shared/core/sync/mutex.d (test for excess errors) +FAIL: libphobos.druntime_shared/core/sync/rwmutex.d (test for excess errors) +FAIL: libphobos.druntime_shared/core/sync/semaphore.d (test for excess errors) +FAIL: libphobos.druntime_shared/core/thread/fiber.d (test for excess errors) +FAIL: libphobos.druntime_shared/core/thread/osthread.d (test for excess errors) +FAIL: libphobos.druntime_shared/core/time.d (test for excess errors) +FAIL: libphobos.phobos_shared/std/algorithm/comparison.d (test for excess errors) +FAIL: libphobos.phobos_shared/std/algorithm/iteration.d (test for excess errors) +FAIL: libphobos.phobos_shared/std/algorithm/mutation.d (test for excess errors) +FAIL: libphobos.phobos_shared/std/base64.d (test for excess errors) +FAIL: libphobos.phobos_shared/std/concurrency.d (test for excess errors) +FAIL: libphobos.phobos_shared/std/conv.d (test for excess errors) +FAIL: libphobos.phobos_shared/std/datetime/date.d (test for excess errors) +FAIL: libphobos.phobos_shared/std/datetime/interval.d (test for excess errors) +FAIL: libphobos.phobos_shared/std/datetime/stopwatch.d (test for excess errors) +FAIL: libphobos.phobos_shared/std/datetime/systime.d (test for excess errors) +FAIL: libphobos.phobos_shared/std/experimental/allocator/building_blocks/free_list.d (test for excess errors) +FAIL: libphobos.phobos_shared/std/experimental/allocator/building_blocks/stats_collector.d (test for excess errors) +FAIL: libphobos.phobos_shared/std/experimental/allocator/package.d (test for excess errors) +FAIL: libphobos.phobos_shared/std/experimental/logger/core.d (test for excess errors) +FAIL: libphobos.phobos_shared/std/experimental/logger/filelogger.d (test for excess errors) FAIL: libphobos.phobos_shared/std/experimental/logger/filelogger.d execution test +FAIL: libphobos.phobos_shared/std/experimental/logger/multilogger.d (test for excess errors) +FAIL: libphobos.phobos_shared/std/experimental/logger/multilogger.d (test for excess errors) +FAIL: libphobos.phobos_shared/std/experimental/logger/nulllogger.d (test for excess errors) +FAIL: libphobos.phobos_shared/std/file.d (test for excess errors) +FAIL: libphobos.phobos_shared/std/mmfile.d (test for excess errors) +FAIL: libphobos.phobos_shared/std/net/curl.d (test for excess errors) +FAIL: libphobos.phobos_shared/std/numeric.d (test for excess errors) +FAIL: libphobos.phobos_shared/std/parallelism.d (test for excess errors) +FAIL: libphobos.phobos_shared/std/path.d (test for excess errors) +FAIL: libphobos.phobos_shared/std/process.d (test for excess errors) +FAIL: libphobos.phobos_shared/std/range/package.d (test for excess errors) +FAIL: libphobos.phobos_shared/std/socket.d (test for excess errors) +FAIL: libphobos.phobos_shared/std/stdio.d (test for excess errors) +FAIL: libphobos.phobos_shared/std/traits.d (test for excess errors) +FAIL: libphobos.phobos_shared/std/typecons.d (test for excess errors) +FAIL: libphobos.phobos_shared/std/zip.d (test for excess errors) The failures happen on both Solaris/SPARC and x86, 32 and 64-bit. The error is always of the same kind: +FAIL: libphobos.druntime_shared/core/atomic.d (test for excess errors) Excess errors: ld: warning: symbol '_D4core6atomic12__ModuleInfoZ' has differing sizes: (file /var/tmp//cchXf0Ca.o value=0x1c; file /var/gcc/regression/master/11.4-gcc-gas/build/sparc-sun-solaris2.11/libphobos/src/.libs/libgphobos.so value=0x14); /var/tmp//cchXf0Ca.o definition taken This is caused by commit fdfcb5353cc2b06fc80205cfcb3bc5ba25556264 Author: Iain Buclaw Date: Fri Mar 26 15:46:24 2021 +0100 libphobos: Build all modules with -fversion=Shared when configured with --enable-shared which dropped -fno-moduleinfo in both libphobos.druntime_shared/druntime_shared.exp and libphobos.phobos_shared/phobos_shared.exp. I've spot-checked that manually rebuilding a failing testcase with -fno-moduleinfo added back both avoids the linker warning and lets the test execute successfully.
[Bug d/99812] [11 regression] Many libphobos.druntime_shared etc. tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99812 Rainer Orth changed: What|Removed |Added Target Milestone|--- |11.0
[Bug bootstrap/99983] [9/10 regression] ICE in bootstrap while building libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99983 Rainer Orth changed: What|Removed |Added Target Milestone|10.4|9.4 Summary|[10 regression] ICE in |[9/10 regression] ICE in |bootstrap while building|bootstrap while building |libstdc++ |libstdc++ CC||ro at gcc dot gnu.org Target|powerpc64*-linux-gnu|powerpc64*-linux-gnu |x86_64-linux-gnu|x86_64-linux-gnu |aarch64-linux-gnu |aarch64-linux-gnu |arm-linux-gnueabihf |arm-linux-gnueabihf, ||*-*-solaris2.* Host|powerpc64*-linux-gnu|powerpc64*-linux-gnu |x86_64-linux-gnu|x86_64-linux-gnu |aarch64-linux-gnu |aarch64-linux-gnu |arm-linux-gnueabihf |arm-linux-gnueabihf, ||*-*-solaris2.* Build|powerpc64*-linux-gnu|powerpc64*-linux-gnu |x86_64-linux-gnu|x86_64-linux-gnu |aarch64-linux-gnu |aarch64-linux-gnu |arm-linux-gnueabihf |arm-linux-gnueabihf, ||*-*-solaris2.* --- Comment #6 from Rainer Orth --- I'm seeing exactly the same ICE on the gcc-9 branch for sparc-sun-solaris2.10 and i386-pc-solaris2.10. The same patch has been backported there, too.
[Bug c++/98529] [11 Regression] g++.dg/modules/stdio-1_a.H FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98529 Rainer Orth changed: What|Removed |Added Last reconfirmed|2021-04-09 00:00:00 |2021-4-14 Status|WAITING |NEW Target|i386-pc-solaris2.11 |*-*-solaris2.11 --- Comment #4 from Rainer Orth --- Yes, unfortunately. I see it not only on x86 now, but also on sparc: FAIL: g++.dg/modules/stdio-1_a.H -std=c++17 scan-lang-dump module "Depset:0 decl entity:[0-9]* function_decl:'::printf'" FAIL: g++.dg/modules/stdio-1_a.H -std=c++2a scan-lang-dump module "Depset:0 decl entity:[0-9]* function_decl:'::printf'" FAIL: g++.dg/modules/stdio-1_a.H -std=c++2b scan-lang-dump module "Depset:0 decl entity:[0-9]* function_decl:'::printf'"
[Bug target/98139] New: varasm.c fails to compile on AIX 7.2: -Werror=unused-variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98139 Bug ID: 98139 Summary: varasm.c fails to compile on AIX 7.2: -Werror=unused-variable Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: dje at gcc dot gnu.org Target Milestone: --- Host: powerpc-ibm-aix7.2.4.0 Target: powerpc-ibm-aix7.2.4.0 Build: powerpc-ibm-aix7.2.4.0 I've just tried a bootstrap of current master with a self-compiled GCC 8.4.0 on gcc119 in the cfarm. The build failed compiling varasm.c in stage2: /home/ro/gcc/src/gcc-master/gcc/varasm.c: In function 'void output_constant_pool _contents(rtx_constant_pool*)': /home/ro/gcc/src/gcc-master/gcc/varasm.c:4254:21: error: unused variable 'name' [-Werror=unused-variable] 4254 | const char *name = targetm.strip_name_encoding (XSTR (desc->sym, 0)); | I've used the attached patch to finish the build. It needs at last proper formatting and wrapping the args in parens. However, I wonder why there's no other report of this issue...
[Bug target/98139] varasm.c fails to compile on AIX 7.2: -Werror=unused-variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98139 --- Comment #1 from Rainer Orth --- Created attachment 49678 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49678&action=edit Hacky patch.
[Bug go/98170] New: Cannot build libgo on AIX: *.gox does not contain any Go export data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98170 Bug ID: 98170 Summary: Cannot build libgo on AIX: *.gox does not contain any Go export data Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: ro at gcc dot gnu.org CC: clement.chigot at atos dot net, cmang at google dot com Target Milestone: --- Host: powerpc-ibm-aix7.2.4.0 Target: powerpc-ibm-aix7.2.4.0 Build: powerpc-ibm-aix7.2.4.0 I've recently tried to build master on AIX 7.2 with --enable-languages=all. Among others, this failed building libgo, all following the same pattern: /home/ro/gcc/src/gcc-master/libgo/go/runtime/internal/math/math.go:7:28: error: ./runtime/internal/sys.gox exists but does not contain any Go export data 7 | import "runtime/internal/sys" |^ All those *.gox files were just 48 bytes long, even with binutils 2.35.1 objcopy. It turns out this is a known issue, explained in https://www.gitmemory.com/issue/golang/go/38043/603687042. There are several issues here: * The version of copycsect referenced there (based on binutils 2.25.1) doesn't compile with current binutils 2.35.1 any longer (bfd_get_section_size has lost its bfd * arg since). * Once this is fixed, the build mostly works (with the exception of the recently reported stab issue https://gcc.gnu.org/pipermail/gcc-patches/2020-December/560857.html) * Unless this functionality can be integrated into binutils, requiring a full binutils just for this seems pretty heavy-handed. I suspect that can way easier be done using libiberty's simple-object interfaces. * Whatever the case, until libgo builds out of the box on AIX, the issue should at the very least be documented (install.texi?) and/or the libgo build disabled so others don't waste time investigating known issues.
[Bug ada/98171] New: adaint.c doesn't compile on AIX 7.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98171
Bug ID: 98171
Summary: adaint.c doesn't compile on AIX 7.2
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
Assignee: unassigned at gcc dot gnu.org
Reporter: ro at gcc dot gnu.org
CC: charlet at gcc dot gnu.org, dje at gcc dot gnu.org
Target Milestone: ---
Host: powerpc-ibm-aix7.2.0.0
Target: powerpc-ibm-aix7.2.0.0
Build: powerpc-ibm-aix7.2.0.0
I recently tried building master on AIX 7.2 in the cfarm (gcc119) with
--enable-languages=all and a self-compiled gcc 8.4.0 as bootstrap compiler.
This
already failed in stage 1 compiling adaint.c:
/home/ro/gcc/src/gcc-master/gcc/ada/adaint.c: In function 'int
__gnat_copy_attri
bs(char*, char*, int)':
/home/ro/gcc/src/gcc-master/gcc/ada/adaint.c:3289:21: error: no match for
'opera
tor=' (operand types are 'timespec' and 'st_timespec_t' {aka 'st_timespec'})
tbuf[0] = fbuf.st_atim;
^~~
In file included from /usr/include/sys/resource.h:57,
from
/home/ro/gcc/8/lib/gcc/powerpc-ibm-aix7.2.0.0/8.4.0/includ
e-fixed/sys/wait.h:56,
from
/home/ro/gcc/8/lib/gcc/powerpc-ibm-aix7.2.0.0/8.4.0/includ
e-fixed/stdlib.h:386,
from /home/ro/gcc/8/include/c++/8.4.0/cstdlib:75,
from /home/ro/gcc/8/include/c++/8.4.0/stdlib.h:36,
from /home/ro/gcc/src/gcc-master/gcc/system.h:259,
from /home/ro/gcc/src/gcc-master/gcc/ada/adaint.c:144:
/usr/include/sys/time.h:197:8: note: candidate: 'timespec&
timespec::operator=(c
onst timespec&)'
struct timespec {
^~~~
/usr/include/sys/time.h:197:8: note: no known conversion for argument 1 from
'
st_timespec_t' {aka 'st_timespec'} to 'const timespec&'
/usr/include/sys/time.h:197:8: note: candidate: 'timespec&
timespec::operator=(t
imespec&&)'
/usr/include/sys/time.h:197:8: note: no known conversion for argument 1 from
'
st_timespec_t' {aka 'st_timespec'} to 'timespec&&'
and similarly for tbuf[1]/fbuf.st_mtim.
I managed to avoid this by assigning the members (tv_sec, tv_nsec)
individually. In addition, I enabled the largefile functions in adaint.h given
that gcc/auto-host.h defines _LARGE_FILES 1.
However, I believe that this maze of platform-specific #ifdefs just cries for
proper autoconf tests, as has already been remarked on gcc-patches recently
IIRC.
(I can't attach the actual patch since gcc119 has been unaccessible for more
than
a day now).
While those changes allowed the compilation to finish, gnat1 still doesn't link
due to PR ada/95549.
[Bug analyzer/98223] New: gcc.dg/analyzer/pr94851-1.c XPASSes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98223 Bug ID: 98223 Summary: gcc.dg/analyzer/pr94851-1.c XPASSes Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: ro at gcc dot gnu.org Target Milestone: --- Between 20201007 (dae673abd37d400408959497e50fe1f3fbef5533) and 20201008 (3e1123e52f8eca2650efa0bc81768792d328961f), gcc.dg/analyzer/pr94851-1.c began to XPASS: XPASS: gcc.dg/analyzer/pr94851-1.c bogus leak (test for bogus messages, line 43) I initially saw it on i386-pc-solaris2.11 and sparc-sun-solaris2.11 (both 32 and 64-bit), but according to gcc-testresults, it happens on many targets (everywhere?). Maybe just remove the xfail?
[Bug analyzer/98223] gcc.dg/analyzer/pr94851-1.c XPASSes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98223 Rainer Orth changed: What|Removed |Added Target Milestone|--- |11.0
[Bug testsuite/98224] New: [11 regression] gcc.dg/Walloca-2.c XPASSes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98224 Bug ID: 98224 Summary: [11 regression] gcc.dg/Walloca-2.c XPASSes Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: aldyh at gcc dot gnu.org Target Milestone: --- Between 20201020 (5d53ec27015b916640171e891870adf2c6fdfd4c) and 20201021 (c8f795cac6a1325bc6bcba3f47b7d04cb790400c), gcc.dg/Walloca-2.c began to XPASS: XPASS: gcc.dg/Walloca-2.c (test for bogus messages, line 16) I'm seeing it on 32-bit Solaris/sparc and x86, but there are many gcc-testresults reports. I suspect the xfail and the FIXME comment can just go?
[Bug testsuite/98224] [11 regression] gcc.dg/Walloca-2.c XPASSes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98224 Rainer Orth changed: What|Removed |Added Target Milestone|--- |11.0
[Bug testsuite/98225] New: gcc.misc-tests/outputs.exp ltrans_args tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98225 Bug ID: 98225 Summary: gcc.misc-tests/outputs.exp ltrans_args tests FAIL Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org Target Milestone: --- Between 20201020 (5d53ec27015b916640171e891870adf2c6fdfd4c) and 20201021 (c8f795cac6a1325bc6bcba3f47b7d04cb790400c), a couple of gcc.misc-tests/outputs.exp tests began to FAIL: FAIL: outputs lto st mult dumpdir named: dir/outputs-ltrans0.ltrans_args FAIL: outputs lto st mult empty dumpbase namedb: dir/outputs.ltrans0.ltrans_args FAIL: outputs lto st mult empty dumpbase unnamed: a.ltrans0.ltrans_args FAIL: outputs lto st mult namedb: dir/outputs.ltrans0.ltrans_args FAIL: outputs lto st mult unnamed: a.ltrans0.ltrans_args FAIL: outputs lto st sing dumpdir empty dumpbase named: dir/outputs-0.ltrans0.ltrans_args FAIL: outputs lto st sing dumpdir named: dir/outputs-ltrans0.ltrans_args FAIL: outputs lto st sing empty dumpbase namedb: dir/outputs.ltrans0.ltrans_args FAIL: outputs lto st sing empty dumpbase unnamed: a.ltrans0.ltrans_args FAIL: outputs lto st sing namedb: dir/outputs.ltrans0.ltrans I'm seeing this on both Solaris/sparc and x86, 32 and 64-bit, both with the native linker and with GNU ld (thus without and with the lto-plugin). There are also gcc-testresults reports for all sorts of targets: i686-pc-linux-gnu, aarch64-suse-linux-gnu, riscv64-suse-linux-gnu, x86_64-pc-linux-gnu, x86_64-unknown-freebsd11.4, x86_64-apple-darwin16. I've tried to have a look, but failed for all sorts of reasons: * When running the corresponding compilation with -v, -v isn't passed on to lto-wrapper. * Despite -save-temps, the lto-wrapper input objects are removed at the end, so I cannot manually rerun lto-wrapper to investigate. I guess this would be way easier for someone familiar with the code to investigate.
[Bug testsuite/98225] gcc.misc-tests/outputs.exp ltrans_args tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98225 Rainer Orth changed: What|Removed |Added Target Milestone|--- |11.0
[Bug analyzer/97090] gcc.dg/analyzer/malloc-vs-local-1b.c fails on arm and powerpc64*-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97090 Rainer Orth changed: What|Removed |Added Target Milestone|--- |11.0 CC||ro at gcc dot gnu.org --- Comment #10 from Rainer Orth --- I see the same flakyness of both gcc.dg/analyzer/unknown-fns-4.c (usually XPASSing XPASS: gcc.dg/analyzer/unknown-fns-4.c (test for warnings, line 13) but PASSing once in a while) and gcc.dg/analyzer/malloc-vs-local-1b.c (usually FAILing FAIL: gcc.dg/analyzer/malloc-vs-local-1b.c (test for bogus messages, line 170) but PASSing once in a while) on both sparc-sun-solaris2.11 and i386-pc-solaris2.11.
[Bug ipa/98237] New: gcc-dg-lto-modref-3-01.exe etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98237 Bug ID: 98237 Summary: gcc-dg-lto-modref-3-01.exe etc. FAIL Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: hubicka at gcc dot gnu.org, marxin at gcc dot gnu.org Target Milestone: --- Two new ipa-modref tests FAIL since they were installed: FAIL: gcc-dg-lto-modref-3-01.exe scan-wpa-ipa-dump modref "parm 1 flags: nodirectescape" FAIL: gcc-dg-lto-modref-4-01.exe scan-wpa-ipa-dump modref "parm 1 flags: nodirectescape" I'm seeing this on Solaris/sparc and x86, there are also gcc-testresults reports for hppa64-hp-hpux11.11. However, this is not an OS issue at all: on Solaris with GNU ld, the tests PASS, while they FAIL on x86_64-pc-linux-gnu with --disable-lto-plugin.
[Bug ipa/98237] gcc-dg-lto-modref-3-01.exe etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98237 Rainer Orth changed: What|Removed |Added Target Milestone|--- |11.0
[Bug tree-optimization/98238] New: gcc.dg/vect/vect-cost-model-1.c etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98238 Bug ID: 98238 Summary: gcc.dg/vect/vect-cost-model-1.c etc. FAIL Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: rsandifo at gcc dot gnu.org Target Milestone: --- Target: sparc*-*-solaris2.11, ia64-suse-linux-gnu, armeb-none-linux-gnueabihf, powerpc-apple-darwin9 Several of the the new vect-cost-model-?.c tests FAIL on several targets: FAIL: gcc.dg/vect/vect-cost-model-1.c -flto -ffat-lto-objects scan-tree-dump vect "LOOP VECTORIZED" FAIL: gcc.dg/vect/vect-cost-model-1.c scan-tree-dump vect "LOOP VECTORIZED" FAIL: gcc.dg/vect/vect-cost-model-3.c -flto -ffat-lto-objects scan-tree-dump vect "LOOP VECTORIZED" FAIL: gcc.dg/vect/vect-cost-model-3.c scan-tree-dump vect "LOOP VECTORIZED" FAIL: gcc.dg/vect/vect-cost-model-5.c -flto -ffat-lto-objects scan-tree-dump vect "LOOP VECTORIZED" FAIL: gcc.dg/vect/vect-cost-model-5.c scan-tree-dump vect "LOOP VECTORIZED" I'm seeing this on 32 and 64-bit Solaris/sparc, but gcc-testresults postings show several other affected targets.
[Bug tree-optimization/98238] gcc.dg/vect/vect-cost-model-1.c etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98238 Rainer Orth changed: What|Removed |Added Target Milestone|--- |11.0
[Bug tree-optimization/98238] gcc.dg/vect/vect-cost-model-1.c etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98238 --- Comment #1 from Rainer Orth --- Created attachment 49735 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49735&action=edit 32-bit sparc-sun-solaris2.11 vect-cost-model-1.c.166t.vect
[Bug tree-optimization/98239] New: gcc.dg/vect/bb-slp-69.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98239 Bug ID: 98239 Summary: gcc.dg/vect/bb-slp-69.c FAILs Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: rguenth at gcc dot gnu.org Target Milestone: --- Target: sparc-sun-solaris2.11 The new gcc.dg/vect/bb-slp-69.c tests FAILs on 32 and 64-bit sparc: FAIL: gcc.dg/vect/bb-slp-69.c -flto -ffat-lto-objects scan-tree-dump slp2 "transform load" FAIL: gcc.dg/vect/bb-slp-69.c scan-tree-dump slp2 "transform load" Dump attached.
[Bug tree-optimization/98239] gcc.dg/vect/bb-slp-69.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98239 Rainer Orth changed: What|Removed |Added Target Milestone|--- |11.0
[Bug tree-optimization/98239] gcc.dg/vect/bb-slp-69.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98239 --- Comment #1 from Rainer Orth --- Created attachment 49736 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49736&action=edit 32-bit sparc-sun-solaris2.11 bb-slp-69.c.178t.slp2
[Bug tree-optimization/98240] New: gcc.dg/vect/pr97678.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98240 Bug ID: 98240 Summary: gcc.dg/vect/pr97678.c FAILs Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: rguenth at gcc dot gnu.org Target Milestone: --- Target: sparc-sun-solaris2.11, armeb-none-linux-gnueabihf The new gcc.dg/vect/pr97678.c tests FAILs on 32 and 64-bit SPARC: FAIL: gcc.dg/vect/pr97678.c -flto -ffat-lto-objects scan-tree-dump vect "vectorizing stmts using SLP" FAIL: gcc.dg/vect/pr97678.c scan-tree-dump vect "vectorizing stmts using SLP" There are reports for armeb on gcc-testresults, too. Dump attached.
[Bug tree-optimization/98240] gcc.dg/vect/pr97678.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98240 Rainer Orth changed: What|Removed |Added Target Milestone|--- |11.0
[Bug tree-optimization/98240] gcc.dg/vect/pr97678.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98240 --- Comment #1 from Rainer Orth --- Created attachment 49737 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49737&action=edit 32-bit sparc-sun-solaris2.11 pr97678.c.166t.vect
[Bug tree-optimization/97494] [11 regression] several vector test case failures starting with r11-3966
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97494 Rainer Orth changed: What|Removed |Added Build|powerpc64*-linux-gnu| Target|powerpc64*-linux-gnu|powerpc64*-linux-gnu, ||sparc-sun-solaris2.11 CC||ro at gcc dot gnu.org Host|powerpc64*-linux-gnu| --- Comment #3 from Rainer Orth --- Also seen on 32 and 64-bit sparc.
[Bug ipa/98237] gcc-dg-lto-modref-3-01.exe etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98237 --- Comment #1 from Rainer Orth --- It's not just the scans that fail: FAIL: gcc.dg/lto/modref-3 c_lto_modref-3_0.o-c_lto_modref-3_1.o execute -O2 -flto-partition=max -fdump-ipa-modref -fno-ipa-sra -fno-ipa-cp -flto FAIL: gcc.dg/lto/modref-4 c_lto_modref-4_0.o-c_lto_modref-4_1.o execute -O2 -flto-partition=max -fdump-ipa-modref -fno-ipa-sra -flto
[Bug testsuite/98241] New: [11 regression] gcc.dg/pr78973.c XPASSes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98241 Bug ID: 98241 Summary: [11 regression] gcc.dg/pr78973.c XPASSes Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: msebor at gcc dot gnu.org Target Milestone: --- Between 20201020 (5d53ec27015b916640171e891870adf2c6fdfd4c) and 20201021 (c8f795cac6a1325bc6bcba3f47b7d04cb790400c), gcc.dg/pr78973.c began to XPASS: XPASS: gcc.dg/pr78973.c pr79073 (test for warnings, line 12) I'm seeing this on 32-bit Solaris/sparc and x86 as well as 32-bit Linux/x86. I suspect the xfail can just go?
[Bug testsuite/98241] [11 regression] gcc.dg/pr78973.c XPASSes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98241 Rainer Orth changed: What|Removed |Added Target Milestone|--- |11.0
[Bug tree-optimization/98242] New: gcc.dg/vect/bb-slp-subgroups-3.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98242 Bug ID: 98242 Summary: gcc.dg/vect/bb-slp-subgroups-3.c FAILs Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: rguenth at gcc dot gnu.org Target Milestone: --- Target: sparc-sun-solaris2.11 The new gcc.dg/vect/bb-slp-subgroups-3.c test FAILs on 32 and 64-bit SPARC: FAIL: gcc.dg/vect/bb-slp-subgroups-3.c -flto -ffat-lto-objects scan-tree-dump-times slp2 "optimized: basic block" 2 FAIL: gcc.dg/vect/bb-slp-subgroups-3.c scan-tree-dump-times slp2 "optimized: basic block" 2 Dump attached.
[Bug tree-optimization/98242] gcc.dg/vect/bb-slp-subgroups-3.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98242 Rainer Orth changed: What|Removed |Added Target Milestone|--- |11.0
[Bug tree-optimization/98242] gcc.dg/vect/bb-slp-subgroups-3.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98242 --- Comment #1 from Rainer Orth --- Created attachment 49738 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49738&action=edit 32-bit sparc-sun-solaris2.11 bb-slp-subgroups-3.c.178t.slp2
[Bug tree-optimization/98243] New: gcc.dg/gomp/simd-2.c etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98243 Bug ID: 98243 Summary: gcc.dg/gomp/simd-2.c etc. FAIL Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: jakub at gcc dot gnu.org Target Milestone: --- Target: sparc-sun-solaris2.11 The new gcc.dg/gomp/simd-2.c and gcc.dg/gomp/simd-3.c tests FAIL on 32 and 64-bit sparc from the beginning: FAIL: gcc.dg/gomp/simd-2.c scan-tree-dump-times vect "vectorized [1-9][0-9]* loops in function" 5 FAIL: gcc.dg/gomp/simd-3.c scan-tree-dump-times vect "vectorized [1-9][0-9]* loops in function" 5 Dump attached.
[Bug tree-optimization/98243] gcc.dg/gomp/simd-2.c etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98243 Rainer Orth changed: What|Removed |Added Target Milestone|--- |11.0
[Bug tree-optimization/98243] gcc.dg/gomp/simd-2.c etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98243 --- Comment #1 from Rainer Orth --- Created attachment 49739 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49739&action=edit 32-bit sparc-sun-solaris2.11 simd-2.c.166t.vect
[Bug tree-optimization/98244] New: gcc.dg/vect/vect-live-6.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98244 Bug ID: 98244 Summary: gcc.dg/vect/vect-live-6.c FAILs Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: rguenth at gcc dot gnu.org Target Milestone: --- Target: sparc-sun-solaris2.11 The gcc.dg/vect/vect-live-6.c test FAILs on sparc from the beginning: +FAIL: gcc.dg/vect/vect-live-6.c -flto -ffat-lto-objects scan-tree-dump vect "vectorized 1 loops" +FAIL: gcc.dg/vect/vect-live-6.c scan-tree-dump vect "vectorized 1 loops" Dump attached.
[Bug tree-optimization/98244] gcc.dg/vect/vect-live-6.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98244 Rainer Orth changed: What|Removed |Added Target Milestone|--- |11.0
[Bug tree-optimization/98244] gcc.dg/vect/vect-live-6.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98244 --- Comment #1 from Rainer Orth --- Created attachment 49740 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49740&action=edit 32-bit sparc-sun-solaris2.11 vect-live-6.c.166t.vect
[Bug tree-optimization/98245] New: gcc.dg/vect/bb-slp-46.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98245 Bug ID: 98245 Summary: gcc.dg/vect/bb-slp-46.c FAILs Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: rguenth at gcc dot gnu.org Target Milestone: --- Target: sparc-sun-solaris2.11 The gcc.dg/vect/bb-slp-46.c test FAIL on 32 and 64-bit sparc since the beginning: FAIL: gcc.dg/vect/bb-slp-46.c -flto -ffat-lto-objects scan-tree-dump-times optimized " + " 3 FAIL: gcc.dg/vect/bb-slp-46.c scan-tree-dump-times optimized " + " 3 Dump attached.
[Bug tree-optimization/98245] gcc.dg/vect/bb-slp-46.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98245 Rainer Orth changed: What|Removed |Added Target Milestone|--- |11.0
[Bug tree-optimization/98245] gcc.dg/vect/bb-slp-46.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98245 --- Comment #1 from Rainer Orth --- Created attachment 49741 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49741&action=edit 32-bit sparc-sun-solaris2.11 bb-slp-46.c.244t.optimized
[Bug c++/98315] New: [11 regression] libcody breaks Solaris bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98315
Bug ID: 98315
Summary: [11 regression] libcody breaks Solaris bootstrap
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ro at gcc dot gnu.org
CC: nathan at gcc dot gnu.org
Target Milestone: ---
Target: *-*-solaris2.11
Since the introduction of libcody, Solaris 11 bootstrap is broken:
* On Solaris 11.4:
In file included from /usr/include/sys/socket.h:25,
from /vol/gcc/src/hg/master/local/gcc/../libcody/cody.hh:29,
from /vol/gcc/src/hg/master/local/gcc/cp/mapper-client.h:26,
from /vol/gcc/src/hg/master/local/gcc/cp/mapper-client.cc:26:
/usr/include/sys/uio.h:192:3: error: attempt to use poisoned "bzero"
bzero(&(xuiop)->xu_hint, sizeof ((xuiop)->xu_hint)); \
^
where has
/*
* Clear the hints portion of an xuio_t, leaving the initial uio_t and the
* xu_ext union untouched.
*
* Note that this does not touch xu_type. Since zero copy is recognized as
* UIO_XUIO with xu_type of UIOTYPE_ZEROCOPY, if extending a uio_t not setup
* for zero copy into a full xuio_t then chances are that xu_type should be
* initialized too as if the xuio_t had been bzero'd - ie to UIOTYPE_ASYNCIO.
*/
#define XUIO_BZERO_HINTS(xuiop) do { \
bzero(&(xuiop)->xu_hint, sizeof ((xuiop)->xu_hint)); \
_NOTE(CONSTCOND) } while (0)
This macros isn't used anywhere, so I wonder why #pragma poison would be
offended.
* On Solaris 11.3:
In file included from /usr/include/sys/stream.h:16,
from /usr/include/netinet/in.h:66,
from /usr/include/sys/socket.h:32,
from /vol/gcc/src/hg/master/local/gcc/../libcody/cody.hh:29,
from /vol/gcc/src/hg/master/local/gcc/cp/mapper-client.h:26,
from /vol/gcc/src/hg/master/local/gcc/cp/mapper-client.cc:26:
/usr/include/sys/strmdep.h:25:26: error: attempt to use poisoned "bcopy"
#define strbcpy(s, d, c) bcopy(s, d, c)
^
with the following in :
/*
* Copy data from one data buffer to another.
* The addresses must be word aligned - if not, use bcopy!
*/
#define strbcpy(s, d, c)bcopy(s, d, c)
I've hacked around both for no by removing bcopy and bzero from #pragma GCC
poison
in gcc/system.h.
[Bug c++/98315] [11 regression] libcody breaks Solaris bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98315 Rainer Orth changed: What|Removed |Added Target Milestone|--- |11.0
[Bug c++/98316] New: [11 regression] cc1plus doesn't link on Solaris 11.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98316 Bug ID: 98316 Summary: [11 regression] cc1plus doesn't link on Solaris 11.3 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: nathan at gcc dot gnu.org Target Milestone: --- Target: *-*-solaris2.11 Even with PR c++/98315 hacked around, Solaris 11.3 (only) bootstrap is still broken: Undefined first referenced symbol in file __xnet_connect ../libcody/libcody.a(netclient.o) __xnet_socket ../libcody/libcody.a(netclient.o) __xnet_getaddrinfo ../libcody/libcody.a(netclient.o) freeaddrinfo../libcody/libcody.a(netclient.o) gai_strerror../libcody/libcody.a(netclient.o) ld: fatal: symbol referencing errors collect2: error: ld returned 1 exit status make[3]: *** [/vol/gcc/src/hg/master/local/gcc/cp/Make-lang.in:136: cc1plus] Error 1 Before Solaris 11.4 folded libsocket and libnsl into libc, one needed to link with both for the socket functions. The same issue exists with the other use of $(LIBCODY) in c++tools/Makefile.in. We already have 4 instances of the libsocket/libnsl check in the tree: gotools/configure.ac libcc1/configure.ac libgo/configure.ac libphobos/m4/druntime/libraries.m4 Instead of adding yet two others, we could make use of the autoconf-archive's m4/ax_lib_socket_nsl.m4 (AX_LIB_SOCKET_NSL).
[Bug c++/98316] [11 regression] cc1plus doesn't link on Solaris 11.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98316 Rainer Orth changed: What|Removed |Added Target Milestone|--- |11.0
[Bug c++/98316] [11 regression] cc1plus doesn't link on Solaris 11.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98316 --- Comment #2 from Rainer Orth --- Created attachment 49778 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49778&action=edit Initial patch The attach has only been lightly tested so far: it allowed cc1plus to link on Solaris 11.3, bootstrap still running.
[Bug c++/98316] [11 regression] cc1plus doesn't link on Solaris 11.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98316 Rainer Orth changed: What|Removed |Added Assignee|nathan at gcc dot gnu.org |ro at gcc dot gnu.org --- Comment #4 from Rainer Orth --- That's easiest, I guess. With one minor addition (gcc/objcp/Make-lang.in needs the same treatment), the Solaris 11.3 build completed successfully; make check still running. I'll try the patch on Solaris 11.4 and Linux/x86_64 tonight, then post it.
[Bug c++/98316] [11 regression] cc1plus doesn't link on Solaris 11.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98316 Rainer Orth changed: What|Removed |Added URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2020-Decembe ||r/562185.html --- Comment #5 from Rainer Orth --- Final patch posted.
[Bug libstdc++/98384] new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98384 Rainer Orth changed: What|Removed |Added CC||ro at gcc dot gnu.org Build|powerpc64-linux-gnu | Host|powerpc64-linux-gnu | Target|powerpc64-linux-gnu |powerpc64-linux-gnu, ||*-*-solaris2.11 --- Comment #1 from Rainer Orth --- The test FAILs in the same way on Solaris 11, both sparc and x86, 32 and 64-bit.
[Bug c++/98316] [11 regression] cc1plus doesn't link on Solaris 11.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98316 Rainer Orth changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Rainer Orth --- Fixed for GCC 11.
[Bug testsuite/98225] gcc.misc-tests/outputs.exp ltrans_args tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98225 Rainer Orth changed: What|Removed |Added CC||burnus at gcc dot gnu.org, ||edlinger at gcc dot gnu.org --- Comment #1 from Rainer Orth --- After commit e9f8a554efe497dd46b8953e580d65e5c023e50c Author: Bernd Edlinger Date: Sun Dec 13 08:24:57 2020 +0100 Fix -save-temp leaking lto files in /tmp I see a massive increase of FAILs on i386-pc-solaris2.11 and sparc-sun-solaris2.11, although similar reports can be found on gcc-testresults for aarch64-suse-linux-gnu, i686-pc-linux-gnu, x86_64-pc-linux-gnu: +FAIL: outputs exe savetmp named2: outputs.ld1_args +FAIL: outputs exe savetmp named2: outputs.ld1_args +FAIL: outputs exe savetmp named2: outputs.ld1_args +FAIL: outputs exe savetmp namedb: outputs.ld1_args +FAIL: outputs lto st mult dumpdir empty dumpbase named: dir/outputs-1.ltrans0.ltrans.args.0 FAIL: outputs lto st mult dumpdir empty dumpbase named: dir/outputs-1.ltrans0.ltrans_args +FAIL: outputs lto st mult dumpdir named: dir/outputs-ltrans0.ltrans.args.0 FAIL: outputs lto st mult dumpdir named: dir/outputs-ltrans0.ltrans_args +FAIL: outputs lto st mult empty dumpbase namedb: dir/outputs.ltrans0.ltrans.args.0 +FAIL: outputs lto st mult empty dumpbase unnamed: a.ltrans0.ltrans.args.0 +FAIL: outputs lto st mult namedb: dir/outputs.ltrans0.ltrans.args.0 +FAIL: outputs lto st mult unnamed: a.ltrans0.ltrans.args.0 +FAIL: outputs lto st sing dumpdir empty dumpbase named: dir/outputs-0.ltrans0.ltrans.args.0 +FAIL: outputs lto st sing dumpdir named: dir/outputs-ltrans0.ltrans.args.0 +FAIL: outputs lto st sing empty dumpbase namedb: dir/outputs.ltrans0.ltrans.args.0 +FAIL: outputs lto st sing empty dumpbase unnamed: a.ltrans0.ltrans.args.0 +FAIL: outputs lto st sing namedb: dir/outputs.ltrans0.ltrans.args.0 +FAIL: outputs lto st sing unnamed: a.ltrans0.ltrans.args.0
[Bug c++/98528] New: g++.dg/modules/hello-1 FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98528 Bug ID: 98528 Summary: g++.dg/modules/hello-1 FAILs Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: nathan at gcc dot gnu.org Target Milestone: --- Target: i386-pc-solaris2.11, sparc-sun-solaris2.11, i586-unknown-freebsd11.4, x86_64-unknown-freebsd11.4 The new g++.dg/modules/hello-1 test FAILs on Solaris and FreeBSD: +UNRESOLVED: g++.dg/modules/hello-1 execute +UNRESOLVED: g++.dg/modules/hello-1 execute +FAIL: g++.dg/modules/hello-1 link +FAIL: g++.dg/modules/hello-1 link Undefined first referenced symbol in file _ZL16__gthread_active /var/tmp//ccAd8Hnb.o ld: fatal: symbol referencing errors This should be extern "C" __gthread_active instead, there's no mangled version in libgcc. Besides, the UNRESOLVED and FAIL lines are identical for both the -std=c++17 and c++2a. However, different tests are supposed to have different test names.
[Bug c++/98528] g++.dg/modules/hello-1 FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98528 Rainer Orth changed: What|Removed |Added Target Milestone|--- |11.0
[Bug c++/98529] New: g++.dg/modules/stdio-1_a.H FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98529 Bug ID: 98529 Summary: g++.dg/modules/stdio-1_a.H FAILs Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: nathan at gcc dot gnu.org Target Milestone: --- Target: i386-pc-solaris2.11 Created attachment 49885 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49885&action=edit i386-pc-solaris2.11 32-bit stdio-1_a.H.002l.module The new g++.dg/modules/stdio-1_a.H test FAILs on Solaris/x86 (only): +FAIL: g++.dg/modules/stdio-1_a.H -std=c++17 scan-lang-dump module "Depset:0 decl entity:[0-9]* function_decl:'::printf'" +FAIL: g++.dg/modules/stdio-1_a.H -std=c++2a scan-lang-dump module "Depset:0 decl entity:[0-9]* function_decl:'::printf'" I'm attaching the .module file.
[Bug c++/98529] g++.dg/modules/stdio-1_a.H FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98529 Rainer Orth changed: What|Removed |Added Target Milestone|--- |11.0
[Bug c++/98530] New: g++.dg/modules/string-1_b.C etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98530 Bug ID: 98530 Summary: g++.dg/modules/string-1_b.C etc. FAIL Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: nathan at gcc dot gnu.org Target Milestone: --- Target: i386-pc-solaris2.11 Created attachment 49886 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49886&action=edit i386-pc-solaris2.11 32-bit string-1_a.H.gcm/string-1_b.ii Several of the new module tests FAIL on Solaris/x86, e.g. +FAIL: g++.dg/modules/string-1_b.C -std=c++17 (test for excess errors) +FAIL: g++.dg/modules/string-1_b.C -std=c++2a (test for excess errors) Excess errors: /usr/include/sys/regset.h:359:19: error: conflicting global module declaration 'fpufpchip_state fpufpchip_state' /usr/include/sys/regset.h:363:19: error: conflicting global module declaration 'fpufp_emul_space fpufp_emul_space' /usr/include/sys/regset.h:359:19: error: conflicting global module declaration 'fpufpchip_state fpufpchip_state' /usr/include/sys/regset.h:359:19: note: existing declaration 'fpufpchip_state fpufpchip_state' /usr/include/sys/regset.h:363:19: error: conflicting global module declaration 'fpufp_emul_space fpufp_emul_space' /usr/include/sys/regset.h:363:19: note: existing declaration 'fpufp_emul_space fpufp_emul_space' This can be reproduced with $ cc1plus -fpreprocessed string-1_b.ii -quiet -std=c++17 -fmodules-ts -fno-module-lazy -o string-1_b.s and the attached .ii/.gcm files.
[Bug c++/98530] g++.dg/modules/string-1_b.C etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98530 Rainer Orth changed: What|Removed |Added Target Milestone|--- |11.0
[Bug c++/98531] New: g++.dg/modules/xtreme-header-2_a.H etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98531 Bug ID: 98531 Summary: g++.dg/modules/xtreme-header-2_a.H etc. FAIL Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: nathan at gcc dot gnu.org Target Milestone: --- Target: i386-pc-solaris2.11, sparc-sun-solaris2.11, i586-unknown-freebsd11.4, x86_64-unknown-freebsd11.4 Created attachment 49887 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49887&action=edit i386-pc-solaris2.11 32-bit xtreme-header-2_a.ii Several of the new modules tests FAIL on Solaris/x86, Solaris/SPARC, and FreeBSD, e.g. +FAIL: g++.dg/modules/xtreme-header-2_a.H -std=c++2a (internal compiler error) +FAIL: g++.dg/modules/xtreme-header-2_a.H -std=c++2a (test for excess errors) Excess errors: /vol/gcc/src/hg/master/local/gcc/testsuite/g++.dg/modules/xtreme-header-2_a.H: internal compiler error: in tree_node, at cp/module.cc:9125 0x8cdfc7f trees_out::tree_node(tree_node*) /vol/gcc/src/hg/master/local/gcc/cp/module.cc:9125 0x8cc9fbe trees_out::core_vals(tree_node*) /vol/gcc/src/hg/master/local/gcc/cp/module.cc:6007 0x8ccd34f trees_out::tree_node_vals(tree_node*) /vol/gcc/src/hg/master/local/gcc/cp/module.cc:7141 0x8ccd34f trees_out::tree_value(tree_node*) /vol/gcc/src/hg/master/local/gcc/cp/module.cc:8956 0x8cc93ce trees_out::tree_node(tree_node*) /vol/gcc/src/hg/master/local/gcc/cp/module.cc:9154 0x8cc9fbe trees_out::core_vals(tree_node*) /vol/gcc/src/hg/master/local/gcc/cp/module.cc:6007 0x8ccd34f trees_out::tree_node_vals(tree_node*) /vol/gcc/src/hg/master/local/gcc/cp/module.cc:7141 0x8ccd34f trees_out::tree_value(tree_node*) /vol/gcc/src/hg/master/local/gcc/cp/module.cc:8956 0x8cc93ce trees_out::tree_node(tree_node*) /vol/gcc/src/hg/master/local/gcc/cp/module.cc:9154 0x8cc9fbe trees_out::core_vals(tree_node*) /vol/gcc/src/hg/master/local/gcc/cp/module.cc:6007 0x8ccd34f trees_out::tree_node_vals(tree_node*) /vol/gcc/src/hg/master/local/gcc/cp/module.cc:7141 0x8ccd34f trees_out::tree_value(tree_node*) /vol/gcc/src/hg/master/local/gcc/cp/module.cc:8956 0x8cc93ce trees_out::tree_node(tree_node*) /vol/gcc/src/hg/master/local/gcc/cp/module.cc:9154 0x8cc9fbe trees_out::core_vals(tree_node*) /vol/gcc/src/hg/master/local/gcc/cp/module.cc:6007 0x8ccd34f trees_out::tree_node_vals(tree_node*) /vol/gcc/src/hg/master/local/gcc/cp/module.cc:7141 0x8ccd34f trees_out::tree_value(tree_node*) /vol/gcc/src/hg/master/local/gcc/cp/module.cc:8956 0x8cc93ce trees_out::tree_node(tree_node*) /vol/gcc/src/hg/master/local/gcc/cp/module.cc:9154 0x8cc9fbe trees_out::core_vals(tree_node*) /vol/gcc/src/hg/master/local/gcc/cp/module.cc:6007 0x8ccd34f trees_out::tree_node_vals(tree_node*) /vol/gcc/src/hg/master/local/gcc/cp/module.cc:7141 0x8ccd34f trees_out::tree_value(tree_node*) /vol/gcc/src/hg/master/local/gcc/cp/module.cc:8956 +FAIL: g++.dg/modules/xtreme-header-2_a.H module-cmi (gcm.cache/vol/gcc/src/hg/master/local/gcc/testsuite/g++.dg/modules/xtreme-header-2_a.H.gcm) must not use absolute filename here +FAIL: g++.dg/modules/xtreme-header-2_b.C -std=c++2a (test for excess errors) Excess errors: /vol/gcc/src/hg/master/local/gcc/testsuite/g++.dg/modules/xtreme-header-2_a.H: error: failed to read compiled module: No such file or directory /vol/gcc/src/hg/master/local/gcc/testsuite/g++.dg/modules/xtreme-header-2_a.H: fatal error: returning to the gate for a mechanical issue compilation terminated. +FAIL: g++.dg/modules/xtreme-header-2_c.C -std=c++2a (test for excess errors) The same failure happens for +FAIL: g++.dg/modules/xtreme-header-5_a.H -std=c++2a (internal compiler error) +FAIL: g++.dg/modules/xtreme-header-5_a.H -std=c++2a (test for excess errors) +FAIL: g++.dg/modules/xtreme-header-5_a.H module-cmi (gcm.cache/vol/gcc/src/hg/master/local/gcc/testsuite/g++.dg/modules/xtreme-header-5_a.H.gcm) +FAIL: g++.dg/modules/xtreme-header-5_b.C -std=c++2a (test for excess errors) +FAIL: g++.dg/modules/xtreme-header-5_c.C -std=c++2a (test for excess errors) +FAIL: g++.dg/modules/xtreme-header-6_a.H -std=c++2a (internal compiler error) +FAIL: g++.dg/modules/xtreme-header-6_a.H -std=c++2a (test for excess errors) +FAIL: g++.dg/modules/xtreme-header-6_a.H module-cmi (gcm.cache/vol/gcc/src/hg/master/local/gcc/testsuite/g++.dg/modules/xtreme-header-6_a.H.gcm) +FAIL: g++.dg/modules/xtreme-header-6_b.C -std=c++2a (test for excess errors) +FAIL: g++.dg/modules/xtreme-header-6_c.C -std=c++2a (test for excess errors) +FAIL: g++.dg/modules/xtreme-header_a.H -std=c++2a (internal compiler error) +FAIL: g++.dg/modules/xtreme-header_a.H -std=c++2a (test for excess errors) +FAIL: g++.dg
[Bug c++/98531] g++.dg/modules/xtreme-header-2_a.H etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98531 Rainer Orth changed: What|Removed |Added Target Milestone|--- |11.0
[Bug c++/98528] g++.dg/modules/hello-1 FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98528 --- Comment #2 from Rainer Orth --- Created attachment 49888 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49888&action=edit i386-pc-solaris2.11 32-bit hello-1_[ab].ii
[Bug c++/98528] g++.dg/modules/hello-1 FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98528 --- Comment #3 from Rainer Orth --- (In reply to Nathan Sidwell from comment #1) > Could you provide the -save-temps .ii files please? I suspect something > different in the solaris system headers. Sure, attached. > it seems to be losing the c++17/2a distinguisher in the test name ... I believe I've seen the same on other failing modules tests on gcc-testresults as well.
[Bug c++/98529] g++.dg/modules/stdio-1_a.H FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98529 --- Comment #2 from Rainer Orth --- Created attachment 49889 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49889&action=edit i386-pc-solaris2.11 32-bit stdio-1_a.ii Sure: I just wasn't sure when which was needed. However, without the actual input, it's hard to do much ;-)
[Bug d/98584] New: Many D tests FAIL with SIGBUS in read_encoded_value_with_base
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98584 Bug ID: 98584 Summary: Many D tests FAIL with SIGBUS in read_encoded_value_with_base Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: d Assignee: ibuclaw at gdcproject dot org Reporter: ro at gcc dot gnu.org Target Milestone: --- Target: sparc-sun-solaris2.11 Inspired by the recent patch to enable libphobos with Solaris/x86 as, I tried the same on Solaris/SPARC (where libphobos is not yet enabled by default even with gas, but I've some success doing so anyway). However, when using as instead of gas, many tests FAIL with SIGBUS, e.g. FAIL: gdc.dg/torture/gdc17.d -O0 execution test Thread 2 received signal SIGBUS, Bus error. [Switching to Thread 1 (LWP 1)] gcc.unwind.pe.read_encoded_value_with_base(ubyte, uint, const(ubyte)**) (encoding=, base=0, p=0xffbfdb8c) at /vol/gcc/src/hg/master/local/libphobos/libdruntime/gcc/unwind/pe.d:200 200 result = cast(_Unwind_Internal_Ptr) *cast(int*)q; (gdb) where #0 gcc.unwind.pe.read_encoded_value_with_base(ubyte, uint, const(ubyte)**) (encoding=, base=0, p=0xffbfdb8c) at /vol/gcc/src/hg/master/local/libphobos/libdruntime/gcc/unwind/pe.d:200 #1 0x0005e258 in gcc.deh.scanLSDA(const(ubyte)*, ulong, int, gcc.unwind.generic._Unwind_Exception*, gcc.unwind.generic._Unwind_Context*, uint, out uint, out int) (lsda=0xcbd2c "\377", exceptionClass=, actions=1, unwindHeader=0xff040220, context=0xffbfdecc, cfa=4290766520, landingPad=@0xffbfdc0c: 0, handler=@0xffbfdc14: 0) at /vol/gcc/src/hg/master/local/libphobos/libdruntime/gcc/deh.d:634 #2 0x0005e508 in gcc.deh.__gdc_personality(int, ulong, gcc.unwind.generic._Unwind_Exception*, gcc.unwind.generic._Unwind_Context*) (actions=1, exceptionClass=5138137972268335104, unwindHeader=0xff040220, context=0xffbfdecc) at /vol/gcc/src/hg/master/local/libphobos/libdruntime/gcc/deh.d:917 #3 0xff07c4f8 in _Unwind_RaiseException (exc=0xff040220) at /builds2/ulhg/nightly_87/components/gcc10/gcc-10.2.0/libgcc/unwind.inc:118 #4 0x0005def4 in _d_throw (object=0xfef32000) at /vol/gcc/src/hg/master/local/libphobos/libdruntime/gcc/deh.d:509 #5 0x000656d0 in onAssertError (file=..., line=12) at /vol/gcc/src/hg/master/local/libphobos/libdruntime/core/exception.d:441 #6 0x00065c18 in _d_assert (file=..., line=12) at /vol/gcc/src/hg/master/local/libphobos/libdruntime/core/exception.d:641 #7 0x0005d1ac in gdc17.contractTest(immutable(char)[]) (path=...) at /vol/gcc/src/hg/master/local/gcc/testsuite/gdc.dg/torture/gdc17.d:12 #8 0x0005d2cc in gdc17.ModuleSaver.save(immutable(char)[]).__require() (this=0xffbfe728) at /vol/gcc/src/hg/master/local/gcc/testsuite/gdc.dg/torture/gdc17.d:21 #9 0x0005d330 in gdc17.ModuleWriter.save(immutable(char)[]) (this=0xfef31000, str=...) at /vol/gcc/src/hg/master/local/gcc/testsuite/gdc.dg/torture/gdc17.d:27 #10 0x0005d044 in D main () at /vol/gcc/src/hg/master/local/gcc/testsuite/gdc.dg/torture/gdc17.d:36 (gdb) p p $1 = (const ubyte **) 0xffbfdc04 (gdb) p/x p $2 = 0xffbfdc04 (gdb) p/x *p $3 = 0xcbd31 SPARC being a strict-alignment target, one cannot dereference an odd point as int *. #1 0x0005e258 in gcc.deh.scanLSDA(const(ubyte)*, ulong, int, gcc.unwind.generic._Unwind_Exception*, gcc.unwind.generic._Unwind_Context*, uint, out uint, out int) (lsda=0xcbd2c "\377", exceptionClass=, actions=1, unwindHeader=0xff040220, context=0xffbfdf44, cfa=4290766640, landingPad=@0xffbfdc84: 0, handler=@0xffbfdc8c: 0) at /vol/gcc/src/hg/master/local/libphobos/libdruntime/gcc/deh.d:634 634 auto CSStart = read_encoded_value(null, CSEncoding, &p); (gdb) p p $4 = (const ubyte *) 0xcbd31 "" Replacing gdc17.o from the gas build lets the test PASS. I have not yet determine where/how exactly the objects differ to cause this failure. However, comparing pe.d (read_encoded_value_with_base) with libgcc's unwind-pe.h, I find that the latter accounts for strict-alignment targets by using an union unaligned for the access instead of just casting.
[Bug testsuite/98225] gcc.misc-tests/outputs.exp ltrans_args tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98225 Rainer Orth changed: What|Removed |Added URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2021-January ||/562967.html --- Comment #16 from Rainer Orth --- (In reply to David Edelsohn from comment #15) > I'm seeing a number of new testsuite failures on AIX after the > collect2/testsuite change. Do you want a separate PR or use this as well? Given that we already identified two different issues here (parallel make check and linker support for response files), I suggest we keep everything together for now. > They are: > > FAIL: outputs exe savetmp named2: extra > FAIL: outputs exe savetmp named2: extra > FAIL: outputs exe savetmp named2: extra > FAIL: outputs exe savetmp named2: outputs.ld1_args > FAIL: outputs exe savetmp named2: outputs.ld1_args > FAIL: outputs exe savetmp named2: outputs.ld1_args > FAIL: outputs exe savetmp namedb: extra > FAIL: outputs exe savetmp namedb: outputs.ld1_args > > I notice that Rainer mentions some ld1_args failures for these same > testcases in Comment #6. Right. I assume you're using the the native AIX linker and it doesn't support response files? In that case, the *.ld1_args failures are the same issue I'm seeing with Solaris ld (which is in the same boat in this respect).
[Bug testsuite/98676] New: gcc.target/i386/pr95021-1.c etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98676 Bug ID: 98676 Summary: gcc.target/i386/pr95021-1.c etc. FAIL Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: hjl.tools at gmail dot com Target Milestone: --- Target: i386-pc-solaris2.11, x86_64-pc-solaris2.11, i586-unknown-freebsd11.4, i686-apple-darwin8 As originally reported in PR middle-end/95021, Comment 11, two of the new testcases added with the fix for that PR FAIL: +FAIL: gcc.target/i386/pr95021-1.c scan-assembler movq[ \\t]%xmm[0-9]+, (%esp) +FAIL: gcc.target/i386/pr95021-3.c scan-assembler movq[ \\t]+[^\\n]*, %xmm I originally saw this on 32-bit Solaris/x86, but there are reports for other targets as well.
[Bug testsuite/98676] gcc.target/i386/pr95021-1.c etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98676 Rainer Orth changed: What|Removed |Added Target Milestone|--- |11.0
[Bug libstdc++/98678] New: 30_threads/future/members/poll.cc execution test FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98678 Bug ID: 98678 Summary: 30_threads/future/members/poll.cc execution test FAILs Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org Target Milestone: --- Target: i386-pc-solaris2.11, x86_64-pc-solaris2.11, arm-none-linux-gnueabi, hppa-unknown-linux-gnu, x86_64-pc-linux-gnu The 30_threads/future/members/poll.cc reliably FAILs on 32 and 64-bit Solaris/x86: /vol/gcc/src/hg/master/local/libstdc++-v3/testsuite/30_threads/future/members/poll.cc:95: int main(): Assertion 'wait_until_sys_min < (ready * 100)' failed. wait_for(0s): 11892ns for 200 calls, avg 59.46ns per call wait_until(system_clock minimum): 1304458ns for 200 calls, avg 6522.29ns per call wait_until(steady_clock minimum): 1403221ns for 200 calls, avg 7016.1ns per call wait_until(system_clock epoch): 3343806ns for 200 calls, avg 16719ns per call wait_until(steady_clock epoch: 2959581ns for 200 calls, avg 14797.9ns per call wait_for when ready: 10969ns for 200 calls, avg 54.845ns per call While I don't see the failure on Solaris/SPARC, there are reports for a couple of other targets on gcc-testresults. However, the Linux/x86_64 ones seem to only affect the gcc-10 branch.
[Bug libstdc++/98678] 30_threads/future/members/poll.cc execution test FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98678 Rainer Orth changed: What|Removed |Added Target Milestone|--- |11.0
[Bug libstdc++/98680] New: Several 30_threads tests are flaky
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98680 Bug ID: 98680 Summary: Several 30_threads tests are flaky Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org Target Milestone: --- Target: i386-pc-solaris2.11, sparc-sun-solaris2.11, i686-apple-darwin*, x86_64-apple-darwin*, hppa2.0w-hp-hpux11.11 Several 30_threads tests are flaky on Solaris, more often on Solaris/x86 but also on SPARC: For the last couple of days, the counts are like this: 11 30_threads/barrier/arrive_and_wait.cc execution test 11 30_threads/barrier/arrive_and_wait.cc execution test program timed out. 1 30_threads/barrier/arrive.cc execution test 1 30_threads/barrier/arrive.cc execution test program timed out. 20 30_threads/barrier/completion.cc execution test 20 30_threads/barrier/completion.cc execution test program timed out. 14 30_threads/latch/3.cc execution test 14 30_threads/latch/3.cc execution test program timed out. 1 30_threads/semaphore/try_acquire_for.cc execution test 1 30_threads/semaphore/try_acquire_for.cc execution test program timed out. 5 30_threads/semaphore/try_acquire_until.cc execution test 5 30_threads/semaphore/try_acquire_until.cc execution test program timed out. At least Darwin and HP-UX are likewise affected; I haven't looked closer for possible others. As an example, I ran arrive_and_wait.exe for ca. 100 times with the following timing: 93 real 0.01 1 real 0.73 1 real 0.95 1 real 1.03 1 real1:13.00
[Bug libstdc++/98680] Several 30_threads tests are flaky
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98680 Rainer Orth changed: What|Removed |Added Target Milestone|--- |11.0
[Bug debug/98728] New: [11 regression] Several debug tests FAIL with DWARF-5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98728 Bug ID: 98728 Summary: [11 regression] Several debug tests FAIL with DWARF-5 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: mark at gcc dot gnu.org Target Milestone: --- Target: i386-pc-solaris2.11, sparc-sun-solaris2.11, x86_64-pc-linux-gnu With the switch to DWARF-5, two debug tests have started to FAIL: +FAIL: g++.dg/debug/dwarf2/constexpr-var-1.C scan-assembler-times DW_AT_const_expr 2 32 and 64-bit Solaris/SPARC and x86, Linux/x86_64 +FAIL: gcc.dg/debug/dwarf2/dwarf-float.c scan-assembler 0x10.*DW_AT_byte_size 32-bit Solaris/x86 and Linux/x86_64 Besides, there were many changes to guality tests on Linux/x86_64, both tests previously XPASSing now XFAIL again, as well as several new FAILs.
[Bug debug/98728] [11 regression] Several debug tests FAIL with DWARF-5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98728 Rainer Orth changed: What|Removed |Added Target Milestone|--- |11.0
[Bug libgomp/98738] task-detach-6.f90 hangs intermittently
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98738 Rainer Orth changed: What|Removed |Added CC||ro at gcc dot gnu.org Target|s390x, x86_64-*-* |s390x, x86_64-*-*, ||*-*-solaris* Target Milestone|--- |11.0 --- Comment #4 from Rainer Orth --- I'm seeing the same on Solaris (both sparc and x86) for both libgomp.c-c++-common/task-detach-6.c and libgomp.fortran/task-detach-6.f90. When running the C test in a loop, about 1 out of 10 times it hangs. On Linux/x86_64, its way rarer (1 out of 1000 or less), however when configuring with --disable-linux-futex the frequency is similar to what I see on Solaris.
[Bug fortran/98763] New: gfortran.dg/gomp/task-detach-1.f90 FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98763 Bug ID: 98763 Summary: gfortran.dg/gomp/task-detach-1.f90 FAILs Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: kcy at codesourcery dot com Target Milestone: --- The new gfortran.dg/gomp/task-detach-1.f90 test FAILs on large number of targets: +FAIL: gfortran.dg/gomp/task-detach-1.f90 -O (test for errors, line 21) +FAIL: gfortran.dg/gomp/task-detach-1.f90 -O (test for errors, line 22) I'm seeing this on i386-pc-solaris2.11 and sparc-sun-solaris2.11 (32-bit only), but there are reports on gcc-testresults for x86_64-pc-linux-gnu, s390x-ibm-linux-gnu, powerpc-ibm-aix7.2.3.0, hppa-unknown-linux-gnu, i586-unknown-freebsd11.4, m68k-unknown-linux-gnu, aarch64-suse-linux-gnu, i686-pc-linux-gnu, probably all for the 32-bit multilib.
[Bug fortran/98763] gfortran.dg/gomp/task-detach-1.f90 FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98763 Rainer Orth changed: What|Removed |Added Target Milestone|--- |11.0
[Bug testsuite/97299] [11 regression] gcc.dg/vect/slp-reduc-3.c fails after r11-3563
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97299 Rainer Orth changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|REOPENED CC||ro at gcc dot gnu.org --- Comment #6 from Rainer Orth --- This patch has caused +XPASS: gcc.dg/vect/slp-reduc-3.c -flto -ffat-lto-objects scan-tree-dump-times vect "VEC_PERM_EXPR" 0 +XPASS: gcc.dg/vect/slp-reduc-3.c scan-tree-dump-times vect "VEC_PERM_EXPR" 0 on sparc-sun-solaris2.11 (32 and 64-bit) and, according to gcc-testresults, on armeb-none-linux-gnueabihf, aarch64-suse-linux-gnu
[Bug testsuite/98771] New: [10/11 regression] gcc.dg/strcmpopt_8.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98771 Bug ID: 98771 Summary: [10/11 regression] gcc.dg/strcmpopt_8.c FAILs Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: msebor at gcc dot gnu.org Target Milestone: --- Target: i386-pc-solaris2.11, sparc-sun-solaris2.11 Created attachment 50012 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50012&action=edit i386-pc-solaris2.11 64-bit strcmpopt_8.c.033t.forwprop1 As originally reported in PR tree-optimization/92683, the gcc.dg/strcmpopt_8.c test still FAILs on both Solaris/x86 and SPARC: * on x86 with -m64 only: FAIL: gcc.dg/strcmpopt_8.c scan-tree-dump-not forwprop1 "strncmp" * on sparc with -m64 only: FAIL: gcc.dg/strcmpopt_8.c (test for excess errors) Excess errors: /vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/strcmpopt_8.c:22:15: warning: '__builtin_strncmp' specified bound 18446744073709551615 exceeds maximum object size 9223372036854775807 [-Wstringop-overread] /vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/strcmpopt_8.c:22:15: warning: '__builtin_strncmp' specified bound 18446744073709551615 exceeds maximum object size 9223372036854775807 [-Wstringop-overread] /vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/strcmpopt_8.c:22:15: warning: '__builtin_strncmp' specified bound 18446744073709551615 exceeds maximum object size 9223372036854775807 [-Wstringop-overread] /vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/strcmpopt_8.c:22:15: warning: '__builtin_strncmp' specified bound 18446744073709551615 exceeds maximum object size 9223372036854775807 [-Wstringop-overread] /vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/strcmpopt_8.c:22:15: warning: '__builtin_strncmp' specified bound 18446744073709551615 exceeds maximum object size 9223372036854775807 [-Wstringop-overread] /vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/strcmpopt_8.c:22:15: warning: '__builtin_strncmp' specified bound 18446744073709551615 exceeds maximum object size 9223372036854775807 [-Wstringop-overread] /vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/strcmpopt_8.c:22:15: warning: '__builtin_strncmp' specified bound 18446744073709551615 exceeds maximum object size 9223372036854775807 [-Wstringop-overread] FAIL: gcc.dg/strcmpopt_8.c scan-tree-dump-not forwprop1 "strncmp" This only happens with 32-bit-default compilers, the corresponding 64-bit-default compilers don't show the failure. I'm attaching both the amd64 and sparcv9 dumps (which are effectively identical).
[Bug testsuite/98771] [10/11 regression] gcc.dg/strcmpopt_8.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98771 --- Comment #1 from Rainer Orth --- Created attachment 50013 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50013&action=edit 64-bit sparc-sun-solaris2.11 strcmpopt_8.c.033t.forwprop1
[Bug testsuite/98771] [10/11 regression] gcc.dg/strcmpopt_8.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98771 Rainer Orth changed: What|Removed |Added Target Milestone|--- |10.3
[Bug tree-optimization/96458] [10/11 Regression] internal compiler error: in expand_expr_addr_expr_1, at expr.c:8075 for msp430-elf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96458 Rainer Orth changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED CC||ro at gcc dot gnu.org --- Comment #1 from Rainer Orth --- Already known/reported. *** This bug has been marked as a duplicate of bug 90448 ***
[Bug c++/90448] [8/9/10/11 Regression] decltype-based lambda parameter pack is rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90448 Rainer Orth changed: What|Removed |Added CC||jozefl at gcc dot gnu.org --- Comment #9 from Rainer Orth --- *** Bug 96458 has been marked as a duplicate of this bug. ***
[Bug ada/98773] New: [11 regression] Bootstrap failure: "Trmsgggg" conflicts with declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98773 Bug ID: 98773 Summary: [11 regression] Bootstrap failure: "Trms" conflicts with declaration Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org Target Milestone: --- Target: i386-pc-solaris2.11, sparc-sun-solaris2.11 Between 20210119 (8227106f5668c8fb1f0c5d2026e44cc0b84ee991) and 20210120 (261cdd23195bc921737fd7a44e34a93ccc44), bootstrap began to fail in stage 2: * Solaris/x86: a-except.adb:625:04: "Trms" conflicts with declaration at line 624 * Solaris/SPARC: osint.ads:51:04: "T" conflicts with declaration at line 50 a-except.adb:625:04: "Trrr" conflicts with declaration at line 624 butil.adb:401:55: "T" conflicts with declaration at line 397 osint.ads:51:04: "T" conflicts with declaration at line 50 erroutc.adb:383:55: "T" conflicts with declaration at line 381 errout.adb:787:07: "T" conflicts with declaration at line 786 exp_ch6.adb:82:04: "T" conflicts with declaration at exp_ch6.ads:59 sem_util.adb:885:30: "T" conflicts with declaration at line 881 sem_util.adb:885:30: "T" conflicts with declaration at line 881 Seems like a miscompilation; haven't started a reghunt yet.
[Bug ada/98773] [11 regression] Bootstrap failure: "Trmsgggg" conflicts with declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98773 Rainer Orth changed: What|Removed |Added Target Milestone|--- |11.0
[Bug ada/98773] [11 regression] Bootstrap failure: "Trmsgggg" conflicts with declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98773 Rainer Orth changed: What|Removed |Added Target|i386-pc-solaris2.11,|i386-pc-solaris2.11, |sparc-sun-solaris2.11 |sparc-sun-solaris2.11, ||i686-pc-linux-gnu --- Comment #1 from Rainer Orth --- FWIW it seems to be a 32-bit-only issue: while both amd64-pc-solaris2.11 and x86_64-pc-linux-gnu bootstraps worked fine, i686-pc-linux-gnu is similarly broken: targparm.adb:76:04: "Tbbccstr" conflicts with declaration at line 75
[Bug ada/98773] [11 regression] Bootstrap failure: "Trmsgggg" conflicts with declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98773 Rainer Orth changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #2 from Rainer Orth --- I misspoke initially: the failure happens in stage 3. I've now run a reghunt and found this patch as the culprit: commit 261cdd23195bc921737fd7a44e34a93ccc44 Author: Richard Biener Date: Wed Jan 20 11:28:30 2021 +0100 Handle overflow in dependence analysis lambda ops gracefully
[Bug debug/98811] New: [11 regression] All Go tests FAIL with abbrev offset out of range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98811 Bug ID: 98811 Summary: [11 regression] All Go tests FAIL with abbrev offset out of range Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: ian at airs dot com, mark at gcc dot gnu.org Target Milestone: --- Target: *-*-solaris2.11, i686-pc-linux-gnu, x86_64-pc-linux-gnu Since the switch to DWARF-5, all Go execution tests started to FAIL in the same way: fatal error: abbrev offset out of range goroutine 1 [running, locked to thread]: fatal error: abbrev offset out of range panic during panic goroutine 1 [running, locked to thread]: fatal error: abbrev offset out of range stack trace unavailable I'm seeing this on both Solaris and Linux, 32 and 64-bit. However, this does not happen when Solaris as is in use, only with GNU as 2.35 (irrespective of linker: Solaris ld and GNU ld show the same behaviour). However, when I switched to the freshly released GNU as 2.36 today, the error vanished everywhere.
[Bug debug/98811] [11 regression] All Go tests FAIL with abbrev offset out of range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98811 Rainer Orth changed: What|Removed |Added Target Milestone|--- |11.0
[Bug d/98910] New: [11 regression] locale_t undefined on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98910 Bug ID: 98910 Summary: [11 regression] locale_t undefined on Solaris Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: d Assignee: ibuclaw at gdcproject dot org Reporter: ro at gcc dot gnu.org Target Milestone: --- Target: *-*-solaris2.11 Created attachment 50100 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50100&action=edit Proposed patch. This patch commit 92dd3e71f957c7818f4ce4189bd187b59af20d9b Author: Iain Buclaw Date: Thu Jan 28 11:18:42 2021 +0100 libphobos: Synchronize libdruntime bindings with upstream druntime broke Solaris bootstrap for two reasons: * locale_t isn't defined: /vol/gcc/src/hg/master/local/libphobos/libdruntime/core/sys/posix/locale.d:67:10: error: undefined identifier 'locale_t' 67 | locale_t duplocale(locale_t locale); | ^ /vol/gcc/src/hg/master/local/libphobos/libdruntime/core/sys/posix/locale.d:69:10: error: undefined identifier 'locale_t' 69 | void freelocale(locale_t locale); | ^ /vol/gcc/src/hg/master/local/libphobos/libdruntime/core/sys/posix/locale.d:73:10: error: undefined identifier 'locale_t' 73 | locale_t newlocale(int mask, const char* locale, locale_t base); | ^ /vol/gcc/src/hg/master/local/libphobos/libdruntime/core/sys/posix/locale.d:77:10: error: undefined identifier 'locale_t' 77 | locale_t uselocale (locale_t locale); | ^ /vol/gcc/src/hg/master/local/libphobos/libdruntime/core/sys/posix/string.d:24:15: error: module core.sys.posix.locale import 'locale_t' not found 24 | public import core.sys.posix.locale : locale_t; | ^ While this can be fixed as in the attached patch, there's a caveat: locale_t and the functions using it are XPG7 additions, but Solaris 11.3 (which is still supported by GCC) only conforms to XPG6. I suspect it's not the only one. Right now, the effects aren't that bad as I've confirmed with an Solaris 11.3/x86 bootstrap since those functions/types are only declared, but not actually used. * there's an alias conflict for idtype_t: /vol/gcc/src/hg/master/local/libphobos/libdruntime/core/thread/osthread.d:1468:12: error: alias core.thread.osthread.idtype_t conflicts with alias core.thread.osthread.idtype_t at /vol/gcc/src/hg/master/local/libphobos/libdruntime/core/thread/osthread.d:162:12 1468 | import core.sys.posix.sys.wait : idtype_t; |^ also fixed by removing the second group of imports. The attached patch has been tested on both i386-pc-solaris2.11 (Solaris 11.4 and 11.3) and sparc-sun-solaris2.11 (Solaris 11.4).
[Bug c++/98531] [11 Regression] g++.dg/modules/xtreme-header-2_a.H etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98531 --- Comment #9 from Rainer Orth --- I've now managed to test your v2 patch, with mixed results: * On Solaris 11.4: the libstdc++ failures are gone the new tests PASS however, the old g++.dg/modules tests continue to ICE as before * On Solaris 11.3: the new tests ICE: FAIL: g++.dg/modules/pr98531_a.H -std=c++17 (internal compiler error) FAIL: g++.dg/modules/pr98531_a.H -std=c++17 (test for excess errors) FAIL: g++.dg/modules/pr98531_a.H -std=c++2a (internal compiler error) FAIL: g++.dg/modules/pr98531_a.H -std=c++2a (test for excess errors) FAIL: g++.dg/modules/pr98531_a.H module-cmi (gcm.cache/\$srcdir/g++.dg/modules/pr98531_a.H.gcm) FAIL: g++.dg/modules/pr98531_a.H module-cmi (gcm.cache/\$srcdir/g++.dg/modules/pr98531_a.H.gcm) FAIL: g++.dg/modules/pr98531_b.C -std=c++17 (test for excess errors) FAIL: g++.dg/modules/pr98531_b.C -std=c++2a (test for excess errors) Excess errors: /vol/gcc/src/hg/master/local/gcc/testsuite/g++.dg/modules/pr98531_a.H: internal compiler error: in tree_node, at cp/module.cc:9137 0xa218acd trees_out::tree_node(tree_node*) /vol/gcc/src/hg/master/local/gcc/cp/module.cc:9137 0x8c4314e trees_out::core_vals(tree_node*) /vol/gcc/src/hg/master/local/gcc/cp/module.cc:6013 0x8c465cf trees_out::tree_node_vals(tree_node*) /vol/gcc/src/hg/master/local/gcc/cp/module.cc:7154 0x8c465cf trees_out::tree_value(tree_node*) /vol/gcc/src/hg/master/local/gcc/cp/module.cc:8968 0x8c4259e trees_out::tree_node(tree_node*) /vol/gcc/src/hg/master/local/gcc/cp/module.cc:9166 0x8c4314e trees_out::core_vals(tree_node*) /vol/gcc/src/hg/master/local/gcc/cp/module.cc:6013 0x8c465cf trees_out::tree_node_vals(tree_node*) /vol/gcc/src/hg/master/local/gcc/cp/module.cc:7154 0x8c465cf trees_out::tree_value(tree_node*) /vol/gcc/src/hg/master/local/gcc/cp/module.cc:8968 0x8c4259e trees_out::tree_node(tree_node*) /vol/gcc/src/hg/master/local/gcc/cp/module.cc:9166 0x8c4314e trees_out::core_vals(tree_node*) /vol/gcc/src/hg/master/local/gcc/cp/module.cc:6013 0x8c465cf trees_out::tree_node_vals(tree_node*) /vol/gcc/src/hg/master/local/gcc/cp/module.cc:7154 0x8c465cf trees_out::tree_value(tree_node*) /vol/gcc/src/hg/master/local/gcc/cp/module.cc:8968 0x8c4259e trees_out::tree_node(tree_node*) /vol/gcc/src/hg/master/local/gcc/cp/module.cc:9166 0x8c4314e trees_out::core_vals(tree_node*) /vol/gcc/src/hg/master/local/gcc/cp/module.cc:6013 0x8c465cf trees_out::tree_node_vals(tree_node*) /vol/gcc/src/hg/master/local/gcc/cp/module.cc:7154 0x8c465cf trees_out::tree_value(tree_node*) /vol/gcc/src/hg/master/local/gcc/cp/module.cc:8968 0x8c4259e trees_out::tree_node(tree_node*) /vol/gcc/src/hg/master/local/gcc/cp/module.cc:9166 0x8c4314e trees_out::core_vals(tree_node*) /vol/gcc/src/hg/master/local/gcc/cp/module.cc:6013 0x8c465cf trees_out::tree_node_vals(tree_node*) /vol/gcc/src/hg/master/local/gcc/cp/module.cc:7154 0x8c465cf trees_out::tree_value(tree_node*) /vol/gcc/src/hg/master/local/gcc/cp/module.cc:8968 This seems to be exactly the same stacktrace as the one in the g++.dg/modules tests. I suspected that this is due to the fact that unlike Solaris 11.4, 11.3 doesn't have __cxa_atexit in libc, and indeed compiling on 11.3 with -fuse-cxa-atexit makes the ICE go away, while -fno-use-cxa-atexit on 11.4 causes it.
[Bug d/98910] [11 regression] locale_t undefined on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98910 --- Comment #2 from Rainer Orth --- Unfortunately, even with your patch Solaris bootstrap is still broken: /vol/gcc/src/hg/master/local/libphobos/libdruntime/core/sys/posix/strings.d:23:15: error: module core.sys.posix.locale import 'locale_t' not found 23 | public import core.sys.posix.locale : locale_t; | ^ I only now noticed that you only define the XPG6 subset of locale functions in locale.d for Solaris. That seems quite unfortunate, castrating functionality for the benefit of older XPG6-only Solaris 11.3 while 11.4 supports locale_t and XPG7 perfectly fine. I'm uncertain what's the best way to handle this: one could certainly test for a locale_t definition via autoconf, record the result in gcc/config.d, and use that instead of version (Solaris). The same test would have to be used in strings.d to avoid leaving that broken when locale_t isn't available.
[Bug testsuite/100451] New: g++.dg/warn/Warray-bounds-20.C XPASSes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100451 Bug ID: 100451 Summary: g++.dg/warn/Warray-bounds-20.C XPASSes Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: msebor at gcc dot gnu.org Target Milestone: --- Between 20210318 (ab03c0d5753549f1a78eeb706510b55fb97c8651) and 20210319 (287e3e8466f44f9d395a2e4dcfcda56cc34ceb1c), g++.dg/warn/Warray-bounds-20.C began to XPASS for 32-bit compilations: XPASS: g++.dg/warn/Warray-bounds-20.C -std=gnu++14 assign (test for warnings, line 30) XPASS: g++.dg/warn/Warray-bounds-20.C -std=gnu++17 assign (test for warnings, line 30) XPASS: g++.dg/warn/Warray-bounds-20.C -std=gnu++2a assign (test for warnings, line 30) XPASS: g++.dg/warn/Warray-bounds-20.C -std=gnu++98 assign (test for warnings, line 30) I'm seeing it on all of i386-pc-solaris2.11, sparc-sun-solaris2.11, and x86_64-pc-linux-gnu with -m32. According to gcc-testresults, the same issue exists on a wide range of other targets, probably everywhere. The gcc-11 branch is affected as well.
