* GTY and const
@ 2004-12-14 7:00 Matt Kraai
2004-12-14 10:30 ` Steven Bosscher
2004-12-14 18:35 ` Zack Weinberg
0 siblings, 2 replies; 12+ messages in thread
From: Matt Kraai @ 2004-12-14 7:00 UTC (permalink / raw)
To: gcc
Howdy,
One of the warnings that causes PR 18176 is an assignment of a const
cpp_token * to the source member of the val union of the cpp_token
structure, which is not const. According to the uses I've found, this
member could be const, except that doing so causes warnings in
gtype-desc.c, which does not preserve the const qualifier.
Would it be better to add a cast around the assignment or to make the
GTY code handle const members?
--
Matt
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: GTY and const
2004-12-14 7:00 GTY and const Matt Kraai
@ 2004-12-14 10:30 ` Steven Bosscher
2004-12-14 18:35 ` Zack Weinberg
1 sibling, 0 replies; 12+ messages in thread
From: Steven Bosscher @ 2004-12-14 10:30 UTC (permalink / raw)
To: gcc; +Cc: Matt Kraai
On Monday 13 December 2004 21:30, Matt Kraai wrote:
> Would it be better to add a cast around the assignment or to make the
> GTY code handle const members?
I'd go for the cast.
Gr.
Steven
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: GTY and const
2004-12-14 7:00 GTY and const Matt Kraai
2004-12-14 10:30 ` Steven Bosscher
@ 2004-12-14 18:35 ` Zack Weinberg
2004-12-21 18:26 ` Geoffrey Keating
1 sibling, 1 reply; 12+ messages in thread
From: Zack Weinberg @ 2004-12-14 18:35 UTC (permalink / raw)
To: Matt Kraai; +Cc: gcc
Matt Kraai <kraai@ftbfs.org> writes:
> Howdy,
>
> One of the warnings that causes PR 18176 is an assignment of a const
> cpp_token * to the source member of the val union of the cpp_token
> structure, which is not const. According to the uses I've found, this
> member could be const, except that doing so causes warnings in
> gtype-desc.c, which does not preserve the const qualifier.
>
> 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.
zw
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: GTY and const
2004-12-14 18:35 ` Zack Weinberg
@ 2004-12-21 18:26 ` Geoffrey Keating
2004-12-21 19:01 ` Zack Weinberg
0 siblings, 1 reply; 12+ messages in thread
From: Geoffrey Keating @ 2004-12-21 18:26 UTC (permalink / raw)
To: Zack Weinberg; +Cc: gcc
Zack Weinberg <zack@codesourcery.com> writes:
> Matt Kraai <kraai@ftbfs.org> writes:
>
> > Howdy,
> >
> > One of the warnings that causes PR 18176 is an assignment of a const
> > cpp_token * to the source member of the val union of the cpp_token
> > structure, which is not const. According to the uses I've found, this
> > member could be const, except that doing so causes warnings in
> > gtype-desc.c, which does not preserve the const qualifier.
> >
> > 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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: GTY and const
2004-12-21 18:26 ` Geoffrey Keating
@ 2004-12-21 19:01 ` Zack Weinberg
2004-12-22 23:11 ` Daniel Berlin
0 siblings, 1 reply; 12+ messages in thread
From: Zack Weinberg @ 2004-12-21 19:01 UTC (permalink / raw)
To: Geoffrey Keating; +Cc: gcc
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.
zw
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: GTY and const
2004-12-21 19:01 ` Zack Weinberg
@ 2004-12-22 23:11 ` Daniel Berlin
2004-12-22 23:24 ` Zack Weinberg
0 siblings, 1 reply; 12+ messages in thread
From: Daniel Berlin @ 2004-12-22 23:11 UTC (permalink / raw)
To: Zack Weinberg; +Cc: Geoffrey Keating, gcc
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.
Right now we GTY/gc allocate a lot of things just so we can mark some
things they may point to.
The fact that we *have* to do this is *bad*.
Roots are roots, whether they occur in GC memory or not.
The requirement that they be in GC memory is just bogus and an artifact
of the way ggc-page marks.
--Dan
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: GTY and const
2004-12-22 23:11 ` Daniel Berlin
@ 2004-12-22 23:24 ` Zack Weinberg
2004-12-23 3:43 ` Geoff Keating
0 siblings, 1 reply; 12+ messages in thread
From: Zack Weinberg @ 2004-12-22 23:24 UTC (permalink / raw)
To: Daniel Berlin; +Cc: Geoffrey Keating, gcc
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.
zw
¹ however, I am still sympathetic to the notion that GC-allocating
everything would be a good idea if we could just get a non-sucky GC
algorithm. Remember that glorious time in the 3.1-3.3 timeframe when
we never had use-after-free bugs?
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: GTY and const
2004-12-22 23:24 ` Zack Weinberg
@ 2004-12-23 3:43 ` Geoff Keating
2004-12-23 5:15 ` Zack Weinberg
0 siblings, 1 reply; 12+ messages in thread
From: Geoff Keating @ 2004-12-23 3:43 UTC (permalink / raw)
To: Zack Weinberg; +Cc: Daniel Berlin, gcc
[-- Attachment #1: Type: text/plain, Size: 1649 bytes --]
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.]
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2410 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: GTY and const
2004-12-23 3:43 ` Geoff Keating
@ 2004-12-23 5:15 ` Zack Weinberg
2004-12-23 5:39 ` Daniel Berlin
0 siblings, 1 reply; 12+ messages in thread
From: Zack Weinberg @ 2004-12-23 5:15 UTC (permalink / raw)
To: Geoff Keating; +Cc: Daniel Berlin, gcc
Geoff Keating <geoffk@geoffk.org> writes:
> 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:
>> 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.
Sure; however, that happens behind the back of the code that uses this
data structure. The 'const' is correctly placed to catch bugs in that
code, which is what I care about.
> [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.]
I think Dan wants to be able to dynamically declare roots which are
somewhere in malloc space, or something like that.
zw
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: GTY and const
2004-12-23 5:15 ` Zack Weinberg
@ 2004-12-23 5:39 ` Daniel Berlin
0 siblings, 0 replies; 12+ messages in thread
From: Daniel Berlin @ 2004-12-23 5:39 UTC (permalink / raw)
To: Zack Weinberg; +Cc: Geoff Keating, gcc
On Wed, 2004-12-22 at 21:06 -0800, Zack Weinberg wrote:
> Geoff Keating <geoffk@geoffk.org> writes:
>
> > 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:
> >> 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.
>
> Sure; however, that happens behind the back of the code that uses this
> data structure. The 'const' is correctly placed to catch bugs in that
> code, which is what I care about.
>
> > [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.]
>
> I think Dan wants to be able to dynamically declare roots which are
> somewhere in malloc space, or something like that.
Yes.
>
> zw
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: GTY and const
2004-12-23 17:09 ` Lucas (a.k.a T-Bird or bsdfan3)
2004-12-23 20:04 ` Robert Dewar
@ 2004-12-24 2:32 ` Marc Espie
1 sibling, 0 replies; 12+ messages in thread
From: Marc Espie @ 2004-12-24 2:32 UTC (permalink / raw)
To: gcc
In article <41CAF9EF.2030404@cox.net> you write:
>Why can't we use the Boehm's GC for all of GCC? It's already
>distributed with GCC and we already use it for the Java runtime.
>Lucas
The java runtime is one of those things that break on a lot of
platforms. Okay, I'm biased, maybe not a lot. But at least on
OpenBSD i386, I haven't been able to get most java runtime tests
to run: boehm-gc doesn't work with dynamic libraries for us.
I don't know why, and I haven't had time to find out.
boehm-gc needs very specific support for each processor, each OS.
I've read through parts of it, it's really not simple code, a real
maze of a mess of #ifdef. the current gc used by gcc is,
comparatively, very easy to work with. And it works on most everything,
as there are degraded versions of it that demand very little where the
OS suppport is concerned.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: GTY and const
2004-12-23 17:09 ` Lucas (a.k.a T-Bird or bsdfan3)
@ 2004-12-23 20:04 ` Robert Dewar
2004-12-24 2:32 ` Marc Espie
1 sibling, 0 replies; 12+ messages in thread
From: Robert Dewar @ 2004-12-23 20:04 UTC (permalink / raw)
To: Lucas (a.k.a T-Bird or bsdfan3); +Cc: gcc, Zack Weinberg, dberlin, geoffk
Lucas (a.k.a T-Bird or bsdfan3) wrote:
> Why can't we use the Boehm's GC for all of GCC? It's already
> distributed with GCC and we already use it for the Java runtime.
> Lucas
> Zack Weinberg wrote:
For the record, you cannot use BGC for the GNAT compiler itself
because it uses virtual origin addressing which is incompatible
with the BGC approach. In terms of the run time library, I think
everything should work except the g-table and g-dyntab units which
also use virtual addressing.
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2004-12-24 0:26 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-12-14 7:00 GTY and const Matt Kraai
2004-12-14 10:30 ` Steven Bosscher
2004-12-14 18:35 ` Zack Weinberg
2004-12-21 18:26 ` Geoffrey Keating
2004-12-21 19:01 ` Zack Weinberg
2004-12-22 23:11 ` Daniel Berlin
2004-12-22 23:24 ` Zack Weinberg
2004-12-23 3:43 ` Geoff Keating
2004-12-23 5:15 ` Zack Weinberg
2004-12-23 5:39 ` Daniel Berlin
[not found] <1103776856.24215.ezmlm@gcc.gnu.org>
2004-12-23 17:09 ` Lucas (a.k.a T-Bird or bsdfan3)
2004-12-23 20:04 ` Robert Dewar
2004-12-24 2:32 ` Marc Espie
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).