[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)
Re: [PATCH] c++: ambiguous call not diagnosed after DR2352 [PR97296]
On 4/12/22 18:50, Marek Polacek wrote:
DR 2352 changed the definitions of reference-related (so that it uses
"similar type" instead of "same type") and of reference-compatible (use
a standard conversion sequence). That means that reference-related is
now more broad, which means that we will be binding more things directly.
The original patch for DR 2352 caused some problems, which were fixed in
r276251 by creating a "fake" ck_qual in direct_reference_binding, so
that in
void f(int *); // #1
void f(const int * const &); // #2
int *x;
int main()
{
f(x); // call #1
}
we call #1. The extra ck_qual in #2 causes compare_ics to select #1,
which is a better match for "int *" because then we don't have to do
a qualification conversion.
Let's turn to the problem in this PR. We have
void f(const int * const &); // #1
void f(const int *); // #2
int *x;
int main()
{
f(x);
}
We arrive in compare_ics to decide which one is better. The ICS for #1
looks like
ck_ref_bind <-ck_qual <- ck_identity
const int *const & const int *const int *
and the ICS for #2 is
ck_qual <- ck_rvalue <- ck_identity
const int * int * int *
We strip the reference and then comp_cv_qual_signature when comparing two
ck_quals sees that "const int *" is a proper subset of "const int *const"
and we return -1. But that's wrong; presumably the top-level "const"
should be ignored and the call should be ambiguous. This patch adjust
the type of the "fake" ck_qual so that this problem doesn't arise.
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/11?
OK, thanks.
PR c++/97296
gcc/cp/ChangeLog:
* call.cc (direct_reference_binding): strip_top_quals when creating
a ck_qual.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/ref-bind4.C: Add dg-error.
* g++.dg/cpp0x/ref-bind8.C: New test.
---
gcc/cp/call.cc | 15 +--
gcc/testsuite/g++.dg/cpp0x/ref-bind4.C | 2 +-
gcc/testsuite/g++.dg/cpp0x/ref-bind8.C | 10 ++
3 files changed, 24 insertions(+), 3 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/cpp0x/ref-bind8.C
diff --git a/gcc/cp/call.cc b/gcc/cp/call.cc
index 3a8d7e4b131..fc2fc009f14 100644
--- a/gcc/cp/call.cc
+++ b/gcc/cp/call.cc
@@ -1680,8 +1680,19 @@ direct_reference_binding (tree type, conversion *conv)
because the types "int *" and "const int *const" are
reference-related and we were binding both directly and they
had the same rank. To break it up, we add a ck_qual under the
- ck_ref_bind so that conversion sequence ranking chooses #1. */
-conv = build_conv (ck_qual, t, conv);
+ ck_ref_bind so that conversion sequence ranking chooses #1.
+
+ We strip_top_quals here which is also what standard_conversion
+ does. Failure to do so would confuse comp_cv_qual_signature
+ into thinking that in
+
+void f(const int * const &); // #1
+void f(const int *); // #2
+int *x;
+f(x);
+
+ #2 is a better match than #1 even thought they're ambiguous (97296). */
+conv = build_conv (ck_qual, strip_top_quals (t), conv);
return build_conv (ck_ref_bind, type, conv);
}
diff --git a/gcc/testsuite/g++.dg/cpp0x/ref-bind4.C
b/gcc/testsuite/g++.dg/cpp0x/ref-bind4.C
index 85ac9fbfd79..d296d7c3b72 100644
--- a/gcc/testsuite/g++.dg/cpp0x/ref-bind4.C
+++ b/gcc/testsuite/g++.dg/cpp0x/ref-bind4.C
@@ -51,6 +51,6 @@ g (int *p, const int *pc, const int **q)
similar types T1 and T2 (_conv.qual_), respectively, and the cv-
qualification signature of type T1 is a proper subset of the cv-
qualification signature of type T2 */
- f8 (q);
+ f8 (q); // { dg-error "call of overloaded" }
f9 (q);
}
diff --git a/gcc/testsuite/g++.dg/cpp0x/ref-bind8.C
b/gcc/testsuite/g++.dg/cpp0x/ref-bind8.C
new file mode 100644
index 000..eee78fd5e74
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/ref-bind8.C
@@ -0,0 +1,10 @@
+// PR c++/97296
+// { dg-do compile }
+
+void f(const int * const &);
+void f(const int *);
+int *x;
+int main()
+{
+ f(x); // { dg-error "call of overloaded" }
+}
base-commit: 3c742621ed28540cf42d4cfbc2bf03433cd26738
[PATCH v2] rs6000: Fix the check of bif argument number [PR104482]
Hi, As PR104482 shown, it's one regression about the handlings when the argument number is more than the one of built-in function prototype. The new bif support only catches the case that the argument number is less than the one of function prototype, but it misses the case that the argument number is more than the one of function prototype. Because it uses "n != expected_args", n is updated in for (n = 0; !VOID_TYPE_P (TREE_VALUE (fnargs)) && n < nargs; fnargs = TREE_CHAIN (fnargs), n++) , it's restricted to be less than or equal to expected_args with the guard !VOID_TYPE_P (TREE_VALUE (fnargs)), so it's wrong. The fix is to use nargs instead, also move the checking hunk's location ahead to avoid useless further scanning when the counts mismatch. Bootstrapped and regtested on powerpc64-linux-gnu P8 and powerpc64le-linux-gnu P9 and P10. Is it ok for trunk? v2: Add one test case and refine commit logs. v1: https://gcc.gnu.org/pipermail/gcc-patches/2022-March/591768.html BR, Kewen PR target/104482 gcc/ChangeLog: * config/rs6000/rs6000-c.cc (altivec_resolve_overloaded_builtin): Fix the equality check for argument number, and move this hunk ahead. gcc/testsuite/ChangeLog: * gcc.target/powerpc/pr104482.c: New test. --- gcc/config/rs6000/rs6000-c.cc | 60 ++--- gcc/testsuite/gcc.target/powerpc/pr104482.c | 16 ++ 2 files changed, 46 insertions(+), 30 deletions(-) create mode 100644 gcc/testsuite/gcc.target/powerpc/pr104482.c diff --git a/gcc/config/rs6000/rs6000-c.cc b/gcc/config/rs6000/rs6000-c.cc index 84bb98f94fb..fa0c93e1841 100644 --- a/gcc/config/rs6000/rs6000-c.cc +++ b/gcc/config/rs6000/rs6000-c.cc @@ -1755,6 +1755,36 @@ altivec_resolve_overloaded_builtin (location_t loc, tree fndecl, vec *arglist = static_cast *> (passed_arglist); unsigned int nargs = vec_safe_length (arglist); + /* If the number of arguments did not match the prototype, return NULL + and the generic code will issue the appropriate error message. Skip + this test for functions where we don't fully describe all the possible + overload signatures in rs6000-overload.def (because they aren't relevant + to the expansion here). If we don't, we get confusing error messages. */ + /* As an example, for vec_splats we have: + +; There are no actual builtins for vec_splats. There is special handling for +; this in altivec_resolve_overloaded_builtin in rs6000-c.cc, where the call +; is replaced by a constructor. The single overload here causes +; __builtin_vec_splats to be registered with the front end so that can happen. +[VEC_SPLATS, vec_splats, __builtin_vec_splats] + vsi __builtin_vec_splats (vsi); +ABS_V4SI SPLATS_FAKERY + +So even though __builtin_vec_splats accepts all vector types, the +infrastructure cheats and just records one prototype. We end up getting +an error message that refers to this specific prototype even when we +are handling a different argument type. That is completely confusing +to the user, so it's best to let these cases be handled individually +in the resolve_vec_splats, etc., helper functions. */ + + if (expected_args != nargs + && !(fcode == RS6000_OVLD_VEC_PROMOTE + || fcode == RS6000_OVLD_VEC_SPLATS + || fcode == RS6000_OVLD_VEC_EXTRACT + || fcode == RS6000_OVLD_VEC_INSERT + || fcode == RS6000_OVLD_VEC_STEP)) +return NULL; + for (n = 0; !VOID_TYPE_P (TREE_VALUE (fnargs)) && n < nargs; fnargs = TREE_CHAIN (fnargs), n++) @@ -1815,36 +1845,6 @@ altivec_resolve_overloaded_builtin (location_t loc, tree fndecl, types[n] = type; } - /* If the number of arguments did not match the prototype, return NULL - and the generic code will issue the appropriate error message. Skip - this test for functions where we don't fully describe all the possible - overload signatures in rs6000-overload.def (because they aren't relevant - to the expansion here). If we don't, we get confusing error messages. */ - /* As an example, for vec_splats we have: - -; There are no actual builtins for vec_splats. There is special handling for -; this in altivec_resolve_overloaded_builtin in rs6000-c.cc, where the call -; is replaced by a constructor. The single overload here causes -; __builtin_vec_splats to be registered with the front end so that can happen. -[VEC_SPLATS, vec_splats, __builtin_vec_splats] - vsi __builtin_vec_splats (vsi); -ABS_V4SI SPLATS_FAKERY - -So even though __builtin_vec_splats accepts all vector types, the -infrastructure cheats and just records one prototype. We end up getting -an error message that refers to this specific prototype even when we -are handling a different argument type. That is completely confusing -to the user, so it's best to let these cases be handled individually -in the resolve_vec_splats, etc., helper functions. */
[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.
Re: [PATCH] ppc: testsuite: skip pr60203 on no ldbl128
On Apr 12, 2022, Segher Boessenkool wrote:
> Hi!
> On Mon, Apr 11, 2022 at 08:57:07PM -0300, Alexandre Oliva wrote:
>> If neither 128-bit long double format is available, skip pr60203.c.
>>
>> Tested with gcc-11 targeting ppc64-vx7r2, with neither long double
>> format enabled. Ok to install?
> Can you use check_effective_target_longdouble128 instead?
> /* { dg-require-effective-target longdouble128 } */
> Okay for trunk, preferably like that. Thanks!
Thanks, here's what I'm installing
ppc: testsuite: skip pr60203 on no ldbl128
If neither 128-bit long double format is available, skip pr60203.c.
for gcc/testsuite/ChangeLog
* gcc.target/powerpc/pr60203.c: Skip on no 128-bit long double.
---
gcc/testsuite/gcc.target/powerpc/pr60203.c |1 +
1 file changed, 1 insertion(+)
diff --git a/gcc/testsuite/gcc.target/powerpc/pr60203.c
b/gcc/testsuite/gcc.target/powerpc/pr60203.c
index 7ada64a32db45..a5a574a883729 100644
--- a/gcc/testsuite/gcc.target/powerpc/pr60203.c
+++ b/gcc/testsuite/gcc.target/powerpc/pr60203.c
@@ -1,5 +1,6 @@
/* { dg-do compile { target { powerpc*-*-* && lp64 } } } */
/* { dg-skip-if "" { powerpc*-*-darwin* } } */
+/* { dg-require-effective-target longdouble128 } */
/* { dg-require-effective-target powerpc_p8vector_ok } */
/* { dg-options "-mdejagnu-cpu=power8 -O3" } */
--
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
Free Software Activist GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts. Ask me about
[PATCH, V4] Eliminate power8 fusion options, use power8 tuning, PR target/102059
Eliminate power8 fusion options, use power8 tuning, PR target/102059
This is V4 of the patch. Compared to V3 of the patch, GCC will just
ignore -m{,no-}power8-fusion and -m{,no-}power8-fusion-sign.
The splitting of signed halfword and word loads into unsigned load and
sign extension is now suppressed with -Os, but it is done normally if we
are not optimizing for space.
The power8 fusion support used to be set automatically when -mcpu=power8 or
-mtune=power8 was used, and it was cleared for other cpu's. However, if you
used the target attribute or target #pragma to change the default cpu type or
tuning, you would get an error that a target specifiction option mismatch
occurred.
This occurred because the rs6000_can_inline_p function just compares the ISA
bits between the called inline function and the caller. If the ISA flags of
the called function is not a subset of the ISA flags of the caller, we won't do
the inlinging. When a power9 or power10 function inlines a function that is
explicitly compiled for power8, the power8 function has the power8 fusion bits
set and the power9 or power10 functions do not have the fusion bits set.
This code makes the -mpower8-fusion option a nop. It is accepted without
warning, but it does nothing. Power8 fusion is only enabled if we are tuning
for a power8.
The undocumented -mpower8-fusion-sign option is also made into a nop.
I left in the pragma target and attribute target support for power8-fusion, but
using it doesn't do anything now. This is because I told the customer who
encountered this problem that one solution was to add an explicit
no-power8-fusion option in their target pragma or attribute to work around the
problem.
I have tested this patch on a little endian power10 system. I have tested
previous versions on little endian power9 and big endian power8 systems.
Can I apply this patch to the master branch?
If it is accepted, I will produce a similar patch for back porting to GCC 11
and GCC 10.
2022-04-12 Michael Meissner
gcc/
PR target/102059
* config/rs6000/rs6000-cpus.def (OTHER_FUSION_MASKS): Delete.
(ISA_3_0_MASKS_SERVER): Don't clear the fusion masks.
(POWERPC_MASKS): Remove OPTION_MASK_P8_FUSION.
* config/rs6000/rs6000.cc (rs6000_option_override_internal):
Delete code that set the power8 fusion options automatically.
(rs6000_opt_masks): Allow #pragma target and attribute target
power8-fusion option for backwards compatibility.
(rs6000_print_options_internal): Skip printing backward
compatibility options that are just ignored.
* config/rs6000/rs6000.h (TARGET_P8_FUSION): New macro.
(TARGET_P8_FUSION_SIGN): Likewise.
(MASK_P8_FUSION): Delete.
* config/rs6000/rs6000.opt (-mpower8-fusion): Recognize the option but
ignore it completely.
(-mpower8-fusion-sign): Likewise.
* doc/invoke.texi (RS/6000 and PowerPC Options): Delete
-mpower8-fusion.
gcc/testsuite/
PR target/102059
* gcc.dg/lto/pr102059-1_0.c: Remove -mno-power8-fusion.
* gcc.dg/lto/pr102059-2_0.c: Likewise.
* gcc.target/powerpc/pr102059-3.c: Likewise.
* gcc.target/powerpc/pr102059-4.c: New test.
---
gcc/config/rs6000/rs6000-cpus.def | 18 +++
gcc/config/rs6000/rs6000.cc | 49 +--
gcc/config/rs6000/rs6000.h| 13 -
gcc/config/rs6000/rs6000.opt | 8 +--
gcc/doc/invoke.texi | 13 +
gcc/testsuite/gcc.dg/lto/pr102059-1_0.c | 2 +-
gcc/testsuite/gcc.dg/lto/pr102059-2_0.c | 2 +-
gcc/testsuite/gcc.target/powerpc/pr102059-3.c | 2 +-
gcc/testsuite/gcc.target/powerpc/pr102059-4.c | 23 +
9 files changed, 62 insertions(+), 68 deletions(-)
create mode 100644 gcc/testsuite/gcc.target/powerpc/pr102059-4.c
diff --git a/gcc/config/rs6000/rs6000-cpus.def
b/gcc/config/rs6000/rs6000-cpus.def
index 963947f6939..d913a3d6b73 100644
--- a/gcc/config/rs6000/rs6000-cpus.def
+++ b/gcc/config/rs6000/rs6000-cpus.def
@@ -54,19 +54,14 @@
| OPTION_MASK_QUAD_MEMORY \
| OPTION_MASK_QUAD_MEMORY_ATOMIC)
-/* ISA masks setting fusion options. */
-#define OTHER_FUSION_MASKS (OPTION_MASK_P8_FUSION \
-| OPTION_MASK_P8_FUSION_SIGN)
-
/* Add ISEL back into ISA 3.0, since it is supposed to be a win. Do not add
FLOAT128_HW here until we are ready to make -mfloat128 on by default. */
-#define ISA_3_0_MASKS_SERVER ((ISA_2_7_MASKS_SERVER \
- | OPTION_MASK_ISEL\
- | OPTION_MASK_MODULO \
- | OPTION_MASK_P9_MINMAX \
- | OPTION_MASK_P9_MISC \
-
Re: [PATCH] rs6000: Guard bifs {un, }pack_{longdouble, ibm128} under hard float [PR103623]
on 2022/4/13 3:11 AM, Segher Boessenkool wrote:
> On Tue, Apr 12, 2022 at 10:02:06AM +0800, Kewen.Lin wrote:
>> on 2022/4/11 11:42 PM, Segher Boessenkool wrote:
>>> On Mon, Apr 11, 2022 at 04:29:40PM +0800, Kewen.Lin wrote:
Nice, I confirmed this makes ICE gone, I've filed one new PR
PR105213 for GCC13 further tracking by associating this patch there.
>>>
>>> Cool, I'll commit it later today then (after a final regstrap). The
>>> _nodm pattern just missed the alternative for no FP regs (the _dm
>>> pattern has it, so just an oversight).
>>
>> Thanks! So it can be counted as a regression fix instead of tiny
>> feature work? Maybe we also need bif documentation change, and
>> gcc12 changes html update (as bif behavior changes), or it's
>> too small so no?
>
> It is just a bugfix. Everything in anything that is not a new feature
> is arguably a regression fix, so that classification isn't useful
> normally. I'd rather fix more bugs than do more filing work ;-)
>
> The documentation already has this under "The following built-in
> functions are also available on all PowerPC processors:", so no doc
> changes are needed either: this is a bugfix! :-)
>
>
Thanks for the explanation!!
As to the documentation, there seem some contradictions.
On page[1], we only have the description for {un,}pack_{ibm128}, that is:
"
The following built-in functions are also available on all PowerPC processors:
uint64_t __builtin_ppc_get_timebase ();
unsigned long __builtin_ppc_mftb ();
double __builtin_unpack_ibm128 (__ibm128, int);
__ibm128 __builtin_pack_ibm128 (double, double);
double __builtin_mffs (void);
void __builtin_mtfsf (const int, double);
void __builtin_mtfsb0 (const int);
void __builtin_mtfsb1 (const int);
void __builtin_set_fpscr_rn (int);
"
On page[2], we have the description for both {un,}pack_{ibm128} and
{un,}pack_{longdouble}
"
**The following functions require -mhard-float and -mmultiple options.**
The __builtin_unpack_longdouble function takes a long double argument and a
compile time constant of 0 or 1. If the constant is 0, the first double within
the long double is returned, otherwise the second double is returned. The
__builtin_unpack_longdouble function is only available if long double uses the
IBM extended double representation.
The __builtin_pack_longdouble function takes two double arguments and returns a
long double value that combines the two arguments. The
__builtin_pack_longdouble function is only available if long double uses the
IBM extended double representation.
The __builtin_unpack_ibm128 function takes a __ibm128 argument and a compile
time constant of 0 or 1. If the constant is 0, the first double within the
__ibm128 is returned, otherwise the second double is returned.
The __builtin_pack_ibm128 function takes two double arguments and returns a
__ibm128 value that combines the two arguments.
Additional built-in functions are available for the 64-bit PowerPC family of
processors, for efficient use of 128-bit floating point (__float128) values.
"
By comparing the above, we seemed to place the documentation for
{un,}pack_{ibm128} in the former wrongly.
And need to update page[2] according to the recent change?
[1]
https://gcc.gnu.org/onlinedocs/gcc/Basic-PowerPC-Built-in-Functions-Available-on-all-Configurations.html#Basic-PowerPC-Built-in-Functions-Available-on-all-Configurations
[2]
https://gcc.gnu.org/onlinedocs/gcc/Basic-PowerPC-Built-in-Functions-Available-on-ISA-2_002e05.html#Basic-PowerPC-Built-in-Functions-Available-on-ISA-2_002e05
BR,
Kewen
Re: [PATCH] ppc: testsuite: test for arch_pwr7 with -mvsx in fold-vec-insert-double
On Apr 12, 2022, Segher Boessenkool wrote:
> On Mon, Apr 11, 2022 at 08:59:41PM -0300, Alexandre Oliva wrote:
>>
>> gcc.target/powerpc/fold-vec-insert-double.c is compiled with -mvsx,
>> while the expected asm output depends on target has_arch_pwr7, which
>> is tested for without -mvsx.
>>
>> In some of our configurations, that have altivec and vsx disabled by
>> default, the former defines up to _ARCH_PWR7, while the latter defines
>> only up to _ARCH_PWR4, i.e., we compile for power7, and test for
>> non-power7.
> You cannot use -mvsx if you do not have -mcpu=power7 (or higher). If
> -mvsx is allowed (i.e. when powerpc_vsx_ok is satisfied) you always are
> compiling for power7 or higher.
> What goes wrong?
What goes wrong is that, because target has_arch_pwr7 runs the compiler
without -mvsx, it gets only power4, so we test for the asm associated
with target { ! has_arch_pwr7 }, which is not what's generated.
Now, since -mvsx requires power7, it looks like the scan-assembler tests
with target { ! has_arch_pwr7 } could be dropped, since they can
(should) never run, and so could the target { has_arch_pwr7 }
conditionals, since they can (should) be taken for granted.
That makes for a much nicer patch. Tested on x86_64-linux-gnu cross to
ppc64-vx7r2. Ok to install?
ppc: testsuite: drop pwr7 conds in fold-vec-insert-double-insert-double
gcc.target/powerpc/fold-vec-insert-double.c is compiled with -mvsx,
which implies power7, but there are scan-assembler checks that depend
on target has_arch_pwr7, negated or not, and that target conditional
is tested for running the compiler without -mvsx.
In some of our configurations, that have altivec and vsx disabled by
default, the former defines up to _ARCH_PWR7, while the latter defines
only up to _ARCH_PWR4, i.e., we compile for power7, and test for
non-power7.
Since -mvsx implies power7, the tests for target has_arch_pwr7 would
be redundant if performed with -mvsx, so I'm dropping the checks
guarded by ! has_arch_pwr7, and dropping has_arch_pwr7 from the
others.
for gcc/testsuite/ChangeLog
* gcc.target/powerpc/fold-vec-insert-double.c: Constant-fold
has_arch_pwr7, implied by -mvsx.
---
.../gcc.target/powerpc/fold-vec-insert-double.c| 16 ++--
1 file changed, 6 insertions(+), 10 deletions(-)
diff --git a/gcc/testsuite/gcc.target/powerpc/fold-vec-insert-double.c
b/gcc/testsuite/gcc.target/powerpc/fold-vec-insert-double.c
index afd7f7e9924e8..e99d5f40b2da9 100644
--- a/gcc/testsuite/gcc.target/powerpc/fold-vec-insert-double.c
+++ b/gcc/testsuite/gcc.target/powerpc/fold-vec-insert-double.c
@@ -24,15 +24,11 @@ testd_cst (double d, vector double vd)
/* { dg-final { scan-assembler-times {\mrldic\M|\mrlwinm\M} 1 } } */
-/* { dg-final { scan-assembler-times {\mstxvd2x\M|\mstxv\M|\mstvx\M} 1 {
target { ! has_arch_pwr7 } } } } */
-/* { dg-final { scan-assembler-times {\mstfdx\M|\mstfd\M} 1 { target { !
has_arch_pwr7 } } } } */
-/* { dg-final { scan-assembler-times {\mlxvd2x\M|\mlxv\M|\mlvx\M} 1 { target {
! has_arch_pwr7 } } } } */
+/* { dg-final { scan-assembler-times {\mstxvd2x\M|\mstxv\M|\mstvx\M} 0 {
target { lp64 } } } } */
+/* { dg-final { scan-assembler-times {\mstfdx\M|\mstfd\M} 0 { target { lp64 }
} } } */
-/* { dg-final { scan-assembler-times {\mstxvd2x\M|\mstxv\M|\mstvx\M} 0 {
target { has_arch_pwr7 && lp64 } } } } */
-/* { dg-final { scan-assembler-times {\mstfdx\M|\mstfd\M} 0 { target {
has_arch_pwr7 && lp64 } } } } */
-
-/* { dg-final { scan-assembler-times {\mlxvd2x\M|\mlxv\M|\mlvx\M} 0 { target {
has_arch_pwr7 && lp64 } } } } */
-/* { dg-final { scan-assembler-times {\mlxvd2x\M|\mlxv\M|\mlvx\M} 0 { target {
has_arch_pwr7 && ilp32 } } } } */
-/* { dg-final { scan-assembler-times {\mstxvd2x\M|\mstxv\M|\mstvx\M} 0 {
target { has_arch_pwr7 && ilp32 } } } } */
-/* { dg-final { scan-assembler-times {\mstfdx\M|\mstfd\M} 0 { target {
has_arch_pwr7 && ilp32 } } } } */
+/* { dg-final { scan-assembler-times {\mlxvd2x\M|\mlxv\M|\mlvx\M} 0 { target {
lp64 } } } } */
+/* { dg-final { scan-assembler-times {\mlxvd2x\M|\mlxv\M|\mlvx\M} 0 { target {
ilp32 } } } } */
+/* { dg-final { scan-assembler-times {\mstxvd2x\M|\mstxv\M|\mstvx\M} 0 {
target { ilp32 } } } } */
+/* { dg-final { scan-assembler-times {\mstfdx\M|\mstfd\M} 0 { target { ilp32 }
} } } */
--
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
Free Software Activist GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts. Ask me about
[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)
[PATCH] c++: ambiguous call not diagnosed after DR2352 [PR97296]
DR 2352 changed the definitions of reference-related (so that it uses
"similar type" instead of "same type") and of reference-compatible (use
a standard conversion sequence). That means that reference-related is
now more broad, which means that we will be binding more things directly.
The original patch for DR 2352 caused some problems, which were fixed in
r276251 by creating a "fake" ck_qual in direct_reference_binding, so
that in
void f(int *); // #1
void f(const int * const &); // #2
int *x;
int main()
{
f(x); // call #1
}
we call #1. The extra ck_qual in #2 causes compare_ics to select #1,
which is a better match for "int *" because then we don't have to do
a qualification conversion.
Let's turn to the problem in this PR. We have
void f(const int * const &); // #1
void f(const int *); // #2
int *x;
int main()
{
f(x);
}
We arrive in compare_ics to decide which one is better. The ICS for #1
looks like
ck_ref_bind <-ck_qual <- ck_identity
const int *const & const int *const int *
and the ICS for #2 is
ck_qual <- ck_rvalue <- ck_identity
const int * int * int *
We strip the reference and then comp_cv_qual_signature when comparing two
ck_quals sees that "const int *" is a proper subset of "const int *const"
and we return -1. But that's wrong; presumably the top-level "const"
should be ignored and the call should be ambiguous. This patch adjust
the type of the "fake" ck_qual so that this problem doesn't arise.
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/11?
PR c++/97296
gcc/cp/ChangeLog:
* call.cc (direct_reference_binding): strip_top_quals when creating
a ck_qual.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/ref-bind4.C: Add dg-error.
* g++.dg/cpp0x/ref-bind8.C: New test.
---
gcc/cp/call.cc | 15 +--
gcc/testsuite/g++.dg/cpp0x/ref-bind4.C | 2 +-
gcc/testsuite/g++.dg/cpp0x/ref-bind8.C | 10 ++
3 files changed, 24 insertions(+), 3 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/cpp0x/ref-bind8.C
diff --git a/gcc/cp/call.cc b/gcc/cp/call.cc
index 3a8d7e4b131..fc2fc009f14 100644
--- a/gcc/cp/call.cc
+++ b/gcc/cp/call.cc
@@ -1680,8 +1680,19 @@ direct_reference_binding (tree type, conversion *conv)
because the types "int *" and "const int *const" are
reference-related and we were binding both directly and they
had the same rank. To break it up, we add a ck_qual under the
- ck_ref_bind so that conversion sequence ranking chooses #1. */
-conv = build_conv (ck_qual, t, conv);
+ ck_ref_bind so that conversion sequence ranking chooses #1.
+
+ We strip_top_quals here which is also what standard_conversion
+ does. Failure to do so would confuse comp_cv_qual_signature
+ into thinking that in
+
+void f(const int * const &); // #1
+void f(const int *); // #2
+int *x;
+f(x);
+
+ #2 is a better match than #1 even thought they're ambiguous (97296). */
+conv = build_conv (ck_qual, strip_top_quals (t), conv);
return build_conv (ck_ref_bind, type, conv);
}
diff --git a/gcc/testsuite/g++.dg/cpp0x/ref-bind4.C
b/gcc/testsuite/g++.dg/cpp0x/ref-bind4.C
index 85ac9fbfd79..d296d7c3b72 100644
--- a/gcc/testsuite/g++.dg/cpp0x/ref-bind4.C
+++ b/gcc/testsuite/g++.dg/cpp0x/ref-bind4.C
@@ -51,6 +51,6 @@ g (int *p, const int *pc, const int **q)
similar types T1 and T2 (_conv.qual_), respectively, and the cv-
qualification signature of type T1 is a proper subset of the cv-
qualification signature of type T2 */
- f8 (q);
+ f8 (q); // { dg-error "call of overloaded" }
f9 (q);
}
diff --git a/gcc/testsuite/g++.dg/cpp0x/ref-bind8.C
b/gcc/testsuite/g++.dg/cpp0x/ref-bind8.C
new file mode 100644
index 000..eee78fd5e74
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/ref-bind8.C
@@ -0,0 +1,10 @@
+// PR c++/97296
+// { dg-do compile }
+
+void f(const int * const &);
+void f(const int *);
+int *x;
+int main()
+{
+ f(x); // { dg-error "call of overloaded" }
+}
base-commit: 3c742621ed28540cf42d4cfbc2bf03433cd26738
--
2.35.1
Re: rustc_codegen_gcc and libgccjit for GCC 12 ?
On Mon, 2022-04-11 at 19:56 -0400, David Malcolm wrote: > On Fri, 2022-04-08 at 16:37 -0400, Antoni Boucher wrote: > > On Fri, 2022-04-08 at 15:36 -0400, David Malcolm wrote: > > [...snip...] > > > > > > > > > So I think I'm waiting on an updated version of the sized- > > > integer- > > > types > > > patch, and some nit-fixes for the other patches (but am > > > disappearing > > > on > > > vacation on 18th - 22nd). > > > > I'll update the patches to address your review over the weekend. > > Thanks! > > Thanks. > > I've been working through them today, fixing things up so they commit > cleanly, and fixing a few more nits, but it's clear I'm not going to > be > done tonight. > > I hope to push the 5 jit patches to trunk for GCC 12 tomorrow > (assuming > my tests pass). I've now pushed the 5 jit patches to trunk for GCC 12, as r12-8116-gaf80ea97b61847 through: r12-8120-g6e5ad1cc24a315 after successful bootstrap and regression testing on x86_64-pc-linux- gnu; see various other recent mails to the gcc-patches/jit mailing lists for the details of the specific patches. Hopefully that's everything that will be needed for gcc 12 for a version of rustc_codegen_gcc to be able to use upstream gcc 12 libgccjit (and that I didn't break anything). I'm working on a wwwdocs patch for the GCC 12 release notes (for these libgccjit API extensions). Thanks again for all the patches Dave
[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.
Re: [PATCH] libgccjit: Add support for setting the alignment [PR104293]
On Sat, 2022-04-09 at 13:50 -0400, Antoni Boucher wrote: > Here's the updated patch. > > On Fri, 2022-04-08 at 15:01 -0400, David Malcolm wrote: > > On Sun, 2022-01-30 at 20:38 -0500, Antoni Boucher via Gcc-patches > > wrote: > > > Hi. > > > This patch adds support for setting the alignment of variables in > > > libgccjit. > > > > Thanks. Sorry about the delay in reviewing it. > > > > > > > > I was wondering if I should change it so that it takes/returns > > > bytes > > > instead of bits. > > > What do you think? > > > > I'm not sure, but given that C refers to bytes for this: > > https://en.cppreference.com/w/c/language/object#Alignment > > https://en.cppreference.com/w/c/language/_Alignof > > ...I think bytes is the better choice, to maximize similarity with C. > > Ok, I updated it to use bytes. Thanks. I updated the patch slightly: * fixed up some hunks that didn't quite apply * tweaked the comment in all-non-failing-tests.h * some whitespace fixes, and a couple of "alignement" to "alignment" spelling fixes * added an ", in bytes" to the doc for gcc_jit_lvalue_set_alignment. * regenerated .texinfo from .rst Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu. I've pushed the patch to trunk for GCC 12 as r12-8120-g6e5ad1cc24a315. https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=6e5ad1cc24a315d07f24c95d76c269cafe2a8182 Thanks again for all the patches Dave > > > > Does anything support/need a fraction-of-a-byte alignment? If so, > > then > > bits would be the way to go. > > > > > > > diff --git a/gcc/jit/docs/topics/compatibility.rst > > > b/gcc/jit/docs/topics/compatibility.rst > > > index 16cebe31a10..1957399dceb 100644 > > > --- a/gcc/jit/docs/topics/compatibility.rst > > > +++ b/gcc/jit/docs/topics/compatibility.rst > > > @@ -302,3 +302,13 @@ thread-local storage model of a variable: > > > section of a variable: > > > > > > * :func:`gcc_jit_lvalue_set_link_section` > > > + > > > +.. _LIBGCCJIT_ABI_24: > > > + > > > +``LIBGCCJIT_ABI_24`` > > > +--- > > > +``LIBGCCJIT_ABI_24`` covers the addition of functions to get and > > > set the > > > +alignement of a variable: > > > + > > > + * :func:`gcc_jit_lvalue_set_alignment` > > > + * :func:`gcc_jit_lvalue_get_alignment` > > > diff --git a/gcc/jit/docs/topics/expressions.rst > > > b/gcc/jit/docs/topics/expressions.rst > > > index 791a20398ca..0f5f5376d8c 100644 > > > --- a/gcc/jit/docs/topics/expressions.rst > > > +++ b/gcc/jit/docs/topics/expressions.rst > > > @@ -738,6 +738,45 @@ where the rvalue is computed by reading from > > > the storage area. > > > > > > #ifdef LIBGCCJIT_HAVE_gcc_jit_lvalue_set_link_section > > > > > > +.. function:: void > > > + gcc_jit_lvalue_set_alignment (gcc_jit_lvalue > > > *lvalue, > > > + int alignment) > > > + > > > + Set the alignment of a variable. > > > + The parameter ``alignment`` is in bits. Analogous to: > > > + > > > + .. code-block:: c > > > + > > > + int variable __attribute__((aligned (16))); > > > + > > > + in C, but in bits instead of bytes. > > > > If we're doing it in bytes, this will need updating, of course. > > > > Maybe rename the int param from "alignment" to "bytes" to make this > > clearer. > > > > Probably should be unsigned as well. > > > > > + > > > + This entrypoint was added in :ref:`LIBGCCJIT_ABI_24`; you can > > > test for > > > + its presence using > > > + > > > + .. code-block:: c > > > + > > > + #ifdef LIBGCCJIT_HAVE_ALIGNMENT > > > + > > > +.. function:: int > > > + gcc_jit_lvalue_get_alignment (gcc_jit_lvalue > > > *lvalue) > > > + > > > + Return the alignment of a variable set by > > > ``gcc_jit_lvalue_set_alignment``, in bits. > > > + Return 0 if the alignment was not set. Analogous to: > > > + > > > + .. code-block:: c > > > + > > > + _Alignof (variable) > > > + > > > + in C, but in bits instead of bytes. > > > > Likewise this will need updating. > > > > > + > > > + This entrypoint was added in :ref:`LIBGCCJIT_ABI_24`; you can > > > test for > > > + its presence using > > > + > > > + .. code-block:: c > > > + > > > + #ifdef LIBGCCJIT_HAVE_ALIGNMENT > > > + > > > Global variables > > > > > > > > > > [...snip...] > > > > > diff --git a/gcc/jit/libgccjit.cc b/gcc/jit/libgccjit.cc > > > index 4c352e8c93d..e03f15ec9c8 100644 > > > --- a/gcc/jit/libgccjit.cc > > > +++ b/gcc/jit/libgccjit.cc > > > @@ -2649,6 +2649,31 @@ gcc_jit_lvalue_set_link_section > > > (gcc_jit_lvalue *lvalue, > > > lvalue->set_link_section (section_name); > > > } > > > > > > +/* Public entrypoint. See description in libgccjit.h. > > > + > > > + After error-checking, the real work is done by the > > > + gcc::jit::recording::lvalue::get_link_section method in jit- > > > recording.cc. */ > > > > Comment refers to wrong function. > > > > > + > > > +int > > > +gcc_jit_lvalue_get_alignment
Re: [PATCH] libgccjit: Add option to hide stderr logs [PR104073]
On Mon, 2022-01-24 at 17:55 -0500, David Malcolm wrote: > On Sun, 2022-01-23 at 12:34 -0500, Antoni Boucher wrote: > > Thanks for the review. > > Here's the updated patch. > > Tnanks. The updated patch looks good to me, but we need to get release > manager approval for adding stuff in stage 4; I'll email them when I've > looked at the other pending patches. I updated the patch slightly: * fixed a copy typo in the comment for LIBGCCJIT_HAVE_gcc_jit_context_set_bool_print_errors_to_stderr * regenerated .texinfo from .rst Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu. I've pushed the patch to trunk for GCC 12 as r12-8119-g79e1a6fb9babb3. https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=79e1a6fb9babb34dfcb99964c37d3c4f8bb619ca Thanks again for the patch Dave > > Dave > > > > > Le mardi 18 janvier 2022 à 18:22 -0500, David Malcolm a écrit : > > > On Mon, 2022-01-17 at 21:02 -0500, Antoni Boucher via Gcc-patches > > > wrote: > > > > Hi. > > > > This option will be useful for rustc_codegen_gcc to hide the > > > > error > > > > about unsupported 128-bit integer types. > > > > > > > > David, if you know of a better way to check if these types are > > > > supported than creating such a type and checking if it causes an > > > > error, > > > > I will not need this patch. > > > > > > Off the top of my head I don't know of such a way. > > > > > > That said, this seems to be vaguely analogous to a test in a > > > "configure" script, attempting a compile and seeing if it succeeds. > > > > > > This seems like a useful pattern for libgccjit to support, so that > > > client code can query the capabilities of the host, so I think the > > > idea > > > of this patch is sound. > > > > > > As for the details of the patch, I don't like adding new members to > > > the > > > enums in libgccjit.h; I prefer adding new entrypoints, as the > > > latter > > > gives a way to tell if client code uses the new entrypoint as part > > > of > > > the ELF metadata, so that we can tell directly that client code is > > > incompatible with an older libgccjit.so from the symbol metadata in > > > the > > > built binary. > > > > > > So I'd prefer something like: > > > > > > extern void > > > gcc_jit_context_set_bool_print_errors_to_stderr (gcc_jit_context > > > *ctxt, > > > int enabled); > > > > > > where gcc_jit_context_set_bool_print_errors_to_stderr defaults to > > > true, > > > but client code can use: > > > > > > gcc_jit_context_set_bool_print_errors_to_stderr (ctxt, false); > > > > > > Or maybe have a way to specify the FILE * for errors to be printed > > > to, > > > defaulting to stderr, but settable to NULL if you want to suppress > > > the > > > printing? That might be more flexible. > > > > > > Thoughts? > > > Dave > > > > > > >
Re: [PATCH] libgccjit: Add support for register variables [PR104072]
On Wed, 2022-02-09 at 20:33 -0500, Antoni Boucher wrote:
> Here's the updated patch.
Thanks.
I updated the patch somewhat:
* fixed up some hunks that didn't quite apply
* tweaked the comment in all-non-failing-tests.h
* fixed continuation lines in .rst ". function::" clause
* test-error-register* was failing: I forcibly disabled colorization
in diagnostic, by adding:
gcc_jit_context_add_command_line_option
(ctxt, "-fdiagnostics-color=never");
to harness.h, to avoid possible difference in output based on whether
stderr is connected to a tty
* regenerated .texinfo from .rst
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
I've pushed the patch to trunk for GCC 12 as r12-8118-g5780ff348ad443
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=5780ff348ad4430383fd67c6f0c572d8c3e721ad
Dave
>
> Le mardi 25 janvier 2022 à 12:13 -0500, Antoni Boucher via Jit a
> écrit :
> > See answers below.
> >
> > Le lundi 24 janvier 2022 à 18:20 -0500, David Malcolm a écrit :
> > > On Sat, 2022-01-22 at 19:29 -0500, Antoni Boucher wrote:
> > > > Hi.
> > > >
> > > > Le mardi 18 janvier 2022 à 18:49 -0500, David Malcolm a écrit :
> > > > > On Mon, 2022-01-17 at 19:46 -0500, Antoni Boucher via Gcc-
> > > > > patches
> > > > > wrote:
> > > > > > I missed the comment about the new define, so here's the
> > > > > > updated
> > > > > > patch.
> > > > >
> > > > > Thanks for the patch.
> > > > > >
> > > > > > Le lundi 17 janvier 2022 à 19:24 -0500, Antoni Boucher via
> > > > > > Jit
> > > > > > a
> > > > > > écrit :
> > > > > > > Hi.
> > > > > > > This patch add supports for register variables in
> > > > > > > libgccjit.
> > > > > > >
> > > > > > > It passes the JIT tests, but since I added a function in
> > > > > > > reginfo.c,
> > > > > > > I
> > > > > > > wonder if I should run the whole testsuite.
> > > > >
> > > > > We're in stage 4 for gcc 12, so we should be especially careful
> > > > > about
> > > > > changes right now, and we're not meant to be adding new GCC 12
> > > > > features.
> > > > >
> > > > > How close is gcc 12's libgccjit to being usable with your rustc
> > > > > backend? If we're almost there, I'm willing to make our case
> > > > > for
> > > > > late-
> > > > > breaking libgccjit changes to the release managers, but if you
> > > > > think
> > > > > rustc users are going to need to build a patched libgccjit,
> > > > > then
> > > > > let's
> > > > > queue this up for gcc 13.
> > > >
> > > > As I mentioned in my other email, if the 4 patches currently
> > > > being
> > > > reviewed (and listed here:
> > > > https://github.com/antoyo/libgccjit-patches) were included in gcc
> > > > 12,
> > > > I'd be able to build rustc_codegen_gcc with an unpatched gcc.
> > >
> > > Thanks. Once the relevant patches look good to me, I'll approach
> > > the
> > > release managers with the proposal.
> > >
> > > >
> > > > It is to be noted however, that I'll need more patches for future
> > > > work.
> > > > Off the top of my head, I'll at least need a patch for the inline
> > > > attribute, try/catch and target-specific builtins.
> > > > The last 2 features will probably take some time to implement, so
> > > > I'll
> > > > let you judge if you think it's worth merging the 4 patches
> > > > currently
> > > > being reviewed for gcc 12.
> > >
> > > Thanks, though I don't know enough about your project's features to
> > > make the judgement call. Does rustc_codegen_gcc have releases yet,
> > > or
> > > are you just pointing people at the trunk of your repo? I guess
> > > the
> > > question is - are you hoping to be able to point people at distro
> > > installs of gcc 12's libgccjit and have some version of
> > > rustc_codegen_gcc "just work" with that, or are they going to have
> > > to
> > > rebuild their own libgccjit to meaningfully use it?
> >
> > rustc_codegen_gcc does not have releases. It is merged from time to
> > time into rustc, so we can as well say that I point them to trunk.
> >
> > I can feature gate the future features/patches I will need so that
> > people can still use the project with an unpatched gcc.
> >
> > There's some interest in having it work with an unpatched gcc because
> > that would allow people to start working on the infra to get the
> > project distributed via rustup so that it could be distributed as a
> > preview component.
> >
> > >
> > > [...snip various corrections...]
> > >
> > > >
> > > > > > diff --git a/gcc/testsuite/jit.dg/test-register-variable.c
> > > > > > b/gcc/testsuite/jit.dg/test-register-variable.c
> > > > > > new file mode 100644
> > > > > > index 000..3cea3f1668f
> > > > > > --- /dev/null
> > > > > > +++ b/gcc/testsuite/jit.dg/test-register-variable.c
> > > > > > +
> > >
> > > [...snip...]
> > >
> > > > > > +/* { dg-final { jit-verify-output-file-was-created "" } } */
> > > > > > +/* { dg-final { jit-verify-assembler-output
> > > > > > "movl \\\$1,
> > > > > > %r12d" } } */
> > > > > > +/* { dg-final {
[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");
};
[committed 5/5] libstdc++: Prefer to use mmap instead of malloc in libbacktrace
Tested powerpc64-linux, pushed to trunk.
-- >8 --
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.
---
libstdc++-v3/acinclude.m4 | 35 +++
libstdc++-v3/config.h.in | 3 ++
libstdc++-v3/configure| 59 +--
3 files changed, 83 insertions(+), 14 deletions(-)
diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4
index f53461c85a5..eac8aeda48b 100644
--- a/libstdc++-v3/acinclude.m4
+++ b/libstdc++-v3/acinclude.m4
@@ -5003,18 +5003,41 @@ elf64) elfsize=64 ;;
esac
BACKTRACE_CPPFLAGS="$BACKTRACE_CPPFLAGS -DBACKTRACE_ELF_SIZE=$elfsize"
- ALLOC_FILE=alloc.lo
- AC_SUBST(ALLOC_FILE)
- VIEW_FILE=read.lo
- AC_SUBST(VIEW_FILE)
-
AC_MSG_CHECKING([whether to build libbacktrace support])
if test "$enable_libstdcxx_backtrace" == "auto"; then
enable_libstdcxx_backtrace=no
fi
if test "$enable_libstdcxx_backtrace" == "yes"; then
BACKTRACE_SUPPORTED=1
-BACKTRACE_USES_MALLOC=1
+
+AC_CHECK_HEADERS(sys/mman.h)
+case "${host}" in
+ *-*-msdosdjgpp) # DJGPP has sys/man.h, but no mmap
+ have_mmap=no ;;
+ *-*-*)
+ have_mmap="$ac_cv_header_sys_mman_h" ;;
+esac
+
+if test "$have_mmap" = "no"; then
+ VIEW_FILE=read.lo
+ ALLOC_FILE=alloc.lo
+else
+ VIEW_FILE=mmapio.lo
+ AC_PREPROC_IFELSE([AC_LANG_SOURCE([
+#include
+#if !defined(MAP_ANONYMOUS) && !defined(MAP_ANON)
+ #error no MAP_ANONYMOUS
+#endif
+])], [ALLOC_FILE=mmap.lo], [ALLOC_FILE=alloc.lo])
+fi
+AC_SUBST(VIEW_FILE)
+AC_SUBST(ALLOC_FILE)
+
+BACKTRACE_USES_MALLOC=0
+if test "$ALLOC_FILE" = "alloc.lo"; then
+ BACKTRACE_USES_MALLOC=1
+fi
+
if test "$ac_has_gthreads" = "yes"; then
BACKTRACE_SUPPORTS_THREADS=1
else
diff --git a/libstdc++-v3/config.h.in b/libstdc++-v3/config.h.in
index f6212de9268..f30a8c51c45 100644
--- a/libstdc++-v3/config.h.in
+++ b/libstdc++-v3/config.h.in
@@ -420,6 +420,9 @@
/* Define to 1 if you have the header file. */
#undef HAVE_SYS_MACHINE_H
+/* Define to 1 if you have the header file. */
+#undef HAVE_SYS_MMAN_H
+
/* Define to 1 if you have the header file. */
#undef HAVE_SYS_PARAM_H
diff --git a/libstdc++-v3/configure b/libstdc++-v3/configure
index ef80912d0b9..35dc3f49383 100755
--- a/libstdc++-v3/configure
+++ b/libstdc++-v3/configure
@@ -681,8 +681,8 @@ BACKTRACE_SUPPORTS_THREADS
BACKTRACE_USES_MALLOC
BACKTRACE_SUPPORTED
BACKTRACE_CPPFLAGS
-VIEW_FILE
ALLOC_FILE
+VIEW_FILE
FORMAT_FILE
ENABLE_FILESYSTEM_TS_FALSE
ENABLE_FILESYSTEM_TS_TRUE
@@ -16190,7 +16190,7 @@ ac_compiler_gnu=$ac_cv_cxx_compiler_gnu
ac_save_CXXFLAGS="$CXXFLAGS"
-cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+cat confdefs.h - <<_ACEOF >conftest.$ac_ext
/* end confdefs.h. */
#if ! defined __GCC_HAVE_SYNC_COMPARE_AND_SWAP_2
@@ -77463,11 +77463,6 @@ elf64) elfsize=64 ;;
esac
BACKTRACE_CPPFLAGS="$BACKTRACE_CPPFLAGS -DBACKTRACE_ELF_SIZE=$elfsize"
- ALLOC_FILE=alloc.lo
-
- VIEW_FILE=read.lo
-
-
{ $as_echo "$as_me:${as_lineno-$LINENO}: checking whether to build
libbacktrace support" >&5
$as_echo_n "checking whether to build libbacktrace support... " >&6; }
if test "$enable_libstdcxx_backtrace" == "auto"; then
@@ -77475,7 +77470,55 @@ $as_echo_n "checking whether to build libbacktrace
support... " >&6; }
fi
if test "$enable_libstdcxx_backtrace" == "yes"; then
BACKTRACE_SUPPORTED=1
-BACKTRACE_USES_MALLOC=1
+
+for ac_header in sys/mman.h
+do :
+ ac_fn_c_check_header_mongrel "$LINENO" "sys/mman.h"
"ac_cv_header_sys_mman_h" "$ac_includes_default"
+if test "x$ac_cv_header_sys_mman_h" = xyes; then :
+ cat >>confdefs.h <<_ACEOF
+#define HAVE_SYS_MMAN_H 1
+_ACEOF
+
+fi
+
+done
+
+case "${host}" in
+ *-*-msdosdjgpp) # DJGPP has sys/man.h, but no mmap
+ have_mmap=no ;;
+ *-*-*)
+ have_mmap="$ac_cv_header_sys_mman_h" ;;
+esac
+
+if test "$have_mmap" = "no"; then
+ VIEW_FILE=read.lo
+ ALLOC_FILE=alloc.lo
+else
+ VIEW_FILE=mmapio.lo
+ cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h. */
+
+#include
+#if !defined(MAP_ANONYMOUS) && !defined(MAP_ANON)
+ #error no MAP_ANONYMOUS
+#endif
+
+_ACEOF
+if ac_fn_c_try_cpp "$LINENO"; then :
+ ALLOC_FILE=mmap.lo
+else
+ ALLOC_FILE=alloc.lo
+fi
+rm -f conftest.err conftest.i conftest.$ac_ext
+fi
+
+
+
+
[committed 4/5] libstdc++: shrink-to-fit in std::basic_stacktrace::current(skip, max)
Tested powerpc64-linux, pushed to trunk.
-- >8 --
If a large stacktrace is reduced to a max depth that is less than half
the capacity it will now be reallocated to remove the unused capacity.
libstdc++-v3/ChangeLog:
* include/std/stacktrace (basic_stacktrace::current): Reallocate
a smaller container if the unused capacity is larger than the
used size.
---
libstdc++-v3/include/std/stacktrace | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/libstdc++-v3/include/std/stacktrace
b/libstdc++-v3/include/std/stacktrace
index 382d900a822..98ce9231150 100644
--- a/libstdc++-v3/include/std/stacktrace
+++ b/libstdc++-v3/include/std/stacktrace
@@ -289,7 +289,20 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
if (__err < 0)
__ret._M_clear();
else if (__ret.size() > __max_depth)
- __ret._M_impl._M_resize(__max_depth, __ret._M_alloc);
+ {
+ __ret._M_impl._M_resize(__max_depth, __ret._M_alloc);
+
+ if (__ret._M_impl._M_capacity / 2 >= __max_depth)
+ {
+ // shrink to fit
+ _Impl __tmp = __ret._M_impl._M_clone(__ret._M_alloc);
+ if (__tmp._M_capacity)
+ {
+ __ret._M_clear();
+ __ret._M_impl = __tmp;
+ }
+ }
+ }
}
return __ret;
}
--
2.34.1
[committed 3/5] libstdc++: Use allocator to construct std::stacktrace_entry objects
Tested powerpc64-linux, pushed to trunk.
-- >8 --
Because std::basic_stacktrace is an allocator-aware container its
elements should be initialized using allocator_traits::construct and
destroyed using allocator_traits::destroy.
This adds new _M_clone and _M_assign helper functions to construct
elements correctly and uses those functions instead of calling
std::uninitialized_copy_n.
The _Impl::_M_destroy function needs to be passed an allocator to
destroy the elements correctly, so is replaced by _M_resize which can
also be used to trim the container to a smaller size.
Because destroying and creating std::stacktrace_entry objects is cheap,
the copy/move assignment operators can just destroy all existing
elements and use _Impl._M_clone or _Impl._M_assign to create new ones.
libstdc++-v3/ChangeLog:
* include/std/stacktrace (basic_stacktrace): Use _Impl::_M_clone
or _Impl::_M_assign to initialize elements in allocated storage.
(basic_stacktrace::_M_clear()): Use _Impl::_M_resize instead of
_Impl::_M_destroy.
(basic_stacktrace::_Impl::_M_destroy()): Replace with ...
(basic_stacktrace::_Impl::_M_resize(size_type, allocator&)): New
function.
(basic_stacktrace::_Impl::_M_push_back): Use _M_xclone. Construct
new element using allocator.
(basic_stacktrace::_Impl::_M_clone): New function.
(basic_stacktrace::_Impl::_M_xclone): New function.
(basic_stacktrace::_Impl::_M_assign): New function.
---
libstdc++-v3/include/std/stacktrace | 92 +++--
1 file changed, 47 insertions(+), 45 deletions(-)
diff --git a/libstdc++-v3/include/std/stacktrace
b/libstdc++-v3/include/std/stacktrace
index f36c5a9abef..382d900a822 100644
--- a/libstdc++-v3/include/std/stacktrace
+++ b/libstdc++-v3/include/std/stacktrace
@@ -289,7 +289,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
if (__err < 0)
__ret._M_clear();
else if (__ret.size() > __max_depth)
- __ret._M_impl._M_size = __max_depth;
+ __ret._M_impl._M_resize(__max_depth, __ret._M_alloc);
}
return __ret;
}
@@ -318,11 +318,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
: _M_alloc(__alloc)
{
if (const auto __s = __other._M_impl._M_size)
- if (auto __f = _M_impl._M_allocate(_M_alloc, __s))
- {
- std::uninitialized_copy_n(__other.begin(), __s, __f);
- _M_impl._M_size = __s;
- }
+ _M_impl = __other._M_impl._M_clone(_M_alloc);
}
basic_stacktrace(basic_stacktrace&& __other,
@@ -334,11 +330,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
else if (_M_alloc == __other._M_alloc)
_M_impl = std::__exchange(__other._M_impl, {});
else if (const auto __s = __other._M_impl._M_size)
- if (auto __f = _M_impl._M_allocate(_M_alloc, __s))
- {
- std::uninitialized_copy_n(__other.begin(), __s, __f);
- _M_impl._M_size = __s;
- }
+ _M_impl = __other._M_impl._M_clone(_M_alloc);
}
basic_stacktrace&
@@ -370,19 +362,13 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
if constexpr (__pocca)
_M_alloc = __other._M_alloc;
- if (auto __f = _M_impl._M_allocate(_M_alloc, __s))
- {
- std::uninitialized_copy_n(__other.begin(), __s, __f);
- _M_impl._M_size = __s;
- }
+ _M_impl = __other._M_impl._M_clone(_M_alloc);
}
else
{
- // Current storage is large enough and can be freed by whichever
- // allocator we will have after this function returns.
- auto __to = std::copy_n(__other.begin(), __s, begin());
- std::destroy(__to, end());
- _M_impl._M_size = __s;
+ // Current storage is large enough.
+ _M_impl._M_resize(0, _M_alloc);
+ _M_impl._M_assign(__other._M_impl, _M_alloc);
if constexpr (__pocca)
_M_alloc = __other._M_alloc;
@@ -418,23 +404,13 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
{
// Need to allocate new storage.
_M_clear();
-
- if (auto __f = _M_impl._M_allocate(_M_alloc, __s))
- {
- std::uninitialized_copy_n(__other.begin(), __s, __f);
- _M_impl._M_size = __s;
- }
+ _M_impl = __other._M_impl._M_clone(_M_alloc);
}
else
{
// Current storage is large enough.
- auto __first = __other.begin();
- auto __mid = __first + std::min(__s, _M_impl._M_size);
- auto __last = __other.end();
- auto __to = std::copy(__first, __mid, begin());
- __to = std::uninitialized_copy(__mid, __last, __to);
- std::destroy(__to, end());
- _M_impl._M_size = __s;
+
[committed 2/5] libstdc++: Use nothrow new in std::stacktrace
Tested powerpc64-linux, pushed to trunk.
-- >8 --
We can avoid the overhead of handling a bad_alloc exception from
std::allocator::allocate by just calling the
nothrow operator new instead.
libstdc++-v3/ChangeLog:
* include/std/stacktrace (basic_stacktrace::_Impl::_M_allocate):
Use nothrow new instead of try block for std::allocator.
(basic_stacktrace::_Impl::_M_deallocate): Use delete for
std::allocator.
---
libstdc++-v3/include/std/stacktrace | 42 -
1 file changed, 35 insertions(+), 7 deletions(-)
diff --git a/libstdc++-v3/include/std/stacktrace
b/libstdc++-v3/include/std/stacktrace
index 5f928f10dee..f36c5a9abef 100644
--- a/libstdc++-v3/include/std/stacktrace
+++ b/libstdc++-v3/include/std/stacktrace
@@ -30,6 +30,7 @@
#if __cplusplus > 202002L && _GLIBCXX_HAVE_STACKTRACE
#include
+#include
#include
#include
#include
@@ -589,23 +590,43 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
return std::min(__size_max, __alloc_max);
}
+#if __has_builtin(__builtin_operator_new) >= 201802L
+# define _GLIBCXX_OPERATOR_NEW __builtin_operator_new
+# define _GLIBCXX_OPERATOR_DELETE __builtin_operator_delete
+#else
+# define _GLIBCXX_OPERATOR_NEW ::operator new
+# define _GLIBCXX_OPERATOR_DELETE ::operator delete
+#endif
+
// Precondition: _M_frames == nullptr && __n != 0
pointer
_M_allocate(allocator_type& __alloc, size_type __n) noexcept
{
if (__n <= _S_max_size(__alloc)) [[likely]]
{
- __try
+ if constexpr (is_same_v>)
{
- _M_frames = __alloc.allocate(__n);
- _M_capacity = __n;
- return _M_frames;
+ __n *= sizeof(value_type);
+ void* const __p = _GLIBCXX_OPERATOR_NEW (__n, nothrow_t{});
+ if (__p == nullptr) [[unlikely]]
+ return nullptr;
+ _M_frames = static_cast(__p);
}
- __catch (...)
+ else
{
+ __try
+ {
+ _M_frames = __alloc.allocate(__n);
+ }
+ __catch (const std::bad_alloc&)
+ {
+ return nullptr;
+ }
}
+ _M_capacity = __n;
+ return _M_frames;
}
- return nullptr;;
+ return nullptr;
}
void
@@ -613,12 +634,19 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
{
if (_M_capacity)
{
- __alloc.deallocate(_M_frames, _M_capacity);
+ if constexpr (is_same_v>)
+ _GLIBCXX_OPERATOR_DELETE (static_cast(_M_frames),
+ _M_capacity * sizeof(value_type));
+ else
+ __alloc.deallocate(_M_frames, _M_capacity);
_M_frames = nullptr;
_M_capacity = 0;
}
}
+#undef _GLIBCXX_OPERATOR_DELETE
+#undef _GLIBCXX_OPERATOR_NEW
+
void
_M_destroy() noexcept
{
--
2.34.1
[committed 1/5] libstdc++: Reduce memory usage in std::stacktrace::current
Tested powerpc64-linux, pushed to trunk.
-- >8 --
This adds an alternative callback for use in the overload of
basic_stacktrace::current that takes a max_depth parameter. The new
callback will not allow the container to grow past the initial capacity,
which is set to the specified maximum depth. This avoids allocating
memory for hundreds of frames only to discard them again because of a
small maximum depth limit.
For larger maximum depths the normal callback is used, with a smaller
initial capacity that can grow as needed. The container will be resized
to the given max depth after the entire backtrace has been produced
(relying on the fact that std::stacktrace_entry objects are trivially
destructible to elide their destruction).
Currently the value for "larger" limits is 128, so a max depth <= 128
will allocate capacity for exactly that many frames. A larger max depth
(or an unspecified max depth) will use an initial capacity of 64 frames
and grow as needed. Since each frame is only a uintptr_t value it might
be reasonable to increase the first value so that memory usage can be
capped for larger maximum depths.
This change also delays the creation of the libbacktrace state until we
actually need it, so that the state is not created if allocation fails.
libstdc++-v3/ChangeLog:
* include/std/stacktrace (basic_stacktrace::current): Replace
calls to _M_reserve and _S_curr_cb with call to _M_prepare.
Check return value of backtrace_simple when max depth given.
(basic_stacktrace::_M_reserve): Remove.
(basic_stacktrace::_S_curr_cb): Remove.
(basic_stacktrace::_M_prepare(size_type)): New function to
reserve initial capacity and return callback.
(basic_stacktrace::_Impl::_M_allocate): Remove check for 0 < n
and remove redundant zeroing of _M_frames and _M_capacity.
(basic_stacktrace::_Impl::_M_push_back): Add [[unlikely]]
attribute. Assign _Impl instead of swapping.
* testsuite/19_diagnostics/stacktrace/current.cc: New test.
---
libstdc++-v3/include/std/stacktrace | 110 ++
.../19_diagnostics/stacktrace/current.cc | 86 ++
2 files changed, 148 insertions(+), 48 deletions(-)
create mode 100644 libstdc++-v3/testsuite/19_diagnostics/stacktrace/current.cc
diff --git a/libstdc++-v3/include/std/stacktrace
b/libstdc++-v3/include/std/stacktrace
index 79038e803f2..5f928f10dee 100644
--- a/libstdc++-v3/include/std/stacktrace
+++ b/libstdc++-v3/include/std/stacktrace
@@ -237,15 +237,14 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
static basic_stacktrace
current(const allocator_type& __alloc = allocator_type()) noexcept
{
- auto __state = stacktrace_entry::_S_init();
basic_stacktrace __ret(__alloc);
- if (!__ret._M_reserve(64)) [[unlikely]]
- return __ret;
-
- if (__glibcxx_backtrace_simple(__state, 1, _S_curr_cb(),
- nullptr, std::__addressof(__ret)))
- __ret._M_clear();
-
+ if (auto __cb = __ret._M_prepare()) [[likely]]
+ {
+ auto __state = stacktrace_entry::_S_init();
+ if (__glibcxx_backtrace_simple(__state, 1, __cb, nullptr,
+ std::__addressof(__ret)))
+ __ret._M_clear();
+ }
return __ret;
}
@@ -254,16 +253,16 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
current(size_type __skip,
const allocator_type& __alloc = allocator_type()) noexcept
{
- auto __state = stacktrace_entry::_S_init();
basic_stacktrace __ret(__alloc);
if (__skip >= __INT_MAX__) [[unlikely]]
return __ret;
- if (!__ret._M_reserve(64)) [[unlikely]]
- return __ret;
-
- if (__glibcxx_backtrace_simple(__state, __skip + 1, _S_curr_cb(),
- nullptr, std::__addressof(__ret)))
- __ret._M_clear();
+ if (auto __cb = __ret._M_prepare()) [[likely]]
+ {
+ auto __state = stacktrace_entry::_S_init();
+ if (__glibcxx_backtrace_simple(__state, __skip + 1, __cb, nullptr,
+ std::__addressof(__ret)))
+ __ret._M_clear();
+ }
return __ret;
}
@@ -275,19 +274,22 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
{
__glibcxx_assert(__skip <= (size_type(-1) - __max_depth));
- auto __state = stacktrace_entry::_S_init();
basic_stacktrace __ret(__alloc);
- if (__max_depth == 0 || __skip >= __INT_MAX__) [[unlikely]]
+ if (__max_depth == 0) [[unlikely]]
return __ret;
- if (!__ret._M_reserve(std::min(__max_depth, 64))) [[unlikely]]
+ if (__skip >= __INT_MAX__) [[unlikely]]
return __ret;
-
- if (__glibcxx_backtrace_simple(__state, __skip + 1, _S_curr_cb(),
- nullptr, std::__addressof(__ret)))
-
[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.
Re: [PATCH] libgccjit: Add support for bitcasts [PR104071]
On Sat, 2022-04-09 at 14:05 -0400, Antoni Boucher wrote:
> Here's the updated patch.
Thanks.
I updated the patch somewhat:
* fixed up some hunks that didn't quite apply
* whitespace fixes
* added a missing comment
* regenerated .texinfo from .rst
* test-bitcast.c failed for me; the bitcast of -5.1298714 float to int
didn't give me the expected 35569201; I got this value:
(gdb) p val
$1 = -1062983704
(gdb) p /x val
$2 = 0xc0a427e8
(gdb) p /x 35569201
$3 = 0x21ebe31
and I couldn't figure out what the relationship between these two
values could be.
The expected: 35569201 == 0x21ebe31
0x021ebe31 as float is 1 × 2^-123 × 1.2401792 = 1.1662589e-37
I rewrote the test to explicitly use int32_t rather than int, but this
didn't help.
I wondered if this was an endianness issue, but:
-5.1298713 is -1 × 2^2 × 1.2824678, which is 0xc0a427e8
In the end, I changed the constants in the test to these:
(gdb) p *(float *)
$25 = 3.14159274
(gdb) p *(int32_t *)
$26 = 1078530011
(gdb) p /x *(int32_t *)
$27 = 0x40490fdb
which passes for me.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
I've pushed the patch to trunk for GCC 12 as r12-8117-g30f7c83e9cfe7c
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=30f7c83e9cfe7c015448d72f63c4c39d14bc6de6
Dave
>
> On Fri, 2022-04-08 at 15:22 -0400, David Malcolm wrote:
> > On Fri, 2022-01-21 at 18:41 -0500, Antoni Boucher wrote:
> > > Hi.
> > > Here's the updated patch.
> > >
> >
> > Thanks. Review below:
> >
> > [...snip...]
> >
> > > diff --git a/gcc/jit/libgccjit.cc b/gcc/jit/libgccjit.cc
> > > index 4c352e8c93d..6bf1e1ceee0 100644
> > > --- a/gcc/jit/libgccjit.cc
> > > +++ b/gcc/jit/libgccjit.cc
> > > @@ -2405,6 +2405,34 @@ gcc_jit_context_new_cast (gcc_jit_context
> > > *ctxt,
> > > return static_cast (ctxt->new_cast (loc,
> > > rvalue, type));
> > > }
> > >
> > > +/* Public entrypoint. See description in libgccjit.h.
> > > +
> > > + After error-checking, the real work is done by the
> > > + gcc::jit::recording::context::new_bitcast method in jit-
> > > recording.c. */
> > > +
> > > +gcc_jit_rvalue *
> > > +gcc_jit_context_new_bitcast (gcc_jit_context *ctxt,
> > > + gcc_jit_location *loc,
> > > + gcc_jit_rvalue *rvalue,
> > > + gcc_jit_type *type)
> > > +{
> > > + RETURN_NULL_IF_FAIL (ctxt, NULL, loc, "NULL context");
> > > + JIT_LOG_FUNC (ctxt->get_logger ());
> > > + /* LOC can be NULL. */
> > > + RETURN_NULL_IF_FAIL (rvalue, ctxt, loc, "NULL rvalue");
> > > + RETURN_NULL_IF_FAIL (type, ctxt, loc, "NULL type");
> > > + // TODO: check the sizes.
> > > + /*RETURN_NULL_IF_FAIL_PRINTF3 (
> > > + is_valid_cast (rvalue->get_type (), type),
> > > + ctxt, loc,
> > > + "cannot cast %s from type: %s to type: %s",
> > > + rvalue->get_debug_string (),
> > > + rvalue->get_type ()->get_debug_string (),
> > > + type->get_debug_string ());*/
> >
> > I think we agreed that we can't check the sizes at this point, so
> > this
> > commented-out check would be better replaced with a comment
> > explaining
> > that we have to defer the check to playback time, when we have the
> > trees.
> >
> > > +
> > > + return static_cast (ctxt->new_bitcast (loc,
> > > rvalue, type));
> > > +}
> > > +
> > > /* Public entrypoint. See description in libgccjit.h.
> > >
> > > After error-checking, the real work is done by the
> >
> > [...snip...]
> >
> > > diff --git a/gcc/testsuite/jit.dg/test-bitcast.c
> > > b/gcc/testsuite/jit.dg/test-bitcast.c
> > > new file mode 100644
> > > index 000..a092fa117e6
> > > --- /dev/null
> > > +++ b/gcc/testsuite/jit.dg/test-bitcast.c
> > > @@ -0,0 +1,60 @@
> > > +#include
> > > +#include
> > > +#include
> > > +
> > > +#include "libgccjit.h"
> > > +
> > > +#include "harness.h"
> > > +
> > > +void
> > > +create_code (gcc_jit_context *ctxt, void *user_data)
> > > +{
> > > + /* Let's try to inject the equivalent of:
> > > +int
> > > +my_bitcast (double x)
> > > +{
> > > + return bitcast(x, int);
> > > +}
> > > + */
> > > + gcc_jit_type *int_type =
> > > + gcc_jit_context_get_int_type (ctxt, 4, 1);
> > > + gcc_jit_type *float_type =
> > > + gcc_jit_context_get_type (ctxt, GCC_JIT_TYPE_FLOAT);
> >
> > This uses GCC_JIT_TYPE_FLOAT for the param...
> >
> > > +
> > > + gcc_jit_param *x =
> > > + gcc_jit_context_new_param (
> > > + ctxt,
> > > + NULL,
> > > + float_type, "x");
> > > + gcc_jit_param *params[1] = {x};
> > > + gcc_jit_function *func =
> > > + gcc_jit_context_new_function (ctxt,
> > > + NULL,
> > > + GCC_JIT_FUNCTION_EXPORTED,
> > > + int_type,
> > > + "my_bitcast",
> > > + 1, params, 0);
> >
> > [..snip...]
> >
> > > +
> > > +void
> > > +verify_code (gcc_jit_context *ctxt, gcc_jit_result *result)
Re: [PATCH] libgccjit: Add support for sized integer types, including 128-bit integers [PR95325]
On Fri, 2022-04-08 at 16:29 -0400, Antoni Boucher wrote: > David, it seems you missed this email that contains the updated patch > and a few questions. > > Attaching the patch again. > > Thanks for the reviews! Thanks for the patch. I updated the patch to fix some minor nits: - Some whitespace fixes (tab vs spaces, overlong lines, continuation lines in .rst ". function::" clause) - I kept compatible_types, with gcc_jit_compatible_types becoming a thin wrapper around it. This avoids a bunch of casts in libgccjit.cc - Regenerated docs/_build/texinfo/libgccjit.texi Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu. I've pushed the patch to trunk for GCC 12 as r12-8116-gaf80ea97b61847: https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=af80ea97b61847d91da0d303e85faed437059092 Dave > > On Fri, 2022-01-21 at 11:22 -0500, Antoni Boucher via Jit wrote: > > David: this is the email I was talking about in my other email. > > Here's the updated patch. > > > > By the way, I find the usage of NUM_GCC_JIT_TYPES brittle. Would it > > be > > better to switch to a new enum value for that instead? > > > > See comments below. > > > > Le jeudi 20 mai 2021 à 15:25 -0400, David Malcolm a écrit : > > > On Tue, 2021-05-18 at 14:53 +0200, Jakub Jelinek via Jit wrote: > > > > On Tue, May 18, 2021 at 08:23:56AM -0400, Antoni Boucher via Gcc- > > > > patches wrote: > > > > > Hello. > > > > > This patch add support for sized integer types. > > > > > Maybe it should check whether the size of a byte for the > > > > > current > > > > > platform is 8 bits and do other checks so that they're only > > > > > available > > > > > when it makes sense. > > > > > What do you think? > > > > > > > > Not a review, just a comment. The 128-bit integral types are > > > > available > > > > only on some targets, the test e.g. the C/C++ FE do for those is > > > > targetm.scalar_mode_supported_p (TImode) > > > > and so even libgccjit shouldn't provide those types > > > > unconditionally. > > > > Similarly for the tests (though it could be guarded with e.g > > > > #ifdef __SIZEOF_INT128__ > > > > in that case). > > > > Also, while currently all in tree targets have BITS_PER_UNIT 8 > > > > and > > > > therefore QImode is 8-bit, HImode 16-bit, SImode 32-bit and > > > > DImode > > > > 64- > > > > bit, > > > > in the past and maybe in he future there can be targets that > > > > could > > > > have > > > > e.g. 16-bit or 32-bit QImode and then there wouldn't be any > > > > uint8_t/int8_t > > > > and int16_t would be intQImode_type_node etc. > > > > uint16_type_node = make_or_reuse_type (16, 1); > > > > uint32_type_node = make_or_reuse_type (32, 1); > > > > uint64_type_node = make_or_reuse_type (64, 1); > > > > if (targetm.scalar_mode_supported_p (TImode)) > > > > uint128_type_node = make_or_reuse_type (128, 1); > > > > are always with the given precisions, perhaps jit should use > > > > signed_type_for (uint16_type_node) etc.? > > > > > > I seem to have mislaid Antoni's original email (sorry), so I'll > > > reply > > > to Jakub's. > > > > > > > 2021-05-18 Antoni Boucher > > > > > > > > gcc/jit/ > > > > PR target/95325 > > > > * jit-playback.c: Add support for the sized integer > > > > types. > > > > * jit-recording.c: Add support for the sized integer > > > > types. > > > > * libgccjit.h (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): > > > > New enum variants for gcc_jit_types. > > > > gcc/testsuite/ > > > > PR target/95325 > > > > * jit.dg/test-types.c: Add tests for sized integer > > > > types. > > > > > > First a high-level question, why not use (or extend) > > > gcc_jit_context_get_int_type instead? > > > > If I remember correctly, I believe I had some issues with this > > function, like having it return sometimes long long, and other times > > long for the same size. Maybe that was an issue with a global > > variable > > not cleaned up. > > > > > > > > Do we really need to extend enum gcc_jit_types? Is this a quality- > > > of- > > > life thing for users of the library? > > > > > > That said, recording::context::get_int_type is currently a bit of a > > > hack, and maybe could probably be improved by using the new enum > > > values > > > the patch adds. > > > > > > IIRC, libgccjit.c does type-checking by comparing recording::type > > > pointer values; does this patch gives us multiple equivalent types > > > that > > > ought to compare as equal? > > > > > > If a user gets a type via GCC_JIT_TYPE_INT and gets "another" type > > > via > > > GCC_JIT_TYPE_INT32_T and they happen to be the same on the current > > > target, should libgccjit complain if you use
[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.
[pushed] 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.
Tested x86_64-pc-linux-gnu, applying to trunk.
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.
---
gcc/cp/decl.cc | 20 ++--
gcc/cp/decl2.cc | 12 ++--
gcc/testsuite/g++.target/i386/mv31.C | 10 ++
3 files changed, 34 insertions(+), 8 deletions(-)
create mode 100644 gcc/testsuite/g++.target/i386/mv31.C
diff --git a/gcc/cp/decl.cc b/gcc/cp/decl.cc
index 31cae4d1d36..5f59612fb00 100644
--- a/gcc/cp/decl.cc
+++ b/gcc/cp/decl.cc
@@ -1069,11 +1069,14 @@ decls_match (tree newdecl, tree olddecl, bool
record_versions /* = true */)
if (types_match
&& !DECL_EXTERN_C_P (newdecl)
&& !DECL_EXTERN_C_P (olddecl)
- && record_versions
- && maybe_version_functions (newdecl, olddecl,
- (!DECL_FUNCTION_VERSIONED (newdecl)
- || !DECL_FUNCTION_VERSIONED (olddecl
- return 0;
+ && targetm.target_option.function_versions (newdecl, olddecl))
+ {
+ if (record_versions)
+ maybe_version_functions (newdecl, olddecl,
+(!DECL_FUNCTION_VERSIONED (newdecl)
+ || !DECL_FUNCTION_VERSIONED (olddecl)));
+ return 0;
+ }
}
else if (TREE_CODE (newdecl) == TEMPLATE_DECL)
{
@@ -2598,7 +2601,12 @@ duplicate_decls (tree newdecl, tree olddecl, bool
hiding, bool was_hidden)
else
{
retrofit_lang_decl (newdecl);
- DECL_LOCAL_DECL_ALIAS (newdecl) = DECL_LOCAL_DECL_ALIAS (olddecl);
+ tree alias = DECL_LOCAL_DECL_ALIAS (newdecl)
+ = DECL_LOCAL_DECL_ALIAS (olddecl);
+ DECL_ATTRIBUTES (alias)
+ = (*targetm.merge_decl_attributes) (alias, newdecl);
+ if (TREE_CODE (newdecl) == FUNCTION_DECL)
+ merge_attribute_bits (newdecl, alias);
}
}
diff --git a/gcc/cp/decl2.cc b/gcc/cp/decl2.cc
index c780702572d..e10331f8568 100644
--- a/gcc/cp/decl2.cc
+++ b/gcc/cp/decl2.cc
@@ -1637,8 +1637,16 @@ find_last_decl (tree decl)
if (TREE_CODE (*iter) == OVERLOAD)
continue;
- if (decls_match (decl, *iter, /*record_decls=*/false))
- return *iter;
+ tree d = *iter;
+
+ /* We can't compare versions in the middle of processing the
+attribute that has the version. */
+ if (TREE_CODE (d) == FUNCTION_DECL
+ && DECL_FUNCTION_VERSIONED (d))
+ return NULL_TREE;
+
+ if (decls_match (decl, d, /*record_decls=*/false))
+ return d;
}
return NULL_TREE;
}
diff --git a/gcc/testsuite/g++.target/i386/mv31.C
b/gcc/testsuite/g++.target/i386/mv31.C
new file mode 100644
index 000..5d8fd1ddf75
--- /dev/null
+++ b/gcc/testsuite/g++.target/i386/mv31.C
@@ -0,0 +1,10 @@
+// PR c++/104669
+
+void bar()
+{
+ int foo(void);
+ int foo(void) __attribute__((target("sse")));
+ int foo(void) __attribute__((target("default")));
+ int (*p)(void) =
+ return;
+}
base-commit: 164c6a1c5d7f99235f1a41440eacac7a977e8fbd
--
2.27.0
[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.
[pushed] 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.
Tested x86_64-pc-linux-gnu, applying to trunk.
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.
---
gcc/cp/init.cc| 2 +-
gcc/testsuite/g++.dg/cpp1z/aligned-new9.C | 4
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/gcc/cp/init.cc b/gcc/cp/init.cc
index ce332c7e329..7ce8d3a46e5 100644
--- a/gcc/cp/init.cc
+++ b/gcc/cp/init.cc
@@ -3292,7 +3292,7 @@ build_new_1 (vec **placement, tree type,
tree nelts,
{
unsigned align = TYPE_ALIGN_UNIT (elt_type);
/* Also consider the alignment of the cookie, if any. */
- if (TYPE_VEC_NEW_USES_COOKIE (elt_type))
+ if (array_p && TYPE_VEC_NEW_USES_COOKIE (elt_type))
align = MAX (align, TYPE_ALIGN_UNIT (size_type_node));
align_arg = build_int_cst (align_type_node, align);
}
diff --git a/gcc/testsuite/g++.dg/cpp1z/aligned-new9.C
b/gcc/testsuite/g++.dg/cpp1z/aligned-new9.C
index 7854299419a..3fa0ed996bd 100644
--- a/gcc/testsuite/g++.dg/cpp1z/aligned-new9.C
+++ b/gcc/testsuite/g++.dg/cpp1z/aligned-new9.C
@@ -23,4 +23,8 @@ int main()
X *p = new X[n];
if (nalign != align)
__builtin_abort ();
+
+ X *p2 = new X;
+ if (nalign != alignof (X))
+__builtin_abort ();
}
base-commit: aa7874596b9f12b25a3214b0a143b040fafa1f10
--
2.27.0
[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)
Re: [PATCH] c++: NON_DEPENDENT_EXPR is not potentially constant [PR104507]
On 4/12/22 15:48, Patrick Palka wrote: On Wed, Feb 16, 2022 at 2:47 PM Patrick Palka wrote: On Tue, 15 Feb 2022, Jason Merrill wrote: On 2/15/22 17:00, Patrick Palka wrote: On Tue, 15 Feb 2022, Jason Merrill wrote: On 2/15/22 15:13, Patrick Palka wrote: On Tue, 15 Feb 2022, Patrick Palka wrote: 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 unhandled trees (of which CAST_EXPR is one). Since cxx_eval_constant_expression always treats NON_DEPENDENT_EXPR as non-constant, and since NON_DEPENDENT_EXPR is also opaque to instantiate_non_dependent_expr, it seems futile to have p_c_e_1 ever return true for NON_DEPENDENT_EXPR, so let's just instead return false and avoid recursing. Well, in a template we use pce1 to decide whether to complain about something that needs to be constant but can't be. We aren't trying to get a value yet. Makes sense.. though for NON_DEPENDENT_EXPR in particular, ISTM this tree is always used in a context where a constant expression isn't required, e.g. in the build_x_* functions. Fair enough. The patch is OK with a comment to that effect. Thanks, I committed the following as r12-7264: Would it be OK to backport this now for 11.3, or shall we wait until after 11.3 is released? It's been two months, and the only reported fallout from this patch was PR104620, where we began to fail to diagnose an invalid consteval call within a template ahead of time (and it turned out we previously were diagnosing it only by accident). The patch also fixed PR103443 (non-dependent consteval call incorrectly rejected). OK. -- >8 -- Subject: [PATCH] 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.cc (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. --- gcc/cp/constexpr.cc | 9 - gcc/testsuite/g++.dg/template/non-dependent21.C | 9 + 2 files changed, 17 insertions(+), 1 deletion(-) create mode 100644 gcc/testsuite/g++.dg/template/non-dependent21.C diff --git a/gcc/cp/constexpr.cc b/gcc/cp/constexpr.cc index 7274c3b760e..4716694cb71 100644 --- a/gcc/cp/constexpr.cc +++ b/gcc/cp/constexpr.cc @@ -9065,6 +9065,14 @@ potential_constant_expression_1 (tree t, bool want_rval, bool strict, bool now, case BIND_EXPR: return RECUR (BIND_EXPR_BODY (t), want_rval); +case NON_DEPENDENT_EXPR: + /* Treat NON_DEPENDENT_EXPR as non-constant: it's not handled by +constexpr evaluation or tsubst, so fold_non_dependent_expr can't +do anything useful with it. And we shouldn't see it in a context +where a constant expression is strictly required, hence the assert. */ + gcc_checking_assert (!(flags & tf_error)); + return false; + case CLEANUP_POINT_EXPR: case MUST_NOT_THROW_EXPR: case TRY_CATCH_EXPR: @@ -9072,7 +9080,6 @@ potential_constant_expression_1 (tree t, bool want_rval, bool strict, bool now, case EH_SPEC_BLOCK: case EXPR_STMT: case PAREN_EXPR: -case NON_DEPENDENT_EXPR: /* For convenience. */ case LOOP_EXPR: case EXIT_EXPR: diff --git
[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.
Re: [PATCH] c++: requires-expr in pack expansion using pack [PR103105]
On 4/12/22 14:44, Patrick Palka wrote:
On Tue, Apr 12, 2022 at 12:33 PM Jason Merrill wrote:
On 4/12/22 12:17, Patrick Palka wrote:
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 looking up the resulting dependent specialization of A, we
crash from iterative_hash_template_arg since it deliberately doesn't
handle ARGUMENT_PACK_SELECT.
Like with 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).
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk/11? For 11, we'd need to backport r12-7102 as a prereq.
OK, that additional backport seems reasonable.
Thanks a lot, committed to trunk so far. I attempted backporting this
(along with the mentioned prereq r12-7102) but it seems we also need
to backport your r12-7857-gfc50d9a252c89c (from PR104008) before we
begin to accept the second testcase. (Now I remember why I sat on
this PR for so long :))
It's in now.
PR c++/103105
PR c++/103706
gcc/cp/ChangeLog:
* pt.cc (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.
---
gcc/cp/pt.cc | 2 +-
.../g++.dg/cpp2a/concepts-requires29.C| 18 +++
.../g++.dg/cpp2a/concepts-requires29a.C | 23 +++
3 files changed, 42 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-requires29.C
create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-requires29a.C
diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
index 78519562953..84712e6fc2f 100644
--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -13048,7 +13048,7 @@ build_extra_args (tree pattern, tree args,
tsubst_flags_t complain)
{
/* Make a copy of the extra arguments so that they won't get changed
out from under us. */
- tree extra = copy_template_args (args);
+ tree extra = preserve_args (copy_template_args (args), /*cow_p=*/false);
if (local_specializations)
if (tree locals = extract_local_specs (pattern, complain))
extra = tree_cons (NULL_TREE, extra, locals);
diff --git a/gcc/testsuite/g++.dg/cpp2a/concepts-requires29.C
b/gcc/testsuite/g++.dg/cpp2a/concepts-requires29.C
new file mode 100644
index 000..5118df978c9
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/concepts-requires29.C
@@ -0,0 +1,18 @@
+// PR c++/103105
+// { dg-do compile { target c++20 } }
+
+template class A;
+
+template
+using wrap = A<1 != (0 + ... + requires { Ts(); })>;
+
+template using type = wrap;
+
+using ty0 = type<>;
+using ty0 = A;
+
+using ty1 = type;
+using ty1 = A;
+
+using ty2 = type;
+using ty2 = A;
diff --git a/gcc/testsuite/g++.dg/cpp2a/concepts-requires29a.C
b/gcc/testsuite/g++.dg/cpp2a/concepts-requires29a.C
new file mode 100644
index 000..c41c1e6d039
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/concepts-requires29a.C
@@ -0,0 +1,23 @@
+// PR c++/103105
+// { dg-do compile { target c++20 } }
+
+template struct list;
+template struct A;
+
+template
+using wrap = A<1 != (0 + ... + requires { T() = Ts(); })>;
+
+template
+using type = list...>;
+
+using ty0 = type<>;
+using ty0 = list<>;
+
+using ty1 = type;
+using ty1 = list>;
+
+using ty2 = type;
+using ty2 = list, A>;
+
+using ty3 = type;
+using ty3 = list, A, A>;
[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.
Re: [PATCH] c, c++: attribute format on a ctor with a vbase [PR101833, PR47634]
On 4/12/22 14:38, Marek Polacek wrote:
On Mon, Apr 11, 2022 at 04:39:22PM -0400, Jason Merrill wrote:
On 4/8/22 15:21, Marek Polacek wrote:
On Wed, Apr 06, 2022 at 04:55:54PM -0400, Jason Merrill wrote:
On 4/1/22 15:14, Marek Polacek wrote:
Attribute format takes three arguments: archetype, string-index, and
first-to-check. The last two specify the position in the function
parameter list. r63030 clarified that "Since non-static C++ methods have
an implicit this argument, the arguments of such methods should be counted
from two, not one, when giving values for string-index and first-to-check."
Therefore one has to write
struct D {
D(const char *, ...) __attribute__((format(printf, 2, 3)));
};
However -- and this is the problem in this PR -- ctors with virtual
bases also get two additional parameters: the in-charge parameter and
the VTT parameter (added in maybe_retrofit_in_chrg). In fact we'll end up
with two clones of the ctor: an in-charge and a not-in-charge version (see
build_cdtor_clones). That means that the argument position the user
specified in the attribute argument will refer to different arguments,
depending on which constructor we're currently dealing with. This can
cause a range of problems: wrong errors, confusing warnings, or crashes.
This patch corrects that; for C we don't have to do anything, and in C++
we can use num_artificial_parms_for. It would be wrong to rewrite the
attributes the user supplied, so I've added an extra parameter called
adjust_pos.
Attribute format_arg is not affected, because it requires that the
function returns "const char *" which will never be the case for cdtors.
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
PR c++/101833
PR c++/47634
gcc/c-family/ChangeLog:
* c-attribs.cc (positional_argument): Add new argument adjust_pos,
use it.
* c-common.cc (check_function_arguments): Pass fndecl to
check_function_format.
* c-common.h (check_function_format): Adjust declaration.
(maybe_adjust_arg_pos_for_attribute): Add.
(positional_argument): Adjust declaration.
* c-format.cc (decode_format_attr): Add fndecl argument. Pass it to
maybe_adjust_arg_pos_for_attribute. Adjust calls to get_constant.
I wonder about, instead of adding another parameter, allowing the current
fntype parameter to be the fndecl when we have one.
And then that gets passed down into positional_argument, so we can call
maybe_adjust_arg_pos_for_attribute there, and adjust the return value
appropriately so we don't need the extra adjustment in get_constant?
Unfortunately I can't do that. positional_argument can't return the
adjusted position, because get_constant returns it and in decode_format_attr
it's used to rewrite the arguments in the attribute list:
tree *format_num_expr = _VALUE (TREE_CHAIN (args));
tree *first_arg_num_expr = _VALUE (TREE_CHAIN (TREE_CHAIN (args)));
...
if (tree val = get_constant (fntype, atname, *format_num_expr,
2, >format_num, 0, validated_p,
adjust_pos))
*format_num_expr = val;
Could we not do that? Currently isn't it just overwriting the value with
the same value after default_conversion?
I think it is.
Maybe do that conversion directly in decode_format_attr instead?
I'm afraid I can't move the default_conversion call out of positional_argument
because positional_argument is called from a lot of handle_*_attribute
functions, and each of those would have to call default_conversion, which
we don't want to do. (Failure to call default_conversion would break e.g.
g++.dg/cpp0x/constexpr-attribute2.C.)
Maybe pass in the pointer where we want to store the converted value?
Replacing the arguments in the attribute list would lead to problems, because
when we're processing the constructor clone without the additional parameters,
the adjusted argument position would be out of whack at this point.
I've attempted to reduce the number of parameters, but it hardly seemed like
a win, here's the patch I came up with:
diff --git a/gcc/c-family/c-attribs.cc b/gcc/c-family/c-attribs.cc
index 6e17847ec9e..972476fbdf4 100644
--- a/gcc/c-family/c-attribs.cc
+++ b/gcc/c-family/c-attribs.cc
@@ -594,7 +594,7 @@ attribute_takes_identifier_p (const_tree attr_id)
}
/* Verify that argument value POS at position ARGNO to attribute NAME
- applied to function TYPE refers to a function parameter at position
+ applied to function FNTYPE refers to a function parameter at position
POS and the expected type CODE. Treat CODE == INTEGER_TYPE as
matching all C integral types except bool. If successful, return
POS after default conversions, if any. Otherwise, issue appropriate
diff --git a/gcc/c-family/c-common.cc b/gcc/c-family/c-common.cc
index 6f08b55d4a7..ffa36673ec0 100644
--- a/gcc/c-family/c-common.cc
+++
Re: [PATCH] c++: NON_DEPENDENT_EXPR is not potentially constant [PR104507]
On Wed, Feb 16, 2022 at 2:47 PM Patrick Palka wrote: > > On Tue, 15 Feb 2022, Jason Merrill wrote: > > > On 2/15/22 17:00, Patrick Palka wrote: > > > On Tue, 15 Feb 2022, Jason Merrill wrote: > > > > > > > On 2/15/22 15:13, Patrick Palka wrote: > > > > > On Tue, 15 Feb 2022, Patrick Palka wrote: > > > > > > > > > > > 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 unhandled trees (of which > > > > > > CAST_EXPR > > > > > > is one). > > > > > > > > > > > > Since cxx_eval_constant_expression always treats NON_DEPENDENT_EXPR > > > > > > as non-constant, and since NON_DEPENDENT_EXPR is also opaque to > > > > > > instantiate_non_dependent_expr, it seems futile to have p_c_e_1 ever > > > > > > return true for NON_DEPENDENT_EXPR, so let's just instead return > > > > > > false > > > > > > and avoid recursing. > > > > > > > > Well, in a template we use pce1 to decide whether to complain about > > > > something > > > > that needs to be constant but can't be. We aren't trying to get a value > > > > yet. > > > > > > Makes sense.. though for NON_DEPENDENT_EXPR in particular, ISTM this > > > tree is always used in a context where a constant expression isn't > > > required, e.g. in the build_x_* functions. > > > > Fair enough. The patch is OK with a comment to that effect. > > Thanks, I committed the following as r12-7264: Would it be OK to backport this now for 11.3, or shall we wait until after 11.3 is released? It's been two months, and the only reported fallout from this patch was PR104620, where we began to fail to diagnose an invalid consteval call within a template ahead of time (and it turned out we previously were diagnosing it only by accident). The patch also fixed PR103443 (non-dependent consteval call incorrectly rejected). > > -- >8 -- > > Subject: [PATCH] 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.cc (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. > --- > gcc/cp/constexpr.cc | 9 - > gcc/testsuite/g++.dg/template/non-dependent21.C | 9 + > 2 files changed, 17 insertions(+), 1 deletion(-) > create mode 100644 gcc/testsuite/g++.dg/template/non-dependent21.C > > diff --git a/gcc/cp/constexpr.cc b/gcc/cp/constexpr.cc > index 7274c3b760e..4716694cb71 100644 > --- a/gcc/cp/constexpr.cc > +++ b/gcc/cp/constexpr.cc > @@ -9065,6 +9065,14 @@ potential_constant_expression_1 (tree t, bool > want_rval, bool strict, bool now, > case BIND_EXPR: >return RECUR (BIND_EXPR_BODY (t), want_rval); > > +case NON_DEPENDENT_EXPR: > + /* Treat NON_DEPENDENT_EXPR as non-constant: it's not handled by > +constexpr evaluation or tsubst, so fold_non_dependent_expr can't > +do anything useful with it. And we shouldn't see it in a context > +where a constant expression is strictly required, hence the assert. > */ > + gcc_checking_assert (!(flags & tf_error)); > + return false; > + > case CLEANUP_POINT_EXPR: > case MUST_NOT_THROW_EXPR: > case
[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
