[Bug c++/108761] New: Add option to produce a unique section for non-COMDAT __attribute__((section("foo"))) object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108761
Bug ID: 108761
Summary: Add option to produce a unique section for non-COMDAT
__attribute__((section("foo"))) object
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: i at maskray dot me
Target Milestone: ---
% cat a.cc
__attribute__((section("foo"))) void f() {}
__attribute__((section("foo"))) void g() {}
% g++ -c -ffunction-sections a.cc
% readelf -WS a.o | grep foo
[ 4] foo PROGBITS 40 0e 00 AX
0 0 1
There is one section named `foo`, with f and g in it (they do not use COMDAT).
In ld --gc-sections, f and g are retained or discarded as a unit.
If we place f and g in two `foo` sections, --gc-sections can discard them
separately.
(We need assembler syntax `.section foo,"ax",@progbits,unique,1` which requires
binutils>=2.35.)
https://reviews.llvm.org/D143745 proposes to add such a feature with an option
name like `-ffunction-sections[=(default,all)]`.
I feel that the option argument is non-intuitive but do not come up with a
better name right now.
I raise this feature request to seek feedback from GCC :)
[Bug libstdc++/108760] New: ranges::iota is not included in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108760
Bug ID: 108760
Summary: ranges::iota is not included in
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
It seems wrong that libstdc++ needs to include for ranges::iota.
#include
int main() {
int x[] = {0, 0, 0, 0, 0};
std::ranges::iota(x, 0);
}
https://godbolt.org/z/33EPeqd1b
[Bug c++/108759] New: "mandatory copy elision" not implemented during constant evaluation redux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108759
Bug ID: 108759
Summary: "mandatory copy elision" not implemented during
constant evaluation redux
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: herring at lanl dot gov
Target Milestone: ---
Extending the test case in (the invalid) #94537 to have a user-provided
destructor does not cause the "mandatory copy elision" to take place even
though the implementation is no longer permitted to introduce a temporary:
struct A;
extern const A a;
struct A {
bool special=this==&a;
constexpr ~A() {}
};
constexpr A get() {return {};} // or "return A();"
constexpr A a=get();
static_assert(a.special);
[Bug testsuite/108675] FAIL: gcc.c-torture/execute/builtins/*printf.c when stdio.h includes definitions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108675
--- Comment #9 from nightstrike ---
I understand it's not ideal based on comment #6, but this fixes all the tests:
diff --git a/gcc/testsuite/gcc.c-torture/execute/builtins/lib/fprintf.c
b/gcc/testsuite/gcc.c-torture/execute/builtins/lib/fprintf.c
index 853a705e86d..499c81b0fa7 100644
--- a/gcc/testsuite/gcc.c-torture/execute/builtins/lib/fprintf.c
+++ b/gcc/testsuite/gcc.c-torture/execute/builtins/lib/fprintf.c
@@ -1,11 +1,10 @@
-#include
#include
extern void abort (void);
extern int inside_main;
__attribute__ ((__noinline__))
int
-fprintf (FILE *fp, const char *string, ...)
+fprintf (void *fp, const char *string, ...)
{
va_list ap;
int r;
@@ -22,7 +21,7 @@ fprintf (FILE *fp, const char *string, ...)
/* Locking stdio doesn't matter for the purposes of this test. */
__attribute__ ((__noinline__))
int
-fprintf_unlocked (FILE *fp, const char *string, ...)
+fprintf_unlocked (void *fp, const char *string, ...)
{
va_list ap;
int r;
diff --git a/gcc/testsuite/gcc.c-torture/execute/builtins/lib/printf.c
b/gcc/testsuite/gcc.c-torture/execute/builtins/lib/printf.c
index 4be7578d124..0d405241cfe 100644
--- a/gcc/testsuite/gcc.c-torture/execute/builtins/lib/printf.c
+++ b/gcc/testsuite/gcc.c-torture/execute/builtins/lib/printf.c
@@ -1,4 +1,3 @@
-#include
#include
extern void abort (void);
extern int inside_main;
diff --git a/gcc/testsuite/gcc.c-torture/execute/builtins/lib/sprintf.c
b/gcc/testsuite/gcc.c-torture/execute/builtins/lib/sprintf.c
index 3ac447b117f..6de24cd7df4 100644
--- a/gcc/testsuite/gcc.c-torture/execute/builtins/lib/sprintf.c
+++ b/gcc/testsuite/gcc.c-torture/execute/builtins/lib/sprintf.c
@@ -1,4 +1,3 @@
-#include
#include
extern void abort (void);
extern int inside_main;
[Bug c++/104577] needs copy constructor for class non-type template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104577 S. Davis Herring changed: What|Removed |Added CC||herring at lanl dot gov --- Comment #4 from S. Davis Herring --- The understood direction for CWG2459 makes it clear that class-type template parameters must indeed be copied; in fact, they have to be copied twice in some cases to guarantee that they have the correct value when user-provided constructors are involved.
[Bug middle-end/108754] [13 Regression] multiple testsuite errors with r13-5761-g10827a92f1a8c3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108754 --- Comment #9 from Vladimir Makarov --- (In reply to Hans-Peter Nilsson from comment #8) > My test-run with the suggested change on top of r13-5761-g10827a92f1a8c3 > came out clean (all regressions resolved, no new ones added) so I'll close > this issue. Thanks for promptly taking care of this! Thank you for your help. And sorry for the inconveniences because of my patch. It is hard to do changes in RA as they might affect different targets in some unexpected way.
[Bug analyzer/108745] -Wanalyzer-deref-before-check false positives seen in ImageMagick due to checks in macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108745 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from David Malcolm --- Should be fixed by the above patch. The warning is new in GCC 13 so no backport needed.
[Bug analyzer/108745] -Wanalyzer-deref-before-check false positives seen in ImageMagick due to checks in macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108745 --- Comment #1 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:aa601e30758581837c9ca7b738ec2810a18350f5 commit r13-5811-gaa601e30758581837c9ca7b738ec2810a18350f5 Author: David Malcolm Date: Fri Feb 10 18:10:21 2023 -0500 analyzer: don't warn for deref-before-check for checks in macros [PR108745] Integration testing shows this patch fixes all 9 known false positives from -Wanalyzer-deref-before-check within ImageMagick-7.1.0-57, and eliminates 34 further as-yet unassessed such diagnostics, without eliminating the 1 known true positive. This improves the rate of true positives for the warning from 1.56% to 4.76% of the total: -Wanalyzer-deref-before-check: 1.56% -> 4.76% (GOOD: 1 BAD: 63->20) TRUE: 1 FALSE: 15 -> 6 (-9) ImageMagick-7.1.0-57: 9 -> 0 (-9) TODO: 48 -> 14 (-34) ImageMagick-7.1.0-57: 21 -> 1 (-20) qemu-7.2.0: 25 -> 11 (-14) gcc/analyzer/ChangeLog: PR analyzer/108745 * sm-malloc.cc (deref_before_check::emit): Reject the warning if the check occurs within a macro defintion. gcc/testsuite/ChangeLog: PR analyzer/108745 * gcc.dg/analyzer/deref-before-check-macro-pr108745.c: New test. * gcc.dg/analyzer/deref-before-check-macro.c: New test. Signed-off-by: David Malcolm
[Bug target/108758] New: gcc.target/powerpc/float128-cmp2-runnable.c fails with excess errors on power 9 BE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108758 Bug ID: 108758 Summary: gcc.target/powerpc/float128-cmp2-runnable.c fails with excess errors on power 9 BE Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- This fails on power 9 BE (only) and fails for trunk as well as gcc 12. It does not fail for gcc 11 and 10. spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test2/gcc/xgcc -B/home/seurer/gcc/git/build/gcc-test2/gcc/ /home/seurer/gcc/git/gcc-test2/gcc/testsuite/gcc.target/powerpc/float128-cmp2-runnable.c -m32 -fdiagnostics-plain-output -O2 -mdejagnu-cpu=power9 -lm -o ./float128-cmp2-runnable.exe /home/seurer/gcc/git/gcc-test2/gcc/testsuite/gcc.target/powerpc/float128-cmp2-runnable.c: In function 'main': /home/seurer/gcc/git/gcc-test2/gcc/testsuite/gcc.target/powerpc/float128-cmp2-runnable.c:155:3: error: '__builtin_vsx_scalar_cmp_exp_qp_eq' requires quad-precision floating-point arithmetic /home/seurer/gcc/git/gcc-test2/gcc/testsuite/gcc.target/powerpc/float128-cmp2-runnable.c:155:3: note: overloaded builtin '__builtin_vec_scalar_cmp_exp_eq' is implemented by builtin '__builtin_vsx_scalar_cmp_exp_qp_eq' /home/seurer/gcc/git/gcc-test2/gcc/testsuite/gcc.target/powerpc/float128-cmp2-runnable.c:171:3: error: '__builtin_vsx_scalar_cmp_exp_qp_eq' requires quad-precision floating-point arithmetic /home/seurer/gcc/git/gcc-test2/gcc/testsuite/gcc.target/powerpc/float128-cmp2-runnable.c:171:3: note: overloaded builtin '__builtin_vec_scalar_cmp_exp_eq' is implemented by builtin '__builtin_vsx_scalar_cmp_exp_qp_eq' /home/seurer/gcc/git/gcc-test2/gcc/testsuite/gcc.target/powerpc/float128-cmp2-runnable.c:187:3: error: '__builtin_vsx_scalar_cmp_exp_qp_lt' requires quad-precision floating-point arithmetic /home/seurer/gcc/git/gcc-test2/gcc/testsuite/gcc.target/powerpc/float128-cmp2-runnable.c:187:3: note: overloaded builtin '__builtin_vec_scalar_cmp_exp_lt' is implemented by builtin '__builtin_vsx_scalar_cmp_exp_qp_lt' /home/seurer/gcc/git/gcc-test2/gcc/testsuite/gcc.target/powerpc/float128-cmp2-runnable.c:203:3: error: '__builtin_vsx_scalar_cmp_exp_qp_lt' requires quad-precision floating-point arithmetic /home/seurer/gcc/git/gcc-test2/gcc/testsuite/gcc.target/powerpc/float128-cmp2-runnable.c:203:3: note: overloaded builtin '__builtin_vec_scalar_cmp_exp_lt' is implemented by builtin '__builtin_vsx_scalar_cmp_exp_qp_lt' /home/seurer/gcc/git/gcc-test2/gcc/testsuite/gcc.target/powerpc/float128-cmp2-runnable.c:219:3: error: '__builtin_vsx_scalar_cmp_exp_qp_gt' requires quad-precision floating-point arithmetic /home/seurer/gcc/git/gcc-test2/gcc/testsuite/gcc.target/powerpc/float128-cmp2-runnable.c:219:3: note: overloaded builtin '__builtin_vec_scalar_cmp_exp_gt' is implemented by builtin '__builtin_vsx_scalar_cmp_exp_qp_gt' /home/seurer/gcc/git/gcc-test2/gcc/testsuite/gcc.target/powerpc/float128-cmp2-runnable.c:235:3: error: '__builtin_vsx_scalar_cmp_exp_qp_gt' requires quad-precision floating-point arithmetic /home/seurer/gcc/git/gcc-test2/gcc/testsuite/gcc.target/powerpc/float128-cmp2-runnable.c:235:3: note: overloaded builtin '__builtin_vec_scalar_cmp_exp_gt' is implemented by builtin '__builtin_vsx_scalar_cmp_exp_qp_gt' /home/seurer/gcc/git/gcc-test2/gcc/testsuite/gcc.target/powerpc/float128-cmp2-runnable.c:251:3: error: '__builtin_vsx_scalar_cmp_exp_qp_unordered' requires quad-precision floating-point arithmetic /home/seurer/gcc/git/gcc-test2/gcc/testsuite/gcc.target/powerpc/float128-cmp2-runnable.c:251:3: note: overloaded builtin '__builtin_vec_scalar_cmp_exp_unordered' is implemented by builtin '__builtin_vsx_scalar_cmp_exp_qp_unordered' /home/seurer/gcc/git/gcc-test2/gcc/testsuite/gcc.target/powerpc/float128-cmp2-runnable.c:267:3: error: '__builtin_vsx_scalar_cmp_exp_qp_unordered' requires quad-precision floating-point arithmetic /home/seurer/gcc/git/gcc-test2/gcc/testsuite/gcc.target/powerpc/float128-cmp2-runnable.c:267:3: note: overloaded builtin '__builtin_vec_scalar_cmp_exp_unordered' is implemented by builtin '__builtin_vsx_scalar_cmp_exp_qp_unordered' compiler exited with status 1 Executing on host: /home/seurer/gcc/git/build/gcc-test2/gcc/xgcc -B/home/seurer/gcc/git/build/gcc-test2/gcc/ exceptions_enabled3155871.cc -m32 -fdiagnostics-plain-output -S -o exceptions_enabled3155871.s(timeout = 300) spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test2/gcc/xgcc -B/home/seurer/gcc/git/build/gcc-test2/gcc/ exceptions_enabled3155871.cc -m32 -fdiagnostics-plain-output -S -o exceptions_enabled3155871.s FAIL: gcc.target/powerpc/float128-cmp2-runnable.c (test for excess errors) Excess errors: /home/seurer/gcc/git/gcc-test2/gcc/testsuite/gcc.target/powerpc/float128-cmp2-runnable.c:155:3: error: '__builtin_vsx_scalar_cmp_exp_qp_eq' requ
[Bug middle-end/108754] [13 Regression] multiple testsuite errors with r13-5761-g10827a92f1a8c3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108754 Hans-Peter Nilsson changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #8 from Hans-Peter Nilsson --- My test-run with the suggested change on top of r13-5761-g10827a92f1a8c3 came out clean (all regressions resolved, no new ones added) so I'll close this issue. Thanks for promptly taking care of this!
[Bug testsuite/106120] [13 regression] g++.dg/warn/Wstringop-overflow-4.C fails since r13-1268-g8c99e307b20c50
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106120 Hans-Peter Nilsson changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Hans-Peter Nilsson --- (In reply to seurer from comment #8) > Yes, in the test run I just did it worked. Ok, as this PR was "testsuite" as opposed to an underlying issue, I'm closing this.
[Bug tree-optimization/88443] [meta-bug] bogus/missing -Wstringop-overflow warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443 Bug 88443 depends on bug 106120, which changed state. Bug 106120 Summary: [13 regression] g++.dg/warn/Wstringop-overflow-4.C fails since r13-1268-g8c99e307b20c50 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106120 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/108757] We do not simplify (a - (N*M)) / N + M -> a / N
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108757 --- Comment #2 from Andrew Pinski --- I am not sure this can be done in the normal case unless you know the range of a to be [64...INF] . The wrap around case might be an issue ... But I am not 100% sure.
[Bug rtl-optimization/108516] Useless movzx instruction emitted when loading 8 bits from 24 bit struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108516
--- Comment #5 from Levo DeLellis ---
Here's a testcase for the same problem
struct T2 { bool a, b; };
static T2 test();
int myfunc() {
auto [a, b] = test();
return ((int)a<<1) + b;
}
[Bug tree-optimization/108757] We do not simplify (a - (N*M)) / N + M -> a / N
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108757 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug tree-optimization/97529] (len / N) * N <= len is not optimized to 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97529 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Andrew Pinski --- Dup of bug 96433. *** This bug has been marked as a duplicate of bug 96433 ***
[Bug tree-optimization/96433] Failed to optimize (A / N) * N <= A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96433 Andrew Pinski changed: What|Removed |Added CC||jmuizelaar at mozilla dot com --- Comment #4 from Andrew Pinski --- *** Bug 97529 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/108757] We do not simplify (a - (N*M)) / N + M -> a / N
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108757 Peter Bergner changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2023-02-10 CC||chip.kerchner at ibm dot com Target||powerpc64le-linux Status|UNCONFIRMED |NEW --- Comment #1 from Peter Bergner --- Reported by our Eigen developers and confirmed by me.
[Bug tree-optimization/108757] New: We do not simplify (a - (N*M)) / N + M -> a / N
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108757
Bug ID: 108757
Summary: We do not simplify (a - (N*M)) / N + M -> a / N
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: bergner at gcc dot gnu.org
Target Milestone: ---
The Eigen project code has a missed optimization that basically simplifies down
to the following test case:
linux$ cat bug.c
#define N 32
#define M 2
unsigned long int
foo (unsigned long int a)
{
return (a - (N*M)) / N + M;
}
linux$ gcc -O2 -S bug.c
linux$ cat bug.s
foo:
addi 3,3,-64
srdi 3,3,5
addi 3,3,2
blr
We should be able to simplify this down to just 'a / N', which for power-of-2
N, results in just the srdi...although, I don't think N is required to be a
power-of-2 to fold this down to just 'a / N'. Can we also simplify this for
non-constant N & M? Maybe under -fast-math or something similar?
[Bug middle-end/108756] Unnecessary instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108756 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- Dup of bug 108516. *** This bug has been marked as a duplicate of bug 108516 ***
[Bug rtl-optimization/108516] Useless movzx instruction emitted when loading 8 bits from 24 bit struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108516 Andrew Pinski changed: What|Removed |Added CC||levo.delellis at gmail dot com --- Comment #4 from Andrew Pinski --- *** Bug 108756 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/108705] [13 Regression] Unexpected CPU time usage with LTO in ranger propagation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108705 Rimvydas (RJ) changed: What|Removed |Added Resolution|--- |FIXED Status|WAITING |RESOLVED --- Comment #10 from Rimvydas (RJ) --- Fixed by g:6493b7af37e473a89c67afab474330f931dd8447 no more issues in ltrans partitions
[Bug c++/108756] New: Unnecessary instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108756
Bug ID: 108756
Summary: Unnecessary instruction
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: levo.delellis at gmail dot com
Target Milestone: ---
You can test this on godbolt. Using gcc 12.2 on x86-64 linux
There appears to be an unnecessary instruction. I commented the assembly below
struct T2 { bool a, b; };
static T2 test();
int myfunc() {
auto [a, b] = test();
return ((int)a<<1) + b;
}
Result
myfunc():
sub rsp, 8
calltest() <-- Result is b<<8 | a
add rsp, 8
movzx edx, al <--- moves a
movzx eax, ah <--- extends b into itself
movzx eax, al <--- Huh?
lea eax, [rax+rdx*2]
ret
[Bug fortran/103259] [11/12/13 Regression] ICE in resolve_common_vars, at fortran/resolve.c:956 since r11-3866-g4d2a56a0f7135469
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103259 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #9 from anlauf at gcc dot gnu.org --- Fixed on all affected branches. Closing. Thanks for the report, and to Steve for the fix!
[Bug fortran/103259] [11/12/13 Regression] ICE in resolve_common_vars, at fortran/resolve.c:956 since r11-3866-g4d2a56a0f7135469
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103259 --- Comment #8 from CVS Commits --- The releases/gcc-11 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:0f1bc8f39c46223897d13d23fefcd456da91b203 commit r11-10517-g0f1bc8f39c46223897d13d23fefcd456da91b203 Author: Steve Kargl Date: Tue Feb 7 20:18:42 2023 +0100 Fortran: error handling of global entity appearing in COMMON block [PR103259] gcc/fortran/ChangeLog: PR fortran/103259 * resolve.c (resolve_common_vars): Avoid NULL pointer dereference when a symbol's location is not set. gcc/testsuite/ChangeLog: PR fortran/103259 * gfortran.dg/pr103259.f90: New test. (cherry picked from commit 7e9f20f5517429cfaadec14d6b04705e59078565)
[Bug fortran/108609] New test case gfortran.dg/pr108527.f90 in r13-5479-g22afa4947584c7 ICEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108609 --- Comment #5 from CVS Commits --- The releases/gcc-11 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:f4efceac1741c03bc3c86f95e4bcd8918ec8ebe6 commit r11-10515-gf4efceac1741c03bc3c86f95e4bcd8918ec8ebe6 Author: Harald Anlauf Date: Wed Feb 1 21:01:32 2023 +0100 Fortran: error recovery on invalid array section [PR108609] The testcase for PR108527 uncovered a latent issue with invalid array sections that resulted in different paths being taken on different architectures. Detect the invalid array declaration for a clean recovery. gcc/fortran/ChangeLog: PR fortran/108609 * expr.c (find_array_section): Add check to prevent interpreting an mpz non-integer constant as an integer. gcc/testsuite/ChangeLog: PR fortran/108609 * gfortran.dg/pr108527.f90: Adjust test pattern. (cherry picked from commit 88a2a09dd4529107e7ef7a6e7ce43acf96457173)
[Bug fortran/95107] ICE in hash_operand, at fold-const.c:3768
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95107 --- Comment #13 from CVS Commits --- The releases/gcc-11 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:4eba6812c5652005e0e9dc62358a6fb3bda193e6 commit r11-10516-g4eba6812c5652005e0e9dc62358a6fb3bda193e6 Author: Harald Anlauf Date: Mon Feb 6 20:59:51 2023 +0100 Fortran: ASSOCIATE variables should not be TREE_STATIC [PR95107] gcc/fortran/ChangeLog: PR fortran/95107 * trans-decl.c (gfc_finish_var_decl): With -fno-automatic, do not make ASSOCIATE variables TREE_STATIC. gcc/testsuite/ChangeLog: PR fortran/95107 * gfortran.dg/save_7.f90: New test. (cherry picked from commit c36f3da534e7f411c5bc48c5b6b660e238167480)
[Bug fortran/108527] [13 Regression] ICE in compare_bound_int(): Bad expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108527 --- Comment #11 from CVS Commits --- The releases/gcc-11 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:c01a495d96f7e9e07b16f62c3476c5242d66aeeb commit r11-10514-gc01a495d96f7e9e07b16f62c3476c5242d66aeeb Author: Harald Anlauf Date: Tue Jan 24 22:36:25 2023 +0100 Fortran: fix ICE in compare_bound_int [PR108527] gcc/fortran/ChangeLog: PR fortran/108527 * resolve.c (compare_bound_int): Expression to compare must be of type INTEGER. (compare_bound_mpz_t): Likewise. (check_dimension): Fix comment on checks applied to array section and clean up associated logic. gcc/testsuite/ChangeLog: PR fortran/108527 * gfortran.dg/pr108527.f90: New test. Co-authored-by: Steven G. Kargl (cherry picked from commit 22afa4947584c701633a79fd8750c9ceeaa96711)
[Bug c++/91846] [10/11/12/13 Regression] ICE in use_thunk, at cp/method.c:316
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91846 Marek Polacek changed: What|Removed |Added CC||ramir.sultano at ya dot ru --- Comment #6 from Marek Polacek --- *** Bug 108755 has been marked as a duplicate of this bug. ***
[Bug c++/108755] ICE in use_thunk at cp/method.cc:317
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108755 Marek Polacek changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- Yeah, I think they're duplicates. *** This bug has been marked as a duplicate of bug 91846 ***
[Bug c++/108755] New: ICE in use_thunk at cp/method.cc:317
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108755
Bug ID: 108755
Summary: ICE in use_thunk at cp/method.cc:317
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ramir.sultano at ya dot ru
Target Milestone: ---
gcc version 12.2.1 20230111 (GCC)
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++,d --enable-bootstrap
--prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--with-build-config=bootstrap-lto --with-linker-hash-style=gnu
--with-system-zlib --enable-__cxa_atexit --enable-cet=auto
--enable-checking=release --enable-clocale=gnu --enable-default-pie
--enable-default-ssp --enable-gnu-indirect-function --enable-gnu-unique-object
--enable-libstdcxx-backtrace --enable-link-serialization=1
--enable-linker-build-id --enable-lto --enable-multilib --enable-plugin
--enable-shared --enable-threads=posix --disable-libssp --disable-libstdcxx-pch
--disable-werror
The complete command line that triggers the bug: g++ main.cxx
The compiler output (error messages, warnings, etc.):
main.cxx: In instantiation of ‘constexpr X AB::b() const [with X = bool]’:
main.cxx:21:23: required from here
main.cxx:14:49: internal compiler error: in use_thunk, at cp/method.cc:317
14 | constexpr X b() const override { return {}; };
| ^
0x19e2ee8 internal_error(char const*, ...)
???:0
0x65443c fancy_abort(char const*, int, char const*)
???:0
0x813cb0 emit_associated_thunks(tree_node*)
???:0
0x7db493 instantiate_decl(tree_node*, bool, bool)
???:0
0x6a7b96 maybe_constant_value(tree_node*, tree_node*, bool)
???:0
0x84a9ba cp_build_binary_op(op_location_t const&, tree_code, tree_node*,
tree_node*, int)
???:0
0x69acb2 build_new_op(op_location_t const&, tree_code, int, tree_node*,
tree_node*, tree_node*, tree_node*, tree_node**, int)
???:0
0x852fbb build_x_binary_op(op_location_t const&, tree_code, tree_node*,
tree_code, tree_node*, tree_code, tree_node*, tree_node**, int)
???:0
0x7c7d9c c_parse_file()
???:0
0x8dd47d c_common_parse_file()
???:0
The preprocessed file (*.i*) that triggers the bug, generated by adding
-save-temps to the complete compilation command:
template
struct A {
constexpr virtual X a() const = 0;
};
template
struct B {
constexpr virtual X b() const = 0;
};
template
struct AB : public A, public B {
constexpr X a() const override { return {}; };
constexpr X b() const override { return {}; };
};
int main() {
using x_type = bool;
constexpr AB ab{};
static_assert(ab.a() == x_type{});
static_assert(ab.b() == x_type{});
return 0;
}
Notes:
possible duplicate of
[91846](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91846)
[Bug c++/106675] [10/11/12/13 Regression] g++ crashes on funky operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106675 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org
[Bug testsuite/106120] [13 regression] g++.dg/warn/Wstringop-overflow-4.C fails since r13-1268-g8c99e307b20c50
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106120 --- Comment #8 from seurer at gcc dot gnu.org --- Yes, in the test run I just did it worked.
[Bug testsuite/106120] [13 regression] g++.dg/warn/Wstringop-overflow-4.C fails since r13-1268-g8c99e307b20c50
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106120 --- Comment #7 from Hans-Peter Nilsson --- Can the reporter please affirm that the issue is now solved (ppc64 m32 BE)? It is for cris-elf, but it wouldn't be right closing someone elses bug-report.
[Bug ipa/108605] [13 Regression] ICE in ipa_push_agg_values_from_jfunc with offsets >= INT_MAX since r13-3359-g656b2338c8f248
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108605 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- Created attachment 54451 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54451&action=edit gcc13-pr108605.patch Untested fix.
[Bug tree-optimization/108692] [11 Regression] Miscompilation of orc_test.c since r11-5160
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108692 Jakub Jelinek changed: What|Removed |Added Summary|[11/12 Regression] |[11 Regression] |Miscompilation of |Miscompilation of |orc_test.c since r11-5160 |orc_test.c since r11-5160 --- Comment #7 from Jakub Jelinek --- Fixed for gcc 12.3 too.
[Bug c++/108607] [12 Regression] ICE in potential_constant_expression_1, at cp/constexpr.cc:10003
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108607 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Jakub Jelinek --- Fixed for gcc 12.3 too.
[Bug target/108599] [12 Regression] Incorrect code generation newer intel architectures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108599 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #13 from Jakub Jelinek --- Fixed for gcc 12.3 too.
[Bug rtl-optimization/108596] [10/11 Regression] error: EDGE_CROSSING missing across section boundary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108596 Jakub Jelinek changed: What|Removed |Added Summary|[10/11/12 Regression] |[10/11 Regression] error: |error: EDGE_CROSSING|EDGE_CROSSING missing |missing across section |across section boundary |boundary| --- Comment #9 from Jakub Jelinek --- Fixed for gcc 12.3 too.
[Bug tree-optimization/108498] [11 Regression] ppc64 big endian generates uninitialized reads with -fstore-merging
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108498 Jakub Jelinek changed: What|Removed |Added Summary|[11/12 Regression] ppc64|[11 Regression] ppc64 big |big endian generates|endian generates |uninitialized reads with|uninitialized reads with |-fstore-merging |-fstore-merging --- Comment #28 from Jakub Jelinek --- Fixed for gcc 12.3 too.
[Bug c++/108365] [10/11 Regression] Wrong code with -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108365 Jakub Jelinek changed: What|Removed |Added Summary|[9/10/11/12 Regression] |[10/11 Regression] Wrong |Wrong code with -O0 |code with -O0 --- Comment #10 from Jakub Jelinek --- Fixed for gcc 12.3 too.
[Bug c++/108286] [12 Regression] OpenMP Target directive causes internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108286 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Jakub Jelinek --- Fixed for gcc 12.3 too.
[Bug middle-end/108264] [11 Regression] ICE compiling guacamole-server on s390x-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108264 Jakub Jelinek changed: What|Removed |Added Summary|[11/12 Regression] ICE |[11 Regression] ICE |compiling guacamole-server |compiling guacamole-server |on s390x-linux |on s390x-linux --- Comment #6 from Jakub Jelinek --- Fixed for gcc 12.3 too.
[Bug c++/108206] [12 Regression] ICE: tree check: expected tree that contains 'decl minimal' structure, have 'error_mark' in merge_default_template_args, at cp/decl.cc:1563 since r12-7562-gfe548eb8436
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108206 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Jakub Jelinek --- Fixed for gcc 12.3 too.
[Bug tree-optimization/103035] [meta-bug] YARPGen bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103035 Bug 103035 depends on bug 108166, which changed state. Bug 108166 Summary: [12 Regression] Wrong code with -O2 since r12-8078-ga42aa68bf1ad745a https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108166 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/108166] [12 Regression] Wrong code with -O2 since r12-8078-ga42aa68bf1ad745a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108166 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Jakub Jelinek --- Fixed for gcc 12.3 too.
[Bug tree-optimization/108068] [10/11 Regression] decimal floating point signed zero is not honored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108068 Jakub Jelinek changed: What|Removed |Added Summary|[10/11/12 Regression] |[10/11 Regression] decimal |decimal floating point |floating point signed zero |signed zero is not honored |is not honored --- Comment #14 from Jakub Jelinek --- Fixed for gcc 12.3 too.
[Bug tree-optimization/107997] [10/11/12/13 Regression] r13-4389-gfd8dd6c0384969 probably uncovered an issue building the Linux kernel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107997 --- Comment #14 from Jakub Jelinek --- Fixed for gcc 12.3 too.
[Bug middle-end/107317] [10/11 Regression] ICE in emit_redzone_byte, at asan.cc:1508
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107317 Jakub Jelinek changed: What|Removed |Added Summary|[10/11/12 Regression] ICE |[10/11 Regression] ICE in |in emit_redzone_byte, at|emit_redzone_byte, at |asan.cc:1508|asan.cc:1508 --- Comment #9 from Jakub Jelinek --- Fixed for gcc 12.3 too.
[Bug c/107127] [11 Regression] Long compile times on code with C complex since r11-3299-gcba079f354a55363
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107127 Jakub Jelinek changed: What|Removed |Added Summary|[11/12 Regression] Long |[11 Regression] Long |compile times on code with |compile times on code with |C complex since |C complex since |r11-3299-gcba079f354a55363 |r11-3299-gcba079f354a55363 --- Comment #11 from Jakub Jelinek --- Fixed for gcc 12.3 too.
[Bug target/106875] [11 Regression] ICE in ix86_emit_outlined_ms2sysv_save with -mabi=ms -mcall-ms2sysv-xlogues and "#pragma GCC target" since r11-3183-gba948b37768c99cd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106875 Jakub Jelinek changed: What|Removed |Added Summary|[11/12 Regression] ICE in |[11 Regression] ICE in |ix86_emit_outlined_ms2sysv_ |ix86_emit_outlined_ms2sysv_ |save with -mabi=ms |save with -mabi=ms |-mcall-ms2sysv-xlogues and |-mcall-ms2sysv-xlogues and |"#pragma GCC target" since |"#pragma GCC target" since |r11-3183-gba948b37768c99cd |r11-3183-gba948b37768c99cd --- Comment #6 from Jakub Jelinek --- Fixed for gcc 12.3 too.
[Bug rtl-optimization/106751] [10/11 Regression] internal compiler error: in purge_dead_edges with inline-asm goto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106751 Jakub Jelinek changed: What|Removed |Added Summary|[10/11/12 Regression] |[10/11 Regression] internal |internal compiler error: in |compiler error: in |purge_dead_edges with |purge_dead_edges with |inline-asm goto |inline-asm goto --- Comment #15 from Jakub Jelinek --- Fixed for gcc 12.3 too.
[Bug debug/106719] [10/11 Regression] '-fcompare-debug' failure w/ -O2 since r10-6038-ge5e07b68187b9a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106719 Jakub Jelinek changed: What|Removed |Added Summary|[10/11/12 Regression] |[10/11 Regression] |'-fcompare-debug' failure |'-fcompare-debug' failure |w/ -O2 since|w/ -O2 since |r10-6038-ge5e07b68187b9a|r10-6038-ge5e07b68187b9a --- Comment #7 from Jakub Jelinek --- Fixed for gcc 12.3 too.
[Bug middle-end/102633] [11/12 Regression] warning for self-initialization despite -Wno-init-self
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102633 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #12 from Jakub Jelinek --- Fixed for gcc 12.3 too.
[Bug tree-optimization/106523] [10/11 Regression] forwprop miscompile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106523 Jakub Jelinek changed: What|Removed |Added Summary|[10/11/12 Regression] |[10/11 Regression] forwprop |forwprop miscompile |miscompile --- Comment #10 from Jakub Jelinek --- Fixed for gcc 12.3 too.
[Bug c/105972] [12 Regression] ICE in lower_stmt, at gimple-low.cc:312 since r12-4608-gb4702276615ff8d4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105972 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #9 from Jakub Jelinek --- Fixed for gcc 12.3 too.
[Bug c++/53932] [10/11 Regression] C++ reference variable to member of anonymous union in global is error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53932 Jakub Jelinek changed: What|Removed |Added Summary|[10/11/12 Regression] C++ |[10/11 Regression] C++ |reference variable to |reference variable to |member of anonymous union |member of anonymous union |in global is error |in global is error --- Comment #14 from Jakub Jelinek --- Fixed for gcc 12.3 too.
[Bug middle-end/108754] [13 Regression] multiple testsuite errors with r13-5761-g10827a92f1a8c3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108754 --- Comment #7 from Hans-Peter Nilsson --- Oh, already committed. Still testing, FWIW.
[Bug tree-optimization/88739] [7 Regression] Big-endian union bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739 --- Comment #65 from CVS Commits --- The releases/gcc-12 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:a5453c659bce698d80f5aebdab5ab0eba39b1ed6 commit r12-9153-ga5453c659bce698d80f5aebdab5ab0eba39b1ed6 Author: Andrew Pinski Date: Thu Feb 9 16:03:54 2023 +0100 match.pd: When simplifying BFR of an insert, require a mode precision integral type [PR108688] The same problem as PR 88739 has crept in but this time in match.pd when simplifying bit_field_ref of an bit_insert. That is we are generating a BIT_FIELD_REF of a non-mode-precision integral type. PR tree-optimization/108688 * match.pd (bit_field_ref [bit_insert]): Avoid generating BIT_FIELD_REFs of non-mode-precision integral operands. * gcc.c-torture/compile/pr108688-1.c: New test. (cherry picked from commit 44f308e59bfa0f93ae05b17e257d8563c12399fd)
[Bug c++/108474] static structured binding undefined reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108474
--- Comment #4 from CVS Commits ---
The releases/gcc-12 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:c153fb6a5bda225fcfb34e17994a31b65616a6db
commit r12-9159-gc153fb6a5bda225fcfb34e17994a31b65616a6db
Author: Jakub Jelinek
Date: Tue Jan 24 11:28:00 2023 +0100
c++: Handle structured bindings like anon unions in initializers [PR108474]
As reported by Andrew Pinski, structured bindings (with the exception
of the ones using std::tuple_{size,element} and get which are really
standalone variables in addition to the binding one) also use
DECL_VALUE_EXPR and needs the same treatment in static initializers.
On Sun, Jan 22, 2023 at 07:19:07PM -0500, Jason Merrill wrote:
> Though, actually, why not instead fix expand_expr_real_1 (and staticp) to
> look through DECL_VALUE_EXPR?
Doing it when emitting the initializers seems to be too late to me,
we in various spots try to put parts of the static var DECL_INITIAL
expressions
into the IL, or e.g. for varpool purposes remember which vars are
referenced
there.
This patch moves it to record_reference, which is called from
varpool_node::analyze
and so about the same time as gimplification of the bodies which also
replaces DECL_VALUE_EXPRs.
2023-01-24 Jakub Jelinek
PR c++/108474
* cp-gimplify.cc (cp_fold_r): Handle structured bindings
vars like anon union artificial vars.
* g++.dg/cpp1z/decomp57.C: New test.
* g++.dg/cpp1z/decomp58.C: New test.
(cherry picked from commit b84e21115700523b4d0ac44275443f7b9c670344)
[Bug middle-end/108435] [13 Regression] ICE in as_a, at is-a.h:242 since r13-142-g705bcedf6eae2d7c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108435
--- Comment #8 from CVS Commits ---
The releases/gcc-12 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:8e74c4389ce242b571cc182b19e88b7c08656145
commit r12-9150-g8e74c4389ce242b571cc182b19e88b7c08656145
Author: Jakub Jelinek
Date: Thu Feb 2 09:54:18 2023 +0100
nested, openmp: Wrap OMP_CLAUSE_*_GIMPLE_SEQ into GIMPLE_BIND for
declare_vars [PR108435]
When gimplifying OMP_CLAUSE_{LASTPRIVATE,LINEAR}_STMT, we wrap it always
into a GIMPLE_BIND, but when putting statements directly into
OMP_CLAUSE_{LASTPRIVATE,LINEAR}_GIMPLE_SEQ, we do it only if needed (there
are any temporaries that need to be declared in the sequence).
convert_nonlocal_omp_clauses was relying on the GIMPLE_BIND to be there
always
because it called declare_vars on it.
The following patch wraps it into GIMPLE_BIND in tree-nested if we need to
declare_vars on it on demand.
2023-02-02 Jakub Jelinek
PR middle-end/108435
* tree-nested.cc (convert_nonlocal_omp_clauses)
: If info->new_local_var_chain and
*seq
is not a GIMPLE_BIND, wrap the sequence into a new GIMPLE_BIND
before calling declare_vars.
(convert_nonlocal_omp_clauses) : Merge
with the OMP_CLAUSE_LASTPRIVATE handling except for whether
seq is initialized to &OMP_CLAUSE_LASTPRIVATE_GIMPLE_SEQ (clause)
or &OMP_CLAUSE_LINEAR_GIMPLE_SEQ (clause).
* gcc.dg/gomp/pr108435.c: New test.
(cherry picked from commit 0f349928e16fdc7dba52561e8d40347909f9f0ff)
[Bug libstdc++/107468] std::from_chars doesn't always round to nearest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107468 --- Comment #6 from CVS Commits --- The releases/gcc-12 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:0061c84d2d85ca4c2ceca6116937f2d1fab6e10a commit r12-9154-g0061c84d2d85ca4c2ceca6116937f2d1fab6e10a Author: Jakub Jelinek Date: Mon Nov 7 15:17:21 2022 +0100 libstdc++: Update from latest fast_float [PR107468] The following patch partially updates from fast_float trunk. That way it gets fix for the incorrect rounding case, PR107468 aka https://github.com/fastfloat/fast_float/issues/149 Using std::fegetround showed in benchmarks too slow, so instead of doing that the patch limits the fast path where it uses floating point multiplication rather than integral to cases where we can prove there will be no rounding (the multiplication will be exact, not just that the two multiplication or division operation arguments are exactly representable). 2022-11-07 Jakub Jelinek PR libstdc++/107468 * src/c++17/fast_float/fast_float.h: Partial merge from fast_float 662497742fea7055f0e0ee27e5a7ddc382c2c38e commit. * testsuite/20_util/from_chars/pr107468.cc: New test. (cherry picked from commit cb0ceeaee9e041aaac3edd089b07b439621d0f29)
[Bug other/108560] builtin_va_arg_pack_len is documented to return size_t, but actually returns int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108560 --- Comment #5 from CVS Commits --- The releases/gcc-12 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:ca1e81324ab9915b745e724945db4a108777f46d commit r12-9145-gca1e81324ab9915b745e724945db4a108777f46d Author: Jakub Jelinek Date: Fri Jan 27 11:17:35 2023 +0100 doc: Fix up return type of __builtin_va_arg_pack_len [PR108560] __builtin_va_arg_pack_len as implemented returned int since its introduction in 2007. The initial documentation didn't mention any return type, which changed in 2010 in r0-103077-gab940b73bfabe2cec4 during some documentation formatting cleanups https://gcc.gnu.org/legacy-ml/gcc-patches/2010-09/msg01632.html I can understand that for formatting some type was needed there but what exactly hasn't been really discussed. So, I think we should change documentation to match the implementation, rather than change implementation to match the documentation. Most people don't use more than 2147483647 arguments to inline functions, and on poor targets with 16-bit ints I bet even having more than 65535 arguments to inline functions would be highly unexpected. 2023-01-27 Jakub Jelinek PR other/108560 * doc/extend.texi: Fix up return type of __builtin_va_arg_pack_len from size_t to int. (cherry picked from commit 16f30680f403891556da2ad6329fcef9dc9b47db)
[Bug tree-optimization/108688] [13 Regression] error: ‘bit_field_ref’ of non-mode-precision operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108688 --- Comment #13 from CVS Commits --- The releases/gcc-12 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:a5453c659bce698d80f5aebdab5ab0eba39b1ed6 commit r12-9153-ga5453c659bce698d80f5aebdab5ab0eba39b1ed6 Author: Andrew Pinski Date: Thu Feb 9 16:03:54 2023 +0100 match.pd: When simplifying BFR of an insert, require a mode precision integral type [PR108688] The same problem as PR 88739 has crept in but this time in match.pd when simplifying bit_field_ref of an bit_insert. That is we are generating a BIT_FIELD_REF of a non-mode-precision integral type. PR tree-optimization/108688 * match.pd (bit_field_ref [bit_insert]): Avoid generating BIT_FIELD_REFs of non-mode-precision integral operands. * gcc.c-torture/compile/pr108688-1.c: New test. (cherry picked from commit 44f308e59bfa0f93ae05b17e257d8563c12399fd)
[Bug c++/105593] avx512 math function raises uninitialized variable warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105593 --- Comment #29 from CVS Commits --- The releases/gcc-12 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:732d744e82332e7cc269694197c0df2a3635730f commit r12-9161-g732d744e82332e7cc269694197c0df2a3635730f Author: Jakub Jelinek Date: Mon Jan 16 09:40:14 2023 +0100 c, c++: Allow ignoring -Winit-self through pragmas [PR105593] As mentioned in the PR, various x86 intrinsics need to return an uninitialized vector. Currently they use self initialization to avoid -Wuninitialized warnings, which works fine in C, but doesn't work in C++ where -Winit-self is enabled in -Wall. We don't have an attribute to mark a variable as knowingly uninitialized (the uninitialized attribute exists but means something else, only in the -ftrivial-auto-var-init context), and trying to suppress either -Wuninitialized or -Winit-self inside of the _mm_undefined_ps etc. intrinsic definitions doesn't work, one needs to currently disable through pragmas -Wuninitialized warning at the point where _mm_undefined_ps etc. result is actually used, but that goes against the intent of those intrinsics. The -Winit-self warning option actually doesn't do any warning, all we do is record a suppression for -Winit-self if !warn_init_self on the decl definition and later look that up in uninit pass. The following patch changes those !warn_init_self tests which are true only based on the command line option setting, not based on GCC diagnostic pragma overrides to !warning_enabled_at (DECL_SOURCE_LOCATION (decl), OPT_Winit_self) such that it takes them into account. 2023-01-16 Jakub Jelinek PR c++/105593 gcc/c/ * c-parser.cc (c_parser_initializer): Check warning_enabled_at at the DECL_SOURCE_LOCATION (decl) for OPT_Winit_self instead of warn_init_self. gcc/cp/ * decl.cc (cp_finish_decl): Check warning_enabled_at at the DECL_SOURCE_LOCATION (decl) for OPT_Winit_self instead of warn_init_self. gcc/testsuite/ * c-c++-common/Winit-self3.c: New test. * c-c++-common/Winit-self4.c: New test. * c-c++-common/Winit-self5.c: New test. (cherry picked from commit 98b41fd4045b7856e7b85dd58d67c600bd909379)
[Bug c++/105593] avx512 math function raises uninitialized variable warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105593 --- Comment #31 from CVS Commits --- The releases/gcc-12 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:c3ba6680492ee1ddef6ae8493787c36c45c2d20e commit r12-9163-gc3ba6680492ee1ddef6ae8493787c36c45c2d20e Author: Jakub Jelinek Date: Tue Jan 31 09:20:34 2023 +0100 i386: Fix up -Wuninitialized warnings in avx512erintrin.h [PR105593] As reported in the PR, there are some -Wuninitialized warnings in avx512erintrin.h. One can see that by compiling sse-23.c testcase with -Wuninitialized (or when actually using those intrinsics). Those 6 spots use an uninitialized variable and pass it as one of the argument to a builtin with constant mask -1, because there is no unmasked builtin. It is true that expansion of those builtins into RTL will see mask is all ones and ignore the unneeded argument, but -Wuninitialized is diagnosed on GIMPLE and on GIMPLE these builtins are just builtin calls. avx512fintrin.h and other headers use in these cases the _mm*_undefined_* () intrinsics, like: return (__m512i) __builtin_ia32_psrav8di_mask ((__v8di) __X, (__v8di) __Y, (__v8di) _mm512_undefined_epi32 (), (__mmask8) -1); etc. and the following patch does the same for avx512erintrin.h. With the recent changes in C++ FE and the _mm*_undefined_* intrinsics, we don't emit -Wuninitialized warnings for those (previously we didn't just in C due to self-initialization). Of course we could also just self-initialize these uninitialized vars and add the #pragma GCC diagnostic dances around it, but using the intrinsics is consistent with the rest and IMHO cleaner. 2023-01-31 Jakub Jelinek PR c++/105593 * config/i386/avx512erintrin.h (_mm512_exp2a23_round_pd, _mm512_exp2a23_round_ps, _mm512_rcp28_round_pd, _mm512_rcp28_round_ps, _mm512_rsqrt28_round_pd, _mm512_rsqrt28_round_ps): Use _mm512_undefined_pd () or _mm512_undefined_ps () instead of using uninitialized automatic variable __W. * gcc.target/i386/sse-23.c: Add -Wuninitialized to dg-options. (cherry picked from commit 41602390456901c14ecdfa2fa64c3cebd5b6ff09)
[Bug c++/53932] [10/11/12 Regression] C++ reference variable to member of anonymous union in global is error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53932 --- Comment #13 from CVS Commits --- The releases/gcc-12 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:d4eca31c521f54a3066f9940fbf09e28b53eff8c commit r12-9142-gd4eca31c521f54a3066f9940fbf09e28b53eff8c Author: Jakub Jelinek Date: Thu Jan 19 23:27:34 2023 +0100 c++: Fix up handling of references to anon union members in initializers [PR53932] For anonymous union members we create artificial VAR_DECLs which have DECL_VALUE_EXPR for the actual COMPONENT_REF. That works just fine inside of functions (including global dynamic constructors), because during gimplification such VAR_DECLs are gimplified as their DECL_VALUE_EXPR. This is also done during regimplification. But references to these artificial vars in DECL_INITIAL expressions aren't ever replaced by the DECL_VALUE_EXPRs, so we end up either with link failures like on the testcase below, or worse ICEs with LTO. The following patch fixes those during cp_fully_fold_init where we already walk all the trees (!data->genericize means that function rather than cp_fold_function). 2023-01-19 Jakub Jelinek PR c++/53932 * cp-gimplify.cc (cp_fold_r): During cp_fully_fold_init replace DECL_ANON_UNION_VAR_P VAR_DECLs with their corresponding DECL_VALUE_EXPR. * g++.dg/init/pr53932.C: New test. (cherry picked from commit 9b9a989adc042b304572fd6d4ade46b47be6ccb8)
[Bug c++/108365] [9/10/11/12 Regression] Wrong code with -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108365
--- Comment #9 from CVS Commits ---
The releases/gcc-12 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:369454ecb53a2911946356b09347259c953f435f
commit r12-9156-g369454ecb53a2911946356b09347259c953f435f
Author: Jakub Jelinek
Date: Sat Jan 14 10:17:14 2023 +0100
c++: Avoid incorrect shortening of divisions [PR108365]
The following testcase is miscompiled, because we shorten the division
in a case where it should not be shortened.
Divisions (and modulos) can be shortened if it is unsigned division/modulo,
or if it is signed division/modulo where we can prove the dividend will
not be the minimum signed value or divisor will not be -1, because e.g.
on sizeof(long long)==sizeof(int)*2 && __INT_MAX__ == 0x7fff targets
(-2147483647 - 1) / -1 is UB
but
(int) (-2147483648LL / -1LL) is not, it is -2147483648.
The primary aim of both the C and C++ FE division/modulo shortening I
assume
was for the implicit integral promotions of {,signed,unsigned} {char,short}
and because at this point we have no VRP information etc., the shortening
is done if the integral promotion is from unsigned type for the divisor
or if the dividend is an integer constant other than -1.
This works fine for char/short -> int promotions when char/short have
smaller precision than int - unsigned char -> int or unsigned short -> int
will always be a positive int, so never the most negative.
Now, the C FE checks whether orig_op0 is TYPE_UNSIGNED where op0 is either
the same as orig_op0 or that promoted to int, I think that works fine,
if it isn't promoted, either the division/modulo common type will have the
same precision as op0 but then the division/modulo is unsigned and so
without UB, or it will be done in wider precision (e.g. because op1 has
wider precision), but then op0 can't be minimum signed value. Or it has
been promoted to int, but in that case it was again from narrower type and
so never minimum signed int.
But the C++ FE was checking if op0 is a NOP_EXPR from TYPE_UNSIGNED.
First of all, not sure if the operand of NOP_EXPR couldn't be non-integral
type where TYPE_UNSIGNED wouldn't be meaningful, but more importantly,
even if it is a cast from unsigned integral type, we only know it can't be
minimum signed value if it is a widening cast, if it is same precision or
narrowing cast, we know nothing.
So, the following patch for the NOP_EXPR cases checks just in case that
it is from integral type and more importantly checks it is a widening
conversion.
2023-01-14 Jakub Jelinek
PR c++/108365
* typeck.cc (cp_build_binary_op): For integral division or modulo,
shorten if type0 is unsigned, or op0 is cast from narrower unsigned
integral type or stripped_op1 is INTEGER_CST other than -1.
* g++.dg/opt/pr108365.C: New test.
* g++.dg/warn/pr108365.C: New test.
(cherry picked from commit 5b3a88640f962d4ffca31ae651bed2d8672f1a8c)
[Bug bootstrap/90543] Build failure on MINGW for gcc-9.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90543 --- Comment #16 from CVS Commits --- The releases/gcc-12 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:db09666c7a014a86693bebcf4e8487f40937f999 commit r12-9143-gdb09666c7a014a86693bebcf4e8487f40937f999 Author: Eric Biggers Date: Tue Jan 24 11:54:41 2023 +0100 options: fix cl_target_option_print_diff() with strings Fix an obvious copy-and-paste error where ptr1 was used instead of ptr2. This bug caused the dump file produced by -fdump-ipa-inline-details to not correctly show the difference in target options when a function could not be inlined due to a target option mismatch. gcc/ChangeLog: PR bootstrap/90543 * optc-save-gen.awk: Fix copy-and-paste error. Signed-off-by: Eric Biggers (cherry picked from commit 9f0cb3368af735e95776769c4f28fa9cbb60eaf8)
[Bug c++/105593] avx512 math function raises uninitialized variable warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105593 --- Comment #30 from CVS Commits --- The releases/gcc-12 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:72af61b122127b112215d496d65c64cfdc56fce8 commit r12-9162-g72af61b122127b112215d496d65c64cfdc56fce8 Author: Jakub Jelinek Date: Mon Jan 16 09:41:38 2023 +0100 x86: Avoid -Wuninitialized warnings on _mm*_undefined_* in C++ [PR105593] In https://gcc.gnu.org/pipermail/gcc-patches/2023-January/609844.html I've posted a patch to allow ignoring -Winit-self using GCC diagnostic pragmas, such that one can mark self-initialization as intentional disabling of -Wuninitialized warnings. The following incremental patch uses that in the x86 intrinsic headers. 2023-01-16 Jakub Jelinek PR c++/105593 gcc/ * config/i386/xmmintrin.h (_mm_undefined_ps): Temporarily disable -Winit-self using pragma GCC diagnostic ignored. * config/i386/emmintrin.h (_mm_undefined_pd, _mm_undefined_si128): Likewise. * config/i386/avxintrin.h (_mm256_undefined_pd, _mm256_undefined_ps, _mm256_undefined_si256): Likewise. * config/i386/avx512fintrin.h (_mm512_undefined_pd, _mm512_undefined_ps, _mm512_undefined_epi32): Likewise. * config/i386/avx512fp16intrin.h (_mm_undefined_ph, _mm256_undefined_ph, _mm512_undefined_ph): Likewise. gcc/testsuite/ * g++.target/i386/pr105593.C: New test. (cherry picked from commit 6b0907b4fc455377e5f8109f427d97da02b6aec9)
[Bug middle-end/108459] [OpenMP] ICE during GIMPLE pass: ompexp (segfault) in expand_omp_for_init_counts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108459 --- Comment #8 from CVS Commits --- The releases/gcc-12 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:629907bff87e238d45afe609716880e8acf9e541 commit r12-9141-g629907bff87e238d45afe609716880e8acf9e541 Author: Jakub Jelinek Date: Thu Jan 19 21:00:08 2023 +0100 openmp: Fix up OpenMP expansion of non-rectangular loops [PR108459] expand_omp_for_init_counts was using for the case where collapse(2) inner loop has init expression dependent on non-constant multiple of the outer iterator and the condition upper bound expression doesn't depend on the outer iterator fold_unary (NEGATE_EXPR, ...). This will just return NULL if it can't be folded, we need fold_build1 instead. 2023-01-19 Jakub Jelinek PR middle-end/108459 * omp-expand.cc (expand_omp_for_init_counts): Use fold_build1 rather than fold_unary for NEGATE_EXPR. * testsuite/libgomp.c/pr108459.c: New test. (cherry picked from commit 46644ec99cb355845b23bb1d02775c057ed8ee88)
[Bug middle-end/108237] [13 Regression] ICE: in gimple_expand_vec_cond_expr, at gimple-isel.cc:281 at -O since r13-1085-g90467f0ad649d081
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108237
--- Comment #9 from CVS Commits ---
The releases/gcc-12 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:4c8e17a6a578b9eb15cd210651b6ea273022db39
commit r12-9136-g4c8e17a6a578b9eb15cd210651b6ea273022db39
Author: Jakub Jelinek
Date: Wed Jan 4 10:54:38 2023 +0100
generic-match-head: Don't assume GENERIC folding is done only early
[PR108237]
We ICE on the following testcase, because a valid V2DImode
!= comparison is folded into an unsupported V2DImode > comparison.
The match.pd pattern which does this looks like:
/* Transform comparisons of the form (X & Y) CMP 0 to X CMP2 Z
where ~Y + 1 == pow2 and Z = ~Y. */
(for cst (VECTOR_CST INTEGER_CST)
(for cmp (eq ne)
icmp (le gt)
(simplify
(cmp (bit_and:c@2 @0 cst@1) integer_zerop)
(with { tree csts = bitmask_inv_cst_vector_p (@1); }
(if (csts && (VECTOR_TYPE_P (TREE_TYPE (@1)) || single_use (@2)))
(with { auto optab = VECTOR_TYPE_P (TREE_TYPE (@1))
? optab_vector : optab_default;
tree utype = unsigned_type_for (TREE_TYPE (@1)); }
(if (target_supports_op_p (utype, icmp, optab)
|| (optimize_vectors_before_lowering_p ()
&& (!target_supports_op_p (type, cmp, optab)
|| !target_supports_op_p (type, BIT_AND_EXPR, optab
(if (TYPE_UNSIGNED (TREE_TYPE (@1)))
(icmp @0 { csts; })
(icmp (view_convert:utype @0) { csts; })
and that optimize_vectors_before_lowering_p () guarded stuff there
already deals with this problem, not trying to fold a supported comparison
into a non-supported one. The reason it doesn't work in this case is that
it isn't GIMPLE folding which does this, but GENERIC folding done during
forwprop4 - forward_propagate_into_comparison ->
forward_propagate_into_comparison_1
-> combine_cond_expr_cond -> fold_binary_loc -> generic_simplify
and we simply assumed that GENERIC folding happens only before
gimplification.
The following patch fixes that by checking cfun properties instead of
always returning true in those cases.
2023-01-04 Jakub Jelinek
PR middle-end/108237
* generic-match-head.cc: Include tree-pass.h.
(canonicalize_math_p, optimize_vectors_before_lowering_p): Define
to false if cfun and cfun->curr_properties has PROP_gimple_opt_math
resp. PROP_gimple_lvec property set.
* gcc.c-torture/compile/pr108237.c: New test.
(cherry picked from commit 345dffd0d4ebff7e705dfff1a8a72017a167120a)
[Bug fortran/108451] [13 Regression] ICE in check_complete_insertion, at hash-table.h:578
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108451 --- Comment #7 from CVS Commits --- The releases/gcc-12 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:f2731d1b9a52a7c97af9bbb6ea76603630cc11c2 commit r12-9151-gf2731d1b9a52a7c97af9bbb6ea76603630cc11c2 Author: Jakub Jelinek Date: Fri Feb 3 21:37:27 2023 +0100 fortran: Fix up hash table usage in gfc_trans_use_stmts [PR108451] The first testcase in the PR (which I haven't included in the patch because it is unclear to me if it is supposed to be valid or not) ICEs since extra hash table checking has been added recently. The problem is that gfc_trans_use_stmts does tree *slot = entry->decls->find_slot_with_hash (rent->use_name, hash, INSERT); if (*slot == NULL) and later on doesn't store anything into *slot and continues. Another spot a few lines later correctly clears the slot if it decides not to use the slot, so the following patch does the same. 2023-02-03 Jakub Jelinek PR fortran/108451 * trans-decl.cc (gfc_trans_use_stmts): Call clear_slot before doing continue. (cherry picked from commit 76f7f0eddcb7c418d1ec3dea3e2341ca99097301)
[Bug middle-end/102633] [11/12 Regression] warning for self-initialization despite -Wno-init-self
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102633 --- Comment #11 from CVS Commits --- The releases/gcc-12 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:aabebf76e9d9a805ea5b443d4ee4f49f13155d87 commit r12-9160-gaabebf76e9d9a805ea5b443d4ee4f49f13155d87 Author: Marek Polacek Date: Tue Jul 26 13:55:58 2022 -0400 c-family: Honor -Wno-init-self for cv-qual vars [PR102633] Since r11-5188-g32934a4f45a721, we drop qualifiers during l-to-r conversion by creating a NOP_EXPR. For e.g. const int i = i; that means that the DECL_INITIAL is '(int) i' and not 'i' anymore. Consequently, we don't suppress_warning here: 711 case DECL_EXPR: 715 if (VAR_P (DECL_EXPR_DECL (*expr_p)) 716 && !DECL_EXTERNAL (DECL_EXPR_DECL (*expr_p)) 717 && !TREE_STATIC (DECL_EXPR_DECL (*expr_p)) 718 && (DECL_INITIAL (DECL_EXPR_DECL (*expr_p)) == DECL_EXPR_DECL (*expr_p)) 719 && !warn_init_self) 720 suppress_warning (DECL_EXPR_DECL (*expr_p), OPT_Winit_self); because of the check on line 718 -- (int) i is not i. So -Wno-init-self doesn't disable the warning as it's supposed to. The following patch fixes it by moving the suppress_warning call from c_gimplify_expr to the front ends, at points where we haven't created the NOP_EXPR yet. PR middle-end/102633 gcc/c-family/ChangeLog: * c-gimplify.cc (c_gimplify_expr) : Don't call suppress_warning here. gcc/c/ChangeLog: * c-parser.cc (c_parser_initializer): Add new tree parameter. Use it. Call suppress_warning. (c_parser_declaration_or_fndef): Pass d down to c_parser_initializer. (c_parser_omp_declare_reduction): Pass omp_priv down to c_parser_initializer. gcc/cp/ChangeLog: * decl.cc (cp_finish_decl): Call suppress_warning. gcc/testsuite/ChangeLog: * c-c++-common/Winit-self1.c: New test. * c-c++-common/Winit-self2.c: New test. (cherry picked from commit 04ce2400b35225302e0d6883bb0817378180f5d7)
[Bug tree-optimization/108166] [12 Regression] Wrong code with -O2 since r12-8078-ga42aa68bf1ad745a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108166 --- Comment #10 from CVS Commits --- The releases/gcc-12 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:86d252ab555d487aefb616562e770ffa46e05b01 commit r12-9133-g86d252ab555d487aefb616562e770ffa46e05b01 Author: Jakub Jelinek Date: Thu Dec 22 12:52:48 2022 +0100 phiopt: Drop SSA_NAME_RANGE_INFO in maybe equal case [PR108166] The following place in value_replacement is after proving that x == cst1 ? cst2 : x phi result is only used in a comparison with constant which doesn't care if it compares cst1 or cst2 and replaces it with x. The testcase is miscompiled because we have after the replacement incorrect range info for the phi result, we would need to effectively union the phi result range with cst1 (oarg in the code) because previously that constant might be missing in the range, but newly it can appear (we've just verified that the single use stmt of the phi result doesn't care about that value in particular). The following patch just resets the info, bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? Aldy/Andrew, how would one instead union the SSA_NAME_RANGE_INFO with some INTEGER_CST and store it back into SSA_NAME_RANGE_INFO (including adjusting non-zero bits and the like)? 2022-12-22 Jakub Jelinek PR tree-optimization/108166 * tree-ssa-phiopt.cc (value_replacement): For the maybe_equal_p case turned into equal_p reset SSA_NAME_RANGE_INFO of phi result. * g++.dg/torture/pr108166.C: New test. (cherry picked from commit 5c17adfb5d08e34da7a7f234dfc2ed1f0aaadaa9)
[Bug middle-end/108264] [11/12 Regression] ICE compiling guacamole-server on s390x-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108264 --- Comment #5 from CVS Commits --- The releases/gcc-12 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:ee25e54233c6a1548eda06aa9a11f09cd7eb32ac commit r12-9135-gee25e54233c6a1548eda06aa9a11f09cd7eb32ac Author: Jakub Jelinek Date: Tue Jan 3 12:13:24 2023 +0100 expr: Fix up store_expr into SUBREG_PROMOTED_* target [PR108264] The following testcase ICEs on s390x-linux (e.g. with -march=z13). The problem is that target is (subreg/s/u:SI (reg/v:DI 66 [ x+-4 ]) 4) and we call convert_move from temp to the SUBREG_REG of that, expecting to extend the value properly. That works nicely if temp has some scalar integer mode (or partial one), but ICEs when temp has V4QImode on the assertion that from and to modes have the same bitsize. store_expr generally allows say store from V4QI to SI target because they have the same size and if temp is a CONST_INT, we already have code to convert the constant properly, so the following patch just adds handling of non-scalar integer modes by converting them to the mode of target first before convert_move extends them. 2023-01-03 Jakub Jelinek PR middle-end/108264 * expr.cc (store_expr): For stores into SUBREG_PROMOTED_* targets from source which doesn't have scalar integral mode first convert it to outer_mode. * gcc.dg/pr108264.c: New test. (cherry picked from commit 226a498733e7919de72eb6f1bf3e16883ad159f6)
[Bug debug/108573] [13 Regression] '-fcompare-debug' failure (length) at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108573 --- Comment #6 from CVS Commits --- The releases/gcc-12 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:7bd8b65bd5d51a33f31ec39dfb435b84e36260e9 commit r12-9149-g7bd8b65bd5d51a33f31ec39dfb435b84e36260e9 Author: Jakub Jelinek Date: Wed Feb 1 12:52:52 2023 +0100 ree: Fix -fcompare-debug issues in combine_reaching_defs [PR108573] The PR78437 r7-4871 changes made combine_reaching_defs punt on WORD_REGISTER_OPERATIONS targets if a setter of smaller than word register has wider uses. This unfortunately breaks -fcompare-debug, because if such a use appears only in DEBUG_INSN(s), while all other uses aren't wider than the setter, we can REE optimize it without -g and not with -g. Such decisions shouldn't be based on debug instructions. We could try to reset them or adjust in some other way after we decide to perform the change, but at least on the testcase which used to fail on riscv64-linux the (debug_insn 8 7 9 2 (var_location:HI s (minus:HI (subreg:HI (and:DI (reg:DI 10 a0 [160]) (const_int 1 [0x1])) 0) (subreg:HI (ashiftrt:DI (reg/v:DI 9 s1 [orig:151 l ] [151]) (debug_expr:SI D#1)) 0))) "pr108573.c":12:5 -1 (nil)) clearly doesn't care about the upper bits and I have hard time imaging how could one end up with DEBUG_INSN which actually cares about those upper bits. So, the following patch just ignores uses on DEBUG_INSNs in this case, if we run into something where we'd need to do something further later on, let's deal with it when we have a testcase for it. 2023-02-01 Jakub Jelinek PR debug/108573 * ree.cc (combine_reaching_defs): Don't return false for paradoxical subregs in DEBUG_INSNs. * gcc.dg/pr108573.c: New test. (cherry picked from commit e4473d7cf871c8ddf8f22d105c5af6375ebe37bf)
[Bug tree-optimization/108440] rotate optimization may introduce new UB
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108440 --- Comment #10 from CVS Commits --- The releases/gcc-12 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:a015ebe382cd6d0beab9db4ad33fbd252b7e2339 commit r12-9158-ga015ebe382cd6d0beab9db4ad33fbd252b7e2339 Author: Jakub Jelinek Date: Thu Jan 19 10:00:51 2023 +0100 forwprop: Further fixes for simplify_rotate [PR108440] As mentioned in the simplify_rotate comment, for e.g. ((T) ((T2) X << (Y & (B - 1 | ((T) ((T2) X >> ((-Y) & (B - 1 we already emit X r<< (Y & (B - 1)) as replacement. This PR is about the ((T) ((T2) X << Y)) OP ((T) ((T2) X >> (B - Y))) ((T) ((T2) X << (int) Y)) OP ((T) ((T2) X >> (int) (B - Y))) forms if T2 is wider than T. Unlike e.g. (X << Y) OP (X >> (B - Y)) which is valid just for Y in [1, B - 1], the above 2 forms are actually valid and do the rotates for Y in [0, B] - for Y 0 the X value is preserved by the left shift and right logical shift by B adds just zeros (but because the shift is in wider precision B is still valid shift count), while for Y equal to B X is preserved through the latter shift and the former adds just zeros. Now, it is unclear if we in the middle-end treat rotates with rotate count equal or larger than precision as UB or not, unlike shifts there are less reasons to do so, but e.g. expansion of X r<< Y if there is no rotate optab for the mode is emitted as (X << Y) | (((unsigned) X) >> ((-Y) & (B - 1))) and so with UB on Y == B. The following patch does multiple things: 1) for the above 2, asks the ranger if Y could be equal to B and if so, instead of using X r<< Y uses X r<< (Y & (B - 1)) 2) for the ((T) ((T2) X << Y)) | ((T) ((T2) X >> ((-Y) & (B - 1 ((T) ((T2) X << (int) Y)) | ((T) ((T2) X >> (int) ((-Y) & (B - 1 forms that were fixed 2 days ago it only punts if Y might be in the [B,B2-1] range but isn't known to be in the [0,B][2*B,2*B][3*B,3*B]... range. Because for Y which is a multiple of B but smaller than B2 it acts as a rotate too, left shift provides 0 and (-Y) & (B - 1) is 0 and so preserves X. Though, for the cases where Y is not known to be in [0,B-1] the patch also uses X r<< (Y & (B - 1)) rather than X r<< Y 3) as discussed with Aldy, instead of using global ranger it uses a pass specific copy but lazily created on first simplify_rotate that needs it; this e.g. handles rotate inside of if body where the guarding condition limits the shift count to some range which will not work with the global ranger (unless there is some SSA_NAME to attach the range to). Note, e.g. on x86 X r<< (Y & (B - 1)) and X r<< Y actually emit the same assembly because rotates work the same even for larger rotate counts, but that is handled only during combine. 2023-01-19 Jakub Jelinek PR tree-optimization/108440 * tree-ssa-forwprop.cc: Include gimple-range.h. (simplify_rotate): For the forms with T2 wider than T and shift counts of Y and B - Y add & (B - 1) masking for the rotate count if Y could be equal to B. For the forms with T2 wider than T and shift counts of Y and (-Y) & (B - 1), don't punt if range could be [B, B2], but only if range doesn't guarantee Y < B or Y = N * B. If range doesn't guarantee Y < B, also add & (B - 1) masking for the rotate count. Use lazily created pass specific ranger instead of get_global_range_query. (pass_forwprop::execute): Disable that ranger at the end of pass if it has been created. * c-c++-common/rotate-10.c: New test. * c-c++-common/rotate-11.c: New test. (cherry picked from commit 05b9868b182bb9ed2013b39a0bc6297354a0db49)
[Bug c++/108180] [OpenMP] Passing a class member variable to firstprivate() erroneously calls its dtor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108180 --- Comment #4 from CVS Commits --- The releases/gcc-12 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:c4b8949a3ad0a2259388841f3c833876a19bd2a2 commit r12-9131-gc4b8949a3ad0a2259388841f3c833876a19bd2a2 Author: Jakub Jelinek Date: Wed Dec 21 09:05:27 2022 +0100 openmp: Don't try to destruct DECL_OMP_PRIVATIZED_MEMBER vars [PR108180] DECL_OMP_PRIVATIZED_MEMBER vars are artificial vars with DECL_VALUE_EXPR of this->field used just during gimplification and omp lowering/expansion to privatize individual fields in methods when needed. As the following testcase shows, when not in templates, they were handled right, but in templates we actually called cp_finish_decl on them and that can result in their destruction, which is obviously undesirable, we should only destruct the privatized copies of them created in omp lowering. Fixed thusly. 2022-12-21 Jakub Jelinek PR c++/108180 * pt.cc (tsubst_expr): Don't call cp_finish_decl on DECL_OMP_PRIVATIZED_MEMBER vars. * testsuite/libgomp.c++/pr108180.C: New test. (cherry picked from commit 1119902b6c7c1c50123ed85ec1def8be4772d68c)
[Bug tree-optimization/106523] [10/11/12 Regression] forwprop miscompile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106523
--- Comment #9 from CVS Commits ---
The releases/gcc-12 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:a558a4d3d1b488783b96dff7141d12e02ded3ad3
commit r12-9157-ga558a4d3d1b488783b96dff7141d12e02ded3ad3
Author: Jakub Jelinek
Date: Tue Jan 17 12:14:25 2023 +0100
forwprop: Fix up rotate pattern matching [PR106523]
The comment above simplify_rotate roughly describes what patterns
are matched into what:
We are looking for X with unsigned type T with bitsize B, OP being
+, | or ^, some type T2 wider than T. For:
(X << CNT1) OP (X >> CNT2) iff CNT1 + CNT2 ==
B
((T) ((T2) X << CNT1)) OP ((T) ((T2) X >> CNT2)) iff CNT1 + CNT2 ==
B
transform these into:
X r<< CNT1
Or for:
(X << Y) OP (X >> (B - Y))
(X << (int) Y) OP (X >> (int) (B - Y))
((T) ((T2) X << Y)) OP ((T) ((T2) X >> (B - Y)))
((T) ((T2) X << (int) Y)) OP ((T) ((T2) X >> (int) (B - Y)))
(X << Y) | (X >> ((-Y) & (B - 1)))
(X << (int) Y) | (X >> (int) ((-Y) & (B - 1)))
((T) ((T2) X << Y)) | ((T) ((T2) X >> ((-Y) & (B - 1
((T) ((T2) X << (int) Y)) | ((T) ((T2) X >> (int) ((-Y) & (B - 1
transform these into (last 2 only if ranger can prove Y < B):
X r<< Y
Or for:
(X << (Y & (B - 1))) | (X >> ((-Y) & (B - 1)))
(X << (int) (Y & (B - 1))) | (X >> (int) ((-Y) & (B - 1)))
((T) ((T2) X << (Y & (B - 1 | ((T) ((T2) X >> ((-Y) & (B - 1
((T) ((T2) X << (int) (Y & (B - 1 \
| ((T) ((T2) X >> (int) ((-Y) & (B - 1
transform these into:
X r<< (Y & (B - 1))
The following testcase shows that 2 of these are problematic.
If T2 is wider than T, then the 2 which yse (-Y) & (B - 1) on one
of the shift counts but Y on the can do something different from
rotate. E.g.:
__attribute__((noipa)) unsigned char
f7 (unsigned char x, unsigned int y)
{
unsigned int t = x;
return (t << y) | (t >> ((-y) & 7));
}
if y is [0, 7], then it is a normal rotate, and if y is in [32, ~0U]
then it is UB, but for y in [9, 31] the left shift in this case
will never leave any bits in the result, while in a rotate they are
left there. Say for y 5 and x 0xaa the expression gives
0x55 which is the same thing as rotate, while for y 19 and x 0xaa
0x5, which is different.
Now, I believe the
((T) ((T2) X << Y)) OP ((T) ((T2) X >> (B - Y)))
((T) ((T2) X << (int) Y)) OP ((T) ((T2) X >> (int) (B - Y)))
forms are ok, because B - Y still needs to be a valid shift count,
and if Y > B then B - Y should be either negative or very large
positive (for unsigned types).
And similarly the last 2 cases above which use & (B - 1) on both
shift operands are definitely ok.
The following patch disables the
((T) ((T2) X << Y)) | ((T) ((T2) X >> ((-Y) & (B - 1
((T) ((T2) X << (int) Y)) | ((T) ((T2) X >> (int) ((-Y) & (B - 1
unless ranger says Y is not in [B, B2 - 1] range.
And, looking at it again this morning, actually the Y equal to B
case is still fine, if Y is equal to 0, then it is
(T) (((T2) X << 0) | ((T2) X >> 0))
and so X, for Y == B it is
(T) (((T2) X << B) | ((T2) X >> 0))
which is the same as
(T) (0 | ((T2) X >> 0))
which is also X. So instead of the [B, B2 - 1] range we could use
[B + 1, B2 - 1]. And, if we wanted to go further, even multiplies
of B are ok if they are smaller than B2, so we could construct a detailed
int_range_max if we wanted.
2023-01-17 Jakub Jelinek
PR tree-optimization/106523
* tree-ssa-forwprop.cc (simplify_rotate): For the
patterns with (-Y) & (B - 1) in one operand's shift
count and Y in another, if T2 has wider precision than T,
punt if Y could have a value in [B, B2 - 1] range.
* c-c++-common/rotate-2.c (f5, f6, f7, f8, f13, f14, f15, f16,
f37, f38, f39, f40, f45, f46, f47, f48): Add assertions using
__builtin_unreachable about shift count.
* c-c++-common/rotate-2b.c: New test.
* c-c++-common/rotate-4.c (f5, f6, f7, f8, f13, f14, f15, f16,
f37, f38, f39, f40, f45, f46, f47, f48): Add assertions using
__builtin_unreachable about shift count.
* c-c++-common/rotate-4b.c: New test.
* gcc.c-torture/execute/pr106523.c: New test.
(cherry picked from commit 001121e8921d5d1a439ce0e64ab04c5959b0bfd8)
[Bug rtl-optimization/108193] [13 Regression] ICE in do_SUBST, at combine.cc:700
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108193 --- Comment #4 from CVS Commits --- The releases/gcc-12 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:cb8022eab6d076325495360da632321078326135 commit r12-9132-gcb8022eab6d076325495360da632321078326135 Author: Jakub Jelinek Date: Thu Dec 22 12:44:13 2022 +0100 cse: Fix up CSE const_anchor handling [PR108193] The following testcase ICEs on aarch64, because insert_const_anchor inserts invalid CONST_INT into the CSE tables - 0x8000 for SImode. The second hunk of the patch fixes that, the first one is to avoid triggering undefined behavior at compile time during compute_const_anchors computations - performing those additions and subtractions in HOST_WIDE_INT means it can overflow for certain constants. 2022-12-22 Jakub Jelinek PR rtl-optimization/108193 * cse.cc (compute_const_anchors): Change n type to unsigned HOST_WIDE_INT, adjust comparison against it to avoid warnings. Formatting fix. (insert_const_anchor): Use gen_int_mode instead of GEN_INT. * gfortran.dg/pr108193.f90: New test. (cherry picked from commit 0cb5d7cdbab8e5f8359764ef5f62d93c2bc88552)
[Bug c++/108607] [12 Regression] ICE in potential_constant_expression_1, at cp/constexpr.cc:10003
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108607
--- Comment #4 from CVS Commits ---
The releases/gcc-12 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:a62d952064c896eaf94e70d7999e6e27343babcf
commit r12-9148-ga62d952064c896eaf94e70d7999e6e27343babcf
Author: Jakub Jelinek
Date: Wed Feb 1 10:38:46 2023 +0100
c++, openmp: Handle some OMP_*/OACC_* constructs during constant expression
evaluation [PR108607]
While potential_constant_expression_1 handled most of OMP_* codes (by
saying that
they aren't potential constant expressions), OMP_SCOPE was missing in that
list.
I've also added OMP_SCAN, though that is less important (similarly to
OMP_SECTION
it ought to appear solely inside of OMP_{FOR,SIMD} resp. OMP_SECTIONS).
As the testcase shows, it isn't enough, potential_constant_expression_1
can catch only some cases, as soon as one uses switch or ifs where at least
one of the possible paths could be constant expression, we can run into the
same codes during cxx_eval_constant_expression, so this patch handles those
there as well.
2023-02-01 Jakub Jelinek
PR c++/108607
* constexpr.cc (cxx_eval_constant_expression): Handle OMP_*
and OACC_* constructs as non-constant.
(potential_constant_expression_1): Handle OMP_SCAN and OMP_SCOPE.
* g++.dg/gomp/pr108607.C: New test.
(cherry picked from commit bfc070595bfb00abef88a002eee5d9117f5b86a7)
[Bug testsuite/108151] gcc.dg/pr64536.c stores pointers in a long, broken for llp64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108151 --- Comment #5 from CVS Commits --- The releases/gcc-12 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:4430147d3779d8f089d8eb765b4c7e0333279424 commit r12-9129-g4430147d3779d8f089d8eb765b4c7e0333279424 Author: Jakub Jelinek Date: Mon Dec 19 13:49:52 2022 +0100 testsuite: Fix up pr64536.c for LLP64 targets [PR108151] The test casts a pointer to long, which is ok for ilp32 and lp64 targets but not for llp64 targets. Nothing reads the values later, it is a link test, so all we care about is that it is the same cast on s390x-linux where it used to fail before the PR64536 fix, and that we don't warn about it. 2022-12-19 Jakub Jelinek PR testsuite/108151 * gcc.dg/pr64536.c (bar): Use casts to __INTPTR_TYPE__ rather than long when casting pointer to integral type. (cherry picked from commit ea37e96a37b50dad17b91d46edc518bbb9132d8e)
[Bug testsuite/108151] gcc.dg/pr64536.c stores pointers in a long, broken for llp64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108151 --- Comment #6 from CVS Commits --- The releases/gcc-12 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:e4f6149fe272101af6de3a19be4e41d0e77e7f6c commit r12-9130-ge4f6149fe272101af6de3a19be4e41d0e77e7f6c Author: Jakub Jelinek Date: Mon Dec 19 15:05:16 2022 +0100 testsuite: Fix up pr64536.c for LLP64 targets [PR108151] Apparently llp64 had 2 further warnings, fixed thusly. 2022-12-19 Jakub Jelinek PR testsuite/108151 * gcc.dg/pr64536.c (bar): Cast long to __INTPTR_TYPE__ before casting to long *. (cherry picked from commit 6e85f89a7d59a99a3395b6e153b99262a58b2f6c)
[Bug tree-optimization/108498] [11/12 Regression] ppc64 big endian generates uninitialized reads with -fstore-merging
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108498 --- Comment #27 from CVS Commits --- The releases/gcc-12 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:671b7c29dd666cb74dfe5ab01b501d6a0ca7b41c commit r12-9144-g671b7c29dd666cb74dfe5ab01b501d6a0ca7b41c Author: Jakub Jelinek Date: Wed Jan 25 10:50:27 2023 +0100 store-merging: Disable string_concatenate mode if start or end aren't byte aligned [PR108498] The first of the following testcases is miscompiled on powerpc64-linux -O2 -m64 at least, the latter at least on x86_64-linux -m32/-m64. Since GCC 11 store-merging has a separate string_concatenation mode which turns stores into setting a MEM_REF from a STRING_CST. This mode is triggered if at least one of the to be merged stores is a STRING_CST store and either the first store (to earliest address) is that STRING_CST store or the first store is 8-bit INTEGER_CST store and then there are some rules when to turn that mode off or not merge further stores into it. The problem with these 2 testcases is that the actual implementation relies on start/width of the store to be at byte boundaries, as it simply creates a char array, MEM_REF can be only on byte boundaries and the char array too, plus obviously STRING_CST as well. But as can be easily seen in the second testcase, nothing verifies this, while the first store has to be a STRING_CST (which will be aligned) or 8-bit INTEGER_CST, that 8-bit INTEGER_CST store could be a bitfield store, nothing verifies any stores in between whether they actually are 8-bit and aligned, the only major requirement is that all the stores are consecutive. For GCC 14 I think we should reconsider this, simply treat STRING_CST stores during the merging like INTEGER_CST stores and deal with it only during split_group where we can create multiple parts, this part would be a normal store, this part would be STRING_CST store, this part another normal store etc. But that is quite a lot of work, the following patch just disables the string_concatenate mode if boundaries aren't byte aligned in the spot where we disable it if it is too short too. If that happens, we'll just try to do the merging using normal 1/2/4/8 etc. byte stores as usually with RMW masking for any bits that shouldn't be touched or punt if we end up with too many stores compared to the original. Note, an original STRING_CST store will count as one store in that case, something we might want to reconsider later too (but, after all, CONSTRUCTOR stores (aka zeroing) already have the same problem, they can be large and expensive and we still count them as one store). 2023-01-25 Jakub Jelinek PR tree-optimization/108498 * gimple-ssa-store-merging.cc (class store_operand_info): End coment with full stop rather than comma. (split_group): Likewise. (merged_store_group::apply_stores): Clear string_concatenation if start or end aren't on a byte boundary. * gcc.c-torture/execute/pr108498-1.c: New test. * gcc.c-torture/execute/pr108498-2.c: New test. (cherry picked from commit 617be7ba436bcbf9d7b883968c6b3c011206b56c)
[Bug tree-optimization/108692] [11/12 Regression] Miscompilation of orc_test.c since r11-5160
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108692
--- Comment #6 from CVS Commits ---
The releases/gcc-12 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:00136f439e2849af2bfd9934d79a8297ab09a1d9
commit r12-9152-g00136f439e2849af2bfd9934d79a8297ab09a1d9
Author: Jakub Jelinek
Date: Wed Feb 8 18:41:21 2023 +0100
vect-patterns: Fix up vect_widened_op_tree [PR108692]
The following testcase is miscompiled on aarch64-linux since r11-5160.
Given
[local count: 955630225]:
# i_22 = PHI
# r_23 = PHI
...
a.0_5 = (unsigned char) a_15;
_6 = (int) a.0_5;
b.1_7 = (unsigned char) b_17;
_8 = (int) b.1_7;
c_18 = _6 - _8;
_9 = ABS_EXPR ;
r_19 = _9 + r_23;
...
where SSA_NAMEs 15/17 have signed char, 5/7 unsigned char and rest is int
we first pattern recognize c_18 as
patt_34 = (a.0_5) w- (b.1_7);
which is still correct, 5/7 are unsigned char subtracted in wider type,
but then vect_recog_sad_pattern turns it into
SAD_EXPR
which is incorrect, because 15/17 are signed char and so it is
sum of absolute signed differences rather than unsigned sum of
absolute unsigned differences.
The reason why this happens is that vect_recog_sad_pattern calls
vect_widened_op_tree with MINUS_EXPR, WIDEN_MINUS_EXPR on the
patt_34 = (a.0_5) w- (b.1_7); statement's vinfo and vect_widened_op_tree
calls vect_look_through_possible_promotion on the operands of the
WIDEN_MINUS_EXPR, which looks through the further casts.
vect_look_through_possible_promotion has careful code to stop when there
would be nested casts that need to be preserved, but the problem here
is that the WIDEN_*_EXPR operation itself has an implicit cast on the
operands already - in this case of WIDEN_MINUS_EXPR the unsigned char
5/7 SSA_NAMEs are widened to unsigned short before the subtraction,
and vect_look_through_possible_promotion obviously isn't told about that.
Now, I think when we see those WIDEN_{MULT,MINUS,PLUS}_EXPR codes, we had
to look through possible promotions already when creating those and so
vect_look_through_possible_promotion again isn't really needed, all we need
to do is arrange what that function will do if the operand isn't result
of any cast. Other option would be let
vect_look_through_possible_promotion
know about the implicit promotion from the WIDEN_*_EXPR, but I'm afraid
that would be much harder.
2023-02-08 Jakub Jelinek
PR tree-optimization/108692
* tree-vect-patterns.cc (vect_widened_op_tree): If rhs_code is
widened_code which is different from code, don't call
vect_look_through_possible_promotion but instead just check op is
SSA_NAME with integral type for which vect_is_simple_use is true
and call set_op on this_unprom.
* gcc.dg/pr108692.c: New test.
(cherry picked from commit 6ad1c1027628f094260037536f6b6fcdb63b5add)
[Bug c/105972] [12 Regression] ICE in lower_stmt, at gimple-low.cc:312 since r12-4608-gb4702276615ff8d4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105972 --- Comment #8 from CVS Commits --- The releases/gcc-12 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:c2b33b330c16a97627e987c60a6ca35ed0fdea56 commit r12-9140-gc2b33b330c16a97627e987c60a6ca35ed0fdea56 Author: Jakub Jelinek Date: Wed Jan 11 22:18:42 2023 +0100 c: Don't emit DEBUG_BEGIN_STMTs for K&R function argument declarations [PR105972] K&R function parameter declarations are handled by calling recursively c_parser_declaration_or_fndef in a loop, where each such call will add_debug_begin_stmt at the start. Now, if the K&R function definition is not a nested function, building_stmt_list_p () is false and so we don't emit the DEBUG_BEGIN_STMTs anywhere, but if it is a nested function, we emit it in the containing function at the point of the nested function definition. As the following testcase shows, it can cause ICEs if the containing function has var-tracking disabled but nested function has them enabled, as the DEBUG_BEGIN_STMTs are added to the containing function which shouldn't have them but MAY_HAVE_DEBUG_MARKER_STMTS is checked already for the nested function, or just wrong experience in the debugger. The following patch ensures we don't emit any such DEBUG_BEGIN_STMTs for the K&R function parameter declarations even in nested functions. 2023-01-11 Jakub Jelinek PR c/105972 * c-parser.cc (c_parser_declaration_or_fndef): Disable debug non-bind markers for K&R function parameter declarations of nested functions. * gcc.dg/pr105972.c: New test. (cherry picked from commit 23b4ce18379cd336d99d7c71701be28118905b57)
[Bug tree-optimization/107997] [10/11/12/13 Regression] r13-4389-gfd8dd6c0384969 probably uncovered an issue building the Linux kernel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107997 --- Comment #13 from CVS Commits --- The releases/gcc-12 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:89daf0dd6f1748077c03fbeb27ca5980a0b9abd5 commit r12-9125-g89daf0dd6f1748077c03fbeb27ca5980a0b9abd5 Author: Jakub Jelinek Date: Sat Dec 10 16:50:39 2022 +0100 ivopts: Fix IP_END handling for asm goto [PR107997] The following testcase ICEs, because the latch bb ends with asm goto which has both fallthrough to the header and one or more labels in the header too. In that case there is just a single edge out of the latch block, but still the asm goto is stmt_ends_bb_p statement, yet ivopts decides to emit an IV bump at the IP_END position and inserts it into the same bb as the asm goto after it, which then fails verification (control flow in the middle of bb). The following patch fixes it by splitting the latch -> header edge in that case and inserting into the newly created bb, where split_edge -> redirect_edge_and_branch is able to deal with this case correctly. 2022-12-10 Jakub Jelinek PR tree-optimization/107997 * tree-ssa-loop-ivopts.cc: Include cfganal.h. (create_new_iv) : If ip_end_pos bb is non-empty and ends with a stmt which ends bb, instead of adding iv update after it split the latch edge and insert iterator into the new latch bb. * gcc.c-torture/compile/pr107997.c: New test. (cherry picked from commit 7676235f690e624b7ed41a22b22ce8ccfac1492f)
[Bug tree-optimization/108095] powerpc-linux / powerpc64-linux: ICEs when building Linux's arch/powerpc/kernel/align.c (asm goto)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108095
--- Comment #10 from CVS Commits ---
The releases/gcc-12 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:7e54e5a2bba69dc7fcbc88fe8cb20c91aaafabd2
commit r12-9126-g7e54e5a2bba69dc7fcbc88fe8cb20c91aaafabd2
Author: Jakub Jelinek
Date: Thu Dec 15 09:26:44 2022 +0100
into-ssa: Fix emitting debug stmts after asm goto [PR108095]
The following testcase ICEs, because ccp1 replaced
s.0_1 = &s;
__asm__ goto("" : "=r" MEM[(T *)s.0_1] : : : "lab" lab);
with
__asm__ goto("" : "=r" s : : : "lab" lab);
and because s is no longer addressable, we are rewriting it into
ssa and want
__asm__ goto("" : "=r" s_7 : : : "lab" lab);
plus debug stmt
# DEBUG s => s_7
The code assumes that there is at most one non-EH edge in that
case, but with the addition of outputs to asm goto that is no longer the
case, we can have many outgoing edges.
The patch keeps the checking assertion that there is at most one such
edge for everything but asm goto, but moves the addition of the debug
stmt into the loop, so that it can be added on all edges where it is
possible, not just one of them.
Furthermore, looking at gsi_insert_on_edge_immediate
-> gimple_find_edge_insert_loc, the conditions to insert stmt there
to the destination block are
if (single_pred_p (dest)
&& gimple_seq_empty_p (phi_nodes (dest))
&& dest != EXIT_BLOCK_PTR_FOR_FN (cfun))
(plus there is code to insert it in the previous block but that is
never true when the pred is known to be stmt_ends_bb_p), while
mayube_register_def was just checking
if (ef && single_pred_p (ef->dest)
&& ef->dest != EXIT_BLOCK_PTR_FOR_FN (cfun))
so if for whatever reason ef->dest had any PHIs, we'd split the
edge for -g and not for -g0, something we must avoid for -fcompare-debug
stability. So, I've added the no phi_nodes check too.
2022-12-15 Jakub Jelinek
PR tree-optimization/108095
* tree-into-ssa.cc (maybe_register_def): Insert debug stmt
on all non-EH edges from asm goto if they have a single
predecessor rather than asserting there is at most one such edge.
Test whether there are no PHI nodes next to the single predecessor
test.
* gcc.dg/pr108095.c: New test.
(cherry picked from commit bf3ce6f84a7a994a0fc87419b383b9ce4efed442)
[Bug target/108599] [12 Regression] Incorrect code generation newer intel architectures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108599
--- Comment #12 from CVS Commits ---
The releases/gcc-12 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:7d7f275ebe7295264a0406876c0670e25a50169a
commit r12-9147-g7d7f275ebe7295264a0406876c0670e25a50169a
Author: Jakub Jelinek
Date: Tue Jan 31 10:12:19 2023 +0100
i386: Fix up ix86_convert_const_wide_int_to_broadcast [PR108599]
The following testcase is miscompiled. The problem is that during
RTL DSE we see a V4DI register is being loaded { 16, 16, 0, 0 }
value and DSE mostly works in terms of scalar modes, so it calls
movoi to set an OImode REG to (const_wide_int 0x100010)
and ix86_convert_const_wide_int_to_broadcast thinks it can compute
that value by broadcasting DImode 0x10. While it is true that
for TImode result the broadcast could be used, for OImode/XImode
it can't be, because all but the lowest 2 HOST_WIDE_INTs aren't
present (so are 0 or -1 depending on sign), not 0x10 in this case.
The function checks if the least significant HOST_WIDE_INT elt
of the CONST_WIDE_INT is broadcastable from QI/HI/SI/DImode and then
/* Check if OP can be broadcasted from VAL. */
for (int i = 1; i < CONST_WIDE_INT_NUNITS (op); i++)
if (val != CONST_WIDE_INT_ELT (op, i))
return nullptr;
That is needed of course, but nothing checks that
CONST_WIDE_INT_NUNITS (op) isn't too small for the mode in question.
I think if op would be 0 or -1, it ought to be never CONST_WIDE_INT,
but CONST_INT and so we can just punt whenever the number of
CONST_WIDE_INT elts is not the expected one.
2023-01-31 Jakub Jelinek
PR target/108599
* config/i386/i386-expand.cc
(ix86_convert_const_wide_int_to_broadcast): Return nullptr if
CONST_WIDE_INT_NUNITS (op) times HOST_BITS_PER_WIDE_INT isn't
equal to bitsize of mode.
* gcc.target/i386/avx2-pr108599.c: New test.
(cherry picked from commit 963315a922e228c4f685382151fc540f111a)
[Bug fortran/108349] LTO mismatch for __builtin_realloc between glibc and gfortran frontend
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108349
--- Comment #7 from CVS Commits ---
The releases/gcc-12 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:463bf7cfb0b03d9e75754ea8ba89c61186d0982f
commit r12-9139-g463bf7cfb0b03d9e75754ea8ba89c61186d0982f
Author: Jakub Jelinek
Date: Wed Jan 11 10:40:54 2023 +0100
fortran: Fix up function types for realloc and sincos{,f,l} builtins
[PR108349]
As reported in the PR, the FUNCTION_TYPE for __builtin_realloc in the
Fortran FE is wrong since r0-100026-gb64fca63690ad which changed
- tmp = tree_cons (NULL_TREE, pvoid_type_node, void_list_node);
- tmp = tree_cons (NULL_TREE, size_type_node, tmp);
- ftype = build_function_type (pvoid_type_node, tmp);
+ ftype = build_function_type_list (pvoid_type_node,
+size_type_node, pvoid_type_node,
+NULL_TREE);
gfc_define_builtin ("__builtin_realloc", ftype, BUILT_IN_REALLOC,
"realloc", false);
The return type is correct, void *, but the first argument should be
void * too and only second one size_t, while the above change changed
realloc to be void *__builtin_realloc (size_t, void *);
I went through all other changes from that commit and found that
__builtin_sincos{,f,l} got broken as well, instead of the former
void __builtin_sincos{,f,l} (ftype, ftype *, ftype *);
where ftype is {double,float,long double} it is now incorrectly
void __builtin_sincos{,f,l} (ftype *, ftype *);
The following patch fixes that, plus some formatting issues around
the spots I've changed.
2023-01-11 Jakub Jelinek
PR fortran/108349
* f95-lang.cc (gfc_init_builtin_function): Fix up function types
for BUILT_IN_REALLOC and BUILT_IN_SINCOS{F,,L}. Formatting fixes.
(cherry picked from commit 0986c351aa8a9f08b3cb614baec13564dd62c114)
[Bug c++/108286] [12 Regression] OpenMP Target directive causes internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108286 --- Comment #6 from CVS Commits --- The releases/gcc-12 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:5de999df9fa0134a1621b552eb2abd65a6384ffd commit r12-9138-g5de999df9fa0134a1621b552eb2abd65a6384ffd Author: Jakub Jelinek Date: Thu Jan 5 11:57:30 2023 +0100 openmp: Fix up finish_omp_target_clauses [PR108286] The comment in the loop says that we shouldn't add a map clause if such a clause exists already, but the loop was actually using OMP_CLAUSE_DECL on any clause. Target construct can have various clauses which don't have OMP_CLAUSE_DECL at all (e.g. nowait, device or if) or clause where it means something different (e.g. privatization clauses, allocate, depend). So, only check OMP_CLAUSE_DECL on OMP_CLAUSE_MAP clauses. 2023-01-05 Jakub Jelinek PR c++/108286 * semantics.cc (finish_omp_target_clauses): Ignore clauses other than OMP_CLAUSE_MAP. * testsuite/libgomp.c++/pr108286.C: New test. (cherry picked from commit 29c3218618ef6177dc33871b26c8fbd9b21eabe1)
[Bug rtl-optimization/108596] [10/11/12 Regression] error: EDGE_CROSSING missing across section boundary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108596 --- Comment #8 from CVS Commits --- The releases/gcc-12 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:e365bfacf2617403f6bc6aa79a45a27bdba8da36 commit r12-9146-ge365bfacf2617403f6bc6aa79a45a27bdba8da36 Author: Jakub Jelinek Date: Tue Jan 31 09:46:35 2023 +0100 bbpart: Fix up ICE on asm goto [PR108596] On the following testcase we have asm goto in hot block with 2 successors, one cold to which it both falls through and has one of the label pointing to it and another hot successor with another label. Now, during bbpart we want to ensure that no blocks from one partition fall through into a block in a different partition. fix_up_fall_thru_edges does that by temporarily clearing the EDGE_CROSSING on the fallthrough edge, calling force_nonfallthru and then depending on whether it created a new bb either set EDGE_CROSSING on the single successor edge from the new bb (the new bb is kept in the same partition as the predecessor block), or if no new bb has been created setting EDGE_CROSSING back on the fallthru edge which has been forced non-EDGE_FALLTHRU. For asm goto this doesn't always work, force_nonfallthru can create a new bb and change the fallthrough edge to point to that, but if the original fallthru destination block has its label referenced among the asm goto labels, it will create a new non-fallthru edge for the label(s). But because we've temporarily cheated and cleared EDGE_CROSSING on the edge, it is cleared on the new edge as well, then the caller sees we've created a new bb and just sets EDGE_CROSSING on the single fallthru edge from the new bb. But the direct edge from cur_bb to fallthru edge's destination isn't handled and fails afterwards consistency checks, because it crosses partitions. The following patch notes the case and sets EDGE_CROSSING on that edge too. 2023-01-31 Jakub Jelinek PR rtl-optimization/108596 * bb-reorder.cc (fix_up_fall_thru_edges): Handle the case where cur_bb ends with asm goto and has a crossing fallthrough edge to the same bb that contains at least one of its labels by restoring EDGE_CROSSING flag even on possible edge from cur_bb to new_bb successor. * gcc.c-torture/compile/pr108596.c: New test. (cherry picked from commit 603a6fbcaac1e80aa90d1d26318c881a53473066)
[Bug c++/108206] [12 Regression] ICE: tree check: expected tree that contains 'decl minimal' structure, have 'error_mark' in merge_default_template_args, at cp/decl.cc:1563 since r12-7562-gfe548eb8436
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108206
--- Comment #6 from CVS Commits ---
The releases/gcc-12 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:7048e8c1073fcf2bf6be1a3d079393a78864ca61
commit r12-9137-g7048e8c1073fcf2bf6be1a3d079393a78864ca61
Author: Jakub Jelinek
Date: Wed Jan 4 18:42:31 2023 +0100
c++: Error recovery in merge_default_template_args [PR108206]
We ICE on the following testcase during error recovery, both new_parm
and old_parm are error_mark_node, the ICE is on
error ("redefinition of default argument for %q+#D", new_parm);
inform (DECL_SOURCE_LOCATION (old_parm),
"original definition appeared here");
where we don't print anything useful for new_parm and ICE trying to
access DECL_SOURCE_LOCATION of old_parm. I think we shouldn't diagnose
anything when either of the parms is erroneous, GCC 11 before
merge_default_template_args has been added was doing
if (TREE_VEC_ELT (tmpl_parms, i) == error_mark_node
|| TREE_VEC_ELT (parms, i) == error_mark_node)
continue;
tmpl_parm = TREE_VALUE (TREE_VEC_ELT (tmpl_parms, i));
if (error_operand_p (tmpl_parm))
return false;
in redeclare_class_template.
2023-01-04 Jakub Jelinek
PR c++/108206
* decl.cc (merge_default_template_args): Return false if either
new_parm or old_parm are erroneous.
* g++.dg/template/pr108206.C: New test.
(cherry picked from commit fc349931adcf1024ee95e0a0cd98cf4a41996093)
[Bug c++/107065] GCC treats rvalue as an lvalue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107065 --- Comment #16 from CVS Commits --- The releases/gcc-12 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:bc1ee711eeab4b0d55463cd153747d30c69225c7 commit r12-9127-gbc1ee711eeab4b0d55463cd153747d30c69225c7 Author: Jakub Jelinek Date: Thu Dec 15 19:17:45 2022 +0100 c++: Ensure !!var is not an lvalue [PR107065] The TRUTH_NOT_EXPR case in cp_build_unary_op is one of the spots where we somewhat fold immediately using invert_truthvalue_loc. I've tried using return build1_loc (location, TRUTH_NOT_EXPR, boolean_type_node, arg); in there instead, but unfortunately that regressed Wlogical-not-parentheses-*.c pr49706.c pr62199.c pr65120.c sequence-pt-1.C tests, so at least for backporting that doesn't seem to be a way to go. So, this patch instead wraps it into NON_LVALUE_EXPR if needed (which also need a tweak for some tests in the pr47906.c test, but nothing major), with the intent to make it backportable, and later I'll try to do further steps to avoid folding here prematurely. Most of the problems with build1 TRUTH_NOT_EXPR are that it doesn't even invert comparisons as most common case and lots of warning code isn't able to deal with ! around comparisons; so perhaps one way to do this would be fold by hand only invertable comparisons and for the rest create TRUTH_NOT_EXPR. 2022-12-15 Jakub Jelinek PR c++/107065 gcc/cp/ * typeck.cc (cp_build_unary_op) : If invert_truthvalue_loc returns obvalue_p, wrap it into NON_LVALUE_EXPR. * parser.cc (cp_parser_binary_expression): Don't call warn_logical_not_parentheses if current.lhs is a NON_LVALUE_EXPR of a decl with boolean type. gcc/testsuite/ * g++.dg/cpp0x/pr107065.C: New test. (cherry picked from commit 8b775b4c48a3cc4ef5c50e56144aea02da2e9cc6)
[Bug debug/106719] [10/11/12 Regression] '-fcompare-debug' failure w/ -O2 since r10-6038-ge5e07b68187b9a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106719
--- Comment #6 from CVS Commits ---
The releases/gcc-12 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:ed8e7ece850bab599c15db3d43041b70d9e99237
commit r12-9124-ged8e7ece850bab599c15db3d43041b70d9e99237
Author: Jakub Jelinek
Date: Thu Dec 8 14:57:22 2022 +0100
cfgbuild: Fix DEBUG_INSN handling in find_bb_boundaries [PR106719]
The following testcase FAILs on aarch64-linux. We have some atomic
instruction followed by 2 DEBUG_INSNs (if -g only of course) followed
by NOTE_INSN_EPILOGUE_BEG followed by some USE insn.
Now, split3 pass replaces the atomic instruction with a code sequence
which ends with a conditional jump and the split3 pass calls
find_many_sub_basic_blocks.
For -g0, find_bb_boundaries sees the flow_transfer_insn (the new
conditional
jump), then NOTE_INSN_EPILOGUE_BEG which can live in between basic blocks
and then the USE insn, so splits block after the NOTE_INSN_EPILOGUE_BEG
and puts the NOTE in between the blocks.
For -g, if sees a DEBUG_INSN after the flow_transfer_insn, so sets
debug_insn to it, then walks over another DEBUG_INSN,
NOTE_INSN_EPILOGUE_BEG
until it finally sees the USE insn, and triggers the:
rtx_insn *prev = PREV_INSN (insn);
/* If the first non-debug inside_basic_block_p insn after a
control
flow transfer is not a label, split the block before the debug
insn instead of before the non-debug insn, so that the debug
insns are not lost. */
if (debug_insn && code != CODE_LABEL && code != BARRIER)
prev = PREV_INSN (debug_insn);
code I've added for PR81325. If there are only DEBUG_INSNs, that is
the right thing to do, but if in between debug_insn and insn there are
notes which can stay in between basic blocks or simnilarly JUMP_TABLE_DATA
or their associated CODE_LABELs, it causes -fcompare-debug differences.
The following patch fixes it by clearing debug_insn if JUMP_TABLE_DATA
or associated CODE_LABEL is seen (I'm afraid there is no good answer
what to do with DEBUG_INSNs before those; the code then removes them:
/* Clean up the bb field for the insns between the blocks.
*/
for (x = NEXT_INSN (flow_transfer_insn);
x != BB_HEAD (fallthru->dest);
x = next)
{
next = NEXT_INSN (x);
/* Debug insns should not be in between basic blocks,
drop them on the floor. */
if (DEBUG_INSN_P (x))
delete_insn (x);
else if (!BARRIER_P (x))
set_block_for_insn (x, NULL);
}
but if there are NOTEs, the patch just reorders the NOTEs and DEBUG_INSNs,
such that the NOTEs come first (so that they stay in between basic blocks
like with -g0) and DEBUG_INSNs after those (so that bb is split before
them, so they will be in the basic block after NOTE_INSN_BASIC_BLOCK).
2022-12-08 Jakub Jelinek
PR debug/106719
* cfgbuild.cc (find_bb_boundaries): If there are NOTEs in between
debug_insn (seen after flow_transfer_insn) and insn, move NOTEs
before all the DEBUG_INSNs and split after NOTEs. If there are
other insns like jump table data, clear debug_insn.
* gcc.dg/pr106719.c: New test.
(cherry picked from commit d9f9d5d30feb33c359955d7030cc6be50ef6dc0a)
[Bug tree-optimization/108068] [10/11/12 Regression] decimal floating point signed zero is not honored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108068 --- Comment #13 from CVS Commits --- The releases/gcc-12 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:29ac1dcd36901a094f7d698bbe244489a58e2715 commit r12-9134-g29ac1dcd36901a094f7d698bbe244489a58e2715 Author: Jakub Jelinek Date: Fri Dec 23 16:12:21 2022 +0100 tree-ssa-dom: can_infer_simple_equiv fixes [PR108068] As reported in the PR, tree-ssa-dom.cc uses real_zerop call to find if a floating point constant is zero and it shouldn't try to infer equivalences from comparison against it if signed zeros are honored. This doesn't work at all for decimal types, because real_zerop always returns false for them (one can have different representations of decimal zero beyond -0/+0), and it doesn't work for vector compares either, as real_zerop checks if all elements are zero, while we need to avoid infering equivalences from comparison against vector constants which have at least one zero element in it (if signed zeros are honored). Furthermore, as mentioned by Joseph, for decimal types many other values aren't singleton. So, this patch stops infering anything if element mode is decimal, and otherwise uses instead of real_zerop a new function, real_maybe_zerop, which will work even for decimal types and for complex or vector will return true if any element is or might be zero (so it returns true for anything but constants for now). 2022-12-23 Jakub Jelinek PR tree-optimization/108068 * tree.h (real_maybe_zerop): Declare. * tree.cc (real_maybe_zerop): Define. * tree-ssa-dom.cc (record_edge_info): Use it instead of real_zerop or TREE_CODE (op1) == SSA_NAME || real_zerop. Always set can_infer_simple_equiv to false for decimal floating point types. * gcc.dg/dfp/pr108068.c: New test. (cherry picked from commit fd1b0aefda5b65f3f841ca6e61ccea6a72daa060)
[Bug rtl-optimization/106751] [10/11/12 Regression] internal compiler error: in purge_dead_edges with inline-asm goto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106751 --- Comment #14 from CVS Commits --- The releases/gcc-12 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:4db6e1bf2f1647521dcd709bc3673f565fc327a5 commit r12-9128-g4db6e1bf2f1647521dcd709bc3673f565fc327a5 Author: Jakub Jelinek Date: Fri Dec 16 10:19:22 2022 +0100 loop-invariant: Split preheader edge if the preheader bb ends with jump [PR106751] The RTL loop passes only request simple preheaders, but don't require fallthru preheaders, while move_invariant_reg apparently assumes the latter, that it can just append instruction(s) to the end of the preheader basic block. The following patch fixes that by splitting the preheader edge if the preheader bb ends with a JUMP_INSN (asm goto in this case). Without that we get control flow in the middle of a bb. 2022-12-16 Jakub Jelinek PR rtl-optimization/106751 * loop-invariant.cc (move_invariant_reg): If preheader bb ends with a JUMP_INSN, split the preheader edge and emit invariants into the new preheader basic block. * gcc.c-torture/compile/pr106751.c: New test. (cherry picked from commit ddcaa60983b50378bde1b7e327086fe0ce101795)
[Bug middle-end/107317] [10/11/12 Regression] ICE in emit_redzone_byte, at asan.cc:1508
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107317 --- Comment #8 from CVS Commits --- The releases/gcc-12 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:ff185dd96ac4576e722b39fc0f7026281de06eb2 commit r12-9122-gff185dd96ac4576e722b39fc0f7026281de06eb2 Author: Jakub Jelinek Date: Thu Nov 24 11:29:54 2022 +0100 asan: Fix up error recovery for too large frames [PR107317] asan_emit_stack_protection and functions it calls have various asserts that verify sanity of the stack protection instrumentation. But, that verification can easily fail if we've diagnosed a frame offset overflow. asan_emit_stack_protection just emits some extra code in the prologue, if we've reported errors, we aren't producing assembly, so it doesn't really matter if we don't include the protection code, compilation is going to fail anyway. 2022-11-24 Jakub Jelinek PR middle-end/107317 * asan.cc: Include diagnostic-core.h. (asan_emit_stack_protection): Return NULL early if seen_error (). * gcc.dg/asan/pr107317.c: New test. (cherry picked from commit b6330a7685476fc30b8ae9bbf3fca1a9b0d4be95)
[Bug c/107127] [11/12 Regression] Long compile times on code with C complex since r11-3299-gcba079f354a55363
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107127
--- Comment #10 from CVS Commits ---
The releases/gcc-12 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:80010acd052ca7fe544740144756cf9fc2fad629
commit r12-9121-g80010acd052ca7fe544740144756cf9fc2fad629
Author: Jakub Jelinek
Date: Thu Nov 24 10:33:00 2022 +0100
testsuite: Fix up broken testcase [PR107127]
I've added { dg-options "" } line manually in the patch but
forgot to adjust the number of added lines.
2022-11-24 Jakub Jelinek
PR c/107127
* gcc.dg/pr107127.c (foo): Add missing closing }.
(cherry picked from commit add0f941be18cdf962a0f300019acacbf2325d41)
