From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id 66D80385800C; Sat, 29 Jul 2023 20:05:03 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 66D80385800C
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1690661103;
	bh=Zal6J23CiXBa+q3kgAGqU6jwxZX/yh5+pZJQ9p7X1Yc=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=C4CZ1k5Gl5pflRVkdZk3JRTAwgH6qlqVMh+LUrjj/dJt8bi8NpYcAG5rVN7cLdmpU
	 sEeIlxDq5t/QkjkBJo6FTxBXfqOjTirdmaOVtAgDMFWsJpzICdCF+0tqUdirUoZ82P
	 WyRXI4KmzRjEs9qBfJqlJoK3w9qXUKuYfZl+Jh88=
From: "anlauf at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/110360] ABI issue with character,value dummy argument
Date: Sat, 29 Jul 2023 20:05:03 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Version: 14.0
X-Bugzilla-Keywords: ABI, wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: anlauf at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: anlauf at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-110360-4-0gZgttbIuZ@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-110360-4@http.gcc.gnu.org/bugzilla/>
References: <bug-110360-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
List-Id: <gcc-bugs.sourceware.org>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D110360

--- Comment #33 from anlauf at gcc dot gnu.org ---
(In reply to David Edelsohn from comment #32)
> I'm leaning back to big-endian vs little-endian, and not a struct issue. =
 A
> little-endian STRING will start at the lowest address and a big-endian
> STRING will start at the highest address.

OK.  I've thought a little and came to the following testcase that might
help to understand what we have right now (a mess).  It tests 6 =3D 3 x 2
variations, namely passing a literal constant, a variable, and a function
result via a temporary to either a fortran subroutine or a C function:

% cat value_10_c.c
#include <stdio.h>

void
val_c (char c)
{
  printf ("val_c: char(%d)=3D'%c'\n", (int) c, c);
}

% cat value_10_f.f90
program p
  implicit none
  interface
     subroutine val_c (c) bind(c)
       use iso_c_binding, only: c_char
       character(c_char), value :: c
     end subroutine val_c
  end interface
  integer   :: a =3D 65
  character :: c =3D char(65)
  call val   ("A")
  call val   (c)
  call val   (char(a))
  call val_c ("A")
  call val_c (c)
  call val_c (char(a))
contains
  subroutine val (c)
    character(kind=3D1), value :: c
    print *, "val(fortran): ", iachar (c), c
  end
end

With the Intel compiler on x86 I get what I expect:

 val(fortran):           65 A
 val(fortran):           65 A
 val(fortran):           65 A
val_c: char(65)=3D'A'
val_c: char(65)=3D'A'
val_c: char(65)=3D'A'

With current 14-trunk on x86 I get:

% gfc-14 value_10_f.f90 value_10_c.c && ./a.out=20
 val(fortran):           65 A
 val(fortran):           65 A
 val(fortran):           65 A
val_c: char(65)=3D'A'
val_c: char(65)=3D'A'
val_c: char(-122)=3D'=EF=BF=BD'

The last line of output is junk, which is understood by looking at the dump,
as in that case we wrongly pass a reference instead of the value.

The C interface part hasn't been touched by the patches in the current PR
and obviously also needs a fix.

So the next thing is to understand how the C interface works and get it rig=
ht
and consistent (both for LE and BE), and with that knowledge find out how t=
he
Fortran part might be.=