[Bug tree-optimization/105189] [9/10 Regression] Wrong code with -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105189 Jakub Jelinek changed: What|Removed |Added Summary|[9/10/11 Regression] Wrong |[9/10 Regression] Wrong |code with -O1 |code with -O1 --- Comment #8 from Jakub Jelinek --- Fixed also for 11.3.
[Bug middle-end/105253] __popcountdi2 calls generated in kernel code with gcc12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105253 --- Comment #3 from Khem Raj --- (In reply to Andrew Pinski from comment #1) > Two things. First the error message is for arm target but you then reference > x86_64 target options. > > Second there is a loop for popcount which gets translated but that was > guarded by a check for optab for popcount existing but maybe that changed. yes the issue is seen on both arm and x86_64, So test case is from x86_64 but the error message is from arm build. I can reduce that too tomorrow. Its with -O2, I have a shell script in tarball which has all the options used to compile.
[Bug middle-end/105253] __popcountdi2 calls generated in kernel code with gcc12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105253 Andrew Pinski changed: What|Removed |Added See Also||https://bugzilla.kernel.org ||/show_bug.cgi?id=200671 --- Comment #2 from Andrew Pinski --- https://bugzilla.kernel.org/show_bug.cgi?id=200671 Looks like a bug was filed in the kernel for this but no action. Is this with -Os?
[Bug middle-end/105253] __popcountdi2 calls generated in kernel code with gcc12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105253 Andrew Pinski changed: What|Removed |Added Target|x86_64 | --- Comment #1 from Andrew Pinski --- Two things. First the error message is for arm target but you then reference x86_64 target options. Second there is a loop for popcount which gets translated but that was guarded by a check for optab for popcount existing but maybe that changed.
[Bug tree-optimization/105237] Missing uninitialized warning in self-initialization case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105237 Eric Gallager changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=53129, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=90043 Keywords||diagnostic CC||egallager at gcc dot gnu.org --- Comment #3 from Eric Gallager --- (In reply to Andrew Pinski from comment #2) > Note: > int n = n; > Is a documented way of having the uninitiated warning to not happen. ...although there are requests for a separate flag to warn in cases like that, e.g. bug 53129 (see also bug 90043 too)
[Bug c/105253] New: __popcountdi2 calls generated in kernel code with gcc12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105253 Bug ID: 105253 Summary: __popcountdi2 calls generated in kernel code with gcc12 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: raj.khem at gmail dot com Target Milestone: --- Created attachment 52794 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52794=edit test case gcc 12 when using -march=core2 generates __popcountdi2 calls which go unresolved in kernel and build fails. When I use -march=corei7 then the calls are optimized away. Interestingly, gcc-11 did not emit these calls even with -march=core2, a similar error is seen when compiling kernel for arm arm-yoe-linux-gnueabi-ld.bfd: arch/arm/probes/kprobes/actions-common.o: in function `simulate_ldm1stm1': actions-common.c:(.kprobes.text+0x74): undefined reference to `__popcountsi2' Attached testcase demonstrates the behaviour on x86_64. Is it expected behavior in gcc 12 ?
[Bug target/105247] [11/12 Regression] IA64: ICE on sqlite-3.38.2: in decompose, at rtl.h:2288 since r11-5271-g4866b2f5db117f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105247 Martin Liška changed: What|Removed |Added Target Milestone|--- |11.3
[Bug target/105247] [11/12 Regression] IA64: ICE on sqlite-3.38.2: in decompose, at rtl.h:2288 since r11-5271-g4866b2f5db117f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105247 Martin Liška changed: What|Removed |Added Summary|IA64: ICE on sqlite-3.38.2: |[11/12 Regression] IA64: |in decompose, at rtl.h:2288 |ICE on sqlite-3.38.2: in ||decompose, at rtl.h:2288 ||since ||r11-5271-g4866b2f5db117f CC||jakub at gcc dot gnu.org, ||marxin at gcc dot gnu.org Last reconfirmed||2022-04-13 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Started with r11-5271-g4866b2f5db117f.
[Bug analyzer/105252] New: [12 Regression] ICE: in cmp_cst, at analyzer/svalue.cc:309 with -O -fanalyzer -fnon-call-exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105252 Bug ID: 105252 Summary: [12 Regression] ICE: in cmp_cst, at analyzer/svalue.cc:309 with -O -fanalyzer -fnon-call-exceptions Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Created attachment 52793 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52793=edit reduced testcase Compiler output: $ x86_64-pc-linux-gnu-gcc -O -fanalyzer -fnon-call-exceptions testcase.c during IPA pass: analyzer In function 'bar', inlined from 'foo' at testcase.c:17:3: testcase.c:9:5: internal compiler error: in cmp_cst, at analyzer/svalue.cc:309 9 | v %= (c | v) % m; | ^~ 0x82fef8 cmp_cst /repo/gcc-trunk/gcc/analyzer/svalue.cc:309 0x17a8abf cmp_cst /repo/gcc-trunk/gcc/analyzer/svalue.cc:340 0x17a8f03 ana::svalue::cmp_ptr(ana::svalue const*, ana::svalue const*) /repo/gcc-trunk/gcc/analyzer/svalue.cc:428 0x2543d40 cmp1 /repo/gcc-trunk/gcc/sort.cc:153 0x2543d94 netsort /repo/gcc-trunk/gcc/sort.cc:170 0x2543d94 mergesort /repo/gcc-trunk/gcc/sort.cc:207 0x254431f gcc_qsort(void*, unsigned long, unsigned long, int (*)(void const*, void const*)) /repo/gcc-trunk/gcc/sort.cc:266 0x17417ed vec::qsort(int (*)(void const*, void const*)) /repo/gcc-trunk/gcc/vec.h:1147 0x17417ed vec::qsort(int (*)(void const*, void const*)) /repo/gcc-trunk/gcc/vec.h:2121 0x17417ed ana::program_state::detect_leaks(ana::program_state const&, ana::program_state const&, ana::svalue const*, ana::extrinsic_state const&, ana::region_model_context*) /repo/gcc-trunk/gcc/analyzer/program-state.cc:1420 0x1741b66 ana::program_state::prune_for_point(ana::exploded_graph&, ana::program_point const&, ana::exploded_node*, ana::uncertainty_t*) const /repo/gcc-trunk/gcc/analyzer/program-state.cc:1214 0x172f78f ana::exploded_graph::process_node(ana::exploded_node*) /repo/gcc-trunk/gcc/analyzer/engine.cc:3780 0x1730622 ana::exploded_graph::process_worklist() /repo/gcc-trunk/gcc/analyzer/engine.cc:3198 0x1732b27 ana::impl_run_checkers(ana::logger*) /repo/gcc-trunk/gcc/analyzer/engine.cc:5777 0x17339be ana::run_checkers() /repo/gcc-trunk/gcc/analyzer/engine.cc:5851 0x1722f48 execute /repo/gcc-trunk/gcc/analyzer/analyzer-pass.cc:87 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. $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r12-8113-20220412190241-gaa7874596b9-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/12.0.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r12-8113-20220412190241-gaa7874596b9-checking-yes-rtl-df-extra-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 12.0.1 20220412 (experimental) (GCC)
[Bug target/105214] [12 Regression] ICE: in connect_traces, at dwarf2cfi.cc:3074 with custom flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105214 --- Comment #8 from CVS Commits --- The releases/gcc-11 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:5b87d9f50b421e18be2a4ef95548182c8af2891e commit r11-9849-g5b87d9f50b421e18be2a4ef95548182c8af2891e Author: Jakub Jelinek Date: Tue Apr 12 09:19:11 2022 +0200 i386: Fix ICE caused by ix86_emit_i387_log1p [PR105214] The following testcase ICEs, because ix86_emit_i387_log1p attempts to emit something like if (cond) some_code1; else some_code2; and emits a conditional jump using emit_jump_insn (standard way in the file) and an unconditional jump using emit_jump. The problem with that is that if there is pending stack adjustment, it isn't emitted before the conditional jump, but is before the unconditional jump and therefore stack is adjusted only conditionally (at the end of some_code1 above), which makes dwarf2 pass unhappy about it but is a serious wrong-code even if it doesn't ICE. This can be fixed either by emitting pending stack adjust before the conditional jump as the following patch does, or by not using emit_jump (label2); and instead hand inlining what that function does except for the pending stack adjustment, like: emit_jump_insn (targetm.gen_jump (label2)); emit_barrier (); In that case there will be no stack adjustment in the sequence and it will be done later on somewhere else. 2022-04-12 Jakub Jelinek PR target/105214 * config/i386/i386-expand.c (ix86_emit_i387_log1p): Call do_pending_stack_adjust. * gcc.dg/asan/pr105214.c: New test. (cherry picked from commit d481d13786cb84f6294833538133dbd6f39d2e55)
[Bug rtl-optimization/105211] ICE: SIGSEGV in contains_struct_check (tree.h:3570) with -Os -ffast-math and __builtin_roundf()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105211
--- Comment #5 from CVS Commits ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:1e4dd03e3a39c65aa5d75df7dd51f4b7fbcc8daa
commit r11-9848-g1e4dd03e3a39c65aa5d75df7dd51f4b7fbcc8daa
Author: Jakub Jelinek
Date: Tue Apr 12 09:16:06 2022 +0200
builtins: Fix up expand_builtin_int_roundingfn_2 [PR105211]
The expansion of __builtin_iround{,f,l} etc. builtins in some cases
emits calls to a different fallback builtin. To locate the right builtin
it uses mathfn_built_in_1 with the type of the first argument.
If its TYPE_MAIN_VARIANT is {float,double,long_double}_type_node, all is
fine, but on the following testcase, because GIMPLE considers scalar
float conversions between types with the same mode as useless,
TYPE_MAIN_VARIANT of the arg's type is float32_type_node and because there
isn't __builtin_lroundf32 returns NULL and we ICE.
This patch will first try the type of the first argument of the builtin's
prototype (so that say on sizeof(double)==sizeof(long double) target it
honors
whether it was a *l or non-*l call; though even that can't be 100% trusted,
user could incorrectly prototype it) and as fallback the type argument.
If neither works, doesn't fallback.
2022-04-11 Jakub Jelinek
PR rtl-optimization/105211
* builtins.c (expand_builtin_int_roundingfn_2): If
mathfn_built_in_1
fails for TREE_TYPE (arg), retry it with
TREE_VALUE (TYPE_ARG_TYPES (TREE_TYPE (fndecl))) and if even that
fails, emit call normally.
* gcc.dg/pr105211.c: New test.
(cherry picked from commit 91a38e8a848c61b2e23ee277306dc8cd194d135b)
[Bug c++/105186] [9/10/11 Regression] ICE in canonicalize_attr_name, at attribs.h:146
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105186 --- Comment #6 from CVS Commits --- The releases/gcc-11 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:473f2b099bdb3e72591b37f42e566086792f453d commit r11-9847-g473f2b099bdb3e72591b37f42e566086792f453d Author: Jakub Jelinek Date: Mon Apr 11 10:41:07 2022 +0200 c-family: Initialize ridpointers for __int128 etc. [PR105186] The following testcase ICEs with C++ and is incorrectly rejected with C. The reason is that both FEs use ridpointers identifiers for CPP_KEYWORD and value or u.value for CPP_NAME e.g. when parsing attributes or OpenMP directives etc., like: /* Save away the identifier that indicates which attribute this is. */ identifier = (token->type == CPP_KEYWORD) /* For keywords, use the canonical spelling, not the parsed identifier. */ ? ridpointers[(int) token->keyword] : id_token->u.value; identifier = canonicalize_attr_name (identifier); I've tried to change those to use ridpointers only if non-NULL and otherwise use the value/u.value even for CPP_KEYWORDS, but that was a large 10 hunks patch. The following patch instead just initializes ridpointers for the __intNN keywords. It can't be done earlier before we record_builtin_type as there are 2 different spellings and if we initialize those ridpointers early, the second record_builtin_type fails miserably. 2022-04-11 Jakub Jelinek PR c++/105186 * c-common.c (c_common_nodes_and_builtins): After registering __int%d and __int%d__ builtin types, initialize corresponding ridpointers entry. * c-c++-common/pr105186.c: New test. (cherry picked from commit 083e8e66d2e90992fa83a53bfc3553dfa91abda1)
[Bug tree-optimization/105189] [9/10/11 Regression] Wrong code with -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105189 --- Comment #7 from CVS Commits --- The releases/gcc-11 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:b28307530ecb4d6aea2328fb3e670068e3275868 commit r11-9846-gb28307530ecb4d6aea2328fb3e670068e3275868 Author: Jakub Jelinek Date: Fri Apr 8 09:14:44 2022 +0200 fold-const: Fix up make_range_step [PR105189] The following testcase is miscompiled, because fold_truth_andor incorrectly folds (unsigned) foo () >= 0U && 1 into foo () >= 0 For the unsigned comparison (which is useless in this case, as >= 0U is always true, but hasn't been folded yet), previous make_range_step derives exp (unsigned) foo () and +[0U, -] range for it. Next we process the NOP_EXPR. We have special code for unsigned to signed casts, already earlier punt if low or high aren't representable in arg0_type or if it is a narrowing conversion. For the signed to unsigned casts, I think if high is specified we are still fine, as we punt for non-representable values in arg0_type, n_high is then still representable and so was smaller or equal to signed maximum and either low is not present (equivalent to 0U), or low must be smaller or equal to high and so for unsigned exp +[low, high] the signed exp +[n_low, n_high] will be correct. Similarly, if both low and high aren't specified (always true or always false), it is ok too. But if we have for unsigned exp +[low, -] or -[low, -], using +[n_low, -] or -[n_high, -] is incorrect. Because low is smaller or equal to signed maximum and high is unspecified (i.e. unsigned maximum), when signed that range is a union of +[n_low, -] and +[-, -1] which is equivalent to -[0, n_low-1], unless low is 0, in that case we can treat it as [-, -]. 2022-04-08 Jakub Jelinek PR tree-optimization/105189 * fold-const.c (make_range_step): Fix up handling of (unsigned) x +[low, -] ranges for signed x if low fits into typeof (x). * g++.dg/torture/pr105189.C: New test. (cherry picked from commit 5e6597064b0c7eb93b8f720afc4aa970eefb0628)
[Bug rtl-optimization/104985] [12 Regression] ICE: SIGSEGV in undo_to_marker / adjust_reg_mode with -Os -frounding-math since r12-4767-g81342e95827f77
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104985 --- Comment #19 from CVS Commits --- The releases/gcc-11 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:a487dbd802d71bcea8feaa41defde92a6848d0c6 commit r11-9845-ga487dbd802d71bcea8feaa41defde92a6848d0c6 Author: Jakub Jelinek Date: Wed Apr 6 18:42:52 2022 +0200 combine: Don't record for UNDO_MODE pointers into regno_reg_rtx array [PR104985] The testcase in the PR fails under valgrind on mips64 (but only Martin can reproduce, I couldn't). But the problem reported there is that SUBST_MODE remembers addresses into the regno_reg_rtx array, then some splitter needs a new pseudo and calls gen_reg_rtx, which reallocates the regno_reg_rtx array and finally undo operation is done and dereferences the old regno_reg_rtx entry. The rtx values stored in regno_reg_rtx array seems to be created by gen_reg_rtx only and since then aren't modified, all we do for it is adjusting its fields (e.g. adjust_reg_mode that SUBST_MODE does). So, I think it is useless to use where.r for UNDO_MODE and store _reg_rtx[regno] in struct undo, we can store just regno_reg_rtx[regno] (i.e. pointer to the REG itself instead of pointer to pointer to REG) or could also store just the regno. The following patch does the latter, and because SUBST_MODE no longer needs to be a macro, changes all SUBST_MODE uses to subst_mode. 2022-04-06 Jakub Jelinek PR rtl-optimization/104985 * combine.c (struct undo): Add where.regno member. (do_SUBST_MODE): Rename to ... (subst_mode): ... this. Change first argument from rtx * into int, operate on regno_reg_rtx[regno] and save regno into where.regno. (SUBST_MODE): Remove. (try_combine): Use subst_mode instead of SUBST_MODE, change first argument from regno_reg_rtx[whatever] to whatever. For UNDO_MODE, use regno_reg_rtx[undo->where.regno] instead of *undo->where.r. (undo_to_marker): For UNDO_MODE, use regno_reg_rtx[undo->where.regno] instead of *undo->where.r. (simplify_set): Use subst_mode instead of SUBST_MODE, change first argument from regno_reg_rtx[whatever] to whatever. (cherry picked from commit 61bee6aed26eb30b798c75b9a595c9d51e080442)
[Bug target/105234] [12 Regression] inlining failed in call to 'always_inline' 'memset': target specific option mismatch since r12-5920-g01ad8c54fdca1d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105234 --- Comment #13 from Kewen Lin --- Just noticed this, many thanks for triaging and fixing!
[Bug target/102146] [11 regression] several test cases fails after r11-8940
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102146 --- Comment #7 from CVS Commits --- The master branch has been updated by Alexandre Oliva : https://gcc.gnu.org/g:6b7cc7294770ecb57c0f3a116a27ce1aaff170b5 commit r12-8128-g6b7cc7294770ecb57c0f3a116a27ce1aaff170b5 Author: Alexandre Oliva Date: Tue Apr 12 22:41:45 2022 -0300 ppc: testsuite: PROMOTE_MODE fallout pr56605 [PR102146] The test expects a compare of DImode values, but after the removal of PROMOTE_MODE from rs6000/, we get SImode. Adjust the expectations. for gcc/testsuite/ChangeLog PR target/102146 * gcc.target/powerpc/pr56605.c: Accept SImode compare operand.
[Bug c++/103105] [11 Regression] ICE iterative_hash_template_arg with concepts and varagrs template since r11-3261-gb28b621ac67beee8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103105 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Patrick Palka --- Fixed for GCC 11.3/12.
[Bug c++/101532] [12 Regression] ICE in finish_expr_stmt, at cp/semantics.c:859
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101532 Patrick Palka changed: What|Removed |Added Target Milestone|12.0|11.3
[Bug c++/103341] [11 Regression] ICE type of variable instantiation constrained on template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103341 Patrick Palka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Patrick Palka --- Fixed for GCC 11.3/12.
[Bug c++/103105] [11 Regression] ICE iterative_hash_template_arg with concepts and varagrs template since r11-3261-gb28b621ac67beee8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103105 Bug 103105 depends on bug 103706, which changed state. Bug 103706 Summary: [11 Regression] ICE: tree check: accessed elt 1 of 'tree_vec' with 0 elts in hash, at cp/constraint.cc:2503 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103706 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/103706] [11 Regression] ICE: tree check: accessed elt 1 of 'tree_vec' with 0 elts in hash, at cp/constraint.cc:2503
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103706 Patrick Palka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Patrick Palka --- Fixed for GCC 11.3/12.
[Bug c++/104507] [10/11 Regression] internal compiler error: unexpected expression ‘(int)(__ret)’ of kind cast_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104507 --- Comment #9 from CVS Commits --- The releases/gcc-11 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:c8aaa9cca96207b5674048972c82a338ef81ce7e commit r11-9843-gc8aaa9cca96207b5674048972c82a338ef81ce7e Author: Patrick Palka Date: Wed Feb 16 12:41:35 2022 -0500 c++: treat NON_DEPENDENT_EXPR as not potentially constant [PR104507] Here we're crashing from potential_constant_expression because it tries to perform trial evaluation of the first operand '(bool)__r' of the conjunction (which is overall wrapped in a NON_DEPENDENT_EXPR), but cxx_eval_constant_expression ICEs on unsupported trees (of which CAST_EXPR is one). The sequence of events is: 1. build_non_dependent_expr for the array subscript yields NON_DEPENDENT_EXPR<<<(bool)__r && __s>>> ? 1 : 2 2. cp_build_array_ref calls fold_non_dependent_expr on this subscript (after this point, processing_template_decl is cleared) 3. during which, the COND_EXPR case of tsubst_copy_and_build calls fold_non_dependent_expr on the first operand 4. during which, we crash from p_c_e_1 because it attempts trial evaluation of the CAST_EXPR '(bool)__r'. Note that even if this crash didn't happen, fold_non_dependent_expr from cp_build_array_ref would still ultimately be one big no-op here since neither constexpr evaluation nor tsubst handle NON_DEPENDENT_EXPR. In light of this and of the observation that we should never see NON_DEPENDENT_EXPR in a context where a constant expression is needed (it's used primarily in the build_x_* family of functions), it seems futile for p_c_e_1 to ever return true for NON_DEPENDENT_EXPR. And the otherwise inconsistent handling of NON_DEPENDENT_EXPR between p_c_e_1, cxx_evaluate_constexpr_expression and tsubst apparently leads to weird bugs such as this one. PR c++/104507 gcc/cp/ChangeLog: * constexpr.c (potential_constant_expression_1) : Return false instead of recursing. Assert tf_error isn't set. gcc/testsuite/ChangeLog: * g++.dg/template/non-dependent21.C: New test. (cherry picked from commit c19f317a78c0e4c1b51d0e5a8e4c0a3b985b7a8e)
[Bug c++/103706] [11 Regression] ICE: tree check: accessed elt 1 of 'tree_vec' with 0 elts in hash, at cp/constraint.cc:2503
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103706 --- Comment #10 from CVS Commits --- The releases/gcc-11 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:6eb8eb51a827a349cd6acce5f16ffef31d8934b1 commit r11-9842-g6eb8eb51a827a349cd6acce5f16ffef31d8934b1 Author: Patrick Palka Date: Tue Feb 8 08:46:13 2022 -0500 c++: constrained auto in lambda using outer tparms [PR103706] Here we're crashing during satisfaction of the lambda's placeholder type constraints because the constraints depend on the template arguments from the enclosing scope, which aren't part of the lambda's DECL_TI_ARGS. This patch fixes this by making do_auto_deduction consider the "regenerating" template arguments of a lambda for satisfaction, mirroring what's done in satisfy_declaration_constraints. PR c++/103706 gcc/cp/ChangeLog: * constraint.cc (satisfy_declaration_constraints): Use lambda_regenerating_args instead. * cp-tree.h (lambda_regenerating_args): Declare. * pt.c (lambda_regenerating_args): Define, split out from satisfy_declaration_constraints. (do_auto_deduction): Use lambda_regenerating_args to obtain the full set of outer template arguments for satisfaction when inside a lambda. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/concepts-lambda18.C: New test. (cherry picked from commit 34ba3d9a2bf72742b1c150a2dd17d10e3e3f0964)
[Bug c++/103341] [11 Regression] ICE type of variable instantiation constrained on template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103341 --- Comment #8 from CVS Commits --- The releases/gcc-11 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:12b11107edfcde6a16ec397a9120687a14254215 commit r11-9841-g12b11107edfcde6a16ec397a9120687a14254215 Author: Patrick Palka Date: Fri Jan 28 08:18:28 2022 -0500 c++: var tmpl w/ dependent constrained auto type [PR103341] When deducing the type of a variable template (or templated static data member) with a constrained auto type, we might need its template arguments for satisfaction since the constraint could depend on them. PR c++/103341 gcc/cp/ChangeLog: * decl.c (cp_finish_decl): Pass the template arguments of a variable template specialization or a templated static data member to do_auto_deduction when the auto is constrained. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/concepts-class4.C: New test. * g++.dg/cpp2a/concepts-var-templ2.C: New test. (cherry picked from commit e272cf95ba048fde60b21aee046c9ca9c9264425)
[Bug c++/104225] [9/10/11 Regression] accepts-invalid new expression that uses deleted implicit default constructor of class specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104225 --- Comment #5 from CVS Commits --- The releases/gcc-11 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:1429db66619d2b801ac0b586b5eed74ab54a35b0 commit r11-9840-g1429db66619d2b801ac0b586b5eed74ab54a35b0 Author: Patrick Palka Date: Tue Jan 25 15:04:49 2022 -0500 c++: deleted fn and noexcept inst [PR101532, PR104225] Here when attempting to use B's implicitly deleted default constructor, mark_used rightfully returns false, but for the wrong reason: it tries to instantiate the synthesized noexcept specifier which then only silently fails because get_defaulted_eh_spec suppresses diagnostics for deleted functions. This lack of diagnostics causes us to crash on the first testcase below (thanks to the assert in finish_expr_stmt), and silently accept the second testcase. To fix this, this patch makes mark_used avoid attempting to instantiate the noexcept specifier of a deleted function, so that we'll instead directly reject (and diagnose) the function due to its deletedness. PR c++/101532 PR c++/104225 gcc/cp/ChangeLog: * decl2.c (mark_used): Don't consider maybe_instantiate_noexcept on a deleted function. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/nsdmi-template21.C: New test. * g++.dg/cpp0x/nsdmi-template21a.C: New test. (cherry picked from commit bc90dd0ecf02e11d47d1af7f627e2e2acaa40106)
[Bug c++/101532] [12 Regression] ICE in finish_expr_stmt, at cp/semantics.c:859
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101532 --- Comment #6 from CVS Commits --- The releases/gcc-11 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:1429db66619d2b801ac0b586b5eed74ab54a35b0 commit r11-9840-g1429db66619d2b801ac0b586b5eed74ab54a35b0 Author: Patrick Palka Date: Tue Jan 25 15:04:49 2022 -0500 c++: deleted fn and noexcept inst [PR101532, PR104225] Here when attempting to use B's implicitly deleted default constructor, mark_used rightfully returns false, but for the wrong reason: it tries to instantiate the synthesized noexcept specifier which then only silently fails because get_defaulted_eh_spec suppresses diagnostics for deleted functions. This lack of diagnostics causes us to crash on the first testcase below (thanks to the assert in finish_expr_stmt), and silently accept the second testcase. To fix this, this patch makes mark_used avoid attempting to instantiate the noexcept specifier of a deleted function, so that we'll instead directly reject (and diagnose) the function due to its deletedness. PR c++/101532 PR c++/104225 gcc/cp/ChangeLog: * decl2.c (mark_used): Don't consider maybe_instantiate_noexcept on a deleted function. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/nsdmi-template21.C: New test. * g++.dg/cpp0x/nsdmi-template21a.C: New test. (cherry picked from commit bc90dd0ecf02e11d47d1af7f627e2e2acaa40106)
[Bug c++/103105] [11 Regression] ICE iterative_hash_template_arg with concepts and varagrs template since r11-3261-gb28b621ac67beee8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103105
--- Comment #5 from CVS Commits ---
The releases/gcc-11 branch has been updated by Patrick Palka
:
https://gcc.gnu.org/g:051d304ce8e2173bd0cb721ed91d4a1fefa61d87
commit r11-9839-g051d304ce8e2173bd0cb721ed91d4a1fefa61d87
Author: Patrick Palka
Date: Tue Apr 12 12:58:18 2022 -0400
c++: requires-expr in pack expansion using pack [PR103105]
Here after dependent substitution of {Ts...} into the alias 'wrap',
since we never partially instantiate a requires-expr, we end up with a
requires-expr whose REQUIRES_EXPR_EXTRA_ARGS contains an
ARGUMENT_PACK_SELECT (which just resolves to the parameter pack Ts).
Then when hashing the resulting dependent specialization of A, we crash
from iterative_hash_template_arg since it deliberately doesn't handle
ARGUMENT_PACK_SELECT.
Like in r12-7102-gdb5f1c17031ad8, it seems the right fix here is to
resolve ARGUMENT_PACK_SELECT arguments before storing them into an
extra args tree (such as REQUIRES_EXPR).
PR c++/103105
gcc/cp/ChangeLog:
* pt.c (build_extra_args): Call preserve_args.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/concepts-requires29.C: New test.
* g++.dg/cpp2a/concepts-requires29a.C: New test.
(cherry picked from commit e2c7070ac7740508a7c49bfee9f895e216a272d6)
[Bug c++/103706] [11 Regression] ICE: tree check: accessed elt 1 of 'tree_vec' with 0 elts in hash, at cp/constraint.cc:2503
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103706 --- Comment #9 from CVS Commits --- The releases/gcc-11 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:d3950a70da6814206eef1946c289b5652ecc9986 commit r11-9838-gd3950a70da6814206eef1946c289b5652ecc9986 Author: Patrick Palka Date: Tue Feb 8 08:46:32 2022 -0500 c++: lambda in pack expansion using pack in constraint [PR103706] Here when expanding the pack expansion pattern containing a constrained lambda, the template argument for each Ts is an ARGUMENT_PACK_SELECT, which we store inside the lambda's LAMBDA_EXPR_REGEN_INFO. Then during satisfaction of the lambda's constraint C the satisfaction cache uses this argument as part of the key to the corresponding sat_entry, but iterative_hash_template_arg and template_args_equal deliberately don't handle ARGUMENT_PACK_SELECT. Since it's wrong to preserve ARGUMENT_PACK_SELECT inside a hash table due to its instability (as documented in iterative_hash_template_arg), this patch helps make sure the satisfaction cache doesn't see such trees by resolving ARGUMENT_PACK_SELECT arguments before adding them to LAMBDA_EXPR_REGEN_INFO. PR c++/103706 gcc/cp/ChangeLog: * pt.c (preserve_args): New function. (tsubst_lambda_expr): Use it when setting LAMBDA_EXPR_REGEN_INFO. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/concepts-lambda19.C: New test. (cherry picked from commit db5f1c17031ad8a898d77121f1e0e0141306e22a)
[Bug target/105251] static assert sizeof(decltype(_together)) <= hardware_constructive_interference_size fails with gcc12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105251 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Andrew Pinski --- Why do you think this is a bug in GCC? The definition: hardware_destructive_interference_size: Minimum offset between two objects to avoid false sharing hardware_constructive_interference_size : Maximum size of contiguous memory to promote true sharing In aarch64, the sizes are defaulting to 256/64 as the max cache line size is 256 while the normal cache line size is 64. I don't see this as a bug in GCC. The code is assuming false definitions of these values.
[Bug target/105251] static assert sizeof(decltype(_together)) <= hardware_constructive_interference_size fails with gcc12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105251 --- Comment #2 from Jonathan Wakely --- (In reply to Khem Raj from comment #0) > This testcase below fails to compile with gcc12 on aarch64 but works ok with > gcc11 [...] > #ifdef __cpp_lib_hardware_interference_size > using std::hardware_constructive_interference_size; > using std::hardware_destructive_interference_size; Not a bug. This is defined for GCC 12, and your assumption about the destructive size is wrong. It's 256 for aarch64. See https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Winterference-size for relevant options.
[Bug target/105251] static assert sizeof(decltype(_together)) <= hardware_constructive_interference_size fails with gcc12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105251 Andrew Pinski changed: What|Removed |Added Component|c++ |target --- Comment #1 from Andrew Pinski --- Right hardware_destructive_interference_size is 256 while hardware_constructive_interference_size is 64.
[Bug c++/105251] New: static assert sizeof(decltype(_together)) <= hardware_constructive_interference_size fails with gcc12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105251
Bug ID: 105251
Summary: static assert sizeof(decltype(_together)) <=
hardware_constructive_interference_size fails with
gcc12
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: raj.khem at gmail dot com
Target Milestone: ---
This testcase below fails to compile with gcc12 on aarch64 but works ok with
gcc11
gcc12
=
$ aarch64-yoe-linux-musl-g++
--sysroot=/mnt/b/yoe/master/build/tmp/work/cortexa72-yoe-linux-musl/mongodb/4.4.13-r0/recipe-sysroot
a.cpp -std=c++17
a.cpp:35:47: error: static assertion failed: cache line spill
35 | static_assert(sizeof(decltype(_together)) <=
hardware_constructive_interference_size,
|
^~
a.cpp:35:47: note: the comparison reduces to '(256 <= 64)'
=
a.cpp
=
#include
#include
#include
#include
#ifdef __cpp_lib_hardware_interference_size
using std::hardware_constructive_interference_size;
using std::hardware_destructive_interference_size;
#else
// 64 bytes on x86-64 │ L1_CACHE_BYTES │ L1_CACHE_SHIFT │
__cacheline_aligned │ ...
constexpr std::size_t hardware_constructive_interference_size = 64;
constexpr std::size_t hardware_destructive_interference_size = 64;
#endif
class NetworkCounter {
private:
template
struct alignas(alignment) WithAlignment : T {
using T::T;
};
template
using WithAlignmentAtLeast = WithAlignment;
// These two counters are always incremented at the same time, so
// we place them on the same cache line.
template
using CacheAligned = WithAlignmentAtLeast;
struct Together {
long long logicalBytesIn{0};
long long requests{0};
};
CacheAligned _together{};
static_assert(sizeof(decltype(_together)) <=
hardware_constructive_interference_size,
"cache line spill");
};
[Bug libbacktrace/105240] backtrace_pcinfo leaks memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105240 --- Comment #5 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:3c742621ed28540cf42d4cfbc2bf03433cd26738 commit r12-8125-g3c742621ed28540cf42d4cfbc2bf03433cd26738 Author: Jonathan Wakely Date: Tue Apr 12 17:56:45 2022 +0100 libstdc++: Prefer to use mmap instead of malloc in libbacktrace As reported in PR libbacktrace/105240, libbacktrace leaks memory when using malloc for allocations. I originally thought it would be simpler to just use malloc unconditionally (because it's supported on all targets) but the leaks make that problematic. This adds libbacktrace's detection for mmap to the libstdc++ configury, so that we use mmap.c and mmapio.c when possible. This avoids the leaks seen previously, at least on linux. libstdc++-v3/ChangeLog: * acinclude.m4 (GLIBCXX_ENABLE_BACKTRACE): Check for mmap. * config.h.in: Regenerate. * configure: Regenerate.
[Bug jit/104293] Add support for setting the alignment of variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104293 --- Comment #1 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:6e5ad1cc24a315d07f24c95d76c269cafe2a8182 commit r12-8120-g6e5ad1cc24a315d07f24c95d76c269cafe2a8182 Author: Antoni Boucher Date: Tue Apr 12 17:25:04 2022 -0400 libgccjit: Add support for setting the alignment [PR104293] gcc/jit/ PR jit/104293 * docs/_build/texinfo/libgccjit.texi: Regenerate. * docs/topics/compatibility.rst (LIBGCCJIT_ABI_24): New ABI tag. * docs/topics/expressions.rst: Add documentation for the functions gcc_jit_lvalue_set_alignment and gcc_jit_lvalue_get_alignment. * jit-playback.h: New function (set_alignment). * jit-recording.cc: New function (set_alignment). * jit-recording.h: New functions (set_alignment, get_alignment) and new field (m_alignment). * libgccjit.cc: New functions (gcc_jit_lvalue_get_alignment, gcc_jit_lvalue_set_alignment) * libgccjit.h: New functions (gcc_jit_lvalue_get_alignment, gcc_jit_lvalue_set_alignment) * libgccjit.map (LIBGCCJIT_ABI_24): New ABI tag. gcc/testsuite/ PR jit/104293 * jit.dg/all-non-failing-tests.h: Mention test-setting-alignment. * jit.dg/test-setting-alignment.c: New test.
[Bug jit/104073] Add option to hide stderr logging in libgccjit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104073 --- Comment #1 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:79e1a6fb9babb34dfcb99964c37d3c4f8bb619ca commit r12-8119-g79e1a6fb9babb34dfcb99964c37d3c4f8bb619ca Author: Antoni Boucher Date: Tue Apr 12 17:23:18 2022 -0400 libgccjit: Add function to hide stderr logs [PR104073] gcc/jit/ PR jit/104073 * docs/_build/texinfo/libgccjit.texi: Regenerate. * docs/topics/compatibility.rst (LIBGCCJIT_ABI_23): New ABI tag. * docs/topics/contexts.rst: Add documentation for the new function gcc_jit_context_set_bool_print_errors_to_stderr. * jit-common.h: New enum value (INNER_BOOL_OPTION_PRINT_ERRORS_TO_STDERR). * jit-recording.cc: Handle the new option INNER_BOOL_OPTION_PRINT_ERRORS_TO_STDERR. * libgccjit.cc: New function (gcc_jit_context_set_bool_print_errors_to_stderr). * libgccjit.h: New function (gcc_jit_context_set_bool_print_errors_to_stderr). * libgccjit.map (LIBGCCJIT_ABI_23): New ABI tag.
[Bug jit/104072] Register variables in libgccjit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104072 --- Comment #1 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:5780ff348ad4430383fd67c6f0c572d8c3e721ad commit r12-8118-g5780ff348ad4430383fd67c6f0c572d8c3e721ad Author: Antoni Boucher Date: Tue Apr 12 17:20:30 2022 -0400 libgccjit: Add support for register variables [PR104072] gcc/jit/ PR jit/104072 * docs/_build/texinfo/libgccjit.texi: Regenerate. * docs/topics/compatibility.rst (LIBGCCJIT_ABI_22): New ABI tag. * docs/topics/expressions.rst: Add documentation for the function gcc_jit_lvalue_set_register_name. * jit-playback.h: New function (set_register_name). * jit-recording.cc: New function (set_register_name) and add support for register variables. * jit-recording.h: New field (m_reg_name) and new function (set_register_name). * libgccjit.cc: New function (gcc_jit_lvalue_set_register_name). * libgccjit.h: New function (gcc_jit_lvalue_set_register_name). * libgccjit.map (LIBGCCJIT_ABI_22): New ABI tag. gcc/ PR jit/104072 * reginfo.cc: New functions (clear_global_regs_cache, reginfo_cc_finalize) to avoid an issue where compiling the same code multiple times gives an error about assigning the same register to 2 global variables. * rtl.h: New function (reginfo_cc_finalize). * toplev.cc: Call it. gcc/testsuite/ PR jit/104072 * jit.dg/all-non-failing-tests.h: Add new test-register-variable. * jit.dg/harness.h: Add -fdiagnostics-color=never to context's command-line options. * jit.dg/test-error-register-variable-bad-name.c: New test. * jit.dg/test-error-register-variable-size-mismatch.c: New test. * jit.dg/test-register-variable.c: New test.
[Bug jit/104071] Add support for bitcast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104071 --- Comment #2 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:30f7c83e9cfe7c015448d72f63c4c39d14bc6de6 commit r12-8117-g30f7c83e9cfe7c015448d72f63c4c39d14bc6de6 Author: Antoni Boucher Date: Tue Apr 12 17:17:50 2022 -0400 libgccjit: Add support for bitcasts [PR104071] gcc/jit/ PR jit/104071 * docs/_build/texinfo/libgccjit.texi: Regenerate. * docs/topics/compatibility.rst (LIBGCCJIT_ABI_21): New ABI tag. * docs/topics/expressions.rst: Add documentation for the function gcc_jit_context_new_bitcast. * jit-playback.cc: New function (new_bitcast). * jit-playback.h: New function (new_bitcast). * jit-recording.cc: New functions (new_bitcast, bitcast::replay_into, bitcast::visit_children, bitcast::make_debug_string, bitcast::write_reproducer). * jit-recording.h: New class (bitcast) and new function (new_bitcast, bitcast::replay_into, bitcast::visit_children, bitcast::make_debug_string, bitcast::write_reproducer, bitcast::get_precedence). * libgccjit.cc: New function (gcc_jit_context_new_bitcast) * libgccjit.h: New function (gcc_jit_context_new_bitcast) * libgccjit.map (LIBGCCJIT_ABI_21): New ABI tag. gcc/testsuite/ PR jit/104071 * jit.dg/all-non-failing-tests.h: Add new test-bitcast. * jit.dg/test-bitcast.c: New test. * jit.dg/test-error-bad-bitcast.c: New test. * jit.dg/test-error-bad-bitcast2.c: New test. gcc/ PR jit/104071 * toplev.cc: Call the new function tree_cc_finalize in toplev::finalize. * tree.cc: New functions (clear_nonstandard_integer_type_cache and tree_cc_finalize) to clear the cache of non-standard integer types to avoid having issues with some optimizations of bitcast where the SSA_NAME will have a size of a cached integer type that should have been invalidated, causing a comparison of integer constant to fail. * tree.h: New function (tree_cc_finalize).
[Bug jit/95325] Support 128-bit integers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95325 --- Comment #4 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:af80ea97b61847d91da0d303e85faed437059092 commit r12-8116-gaf80ea97b61847d91da0d303e85faed437059092 Author: Antoni Boucher Date: Tue Apr 12 17:16:45 2022 -0400 libgccjit: Add support for sized integer types, including 128-bit integers [PR95325] gcc/jit/ PR target/95325 * docs/_build/texinfo/libgccjit.texi: Regenerate * docs/topics/compatibility.rst (LIBGCCJIT_ABI_20): New ABI tag. * docs/topics/types.rst: Add documentation for the new types GCC_JIT_TYPE_UINT8_T, GCC_JIT_TYPE_UINT16_T, GCC_JIT_TYPE_UINT32_T, GCC_JIT_TYPE_UINT64_T, GCC_JIT_TYPE_UINT128_T, GCC_JIT_TYPE_INT8_T, GCC_JIT_TYPE_INT16_T, GCC_JIT_TYPE_INT32_T, GCC_JIT_TYPE_INT64_T, GCC_JIT_TYPE_INT128_T and new functions (gcc_jit_compatible_types, gcc_jit_type_get_size). * jit-builtins.cc: Add support for BT_UINT128. * jit-common.h: Update the value of NUM_GCC_JIT_TYPES. * jit-playback.cc: Add support for the sized integer types. * jit-recording.cc: Add support for the sized integer types. * jit-recording.h: Add support for comparing integer types and new function (is_signed). * libgccjit.cc (gcc_jit_compatible_types): New. (gcc_jit_type_get_size) New. * libgccjit.h: New enum variants for gcc_jit_types (GCC_JIT_TYPE_UINT8_T, GCC_JIT_TYPE_UINT16_T, GCC_JIT_TYPE_UINT32_T, GCC_JIT_TYPE_UINT64_T, GCC_JIT_TYPE_UINT128_T, GCC_JIT_TYPE_INT8_T, GCC_JIT_TYPE_INT16_T, GCC_JIT_TYPE_INT32_T, GCC_JIT_TYPE_INT64_T, GCC_JIT_TYPE_INT128_T) and new functions (gcc_jit_compatible_types, gcc_jit_type_get_size). * libgccjit.map (LIBGCCJIT_ABI_20): New ABI tag. gcc/testsuite/ PR target/95325 * jit.dg/test-types.c: Add tests for sized integer types.
[Bug middle-end/97048] [meta-bug] bogus/missing -Wstringop-overread warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97048 Bug 97048 depends on bug 100516, which changed state. Bug 100516 Summary: [11 Regression] Unexpected -Wstringop-overread in deque initialization from empty initializer_list https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100516 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug libstdc++/100516] [11 Regression] Unexpected -Wstringop-overread in deque initialization from empty initializer_list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100516 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Jonathan Wakely --- Fixed for 11.3
[Bug libstdc++/100516] [11 Regression] Unexpected -Wstringop-overread in deque initialization from empty initializer_list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100516 --- Comment #9 from CVS Commits --- The releases/gcc-11 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:573bb865df967b420aba5382a5987b8865f83dc0 commit r11-9837-g573bb865df967b420aba5382a5987b8865f83dc0 Author: Jonathan Wakely Date: Thu Jan 27 22:31:26 2022 + libstdc++: Prevent -Wstringop-overread warning in std::deque [PR100516] The compiler warns about the loop in deque::_M_range_initialize because it doesn't know that the number of nodes has already been correctly sized to match the size of the input. Use __builtin_unreachable to tell it that the loop will never be entered if the number of elements is smaller than a single node. libstdc++-v3/ChangeLog: PR libstdc++/100516 * include/bits/deque.tcc (_M_range_initialize): Add __builtin_unreachable to loop. * testsuite/23_containers/deque/100516.cc: New test. (cherry picked from commit eae41b4d2cc30327f9f15c7390438c46aa09ed3f)
[Bug tree-optimization/102516] [12 regression] pr65947-13.c and vect-alias-check-18.c fail on armeb since r12-3893
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102516 --- Comment #5 from Christophe Lyon --- Indeed. I know that vectorization does not work on armeb as well as on arm (little-endian), I was just wondering whether this regression was "expected"
[Bug c++/104669] [11/12 Regression] ICE in is_function_default_version, at attribs.cc:1219
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104669 --- Comment #4 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:791a968630b3846b614a435b9a75a52f29147a08 commit r12-8115-g791a968630b3846b614a435b9a75a52f29147a08 Author: Jason Merrill Date: Tue Apr 12 16:40:14 2022 -0400 c++: local function versioning [PR104669] There were two problems with this testcase: we weren't copying the target attribute from the second declaration to the global alias for the first one (duplicate_decls hunk), and then we were treating the third one as matching the earlier one even though both are versioned (decls_match hunk). The latter change required a fix to find_last_decl (used for attribute mismatch warnings) to give up if we see a versioned function, as in that case we can't determine whether the decls match, because we are still in the process of setting the attributes on the new decl. PR c++/104669 gcc/cp/ChangeLog: * decl.cc (decls_match): Compare versions even if not recording. (duplicate_decls): Propagate attributes to alias. * decl2.cc (find_last_decl): Give up if versioned. gcc/testsuite/ChangeLog: * g++.target/i386/mv31.C: New test.
[Bug c++/102071] [10/11 Regression] crash when combining -faligned-new=N with array cookie
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102071 --- Comment #6 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:164c6a1c5d7f99235f1a41440eacac7a977e8fbd commit r12-8114-g164c6a1c5d7f99235f1a41440eacac7a977e8fbd Author: Jason Merrill Date: Tue Apr 12 16:06:18 2022 -0400 c++: non-array new alignment [PR102071] While considering the PR102071 patch for backporting, I noticed that I was considering the alignment of the array new cookie even when there isn't one because we aren't allocating an array. PR c++/102071 gcc/cp/ChangeLog: * init.cc (build_new_1): Check array_p for alignment. gcc/testsuite/ChangeLog: * g++.dg/cpp1z/aligned-new9.C: Add single-object test.
[Bug c++/105245] [10/11/12 Regression] ICE in clear_no_implicit_zero, in cp/constexpr.cc:1892
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105245 Jason Merrill changed: What|Removed |Added CC||jason at gcc dot gnu.org Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug libstdc++/93602] [9/10/11/12 Regression] Missing reference to libiconv in 9.x libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93602 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed|2020-02-05 00:00:00 |2022-04-12 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org --- Comment #16 from Jonathan Wakely --- I think we need to use LTLIBICONV when linking libstdc++.
[Bug target/104894] [11/12 Regression] ICE with -fno-plt -mcpu=power10 on PowerPC64 LE Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104894 Peter Bergner changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #11 from Peter Bergner --- Fixed everywhere.
[Bug libstdc++/103630] [9/10 Regression] std::make_exception_ptr(t) is ill-formed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103630 Jonathan Wakely changed: What|Removed |Added Summary|[9/10/11 Regression]|[9/10 Regression] |std::make_exception_ptr |std::make_exception_ptr |(t) is ill-formed |(t) is ill-formed --- Comment #5 from Jonathan Wakely --- Fixed for 11.3 too.
[Bug c++/101051] [10/11 Regression] ICE in splice_late_return_type with trailing return type on a conversion operator, caused by r10-6571
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101051 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Target Milestone|10.4|11.3 Resolution|--- |FIXED --- Comment #8 from Jason Merrill --- Fixed for 11.3/12.
[Bug c++/101894] [11 Regression] ICE with multiple friend declarations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101894 Jason Merrill changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #8 from Jason Merrill --- Fixed for 11.3/12.
[Bug c++/103943] [11 Regression] ICE building qualified name inside class with variadic CTAD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103943 Jason Merrill changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Jason Merrill --- Fixed for 11.3/12.
[Bug c++/102869] [11 Regression] Expansion pattern 'std::integer_sequence' contains no parameter packs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102869 Jason Merrill changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Jason Merrill --- Fixed for 11.3/12.
[Bug target/104894] [11/12 Regression] ICE with -fno-plt -mcpu=power10 on PowerPC64 LE Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104894 --- Comment #10 from CVS Commits --- The releases/gcc-11 branch has been updated by Peter Bergner : https://gcc.gnu.org/g:5ede37c0f274f0de19afd662588891e32b60f705 commit r11-9836-g5ede37c0f274f0de19afd662588891e32b60f705 Author: Peter Bergner Date: Tue Apr 12 14:08:53 2022 -0500 rs6000: Handle pcrel sibcalls to longcall functions [PR104894] Before PCREL in POWER10, we were not allowed to perform sibcalls to longcall functions since callee's return would skip the TOC restore in the caller. However, with PCREL we can now safely perform a sibling call to longcall functions. The problem with the current code is that pcrel sibcall branches to a PLT stub label even though -fno-plt was used. The solution here is to check for a pcrel longcall and emit an inline plt stub in that case. 2022-04-11 Peter Bergner gcc/ PR target/104894 * config/rs6000/rs6000.c (rs6000_sibcall_aix): Handle pcrel sibcalls to longcall functions. gcc/testsuite/ PR target/104894 * gcc.target/powerpc/pr104894.c: New test. * gcc.target/powerpc/pr104894-2.c: New test. (cherry picked from commit d74c4c6a1b4956b5cd9b2a770bb7261836fa1289)
[Bug c++/105003] [12 regression] ICE in new test case from r12-7710-gc7a6a32739d62d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105003 Bug 105003 depends on bug 104008, which changed state. Bug 104008 Summary: [11 Regression] New g++ folly compile error since r11-7931-ga2531859bf5bf6cf https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104008 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/103105] [11 Regression] ICE iterative_hash_template_arg with concepts and varagrs template since r11-3261-gb28b621ac67beee8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103105 Bug 103105 depends on bug 104008, which changed state. Bug 104008 Summary: [11 Regression] New g++ folly compile error since r11-7931-ga2531859bf5bf6cf https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104008 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/104008] [11 Regression] New g++ folly compile error since r11-7931-ga2531859bf5bf6cf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104008 Jason Merrill changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #16 from Jason Merrill --- Fixed for 11.3/12.
[Bug c++/101677] [11 Regression] Concept with use of incomplete type succeeds on GCC 10.3.0, fails on GCC 11 onward
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101677 Jason Merrill changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Jason Merrill --- Fixed for 11.3/12.
[Bug libstdc++/105021] [11 Regression] Missing freestanding headers: bits/atomic_base.h:41:10: fatal error: bits/atomic_wait.h: No such file or directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105021 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Jonathan Wakely --- Fixed for 11.3
[Bug c++/104476] [11 Regression] using-decl shadowed by member function when in incomplete-class context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104476 --- Comment #9 from Jason Merrill --- I'm not sure whether it makes more sense to revert the PR92918 patch on the 11 branch or leave it alone; the GCC 12 fix is too complex to backport. I guess I lean toward leaving it alone, since this hasn't gotten other reports.
[Bug libstdc++/103638] [11 Regression] #include gives errors for --disable-threads builds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103638 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jonathan Wakely --- Fixed for 11.3
[Bug libstdc++/90943] Visiting inherited variants no longer works in 9.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90943 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #12 from Jonathan Wakely --- Fixed for 11.3
[Bug libstdc++/103630] [9/10/11 Regression] std::make_exception_ptr(t) is ill-formed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103630 --- Comment #4 from CVS Commits --- The releases/gcc-11 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:84e2410c8d10d7f3ca61c3063418ace8dd8f9e35 commit r11-9835-g84e2410c8d10d7f3ca61c3063418ace8dd8f9e35 Author: Jonathan Wakely Date: Thu Dec 9 13:54:39 2021 + libstdc++: Fix std::exception_ptr regressions [PR103630] This restores support for std::make_exception_ptr and for using std::exception_ptr in C++98. Because the new non-throwing implementation needs to use std::decay to handle references the original throwing implementation is used for C++98. We also need to change the typeid expression so it doesn't yield the dynamic type when the function parameter is a reference to a polymorphic type. Otherwise the new exception object could be caught by any handler matching the dynamic type, even though the actual exception object is only a copy of the base class, sliced to the static type. libstdc++-v3/ChangeLog: PR libstdc++/103630 * libsupc++/exception_ptr.h (exception_ptr): Fix exception specifications on inline definitions. (make_exception_ptr): Decay the template parameter. Use typeid of the static type. * testsuite/18_support/exception_ptr/103630.cc: New test. (cherry picked from commit a1ca039fc0fe934ef36c25d8284e6e116bcaffa7)
[Bug libstdc++/105021] [11 Regression] Missing freestanding headers: bits/atomic_base.h:41:10: fatal error: bits/atomic_wait.h: No such file or directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105021 --- Comment #2 from CVS Commits --- The releases/gcc-11 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:ac0e9b696c362fdd49752260ca7b3ce9e467ec36 commit r11-9834-gac0e9b696c362fdd49752260ca7b3ce9e467ec36 Author: Jonathan Wakely Date: Tue Mar 22 21:17:01 2022 + libstdc++: Disable atomic wait for freestanding [PR105021] We use either condition variables or futexes to implement atomic waits, so we can't do it in freestanding. This is non-conforming, so should be revisited later, probably by making freestanding atomic waiting operations spin without ever blocking. Reviewed-by: Thomas Rodgers libstdc++-v3/ChangeLog: PR libstdc++/105021 * include/bits/atomic_base.h [!_GLIBCXX_HOSTED]: Do not include for freestanding. (cherry picked from commit 5bf59b004808abf6acbfe5ef54a0f9216b8dce22)
[Bug libstdc++/103638] [11 Regression] #include gives errors for --disable-threads builds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103638 --- Comment #3 from CVS Commits --- The releases/gcc-11 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:105f1c08369aa6702d070f911dd658b93230ac46 commit r11-9833-g105f1c08369aa6702d070f911dd658b93230ac46 Author: Jonathan Wakely Date: Fri Dec 10 11:44:29 2021 + libstdc++: Guard mutex and condvar with gthreads macro [PR103638] A mutex and condition variable is used for timed waits on atomics if there is no "platform wait" (e.g. futex) supported. But the use of those types wasn't guarded by the _GLIBCXX_HAS_GTHREADS macro, causing errors for --disable-threads builds. This fix allows to work on targets with futexes but no gthreads. libstdc++-v3/ChangeLog: PR libstdc++/103638 * include/bits/atomic_timed_wait.h: Check _GLIBCXX_HAS_GTHREADS before using std::mutex and std::__condvar. (cherry picked from commit ffb632517fc446474baba10ee2ff13a218ec2c7b)
[Bug libstdc++/90943] Visiting inherited variants no longer works in 9.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90943 --- Comment #11 from CVS Commits --- The releases/gcc-11 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:90b94ca5a2ddd7834afff9ad5e1afff5554e0752 commit r11-9831-g90b94ca5a2ddd7834afff9ad5e1afff5554e0752 Author: Jonathan Wakely Date: Mon Apr 19 14:49:12 2021 +0100 libstdc++: Allow visiting inherited variants [PR 90943] Implement the changes from P2162R2 (as a DR for C++17). Signed-off-by: Jonathan Wakely libstdc++-v3/ChangeLog: PR libstdc++/90943 * include/std/variant (__cpp_lib_variant): Update value. (__detail::__variant::__as): New helpers implementing the as-variant exposition-only function templates. (visit, visit): Use __as to upcast the variant parameters. * include/std/version (__cpp_lib_variant): Update value. * testsuite/20_util/variant/visit_inherited.cc: New test. (cherry picked from commit c46ecb0112e91c80ee111439e79a58a953e4479d)
[Bug c++/98249] [9/10/11 Regression] Improper ADL on the `arg` in `new (arg) T`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98249 --- Comment #4 from CVS Commits --- The releases/gcc-11 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:7aa5f05583066f5b3146c999319288631c75597f commit r11-9830-g7aa5f05583066f5b3146c999319288631c75597f Author: Jason Merrill Date: Mon Apr 11 13:06:05 2022 -0400 c++: operator new lookup [PR98249] The standard says, as we quote in the comment just above, that if we don't find operator new in the allocated type, it should be looked up in the global scope. This is specifically ::, not just any namespace, and we already give an error for an operator new declared in any other namespace. PR c++/98249 gcc/cp/ChangeLog: * call.c (build_operator_new_call): Just look in ::. gcc/testsuite/ChangeLog: * g++.dg/lookup/new3.C: New test.
[Bug c++/100608] [10/11 Regression] -Wshadow=compatible-local false positive: function local type declaration shadows variable of different type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100608 --- Comment #3 from CVS Commits --- The releases/gcc-11 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:c52cd0b35d356565f67f7956f4defc022dfa2172 commit r11-9829-gc52cd0b35d356565f67f7956f4defc022dfa2172 Author: Jason Merrill Date: Tue Apr 5 16:02:04 2022 -0400 c++: -Wshadow=compatible-local type vs var [PR100608] The patch for PR92024 changed -Wshadow=compatible-local to warn if either new or old decl was a type, but the rationale only talked about the case where both are types. If only one is, they aren't compatible. PR c++/100608 gcc/cp/ChangeLog: * name-lookup.c (check_local_shadow): Use -Wshadow=local if exactly one of 'old' and 'decl' is a type. gcc/testsuite/ChangeLog: * g++.dg/warn/Wshadow-compatible-local-3.C: New test.
[Bug c++/101677] [11 Regression] Concept with use of incomplete type succeeds on GCC 10.3.0, fails on GCC 11 onward
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101677 --- Comment #4 from CVS Commits --- The releases/gcc-11 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:556d061e62ea863c7f99129219ca69bf0792c7f1 commit r11-9828-g556d061e62ea863c7f99129219ca69bf0792c7f1 Author: Jason Merrill Date: Sun Mar 27 22:31:51 2022 -0400 c++: elaborated-type-spec in requires-expr [PR101677] We were failing to declare class S in the global namespace because we were treating the requires-expression parameter scope as a normal block scope, so the implicit declaration went there. It seems to me that the requires parameter scope is more like a function parameter scope (not least in the use of the word "parameter"), so let's change the scope kind. But then we need to adjust the prohibition on placeholders declaring implicit template parameters. PR c++/101677 gcc/cp/ChangeLog: * name-lookup.h (struct cp_binding_level): Add requires_expression bit-field. * parser.c (cp_parser_requires_expression): Set it. (synthesize_implicit_template_parm): Check it. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/concepts-pr67178.C: Adjust error. * g++.dg/cpp2a/concepts-requires28.C: New test.
[Bug c++/102869] [11 Regression] Expansion pattern 'std::integer_sequence' contains no parameter packs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102869 --- Comment #4 from CVS Commits --- The releases/gcc-11 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:00e7d6e66638b8d2d93ff6659a140f8b3cf37aeb commit r11-9827-g00e7d6e66638b8d2d93ff6659a140f8b3cf37aeb Author: Jason Merrill Date: Fri Mar 25 13:13:35 2022 -0400 c++: hash table ICE with variadic alias [PR105003] For PR104008 we thought it might be enough to keep strip_typedefs from removing this alias template specialization, but this PR demonstrates that other parts of the compiler also need to know to consider it dependent. So, this patch changes complex_alias_template_p to no longer consider template parameters used when their only use appears in a pack expansion, unless they are the parameter packs being expanded. To do that I also needed to change it to use cp_walk_tree instead of for_each_template_parm. It occurs to me that find_template_parameters should probably also use cp_walk_tree, but I'm not messing with that now. PR c++/105003 PR c++/104008 PR c++/102869 gcc/cp/ChangeLog: * pt.c (complex_alias_template_r): walk_tree callback, replacing uses_all_template_parms_r, complex_pack_expansion_r. (complex_alias_template_p): Adjust. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/variadic-alias6.C: New test. * g++.dg/cpp0x/variadic-alias7.C: New test.
[Bug c++/104008] [11 Regression] New g++ folly compile error since r11-7931-ga2531859bf5bf6cf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104008 --- Comment #15 from CVS Commits --- The releases/gcc-11 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:00e7d6e66638b8d2d93ff6659a140f8b3cf37aeb commit r11-9827-g00e7d6e66638b8d2d93ff6659a140f8b3cf37aeb Author: Jason Merrill Date: Fri Mar 25 13:13:35 2022 -0400 c++: hash table ICE with variadic alias [PR105003] For PR104008 we thought it might be enough to keep strip_typedefs from removing this alias template specialization, but this PR demonstrates that other parts of the compiler also need to know to consider it dependent. So, this patch changes complex_alias_template_p to no longer consider template parameters used when their only use appears in a pack expansion, unless they are the parameter packs being expanded. To do that I also needed to change it to use cp_walk_tree instead of for_each_template_parm. It occurs to me that find_template_parameters should probably also use cp_walk_tree, but I'm not messing with that now. PR c++/105003 PR c++/104008 PR c++/102869 gcc/cp/ChangeLog: * pt.c (complex_alias_template_r): walk_tree callback, replacing uses_all_template_parms_r, complex_pack_expansion_r. (complex_alias_template_p): Adjust. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/variadic-alias6.C: New test. * g++.dg/cpp0x/variadic-alias7.C: New test.
[Bug c++/105003] [12 regression] ICE in new test case from r12-7710-gc7a6a32739d62d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105003 --- Comment #5 from CVS Commits --- The releases/gcc-11 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:00e7d6e66638b8d2d93ff6659a140f8b3cf37aeb commit r11-9827-g00e7d6e66638b8d2d93ff6659a140f8b3cf37aeb Author: Jason Merrill Date: Fri Mar 25 13:13:35 2022 -0400 c++: hash table ICE with variadic alias [PR105003] For PR104008 we thought it might be enough to keep strip_typedefs from removing this alias template specialization, but this PR demonstrates that other parts of the compiler also need to know to consider it dependent. So, this patch changes complex_alias_template_p to no longer consider template parameters used when their only use appears in a pack expansion, unless they are the parameter packs being expanded. To do that I also needed to change it to use cp_walk_tree instead of for_each_template_parm. It occurs to me that find_template_parameters should probably also use cp_walk_tree, but I'm not messing with that now. PR c++/105003 PR c++/104008 PR c++/102869 gcc/cp/ChangeLog: * pt.c (complex_alias_template_r): walk_tree callback, replacing uses_all_template_parms_r, complex_pack_expansion_r. (complex_alias_template_p): Adjust. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/variadic-alias6.C: New test. * g++.dg/cpp0x/variadic-alias7.C: New test.
[Bug c++/101894] [11 Regression] ICE with multiple friend declarations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101894 --- Comment #7 from CVS Commits --- The releases/gcc-11 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:ad4b23729b2e57676efb3d8313f4fc5300b94339 commit r11-9826-gad4b23729b2e57676efb3d8313f4fc5300b94339 Author: Jason Merrill Date: Fri Apr 1 16:18:31 2022 -0400 c++: repeated friend template [PR101894] Since olddecl isn't a definition, it doesn't get DECL_FRIEND_CONTEXT, so we need to copy it from newdecl when we merge the declarations. PR c++/101894 gcc/cp/ChangeLog: * decl.c (duplicate_decls): Copy DECL_FRIEND_CONTEXT. gcc/testsuite/ChangeLog: * g++.dg/lookup/friend22.C: New test.
[Bug c++/103943] [11 Regression] ICE building qualified name inside class with variadic CTAD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103943 --- Comment #4 from CVS Commits --- The releases/gcc-11 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:3a17a1842350e7a9a6e81931e8ad66184b33efb2 commit r11-9825-g3a17a1842350e7a9a6e81931e8ad66184b33efb2 Author: Jason Merrill Date: Sat Mar 26 22:05:53 2022 -0400 c++: CTAD and member function references [PR103943] More quirks of rewriting member references to dependent references for CTAD. A reference to a member of dependent scope is definitely dependent. And since r11-7044, tsubst_baselink builds a SCOPE_REF, so tsubst_qualified_id should just use it. PR c++/103943 gcc/cp/ChangeLog: * pt.c (tsubst_qualified_id): Handle getting SCOPE_REF from tsubst_baselink. (instantiation_dependent_scope_ref_p): Check dependent_scope_p. gcc/testsuite/ChangeLog: * g++.dg/cpp1z/class-deduction109.C: New test.
[Bug c++/101717] [9/10/11 Regression] ICE capturing static member within stateless generic lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101717 --- Comment #8 from CVS Commits --- The releases/gcc-11 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:eea5641912b914f3589ec1ec576a596451180baa commit r11-9824-geea5641912b914f3589ec1ec576a596451180baa Author: Jason Merrill Date: Wed Apr 6 22:20:49 2022 -0400 c++: nested generic lambda in DMI [PR101717] We were already checking COMPLETE_TYPE_P to recognize instantiation of a generic lambda, but didn't consider that we might be nested in a non-generic lambda. PR c++/101717 gcc/cp/ChangeLog: * lambda.c (lambda_expr_this_capture): Check all enclosing lambdas for completeness. gcc/testsuite/ChangeLog: * g++.dg/cpp1y/lambda-generic-this4.C: New test.
[Bug c++/101051] [10/11 Regression] ICE in splice_late_return_type with trailing return type on a conversion operator, caused by r10-6571
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101051 --- Comment #7 from CVS Commits --- The releases/gcc-11 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:25167a3d8cfc738deb4b2bfb74ad37fd8a0f1ca4 commit r11-9823-g25167a3d8cfc738deb4b2bfb74ad37fd8a0f1ca4 Author: Jason Merrill Date: Wed Apr 6 21:57:33 2022 -0400 c++: conversion with trailing return type [PR101051] We've had a diagnostic for this, but since r10-6571 added an assert to splice_late_return_type, we need to diagnose before we call it. PR c++/101051 gcc/cp/ChangeLog: * decl.c (grokdeclarator): Reject conversion with trailing return sooner. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/trailing15.C: New test.
[Bug ipa/105250] New: ICE: in fold_convert_loc, at fold-const.cc:2581 with conflicting function redeclaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105250
Bug ID: 105250
Summary: ICE: in fold_convert_loc, at fold-const.cc:2581 with
conflicting function redeclaration
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: zsojka at seznam dot cz
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Created attachment 52792
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52792=edit
reduced testcase
The testcase is broken in a similar way as PR105140
Compiler output:
$ x86_64-pc-linux-gnu-gcc -O2 testcase.c
testcase.c:9:1: warning: return type defaults to 'int' [-Wimplicit-int]
9 | foo(int, int, int, int, U, U, V, V, W, W, int,
| ^~~
testcase.c:9:1: warning: conflicting types for 'foo'
testcase.c:7:6: note: previous declaration of 'foo' with type 'void()'
7 | void foo();
| ^~~
testcase.c: In function 'foo':
testcase.c:9:1: note: the ABI for passing parameters with 32-byte alignment has
changed in GCC 4.6
9 | foo(int, int, int, int, U, U, V, V, W, W, int,
| ^~~
during IPA pass: inline
testcase.c:16:3: internal compiler error: in fold_convert_loc, at
fold-const.cc:2581
16 | foo(0, 0, 0, 0, (U){}, (U){}, (V){}, (V){}, (W){},
| ^~
17 |(W){}, 2, (T){}, 0, 0, 0, 0, (U){}, (U){},
|~~
18 |(V){}, (V){}, (W){}, (W){}, (T){},
|~~
19 |(T){}, 0, 0, 0, 0, (U){}, (U){}, (V){},
|~~~
20 |(V){}, (W){}, (W){}, (T){}, (T){}, 0, 0, 0,
|~~~
21 |0, 0, 0, (T){},
|~~~
22 |(T){}, (W){},
|~
23 |(W){}, (T){}, (T){}, 0, 0, 0, 0, 0, 0, (W){},
|~
24 |(V){}, (W){}, (T){}, 0, 0, (U){}, (F){});
|
0x6db3be fold_convert_loc(unsigned int, tree_node*, tree_node*)
/repo/gcc-trunk/gcc/fold-const.cc:2581
0x1415210 setup_one_parameter
/repo/gcc-trunk/gcc/tree-inline.cc:3549
0x142031a initialize_inlined_parameters
/repo/gcc-trunk/gcc/tree-inline.cc:3642
0x142031a expand_call_inline
/repo/gcc-trunk/gcc/tree-inline.cc:5017
0x14229c6 gimple_expand_calls_inline
/repo/gcc-trunk/gcc/tree-inline.cc:5320
0x14229c6 optimize_inline_calls(tree_node*)
/repo/gcc-trunk/gcc/tree-inline.cc:5492
0x110d0cb inline_transform(cgraph_node*)
/repo/gcc-trunk/gcc/ipa-inline-transform.cc:790
0x1289f16 execute_one_ipa_transform_pass
/repo/gcc-trunk/gcc/passes.cc:2330
0x1289f16 execute_all_ipa_transforms(bool)
/repo/gcc-trunk/gcc/passes.cc:2393
0xeb520d cgraph_node::expand()
/repo/gcc-trunk/gcc/cgraphunit.cc:1828
0xeb520d cgraph_node::expand()
/repo/gcc-trunk/gcc/cgraphunit.cc:1788
0xeb6806 expand_all_functions
/repo/gcc-trunk/gcc/cgraphunit.cc:1999
0xeb6806 symbol_table::compile()
/repo/gcc-trunk/gcc/cgraphunit.cc:2349
0xeb93e7 symbol_table::compile()
/repo/gcc-trunk/gcc/cgraphunit.cc:2262
0xeb93e7 symbol_table::finalize_compilation_unit()
/repo/gcc-trunk/gcc/cgraphunit.cc:2530
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug libstdc++/103955] std::to_chars(char*, char*, double, std::chars_format, int precision) crashes for the two maximal int precision values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103955 Patrick Palka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Patrick Palka --- Fixed for 11.3/12.
[Bug libstdc++/103955] std::to_chars(char*, char*, double, std::chars_format, int precision) crashes for the two maximal int precision values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103955 --- Comment #4 from CVS Commits --- The releases/gcc-11 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:0b6d4ee830b01ee70cc5dc32722d73ac3ea4e0db commit r11-9822-g0b6d4ee830b01ee70cc5dc32722d73ac3ea4e0db Author: Patrick Palka Date: Wed Jan 12 09:10:24 2022 -0500 libstdc++: Avoid overflow in bounds checks [PR103955] We currently crash when the floating-point to_chars overloads are passed a precision value near INT_MAX, ultimately due to overflow in the bounds checks that verify the output range is large enough. The simplest portable fix seems to be to replace bounds checks of the form A >= B + C (where B + C may overflow) with the otherwise equivalent check A >= B && A - B >= C, which is the approach this patch takes. Before we could do this in __floating_to_chars_hex, there we first need to track the unbounded "excess" precision (i.e. the number of trailing fractional digits in the output that are guaranteed to be '0') separately from the bounded "effective" precision (i.e. the number of significant fractional digits in the output), like we do in __f_t_c_precision. PR libstdc++/103955 libstdc++-v3/ChangeLog: * src/c++17/floating_to_chars.cc (__floating_to_chars_hex): Track the excess precision separately from the effective precision. Avoid overflow in bounds check by splitting it into two checks. (__floating_to_chars_precision): Avoid overflow in bounds checks similarly. * testsuite/20_util/to_chars/103955.cc: New test. (cherry picked from commit c0e355c77972d96fcec2ff7da047ad03e10e51d9)
[Bug c++/103871] [11/12 Regression] co_await causes build error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103871
--- Comment #10 from Iain Sandoe ---
Despite investing some time in this, it seems that I cannot get a patch ready
for master / reviewed and back-ported in time (although I am hopeful to get the
fix sorted out in time for GCC-12)
(I can confirm that my fix does still work for this - but there is just not
enough time to process it through).
Looking at the test case and the diagnostics, it seems that PR98056 was latent
here and the fix in r12-618-g14ed21f8749ae359690d9c4a69ca38cc45d0d1b0 has
simply revealed it.
a workaround in the example might be:
auto task = g(std::make_unique(std::vector{0L})); // ok
co_await task;
[Bug debug/105249] schedule-insns2 makes a variable not available and associates the code that assigns it to a different function frame
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105249 --- Comment #1 from Cristian Assaiante --- This issue is similar to bug 105036 but it appears on different optimization levels and, differently from the previously reported issue, it has a much simpler code structure since we have only a call to a printf in the body of the inlined routine.
[Bug debug/105249] New: schedule-insns2 makes a variable not available and associates the code that assigns it to a different function frame
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105249
Bug ID: 105249
Summary: schedule-insns2 makes a variable not available and
associates the code that assigns it to a different
function frame
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: assaiante at diag dot uniroma1.it
Target Milestone: ---
In this minimized C example, induction variable i is not available when
stepping on line 9. At -Os we note that the address of the instruction that
assigns to variable a is associated in DWARF with locations from c(), thus
leading to a wrong current function frame when debugging. At -Og/-O1 the
behavior is instead correct. Apparently, schedule-insns2 is responsible for
generating overlapping locations for function c and induction variable i.
At -Oz/-O2/-O3, if we place a breakpoint on line 9 the line is never stepped,
but instead the program breaks inside the body of function c. For this scenario
too, the issue disappears with -fno-schedule-insns2.
Please find below a detailed analysis for -Os on x64 and a quick assessment on
past gcc versions where the issue is sometimes not present.
$ cat a.c
volatile int a;
int b[2];
static void c(int d3) { printf("%d", d3); }
int main() {
int i;
b[0] = 0;
i = 0;
for (; i < 2; i++)
a = b[i];
c(0);
}
GCC and GDB version:
- gcc (GCC) 12.0.0 20211227 (experimental) - commit id: 500d3f0a302
- GNU gdb (GDB) 11.2
GDB trace:
$ gcc -Os -g a.c -o opt
$ gdb -q opt
Reading symbols from opt...
(gdb) b 9
Breakpoint 1 at 0x400421: file a.c, line 9.
(gdb) r
Starting program: /tmp/opt
Breakpoint 1, c (d3=) at a.c:9
9 a = b[i];
(gdb) info loc
No locals.
ASM at -Os:
00400410 :
400410: 50 push %rax
400411: 8b 05 25 0c 20 00 mov0x200c25(%rip),%eax#
60103c
400417: 31 d2 xor%edx,%edx
400419: 31 f6 xor%esi,%esi
40041b: 89 15 1f 0c 20 00 mov%edx,0x200c1f(%rip)#
601040
400421: bf b4 05 40 00 mov$0x4005b4,%edi
400426: 89 05 14 0c 20 00 mov%eax,0x200c14(%rip)#
601040
40042c: 31 c0 xor%eax,%eax
40042e: 89 15 04 0c 20 00 mov%edx,0x200c04(%rip)#
601038
400434: e8 c7 ff ff ff callq 400400
400439: 31 c0 xor%eax,%eax
40043b: 59 pop%rcx
40043c: c3 retq
DWARF at -Os:
[ function c DIE ]
0x00a7: DW_TAG_inlined_subroutine
DW_AT_abstract_origin (0x00f1 "c")
DW_AT_entry_pc(0x0040042c)
DW_AT_unknown_2138(0x03)
DW_AT_ranges (0x000c
[0x00400419, 0x0040041b)
[0x00400421, 0x00400426)
[0x0040042c, 0x0040042e)
[0x00400434, 0x00400439))
DW_AT_call_file ("/tmp/a.c")
DW_AT_call_line (10)
DW_AT_call_column (0x03)
[ variable i DIE ]
0x0095: DW_TAG_variable
DW_AT_name("i")
DW_AT_decl_file ("/tmp/a.c")
DW_AT_decl_line (5)
DW_AT_decl_column (0x07)
DW_AT_type(0x003d "int")
DW_AT_location(0x0010:
[0x00400421, 0x0040042c): DW_OP_lit1,
DW_OP_stack_value
[0x0040042c, 0x0040043d): DW_OP_lit2,
DW_OP_stack_value)
DW_AT_GNU_locviews(0x000c)
DEBUG line info at -Os:
AddressLine Column File ISA Discriminator Flags
-- -- -- -- --- - -
0x00400421 9 5 1 0 0 is_stmt
In the DWARF info function c is defined in the range [0x00400421,
0x00400426) and from the line info we can see how the begin address of
the range is associated with line 9. This causes the variable i to not be
available when debugging even if its location is correctly defined.
Through some testing we found out that the optimization that makes the variable
not available and introduces the location overlapping is -fschedule-insns2. If
we add -fno-schedule-insns2 to the previous compilation command line, the issue
is not present anymore since the DWARF location and line number association are
correctly computed. The option would also solve the correctness problem pointed
out for -Oz/-O2/-O3.
ASM at -Os with -fno-schedule-insns2:
00400410 :
[Bug gcov-profile/105210] gcc/auto-profile.cc:391:11: warning: variable 'level' set but not used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105210 --- Comment #8 from Martin Liška --- > Do you mean the smaller patch to fix the problems I reported, > or a larger patch to have gcc duplicate the behaviour of clang ? Yes, the former one.
[Bug libstdc++/105241] std::bitset::reference should have an ADL swap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105241 Jonathan Wakely changed: What|Removed |Added Severity|normal |enhancement
[Bug gcov-profile/105210] gcc/auto-profile.cc:391:11: warning: variable 'level' set but not used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105210 --- Comment #7 from David Binderman --- (In reply to Martin Liška from comment #6) > I'm going to prepare a patch for next stage 1. Do you mean the smaller patch to fix the problems I reported, or a larger patch to have gcc duplicate the behaviour of clang ? I checked the assembly language output from the code in comment 2 and AFAIK the optimiser removes the pointless increment at level -O1 and above.
[Bug c++/105245] [10/11/12 Regression] ICE in clear_no_implicit_zero, in cp/constexpr.cc:1892
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105245
--- Comment #2 from Marek Polacek ---
0x00b5b5c9 in clear_no_implicit_zero (ctor=) at /home/mpolacek/src/gcc/gcc/cp/constexpr.cc:1892
1892if (TREE_CODE (e.value) == CONSTRUCTOR)
(gdb) p ctor
$3 =
(gdb) pge
{.b=}
that ctor doesn't look right...
[Bug c++/105245] [10/11/12 Regression] ICE in clear_no_implicit_zero, in cp/constexpr.cc:1892
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105245 Marek Polacek changed: What|Removed |Added Priority|P3 |P2 CC||jakub at gcc dot gnu.org, ||mpolacek at gcc dot gnu.org Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2022-04-12 Target Milestone|--- |10.4 --- Comment #1 from Marek Polacek --- Started with r11-8222-g35e8b38a91d9fb: commit 35e8b38a91d9fb49a4759649576f15e76c129d99 Author: Jakub Jelinek Date: Fri Apr 16 17:37:07 2021 +0200 c++: Fix empty base stores in cxx_eval_store_expression [PR100111]
[Bug libstdc++/105241] std::bitset::reference should have an ADL swap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105241 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2022-04-12 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- (In reply to Arthur O'Dwyer from comment #0) > Swapping elements via the std::swap two-step works for `std::vector`; Not according to the C++ standard it doesn't. That's https://wg21.link/lwg3638 > I see no reason it shouldn't also work for `std::bitset`. I see no requirement in the standard for it to work. > libc++ and Microsoft STL both support `swap` on `bitset::reference` just > fine. That's a non-standard extension. I think we could add it to libstdc++, but this seems like an LWG issue to me.
[Bug debug/105248] New: Missing value or location attribute for constant live variable likely caused by tree-dse at -O1/-O2/-O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105248
Bug ID: 105248
Summary: Missing value or location attribute for constant live
variable likely caused by tree-dse at -O1/-O2/-O3
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: assaiante at diag dot uniroma1.it
Target Milestone: ---
In this minimized C example, variable l_56 is marked as optimized out when
stepping on a call to an external function that takes it as an argument. This
happens then the optimization level is -O1/-O2/-O3 while at -Og the debug
information is correctly defined. The variable has constant value.
Apparently, tree-dse optimization is responsible for a missing location
attribute in the DWARF DIE associated with variable l_56. If we prevent the
compiler from performing such optimization, the generated ASM will be identical
but the DWARF location info will be complete, making the variable available in
its uses.
Please find below a detailed analysis for -O1 on x64 and a quick assessment on
past gcc versions where the issue is sometimes not present.
$ cat a.c
void a()
{
int *b;
short l_47 = 5;
int l_56 = 6;
int **c =
test(l_47, l_56);
*c = _56;
}
int main ()
{
a();
}
$ cat lib.c
#include
void test(int l_47, int l_56) {
printf("%d %d", l_47, l_56);
}
GCC and GDB version:
- gcc (GCC) 12.0.0 20211227 (experimental) - commit id: 500d3f0a302
- GNU gdb (GDB) 11.2
GDB trace:
$ gcc -O1 -g a.c lib.c -o opt
$ gdb -q opt
Reading symbols from opt...
(gdb) b 7
Breakpoint 1 at 0x40054a: file a.c, line 7.
(gdb) r
Starting program: /tmp/opt
Breakpoint 1, a () at a.c:7
7 test(l_47, l_56);
(gdb) info locals
b =
l_47 = 5
l_56 =
c =
ASM at -O1:
00400546 :
400546: 48 83 ec 08 sub$0x8,%rsp
40054a: be 06 00 00 00 mov$0x6,%esi
40054f: bf 05 00 00 00 mov$0x5,%edi
400554: b8 00 00 00 00 mov$0x0,%eax
400559: e8 30 00 00 00 callq 40058e
40055e: 48 83 c4 08 add$0x8,%rsp
400562: c3 retq
DWARF info at -O1:
0x00a7: DW_TAG_variable
DW_AT_name("l_56")
DW_AT_decl_file ("/tmp/a.c")
DW_AT_decl_line (5)
DW_AT_decl_column (0x09)
DW_AT_type(0x003d "int")
>From DWARF info we can see how the variable l_56 DIE is completely missing
either a const value or a location attribute and this lack of information
causes the unavailability of its value during debugging.
Through some testing we found out that the optimization that makes the variable
not available and that introduces the location overlapping is -ftree-dse. If we
add -fno-tree-dse to the previous compilation command line, the issue is not
present anymore since the DWARF location is correctly computed with the correct
value associated with it.
ASM at -O1 with -fno-tree-dse:
00400546 :
400546: 48 83 ec 08 sub$0x8,%rsp
40054a: be 06 00 00 00 mov$0x6,%esi
40054f: bf 05 00 00 00 mov$0x5,%edi
400554: b8 00 00 00 00 mov$0x0,%eax
400559: e8 30 00 00 00 callq 40058e
40055e: 48 83 c4 08 add$0x8,%rsp
400562: c3 retq
DWARF info at -O1 with -fno-tree-dse:
0x00a7: DW_TAG_variable
DW_AT_name("l_56")
DW_AT_decl_file ("/tmp/a.c")
DW_AT_decl_line (5)
DW_AT_decl_column (0x09)
DW_AT_type(0x003d "int")
DW_AT_location(0x000e:
[0x0040054a, 0x0040055e): DW_OP_lit6,
DW_OP_stack_value)
DW_AT_GNU_locviews(0x000c)
We have also tested older gcc versions (6.4, 7.5, 8.4, 9.3, 10.3, 11.1) and the
results are identical to the git version.
[Bug target/105247] New: IA64: ICE on sqlite-3.38.2: in decompose, at rtl.h:2288
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105247
Bug ID: 105247
Summary: IA64: ICE on sqlite-3.38.2: in decompose, at
rtl.h:2288
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at gcc dot gnu.org
Target Milestone: ---
Target: ia64-unknown-linux-gnu
Noticed when built sqlite with thsi week's gcc for ia64 target. Extracted
example:
int sqlite3CodeVerifySchemaAtToplevel_pToplevel_0;
void sqlite3CodeVerifySchema();
void sqlite3FindInIndex_pParse() {
int i = -8;
sqlite3CodeVerifySchema(sqlite3FindInIndex_pParse, i);
}
void sqlite3CodeVerifySchema(int, int iDb) {
sqlite3CodeVerifySchemaAtToplevel_pToplevel_0 |= 1 << iDb;
}
$ ia64-unknown-linux-gnu-gcc -O1 -c sqlite3-sqlite3.o.c -o a.o
during RTL pass: cse1
sqlite3-sqlite3.o.c: In function 'sqlite3FindInIndex_pParse':
sqlite3-sqlite3.o.c:7:1: internal compiler error: in decompose, at rtl.h:2288
7 | }
| ^
0xa02263 wi::int_traits >::decompose(long*,
unsigned int, std::pair const&)
../../gcc-12-20220410/gcc/rtl.h:2288
0xa02263 wide_int_ref_storage::wide_int_ref_storage
>(std::pair const&)
../../gcc-12-20220410/gcc/wide-int.h:1024
0xa02263 generic_wide_int
>::generic_wide_int >(std::pair const&)
../../gcc-12-20220410/gcc/wide-int.h:782
0xa02263 wide_int_storage::wide_int_storage
>(std::pair const&)
../../gcc-12-20220410/gcc/wide-int.h:1115
0xdc9c5b
generic_wide_int::generic_wide_int >(std::pair const&)
../../gcc-12-20220410/gcc/wide-int.h:782
0xdc9c5b simplify_const_binary_operation(rtx_code, machine_mode, rtx_def*,
rtx_def*)
../../gcc-12-20220410/gcc/simplify-rtx.cc:5069
0xdd19f8 simplify_context::simplify_binary_operation(rtx_code, machine_mode,
rtx_def*, rtx_def*)
../../gcc-12-20220410/gcc/simplify-rtx.cc:2569
0x15a2294 simplify_binary_operation(rtx_code, machine_mode, rtx_def*, rtx_def*)
../../gcc-12-20220410/gcc/rtl.h:3475
0x15a2294 fold_rtx
../../gcc-12-20220410/gcc/cse.cc:3720
0x15a39f0 cse_insn
../../gcc-12-20220410/gcc/cse.cc:4669
0x15a894f cse_extended_basic_block
../../gcc-12-20220410/gcc/cse.cc:6566
0x15a894f cse_main
../../gcc-12-20220410/gcc/cse.cc:6711
0x15a97e6 rest_of_handle_cse
../../gcc-12-20220410/gcc/cse.cc:7532
0x15a97e6 execute
../../gcc-12-20220410/gcc/cse.cc:7575
$ ia64-unknown-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/<>/ia64-unknown-linux-gnu-stage-final-gcc-debug-12.0.0/bin/ia64-unknown-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/<>/ia64-unknown-linux-gnu-stage-final-gcc-debug-12.0.0/libexec/gcc/ia64-unknown-linux-gnu/12.0.1/lto-wrapper
Target: ia64-unknown-linux-gnu
Configured with:
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.1 20220410 (experimental) (GCC)
[Bug c++/105244] [9/10/11/12 Regression] ICE in implicitly_declare_fn, at cp/method.cc:3114
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105244 Marek Polacek changed: What|Removed |Added Target Milestone|--- |9.5 Status|UNCONFIRMED |NEW Priority|P3 |P2 Ever confirmed|0 |1 CC||mpolacek at gcc dot gnu.org Last reconfirmed||2022-04-12 --- Comment #1 from Marek Polacek --- Started with r9-6097-g9d35a27a8353b5: commit 9d35a27a8353b57ed11fa1cb7d747edf1c4faa01 Author: Jason Merrill Date: Tue Feb 19 21:00:29 2019 -0500 PR c++/88368 - wrong 'use of deleted function' Unfortunately it wasn't fixed by my commit d4e0bdbc036644401f9de49f594b2bb16b287381 Author: Marek Polacek Date: Fri Mar 5 15:46:50 2021 -0500 c++: ICE on invalid with inheriting constructors [PR94751]
[Bug libbacktrace/105240] backtrace_pcinfo leaks memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105240
--- Comment #4 from Jonathan Wakely ---
The report in comment 0 is from libstdc++ which uses a local static variable to
hold the state.
Modifying the comment 1 example to use a global:
#include
int cb_pcinfo(void*, uintptr_t, const char*, int, const char* function)
{ return function != nullptr; }
int cb(void* p, uintptr_t pc) { *static_cast(p) = pc; return 1; }
backtrace_state* state;
int main()
{
state = backtrace_create_state(nullptr, 1, nullptr, nullptr);
uintptr_t pc;
backtrace_simple(state, 0, cb, nullptr, );
backtrace_pcinfo(state, pc, cb_pcinfo, nullptr, nullptr);
}
I get:
==494586== Memcheck, a memory error detector
==494586== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==494586== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info
==494586== Command: ./a.out
==494586==
==494586==
==494586== HEAP SUMMARY:
==494586== in use at exit: 112,638,181 bytes in 729,676 blocks
==494586== total heap usage: 729,861 allocs, 185 frees, 115,412,694 bytes
allocated
==494586==
==494586== 84 bytes in 3 blocks are definitely lost in loss record 6 of 35
==494586==at 0x484086F: malloc (vg_replace_malloc.c:381)
==494586==by 0x406FF1: backtrace_alloc (alloc.c:57)
==494586==by 0x409283: read_lnct (dwarf.c:2543)
==494586==by 0x409283: read_line_header_format_entries (dwarf.c:2618)
==494586==by 0x40B08A: read_line_header (dwarf.c:2712)
==494586==by 0x40B08A: read_line_info (dwarf.c:2965)
==494586==by 0x40B08A: dwarf_lookup_pc (dwarf.c:3747)
==494586==by 0x40C1BE: dwarf_fileline (dwarf.c:3935)
==494586==by 0x401357: main (bt.cc:15)
==494586==
==494586== 2,839 bytes in 1 blocks are possibly lost in loss record 19 of 35
==494586==at 0x484086F: malloc (vg_replace_malloc.c:381)
==494586==by 0x406FF1: backtrace_alloc (alloc.c:57)
==494586==by 0x406ED6: backtrace_get_view (read.c:68)
==494586==by 0x40667B: elf_add (elf.c:4381)
==494586==by 0x406D83: backtrace_initialize (elf.c:4877)
==494586==by 0x4014B1: fileline_initialize (fileline.c:261)
==494586==by 0x401581: backtrace_pcinfo (fileline.c:295)
==494586==by 0x401357: main (bt.cc:15)
==494586==
==494586== 13,920 bytes in 1 blocks are definitely lost in loss record 23 of 35
==494586==at 0x484086F: malloc (vg_replace_malloc.c:381)
==494586==by 0x406FF1: backtrace_alloc (alloc.c:57)
==494586==by 0x406ED6: backtrace_get_view (read.c:68)
==494586==by 0x40568A: elf_get_view (elf.c:426)
==494586==by 0x40568A: elf_add (elf.c:4329)
==494586==by 0x406BC8: phdr_callback (elf.c:4848)
==494586==by 0x4D2A314: dl_iterate_phdr (dl-iteratephdr.c:75)
==494586==by 0x406DDD: backtrace_initialize (elf.c:4892)
==494586==by 0x4014B1: fileline_initialize (fileline.c:261)
==494586==by 0x401581: backtrace_pcinfo (fileline.c:295)
==494586==by 0x401357: main (bt.cc:15)
==494586==
==494586== 69,736 bytes in 2 blocks are possibly lost in loss record 26 of 35
==494586==at 0x484086F: malloc (vg_replace_malloc.c:381)
==494586==by 0x406FF1: backtrace_alloc (alloc.c:57)
==494586==by 0x406ED6: backtrace_get_view (read.c:68)
==494586==by 0x40568A: elf_get_view (elf.c:426)
==494586==by 0x40568A: elf_add (elf.c:4329)
==494586==by 0x406BC8: phdr_callback (elf.c:4848)
==494586==by 0x4D2A314: dl_iterate_phdr (dl-iteratephdr.c:75)
==494586==by 0x406DDD: backtrace_initialize (elf.c:4892)
==494586==by 0x4014B1: fileline_initialize (fileline.c:261)
==494586==by 0x401581: backtrace_pcinfo (fileline.c:295)
==494586==by 0x401357: main (bt.cc:15)
==494586==
==494586== 451,020 bytes in 7 blocks are possibly lost in loss record 31 of 35
==494586==at 0x484086F: malloc (vg_replace_malloc.c:381)
==494586==by 0x406FF1: backtrace_alloc (alloc.c:57)
==494586==by 0x406ED6: backtrace_get_view (read.c:68)
==494586==by 0x40667B: elf_add (elf.c:4381)
==494586==by 0x406BC8: phdr_callback (elf.c:4848)
==494586==by 0x4D2A314: dl_iterate_phdr (dl-iteratephdr.c:75)
==494586==by 0x406DDD: backtrace_initialize (elf.c:4892)
==494586==by 0x4014B1: fileline_initialize (fileline.c:261)
==494586==by 0x401581: backtrace_pcinfo (fileline.c:295)
==494586==by 0x401357: main (bt.cc:15)
==494586==
==494586== LEAK SUMMARY:
==494586==definitely lost: 14,004 bytes in 4 blocks
==494586==indirectly lost: 0 bytes in 0 blocks
==494586== possibly lost: 523,595 bytes in 10 blocks
==494586==still reachable: 112,100,582 bytes in 729,662 blocks
==494586== suppressed: 0 bytes in 0 blocks
==494586== Reachable blocks (those to which a pointer was found) are not shown.
==494586== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==494586==
==494586== For lists of detected and suppressed errors, rerun with: -s
==494586== ERROR SUMMARY: 5 errors from 5 contexts (suppressed: 0 from 0)
So that's still 14kB definitely lost,
[Bug target/89125] Misoptimization of converting sin(x) and cos(x) into sincos(x,,)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89125 --- Comment #14 from kargl at gcc dot gnu.org --- *** Bug 105206 has been marked as a duplicate of this bug. ***
[Bug target/105206] mis-optimization with -ffast-math and __builtin_powf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105206 kargl at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |DUPLICATE --- Comment #7 from kargl at gcc dot gnu.org --- (In reply to rguent...@suse.de from comment #6) > On Mon, 11 Apr 2022, kargl at gcc dot gnu.org wrote: > > > > > This might be related to PR89125. The patch I attached to that PR has never > > found its way into the repository. I'll do some more testing later today. > > Ah, yeah - that old issue, indeed good to revisit that. It's definitely a manifestation of PR89125. I'll close this as a duplicate. *** This bug has been marked as a duplicate of bug 89125 ***
[Bug target/105246] New: [amdgcn] Use library call for SQRT with -ffast-math + provide additional option to use single-precsion opcode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105246 Bug ID: 105246 Summary: [amdgcn] Use library call for SQRT with -ffast-math + provide additional option to use single-precsion opcode Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: documentation, wrong-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org CC: ams at gcc dot gnu.org Target Milestone: --- Target: amdgcn-amdhsa AMD GCN hardware has opcodes which operate on double-precision variables as input/output but internally only do single-precision operation. This affects (currently) only "sqrt" which for -funsafe-math-optimizations (implied by -Ofast / -ffast-math) uses AMDGCN's "v_sqrt". Namely gcc/config/gcn/gcn-valu.md has: (define_insn "sqrt2" ... "flag_unsafe_math_optimizations" "v_sqrt%i0\t%0, %1" Thus: while "v_sqrt" works on double-precision variables, it only calculates with 23bits (as with float32) instead of 52bits (as float64 provides) for the fractional part of the floating-point number. PROBLEM: In many cases, this loss of precision by an order of 100,000,000 (10⁸ / 2²⁹) is very unexpected and too much for code which requires double precision. An ULP of 4 is expected not an ULP of 10⁸! In particular: In order to permit several optimizations, -Ofast or --fast-math is commonly recommended and the precision loss is unexpected. In terms of testsuites, OvO's sqrt examples are effected, requiring a way higher OVO_TOL_ULP to pass (→ https://github.com/TApplencourt/OvO ) But the issue really came up when discussion with HPC code users. EXPECTED: - By default, with -ffast-math, do the double-precision operation by a library call - Provide some (GCN-specific) -m... flag to do those calculations in single precision. For instance something like: -mpermit-reduced-precision Use hardware intrinsics instead of library even if they provide a much reduced precision. Example: use v_sqrt with double-precision variables even though the hardware only provides single-precision results for the fractional part of the floating-point variable. (Default: disabled)
[Bug c++/103057] [11 Regression] Internal compiler error: Error reporting routines re-entered since r11-291-g0f50f6daa140186a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103057 Jason Merrill changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #11 from Jason Merrill --- Fixed for 11.3.
[Bug c++/54367] [meta-bug] lambda expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54367 Bug 54367 depends on bug 103186, which changed state. Bug 103186 Summary: [11 Regression] ICE with lambda as default argument in template https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103186 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/103186] [11 Regression] ICE with lambda as default argument in template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103186 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #16 from Jason Merrill --- Fixed for 11.3.
[Bug c++/105245] New: [10/11/12 Regression] ICE in clear_no_implicit_zero, in cp/constexpr.cc:1892
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105245
Bug ID: 105245
Summary: [10/11/12 Regression] ICE in clear_no_implicit_zero,
in cp/constexpr.cc:1892
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Started between 20210411 and 20210418,
with option -fno-elide-constructors plus -std=c++11 or -std=c++14
and file g++.dg/cpp1y/constexpr-empty2.C :
$ g++-9 -c constexpr-empty2.C -fno-elide-constructors -std=c++14
$ g++-12-20220410 -c constexpr-empty2.C -fno-elide-constructors -std=c++17
$
$ g++-12-20220410 -c constexpr-empty2.C -fno-elide-constructors -std=c++14
constexpr-empty2.C: In function 'constexpr int f()':
constexpr-empty2.C:22:10: in 'constexpr' expansion of 'b2.C::C(b1)'
constexpr-empty2.C:22:10: internal compiler error: Segmentation fault
22 | C b2{b1};
| ^
0xda8c2f crash_signal
../../gcc/toplev.cc:322
0x6f902b clear_no_implicit_zero
../../gcc/cp/constexpr.cc:1892
0x6ff9db cxx_eval_call_expression
../../gcc/cp/constexpr.cc:2992
0x702388 cxx_eval_constant_expression
../../gcc/cp/constexpr.cc:6713
0x705043 cxx_eval_outermost_constant_expr
../../gcc/cp/constexpr.cc:7822
0x70843f maybe_constant_init_1
../../gcc/cp/constexpr.cc:8285
0x76f8d5 expand_default_init
../../gcc/cp/init.cc:2204
0x76f8d5 expand_aggr_init_1
../../gcc/cp/init.cc:2309
0x771489 build_aggr_init(tree_node*, tree_node*, int, int)
../../gcc/cp/init.cc:2029
0x74f02d build_aggr_init_full_exprs
../../gcc/cp/decl.cc:7183
0x74f02d check_initializer
../../gcc/cp/decl.cc:7348
0x750360 cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
../../gcc/cp/decl.cc:8379
0x8133ef cp_parser_init_declarator
../../gcc/cp/parser.cc:22821
0x7f1502 cp_parser_simple_declaration
../../gcc/cp/parser.cc:15280
0x7f2da9 cp_parser_declaration_statement
../../gcc/cp/parser.cc:14361
0x7f33ab cp_parser_statement
../../gcc/cp/parser.cc:12446
0x7f42f4 cp_parser_statement_seq_opt
../../gcc/cp/parser.cc:12850
0x7f43af cp_parser_compound_statement
../../gcc/cp/parser.cc:12802
0x812578 cp_parser_function_body
../../gcc/cp/parser.cc:25060
0x812578 cp_parser_ctor_initializer_opt_and_function_body
../../gcc/cp/parser.cc:25111
[Bug c++/105244] New: [9/10/11/12 Regression] ICE in implicitly_declare_fn, at cp/method.cc:3114
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105244
Bug ID: 105244
Summary: [9/10/11/12 Regression] ICE in implicitly_declare_fn,
at cp/method.cc:3114
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Started between 20190217 and 20190224,
with option -std=c++98 or -std=c++03 :
$ cat z1.cc
template
struct S
{
static T max();
};
template
struct V
{
double a = S::max[1]();
};
template
V<> foo()
{
return {};
}
int main()
{
V<> b = foo();
}
$ g++-12-20220410 -c z1.cc -std=c++03
z1.cc:9:12: warning: non-static data member initializers only available with
'-std=c++11' or '-std=gnu++11' [-Wc++11-extensions]
9 | double a = S::max[1]();
|^
z1.cc: In function 'V<> foo()':
z1.cc:14:10: warning: extended initializer lists only available with
'-std=c++11' or '-std=gnu++11' [-Wc++11-extensions]
14 | return {};
| ^
z1.cc:9:30: warning: pointer to a function used in arithmetic [-Wpointer-arith]
9 | double a = S::max[1]();
| ^
z1.cc:14:11: internal compiler error: in implicitly_declare_fn, at
cp/method.cc:3114
14 | return {};
| ^
0x792b1d implicitly_declare_fn(special_function_kind, tree_node*, bool,
tree_node*, tree_node*)
../../gcc/cp/method.cc:3114
0x792f5c lazily_declare_fn(special_function_kind, tree_node*)
../../gcc/cp/method.cc:3415
0x7c347c maybe_lazily_declare
../../gcc/cp/name-lookup.cc:1896
0x7c347c get_class_binding(tree_node*, tree_node*, bool)
../../gcc/cp/name-lookup.cc:1926
0x6dc612 build_user_type_conversion_1
../../gcc/cp/call.cc:4151
0x6d54e1 implicit_conversion_1
../../gcc/cp/call.cc:2091
0x6d54e1 implicit_conversion
../../gcc/cp/call.cc:2132
0x6da2ce perform_implicit_conversion_flags(tree_node*, tree_node*, int, int)
../../gcc/cp/call.cc:12710
0x898699 convert_for_initialization(tree_node*, tree_node*, tree_node*, int,
impl_conv_rhs, tree_node*, int, int)
../../gcc/cp/typeck.cc:10067
0x8992fe check_return_expr(tree_node*, bool*)
../../gcc/cp/typeck.cc:10729
0x85d31e finish_return_stmt(tree_node*)
../../gcc/cp/semantics.cc:1195
0x7f3d17 cp_parser_jump_statement
../../gcc/cp/parser.cc:14307
0x7f3d17 cp_parser_statement
../../gcc/cp/parser.cc:12312
0x7f42f4 cp_parser_statement_seq_opt
../../gcc/cp/parser.cc:12850
0x7f43af cp_parser_compound_statement
../../gcc/cp/parser.cc:12802
0x812578 cp_parser_function_body
../../gcc/cp/parser.cc:25060
0x812578 cp_parser_ctor_initializer_opt_and_function_body
../../gcc/cp/parser.cc:25111
0x812a36 cp_parser_function_definition_after_declarator
../../gcc/cp/parser.cc:31242
0x813987 cp_parser_function_definition_from_specifiers_and_declarator
../../gcc/cp/parser.cc:31158
0x813987 cp_parser_init_declarator
../../gcc/cp/parser.cc:22582
[Bug fortran/105184] ICE in gfc_array_init_size, at fortran/trans-array.cc:5841
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105184 --- Comment #7 from G. Steinmetz --- Thank you very much for fixing this problem !
