[Bug target/103353] Indefinite recursion when compiling -mmma requiring testcase w/ -maltivec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103353 --- Comment #8 from CVS Commits --- The master branch has been updated by Kewen Lin : https://gcc.gnu.org/g:9367e3a65f874dffc8f8a3b6760e77fd9ed67117 commit r13-2062-g9367e3a65f874dffc8f8a3b6760e77fd9ed67117 Author: Kewen.Lin Date: Tue Aug 16 00:24:07 2022 -0500 rs6000: Adjust mov optabs for opaque modes [PR103353] As PR103353 shows, we may want to continue to expand built-in function __builtin_vsx_lxvp, even if we have already emitted error messages about some missing required conditions. As shown in that PR, without one explicit mov optab on OOmode provided, it would call emit_move_insn recursively. So this patch is to allow the mov pattern to be generated during expanding phase if compiler has already seen errors. PR target/103353 gcc/ChangeLog: * config/rs6000/mma.md (define_expand movoo): Move TARGET_MMA condition check to preparation statements and add handlings for !TARGET_MMA. (define_expand movxo): Likewise. gcc/testsuite/ChangeLog: * gcc.target/powerpc/pr103353.c: New test.
[Bug tree-optimization/106322] [12/13 Regression] tree-vectorize: Wrong code at O2 level (-fno-tree-vectorize is working) since r12-2404-ga1d27560770818c5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106322 --- Comment #46 from CVS Commits --- The master branch has been updated by Kewen Lin : https://gcc.gnu.org/g:5239e2bd48fb1e6a1d1b06a1bac49bee0a742e98 commit r13-2061-g5239e2bd48fb1e6a1d1b06a1bac49bee0a742e98 Author: Kewen Lin Date: Tue Aug 16 00:18:51 2022 -0500 vect: Don't allow vect_emulated_vector_p type in vectorizable_call [PR106322] As PR106322 shows, in some cases for some vector type whose TYPE_MODE is a scalar integral mode instead of a vector mode, it's possible to obtain wrong target support information when querying with the scalar integral mode. For example, for the test case in PR106322, on ppc64 32bit vectorizer gets vector type "vector(2) short unsigned int" for scalar type "short unsigned int", its mode is SImode instead of V2HImode. The target support querying checks umul_highpart optab with SImode and considers it's supported, then vectorizer further generates .MULH IFN call for that vector type. Unfortunately it's wrong to use SImode support for that vector type multiply highpart here. This patch is to teach vectorizable_call analysis not to allow vect_emulated_vector_p type for both vectype_in and vectype_out as Richi suggested. PR tree-optimization/106322 gcc/ChangeLog: * tree-vect-stmts.cc (vectorizable_call): Don't allow vect_emulated_vector_p type for both vectype_in and vectype_out. gcc/testsuite/ChangeLog: * gcc.target/i386/pr106322.c: New test. * gcc.target/powerpc/pr106322.c: New test.
[Bug analyzer/106634] New: [13 Regression] ICE in get_region_for_local, at analyzer/region.cc:874
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106634 Bug ID: 106634 Summary: [13 Regression] ICE in get_region_for_local, at analyzer/region.cc:874 Product: gcc Version: 13.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: asolokha at gmx dot com Target Milestone: --- gcc 13.0.0 20220814 snapshot (g:fe4dc4f553d8639b0ce3465e5e6dcf61c1ae9752) ICEs when compiling gcc/testsuite/gcc.dg/torture/pr92088-1.c w/ -fanalyzer: % gcc-13.0.0 -fanalyzer -c gcc/testsuite/gcc.dg/torture/pr92088-1.c during IPA pass: analyzer gcc/testsuite/gcc.dg/torture/pr92088-1.c: In function 'g': gcc/testsuite/gcc.dg/torture/pr92088-1.c:7:11: internal compiler error: in get_region_for_local, at analyzer/region.cc:874 7 | return p[9]; | ~^~~ 0x7c7dd8 ana::frame_region::get_region_for_local(ana::region_model_manager*, tree_node*, ana::region_model_context const*) const /var/tmp/portage/sys-devel/gcc-13.0.0_p20220814/work/gcc-13-20220814/gcc/analyzer/region.cc:874 0x12d23f2 ana::region_model::get_lvalue(ana::path_var, ana::region_model_context*) const /var/tmp/portage/sys-devel/gcc-13.0.0_p20220814/work/gcc-13-20220814/gcc/analyzer/region-model.cc:2618 0x12cebc7 ana::region_model::get_rvalue_1(ana::path_var, ana::region_model_context*) const /var/tmp/portage/sys-devel/gcc-13.0.0_p20220814/work/gcc-13-20220814/gcc/analyzer/region-model.cc:2677 0x12cf04c ana::region_model::get_rvalue(ana::path_var, ana::region_model_context*) const /var/tmp/portage/sys-devel/gcc-13.0.0_p20220814/work/gcc-13-20220814/gcc/analyzer/region-model.cc:2752 0x12ce26e ana::region_model::check_region_bounds(ana::region const*, ana::access_direction, ana::region_model_context*) const /var/tmp/portage/sys-devel/gcc-13.0.0_p20220814/work/gcc-13-20220814/gcc/analyzer/region-model.cc:1651 0x12ce73b ana::region_model::check_region_access(ana::region const*, ana::access_direction, ana::region_model_context*) const /var/tmp/portage/sys-devel/gcc-13.0.0_p20220814/work/gcc-13-20220814/gcc/analyzer/region-model.cc:3236 0x12ce73b ana::region_model::check_region_for_read(ana::region const*, ana::region_model_context*) const /var/tmp/portage/sys-devel/gcc-13.0.0_p20220814/work/gcc-13-20220814/gcc/analyzer/region-model.cc:3266 0x12ce73b ana::region_model::get_store_value(ana::region const*, ana::region_model_context*) const /var/tmp/portage/sys-devel/gcc-13.0.0_p20220814/work/gcc-13-20220814/gcc/analyzer/region-model.cc:2850 0x12cf04c ana::region_model::get_rvalue(ana::path_var, ana::region_model_context*) const /var/tmp/portage/sys-devel/gcc-13.0.0_p20220814/work/gcc-13-20220814/gcc/analyzer/region-model.cc:2752 0x12d61c7 ana::region_model::on_assignment(gassign const*, ana::region_model_context*) /var/tmp/portage/sys-devel/gcc-13.0.0_p20220814/work/gcc-13-20220814/gcc/analyzer/region-model.cc:1089 0x12aaf48 ana::exploded_node::on_stmt(ana::exploded_graph&, ana::supernode const*, gimple const*, ana::program_state*, ana::uncertainty_t*, ana::path_context*) /var/tmp/portage/sys-devel/gcc-13.0.0_p20220814/work/gcc-13-20220814/gcc/analyzer/engine.cc:1430 0x12addef ana::exploded_graph::process_node(ana::exploded_node*) /var/tmp/portage/sys-devel/gcc-13.0.0_p20220814/work/gcc-13-20220814/gcc/analyzer/engine.cc:3868 0x12aee1a ana::exploded_graph::process_worklist() /var/tmp/portage/sys-devel/gcc-13.0.0_p20220814/work/gcc-13-20220814/gcc/analyzer/engine.cc:3271 0x12b14bc ana::impl_run_checkers(ana::logger*) /var/tmp/portage/sys-devel/gcc-13.0.0_p20220814/work/gcc-13-20220814/gcc/analyzer/engine.cc:5912 0x12b250e ana::run_checkers() /var/tmp/portage/sys-devel/gcc-13.0.0_p20220814/work/gcc-13-20220814/gcc/analyzer/engine.cc:5986 0x12a14b8 execute /var/tmp/portage/sys-devel/gcc-13.0.0_p20220814/work/gcc-13-20220814/gcc/analyzer/analyzer-pass.cc:87
[Bug tree-optimization/106533] loop distribution not distributing inner loop (to memcpy) when perfect loop nest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106533 --- Comment #7 from Vineet Gupta --- Can this be back-ported to gcc 12 please ?
[Bug analyzer/106620] Incorrectly thinks execution can continue after a return statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106620 --- Comment #3 from nrk at disroot dot org --- > Feel free to reopen it if you're able to reproduce it with gcc 12 or later Huh, I linked to godbolt specifically because I wanted to test gcc 12 and see if the bug still persists or not since my local version is at 11.2.1. But looks like I messed it up. In any case, thanks for fixing it!
[Bug c++/106633] Hidden visibility on forward declarations impacts visibility of default-visibility class methods
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106633 Mike Hommey changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Mike Hommey --- Started with https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=a53781c8fd258608780821168a7f5faf7be63690;hp=ba9b07d0259b38a9eccd4eb0df327d3aaabad3c6 ... which points to the fact that this is now consistent with the behavior of forward declarations of any other class...
[Bug c++/106633] Hidden visibility on forward declarations impacts visibility of default-visibility class methods
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106633 --- Comment #1 from Andrew Pinski --- I don't think this is a gcc bug but rather gcc 12 fixed a bug
[Bug c++/106633] New: Hidden visibility on forward declarations impacts visibility of default-visibility class methods
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106633
Bug ID: 106633
Summary: Hidden visibility on forward declarations impacts
visibility of default-visibility class methods
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mh+gcc at glandium dot org
Target Milestone: ---
This was not happening before GCC 12.
Reduced testcase from a Firefox build failure we got in Debian on armhf:
```
#pragma GCC visibility push(hidden)
namespace std { class type_info; }
#pragma GCC visibility pop
#include
bool foo(std::type_info& a, std::type_info& b) { return a == b; }
```
Compile with `-O2 -D__GXX_TYPEINFO_EQUALITY_INLINE=0` (the define makes the
problem appear on all platforms, rather than armhf only)
What happens in this example is that the symbol reference to
`std::type_info::operator==` ends up with hidden visibility, instead of default
visibility. With GCC 11 and older versions, it would end up with default
visibility.
On godbolt:
https://godbolt.org/z/hYKjWGaeq
(Ironically(?), that forward declaration comes from ICU working around an old
bug in libstdc++ headers)
[Bug target/106586] riscv32 still broke with zba_zbb_zbc_zbs, ICE in do_SUBST in C++ code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106586 --- Comment #13 from Andrew Pinski --- All patches I have pushed to refs/users/pinskia/heads/riscvbit this includes all cleanups I did to the backend. I will finish up the patches (add testcases and run the testsuite) in the next few days.
[Bug target/106632] undefined code causes assembler failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106632 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2022-08-15 Status|UNCONFIRMED |ASSIGNED --- Comment #1 from Andrew Pinski --- Mine. Fixed: diff --git a/gcc/config/riscv/bitmanip.md b/gcc/config/riscv/bitmanip.md index 6f5f18eda41..80c5ccbfcbf 100644 --- a/gcc/config/riscv/bitmanip.md +++ b/gcc/config/riscv/bitmanip.md @@ -354,6 +354,6 @@ (define_insn "*bexti" (zero_extract:X (match_operand:X 1 "register_operand" "r") (const_int 1) (match_operand 2 "immediate_operand" "n")))] - "TARGET_ZBS" + "TARGET_ZBS && UINTVAL (operands[2]) < GET_MODE_BITSIZE (mode)" "bexti\t%0,%1,%2"
[Bug target/106632] New: undefined code causes assembler failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106632
Bug ID: 106632
Summary: undefined code causes assembler failure
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: assemble-failure
Severity: normal
Priority: P3
Component: target
Assignee: pinskia at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Target: riscv-linux-gnu
Take:
long f(long a, long b)
{
b = 66;
return (a >> b) & 1;
}
This will produce:
f:
bexti a0,a0,66
ret
Which is invalid assembly as rejected by gas:
/tmp/ccTvKnLv.s: Assembler messages:
/tmp/ccTvKnLv.s:8: Error: improper shift amount (66)
[Bug target/106586] riscv32 still broke with zba_zbb_zbc_zbs, ICE in do_SUBST in C++ code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106586 --- Comment #12 from Andrew Pinski --- Created attachment 53463 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53463=edit Patch (which might depend on other patches) I have a full fix now. The problem I mentioned is a few different issues. First is SINGLE_BIT_MASK_OPERAND is not correct for 32bit for INT_MAX. single_bit_mask_operand and not_single_bit_mask_operand should be using SINGLE_BIT_MASK_OPERAND now too to correct for that also. Next issue is riscv_build_integer_1 should not special case SImode for !TARAGET_64BIT, it is already correct. The next issue is riscv_build_integer_1 needs to do trunc_int_for_mode. And then riscv_move_integer should do that also. Last but not least riscv_emit_int_compare forgot to do trunc_int_for_mode also.
[Bug target/106586] riscv32 still broke with zba_zbb_zbc_zbs, ICE in do_SUBST in C++ code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106586 --- Comment #11 from Andrew Pinski --- There was a few issues dealing with not doing trunc_int_for_mode in some cases.
[Bug tree-optimization/106630] [13 Regression] ICE: Segmentation fault signal terminated program cc1plus with -O2 since r13-1268-g8c99e307b20c50
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106630 --- Comment #5 from Aldy Hernandez --- (In reply to Andrew Pinski from comment #4) > > It looks like DOM2, as a side-effect of using the ranger to do cprop, is > > exporting a global range for a_9 > > Where a_9 has a global range of [0,0]. > > Why didn't DOM do a constant prop here since the only value for a_9 is 0 ... The only uses of a_9 are in PHIs: [local count: 4724464]: # a_9 = PHI goto ; [100.00%] ... ... [local count: 42949672]: # a_23 = PHI goto ; [100.00%] Perhaps DOM doesn't cprop into PHIs? actually: static void cprop_into_successor_phis (basic_block bb, class const_and_copies *const_and_copies) But that only works with DOM's internal const_and_copies tables, not with ranger (or originally with the evrp engine).
[Bug tree-optimization/106630] [13 Regression] ICE: Segmentation fault signal terminated program cc1plus with -O2 since r13-1268-g8c99e307b20c50
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106630 --- Comment #4 from Andrew Pinski --- > It looks like DOM2, as a side-effect of using the ranger to do cprop, is > exporting a global range for a_9 > Where a_9 has a global range of [0,0]. Why didn't DOM do a constant prop here since the only value for a_9 is 0 ...
[Bug target/106586] riscv32 still broke with zba_zbb_zbc_zbs, ICE in do_SUBST in C++ code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106586
--- Comment #10 from Andrew Pinski ---
There is still some missing sign extend of the const_int.
(insn 17 16 18 4 (set (reg:SI 77)
(mem/u/c:SI (lo_sum:SI (reg/f:SI 78)
(symbol_ref/u:SI ("*.LC0") [flags 0x82])) [0 S4 A32]))
"t89.c":5:16 140 {*movsi_internal}
(expr_list:REG_DEAD (reg/f:SI 78)
(expr_list:REG_EQUAL (const_int 2147483648 [0x8000])
(nil
Notice the REG_EQUAL.
I think the issue is inside riscv_build_integer_1.
Specifically this:
alt_cost = 1 + riscv_build_integer_1 (alt_codes, value - low_part, mode);
[Bug tree-optimization/106630] [13 Regression] ICE: Segmentation fault signal terminated program cc1plus with -O2 since r13-1268-g8c99e307b20c50
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106630 Aldy Hernandez changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #3 from Aldy Hernandez --- It looks like DOM2, as a side-effect of using the ranger to do cprop, is exporting a global range for a_9 that is causing a match.pd pattern to go into an endless loop. I don't understand match.pd patterns very well. Could someone see if there is something obvious going on in the pattern? This is .ivopts: Applying pattern match.pd:3164, generic-match.cc:22877 Matching expression match.pd:1894, generic-match.cc:676 Applying pattern match.pd:3164, generic-match.cc:22877 Matching expression match.pd:1894, generic-match.cc:676 Applying pattern match.pd:3164, generic-match.cc:22877 Matching expression match.pd:1894, generic-match.cc:676 Applying pattern match.pd:3164, generic-match.cc:22877 Matching expression match.pd:1894, generic-match.cc:676 Applying pattern match.pd:3164, generic-match.cc:22877 Matching expression match.pd:1894, generic-match.cc:676 Matching expression match.pd:1894, generic-match.cc:676 Applying pattern match.pd:1921, generic-match.cc:27593 Matching expression match.pd:146, generic-match.cc:23 Matching expression match.pd:1894, generic-match.cc:676 Applying pattern match.pd:3164, generic-match.cc:22877 Matching expression match.pd:1894, generic-match.cc:676 Applying pattern match.pd:3164, generic-match.cc:22877 Matching expression match.pd:1894, generic-match.cc:676 Applying pattern match.pd:3164, generic-match.cc:22877 Matching expression match.pd:1894, generic-match.cc:676 Matching expression match.pd:1894, generic-match.cc:676 Applying pattern match.pd:1921, generic-match.cc:27593 etc etc etc generic_simplify() is being called with: (gdb) p code $20 = POINTER_PLUS_EXPR (gdb) p debug(_p0) (vector(8) short int *) + a_9 * 48 $21 = void (gdb) p debug(_p1) 48 $22 = void (gdb) Where a_9 has a global range of [0,0].
[Bug c++/106631] New: Unhelpful diagnostic on variable template specialization with unknown name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106631 Bug ID: 106631 Summary: Unhelpful diagnostic on variable template specialization with unknown name Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: barry.revzin at gmail dot com Target Milestone: --- Short example: template constexpr bool trait = true; template <> constexpr bool triat = false; Note the typo on triat. The current error message gcc provides is: :5:21: error: expected initializer before '<' token 5 | constexpr bool triat = false; | ^ Which is... technically true. Given that triat doesn't exist as a variable template, the next thing coming up needs to be an initializer for it, since this is really a declaration. But the intent was for it to specialize trait - it seems like it's more likely that this kind of error would come from getting the name of the variable template wrong rather than spelling the initializer incorrectly? So something like: :5:21: error: unknown variable template 'triat' being specialized 5 | constexpr bool triat = false; |^ note: did you mean trait? Would be much more helpful.
[Bug bootstrap/106624] [13 Regression] LTO plugin fails to build in parallel builds: xgcc: fatal error: cannot execute '/build/build/./prev-gcc/collect2': execv: Bad address since r13-2011-g53e3b2bf16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106624 --- Comment #6 from Martin Liška --- > Which makes some sense as I locally run GNU make with --shuffle enabled by > default: https://savannah.gnu.org/bugs/index.php?62100 Do you have a special patch on top of that? Which exact revision of the make do you use?
[Bug d/106623] internal compiler error: Segmentation fault at gimple-expr.cc:88
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106623 Iain Buclaw changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Iain Buclaw --- Fix committed.
[Bug d/106623] internal compiler error: Segmentation fault at gimple-expr.cc:88
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106623 --- Comment #2 from CVS Commits --- The releases/gcc-12 branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:dc230a0c690794cd45cc4065fa13303fd6cdfc40 commit r12-8688-gdc230a0c690794cd45cc4065fa13303fd6cdfc40 Author: Iain Buclaw Date: Mon Aug 15 17:51:03 2022 +0200 d: Fix internal compiler error: Segmentation fault at gimple-expr.cc:88 Because complex types are deprecated in the language, the new way to expose native complex types is by defining an enum with a basetype of a library-defined struct that is implicitly treated as-if it is native. As casts are not implicitly added by the front-end when downcasting from enum to its underlying type, we must insert an explicit cast during the code generation pass. PR d/106623 gcc/d/ChangeLog: * d-codegen.cc (underlying_complex_expr): New function. (d_build_call): Handle passing native complex objects as the library-defined equivalent. * d-tree.h (underlying_complex_expr): Declare. * expr.cc (ExprVisitor::visit (DotVarExp *)): Call underlying_complex_expr instead of build_vconvert. gcc/testsuite/ChangeLog: * gdc.dg/torture/pr106623.d: New test. (cherry picked from commit e206fecaac29f559f4990312b875604eb1ce3ef3)
[Bug bootstrap/106624] [13 Regression] LTO plugin fails to build in parallel builds: xgcc: fatal error: cannot execute '/build/build/./prev-gcc/collect2': execv: Bad address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106624 Martin Liška changed: What|Removed |Added Status|WAITING |ASSIGNED Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org --- Comment #5 from Martin Liška --- (In reply to Sergei Trofimovich from comment #4) > Bisected locally down to: > > 53e3b2bf16a486c15c20991c6095f7be09012b55 is the first bad commit > commit 53e3b2bf16a486c15c20991c6095f7be09012b55 > Author: Martin Liska > Date: Tue Aug 9 13:59:36 2022 +0200 > > lto: support --jobserver-style=fifo for recent GNU make > > gcc/ChangeLog: > > * opts-jobserver.h: Add one member. > * opts-common.cc (jobserver_info::jobserver_info): Parse FIFO > format of --jobserver-auth. > > gcc/opts-common.cc | 17 +++-- > gcc/opts-jobserver.h | 2 ++ > 2 files changed, 17 insertions(+), 2 deletions(-) Funny. > > Which makes some sense as I locally run GNU make with --shuffle enabled by > default: https://savannah.gnu.org/bugs/index.php?62100 Well, it's more likely caused by the fact that recent GNU make uses of the newly added fifo style for jobserver. Let me try reproducing it with the current make master. > > It should generate environment something like 'MAKEFLAGS= -j2 > --jobserver-auth=3,4 --shuffle=1660054175'.
[Bug bootstrap/106624] [13 Regression] LTO plugin fails to build in parallel builds: xgcc: fatal error: cannot execute '/build/build/./prev-gcc/collect2': execv: Bad address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106624 --- Comment #4 from Sergei Trofimovich --- Bisected locally down to: 53e3b2bf16a486c15c20991c6095f7be09012b55 is the first bad commit commit 53e3b2bf16a486c15c20991c6095f7be09012b55 Author: Martin Liska Date: Tue Aug 9 13:59:36 2022 +0200 lto: support --jobserver-style=fifo for recent GNU make gcc/ChangeLog: * opts-jobserver.h: Add one member. * opts-common.cc (jobserver_info::jobserver_info): Parse FIFO format of --jobserver-auth. gcc/opts-common.cc | 17 +++-- gcc/opts-jobserver.h | 2 ++ 2 files changed, 17 insertions(+), 2 deletions(-) Which makes some sense as I locally run GNU make with --shuffle enabled by default: https://savannah.gnu.org/bugs/index.php?62100 It should generate environment something like 'MAKEFLAGS= -j2 --jobserver-auth=3,4 --shuffle=1660054175'.
[Bug d/106623] internal compiler error: Segmentation fault at gimple-expr.cc:88
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106623 --- Comment #1 from CVS Commits --- The master branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:e206fecaac29f559f4990312b875604eb1ce3ef3 commit r13-2057-ge206fecaac29f559f4990312b875604eb1ce3ef3 Author: Iain Buclaw Date: Mon Aug 15 17:51:03 2022 +0200 d: Fix internal compiler error: Segmentation fault at gimple-expr.cc:88 Because complex types are deprecated in the language, the new way to expose native complex types is by defining an enum with a basetype of a library-defined struct that is implicitly treated as-if it is native. As casts are not implicitly added by the front-end when downcasting from enum to its underlying type, we must insert an explicit cast during the code generation pass. PR d/106623 gcc/d/ChangeLog: * d-codegen.cc (underlying_complex_expr): New function. (d_build_call): Handle passing native complex objects as the library-defined equivalent. * d-tree.h (underlying_complex_expr): Declare. * expr.cc (ExprVisitor::visit (DotVarExp *)): Call underlying_complex_expr instead of build_vconvert. gcc/testsuite/ChangeLog: * gdc.dg/torture/pr106623.d: New test.
[Bug tree-optimization/106630] [13 Regression] ICE: Segmentation fault signal terminated program cc1plus with -O2 since r13-1268-g8c99e307b20c50
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106630 --- Comment #2 from Aldy Hernandez --- Works with -fno-thread-jumps or with -fdisable-tree-dom3. I haven't investigated whether the threading done in DOM2 is generating invalid IL, but it looks like this match.pd pattern is going around in circles: /* (A * C) +- (B * C) -> (A+-B) * C and (A * C) +- A -> A * (C+-1). Modeled after fold_plusminus_mult_expr. */ (if (!TYPE_SATURATING (type) && (!FLOAT_TYPE_P (type) || flag_associative_math)) (for plusminus (plus minus) ... ...
[Bug target/106586] riscv32 still broke with zba_zbb_zbc_zbs, ICE in do_SUBST in C++ code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106586
--- Comment #9 from Andrew Pinski ---
Here is a testcase which shows a similar issue where bseti is not used (ignore
the 1<<31 being undefined/unspecified issue):
int f(int a, int b)
{
b = 31;
int tt = sizeof(b)*8 - 1;
return a | (((__typeof__(b))1) << (b & tt));
}
[Bug analyzer/106626] Improvements to wording of -Wanalyzer-out-of-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106626 --- Comment #1 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:23e8c0b0d99f585499baddda70af6a8b26f49bea commit r13-2054-g23e8c0b0d99f585499baddda70af6a8b26f49bea Author: David Malcolm Date: Mon Aug 15 14:47:03 2022 -0400 analyzer: fix direction of -Wanalyzer-out-of-bounds note [PR106626] Fix a read/write typo. Also, add more test coverage of -Wanalyzer-out-of-bounds to help establish a baseline for experiments on tweaking the wording of the warning (PR analyzer/106626). gcc/analyzer/ChangeLog: PR analyzer/106626 * region-model.cc (buffer_overread::emit): Fix copy error in direction of the access in the note. gcc/testsuite/ChangeLog: PR analyzer/106626 * gcc.dg/analyzer/out-of-bounds-read-char-arr.c: New test. * gcc.dg/analyzer/out-of-bounds-read-int-arr.c: New test. * gcc.dg/analyzer/out-of-bounds-write-char-arr.c: New test. * gcc.dg/analyzer/out-of-bounds-write-int-arr.c: New test. Signed-off-by: David Malcolm
[Bug analyzer/106573] Missing -Wanalyzer-use-of-uninitialized-value on calls handled by state machines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106573 --- Comment #4 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:ca123e019bb92fd1d6909e8da7f53a4f45922526 commit r13-2053-gca123e019bb92fd1d6909e8da7f53a4f45922526 Author: David Malcolm Date: Mon Aug 15 14:47:02 2022 -0400 analyzer: better fix for -Wanalyzer-use-of-uninitialized-value [PR106573] gcc/analyzer/ChangeLog: PR analyzer/106573 * region-model.cc (region_model::on_call_pre): Use check_call_args when ensuring that we call get_arg_svalue on all args. Remove redundant call from handling for stdio builtins. Signed-off-by: David Malcolm
[Bug tree-optimization/106621] [13 Regression] ICE in irange_set, at value-range.cc:619
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106621 Andrew Macleod changed: What|Removed |Added CC||amacleod at redhat dot com Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from Andrew Macleod --- should be fixed
[Bug tree-optimization/106630] [13 Regression] ICE: Segmentation fault signal terminated program cc1plus with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106630 Marek Polacek changed: What|Removed |Added Last reconfirmed||2022-08-15 CC||aldyh at gcc dot gnu.org, ||mpolacek at gcc dot gnu.org Priority|P3 |P1 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Marek Polacek --- Started with r13-1268-g8c99e307b20c50.
[Bug tree-optimization/106630] [13 Regression] ICE: Segmentation fault signal terminated program cc1plus with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106630 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |13.0
[Bug tree-optimization/106621] [13 Regression] ICE in irange_set, at value-range.cc:619
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106621 --- Comment #1 from CVS Commits --- The master branch has been updated by Andrew Macleod : https://gcc.gnu.org/g:265cdd067afd56293137ecb3057c5ba28a7c9480 commit r13-2052-g265cdd067afd56293137ecb3057c5ba28a7c9480 Author: Andrew MacLeod Date: Mon Aug 15 10:16:23 2022 -0400 Check for undefined and varying first. Rearrange order in irange:set to ensure all POLY_INTs map to varying. PR tree-optimization/106621 gcc/ * value-range.cc (irange::set): Check for POLY_INT_CST early. gcc/testsuite/ * gcc.dg/pr106621.c
[Bug tree-optimization/106630] New: [13 Regression] ICE: Segmentation fault signal terminated program cc1plus with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106630
Bug ID: 106630
Summary: [13 Regression] ICE: Segmentation fault signal
terminated program cc1plus with -O2
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: vsevolod.livinskiy at gmail dot com
Target Milestone: ---
Link to the Compiler Explorer: https://godbolt.org/z/1hs7ssMrd
Reproducer:
short d, e;
int f;
extern short g[][24];
char c;
void h() {
char a = 6;
c = a;
for (unsigned long a = (d || e) - 1; a < c; a += f)
for (signed b = 0; b < 24; b++)
g[a][b] = 4;
}
Error:
>$ g++ -O2 -c func.cpp
g++: internal compiler error: Segmentation fault signal terminated program
cc1plus
gcc version 13.0.0 20220815 (6624ad73064de241e937e97a28b65c50fe14c78e)
[Bug analyzer/106551] [13 Regression] dup2 causes -fanalyzer ICE in valid_to_unchecked_state, at analyzer/sm-fd.cc:751
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106551 --- Comment #7 from Immad Mir --- (In reply to CVS Commits from comment #6) The patch was lightly tested on x86_64 Linux.
[Bug analyzer/106551] [13 Regression] dup2 causes -fanalyzer ICE in valid_to_unchecked_state, at analyzer/sm-fd.cc:751
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106551 --- Comment #6 from CVS Commits --- The master branch has been updated by Immad Mir : https://gcc.gnu.org/g:ed7e7620188dc0e653815bdd40d8802bd5446638 commit r13-2051-ged7e7620188dc0e653815bdd40d8802bd5446638 Author: Immad Mir Date: Mon Aug 15 22:21:27 2022 +0530 analyzer: fix for ICE in sm-fd.cc [PR106551] This patch fixes the ICE caused by valid_to_unchecked_state in sm-fd.cc by exiting early if first argument of any "dup" functions is invalid. gcc/analyzer/ChangeLog: PR analyzer/106551 * sm-fd.cc (check_for_dup): exit early if first argument is invalid for all dup functions. gcc/testsuite/ChangeLog: PR analyzer/106551 * gcc.dg/analyzer/fd-dup-1.c: New testcase. Signed-off-by: Immad Mir
[Bug c++/106629] GCC accepts invalid program involving {1,2,3,4} as template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106629 --- Comment #4 from Andrew Pinski --- (In reply to Marek Polacek from comment #3) > Not a bug, this is > https://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#2450 I > implemented in GCC. Oh I see, I should have looked into the active defect reports too :). Even though cppreference is not part of the C++ standard. It would be useful to put a reference to that defect report on https://en.cppreference.com/w/cpp/language/template_parameters .
[Bug tree-optimization/98954] ((X << CST0) & CST1) == 0 is not optimized to 0 == (X & (CST1 >> CST0))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98954 --- Comment #7 from CVS Commits --- The master branch has been updated by Roger Sayle : https://gcc.gnu.org/g:418b71c0d535bf91df78bad2e198c57934682eaa commit r13-2048-g418b71c0d535bf91df78bad2e198c57934682eaa Author: Roger Sayle Date: Mon Aug 15 17:39:47 2022 +0100 PR tree-optimization/64992: (B << 2) != 0 is B when B is Boolean. This patch resolves both PR tree-optimization/64992 and PR tree-optimization/98956 which are missed optimization enhancement request, for which Andrew Pinski already has a proposed solution (related to a fix for PR tree-optimization/98954). Yesterday, I proposed an alternate improved patch for PR98954, which although superior in most respects, alas didn't address this case [which doesn't include a BIT_AND_EXPR], hence this follow-up fix. For many functions, F(B), of a (zero-one) Boolean value B, the expression F(B) != 0 can often be simplified to just B. Hence "(B * 5) != 0" is B, "-B != 0" is B, "bswap(B) != 0" is B, "(B >>r 3) != 0" is B. These are all currently optimized by GCC, with the strange exception of left shifts by a constant (possibly due to the undefined/implementation defined behaviour when the shift constant is larger than the first operand's precision). This patch adds support for this particular case, when the shift constant is valid. 2022-08-15 Roger Sayle gcc/ChangeLog PR tree-optimization/64992 PR tree-optimization/98956 * match.pd (ne (lshift @0 @1) 0): Simplify (X << C) != 0 to X when X is zero_one_valued_p and the shift constant C is valid. (eq (lshift @0 @1) 0): Likewise, simplify (X << C) == 0 to !X when X is zero_one_valued_p and the shift constant C is valid. gcc/testsuite/ChangeLog PR tree-optimization/64992 * gcc.dg/pr64992.c: New test case.
[Bug tree-optimization/98956] Failure to optimize out boolean left shift
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98956 --- Comment #5 from CVS Commits --- The master branch has been updated by Roger Sayle : https://gcc.gnu.org/g:418b71c0d535bf91df78bad2e198c57934682eaa commit r13-2048-g418b71c0d535bf91df78bad2e198c57934682eaa Author: Roger Sayle Date: Mon Aug 15 17:39:47 2022 +0100 PR tree-optimization/64992: (B << 2) != 0 is B when B is Boolean. This patch resolves both PR tree-optimization/64992 and PR tree-optimization/98956 which are missed optimization enhancement request, for which Andrew Pinski already has a proposed solution (related to a fix for PR tree-optimization/98954). Yesterday, I proposed an alternate improved patch for PR98954, which although superior in most respects, alas didn't address this case [which doesn't include a BIT_AND_EXPR], hence this follow-up fix. For many functions, F(B), of a (zero-one) Boolean value B, the expression F(B) != 0 can often be simplified to just B. Hence "(B * 5) != 0" is B, "-B != 0" is B, "bswap(B) != 0" is B, "(B >>r 3) != 0" is B. These are all currently optimized by GCC, with the strange exception of left shifts by a constant (possibly due to the undefined/implementation defined behaviour when the shift constant is larger than the first operand's precision). This patch adds support for this particular case, when the shift constant is valid. 2022-08-15 Roger Sayle gcc/ChangeLog PR tree-optimization/64992 PR tree-optimization/98956 * match.pd (ne (lshift @0 @1) 0): Simplify (X << C) != 0 to X when X is zero_one_valued_p and the shift constant C is valid. (eq (lshift @0 @1) 0): Likewise, simplify (X << C) == 0 to !X when X is zero_one_valued_p and the shift constant C is valid. gcc/testsuite/ChangeLog PR tree-optimization/64992 * gcc.dg/pr64992.c: New test case.
[Bug tree-optimization/64992] More optimize opportunity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64992 --- Comment #12 from CVS Commits --- The master branch has been updated by Roger Sayle : https://gcc.gnu.org/g:418b71c0d535bf91df78bad2e198c57934682eaa commit r13-2048-g418b71c0d535bf91df78bad2e198c57934682eaa Author: Roger Sayle Date: Mon Aug 15 17:39:47 2022 +0100 PR tree-optimization/64992: (B << 2) != 0 is B when B is Boolean. This patch resolves both PR tree-optimization/64992 and PR tree-optimization/98956 which are missed optimization enhancement request, for which Andrew Pinski already has a proposed solution (related to a fix for PR tree-optimization/98954). Yesterday, I proposed an alternate improved patch for PR98954, which although superior in most respects, alas didn't address this case [which doesn't include a BIT_AND_EXPR], hence this follow-up fix. For many functions, F(B), of a (zero-one) Boolean value B, the expression F(B) != 0 can often be simplified to just B. Hence "(B * 5) != 0" is B, "-B != 0" is B, "bswap(B) != 0" is B, "(B >>r 3) != 0" is B. These are all currently optimized by GCC, with the strange exception of left shifts by a constant (possibly due to the undefined/implementation defined behaviour when the shift constant is larger than the first operand's precision). This patch adds support for this particular case, when the shift constant is valid. 2022-08-15 Roger Sayle gcc/ChangeLog PR tree-optimization/64992 PR tree-optimization/98956 * match.pd (ne (lshift @0 @1) 0): Simplify (X << C) != 0 to X when X is zero_one_valued_p and the shift constant C is valid. (eq (lshift @0 @1) 0): Likewise, simplify (X << C) == 0 to !X when X is zero_one_valued_p and the shift constant C is valid. gcc/testsuite/ChangeLog PR tree-optimization/64992 * gcc.dg/pr64992.c: New test case.
[Bug c++/106629] GCC accepts invalid program involving {1,2,3,4} as template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106629 Marek Polacek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID CC||mpolacek at gcc dot gnu.org --- Comment #3 from Marek Polacek --- Not a bug, this is https://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#2450 I implemented in GCC.
[Bug tree-optimization/71343] missed optimization (can't "prove" shift and multiplication equivalence)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71343 --- Comment #3 from CVS Commits --- The master branch has been updated by Roger Sayle : https://gcc.gnu.org/g:03acd8b6429e22068330dce5abf129291d3f26de commit r13-2047-g03acd8b6429e22068330dce5abf129291d3f26de Author: Roger Sayle Date: Mon Aug 15 17:32:26 2022 +0100 PR tree-optimization/71343: Optimize (X< Richard Biener gcc/ChangeLog PR tree-optimization/71343 * match.pd (op (lshift @0 @1) (lshift @2 @1)): Optimize the expression (X<>C)^(Y>>C) to (X^Y)>>C for binary logical operators, AND, IOR and XOR. gcc/testsuite/ChangeLog PR tree-optimization/71343 * gcc.dg/pr71343-1.c: New test case.
[Bug c++/106629] GCC accepts invalid program involving {1,2,3,4} as template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106629
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Last reconfirmed||2022-08-15
Keywords||accepts-invalid
--- Comment #2 from Andrew Pinski ---
>The program is invalid because `{1,2,3,4}` cannot be a template argument.
This is because braced-init-list is not included in constant-expression .
[Bug c++/106629] GCC accepts invalid program involving {1,2,3,4} as template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106629 --- Comment #1 from Andrew Pinski --- Created attachment 53462 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53462=edit full testcase
[Bug c++/106629] New: GCC accepts invalid program involving {1,2,3,4} as template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106629
Bug ID: 106629
Summary: GCC accepts invalid program involving {1,2,3,4} as
template argument
Product: gcc
Version: 12.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jlame646 at gmail dot com
Target Milestone: ---
The following invalid program is accepted by gcc.
https://godbolt.org/z/Mb3qbvvPz
```
struct Impl
{
constexpr Impl(std::initializer_list)
{
}
};
struct Bar{};
template
struct Foo
{
};
int main()
{
constexpr Foo foo; //works in msvc & gcc but rejected in
clang
return 0;
}
```
The program is invalid because `{1,2,3,4}` cannot be a template argument.
[Bug c/106628] Missed folding with COMPOUND_EXPR due to C frontend bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106628 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2022-08-15 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Keywords||diagnostic, ||missed-optimization --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug c++/106618] C++ Option Summary shows `-fargs-in-order` instead of `-fstrong-eval-order`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106618
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2022-08-15
Summary|[docs] Option Summary shows |C++ Option Summary shows
|`-fargs-in-order` instead |`-fargs-in-order` instead
|of `-fstrong-eval-order`|of `-fstrong-eval-order`
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Version|unknown |13.0
--- Comment #1 from Andrew Pinski ---
Confirmed.
Something like this:
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index fd7edd1938d..fd719b7b2d4 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -212,7 +212,7 @@ in the following sections.
@item C++ Language Options
@xref{C++ Dialect Options,,Options Controlling C++ Dialect}.
@gccoptlist{-fabi-version=@var{n} -fno-access-control @gol
--faligned-new=@var{n} -fargs-in-order=@var{n} -fchar8_t -fcheck-new @gol
+-faligned-new=@var{n} -fchar8_t -fcheck-new @gol
-fconstexpr-depth=@var{n} -fconstexpr-cache-depth=@var{n} @gol
-fconstexpr-loop-limit=@var{n} -fconstexpr-ops-limit=@var{n} @gol
-fno-elide-constructors @gol
@@ -243,6 +243,7 @@ in the following sections.
-flang-info-include-translate@r{[}=@var{header}@r{]} @gol
-flang-info-include-translate-not @gol
-flang-info-module-cmi@r{[}=@var{module}@r{]} @gol
+-fstrong-eval-order @gol
-stdlib=@var{libstdc++,libc++} @gol
-Wabi-tag -Wcatch-value -Wcatch-value=@var{n} @gol
-Wno-class-conversion -Wclass-memaccess @gol
[Bug target/106609] [SH] miscompilation of loop involving noreturn call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106609 Andrew Pinski changed: What|Removed |Added Component|rtl-optimization|target --- Comment #3 from Andrew Pinski --- > -fdump-rtl-mach is the first stage where the comparison to 0 is gone Then this is a target specific issue until provided otherwise. mach stands for machine (target) specific pass.
[Bug analyzer/106620] Incorrectly thinks execution can continue after a return statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106620 --- Comment #2 from David Malcolm --- (In reply to David Malcolm from comment #1) > I've made lots of implementation changes to -fanalyzer in gcc 12 in beyond "and beyond", I meant to say
[Bug analyzer/106620] Incorrectly thinks execution can continue after a return statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106620 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #1 from David Malcolm --- Thanks for filing this. Looking at the Compiler Explorer link, the false positive occurs with gcc 11.1 at -O3. With gcc 11.1 and gcc 11.3 the false +ve occurs at -O1 and above. With gcc 12.1 and trunk, the false +ve does not occur. I've made lots of implementation changes to -fanalyzer in gcc 12 in beyond that I don't intend to backport to gcc 11, so I'm going to mark this as resolved with "WORKSFORME". Feel free to reopen it if you're able to reproduce it with gcc 12 or later; thanks again for filing this.
[Bug c++/106627] Exception from multiversion function cannot be caught
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106627
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2022-08-15
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
--- Comment #1 from Andrew Pinski ---
Confirmed, not a regression.
Using a wrapper function does not fully work either, you need to mark the
function as noipa (I suspect the new function for f is being marked as nonthrow
for some reason):
__attribute__((target("default")))
void f() {
throw 1;
}
__attribute__((target("sse4.2")))
void f() {
throw 2;
}
[[gnu::noipa]]
void f1()
{
f();
}
int main()
{
try {
f1();
}
catch(... )
{
return 0;
}
return 1;
}
[Bug c++/106276] Missing -Wpessimizing-move warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106276 Marek Polacek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from Marek Polacek --- Done for GCC 13.
[Bug c++/106276] Missing -Wpessimizing-move warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106276
--- Comment #6 from CVS Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:ae3459cd5956fcd29e8aa5408efb707cb7d9b14f
commit r13-2045-gae3459cd5956fcd29e8aa5408efb707cb7d9b14f
Author: Marek Polacek
Date: Fri Jul 22 18:10:30 2022 -0400
c++: Extend -Wpessimizing-move for class prvalues [PR106276]
We already have a warning that warns about pessimizing std::move
in a return statement, when it prevents the NRVO:
T fn()
{
T t;
return std::move (t); // warning \o/
}
However, the warning doesn't warn when what we are returning is a class
prvalue, that is, when std::move prevents the RVO:
T fn()
{
T t;
return std::move (T{}); // no warning :-(
}
This came up recently in GCC:
.
This patch fixes that. I would like to extend the warning further, so
that it warns in more contexts, e.g.:
T t = std::move(T());
or
void foo (T);
foo (std::move(T()));
PR c++/106276
gcc/cp/ChangeLog:
* typeck.cc (can_do_rvo_p): New.
(maybe_warn_pessimizing_move): Warn when moving a temporary object
in a return statement prevents copy elision.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/Wpessimizing-move7.C: New test.
[Bug ipa/101839] [10/11/12 Regression] Hang in C++ code with -fdevirtualize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101839 --- Comment #12 from Martin Liška --- (In reply to Jan Hubicka from comment #11) > Fixed on mainline with r:0f2c7ccd14a29a8af8318f50b8296098fb0ab218 g:0f2c7ccd14a29a8af8318f50b8296098fb0ab218
[Bug c/106628] New: Missed folding with COMPOUND_EXPR due to C frontend bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106628 Bug ID: 106628 Summary: Missed folding with COMPOUND_EXPR due to C frontend bugs Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org Target Milestone: --- Doing diff --git a/gcc/fold-const.cc b/gcc/fold-const.cc index 4f4ec81c8d4..698f115507a 100644 --- a/gcc/fold-const.cc +++ b/gcc/fold-const.cc @@ -12595,14 +12595,9 @@ fold_binary_loc (location_t loc, enum tree_code code, tree type, return NULL_TREE; case COMPOUND_EXPR: - /* When pedantic, a compound expression can be neither an lvalue -nor an integer constant expression. */ - if (TREE_SIDE_EFFECTS (arg0) || TREE_CONSTANT (arg1)) + if (TREE_SIDE_EFFECTS (arg0)) return NULL_TREE; - /* Don't let (0, 0) be null pointer constant. */ - tem = integer_zerop (arg1) ? build1_loc (loc, NOP_EXPR, type, arg1) -: fold_convert_loc (loc, type, arg1); - return tem; + return op1; case ASSERT_EXPR: /* An ASSERT_EXPR should never be passed to fold_binary. */ results in missed diagnostics: FAIL: gcc.dg/array-5.c bad vla handling (test for bogus messages, line 40) FAIL: gcc.dg/c99-const-expr-12.c (test for excess errors) FAIL: gcc.dg/pr61096-1.c (test for errors, line 29) FAIL: gcc.dg/pr61096-1.c (test for excess errors)
[Bug sanitizer/106591] ASan at -O1 fails to detect a global buffer overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106591 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2022-08-15 Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Is it the same problem as PR106558?
[Bug bootstrap/106624] [13 Regression] LTO plugin fails to build in parallel builds: xgcc: fatal error: cannot execute '/build/build/./prev-gcc/collect2': execv: Bad address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106624 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING Last reconfirmed||2022-08-15 --- Comment #3 from Martin Liška --- Works for me (with system dependencies), tries for g:e236d671d460dd47262accdea2e9d1d80820ae88.
[Bug bootstrap/106624] [13 Regression] LTO plugin fails to build in parallel builds: xgcc: fatal error: cannot execute '/build/build/./prev-gcc/collect2': execv: Bad address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106624 --- Comment #2 from Sergei Trofimovich --- Used configure options: configure flags: --prefix=/nix/store/fx45rjgwi61c5xx6xyxz9lih1bkyv374-gfortran-13.0.0 --with-gmp-include=/nix/store/gyr707p3ac6ss8pcmf14g0hx041vj9xf-gmp-with-cxx-stage3-6.2.1-dev/include --with-gmp-lib=/nix/store/lcnnbhzzvknkfnlm5qh89xn4in9jm035-gmp-with-cxx-stage3-6.2.1/lib --with-mpfr-include=/nix/store/nfxamp6dnv1jhydhjndnln3maixsw22d-mpfr-stage3-4.1.0-dev/include --with-mpfr-lib=/nix/store/gwrfldp0x95sgsd6kqi2ms52kp68qrk7-mpfr-stage3-4.1.0/lib --with-mpc=/nix/store/3m2bgmj266d857m3x4sfzcbx0rpsqyfd-libmpc-stage3-1.2.1 --with-libelf=/nix/store/7gv2c6bfr8gzzikkp04l5py3yd6w5w13-libelf-0.8.13 --with-native-system-header-dir=/nix/store/q7l8qdpbvm594q4ayf4xr8wfqknc0nmg-glibc-2.35-163-dev/include --with-build-sysroot=/ --program-prefix= --enable-lto --disable-libstdcxx-pch --without-included-gettext --with-system-zlib --enable-checking=release --enable-static --enable-languages=fortran --disable-multilib --enable-plugin --with-isl=/nix/store/vcik6gi61dpw72ygd7lqv8g074m5p4cw-isl-stage3-0.20 --build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu --target=x86_64-unknown-linux-gnu
[Bug target/106355] Linux s390x -O2 argument passing miscompile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106355 --- Comment #4 from Stefan Schulze Frielinghaus --- The problem is with sibling call optimization where parameters with BLKmode are not handled correctly. I will prepare a patch and submit it shortly.
[Bug c++/106627] New: Exception from multiversion function cannot be caught
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106627
Bug ID: 106627
Summary: Exception from multiversion function cannot be caught
Product: gcc
Version: 12.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc.gnu at vvalter dot com
Target Milestone: ---
An exception thrown by a multiversioned function cannot be caught in the called
function. I expect the following program to exit with status code 0, but it
gets terminated because of an uncaught exception. With clang, the program works
as expected. According to godbolt.org it's also broken in gcc trunk and all
other versions that I checked: https://godbolt.org/z/564c6q8xo
__attribute__((target("default")))
void f() {
throw 1;
}
__attribute__((target("sse4.2,bmi")))
void f() {
throw 2;
}
int main()
{
try {
f();
}
catch(... )
{
return 0;
}
return 1;
}
Output of g++ -v:
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/12/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,fortran,objc,obj-c++,ada,go,d,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-gcc-major-version-only --enable-libstdcxx-backtrace
--with-linker-hash-style=gnu --enable-plugin --enable-initfini-array
--with-isl=/builddir/build/BUILD/gcc-12.1.1-20220507/obj-x86_64-redhat-linux/isl-install
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-offload-defaulted --enable-gnu-indirect-function --enable-cet
--with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
--with-build-config=bootstrap-lto --enable-link-serialization=1
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.1.1 20220507 (Red Hat 12.1.1-1) (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-shared-libgcc' '-mtune=generic'
'-march=x86-64' '-dumpdir' 'a-'
/usr/libexec/gcc/x86_64-redhat-linux/12/cc1plus -E -quiet -v -D_GNU_SOURCE
bug.cpp -mtune=generic -march=x86-64 -fpch-preprocess -o a-bug.ii
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-redhat-linux/12/include-fixed"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-redhat-linux/12/../../../../x86_64-redhat-linux/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12
/usr/lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/x86_64-redhat-linux
/usr/lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/backward
/usr/lib/gcc/x86_64-redhat-linux/12/include
/usr/local/include
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-shared-libgcc' '-mtune=generic'
'-march=x86-64' '-dumpdir' 'a-'
/usr/libexec/gcc/x86_64-redhat-linux/12/cc1plus -fpreprocessed a-bug.ii -quiet
-dumpdir a- -dumpbase bug.cpp -dumpbase-ext .cpp -mtune=generic -march=x86-64
-version -o a-bug.s
GNU C++17 (GCC) version 12.1.1 20220507 (Red Hat 12.1.1-1)
(x86_64-redhat-linux)
compiled by GNU C version 12.1.1 20220507 (Red Hat 12.1.1-1), GMP
version 6.2.1, MPFR version 4.1.0-p13, MPC version 1.2.1, isl version
isl-0.18-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++17 (GCC) version 12.1.1 20220507 (Red Hat 12.1.1-1)
(x86_64-redhat-linux)
compiled by GNU C version 12.1.1 20220507 (Red Hat 12.1.1-1), GMP
version 6.2.1, MPFR version 4.1.0-p13, MPC version 1.2.1, isl version
isl-0.18-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 2b1c93ff5f3b69a44b0e1b07f6437558
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-shared-libgcc' '-mtune=generic'
'-march=x86-64' '-dumpdir' 'a-'
as -v --64 -o a-bug.o a-bug.s
GNU assembler version 2.37 (x86_64-redhat-linux) using BFD version version
2.37-27.fc36
COMPILER_PATH=/usr/libexec/gcc/x86_64-redhat-linux/12/:/usr/libexec/gcc/x86_64-redhat-linux/12/:/usr/libexec/gcc/x86_64-redhat-linux/:/usr/lib/gcc/x86_64-redhat-linux/12/:/usr/lib/gcc/x86_64-redhat-linux/
LIBRARY_PATH=/usr/lib/gcc/x86_64-redhat-linux/12/:/usr/lib/gcc/x86_64-redhat-linux/12/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/usr/lib/gcc/x86_64-redhat-linux/12/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-shared-libgcc' '-mtune=generic'
'-march=x86-64' '-dumpdir' 'a.'
/usr/libexec/gcc/x86_64-redhat-linux/12/collect2 -plugin
/usr/libexec/gcc/x86_64-redhat-linux/12/liblto_plugin.so
[Bug analyzer/106626] New: Improvements to wording of -Wanalyzer-out-of-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106626
Bug ID: 106626
Summary: Improvements to wording of -Wanalyzer-out-of-bounds
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
CC: tlange at gcc dot gnu.org
Target Milestone: ---
During the patch review of -Wanalyzer-out-of-bounds we decided to focus on
getting the feature implemented in trunk first, and defer coming up with the
precise wording, to avoid holding up the feature.
I'm filing this bug to track coming up with the precise wording for
-Wanalyzer-out-of-bounds.
Current status quo:
Given e.g.:
int arr[10];
int
test (void)
{
return arr[10];
}
https://godbolt.org/z/EPrqGTj8s
we report:
: In function 'test':
:6:15: warning: buffer overread [CWE-126] [-Wanalyzer-out-of-bounds]
6 | return arr[10];
|~~~^~~~
event 1
|
|1 | int arr[10];
| | ^~~
| | |
| | (1) capacity is 40 bytes
|
+--> 'test': events 2-3
|
|4 | test (void)
| | ^~~~
| | |
| | (2) entry to 'test'
|5 | {
|6 | return arr[10];
| |~~~
| | |
| | (3) out-of-bounds read from byte 40 till byte
43 but 'arr' ends at byte 40
|
:6:15: note: write is 4 bytes past the end of 'arr'
6 | return arr[10];
|~~~^~~~
The note erroneously says "write" due to a copy which I plan to fix
shortly.
Goals:
I'd like the diagnostics to (somehow) convey the following information to the
user:
* what was the expression (if available) responsible for the bad access, since
we can't always underline exactly the problematic subexpression in a compound
expression (or macros could be involved, obscuring the user's view of what the
analyzer is "seeing"). e.g. in the above example 'arr[10]'
* direction of the access: read vs write? e.g. in the above example: read
* boundary being violated: is the access before or after the buffer? e.g. in
the above example: after the buffer
,* location: where is the invalid access? heap vs stack vs elsewhere (since
this can affect the impact of a vulnerability): e.g. in the above example:
stack
* magnitude: how far beyond the boundary is the invalid access (consider e.g.
the cases of immediately beyond ("off-by-one"), vs near (a few bytes or
elements), vs far); e.g. in the above example: 0-3 bytes beyond the boundary, 0
elements beyond when expressed as array index
* data size: how much data beyond the boundary is accessed; e.g. in the above
example 4 bytes, or 1 element.
Doing so is likely to avoid a combinatorial explosion (due to the need for
i18n), so to tame this, some of this may need to be split between different
parts of the diagnostic (the initial warning, events in the warning's
diagnostic path, and any notes after the warning).
The above list is taken in part from the the Bug Framework's deprecated Buffer
Overflow (BOF) Class:
https://samate.nist.gov/BF/Old/BOFClass.html
I'm not sure why the Bug Framework deprecated "BOF" (presumably in favor of the
"BF Memory Model",
https://samate.nist.gov/BF/Classes/MEM/MEMModel.html
and its "Memory Use Bugs (MUS) Class":
https://samate.nist.gov/BF/Classes/MEM/MUS.html
), but the BOF attributes seem to me to be pertinent information for the user,
and good things to think about in test cases.
Currently -Wanalyzer-out-of-bounds only warns when the size and offset of the
access are constant (not symbolic), and the capacity of the underlying region
is constant (not symbolic). I'd like to eventually generalize that (see PR
106625), so ideally whatever scheme we come up with should support that.
Ideally these should be reported in terms of the user's source code. In the
above example, the messages talk about bytes, but we should probably *also*
talk about array indices (e.g. that indices 0 through 9 are valid, and 10 is
one beyond).
The wording should also be clear about inclusive vs exclusive ranges - I feel
'arr' ends at byte 40"
is unclear. Perhaps something like:
'arr' has 10 elements, so valid indices are '[0]' to '[9]' (bytes 0-39)
or somesuch.
I'm not sure what a correct solution here is, but am filing this now to try to
capture the things we might try to design for.
Tim: I'm CCing you in case you want to work on this; otherwise I'd like to have
a go at this in a few weeks.
[Bug target/106355] Linux s390x -O2 argument passing miscompile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106355 Dan Horák changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Dan Horák --- adding Jakub as this affect Fedora ...
[Bug analyzer/106625] RFE: support some symbolic values in -Wanalyzer-out-of-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106625 David Malcolm changed: What|Removed |Added CC||tlange at gcc dot gnu.org --- Comment #1 from David Malcolm --- Tim: I'm CCing you in case you want to work on this; otherwise I might tackle this in a few weeks.
[Bug analyzer/106625] New: RFE: support some symbolic values in -Wanalyzer-out-of-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106625
Bug ID: 106625
Summary: RFE: support some symbolic values in
-Wanalyzer-out-of-bounds
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
Currently -Wanalyzer-out-of-bounds only warns when:
* the size of the memory access is constant, rather than symbolic, and
* the capacity of the underlying memory region being accessed is constant,
rather than symbolic, and
* the offset of the memory access is constant, rather than symbolic
I'd like to eventually generalize the warning so that it can "do something
sensible" when at least some of the above are symbolic - for some meaning of
"something sensible". I'm not quite sure what subset we can support, but
-Wanalyzer-out-of-bounds should probably continue to restrict itself to
"definitely out-of-bounds" cases.
For example, consider the classic mistake in C of confusing the size vs length
of a 0-terminated string:
char *
test_concat (const char *x, const char *y)
{
size_t len_x = __builtin_strlen (x);
size_t len_y = __builtin_strlen (y);
size_t sz = len_x + len_y; // BUG (root cause): forgot to add 1 for
terminator;
char *result = __builtin_malloc (sz);
if (!result)
return NULL;
__builtin_memcpy (result, x, len_x);
__builtin_memcpy (result + len_x, y, len_y);
result[len_x + len_y] = '\0'; // BUG (symptom): off-by-one out-of-bounds
write to heap
return result;
}
Currently -Wanalyzer-out-of-bounds doesn't warn for this; it would be great if
void region_model::check_region_bounds could handle this. Specifically, in
this case, although the size of the access:
result[len_x + len_y] = '\0';
is constant (1 byte), the offset of the access is symbolic (len_x + len_y), and
the capacity of "result" is symbolic. That said the symbolic offset of the
access and symbolic capacity of the base region are directly related, and the
former is definitely wrong with respect to the latter.
[Bug target/81708] The x86 stack canary location should be customizable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81708 --- Comment #19 from CVS Commits --- The master branch has been updated by Alexandre Oliva : https://gcc.gnu.org/g:4ad200addc3eaf55fba6cc91db3d3b66eabaf3d0 commit r13-2043-g4ad200addc3eaf55fba6cc91db3d3b66eabaf3d0 Author: Alexandre Oliva Date: Mon Aug 15 09:21:33 2022 -0300 i386 PIE: testsuite: cope with default pie on ia32 This patch continues the effort of cleaning up the testsuite for --enable-default-pie; the focus herein is mostly 32-bit x86. As much as I tried to avoid it, most of the changes to the testsuite simply disable PIC/PIE, for reasons I'm going to detail below. static-cdtor1.C gets new patterns to match PIE output. Some avx512fp16 tests change only in register allocation, because of the register used to hold the GOT base address. Interrupt tests changed in this regard as well, but here it also affected register saving and restoring. The previous patch modified cet-sjlj tests, mentioning a single regexp covering PIC and nonPIC got incorrect match counts. I found out that adding ?: to parenthesized subpatterns avoids miscounting matches. Other tests that count certain kinds of insns needed adjustment over insns in get_pc_thunk, extra loads from the GOT, or extra adds to compute addresses. In one case, namely stack-check-12, it is nonPIC that had extra insns, that PIC gets rid of, or rather, pushing and popping the PIC register obviates the dummy push and matching pop used for stack probing in nonpic. pr95126 tests were supposed to optimize loads into known constants, but the @GOTOFF addresses prevent that for reasons I have not investigated, but that would be clearly desirable, so I've XFAILed these. pr95852 is another case of missed optimization: sibcalls are not possible when the PIC register needs to be set up for the call, which prevents the expected constant propagation to the return block; I have adjusted the codegen expectations of these tests. As for tests that disable PIE... Some are judgment calls, that fail for similar reasons as tests described above, but I chose not to adjust their expectations; others are just not possible with PIC, or not worth the effort of adjusting. anon[14].C check for no global or comdat symbols, respectively, but -fPIE outputs get_pc_thunk, as global hidden comdat. initlist-const1.C wants .rodata and checks for no .data, but PIC outputs constant data that needs relocations in .data.rel.ro.local. no-stack-protector-attr-3.C and stackprotectexplicit2.C count stack_check_fail matches; -fPIE calls stack_check_fail_local instead, which matches the pattern, but this symbol is also marked as .hidden, so the match count needs to be adjusted. pr71694.C checks for no movl, but get_pc_thunk contains one. pr102892-1.c is a missed optimization, ivopts creates an induction variable because the array address can't be part of an indexing base address with PIE, and that ends up stopping a load from being resolved to a constant as expected. sibcall-11.c needs @PLT for the call, which requires the PIC register, which makes sibcalling impossible. builtin-self.c, in turn, expects no calls, but PIC calls get_pc_thunk. avx* vector tests that had PIE disabled were affected in that the need for GOT-based addressing modes changed instruction selection in ways that deviated from the expectations of the tests. Ditto other vector tests: pr100865*, pr101796-1, pr101846, pr101989-broadcast-1, and pr102021, pr54855-[37], and pr90773-17. pr15184* tests need a PIC register to access global variables, which affects register allocation, so the patterns would have to be adjusted. pr27971 can't use the expected addressing mode to dereference the array with PIC, so it ends up selecting an indexed addressing mode, obviating the expected separate shift insn. pr70263-2 is another case that implicitly expects a sibcall, impossible because of the need for the PIC register; without a sibcall, the expected REG_EQUIV for the reuse of the stack slot of an incoming argument does not occur. pr78035 duplicates the final compare in both then and else blocks with PIE, which deviates from the expected cmp count. pr81736-[57] test for no frame pointer, but the PIC register assignment to a call-saved register forces a frame; the former ends up not using the PIC register, but it's only optimized out after committing to a stack frame to preserve it. pr85620-6 also expects a tail call in a situation that is impossible on ia32 PIC. pr85667-6 doesn't expect the movl in get_pc_thunk. pr93492-5 tests -mfentry, not available with PIC on ia32. pr96539 expects a tail-call, to avoid copying a large-ish struct argument, but the call requires the PIC register, so no
[Bug bootstrap/106624] [13 Regression] LTO plugin fails to build in parallel builds: xgcc: fatal error: cannot execute '/build/build/./prev-gcc/collect2': execv: Bad address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106624 --- Comment #1 from Sergei Trofimovich --- Created attachment 53461 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53461=edit good.log.xz
[Bug bootstrap/106624] New: [13 Regression] LTO plugin fails to build in parallel builds: xgcc: fatal error: cannot execute '/build/build/./prev-gcc/collect2': execv: Bad address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106624 Bug ID: 106624 Summary: [13 Regression] LTO plugin fails to build in parallel builds: xgcc: fatal error: cannot execute '/build/build/./prev-gcc/collect2': execv: Bad address Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: slyfox at gcc dot gnu.org Target Milestone: --- Created attachment 53460 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53460=edit bad.log.xz This week's gcc snapshot fails bootstrap builds in parallel mode surprisingly frequently. The symptom is the same: build fails while .libs/liblto_plugin.so is being linked. I attached successful good.log.xz (-j1) and failing bad.log.xz (-j16) builds. Can you help me understand why it fails? Failure snippet is: checking for fgets_unlocked... /nix/store/i3ibpx67yncp4w4mpkf5pwvjjsd0aqln-bootstrap-tools/bin/bash ./libtool --tag=CC --tag=disable-static --mode=link /build/build/./prev-gcc/xgcc -B/build/build/./prev-gcc/ -B/nix/store/v06bn3lc2s0yjci9px8l829mbks695fm-gfortran-13.0.0/x86_64-unknown-linux-gnu/bin/ -O2 -I/nix/store/q7l8qdpbvm594q4ayf4xr8wfqknc0nmg-glibc-2.35-163-dev/include -B/nix/store/z1as323dfsk12agzlp9ia35p5801isd7-glibc-2.35-163/lib/ -idirafter /nix/store/q7l8qdpbvm594q4ayf4xr8wfqknc0nmg-glibc-2.35-163-dev/include -idirafter /nix/store/i3ibpx67yncp4w4mpkf5pwvjjsd0aqln-bootstrap-tools/lib/gcc/x86_64-unknown-linux-gnu/8.3.0/include-fixed -Wl,-rpath,/nix/store/m3wi1gn0309l15zrha95yv9mw39972db-gfortran-13.0.0-lib/lib -Wl,-L/nix/store/z1as323dfsk12agzlp9ia35p5801isd7-glibc-2.35-163/lib -Wl,-rpath -Wl,/nix/store/z1as323dfsk12agzlp9ia35p5801isd7-glibc-2.35-163/lib -Wl,-dynamic-linker=/nix/store/z1as323dfsk12agzlp9ia35p5801isd7-glibc-2.35-163/lib/ld-linux-x86-64.so.2 --sysroot=/ -fno-checking -Wall -fcf-protection -DBASE_VERSION='"13.0.0"' -O2 -I/nix/store/q7l8qdpbvm594q4ayf4xr8wfqknc0nmg-glibc-2.35-163-dev/include -B/nix/store/z1as323dfsk12agzlp9ia35p5801isd7-glibc-2.35-163/lib/ -idirafter /nix/store/q7l8qdpbvm594q4ayf4xr8wfqknc0nmg-glibc-2.35-163-dev/include -idirafter /nix/store/i3ibpx67yncp4w4mpkf5pwvjjsd0aqln-bootstrap-tools/lib/gcc/x86_64-unknown-linux-gnu/8.3.0/include-fixed -Wl,-rpath,/nix/store/m3wi1gn0309l15zrha95yv9mw39972db-gfortran-13.0.0-lib/lib -Wl,-L/nix/store/z1as323dfsk12agzlp9ia35p5801isd7-glibc-2.35-163/lib -Wl,-rpath -Wl,/nix/store/z1as323dfsk12agzlp9ia35p5801isd7-glibc-2.35-163/lib -Wl,-dynamic-linker=/nix/store/z1as323dfsk12agzlp9ia35p5801isd7-glibc-2.35-163/lib/ld-linux-x86-64.so.2 -fno-checking -gtoggle -Wc,-static-libgcc -pthread -module -avoid-version -bindir /nix/store/v06bn3lc2s0yjci9px8l829mbks695fm-gfortran-13.0.0/libexec/gcc/x86_64-unknown-linux-gnu/13.0.0 -Wl,--version-script=../../gcc-13-20220814/lto-plugin/lto-plugin.map -Xcompiler '-static-libstdc++' -Xcompiler '-static-libgcc' '-O2' '-I/nix/store/q7l8qdpbvm594q4ayf4xr8wfqknc0nmg-glibc-2.35-163-dev/include' -Xcompiler '-B/nix/store/z1as323dfsk12agzlp9ia35p5801isd7-glibc-2.35-163/lib/' '-idirafter' '/nix/store/q7l8qdpbvm594q4ayf4xr8wfqknc0nmg-glibc-2.35-163-dev/include' '-idirafter' '/nix/store/i3ibpx67yncp4w4mpkf5pwvjjsd0aqln-bootstrap-tools/lib/gcc/x86_64-unknown-linux-gnu/8.3.0/include-fixed' '-Wl,-rpath,/nix/store/m3wi1gn0309l15zrha95yv9mw39972db-gfortran-13.0.0-lib/lib' '-Wl,-L/nix/store/z1as323dfsk12agzlp9ia35p5801isd7-glibc-2.35-163/lib' '-Wl,-rpath' '-Wl,/nix/store/z1as323dfsk12agzlp9ia35p5801isd7-glibc-2.35-163/lib' '-Wl,-dynamic-linker=/nix/store/z1as323dfsk12agzlp9ia35p5801isd7-glibc-2.35-163/lib/ld-linux-x86-64.so.2' -o liblto_plugin.la -rpath /nix/store/v06bn3lc2s0yjci9px8l829mbks695fm-gfortran-13.0.0/libexec/gcc/x86_64-unknown-linux-gnu/13.0.0 lto-plugin.lo -Wc,../libiberty/pic/libiberty.a yes checking for fileno_unlocked... libtool: link: /build/build/./prev-gcc/xgcc -B/build/build/./prev-gcc/ -B/nix/store/v06bn3lc2s0yjci9px8l829mbks695fm-gfortran-13.0.0/x86_64-unknown-linux-gnu/bin/ -O2 -I/nix/store/q7l8qdpbvm594q4ayf4xr8wfqknc0nmg-glibc-2.35-163-dev/include -B/nix/store/z1as323dfsk12agzlp9ia35p5801isd7-glibc-2.35-163/lib/ -idirafter /nix/store/q7l8qdpbvm594q4ayf4xr8wfqknc0nmg-glibc-2.35-163-dev/include -idirafter /nix/store/i3ibpx67yncp4w4mpkf5pwvjjsd0aqln-bootstrap-tools/lib/gcc/x86_64-unknown-linux-gnu/8.3.0/include-fixed -Wl,-rpath,/nix/store/m3wi1gn0309l15zrha95yv9mw39972db-gfortran-13.0.0-lib/lib -Wl,-L/nix/store/z1as323dfsk12agzlp9ia35p5801isd7-glibc-2.35-163/lib -Wl,-rpath -Wl,/nix/store/z1as323dfsk12agzlp9ia35p5801isd7-glibc-2.35-163/lib -Wl,-dynamic-linker=/nix/store/z1as323dfsk12agzlp9ia35p5801isd7-glibc-2.35-163/lib/ld-linux-x86-64.so.2 --sysroot=/ -fno-checking -shared -fPIC -DPIC .libs/lto-plugin.o -Wl,-rpath -Wl,/nix/store/m3wi1gn0309l15zrha95yv9mw39972db-gfortran-13.0.0-lib/lib
[Bug d/106623] New: internal compiler error: Segmentation fault at gimple-expr.cc:88
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106623
Bug ID: 106623
Summary: internal compiler error: Segmentation fault at
gimple-expr.cc:88
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: d
Assignee: ibuclaw at gdcproject dot org
Reporter: ibuclaw at gdcproject dot org
Target Milestone: ---
When compiling with -O1 and above.
---
private struct _Complex(T) { T re; T im; }
enum __c_complex_double : _Complex!double;
pragma(inline, true)
size_t hashOf()(scope const double val)
{
return *cast(size_t*)
}
pragma(inline, true)
size_t hashOf()(scope const _Complex!double val, size_t seed = 0)
{
return hashOf(val.re) + hashOf(val.im);
}
pragma(inline, true)
size_t hashOf()(__c_complex_double val, size_t seed = 0)
{
return hashOf(cast(_Complex!double) val, seed);
}
int main()
{
__c_complex_double val;
return cast(int)hashOf(val);
}
---
The conflating between native complex and struct representation in the code
generation bites us in the optimization pass.
[Bug rtl-optimization/106590] [12/13 Regression] x86-64 miscompilation starting with r12-8233-g1ceddd7497e15d w/ mtune=skylake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106590 --- Comment #9 from Jakub Jelinek --- Fixed on the trunk so far, 12.2 is frozen now and I think the fix needs some time on the trunk before backporting, so probably only will be fixed for 12.3.
[Bug rtl-optimization/106590] [12/13 Regression] x86-64 miscompilation starting with r12-8233-g1ceddd7497e15d w/ mtune=skylake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106590
--- Comment #8 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:3a74a7bf62f47ed0d19866576378724be932ee17
commit r13-2042-g3a74a7bf62f47ed0d19866576378724be932ee17
Author: Jakub Jelinek
Date: Mon Aug 15 13:56:57 2022 +0200
ifcvt: Fix up noce_convert_multiple_sets [PR106590]
The following testcase is miscompiled on x86_64-linux.
The problem is in the noce_convert_multiple_sets optimization.
We essentially have:
if (g == 1)
{
g = 1;
f = 23;
}
else
{
g = 2;
f = 20;
}
and for each insn try to create a conditional move sequence.
There is code to detect overlap with the regs used in the condition
and the destinations, so we actually try to construct:
tmp_g = g == 1 ? 1 : 2;
f = g == 1 ? 23 : 20;
g = tmp_g;
which is fine. But, we actually try to create two different
conditional move sequences in each case, seq1 with the whole
(eq (reg/v:HI 82 [ g ]) (const_int 1 [0x1]))
condition and seq2 with cc_cmp
(eq (reg:CCZ 17 flags) (const_int 0 [0]))
to rely on the earlier present comparison. In each case, we
compare the rtx costs and choose the cheaper sequence (seq1 if both
have the same cost).
The problem is that with the skylake tuning,
tmp_g = g == 1 ? 1 : 2;
is actually expanded as
tmp_g = (g == 1) + 1;
in seq1 (which clobbers (reg 17 flags)) and as a cmov in seq2
(which doesn't). The tuning says both have the same cost, so we
pick seq1. Next we check sequences for
f = g == 1 ? 23 : 20; and here the seq2 cmov is cheaper, but it
uses (reg 17 flags) which has been clobbered earlier.
The following patch fixes that by detecting if we in the chosen
sequence clobber some register mentioned in cc_cmp or rev_cc_cmp,
and if yes, arranges for only seq1 (i.e. sequences that emit the
comparison itself) to be used after that.
2022-08-15 Jakub Jelinek
PR rtl-optimization/106590
* ifcvt.cc (check_for_cc_cmp_clobbers): New function.
(noce_convert_multiple_sets_1): If SEQ sets or clobbers any regs
mentioned in cc_cmp or rev_cc_cmp, don't consider seq2 for any
further conditional moves.
* gcc.dg/torture/pr106590.c: New test.
[Bug tree-optimization/106621] [13 Regression] ICE in irange_set, at value-range.cc:619
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106621 Richard Biener changed: What|Removed |Added Target Milestone|--- |13.0 CC||aldyh at gcc dot gnu.org, ||rguenth at gcc dot gnu.org
[Bug demangler/106622] New: Bug report
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106622 Bug ID: 106622 Summary: Bug report Product: gcc Version: rust/master Status: UNCONFIRMED Severity: normal Priority: P3 Component: demangler Assignee: unassigned at gcc dot gnu.org Reporter: sophrosx at gmail dot com Target Milestone: --- Created attachment 53459 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53459=edit testcases for nm-new Hello, I detected the memory leak and dead loop problems through fuzz testing, which I think might be a vulnerability. I found that the binutils-gdb[https://github.com/bminor/binutils-gdb]'s program nm-new with the test inputs triggered dead loop and memory leak vulnerabilities. As a result, I submit the testcases to binutils and here is the bug report[https://sourceware.org/bugzilla/show_bug.cgi?id=29492]. The configuration of binutils is: $ ./configure --disable-shared && make -j and compiled with gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0 Then the maintainer Alan Modra[amo...@gmail.com] told me that the endless looping is all in the rust demangler. What is more, the symbols being demangled are: 1) _RYXBAL_OFFGLOBTABLE_ 2) _RYFGNUSLT_FHStNB10ay_start 3) _RYDGLOBOFFSET_TABLE_ 4) _RYFGDIC6gnu_compilediBtOhighlightEH_FRAME_HDR 5) _RYFUDGC6ShigdefaulttiBtOhighlightEH_FRAME_HDR 6) _RYFUDGC6Shighdignu_compiledhlightEH_FRAME_HDR 7) _RYFIMYeB_xDGLtSarray_start 8) _RYdMMYTopFinFGAarral_start 9) _RMYADGC0hdpnit_Grray_start 10) _RYNSMICu2FiFGtDBrray_s 11) _RYTOdPjesistePDGC1onRLab_e 12) _RIYADGO0Rdpnit_Grray_start Further more, I add those testcases in the attachment. If there is anything I am unclear about or need to discuss further, please feel free to contact me~ Looking forward to your reply!
[Bug sanitizer/106558] ASan failed to detect a global-buffer-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106558 --- Comment #10 from Yury Gribov --- Created attachment 53458 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53458=edit Very draft patch (In reply to Jakub Jelinek from comment #7) > Perhaps either a quick check that for base ptrs that live in memory > gimple_vuse is the same for both statements or if not, do walk_aliased_vdefs > with low constant limit? > We'd want to stop if we reach the vdef of the stmt in base_checks vector > (then we didn't find anything that could clobber it and can therefore use > the cached check) or when we see a stmt that may clobber it (then we can't > use the cached check). Something like this? It does not help with b.1_2 in attached reprocase though, because alias oracle considers *b.0_1 = 2; to clobber it. I'm trying to collect statistics how many checks this optimization removes during bootstrap-asan but I'm getting crashes when asan-bootstrapping on unchanged trunk. Is this possible?
[Bug tree-optimization/106621] New: [13 Regression] ICE in irange_set, at value-range.cc:619
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106621
Bug ID: 106621
Summary: [13 Regression] ICE in irange_set, at
value-range.cc:619
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
Target: aarch64-linux-gnu
gcc 13.0.0 20220814 snapshot (g:fe4dc4f553d8639b0ce3465e5e6dcf61c1ae9752) ICEs
when compiling the following testcase w/ -mcpu=neoverse-v1 -O2
-fvect-cost-model=dynamic -fno-tree-scev-cprop:
int m, n;
void
foo (unsigned int x, short int y)
{
if (m)
for (;;)
{
++m;
while (m < 1)
{
n += m + x;
++m;
}
}
for (;;)
if (y)
{
++x;
if (x)
for (y = 0; y < 75; y += 2)
{
}
}
}
% aarch64-linux-gnu-gcc-13.0.0 -mcpu=neoverse-v1 -O2 -fvect-cost-model=dynamic
-fno-tree-scev-cprop -c k0jfume7.c
during GIMPLE pass: vrp
k0jfume7.c: In function 'foo':
k0jfume7.c:4:1: internal compiler error: in irange_set, at value-range.cc:619
4 | foo (unsigned int x, short int y)
| ^~~
0x7e41ce irange::irange_set(tree_node*, tree_node*)
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20220814/work/gcc-13-20220814/gcc/value-range.cc:619
0x1b1d97d fold_using_range::range_of_ssa_name_with_loop_info(vrange&,
tree_node*, loop*, gphi*, fur_source&)
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20220814/work/gcc-13-20220814/gcc/gimple-range-fold.cc:1381
0x1b1e18e fold_using_range::range_of_phi(vrange&, gphi*, fur_source&)
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20220814/work/gcc-13-20220814/gcc/gimple-range-fold.cc:863
0x1b205c8 fold_using_range::fold_stmt(vrange&, gimple*, fur_source&,
tree_node*)
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20220814/work/gcc-13-20220814/gcc/gimple-range-fold.cc:557
0x1b12889 gimple_ranger::fold_range_internal(vrange&, gimple*, tree_node*)
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20220814/work/gcc-13-20220814/gcc/gimple-range.cc:258
0x1b12889 gimple_ranger::range_of_stmt(vrange&, gimple*, tree_node*)
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20220814/work/gcc-13-20220814/gcc/gimple-range.cc:319
0x1b12bea gimple_ranger::register_inferred_ranges(gimple*)
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20220814/work/gcc-13-20220814/gcc/gimple-range.cc:472
0x12122e0 rvrp_folder::pre_fold_bb(basic_block_def*)
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20220814/work/gcc-13-20220814/gcc/tree-vrp.cc:4306
0x1100e82 substitute_and_fold_dom_walker::before_dom_children(basic_block_def*)
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20220814/work/gcc-13-20220814/gcc/tree-ssa-propagate.cc:758
0x1adcbc7 dom_walker::walk(basic_block_def*)
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20220814/work/gcc-13-20220814/gcc/domwalk.cc:311
0x10ffbf5 substitute_and_fold_engine::substitute_and_fold(basic_block_def*)
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20220814/work/gcc-13-20220814/gcc/tree-ssa-propagate.cc:987
0x12078c0 execute_ranger_vrp(function*, bool)
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20220814/work/gcc-13-20220814/gcc/tree-vrp.cc:4349
[Bug middle-end/106609] [SH] miscompilation of loop involving noreturn call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106609 --- Comment #2 from Sébastien Michelland --- Yes there are delay slots for all branches except bt and bf, so here bt.s, jsr and rts all have one. (-fno-delayed-branches avoids them but that doesn't affect the bad optimization in this case.) Adding -fno-schedule-insns -fno-schedule-insns2 doesn't help; the test and load are still eliminated. In fact, I negated the entirety of -Q --help=optimizers and still got an incorrect output. It seems that the problem lies further downstream. I dumped various RTL stages and -fdump-rtl-mach is the first stage where the comparison to 0 is gone, if the order in the manual is anything to go by. Since I have both functional and non-functional outputs from different RTL stages, I'm switching the component to rtl-optimization.
[Bug tree-optimization/106617] [13 Regression] gcc is very slow at ternary expressions,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106617 --- Comment #8 from Richard Biener --- We don't fold because case COMPOUND_EXPR: /* When pedantic, a compound expression can be neither an lvalue nor an integer constant expression. */ if (TREE_SIDE_EFFECTS (arg0) || TREE_CONSTANT (arg1)) return NULL_TREE; /* Don't let (0, 0) be null pointer constant. */ tem = integer_zerop (arg1) ? build1_loc (loc, NOP_EXPR, type, arg1) : fold_convert_loc (loc, type, arg1); return tem; where we chicken out because of the fear of early folding. At least the C frontend should get this correct now. Ideally the above would just return arg1 if !TREE_SIDE_EFFECTS (arg0). OTOH it's really sth for language specific folding. Of course the bug then would be still present when replacing (0, 0) with something non-constant.
[Bug analyzer/106620] New: Incorrectly thinks execution can continue after a return statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106620 Bug ID: 106620 Summary: Incorrectly thinks execution can continue after a return statement Product: gcc Version: 12.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: nrk at disroot dot org Target Milestone: --- Created attachment 53457 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53457=edit sample code Sample code (also attached) : https://godbolt.org/z/ez556Yd39 It thinks that memchr() is being called with null. But if `hay` was null, then the function returns, so that's not possible. Removing the `|| nlen == 1` silences the warning.
[Bug tree-optimization/106617] [13 Regression] gcc is very slow at ternary expressions,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106617 Richard Biener changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org Status|UNCONFIRMED |NEW Last reconfirmed||2022-08-15 Keywords||needs-bisection Ever confirmed|0 |1 --- Comment #7 from Richard Biener --- Applying pattern match.pd:5769, generic-match.cc:14472 Applying pattern match.pd:5769, generic-match.cc:14472 Applying pattern match.pd:5769, generic-match.cc:14472 Applying pattern match.pd:5769, generic-match.cc:14472 Applying pattern match.pd:5769, generic-match.cc:14472 Applying pattern match.pd:5769, generic-match.cc:14472 Applying pattern match.pd:5769, generic-match.cc:14472 Applying pattern match.pd:5769, generic-match.cc:14472 Applying pattern match.pd:5769, generic-match.cc:14472 Applying pattern match.pd:5769, generic-match.cc:14472 Applying pattern match.pd:5769, generic-match.cc:14472 Applying pattern match.pd:5769, generic-match.cc:14472 Applying pattern match.pd:5769, generic-match.cc:14472 Applying pattern match.pd:5769, generic-match.cc:14472 ... that's the following pattern which GCC 12 doesn't have /* From fold_binary_op_with_conditional_arg handle the case of rewriting (a ? b : c) > d to a ? (b > d) : (c > d) when the compares simplify. */ (for cmp (simple_comparison) (simplify (cmp:c (cond @0 @1 @2) @3) /* Do not move possibly trapping operations into the conditional as this pessimizes code and causes gimplification issues when applied late. */ (if (!FLOAT_TYPE_P (TREE_TYPE (@3)) || operation_could_trap_p (cmp, true, false, @3)) (cond @0 (cmp! @1 @3) (cmp! @2 @3) the testcase is essentially a degenerate case of this, applying the pattern recursively. The testcase is a bit too large to easily follow what happens, cutting some lines in the middle shows we are eventually producing 0, 0 ? nr_cpu_ids == 0 && ((nr_cpu_ids & 7) == 0 && (nr_cpu_ids == 0 && ((nr_cpu_ids & 5) == 0 && (nr_cpu_ids == 0 && ((nr_cpu_ids & 3) == 0 && (nr_cpu_ids + -1 & 1) != 0) : 0 ? 2 : 1; not sure why we don't fold the (0, 0) ? ..., that seems to be a "bug" of fully folding in the C frontend? We do simplify 0 ? ... just fine. Supposedly COMPOUND_EXPRs are never constant folded?
[Bug analyzer/106551] [13 Regression] dup2 causes -fanalyzer ICE in valid_to_unchecked_state, at analyzer/sm-fd.cc:751
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106551 --- Comment #5 from Immad Mir --- Thanks for reporting the ICE, Tim. Dave: I have sent a patch via gcc-patches.
[Bug middle-end/106609] [SH] miscompilation of loop involving noreturn call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106609 --- Comment #1 from Richard Biener --- .L3:bt.s.L2 dt r1 are there any delay slots in SH? Does -fno-schedule-insns -fno-schedule-insns2 help?
[Bug libstdc++/106608] [12/13 Regression] std::optional requires unavailable dtor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106608 Richard Biener changed: What|Removed |Added Summary|[12 Regression] |[12/13 Regression] |std::optional requires |std::optional requires |unavailable dtor|unavailable dtor Keywords||needs-bisection, ||rejects-valid Target Milestone|--- |12.2
[Bug c++/106619] New: Inconsistent __PRETTY_FUNCTION__ output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106619
Bug ID: 106619
Summary: Inconsistent __PRETTY_FUNCTION__ output
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: kentsangkm at gmail dot com
Target Milestone: ---
Created attachment 53456
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53456=edit
example code
The __PRETTY_FUNCTION__ macro does print the function name as well as the
template arguments (if any), but the output is inconsistent and depends on the
declaration sequence.
// any templated typed with optional parameter(s)
template, void,
T>>
struct Foo
{
};
template
struct Container
{
void get() const{
std::cout << typeid(T).name() << " "<< __PRETTY_FUNCTION__ <<
std::endl;
}
};
int main()
{
Container> b;
b.get();
Container> a;
a.get();
}
Output:
3FooIiiE void Container::get() const [with T = Foo]
3FooIiiE void Container::get() const [with T = Foo]
If we swap the declaration of a and b, the output becomes:
3FooIiiE void Container::get() const [with T = Foo]
3FooIiiE void Container::get() const [with T = Foo]
in contrast, the typeid is very consistent on both cases, but it is not an
constexpr function
Clang does not have such issue, as it always expends the optional arguments and
output Foo always
Here is a short link for godbolt
https://godbolt.org/z/vfTnz5bEb
the same code piece is also be enclosed
[Bug web/106618] New: [docs] Option Summary shows `-fargs-in-order` instead of `-fstrong-eval-order`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106618 Bug ID: 106618 Summary: [docs] Option Summary shows `-fargs-in-order` instead of `-fstrong-eval-order` Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: web Assignee: unassigned at gcc dot gnu.org Reporter: davidfong19 at gmail dot com Target Milestone: --- When reading through the [Options Summary](https://gcc.gnu.org/onlinedocs/gcc/Option-Summary.html) page, I noticed that there was an option in the C++ language section, `-fargs-in-order=n`, that was not listed in [the dedicated page for C++ language options](https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Dialect-Options.html). I did a quick google and one of the top results was about [a gcc patch which renamed](https://gcc.gnu.org/legacy-ml/gcc-patches/2016-07/txt8uZU1Gq8SB.txt) the argument to `-fstrong-eval-order`. I'm guessing it's just a mistake not noticing this documentation which should be updated?
[Bug tree-optimization/106617] [13 Regression] gcc is very slow at ternary expressions,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106617 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |13.0
[Bug tree-optimization/106617] [13 Regression] gcc is very slow at ternary expressions,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106617 --- Comment #6 from Sergei Trofimovich --- Created attachment 53455 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53455=edit ring_buffer.c.gz ring_buffer.c.gz is a preprocessed file from linux-4.19. $ time gcc-12.1.0 -O2 -c ring_buffer.c -o bug.o real0m0,308s user0m0,285s sys 0m0,017s $ gcc -O2 -c ring_buffer.c -o bug.o # Runs for minutes, increases RAM usage, never finishes. perf stats after 3 minutes' run: 10,16% cc1 [.] operand_compare::operand_equal_p 7,38% cc1 [.] fold_binary_loc 7,01% cc1 [.] generic_simplify_453 5,63% cc1 [.] generic_simplify_GT_EXPR 3,72% cc1 [.] wide_int_binop 3,42% cc1 [.] generic_simplify_COND_EXPR 3,38% cc1 [.] hash_table::find_slot_with_hash 3,04% cc1 [.] wide_int_to_tree_1 3,00% cc1 [.] tree_strip_nop_conversions 2,82% cc1 [.] int_const_binop 2,47% cc1 [.] get_inner_reference 2,45% cc1 [.] fold_build2_loc 2,23% cc1 [.] fold_ternary_loc 2,07% cc1 [.] tree_strip_sign_nop_conversions 1,96% cc1 [.] int_cst_hasher::hash 1,83% cc1 [.] ggc_internal_alloc 1,81% cc1 [.] fold_relational_const 1,61% cc1 [.] wi::fits_to_tree_p > > > 1,57% cc1 [.] generic_simplify_155 1,51% cc1 [.] operand_equal_p 1,22% cc1 [.] dbg_cnt 1,20% cc1 [.] element_precision 1,10% cc1 [.] ggc_free
[Bug tree-optimization/106617] [13 Regression] gcc is very slow at ternary expressions,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106617 --- Comment #5 from Sergei Trofimovich --- --enable-checking=release did not help much. Attached example still compiles 3.5 s. verify parts disappeared from profile, but generic_simplify are still there: 11.20% cc1 cc1 [.] operand_compare::operand_equal_p 4.32% cc1 cc1 [.] wide_int_to_tree_1 4.23% cc1 cc1 [.] fold_binary_loc 4.02% cc1 cc1 [.] generic_simplify_NE_EXPR 3.64% cc1 cc1 [.] generic_simplify_EQ_EXPR 3.62% cc1 cc1 [.] tree_strip_nop_conversions 2.78% cc1 cc1 [.] get_inner_reference 2.22% cc1 cc1 [.] wide_int_binop 2.17% cc1 cc1 [.] int_const_binop 2.00% cc1 cc1 [.] tree_nop_convert 1.90% cc1 cc1 [.] operand_equal_p 1.77% cc1 cc1 [.] wi::fits_to_tree_p > > > 1.75% cc1 cc1 [.] integer_zerop 1.72% cc1 cc1 [.] ggc_internal_alloc 1.66% cc1 cc1 [.] element_precision 1.38% cc1 cc1 [.] hash_table::find_slot_with_hash 1.33% cc1 cc1 [.] build2 1.30% cc1 cc1 [.] tree_with_possible_nonzero_bits2 1.29% cc1 cc1 [.] fold_ternary_loc 1.24% cc1 cc1 [.] wi::popcount 1.19% cc1 cc1 [.] tree_truth_valued_p 1.14% cc1 cc1 [.] tree_strip_sign_nop_conversions 1.11% cc1 cc1 [.] generic_simplify 1.11% cc1 cc1 [.] fold_truth_andor 1.10% cc1 cc1 [.] bitmask_inv_cst_vector_p 1.08% cc1 cc1 [.] __popcountdi2 1.02% cc1 cc1 [.] get_nonzero_bits And I also see hangups when building linux-4.19, this time on x86_64 as well. Will try to extract non-minimized example.
[Bug tree-optimization/106322] [12/13 Regression] tree-vectorize: Wrong code at O2 level (-fno-tree-vectorize is working) since r12-2404-ga1d27560770818c5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106322
Kewen Lin changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #45 from Kewen Lin ---
One reduced C test case:
#define N 64
typedef unsigned short int uh;
typedef unsigned short int uw;
uh a[N];
uh b[N];
uh c[N];
uh e[N];
__attribute__ ((noipa)) void
foo ()
{
for (int i = 0; i < N; i++)
c[i] = ((uw) b[i] * (uw) a[i]) >> 16;
}
__attribute__ ((optimize ("-O0"))) void
init ()
{
for (int i = 0; i < N; i++)
{
a[i] = (uh) (0x7ABC - 0x5 * i);
b[i] = (uh) (0xEAB + 0xF * i);
e[i] = ((uw) b[i] * (uw) a[i]) >> 16;
}
}
__attribute__ ((optimize ("-O0"))) void
check ()
{
for (int i = 0; i < N; i++)
{
if (c[i] != e[i])
__builtin_abort ();
}
}
int
main ()
{
init ();
foo ();
check ();
return 0;
}
