[Bug fortran/110360] ABI issue with character,value dummy argument

["anlauf at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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.