[Bug c++/90254] [8/9/10 Regression] ice on aggregate initialization of unmovable base
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90254 Bug 90254 depends on bug 98642, which changed state. Bug 98642 Summary: [10 Regression] wrong "use of deleted function" error https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98642 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/90254] [8/9/10 Regression] ice on aggregate initialization of unmovable base
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90254 --- Comment #8 from CVS Commits --- The releases/gcc-10 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:97014e4ada448aa8978b3cd14ed95e0e56f375d9 commit r10-9168-g97014e4ada448aa8978b3cd14ed95e0e56f375d9 Author: Jason Merrill Date: Wed Aug 12 05:45:02 2020 -0400 c++: Copy elision and [[no_unique_address]]. [PR93711] We don't elide a copy from a function returning a class by value into a base because that can overwrite data laid out in the tail padding of the base class; we need to handle [[no_unique_address]] fields the same way, or we ICE when the middle-end wants to create a temporary object of a TYPE_NEEDS_CONSTRUCTING type. This means that we can't always express initialization of a field with INIT_EXPR from a TARGET_EXPR the way we usually do, so I needed to change several places that were assuming that was sufficient. This also fixes 90254, the same problem with C++17 aggregate initialization of a base. gcc/cp/ChangeLog: PR c++/90254 PR c++/93711 * cp-tree.h (unsafe_return_slot_p): Declare. * call.c (is_base_field_ref): Rename to unsafe_return_slot_p. (build_over_call): Check unsafe_return_slot_p. (build_special_member_call): Likewise. * init.c (expand_default_init): Likewise. * typeck2.c (split_nonconstant_init_1): Likewise. gcc/testsuite/ChangeLog: PR c++/90254 PR c++/93711 * g++.dg/cpp1z/aggr-base10.C: New test. * g++.dg/cpp2a/no_unique_address7.C: New test. * g++.dg/cpp2a/no_unique_address7a.C: New test.
[Bug c++/90254] [8/9/10 Regression] ice on aggregate initialization of unmovable base
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90254 Jason Merrill changed: What|Removed |Added Summary|[8/9/10/11 Regression] ice |[8/9/10 Regression] ice on |on aggregate initialization |aggregate initialization of |of unmovable base |unmovable base --- Comment #7 from Jason Merrill --- The patch fixes the testcase from comment #4 for GCC 11. I agree with the clang response that the original testcase is ill-formed, and will continue to be rejected. The testcase in comment #3 is still broken due to PR 66139.
[Bug c++/90254] [8/9/10 Regression] ice on aggregate initialization of unmovable base
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90254 Marek Polacek changed: What|Removed |Added Keywords||ice-on-valid-code Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug c++/90254] [8/9/10 Regression] ice on aggregate initialization of unmovable base
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90254
Nicholas Krause changed:
What|Removed |Added
CC||xerofoify at gmail dot com
--- Comment #5 from Nicholas Krause ---
Seems to be regressing due to missing a check for another constructor type in
type_has_nontrivial_copy_init or somewhere up the stack.Both the other two in
the last reported case are fine. Therefore I'm assuming is not be found as a
trivial move or copy constructor somewhere and this looks to the compiler like
a different constructor type:
B b{foo()};
Seems to be a trivial constructor to me but the compiler seems to be ICEing
because its not or detected as such and therefore is not correctly building
special temp member functions. The original patch seems to causing some issue
in this way.
[Bug c++/90254] [8/9/10 Regression] ice on aggregate initialization of unmovable base
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90254
--- Comment #4 from Marek Polacek ---
But this one is accepted by icc/clang++ yet we ICE:
struct A {
A();
A(const A &);
};
struct B : A { };
A foo ();
int
main ()
{
B b{foo()};
}
[Bug c++/90254] [8/9/10 Regression] ice on aggregate initialization of unmovable base
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90254
--- Comment #3 from Marek Polacek ---
This reduced test actually regressed with r241187:
struct A {
A(A &);
};
struct B : A { };
A foo ();
int
main ()
{
B{foo()};
}
$ ./cc1plus -quiet x.C -std=c++17
during RTL pass: expand
x.C: In function ‘int main()’:
x.C:11:3: internal compiler error: in assign_temp, at function.c:984
11 | B{foo()};
| ^~~~
0x105cdf1 assign_temp(tree_node*, int, int)
/home/mpolacek/src/gcc/gcc/function.c:984
0xdf123d expand_call(tree_node*, rtx_def*, int)
/home/mpolacek/src/gcc/gcc/calls.c:3825
0xfe98d5 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/home/mpolacek/src/gcc/gcc/expr.c:11135
0xfdc3d9 expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier,
rtx_def**, bool)
/home/mpolacek/src/gcc/gcc/expr.c:8358
0xfbb233 expand_normal
/home/mpolacek/src/gcc/gcc/expr.h:288
0xfd7588 store_field
/home/mpolacek/src/gcc/gcc/expr.c:7102
0xfcf3c6 expand_assignment(tree_node*, tree_node*, bool)
/home/mpolacek/src/gcc/gcc/expr.c:5374
0xe12534 expand_call_stmt
/home/mpolacek/src/gcc/gcc/cfgexpand.c:2701
0xe15cab expand_gimple_stmt_1
/home/mpolacek/src/gcc/gcc/cfgexpand.c:3682
0xe1634a expand_gimple_stmt
/home/mpolacek/src/gcc/gcc/cfgexpand.c:3847
0xe1e4f9 expand_gimple_basic_block
/home/mpolacek/src/gcc/gcc/cfgexpand.c:5887
0xe2013b execute
/home/mpolacek/src/gcc/gcc/cfgexpand.c:6542
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug c++/90254] [8/9/10 Regression] ice on aggregate initialization of unmovable base
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90254 Jakub Jelinek changed: What|Removed |Added Target Milestone|8.4 |8.5 --- Comment #2 from Jakub Jelinek --- GCC 8.4.0 has been released, adjusting target milestone.
