Re: Hash table iterators.
On Mon, Nov 26, 2012 at 9:57 PM, Lawrence Crowl wrote: > On 11/23/12, Andrew MacLeod wrote: >> On 11/22/2012 01:18 PM, Lawrence Crowl wrote: >> > I have found that tree-flow.h implements iteration over htab_t, >> > while there is no current facility to do that with hash_table. >> > Unfortunately, the specific form does not match the standard C++ >> > approach to iterators. We have several choices. >> > >> > (1) Ignore the problem and leave all such tables as htab_t. >> > >> > (2) Write new hash_table iteration functions to match the form of >> > the existing GCC macro/function approach. >> > >> > (3) Write new hash_table iteration functions to match the form used >> > by the C++ standard. This approach would entail modifying the loops. >> > >> > Diego and I have a preference for (3). What do you prefer? >> >> I don't like (1) for sure. >> >> Before deciding a preference between (2) and (3), what are the >> actual differences? ie, is (2) doing something practical that >> (3) has to bend over for, or is (3)'s format better but wasn't >> practical before? is (2) otherwise useful going forward? > > For iterating over a hash table containing elements of type T, > > (2) The for statement is parameterized by an iterator variable and a > variable of type T. The loop copies the element into the T variable, > and that variable is used in the body. > > (3) The for statement is parameterized only by an iterator variable. > The loop uses "*iterator_variable" to obtain a reference to the > element. > > With (3), we have well-established practice for writing generic > algorithms. With (2), we seem to have just for loops. If you view them in isolation, yes. But you can trivially provide the interface of (2) by wrapping over (3). So I'd prefer the implementation to be (3) but (2) be still provided by means of wrapping it (I'd really like to see less C / C++ spaghetti mix in the various passes, not that I like the C++ iterator idiom very much anyway). Btw, my pending loop iterator change attached (no longer applies after the VEC changes). Richard. > -- > Lawrence Crowl loop-iterator-cxx Description: Binary data
Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon
On Tue, Nov 27, 2012 at 1:06 AM, Kenneth Zadeck
wrote:
> Richard,
>
> I spent a good part of the afternoon talking to Mike about this. He is on
> the c++ standards committee and is a much more seasoned c++ programmer than
> I am.
>
> He convinced me that with a large amount of engineering and c++
> "foolishness" that it was indeed possible to get your proposal to POSSIBLY
> work as well as what we did.
>
> But now the question is why would any want to do this?
>
> At the very least you are talking about instantiating two instances of
> wide-ints, one for the stack allocated uses and one for the places where we
> just move a pointer from the tree or the rtx. Then you are talking about
> creating connectors so that the stack allocated functions can take
> parameters of pointer version and visa versa.
>
> Then there is the issue that rather than just saying that something is a
> wide int, that the programmer is going to have to track it's origin. In
> particular, where in the code right now i say.
>
> wide_int foo = wide_int::from_rtx (r1);
> wide_int bar = wide_int::from_rtx (r2) + foo;
>
> now i would have to say
>
> wide_int_ptr foo = wide_int_ptr::from_rtx (r1);
> wide_int_stack bar = wide_int_ptr::from_rtx (r2) + foo;
No, you'd say
wide_int foo = wide_int::from_rtx (r1);
and the static, non-templated from_rtx method would automagically
return (always!) a "wide_int_ptr" kind. The initialization then would
use the assignment operator that mediates between wide_int and
"wide_int_ptr", doing the copying.
The user should get a 'stack' kind by default when specifying wide_int,
like implemented with
struct wide_int_storage_stack;
struct wide_int_storage_ptr;
template
class wide_int : public storage
{
...
static wide_int from_rtx (rtx);
}
the whole point of the exercise is to make from_rtx and from_tree avoid
the copying (and excessive stack space allocation) for the rvalue case
like in
wide_int res = wide_int::from_rtx (x) + 1;
if you save the result into a wide_int temporary first then you are lost
of course (modulo some magic GCC optimization being able to elide
the copy somehow).
And of course for code like VRP that keeps a lattice of wide_ints to
be able to reduce its footprint by using ptr storage and explicit allocations
(that's a secondary concern, of course). And for VRP to specify that
it needs more than the otherwise needed MAX_INT_MODE_SIZE.
ptr storage would not have this arbitrary limitation, only embedded
storage (should) have.
> then when i want to call some function using a wide_int ref that function
> now must be either overloaded to take both or i have to choose one of the
> two instantiations (presumably based on which is going to be more common)
> and just have the compiler fix up everything (which it is likely to do).
Nope, they'd be
class wide_int ...
{
template
wide_int operator+(wide_int a, wide_int b)
{
return wide_int::plus_worker (a.precision, a. , a.get_storage_ptr (),
b.precision, ...,
b.get_storage_ptr ());
}
> And so what is the payoff:
> 1) No one except the c++ elite is going to understand the code. The rest of
> the community will hate me and curse the ground that i walk on.
Maybe for the implementation - but look at hash-table and vec ... not for
usage certainly.
> 2) I will end up with a version of wide-int that can be used as a medium
> life container (where i define medium life as not allowed to survive a gc
> since they will contain pointers into rtxes and trees.)
> 3) An no clients that actually wanted to do this!!I could use as an
> example one of your favorite passes, tree-vrp. The current double-int
> could have been a medium lifetime container since it has a smaller
> footprint, but in fact tree-vrp converts those double-ints back into trees
> for medium storage. Why, because it needs the other fields of a tree-cst
> to store the entire state. Wide-ints also "suffer" this problem. their
> only state are the data, and the three length fields. They have no type
> and none of the other tree info so the most obvious client for a medium
> lifetime object is really not going to be a good match even if you "solve
> the storage problem".
>
> The fact is that wide-ints are an excellent short term storage class that
> can be very quickly converted into our two long term storage classes. Your
> proposal is requires a lot of work, will not be easy to use and as far as i
> can see has no payoff on the horizon. It could be that there could be
> future clients for a medium lifetime value, but asking for this with no
> clients in hand is really beyond the scope of a reasonable review.
>
> I remind you that the purpose of these patches is to solve problems that
> exist in the current compiler that we have papered over for years. If
> someone needs wide-ints in some way that is not foreseen then they can
> change it.
The patches introduce a lot more temporary wide-int
Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon
i will discuss this with mike when he wakes up.he lives on the west
pole so that will not be until after you go to bed.
the one point that i will take exception to is that the copying
operation is, in practice, any more time expensive than the pointer
copy. I never bother to initialize the storage in the array, i only
copy the elements that are live.This is with almost always 1 hwi
because either most types are small or most constants of large types
compress to 1 hwi.So even if a compilation does a zillion
::from_trees, you will most likely never see the difference in time.
kenny
On 11/27/2012 05:03 AM, Richard Biener wrote:
On Tue, Nov 27, 2012 at 1:06 AM, Kenneth Zadeck
wrote:
Richard,
I spent a good part of the afternoon talking to Mike about this. He is on
the c++ standards committee and is a much more seasoned c++ programmer than
I am.
He convinced me that with a large amount of engineering and c++
"foolishness" that it was indeed possible to get your proposal to POSSIBLY
work as well as what we did.
But now the question is why would any want to do this?
At the very least you are talking about instantiating two instances of
wide-ints, one for the stack allocated uses and one for the places where we
just move a pointer from the tree or the rtx. Then you are talking about
creating connectors so that the stack allocated functions can take
parameters of pointer version and visa versa.
Then there is the issue that rather than just saying that something is a
wide int, that the programmer is going to have to track it's origin. In
particular, where in the code right now i say.
wide_int foo = wide_int::from_rtx (r1);
wide_int bar = wide_int::from_rtx (r2) + foo;
now i would have to say
wide_int_ptr foo = wide_int_ptr::from_rtx (r1);
wide_int_stack bar = wide_int_ptr::from_rtx (r2) + foo;
No, you'd say
wide_int foo = wide_int::from_rtx (r1);
and the static, non-templated from_rtx method would automagically
return (always!) a "wide_int_ptr" kind. The initialization then would
use the assignment operator that mediates between wide_int and
"wide_int_ptr", doing the copying.
The user should get a 'stack' kind by default when specifying wide_int,
like implemented with
struct wide_int_storage_stack;
struct wide_int_storage_ptr;
template
class wide_int : public storage
{
...
static wide_int from_rtx (rtx);
}
the whole point of the exercise is to make from_rtx and from_tree avoid
the copying (and excessive stack space allocation) for the rvalue case
like in
wide_int res = wide_int::from_rtx (x) + 1;
if you save the result into a wide_int temporary first then you are lost
of course (modulo some magic GCC optimization being able to elide
the copy somehow).
And of course for code like VRP that keeps a lattice of wide_ints to
be able to reduce its footprint by using ptr storage and explicit allocations
(that's a secondary concern, of course). And for VRP to specify that
it needs more than the otherwise needed MAX_INT_MODE_SIZE.
ptr storage would not have this arbitrary limitation, only embedded
storage (should) have.
then when i want to call some function using a wide_int ref that function
now must be either overloaded to take both or i have to choose one of the
two instantiations (presumably based on which is going to be more common)
and just have the compiler fix up everything (which it is likely to do).
Nope, they'd be
class wide_int ...
{
template
wide_int operator+(wide_int a, wide_int b)
{
return wide_int::plus_worker (a.precision, a. , a.get_storage_ptr (),
b.precision, ...,
b.get_storage_ptr ());
}
And so what is the payoff:
1) No one except the c++ elite is going to understand the code. The rest of
the community will hate me and curse the ground that i walk on.
Maybe for the implementation - but look at hash-table and vec ... not for
usage certainly.
2) I will end up with a version of wide-int that can be used as a medium
life container (where i define medium life as not allowed to survive a gc
since they will contain pointers into rtxes and trees.)
3) An no clients that actually wanted to do this!!I could use as an
example one of your favorite passes, tree-vrp. The current double-int
could have been a medium lifetime container since it has a smaller
footprint, but in fact tree-vrp converts those double-ints back into trees
for medium storage. Why, because it needs the other fields of a tree-cst
to store the entire state. Wide-ints also "suffer" this problem. their
only state are the data, and the three length fields. They have no type
and none of the other tree info so the most obvious client for a medium
lifetime object is really not going to be a good match even if you "solve
the storage problem".
The fact is that wide-ints are an excellent short term storage class that
can be very quickly converted into our two long term storage classes. Your
propos
Re: Unifying the GCC Debugging Interface
> "Gaby" == Gabriel Dos Reis writes: Richard> Just to add another case which seems to be not covered in the thread. Richard> When dumping from inside a gdb session in many cases I cut&paste Richard> addresses literally. For overloading to work I'd need to write casts Richard> in front of the inferior call argument. That sounds ugly - so at least Richard> keep the old interfaces as well. Or rather for debugging purposes Richard> provide python helpers rather than new inferior overloads. Gaby> this means that we need an improvement from GDB. This Gaby> is not useful only to the small GCC community. It is very useful to Gaby> the wider GDB/C++ user community. There is no way for gdb to do anything about this generically. Richard is talking about a situation like: print overload(0xf) gdb can't know what the user meant here. Maybe it is possible with some application-specific knowledge, for example if you could tell the type of an object from its address. In this case it can be done by gcc, via Python scripts for gdb. Tom
Help with target hook TARGET_INIT_LIBFUNCS
Hello All,
I need some clarification regarding the target hook "TARGET_INIT_LIBFUNCS".
I wanted to replace all the instances of 'memcpy' with '__memcpy'. For
that, i have used the above mentioned target hook with the code as
shown below:
memcpy_libfunc = init_one_libfunc ("__memcpy");
I can see while debugging that function table is getting updated, but
i cannot see this change in the assembly file.
(gdb) p debug_rtx((&default_target_libfuncs)->x_libfunc_table[1])
(symbol_ref:SI ("memcpy") [flags 0x41])
$1 = void
(gdb) n
(gdb) p debug_rtx((&default_target_libfuncs)->x_libfunc_table[1])
(symbol_ref:SI ("__memcpy") [flags 0x41])
Am i missing any other details or is this not the right way to do this?
Regards,
Rohit
Re: Unifying the GCC Debugging Interface
On Sun, Nov 25, 2012 at 8:45 AM, Richard Biener wrote: > Just to add another case which seems to be not covered in the thread. > When dumping from inside a gdb session in many cases I cut&paste > addresses literally. For overloading to work I'd need to write casts > in front of the inferior call argument. That sounds ugly - so at least > keep the old interfaces as well. Or rather for debugging purposes > provide python helpers rather than new inferior overloads. Thanks. I think python helpers would probably be a good idea. I tend to use $nn instead of the numeric values. The $nn variables are typed. Diego.
--enable-gather-detailed-mem-stats broken in trunk?
Lots of errors like the following: -o build/genrecog.o ../../gcc/genrecog.c In file included from ../../gcc/rtl.h:29, from ../../gcc/genoutput.c:92: ../../gcc/vec.h:654: error: default argument missing for parameter 4 of ‘template bool vec_safe_reserve(vec*&, unsigned int, bool, const char*, int, const char*)’ ../../gcc/vec.h:654: error: default argument missing for parameter 5 of ‘template bool vec_safe_reserve(vec*&, unsigned int, bool, const char*, int, const char*)’ ../../gcc/vec.h:654: error: default argument missing for parameter 6 of ‘template bool vec_safe_reserve(vec*&, unsigned int, bool, const char*, int, const char*)’ In file included from ../../gcc/rtl.h:29, from ../../gcc/genemit.c:26: ../../gcc/vec.h:654: error: default argument missing for parameter 4 of ‘template bool vec_safe_reserve(vec*&, unsigned int, bool, const char*, int, const char*)’ ../../gcc/vec.h:654: error: default argument missing for parameter 5 of ‘template bool vec_safe_reserve(vec*&, unsigned int, bool, const char*, int, const char*)’ ../../gcc/vec.h:654: error: default argument missing for parameter 6 of ‘template bool vec_safe_reserve(vec*&, unsigned int, bool, const char*, int, const char*)’ In file included from ../../gcc/rtl.h:29, from ../../gcc/genattrtab.c:111: ../../gcc/vec.h:654: error: default argument missing for parameter 4 of ‘template bool vec_safe_reserve(vec*&, unsigned int, bool, const char*, int, const char*)’ ../../gcc/vec.h:654: error: default argument missing for parameter 5 of ‘template bool vec_safe_reserve(vec*&, unsigned int, bool, const char*, int, const char*)’ ../../gcc/vec.h:654: error: default argument missing for parameter 6 of ‘template bool vec_safe_reserve(vec*&, unsigned int, bool, const char*, int, const char*)’ In file included from ../../gcc/rtl.h:29, from ../../gcc/genautomata.c:112: ../../gcc/vec.h:654: error: default argument missing for parameter 4 of ‘template bool vec_safe_reserve(vec*&, unsigned int, bool, const char*, int, const char*)’ ../../gcc/vec.h:654: error: default argument missing for parameter 5 of ‘template bool vec_safe_reserve(vec*&, unsigned int, bool, const char*, int, const char*)’ ../../gcc/vec.h:654: error: default argument missing for parameter 6 of ‘template bool vec_safe_reserve(vec*&, unsigned int, bool, const char*, int, const char*)’ In file included from ../../gcc/rtl.h:29, Paolo
Re: --enable-gather-detailed-mem-stats broken in trunk?
On Tue, Nov 27, 2012 at 10:15 AM, Paolo Bonzini wrote: > Lots of errors like the following: > > -o build/genrecog.o ../../gcc/genrecog.c > In file included from ../../gcc/rtl.h:29, Oops, I forgot to re-test detailed-memory stats. I'll fix. Diego.
Re: Unifying the GCC Debugging Interface
On Tue, Nov 27, 2012 at 4:06 PM, Diego Novillo wrote: > On Sun, Nov 25, 2012 at 8:45 AM, Richard Biener > wrote: > >> Just to add another case which seems to be not covered in the thread. >> When dumping from inside a gdb session in many cases I cut&paste >> addresses literally. For overloading to work I'd need to write casts >> in front of the inferior call argument. That sounds ugly - so at least >> keep the old interfaces as well. Or rather for debugging purposes >> provide python helpers rather than new inferior overloads. > > Thanks. I think python helpers would probably be a good idea. I tend > to use $nn instead of the numeric values. The $nn variables are > typed. me too, just when you do debug_tree ($1) you then don't have $nn for all of the trees referenced from the output ;) Richard. > > Diego.
Re: Unifying the GCC Debugging Interface
On Tue, Nov 27, 2012 at 10:23 AM, Richard Biener wrote: > me too, just when you do debug_tree ($1) you then don't have $nn for > all of the trees referenced from the output ;) True that :)
RFC - Remove support for PCH post 4.8
I admit that I'm partly fishing here, but my proposal is based on the following: * The implementation of PCH in GCC is atrocious and hard to maintain. * The next C++ standard is likely to define modules (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3347.pdf) * The user-base for PCH is negligibly small (here's where I'm mostly guessing). * PCH is absolutely useless for C. Removing PCH will give us more implementation freedom for the memory management project (http://gcc.gnu.org/wiki/cxx-conversion/gc-alternatives). With some effort, we could revive the streaming work done in the PPH branch and re-implement PCH with it (when we abandoned the branch, we were probably 80% complete as a PCH replacement). If we could at least remove support for C, then I can see a streaming-based PCH for the 4.9 release. Thoughts? Are there any big PCH users out there? Thanks. Diego.
Re: RFC - Remove support for PCH post 4.8
On Nov 27, 2012, at 8:00 AM, Diego Novillo wrote: > I admit that I'm partly fishing here, but my proposal is based on the > following: > > * The implementation of PCH in GCC is atrocious and hard to maintain. > * The next C++ standard is likely to define modules > (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3347.pdf) > * The user-base for PCH is negligibly small (here's where I'm mostly > guessing). > * PCH is absolutely useless for C. PCH is used extensively in Objective-C code and many C++ applications that also build for windows. I'm not sure how important these communities are though... -Chris > > Removing PCH will give us more implementation freedom for the memory > management project > (http://gcc.gnu.org/wiki/cxx-conversion/gc-alternatives). > > With some effort, we could revive the streaming work done in the PPH > branch and re-implement PCH with it (when we abandoned the branch, we > were probably 80% complete as a PCH replacement). If we could at least > remove support for C, then I can see a streaming-based PCH for the 4.9 > release. > > Thoughts? > > Are there any big PCH users out there? > > > Thanks. Diego.
Re: RFC - Remove support for PCH post 4.8
Hi, >Thoughts? Assuming that the new implementation will be available in time for 4.9, my primary concern is that in the meanwhile running the libstdc++ testsuite will be quite noticeably slower. Do you have some numbers? Thanks, Paolo
stupid build error
This: Verify that you have permission to grant a GFDL license for all new text in tm.texi, then copy it to ../../gcc/gcc/doc/tm.texi. make[3]: *** [s-tm-texi] Error 1 make[3]: *** Waiting for unfinished jobs…. is one of the stupidest build errors I've seen all decade. Can someone fix it please?
Re: RFC - Remove support for PCH post 4.8
On Tue, Nov 27, 2012 at 2:48 PM, Paolo Carlini wrote: > Assuming that the new implementation will be available in time for 4.9, my > primary concern is that in the meanwhile running the libstdc++ testsuite > will be quite noticeably slower. Do you have some numbers? No, but I can get them. How do I disable PCH for libstdc++? Diego.
Re: stupid build error
On Tue, Nov 27, 2012 at 12:55 PM, Mike Stump wrote: > This: > > Verify that you have permission to grant a GFDL license for all > new text in tm.texi, then copy it to ../../gcc/gcc/doc/tm.texi. > make[3]: *** [s-tm-texi] Error 1 > make[3]: *** Waiting for unfinished jobs…. > > is one of the stupidest build errors I've seen all decade. Can someone fix > it please? This means someone edited gcc/doc/tm.texi.in and/or gcc/target.def without checking a new version of gcc/doc/tm.texi . This build failure is to make sure we are not violating the rules setup by FSF for the licensing for target.def both GPL and GFDL. Thanks, Andrew Pinski
Re: RFC - Remove support for PCH post 4.8
On Tue, Nov 27, 2012 at 1:22 PM, Diego Novillo wrote: > On Tue, Nov 27, 2012 at 2:48 PM, Paolo Carlini > wrote: > >> Assuming that the new implementation will be available in time for 4.9, my >> primary concern is that in the meanwhile running the libstdc++ testsuite >> will be quite noticeably slower. Do you have some numbers? > > No, but I can get them. How do I disable PCH for libstdc++? --disable-libstdcxx-pch Thanks, Andrew
Re: RFC - Alternatives to gengtype
As a follow up to our proposal to improve memory management in the compiler, we plan to proceed in two parts: * A transition plan to quickly remove gengtype out of the picture. This has become the main blocker for several C++ cleanups. The transition here is to move all the GTY() structures to use user-provided markers. With this, we are pretty sure that we can minimize the role of gengtype to the point that it doesn't need to understand C++. We would keep our current GC and PCH implementations unchanged. This will be ready for the 4.9 release. * Start implementing memory pools for data structures that do not need to be in PCH images. It is still not clear what types of memory pools we will need, but at a minimum we are thinking of a permanent pool, per-pass pools and at least one or two stage-based pools (e.g., front ends). We may be able to have some implemented for the 4.9 release. * As far as PCH is concerned, we are considering 2 alternatives: (a) move to a type streamer based on the work in the PPH branch (http://gcc.gnu.org/wiki/pph), (b) get rid of it completely, as this feature will be obsoleted by C++ modules (http://gcc.gnu.org/ml/gcc/2012-11/msg00468.html). We do not really think that option (b) is advisable until C++ modules are a more concrete reality. Thoughts? Thanks. Diego.
Re: RFC - Remove support for PCH post 4.8
On Tue, Nov 27, 2012 at 2:20 PM, Chris Lattner wrote: > On Nov 27, 2012, at 8:00 AM, Diego Novillo wrote: >> I admit that I'm partly fishing here, but my proposal is based on the >> following: >> >> * The implementation of PCH in GCC is atrocious and hard to maintain. >> * The next C++ standard is likely to define modules >> (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3347.pdf) >> * The user-base for PCH is negligibly small (here's where I'm mostly >> guessing). >> * PCH is absolutely useless for C. > > PCH is used extensively in Objective-C code and many C++ applications that > also build for windows. I'm not sure how important these communities are > though... Ah, thanks. I had forgotten about obj-c. I'm not sure how much usage this feature gets and it doesn't seem like it would be easy to find out (other than do a release without it and wait for the fan mail ;) Diego.
Re: Unifying the GCC Debugging Interface
On Tue, Nov 27, 2012 at 8:54 AM, Tom Tromey wrote: >> "Gaby" == Gabriel Dos Reis writes: > > Richard> Just to add another case which seems to be not covered in the thread. > Richard> When dumping from inside a gdb session in many cases I cut&paste > Richard> addresses literally. For overloading to work I'd need to write casts > Richard> in front of the inferior call argument. That sounds ugly - so at > least > Richard> keep the old interfaces as well. Or rather for debugging purposes > Richard> provide python helpers rather than new inferior overloads. > > Gaby> this means that we need an improvement from GDB. This > Gaby> is not useful only to the small GCC community. It is very useful to > Gaby> the wider GDB/C++ user community. > > There is no way for gdb to do anything about this generically. > Richard is talking about a situation like: > > print overload(0xf) > > gdb can't know what the user meant here. > > Maybe it is possible with some application-specific knowledge, for > example if you could tell the type of an object from its address. > In this case it can be done by gcc, via Python scripts for gdb. > > Tom Thanks for the clarification. -- Gaby
Re: RFC - Alternatives to gengtype
On 11/27/2012 03:51 PM, Diego Novillo wrote: * Start implementing memory pools for data structures that do not need to be in PCH images. It is still not clear what types of memory pools we will need, but at a minimum we are thinking of a permanent pool, per-pass pools and at least one or two stage-based pools (e.g., front ends). We may be able to have some implemented for the 4.9 release. By far the most important aspect of this is defining your pools and their lifetimes properly. If you're not careful, this will end up like the old obstack mess we had in the past. I don't want to discourage the work, but we need to think carefully and get it right. Jeff
Re: RFC - Remove support for PCH post 4.8
> I admit that I'm partly fishing here, but my proposal is based on the > following: > > * The implementation of PCH in GCC is atrocious and hard to maintain. > * The next C++ standard is likely to define modules > (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3347.pdf) > * The user-base for PCH is negligibly small (here's where I'm mostly > guessing). * PCH is absolutely useless for C. > > Removing PCH will give us more implementation freedom for the memory > management project > (http://gcc.gnu.org/wiki/cxx-conversion/gc-alternatives). One of the arguments put forward to advocate the transition to C++ was the competition. Where do the other compilers stand when it comes to PCHs? -- Eric Botcazou
Re: RFC - Alternatives to gengtype
On Tue, Nov 27, 2012 at 6:20 PM, Jeff Law wrote: > On 11/27/2012 03:51 PM, Diego Novillo wrote: >>> >>> * Start implementing memory pools for data structures that do not need >> >> to be in PCH images. It is still not clear what types of memory pools >> we will need, but at a minimum we are thinking of a permanent pool, >> per-pass pools and at least one or two stage-based pools (e.g., front >> ends). We may be able to have some implemented for the 4.9 release. > > By far the most important aspect of this is defining your pools and their > lifetimes properly. If you're not careful, this will end up like the old > obstack mess we had in the past. Right. That's why we want to be very conservative in this plan. We want to be able to move data structures incrementally and keep the current GC mechanism working at the same time. We would only merge back into trunk once we have a solid transition. Diego.
Re: RFC - Remove support for PCH post 4.8
On Tue, Nov 27, 2012 at 6:32 PM, Eric Botcazou wrote: > One of the arguments put forward to advocate the transition to C++ was the > competition. Where do the other compilers stand when it comes to PCHs? Note that although we are doing this in the umbrella of the C++ transition, this is actually orthogonal to it. For feature-parity, we will want to maintain the feature. C++ now gives us a slightly-easier implementation strategy for streamable types. Diego.
Re: RFC - Remove support for PCH post 4.8
On Nov 27, 2012, at 3:32 PM, Eric Botcazou wrote: >> I admit that I'm partly fishing here, but my proposal is based on the >> following: >> >> * The implementation of PCH in GCC is atrocious and hard to maintain. >> * The next C++ standard is likely to define modules >> (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3347.pdf) >> * The user-base for PCH is negligibly small (here's where I'm mostly >> guessing). * PCH is absolutely useless for C. >> >> Removing PCH will give us more implementation freedom for the memory >> management project >> (http://gcc.gnu.org/wiki/cxx-conversion/gc-alternatives). > > One of the arguments put forward to advocate the transition to C++ was the > competition. Where do the other compilers stand when it comes to PCHs? Clang has fantastic support for PCH... and soon modules. We don't plan to drop PCH support when modules is implemented. -Chris
Re: stupid build error
On Nov 27, 2012, at 1:22 PM, Andrew Pinski wrote: > On Tue, Nov 27, 2012 at 12:55 PM, Mike Stump wrote: >> This: >> >> Verify that you have permission to grant a GFDL license for all >> new text in tm.texi, then copy it to ../../gcc/gcc/doc/tm.texi. >> make[3]: *** [s-tm-texi] Error 1 >> make[3]: *** Waiting for unfinished jobs…. >> >> is one of the stupidest build errors I've seen all decade. Can someone fix >> it please? > > This means someone edited gcc/doc/tm.texi.in and/or gcc/target.def > without checking a new version of gcc/doc/tm.texi . > This build failure is to make sure we are not violating the rules > setup by FSF for the licensing for target.def both GPL and GFDL. A review of the change and approval of the change should be enough to catch issues going into the FSF tree. The build should just copy the generated file to the source tree, if changed. The build failed for me, which is wrong, as there if absolutely no change I can make that runs afoul of copyright law, save copying in content for which would be a violation, which is completely uncatchable, so, there is absolutely no way to check for this failure and absolutely every other failure is a false positive, so, again, let me state that the check is wrong. What ever condition people are trying to catch, how they did it is wrong. I mean, we could have a check that fails the build if any source file has been modified. This would catch all new copyright volitions with probability 1; however, we don't do that? Why? Simple, too many false positives. By changing a file, you assert are doing so in a manner consist with law, and that is that. Once so asserted, there _can be_ no non-false positives, ever.
Re: stupid build error
On Tue, 27 Nov 2012, Mike Stump wrote: > A review of the change and approval of the change should be enough to > catch issues going into the FSF tree. The build should just copy the > generated file to the source tree, if changed. The build failed for me, The rule from the FSF is that tm.texi is treated more like a source file than a generated file, because no actual dual-licensing notice for target.def could be produced (if it could, we wouldn't need a checked-in tm.texi at all - checked-in generated files are only for cases where they are needed in the bootstrap process or to reduce the external dependencies for a build). Someone can write new text and put it in both places for licensing in each source file under its respective license - the makefile rules are providing a tool to assist someone choosing to do so and so ensure that the source files target.def, tm.texi.in, tm.texi are kept in sync in a way that we wish to keep them in sync. Or someone can copy existing doc strings from tm.texi to target.def, or from comments to both target.def and tm.texi, keeping the three files in sync in the desired way, but with approval for the patch from one of the docstring relicensing maintainers being required in that case. Thus, the makefile rules are not rules for updating a generated file in the usual sense - they are rules to assist developers, who have made a conscious decision to put the same text in multiple source files under different licenses, in making changes to those multiple source files in sync with each other. Perhaps the error message should be phrased differently to make clear that it is about the three source files not being in sync with each other. -- Joseph S. Myers jos...@codesourcery.com
Re: RFC - Remove support for PCH post 4.8
On Tue, Nov 27, 2012 at 4:11 PM, Chris Lattner wrote: > > On Nov 27, 2012, at 3:32 PM, Eric Botcazou wrote: > >>> I admit that I'm partly fishing here, but my proposal is based on the >>> following: >>> >>> * The implementation of PCH in GCC is atrocious and hard to maintain. >>> * The next C++ standard is likely to define modules >>> (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3347.pdf) >>> * The user-base for PCH is negligibly small (here's where I'm mostly >>> guessing). * PCH is absolutely useless for C. >>> >>> Removing PCH will give us more implementation freedom for the memory >>> management project >>> (http://gcc.gnu.org/wiki/cxx-conversion/gc-alternatives). >> >> One of the arguments put forward to advocate the transition to C++ was the >> competition. Where do the other compilers stand when it comes to PCHs? > > Clang has fantastic support for PCH... and soon modules. Are they sharing some implementations? David >We don't plan to drop PCH support when modules is implemented. > > -Chris
Re: stupid build error
On Nov 27, 2012, at 4:50 PM, "Joseph S. Myers" wrote: > On Tue, 27 Nov 2012, Mike Stump wrote: > >> A review of the change and approval of the change should be enough to >> catch issues going into the FSF tree. The build should just copy the >> generated file to the source tree, if changed. The build failed for me, > > The rule from the FSF is that tm.texi is treated more like a source file > than a generated file, because no actual dual-licensing notice for > target.def could be produced (if it could, we wouldn't need a checked-in > tm.texi at all - checked-in generated files are only for cases where they > are needed in the bootstrap process or to reduce the external dependencies > for a build). Someone can write new text and put it in both places for > licensing in each source file under its respective license - the makefile > rules are providing a tool to assist someone choosing to do so and so > ensure that the source files target.def, tm.texi.in, tm.texi are kept in > sync in a way that we wish to keep them in sync. Or someone can copy > existing doc strings from tm.texi to target.def, or from comments to both > target.def and tm.texi, keeping the three files in sync in the desired > way, but with approval for the patch from one of the docstring relicensing > maintainers being required in that case. > > Thus, the makefile rules are not rules for updating a generated file in > the usual sense - they are rules to assist developers, who have made a > conscious decision to put the same text in multiple source files under > different licenses, in making changes to those multiple source files in > sync with each other. > > Perhaps the error message should be phrased differently to make clear that > it is about the three source files not being in sync with each other. You failed to state a single case where a violation is caught. Do that now, I'll wait. If I modify the tree in a way that the generated tm.texi file changes, and that file is copied into the source tree, and I distribute it, then, there are only two cases to consider, either, I did that in violation of the copyright law, or I did not. If I did, then, exactly how the law is violated is beyond the grasp of software, or I did not, and in that case, there is no aide to me for failing the build. You're under the mistaken idea that you can write software to catch violations of law, stop. You cannot. Failing the build because I merely _changed_ the software is _not_ an indication of a violation of law is about to take place. If you want to argue that it is possible to catch a violation of law, go for it. For the counter proof, there can be no violation of law, without a copy, or, say, a distribution. I'm not going to distribute, therefore, there can be no violation of law, QED. All failures from any development I might undertake that fail the build in this way, are _always_ false positives. Please fix all false positives.
Re: stupid build error
On Tue, 27 Nov 2012, Mike Stump wrote: > You failed to state a single case where a violation is caught. It's not about catching violations of law, it's about catching cases where the source tree is in an inconsistent state. And a not uncommon cause of that is that someone didn't know about the relation between the three source files, target.def, tm.texi.in and tm.texi, and modified tm.texi directly, or modified multiple files by hand inconsistently. (Although the code attempts to use timestamps to distinguish different cases of inconsistency, this can be unreliable, especially if someone checked in an inconsistent state and someone else is building from a tree updated with svn update. So the rule is that in any case of an inconsistency in the source tree, things are passed back to the user to make a determination, based on examining the differences, of how to restore consistency to the source tree - and of whether the resulting patch submission will need docstring relicensing review.) -- Joseph S. Myers jos...@codesourcery.com
Re: RFC - Remove support for PCH post 4.8
On Nov 27, 2012, at 5:16 PM, Xinliang David Li wrote: Removing PCH will give us more implementation freedom for the memory management project (http://gcc.gnu.org/wiki/cxx-conversion/gc-alternatives). >>> >>> One of the arguments put forward to advocate the transition to C++ was the >>> competition. Where do the other compilers stand when it comes to PCHs? >> > >> Clang has fantastic support for PCH... and soon modules. > > Are they sharing some implementations? Yes, absolutely. In the GCC terminology, both use a "streaming" approach for writing out code, and a lot of the mechanics of that streaming logic are similar. Modules adds a bunch of additional logic on top of what PCH uses though. -Chris
Re: RFC - Remove support for PCH post 4.8
Chris Lattner writes: > Clang has fantastic support for PCH... and soon modules. We don't > plan to drop PCH support when modules is implemented. Do you have a pointer to the modules proposal clang will implement? Thanks, -miles -- 「寒いね」と話しかければ「寒いね」と答える人のいるあったかさ [俵万智]
Re: RFC - Remove support for PCH post 4.8
On Nov 27, 2012, at 9:08 PM, Miles Bader wrote: > Chris Lattner writes: >> Clang has fantastic support for PCH... and soon modules. We don't >> plan to drop PCH support when modules is implemented. > > Do you have a pointer to the modules proposal clang will implement? Most of it is implemented in mainline Clang already. Here is a recent talk describing it: http://llvm.org/devmtg/2012-11/Gregor-Modules.pdf Doug is also the chair of the C++ working group on modules, leading the effort to standardize it (along with Lawrence and others). -Chris
Re: RFC - Remove support for PCH post 4.8
On Tue, Nov 27, 2012 at 10:40 PM, Chris Lattner wrote: > > On Nov 27, 2012, at 9:08 PM, Miles Bader wrote: > >> Chris Lattner writes: >>> Clang has fantastic support for PCH... and soon modules. We don't >>> plan to drop PCH support when modules is implemented. >> >> Do you have a pointer to the modules proposal clang will implement? > > Most of it is implemented in mainline Clang already. For Object-C or C++? >Here is a recent talk describing it: > http://llvm.org/devmtg/2012-11/Gregor-Modules.pdf > It is likely that the module file format will be standardized in the future, so it is better for different communities to start move in the same direction. Is the module format adopted by Clang documented anywhere? thanks, David > Doug is also the chair of the C++ working group on modules, leading the > effort to standardize it (along with Lawrence and others). > > -Chris >
Re: RFC - Remove support for PCH post 4.8
On Nov 27, 2012, at 11:05 PM, Xinliang David Li wrote: > On Tue, Nov 27, 2012 at 10:40 PM, Chris Lattner wrote: >> >> On Nov 27, 2012, at 9:08 PM, Miles Bader wrote: >> >>> Chris Lattner writes: Clang has fantastic support for PCH... and soon modules. We don't plan to drop PCH support when modules is implemented. >>> >>> Do you have a pointer to the modules proposal clang will implement? >> >> Most of it is implemented in mainline Clang already. > > For Object-C or C++? C and Objective-C are nearly complete, C++ support is still in progress. > >> Here is a recent talk describing it: >> http://llvm.org/devmtg/2012-11/Gregor-Modules.pdf >> > > It is likely that the module file format will be standardized in the > future, so it is better for different communities to start move in the > same direction. Is the module format adopted by Clang documented > anywhere? No, the design does not require a binary compatible file format. Header files and module maps remain "the truth". Any binary file format produced by a compiler as a side effect of building is an implementation detail of that compiler. -Chris
Re: RFC - Remove support for PCH post 4.8
What you described is the 'transitional model' right? but I don't see any of those in the C++ standard working paper: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3347.pdf David On Tue, Nov 27, 2012 at 11:07 PM, Chris Lattner wrote: > > On Nov 27, 2012, at 11:05 PM, Xinliang David Li wrote: > >> On Tue, Nov 27, 2012 at 10:40 PM, Chris Lattner wrote: >>> >>> On Nov 27, 2012, at 9:08 PM, Miles Bader wrote: >>> Chris Lattner writes: > Clang has fantastic support for PCH... and soon modules. We don't > plan to drop PCH support when modules is implemented. Do you have a pointer to the modules proposal clang will implement? >>> >>> Most of it is implemented in mainline Clang already. >> >> For Object-C or C++? > > C and Objective-C are nearly complete, C++ support is still in progress. > >> >>> Here is a recent talk describing it: >>> http://llvm.org/devmtg/2012-11/Gregor-Modules.pdf >>> >> >> It is likely that the module file format will be standardized in the >> future, so it is better for different communities to start move in the >> same direction. Is the module format adopted by Clang documented >> anywhere? > > No, the design does not require a binary compatible file format. Header > files and module maps remain "the truth". Any binary file format produced by > a compiler as a side effect of building is an implementation detail of that > compiler. > > -Chris
