Re: Request for suppressing "warn_unused_result" warnings
On Fri, May 28, 2010 at 11:32:46AM -0700, Ian Lance Taylor wrote:
> Please read http://gcc.gnu.org/PR25509 .
>
> As the compiler documentation states, warn_unused_result was intended
> for cases where failing to check the return value is always a security
> risk or a bug. The documentation cites the example of realloc. That
> is a case where casting the return value to (void) would always be
> wrong. The compiler really should warn for that code by default; if
> you have some crazy need to ignore the result of realloc, just use the
> -Wno-unused-result option.
>
> That said, I agree that glibc is overly aggressive in using
> warn_unused_result when FORTIFY_SOURCE is defined. I agree that
> Debian is overly aggressive in having a distro-specific patch to
> enable FORTIFY_SOURCE by default. I think that both of those
> decisions were ill-advised. The combination of those decisions with
> the ones made by the gcc developers definitely makes some code
> inappropriately awkward.
>
> So what are the right choices here? I tend to be reluctant to endorse
> adding a new option, but I can't think of another approach.
Perhaps we might have a pragma to avoid a specific occurrence of the warning.
So the example code would become:
extern int foo() __attribute__((warn_unused_result));
int main()
{
/* the pragma has effect only on the following statement */
#pragma GCC dont_warn_unused_result
(void) foo();
return 0;
}
Or perhaps even
_Pragma(GCC(dont_warn_unused_result), foo())
I know that pragmas have been undesirable in GCC, but perhaps in that
case (marking a specific occurrence or statement) they might be
ok. AFAIK, we don't have statement attributes.
Or perhaps it should be yet another builtin, eg
builtin_dont_warn_unused_result(foo())
An artificial, contrieved, hypothetical use case could be when the
programmer know for sure that a particular call occurrence to a
warn_unused_result function don't return normally (e.g. always throws
a C++ exception or do a setjmp in C or loop forever.).
But I agree that all this is not very important. Sorry for bothering!
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: Using C++ in GCC is OK
On Mon, May 31, 2010 at 01:39:08AM -0500, Gabriel Dos Reis wrote:
> On Mon, May 31, 2010 at 12:28 AM, Basile Starynkevitch
> wrote:
>
> > At last, there is a very important issue when switching to C++. What is
> > our "ideal" class hierarchy?
>
> The ideal class hierarchy is independent of the language used. The language
> matters only to the extend that it provides direct support (or lack thereof)
> to
> express that hierarchy.
I fully agree (and indeed we could have a quite clean class hierarchy
in C, like GTK have), but a transition to C++ could also be the time
for defining more properly our type or class hierarchies.
Cheers.
--
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} ***
Code Instrumentation
Hallo,
i would like to instrument some existing code. For example, after an ADD-EXPR:
int main() {
int a=5;
int b=5;
int c = a + b; ...
}
should become:
...
int c = a + b;
puts("ADD-EXPR");
...
I thought writing a Gimple-pass would be best, but i don't know exactly where
to start. I'm able to walk throug the Gimple-Statements and debug it, but i'm
not able to insert something.
Is there any source-code available?
Thanks
Wolfgang
--
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
Re: Using C++ in GCC is OK
Eric Botcazou writes: > Where does this "long long" requirement come from? We should only require an > ISO C++98 compiler, just like we currently require only an ISO C90 compiler. C90 does not have long long either, yet we use it as required (for HWI). Andreas. -- Andreas Schwab, sch...@redhat.com GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E "And now for something completely different."
Re: Using C++ in GCC is OK
> C90 does not have long long either, yet we use it as required (for HWI). No, we use it when present but we don't require it, see hwint.h. -- Eric Botcazou
Re: Using C++ in GCC is OK
On 05/31/2010 11:48 AM, Eric Botcazou wrote: C90 does not have long long either, yet we use it as required (for HWI). No, we use it when present but we don't require it, see hwint.h. Both of you are right, as our requirements for building a cross compiler are stricter than for a native compiler. We do require long long for 32->64 cross compilers. Paolo
Re: Using C++ in GCC is OK
Sent from my iPhone On May 31, 2010, at 2:48 AM, Eric Botcazou wrote: C90 does not have long long either, yet we use it as required (for HWI). No, we use it when present but we don't require it, see hwint.h. Kinda. It depends on the host and target. If the target requires 64bit host wide ints then we require long long for 32 bit hosts. An example is a cross compiler from x86 to alpha. -- Eric Botcazou
Re: Using C++ in GCC is OK
> Both of you are right, as our requirements for building a cross compiler > are stricter than for a native compiler. > > We do require long long for 32->64 cross compilers. Right, only in this case, and I don't see why this should be changed with the transition to C++, that's orthogonal. -- Eric Botcazou
Re: Using C++ in GCC is OK
Eric Botcazou writes: > Right, only in this case, and I don't see why this should be changed with the > transition to C++, that's orthogonal. It will be used as required. Andreas. -- Andreas Schwab, sch...@redhat.com GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E "And now for something completely different."
Re: Using C++ in GCC is OK
On Mon, May 31, 2010 at 8:26 AM, Mark Mitchell wrote: > I am pleased to report that the GCC Steering Committee and the FSF have > approved the use of C++ in GCC itself. Of course, there's no reason for > us to use C++ features just because we can. The goal is a better > compiler for users, not a C++ code base for its own sake. > Outstanding decision! C++ is an amazing language. C++'s three main features(encapsulation, inheritance, polymorphism) can greatly improve the GCC's code base, render it more modular and readable and let GCC developer to think at a more abstract layer. In GCC, there are too many data structures that can be encapsulated as ADT(Abstract Data Type), like sbitmap, bitmap, struct real_value, struct sreal, double_int, HWI, etc. I will glad to see these data structures can be used as conveniently as string in C++. The complexity and irregularity of TREE and RTL IRs may be the biggest hurdle to use inheritance and polymorphism on them. Language hooks and target hooks can be easily replaced by virtual methods. I have FUD on the use of "advanced" C++ features like template(even standard template), namespace, exceptions. This is partly because my favorite source code analyzer can not handle them properly. I have tried to use my favorite source code analyzer to analyze LLVM source code, which use C++ standard template aggressively, the result is not ideal . I also have tried to use it to analyze Open64 source code, which does not use template, the result is much better .It would be nice if there are another template-free encapsulation over standard template. For example, an template-free container encapsulating standard container template. -- 徐持恒(Chiheng Xu) Wuhan,China
Re: Using C++ in GCC is OK
On Mon, May 31, 2010 at 5:54 PM, Andrew Pinski wrote: > > > Sent from my iPhone > > On May 31, 2010, at 2:48 AM, Eric Botcazou wrote: > >>> C90 does not have long long either, yet we use it as required (for HWI). >> >> No, we use it when present but we don't require it, see hwint.h. > > Kinda. It depends on the host and target. If the target requires 64bit host > wide ints then we require long long for 32 bit hosts. An example is a cross > compiler from x86 to alpha. > > >> >> -- >> Eric Botcazou > You can encapsulate HWI in an ADT(abstract data type). I think compiler can and should be host independent, like LLVM. -- 徐持恒(Chiheng Xu) Wuhan,China
Re: Using C++ in GCC is OK
徐持恒 wrote: I have FUD on the use of "advanced" C++ features like template(even standard template), namespace, exceptions. This is partly because my favorite source code analyzer can not handle them properly. I have tried to use my favorite source code analyzer to analyze LLVM source code, which use C++ standard template aggressively, the result is not ideal . I also have tried to use it to analyze Open64 source code, which does not use template, the result is much better .It would be nice if there are another template-free encapsulation over standard template. For example, an template-free container encapsulating standard container template. It's a pity to exclude namespaces, the advantage of breaking the single-big-namespace model are evident.
Re: Using C++ in GCC is OK
On Mon, May 31, 2010 at 6:41 PM, Robert Dewar wrote: > It's a pity to exclude namespaces, the advantage of breaking the > single-big-namespace model are evident. >> Yes, the advantage of namespace is obvious. But, I think namespace is just a syntax sugar. You can name your variables, functions, classes properly to "avoid" it. -- 徐持恒(Chiheng Xu) Wuhan,China
Re: Using C++ in GCC is OK
On Mon, May 31, 2010 at 12:41 PM, Robert Dewar wrote: > 徐持恒 wrote: > >> I have FUD on the use of "advanced" C++ features like template(even >> standard template), namespace, exceptions. This is partly because my >> favorite source code analyzer can not handle them properly. I have >> tried to use my favorite source code analyzer to analyze LLVM source >> code, which use C++ standard template aggressively, the result is not >> ideal . I also have tried to use it to analyze Open64 source code, >> which does not use template, the result is much better .It would be >> nice if there are another template-free encapsulation over standard >> template. For example, an template-free container encapsulating >> standard container template. > > It's a pity to exclude namespaces, the advantage of breaking the > single-big-namespace model are evident. I agree. I would not exclude namespaces. What I would add is a required "explicit" on all single-argument constructors. We want all conversions to be explicitly specified. Do we have a warning for this we can use? I would like to be able to use function overloading. For the start we'd want to use -fno-exceptions -fno-rtti for stage2 and stage3. Oh - and we didn't yet decide to switch to C++ as implementation language. Did we? Thanks, Richard.
Re: Using C++ in GCC is OK
徐持恒 wrote: On Mon, May 31, 2010 at 6:41 PM, Robert Dewar wrote: It's a pity to exclude namespaces, the advantage of breaking the single-big-namespace model are evident. Yes, the advantage of namespace is obvious. But, I think namespace is just a syntax sugar. You can name your variables, functions, classes properly to "avoid" it. All of OO is just syntactic sugar :-) You can mimic anything in C, the point is that it obscures the code, this kind of naming obscures the code, so it is better avoided.
Re: Using C++ in GCC is OK
On Mon, May 31, 2010 at 12:59 PM, Robert Dewar wrote: > 徐持恒 wrote: >> >> On Mon, May 31, 2010 at 6:41 PM, Robert Dewar wrote: >> >>> It's a pity to exclude namespaces, the advantage of breaking the >>> single-big-namespace model are evident. >> >> Yes, the advantage of namespace is obvious. >> >> But, I think namespace is just a syntax sugar. You can name your >> variables, functions, classes properly to "avoid" it. > > All of OO is just syntactic sugar :-) > You can mimic anything in C, the point is that it obscures the > code, this kind of naming obscures the code, so it is better > avoided. Indeed. Like the funny names you start to invent when you have wrappers that allow different kind of argument types for a common worker. Like building a points-to constraint in tree-ssa-structalias.c, those have two args which technically can be either of type int, of type varinfo_t or of type struct constraint_expr ... The most convenient variant would be auto-conversion to struct constraint_expr, but even an explicit constructor call would be ok. Or simply use function overloading for a sub-set of all argument type combinations. The same applies to functions operating on HWI vs. double-int vs. tree integer constants vs. RTL integer constants. Where at that point the question is whether we want to allow operator overloading. (No would be my answer) Richard.
Re: Using C++ in GCC is OK
There are several C++ features which not all compilers support well,
these features should be avoided if possible.
For example VC++ 2008 treats
struct foo{ static const int bar=1; };
As if the coder has also written (at the same spot)
const int foo::bar;
The consequence is multiple definitions of foo::bar which make the linker
emits an. You can force the linker to accept such duplicate symbols,
but from what I read, not verified, using this flag is a bad idea.
Another case:class foo { class bar { }; };
Some compilers still disagree whether class bar is an implicit friend of
class foo or not.
And don't get me started on template related incompatibility of compilers.
Even passing std::set to gcc GCC-4.3 may trigger seemingly unrelated
warnings, depending on code near std::set (I have commented an existing PR
showing this case).
Maybe there should be a special flag in GCC to make it more strict, such
that
these cases will be warned about.
Michael
On 05/31/10 03:26, Mark Mitchell wrote:
I am pleased to report that the GCC Steering Committee and the FSF have
approved the use of C++ in GCC itself. Of course, there's no reason for
us to use C++ features just because we can. The goal is a better
compiler for users, not a C++ code base for its own sake.
Before we start to actually use C++, we need to determine a set of
coding standards that will apply to use of C++ within GCC. At first, I
believe that we should keep the set of C++ features permitted small, in
part so that GCC developers not familiar with C++ are not rapidly
overwhelmed by a major change in the implementation language for the
compiler itself. We can always use more of C++ later if it seems
appropriate to do so, then.
For example, I think it goes without question that at this point we are
limiting ourselves to C++98 (plus "long long" so that we have a 64-bit
integer type); C++0x features should not be used. Using multiple
inheritance, templates (other than when using the C++ standard library,
e.g. std::list), or exceptions also seems overly aggressive to me.
We should use features that are relatively easy for C programmers to
understand and relatively hard for new C++ programmers to misuse. (For
example, I think constructors and destructors are pretty easy and hard
to misuse.)
Because C++ is a big language, I think we should try to enumerate what
is OK, rather than what is not OK. But, at the same time, I don't think
we should try to get overly legalistic about exactly what is in and what
is out. We need information guidelines, not an ISO standard.
Is there anyone who would like to volunteer to develop the C++ coding
standards? I think that this could be done as a Wiki page. (If nobody
volunteers, I will volunteer myself.) Whoever ends up doing this, I
would urge the rest of us not to spend too much time in the C++
coding-standards bikeshed; we're not going to win or lose too much
because we do or do not permit default parameters.
Re: Using C++ in GCC is OK
One interesting issue is whether it is important for gcc to be able to be compiled with foreign compilers (other than gcc). I know that historically this has been an important requirement, but I wonder whether it is still relevant. Gcc is very widespread at this point. Yes, there is the issue of completely new targets, but these can be easily handled by building cross-compilers. I suspect that the use of C++ will make the use of foreign compilers harder, but I suspect also that it doesn't matter. When we first wrote the front end of GNAT in Ada, we worried about the fact that it meant that GNAT needed a version of gcc to be compiled. We had various schemes to get around this (generate C, generate MIPS code and use a MIPS simulator etc). But as it turned out, the requirement for a previous version of gcc did not turn out to be an impediment in getting GNAT spread to all sorts of strange machines. We do take care to ensure that the front end and critical tools can be compiled with an old version of GNAT, so e.g. we avoid using new features like conditional expressions in the GNAT front end.
Re: Using C++ in GCC is OK
On Mon, May 31, 2010 at 3:42 AM, Basile Starynkevitch wrote: > On Mon, May 31, 2010 at 01:39:08AM -0500, Gabriel Dos Reis wrote: >> On Mon, May 31, 2010 at 12:28 AM, Basile Starynkevitch >> wrote: >> >> > At last, there is a very important issue when switching to C++. What is >> > our "ideal" class hierarchy? >> >> The ideal class hierarchy is independent of the language used. The language >> matters only to the extend that it provides direct support (or lack thereof) >> to >> express that hierarchy. > > > I fully agree (and indeed we could have a quite clean class hierarchy > in C, like GTK have), and as a matter of fact, we do already have a class hierarchy. The issue there I suspect is whether its expression in C is faithful. > but a transition to C++ could also be the time > for defining more properly our type or class hierarchies. yes, it definitely is an opportunity to revise the design as we are revisiting the area, but that should be orthogonal to the rest. -- Gaby
Re: Using C++ in GCC is OK
On Mon, May 31, 2010 at 4:58 PM, Gabriel Dos Reis wrote: > On Mon, May 31, 2010 at 3:42 AM, Basile Starynkevitch > wrote: >> On Mon, May 31, 2010 at 01:39:08AM -0500, Gabriel Dos Reis wrote: >>> On Mon, May 31, 2010 at 12:28 AM, Basile Starynkevitch >>> wrote: >>> >>> > At last, there is a very important issue when switching to C++. What is >>> > our "ideal" class hierarchy? >>> >>> The ideal class hierarchy is independent of the language used. The language >>> matters only to the extend that it provides direct support (or lack >>> thereof) to >>> express that hierarchy. >> >> >> I fully agree (and indeed we could have a quite clean class hierarchy >> in C, like GTK have), > > and as a matter of fact, we do already have a class hierarchy. The issue > there > I suspect is whether its expression in C is faithful. > >> but a transition to C++ could also be the time >> for defining more properly our type or class hierarchies. > > yes, it definitely is an opportunity to revise the design as we are revisiting > the area, but that should be orthogonal to the rest. And we definitely should not do so just because we can. I see little value in turning our tree upside-down just because we now can use C++ and make everything a class rather than a union. Richard.
Re: Using C++ in GCC is OK
On Mon, May 31, 2010 at 5:03 PM, Richard Guenther wrote: > And we definitely should not do so just because we can. I see > little value in turning our tree upside-down just because we now > can use C++ and make everything a class rather than a union. If hiding the structure of the data types matters, then 'tree' should be re-done as a class, shouldn't it? Otherwise, how are you going to get rid of all the accessor macros and static inline functions that only half-hide the underlying structures? Ciao! Steven
Re: Using C++ in GCC is OK
On Mon, May 31, 2010 at 7:22 AM, Robert Dewar wrote: > One interesting issue is whether it is important for gcc to be > able to be compiled with foreign compilers (other than gcc). > > I know that historically this has been an important requirement, > but I wonder whether it is still relevant. > > Gcc is very widespread at this point. Yes, there is the issue > of completely new targets, but these can be easily handled by > building cross-compilers. > > I suspect that the use of C++ will make the use of foreign > compilers harder, but I suspect also that it doesn't matter. I do not think so, and I would not suggest that the use of C++ is an excuse do ditch the possibility of bootstrapping with anything other than GCC. As for the subset of C++ to use, yes we need to be conservative. A very large part of C++98 is well established. Although it would be tempting, I would recommend against using it as with "C with classes". We should be able to use: * classes with multiple access protection sections (i.e. public sectionsfor interface operations, private section for data members that should not be accessed directly, etc.) * full single inheritance * multiple inheritance where appropriate, but NOT virtual inheritance * namespaces to partition codes. Prefer explicit qualification over reliance on argument dependent name lookup (except for operators, of course) * simple templates -- e.g. containers, simple functions, but avoid creative uses such as template metaprogramming. * avoid casts, and dynamic_cast should be kept to the minimum -- use of virtual functions should be preferred (as we currently do with hooks). * trust the reviewers to use the best judgments. -- Gaby
Re: Using C++ in GCC is OK
On Mon, May 31, 2010 at 10:03 AM, Richard Guenther wrote: > On Mon, May 31, 2010 at 4:58 PM, Gabriel Dos Reis > wrote: >> On Mon, May 31, 2010 at 3:42 AM, Basile Starynkevitch >> wrote: >>> On Mon, May 31, 2010 at 01:39:08AM -0500, Gabriel Dos Reis wrote: On Mon, May 31, 2010 at 12:28 AM, Basile Starynkevitch wrote: > At last, there is a very important issue when switching to C++. What is > our "ideal" class hierarchy? The ideal class hierarchy is independent of the language used. The language matters only to the extend that it provides direct support (or lack thereof) to express that hierarchy. >>> >>> >>> I fully agree (and indeed we could have a quite clean class hierarchy >>> in C, like GTK have), >> >> and as a matter of fact, we do already have a class hierarchy. The issue >> there >> I suspect is whether its expression in C is faithful. >> >>> but a transition to C++ could also be the time >>> for defining more properly our type or class hierarchies. >> >> yes, it definitely is an opportunity to revise the design as we are >> revisiting >> the area, but that should be orthogonal to the rest. > > And we definitely should not do so just because we can. I see > little value in turning our tree upside-down just because we now > can use C++ and make everything a class rather than a union. I was not arguing for redefining the tree hierarchy -- just pointing out that Basile's original question is independent of the language use. Whether we actually decide to redesign it, in my mind, is an orthogonal issue. There are values to have them as C data types (with all the funny things we have been doing), and also to convert them to a C++ class hierarchy. Which approach is chosen should depend on the merits.
Re: Using C++ in GCC is OK
For example, I think it goes without question that at this point we are limiting ourselves to C++98 (plus "long long" so that we have a 64-bit integer type); C++0x features should not be used. Using multiple inheritance, templates (other than when using the C++ standard library, e.g. std::list), or exceptions also seems overly aggressive to me. We should use features that are relatively easy for C programmers to understand and relatively hard for new C++ programmers to misuse. (For example, I think constructors and destructors are pretty easy and hard to misuse.) This sort of leads to questions about C++ libraries used by gcc: 1) is there interest in using libstdc++ (gcc's version) in whole or a subset? (which subset?) For example, I think it would be reasonable to use most standard containers. could be useful, but itself relies on function overloading for optimization in some places. Overloading in any form could be debatable, if you're being conservative about feature selection. 2) should there be a double standard w.r.t. std library use? Allowing a greater set of language features for the sake of using libstdc++, but a restricted set of C++ for non-libstdc++ libraries and data structures? iostreams, for example, uses multiple inheritance (even multiple virtual inheritance), should that be sufficient grounds for forbidding use of iostreams? Fang David Fang http://www.csl.cornell.edu/~fang/ http://www.achronix.com/
Re: Using C++ in GCC is OK
On Mon, May 31, 2010 at 5:09 PM, Steven Bosscher wrote: > On Mon, May 31, 2010 at 5:03 PM, Richard Guenther > wrote: >> And we definitely should not do so just because we can. I see >> little value in turning our tree upside-down just because we now >> can use C++ and make everything a class rather than a union. > > If hiding the structure of the data types matters, then 'tree' should > be re-done as a class, shouldn't it? Otherwise, how are you going to > get rid of all the accessor macros and static inline functions that > only half-hide the underlying structures? Well - if somebody does the work and _completely_ converts tree and its accessor functions and macros to use a class-based tree then more power to him. What I do not like to see is partial conversions to C++. Richard. > Ciao! > Steven >
Re: Using C++ in GCC is OK
Eric Botcazou wrote: >> We do require long long for 32->64 cross compilers. > > Right, only in this case, and I don't see why this should be changed with the > transition to C++, that's orthogonal. I agree. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: Using C++ in GCC is OK
Gabriel Dos Reis writes: > [...] I do not think so, and I would not suggest that the use of > C++ is an excuse do ditch the possibility of bootstrapping with > anything other than GCC. Right. It would be good to enumerate any language/design constraints that other noteworthy C++ compilers would impose on the GCC source base. The remaining language feature set could be noted as the "upper limit" of C++ being adopted. > As for the subset of C++ to use, yes we need to be conservative. [...] ... at least at first, as the gcc developer population learns the language. Whatever constraints are adopted for purposes of simplifying the language/system for C-only developers should be thought of as temporary "lower limits" that accomplish a gentle introduction. In the longer run, there may be no reason to hold back approaching the "upper limit" of the full language, as people learn and learn to love it. It may also help the training process to identify not just initial constraints on the language, but to name those parts of gcc that could most obviously benefit from C++y abstraction. These areas should be enumerated and analyzed by C++-familiar developers, to ensure that the initial "lower limit" feature set is sufficient to make a dent into those areas. - FChE
Re: Using C++ in GCC is OK
On Mon, May 31, 2010 at 5:29 PM, David Fang wrote: >> For example, I think it goes without question that at this point we are >> limiting ourselves to C++98 (plus "long long" so that we have a 64-bit >> integer type); C++0x features should not be used. Using multiple >> inheritance, templates (other than when using the C++ standard library, >> e.g. std::list), or exceptions also seems overly aggressive to me. >> We should use features that are relatively easy for C programmers to >> understand and relatively hard for new C++ programmers to misuse. (For >> example, I think constructors and destructors are pretty easy and hard >> to misuse.) > > This sort of leads to questions about C++ libraries used by gcc: > > 1) is there interest in using libstdc++ (gcc's version) in whole or a > subset? (which subset?) For example, I think it would be reasonable to use > most standard containers. could be useful, but itself relies on > function overloading for optimization in some places. Overloading in any > form could be debatable, if you're being conservative about feature > selection. > > 2) should there be a double standard w.r.t. std library use? Allowing a > greater set of language features for the sake of using libstdc++, but a > restricted set of C++ for non-libstdc++ libraries and data structures? > iostreams, for example, uses multiple inheritance (even multiple virtual > inheritance), should that be sufficient grounds for forbidding use of > iostreams? We expect a C++98 compiler to provide a conformant standard library. Implementation details of libstdc++ do not matter here (we certainly can't use our own libstdc++ implementation together with the host compiler). Richard. > Fang > > David Fang > http://www.csl.cornell.edu/~fang/ > http://www.achronix.com/ > >
Re: Using C++ in GCC is OK
On Mon, May 31, 2010 at 10:29 AM, David Fang wrote: >> For example, I think it goes without question that at this point we are >> limiting ourselves to C++98 (plus "long long" so that we have a 64-bit >> integer type); C++0x features should not be used. Using multiple >> inheritance, templates (other than when using the C++ standard library, >> e.g. std::list), or exceptions also seems overly aggressive to me. >> We should use features that are relatively easy for C programmers to >> understand and relatively hard for new C++ programmers to misuse. (For >> example, I think constructors and destructors are pretty easy and hard >> to misuse.) > > This sort of leads to questions about C++ libraries used by gcc: > > 1) is there interest in using libstdc++ (gcc's version) in whole or a > subset? (which subset?) For example, I think it would be reasonable to use > most standard containers. could be useful, but itself relies on > function overloading for optimization in some places. Overloading in any > form could be debatable, if you're being conservative about feature > selection. > > 2) should there be a double standard w.r.t. std library use? Allowing a > greater set of language features for the sake of using libstdc++, but a > restricted set of C++ for non-libstdc++ libraries and data structures? > iostreams, for example, uses multiple inheritance (even multiple virtual > inheritance), should that be sufficient grounds for forbidding use of > iostreams? Currently GCC uses the C standard implementation, without using itself all the horrors you can find in standard header files. The subset being discussed in the one that reviewers will accept, not the one the C++ compiler will accept.
Re: Using C++ in GCC is OK
On Mon, May 31, 2010 at 11:09, Steven Bosscher wrote: > On Mon, May 31, 2010 at 5:03 PM, Richard Guenther > wrote: >> And we definitely should not do so just because we can. I see >> little value in turning our tree upside-down just because we now >> can use C++ and make everything a class rather than a union. > > If hiding the structure of the data types matters, then 'tree' should > be re-done as a class, shouldn't it? Otherwise, how are you going to > get rid of all the accessor macros and static inline functions that > only half-hide the underlying structures? I agree. Richard, why do you think turning tree into an appropriate class hierarchy would not be useful? Diego.
Re: Using C++ in GCC is OK
Basile Starynkevitch wrote:
> At last, there is a very important issue when switching to C++. What is
> our "ideal" class hierarchy? Do we aim at a large forest, or on the
> contrary at a single tree of classes, so we have a single root class,
> providing common services (dump or debug printing, serialization, ...)
> or not?
There's no reason to get into these kinds of questions at this point.
The goal is not to reimplement GCC from the ground up using modern
OO/C++ techniques. The goal is simply to permit ourselves to use C++
features where appropriate in the codebase.
With respect to a class hierarchy, we already have inheritance in a few
places. For example, the "tree" data structures are inheriting from a
base class by doing things like:
struct tree_derived {
struct tree_base base;
/* derived fields here. */
};
It's natural to use actual C++ inheritance there. But, there's no a
priori reason to start making other things inherit from each other or
start trying to factor out base classes that we don't currently have,
unless it's actually demonstrably useful to do so.
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
Re: Using C++ in GCC is OK
On Mon, May 31, 2010 at 11:27, Richard Guenther wrote: > Well - if somebody does the work and _completely_ converts > tree and its accessor functions and macros to use a class-based > tree then more power to him. What I do not like to see is > partial conversions to C++. OK, that's reasonable. Diego.
Re: Using C++ in GCC is OK
On Mon, May 31, 2010 at 11:54, Richard Guenther wrote: > It's a lot of work (tree extends in all three Frontends, middle-end > and backends). And my fear is we'll only get a halfway transition - > something worse than no transition at all. Yeah, that's true. Diego.
Re: Using C++ in GCC is OK
Mark Mitchell wrote: I am pleased to report that the GCC Steering Committee and the FSF have approved the use of C++ in GCC itself. Of course, there's no reason for us to use C++ features just because we can. The goal is a better compiler for users, not a C++ code base for its own sake. Personally, I am not enthusiastic about this decision. But I know I am minority in this and I don't want to start a flame war on this topic. I just really hope we will have strict criteria that any transition will not make compiler slower and will not increase compiler build time.
Re: Using C++ in GCC is OK
On Mon, May 31, 2010 at 5:53 PM, Diego Novillo wrote: > On Mon, May 31, 2010 at 11:09, Steven Bosscher wrote: >> On Mon, May 31, 2010 at 5:03 PM, Richard Guenther >> wrote: >>> And we definitely should not do so just because we can. I see >>> little value in turning our tree upside-down just because we now >>> can use C++ and make everything a class rather than a union. >> >> If hiding the structure of the data types matters, then 'tree' should >> be re-done as a class, shouldn't it? Otherwise, how are you going to >> get rid of all the accessor macros and static inline functions that >> only half-hide the underlying structures? > > I agree. Richard, why do you think turning tree into an appropriate > class hierarchy would not be useful? It's a lot of work (tree extends in all three Frontends, middle-end and backends). And my fear is we'll only get a halfway transition - something worse than no transition at all. Richard. > > Diego. >
Re: Using C++ in GCC is OK
On Mon, May 31, 2010 at 12:00:21PM -0400, Vladimir Makarov wrote: > Mark Mitchell wrote: >> I am pleased to report that the GCC Steering Committee and the FSF have >> approved the use of C++ in GCC itself. Of course, there's no reason for >> us to use C++ features just because we can. The goal is a better >> compiler for users, not a C++ code base for its own sake. >> >> > Personally, I am not enthusiastic about this decision. But I know I am > minority in this and I don't want to start a flame war on this topic. I'm not enthusiastic about that either. > I just really hope we will have strict criteria that any transition will > not make compiler slower and will not increase compiler build time. Nor will grow the memory footprint, at least of the important data structures, or increase maintanance costs by making the code less readable, etc. Jakub
[RFC] Switching implementation language to C++
Now that the SC and the FSF have agreed to this, we should decide whether we switch and how. So, I would like comments on the following questions: 1- Should we switch to C++? 2- What is the cost in terms of build time? 3- What coding guidelines should we use? 4- Should we make the switch during the 4.6 stage 1? Questions 2-4 are predicated on the outcome of #1. We need volunteers to work on #3. Personally, I would just use some other existing coding guideline that we find reasonable. I do not volunteer to do this. My knowledge of C++ is sufficiently limited that I don't trust myself to work on this. Diego.
Re: Using C++ in GCC is OK
On Mon, 2010-05-31 at 08:53 -0700, Mark Mitchell wrote:
> Basile Starynkevitch wrote:
>
> > At last, there is a very important issue when switching to C++. What is
> > our "ideal" class hierarchy? Do we aim at a large forest, or on the
> > contrary at a single tree of classes, so we have a single root class,
> > providing common services (dump or debug printing, serialization, ...)
> > or not?
>
> There's no reason to get into these kinds of questions at this point.
> The goal is not to reimplement GCC from the ground up using modern
> OO/C++ techniques. The goal is simply to permit ourselves to use C++
> features where appropriate in the codebase.
Except that perhaps these questions are important for any gengtype
enhancement. In particular, one could consider that marking a GTY-ed
data would be done by a virtual method (generated by gengtype), and then
having every GTY-ed data inheriting from an abstract class providing
this method will make both gengtype & ggc*.c simpler.
The same can be said about PCH serialization, or debug dumping.
In addition, if we want to parse C++ class declaration from gengtype,
that could be much more difficult than parsing struct (as gengtype is
doing today). This is why I thought perhaps of some simpler syntax for
the description of all our GTY-ed data, which would generate
appropriately the C++ header files describing them.
But nothing is possible without a rather broad consensus. Nobody will
start a branch on these ideas without having some probability that such
changes will be accepted.
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: possible license issue (documentation generated from source) in MELT branch of GCC
On Sat, 2010-05-29 at 22:40 -0700, Joe Buck wrote:
> On Sat, May 29, 2010 at 01:39:44AM -0700, Basile Starynkevitch wrote:
> > ... I was told that
> > generating a *texi file from (GPLv3+ licensed, FSF copyrighted) source
> > code could be incompatible with the GFDL license of gccint.texi.
>
> The SC is trying to work something out with RMS on this (more generally,
> it's also an issue for libstdc++ and doxygen). While I can't make
> promises, it seems he's open to coming up with some kind of solution that
> would allow this use, ideally without needing to involve lawyers.
>
> Unfortunately these things always take longer than you'd think that they
> should.
To my greatest & extremely positive surprise, I got today an answer from
the FSF (I really am very happy of such a quick answer)! I hope it OK to
cite here part of the reply I've got to my question [gnu.org #579118]
to licens...@fsf.org since Karl Berry replied to me
> The FSF has already officially approved and recommended the strategy
> mentioned in your message, and throughout the thread: dual-license,
> under the GPL and GFDL, material that applies to both code and
> manuals,
> or is auto-generated from one to the other.
>
> In your case, you are generating documentation from the code. So, put
> a
> license notice in the original (GPL'd) source files that the
> documentation so generated is also available under the FDL.
> Automatically insert an FDL license statement in the generated files.
Regards and thanks to everybody!
Cheers.
--
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: Using C++ in GCC is OK
Basile Starynkevitch wrote: > Except that perhaps these questions are important for any gengtype > enhancement. In particular, one could consider that marking a GTY-ed > data would be done by a virtual method (generated by gengtype), and then > having every GTY-ed data inheriting from an abstract class providing > this method will make both gengtype & ggc*.c simpler. There is no pressing need for a gengtype enhancement as far as I can tell. I think the right way to look at this is that we can now use C++ going-forward to implement things, and that is helpful. In some cases, we'll want to convert existing things to C++ because that helps us to do new things. But, we don't need to convert things just because we can. We don't get a prize for having a tidier code base *in and of itself*. I think we should focus on some user-visible deliverable (better optimization, faster compiler, new language feature, plugin API, whatever). If converting something to use C++ helps achieve that goal, great. If it doesn't, then why bother? I'm not saying that we should reject "clean-up" patches that use C++ in some way that makes things notably tidier. I'm just saying that I'm more excited if I see how that patch is going to help us build new functionality. And, I think it's premature to start talking about particular changes to particular parts of the compiler. Step 1 is to agree on the subset of C++ we're willing to use. Step 2 is for someone to propose a C++-using patch that does something useful and get it approved. So far, I've seen a lot of input on Step 1, but nobody that wants to step up and take responsibility for the task. Any takers? -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: Using C++ in GCC is OK
> I'm not enthusiastic about that either. FWIW neither am I. > Nor will grow the memory footprint, at least of the important data > structures, or increase maintanance costs by making the code less readable, > etc. It's clear that we don't want blind conversions to fancy C++ style, but Mark was clear about that. Maintainers should be allowed to reject conversions that buy too little or nothing. -- Eric Botcazou
Re: Using C++ in GCC is OK
Jakub Jelinek wrote: >> I just really hope we will have strict criteria that any transition will >> not make compiler slower and will not increase compiler build time. > > Nor will grow the memory footprint, at least of the important data > structures, or increase maintanance costs by making the code less readable, > etc. There is no reason that use of C++ should increase the memory footprint of the compiler, make the compiler slower, or make the code less readable. Poor use of C++ might lead to those things; good use will not. That is why we need coding standards and patch review. It is likely that use of C++ will make the compiler build time somewhat longer since G++ is generally a bit slower than GCC and since parsing things like the C++ include file is certainly more expensive than parsing our own "vec.h". (Precompiled header files may help, of course.) I would expect that this delta will be quite small in the scope of a complete compiler bootstrap, especially if you include building libstdc++ and/or libjava. As usual, we won't know for sure until we measure. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: [RFC] Switching implementation language to C++
On Mon, May 31, 2010 at 11:22 AM, Diego Novillo wrote: > > Now that the SC and the FSF have agreed to this, we should decide whether we > switch and how. So, I would like comments on the following questions: > > 1- Should we switch to C++? By switch, do you using a C++ compiler to compile everything, or that some components may be written only in C++ with sufficient care that they can be linked with other part written in C? > 2- What is the cost in terms of build time? we would have to measure when we can a sizable component in C++ > 3- What coding guidelines should we use? this is under discussion :-) > 4- Should we make the switch during the 4.6 stage 1? 4.7? > > Questions 2-4 are predicated on the outcome of #1. > > We need volunteers to work on #3. I can help with #3 -- but not if we have to rehearse old debates :-/ > Personally, I would just use some other > existing coding guideline that we find reasonable. I agree. >I do not volunteer to do > this. My knowledge of C++ is sufficiently limited that I don't trust myself > to work on this. > > > Diego. >
Re: possible license issue (documentation generated from source) in MELT branch of GCC
Basile Starynkevitch wrote: To my greatest & extremely positive surprise, I got today an answer from the FSF (I really am very happy of such a quick answer)! I hope it OK to cite here part of the reply I've got to my question [gnu.org #579118] to licens...@fsf.org since Karl Berry replied to me The FSF has already officially approved and recommended the strategy mentioned in your message, and throughout the thread: dual-license, under the GPL and GFDL, material that applies to both code and manuals, or is auto-generated from one to the other. In your case, you are generating documentation from the code. So, put a license notice in the original (GPL'd) source files that the documentation so generated is also available under the FDL. Automatically insert an FDL license statement in the generated files. Regards and thanks to everybody! Great, it's always good when you hit an established FAQ to which the answer is already available Cheers.
Re: [RFC] Switching implementation language to C++
On 10-05-31 12:50 , Gabriel Dos Reis wrote: By switch, do you using a C++ compiler to compile everything, or that some components may be written only in C++ with sufficient care that they can be linked with other part written in C? Ideally, the former. If we cannot get consensus on that, then I guess we'd have to settle for the latter. Diego.
Re: Using C++ in GCC is OK
On Mon, May 31, 2010 at 09:44:08AM -0700, Mark Mitchell wrote: > >> I just really hope we will have strict criteria that any transition will > >> not make compiler slower and will not increase compiler build time. > > > > Nor will grow the memory footprint, at least of the important data > > structures, or increase maintanance costs by making the code less readable, > > etc. > > There is no reason that use of C++ should increase the memory footprint > of the compiler, make the compiler slower, or make the code less > readable. Poor use of C++ might lead to those things; good use will > not. That is why we need coding standards and patch review. E.g. when you start using virtual methods, suddenly you need a vtable pointer in the object and thus the object grew by 8 bytes. In many cases it would be really addition of that pointer, dropping an 8/16 bit code would slow things down too much (using virtual method to get you say enum tree_code from a tree would be way too slow, similarly for rtti). Similarly if the compiler massively starts using virtual methods everywhere, there will be slow downs caused by the increased number of harder to predict indirect calls. Jakub
Re: Using C++ in GCC is OK
Richard Guenther wrote: > Oh - and we didn't yet decide to switch to C++ as implementation > language. Did we? I'm not sure exactly what you're asking. We now have permission to switch. The reason we wanted permission to switch was that there was a consensus that we wanted to switch; as far as I know, we didn't want the permission just so that we could at some later point consider switching! I think we've decided to switch, but we haven't decided to what subset of C++ we're switching. I think that we want what might be called the "syntactic sugar" subset. For example, single inheritance to replace our C-style inheritance, constructors/destructors to replace explicit calls to required initialization/finalization functions, and member functions to implement ADTs, namespaces to save us some typing. None of these things impacts memory use, or run-time performance. Generally speaking, these are things that remove lines of code, help to prevent mistakes made by casting or forgetting to obey requirements of APIs, and make it easier to replace particular components without impacting large parts of the rest of the source code. The more "exotic" bits of C++ (RTTI, exceptions, virtual inheritance, templates, etc.) all involve the compiler doing a lot more implicit generation of data structures and code, including, in some cases, implicitly making data structures bigger. I think these techniques are valuable when used appropriately, but I wouldn't propose using them in GCC soon. It is easy to mis-use them and for them to have unintended consequences. I think virtual functions are on the edge; quite useful, but do result in the compiler adding a pointer to data objects and in uninlinable indirect calls at run-time. Therefore, I would avoid them in the initial subset of C++ used in GCC. (If we decide at some point, for example, that we want to be able to use multiple back-ends in a single compiler, then virtual functions are a good way of implementing that -- but we need to understand that there will be an indirection for every call to a back-end function. If that's too high a price to pay, then we won't want to do that. The point here is that "use virtual functions" should not be the goal; the goal should be "multiple back-ends" and then "use virtual functions" is just an implementation technique, with costs approximately equivalent to doing the same thing "by hand" in C.) I am certainly a "C++ guy", and I feel that all these features have their place, but I think we should err on the side of using less of C++, rather than more. We have C code that works, and we have a group of developers comfortable in C. We lose if we break our code, and even more if alienate those developers. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: [RFC] Switching implementation language to C++
On Mon, May 31, 2010 at 11:54 AM, Diego Novillo wrote: > On 10-05-31 12:50 , Gabriel Dos Reis wrote: > >> By switch, do you using a C++ compiler to compile everything, or that some >> components may be written only in C++ with sufficient care that they can >> be >> linked with other part written in C? > > Ideally, the former. If we cannot get consensus on that, then I guess we'd > have to settle for the latter. OK, thanks for the clarification.
Re: Using C++ in GCC is OK
On Mon, May 31, 2010 at 11:54 AM, Jakub Jelinek wrote: > On Mon, May 31, 2010 at 09:44:08AM -0700, Mark Mitchell wrote: >> >> I just really hope we will have strict criteria that any transition will >> >> not make compiler slower and will not increase compiler build time. >> > >> > Nor will grow the memory footprint, at least of the important data >> > structures, or increase maintanance costs by making the code less readable, >> > etc. >> >> There is no reason that use of C++ should increase the memory footprint >> of the compiler, make the compiler slower, or make the code less >> readable. Poor use of C++ might lead to those things; good use will >> not. That is why we need coding standards and patch review. > > E.g. when you start using virtual methods, suddenly you need a vtable > pointer in the object and thus the object grew by 8 bytes. aren't we already doing this with the various hooks we have? We do not need to generate RTTI if all we are interested in is vcalls. > In many cases it would be really addition of that pointer, dropping an 8/16 > bit code would slow things down too much (using virtual method to get you > say enum tree_code from a tree would be way too slow, similarly for rtti). Currently, we go through lot of manual checking with globals tables where the vcall mechanism already ensures that. I would suggest that when we are worrying about this kind of this, we also look at the alternatives we currently have and how they compare. > > Similarly if the compiler massively starts using virtual methods everywhere, > there will be slow downs caused by the increased number of harder to predict > indirect calls. that is why reviewers will use their best judgements, in particular to decide where a virtual function is preferable to a huge switch, current practice, which will generate more data than a vtable. > > Jakub >
Re: Using C++ in GCC is OK
On Mon, May 31, 2010 at 12:11:14PM -0500, Gabriel Dos Reis wrote: > aren't we already doing this with the various hooks we have? Currently hooks are used mainly for target or language hooks, that's far different from using virtual methods say on the tree or rtl objects. > We do not need to generate RTTI if all we are interested in is vcalls. I've mentioned that just that dropping the code field in tree objects would be a bad idea, even when there is a vtable pointer. > > In many cases it would be really addition of that pointer, dropping an 8/16 > > bit code would slow things down too much (using virtual method to get you > > say enum tree_code from a tree would be way too slow, similarly for rtti). > > Currently, we go through lot of manual checking with globals tables where > the vcall mechanism already ensures that. That kind of checking is done with --enable-checking only, for release compilers most of the checking isn't done and the macros result just into field accesses. Jakub
Re: Using C++ in GCC is OK
On Mon, May 31, 2010 at 12:02 PM, Mark Mitchell wrote: > Richard Guenther wrote: > > I think virtual functions are on the edge; quite useful, but do result > in the compiler adding a pointer to data objects and in uninlinable > indirect calls at run-time. Therefore, I would avoid them in the > initial subset of C++ used in GCC. In the current GCC source code, the additional data is already there in forms of enum codes that we use to distinguish various trees or types. To be clear, a virtual function should be used only when it is clear that there are more than one kind of information to be accessed, and that access requires dynamic resolution. Otherwise, we should either use a simple template or an enum. > I am certainly a "C++ guy", and I feel that all these features have > their place, but I think we should err on the side of using less of C++, > rather than more. We have C code that works, and we have a group of > developers comfortable in C. We lose if we break our code, and even > more if alienate those developers. There are good C++ coding standards out there, and I would be reluctant to encourage a NIH-driven design as opposed to adapting existing ones that have been given lot of considerations: http://www2.research.att.com/~bs/bs_faq2.html#coding-standard http://www2.research.att.com/~bs/JSF-AV-rules.pdf certainly there are elements there that are use for us to consider.
Re: Using C++ in GCC is OK
Gabriel Dos Reis wrote: > There are good C++ coding standards out there, and I would be reluctant > to encourage a NIH-driven design as opposed to adapting existing ones > that have been given lot of considerations: > >http://www2.research.att.com/~bs/bs_faq2.html#coding-standard >http://www2.research.att.com/~bs/JSF-AV-rules.pdf > > certainly there are elements there that are use for us to consider. I've already asked if someone wants to volunteer to put together coding standards. I'm happy for that to end up being some set of coding standards that already exist, whether Bjarne's, Google's, or whatever. I don't have any inherent desire to invent a completely fresh set of standards. On the other hand, as Bjarne says, the right subset is dependent on context. We're not in a safety-critical environment, we have a large existing C codebase, and we have a developer team made up of experienced C programmers, not all of whom are used to programming in C++. So, we need to take those factors into account. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: Using C++ in GCC is OK
Gabriel Dos Reis wrote: On Mon, May 31, 2010 at 11:54 AM, Jakub Jelinek wrote: Similarly if the compiler massively starts using virtual methods everywhere, there will be slow downs caused by the increased number of harder to predict indirect calls. that is why reviewers will use their best judgements, in particular to decide where a virtual function is preferable to a huge switch, current practice, which will generate more data than a vtable. Reviewers are frequently busy. I bet not a lot of reviewers apply patches and play with it. So it would be nice that people who submits such patches report changes in compile time/footprint/build time (at least I am going to ask this for parts which I review even if such changes in these parts will be not critical for whole compiler as tree or rtl infrastructure changes). Otherwise, we are in danger to get slowly degrading compiler.
Re: Using C++ in GCC is OK
On Mon, May 31, 2010 at 12:31 PM, Mark Mitchell wrote: > Gabriel Dos Reis wrote: > >> There are good C++ coding standards out there, and I would be reluctant >> to encourage a NIH-driven design as opposed to adapting existing ones >> that have been given lot of considerations: >> >> http://www2.research.att.com/~bs/bs_faq2.html#coding-standard >> http://www2.research.att.com/~bs/JSF-AV-rules.pdf >> >> certainly there are elements there that are use for us to consider. > > I've already asked if someone wants to volunteer to put together coding > standards. I'm happy for that to end up being some set of coding > standards that already exist, whether Bjarne's, Google's, or whatever. > I don't have any inherent desire to invent a completely fresh set of > standards. And I said I'm willing to help with that, as long as we don't have to rehash old debates as those we had end of '90s when EC++ popped up. > > On the other hand, as Bjarne says, the right subset is dependent on > context. We're not in a safety-critical environment, we have a large > existing C codebase, and we have a developer team made up of experienced > C programmers, not all of whom are used to programming in C++. So, we > need to take those factors into account. Definitely. That document is interesting in that it offers views and rationale about some of the restrictions being put forward. For example, I would not discount easily sections 4.10, 4.11, 4.12. -- Gaby
Re: Using C++ in GCC is OK
On Mon, May 31, 2010 at 12:33 PM, Vladimir Makarov wrote: > So it would be nice that people who submits such patches report changes in > compile time/footprint/build time I thought this has been part of our usual procedure for a while now. -- Gaby
Re: Using C++ in GCC is OK
Gabriel Dos Reis wrote: On Mon, May 31, 2010 at 12:33 PM, Vladimir Makarov wrote: So it would be nice that people who submits such patches report changes in compile time/footprint/build time I thought this has been part of our usual procedure for a while now. Well then a lot of people don't follow this procedure.
Re: Using C++ in GCC is OK
Mark Mitchell writes: > > I think virtual functions are on the edge; quite useful, but do result > in the compiler adding a pointer to data objects and in uninlinable > indirect calls at run-time. Therefore, I would avoid them in the Is that still true given profile feedback and the recent devirtualization work? I would assume the common case to get inlined then anyways. -Andi -- a...@linux.intel.com -- Speaking for myself only.
Re: [RFC] Switching implementation language to C++
On Mon, May 31, 2010 at 11:22, Diego Novillo wrote: > Now that the SC and the FSF have agreed to this. When did this come up and why? Where can I read more about this? Was there a thread I missed?
Re: [RFC] Switching implementation language to C++
On Mon, May 31, 2010 at 13:21, Michael Witten wrote: > On Mon, May 31, 2010 at 11:22, Diego Novillo wrote: >> Now that the SC and the FSF have agreed to this. > > When did this come up and why? Where can I read more about this? Was > there a thread I missed? Nevermind! It's a fairly recent thread :-)
Re: [RFC] Switching implementation language to C++
Diego Novillo wrote: >> By switch, do you using a C++ compiler to compile everything, or that >> some >> components may be written only in C++ with sufficient care that they >> can be >> linked with other part written in C? > > Ideally, the former. If we cannot get consensus on that, then I guess > we'd have to settle for the latter. I don't think a partial conversion strategy will be very successful. As soon as we use C++ in tree.h, we're going to have to use it everywhere. And, I suspect that using single inheritance in tree.h is the sort of change that will cut down on a fair bit of casting, possibly helping us to invalid conversions. That doesn't necessarily mean that we have to use lots of C++ features everywhere. We can use the C (almost) subset of C++ if we want to in some places. As an example, if the Fortran folks want to use C in the Fortran front-end, then -- except to the extent required by the common interfaces, those files could read as if they were C code. But, I think they'd still need to be compiled with a C++ compiler because they'll probably pull in headers that use C++ constructs. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: [RFC] Switching implementation language to C++
On Mon, May 31, 2010 at 1:25 PM, Mark Mitchell wrote: > Diego Novillo wrote: > >>> By switch, do you using a C++ compiler to compile everything, or that >>> some >>> components may be written only in C++ with sufficient care that they >>> can be >>> linked with other part written in C? >> >> Ideally, the former. If we cannot get consensus on that, then I guess >> we'd have to settle for the latter. > > I don't think a partial conversion strategy will be very successful. As > soon as we use C++ in tree.h, we're going to have to use it everywhere. > And, I suspect that using single inheritance in tree.h is the sort of > change that will cut down on a fair bit of casting, possibly helping us > to invalid conversions. > > That doesn't necessarily mean that we have to use lots of C++ features > everywhere. We can use the C (almost) subset of C++ if we want to in > some places. As an example, if the Fortran folks want to use C in the > Fortran front-end, then -- except to the extent required by the common > interfaces, those files could read as if they were C code. But, I think > they'd still need to be compiled with a C++ compiler because they'll > probably pull in headers that use C++ constructs. > Yes, this is the sort of issues I have in mind. For example, I do not see how we can use C++ in tree.h without requiring other front-ends to use C++, at least for the parts that use tree.h. By components, I meant "for example, is it the case that the C++ front-end would use C++, but with sufficient care that it can be linked with the common C codes if the C front-end is not using C++?". -- Gaby
Re: Using C++ in GCC is OK
Andi Kleen wrote: >> I think virtual functions are on the edge; quite useful, but do result >> in the compiler adding a pointer to data objects and in uninlinable >> indirect calls at run-time. Therefore, I would avoid them in the > > Is that still true given profile feedback and the recent > devirtualization work? I would assume the common case > to get inlined then anyways. I don't think we have enough evidence to make that a safe assumption. I would prefer to be conservative in making this transition; we have a consensus that we want to use C++, but quite a few people who are concerned about what that means in practice, and so I think we should make the transition slowly and carefully. Don't get me wrong; I think virtual functions are very useful. The "target hooks" and "language hooks" we have are essentially "poor man's" virtual functions, and we could naturally (and mechanically) convert them to actual virtual functions. That's why I think virtual functions are on the edge. If the consensus is that it's OK to use them now that's OK by me, but I'd prefer to keep them out of the initial set of coding guidelines. I would, however, expect that they will be one of the first advanced features to make their way into GCC in the future. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: [RFC] Switching implementation language to C++
Gabriel Dos Reis wrote: > Yes, this is the sort of issues I have in mind. For example, I do not see how > we can use C++ in tree.h without requiring other front-ends to use C++, at > least > for the parts that use tree.h. By components, I meant "for example, is it the > case that the C++ front-end would use C++, but with sufficient care > that it can be > linked with the common C codes if the C front-end is not using C++?". Yes, I think it's possible for a front-end or a back-end to use C++ without the rest of the compiler doing so. I doubt that's where we get maximum bang from allowing use of C++, but it could certainly be done. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
How to find out register information at the beginning of a basic block?
Hi, I am working on generating vzeroupper to avoid AVX->SSE transition penalty. I have generated vzeroupper on function return as well as function call. I am working on a backend pass to eliminate those vzeroupper instructions when I can prove that the upper 128bits of AVX registers are dead at the point where vzeroupper is added. To do that, I need to find out if a register is live at the beginning of a basic block as well as its size. I thought dataflow might give me such info. But I couldn't find a way to access such information. Does anyone have any pointers? BTW, I have a PDF file to describe how vzeroupper is added. But the PDF attachment was rejected by the gcc mailing list. Please send me an email if you want it. Thanks. -- H.J.
Re: [RFC] Switching implementation language to C++
Am 31.05.2010 20:50, schrieb Mark Mitchell: > Gabriel Dos Reis wrote: > >> Yes, this is the sort of issues I have in mind. For example, I do not see >> how >> we can use C++ in tree.h without requiring other front-ends to use C++, at >> least >> for the parts that use tree.h. By components, I meant "for example, is it >> the >> case that the C++ front-end would use C++, but with sufficient care >> that it can be >> linked with the common C codes if the C front-end is not using C++?". > > Yes, I think it's possible for a front-end or a back-end to use C++ > without the rest of the compiler doing so. I doubt that's where we get > maximum bang from allowing use of C++, but it could certainly be done. I think the C -> C++ switch is in terms of compiling GCC an all or nothing: You need have all of a sudden a C++ compiler for bootstrapping; otherwise, the middle end and all front ends should be C++ save thanks to to work of Ian et al. and -Wc++-compat. Thus, you get all the avantages and disadvantage of C++ and a C++ compiler everywhere. And as long as the code remains clear to a little-experience C++ compiler (at least, e.g., the middle-end code to which a front end programmer is exposed), I also do not see a problem for C++. Whether and to what extend the different parts of the compilers will switch, remains to be seen. I could imagine that some C++ will slowly creep in everywhere. Tobias, who is rather agnostic about the change, but who does not want to see overloaded operators of the type "+" or "*" (neither in C++ nor in Fortran).
Re: [RFC] Switching implementation language to C++
On Mon, May 31, 2010 at 1:50 PM, Mark Mitchell wrote: > Gabriel Dos Reis wrote: > >> Yes, this is the sort of issues I have in mind. For example, I do not see >> how >> we can use C++ in tree.h without requiring other front-ends to use C++, at >> least >> for the parts that use tree.h. By components, I meant "for example, is it >> the >> case that the C++ front-end would use C++, but with sufficient care >> that it can be >> linked with the common C codes if the C front-end is not using C++?". > > Yes, I think it's possible for a front-end or a back-end to use C++ > without the rest of the compiler doing so. I doubt that's where we get > maximum bang from allowing use of C++, but it could certainly be done. OK, I will reformulate my question to you and Diego is: is this what we want, e.g. C++ as THE common implementation language, or just ONE common implementation language (the other being C)? I asking for the purpose of formulating tentative guidelines. -- Gaby
Re: How to find out register information at the beginning of a basic block?
H.J. Lu wrote: Hi, I am working on generating vzeroupper to avoid AVX->SSE transition penalty. I have generated vzeroupper on function return as well as function call. I am working on a backend pass to eliminate those vzeroupper instructions when I can prove that the upper 128bits of AVX registers are dead at the point where vzeroupper is added. To do that, I need to find out if a register is live at the beginning of a basic block as well as its size. I thought dataflow might give me such info. But I couldn't find a way to access such information. Does anyone have any pointers? DF_LR_IN (bb) returns bitmap of livings prseudo regnos. DF_LIVE_IN (bb) takes availability info into account. Size of hard registers is defined by hard_regno_nregs. It is more complicated if you need the size of pseudo. The class of pseudo is necessary for this but even if you know this there are complicated situations, e.g. on x86 pseudo of FLOAT_INT_REGS in DFmode cant take 2 general registers and 1 float reg. BTW, I have a PDF file to describe how vzeroupper is added. But the PDF attachment was rejected by the gcc mailing list. Please send me an email if you want it.
Re: Using C++ in GCC is OK
On Mon, 2010-05-31 at 11:48 -0700, Mark Mitchell wrote:
> Andi Kleen wrote:
>
> Don't get me wrong; I think virtual functions are very useful. The
> "target hooks" and "language hooks" we have are essentially "poor man's"
> virtual functions, and we could naturally (and mechanically) convert
> them to actual virtual functions.
The GGC marking routines are probably also somehow like virtual
functions, even if they are not implemented as function pointers.
What I mean is that today, the following generated function (from
gtype-desc.c in the build tree)
void
gt_pch_nx_eh_region_d (void *x_p)
{
struct eh_region_d * const x = (struct eh_region_d *)x_p;
if (gt_pch_note_object (x, x, gt_pch_p_11eh_region_d,
gt_ggc_e_11eh_region_d))
{
gt_pch_n_11eh_region_d ((*x).outer);
gt_pch_n_11eh_region_d ((*x).inner);
gt_pch_n_11eh_region_d ((*x).next_peer);
switch ((*x).type)
{
case ERT_TRY:
gt_pch_n_10eh_catch_d ((*x).u.eh_try.first_catch);
gt_pch_n_10eh_catch_d ((*x).u.eh_try.last_catch);
break;
case ERT_ALLOWED_EXCEPTIONS:
gt_pch_n_9tree_node ((*x).u.allowed.type_list);
gt_pch_n_9tree_node ((*x).u.allowed.label);
break;
case ERT_MUST_NOT_THROW:
gt_pch_n_9tree_node ((*x).u.must_not_throw.failure_decl);
break;
default:
break;
}
gt_pch_n_16eh_landing_pad_d ((*x).landing_pads);
gt_pch_n_7rtx_def ((*x).exc_ptr_reg);
gt_pch_n_7rtx_def ((*x).filter_reg);
}
}
could probably be replaced by a virtual function to mark each
eh_region_d, and have 3 subclasses of these for the ERT_TRY,
ERT_ALLOWED_EXCEPTIONS, ERT_MUST_NOT_THROW cases.
I would believe that replacing a complex function like above (which
contains a switch) with a virtual function call could probably be a win
in performance, not a loose.
But perhaps my intuition is wrong. Honestly, I don't have exact figures
of the cost of virtual calls. IIRC, they have been costly for Intel
processors more than 5 years ago (but AMD processors perhaps run them
quicker at that time), but current Intel & AMD processors probably deal
better with indirect jump, so a virtual call is perhaps a with w.r.t. a
complex switch like above.
Another point where virtual functions will greatly help is for dump code
used when debugging GCC & passing some -fdump-... option to GCC.
Besides, in that case, the speed of the dump does not matter much.
Still, my concerns on C++ is mostly gengtype related. I believe we need
to keep a garbage collector even with C++, and I believe that changing
gengtype to follow C++ could be quite painful if we follow the usual
route of parsing our headers. Making a gengtype able to parse almost any
C++ header file would be painful.
Cheers.
--
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] Switching implementation language to C++
Gabriel Dos Reis wrote: > OK, I will reformulate my question to you and Diego is: is this what we want, > e.g. C++ as THE common implementation language, or just ONE common > implementation language (the other being C)? I believe that we want (a subset of) C++ to be the language used to implement all of GCC, including front-ends, back-ends, and common code. Where we currently use C, we wish to instead use C++. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: [RFC] Switching implementation language to C++
On Mon, May 31, 2010 at 15:33, Mark Mitchell wrote: > I believe that we want (a subset of) C++ to be the language used to > implement all of GCC, including front-ends, back-ends, and common code. > Where we currently use C, we wish to instead use C++. That's what I want as well. Diego.
Re: [RFC] Switching implementation language to C++
On Mon, May 31, 2010 at 2:35 PM, Diego Novillo wrote: > On Mon, May 31, 2010 at 15:33, Mark Mitchell wrote: > >> I believe that we want (a subset of) C++ to be the language used to >> implement all of GCC, including front-ends, back-ends, and common code. >> Where we currently use C, we wish to instead use C++. > > That's what I want as well. OK, thanks to both of you. -- Gaby
Re: possible license issue (documentation generated from source) in MELT branch of GCC
Basile Starynkevitch wrote: > To my greatest & extremely positive surprise, I got today an answer from > the FSF (I really am very happy of such a quick answer)! I hope it OK to > cite here part of the reply I've got to my question [gnu.org #579118] > to licens...@fsf.org since Karl Berry replied to me >From RMS' comments on the SC list, I'm not sure if Karl had full context. His answer is certainly reasonable as an explanation of how you could create a project that had GPL'd code and GFDL'd manuals. Whether or not it's an answer to how the FSF wants to deal with the code it owns, however, is not obvious to me. I have asked RMS to clarify. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: [RFC] Switching implementation language to C++
On 05/31/2010 06:22 PM, Diego Novillo wrote: Now that the SC and the FSF have agreed to this, we should decide whether we switch and how. So, I would like comments on the following questions: H, when I voted "yes" on the question "Requiring C++ Compiler for GCC Builds" (that was the subject of the mail to the Steering Committee mailing list to discuss this), I had the following in mind: 1- Should we switch to C++? Yes, otherwise I wouldn't have taken the time to ponder this. In fact, if not for the hordes of people that are only too eager to use every nook and cranny of the C++ language, I would have been much more supportive, as the situation we're finding ourselves in today is as if we were to write a Fortran 2003 compiler using only features from Fortran 77 plus (DE)ALLOCATE. This simply isn't leading us into a maintainable future. 2- What is the cost in terms of build time? Vladimir Makarov already addressed this. 3- What coding guidelines should we use? We might need some time to find the right coding standards for *our* use. What I wrote in my e-mail to the SC mailing list to support my stance was the following: "The useful part is to be able to use stl data structures and functions to do the hard work in the compiler instead of using specially-written tree-, list-, bitmap-, queue- and stack-creators, destroyers and walkers." because I think that would be *immediately* useful, as in ... 4- Should we make the switch during the 4.6 stage 1? ... version 4.6. Of course I agree with Richard Guenther that - *if done well and completely* - turning the tree data type into a class is desirable. However, that might simply be too much for the approximately 6 months remaining of 4.6's stage 1. Cheers, -- 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/gcc-4.5/changes.html#Fortran
Re: [RFC] Switching implementation language to C++
On Mon, 2010-05-31 at 12:33 -0700, Mark Mitchell wrote:
> Gabriel Dos Reis wrote:
>
> > OK, I will reformulate my question to you and Diego is: is this what we
> > want,
> > e.g. C++ as THE common implementation language, or just ONE common
> > implementation language (the other being C)?
>
> I believe that we want (a subset of) C++ to be the language used to
> implement all of GCC, including front-ends, back-ends, and common code.
>Where we currently use C, we wish to instead use C++.
You forgot to mention plugins. In my understanding, any future GCC
plugin would necessarily be coded in C++ and be compiled by a C++
compiler. Am I right?
The consequence would be that future GCC could be built on a system with
any C compiler, but only a C++ one.
I would even imagine that later, one could configure GCC to have only a
C++ front-end, but no more a C one. That probably would be unusual,
since many important applications which want to be compiled by GCC (I am
thinking of the Linux kernel) will continue to exist in C. But I would
believe that a future GCC with only a C++ frontend and without a C
frontend would be possible, and be able to bootstrap (i.e. make stage3),
which is not true today. IIRC, today's GCC (i.e. 4.5) cannot even be
configured to have a C++ front-end without having a C front-end. Do we
want to change that?
Cheers.
--
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: How to find out register information at the beginning of a basic block?
On Mon, May 31, 2010 at 12:31 PM, Vladimir Makarov wrote:
> H.J. Lu wrote:
>>
>> Hi,
>>
>> I am working on generating vzeroupper to avoid AVX->SSE transition
>> penalty.
>>
>> I have generated vzeroupper on function return as well as function
>> call. I am working on a backend pass to eliminate those vzeroupper
>> instructions when I can prove that the upper 128bits of AVX registers
>> are dead at the point where vzeroupper is added. To do that, I need
>> to find out if a register is live at the beginning of a basic block as
>> well
>> as its size. I thought dataflow might give me such info. But I couldn't
>> find a way to access such information. Does anyone have any pointers?
>>
>>
>
> DF_LR_IN (bb) returns bitmap of livings prseudo regnos.
> DF_LIVE_IN (bb) takes availability info into account.
>
> Size of hard registers is defined by hard_regno_nregs.
>
> It is more complicated if you need the size of pseudo. The class of pseudo
> is necessary for this but even if you know this there are complicated
> situations, e.g.
The new backend pass is run as the last pass and doesn't deal with pseudo
registers. I have
df_chain_add_problem (DF_UD_CHAIN + DF_DU_CHAIN); <<< Is this correct?
df_analyze ();
FOR_EACH_BB (curr_block)
{
bool upper_128bits_live = false;
bitmap live_in = DF_LIVE_IN (curr_block);
...
}
df_finish_pass (false);
> on x86 pseudo of FLOAT_INT_REGS in DFmode cant take 2 general registers and
> 1 float reg.
>
Thanks.
--
H.J.
Re: How to find out register information at the beginning of a basic block?
H.J. Lu wrote: On Mon, May 31, 2010 at 12:31 PM, Vladimir Makarov wrote: H.J. Lu wrote: Hi, I am working on generating vzeroupper to avoid AVX->SSE transition penalty. I have generated vzeroupper on function return as well as function call. I am working on a backend pass to eliminate those vzeroupper instructions when I can prove that the upper 128bits of AVX registers are dead at the point where vzeroupper is added. To do that, I need to find out if a register is live at the beginning of a basic block as well as its size. I thought dataflow might give me such info. But I couldn't find a way to access such information. Does anyone have any pointers? DF_LR_IN (bb) returns bitmap of livings prseudo regnos. DF_LIVE_IN (bb) takes availability info into account. Size of hard registers is defined by hard_regno_nregs. It is more complicated if you need the size of pseudo. The class of pseudo is necessary for this but even if you know this there are complicated situations, e.g. The new backend pass is run as the last pass and doesn't deal with pseudo registers. I have df_chain_add_problem (DF_UD_CHAIN + DF_DU_CHAIN); <<< Is this correct? I don't think you need all these chains (of course if you really need it). It is time consuming. I guess df_live_add_problem () will be enough.
Re: possible license issue (documentation generated from source) in MELT branch of GCC
On Mon, 2010-05-31 at 12:51 -0400, Robert Dewar wrote:
> Basile Starynkevitch wrote:
>
> > To my greatest & extremely positive surprise, I got today an answer from
> > the FSF (I really am very happy of such a quick answer)! I hope it OK to
> > cite here part of the reply I've got to my question [gnu.org #579118]
> > to licens...@fsf.org since Karl Berry replied to me
> >
> >
> >> The FSF has already officially approved and recommended the strategy
> >> mentioned in your message, and throughout the thread: dual-license,
> >> under the GPL and GFDL, material that applies to both code and
> >> manuals,
> >> or is auto-generated from one to the other.
> >>
> >> In your case, you are generating documentation from the code. So, put
> >> a
> >> license notice in the original (GPL'd) source files that the
> >> documentation so generated is also available under the FDL.
> >> Automatically insert an FDL license statement in the generated
> files.
> >
> >
> > Regards and thanks to everybody!
>
> Great, it's always good when you hit an established FAQ to which
> the answer is already available
I did wrote on http://gcc.gnu.org/ml/gcc-patches/2010-05/msg02442.html
about the patch I intend to apply to the MELT branch (changing copyright
notice of gcc/melt/warmelt*.melt files there).
I also emailed k...@gnu.org about that.
If someone objects to this copyright/license notice change patch please
tell me as soon as possible.
Cheers.
--
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: Using C++ in GCC is OK
> Because C++ is a big language, I think we should try to enumerate what > is OK, rather than what is not OK. > Is there anyone who would like to volunteer to develop the C++ coding > standards? I hope you you don't mind my question (as I am currently not an active GCC developer), but what is the point of this? I understand why you do not want to have sudden, disruptive changes to a large existing code base, so any introduction of C++ features should be careful and controlled, but why artificially eliminate parts of the language? I personally think the coding standard should be: "All C++ code has to be 1) easily readable, 2) easily maintainable, and 3) produce efficient machine code and conserve memory. Apart from that use ISO/IEC 14882-1998". Now I know that this is totally unrealistic in the context of the GCC project, and some people here get really nervous about a potential C++ creep, but IMHO artificial limitations on a pure syntax base are not really meaningful. One should look at the consequences and not at the syntax. Thomas
Re: Using C++ in GCC is OK
Thomas Neumann wrote: Now I know that this is totally unrealistic in the context of the GCC project, and some people here get really nervous about a potential C++ creep, but IMHO artificial limitations on a pure syntax base are not really meaningful. One should look at the consequences and not at the syntax. Well anyone can think anything, but this view is way out of the mainstream. I do not know of a single large real project using a large complex language that does not have coding standards that limit the use of the language.
Re: [RFC] Switching implementation language to C++
Basile Starynkevitch wrote: > You forgot to mention plugins. In my understanding, any future GCC > plugin would necessarily be coded in C++ and be compiled by a C++ > compiler. Am I right? Not necessarily. If we felt it desirable, the interface exposed for plug-ins could be C, not C++. However, I would expect it would be better to expose a C++ API. We'll have to see what consensus emerges on that point. (I do not feel that plug-ins should have full access to GCC's internals; I want to see a structured API that permits plug-ins access to a documented, stable interface.) > I would even imagine that later, one could configure GCC to have only a > C++ front-end, but no more a C one. I suppose, though thinking about that doesn't seem a great use of time at this point. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: Using C++ in GCC is OK
> Well anyone can think anything, but this view is way out of the > mainstream. I do not know of a single large real project using a > large complex language that does not have coding standards that > limit the use of the language. I know this, but I do not understand this. I have worked in reasonably large commercial projects. Admittedly only one had had more than a hundred active developers (which in fact was the one with the most loose coding standards). But as far as I have seen it coding standards are either in the spirit of what I had proposed (emphasizing code quality over language features) or are an over-detailed mess that is a pain in practice and gives no reasonable justification for the imposed limitations. I would like to prevent the later for GCC. But this is getting off-topic, GCC will probably limit itself to "C with classes" anyway. Which in my opinion is a shame, but such is life. Thomas
Re: Using C++ in GCC is OK
Quoting Vladimir Makarov : Reviewers are frequently busy. I bet not a lot of reviewers apply patches and play with it. So it would be nice that people who submits such patches report changes in compile time/footprint/build time (at least I am going to ask this for parts which I review even if such changes in these parts will be not critical for whole compiler as tree or rtl infrastructure changes). Otherwise, we are in danger to get slowly degrading compiler. I'm not sure that this will be effective against bloat creep. When considering one small patch that slows down the compiler (and/or slows down build time) by 0.1%, the difference will be in the noise and impossible to measure with a manageable sample size. But if you combine 1100 of such small patches, the compiler will be three times slower. So, unless we can get some coding style/review mechanism in place that prevents such bloat creep by examining the source code change and the area where it is applied, I think we would need a way to magnify the performance impact of abstraction penalties. E.g. if the penalty is a vtable lookup, making it take a hundred times more specifically in the changed places would magnify the 0.1% overall change to a measurable delta of 10%.
Re: Using C++ in GCC is OK
Quoting Gabriel Dos Reis : Definitely. That document is interesting in that it offers views and rationale about some of the restrictions being put forward. For example, I would not discount easily sections 4.10, 4.11, 4.12. I think we have grounds to modify 4.11 . : AV Rule 98: :Every nonlocal name, except main(), should be placed in some namespace. I think for global symbols that are part of the plugin interface, C linkage is preferable, because that allows to implement the plugins with C and other languages that allow for linking with C code. Moreover, it protects the plugin interface from variations in name mangling over time or across different C++ implementations. We should also evaluate carefully if debugging helper functions (e.g. ones that are called by a dubugger like gdb or vender-supplied debugger) are better off with C linkage for stability & compatibility. : AV Rule 99 : Namespaces will not be nested more than two levels deep. :AV Rule 100 : Elements from a namespace should be selected as follows: : · using declaration or explicit qualification for few :(approximately five) names, : · using directive for many names. Would this be solely applied to explicitly coded namespace usage, or also to namespace usage introduced by the build infrastructure? My approach to combine multiple backends puts functions duplicated across different backends into different namespaces. If you have already exhausted two namespace nesting in the general code, that would add a third layer. Also, the selection of namespace members is restricted to what can be readily done with macros given the known context, and it is not known in the first place how many members there are to be selected in the first place.
Re: Using C++ in GCC is OK
On 05/31/2010 04:36 PM, Thomas Neumann wrote: Well anyone can think anything, but this view is way out of the mainstream. I do not know of a single large real project using a large complex language that does not have coding standards that limit the use of the language. I know this, but I do not understand this. I have worked in reasonably large commercial projects. Admittedly only one had had more than a hundred active developers (which in fact was the one with the most loose coding standards). But as far as I have seen it coding standards are either in the spirit of what I had proposed (emphasizing code quality over language features) or are an over-detailed mess that is a pain in practice and gives no reasonable justification for the imposed limitations. I would like to prevent the later for GCC. But this is getting off-topic, GCC will probably limit itself to "C with classes" anyway. Which in my opinion is a shame, but such is life. Maybe I am reading too much into what Mark has been saying but from a practical view, nothing is going to happen quickly. Maybe the question shouldn't be phrased in terms that make it sound like a C++ feature will never be used but in terms of which have the clearest near-term impact. So this is defining the first set of C++ features to use. We should not open the floodgate to every C++ feature without due consideration. Focus on features that are easy to take advantage of in the code now and have high payback on maintainability and readability. This gives us an orderly transition and a chance for those GCC developers who are not expert C++ programmers to learn on the job. I think that "C with classes" with single inheritance and using the standard library where appropriate are the logical first step. That's enough surgery and the payback is high. It also forces the examination of public interfaces, bootstrap compiler issues, etc. Another thing that has bothered me is the fear of getting slower. If using C++ makes GCC slower, then GCC C++ needs to get faster. This is eating our own dog food. :) Thomas --joel sherrill
Re: Using C++ in GCC is OK
On Tue, Jun 1, 2010 at 1:12 AM, Joel Sherrill wrote: > Another thing that has bothered me is the fear of > getting slower. If using C++ makes GCC slower, then > GCC C++ needs to get faster. This is eating our own > dog food. :) Indeed. If we can avoid the obvious problems (vtables, etc.) there is no reason why using C++ should lead to a slower compiler. If we can properly hide some things better, maybe we can even help our own optimizers. With some of the union tricks GCC plays now, GCC has to make the worst-case assumptions when building itself. If we can solve this with C++ we may actually get a faster compiler! (fingers crossed...) Things like bootstrapping with LTO (in whopr more, hopefully the default for GCC 4.6?) may also help reduce the potential extra overhead of using C++. Ciao! Steven
Re: Using C++ in GCC is OK
On 05/31/10 14:30, Basile Starynkevitch wrote: [snip] > I would believe that replacing a complex function like above (which > contains a switch) with a virtual function call could probably be a win > in performance, not a loose. > > But perhaps my intuition is wrong. Honestly, I don't have exact figures > of the cost of virtual calls. IIRC, they have been costly for Intel > processors more than 5 years ago (but AMD processors perhaps run them > quicker at that time), but current Intel & AMD processors probably deal > better with indirect jump, so a virtual call is perhaps a with w.r.t. a > complex switch like above. [snip] The following post to the boost devel list: http://sourceforge.net/mailarchive/message.php?msg_name=3f49a9f41003031715g19a23b94p47ccec2251acd55%40mail.gmail.com claims that switch statements are faster than virtual function calls. There's also this boost devel list post: http://lists.boost.org/Archives/boost/2008/01/132074.php where, instead of a virtual function table, a vector of function pointers is used. Using this method, I assume, would have a speed comparable to that of using a virtual function table since a virtual function table, IIUC, is essentially a vector of function pointers. However, that boost devel post claims using a switch statement would be faster. HTH. -regards, Larry
Re: Using C++ in GCC is OK
On Mon, May 31, 2010 at 6:29 PM, Larry Evans wrote: > However, that boost devel post claims using a switch statement would > be faster. Switching to C++ should never be excuse to bring more more brittle codes or more obscurities. Rather, it should be opportunity to write simpler and better code. The compiler has gotten better lately in devirtualization. We are the compiler guys. If our implementation shows that we can do better with virtual functions, then we should be improving the compiler -- not only we get a faster compiler, but for the end user we get a compiler that generates much better code. And that is a win win. None of that should be construed as an argument for using virtual functions in GCC. Rather, it is argument for resisting desperate actions.
Re: How to find out register information at the beginning of a basic block?
On Mon, May 31, 2010 at 12:31 PM, Vladimir Makarov wrote: > H.J. Lu wrote: >> >> Hi, >> >> I am working on generating vzeroupper to avoid AVX->SSE transition >> penalty. >> >> I have generated vzeroupper on function return as well as function >> call. I am working on a backend pass to eliminate those vzeroupper >> instructions when I can prove that the upper 128bits of AVX registers >> are dead at the point where vzeroupper is added. To do that, I need >> to find out if a register is live at the beginning of a basic block as >> well >> as its size. I thought dataflow might give me such info. But I couldn't >> find a way to access such information. Does anyone have any pointers? >> >> > > DF_LR_IN (bb) returns bitmap of livings prseudo regnos. > DF_LIVE_IN (bb) takes availability info into account. > > Size of hard registers is defined by hard_regno_nregs. > My impression is hard_regno_nregs tells me that number of hard registers given machine mode occupy. It doesn't tell me the live size of a hard register at the beginning of a basic block. How do I get this information? Thanks. -- H.J.
Question on REG_EQUAL documentation
The GCC internal document says [1]: [quote] In the early stages of register allocation, a REG_EQUAL note is changed into a REG_EQUIV note if op is a constant and the insn represents the only set of its destination register. Thus, compiler passes prior to register allocation need only check for REG_EQUAL notes and passes subsequent to register allocation need only check for REG_EQUIV notes. [/quote] But I still find REG_EQUAL notes in RTL dumps for those passes after IRA. My understanding is: a REG_EQUAL note is changed into a REG_EQUIV note in IRA when possible, but the remaining REG_EQUAL notes are still kept around. So the compiler passes after register allocation need check for both REG_EQUIV notes and REG_EQUAL notes. Is my understanding correct? [1] http://gcc.gnu.org/onlinedocs/gccint/Insns.html#index-REG_005fEQUIV-2258 -- Jie Zhang CodeSourcery (650) 331-3385 x735
Re: [RFC] Switching implementation language to C++
On May 31, 2010, at 14:25, Mark Mitchell wrote: > That doesn't necessarily mean that we have to use lots of C++ features > everywhere. We can use the C (almost) subset of C++ if we want to in > some places. As an example, if the Fortran folks want to use C in the > Fortran front-end, then -- except to the extent required by the common > interfaces, those files could read as if they were C code. But, I think > they'd still need to be compiled with a C++ compiler because they'll > probably pull in headers that use C++ constructs. I don't see why the implementation language of the front end should necessarily be tied to that of the back end. One of the benefits we should get from switching implementation language is a cleaner interface between the language-specific parts of the compiler and the shared back end files. For the Ada compiler, we've never found it a disadvantage to use Ada as implementation language, even though the back end is written in C. The hard parts of mapping Ada idioms to the intermediate languages used in the back end have never been related to the language used for implementing the front end or back end. If anything, the strict separation between front end and back end data structures has helped avoiding inadvertent reuse of representations for constructs with similar yet subtly different properties. Ideally, when having a full C++ definition of the back end interface, we can use straight type and function definitions, instead of webs of header files with macro definitions. Maybe, some day, we could even use Ada directly to interface with libbackend, eliminating the last remaining non-Ada code in the Ada front end. However, it seems backwards to decide wether we want to change implementation language before we even have an outline of a design for a new interface, or at least some agreement on design goals. If we do not have a path to rewriting tree.h and friends using C++ to raise the abstraction level and improve maintainability of GCC (while maintaining performance and avoiding overgeneralization and needless complexity), I am not sure the cost of moving to C++ will result in many gains. Once we're using C++, there will be a great temptation to use overly complex data structures that would have been inconceivable with C. The best defense against this is a clear design that, at least for the most significant data structures, specifies the interface that is going to be used. Here is where we decide how we're going to do memory management, where we need dynamic data structures, where we may need dispatching etc. If we're just going to get some new power tools for our workshop and let people have at it, the lessons we'll learn might end up being more about what not to do, rather than a show case of their effective use. In short, what we seem to be missing is a clear objective on what we want to accomplish by switching to C++ and how we'll reach those goals. Without that, switching might be ill considered and not in GCC's best interest in the long run. -Geert
Re: How to find out register information at the beginning of a basic block?
On 05/31/2010 08:17 PM, H.J. Lu wrote: On Mon, May 31, 2010 at 12:31 PM, Vladimir Makarov wrote: H.J. Lu wrote: Hi, I am working on generating vzeroupper to avoid AVX->SSE transition penalty. I have generated vzeroupper on function return as well as function call. I am working on a backend pass to eliminate those vzeroupper instructions when I can prove that the upper 128bits of AVX registers are dead at the point where vzeroupper is added. To do that, I need to find out if a register is live at the beginning of a basic block as well as its size. I thought dataflow might give me such info. But I couldn't find a way to access such information. Does anyone have any pointers? DF_LR_IN (bb) returns bitmap of livings prseudo regnos. DF_LIVE_IN (bb) takes availability info into account. Size of hard registers is defined by hard_regno_nregs. My impression is hard_regno_nregs tells me that number of hard registers given machine mode occupy. It doesn't tell me the live size of a hard register at the beginning of a basic block. How do I get this information? If you mean what part of hard register lives, then as I know there is no such infrastructure code. As I remember Ken Zadeck tried to implement something analogous in the old RA. You could try to find this code in archives.
Re: [RFC] Switching implementation language to C++
Geert Bosch wrote: > If we're just going to get some new power tools for our workshop > and let people have at it, the lessons we'll learn might end up > being more about what not to do, rather than a show case of their > effective use. That's why we're not doing that. Instead, we're going to determine what subset of C++ we're comfortable using, and then we're going to let people propose ways of using that subset. Nobody's suggesting letting people run around using their favorite C++ features in random ways. This is a chicken-egg thing. We couldn't reasonably ask people to start proposing ways of using C++ without knowing that the SC would allow it to be used. Now we've got that approval, and now people can suggest uses. I've already implicitly suggested one, namely, using single inheritance to implement the tree data structures, thereby avoiding casts up and down the hierarchy. Including, for example, declaring a routine that's supposed to take a DECL as taking a tree_decl&, instead of just a tree *. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: possible license issue (documentation generated from source) in MELT branch of GCC
On Mon, 2010-05-31 at 22:46 +0200, Basile Starynkevitch wrote:
>
> I did wrote on http://gcc.gnu.org/ml/gcc-patches/2010-05/msg02442.html
> about the patch I intend to apply to the MELT branch (changing copyright
> notice of gcc/melt/warmelt*.melt files there).
>
> I also emailed k...@gnu.org about that.
I have been asked by Karl Berry to wait several days before making that
patch. So I will.
Cheers.
--
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: trampolines handling, important copyright question
Basile Starynkevitch writes: > What I am very scared of, is to make someone at FSF unhappy or angry > against me. I have a very fuzzy perception of the FSF [I'm living on a > different continent, I am not a native English speaker, etc..]. I don't > know who is an influent member of FSF and did met me once to be able to > put a face (mine) on MELT. Perhaps David Edelsohn or Diego Novillo or > Ian Taylor [or even Sebastian Pop] are important people at the FSF. I > really don't know (but I guess most of them are)! And I really don't > understand the difference (not in role, but in the set of people) > between GCC steering committee and FSF. I am guessing that they have > mostly the same people wearing different hats. If I remember correctly, > David Edelsohn did tell once at some GCC Summit that he is member of FSF > board, but I might have remembered incorrectly. I just wanted to clarify that none of the people you mention are actual directors or employees of the FSF. The members of the FSF may be found at these web pages: http://www.fsf.org/about/leadership.html http://www.fsf.org/about/staff/ For each FSF software project there is a designated maintainer who is responsible for handling FSF requests and concerns. For the GCC project the designated maintainer is the GCC steering committee. The members of the GCC steering committee are listed at http://gcc.gnu.org/steering.html Ian
Re: GCC documentation in .info
christophe.ja...@ouvaton.org writes: > I browsed your html documentation at http://gcc.gnu.org/onlinedocs/ > and would like to know if there is a way to obtain GCC documentation > in .info format from your website, as is proposed by almost all other > software projects from GNU (see > http://www.gnu.org/software/gawk/manual/ for example). This message would be more appropriate for the mailing list gcc-h...@gcc.gnu.org. Please take any followups to gcc-help. Thanks. The gcc .info files are not currently distributed separately. They are included if you download a gcc release. Ian
Re: Using C++ in GCC is OK
Mark Mitchell writes: > I am pleased to report that the GCC Steering Committee and the FSF have > approved the use of C++ in GCC itself. Of course, there's no reason for > us to use C++ features just because we can. The goal is a better > compiler for users, not a C++ code base for its own sake. I would like to thank Mark and the SC for securing this agreement. > Before we start to actually use C++, we need to determine a set of > coding standards that will apply to use of C++ within GCC. I have written a proposed set of C++ coding conventions on the wiki at http://gcc.gnu.org/wiki/CppConventions This is only a preliminary proposal. It requires fleshing out and discussion. Comments welcome. Ian
