mutable members in global const objects

[Nathan Sidwell <nathan at cs dot bris dot ac dot uk>]

Hi,
Previously I reported a problem about mutable members in static const
objects (http://www.cygnus.com/ml/egcs-bugs/1998-Jul/0346.html). The
problem being that g++ can place these in the read only data section
(rodata).

I've investigated the code, which resides in varasm.c
(variable_section). Unfortunately, the inner workings of this function
is obscured somewhat by the macro SELECT_SECTION, which does the work,
and is itself defined in one of the config files (in my case
gcc/config/sparc/sparc.h). There are about a dozen architecture config
files which define SELECT_SECTION, but I think all these have the same
overall structure and behave the same way with regards to the mutable
problem. What SELECT_SECTION does for a VAR_DECL of a const object is
see if the initialization is simple enough to be a compile time constant
and then bung it in the const data section. If initialization is more
complicated (via a ctor, or some other cases), the object is placed in
the data section. No check is made to see if the object has mutable
members. There is a comment in variable_section about the initialization
by ctor, but no mention of mutables.

To solve the problem there appears to be several solutions,
1) In SELECT_SECTION look to see if the object is of class type, and
recursively descend it looking for mutable members. If (at least) one is
found, place the object in the data section.
2) Add a new flag to the tree_common structure which indicates that a
class type contains a mutable member (or has a member which contains
mutable member, ...). This can be set somewhere in decl.c I guess.
3) Force TREE_CONSTANT() to be false for initializations of objects with
mutable members.

For options 1 and 2, each definition of SELECT_SECTION needs updating to
invoke whichever test is used. Option 3 might have deleterious effects
of which I am unaware. All of these alternatives look like big changes
to me, which I do not feel qualified to do. gcc/tree.h has a comment
about tree_common saying
	DO NOT change the layout of tree_common unless absolutely 			necessary.
I take that as a bit of a hint to stay clear! It's also not clear that
that's the right place to put the new flag. If option 3 is chosen the
test must be recursive, so it'd still be better to have some (language
specific?) flag in tree_type indicating the presence of mutables, so the
equivalent of option 2 must be implemented in some manner.

It occurs to me that some optimizations might need to know about the
presence of mutable members too, though I think it sufficient for them
to know only when they access the mutable member itself (and that of
course is indicated in the member's declaration).

In summary, I'm not familiar enough with the internals of g++ to have a
go at it. I would, however, be willing to have a go at option 3 and
adding a language specific flag to tree_type, if someone could offer
some guidance on how to proceed.

nathan
-- 
Dr Nathan Sidwell :: Computer Science Department :: Bristol University
      You can up the bandwidth, but you can't up the speed of light      
nathan@acm.org  http://www.cs.bris.ac.uk/~nathan/  nathan@cs.bris.ac.uk