This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GCC RTX generation question


> "Radu Hobincu" <radu.hobincu@arh.pub.ro> writes:
>
>> 1. I have the following code:
>>
>> -------------------------------
>> extern void doSmth();
>>
>> void bugTest(){
>> 	doSmth();
>> }
>> -------------------------------
>>
>> It compiles fine with -O0, but when I try to use -O3, I get the
>> following
>> compiler error:
>>
>> ---------------------------------------------
>> test0.c:13: error: unrecognizable insn:
>> (call_insn 7 6 8 3 test0.c:12 (call (mem:SI (mem:SI (reg/f:SI 41) [0 S4
>> A32]) [0 S4 A32])
>>         (const_int 0 [0x0])) -1 (nil)
>>     (nil))
>> test0.c:13: internal compiler error: in extract_insn, at recog.c:2048
>> ---------------------------------------------
>>
>> I don't understand why the compiler generates (call (mem (mem (reg)
>> )))...
>> and also, I was under the impression that any address should checked by
>> the GO_IF_LEGITIMATE_ADDRESS macro, but I checked and the macro doesn't
>> receive a (mem (reg)) rtx to verify. This is most likely a failure of my
>> part to describe something correctly, but the error message isn't very
>> explicit.
>
> This looks like gcc is loading the function address from memory.  Is
> that required for your target?  Assuming it is, then the problem seems
> to be that the operand predicate for your call instruction accepts
> (mem:SI (mem:SI (reg:SI 41))).  That seems odd.

Thank you, you are right, the description of "call" was way off. Fixed it
and it works now with any optimization level.


>> 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?

Regards,
Radu


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]