https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120308
Thomas Schwinge <tschwinge at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|unassigned at gcc dot gnu.org |tschwinge at gcc dot
gnu.org
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0 |1
Last reconfirmed| |2025-05-16
--- Comment #2 from Thomas Schwinge <tschwinge at gcc dot gnu.org> ---
Created attachment 61442
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61442&action=edit
'0001-TYPE_EMPTY_P-vs.-code-offloading-PR120308.patch'
(In reply to Richard Biener from comment #1)
> It looks like TYPE_EMPTY_P is only used during RTL expansion for ABI
> purposes, so computing it during layout_type is premature as shown here.
Thanks for confirming what I suspected/hoped.
> I would suggest to simply re-compute it at offload stream-in time.
I'm testing the patch that I'm attaching here. Does that look alright? Do I
understand correctly that (per (non-)handling of other similar cases) I do
*not* conditionalize 'compare_values (TYPE_EMPTY_P);' in
'gcc/lto/lto-common.cc:compare_tree_sccs_1'?
> Design-wise we might want to replace all TYPE_EMPTY_P uses with a call
> to the target hook or instead make it tri-state and maintain only a cache
> in the tree node
ACK, noted for further improvement, later on.
> and make sure that cache isn't populated until after
> LTO stream-in.
ACK. I wish that we generally were more explicit about which information in
GCC data structures is valid at which stage during compilation.
