help understanding a gcc compilation issue

help understanding a gcc compilation issue

[Gabi Voiculescu]

Hello.

Sorry about the intelligibility of this email but it is pretty late over here.

I am a newbie when it comes to gcc abi. I usually write my code in C.

I found a weird issue when porting a piece of software from a crostools gcc-3.4.4 based toolchain to a crostools based gcc-4.2.4 and I would like some help understanding it.

When running, the function llrint() using and returning 64 bit variables fails to call rint(), and instead calls itself!?!.

#include <stdio.h>
extern double rint(double x);

long long llrint(double x);
long long llrint(double x)
{
printf("%s,%d llrint entry\n", __func__, __LINE__); //-gabi 07/08/2009 
    return (long long) rint(x);
}

When calling llrint I see the print statement repeated forever, without calling rint() or returning from llrint().
 
The way I fixed my issue: I had to use local variables to store the result from rint:


#include <stdio.h>
extern double rint(double x);

long long llrint(double x);
long long llrint(double x)
{
     double result;
     long long temp;
     result =rint(x);
     temp =(long long) result;
printf("%s,%d llrint entry\n", __func__, __LINE__); //-gabi 07/08/2009 
    return (long long) rint(x);
}

I must say I am verifying this code as part of a ported libm over l4, for armv5te platform in the skyeye emulator.

The compiler has been obtained from the steps specified at: wiki.ok-labs.com:
To build such a cross compiler get the latest version of Crosstool 0.43 and apply the Crosstool EABI patch. Then build the toolchain with:
# sh demo-arm-softfloat.sh 

If anybody knows if this issue comes from a known gcc behaviour I would appreciate a reply. I have attached the result of objdump-ing the compiled object, for each example code from above.

Hope to get some feedback,
Gabi Voiculescu

--------------------------------------------------------------------------
compilation command:
 /opt/okl/Linux-i386/arm/gcc-4.2.4-glibc-2.7/arm-unknown-linux-gnueabi/bin/arm-unknown-linux-gnueabi-gcc --std=gnu99 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Wmissing-declarations -Wredundant-decls -Wundef -Wpointer-arith -Wno-nonnull -Werror -march=armv5te -mtune=xscale -O2 -nostdlib -nostdinc -g -DARCH_ARM -DARCH_VER=5 -DMACHINE_GUMSTIX2 -DENDIAN_LITTLE -DWORDSIZE_32 -DARM_PID_RELOC=1 -DARM_SHARED_DOMAINS=1 -D__ARMv__=5 -D__ARMv5TE__ -DPLATFORM_PXA=1 -DSERIAL_FFUART=1 -DVIDEO_HACK=1 -DVIDEO2_HAC
 K=1 -DUSE_MOV=1 -DUSE_LIBM=1 -DDEBUG_PRINT_EXCEPTION=1 -DIG_APP_CONFIG_PLAT_PXA=1 -DIG_DEBUG_PRINT=1 -DPXA_LCD_DRIVER=1 -DMAIN_MENU=1 -DENABLE_SKYEYE_DEBUGGING=1 -DCONFIG_VERBOSE_INIT=1 -DARM_PID_RELOC=1 -DARM_SHARED_DOMAINS=1 -D__ARMv__=5 -D__ARMv5TE__ -DPLATFORM_PXA=1 -DSERIAL_FFUART=1 -DVIDEO_HACK=1 -DVIDEO2_HACK=1 -DUSE_MOV=1 -DUSE_LIBM=1 -DDEBUG_PRINT_EXCEPTION=1 -DIG_APP_CONFIG_PLAT_PXA=1 -DIG_DEBUG_PRINT=1 -DPXA_LCD_DRIVER=1 -DMAIN_MENU=1 -DENABLE_SKYEYE_DEBUGGING=1 -DCONFIG_VERBOSE_INIT=1 -DKENGE_IGUANA -DKENGE_IGUANA -DKENGE_L4_ROOTSERVER -DTHREAD_SAFE -DMAX_ELF_SEGMENTS=1000 -DIGUANA_VERSION=20060101UL -DIGUANA_DEBUG=5 -DIG_DEBUG_PRINT -DCONFIG_TRACEBUFFER=1 -DIG_VERBOSE -DCONFIG_MAX_THREAD_BITS=10 -DCONFIG_SCHEDULE_INHERITANCE=1
 -DCONFIG_EAS=1 -DCONFIG_ZONE=1 -DCONFIG_MEM_PROTECTED=1 -DCONFIG_MEMLOAD=1
 -DCONFIG_REMOTE_MEMORY_COPY=1 -DCONFIG_USER_MUTEXES=1 -D__L4_ARCH__=arm -DL4_ARCH_ARM -DCONFIG_DEBUG=1 -Ibuild_demogb/iguana/include -Ibuild_demogb/iguana/object/libs_m/src -Ilibs/m/src libs/m/src/common/s_llrint.c -c -o build_demogb/iguana/object/libs_m/src/common/s_llrint.o
--------------------------------------------------------------------------
Original (non working/looping code objdump):

s_llrint.o.not.ok:     file format elf32-littlearm

Disassembly of section .text:

00000000 <llrint>:
extern double rint(double x);

long long llrint(double x);
long long llrint(double x)
{
   0:	e92d4030 	stmdb	sp!, {r4, r5, lr}
printf("%s,%d llrint entry\n", __func__, __LINE__); //-gabi 07/08/2009 FIXME: remove rint statememt
   4:	e3a0200d 	mov	r2, #13	; 0xd
   8:	e1a04000 	mov	r4, r0
   c:	e1a05001 	mov	r5, r1
  10:	e24dd004 	sub	sp, sp, #4	; 0x4
  14:	e59f1018 	ldr	r1, [pc, #24]	; 34 <.text+0x34>
  18:	e59f0018 	ldr	r0, [pc, #24]	; 38 <.text+0x38>
  1c:	ebfffffe 	bl	1c <llrint+0x1c>
#if 1 //-gabi 07/08/2009 Does this fix the call to rint problem? what is the cause of the rint
    long long temp;
    double result;
    result = rint(x);
    temp = (long long) result;
    return temp;
#else 
    return (long long) rint(x);
  20:	e1a00004 	mov	r0, r4
  24:	e1a01005 	mov	r1, r5
#endif
}
  28:	e28dd004 	add	sp, sp, #4	; 0x4
  2c:	e8bd4030 	ldmia	sp!, {r4, r5, lr}
  30:	eafffffe 	b	30 <llrint+0x30>
	...


--------------------------------------------------------------------------
New (working code objdump):

s_llrint.o.ok:     file format elf32-littlearm

Disassembly of section .text:

00000000 <llrint>:
extern double rint(double x);

long long llrint(double x);
long long llrint(double x)
{
   0:	e92d4030 	stmdb	sp!, {r4, r5, lr}
printf("%s,%d llrint entry\n", __func__, __LINE__); //-gabi 07/08/2009 FIXME: remove rint statememt
   4:	e3a0200d 	mov	r2, #13	; 0xd
   8:	e24dd004 	sub	sp, sp, #4	; 0x4
   c:	e1a04000 	mov	r4, r0
  10:	e1a05001 	mov	r5, r1
  14:	e59f001c 	ldr	r0, [pc, #28]	; 38 <.text+0x38>
  18:	e59f101c 	ldr	r1, [pc, #28]	; 3c <.text+0x3c>
  1c:	ebfffffe 	bl	1c <llrint+0x1c>
#if 1 //-gabi 07/08/2009 Does this fix the call to rint problem? what is the cause of the rint
    long long temp;
    double result;
    result = rint(x);
  20:	e1a00004 	mov	r0, r4
  24:	e1a01005 	mov	r1, r5
  28:	ebfffffe 	bl	28 <llrint+0x28>
  2c:	ebfffffe 	bl	2c <llrint+0x2c>
    temp = (long long) result;
    return temp;
#else 
    return (long long) rint(x);
#endif
}
  30:	e28dd004 	add	sp, sp, #4	; 0x4
  34:	e8bd8030 	ldmia	sp!, {r4, r5, pc}
	...



      

Re: help understanding a gcc compilation issue

[Ian Lance Taylor]

Gabi Voiculescu <boy3dfx2@yahoo.com> writes:

> When running, the function llrint() using and returning 64 bit variables fails to call rint(), and instead calls itself!?!.
>
> #include <stdio.h>
> extern double rint(double x);
>
> long long llrint(double x);
> long long llrint(double x)
> {
> printf("%s,%d llrint entry\n", __func__, __LINE__); //-gabi 07/08/2009 
>     return (long long) rint(x);
> }
>
> When calling llrint I see the print statement repeated forever, without calling rint() or returning from llrint().

gcc is outsmarting itself.  When it sees "(long long) rint(x)", it
converts that into "llrint(x)".  This is normally a safe conversion, but
of course it is unsafe when you are trying to implement llrint itself.
You can avoid this problem by using the -fno-builtin-rint option.

Ian

Re: help understanding a gcc compilation issue

[Gabi Voiculescu]

Thank you.

I would have spent some time figuring this out and might not have done it in the end.

Gabi Voiculescu

--- On Thu, 7/9/09, Ian Lance Taylor <iant@google.com> wrote:

> From: Ian Lance Taylor <iant@google.com>
> Subject: Re: help understanding a gcc compilation issue
> To: "Gabi Voiculescu" <boy3dfx2@yahoo.com>
> Cc: gcc-help@gcc.gnu.org
> Date: Thursday, July 9, 2009, 7:42 AM
> Gabi Voiculescu <boy3dfx2@yahoo.com>
> writes:
> 
> > When running, the function llrint() using and
> returning 64 bit variables fails to call rint(), and instead
> calls itself!?!.
> >
> > #include <stdio.h>
> > extern double rint(double x);
> >
> > long long llrint(double x);
> > long long llrint(double x)
> > {
> > printf("%s,%d llrint entry\n", __func__, __LINE__);
> //-gabi 07/08/2009 
> >     return (long long) rint(x);
> > }
> >
> > When calling llrint I see the print statement repeated
> forever, without calling rint() or returning from llrint().
> 
> gcc is outsmarting itself.  When it sees "(long long)
> rint(x)", it
> converts that into "llrint(x)".  This is normally a
> safe conversion, but
> of course it is unsafe when you are trying to implement
> llrint itself.
> You can avoid this problem by using the -fno-builtin-rint
> option.
> 
> Ian
>