https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87689
Thomas Koenig <tkoenig at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|WAITING |NEW
--- Comment #3 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
I checked, and it seems that this is an old bug; it occurs both
with gfortran 4.8.5 and 8.1.0.
This goes away with -flto or if you put both procedures into one file,
and does not happen on Linux.
Tree dump looks reasonable with 8.1:
static integer(kind=4) C.2183 = 1;
static integer(kind=4) C.2184 = 2;
static integer(kind=4) C.2185 = 3;
static integer(kind=4) C.2186 = 4;
static integer(kind=4) C.2187 = 5;
static integer(kind=4) C.2188 = 6;
character(kind=1) str.0[20];
doesntwork_p8 ((character(kind=1)[1:20] *) &str.0, 20, &c, &C.2183,
&C.2184, &C.2185, &C.2186, &C.2187, &C.2188, 1);
__builtin_memmove ((void *) &res, (void *) &str.0, 20);
vs.
doesntwork_p8 (character(kind=1)[1:20] & __result, integer(kind=8) .__result,
character(kind=1)[1:1] & restrict c, integer(kind=4) & restrict a1,
integer(kind=4) & restrict a2, integer(kind=4) & restrict a3, integer(kind=4) &
restrict a4, integer(kind=4) & restrict a5, integer(kind=4) & restrict a6,
integer(kind=8) _c)
{
What looks less reasonable is the debug output:
breakpoint 1, doesntwork_p8 (__result=@0x3fffffffed80:
'\224\016\000\020\000\000\000\000\230\016\000\020\000\000\000\000\000\000\000\000',
.__result=20, c='`', a1=1, a2=2, a3=3, a4=4, a5=5,
a6=<error reading variable: Cannot access memory at address 0x0>, _c=0) at
b.f90:6
This looks like the arguments pushed on the stack somehow have the wrong number
of bytes...
