Re: Your June 7 change to expand_expr

[kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)]

      > 
      > The fundamental problem is that there needs to be a "conservative"
      > setting, one for which we can safely make things without risking
      > bugs.  This used to be the case when that bit is true.

    ?  I'm not aware of any time in the recent (gcc2 era) past where the
    MEM_IN_STRUCT_P bit had that meaning.

    Why?  Because the old alias code (as far as I know) has always used
    MEM_IN_STRUCT_P to help with alias analysis.

Strictly speaking, that's true: you can construct cases where either
setting of the bit can generate wrong code in some case, but normally
turning it on was the "safe case" (more precisely, the *safer* case).
As it gets used more, this is less true.

And that's dangerous because there's no way to set it precisely.

    The question then becomes "has egcs's alias analysis progressed far
    enough to remove the that flag?".  I don't know the answer.

Unfortunately, I don't think there's much choice.  From what I've seen,
the reason why we don't see more bugs due to it being set wrong is that
it doesn't tend to affect the schedule all that much.  I think it's a very
gross approximation that we've gotten away with for this many years since
scheduling was not that agressive.