https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123948
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Last reconfirmed| |2026-02-03
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Known to fail| |11.5.0, 16.0
Keywords| |ice-checking
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed.
- b = __VIEW_CONVERT <struct y>(D_4772);
- _2 = b.x;
+ _4 = D_4772;
+ _17 = __VIEW_CONVERT <integer(kind=4)>(_4);
+ b$x_6 = _17;
+ _2 = b$x_6;
fails already with GCC 11, didn't check earlier. Built here:
static enum assignment_mod_result
sra_modify_assign (gimple *stmt, gimple_stmt_iterator *gsi)
{
...
4761 rhs = fold_build1_loc (loc, VIEW_CONVERT_EXPR, TREE_TYPE
(lhs), rhs);
the issue is that rhs is VIEW_CONVERT_EXPR <struct Y> (DImode) and
the LHS type is SImode. While the former is valid, match.pd transforms
V_C_E <T'> (V_C_E <T> (x)) to V_C_E <T'> (x) which is invalid here.
The original V_C_E to aggregate of smaller size is questionable, but we
do not reject it in IL verification (for "reasons").
The original V_C_E is created by the fronted from gfc_trans_scalar_assign:
11761 else if (gfc_bt_struct (ts.type))
11762 {
11763 gfc_add_block_to_block (&block, &rse->pre);
11764 gfc_add_block_to_block (&block, &lse->finalblock);
11765 gfc_add_block_to_block (&block, &lse->pre);
11766 tmp = fold_build1_loc (input_location, VIEW_CONVERT_EXPR,
11767 TREE_TYPE (lse->expr), rse->expr);
where rse->expr is a call, p (), which has strange type, pointer-to-function
instead of the call result typoe (struct Y). The call is built in
gfc_conv_procedure_call which I think shows the function type is wrong:
(gdb) p debug_tree (fntype)
<function_type 0x7ffff6629c78
type <pointer_type 0x7ffff6629150
type <function_type 0x7ffff6629f18 type <record_type 0x7ffff66225e8 y>
QI
size <integer_cst 0x7ffff6802eb8 constant 8>
unit-size <integer_cst 0x7ffff6802ed0 constant 1>
align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7ffff6629e70
so this is a frontend issue that exposes a match.pd or IL verification
issue (we should have rejected this earlier, as generated by the frontend).
