[Bug tree-optimization/94727] [10 Regression] GCC produces incorrect code with -O3 since r10-5071-g02d895504cc59be0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94727 --- Comment #10 from CVS Commits --- The master branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:e62a820d686d1fa97a9eefdc65ca07d8f96ac9f4 commit r10-8006-ge62a820d686d1fa97a9eefdc65ca07d8f96ac9f4 Author: Richard Sandiford Date: Tue Apr 28 08:04:29 2020 +0100 vect: Fix COND_EXPRs involving variant booleans [PR94727] The previous patch for this PR handled separate comparisons. However, as arm targets show, the same fix is needed when handling comparisons embedded in a VEC_COND_EXPR. Here too, the problem is that vect_get_constant_vectors will calculate its own vector type, using truth_type_for on the STMT_VINFO_VECTYPE, and the vectoriable_* routines need to be consistent with that. 2020-04-28 Richard Sandiford gcc/ PR tree-optimization/94727 * tree-vect-stmts.c (vect_is_simple_cond): If both comparison operands are invariant booleans, use the mask type associated with the STMT_VINFO_VECTYPE. Use !slp_node instead of !vectype to exclude SLP. (vectorizable_condition): Pass vectype unconditionally to vect_is_simple_cond.
[Bug rtl-optimization/94804] Failure to elide useless movs in 128-bit addition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94804 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2020-04-28 Status|UNCONFIRMED |NEW
[Bug fortran/94813] New: [10 regression] 'libgomp.fortran/use_device_ptr-1.f90' offloading execution test regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94813
Bug ID: 94813
Summary: [10 regression] 'libgomp.fortran/use_device_ptr-1.f90'
offloading execution test regression
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: openmp
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: tschwinge at gcc dot gnu.org
CC: burnus at gcc dot gnu.org, jakub at gcc dot gnu.org,
tkoenig at gcc dot gnu.org
Target Milestone: ---
The recent commit 06eca1acafa27e19e82dc73927394a7a4d0bdbc5 "Fix PR 93956, wrong
pointer when returned via function" regresses in offloading configurations (at
least gcn, nvptx):
PASS: libgomp.fortran/use_device_ptr-1.f90 -O0 (test for excess errors)
[-PASS:-]{+FAIL:+} libgomp.fortran/use_device_ptr-1.f90 -O0 execution
test
... for all torture testing variants.
Program received signal SIGSEGV, Segmentation fault.
0x00409976 in omp_device_ptr () at
source-gcc/libgomp/testsuite/libgomp.fortran/use_device_ptr-1.f90:508
508 call copy3_array1(AptrA, BptrB)
(gdb) bt
#0 0x00409976 in omp_device_ptr () at
source-gcc/libgomp/testsuite/libgomp.fortran/use_device_ptr-1.f90:508
#1 0x0040b564 in main (argc=1, argv=0x7fffd971) at
source-gcc/libgomp/testsuite/libgomp.fortran/use_device_ptr-1.f90:423
#2 0x770f5b97 in __libc_start_main () from
/lib/x86_64-linux-gnu/libc.so.6
#3 0x00400c6a in _start ()
No regression seen for host-fallback execution.
[Bug fortran/94813] [10 regression] 'libgomp.fortran/use_device_ptr-1.f90' offloading execution test regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94813 Thomas Schwinge changed: What|Removed |Added Last reconfirmed||2020-04-28 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |burnus at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Thomas Schwinge --- Tobias, please have a look.
[Bug tree-optimization/94809] [8/9/10 Regression] Different results between gcc-9 and gcc-6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94809 --- Comment #5 from Richard Biener --- LGTM
[Bug tree-optimization/94809] [8/9/10 Regression] Different results between gcc-9 and gcc-6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94809 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug fortran/94813] [10 regression] 'libgomp.fortran/use_device_ptr-1.f90' offloading execution test regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94813 Richard Biener changed: What|Removed |Added Target Milestone|--- |10.0
[Bug fortran/94813] [10 regression] 'libgomp.fortran/use_device_ptr-1.f90' offloading execution test regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94813 Tobias Burnus changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Tobias Burnus --- (In reply to Thomas Schwinge from comment #1) > Tobias, please have a look. That's not that difficult – as Thomas K has written shortly before you filled this PR: https://gcc.gnu.org/pipermail/fortran/2020-April/054270.html "... and also caused a regression, see PR 94788. Reverted on trunk so far, so the upcoming release is OK. This will still take some more work, I suppose..." And: commit r10-8001-gd8df7c404e233abb1e26d8b8370c460732904531 Author: Thomas Koenig Date: Mon Apr 27 23:49:36 2020 +0200 Revert r10-7920-g06eca1acafa27e19e82dc73927394a7a4d0bdbc5 . Hence: Duplicate of PR 94788 *** This bug has been marked as a duplicate of bug 94788 ***
[Bug fortran/94788] [8/9 Regression] Severe regression leading to double free in tcache
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94788 Tobias Burnus changed: What|Removed |Added CC||tschwinge at gcc dot gnu.org --- Comment #24 from Tobias Burnus --- *** Bug 94813 has been marked as a duplicate of this bug. ***
[Bug c++/94771] g++.dg/concepts/diagnostic10.C fails on mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94771 --- Comment #4 from Bence Szabó --- Interesting, the t.f syntax is not allowed anymore even with MSVC: https://godbolt.org/z/YCK-mv msvc also doesn't list under extensions_ https://docs.microsoft.com/en-us/cpp/build/reference/microsoft-extensions-to-c-and-cpp?view=vs-2015 and some recent overview on ms extensions: https://stackoverflow.com/questions/56554567/what-does-the-ms-extensions-flag-do-exactly-with-gcc Is this a dinosaur that forgot to die?
[Bug ipa/94472] 400.perlbench is slower when compiled at -O2 with both PGO and LTO on AMD Zen CPUs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94472 --- Comment #3 from Martin Jambor --- My benchmarking setup is currently gone so unfortunately no, not easily. I'll be re-measuring everything on a different computer with a slightly different CPU model soon, so after that I guess I could. But it is most likely the limits, yes.
[Bug fortran/94788] [8/9 Regression] Severe regression leading to double free in tcache
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94788 --- Comment #25 from Jürgen Reuter --- (In reply to Thomas Koenig from comment #23) > (In reply to Jürgen Reuter from comment #20) > > Thanks a lot for reverting, Thomas, shall I further reduce the reproducer, > > or can you work with it now? > > I could use it to confirm that there is a bug, but the test case is > far too complex for analysis, and it is also not possible to put > it in the testsuite. So, at the moment, work on PR 93956 (a F95 wrong-code > bug, hence a high priority) is effectively blocked. > > So yes, I would appreciate a shorter reproducer, especially since > I plan to revisit the whole span and pointer area once gcc 10 > is out of the door. > > So, I'll mark this bug as WAITING for now. Ok, Simon and I try our best, working independently, me reducing the existing case further, and he tries to write a small reproducer from scratch.
[Bug fortran/94788] [8/9 Regression] Severe regression leading to double free in tcache
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94788 --- Comment #26 from Jürgen Reuter --- At least there is no time pressure at the moment ...
[Bug c++/94760] coroutines: mismatch between traits and promise parameter preview.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94760 Iain Sandoe changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Iain Sandoe --- fixed on master
[Bug target/94704] [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on s390x/s390
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94704
--- Comment #5 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:dde5ce541e3258276848aee85229a71c0e5f6965
commit r10-8007-gdde5ce541e3258276848aee85229a71c0e5f6965
Author: Jakub Jelinek
Date: Tue Apr 28 10:26:24 2020 +0200
s390: -Wpsabi diagnostics for C++14 vs. C++17 ABI incompatibility on
s390{,x} [PR94704]
> We probably have to look into providing a -Wpsabi warning as well.
So like this?
2020-04-28 Jakub Jelinek
PR target/94704
* config/s390/s390.c (s390_function_arg_vector,
s390_function_arg_float): Emit -Wpsabi diagnostics if the ABI
changed.
[Bug ipa/94472] 400.perlbench is slower when compiled at -O2 with both PGO and LTO on AMD Zen CPUs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94472 --- Comment #4 from Bernd Edlinger --- (In reply to Martin Jambor from comment #3) > My benchmarking setup is currently gone so unfortunately no, not easily. > I'll be re-measuring everything on a different computer with a slightly > different CPU model soon, so after that I guess I could. But it is most > likely the limits, yes. Yeah, easy to fix, but it takes some time. But this is not more important than your life. Shall I raise this to P1 so it prevents gcc-10 release?
[Bug ipa/94472] 400.perlbench is slower when compiled at -O2 with both PGO and LTO on AMD Zen CPUs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94472 --- Comment #5 from Jakub Jelinek --- No, we can't block GCC 10 release indefinitely, we are already behind the usual schedule. We need to resolve the C++ ABI issues and get the release out.
[Bug ipa/94472] 400.perlbench is slower when compiled at -O2 with both PGO and LTO on AMD Zen CPUs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94472 --- Comment #6 from Bernd Edlinger --- (In reply to Jakub Jelinek from comment #5) > No, we can't block GCC 10 release indefinitely, we are already behind the > usual schedule. We need to resolve the C++ ABI issues and get the release > out. Sorry, have you heard of the Corona pandemic out there? This is not like olympic games 2020, which has been cancelled? I just say I would delay gcc 10 right now, before it is too late, this performance regression will make the damage worse.
[Bug ipa/94472] 400.perlbench is slower when compiled at -O2 with both PGO and LTO on AMD Zen CPUs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94472 Bernd Edlinger changed: What|Removed |Added Priority|P3 |P1
[Bug libstdc++/94810] std::cout segmentation fault in __attribute__((constructor)) function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94810 --- Comment #3 from Jonathan Wakely --- There isn't, there's a segfault in your program. That is caused by assuming that the global streams have been constructed already, when it is clearly documented that the construction order is unspecified.
[Bug libstdc++/94811] Please make make_tuple noexcept when possible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94811 --- Comment #2 from Jonathan Wakely --- (In reply to Marc Glisse from comment #1) > Each extra noexcept is one more chance to get things wrong And slows down compilation due to instantiating the trait class templates (which G++ was doing even when not being checked by a noexcept-expression, but I think that might have been fixed recently).
[Bug libstdc++/94811] Please make make_tuple noexcept when possible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94811 --- Comment #3 from Jonathan Wakely --- (In reply to Rafael Avila de Espindola from comment #0) > So it should be possible to make the std::tuple constructor and Isn't that already done? > std::make_tuple noexcept when the arguments have noexcept copy or move > constructors. make_tuple should depend on the tuple being constructed, not on the individual elements, because make_tuple is constructing a tuple, not constructing the elements. But I think this is slightly complicated by guaranteed copy elision in C++17. For C++14 the make_tuple function depends on whether constructing the tuple can throw *and* whether copying the return value can throw, for C++17 it only depends on the former.
[Bug testsuite/94725] Tests with proprietary license notices
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94725 Paul Thomas changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #3 from Paul Thomas --- (In reply to Richard Biener from comment #1) > CCing "authors" of the testcase. Thanks Joseph and Richie, I have a slot tomorrow morning, when I can deal with it. My preference would be to go through the testcases to check which features are not tested elsewhere so that I can write replacements. This might take a little longer than one morning. The pity is that, although Mark LeAir gave permission for use and the testcases were published openly, the copyright is still held by Nvidia. Of the two, dtio_5.f90 is the most straightforward to replace. pdt_5.f03 contains a few workarounds to cover features not yet handled by gfortran. I must make sure that there are PRs to cover them. Best regards Paul
[Bug fortran/94788] [8/9 Regression] Severe regression leading to double free in tcache
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94788 --- Comment #27 from Thomas Koenig --- (In reply to Jürgen Reuter from comment #25) > Ok, Simon and I try our best, working independently, me reducing the > existing case further, and he tries to write a small reproducer from scratch. Thanks a lot! That is really appreciated.
[Bug ipa/94472] 400.perlbench is slower when compiled at -O2 with both PGO and LTO on AMD Zen CPUs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94472 --- Comment #7 from Richard Biener --- (In reply to Bernd Edlinger from comment #4) > (In reply to Martin Jambor from comment #3) > > My benchmarking setup is currently gone so unfortunately no, not easily. > > I'll be re-measuring everything on a different computer with a slightly > > different CPU model soon, so after that I guess I could. But it is most > > likely the limits, yes. > > Yeah, easy to fix, but it takes some time. > But this is not more important than your life. Note tuning parameters is hard and takes a lot of time. If we adjust things to make 400.perlbench happy which is btw. from SPEC 2006(!) we're going to regress things elsewhere. It's going to be a whack-a-mole game and definitely not suitable at this stage (inliner re-tuning is also prone to trigger latent GCC issues in previously fine compiling apps). > Shall I raise this to P1 so it prevents gcc-10 release? Definitely not. Setting priority is the release managers job, and btw. bug priority is meaningless for non-regression bugreports.
[Bug ipa/94472] 400.perlbench is slower when compiled at -O2 with both PGO and LTO on AMD Zen CPUs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94472 Richard Biener changed: What|Removed |Added Status|NEW |WAITING --- Comment #8 from Richard Biener --- Oh, and bugfixing requires to first understand the bug. Especially for performance related issues understanding what goes wrong is important. I see no analysis being performed to date.
[Bug tree-optimization/94809] [8/9/10 Regression] Different results between gcc-9 and gcc-6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94809
--- Comment #6 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:34f6b14ff33e0c64b3a4a1a2cd871df715d69151
commit r10-8009-g34f6b14ff33e0c64b3a4a1a2cd871df715d69151
Author: Jakub Jelinek
Date: Tue Apr 28 11:26:56 2020 +0200
tree: Fix up TREE_SIDE_EFFECTS on internal calls [PR94809]
On the following testcase, match.pd during GENERIC folding
changes the -1U / x < y into __imag__ .MUL_OVERFLOW (x, y),
but unfortunately unlike for normal calls nothing sets TREE_SIDE_EFFECTS on
the call. There is the process_call_operands function that non-internal
call creation calls and it is usable for internal calls too,
e.g. TREE_SIDE_EFFECTS is derived from checking whether the
call has side-effects (non-ECF_{CONST,PURE}; we have those for internal
calls) and from whether any of the arguments has TREE_SIDE_EFFECTS.
2020-04-28 Jakub Jelinek
PR tree-optimization/94809
* tree.c (build_call_expr_internal_loc_array): Call
process_call_operands.
* gcc.c-torture/execute/pr94809.c: New test.
[Bug tree-optimization/94809] [8/9 Regression] Different results between gcc-9 and gcc-6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94809 Jakub Jelinek changed: What|Removed |Added Summary|[8/9/10 Regression] |[8/9 Regression] Different |Different results between |results between gcc-9 and |gcc-9 and gcc-6 |gcc-6 --- Comment #7 from Jakub Jelinek --- Fixed for 10.1 for now.
[Bug debug/94474] Incorrect DWARF range information for inlined function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94474 --- Comment #10 from Andrew Burgess --- Bernd, Not a problem, always happy to expand on things. This might get a little long, but hopefully it should give you an idea what I think is wrong. I have not updated the reproducer, I don't know why I would need to do that, as the existing example demonstrates the issues. My original comment did use an older version of binutils though, which is why I saw =<8e8> Unknown AT value: 2138: 3=, which was unfortunate. I'm now using binutils 2.34. To reduce the length of this post I'm only looking at the first inlined subroutine, this is the worst offender, the issues with the other two are just repeats of this one. >From the reproducer I'm only looking at the *-v3 output files. Here's the DWARF for the first inlined subroutine: #+BEGIN_EXAMPLE <2><8dd>: Abbrev Number: 38 (DW_TAG_inlined_subroutine) <8de> DW_AT_abstract_origin: <0x9ce> <8e2> DW_AT_entry_pc: 0x401165 <8ea> DW_AT_GNU_entry_view: 0 <8eb> DW_AT_ranges : 0x30 <8ef> DW_AT_call_file : 1 <8f0> DW_AT_call_line : 52 <8f1> DW_AT_call_column : 10 <8f2> DW_AT_sibling : <0x931> #+END_EXAMPLE It references the range information at offset 0x30, which can be seen here, the duplication is just an objdump oddity, the ranges we care about are the first four lines starting with =0030=: #+BEGIN_EXAMPLE Contents of the .debug_ranges section: Offset BeginEnd 00401160 004011ca 00401040 00401045 0030 00401165 00401165 (start == end) 0030 00401169 00401173 0030 00401040 00401045 0030 0030 00401165 00401165 (start == end) 0030 00401169 00401173 0030 00401040 00401045 0030 0070 00401160 004011ca 0070 00401040 00401045 0070 00401050 00401065 0070 #+END_EXAMPLE Next, here's a snippet of disassembler, this covers two of the ranges from the above, the empty one =0x401165= to =0x401165=, and then =0x401169= to =0x401173=. The range =0x401040= to =0x401045= I'm ignoring for now, it's just some out of line cold code and not important for this discussion: #+BEGIN_EXAMPLE 00401160 <_Z13get_alias_setP4tree>: 401160: 48 85 fftest %rdi,%rdi 401163: 74 4b je 4011b0 <_Z13get_alias_setP4tree+0x50> 401165: 48 83 ec 08 sub$0x8,%rsp 401169: 8b 07 mov(%rdi),%eax 40116b: 85 c0 test %eax,%eax 40116d: 0f 85 cd fe ff ff jne401040 <_Z13get_alias_setP4tree.cold> 401173: 8b 47 04mov0x4(%rdi),%eax 401176: 83 f8 01cmp$0x1,%eax 401179: 74 28 je 4011a3 <_Z13get_alias_setP4tree+0x43> 40117b: 8b 07 mov(%rdi),%eax 40117d: 85 c0 test %eax,%eax #+END_EXAMPLE Finally, a snippet of the line table covering the same disassembler region as above: #+BEGIN_EXAMPLE test-v3: file format elf64-x86-64 Contents of the .debug_line section: CU: ./step-and-next-inline.cc: File nameLine numberStarting addressView Stmt step-and-next-inline.cc 500x401160 x step-and-next-inline.cc 510x401160 1 x step-and-next-inline.cc 540x401160 2 ./step-and-next-inline.h:[++] step-and-next-inline.h320x401165 x step-and-next-inline.h340x401165 1 x ./step-and-next-inline.cc:[++] step-and-next-inline.cc 500x401165 2 ./step-and-next-inline.h:[++] step-and-next-inline.h340x401169 step-and-next-inline.h340x40116b step-and-next-inline.h360x401173 x step-and-next-inline.h370x401173 1 x step-and-next-inline.h370x401173 2 ./step-and-next-inline.cc:[++] step-and-next-inline.cc 520x401173 3 step-and-next-inline.cc 520x401176 #+END_EXAMPLE Here is what I think GCC could have produced for the range information instead: #+BEGIN_EXAMPLE 0030 00401165 00401176 0030 00401040 00401045 0
[Bug ipa/94472] 400.perlbench is slower when compiled at -O2 with both PGO and LTO on AMD Zen CPUs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94472 --- Comment #9 from Jan Hubicka --- > --- Comment #8 from Richard Biener --- > Oh, and bugfixing requires to first understand the bug. Especially for > performance related issues understanding what goes wrong is important. > I see no analysis being performed to date. The problem here is that -O2 -fprofile-use is now using -O2 inliner limits while previously it used -O3 inliner limit (because -fprofile-use enables -finline-functions). I can see this on SPEC GCC, perl, Firefox, real GCC and clang. We now have performance diference between -O2+FDO and -O3+FDO. It is something I kind of missed in my testing, because I was testing -O2 and -O3 + FDO but not -O2+FDO. I realize that -O2+FDO is kind of important because we use it in our bootstrap. So i was collecting data over weekend for Clang, GCC and Firefox. It is question how agressive we want to be at -O2+FDO but the observation is that in all these programs the code size growth for -O3 style limits is quite small (bellow 2%) simply because thraining coverage is quite small in all those programs (sub 10%) and thus the code size growth for inlining hot calls is acceptable and thus I think the current defaults are really suboptimal. I think there are few ways to proceed 1) make inline limits with FDO to be -O3 ones 2) invent yet another set of parameters for FDO 3) increase importance of known_hot hint that is set of calls that are known to be hot (either by inlining or by hot attribute). 1 is easiest but bit non-sytematic. I am not really keen about 2 because if parameter explosion. However 3 looks like good alternative so I am running benchmarks with few settings of it, but they take some time. Honza
[Bug tree-optimization/89430] A missing ifcvt optimization to generate csel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89430 Tamar Christina changed: What|Removed |Added CC||tnfchris at gcc dot gnu.org --- Comment #14 from Tamar Christina --- Indeed, we should revisit this for GCC 11 as the partial revert has caused a 5% regression in leela.
[Bug target/94814] New: [9 Regression] ICE: RTL check: expected code 'const_int', have 'reg' in output_3367, at config/aarch64/atomics.md:755
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94814
Bug ID: 94814
Summary: [9 Regression] ICE: RTL check: expected code
'const_int', have 'reg' in output_3367, at
config/aarch64/atomics.md:755
Product: gcc
Version: 8.4.1
Status: UNCONFIRMED
Keywords: ice-checking
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: zsojka at seznam dot cz
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Target: aarch64-unknown-linux-gnu
Created attachment 48391
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48391&action=edit
reduced testcase
This looks like a recent regression on the 8-branch. This was fixed on the
9-branch in PR94518, but now the problem triggers on the 8-branch as well.
Compiler output:
$ /repo/build-gcc-8-branch-aarch64/./gcc/cc1plus tsan_interface_atomic.ii
void b()
Analyzing compilation unit
Performing interprocedural optimizations
<*free_lang_data>
Assembling functions:
void b()during RTL pass: final
tsan_interface_atomic.ii: In function 'void b()':
tsan_interface_atomic.ii:2:41: internal compiler error: RTL check: expected
code 'const_int', have 'reg' in output_3367, at config/aarch64/atomics.md:755
void b() { __sync_fetch_and_and(&a, c); }
^
0x74e65b rtl_check_failed_code1(rtx_def const*, rtx_code, char const*, int,
char const*)
/repo/gcc-8-branch/gcc/rtl.c:849
0x8d28f2 output_3367
/repo/gcc-8-branch/gcc/config/aarch64/atomics.md:755
0xd446db final_scan_insn_1
/repo/gcc-8-branch/gcc/final.c:3111
0xd44dcb final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
/repo/gcc-8-branch/gcc/final.c:3224
0xd450b7 final_1
/repo/gcc-8-branch/gcc/final.c:2091
0xd45ee6 rest_of_handle_final
/repo/gcc-8-branch/gcc/final.c:4677
0xd45ee6 execute
/repo/gcc-8-branch/gcc/final.c:4755
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug fortran/94788] [8/9 Regression] Severe regression leading to double free in tcache
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94788 --- Comment #28 from Jürgen Reuter --- Created attachment 48392 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48392&action=edit 3rd reproducer, down to 600 kb
[Bug fortran/94788] [8/9 Regression] Severe regression leading to double free in tcache
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94788 --- Comment #29 from Jürgen Reuter --- Is this now small enough?
[Bug target/94743] IRQ handler doesn't save scratch VFP registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94743 --- Comment #3 from Christophe Lyon --- Maybe we could - save the VFP registers as needed by default - emit a warning "IRQ handler 'foo' saves VFP registers because it is not a leaf function. If you know none of the callees will clobber the VFP registers you can use the 'IRQ-dont-push-VFP-regs' attribute" - implement this new attribute such that users can disable such long vpush sequences
[Bug target/94743] IRQ handler doesn't save scratch VFP registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94743 Christophe Lyon changed: What|Removed |Added CC||ktkachov at gcc dot gnu.org --- Comment #4 from Christophe Lyon --- Adding Kyrylo so that he can share Arm's thoughts.
[Bug c/94815] New: Abusive -Wrestrict warning with sprintf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94815
Bug ID: 94815
Summary: Abusive -Wrestrict warning with sprintf
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent.riviere at freesbee dot fr
Target Milestone: ---
Target: m68k-elf
Testcase:
$ cat foo.c && m68k-elf-gcc -c foo.c -Wall -O
char *strcpy(char *, const char *);
int sprintf(char *, const char *, ...);
char* myalloc(int n);
void f(void)
{
char* buf = myalloc(20);
char* str1 = buf;
char* str2 = buf + 10;
strcpy(str2, "123");
sprintf(str1, "ABC%s", str2);
}
foo.c: In function 'f':
foo.c:13:5: warning: 'sprintf' argument 3 may overlap destination object 'buf'
[-Wrestrict]
13 | sprintf(str1, "ABC%s", str2);
| ^~~~
This warning is a unexpected because:
1) strcpy() and sprintf() are declared without __restrict, but __restrict rules
are still actually used.
2) In this simple example, it is obvious that the buffer will not overflow.
This is annoying, because it prevents creating several logical buffers from a
single allocation.
[Bug middle-end/93517] bogus -Wrestrict on sprintf with unknown strings bounded by array size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93517 Vincent Riviere changed: What|Removed |Added CC||vincent.riviere at freesbee dot fr --- Comment #1 from Vincent Riviere --- Bug #94815 is similar to this one.
[Bug fortran/94769] Possible use of uninitialized variable num
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94769 --- Comment #8 from Stefan Schulze Frielinghaus --- Patch posted: https://gcc.gnu.org/pipermail/gcc-patches/2020-April/544716.html
[Bug c++/94808] [ICE] [Regression] Segfault during diagnostics from concept check failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94808
Patrick Palka changed:
What|Removed |Added
Last reconfirmed||2020-04-28
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0 |1
Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot
gnu.org
CC||ppalka at gcc dot gnu.org
--- Comment #1 from Patrick Palka ---
Confirmed. Reduced testcase:
template
concept baz = requires (T t, Args... args) { *t; };
template
requires baz
void foo() { }
void bar()
{
foo();
}
GCC 10 segfaults during diagnostics, GCC 9 doesn't.
Looking into it.
[Bug analyzer/94816] New: ICE: Segmentation fault (in ana::region_model::add_region_for_type)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94816
Bug ID: 94816
Summary: ICE: Segmentation fault (in
ana::region_model::add_region_for_type)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
g++-10.0.1-alpha20200426 snapshot (g:29f55115583a0dab6cbac749c4f0804fd88e9536)
ICEs when compiling the following testcase, reduced from
gcc/testsuite/g++.dg/init/array51.C, w/ -O1 -fanalyzer:
struct jr;
struct ch {
int jr::*rx;
};
ch
ad ()
{
return ch ();
}
% g++-10.0.1 -O1 -fanalyzer -c noivoaih.C
during IPA pass: analyzer
noivoaih.C: In function 'ch ad()':
noivoaih.C:10:14: internal compiler error: Segmentation fault
10 | return ch ();
| ^
0xfebacf crash_signal
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200426/work/gcc-10-20200426/gcc/toplev.c:328
0x136769e ana::region_model::add_region_for_type(ana::region_id, tree_node*,
ana::region_model_context*)
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200426/work/gcc-10-20200426/gcc/analyzer/region-model.cc:6491
0x136d918 ana::map_region::get_or_create(ana::region_model*, ana::region_id,
tree_node*, tree_node*, ana::region_model_context*)
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200426/work/gcc-10-20200426/gcc/analyzer/region-model.cc:1832
0x136ec2e ana::region_model::copy_struct_region(ana::region_id,
ana::struct_region*, ana::struct_region*, ana::region_model_context*)
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200426/work/gcc-10-20200426/gcc/analyzer/region-model.cc:1304
0x134e9d1 ana::exploded_node::on_stmt(ana::exploded_graph&, ana::supernode
const*, gimple const*, ana::program_state*, ana::state_change*) const
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200426/work/gcc-10-20200426/gcc/analyzer/engine.cc:1022
0x134f3e1 ana::exploded_graph::process_node(ana::exploded_node*)
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200426/work/gcc-10-20200426/gcc/analyzer/engine.cc:2530
0x134f8ca ana::exploded_graph::process_worklist()
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200426/work/gcc-10-20200426/gcc/analyzer/engine.cc:2348
0x134fffb ana::impl_run_checkers(ana::logger*)
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200426/work/gcc-10-20200426/gcc/analyzer/engine.cc:4029
0x1350bcc ana::run_checkers()
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200426/work/gcc-10-20200426/gcc/analyzer/engine.cc:4097
0x1345778 execute
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200426/work/gcc-10-20200426/gcc/analyzer/analyzer-pass.cc:84
[Bug target/94518] [9 Regression] ICE: RTL check: expected code 'const_int', have 'reg' in output_3774, at config/aarch64/atomics.md:758
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94518 --- Comment #4 from CVS Commits --- The releases/gcc-8 branch has been updated by Andre Simoes Dias Vieira : https://gcc.gnu.org/g:034dfe065033a846761b0a5c35fc86023bee1874 commit r8-10223-g034dfe065033a846761b0a5c35fc86023bee1874 Author: Andre Vieira Date: Tue Apr 28 13:25:43 2020 +0100 aarch64: Fix for PR target/94814 Backport of PR target/94518: Fix memmodel index in aarch64_store_exclusive_pair 2020-04-28 Andre Vieira PR target/94814 Backport from gcc-9. 2020-04-07 Kyrylo Tkachov PR target/94518 2019-09-23 Richard Sandiford * config/aarch64/atomics.md (aarch64_store_exclusive_pair): Fix memmodel index.
[Bug target/94814] [8 Regression] ICE: RTL check: expected code 'const_int', have 'reg' in output_3367, at config/aarch64/atomics.md:755
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94814 --- Comment #1 from CVS Commits --- The releases/gcc-8 branch has been updated by Andre Simoes Dias Vieira : https://gcc.gnu.org/g:034dfe065033a846761b0a5c35fc86023bee1874 commit r8-10223-g034dfe065033a846761b0a5c35fc86023bee1874 Author: Andre Vieira Date: Tue Apr 28 13:25:43 2020 +0100 aarch64: Fix for PR target/94814 Backport of PR target/94518: Fix memmodel index in aarch64_store_exclusive_pair 2020-04-28 Andre Vieira PR target/94814 Backport from gcc-9. 2020-04-07 Kyrylo Tkachov PR target/94518 2019-09-23 Richard Sandiford * config/aarch64/atomics.md (aarch64_store_exclusive_pair): Fix memmodel index.
[Bug target/94814] [8 Regression] ICE: RTL check: expected code 'const_int', have 'reg' in output_3367, at config/aarch64/atomics.md:755
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94814 avieira at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED CC||avieira at gcc dot gnu.org --- Comment #2 from avieira at gcc dot gnu.org --- I believe this is fixed with the above backport.
[Bug c++/94817] New: ICE in add_stmt, at cp/semantics.c:392
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94817
Bug ID: 94817
Summary: ICE in add_stmt, at cp/semantics.c:392
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
g++-10.0.1-alpha20200426 snapshot (g:29f55115583a0dab6cbac749c4f0804fd88e9536)
ICEs when compiling the following testcase, extracted from
clang/testsuite/SemaCXX/coroutines.cpp from the clang 10.0.0 test suite, w/
-fcoroutines:
void no_coroutine_traits() {
co_await 4;
}
template
struct void_t_imp {
using type = void;
};
% g++-10.0.1 -fcoroutines -c e96qfdep.cpp
e96qfdep.cpp: In function 'void no_coroutine_traits()':
e96qfdep.cpp:2:3: error: coroutines require a traits template; cannot find
'std::coroutine_traits'
2 | co_await 4;
| ^~~~
e96qfdep.cpp:2:3: note: perhaps '#include ' is missing
e96qfdep.cpp:8:1: internal compiler error: in add_stmt, at cp/semantics.c:392
8 | };
| ^
0x678153 add_stmt(tree_node*)
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200426/work/gcc-10-20200426/gcc/cp/semantics.c:392
0x89887a finish_struct(tree_node*, tree_node*)
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200426/work/gcc-10-20200426/gcc/cp/class.c:7563
0x999413 cp_parser_class_specifier_1
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200426/work/gcc-10-20200426/gcc/cp/parser.c:23881
0x99b4bb cp_parser_class_specifier
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200426/work/gcc-10-20200426/gcc/cp/parser.c:24180
0x99b4bb cp_parser_type_specifier
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200426/work/gcc-10-20200426/gcc/cp/parser.c:17711
0x99c5c5 cp_parser_decl_specifier_seq
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200426/work/gcc-10-20200426/gcc/cp/parser.c:14359
0x9c3c78 cp_parser_single_declaration
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200426/work/gcc-10-20200426/gcc/cp/parser.c:29396
0x9c402c cp_parser_template_declaration_after_parameters
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200426/work/gcc-10-20200426/gcc/cp/parser.c:29059
0x9c4790 cp_parser_explicit_template_declaration
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200426/work/gcc-10-20200426/gcc/cp/parser.c:29325
0x9c79a9 cp_parser_declaration
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200426/work/gcc-10-20200426/gcc/cp/parser.c:13382
0x9c7fef cp_parser_translation_unit
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200426/work/gcc-10-20200426/gcc/cp/parser.c:4734
0x9c7fef c_parse_file()
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200426/work/gcc-10-20200426/gcc/cp/parser.c:43975
0xae0edb c_common_parse_file()
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200426/work/gcc-10-20200426/gcc/c-family/c-opts.c:1190
[Bug rtl-optimization/94804] Failure to elide useless movs in 128-bit addition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94804
--- Comment #3 from Gabriel Ravier ---
So, things like
uint64_t swap64(uint64_t x)
{
uint64_t a = __builtin_bswap32(x);
x >>= 32;
a <<= 32;
return __builtin_bswap32(x) | a;
}
Having similar problems with useless movs is from the same non well-optimized
register allocation on function boundaries ?
[Bug tree-optimization/94818] New: GCC emits dead bodies of functions whose all calls have been eliminated by optimisations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94818
Bug ID: 94818
Summary: GCC emits dead bodies of functions whose all calls
have been eliminated by optimisations
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: felix.von.s at posteo dot de
Target Milestone: ---
Target: x86_64-linux-gnu
In this code:
__attribute__((__warning__("argh")))
static void foo(void) {
__asm__ (
""
""
);
}
void bar0(int x) {
if (__builtin_constant_p(x))
foo();
}
void bar1(int x) {
if (__builtin_constant_p(x))
foo();
}
No calls to foo are emitted in the final output, and GCC knows this, since no
warnings are emitted. However, GCC will still emit a function body for foo,
unless either the __asm__ statement is removed or both conditions are changed
to integer constant expressions, so that the function is eliminated by one of
the inlining passes.
(I decided to demonstrate it this way instead of using
__attribute__((__noinline__)), just to make sure this is not related to
__attribute__((__noinline__)) somehow implying __attribute__((__used__)).)
[Bug bootstrap/94739] GCC won't build on CET enabled Linux OS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94739 --- Comment #11 from CVS Commits --- The master branch has been updated by H.J. Lu : https://gcc.gnu.org/g:eedc73a224df61694fe4802ddec8eb9ad1822f32 commit r10-8010-geedc73a224df61694fe4802ddec8eb9ad1822f32 Author: H.J. Lu Date: Tue Apr 28 05:42:34 2020 -0700 Check whether -fcf-protection=none -Wl,-z,ibt,-z,shstk work first GCC_CET_HOST_FLAGS uses -Wl,-z,ibt,-z,shstk to check if Linux/x86 host has Intel CET enabled by introducing an Intel CET violation on purpose. To avoid false positive, check whether -Wl,-z,ibt,-z,shstk works first. -fcf-protection=none is added to avoid false negative when -fcf-protection is enabled by default. config/ PR bootstrap/94739 * cet.m4 (GCC_CET_HOST_FLAGS): Add -fcf-protection=none to -Wl,-z,ibt,-z,shstk. Check whether -fcf-protection=none -Wl,-z,ibt,-z,shstk works first. libiberty/ PR bootstrap/94739 * configure: Regenerated. lto-plugin/ PR bootstrap/94739 * configure: Regenerated.
[Bug c++/94819] New: [10 Regression] Inherited and constrained constructors are "ambiguous" even if they aren't Pt. 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94819
Bug ID: 94819
Summary: [10 Regression] Inherited and constrained constructors
are "ambiguous" even if they aren't Pt. 2
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc-bugs at marehr dot dialup.fu-berlin.de
Target Milestone: ---
Hi gcc-team,
a recent report of mine https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94549
fixed my reduced example, but my unreduced test case is still failing.
This is the second attempt at reducing my test case and this came out of it:
```c++
#include
template
concept same_as = std::is_same_v;
template
concept convertible_to = std::is_convertible_v;
template
struct alphabet_tuple_base
{
template
static constexpr bool is_component = (same_as ||
...);
template
static constexpr bool is_indirect_component = !is_component &&
(convertible_to || ...);
// commenting out constexpr works?!
template
requires is_component
constexpr alphabet_tuple_base(component_type) {}
template
requires is_indirect_component
alphabet_tuple_base(indirect_component_type);
};
template
struct structured_rna : alphabet_tuple_base {
using base_type = alphabet_tuple_base;
using base_type::base_type;
};
struct dna4 {};
struct rna4 {
rna4(dna4);
};
struct wuss51 {};
// commenting out any of these works?!
structured_rna t1{wuss51{}};
structured_rna t2{dna4{}};
structured_rna t3{wuss51{}};
```
https://godbolt.org/z/WVvSxb
Note that `is_component` and `is_indirect_component` are mutual exclusive, so
there isn't any ambiguity even if they don't subsume each other.
This worked in gcc-9 with `-fconcepts` and apparently in msvc and clang, too.
```
> g++-git -std=c++2a
:41:41: error: call of overloaded 'structured_rna()' is ambiguous
41 | structured_rna t3{wuss51{}}; // commenting out any of
these works?!
| ^
:20:15: note: candidate: 'constexpr
alphabet_tuple_base::alphabet_tuple_base(component_type) [with
component_type = wuss51; component_types = {rna4, wuss51}]'
20 | constexpr alphabet_tuple_base(component_type) {} // commenting out
constexpr works?!
| ^~~
:30:20: note: inherited here
30 | using base_type::base_type;
|^
:24:5: note: candidate:
'alphabet_tuple_base::alphabet_tuple_base(indirect_component_type)
[with indirect_component_type = indirect_component_type; component_types =
{rna4, wuss51}]'
24 | alphabet_tuple_base(indirect_component_type);
| ^~~
:30:20: note: inherited here
30 | using base_type::base_type;
|^
:28:8: note: candidate: 'constexpr structured_rna::structured_rna(const structured_rna&)'
28 | struct structured_rna : alphabet_tuple_base {
|^~
:28:8: note: candidate: 'constexpr structured_rna::structured_rna(structured_rna&&)'
Compiler returned: 1
```
[Bug bootstrap/94739] GCC won't build on CET enabled Linux OS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94739 H.J. Lu changed: What|Removed |Added Resolution|--- |FIXED Status|REOPENED|RESOLVED --- Comment #12 from H.J. Lu --- Fixed.
[Bug ipa/94472] 400.perlbench is slower when compiled at -O2 with both PGO and LTO on AMD Zen CPUs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94472 --- Comment #10 from Bernd Edlinger --- (In reply to Richard Biener from comment #7) > > > Shall I raise this to P1 so it prevents gcc-10 release? > > Definitely not. Setting priority is the release managers job, and btw. > bug priority is meaningless for non-regression bugreports. Okay, Richard, is this P2 or P3 then, I just wanted you to think about it. ;-) Thanks Bernd.
[Bug libstdc++/94810] std::cout segmentation fault in __attribute__((constructor)) function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94810 --- Comment #4 from Geoffrey Casper --- Wouldn't it make more sense to initialize global objects on a per need basis? So the constructors of unused global objects would never be called and there is no ambiguity of when constructors are called. I'd gladly work on implementing this, but I'd need some more information on the brod design of GCC.
[Bug c++/94819] [10 Regression] Inherited and constrained constructors are "ambiguous" even if they aren't Pt. 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94819
--- Comment #1 from gcc-bugs at marehr dot dialup.fu-berlin.de ---
A slightly more reduced example:
```c++
#include
template
struct alphabet_tuple_base
{
template
requires std::is_same_v
constexpr alphabet_tuple_base(component_type) {} // commenting out
constexpr works?!
template
requires (!std::is_same_v)
alphabet_tuple_base(indirect_component_type) {};
};
template
struct structured_rna : alphabet_tuple_base {
using base_type = alphabet_tuple_base;
using base_type::base_type;
};
struct dna4 {};
struct rna4 {};
structured_rna t1{rna4{}}; // commenting out any of these works?!
structured_rna t2{dna4{}}; // commenting out any of these works?!
structured_rna t3{rna4{}}; // commenting out any of these works?!
```
https://godbolt.org/z/VACou9
[Bug target/94743] IRQ handler doesn't save scratch VFP registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94743 --- Comment #5 from Richard Earnshaw --- This is made more complex due to the fact that the existence of the top 16 D registers depends on the hardware you have, so saving them might require a d32 variant of the ISA, but we can't (quickly) tell in an interrupt context whether or not we have that. It only matters in reality if the interrupt routine calls a function in another translation unit where we can't see what FP registers might be needed. Also, it's not just the registers that need to be saved. The floating point status registers also need to be saved and restored. My initial thoughts are along the lines of... Only try to save FP registers that this function directly clobbers. Provide libgcc routines to save/restore the FP context. Or we could say simply: interrupt routines should be compiled as if with -mgeneral-regs-only and if they want to call some routine that uses FP then they must take it upon themselves to save and restore the FP context.
[Bug target/94820] New: pr94780.c fails with ICE on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94820 Bug ID: 94820 Summary: pr94780.c fails with ICE on aarch64 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: clyon at gcc dot gnu.org Target Milestone: --- Hi, The new gcc.dg/pr94780.c test causes an ICE on aarch64: /gcc/testsuite/gcc.dg/pr94780.c: In function 'foo': /gcc/testsuite/gcc.dg/pr94780.c:8:1: internal compiler error: Segmentation fault 0xd5f4af crash_signal /gcc/toplev.c:328 0xe2b238 contains_struct_check /gcc/tree.h:3400 0xe2b238 convert_nonlocal_reference_op /gcc/tree-nested.c:1065 0x10cf01b walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*, tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*)) /gcc/tree.c:12000 0xa34d93 walk_gimple_op(gimple*, tree_node* (*)(tree_node**, int*, void*), walk_stmt_info*) /gcc/gimple-walk.c:268 0xa355e4 walk_gimple_stmt(gimple_stmt_iterator*, tree_node* (*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*), walk_stmt_info*) /gcc/gimple-walk.c:596 0xa357e8 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*), walk_stmt_info*) /gcc/gimple-walk.c:51 0xa35682 walk_gimple_stmt(gimple_stmt_iterator*, tree_node* (*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*), walk_stmt_info*) /gcc/gimple-walk.c:606 0xa357e8 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*), walk_stmt_info*) /gcc/gimple-walk.c:51 0xe23ac1 walk_body /gcc/tree-nested.c:713 0xe24508 walk_function /gcc/tree-nested.c:724 0xe24508 walk_all_functions /gcc/tree-nested.c:789 0xe2a1af lower_nested_functions(tree_node*) /gcc/tree-nested.c:3553 0x86f243 cgraph_node::analyze() /gcc/cgraphunit.c:676 0x872ae3 analyze_functions /gcc/cgraphunit.c:1227 0x8738a2 symbol_table::finalize_compilation_unit() /gcc/cgraphunit.c:2974
[Bug analyzer/94447] Not handling CONSTRUCTOR tree code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94447 --- Comment #1 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:78b9783774bfd3540f38f5b1e3c7fc9f719653d7 commit r10-8012-g78b9783774bfd3540f38f5b1e3c7fc9f719653d7 Author: David Malcolm Date: Thu Apr 23 21:31:22 2020 -0400 analyzer: remove -Wanalyzer-use-of-uninitialized-value for GCC 10 From what I can tell -Wanalyzer-use-of-uninitialized-value has not yet found a true diagnostic in real-world code, and seems to be particularly susceptible to false positives. These relate to bugs in the region_model code. For GCC 10 it seems best to remove this warning, which this patch does. Internally it also removes POISON_KIND_UNINIT. I'm working on a rewrite of the region_model code for GCC 11 that I hope will fix these issues, and allow this warning to be reintroduced. gcc/analyzer/ChangeLog: PR analyzer/94447 PR analyzer/94639 PR analyzer/94732 PR analyzer/94754 * analyzer.opt (Wanalyzer-use-of-uninitialized-value): Delete. * program-state.cc (selftest::test_program_state_dumping): Update expected dump result for removal of "uninit". * region-model.cc (poison_kind_to_str): Delete POISON_KIND_UNINIT case. (root_region::ensure_stack_region): Initialize stack with null svalue_id rather than with a typeless POISON_KIND_UNINIT value. (root_region::ensure_heap_region): Likewise for the heap. (region_model::dump_summary_of_rep_path_vars): Remove summarization of uninit values. (region_model::validate): Remove check that the stack has a POISON_KIND_UNINIT value. (poisoned_value_diagnostic::emit): Remove POISON_KIND_UNINIT case. (poisoned_value_diagnostic::describe_final_event): Likewise. (selftest::test_dump): Update expected dump result for removal of "uninit". (selftest::test_svalue_equality): Remove "uninit" and "freed". * region-model.h (enum poison_kind): Remove POISON_KIND_UNINIT. gcc/ChangeLog: PR analyzer/94447 PR analyzer/94639 PR analyzer/94732 PR analyzer/94754 * doc/invoke.texi (Static Analyzer Options): Remove -Wanalyzer-use-of-uninitialized-value. (-Wno-analyzer-use-of-uninitialized-value): Remove item. gcc/testsuite/ChangeLog: PR analyzer/94447 PR analyzer/94639 PR analyzer/94732 PR analyzer/94754 * gcc.dg/analyzer/data-model-1.c: Mark "use of uninitialized value" warnings as xfail for now. * gcc.dg/analyzer/data-model-5b.c: Remove uninitialized warning. * gcc.dg/analyzer/pr94099.c: Mark "uninitialized" warning as xfail for now. * gcc.dg/analyzer/pr94447.c: New test. * gcc.dg/analyzer/pr94639.c: New test. * gcc.dg/analyzer/pr94732.c: New test. * gcc.dg/analyzer/pr94754.c: New test. * gcc.dg/analyzer/zlib-6.c: Mark "uninitialized" warning as xfail for now.
[Bug analyzer/94639] false-positive uninitialized value on fixed sized array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94639 --- Comment #1 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:78b9783774bfd3540f38f5b1e3c7fc9f719653d7 commit r10-8012-g78b9783774bfd3540f38f5b1e3c7fc9f719653d7 Author: David Malcolm Date: Thu Apr 23 21:31:22 2020 -0400 analyzer: remove -Wanalyzer-use-of-uninitialized-value for GCC 10 From what I can tell -Wanalyzer-use-of-uninitialized-value has not yet found a true diagnostic in real-world code, and seems to be particularly susceptible to false positives. These relate to bugs in the region_model code. For GCC 10 it seems best to remove this warning, which this patch does. Internally it also removes POISON_KIND_UNINIT. I'm working on a rewrite of the region_model code for GCC 11 that I hope will fix these issues, and allow this warning to be reintroduced. gcc/analyzer/ChangeLog: PR analyzer/94447 PR analyzer/94639 PR analyzer/94732 PR analyzer/94754 * analyzer.opt (Wanalyzer-use-of-uninitialized-value): Delete. * program-state.cc (selftest::test_program_state_dumping): Update expected dump result for removal of "uninit". * region-model.cc (poison_kind_to_str): Delete POISON_KIND_UNINIT case. (root_region::ensure_stack_region): Initialize stack with null svalue_id rather than with a typeless POISON_KIND_UNINIT value. (root_region::ensure_heap_region): Likewise for the heap. (region_model::dump_summary_of_rep_path_vars): Remove summarization of uninit values. (region_model::validate): Remove check that the stack has a POISON_KIND_UNINIT value. (poisoned_value_diagnostic::emit): Remove POISON_KIND_UNINIT case. (poisoned_value_diagnostic::describe_final_event): Likewise. (selftest::test_dump): Update expected dump result for removal of "uninit". (selftest::test_svalue_equality): Remove "uninit" and "freed". * region-model.h (enum poison_kind): Remove POISON_KIND_UNINIT. gcc/ChangeLog: PR analyzer/94447 PR analyzer/94639 PR analyzer/94732 PR analyzer/94754 * doc/invoke.texi (Static Analyzer Options): Remove -Wanalyzer-use-of-uninitialized-value. (-Wno-analyzer-use-of-uninitialized-value): Remove item. gcc/testsuite/ChangeLog: PR analyzer/94447 PR analyzer/94639 PR analyzer/94732 PR analyzer/94754 * gcc.dg/analyzer/data-model-1.c: Mark "use of uninitialized value" warnings as xfail for now. * gcc.dg/analyzer/data-model-5b.c: Remove uninitialized warning. * gcc.dg/analyzer/pr94099.c: Mark "uninitialized" warning as xfail for now. * gcc.dg/analyzer/pr94447.c: New test. * gcc.dg/analyzer/pr94639.c: New test. * gcc.dg/analyzer/pr94732.c: New test. * gcc.dg/analyzer/pr94754.c: New test. * gcc.dg/analyzer/zlib-6.c: Mark "uninitialized" warning as xfail for now.
[Bug analyzer/94754] -fanalyzer false positive due to it ignoring previous if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94754 --- Comment #2 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:78b9783774bfd3540f38f5b1e3c7fc9f719653d7 commit r10-8012-g78b9783774bfd3540f38f5b1e3c7fc9f719653d7 Author: David Malcolm Date: Thu Apr 23 21:31:22 2020 -0400 analyzer: remove -Wanalyzer-use-of-uninitialized-value for GCC 10 From what I can tell -Wanalyzer-use-of-uninitialized-value has not yet found a true diagnostic in real-world code, and seems to be particularly susceptible to false positives. These relate to bugs in the region_model code. For GCC 10 it seems best to remove this warning, which this patch does. Internally it also removes POISON_KIND_UNINIT. I'm working on a rewrite of the region_model code for GCC 11 that I hope will fix these issues, and allow this warning to be reintroduced. gcc/analyzer/ChangeLog: PR analyzer/94447 PR analyzer/94639 PR analyzer/94732 PR analyzer/94754 * analyzer.opt (Wanalyzer-use-of-uninitialized-value): Delete. * program-state.cc (selftest::test_program_state_dumping): Update expected dump result for removal of "uninit". * region-model.cc (poison_kind_to_str): Delete POISON_KIND_UNINIT case. (root_region::ensure_stack_region): Initialize stack with null svalue_id rather than with a typeless POISON_KIND_UNINIT value. (root_region::ensure_heap_region): Likewise for the heap. (region_model::dump_summary_of_rep_path_vars): Remove summarization of uninit values. (region_model::validate): Remove check that the stack has a POISON_KIND_UNINIT value. (poisoned_value_diagnostic::emit): Remove POISON_KIND_UNINIT case. (poisoned_value_diagnostic::describe_final_event): Likewise. (selftest::test_dump): Update expected dump result for removal of "uninit". (selftest::test_svalue_equality): Remove "uninit" and "freed". * region-model.h (enum poison_kind): Remove POISON_KIND_UNINIT. gcc/ChangeLog: PR analyzer/94447 PR analyzer/94639 PR analyzer/94732 PR analyzer/94754 * doc/invoke.texi (Static Analyzer Options): Remove -Wanalyzer-use-of-uninitialized-value. (-Wno-analyzer-use-of-uninitialized-value): Remove item. gcc/testsuite/ChangeLog: PR analyzer/94447 PR analyzer/94639 PR analyzer/94732 PR analyzer/94754 * gcc.dg/analyzer/data-model-1.c: Mark "use of uninitialized value" warnings as xfail for now. * gcc.dg/analyzer/data-model-5b.c: Remove uninitialized warning. * gcc.dg/analyzer/pr94099.c: Mark "uninitialized" warning as xfail for now. * gcc.dg/analyzer/pr94447.c: New test. * gcc.dg/analyzer/pr94639.c: New test. * gcc.dg/analyzer/pr94732.c: New test. * gcc.dg/analyzer/pr94754.c: New test. * gcc.dg/analyzer/zlib-6.c: Mark "uninitialized" warning as xfail for now.
[Bug analyzer/94732] Analyzer: false positive in MPFR's atan.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94732 --- Comment #2 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:78b9783774bfd3540f38f5b1e3c7fc9f719653d7 commit r10-8012-g78b9783774bfd3540f38f5b1e3c7fc9f719653d7 Author: David Malcolm Date: Thu Apr 23 21:31:22 2020 -0400 analyzer: remove -Wanalyzer-use-of-uninitialized-value for GCC 10 From what I can tell -Wanalyzer-use-of-uninitialized-value has not yet found a true diagnostic in real-world code, and seems to be particularly susceptible to false positives. These relate to bugs in the region_model code. For GCC 10 it seems best to remove this warning, which this patch does. Internally it also removes POISON_KIND_UNINIT. I'm working on a rewrite of the region_model code for GCC 11 that I hope will fix these issues, and allow this warning to be reintroduced. gcc/analyzer/ChangeLog: PR analyzer/94447 PR analyzer/94639 PR analyzer/94732 PR analyzer/94754 * analyzer.opt (Wanalyzer-use-of-uninitialized-value): Delete. * program-state.cc (selftest::test_program_state_dumping): Update expected dump result for removal of "uninit". * region-model.cc (poison_kind_to_str): Delete POISON_KIND_UNINIT case. (root_region::ensure_stack_region): Initialize stack with null svalue_id rather than with a typeless POISON_KIND_UNINIT value. (root_region::ensure_heap_region): Likewise for the heap. (region_model::dump_summary_of_rep_path_vars): Remove summarization of uninit values. (region_model::validate): Remove check that the stack has a POISON_KIND_UNINIT value. (poisoned_value_diagnostic::emit): Remove POISON_KIND_UNINIT case. (poisoned_value_diagnostic::describe_final_event): Likewise. (selftest::test_dump): Update expected dump result for removal of "uninit". (selftest::test_svalue_equality): Remove "uninit" and "freed". * region-model.h (enum poison_kind): Remove POISON_KIND_UNINIT. gcc/ChangeLog: PR analyzer/94447 PR analyzer/94639 PR analyzer/94732 PR analyzer/94754 * doc/invoke.texi (Static Analyzer Options): Remove -Wanalyzer-use-of-uninitialized-value. (-Wno-analyzer-use-of-uninitialized-value): Remove item. gcc/testsuite/ChangeLog: PR analyzer/94447 PR analyzer/94639 PR analyzer/94732 PR analyzer/94754 * gcc.dg/analyzer/data-model-1.c: Mark "use of uninitialized value" warnings as xfail for now. * gcc.dg/analyzer/data-model-5b.c: Remove uninitialized warning. * gcc.dg/analyzer/pr94099.c: Mark "uninitialized" warning as xfail for now. * gcc.dg/analyzer/pr94447.c: New test. * gcc.dg/analyzer/pr94639.c: New test. * gcc.dg/analyzer/pr94732.c: New test. * gcc.dg/analyzer/pr94754.c: New test. * gcc.dg/analyzer/zlib-6.c: Mark "uninitialized" warning as xfail for now.
[Bug target/94820] [8/9/10 Regression] pr94780.c fails with ICE on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94820 Richard Biener changed: What|Removed |Added Depends on||94780 Priority|P3 |P2 Target Milestone|--- |8.5 Keywords||ice-on-valid-code Last reconfirmed||2020-04-28 Summary|pr94780.c fails with ICE on |[8/9/10 Regression] |aarch64 |pr94780.c fails with ICE on ||aarch64 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Looks like an exact duplicate of the PR but this time for aarch64. The fix is going to be similar (and likely more targets will be affected). Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94780 [Bug 94780] [8/9 Regression] ICE in walk_body at gcc/tree-nested.c:713 since r6-3632-gf6f69fb09c5f81df
[Bug target/94814] [8 Regression] ICE: RTL check: expected code 'const_int', have 'reg' in output_3367, at config/aarch64/atomics.md:755
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94814 Richard Biener changed: What|Removed |Added Target Milestone|--- |8.5
[Bug analyzer/94754] -fanalyzer false positive due to it ignoring previous if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94754 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from David Malcolm --- Should be fixed by r10-8012-g78b9783774bfd3540f38f5b1e3c7fc9f719653d7.
[Bug c/94815] Abusive -Wrestrict warning with sprintf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94815 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 CC||msebor at gcc dot gnu.org Last reconfirmed||2020-04-28 --- Comment #1 from Richard Biener --- Confirmed.
[Bug analyzer/94732] Analyzer: false positive in MPFR's atan.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94732 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #3 from David Malcolm --- Should be fixed by r10-8012-g78b9783774bfd3540f38f5b1e3c7fc9f719653d7.
[Bug analyzer/94447] Not handling CONSTRUCTOR tree code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94447 --- Comment #2 from David Malcolm --- r10-8012-g78b9783774bfd3540f38f5b1e3c7fc9f719653d7 removes the false positive, but we should still handle CONSTRUCTOR tree nodes. Keeping this open.
[Bug ipa/94818] GCC emits dead bodies of functions whose all calls have been eliminated by optimisations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94818 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2020-04-28 CC||marxin at gcc dot gnu.org Component|tree-optimization |ipa Status|UNCONFIRMED |NEW --- Comment #1 from Richard Biener --- Confirmed. ___builtin_constant_p is only resolved after IPA optimization and at that point unreachable functions can no longer be removed reliably (foo is output before bar0 __builtin_constant_p is resolved). We could add another "IPA" sync point before RTL expansion but not sure if we really want to. We could also see there's no callers to bar0 and bar1 and resolve __builtin_constant_p earlier during IPA.
[Bug c++/94819] [10 Regression] Inherited and constrained constructors are "ambiguous" even if they aren't Pt. 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94819 Richard Biener changed: What|Removed |Added Keywords||rejects-valid Known to work||9.3.0 Target Milestone|--- |10.0
[Bug analyzer/94639] false-positive uninitialized value on fixed sized array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94639 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from David Malcolm --- Should be fixed by r10-8012-g78b9783774bfd3540f38f5b1e3c7fc9f719653d7.
[Bug analyzer/94714] Analyzer: no warning on access of an uninitialized variable of automatic storage duration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94714 David Malcolm changed: What|Removed |Added Target Milestone|--- |11.0 --- Comment #1 from David Malcolm --- Thanks for filing this bug. I've removed -Wanalyzer-use-of-uninitialized-value for GCC 10 (in r10-8012-g78b9783774bfd3540f38f5b1e3c7fc9f719653d7) since the underlying region_model code is too buggy to support it. I'm rewriting it for GCC 11 and hope to reintroduce the warning there; setting target milestone accordingly.
[Bug target/94821] New: aarch64: ICE in walk_body at gcc/tree-nested.c:713
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94821
Bug ID: 94821
Summary: aarch64: ICE in walk_body at gcc/tree-nested.c:713
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: z.zhanghaijian at huawei dot com
Target Milestone: ---
The case gcc.dg/pr94780.c on aarch64:
_Atomic double x;
double
foo (void)
{
double bar () { return x; }
x /= 3;
return bar ();
}
---
gcc pr94780.c -S
pr94780.c: In function ‘foo’:
pr94780.c:8:1: internal compiler error: Segmentation fault
8 | foo (void)
| ^~~
0x125cdc3 crash_signal
../.././gcc/toplev.c:328
0x94a4dc tree_check(tree_node*, char const*, int, char const*, tree_code)
../.././gcc/tree.h:3286
0x1356f83 convert_nonlocal_reference_op
../.././gcc/tree-nested.c:1064
0x1677c5f walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
../.././gcc/tree.c:12000
0xe0a7b7 walk_gimple_op(gimple*, tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../.././gcc/gimple-walk.c:268
0xe0b33b walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
../.././gcc/gimple-walk.c:596
0xe09d83 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../.././gcc/gimple-walk.c:51
0xe0b437 walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
../.././gcc/gimple-walk.c:605
0xe09d83 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../.././gcc/gimple-walk.c:51
0x1355da7 walk_body
../.././gcc/tree-nested.c:713
0x1355def walk_function
../.././gcc/tree-nested.c:724
0x135613b walk_all_functions
../.././gcc/tree-nested.c:789
0x13607b3 lower_nested_functions(tree_node*)
../.././gcc/tree-nested.c:3551
0xbc6187 cgraph_node::analyze()
../.././gcc/cgraphunit.c:676
0xbc842f analyze_functions
../.././gcc/cgraphunit.c:1227
0xbcd97b symbol_table::finalize_compilation_unit()
../.././gcc/cgraphunit.c:2974
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug target/94821] aarch64: ICE in walk_body at gcc/tree-nested.c:713
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94821 Andreas Schwab changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andreas Schwab --- dup *** This bug has been marked as a duplicate of bug 94820 ***
[Bug target/94820] [8/9/10 Regression] pr94780.c fails with ICE on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94820 Andreas Schwab changed: What|Removed |Added CC||z.zhanghaijian at huawei dot com --- Comment #2 from Andreas Schwab --- *** Bug 94821 has been marked as a duplicate of this bug. ***
[Bug lto/94822] New: ICE in lto with option -Warray-bounds and -fno-use-linker-plugin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94822
Bug ID: 94822
Summary: ICE in lto with option -Warray-bounds and
-fno-use-linker-plugin
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: lizekun1 at huawei dot com
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Created attachment 48393
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48393&action=edit
gcc10-lto-constructor-array-bounds.patch
Hi,
I find an ICE when testing GCC10.0 on aarch64 at '-O3 -flto
-fno-use-linker-plugin -Warray-bounds' with POCs below:
test.h
---
typedef struct {
int i;
int ints[];
} struct_t;
---
test0.c
---
/* { dg-lto-do link } */
#include "test.h"
extern struct_t my_struct;
int main() {
return my_struct.ints[1];
}
---
test1.c
---
#include "test.h"
struct_t my_struct = {
20,
{ 1, 2 }
};
---
GCC version:
gcc version 10.0.1 20200421 (experimental)
Runcommand:
gcc -O3 -flto -fno-use-linker-plugin -Warray-bounds -c -o test0.o test0.c
gcc -O3 -flto -fno-use-linker-plugin -Warray-bounds -c -o test1.o test1.c
gcc test0.o test1.o -flto -Warray-bounds -fno-use-linker-plugin -o test.exe
Stack dump:
during GIMPLE pass: vrp
test0.c: In function 'main':
test0.c:7:5: internal compiler error: tree check: expected constructor, have
error_mark in get_initializer_for, at tree.c:13565
7 | int main() {
| ^
0x15d8fc7 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
/home/lzk /gcc-10.0/gcc/tree.c:9685
0x9b0a37 tree_check(tree_node*, char const*, int, char const*, tree_code)
/home/lzk /gcc-10.0/gcc/tree.h:3278
0x15eafdf get_initializer_for
/home/lzk gcc-10.0/gcc/tree.c:13565
0x15eb73f component_ref_size(tree_node*, bool*)
/home/lzk/ gcc-10.0/gcc/tree.c:13678
0x15a2037 vrp_prop::check_array_ref(unsigned int, tree_node*, bool)
/home/lzk/gcc-10.0/gcc/tree-vrp.c:3525
0x15a46c3 check_array_bounds
/home/lzk /gcc-10.0/gcc/tree-vrp.c:4062
0x15e3cc3 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
/home/lzk/gcc-10.0/gcc/tree.c:11954
0xd2cd37 walk_gimple_op(gimple*, tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
/home/lzk/gcc-10.0/gcc/gimple-walk.c:202
0x15a485b check_array_bounds_dom_walker::before_dom_children(basic_block_def*)
/home/lzk/gcc-10.0/gcc/tree-vrp.c:4120
0x1f8c863 dom_walker::walk(basic_block_def*)
/home/lzk/gcc-10.0/gcc/domwalk.c:309
0x15a48b7 vrp_prop::check_all_array_refs()
/home/lzk/gcc-10.0/gcc/tree-vrp.c:4137
0x15a805f vrp_prop::vrp_finalize(bool)
/home/lzk/gcc-10.0/gcc/tree-vrp.c:5209
0x15a80cb execute_vrp
/home/lzk/gcc-10.0/gcc/tree-vrp.c:5277
0x15a82fb execute
/home/lzk/gcc-10.0/gcc/tree-vrp.c:5359
This ICE appears because gcc will stream it to the function_body section when
processing the variable with the initial value of the constructor type, and the
error_mark_node to the decls section. When recompiling, the value obtained with
DECL_INITIAL will be error_mark.
My proposed fix is:
---
diff --git a/gcc/tree.c b/gcc/tree.c
index 63dc6730b2b..385c22e667f 100644
--- a/gcc/tree.c
+++ b/gcc/tree.c
@@ -13719,6 +13719,13 @@ component_ref_size (tree ref, bool *inte
the initializer of the BASE object if it has one. */
if (tree init = DECL_P (base) ? DECL_INITIAL (base) : NULL_TREE)
{
+ varpool_node *vnode;
+ if (TREE_CODE (init) == ERROR_MARK
+ && in_lto_p
+ && VAR_P (base)
+ && (vnode = varpool_node::get (base)
+ ? varpool_node::get (base)->ultimate_alias_target () : NULL))
+ init = vnode->get_constructor ();
init = get_initializer_for (init, member);
if (init)
{
---
any suggestion?
[Bug libstdc++/94811] Please make make_tuple noexcept when possible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94811 --- Comment #4 from Rafael Avila de Espindola --- (In reply to Jonathan Wakely from comment #3) > (In reply to Rafael Avila de Espindola from comment #0) > > So it should be possible to make the std::tuple constructor and > > Isn't that already done? It is :-) I had tested this bit with gcc 9, but with 10 the following assert passes: static_assert(std::is_nothrow_constructible_v, int>); Given CTAD I am happy to call this bug fixed if you want.
[Bug fortran/94788] [8/9 Regression] Severe regression leading to double free in tcache
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94788 --- Comment #30 from Jürgen Reuter --- Thomas, can you work with this now!?
[Bug lto/94822] [10 Regression] ICE in lto with option -Warray-bounds and -fno-use-linker-plugin since r10-4300-g49fb45c81f4ac068
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94822 Martin Liška changed: What|Removed |Added Known to fail||10.0 Summary|ICE in lto with option |[10 Regression] ICE in lto |-Warray-bounds and |with option -Warray-bounds |-fno-use-linker-plugin |and -fno-use-linker-plugin ||since ||r10-4300-g49fb45c81f4ac068 Last reconfirmed||2020-04-28 Target Milestone|--- |10.0 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Known to work||9.3.0 Keywords||ice-on-valid-code CC||hubicka at gcc dot gnu.org, ||msebor at gcc dot gnu.org --- Comment #1 from Martin Liška --- Started with r10-4300-g49fb45c81f4ac068.
[Bug analyzer/94816] ICE: Segmentation fault (in ana::region_model::add_region_for_type) since r10-5950-g757bf1dff5e8cee3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94816 Martin Liška changed: What|Removed |Added Known to work||9.3.0 Ever confirmed|0 |1 Summary|ICE: Segmentation fault (in |ICE: Segmentation fault (in |ana::region_model::add_regi |ana::region_model::add_regi |on_for_type)|on_for_type) since ||r10-5950-g757bf1dff5e8cee3 Target Milestone|--- |10.0 Known to fail||10.0 Status|UNCONFIRMED |ASSIGNED CC||marxin at gcc dot gnu.org Last reconfirmed||2020-04-28 --- Comment #1 from Martin Liška --- Started with r10-5950-g757bf1dff5e8cee3.
[Bug c++/94817] ICE in add_stmt, at cp/semantics.c:392 since r10-6063-g49789fd08378e3ff
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94817 Martin Liška changed: What|Removed |Added Target Milestone|--- |10.0 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW CC||iains at gcc dot gnu.org, ||marxin at gcc dot gnu.org Known to fail||10.0 Last reconfirmed||2020-04-28 Summary|ICE in add_stmt, at |ICE in add_stmt, at |cp/semantics.c:392 |cp/semantics.c:392 since ||r10-6063-g49789fd08378e3ff --- Comment #1 from Martin Liška --- Started with r10-6063-g49789fd08378e3ff.
[Bug c/94815] Abusive -Wrestrict warning with sprintf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94815
Martin Sebor changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|NEW |RESOLVED
--- Comment #2 from Martin Sebor ---
The warning is only issued with optimization enabled the strlen pass disabled,
such as at -O1, but not at -O2. The strlen dump below helps explain why: when
the strlen pass doesn't run the warning doesn't compute the length of str2 (as
reflected by the very large value in the Result of the %s directive) and so it
makes a decision solely on the basis that the %s argument points to the same
array as the destination of the sprintf call. This is by design. To avoid
the warning under these conditions use a precision in the directive: %.3s.
;; Function f (f, funcdef_no=0, decl_uid=1938, cgraph_uid=1, symbol_order=0)
;; 1 loops found
;;
;; Loop 0
;; header 0, latch 1
;; depth 0, outer -1
;; nodes: 0 1 2
;; 2 succs { 1 }
Computing maximum subobject size for buf_3:
pr94815.c:13: sprintf: objsize = 9223372036854775807, fmtstr = "ABC%s"
Directive 1 at offset 0: "ABC", length = 3
Result: 3, 3, 3, 3 (3, 3, 3, 3)
Directive 2 at offset 3: "%s"
Result: 0, 0, -1, 9223372036854775807 (3, 3, -1, -1)
Directive 3 at offset 5: "", length = 1
pr94815.c: In function ‘f’:
pr94815.c:13:5: warning: ‘sprintf’ argument 3 may overlap destination object
‘buf’ [-Wrestrict]
13 | sprintf(str1, "ABC%s", str2);
| ^~~~
[Bug tree-optimization/84774] [meta-bug] bogus/missing -Wrestrict
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84774 Bug 84774 depends on bug 94815, which changed state. Bug 94815 Summary: Abusive -Wrestrict warning with sprintf https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94815 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX
[Bug middle-end/93517] bogus -Wrestrict on sprintf with unknown strings bounded by array size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93517 --- Comment #2 from Martin Sebor --- This bug is different than PR94815 because here the warning code should be able to determine that the sprintf call cannot overlap based on the sizes of the array arguments that put an upper bound on the lengths of the strings stored in the arrays. (In PR94815 the sizes of the arrays aren't known and neither are the lengths of the strings stored in them.)
[Bug c/94815] Abusive -Wrestrict warning with sprintf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94815 --- Comment #3 from Martin Sebor --- I should add: it's helpful to make use of attribute alloc_size on allocation functions like myalloc to let GCC determine the size of the allocated objects. The size can then be used as an upper bound on the lengths of strings stored there. The -Wrestrict warning for sprintf doesn't yet make use of it but other warnings already do and I expect to extend it to sprintf as well.
[Bug target/94711] [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94711
--- Comment #2 from CVS Commits ---
The master branch has been updated by Matthew Malcomson :
https://gcc.gnu.org/g:a5bff8af0a68d039e1586087639c86d6931c9b81
commit r10-8013-ga5bff8af0a68d039e1586087639c86d6931c9b81
Author: Matthew Malcomson
Date: Tue Apr 28 15:38:43 2020 +0100
[Arm] Account for C++17 artificial field determining Homogeneous Aggregates
In C++14, an empty class deriving from an empty base is not an
aggregate, while in C++17 it is. In order to implement this, GCC adds
an artificial field to such classes.
This artificial field has no mapping to Fundamental Data Types in the
Arm PCS ABI and hence should not count towards determining whether an
object can be passed using the vector registers as per section
"7.1.2 Procedure Calling" in the arm PCS
https://developer.arm.com/docs/ihi0042/latest?_ga=2.60211309.1506853196.1533541889-405231439.1528186050
This patch avoids counting this artificial field in
aapcs_vfp_sub_candidate, and hence calculates whether such objects
should be passed in vector registers in the same manner as C++14 (where
the artificial field does not exist).
Before this change, the test below would pass the arguments to `f` in
general registers. After this change, the test passes the arguments to
`f` using the vector registers.
The new behaviour matches the behaviour of `armclang`, and also matches
the GCC behaviour when run with `-std=gnu++14`.
> gcc -std=gnu++17 -march=armv8-a+simd -mfloat-abi=hard test.cpp
``` test.cpp
struct base {};
struct pair : base
{
float first;
float second;
pair (float f, float s) : first(f), second(s) {}
};
void f (pair);
int main()
{
f({3.14, 666});
return 1;
}
```
We add a `-Wpsabi` warning to catch cases where this fix has changed the
ABI for
some functions. Unfortunately this warning is not emitted twice for
multiple
calls to the same function, but I feel this is not much of a problem and
can be
fixed later if needs be.
(i.e. if `main` called `f` twice in a row we only emit a diagnostic for the
first).
Testing:
Bootstrapped and regression tested on arm-linux.
This change fixes the struct-layout-1 tests Jakub added
https://gcc.gnu.org/pipermail/gcc-patches/2020-April/544204.html
Regression tested on arm-none-eabi.
gcc/ChangeLog:
2020-04-28 Matthew Malcomson
Jakub Jelinek
PR target/94711
* config/arm/arm.c (aapcs_vfp_sub_candidate): Account for C++17
empty
base class artificial fields.
(aapcs_vfp_is_call_or_return_candidate): Warn when PCS ABI
decision is different after this fix.
[Bug target/94711] [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94711 --- Comment #3 from Matthew Malcomson --- This has been fixed by. https://gcc.gnu.org/pipermail/gcc-patches/2020-April/544625.html In the email linked above I mentioned another problem using `-mabi=apcs-gnu`. Since that ABI is obsolete (Kyrylo pointed that out to me) I don't think that problem should hold up GCC10.
[Bug target/94711] [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94711 Matthew Malcomson changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from Matthew Malcomson --- Resolving since the issue with the obsolete ABI is different to this ticket.
[Bug target/94743] IRQ handler doesn't save scratch VFP registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94743 --- Comment #6 from Christophe Lyon --- If we consider the initial testcase, it doesn't clobber any FP register directly, but the compiler inserts a call to memcpy which does. So IIUC your 1st suggestion, it would mean: - save no FP register in the IRQ handler - call a libgcc routine to save all FP registers+status registers (this routine would have to decide about d16 vs d32 at runtime, unless we can rely on multilibs -- it would mean defining mandatory d16 and d32 libgcc multilibs...) Hence I like your simpler suggestion :-) But I think we should help the user diagnose potential problems: - maybe issue a warning when compiling an IRQ handler without -mgeneral-regs-only. That might break some packages, but would force them to check their code - also emit a warning when calling a function defined in another unit (but we should recurse) However this does not help if the compiler inserts a call to memcpy which happens to be using FPU code: the user would get a warning, but how could he solve it? Avoid implicit use of memcpy?
[Bug libstdc++/94823] New: modulo arithmetic bug in random.tcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94823
Bug ID: 94823
Summary: modulo arithmetic bug in random.tcc
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: nathan at gcc dot gnu.org
Target Milestone: ---
I think there's a bug in libstdc++v3/include/bits/random.tcc, found by ubsan's
(over conservative) unsigned overflow checker. This time, a true positive.
there's a bunch of code like:
for (size_t __k = 0; __k < __m; ++__k)
{
_Type __arg = (__begin[__k % __n]
^ __begin[(__k + __p) % __n]
^ __begin[(__k - 1) % __n]); // this line
... calculate stuff
__begin[(__k + __p) % __n] += __r1;
__begin[(__k + __q) % __n] += __r2;
__begin[__k % __n] = __r2;
}
AFAICT we're treating __begin as a circular buffer length __n. __n has no
special properties. The marked line is presuming that '(V mod 2^n) mod __n' is
the same as '(V mod __n)' which is not true in general. In particular when
__k is zero we're taking '(2^64 - 1) mod __n', which is not necessarily __n -
1, the last position in the buffer, right?
I don't know if the prior line __k + __p can overflow too. If it can't then I
think the marked line should be:
__begin[(__k + __n - 1) % __n]
[Bug target/93654] Inappropriate "-fcf-protection and -mindirect-branch=thunk are incompatible on x86_64" restriction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93654 H.J. Lu changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #2 from H.J. Lu --- Created attachment 48394 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48394&action=edit A proposal to support retpoline and CET
[Bug tree-optimization/84774] [meta-bug] bogus/missing -Wrestrict
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84774 Bug 84774 depends on bug 94815, which changed state. Bug 94815 Summary: Abusive -Wrestrict warning with sprintf https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94815 What|Removed |Added Status|RESOLVED|REOPENED Resolution|WONTFIX |---
[Bug target/93654] Inappropriate "-fcf-protection and -mindirect-branch=thunk are incompatible on x86_64" restriction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93654 --- Comment #3 from H.J. Lu --- Please DO disable -fcf-protection in the kernel build. We are enabling CET for the user space first. The kernel CET will be the next. I am enclosing a proposal to make -fcf-protection compatible with retpoline. It targets user space. It can be made compatible with kernel.
[Bug c/94815] Abusive -Wrestrict warning with sprintf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94815
Vincent Riviere changed:
What|Removed |Added
Resolution|WONTFIX |---
Status|RESOLVED|REOPENED
--- Comment #4 from Vincent Riviere ---
Thanks for your explanations.
But apologies, I oversimplified my real-world testcase. The one below is more
realistic, and still triggers the warning with -O2
$ cat foo.c && m68k-elf-gcc -c foo.c -Wall -O2
char *strcpy(char *, const char *);
int sprintf(char *, const char *, ...);
char* myalloc(int n) __attribute__((alloc_size(1)));
void f(void)
{
char* buf = myalloc(30);
char* str1 = buf;
char* str2 = buf + 10;
char* str3 = buf + 20;
strcpy(str3, "123");
sprintf(str2, "ABC%s", str3);
sprintf(str1, "DEF%s", str2);
}
foo.c: In function 'f':
foo.c:15:5: warning: 'sprintf' argument 3 may overlap destination object 'buf'
[-Wrestrict]
15 | sprintf(str1, "DEF%s", str2);
| ^~~~
[Bug target/94743] IRQ handler doesn't save scratch VFP registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94743 --- Comment #7 from Richard Earnshaw --- well, __aeabi_memcpy is required not to clobber the FP state. Sadly, GCC does not know about it...
[Bug tree-optimization/94824] New: Failure to optimize with __builtin_bswap32 as well as with a function recognized as such
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94824
Bug ID: 94824
Summary: Failure to optimize with __builtin_bswap32 as well as
with a function recognized as such
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
uint32_t swap32(uint32_t x)
{
return ((x << 24) | ((x << 8) & 0x00FF) | ((x >> 8) & 0xFF00) | (x
>> 24));
}
uint64_t swap64v1(uint64_t x)
{
uint64_t a = __builtin_bswap32(x);
x >>= 32;
a <<= 32;
return __builtin_bswap32(x) | a;
}
uint64_t swap64v2(uint64_t x)
{
uint64_t a = swap32(x);
x >>= 32;
a <<= 32;
return swap32(x) | a;
}
swap64v1 and swap64v2 are identical, since bswap32 is equivalent to
__builtin_bswap32. However, only swap64v2 is optimized to __builtin_bswap64.
swap64v1 is compiled to this by gcc -O3 :
swap64v1(unsigned long):
mov rdx, rdi
mov eax, edi
shr rdx, 32
bswap eax
sal rax, 32
bswap edx
mov edi, edx
or rax, rdi
ret
And swap64v2 gives this :
swap64v2(unsigned long):
mov rax, rdi
bswap rax
ret
[Bug c++/90750] [9 Regression] ICE in cp_default_conversion, at cp/typeck.c:2162
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90750 --- Comment #5 from CVS Commits --- The releases/gcc-9 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:aa988998be8f85334665a6b049d5d9139408c250 commit r9-8550-gaa988998be8f85334665a6b049d5d9139408c250 Author: Jason Merrill Date: Mon Jan 27 05:45:01 2020 -0500 c++: Avoid ICE with dependent attribute on type. We previously happened to accept this testcase, but never actually did anything useful with the attribute. The patch for PR86379 stopped using TREE_TYPE as USING_DECL_SCOPE, so 'using A::b' no longer had TREE_TYPE set, so the language-independent decl_attributes started crashing on it. GNU attributes are more flexible in their placement than C++11 attributes, so if we encounter a dependent GNU attribute that syntactically appertains to a type rather than the declaration as a whole, move it to the declaration; that's almost certainly what the user meant, anyway. gcc/cp/ChangeLog 2020-01-27 Jason Merrill PR c++/90750 PR c++/79585 * decl.c (grokdeclarator): Move dependent attribute to decl. * decl2.c (splice_template_attributes): No longer static.
[Bug c++/79585] spurious -Wunused-variable on a pointer with attribute unused in function template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79585 --- Comment #4 from CVS Commits --- The releases/gcc-9 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:aa988998be8f85334665a6b049d5d9139408c250 commit r9-8550-gaa988998be8f85334665a6b049d5d9139408c250 Author: Jason Merrill Date: Mon Jan 27 05:45:01 2020 -0500 c++: Avoid ICE with dependent attribute on type. We previously happened to accept this testcase, but never actually did anything useful with the attribute. The patch for PR86379 stopped using TREE_TYPE as USING_DECL_SCOPE, so 'using A::b' no longer had TREE_TYPE set, so the language-independent decl_attributes started crashing on it. GNU attributes are more flexible in their placement than C++11 attributes, so if we encounter a dependent GNU attribute that syntactically appertains to a type rather than the declaration as a whole, move it to the declaration; that's almost certainly what the user meant, anyway. gcc/cp/ChangeLog 2020-01-27 Jason Merrill PR c++/90750 PR c++/79585 * decl.c (grokdeclarator): Move dependent attribute to decl. * decl2.c (splice_template_attributes): No longer static.
[Bug c++/90750] [9 Regression] ICE in cp_default_conversion, at cp/typeck.c:2162
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90750 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Jason Merrill --- Fixed for 9.4/10.
[Bug c++/79585] spurious -Wunused-variable on a pointer with attribute unused in function template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79585 Jason Merrill changed: What|Removed |Added Target Milestone|10.0|9.4 Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jason Merrill --- Fixed for 9.4/10.
[Bug c/89180] [meta-bug] bogus/missing -Wunused warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89180 Bug 89180 depends on bug 79585, which changed state. Bug 79585 Summary: spurious -Wunused-variable on a pointer with attribute unused in function template https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79585 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug libstdc++/94811] Please make make_tuple noexcept when possible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94811 Jonathan Wakely changed: What|Removed |Added Resolution|--- |WORKSFORME Status|UNCONFIRMED |RESOLVED --- Comment #5 from Jonathan Wakely --- OK thanks
[Bug libstdc++/94810] std::cout segmentation fault in __attribute__((constructor)) function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94810 --- Comment #5 from Jonathan Wakely --- I don't see how that could conform to the standard's requirements.
