"Radu Hobincu" <radu.hobi...@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
