[Bug lto/104237] [11 Regression] Emitted binary code changes when -g is enabled at -O1 -flto and optimize attribute since r11-3126-ga8f9b4c54cc35062
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104237 --- Comment #9 from Chengnian Sun --- Hi, Could you explain why the flag `-fcompare-debug` does not detect this bug? Is it because the bug is triggered with -flto and -fcompare-debug does not work with -flto? Thanks.
[Bug target/104219] [12 regression] riscv64 compiler build fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104219 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.0
[Bug target/104213] [12 Regression] bogus use-after-free in virtual dtor with -ffat-lto-objects on ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104213 Andrew Pinski changed: What|Removed |Added CC||unlvsur at live dot com --- Comment #15 from Andrew Pinski --- *** Bug 104190 has been marked as a duplicate of this bug. ***
[Bug libstdc++/104190] arm-linux-gnueabi shows warnings of use-after-free of libstdc++?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104190 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Andrew Pinski --- Dup of bug 104213 in the end. *** This bug has been marked as a duplicate of bug 104213 ***
[Bug tree-optimization/104265] Missed vectorization in 526.blender_r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104265 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug c++/104266] Temporaries with protected destructor are erroneously permitted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104266
--- Comment #3 from Andrew Pinski ---
Here is another example:
class X { protected: ~X(); friend struct Y; };
struct Y { X x = {}; };
int main() {
Y b {};
}
But unlike the previous example, this one is rejected by clang in C++14 but
accepted for C++11.
And even accepted by ICC for C++17 and C++14.
Note it is rejected by MSVC though.
[Bug c++/104266] Temporaries with protected destructor are erroneously permitted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104266 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2022-01-29 --- Comment #2 from Andrew Pinski --- So clang, ICC and MSVC all reject it for at least in C++17 mode (clang and ICC accepted it for C++14). Confirmed.
[Bug target/104268] z13: inefficient vec_popcnt for 16-bit for z13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104268 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug debug/104277] New: [meta-bug] gstatement-frontiers causes fcompare-debug issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104277 Bug ID: 104277 Summary: [meta-bug] gstatement-frontiers causes fcompare-debug issues Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: compare-debug-failure, meta-bug Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org Target Milestone: --- Just to record all of the fcompare-debug issues with gstatement-frontiers
[Bug target/100930] PPC: Missing builtins for P9 vextsb2w, vextsb2w, vextsb2d, vextsh2d, vextsw2d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100930 Carl Love changed: What|Removed |Added CC||carll at gcc dot gnu.org --- Comment #3 from Carl Love --- So, with a little archaeological digging.. Looks like the patch was committed to mainline on 6/8/2021 as follows: From db042e1603db5057314c404eded73c45f60ad2d6 Mon Sep 17 00:00:00 2001 From: Carl Love Date: Mon, 3 Feb 2020 14:41:42 -0600 Subject: [PATCH] RS6000 Add 128-bit Binary Integer sign extend operations This patch adds the 128-bit sign extension instruction support and corresponding builtin support. RS6000 Add 128-bit Binary Integer sign extend operations 2021-06-08 Carl Love gcc/ChangeLog * config/rs6000/altivec.h (vec_signextll, vec_signexti, vec_signextq): Add define for new builtins. * config/rs6000/altivec.md(altivec_vreveti2): Add define_expand. * config/rs6000/rs6000-builtin.def (VSIGNEXTI, VSIGNEXTLL): Add overloaded builtin definitions. (VSIGNEXTSB2W, VSIGNEXTSH2W, VSIGNEXTSB2D, VSIGNEXTSH2D,VSIGNEXTSW2D, VSIGNEXTSD2Q): Add builtin expansions. (SIGNEXT): Add P10 overload definition. * config/rs6000/rs6000-call.c (P9V_BUILTIN_VEC_VSIGNEXTI, P9V_BUILTIN_VEC_VSIGNEXTLL, P10_BUILTIN_VEC_SIGNEXT): Add overloaded argument definitions. * config/rs6000/vsx.md (vsx_sign_extend_v2di_v1ti): Add define_insn. (vsignextend_v2di_v1ti, vsignextend_qi_, vsignextend_hi_, vsignextend_si_v2di)[VIlong]: Add define_expand. Make define_insn vsx_sign_extend_si_v2di visible. * doc/extend.texi: Add documentation for the vec_signexti, vec_signextll builtins and vec_signextq. gcc/testsuite/ChangeLog * gcc.target/powerpc/int_128bit-runnable.c (extsd2q): Update expected count. Add tests for vec_signextq. * gcc.target/powerpc/p9-sign_extend-runnable.c: New test case. Looking at the GCC 11 tree it looks like I did backport and commit it there as well: commit 88b66b376844fe7c537ab229250a41a54e706eaf Author: Carl Love Date: Tue Jun 15 11:37:31 2021 -0500 RS6000 Add 128-bit Binary Integer sign extend operations This patch adds the 128-bit sign extension instruction support and corresponding builtin support. RS6000 Add 128-bit Binary Integer sign extend operations 2021-06-08 Carl Love gcc/ChangeLog * config/rs6000/altivec.h (vec_signextll, vec_signexti, vec_signext\ q): Add define for new builtins. * config/rs6000/altivec.md(altivec_vreveti2): Add define_expand. * config/rs6000/rs6000-builtin.def (VSIGNEXTI, VSIGNEXTLL): Add overloaded builtin definitions. (VSIGNEXTSB2W, VSIGNEXTSH2W, VSIGNEXTSB2D, VSIGNEXTSH2D,VSIGNEXTSW2\ D, VSIGNEXTSD2Q): Add builtin expansions. (SIGNEXT): Add P10 overload definition. * config/rs6000/rs6000-call.c (P9V_BUILTIN_VEC_VSIGNEXTI, P9V_BUILTIN_VEC_VSIGNEXTLL, P10_BUILTIN_VEC_SIGNEXT): Add overloaded argument definitions. * config/rs6000/vsx.md (vsx_sign_extend_v2di_v1ti): Add define_insn\ . (vsignextend_v2di_v1ti, vsignextend_qi_, vsignextend_hi_, vsignextend_si_v2di)[VIlong]: Add define_expand. Make define_insn vsx_sign_extend_si_v2di visible. * doc/extend.texi: Add documentation for the vec_signexti, vec_signextll builtins and vec_signextq. gcc/testsuite/ChangeLog * gcc.target/powerpc/int_128bit-runnable.c (extsd2q): Update expect\ ed count. Add tests for vec_signextq. * gcc.target/powerpc/p9-sign_extend-runnable.c: New test case. Probably should have fixed the commit log date. So, it looks to me like this has been done and the issue should be closed.
[Bug tree-optimization/80641] missed optimization with with std::vector resize in loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80641 --- Comment #15 from Andrew Pinski --- This is interesting: _48 = _149 + 18446744073709551612; // _149 - 4 _63 = _55 + _48; _18 = _63 - _55; _19 = _18 /[ex] 4; _20 = (long unsigned int) _19; if (_55 != _63) _18 should be the same as _48 and the if statement should be if (_48 != 0)
[Bug tree-optimization/104276] memset is not elimited when followed by a store loop writing to that memory location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104276 Andrew Pinski changed: What|Removed |Added Status|RESOLVED|NEW Resolution|DUPLICATE |--- --- Comment #6 from Andrew Pinski --- Actually not an exact sorry still only related.
[Bug tree-optimization/28134] optimize redundant memset + assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28134 Andrew Pinski changed: What|Removed |Added CC||Darrell.Wright at gmail dot com --- Comment #3 from Andrew Pinski --- *** Bug 104276 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/104276] memset is not elimited when followed by a store loop writing to that memory location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104276 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #5 from Andrew Pinski --- Exact duplicate of PR 28134. *** This bug has been marked as a duplicate of bug 28134 ***
[Bug tree-optimization/104276] memset is not elimited when followed by a store loop writing to that memory location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104276
Andrew Pinski changed:
What|Removed |Added
Summary|Fail to eliminate deadstore |memset is not elimited when
|from vector constructor |followed by a store loop
||writing to that memory
||location
Last reconfirmed||2022-01-28
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
--- Comment #4 from Andrew Pinski ---
Simplified C testcase (without std::vector usage):
#define SZ 4096
void foo1(int *a) {
__builtin_memset(a, 0, sizeof(int)*SZ);
for (int n = 0; n < SZ; ++n) {
a[n] = n;
}
}
[Bug tree-optimization/104276] Fail to eliminate deadstore from vector constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104276 --- Comment #3 from Darrell Wright --- (In reply to Andrew Pinski from comment #2) > >clang is unable to remove the memset in code like > > I think you mean GCC there :). :) both are true. This optimization would remove the need for things like resize_and_overwrite which means we all win
[Bug tree-optimization/104276] Fail to eliminate deadstore from vector constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104276 --- Comment #2 from Andrew Pinski --- >clang is unable to remove the memset in code like I think you mean GCC there :).
[Bug tree-optimization/104276] Fail to eliminate deadstore from vector constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104276
--- Comment #1 from Andrew Pinski ---
Full testcase:
#include
#include
#include
#include
#include
#define SZ 4096
std::vector foo() {
auto result = std::vector(SZ);
int *ptr = result.data();
for (std::size_t n = 0; n < SZ; ++n) {
ptr[n] = static_cast( n );
}
return result;
}
[Bug tree-optimization/104276] Fail to eliminate deadstore from vector constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104276 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Severity|normal |enhancement
[Bug tree-optimization/98026] optimization dependant on condition order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98026
--- Comment #5 from Andrew Macleod ---
(In reply to Andrew Macleod from comment #4)
> > void f4(signed int i,unsigned int j) {
> > if (i > 100) return;
> > if (j > i) return;
> >
> > if (j > 100) link_error();
>
> if i is -2 (0xfffe) and j is 0xff (-1)
>
> then link error cant be removed.. ?
err, j is 0xfffd (-3) you get the idea :-)
Friday evenings are killer for logic and bit patterns...
[Bug c++/104276] New: Fail to eliminate deadstore from vector constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104276
Bug ID: 104276
Summary: Fail to eliminate deadstore from vector constructor
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: Darrell.Wright at gmail dot com
Target Milestone: ---
clang is unable to remove the memset in code like
std::vector foo() {
auto result = std::vector(SZ);
int *ptr = result.data();
for (std::size_t n = 0; n < SZ; ++n) {
ptr[n] = static_cast( n );
}
return result;
}
https://gcc.godbolt.org/z/5cbKejfqr
This is unaffected if the value is set during resize. That may result in
inlining of the memset but does not eliminate it.
However for code that uses blessed methods like memset subsequently
std::vector foo() {
auto result = std::vector(SZ);
std::memset(result.data(), 5, sizeof(int) * SZ);
return result;
}
https://gcc.godbolt.org/z/Kfs9x8Pe9
It is. This seems to be the usecase of resize_and_overwrite in future string.
Is there a way to formulate the code to do this. Or, and I think a better way,
is there a builtin or could there be that lets the compiler assume that the
memory will be subsequently written to? e.g. `__bultin_assume_set( void *
dest, size_t count )` ?
[Bug tree-optimization/98026] optimization dependant on condition order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98026
--- Comment #4 from Andrew Macleod ---
> void f4(signed int i,unsigned int j) {
> if (i > 100) return;
> if (j > i) return;
>
> if (j > 100) link_error();
if i is -2 (0xfffe) and j is 0xff (-1)
then link error cant be removed.. ?
[Bug analyzer/103872] testcase fail in gcc.dg/analyzer/pr103526.c on riscv64-unknown-elf-gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103872
Andrew Pinski changed:
What|Removed |Added
Target|riscv64-unknown-elf |riscv64-unknown-elf
||hppa*-*-* aarch64-*-*
Status|UNCONFIRMED |NEW
Last reconfirmed||2022-01-28
Ever confirmed|0 |1
--- Comment #2 from Andrew Pinski ---
strict alignment is causing the memcpy to have slightly different IR between
the targets.
I can reproduce the failure on aarch64 with -mstrict-align.
ubuntu@ubuntu:~/src/upstream-gcc-aarch64/gcc/objdir/gcc\# ./xgcc -B. t.c
-fanalyzer -Wanalyzer-too-complex -fanalyzer-call-summaries
ubuntu@ubuntu:~/src/upstream-gcc-aarch64/gcc/objdir/gcc\# ./xgcc -B. t.c
-fanalyzer -Wanalyzer-too-complex -fanalyzer-call-summaries -mstrict-align
t.c: In function 'game_new':
t.c:31:1: warning: leak of 'tmp.word_state' [CWE-401] [-Wanalyzer-malloc-leak]
31 | } /* { dg-bogus "leak" } */
| ^
'game_new': events 1-7
|
| 20 | if ((tmp.word_state = malloc(wordlen+1)) == NULL)
| |~ ^
| || |
| || (1) allocated here
| |(2) assuming 'tmp.word_state' is non-NULL
| |(3) following 'false' branch...
| 21 | goto err;
| 22 | if ((rval = malloc(sizeof(*rval))) == NULL)
| |~~
| |||
| ||(4) ...to here
| |(5) following 'false' branch (when 'rval' is
non-NULL)...
| 23 | goto err;
| 24 | memcpy(rval, , sizeof(*rval));
| | ~
| | |
| | (6) ...to here
|..
| 31 | } /* { dg-bogus "leak" } */
| | ~
| | |
| | (7) 'tmp.word_state' leaks here; was allocated at (1)
|
[Bug analyzer/103872] testcase fail in gcc.dg/analyzer/pr103526.c on riscv64-unknown-elf-gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103872 Andrew Pinski changed: What|Removed |Added CC||danglin at gcc dot gnu.org --- Comment #1 from Andrew Pinski --- *** Bug 104273 has been marked as a duplicate of this bug. ***
[Bug analyzer/104273] FAIL: gcc.dg/analyzer/pr103526.c (test for bogus messages, line 31)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104273 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- Dup of bug 103872. I suspect the strict alignment targets cause the difference. *** This bug has been marked as a duplicate of bug 103872 ***
[Bug analyzer/104270] -Wanalyzer-use-of-uninitialized-value is incorrectly suppressed by -ftrivial-auto-var-init=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104270 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2022-01-28 Keywords||diagnostic --- Comment #1 from Andrew Pinski --- Confirmed. I suspect it should be easy to treat DEFERRED_INIT as similar to ssa names that are (D).
[Bug c++/104255] parsing function signature fails when it uses a function parameter outside of an unevaluated context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104255 --- Comment #4 from qingzhe huang --- (In reply to Patrick Palka from comment #2) > > error: use of parameter outside function body before ‘)’ token > > due to 'e' being used outside of an unevaluated context within the signature > of the function. Sorry for my being unable to grasp your meaning before. Now I can see your point that the "e" of A is from declaration of parameter of function "g". Now that we agree the value from parameter clause should not be used in trailing return type, then it should also not be used in requires clause etc. (https://eel.is/c++draft/basic.scope.param#1.3) But this works: template auto f(int n) requires (n>0); This is violating our assumption. So, I am not convinced that (https://eel.is/c++draft/basic.scope.param#note-1) "A function parameter cannot be used for its value within the parameter-declaration-clause" is really meaningful. Or I misunderstand it??? https://www.godbolt.org/z/759oGdr94
[Bug target/104253] libgcc missing __floatdiif
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104253 Michael Meissner changed: What|Removed |Added Attachment #52306|0 |1 is obsolete|| --- Comment #9 from Michael Meissner --- Created attachment 52312 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52312=edit Replacement patch for fixing the integer <-> __ibm128 conversions if long double is IEEE 128-bit. Replacement for patch #2 that only modifies the names that are used.
[Bug fortran/101135] Load of null pointer when passing absent assumed-shape array argument for an optional dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101135 --- Comment #4 from anlauf at gcc dot gnu.org --- Created attachment 52311 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52311=edit Patch that regtests ok. The patch suggested by the reporter is rather close to this one. We need to special-case optional arguments of procedures with bind(c) attribute. I haven't understood the details yet, but excluding those prevents regressions in the c-binding testsuite, e.g. bind-c-contiguous-4.*. We need to fix the pattern for testcase gfortran.dg/missing_optional_dummy_6a.f90 which would have failed with -fsanitize=undefined without this patch.
[Bug tree-optimization/103514] Missing XOR-EQ-AND Optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103514 Navid Rahimi changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Navid Rahimi --- Thanks Jeff.
[Bug tree-optimization/103514] Missing XOR-EQ-AND Optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103514 --- Comment #3 from CVS Commits --- The master branch has been updated by Jeff Law : https://gcc.gnu.org/g:cb3ac1985a5332fa811a62844adb33ca140bd4ba commit r12-6928-gcb3ac1985a5332fa811a62844adb33ca140bd4ba Author: Navid Rahimi Date: Fri Jan 28 17:11:30 2022 -0500 tree-optimization/103514 Missing XOR-EQ-AND Optimization This patch will add the missed pattern described in bug 103514 [1] to the match.pd. [1] includes proof of correctness for the patch too. 1) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103514 gcc/ PR tree-optimization/103514 * match.pd (a & b) ^ (a == b) -> !(a | b): New optimization. (a & b) == (a ^ b) -> !(a | b): New optimization. gcc/testsuite * gcc.dg/tree-ssa/pr103514.c: Testcase for this optimization.
[Bug testsuite/99175] FAIL: g++.dg/modules/bad-mapper-1.C -std=c++17 (test for errors, line )
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99175 Andrew Pinski changed: What|Removed |Added Host|hppa*-*-hpux* | Build|hppa*-*-hpux* | Target|hppa*-*-hpux* | --- Comment #4 from Andrew Pinski --- I see this now on aarch64 too: FAIL: g++.dg/modules/bad-mapper-3.C -std=c++17 at line 3 (test for errors, line ) FAIL: g++.dg/modules/bad-mapper-3.C -std=c++17 (test for excess errors) FAIL: g++.dg/modules/bad-mapper-3.C -std=c++2a at line 3 (test for errors, line ) FAIL: g++.dg/modules/bad-mapper-3.C -std=c++2a (test for excess errors) FAIL: g++.dg/modules/bad-mapper-3.C -std=c++2b at line 3 (test for errors, line ) FAIL: g++.dg/modules/bad-mapper-3.C -std=c++2b (test for excess errors)
[Bug fortran/104228] [9/10/11/12 Regression] ICE in df_install_ref, at df-scan.cc:2294 since r8-3589-g707905d0773e5a8e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104228
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |mikael at gcc dot
gnu.org
Status|NEW |ASSIGNED
--- Comment #6 from Mikael Morin ---
The full typespec is copied from the associate target (x) to the associate
symbol (y) at parse.cc:4925. This includes the character length object, which
starting from there is shared between x and y. None of the various conditions
are met in resolve_assoc_var to overwrite the character length object. So when
we create the length decl (.y) for y and store it in its character length
object, it also appears in that of x at the same time. And from there it is
added to both functions along a path that I have lost.
Draft patch:
diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index 835a4783718..266e41e25b1 100644
--- a/gcc/fortran/resolve.cc
+++ b/gcc/fortran/resolve.cc
@@ -9227,7 +9227,6 @@ resolve_assoc_var (gfc_symbol* sym, bool resolve_target)
sym->ts.u.cl = target->ts.u.cl;
if (sym->ts.deferred && target->expr_type == EXPR_VARIABLE
- && target->symtree->n.sym->attr.dummy
&& sym->ts.u.cl == target->ts.u.cl)
{
sym->ts.u.cl = gfc_new_charlen (sym->ns, NULL);
[Bug c++/104177] coroutine frame is not being allocated with the correct alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104177 --- Comment #14 from Luke Dalessandro --- Thanks for the information Iain. Is there something short-term where gcc could provide an "unimplemented" failure or warning diagnostic for requests for coroutine frames with extended alignment? This could save a lot of debugging angst.
[Bug target/104253] libgcc missing __floatdiif
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104253 --- Comment #8 from Michael Meissner --- Yes, you are right. I didn't remember which functions were generated by the compiler, but I just did all of the conversion functions.
[Bug ipa/104275] Os causes some functions which are no-ops not to be inlined in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104275
Andrew Pinski changed:
What|Removed |Added
Component|tree-optimization |ipa
CC||marxin at gcc dot gnu.org
Status|UNCONFIRMED |NEW
Last reconfirmed||2022-01-28
Ever confirmed|0 |1
Summary|Os does not apply return|Os causes some functions
|value optimization while O2 |which are no-ops not to be
|and O3 does |inlined in some cases
Severity|normal |enhancement
--- Comment #1 from Andrew Pinski ---
This has nothing to do with RVO but rather inlining differences causes the
issue.
So the function which does not get inlined starts with:
void std::_Vector_base >::~_Vector_base (struct
_Vector_base * const this)
{
double * _1;
double * _2;
long int _3;
long unsigned int _10;
[local count: 1073741824]:
_2 = this_7(D)->_M_impl.D.21368._M_start;
if (_2 != 0B)
goto ; [53.47%]
else
goto ; [46.53%]
...
[local count: 499612072]:
goto ; [100.00%]
...
[local count: 1073741824]:
return;
}
But right before the function call to the deconstructor we have:
MEM[(struct _Vector_impl_data &)]._M_end_of_storage = 0B;
MEM[(struct _Vector_impl_data &)]._M_finish = 0B;
MEM[(struct _Vector_impl_data &)]._M_start = 0B;
std::_Vector_base >::~_Vector_base
();
So the deconstructor will be basically gone when inlined.
[Bug c++/104177] coroutine frame is not being allocated with the correct alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104177 Iain Sandoe changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2022-01-28 --- Comment #13 from Iain Sandoe --- the design that is agreed (by the coroutine "ABI group", at least) is this: If the frame requires greater than pointer alignment * 2, we should place the padding **BEFORE** the (resume*)() and (destroy*)() members - and the frame pointer will continue to point to the (resume*)() member. So that, from the point of view of a continuing caller - there is no difference between such frames and ones less-aligned. This requires: 1. keeping some accounting information on the side so that the correct memory can be freed. 2. having an allocator that honours alignment > 2 * pointer (well. I'd guess most do that, but we really need the aligned allocator change, however [as noted in the thread referenced] that change did not make C++20). We can, of course, follow clang. 3. ensuring that excess and user alignments are honoured in the placement of frame entries (I wonder if we actually need to honour anything larger than then stack would allow). Fro my part, I completely agree that GCC coroutines should support fields will suitable alignment for larger vector objects. It's just a question of finding time to implement the changes, as with all projects The idea is that coroutines form different compilers should be inter-callable (even though the frame layout might be completely different beyond that specified for ABI).
[Bug tree-optimization/104275] New: Os does not apply return value optimization while O2 and O3 does
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104275
Bug ID: 104275
Summary: Os does not apply return value optimization while O2
and O3 does
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: andij.cr at gmail dot com
Target Milestone: ---
tested from gcc 8 to gcc 11
an identity function (mark) interposed in a call stack that ends in a complex
type is reasonably elided in O2 and O3, but at Os it creates a somewhat strange
assembly.
tested on arm32 and x86_64.
for a less artificial example, where the problem still appears:
https://gcc.godbolt.org/z/GbKrGKa6f
code:
https://godbolt.org/z/v95jEvvzc
// condensed result of a constexpr trasformation.
// in this form, it would be nice if it was transparent to the value
template
auto mark(Ts&& head) noexcept -> decltype(auto) {
return static_cast(head);
}
#include
// generic producer of a complex type
auto generate() -> std::vector;
// here is a stack of functions using mark
namespace {
// in an anonymous namespace to nudge the compiler to inline them
auto user_base() { return mark(generate()); }
auto user_mark() { return mark(user_base()); }
auto user_mark2() { return mark(user_mark()); }
auto user_mark3() { return mark(user_mark2()); }
} // namespace
// this function has a normal assembly at O2 and O3
// but a silly one at Os
auto user_mark4() { return mark(user_mark3()); }
compiled with
-std=c++17 -O2
user_mark4():
pushr12
mov r12, rdi
sub rsp, 32
mov rdi, rsp
callgenerate()
mov rax, QWORD PTR [rsp]
mov QWORD PTR [r12], rax
mov rax, QWORD PTR [rsp+8]
mov QWORD PTR [r12+8], rax
mov rax, QWORD PTR [rsp+16]
mov QWORD PTR [r12+16], rax
add rsp, 32
mov rax, r12
pop r12
ret
compiled with
-std=c++17 -Os
user_mark4():
pushr13
pushr12
mov r12, rdi
pushrbp
pushrbx
sub rsp, 40
lea rdi, [rsp+8]
callgenerate()
lea rdi, [rsp+8]
mov r13, QWORD PTR [rsp+8]
mov rbp, QWORD PTR [rsp+16]
mov QWORD PTR [rsp+8], 0
mov rbx, QWORD PTR [rsp+24]
mov QWORD PTR [rsp+16], 0
mov QWORD PTR [rsp+24], 0
callstd::_Vector_base
>::~_Vector_base() [base object destructor]
lea rdi, [rsp+8]
mov QWORD PTR [rsp+24], 0
mov QWORD PTR [rsp+16], 0
mov QWORD PTR [rsp+8], 0
callstd::_Vector_base
>::~_Vector_base() [base object destructor]
lea rdi, [rsp+8]
mov QWORD PTR [rsp+24], 0
mov QWORD PTR [rsp+16], 0
mov QWORD PTR [rsp+8], 0
callstd::_Vector_base
>::~_Vector_base() [base object destructor]
lea rdi, [rsp+8]
mov QWORD PTR [rsp+24], 0
mov QWORD PTR [rsp+16], 0
mov QWORD PTR [rsp+8], 0
callstd::_Vector_base
>::~_Vector_base() [base object destructor]
mov QWORD PTR [r12], r13
lea rdi, [rsp+8]
mov QWORD PTR [r12+8], rbp
mov QWORD PTR [r12+16], rbx
mov QWORD PTR [rsp+24], 0
mov QWORD PTR [rsp+16], 0
mov QWORD PTR [rsp+8], 0
callstd::_Vector_base
>::~_Vector_base() [base object destructor]
add rsp, 40
mov rax, r12
pop rbx
pop rbp
pop r12
pop r13
ret
[Bug c++/92752] [9/10/11 Regression] Bogus "ignored qualifiers" warning on const-qualified pointer-to-member-function objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92752 Patrick Palka changed: What|Removed |Added Summary|[9/10/11/12 Regression] |[9/10/11 Regression] Bogus |Bogus "ignored qualifiers" |"ignored qualifiers" |warning on const-qualified |warning on const-qualified |pointer-to-member-function |pointer-to-member-function |objects |objects --- Comment #3 from Patrick Palka --- Fixed for GCC 12 so far.
[Bug c++/92752] [9/10/11/12 Regression] Bogus "ignored qualifiers" warning on const-qualified pointer-to-member-function objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92752 --- Comment #2 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:e971990cbda091b4caf5e1a5bded5121068934e4 commit r12-6926-ge971990cbda091b4caf5e1a5bded5121068934e4 Author: Patrick Palka Date: Fri Jan 28 15:41:15 2022 -0500 c++: bogus warning with value init of const pmf [PR92752] Here we're emitting a -Wignored-qualifiers warning for an intermediate compiler-generated cast of nullptr to 'method-type* const' as part of value initialization of a const pmf. This patch suppresses the warning by instead casting to the corresponding unqualified type. PR c++/92752 gcc/cp/ChangeLog: * typeck.cc (build_ptrmemfunc): Cast a nullptr constant to the unqualified pointer type not the qualified one. gcc/testsuite/ChangeLog: * g++.dg/warn/Wignored-qualifiers2.C: New test. Co-authored-by: Jason Merrill
[Bug target/104253] libgcc missing __floatdiif
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104253 --- Comment #7 from Jakub Jelinek --- Conversion from __ibm128 to float/double etc. are done differently, and for si <-> if named tf we want to use di instead. So, shouldn't we just add + set_conv_libfunc (sfix_optab, DImode, mode, "__fixtfdi"); + set_conv_libfunc (ufix_optab, DImode, mode, "__fixunstfdi"); + + set_conv_libfunc (sfloat_optab, mode, DImode, "__floatditf"); + set_conv_libfunc (ufloat_optab, mode, DImode, "__floatunditf"); and nothing else?
[Bug target/101891] Adjust -fzero-call-used-regs to always use XOR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101891 qinzhao at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2022-01-28 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1
[Bug analyzer/104274] New: FAIL: gcc.dg/analyzer/pr97029.c (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104274 Bug ID: 104274 Summary: FAIL: gcc.dg/analyzer/pr97029.c (test for excess errors) Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org Target Milestone: --- Host: hppa*-*-hpux* Target: hppa*-*-hpux* Build: hppa*-*-hpux* spawn -ignore SIGHUP /home/dave/gnu/gcc/objdir64/gcc/xgcc -B/home/dave/gnu/gcc/o bjdir64/gcc/ /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/analyzer/pr97029.c -fdi agnostics-plain-output -fanalyzer -Wanalyzer-too-complex -fanalyzer-call-summari es -S -o pr97029.s /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/analyzer/pr97029.c: In function 'set jmp': /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/analyzer/pr97029.c:6:3: warning: use of uninitialized value 'pl.0' [CWE-457] [-Wanalyzer-use-of-uninitialized-value] /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/analyzer/pr97029.c:6:3: note: (1) us e of uninitialized value 'pl.0' here FAIL: gcc.dg/analyzer/pr97029.c (test for excess errors) Excess errors: /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/analyzer/pr97029.c:6:3: warning: use of uninitialized value 'pl.0' [CWE-457] [-Wanalyzer-use-of-uninitialized-value]
[Bug analyzer/104273] New: FAIL: gcc.dg/analyzer/pr103526.c (test for bogus messages, line 31)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104273 Bug ID: 104273 Summary: FAIL: gcc.dg/analyzer/pr103526.c (test for bogus messages, line 31) Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org Target Milestone: --- Host: hppa*-*-* Target: hppa*-*-* Build: hppa*-*-* spawn -ignore SIGHUP /home/dave/gnu/gcc/objdir64/gcc/xgcc -B/home/dave/gnu/gcc/o bjdir64/gcc/ /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/analyzer/pr103526.c -fd iagnostics-plain-output -fanalyzer -Wanalyzer-too-complex -fanalyzer-call-summar ies -S -o pr103526.s /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/analyzer/pr103526.c: In function 'game_new': /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/analyzer/pr103526.c:31:1: warning: leak of 'tmp.word_state' [CWE-401] [-Wanalyzer-malloc-leak] /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/analyzer/pr103526.c:20:31: note: (1) allocated here /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/analyzer/pr103526.c:20:12: note: (2) assuming 'tmp.word_state' is non-NULL /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/analyzer/pr103526.c:20:12: note: (3) following 'false' branch... /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/analyzer/pr103526.c:22:21: note: (4) ...to here /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/analyzer/pr103526.c:22:12: note: (5) following 'false' branch (when 'rval' is non-NULL)... /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/analyzer/pr103526.c:24:9: note: (6) ...to here /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/analyzer/pr103526.c:31:1: note: (7) 'tmp.word_state' leaks here; was allocated at (1) FAIL: gcc.dg/analyzer/pr103526.c (test for bogus messages, line 31) PASS: gcc.dg/analyzer/pr103526.c (test for excess errors)
[Bug c++/104255] parsing function signature fails when it uses a function parameter outside of an unevaluated context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104255
--- Comment #3 from qingzhe huang ---
(In reply to Patrick Palka from comment #2)
> The error message is obscure, but it seems what GCC has issue with here is
> the use of the function parameter seq2 in the trailing return type occurring
> outside of an unevaluated context.
>
The error messages are issued in a cascading fashion, the "outside function
parameter" is issued much later which maybe far-fetched from core one, in my
guess.
> I'm not totally sure if the testcase is valid
> (https://eel.is/c++draft/basic.scope.param#note-1 might suggest it's not?),
> but one workaround is to replace the use of seq2 in the trailing return type
> with decltype(seq2){} (which works because index_sequence is an empty type).
This is about "parameter-declaration-clause" which is not our case, because
"f(e)" is not function declaration part, instead an invoking of function of
which "e" is not "declaration" at all, but an argument of function.
> Here's a minimal testcase demonstrating the issue
>
> struct empty { };
> constexpr int f(empty) { return 0; }
> template struct A { };
> auto g(empty e) -> A;
Again, GCC is only one rejecting this code
(https://www.godbolt.org/z/1bvMavKKd) which makes me suspect that GCC may not
be correct.
> which is rejected with
>
> error: use of parameter outside function body before ‘)’ token
>
> due to 'e' being used outside of an unevaluated context within the signature
> of the function.
BTW, this has nothing to do with c++20(no -std=c++20 is needed) which
eliminates potential issues of many c++20 new features. Thank you for your
simplified case which is a much clearer one to demonstrate the core issue.
[Bug testsuite/70230] 11 test regressions when building GCC 6 with --enable-default-ssp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70230 Jeffrey A. Law changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED CC||law at gcc dot gnu.org --- Comment #7 from Jeffrey A. Law --- Fixed on the trunk.
[Bug middle-end/19987] [meta-bug] fold missing optimizations in general
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19987 Bug 19987 depends on bug 95424, which changed state. Bug 95424 Summary: Failure to optimize division with numerator of 1 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95424 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/95424] Failure to optimize division with numerator of 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95424 Jeffrey A. Law changed: What|Removed |Added CC||law at gcc dot gnu.org Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Jeffrey A. Law --- Fixed on the trunk.
[Bug fortran/104272] New: finalizer gets called during allocate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104272 Bug ID: 104272 Summary: finalizer gets called during allocate Product: gcc Version: 9.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: kai.germaschewski at gmail dot com Target Milestone: --- Created attachment 52310 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52310=edit reproducer This issue appears to be present in gfortran-9,10,11. A minimal reproducer is provided. I have an abstract base class, from which one class is derived which itself is further derived one more time. When allocating an array of the most-derived type, for some reason the finalizer of the intermediate class is called. This does not happen with ifort or xlf, and I don't think it should happen. output: allocating solver_gpu_final<-- this being called is a bug (IMHO) allocating done solver_sparse_gpu_final solver_sparse_gpu_final solver_gpu_final solver_gpu_final
[Bug target/104253] libgcc missing __floatdiif
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104253 --- Comment #6 from Jakub Jelinek --- (In reply to Michael Meissner from comment #4) > Created attachment 52306 [details] > Patch to use the correct names for __ibm128 converts if long double is IEEE > 128-bit > > The problem was internally there are 3 types for 128-bit floating point: > TFmode -- mode for the type long double > IFmode -- mode for __ibm128 if long double is IEEE 128-bit > KFmode -- mode for __float128 > > There was not a conversion function specified to convert between IFmode and > other modes, so the machine independent portion of the compiler created a > name with 'if' in it. > > This patch specifies the names for the conversion functions to use the > traditional TF modes. None of these functions except for the DI <-> IF (called tf) functions actually exist in libgcc though.
[Bug tree-optimization/95424] Failure to optimize division with numerator of 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95424
--- Comment #7 from CVS Commits ---
The master branch has been updated by Jeff Law :
https://gcc.gnu.org/g:c2b610e7c6c89fd422c5c31f01023bcddf3cf4a5
commit r12-6924-gc2b610e7c6c89fd422c5c31f01023bcddf3cf4a5
Author: Zhao Wei Liew
Date: Fri Jan 28 13:36:39 2022 -0500
match.pd: Simplify 1 / X for integer X [PR95424]
This patch implements an optimization for the following C++ code:
int f(int x) {
return 1 / x;
}
int f(unsigned int x) {
return 1 / x;
}
Before this patch, x86-64 gcc -std=c++20 -O3 produces the following
assembly:
f(int):
xor edx, edx
mov eax, 1
idiv edi
ret
f(unsigned int):
xor edx, edx
mov eax, 1
div edi
ret
In comparison, clang++ -std=c++20 -O3 produces the following assembly:
f(int):
lea ecx, [rdi + 1]
xor eax, eax
cmp ecx, 3
cmovb eax, edi
ret
f(unsigned int):
xor eax, eax
cmp edi, 1
sete al
ret
Clang's output is more efficient as it avoids expensive div operations.
With this patch, GCC now produces the following assembly:
f(int):
lea eax, [rdi + 1]
cmp eax, 2
mov eax, 0
cmovbe eax, edi
ret
f(unsigned int):
xor eax, eax
cmp edi, 1
sete al
ret
which is virtually identical to Clang's assembly output. Any slight
differences
in the output for f(int) is possibly related to a different missed
optimization.
v2: https://gcc.gnu.org/pipermail/gcc-patches/2022-January/587751.html
Changes from v2:
1. Refactor from using a switch statement to using the built-in
if-else statement.
v1: https://gcc.gnu.org/pipermail/gcc-patches/2022-January/587634.html
Changes from v1:
1. Refactor common if conditions.
2. Use build_[minus_]one_cst (type) to get -1/1 of the correct type.
3. Match only for TRUNC_DIV_EXPR and TYPE_PRECISION (type) > 1.
gcc/ChangeLog:
PR tree-optimization/95424
* match.pd: Simplify 1 / X where X is an integer.
[Bug tree-optimization/104269] [12 Regression] Bogus -Wuse-after-free seen in xen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104269 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=104232 --- Comment #2 from Andrew Pinski --- I think this might be the same as PR 104232.
[Bug c++/102204] OpenMP offload map type restriction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102204 --- Comment #3 from Ye Luo --- I tried today's main 3f0fcda37f58d4108feb67de08f181a32bcb6388. This issue persists. Any chance this will be resolved in 12 release?
[Bug testsuite/99175] FAIL: g++.dg/modules/bad-mapper-1.C -std=c++17 (test for errors, line )
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99175
Andrew Pinski changed:
What|Removed |Added
Component|c++ |testsuite
--- Comment #3 from Andrew Pinski ---
I take that back, it looks more like the testcase is not expecting some of the
error messages that happen on HPUX for this testcase.
It is only expecting:
// { dg-error "-:failed exec.*mapper.* .*this-will-not-work" "" { target *-*-*
} 0 }
But got:
cc1plus: error trying to exec 'this-will-not-work': execvp: No such file or
directory
A few other messages.
[Bug c++/99175] FAIL: g++.dg/modules/bad-mapper-1.C -std=c++17 (test for errors, line )
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99175 Andrew Pinski changed: What|Removed |Added Component|testsuite |c++ --- Comment #2 from Andrew Pinski --- Looks like the interface between the c++ front-end and the c++ tools is not working on hpux.
[Bug tree-optimization/104263] [10/11 Regression] '-fcompare-debug' failure (length) w/ -O2 -fnon-call-exceptions -fno-inline-small-functions since r10-3575-g629387a6586a7531
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104263 Jakub Jelinek changed: What|Removed |Added Summary|[10/11/12 Regression] |[10/11 Regression] |'-fcompare-debug' failure |'-fcompare-debug' failure |(length) w/ -O2 |(length) w/ -O2 |-fnon-call-exceptions |-fnon-call-exceptions |-fno-inline-small-functions |-fno-inline-small-functions |since |since |r10-3575-g629387a6586a7531 |r10-3575-g629387a6586a7531 --- Comment #11 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug tree-optimization/104263] [10/11/12 Regression] '-fcompare-debug' failure (length) w/ -O2 -fnon-call-exceptions -fno-inline-small-functions since r10-3575-g629387a6586a7531
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104263 --- Comment #10 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:a591c71b41e18e4ff86852a974592af4962aef57 commit r12-6923-ga591c71b41e18e4ff86852a974592af4962aef57 Author: Jakub Jelinek Date: Fri Jan 28 19:02:26 2022 +0100 store-merging: Fix up a -fcompare-debug bug in get_status_for_store_merging [PR104263] As mentioned in the PRthe following testcase fails, because the last stmt of a bb with -g is a debug stmt and get_status_for_store_merging uses gimple_seq_last_stmt (bb_seq (bb)) when testing if it is valid for store merging. The debug stmt isn't valid, while a stmt at that position with -g0 is valid and so the divergence. As we walk the whole bb already, this patch just remembers the last non-debug stmt, so that we don't need to skip backwards debug stmts at the end of the bb to find last real stmt. 2022-01-28 Jakub Jelinek PR tree-optimization/104263 * gimple-ssa-store-merging.cc (get_status_for_store_merging): For cfun->can_throw_non_call_exceptions && cfun->eh test whether last non-debug stmt in the bb is store_valid_for_store_merging_p rather than last stmt. * gcc.dg/pr104263.c: New test.
[Bug tree-optimization/104269] [12 Regression] Bogus -Wuse-after-free seen in xen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104269
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2022-01-28
Ever confirmed|0 |1
--- Comment #1 from Andrew Pinski ---
Since the warning runs after uncprop, it is the diagnostics are all wrong.
Before uncprop:
if (_6 == 0B)
goto ; [15.47%]
else
goto ; [84.53%]
[local count: 166107864]:
goto ; [100.00%]
[local count: 907633961]:
ret_buf_8 = malloc (0);
[local count: 1073741824]:
# ret_buf_2 = PHI
out:
free (_6);
dirent1.0_1 = dirent1;
free (dirent1.0_1);
dirent1 ={v} {CLOBBER};
return ret_buf_2;
After:
# ret_buf_2 = PHI
The warning is still not flow sensitive enough to know that _6 from bb5 will be
0B. and that doing free(0) does not matter.
[Bug testsuite/99175] FAIL: g++.dg/modules/bad-mapper-1.C -std=c++17 (test for errors, line )
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99175 John David Anglin changed: What|Removed |Added Host|hppa2.0w-hp-hpux11.11 |hppa*-*-hpux* Build|hppa2.0w-hp-hpux11.11 |hppa*-*-hpux* Target|hppa2.0w-hp-hpux11.11 |hppa*-*-hpux* --- Comment #1 from John David Anglin --- Similar: FAIL: g++.dg/modules/bad-mapper-1.C -std=c++17 at line 3 (test for errors, line ) FAIL: g++.dg/modules/bad-mapper-1.C -std=c++17 (test for excess errors) FAIL: g++.dg/modules/bad-mapper-1.C -std=c++2a at line 3 (test for errors, line ) FAIL: g++.dg/modules/bad-mapper-1.C -std=c++2a (test for excess errors) FAIL: g++.dg/modules/bad-mapper-1.C -std=c++2b at line 3 (test for errors, line ) FAIL: g++.dg/modules/bad-mapper-1.C -std=c++2b (test for excess errors) FAIL: g++.dg/modules/bad-mapper-3.C -std=c++17 at line 3 (test for errors, line ) FAIL: g++.dg/modules/bad-mapper-3.C -std=c++17 (test for excess errors) FAIL: g++.dg/modules/bad-mapper-3.C -std=c++2a at line 3 (test for errors, line ) FAIL: g++.dg/modules/bad-mapper-3.C -std=c++2a (test for excess errors) FAIL: g++.dg/modules/bad-mapper-3.C -std=c++2b at line 3 (test for errors, line ) FAIL: g++.dg/modules/bad-mapper-3.C -std=c++2b (test for excess errors)
[Bug tree-optimization/104269] [12 Regression] Bogus -Wuse-after-free seen in xen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104269 Andrew Pinski changed: What|Removed |Added Keywords||diagnostic Target Milestone|--- |12.0 Summary|Bogus -Wuse-after-free seen |[12 Regression] Bogus |in xen |-Wuse-after-free seen in ||xen
[Bug testsuite/70230] 11 test regressions when building GCC 6 with --enable-default-ssp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70230 --- Comment #6 from CVS Commits --- The master branch has been updated by Jeff Law : https://gcc.gnu.org/g:90c31ff339015ddd89ac519656fbd23a36ee6271 commit r12-6922-g90c31ff339015ddd89ac519656fbd23a36ee6271 Author: Allan McRae Date: Fri Jan 28 12:44:08 2022 -0500 testsuite/70230 - fix failures with default SSP\ Configuring with --enable-default-ssp triggers various testsuite failures. These contain asm statements that are not compatible with -fstack-protector. Adding -fno-stack-protector to dg-options to work around this issue. Tested on x86_64-linux. PR testsuite/70230 * gcc.dg/asan/use-after-scope-4.c (dg-options): Add -fno-stack-protector. * gcc.dg/stack-usage-1.c: Likewise * gcc.dg/superblock.c: Likewise * gcc.target/i386/avx-vzeroupper-17.c: Likewise * gcc.target/i386/cleanup-1.c: Likewise * gcc.target/i386/cleanup-2.c: Likewise * gcc.target/i386/interrupt-redzone-1.c: Likewise * gcc.target/i386/interrupt-redzone-2.c: Likewise * gcc.target/i386/pr79793-1.c: Likewise * gcc.target/i386/pr79793-2.c: Likewise * gcc.target/i386/shrink_wrap_1.c: Likewise * gcc.target/i386/stack-check-11.c: Likewise * gcc.target/i386/stack-check-18.c: Likewise * gcc.target/i386/stack-check-19.c: Likewise * gcc.target/i386/stackalign/pr88483-1.c: Likewise * gcc.target/i386/stackalign/pr88483-2.c: Likewise * gcc.target/i386/sw-1.c: Likewise
[Bug ipa/103171] [12 Regression] ICE Segmentation fault since r12-2523-g13586172d0b70c9d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103171 --- Comment #5 from Martin Jambor --- I have proposed a patch on the mailing list: https://gcc.gnu.org/pipermail/gcc-patches/2022-January/589429.html
[Bug target/104271] New: 538.imagick_r run-time at -Ofast -march=native regressed by 26% on Intel Cascade Lake server CPU
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104271 Bug ID: 104271 Summary: 538.imagick_r run-time at -Ofast -march=native regressed by 26% on Intel Cascade Lake server CPU Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: jamborm at gcc dot gnu.org CC: liuhongt at gcc dot gnu.org Blocks: 26163 Target Milestone: --- Host: x86_64-linux Target: x86_64-linux On our Intel Cascade Lake server CPU, the benchmark 538.imagick_r from the SPEC 2017 FPrate suite is 26% slower when built with GCC 12 using options -Ofast -march=native than when built with GCC 11 with the same options. I have bisected the issue to r12-2549-g872da9a6f664a0: 872da9a6f664a06d73c987aa0cb2e5b830158a10 is the first bad commit commit 872da9a6f664a06d73c987aa0cb2e5b830158a10 Author: liuhongt Date: Fri Mar 26 10:56:47 2021 +0800 Add the member integer_to_sse to processor_cost as a cost simulation for movd/pinsrd. It will be used to calculate the cost of vec_construct. gcc/ChangeLog: PR target/99881 * config/i386/i386.h (processor_costs): Add new member integer_to_sse. * config/i386/x86-tune-costs.h (ix86_size_cost, i386_cost, i486_cost, pentium_cost, lakemont_cost, pentiumpro_cost, geode_cost, k6_cost, athlon_cost, k8_cost, amdfam10_cost, bdver_cost, znver1_cost, znver2_cost, znver3_cost, btver1_cost, btver2_cost, btver3_cost, pentium4_cost, nocona_cost, atom_cost, atom_cost, slm_cost, intel_cost, generic_cost, core_cost): Initialize integer_to_sse same value as sse_op. (skylake_cost): Initialize integer_to_sse twice as much as sse_op. * config/i386/i386.c (ix86_builtin_vectorization_cost): Use integer_to_sse instead of sse_op to calculate the cost of vec_construct. It is very likely that the problem is a load-to-store-forwarding stall issue and so related to PR 80689 but the commit makes it either more frequent or much worse. Sorry for reporting this so late, unfortunately we do not benchmark this class of CPUs periodically. We do not see the problem on any of the AMD Zens or Intel Kabylake (client) CPUs. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 [Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
[Bug modula2/101391] Unresolved reference to module getopt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101391 --- Comment #8 from Gaius Mulley --- Is it okay to close this PR as I've git committed some regression tests to check that cgetopt and (other modules) are present and visible to the linker? https://gcc.gnu.org/pipermail/gcc-cvs/2022-January/359926.html
[Bug target/103676] [10/11 Regression] internal compiler error: in extract_constrain_insn, at recog.c:2671
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103676 Jakub Jelinek changed: What|Removed |Added Summary|[10/11/12 Regression] |[10/11 Regression] internal |internal compiler error: in |compiler error: in |extract_constrain_insn, at |extract_constrain_insn, at |recog.c:2671|recog.c:2671 --- Comment #25 from Jakub Jelinek --- Fixed on the trunk.
[Bug middle-end/103616] [9/10/11/12 Regression] ICE on ceph with systemtap macro since r8-5608
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103616 --- Comment #2 from Jakub Jelinek --- #c0 doesn't ICE on the trunk since r12-5944-ga7acb6dca941db2b1c135107dac3a34a20650d5c
[Bug c++/92752] [9/10/11/12 Regression] Bogus "ignored qualifiers" warning on const-qualified pointer-to-member-function objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92752 Patrick Palka changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org
[Bug fortran/104228] [9/10/11/12 Regression] ICE in df_install_ref, at df-scan.cc:2294 since r8-3589-g707905d0773e5a8e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104228
Jakub Jelinek changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #5 from Jakub Jelinek ---
If the testcase is extended to:
program p
character(:), save, allocatable :: x(:)
call s1
call s2
call s3
call s4
contains
subroutine s1
associate (y1 => x)
y1 = [x]
end associate
end
subroutine s2
associate (y2 => x)
y2 = [x]
end associate
end
subroutine s3
associate (y3 => x)
y3 = [x]
end associate
end
subroutine s4
associate (y4 => x)
y4 = [x]
end associate
end
end
then the p program contains just one of those y vars (y4/.y4):
__attribute__((fn spec (". ")))
void p ()
{
static voidD.27 s4D.4214 (void);
static voidD.27 s3D.4216 (void);
static voidD.27 s2D.4218 (void);
static voidD.27 s1D.4220 (void);
struct array01_character(kind=1) y4D.4244;
static integer(kind=8)D.9 .y4D.4222;
static struct array01_character(kind=1) xD.4255 = {.dataD.4250=0B};
bitsizetype D.4401;
sizetype D.4402;
D.4401 = (bitsizetype) (sizetype) NON_LVALUE_EXPR <.y4D.4222> * 8;
D.4402 = (sizetype) NON_LVALUE_EXPR <.y4D.4222>;
s1D.4220 ();
s2D.4218 ();
s3D.4216 ();
s4D.4214 ();
}
Now, if that .y4 randomly called based on one of the associate users is just
named character length of the x
array (shouldn't it be called .x ?) of a SAVE var in p, I'd think it should go
to the BLOCK where x is defined and nowhere else, all the nested functions (==
contained subroutines) should refer to it non-locally and shouldn't have it in
its BLOCK_VARS.
[Bug tree-optimization/94801] Failure to optimize narrowed __builtin_clz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94801 dragan.mladjenovic at syrmia dot com changed: What|Removed |Added CC||dragan.mladjenovic at syrmia dot c ||om --- Comment #9 from dragan.mladjenovic at syrmia dot com --- Note that the transformation that the clang does seems to be target specific, so it won't trigger for example on Aarch64. It does so on x86 irrespective of the availability of lzcnt instruction.
[Bug rtl-optimization/102178] [12 Regression] SPECFP 2006 470.lbm regressions on AMD Zen CPUs after r12-897-gde56f95afaaa22
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102178
--- Comment #27 from Vladimir Makarov ---
(In reply to Richard Biener from comment #17)
> So in .reload we have (with unpatched trunk)
>
> 401: NOTE_INSN_BASIC_BLOCK 6
> 462: ax:DF=[`*.LC0']
> REG_EQUAL 9.8506899724167309977929107844829559326171875e-1
> 407: xmm2:DF=ax:DF
> 463: ax:DF=[`*.LC0']
> REG_EQUAL 9.8506899724167309977929107844829559326171875e-1
> 408: xmm4:DF=ax:DF
>
> why??! We can load .LC0 into xmm4 directly. IRA sees
>
> 401: NOTE_INSN_BASIC_BLOCK 6
> 407: r118:DF=r482:DF
> 408: r119:DF=r482:DF
>
> now I cannot really decipher IRA or LRA dumps but my guess would be that
> inheritance (causing us to load from LC0) interferes badly with register
> class assignment?
>
> Changing pseudo 482 in operand 1 of insn 407 on equiv
> 9.8506899724167309977929107844829559326171875e-1
> ...
> alt=21,overall=9,losers=1,rld_nregs=1
> Choosing alt 21 in insn 407: (0) v (1) r {*movdf_internal}
> Creating newreg=525, assigning class GENERAL_REGS to r525
> 407: r118:DF=r525:DF
> Inserting insn reload before:
> 462: r525:DF=[`*.LC0']
> REG_EQUAL 9.8506899724167309977929107844829559326171875e-1
>
> we should have preferred alt 14 I think (0) v (1) m, but that has
>
> alt=14,overall=13,losers=1,rld_nregs=0
> 0 Spill pseudo into memory: reject+=3
> Using memory insn operand 0: reject+=3
> 0 Non input pseudo reload: reject++
> 1 Non-pseudo reload: reject+=2
> 1 Non input pseudo reload: reject++
> alt=15,overall=28,losers=3 -- refuse
> 0 Costly set: reject++
> alt=16: Bad operand -- refuse
> 0 Costly set: reject++
> 1 Costly loser: reject++
> 1 Non-pseudo reload: reject+=2
> 1 Non input pseudo reload: reject++
> alt=17,overall=17,losers=2 -- refuse
> 0 Costly set: reject++
> 1 Spill Non-pseudo into memory: reject+=3
> Using memory insn operand 1: reject+=3
> 1 Non input pseudo reload: reject++
> alt=18,overall=14,losers=1 -- refuse
> 0 Spill pseudo into memory: reject+=3
> Using memory insn operand 0: reject+=3
> 0 Non input pseudo reload: reject++
> 1 Costly loser: reject++
> 1 Non-pseudo reload: reject+=2
> 1 Non input pseudo reload: reject++
> alt=19,overall=29,losers=3 -- refuse
> 0 Non-prefered reload: reject+=600
> 0 Non input pseudo reload: reject++
> alt=20,overall=607,losers=1 -- refuse
> 1 Non-pseudo reload: reject+=2
> 1 Non input pseudo reload: reject++
>
> I'm not sure I can decipher the reasoning but I don't understand how it
> doesn't seem to anticipate the cost of reloading the GPR in the alternative
> it chooses?
>
> Vlad?
All this diagnostics is just description of voodoo from the old reload pass.
LRA choosing alternative the same way as the old reload pass (I doubt that any
other approach will not break all existing targets). Simply the old reload
pass does not report its decisions in the dump.
LRA code (lra-constraints.cc::process_alt_operands) choosing the insn
alternatives (as the old reload pass) does not use any memory or register move
costs. Instead, the alternative is chosen by heuristics and insn constraints
hints (like ? !). The only case where these costs are used, when we have
reg:=reg and the register move costs for this is 2. In this case LRA(reload)
does not bother to check the insn constraints.
[Bug c++/104266] Temporaries with protected destructor are erroneously permitted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104266 Jiang An changed: What|Removed |Added CC||de34 at live dot cn --- Comment #1 from Jiang An --- I think this is CWG DR 2227 (https://wg21.link/cwg2227). And IIUC although it is correct to reject this code, clang's error message is wrong, because there's no temporary of type 'A' created due to guaranteed RVO since C++17.
[Bug fortran/104228] [9/10/11/12 Regression] ICE in df_install_ref, at df-scan.cc:2294 since r8-3589-g707905d0773e5a8e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104228 --- Comment #4 from Jakub Jelinek --- The .y var is added into the s function with: #0 add_decl_as_local (decl=) at ../../gcc/fortran/trans-decl.cc:257 #1 0x00c054f8 in gfc_finish_var_decl (decl=, sym=0x3e16a00) at ../../gcc/fortran/trans-decl.cc:649 #2 0x00c09e9e in gfc_get_symbol_decl (sym=0x3e16a00) at ../../gcc/fortran/trans-decl.cc:1882 #3 0x00c18dee in generate_local_decl (sym=0x3e16a00) at ../../gcc/fortran/trans-decl.cc:5853 #4 0x00bb5174 in do_traverse_symtree (st=0x3e16b60, st_func=0x0, sym_func=0xc18d2a ) at ../../gcc/fortran/symbol.cc:4174 #5 0x00bb522f in gfc_traverse_ns (ns=0x3e19810, sym_func=0xc18d2a ) at ../../gcc/fortran/symbol.cc:4199 #6 0x00c19780 in generate_local_vars (ns=0x3e19810) at ../../gcc/fortran/trans-decl.cc:6064 #7 0x00c20fae in gfc_process_block_locals (ns=0x3e19810) at ../../gcc/fortran/trans-decl.cc:7940 #8 0x00ca8b60 in gfc_trans_block_construct (code=0x3e16ba0) at ../../gcc/fortran/trans-stmt.cc:2296 #9 0x00bd8645 in trans_code (code=0x3e16ba0, cond=) at ../../gcc/fortran/trans.cc:2012 #10 0x00bd8a58 in gfc_trans_code (code=0x3e16ba0) at ../../gcc/fortran/trans.cc:2268 #11 0x00c203ea in gfc_generate_function_code (ns=0x3e15530) at ../../gcc/fortran/trans-decl.cc:7654 #12 0x00c18b5d in gfc_generate_contained_functions (parent=0x3e14530) at ../../gcc/fortran/trans-decl.cc:5777 #13 0x00c20031 in gfc_generate_function_code (ns=0x3e14530) at ../../gcc/fortran/trans-decl.cc:7586 #14 0x00bd8a9c in gfc_generate_code (ns=0x3e14530) at ../../gcc/fortran/trans.cc:2285 #15 0x00b5ca50 in translate_all_program_units (gfc_global_ns_list=0x3e14530) at ../../gcc/fortran/parse.cc:6651 #16 0x00b5d299 in gfc_parse_file () at ../../gcc/fortran/parse.cc:6938 #17 0x00bc0539 in gfc_be_parse_file () at ../../gcc/fortran/f95-lang.cc:216 #18 0x01463e4f in compile_file () at ../../gcc/toplev.cc:452 #19 0x01466e45 in do_compile (no_backend=false) at ../../gcc/toplev.cc:2158 #20 0x0146720a in toplev::main (this=0x7fffd76a, argc=4, argv=0x7fffd878) at ../../gcc/toplev.cc:2310 #21 0x02b3c444 in main (argc=4, argv=0x7fffd878) at ../../gcc/main.cc:39 and then pushdecl is called on it too: #0 pushdecl (decl=) at ../../gcc/fortran/f95-lang.cc:442 #1 0x00c21086 in gfc_process_block_locals (ns=0x3e19810) at ../../gcc/fortran/trans-decl.cc:7952 #2 0x00ca8b60 in gfc_trans_block_construct (code=0x3e16ba0) at ../../gcc/fortran/trans-stmt.cc:2296 #3 0x00bd8645 in trans_code (code=0x3e16ba0, cond=) at ../../gcc/fortran/trans.cc:2012 #4 0x00bd8a58 in gfc_trans_code (code=0x3e16ba0) at ../../gcc/fortran/trans.cc:2268 #5 0x00c203ea in gfc_generate_function_code (ns=0x3e15530) at ../../gcc/fortran/trans-decl.cc:7654 #6 0x00c18b5d in gfc_generate_contained_functions (parent=0x3e14530) at ../../gcc/fortran/trans-decl.cc:5777 #7 0x00c20031 in gfc_generate_function_code (ns=0x3e14530) at ../../gcc/fortran/trans-decl.cc:7586 #8 0x00bd8a9c in gfc_generate_code (ns=0x3e14530) at ../../gcc/fortran/trans.cc:2285 #9 0x00b5ca50 in translate_all_program_units (gfc_global_ns_list=0x3e14530) at ../../gcc/fortran/parse.cc:6651 #10 0x00b5d299 in gfc_parse_file () at ../../gcc/fortran/parse.cc:6938 #11 0x00bc0539 in gfc_be_parse_file () at ../../gcc/fortran/f95-lang.cc:216 #12 0x01463e4f in compile_file () at ../../gcc/toplev.cc:452 #13 0x01466e45 in do_compile (no_backend=false) at ../../gcc/toplev.cc:2158 #14 0x0146720a in toplev::main (this=0x7fffd76a, argc=4, argv=0x7fffd878) at ../../gcc/toplev.cc:2310 #15 0x02b3c444 in main (argc=4, argv=0x7fffd878) at ../../gcc/main.cc:39 with cfun->decl of s and once again in: #0 pushdecl (decl=) at ../../gcc/fortran/f95-lang.cc:442 #1 0x00c20b7e in gfc_generate_function_code (ns=0x3e14530) at ../../gcc/fortran/trans-decl.cc:7768 #2 0x00bd8a9c in gfc_generate_code (ns=0x3e14530) at ../../gcc/fortran/trans.cc:2285 #3 0x00b5ca50 in translate_all_program_units (gfc_global_ns_list=0x3e14530) at ../../gcc/fortran/parse.cc:6651 #4 0x00b5d299 in gfc_parse_file () at ../../gcc/fortran/parse.cc:6938 #5 0x00bc0539 in gfc_be_parse_file () at ../../gcc/fortran/f95-lang.cc:216 #6 0x01463e4f in compile_file () at ../../gcc/toplev.cc:452 #7 0x01466e45 in do_compile (no_backend=false) at ../../gcc/toplev.cc:2158 #8 0x0146720a in toplev::main (this=0x7fffd76a, argc=4, argv=0x7fffd878) at ../../gcc/toplev.cc:2310 #9 0x02b3c444 in main (argc=4, argv=0x7fffd878) at ../../gcc/main.cc:39 with cfun->decl of p.
[Bug c++/102449] template parameter with default argument is used without being verified during explicit specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102449 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Patrick Palka --- (In reply to Andrew Pinski from comment #1) > I think this is valid code as the compiler can deduce that First is int. > All compilers I have tried accept the code. Agreed.
[Bug c++/101783] unnecessary error when top level cv qualifier is dropped
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101783 Patrick Palka changed: What|Removed |Added Target Milestone|--- |12.0 Resolution|--- |FIXED CC||ppalka at gcc dot gnu.org Status|NEW |RESOLVED Assignee|unassigned at gcc dot gnu.org |nickhuang99 at hotmail dot com --- Comment #11 from Patrick Palka --- Marking as fixed for GCC 12, thanks for working on this!
[Bug rtl-optimization/102178] [12 Regression] SPECFP 2006 470.lbm regressions on AMD Zen CPUs after r12-897-gde56f95afaaa22
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102178 --- Comment #26 from Vladimir Makarov --- (In reply to Richard Biener from comment #7) > make costs in a way that IRA/LRA prefer re-materialization of constants > from the constant pool over spilling to GPRs (if that's possible at all - > Vlad?) LRA rematerialization can not rematerialize constant value from memory pool. It can rematerialize value of expression only consisting of other pseudos (currently assigned to hard regs) and constants. I guess rematerialization pass can be extended to work for constants from constant memory pool. It is pretty doable project opposite to rematerialization of any memory which would require a lot analysis including aliasing and complicated cost calculation benefits. May be somebody could pick this project up.
[Bug fortran/104228] [9/10/11/12 Regression] ICE in df_install_ref, at df-scan.cc:2294 since r8-3589-g707905d0773e5a8e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104228
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek ---
Seems to be a FE bug.
Already in *.gimple bug with -fdump-tree-all-uid one can see:
__attribute__((fn spec (". ")))
void p ()
{
static voidD.27 sD.4214 (void);
struct array01_character(kind=1) yD.4238;
static integer(kind=8)D.9 .yD.4216;
static struct array01_character(kind=1) xD.4249 = {.dataD.4244=0B};
bitsizetype D.4278;
sizetype D.4279;
try
{
...
__attribute__((fn spec (". ")))
void s ()
{
bitsizetype D.4285;
sizetype .y.10D.4286;
integer(kind=8)D.9 iftmp.14D.4287;
{
static integer(kind=8)D.9 .yD.4216;
static struct array01_character(kind=1) xD.4249 = {.dataD.4244=0B};
bitsizetype D.4278;
sizetype D.4279;
That means that BLOCK_VARS of a BLOCK inside of p function contain
s var with DECL_UID 4214, its DECL_CHAIN is y with DECL_UID 4238 and
its DECL_CHAIN is .y with DECL_UID 4216.
But the same .y var with DECL_UID 4216 is also in BLOCK_VARS of another BLOCK
inside of s. Vars in BLOCK_VARS are chained through DECL_CHAIN, aren't in some
vec or TREE_VEC etc., so can't be part of multiple chains.
[Bug analyzer/104270] New: -Wanalyzer-use-of-uninitialized-value is incorrectly suppressed by -ftrivial-auto-var-init=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104270
Bug ID: 104270
Summary: -Wanalyzer-use-of-uninitialized-value is incorrectly
suppressed by -ftrivial-auto-var-init=
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
As of GCC 12, the analyzer ought to complain about uses of uninitialized memory
via
-Wanalyzer-use-of-uninitialized-value
but fails to do so for trivial cases of locals when -ftrivial-auto-var-init= is
used with "pattern" or "zero".
The docs for -ftrivial-auto-var-init say:
> GCC still considers an automatic variable that doesn't have an explicit
> initializer as uninitialized, @option{-Wuninitialized} will still report
> warning messages on such automatic variables.
which implies that -ftrivial-auto-var-init is intended for mitigation, and that
the analyzer ought to still warn on such cases.
At the gimple level we have e.g.:
i_1 = .DEFERRED_INIT (4, 1, &"i"[0]);
which the analyzer doesn't yet have any special knowledge about, and thus
treats the result as a normal value, suppressing the warning.
[Bug middle-end/103483] [12 regression] context-sensitive ranges change triggers stringop-overread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103483 --- Comment #21 from Jeffrey A. Law --- Yes, the wording is dreadful. Yes we need a better way to express to the user the paths followed and how they impacted the analysis. As for suppressing. There's not a great option here, which isn't a huge surprise. In this specific case we'd need to be able to make mystrlen less opaque, particularly WRT its return value. Even if we had a solution to do that, it's still far from good IMHO -- you end up with annotations all over the place.
[Bug c++/104255] parsing trailing return type fails with parameter pack expansion when two parameter packs at present
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104255
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
--- Comment #2 from Patrick Palka ---
The error message is obscure, but it seems what GCC has issue with here is the
use of the function parameter seq2 in the trailing return type occurring
outside of an unevaluated context.
I'm not totally sure if the testcase is valid
(https://eel.is/c++draft/basic.scope.param#note-1 might suggest it's not?), but
one workaround is to replace the use of seq2 in the trailing return type with
decltype(seq2){} (which works because index_sequence is an empty type).
Here's a minimal testcase demonstrating the issue
struct empty { };
constexpr int f(empty) { return 0; }
template struct A { };
auto g(empty e) -> A;
which is rejected with
error: use of parameter outside function body before ‘)’ token
due to 'e' being used outside of an unevaluated context within the signature of
the function.
[Bug middle-end/103616] [9/10/11/12 Regression] ICE on ceph with systemtap macro since r8-5608
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103616 --- Comment #1 from Vladimir Makarov --- I can not reproduce ICE on this week GCC. Probably it was fixed (or switched off) by some recent RA patch. As for the second issue (code generation for function foo), I thought for some time how it could be fixed. It seemed that LRA inheritance sub-pass could be extended to work on memory too besides regs. But I got to conclusion that it would complicate already complicated LRA (inheritance subpass) more as we need to add sophisticated analysis (including aliasing) for memory. I guess there is an simpler alternative solution. The problem would disappear if double constant were in asm insn before LRA. I think some pass before RA could this. It could be driven by a target, for example to promote double constants for x86-64. Also the problem might be solved if we had pseudo<-double insn instead of mem<-double insn before LRA, LRA code dealing with equiv could promote double into the asm insn (although I am not 100% sure about this but, if it is not the case, probably code dealing with equiv could be tweaked to do this). So my proposal is to solve the problem somehow outside RA.
[Bug tree-optimization/103035] [meta-bug] YARPGen bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103035 Bug 103035 depends on bug 103489, which changed state. Bug 103489 Summary: [11 Regression] ICE with -O3 in operator[], at vec.h:889 since r12-5394-g0fc859f5efcb4624 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103489 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/103489] [11 Regression] ICE with -O3 in operator[], at vec.h:889 since r12-5394-g0fc859f5efcb4624
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103489 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Richard Biener --- Fixed.
[Bug tree-optimization/103596] [9/10/11 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p, at gimple-expr.c:88 since r8-565-g7581ce9a1ad6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103596 --- Comment #7 from CVS Commits --- The releases/gcc-11 branch has been updated by Richard Biener : https://gcc.gnu.org/g:08f594465fa9b6a4ea1e3816cfecf256e883ff53 commit r11-9524-g08f594465fa9b6a4ea1e3816cfecf256e883ff53 Author: Richard Biener Date: Tue Dec 7 11:13:39 2021 +0100 tree-optimization/103596 - fix missed propagation into switches may_propagate_copy unnecessarily restricts propagating non-abnormals into places that currently contain an abnormal SSA name but are not the PHI argument for an abnormal edge. This causes VN to not elide a CFG path that it assumes is elided, resulting in released SSA names in the IL. The fix is to enhance the may_propagate_copy API to specify the destination is _not_ a PHI argument. I chose to not update only the relevant caller in VN and the may_propagate_copy_into_stmt API at this point because this is a regression and needs backporting. 2021-12-07 Richard Biener PR tree-optimization/103596 * tree-ssa-sccvn.c (eliminate_dom_walker::eliminate_stmt): Note we are not propagating into a PHI argument to may_propagate_copy. * tree-ssa-propagate.h (may_propagate_copy): Add argument specifying whether we propagate into a PHI arg. * tree-ssa-propagate.c (may_propagate_copy): Likewise. When not doing so we can replace an abnormal with something else. (may_propagate_into_stmt): Update may_propagate_copy calls. (replace_exp_1): Move propagation checking code to propagate_value and rename to ... (replace_exp): ... this and elide previous wrapper. (propagate_value): Perform checking with adjusted may_propagate_copy call and dispatch to replace_exp. * gcc.dg/torture/pr103596.c: New testcase. (cherry picked from commit 6e8a31275fda445fb3e8d98e53f5e1541f4727af)
[Bug tree-optimization/103489] [11 Regression] ICE with -O3 in operator[], at vec.h:889 since r12-5394-g0fc859f5efcb4624
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103489 --- Comment #9 from CVS Commits --- The releases/gcc-11 branch has been updated by Richard Biener : https://gcc.gnu.org/g:2c7d8ca8317981c2eb21eb1e85e0f55d3f71aff1 commit r11-9523-g2c7d8ca8317981c2eb21eb1e85e0f55d3f71aff1 Author: Richard Biener Date: Tue Nov 30 14:08:19 2021 +0100 tree-optimization/103489 - fix ICE when bool pattern recog fails bool pattern recog currently does not handle cycles correctly and when it fails we can ICE later vectorizing PHIs with mismatched bool and non-bool vector types. The following avoids blindly trusting bool pattern recog here and verifies things more thoroughly in vectorizable_phi. A bool pattern recog fix is for GCC 13. 2021-11-30 Richard Biener PR tree-optimization/103489 * tree-vect-loop.c (vectorizable_phi): Verify argument vector type compatibility to mitigate bool pattern recog bug. * gcc.dg/torture/pr103489.c: New testcase. (cherry picked from commit 0194d92c35ca8b3aa850b805d9becb4491cf6bec)
[Bug tree-optimization/104269] New: Bogus -Wuse-after-free seen in xen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104269
Bug ID: 104269
Summary: Bogus -Wuse-after-free seen in xen
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: msebor at gcc dot gnu.org
Target Milestone: ---
Reduced from xen package:
$ cat core.c
#include
typedef struct xenhypfs_handle xenhypfs_handle;
typedef struct
{
int a;
} dirent;
void *foo(dirent **);
dirent *xenhypfs_readdir(xenhypfs_handle *fshdl,
const char *path,
unsigned int *num_entries)
{
unsigned int n = 0, name_sz = 0;
void *buf;
dirent *ret_buf = 0;
dirent *dirent;
buf = foo();
if (!buf)
goto out;
ret_buf = malloc(n * sizeof(*ret_buf) + name_sz);
if (!ret_buf)
goto out;
out:
free(buf);
free(dirent);
return ret_buf;
}
$ gcc core.c -c -O2 -Wall -Werror=use-after-free
core.c: In function ‘xenhypfs_readdir’:
core.c:33:12: error: pointer ‘ret_buf’ used after ‘free’
[-Werror=use-after-free]
33 | return ret_buf;
|^~~
core.c:30:5: note: call to ‘free’ here
30 | free(buf);
| ^
cc1: some warnings being treated as errors
I believe the code is fine.
[Bug c++/103341] [11 Regression] ICE type of variable instantiation constrained on template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103341 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org Summary|[11/12 Regression] ICE type |[11 Regression] ICE type of |of variable instantiation |variable instantiation |constrained on template |constrained on template |parameter |parameter Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #5 from Patrick Palka --- Fixed for 12 so far.
[Bug c++/103341] [11/12 Regression] ICE type of variable instantiation constrained on template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103341 --- Comment #4 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:e272cf95ba048fde60b21aee046c9ca9c9264425 commit r12-6919-ge272cf95ba048fde60b21aee046c9ca9c9264425 Author: Patrick Palka Date: Fri Jan 28 08:18:28 2022 -0500 c++: var tmpl w/ dependent constrained auto type [PR103341] When deducing the type of a variable template (or templated static data member) with a constrained auto type, we might need its template arguments for satisfaction since the constraint could depend on them. PR c++/103341 gcc/cp/ChangeLog: * decl.cc (cp_finish_decl): Pass the template arguments of a variable template specialization or a templated static data member to do_auto_deduction when the auto is constrained. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/concepts-class4.C: New test. * g++.dg/cpp2a/concepts-var-templ2.C: New test.
[Bug tree-optimization/104267] [12 Regression] ICE in vect_schedule_slp_node, at tree-vect-slp.c:7144 since r12-5613-g32ede1083fad4b68
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104267 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Richard Biener --- Fixed.
[Bug tree-optimization/104267] [12 Regression] ICE in vect_schedule_slp_node, at tree-vect-slp.c:7144 since r12-5613-g32ede1083fad4b68
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104267 --- Comment #3 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:9ec306582fd60e5b76f07eb81c9ed2415d9a3590 commit r12-6918-g9ec306582fd60e5b76f07eb81c9ed2415d9a3590 Author: Richard Biener Date: Fri Jan 28 11:32:11 2022 +0100 tree-optimization/104267 - fix external def vector type for call args The following fixes the vector type registered for external defs in call arguments when vectorizing with SLP. We assumed uniform vectype_in types here but with calls like .COND_MUL we also have mask arguments which, when invariant or external, need to have a proper mask vector type. 2022-01-28 Richard Biener PR tree-optimization/104267 * tree-vect-stmts.cc (vectorizable_call): Properly use the per-argument determined vector type for externals and invariants.
[Bug tree-optimization/104263] [10/11/12 Regression] '-fcompare-debug' failure (length) w/ -O2 -fnon-call-exceptions -fno-inline-small-functions since r10-3575-g629387a6586a7531
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104263 --- Comment #9 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:5b6f04276e3d1f20817ed37b2e26e43bd12cc0d2 commit r12-6917-g5b6f04276e3d1f20817ed37b2e26e43bd12cc0d2 Author: Richard Biener Date: Fri Jan 28 10:55:29 2022 +0100 tree-optimization/104263 - avoid retaining abnormal edges for non-call/goto stmts This removes a premature optimization from gimple_purge_dead_abnormal_call_edges which, after eliding the last setjmp (or computed goto) statement from a function and thus clearing cfun->calls_setjmp, leaves us with the abnormal edges from other calls that are elided for example via inlining or DCE. That's a CFG / IL combination that should be impossible (not addressing the fact that with cfun->calls_setjmp and cfun->has_nonlocal_label cleared we should not have any abnormal edge at all). For the testcase in the PR this means that IPA inlining will remove the abormal edges from the block after inlining the call the edge was coming from. 2022-01-28 Richard Biener PR tree-optimization/104263 * tree-cfg.cc (gimple_purge_dead_abnormal_call_edges): Purge edges also when !cfun->has_nonlocal_label and !cfun->calls_setjmp. * gcc.dg/tree-ssa/inline-13.c: New testcase.
[Bug debug/103788] [9/10/11/12 Regression] '-fcompare-debug' failure (length) w/ -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103788 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #7 from Jakub Jelinek --- Dup of the many -gstatement-frontiers -fcompare-debug issues. No idea what to do about those.
[Bug middle-end/104151] [9/10/11/12 Regression] x86: excessive code generated for 128-bit byteswap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104151
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #11 from Jakub Jelinek ---
With -O3 it regresses with
r7-2009-g8d4fc2d3d0c8f87bb3e182be1a618a511f8f9465
__uint128_t bswap(__uint128_t a) { return __builtin_bswap128 (a); }
emits the optimal code but is only in GCC 11.1 and later.
One fix for this might be to handle
_8 = BIT_FIELD_REF ;
_1 = __builtin_bswap64 (_8);
y[0] = _1;
_10 = BIT_FIELD_REF ;
_2 = __builtin_bswap64 (_10);
y[1] = _2;
_7 = MEM [(char * {ref-all})];
in bswap or store merging.
Though, current bswap infrastructure I'm afraid limits it to 64-bit size,
because it tracks the bytes in uint64_t vars and uses 8 bits to determine which
byte it is (0 value of zero, 1-8 byte index and 0xff unknown).
While that is 10 different values right now, if we handled uint128_t we'd need
18 different values times 16.
Note, even:
unsigned long long
bswap (unsigned long long a)
{
unsigned int x[2];
__builtin_memcpy (x, , 8);
unsigned int y[2];
y[0] = __builtin_bswap32 (x[1]);
y[1] = __builtin_bswap32 (x[0]);
__builtin_memcpy (, y, 8);
return a;
}
unsigned long long
bswap2 (unsigned long long a)
{
return __builtin_bswap64 (a);
}
emits better code in the latter function rather than former store-merging
isn't able to handle even that.
So we want to handle it in store-merging, we should start with handling
_8 = BIT_FIELD_REF ;
_1 = __builtin_bswap32 (_8);
_10 = (unsigned int) a_3(D);
_2 = __builtin_bswap32 (_10);
_11 = {_1, _2};
_5 = VIEW_CONVERT_EXPR(_11);
and
_8 = BIT_FIELD_REF ;
_1 = __builtin_bswap32 (_8);
y[0] = _1;
_10 = (unsigned int) a_3(D);
_2 = __builtin_bswap32 (_10);
y[1] = _2;
_7 = MEM [(char * {ref-all})];
and only once that is handled try
_8 = BIT_FIELD_REF ;
_1 = __builtin_bswap64 (_8);
_10 = (long long unsigned int) a_3(D);
_2 = __builtin_bswap64 (_10);
_11 = {_1, _2};
_5 = VIEW_CONVERT_EXPR(_11);
Doesn't look like stage4 material though.
So in the meantime perhaps some other improvements.
[Bug ipa/103830] [12 Regression] null pointer access optimized away by removing function call at -Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103830
Bernd Edlinger changed:
What|Removed |Added
Resolution|INVALID |FIXED
--- Comment #9 from Bernd Edlinger ---
(In reply to Richard Biener from comment #7)
> A fix in the source would be:
>
> void MyClass::call() {
> volatile char * volatile null = nullptr;
> *null = 1; /* line 26 */
> }
>
> which then compiles to
>
> movq$0, -8(%rsp)
> movq-8(%rsp), %rax
> movb$1, (%rax)
> ret
>
> (some "advanced" means using some asm() to hide the constant from the
> compiler might also work)
Yes, that works, but I would prefer:
*(volatile char*)1 = 2;
[Bug ipa/103830] [12 Regression] null pointer access optimized away by removing function call at -Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103830 Richard Biener changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #8 from Richard Biener --- I'd say invalid. For -Og we might want to consider not doing pure/const discovery (or modref) but stick to what the user declared so.
[Bug ipa/103830] [12 Regression] null pointer access optimized away by removing function call at -Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103830
--- Comment #7 from Richard Biener ---
A fix in the source would be:
void MyClass::call() {
volatile char * volatile null = nullptr;
*null = 1; /* line 26 */
}
which then compiles to
movq$0, -8(%rsp)
movq-8(%rsp), %rax
movb$1, (%rax)
ret
(some "advanced" means using some asm() to hide the constant from the compiler
might also work)
[Bug ipa/103830] [12 Regression] null pointer access optimized away by removing function call at -Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103830
--- Comment #6 from Richard Biener ---
To clarify myself - the testcase is invoking UB, 'volatile' doesn't make a
difference here. That we get the DSE as a second-order effect is unfortunate
at most, in other places we try to preserve volatile qualified accesses. But I
do not think it's worth to pessimize -Og for that. If you declare
MyClass::call() noinline you get the same behavior with all optimization
levels:
struct MyClass;
struct ptr {
MyClass* get() { return t; } /* line 21 */
MyClass* t;
};
struct MyClass { void __attribute__((noinline)) call(); };
void MyClass::call() {
*(volatile char*)(nullptr) = 1; /* line 26 */
}
static void intermediate(ptr p) {
p.get()->call(); /* line 29 */
}
int main() {
intermediate(ptr{new MyClass});
}
so iff then we need to argue about the modref/ipa-pure-const behavior, not
about DCE of calls at -Og.
[Bug target/104172] [9/10 Regression] ppc64le mangling ICE with -flto -ffat-lto-objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104172 Jakub Jelinek changed: What|Removed |Added Summary|[9/10/11/12 Regression] |[9/10 Regression] ppc64le |ppc64le mangling ICE with |mangling ICE with -flto |-flto -ffat-lto-objects |-ffat-lto-objects Target Milestone|9.5 |11.3 Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #17 from Jakub Jelinek --- Fixed for 11.3/trunk, not going to backport further.
[Bug c++/104142] [9/10/11/12 Regression] Spurios warning unused-variable on const static variable and defaulted constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104142
Jakub Jelinek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org,
||ppalka at gcc dot gnu.org
--- Comment #4 from Jakub Jelinek ---
If we want the same warning, we'd need to probably special case const vars with
defaulted default ctors and empty classes, if it isn't empty class, both of
these are rejected already:
pr104142.C:2:16: error: uninitialized ‘const a’ [-fpermissive]
2 | static const A a;
|^
pr104142.C:1:8: note: ‘const struct A’ has no user-provided default constructor
1 | struct A { int a; };
|^
pr104142.C:1:16: note: and the implicitly-defined constructor does not
initialize ‘int A::a’
1 | struct A { int a; };
|^
pr104142.C:5:16: error: uninitialized ‘const b’ [-fpermissive]
5 | static const B b;
|^
pr104142.C:4:8: note: ‘const struct B’ has no user-provided default constructor
4 | struct B { B()=default; int b; };
|^
pr104142.C:4:12: note: constructor is not user-provided because it is
explicitly defaulted in the class body
4 | struct B { B()=default; int b; };
|^
pr104142.C:4:29: note: and the implicitly-defined constructor does not
initialize ‘int B::b’
4 | struct B { B()=default; int b; };
| ^
[Bug c++/103790] internal compiler error: Segmentation fault when playing with coroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103790 --- Comment #7 from CVS Commits --- The master branch has been updated by Andre Vehreschild : https://gcc.gnu.org/g:26e237fb5b83582b30ef7c5a388bc4e968a5a289 commit r12-6915-g26e237fb5b83582b30ef7c5a388bc4e968a5a289 Author: Andre Vehreschild Date: Fri Jan 28 12:34:17 2022 +0100 Prevent malicious descriptor stacking for scalar components [V2]. gcc/fortran/ChangeLog: PR fortran/103790 * trans-array.cc (structure_alloc_comps): Prevent descriptor stacking for non-array data; do not broadcast caf-tokens. * trans-intrinsic.cc (conv_co_collective): Prevent generation of unused descriptor. gcc/testsuite/ChangeLog: PR fortran/103790 * gfortran.dg/coarray_collectives_18.f90: New test.
[Bug c++/104142] [9/10/11/12 Regression] Spurios warning unused-variable on const static variable and defaulted constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104142 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- It isn't clear what exactly is the regression. We warn on b with -Wunused-variable since r9-412-gb46b715d5b838d9869f89d3594ebf7d0b7cb374c A and B aren't the same, one has explicit defaulted ctor, the other has implicit ctor. -Wunused-const-variable warns about a and not b since its introduction in r6-3283-g0f876f22887f239cedca64ff170b71e5f1daaf54
