https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123692
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 63426
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=63426&action=edit
gcc16-pr123692.patch
The problem is in the moving of resolves_to_fixed_type_p call earlier. In this
case, expr is CALL_EXPR with class type on which fixed_type_or_null ICEs
because it wants to point out to some forgotten build_cplus_new. The reason
this worked
before was that when the call was later on, after cp_build_addr_expr,
cp_build_addr_expr -> unary_complex_lvalue -> build_cplus_new wraps it in a
TARGET_EXPR and resolves_to_fixed_type_p was called only after that.
Now, for the uneval case we actually never need the fixed_type_p,
virtual_access nor nonnull values, so if such problematic arguments can appear
only in the uneval cases, I think we can as well not to call
resolves_to_fixed_type_p at all in that case.
