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).