public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/99281] New: internal compiler error: in assign_temp, at function.c:984
@ 2021-02-26 4:34 jonathan.poelen at gmail dot com
2021-02-26 7:38 ` [Bug c++/99281] " rguenth at gcc dot gnu.org
` (4 more replies)
0 siblings, 5 replies; 6+ messages in thread
From: jonathan.poelen at gmail dot com @ 2021-02-26 4:34 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99281
Bug ID: 99281
Summary: internal compiler error: in assign_temp, at
function.c:984
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jonathan.poelen at gmail dot com
Target Milestone: ---
g++ -std=c++17 test.cpp
during RTL pass: expand
test.cpp: In function ‘int main()’:
test.cpp:27:5: internal compiler error: in assign_temp, at function.c:984
27 | pack_type<X>{get(1)};
| ^~~~~~~~~~~~~~~~~~~~
Compile with -O1 or higher.
struct Data
{
Data() {}
~Data() {}
long long i;
};
struct X
{
Data a;
int b;
};
template<class T>
X get(T const&)
{
return X{};
}
template<class... Ts>
struct pack_type : Ts...
{};
int main()
{
pack_type<X>{get(1)};
}
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug c++/99281] internal compiler error: in assign_temp, at function.c:984
2021-02-26 4:34 [Bug c++/99281] New: internal compiler error: in assign_temp, at function.c:984 jonathan.poelen at gmail dot com
@ 2021-02-26 7:38 ` rguenth at gcc dot gnu.org
2021-02-26 8:51 ` rguenth at gcc dot gnu.org
` (3 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-02-26 7:38 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99281
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |ice-on-valid-code
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Last reconfirmed| |2021-02-26
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed. We're building a temporary of type X which we shouldn't do when
expanding
get<int> (&D.2164) [return slot optimization]
and we run into
#2 0x0000000000fd165a in expand_call (exp=<call_expr 0x7ffff66ed818>,
target=0x0, ignore=0) at /home/rguenther/src/gcc3/gcc/calls.c:3878
3873 else
3874 {
3875 /* For variable-sized objects, we must be called with a
target
3876 specified. If we were to allocate space on the stack
here,
3877 we would have no way of knowing when to free it. */
3878 rtx d = assign_temp (rettype, 1, 1);
3879 structure_value_addr = XEXP (d, 0);
3880 target = 0;
because target is NULL when we come via
#7 0x0000000001197afe in expand_assignment (to=<component_ref 0x7ffff66d9390>,
from=<call_expr 0x7ffff66ed818>,
nontemporal=false) at /home/rguenther/src/gcc3/gcc/expr.c:5482
5481 else
5482 result = store_field (to_rtx, bitsize, bitpos,
5483 bitregion_start, bitregion_end,
5484 mode1, from, get_alias_set (to),
5485 nontemporal, reversep);
and the large conditional on
/* If the structure is in a register or if the component
is a bit field, we cannot use addressing to access it.
Use bit-field techniques or SUBREG to store in it. */
somehow misfires on this, specifically there is
/* And except for bitwise copying of TREE_ADDRESSABLE types,
where the FIELD_DECL has the right bitsize, but TREE_TYPE (exp)
includes some extra padding. store_expr / expand_expr will in
that case call get_inner_reference that will have the bitsize
we check here and thus the block move will not clobber the
padding that shouldn't be clobbered. In the future we could
replace the TREE_ADDRESSABLE check with a check that
get_base_address needs to live in memory. */
&& (!TREE_ADDRESSABLE (TREE_TYPE (exp))
|| TREE_CODE (exp) != COMPONENT_REF
|| !multiple_p (bitsize, BITS_PER_UNIT)
|| !multiple_p (bitpos, BITS_PER_UNIT)
|| !poly_int_tree_p (DECL_SIZE (TREE_OPERAND (exp, 1)),
&decl_bitsize)
|| maybe_ne (decl_bitsize, bitsize)))
maybe sth as simple as the following works (instead of for return-slot-opt
we can also test !TREE_ADDRESSABLE here or boht for the testcase)
diff --git a/gcc/expr.c b/gcc/expr.c
index 86dc1b6c973..54007ac0efe 100644
--- a/gcc/expr.c
+++ b/gcc/expr.c
@@ -7214,7 +7214,10 @@ store_field (rtx target, poly_int64 bitsize, poly_int64
bitpos,
|| !multiple_p (bitpos, BITS_PER_UNIT)
|| !poly_int_tree_p (DECL_SIZE (TREE_OPERAND (exp, 1)),
&decl_bitsize)
- || maybe_ne (decl_bitsize, bitsize)))
+ || maybe_ne (decl_bitsize, bitsize))
+ /* A call with return-slot-opt must not need bitfield operations. */
+ && (TREE_CODE (exp) != CALL_EXPR
+ || !CALL_EXPR_RETURN_SLOT_OPT (exp)))
/* If we are expanding a MEM_REF of a non-BLKmode non-addressable
decl we must use bitfield operations. */
|| (known_size_p (bitsize)
note clang warns
t.ii:27:5: warning: expression result unused [-Wunused-value]
pack_type<X>{get(1)};
^ ~~~~~~~~
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug c++/99281] internal compiler error: in assign_temp, at function.c:984
2021-02-26 4:34 [Bug c++/99281] New: internal compiler error: in assign_temp, at function.c:984 jonathan.poelen at gmail dot com
2021-02-26 7:38 ` [Bug c++/99281] " rguenth at gcc dot gnu.org
@ 2021-02-26 8:51 ` rguenth at gcc dot gnu.org
2021-02-26 11:34 ` cvs-commit at gcc dot gnu.org
` (2 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-02-26 8:51 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99281
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org
Status|NEW |ASSIGNED
--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
Posted a patch.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug c++/99281] internal compiler error: in assign_temp, at function.c:984
2021-02-26 4:34 [Bug c++/99281] New: internal compiler error: in assign_temp, at function.c:984 jonathan.poelen at gmail dot com
2021-02-26 7:38 ` [Bug c++/99281] " rguenth at gcc dot gnu.org
2021-02-26 8:51 ` rguenth at gcc dot gnu.org
@ 2021-02-26 11:34 ` cvs-commit at gcc dot gnu.org
2021-02-26 11:38 ` rguenth at gcc dot gnu.org
2024-04-05 23:01 ` pinskia at gcc dot gnu.org
4 siblings, 0 replies; 6+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-02-26 11:34 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99281
--- Comment #3 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Richard Biener <rguenth@gcc.gnu.org>:
https://gcc.gnu.org/g:c173346aac4a66ad3747f380f2f0c97d2dbf8973
commit r11-7420-gc173346aac4a66ad3747f380f2f0c97d2dbf8973
Author: Richard Biener <rguenther@suse.de>
Date: Fri Feb 26 08:45:36 2021 +0100
middle-end/99281 - avoid bitfield stores into addressable types
This avoids doing bitfield stores into the return object of calls
when using return-slot optimization and the type is addressable.
Instead we have to pass down the original target RTX to the call
expansion which otherwise tries to create a new temporary.
2021-02-26 Richard Biener <rguenther@suse.de>
PR middle-end/99281
* expr.c (store_field): For calls with return-slot optimization
and addressable return type expand the store directly.
* g++.dg/pr99218.C: New testcase.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug c++/99281] internal compiler error: in assign_temp, at function.c:984
2021-02-26 4:34 [Bug c++/99281] New: internal compiler error: in assign_temp, at function.c:984 jonathan.poelen at gmail dot com
` (2 preceding siblings ...)
2021-02-26 11:34 ` cvs-commit at gcc dot gnu.org
@ 2021-02-26 11:38 ` rguenth at gcc dot gnu.org
2024-04-05 23:01 ` pinskia at gcc dot gnu.org
4 siblings, 0 replies; 6+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-02-26 11:38 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99281
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Known to work| |11.0
Known to fail|11.0 |
--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed on trunk, it's not a regression, the testcase is still rejected by GCC
6.5
and it ICEs with 7.1.0 already (at -O0). I'm still leaving this open for
eventual backporting to at least GCC 10 where it was reported against.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug c++/99281] internal compiler error: in assign_temp, at function.c:984
2021-02-26 4:34 [Bug c++/99281] New: internal compiler error: in assign_temp, at function.c:984 jonathan.poelen at gmail dot com
` (3 preceding siblings ...)
2021-02-26 11:38 ` rguenth at gcc dot gnu.org
@ 2024-04-05 23:01 ` pinskia at gcc dot gnu.org
4 siblings, 0 replies; 6+ messages in thread
From: pinskia at gcc dot gnu.org @ 2024-04-05 23:01 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99281
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution|--- |FIXED
Target Milestone|--- |11.0
--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
GCC 10.x has long been closed for new patches so closing as fixed for GCC 11.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2024-04-05 23:01 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-02-26 4:34 [Bug c++/99281] New: internal compiler error: in assign_temp, at function.c:984 jonathan.poelen at gmail dot com
2021-02-26 7:38 ` [Bug c++/99281] " rguenth at gcc dot gnu.org
2021-02-26 8:51 ` rguenth at gcc dot gnu.org
2021-02-26 11:34 ` cvs-commit at gcc dot gnu.org
2021-02-26 11:38 ` rguenth at gcc dot gnu.org
2024-04-05 23:01 ` pinskia at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).