Deadly optimization bug (all gcc versions!)

[Toon Moene]

David Edelsohn wrote:

> >>>>> veksler  writes:

> veksler> The bug shows itself on gcc-2.7.0 gcc-2.7.2.1, egcs-1.0.1, egcs-1.1.2,
> veksler> gcc-2.95.
> veksler> On AIX-4.1, Linux-x86 (RH4.2 and RH6.0).

>         This means that you have seen the bug in both PowerPC and IA-32
> code generation?  I definitely see it in PowerPC.  A whole group of
> instructions disappear between flow and combine.  Also, -O3 with inlining
> seems to produce correct results.  Maybe combine is trying some alternate
> instructions, failing, and then not properly restoring the instructions?

[ General Warning:  I have no idea what the C Standard mandates when
  shifting an unsigned number by a signed quantity (i.e. the constant
  1) ]

I just found that on RH Linux 5.2, GNU C version 2.95.1 19990809
(prerelease) with -O produces as output:

ret=0
ret=0
ret=0

whereas the non-optimized version gives:

ret=0
ret=1
ret=1

in accordance with what I got from SGI's cc 7.2.1 compiler at work.

>  Maybe combine is trying some alternate instructions, failing, and 
>  then not properly restoring the instructions?

Or the other way around (I see a couple of NOTE_INSN_DELETED in the
.combine dump where the .flow dump still has something like:

(insn 4 31 6 (set (reg/v:SI 22)
        (mem/f:SI (reg:SI 16 %argp) 0)) 48 {movsi+2} (nil)
    (expr_list:REG_EQUIV (mem/f:SI (reg:SI 16 %argp) 0)
        (nil)))

[ Flow is run before combine, isn't it - doesn't combine need some
  flow graph info to decide whether certain combine's are valid ? ]

-- 
Toon Moene (toon@moene.indiv.nluug.nl)
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Phone: +31 346 214290; Fax: +31 346 214286
GNU Fortran: http://world.std.com/~burley/g77.html