[Bug c++/96868] C++20 designated initializer erroneous warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96868 --- Comment #2 from Matt Godbolt --- Thanks: I was confused (as I think will many folks be). The examples for designated initialisers in C++20 on cppreference cite this behaviour as being useful^. Of course I understand it can be misused, and this indeed a non-default warning. Thanks for taking the time to reply! --matt ^: https://en.cppreference.com/w/cpp/language/aggregate_initialization#Designated_initializers
[Bug c++/96877] New: Erroneous warning when default initializing function pointer types defined using std::declval
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96877
Bug ID: 96877
Summary: Erroneous warning when default initializing function
pointer types defined using std::declval
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: insertinterestingnamehere at gmail dot com
Target Milestone: ---
When compiling the following with -Wextra (C++11 and later, all recent version
of gcc) the compiler emits an erroneous warning about binding a temporary in a
constructor. Note: this works fine if function_type is declared as a plain
typedef instead of using decltype and std::declval. See
https://godbolt.org/z/sjKdP5.
#include
using function_type = decltype(std::declval());
struct S {
function_type fptr = nullptr;
};
int main() {
S thing;
}
[Bug c++/96868] C++20 designated initializer erroneous warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96868
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment #1 from Marek Polacek ---
I think the warning is correct, Test::obj here is initialized from {}, but
that's not what the user might intend.
[Bug c++/96863] [9/10/11 Regression] ICE: in output_constructor_regular_field, at varasm.c:5223
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96863 Marek Polacek changed: What|Removed |Added Target Milestone|11.0|9.4 Summary|[11 Regression] ICE: in |[9/10/11 Regression] ICE: |output_constructor_regular_ |in |field, at varasm.c:5223 |output_constructor_regular_ ||field, at varasm.c:5223
[Bug c++/96863] [11 Regression] ICE: in output_constructor_regular_field, at varasm.c:5223
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96863 Marek Polacek changed: What|Removed |Added Keywords|needs-bisection | CC||jason at gcc dot gnu.org --- Comment #2 from Marek Polacek --- Started with r268368.
[Bug c++/96871] [11 Regression] Fails to parse templated constructor in template class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96871 Marek Polacek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID Keywords|needs-bisection,| |rejects-valid | --- Comment #2 from Marek Polacek --- Oh duh, this is actually DR 2237 that I implemented. It says "A simple-template-id is no longer valid as the declarator-id of a constructor or destructor." So instead of S(Arg&&... arg); write S(Arg&&... arg); This is mentioned here too: https://gcc.gnu.org/gcc-11/changes.html
[Bug target/85830] vec_popcntd is improperly defined in altivec.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85830 --- Comment #6 from CVS Commits --- The master branch has been updated by Carl Love : https://gcc.gnu.org/g:1da918e153b60ef81686dc5cd110d8608d962c79 commit r11-2958-g1da918e153b60ef81686dc5cd110d8608d962c79 Author: Carl Love Date: Thu Aug 27 13:36:13 2020 -0500 rs6000, remove improperly defined and unsupported builtins. gcc/ChangeLog 2020-08-31 Carl Love PR target/85830 * config/rs6000/altivec.h (vec_popcntb, vec_popcnth, vec_popcntw, vec_popcntd): Remove defines.
[Bug analyzer/96798] Analyzer failures on Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96798 --- Comment #12 from David Malcolm --- Does r11-2957-gbc62bfb0f43eeada02cb924e3cb5457a399b01c0 fix the failing tests seen on Darwin? In any case, I should probably also fix: > (a) looks like region_model::on_call_pre is erroneously treating a builtin I > haven't coded yet as a no-op; it should instead conservatively assume that > any escaped/reachable regions are affected (replying to myself from comment #6)
[Bug analyzer/96860] [11 Regression] ICE in apply_ctor_to_region, at analyzer/store.cc:445
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96860 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from David Malcolm --- Should be fixed by the above commit.
[Bug analyzer/96798] Analyzer failures on Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96798 --- Comment #11 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:bc62bfb0f43eeada02cb924e3cb5457a399b01c0 commit r11-2957-gbc62bfb0f43eeada02cb924e3cb5457a399b01c0 Author: David Malcolm Date: Mon Aug 31 11:55:34 2020 -0400 analyzer: handle __builtin___memset_chk [PR96798] gcc/analyzer/ChangeLog: PR analyzer/96798 * region-model.cc (region_model::on_call_pre): Handle BUILT_IN_MEMSET_CHK. gcc/testsuite/ChangeLog: PR analyzer/96798 * gcc.dg/analyzer/memset-1.c (test_5a): New.
[Bug analyzer/96798] Analyzer failures on Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96798 --- Comment #10 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:ee7bfbe5eb70a23bbf3a2cedfdcbd2ea1a20c3f2 commit r11-2956-gee7bfbe5eb70a23bbf3a2cedfdcbd2ea1a20c3f2 Author: David Malcolm Date: Mon Aug 31 16:20:55 2020 -0400 analyzer: gather builtin/internal fn handling into switch statements Clean up this code in preparation for fixing PR analyzer/96798. gcc/analyzer/ChangeLog: * region-model.cc (region_model::on_call_pre): Gather handling of builtins and of internal fns into switch statements. Handle "alloca" and BUILT_IN_ALLOCA_WITH_ALIGN.
[Bug analyzer/96860] [11 Regression] ICE in apply_ctor_to_region, at analyzer/store.cc:445
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96860 --- Comment #2 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:18056e45db1c75aa209fa9a756395ddceb867a88 commit r11-2955-g18056e45db1c75aa209fa9a756395ddceb867a88 Author: David Malcolm Date: Mon Aug 31 09:00:23 2020 -0400 analyzer: fix ICE on unknown index in CONSTRUCTOR [PR96860] PR analyzer/96860 reports an ICE inside CONSTRUCTOR-handling with --param analyzer-max-svalue-depth=0 when attempting to build a binding_map for the CONSTRUCTOR's values. The issue is that when handling (index, value) pairs for initializing an array, the index values for the elements exceeds the svalue complexity limit, and the index is thus treated as unknown, leading to a symbolic rather than concrete offset for each array element. This patch updates the CONSTRUCTOR-handling code so that it can fail, returning an unknown value for the overall value of the constructor for this case, fixing the ICE. gcc/analyzer/ChangeLog: PR analyzer/96860 * region.cc (decl_region::get_svalue_for_constructor): Support apply_ctor_to_region failing. * store.cc (binding_map::apply_ctor_to_region): Add failure handling. (binding_map::apply_ctor_val_to_range): Likewise. (binding_map::apply_ctor_pair_to_child_region): Likewise. Replace assertion that child_base_offset is not symbolic with error handling. * store.h (binding_map::apply_ctor_to_region): Convert return type from void to bool. (binding_map::apply_ctor_val_to_range): Likewise. (binding_map::apply_ctor_pair_to_child_region): Likewise. gcc/testsuite/ChangeLog: PR analyzer/96860 * gcc.dg/analyzer/pr96860-1.c: New test. * gcc.dg/analyzer/pr96860-2.c: New test.
[Bug c++/96876] missing check for destructibility of base classes in aggregate initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96876 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2020-08-31 --- Comment #1 from Marek Polacek --- Confirmed. Doesn't seem to be a regression.
[Bug c++/95291] ICE in resolve_args at gcc/cp/call.c:4482
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95291 Marek Polacek changed: What|Removed |Added CC||mateusz.pusz at gmail dot com --- Comment #4 from Marek Polacek --- *** Bug 96874 has been marked as a duplicate of this bug. ***
[Bug c++/95291] ICE in resolve_args at gcc/cp/call.c:4482
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95291 --- Comment #5 from Marek Polacek --- When fixing, let's make sure that bug 96874 is fixed too.
[Bug c++/96874] Internal Compiler Error: Segmentation fault on class NTTP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96874 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Marek Polacek --- Looks like a dup. *** This bug has been marked as a duplicate of bug 95291 ***
[Bug c++/96873] Internal compiler error in alias_ctad_tweaks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96873 Marek Polacek changed: What|Removed |Added Ever confirmed|0 |1 CC||mpolacek at gcc dot gnu.org Last reconfirmed||2020-08-31 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=94691, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=94560, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=93085 Status|UNCONFIRMED |NEW --- Comment #2 from Marek Polacek --- Confirmed, but most likely a dup of one of the bugs in See Also. The backtraces aren't identical, but I'm sure these are all related.
[Bug c++/96872] [11 Regression] ICE: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96872 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Marek Polacek --- Dup. *** This bug has been marked as a duplicate of bug 96805 ***
[Bug c++/96805] [10/11 Regression] ICE: Segmentation fault in instantiate_template / pop_nested_class()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96805 Marek Polacek changed: What|Removed |Added CC||gcc-bugs at marehr dot dialup.fu-b ||erlin.de --- Comment #7 from Marek Polacek --- *** Bug 96872 has been marked as a duplicate of this bug. ***
[Bug c++/96863] [11 Regression] ICE: in output_constructor_regular_field, at varasm.c:5223
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96863 Marek Polacek changed: What|Removed |Added Ever confirmed|0 |1 Keywords||needs-bisection Status|UNCONFIRMED |NEW CC||mpolacek at gcc dot gnu.org Last reconfirmed||2020-08-31 --- Comment #1 from Marek Polacek --- Confirmed. Not a dup of 96282 because that was fixed already. Can't bisect right now.
[Bug c++/96871] [11 Regression] Fails to parse templated constructor in template class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96871 Marek Polacek changed: What|Removed |Added Summary|Fails to parse templated|[11 Regression] Fails to |constructor in template |parse templated constructor |class |in template class CC||mpolacek at gcc dot gnu.org Target Milestone|--- |11.0 Last reconfirmed||2020-08-31 Keywords||needs-bisection, ||rejects-valid Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Marek Polacek --- Looks like an 11 regression with -std=c++20. Can't bisect right now, maybe tomorrow.
[Bug c++/96876] New: missing check for destructibility of base classes in aggregate initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96876
Bug ID: 96876
Summary: missing check for destructibility of base classes in
aggregate initialization
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: richard-gccbugzilla at metafoo dot co.uk
Target Milestone: ---
GCC accepts this invalid code (which is ill-formed because [dcl.init.aggr]/8
says it potentially-invokes the destructor for B, which [class.dtor]/15 says
requires the destructor to be accessible):
struct B {
protected:
~B() {}
};
struct C : B { int n; };
int f();
void g() {
C c{{}, f()};
}
... and generates wrong code for this similar example:
#include
struct B {
public:
~B() { puts("destroyed"); }
};
struct C : B { int n; };
int f() { throw "hello"; }
int main() {
try {
C c{{}, f()};
} catch (const char*) {
}
}
... which is required to print "destroyed" (when the B base class subobject is
destroyed during stack unwinding), but with GCC does not.
[Bug d/96869] __vectors unsupported in hardware should be rejected at compile-time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96869 --- Comment #2 from Iain Buclaw --- (In reply to Andrew Pinski from comment #1) > Hmmm, so you dont want to allow generic vector types? This is unlike GNU > c/C++. Correct, the D spec has had the following entry added. > Implementation Defined: Which vector types are supported depends > on the target. The implementation is expected to only support the > vector types that are implemented in the target's hardware. I could go one further and reject vector expressions not supported in hardware, but I don't think that kind of information is readily available in a target hook.
[Bug c++/88323] implement C++20 language features.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88323 Bug 88323 depends on bug 93529, which changed state. Bug 93529 Summary: Implement P1009R2, Array size deduction in new-expressions https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93529 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug analyzer/96763] [11 Regression] ICE in get_subregion_within_ctor, at analyzer/store.cc:379 on RANGE_EXPR index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96763 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from David Malcolm --- Should be fixed by above commit.
[Bug analyzer/96764] [11 Regression] ICE in fold_convert_const_int_from_real, at fold-const.c:2038
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96764 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from David Malcolm --- Should be fixed by above commit.
[Bug c++/93529] Implement P1009R2, Array size deduction in new-expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93529 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Marek Polacek --- Implemented in GCC 11.
[Bug c++/93529] Implement P1009R2, Array size deduction in new-expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93529
--- Comment #4 from CVS Commits ---
The master branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:73a2b8dd17dbc02c0c7e6286e90f17833aa50906
commit r11-2954-g73a2b8dd17dbc02c0c7e6286e90f17833aa50906
Author: Marek Polacek
Date: Thu Aug 13 14:56:13 2020 -0400
c++: Implement P1009: Array size deduction in new-expressions.
This patch implements C++20 P1009, allowing code like
new double[]{1,2,3}; // array bound will be deduced
Since this proposal makes the initialization rules more consistent, it is
applied to all previous versions of C++ (thus, effectively, all the way
back
to C++11).
My patch is based on Jason's patch that handled the basic case. I've
extended it to work with ()-init and also the string literal case.
Further testing revealed that to handle stuff like
new int[]{t...};
in a template, we have to consider such a NEW_EXPR type-dependent.
Obviously, we first have to expand the pack to be able to deduce the
number of elements in the array.
Curiously, while implementing this proposal, I noticed that we fail
to accept
new char[4]{"abc"};
so I've assigned 77841 to self. I think the fix will depend on the
build_new_1 hunk in this patch.
The new tree.c function build_constructor_from_vec helps us morph
a vector into a CONSTRUCTOR more efficiently.
gcc/cp/ChangeLog:
PR c++/93529
* call.c (build_new_method_call_1): Use build_constructor_from_vec
instead of build_tree_list_vec + build_constructor_from_list.
* init.c (build_new_1): Handle new char[]{"foo"}. Use
build_constructor_from_vec instead of build_tree_list_vec +
build_constructor_from_list.
(build_new): Deduce the array size in new-expression if not
present. Handle ()-init. Handle initializing an array from
a string literal.
* parser.c (cp_parser_new_type_id): Leave [] alone.
(cp_parser_direct_new_declarator): Allow [].
* pt.c (type_dependent_expression_p): In a NEW_EXPR, consider
array types whose dimension has to be deduced type-dependent.
gcc/ChangeLog:
PR c++/93529
* tree.c (build_constructor_from_vec): New.
* tree.h (build_constructor_from_vec): Declare.
gcc/testsuite/ChangeLog:
PR c++/93529
* g++.dg/cpp0x/sfinae4.C: Adjust expected result after P1009.
* g++.dg/cpp2a/new-array1.C: New test.
* g++.dg/cpp2a/new-array2.C: New test.
* g++.dg/cpp2a/new-array3.C: New test.
* g++.dg/cpp2a/new-array4.C: New test.
Co-authored-by: Jason Merrill
[Bug analyzer/96763] [11 Regression] ICE in get_subregion_within_ctor, at analyzer/store.cc:379 on RANGE_EXPR index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96763 --- Comment #2 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:0d1b4edc5fff834e8f924b20dd021ded7a21d2d2 commit r11-2953-g0d1b4edc5fff834e8f924b20dd021ded7a21d2d2 Author: David Malcolm Date: Mon Aug 24 09:33:42 2020 -0400 analyzer: fix ICE on RANGE_EXPR in CONSTRUCTORs [PR96763] gcc/analyzer/ChangeLog: PR analyzer/96763 * store.cc (binding_map::apply_ctor_to_region): Handle RANGE_EXPR by calling a new binding_map::apply_ctor_val_to_range subroutine. Split out the existing non-CONSTRUCTOR-handling code to a new apply_ctor_pair_to_child_region subroutine. (binding_map::apply_ctor_val_to_range): New. (binding_map::apply_ctor_pair_to_child_region): New, split out from binding_map::apply_ctor_to_region as noted above. * store.h (binding_map::apply_ctor_val_to_range): New decl. (binding_map::apply_ctor_pair_to_child_region): New decl. gcc/testsuite/ChangeLog: PR analyzer/96763 * g++.dg/analyzer/pr96763.C: New test.
[Bug analyzer/96764] [11 Regression] ICE in fold_convert_const_int_from_real, at fold-const.c:2038
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96764 --- Comment #2 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:ecdb93224c56189a129e97c556fe6b78e1b15a63 commit r11-2952-gecdb93224c56189a129e97c556fe6b78e1b15a63 Author: David Malcolm Date: Thu Aug 27 18:20:24 2020 -0400 analyzer: fix ICE on casting float to pointer [PR96764] gcc/analyzer/ChangeLog: PR analyzer/96764 * region-model-manager.cc (region_model_manager::maybe_fold_unaryop): Handle VIEW_CONVERT_EXPR. (region_model_manager::get_or_create_cast): Move logic for real->integer casting to... (get_code_for_cast): ...this new function, and add logic for real->non-integer casts. (region_model_manager::maybe_fold_sub_svalue): Handle VIEW_CONVERT_EXPR. * region-model.cc (region_model::add_any_constraints_from_gassign): Likewise. * svalue.cc (svalue::maybe_undo_cast): Likewise. (unaryop_svalue::dump_to_pp): Likewise. gcc/testsuite/ChangeLog: PR analyzer/96764 * gcc.dg/analyzer/pr96764.c: New test.
[Bug rtl-optimization/14319] incorrect optimization of union of structs with common initial sequences
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14319 Francois-Xavier Coudert changed: What|Removed |Added CC||fxcoudert at gcc dot gnu.org --- Comment #16 from Francois-Xavier Coudert --- There is a case in our testsuite that is exercising this check: gcc.c-torture/execute/2603-1.c It was kept in the testsuite because "the exact DR resolution is as yet unclear but it seems very likely that the modified version will be considered OK" https://gcc.gnu.org/legacy-ml/gcc-patches/2004-02/msg00498.html Either this is OK, and the bug should be reconfirmed/unsuspended. Or the test case should be removed from the GCC testsuite.
[Bug rtl-optimization/14319] incorrect optimization of union of structs with common initial sequences
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14319 Andrew Pinski changed: What|Removed |Added CC||iains at gcc dot gnu.org --- Comment #15 from Andrew Pinski --- *** Bug 96875 has been marked as a duplicate of this bug. ***
[Bug target/96875] Aliased pointers to union members result in different output with optimisation level.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96875 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #2 from Andrew Pinski --- This is an exact dup of bug 14319 *** This bug has been marked as a duplicate of bug 14319 ***
[Bug target/96875] Aliased pointers to union members result in different output with optimisation level.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96875 --- Comment #1 from Andrew Pinski --- There is a defect report against the C standard about this case and a much older gcc bugzilla filed too.
[Bug target/96875] Aliased pointers to union members result in different output with optimisation level.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96875 Iain Sandoe changed: What|Removed |Added Target||aarch64-linux-gnu, ||aarch64-darwin Ever confirmed|0 |1 CC||fxcoudert at gcc dot gnu.org, ||rsandifo at redhat dot com Keywords||alias Status|UNCONFIRMED |NEW Last reconfirmed||2020-08-31
[Bug target/96875] New: Aliased pointers to union members result in different output with optimisation level.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96875
Bug ID: 96875
Summary: Aliased pointers to union members result in different
output with optimisation level.
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: iains at gcc dot gnu.org
Target Milestone: ---
For my 0.02 GBP this is ill-conditioned code, but apparently either the try is
still out - or it has been decided to consider it OK.
struct s1 { double d; };
struct s2 { double d; };
union u { struct s1 x; struct s2 y; };
__attribute__((__noinline__))
double
f(struct s1 *a, struct s2 *b)
{
a->d = 1.0;
return b->d + 1.0;
}
int
main ()
{
union u X;
return f (, ) == 2.0;
}
O1:
f:
.LFB0:
.cfi_startproc
fmovd0, 1.0e+0
str d0, [x0]
ldr d1, [x1]
faddd0, d1, d0
ret
.cfi_endproc
this is the "expected" result.
=
O2:
f:
.LFB0:
.cfi_startproc
ldr d1, [x1]
fmovd0, 1.0e+0
str d0, [x0]
faddd0, d1, d0
ret
.cfi_endproc
this is some random answer.
I'd hazard a guess that something decides that pointers to different types
can't alias, so it's OK to move things around... but the user code bends over
backwards to force the different entities to alias.
[Bug middle-end/54201] XMM constant duplicated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54201
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #11 from Jakub Jelinek ---
The .rodata duplication should now be gone with the above commit.
I've tried
--- gcc/varasm.c.jj 2020-08-31 10:26:56.978179325 +0200
+++ gcc/varasm.c2020-08-31 19:15:34.563274307 +0200
@@ -3818,6 +3818,38 @@ force_const_mem (machine_mode in_mode, r
if (!is_a (in_mode, ))
return NULL_RTX;
+ /* Try to canonicalize CONST_VECTORs. See PR54201. */
+ if (GET_CODE (x) == CONST_VECTOR)
+{
+ machine_mode cmode = MIN_MODE_VECTOR_INT;
+ machine_mode altmode = VOIDmode;
+
+ /* Choose a MODE_VECTOR_INT mode with the same size as in_mode
+and as large as possible element, as long as the element is
+at most HWI sized (so that CONST_INTs can be used rather
+than CONST_DOUBLEs or CONST_WIDE_INTs. */
+ FOR_EACH_MODE_FROM (cmode, cmode)
+ if (known_eq (GET_MODE_SIZE (cmode), GET_MODE_SIZE (in_mode))
+ && known_le (GET_MODE_SIZE (GET_MODE_INNER (cmode)),
+HOST_BITS_PER_WIDE_INT)
+ && (altmode == VOIDmode
+ || (GET_MODE_SIZE (GET_MODE_INNER (cmode))
+ > GET_MODE_SIZE (GET_MODE_INNER (altmode)
+ altmode = cmode;
+ if (altmode != VOIDmode && altmode != in_mode)
+ {
+ rtx altx = simplify_subreg (altmode, x, in_mode, 0);
+ if (altx && GET_CODE (altx) == CONST_VECTOR)
+ {
+ rtx altret = force_const_mem (altmode, altx);
+ if (altret)
+ {
+ PUT_MODE (altret, in_mode);
+ return altret;
+ }
+ }
+ }
+}
/* If we're not allowed to drop X into the constant pool, don't. */
if (targetm.cannot_force_const_mem (mode, x))
return NULL_RTX;
as a variant of Richi's patch, but e.g. on
typedef int V __attribute__((vector_size (16)));
typedef long long int W __attribute__((vector_size (16)));
typedef float X __attribute__((vector_size (16)));
void
foo (V *v, W *w, X *x)
{
*v += (V) (X) { 2.0f, 2.0f, 2.0f, 2.0f };
*w += (W) (X) { 2.0f, 2.0f, 2.0f, 2.0f };
*x += (X) { 2.0f, 2.0f, 2.0f, 2.0f };
}
nothing will really try to share the loads, so the question is if it would gain
us anything.
[Bug c++/96873] Internal compiler error in alias_ctad_tweaks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96873
--- Comment #1 from Mateusz Pusz ---
Similar error but in a different line happens for:
```
#include
template
struct basic_fixed_string {
CharT data_[N + 1] = {};
constexpr basic_fixed_string(CharT ch) noexcept { data_[0] = ch; }
constexpr basic_fixed_string(const CharT ()[N + 1]) noexcept
{
if constexpr (N != 0)
for (std::size_t i = 0; i < N; ++i) data_[i] = txt[i];
}
[[nodiscard]] constexpr const CharT& operator[](std::size_t index) const
noexcept { return data_[index]; }
[[nodiscard]] constexpr CharT operator[](std::size_t index) noexcept { return
data_[index]; }
template
[[nodiscard]] constexpr friend basic_fixed_string operator+(
const basic_fixed_string& lhs, const basic_fixed_string& rhs)
noexcept
{
CharT txt[N + N2 + 1] = {};
for(std::size_t i = 0; i != N; ++i) txt[i] = lhs[i];
for(std::size_t i = 0; i != N2; ++i) txt[N + i] = rhs[i];
return basic_fixed_string(txt);
}
};
template
basic_fixed_string(const CharT ()[N]) -> basic_fixed_string;
template
basic_fixed_string(CharT) -> basic_fixed_string;
template
using fixed_string = basic_fixed_string;
fixed_string txt = "txt";
```
[Bug c++/96874] New: Internal Compiler Error: Segmentation fault on class NTTP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96874
Bug ID: 96874
Summary: Internal Compiler Error: Segmentation fault on class
NTTP
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mateusz.pusz at gmail dot com
Target Milestone: ---
#include
template
struct basic_fixed_string {
CharT data_[N + 1] = {};
constexpr basic_fixed_string(CharT ch) noexcept { data_[0] = ch; }
constexpr basic_fixed_string(const CharT ()[N + 1]) noexcept
{
if constexpr (N != 0)
for (std::size_t i = 0; i < N; ++i) data_[i] = txt[i];
}
[[nodiscard]] constexpr const CharT& operator[](std::size_t index) const
noexcept { return data_[index]; }
[[nodiscard]] constexpr CharT operator[](std::size_t index) noexcept { return
data_[index]; }
template
[[nodiscard]] constexpr friend basic_fixed_string operator+(
const basic_fixed_string& lhs, const basic_fixed_string& rhs)
noexcept
{
CharT txt[N + N2 + 1] = {};
for(std::size_t i = 0; i != N; ++i) txt[i] = lhs[i];
for(std::size_t i = 0; i != N2; ++i) txt[N + i] = rhs[i];
return basic_fixed_string(txt);
}
};
template
basic_fixed_string(const CharT ()[N]) -> basic_fixed_string;
template
basic_fixed_string(CharT) -> basic_fixed_string;
template
using fixed_string = basic_fixed_string;
template
struct X {};
template
auto merge(X, X)
{
return X();
}
auto res = merge(X<"ab">(), X<"cd">());
[Bug c++/96873] New: Internal compiler error in alias_ctad_tweaks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96873
Bug ID: 96873
Summary: Internal compiler error in alias_ctad_tweaks
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mateusz.pusz at gmail dot com
Target Milestone: ---
#include
template
struct basic_fixed_string {
CharT data_[N + 1] = {};
constexpr basic_fixed_string(CharT ch) noexcept { data_[0] = ch; }
constexpr basic_fixed_string(const CharT ()[N + 1]) noexcept
{
if constexpr (N != 0)
for (std::size_t i = 0; i < N; ++i) data_[i] = txt[i];
}
};
template
basic_fixed_string(const CharT ()[N]) -> basic_fixed_string;
template
basic_fixed_string(CharT) -> basic_fixed_string;
template
using fixed_string = basic_fixed_string;
template
struct X {};
X<"txt"> x;
[Bug fortran/96859] Wrong answer with intrinsic merge_bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96859 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #2 from kargl at gcc dot gnu.org --- gfortran appears to be correct. Writing an actual program with your examples, I have program foo print '(I0,1X,I0)', & & merge_bits(32767_2,o'1234567',32767_2), & & ior(iand(32767_2,32767_2),iand(o'1234567',not(32767_2))) print '(I0,1X,I0)', & & merge_bits(o'1234567',32767_2,o'1234567'), & & ior(iand(o'1234567',int(o'1234567',2)),iand(32767_2,not(int(o'1234567',2 print '(I0,1X,I0)', & & merge_bits(32767_2,o'1234567',b'010101'), & & ior(iand(32767_2,b'010101'),iand(o'1234567', not(int(b'010101',2 print '(I0,1X,I0)', & & merge_bits(32767_2,o'1234567',z'12345678'), & & ior(iand(32767_2,z'12345678'), iand(o'1234567',not(int( z'12345678',2 end program foo
[Bug c++/96872] New: [11 Regression] ICE: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96872
Bug ID: 96872
Summary: [11 Regression] ICE: Segmentation fault
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc-bugs at marehr dot dialup.fu-berlin.de
Target Milestone: ---
Hi gcc-team,
the following code ices
```
template struct concat_view {
struct {
template using constify_if = int;
using concat_view_t = constify_if;
};
};
```
https://godbolt.org/z/db3qq6
with
> g++-git -std=c++2a
and outputs
```
ice.cpp: In substitution of ‘template template using constify_if
= int [with = concat_view< >;
= ]’:
ice.cpp:4:50: required from here
ice.cpp:4:50: internal compiler error: Segmentation fault
4 | using concat_view_t = constify_if;
| ^
Please submit a full bug report,
with preprocessed source if appropriate.
See
[Bug c++/96871] New: Fails to parse templated constructor in template class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96871
Bug ID: 96871
Summary: Fails to parse templated constructor in template class
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tiagomacarios at gmail dot com
Target Milestone: ---
Both clang and MSVC compile the below fine - gcc fails.
https://godbolt.org/z/hfPdKT
#include
template
struct S {
template
S(Arg&&... arg);
};
:6:11: error: expected ')' before '&&' token
6 | S(Arg&&... arg);
| ~ ^~
| )
[Bug fortran/96870] Class name on error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96870 --- Comment #1 from José Rui Faustino de Sousa --- Patch posted: https://gcc.gnu.org/pipermail/fortran/2020-August/054955.html
[Bug fortran/96870] New: Class name on error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96870 Bug ID: 96870 Summary: Class name on error message Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jrfsousa at gmail dot com Target Milestone: --- Created attachment 49161 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49161=edit Fortran code demonstrating problems. Hi all! Having error messages with the internal class name is not very helpful for the average user: Error: Type mismatch in argument ‘p’ at (1); passed CLASS(__class_main_p_T0_p) to CLASS(__class_main_p_T1_t) Seen on: GNU Fortran (GCC) 9.3.1 20200831 GNU Fortran (GCC) 10.2.1 20200831 GNU Fortran (GCC) 11.0.0 20200831 (experimental) Thank you very much. Best regards, José Rui
[Bug d/96869] __vectors unsupported in hardware should be rejected at compile-time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96869 --- Comment #1 from Andrew Pinski --- Hmmm, so you dont want to allow generic vector types? This is unlike GNU c/C++.
[Bug d/96869] New: __vectors unsupported in hardware should be rejected at compile-time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96869 Bug ID: 96869 Summary: __vectors unsupported in hardware should be rejected at compile-time Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: d Assignee: ibuclaw at gdcproject dot org Reporter: ibuclaw at gdcproject dot org Target Milestone: --- It should also be possible to use __traits(compiles) in order to determine whether a vector is supported or not. Currently, pretty much any __vector is permissible. The desired result would be to only use targetm.vector_mode_supported_p as gate for whether to accept the use of a vector type or not. Splitting up the simd.d test file into more granular tests should be done with this as well.
[Bug tree-optimization/96818] [11 Regression] ICE: in decompose, at wide-int.h:984 at -O since r11-2883
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96818 --- Comment #9 from CVS Commits --- The master branch has been updated by Aldy Hernandez : https://gcc.gnu.org/g:d503cd98713a41aad34ade2b9b0d9973efb21e11 commit r11-2951-gd503cd98713a41aad34ade2b9b0d9973efb21e11 Author: Aldy Hernandez Date: Fri Aug 28 18:44:58 2020 +0200 PR tree-optimization/96818 - cast label range to type of switch operand PR tree-optimization/96818 * tree-vrp.c (find_case_label_range): Cast label range to type of switch operand.
[Bug c++/96862] -frounding-math -std=c++2a error: '(1.29e+2 * 6.9314718055994529e-1)' is not a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96862 --- Comment #9 from Jakub Jelinek --- I don't know. fold-const.c has: #define START_FOLD_INIT \ int saved_signaling_nans = flag_signaling_nans;\ int saved_trapping_math = flag_trapping_math;\ int saved_rounding_math = flag_rounding_math;\ int saved_trapv = flag_trapv;\ int saved_folding_initializer = folding_initializer;\ flag_signaling_nans = 0;\ flag_trapping_math = 0;\ flag_rounding_math = 0;\ flag_trapv = 0;\ folding_initializer = 1; #define END_FOLD_INIT \ flag_signaling_nans = saved_signaling_nans;\ flag_trapping_math = saved_trapping_math;\ flag_rounding_math = saved_rounding_math;\ flag_trapv = saved_trapv;\ folding_initializer = saved_folding_initializer;
[Bug c++/96862] -frounding-math -std=c++2a error: '(1.29e+2 * 6.9314718055994529e-1)' is not a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96862 --- Comment #8 from Marc Glisse --- Should we handle flag_trapping_math at the same time?
[Bug target/96791] ICE in convert_mode_scalar, at expr.c:412
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96791 --- Comment #7 from acsawdey at gcc dot gnu.org --- I wonder if this other case works properly when compiled with -m64. Trying to generate a stxvp with a 32-bit address seems odd.
[Bug c++/96862] -frounding-math -std=c++2a error: '(1.29e+2 * 6.9314718055994529e-1)' is not a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96862 --- Comment #7 from Jakub Jelinek --- Created attachment 49160 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49160=edit gcc11-pr96862.patch Untested patch. e and f initializers are still evaluated at runtime and will depend on the rounding mode.
[Bug analyzer/96860] [11 Regression] ICE in apply_ctor_to_region, at analyzer/store.cc:445
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96860 David Malcolm changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-08-31 --- Comment #1 from David Malcolm --- Thanks for filing this bug. Confirmed; am testing a fix.
[Bug c++/96862] -frounding-math -std=c++2a error: '(1.29e+2 * 6.9314718055994529e-1)' is not a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96862 --- Comment #6 from Jonathan Wakely --- Also C++ [expr.const] p12.
[Bug target/96847] Code size increase +42% depending on memory size allocated on stack for ARM Cortex-M3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96847 --- Comment #2 from Fredrik Hederstierna --- Ok thanks, just wanted also to clarify that the size increase was not actually due to changing array sizes, but it was difference between GCC-9.2 and GCC-10.2 for the _same_ array lengths. So GCC-10.2 generated worse code then previous GCC versions for this exact same code. BR Fredrik
[Bug c++/96862] -frounding-math -std=c++2a error: '(1.29e+2 * 6.9314718055994529e-1)' is not a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96862
--- Comment #5 from Marc Glisse ---
"[Note: This document does not require an implementation to support the
FENV_ACCESS pragma; it is implementation-defined (15.8) whether the pragma
is supported. As a consequence, it is implementation-defined whether
these functions can be used to test floating-point status flags, set
floating-point control modes, or run under non-default mode settings. If
the pragma is used to enable control over the floating-point environment,
this document does not specify the effect on floating-point evaluation in
constant expressions. — end note]"
So the C++ standard lets us choose what we want gcc to do in this case. The C
standard is of course more precise, but using its own definition of constant
expressions
http://port70.net/~nsz/c/c11/n1570.html#F.8.4
"1 An arithmetic constant expression of floating type, other than one in an
initializer for an object that has static or thread storage duration, is
evaluated (as if) during execution; thus, it is affected by any operative
floating-point control modes and raises floating-point exceptions as required
by IEC 60559 (provided the state for the FENV_ACCESS pragma is ''on'').366)
2 EXAMPLE
#include
#pragma STDC FENV_ACCESS ON
void f(void)
{
float w[] = { 0.0/0.0 }; // raises an
exception
static float x = 0.0/0.0; // does not raise
an exception
float y = 0.0/0.0;// raises an
exception
double z = 0.0/0.0; // raises an
exception
/* ... */
}
3 For the static initialization, the division is done at translation time,
raising no (execution-time) floating- point exceptions. On the other hand, for
the three automatic initializations the invalid division occurs at execution
time."
So Jakub's proposition makes sense, fold inexact operations when we have to
(and use default (nearest) rounding in that case, as long as we don't have
pragma fenv_round). Initializing a global (before main starts) also looks like
a place where folding could make sense, although it is less important.
[Bug c++/96867] [11 Regression] ICE: tree check: expected parm_decl, have var_decl in handle_omp_array_sections_1, at cp/semantics.c:5086 since r11-2849
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96867 --- Comment #2 from Jakub Jelinek --- Created attachment 49159 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49159=edit gcc11-pr96867.patch Untested fix.
[Bug c++/96862] -frounding-math -std=c++2a error: '(1.29e+2 * 6.9314718055994529e-1)' is not a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96862 --- Comment #4 from Laurent Rineau --- At the compiler level, I do not think the bug is related to `-std=c++2a`. That flags was there only to trigger the bug from the recent versions of libstdc++ since: commit e6c76f0d3327bf00c96f5a63961c1d5ab77512db Author: Patrick Palka Date: Wed Aug 19 09:12:55 2020 -0400
[Bug analyzer/96860] [11 Regression] ICE in apply_ctor_to_region, at analyzer/store.cc:445
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96860 Richard Biener changed: What|Removed |Added Target Milestone|--- |11.0 Priority|P3 |P4
[Bug target/96861] Integer min/max optimization failed under -march=skylake-avx512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96861
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Last reconfirmed||2020-08-31
Keywords||missed-optimization
--- Comment #1 from Richard Biener ---
Collected chain #1...
insns: 6
defs to convert: r84, r85
Computing gain for chain #1...
Instruction gain 8 for 6: {r84:SI=smax(r85:SI,0x1);clobber flags:CC;}
REG_DEAD r85:SI
REG_UNUSED flags:CC
Instruction conversion gain: 8
Registers conversion cost: 4
Total gain: 4
Converting chain #1...
else if (GET_CODE (src) == SMAX
|| GET_CODE (src) == SMIN
|| GET_CODE (src) == UMAX
|| GET_CODE (src) == UMIN)
{
/* We do not have any conditional move cost, estimate it as a
reg-reg move. Comparisons are costed as adds. */
igain += m * (COSTS_N_INSNS (2) + ix86_cost->add);
/* Integer SSE ops are all costed the same. */
igain -= ix86_cost->sse_op;
}
is a bit of hand-waving, esp. since costs in general have not been
very consistent between the GPR and vector parts of the cores
(that also hurts vector cost estimates btw which also compare those
apples vs. oranges)
[Bug c++/96862] -frounding-math -std=c++2a error: '(1.29e+2 * 6.9314718055994529e-1)' is not a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96862 Richard Biener changed: What|Removed |Added Target Milestone|11.0|--- Component|libstdc++ |c++ Keywords||rejects-valid Version|unknown |11.0
[Bug c++/96863] [11 Regression] ICE: in output_constructor_regular_field, at varasm.c:5223
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96863 Richard Biener changed: What|Removed |Added Keywords||ice-on-valid-code Target Milestone|--- |11.0
[Bug target/96864] loop not vectorized due AVX512 condition handling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96864 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Summary|loop not vectorized due to |loop not vectorized due |cost model |AVX512 condition handling Blocks||53947 Keywords||missed-optimization Target||x86_64-*-* i?86-*-* Ever confirmed|0 |1 Last reconfirmed||2020-08-31 --- Comment #1 from Richard Biener --- t.c:3:5: missed: not vectorized: relevant stmt not supported: patt_25 = () patt_24; t.c:6:5: missed: bad operation or unsupported loop bound. t.c:6:5: note: * Analysis failed with vector mode V4DF it's more a bad pattern for condition vectorization and AVX512 it seems. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 [Bug 53947] [meta-bug] vectorizer missed-optimizations
[Bug c++/96867] [11 Regression] ICE: tree check: expected parm_decl, have var_decl in handle_omp_array_sections_1, at cp/semantics.c:5086 since r11-2849
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96867 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Depends on||96678 Status|NEW |ASSIGNED Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96678 [Bug 96678] [OpenMP] Rejects map(var[:]) of known size with "for pointer type length expression must be specified"
[Bug c++/96867] [11 Regression] ICE: tree check: expected parm_decl, have var_decl in handle_omp_array_sections_1, at cp/semantics.c:5086 since r11-2849
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96867 Jakub Jelinek changed: What|Removed |Added Target Milestone|--- |11.0 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2020-08-31 Summary|ICE: tree check: expected |[11 Regression] ICE: tree |parm_decl, have var_decl in |check: expected parm_decl, |handle_omp_array_sections_1 |have var_decl in |, at cp/semantics.c:5086|handle_omp_array_sections_1 ||, at cp/semantics.c:5086 ||since r11-2849 CC||jakub at gcc dot gnu.org Priority|P3 |P1 --- Comment #1 from Jakub Jelinek --- Started with r11-2849-g3d5ed337cb354c2f85a9caf60377bad887b18d53
[Bug c++/96868] New: C++20 designated initializer erroneous warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96868
Bug ID: 96868
Summary: C++20 designated initializer erroneous warnings
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: matt at godbolt dot org
Target Milestone: ---
The following code, with -Wall -Wextra, GCC 10.x or trunk, -std=c++20:
```
struct MyObj {
MyObj();
};
struct Test {
int a{};
MyObj obj;
};
Test t() {
Test t{.a = 1};
return t;
}
```
Creates a warning:
```
: In function 'Test t()':
:11:18: warning: missing initializer for member 'Test::obj'
[-Wmissing-field-initializers]
11 | Test t{.a = 1};
| ^
```
The "obj" is not missing initialization: the generated code correctly calls
MyObj::MyObj().
clang issues no diagnostic on the same code (even with -Weverything).
May be a duplicate of bug #82283 or bug #84685, but those have far more
complex-looking initialiser lists.
CE link: https://godbolt.org/z/b75P6r
[Bug c++/96867] New: ICE: tree check: expected parm_decl, have var_decl in handle_omp_array_sections_1, at cp/semantics.c:5086
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96867
Bug ID: 96867
Summary: ICE: tree check: expected parm_decl, have var_decl in
handle_omp_array_sections_1, at cp/semantics.c:5086
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, openmp
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
gcc-11.0.0-alpha20200830 snapshot (g:6ccadc4c0486ff011a32c74de1a31148acb3cbe2)
ICEs when compiling the following testcase, reduced from
test/OpenMP/target_update_to_messages.cpp from the clang 10.0.1 test suite, w/
-fopenmp:
int *cq;
void
l0 (int va)
{
#pragma omp target update to (va, cq[:])
}
% g++-11.0.0 -fopenmp -c jwicc9e4.cpp
jwicc9e4.cpp: In function 'void l0(int)':
jwicc9e4.cpp:6:41: internal compiler error: tree check: expected parm_decl,
have var_decl in handle_omp_array_sections_1, at cp/semantics.c:5086
6 | #pragma omp target update to (va, cq[:])
| ^
0x7c2ce2 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200830/work/gcc-11-20200830/gcc/tree.c:9714
0x68e1c2 tree_check(tree_node*, char const*, int, char const*, tree_code)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200830/work/gcc-11-20200830/gcc/tree.h:3295
0x68e1c2 handle_omp_array_sections_1
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200830/work/gcc-11-20200830/gcc/cp/semantics.c:5086
0xa61af2 handle_omp_array_sections
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200830/work/gcc-11-20200830/gcc/cp/semantics.c:5159
0xa669e9 finish_omp_clauses(tree_node*, c_omp_region_type)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200830/work/gcc-11-20200830/gcc/cp/semantics.c:7325
0x9bde94 cp_parser_omp_all_clauses
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200830/work/gcc-11-20200830/gcc/cp/parser.c:37627
0x9db114 cp_parser_omp_target_update
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200830/work/gcc-11-20200830/gcc/cp/parser.c:40714
0x9db114 cp_parser_omp_target
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200830/work/gcc-11-20200830/gcc/cp/parser.c:40893
0x9ae8b2 cp_parser_pragma
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200830/work/gcc-11-20200830/gcc/cp/parser.c:43948
0x9b77bc cp_parser_statement
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200830/work/gcc-11-20200830/gcc/cp/parser.c:11529
0x9b845d cp_parser_statement_seq_opt
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200830/work/gcc-11-20200830/gcc/cp/parser.c:11921
0x9b8538 cp_parser_compound_statement
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200830/work/gcc-11-20200830/gcc/cp/parser.c:11871
0x9d0bfc cp_parser_function_body
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200830/work/gcc-11-20200830/gcc/cp/parser.c:23170
0x9d0bfc cp_parser_ctor_initializer_opt_and_function_body
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200830/work/gcc-11-20200830/gcc/cp/parser.c:23221
0x9d43d9 cp_parser_function_definition_after_declarator
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200830/work/gcc-11-20200830/gcc/cp/parser.c:29116
0x9d5439 cp_parser_function_definition_from_specifiers_and_declarator
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200830/work/gcc-11-20200830/gcc/cp/parser.c:29032
0x9d5439 cp_parser_init_declarator
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200830/work/gcc-11-20200830/gcc/cp/parser.c:20776
0x9b473e cp_parser_simple_declaration
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200830/work/gcc-11-20200830/gcc/cp/parser.c:13811
0x9e06fe cp_parser_declaration
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200830/work/gcc-11-20200830/gcc/cp/parser.c:13510
0x9e0df0 cp_parser_translation_unit
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200830/work/gcc-11-20200830/gcc/cp/parser.c:4793
target_update_from_messages.cpp fails similarly.
[Bug target/96866] New: ICE in print_operand_address, at config/rs6000/rs6000.c:13560
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96866 Bug ID: 96866 Summary: ICE in print_operand_address, at config/rs6000/rs6000.c:13560 Product: gcc Version: 11.0 Status: UNCONFIRMED Keywords: ice-on-invalid-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: asolokha at gmx dot com Target Milestone: --- Target: powerpc-*-linux-gnu gcc-11.0.0-alpha20200830 snapshot (g:6ccadc4c0486ff011a32c74de1a31148acb3cbe2) ICEs when compiling gcc/testsuite/gcc.target/aarch64/asm-2.c w/ -fPIC: % powerpc-e300c3-linux-gnu-gcc-11.0.0 -fPIC -c gcc/testsuite/gcc.target/aarch64/asm-2.c during RTL pass: final gcc/testsuite/gcc.target/aarch64/asm-2.c: In function 'f': gcc/testsuite/gcc.target/aarch64/asm-2.c:10:1: internal compiler error: in print_operand_address, at config/rs6000/rs6000.c:13560 10 | } | ^ 0x700ec6 print_operand_address(_IO_FILE*, rtx_def*) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200830/work/gcc-11-20200830/gcc/config/rs6000/rs6000.c:13560 0xa3de1d output_address(machine_mode, rtx_def*) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200830/work/gcc-11-20200830/gcc/final.c:4067 0xa3eb4d output_asm_insn(char const*, rtx_def**) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200830/work/gcc-11-20200830/gcc/final.c:3924 0xa42c8c final_scan_insn_1 /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200830/work/gcc-11-20200830/gcc/final.c:2715 0xa42f28 final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200830/work/gcc-11-20200830/gcc/final.c:3152 0xa43046 final_1 /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200830/work/gcc-11-20200830/gcc/final.c:2020 0xa43d01 rest_of_handle_final /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200830/work/gcc-11-20200830/gcc/final.c:4658 0xa43d01 execute /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200830/work/gcc-11-20200830/gcc/final.c:4736
[Bug target/96854] [10 Regression] avx vectorizer breaks complex arithmetic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96854 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Richard Biener --- Fixed.
[Bug target/96854] [10 Regression] avx vectorizer breaks complex arithmetic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96854 --- Comment #9 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:f089569851ca9c8a81400dd8a159f86636ed20ec commit r11-2949-gf089569851ca9c8a81400dd8a159f86636ed20ec Author: Richard Biener Date: Mon Aug 31 13:36:09 2020 +0200 tree-optimization/96854 - testcase for SLP reduction of two-operator This adds the testcase for the already fixed PR. 2020-08-31 Richard Biener PR tree-optimization/96854 * gcc.dg/vect/pr96854.c: New testcase.
[Bug target/96854] [10 Regression] avx vectorizer breaks complex arithmetic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96854 --- Comment #8 from CVS Commits --- The releases/gcc-10 branch has been updated by Richard Biener : https://gcc.gnu.org/g:9f980cdba9e2fc0cc3f50c2c790f53b4dcd9dbe5 commit r10-8693-g9f980cdba9e2fc0cc3f50c2c790f53b4dcd9dbe5 Author: Richard Biener Date: Mon Aug 31 13:36:09 2020 +0200 tree-optimization/96854 - SLP reduction of two-operator is broken This fixes SLP reduction of two-operator operations by marking those not supported. In fact any live lane out of such an operation cannot be code-generated correctly. 2020-08-31 Richard Biener PR tree-optimization/96854 * tree-vect-loop.c (vectorizable_live_operation): Disallow SLP_TREE_TWO_OPERATORS nodes. * gcc.dg/vect/pr96854.c: New testcase.
[Bug target/96854] [10 Regression] avx vectorizer breaks complex arithmetic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96854 --- Comment #7 from Richard Biener --- On trunk we fail the SLP reduction vectorization because a VEC_PERM SLP reduction operation is not supported by epilogue generation.
[Bug target/96854] [10 Regression] avx vectorizer breaks complex arithmetic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96854 --- Comment #6 from Richard Biener --- (In reply to Michael_S from comment #4) > Pay attention that it's not just AVX. > '-mavx2 -mfma -Ofast' generates different code, but at the end gives the > same wrong result. > Unfortunately, I have no AVX512 hardware to test, but wouldn't be surprised > if it's also broken in 10.2. Even SSE codegen is broken, you just need -fno-vect-cost-model to trigger it there.
[Bug target/96854] [10 Regression] avx vectorizer breaks complex arithmetic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96854 --- Comment #5 from Richard Biener --- OK so the issue is that SLP_TREE_TWO_OPERATORS as it used to be cannot be used to drive live operation vectorization (it does it twice but with only the intermediate vector results). The easiest is to not try to fix this (the issue is latent everywhere) and simply punt on such live operations. That will force non-SLP vectorization. The triggering rev. opened up the SLP vectorization opportunity and wasn't at fault itself. Testing patch.
[Bug libstdc++/96862] -frounding-math -std=c++2a error: '(1.29e+2 * 6.9314718055994529e-1)' is not a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96862 Jakub Jelinek changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- What fold-const.c has is: /* Don't constant fold this floating point operation if the result may dependent upon the run-time rounding mode and flag_rounding_math is set, or if GCC's software emulation is unable to accurately represent the result. */ if ((flag_rounding_math || (MODE_COMPOSITE_P (mode) && !flag_unsafe_math_optimizations)) && (inexact || !real_identical (, ))) return NULL_TREE; i.e. if the result is inexact, it punts with -frounding-math (or for IBM double double without -ffast-math). So are you suggesting that constexpr.c should temporarily disable flag_rounding_math during !allow_non_constant mode (or rather manifestly_const_eval || !allow_non_constant mode), perhaps directly in cxx_eval_outermost_constant_expr, on the basis that constant evaluation happens when the rounding mode couldn't be changed? For constant evaluation not required by the standard we need to still punt IMNSHO, as that is normally evaluated at runtime where it could be affected by rounding mode.
[Bug libstdc++/96862] -frounding-math -std=c++2a error: '(1.29e+2 * 6.9314718055994529e-1)' is not a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96862 --- Comment #2 from Jonathan Wakely --- I think this is a compiler bug. The arithmetic must be valid in constexpr. It does not have to give the same result as it would during runtime evaluation, so I think constexpr evaluation should not be disabled by -frounding-math.
[Bug target/69031] ICE: in hash_rtx_cb, at cse.c:2533 with -fPIC -fselective-scheduling and __builtin_setjmp()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69031 Arseny Solokha changed: What|Removed |Added CC||asolokha at gmx dot com --- Comment #2 from Arseny Solokha --- Is it still an issue? I cannot reproduce it w/ the current gcc-11.0.0 snapshot. I've managed to find a PR96865, though.
[Bug rtl-optimization/96865] New: ICE in hash_rtx_cb, at cse.c:2548
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96865
Bug ID: 96865
Summary: ICE in hash_rtx_cb, at cse.c:2548
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
Target: powerpc-*-linux-gnu
gcc-11.0.0-alpha20200830 snapshot (g:6ccadc4c0486ff011a32c74de1a31148acb3cbe2)
ICEs when compiling the following testcase, reduced from
gcc/testsuite/gcc.target/sparc/tls-ld-uint16.c, w/ -m32 -O2 -fPIC
-fselective-scheduling:
__thread int ky __attribute__ ((tls_model ("local-dynamic")));
void
y9 (int cw)
{
ky = cw;
}
% powerpc-e300c3-linux-gnu-gcc-11.0.0 -m32 -O2 -fPIC -fselective-scheduling -c
ggkraci7.c
during RTL pass: sched1
ggkraci7.c: In function 'y9':
ggkraci7.c:7:1: internal compiler error: in hash_rtx_cb, at cse.c:2548
7 | }
| ^
0x75e4f1 hash_rtx_cb(rtx_def const*, machine_mode, int*, int*, bool, int
(*)(rtx_def const*, machine_mode, rtx_def**, machine_mode*))
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200830/work/gcc-11-20200830/gcc/cse.c:2548
0x159e1fc hash_rtx_cb(rtx_def const*, machine_mode, int*, int*, bool, int
(*)(rtx_def const*, machine_mode, rtx_def**, machine_mode*))
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200830/work/gcc-11-20200830/gcc/cse.c:2526
0xd3eff8 vinsn_init
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200830/work/gcc-11-20200830/gcc/sel-sched-ir.c:1199
0xd4243f vinsn_create
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200830/work/gcc-11-20200830/gcc/sel-sched-ir.c:1231
0xd4243f init_global_and_expr_for_insn
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200830/work/gcc-11-20200830/gcc/sel-sched-ir.c:3028
0xd352db sched_scan
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200830/work/gcc-11-20200830/gcc/sel-sched-ir.c:2818
0xd3804a sel_init_global_and_expr(vec)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200830/work/gcc-11-20200830/gcc/sel-sched-ir.c:3050
0xd52743 sel_region_init
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200830/work/gcc-11-20200830/gcc/sel-sched.c:6901
0xd52743 sel_sched_region(int)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200830/work/gcc-11-20200830/gcc/sel-sched.c:7624
0xd53c59 run_selective_scheduling()
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200830/work/gcc-11-20200830/gcc/sel-sched.c:7720
0xd33904 rest_of_handle_sched
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200830/work/gcc-11-20200830/gcc/sched-rgn.c:3724
0xd33904 execute
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200830/work/gcc-11-20200830/gcc/sched-rgn.c:3834
[Bug target/96855] [11 Regression] r11-571 regression FAIL: gcc.target/i386/pr92658-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96855 --- Comment #3 from Hongtao.liu --- r11-571-ge740f3d73144abbca1ad98a04825c6bd63314a0b
[Bug target/96857] [11 Regression] FAIL: gcc.target/i386/avx512bw-pr95488-1.c scan-assembler-times vpmullw[^\n]*zmm 2 on Linux/x86_64 (-m64 -march=cascadelake)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96857 --- Comment #1 from Hongtao.liu --- r11-1301-54cdb2f5a5b01a482d7cbce30e7b738558eecf59
[Bug target/96856] [11 Regression] FAIL: gcc.target/i386/pr92645-4.c scan-tree-dump-times optimized "VEC_PACK_TRUNC" 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96856 --- Comment #2 from Hongtao.liu --- (In reply to Martin Liška from comment #1) > Can you please paste git commits in a pretty format: > > $ git gcc-descr --full e740f3d73144abbca1ad98a04825c6bd63314a0b > r11-571-ge740f3d73144abbca1ad98a04825c6bd63314a0b > > ? Will do.
[Bug target/96864] New: loop not vectorized due to cost model
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96864
Bug ID: 96864
Summary: loop not vectorized due to cost model
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: crazylht at gmail dot com
CC: hjl.tools at gmail dot com
Target Milestone: ---
cat test.c
---
double d1[1024], d2[1024];
char c1[1024];
int test4(int n)
{
int i;
for (int i = 0; i < 1024; i++)
c1[i] = d1[i] > d2[i] ? c1[i] : 1;
}
---
loop is not vectorized with under -mtune=skylake-avx512 but success with
-mtune=generic
Refer to https://godbolt.org/z/xPGhTh
output of -fopt-info-all
---
Unit growth for small function inlining: 16->16 (0%)
Inlined 0 calls, eliminated 0 functions
test.c:6:5: missed: couldn't vectorize loop
test.c:7:17: missed: not vectorized: no vectype for stmt: _1 = d1[i_13];
scalar_type: double
test.c:6:5: note: * Analysis failed with vector mode V4DF
test.c:6:5: note: * Skipping vector mode V32QI, which would repeat the
analysis for V4DF
test.c:3:5: note: vectorized 0 loops in function.
test.c:3:5: note: * Analysis failed with vector mode VOID
test.c:7:13: note: * Analysis failed with vector mode V4DF
test.c:7:13: note: * Skipping vector mode V32QI, which would repeat the
analysis for V4DF
test.c:7:13: note: * Analysis failed with vector mode V32QI
test.c:7:13: note: * Skipping vector mode V32QI, which would repeat the
analysis for V32QI
test.c:6:5: note: * Analysis failed with vector mode V32QI
test.c:6:5: note: * Skipping vector mode V32QI, which would repeat the
analysis for V32QI
test.c:6:5: note: * Analysis failed with vector mode VOID
test.c:8:1: note: * Analysis failed with vector mode VOID
---
Seems problem of cost model.
[Bug c++/96863] New: [11 Regression] ICE: in output_constructor_regular_field, at varasm.c:5223
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96863
Bug ID: 96863
Summary: [11 Regression] ICE: in
output_constructor_regular_field, at varasm.c:5223
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc-bugs at marehr dot dialup.fu-berlin.de
Target Milestone: ---
Hi gcc-team,
the following code ices:
```c++
#include
namespace seqan3 {
template struct pipeable_config_element;
template
struct pipeable_config_element {};
template struct pipeable_config_element {
value_t value;
};
struct gap_scheme {
int gap = 1;
};
template
struct configuration : std::tuple {
template
constexpr configuration(pipeable_config_element const) {}
template constexpr configuration(std::tuple<> const) {}
template
constexpr auto push_back(config_element_t) const {
return configuration{std::tuple{}};
}
};
template
configuration(pipeable_config_element const)
-> configuration;
} // namespace seqan3
namespace seqan3::align_cfg {
template
struct gap : pipeable_config_element, gap_scheme_t> {
gap() = default;
constexpr gap(gap_scheme_t const)
: pipeable_config_element() {}
};
} // namespace seqan3::align_cfg
namespace seqan3::detail {
struct method_local_tag : pipeable_config_element {};
} // namespace seqan3::detail
namespace seqan3::align_cfg {
seqan3::detail::method_local_tag method_local;
template
struct scoring_scheme : pipeable_config_element {
scoring_scheme() = default;
constexpr scoring_scheme(scoring_scheme_t) {};
};
struct aminoacid_scoring_scheme {};
template struct alignment_fixture { config_t config; };
template
alignment_fixture(config_t) -> alignment_fixture;
inline constexpr auto align_config =
seqan3::configuration{seqan3::align_cfg::method_local}.push_back(
seqan3::align_cfg::gap{seqan3::gap_scheme{}});
static auto aa27_02 = [] {
return alignment_fixture{align_config.push_back(
seqan3::align_cfg::scoring_scheme{aminoacid_scoring_scheme{}})};
}();
} // namespace seqan3::align_cfg
```
https://godbolt.org/z/M4Mh1f
with
> g++-git -std=c++2a
error:
```
ice.cpp:55:1: internal compiler error: in output_constructor_regular_field, at
varasm.c:5223
55 | } // namespace seqan3::align_cfg
| ^
Please submit a full bug report,
with preprocessed source if appropriate.
See
[Bug target/96854] [10 Regression] avx vectorizer breaks complex arithmetic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96854 --- Comment #4 from Michael_S --- Pay attention that it's not just AVX. '-mavx2 -mfma -Ofast' generates different code, but at the end gives the same wrong result. Unfortunately, I have no AVX512 hardware to test, but wouldn't be surprised if it's also broken in 10.2.
[Bug fortran/96859] Wrong answer with intrinsic merge_bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96859 Dominique d'Humieres changed: What|Removed |Added Last reconfirmed||2020-08-31 Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- What results do you expect?
[Bug libstdc++/96862] -frounding-math -std=c++2a error: '(1.29e+2 * 6.9314718055994529e-1)' is not a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96862 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||ppalka at gcc dot gnu.org, ||redi at gcc dot gnu.org Target Milestone|--- |11.0 --- Comment #1 from Jakub Jelinek --- Using floating point arithmetics for + static constexpr int digits10 + = static_cast(digits * numbers::ln2 / numbers::ln10); seems unsafe, indeed with -frounding-math it can't be evaluated at compile time, as it depends on the rounding mode. Perhaps add a simple constexpr function that will compute this iteratively?
[Bug target/96854] [10 Regression] avx vectorizer breaks complex arithmetic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96854 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Priority|P3 |P2 --- Comment #3 from Richard Biener --- Mine.
[Bug target/96551] [10/11 Regression] FAIL: gcc.target/i386/vectorize8.c (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96551 Hongtao.liu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #6 from Hongtao.liu --- Fixed in GCC11 and backport to GCC10
[Bug target/96551] [10/11 Regression] FAIL: gcc.target/i386/vectorize8.c (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96551 --- Comment #5 from CVS Commits --- The releases/gcc-10 branch has been updated by hongtao Liu : https://gcc.gnu.org/g:2cbd82044b21679fa533445f373374576f638da1 commit r10-8692-g2cbd82044b21679fa533445f373374576f638da1 Author: liuhongt Date: Tue Aug 11 11:05:40 2020 +0800 Refine expander vec_unpacku_float_hi_v16si/vec_unpacku_float_lo_v16si gcc/ PR target/96551 * config/i386/sse.md (vec_unpacku_float_hi_v16si): For vector compare to integer mask, don't use gen_rtx_LT, use ix86_expand_mask_vec_cmp instead. (vec_unpacku_float_hi_v16si): Ditto. gcc/testsuite * gcc.target/i386/avx512f-pr96551-1.c: New test. * gcc.target/i386/avx512f-pr96551-2.c: New test.
[Bug target/96551] [10/11 Regression] FAIL: gcc.target/i386/vectorize8.c (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96551 --- Comment #4 from CVS Commits --- The master branch has been updated by hongtao Liu : https://gcc.gnu.org/g:1aa71af09350b9ff4d2fad88a440b682545682ec commit r11-2947-g1aa71af09350b9ff4d2fad88a440b682545682ec Author: liuhongt Date: Tue Aug 11 11:05:40 2020 +0800 Refine expander vec_unpacku_float_hi_v16si/vec_unpacku_float_lo_v16si gcc/ PR target/96551 * config/i386/sse.md (vec_unpacku_float_hi_v16si): For vector compare to integer mask, don't use gen_rtx_LT, use ix86_expand_mask_vec_cmp instead. (vec_unpacku_float_hi_v16si): Ditto. gcc/testsuite * gcc.target/i386/avx512f-pr96551-1.c: New test. * gcc.target/i386/avx512f-pr96551-2.c: New test.
[Bug libstdc++/96862] New: -frounding-math -std=c++2a error: '(1.29e+2 * 6.9314718055994529e-1)' is not a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96862 Bug ID: 96862 Summary: -frounding-math -std=c++2a error: '(1.29e+2 * 6.9314718055994529e-1)' is not a constant expression Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: Laurent.Rineau__gcc at normalesup dot org Target Milestone: --- Commit e6c76f0d3327bf00c96f5a63961c1d5ab77512db introduced a compilation error with `-frounding-math -std=c++2a`: it seems that, with `-frounding-math` a floating-point expression cannot be constexpr. # cat test.cpp #include # g++ --version g++ (GCC) 11.0.0 20200828 (experimental) Copyright (C) 2020 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. # g++ -std=c++2a -frounding-math test.cpp In file included from /usr/local/include/c++/11.0.0/bits/range_access.h:40, from /usr/local/include/c++/11.0.0/string:54, from test.cpp:1: /usr/local/include/c++/11.0.0/bits/max_size_type.h:708:35: error: '(1.29e+2 * 6.9314718055994529e-1)' is not a constant expression 708 | = static_cast(digits * numbers::ln2 / numbers::ln10); |~~~^~ /usr/local/include/c++/11.0.0/bits/max_size_type.h:734:50: error: '(8.8722839111672997e+1 / 2.3025850929940459e+0)' is not a constant expression 734 | = static_cast(digits * numbers::ln2 / numbers::ln10); |~~^~~
[Bug target/96854] [10 Regression] avx vectorizer breaks complex arithmetic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96854
Jakub Jelinek changed:
What|Removed |Added
Keywords|needs-bisection |
CC||jakub at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek ---
double _Complex __attribute__((noipa))
foo (double _Complex acc, const double _Complex *x, const double _Complex* y,
int N)
{
for (int c = 0; c < N; ++c)
acc -= x[c] * y[c];
return acc;
}
int
main()
{
static const double _Complex y[] = { 1, 2, };
static const double _Complex x[] = { 1, 3, };
double _Complex ref = foo (0, x, y, 2);
if (__builtin_creal (ref) != -7.)
__builtin_abort ();
return 0;
}
Started with r10-3252-g901083b9bdf69a7b1382f9682c6fd1d5759667dd
stopped with r11-1501-gda2b7c7f0a136b4d00520a08d4c443fc2e3a467d
The result it compiles when miscompiled is 7., so it is not just some ulp
difference in the computation.
[Bug target/96861] New: Integer min/max optimization failed under -march=skylake-avx512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96861
Bug ID: 96861
Summary: Integer min/max optimization failed under
-march=skylake-avx512
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: crazylht at gmail dot com
CC: hjl.tools at gmail dot com
Target Milestone: ---
Target: i386, x86-64
cat minmax-10.c
---
#define max(a,b) (((a) > (b))) ? (a) : (b)
#define min(a,b) (((a) < (b))) ? (a) : (b)
int smax1(int x)
{
return max(x,1);
}
---
gcc -O2 -march=skylake-avx512 -S
---
smax1(int):
vmovdqa xmm1, XMMWORD PTR .LC0[rip]
vmovd xmm0, edi
vpmaxsd xmm0, xmm0, xmm1
vmovd eax, xmm0
ret
---
gcc -O2 -march=x86-64 -S
---
smax1(int):
testedi, edi
mov eax, 1
cmovg eax, edi
ret
---
It seems cost model need to be adjusted for skylake_cost.
[Bug middle-end/44612] -flto -fwhole-program: Never read variable not optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44612 --- Comment #8 from Tobias Burnus --- For what it is worth, still occurs with on mainline (GCC 11). (In reply to Richard Biener from comment #6) > Confirmed. > > DSE doesn't remove memset or memcpy calls. > > We also do not have a flag to mark functions only clobbering local or > incoming memory (thus effectively not have side-effects if the argument > reachable memory is unused after a call). (In reply to Jakub Jelinek from comment #7) > Well, RTL DSE to some extent knows about memset. > And, for tree DSE handling it would be much easier and desirable.
[Bug target/96791] ICE in convert_mode_scalar, at expr.c:412
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96791
--- Comment #6 from Arseny Solokha ---
There's also a seemingly related case where gcc ICES in branch
if (GET_MODE_CLASS (to_mode) == MODE_PARTIAL_INT)
instead.
The following testcase is reduced from
gcc/testsuite/gcc.target/powerpc/pr96125.c:
void __attribute__ ((target ("cpu=power10")))
le (__vector_quad *ql)
{
__vector_quad hg;
__builtin_mma_xxsetaccz ();
*ql = hg;
}
% powerpc-e300c3-linux-gnu-gcc-11.0.0 -c ihgsd1rx.c
during RTL pass: expand
ihgsd1rx.c: In function 'le':
ihgsd1rx.c:7:7: internal compiler error: in convert_mode_scalar, at expr.c:394
7 | *ql = hg;
| ^~~~
0x5ef679 convert_mode_scalar
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200830/work/gcc-11-20200830/gcc/expr.c:394
0xa2f11b convert_modes(machine_mode, machine_mode, rtx_def*, int)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200830/work/gcc-11-20200830/gcc/expr.c:737
0xa0ea12 extract_integral_bit_field
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200830/work/gcc-11-20200830/gcc/expmed.c:1961
0xa0ea12 extract_bit_field_1
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200830/work/gcc-11-20200830/gcc/expmed.c:1846
0xa0f0b2 extract_bit_field(rtx_def*, poly_int<1u, unsigned long>, poly_int<1u,
unsigned long>, int, rtx_def*, machine_mode, machine_mode, bool, rtx_def**)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200830/work/gcc-11-20200830/gcc/expmed.c:2118
0xa19b88 expand_misaligned_mem_ref
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200830/work/gcc-11-20200830/gcc/expr.c:8620
0xa284cf expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200830/work/gcc-11-20200830/gcc/expr.c:10517
0xa34c1b store_expr(tree_node*, rtx_def*, int, bool, bool)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200830/work/gcc-11-20200830/gcc/expr.c:5858
0xa36f21 expand_assignment(tree_node*, tree_node*, bool)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200830/work/gcc-11-20200830/gcc/expr.c:5594
0x90062f expand_gimple_stmt_1
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200830/work/gcc-11-20200830/gcc/cfgexpand.c:3749
0x90062f expand_gimple_stmt
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200830/work/gcc-11-20200830/gcc/cfgexpand.c:3847
0x90655a expand_gimple_basic_block
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200830/work/gcc-11-20200830/gcc/cfgexpand.c:5888
0x90814f execute
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200830/work/gcc-11-20200830/gcc/cfgexpand.c:6572
And compiling w/ -O1 yields the following instead:
% powerpc-e300c3-linux-gnu-gcc-11.0.0 -O1 -c ihgsd1rx.c
ihgsd1rx.c: In function 'le':
ihgsd1rx.c:8:1: error: insn does not satisfy its constraints:
8 | }
| ^
(insn 53 52 54 2 (set (mem/c:POI (plus:SI (reg/f:SI 1 1)
(const_int 16 [0x10])) [3 %sfp+-80 S32 A128])
(reg:POI 32 0 [ _1 ])) 2190 {*movpoi}
(nil))
during RTL pass: pro_and_epilogue
ihgsd1rx.c:8:1: internal compiler error: in extract_constrain_insn, at
recog.c:2195
0x65b80d _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200830/work/gcc-11-20200830/gcc/rtl-error.c:108
0x65b839 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200830/work/gcc-11-20200830/gcc/rtl-error.c:118
0x659e71 extract_constrain_insn(rtx_insn*)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200830/work/gcc-11-20200830/gcc/recog.c:2195
0xcf731c copyprop_hardreg_forward_1
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200830/work/gcc-11-20200830/gcc/regcprop.c:802
0xcf8101 copyprop_hardreg_forward_bb_without_debug_insn(basic_block_def*)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200830/work/gcc-11-20200830/gcc/regcprop.c:1181
0xd56f3d prepare_shrink_wrap
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200830/work/gcc-11-20200830/gcc/shrink-wrap.c:451
0xd56f3d try_shrink_wrapping(edge_def**, rtx_insn*)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200830/work/gcc-11-20200830/gcc/shrink-wrap.c:674
0xa92dc0 thread_prologue_and_epilogue_insns()
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200830/work/gcc-11-20200830/gcc/function.c:5909
0xa934c6 rest_of_handle_thread_prologue_and_epilogue
[Bug middle-end/31892] optimization: Loop not optimized away because of static
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31892 Tobias Burnus changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Tobias Burnus --- In the meanwhile FIXED: Now also fast with GCC 7 + -O1 (and with -O2 all traces of the array are removed).
[Bug analyzer/96860] New: [11 Regression] ICE in apply_ctor_to_region, at analyzer/store.cc:445
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96860
Bug ID: 96860
Summary: [11 Regression] ICE in apply_ctor_to_region, at
analyzer/store.cc:445
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
Target: x86_64-pc-linux-gnu
gcc-11.0.0-alpha20200830 snapshot (g:6ccadc4c0486ff011a32c74de1a31148acb3cbe2)
ICEs when compiling the following testcase, reduced from
gcc/testsuite/gcc.c-torture/execute/pr89634.c, w/ -fanalyzer --param
analyzer-max-svalue-depth=0:
void
x7 (void)
{
__int128 z5[] = {
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 1, 0, 1, 0, 1,
};
}
% x86_64-pc-linux-gnu-gcc-11.0.0 -fanalyzer --param analyzer-max-svalue-depth=0
-c z2ncgwrg.c
during IPA pass: analyzer
z2ncgwrg.c: In function 'x7':
z2ncgwrg.c:4:12: internal compiler error: in apply_ctor_to_region, at
analyzer/store.cc:445
4 | __int128 z5[] = {
|^~
0x7244b1 ana::binding_map::apply_ctor_to_region(ana::region const*, tree_node*,
ana::region_model_manager*)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200830/work/gcc-11-20200830/gcc/analyzer/store.cc:445
0x110cea4 ana::decl_region::get_svalue_for_constructor(tree_node*,
ana::region_model_manager*) const
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200830/work/gcc-11-20200830/gcc/analyzer/region.cc:907
0xdb4 ana::region_model::get_store_value(ana::region const*) const
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200830/work/gcc-11-20200830/gcc/analyzer/region-model.cc:1284
0x1113c6a ana::region_model::get_rvalue(tree_node*, ana::region_model_context*)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200830/work/gcc-11-20200830/gcc/analyzer/region-model.cc:1190
0x1116727 ana::region_model::on_assignment(gassign const*,
ana::region_model_context*)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200830/work/gcc-11-20200830/gcc/analyzer/region-model.cc:562
0x10f7532 ana::exploded_node::on_stmt(ana::exploded_graph&, ana::supernode
const*, gimple const*, ana::program_state*) const
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200830/work/gcc-11-20200830/gcc/analyzer/engine.cc:1029
0x10f877d ana::exploded_graph::process_node(ana::exploded_node*)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200830/work/gcc-11-20200830/gcc/analyzer/engine.cc:2526
0x10f926a ana::exploded_graph::process_worklist()
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200830/work/gcc-11-20200830/gcc/analyzer/engine.cc:2341
0x10fb39f ana::impl_run_checkers(ana::logger*)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200830/work/gcc-11-20200830/gcc/analyzer/engine.cc:4107
0x10fbfbc ana::run_checkers()
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200830/work/gcc-11-20200830/gcc/analyzer/engine.cc:4175
0x10f0978 execute
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200830/work/gcc-11-20200830/gcc/analyzer/analyzer-pass.cc:84
It's also possible to trigger this ICE w/ -m32 when one replaces __int128 w/
long int in z5 declaration.
[Bug ipa/96806] ICE: in good_cloning_opportunity_p, at ipa-cp.c:3235 with -O -fipa-cp -fipa-cp-clone --param=ipa-cp-max-recursive-depth=94 --param=logical-op-non-short-circuit=0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96806 --- Comment #2 from CVS Commits --- The master branch has been updated by Feng Xue : https://gcc.gnu.org/g:e11c4b7f837bc6b4c22b1f5bf41a9d0608d256be commit r11-2945-ge11c4b7f837bc6b4c22b1f5bf41a9d0608d256be Author: Feng Xue Date: Mon Aug 31 15:00:52 2020 +0800 ipa/96806 - Fix ICE in ipa-cp due to integer addition overflow 2020-08-31 Feng Xue gcc/ PR tree-optimization/96806 * ipa-cp.c (decide_about_value): Use safe_add to avoid cost addition overflow. gcc/testsuite/ PR tree-optimization/96806 * g++.dg/ipa/pr96806.C: New test.
[Bug middle-end/54201] XMM constant duplicated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54201
--- Comment #10 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:0106300f6c3f7bae5eb1c46dbd45aa07c94e1b15
commit r11-2944-g0106300f6c3f7bae5eb1c46dbd45aa07c94e1b15
Author: Jakub Jelinek
Date: Mon Aug 31 10:27:00 2020 +0200
varasm: Optimize memory broadcast for constant vector under AVX512
[PR54201]
I meant something like the following, which on e.g. a dumb:
typedef float V __attribute__((vector_size (4 * sizeof (float;
void
foo (V *p, float *q)
{
p[0] += (V) { 1.0f, 2.0f, 3.0f, 4.0f };
q[0] += 4.0f;
q[1] -= 3.0f;
q[17] -= 2.0f;
q[31] += 1.0f;
}
testcase merges all the 4 scalar constant pool entries into the
CONST_VECTOR
one.
I'm punting for section anchors and not doing it in the per-function (i.e.
non-shared) constant pools simply because I don't know them well enough,
don't know whether backends use the offsets for something etc.
For section anchors, I guess it would need to be done before (re)computing
the
offsets and arrange for the desc->mark < 0 entries not to be considered as
objects in the object block, for non-shared pools, perhaps it would be
enough to call the new function from output_constant_pool before calling
recompute_pool_offsets and adjust recompute_pool_offsets to ignore
desc->mark < 0.
Here is an adjusted patch that ought to merge even the same sized different
mode vectors with the same byte representation, etc.
It won't really help with avoiding the multiple reads of the constant in
the
same function, but as you found, your patch doesn't help with that either.
Your patch isn't really incompatible with what the patch below does, though
I wonder whether a) it wouldn't be better to always canonicalize to an
integral mode with as few elts as possible even e.g. for floats b) whether
asserting that it simplify_rtx succeeds is safe, whether it shouldn't just
canonicalize if the canonicalization works and just do what it previously
did otherwise.
The following patch puts all pool entries which can be natively encoded
into a vector, sorts it by decreasing size, determines minimum size
of a pool entry and adds hash elts for each (aligned) min_size or wider
power of two-ish portion of the pool constant in addition to the whole pool
constant byte representation.
This is the version that passed bootstrap/regtest on both x86_64-linux and
i686-linux. In both bootstraps/regtests together, it saved (from the
statistics I've gathered) 63104 .rodata bytes (before constant merging),
in 6814 hits of the data->desc->mark = ~(*slot)->desc->labelno;.
2020-08-31 Jakub Jelinek
PR middle-end/54201
* varasm.c: Include alloc-pool.h.
(output_constant_pool_contents): Emit desc->mark < 0 entries as
aliases.
(struct constant_descriptor_rtx_data): New type.
(constant_descriptor_rtx_data_cmp): New function.
(struct const_rtx_data_hasher): New type.
(const_rtx_data_hasher::hash, const_rtx_data_hasher::equal): New
methods.
(optimize_constant_pool): New function.
(output_shared_constant_pool): Call it if TARGET_SUPPORTS_ALIASES.
[Bug c/96810] This is a case that gcc shoud not compile successfully, but gcc acts opposite.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96810
--- Comment #4 from Wei Wentao ---
>>--- Comment #3 from Jakub Jelinek ---
>>Actually sorry, the diagnostics clang emits is not about the bug mentioned in
>>the testcase, but about something different.
>>And while the bug described in the comment is really hard to diagnose at
>>compile time and in most cases impossible, what clang diagnoses is the fact
>>that
>>the target construct has implicit map(tofrom:A) clause and because the target
>>data maps only a small part of it, it mapping in target construct will fail.
>>Still, clang implements it incorrectly, it e.g. rejects:
>>int A[30];
>>void
>>foo (void)
>>{
>> #pragma omp target data map (A[0:4])
>> #pragma omp target
>> A[2] = 0;
>>}
>>int
>>main ()
>>{
>> #pragma omp target data map (A)
>> foo ();
>> return 0;
>>}
>>or
>>void bar (int *, int);
>>void
>>foo (void)
>>{
>> int A[30];
>> bar (A, 0);
>> #pragma omp target data map (A[0:4])
>> #pragma omp target
>> A[2] = 0;
>> bar (A, 1);
>>}
>>Both are completely valid and e.g. the latter could work just fine at runtime
>>if bar performs #pragma omp target enter data (arg1[:30]) for arg2 0 and exit
>>data for arg2 non-zero.
>>Perhaps a warning might be ok, but it still can have many false positives
>>(unless the compiler can prove that the array can't be mapped before the outer
>>target data).
