This is the mail archive of the
mailing list for the GCC project.
Re: Using C++ in GCC is OK
- From: VÃclav Haisman <v dot haisman at sh dot cvut dot cz>
- To: Joern Rennecke <amylaar at spamcop dot net>
- Cc: Vladimir Makarov <vmakarov at redhat dot com>, Gabriel Dos Reis <gdr at integrable-solutions dot net>, Jakub Jelinek <jakub at redhat dot com>, Mark Mitchell <mark at codesourcery dot com>, GCC <gcc at gcc dot gnu dot org>
- Date: Tue, 01 Jun 2010 10:13:37 +0200
- Subject: Re: Using C++ in GCC is OK
- References: "<4C030228.firstname.lastname@example.org> <4C03DD15.email@example.com> <20100531161637.GA26878@sunsite.ms.mff.cuni.cz> <4C03E758.firstname.lastname@example.org> <20100531165411.GB26878@sunsite.ms.mff.cuni.cz> <AANLkTikdIfpWvpx7sKsaBv-9a14EUaaltKLKQO3CF2mS@mail.gmail.com>" <4C03F2DB.email@example.com> <firstname.lastname@example.org>
On Mon, 31 May 2010 18:24:00 -0400, Joern Rennecke wrote:
> Quoting Vladimir Makarov <email@example.com>:
>> 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
> build time) by 0.1%, the difference will be in the noise and impossible
> measure with a manageable sample size.
> But if you combine 1100 of such small patches, the compiler will be
> times slower.
> So, unless we can get some coding style/review mechanism in place that
> such bloat creep by examining the source code change and the area where
> 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,
> it take a hundred times more specifically in the changed places would
> magnify the 0.1% overall change to a measurable delta of 10%.
Your argument is applicable to any changes in GCC, not just to C to C++
conversions. Do patches that slow down the current C code base by 0.1% get
rejected? They do not.