rtx_unchanging_p vs c++ vtable fields

[Richard Kenner]

    Recently, libstdc++ has been being miscompiled, which causes all c++
    tests to fail on alphaev6-linux.  Not sure exactly what change exposed
    the problem, but the bug is that in ctype<char>::ctype,

    (insn 135 133 139 (set (mem/s/u/j:DI (reg/v/u/f:DI 69)
				     [0 <variable>._vptr$facet+0 S8 A64])
        (reg:DI 90)) -1 (nil)
    (nil))

    the memory reference is marked unchanging.  In a constructor, this field
    is not unchanging; it will in fact be assigned once for every base class.
    Once constructed, the value is unchanging, but I didn't think we make any
    attempt to use this knowledge.

And why is this a problem?  See below.

    I might guess that this should be conditional on
    lang_hooks.honor_read_only, but I have no idea what that hook really
    does.  I merely base this guess on the fact that that flag is only
    true for Ada.

No, that has to do with whether an INDIRECT_REF is to be considered readonly
because the result type is.

The issue here is very different and not something that was changed recently.

Jeff Law, as I recall, ran into this a while ago.  The problem is that if you
have something that has both unchanging and non-unchanging fields and you
store into the whole thing without /u, the unchanging parts won't be
invalidated.

His conclusion then, with which I agree, is that the *safe* direction is no
/u on a read and /u on a store.  So the idea was to be conservative in a
store case and force /u if any part of it would be read that way.  How can it
be an error to have an "extra" /u on a store: all it will do is invalidate
things it shouldn't?