Ian Lance Taylor wrote:
Sanjiv Kumar Gupta <[EMAIL PROTECTED]> writes:
I am using gcc 3.3.1 release as my port, and looks
like I have hit a problem with greg.
You neglected to mention what target you are using.
Ian, the port is for a 32-bit RISC and not complete yet,
hence still not contributed.
This probably makes difficult for you to suggest any
fix, but I still asked in case I could get any pointers
for investigation.
I couldn't understand why the insns 620 and 621 are
being generated here as DI moves.
I'm not sure specifically why it got a DI move here, but it doesn't
look wrong. It's treating the struct named parts as DImode.
This is creating problem since insn 621 gets splitted
after reload into two SI moves,i.e. @(r21, -8) and
@(r21, -4).
This renders insns 619 as dead and hence insns 618 and
insn 429 as dead, which are eliminated by flow2.
It does look rather suspicious, but it's hard to know whether it is
wrong without seeing the value in r1.
r1 looks unrelated to struct members, and is being used by the
ifcvt pass to expand some comparison insns.
Does the behaviour change if you use -fno-strict-aliasing? (I can't
remember what the default was in 3.3.1).
Ian
The behaviour doesn't changes with -fno-strict-aliasing or
-fstrict-aliasing.
Thanks
Sanjiv
