https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360
--- Comment #6 from anlauf at gcc dot gnu.org ---
(In reply to Mikael Morin from comment #4)
> (In reply to anlauf from comment #0)
> > but the second line contains junk, as the tree-dump shows:
> >
> > static void val (character(kind=1)[1:1], integer(kind=8));
> > static integer(kind=4) a = 65;
> >
> > val ("A", 1);
> > {
> > character(kind=1) char.1;
> >
> > char.1 = (character(kind=1)) a;
> > val (&char.1, 1);
> > }
> >
> > Clearly, the second case is inconsistent with the ABI, see the prototype,
> > and
> >
> Yes, but it's not worse than the first one: "A" is a pointer, not a value.
> I would say that it is the middle-end that is inconsistent here.
Hmm. Have a look at the following:
subroutine s
implicit none
interface
subroutine val (c)
character, value :: c
end
end interface
call val ("A")
call val ("ABCDEF")
end
Dump-tree:
val ("A", 1);
val ("ABCDEF", 6);
I am not good at reading assembler, but it appears that "ABCDEF" is
awfully copied (pushed?) on the stack. --> missed optimization.
(I've played a little but didn't find a quick, working solution for the
truncation, only some awful lengthy code. Will add a TODO in the patch.)
Changing the interface to use "character, intent(in) :: c"
produces what I assume is the ordinary by-reference.
> Looks good.
> I would suggest to create an overload that avoids duplicating the
> build_int_cst (integer_type_node, 1) in several places.
> Shouldn't it be build_int_cst (gfc_charlen_type_node, 1) by the way?
That's true. I copied that from another snippet.
It is not clear to me what you mean by "overload" here. Do you want to
elaborate?
I've also extended the testcase to sample most things that came to my mind,
except for the [character, value, bind(c)] case. We'd better track this
elsewhere.
