gcc on 64 bit && different behaviour while 'cast to pointer from integer of different size'

gcc on 64 bit && different behaviour while 'cast to pointer from integer of different size'

[Matthias Apitz]

Hello,

We compile on Solaris SPARC a big software project and for the first
time to support 64 bit. The historical grown C code was never written
with 64 bit in mind and on 32 bit pointers and integers are of the same size.

We have two different version of gcc available on this host, 3.4.3 and 4.4.2.
I have below a small example where a function fun() should return a char pointer
and due to its missing declaration as 'extern char *fun();' the compiler
treats the function as integer returning and produce the warning

   cast to pointer from integer of different size

Until now total clear. The questions are:

Why does the gcc 3.4.3 correct this problem on the fly and stores
the full 64 bit pointer into the receiving char pointer, while the
gcc 4.4.2 does not? 

When this feature or behaviour was changed after gcc 3.4.3?

Is this somehow a command line flag for gcc to control the behaviour?

For sure, the correct way is to change the (hundreds) of places where
the function declaration is missing.

Thanks

	matthias


$ uname -a
SunOS srap01dxle 5.10 Generic_150400-17 sun4u sparc SUNW,SPARC-Enterprise

$ /usr/local/bin/gcc --version
gcc (GCC) 4.4.2
Copyright (C) 2009 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ /usr/sfw/bin/gcc --version
gcc (GCC) 3.4.3 (csl-sol210-3_4-branch+sol_rpath)
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ cat main.c
/* main.c */
#include <stdio.h>

/* extern char* fun(); */

main(int argc, char **argv)
{
   char *p = (char *) NULL;
   p = (char *)  fun();
   printf("main has p as: %016lx\n", p);
   printf("main has p as: %s\n", p);
}

$ cat fun.c
/* fun.c */
#include <stdio.h>
char *fun()
{
   char *p = "fun";
   printf("fun() returns pointer p as: %016lx\n", p);
   return (p);
}

$ /usr/sfw/bin/gcc -m64 main.c fun.c ; ./a.out
main.c: In function `main':
main.c:9: warning: cast to pointer from integer of different size
fun() returns pointer p as: 0000000100000c80
main has p as: 0000000100000c80
main has p as: fun

$ /usr/local/bin/gcc -m64 main.c fun.c ; ./a.out
main.c: In function 'main':
main.c:9: warning: cast to pointer from integer of different size
fun() returns pointer p as: 0000000100000c30
main has p as: 0000000000000c30
Segmentation Fault (core dumped)

-- 
Matthias Apitz, guru@unixarea.de, http://www.unixarea.de/  +49-176-38902045
No! Nein! ¡No! Όχι! -- Ευχαριστούμε!

Re: gcc on 64 bit && different behaviour while 'cast to pointer from integer of different size'

[Andrew Haley]

On 22/07/15 08:46, Matthias Apitz wrote:
> Why does the gcc 3.4.3 correct this problem on the fly and stores
> the full 64 bit pointer into the receiving char pointer, while the
> gcc 4.4.2 does not? 
> 
> When this feature or behaviour was changed after gcc 3.4.3?
> 
> Is this somehow a command line flag for gcc to control the behaviour?

The question is whether the 64-bit function pointer is truncated when
it is read from register RAX on return from the function.  This is a
matter for the system ABI: it's not something that GCC decides.  The
x86_64 ABI changed during this timeframe, and you might be seeing an
effect of that.  I can't remember exactly when the changes were made.

However, this is also the kind of thing which can also vary depending
on the optimization level.  Turn on optimization and it might all
break.  You can't depend on good luck to make this work.

Andrew.

Re: gcc on 64 bit && different behaviour while 'cast to pointer from integer of different size'

[Andrew Haley]

On 22/07/15 09:07, Matthias Apitz wrote:
> El día Wednesday, July 22, 2015 a las 08:59:52AM +0100, Andrew Haley escribió:
> 
>> On 22/07/15 08:46, Matthias Apitz wrote:
>>> Why does the gcc 3.4.3 correct this problem on the fly and stores
>>> the full 64 bit pointer into the receiving char pointer, while the
>>> gcc 4.4.2 does not? 
>>>
>>> When this feature or behaviour was changed after gcc 3.4.3?
>>>
>>> Is this somehow a command line flag for gcc to control the behaviour?
>>
>> The question is whether the 64-bit function pointer is truncated when
>> it is read from register RAX on return from the function.  This is a
>> matter for the system ABI: it's not something that GCC decides.  The
>> x86_64 ABI changed during this timeframe, and you might be seeing an
>> effect of that.  I can't remember exactly when the changes were made.
> 
> This is not on x86, but SPARC.

Sorry, yes, I read it too quickly and was thinking of Solaris x86.
First coffee of the day.

>> However, this is also the kind of thing which can also vary depending
>> on the optimization level.  Turn on optimization and it might all
>> break.  You can't depend on good luck to make this work.
> 
> I agree here. The question was more to understand why it works on 3.4.3.

Sure, I get that. Maybe somebody will do the work to look inside the
compiler and see why the code generation is different.  But with
undefined behaviour on an obsolete compiler, you may be out of luck.

Andrew.