[Bug other/115211] [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 --- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #1 from Richard Biener --- > This was done on purpose, you can use -help=optimizers now I think. The thread I cited rather suggested is was removed because Martin argued the info wasn't fully complete. However, I don't see how something that is only 95% complete is worse than having nothing. --help=optimizers just documents optimization options, with no indication which are enabled for a given compilation. Don't see how this helps.
[Bug target/114148] gcc.target/i386/pr106010-7b.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114148 --- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #4 from Hongtao Liu --- > (In reply to r...@cebitec.uni-bielefeld.de from comment #3) [...] > uoops, does below patch fix the testcase on Solaris/x86? > >memcpy (pd_src, p_init, 2 * N * sizeof (double)); > - memcpy (ps_dst, p_init, 2 * N * sizeof (float)); > - memcpy (epi64_dst, p_init, 2 * N * sizeof (long long)); > - memcpy (epi32_dst, p_init, 2 * N * sizeof (int)); > - memcpy (epi16_dst, p_init, 2 * N * sizeof (short)); > - memcpy (epi8_dst, p_init, 2 * N * sizeof (char)); > + memcpy (ps_src, p_init, 2 * N * sizeof (float)); > + memcpy (epi64_src, p_init, 2 * N * sizeof (long long)); > + memcpy (epi32_src, p_init, 2 * N * sizeof (int)); > + memcpy (epi16_src, p_init, 2 * N * sizeof (short)); > + memcpy (epi8_src, p_init, 2 * N * sizeof (char)); It does indeed: tested 32 and 64-bit, and, for good measure, with all allocators I tried before, too. Thanks.
[Bug target/114148] gcc.target/i386/pr106010-7b.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114148
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ---
To investigate further, I've added comparison functions to a reduced
version of pr106010-7b.c, with
void
cmp_epi8 (_Complex unsigned char* a, _Complex unsigned char* b)
{
for (int i = 0; i != N; i++)
if (a[i] != b[i])
{
printf ("cmp_epi8: i = %d: a[i].r = %x a[i].i = %x b[i].r = %x b[i].i =
%x\n",
i, __real__ a[i], __imag__ a[i], __real__ b[i], __imag__ b[i]);
}
}
This shows (when using _Complex unsigned char since on Solaris, char is
signed by default)
cmp_epi8: i = 76: a[i].r = 0 a[i].i = 0 b[i].r = 88 b[i].i = 33
cmp_epi8: i = 77: a[i].r = 0 a[i].i = 0 b[i].r = 6 b[i].i = 8
cmp_epi8: i = 80: a[i].r = 0 a[i].i = 0 b[i].r = 3 b[i].i = 0
I've also noticed that the test result depends on the implementation of
malloc used:
* With Solaris libc malloc, libmalloc, and watchmalloc, the test aborts.
* However, when using one of libbsdmalloc, libmapmalloc, libmtmalloc, or
libumem, the test works.
However, ISTM that the test is simply bogus: in avx_test
* epi8_src, epi8_dst are allocated with malloc, buffer contents undefined
* epi8_dst is cleared
* epi8_dst is initialized from p_init
* in foo_epi8, epi8_src[0] (an undefined value) is copied into first N
elements of epi8_dst
* epi8_dst is compared to epi8_src (with the remaining members of epi8_src
still undefined)
Why on earth would the rest of epi8_dst and epi8_src be identical if
epi8_src was never initialized?
[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 #6 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE Uni-Bielefeld.DE> --- >> --- Comment #4 from Jonathan Wakely --- > >> It's possible that all the lambda frames are inlined, or skip+2 in >> stacktrace.cc causes us to skip real frames that we should keep, or maybe >> libbacktrace just doesn't work on this target. [...] > The stacktrace failures only happen on 32-bit x86; 64-bit x86 is fine. > > I'm now trying a debug build and plan to compare i386 and amd64 side by > side to find differences. While that didn't produce anything useful, I noticed that both libbacktrace and its testcases are built with -funwind-tables. Checking what gcc does for that option, here's what I found: * 64-bit x86 defaults to -fasynchronous-unwind-tables, thus implicitly -funwind-tables, too. For that reason, the stacktrace tests PASS on both Linux/x86_64 and Solaris/amd64. * 32-bit x86 defaults to -fasynchronous-unwind-tables *if* -fomit-frame-pointer is enabled. This is the case on Linux/i686, thus the PASSes, while Solaris/i386 defaults to -fno-omit-frame-pointer, thus the FAILs observed. * Solaris never enables -funwind-tables by default, thus the FAILs on both Solaris/SPARC and Linux/SPARC. When I manually rebuild libstdc++-v3/src/libbacktrace with -g3 -O0 -funwind-tables and a testcase, too, it PASSes. The question is how to proceed, though: while one could enable -funwind-tables unconditionally in src/libbacktrace/Makefile.am (it's done this way in other runtimes libs) and add -funwind-tables to the affected testcases using dg-additional-options, I wonder if that produces a satisfying user experience in the end. Maybe it's better to just default to -funwind-tables in g++ instead?
[Bug c++/57025] Solaris g++ defines __STDC_VERSION__=199901L
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57025 --- Comment #12 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #11 from Alan Coopersmith --- > While Solaris 11.3 support has been dropped from gcc now, Jonathan Perkins > from pkgsrc found that just removing the definition of __STDC_VERSION__ > didn't work with some of the illumos headers: > https://github.com/jperkin/notes/blob/main/gcc-cpp-stdc/README.md Unfortunately, the Illumos guys have refused to cooperate with upstream GCC and LLVM for years, never tried to upstream patches, perform testing, report results or anything. Unless they suddenly start testing, analysis, and provide patches, I'm not willing to do their work for them. I simply don't have the 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 --- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #4 from Jonathan Wakely --- > It's possible that all the lambda frames are inlined, or skip+2 in > stacktrace.cc causes us to skip real frames that we should keep, or maybe > libbacktrace just doesn't work on this target. In the Solaris case, the libbacktrace tests all PASS on all of 32 and 64-bit SPARC and x86. The stacktrace failures only happen on 32-bit x86; 64-bit x86 is fine. I'm now trying a debug build and plan to compare i386 and amd64 side by side to find differences.
[Bug tree-optimization/114072] gcc.dg/vect/vect-pr111779.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114072
--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #4 from rguenther at suse dot de ---
[...]
>> I think the best we can do then is
>>
>> /* { dg-skip-if "PR tree-optimization/114072" { be && { ! vect_shift_char }
>> } }
>> */
>>
>> Lets the test become UNSUPPORTED on 32 and 64-bit SPARC, but still PASS
>> as before on 32 and 64-bit x86.
>
> Can we instead guard the scan-tree-dump? This way the correctness
> execute part still is exercised?
Sure, even if the result is somewhat hard to read with all those levels
of braces:
/* { dg-final { scan-tree-dump "LOOP VECTORIZED" "vect" { target { vect_int &&
{ le || { be && vect_shift_char } } } } } } */
This way, all of compile, execute, and scan are run on x86, while on
sparc it's only compile, execute.
[Bug tree-optimization/114072] gcc.dg/vect/vect-pr111779.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114072
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #2 from Richard Biener ---
> Hmm, is solaris-sparc big-endian? It seems so. That makes the bitfield
It is indeed.
> access require a VnQImode logical right shift (but little-endian doesn't
> require it - it's actually bitfield endianess that matters).
>
> There is vect_shift_char you could use and somehow conditionalize that
> on big-endianess.
I think the best we can do then is
/* { dg-skip-if "PR tree-optimization/114072" { be && { ! vect_shift_char } } }
*/
Lets the test become UNSUPPORTED on 32 and 64-bit SPARC, but still PASS
as before on 32 and 64-bit x86.
[Bug ada/115168] [15 regression] Several libada compile errors on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115168 --- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #2 from Eric Botcazou --- > Created attachment 58255 > --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58255=edit > Tentative fix Both i386-pc-solaris2.11 and sparc-sun-solaris2.11 bootstraps are well into make check now. Thanks.
[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 --- Comment #9 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #6 from Eric Botcazou --- >> as of r15-644, Ada bootstrap succeeded on i686-darwin9 and 17. > > Great! Same on i386-pc-solaris2.11. >> I do not known whether that means the issue is actually fixed by recent Ada >> commits, or that it's now just become latent. > > Ada commits have nothing to do with it though, the breakage and the probable > fix both came from recent optimization changes. I'm practically certain that this is due to Richard's recent fix for PR middle-end/115110, so it's not latent.
[Bug ada/115133] [15 regression] s-oslock__solaris.ads doesn't compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115133 --- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #6 from Eric Botcazou --- > Created attachment 58230 > --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58230=edit > Tentative fix > > Hopefully the final version of it. Yes, make all-target-libada completed just fine with this. Thanks!
[Bug ada/115133] [15 regression] s-oslock__solaris.ads doesn't compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115133 --- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #4 from Eric Botcazou --- > Created attachment 58229 > --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58229=edit > Tentative fix > > The complete version of it. Thanks. There's one issue left: s-tasini.adb:248:11: warning: default initialization of "Lock" may modify overlaid storage [-gnatwo] s-tasini.adb:248:11: warning: use pragma Import for "Lock" to suppress initialization (RM B.1(24)) [-gnatwo] s-tasini.adb:260:11: warning: default initialization of "Lock" may modify overlaid storage [-gnatwo] s-tasini.adb:260:11: warning: use pragma Import for "Lock" to suppress initialization (RM B.1(24)) [-gnatwo] s-tasini.adb:272:11: warning: default initialization of "Lock" may modify overlaid storage [-gnatwo] s-tasini.adb:272:11: warning: use pragma Import for "Lock" to suppress initialization (RM B.1(24)) [-gnatwo] s-tasini.adb:284:11: warning: default initialization of "Lock" may modify overlaid storage [-gnatwo] s-tasini.adb:284:11: warning: use pragma Import for "Lock" to suppress initialization (RM B.1(24)) [-gnatwo]
[Bug ada/115133] [15 regression] s-oslock__solaris.ads doesn't compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115133 --- Comment #1 from ro at CeBiTec dot Uni-Bielefeld.DE --- > 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. There's a 2-space indentation instead of the expected 3 spaces. I had to look several times to see it, though. Maybe the error could be clearer? After that, I run into s-taprop.adb:1402:20: error: expected type "System.Os_Locks.RTS_Lock_Ptr" s-taprop.adb:1402:20: error: found type "System.Task_Primitives.Lock_Ptr" s-taprop.adb:1443:57: error: expected type "System.Task_Primitives.Lock_Ptr" s-taprop.adb:1443:57: error: found type "System.Os_Locks.RTS_Lock_Ptr" s-taprop.adb:1471:20: error: expected type "System.Os_Locks.RTS_Lock_Ptr" s-taprop.adb:1471:20: error: found type "System.Task_Primitives.Lock_Ptr" s-taprop.adb:1552:57: error: expected type "System.Task_Primitives.Lock_Ptr" s-taprop.adb:1552:57: error: found type "System.Os_Locks.RTS_Lock_Ptr" make[6]: *** [../gcc-interface/Makefile:306: s-taprop.o] Error 1 but am stuck.
[Bug ipa/114985] [15 regression] internal compiler error: in discriminator_fail during stage2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114985 --- Comment #31 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #29 from Aldy Hernandez --- [...] > Ok, what's the minimum configuration I need to build here? > > srcdir/configure --build=sparc-sun-solaris2.11 > > srcdir/configure --build=sparc-sun-solaris2.11 --without-gnu-as > --without-gnu-ld > > ?? srcdir/configure --build=sparcv9-sun-solaris2.11 --without-gnu-as --with-as=/usr/bin/as --without-gnu-ld --with-ld=/usr/bin/ld should do the trick. Preferably prepend /usr/gnu/bin to PATH. > I really don't care how it builds, I just want the bare minimum so I can > bootstrap and run tests. > > A minor rant, but why can't all this be set up automatically in the compile > farm machines? Keeping track of minor nuances of each architecture is > distracting. They should all be set up, whether by setting default paths in Agreed, but you always run into stuff like this when leaving Linux (like AIX, HP-UX, or macOS). PATHs won't help much for reasons explained in install.texi. > /etc/profile or whatever, or by having the relevant patches in GCC's source > base, such that they work with src/configure && make. But what should be the default: GNU or native tools? You have choices here and need to decide what you need/want. No one can do this for you. > I know this isn't your fault, but if more cfarm boxes where set up to go with > no surprises, I'd add more boxen to my testing harness. Well, I *did* set up the Solaris cfarm systems, actually ;-) I see your point, but things are not that simple unfortunately. And GCC's configure doesn't need to cater to users of the cfarm only... Some of the issues (like the need for --build) have been caused by upstream (like the config.guess maintainers that refuse to listen to reason ;-). I thought about improving the --with-as/ld situation; maybe something can be done there.
[Bug ipa/114985] [15 regression] internal compiler error: in discriminator_fail during stage2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114985 --- Comment #28 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #27 from Aldy Hernandez --- > This is in cfarm216.cfarm.et: > > aldyh@s11-sparc:~/bld/clean$ hostname > s11-sparc.cfarm > aldyh@s11-sparc:~/bld/clean$ uname -a > SunOS s11-sparc.cfarm 5.11 11.4.68.164.2 sun4v sparc sun4v logical-domain > aldyh@s11-sparc:~/bld/clean$ ~/src/clean/configure && gmake -j80 && gmake > check > -k -j80 You need to be careful that the assembler and linker actually used match gcc's idea thereof: https://gcc.gnu.org/install/specific.html#x-x-solaris2 Best specify all of --build sparcv9-sun-solaris2.11 (if you're bootstrapping with a 64-bit-default gcc/g++) and --with-as=/usr/gnu/bin/as (or /opt/cfarm/binutils-latest-64/bin/as) --with-gnu-as (/usr/bin/as works too, but you need to specify both the path and --without-gnu-as) --with-ld=/usr/bin/ld --without-gnu-ld Having two different assemblers and linkers (Solaris and GNU) available can lead to confusion if you rely on PATH alone. > gmake[3]: Leaving directory '/home/aldyh/bld/clean' > Comparing stages 2 and 3 > Bootstrap comparison failure! > gcc/tree-vect-stmts.o differs I'm not seeing this myself.
[Bug ipa/114985] [15 regression] internal compiler error: in discriminator_fail during stage2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114985 --- Comment #26 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #25 from Aldy Hernandez --- > prange has been enabled again, after testing on x86-64 and ppc64le linux. > Aarch has no space to run tests on the compile farm, and sparc bootstrap was > already broken. Huh? Current trunk bootstraps just fine on Solaris/SPARC without any patches. What issue do you see? Besides, there *is* a Solaris/SPARC system in the cfarm (cfarm216), so you can try for yourself.
[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
--- Comment #12 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #11 from Tom de Vries ---
> (In reply to Rainer Orth from comment #10)
[...]
>> 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.
>
> This looks like test-case issue, so re-closing the PR.
True, but it's often way simpler to discuss testcase issues in the
original PR rather than open new PRs for every single issue with a
testcase (and there's already been the comment character one here).
> How about:
> ...
> -/* { dg-final { scan-assembler {\.byte\t0xb\t[^\n\r]* Define macro strx} } }
> */
> +/* { dg-final { scan-assembler {\.byte\t0xb\t[^\n\r]* Define macro
> strx|\.byte\t0x1\t[^\n\r]* Define macro}
> ...
> ?
Seems like an option, too (and would work on other affected targets
should they appear). Tested on sparc-sun-solaris2.11 with as and gas.
Btw., I wonder which of the targets currently skipped with "split DWARF
unsupported" are instances of this problem, too: Solaris doesn't support
-gsplit-dwarf, still the test PASSes on Solaris/SPARC with gas and
Solaris/x86 with either assembler.
[Bug c++/113719] [13/14/15 regression] g++.target/i386/pr103696.C FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113719 --- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #4 from Hongyu Wang --- [...] > Could you try the attachment and see if the error was solved? I tested with I just bootstrapped with the patch included on i386-pc-solaris2.11 and the failure is gone for both 32 and 64-bit. Thanks. > cross-compiled solaris gcc but it has some error on varasm with 64bit so I'm > not sure it can pass all 32/64bit test. FWIW, there's now a Solaris/x86 cfarm system (cfarm215), just in case you ever need one ;-)
[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 #8 from ro at CeBiTec dot Uni-Bielefeld.DE --- When I hack locally to avoid the indirection in the definitions of the SOCK_* constants, only two gcc.dg/analyzer/fd-*.c tests FAIL on Solaris: 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) Excess errors: /vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/analyzer/fd-access-mode-target-headers.c:55:3: warning: named constant 'O_ACCMODE' has unknown value (included from ) has #define O_ACCMODE (O_SEARCH | O_EXEC | 0x3) which analyzer cannot handle (not a simple numeric constant; same issue as with SOCK_*). Linux/glibc has instead #define O_ACCMODE 0003 FAIL: gcc.dg/analyzer/fd-glibc-byte-stream-connection-server.c (test for excess errors) Excess errors: /vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/analyzer/fd-glibc-byte-stream-connection-server.c:91:3: error: implicit declaration of function 'memset' [-Wimplicit-function-declaration] Solaris has #define FD_ZERO(__p)(void) memset((__p), 0, sizeof (*(__p))) While one certainly could argue that the header should be self-contained, it's easy enough to just include in the test to avoid this.
[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 #7 from ro at CeBiTec dot Uni-Bielefeld.DE --- I think I've found what's going on: really has #if !defined(_XPG4_2) || defined(__EXTENSIONS__) #ifndef NC_TPI_CLTS #define NC_TPI_CLTS 1 /* must agree with netconfig.h */ #define NC_TPI_COTS 2 /* must agree with netconfig.h */ [...] #if !defined(_XPG4_2) || defined(__EXTENSIONS__) #define SOCK_STREAM NC_TPI_COTS /* stream socket */ #define SOCK_DGRAM NC_TPI_CLTS /* datagram socket */ [...] #else #define SOCK_STREAM 2 /* stream socket */ #define SOCK_DGRAM 1 /* datagram socket */ The problem seems to be the indirection: when SOCK_DGRAM etc. are defined as numeric constants, things work, while the indirection via NC_TPI_* does not.
[Bug target/112959] install.tex needs updates on FreeBSD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112959 --- Comment #13 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #11 from Gerald Pfeifer --- > (In reply to r...@cebitec.uni-bielefeld.de from comment #6) >> What's there looks good to me. > > Cool, thank you. I cherry picked the changes I made to the GCC 14 > branch, so they should be in the GCC 14.2 release. Great, thanks. >> However, one issue mentioned in PR target/112959 is missing, namely the >> problem of getting a working Ada bootstrap compiler. I have no idea if >> gnat12 has been fixed since and is now able to build Ada on trunk/the >> gcc-14 branch. Otherwise, the old GNAT 6.4.1 worked for me, but this >> isn't easy to find. > > Looking at the lang/gnat12 and now lang/gcc13 ports and recent changes > including ones like [...] > (which was a few days after this report was filed) I am hopefully it would > work. However, I cannot guarantee. > > I am temped to mark this report as RESOLVED based on my changes. I tend to agree: if someone runs into GNAT problems in the future, they can report them anew.
[Bug ipa/114985] [15 regression] internal compiler error: in discriminator_fail during stage2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114985 --- Comment #13 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #12 from Aldy Hernandez --- > Created attachment 58168 > --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58168=edit > proposed patch in testing I just tried bootstrapping on sparc-sun-solaris2.11 with this patch and commit 36e877996936abd8bd08f8b1d983c8d1023a5842 Author: Aldy Hernandez Date: Tue May 7 14:05:50 2024 +0200 Enable prange support. reapplied. It ICEs in stage 2: Unsupported operand combination in dispatch: RO_PII during IPA pass: inline In file included from /vol/gcc/src/hg/master/solaris/gcc/c/c-parser.cc:26971: ./gt-c-c-parser.h:94:2: internal compiler error: in discriminator_fail, at range-op.cc:205 94 | }; | ^ 0x218a05b range_op_handler::discriminator_fail(vrange const&, vrange const&, vrange const&) const /vol/gcc/src/hg/master/solaris/gcc/range-op.cc:205 0x218a313 range_op_handler::fold_range(vrange&, tree_node*, vrange const&, vrange const&, relation_trio) const /vol/gcc/src/hg/master/solaris/gcc/range-op.cc:229 0x3569d2f ipa_vr_operation_and_type_effects /vol/gcc/src/hg/master/solaris/gcc/ipa-cp.cc:1663 0x356a337 ipa_value_range_from_jfunc(vrange&, ipa_node_params*, cgraph_edge*, ipa_jump_func*, tree_node*) /vol/gcc/src/hg/master/solaris/gcc/ipa-cp.cc:1759 0x1e1cbef evaluate_properties_for_edge(cgraph_edge*, bool, unsigned int*, unsigned int*, ipa_auto_call_arg_values*, bool) /vol/gcc/src/hg/master/solaris/gcc/ipa-fnsummary.cc:684 0x1e4ea47 do_estimate_edge_size(cgraph_edge*) /vol/gcc/src/hg/master/solaris/gcc/ipa-inline-analysis.cc:337 0x1e4fcff estimate_edge_size(cgraph_edge*) /vol/gcc/src/hg/master/solaris/gcc/ipa-inline.h:79 0x1e4fdbb estimate_edge_growth(cgraph_edge*) /vol/gcc/src/hg/master/solaris/gcc/ipa-inline.h:100 0x1e4f033 do_estimate_growth_1 /vol/gcc/src/hg/master/solaris/gcc/ipa-inline-analysis.cc:436 0x1971d87 cgraph_node::call_for_symbol_and_aliases(bool (*)(cgraph_node*, void*), void*, bool) /vol/gcc/src/hg/master/solaris/gcc/cgraph.h:3429 0x1e4f2a7 estimate_growth(cgraph_node*) /vol/gcc/src/hg/master/solaris/gcc/ipa-inline-analysis.cc:474 0x359d46f inline_small_functions /vol/gcc/src/hg/master/solaris/gcc/ipa-inline.cc:2081 0x35a1083 ipa_inline /vol/gcc/src/hg/master/solaris/gcc/ipa-inline.cc:2850 0x35a24b3 execute /vol/gcc/src/hg/master/solaris/gcc/ipa-inline.cc:3248
[Bug tree-optimization/114912] [15 regression] SIGBUS in wi::copy<> on SPARC since r15-88-gc60b3e211c5557 since char array is not aligned to what it needs to be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114912 --- Comment #18 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #16 from Aldy Hernandez --- > (In reply to r...@cebitec.uni-bielefeld.de from comment #14) >> > --- Comment #13 from Aldy Hernandez --- >> > BTW, I'm waiting for a review, or at least a nod from a C++ savvy >> > person here: >> > >> > https://gcc.gnu.org/pipermail/gcc-patches/2024-May/650634.html >> >> I can give the patch a whirl, thanks. > > I've attached a rebased patch against current mainline. Let me know if it > works on your end, and I'll commit. I've included both this patch ... >> I had Andrew's patch in my tree to avoid the issue. Unfortunately, >> Solaris/SPARC bootstrap is broken again due to PR ipa/114985. > > I have provided a patch for that PR as well, but the IPA folk need to say if > this is the correct approach. ... and that one in last night's SPARC bootstraps, which worked just fine again. Thanks.
[Bug tree-optimization/114912] [15 regression] SIGBUS in wi::copy<> on SPARC since r15-88-gc60b3e211c5557 since char array is not aligned to what it needs to be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114912 --- Comment #14 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #13 from Aldy Hernandez --- > BTW, I'm waiting for a review, or at least a nod from a C++ savvy person here: > > https://gcc.gnu.org/pipermail/gcc-patches/2024-May/650634.html I can give the patch a whirl, thanks. I had Andrew's patch in my tree to avoid the issue. Unfortunately, Solaris/SPARC bootstrap is broken again due to PR ipa/114985.
[Bug target/112959] install.tex needs updates on FreeBSD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112959 --- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #5 from Gerald Pfeifer --- > Rainer, do you think the three changes I made - and hence the current > state of install.texi on trunk - address all the issues you reported > and sufficiently well? What's there looks good to me. However, one issue mentioned in PR target/112959 is missing, namely the problem of getting a working Ada bootstrap compiler. I have no idea if gnat12 has been fixed since and is now able to build Ada on trunk/the gcc-14 branch. Otherwise, the old GNAT 6.4.1 worked for me, but this isn't easy to find. AFAICS, AdaCore provides no FreeBSD GNAT tarball of any kind.
[Bug tree-optimization/114912] [15 regression] SIGBUS in wi::copy<> on SPARC since r15-88-gc60b3e211c5557 since char array is not aligned to what it needs to be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114912 --- Comment #11 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #10 from Andrew Pinski --- > If Aldy does not fix it by Saturday, I will give the union a try then. I will Great, thanks. Your alignas patch also worked fine btw. > also try out the solaris machine on the compile farm if possible. Otherwise, you can just send it my way and I'll give it a whirl.
[Bug c++/113706] c-c++-common/pr103798-2.c FAILs as C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113706 --- Comment #14 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #13 from Jason Merrill --- > Should be fixed now. It is indeed. Thanks a lot.
[Bug ada/112958] [12/13/14/15 regression] s-exnllf.ads etc. don't compile on 32-bit FreeBSD/x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112958 --- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #6 from Gerald Pfeifer --- > FreeBSD i386 is on it's way out: FreeBSD 14 is the last series supporting > it; FreeBSD 15 is dropping support for it. Ah, I wasn't aware of that (and was particularly interested in i386 for comparison with Solaris/i386 asan). > Can we disable libgnat (or GNAT) support during configure time? Sure: --disable-libasan should work for every toplevel library, although there's little point in building GNAT without the runtime libs. Given that there's no --disable-languages (I've filed a PR for that ages ago, I believe), you have to use --enable-languages= instead of --enable-languages=all --disable-languages=ada
[Bug analyzer/111475] [14/15 regression] Many C++ analyzer tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111475 --- Comment #12 from ro at CeBiTec dot Uni-Bielefeld.DE --- "dmalcolm at gcc dot gnu.org" writes: > --- Comment #11 from David Malcolm --- > Thanks. I've been working on this on cfarm216; I have a messy set of patches > with this improvement to g++.sum with analyzer.exp so far: > > # of expected passes 11395 -> 12015 > # of unexpected failures 684 ->64 > # of unexpected successes 4 -> 0 > # of expected failures 443 -> 447 > # of unsupported tests50 > > However I'm don't have access to my regular workstation/testing box until late > tomorrow, so I'm holding off on posting until I've cleaned them up and put > them > through my usual testing regime. That's excellent news, thanks for the update.
[Bug analyzer/111475] [14/15 regression] Many C++ analyzer tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111475 --- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #9 from David Malcolm --- > Sorry about this. > > Is there a machine in the compile farm I can test this on? Sure, both cfarm215 (Solaris/x86) and cfarm216 (Solaris/SPARC). With the attached Solaris testcase, you can reproduce it even on Linux.
[Bug target/114416] calling convention incompatibility with vendor compiler for V9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114416 --- Comment #19 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #18 from ro at CeBiTec dot Uni-Bielefeld.DE Uni-Bielefeld.DE> --- >> --- Comment #17 from Eric Botcazou --- [...] >>> The sparc64-unknown-linux-gnu one will be running for a couple more >>> hours, though. >> >> The change should be a no-op for this platform. > > True. However, I'd rather wait for the bootstrap to complete. Should > be sometime tonight... That's finished now, too, and as expected there were no regressions.
[Bug target/114416] calling convention incompatibility with vendor compiler for V9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114416 --- Comment #18 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #17 from Eric Botcazou --- >> The sparc-sun-solaris2.11 bootstrap (both multilibs) has just completed >> successfully without regressions. >> >> However, sparc/sol2.h needed an #undef to fix [...] > Thanks, fixed. great, thanks. >> The sparc64-unknown-linux-gnu one will be running for a couple more >> hours, though. > > The change should be a no-op for this platform. True. However, I'd rather wait for the bootstrap to complete. Should be sometime tonight... >> Btw., I thought about running gcc.dg/compat against Studio 12.6 cc. I'd >> started trying some time ago, but got distracted. At the very least, I >> needed -features=extensions -DSKIP_COMPLEX_INT for a considerable part >> of that testsuite to compile at all, for the likes of >> >> "/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/compat/pr102024_test.h", >> line 7: zero-sized struct/union >> >> "/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/compat/struct-layout-1.h", >> line 197: invalid type combination > > I used to do that on a regular basis 20 years ago, which led to: > https://gcc.gnu.org/gcc-3.4/sparc-abi.html > but I lost access to Sun Studio at some point. FWIW, cfarm216, the new Solaris 11.4/SPARC compile farm host, does have Studio 12.6 installed. Right now, it's only the FCS version, but I hope to get access to the studiosupport repo in the future. Besides, I've checked the testcase that prompted this PR with previous Studio versions quite some time back and their behaviour in this regard is unchanged.
[Bug target/114416] calling convention incompatibility with vendor compiler for V9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114416 --- Comment #16 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #15 from ro at CeBiTec dot Uni-Bielefeld.DE Uni-Bielefeld.DE> --- >> --- Comment #14 from Eric Botcazou --- >> Do you happen to have some spare cycles to conduct a testing cycle of the >> above >> tentative fix? It only affects the 64-bit ABI so a sparc64/sparcv9 one would >> be sufficient (Unfortunately I no longer have access to my SPARC/Solaris >> setup >> and haven't tried the Compile Farm yet). > > Sure: I've kept one half of the T8-1 hosting the new Solaris 11.4/SPARC > cfarm node to myself ;-) I've also got a Linux/sparc64 LDom around > since the cfarm instance has been very unstable lately. The sparc-sun-solaris2.11 bootstrap (both multilibs) has just completed successfully without regressions. However, sparc/sol2.h needed an #undef to fix In file included from ./tm.h:27, from /vol/gcc/src/hg/master/local/gcc/gencheck.cc:23: /vol/gcc/src/hg/master/local/gcc/config/sparc/sol2.h:460:9: error: "SUN_V9_ABI_COMPATIBILITY" redefined [-Werror] 460 | #define SUN_V9_ABI_COMPATIBILITY 1 | ^~~~ In file included from ./tm.h:24: /vol/gcc/src/hg/master/local/gcc/config/sparc/sparc.h:1705:9: note: this is the location of the previous definition 1705 | #define SUN_V9_ABI_COMPATIBILITY 0 | ^~~~ The sparc64-unknown-linux-gnu one will be running for a couple more hours, though. Btw., I thought about running gcc.dg/compat against Studio 12.6 cc. I'd started trying some time ago, but got distracted. At the very least, I needed -features=extensions -DSKIP_COMPLEX_INT for a considerable part of that testsuite to compile at all, for the likes of "/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/compat/pr102024_test.h", line 7: zero-sized struct/union "/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/compat/struct-layout-1.h", line 197: invalid type combination
[Bug target/114416] calling convention incompatibility with vendor compiler for V9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114416 --- Comment #15 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #14 from Eric Botcazou --- > OK, thanks, let's go ahead for Solaris then, but I agree that we'd better do > nothing for other platforms at this point. Right, I forgot that there are others (and I cannot test any of them at this point; I don't even know if current BSDs still support SPARC at all). > Do you happen to have some spare cycles to conduct a testing cycle of the > above > tentative fix? It only affects the 64-bit ABI so a sparc64/sparcv9 one would > be sufficient (Unfortunately I no longer have access to my SPARC/Solaris setup > and haven't tried the Compile Farm yet). Sure: I've kept one half of the T8-1 hosting the new Solaris 11.4/SPARC cfarm node to myself ;-) I've also got a Linux/sparc64 LDom around since the cfarm instance has been very unstable lately.
[Bug target/114416] calling convention incompatibility with vendor compiler for V9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114416 --- Comment #13 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #12 from Eric Botcazou --- > Rainer, what's your take on this? Should we proceed and change the ABI on > Solaris for GCC 14? I think so, yes: * Binary compatibility with the Studio compilers is pretty important IMO. * Even though the SCD wording isn't really clear, the intent seems to match what Studio cc does according to the colleague on the spec group Jakub cited. * There's no point in waiting beyond GCC 14, I believe: this will break compatiblity with GCC <= 13 no matter what. * Besides, Solaris is pretty quick picking up new GCC releases these days, so they'll bundle GCC 14.1.0 not long after it's released, so the benefit will be immediate. * I'm a tad uncertain about what to do on Linux/sparc64, though: while it mostly has followed the SCD, there are exceptions (e.g. sizeof (long double)) and no vendor compiler to be compatible with. So making the same change there would only mean breaking compatibility with older GCCs (and clang) for little gain.
[Bug go/114454] go.test/test/fixedbugs/issue27836.go FAILs with LANG=C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114454
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from Ian Lance Taylor ---
> I'm not sure what is going on here. The test as such does not require a UTF-8
> LANG. That is, I can run the compiler and the test with LANG=C and everything
> passes. In fact, that is exactly how the GCC testsuite runs the test: the GCC
> testsuite sets LANG=C before all tests.
>
> As best I can tell the problem must be arising somehow in the DejaGNU code.
> The filenames in the test use UTF-8 non-ASCII characters. But I haven't been
> able to figure out where the problem is.
I've done a bit more digging now, running the test under runtest both
with LANG=en_US.UTF-8 and LANG=C.
* Comparing go.log shows
-PASS: go.test/test/fixedbugs/issue27836.dir/�<84>foo.go -O -I. (test for
excess errors)
+go1: fatal error: cannot open
/vol/gcc/src/hg/master/local/gcc/testsuite/go.test/test/fixedbugs/issue27836.dir/�<83>�<84>foo.go:
No such file or directory
i.e. a leading "�<83>" is added to the filename.
* Running both under truss, I see that gccgo is invoked differently:
LANG=UTF-8:
14285:
execve("/var/gcc/regression/master/11.4-gcc/build/gcc/testsuite/go-issue27836/../../gccgo",
0x00E00790, 0x009A5F10) argc = 12
14285: argv:
14285:
/var/gcc/regression/master/11.4-gcc/build/gcc/testsuite/go-issue27836/../../gccgo
14285:
-B/var/gcc/regression/master/11.4-gcc/build/gcc/testsuite/go-issue27836/../../
14285:-fdiagnostics-plain-output
14285:
-I/var/gcc/regression/master/11.4-gcc/build/i386-pc-solaris2.11/./libgo
14285:-O -I. -w -pedantic-errors -c -o Ã<84>foo.o
14285:
/vol/gcc/src/hg/master/local/gcc/testsuite/go.test/test/fixedbugs/issue27836.dir/Ã<84>foo.go
LANG=C:
14441:
execve("/var/gcc/regression/master/11.4-gcc/build/gcc/testsuite/go-issue27836/../../gccgo",
0x00DFFA40, 0x009A11A0) argc = 12
14441: argv:
14441:
/var/gcc/regression/master/11.4-gcc/build/gcc/testsuite/go-issue27836/../../gccgo
14441:
-B/var/gcc/regression/master/11.4-gcc/build/gcc/testsuite/go-issue27836/../../
14441:-fdiagnostics-plain-output
14441:
-I/var/gcc/regression/master/11.4-gcc/build/i386-pc-solaris2.11/./libgo
14441:-O -I. -w -pedantic-errors -c -o Ã<83>Â<84>foo.o
14441:
/vol/gcc/src/hg/master/local/gcc/testsuite/go.test/test/fixedbugs/issue27836.dir/Ã<83>Â<84>foo.go
So the caller of gccgo (runtest/expect) calls it differently.
runtest is the latest version:
DejaGnu version 1.6.3
Expect version 5.45.4
Tcl version 8.6
but expect is ancient (the latest available from 2018).
My inclination to debug runtest or even expect is limited, TBH.
[Bug c++/112652] g++.dg/cpp26/literals2.C FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112652 --- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #9 from Jakub Jelinek --- > (In reply to r...@cebitec.uni-bielefeld.de from comment #8) >> FWIW, the iconv conversion tables in /usr/lib/iconv can be regenerated >> from the OpenSolaris sources, modified not to do that '?' conversion. >> Worked for a quick check for the UTF-8 -> ASCII example, but the '?' is >> more prevalent and would need to be eradicated upstream. > > If it is always '?' used instead of unknown character, we could also have some > hack on the libcpp side for it. It took me a bit to get back to you here since I had to check with both Solaris engineering and dig up our old Solaris 9 sources (which, unlike, OpenSolaris, have no relevant parts missing due to copyright issues). Both what I found in the iconv conversion tables and what's documented in unicode_iconv(7) confirms the consistent use of '?'. The manpage has If the source character code value is not within a range defined by the source codeset standard, it is considered as an illegal character. If the source character code value is within the range(s) defined by the standard, it will be considered as non-identical, even if the source character code value maps to an undefined or a reserved location within the valid range. The non-identical character will map to either ? (0x3f in ASCII-compatible codesets) if the target codeset is a non-Unicode codeset or to Unicode replacement character (U+FFFD) if the target codeset is an Unicode codeset. It will of course be in the respective charset's encoding (0x3f for ASCII, 0x6f for EBCDIC), but that's all I could find. This is not a complete guarantee (I may well have missed something), but seems plausible enough... > Like (but limited to Solaris hosts) in convert_using_iconv when converting > from > SOURCE_CHARSET to some other character set don't try to convert the whole > UTF-8 > string at once, but split it into chunks at u'?' characters, so > foo???bar?baz?qux > would be iconv converted as > foo > ??? > bar > ? > baz > ? > qux > chunks. And when converting the non-? chunks, it would after the conversion > check for the '?' character (in the destination character set - that is > something that perhaps could be queried during initialization after > iconv_open) > and treat it as an error if it appeared there. Or always convert also back to > UTF-8 and check if it has more '?' characters than the source. Unless we want to take the easy way out and just require GNU libiconv on Solaris, that seems like a plausible way of handling the issue.
[Bug target/114416] SPARC V9 struct return with floating-point members violates ABI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114416 --- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE --- I've now also found p. 3P-10: %f0 through %f7 Floating-point fields from structure return (%d0 through %d6) values with a total size of 32 bytes or less (%q0 and %q4) appear in the floating-point registers. and %o0 through %o5 Outgoing non-floating-point parameters slots use up to 6 corresponding out registers. Arguments beyond the sixth extended-word appear on the stack. The second line seems pretty clear that the %o[0-5] registers are only for non-fp parameter slots, while the first could be interpreted either way (fp *fields only* or fp fields in general). While compatibility with the vendor compiler is a strong argument, in the end the ABI remains the reference.
[Bug tree-optimization/96147] [11 regression] gcc.dg/vect/slp-43.c etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96147
--- Comment #12 from ro at CeBiTec dot Uni-Bielefeld.DE ---
It seems the xfail can go completely now: the test PASSes on both
sparc-sun-solaris2.11 and i386-pc-solaris2.11 (32 and 64-bit) with
diff --git a/gcc/testsuite/gcc.dg/vect/bb-slp-32.c
b/gcc/testsuite/gcc.dg/vect/bb-slp-32.c
--- a/gcc/testsuite/gcc.dg/vect/bb-slp-32.c
+++ b/gcc/testsuite/gcc.dg/vect/bb-slp-32.c
@@ -25,4 +25,4 @@ int foo (int *p, int a, int b)
return sum;
}
-/* { dg-final { scan-tree-dump "vectorization is not profitable" "slp2" {
xfail { vect_no_align && { ! vect_hw_misalign } } } } } */
+/* { dg-final { scan-tree-dump "vectorization is not profitable" "slp2" {
xfail { ! vect_hw_misalign } } } } */
[Bug tree-optimization/113431] [14 Regression] Wrong code at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113431 --- Comment #24 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #23 from Jakub Jelinek --- > Assuming fixed even on sparc*. It is. I've missed this one when collecting instances of missing vect_hw_misalign like PR tree-optimization/98238. Thanks.
[Bug d/114155] gdc.test/runnable/literal.d FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114155 --- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #2 from Iain Buclaw --- > Fix to format hexstrings as big endian has been committed from upstream merge. > > r14-9505 > > This should be resolved now. It is. Thanks for taking care of this.
[Bug libobjc/48626] --enable-objc-gc should be automatic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48626 --- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #9 from Andrew Pinski --- > Let me look into that for GCC 15. Note libobjc is not used by many folks even > the GNUStep folks don't use it any more ... Thanks. I only include it (and objc-gc) in my builds to maximize coverage on uncommon targets: this tends to find bugs that aren't seen on e.g. Linux.
[Bug tree-optimization/114154] gcc.dg/vect/vect-alias-check-1.c XPASSes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114154 --- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE Uni-Bielefeld.DE> --- >> --- Comment #2 from Richard Biener --- >> possibly "fallout" of r14-9193-ga0b1798042d033 > > It's not: I've reverted that patch locally, rebuilt cc1 and re-tested: > the XPASSes remain. A reghunt identified this patch: commit d30846a02eb9ea43b61311e74fbf05692ffefba2 Author: Fei Yang Date: Fri Jun 12 11:37:00 2020 +0100 vect: Fix an ICE in vect_loop_versioning [PR95570]
[Bug tree-optimization/114154] gcc.dg/vect/vect-alias-check-1.c XPASSes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114154 --- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #2 from Richard Biener --- > possibly "fallout" of r14-9193-ga0b1798042d033 It's not: I've reverted that patch locally, rebuilt cc1 and re-tested: the XPASSes remain.
[Bug libobjc/48626] --enable-objc-gc should be automatic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48626 --- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #7 from Iain Sandoe --- > now that boehm-gc is no longer in tree > > what should we do with this? > > I suppose there could be some more sophisticated top-level configuration > (similar to GMP et. al.) which determines if there's a suitable libgc > available? On the contrary: I think support for --enable-objc-gc at both the toplevel and gcc can just go. * At the toplevel, it's just a preliminary check which I don't think is necessary at all since it's redone in more detail in libobjc. * In gcc, all that --enable-objc-gc does is set OBJC_BOEHM_GC in gcc/Makefile, which isn't ever used.
[Bug c++/112652] g++.dg/cpp26/literals2.C FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112652 --- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #7 from Jakub Jelinek --- > (In reply to r...@cebitec.uni-bielefeld.de from comment #6) >> > --- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE > > Uni-Bielefeld.DE> --- >> >> --- Comment #4 from Jakub Jelinek --- >> >> Given that C++ says e.g. in https://eel.is/c++draft/lex.ccon#3.1 >> >> that program is ill-formed if some character lacks encoding in the >> >> execution >> >> character set, I'm afraid the Solaris iconv behavior results in violation >> >> of >> >> Although I can barely wrap my head around the standardese there, I had a >> look at n4928 (the last? C++23 draft), which has a different wording >> here (p.25, 5.13.3): > > The testcase is for a C++26 feature, which made those ill-formed. Should have been obvious from the pathname ;-( N4971 has that wording... >> The current Solaris iconv behaviour certainly isn't particularly >> intuitive and I'll ask the Solaris engineers about it. However, there's >> the question what to do about the testcase? Just xfail it on Solaris or >> omit just the two affected subtests there? > > xfailing is one possibility, but then on Solaris we'll never support C++26 > properly. I guess it's the best solution in the short term (GCC 14), though. > Or require using GNU libiconv rather than Solaris iconv if it can't deal with > that? At least document the suggestion in install.texi; I wouldn't make it a hard requirement yet. I'll also wait what the Solaris engineers can provide on background for the current behaviour. FWIW, the iconv conversion tables in /usr/lib/iconv can be regenerated from the OpenSolaris sources, modified not to do that '?' conversion. Worked for a quick check for the UTF-8 -> ASCII example, but the '?' is more prevalent and would need to be eradicated upstream.
[Bug c++/112652] g++.dg/cpp26/literals2.C FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112652 --- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE Uni-Bielefeld.DE> --- >> --- Comment #4 from Jakub Jelinek --- >> Given that C++ says e.g. in https://eel.is/c++draft/lex.ccon#3.1 >> that program is ill-formed if some character lacks encoding in the execution >> character set, I'm afraid the Solaris iconv behavior results in violation of Although I can barely wrap my head around the standardese there, I had a look at n4928 (the last? C++23 draft), which has a different wording here (p.25, 5.13.3): (3.1) — A character-literal with a c-char-sequence consisting of a single basic-c-char, simple-escape-sequence, or universal-character-name is the code unit value of the specified character as encoded in the literal’s associated character encoding. [Note 2 : If the specified character lacks representation in the literal’s associated character encoding or if it cannot be encoded as a single code unit, then the literal is a non-encodable character literal. —end note > I've not yet tried to understand what either iconv(3) has to say on the > matter. Digging further, Solaris iconv(3C) has If iconv() encounters a character in the input buffer that is legal, but for which an identical character does not exist in the target code set, iconv() performs an implementation-defined conversion on this character. which exactly matches XPG7, so the behaviour seems to be in line with the standards. I've also found that Solaris 11 has iconvctl(3C) (obviously patterened after GNU libiconv) with ICONV_SET_TRANSLITERATE With this request and a pointer to a const int with a non-zero value, caller can instruct the current conversion to transliterate non-identical characters from the input buffer during the code con- version as much as it can. The value of zero, on the other hand, turns it off. However, int transliterate = 0; iconvctl (cd, ICONV_SET_TRANSLITERATE, ); doesn't make a difference. The current Solaris iconv behaviour certainly isn't particularly intuitive and I'll ask the Solaris engineers about it. However, there's the question what to do about the testcase? Just xfail it on Solaris or omit just the two affected subtests there?
[Bug c++/112652] g++.dg/cpp26/literals2.C FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112652 --- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #4 from Jakub Jelinek --- > Given that C++ says e.g. in https://eel.is/c++draft/lex.ccon#3.1 > that program is ill-formed if some character lacks encoding in the execution > character set, I'm afraid the Solaris iconv behavior results in violation of > the C++ standard requirements, it is hard to argue that in the Solaris case > e.g. ISO-8859-1 execution charset would be some special character set where ? > character represents all Unicode characters which don't have a representation > in the character set in addition to ?. I've now started digging into this myself. * Solaris iconv(1) says output. If no conversion exists for a particular character, an imple- mentation-defined conversion is performed on this character. * This seems to at least partially match with XPG7: -s Suppress any messages written to standard error concerning invalid characters. When -s is not used, the results of encountering invalid characters in the input stream (either those that are not valid characters in the codeset of the input file or that have no corresponding character in the codeset of the output file) shall be specified in the system documentation. The presence or absence of -s shall not affect the exit status of iconv. AFAIU that's related to what Solaris iconv(1) does, although they don't specify the output '?' and produce no message. However, they still exit with 0, which seems wrong to me. I've not yet tried to understand what either iconv(3) has to say on the matter. > I'm afraid we don't want to maintain iconv replacement inside of libcpp > though. Agreed.
[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
--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> * out-of-bounds-diagram-3.c gets skipped on that machine due to
> { dg-require-effective-target lp64 }
> "check_cached_effective_target lp64: returning 0 for unix"
>
> Is there a config/cfarm machine you see the out-of-bounds-diagram-3.c failure
> on?
GCC on Solaris is bi-arch by default, so this should be a matter of
running the testsuite with both -m32 and -m64, as described in
install.texi (Passing options and running multiple testsuites).
Since properly quoting RUNTESTFLAGS can be trick, I usually use a
site.exp instead like
global target_list
case "$target_triplet" in {
{ "sparc-*-solaris2*" } {
set target_list { "unix{,-m64}" }
}
}
and point the DEJAGNU env variable to its path.
[Bug modula2/102344] gm2/pim/fail/TestLong4.mod FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102344 --- Comment #11 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #10 from Gaius Mulley --- > I'm optimistically changing the version of the bug from 12 to 14 and closing > it. Right, that was my intent ;-) > Feel free to re-open if this was misjudged. I suspect this patch is a > candidate for back porting to 13. It wouldn't hurt given that it's low-risk. However, I'm concentrating on 14 right now to finally get cleaner results on Solaris. Thanks.
[Bug modula2/102344] gm2/pim/fail/TestLong4.mod FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102344 --- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE --- Looks good: I've just tested both testcases on i386-pc-solaris2.11 and sparc-sun-solaris2.11 (both 32 and 64-bit). Everything PASSes just fine. Thanks.
[Bug tree-optimization/107855] gcc.dg/vect/vect-ifcvt-18.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107855
--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #6 from Xi Ruoyao ---
> Hmm, the test contains
>
> "/* { dg-additional-options "-Ofast -mavx" { target avx_runtime } } */"
>
> So it passes on AVX capable native builds, but fails otherwise.
I can reproduce things in a VM now: when it doesn't have avx support,
the test is compiled with -msse2 only and FAILs both for the dump and
execution:
FAIL: gcc.dg/vect/vect-ifcvt-18.c -flto -ffat-lto-objects scan-tree-dump vect
"vectorized 3 loops"
FAIL: gcc.dg/vect/vect-ifcvt-18.c -flto -ffat-lto-objects execution test
FAIL: gcc.dg/vect/vect-ifcvt-18.c execution test
FAIL: gcc.dg/vect/vect-ifcvt-18.c scan-tree-dump vect "vectorized 3 loops"
The test aborts here:
Thread 2 received signal SIGABRT, Aborted.
#0 0xfe26e385 in __lwp_sigqueue () from /lib/libc.so.1
#1 0xfe2660ef in thr_kill () from /lib/libc.so.1
#2 0xfe19db82 in raise () from /lib/libc.so.1
#3 0xfe16b1f4 in abort () from /lib/libc.so.1
#4 0x08050d58 in main ()
at
/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/vect/vect-ifcvt-18.c:34
and the dump shows
/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/vect/vect-ifcvt-18.c:28:17:
note: === analyze_loop_nest ===
/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/vect/vect-ifcvt-18.c:28:17:
note: === vect_analyze_loop_form ===
/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/vect/vect-ifcvt-18.c:28:17:
note: using as main loop exit: 13 -> 14 [AUX: 0]
/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/vect/vect-ifcvt-18.c:28:17:
missed: not vectorized: unsupported control flow in loop.
/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/vect/vect-ifcvt-18.c:28:17:
missed: bad loop form.
/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/vect/vect-ifcvt-18.c:28:17:
missed: couldn't vectorize loop
When I add avx support to the VM, the test PASSes.
It seems the test is missing some requirement here.
[Bug libstdc++/113450] [14 Regression] std/format/functions/format.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113450 --- Comment #19 from ro at CeBiTec dot Uni-Bielefeld.DE --- I'm talking with Oracle Solaris Engineering and they're amenable to making the int8_t change from char to signed char. To assess the possible impact, the plan is to compare the public symbols of C++ libraries delivered with Solaris now and after a rebuild with changed. Are there other important issues to consider with such a change?
[Bug target/114049] gcc.dg/framework-1.c FAILs with Xcode 15.3 beta 3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114049 --- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #3 from Iain Sandoe --- > so .. if i follow your discussion correctly - neither clang nor gcc finds it > because it's incorrectly quoted (is that an SDK issue?).. or? The quoting is one part, certainly. While clang falls back from <> to "", gcc does not. However, even if I change string.h locally to use "", while this allows machine/trap.h to be found, the subsequent i386/trap.h is still not found, neither by gcc nor by clang. I have not idea what they are doing here, but the same construct is used all over Frameworks/Kernel.framework/Headers. > We do have control, IIRC, about adding the frameworks search path to "system" > rather than "user". That might be an option: I guess we should follow what clang does here.
[Bug target/114049] gcc.dg/framework-1.c FAILs with Xcode 15.3 beta 3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114049 --- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #1 from Iain Sandoe --- > /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Kernel.framework/Headers > should be a symlink to > /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Kernel.framework/Versions/A/Headers More or less: the symlink is to Versions/Current/Headers. > so either that's broken or we're failing to follow a symlink somehow. I've checked: the original invocation is /private/var/gcc/regression/master/14-gcc/build/gcc/xgcc -B/private/var/gcc/regression/master/14-gcc/build/gcc/ /vol/gcc/src/hg/master/darwin/gcc/testsuite/gcc.dg/framework-1.c -fdiagnostics-plain-output -F. -S -o framework-1.s with cc1 called like /private/var/gcc/regression/master/14-gcc/build/gcc/cc1 -quiet -v -F. -iprefix /private/var/gcc/regression/master/14-gcc/build/gcc/../lib/gcc/x86_64-apple-darwin23.3.0/14.0.1/ -isystem /private/var/gcc/regression/master/14-gcc/build/gcc/include -isystem /private/var/gcc/regression/master/14-gcc/build/gcc/include-fixed -D__DYNAMIC__ /vol/gcc/src/hg/master/darwin/gcc/testsuite/gcc.dg/framework-1.c -fPIC -quiet -dumpbase framework-1.c -dumpbase-ext .c -mmacosx-version-min=14.0.0 -mtune=core2 -version -fdiagnostics-color=never -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-urls=never -fdiagnostics-path-format=separate-events -fdiagnostics-text-art-charset=none -o framework-1.s After the usual messages about nonexistant directories, we get to #include <...> search starts here: . /private/var/gcc/regression/master/14-gcc/build/gcc/include /private/var/gcc/regression/master/14-gcc/build/gcc/include-fixed /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks End of search list. /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Kernel.framework/Headers/string.h has #include which lives in /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Kernel.framework/Versions/A/Headers/machine/trap.h Given the above search list, "machine/trap.h" should work, but doesn't. When using the bundled clang, I get $ clang /vol/gcc/src/hg/master/darwin/gcc/testsuite/gcc.dg/framework-1.c -F. -S -o framework-1.s In file included from /vol/gcc/src/hg/master/darwin/gcc/testsuite/gcc.dg/framework-1.c:4: /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Kernel.framework/Headers/string.h:55:10: error: 'machine/trap.h' file not found with include; use "quotes" instead #include ^ In file included from /vol/gcc/src/hg/master/darwin/gcc/testsuite/gcc.dg/framework-1.c:4: In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Kernel.framework/Headers/string.h:55: /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Kernel.framework/Headers/machine/trap.h:32:10: fatal error: 'i386/trap.h' file not found #include "i386/trap.h" ^ 2 errors generated.
[Bug preprocessor/114007] gcc chokes on __has_cpp_attribute(clang::unsafe_buffer_usage)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007 --- Comment #25 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #24 from Jakub Jelinek --- > (In reply to fxcoud...@gmail.com from comment #19) >> I haven’t yet tested Xcode 13.3 myself, and have only followed the PRs from >> far away. Are there any issues (SDK, linker, or otherwise) that we need to >> report to Apple? Or that are already reported but we want taken more >> seriously? > > Do they use [[clang::unsafe_buffer_usage]] then if __has_safe_buffers is > defined > even in -std=c11 etc. modes in the headers? they do AFAICS: their has no provision for different C std versions (except the obvious like not using restrict before C99). The section in question is #if __has_cpp_attribute(clang::unsafe_buffer_usage) #define __has_safe_buffers 1 #define __unsafe_buffer_usage [[clang::unsafe_buffer_usage]] #elif __has_attribute(unsafe_buffer_usage) #define __has_safe_buffers 1 #define __unsafe_buffer_usage __attribute__((__unsafe_buffer_usage__)) #else #define __has_safe_buffers 0 #define __unsafe_buffer_usage #endif with a long comment explaining the use with clang -Wunsafe-buffer-usage.
[Bug preprocessor/114007] gcc chokes on __has_cpp_attribute(clang::unsafe_buffer_usage)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007 --- Comment #23 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #22 from Iain Sandoe --- > (In reply to r...@cebitec.uni-bielefeld.de from comment #21) >> > --- Comment #19 from fxcoudert at gmail dot com > com> --- > > >> The only issue left (the gcc.dg/framework-1.c failure) so far seems to >> be an issue with gcc not setting include paths correctly for frameworks. > > Please raise a separate BZ for that - it's a bit surprising (I would have > expected more fails if that was not working). Done now: PR target/114049, gcc.dg/framework-1.c FAILs with Xcode 15.3 beta 3.
[Bug preprocessor/114007] gcc chokes on __has_cpp_attribute(clang::unsafe_buffer_usage)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007 --- Comment #21 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #19 from fxcoudert at gmail dot com > --- > Hi Rainer, > >> Thanks a lot for the patch. I've now re-bootstrapped trunk on macOS 14 >> with it applied instead of the local (incomplete) >> workaround. > > I haven’t yet tested Xcode 13.3 myself, and have only followed the PRs from > far > away. Are there any issues (SDK, linker, or otherwise) that we need to report > to Apple? Or that are already reported but we want taken more seriously? > > I can use my channel through Homebrew to get them to prioritise it to some > extent. It’s probably too late for 13.3 at this point, but we should get it > fixed anyway for later. I don't think so (otherwise I'd hopefully done it myself already ;-) The only issue left (the gcc.dg/framework-1.c failure) so far seems to be an issue with gcc not setting include paths correctly for frameworks.
[Bug libstdc++/113450] [14 Regression] std/format/functions/format.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113450 --- Comment #18 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #17 from Joseph S. Myers --- > The tests that GCC's internal notion of the types agrees with the headers are > in gcc.dg/c99-stdint-5.c and gcc.dg/c99-stdint-6.c. Ah, now I remember: they had to be adjusted back in the day for various omissions on Solaris and Tru64 UNIX. During my recent test bootstrap, they didn't show up because I had changed and sol2.h's INT8_TYPE etc. in lockstep, so no inconsistencies occured.
[Bug preprocessor/114007] gcc chokes on __has_cpp_attribute(clang::unsafe_buffer_usage)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007 --- Comment #18 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #17 from Jakub Jelinek --- > Created attachment 57483 > --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57483=edit > gcc14-pr114007.patch > > So far very lightly tested fix. Thanks a lot for the patch. I've now re-bootstrapped trunk on macOS 14 with it applied instead of the local (incomplete) workaround. With one unrelated exception +FAIL: gcc.dg/framework-1.c (test for excess errors) test results with Xcode 15.1 and 15.3 beta 3 are now identical.
[Bug libstdc++/113450] [14 Regression] std/format/functions/format.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113450 --- Comment #16 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #15 from Jonathan Wakely --- > (In reply to r...@cebitec.uni-bielefeld.de from comment #14) >> * When checking clang, there were more surprises: >> >> #define __INT8_TYPE__ signed char >> >> With very few exceptions, clang uses the default definitions of the >> intN_t types everywhere. > > That's interesting. I think GCC defines those __INTn_TYPE__ macros after > inspecting the target headers (assuming the target provides or > ) to ensure they agree. I wonder if Clang intentionally deviated Unfortunately not: gcc hardcodes all those types all over gcc/config (e.g. sol2.h) as INT8_TYPE. > from the Solaris headers to "fix" this issue, or if they just define > __INT8_TYPE__ to signed char for all 8-bit targets because "obviously" that's > correct for all targets (even though it isn't actually correct for Solaris). I guess no one cared enough about Solaris in Clang to notice this. There isn't even a test to check if Clang's internal idea of e.g. int8_t and that of the system headers match (but neither does gcc). > That means GCC and Clang will disagree about the mangling of a C++ function > like > void foo(int8_t); As I found, they won't: while their internal definitions of __INT8_TYPE__ differ, when one wants to use int8_t, one needs to include a corresponding header (//), thus will always get what the header defines. Only when using __INT8_TYPE__ directly will you get the mangled form of the compiler's internal idea of int8_t. To check what happens, I've re-run last night bootstraps (sparc and x86) with changed to define int8_t and friends as signed char, at the same time modifying gcc/config/sol2.h to match. The bootstrap (i386 so far, sparc still running, though I don't expect any difference) went without issues: the only regression seen is +UNRESOLVED: gdc.test/runnable_cxx/stdint.d compilation failed to produce executable +UNRESOLVED: gdc.test/runnable_cxx/stdint.d -shared-libphobos compilation failed to produce executable where the executable fails to link: Undefined first referenced symbol in file _Z15testCppI8Manglechchch /var/tmp//ccJLlOBa.o This test has D (stdint.d) and C++ (extra-files/stdint.cpp) components, checking the gdc and g++'s ideas of various types match. Unlike C/C++, where the definition of int8_t is from , D has it's equivalent in libphobos/libdruntime/core/stdc/stdint.d which will have to be adjusted, too. >> However, the question remains how much that counts: given clang/llvm >> has seen years of neglect on Solaris, I wonder how much actual code is >> really built with it on Solaris. >> >> * The Oracle Studio 12.6 cc has no definition of __INT8_TYPE__ at all >> AFAICT. If that's true, one could change the type's definition simply >> by adjusting , which would be nice and easy. > > I think those macros are a GCC thing not required by any standard. Oracle > Studio can just rely on being present, because they know that's > true > for Solaris. GCC can't (or couldn't historically) rely on being > present for all targets so needed some other way to make those types > available. I guess so: I just meant to find out if cc/CC has it's own idea of the types apart from the system headers. However, going forward, this can certainly learned from Oracle. I'll think given the information so far, I'll take the idea of changing int8_t for C99+ conformance to them and see what they think.
[Bug libstdc++/113450] [14 Regression] std/format/functions/format.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113450 --- Comment #14 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #11 from ro at CeBiTec dot Uni-Bielefeld.DE Uni-Bielefeld.DE> --- >> --- Comment #7 from Jonathan Wakely --- >> (In reply to Jonathan Wakely from comment #1) >>> I assume that int8_t is char on Solaris, rather than signed char? >> >> This actually violates the C and C++ standards, which require that intN_t is >> a >> signed integer type, and C 6.2.5 says "There are five standard signed integer >> types, designated as signed char, short int, int, long int, and long long >> int." >> So char isn't allowed, it should be signed char. > > I've done some digging now: / were > introduced into Solaris 2.6 (the file dates from Jul 16 1997), way > before the C99 standard was finalized. Further research has uncovered some interesting facts: * Neither the SysV SPARC psABI (3rd Edition, 1996) nor the original i386 psABI (4th Edition, 1997) specify int8_t at all. Actually no wonder because both predate C99. However, even the current Intel386 psABI 1.1 (2015) has nothing here, nor does the AMD64 psABI 1.0 (2024). To my astonishment however, the SPARC Compliance Definition 2.4.1 (1999), defacto if not in name the SPARC V9 psABI, lists in Figure 6-140: , p.6P-13: typedef signed char int8_t; So it seems at least Solaris/SPARCV9 violates its own ABI ;-( * When checking clang, there were more surprises: #define __INT8_TYPE__ signed char With very few exceptions, clang uses the default definitions of the intN_t types everywhere. However, the question remains how much that counts: given clang/llvm has seen years of neglect on Solaris, I wonder how much actual code is really built with it on Solaris. * The Oracle Studio 12.6 cc has no definition of __INT8_TYPE__ at all AFAICT. If that's true, one could change the type's definition simply by adjusting , which would be nice and easy.
[Bug libstdc++/113450] [14 Regression] std/format/functions/format.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113450 --- Comment #13 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #10 from Jakub Jelinek --- > Or convince Oracle to change it (again, an ABI break). I can try, but don't hold your breath.
[Bug libstdc++/113450] [14 Regression] std/format/functions/format.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113450 --- Comment #12 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #9 from Jonathan Wakely --- > It's technically an ABI break, since void f(int8_t) would mangle differently. > It probably wouldn't affect much in practice, but would still be a break. Still, given how serious Sun/Oracle is about ABI compatibility (and always has been), I'm doubtful they would be amenable to the idea.
[Bug libstdc++/113450] [14 Regression] std/format/functions/format.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113450 --- Comment #11 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #7 from Jonathan Wakely --- > (In reply to Jonathan Wakely from comment #1) >> I assume that int8_t is char on Solaris, rather than signed char? > > This actually violates the C and C++ standards, which require that intN_t is a > signed integer type, and C 6.2.5 says "There are five standard signed integer > types, designated as signed char, short int, int, long int, and long long > int." > So char isn't allowed, it should be signed char. I've done some digging now: / were introduced into Solaris 2.6 (the file dates from Jul 16 1997), way before the C99 standard was finalized. I've looked around the WG14 archive, and some drafts after that date (N737 (1997-06-26), N788 (1997-11-17), N851 (1998-09-22)) do have the `signed integer type' wording. Unfortunately, all of the previous ones (which would have been the basis of the Solaris implementation) are no longer available.
[Bug preprocessor/114007] gcc chokes on __has_cpp_attribute(clang::unsafe_buffer_usage)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007 --- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #1 from Iain Sandoe --- > Is this a clang extension (handling clang::x with -std= < c23)? I can't tell: I was waiting for the preprocessor maintainers to comment. > i.e. if the header is not actually standard-conforming - perhaps there's time > to get the released SDK fixed (did you raise a feedback?) Not yet, but I mean to. However, it's better to have a clean understanding if the code is wrong first.
[Bug rtl-optimization/60045] gcc.dg/atomic/c11-atomic-exec-[23].c compilation times out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60045 --- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #5 from Richard Biener --- > There was some recent fixes (in GCC 14) addressing scheduling related issues. > Do these testcases still pose problems? I've checked the 32-bit gcc.dg/atomic/c11-atomic-exec-2.c testcase on my current SPARC build systems: * colima (4.267 GHz SPARC-S7): real 15.13 user 14.70 sys0.10 * gamalama (5.067 GHz SPARC-M8): real 10.84 user 10.49 sys0.06 While I still have an ancient 1.165 GHz UltraSPARC-T2 system around (where I originally reported the slow compilation), I haven't done a GCC build there in ages. I'd argue that this is no longer an issue on current systems.
[Bug tree-optimization/113910] [12/13 Regression] Factor 15 slowdown compiling AMDGPUDisassembler.cpp on SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113910 --- Comment #15 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #14 from Richard Biener --- > The regression should be fixed, can you check we're now no longer slower on > trunk? (either use a release checking build or use -fno-checking which should > get you reasonably close) I've done a --enable-checking=release build on trunk and compare compile times of the -save-temps with g++ 11.4.0: $ time cc1plus -fpreprocessed AMDGPUDisassembler.cpp.ii -quiet -mcpu=v9 -O -std=c++17 -o AMDGPUDisassembler.cpp.s * 11.4.0: real2:04.33 user2:03.86 sys0.30 * 14.0.1: real2:17.58 user2:16.47 sys0.87
[Bug tree-optimization/113910] [12/13/14 regression] Factor 15 slowdown compiling AMDGPUDisassembler.cpp on SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113910 --- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #4 from Andrew Pinski --- >>Configure with --enable-checking=release to disable checks. I'm seeing the same slowdown with release builds of GCC 12.3.0 and 13.2.0. > Can you try that if you are comparing compile times? > Some of the slow down is definitely related to that: >> tree SSA verifier : 12.28 ( 1%) 0.02 ( 0%) 12.12 ( 1%) 0 ( 0%) >> tree STMT verifier : 18.62 ( 1%) 0.00 ( 0%) 18.79 ( 1%) 0 ( 0%) >> CFG verifier : 9.77 ( 0%) 0.01 ( 0%) 10.01 ( 1%) 0 ( 0%) >> verify RTL sharing : 12.45 ( 1%) 0.01 ( 0%) 12.46 ( 1%) 0 ( 0%) > > > For an example. 13.2.0 takes real 19.59 user 16.05 sys3.43 but was still in the half-hour range with the original full set of flags. I'll retry that and report.
[Bug sanitizer/113785] c-c++-common/asan/swapcontext-test-1.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113785 --- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE --- Upstream pull request posted: https://github.com/llvm/llvm-project/pull/81588
[Bug sanitizer/113785] c-c++-common/asan/swapcontext-test-1.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113785 --- Comment #1 from ro at CeBiTec dot Uni-Bielefeld.DE --- I've found what's going on: as described in Solaris makecontext(3C), the function changed starting with Solaris 10: NOTES The semantics of the uc_stack member of the ucontext_t structure have changed as they apply to inputs to makecontext(). Prior to Solaris 10, the ss_sp member of the uc_stack structure represented the high memory address of the area reserved for the stack. The ss_sp member now repre- sents the base (low memory address), in keeping with other uses of ss_sp. This change in the meaning of ss_sp is now the default behavior. The -D__MAKECONTEXT_V2_SOURCE compilation flag used in Solaris 9 update releases to access this behavior is obsolete. To preserve, binary compatiblity, the old behaviour of makecontext() has been retained, and the following snippet in ensures that a different function with the new behavious is called from user code instead: /* makecontext removed in SUSv4 (XPG7, UNIX V7) */ #if !defined(_XPG7) || defined(__EXTENSIONS__) #ifdef __sparc #ifdef __PRAGMA_REDEFINE_EXTNAME #pragma redefine_extnamemakecontext __makecontext_v2 #else #define makecontext __makecontext_v2 #endif #endif /* __sparc */ #endif /* !defined(_XPG7) || ... */ However, libasan knows nothing about this and just intercepts unadorned makecontext, but this interceptor is never called. I've got a patch (attached for reference) that changes the makecontext interceptor to call __makecontext_v2 instead on Solaris/SPARC. With this, the c-c++-common/asan/swapcontext-test-1.c test now PASSes on Solaris/SPARC. I'm going to submit it upstream soon.
[Bug d/104739] gdc.test/runnable/mangle.d etc. FAIL with Solaris as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104739 --- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #6 from Iain Buclaw --- > (In reply to r...@cebitec.uni-bielefeld.de from comment #5) > Can give it a go. > > https://github.com/dlang/dmd/pull/16136 Great, thanks for doing this. With this patch applied locally, adding DejaGnu support for the new annotation proved to be as easy as I'd suspected.
[Bug d/104739] gdc.test/runnable/mangle.d etc. FAIL with Solaris as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104739
--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #4 from Rainer Orth ---
> I wonder how to handle this: while DejaGnu has an ucn effective-target
> keyword,
> the gdc.test testsuite doesn't use those at all.
What I think could be done is
* Add "//UTF-8 chars" comments to testmodule.d and ufcs.d; mangle.d
already has one.
* Make gdc-utils.exp (gdc-convert-test) check for those annotations,
adding
// { dg-require-effective-target ucn}
if found.
The new annotations would have to go upstream, I believe. WDYT?
[Bug target/113700] libgcc_s does not include symbols for _Float16 and __bf16 on Solaris/Illumos even though gcc generates code for _Float16 and __bf16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113700 --- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE --- When looking at the 64-bit libgcc_s.so.1 on both Solaris/x86 and Linux/i686, I noticed that all the new GCC_14.0.0 symbols from libgcc-glibc.ver (and now libgcc-sol2.ver) have been demoted to local. IIUC, this happens because the __PFX__ handling (substitution by $(LIBGCC_VER_GNU_PREFIX) as needed) is only applied to libgcc-std.ver.in by Makefile.in. In the i386/libgcc-*.ver files, this substitution doesn't happen, the literal "__PFX__fixxfbitint" etc. symbols are not found in any object, so the unprefixed ones are turned local. >From what I could see in config.host, LIBGCC_VER_GNU_PREFIX only applies to non-x86 targets. Maybe we can just remove __PFX__ from i386/libgcc-*.ver? Jakub?
[Bug tree-optimization/113706] c-c++-common/pr103798-2.c FAILs as C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113706
--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #3 from H.J. Lu ---
> On Solaris, when compiling this
>
> #include
>
> __attribute__ ((weak))
> int
> f (int a)
> {
>return memchr ("aE", a, 2) != NULL;
> }
>
> as C++ source, std::memchr is used and GCC doesn't treat std::memchr as
> BUILT_IN_MEMCHR.
I see. I'm testing a patch to directly define/declare NULL, size_t and
memchr instead of including . This should still test what the
testcase is supposed to test, I believe.
[Bug preprocessor/105608] [11/12/13/14 Regression] ICE: in linemap_add with a really long defined macro on the command line r11-338-g2a0225e47868fbfc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105608 --- Comment #12 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #11 from Lewis Hyatt --- > Oh interesting. So the purpose of this test was just to record that GCC > outputs > incorrect locations for this case, I wanted to xfail it and then fix it > properly for GCC 15. I did not consider that it might output different wrong > locations for different platforms, but I could buy that it may happen, for a > similar reason why this switched from being silently broken to ICEing since > r11-338 which was seemingly unrelated. It seems like in one case the wrong > location is inside the header file and in the other case, the wrong location > is > the line just following the include. It may have to do with line endings or > some other issue with the treatment of EOF? If this test is causing problems > we It's still weird given that it's exactly the same version of Solaris on both SPARC and x86. > could just skip it on some architectures maybe? Once the underlying issue is I guess that's best for now. I'll check if the test behaves differently for a 64-bit-default (amd64-pc-solaris2.11) compiler. > fixed, the location (line 2 of the .C file) will be correct everywhere. I am > curious why it gets a different wrong output though, if there is a compile > farm > machine with this architecture I could look into it. There's no Solaris/x86 system in the cfarm right now, unfortunately. The only one runs Solaris 11.3/SPARC, where the test works just like everywhere else. That said, I've accquired systems to add to the cfarm that will both be running current Solaris 11.4 (SPARC and x86). I'm working on installing and integrating them as we speak, but I don't have an ETA yet.
[Bug target/112862] [14 regression] gfortran.dg coarray tests FAIL on macOS 12+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112862 --- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #9 from Iain Sandoe --- > (In reply to Rainer Orth from comment #8) >> Again tested on macOS 11 (unchanged) and 14. On the latter, the previous >> failures >> to find libatomic.1.dylib have been traded for >> >> FAIL: gfortran.dg/coarray/alloc_comp_1.f90 -fcoarray=single -O2 (test for >> excess errors) >> Excess errors: >> ld: warning: duplicate -rpath >> '/private/var/gcc/regression/master/14-gcc/build/x86_64-apple-darwin23.2.0/ >> libatomic/.libs' ignored >> >> This is definitely progress ;-) > > hmm I wonder where this is coming from .. as you noted there is a bit of a > tendency in the testsuite to add stuff somewhat randomly. Right: I believe sometimes such duplication depends on whether you run the test sequentially or in parallel. FWIW, alloc_comp_1.f90 is linked like spawn -ignore SIGHUP /private/var/gcc/regression/master/14-gcc/build/gcc/testsuite/gfortran/../../gfortran -B/private/var/gcc/regression/master/14-gcc/build/gcc/testsuite/gfortran/../../ -B/private/var/gcc/regression/master/14-gcc/build/x86_64-apple-darwin23.2.0/./libgfortran/ /vol/gcc/src/hg/master/darwin/gcc/testsuite/gfortran.dg/coarray/alloc_comp_1.f90 -fdiagnostics-plain-output -fdiagnostics-plain-output -fcoarray=single -O2 -B/private/var/gcc/regression/master/14-gcc/build/x86_64-apple-darwin23.2.0/./libatomic/ -B/private/var/gcc/regression/master/14-gcc/build/x86_64-apple-darwin23.2.0/./libatomic/.libs -B/private/var/gcc/regression/master/14-gcc/build/x86_64-apple-darwin23.2.0/./libgfortran/.libs -B/private/var/gcc/regression/master/14-gcc/build/x86_64-apple-darwin23.2.0/./libatomic/.libs -B/private/var/gcc/regression/master/14-gcc/build/x86_64-apple-darwin23.2.0/./libquadmath/.libs -lm -o ./alloc_comp_1.exe In this case (by pure inspection) caf.exp includes both gfortran-dg.exp and atomic-dg.exp. The latter adds -B... itself.
[Bug target/112861] [14 regression] Most gdc tests FAIL on macOS 12+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112861 --- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #1 from Iain Sandoe --- > Created attachment 57201 > --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57201=edit > patch under test > > works on x86_64 sonoma, with XC 15.1 CLT. > testing more widely, I've successfully tested the patch on both x86_64-apple-darwin23.2.0 with Xcode 15.1 CLT and x86_64-apple-darwin20.6.0 with Xcode 13.2 CLT. macOS 11 results are clean as before, macOS 14 results almost so: FAIL: gdc.dg/debug/trivial.d -gdwarf-2 -g3 (test for excess errors) FAIL: gdc.dg/debug/trivial.d -gdwarf-2 -g3 -O (test for excess errors) FAIL: gdc.dg/debug/trivial.d -gdwarf-2 -g3 -O3 (test for excess errors) which are due a known dsymutil issue: Excess errors: warning: '.debug_macinfo' is not currently supported: file will be skipped note: while processing /private/var/folders/n9/ygx22vs12c5crsryv773x1k800021y/T/cc3IYcpb.o Thanks.
[Bug modula2/113559] gm2/isolib/run/pass/seqappend.mod FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113559 --- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #3 from Gaius Mulley --- > Created attachment 57205 > --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57205=edit > Proposed fix v2 > > Correction the cast should be the signed sizetype CSSIZE_T. I've just successfully tested this version on both i386-pc-solaris2.11 and sparc-sun-solaris2.11. Thanks.
[Bug testsuite/113558] [14 regression] gcc.dg/vect/vect-outer-4c-big-array.c etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113558 --- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #2 from Robin Dapp --- > Would you mind giving the attached patch a try? I ran it on riscv and power10 > so far, x86 and aarch64 are still in progress. Sure: I tested the patch on sparc-sun-solaris2.11 last night and all but one of the failures are gone. Seems you missed FAIL: gcc.dg/vect/vect-reduc-pattern-2a.c scan-tree-dump-times vect "vect_recog_widen_sum_pattern: detected(?:(?!failed)(?!Re-trying).)*succeeded" 1 Thanks for the quick fix.
[Bug target/112862] [14 regression] gfortran.dg coarray tests FAIL on macOS 12+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112862 --- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #5 from Iain Sandoe --- >> > Now I have a concern that we have instances of -Bpath/to/libsomething/.libs >> > that are present to allow for specs substitution and we also need them for >> > providing run paths at test time. BUT, we do not want duplicates >> > (since, that >> > triggers a different warning for some Xcode versions, and is >> > inefficient anyway >> > - albeit probably a very minor contribution to testing time). >> >> Still there is going to be an impact, even on non-Darwin. However, this >> duplication of -B and -L options is present all over the testsuite >> already, just nobody cared to do something about it so far. Those Xcode >> 15 ld warnings my change this, though... > > Actually, since -B produces a -L for every -B directory that exists, if we add > -B we really ought to omit the -L if it's the same - otherwise we get useless > duplicates on the link line. Do you know of any exception to the B implies L? No. TBH I only really knew about -B to find e.g. library-specific spec files, not for libraries themselves.
[Bug libstdc++/113450] [14 Regression] std/format/functions/format.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113450 --- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #4 from Jonathan Wakely --- > I pushed a slightly different change, but it should be equivalent. Please > reopen if I messed it up :-) The variant worked just fine. Thanks.
[Bug analyzer/111475] Many C++ analyzer tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111475 --- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE --- David, can you provide some help or suggestions here? I'm completely lost in the analyzer code. Thanks.
[Bug target/112862] [14 regression] gfortran.dg coarray tests FAIL on macOS 12+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112862 --- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #3 from Iain Sandoe --- > OK. So I realise the reason you see this and I wasn't: I have the habit of > installing before running the testsuite. When I test uninstalled, then I get > the issue. Right: I always avoid installing before testing to make extra certain to test the freshly built bits and nothing else. > Now I have a concern that we have instances of -Bpath/to/libsomething/.libs > that are present to allow for specs substitution and we also need them for > providing run paths at test time. BUT, we do not want duplicates (since, that > triggers a different warning for some Xcode versions, and is inefficient > anyway > - albeit probably a very minor contribution to testing time). Still there is going to be an impact, even on non-Darwin. However, this duplication of -B and -L options is present all over the testsuite already, just nobody cared to do something about it so far. Those Xcode 15 ld warnings my change this, though... > So I think that gcc/lib/gfortran.exp needs to have the library -B/-L additions > structured so that only one set gets added. I'll draft a patch for you to > try. Great, thanks.
[Bug libstdc++/113450] [14 Regression] std/format/functions/format.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113450 --- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #1 from Jonathan Wakely --- > I assume that int8_t is char on Solaris, rather than signed char? Indeed. AFAIK char being signed goes back to SysVr4 at least (and has bitten us several times already, especially over in LLVM). > Formatting a char behaves differently from signed char, and other integral > types. > > I think this will fix it: [...] > That causes the lambda to use signed char instead of char, and that is > formatted as an integer not a character. It does indeed. Tested on both i386-pc-solaris2.11 and sparc-sun-solaris2.11 for good measure. Thanks!
[Bug target/112863] [14 regression] Many obj-c++ tests FAIL on macOS 12+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112863 --- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #1 from Iain Sandoe --- > which Xcode version produces this? 15.1. Btw., I only see those failures on macOS 14, not earlier versions. > on Darwin23 with XC15.1 I get clean obj-c++ results > (but we should omit the duplicates anyway) Indeed: even in they aren't harmful on other targets, they are just wasted effort.
[Bug target/112862] [14 regression] gfortran.dg coarray tests FAIL on macOS 12+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112862 --- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #1 from Iain Sandoe --- > this appears to be fixed; I get clean fortran testsuite results on (x86_64) > Darwin21 and Darwin23. Please could you check and either close this or post > your Xcode version, configure line and OS version. I'm still seeing this in last Friday's bootstraps: macOS/Darwin versions Xcode version 12.7.2 (21G1974)/21.6.0 14.2 13.6.3 (22G436)/22.6.0 14.3 14.2.1 (23C71)/23.2.0 15.1 The full configure line for macOS 14 is /usr/local/bin/bash /vol/gcc/src/hg/master/darwin/configure --prefix=/vol/gcc --target=x86_64-apple-darwin23.2.0 --disable-multilib --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk --enable-libphobos --enable-objc-gc --with-target-bdw-gc-include=/vol/gcc/include --with-target-bdw-gc-lib=/vol/gcc/lib/amd64,i386=/vol/gcc/lib --with-gmp-include=/vol/gcc/include --with-gmp-lib=/vol/gcc/lib/amd64 --with-mpfr-include=/vol/gcc/include --with-mpfr-lib=/vol/gcc/lib/amd64 --with-mpc-include=/vol/gcc/include --with-mpc-lib=/vol/gcc/lib/amd64 --enable-languages=all,ada,obj-c++ --with-isl-include=/vol/gcc/include --with-isl-lib=/vol/gcc/lib/amd64 --with-zstd-include=/vol/gcc/include --with-zstd-lib=/vol/gcc/lib/amd64 --build=x86_64-apple-darwin23.2.0 --host=x86_64-apple-darwin23.2.0 The other two are equivalent. When I check the coarray_40.exe binary on macOS 14, I find: $ otool -L ./coarray_40.exe ./coarray_40.exe: @rpath/libatomic.1.dylib (compatibility version 4.0.0, current version 4.0.0) @rpath/libgfortran.5.dylib (compatibility version 6.0.0, current version 6.0.0) @rpath/libgcc_s.1.1.dylib (compatibility version 1.0.0, current version 1.1.0) @rpath/libquadmath.0.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1336.61.1) $ otool -l ./coarray_40.exe [...] Load command 14 cmd LC_LOAD_DYLIB cmdsize 56 name @rpath/libatomic.1.dylib (offset 24) time stamp 2 Thu Jan 1 01:00:02 1970 current version 4.0.0 compatibility version 4.0.0 but, unlike for the other libs, *no* corresponding LC_RPATH. If I manually add the right -B arg (-B/private/var/gcc/regression/master/14-gcc/build/x86_64-apple-darwin23.2.0/./libatomic/.libs) to the command line, the missing LC_RPATH shows up and the excutable runs successfully.
[Bug ada/112958] [12/13/14 regression] s-exnllf.ads etc. don't compile on 32-bit FreeBSD/x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112958 --- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #4 from Eric Botcazou --- > Someone motivated enough should add a specific libgnat/s-dorepr__freebsd.adb > unit where Rep64 is an array of two Interfaces.Unsigned_64 and the AND > operation on line 88 is performed on the first component. Thanks for the analysis. I guess I'll leave that to the FreeBSD folks then: this was just one of many issues I found during a trunk FreeBSD bootstrap.
[Bug ada/112958] [14 regression] s-exnllf.ads etc. don't compile on 32-bit FreeBSD/x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112958 --- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #1 from Eric Botcazou --- > The code is the same on the 13 branch though, does it compile there? So far, I had only tried gcc 11.4.0 (where the code compiles) and trunk (where it doesn't). Now, I've tried both the gcc-12 and gcc-13 branches and both fail like trunk.
[Bug target/113140] [SPARC] [13 Regression] Segmentation fault during RTL pass: dbr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113140 --- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #5 from Rainer Orth --- > It's also helpful to include the cc1plus invocation from g++ -v; that includes > all you need to reproduce. The full one is cc1plus -fpreprocessed qv4qobjectwrapper.cpp.ii -mptr64 -mstack-bias -mno-v8plus -quiet -m64 -mcpu=v9 -g -O2 -std=c++17 -version -flto=auto -ffat-lto-objects -fstack-protector-strong -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -fno-exceptions -o qv4qobjectwrapper.cpp.s With the original testcase and cc1plus from the gcc-13 branch, this can be reduced to cc1plus -fpreprocessed qv4qobjectwrapper.cpp.ii -mptr64 -mstack-bias -mno-v8plus -quiet -m64 -mcpu=v9 -O2 -fno-exceptions -o qv4qobjectwrapper.cpp.s while without -fno-exceptions the test compiles in this configuration. Fortunately, I managed to reduce the testcase as attached, which SEGVs even without -fno-exceptions. On trunk, the original testcase compiles without issues, while the reduced one SEGVs since gcc-8 (didn't try before) up to trunk.
[Bug go/86535] FreeBSD/PowerPC64 - Building Go Frontend support for gcc 7.3.0 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86535 --- Comment #38 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #37 from Ian Lance Taylor --- > Search for this comment in the top-level configure.ac file. > > # Disable libgo for some systems where it is known to not work. > # For testing, you can easily override this with --enable-libgo. Ah, I'd missed that, being more used to the various lib*/configure.tgt files. The disadvantage of having this in the toplevel configure.ac is that this file is shared with binutils-gdb. > That said if you don't configure with --enable-languages=go then you shouldn't > get libgo. True. However, I did configure with --enable-languages=all (which expanded to c,ada,c++,d,fortran,go,lto,m2,objc,obj-c++,rust). Unfortunately, we lack a --disable-languages=, so you need to use --enable-languages=, which is guaranteed to break (or rather miss new languages) as has happened to me for m2 and rust. It's best if GCC self-defends against configurations which are known not to work instead of having developers run into the trap first ;-)
[Bug middle-end/112917] Most strub execution tests FAIL on SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112917 --- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #2 from Alexandre Oliva --- > Nevermind, I've managed to log into the cfarm machines running solaris/sparc. Good: while the Solaris 11.3/SPARC system (cfarm211) seems to have worked fine for me, the Solaris 11.4 one (cfarm106) is off for 4 months. I hope to add new Solaris 11.4/SPARC (and x86) cfarm hosts myself early next year.
[Bug testsuite/112728] gcc.dg/scantest-lto.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112728 --- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #3 from Jorn Wolfgang Rennecke --- > (In reply to Rainer Orth from comment #0) >> The gcc.dg/scantest-lto.c FAILs on quite a number of targets: > ... >> * On Darwin, the __TEXT,__eh_frame contains .ascii because the assembler >> lacks support for cfi directives. > > I suppose we could handle the darwin case by: > > - Not doing the common scan-assembler* tests for darwin I guess it would be better to use the recently introduce cfi effective-target keyword to catch targets that would show ascii in there. > - doing a scan-assembler-times test that expects exactly how many .ascii are > emitted for cfi. While that's an option, I suspect that's going too far actually.
[Bug testsuite/112729] gcc.target/i386/apx-interrupt-1.c etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112729
--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #3 from Hongyu Wang ---
[...]
> Hi Rainer, can you help verify if the change make these test pass on
> solaris/FreeBSD?
They do on Solaris/x86. Thanks.
FreeBSD was more involved (I'd only noticed the failure there on
gcc-testresults). Unfortunately, there's no FreeBSD/x86_64 system in
the cfarm. However, I had an old FreeBSD 13 VM around which could be
coaxed into a gcc build with some effort. With your patch, the failures
are gone there, too.
One nit:
diff --git a/gcc/testsuite/gcc.target/i386/apx-push2pop2-1.c
b/gcc/testsuite/gcc.target/i386/apx-push2pop2-1.c
index d78c96d36a3..1d73aab1128 100644
--- a/gcc/testsuite/gcc.target/i386/apx-push2pop2-1.c
+++ b/gcc/testsuite/gcc.target/i386/apx-push2pop2-1.c
@@ -1,5 +1,5 @@
/* { dg-do compile { target { ! ia32 } } } */
-/* { dg-options "-O2 -mapx-features=push2pop2" } */
+/* { dg-options "-O2 -fomit-frame-pointer -mapx-features=push2pop2" } */
/* { dg-skip-if "does not emit .cfi_xxx" "*-*-darwin*" } */
extern int bar (int);
diff --git a/gcc/testsuite/gcc.target/i386/apx-push2pop2_force_drap-1.c
b/gcc/testsuite/gcc.target/i386/apx-push2pop2_force_drap-1.c
index 3cac7b10769..4e2259f0c99 100644
--- a/gcc/testsuite/gcc.target/i386/apx-push2pop2_force_drap-1.c
+++ b/gcc/testsuite/gcc.target/i386/apx-push2pop2_force_drap-1.c
@@ -1,5 +1,5 @@
/* { dg-do compile { target { ! ia32 } } } */
-/* { dg-options "-O2 -mapx-features=push2pop2 -mforce-drap" } */
+/* { dg-options "-O2 -mapx-features=push2pop2 -fomit-frame-pointer
-mforce-drap" } */
/* { dg-skip-if "does not emit .cfi_xxx" "*-*-darwin*" } */
#include "apx-push2pop2-1.c"
Is there a reason to have -fomit-frame-pointer once before and once
after -mapx-features=push2pop2?
[Bug testsuite/112729] gcc.target/i386/apx-interrupt-1.c etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112729 --- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #2 from Hongyu Wang --- > The cfi scan fails was caused by -fno-omit-frame-pointer which force push the > frame pointer first and the cfi info become different. By default we have > -fomit-frame-pointer on linux, but not other targets. I'd just add > -fomit-frame-pointer to these tests. That's one of the first differences between Linux and other x86 targets that come to mind. I'd have sworn that's what I tried before reporting the bug. Apparently not ;-(
[Bug sanitizer/112563] [14 regression] libsanitizer doesn't assemble with Solaris/sparc as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112563 --- Comment #12 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #11 from ro at CeBiTec dot Uni-Bielefeld.DE Uni-Bielefeld.DE> --- >> --- Comment #10 from Jakub Jelinek --- >> (In reply to r...@cebitec.uni-bielefeld.de from comment #9) [...] >> If it works, nice. Can you file it on github.com/llvm/llvm-project as an >> issue >> and see if upstream is willing to accept it? I think they'll want some > > Can do, either as an issue or directly as a pull request. I'll run it > through a full llvm build, too, first. Unfortunately, this didn't work out at all. Initially, I had only rebuilt libsanitizer with the patch, checking that there were only the exepected number of calls to mem* functions in libasan.so. The LLVM build on Solaris/sparcv9, while successful, doesn't tell you much, unfortunately: due to a clang bug on sparc, the asan tests are never run there. When I ran a full Solaris/SPARC bootstrap, all asan tests FAILed with AddressSanitizer: CHECK failed: asan_rtl.cpp:397 "((!AsanInitIsRunning() && "ASan init calls itself!")) != (0)" (0x0, 0x0) (tid=1) I've once had the misfortune of debugging such a initializion order issue in LLVM, and that was an long and painful experience which I'd rather not repeat here. The fix found in that case (build both libasan.so and all asan tests with -z now) didn't work here, either: this just turned the assertion failures into SEGVs. This reliance on init order is a total nightmare: the details are completely platform-specific and not portable at all. Given all this, I've instead developed a patch that checks for assembler a = b support in the libsanitizer configury and uses the result in sanitizer_redefine_builtins.h. This way, only the one configuration that has an issue here is punished. However, this has to stay local to libsanitizer for obvious reasons.
[Bug sanitizer/112562] [14 regression] asan_interceptors_memintrinsics.cpp doesn't assemble with Solaris/x86 as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112562 --- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE --- > Should be fixed now I believe. It is indeed: thanks for the quick fix.
[Bug c++/112652] g++.dg/cpp26/literals2.C FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112652 --- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #1 from Jakub Jelinek --- > Strange. On cfarm211 which is > SunOS gcc-solaris11 5.11 11.3 sun4u sparc SUNW,SPARC-Enterprise > the test passes. Can you check which libiconv got picked up there? The non-standard OpenCSW packages on that system may include GNU libiconv and install into default system directories, so they are picked up by default. > You get no diagnostics for those lines at all? Buggy libconv? No. There's no separate libiconv on Solaris; the iconv* functions are included in libc. > I mean the emojis certainly aren't in ISO-8859-1... Probably not ;-) FWIW, I've just built trunk with GNU libiconv 1.17 on i386-pc-solaris2.11. The test PASSes now with both LANG=C and LANG=en_US.UTF-8. I'll dig further into Solaris iconv functions here...
[Bug other/112671] libiconv support lacks separate --with-libiconv-{include,lib}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112671 --- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #3 from Arsen Arsenović --- > hm, actually, I think I confused reports - sorry. > > do you know if this worked a short while ago? and if so, how did such a > configuration look? I have no idea: at least AFAICS back to the gcc-11 branch (didn't look further) there was only --with-libiconv-prefix. Still it's inconsistent with how many (all?) other support libs are handled.
[Bug other/112671] libiconv support lacks separate --with-libiconv-{include,lib}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112671 --- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #1 from Arsen Arsenović --- [...] > I will restore the modifications in the shared tree with the few other patches > I mentioned on the GCC ML recently soon (I've ran a little low on testing > bandwidth this week..) > > apologies for the inconvenience No worries, this is the first time ever I tried this on Solaris and can easily live with 32-bit-only testing for now. Thanks for taking care of this.
