https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360
--- 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 = 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)='%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 = 65
character :: c = 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=1), 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)='A'
val_c: char(65)='A'
val_c: char(65)='A'
With current 14-trunk on x86 I get:
% gfc-14 value_10_f.f90 value_10_c.c && ./a.out
val(fortran): 65 A
val(fortran): 65 A
val(fortran): 65 A
val_c: char(65)='A'
val_c: char(65)='A'
val_c: char(-122)='�'
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 right
and consistent (both for LE and BE), and with that knowledge find out how the
Fortran part might be.
