GCSE botch with EH case

[Richard Kenner]

    > the EH case that wasn't there in the the normal case.  I don't at all
    > understand what this store motion is all about.  Not only does it 
    > appear incorrect, but I don't see how it's an "optimization".
    
    This i'll ignore, since i'm really not up to explaining the details of 
    store motion to you right now, when any compiler book could do it just 
    as well.

Sorry to be unclear.

I wasn't asking about store motion in general, but about *that particular*
store motion.  I don't see what the benefit of moving that store would have
been even if it were correct to move it.

    Is this on a clean tree? One with local patches?  If it's one with 
    local patches, please retry this on a clean tree and let us know if 
    it's still happening.

Without local patches, I don't even get this far with Ada, so it's somewhat
of a Catch-22 situation.  If I can get the problem in tree-cfg.c resolved,
then my patches will pass testing and I can start to get them in, so perhaps
that might have to happen first.

    It looks like some code that handles this in compute_pre_data needs to 
    be added to build_store_vectors, but it also could be some local 
    patches in your tree.

I don't have any patches to the RTL optimizers, so it's not likely *caused*
by any local patches, though it could easily be a latent problem exposed by
them.  However, this ACATS test was also failing on July 30, so it wasn't
anything *too* recent.

Can you point to the exact code you're talking about?  Perhaps I can try
what you're suggesting and see what happens.