Deadly optimization bug (all gcc versions!)

[Jeffrey A Law]

  In message < 37B869E2.30CAA4A@moene.indiv.nluug.nl >you write:
  > [ 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) ]
As long as the shift count is positive and smaller than the bitsize of the
object being shifted, it will do what one would expect :-)  The shift count
has no bearing on the ultimate type of the expression (the type of the
expression is derived solely from the value being shifted).

Anyway...

  > >  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:
This tends to indicate that combine thought it could simplify the expression
into a nop.


  > [ Flow is run before combine, isn't it - doesn't combine need some
  >   flow graph info to decide whether certain combine's are valid ? ]
flow is run before combine and provides the combiner with the dataflow
information to drive what combinations it will try.  ie, it provides use-def
chain pointers.  The combiner then tries to combine the definition of a value
with the use of the value.

jeff