[Bug target/113719] [13/14/15 regression] g++.target/i386/pr103696.C FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113719 --- Comment #6 from Rainer Orth --- Maybe it's time to ping the patch?
[Bug ada/115270] New: gnat doesn't link on 32-bit Linux/sparc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115270 Bug ID: 115270 Summary: gnat doesn't link on 32-bit Linux/sparc Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: dkm at gcc dot gnu.org, ebotcazou at gcc dot gnu.org Target Milestone: --- Target: sparc-unknown-linux-gnu When trying to build trunk on 32-bit Linux/sparc for comparison with 32-bit Solaris/SPARC, the build failed because gnat didn't link: /vol/gcc/bin/sparc/gld-2.42: ../rts/s-atopri.o: in function `system__atomic_primitives__lock_free_try_write_64': /var/gcc/regression/master/6.8.9-gcc-gas-gld-32/build/gcc/ada/rts/s-atopri.adb:67:(.text+0x250): undefined reference to `__atomic_compare_exchange_8' collect2: error: ld returned 1 exit status gnatlink: error when calling /var/gcc/regression/master/6.8.9-gcc-gas-gld-32/build/gcc/xg++ make[3]: *** [../gcc-interface/Makefile:464: common-tools] Error 4 make[3]: Leaving directory '/var/gcc/regression/master/6.8.9-gcc-gas-gld-32/build/gcc/ada/tools' make[2]: *** [Makefile:201: gnattools-native] Error 2 make[2]: Leaving directory '/var/gcc/regression/master/6.8.9-gcc-gas-gld-32/build/gnattools' This happened both when configuring with --with-cpu-32=ultrasparc and --with-cpu=v9. In hindsight, that's obvious because __atomic_compare_exchange_8 requires -mv8plus, which AFAICS isn't enabled on 32-bit Linux/sparc and I found no way to do so. This is unlike 32-bit Solaris/SPARC, where TARGET_DEFAULT includes MASK_V8PLUS. While it's clear the Linux/sparc cannot move to the Solaris default since it still supports the V8 Leon CPUs, I wonder if it wouldn't be possible to allow for V8+ with --with-cpu=v9? There are other possible hacks, like explicitly passing -mv8plus for libgnat or linking with -latomic, but those would be just that: hacks.
[Bug libstdc++/111641] FAIL: 19_diagnostics/stacktrace/current.cc -std=gnu++23 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111641 Rainer Orth changed: What|Removed |Added Target Milestone|15.0|14.2 Assignee|unassigned at gcc dot gnu.org |ro at gcc dot gnu.org --- Comment #10 from Rainer Orth --- Fixed for GCC 15.0; will commit to the gcc-14 branch after a bit of soak time.
[Bug libstdc++/111641] FAIL: 19_diagnostics/stacktrace/current.cc -std=gnu++23 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111641 Rainer Orth changed: What|Removed |Added Target Milestone|--- |15.0 URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2024-May/652 ||912.html --- Comment #8 from Rainer Orth --- Patch posted.
[Bug d/115249] [14/15 regression] gdc.test/runnable/test34.d etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115249 Rainer Orth changed: What|Removed |Added Target Milestone|15.0|14.2 --- Comment #2 from Rainer Orth --- It started to regress on the gcc-14 branch indeed. However, for simple testsuite failures, I often don't care about backports, provided the issue is fixed on trunk.
[Bug ada/115250] [15 regression] gnat.dg/opt58.adb FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115250 Rainer Orth changed: What|Removed |Added Target Milestone|--- |15.0
[Bug ada/115250] New: [15 regression] gnat.dg/opt58.adb FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115250 Bug ID: 115250 Summary: [15 regression] gnat.dg/opt58.adb FAILs Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: dkm at gcc dot gnu.org Target Milestone: --- Target: sparc-sun-solaris2.11 Between 20240520 (591bc70139d898c06b1d605ff4fed591ffd2e2e7) and20240521 (232a86f9640cde6908d0875b8df52c36030c5b5e), the gnat.dg/opt58.adb test began to FAIL on 32-bit Solaris/SPARC: FAIL: gnat.dg/opt58.adb (test for excess errors) Excess errors: opt58.adb:13:34: warning: unchecked conversion implemented by copy [enabled by default] opt58.adb:13:34: warning: use pragma Universal_Aliasing on either type [enabled by default] opt58.adb:13:34: warning: to enable RM 13.9(12) implementation permission [enabled by default]
[Bug d/115249] [14/15 regression] gdc.test/runnable/test34.d etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115249 Rainer Orth changed: What|Removed |Added Target Milestone|--- |15.0
[Bug d/115249] New: [14/15 regression] gdc.test/runnable/test34.d etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115249 Bug ID: 115249 Summary: [14/15 regression] gdc.test/runnable/test34.d etc. FAIL Product: gcc Version: 15.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 Between 20240202 (a9e3818fdc3cfa8d51b7526c0f6b61b268cc4be5) and 20240205 (23f1b496aa6c7015a2b986aa183041c722104779), 3 tests regressed on Solaris/SPARC (32 and 64-bit): FAIL: gdc.test/runnable/test34.d execution test FAIL: gdc.test/runnable/test34.d -shared-libphobos execution test FAIL: gdc.test/runnable/xtest46.d execution test FAIL: gdc.test/runnable/xtest46.d -shared-libphobos execution test FAIL: gdc.test/runnable/xtest46_gc.d execution test FAIL: gdc.test/runnable/xtest46_gc.d -shared-libphobos execution test core.exception.AssertError@runnable/test34.d(298): Assertion failure /vol/gcc/src/hg/master/local/libphobos/libdruntime/rt/dmain2.d:232 _d_traceContext [0x100092c73] /vol/gcc/src/hg/master/local/libphobos/libdruntime/rt/deh.d:51 _d_createTrace [0x10009acef] /vol/gcc/src/hg/master/local/libphobos/libdruntime/gcc/deh.d:484 _d_throw [0x100091eb7] /vol/gcc/src/hg/master/local/libphobos/libdruntime/core/exception.d:556 onAssertError [0x1000971eb] ??:? void test34.test13() [0x100087213] ??:? _Dmain [0x10008ca07] one two ~one ~two #2 0x0008d258 in _D6test346test13FZv () at runnable/test34.d:298 298 assert(c.a == 5); (gdb) p c.a warning: can't find linker symbol for virtual table for `test34.C13' value warning: found `initializer for test34.C13' instead $1 = 4 also happens with gld core.exception.AssertError@runnable/xtest46.d(4231): Assertion failure /vol/gcc/src/hg/master/local/libphobos/libdruntime/rt/dmain2.d:232 _d_traceContext [0x1000eca43] /vol/gcc/src/hg/master/local/libphobos/libdruntime/rt/deh.d:51 _d_createTrace [0x1000f4bef] /vol/gcc/src/hg/master/local/libphobos/libdruntime/gcc/deh.d:484 _d_throw [0x1000ebc87] /vol/gcc/src/hg/master/local/libphobos/libdruntime/core/exception.d:556 onAssertError [0x1000f0fbb] ??:? void xtest46.test1962() [0x1000cc9b3] ??:? _Dmain [0x1000e2253] [...] gdb isn't helpful: #2 0x000c988c in _D7xtest468test1962FZv () at runnable/xtest46.d:4231 4231assert(C.classinfo.create() is null); (gdb) p C No symbol "C" in current context. core.exception.AssertError@runnable/xtest46_gc.d-mixin-29(4259): Assertion failure /vol/gcc/src/hg/master/local/libphobos/libdruntime/rt/dmain2.d:232 _d_traceContext [0xe95a3] /vol/gcc/src/hg/master/local/libphobos/libdruntime/rt/deh.d:51 _d_createTrace [0xf2f3b] /vol/gcc/src/hg/master/local/libphobos/libdruntime/gcc/deh.d:484 _d_throw [0xe862b] /vol/gcc/src/hg/master/local/libphobos/libdruntime/core/exception.d:556 onAssertError [0xee753] /vol/gcc/src/hg/master/local/libphobos/libdruntime/core/exception.d:785 _d_assertp [0xee77f] ??:? void xtest46_gc.test1962() [0xcbd7b] ??:? _Dmain [0xdf94b] [...] again, gdb is not helpful: (gdb) up #2 0x000cbc8c in _D10xtest46_gc8test1962FZv () at runnable/xtest46_gc.d-mixin-29:4259 warning: 4259 runnable/xtest46_gc.d-mixin-29: No such file or directory
[Bug libstdc++/115247] experimental/simd/pr109261_constexpr_simd.cc FAILs on 32-bit x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115247 Rainer Orth changed: What|Removed |Added Target Milestone|--- |15.0
[Bug libstdc++/115247] New: experimental/simd/pr109261_constexpr_simd.cc FAILs on 32-bit x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115247
Bug ID: 115247
Summary: experimental/simd/pr109261_constexpr_simd.cc FAILs on
32-bit x86
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: ro at gcc dot gnu.org
CC: mkretz at gcc dot gnu.org
Target Milestone: ---
Target: i?86-*-*, x86_64-*-*
The experimental/simd/pr109261_constexpr_simd.cc test FAILs on 32-bit x86
(seen on all of Solaris, Linux, Darwin):
FAIL: experimental/simd/pr109261_constexpr_simd.cc -msse2 -O2 -Wno-psabi (test
for excess errors)
Excess errors:
/var/gcc/regression/master/11.4-gcc/build/i386-pc-solaris2.11/libstdc++-v3/include/experimental/bits/simd_builtin.h:131:
error: could not convert
'std::experimental::parallelism_v2::__vec_shuffle<__vector(4) wchar_t,
__extract_part<2, 3, 2, wchar_t, 3>(_SimdWrapper)::, std::integer_sequence
>(std::experimental::parallelism_v2::__as_vector<_SimdWrapper
>(__x), (std::make_index_sequence<2>(), std::make_index_sequence<2>()),
(std::experimental::parallelism_v2::__extract_part<2, 3,
2, wchar_t, 3>(_SimdWrapper)::(),
std::experimental::parallelism_v2::__extract_part<2, 3, 2, wchar_t,
3>(_SimdWrapper)::()))' from
'__vector(2) wchar_t' to 'std::conditional_t >' {aka
'std::conditional >::type'}
[Bug ada/115246] [15 regression] gnat.dg/alignment14.adb FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115246 Rainer Orth changed: What|Removed |Added Target Milestone|--- |15.0
[Bug ada/115246] New: [15 regression] gnat.dg/alignment14.adb FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115246 Bug ID: 115246 Summary: [15 regression] gnat.dg/alignment14.adb FAILs Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: dkm at gcc dot gnu.org Target Milestone: --- Target: i386-pc-solaris2.11, sparc-sun-solaris2.11, s390x-ibm-linux-gnu, armv8l-unknown-linux-gnueabihf, i686-apple-darwin17 Between 20240519 (a6114c2a691112f9cf5b072c21685d2e43c76d81) and 20240520 (591bc70139d898c06b1d605ff4fed591ffd2e2e7), the gnat.dg/alignment14.adb test regressed on quite a number of targets, including 32-bit Solaris/SPARC and x86: FAIL: gnat.dg/alignment14.adb (test for excess errors) Excess errors: alignment14.adb:11:29: error: specified alignment too large for discrete or fixed point type
[Bug tree-optimization/115208] [15 Regression] Memory consumption get extremely high after r15-809
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115208 --- Comment #3 from Rainer Orth --- An i686-pc-linux-gnu reghunt just completed, looking for the rust OOM failures reported in PR bootstrap/115213. This patch is the culprit: commit fae5e6a4dfcf9270cd09c2240480860b09c2c627 Author: Andrew MacLeod Date: Tue May 21 14:20:52 2024 -0400 Make gori_map a shared component.
[Bug bootstrap/115213] [15 regression] Excessive memory use compiling rust with 32-bit gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115213 Rainer Orth changed: What|Removed |Added Target Milestone|--- |15.0
[Bug bootstrap/115213] New: [15 regression] Excessive memory use compiling rust with 32-bit gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115213 Bug ID: 115213 Summary: [15 regression] Excessive memory use compiling rust with 32-bit gcc Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org Target Milestone: --- Host: i386-pc-solaris2.11, sparc-sun-solaris2.11, i686-pc-linux-gnu Target: i386-pc-solaris2.11, sparc-sun-solaris2.11, i686-pc-linux-gnu Build: i386-pc-solaris2.11, sparc-sun-solaris2.11, i686-pc-linux-gnu Between 20240523 (f0a02467bbc35a478eb82f5a8a7e8870827b51fc) and 20240524 (51f4b47c4f4f61fe31a7bd1fa80e08c2438d76a8), memory use compiling rust with a 32-bit gcc exploded in stage 2, breaking bootstrap: cc1plus: out of memory allocating 4084 bytes after a total of 3223085056 bytes make[3]: *** [/vol/gcc/src/hg/master/local/gcc/rust/Make-lang.in:412: rust/rust-ast.o] Error 1 make[3]: *** Waiting for unfinished jobs cc1plus: out of memory allocating 65536 bytes after a total of 3011272704 bytes make[3]: *** [Makefile:1197: rust/rust-session-manager.o] Error 1 cc1plus: out of memory allocating 4064 bytes after a total of 3049021440 bytes make[3]: *** [/vol/gcc/src/hg/master/local/gcc/rust/Make-lang.in:422: rust/rust-macro-expand.o] Error 1 So far, I've no idea which commit in this range might be responsible. Seems to call for a reghunt.
[Bug libbacktrace/115212] New: testsuite should produce DejaGnu style summary, log
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115212 Bug ID: 115212 Summary: testsuite should produce DejaGnu style summary, log Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libbacktrace Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: ian at gcc dot gnu.org Target Milestone: --- Currently, when libbacktrace make -k check is run, it only produces a summary in its own (or rather, automake's) format: test-suite.log or individual PASS/FAIL results buried deeply in the build logs. Also, when building even a single test fails for some reason, the testsuite isn't run at all, which again is quite easily missed. It would be way better if libbacktrace make check produced DejaGnu style log and summary files, as e.g. libgo does. Those would be picked up by make mail-report.log and testsuite failures were much harder to overlook.
[Bug other/115211] New: [11/12/13/14/15 regression] -frecord-gcc-switches refactoring lost list of enabled options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115211 Bug ID: 115211 Summary: [11/12/13/14/15 regression] -frecord-gcc-switches refactoring lost list of enabled options Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org Target Milestone: --- When investigating PR libstdc++/111641, I had the need to determine if -funwind-tables is enabled by default on various targets. Previously, this could be done as easily as assembling an empty file with -dA -fverbose-asm and looking for the "options enabled" comment in there (or, as I recently learned, by just adding -Q -v to the compile command). To my dismay, I found that this facility has been removed since GCC 11 by this commit: commit 7caa49706316e650fb67719e1a1bf3a35054b685 Author: Martin Liska Date: Mon Nov 23 13:40:04 2020 +0100 Refactor -frecord-gcc-switches. -[fg]record-gcc-switches is no replacement since it only includes the options explicitly passed on the command line, not the enabled ones. I know of no replacement at all for this facitlity, and digging through the mazes of option handling in toplev.cc, opts.cc, target option handling code is a totally losing proposition. Martin argued in https://gcc.gnu.org/pipermail/gcc-patches/2020-November/560358.html that the support in GCC 10 were incomplete, but any support is better than nothing at all. Going back to GCC 10 may sort of work for a while, but over time the divergence will become so great that the result is useless.
[Bug libstdc++/111641] FAIL: 19_diagnostics/stacktrace/current.cc -std=gnu++23 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111641 --- Comment #7 from Rainer Orth --- Created attachment 58276 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58276=edit Minimal patch Minimal patch as described: just build src/libbacktrace with -funwind-tables, same for 19_diagnostics/stacktrace tests. Ran just the stacktrace tests on i386-pc-solaris2.11 and sparc-sun-solaris2.11 (32 and 64-bit each), all PASS now.
[Bug tree-optimization/114072] gcc.dg/vect/vect-pr111779.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114072 Rainer Orth changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Assignee|unassigned at gcc dot gnu.org |ro at gcc dot gnu.org Resolution|--- |FIXED Target Milestone|--- |15.0 --- Comment #8 from Rainer Orth --- Fixed for GCC 15.0.
[Bug testsuite/115140] [15 regression] libgomp.oacc-c++/../libgomp.oacc-c-c++-common/acc_prof-kernels-1.c excess errors after r15-579-ga9251ab3c91c8c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115140 Rainer Orth changed: What|Removed |Added Host|powerpc64-linux-gnu,|powerpc64-linux-gnu, |powerpc64le-linux-gnu |powerpc64le-linux-gnu, ||*-*-solaris2.11 CC||ro at gcc dot gnu.org Build|powerpc64-linux-gnu,|powerpc64-linux-gnu, |powerpc64le-linux-gnu |powerpc64le-linux-gnu, ||*-*-solaris2.11 Target|powerpc64-linux-gnu,|powerpc64-linux-gnu, |powerpc64le-linux-gnu |powerpc64le-linux-gnu, ||*-*-solaris2.11 --- Comment #2 from Rainer Orth --- Also seen on Solaris/SPARC and x86.
[Bug testsuite/102954] [12/13/14/15 regression] gcc.dg/vect/pr33804.c XPASSes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102954
--- Comment #8 from Rainer Orth ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #2)
> > --- Comment #1 from Richard Biener ---
> > It was likely the vect_worthwhile_without_simd_p changes where we might now
> > vectorize this loop using (unaligned) 'int'.
> >
> > Can you confirm that?
>
> Indeed. I've also noticed that another regression was caused by the
> same change:
>
> XPASS: gcc.dg/vect/slp-multitypes-3.c -flto -ffat-lto-objects
> scan-tree-dump-times vect "vectorized 1 loops" 1
> XPASS: gcc.dg/vect/slp-multitypes-3.c -flto -ffat-lto-objects
> scan-tree-dump-times vect "vectorizing stmts using SLP" 2
> XPASS: gcc.dg/vect/slp-multitypes-3.c scan-tree-dump-times vect "vectorized
> 1 loops" 1
> XPASS: gcc.dg/vect/slp-multitypes-3.c scan-tree-dump-times vect "vectorizing
> stmts using SLP" 2
>
> Again 64-bit SPARC.
That test already has
/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect" { xfail
sparc*-*-* } } } */
so we could change the xfail to { sparc*-*-* && ilp32 } (although that might be
papering over the real issue).
[Bug tree-optimization/114072] gcc.dg/vect/vect-pr111779.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114072 --- Comment #1 from Rainer Orth --- Richard, any suggestion on how to handle this? There are 3 instances of "not vectorized" in the dump: /vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/vect/vect-pr111779.c:29:23: missed: not vectorized: relevant stmt not supported: _4 = a$b4_6 >> 7; /vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/vect/vect-pr111779.c:36:1: missed: not vectorized: relevant stmt not supported: _ifc__32 = x[i_15].D.2986; /vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/vect/vect-pr111779.c:45:17: missed: not vectorized: no grouped stores in basic block.
[Bug tree-optimization/114154] gcc.dg/vect/vect-alias-check-1.c XPASSes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114154 Rainer Orth changed: What|Removed |Added CC||felix.yang at huawei dot com --- Comment #5 from Rainer Orth --- Felix, can you have a look please?
[Bug tree-optimization/115184] gcc.dg/vect/vect-33.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115184 --- Comment #1 from Rainer Orth --- Created attachment 58266 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58266=edit 32-bit sparc-sun-solaris2.11 vect-33.c.265t.optimized
[Bug tree-optimization/115184] New: gcc.dg/vect/vect-33.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115184 Bug ID: 115184 Summary: gcc.dg/vect/vect-33.c FAILs Product: gcc Version: 15.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: hubicka at gcc dot gnu.org Target Milestone: --- Target: sparc*-sun-solaris2.11 Since 20230801, the gcc.dg/vect/vect-33.c test FAILs on 32 and 64-bit Solaris/SPARC: FAIL: gcc.dg/vect/vect-33.c -flto -ffat-lto-objects scan-tree-dump-not optimized "Invalid sum" FAIL: gcc.dg/vect/vect-33.c scan-tree-dump-not optimized "Invalid sum" Obviously due to this patch: commit 1762957384c659a2e6827939ce4b1f1d1ad40003 Author: Jan Hubicka Date: Tue Aug 1 12:07:39 2023 +0200
[Bug tree-optimization/108357] [13 Regression] Dead Code Elimination Regression at -O2 since r13-4607-g2dc5d6b1e7ec88
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108357 Rainer Orth changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|REOPENED --- Comment #22 from Rainer Orth --- As reported, the test still FAILs on Solaris/SPARC (and always had). Also happens on Linux/sparc64, btw., so nothing Solaris-specific in here.
[Bug tree-optimization/113524] FAIL: gcc.dg/torture/pr113026-1.c -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (test for bogus messages, line 10)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113524 Rainer Orth changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #3 from Rainer Orth --- FWIW, I've now found that on sparc-sun-solaris2.11 (32-bit only) the warning occurs as far back as gcc 10 with just gcc -O3 -ftracer Back in gcc 10, it would happen for both -m32 and -m64, while from gcc 11 onward, it's for -m32 only.
[Bug tree-optimization/110279] [14 Regression] Regressions on aarch64 cause by handing FMA in reassoc (510.parest_r, 508.namd_r)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110279 Rainer Orth changed: What|Removed |Added Resolution|FIXED |--- CC||ro at gcc dot gnu.org Last reconfirmed||2024-05-21 Status|RESOLVED|REOPENED Ever confirmed|0 |1 --- Comment #9 from Rainer Orth --- Not at all, the test still FAILs on sparc-sun-solaris2.11, arm-unknown-linux-gnueabihf, pru-unknown-elf, m68k-unknown-linux-gnu.
[Bug analyzer/107856] [13/14/15 Regression] gcc.dg/plugin/infoleak-vfio_iommu_type1.c XPASSes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107856 --- Comment #4 from Rainer Orth --- Something is very weird with this test: * For 32-bit x86 (both with 32-bit default and 64-bit default compilers), gcc emits not output at all and the bogus warning on l.42 XPASSes. * For 64-bit x86, the bogus message is emitted and XFAILed. * For 32 and 64-bit sparc (with with 32-bit default and 64-bit default compilers), we always get the bogus message, XFAILed as expected. Doesn't seem particularly reliable to me ;-)
[Bug ada/115168] [15 regression] Several libada compile errors on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115168 Rainer Orth changed: What|Removed |Added Target Milestone|--- |15.0
[Bug ada/115168] New: [15 regression] Several libada compile errors on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115168 Bug ID: 115168 Summary: [15 regression] Several libada compile errors on Solaris Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: dkm at gcc dot gnu.org, ebotcazou at gcc dot gnu.org Target Milestone: --- Target: *-*-solaris2.11 Between 20240519 (a6114c2a691112f9cf5b072c21685d2e43c76d81) and 20240520 (591bc70139d898c06b1d605ff4fed591ffd2e2e7), Ada bootstrap on Solaris got broken again in various ways: * sparc-sun-solaris2.11: s-taprop.adb:427:07: error: "Self_ID" is undefined * i386-pc-solaris2.11: a-strunb.ads:749:09: error: run-time library configuration error a-strunb.ads:749:09: error: file s-finpri.ads had semantic errors a-strunb.ads:749:09: error: entity "System.Finalization_Primitives.Master_Node" not available s-oslock.ads:46:40: error: specified alignment too large for discrete or fixed point type
[Bug ada/115133] [15 regression] s-oslock__solaris.ads doesn't compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115133 Rainer Orth changed: What|Removed |Added Target Milestone|--- |15.0
[Bug ada/115133] New: [15 regression] s-oslock__solaris.ads doesn't compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115133 Bug ID: 115133 Summary: [15 regression] s-oslock__solaris.ads doesn't compile Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: dkm at gcc dot gnu.org, ebotcazou at gcc dot gnu.org Target Milestone: --- Target: *-*-solaris2.11 The new gcc/ada/libgnat/s-oslock__solaris.ads from commit c8e5d90c4a0b736c2c4c5be3e8a3e9744e602d9d Author: Eric Botcazou Date: Tue Mar 5 23:30:51 2024 +0100 ada: Replace spinlocks with fully-fledged locks in finalization collections breaks Solaris Ada bootstrap: s-oslock.ads:50:10: error: "Ada" is not visible s-oslock.ads:50:10: error: non-visible declaration at ada.ads:16 This snippet got me further along: diff --git a/gcc/ada/libgnat/s-oslock__solaris.ads b/gcc/ada/libgnat/s-oslock__solaris.ads --- a/gcc/ada/libgnat/s-oslock__solaris.ads +++ b/gcc/ada/libgnat/s-oslock__solaris.ads @@ -32,6 +32,7 @@ -- This is a Solaris (native) version of this package with Interfaces.C; +with Ada.Unchecked_Conversion; package System.OS_Locks is pragma Preelaborate; @@ -65,10 +66,10 @@ package System.OS_Locks is private - type array_type_9 is array (0 .. 3) of unsigned_char; + type array_type_9 is array (0 .. 3) of Interfaces.C.unsigned_char; type record_type_3 is record flag : array_type_9; - Xtype : unsigned_long; + Xtype : Interfaces.C.unsigned_long; end record; pragma Convention (C, record_type_3); but it may not be enough: a-stbufi.ads:71:04: error: run-time library configuration error a-stbufi.ads:71:04: error: file s-taskin.ads had semantic errors a-stbufi.ads:71:04: error: entity "System.Tasking.Activation_Chain_Access" not available s-osinte.ads:301:29: error: "OS_Lock" not declared in "System" s-osinte.ads:301:30: error: possible misspelling of "OS_Locks" compilation abandoned make[6]: *** [../gcc-interface/Makefile:306: a-stbufi.o] Error 1 This patch fixes the typo: diff --git a/gcc/ada/libgnarl/s-osinte__solaris.ads b/gcc/ada/libgnarl/s-osinte__solaris.ads --- a/gcc/ada/libgnarl/s-osinte__solaris.ads +++ b/gcc/ada/libgnarl/s-osinte__solaris.ads @@ -298,7 +298,7 @@ package System.OS_Interface is function To_thread_t is new Ada.Unchecked_Conversion (Integer, thread_t); - subtype mutex_t is System.OS_Lock.mutex_t; + subtype mutex_t is System.OS_Locks.mutex_t; type cond_t is limited private; until one runs into s-oslock.ads:83:03: (style) bad indentation [-gnaty0] make[6]: *** [../gcc-interface/Makefile:306: a-undesu.o] Error 1 No idea what's wrong here, though.
[Bug middle-end/115110] [15 regression] several failures after r15-512-g9b7cad5884f21c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115110 Rainer Orth changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=115106 CC||ro at gcc dot gnu.org --- Comment #5 from Rainer Orth --- There's also PR ada/115106 where this patch broke 32-bit Solaris/x86 Ada bootstrap.
[Bug debug/115066] [debug, gsplit-dwarf, gdwarf-4, g3] DW_MACRO_define_strp used for debug_str_offsets index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115066 Rainer Orth changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2024-05-16 CC||ro at gcc dot gnu.org Resolution|FIXED |--- Status|RESOLVED|REOPENED --- Comment #10 from Rainer Orth --- The new test currently FAILs on Solaris/SPARC with the native as: FAIL: gcc.dg/pr115066.c scan-assembler .bytet0xbt# Define macro strx The relevant snippet of pr115066.s is .section".debug_macro.dwo",#exclude,#progbits .LLdebug_macro0: .uahalf 0x4 ! DWARF macro version number .byte 0x2 ! Flags: 32-bit, lineptr present .uaword .LLskeleton_debug_line0 .byte 0x1 ! Define macro while when using gas, I have .section.debug_macro.dwo,"e",@progbits .LLdebug_macro0: .uahalf 0x4 ! DWARF macro version number .byte 0x2 ! Flags: 32-bit, lineptr present .uaword .LLskeleton_debug_line0 .byte 0xb ! Define macro strx AFAICS from dwarf2out.cc (output_macinfo_op), the requirements for using DW_MACRO_define_strx are (among others) !DWARF2_INDIRECT_STRING_SUPPORT_MISSING_ON_TARGET && SECTION_MERGE. However, with the native assembler, SHF_MERGE doesn't work (as emits something ld cannot link). I wonder how best to handle this: just skip the test on sparc*-sun-solaris2* && !gas? Theoretically, there could be other targets with similar issues.
[Bug ada/115106] [15 regression] SEGV in sem_elab.internal_representation.nts_map.mutate_and_rehash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115106 Rainer Orth changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #1 from Rainer Orth --- The reghunt identified commit 9b7cad5884f21cc5783075be0043777448db3fab Author: Jan Hubicka Date: Wed May 15 14:14:27 2024 +0200 Avoid pointer compares on TYPE_MAIN_VARIANT in TBAA FWIW, none of amd64-pc-solaris2.11, i686-pc-linux-gnu, and x86_64-pc-linux-gnu show the failure.
[Bug ada/115106] New: [15 regression] SEGV in sem_elab.internal_representation.nts_map.mutate_and_rehash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115106 Bug ID: 115106 Summary: [15 regression] SEGV in sem_elab.internal_representation.nts_map.mutate_and_re hash Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: dkm at gcc dot gnu.org Target Milestone: --- Host: i386-pc-solaris2.11 Target: i386-pc-solaris2.11 Build: i386-pc-solaris2.11 Between 20240514 (0a99ad5c52caa06c113b1889bbe6634812b89be5) and 20240515 (5609d77e683944439fae38323ecabc44a1eb4671), Ada bootstrap broke in stage 3 on Solaris/x86: +===GNAT BUG DETECTED==+ | 15.0.0 20240515 (experimental) [master 5609d77e683944439fae38323ecabc44a1eb4671] (i386-pc-solaris2.11) | | Constraint_Error SIGSEGV | | Error detected at table.adb:219:13 [ali.ads:315:4] | | Compiling /vol/gcc/src/hg/master/local/gcc/ada/ali.adb | | Please submit a bug report; see https://gcc.gnu.org/bugs/ . | | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact command that you entered. | | Also include sources listed below. | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. Consider also -gnatd.n switch (see debug.adb). /vol/gcc/src/hg/master/local/gcc/ada/gcc-interface/system.ads /vol/gcc/src/hg/master/local/gcc/ada/ali.adb /vol/gcc/src/hg/master/local/gcc/ada/ali.ads /vol/gcc/src/hg/master/local/gcc/ada/casing.ads /vol/gcc/src/hg/master/local/gcc/ada/namet.ads /vol/gcc/src/hg/master/local/gcc/ada/alloc.ads /vol/gcc/src/hg/master/local/gcc/ada/hostparm.ads /vol/gcc/src/hg/master/local/gcc/ada/types.ads /vol/gcc/src/hg/master/local/gcc/ada/libgnat/ada.ads /vol/gcc/src/hg/master/local/gcc/ada/libgnat/a-unccon.ads /vol/gcc/src/hg/master/local/gcc/ada/libgnat/a-uncdea.ads /vol/gcc/src/hg/master/local/gcc/ada/table.ads ada/generated/gnatvsn.ads /vol/gcc/src/hg/master/local/gcc/ada/rident.ads ada/s-rident.ads ada/gnat.ads ada/g-dyntab.ads /vol/gcc/src/hg/master/local/gcc/ada/libgnat/g-htable.ads /vol/gcc/src/hg/master/local/gcc/ada/libgnat/s-htable.ads /vol/gcc/src/hg/master/local/gcc/ada/butil.ads /vol/gcc/src/hg/master/local/gcc/ada/debug.ads /vol/gcc/src/hg/master/local/gcc/ada/fname.ads /vol/gcc/src/hg/master/local/gcc/ada/opt.ads /vol/gcc/src/hg/master/local/gcc/ada/libgnat/s-string.ads /vol/gcc/src/hg/master/local/gcc/ada/libgnat/s-wchcon.ads /vol/gcc/src/hg/master/local/gcc/ada/osint.ads /vol/gcc/src/hg/master/local/gcc/ada/libgnat/s-os_lib.ads /vol/gcc/src/hg/master/local/gcc/ada/libgnat/s-stoele.ads /vol/gcc/src/hg/master/local/gcc/ada/output.ads ada/snames.ads ada/g-dynhta.ads /vol/gcc/src/hg/master/local/gcc/ada/libgnat/s-strhas.ads /vol/gcc/src/hg/master/local/gcc/ada/libgnat/s-stalib.ads /vol/gcc/src/hg/master/local/gcc/ada/libgnat/s-exctab.ads /vol/gcc/src/hg/master/local/gcc/ada/libgnat/s-unstyp.ads /vol/gcc/src/hg/master/local/gcc/ada/libgnat/s-conca2.ads /vol/gcc/src/hg/master/local/gcc/ada/libgnat/s-assert.ads /vol/gcc/src/hg/master/local/gcc/ada/libgnat/a-assert.ads /vol/gcc/src/hg/master/local/gcc/ada/libgnat/s-secsta.ads /vol/gcc/src/hg/master/local/gcc/ada/libgnat/s-parame.ads /vol/gcc/src/hg/master/local/gcc/ada/libgnat/a-except.ads /vol/gcc/src/hg/master/local/gcc/ada/libgnat/s-traent.ads /vol/gcc/src/hg/master/local/gcc/ada/table.adb /vol/gcc/src/hg/master/local/gcc/ada/libgnat/s-memory.ads compilation abandoned make: *** [/vol/gcc/src/hg/master/local/gcc/ada/gcc-interface/Make-lang.in:166: ada/ali.o] Error 1 gdb shows gnat1 -I - -I . -I ada/generated -I ada -I /vol/gcc/src/hg/master/local/gcc/ada -I ada/libgnat -I /vol/gcc/src/hg/master/local/gcc/ada/libgnat -I ada/gcc-interface -I /vol/gcc/src/hg/master/local/gcc/ada/gcc-interface -quiet -nostdinc -O2 -Wextra -Wall -dumpdir ada/ -dumpbase ali.adb -dumpbase-ext .adb -gnatwa -fchecking=1 -g -fchecking=1 -gnatpg -gnatwns -gnata -fno-PIE -mtune=generic -march=pentium4 -gnatO ada/ali.o /vol/gcc/src/hg/master/local/gcc/ada/ali.adb -o ali.s Thread 2 received signal SIGSEGV, Segmentation fault. [Switching to Thread 1 (LWP 1)] 0x0920c153 in sem_elab.internal_representation.nts_map.mutate_and_rehash () (gdb) bt #0 0x0920c153 in sem_elab.internal_representation.nts_map.mutate_and_rehash () #1 0x09214c60
[Bug target/115028] [15 regression] gcc.target/i386/pr101950-2.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115028 Rainer Orth changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #4 from Rainer Orth --- A reghunt identified commit 9dbff9c05520a74e6cd337578f27b56c941f64f3 Author: Richard Biener Date: Tue May 7 10:14:19 2024 +0200 Revert "Revert "combine: Don't combine if I2 does not change"" as the culprit.
[Bug target/64835] -fno-ipa-cp is inconsitently supported when attributes optimize or target are used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64835 Rainer Orth changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org, ||ro at gcc dot gnu.org --- Comment #11 from Rainer Orth --- Eric, gcc.dg/ipa/iinline-attr.c XPASSes on 64-bit SPARC since commit ffabce849033e57ebaf60029822b81e981681c21 Author: Eric Botcazou Date: Tue Nov 29 11:43:32 2022 +0100 Couple of testsuite adjustments gcc/testsuite/ * gcc.dg/ipa/iinline-attr.c: XFAIL on SPARC. while the 32-bit test is XFAILed. Should we restrict the xfail to 32-bit sparc then?
[Bug tree-optimization/87332] [meta-bug] Issues related to Identical Code Folding (ICF) and Tail Merging (-ftree-tail-merge)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87332 Bug 87332 depends on bug 85656, which changed state. Bug 85656 Summary: gcc.dg/ipa/ipa-icf-38.c FAILs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85656 What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED
[Bug ipa/85656] gcc.dg/ipa/ipa-icf-38.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85656 Rainer Orth changed: What|Removed |Added Resolution|--- |FIXED Status|WAITING |RESOLVED --- Comment #16 from Rainer Orth --- Actually close as fixed.
[Bug ipa/85656] gcc.dg/ipa/ipa-icf-38.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85656 Rainer Orth changed: What|Removed |Added Assignee|ro at CeBiTec dot Uni-Bielefeld.DE |ro at gcc dot gnu.org Target Milestone|--- |15.0 URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2024-May/651 ||780.html --- Comment #15 from Rainer Orth --- Fixed for GCC 15.
[Bug c++/113719] [13/14/15 regression] g++.target/i386/pr103696.C FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113719 Rainer Orth changed: What|Removed |Added Summary|g++.target/i386/pr103696.C |[13/14/15 regression] |FAILs |g++.target/i386/pr103696.C ||FAILs --- Comment #3 from Rainer Orth --- Actually, this is a regression from GCC 12.
[Bug c++/113719] g++.target/i386/pr103696.C FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113719 Rainer Orth changed: What|Removed |Added CC||hongyuw at gcc dot gnu.org --- Comment #2 from Rainer Orth --- A reghunt identified this patch as the culprit: commit 8caf155a3d6e23e47bf55068ad23c23d4655a054 Author: Hongyu Wang Date: Sat Nov 19 09:38:00 2022 +0800 i386: Only enable small loop unrolling in backend [PR 107692]
[Bug c++/103524] [meta-bug] modules issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524 Bug 103524 depends on bug 98529, which changed state. Bug 98529 Summary: [11/12/13/14/15 Regression] g++.dg/modules/stdio-1_a.H FAILs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98529 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/98529] [11/12/13/14/15 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 Target Milestone|11.5|15.0 Resolution|--- |FIXED Status|NEW |RESOLVED Assignee|unassigned at gcc dot gnu.org |ro at gcc dot gnu.org --- Comment #12 from Rainer Orth --- Fixed for GCC 15.
[Bug c++/98529] [11/12/13/14/15 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 URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2024-May/651 ||427.html --- Comment #10 from Rainer Orth --- Patch posted.
[Bug c++/115031] g++.dg/modules/pr99023_b.X FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115031 Rainer Orth changed: What|Removed |Added CC||nathan at gcc dot gnu.org --- Comment #1 from Rainer Orth --- Nathan, any suggestion where to start looking here?
[Bug modula2/115032] gm2/iso/run/pass/packed.mod FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115032 --- Comment #1 from Rainer Orth --- The failure started on 20240205.
[Bug modula2/115032] New: gm2/iso/run/pass/packed.mod FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115032
Bug ID: 115032
Summary: gm2/iso/run/pass/packed.mod FAILs
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: modula2
Assignee: gaius at gcc dot gnu.org
Reporter: ro at gcc dot gnu.org
Target Milestone: ---
Target: sparc-sun-solaris2.11
The gm2/iso/run/pass/packed.mod test FAILs on Solaris/SPARC with a SEGV in
cc1gm2:
+FAIL: gm2/iso/run/pass/packed.mod compilation, {additional_flags= -O3
-fomit-fr
ame-pointer -finline-functions } timeout=60 (internal compiler error:
Segmentati
on Fault signal terminated program cc1gm2)
+FAIL: gm2/iso/run/pass/packed.mod compilation, {additional_flags= -O3
-fomit-fr
ame-pointer } timeout=60 (internal compiler error: Segmentation Fault signal
ter
minated program cc1gm2)
+FAIL: gm2/iso/run/pass/packed.mod compilation, {additional_flags= -Os }
timeout
=60 (internal compiler error: Segmentation Fault signal terminated program
cc1gm
2)
+UNRESOLVED: gm2/iso/run/pass/packed.mod execution, {additional_flags= -O3
-fomi
t-frame-pointer -finline-functions } timeout=60
+UNRESOLVED: gm2/iso/run/pass/packed.mod execution, {additional_flags= -O3
-fomi
t-frame-pointer } timeout=60
+UNRESOLVED: gm2/iso/run/pass/packed.mod execution, {additional_flags= -Os }
tim
eout=60
Thread 2 received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1 (LWP 1)]
build_call_expr_loc_array (loc=0, fndecl=, n=1, argarray=0xffbfcd58)
at /vol/gcc/src/hg/master/local/gcc/tree.cc:10863
10863 tree fntype = TREE_TYPE (fndecl);
(gdb) bt
#0 build_call_expr_loc_array (loc=0, fndecl=, n=1,
argarray=0xffbfcd58) at /vol/gcc/src/hg/master/local/gcc/tree.cc:10863
#1 0x0133dcc0 in build_call_expr (fndecl=, n=1)
at /vol/gcc/src/hg/master/local/gcc/tree.cc:10913
#2 0x0115c788 in build_cltz_expr (src=,
leading=, define_at_zero=)
at /vol/gcc/src/hg/master/local/gcc/tree-ssa-loop-niter.cc:2290
#3 0x0116aadc in number_of_iterations_cltz_complement (exit=,
loop=0xfa814f80, code=, niter=0xffbfd0d0)
at /vol/gcc/src/hg/master/local/gcc/tree-ssa-loop-niter.cc:2542
#4 number_of_iterations_bitcount (loop=0xfa814f80, exit=,
code=, niter=0xffbfd0d0)
at /vol/gcc/src/hg/master/local/gcc/tree-ssa-loop-niter.cc:2628
#5 number_of_iterations_exit_assumptions (loop=0xfa814f80,
exit=, niter=0xffbfd0d0, at_stmt=,
every_iteration=, body=)
at /vol/gcc/src/hg/master/local/gcc/tree-ssa-loop-niter.cc:3168
#6 0x0116cd38 in number_of_iterations_exit (loop=0xfa814f80,
exit= 13)>, niter=0xffbfd0d0, warn=false,
every_iteration=false, body=0x26a9670)
at /vol/gcc/src/hg/master/local/gcc/tree-ssa-loop-niter.cc:3257
#7 estimate_numbers_of_iterations (loop=0xfa814f80)
at /vol/gcc/src/hg/master/local/gcc/tree-ssa-loop-niter.cc:4854
#8 0x01171908 in max_loop_iterations (loop=0xfa814f80, nit=0xffbfd190)
at /vol/gcc/src/hg/master/local/gcc/tree-ssa-loop-niter.cc:4939
#9 finite_loop_p (loop=0xfa814f80)
at /vol/gcc/src/hg/master/local/gcc/tree-ssa-loop-niter.cc:3377
#10 0x010f44f4 in find_obviously_necessary_stmts (aggressive=true)
at /vol/gcc/src/hg/master/local/gcc/tree-ssa-dce.cc:509
#11 perform_tree_ssa_dce (aggressive=)
at /vol/gcc/src/hg/master/local/gcc/tree-ssa-dce.cc:2013
#12 0x010f55b8 in tree_ssa_cd_dce ()
at /vol/gcc/src/hg/master/local/gcc/tree-ssa-dce.cc:2070
#13 (anonymous namespace)::pass_cd_dce::execute (this=0x23c9530)
at /vol/gcc/src/hg/master/local/gcc/tree-ssa-dce.cc:2153
#14 0x00df19fc in execute_one_pass (pass=)
at /vol/gcc/src/hg/master/local/gcc/passes.cc:2647
#15 0x00df2470 in execute_pass_list_1 (pass=)
at /vol/gcc/src/hg/master/local/gcc/passes.cc:2756
#16 0x00df2494 in execute_pass_list_1 (
pass=)
at /vol/gcc/src/hg/master/local/gcc/passes.cc:2757
#17 0x00df24e8 in execute_pass_list (fn=0xfa856168,
pass=)
at /vol/gcc/src/hg/master/local/gcc/passes.cc:2767
#18 0x00df30ac in do_per_function_toporder (
callback=0xdf24c8 ,
data=0x23c9070) at /vol/gcc/src/hg/master/local/gcc/passes.cc:1774
#19 0x00df3350 in do_per_function_toporder (
callback=0xdf24c8 ,
data=) at /vol/gcc/src/hg/master/local/gcc/passes.cc:1741
#20 execute_ipa_pass_list (pass=)
at /vol/gcc/src/hg/master/local/gcc/passes.cc:3101
#21 0x0092df34 in ipa_passes ()
at /vol/gcc/src/hg/master/local/gcc/cgraphunit.cc:2214
#22 symbol_table::compile (this=0xfa812000)
at /vol/gcc/src/hg/master/local/gcc/cgraphunit.cc:2337
#23 0x00931d8c in symbol_table::compile (this=0xfa812000)
at /vol/gcc/src/hg/master/local/gcc/cgraphunit.cc:2315
#24 symbol_table::finalize_compilation_unit (this=0xfa812000)
at /vol/gcc/src/hg/master/local/gcc/cgraphunit.cc:2589
#25 0x00f5bb9c in compile_file ()
at /vol/gcc/src/hg/master/local/gcc/toplev.cc:476
#26 0x00f5f5ac in do_compile ()
at /vol/gcc/src/hg/master/local/
[Bug c++/115031] New: g++.dg/modules/pr99023_b.X FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115031 Bug ID: 115031 Summary: g++.dg/modules/pr99023_b.X FAILs Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org Target Milestone: --- Host: sparc-sun-solaris2.11 Target: sparc-sun-solaris2.11 Build: sparc-sun-solaris2.11 The g++.dg/modules/pr99023_b.X test FAILs on Solaris/SPARC when using a 32-bit-default compiler: FAIL: g++.dg/modules/pr99023_b.X -std=c++2a 1 blank line(s) in output FAIL: g++.dg/modules/pr99023_b.X -std=c++2a (test for excess errors) Excess errors: cc1plus: out of memory allocating 1048344 bytes after a total of 7913472 bytes Strangely, this doesn't happen with a 32-bit-default Solaris/x86 compiler. The failure (I haven't checked the specifics) goes back as far as 20210219.
[Bug target/115028] [15 regression] gcc.target/i386/pr101950-2.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115028 Rainer Orth changed: What|Removed |Added Target|i386-pc-solaris2.11 |i386-pc-solaris2.11, ||x86_64-pc-linux-gnu --- Comment #3 from Rainer Orth --- I'm seeing this on Linux/x86_64, too.
[Bug target/115028] [15 regression] gcc.target/i386/pr101950-2.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115028 --- Comment #2 from Rainer Orth --- Created attachment 58171 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58171=edit gcc-14 assembler input
[Bug target/115028] [15 regression] gcc.target/i386/pr101950-2.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115028 --- Comment #1 from Rainer Orth --- Created attachment 58170 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58170=edit trunk assembler input
[Bug target/115028] New: [15 regression] gcc.target/i386/pr101950-2.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115028 Bug ID: 115028 Summary: [15 regression] gcc.target/i386/pr101950-2.c FAILs Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org Target Milestone: --- Target: i386-pc-solaris2.11 Between 20240506 (80c03ac8041340b29325f86ed58ea8bd40a55b99) and 20240507 (bf10f0db20db1598157505b373098bc93c66b915), the 64-bit gcc.target/i386/pr101950-2.c test regressed on Solaris/x86: FAIL: gcc.target/i386/pr101950-2.c scan-assembler-times \\txor[ql]\\t 2 There are 3 instances of xor[ql] now instead of the expected two: xorq%rax, %rdi xorl%eax, %edi xorl%eax, %eax where the gcc-14 branch has xorq%rdi, %rax xorl%edi, %eax The additional one is from @@ -20,8 +20,9 @@ .LFB1: movl%edi, %eax sarl$31, %eax - xorl%edi, %eax - lzcntl %eax, %eax + xorl%eax, %edi + xorl%eax, %eax + lzcntl %edi, %eax subl$1, %eax ret .LFE1: I'm attaching both gcc-14 and trunk assembler output.
[Bug c++/98529] [11/12/13/14/15 Regression] g++.dg/modules/stdio-1_a.H FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98529 --- Comment #9 from Rainer Orth --- I see it's a common issue on Solaris: instead of the expected Depset:0 decl entity:204 function_decl:'::fprintf' as found on Linux, we have Depset:0 decl entity:26 function_decl:'::std::printf' What's the best way to handle this: just allow for the alternative form in the scan-lang-dump?
[Bug analyzer/107750] [13/14/15 Regression] Many gcc.dg/analyzer/fd-*.c tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107750 --- Comment #6 from Rainer Orth --- David, after your amazing work on PR analyzer/111475, there are only a handful of analyzer failures left on trunk: FAIL: gcc.dg/analyzer/fd-accept.c (test for excess errors) FAIL: gcc.dg/analyzer/fd-accept.c final event at line 58 (test for warnings, line 57) FAIL: gcc.dg/analyzer/fd-accept.c warning (test for warnings, line 57) FAIL: gcc.dg/analyzer/fd-access-mode-target-headers.c (test for warnings, line 19) FAIL: gcc.dg/analyzer/fd-access-mode-target-headers.c (test for warnings, line 27) FAIL: gcc.dg/analyzer/fd-access-mode-target-headers.c (test for warnings, line 32) FAIL: gcc.dg/analyzer/fd-access-mode-target-headers.c (test for warnings, line 39) FAIL: gcc.dg/analyzer/fd-access-mode-target-headers.c (test for warnings, line 55) FAIL: gcc.dg/analyzer/fd-access-mode-target-headers.c (test for excess errors) FAIL: gcc.dg/analyzer/fd-connect.c (test for warnings, line 35) FAIL: gcc.dg/analyzer/fd-datagram-socket.c (test for warnings, line 13) FAIL: gcc.dg/analyzer/fd-datagram-socket.c (test for warnings, line 32) FAIL: gcc.dg/analyzer/fd-datagram-socket.c (test for warnings, line 38) FAIL: gcc.dg/analyzer/fd-datagram-socket.c (test for warnings, line 50) FAIL: gcc.dg/analyzer/fd-datagram-socket.c (test for warnings, line 72) FAIL: gcc.dg/analyzer/fd-datagram-socket.c (test for warnings, line 83) FAIL: gcc.dg/analyzer/fd-datagram-socket.c (test for warnings, line 86) FAIL: gcc.dg/analyzer/fd-datagram-socket.c (test for warnings, line 94) FAIL: gcc.dg/analyzer/fd-datagram-socket.c (test for warnings, line 98) FAIL: gcc.dg/analyzer/fd-datagram-socket.c (test for excess errors) FAIL: gcc.dg/analyzer/fd-datagram-socket.c final event at line 110 (test for warnings, line 109) FAIL: gcc.dg/analyzer/fd-datagram-socket.c final event at line 88 (test for warnings, line 87) FAIL: gcc.dg/analyzer/fd-datagram-socket.c warning (test for warnings, line 109) FAIL: gcc.dg/analyzer/fd-datagram-socket.c warning (test for warnings, line 87) FAIL: gcc.dg/analyzer/fd-glibc-byte-stream-connection-server.c (test for excess errors) FAIL: gcc.dg/analyzer/fd-listen.c (test for excess errors) FAIL: gcc.dg/analyzer/fd-listen.c final event at line 55 (test for warnings, line 54) FAIL: gcc.dg/analyzer/fd-listen.c warning (test for warnings, line 54) FAIL: gcc.dg/analyzer/fd-socket-misuse.c (test for warnings, line 18) FAIL: gcc.dg/analyzer/fd-socket-misuse.c (test for excess errors) FAIL: gcc.dg/analyzer/fd-socket-misuse.c final event at line 22 (test for warnings, line 21) FAIL: gcc.dg/analyzer/fd-socket-misuse.c warning (test for warnings, line 21) FAIL: gcc.dg/analyzer/fd-stream-socket-active-open.c (test for warnings, line 21) FAIL: gcc.dg/analyzer/fd-stream-socket-active-open.c (test for warnings, line 32) FAIL: gcc.dg/analyzer/fd-stream-socket-active-open.c (test for warnings, line 39) FAIL: gcc.dg/analyzer/fd-stream-socket-active-open.c (test for warnings, line 47) FAIL: gcc.dg/analyzer/fd-stream-socket-active-open.c (test for excess errors) FAIL: gcc.dg/analyzer/fd-stream-socket-passive-open.c (test for warnings, line 27) FAIL: gcc.dg/analyzer/fd-stream-socket-passive-open.c (test for warnings, line 35) FAIL: gcc.dg/analyzer/fd-stream-socket-passive-open.c (test for warnings, line 41) FAIL: gcc.dg/analyzer/fd-stream-socket-passive-open.c (test for warnings, line 46) FAIL: gcc.dg/analyzer/fd-stream-socket-passive-open.c (test for excess errors) FAIL: gcc.dg/analyzer/fd-stream-socket.c (test for warnings, line 13) FAIL: gcc.dg/analyzer/fd-stream-socket.c (test for warnings, line 37) FAIL: gcc.dg/analyzer/fd-stream-socket.c (test for warnings, line 70) FAIL: gcc.dg/analyzer/fd-stream-socket.c (test for warnings, line 81) FAIL: gcc.dg/analyzer/fd-stream-socket.c (test for warnings, line 92) As an example, I looked into fd-accept.c, which shows those differences between Linux and Solaris output: --- /homes/ro/fd-accept.out.i.linux 2024-05-08 13:19:07.595246605 +0200 +++ fd-accept.out.i 2024-05-08 13:23:30.986283368 +0200 @@ -23,2 +23,2 @@ -/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/analyzer/fd-accept.c:57:3: warning: ‘accept’ on datagram socket file descriptor ‘fd’ [-Wanalyzer-fd-type-mismatch] -/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/analyzer/fd-accept.c:54:12: note: (1) datagram socket created here +/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/analyzer/fd-accept.c:57:3: warning: ‘accept’ on file descriptor ‘fd’ in wrong phase [CWE-666] [-Wanalyzer-fd-phase-mismatch] +/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/analyzer/fd-accept.c:54:12: note: (1) socket created here @@ -28 +28 @@ -/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/analyzer/fd-accept.c:57:3: note: (5) ‘accept’ expects a stream socket file descriptor but ‘fd’ is a datagram socket +/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/analyzer/fd-accept.c:57:3: note: (5) ‘accept’ expects a listening stream socket
[Bug middle-end/114912] [15 regression] SIGBUS in wi::copy<> on SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114912 --- Comment #4 from Rainer Orth --- Created attachment 58081 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58081=edit preprocessed input
[Bug middle-end/114912] [15 regression] SIGBUS in wi::copy<> on SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114912 --- Comment #3 from Rainer Orth --- (In reply to Aldy Hernandez from comment #1) > Since this happens while building libgcc during stage1, perhaps this can be > reproduced with a cross? Would it be possible to get the preprocessed file > that's failing? I doubt this can be seen in a cross: running the compilation under truss reveals the SIGBUS as 2834: Incurred fault #5, FLTACCESS %pc = 0x00723E58 2834: siginfo: SIGBUS BUS_ADRALN addr=0xFFBFC954 2834: Received signal #10, SIGBUS [caught] 2834: siginfo: SIGBUS BUS_ADRALN addr=0xFFBFC954 i.e. an unaligned access. While SPARC is a strict-alignment target, x86 cares little if any about alignment at all. > You could try /var/gcc/reghunt/sigbus-range/288807/./gcc/xgcc -save-temps > [blah blah], and attach the libgcc2.i file that gets generated. Sure, please find _muldi3.i attached. cc1 invocation is cc1 -fpreprocessed _muldi3.i -quiet -dumpbase _muldi3.c -dumpbase-ext .c -mcpu=v9 -g -g -g -O2 -O2 -O2 -Wextra -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -version -fbuilding-libgcc -fno-stack-protector -fPIC -fvisibility=hidden -o _muldi3.s
[Bug middle-end/114912] [15 regression] SIGBUS in wi::copy<> on SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114912 Rainer Orth changed: What|Removed |Added Target Milestone|--- |15.0
[Bug middle-end/114912] New: [15 regression] SIGBUS in wi::copy<> on SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114912 Bug ID: 114912 Summary: [15 regression] SIGBUS in wi::copy<> on SPARC Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: aldyh at gcc dot gnu.org Target Milestone: --- Target: sparc-sun-solaris2.11 Between 20240430 (0b2735e0797fee9b4ec5cd74f22afe0483f888dd) and 20240501 (c3bc2787b8beb7aae67fdf2a7f7271a9a4edca7c), Solaris/SPARC bootstrap began to fail with a SIGBUS in cc1 compiling stage 1 libgcc. E.g. /var/gcc/reghunt/sigbus-range/288807/./gcc/xgcc -B/var/gcc/reghunt/sigbus-range/288807/./gcc/ -B/usr/local/sparc-sun-solaris2.11/bin/ -B/usr/local/sparc-sun-solaris2.11/lib/ -isystem /usr/local/sparc-sun-solaris2.11/include -isystem /usr/local/sparc-sun-solaris2.11/sys-include-g -O2 -O2 -g -O2 -DIN_GCC -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fPIC -I. -I. -I../.././gcc -I/var/gcc/reghunt/master/libgcc -I/var/gcc/reghunt/master/libgcc/. -I/var/gcc/reghunt/master/libgcc/../gcc -I/var/gcc/reghunt/master/libgcc/../include -o _muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep -DL_muldi3 -c /var/gcc/reghunt/master/libgcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS during GIMPLE pass: evrp /var/gcc/reghunt/master/libgcc/libgcc2.c: In function ‘__muldi3’: /var/gcc/reghunt/master/libgcc/libgcc2.c:538:1: internal compiler error: Bus Error 538 | } | ^ 0xf26783 crash_signal /var/gcc/reghunt/master/gcc/toplev.cc:319 0x723e58 void wi::copy > >(wide_int_storage&, generic_wide_int > const&) /var/gcc/reghunt/master/gcc/wide-int.h:2191 0x723e58 wide_int_storage& wide_int_storage::operator=(wi::hwi_with_prec const&) /var/gcc/reghunt/master/gcc/wide-int.h:1247 0x723e58 generic_wide_int& generic_wide_int::operator=(wi::hwi_with_prec const&) /var/gcc/reghunt/master/gcc/wide-int.h:1002 0x723e58 irange_bitmask::set_unknown(unsigned int) /var/gcc/reghunt/master/gcc/value-range.h:163 0x723e58 irange::set_varying(tree_node*) /var/gcc/reghunt/master/gcc/value-range.h:1067 0x13680db gimple_range_global(vrange&, tree_node*, function*) /var/gcc/reghunt/master/gcc/value-query.cc:419 0x136954f global_range_query::range_of_expr(vrange&, tree_node*, gimple*) /var/gcc/reghunt/master/gcc/value-query.cc:436 0x1ad000b fur_stmt::get_operand(vrange&, tree_node*) /var/gcc/reghunt/master/gcc/gimple-range-fold.cc:162 0x1ad5edb fold_using_range::range_of_range_op(vrange&, gimple_range_op_handler&, fur_source&) /var/gcc/reghunt/master/gcc/gimple-range-fold.cc:673 0x1ad831f fold_using_range::fold_stmt(vrange&, gimple*, fur_source&, tree_node*) /var/gcc/reghunt/master/gcc/gimple-range-fold.cc:604 0x1ad8927 fold_range(vrange&, gimple*, range_query*) /var/gcc/reghunt/master/gcc/gimple-range-fold.cc:324 0x1ac8727 ranger_cache::get_global_range(vrange&, tree_node*, bool&) /var/gcc/reghunt/master/gcc/gimple-range-cache.cc:1054 0x1abefaf gimple_ranger::range_of_stmt(vrange&, gimple*, tree_node*) /var/gcc/reghunt/master/gcc/gimple-range.cc:323 0x1367d2f range_query::value_of_stmt(gimple*, tree_node*) /var/gcc/reghunt/master/gcc/value-query.cc:133 0x1315c3f rvrp_folder::value_of_stmt(gimple*, tree_node*) /var/gcc/reghunt/master/gcc/tree-vrp.cc:1001 0x11ab12f substitute_and_fold_dom_walker::before_dom_children(basic_block_def*) /var/gcc/reghunt/master/gcc/tree-ssa-propagate.cc:820 0x1a4df83 dom_walker::walk(basic_block_def*) /var/gcc/reghunt/master/gcc/domwalk.cc:311 0x11a9d07 substitute_and_fold_engine::substitute_and_fold(basic_block_def*) /var/gcc/reghunt/master/gcc/tree-ssa-propagate.cc:999 0x13132f7 execute_ranger_vrp(function*, bool, bool) /var/gcc/reghunt/master/gcc/tree-vrp.cc:1066 A reghunt identified commit c60b3e211c555706cdc2dc8bfcdd540152cff350 Author: Aldy Hernandez Date: Tue Apr 30 19:39:00 2024 +0200 Reduce startup costs for Value_Range. as the culprit.
[Bug modula2/114886] gm2 testsuite arbitrarily reduces timeouts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114886 Rainer Orth changed: What|Removed |Added Assignee|gaius at gcc dot gnu.org |ro at gcc dot gnu.org --- Comment #4 from Rainer Orth --- Fixed for GCC 15.
[Bug modula2/114886] gm2 testsuite arbitrarily reduces timeouts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114886 Rainer Orth changed: What|Removed |Added URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2024-April/6 ||50222.html Status|UNCONFIRMED |NEW Last reconfirmed||2024-04-30 Target Milestone|--- |14.2 Ever confirmed|0 |1 --- Comment #2 from Rainer Orth --- Proper patch posted.
[Bug modula2/114886] gm2 testsuite arbitrarily reduces timeouts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114886 --- Comment #1 from Rainer Orth --- Created attachment 58068 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58068=edit Hack to identify places that reduce timeouts.
[Bug modula2/114886] New: gm2 testsuite arbitrarily reduces timeouts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114886 Bug ID: 114886 Summary: gm2 testsuite arbitrarily reduces timeouts Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: modula2 Assignee: gaius at gcc dot gnu.org Reporter: ro at gcc dot gnu.org Target Milestone: --- When bootstrapping the gcc-14 branch on sparc-sun-solaris2.11, quite a number of gm2 tests FAILed due to timeouts. I had seen this before and could trace this to the gm2 testsuite reducing way beyond the default of 300 seconds (sometimes as low as 10 seconds). I think this is badly misguided for a couple of reasons: * If a test completes (PASS or FAIL) within the reduced reduced timeout, it will do so with the default timeout, too. * If a test takes either longer than the default timeout (either because compilation of execution is particularly slow or because some step loops indefinitely), reducing the timeout would give a result earlier. However, I've rarely if ever seen such a case in all my testing. * If a test takes longer than the reduced timeout, it will fail while it would pass just fine with the default timeout. * Using hardcoded timeouts is always wrong: while the values currenly used may work one some particular target, it will cause failures on systems that are either slower or under higher load. Besides, it is possible to globally change the derfault in some expect snippet (like global board_info set board_info(unix,gcc,timeout) 600 (even differently per multilib if desired). IMO this whole approach is completely misguided, has very little benefit even in the best case, and demonstrably introduces failures that wouldn't exist without it. I'm attaching my current hack for reference, but it's completely inappropriate as is. It only identifies some (all?) places that need changing.
[Bug analyzer/111475] [14/15 regression] Many C++ analyzer tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111475 Rainer Orth changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||rguenth at gcc dot gnu.org --- Comment #8 from Rainer Orth --- I wonder what to do about this PR for GCC 14: * It increased analyzer failures from 92 on the gcc-13 branch to 1482 on trunk. * This is a massive regression for sparc-sun-solaris2.11, a primary target. * I never got any response from either the patch author or David as analyzer maintainer. In the worst case, I guess it's better to disable the analyzer testsuite on Solaris rather than having this insane amount of noise. Thoughts?
[Bug analyzer/111475] [14 regression] Many C++ analyzer tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111475 Rainer Orth changed: What|Removed |Added Last reconfirmed||2024-04-23 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #7 from Rainer Orth --- A reghunt identified this patch as the culprit: commit 55f6a7d949abc708d1c6ebc01eb3053f96d1472b Author: benjamin priour Date: Sun Aug 27 14:36:14 2023 +0200 analyzer: Move gcc.dg/analyzer tests to c-c++-common (1) [PR96395]
[Bug analyzer/111475] [14 regression] Many C++ analyzer tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111475 Rainer Orth changed: What|Removed |Added Summary|Many C++ analyzer tests |[14 regression] Many C++ |FAIL|analyzer tests FAIL --- Comment #6 from Rainer Orth --- This actually is a regression from GCC 13: with the as1-sol2.ii testcase, GCC 13 cc1plus produces the same output as on Linux, while GCC 14 cc1plus differs as described.
[Bug gcov-profile/114720] New: gcc.misc-tests/gcov-22.c loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114720 Bug ID: 114720 Summary: gcc.misc-tests/gcov-22.c loops Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: gcov-profile Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org Target Milestone: --- Target: sparc*-sun-solaris2.11, sparc64-unknown-linux-gnu The new gcc.misc-tests/gcov-22.c test loops on Solaris/SPARC (32 and 64-bit) and Linux/sparc64: WARNING: gcc.misc-tests/gcov-22.c execution test program timed out. +FAIL: gcc.misc-tests/gcov-22.c execution test +FAIL: gcc.misc-tests/gcov-22.c gcov: 0 failures in line counts, 0 in branch percentages, 32 in condition/decision, 0 in return percentages, 0 in intermediate format [...] truss -u reveals the test loops in longjmp like this: /1@1: -> libc:longjmp(0x25450, 0x1, 0xffbfe9e8, 0x12b04) /1@1: <- libc:longjmp() = 1 /1@1: -> libc:longjmp(0x25450, 0x1, 0xffbfe9e8, 0x12b04) /1@1: <- libc:longjmp() = 1 [...] I'm astonished the test works anywere, actually. AFAICS, the issue is this: setdest -> setjmp returns 0 setdest returns 2 -> jump -> longjmp make setdest return 1 -> jump -> longjmp ... continuing ad infinitum.
[Bug go/114584] New: go.test/test/nil.go FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114584
Bug ID: 114584
Summary: go.test/test/nil.go FAILs
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: go
Assignee: ian at airs dot com
Reporter: ro at gcc dot gnu.org
Target Milestone: ---
Target: sparc-sun-solaris2.11
The 32-bit go.test/test/nil.go test FAILs on Solaris/SPARC:
FAIL: go.test/test/nil.go execution, -O2 -g
SIGABRT: abort
PC=0xfd799dc4 m=0 sigcode=4294967295
goroutine 1 [running]:
__lwp_sigqueue
:0
Thread 5 received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1 (LWP 1)]
main.arraytest..func1 ()
at /vol/gcc/src/hg/master/local/gcc/testsuite/go.test/test/nil.go:91
91 for i, v := range p {
(gdb) bt
#0 main.arraytest..func1 ()
at /vol/gcc/src/hg/master/local/gcc/testsuite/go.test/test/nil.go:91
#1 0x00014e74 in main.shouldPanic (f=0x64de2c)
at /vol/gcc/src/hg/master/local/gcc/testsuite/go.test/test/nil.go:56
#2 0x000154d0 in main.arraytest ()
at /vol/gcc/src/hg/master/local/gcc/testsuite/go.test/test/nil.go:90
#3 main.main ()
at /vol/gcc/src/hg/master/local/gcc/testsuite/go.test/test/nil.go:44
(gdb) cont
Continuing.
SIGSEGV: segmentation violation
PC=0x14b3c m=0 sigcode=0
[Bug go/114583] New: go.test/test/fixedbugs/issue4562.go FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114583
Bug ID: 114583
Summary: go.test/test/fixedbugs/issue4562.go FAILs
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: go
Assignee: ian at airs dot com
Reporter: ro at gcc dot gnu.org
Target Milestone: ---
Target: sparc-sun-solaris2.11
go.test/test/fixedbugs/issue4562.go FAILs on 32-bit Solaris/SPARC:
panic: runtime error: invalid memory address or nil pointer dereference
[recovered]
panic: crashed at line 20, wanted line 22
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x0]
goroutine 1 [running]:
main.expectError
/vol/gcc/src/hg/master/local/gcc/testsuite/go.test/test/fixedbugs/issue4562.go:33
panic
/vol/gcc/src/hg/master/local/libgo/go/runtime/panic.go:708
main.main
/vol/gcc/src/hg/master/local/gcc/testsuite/go.test/test/fixedbugs/issue4562.go:20
gdb shows
Thread 5 received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1 (LWP 1)]
main.main ()
at
/vol/gcc/src/hg/master/local/gcc/testsuite/go.test/test/fixedbugs/issue4562.go:22
22 switch pT.val { // error should be here - line 22
(gdb) bt
#0 main.main ()
at
/vol/gcc/src/hg/master/local/gcc/testsuite/go.test/test/fixedbugs/issue4562.go:22
(gdb) cont
Continuing.
SIGSEGV: segmentation violation
PC=0x13be8 m=0 sigcode=0
goroutine 1 [running]:
main.main
/vol/gcc/src/hg/master/local/gcc/testsuite/go.test/test/fixedbugs/issue4562.go:20
[Bug go/114582] New: go.test/test/fixedbugs/issue34123.go FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114582 Bug ID: 114582 Summary: go.test/test/fixedbugs/issue34123.go FAILs Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: ro at gcc dot gnu.org Target Milestone: --- Target: sparc-sun-solaris2.11 The go.test/test/fixedbugs/issue34123.go test FAILs on 32-bit Solaris/SPARC since it was introduced: FAIL: go.test/test/fixedbugs/issue34123.go execution, -O2 -g SIGABRT: abort PC=0xfd799dc4 m=5 sigcode=4294967295 goroutine 1 [running]: __lwp_sigqueue :0 As with PR go/114581, under gdb the code path is different: Thread 5 received signal SIGSEGV, Segmentation fault. [Switching to Thread 1 (LWP 1)] 0x00013a8c in main.f () at /vol/gcc/src/hg/master/local/gcc/testsuite/go.test/test/fixedbugs/issue34123.go:24 24 *q = 12 // line 24 (gdb) bt #0 0x00013a8c in main.f () at /vol/gcc/src/hg/master/local/gcc/testsuite/go.test/test/fixedbugs/issue34123.go:24 #1 0x00013adc in main.main () at /vol/gcc/src/hg/master/local/gcc/testsuite/go.test/test/fixedbugs/issue34123.go:42 (gdb) p q $1 = (uint8 *) 0x0 (gdb) cont Continuing. SIGSEGV: segmentation violation PC=0x13600 m=0 sigcode=0 goroutine 1 [running]: main.f /vol/gcc/src/hg/master/local/gcc/testsuite/go.test/test/fixedbugs/issue34123.go:24 main.main /vol/gcc/src/hg/master/local/gcc/testsuite/go.test/test/fixedbugs/issue34123.go:42 This could well be a gdb issue, however: dbx behaves differently: t@1 (l@1) signal SEGV (no mapping at the fault address) in main.f at 0x13600 0x00013600: f+0x000c: stb %g2, [%g1] (dbx) cont -sig SEGV t@1 (l@1) signal ABRT (Abort) in __lwp_sigqueue at 0xfd799dc4 0xfd799dc4: __lwp_sigqueue+0x0008: bcc,a,pt %icc,__lwp_sigqueue+0x18 ! 0xfd799dd4 (dbx) where current thread: t@1 =>[1] __lwp_sigqueue(0x0, 0x1, 0x6, 0x0, 0x, 0x0), at 0xfd799dc4 [2] raise(0x6, 0x6, 0x5, 0x0, 0x0, 0x0), at 0xfd6d7570 [3] abort(0xfe362cd4, 0xfd7ec000, 0x64cae8, 0x474f, 0x41c180, 0x64d01c), at 0xfd6a87b8 hidden frames, use 'where -h' to see them all [6] throwException(0x400500, 0x0, 0x7, 0xff1e5950, 0xfe0e0758, 0xff1e0318), at 0xfe363748 [7] gopanic(0x64d54c, 0x1, 0x696020, 0xfeec51f0, 0x400500, 0x64de48), at 0xfe9252e0 [8] panicmem(0xb, 0x64d8d0, 0x0, 0x0, 0xff, 0x64d6a0), at 0xfe9036fc [9] sigpanic(0x0, 0x64d8d0, 0x0, 0x0, 0x0, 0x400500), at 0xfe90708c [10] sigtrampgo(0xb, 0x64dd60, 0x64da80, 0x88, 0x64d8d0, 0x400500), at 0xfe91a46c [11] __sighndlr(0xb, 0x64dd60, 0x64da80, 0xfe362cd4, 0x0, 0x1), at 0xfd794ee0 called from signal handler with signal 11 (SIGSEGV) -- [12] main.f(0x64de48, 0x64de46, 0x13a30, 0x64de47, 0x6b20c0, 0x400500), at 0x13600 [13] main.main(0x418128, 0xfeec51f0, 0x418130, 0x400500, 0x64de60, 0x400500), at 0x13ce0 [14] main(0xfeec0fcc, 0xfeec1b48, 0x40a138, 0x418440, 0x64dee2, 0xfe92a8e0), at 0xfe92e7f8 [15] kickoff(0x0, 0x4007c8, 0xfe92952c, 0x0, 0x4007a4, 0x400500), at 0xfe925834
[Bug go/114581] New: go.test/test/fixedbugs/issue22881.go FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114581 Bug ID: 114581 Summary: go.test/test/fixedbugs/issue22881.go FAILs Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: ro at gcc dot gnu.org Target Milestone: --- Target: sparc-sun-solaris2.11 The go.test/test/fixedbugs/issue22881.go test FAILs on 32-bit Solaris/SPARC since it was added: FAIL: go.test/test/fixedbugs/issue22881.go execution, -O2 -g failed to rethrow unwind exception (reason=5) SIGABRT: abort PC=0xfd799dc4 m=0 sigcode=4294967295 goroutine 1 [running]: __lwp_sigqueue :0 Weirdly, the test FAILs differently when run under gdb: hread 6 received signal SIGSEGV, Segmentation fault. [Switching to Thread 1 (LWP 1)] main.f0 (m=0x9120a0) at /vol/gcc/src/hg/master/local/gcc/testsuite/go.test/test/fixedbugs/issue22881.go:51 51 m[0] = *p (gdb) p p $1 = (int *) 0x0 (gdb) bt #0 main.f0 (m=0x9120a0) at /vol/gcc/src/hg/master/local/gcc/testsuite/go.test/test/fixedbugs/issue22881.go:51 #1 0x0001470c in main.main..func1 () at /vol/gcc/src/hg/master/local/gcc/testsuite/go.test/test/fixedbugs/issue22881.go:23 #2 0x00014d5c in main.main () at /vol/gcc/src/hg/master/local/gcc/testsuite/go.test/test/fixedbugs/issue22881.go:19 (gdb) cont Continuing. SIGSEGV: segmentation violation PC=0x14454 m=0 sigcode=0 goroutine 1 [running]: main.f0 /vol/gcc/src/hg/master/local/gcc/testsuite/go.test/test/fixedbugs/issue22881.go:51 main.main..func1 /vol/gcc/src/hg/master/local/gcc/testsuite/go.test/test/fixedbugs/issue22881.go:23 main.main /vol/gcc/src/hg/master/local/gcc/testsuite/go.test/test/fixedbugs/issue22881.go:19 The 64-bit test is fine, however.
[Bug go/52357] 64bit-out.go and go.test/test/cmplxdivide.go time out on Solaris/SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52357 Rainer Orth changed: What|Removed |Added Status|SUSPENDED |NEW --- Comment #7 from Rainer Orth --- Unfortunately, the issue persists on current trunk: 32-bit-default gccgo, sparc-sun-solaris2.11 (SPARC S7-2): real3:07.71 user3:05.92 sys0.89 32-bit-default gccgo, sparc-sun-solaris2.11 (SPARC T8-1): real1:18.05 user1:16.50 sys0.38 Given that the compile time is close to the default limit (5m) even on an unloaded machine, the test is almost guaranteed to FAIL under load. S7-2 -ftime-report output: Time variable usr sys wall GGC phase parsing : 0.59 ( 0%) 0.02 ( 2%) 0.61 ( 0%) 2575k ( 2%) phase opt and generate : 145.88 (100%) 0.79 ( 96%) 146.88 (100%) 113M ( 98%) phase last asm : 0.02 ( 0%) 0.01 ( 1%) 0.02 ( 0%) 230k ( 0%) garbage collection : 0.37 ( 0%) 0.04 ( 5%) 0.56 ( 0%) 0 ( 0%) dump files : 0.02 ( 0%) 0.00 ( 0%) 0.00 ( 0%) 0 ( 0%) callgraph construction : 0.06 ( 0%) 0.00 ( 0%) 0.04 ( 0%) 1070k ( 1%) callgraph optimization : 0.01 ( 0%) 0.00 ( 0%) 0.02 ( 0%) 0 ( 0%) callgraph ipa passes : 1.93 ( 1%) 0.06 ( 7%) 1.99 ( 1%) 2573k ( 2%) ipa dead code removal : 0.00 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 0 ( 0%) ipa inlining heuristics: 0.01 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 0 ( 0%) cfg construction : 0.02 ( 0%) 0.00 ( 0%) 0.02 ( 0%) 8896 ( 0%) cfg cleanup: 0.01 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 176 ( 0%) CFG verifier : 2.58 ( 2%) 0.00 ( 0%) 2.60 ( 2%) 0 ( 0%) trivially dead code: 0.22 ( 0%) 0.00 ( 0%) 0.22 ( 0%) 0 ( 0%) df scan insns : 0.11 ( 0%) 0.01 ( 1%) 0.11 ( 0%) 7392 ( 0%) df live regs : 0.15 ( 0%) 0.00 ( 0%) 0.14 ( 0%) 0 ( 0%) df reg dead/unused notes : 0.17 ( 0%) 0.00 ( 0%) 0.17 ( 0%) 2353k ( 2%) register information : 0.04 ( 0%) 0.00 ( 0%) 0.05 ( 0%) 0 ( 0%) alias analysis : 0.17 ( 0%) 0.00 ( 0%) 0.18 ( 0%) 2053k ( 2%) rebuild jump labels: 0.09 ( 0%) 0.00 ( 0%) 0.09 ( 0%) 0 ( 0%) parser (global): 0.59 ( 0%) 0.02 ( 2%) 0.61 ( 0%) 2574k ( 2%) inline parameters : 0.06 ( 0%) 0.00 ( 0%) 0.06 ( 0%) 4768 ( 0%) tree gimplify : 0.17 ( 0%) 0.00 ( 0%) 0.17 ( 0%) 7786k ( 7%) tree eh: 0.02 ( 0%) 0.00 ( 0%) 0.00 ( 0%) 8960 ( 0%) tree CFG construction : 0.02 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 60k ( 0%) tree CFG cleanup : 0.01 ( 0%) 0.00 ( 0%) 0.00 ( 0%) 0 ( 0%) tree SSA other : 0.00 ( 0%) 0.01 ( 1%) 0.00 ( 0%) 0 ( 0%) tree SSA rewrite : 0.04 ( 0%) 0.03 ( 4%) 0.08 ( 0%) 512k ( 0%) tree SSA incremental : 0.02 ( 0%) 0.00 ( 0%) 0.03 ( 0%) 480k ( 0%) tree operand scan : 0.16 ( 0%) 0.05 ( 6%) 0.18 ( 0%) 2205k ( 2%) tree SSA verifier : 1.09 ( 1%) 0.00 ( 0%) 1.12 ( 1%) 0 ( 0%) tree STMT verifier : 1.57 ( 1%) 0.00 ( 0%) 1.59 ( 1%) 0 ( 0%) callgraph verifier : 0.07 ( 0%) 0.00 ( 0%) 0.04 ( 0%) 0 ( 0%) dominance computation : 0.03 ( 0%) 0.00 ( 0%) 0.04 ( 0%) 0 ( 0%) out of ssa : 0.02 ( 0%) 0.00 ( 0%) 0.04 ( 0%) 4472 ( 0%) expand vars: 0.03 ( 0%) 0.01 ( 1%) 0.05 ( 0%) 2955k ( 2%) expand : 0.49 ( 0%) 0.01 ( 1%) 0.51 ( 0%) 26M ( 23%) post expand cleanups : 0.07 ( 0%) 0.00 ( 0%) 0.07 ( 0%) 12k ( 0%) integrated RA : 48.45 ( 33%) 0.05 ( 6%) 48.48 ( 33%) 24M ( 21%) LRA non-specific : 4.00 ( 3%) 0.03 ( 4%) 3.99 ( 3%) 27M ( 24%) LRA virtuals elimination : 0.26 ( 0%) 0.00 ( 0%) 0.28 ( 0%) 45k ( 0%) LRA reload inheritance : 1.85 ( 1%) 0.01 ( 1%) 1.88 ( 1%) 6286k ( 5%) LRA create live ranges : 2.49 ( 2%) 0.00 ( 0%) 2.49 ( 2%) 2592k ( 2%) LRA hard reg assignment: 74.81 ( 51%) 0.51 ( 62%) 75.34 ( 51%) 0 ( 0%)
[Bug go/106813] getSiginfo() libgo/runtime/go-signal.c missing Solaris specific code to get ret.sigpc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106813 --- Comment #2 from Rainer Orth --- Created attachment 57848 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57848=edit Alternative patch.
[Bug go/106813] getSiginfo() libgo/runtime/go-signal.c missing Solaris specific code to get ret.sigpc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106813 Rainer Orth changed: What|Removed |Added CC||ro at gcc dot gnu.org --- Comment #1 from Rainer Orth --- FWIW I had a similar patch in my local tree for years, but neglected to submit it (among others because it lacked dumpregs support. While going over the remaining go.test failures recently, I noted some that might be related, so I completed the patch (attached). A few notes: * I've used the customary __sun__ && __svr4__ guard for Solaris-specific code, not __sun && __SVR4 which is only used in runtime/go-libmain.c. * I've reused the Linux/x86_64 code in dumpregs for Solaris. Only a few adjustments were necessary, but this still seemed better than replicating the whole section. * I've added SPARC support, too. Since gregs[] is almost identical between 32 and 64-bit, I've just used different formats for printing 32 and 64-bit registers, again to avoid massive duplication. * When testing on Debian/sparc64, the 64-bit version there reguired an ugly variation: the general-purpose member of mcontext_t is called mc_gregs instead of gregs, and the indices are named MC_* instead of REG_* (although the names are identical with one exception). I have no idea what rid them to do this, but at least my code does compile and run there. The patch has been tested on i386-pc-solaris2.11, sparc-sun-solaris2.11, x86_64-pc-linux-gnu, and sparc64-unknown-linux-gnu (32 and 64-bit each). There were no regressions, but compared to a vanilla tree there where no new PASSes either.
[Bug go/114500] New: go.test/test/fixedbugs/issue23781.go FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114500 Bug ID: 114500 Summary: go.test/test/fixedbugs/issue23781.go FAILs Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: ro at gcc dot gnu.org Target Milestone: --- Host: i386-pc-solaris2.11 Target: amd64-pc-solaris2.11 Build: i386-pc-solaris2.11 The go.test/test/fixedbugs/issue23781.go test FAILs on Solaris/x86 with a 32-bit-default compiler, but targetting 64-bit x86: FAIL: go.test/test/fixedbugs/issue23781.go -O (test for excess errors) Excess errors: /vol/gcc/src/hg/master/local/gcc/testsuite/go.test/test/fixedbugs/issue23781.go:10:17: error: index value overflow The test just PASSes when using a 64-bit-default compiler instead.
[Bug go/114463] New: go.test/test/fixedbugs/issue4458.go FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114463 Bug ID: 114463 Summary: go.test/test/fixedbugs/issue4458.go FAILs Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: ro at gcc dot gnu.org Target Milestone: --- Target: i?86-pc-solaris2.11, sparcv9-sun-solaris2.11 The go.test/test/fixedbugs/issue4458.go FAILs on Solaris in a weird way: FAIL: issue4458.go -O (test for errors, line 19) FAIL: issue4458.go -O (test for excess errors) The issue happens both for a 32-bit-default x86 compiler, generating either 32 or 64-bit-code: Excess errors: issue4458.go:19: error: method 'foo' is ambiguous A 64-bit-default x86 compiler is fine,though. OTOH on sparc, a 32-bit default compiler is fine while a 64-bit-default compiler shows the same issue.
[Bug go/114454] New: go.test/test/fixedbugs/issue27836.go FAILs with LANG=C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114454 Bug ID: 114454 Summary: go.test/test/fixedbugs/issue27836.go FAILs with LANG=C Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: ro at gcc dot gnu.org Target Milestone: --- When running the Go testsuite with LANG=C (or any non-UTF-8 locale, I suppose), go.test/test/fixedbugs/issue27836.go FAILs: FAIL: go.test/test/fixedbugs/issue27836.dir/Äfoo.go -O -I. (test for excess errors) Excess errors: go1: fatal error: cannot open /vol/gcc/src/hg/master/local/gcc/testsuite/go.test/test/fixedbugs/issue27836.dir/Ã<84>foo.go: No such file or directory compilation terminated. FAIL: go.test/test/fixedbugs/issue27836.dir/Ämain.go -O -I. (test for excess errors) Excess errors: go1: fatal error: cannot open /vol/gcc/src/hg/master/local/gcc/testsuite/go.test/test/fixedbugs/issue27836.dir/Ã<84>main.go: No such file or directory compilation terminated. It seems the test assumes an UTF-8 locale, but takes no precautions to guarantee that.
[Bug go/114453] New: 32-bit go.test/test/fixedbugs/issue16016.go FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114453 Bug ID: 114453 Summary: 32-bit go.test/test/fixedbugs/issue16016.go FAILs Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: ro at gcc dot gnu.org Target Milestone: --- Target: i386-pc-solaris2.11, sparc-sun-solaris2.11, i686-pc-linux-gnu The 32-bit go.test/test/fixedbugs/issue16016.go FAILs on most (all?) targets: FAIL: go.test/test/fixedbugs/issue16016.go execution, -O2 -g On Solaris, the error is like runtime: out of memory: cannot allocate 4194304-byte block (3779067904 in use) fatal error: out of memory while on Linux/i686 I get unable to allocate additional stack space: errno 1 SIGABRT: abort PC=0xf7ed3d99 m=6 sigcode=4294967290
[Bug d/114434] gdc.test/runnable/test23514.d FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114434 Rainer Orth changed: What|Removed |Added Target|amd64-pc-solaris2.11, |i386-pc-solaris2.11, |sparcv9-sun-solaris2.11 |sparc-sun-solaris2.11, ||i386-apple-darwin1[15], ||i686-pc-linux-gnu --- Comment #1 from Rainer Orth --- I just noticed that this only happens for a 32-bit-default compiler, and is also seen on Darwin/i386 and Linux/i686.
[Bug d/114434] gdc.test/runnable/test23514.d FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114434 Rainer Orth changed: What|Removed |Added Target Milestone|--- |14.0
[Bug d/114434] New: gdc.test/runnable/test23514.d FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114434 Bug ID: 114434 Summary: gdc.test/runnable/test23514.d FAILs Product: gcc Version: 14.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: amd64-pc-solaris2.11, sparcv9-sun-solaris2.11 The gdc.test/runnable/test23514.d test FAILs on Solaris (64-bit only) since its introduction: FAIL: gdc.test/runnable/test23514.d execution test FAIL: gdc.test/runnable/test23514.d -shared-libphobos execution test core.exception.AssertError@runnable/test23514.d(12): Assertion failure /vol/gcc/src/hg/master/local/libphobos/libdruntime/rt/deh.d:51 _d_createTrace [0x4dbeeb] /vol/gcc/src/hg/master/local/libphobos/libdruntime/gcc/deh.d:484 _d_throw [0x4c54b9] /vol/gcc/src/hg/master/local/libphobos/libdruntime/core/exception.d:556 onAssertError [0x4a536c] ??:? _Dmain [0x4a0ee6] The weird thing is that performing the comparison in gdb works.
[Bug tree-optimization/96147] [11 regression] gcc.dg/vect/slp-43.c etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96147 Rainer Orth changed: What|Removed |Added Resolution|--- |FIXED Status|REOPENED|RESOLVED --- Comment #14 from Rainer Orth --- gcc.dg/vect/bb-slp-32.c XPASSes avoided as discussed in https://gcc.gnu.org/pipermail/gcc-patches/2024-March/648142.html and followups.
[Bug target/114150] gcc.target/i386/avx512cd-vpbroadcastmb2q-2.c etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114150 Rainer Orth changed: What|Removed |Added URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2024-March/6 ||48140.html Target Milestone|--- |14.0 Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |ro at gcc dot gnu.org --- Comment #2 from Rainer Orth --- Fixed for GCC 14.0.1.
[Bug target/114416] SPARC V9 struct return with floating-point members violates ABI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114416 --- Comment #1 from Rainer Orth --- Created attachment 57757 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57757=edit testcase
[Bug target/114416] SPARC V9 struct return with floating-point members violates ABI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114416 Rainer Orth changed: What|Removed |Added Target Milestone|--- |14.0
[Bug target/114416] New: SPARC V9 struct return with floating-point members violates ABI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114416 Bug ID: 114416 Summary: SPARC V9 struct return with floating-point members violates ABI Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: ebotcazou at gcc dot gnu.org Target Milestone: --- Target: sparc*-sun-solaris2.11 I've been informed of a case where gcc generates code for struct return with floating-point members that violates the SPARC V9 ABI (SCD 2.4.1): consider the attached testcase: $ gcc -m64 -O2 -c fpret.c $ cc -m64 -O2 caller.c $ gcc -m64 -o cc-gcc caller.o fpret.o $ ./cc-gcc sum2: x[0] = -nan x[1] = -nan sum2x: x = 0 y = 1 With gcc, sum2 places the return value into %o0/%o1 sum2() sum2: 9c 03 bf 60 add %sp, -0xa0, %sp sum2+0x4: 90 10 20 00 clr %o0 sum2+0x8: 92 10 23 ff mov 0x3ff, %o1 sum2+0xc: 93 2a 70 34 sllx %o1, 0x34, %o1 sum2+0x10: 81 c3 e0 08 retl sum2+0x14: 9c 03 a0 a0 add %sp, 0xa0, %sp while cc uses %d0/%d2 instead: sum2() sum2: 1b 00 00 00 sethi %hi(0x0), %o5 sum2+0x4: 81 b0 0c 00 fzerod%d0 sum2+0x8: c1 3b a8 7f std %d0, [%sp + 0x87f] sum2+0xc: 98 13 60 00 or%o5, 0x0, %o4 sum2+0x10: 97 2b 30 0c sllx %o4, 0xc, %o3 sum2+0x14: c5 1a e0 00 ldd [%o3], %d2 sum2+0x18: 81 c3 e0 08 retl sum2+0x1c: c5 3b a8 87 std %d2, [%sp + 0x887] I believe this in line with SCD 2.4.1: * 3P-13 states Structure or Union return values Structure and union return types up to thirty-two bytes in size are returned in registers. The registers are assigned as if the value was being passed as the first argument to a function with a known prototype. * and p. 3P-12 has Structure or union types larger than eight bytes, and up to sixteen bytes in size are assigned to two consecutive parameter array words, and align according to the alignment requirements of the structure or at least to an eight-byte boundary. * If I read the table on p. 3P-11 correctly, those parameter array words should map to %d0/%d2 for double args, just as cc does.
[Bug testsuite/96109] [11 Regression] gcc.dg/vect/slp-47.c etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96109 --- Comment #18 from Rainer Orth --- SPARC testsuite failures fixed for GCC 14.0.1.
[Bug tree-optimization/113557] gcc.dg/vect/vect-multi-peel-gaps.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113557 Rainer Orth changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2024-March/6 ||47558.html Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |ro at gcc dot gnu.org --- Comment #4 from Rainer Orth --- Fixed for GCC 14.0.1.
[Bug tree-optimization/114071] gcc.dg/vect/pr37027.c etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114071 Rainer Orth changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2024-March/6 ||47558.html Assignee|unassigned at gcc dot gnu.org |ro at gcc dot gnu.org Target Milestone|--- |14.0 --- Comment #3 from Rainer Orth --- Fixed for GCC 14.0.1.
[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 Assignee|unassigned at gcc dot gnu.org |ro at gcc dot gnu.org Target Milestone|11.5|14.0 Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2024-March/6 ||47559.html --- Comment #8 from Rainer Orth --- Fixed for GCC 14.0.1.
[Bug analyzer/110483] [14 Regression] Several gcc.dg/analyzer/out-of-bounds-diagram-*.c tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110483
Rainer Orth changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed||2024-02-29
Resolution|FIXED |---
Status|RESOLVED|REOPENED
--- Comment #5 from Rainer Orth ---
Thanks for the patch. Last night's bootstrap showed that all C tests PASS now.
However, two of the tests FAIL when compiled as C++:
FAIL: c-c++-common/analyzer/out-of-bounds-diagram-3.c -std=c++98 (test for
warnings, line 25)
FAIL: c-c++-common/analyzer/out-of-bounds-diagram-3.c -std=c++98 at line 20
(test for warnings, line 19)
FAIL: c-c++-common/analyzer/out-of-bounds-diagram-3.c -std=c++98 expected
multiline pattern lines 30-45
and same for -std=c++(14|17|20). When compiling manually, there's no output at
all.
There's also
FAIL: c-c++-common/analyzer/out-of-bounds-diagram-11.c -std=c++98 (test for
warnings, line 12)
FAIL: c-c++-common/analyzer/out-of-bounds-diagram-11.c -std=c++98 expected
multiline pattern lines 18-36
Here's the full output:
/vol/gcc/src/hg/master/local/gcc/testsuite/c-c++-common/analyzer/out-of-bounds-diagram-11.c:
In function ‘void test7(std::size_t)’:
/vol/gcc/src/hg/master/local/gcc/testsuite/c-c++-common/analyzer/out-of-bounds-diagram-11.c:41:47:
warning: allocated buffer size is not a multiple of the pointee's size
[CWE-131] [-Wanalyzer-allocation-size]
/vol/gcc/src/hg/master/local/gcc/testsuite/c-c++-common/analyzer/out-of-bounds-diagram-11.c:41:47:
note: (1) allocated ‘((size * 4) + 3)’ bytes and assigned to ‘int32_t*’ {aka
‘int*’} here; ‘sizeof (int32_t {aka int})’ is ‘4’
/vol/gcc/src/hg/master/local/gcc/testsuite/c-c++-common/analyzer/out-of-bounds-diagram-11.c:42:13:
warning: stack-based buffer overflow [CWE-121] [-Wanalyzer-out-of-bounds]
/vol/gcc/src/hg/master/local/gcc/testsuite/c-c++-common/analyzer/out-of-bounds-diagram-11.c:41:47:
note: (1) capacity: ‘((size * 4) + 3)’ bytes
/vol/gcc/src/hg/master/local/gcc/testsuite/c-c++-common/analyzer/out-of-bounds-diagram-11.c:42:13:
note: (2) write of 4 bytes at offset ‘(size * 4)’ exceeds the buffer
┌───┐
│ write of ‘(int) 42’ │
└───┘
│ │
│ │
v v
┌──┐┌──┐
│ buffer allocated on stack at (1) ││after valid range │
└──┘└──┘
├┬─┤├┬─┤
│ │
╭───┴──╮ ╭─┴╮
│capacity: ‘size * 4 + 3’ bytes│ │overflow of 1 byte│
╰──╯ ╰──╯
/vol/gcc/src/hg/master/local/gcc/testsuite/c-c++-common/analyzer/out-of-bounds-diagram-11.c:
In function ‘char* test99(const char*, const char*)’:
/vol/gcc/src/hg/master/local/gcc/testsuite/c-c++-common/analyzer/out-of-bounds-diagram-11.c:80:25:
warning: heap-based buffer overflow [CWE-122] [-Wanalyzer-out-of-bounds]
/vol/gcc/src/hg/master/local/gcc/testsuite/c-c++-common/analyzer/out-of-bounds-diagram-11.c:74:44:
note: (1) capacity: ‘(len_x + len_y)’ bytes
/vol/gcc/src/hg/master/local/gcc/testsuite/c-c++-common/analyzer/out-of-bounds-diagram-11.c:75:3:
note: (2) following ‘false’ branch (when ‘result’ is non-NULL)...
/vol/gcc/src/hg/master/local/gcc/testsuite/c-c++-common/analyzer/out-of-bounds-diagram-11.c:77:20:
note: (3) ...to here
/vol/gcc/src/hg/master/local/gcc/testsuite/c-c++-common/analyzer/out-of-bounds-diagram-11.c:80:25:
note: (4) out-of-bounds write
I'm uncertain if this isn't another issue, though.
[Bug d/114155] gdc.test/runnable/literal.d FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114155 Rainer Orth changed: What|Removed |Added Target Milestone|--- |14.0
[Bug d/114155] New: gdc.test/runnable/literal.d FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114155 Bug ID: 114155 Summary: gdc.test/runnable/literal.d FAILs Product: gcc Version: 14.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 gdc.test/runnable/literal.d FAILs on 32 and 64-bit Solaris/SPARC since it was installed: +UNRESOLVED: gdc.test/runnable/literal.d compilation failed to produce executable +UNRESOLVED: gdc.test/runnable/literal.d -shared-libphobos compilation failed to produce executable runnable/literal.d:262:5: error: static assert: '"x\"1122334455667788AABBCCDDEEFF0099\"" == "x\"88776655443322119900FFEEDDCCBBAA\""' is false compiler exited with status 1 Seems like an endianess to me.
[Bug testsuite/113685] [14 regression] gcc.dg/vect/vect-117.c fails profile checking with Invalid sum after r14-4089-gd45ddc2c04e471
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113685 --- Comment #3 from Rainer Orth --- Created attachment 57567 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57567=edit 64-bit sparc-sun-solaris2.11 vect-117.c.265t.optimized
[Bug testsuite/113685] [14 regression] gcc.dg/vect/vect-117.c fails profile checking with Invalid sum after r14-4089-gd45ddc2c04e471
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113685 Rainer Orth changed: What|Removed |Added CC||ro at gcc dot gnu.org Host|powerpc64le-linux-gnu |powerpc64le-linux-gnu, ||sparc*-sun-solaris2.11 Build|powerpc64le-linux-gnu |powerpc64le-linux-gnu, ||sparc*-sun-solaris2.11 Target|powerpc64le-linux-gnu |powerpc64le-linux-gnu, ||sparc*-sun-solaris2.11 --- Comment #2 from Rainer Orth --- The same issue exists on 64-bit Solaris/SPARC: +FAIL: gcc.dg/vect/vect-117.c -flto -ffat-lto-objects scan-tree-dump-not optimized "Invalid sum" +FAIL: gcc.dg/vect/vect-117.c scan-tree-dump-not optimized "Invalid sum"
[Bug testsuite/102954] [12/13/14 regression] gcc.dg/vect/pr33804.c XPASSes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102954 --- Comment #7 from Rainer Orth --- Created attachment 57566 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57566=edit 64-bit sparc-sun-solaris2.11 slp-multitypes-3.c.179t.vect
[Bug testsuite/102954] [12/13/14 regression] gcc.dg/vect/pr33804.c XPASSes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102954 --- Comment #6 from Rainer Orth --- Created attachment 57565 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57565=edit 64-bit sparc-sun-solaris2.11 pr33804.c.179t.vect The issue persists as of 20240228.
