[Bug tree-optimization/102513] [10/11/12 Regression] Many false positive warnings with recursive function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102513 --- Comment #2 from Andrew Pinski --- A simple workaround is to add at the begining of the function: if (level == 0) return 0; What I found is since we don't run loop copy header until after IPA-CP, we get some interesting IR where we don't jump thread the level == 0 case correctly.
[Bug tree-optimization/102902] [12 Regression] -O3 produces code that uses an uninitialized variable but originally was not used by r12-3876
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102902 --- Comment #6 from Zhendong Su --- Hi Richard, I just noticed that this issue was mis-categorized as a duplicate of 102920, which was filed later. It's not very important, but it would probably be nice to correctly label the issues in the bug tracker. Thanks.
[Bug fortran/103389] [9/10/11/12 Regression] ICE in estimate_move_cost, at tree-inline.c:4191 since r9-5784-ga3df90b9672562d0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103389 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2021-11-24 CC||marxin at gcc dot gnu.org, ||pault at gcc dot gnu.org Summary|[9/10/11/12 Regression] ICE |[9/10/11/12 Regression] ICE |in estimate_move_cost, at |in estimate_move_cost, at |tree-inline.c:4191 |tree-inline.c:4191 since ||r9-5784-ga3df90b9672562d0 --- Comment #2 from Martin Liška --- Started with r9-5784-ga3df90b9672562d0.
[Bug fortran/103390] [12 Regression] ICE: gimplification failed since r12-4591-g1af78e731feb9327
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103390 Martin Liška changed: What|Removed |Added Summary|[12 Regression] ICE:|[12 Regression] ICE: |gimplification failed |gimplification failed since ||r12-4591-g1af78e731feb9327 Status|UNCONFIRMED |NEW Last reconfirmed||2021-11-24 CC||marxin at gcc dot gnu.org, ||sandra at codesourcery dot com Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Started with r12-4591-g1af78e731feb9327.
[Bug fortran/103391] [9/10/11/12 Regression] ICE: gimplification failed since r7-4021-g574284e9c49687d8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103391 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org, ||vehre at gcc dot gnu.org Last reconfirmed||2021-11-24 Summary|[9/10/11/12 Regression] |[9/10/11/12 Regression] |ICE: gimplification failed |ICE: gimplification failed ||since ||r7-4021-g574284e9c49687d8 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #2 from Martin Liška --- Started with r7-4021-g574284e9c49687d8.
[Bug fortran/103392] [9/10/11 Regression] ICE in simplify_bound, at fortran/simplify.c:4273
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103392 Martin Liška changed: What|Removed |Added Summary|[9/10/11/12 Regression] ICE |[9/10/11 Regression] ICE in |in simplify_bound, at |simplify_bound, at |fortran/simplify.c:4273 |fortran/simplify.c:4273 CC||marxin at gcc dot gnu.org --- Comment #5 from Martin Liška --- Fixed on master with r12-5480-g16e95050f71e9fa4 and it started with r6-597-g22fa926f19ae0ebb.
[Bug fortran/103392] [9/10/11 Regression] ICE in simplify_bound, at fortran/simplify.c:4273
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103392 --- Comment #6 from Martin Liška --- @Anlauf: Heh, you fixed faster than I made bisection :P
[Bug tree-optimization/102902] [12 Regression] -O3 produces code that uses an uninitialized variable but originally was not used by r12-3876
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102902 Andrew Pinski changed: What|Removed |Added Resolution|DUPLICATE |--- Status|RESOLVED|NEW --- Comment #7 from Andrew Pinski --- Reopening.
[Bug tree-optimization/102902] [12 Regression] -O3 produces code that uses an uninitialized variable but originally was not used by r12-3876
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102902 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=100810 --- Comment #8 from Andrew Pinski --- It is basically the same as PR 100810. we have a conditional use of an unitialized variable and ivopts decides to make it unconditional ...
[Bug tree-optimization/103388] [12 Regression] missed optimization for dead code elimination at -O3 (trunk vs 11.2.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103388 Richard Biener changed: What|Removed |Added Target Milestone|--- |12.0 Keywords||missed-optimization
[Bug c++/103402] New: Compile-time less/more comparison of a pointer vs nullptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103402
Bug ID: 103402
Summary: Compile-time less/more comparison of a pointer vs
nullptr
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: fchelnokov at gmail dot com
Target Milestone: ---
The following code is invalid and must be rejected:
```
int main() {
static constexpr int x = 1;
constexpr const int * p = nullptr;
static_assert( p < &x );
}
```
because less/more comparison with nullptr has unspecified value and cannot
appear in a constant expression.
Clang correctly rejects the code, demo: https://gcc.godbolt.org/z/E4ME4zh3M
[Bug fortran/103389] [9/10/11/12 Regression] ICE in estimate_move_cost, at tree-inline.c:4191 since r9-5784-ga3df90b9672562d0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103389 Richard Biener changed: What|Removed |Added Target Milestone|--- |9.5 Priority|P3 |P4 --- Comment #3 from Richard Biener --- # VUSE <.MEM_29> _31 = *_1; (gdb) p debug_tree ($2)
[Bug fortran/103390] [12 Regression] ICE: gimplification failed since r12-4591-g1af78e731feb9327
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103390 Richard Biener changed: What|Removed |Added Target Milestone|--- |12.0 Priority|P3 |P4
[Bug fortran/103391] [9/10/11/12 Regression] ICE: gimplification failed since r7-4021-g574284e9c49687d8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103391 Richard Biener changed: What|Removed |Added Target Milestone|--- |9.5 Priority|P3 |P4
[Bug fortran/103392] [9/10/11 Regression] ICE in simplify_bound, at fortran/simplify.c:4273
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103392 Richard Biener changed: What|Removed |Added Target Milestone|--- |9.5
[Bug tree-optimization/103345] missed optimization: add/xor individual bytes to form a word
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103345 --- Comment #4 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:04eccbbe3d9a4e9d2f8f43dba8ac4cb686029fb2 commit r12-5492-g04eccbbe3d9a4e9d2f8f43dba8ac4cb686029fb2 Author: Jakub Jelinek Date: Wed Nov 24 09:54:44 2021 +0100 bswap: Fix up symbolic merging for xor and plus [PR103376] On Mon, Nov 22, 2021 at 08:39:42AM -, Roger Sayle wrote: > This patch implements PR tree-optimization/103345 to merge adjacent > loads when combined with addition or bitwise xor. The current code > in gimple-ssa-store-merging.c's find_bswap_or_nop alreay handles ior, > so that all that's required is to treat PLUS_EXPR and BIT_XOR_EXPR in > the same way at BIT_IOR_EXPR. Unfortunately they aren't exactly the same. They work the same if always at least one operand (or corresponding byte in it) is known to be 0, 0 | 0 = 0 ^ 0 = 0 + 0 = 0. But for | also x | x = x for any other x, so perform_symbolic_merge has been accepting either that at least one of the bytes is 0 or that both are the same, but that is wrong for ^ and +. The following patch fixes that by passing through the code of binary operation and allowing non-zero masked1 == masked2 through only for BIT_IOR_EXPR. Thinking more about it, perhaps we could do more for BIT_XOR_EXPR. We could allow masked1 == masked2 case for it, but would need to do something different than the n->n = n1->n | n2->n; we do on all the bytes together. In particular, for masked1 == masked2 if masked1 != 0 (well, for 0 both variants are the same) and masked1 != 0xff we would need to clear corresponding n->n byte instead of setting it to the input as x ^ x = 0 (but if we don't know what x and y are, the result is also don't know). Now, for plus it is much harder, because not only for non-zero operands we don't know what the result is, but it can modify upper bytes as well. So perhaps only if current's byte masked1 && masked2 set the resulting byte to 0xff (unknown) iff the byte above it is 0 and 0, and set that resulting byte to 0xff too. Also, even for | we could instead of return NULL just set the resulting byte to 0xff if it is different, perhaps it will be masked off later on. 2021-11-24 Jakub Jelinek PR tree-optimization/103376 * gimple-ssa-store-merging.c (perform_symbolic_merge): Add CODE argument. If CODE is not BIT_IOR_EXPR, ensure that one of masked1 or masked2 is 0. (find_bswap_or_nop_1, find_bswap_or_nop, imm_store_chain_info::try_coalesce_bswap): Adjust perform_symbolic_merge callers. * gcc.c-torture/execute/pr103376.c: New test.
[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 #8 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:04eccbbe3d9a4e9d2f8f43dba8ac4cb686029fb2 commit r12-5492-g04eccbbe3d9a4e9d2f8f43dba8ac4cb686029fb2 Author: Jakub Jelinek Date: Wed Nov 24 09:54:44 2021 +0100 bswap: Fix up symbolic merging for xor and plus [PR103376] On Mon, Nov 22, 2021 at 08:39:42AM -, Roger Sayle wrote: > This patch implements PR tree-optimization/103345 to merge adjacent > loads when combined with addition or bitwise xor. The current code > in gimple-ssa-store-merging.c's find_bswap_or_nop alreay handles ior, > so that all that's required is to treat PLUS_EXPR and BIT_XOR_EXPR in > the same way at BIT_IOR_EXPR. Unfortunately they aren't exactly the same. They work the same if always at least one operand (or corresponding byte in it) is known to be 0, 0 | 0 = 0 ^ 0 = 0 + 0 = 0. But for | also x | x = x for any other x, so perform_symbolic_merge has been accepting either that at least one of the bytes is 0 or that both are the same, but that is wrong for ^ and +. The following patch fixes that by passing through the code of binary operation and allowing non-zero masked1 == masked2 through only for BIT_IOR_EXPR. Thinking more about it, perhaps we could do more for BIT_XOR_EXPR. We could allow masked1 == masked2 case for it, but would need to do something different than the n->n = n1->n | n2->n; we do on all the bytes together. In particular, for masked1 == masked2 if masked1 != 0 (well, for 0 both variants are the same) and masked1 != 0xff we would need to clear corresponding n->n byte instead of setting it to the input as x ^ x = 0 (but if we don't know what x and y are, the result is also don't know). Now, for plus it is much harder, because not only for non-zero operands we don't know what the result is, but it can modify upper bytes as well. So perhaps only if current's byte masked1 && masked2 set the resulting byte to 0xff (unknown) iff the byte above it is 0 and 0, and set that resulting byte to 0xff too. Also, even for | we could instead of return NULL just set the resulting byte to 0xff if it is different, perhaps it will be masked off later on. 2021-11-24 Jakub Jelinek PR tree-optimization/103376 * gimple-ssa-store-merging.c (perform_symbolic_merge): Add CODE argument. If CODE is not BIT_IOR_EXPR, ensure that one of masked1 or masked2 is 0. (find_bswap_or_nop_1, find_bswap_or_nop, imm_store_chain_info::try_coalesce_bswap): Adjust perform_symbolic_merge callers. * gcc.c-torture/execute/pr103376.c: New test.
[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 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #9 from Jakub Jelinek --- Fixed.
[Bug tree-optimization/103393] [12 Regression] Generating 256bit register usage with -mprefer-avx128 -mprefer-vector-width=128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103393 Richard Biener changed: What|Removed |Added Target Milestone|--- |12.0 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW CC||hjl.tools at gmail dot com Summary|[ 12 Regression ] Auto |[12 Regression] Generating |vectorizer generating |256bit register usage with |256bit register usage with |-mprefer-avx128 |-mprefer-avx128 |-mprefer-vector-width=128 |-mprefer-vector-width=128 | Target||x86_64-*-* i?86-*-* Last reconfirmed||2021-11-24 --- Comment #1 from Richard Biener --- It isn't the vectorizer but memmove inline expansion. I'm not sure it's really a bug, but there isn't a way to disable %ymm use besides disabling AVX entirely. HJ?
[Bug c++/103402] Compile-time less/more comparison of a pointer vs nullptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103402 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2021-11-24 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug middle-end/103365] [12 Regression] ICE in register_scoped_attribute, with attribute starting with underscore: -Wno-attributes=n::_a or #pragma GCC diagnostic ignored_attributes "n::_a"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103365 --- Comment #4 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:709716b9f49f2fcf46f319000562cf6e61bd2f71 commit r12-5493-g709716b9f49f2fcf46f319000562cf6e61bd2f71 Author: Jakub Jelinek Date: Wed Nov 24 10:08:35 2021 +0100 attribs: Fix ICEs on attributes starting with _ [PR103365] As the patch shows, we have quite a few asserts that we don't call lookup_attribute etc. with attr_name that starts with an underscore, to make sure nobody is trying to call it with non-canonicalized attribute name like "__cold__" instead of "cold". We canonicalize only attributes that start with 2 underscores and end with 2 underscores though. Before Marek's patch, that wasn't an issue, we had no attributes like "_foo" or "__bar_" etc., so lookup_scoped_attribute_spec would always return NULL for those and we wouldn't try to register them, look them up etc., just with -Wattributes would warn about them. But now, as the new testcases show, users can actually request such attributes to be ignored, and we ICE for those during register_scoped_attribute and when that is fixed, ICE later on when somebody uses those attributes because they will be looked up to find out that they should be ignored. So, the following patch instead of or in addition to, depending on how performance sensitive a particular spot is, checking that attribute doesn't start with underscore allows attribute names that start with underscore as long as it doesn't canonicalize (i.e. doesn't start and end with 2 underscores). In addition to that, I've noticed lookup_attribute_by_prefix was calling get_attribute_name twice unnecessarily, and 2 tests were running in c++98 mode with -std=c++98 -std=c++11 which IMHO isn't useful because -std=c++11 testing is done too when testing all language versions. 2021-11-24 Jakub Jelinek PR middle-end/103365 * attribs.h (lookup_attribute): Allow attr_name to start with underscore, as long as canonicalize_attr_name returns false. (lookup_attribute_by_prefix): Don't call get_attribute_name twice. * attribs.c (extract_attribute_substring): Reimplement using canonicalize_attr_name. (register_scoped_attribute): Change gcc_assert into gcc_checking_assert, verify !canonicalize_attr_name rather than that str.str doesn't start with '_'. * c-c++-common/Wno-attributes-1.c: Require effective target c || c++11 and drop dg-additional-options. * c-c++-common/Wno-attributes-2.c: Likewise. * c-c++-common/Wno-attributes-4.c: New test. * c-c++-common/Wno-attributes-5.c: New test.
[Bug middle-end/103365] [12 Regression] ICE in register_scoped_attribute, with attribute starting with underscore: -Wno-attributes=n::_a or #pragma GCC diagnostic ignored_attributes "n::_a"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103365 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Jakub Jelinek --- Fixed.
[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 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2021-11-24 Ever confirmed|0 |1 Keywords||ice-on-valid-code --- Comment #2 from Andrew Pinski --- Confirmed.
[Bug libstdc++/103340] [12 Regression] constexpr std::string is incompatible with --enable-libstdcxx-allocator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103340 --- Comment #3 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #2) > Making the others work isn't difficult. HA! Making them usable in constexpr wasn't difficult, but analysing the test results and realising that they're completely broken was much harder, see PR 103400. And --enable-libstdcxx-allocator=bitmap had been unable to bootstrap for years, see PR 103381.
[Bug middle-end/103384] [OpenMP] declare variant with device={kind(nohost)} does not use GPU, kind(gpu) works
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103384 --- Comment #2 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:5bca26742cf3357bf4e20ec97eee4c7f7de17ce0 commit r12-5494-g5bca26742cf3357bf4e20ec97eee4c7f7de17ce0 Author: Jakub Jelinek Date: Wed Nov 24 10:30:32 2021 +0100 openmp: Fix up handling of kind(host) and kind(nohost) in ACCEL_COMPILERs [PR103384] As the testcase shows, we weren't handling kind(host) and kind(nohost) properly in the ACCEL_COMPILERs, the code written in there is valid for the host compiler only, where if we are maybe offloaded, we defer resolution after IPA, otherwise return 0 for kind(nohost) and accept it for kind(host). Note, omp_maybe_offloaded is false after IPA. If ACCEL_COMPILER is defined, it is the other way around, but also we know we are after IPA. 2021-11-24 Jakub Jelinek PR middle-end/103384 gcc/ * omp-general.c (omp_context_selector_matches): For ACCEL_COMPILER, return 0 for kind(host) and continue for kind(nohost). libgomp/ * testsuite/libgomp.c/declare-variant-2.c: New test.
[Bug c++/103401] gcc accepts decltype(auto(0)) as the parameter of the function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103401 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2021-11-24
[Bug c++/103403] New: Decltype of rvalue reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103403
Bug ID: 103403
Summary: Decltype of rvalue reference
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: enricomaria.dean6elis at gmail dot com
CC: anders.granlund.0 at gmail dot com,
daniel.kruegler at googlemail dot com, jason at gcc dot
gnu.org,
mpolacek at gcc dot gnu.org, trippels at gcc dot gnu.org,
webrown.cpp at gmail dot com
Target Milestone: ---
Unlike the comment at the end of the original report claims, the bug seems to
be still present (or at least a different shade of it).
StackOverflow question:
https://stackoverflow.com/questions/70092776/validity-of-presenting-an-xvalue-as-an-lvalue
Repro: https://godbolt.org/z/h943G933a
+++ This bug was initially created as a clone of Bug #78209 +++
This came up on the isocpp mailing list yesterday:
markus@x4 /tmp % cat test.ii
int main() {
int &&i = 0;
decltype(auto) j = i;
return j;
}
markus@x4 /tmp % clang++ test.ii
test.ii:3:18: error: rvalue reference to type 'int' cannot bind to lvalue of
type 'int'
decltype(auto) j = i;
^ ~
1 error generated.
markus@x4 /tmp % icpc test.ii
test.ii(3): error: an rvalue reference cannot be bound to an lvalue
decltype(auto) j = i;
^
compilation aborted for test.ii (code 2)
markus@x4 /tmp % g++ -Wall -Wextra test.ii
markus@x4 /tmp %
[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 #3 from Jakub Jelinek --- Note, in qemu it isn't just those newlines but simply a long inline asm. It can very well be something that is empty or very short in the .text section, e.g. can .pushsection; .section whatever; put lots of stuff in there; .popsection. But as inline asm is a black box to gcc, we have only very rough estimation for the inline asm text length, which just counts how many newlines and typically ; characters there are and multiple that by some insn size.
[Bug c++/103401] [11/12 Regression] gcc accepts decltype(auto(0)) as the parameter of the function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103401 Jonathan Wakely changed: What|Removed |Added Summary|gcc accepts |[11/12 Regression] gcc |decltype(auto(0)) as the|accepts decltype(auto(0)) |parameter of the function |as the parameter of the ||function Target Milestone|--- |11.3 CC||mpolacek at gcc dot gnu.org Known to work||10.3.0 Known to fail||11.2.1, 12.0 --- Comment #1 from Jonathan Wakely --- Started to be accepted with r11-1913 "c++: Better diagnostic for decltype(auto) in C++11 [PR96103]"
[Bug c++/78209] Decltype of rvalue reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78209 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |11.0
[Bug rtl-optimization/103404] New: ICE: SIGSEGV in insert_with_costs (cse.c:1569) with custom flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103404 Bug ID: 103404 Summary: ICE: SIGSEGV in insert_with_costs (cse.c:1569) with custom flags Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Created attachment 51865 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51865&action=edit reduced testcase Compiler output: $ x86_64-pc-linux-gnu-gcc -Og -fcse-follow-jumps -fno-dce -fno-early-inlining -fgcse -fharden-conditional-branches -frerun-cse-after-loop -fno-tree-ccp -mavx5124fmaps testcase.c -wrapper valgrind,-q ==24674== Invalid read of size 4 ==24674==at 0x2242C56: insert_with_costs(rtx_def*, table_elt*, unsigned int, machine_mode, int, int) (cse.c:1569) ==24674==by 0x2244F70: insert (cse.c:1695) ==24674==by 0x2244F70: merge_equiv_classes(table_elt*, table_elt*) [clone .isra.0] (cse.c:1756) ==24674==by 0x224F7F9: record_jump_equiv (cse.c:3891) ==24674==by 0x224F7F9: cse_extended_basic_block (cse.c:6614) ==24674==by 0x224F7F9: cse_main(rtx_insn*, int) [clone .constprop.0] (cse.c:6706) ==24674==by 0x224FE40: rest_of_handle_cse2 (cse.c:7592) ==24674==by 0x224FE40: (anonymous namespace)::pass_cse2::execute(function*) (cse.c:7645) ==24674==by 0x126020C: execute_one_pass(opt_pass*) (passes.c:2567) ==24674==by 0x1260A7F: execute_pass_list_1(opt_pass*) (passes.c:2656) ==24674==by 0x1260A91: execute_pass_list_1(opt_pass*) (passes.c:2657) ==24674==by 0x1260AB8: execute_pass_list(function*, opt_pass*) (passes.c:2667) ==24674==by 0xE947D5: expand (cgraphunit.c:1834) ==24674==by 0xE947D5: cgraph_node::expand() (cgraphunit.c:1787) ==24674==by 0xE95D1F: expand_all_functions (cgraphunit.c:1998) ==24674==by 0xE95D1F: symbol_table::compile() [clone .part.0] (cgraphunit.c:2362) ==24674==by 0xE98957: compile (cgraphunit.c:2275) ==24674==by 0xE98957: symbol_table::finalize_compilation_unit() (cgraphunit.c:2543) ==24674==by 0x1369EFF: compile_file() (toplev.c:479) ==24674== Address 0x40 is not stack'd, malloc'd or (recently) free'd ==24674== during RTL pass: cse2 testcase.c: In function 'foo': testcase.c:28:1: internal compiler error: Segmentation fault 28 | } | ^ 0x1369c3f crash_signal /repo/gcc-trunk/gcc/toplev.c:322 0x2242c56 insert_with_costs /repo/gcc-trunk/gcc/cse.c:1569 0x2244f70 insert /repo/gcc-trunk/gcc/cse.c:1695 0x2244f70 merge_equiv_classes /repo/gcc-trunk/gcc/cse.c:1756 0x224f7f9 record_jump_equiv /repo/gcc-trunk/gcc/cse.c:3891 0x224f7f9 cse_extended_basic_block /repo/gcc-trunk/gcc/cse.c:6614 0x224f7f9 cse_main /repo/gcc-trunk/gcc/cse.c:6706 0x224fe40 rest_of_handle_cse2 /repo/gcc-trunk/gcc/cse.c:7592 0x224fe40 execute /repo/gcc-trunk/gcc/cse.c:7645 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r12-5492-20211124095444-g04eccbbe3d9-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --disable-bootstrap --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r12-5492-20211124095444-g04eccbbe3d9-checking-yes-rtl-df-extra-nobootstrap-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 12.0.0 20211124 (experimental) (GCC)
[Bug c++/103403] Decltype of rvalue reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103403 --- Comment #1 from Andrew Pinski --- This is a totally different issue and unrelated issue from PR 78209
[Bug c++/103403] [11/12 Regression] auto return type with a trailing return type of decl(auto) uses rvalue reference type instead of reference type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103403
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |11.3
Ever confirmed|0 |1
Known to fail||11.1.0
Summary|Decltype of rvalue |[11/12 Regression] auto
|reference |return type with a trailing
||return type of decl(auto)
||uses rvalue reference type
||instead of reference type
Status|UNCONFIRMED |NEW
Known to work||10.1.0, 10.3.0, 7.1.0
Last reconfirmed||2021-11-24
--- Comment #2 from Andrew Pinski ---
Here is a C++14 testcase which shows this is also a regression:
template
auto constexpr RtoL1(T&& r) -> decltype(auto) {
return (r);
};
int main() {
int t;
int x{3};
decltype (RtoL1(x+0)) y = t;
}
Confirmed.
[Bug libstdc++/103340] [12 Regression] constexpr std::string is incompatible with --enable-libstdcxx-allocator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103340 --- Comment #4 from Jonathan Wakely --- Created attachment 51866 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51866&action=edit Make all allocator base classes constexpr This patch would make bitmap_allocator, __mt_alloc and __pool_alloc usable as constexpr std::allocator in C++20. But I'm not going to commit it, because these allocators are just broken (see the linked PRs in the comment above). Instead, I'm going to remove them from the allowed --enable-libstdcxx-allocator options.
[Bug middle-end/103384] [OpenMP] declare variant with device={kind(nohost)} does not use GPU, kind(gpu) works
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103384 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Jakub Jelinek --- Fixed.
[Bug middle-end/103193] gcc for x86_64: wrong code generation: ucomiss instead of comiss
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103193 --- Comment #7 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:d9ca2ca381e44a332703155d07b50b84aa21f80d commit r12-5495-gd9ca2ca381e44a332703155d07b50b84aa21f80d Author: Richard Biener Date: Mon Nov 15 12:13:40 2021 +0100 middle-end/103193 - avoid canonicalizing <= and >= to == for floats This avoids doing aforementioned canoncalization when -ftrapping-math is in effect and we honor NaNs. 2021-11-15 Richard Biener PR middle-end/103193 * match.pd: Avoid canonicalizing (le/ge @0 @0) to (eq @0 @0) with NaNs and -ftrapping-math.
[Bug ada/103405] New: [12 Regression] c67005c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103405 Bug ID: 103405 Summary: [12 Regression] c67005c FAILs Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org Target Milestone: --- I see === acats tests === FAIL: c67005c === acats Summary === # of expected passes2327 # of unexpected failures1 Native configuration is x86_64-pc-linux-gnu it's reported to be failing since Nov 18th, also on powerpc64le
[Bug ada/103405] [12 Regression] c67005c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103405 Richard Biener changed: What|Removed |Added Target||x86_64-*-*, ||powerpc64le-linux Target Milestone|--- |12.0
[Bug middle-end/103193] gcc for x86_64: wrong code generation: ucomiss instead of comiss
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103193 Richard Biener changed: What|Removed |Added Known to work||12.0 --- Comment #8 from Richard Biener --- Fixed on trunk sofar, I'm going to backport to at least GCC 11 which where the issue was reported for but it's been broken forever (originally in fold-const.c:fold_comparison, moved in 2015).
[Bug ada/103405] [12 Regression] c67005c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103405 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Keywords||wrong-code Ever confirmed|0 |1 Last reconfirmed||2021-11-24 --- Comment #1 from Andrew Pinski --- for me it started between r12-5291-g3200de91bc70bfd6d and r12-5390-gd3152981f71eef1.
[Bug c++/103403] [11/12 Regression] auto return type with a trailing return type of decl(auto) uses rvalue reference type instead of reference type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103403 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug rtl-optimization/103404] ICE: SIGSEGV in insert_with_costs (cse.c:1569) with custom flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103404 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-11-24 Status|UNCONFIRMED |NEW --- Comment #1 from Richard Biener --- Confirmed.
[Bug ada/103405] [12 Regression] c67005c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103405 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- For me it is r12-5347-g2c2148d8c144d7388abcb7c34b782be647fe81c9 known good and r12-5385-g6f4ac4f81f89caac7e74127ed2e6db6bbb3d7426 known bad.
[Bug ipa/103405] [12 Regression] c67005c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103405 Andrew Pinski changed: What|Removed |Added Component|ada |ipa CC||marxin at gcc dot gnu.org --- Comment #3 from Andrew Pinski --- -O2 fails but -O2 -fno-ipa-modref pass.
[Bug ipa/103405] [12 Regression] c67005c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103405 --- Comment #4 from Andrew Pinski --- DSE removes a few stores even though they are used in the check. _18 = .gnat_malloc (4); MEM[(integer *)_18] = 1; ;; this one FRAME.2.i = _18; _17 = .gnat_malloc (4); MEM[(integer *)_17] = 0; ;; this one FRAME.2.j = _17; c67005c.B_1.check (0); [static-chain: &FRAME.2] _16 = .gnat_malloc (4); MEM[(integer *)_16] = 0; ;; this one FRAME.2.i = _16; c67005c.B_1.check (1); [static-chain: &FRAME.2] report.result ();
[Bug rtl-optimization/103404] ICE: SIGSEGV in insert_with_costs (cse.c:1569) with custom flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103404
--- Comment #2 from Richard Biener ---
Program received signal SIGSEGV, Segmentation fault.
0x028071dc in insert_with_costs (x=0x76739090, classp=0x0,
hash=13, mode=E_SImode, cost=0, reg_cost=1)
at /home/rguenther/src/gcc3/gcc/cse.c:1569
1569 if (CHEAPER (elt, classp))
where classp is NULL. The passed in class is
#2 0x028079e7 in merge_equiv_classes (class1=0x40b8700,
class2=0x3f0a950) at /home/rguenther/src/gcc3/gcc/cse.c:1756
1756 new_elt = insert (exp, class1, hash, mode);
(gdb) p *class1
$4 = {exp = 0x76739090, canon_exp = 0x0, next_same_hash = 0x40b85e0,
prev_same_hash = 0x0, next_same_value = 0x0, prev_same_value = 0x0,
first_same_value = 0x0, related_value = 0x0, cost = 0, regcost = 1,
mode = E_SImode, in_memory = 0 '\000', is_const = 0 '\000', flag = 0 '\000'}
It seems we remove class1 from the table while processing the merge:
#0 remove_from_table (elt=0x40b8700, hash=11)
at /home/rguenther/src/gcc3/gcc/cse.c:1354
#1 0x02806cc5 in remove_pseudo_from_table (x=0x76739090, hash=11)
at /home/rguenther/src/gcc3/gcc/cse.c:1426
#2 0x0280792d in merge_equiv_classes (class1=0x40b8700,
class2=0x3f0a950) at /home/rguenther/src/gcc3/gcc/cse.c:1747
and note it may even get re-used via the free_element_chain so it might
stay in the table but have a different purpose. Somebody more familiar
with the equivalence code needs to look at this. I'd try postponing
remove_pseudo_from_table until after the merge for example.
[Bug rtl-optimization/103404] ICE: SIGSEGV in insert_with_costs (cse.c:1569) with custom flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103404 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org, ||tnfchris at gcc dot gnu.org --- Comment #3 from Martin Liška --- Likely started with r12-4827-g68b48f3f4c49132c.
[Bug testsuite/103244] [12 regression] c-c++-common/goacc/firstprivate-mappings-1.c fails on arm since g:b7e20480630e3eeb9eed8b3941da3b3f0c22c969
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103244 --- Comment #2 from CVS Commits --- The master branch has been updated by Thomas Schwinge : https://gcc.gnu.org/g:fdd34569e7a9fc2b6c638a7ef62b965ed7e832ce commit r12-5498-gfdd34569e7a9fc2b6c638a7ef62b965ed7e832ce Author: Thomas Schwinge Date: Mon Nov 22 17:29:09 2021 +0100 Restore previous OpenACC implicit data clauses ordering [PR103244] Follow-up for recent commit b7e20480630e3eeb9eed8b3941da3b3f0c22c969 "openmp: Relax handling of implicit map vs. existing device mappings". As discussed, we likely also for OpenACC ought to use 'OMP_CLAUSE_MAP_RUNTIME_IMPLICIT_P' and do the appropriate implicit clauses ordering -- but that's for a separate step. gcc/ PR middle-end/103244 * gimplify.c (gimplify_adjust_omp_clauses): Restore previous OpenACC behavior. gcc/testsuite/ PR middle-end/103244 * c-c++-common/goacc/combined-reduction.c: Revert/expect previous OpenACC behavior. * c-c++-common/goacc/firstprivate-mappings-1.c: Likewise. * c-c++-common/goacc/mdc-1.c: Likewise. * g++.dg/goacc/firstprivate-mappings-1.C: Likewise.
[Bug ipa/103405] [12 Regression] c67005c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103405
--- Comment #5 from Andrew Pinski ---
C testcase:
typedef __SIZE_TYPE__ size_t;
void *malloc(size_t);
static inline int *starter(int a)
{
int *b = malloc(sizeof(int));
*b = a;
return b;
}
static inline _Bool equal(int *l, int *r)
{
if (l == 0)
__builtin_abort();
if (r == 0)
__builtin_abort();
return *r == *l;
}
int main(void)
{
int *i;
int *j;
void check(_Bool a)
{
_Bool t = equal(i, j);
if (a && t) __builtin_abort ();
_Bool t1 = equal(i, j);
if (!a && !t1) __builtin_abort ();
}
i = starter(1);
j = starter(0);
check(1);
i = starter(0);
check(0);
}
[Bug ipa/103405] [12 Regression] c67005c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103405 Jan Hubicka changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #6 from Jan Hubicka --- mine.
[Bug c/103406] New: gcc -O0 behaves differently on "DBL_MAX related operations" than gcc -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103406
Bug ID: 103406
Summary: gcc -O0 behaves differently on "DBL_MAX related
operations" than gcc -O1 and above
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: shaohua.li at inf dot ethz.ch
Target Milestone: ---
Hi there,
I found that for a piece of code, gcc would give out different results when
compiled with different opt flags.
- gcc version: 11.1.0
- Platform: Ubuntu 20.04, x86_64
$gcc a.c -O0; ./a.out
nan
$
$
$gcc a.c -O1; ./a.out
-nan
$
$
$cat a.c
#include
#include
#define INFINITY (DBL_MAX+DBL_MAX)
#define NAN (INFINITY-INFINITY)
void main() {
double x = -NAN;
double y = NAN;
double z = x + y;
printf("%lf\n", z);
}
[Bug testsuite/103244] [12 regression] c-c++-common/goacc/firstprivate-mappings-1.c fails in certain configurations since g:b7e20480630e3eeb9eed8b3941da3b3f0c22c969
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103244 Thomas Schwinge changed: What|Removed |Added Status|ASSIGNED|RESOLVED Summary|[12 regression] |[12 regression] |c-c++-common/goacc/firstpri |c-c++-common/goacc/firstpri |vate-mappings-1.c fails on |vate-mappings-1.c fails in |arm since |certain configurations |g:b7e20480630e3eeb9eed8b394 |since |1da3b3f0c22c969 |g:b7e20480630e3eeb9eed8b394 ||1da3b3f0c22c969 Resolution|--- |FIXED --- Comment #3 from Thomas Schwinge --- Expected to be fixed.
[Bug ipa/103405] [12 Regression] c67005c FAILs with -fipa-modref
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103405 Eric Botcazou changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org Summary|[12 Regression] c67005c |[12 Regression] c67005c |FAILs |FAILs with -fipa-modref --- Comment #7 from Eric Botcazou --- Yep, so far it's the only Ada issue I know of with -fipa-modref.
[Bug c/103406] gcc -O0 behaves differently on "DBL_MAX related operations" than gcc -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103406 --- Comment #1 from Andrew Pinski --- This is interesting. The trunk does 0.0 for both -O0 and -O1. ICC also does 0.0 for both -O0 and -O1 and -0.0 for -O2. clang does -nan for -O1, -O2 and -O0 MSVC does nan for /O2 and /O1 (7ff8) and for the non-optimizing case (I think if I read the assembly correctly).
[Bug c/103406] gcc -O0 behaves differently on "DBL_MAX related operations" than gcc -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103406 --- Comment #2 from Uroš Bizjak --- gcc/libgcc/config/i386/sfp-machine.h says: /* Here is something Intel misdesigned: the specs don't define the case where we have two NaNs with same mantissas, but different sign. Different operations pick up different NaNs. */
[Bug rtl-optimization/103404] ICE: SIGSEGV in insert_with_costs (cse.c:1569) with custom flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103404 Tamar Christina changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |tnfchris at gcc dot gnu.org --- Comment #4 from Tamar Christina --- Looks like it did start with my patch, so will take a look.
[Bug c/103406] gcc -O0 behaves differently on "DBL_MAX related operations" than gcc -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103406 --- Comment #3 from Andrew Pinski --- Hmm, the trunk is constant folding (maybe wrong?). We used to get for 11.1.0: _1 = 1.79769313486231570814527423731704356798070567525844996599e+308 * 2.0e+0; _2 = 1.79769313486231570814527423731704356798070567525844996599e+308 * 2.0e+0; _3 = _1 - _2; x_6 = -_3; But now we get 0.0.
[Bug tree-optimization/103168] Value numbering for PRE of pure functions can be improved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103168 --- Comment #18 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:6180f5c8d6d1dc7b6634c41a46f0f8f5ca2e5b9d commit r12-5499-g6180f5c8d6d1dc7b6634c41a46f0f8f5ca2e5b9d Author: Richard Biener Date: Wed Nov 24 09:08:44 2021 +0100 tree-optimization/103168 - Improve VN of pure function calls This improves value-numbering of calls that read memory, calls to const functions with aggregate arguments and calls to pure functions where the latter include const functions we demoted to pure for the fear of interposing with a less optimized version. Note that for pure functions we do not handle functions that access global memory. 2021-11-24 Richard Biener Jan Hubicka PR tree-optimization/103168 * ipa-modref.h (struct modref_summary): Add load_accesses. * ipa-modref.c (modref_summary::finalize): Initialize load_accesses. * tree-ssa-sccvn.c (visit_reference_op_call): Use modref info to walk the virtual use->def chain to CSE const/pure function calls possibly reading from memory. * g++.dg/tree-ssa/pr103168.C: New testcase.
[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 #8 from CVS Commits --- The releases/gcc-11 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:fa1ea255dba2d44ff22e434ed3d7778e8aaf4b91 commit r11-9275-gfa1ea255dba2d44ff22e434ed3d7778e8aaf4b91 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. (cherry picked from commit c59ec55c3459fba619e05ee7f59480b71e85ffd7)
[Bug libstdc++/100117] FAIL testsuite/17_intro/headers/c++1998/49745.cc with trunk glibc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100117 --- Comment #8 from CVS Commits --- The releases/gcc-11 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:176e55cc28a61b7b246bd9e16ffeaa31367a8985 commit r11-9277-g176e55cc28a61b7b246bd9e16ffeaa31367a8985 Author: Jonathan Wakely Date: Wed Nov 10 11:43:46 2021 + libstdc++: Fix test for libstdc++ not including [PR100117] The headers for the C library are not under our control, so we can't prevent them from including . Change the PR 49745 test to only include the C++ library headers, not the ones. To ensure isn't included automatically we need to use no_pch to disable PCH. libstdc++-v3/ChangeLog: PR libstdc++/100117 * testsuite/17_intro/headers/c++1998/49745.cc: Explicitly list all C++ headers instead of including (cherry picked from commit 77963796aef8aa07993c0bc757c15848fab7432a)
[Bug libstdc++/49745] error: ‘int truncate’ redeclared as different kind of symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49745 --- Comment #24 from CVS Commits --- The releases/gcc-11 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:176e55cc28a61b7b246bd9e16ffeaa31367a8985 commit r11-9277-g176e55cc28a61b7b246bd9e16ffeaa31367a8985 Author: Jonathan Wakely Date: Wed Nov 10 11:43:46 2021 + libstdc++: Fix test for libstdc++ not including [PR100117] The headers for the C library are not under our control, so we can't prevent them from including . Change the PR 49745 test to only include the C++ library headers, not the ones. To ensure isn't included automatically we need to use no_pch to disable PCH. libstdc++-v3/ChangeLog: PR libstdc++/100117 * testsuite/17_intro/headers/c++1998/49745.cc: Explicitly list all C++ headers instead of including (cherry picked from commit 77963796aef8aa07993c0bc757c15848fab7432a)
[Bug libstdc++/100153] Undefined behavior in stl_bvector.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100153 --- Comment #6 from CVS Commits --- The releases/gcc-11 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:c04b0f63243d4d474daa66f84874ebf6b9e7b0cd commit r11-9281-gc04b0f63243d4d474daa66f84874ebf6b9e7b0cd Author: Jonathan Wakely Date: Tue Apr 20 16:16:13 2021 +0100 libstdc++: Do not allocate a zero-size vector [PR 100153] The vector::shrink_to_fit() implementation will allocate new storage even if the vector is empty. That then leads to the end-of-storage pointer being non-null and equal to the _M_start._M_p pointer, which means that _M_end_addr() has undefined behaviour. The fix is to stop doing a useless zero-sized allocation in shrink_to_fit(), so that _M_start._M_p and _M_end_of_storage are both null after an empty vector shrinks. Signed-off-by: Jonathan Wakely libstdc++-v3/ChangeLog: PR libstdc++/100153 * include/bits/vector.tcc (vector::_M_shrink_to_fit()): When size() is zero just deallocate and reset. (cherry picked from commit 681707ec28d56494fa61a80c62500724d55f8586)
[Bug libstdc++/98421] std::span does not detect invalid range in Debug Mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98421 --- Comment #3 from CVS Commits --- The releases/gcc-11 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:238fd13380838ad57d199f3e9ca1d5403f33d381 commit r11-9291-g238fd13380838ad57d199f3e9ca1d5403f33d381 Author: Jonathan Wakely Date: Tue Aug 31 17:34:51 2021 +0100 libstdc++: Add valid range checks to std::span constructors [PR98421] Signed-off-by: Jonathan Wakely libstdc++-v3/ChangeLog: PR libstdc++/98421 * include/std/span (span(Iter, size_type), span(Iter, Iter)): Add valid range checks. * testsuite/23_containers/span/cons_1_assert_neg.cc: New test. * testsuite/23_containers/span/cons_2_assert_neg.cc: New test. (cherry picked from commit ef7becc9c8a48804d3fd9dac032f7b33e561a612)
[Bug libstdc++/102894] make_any is not SFINAE-friendly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102894 --- Comment #2 from CVS Commits --- The releases/gcc-11 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:88d481c9ee1e6a24dc11ab56d8688308e0211855 commit r11-9293-g88d481c9ee1e6a24dc11ab56d8688308e0211855 Author: Jonathan Wakely Date: Fri Oct 22 22:55:00 2021 +0100 libstdc++: Constrain std::make_any [PR102894] std::make_any should be constrained so it can only be called if the construction of the return value would be valid. libstdc++-v3/ChangeLog: PR libstdc++/102894 * include/std/any (make_any): Add SFINAE constraint. * testsuite/20_util/any/102894.cc: New test. (cherry picked from commit 0c1f737a485f05c591c94b50acfb416c45a4c916)
[Bug libstdc++/98725] Review what is disabled in libstdc++ by --disable-wchar_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98725 --- Comment #15 from CVS Commits --- The releases/gcc-11 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:ecc43c92151141e3e862a344f753516dc6d5d967 commit r11-9295-gecc43c92151141e3e862a344f753516dc6d5d967 Author: Jonathan Wakely Date: Fri Oct 8 14:26:09 2021 +0100 libstdc++: Define deleted wchar_t overloads unconditionally [PR 98725] We don't need to have support in order to delete overloads for inserting wide characters into narrow streams. libstdc++-v3/ChangeLog: PR libstdc++/98725 * include/std/ostream (operator<<(basic_ostream&, wchar_t)) (operator<<(basic_ostream&, const wchar_t*)): Always define as deleted. Do not check _GLIBCXX_USE_WCHAR_T. (cherry picked from commit 9a89281c4005a51eeed058ca66bcce8df1dd1b24)
[Bug libstdc++/98421] std::span does not detect invalid range in Debug Mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98421 Jonathan Wakely changed: What|Removed |Added Target Milestone|12.0|11.3
[Bug testsuite/100748] [12 regression] 30_threads/jthread/95989.cc fails after r12-843
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100748 --- Comment #11 from CVS Commits --- The releases/gcc-11 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:293075002a7eaf1e9d457a1839bcaf83f8626824 commit r11-9301-g293075002a7eaf1e9d457a1839bcaf83f8626824 Author: Jonathan Wakely Date: Tue Nov 9 23:45:36 2021 + libstdc++: Disable gthreads weak symbols for glibc 2.34 [PR103133] Since Glibc 2.34 all pthreads symbols are defined directly in libc not libpthread, and since Glibc 2.32 we have used __libc_single_threaded to avoid unnecessary locking in single-threaded programs. This means there is no reason to avoid linking to libpthread now, and so no reason to use weak symbols defined in gthr-posix.h for all the pthread_xxx functions. libstdc++-v3/ChangeLog: PR libstdc++/100748 PR libstdc++/103133 * config/os/gnu-linux/os_defines.h (_GLIBCXX_GTHREAD_USE_WEAK): Define for glibc 2.34 and later. (cherry picked from commit 80fe172ba9820199c2bbce5d0611ffca27823049)
[Bug libstdc++/103133] Binary built with -static using std::thread crashes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103133 --- Comment #9 from CVS Commits --- The releases/gcc-11 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:293075002a7eaf1e9d457a1839bcaf83f8626824 commit r11-9301-g293075002a7eaf1e9d457a1839bcaf83f8626824 Author: Jonathan Wakely Date: Tue Nov 9 23:45:36 2021 + libstdc++: Disable gthreads weak symbols for glibc 2.34 [PR103133] Since Glibc 2.34 all pthreads symbols are defined directly in libc not libpthread, and since Glibc 2.32 we have used __libc_single_threaded to avoid unnecessary locking in single-threaded programs. This means there is no reason to avoid linking to libpthread now, and so no reason to use weak symbols defined in gthr-posix.h for all the pthread_xxx functions. libstdc++-v3/ChangeLog: PR libstdc++/100748 PR libstdc++/103133 * config/os/gnu-linux/os_defines.h (_GLIBCXX_GTHREAD_USE_WEAK): Define for glibc 2.34 and later. (cherry picked from commit 80fe172ba9820199c2bbce5d0611ffca27823049)
[Bug c/103406] gcc -O0 behaves differently on "DBL_MAX related operations" than gcc -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103406 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Keywords||wrong-code Last reconfirmed||2021-11-24 --- Comment #4 from Richard Biener --- Already .original at -O0 has double x = -0.0; double y = 0.0; double z = x + y; printf ((const char * restrict) "%lf\n", z);
[Bug libstdc++/103133] Binary built with -static using std::thread crashes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103133 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Jonathan Wakely --- Fixed for GCC 11.3
[Bug libstdc++/103407] New: [12 regression] abi_check FAILs on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103407 Bug ID: 103407 Summary: [12 regression] abi_check FAILs on Solaris Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org Target Milestone: --- Target: *-*-solaris2.11 Between 2021 (dc002e31fb2d001703278263ea3d1cef366018ae) and 2023 (a246d7230b8f8b059b21a073e8a91c213dee9cf4), abi_check began to FAIL on Solaris, both sparc and x86, 32 and 64-bit: +FAIL: libstdc++-abi/abi_check 3 incompatible symbols 0 _ZSt10from_charsPKcS0_RfSt12chars_format std::from_chars(char const*, char const*, float&, std::chars_format) version status: incompatible GLIBCXX_3.4.29 type: function status: added 1 _ZSt10from_charsPKcS0_ReSt12chars_format std::from_chars(char const*, char const*, long double&, std::chars_format) version status: incompatible GLIBCXX_3.4.29 type: function status: added 2 _ZSt10from_charsPKcS0_RdSt12chars_format std::from_chars(char const*, char const*, double&, std::chars_format) version status: incompatible GLIBCXX_3.4.29 type: function status: added This coincides with the introduction of the GLIBCXX_3.4.30 version. After some searching, I found/remembered that the GCC 11.1 baselines on Solaris explicitly had omitted those symbols: https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566167.html to avoid having separate baselines for Solaris 11.3 (which lacks XPG7 support and thus uselocale) and 11.4 (which is XPG7 conformant). I'm uncertain how to handle this: * bite the bullet and introduce separate baselines for both versions (still supported by GCC 12) * filter out those symbols when generating baseline_symbols.txt * something else
[Bug libstdc++/103407] [12 regression] abi_check FAILs on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103407 Rainer Orth changed: What|Removed |Added Target Milestone|--- |12.0
[Bug c/103406] gcc -O0 behaves differently on "DBL_MAX related operations" than gcc -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103406
--- Comment #5 from Richard Biener ---
We are folding
(1.79769313486231570814527423731704356798070567525844996599e+308 * 2.0e+0) -
(1.79769313486231570814527423731704356798070567525844996599e+308 * 2.0e+0)
to 0.0 via
(simplify
(minus @0 @0)
(if (!FLOAT_TYPE_P (type) || !tree_expr_maybe_nan_p (@0))
{ build_zero_cst (type); }))
but appearantly even Inf - Inf is not zero.
[Bug c/103406] gcc -O0 behaves differently on "DBL_MAX related operations" than gcc -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103406 Richard Biener changed: What|Removed |Added CC||sayle at gcc dot gnu.org --- Comment #6 from Richard Biener --- Caused by g:5b02ed4b8768 but latent before (we missed !HONOR_INFINITIES on the pattern).
[Bug middle-end/103406] [12 Regression] gcc -O0 behaves differently on "DBL_MAX related operations" than gcc -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103406 Richard Biener changed: What|Removed |Added Summary|gcc -O0 behaves differently |[12 Regression] gcc -O0 |on "DBL_MAX related |behaves differently on |operations" than gcc -O1|"DBL_MAX related |and above |operations" than gcc -O1 ||and above Component|c |middle-end Target Milestone|--- |12.0
[Bug libstdc++/103407] [12 regression] abi_check FAILs on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103407 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Keywords||ABI
[Bug tree-optimization/103168] Value numbering for PRE of pure functions can be improved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103168 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #19 from Richard Biener --- Fixed.
[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 #4 from Richard Earnshaw --- I suspect the best we're likely to be able to do is to downgrade the ICE into an error if there's a long inline ASM in the code, much like the way we handle invalid constraints in inline ASMs.
[Bug libstdc++/101263] non-propagating-cache::emplace-deref missing constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101263 --- Comment #9 from Jonathan Wakely --- Fixed on trunk. It can't be backported without also backporting r12-1068 to fix PR100368.
[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 #5 from Jakub Jelinek --- That will still mean qemu will not compile. I admit I know next to nothing about the arm minipool stuff, but can't whatever needs to be inserted be inserted either before or after the inline asm, if it is needed for the asm inputs then likely before that?
[Bug middle-end/103406] [12 Regression] gcc -O0 behaves differently on "DBL_MAX related operations" than gcc -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103406
Roger Sayle changed:
What|Removed |Added
CC||roger at nextmovesoftware dot
com
Assignee|unassigned at gcc dot gnu.org |roger at
nextmovesoftware dot com
Status|NEW |ASSIGNED
--- Comment #7 from Roger Sayle ---
I'm currently bootstrapping and regression testing this fix:
(simplify
(minus @0 @0)
- (if (!FLOAT_TYPE_P (type) || !tree_expr_maybe_nan_p (@0))
+ (if (!FLOAT_TYPE_P (type)
+ || (!tree_expr_maybe_nan_p (@0)
+ && !tree_expr_maybe_infinite_p (@0)))
{ build_zero_cst (type); }))
[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 Andrew Stubbs changed: What|Removed |Added Last reconfirmed||2021-11-24 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ams at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #4 from Andrew Stubbs --- I think I have a fix for this. It happens when the link register has to be saved because it is used implicitly by a function call, but the register is never explicitly mentioned anywhere else in the function. I don't know why this hasn't been a problem before now?
[Bug libstdc++/103407] [12 regression] abi_check FAILs on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103407 --- Comment #1 from Jonathan Wakely --- (In reply to Rainer Orth from comment #0) > * something else This one! :-) Patrick is in the process of replacing my janky std::from_chars implementation with something faster and more standards-conforming, which will mean we stop using strtof and strtod, and so don't need the uselocale kluge to make the conversions locale-independent. That should mean that the float and double overloads can be defined unconditionally for Solaris 11.3. Then we have two problems: If we add those symbols now, they would be in the 3.4.30 version for Solaris 11.3 and 3.4.29 for Solaris 11.4, which I assume you don't want. Secondly, it wouldn't change anything for the long double overload.
[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 --- Comment #12 from Martin Jambor --- Some testing is still underway, but I have proposed the patch (with one minor testsuite change) on the mailing list: https://gcc.gnu.org/pipermail/gcc-patches/2021-November/585337.html
[Bug middle-end/103406] [12 Regression] gcc -O0 behaves differently on "DBL_MAX related operations" than gcc -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103406
--- Comment #8 from Richard Biener ---
And the -nan vs. nan is because we fold x + -y to x - y:
/* We can't reassociate at all for saturating types. */
(if (!TYPE_SATURATING (type))
/* Contract negates. */
/* A + (-B) -> A - B */
(simplify
(plus:c @0 (convert? (negate @1)))
/* Apply STRIP_NOPS on the negate. */
(if (tree_nop_conversion_p (type, TREE_TYPE (@1))
&& !TYPE_OVERFLOW_SANITIZED (type))
(with
{
tree t1 = type;
if (INTEGRAL_TYPE_P (type)
&& TYPE_OVERFLOW_WRAPS (type) != TYPE_OVERFLOW_WRAPS (TREE_TYPE (@1)))
t1 = TYPE_OVERFLOW_WRAPS (type) ? type : TREE_TYPE (@1);
}
(convert (minus (convert:t1 @0) (convert:t1 @1))
all the negate contracting misses HONOR_SIGNED_ZEROS/HONOR_NANS checking?
Not sure if they are really a problem for signed zeros? If so we should
try to get a testcase for that as well.
diff --git a/gcc/match.pd b/gcc/match.pd
index 5adcd6bd02c..9cdd113e02c 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -2471,7 +2473,8 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
(plus:c @0 (convert? (negate @1)))
/* Apply STRIP_NOPS on the negate. */
(if (tree_nop_conversion_p (type, TREE_TYPE (@1))
- && !TYPE_OVERFLOW_SANITIZED (type))
+ && !TYPE_OVERFLOW_SANITIZED (type)
+ && (!FLOAT_TYPE_P (type) || !tree_expr_maybe_nan_p (@1)))
(with
{
tree t1 = type;
@@ -2484,7 +2487,8 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
(simplify
(minus @0 (convert? (negate @1)))
(if (tree_nop_conversion_p (type, TREE_TYPE (@1))
- && !TYPE_OVERFLOW_SANITIZED (type))
+ && !TYPE_OVERFLOW_SANITIZED (type)
+ && (!FLOAT_TYPE_P (type) || !tree_expr_maybe_nan_p (@1)))
(with
{
tree t1 = type;
btw, that doesn't fix it since combine will happily contract the negate as
well:
- 10: {r88:DF=-r83:DF;use r89:V2DF;clobber flags:CC;}
- REG_DEAD r89:V2DF
- REG_UNUSED flags:CC
- 11: r90:DF=r88:DF+r83:DF
- REG_DEAD r88:DF
+9: NOTE_INSN_DELETED
+ 10: NOTE_INSN_DELETED
+ 11: r90:DF=r83:DF-r83:DF
[Bug middle-end/103406] [12 Regression] gcc -O0 behaves differently on "DBL_MAX related operations" than gcc -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103406 --- Comment #9 from Richard Biener --- simplify_binary_operation_1 has /* ((-a) + b) -> (b - a) and similarly for (a + (-b)). These transformations are safe even for IEEE. */ if (GET_CODE (op0) == NEG) return simplify_gen_binary (MINUS, mode, op1, XEXP (op0, 0)); else if (GET_CODE (op1) == NEG) return simplify_gen_binary (MINUS, mode, op0, XEXP (op1, 0));
[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 #6 from Richard Earnshaw --- It depends on the the reference. Some minipool references can only be forwards due to the nature of the instruction making the reference. I'll need to take a look, and I might also need a real testcase, not just the reduced one below.
[Bug middle-end/103406] [12 Regression] gcc -O0 behaves differently on "DBL_MAX related operations" than gcc -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103406 Richard Biener changed: What|Removed |Added CC||jsm28 at gcc dot gnu.org --- Comment #10 from Richard Biener --- But I'm not sure what the stance is on the sign of NaNs
[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 #7 from Jakub Jelinek --- Created attachment 51867 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51867&action=edit qemuice.i.xz Unreduced preprocessed source.
[Bug middle-end/103059] [12 regression][VAX] ICE in postreload with the ASHIFT form of scaled indexed addressing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103059
--- Comment #1 from CVS Commits ---
The master branch has been updated by Maciej W. Rozycki :
https://gcc.gnu.org/g:29e1cbdc0c6e7d3de10478ef2b881900545c2a55
commit r12-5500-g29e1cbdc0c6e7d3de10478ef2b881900545c2a55
Author: Maciej W. Rozycki
Date: Wed Nov 24 13:15:06 2021 +
PR middle-end/103059: reload: Also accept ASHIFT with indexed addressing
Correct a `vax-netbsdelf' target regression ultimately caused by commit
c605a8bf9270 ("VAX: Accept ASHIFT in address expressions") (needed for
LRA) and as of commit 4a960d548b7d ("Avoid invalid loop transformations
in jump threading registry.") causing a build error in libgcc:
.../libgcc/libgcov-driver.c: In function 'gcov_do_dump':
.../libgcc/libgcov-driver.c:686:1: error: insn does not satisfy its
constraints:
686 | }
| ^
(insn 2051 2050 2052 185 (set (reg/f:SI 0 %r0 [555])
(plus:SI (ashift:SI (mem/c:SI (plus:SI (reg/f:SI 13 %fp)
(const_int -28 [0xffe4])) [40 %sfp+-28
S4 A32])
(const_int 3 [0x3]))
(plus:SI (reg/v/f:SI 9 %r9 [orig:176 fn_buffer ] [176])
(const_int 24 [0x18]
".../libgcc/libgcov-driver.c":172:40 614 {movaddrdi}
(nil))
during RTL pass: postreload
.../libgcc/libgcov-driver.c:686:1: internal compiler error: in
extract_constrain_insn, at recog.c:2670
0x1122a5ff _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
.../gcc/rtl-error.c:108
0x1122a697 _fatal_insn_not_found(rtx_def const*, char const*, int, char
const*)
.../gcc/rtl-error.c:118
0x111b5f2f extract_constrain_insn(rtx_insn*)
.../gcc/recog.c:2670
0x11143eef reload_cse_simplify_operands
.../gcc/postreload.c:407
0x11142fdb reload_cse_simplify
.../gcc/postreload.c:132
0x11143533 reload_cse_regs_1
.../gcc/postreload.c:238
0x11142ce7 reload_cse_regs
.../gcc/postreload.c:66
0x1114af33 execute
.../gcc/postreload.c:2355
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See ,
and commit 6b3034eaba83 ("lra: Canonicalize mult to shift in address
reloads").
gcc/
PR middle-end/103059
* reload.c (find_reloads_address_1): Also accept the ASHIFT form
of indexed addressing.
(find_reloads): Adjust accordingly.
[Bug middle-end/103059] [12 regression][VAX] ICE in postreload with the ASHIFT form of scaled indexed addressing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103059
--- Comment #2 from CVS Commits ---
The releases/gcc-11 branch has been updated by Maciej W. Rozycki
:
https://gcc.gnu.org/g:78421afafde5156d6d4c6c7073653e4b92f88e3d
commit r11-9306-g78421afafde5156d6d4c6c7073653e4b92f88e3d
Author: Maciej W. Rozycki
Date: Wed Nov 24 13:15:06 2021 +
PR middle-end/103059: reload: Also accept ASHIFT with indexed addressing
Correct a `vax-netbsdelf' target regression ultimately caused by commit
c605a8bf9270 ("VAX: Accept ASHIFT in address expressions") (needed for
LRA) and as of commit 4a960d548b7d ("Avoid invalid loop transformations
in jump threading registry.") causing a build error in libgcc:
.../libgcc/libgcov-driver.c: In function 'gcov_do_dump':
.../libgcc/libgcov-driver.c:686:1: error: insn does not satisfy its
constraints:
686 | }
| ^
(insn 2051 2050 2052 185 (set (reg/f:SI 0 %r0 [555])
(plus:SI (ashift:SI (mem/c:SI (plus:SI (reg/f:SI 13 %fp)
(const_int -28 [0xffe4])) [40 %sfp+-28
S4 A32])
(const_int 3 [0x3]))
(plus:SI (reg/v/f:SI 9 %r9 [orig:176 fn_buffer ] [176])
(const_int 24 [0x18]
".../libgcc/libgcov-driver.c":172:40 614 {movaddrdi}
(nil))
during RTL pass: postreload
.../libgcc/libgcov-driver.c:686:1: internal compiler error: in
extract_constrain_insn, at recog.c:2670
0x1122a5ff _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
.../gcc/rtl-error.c:108
0x1122a697 _fatal_insn_not_found(rtx_def const*, char const*, int, char
const*)
.../gcc/rtl-error.c:118
0x111b5f2f extract_constrain_insn(rtx_insn*)
.../gcc/recog.c:2670
0x11143eef reload_cse_simplify_operands
.../gcc/postreload.c:407
0x11142fdb reload_cse_simplify
.../gcc/postreload.c:132
0x11143533 reload_cse_regs_1
.../gcc/postreload.c:238
0x11142ce7 reload_cse_regs
.../gcc/postreload.c:66
0x1114af33 execute
.../gcc/postreload.c:2355
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See ,
and commit 6b3034eaba83 ("lra: Canonicalize mult to shift in address
reloads").
gcc/
PR middle-end/103059
* reload.c (find_reloads_address_1): Also accept the ASHIFT form
of indexed addressing.
(find_reloads): Adjust accordingly.
(cherry picked from commit 29e1cbdc0c6e7d3de10478ef2b881900545c2a55)
[Bug middle-end/103059] [12 regression][VAX] ICE in postreload with the ASHIFT form of scaled indexed addressing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103059 Maciej W. Rozycki changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Maciej W. Rozycki --- Fixed on trunk and backported to GCC 11. Closing bug.
[Bug target/103393] [12 Regression] Generating 256bit register usage with -mprefer-avx128 -mprefer-vector-width=128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103393 --- Comment #2 from H.J. Lu --- (In reply to Richard Biener from comment #1) > It isn't the vectorizer but memmove inline expansion. I'm not sure it's > really a bug, but there isn't a way to disable %ymm use besides disabling > AVX entirely. > HJ? YMM move is generated by loop distribution which doesn't check TARGET_PREFER_AVX128.
[Bug target/103393] [12 Regression] Generating 256bit register usage with -mprefer-avx128 -mprefer-vector-width=128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103393 Richard Biener changed: What|Removed |Added CC||rearnsha at gcc dot gnu.org --- Comment #3 from Richard Biener --- (In reply to H.J. Lu from comment #2) > (In reply to Richard Biener from comment #1) > > It isn't the vectorizer but memmove inline expansion. I'm not sure it's > > really a bug, but there isn't a way to disable %ymm use besides disabling > > AVX entirely. > > HJ? > > YMM move is generated by loop distribution which doesn't check > TARGET_PREFER_AVX128. I think it's generated by gimple_fold_builtin_memory_op which since Richards changes accepts bigger now, up to MOVE_MAX * MOVE_RATIO and that ends up picking an integer mode via scalar_int_mode mode; if (int_mode_for_size (ilen * 8, 0).exists (&mode) && GET_MODE_SIZE (mode) * BITS_PER_UNIT == ilen * 8 && have_insn_for (SET, mode) /* If the destination pointer is not aligned we must be able to emit an unaligned store. */ && (dest_align >= GET_MODE_ALIGNMENT (mode) || !targetm.slow_unaligned_access (mode, dest_align) || (optab_handler (movmisalign_optab, mode) != CODE_FOR_nothing))) not sure if there's another way to validate things.
[Bug c++/92145] -Wdeprecated-copy false-positive when inheriting base assignment operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92145 --- Comment #3 from Nikita Kniazev --- (In reply to Marek Polacek from comment #2) > Fixed? It is fixed on trunk but still presented in every release (since the fix landed 9.4 and 11.2 were released). I assume it was not backported, could you please backport the fix to 9, 10, 11 branches?
[Bug tree-optimization/103231] [12 Regression] ICE (nondeterministic/stack overflow) on valid code at -O1 on x86_64-linux-gnu: Segmentation fault since r12-5014-g6b8b959675a3e14c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103231 --- Comment #13 from CVS Commits --- The master branch has been updated by Andrew Macleod : https://gcc.gnu.org/g:5deacf6058d1bc7261a75c9fd1f116c4442e9e60 commit r12-5505-g5deacf6058d1bc7261a75c9fd1f116c4442e9e60 Author: Andrew MacLeod Date: Mon Nov 22 14:39:41 2021 -0500 Directly resolve range_of_stmt dependencies. All ranger API entries eventually call range_of_stmt to ensure there is an initial global value to work with. This can cause very deep call chains when satisfied via the normal API. Instead, push any dependencies onto a stack and evaluate them in a depth first manner, mirroring what would have happened via the normal API calls. PR tree-optimization/103231 gcc/ * gimple-range.cc (gimple_ranger::gimple_ranger): Create stmt stack. (gimple_ranger::gimple_ranger): Delete stmt stack. (gimple_ranger::range_of_stmt): Process depenedencies if they have no global cache entry. (gimple_ranger::prefill_name): New. (gimple_ranger::prefill_stmt_dependencies): New. * gimple-range.h (class gimple_ranger): Add prototypes.
[Bug tree-optimization/103231] [12 Regression] ICE (nondeterministic/stack overflow) on valid code at -O1 on x86_64-linux-gnu: Segmentation fault since r12-5014-g6b8b959675a3e14c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103231 Andrew Macleod changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #14 from Andrew Macleod --- Should be fixed.
[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 #10 from Roger Sayle --- Many thanks to Jakub for the speedy fix (and Richard B for the speedy review), and my apologies for the inconvenience. As diagnosed by Jakub, I hadn't realized that the bswap pass was performing additional optimizations, and simplifying x op x as just x, doesn't work for plus and xor the same way as it does for ior. Thank you to Jakub again.
[Bug c++/103403] [11/12 Regression] auto return type with a trailing return type of decl(auto) uses rvalue reference type instead of reference type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103403 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org --- Comment #3 from Marek Polacek --- Started with my r11-4758, sigh.
[Bug c++/103401] [11/12 Regression] gcc accepts decltype(auto(0)) as the parameter of the function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103401 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek --- Mine then.
