https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360
--- Comment #30 from anlauf at gcc dot gnu.org ---
(In reply to David Edelsohn from comment #29)
> Maybe something about the way that GFORTRAN is passing the string by value.
> 257.optimized shows
>
> val (&"B"[1]{lb: 1 sz: 1}, "B", 1, 1);
> val (&"A"[1]{lb: 1 sz: 1}, "A", 1, 1);
> val (&"A"[1]{lb: 1 sz: 1}, 65, 1, 1);
> val (&"A"[1]{lb: 1 sz: 1}, 65, 1, 1);
> val (&"A"[1]{lb: 1 sz: 1}, 65, 1, 1);
> _37 = c[1]{lb: 1 sz: 1};
> val (&"1"[1]{lb: 1 sz: 1}, _37, 1, 1);
> _38 = c[1]{lb: 1 sz: 1};
> val (&"1"[1]{lb: 1 sz: 1}, _38, 1, 1);
>
> &"B"[1] is not shifted. 65 is not shifted. "B" is shifted.
>
> GFORTRAN is passing the value in different ways that trigger different parts
> of the target ABI. It seems to be assuming that those different parts of
> the ABI and forms of parameter passing will produce the same results in
> terms of padding, but that is not guaranteed.
Is it possible that a VIEW_CONVERT_EXPR is needed for handling this, and
that this is forgotten or wrong for one of those variants?
There exists native_encode_expr, which appears to handle constant exprs,
and which might pass "B" to native_encode_string, and we need to emulate
this conversion for non-constant char expressions. (Just guessing.)
That &"B"[1] is not shifted is not surprising: we are passing this argument
by reference, not value.
