[Bug tree-optimization/103204] [11/12 Regression] ICE: in vn_reference_insert_pieces, at tree-ssa-sccvn.c:3842 (on -O2 and above)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103204 --- Comment #2 from Andrew Pinski --- I suspect the patch which fixed PR 100923 caused this one but I could be wrong.
[Bug tree-optimization/103192] [12 Regression] ICE on libgomp target-in-reduction-2.{C,c}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103192 --- Comment #3 from Aldy Hernandez --- (In reply to Jakub Jelinek from comment #1) > Seems to have started with r12-4790-g4b3a325f07acebf47e82de227ce1d5ba62f5bcae Huh. I wonder what happened. I never saw these regressions in my testing. Will take a look.
[Bug c++/68613] initializer-string for array of chars is too long error on flexible array member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68613 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |6.0
[Bug c++/69338] incorrect ctor initialization of a flexible array member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69338 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |9.0
[Bug c++/84462] internal compiler error: in output_constructor_regular_field when creating array of structs (with testcase)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84462 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |8.0 Keywords||ice-on-invalid-code See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=68613 Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Andrew Pinski --- GCC 8+ gives: :28:1: error: initialization of flexible array member in a nested context GCC 5 (and before) gave: :28:1: error: initializer-string for array of chars is too long [-fpermissive] }; Dup of bug 80135. *** This bug has been marked as a duplicate of bug 80135 ***
[Bug c++/80135] [7 Regression] ICE in output_constructor_regular_field, at varasm.c:4968
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80135 Andrew Pinski changed: What|Removed |Added CC||christianlupus at web dot de --- Comment #14 from Andrew Pinski --- *** Bug 84462 has been marked as a duplicate of this bug. ***
[Bug middle-end/92023] [9/10/11/12 Regression] Miscompilation when inlining operator delete[]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92023
Andrew Pinski changed:
What|Removed |Added
Component|c++ |middle-end
Known to fail||11.2.0, 7.1.0
Summary|Miscompilation when |[9/10/11/12 Regression]
|inlining operator delete[] |Miscompilation when
||inlining operator delete[]
Known to work||6.4.0
Target Milestone|--- |9.5
--- Comment #3 from Andrew Pinski ---
here is a runtime testcase:
#include
#include
#include
int t = 0;
void use(int* p) __attribute__((noipa,noinline,noclone));
void use(int*){}
void report(int) __attribute__((noipa,noinline,noclone));
void report(int a)
{printf("%d\n",a);t++;}
const int N = 5;
const size_t S = 512;
char objs[N][S];
bool taken[N] = {};
void* operator new[](size_t size) {
if (size <= S) {
for (int i = 0; i < N; i++) {
if (!taken[i]) {
report(2000 + i);
taken[i] = true;
return &objs[i];
}
}
}
throw std::bad_alloc();
}
void operator delete[](void* ptr) noexcept {
for (int i = 0; i < N; i++) {
if (ptr == &objs[i]) {
report(-2000 - i);
taken[i] = false;
}
}
}
int n = 10;
void test() __attribute__((noinline));
void test() {
int* a = new int[n];
int* b = new int[n];
use(a);
use(b);
delete[] b;
delete[] a;
}
int main(void)
{
test();
if (t != 4)
__builtin_abort();
}
[Bug c++/85079] Segfault While Compiling DXX-Rebirth Project
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85079 Andrew Pinski changed: What|Removed |Added Keywords|needs-reduction | --- Comment #4 from Andrew Pinski --- Reducing ...
[Bug tree-optimization/103204] [11/12 Regression] ICE: in vn_reference_insert_pieces, at tree-ssa-sccvn.c:3842 (on -O2 and above)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103204 --- Comment #3 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:140346fa246dc2476c5c2bf2ecadebd18a3af5d0 commit r12-5189-g140346fa246dc2476c5c2bf2ecadebd18a3af5d0 Author: Richard Biener Date: Fri Nov 12 09:09:29 2021 +0100 tree-optimization/103204 - fix missed valueization in VN The following fixes a missed valueization when simplifying a MEM[&...] combination during valueization. 2021-11-12 Richard Biener PR tree-optimization/103204 * tree-ssa-sccvn.c (valueize_refs_1): Re-valueize the top operand after folding in an address. * gcc.dg/torture/pr103204.c: New testcase.
[Bug c++/85079] Segfault While Compiling DXX-Rebirth Project
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85079 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #5 from Andrew Pinski --- Dup of bug 71740. *** This bug has been marked as a duplicate of bug 71740 ***
[Bug c++/71740] [9/10 Regression] ICE when defining a pointer to the `memcpy()` function with namespace scope using `auto` or as a template argument targeting i686
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71740 Andrew Pinski changed: What|Removed |Added CC||afuturepilotis at gmail dot com --- Comment #5 from Andrew Pinski --- *** Bug 85079 has been marked as a duplicate of this bug. ***
[Bug middle-end/92023] [9/10/11/12 Regression] Miscompilation when inlining operator delete[]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92023 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug tree-optimization/103202] [12 regression] gcc miscompiles ed-1.17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103202
--- Comment #3 from Sergei Trofimovich ---
Created attachment 51776
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51776&action=edit
main_loop_simpler.c
Attaching seemingly simpler example. I applied most inlines and simplified
loops as much as I could. It looks like VRP does something funny with:
while (n > 0)
{
while (n-- > 0)
{
Looking at 039t.mergephi1
with -fno-tree-vrp:
--- no-vrp/ed-main_loop.c.039t.mergephi12021-11-12 09:07:55.120821967 +
+++ yes-vrp/ed-main_loop.c.039t.mergephi12021-11-12 09:07:55.186822973
+
@@ -93,7 +93,7 @@
# np_6 = PHI
# n_8 = PHI
n_23 = n_8 + -1;
- if (n_8 > 0)
+ if (n_8 != 0)
goto ; [INV]
else
goto ; [INV]
I think our loop is executed with n == -1 on real data and vrp provided
incorrect range.
[Bug tree-optimization/103194] [12 Regression] ice in optimize_atomic_bit_test_and with __sync_fetch_and_and since r12-5102-gfb161782545224f5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103194 Martin Liška changed: What|Removed |Added Summary|[12 Regression] ice in |[12 Regression] ice in |optimize_atomic_bit_test_an |optimize_atomic_bit_test_an |d with __sync_fetch_and_and |d with __sync_fetch_and_and ||since ||r12-5102-gfb161782545224f5 CC||marxin at gcc dot gnu.org --- Comment #3 from Martin Liška --- Really started with r12-5102-gfb161782545224f5.
[Bug target/103201] [12 Regression] trunk 20211111 ftbfs for amdgcn – libgomp/teams.c:49:6: error: 'struct gomp_thread' has no member named 'num_teams'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103201 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW CC||marxin at gcc dot gnu.org Last reconfirmed||2021-11-12 Ever confirmed|0 |1
[Bug tree-optimization/103202] [12 regression] gcc miscompiles ed-1.17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103202
--- Comment #4 from Richard Biener ---
(In reply to Sergei Trofimovich from comment #3)
> Created attachment 51776 [details]
> main_loop_simpler.c
>
> Attaching seemingly simpler example. I applied most inlines and simplified
> loops as much as I could. It looks like VRP does something funny with:
>
> while (n > 0)
> {
> while (n-- > 0)
> {
>
> Looking at 039t.mergephi1
>
> with -fno-tree-vrp:
>
> --- no-vrp/ed-main_loop.c.039t.mergephi12021-11-12 09:07:55.120821967
> +
> +++ yes-vrp/ed-main_loop.c.039t.mergephi12021-11-12 09:07:55.186822973
> +
> @@ -93,7 +93,7 @@
># np_6 = PHI
># n_8 = PHI
>n_23 = n_8 + -1;
> - if (n_8 > 0)
> + if (n_8 != 0)
> goto ; [INV]
>else
> goto ; [INV]
>
> I think our loop is executed with n == -1 on real data and vrp provided
> incorrect range.
But how would the inner loop be reachable with n == -1?
[Bug tree-optimization/103202] [12 regression] gcc miscompiles ed-1.17 since r12-3876-g4a960d548b7d7d94
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103202 Martin Liška changed: What|Removed |Added Summary|[12 regression] gcc |[12 regression] gcc |miscompiles ed-1.17 |miscompiles ed-1.17 since ||r12-3876-g4a960d548b7d7d94 CC||aldyh at gcc dot gnu.org, ||amacleod at redhat dot com, ||marxin at gcc dot gnu.org Keywords|needs-bisection | --- Comment #5 from Martin Liška --- Started with r12-3876-g4a960d548b7d7d94.
[Bug target/103201] [12 Regression] trunk 20211111 ftbfs for amdgcn – libgomp/teams.c:49:6: error: 'struct gomp_thread' has no member named 'num_teams'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103201 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Created attachment 51777 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51777&action=edit gcc12-pr103201.patch I think this should fix it, but I currently don't have a way to test it. I was relying on libgomp/teams.c not being compiled for the !LIBGOMP_USE_PTHREAD targets...
[Bug target/103205] New: [12 Regression] ICE Segmentation fault since r12-5102-gfb161782545224f5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103205
Bug ID: 103205
Summary: [12 Regression] ICE Segmentation fault since
r12-5102-gfb161782545224f5
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: hjl at gcc dot gnu.org
Target Milestone: ---
Host: x86_64-linux-gnu
The following crashes:
$ cat ice.i
int short sync_fetch_and_and_short_15_a;
int __attribute__sync_fetch_and_and_short_15() {
return __sync_fetch_and_and(&sync_fetch_and_and_short_15_a, ~1) & 1;
}
$ gcc ice.i -march=c3-2 -m32 -O2 -c
during RTL pass: expand
ice.i: In function ‘__attribute__sync_fetch_and_and_short_15’:
ice.i:4:10: internal compiler error: Segmentation fault
4 | return __sync_fetch_and_and(&sync_fetch_and_and_short_15_a, ~1) & 1;
| ^~~~
0xf1db4a crash_signal
/home/marxin/Programming/gcc/gcc/toplev.c:322
0x7789979f ???
/usr/src/debug/glibc-2.34-2.1.x86_64/signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
0xb62ee1 emit_move_insn(rtx_def*, rtx_def*)
/home/marxin/Programming/gcc/gcc/expr.c:4013
0x1917918 gen_atomic_bit_test_and_resethi(rtx_def*, rtx_def*, rtx_def*,
rtx_def*, rtx_def*)
/home/marxin/Programming/gcc/gcc/config/i386/sync.md:806
0xdec8fc maybe_expand_insn(insn_code, unsigned int, expand_operand*)
/home/marxin/Programming/gcc/gcc/optabs.c:7915
0xa007bb expand_ifn_atomic_bit_test_and(gcall*)
/home/marxin/Programming/gcc/gcc/builtins.c:6225
0xa2f5d7 expand_call_stmt
/home/marxin/Programming/gcc/gcc/cfgexpand.c:2749
0xa2f5d7 expand_gimple_stmt_1
/home/marxin/Programming/gcc/gcc/cfgexpand.c:3876
0xa2f5d7 expand_gimple_stmt
/home/marxin/Programming/gcc/gcc/cfgexpand.c:4040
0xa35464 expand_gimple_basic_block
/home/marxin/Programming/gcc/gcc/cfgexpand.c:6082
0xa37687 execute
/home/marxin/Programming/gcc/gcc/cfgexpand.c:6808
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug target/103206] New: ICE in insn_default_length, at config/aarch64/aarch64.md:1183
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103206 Bug ID: 103206 Summary: ICE in insn_default_length, at config/aarch64/aarch64.md:1183 Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: qing.zhao at oracle dot com Target Milestone: --- Host: x86_64-linux-gnu Target: aarch64-linux-gnu The following fails: $ aarch64-linux-gnu-gcc /home/marxin/Programming/gcc/gcc/testsuite/gcc.target/aarch64/sve/pr102587-1.c -ftrivial-auto-var-init=zero ... 0xdeadbeef _fatal_insn(char const*, rtx_def const*, char const*, int, char const*) /home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/rtl-error.c:108 0xdeadbeef _fatal_insn_not_found(rtx_def const*, char const*, int, char const*) /home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/rtl-error.c:116 0xdeadbeef insn_default_length(rtx_insn*) /home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/config/aarch64/aarch64.md:1183 0xdeadbeef shorten_branches(rtx_insn*) /home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/final.c:1105 0xdeadbeef rest_of_handle_shorten_branches /home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/final.c:4380 0xdeadbeef execute /home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/final.c:4409
[Bug target/103206] ICE in insn_default_length, at config/aarch64/aarch64.md:1183
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103206 Martin Liška changed: What|Removed |Added CC||rguenth at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2021-11-12
[Bug tree-optimization/103204] [11 Regression] ICE: in vn_reference_insert_pieces, at tree-ssa-sccvn.c:3842 (on -O2 and above) since r12-1295-g7a56d3d3e99cc77a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103204 Martin Liška changed: What|Removed |Added Summary|[11 Regression] ICE: in |[11 Regression] ICE: in |vn_reference_insert_pieces, |vn_reference_insert_pieces, |at tree-ssa-sccvn.c:3842|at tree-ssa-sccvn.c:3842 |(on -O2 and above) |(on -O2 and above) since ||r12-1295-g7a56d3d3e99cc77a CC||marxin at gcc dot gnu.org Keywords|needs-bisection | --- Comment #4 from Martin Liška --- Btw. started with r12-1295-g7a56d3d3e99cc77a.
[Bug tree-optimization/103195] [12 Regression] tfft2 text grows by 70% with -Ofast since r12-5113-gd70ef65692fced7a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103195 Martin Liška changed: What|Removed |Added Keywords|needs-bisection | Status|UNCONFIRMED |NEW CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 Summary|tfft2 text grows by 70% |[12 Regression] tfft2 text |with -Ofast between |grows by 70% with -Ofast |g:52fa771758635d9c53cddb911 |since |6e5a66fae592230...a97fdde62 |r12-5113-gd70ef65692fced7a |7e64202940112009d45d17f85e4 | |cc61| Last reconfirmed||2021-11-12 --- Comment #2 from Martin Liška --- (In reply to Richard Biener from comment #1) > threader stuff would be my bet, but we need to bisect this (tfft2 is also > quite small) Bad bet ;) It's caused by r12-5113-gd70ef65692fced7a.
[Bug target/103200] [12 Regression] FAIL: gcc.target/i386/pr91333.c scan-assembler-times vmovapd|vmovsd 3 since r12-5177-g494bdadf28d0fb35
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103200 Martin Liška changed: What|Removed |Added Keywords|needs-bisection | Summary|[12 Regression] FAIL: |[12 Regression] FAIL: |gcc.target/i386/pr91333.c |gcc.target/i386/pr91333.c |scan-assembler-times|scan-assembler-times |vmovapd|vmovsd 3|vmovapd|vmovsd 3 since ||r12-5177-g494bdadf28d0fb35 CC||hubicka at gcc dot gnu.org, ||marxin at gcc dot gnu.org --- Comment #2 from Martin Liška --- Started with r12-5177-g494bdadf28d0fb35. @Honza: Did you run tests for the change?
[Bug tree-optimization/103202] [12 regression] gcc miscompiles ed-1.17 since r12-3876-g4a960d548b7d7d94
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103202 --- Comment #6 from Aldy Hernandez --- Not looking at this yet, but disabling jump threading from all passes (dom included) makes the problem go away: $ ./xgcc -B./ a.c -w -O2 -fno-thread-jumps && ./a.out element 1 element 2 element 3 ...so *maybe* threading related. The minimum number of threads that reproduces this is: ./xgcc -B./ a.c -w -O2 -fdbg-cnt=registered_jump_thread:1-1:3-3:5-5 && ./a.out ***dbgcnt: lower limit 1 reached for registered_jump_thread.*** ***dbgcnt: upper limit 1 reached for registered_jump_thread.*** ***dbgcnt: lower limit 3 reached for registered_jump_thread.*** ***dbgcnt: upper limit 3 reached for registered_jump_thread.*** ***dbgcnt: lower limit 5 reached for registered_jump_thread.*** ***dbgcnt: upper limit 5 reached for registered_jump_thread.*** element 1 element 2 $ grep 'Register.*jump' a.c.* a.c.111t.threadfull1: [1] Registering jump thread: (6, 7) incoming edge; (7, 9) nocopy; a.c.126t.thread1: [3] Registering jump thread: (2, 4) incoming edge; (4, 12) nocopy; a.c.191t.thread2: [5] Registering jump thread: (13, 11) incoming edge; (11, 10) nocopy;
[Bug tree-optimization/103202] [12 regression] gcc miscompiles ed-1.17 since r12-3876-g4a960d548b7d7d94
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103202 --- Comment #7 from Aldy Hernandez --- (In reply to Aldy Hernandez from comment #6) > Not looking at this yet, but disabling jump threading from all passes (dom > included) makes the problem go away: > > $ ./xgcc -B./ a.c -w -O2 -fno-thread-jumps && ./a.out > element 1 > element 2 > element 3 a.c is main_loop_simpler.c
[Bug target/103206] ICE in insn_default_length, at config/aarch64/aarch64.md:1183
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103206 Richard Biener changed: What|Removed |Added Keywords|ice-on-valid-code |ice-on-invalid-code --- Comment #1 from Richard Biener --- I think we have a duplicate of this - the testcase is invalid unless you enable SVE.
[Bug target/103205] [12 Regression] ICE Segmentation fault since r12-5102-gfb161782545224f5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103205 Richard Biener changed: What|Removed |Added Target Milestone|--- |12.0 Status|UNCONFIRMED |NEW Priority|P3 |P1 Ever confirmed|0 |1 Last reconfirmed||2021-11-12 --- Comment #1 from Richard Biener --- Confirmed. Might be a duplicate.
[Bug tree-optimization/103195] [12 Regression] tfft2 text grows by 70% with -Ofast since r12-5113-gd70ef65692fced7a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103195 --- Comment #3 from hubicka at kam dot mff.cuni.cz --- > > threader stuff would be my bet, but we need to bisect this (tfft2 is also > > quite small) > > Bad bet ;) It's caused by r12-5113-gd70ef65692fced7a. Hehe, that was my guess yeterday. Thanks for confirming. So now to figure out why better alias info makes tfft2 grow. I guess more vectorization? Thanks for bisecting this
[Bug libstdc++/103133] Binary built with -static using std::thread crashes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103133 --- Comment #8 from Jonathan Wakely --- For the record, musl does the same, since g:85da5c3024f731e719c4093314da8edcd1056527
[Bug tree-optimization/103192] [12 Regression] ICE on libgomp target-in-reduction-2.{C,c}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103192 --- Comment #4 from Aldy Hernandez --- I can reproduce on a stage2 compiler. I've narrowed it down to: -O2 -fdisable-tree-threadfull2 -fdisable-tree-threadfull1 -fdisable-tree-thread2 -fdisable-tree-thread1 -fdbg-cnt=registered_jump_thread:543-544:550-555 Which is interesting because I've disabled both thread[12] and threadfull[12] which are the passes affected by the bisected culprit (r12-4790). All the threads come from ethread: $ grep Register.*jump gimplify.c.* gimplify.c.034t.ethread: [543] Registering jump thread: (687, 689) incoming edge; (689, 690) nocopy; gimplify.c.034t.ethread: [544] Registering jump thread: (688, 689) incoming edge; (689, 693) nocopy; gimplify.c.034t.ethread: [550] Registering jump thread: (776, 777) incoming edge; (777, 801) nocopy; gimplify.c.034t.ethread: [551] Registering jump thread: (779, 780) incoming edge; (780, 781) nocopy; gimplify.c.034t.ethread: [552] Registering jump thread: (780, 782) incoming edge; (782, 785) nocopy; gimplify.c.034t.ethread: [553] Registering jump thread: (784, 786) incoming edge; (786, 787) nocopy; gimplify.c.034t.ethread: [554] Registering jump thread: (785, 786) incoming edge; (786, 788) nocopy; gimplify.c.034t.ethread: [555] Registering jump thread: (804, 806) incoming edge; (806, 807) nocopy; ...which was not affected by the commit, and which is a rather simple threading pass with no IL changes and no full resolving ranger mode. If I disable DOM it goes away, so *maybe* these ethreads cause DOM to perform an optimization that triggers the ICE. Damn it. These bugs are getting trickier and trickier. Where are the simple 5 liners I could fix in no time flat? :)
[Bug target/103200] [12 Regression] FAIL: gcc.target/i386/pr91333.c scan-assembler-times vmovapd|vmovsd 3 since r12-5177-g494bdadf28d0fb35
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103200
--- Comment #3 from Jan Hubicka ---
Sorry, I managed to include last minute change that was wrong. Currently
modref does not track if function is deterministic so we can not detect looping
pure/consts. I am testing.
diff --git a/gcc/ipa-modref.c b/gcc/ipa-modref.c
index 72006251f29..4da5284c94f 100644
--- a/gcc/ipa-modref.c
+++ b/gcc/ipa-modref.c
@@ -2790,9 +2790,10 @@ analyze_function (function *f, bool ipa)
if (!ipa && flag_ipa_pure_const)
{
- if (!summary->stores->every_base && !summary->stores->bases)
+ if (!summary->stores->every_base && !summary->stores->bases
+ && !summary->side_effects)
{
- if (!summary->loads->every_base && !summary->loads->bases)
+ if (!summary->loads->every_base && !summary->loads->bases
fixup_cfg = ipa_make_function_const
(cgraph_node::get (current_function_decl),
summary->side_effects, true);
@@ -4380,7 +4381,8 @@ modref_propagate_in_scc (cgraph_node *component_node)
modref_summary_lto *summary_lto = summaries_lto
? summaries_lto->get (cur)
: NULL;
- if (summary && !summary->stores->every_base && !summary->stores->bases)
+ if (summary && !summary->stores->every_base && !summary->stores->bases
+ && !summary->side_effects)
{
if (!summary->loads->every_base && !summary->loads->bases)
pureconst |= ipa_make_function_const
@@ -4390,7 +4392,7 @@ modref_propagate_in_scc (cgraph_node *component_node)
(cur, summary->side_effects, false);
}
if (summary_lto && !summary_lto->stores->every_base
- && !summary_lto->stores->bases)
+ && !summary_lto->stores->bases && !summary->side_effects)
{
if (!summary_lto->loads->every_base && !summary_lto->loads->bases)
pureconst |= ipa_make_function_const
[Bug tree-optimization/103207] New: [12 Regression] ICE in verify_range, at value-range.cc:385
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103207
Bug ID: 103207
Summary: [12 Regression] ICE in verify_range, at
value-range.cc:385
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: ice-checking, ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
gcc-12.0.0-alpha20211107 snapshot (g:962ff7d2849e1fa6a1fe0535aa2dec5c2b9a32a6)
ICEs when compiling the following testcase, reduced from test/Sema/switch-1.c
from the clang 12.0.0 test suite, w/ -O2 --param case-values-threshold=1:
int f(int i) {
switch (i) {
case 2147483647:
return 1;
case 9223372036854775807L:
return 2;
case (2147483647*4)%4:
return 4;
}
return 0;
}
% gcc-12.0.0 -O2 --param case-values-threshold=1 -c cxsrkwpe.c
cxsrkwpe.c: In function 'f':
cxsrkwpe.c:5:5: warning: overflow in conversion from 'long int' to 'int'
changes value from '9223372036854775807' to '-1' [-Woverflow]
5 | case 9223372036854775807L:
| ^~~~
cxsrkwpe.c:7:21: warning: integer overflow in expression of type 'int' results
in '-4' [-Woverflow]
7 | case (2147483647*4)%4:
| ^
during GIMPLE pass: thread
cxsrkwpe.c:1:5: internal compiler error: in verify_range, at value-range.cc:385
1 | int f(int i) {
| ^
0x78ae3b irange::verify_range()
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211107/work/gcc-12-20211107/gcc/value-range.cc:385
0x115a64e int_range<255u>::int_range(tree_node*, tree_node*, value_range_kind)
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211107/work/gcc-12-20211107/gcc/value-range.h:425
0x115a64e find_case_label_range(gswitch*, irange const*)
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211107/work/gcc-12-20211107/gcc/tree-vrp.c:2496
0x10ca508 back_threader::find_taken_edge_switch(vec const&, gswitch*)
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211107/work/gcc-12-20211107/gcc/tree-ssa-threadbackward.c:263
0x10cb11f back_threader::maybe_register_path()
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211107/work/gcc-12-20211107/gcc/tree-ssa-threadbackward.c:198
0x10cb855 back_threader::find_paths_to_names(basic_block_def*, bitmap_head*)
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211107/work/gcc-12-20211107/gcc/tree-ssa-threadbackward.c:404
0x10cb8d9 back_threader::find_paths_to_names(basic_block_def*, bitmap_head*)
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211107/work/gcc-12-20211107/gcc/tree-ssa-threadbackward.c:442
0x10cbe11 back_threader::find_paths(basic_block_def*, tree_node*)
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211107/work/gcc-12-20211107/gcc/tree-ssa-threadbackward.c:477
0x10cc041 back_threader::thread_blocks()
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211107/work/gcc-12-20211107/gcc/tree-ssa-threadbackward.c:922
0x10cc0b4 execute
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211107/work/gcc-12-20211107/gcc/tree-ssa-threadbackward.c:1024
[Bug tree-optimization/103208] New: ICE: SSA corruption (Existing SSA name for symbol marked for renaming),or ICE in make_decl_rtl, at varasm.c:1446
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103208 Bug ID: 103208 Summary: ICE: SSA corruption (Existing SSA name for symbol marked for renaming),or ICE in make_decl_rtl, at varasm.c:1446 Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: openmp Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: asolokha at gmx dot com Target Milestone: --- 1. gcc-12.0.0-alpha20211107 snapshot (g:962ff7d2849e1fa6a1fe0535aa2dec5c2b9a32a6) ICEs when compiling gcc/testsuite/c-c++-common/gomp/loop-8.c w/ -O1 -fopenmp -fwrapv: % gcc-12.0.0 -O1 -fopenmp -fwrapv -c gcc/testsuite/c-c++-common/gomp/loop-8.c Existing SSA name for symbol marked for renaming: .omp_data_i_14(D) during GIMPLE pass: sccp gcc/testsuite/c-c++-common/gomp/loop-8.c: In function 'foo._omp_fn.0': gcc/testsuite/c-c++-common/gomp/loop-8.c:6:11: internal compiler error: SSA corruption 6 | #pragma omp parallel for collapse(2) | ^~~ 0xf3e860 update_ssa(unsigned int) /var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211107/work/gcc-12-20211107/gcc/tree-into-ssa.c:3441 0xef4e38 cleanup_tree_cfg_noloop /var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211107/work/gcc-12-20211107/gcc/tree-cfgcleanup.c:1078 0xef4e38 cleanup_tree_cfg(unsigned int) /var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211107/work/gcc-12-20211107/gcc/tree-cfgcleanup.c:1183 0xdaf3dc execute_function_todo /var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211107/work/gcc-12-20211107/gcc/passes.c:2008 0xdafd1c execute_todo /var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211107/work/gcc-12-20211107/gcc/passes.c:2096 2. Omitting -O1 from the command line yields the following instead, which may be a separate issue: % gcc-12.0.0 -fopenmp -fwrapv -c gcc/testsuite/c-c++-common/gomp/loop-8.c during RTL pass: expand gcc/testsuite/c-c++-common/gomp/loop-8.c: In function 'foo._omp_fn.0': gcc/testsuite/c-c++-common/gomp/loop-8.c:6:11: internal compiler error: in make_decl_rtl, at varasm.c:1446 6 | #pragma omp parallel for collapse(2) | ^~~ 0x79274e make_decl_rtl(tree_node*) /var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211107/work/gcc-12-20211107/gcc/varasm.c:1446 0xaed6f7 expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) /var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211107/work/gcc-12-20211107/gcc/expr.c:10553 0xaf676f expand_expr /var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211107/work/gcc-12-20211107/gcc/expr.h:301 0xaf676f expand_expr_addr_expr_1 /var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211107/work/gcc-12-20211107/gcc/expr.c:8430 0xaf65c4 expand_expr_addr_expr_1 /var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211107/work/gcc-12-20211107/gcc/expr.c:8476 0xaec095 expand_expr_addr_expr /var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211107/work/gcc-12-20211107/gcc/expr.c:8551 0xaec095 expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) /var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211107/work/gcc-12-20211107/gcc/expr.c:11767 0xa3a6e6 expand_normal /var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211107/work/gcc-12-20211107/gcc/expr.h:307 0xa3a6e6 do_compare_and_jump /var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211107/work/gcc-12-20211107/gcc/dojump.c:1257 0xa3bf47 do_jump_1 /var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211107/work/gcc-12-20211107/gcc/dojump.c:231 0x9bfba8 expand_gimple_cond /var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211107/work/gcc-12-20211107/gcc/cfgexpand.c:2657 0x9c0b74 expand_gimple_basic_block /var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211107/work/gcc-12-20211107/gcc/cfgexpand.c:5944 0x9c21fe execute /var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211107/work/gcc-12-20211107/gcc/cfgexpand.c:6811
[Bug tree-optimization/103192] [12 Regression] ICE on libgomp target-in-reduction-2.{C,c}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103192 --- Comment #5 from Martin Jambor --- On one of my machines I can see the ICE with an LTO profiledbootstrapped compiler but neither with a normally bootstrapped compiler nor with an LTO-bootstrapped compiler, without PGO. I have not yet tried with a non-LTO profiledbootstrapped one.
[Bug target/103197] ppc inline expansion of memcpy/memmove should not use lxsibzx/stxsibx for a single byte
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103197 Segher Boessenkool changed: What|Removed |Added Last reconfirmed||2021-11-12 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #3 from Segher Boessenkool --- Also, it reloads the whole address into a register, instead of just the offset. The latter is much better to do (the offset can often be shared with later insns, in this example already!) But that aside. Confirmed. It only happens for power9 and up in my testing, does your compiler default to that?
[Bug other/103021] Make the path to etags used in the build system configurable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103021 --- Comment #1 from Eric Gallager --- Note that automake did similarly in the following commit: https://git.savannah.gnu.org/cgit/automake.git/commit/m4?id=d2ccbd7eb38d6a4277d6f42b994eb5a29b1edf29 ...and that commit is part of automake 1.16.4, so updating to automake 1.16.4 would fix this for the directories that use automake. It wouldn't fix it for the directories that don't use automake, though.
[Bug tree-optimization/103192] [12 Regression] ICE on libgomp target-in-reduction-2.{C,c}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103192 --- Comment #6 from Aldy Hernandez --- Hmm, all these threads look correct. Following are my steps for verification. In a stage2 compiler I do: $ rm -f gimplify.o $ make cc1 CXXFLAGS="-O2 -fdisable-tree-threadfull2 -fdisable-tree-threadfull1 -fdisable-tree-thread2 -fdisable-tree-thread1 -fdbg-cnt=registered_jump_thread:543-543:544-544:550-550:551-551:552-552:553-553:554-554:555-555 -fdump-tree-all-details --param=threader-debug=all" $ ./cc1 a.c -O2 -fopenmp -quiet a.c: In function ‘foo’: a.c:35:13: internal compiler error: Segmentation fault ... ... This disables all the threaders except DOM and ethread. It also splits up the individual threaded paths for easy grepping in the source (dbgcnt.*543, dbgcnt.*544, etc). All of the threads are needed to reproduce. All of them are from ethread and belong to the gimplify_scan_omp_clauses function: $ grep Register.*jump gimplify.c.* gimplify.c.034t.ethread: [543] Registering jump thread: (687, 689) incoming edge; (689, 690) nocopy; gimplify.c.034t.ethread: [544] Registering jump thread: (688, 689) incoming edge; (689, 693) nocopy; gimplify.c.034t.ethread: [550] Registering jump thread: (776, 777) incoming edge; (777, 801) nocopy; gimplify.c.034t.ethread: [551] Registering jump thread: (779, 780) incoming edge; (780, 781) nocopy; gimplify.c.034t.ethread: [552] Registering jump thread: (780, 782) incoming edge; (782, 785) nocopy; gimplify.c.034t.ethread: [553] Registering jump thread: (784, 786) incoming edge; (786, 787) nocopy; gimplify.c.034t.ethread: [554] Registering jump thread: (785, 786) incoming edge; (786, 788) nocopy; gimplify.c.034t.ethread: [555] Registering jump thread: (804, 806) incoming edge; (806, 807) nocopy; All of these paths, with the exception of 551 are trivially solvable. For example: The IL immediate above this... ***dbgcnt: lower limit 543 reached for registered_jump_thread.*** ***dbgcnt: upper limit 543 reached for registered_jump_thread.*** [543] Registering jump thread: (687, 689) incoming edge; (689, 690) nocopy; path: 687->689->690 SUCCESS ...is the path: : # iftmp.2344_1598 = PHI <1(687), 0(688)> if (iftmp.2344_1598 != 0) goto ; [INV] else goto ; [INV] That's an obvious thread from 687->689->690. The rest are a similar pattern. The only different path is: ***dbgcnt: lower limit 551 reached for registered_jump_thread.*** ***dbgcnt: upper limit 551 reached for registered_jump_thread.*** [551] Registering jump thread: (779, 780) incoming edge; (780, 781) nocopy; path: 779->780->781 SUCCESS with an IL of: : # iftmp.2373_1603 = PHI if (iftmp.2373_1603 != 0B) goto ; [INV] else goto ; [INV] but if you look at the definition of ctx_1868, it's clear it's threadable to bb781 because ctx_1868 is known to be non-zero: ctx_1868 = new_omp_context (region_type_1866(D)); ctx_1868->code = code_1869(D); Those are all the jump threads in play and they're all correct.
[Bug tree-optimization/103192] [12 Regression] ICE on libgomp target-in-reduction-2.{C,c}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103192 --- Comment #7 from Jakub Jelinek --- For me, all I can see is that clearly at runtime omp_add_variable is called with pctx NULL despite the if (pctx) guard around it and that until threadfull2 I was seeing a guarding condition in the IL that ensured that (either test of the SSA_NAME passed to first arg of omp_add_variable later against 0, or in some cases/some revisions something like: temp = code == OMP_TARGET ? outer_ctx : ctx; ... if (code != OMP_TARGET) goto bbn; if (outer_ctx != 0) goto bbn; else goto somewhere_else; bbn: omp_add_variable (temp, ...); which is also fine, as ctx is guaranteed to be non-NULL.
[Bug tree-optimization/103192] [12 Regression] ICE on libgomp target-in-reduction-2.{C,c}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103192 --- Comment #8 from Aldy Hernandez --- Note that I've disabled all the thread full passes and the problem persists.
[Bug tree-optimization/102497] gimple-predicate-analysis.cc:2143:1: warning: function 'add_pred' is not needed and will not be emitted [-Wunneeded-internal-declaration]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102497 --- Comment #4 from CVS Commits --- The master branch has been updated by Martin Liska : https://gcc.gnu.org/g:5f516a6a5d7ecce48a86d01fed1aeb4fc4ccc534 commit r12-5190-g5f516a6a5d7ecce48a86d01fed1aeb4fc4ccc534 Author: Martin Liska Date: Fri Nov 12 12:37:26 2021 +0100 Remove unused function. PR tree-optimization/102497 gcc/ChangeLog: * gimple-predicate-analysis.cc (add_pred): Remove unused function:
[Bug tree-optimization/103192] [12 Regression] ICE on libgomp target-in-reduction-2.{C,c}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103192 --- Comment #9 from Jakub Jelinek --- (In reply to Aldy Hernandez from comment #8) > Note that I've disabled all the thread full passes and the problem persists. So, can you see where the guarding condition vanishes in that case?
[Bug tree-optimization/102497] gimple-predicate-analysis.cc:2143:1: warning: function 'add_pred' is not needed and will not be emitted [-Wunneeded-internal-declaration]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102497 Martin Liška changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Martin Liška --- Fixed.
[Bug c++/87504] inconsistent diagnostic style between C and C++ for binary operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87504 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #9 from Eric Gallager --- (In reply to David Malcolm from comment #8) > Author: dmalcolm > Date: Thu Dec 20 14:18:48 2018 > New Revision: 267299 > > URL: https://gcc.gnu.org/viewcvs?rev=267299&root=gcc&view=rev > Log: > -Wtautological-compare: fix comparison of macro expansions > > gcc/c-family/ChangeLog: > PR c++/87504 > * c-warn.c (get_outermost_macro_expansion): New function. > (spelled_the_same_p): Use it to unwind the macro expansions, and > compare the outermost macro in each nested expansion, rather than > the innermost. > > gcc/testsuite/ChangeLog: > PR c++/87504 > * c-c++-common/Wtautological-compare-8.c: New test. > > > Added: > trunk/gcc/testsuite/c-c++-common/Wtautological-compare-8.c > Modified: > trunk/gcc/c-family/ChangeLog > trunk/gcc/c-family/c-warn.c > trunk/gcc/testsuite/ChangeLog so is this fixed now?
[Bug libfortran/102992] fortran: redirecting standard out to a file does not work on macOS 12.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102992 Francois-Xavier Coudert changed: What|Removed |Added CC||fxcoudert at gcc dot gnu.org --- Comment #28 from Francois-Xavier Coudert --- > Well, unless there's a good reason to have it in a DTOR, it makes for a more > robust solution to call it directly (there are various other differences > that could occur in mixed code bases esp. c++ + fortran even without the > Darwin21.1 bug). Mixed code is in fact the reason why it's in a DTOR and not called at the end of Fortran main program. We need this clean-up routine to run even when the main code is not in Fortran, and but Fortran routines are called by other means (Fortran object files linked, or Fortran-based library loaded at run-time).
[Bug fortran/97896] [11/12 Regression] ICE in gfc_trans_assignment_1, at fortran/trans-expr.c:11156
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97896 --- Comment #12 from CVS Commits --- The master branch has been updated by Mikael Morin : https://gcc.gnu.org/g:68d62cb20637b2faf2c2cc1716a0786b07a6a76f commit r12-5192-g68d62cb20637b2faf2c2cc1716a0786b07a6a76f Author: Mikael Morin Date: Sun Nov 7 14:39:18 2021 +0100 fortran: Ignore unused args in scalarization [PR97896] The KIND argument of the INDEX intrinsic is a compile time constant that is used at compile time only to resolve to a kind-specific library function. That argument is otherwise completely ignored at runtime, and there is no code generated for it as the library procedure has no kind argument. This confuses the scalarizer which expects to see every argument of elemental functions used when calling a procedure. This change removes the argument from the scalarization lists at the beginning of the scalarization process, so that the argument is completely ignored. This also reverts the existing workaround (commit d09847357b965a2c2cda063827ce362d4c9c86f2 except for its testcase). PR fortran/97896 gcc/fortran/ChangeLog: * intrinsic.c (add_sym_4ind): Remove. (add_functions): Use add_sym4 instead of add_sym4ind. Donât special case the index intrinsic. * iresolve.c (gfc_resolve_index_func): Use the individual arguments directly instead of the full argument list. * intrinsic.h (gfc_resolve_index_func): Update the declaration accordingly. * trans-decl.c (gfc_get_extern_function_decl): Donât modify the list of arguments in the case of the index intrinsic. * trans-array.h (gfc_get_intrinsic_for_expr, gfc_get_proc_ifc_for_expr): New. * trans-array.c (gfc_get_intrinsic_for_expr, arg_evaluated_for_scalarization): New. (gfc_walk_elemental_function_args): Add intrinsic procedure as argument. Count arguments. Check arg_evaluated_for_scalarization. * trans-intrinsic.c (gfc_walk_intrinsic_function): Update call. * trans-stmt.c (get_intrinsic_for_code): New. (gfc_trans_call): Update call. gcc/testsuite/ChangeLog: * gfortran.dg/index_5.f90: New.
[Bug tree-optimization/103209] New: [12 Regression] wrong code at -O1 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103209
Bug ID: 103209
Summary: [12 Regression] wrong code at -O1 on x86_64-linux-gnu
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: haoxintu at gmail dot com
Target Milestone: ---
Hi all.
It seems to be a recent regression issue.
$cat small.c
#include
#include
int32_t a[6];
int64_t b;
int32_t *c;
int32_t **d = &c;
int64_t *e = &b;
int32_t **const *f = &d;
int32_t **const **g = &f;
int32_t *h();
static int16_t j();
static uint32_t k(int8_t, const int32_t *, int64_t);
static uint32_t l() {
int32_t *m = &a[3];
int32_t n = 0;
int8_t o = 0;
int32_t *p[] = {&n, &n, &n, &n};
uint32_t q[6][1][2] = {};
for (o = 0; o <= 1; o = 6)
if (h(j(k(3, 0, q[2][0][0]), &n), n) == p[3])
*m = *e;
return 0;
}
int32_t *h(uint32_t, int32_t) { return ***g; }
int16_t j(uint32_t, int32_t *r) { **f = r; }
uint32_t k(int8_t, const int32_t *, int64_t) { *e = 3; return 0;}
int main() {
int i = 0;
l();
for (i = 0; i < 6; i++){
if (i == 3)
printf("%d\n", a[i]);
}
return 0;
}
$gcc -O1 small.c ; ./a.out
0
$gcc -O0 small.c ; ./a.out
3
$gcc -O2 small.c ; ./a.out
3
$gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/haoxin/haoxin-data/compilers/gcc/build/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with:../configure
--prefix=/home/haoxin/haoxin-data/compilers/gcc/build/ --enable-bootstrap
--enable-checking=release --enable-languages=c,c++ --enable-multilib :
(reconfigured) ../configure
--prefix=/home/haoxin/haoxin-data/compilers/gcc/build/ --enable-bootstrap
--enable-checking=release --enable-multilib --enable-languages=c,c++,lto
--no-create --no-recursion
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 2022 (experimental) (GCC)
Thanks,
Haoxin
[Bug c/71852] add warning for conditions that can never be true (missed -Wtautological-compare?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71852 --- Comment #4 from Eric Gallager --- (In reply to Eric Gallager from comment #3) > Confirmed, I would've thought Marek's recent changes to > -Wtautological-compare would have gotten this, but guess not... Can someone help me remember which commit(s) I was referring to when saying "Marek's recent changes" here? I'm trying to craft a preprocessor conditional for disabling -Wtautological-compare for a similar case as this, but am forgetting in which version of GCC this particular kind of bitwise comparison warning was added to -Wtautological-compare... on a side note, maybe the bitwise comparison warnings could be split off from -Wtautological-compare into a separate subflag (-Wtautological-bitwise-compare perhaps?) so they can be toggled separately?
[Bug c++/70361] Obviously false code in if not detected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70361 Eric Gallager changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=71852 --- Comment #5 from Eric Gallager --- (In reply to Patrick Palka from comment #2) > Maybe the new -Wtautological-compare flag could be extended to warn about > these kinds of conditionals. Maybe Marek Polacek's enhancements to it could be relevant here? See also bug 71852
[Bug libstdc++/59675] -D_GLIBCXX_DEBUG asserts to stdout (it should stderr)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59675 --- Comment #10 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:a54ce8865a885bca5ab9c4aa6ec725cd13c09901 commit r12-5193-ga54ce8865a885bca5ab9c4aa6ec725cd13c09901 Author: Jonathan Wakely Date: Wed Nov 3 16:06:29 2021 + libstdc++: Print assertion messages to stderr [PR59675] This replaces the printf used by failed debug assertions with fprintf, so we can write to stderr. To avoid including the assert function is moved into the library. To avoid programs using a vague linkage definition of the old inline function, the function is renamed. Code compiled with old versions of GCC might still call the old function, but code compiled with the newer GCC will call the new function and write to stderr. libstdc++-v3/ChangeLog: PR libstdc++/59675 * acinclude.m4 (libtool_VERSION): Bump version. * config/abi/pre/gnu.ver (GLIBCXX_3.4.30): Add version and export new symbol. * configure: Regenerate. * include/bits/c++config (__replacement_assert): Remove, declare __glibcxx_assert_fail instead. * src/c++11/debug.cc (__glibcxx_assert_fail): New function to replace __replacement_assert, writing to stderr instead of stdout. * testsuite/util/testsuite_abi.cc: Update latest version.
[Bug libstdc++/59675] -D_GLIBCXX_DEBUG asserts to stdout (it should stderr)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59675 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from Jonathan Wakely --- Fixed for gcc-12.
[Bug libfortran/102992] fortran: redirecting standard out to a file does not work on macOS 12.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102992 --- Comment #29 from Iain Sandoe --- (In reply to Francois-Xavier Coudert from comment #28) > > Well, unless there's a good reason to have it in a DTOR, it makes for a more > > robust solution to call it directly (there are various other differences > > that could occur in mixed code bases esp. c++ + fortran even without the > > Darwin21.1 bug). > > Mixed code is in fact the reason why it's in a DTOR and not called at the > end of Fortran main program. We need this clean-up routine to run even when > the main code is not in Fortran, and but Fortran routines are called by > other means (Fortran object files linked, or Fortran-based library loaded at > run-time). I've posted a fix for this (it is the fix for darwin21 DTORs in general) however CAVEAT : there is No guarantee given by the GCC DTOR machinery about the relative ordering of DTORs between different TUs, my fix will not solve that.
[Bug libfortran/102992] fortran: redirecting standard out to a file does not work on macOS 12.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102992 --- Comment #30 from Francois-Xavier Coudert --- (In reply to Iain Sandoe from comment #29) > I've posted a fix for this (it is the fix for darwin21 DTORs in general) Yes I've seen the patch, thanks! > however CAVEAT : there is No guarantee given by the GCC DTOR machinery about > the relative ordering of DTORs between different TUs, my fix will not solve > that. That was already the case before (if I understand right) and this is fine for our use: we have only one DTOR in libgfortran, and Fortran I/O and I/O in other languages should not operate on the same files or descriptors.
[Bug c/103210] New: "warning: braces around scalar initializer" should have a warning flag controlling it [-Wmany-braces-around-scalar-init]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103210
Bug ID: 103210
Summary: "warning: braces around scalar initializer" should
have a warning flag controlling it
[-Wmany-braces-around-scalar-init]
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: egallager at gcc dot gnu.org
CC: dmalcolm at gcc dot gnu.org, dodji at gcc dot gnu.org,
mpolacek at gcc dot gnu.org
Blocks: 44209
Target Milestone: ---
Example from libopcodes:
xstormy16-opc.c:1013:5: warning: braces around scalar initializer
1013 | { 0|A(ALIAS), { { { (1
[Bug c/103210] "warning: braces around scalar initializer" should have a warning flag controlling it [-Wmany-braces-around-scalar-init]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103210 --- Comment #1 from Eric Gallager --- Note that this also applies to the related "excess elements in scalar initializer" pedwarn at lines 10574-10575 in the same file: https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/c/c-typeck.c;h=782414f8c8cb66b155a3cd7432706caed8828b32;hb=HEAD#l10575
[Bug target/103200] [12 Regression] FAIL: gcc.target/i386/pr91333.c scan-assembler-times vmovapd|vmovsd 3 since r12-5177-g494bdadf28d0fb35
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103200 --- Comment #4 from CVS Commits --- The master branch has been updated by Jan Hubicka : https://gcc.gnu.org/g:1b62cddcf091fb8cadf575246a7d3ff778650a6b commit r12-5195-g1b62cddcf091fb8cadf575246a7d3ff778650a6b Author: Jan Hubicka Date: Fri Nov 12 14:00:47 2021 +0100 Fix ipa-modref pure/const discovery PR ipa/103200 * ipa-modref.c (analyze_function, modref_propagate_in_scc): Do not mark pure/const function if there are side-effects.
[Bug c/103210] "warning: braces around scalar initializer" should have a warning flag controlling it [-Wmany-braces-around-scalar-init]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103210 --- Comment #2 from Jonathan Wakely --- (In reply to Eric Gallager from comment #0) > As for a warning name, in bug 95559 it was mentioned that apparently clang > calls this -Wmany-braces-around-scalar-init, so maybe use that? Just "many" doesn't make any sense for "too many" IMHO. They mean different things. The clang name seems poor.
[Bug c/103210] "warning: braces around scalar initializer" should have a warning flag controlling it [-Wmany-braces-around-scalar-init]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103210 --- Comment #3 from Jonathan Wakely --- And GCC already has a distinct "too many braces around scalar initializer" diagnostic (an error) for the cases covered by that Clang option. I think this is a different case (although without a proper testcase I'm not sure exactly what kind of initializer causes the warning).
[Bug tree-optimization/103207] [12 Regression] ICE in verify_range, at value-range.cc:385 since r12-4766-g113dab2b9d511f3a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103207 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2021-11-12 Ever confirmed|0 |1 CC||aldyh at gcc dot gnu.org, ||marxin at gcc dot gnu.org Summary|[12 Regression] ICE in |[12 Regression] ICE in |verify_range, at|verify_range, at |value-range.cc:385 |value-range.cc:385 since ||r12-4766-g113dab2b9d511f3a --- Comment #1 from Martin Liška --- Started with r12-4766-g113dab2b9d511f3a.
[Bug tree-optimization/103208] [12 Regression] ICE: SSA corruption (Existing SSA name for symbol marked for renaming),or ICE in make_decl_rtl, at varasm.c:1446 since r12-4733-g2084b5f42a4432da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103208 Martin Liška changed: What|Removed |Added Known to fail||12.0 Ever confirmed|0 |1 Summary|ICE: SSA corruption |[12 Regression] ICE: SSA |(Existing SSA name for |corruption (Existing SSA |symbol marked for |name for symbol marked for |renaming),or ICE in |renaming),or ICE in |make_decl_rtl, at |make_decl_rtl, at |varasm.c:1446 |varasm.c:1446 since ||r12-4733-g2084b5f42a4432da Last reconfirmed||2021-11-12 CC||jakub at gcc dot gnu.org, ||marxin at gcc dot gnu.org Status|UNCONFIRMED |NEW --- Comment #1 from Martin Liška --- Started with r12-4733-g2084b5f42a4432da.
[Bug tree-optimization/103209] [12 Regression] wrong code at -O1 on x86_64-linux-gnu since r12-4324-g008e7397dad971c0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103209 Martin Liška changed: What|Removed |Added Last reconfirmed||2021-11-12 Status|UNCONFIRMED |NEW Summary|[12 Regression] wrong code |[12 Regression] wrong code |at -O1 on x86_64-linux-gnu |at -O1 on x86_64-linux-gnu ||since ||r12-4324-g008e7397dad971c0 Ever confirmed|0 |1 CC||hubicka at gcc dot gnu.org, ||marxin at gcc dot gnu.org --- Comment #1 from Martin Liška --- Started with r12-4324-g008e7397dad971c0.
[Bug target/103200] [12 Regression] FAIL: gcc.target/i386/pr91333.c scan-assembler-times vmovapd|vmovsd 3 since r12-5177-g494bdadf28d0fb35
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103200 Martin Liška changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Martin Liška --- Fixed now.
[Bug ipa/103211] New: [12 Regression] 416.gamess crashes after r12-5177-g494bdadf28d0fb35
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103211 Bug ID: 103211 Summary: [12 Regression] 416.gamess crashes after r12-5177-g494bdadf28d0fb35 Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: hubicka at gcc dot gnu.org, marxin at gcc dot gnu.org Blocks: 26163 Target Milestone: --- Crashes with -Ofast -march=skylake -g: Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: #0 0x7799c79f in ??? at /usr/src/debug/glibc-2.34-2.1.x86_64/signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0 #1 0x77606d in huckel_ at /home/marxin/Programming/cpu2006/benchspec/CPU2006/416.gamess/build/build_peak_amd64-m64-mine.0004/guess.fppized.f:1270 #2 0x777894 in hucklm_ at /home/marxin/Programming/cpu2006/benchspec/CPU2006/416.gamess/build/build_peak_amd64-m64-mine.0004/guess.fppized.f:1727 #3 0x7782c8 in gesmem_ at /home/marxin/Programming/cpu2006/benchspec/CPU2006/416.gamess/build/build_peak_amd64-m64-mine.0004/guess.fppized.f:842 #4 0x778df3 in guesmo_ at /home/marxin/Programming/cpu2006/benchspec/CPU2006/416.gamess/build/build_peak_amd64-m64-mine.0004/guess.fppized.f:1022 #5 0x700921 in energx_ at /home/marxin/Programming/cpu2006/benchspec/CPU2006/416.gamess/build/build_peak_amd64-m64-mine.0004/gamess.fppized.f:913 #6 0x701894 in brnchx_ at /home/marxin/Programming/cpu2006/benchspec/CPU2006/416.gamess/build/build_peak_amd64-m64-mine.0004/gamess.fppized.f:769 #7 0xc7b420 in srftwo_ at /home/marxin/Programming/cpu2006/benchspec/CPU2006/416.gamess/build/build_peak_amd64-m64-mine.0004/surf.fppized.f:311 #8 0xc7ccfa in surfx_ at /home/marxin/Programming/cpu2006/benchspec/CPU2006/416.gamess/build/build_peak_amd64-m64-mine.0004/surf.fppized.f:52 #9 0x70206b in gamess at /home/marxin/Programming/cpu2006/benchspec/CPU2006/416.gamess/build/build_peak_amd64-m64-mine.0004/gamess.fppized.f:570 #10 0x4080dc in main at /home/marxin/Programming/cpu2006/benchspec/CPU2006/416.gamess/build/build_peak_amd64-m64-mine.0004/gamess.fppized.f:677 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 [Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
[Bug ipa/103211] [12 Regression] 416.gamess crashes after r12-5177-g494bdadf28d0fb35
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103211 Martin Liška changed: What|Removed |Added Target Milestone|--- |12.0 Last reconfirmed||2021-11-12 Status|UNCONFIRMED |NEW Ever confirmed|0 |1
[Bug ipa/103211] [12 Regression] 416.gamess crashes after r12-5177-g494bdadf28d0fb35
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103211 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug c/103210] "warning: braces around scalar initializer" should have a warning flag controlling it [-Wmany-braces-around-scalar-init]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103210 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2021-11-12
[Bug tree-optimization/103209] [12 Regression] wrong code at -O1 on x86_64-linux-gnu since r12-4324-g008e7397dad971c0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103209 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Target Milestone|--- |12.0
[Bug tree-optimization/103208] [12 Regression] ICE: SSA corruption (Existing SSA name for symbol marked for renaming),or ICE in make_decl_rtl, at varasm.c:1446 since r12-4733-g2084b5f42a4432da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103208 Richard Biener changed: What|Removed |Added Target Milestone|--- |12.0
[Bug tree-optimization/103207] [12 Regression] ICE in verify_range, at value-range.cc:385 since r12-4766-g113dab2b9d511f3a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103207 Richard Biener changed: What|Removed |Added Target Milestone|--- |12.0
[Bug jit/103199] FAIL: ../jit/docs/examples/tut04-toyvm/toyvm.c, initial compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103199 --- Comment #1 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:aa1fd30df56d752e3d5a81af409875a1f1e3e327 commit r12-5196-gaa1fd30df56d752e3d5a81af409875a1f1e3e327 Author: David Malcolm Date: Thu Nov 11 18:32:21 2021 -0500 jit: fix -Werror=format-overflow= in testsuite [PR103199] gcc/jit/ChangeLog: PR jit/103199 * docs/examples/tut04-toyvm/toyvm.c (toyvm_function_compile): Increase size of buffer. * docs/examples/tut04-toyvm/toyvm.cc (compilation_state::create_function): Likewise. Signed-off-by: David Malcolm
[Bug c/103210] "warning: braces around scalar initializer" should have a warning flag controlling it [-Wmany-braces-around-scalar-init]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103210 --- Comment #4 from Eric Gallager --- (In reply to Jonathan Wakely from comment #3) > And GCC already has a distinct "too many braces around scalar initializer" > diagnostic (an error) for the cases covered by that Clang option. I think > this is a different case (although without a proper testcase I'm not sure > exactly what kind of initializer causes the warning). I think that that one is for the C++ front-end, while this one is for the plain C front-end.
[Bug tree-optimization/103192] [12 Regression] ICE on libgomp target-in-reduction-2.{C,c}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103192 --- Comment #10 from Aldy Hernandez --- The guard seems to be removed by the vrp2 pass, not by jump threading. a.ii.195t.vrp2:Folding predicate iftmp.2373_1515 != 0B to 1 For some bizarre reason, ranger thinks iftmp.2373_1515 is nonzero and removes the check against zero: === BB 219 region_type_1384(D) unsigned int VARYING ctx_1386struct gimplify_omp_ctx * [1B, +INF] code_1387(D)tree_code [0, 65535] outer_ctx_1389 struct gimplify_omp_ctx * VARYING _2620 bool VARYING c_3771 union tree_node * [1B, +INF] _3783 bool VARYING [local count: 105119385]: iftmp.2340_1256 = code_1387(D) == 199 ? 81 : 80; iftmp.2304_1247 = code_1387(D) == 195 ? 81 : 80; check_non_private_1152 = code_1387(D) != 177 ? "lastprivate" : 0B; iftmp.2373_1515 = code_1387(D) != 181 ? ctx_1386 : outer_ctx_1389; iftmp.2304_1247 : gomp_map_kind [80, 81] iftmp.2340_1256 : gomp_map_kind [80, 81] iftmp.2373_1515 : struct gimplify_omp_ctx * [1B, +INF] Notice the non-zero range on exit. To reproduce: tmcc1plus a.ii -O2 -fdisable-tree-threadfull2 -fdisable-tree-threadfull1 -fdisable-tree-thread2 -fdisable-tree-thread1 -fdbg-cnt=registered_jump_thread:543-543:544-544:550-550:551-551:552-552:553-553:554-554:555-555 -fno-PIE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -fno-common -fdump-tree-all-lineno and search for: :10070:.*omp_add_variable ...in the vrp2 dump. There's no guard on iftmp.2373_1515 because the check was removed. It is possible that threadfull2, which uses the ranger engine and runs before vrp2, was threading the check, since ranger obviously thinks it's a constant. This is why removing threadfull2 didn't fix the problem, since vrp2 (which is now using ranger) will make the same conclusion, albeit with a different approach (remove the conditional instead of thread the path). And indeed, if I add --param=vrp2-mode=vrp, to the above steps, the problem goes away. So, this is ranger...not the threader. I'm going to put this aside while I take a look at the other P1s that are completely the threader's fault, and if Andrew doesn't get to it before, I'll come back to this.
[Bug tree-optimization/103192] [12 Regression] ICE on libgomp target-in-reduction-2.{C,c}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103192 --- Comment #11 from Aldy Hernandez --- Created attachment 51778 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51778&action=edit preprocessed source to reproduce
[Bug c++/103212] New: requires expression with lambda fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103212
Bug ID: 103212
Summary: requires expression with lambda fails
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: egor.pugin at gmail dot com
Target Milestone: ---
---
constexpr bool test = requires { [](auto o){}(0); };
static_assert(test);
---
gives
:1:37: error: expected primary-expression before 'auto'
1 | constexpr bool test = requires { [](auto o){}(0); };
| ^~~~
Also see for compiler comparison:
https://godbolt.org/z/zYGa733d4
msvc fails that condition, clang compiles ok.
[Bug c++/103212] requires expression with lambda fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103212
--- Comment #1 from Egor Pugin ---
Original code was closer to something like this:
---
#include
constexpr bool test = requires { [](auto o) {}(std::unique_ptr{}); };
static_assert(test);
---
[Bug c++/103213] New: Lambda type name overlap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103213
Bug ID: 103213
Summary: Lambda type name overlap
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mario.demontis at gmail dot com
Target Milestone: ---
/*** BEGIN SOURCE ***/
template
struct Wrap{
T w;
};
int main() {
auto l1 = [x = 5](int a){return x+a;};
auto l2 = [y = 6](int a){return y+1;};
Wrap w1{l1};
Wrap w2{l2};
}
/ END SOURCE /
Both w1 and w2 are assigned type name Wrap >
In gdb there is no way to distinguish between the 2 types:
(gdb) ptype 'Wrap >'
type = struct Wrap > {
struct {
int __x;
} w;
}
For the same reason, there is also no way to obtain the 2 different python
gdb.Type objects
[Bug middle-end/102997] [12 Regression] 45% 454.calculix regression with LTO+PGO -march=native -Ofast on Zen since r12-4526-gd8edfadfc7a9795b65177a50ce44fd348858e844
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997 --- Comment #29 from Martin Liška --- As seen here: https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=299.170.0 https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=474.170.0 the regression is fixed!
[Bug tree-optimization/103194] [12 Regression] ice in optimize_atomic_bit_test_and with __sync_fetch_and_and since r12-5102-gfb161782545224f5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103194
--- Comment #4 from H.J. Lu ---
This avoids the crash:
diff --git a/gcc/tree-ssa-ccp.c b/gcc/tree-ssa-ccp.c
index 0f79e9f05bd..14c5ecdf119 100644
--- a/gcc/tree-ssa-ccp.c
+++ b/gcc/tree-ssa-ccp.c
@@ -3443,7 +3443,7 @@ optimize_atomic_bit_test_and (gimple_stmt_iterator *gsip,
ibit = 0;
}
else if (TYPE_PRECISION (TREE_TYPE (use_lhs))
- == TYPE_PRECISION (TREE_TYPE (use_rhs)))
+ <= TYPE_PRECISION (TREE_TYPE (use_rhs)))
{
gimple *use_nop_stmt;
if (!single_imm_use (use_lhs, &use_p, &use_nop_stmt)
But nop_atomic_bit_test_and_p should handle cast. Hongtao, please take a look.
[Bug tree-optimization/103209] [12 Regression] wrong code at -O1 on x86_64-linux-gnu since r12-4324-g008e7397dad971c0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103209 Jan Hubicka changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #2 from Jan Hubicka --- mine.
[Bug middle-end/102997] [12 Regression] 45% 454.calculix regression with LTO+PGO -march=native -Ofast on Zen since r12-4526-gd8edfadfc7a9795b65177a50ce44fd348858e844
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #30 from Richard Biener --- It likely was the loop header copying missing on cold loops then.
[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 Bug 26163 depends on bug 102997, which changed state. Bug 102997 Summary: [12 Regression] 45% 454.calculix regression with LTO+PGO -march=native -Ofast on Zen since r12-4526-gd8edfadfc7a9795b65177a50ce44fd348858e844 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug libbacktrace/103167] UBSAN error since g:05f40bc4c116ba48843728201bc7290a5e518598
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103167 --- Comment #9 from CVS Commits --- The master branch has been updated by Martin Liska : https://gcc.gnu.org/g:83310a08a2bc52b6e8c3a3e3216b4e723e58c961 commit r12-5197-g83310a08a2bc52b6e8c3a3e3216b4e723e58c961 Author: Martin Liska Date: Fri Nov 12 14:50:57 2021 +0100 libbacktrace: fix UBSAN issues Fix issues mentioned in the PR. PR libbacktrace/103167 libbacktrace/ChangeLog: * elf.c (elf_uncompress_lzma_block): Cast to unsigned int. (elf_uncompress_lzma): Likewise. * xztest.c (test_samples): memcpy only if v > 0.
[Bug libbacktrace/103167] UBSAN error since g:05f40bc4c116ba48843728201bc7290a5e518598
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103167 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Martin Liška --- Fixed.
[Bug other/63426] [meta-bug] Issues found with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426 Bug 63426 depends on bug 103167, which changed state. Bug 103167 Summary: UBSAN error since g:05f40bc4c116ba48843728201bc7290a5e518598 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103167 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug target/103205] [9/10/11/12 Regression] ICE Segmentation fault since r7-532
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103205
H.J. Lu changed:
What|Removed |Added
Summary|[12 Regression] ICE |[9/10/11/12 Regression] ICE
|Segmentation fault since|Segmentation fault since
|r12-5102-gfb161782545224f5 |r7-532
CC|hjl at gcc dot gnu.org |hjl.tools at gmail dot
com,
||jakub at redhat dot com
--- Comment #2 from H.J. Lu ---
[hjl@gnu-cfl-2 pr103205]$ cat s2.c
unsigned short sync_fetch_and_and_short_15_a;
unsigned short
__attribute__sync_fetch_and_and_short_15 (void)
{
return __sync_fetch_and_and(&sync_fetch_and_and_short_15_a, ~1) & 1;
}
[hjl@gnu-cfl-2 pr103205]$ /usr/gcc-7.3.1-x32/bin/gcc -O2
-mtune-ctrl=^himode_math -S s2.c
s2.c: In function ‘__attribute__sync_fetch_and_and_short_15’:
s2.c:5:10: internal compiler error: Segmentation fault
return __sync_fetch_and_and(&sync_fetch_and_and_short_15_a, ~1) & 1;
^~~~
unrecognized DWARF version in .debug_info at 6
Please submit a full bug report,
with preprocessed source if appropriate.
See
[Bug jit/103199] FAIL: ../jit/docs/examples/tut04-toyvm/toyvm.c, initial compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103199 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from David Malcolm --- Thanks; should be fixed by the above commit.
[Bug tree-optimization/103207] [12 Regression] ICE in verify_range, at value-range.cc:385 since r12-4766-g113dab2b9d511f3a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103207 Aldy Hernandez changed: What|Removed |Added CC||amacleod at redhat dot com --- Comment #2 from Aldy Hernandez --- We're trying to build a range for [-1, 0(OVF)] in find_case_label_range: int_range_max label_range (CASE_LOW (min_label), case_high); and case_high has an overflow. This causes us to fail in irange::verify_range() on the compare_values: tree lb = tree_lower_bound (i); tree ub = tree_upper_bound (i); int c = compare_values (lb, ub); gcc_checking_assert (c == 0 || c == -1); The question is, is this 0(OVF) allowed? [local count: 1073741824]: switch (i_2(D)) [0.00%], case -1: [50.00%], case 0(OVF): [50.00%]>
[Bug target/103205] [9/10/11/12 Regression] ICE Segmentation fault since r7-532
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103205
--- Comment #3 from Martin Liška ---
(In reply to H.J. Lu from comment #2)
> [hjl@gnu-cfl-2 pr103205]$ cat s2.c
> unsigned short sync_fetch_and_and_short_15_a;
> unsigned short
> __attribute__sync_fetch_and_and_short_15 (void)
> {
> return __sync_fetch_and_and(&sync_fetch_and_and_short_15_a, ~1) & 1;
> }
This one started with r7-532-gadedd5c173388ae5.
[Bug target/103206] ICE in insn_default_length, at config/aarch64/aarch64.md:1183
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103206 qinzhao at gcc dot gnu.org changed: What|Removed |Added CC||qinzhao at gcc dot gnu.org --- Comment #2 from qinzhao at gcc dot gnu.org --- (In reply to Richard Biener from comment #1) > I think we have a duplicate of this - the testcase is invalid unless you > enable SVE. Yes, the original bug is for PR102587. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102587 require -march=armv8.3-a+sve.
[Bug testsuite/103051] [12 regression] new test case gcc.dg/vect/tsvc/vect-tsvc-s112.c fails in r12-4840
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103051 --- Comment #12 from CVS Commits --- The master branch has been updated by Martin Liska : https://gcc.gnu.org/g:6849c71c065e599282c98f3678f22ac52d97a755 commit r12-5198-g6849c71c065e599282c98f3678f22ac52d97a755 Author: Martin Liska Date: Thu Nov 11 17:31:56 2021 +0100 testsuite: Filter out TSVC test on Power [PR103051] PR testsuite/103051 gcc/testsuite/ChangeLog: * gcc.dg/vect/tsvc/vect-tsvc-s112.c: Skip test for old Power CPUs.
[Bug testsuite/103051] [12 regression] new test case gcc.dg/vect/tsvc/vect-tsvc-s112.c fails in r12-4840
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103051 Martin Liška changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #13 from Martin Liška --- Thank you for the help, pushed.
[Bug target/103205] [9/10/11/12 Regression] ICE Segmentation fault since r7-532
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103205 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Created attachment 51779 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51779&action=edit gcc12-pr103205.patch Untested fix.
[Bug other/89259] liboffloadmic/runtime/offload_omp_host.cpp:692: pointless test ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89259 Martin Liška changed: What|Removed |Added Resolution|--- |WONTFIX Status|ASSIGNED|RESOLVED --- Comment #6 from Martin Liška --- H.J. We'd like to deprecate MIC offload in GCC 12. We will remove all traces of MIC offload in GCC 13.
[Bug other/89863] [meta-bug] Issues in gcc that other static analyzers (cppcheck, clang-static-analyzer, PVS-studio) find that gcc misses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89863 Bug 89863 depends on bug 89259, which changed state. Bug 89259 Summary: liboffloadmic/runtime/offload_omp_host.cpp:692: pointless test ? https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89259 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |WONTFIX
[Bug target/103201] [12 Regression] trunk 20211111 ftbfs for amdgcn – libgomp/teams.c:49:6: error: 'struct gomp_thread' has no member named 'num_teams'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103201 --- Comment #3 from Andrew Stubbs --- I did some preliminary testing on your patch: the libgomp.c/target-teams-1.c testcase runs fine on amdgcn. I presume that that covers most of the existing features of those runtime calls?
[Bug target/103201] [12 Regression] trunk 20211111 ftbfs for amdgcn – libgomp/teams.c:49:6: error: 'struct gomp_thread' has no member named 'num_teams'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103201
--- Comment #4 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:f49c7a4fb23d82c89c97acec88770b300c903d9a
commit r12-5200-gf49c7a4fb23d82c89c97acec88770b300c903d9a
Author: Jakub Jelinek
Date: Fri Nov 12 16:11:02 2021 +0100
libgomp: Unbreak gcn offload build
My recent libgomp change apparently broke libgomp build for gcn offloading.
The problem is that gcn, unlike nvptx, doesn't override teams.c source file
and the patch I've committed assumed all the non-LIBGOMP_USE_PTHREADS
targets
do not use it. My understanding is that gcn included omp_get_num_teams
and omp_get_team_num definitions in both icv-device.o and teams.o,
with the definitions only in the former working correctly.
This patch brings gcn into sync with how nvptx does it, that teams.c
is overridden, provides a dummy GOMP_teams_reg and
omp_get_{num_teams,team_num}
definitions and icv-device.c doesn't provide those.
2021-11-12 Jakub Jelinek
PR target/103201
* config/gcn/icv-device.c (omp_get_num_teams, omp_get_team_num):
Move
to ...
* config/gcn/teams.c: ... here. New file.
[Bug c++/84930] Brace-closed initialization of cstring (i.e."abcdefghi") to coresponding aggregate types fails in certain situation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84930 Will Wray changed: What|Removed |Added CC||wjwray at gmail dot com --- Comment #8 from Will Wray --- This can be marked RESOLVED, fixed in gcc11, same as the referenced duplicates.
[Bug tree-optimization/103202] [12 regression] gcc miscompiles ed-1.17 since r12-3876-g4a960d548b7d7d94
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103202 Aldy Hernandez changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |aldyh at gcc dot gnu.org --- Comment #8 from Aldy Hernandez --- The problem here is this thread: [5] Registering jump thread: (13, 11) incoming edge; (11, 10) nocopy; BB11 has this: === BB 11 Imports: n_42 Exports: n_42 Relational : (n_45 < n_42) [local count: 118111614]: # np_43 = PHI # n_42 = PHI # m_31 = PHI <0(13), m_16(4)> n_45 = n_42 + -1; if (n_42 != 0) goto ; [89.00%] else goto ; [11.00%] Because of the ordering of the import bitmap, we solve m_31 first to 0. Then, when we solve n_42, we think we can use the m_31 in the cache, but the ordering is wrong. PHIs must always be done first. We went through a similar exercise to get relationals right and somehow missed this.
[Bug tree-optimization/103202] [12 regression] gcc miscompiles ed-1.17 since r12-3876-g4a960d548b7d7d94
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103202 --- Comment #9 from Aldy Hernandez --- Created attachment 51780 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51780&action=edit patch in testing
[Bug target/93082] macOS Authorization.h needs fixinclude
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93082 Eric Gallager changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=90835, ||https://bugs.llvm.org/show_ ||bug.cgi?id=44406 CC||bkorb at gnu dot org, ||iains at gcc dot gnu.org, ||mikestump at comcast dot net --- Comment #6 from Eric Gallager --- This is hitting me in my fork of Apple's version of gdb; cc-ing Darwin and fixincludes maintainers
