[Bug rtl-optimization/102446] [9/10/11/12 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102446 Andrew Pinski changed: What|Removed |Added Keywords||needs-bisection --- Comment #10 from Andrew Pinski --- (In reply to Jakub Jelinek from comment #6) This testcase seems to be fixed on the trunk. It would be useful to know where it was fixed.
[Bug rtl-optimization/95123] [10/11/12 Regression] Wrong code w/ -O2 -fselective-scheduling2 -funroll-loops --param early-inlining-insns=5 --param loop-invariant-max-bbs-in-loop=3 --param max-jump-thr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95123 Andrew Pinski changed: What|Removed |Added Keywords||needs-bisection Summary|[10/11/12 Regression] Wrong |[10/11/12 Regression] Wrong |code w/ -O2 |code w/ -O2 |-fselective-scheduling2 |-fselective-scheduling2 |-funroll-loops --param |-funroll-loops --param |early-inlining-insns=5 |early-inlining-insns=5 |--param |--param |loop-invariant-max-bbs-in-l |loop-invariant-max-bbs-in-l |oop=3 --param |oop=3 --param |max-jump-thread-duplication |max-jump-thread-duplication |-stmts=0|-stmts=0 -fPIE --- Comment #11 from Andrew Pinski --- Seems to be working on the trunk, would be interesting to see why it passes there.
[Bug target/100623] [10/11/12 Regression] wrong code with -Os -fno-dce -fno-defer-pop -fno-forward-propagate -flive-range-shrinkage -fno-rerun-cse-after-loop -mno-push-args since r10-7515-g2c0fa3ecf70
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100623 --- Comment #4 from Andrew Pinski --- (In reply to Andrew Pinski from comment #3) > There seems to be some IR difference on the gimple level which might be > making this latent. But that is not where the problem is located really as far as I can tell, the assembly for bn_mul_recursive is different too (and it looks like the difference in the assembly for bn_add_words is only different in the comparison and nothing else [no other code changes]).
[Bug target/100623] [10/11/12 Regression] wrong code with -Os -fno-dce -fno-defer-pop -fno-forward-propagate -flive-range-shrinkage -fno-rerun-cse-after-loop -mno-push-args since r10-7515-g2c0fa3ecf70
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100623 --- Comment #3 from Andrew Pinski --- There seems to be some IR difference on the gimple level which might be making this latent. In GCC 11.2.0 we have (bn_add_words) : _2 = n_3 & -4; ... if (_2 != 0) While on the trunk we have: _14 = (unsigned int) n_3; if (_14 > 3) This does look like a valid transformation knowing that n is subtracted by 4.
[Bug target/100623] [10/11/12 Regression] wrong code with -Os -fno-dce -fno-defer-pop -fno-forward-propagate -flive-range-shrinkage -fno-rerun-cse-after-loop -mno-push-args since r10-7515-g2c0fa3ecf70
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100623 Andrew Pinski changed: What|Removed |Added Known to fail||11.2.0 Keywords||needs-bisection --- Comment #2 from Andrew Pinski --- Looks to be fixed on the trunk.
[Bug c++/104282] Copy elision when initializing a base-class subobject with aggregate initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104282 --- Comment #6 from Andrew Pinski --- http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#2403
[Bug fortran/104127] [9 Regression] ICE in get_array_charlen, at fortran/trans-array.c:7244
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104127 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from anlauf at gcc dot gnu.org --- Fixed on 9-branch for the reported testcase. The extended testcase committed on 10-branch and higher needed deactivating of two lines which seem to require additional fixes and likely failed before. Closing. Thanks for the report!
[Bug fortran/104127] [9 Regression] ICE in get_array_charlen, at fortran/trans-array.c:7244
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104127 --- Comment #10 from CVS Commits --- The releases/gcc-9 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:bb05ddea976a7a8b3f02175050a5d53356ccab9d commit r9-9932-gbb05ddea976a7a8b3f02175050a5d53356ccab9d Author: Harald Anlauf Date: Thu Jan 20 22:36:50 2022 +0100 Fortran: fix simplification of TRANSFER for zero-sized character array result gcc/fortran/ChangeLog: PR fortran/104127 * simplify.c (gfc_simplify_transfer): Ensure that the result typespec is set up for TRANSFER with MOLD of type CHARACTER including character length even if the result is a zero-sized array. gcc/testsuite/ChangeLog: PR fortran/104127 * gfortran.dg/transfer_simplify_11.f90: Fix logic. * gfortran.dg/transfer_simplify_13.f90: New test. (cherry picked from commit 6c1a93102b41a558f3ad49a7c66015257535c747)
Re: [Bug regression/103997] [12 Regression] gcc.target/i386/pr88531-??.c scan-assembler-times FAILs
On Sat, Jan 29, 2022 at 2:40 PM write2mark1--- via Gcc-bugs wrote: > > Why does gcc use CVS and not git GCC has used git for ~2 years now and before that it was using svn for ~14 years; before that used cvs for ~8 years and then used rcs (though the overlap between rcs and cvs is real). GCC's git repo has the history all the way back to the rcs days even. GCC's web pages are in git too; moved to git before the source base and before that it was in cvs (the reasons to move to svn were not needed due to no branch usage, etc.). So I am not understanding the question here really. Thanks, Andrew Pinski > On Tue, Jan 25, 2022 at 5:27 PM admin at levyhsu dot com via Gcc-bugs < > gcc-bugs@gcc.gnu.org> wrote: > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103997 > > > > --- Comment #14 from Levy Hsu --- > > Hi Avieira and Richard > > > > I checked the data for the last half month and you are right, that no real > > regression was caused. Thank you all for the detailed explanation.
Re: [Bug regression/103997] [12 Regression] gcc.target/i386/pr88531-??.c scan-assembler-times FAILs
Why does gcc use CVS and not git On Tue, Jan 25, 2022 at 5:27 PM admin at levyhsu dot com via Gcc-bugs < gcc-bugs@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103997 > > --- Comment #14 from Levy Hsu --- > Hi Avieira and Richard > > I checked the data for the last half month and you are right, that no real > regression was caused. Thank you all for the detailed explanation.
[Bug fortran/104127] [9 Regression] ICE in get_array_charlen, at fortran/trans-array.c:7244
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104127 anlauf at gcc dot gnu.org changed: What|Removed |Added Summary|[9/10/11/12 Regression] ICE |[9 Regression] ICE in |in get_array_charlen, at|get_array_charlen, at |fortran/trans-array.c:7244 |fortran/trans-array.c:7244 --- Comment #9 from anlauf at gcc dot gnu.org --- Fixed on mainline for gcc-12, and on 11- and 10-branch so far.
[Bug fortran/83079] ICE in gfc_widechar_to_char, at fortran/scanner.c:198
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83079 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Target Milestone|--- |10.4 Resolution|--- |FIXED --- Comment #10 from anlauf at gcc dot gnu.org --- Fixed on mainline for gcc-12, and on 11- and 10-branch. Closing. Thanks for the report!
[Bug tree-optimization/104215] bogus -Wuse-after-free=3 due to forwprop moving a pointer test after realloc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104215 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2022-01-29 --- Comment #8 from Andrew Pinski --- Confirmed.
[Bug fortran/83079] ICE in gfc_widechar_to_char, at fortran/scanner.c:198
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83079 --- Comment #9 from CVS Commits --- The releases/gcc-10 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:aa87c979d34bdea62586de79e8645fbddfa065b8 commit r10-10427-gaa87c979d34bdea62586de79e8645fbddfa065b8 Author: Harald Anlauf Date: Tue Jan 11 22:06:10 2022 +0100 Fortran: fix ICE and wrong code with TRANSFER and CHARACTER(kind=4) gcc/fortran/ChangeLog: PR fortran/83079 * target-memory.c (gfc_interpret_character): Result length is in bytes and thus depends on the character kind. * trans-intrinsic.c (gfc_conv_intrinsic_transfer): Compute correct string length for the result of the TRANSFER intrinsic and for temporaries for the different character kinds. gcc/testsuite/ChangeLog: PR fortran/83079 * gfortran.dg/transfer_char_kind4.f90: New test. (cherry picked from commit 29401b7b4581e9131e7057e263dcea8b40a6b5ab)
[Bug fortran/104127] [9/10/11/12 Regression] ICE in get_array_charlen, at fortran/trans-array.c:7244
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104127 --- Comment #8 from CVS Commits --- The releases/gcc-10 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:6da0c19bdcf992bd18c32335342fc3511683f314 commit r10-10426-g6da0c19bdcf992bd18c32335342fc3511683f314 Author: Harald Anlauf Date: Thu Jan 20 22:36:50 2022 +0100 Fortran: fix simplification of TRANSFER for zero-sized character array result gcc/fortran/ChangeLog: PR fortran/104127 * simplify.c (gfc_simplify_transfer): Ensure that the result typespec is set up for TRANSFER with MOLD of type CHARACTER including character length even if the result is a zero-sized array. gcc/testsuite/ChangeLog: PR fortran/104127 * gfortran.dg/transfer_simplify_11.f90: Fix logic. * gfortran.dg/transfer_simplify_13.f90: New test. (cherry picked from commit 6c1a93102b41a558f3ad49a7c66015257535c747)
[Bug tree-optimization/104286] gimple-match should cause an ICE for comparisons which are not of "boolean" types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104286 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Component|middle-end |tree-optimization
[Bug middle-end/104286] New: gimple-match should cause an ICE for comparisons which are not of "boolean" types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104286 Bug ID: 104286 Summary: gimple-match should cause an ICE for comparisons which are not of "boolean" types Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: internal-improvement Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org Target Milestone: --- As shown by PR 104279 (and others), gimple-match should cause an ICE when a match pattern tries to create a comparison which is not of "boolean" type. (boolean type is either BOOLEAN_TYPE or an integeral type which is one bit wide). I am filing this now for GCC 13 as we are currently in stage 4.
[Bug fortran/101135] Load of null pointer when passing absent assumed-shape array argument for an optional dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101135 anlauf at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #5 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2022-January/057496.html
[Bug c++/104284] [9/10/11/12 Regression] ICE: unexpected expression '' of kind implicit_conv_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104284 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2022-01-29 Status|UNCONFIRMED |NEW --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug c++/104284] [9/10/11/12 Regression] ICE: unexpected expression '' of kind implicit_conv_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104284 Andrew Pinski changed: What|Removed |Added Keywords||ice-checking Target Milestone|--- |9.5
[Bug c++/104285] New: openmp offload linker issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104285 Bug ID: 104285 Summary: openmp offload linker issue Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: xw111luoye at gmail dot com Target Milestone: --- miniQMC https://github.com/ye-luo/miniqmc ships a set of OpenMP offload tests. ``` cmake -DCMAKE_CXX_COMPILER=g++ -DENABLE_OFFLOAD=ON .. make -j32 ``` When those tests are compiled into individual executables. All tests compile/link/run fine. However if all the tests are linked together into a single executable test_omptarget_all_in_one I got ``` lto1: fatal error: CMakeFiles/test_omptarget_all_in_one.dir/test_omp_reduction.cpp.o: section _ZN11qmcplusplusL29C_A_T_C_HT_E_S_T0Ev$_omp_fn$1.3169 is missing compilation terminated. mkoffload: fatal error: /soft/gcc/gcc-12-dev-2022-01-28/bin/x86_64-pc-linux-gnu-accel-nvptx-none-gcc returned 1 exit status compilation terminated. lto-wrapper: fatal error: /soft/gcc/gcc-12-dev-2022-01-28/libexec/gcc/x86_64-pc-linux-gnu/12.0.1//accel/nvptx-none/mkoffload returned 1 exit status compilation terminated. /usr/bin/ld: error: lto-wrapper failed collect2: error: ld returned 1 exit status make[2]: *** [src/Platforms/tests/OMPTarget/CMakeFiles/test_omptarget_all_in_one.dir/build.make:359: src/Platforms/tests/OMPTarget/test_omptarget_all_in_one] Error 1 make[1]: *** [CMakeFiles/Makefile2:1656: src/Platforms/tests/OMPTarget/CMakeFiles/test_omptarget_all_in_one.dir/all] Error 2 make: *** [Makefile:101: all] Error 2 ``` gcc compiler commit 3f0fcda37f58d4108feb67de08f181a32bcb6388
[Bug c++/104284] New: [9/10/11/12 Regression] ICE: unexpected expression '' of kind implicit_conv_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104284 Bug ID: 104284 Summary: [9/10/11/12 Regression] ICE: unexpected expression '' of kind implicit_conv_expr Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: dani at danielbertalan dot dev Target Milestone: --- Godbolt link: https://godbolt.org/z/8bTPra5jK The following code snippet causes an ICE on trunk (commit 3d41939c8799a51b1cd7f4610c06771bf6d52f15), and as far back as on 9.1 with -fchecking=2: --- struct EstablishedTiming { char m_dmt_id{}; }; auto x = [](auto) { constexpr EstablishedTiming established_timings3_bytes[]{{}}; }; --- ice1.ii: In lambda function: ice1.ii:5:80: internal compiler error: unexpected expression '' of kind implicit_conv_expr 5 | x = [](auto) { constexpr EstablishedTiming established_timings3_bytes[]{{}}; }; | ^ 0x98a181 cxx_eval_constant_expression gcc/cp/constexpr.cc:7493 0x99109b cxx_eval_store_expression gcc/cp/constexpr.cc:5619 0x9860b4 cxx_eval_constant_expression gcc/cp/constexpr.cc:6763 0x98a626 cxx_eval_outermost_constant_expr gcc/cp/constexpr.cc:7707 0x98f770 fold_non_dependent_expr_template gcc/cp/constexpr.cc:8066 0xb0de7f build_non_dependent_expr(tree_node*) gcc/cp/pt.cc:28412 0xb6c547 finish_expr_stmt(tree_node*) gcc/cp/semantics.cc:870 0xa2d933 get_temp_regvar(tree_node*, tree_node*) gcc/cp/init.cc:4254 0xa2d933 build_vec_init(tree_node*, tree_node*, tree_node*, bool, int, int, vec**) gcc/cp/init.cc:4477 0xa2f503 build_aggr_init(tree_node*, tree_node*, int, int) gcc/cp/init.cc:2009 0x9d83ec build_aggr_init_full_exprs gcc/cp/decl.cc:7053 0x9d83ec check_initializer gcc/cp/decl.cc:7214 0x9fdc7f cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int) gcc/cp/decl.cc:8108 0xaf15df cp_parser_init_declarator gcc/cp/parser.cc:22823 0xacb5e3 cp_parser_simple_declaration gcc/cp/parser.cc:15286 0xacd2fd cp_parser_declaration_statement gcc/cp/parser.cc:14367 0xacdaeb cp_parser_statement gcc/cp/parser.cc:12452 0xace9bd cp_parser_statement_seq_opt gcc/cp/parser.cc:12856 0xacea98 cp_parser_compound_statement gcc/cp/parser.cc:12808 0xacf797 cp_parser_function_body gcc/cp/parser.cc:25062
[Bug target/104283] New: nvptx-none needs more user friendly architecture handling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104283 Bug ID: 104283 Summary: nvptx-none needs more user friendly architecture handling Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: xw111luoye at gmail dot com Target Milestone: --- x86_64-pc-linux-gnu-accel-nvptx-none-gcc needs both -misa and -mptx to select a specific target. When I use OpenMP offload. -foffload-options=nvptx-none="-misa=sm_80" I got error ``` ptxas /tmp/ccW7wYQT.o, line 3; error : PTX .version 3.1 does not support .target sm_80 ptxas /tmp/ccW7wYQT.o, line 2622; warning : Instruction 'shfl' without '.sync' may produce unpredictable results on sm_70 and later architectures ``` Then I have to get it through with -foffload-options=nvptx-none="-misa=sm_80 -mptx=7.0" I think GPU users know what sm_80 is but they rarely know PTX. Can we -mptx default to highest -misa selection supports? Or introduce something like -march=sm_80 and map it to appropriate -misa and -mptx. Simplify the need of options is much appreciated.
[Bug c++/104282] Copy elision when initializing a base-class subobject with aggregate initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104282 --- Comment #5 from Jonathan Wakely --- Related to https://github.com/itanium-cxx-abi/cxx-abi/issues/107
[Bug c++/104282] Copy elision when initializing a base-class subobject with aggregate initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104282 --- Comment #4 from Jonathan Wakely --- I think there's any existing bug about this, and it's an open issue in the ABI
[Bug c++/104266] Temporaries with protected destructor are erroneously permitted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104266 --- Comment #4 from Fedor Chelnokov --- In your last example, I think Clang is right, because `Y` is not an aggregate in C++11 due to the presence of default member initializer. And it becomes an aggregate only in C++14.
[Bug c++/104282] Copy elision when initializing a base-class subobject with aggregate initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104282 --- Comment #3 from Fedor Chelnokov --- Both Clang and GCC do not change their output either with `-std=c++20` or with `-std=c++17` options. And both reject the program with -std=c++14`.
[Bug c++/104282] Copy elision when initializing a base-class subobject with aggregate initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104282 --- Comment #2 from Andrew Pinski --- That is c++17 requires Copy elision here while c++14 does not.
[Bug c++/104282] Copy elision when initializing a base-class subobject with aggregate initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104282 --- Comment #1 from Andrew Pinski --- Gcc 12 defaults to c++17. I have not looked but I suspect that is the difference.
[Bug tree-optimization/104281] [12 Regression] wrong code at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104281 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Fixed.
[Bug tree-optimization/104279] [12 Regregression] ICE on valid code at -O1 and above on x86_64-linux-gnu: verify_gimple failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104279 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Fixed.
[Bug tree-optimization/104280] [12 Regression] wrong code at -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104280 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Jakub Jelinek --- Fixed.
[Bug tree-optimization/95424] Failure to optimize division with numerator of 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95424 --- Comment #9 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:3d41939c8799a51b1cd7f4610c06771bf6d52f15 commit r12-6932-g3d41939c8799a51b1cd7f4610c06771bf6d52f15 Author: Jakub Jelinek Date: Sat Jan 29 17:55:51 2022 +0100 testsuite: Fix up tree-ssa/divide-7.c testcase [PR95424] This test fails everywhere, because ? doesn't match literal ?. It should use \\? instead. I've also changed those .s in there. 2022-01-29 Jakub Jelinek PR tree-optimization/95424 * gcc.dg/tree-ssa/divide-7.c: Fix up regexps in scan-tree-dump{,-not}.
[Bug tree-optimization/104281] [12 Regression] wrong code at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104281 --- Comment #2 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:a1544878966020d1f7a640b35d1f7a5f0e055624 commit r12-6931-ga1544878966020d1f7a640b35d1f7a5f0e055624 Author: Jakub Jelinek Date: Sat Jan 29 17:54:43 2022 +0100 match.pd: Fix up 1 / X for unsigned X optimization [PR104280] On Fri, Jan 28, 2022 at 11:38:23AM -0700, Jeff Law wrote: > Thanks. Given the original submission and most of the review work was done > prior to stage3 closing, I went ahead and installed this on the trunk. Unfortunately this breaks quite a lot of things. The main problem is that GIMPLE allows EQ_EXPR etc. only with BOOLEAN_TYPE or with TYPE_PRECISION == 1 integral type (or vector boolean). Violating this causes verification failures in tree-cfg.cc in some cases, in other cases wrong-code issues because before it is verified we e.g. transform 1U / x into x == 1U and later into x (because we assume that == type must be one of the above cases and when it is the same type as the type of the first operand, for boolean-ish cases it should be equivalent). Fixed by changing that (eq @1 { build_one_cst (type); }) into (convert (eq:boolean_type_node @1 { build_one_cst (type); })) Note, I'm not 100% sure if :boolean_type_node is required in that case, I see some spots in match.pd that look exactly like this, while there is e.g. (convert (le ...)) that supposedly does the right thing too. The signed integer 1/X case doesn't need changes changes, for (cond (le ...) ...) le gets correctly boolean_type_node and cond should use type. I've also reformatted it, some lines were too long, match.pd uses indentation by 1 column instead of 2 etc. 2022-01-29 Jakub Jelinek Andrew Pinski PR tree-optimization/104279 PR tree-optimization/104280 PR tree-optimization/104281 * match.pd (1 / X -> X == 1 for unsigned X): Build eq with boolean_type_node and convert to type. Formatting fixes. * gcc.dg/torture/pr104279.c: New test. * gcc.dg/torture/pr104280.c: New test. * gcc.dg/torture/pr104281.c: New test.
[Bug tree-optimization/104280] [12 Regression] wrong code at -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104280 --- Comment #9 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:a1544878966020d1f7a640b35d1f7a5f0e055624 commit r12-6931-ga1544878966020d1f7a640b35d1f7a5f0e055624 Author: Jakub Jelinek Date: Sat Jan 29 17:54:43 2022 +0100 match.pd: Fix up 1 / X for unsigned X optimization [PR104280] On Fri, Jan 28, 2022 at 11:38:23AM -0700, Jeff Law wrote: > Thanks. Given the original submission and most of the review work was done > prior to stage3 closing, I went ahead and installed this on the trunk. Unfortunately this breaks quite a lot of things. The main problem is that GIMPLE allows EQ_EXPR etc. only with BOOLEAN_TYPE or with TYPE_PRECISION == 1 integral type (or vector boolean). Violating this causes verification failures in tree-cfg.cc in some cases, in other cases wrong-code issues because before it is verified we e.g. transform 1U / x into x == 1U and later into x (because we assume that == type must be one of the above cases and when it is the same type as the type of the first operand, for boolean-ish cases it should be equivalent). Fixed by changing that (eq @1 { build_one_cst (type); }) into (convert (eq:boolean_type_node @1 { build_one_cst (type); })) Note, I'm not 100% sure if :boolean_type_node is required in that case, I see some spots in match.pd that look exactly like this, while there is e.g. (convert (le ...)) that supposedly does the right thing too. The signed integer 1/X case doesn't need changes changes, for (cond (le ...) ...) le gets correctly boolean_type_node and cond should use type. I've also reformatted it, some lines were too long, match.pd uses indentation by 1 column instead of 2 etc. 2022-01-29 Jakub Jelinek Andrew Pinski PR tree-optimization/104279 PR tree-optimization/104280 PR tree-optimization/104281 * match.pd (1 / X -> X == 1 for unsigned X): Build eq with boolean_type_node and convert to type. Formatting fixes. * gcc.dg/torture/pr104279.c: New test. * gcc.dg/torture/pr104280.c: New test. * gcc.dg/torture/pr104281.c: New test.
[Bug tree-optimization/104279] [12 Regregression] ICE on valid code at -O1 and above on x86_64-linux-gnu: verify_gimple failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104279 --- Comment #3 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:a1544878966020d1f7a640b35d1f7a5f0e055624 commit r12-6931-ga1544878966020d1f7a640b35d1f7a5f0e055624 Author: Jakub Jelinek Date: Sat Jan 29 17:54:43 2022 +0100 match.pd: Fix up 1 / X for unsigned X optimization [PR104280] On Fri, Jan 28, 2022 at 11:38:23AM -0700, Jeff Law wrote: > Thanks. Given the original submission and most of the review work was done > prior to stage3 closing, I went ahead and installed this on the trunk. Unfortunately this breaks quite a lot of things. The main problem is that GIMPLE allows EQ_EXPR etc. only with BOOLEAN_TYPE or with TYPE_PRECISION == 1 integral type (or vector boolean). Violating this causes verification failures in tree-cfg.cc in some cases, in other cases wrong-code issues because before it is verified we e.g. transform 1U / x into x == 1U and later into x (because we assume that == type must be one of the above cases and when it is the same type as the type of the first operand, for boolean-ish cases it should be equivalent). Fixed by changing that (eq @1 { build_one_cst (type); }) into (convert (eq:boolean_type_node @1 { build_one_cst (type); })) Note, I'm not 100% sure if :boolean_type_node is required in that case, I see some spots in match.pd that look exactly like this, while there is e.g. (convert (le ...)) that supposedly does the right thing too. The signed integer 1/X case doesn't need changes changes, for (cond (le ...) ...) le gets correctly boolean_type_node and cond should use type. I've also reformatted it, some lines were too long, match.pd uses indentation by 1 column instead of 2 etc. 2022-01-29 Jakub Jelinek Andrew Pinski PR tree-optimization/104279 PR tree-optimization/104280 PR tree-optimization/104281 * match.pd (1 / X -> X == 1 for unsigned X): Build eq with boolean_type_node and convert to type. Formatting fixes. * gcc.dg/torture/pr104279.c: New test. * gcc.dg/torture/pr104280.c: New test. * gcc.dg/torture/pr104281.c: New test.
[Bug c++/88417] partial specialization of static template variable inside class template gives wrong result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88417 Fedor Chelnokov changed: What|Removed |Added CC||fchelnokov at gmail dot com --- Comment #3 from Fedor Chelnokov --- Even more reduced example. Below program is accepted in Clang and MSVC: ``` template struct Y { static constexpr T2 x{0}; }; template<> constexpr int Y::x{1}; int main() { static_assert(Y::x == 1); } ``` but GCC complains: ``` duplicate initialization of 'Y::x' ``` Demo: https://gcc.godbolt.org/z/TbP18z9Yq Related discussion: https://stackoverflow.com/q/53687873/7325599
[Bug tree-optimization/104280] [12 Regression] wrong code at -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104280 H.J. Lu changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #8 from H.J. Lu --- r12-6924 also caused: FAIL: gcc.dg/tree-ssa/divide-7.c scan-tree-dump optimized ".. <= 2 ? x_..D. : 0;" FAIL: libgomp.c++/pr86291.C execution test https://gcc.gnu.org/pipermail/gcc-regression/2022-January/076304.html
[Bug c++/104282] New: Copy elision when initializing a base-class subobject with aggregate initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104282 Bug ID: 104282 Summary: Copy elision when initializing a base-class subobject with aggregate initialization Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: fchelnokov at gmail dot com Target Milestone: --- The program ``` #include struct A { A() { std::cout << "A "; } A(const A&) { std::cout << "Acopy "; } A(A&&) { std::cout << "Amove "; } ~A() { std::cout << "~A "; } }; struct B : A { }; int main() { B b{ A{} }; } ``` if compiled by GCC, prints `A ~A `, showing that there is no copy/move of the temporary `A{}`. Clang prints on the other hand `A Amove ~A ~A `, which looks correct, because of "no elision when initializing a base-class subobject", see https://en.cppreference.com/w/cpp/language/copy_elision Demo: https://gcc.godbolt.org/z/rafEsTdd9
[Bug tree-optimization/104280] [12 Regression] wrong code at -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104280 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #7 from Jakub Jelinek --- Created attachment 52313 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52313=edit gcc12-pr104280.patch Untested fix for all 3 PRs. For the signed 1 / X case we don't need to change anything (except formatting), because genmatch for (cond (le ...) ...) already uses boolean_type_node for the comparison and COND_EXPR itself should have type.
[Bug tree-optimization/104280] [12 Regression] wrong code at -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104280 --- Comment #6 from Jakub Jelinek --- Actually you're right, we in fact enforce this: /* The resulting type of a comparison may be an effective boolean type. */ if (INTEGRAL_TYPE_P (type) && (TREE_CODE (type) == BOOLEAN_TYPE || TYPE_PRECISION (type) == 1)) ... /* Or a boolean vector type with the same element count as the comparison operand types. */ else if (TREE_CODE (type) == VECTOR_TYPE && TREE_CODE (TREE_TYPE (type)) == BOOLEAN_TYPE) ... else { error ("bogus comparison result type");
[Bug tree-optimization/104280] [12 Regression] wrong code at -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104280 --- Comment #5 from Jakub Jelinek --- (In reply to Andrew Pinski from comment #3) > (In reply to Jakub Jelinek from comment #2) > > To me this looks like a bug in gimple-fold.cc. > > The r12-6924-gc2b610e7c6c89fd4 simplifies > > _5 = 1 / c.0_4; > > into > > _5 = c.0_4 == 1; > > No this is not valid gimple as the comparisons always return a boolean type. > There needs to be a cast added. I don't think we ever say that, nor we enforce that. It is true that we don't fold _Bool _1; int _4; : _1 = a_2(D) == b_3(D); _4 = (int) _1; return _4; to just _4 = a_2(D) == b_3(D); return _4; though. And it is true that e.g. truth_valued_p would misbehave if the comparison/truth_* result is precision 1 signed integer (unless truth valued is defined as 0 or non-zero rather than 0 and 1). Certainly e.g. in Fortran EQ_EXPR etc. result doesn't need to be boolean_type_node, can be also any of the logical(kind=8) etc. types.
[Bug tree-optimization/104280] [12 Regression] wrong code at -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104280 --- Comment #4 from Andrew Pinski --- (eq @1 { build_one_cst (type); }) Should be: (convert (eq:boolean_type_node @1 { build_one_cst (type); })) The other part of the match pattern needs a similar fix too.
[Bug tree-optimization/104280] [12 Regression] wrong code at -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104280 --- Comment #3 from Andrew Pinski --- (In reply to Jakub Jelinek from comment #2) > To me this looks like a bug in gimple-fold.cc. > The r12-6924-gc2b610e7c6c89fd4 simplifies > _5 = 1 / c.0_4; > into > _5 = c.0_4 == 1; No this is not valid gimple as the comparisons always return a boolean type. There needs to be a cast added.
[Bug tree-optimization/104280] [12 Regression] wrong code at -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104280 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P1 Last reconfirmed||2022-01-29 CC||jakub at gcc dot gnu.org Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #2 from Jakub Jelinek --- To me this looks like a bug in gimple-fold.cc. The r12-6924-gc2b610e7c6c89fd4 simplifies _5 = 1 / c.0_4; into _5 = c.0_4 == 1; As it is unsigned division, that is perfectly fine. But then gimple-fold.cc's /* Try to canonicalize for boolean-typed X the comparisons X == 0, X == 1, X != 0, and X != 1. */ if (gimple_assign_rhs_code (stmt) == EQ_EXPR || gimple_assign_rhs_code (stmt) == NE_EXPR) { tree lhs = gimple_assign_lhs (stmt); tree op1 = gimple_assign_rhs1 (stmt); tree op2 = gimple_assign_rhs2 (stmt); tree type = TREE_TYPE (op1); /* Check whether the comparison operands are of the same boolean type as the result type is. Check that second operand is an integer-constant with value one or zero. */ if (TREE_CODE (op2) == INTEGER_CST && (integer_zerop (op2) || integer_onep (op2)) && useless_type_conversion_p (TREE_TYPE (lhs), type)) { enum tree_code cmp_code = gimple_assign_rhs_code (stmt); bool is_logical_not = false; /* X == 0 and X != 1 is a logical-not.of X X == 1 and X != 0 is X */ if ((cmp_code == EQ_EXPR && integer_zerop (op2)) || (cmp_code == NE_EXPR && integer_onep (op2))) is_logical_not = true; if (is_logical_not == false) gimple_assign_set_rhs_with_ops (gsi, TREE_CODE (op1), op1); /* Only for one-bit precision typed X the transformation !X -> ~X is valied. */ else if (TYPE_PRECISION (type) == 1) gimple_assign_set_rhs_with_ops (gsi, BIT_NOT_EXPR, op1); /* Otherwise we use !X -> X ^ 1. */ else gimple_assign_set_rhs_with_ops (gsi, BIT_XOR_EXPR, op1, build_int_cst (type, 1)); changed = true; break; } } kicks in and incorrectly "simplifies" it further into _5 = c.0_4; The comment talks about boolean type but nothing really checks that it is a boolean or precision 1 type, perhaps it expects that EQ_EXPR/NE_EXPR result must be boolean-ish, but that is not true. So, I think this optimization needs to be guarded on gimple_truth_valued_p (op1, valueize) but unfortunately while the function is not static inside of gimple-match.cc, it isn't declared in any header.
[Bug c++/54367] [meta-bug] lambda expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54367 Bug 54367 depends on bug 103929, which changed state. Bug 103929 Summary: False warning: no return statement in function returning non-void with lambda in template argument for non-class type as default template argument https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103929 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug c++/99902] Deduced return type of lambda in default template argument takes return type from variable template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99902 Andrew Pinski changed: What|Removed |Added CC||fchelnokov at gmail dot com --- Comment #1 from Andrew Pinski --- *** Bug 103929 has been marked as a duplicate of this bug. ***
[Bug c++/103929] False warning: no return statement in function returning non-void with lambda in template argument for non-class type as default template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103929 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #4 from Andrew Pinski --- Dup of bug 99902. *** This bug has been marked as a duplicate of bug 99902 ***
[Bug c++/104278] ICE with class non-type template parameter with a value depdenent constexpr call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104278 Andrew Pinski changed: What|Removed |Added Summary|ICE constexpr class |ICE with class non-type |non-type template parameter |template parameter with a ||value depdenent constexpr ||call Ever confirmed|0 |1 Last reconfirmed||2022-01-29 Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW --- Comment #2 from Andrew Pinski --- Confirmed reduced testcase: struct foo { int value; }; constexpr foo modify(foo) { return { 0 }; } template struct bar { static void run() { } }; template static void run() { bar::run(); } void h() { run(); } bar::run still needs to be in a templated class.
[Bug tree-optimization/104279] [12 Regregression] ICE on valid code at -O1 and above on x86_64-linux-gnu: verify_gimple failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104279 --- Comment #2 from Andrew Pinski --- I think this one and the other two are all caused by r12-6924.
[Bug tree-optimization/104281] [12 Regression] wrong code at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104281 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.0 Version|unknown |12.0
[Bug tree-optimization/104279] [12 Regregression] ICE on valid code at -O1 and above on x86_64-linux-gnu: verify_gimple failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104279 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.0 Version|unknown |12.0 Summary|ICE on valid code at -O1|[12 Regregression] ICE on |and above on|valid code at -O1 and above |x86_64-linux-gnu: |on x86_64-linux-gnu: |verify_gimple failed|verify_gimple failed
[Bug tree-optimization/104280] [12 Regression] wrong code at -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104280 Andrew Pinski changed: What|Removed |Added Version|unknown |12.0 Target Milestone|--- |12.0 Summary|wrong code at -O1 and above |[12 Regression] wrong code ||at -O1 and above
[Bug lto/104237] [11 Regression] Emitted binary code changes when -g is enabled at -O1 -flto and optimize attribute since r11-3126-ga8f9b4c54cc35062
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104237 --- Comment #10 from Jakub Jelinek --- Because -fcompare-debug tells the driver to compile the TU twice, once without and once with -gtoggle, and compare the result. So, if there is a difference in the generated IL e.g. for -flto -ffat-lto-objects, it will detect it. Just watch gcc -flto -O1 pr104237.c -o pr104237 -g -fcompare-debug -v 2>&1 | grep 'cc1\|lto1' to see that, cc1 is invoked twice, once without -gtoggle, once with it, but lto1 is invoked just twice, once for wpa and once for ltrans. Even if you convince the linker plugin to pass -fcompare-debug even to the driver that invokes lto1, that would again compare lto1 with and without -g but only on a single input (depending on whether the original command line has -g with or without debug stmts in it). To reproduce this bug, one needs to do a "manual -fcompare-debug", which is gcc -flto -O1 pr104237.c -o pr104237 -g // + force lto1 to pass -fdump-final-insns=1 gcc -flto -O1 pr104237.c -o pr104237 // + force lto1 to pass -fdump-final-insns=2 diff -up 1 2 Now, in theory the driver could arrange that, but it would only handle the trivial case when the compilation and linking are from the same command. Typically with LTO, compilation is done separately and linking is done separately, and I don't see how the driver could arrange for that to work, we need in that case two sets of *.o files with the IL, one with -g0 and one with -g, link twice and compare the result at the end.
[Bug tree-optimization/104281] wrong code at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104281 --- Comment #1 from Zhendong Su --- Compiler Explorer: https://godbolt.org/z/ovnrnEGj6
[Bug tree-optimization/104281] New: wrong code at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104281 Bug ID: 104281 Summary: wrong code at -O3 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zhendong.su at inf dot ethz.ch Target Milestone: --- It is a recent regression and likely related to PR 104280 and PR 104279, but it only reproduces at -O3. [537] % gcctk -v Using built-in specs. COLLECT_GCC=gcctk COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/12.0.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../gcc-trunk/configure --disable-bootstrap --prefix=/local/suz-local/software/local/gcc-trunk --enable-languages=c,c++ --disable-werror --enable-multilib --with-system-zlib Thread model: posix Supported LTO compression algorithms: zlib gcc version 12.0.1 20220129 (experimental) [master r12-6930-gf6f2d6cfec1] (GCC) [538] % [538] % gcctk -O2 small.c; ./a.out [539] % [539] % gcctk -O3 small.c [540] % timeout -s 9 5 ./a.out Killed [541] % [541] % cat small.c unsigned a = 1; int b, c = 2; long d; int main() { while (1) { int m = a; L: a = ~(-(m || b & d)); b = ((1 ^ a) / c); if (b) goto L; break; } return 0; }
[Bug tree-optimization/104280] wrong code at -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104280 --- Comment #1 from Zhendong Su --- It might be related to PR 104279. Compiler Explorer: https://godbolt.org/z/szrGT9E7T
[Bug tree-optimization/104280] New: wrong code at -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104280 Bug ID: 104280 Summary: wrong code at -O1 and above Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zhendong.su at inf dot ethz.ch Target Milestone: --- It is a recent regression. [548] % gcctk -v Using built-in specs. COLLECT_GCC=gcctk COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/12.0.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../gcc-trunk/configure --disable-bootstrap --prefix=/local/suz-local/software/local/gcc-trunk --enable-languages=c,c++ --disable-werror --enable-multilib --with-system-zlib Thread model: posix Supported LTO compression algorithms: zlib gcc version 12.0.1 20220129 (experimental) [master r12-6930-gf6f2d6cfec1] (GCC) [549] % [549] % gcctk -O0 small.c; ./a.out [550] % [550] % gcctk -O1 small.c [551] % ./a.out Aborted [552] % [552] % cat small.c int a(unsigned b, int c) { return b / c; } int main() { if (a(1, 2) != 0) __builtin_abort(); return 0; }
[Bug fortran/97024] Overriding finalization on polymorphic types triggers ICE error in generate_finalization_wrapper
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97024 Paul Thomas changed: What|Removed |Added CC||pault at gcc dot gnu.org --- Comment #4 from Paul Thomas --- (In reply to Dominique d'Humieres from comment #3) > Confirmed from GCC9 up to trunk. I am completely unable to reproduce the ICE on FC13/x86_64 with GNU Fortran (GCC) 9.3.1 20210315 through to mainline 12.0.1 20220119 (experimental). module m type::t1 end type t1 type,extends(t1)::t2 contains final::t2_finalize end type t2 contains subroutine t2_finalize(this) type(t2)::this print *, "finalize" end subroutine t2_finalize subroutine err() class(t1),allocatable::o1 type(t2)::o2 o1=o2 end subroutine err end module m use m call err end produces the expected output ("finalize" twice). Paul
[Bug tree-optimization/104279] ICE on valid code at -O1 and above on x86_64-linux-gnu: verify_gimple failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104279 --- Comment #1 from Zhendong Su --- >From Compiler Explorer: https://godbolt.org/z/465M9Kvx1
[Bug tree-optimization/104279] New: ICE on valid code at -O1 and above on x86_64-linux-gnu: verify_gimple failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104279 Bug ID: 104279 Summary: ICE on valid code at -O1 and above on x86_64-linux-gnu: verify_gimple failed Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zhendong.su at inf dot ethz.ch Target Milestone: --- It appears to be a recent regression. [551] % gcctk -v Using built-in specs. COLLECT_GCC=gcctk COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/12.0.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../gcc-trunk/configure --disable-bootstrap --prefix=/local/suz-local/software/local/gcc-trunk --enable-languages=c,c++ --disable-werror --enable-multilib --with-system-zlib Thread model: posix Supported LTO compression algorithms: zlib gcc version 12.0.1 20220129 (experimental) [master r12-6930-gf6f2d6cfec1] (GCC) [552] % [552] % gcctk -O0 small.c; ./a.out [553] % [553] % gcctk -O1 small.c small.c: In function ‘main’: small.c:6:1: error: bogus comparison result type 6 | } | ^ unsigned int _5 = a.1_3 == 4294967294; during GIMPLE pass: fre small.c:6:1: internal compiler error: verify_gimple failed 0xe52365 verify_gimple_in_cfg(function*, bool) ../../gcc-trunk/gcc/tree-cfg.cc:5559 0xce8ece execute_function_todo ../../gcc-trunk/gcc/passes.cc:2084 0xce9952 execute_todo ../../gcc-trunk/gcc/passes.cc:2138 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. [554] % [554] % cat small.c unsigned a, b; int main() { b = ~(0 || ~0); a = ~b / ~a; return 0; }
[Bug c++/104278] ICE constexpr class non-type template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104278 --- Comment #1 from Pubby8 --- Oops I forgot to include the template instantiation: // --- int main(int argc, char const** argv) { qux::run(); } // ---
[Bug c++/104278] New: ICE constexpr class non-type template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104278 Bug ID: 104278 Summary: ICE constexpr class non-type template parameter Product: gcc Version: 11.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: pubby.8 at gmail dot com Target Milestone: --- Getting ICE from the following code. The trigger seems to be the 'modify' function. // --- struct foo { int value; constexpr foo modify() const { return { value + 1 }; } }; template struct bar { static void run() { } }; template struct qux { static void run() { bar::run(); } }; // --- Error: test.cpp: In instantiation of ‘static void qux::run() [with foo f = foo(); bool Enable = false]’: test.cpp:25:16: required from here test.cpp:7:33: internal compiler error: in tsubst_copy, at cp/pt.c:16939 7 | template | ~~^ 0x1797368 internal_error(char const*, ...) ???:0 0x67f8f9 fancy_abort(char const*, int, char const*) ???:0 0x7fa400 tsubst_template_args(tree_node*, tree_node*, int, tree_node*) ???:0 0x7ea4ef instantiate_decl(tree_node*, bool, bool) ???:0 0x80659b instantiate_pending_templates(int) ???:0 0x7136c0 c_parse_final_cleanups() ???:0