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.


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

Ian


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