This is the mail archive of the
mailing list for the GCC project.
Re: rtx_unchanging_p vs c++ vtable fields
- From: kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)
- To: rth at redhat dot com
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Fri, 7 Dec 01 21:55:24 EST
- Subject: Re: rtx_unchanging_p vs c++ vtable fields
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)
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
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?