Re: RFC - Remove support for PCH post 4.8
On 28 November 2012 07:36, Xinliang David Li wrote: > 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 It's far too early for anything to have been voted into the working paper, that doesn't change the fact there's a WG21 study group, chaired by Doug, working on modules. See http://isocpp.org/std/the-committee
Re: RFC - Remove support for PCH post 4.8
On 11/27/2012 04:00 PM, Diego Novillo wrote: > Are there any big PCH users out there? Yes, lots. We certainly need it to make OpenJDK builds tolerable. It was quite a lot of work to reorganize the build to use it, but very worthwhile. Andrew.
Re: RFC - Alternatives to gengtype
On Wed, Nov 28, 2012 at 12:48 AM, Diego Novillo wrote: > 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. Note that I don't think that non-GC is inherently better than GC. In fact, using a GC leads to easier maintainable code. The fact that we are more memory hungry than necessary (and also maybe consume more compile-time than necessary) is because our GC isn't exactly using technology known for 25 years (generational and copying collection come to my mind). So - I don't want to discourage your work but I think the cycles trying to "remove" GC are better spent elsewhere. For example in solving real problems, like debug info for LTO. Thanks anyway, Richard.
Re: RFC - Alternatives to gengtype
On Wed, Nov 28, 2012 at 11:30:32AM +0100, Richard Biener wrote:
>
> Note that I don't think that non-GC is inherently better than GC. In fact,
> using a GC leads to easier maintainable code. The fact that we are more
> memory hungry than necessary (and also maybe consume more compile-time
> than necessary) is because our GC isn't exactly using technology known
> for 25 years (generational and copying collection come to my mind).
I definitely agree with that. And FWIW,
MELT (http://gcc-melt.org/ has since its beginning a generational
copying garbage collector above ggc+gengtype, so that is definitely doable.
I would wish that GCC systematically used a generational copying GC scheme.
However, this requires that the GCC community agree with that goal (and
apparently,
most - or some - people want on the contrary to get rid of GC).
FWIW, C++ may help in having a manageable copying GC inside GCC,
provided every GCC contributor agree with it. (The hard point is that
garbage collection deals with a global -non-modular- property of
the GCC program -liveness of data-, so it is not feasible to introduce
a generational copying GC progressively or incrementally).
What a precise copying generational GC needs to know is all
the local (and global) variables containing GC-managed pointer data.
The important word is *all*, and that means that everyone should agree to
use it.
We could for instance have a template for every garbage collector local
pointer,
and declare everywhere locals like
gclocal pt1, pt2;
gclocal pg;
we could also have them handled by a preprocessor (à la gengtype) and make that
something like
GCLOCAL(tree pt1, pt2);
GCLOCAL(gimple pg);
Introducing a copying generational scheme would involve perhaps a bigger effort
than the vec.h transition, because a lot of GCC source files would have to be
somehow modified.
(there is an economical & social issue here: who is brave enough to spend time
to work on that?
Few people could take the risk to experiment that if an agreement on GC cannot
be reached)
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: RFC - Alternatives to gengtype
On Wed, Nov 28, 2012 at 11:54 AM, Basile Starynkevitch
wrote:
> On Wed, Nov 28, 2012 at 11:30:32AM +0100, Richard Biener wrote:
>>
>> Note that I don't think that non-GC is inherently better than GC. In fact,
>> using a GC leads to easier maintainable code. The fact that we are more
>> memory hungry than necessary (and also maybe consume more compile-time
>> than necessary) is because our GC isn't exactly using technology known
>> for 25 years (generational and copying collection come to my mind).
>
>
> I definitely agree with that. And FWIW,
> MELT (http://gcc-melt.org/ has since its beginning a generational
> copying garbage collector above ggc+gengtype, so that is definitely doable.
>
> I would wish that GCC systematically used a generational copying GC scheme.
> However, this requires that the GCC community agree with that goal (and
> apparently,
> most - or some - people want on the contrary to get rid of GC).
>
> FWIW, C++ may help in having a manageable copying GC inside GCC,
> provided every GCC contributor agree with it. (The hard point is that
> garbage collection deals with a global -non-modular- property of
> the GCC program -liveness of data-, so it is not feasible to introduce
> a generational copying GC progressively or incrementally).
>
> What a precise copying generational GC needs to know is all
> the local (and global) variables containing GC-managed pointer data.
> The important word is *all*, and that means that everyone should agree to
> use it.
>
> We could for instance have a template for every garbage collector local
> pointer,
> and declare everywhere locals like
>gclocal pt1, pt2;
>gclocal pg;
> we could also have them handled by a preprocessor (ą la gengtype) and make
> that something like
>GCLOCAL(tree pt1, pt2);
>GCLOCAL(gimple pg);
>
> Introducing a copying generational scheme would involve perhaps a bigger
> effort than the vec.h transition, because a lot of GCC source files would
> have to be somehow modified.
> (there is an economical & social issue here: who is brave enough to spend
> time to work on that?
> Few people could take the risk to experiment that if an agreement on GC
> cannot be reached)
We don't need to track local pointers at all as our garbage collection points
are manually chosen (which is probably a very good thing). For a copying
collector all we need is to get rid of the hacks to not mark thing for the
walkers (with GTY((skip))) to improve marking performance because we
know it's referenced from elsewhere. We'd need to instead use a new
GTY((skip-for-marking)) but still consider the reference when copying.
Btw, memory usage improvements by using a copying collector
can be estimated by looking at (or enhancing) our GC statistics.
Btw, I doubt non-GC pools will do better memory-usage wise - they might
improve performance (no collecting) at the cost of a maintainance overhead.
Richard.
> Regards.
>
> --
> Basile STARYNKEVITCH http://starynkevitch.net/Basile/
> email: basilestarynkevitchnet mobile: +33 6 8501 2359
> 8, rue de la Faiencerie, 92340 Bourg La Reine, France
> *** opinions {are only mines, sont seulement les miennes} ***
Re: RFC - Remove support for PCH post 4.8
Thanks for all the responses, folks. The choice is clear, then. We will not pursue the removal of PCH. We'll attempt to re-structure PCH to use the streaming infrastructure, to make it at least more efficient (we were observing very significant file size gains when we tried it on the PPH branch). Diego.
Re: RFC - Alternatives to gengtype
On Wed, Nov 28, 2012 at 5:30 AM, Richard Biener wrote: > Note that I don't think that non-GC is inherently better than GC. In fact, > using a GC leads to easier maintainable code. I don't think there is a direct relationship, actually. Other, easier to maintain compilers, are quite happy without a GC. I do agree, however, that a bad memory management system leads to maintainability issues. We definitely do not want to fall into the obstack nightmare. We are fully prepared to go about this very carefully. The most important intermediate step to take now is to get gengtype out of the picture. Making use of a couple of C++ facilities, we can make GC marking simpler without requiring ad-hoc GTY markers. In our code base, GC makes for up to 10% of compilation time. We are looking to eliminate this overhead. Additionally, reducing memory consumption is a secondary benefit we are pursuing. > So - I don't want to discourage your work but I think the cycles > trying to "remove" > GC are better spent elsewhere. For example in solving real problems, > like debug info for LTO. Yeah, debug info for LTO also needs fixing. I agree that it would be great if someone worked on that. I'm actually not sure if it's listed in the improvements wiki, perhaps it should be. Diego.
Re: RFC - Alternatives to gengtype
> I don't think there is a direct relationship, actually. Other, easier > to maintain compilers, are quite happy without a GC. I do agree, > however, that a bad memory management system leads to maintainability > issues. We definitely do not want to fall into the obstack nightmare. I agree completely with this. GC can make it easier to write code because you don't have to worry about memory management and, in that sense, it improves maintainablility. But it can make a bug that would previously have taken 10 minutes to be one that takes days of careful work to find because it's now become intermittent. Obstack issues were one of the hardest to debug in the past and that was even though it's a relatively controlled form of "GC" and there were ways, using conditional breakpoints, to get a handle on what was going on.
libstdc++-v3 without exception/exception segments
Hello, I currenty build an arm-elf cross compiler. It is intended to use it together with eCos, a small RTOS. I want to use the C++ compiler and therefore I want to use the libstdc++-v3. Since eCos has no underlying exception support I want to disable all exceptions in the libstdc++-v3. This is possible with the -fno-exceptions flag during compiling the files of this library. However - I was unable to set the enviromental flags and/or configure arguments in such a way, that the libstdc++-v3 library is build with the -fno-exceptions flag. At the moment I use the following enviroment: CXXFLAGS="-fno-exceptions" CFLAGS="-fno-exceptions" and the following configure call /usr/tmp/gcc-4.6.3/configure --target=arm-elf --prefix=/usr/local/arm-elf \ --enable-interwork --enable-multilib --enable-languages="c,c++" \ --enable-target-optspace --with-float=soft --with-newlib \ --with-gnu-as --with-gnu-ld \ --with-gxx-include-dir=/usr/local/arm-elf/include \ -disable-__cxa_atexit --with-gmp=/usr/local/ \ --disable-nls Can you help me figuring out what to change/configure to disable the exceptions or to enable the -fno-exceptions flag for the libstdc++-v3 part? One way is to modify the Makefile.am in the libstdc++-v3/libsupc++ to hardcode the CXXFLAGS. For my feeling however the configure script should evaluate the CXXFLAGS enviroment variable to do this decision. Thank you, Martin Laabs -- Dipl.-Ing. Martin Laabs Technische Universität Dresden Fakultät für Elektrotechnik und Informationstechnik Institut für Nachrichtentechnik, Lehrstuhl Hochfrequenztechnik Tel.: +49 (0)351 463-31918 Fax: +49 (0)351 463-37163 Email: martin.la...@tu-dresden.de smime.p7s Description: S/MIME Cryptographic Signature
Re: libstdc++-v3 without exception/exception segments
This message is inappropirate on this list, which is for discussing development of GCC. For help using or building GCC please use the gcc-help list instead. Please take any follow up to that list, thanks. On 28 November 2012 15:19, Martin Laabs wrote: > Hello, > > I currenty build an arm-elf cross compiler. It is intended to use it > together with eCos, a small RTOS. > I want to use the C++ compiler and therefore I want to use the > libstdc++-v3. Since eCos has no underlying exception support I want to > disable all exceptions in the libstdc++-v3. This is possible with the > -fno-exceptions flag during compiling the files of this library. > However - I was unable to set the enviromental flags and/or configure > arguments in such a way, that the libstdc++-v3 library is build with the > -fno-exceptions flag. > At the moment I use the following enviroment: > > CXXFLAGS="-fno-exceptions" > CFLAGS="-fno-exceptions" > > and the following configure call > > /usr/tmp/gcc-4.6.3/configure --target=arm-elf --prefix=/usr/local/arm-elf \ > --enable-interwork --enable-multilib --enable-languages="c,c++" \ > --enable-target-optspace --with-float=soft --with-newlib \ > --with-gnu-as --with-gnu-ld \ > --with-gxx-include-dir=/usr/local/arm-elf/include \ > -disable-__cxa_atexit --with-gmp=/usr/local/ \ > --disable-nls > > Can you help me figuring out what to change/configure to disable the > exceptions or to enable the -fno-exceptions flag for the libstdc++-v3 part? > One way is to modify the Makefile.am in the libstdc++-v3/libsupc++ to > hardcode the CXXFLAGS. For my feeling however the configure script should > evaluate the CXXFLAGS enviroment variable to do this decision. Did you try the documented approach of using --enable-cxx-flags=FLAGS ? http://gcc.gnu.org/onlinedocs/libstdc++/manual/configure.html You can also rebuild libstdc++ by running 'make CXXFLAGS="..."' in the libstdc++ build directory
Re: RFC - Remove support for PCH post 4.8
On Nov 27, 2012, at 11:36 PM, Xinliang David Li wrote: > What you described is the 'transitional model' right? but I don't see It's not immediately clear from the slides, but the "transitional" model is the only model that we're pursuing. The other approach is set out in the slides for contrast. The video of the talk should be available soon, hopefully this week, which will make it more clear. > any of those in the C++ standard working paper: > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3347.pdf As far as I know, Daveed's proposal has not been implemented, and does not reflect the details of what we're implementing in Clang (Doug can give more details if you're interested). Doug and Daveed are working closely on the modules WG, which will eventually bring forward an updated proposal. -Chris
Re: RFC - Remove support for PCH post 4.8
On 11/28/2012 02:53 PM, Diego Novillo wrote: Thanks for all the responses, folks. The choice is clear, then. We will not pursue the removal of PCH. We'll attempt to re-structure PCH to use the streaming infrastructure, to make it at least more efficient (we were observing very significant file size gains when we tried it on the PPH branch). Is it permissable to ask a meta-question here ? What's so horrible about the definition of header files that something like this is necessary ? In Fortran we have modules. Certainly, the efficient processing of these files is important. To us, that's our - internal - problem. How can it be that a wart on a C++ problem gets so much air time ? Kind regards, -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/ Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news
Re: RFC - Remove support for PCH post 4.8
On 28 November 2012 09:03, Jonathan Wakely wrote: > On 28 November 2012 07:36, Xinliang David Li wrote: >> 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 > > It's far too early for anything to have been voted into the working > paper, that doesn't change the fact there's a WG21 study group, > chaired by Doug, working on modules. See > http://isocpp.org/std/the-committee Oh sorry, I didn't follow the link to realise that's Vandevoorde's most recent proposal. When you said "working paper" I thought you meant the current C++ draft, which is what people usually mean by "the C++ standard working paper". N3347 is just a proposal, it's not part of the standard and hasn't been approved or agreed on as being "the current state of modules". There are often competing or alternative proposals during development of a feature.
Re: RFC - Remove support for PCH post 4.8
On 28 November 2012 20:16, Toon Moene wrote: > On 11/28/2012 02:53 PM, Diego Novillo wrote: > > Is it permissable to ask a meta-question here ? > > What's so horrible about the definition of header files that something like > this is necessary ? > > In Fortran we have modules. Certainly, the efficient processing of these > files is important. To us, that's our - internal - problem. How can it be > that a wart on a C++ problem gets so much air time ? The simple textual inclusion model of C++ headers has a number of problems, including excessive build times to recompile code multiple times then for the linker to discard it again, interference between user-defined macros and library names, poor separation of interface and implementation (private members must be declared in a class and parsed as part of any user code including the class definition despite being inaccessible to those users.) There are ways to mitigate these problems, but they add extra work. See Section 4 of Vandevoorde's N3347 proposal for more information.
Re: RFC - Remove support for PCH post 4.8
On Nov 28, 2012, at 1:14 PM, Jonathan Wakely wrote: > On 28 November 2012 09:03, Jonathan Wakely wrote: >> On 28 November 2012 07:36, Xinliang David Li wrote: >>> 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 >> >> It's far too early for anything to have been voted into the working >> paper, that doesn't change the fact there's a WG21 study group, >> chaired by Doug, working on modules. See >> http://isocpp.org/std/the-committee > > Oh sorry, I didn't follow the link to realise that's Vandevoorde's > most recent proposal. When you said "working paper" I thought you > meant the current C++ draft, which is what people usually mean by "the > C++ standard working paper". N3347 is just a proposal, it's not part > of the standard and hasn't been approved or agreed on as being "the > current state of modules". There are often competing or alternative > proposals during development of a feature. There is no document (yet) that proposes modules as implemented in Clang. We hope to have one for the Bristol meeting. - Doug
Re: RFC - Remove support for PCH post 4.8
On Wed, Nov 28, 2012 at 3:14 PM, Jonathan Wakely wrote: > On 28 November 2012 09:03, Jonathan Wakely wrote: >> On 28 November 2012 07:36, Xinliang David Li wrote: >>> 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 >> >> It's far too early for anything to have been voted into the working >> paper, that doesn't change the fact there's a WG21 study group, >> chaired by Doug, working on modules. See >> http://isocpp.org/std/the-committee > > Oh sorry, I didn't follow the link to realise that's Vandevoorde's > most recent proposal. When you said "working paper" I thought you > meant the current C++ draft, which is what people usually mean by "the > C++ standard working paper". N3347 is just a proposal, it's not part > of the standard and hasn't been approved or agreed on as being "the > current state of modules". There are often competing or alternative > proposals during development of a feature. My understanding from attending the last C++ standards committee is that we are still way far from having something that gets consensus of good enough proposal on modules to coalesce around. We have several proposals, each in various states of experimental implementations; nothing more. -- Gaby
Re: RFC - Remove support for PCH post 4.8
2012/11/29 Gabriel Dos Reis : > My understanding from attending the last C++ standards committee is > that we are still way far from having something that gets consensus of > good enough proposal on modules to coalesce around. We have several > proposals, each in various states of experimental implementations; > nothing more. Do you have pointers to any other other (currently viable) proposals, besides the one outlined by N3347 and the slides Chris pointed a link to? Thanks, -miles p.s. sorry if all of this is common knowledge... ^^; -- Cat is power. Cat is peace.
Re: RFC - Remove support for PCH post 4.8
On Wed, Nov 28, 2012 at 6:41 PM, Miles Bader wrote: > 2012/11/29 Gabriel Dos Reis : >> My understanding from attending the last C++ standards committee is >> that we are still way far from having something that gets consensus of >> good enough proposal on modules to coalesce around. We have several >> proposals, each in various states of experimental implementations; >> nothing more. > > Do you have pointers to any other other (currently viable) proposals, > besides the one outlined by N3347 and the slides Chris pointed a link > to? > > Thanks, > > -miles > > p.s. sorry if all of this is common knowledge... ^^; > > -- > Cat is power. Cat is peace. Lawrence Crowl (in collaboration with Diego I think) has a proposal based on PPH. Lawrence knows best the proposal number. It was already pointed out that David Vandevoorde has a proposal slightly different from Clang's. At the Fall 2012 Portland meeting, people from CERN expressed concerns about Clang's implementation and have been working with Clang people to get their proposed modifications integrated; it is not clear to me whether they have made progress on that or whether they are going to formally put forward a fourth formal proposal. As Doug just indicated, there is going to be another proposal based on Clang's current implementation -- which is different from the document referred to earlier. -- Gaby
Re: RFC - Remove support for PCH post 4.8
On 11/28/12, Gabriel Dos Reis wrote: > On Nov 28, 2012 Miles Bader wrote: > > 2012/11/29 Gabriel Dos Reis : > > > My understanding from attending the last C++ standards > > > committee is that we are still way far from having something > > > that gets consensus of good enough proposal on modules to > > > coalesce around. We have several proposals, each in various > > > states of experimental implementations; nothing more. > > > > Do you have pointers to any other other (currently viable) > > proposals, besides the one outlined by N3347 and the slides > > Chris pointed a link to? > > Lawrence Crowl (in collaboration with Diego I think) has a proposal > based on PPH. Lawrence knows best the proposal number. The paper is N3426 Experience with Pre-Parsed Headers. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3426.html Note however, that this paper is not a C++ proposal. It tells our experience in trying to save header parses. By design, PPH does not address some issues that we think need to be addressed in a full modules proposal. In particular, we think export control is important to both robust software and decent compilation performance. > It was already pointed out that David Vandevoorde has a proposal > slightly different from Clang's. > > At the Fall 2012 Portland meeting, people from CERN expressed > concerns about Clang's implementation and have been working with > Clang people to get their proposed modifications integrated; it is > not clear to me whether they have made progress on that or whether > they are going to formally put forward a fourth formal proposal. > As Doug just indicated, there is going to be another proposal > based on Clang's current implementation -- which is different > from the document referred to earlier. -- Lawrence Crowl
Re: RFC - Remove support for PCH post 4.8
On Wed, Nov 28, 2012 at 7:07 PM, Lawrence Crowl wrote: > On 11/28/12, Gabriel Dos Reis wrote: >> On Nov 28, 2012 Miles Bader wrote: >> > 2012/11/29 Gabriel Dos Reis : >> > > My understanding from attending the last C++ standards >> > > committee is that we are still way far from having something >> > > that gets consensus of good enough proposal on modules to >> > > coalesce around. We have several proposals, each in various >> > > states of experimental implementations; nothing more. >> > >> > Do you have pointers to any other other (currently viable) >> > proposals, besides the one outlined by N3347 and the slides >> > Chris pointed a link to? >> >> Lawrence Crowl (in collaboration with Diego I think) has a proposal >> based on PPH. Lawrence knows best the proposal number. > > The paper is N3426 Experience with Pre-Parsed Headers. > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3426.html > > Note however, that this paper is not a C++ proposal. It tells our > experience in trying to save header parses. By design, PPH does > not address some issues that we think need to be addressed in a > full modules proposal. In particular, we think export control is > important to both robust software and decent compilation performance. Thanks, Lawrence! -- Gaby
