[Bug target/91614] [10 regression][arm] gcc.target/arm/unaligned-memcpy-2.c FAIL since r274986
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91614
--- Comment #2 from Bernd Edlinger ---
In some configs the function saves r4/r5 with strd/ldrd,
I think the dg-final statments should ignore register spills,
they are easy to detect since they always use the sp register.
This changed a bit, since the string constant is 4-byte aligned
and the expansion uses the new unaligned_load for those.
Since the test case was failing already before, I think
the best would be to adapt the test patterns to the reality.
And update those whenever necessary.
like following:
Index: unaligned-memcpy-2.c
===
--- unaligned-memcpy-2.c(revision 275063)
+++ unaligned-memcpy-2.c(working copy)
@@ -15,9 +15,11 @@
loads/stores for the remainder. */
/* { dg-final { scan-assembler-times "ldmia" 0 } } */
-/* { dg-final { scan-assembler-times "ldrd" 0 } } */
+/* { dg-final { scan-assembler-times "ldrd\(?!\[^\\n\]*sp\)" 0 } } */
+/* { dg-final { scan-assembler-times "ldm\(?!ia\)" 0 } } */
/* { dg-final { scan-assembler-times "stmia" 1 { target { ! {
arm_prefer_ldrd_strd } } } } } */
-/* { dg-final { scan-assembler-times "strd" 1 { target { arm_prefer_ldrd_strd
} } } } */
+/* { dg-final { scan-assembler-times "strd\(?!\[^\\n\]*sp\)" 1 { target {
arm_prefer_ldrd_strd } } } } */
+/* { dg-final { scan-assembler-times "stm\(?!ia\)" 0 } } */
/* { dg-final { scan-assembler-times "ldrh" 1 } } */
/* { dg-final { scan-assembler-times "strh" 1 } } */
/* { dg-final { scan-assembler-times "ldrb" 1 } } */
Index: unaligned-memcpy-3.c
===
--- unaligned-memcpy-3.c(revision 275063)
+++ unaligned-memcpy-3.c(working copy)
@@ -15,10 +15,12 @@
loads/stores for the remainder. */
/* { dg-final { scan-assembler-times "ldmia" 1 { target { ! {
arm_prefer_ldrd_strd } } } } } */
-/* { dg-final { scan-assembler-times "ldrd" 1 { target { arm_prefer_ldrd_strd
} } } } */
-/* { dg-final { scan-assembler-times "strd" 0 } } */
-/* { dg-final { scan-assembler-times "stm" 0 } } */
-/* { dg-final { scan-assembler-times "ldrh" 1 { target { ! {
arm_prefer_ldrd_strd } } } } } */
+/* { dg-final { scan-assembler-times "ldrd\(?!\[^\\n\]*sp\)" 1 { target {
arm_prefer_ldrd_strd } } } } */
+/* { dg-final { scan-assembler-times "ldm\(?!ia\)" 0 } } */
+/* { dg-final { scan-assembler-times "stmia" 0 } } */
+/* { dg-final { scan-assembler-times "strd\(?!\[^\\n\]*sp\)" 0 } } */
+/* { dg-final { scan-assembler-times "stm\(?!ia\)" 0 } } */
+/* { dg-final { scan-assembler-times "ldrh" 1 } } */
/* { dg-final { scan-assembler-times "strh" 1 } } */
-/* { dg-final { scan-assembler-times "ldrb" 1 { target { ! {
arm_prefer_ldrd_strd } } } } } */
+/* { dg-final { scan-assembler-times "ldrb" 1 } } */
/* { dg-final { scan-assembler-times "strb" 1 } } */
which does pass in this test:
make check-gcc-c RUNTESTFLAGS="arm.exp=unaligned-memcpy-*
--target_board=unix\{-mcpu=cortex-a57,-mcpu=cortex-a15,-mcpu=cortex-a9,-mcpu=cortex-a8,-mcpu=cortex-a7\}\{-mfpu=crypto-neon-fp-armv8,-mfpu=neon-vfpv4,-mfpu=crypto-neon-fp-armv8\}\{-fno-omit-frame-pointer,\}"
[Bug d/91628] libdruntime uses glibc internal symbol on s390
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91628 Florian Weimer changed: What|Removed |Added CC||fw at gcc dot gnu.org --- Comment #2 from Florian Weimer --- (In reply to Carlos O'Donell from comment #1) > Note that is also the case for Rust which uses > __pthread_get_minstack@@GLIBC_PRIVATE, and this has prevented us from doing > valid and meaningful cleanup of the libpthread internals to remove this > function. The use of __pthread_get_minstack@@GLIBC_PRIVATE in Rust was safe last time I checked, treating a missing function as indicating that glibc will not place the TCB on the stack. The use in OpenJDK follows this pattern too. If we change TCB allocation not to use the stack anymore, we can remove the function at the same time, and Rust and OpenJDK will still do the right thing. (This is just an aside here, of course.)
[Bug testsuite/65364] FAIL: gcc.dg/uninit-19.c (test for warnings, line 22)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65364 --- Comment #7 from Iain Sandoe --- Author: iains Date: Sat Aug 31 19:23:54 2019 New Revision: 275248 URL: https://gcc.gnu.org/viewcvs?rev=275248=gcc=rev Log: [Darwin, testsuite] Fix PR 65364 (uninit-19.c). This test currently fails on Darwin, because the port inlines fn2 for both PIC (and non-pic for m32). Fixed by adjusting the target condition. 2019-08-31 Iain Sandoe Backport from mainline. 2019-06-11 Iain Sandoe PR testsuite/65364 * gcc.dg/uninit-19.c (fn1): Adjust target condition for Darwin. (fn2): Likewise. Modified: branches/gcc-8-branch/gcc/testsuite/ChangeLog branches/gcc-8-branch/gcc/testsuite/gcc.dg/uninit-19.c
[Bug pch/61250] Random pch failures with -save-temps on x86_64-apple-darwin1(3-8).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61250 --- Comment #27 from Iain Sandoe --- Author: iains Date: Sat Aug 31 19:12:10 2019 New Revision: 275246 URL: https://gcc.gnu.org/viewcvs?rev=275246=gcc=rev Log: [c-family] Backport fix for PCH / PR61250. When we are parsing a source file, the very first token might be a PRAGMA_GCC_PCH_PREPROCESS. This indicates that we are going read in a PCH file (named as the value of the pragma). If we don't see this pragma, then we know that it's OK to release any resources that the host might have set aside for the PCH file. There is a thinko in the current implementation, in that the decision to release resources is happening unconditionally right after the first token is extracted but before it's been checked or acted upon. This leads to the pch bug on Darwin, because we actually do release resources - which are subsequently (reasonably) assumed to be available when reading a PCH file. We then get random crashes or hangs depending on the interaction between unmmap and malloc. The bug is present everywhere but doesn't show on (say) Linux, since the release of PCH resources is a NOP there. This effects all the c-family front ends, because they all use c_lex_with_flags () to implement this. The solution is to check for the PRAGMA_GCC_PCH_PREPROCESS and only call c_common_no_more_pch () when that is not the first token. A secondary effect of the collection is that the name of the PCH file can be collected during the ggc_pch_read() reset of state. Therefore we should issue any diagnostic that might name the file before the collections are triggered. gcc/ 2019-08-31 Iain Sandoe Backport from mainline 2019-08-23 Iain Sandoe PR pch/61250 * ggc-page.c (ggc_pch_read): Read the ggc_pch_ondisk structure and issue any diagnostics needed before collecting the pre-PCH state. gcc/c-family/ 2019-08-31 Iain Sandoe Backport from mainline 2019-08-23 Iain Sandoe PR pch/61250 * c-lex.c (c_lex_with_flags): Don't call c_common_no_more_pch () from here. gcc/c/ 2019-08-31 Iain Sandoe Backport from mainline. 2019-08-23 Iain Sandoe PR pch/61250 * c-parser.c (c_parse_file): Call c_common_no_more_pch () after determining that the first token is not PRAGMA_GCC_PCH_PREPROCESS. gcc/cp/ 2019-08-31 Iain Sandoe Backported from mainline 2019-08-23 Iain Sandoe PR pch/61250 * parser.c (cp_parser_initial_pragma): Call c_common_no_more_pch () after determining that the first token is not PRAGMA_GCC_PCH_PREPROCESS. Modified: branches/gcc-9-branch/gcc/ChangeLog branches/gcc-9-branch/gcc/c-family/ChangeLog branches/gcc-9-branch/gcc/c-family/c-lex.c branches/gcc-9-branch/gcc/c/ChangeLog branches/gcc-9-branch/gcc/c/c-parser.c branches/gcc-9-branch/gcc/cp/ChangeLog branches/gcc-9-branch/gcc/cp/parser.c branches/gcc-9-branch/gcc/ggc-page.c
[Bug debug/82738] [meta-bug] issues with the -Og optimization level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82738 Bug 82738 depends on bug 89794, which changed state. Bug 89794 Summary: combine incorrectly forwards register value through auto-inc operation https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89794 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug rtl-optimization/89794] combine incorrectly forwards register value through auto-inc operation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89794 Segher Boessenkool changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Segher Boessenkool --- Fixed on 9 and trunk. Closing.
[Bug target/91481] POWER9 "DARN" RNG intrinsic produces repeated output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91481 --- Comment #17 from Segher Boessenkool --- Author: segher Date: Sat Aug 31 19:01:52 2019 New Revision: 275245 URL: https://gcc.gnu.org/viewcvs?rev=275245=gcc=rev Log: rs6000: Fix darn-3.c for GCC 8 and GCC 7 Apparently I didn't properly test the testcase backport to GCC 8 and GCC 7. This makes it not fail there. PR target/91481 * gcc.target/powerpc/darn-3.c: Fix testcase. Modified: branches/gcc-7-branch/gcc/testsuite/ChangeLog branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/darn-3.c
[Bug target/91481] POWER9 "DARN" RNG intrinsic produces repeated output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91481 --- Comment #16 from Segher Boessenkool --- Author: segher Date: Sat Aug 31 18:58:04 2019 New Revision: 275244 URL: https://gcc.gnu.org/viewcvs?rev=275244=gcc=rev Log: rs6000: Fix darn-3.c for GCC 8 and GCC 7 Apparently I didn't properly test the testcase backport to GCC 8 and GCC 7. This makes it not fail there. PR target/91481 * gcc.target/powerpc/darn-3.c: Fix testcase. Modified: branches/gcc-8-branch/gcc/testsuite/ChangeLog branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/darn-3.c
[Bug c++/91607] [9 regression] internal compiler error: in equal, at cp/constexpr.c:1088
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91607 --- Comment #6 from Marek Polacek --- That's why I haven't closed the PR. Trunk seems to emit a potentially bogus error, reducing that.
[Bug target/91323] LTGT rtx produces UCOMISS instead of COMISS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91323 Eric Botcazou changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org --- Comment #14 from Eric Botcazou --- The test fails on SPARC too because it was aligned with the x86. We really need to make a global decision about LTGT, otherwise we should keep the status quo and revert the x86 change.
[Bug driver/91629] New: gcc-ar assumes that GCC_EXEC_PREFIX is ${bindir}, but it is ${libdir}/gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91629
Bug ID: 91629
Summary: gcc-ar assumes that GCC_EXEC_PREFIX is ${bindir}, but
it is ${libdir}/gcc
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: driver
Assignee: unassigned at gcc dot gnu.org
Reporter: sjc at immunant dot com
Target Milestone: ---
Created attachment 46795
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46795=edit
Proposed fix to handle GCC_EXEC_PATH correctly
If available, gcc-ar grabs its binary path (self) from the GCC_EXEC_PREFIX. It
then constructs a relative path difference between standard_bin_prefix and
standard_exec_prefix to make self_exec_prefix:
self_exec_prefix = make_relative_prefix (self,
standard_bin_prefix,
standard_exec_prefix);
The gcc frontend sets GCC_EXEC_PREFIX to the exec_prefix, not the bin_prefix:
gcc_exec_prefix = get_relative_prefix (decoded_options[0].arg,
standard_bindir_prefix,
standard_exec_prefix);
gcc_libexec_prefix = get_relative_prefix (decoded_options[0].arg,
standard_bindir_prefix,
standard_libexec_prefix);
if (gcc_exec_prefix)
xputenv (concat ("GCC_EXEC_PREFIX=", gcc_exec_prefix, NULL));
Normally this just happens to work, but if libdir and bindir were set to custom
paths in configure, then this can break.
I've attached a proposed fix, although I haven't had a chance to test it in the
environment I found this (a yocto build environment).
[Bug c++/91607] [9 regression] internal compiler error: in equal, at cp/constexpr.c:1088
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91607 --- Comment #5 from Hannes Hauswedell --- > (In reply to Marek Polacek from comment #4) > The ICE was fixed by r266816. But not for GCC9? I can confirm that GCC 9.2.1 snapshot from 20190817 still triggers the bug.
[Bug lto/91626] FAIL: gcc.dg/lto/pr48622 c_lto_pr48622_0.o-c_lto_pr48622_0.o link, -O -flto -finline-small-functions -fno-early-inlining
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91626 --- Comment #2 from dave.anglin at bell dot net --- On 2019-08-31 12:10 p.m., marxin at gcc dot gnu.org wrote: > Can you please bisect that what caused the regression? >From test results, revision 263930 was okay. Test failed in revision 264295. Will try to narrow this down.
[Bug d/91628] libdruntime uses glibc internal symbol on s390
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91628 Carlos O'Donell changed: What|Removed |Added CC||carlos at redhat dot com --- Comment #1 from Carlos O'Donell --- If the D runtime, or libphobos in particular, has a need to get a lower-level view of the TLS runtime then we should work together to formalize what's required and provide a low-level TLS ABI. Note that is also the case for Rust which uses __pthread_get_minstack@@GLIBC_PRIVATE, and this has prevented us from doing valid and meaningful cleanup of the libpthread internals to remove this function. The related glibc bug is here: https://sourceware.org/bugzilla/show_bug.cgi?id=16291 It would be great to get feedback on the required API and needs.
[Bug tree-optimization/91570] [10 Regression] ICE in get_range_strlen_dynamic on a conditional of two strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91570
--- Comment #2 from Martin Liška ---
One more test-case with a bit different backtrace:
$ cat ice.i
int a;
int fprintf(int *, char *, ...);
char *strcat();
char *strrchr();
void store_sif(outname, src, offset, incr, height) char *outname;
char src;
int offset, incr, height;
{
char *b, *c, *d = outname, *e = strrchr(d, '/');
strcat(outname, ".SIF");
b = e ?: d;
c = b;
fprintf(, "saving %s\n", c);
}
$ gcc ice.i -c -O2
during GIMPLE pass: strlen
ice.i: In function ‘store_sif’:
ice.i:5:6: internal compiler error: tree check: expected integer_cst, have
plus_expr in get_len, at tree.h:5826
5 | void store_sif(outname, src, offset, incr, height) char *outname;
| ^
0x72ffde tree_check_failed(tree_node const*, char const*, int, char const*,
...)
/home/marxin/Programming/gcc/gcc/tree.c:9925
0x70e3d9 get_range_strlen_dynamic
/home/marxin/Programming/gcc/gcc/tree.h:3519
0xf69eb3 get_range_strlen_dynamic(tree_node*, c_strlen_data*, vr_values const*)
/home/marxin/Programming/gcc/gcc/tree-ssa-strlen.c:1037
0x161aec6 get_string_length
/home/marxin/Programming/gcc/gcc/gimple-ssa-sprintf.c:1980
0x161aec6 format_string
/home/marxin/Programming/gcc/gcc/gimple-ssa-sprintf.c:2170
0x161b856 format_directive
/home/marxin/Programming/gcc/gcc/gimple-ssa-sprintf.c:2730
0x161f2b3 compute_format_length
/home/marxin/Programming/gcc/gcc/gimple-ssa-sprintf.c:3532
0x161f2b3 handle_printf_call(gimple_stmt_iterator*, vr_values const*)
/home/marxin/Programming/gcc/gcc/gimple-ssa-sprintf.c:4199
0xf700d7 strlen_check_and_optimize_call
/home/marxin/Programming/gcc/gcc/tree-ssa-strlen.c:4459
0xf700d7 check_and_optimize_stmt
/home/marxin/Programming/gcc/gcc/tree-ssa-strlen.c:4595
0xf700d7 strlen_dom_walker::before_dom_children(basic_block_def*)
/home/marxin/Programming/gcc/gcc/tree-ssa-strlen.c:4822
0x15d73a7 dom_walker::walk(basic_block_def*)
/home/marxin/Programming/gcc/gcc/domwalk.c:309
0xf652d9 printf_strlen_execute
/home/marxin/Programming/gcc/gcc/tree-ssa-strlen.c:4888
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug lto/91627] FAIL: gcc.dg/lto/20081201-2 c_lto_20081201-2_0.o-c_lto_20081201-2_1.o execute -O3 -flto -flto-partition=1to1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91627
--- Comment #1 from John David Anglin ---
-bash-4.4$ cat /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/lto/20081201-2_0.c
/* { dg-lto-options {{-O3 -flto -flto-partition=1to1}} } */
/* Test that cross-TU inlining works. */
extern void abort ();
extern void exit (int);
extern void *foo (void);
int
main ()
{
if (foo () != __builtin_return_address (0))
abort ();
exit (0);
}
(gdb) r
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program:
/test/gnu/gcc/objdir/gcc/testsuite/gcc/gcc-dg-lto-20081201-2-01.exe
warning: Private mapping of shared library text was not specified
by the executable; setting a breakpoint in a shared library which
is not privately mapped will not work. See the HP-UX 11i v3 chatr
manpage for methods to privately map shared library text.
Breakpoint 2, 0x40005644 in main ()
at /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/lto/20081201-2_0.c:12
12if (foo () != __builtin_return_address (0))
(gdb) disass
Dump of assembler code for function main:
0x40005628 <+0>: std rp,-10(sp)
0x4000562c <+4>: std,ma r4,80(sp)
0x40005630 <+8>: ldo -30(sp),ret1
0x40005634 <+12>:std r3,-78(sp)
0x40005638 <+16>:copy rp,r3
0x4000563c <+20>:b,l 0x40002c60 ,rp
0x40005640 <+24>:copy dp,r4
=> 0x40005644 <+28>:cmpb,*<> r3,ret0,0x40005658
0x40005648 <+32>:copy r4,dp
0x4000564c <+36>:ldo -30(sp),ret1
0x40005650 <+40>:b,l 0x400019c0 <.stub>,rp
0x40005654 <+44>:ldi 0,r26
0x40005658 <+48>:ldo -30(sp),ret1
0x4000565c <+52>:b,l 0x40005668 <.stub>,rp
0x40005660 <+56>:nop
0x40005664 <+60>:nop
End of assembler dump.
(gdb) p/x $r3
$4 = 0xc000b8fb
(gdb) p/x $ret0
$5 = 0x40005647
[Bug d/91628] New: libdruntime uses glibc internal symbol on s390
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91628 Bug ID: 91628 Summary: libdruntime uses glibc internal symbol on s390 Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: d Assignee: ibuclaw at gdcproject dot org Reporter: aurelien at aurel32 dot net CC: ibuclaw at gcc dot gnu.org Target Milestone: --- Host: s390x-ibm-linux-gnu Target: s390x-ibm-linux-gnu Build: s390x-ibm-linux-gnu libdruntime on s390 uses a GNU libc internal symbol: __tls_get_addr_internal. Things might break if the symbol is changed on the GNU libc side.
[Bug lto/91627] New: FAIL: gcc.dg/lto/20081201-2 c_lto_20081201-2_0.o-c_lto_20081201-2_1.o execute -O3 -flto -flto-partition=1to1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91627 Bug ID: 91627 Summary: FAIL: gcc.dg/lto/20081201-2 c_lto_20081201-2_0.o-c_lto_20081201-2_1.o execute -O3 -flto -flto-partition=1to1 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org CC: marxin at gcc dot gnu.org Target Milestone: --- Host: hppa64-hp-hpux11.11 Target: hppa64-hp-hpux11.11 Build: hppa64-hp-hpux11.11 Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/ -f no-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color =never -O3 -flto -flto-partition=1to1 -c -o c_lto_20081201-2_0.o /test/gnu/g cc/gcc/gcc/testsuite/gcc.dg/lto/20081201-2_0.c(timeout = 300) spawn /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/ -fno-diagnostics -show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -O3 -fl to -flto-partition=1to1 -c -o c_lto_20081201-2_0.o /test/gnu/gcc/gcc/gcc/testsui te/gcc.dg/lto/20081201-2_0.c PASS: gcc.dg/lto/20081201-2 c_lto_20081201-2_0.o assemble, -O3 -flto -flto-parti tion=1to1 Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/ -f no-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color =never -O3 -flto -flto-partition=1to1 -c -o c_lto_20081201-2_1.o /test/gnu/g cc/gcc/gcc/testsuite/gcc.dg/lto/20081201-2_1.c(timeout = 300) spawn /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/ -fno-diagnostics -show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -O3 -fl to -flto-partition=1to1 -c -o c_lto_20081201-2_1.o /test/gnu/gcc/gcc/gcc/testsui te/gcc.dg/lto/20081201-2_1.c PASS: gcc.dg/lto/20081201-2 c_lto_20081201-2_1.o assemble, -O3 -flto -flto-parti tion=1to1 Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/ c_l to_20081201-2_0.o c_lto_20081201-2_1.o -fno-diagnostics-show-caret -fno-diagnos tics-show-line-numbers -fdiagnostics-color=never -O3 -flto -flto-partition=1to1 -o gcc-dg-lto-20081201-2-01.exe(timeout = 300) spawn /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/ c_lto_20081201-2 _0.o c_lto_20081201-2_1.o -fno-diagnostics-show-caret -fno-diagnostics-show-line -numbers -fdiagnostics-color=never -O3 -flto -flto-partition=1to1 -o gcc-dg-lto- 20081201-2-01.exe PASS: gcc.dg/lto/20081201-2 c_lto_20081201-2_0.o-c_lto_20081201-2_1.o link, -O3 -flto -flto-partition=1to1 Setting LD_LIBRARY_PATH to :/test/gnu/gcc/objdir/gcc:/test/gnu/gcc/objdir/hppa64 -hp-hpux11.11/./libatomic/.libs::/test/gnu/gcc/objdir/gcc:/test/gnu/gcc/objdir/h ppa64-hp-hpux11.11/./libatomic/.libs spawn [open ...] FAIL: gcc.dg/lto/20081201-2 c_lto_20081201-2_0.o-c_lto_20081201-2_1.o execute -O3 -flto -flto-partition=1to1
[Bug lto/91626] FAIL: gcc.dg/lto/pr48622 c_lto_pr48622_0.o-c_lto_pr48622_0.o link, -O -flto -finline-small-functions -fno-early-inlining
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91626 Martin Liška changed: What|Removed |Added Keywords||needs-bisection Status|UNCONFIRMED |WAITING Last reconfirmed||2019-08-31 Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Can you please bisect that what caused the regression?
[Bug middle-end/91623] [7/8/9/10 Regression] -msse4.1 -O3 segfault in /usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/include/smmintrin.h:270:10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91623
--- Comment #3 from Jakub Jelinek ---
--- gcc/optabs.c.jj 2019-08-27 12:26:37.392912813 +0200
+++ gcc/optabs.c2019-08-31 18:00:59.838412487 +0200
@@ -5868,6 +5868,8 @@ expand_vec_cond_expr (tree vec_cond_type
icode = get_vcond_icode (mode, cmp_op_mode, unsignedp);
if (icode == CODE_FOR_nothing)
{
+ if (tcode == LT_EXPR && op0a == op0)
+ tcode = NE_EXPR;
if (tcode == EQ_EXPR || tcode == NE_EXPR)
icode = get_vcond_eq_icode (mode, cmp_op_mode);
if (icode == CODE_FOR_nothing)
fixes this, though perhaps before doing that we should verify op0a is a vector
constant containing just 0s and -1s.
Or for the VECTOR_CST op0 fold it in the expander.
[Bug lto/91626] New: FAIL: gcc.dg/lto/pr48622 c_lto_pr48622_0.o-c_lto_pr48622_0.o link, -O -flto -finline-small-functions -fno-early-inlining
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91626 Bug ID: 91626 Summary: FAIL: gcc.dg/lto/pr48622 c_lto_pr48622_0.o-c_lto_pr48622_0.o link, -O -flto -finline-small-functions -fno-early-inlining Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org CC: marxin at gcc dot gnu.org Target Milestone: --- Host: hppa64-hp-hpux11.11 Target: hppa64-hp-hpux11.11 Build: hppa64-hp-hpux11.11 Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/ -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -O -flto -finline-small-functions -fno-early-inlining -c -o c_lto_pr48622_0.o /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/lto/pr48622_0.c(timeout = 300) spawn /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/ -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -O -flto -finline-small-functions -fno-early-inlining -c -o c_lto_pr48622_0.o /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/lto/pr48622_0.c PASS: gcc.dg/lto/pr48622 c_lto_pr48622_0.o assemble, -O -flto -finline-small-functions -fno-early-inlining Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/ c_lto_pr48622_0.o -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -O -flto -finline-small-functions -fno-early-inlining-o gcc-dg-lto-pr48622-01.exe(timeout = 300) spawn /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/ c_lto_pr48622_0.o -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -O -flto -finline-small-functions -fno-early-inlining -o gcc-dg-lto-pr48622-01.exe ld: Unsatisfied symbol "ashift_qi_1" in file /var/tmp//gcc-dg-lto-pr48622-01.exe.mbbTyk.ltrans0.ltrans.o 1 errors. collect2: fatal error: ld returned 1 exit status compilation terminated. compiler exited with status 1 output is: ld: Unsatisfied symbol "ashift_qi_1" in file /var/tmp//gcc-dg-lto-pr48622-01.exe.mbbTyk.ltrans0.ltrans.o 1 errors. collect2: fatal error: ld returned 1 exit status compilation terminated. FAIL: gcc.dg/lto/pr48622 c_lto_pr48622_0.o-c_lto_pr48622_0.o link, -O -flto -finline-small-functions -fno-early-inlining
[Bug tree-optimization/91625] New: FAIL: gcc.dg/strlenopt-68.c execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91625 Bug ID: 91625 Summary: FAIL: gcc.dg/strlenopt-68.c execution test Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org Target Milestone: --- Host: hppa64-hp-hpux11.11 Target: hppa64-hp-hpux11.11 Build: hppa64-hp-hpux11.11 spawn /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/ /test/gnu/gcc/gc c/gcc/testsuite/gcc.dg/strlenopt-68.c -fno-diagnostics-show-caret -fno-diagnosti cs-show-line-numbers -fdiagnostics-color=never -O2 -Wall -lm -o ./strlenopt-68.e xe PASS: gcc.dg/strlenopt-68.c (test for excess errors) Setting LD_LIBRARY_PATH to :/test/gnu/gcc/objdir/gcc:/test/gnu/gcc/objdir/hppa64 -hp-hpux11.11/./libatomic/.libs::/test/gnu/gcc/objdir/gcc:/test/gnu/gcc/objdir/h ppa64-hp-hpux11.11/./libatomic/.libs spawn [open ...] assertion failed on line 41: snprintf (0, 0, "%s", p) == 4 FAIL: gcc.dg/strlenopt-68.c execution test
[Bug go/91617] [10 regression] Many go test case failures after r275026
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91617 --- Comment #3 from Ian Lance Taylor --- To see how to run libgo tests, see the Debugging section in libgo/README. The problem you are having with runtime.osinit looks related to a recent libgo patch (https://gcc.gnu.org/ml/gcc-patches/2019-08/msg01916.html). It looks like you somehow linked against an older version of libgo.
[Bug tree-optimization/91624] New: FAIL: gcc.dg/tree-ssa/sra-18.c scan-tree-dump-times esra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91624 Bug ID: 91624 Summary: FAIL: gcc.dg/tree-ssa/sra-18.c scan-tree-dump-times esra Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org Target Milestone: --- Host: hppa64-hp-hpux11.11 Target: hppa64-hp-hpux11.11 Build: hppa64-hp-hpux11.11 Created attachment 46794 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46794=edit Tree dump Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/ /te st/gnu/gcc/gcc/gcc/testsuite/gcc.dg/tree-ssa/sra-18.c -fno-diagnostics-show-car et -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -O2 -fdump-tre e-esra --param sra-max-scalarization-size-Ospeed=32 -lm-o ./sra-18.exe ( timeout = 300) spawn /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/ /test/gnu/gcc/gc c/gcc/testsuite/gcc.dg/tree-ssa/sra-18.c -fno-diagnostics-show-caret -fno-diagno stics-show-line-numbers -fdiagnostics-color=never -O2 -fdump-tree-esra --param s ra-max-scalarization-size-Ospeed=32 -lm -o ./sra-18.exe PASS: gcc.dg/tree-ssa/sra-18.c (test for excess errors) Setting LD_LIBRARY_PATH to :/test/gnu/gcc/objdir/gcc:/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libatomic/.libs::/test/gnu/gcc/objdir/gcc:/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libatomic/.libs spawn [open ...] PASS: gcc.dg/tree-ssa/sra-18.c execution test gcc.dg/tree-ssa/sra-18.c: pattern found 0 times FAIL: gcc.dg/tree-ssa/sra-18.c scan-tree-dump-times esra "Removing load: a = \\*.?L.?C.?.?.?0;" 1 gcc.dg/tree-ssa/sra-18.c: pattern found 0 times FAIL: gcc.dg/tree-ssa/sra-18.c scan-tree-dump-times esra "SR\\.[0-9_]+ = \\*.?L.?C.?.?.?0\\.b\\[0\\]\\.f\\[0\\]\\.x" 1 gcc.dg/tree-ssa/sra-18.c: pattern found 0 times FAIL: gcc.dg/tree-ssa/sra-18.c scan-tree-dump-times esra "SR\\.[0-9_]+ = \\*.?L.?C.?.?.?0\\.b\\[0\\]\\.f\\[1\\]\\.x" 1 gcc.dg/tree-ssa/sra-18.c: pattern found 0 times FAIL: gcc.dg/tree-ssa/sra-18.c scan-tree-dump-times esra "SR\\.[0-9_]+ = \\*.?L.?C.?.?.?0\\.b\\[1\\]\\.f\\[0\\]\\.x" 1 gcc.dg/tree-ssa/sra-18.c: pattern found 0 times FAIL: gcc.dg/tree-ssa/sra-18.c scan-tree-dump-times esra "SR\\.[0-9_]+ = \\*.?L.?C.?.?.?0\\.b\\[1\\]\\.f\\[1\\]\\.x" 1 Similar fail: Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/ /te st/gnu/gcc/gcc/gcc/testsuite/gcc.dg/tree-ssa/sra-17.c -fno-diagnostics-show-car et -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -O2 -fdump-tre e-esra --param sra-max-scalarization-size-Ospeed=32 -lm-o ./sra-17.exe ( timeout = 300) spawn /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/ /test/gnu/gcc/gc c/gcc/testsuite/gcc.dg/tree-ssa/sra-17.c -fno-diagnostics-show-caret -fno-diagno stics-show-line-numbers -fdiagnostics-color=never -O2 -fdump-tree-esra --param s ra-max-scalarization-size-Ospeed=32 -lm -o ./sra-17.exe PASS: gcc.dg/tree-ssa/sra-17.c (test for excess errors) Setting LD_LIBRARY_PATH to :/test/gnu/gcc/objdir/gcc:/test/gnu/gcc/objdir/hppa64 -hp-hpux11.11/./libatomic/.libs::/test/gnu/gcc/objdir/gcc:/test/gnu/gcc/objdir/h ppa64-hp-hpux11.11/./libatomic/.libs spawn [open ...] PASS: gcc.dg/tree-ssa/sra-17.c execution test gcc.dg/tree-ssa/sra-17.c: pattern found 0 times FAIL: gcc.dg/tree-ssa/sra-17.c scan-tree-dump-times esra "Removing load: a = \\* .?L.?C.?.?.?0;" 1 gcc.dg/tree-ssa/sra-17.c: pattern found 0 times FAIL: gcc.dg/tree-ssa/sra-17.c scan-tree-dump-times esra "SR\\.[0-9_]+ = \\*.?L. ?C.?.?.?0\\[" 4 These are not new fails. Gcc 7, 8 and 9 also fail for this target. For some reason, I thought these fails were a regexp issue and didn't look at the tree dump. The tests pass on 32-bit hppa targets. I see that these tests only run on a selected set of targets.
[Bug libstdc++/91620] std::[forward_]list::remove_if/unique should respect to DR 526
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91620 --- Comment #2 from frankhb1989 at gmail dot com --- I missed `unique` should be also affected. The fixes have been applied in libc++ in the same commit to fix `remove_if`. MSVC's current implementations are also correct, with a different implementation strategy. It uses a singly liked list for nodes pending to delete.
[Bug middle-end/91623] [7/8/9/10 Regression] -msse4.1 -O3 segfault in /usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/include/smmintrin.h:270:10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91623 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED CC||jakub at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Target Milestone|--- |7.5 Summary|[7/8/9 Regression] -msse4.1 |[7/8/9/10 Regression] |-O3 segfault in |-msse4.1 -O3 segfault in |/usr/lib/gcc/x86_64-pc-linu |/usr/lib/gcc/x86_64-pc-linu |x-gnu/8.3.0/include/smmintr |x-gnu/8.3.0/include/smmintr |in.h:270:10 |in.h:270:10 --- Comment #2 from Jakub Jelinek --- Started with r241525. I'll have a look.
[Bug c++/91622] Compiler internal error DJGPP GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91622 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2019-08-31 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- There is no attachment.
[Bug c++/38175] Explicit instantiation of a template hides symbols with the default visibility attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38175 Bradly changed: What|Removed |Added CC||bradley2844maximus at gmx dot com --- Comment #4 from Bradly --- Isn't the visibility set to "hidden" by default? https://igreviewhub.org/
[Bug middle-end/91623] [7/8/9 Regression] -msse4.1 -O3 segfault in /usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/include/smmintrin.h:270:10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91623
Marc Glisse changed:
What|Removed |Added
Keywords||ice-on-valid-code
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-08-31
Component|c |middle-end
Ever confirmed|0 |1
--- Comment #1 from Marc Glisse ---
typedef long long b __attribute__((__vector_size__(16)));
b e, h;
int d;
const int i;
void m();
void j(int k, int l) {
if (d && 0 <= k - 1 && l)
m();
}
void p() {
b n = (b){1};
b g = (b){};
b o = g;
for (int f=0; f < i; ++f) {
b a = o == n;
h = a;
j(f, i);
o = e;
}
}
Program received signal SIGSEGV, Segmentation fault.
0x00c0f5f8 in expand_expr_real_1 (exp=,
target=0x775da960, tmode=E_V2DImode, modifier=EXPAND_NORMAL,
alt_rtl=0x7fffd3f0, inner_reference_p=false) at
/home/glisse/repos/gcc/trunk/gcc/expr.c:9961
9961 if (REG_P (r) && !REG_EXPR (r))
(gdb) bt
#0 0x00c0f5f8 in expand_expr_real_1 (exp=,
target=0x775da960, tmode=E_V2DImode, modifier=EXPAND_NORMAL,
alt_rtl=0x7fffd3f0, inner_reference_p=false) at
/home/glisse/repos/gcc/trunk/gcc/expr.c:9961
#1 0x00c07d19 in expand_expr_real (exp=,
target=0x775da960, tmode=E_V2DImode, modifier=EXPAND_NORMAL,
alt_rtl=0x7fffd3f0, inner_reference_p=false) at
/home/glisse/repos/gcc/trunk/gcc/expr.c:8280
#2 0x00bfd2ae in store_expr (exp=,
target=0x775da960, call_param_p=0, nontemporal=false, reverse=false)
at /home/glisse/repos/gcc/trunk/gcc/expr.c:5679
#3 0x00bfb68f in expand_assignment (to=,
from=, nontemporal=false)
at /home/glisse/repos/gcc/trunk/gcc/expr.c:5441
#4 0x00a4bd8d in expand_gimple_stmt_1 (stmt=) at /home/glisse/repos/gcc/trunk/gcc/cfgexpand.c:3777
Seems to happen for the statement
a_6 = VEC_COND_EXPR <{ 0, -1 }, { -1, -1 }, { 0, 0 }>;
which was created by DOM3 (missed constant folding?).
[Bug c/91623] New: [7/8/9 Regression] -msse4.1 -O3 segfault in /usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/include/smmintrin.h:270:10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91623
Bug ID: 91623
Summary: [7/8/9 Regression] -msse4.1 -O3 segfault in
/usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/include/smmintr
in.h:270:10
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: soap at gentoo dot org
Target Milestone: ---
Created attachment 46793
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46793=edit
Minimum test case
Under certain conditions, GCC raises an ICE. I have used creduce to produce a
minimal example:
typedef long long a __attribute__((__vector_size__(16)));
typedef long long b __attribute__((__vector_size__(16)));
b c, e, g, h;
d;
const i;
j(k, l) {
if (d && 0 <= k - 1 && l)
m();
}
p() {
int f = 0;
c = (a){1};
b n = c;
g = (a){};
b o = g;
for (; f < i; ++f) {
b a = o == n;
h = a;
j(f, i);
o = e;
}
}
gcc-6.5.0 -msse4.1 -O3 -c test.c: PASS
gcc-6.5.0 -msse4.1 -O2 -c test.c: PASS
gcc-7.4.0 -msse4.1 -O3 -c test.c: FAIL
gcc-7.4.0 -msse4.1 -O2 -c test.c: PASS
gcc-8.3.0 -msse4.1 -O3 -c test.c: FAIL
gcc-8.3.0 -msse4.1 -O2 -c test.c: PASS
gcc-9.2.0 -msse4.1 -O3 -c test.c: FAIL
gcc-9.2.0 -msse4.1 -O2 -c test.c: PASS
In all failure cases I get the error
during RTL pass: expand
test.c: In function ‘p’:
test.c:10:1: internal compiler error: Segmentation fault
[Bug tree-optimization/91616] Incorrect data address computation in very simple code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91616 --- Comment #1 from Mikael Pettersson --- Please provide a self-contained test case with a built-in check of its correctness, or at least a printout of the computed array. I did the latter locally, and data_array[] looks correct to me (it contains 0xcafebebedeadbeef up to 0xcafebebedeadbefe as one would expect from the source code).
[Bug target/91602] GCC fails to build for riscv in a combined tree due to misconfigured leb128 support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91602 --- Comment #7 from Serge Belyshev --- (In reply to Jim Wilson from comment #5) > When you build packages separately, each package after the first uses > feature tests to configure itself appropriately to use the earlier packages. > When you use a combined tree build, feature tests can't be used because > earlier packages haven't been installed yet, so configure just makes > guesses. We have the most commonly correct results hardwired in as guesses. > This was fine when packages were smaller, and we had a smaller number of > targets. I believe that this particular problem was fixed since r17 which made configure-gcc depend on all-gas. Which means that there is no need to treat in-tree case specially anymore, and the proper fix is appears to be very simple: --- a/gcc/acinclude.m4 +++ b/gcc/acinclude.m4 @@ -532,10 +532,8 @@ AC_DEFUN([gcc_GAS_CHECK_FEATURE], [AC_REQUIRE([gcc_GAS_FLAGS])dnl AC_CACHE_CHECK([assembler for $1], [$2], [[$2]=no - ifelse([$3],,,[dnl - if test $in_tree_gas = yes; then -gcc_GAS_VERSION_GTE_IFELSE($3, [[$2]=yes]) - el])if test x$gcc_cv_as != x; then + ifelse([$3],,,) +if test x$gcc_cv_as != x; then AS_ECHO([ifelse(m4_substr([$5],0,1),[$], "[$5]", '[$5]')]) > conftest.s if AC_TRY_COMMAND([$gcc_cv_as $gcc_cv_as_flags $4 -o conftest.o conftest.s >_MESSAGE_LOG_FD]) then
[Bug target/91612] [10 regression][arm] gcc.target/arm/aapcs/align4.c ICE after r274986
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91612 Bernd Edlinger changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-08-31 Assignee|unassigned at gcc dot gnu.org |edlinger at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Bernd Edlinger --- Created attachment 46792 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46792=edit untested patch This is a untested patch it should fix pr91612 pr91613 pr91615 (?) pr91603 and pr91605 (i386) but probably not 91614
[Bug go/91617] [10 regression] Many go test case failures after r275026
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91617 --- Comment #2 from Jakub Jelinek --- Or something is wrong in the go FE langhooks. Anyway, I have no idea how to debug this, the libgo libgo.log doesn't contain anything that would make it clear how to run the tests and even looking at the simpler gcc/testsuite/go/go.log, there is command how to compile/link the test, but not how to run it. LD_LIBRARY_PATH=/home/jakub/src/gcc/obj52/x86_64-pc-linux-gnu/./libgo/.libs ./select5.exe ./select5.exe: symbol lookup error: ./select5.exe: undefined symbol: runtime.osinit LD_LIBRARY_PATH=/home/jakub/src/gcc/obj54/x86_64-pc-linux-gnu/./libgo/.libs ./select5.exe panic: "recv": template: recv:1: unexpected goroutine 1 [running]: main.parse /home/jakub/src/gcc/gcc/testsuite/go.test/test/chan/select5.go:142
[Bug fortran/91552] ICE with valid array constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91552 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 CC||kargl at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |kargl at gcc dot gnu.org --- Comment #2 from kargl at gcc dot gnu.org --- I have a patch that is currently regression testing.
