[Bug rtl-optimization/33638] [4.3 regression]: wrong code with -fforce-addr

["zadeck at naturalbridge dot com" <gcc-bugzilla at gcc dot gnu dot org>]

------- Comment #18 from zadeck at naturalbridge dot com  2007-10-06 13:07 -------
Subject: Re:  [4.3 regression]: wrong code with
 -fforce-addr

ubizjak at gmail dot com wrote:
> ------- Comment #16 from ubizjak at gmail dot com  2007-10-06 06:49 -------
> (In reply to comment #14)
>   
>> The testcase works for me, that is, it produces the expected output good.out.
>>     
>
> Uh, you have to un-comment the line 315 of the comunpack.f test. The testcase,
> as attached, produces good code. Un-commenting line 315, you will get:
>
> .L80:
>         movl    $0x40000000, (%esp)
>         call    powf
>         fstps   -152(%ebp)
>         negl    -136(%ebp)
>         fildl   -136(%ebp)
>         fstps   4(%esp)
>         movl    $0x41200000, (%esp)
>         call    powf
>
> Note that only one argument is loaded to the stack before first powf.
>
> Without -fforce-address on un-commented testcase, we got:
>
> .L80:
>         fildl   -132(%ebp)
>         fstps   4(%esp)
>         movl    $0x40000000, (%esp)
>         call    powf
>         fstps   -140(%ebp)
>         negl    -128(%ebp)
>         fildl   -128(%ebp)
>         fstps   4(%esp)
>         movl    $0x41200000, (%esp)
>         call    powf
>
>
>   
ian,

As you may remember, the dse code assumes that it can "see" all of the
stores that are frame_related.   It appears that with the  -fforce-addr
option this is not true.  in this particular example, a frame related
pointer gets loaded into register 755 very early on (in a different
block) and since const calls only disqualify frame-related stores,
(since they may push params onto the stack), the parameter push is
considered dead.

My question to you, is the proper fix to check flag_force-addr and if it
is set just assume that every store may be frame related or is there
some sort of tea leaf that i might have access to know that reg 755 is
used in this way?

(note that you have to jump thru a few hoops to recreate this, since
comunpack.f is in a separate attachment from the rest of the code and
you have to uncomment line 315 to recreate the bug.)


Kenny


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33638