Re: TREE_READONLY in lookup_tmp_var

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

    It was wrong.  These temporaries *are* set more than once.

How?  Those are the ones that are in the hash table.  If they are overwritten
then nobody else should be getting that same variable for the same value.

    Well, no one else can tell because no one else can build the ada front
    end at all.  This is your fault for not committing anything to fix the
    things that you know are wrong.  

I couldn't because I was getting regressions on the gcc testsuite due to
a latent problem with tree-cfg.c, which I just recently got a fix for.
Indeed I had a test run going just now, but a network failure killed it
and I'm not sure I'll be able to finish another one before I leave for
Europe tomorrow morning.  (The run looked good so far, but I'm on a target
with preexisting failures, so analysis is a complex process.)

    In particular, the alloca fix is a complete show-stopper.

As are others.  It's not like things were basically working: nothing was
really working that much at all, so I didn't give priority to keeping things
less broken on the Ada front.  I did check in the changes to the Ada files
(including that one) to the tree that Arno uses (it's confusing to his
procedures if both he and I check in Ada files to the FSF tree, so he's doing
all of them).  However, he couldn't check it in since he couldn't get a test
to work correctly, probably due to this problem.

    I should remind you that batching changes is a bad habit.

It's not ideal, but there aren't really that many and most are small.
Unfortunately, while I was getting testsuite failures that I didn't know
enough to fix and was waiting for help on, I didn't have much choice if
I wanted to continue to make progress.

    Why are you ever taking the address of a CONSTRUCTOR?  A constructor
    is not an lvalue.  Use a real variable.  *Especially* if you are 
    relying on it being treated a particular way, namely, by setting
    TREE_STATIC+TREE_READONLY.

The address is being used in another CONSTRUCTOR.

The typical case is for an unconstrained array.  If you have in Ada

	foo: string := "abc";

The most straightforward way of representing what this really looks like is:

	foo = { &{1, 3}, "abc"};

Yes, a temporary could be made for the {1,3}, but the job of that part of the
Ada front end is to make complex expression, letting the gimplifier
put in any needed temporaries.  That seems the right balance to me.

The semantics of the above are fairly clear and it used to work.