This is the mail archive of the
mailing list for the GCC project.
>>>>> "Jason" == Jason Merrill <firstname.lastname@example.org> writes:
>> Yes. A set that really Really means "this mem resides in read-only
Jason> Of course, that's not true until the object is fully
Jason> constructed, and inlined constructors could cause trouble. And
Jason> have, in my experimentation with TREE_CONSTANT;
Jason> g++.rfg/21027_14+.C was misoptimized because I was assigning
Jason> multiple times to an UNCHANGING location.
This would still be useful for gcj. In Java, the vtable really never
changes (at least, as long as vtables aren't moved by the GC -- but we
already assume a non-moving collector). Superclass constructors
always see the end vtable.
For gcj we'd also like to be able to tell the compiler that the length
field of an array never changes. It is set when the array is
constructed, but that happens in C++ and is hidden from gcj. I think
this is similar to saying that the vtable pointer can't change. I had
some example code a few months ago where I assumed gcj would optimize
out a redundant length check, but didn't.