Re: GCC RTX generation question

["Radu Hobincu" <radu dot hobincu at arh dot pub dot ro>]

> "Radu Hobincu" <radu.hobincu@arh.pub.ro> writes:
>
>>>> 2. I have another piece of code that fails to compile with -O3.
>>>>
>>>> ---------------------------------------------
>>>> struct desc{
>>>> 	int int1;
>>>> 	int int2;
>>>> 	int int3;
>>>> };
>>>>
>>>> int bugTest(struct desc *tDesc){
>>>> 	return *((int*)(tDesc->int1 + 16));
>>>> }
>>>> ----------------------------------------------
>>>
>>> That code looks awfully strange.  Is that an integer or a pointer?
>>>
>>>> This time the compiler crashes with a segmentation fault. From what I
>>>> could dig up with gdb, the compilers tries to make a LIBCALL for a
>>>> memcopy, but I'm not really sure why. At the end is the back-trace of
>>>> the
>>>> crash.
>>>
>>> gcc is invoking memmove.  This is happening in the return statement.
>>> For some reason gcc thinks that the function returns a struct.  Your
>>> example does not return a struct..  I can not explain this.
>>
>> Ok, after changing both PARM_BOUNDARY and STACK_BOUNDARY from 8 to 32,
>> now
>> the compiler no longer crashes with segmentation fault, but it still
>> generates a memmove syscall.
>>
>> To explain the code, I have a structure holding some info about a serial
>> interface. One of the fields of the structure is the base address at
>> which
>> the serial is mapped in the main memory. Offseted by 16 bytes is the
>> address from which I can read the available byte count received by the
>> serial. It would probably be a better practice to define the base as
>> (*int) rather than (int) but this should work as well. I tried both
>>
>> return *((int*)tDesc->int1 + 4);
>> return *((int*)(tDesc->int1 + 16));
>>
>> The result is the same: a system call. Is this in any way related to the
>> back-end definition which I might have done wrong, or is it middle-end
>> related?
>
> I don't know.  There is something very odd about the fact that gcc
> thinks that you are returning a struct when you are actually returning
> an int.  In particular, as far as I can see, cfun->returns_struct is
> true.  I think you need to try to figure out why that is happening.
>
> Ian
>

Ok, thanks again for pointing me in the right direction. It seems that I
declared the FUNCTION_VALUE_REGNO_P as register 12, but I didn't specify
it as a CALL_USED_REGISTERS. So the compiler tried to return the value in
memory. Since the returned value was something that was supposed to be
read from memory, it probably decided to use memmove to copy the 4 bytes
of the int pointer from the return statement to the stack (not sure if
it's faster than a read and a write with an additional general register
tho).

Anyway, thank you!
Radu