[Bug c++/103401] New: gcc accepts decltype(auto(0)) as the parameter of the function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103401
Bug ID: 103401
Summary: gcc accepts decltype(auto(0)) as the parameter of the
function
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
It seems that gcc should not accept this strange syntax, although I don't know
why f has two template parameters..
void f(decltype(auto(0))) { }
int main() {
f(0);
}
https://godbolt.org/z/PaevrsrE8
[Bug c++/85428] constexpr pointer equality comparison not considered constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85428
Fedor Chelnokov changed:
What|Removed |Added
CC||fchelnokov at gmail dot com
--- Comment #2 from Fedor Chelnokov ---
Here is an example without templates that erroneously fails to compile as well:
```
int main() {
static constexpr int x = 1;
static constexpr int y = 2;
static_assert( != );
}
```
Demo: https://gcc.godbolt.org/z/3WdqP49Gq
Related discussion: https://stackoverflow.com/q/70091821/7325599
[Bug target/102239] powerpc suboptimal boolean test of contiguous bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102239
luoxhu at gcc dot gnu.org changed:
What|Removed |Added
CC||luoxhu at gcc dot gnu.org
--- Comment #2 from luoxhu at gcc dot gnu.org ---
(In reply to Segher Boessenkool from comment #1)
> Confirmed.
>
> So the relevant insn
>
> (parallel [(set (reg:CC 123)
> (compare:CC (and:DI (reg:DI 124)
> (const_int 25769803776 [0x6]))
> (const_int 0 [0])))
>(clobber (scratch:DI))])
>
> is matched by *and3_2insn but not by any pattern that ends up as just
> one insn. Not *and3_mask_dot, because that doesn't do a shift first,
> is just an AND and there are no machine insns to do that; but there is no
> pattern for what we can do.
>
> *rotl3_mask_dot cannot do this either; the base and the dot2 of that
> cannot be done, they return a shifted result, but that doesn't matter for
> comparing it to 0. So we should add a specialised version.
Seems different with what you describe, in combine, it was combined to
anddi3_2insn_dot:
(insn 9 8 10 2 (parallel [
(set (reg:CC 122)
(compare:CC (and:DI (reg:DI 123)
(const_int 25769803776 [0x6]))
(const_int 0 [0])))
(clobber (scratch:DI))
]) "pr102239.c":3:6 210 {*anddi3_2insn_dot}
(expr_list:REG_DEAD (reg:DI 123)
(nil)))
(jump_insn 10 9 11 2 (set (pc)
(if_then_else (eq (reg:CC 122)
(const_int 0 [0]))
(label_ref 15)
(pc))) "pr102239.c":3:6 868 {*cbranch}
(expr_list:REG_DEAD (reg:CC 122)
(int_list:REG_BR_PROB 536870916 (nil)))
Then in pr102239.c.302r.split2, it is split by "*and3_2insn_dot" to
rotldi3_mask+lshrdi3_dot:
Splitting with gen_split_80 (rs6000.md:3721)
(insn 32 8 33 2 (set (reg:DI 3 3 [124])
(and:DI (ashift:DI (reg:DI 3 3 [123])
(const_int 29 [0x1d]))
(const_int -4611686018427387904 [0xc000])))
"pr102239.c":3:6 236 {*rotldi3_mask}
(nil))
(insn 33 32 10 2 (parallel [
(set (reg:CC 100 0 [122])
(compare:CC (lshiftrt:DI (reg:DI 3 3 [124])
(const_int 29 [0x1d]))
(const_int 0 [0])))
(clobber (reg:DI 3 3 [124]))
]) "pr102239.c":3:6 281 {*lshrdi3_dot}
(nil))
Why this difference happens?
0x6 is not a valid mask for anddi3_2insn_dot:
"(mode == Pmode || UINTVAL (operands[2]) <= 0x7fff)
&& rs6000_is_valid_2insn_and (operands[2], mode)
&& !(rs6000_is_valid_and_mask (operands[2], mode)
|| logical_const_operand (operands[2], mode))"
(gdb) p UINTVAL (operands[2]) <= 0x7fff
$84 = false
(gdb) p rs6000_is_valid_2insn_and (operands[2], E_DImode)
$85 = true
(gdb) p logical_const_operand (operands[2], E_DImode)
$86 = false
(gdb) p rs6000_is_valid_and_mask (operands[2], E_DImode)
$87 = false
(gdb) p Pmode
$88 = DImode
[Bug tree-optimization/103376] [12 Regression] wrong code at -Os and above on x86_64-linux-gnu since r12-5453-ga944b5dec3adb28e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103376
--- Comment #7 from Zhendong Su ---
A couple of additional tests for the same issue:
(1) at -Os and above
[622] % gcctk -O1 small.c; ./a.out
[623] % gcctk -Os small.c; ./a.out
Aborted
[624] % cat small.c
long a = 2653121401;
unsigned char b;
int c;
int main() {
b = a;
c = ~(((a ^ b) + 2) ^ 254);
if (c > 1641845765)
__builtin_abort();
return 0;
}
(2) at -O2 and -O3
[511] % gcctk -Os small.c; ./a.out
[512] % gcctk -O2 small.c; ./a.out
Segmentation fault
[513] %
[513] % cat small.c
int printf(const char *, ...);
int a = 1, *b;
int main() {
int c = a;
if (a == 2)
printf("0");
a = a ^ c;
if (a)
a++;
if (a && *b)
return a;
return 0;
}
[Bug middle-end/90663] [9/10/11/12 Regression] strcmp ([i], a + i) not folded for arrays and constant index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90663 Andrew Pinski changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Summary|[9 Regression] strcmp |[9/10/11/12 Regression] |([i], a + i) not folded |strcmp ([i], a + i) not |for arrays and constant |folded for arrays and |index |constant index Status|NEW |ASSIGNED --- Comment #7 from Andrew Pinski --- (In reply to Richard Biener from comment #1) > Anyhow, I suggest to use get_addr_base_and_unit_offset in the gimple > folder since there variable addresses will not appear literally but > only in separate SSA defs. We could also use ptr_difference_const now and see if the difference is zero. Let me try that.
[Bug target/103252] questionable codegen with kmovd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103252
--- Comment #14 from Hongtao.liu ---
(In reply to Hongtao.liu from comment #13)
> >
> > So for short live range reg, we may lose opportunity to allocate best
> > regclass, maybe add peephole2 to handle those cases instead of tune RA.
> No, r132 is also used as addr, but currently lra only add cost of movement
> from mask to gpr, but we could possibly run out of gpr which means there
> will be an extra spill, and this is not counted by record_address_regs.
>
> modified gcc/ira-costs.c
> @@ -1226,7 +1226,7 @@ record_address_regs (machine_mode mode, addr_space_t
> as, rtx x,
> struct costs *pp;
> int *pp_costs;
> enum reg_class i;
> - int k, regno, add_cost;
> + int k, regno, add_cost, potential_spill_cost;
> cost_classes_t cost_classes_ptr;
> enum reg_class *cost_classes;
> move_table *move_in_cost;
> @@ -1239,6 +1239,7 @@ record_address_regs (machine_mode mode, addr_space_t
> as, rtx x,
> ALLOCNO_BAD_SPILL_P (ira_curr_regno_allocno_map[regno]) = true;
> pp = COSTS (costs, COST_INDEX (regno));
> add_cost = (ira_memory_move_cost[Pmode][rclass][1] * scale) / 2;
> + potential_spill_cost = add_cost / 5;
> if (INT_MAX - add_cost < pp->mem_cost)
> pp->mem_cost = INT_MAX;
> else
> @@ -1252,6 +1253,10 @@ record_address_regs (machine_mode mode, addr_space_t
> as, rtx x,
> {
> i = cost_classes[k];
> add_cost = (move_in_cost[i][rclass] * scale) / 2;
> + /* If we run out of rclass regs, there could be an extra spill,
> +Let's say 20% possibility. */
> + if (!ira_class_subset_p[i][rclass])
> + add_cost += potential_spill_cost;
> if (INT_MAX - add_cost < pp_costs[k])
> pp_costs[k] = INT_MAX;
Increase cost will lose some spill to mask opportunity like testcase
https://gcc.godbolt.org/z/KG63ErzEr
[Bug tree-optimization/34723] [9/10/11/12 Regression] Summing variable should be initialized to the first member before the loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34723 --- Comment #17 from Andrew Pinski --- Note GCC 10+ autovectorizes the loop to (which is better than clang, which produces a lot of shuffles): movqxmm0, QWORD PTR table[rip] pxorxmm1, xmm1 movdqa xmm2, xmm0 psadbw xmm2, xmm1 movqrax, xmm2 add al, BYTE PTR table[rip+8] add al, BYTE PTR table[rip+9] movsx eax, al ret
[Bug tree-optimization/86955] strlen of a known string in member array plus offset not folded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86955 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Last reconfirmed|2019-06-07 00:00:00 |2021-11-23 --- Comment #3 from Andrew Pinski --- (In reply to Martin Sebor from comment #1) > The reason is that the strlen pass sees the following: Note we get now (after r12-5465-g911b633803): _1 = _4(D)->a; __builtin_memcpy (_1, "123", 4); _2 = p_4(D) + 2; _3 = __builtin_strlen (_2); But strlen pass still does not understand p_4(D)+4 is the same as _4(D)->a[1]
[Bug c++/103347] [9/10/11 Regression] Non-static data member initialization is erroneously allowed in C++03 with assignment to NULL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103347 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Summary|[9/10/11/12 Regression] |[9/10/11 Regression] |Non-static data member |Non-static data member |initialization is |initialization is |erroneously allowed in |erroneously allowed in |C++03 with assignment to|C++03 with assignment to |NULL|NULL --- Comment #11 from Marek Polacek --- Fixed in GCC 12.
[Bug c++/103347] [9/10/11/12 Regression] Non-static data member initialization is erroneously allowed in C++03 with assignment to NULL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103347
--- Comment #10 from CVS Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:d71d019f63ed5d3fdb34579023bafa4dcf323f2c
commit r12-5488-gd71d019f63ed5d3fdb34579023bafa4dcf323f2c
Author: Marek Polacek
Date: Mon Nov 22 14:09:25 2021 -0500
c++: Fix missing NSDMI diagnostic in C++98 [PR103347]
Here the problem is that we aren't detecting a NSDMI in C++98:
struct A {
void *x = NULL;
};
because maybe_warn_cpp0x uses input_location and that happens to point
to NULL which comes from a system header. Jakub suggested changing the
location to the '=', thereby avoiding the system header problem. To
that end, I've added a new location_t member into cp_declarator. This
member is used when this declarator is part of an init-declarator. The
rest of the changes is obvious. I've also taken the liberty of adding
loc_or_input_loc, since I want to avoid checking for UNKNOWN_LOCATION.
PR c++/103347
gcc/cp/ChangeLog:
* cp-tree.h (struct cp_declarator): Add a location_t member.
(maybe_warn_cpp0x): Add a location_t parameter with a default
argument.
(loc_or_input_loc): New.
* decl.c (grokdeclarator): Use loc_or_input_loc. Pass init_loc
down
to maybe_warn_cpp0x.
* error.c (maybe_warn_cpp0x): Add a location_t parameter. Use it.
* parser.c (make_declarator): Initialize init_loc.
(cp_parser_member_declaration): Set init_loc.
(cp_parser_condition): Likewise.
(cp_parser_init_declarator): Likewise.
(cp_parser_parameter_declaration): Likewise.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/nsdmi-warn1.C: New test.
* g++.dg/cpp0x/nsdmi-warn1.h: New file.
[Bug tree-optimization/51084] bounds checking not optimized to a single comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51084
Andrew Pinski changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot
gnu.org
--- Comment #3 from Andrew Pinski ---
(simplify
(bit_and:c (lt @0 ADDR_EXPR@1) (ge @0 ADDR_EXPR@2))
(with { poly_int64 diff; }
(if (ptr_difference_const (@2, @1, ))
(le (pointer_diff:ssizetype .
I will implement this for GCC 13.
[Bug target/103383] Microblaze bswaphi2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103383 --- Comment #4 from Andrew Pinski --- (In reply to Rich Kujoth from comment #3) > Haha nice, I guess I should have read a little further. Thanks! > > What does the "length" mean? length means the size of the instructions in bytes that would be in the executable. I noticed it was not set so it might be a good idea to set it too. There are places in the Microblaze backend that uses the length attr to add some nops or something I didn't really look into it that much.
[Bug target/103383] Microblaze bswaphi2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103383 --- Comment #3 from Rich Kujoth --- Haha nice, I guess I should have read a little further. Thanks! What does the "length" mean?
[Bug target/103383] Microblaze bswaphi2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103383 Andrew Pinski changed: What|Removed |Added Target||microblaze Last reconfirmed||2021-11-24 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #2 from Andrew Pinski --- I think this patch fixes the problem: diff --git a/gcc/config/microblaze/microblaze.md b/gcc/config/microblaze/microblaze.md index 6d77752cbfd..ca4bd976a5c 100644 --- a/gcc/config/microblaze/microblaze.md +++ b/gcc/config/microblaze/microblaze.md @@ -372,7 +372,8 @@ (define_insn "bswaphi2" "TARGET_REORDER" "swapb %0, %1 swaph %0, %0" -) + [(set_attr "length" "8") + (set_attr "type" "no_delay_arith")]) ;; ;; Microblaze delay slot description CUT The delay slot description is right below bswaphi2 definition even: (define_delay (eq_attr "type" "branch,call,jump") [(and (eq_attr "type" "!branch,call,jump,icmp,multi,no_delay_arith,no_delay_load,no_delay_store,no_delay_imul,no_delay_move,darith") (ior (not (match_test "microblaze_no_unsafe_delay")) (eq_attr "type" "!fadd,frsub,fmul,fdiv,fcmp,store,load") )) (nil) (nil)]) Or multi could be used instead of no_delay_arith.
[Bug tree-optimization/103376] [12 Regression] wrong code at -Os and above on x86_64-linux-gnu since r12-5453-ga944b5dec3adb28e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103376
--- Comment #6 from Andrew Pinski ---
Another testcase (from PR 103399) which shows the issue:
int t1 = -2;
int e(int) __attribute__((noipa));
int e(int f) {
int t = 0;
for (int d = 0; d < f; d ++) {
for (int c = 0; c < ((f ? t1 : 0) ^ t1) + 1; c++)
t= 42;
}
return t;
}
int main() {
unsigned a = e(1);
printf("%u\n", a);
if (a != 42)
__builtin_abort ();
}
[Bug tree-optimization/103035] [meta-bug] YARPGen bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103035 Bug 103035 depends on bug 103399, which changed state. Bug 103399 Summary: [12 Regression] Wrong code with -O2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103399 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug tree-optimization/103376] [12 Regression] wrong code at -Os and above on x86_64-linux-gnu since r12-5453-ga944b5dec3adb28e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103376 Andrew Pinski changed: What|Removed |Added CC||vsevolod.livinskij at frtk dot ru --- Comment #5 from Andrew Pinski --- *** Bug 103399 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/103399] [12 Regression] Wrong code with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103399 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #3 from Andrew Pinski --- Dup of bug 103376. *** This bug has been marked as a duplicate of bug 103376 ***
[Bug tree-optimization/103399] [12 Regression] Wrong code with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103399 --- Comment #2 from Andrew Pinski --- Before bswap, we have: iftmp.0_11 = t1; t1.1_1 = t1; _2 = t1.1_1 ^ iftmp.0_11; But after we get: load_dst_8 = MEM[(int *)]; _2 = (int) load_dst_8; Which is wrong as _2 should have been 0.
[Bug tree-optimization/103399] [12 Regression] Wrong code with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103399
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Last reconfirmed||2021-11-24
--- Comment #1 from Andrew Pinski ---
Confirmed reduced testcase:
int t1 = -2;
int e(int) __attribute__((noipa));
int e(int f) {
int t = 0;
for (int d = 0; d < f; d ++) {
for (int c = 0; c < ((f ? t1 : 0) ^ t1) + 1; c++)
t= 42;
}
return t;
}
int main() {
unsigned a = e(1);
printf("%u\n", a);
if (a != 42)
__builtin_abort ();
}
Note the t1 being negative is important. t1 being global is also important, if
you do a load of t1 before either loop, you end up with working code.
THis is another bswap issue ...
[Bug tree-optimization/103399] [12 Regression] Wrong code with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103399 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.0
[Bug driver/103398] configure: Enable --enable-default-pie by default for Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103398 --- Comment #3 from Sam James --- (In reply to Andrew Pinski from comment #1) > No. The whole reason why there is an option is because it is optional. A fair amount of future-new-defaults start off as optional and eventually become it. This isn't a particularly strong reason to reject it. The alternative would be that there was.. never a configure option? And one day it just flipped without any chance of changing it? I think this would probably benefit from more discussion. As meowray noted, this has been set by every major Linux distro for quite some time. It would make sense to re-evaluate GCC's defaults in that context and whether the reasons for them still make sense.
[Bug driver/103398] configure: Enable --enable-default-pie by default for Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103398 --- Comment #2 from Fangrui Song --- I want to switch the default because: * It seems to me that every Linux distro uses --enable-default-pie GCC. I use "many", but it is likely "most" at this point (2021). * When a user builds GCC on Linux, the generated GCC does not default PIE. This almost certainly does not match the behavior of their host GCC. On the libc-alpha mailing list, I have seen that contributors waste time because they don't notice that scripts/build-many-glibcs.py built GCC uses the implicit --disable-default-pie, which has a behavior different from the host GCC or cross compiler provided by system packages.
[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 #21 from Hongtao.liu --- (In reply to H.J. Lu from comment #14) > Should we open a new bug for missed optimization? Missed optimization is fixed in GCC12.
[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 #20 from CVS Commits --- The master branch has been updated by hongtao Liu : https://gcc.gnu.org/g:7df89377a7ae3906255e38a79be8e5d962c3a0df commit r12-5486-g7df89377a7ae3906255e38a79be8e5d962c3a0df Author: liuhongt Date: Tue Nov 16 13:36:36 2021 +0800 Enhance optimize_atomic_bit_test_and to handle truncation. r12-5102-gfb161782545224f5 improves integer bit test on __atomic_fetch_[or|and]_* returns only for nop_convert, .i.e. transfrom mask_5 = 1 << bit_4(D); mask.0_1 = (unsigned int) mask_5; _2 = __atomic_fetch_or_4 (a_7(D), mask.0_1, 0); t1_9 = (int) _2; t2_10 = mask_5 & t1_9; to mask_5 = 1 << n_4(D); mask.1_1 = (unsigned int) mask_5; _11 = .ATOMIC_BIT_TEST_AND_SET (_a_1_4, n_4(D), 0); _8 = (int) _11; And this patch extend the original patch to handle truncation. .i.e. transform long int mask; mask_8 = 1 << n_7(D); mask.0_1 = (long unsigned int) mask_8; _2 = __sync_fetch_and_or_8 (_a_2_3, mask.0_1); _3 = (unsigned int) _2; _4 = (unsigned int) mask_8; _5 = _3 & _4; _6 = (int) _5; to long int mask; mask_8 = 1 << n_7(D); mask.0_1 = (long unsigned int) mask_8; _14 = .ATOMIC_BIT_TEST_AND_SET (_a_2_3, n_7(D), 0); _5 = (unsigned int) _14; _6 = (int) _5; 2021-11-17 Hongtao Liu H.J. Lu gcc/ChangeLog: PR tree-optimization/103194 * match.pd (gimple_nop_atomic_bit_test_and_p): Extended to match truncation. * tree-ssa-ccp.c (gimple_nop_convert): Declare. (optimize_atomic_bit_test_and): Enhance optimize_atomic_bit_test_and to handle truncation. gcc/testsuite/ChangeLog: * gcc.target/i386/pr103194-2.c: New test. * gcc.target/i386/pr103194-3.c: New test. * gcc.target/i386/pr103194-4.c: New test. * gcc.target/i386/pr103194-5.c: New test. * gcc.target/i386/pr103194.c: New test.
[Bug libstdc++/103400] src/c++98/*_allocator.cc symbols not exported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103400 --- Comment #2 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #0) > And --enable-libstdcxx-allocator=bitmap is completely broken, see PR 103381. Repeating PR 103381 comment 4: Every test fails with: /usr/bin/ld: .../libstdc++-v3/src/.libs/libstdc++.so: undefined reference to `__gnu_cxx::bitmap_allocator::_S_last_request' /usr/bin/ld: .../libstdc++-v3/src/.libs/libstdc++.so: undefined reference to `__gnu_cxx::bitmap_allocator, (__gnu_cxx::_Lock_policy)2> >::_S_mut' /usr/bin/ld: .../libstdc++-v3/src/.libs/libstdc++.so: undefined reference to `__gnu_cxx::bitmap_allocator, (__gnu_cxx::_Lock_policy)2> >::_S_mut' /usr/bin/ld: .../libstdc++-v3/src/.libs/libstdc++.so: undefined reference to `__gnu_cxx::bitmap_allocator, (__gnu_cxx::_Lock_policy)2> >::_S_mem_blocks' /usr/bin/ld: .../libstdc++-v3/src/.libs/libstdc++.so: undefined reference to `__gnu_cxx::bitmap_allocator, (__gnu_cxx::_Lock_policy)2> >::_S_last_request' /usr/bin/ld: .../libstdc++-v3/src/.libs/libstdc++.so: undefined reference to `__gnu_cxx::bitmap_allocator::_S_mut' /usr/bin/ld: .../libstdc++-v3/src/.libs/libstdc++.so: undefined reference to `__gnu_cxx::bitmap_allocator::_S_mem_blocks' /usr/bin/ld: .../libstdc++-v3/src/.libs/libstdc++.so: undefined reference to `__gnu_cxx::bitmap_allocator, (__gnu_cxx::_Lock_policy)2> >::_S_last_request' /usr/bin/ld: .../libstdc++-v3/src/.libs/libstdc++.so: undefined reference to `__gnu_cxx::bitmap_allocator, (__gnu_cxx::_Lock_policy)2> >::_S_mem_blocks'
[Bug libstdc++/103381] [9/10/11 Regression] --enable-libstdcxx-allocator=bitmap doesn't build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103381 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Jonathan Wakely --- The bootstrap failure is fixed. The linker error can be tracked by PR 103400
[Bug libstdc++/103381] [9/10/11 Regression] --enable-libstdcxx-allocator=bitmap doesn't build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103381 --- Comment #6 from CVS Commits --- The releases/gcc-9 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:4a641becb2c8fdca4e9c113b2dcf6cc5e8a6c04a commit r9-9840-g4a641becb2c8fdca4e9c113b2dcf6cc5e8a6c04a Author: Jonathan Wakely Date: Tue Nov 23 12:28:22 2021 + libstdc++: Fix circular dependency for bitmap_allocator [PR103381] includes , and since C++17 that includes . If std::allocator is defined in terms of __gnu_cxx::bitmap_allocator then you get a circular reference and bootstrap fails when compiling src/c++17/*.cc. libstdc++-v3/ChangeLog: PR libstdc++/103381 * include/ext/bitmap_allocator.h: Include instead of . (cherry picked from commit 5459fa132a99e6037e5ccf1b49d617677a584ff8)
[Bug libstdc++/103381] [9/10/11 Regression] --enable-libstdcxx-allocator=bitmap doesn't build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103381 --- Comment #5 from CVS Commits --- The releases/gcc-10 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:0a7a68872b425afb015d499c879e709fdd32616b commit r10-10290-g0a7a68872b425afb015d499c879e709fdd32616b Author: Jonathan Wakely Date: Tue Nov 23 12:28:22 2021 + libstdc++: Fix circular dependency for bitmap_allocator [PR103381] includes , and since C++17 that includes . If std::allocator is defined in terms of __gnu_cxx::bitmap_allocator then you get a circular reference and bootstrap fails when compiling src/c++17/*.cc. libstdc++-v3/ChangeLog: PR libstdc++/103381 * include/ext/bitmap_allocator.h: Include instead of . (cherry picked from commit 5459fa132a99e6037e5ccf1b49d617677a584ff8)
[Bug libstdc++/103400] src/c++98/*_allocator.cc symbols not exported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103400
--- Comment #1 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #0)
> Similarly, when built with --enable-libstdcxx-allocator=mt lots of tests
> fail, because the __gnu_cxx::__common_pool<__gnu_cxx::__pool,
> true>::_S_get_pool()::_S_pool static variable and its guard variable are not
> exported. That means the linker cannot combine the definition in
> libstdc++.so with the one in user code, and we get two copies of it. This
> means allocations and deallocations might happen in different pools, and so
> segfault.
nm /tmp/alloc/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so | fgrep
_S_pool
002205e8 b
_ZGVZN9__gnu_cxx13__common_poolINS_6__poolELb1EE11_S_get_poolEvE7_S_pool
00220600 b
_ZZN9__gnu_cxx13__common_poolINS_6__poolELb1EE11_S_get_poolEvE7_S_pool
They should have type 'u'. It can be fixed by:
--- a/libstdc++-v3/config/abi/pre/gnu.ver
+++ b/libstdc++-v3/config/abi/pre/gnu.ver
@@ -2400,6 +2400,8 @@ GLIBCXX_3.4.29 {
GLIBCXX_3.4.30 {
_ZSt21__glibcxx_assert_fail*;
+_ZGVZN9__gnu_cxx13__common_poolINS_6__poolELb1EE11_S_get_poolEvE7_S_pool;
+_ZZN9__gnu_cxx13__common_poolINS_6__poolELb1EE11_S_get_poolEvE7_S_pool;
} GLIBCXX_3.4.29;
[Bug fortran/103394] Bad object code for structure constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103394 --- Comment #1 from Neil Carlson --- I've experimented some more and have reduced things further to this example. I'm not positive it captures everything that is going wrong in the original. program example type :: foo end type type :: bar type(foo), pointer :: fptr end type class(foo), pointer :: f allocate(foo :: f) call sub(bar(f)) contains subroutine sub(b) type(bar), intent(in) :: b if (.not.associated(b%fptr, f)) stop 1 end subroutine end program The example works correctly if "class(foo), pointer :: f" is replaced by "type(foo), pointer :: f", so it seems pretty clear that intrinsic structure constructor is not properly making the assignment "bar%fptr => f".
[Bug libstdc++/103400] New: src/c++98/*_allocator.cc symbols not exported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103400 Bug ID: 103400 Summary: src/c++98/*_allocator.cc symbols not exported Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: link-failure Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: redi at gcc dot gnu.org Target Milestone: --- When GCC is configured with --enable-libstdcxx-allocator=pool we get this test failure: FAIL: 27_io/manipulators/standard/wchar_t/2.cc (test for excess errors) Excess errors: /usr/bin/ld: Dwarf Error: Can't find .debug_ranges section. 2.cc:(.text._ZNSt7__cxx1115basic_stringbufIwSt11char_traitsIwESaIwEED2Ev[_ZNSt7__cxx1115basic_stringbufIwSt11char_traitsIwESaIwEED5Ev]+0x44): undefined reference to `__gnu_cxx::__pool_alloc::deallocate(wchar_t*, unsigned long)' 2.cc:(.text._ZNSt7__cxx1115basic_stringbufIwSt11char_traitsIwESaIwEED0Ev[_ZNSt7__cxx1115basic_stringbufIwSt11char_traitsIwESaIwEED5Ev]+0x44): undefined reference to `__gnu_cxx::__pool_alloc::deallocate(wchar_t*, unsigned long)' 2.cc:(.text._Z6test01v+0x464): undefined reference to `__gnu_cxx::__pool_alloc::deallocate(wchar_t*, unsigned long)' 2.cc:(.text._Z6test01v+0x4c4): undefined reference to `__gnu_cxx::__pool_alloc::deallocate(wchar_t*, unsigned long)' 2.cc:(.text._Z6test01v+0x51c): undefined reference to `__gnu_cxx::__pool_alloc::deallocate(wchar_t*, unsigned long)' collect2: error: ld returned 1 exit status The specialization is explicitly instantiated in src/c++98/pool_allocator.cc: // Instantiations. template class __pool_alloc; template class __pool_alloc; But the symbols have never been exported, so dynamic link fails (static linking works though). Similarly, when built with --enable-libstdcxx-allocator=mt lots of tests fail, because the __gnu_cxx::__common_pool<__gnu_cxx::__pool, true>::_S_get_pool()::_S_pool static variable and its guard variable are not exported. That means the linker cannot combine the definition in libstdc++.so with the one in user code, and we get two copies of it. This means allocations and deallocations might happen in different pools, and so segfault. And --enable-libstdcxx-allocator=bitmap is completely broken, see PR 103381. it's not clear whether it's worth salvaging these extensions, or if we should just deprecate and them remove them.
[Bug libstdc++/103381] [9/10/11 Regression] --enable-libstdcxx-allocator=bitmap doesn't build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103381 --- Comment #4 from Jonathan Wakely --- Every test fails with: /usr/bin/ld: .../libstdc++-v3/src/.libs/libstdc++.so: undefined reference to `__gnu_cxx::bitmap_allocator::_S_last_request' /usr/bin/ld: .../libstdc++-v3/src/.libs/libstdc++.so: undefined reference to `__gnu_cxx::bitmap_allocator, (__gnu_cxx::_Lock_policy)2> >::_S_mut' /usr/bin/ld: .../libstdc++-v3/src/.libs/libstdc++.so: undefined reference to `__gnu_cxx::bitmap_allocator, (__gnu_cxx::_Lock_policy)2> >::_S_mut' /usr/bin/ld: .../libstdc++-v3/src/.libs/libstdc++.so: undefined reference to `__gnu_cxx::bitmap_allocator, (__gnu_cxx::_Lock_policy)2> >::_S_mem_blocks' /usr/bin/ld: .../libstdc++-v3/src/.libs/libstdc++.so: undefined reference to `__gnu_cxx::bitmap_allocator, (__gnu_cxx::_Lock_policy)2> >::_S_last_request' /usr/bin/ld: .../libstdc++-v3/src/.libs/libstdc++.so: undefined reference to `__gnu_cxx::bitmap_allocator::_S_mut' /usr/bin/ld: .../libstdc++-v3/src/.libs/libstdc++.so: undefined reference to `__gnu_cxx::bitmap_allocator::_S_mem_blocks' /usr/bin/ld: .../libstdc++-v3/src/.libs/libstdc++.so: undefined reference to `__gnu_cxx::bitmap_allocator, (__gnu_cxx::_Lock_policy)2> >::_S_last_request' /usr/bin/ld: .../libstdc++-v3/src/.libs/libstdc++.so: undefined reference to `__gnu_cxx::bitmap_allocator, (__gnu_cxx::_Lock_policy)2> >::_S_mem_blocks' So this configure option seems broken, and nobody seems to have noticed.
[Bug tree-optimization/103388] [12 Regression] missed optimization for dead code elimination at -O3 (vs. -O2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103388 Jeffrey A. Law changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |law at gcc dot gnu.org --- Comment #3 from Jeffrey A. Law --- So to fix this right we'd need to duplicate some of the logic in tree-ssa-threadupdate.c. Conceptually for block B where one or more predecessors thread to target T, you make a single copy B', and redirect *all* the relevant predecessors to B'. In addition to allowing more aggressive threading, it would also reduce codesize since currently we'll end up with multiple copies of B'. We have optimizers that are supposed to clean that up, but I've never seen them do a particularly good job. This isn't likely to land in gcc-12. An interim approach might be to go ahead and register the thread and only reject it for size later if we're going to end up with multiple copies. After all this is a cost analysis question and we don't know until all the paths are registered if it's profitable or not. Anyway, it should probably be assigned to me. Not sure if I'll get to the interim approach or not for gcc-12. I'll have to poke around a bit.
[Bug c++/103375] [12 regression] -Werror=uninitialized false positive on unittest-cpp since r12-5391-g0790c8aacdfb4f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103375 Marek Polacek changed: What|Removed |Added Resolution|--- |INVALID Status|NEW |RESOLVED --- Comment #4 from Marek Polacek --- The reduced test no longer warns. The unreduced warns, but that seems to be a good thing, just switch the order of these: 23480 TestRunner runner; 23481 RecordingReporter reporter; Not a bug, IMHO.
[Bug target/101985] vec_cpsgn parameter order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101985 Bill Schmidt changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from Bill Schmidt --- Now fixed everywhere.
[Bug target/101985] vec_cpsgn parameter order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101985 --- Comment #9 from CVS Commits --- The releases/gcc-9 branch has been updated by William Schmidt : https://gcc.gnu.org/g:4326a1cd664e56167ed23de8beecfe250f466fcb commit r9-9839-g4326a1cd664e56167ed23de8beecfe250f466fcb Author: Bill Schmidt Date: Tue Nov 23 16:14:01 2021 -0600 rs6000: Fix vec_cpsgn parameter order (PR101985) Backport r12-4361 to releases/gcc-9. 2021-11-23 Bill Schmidt gcc/ PR target/101985 * config/rs6000/altivec.h (vec_cpsgn): Swap operand order. gcc/testsuite/ PR target/101985 * gcc.target/powerpc/pr101985-1.c: New. * gcc.target/powerpc/pr101985-2.c: New.
[Bug c++/87403] [Meta-bug] Issues that suggest a new warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87403 Bug 87403 depends on bug 88232, which changed state. Bug 88232 Summary: Please implement -Winfinite-recursion https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88232 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug middle-end/88232] Please implement -Winfinite-recursion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88232 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |12.0 --- Comment #6 from Martin Sebor --- Done for GCC 12.
[Bug c/103360] [meta-bug] bogus/missing -Waddress
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103360 Bug 103360 depends on bug 96507, which changed state. Bug 96507 Summary: missing -Waddress for member references https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96507 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/96507] missing -Waddress for member references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96507 Martin Sebor changed: What|Removed |Added Target Milestone|--- |12.0 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Martin Sebor --- Fixed in GCC 12.
[Bug target/101985] vec_cpsgn parameter order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101985 --- Comment #8 from CVS Commits --- The releases/gcc-10 branch has been updated by William Schmidt : https://gcc.gnu.org/g:049aa656393299d2ff23f0292c6f49e5057e2909 commit r10-10289-g049aa656393299d2ff23f0292c6f49e5057e2909 Author: Bill Schmidt Date: Tue Nov 23 15:57:27 2021 -0600 rs6000: Fix vec_cpsgn parameter order (PR101985) Backport r12-4361 to releases/gcc-10. 2021-11-23 Bill Schmidt gcc/ PR target/101985 * config/rs6000/altivec.h (vec_cpsgn): Swap operand order. gcc/testsuite/ PR target/101985 * gcc.target/powerpc/pr101985-1.c: New. * gcc.target/powerpc/pr101985-2.c: New.
[Bug c++/96507] missing -Waddress for member references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96507 --- Comment #3 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:2dd56aed3e4e1938a9020ab2fe6a410e1a1c2eb3 commit r12-5484-g2dd56aed3e4e1938a9020ab2fe6a410e1a1c2eb3 Author: Martin Sebor Date: Tue Nov 23 15:35:31 2021 -0700 Issue -Waddress also for reference members [PR96507]. Resolves: PR c++/96507 - missing -Waddress for member references gcc/cp/ChangeLog: PR c++/96507 * typeck.c (warn_for_null_address): Handle reference members. gcc/testsuite/ChangeLog: PR c++/96507 * g++.dg/warn/Waddress-8.C: New test.
[Bug middle-end/88232] Please implement -Winfinite-recursion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88232 --- Comment #5 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:30ba058f77eedfaf7a0582f5d42aff949710bce4 commit r12-5483-g30ba058f77eedfaf7a0582f5d42aff949710bce4 Author: Martin Sebor Date: Tue Nov 23 15:30:29 2021 -0700 Implement -Winfinite-recursion [PR88232]. Resolves: PR middle-end/88232 - Please implement -Winfinite-recursion gcc/ChangeLog: PR middle-end/88232 * Makefile.in (OBJS): Add gimple-warn-recursion.o. * common.opt: Add -Winfinite-recursion. * doc/invoke.texi (-Winfinite-recursion): Document. * passes.def (pass_warn_recursion): Schedule a new pass. * tree-pass.h (make_pass_warn_recursion): Declare. * gimple-warn-recursion.c: New file. gcc/c-family/ChangeLog: PR middle-end/88232 * c.opt: Add -Winfinite-recursion. gcc/testsuite/ChangeLog: PR middle-end/88232 * c-c++-common/attr-used-5.c: Suppress valid warning. * c-c++-common/attr-used-6.c: Same. * c-c++-common/attr-used-9.c: Same. * g++.dg/warn/Winfinite-recursion-2.C: New test. * g++.dg/warn/Winfinite-recursion-3.C: New test. * g++.dg/warn/Winfinite-recursion.C: New test. * gcc.dg/Winfinite-recursion-2.c: New test. * gcc.dg/Winfinite-recursion.c: New test.
[Bug tree-optimization/103399] New: [12 Regression] Wrong code with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103399
Bug ID: 103399
Summary: [12 Regression] Wrong code with -O2
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: vsevolod.livinskij at frtk dot ru
Target Milestone: ---
Link to the Compiler Explorer: https://godbolt.org/z/3GE6fKvYr
Reproducer:
#include
char a = 0;
long long b[8][10][18];
void e(int, long long[][10][18]) __attribute__((noipa));
void e(int f, long long g[][10][18]) {
for (int d = 0; d < f; d += 3LL)
for (int c = 0; c < ((f ? g[5][0][0] : 0) ^ g[5][0][0]) + 1; c++)
a = 42;
}
int main() {
for (size_t i = 0; i < 8; ++i)
for (size_t k = 0; k < 10; ++k)
for (size_t j = 0; j < 8; ++j)
b[i][k][j] = -1311387439415292401LL;
e(8, b);
printf("%u\n", a);
if (a != 42)
__builtin_abort();
}
Error:
>$ g++ -O1 driver.cpp && ./a.out
42
>$ g++ -O2 driver.cpp && ./a.out
0
gcc version 12.0.0 20211123 (721d8b9e26bf8205c1f2125c2626919a408cdbe4) (GCC)
[Bug driver/103398] configure: Enable --enable-default-pie by default for Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103398 Andrew Pinski changed: What|Removed |Added Resolution|--- |WONTFIX Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- No. The whole reason why there is an option is because it is optional.
[Bug target/103395] [9/10/11/12 Regression] ICE on qemu in arm create_fix_barrier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103395 --- Comment #1 from Richard W.M. Jones --- Nice reproducer! Here's the original thread where the bug was reported when compiling qemu on Fedora Rawhide for armv7: https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/GD3ABSWD6HHTNEKV2EJY4PXABQ245UCZ/
[Bug driver/103398] New: configure: Enable --enable-default-pie by default for Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103398 Bug ID: 103398 Summary: configure: Enable --enable-default-pie by default for Linux Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver Assignee: unassigned at gcc dot gnu.org Reporter: i at maskray dot me Target Milestone: --- Many Linux distros configure GCC with --enable-default-pie (at least Arch/Debian/Fedora/Gentoo/Ubuntu). I think it makes sense to default to --enable-default-pie for Linux.
[Bug libstdc++/103086] [11 Regression] std::unique_ptr printer gets confused by [[no_unique_address]] in tuple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103086 --- Comment #7 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:c59ec55c3459fba619e05ee7f59480b71e85ffd7 commit r12-5482-gc59ec55c3459fba619e05ee7f59480b71e85ffd7 Author: Jonathan Wakely Date: Tue Nov 23 21:35:40 2021 + libstdc++: Add another testcase for std::unique_ptr printer [PR103086] libstdc++-v3/ChangeLog: PR libstdc++/103086 * testsuite/libstdc++-prettyprinters/cxx11.cc: Check unique_ptr with non-empty pointer and non-empty deleter.
[Bug c/79074] -Waddress difference between C and C++ with (T*)0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79074
Martin Sebor changed:
What|Removed |Added
Known to fail||10.2.0, 11.2.0, 12.0,
||7.3.0, 8.3.0, 9.2.0
Last reconfirmed|2017-01-12 00:00:00 |2021-11-23
--- Comment #3 from Martin Sebor ---
No change in GCC 12. The inequality test below is still not diagnosed in C
(but is in C++):
int g (int i) { return != (int *) 0; }
[Bug target/101985] vec_cpsgn parameter order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101985 --- Comment #7 from CVS Commits --- The releases/gcc-11 branch has been updated by William Schmidt : https://gcc.gnu.org/g:8fb9bf6667db0c9bac4145fcc02280b8d3133a27 commit r11-9272-g8fb9bf6667db0c9bac4145fcc02280b8d3133a27 Author: Bill Schmidt Date: Tue Nov 23 14:33:18 2021 -0600 rs6000: Fix vec_cpsgn parameter order (PR101985) Backport r12-4361 to releases/gcc-11. 2021-11-23 Bill Schmidt gcc/ PR target/101985 * config/rs6000/altivec.h (vec_cpsgn): Swap operand order. gcc/testsuite/ PR target/101985 * gcc.target/powerpc/pr101985-1.c: New. * gcc.target/powerpc/pr101985-2.c: New.
[Bug target/103396] [12 Regression][GCN][BUILD] ICE RTL check: access of elt 4 of vector with last elt 3 in move_callee_saved_registers, at config/gcn/gcn.c:2821
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103396 Tobias Burnus changed: What|Removed |Added Summary|[GCN][BUILD] ICE RTL check: |[12 Regression][GCN][BUILD] |access of elt 4 of vector |ICE RTL check: access of |with last elt 3 in |elt 4 of vector with last |move_callee_saved_registers |elt 3 in |, at config/gcn/gcn.c:2821 |move_callee_saved_registers ||, at config/gcn/gcn.c:2821 Target Milestone|--- |12.0
[Bug libstdc++/103387] powerpc64le: segmentation fault on std::cout with ieee128 long double variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103387 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |12.0 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug target/103396] [GCN][BUILD] ICE RTL check: access of elt 4 of vector with last elt 3 in move_callee_saved_registers, at config/gcn/gcn.c:2821
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103396
--- Comment #3 from Tobias Burnus ---
Created attachment 51864
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51864=edit
Reduced testcase – compile with -O2 -march=gfx900 / gfx906 / gfx908
Note: No ICE with -match=fiji
ICE at:
Breakpoint 1, move_callee_saved_registers (sp=0x773090f0,
offsets=0x77402e00, prologue=true)
at gcc-mainline/gcc/config/gcn/gcn.c:2821
2821RTVEC_ELT (seq, count) = set;
with
(gdb) p debug_rtx(sp)
(reg/f:DI 16 s16)
(gdb) p debug_rtx(set)
(set/f (mem:DI (plus:DI (reg/f:DI 16 s16)
(const_int 8 [0x8])) [0 S8 A64])
(reg:DI 420 ?dwlr))
$18 = void
(gdb) p count
$8 = 4
(gdb) p *seq
$10 = {num_elem = 4, elem = {0x7742ef30}}
(gdb) p *seq.elem
$11 = (rtx) 0x7742ef30
(gdb) p seq.elem[0]
$12 = (rtx) 0x7742ef30
(gdb) p debug_rtx(seq.elem[0])
(set/f (mem:SI (plus:DI (reg/f:DI 16 s16)
(const_int 0 [0])) [0 S4 A32])
(reg:SI 14 s14))
$13 = void
(gdb) p debug_rtx(seq.elem[1])
(set/f (mem:SI (plus:DI (reg/f:DI 16 s16)
(const_int 4 [0x4])) [0 S4 A32])
(reg:SI 15 s15))
$14 = void
(gdb) p debug_rtx(seq.elem[2])
(set/f (mem:SI (plus:DI (reg/f:DI 16 s16)
(const_int 8 [0x8])) [0 S4 A32])
(reg:SI 18 s18))
$15 = void
(gdb) p debug_rtx(seq.elem[3])
(set/f (mem:SI (plus:DI (reg/f:DI 16 s16)
(const_int 12 [0xc])) [0 S4 A32])
(reg:SI 19 s19))
$16 = void
[Bug fortran/103367] [10/11/12 Regression] ICE in gfc_conv_array_initializer, at fortran/trans-array.c:6377 since r12-4278-g74ccca380cde5e79
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103367 --- Comment #3 from anlauf at gcc dot gnu.org --- The 'real' index 'b' is a red herring. Replacing it e.g. by an undefined 'm' generates the same backtrace. Also replacing the bad code line by integer, parameter :: y(1,2) = (x(m)%a) ! ICE-on-invalid reproduces the issue.
[Bug libstdc++/103187] std::counting_semaphore::try_acquire_for does not unblock during wait duration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103187 --- Comment #3 from Jonathan Wakely --- I've backported that fix for GCC 11.3 but I want to keep this open to get to the bottom of the underlying bug.
[Bug libstdc++/103086] [11 Regression] std::unique_ptr printer gets confused by [[no_unique_address]] in tuple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103086 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Jonathan Wakely --- The regression caused by [[no_unique_address] and ambiguous field accesses is fixed. I'll backport it to fix the latent bug on the other branches.
[Bug libstdc++/103086] [11 Regression] std::unique_ptr printer gets confused by [[no_unique_address]] in tuple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103086 --- Comment #5 from CVS Commits --- The releases/gcc-11 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:fa4a8f3faaa1172b103c6a148a7830e7e6375cc3 commit r11-9271-gfa4a8f3faaa1172b103c6a148a7830e7e6375cc3 Author: Jonathan Wakely Date: Thu Nov 4 22:50:02 2021 + libstdc++: Fix pretty printing of std::unique_ptr [PR103086] Since std::tuple started using [[no_unique_address]] the tuple member of std::unique_ptr has two _M_head_impl subobjects, in different base classes. That means this printer code is ambiguous: tuple_head_type = tuple_impl_type.fields()[1].type # _Head_base head_field = tuple_head_type.fields()[0] if head_field.name == '_M_head_impl': self.pointer = tuple_member['_M_head_impl'] In older versions of GDB it happened to work by chance, because GDB returned the last _M_head_impl member and std::tuple's base classes are stored in reverse order, so the last one was the T* element of the tuple. Since GDB 11 it returns the first _M_head_impl, which is the deleter element. The fix is for the printer to stop using an ambiguous field name and cast the tuple to the correct base class before accessing the _M_head_impl member. Instead of fixing this in both UniquePointerPrinter and StdPathPrinter a new unique_ptr_get function is defined to do it correctly. That is defined in terms of new tuple_get and _tuple_impl_get functions. It would be possible to reuse _tuple_impl_get to access each element in StdTuplePrinter._iterator.__next__, but that already does the correct casting, and wouldn't be much simpler anyway. libstdc++-v3/ChangeLog: PR libstdc++/103086 * python/libstdcxx/v6/printers.py (_tuple_impl_get): New helper for accessing the tuple element stored in a _Tuple_impl node. (tuple_get): New function for accessing a tuple element. (unique_ptr_get): New function for accessing a unique_ptr. (UniquePointerPrinter, StdPathPrinter): Use unique_ptr_get. * python/libstdcxx/v6/xmethods.py (UniquePtrGetWorker): Cast tuple to its base class before accessing _M_head_impl. (cherry picked from commit a634928f5c8a281442ac8f5fb1636aed048ed72c)
[Bug libstdc++/103240] std::type_info::before gives wrong answer for ARM EABI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103240 --- Comment #3 from CVS Commits --- The releases/gcc-11 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:ec6ba81a038be488cec5e3bdc4f30b7876d9c5ea commit r11-9270-gec6ba81a038be488cec5e3bdc4f30b7876d9c5ea Author: Jonathan Wakely Date: Tue Nov 16 21:03:21 2021 + libstdc++: Fix std::type_info::before for ARM [PR103240] The r179236 fix for std::type_info::operator== should also have been applied to std::type_info::before. Otherwise two distinct types can compare equivalent due to using a string comparison, when they should do a pointer comparison. libstdc++-v3/ChangeLog: PR libstdc++/103240 * libsupc++/tinfo2.cc (type_info::before): Use unadjusted name to check for the '*' prefix. * testsuite/util/testsuite_shared.cc: Add type_info object for use in new test. * testsuite/18_support/type_info/103240.cc: New test. (cherry picked from commit 054bf99841aad3869c70643b2ba2d9f85770c980)
[Bug libstdc++/103381] [9/10/11 Regression] --enable-libstdcxx-allocator=bitmap doesn't build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103381 --- Comment #3 from CVS Commits --- The releases/gcc-11 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:9a7308bac8c9a90c153a6f25f0c9bf7e2a0f2e73 commit r11-9269-g9a7308bac8c9a90c153a6f25f0c9bf7e2a0f2e73 Author: Jonathan Wakely Date: Tue Nov 23 12:28:22 2021 + libstdc++: Fix circular dependency for bitmap_allocator [PR103381] includes , and since C++17 that includes . If std::allocator is defined in terms of __gnu_cxx::bitmap_allocator then you get a circular reference and bootstrap fails when compiling src/c++17/*.cc. libstdc++-v3/ChangeLog: PR libstdc++/103381 * include/ext/bitmap_allocator.h: Include instead of . (cherry picked from commit 5459fa132a99e6037e5ccf1b49d617677a584ff8)
[Bug libstdc++/101571] DestroyGuard used by the ranges::uninitialized family should use addressof()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101571 --- Comment #5 from CVS Commits --- The releases/gcc-11 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:667339efd8ee10079aac9684c5d1c9c9b28d9da6 commit r11-9268-g667339efd8ee10079aac9684c5d1c9c9b28d9da6 Author: Jonathan Wakely Date: Thu Jul 22 14:37:24 2021 +0100 libstdc++: Use std::addressof in ranges::uninitialized_xxx [PR101571] Make the ranges::uninitialized_xxx algorithms use std::addressof to protect against iterator types that overload operator&. Signed-off-by: Jonathan Wakely libstdc++-v3/ChangeLog: PR libstdc++/101571 * include/bits/ranges_uninitialized.h (_DestroyGuard): Change constructor parameter to reference and use addressof. * testsuite/util/testsuite_iterators.h: Define deleted operator& overloads for test iterators. (cherry picked from commit aca7a0253d6e3116f846ad530b19d89644a64267)
[Bug target/103396] [GCN][BUILD] ICE RTL check: access of elt 4 of vector with last elt 3 in move_callee_saved_registers, at config/gcn/gcn.c:2821
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103396 --- Comment #2 from Andrew Pinski --- Is the cross compiler built with this GCC that includes this patch or this patch just exposing a bug in the backend?
[Bug target/103396] [GCN][BUILD] ICE RTL check: access of elt 4 of vector with last elt 3 in move_callee_saved_registers, at config/gcn/gcn.c:2821
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103396 Andrew Pinski changed: What|Removed |Added CC||tschwinge at gcc dot gnu.org --- Comment #1 from Andrew Pinski --- *** Bug 103397 has been marked as a duplicate of this bug. ***
[Bug target/103397] [12 Regression] GCN target '-march=gfx900' libgfortran build broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103397 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Dup of bug 103396. *** This bug has been marked as a duplicate of bug 103396 ***
[Bug target/103397] New: [12 Regression] GCN target '-march=gfx900' libgfortran build broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103397 Bug ID: 103397 Summary: [12 Regression] GCN target '-march=gfx900' libgfortran build broken Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: tschwinge at gcc dot gnu.org CC: ams at gcc dot gnu.org, jules at gcc dot gnu.org Target Milestone: --- Target: GCN GCN target '-march=gfx900' libgfortran build broken: [xgcc] [...] -march=gfx900 [...] -c [...]/source-gcc/libgfortran/runtime/environ.c -o environ.o In file included from [...]/source-gcc/libgfortran/runtime/environ.c:29: [...]/source-gcc/libgfortran/runtime/environ.c: In function ‘init_integer’: [...]/source-gcc/libgfortran/runtime/environ.c:94:19: warning: array subscript has type ‘char’ [-Wchar-subscripts] 94 | if (!isdigit (*q) && (p != q || *q != '-')) | ^~ [...]/source-gcc/libgfortran/runtime/environ.c: In function ‘match_integer’: [...]/source-gcc/libgfortran/runtime/environ.c:347:19: warning: array subscript has type ‘char’ [-Wchar-subscripts] 347 | while (isdigit (*p)) | ^~ during RTL pass: pro_and_epilogue [...]/source-gcc/libgfortran/runtime/environ.c: In function ‘search_unit’: [...]/source-gcc/libgfortran/runtime/environ.c:319:1: internal compiler error: RTL check: access of elt 4 of vector with last elt 3 in move_callee_saved_registers, at config/gcn/gcn.c:2821 319 | } | ^ 0x5b8b27 rtvec_check_failed_bounds(rtvec_def const*, int, char const*, int, char const*) [...]/source-gcc/gcc/rtl.c:976 0x11af5d2 move_callee_saved_registers [...]/source-gcc/gcc/config/gcn/gcn.c:2821 0x11afc2b gcn_expand_prologue() [...]/source-gcc/gcc/config/gcn/gcn.c:2939 0x156b02a gen_prologue() [...]/source-gcc/gcc/config/gcn/gcn.md:714 0x11a3e98 target_gen_prologue ./insn-target-def.h:433 0x9bded7 make_prologue_seq [...]/source-gcc/gcc/function.c:5823 0x9be063 thread_prologue_and_epilogue_insns() [...]/source-gcc/gcc/function.c:6041 0x9beac2 rest_of_handle_thread_prologue_and_epilogue [...]/source-gcc/gcc/function.c:6532 0x9beac2 execute [...]/source-gcc/gcc/function.c:6608 This appears with recent commit r12-5436-gdc915b361bbc99da83fc53db7f7e0e28d0ce12c8 "Tweak tree-ssa-math-opts.c to solve PR target/102117". It may well be a latent issue in the GCN target, '-march=gfx900' specifically, instead of a problem with that commit specifically? (Locally reverting that commit does unblock the build.)
[Bug fortran/103392] [9/10/11/12 Regression] ICE in simplify_bound, at fortran/simplify.c:4273
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103392 --- Comment #4 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:16e95050f71e9fa408e9bd8ccd415b0e7adc66e5 commit r12-5480-g16e95050f71e9fa408e9bd8ccd415b0e7adc66e5 Author: Harald Anlauf Date: Tue Nov 23 21:39:36 2021 +0100 Fortran: do not attempt simplification of [LU]BOUND for pointer/allocatable gcc/fortran/ChangeLog: PR fortran/103392 * simplify.c (simplify_bound): Do not try to simplify LBOUND/UBOUND for arrays with POINTER or ALLOCATABLE attribute. gcc/testsuite/ChangeLog: PR fortran/103392 * gfortran.dg/bound_simplification_7.f90: New test.
[Bug target/103396] New: [GCN][BUILD] ICE RTL check: access of elt 4 of vector with last elt 3 in move_callee_saved_registers, at config/gcn/gcn.c:2821
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103396 Bug ID: 103396 Summary: [GCN][BUILD] ICE RTL check: access of elt 4 of vector with last elt 3 in move_callee_saved_registers, at config/gcn/gcn.c:2821 Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: build, ice-on-valid-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org CC: ams at gcc dot gnu.org, rdapp at gcc dot gnu.org, sayle at gcc dot gnu.org Target Milestone: --- Host: x86_64-gnu-linux Target: amdgcn-amdhsa Bisecting points at r12-5436-gdc915b361bbc99da83fc53db7f7e0e28d0ce12c8 Date: Sun Nov 21 11:40:08 2021 + Tweak tree-ssa-math-opts.c to solve PR target/102117. ... 2021-11-21 Roger Sayle Robin Dapp gcc/ChangeLog PR target/102117 * tree-ssa-math-opts.c (convert_mult_to_widen): Recognize signed WIDEN_MULT_EXPR if the target supports umul_widen_optab. ... Compiling libgfortran/runtime/environ.c during bootstrap with -march=gfx900 -O2 fails with: during RTL pass: pro_and_epilogue libgfortran/runtime/environ.c: In function 'search_unit': libgfortran/runtime/environ.c:319:1: internal compiler error: RTL check: access of elt 4 of vector with last elt 3 in move_callee_saved_registers, at config/gcn/gcn.c:2821 319 | } | ^ 0x908087 rtvec_check_failed_bounds(rtvec_def const*, int, char const*, int, char const*) gcc-mainline/gcc/rtl.c:975 0x9aa041 move_callee_saved_registers gcc-mainline/gcc/config/gcn/gcn.c:2821 0x14679cf gcn_expand_prologue() gcc-mainline/gcc/config/gcn/gcn.c:2939 0x17d331a gen_prologue() gcc-mainline/gcc/config/gcn/gcn.md:714 0x1460758 target_gen_prologue ./insn-target-def.h:433 0xdb3537 make_prologue_seq gcc-mainline/gcc/function.c:5823 0xdb36c2 thread_prologue_and_epilogue_insns()
[Bug fortran/103392] [9/10/11/12 Regression] ICE in simplify_bound, at fortran/simplify.c:4273
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103392 anlauf at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org Priority|P3 |P4 Status|NEW |ASSIGNED --- Comment #3 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2021-November/057054.html
[Bug tree-optimization/103221] evrp removes |SIGN but does not propagate the ssa name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103221 Andrew Macleod changed: What|Removed |Added CC||amacleod at redhat dot com --- Comment #2 from Andrew Macleod --- I can tweak it so that we do register the equivalence with ranger by reprocessing statements after a successful simplify or fold: === BB 3 a_2(D) signed char [-INF, -1] Equivalence set : [a_2(D), v_4] : v_4 = a_2(D); v_4 : signed char [-INF, -1] === BB 4 : # v_1 = PHI but it doesn't buy us much on its own. Later passes propagate a_2 into the PHI and then fold the PHI into a copy regardless. We could in theory do that in EVRP too, but it seems like something copy propagation or PHI-opt would handle more naturally. The arguments can come from an arbitrary list of equivalences and yet resolve to the same value... but we need to pick the right one. That said, its probably worth getting the equivalence added because that could be useful in other ways too.
[Bug c++/103379] ICE: tree check: expected class 'type', have 'declaration' (namespace_decl) in comptypes, at cp/typeck.c:1544
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103379 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org Status|UNCONFIRMED |NEW Last reconfirmed||2021-11-23 Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Confirmed, but clang++ accepts it, so probably valid code.
[Bug c++/19808] miss a warning about uninitialized member usage in member initializer list in constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19808 --- Comment #56 from CVS Commits --- The trunk branch has been updated by Marek Polacek : https://gcc.gnu.org/g:4b1d3d8d732bea86c7b2aba46c2a437461020824 commit r12-5479-g4b1d3d8d732bea86c7b2aba46c2a437461020824 Author: Marek Polacek Date: Fri Nov 19 14:22:10 2021 -0500 c++: -Wuninitialized for mem-inits and empty classes [PR19808] This fixes a bogus -Wuninitialized warning: there's nothing to initialize in empty classes, so don't add them into our uninitialized set. PR c++/19808 gcc/cp/ChangeLog: * init.c (emit_mem_initializers): Don't add is_really_empty_class members into uninitialized. gcc/testsuite/ChangeLog: * g++.dg/warn/Wuninitialized-28.C: Make a class nonempty. * g++.dg/warn/Wuninitialized-29.C: Likewise. * g++.dg/warn/Wuninitialized-31.C: New test.
[Bug fortran/103392] [9/10/11/12 Regression] ICE in simplify_bound, at fortran/simplify.c:4273
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103392 anlauf at gcc dot gnu.org changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2021-11-23 CC||anlauf at gcc dot gnu.org --- Comment #2 from anlauf at gcc dot gnu.org --- Confirmed. Tentative patch: diff --git a/gcc/fortran/simplify.c b/gcc/fortran/simplify.c index 6a6b3fbd037..477fd095b2d 100644 --- a/gcc/fortran/simplify.c +++ b/gcc/fortran/simplify.c @@ -4266,6 +4266,9 @@ simplify_bound (gfc_expr *array, gfc_expr *dim, gfc_expr *kind, int upper) || (as->type == AS_ASSUMED_SHAPE && upper))) return NULL; + if (gfc_expr_attr (array).allocatable || gfc_expr_attr (array).pointer) +return NULL; + gcc_assert (!as || (as->type != AS_DEFERRED && array->expr_type == EXPR_VARIABLE
[Bug target/93453] PPC: rldimi not taken into account to avoid shift+or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93453
--- Comment #7 from Segher Boessenkool ---
(In reply to HaoChen Gui from comment #6)
> Yes, I found that the nonzero_bits doesn't return exact value in other
> pass.
It returns a different value. Neither is "exact".
The version used by combine uses what combine keeps track of in reg_stat. What
that records depends on the order combine tries its combinations, and on which
succeed as well: it is suboptimal.
The version used outside of combine does not keep track of known values at all.
This is worse.
> So calling nonzero_bits in md file is bad as it can't be recognized in
> other pass.
An insn that matches in one pass is required to match in the next as well, yes.
This does not mean you cannot use nonzero_bits at all, but yes it is close.
> Right now I want to convert a single pseudo to the pseudo AND with a mask
> in combine pass if its nonzero_bits is less than its mode mask and the outer
> operation is plus/ior/xor and its one of inner operation is
> ashift/lshiftrt/and. Thus it is possible to match rotate and insert pattern.
> What's your opinion? Thanks a lot.
>
> (ior:DI (ashift:DI (reg:DI 125)
> (const_int 32 [0x20]))
> (reg:DI 126)))
>
> is converted to
>
> (ior:DI (ashift:DI (reg:DI 125)
>(const_int 32 [0x20]))
> (and:DI (reg:DI 126)
> (const_int 4294967295 [0xfff]
In this example it isn't invalid RTL.
> diff --git a/gcc/combine.c b/gcc/combine.c
> index 892c834a160..8b72a5ec831 100644
> --- a/gcc/combine.c
> +++ b/gcc/combine.c
> @@ -11539,6 +11539,26 @@ change_zero_ext (rtx pat)
>return changed;
> }
>
> +/* Convert a psuedo to psuedo AND with a mask if its nonzero_bits is less
> + than its mode mask. */
> +static bool
> +pseudo_and_with_mask (rtx *reg)
> +{
> + bool changed = false;
> + gcc_assert (REG_P (*reg));
> +
> + machine_mode mode = GET_MODE (*reg);
> + unsigned HOST_WIDE_INT nonzero = nonzero_bits (*reg, mode);
> + if (nonzero < GET_MODE_MASK (mode))
> +{
> + rtx x = gen_rtx_AND (mode, *reg, GEN_INT (nonzero));
> + SUBST (*reg, x);
> + changed = true;
> + //fprintf (stdout, "PIX optimization\n");
> +}
> + return changed;
> +}
> +
> /* Like recog, but we receive the address of a pointer to a new pattern.
> We try to match the rtx that the pointer points to.
> If that fails, we may try to modify or replace the pattern,
> @@ -11565,9 +11585,34 @@ recog_for_combine (rtx *pnewpat, rtx_insn *insn,
> rtx *pnotes)
>
>void *marker = get_undo_marker ();
>bool changed = false;
> + //bool PIX_opt = false;
>
>if (GET_CODE (pat) == SET)
> -changed = change_zero_ext (pat);
> +{
> + rtx src = SET_SRC (pat);
> + if ((GET_CODE (src) == IOR
> + || GET_CODE (src) == XOR
> + || GET_CODE (src) == PLUS)
> + && (((GET_CODE (XEXP (src, 0)) == ASHIFT
> + || GET_CODE (XEXP (src, 0)) == LSHIFTRT
> + || GET_CODE (XEXP (src, 0)) == AND)
> + && REG_P (XEXP (src, 1)))
> + || ((GET_CODE (XEXP (src, 1)) == ASHIFT
> + || GET_CODE (XEXP (src, 1)) == LSHIFTRT
> + || GET_CODE (XEXP (src, 1)) == AND)
> + && REG_P (XEXP (src, 0)
> + {
> + changed = REG_P (XEXP (src, 0))
> + ? pseudo_and_with_mask ( (SET_SRC (pat), 0))
> + : pseudo_and_with_mask ( (SET_SRC (pat), 1));
> + if (changed)
> + {
> + maybe_swap_commutative_operands (SET_SRC (pat));
> + //PIX_opt = true;
> + }
> + }
> + changed |= change_zero_ext (pat);
> +}
>else if (GET_CODE (pat) == PARALLEL)
> {
>int i;
> @@ -11585,6 +11630,8 @@ recog_for_combine (rtx *pnewpat, rtx_insn *insn, rtx
> *pnotes)
>
>if (insn_code_number < 0)
> undo_to_marker (marker);
> + //else if (PIX_opt)
> + //fprintf (stdout, "PIX applied\n");
> }
>
>return insn_code_number;
I don't like this at all. Maybe it will look better if you split this out
to a new helper like change_zero_ext? That will make it clearer if and how
these change things interact: they should not make us try out an exponential
number of things (you don't cause that here, good), but also they should not
negatively affect each other, and that isn't clear at all as written.
Another problem is this is kind of giving up and trying to solve a problem
in combine itself with this band-aid, while the existing change_* stuff is
battling a problem in the design of RTL itself. That can be solved by
clarifying things in a comment of course :-)
[Bug target/103395] [9/10/11/12 Regression] ICE on qemu in arm create_fix_barrier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103395 Jakub Jelinek changed: What|Removed |Added Target Milestone|--- |9.5 CC||rjones at redhat dot com Priority|P3 |P2
[Bug target/103395] New: [9/10/11/12 Regression] ICE on qemu in arm create_fix_barrier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103395
Bug ID: 103395
Summary: [9/10/11/12 Regression] ICE on qemu in arm
create_fix_barrier
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
Since GCC 5 (r208990 still works fine, r215478 ICEs already up to current
trunk)
the following testcase ICEs on armv7hl-linux-gnueabi with -O2:
void
foo (void)
{
__asm__ ("\n\n\n\n\n\n\n\n\n\n"
"\n\n\n\n\n\n\n\n\n\n"
"\n\n\n\n\n\n\n\n\n\n"
"\n\n\n\n\n\n\n\n\n\n"
"\n\n\n\n\n\n\n\n\n\n"
"\n\n\n\n\n\n\n\n\n\n"
"\n" : : "nor" (0), "nor" (0));
}
Removing just one newline makes the ICE go away. get_attr_length for such
inline asm is 248 bytes (estimation) and the arm minipool code is apparently
upset about it.
[Bug tree-optimization/103388] [12 Regression] missed optimization for dead code elimination at -O3 (vs. -O2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103388
Aldy Hernandez changed:
What|Removed |Added
CC||law at gcc dot gnu.org
Resolution|DUPLICATE |---
Status|RESOLVED|NEW
Last reconfirmed||2021-11-23
Ever confirmed|0 |1
--- Comment #2 from Aldy Hernandez ---
(In reply to Aldy Hernandez from comment #1)
> By *.threadfull1 this is the path at 4->5->7. It looks like:
>
> PREHEADER
> |
> v
> HEADER+
> | |
> V
> UNREACHABLE |
> |/
> V /
> return 0 <-+
>
> This is more or less PR102981.
>
> Is there any way we can stop reporting the same thing over and over?
>
> *** This bug has been marked as a duplicate of bug 102981 ***
Errr, wait a minute, that's not a loop. My bad.
We're failing to thread 4->5->xxx because:
Checking profitability of path (backwards): bb:5 (10 insns) bb:4
Control statement insns: 2
Overall: 8 insns
FAIL: Did not thread around loop and would copy too many statements.
which is a limitation of the backward threader copier:
/* The generic copier used by the backthreader does not re-use an
existing threading path to reduce code duplication. So for that
case, drastically reduce the number of statements we are allowed
to copy. */
if (!(threaded_through_latch && threaded_multiway_branch)
&& (n_insns * param_fsm_scale_path_stmts
>= param_max_jump_thread_duplication_stmts))
{
if (dump_file && (dump_flags & TDF_DETAILS))
fprintf (dump_file,
" FAIL: Did not thread around loop and would copy too "
"many statements.\n");
return false;
}
Confirmed.
[Bug fortran/103394] New: Bad object code for structure constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103394 Bug ID: 103394 Summary: Bad object code for structure constructor Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: neil.n.carlson at gmail dot com Target Milestone: --- Bad object code is being generated for the structure constructor expression in the example below. This occurs for the current 12.0 trunk and any of the earlier 9.x, 10.x and 11.x versions I've tried. It seems that things go wrong with the expression foo_vector_func(this) when both the foo_vector_func type is an extension and the variable this is also polymorphic. module foo_type type :: foo contains procedure :: alloc_foo_vector_func end type type, abstract :: vector_func end type type, extends(vector_func) :: foo_vector_func type(foo), pointer :: ptr end type contains subroutine alloc_foo_vector_func(this, vf) class(foo), intent(in), target :: this class(vector_func), allocatable, intent(out) :: vf allocate(vf, source=foo_vector_func(this)) ! DOESN'T WORK CORRECTLY !vf = foo_vector_func(this) ! DOESN'T WORK EITHER end subroutine end module program main use foo_type type(foo), target :: x class(vector_func), allocatable :: vf call x%alloc_foo_vector_func(vf) select type (vf) type is (foo_vector_func) if (.not.associated(vf%ptr, x)) stop 1 ! SHOULD NOT EXIT HERE end select end program
[Bug bootstrap/103306] [12 Regression] parallel build hangs since r12-5234-g04c5a9 when /usr/include includes broken symbolic links
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103306 --- Comment #19 from Xi Ruoyao --- Fixed on trunk.
[Bug tree-optimization/103393] New: [ 12 Regression ] Auto vectorizer generating 256bit register usage with -mprefer-avx128 -mprefer-vector-width=128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103393
Bug ID: 103393
Summary: [ 12 Regression ] Auto vectorizer generating 256bit
register usage with -mprefer-avx128
-mprefer-vector-width=128
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jschoen4 at gmail dot com
Target Milestone: ---
gcc -v
Using built-in specs.
COLLECT_GCC=/gcc_build/bin/gcc
COLLECT_LTO_WRAPPER=/gcc_build/bin/../libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --prefix=/gcc_build --include=/gcc_build/include
--disable-multilib --enable-rpath --enable-__cxa_atexit --enable-nls
--disable-checking --disable-libunwind-exceptions --enable-bootstrap
--enable-shared --enable-static --enable-threads=posix --with-gcc --with-gnu-as
--with-gnu-ld --with-system-zlib
--enable-languages=c,c++,fortran,go,objc,obj-c++ --enable-lto
--enable-stage1-languages=c
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20211123 (experimental) (GCC)
Branch: trunk, w/ a latest commit of 721d8b9e26bf8205c1f2125c2626919a408cdbe4
===
=TEST CODE=
===
# cat test.cpp
struct TestData {
float arr[8];
};
void cpy( TestData& s1, TestData& s2 ) {
for(int i=0; i<8; ++i) {
s1.arr[i] = s2.arr[i];
}
}
===
=cmd =
===
gcc -S -masm=intel -O2 -mavx -mprefer-avx128 -mprefer-vector-width=128 -Wall
-Wextra test.cpp -o test.s
===
=BAD ASM =
= GCC 12 =
===
cat test.s
.file "test.cpp"
.intel_syntax noprefix
.text
.p2align 4
.globl _Z3cpyR8TestDataS0_
.type _Z3cpyR8TestDataS0_, @function
_Z3cpyR8TestDataS0_:
.LFB0:
.cfi_startproc
vmovdqu ymm0, YMMWORD PTR [rsi]
vmovdqu YMMWORD PTR [rdi], ymm0
vzeroupper
ret
.cfi_endproc
.LFE0:
.size _Z3cpyR8TestDataS0_, .-_Z3cpyR8TestDataS0_
.ident "GCC: (GNU) 12.0.0 20211123 (experimental)"
.section.note.GNU-stack,"",@progbits
===
= GCC 11 = (GCC 10 generates identical asm)
===
cat test.s
.file "test.cpp"
.intel_syntax noprefix
.text
.p2align 4
.globl _Z3cpyR8TestDataS0_
.type _Z3cpyR8TestDataS0_, @function
_Z3cpyR8TestDataS0_:
.LFB0:
.cfi_startproc
mov edx, 32
jmp memmove
.cfi_endproc
.LFE0:
.size _Z3cpyR8TestDataS0_, .-_Z3cpyR8TestDataS0_
.ident "GCC: (GNU) 11.2.0"
.section.note.GNU-stack,"",@progbits
=
= GCC 9 =
=
cat test.s
.file "test.cpp"
.intel_syntax noprefix
.text
.p2align 4
.globl _Z3cpyR8TestDataS0_
.type _Z3cpyR8TestDataS0_, @function
_Z3cpyR8TestDataS0_:
.LFB0:
.cfi_startproc
xor eax, eax
.p2align 4,,10
.p2align 3
.L2:
vmovss xmm0, DWORD PTR [rsi+rax]
vmovss DWORD PTR [rdi+rax], xmm0
add rax, 4
cmp rax, 32
jne .L2
ret
.cfi_endproc
.LFE0:
.size _Z3cpyR8TestDataS0_, .-_Z3cpyR8TestDataS0_
.ident "GCC: (GNU) 9.3.0"
.section.note.GNU-stack,"",@progbits
The auto vectorizer is generating YMM / 256-bit vector instructions with
-mprefer-avx128 and -mprefer-vector-width=128 flags specified. This is an
issue for low latency software. Using registers 256-bit and wider causes jitter
CPU problems on sky lake / cascade lake / ice lake chips. This is true even in
cases where the instructions used are considered avx256-light instructions due
to a "mix of instructions" being used to determine the power levels (this is
also mentioned in intel's optimization manual).
Auto vectorizer needs to respect the prefer width flags. Enabling/using newer
instruction sets i.e. AVX/AVX2/AVX512 does not require usage of the wider
register types.
[Bug bootstrap/103306] [12 Regression] parallel build hangs since r12-5234-g04c5a9 when /usr/include includes broken symbolic links
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103306 --- Comment #18 from CVS Commits --- The master branch has been updated by Xi Ruoyao : https://gcc.gnu.org/g:3363022ed810a2797c47867890547c8f73163257 commit r12-5477-g3363022ed810a2797c47867890547c8f73163257 Author: Xi Ruoyao Date: Thu Nov 18 18:46:12 2021 +0800 fixincludes: don't abort() on access failure [PR103306] Some distro may ship dangling symlinks in include directories, triggers the access failure. Skip it and continue to next header instead of being to panic. Restore to old behavior before r12-5234 but without resurrecting the problematic getcwd() call, by using the environment variable "INPUT" exported by fixinc.sh. Tested on x86_64-linux-gnu, with a dangling symlink intentionally injected into /usr/include. fixincludes/ PR bootstrap/103306 * fixincl.c (process): Don't call abort().
[Bug tree-optimization/102981] [12 Regression] Dead Code Elimination Regression at -O3 (trunk vs 11.2.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102981 --- Comment #7 from Aldy Hernandez --- *** Bug 103388 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/103388] [12 Regression] missed optimization for dead code elimination at -O3 (vs. -O2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103388 Aldy Hernandez changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Aldy Hernandez --- By *.threadfull1 this is the path at 4->5->7. It looks like: PREHEADER | v HEADER+ | | V UNREACHABLE | |/ V / return 0 <-+ This is more or less PR102981. Is there any way we can stop reporting the same thing over and over? *** This bug has been marked as a duplicate of bug 102981 ***
[Bug fortran/103392] [9/10/11/12 Regression] ICE in simplify_bound, at fortran/simplify.c:4273
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103392 G. Steinmetz changed: What|Removed |Added Keywords||ice-on-invalid-code --- Comment #1 from G. Steinmetz --- More variants : $ cat z2.f90 program p integer, allocatable :: a(1:) integer :: b(1) = lbound(a) integer :: c(1) = ubound(a) end $ cat z3.f90 program p integer, allocatable :: a(1) integer :: b(1) = lbound(a) integer :: c(1) = ubound(a) end $ cat z4.f90 program p integer, allocatable :: a(1) integer :: b = lbound(a) integer :: c = ubound(a) end $ cat z5.f90 program p integer, allocatable :: a(1:) integer :: b, c b = lbound(a) c = ubound(a) end
[Bug fortran/103392] New: [9/10/11/12 Regression] ICE in simplify_bound, at fortran/simplify.c:4273
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103392 Bug ID: 103392 Summary: [9/10/11/12 Regression] ICE in simplify_bound, at fortran/simplify.c:4273 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Started with r6 : $ cat z1.f90 program p integer, allocatable :: a(1:1) integer :: b(1) = lbound(a) integer :: c(1) = ubound(a) end $ gfortran-5 -c z1.f90 z1.f90:2:33: integer, allocatable :: a(1:1) 1 Error: Allocatable array 'a' at (1) must have a deferred shape or assumed rank $ gfortran-12-20211121 -c z1.f90 f951: internal compiler error: in simplify_bound, at fortran/simplify.c:4273 0x824e69 simplify_bound ../../gcc/fortran/simplify.c:4269 0x7ac9da do_simplify ../../gcc/fortran/intrinsic.c:4655 0x7b7a7a gfc_intrinsic_func_interface(gfc_expr*, int) ../../gcc/fortran/intrinsic.c:5034 0x80b71c resolve_unknown_f ../../gcc/fortran/resolve.c:2972 0x80b71c resolve_function ../../gcc/fortran/resolve.c:3329 0x80b71c gfc_resolve_expr(gfc_expr*) ../../gcc/fortran/resolve.c:7166 0x79cac4 gfc_reduce_init_expr(gfc_expr*) ../../gcc/fortran/expr.c:3130 0x79f990 gfc_match_init_expr(gfc_expr**) ../../gcc/fortran/expr.c:3178 0x789f44 variable_decl ../../gcc/fortran/decl.c:3004 0x789f44 gfc_match_data_decl() ../../gcc/fortran/decl.c:6297 0x7f3df3 match_word ../../gcc/fortran/parse.c:67 0x7f3df3 decode_statement ../../gcc/fortran/parse.c:378 0x7f583a next_free ../../gcc/fortran/parse.c:1397 0x7f583a next_statement ../../gcc/fortran/parse.c:1629 0x7f6f5b parse_spec ../../gcc/fortran/parse.c:4168 0x7fa2bc parse_progunit ../../gcc/fortran/parse.c:6179 0x7fb5a1 gfc_parse_file() ../../gcc/fortran/parse.c:6724 0x848a6f gfc_be_parse_file ../../gcc/fortran/f95-lang.c:216
[Bug fortran/103391] [9/10/11/12 Regression] ICE: gimplification failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103391 G. Steinmetz changed: What|Removed |Added Keywords||ice-on-valid-code --- Comment #1 from G. Steinmetz --- Compiles : $ cat z2.f90 program p type t end type type t2 type(t), pointer :: a(:) end type contains function f(x) class(t), intent(in), target :: x(:) type(t2) :: f f%a => x end end
[Bug fortran/103391] New: [9/10/11/12 Regression] ICE: gimplification failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103391 Bug ID: 103391 Summary: [9/10/11/12 Regression] ICE: gimplification failed Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Started with r7 : $ cat z1.f90 program p type t end type type t2 type(t), pointer :: a(:) end type contains function f(x) class(t), intent(in), target :: x(:) type(t2) :: f f%a = x end end $ gfortran-6 -c z1.f90 $ $ gfortran-12-20211121 -c z1.f90 gimplification failed: D.4265 + _15 unit-size align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7f68226a7f18 pointer_to_this reference_to_this chain > unsigned DI size unit-size align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7f68226a7690> arg:0 unsigned DI size unit-size align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7f68226ad1f8> used unsigned ignored DI z1.f90:11:13 size unit-size align:64 warn_if_not_align:0 context chain used ignored DI z1.f90:11:13 size unit-size align:64 warn_if_not_align:0 context chain >> arg:1 unit-size align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7f68224cc000 precision:64 min max > def_stmt _15 = (sizetype) _14; version:15>> z1.f90:11:13: 11 | f%a = x | ^ internal compiler error: gimplification failed 0xbdad08 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) ../../gcc/gimplify.c:15679 0xbe91bb gimplify_modify_expr ../../gcc/gimplify.c:5973 0xbd9aa7 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) ../../gcc/gimplify.c:14666 0xbddd78 gimplify_stmt(tree_node**, gimple**) ../../gcc/gimplify.c:7024 0xbd93db gimplify_statement_list ../../gcc/gimplify.c:2012 0xbd93db gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) ../../gcc/gimplify.c:15111 0xbddd78 gimplify_stmt(tree_node**, gimple**) ../../gcc/gimplify.c:7024 0xbde713 gimplify_bind_expr ../../gcc/gimplify.c:1426 0xbda08a gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) ../../gcc/gimplify.c:14867 0xbddd78 gimplify_stmt(tree_node**, gimple**) ../../gcc/gimplify.c:7024 0xbd93db gimplify_statement_list ../../gcc/gimplify.c:2012 0xbd93db gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) ../../gcc/gimplify.c:15111 0xbddd78 gimplify_stmt(tree_node**, gimple**) ../../gcc/gimplify.c:7024 0xbd974c gimplify_and_add(tree_node*, gimple**) ../../gcc/gimplify.c:494 0xbd974c gimplify_loop_expr ../../gcc/gimplify.c:1986 0xbd974c gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) ../../gcc/gimplify.c:14871 0xbddd78 gimplify_stmt(tree_node**, gimple**) ../../gcc/gimplify.c:7024 0xbd93db gimplify_statement_list ../../gcc/gimplify.c:2012 0xbd93db gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) ../../gcc/gimplify.c:15111 0xbddd78 gimplify_stmt(tree_node**, gimple**) ../../gcc/gimplify.c:7024
[Bug fortran/103390] New: [12 Regression] ICE: gimplification failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103390 Bug ID: 103390 Summary: [12 Regression] ICE: gimplification failed Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Changed between 20211017 and 20211024 : (ok without bind(c)) $ cat z1.f90 program p integer, pointer :: z(:) integer, target :: x(3) = [1, 2, 3] z => x call s(shape(z)) contains subroutine s(x) bind(c) integer, contiguous :: x(:) end end $ gfortran-12-20211017 -c z1.f90 $ $ gfortran-12-20211121 -c z1.f90 gimplification failed: (integer(kind=4)) _33 unit-size align:32 warn_if_not_align:0 symtab:0 alias-set 3 canonical-type 0x7f169465a5e8 precision:32 min max pointer_to_this > arg:0 unit-size align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7f169483ce70 precision:32 min max > def_stmt _33 = _32 + 1; version:33> z1.f90:5:19 start: z1.f90:5:19 finish: z1.f90:5:19> z1.f90:5:19: 5 |call s(shape(z)) | ^ internal compiler error: gimplification failed 0xbdad08 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) ../../gcc/gimplify.c:15679 0xbe91bb gimplify_modify_expr ../../gcc/gimplify.c:5973 0xbd9aa7 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) ../../gcc/gimplify.c:14666 0xbddd78 gimplify_stmt(tree_node**, gimple**) ../../gcc/gimplify.c:7024 0xbd93db gimplify_statement_list ../../gcc/gimplify.c:2012 0xbd93db gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) ../../gcc/gimplify.c:15111 0xbddd78 gimplify_stmt(tree_node**, gimple**) ../../gcc/gimplify.c:7024 0xbd974c gimplify_and_add(tree_node*, gimple**) ../../gcc/gimplify.c:494 0xbd974c gimplify_loop_expr ../../gcc/gimplify.c:1986 0xbd974c gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) ../../gcc/gimplify.c:14871 0xbddd78 gimplify_stmt(tree_node**, gimple**) ../../gcc/gimplify.c:7024 0xbd93db gimplify_statement_list ../../gcc/gimplify.c:2012 0xbd93db gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) ../../gcc/gimplify.c:15111 0xbddd78 gimplify_stmt(tree_node**, gimple**) ../../gcc/gimplify.c:7024 0xbde713 gimplify_bind_expr ../../gcc/gimplify.c:1426 0xbda08a gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) ../../gcc/gimplify.c:14867 0xbddd78 gimplify_stmt(tree_node**, gimple**) ../../gcc/gimplify.c:7024 0xbe4780 gimplify_cond_expr ../../gcc/gimplify.c:4393 0xbda65f gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) ../../gcc/gimplify.c:14623 0xbddd78 gimplify_stmt(tree_node**, gimple**) ../../gcc/gimplify.c:7024
[Bug fortran/103389] [9/10/11/12 Regression] ICE in estimate_move_cost, at tree-inline.c:4191
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103389 G. Steinmetz changed: What|Removed |Added Keywords||ice-on-valid-code --- Comment #1 from G. Steinmetz --- Compiles : $ cat z2.f90 program p type t real, allocatable :: a(:) end type type(t) :: y call s(y) contains subroutine s(x) class(*) :: x end end
[Bug fortran/103389] New: [9/10/11/12 Regression] ICE in estimate_move_cost, at tree-inline.c:4191
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103389 Bug ID: 103389 Summary: [9/10/11/12 Regression] ICE in estimate_move_cost, at tree-inline.c:4191 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Starts with r7 (changed in r9 between 20190127 and 20190203) : $ cat z1.f90 program p type t real, allocatable :: a(:) end type type(t) :: y call s((y)) contains subroutine s(x) class(*) :: x end end $ gfortran-9-20190127 -c z1.f90 $ $ gfortran-12-20211121 -c z1.f90 during GIMPLE pass: local-fnsummary z1.f90:6:14: 6 |call s((y)) | ^ internal compiler error: in estimate_move_cost, at tree-inline.c:4191 0xdccbff estimate_move_cost(tree_node*, bool) ../../gcc/tree-inline.c:4191 0xdcd054 estimate_num_insns(gimple*, eni_weights*) ../../gcc/tree-inline.c:4421 0xb2c7fc analyze_function_body ../../gcc/ipa-fnsummary.c:2746 0xb2f6cf compute_fn_summary(cgraph_node*, bool) ../../gcc/ipa-fnsummary.c:3191 0xb2fe4c compute_fn_summary_for_current ../../gcc/ipa-fnsummary.c:3221 0xb2fe4c execute ../../gcc/ipa-fnsummary.c:4829
[Bug libstdc++/103387] powerpc64le: segmentation fault on std::cout with ieee128 long double variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103387 Michael Meissner changed: What|Removed |Added Severity|normal |major Last reconfirmed||2021-11-23 Priority|P3 |P1 CC||meissner at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Michael Meissner --- I tried it on a current trunk compiler (from November 23, 2021) using glibc 2.34 (IBM AT 14.0), and it does fail. It works fine if I build a toolchain where the default long double is IEEE 128-bit.
[Bug middle-end/103386] stage1 with PGO produces bad offsets in rtl-reload on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103386 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 Last reconfirmed||2021-11-23 Component|rtl-optimization|middle-end Keywords||wrong-code --- Comment #1 from Andrew Pinski --- What GCC are you starting with? Because you are building stage 1 compiler with "-O3 -ftree-vectorize -fomit-frame-pointer -mcpu=neoverse-n1 -mtune=neoverse-n1 -fno-plt -fipa-pta -funsafe-math-optimizations -funsafe-loop-optimizations -fdevirtualize-at-ltrans -floop-nest-optimize -fgraphite-identity -floop-interchange" I think both "-fipa-pta" and "-fgraphite-identity" have known issues which could be causing issues here. Plus GCC is not normally compiled with "-funsafe-math-optimizations" or "-funsafe-loop-optimizations".
[Bug tree-optimization/103388] New: [12 Regression] missed optimization for dead code elimination at -O3 (vs. -O2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103388
Bug ID: 103388
Summary: [12 Regression] missed optimization for dead code
elimination at -O3 (vs. -O2)
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: theodort at inf dot ethz.ch
Target Milestone: ---
cat case.c
void foo(void);
void bar(void);
static int b, d, e, *c, *f = , *h =
int main() {
int **i =
if (e) {
e = *f;
bar();
if (!(((i && d) + *h >= 1 ^ d & b) <= 4 | d))
foo();
}
}
trunk cannot eliminate the call to foo but 11.2.0 can:
gcc-11.2.0 -O3 -S -o /dev/stdout case.c
main:
.LFB0:
.cfi_startproc
movle(%rip), %ecx
testl %ecx, %ecx
jne .L8
xorl%eax, %eax
ret
.L8:
pushq %rax
.cfi_def_cfa_offset 16
movld(%rip), %eax
movl%eax, e(%rip)
callbar
xorl%eax, %eax
popq%rdx
.cfi_def_cfa_offset 8
ret
.cfi_endproc
.LFE0:
gcc-trunk -O3 -S -o /dev/stdout case.c
main:
.LFB0:
.cfi_startproc
movle(%rip), %esi
testl %esi, %esi
jne .L10
xorl%eax, %eax
ret
.L10:
pushq %rcx
.cfi_def_cfa_offset 16
movld(%rip), %eax
movl%eax, e(%rip)
callbar
movld(%rip), %edx
movlb(%rip), %eax
cmpl$1, %edx
movl%eax, %ecx
sbbl$-1, %ecx
testl %ecx, %ecx
setg%cl
andl%edx, %eax
movzbl %cl, %ecx
xorl%ecx, %eax
cmpl$4, %eax
setle %al
movzbl %al, %eax
orl %edx, %eax
je .L11
.L3:
xorl%eax, %eax
popq%rdx
.cfi_remember_state
.cfi_def_cfa_offset 8
ret
.L11:
.cfi_restore_state
callfoo
jmp .L3
.cfi_endproc
.LFE0:
gcc-trunk -v
Using built-in specs.
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.0 20211123 (experimental) (GCC)
Started with
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=4b3a325f07acebf47e82de227ce1d5ba62f5bcae
[Bug c++/103339] [modules] ICE in exporting module on use of outside specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103339 --- Comment #3 from Johel Ernesto Guerrero Peña --- Turns out that the error from Bug 99861 just happens occasionally when compiling.
[Bug libstdc++/103086] [11 Regression] std::unique_ptr printer gets confused by [[no_unique_address]] in tuple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103086
--- Comment #4 from Jonathan Wakely ---
The branches all get this testcase wrong:
#include
#include "../util/testsuite_allocator.h"
struct Deleter
{
int deleter_member = -1;
using pointer = __gnu_test::NullablePointer;
void operator()(pointer) const noexcept { }
};
int main()
{
std::unique_ptr p;
return 0;
}
I'll add that test, as well as backporting the fix from trunk.
[Bug libstdc++/103387] New: powerpc64le: segmentation fault on std::cout with ieee128 long double variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103387
Bug ID: 103387
Summary: powerpc64le: segmentation fault on std::cout with
ieee128 long double variable
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: maxiwell at gmail dot com
Target Milestone: ---
How to reproduce:
- Building GCC from the master branch:
~/devel> git clone git://gcc.gnu.org/git/gcc.git && cd gcc/
~/devel/gcc> git rev-parse HEAD
a944b5dec3adb28ed199234d2116145ca9010d6a
~/devel/gcc> mkdir build && cd build
~/devel/gcc/build> ../configure --prefix=/home/maxiwell/usr/
--build=powerpc64le-linux-gnu --host=powerpc64le-linux-gnu
--target=powerpc64le-linux-gnu --enable-languages=c++ --disable-bootstrap
CC=gcc-11 CXX=g++-11
~/devel/gcc/build> make && make install
~/devel/gcc/build> /home/maxiwell/usr/bin/g++ -v
Using built-in specs.
COLLECT_GCC=/home/maxiwell/usr/bin/g++
COLLECT_LTO_WRAPPER=/home/maxiwell/usr/libexec/gcc/powerpc64le-linux-gnu/12.0.0/lto-wrapper
Target: powerpc64le-linux-gnu
Configured with: ../configure --prefix=/home/maxiwell/usr/
--build=powerpc64le-linux-gnu --host=powerpc64le-linux-gnu
--target=powerpc64le-linux-gnu --enable-languages=c++ --disable-bootstrap
CC=gcc-11 CXX=g++-11
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20211123 (experimental) (GCC)
- Running a simple C++ program to print an IEEE long double var using std::cout
~> cat test.cpp
#include
int main()
{
long double n = 0.1L;
std::cout << n;
return 0;
}
~> /home/maxiwell/usr/bin/g++ test.cpp -g -o test -mabi=ieeelongdouble
~> ./test
Segmentation fault (core dumped)
- It works with printf:
~> cat test-printf.cpp
#include
int main()
{
long double n = 0.1L;
printf("%Lg\n", n);
return 0;
}
~> /home/maxiwell/usr/bin/g++ test-printf.cpp -g -o test-printf
-mabi=ieeelongdouble
~> ./test-printf
0.1
- Running the std::cout program with GDB
~> gdb -q -s --args test
Reading symbols from test...
(gdb) r
Starting program: /home/maxiwell/test
Program received signal SIGSEGV, Segmentation fault.
0x in ?? ()
(gdb) bt
#0 0x in ?? ()
#1 0x77d3667c in std::__gnu_cxx_ieee128::num_put > >::put
(__v=6.95334903218850043777638611569573e-310, __fill=32 ' ',
__io=..., __s=..., this=0x77f55208 <(anonymous namespace)::num_put_c>)
at
/usr/src/debug/gcc11-11.1.1+git340-1.1.ppc64le/obj-powerpc64le-suse-linux/powerpc64le-suse-linux/libstdc++-v3/include/bits/locale_facets.h:2461
#2 std::ostream::_M_insert<__ieee128> (this=0x77f536e8 ,
__v=6.95334903218850043777638611569573e-310)
at
/usr/src/debug/gcc11-11.1.1+git340-1.1.ppc64le/obj-powerpc64le-suse-linux/powerpc64le-suse-linux/libstdc++-v3/include/bits/ostream.tcc:73
#3 0x77d368c8 in std::ostream::operator<< (this=,
__f=)
at
/usr/src/debug/gcc11-11.1.1+git340-1.1.ppc64le/obj-powerpc64le-suse-linux/powerpc64le-suse-linux/libstdc++-v3/include/ostream:233
#4 0x198c in main () at test.cpp:6
The __v parameter from #1 and #2 has the same value that was reported here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100912
- Versions:
~> cat /etc/os-release
NAME="openSUSE Tumbleweed"
# VERSION="20210626"
ID="opensuse-tumbleweed"
ID_LIKE="opensuse suse"
VERSION_ID="20210626"
PRETTY_NAME="openSUSE Tumbleweed"
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:opensuse:tumbleweed:20210626"
BUG_REPORT_URL="https://bugs.opensuse.org;
HOME_URL="https://www.opensuse.org/;
DOCUMENTATION_URL="https://en.opensuse.org/Portal:Tumbleweed;
LOGO="distributor-logo"
~> g++-11 -v
Using built-in specs.
COLLECT_GCC=g++-11
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/powerpc64le-suse-linux/11/lto-wrapper
Target: powerpc64le-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,objc,fortran,obj-c++,ada,go,jit --enable-host-shared
--enable-checking=release --disable-werror
--with-gxx-include-dir=/usr/include/c++/11 --enable-ssp --disable-libssp
--disable-libvtv --enable-cet=auto --disable-libcc1 --enable-plugin
--with-bugurl=https://bugs.opensuse.org/ --with-pkgversion='SUSE Linux'
--with-slibdir=/lib64 --with-system-zlib --enable-libstdcxx-allocator=new
--disable-libstdcxx-pch --enable-version-specific-runtime-libs
--with-gcc-major-version-only --enable-linker-build-id --enable-linux-futex
--enable-gnu-indirect-function --program-suffix=-11 --without-system-libunwind
--with-cpu=power8 --with-tune=power9 --enable-secureplt --with-long-double-128
--enable-targets=pow
[Bug c++/103339] [modules] ICE in exporting module on use of outside specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103339 --- Comment #2 from Johel Ernesto Guerrero Peña --- Or not really. Removing a comment breaks it again, so I guess the compiler is already in a bugged state that seems to work fine.
[Bug c++/96645] [9/10/11/12 Regression] std::variant default constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96645 --- Comment #13 from Jonathan Wakely --- Tim Song says "This is another variant of CWG2335, which is currently blocked on implementation experience and wording."
[Bug libstdc++/97120] circular concept loops in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97120 Jonathan Wakely changed: What|Removed |Added Resolution|--- |MOVED Status|UNCONFIRMED |RESOLVED See Also||https://bugs.llvm.org/show_ ||bug.cgi?id=47509 --- Comment #3 from Jonathan Wakely --- This is a clang bug.
[Bug ipa/103227] [12 Regression] 58% exchange2 regression with -Ofast -march=native on zen3 since r12-5223-gecdf414bd89e6ba251f6b3f494407139b4dbae0e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103227 Martin Jambor changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jamborm at gcc dot gnu.org --- Comment #11 from Martin Jambor --- Created attachment 51863 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51863=edit Untested fix I am testing the attached patch. I would like to file a new bug for the testcase in comment #6 as it is a different issue.
[Bug c++/103339] [modules] ICE in exporting module on use of outside specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103339
--- Comment #1 from Johel Ernesto Guerrero Peña ---
In non-reduced code, I got the error from Bug 99861 which I solved with the
workaround above:
```
hash table checking failed: equal operator returns true for a pair of values
with a different hash value
In module waarudo.numbers, imported at
/home/johel/Documents/C++/Repos/waarudo/tests/test.waarudo.numbers.cpp:4:
/home/johel/Documents/C++/Repos/waarudo/sources/waarudo.numbers.cpp: In
substitution of ‘template using number_difference_t = typename
waarudo::number_difference@waarudo.numbers::type [with T = short unsigned
int]’:
/home/johel/Documents/C++/Repos/waarudo/sources/waarudo.numbers.cpp:57:24:
required by substitution of ‘template requires scalar_quantity
using x_component =
waarudo::component@waarudo.geometries [with Q
= waarudo::pixels@waarudo.quantities]’
/home/johel/Documents/C++/Repos/waarudo/tests/test.waarudo.numbers.cpp:111:9:
required from ‘{anonymous}::test():: [with I = short unsigned int]’
/usr/include/boost/mp11/algorithm.hpp:1039:29: required from ‘constexpr F
boost::mp11::detail::mp_for_each_impl(boost::mp11::mp_list, F&&) [with T
= {unsigned char, short unsigned int}; F =
{anonymous}::test()::]’
/usr/include/boost/mp11/algorithm.hpp:1072:36: required from ‘constexpr F
boost::mp11::mp_for_each(F&&) [with L = boost::mp11::mp_list; F = {anonymous}::test()::]’
/home/johel/Documents/C++/Repos/waarudo/tests/test.waarudo.numbers.cpp:110:58:
required from here
/home/johel/Documents/C++/Repos/waarudo/sources/waarudo.numbers.cpp:25:32:
internal compiler error: in hashtab_chk_error, at hash-table.c:137
25 | export template using number_difference_t = typename
number_difference::type;
|^~~
0x20f297d internal_error(char const*, ...)
???:0
0x97de46 fancy_abort(char const*, int, char const*)
???:0
0x97dc52 hashtab_chk_error()
???:0
0x9eb38e hash_table::verify(tree_node* const&,
unsigned int)
???:0
0x9ea2c8 constraints_satisfied_p(tree_node*, tree_node*)
???:0
0xb8a0ec most_specialized_partial_spec(tree_node*, int)
???:0
0xba6a27 instantiate_class_template(tree_node*)
???:0
0xbf7c74 complete_type_or_maybe_complain(tree_node*, tree_node*, int)
???:0
0xb8d16a tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0xb8be48 tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0x9ea286 tsubst_requires_expr(tree_node*, tree_node*, int, tree_node*)
???:0
0x9ea2c8 constraints_satisfied_p(tree_node*, tree_node*)
???:0
0xb8bfba tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0xb8e487 tsubst_template_args(tree_node*, tree_node*, int, tree_node*)
???:0
0xb8e8df tsubst_argument_pack(tree_node*, tree_node*, int, tree_node*)
???:0
0xb8e664 tsubst_template_args(tree_node*, tree_node*, int, tree_node*)
???:0
0xb8e487 tsubst_template_args(tree_node*, tree_node*, int, tree_node*)
???:0
0xb8e8df tsubst_argument_pack(tree_node*, tree_node*, int, tree_node*)
???:0
0xb8e664 tsubst_template_args(tree_node*, tree_node*, int, tree_node*)
???:0
0xb8e487 tsubst_template_args(tree_node*, tree_node*, int, tree_node*)
???:0
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
