------- Additional Comments From jakub at gcc dot gnu dot org 2005-02-21 12:43
-------
Patch here: <http://gcc.gnu.org/ml/gcc-patches/2005-02/msg01138.html>
Mark's request: <http://gcc.gnu.org/ml/gcc-patches/2005-02/msg01162.html>
Unfortunately, I'm afraid I don't know the C++ frontend enough to handle that.
TREE_READONLY flag is set in code common to C/C++, c_apply_type_quals_to_decl.
For C/ObjC, we know that the type will never have TYPE_NEEDS_CONSTRUCTING,
so it is fine that way, but for C++ if the type is not yet complete
at the c_apply_type_quals_to_decl (for C++ this is the usual case), we might
set TREE_READONLY flag prematurely and the type when completed might have
TYPE_NEEDS_CONSTRUCTING.
Now, if we want to avoid setting it until we know it doesn't need constructing,
we could e.g. wrap c_apply_type_quals_to_decl into cp_apply_type_quals_to_decl
that will avoid marking it TREE_READONLY if the type is not yet complete and
in say complete_vars and cp_finish_decl mark it readonly if cp_type_quals (type)
& TYPE_QUAL_CONST and !TYPE_NEEDS_CONSTRUCTING (type). Unfortunately, e.g.
split_nonconstant_init clears this flag even for vars that don't have
TYPE_NEEDS_CONSTRUCTNG set, so if we did that, we'd suddenly change the variable
back to have TREE_READONLY set while it should have it set.
--
What |Removed |Added
----------------------------------------------------------------------------
CC| |jason at redhat dot com,
| |mark at codesourcery dot com
AssignedTo|jakub at gcc dot gnu dot org|unassigned at gcc dot gnu
| |dot org
Status|ASSIGNED |NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20073
