Hello all,

I've been using GCC 4.9.4 for a while now (arm-linux-gnueabi-gcc (Linaro GCC 4.9-2017.01) 4.9.4), and I found this strange behavior:

In the library header (libm5op.h):
-----
#ifdef __cplusplus
extern "C" {
#endif

#include <stdint.h>

void warm_and_run_(int64_t intervals_warm, int64_t intervals_run);

#ifdef __cplusplus
}
#endif
-----

In the library C file (m5op_arm_.c):
-----
#include "stdio.h"
#include <stdlib.h>
#include "libm5op.h"

void warm_and_run_(int64_t intervals_warm, int64_t intervals_run)
{
    // Code here using args
}
-----

The code above is in /home/fernando/work/benchs/SPEC_CPU2006v1.1-aarch64/m5op/ and compiled as a library with GCC 6.3.1 and is ok:

~/work/toolchains/gcc-linaro-6.3.1-2017.02-x86_64_arm-linux-gnueabi/bin/arm-linux-gnueabi-gcc -march=armv7-a -mfpu=neon-vfpv4 -mfloat-abi=softfp -O3 -fno-optimize-sibling-calls -c m5op_arm_.c -o m5op_arm_.o

~/work/toolchains/gcc-linaro-6.3.1-2017.02-x86_64_arm-linux-gnueabi/bin/arm-linux-gnueabi-gcc -c m5op_arm.S -o m5op_arm.o

~/work/toolchains/gcc-linaro-6.3.1-2017.02-x86_64_arm-linux-gnueabi/bin/arm-linux-gnueabi-ar rcs libm5op32.a m5op_arm_.o m5op_arm.o





The library is used in a source code compiled with the GCC 4.9.4 describe at the begining.
In the C file:
-----
#include <libm5op.h>

S_regmatch(pTHX_ regnode *prog)
{
    warm_and_run_(161, 818);

    // Code continues
}
------

This source is compile with:

~/work/toolchains/gcc-linaro-4.9.4-2017.01-x86_64_arm-linux-gnueabi/bin/arm-linux-gnueabi-gcc -c -o regexec.o -DSPEC_CPU -DNDEBUG -DPERL_CORE   -static -marm -march=armv7-a -          mtune=generic-armv7-a -mfpu=neon-vfpv4 -mfloat-abi=softfp -O3 -fno-strict-aliasing -std=gnu89 -I/home/fernando/work/benchs/SPEC_CPU2006v1.1-aarch64/m5op/ -L/home/fernando/work/benchs/ SPEC_CPU2006v1.1-aarch64/m5op/ -DGEM5_ARM32=1       -DSPEC_CPU_ILP32 -DSPEC_CPU_LINUX_IA32        regexec.c

~/work/toolchains/gcc-linaro-4.9.4-2017.01-x86_64_arm-linux-gnueabi/bin/arm-linux-gnueabi-gcc   -static -marm -march=armv7-a -mtune=generic-armv7-a -mfpu=neon-vfpv4 -mfloat-           abi=softfp -O3 -fno-strict-aliasing -std=gnu89 -I/home/fernando/work/benchs/SPEC_CPU2006v1.1-aarch64/m5op/ -L/home/fernando/work/benchs/SPEC_CPU2006v1.1-aarch64/m5op/ -DGEM5_ARM32=1  -DSPEC_CPU_ILP32 -DSPEC_CPU_LINUX_IA32       av.o deb.o doio.o doop.o dump.o globals.o gv.o hv.o locale.o mg.o numeric.o op.o pad.o perl.o perlapi.o perlio.o perlmain.o perly.o pp.o    pp_ctl.o pp_hot.o pp_pack.o pp_sort.o pp_sys.o regcomp.o regexec.o run.o scope.o sv.o taint.o toke.o universal.o utf8.o util.o xsutils.o Base64.o Cwd.o Dumper.o HiRes.o IO.o Peek.o    attrs.o poll.o stdio.o DynaLoader.o MD5.o Storable.o Parser.o specrand.o Hostname.o Opcode.o             -lm     -lm5op32 -lm5op32  -o perlbench





Finally, the assembled code of S_regmatch has:
-----
   af2d0:   e3a000a1    mov r0, #161    ; 0xa1
   af2d4:   e3001332    movw    r1, #818    ; 0x332
   af2d8:   e58d3018    str r3, [sp, #24]
   af2dc:   e58d2028    str r2, [sp, #40]   ; 0x28
   af2e0:   fa02615c    blx 147858 <warm_and_run_>
-----

So, this means that warm_and_run_ is assumed by GCC 4.9.4 to have 32 bits arguments, while they are indeed 64 bits. This seems to be a bug for me. The code in the library is correctly allocating 2*32 bits regs for each argument.

For now, I'm using int32_t, and I just thought it could be useful to feedback you guys.

--
Fernando A. Endo, Post-doc

INRIA Rennes-Bretagne Atlantique
France