Possible bug with int64_t in GCC 4.9.4

[Fernando Endo]

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

[Jim Wilson]

I've been using GCC 4.9.4 for a while now (arm-linux-gnueabi-gcc (Linaro GCC
...
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.

I am not able to reproduce this problem with the info you have
provided. I am getting 64-bit args passed to the warm_and_run_
function. Perhaps the reduced testcase doesn't show the problem. I
had to modify your testcase to build it, pTHX_ and regnode are not
defined for instance, so maybe an important detail was accidentally
left out. Or maybe something else went wrong on your end. Maybe you
have two copies of the libm5op.h file, and the wrong one was included.

I suggest compiling the regexec.c file with --save-temps, which will
leave behind the proprocessor output in the regexec.i file, and the
assembler output in the regexec.s file. Check the regexec.i file to
make sure the types are OK after preprocessing. If you can send us
this file, that would help.

Jim