GTY and const

[Geoff Keating]

On 22/12/2004, at 3:10 PM, Zack Weinberg wrote:

> Daniel Berlin <dberlin@dberlin.org> writes:
>
>> On Tue, 2004-12-21 at 11:01 -0800, Zack Weinberg wrote:
>>> Geoffrey Keating <geoffk@geoffk.org> writes:
>>>
>>>>>> Would it be better to add a cast around the assignment or to make
>>>>>> the GTY code handle const members?
>>>>>
>>>>> I'd prefer that you improved gengtype.
>>>>
>>>> It's not gengtype, the problem really is that you cannot have const
>>>> GCed memory, for the same underlying reasons that you cannot free() 
>>>> a
>>>> const pointer.
>>>
>>> No, that's just plain not true.  cpplib makes extensive use of 
>>> 'const'
>>> to indicate write-once data structures (they are initialized through 
>>> a
>>> non-const pointer, of course).  Those definitely can be GC memory.
>>
>> Right. There is a significant difference between what we need to walk
>> for marking, and what we really need to GC allocate.
>
> While what you say is true¹, this particular data structure needs to be
> in GC memory not because it can point to other things that are in GC
> memory, but because it's part of a precompiled header.

And, as a consequence of this, these data structures are not truly 
write-once; any pointers contained in them will be changed by saving a 
PCH.

[I think I disagree with Dan's statement, but I'm not sure what he 
means by "GC allocate".  Certainly all roots need to be under control 
of the GC machinery.  Equally certainly, not all roots need to be in 
memory that can be freed, and there are two obvious counterexamples in 
the current compiler, static variables and PCH files.]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2410 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc/attachments/20041223/06644946/attachment.p7s>