This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Avoid setting MEM_READONLY_P on decls that are not really read-only (PR regression/19813) (take 2)

On Sun, Feb 20, 2005 at 09:32:12AM -0800, Mark Mitchell wrote:
> I don't think the C++ changes are as correct as they could be.
> The fact that we're now clearing TREE_READONLY suggests that we set it 
> at some point in the past.  But, it wasn't correct to set it, since the 
> declaration wasn't really read-only, and if the C++ front end itself in 
> any way (now or in future) were to rely on the incorrect setting, we 
> could run into problems.
> Jakub, would you please find where the flag is getting set, and avoid 
> setting it if either (a) !COMPLETE_TYPE_P (TREE_TYPE (decl)), or (b) 
> TYPE_NEEDS_CONSTRUCTING (TREE_TYPE (decl))?  Then, where the type gets 
> completed, in complete_vars, you'd need to set the flag affirmatively 
> when the object really does turn out to be readonly.

It is set by c_apply_type_quals_to_decl in c-common.c.
But checking there for COMPLETE_TYPE wouldn't help the C/ObjC frontends
where we know the frontend will never set that flag and therefore
don't need to wait until the type is complete.

So one option would be perhaps to add cp_apply_type_quals_to_decl
wrapper that would mask off TYPE_QUAL_CONST if the type is not complete
and then find out places where the C frontend will certainly see the
decl's again already when the type is already complete and set
the readonly flag there if cp_type_quals () & TYPE_QUAL_CONST


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]