[Bug tree-optimization/100076] eembc/automotive/basefp01 has 30.3% regression compare -O2 -ftree-vectorize with -O2 on CLX/Znver3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100076 --- Comment #2 from Hongtao.liu --- (In reply to H.J. Lu from comment #1) > Is -O3 slower than -O3 -fno-tree-vectorize? If not, why? For this case O3 is Ok, because O3 will enable pass_cunroll to complete unroll the loop1/loop2/loop3, and later pass_fre will elimiate redudant load of polyX1 in loop2 and loop3 for both -O3 and -O3 -fno-tree-vectorize.
[Bug c++/99478] [9/10 Regression] ICE when decltype lambda in template list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99478 Jason Merrill changed: What|Removed |Added Summary|[9/10/11 Regression] ICE|[9/10 Regression] ICE when |when decltype lambda in |decltype lambda in template |template list |list --- Comment #3 from Jason Merrill --- Fixed for 11 so far.
[Bug c++/99478] [9/10/11 Regression] ICE when decltype lambda in template list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99478 --- Comment #2 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:e1666ebd9ad31dbd8b9b933c883bdd882cfd1522 commit r11-8166-ge1666ebd9ad31dbd8b9b933c883bdd882cfd1522 Author: Jason Merrill Date: Tue Apr 13 22:28:32 2021 -0400 c++: lambda in non-type template parm type [PR99478] In this testcase, the non-type template parameter has the type of a lambda-expression. This makes no sense because a lambda in template context is specified to be distinct between different specializations of the template, even if the lambda is non-dependent, but here which specialization we are dealing with depends on which lambda we have, and vice versa. gcc/cp/ChangeLog: PR c++/99478 * parser.c (cp_parser_lambda_expression): Reject lambda in template parameter type. gcc/testsuite/ChangeLog: PR c++/99478 * g++.dg/cpp2a/lambda-uneval14.C: New test.
[Bug tree-optimization/100076] eembc/automotive/basefp01 has 30.3% regression compare -O2 -ftree-vectorize with -O2 on CLX/Znver3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100076 --- Comment #1 from H.J. Lu --- Is -O3 slower than -O3 -fno-tree-vectorize? If not, why?
[Bug tree-optimization/100076] New: eembc/automotive/basefp01 has 30.3% regression compare -O2 -ftree-vectorize with -O2 on SKX/CLX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100076
Bug ID: 100076
Summary: eembc/automotive/basefp01 has 30.3% regression compare
-O2 -ftree-vectorize with -O2 on SKX/CLX
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: crazylht at gmail dot com
CC: hjl.tools at gmail dot com
Target Milestone: ---
Refer to https://godbolt.org/z/e3nfz3xvW
cat testcase.c
int
t_run_test(double a)
{
static double P1, Q1;
static varsize polyX1[9];
polyX1[1] = a;
P1 = (varsize)constantP[0];
polyX1[1] = a;
// Loop 1
for( int i1 = 2 ; i1 <= 8 ; i1++ )
{
polyX1[i1] = polyX1[i1 - 1] * polyX1[1] ;
}
P1 = (varsize)constantP[0] ;
// Loop 2
for( int i1 = 1 ; i1 <= 8 ; i1++ )
{
P1 += (varsize)constantP[i1] * polyX1[i1] ;
}
Q1 = (varsize)constantQ[0] ;
// Loop 3
for( int i1 = 1 ; i1 <= 8 ; i1++ )
{
Q1 += (varsize)constantQ[i1] * polyX1[i1] ;
}
return a = a * P1 / Q1 ;
}
Loop 1 write array polyX1 which is used by Loop2 and Loop 3, with
-ftree-vectorize -O2, Loop2 and Loop 3 are vectorized, but Loop 1 is not since
it have inter-iterative dependence, then for array polyX1, there're 64-bit
stores in loop 1 and 128-bit load in Loop2 and Loop 3, and it causes store
forwarding stalls which hurt performance.
[Bug c++/99478] [9/10/11 Regression] ICE when decltype lambda in template list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99478 Jason Merrill changed: What|Removed |Added CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug fortran/63797] Bogus ambiguous reference to 'sqrt'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63797
--- Comment #5 from Steve Kargl ---
On Tue, Apr 13, 2021 at 08:49:35PM +, anlauf at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63797
>
> --- Comment #4 from anlauf at gcc dot gnu.org ---
> The following patch regtests ok and fixes the testcase:
>
> diff --git a/gcc/fortran/module.c b/gcc/fortran/module.c
> index 4db0a3ac76d..b4b7b437f86 100644
> --- a/gcc/fortran/module.c
> +++ b/gcc/fortran/module.c
> @@ -6218,6 +6218,9 @@ write_symtree (gfc_symtree *st)
>if (check_unique_name (st->name))
> return;
>
> + if (strcmp (sym->module, "(intrinsic)") == 0)
> +return;
> +
>p = find_pointer (sym);
>if (p == NULL)
> gfc_internal_error ("write_symtree(): Symbol not written");
>
>
> It even fixes the slightly reduced & refined testcase:
>
Harald, if this survives regression testing, it might be
appropriate to commit. The only issue I can think of
is procedure pointers. I don't use them, but if one can
point at sqrt (or dsqrt, i.e., with specific vs generic
name), then is [d]sqrt needed to be written into the module?
[Bug debug/90674] [8/9/10 Regression] ICE in gen_subprogram_die
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90674 Jason Merrill changed: What|Removed |Added Known to work||11.0 Summary|[8/9/10/11 Regression] ICE |[8/9/10 Regression] ICE in |in gen_subprogram_die |gen_subprogram_die --- Comment #6 from Jason Merrill --- Fixed for 11 so far.
[Bug debug/90674] [8/9/10/11 Regression] ICE in gen_subprogram_die
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90674 --- Comment #5 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:0589be0c59767cf4cbb0ef0e7d918cf6aa3d606c commit r11-8165-g0589be0c59767cf4cbb0ef0e7d918cf6aa3d606c Author: Jason Merrill Date: Tue Apr 13 20:32:13 2021 -0400 c++: DWARF ICE with defaulted specialization [PR90674] Here when we merged the specialization with the implicit instantiation declaration, we wrongly kept the value of DECL_INITIALIZED_IN_CLASS_P from the latter. gcc/cp/ChangeLog: PR c++/90674 * decl.c (duplicate_decls): Don't propagate DECL_INITIALIZED_IN_CLASS_P to a specialization. gcc/testsuite/ChangeLog: PR c++/90674 * g++.dg/debug/defaulted1.C: New test.
[Bug libgcc/100074] build fails for libgcc with --without-headers and --with-newlib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100074 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #3 from Marek Polacek --- Can you please resist your natural inclination to open a gcc bug any time you see an error?
[Bug rtl-optimization/92342] [10/11 Regression] a small missed transformation into x?b:0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92342 Andrew Pinski changed: What|Removed |Added CC||luc.vanoostenryck at gmail dot com --- Comment #21 from Andrew Pinski --- *** Bug 100072 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/100072] [10/11 Regression] csel vs. csetm + and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100072 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |10.4 CC||pinskia at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED Component|target |tree-optimization Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- This is an exact dup of bug 92342. *** This bug has been marked as a duplicate of bug 92342 ***
[Bug debug/93951] [8/9/10/11 Regression] ICE with '-flto -g -femit-struct-debug-baseonly'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93951 Jason Merrill changed: What|Removed |Added Status|NEW |WAITING --- Comment #11 from Jason Merrill --- I can't reproduce this. Can anyone else?
[Bug libgcc/100074] build fails for libgcc with --without-headers and --with-newlib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100074 cqwrteur changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #2 from cqwrteur --- not a bug
[Bug c++/100032] [8/9/10 Regression] renaming alias template that also adds cv-qualifiers is deemed equivalent to underlying template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100032 Jason Merrill changed: What|Removed |Added Summary|[8/9/10/11 Regression] |[8/9/10 Regression] |renaming alias template |renaming alias template |that also adds |that also adds |cv-qualifiers is deemed |cv-qualifiers is deemed |equivalent to underlying|equivalent to underlying |template|template Known to work||11.0 --- Comment #4 from Jason Merrill --- Fixed for GCC 11 so far.
[Bug debug/90674] [8/9/10/11 Regression] ICE in gen_subprogram_die
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90674 Jason Merrill changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Status|NEW |ASSIGNED CC||jason at gcc dot gnu.org
[Bug debug/88742] [8/9/10 Regression] Debugger jumps back when stepping over class destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88742 Jason Merrill changed: What|Removed |Added Summary|[8/9/10/11 Regression] |[8/9/10 Regression] |Debugger jumps back when|Debugger jumps back when |stepping over class |stepping over class |destructor |destructor Known to work||11.0 --- Comment #5 from Jason Merrill --- Fixed for GCC 11 so far.
[Bug debug/49951] [4.5/4.6/4.7 Regression] Debug stepping behavior regarding g++ Class destructor has changed for the worse starting at gcc 4.5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49951 --- Comment #22 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:006783f4b165dff25aae3697920fcf547544 commit r11-8164-g006783f4b165dff25aae3697920fcf547544 Author: Jason Merrill Date: Tue Apr 13 16:18:54 2021 -0400 c++: debug location of variable cleanups [PR88742] PR49951 complained about the debugger jumping back to the declaration of a local variable when we run its destructor. That was fixed in 4.7, but broke again in 4.8. PR58123 fixed an inconsistency in the behavior, but not the jumping around. This patch addresses the issue by setting EXPR_LOCATION on a cleanup destructor call to the location of the closing brace of the compound-statement, or whatever token ends the scope of the variable. The change to cp_parser_compound_statement is so input_location is the } rather than the ; of the last substatement. gcc/cp/ChangeLog: PR c++/88742 PR c++/49951 PR c++/58123 * semantics.c (set_cleanup_locs): New. (do_poplevel): Call it. * parser.c (cp_parser_compound_statement): Consume the } before finish_compound_stmt. gcc/testsuite/ChangeLog: PR c++/88742 * g++.dg/debug/cleanup1.C: New test. * c-c++-common/Wimplicit-fallthrough-6.c: Adjust diagnostic line. * c-c++-common/Wimplicit-fallthrough-7.c: Likewise. * g++.dg/cpp2a/constexpr-dtor3.C: Likewise. * g++.dg/ext/constexpr-attr-cleanup1.C: Likewise. * g++.dg/tm/inherit2.C: Likewise. * g++.dg/tm/unsafe1.C: Likewise. * g++.dg/warn/Wimplicit-fallthrough-1.C: Likewise. * g++.dg/gcov/gcov-2.C: Adjust coverage counts.
[Bug debug/58123] [4.8/4.9/5 Regression] debug line not tracked for last autovariable dtor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58123 --- Comment #13 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:006783f4b165dff25aae3697920fcf547544 commit r11-8164-g006783f4b165dff25aae3697920fcf547544 Author: Jason Merrill Date: Tue Apr 13 16:18:54 2021 -0400 c++: debug location of variable cleanups [PR88742] PR49951 complained about the debugger jumping back to the declaration of a local variable when we run its destructor. That was fixed in 4.7, but broke again in 4.8. PR58123 fixed an inconsistency in the behavior, but not the jumping around. This patch addresses the issue by setting EXPR_LOCATION on a cleanup destructor call to the location of the closing brace of the compound-statement, or whatever token ends the scope of the variable. The change to cp_parser_compound_statement is so input_location is the } rather than the ; of the last substatement. gcc/cp/ChangeLog: PR c++/88742 PR c++/49951 PR c++/58123 * semantics.c (set_cleanup_locs): New. (do_poplevel): Call it. * parser.c (cp_parser_compound_statement): Consume the } before finish_compound_stmt. gcc/testsuite/ChangeLog: PR c++/88742 * g++.dg/debug/cleanup1.C: New test. * c-c++-common/Wimplicit-fallthrough-6.c: Adjust diagnostic line. * c-c++-common/Wimplicit-fallthrough-7.c: Likewise. * g++.dg/cpp2a/constexpr-dtor3.C: Likewise. * g++.dg/ext/constexpr-attr-cleanup1.C: Likewise. * g++.dg/tm/inherit2.C: Likewise. * g++.dg/tm/unsafe1.C: Likewise. * g++.dg/warn/Wimplicit-fallthrough-1.C: Likewise. * g++.dg/gcov/gcov-2.C: Adjust coverage counts.
[Bug debug/88742] [8/9/10/11 Regression] Debugger jumps back when stepping over class destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88742 --- Comment #4 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:006783f4b165dff25aae3697920fcf547544 commit r11-8164-g006783f4b165dff25aae3697920fcf547544 Author: Jason Merrill Date: Tue Apr 13 16:18:54 2021 -0400 c++: debug location of variable cleanups [PR88742] PR49951 complained about the debugger jumping back to the declaration of a local variable when we run its destructor. That was fixed in 4.7, but broke again in 4.8. PR58123 fixed an inconsistency in the behavior, but not the jumping around. This patch addresses the issue by setting EXPR_LOCATION on a cleanup destructor call to the location of the closing brace of the compound-statement, or whatever token ends the scope of the variable. The change to cp_parser_compound_statement is so input_location is the } rather than the ; of the last substatement. gcc/cp/ChangeLog: PR c++/88742 PR c++/49951 PR c++/58123 * semantics.c (set_cleanup_locs): New. (do_poplevel): Call it. * parser.c (cp_parser_compound_statement): Consume the } before finish_compound_stmt. gcc/testsuite/ChangeLog: PR c++/88742 * g++.dg/debug/cleanup1.C: New test. * c-c++-common/Wimplicit-fallthrough-6.c: Adjust diagnostic line. * c-c++-common/Wimplicit-fallthrough-7.c: Likewise. * g++.dg/cpp2a/constexpr-dtor3.C: Likewise. * g++.dg/ext/constexpr-attr-cleanup1.C: Likewise. * g++.dg/tm/inherit2.C: Likewise. * g++.dg/tm/unsafe1.C: Likewise. * g++.dg/warn/Wimplicit-fallthrough-1.C: Likewise. * g++.dg/gcov/gcov-2.C: Adjust coverage counts.
[Bug libgcc/100074] build fails for libgcc with --without-headers and --with-newlib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100074 --- Comment #1 from cqwrteur --- Created attachment 50589 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50589=edit config.log
[Bug target/100075] New: [9/10/11 Regression] unneeded sign extension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100075
Bug ID: 100075
Summary: [9/10/11 Regression] unneeded sign extension
Product: gcc
Version: 10.3.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: luc.vanoostenryck at gmail dot com
Target Milestone: ---
Target: aarch64
Created attachment 50588
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50588=edit
test case
Until gcc8, the following code:
struct s {
short x, y;
};
struct s rot(struct s p)
{
return (struct s) { -p.y, p.x };
}
was translated:
rot90:
neg w1, w0, asr 16
and w1, w1, 65535
orr w0, w1, w0, lsl 16
ret
but since gcc9 it translates less nicely, with an unneeded sign extension:
rot90:
mov w1, w0
sbfxx0, x1, 16, 16
neg w0, w0
bfi w0, w1, 16, 16
ret
See with another variant in attachment or https://gcc.godbolt.org/z/1oW1cEMGc
[Bug libgcc/100074] New: build fails for libgcc with --without-headers and --with-newlib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100074 Bug ID: 100074 Summary: build fails for libgcc with --without-headers and --with-newlib Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: unlvsur at live dot com Target Milestone: --- cannot compute suffix of object files: cannot compile ../../gcc/configure --disable-nls --disable-bootstrap --disable-hosted-libstdcxx --disable-werror --with-newlib --target=x86_64-elf --prefix=$PREFIX --without-headers --disable-libstdcxx-verbose --enable-languages=c,c++ --disable-libquadmath --disable-libssp --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 --target=x86_64-elf --with-newlib --disable-shared checking for x86_64-elf-gcc... /home/unlvs/gcc_elf_freestanding/gcc/./gcc/xgcc -B/home/unlvs/gcc_elf_freestanding/gcc/./gcc/ -B/d/cross_toolchains/x86_64-elf/x86_64-elf/bin/ -B/d/cross_toolchains/x86_64-elf/x86_64-elf/lib/ -isystem /d/cross_toolchains/x86_64-elf/x86_64-elf/include -isystem /d/cross_toolchains/x86_64-elf/x86_64-elf/sys-include checking for suffix of object files... configure: error: in `/home/unlvs/gcc_elf_freestanding/gcc/x86_64-elf/libgcc': configure: error: cannot compute suffix of object files: cannot compile See `config.log' for more details make[1]: *** [Makefile:14336: configure-target-libgcc] Error 1 make[1]: Leaving directory '/home/unlvs/gcc_elf_freestanding/gcc' make: *** [Makefile:979: all] Error 2
[Bug middle-end/80548] -Wmaybe-uninitialized false positive when an assignment is added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80548
Martin Sebor changed:
What|Removed |Added
Blocks||24639
Last reconfirmed|2017-04-28 00:00:00 |2021-4-13
CC||msebor at gcc dot gnu.org
Known to fail||11.0
--- Comment #2 from Martin Sebor ---
Reconfirmed with GCC 11 and the IL below annotated with my comments. I don't
see anything in the IL to rule out the uninitialized use:
void f (int b)
{
int y;
int x;
int _1;
[local count: 59055799]:
if (b_5(D) != 0)
goto ; [33.00%]
else
goto ; [67.00%] >>> b == 0
[local count: 19488414]:
# .MEM_9 = VDEF <.MEM_8(D)>
x_10 = g ();
# .MEM_11 = VDEF <.MEM_9>
y_12 = g ();
goto ; [100.00%]>>> b != 0
[local count: 1014686025]:
if (b_5(D) != 0)
goto ; [5.50%]
else
goto ; [94.50%]
[local count: 958878294]:
goto ; [100.00%]
[local count: 55807731]: <<< x_17 used when g() != 0 AND b != 0
# .MEM_14 = VDEF <.MEM_13>
h (x_17, y_2);<<< warning for x_17
# .MEM_15 = VDEF <.MEM_14>
y_16 = g ();
goto ; [100.00%]
[local count: 39567385]: <<< b == 0
[local count: 59055799]: <<< x_6(D) uninitialized when b != 0 OR
b == 0
# x_17 = PHI <<< x_17 <-- x_6(D)(11)
# y_18 = PHI
# .MEM_19 = PHI <.MEM_11(3), .MEM_8(D)(11)>
[local count: 114863530]:
# y_2 = PHI
# .MEM_20 = PHI <.MEM_19(6), .MEM_15(5)>
[local count: 1073741824]:
# .MEM_4 = PHI <.MEM_20(7), .MEM_13(10)>
# .MEM_13 = VDEF <.MEM_4>
_1 = g ();
if (_1 != 0)
goto ; [94.50%] >>> g() != 0
else
goto ; [5.50%]
[local count: 59055800]:
# VUSE <.MEM_13>
return;
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
[Bug 24639] [meta-bug] bug to track all Wuninitialized issues
[Bug tree-optimization/100053] [9/10 Regression] tree-fre incorrectly delete a condition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100053 --- Comment #11 from qinzhao at gcc dot gnu.org --- (In reply to Richard Biener from comment #4) > Created attachment 50579 [details] > fix for the issue > > I am testing this patch - maybe you can test it on the original testcase you > cannot disclose. > I tested this patch with the original test case, and it resolved the runtime error. thanks.
[Bug testsuite/100073] New: [11 regression] test case gcc.dg/pr86058.c fails after r11-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100073 Bug ID: 100073 Summary: [11 regression] test case gcc.dg/pr86058.c fails after r11- Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:8084ab15a3e300e3b2c537e56e0f3a1b00778aec, r11-8161 make -k check-gcc RUNTESTFLAGS="dg.exp=gcc.dg/pr86058.c" FAIL: gcc.dg/pr86058.c actual (test for warnings, line 13) # of expected passes1 # of unexpected failures1 spawn /home/seurer/gcc/git/build/gcc-test/gcc/xgcc -B/home/seurer/gcc/git/build/gcc-test/gcc/ /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/pr86058.c -fdiagnostics-plain-output -O2 -Wuninitialized -Wmaybe-uninitialized -S -o pr86058.s XFAIL: gcc.dg/pr86058.c pr? (test for warnings, line 13) FAIL: gcc.dg/pr86058.c actual (test for warnings, line 13) I don't see any excess warnings so maybe it is a missing warning?
[Bug target/100072] New: [10/11 Regression] csel vs. csetm + and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100072
Bug ID: 100072
Summary: [10/11 Regression] csel vs. csetm + and
Product: gcc
Version: 10.3.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: luc.vanoostenryck at gmail dot com
Target Milestone: ---
Target: aarch64
Created attachment 50587
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50587=edit
testcase
The following code:
int sel_andn(int p, int a) { return (p ? ~0 : 0) & a; }
int sel_andr(int p, int a) { return (p ? 0 : ~0) & a; }
translated to the following with GCC9 and before:
sel_andn:
cmp w0, 0
cselw0, w1, wzr, ne
ret
sel_andr:
cmp w0, 0
cselw0, w1, wzr, eq
ret
but since version 10 it translates into:
sel_andn:
cmp w0, 0
csetm w0, ne
and w0, w0, w1
ret
sel_andr:
cmp w0, 0
csetm w0, eq
and w0, w0, w1
ret
Same at https://gcc.godbolt.org/z/16fj1EYhx
[Bug libstdc++/99402] [10 Regression] std::copy creates _GLIBCXX_DEBUG false positive for attempt to subscript a dereferenceable (start-of-sequence) iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99402 --- Comment #12 from Jonathan Wakely --- François fixed it. I just pasted the info here that didn't get automatically added by the commit hooks, for some reason.
[Bug libstdc++/99402] [10 Regression] std::copy creates _GLIBCXX_DEBUG false positive for attempt to subscript a dereferenceable (start-of-sequence) iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99402 --- Comment #11 from Kip Warner --- Thanks Jonathan. That was a constructive follow up.
[Bug libstdc++/100070] Standard library container iterator-pair constructors should check C++20 iterator concepts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100070 --- Comment #3 from Jonathan Wakely --- So I think there is a *lot* work needed throughout the library to solve the general problem that the existing container code uses C++17 iterator categories and C++17 std::algos (not ranges::algos). We might be better off just waiting for a vector(range&&) constructor.
[Bug libstdc++/100070] Standard library container iterator-pair constructors should check C++20 iterator concepts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100070
--- Comment #2 from Jonathan Wakely ---
This is a partial solution:
--- a/libstdc++-v3/include/bits/stl_vector.h
+++ b/libstdc++-v3/include/bits/stl_vector.h
@@ -654,6 +654,19 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
const allocator_type& __a = allocator_type())
: _Base(__a)
{
+#if __cpp_lib_concepts
+ if constexpr (forward_iterator<_InputIterator>)
+ {
+ size_type __n;
+ if constexpr (random_access_iterator<_InputIterator>)
+ __n = __last - __first;
+ else
+ __n = std::distance(__first, __last);
+ _M_range_initialize_n(__first, __last, __n);
+ return;
+ }
+ else
+#endif
_M_range_initialize(__first, __last,
std::__iterator_category(__first));
}
@@ -1577,7 +1590,15 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
_M_range_initialize(_ForwardIterator __first, _ForwardIterator __last,
std::forward_iterator_tag)
{
- const size_type __n = std::distance(__first, __last);
+ _M_range_initialize_n(__first, __last,
+ std::distance(__first, __last));
+ }
+
+ template
+ void
+ _M_range_initialize_n(_InputIterator __first, _InputIterator __last,
+ size_type __n)
+ {
this->_M_impl._M_start
= this->_M_allocate(_S_check_init_len(__n, _M_get_Tp_allocator()));
this->_M_impl._M_end_of_storage = this->_M_impl._M_start + __n;
This doubles the speed of the vector construction, but it's still slow because
it uses std::copy to copy the range elements into the vector, and std::copy
also dispatches on the iterator_category.
[Bug testsuite/100071] New: Test case libgomp.fortran/alloc-2.F90 fails with invalid memory reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100071
Bug ID: 100071
Summary: Test case libgomp.fortran/alloc-2.F90 fails with
invalid memory reference
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: seurer at gcc dot gnu.org
Target Milestone: ---
g:fff15bad1ab571906c37b88380431768d917dcb0, r11-2101
The commit above is where this test case was introduced and it fails both there
and with current trunk. The following runs were on a power 8 BE machine. I
did not see failures on LE.
This is kind of odd. If I run the test case like this the 64 bit run fails:
make -k check-target-libgomp RUNTESTFLAGS="--target_board=unix'{-m32,-m64}'
fortran.exp=libgomp.fortran/alloc-2.F90"
=== libgomp tests ===
Running target unix/-m32
=== libgomp Summary for unix/-m32 ===
# of expected passes2
Running target unix/-m64
FAIL: libgomp.fortran/alloc-2.F90 -O execution test
=== libgomp Summary for unix/-m64 ===
# of expected passes1
# of unexpected failures1
=== libgomp Summary ===
# of expected passes3
# of unexpected failures1
The error is:
Program received signal SIGSEGV: Segmentation fault - invalid memory reference.
Backtrace for this error:
#0 0x3fffb7f80477 in ???
#1 0x3fffb799af24 in __GI___libc_free
at /usr/src/debug/glibc-2.17-c758a686/malloc/malloc.c:2941
#2 0x3fffb7b9940f in omp_free
at /home/seurer/gcc/git/gcc-test2/libgomp/allocator.c:391
#3 0x100015bb in ???
#4 0x10001793 in ???
#5 0x3fffb7927ceb in generic_start_main
at ../csu/libc-start.c:266
FAIL: libgomp.fortran/alloc-2.F90 -O execution test
If I run just the 32 or the 64 bit ones individually they work:
make -k check-target-libgomp RUNTESTFLAGS="--target_board=unix'{-m32}'
fortran.exp=libgomp.fortran/alloc-2.F90"
=== libgomp tests ===
Running target unix/-m32
=== libgomp Summary ===
# of expected passes2
make -k check-target-libgomp RUNTESTFLAGS="--target_board=unix'{-m64}'
fortran.exp=libgomp.fortran/alloc-2.F90"
=== libgomp tests ===
Running target unix/-m64
=== libgomp Summary ===
# of expected passes2
If I run the 64 bit one before the 32 bit one they both work. If I do the 64
bit one twice the second run fails. If I do the 32 bit one twice they both
work.
So, it looks like something is not being cleaned up between the runs that
causes the second run to fail if it is a 64 bit run.
[Bug libstdc++/100070] Standard library container iterator-pair constructors should check C++20 iterator concepts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100070 --- Comment #1 from Jonathan Wakely --- We want to do the same thing in insert and assign too. And in std::deque.
[Bug c/100068] inconsistent handling of noreturn on nested function declarations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100068 --- Comment #4 from Martin Sebor --- The latter: in f1() warn for the redeclaration of g1() in the nested scope. That's where GCC and other compilers differ.
[Bug libstdc++/100070] Standard library container iterator-pair constructors should check C++20 iterator concepts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100070 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Component|c++ |libstdc++ Last reconfirmed||2021-04-13
[Bug c++/100070] New: Standard library container iterator-pair constructors should check C++20 iterator concepts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100070 Bug ID: 100070 Summary: Standard library container iterator-pair constructors should check C++20 iterator concepts Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: barry.revzin at gmail dot com Target Milestone: --- >From StackOverflow (https://stackoverflow.com/q/67081354/2069064), a user was benchmarking code that did this: int convert(int); std::vector foo(100,42); auto transform_range = foo | std::ranges::views::transform(convert); std::vector fooTimesTwo(transform_range.begin(), transform_range.end()); And found it to be much slower than their initial implementation that did not use ranges. This is because while transform_range is a C++20 random access range, it is only a C++17 input range. libstdc++'s decision is based entirely on iterator_category (https://github.com/gcc-mirror/gcc/blob/8084ab15a3e300e3b2c537e56e0f3a1b00778aec/libstdc%2B%2B-v3/include/bits/stl_vector.h#L652-L659) which does the best you can with an input range: just loop and emplace. But if it instead checked for forward_iterator and random_access_iterator (the concept), this construction case could be handled efficiently (i.e. as a single allocation). I think that should safe? Checking for random_access_iterator checks the tag before checking for the validity of operator-?
[Bug middle-end/90043] Turn on -Winit-self by default for -Wuninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90043 --- Comment #4 from Andrew Pinski --- I remember when I added -Winit-self, it was specifically because that was the original documented way of disabling uninitialized variables. I don't remember if I came up with the option name or it was changed. It was a long time back in the 4.0 days even.
[Bug tree-optimization/82090] Bogus warning: ‘magic_p’ may be used uninitialized in this function [-Wmaybe-uninitialized]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82090 Martin Sebor changed: What|Removed |Added Known to fail||10.2.0, 11.0, 7.3.0, 8.3.0, ||9.2.0 Last reconfirmed|2017-09-04 00:00:00 |2021-4-13 Blocks||24639 CC||msebor at gcc dot gnu.org --- Comment #2 from Martin Sebor --- Reconfirmed with GCC 11. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 [Bug 24639] [meta-bug] bug to track all Wuninitialized issues
[Bug c++/100069] function redeclaration with noreturn not rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100069 --- Comment #1 from Andrew Pinski --- The C++ front-end has many issues with global declarations inside a local scope. PR 81609 is another one. PR 32042 is another.
[Bug c++/82800] Incorrect warning on "may be used uninitialized in this function" in variadic template code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82800 --- Comment #2 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:af7128621e54f04b90589bb0c3e1ef271c239265 commit r11-8162-gaf7128621e54f04b90589bb0c3e1ef271c239265 Author: Martin Sebor Date: Tue Apr 13 14:53:26 2021 -0600 PR tree-optimization/82800 - Incorrect warning on "may be used uninitialized in variadic template code gcc/testsuite/ChangeLog: PR tree-optimization/82800 * g++.dg/warn/uninit-pr82800.C: New test.
[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 Bug 24639 depends on bug 82800, which changed state. Bug 82800 Summary: Incorrect warning on "may be used uninitialized in this function" in variadic template code https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82800 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug c++/82800] Incorrect warning on "may be used uninitialized in this function" in variadic template code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82800 Martin Sebor changed: What|Removed |Added Blocks||24639 CC||msebor at gcc dot gnu.org Resolution|--- |FIXED Target Milestone|--- |7.4 Status|UNCONFIRMED |RESOLVED --- Comment #1 from Martin Sebor --- I cannot reproduce the warning anymore. It disappeared in GCC 7.3 or 7.4. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 [Bug 24639] [meta-bug] bug to track all Wuninitialized issues
[Bug libstdc++/99402] [10 Regression] std::copy creates _GLIBCXX_DEBUG false positive for attempt to subscript a dereferenceable (start-of-sequence) iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99402 Jonathan Wakely changed: What|Removed |Added Summary|[10/11 Regression] |[10 Regression] std::copy |std::copy creates |creates _GLIBCXX_DEBUG |_GLIBCXX_DEBUG false|false positive for attempt |positive for attempt to |to subscript a |subscript a dereferenceable |dereferenceable |(start-of-sequence) |(start-of-sequence) |iterator|iterator --- Comment #10 from Jonathan Wakely --- This was fixed on trunk by r11-8100: libstdc++: [_GLIBCXX_DEBUG] Fix management of __dp_sign_max_size [PR 99402] __dp_sign precision indicates that we found out what iterator comes first or last in the range. __dp_sign_max_size is the same plus it gives the information of the max size of the range that is to say the max_size value such that distance(lhs, rhs) < max_size. Thanks to this additional information we are able to tell when a copy of n elements to that range will fail even if we do not know exactly how large it is. This patch makes sure that we are properly using this information. libstdc++-v3/ChangeLog: PR libstdc++/99402 * include/debug/helper_functions.h (__can_advance(_InputIterator, const std::pair<_Diff, _Distance_precision>&, int)): New. (__can_advance(const _Safe_iterator<>&, const std::pair<_Diff, _Distance_precision>&, int)): New. * include/debug/macros.h (__glibcxx_check_can_increment_dist): New, use latter. (__glibcxx_check_can_increment_range): Adapt to use latter. (__glibcxx_check_can_decrement_range): Likewise. * include/debug/safe_iterator.h (_Safe_iterator<>::_M_can_advance(const std::pair<_Diff, _Distance_precision>&, int)): New. (__can_advance(const _Safe_iterator<>&, const std::pair<_Diff, _Distance_precision>&, int)): New. * include/debug/safe_iterator.tcc (_Safe_iterator<>::_M_can_advance(const std::pair<_Diff, _Distance_precision>&, int)): New. (_Safe_iterator<>::_M_valid_range(const _Safe_iterator<>&, std::pair&, bool)): Adapt for __dp_sign_max_size. (__copy_move_a): Adapt to use __glibcxx_check_can_increment_dist. (__copy_move_backward_a): Likewise. (__equal_aux): Likewise. * include/debug/stl_iterator.h (__can_advance(const std::reverse_iterator<>&, const std::pair<_Diff, _Distance_precision>&, int)): New. (__can_advance(const std::move_iterator<>&, const std::pair<_Diff, _Distance_precision>&, int)): New. * testsuite/25_algorithms/copy/debug/99402.cc: New test.
[Bug fortran/63797] Bogus ambiguous reference to 'sqrt'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63797
--- Comment #4 from anlauf at gcc dot gnu.org ---
The following patch regtests ok and fixes the testcase:
diff --git a/gcc/fortran/module.c b/gcc/fortran/module.c
index 4db0a3ac76d..b4b7b437f86 100644
--- a/gcc/fortran/module.c
+++ b/gcc/fortran/module.c
@@ -6218,6 +6218,9 @@ write_symtree (gfc_symtree *st)
if (check_unique_name (st->name))
return;
+ if (strcmp (sym->module, "(intrinsic)") == 0)
+return;
+
p = find_pointer (sym);
if (p == NULL)
gfc_internal_error ("write_symtree(): Symbol not written");
It even fixes the slightly reduced & refined testcase:
module mod1
implicit none
real, parameter :: z = sqrt (0.0)
end module mod1
module mod2
implicit none
type t
real :: a = 0.
end type
interface sqrt
module procedure sqrt
end interface
contains
function sqrt (a)
type(t), intent(in) :: a
type(t) :: sqrt
sqrt% a = a% a
end function sqrt
end module mod2
program test
use mod1
use mod2
implicit none
type(t) :: x, y
y = sqrt (x)
end program test
[Bug libstdc++/99846] [11 regression] std::variant comparison operator error for recursive type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99846 Jonathan Wakely changed: What|Removed |Added Resolution|--- |INVALID Status|NEW |RESOLVED --- Comment #10 from Jonathan Wakely --- (In reply to Patrick Palka from comment #7) > After CWG 2369 (i.e. in GCC 11), we check constraints sooner during overload > resolution, so when considering the operator<=> candidate we end up looping > during constraint checking, which we consider to be a fatal error. Jason suggested adding a constraint to variant's operator<=> so that satisfaction would fail before we try the loopy part. But I don't know how to do that. I think both G++ and libstdc++ are behaving correctly here, and I can't think of a non-standard change we could make to support it. So closing as not a bug.
[Bug libstdc++/99846] [11 regression] std::variant comparison operator error for recursive type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99846 --- Comment #9 from Jonathan Wakely --- This still means that comparisons on Value objects use the comparison operators from the Variant base, and those comparisons depend on the alternative types in the variant. One of those is list, and comparisons for list depend on comparisons for Value. You are back where you started.
[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 Bug 24639 depends on bug 90307, which changed state. Bug 90307 Summary: -Wuninitialized only at -O1, not at -O2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90307 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/90307] -Wuninitialized only at -O1, not at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90307 Martin Sebor changed: What|Removed |Added Blocks||24639 Known to fail||10.3.0 Resolution|--- |FIXED Status|NEW |RESOLVED Target Milestone|--- |11.0 CC||msebor at gcc dot gnu.org --- Comment #3 from Martin Sebor --- GCC warns in both -O1 and -O2 since r11-7940. The IL shows the ctor is inlined now which is what makes the warning possible. Defining the ctor outside the class keeps GCC from inlining it which in turn defeats the warning as one might expect. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 [Bug 24639] [meta-bug] bug to track all Wuninitialized issues
[Bug c++/97197] With -O2, Incorrect -Werror=maybe-uninitialized thrown, leads to 'target_mem_ref' and 'dump_expr' in message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97197
Martin Sebor changed:
What|Removed |Added
Target Milestone|--- |11.0
Resolution|--- |FIXED
Status|ASSIGNED|RESOLVED
CC||msebor at gcc dot gnu.org
--- Comment #7 from Martin Sebor ---
For the test case in comment #0 GCC 11 issues the following so this works as
expected (GCC 10 output is similar).
In copy constructor ‘Normal::Normal(const Normal&)’,
inlined from ‘Combo::Combo(const Combo&)’ at pr97197.C:23:8,
inlined from ‘void Y::f()’ at pr97197.C:38:24:
pr97197.C:20:35: warning: ‘*((const bool*)& combo +1)’ may be used
uninitialized [-Wmaybe-uninitialized]
20 | Normal(Normal const& o) : p(o.p /* warning here for no good reason
*/) { }
| ~~^
pr97197.C: In member function ‘void Y::f()’:
pr97197.C:38:16: note: ‘combo’ declared here
38 | for (Combo combo : comboList) { /* implicit copy required to
reproduce bug */
|^
[Bug fortran/63797] Bogus ambiguous reference to 'sqrt'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63797 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org --- Comment #3 from anlauf at gcc dot gnu.org --- (In reply to kargl from comment #2) > The bug likely does not effect anyone that contributes code > to GCC. It does not affect me, but that is due my coding style (using public/private). > Fortunately, > there is a trivial work around, e.g., change the generic-name > from 'sqrt' to 'root'. Please don't do that. I already have my own generic root()... However, why in the world does an intrinsic need to show up in the module file in the first place? Consider: module mod1 implicit none real, parameter :: z = sqrt (0.0) end module mod1 Is there a reason why the intrinsic should not be prevented from occurring in the module file?
[Bug c/100068] inconsistent handling of noreturn on nested function declarations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100068 --- Comment #3 from Andrew Pinski --- What diagnostic is missing? That there is unreachable code after the noreturn functions? There are other bugs for that already? Or diagnostic when merging the two decls and one was noreturn and the other was not?
[Bug c++/83476] [8/9/10/11 Regression] Template argument deduction fails with reference template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83476
Patrick Palka changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot
gnu.org
--- Comment #3 from Patrick Palka ---
I am testing:
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index c2b581c0f82..0a7397b742f 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -21898,8 +21898,10 @@ static bool uses_deducible_template_parms (tree type);
static bool
deducible_expression (tree expr)
{
- /* Strip implicit conversions. */
- while (CONVERT_EXPR_P (expr) || TREE_CODE (expr) == VIEW_CONVERT_EXPR)
+ /* Strip implicit conversions and implicit INDIRECT_REFs. */
+ while (CONVERT_EXPR_P (expr)
+|| TREE_CODE (expr) == VIEW_CONVERT_EXPR
+|| REFERENCE_REF_P (expr))
expr = TREE_OPERAND (expr, 0);
return (TREE_CODE (expr) == TEMPLATE_PARM_INDEX);
}
[Bug c++/83476] [8/9/10/11 Regression] Template argument deduction fails with reference template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83476
Patrick Palka changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Known to work||4.8.1
Summary|Template argument deduction |[8/9/10/11 Regression]
|fails with reference|Template argument deduction
|template parameter |fails with reference
||template parameter
CC||jason at gcc dot gnu.org,
||ppalka at gcc dot gnu.org
Known to fail||10.3.0, 11.0, 8.4.0, 9.3.0
Last reconfirmed||2021-04-13
Ever confirmed|0 |1
Target Milestone|--- |8.5
Blocks||99885
--- Comment #2 from Patrick Palka ---
Confirmed. C++98 testcase (essentially equivalent to comment #2, but without
brace initialization) which exhibits a regression starting with r0-128511
(4.9.0):
template struct A {};
template void f(A);
int n;
int main() {
A a;
f(a);
}
GCC 4.8 compiles the testcase successfully.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99885
[Bug 99885] CTAD fails for auto const& NTTP
[Bug middle-end/90043] Turn on -Winit-self by default for -Wuninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90043
Martin Sebor changed:
What|Removed |Added
Last reconfirmed|2019-09-29 00:00:00 |2021-4-13
Blocks||24639
--- Comment #3 from Martin Sebor ---
No progress in GCC 11 (my bad). I'll see if I can remember for GCC 12. Below
is a C test case (in C++ the warning is included in -Wall).
$ (set -x && cat pr90043.c && gcc -S -Wall -Wextra -Wpedantic pr90043.c && gcc
-S -Wall -Wextra -Wpedantic -Winit-self pr90043.c)
+ cat pr90043.c
int f (void)
{
int i = i;
return i;
}
+ gcc -S -Wall -Wextra -Wpedantic pr90043.c
+ gcc -S -Wall -Wextra -Wpedantic -Winit-self pr90043.c
pr90043.c: In function ‘f’:
pr90043.c:3:7: warning: ‘i’ is used uninitialized [-Wuninitialized]
3 | int i = i;
| ^
pr90043.c:3:7: note: ‘i’ was declared here
3 | int i = i;
| ^
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
[Bug 24639] [meta-bug] bug to track all Wuninitialized issues
[Bug middle-end/86058] TARGET_MEM_REF causing incorrect message for -Wmaybe-uninitialized warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86058 --- Comment #5 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:8084ab15a3e300e3b2c537e56e0f3a1b00778aec commit r11-8161-g8084ab15a3e300e3b2c537e56e0f3a1b00778aec Author: Martin Sebor Date: Tue Apr 13 13:46:21 2021 -0600 PR middle-end/86058 - TARGET_MEM_REF causing incorrect message for -Wmaybe-uninitialized warning gcc/testsuite/ChangeLog: PR middle-end/86058 * gcc.dg/pr86058.c: New test.
[Bug middle-end/86058] TARGET_MEM_REF causing incorrect message for -Wmaybe-uninitialized warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86058
Martin Sebor changed:
What|Removed |Added
Component|c |middle-end
CC||msebor at gcc dot gnu.org
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #4 from Martin Sebor ---
GCC 11 issues the warning below so this has been (mostly) fixed.
pr86058.c: In function ‘zip’:
pr86058.c:13:21: warning: ‘arr’ may be used uninitialized
[-Wmaybe-uninitialized]
13 | out[i] = arr[i] + 1; /* { dg-warning "'arr[i]' may be used
uninitialized in this function" } */
| ~~~^~~
pr86058.c:10:11: note: ‘arr’ declared here
10 | int arr[10];
| ^~~
[Bug c++/99008] [10 Regression] ICE in set_constraints, at cp/constraint.cc:1256
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99008 --- Comment #5 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:96d73645c77e7784ebd12527322d52b6b7eedb06 commit r11-8160-g96d73645c77e7784ebd12527322d52b6b7eedb06 Author: Patrick Palka Date: Tue Apr 13 15:40:08 2021 -0400 c++: Adjust expected diagnostics for old-deja tests [PR99008] I missed adjusting these tests in the recently committed r11-8155. gcc/testsuite/ChangeLog: PR c++/99008 * g++.old-deja/g++.ns/crash3.C: Adjust expected diagnostic. * g++.old-deja/g++.ns/template7.C: Likewise. * g++.old-deja/g++.pt/crash8.C: Likewise.
[Bug c++/81873] spurious -Wreturn-type calling a locally declared noreturn function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81873 Martin Sebor changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=99974 --- Comment #7 from Martin Sebor --- See also pr99974 which may be due to the same root cause.
[Bug c++/100069] New: function redeclaration with noreturn not rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100069
Bug ID: 100069
Summary: function redeclaration with noreturn not rejected
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
In [dcl.attr.noreturn] the C++ standard specifies that
The first declaration of a function shall specify the noreturn attribute if
any declaration of that function specifies the noreturn attribute.
The test case below shows that GCC fails to enforce this constraint for
declarations in different scopes.
$ cat t.C && gcc -O2 -S -Wall -Wextra -Wpedantic t.C
void g ()
{
void f ();
}
void h ()
{
[[noreturn]] void f ();
}
void ff ();
[[noreturn]] void ff ();
t.C:12:19: error: function ‘void ff()’ declared ‘[[noreturn]]’ but its first
declaration was not
12 | [[noreturn]] void ff ();
| ^~
t.C:11:6: note: previous declaration of ‘void ff()’
11 | void ff ();
| ^~
In contrast, Clang issues errors for both redeclarations:
t.C:8:5: error: function declared '[[noreturn]]' after its first declaration
[[noreturn]] void f ();
^
t.C:3:8: note: declaration missing '[[noreturn]]' attribute is here
void f ();
^
t.C:12:3: error: function declared '[[noreturn]]' after its first declaration
[[noreturn]] void ff ();
^
t.C:11:6: note: declaration missing '[[noreturn]]' attribute is here
void ff ();
^
2 errors generated.
[Bug c++/100032] [8/9/10/11 Regression] renaming alias template that also adds cv-qualifiers is deemed equivalent to underlying template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100032 --- Comment #3 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:34ec63f1b5c2a4d39aa3b13ade96bcd44e294066 commit r11-8159-g34ec63f1b5c2a4d39aa3b13ade96bcd44e294066 Author: Jason Merrill Date: Tue Apr 13 14:49:29 2021 -0400 c++: alias template equivalence and cv-quals [PR100032] We also need to check that the cv-qualifiers are the same. gcc/cp/ChangeLog: PR c++/100032 * pt.c (get_underlying_template): Compare TYPE_QUALS. gcc/testsuite/ChangeLog: PR c++/100032 * g++.dg/cpp0x/alias-decl-equiv1.C: New test.
[Bug c++/99885] CTAD fails for auto const& NTTP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99885
Patrick Palka changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
CC||ppalka at gcc dot gnu.org
Last reconfirmed||2021-04-13
Ever confirmed|0 |1
Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot
gnu.org
--- Comment #1 from Patrick Palka ---
Confirmed, this never worked. Reduced:
template struct A {};
int n = 1;
A a = A{};
Looking into it.
[Bug c++/99974] attributes not propagated across function redeclarations at local scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99974 Martin Sebor changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=100068 --- Comment #4 from Martin Sebor --- See also pr100068 for another slightly different example involving noreturn and redeclarations.
[Bug c/100068] inconsistent handling of noreturn on nested function declarations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100068 Martin Sebor changed: What|Removed |Added Keywords|wrong-code |diagnostic --- Comment #2 from Martin Sebor --- On second thought, and after reading what C and C++ say about noreturn, I don't think it's wrong to emit just one call to either g0() or g1() in the test case. C in particular specifies that: A function declared with a _Noreturn function specifier shall not return to its caller. so declaring a function _Noreturn once is enough to grant the permission to eliminate subsequent code regardless of any intervening redeclarations of the function. Let me change the Keywords from wrong-code to missing diagnostic.
[Bug debug/88742] [8/9/10/11 Regression] Debugger jumps back when stepping over class destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88742 Jason Merrill changed: What|Removed |Added CC||jason at gcc dot gnu.org Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug c/100068] inconsistent handling of noreturn on nested function declarations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100068 Martin Sebor changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=99420 Keywords||wrong-code --- Comment #1 from Martin Sebor --- I noticed this while testing my fix for pr99420. I don't think it's terribly important so the bug is mainly to record the difference between GCC and other compilers. Rather than trying to change the code GCC emits to match other compilers I would suggest to solve the problem by issuing a diagnostic for the "mismatched" declarations.
[Bug c++/100032] [8/9/10/11 Regression] renaming alias template that also adds cv-qualifiers is deemed equivalent to underlying template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100032 Jason Merrill changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug c/100068] New: inconsistent handling of noreturn on nested function declarations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100068
Bug ID: 100068
Summary: inconsistent handling of noreturn on nested function
declarations
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
For the test case below, in f1() GCC (in both C and C++ modes) emits just one
call to g1() while Clang, ICC emit two. Visual C gives an error for the
noreturn mismatch between the two declarations of g1().
In f0(), all compilers emit just one call to g0() (Visual C with optimization;
without optimization it warns about the second call to g0() being unreachable).
$ cat a.c && gcc -O -S -Wall -fdump-tree-optimized=/dev/stdout a.c
void f0 (void)
{
extern __attribute__ ((noreturn)) int g0 (void);
{
extern int g0 (void);
}
g0 ();
g0 (); // eliminated by all tested compilers
}
void f1 (void)
{
extern int g1 (void);
{
extern __attribute__ ((noreturn)) int g1 (void);
}
g1 ();
g1 (); // eliminated by GCC, emitted by Clang and ICC
}
;; Function f0 (f0, funcdef_no=0, decl_uid=1943, cgraph_uid=1, symbol_order=0)
(executed once)
void f0 ()
{
[local count: 1073741824]:
g0 ();
}
;; Function f1 (f1, funcdef_no=1, decl_uid=1952, cgraph_uid=2, symbol_order=1)
(executed once)
void f1 ()
{
[local count: 1073741824]:
g1 ();
}
[Bug c++/97121] ICE (segfault) on incorrect default three-way comparison declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97121 --- Comment #5 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:4df918798b445e86305b63f86f5312a18e4017c5 commit r11-8158-g4df918798b445e86305b63f86f5312a18e4017c5 Author: Jakub Jelinek Date: Tue Apr 13 20:42:07 2021 +0200 testsuite: Add testcase for already fixed PR97121 This was fixed by r11-5866 aka PR96299 fix. 2021-04-13 Jakub Jelinek PR c++/97121 * g++.dg/cpp2a/spaceship-err6.C: New test.
[Bug libstdc++/99846] [11 regression] std::variant comparison operator error for recursive type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99846
--- Comment #8 from Nils Gladitz ---
(In reply to Jonathan Wakely from comment #5)
> Now this is *obviously* wrong. The left < right expression uses the
> operator< defined for the std::list base class, which depends on
> comparing the list's elements, which obviously recurses.
Maybe my original test case was reduced a bit too far.
Recursive but bounded example which maybe is a little closer to the original
case and I hope maybe a little less obviously wrong:
#include
#include
#include
struct Value;
using Array = std::list;
using Variant = std::variant;
struct Value : Variant
{
using Variant::variant;
};
int main()
{
Value left = Array{2, Array{}, 3};
Value right = Array{1};
std::cout << "<\t" << (left < right) << std::endl;
std::cout << ">\t" << (left > right) << std::endl;
std::cout << "==\t" << (left == right) << std::endl;
}
[Bug c/100064] False positive with -Wincompatible-pointer-types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100064 --- Comment #1 from joseph at codesourcery dot com --- This conversion is required to be diagnosed by ISO C. Some way of marking a particular cast as being an inheritance cast (thus, to be diagnosed if the types don't in fact match) would seem better than disabling it by default and assuming an implicit conversion is deliberate rather than a user mistake.
[Bug analyzer/98599] [11 Regression] fatal error: Cgraph edge statement index out of range with -Os -flto -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98599 --- Comment #17 from David Malcolm --- (In reply to Jan Hubicka from comment #15) Thanks. [...] > So apparenlty analyzer is first pass that does use UIDs of statements at > WPA time. I wonder if there should be a debug flag that trashes all UIDs to a garbage value at the end of every pass, to avoid reliance on UIDs surviving a pass.
[Bug c++/100054] [11 Regression] internal compiler error: in get_nsdmi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100054 --- Comment #5 from Patrick Palka --- (In reply to Jason Merrill from comment #4) > Fixed. Apparently 90479 is the wrong PR number for the earlier change, I > wonder what the correct one was. Looks like it's PR90749
[Bug target/99249] SVE: ICE in aarch64_expand_sve_const_vector (during RTL pass: early_remat)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99249 rsandifo at gcc dot gnu.org changed: What|Removed |Added CC||rsandifo at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #3 from rsandifo at gcc dot gnu.org --- Mine.
[Bug c++/100054] [11 Regression] internal compiler error: in get_nsdmi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100054 Jason Merrill changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Jason Merrill --- Fixed. Apparently 90479 is the wrong PR number for the earlier change, I wonder what the correct one was.
[Bug target/100056] [9/10/11 Regression] orr + lsl vs. [us]bfiz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100056 --- Comment #8 from Jakub Jelinek --- Created attachment 50586 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50586=edit gcc11-pr100056.patch Updated patch.
[Bug target/90479] gcc-arm-none-eabi-8-2018-q4-major [c99 plus -pg not working]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90479 --- Comment #5 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:6173f713a35d5450f0e2acfdaec695b42632aeed commit r11-8157-g6173f713a35d5450f0e2acfdaec695b42632aeed Author: Jason Merrill Date: Tue Apr 13 12:33:39 2021 -0400 c++: generic lambda in template fn with DMI [PR100054] get_nsdmi instantiates default member initializers on demand. It tries to push into the context of the class before doing so, so access checking works properly, but since my patch for 90479 not for local classes. We should only be doing this when any template parameters have arguments. But in this case, we get here while regenerating a generic lambda, so processing_template_decl is true, even though the class and its DMI are non-dependent at this point. And so we crashed. So let's do more of the pushing into the context of the class even for local classes. gcc/cp/ChangeLog: PR c++/100054 PR c++/90479 * init.c (get_nsdmi): Do more context adjustment for local classes. gcc/testsuite/ChangeLog: PR c++/100054 * g++.dg/cpp1y/lambda-generic-local-class1.C: New test.
[Bug c++/100054] [11 Regression] internal compiler error: in get_nsdmi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100054 --- Comment #3 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:6173f713a35d5450f0e2acfdaec695b42632aeed commit r11-8157-g6173f713a35d5450f0e2acfdaec695b42632aeed Author: Jason Merrill Date: Tue Apr 13 12:33:39 2021 -0400 c++: generic lambda in template fn with DMI [PR100054] get_nsdmi instantiates default member initializers on demand. It tries to push into the context of the class before doing so, so access checking works properly, but since my patch for 90479 not for local classes. We should only be doing this when any template parameters have arguments. But in this case, we get here while regenerating a generic lambda, so processing_template_decl is true, even though the class and its DMI are non-dependent at this point. And so we crashed. So let's do more of the pushing into the context of the class even for local classes. gcc/cp/ChangeLog: PR c++/100054 PR c++/90479 * init.c (get_nsdmi): Do more context adjustment for local classes. gcc/testsuite/ChangeLog: PR c++/100054 * g++.dg/cpp1y/lambda-generic-local-class1.C: New test.
[Bug libstdc++/100060] [10/11 Regression] freestanding header includes non-freestanding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100060 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Jonathan Wakely --- Fixed for 10.4
[Bug libstdc++/100060] [10/11 Regression] freestanding header includes non-freestanding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100060 --- Comment #2 from CVS Commits --- The releases/gcc-10 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:d83dace65b97112320042c7f4941b64ef339799d commit r10-9703-gd83dace65b97112320042c7f4941b64ef339799d Author: Jonathan Wakely Date: Tue Apr 13 16:55:37 2021 +0100 libstdc++: Fix to work freestanding [PR 100060] libstdc++-v3/ChangeLog: PR libstdc++/100060 * include/std/bit: Only include for hosted build, use otherwise. (cherry picked from commit 474cb5a0a404c5de7c1cd21aac8b1b7e7ce95d9b)
[Bug target/100067] New: Unexpected warning for -mcpu=neoverse-n1 when configured with --with-fpu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100067 Bug ID: 100067 Summary: Unexpected warning for -mcpu=neoverse-n1 when configured with --with-fpu Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: rearnsha at gcc dot gnu.org Target Milestone: --- If the compiler is configured with (for example): --with-arch=armv7-a --with-fpu=neon --with-float=hard then compiling with gcc -S -mcpu=neoverse-n1 leads to an unexpected warning: cc1: warning: switch ‘-mcpu=neoverse-n1’ conflicts with ‘-march=armv8.2-a’ switch The same can be seen if -mfpu is passed explicitly on the command-line (which, while it shouldn't happen, is slightly less surprising). If -mfpu is specified to be anything other than auto (via command line or configuration), it is expected that this will override *all* features from the cpu/arch setting that relate to the use of the FPU. Note, we should probably at this point progress the deprecation process for -mfpu by deprecating the config option that allows this to be set during configure.
[Bug rtl-optimization/100066] [11 Regression] ICE in lra_assign, at lra-assigns.c:1649
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100066 --- Comment #2 from Vladimir Makarov --- Thank you for reporting this. I've reproduced this bug. It seems something wrong with hard reg live range splitting. This code is complicated so I can not say when it will be fixed but I'll do my best to fix this as soon as possible.
[Bug c++/92416] ICE with spaceship and vector types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92416 Jonathan Wakely changed: What|Removed |Added Keywords|ice-on-invalid-code |FIXME Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2021-04-13
[Bug c++/97121] ICE (segfault) on incorrect default three-way comparison declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97121 Jonathan Wakely changed: What|Removed |Added CC||crillion at tiscali dot it --- Comment #4 from Jonathan Wakely --- *** Bug 99086 has been marked as a duplicate of this bug. ***
[Bug c++/99086] including and defaulting spaceship operator causes compiler segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99086 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #1) > GCC's crash on the invalid code has already been fixed in r11-5866: > > c++: Fix defaulted <=> fallback to < and == [PR96299] And we already have multiple duplicates of this. *** This bug has been marked as a duplicate of bug 97121 ***
[Bug c++/97216] ICE with (incorrect) spaceship operator declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97216 --- Comment #3 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #2) > It is ill-formed, because operator<=> can't return bool. And that's because <=> has to say if one operand is greater, equal, or less than the other. A bool can't encode three states. You probably want to use "auto" as the return type.
[Bug target/99929] SVE: Wrong code at -O2 -ftree-vectorize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99929 rsandifo at gcc dot gnu.org changed: What|Removed |Added CC||rsandifo at gcc dot gnu.org Last reconfirmed||2021-04-13 Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED --- Comment #2 from rsandifo at gcc dot gnu.org --- Nice catch. Looks like we're missing some equality checks for variable-length CONST_VECTORs.
[Bug c++/97121] ICE (segfault) on incorrect default three-way comparison declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97121 Jonathan Wakely changed: What|Removed |Added CC||GCCBugzilla at DRHouck dot me --- Comment #3 from Jonathan Wakely --- *** Bug 97216 has been marked as a duplicate of this bug. ***
[Bug c++/97216] ICE with (incorrect) spaceship operator declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97216 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Jonathan Wakely --- (In reply to Daniel Houck from comment #0) > Attempting to compile the following code produces an ICE. The code may be > ill-formed (I don't know if I'm reading the standard correctly when trying > to figure that out) It is ill-formed, because operator<=> can't return bool. (In reply to Jakub Jelinek from comment #1) > Most likely dup of PR97121 Yes, the ICE is fixed by the same commit as I noted in that PR, r11-5866 *** This bug has been marked as a duplicate of bug 97121 ***
[Bug c++/97121] ICE (segfault) on incorrect default three-way comparison declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97121 --- Comment #2 from Jonathan Wakely --- Fixed on trunk by r11-5866 c++: Fix defaulted <=> fallback to < and == [PR96299] I thought I had implemented P1186R3, but apparently I didn't read it closely enough to understand the point of the paper, namely that for a defaulted operator<=>, if a member type doesn't have a viable operator<=>, we will use its operator< and operator== if the defaulted operator has an specific comparison category as its return type; the compiler can't guess if it should be strong_ordering or something else, but the user can make that choice explicit. The libstdc++ test change was necessary because of the change in genericize_spaceship from op0 > op1 to op1 < op0; this should be equivalent, but isn't because of PR88173. We should add a test and close it.
[Bug libstdc++/100060] [10/11 Regression] freestanding header includes non-freestanding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100060 --- Comment #1 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:474cb5a0a404c5de7c1cd21aac8b1b7e7ce95d9b commit r11-8156-g474cb5a0a404c5de7c1cd21aac8b1b7e7ce95d9b Author: Jonathan Wakely Date: Tue Apr 13 16:55:37 2021 +0100 libstdc++: Fix to work freestanding [PR 100060] libstdc++-v3/ChangeLog: PR libstdc++/100060 * include/std/bit: Only include for hosted build, use otherwise.
[Bug middle-end/100059] [OpenMP] wrong code with 'declare target link' and a scalar variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100059 Tobias Burnus changed: What|Removed |Added Last reconfirmed||2021-04-13 Assignee|unassigned at gcc dot gnu.org |burnus at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 --- Comment #4 from Tobias Burnus --- That's in issue with how the nvptx pseudoassembler re-outputs the assembler, which reorders the symbols – such that the order in var_mappings is wrong (i.e. differs from the order on the host). (Order is based on traversing the htab – I wonder why this did not show up before?) See ISSUE DESCRIPTION and SOLUTION (PATCH) at https://github.com/MentorEmbedded/nvptx-tools/pull/29
[Bug rtl-optimization/100066] [11 Regression] ICE in lra_assign, at lra-assigns.c:1649
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100066 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Target Milestone|--- |11.0 CC||jakub at gcc dot gnu.org, ||vmakarov at gcc dot gnu.org Last reconfirmed||2021-04-13 Ever confirmed|0 |1 Priority|P3 |P1 --- Comment #1 from Jakub Jelinek --- Started with r11-8008-g4bbd51afaa4a3c116fb538d912b35e126be80b41
[Bug c++/99008] [10 Regression] ICE in set_constraints, at cp/constraint.cc:1256
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99008 Patrick Palka changed: What|Removed |Added Summary|[10/11 Regression] ICE in |[10 Regression] ICE in |set_constraints, at |set_constraints, at |cp/constraint.cc:1256 |cp/constraint.cc:1256 --- Comment #4 from Patrick Palka --- Fixed for GCC 11 so far.
[Bug c++/99008] [10/11 Regression] ICE in set_constraints, at cp/constraint.cc:1256
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99008 --- Comment #3 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:8913b2c2bcded39427ff27e6dfc276ae8555f6b8 commit r11-8155-g8913b2c2bcded39427ff27e6dfc276ae8555f6b8 Author: Patrick Palka Date: Tue Apr 13 12:35:33 2021 -0400 c++: Reject alias CTAD in C++17 [PR99008] Here, in C++17 mode, we only pedwarn about the use of alias CTAD and then later ICE from alias_ctad_tweaks when attempting to constrain the guides. Since the construction of the guides of an alias template effectively relies on concepts, we shouldn't be permissive about alias CTAD in C++17 mode, so this patch turns the pertinent pedwarn in do_class_deduction into an error. In order to get a consistent diagnostic for B() vs the other forms in the added testcase, I had to remove the special handling of CTAD with empty initializer in build_functional_cast_1 so that we always pass 'complain' to do_auto_deduction. gcc/cp/ChangeLog: PR c++/99008 * pt.c (do_class_deduction): Reject alias CTAD in C++17 mode rather than issuing a pedwarn. * typeck2.c (build_functional_cast_1): Handle CTAD uniformly for consistent diagnostics. gcc/testsuite/ChangeLog: PR c++/99008 * g++.dg/parse/template2.C: Adjust expected diagnostic. * g++.dg/template/error8.C: Likewise. * g++.dg/cpp1z/class-deduction84.C: New test.
[Bug tree-optimization/100053] [9/10 Regression] tree-fre incorrectly delete a condition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100053
--- Comment #10 from rguenther at suse dot de ---
On April 13, 2021 5:28:37 PM GMT+02:00, "qinzhao at gcc dot gnu.org"
wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100053
>
>--- Comment #9 from qinzhao at gcc dot gnu.org ---
>(In reply to Richard Biener from comment #3)
>> It would be nice if the reduced testcase could be sanitized to throw
>less
>> diagnostics with -Wall, likewise if it were a runtime testcase.
>>
>> Reduced:
>>
>> int __attribute__((returns_twice,noipa)) x() { return 0; }
>> void __attribute__((noipa)) ar() {}
>> void __attribute__((noipa)) as() { __builtin_abort (); }
>> int a1, a2, a3;
>> void __attribute__((noipa)) v(int init)
>> {
>> if (!init) {
>> as();
>> if (a1)
>> goto aq;
>> if (x ())
>> if (a2)
>> as();
>> }
>> if (!init)
>> a3 = 1;
>> ar();
>> aq:
>> if (!init)
>> as();
>> }
>>
>> int main()
>> {
>> v(1);
>> return 0;
>> }
>
>Hi, thanks for the further reduced testing case.
>I am wondering whether you did the above further reducing manually?
Yes, I did.
[Bug rtl-optimization/100066] New: [11 Regression] ICE in lra_assign, at lra-assigns.c:1649
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100066
Bug ID: 100066
Summary: [11 Regression] ICE in lra_assign, at
lra-assigns.c:1649
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
Target: x86_64-unknown-linux-gnu
gcc-11.0.1-alpha20210411 snapshot (g:ac200799acb5cd2fb9e1758f6bf5fff1978daaeb)
ICEs when compiling the following testcase w/ -O1:
int pm;
void
w3 (int, int, int);
void
e6 (__int128 rt, long int mo)
{
mo += rt / 0;
w3 (pm / mo, pm, 0);
}
% x86_64-unknown-linux-gnu-gcc-11.0.1 -O1 -w -c eukuvtrk.c
during RTL pass: reload
eukuvtrk.c: In function 'e6':
eukuvtrk.c:11:1: internal compiler error: in lra_assign, at lra-assigns.c:1649
11 | }
| ^
0xc6d9fa lra_assign(bool&)
/var/tmp/portage/sys-devel/gcc-11.0.1_alpha20210411/work/gcc-11-20210411/gcc/lra-assigns.c:1649
0xc67b94 lra(_IO_FILE*)
/var/tmp/portage/sys-devel/gcc-11.0.1_alpha20210411/work/gcc-11-20210411/gcc/lra.c:2387
0xc203c9 do_reload
/var/tmp/portage/sys-devel/gcc-11.0.1_alpha20210411/work/gcc-11-20210411/gcc/ira.c:5835
0xc203c9 execute
/var/tmp/portage/sys-devel/gcc-11.0.1_alpha20210411/work/gcc-11-20210411/gcc/ira.c:6021
It ICEs on the same assertion as in PR99829, so I suppose it's actually a
duplicate.
[Bug target/97142] __builtin_fmod not optimized on POWER
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97142 --- Comment #11 from Segher Boessenkool --- (In reply to luoxhu from comment #10) > If not built with fast-math, gimple_has_side_effects will return true and > cause the expand_call_stmt fail to expand the "_1 = fmod (x_2(D), y_3(D));" > to internal function. X86 also produces "bl fmod" for O3 build. > > > xlF expands the fmod to below ASM, no FMA generated? > > > 1900 : > 1900: 8c 03 01 10 vspltisw v0,1 > 1904: 00 00 24 c8 lfd f1,0(r4) > 1908: 00 00 03 c8 lfd f0,0(r3) > 190c: e2 03 40 f0 xvcvsxwdp vs2,vs32 > 1910: c0 09 62 f0 xsdivdp vs3,vs2,vs1 > 1914: 80 19 80 f0 xsmuldp vs4,vs0,vs3 > 1918: 64 21 a0 f0 xsrdpiz vs5,vs4 > 191c: 88 2d 01 f0 xsnmsubadp vs0,vs1,vs5 > 1920: 18 00 20 fc frspf1,f0 > 1924: 20 00 80 4e blr xsnmsubadp is an FMA. Multiply-subtract in this case, but that is just a sign switch -- I often say FMA for all of fmadd, fnmadd, fnmsub, fmsub, and their VSX counterparts. "Anything that does a multiply-type operation followed by an addition-type operation". (And often call integer MADs "FMA" as well, which is totally wrong, but :-) )
[Bug target/100056] [9/10/11 Regression] orr + lsl vs. [us]bfiz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100056 --- Comment #7 from Luc Van Oostenryck --- Created attachment 50585 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50585=edit newer testcases (with 32 -> 64-bit extensions)
[Bug rtl-optimization/98973] [11 regression] Wrong code with gcse store motion pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98973 --- Comment #12 from Jeffrey A. Law --- IIRC LSM is quite restricted in the types of MEM expressions it will optimize. In particular I think they have to be SYMBOL_REFs which severely limits LSM's effectiveness. I would support removing it given that it's not enabled by default anywhere and is of limited utility.
[Bug fortran/99307] FAIL: gfortran.dg/class_assign_4.f90 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99307 --- Comment #11 from Paul Thomas --- The patch was posted at https://gcc.gnu.org/pipermail/fortran/2021-April/055923.html I'll ping it. Thanks Richard. Paul
