Switching to C++ by default in 4.8

Switching to C++ by default in 4.8

[Diego Novillo]

We would like to start the process to make GCC 4.8 build in C++ mode by 
default.

The mechanics of the change are simple enough.  I volunteer to test 
changing the default on all primary targets (assuming I can get them 
from the GCC build farm).

Concurrently with this, Lawrence and Ian are working on the C++ coding 
guidelines.  The draft is stored at 
http://gcc.gnu.org/wiki/CppConventions.  They will be sending an update 
in the next few days.  The idea is to hash out the details on the wiki 
and then produce a patch to http://gcc.gnu.org/codingconventions.html.

While these two changes are independent, it probably makes sense to 
first have agreement on an initial set of coding conventions before we 
switch the default.

I expect that coding conventions will evolve quite a bit in the next few 
months, so we should do the switch after the first patch to 
codingconventions.html is approved and installed.  A reasonable initial 
version of this should cover the core language features that allow 
implementing basic conversions (for instance, those that would allow 
re-implementing vec.h).

I would like to avoid discussions to drag on indefinitely.  But, given 
the magnitude of these changes, I suppose that it may take a few days to 
hash it out.  Therefore, I propose that:

- For the coding conventions, we have the explicit approval of at least 
4 global reviewers.
- For the build changes, approval from a build maintainer should be enough.


Thanks.  Diego.

Re: Switching to C++ by default in 4.8

[Paweł Sikora]

On Tuesday 03 of April 2012 13:37:50 Diego Novillo wrote:
> 
> Concurrently with this, Lawrence and Ian are working on the C++ coding 
> guidelines.  The draft is stored at http://gcc.gnu.org/wiki/CppConventions.

what about using http://astyle.sourceforge.net/astyle.html for code checkers?
what about -Woverloaded-virtual [-Werror] by default?

Re: Switching to C++ by default in 4.8

[Ian Lance Taylor]

Paweł Sikora <pluto@agmk.net> writes:

> On Tuesday 03 of April 2012 13:37:50 Diego Novillo wrote:
>> 
>> Concurrently with this, Lawrence and Ian are working on the C++ coding 
>> guidelines.  The draft is stored at http://gcc.gnu.org/wiki/CppConventions.
>
> what about using http://astyle.sourceforge.net/astyle.html for code checkers?

I don't think we want to automatically reformat the entire GCC codebase.
Or at least, if we do, we don't want to confuse that with the C++
transition.


> what about -Woverloaded-virtual [-Werror] by default?

Sounds good to me.  -Werror will of course be on by default for stage 2
and 3 development builds.  Want to add a cxx_strict_warn along the lines
of c_strict_warn in gcc/configure.ac and gcc/Makefile.in?

Ian

Re: Switching to C++ by default in 4.8

[Paweł Sikora]

On Tuesday 03 of April 2012 13:51:56 Ian Lance Taylor wrote:
> Paweł Sikora <pluto@agmk.net> writes:
> 
> > On Tuesday 03 of April 2012 13:37:50 Diego Novillo wrote:
> >> 
> >> Concurrently with this, Lawrence and Ian are working on the C++ coding 
> >> guidelines.  The draft is stored at http://gcc.gnu.org/wiki/CppConventions.
> >
> > what about using http://astyle.sourceforge.net/astyle.html for code checkers?
> 
> I don't think we want to automatically reformat the entire GCC codebase.
> Or at least, if we do, we don't want to confuse that with the C++
> transition.

i'm only suggesting that astyle (or another tool) can be used in svn pre-commit
hook to verifying gnu formatting rules (incoming files can be extracted from
svn transaction to /tmp and checked). manual formatting rules reviewing @gcc-patches
is waste of time.

Re: Switching to C++ by default in 4.8

[Joseph S. Myers]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=utf-8, Size: 566 bytes --]

On Tue, 3 Apr 2012, PaweÅ~B Sikora wrote:

> i'm only suggesting that astyle (or another tool) can be used in svn pre-commit
> hook to verifying gnu formatting rules (incoming files can be extracted from

I think it's a bad idea to check anything in a pre-commit hook that isn't 
also covered by a normal build and testsuite run.  Commit time is too late 
for detecting problems with patches; if you want automatic style checks 
then make them cause the build or testsuite run to fail if there are 
problems.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Switching to C++ by default in 4.8

[Basile Starynkevitch]

On Tue, 03 Apr 2012 13:51:56 -0700
Ian Lance Taylor <iant@google.com> wrote:

> Paweł Sikora <pluto@agmk.net> writes:
> 
> > On Tuesday 03 of April 2012 13:37:50 Diego Novillo wrote:
> >> 
> >> Concurrently with this, Lawrence and Ian are working on the C++ coding 
> >> guidelines.  The draft is stored at http://gcc.gnu.org/wiki/CppConventions.
> >
> > what about using http://astyle.sourceforge.net/astyle.html for code checkers?
> 
> I don't think we want to automatically reformat the entire GCC codebase.
> Or at least, if we do, we don't want to confuse that with the C++
> transition.


But I believe we could install as a rule that every genuine C++ source file be indented
with 
   astyle -gnu -s2
and perhaps even provide an 'indent' make target for that purpose.

I really think that systematic reindentation would help us a lot.

What do you think?

Cheers
-- 
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***

Re: Switching to C++ by default in 4.8

[David Edelsohn]

On Tue, Apr 3, 2012 at 1:37 PM, Diego Novillo <dnovillo@google.com> wrote:
>
> We would like to start the process to make GCC 4.8 build in C++ mode by
> default.
>
> The mechanics of the change are simple enough.  I volunteer to test changing
> the default on all primary targets (assuming I can get them from the GCC
> build farm).

I appreciate the motivation, but this may cause major problems on
non-GNU/Linux platforms.  Testing on all primary targets is not
enough.

Do you expect GCC to be able to bootstrap starting from a vendor C++
compiler or will this require G++?

What is the earliest release of G++ that will allow GCC to bootstrap?

Thanks, David

Re: Switching to C++ by default in 4.8

[Ian Lance Taylor]

David Edelsohn <dje.gcc@gmail.com> writes:

> Do you expect GCC to be able to bootstrap starting from a vendor C++
> compiler or will this require G++?

In principle it should be possible to start from a vendor C++ compiler.
Of course we will have to test in order to see.

> What is the earliest release of G++ that will allow GCC to bootstrap?

Another thing that is worth testing.  Right now I would anticipate that
even fairly old releases of G++ can bootstrap GCC.  However, we will
need to decide what old release we want to ensure works.

Ian

Re: Switching to C++ by default in 4.8

[Miles Bader]

Ian Lance Taylor <iant@google.com> writes:
>> What is the earliest release of G++ that will allow GCC to bootstrap?
>
> Another thing that is worth testing.  Right now I would anticipate that
> even fairly old releases of G++ can bootstrap GCC.  However, we will
> need to decide what old release we want to ensure works.

4.2 at the latest might be a good idea, given its continued widespread
use in "scared of the GPL3"[*] communities (*BSD, the pre-clang llvm
frontend, the pathscale/path64 compiler frontend, etc)...

[*] stronger language omitted for diplomatic reasons

-miles

-- 
Zeal, n. A certain nervous disorder afflicting the young and inexperienced.

Re: Switching to C++ by default in 4.8

[Gabriel Dos Reis]

On Tue, Apr 3, 2012 at 8:13 PM, David Edelsohn <dje.gcc@gmail.com> wrote:
> On Tue, Apr 3, 2012 at 1:37 PM, Diego Novillo <dnovillo@google.com> wrote:
>>
>> We would like to start the process to make GCC 4.8 build in C++ mode by
>> default.
>>
>> The mechanics of the change are simple enough.  I volunteer to test changing
>> the default on all primary targets (assuming I can get them from the GCC
>> build farm).
>
> I appreciate the motivation, but this may cause major problems on
> non-GNU/Linux platforms.  Testing on all primary targets is not
> enough.
>
> Do you expect GCC to be able to bootstrap starting from a vendor C++
> compiler or will this require G++?

I would expect that we use C++03, and any C++ compiler.

> What is the earliest release of G++ that will allow GCC to bootstrap?

Any G++ from the last five years should be good.

-- Gaby

Re: Switching to C++ by default in 4.8

[Richard Guenther]

On Wed, Apr 4, 2012 at 10:32 AM, Gabriel Dos Reis
<gdr@integrable-solutions.net> wrote:
> On Tue, Apr 3, 2012 at 8:13 PM, David Edelsohn <dje.gcc@gmail.com> wrote:
>> On Tue, Apr 3, 2012 at 1:37 PM, Diego Novillo <dnovillo@google.com> wrote:
>>>
>>> We would like to start the process to make GCC 4.8 build in C++ mode by
>>> default.
>>>
>>> The mechanics of the change are simple enough.  I volunteer to test changing
>>> the default on all primary targets (assuming I can get them from the GCC
>>> build farm).
>>
>> I appreciate the motivation, but this may cause major problems on
>> non-GNU/Linux platforms.  Testing on all primary targets is not
>> enough.
>>
>> Do you expect GCC to be able to bootstrap starting from a vendor C++
>> compiler or will this require G++?
>
> I would expect that we use C++03, and any C++ compiler.

Yes.  Thus, for stage1 we should force -std=c++03 -pedantic if we
build with GCC to
avoid creep in of GNU features.

Btw, I think we should only start forcing C++ when 1) there is a
branch/patch out
that shows benefit from using C++.  I previously mentioned that I'd like to see
2) a patch that _properly_ wraps a C++ class for consumption by our garbage
collector (thus, not a hack that works for a specific case but infrastructure
that we think will work for _all_ cases, including libstdc++ container use).

So - I'll veto the switch unless I see 1) and 2).  1) and 2) can be combined
by transitioning vec.h to a C++ template class, with proper GC support.
(not sure that I can veto anything - heh)

Thanks,
Richard.

Re: Switching to C++ by default in 4.8

[Gabriel Dos Reis]

On Wed, Apr 4, 2012 at 4:06 AM, Richard Guenther
<richard.guenther@gmail.com> wrote:

> (not sure that I can veto anything - heh)

I found out that is the only power a Release Manager has -- apart from
fixing the bug himself or herself  ;-p

-- Gaby

Re: Switching to C++ by default in 4.8

[Gabriel Dos Reis]

On Wed, Apr 4, 2012 at 4:06 AM, Richard Guenther
<richard.guenther@gmail.com> wrote:
> On Wed, Apr 4, 2012 at 10:32 AM, Gabriel Dos Reis
> <gdr@integrable-solutions.net> wrote:
>> On Tue, Apr 3, 2012 at 8:13 PM, David Edelsohn <dje.gcc@gmail.com> wrote:
>>> On Tue, Apr 3, 2012 at 1:37 PM, Diego Novillo <dnovillo@google.com> wrote:
>>>>
>>>> We would like to start the process to make GCC 4.8 build in C++ mode by
>>>> default.
>>>>
>>>> The mechanics of the change are simple enough.  I volunteer to test changing
>>>> the default on all primary targets (assuming I can get them from the GCC
>>>> build farm).
>>>
>>> I appreciate the motivation, but this may cause major problems on
>>> non-GNU/Linux platforms.  Testing on all primary targets is not
>>> enough.
>>>
>>> Do you expect GCC to be able to bootstrap starting from a vendor C++
>>> compiler or will this require G++?
>>
>> I would expect that we use C++03, and any C++ compiler.
>
> Yes.  Thus, for stage1 we should force -std=c++03 -pedantic if we
> build with GCC to
> avoid creep in of GNU features.

Fully agreed.

> Btw, I think we should only start forcing C++ when 1) there is a
> branch/patch out
> that shows benefit from using C++.  I previously mentioned that I'd like to see
> 2) a patch that _properly_ wraps a C++ class for consumption by our garbage
> collector (thus, not a hack that works for a specific case but infrastructure
> that we think will work for _all_ cases, including libstdc++ container use).

I was actually thinking starting with abstractions that do not interact directly
with the memory manager, because I would like us to get our feet wet
before doing the full plunge.  Such a work would be confined to a part of
the compiler (say the C++ front-end).  Any particular reason you would
like to start
with the garbage collector which touches just about anything?

-- Gaby

Re: Switching to C++ by default in 4.8

[Richard Guenther]

On Wed, Apr 4, 2012 at 11:15 AM, Gabriel Dos Reis
<gdr@integrable-solutions.net> wrote:
> On Wed, Apr 4, 2012 at 4:06 AM, Richard Guenther
> <richard.guenther@gmail.com> wrote:
>> On Wed, Apr 4, 2012 at 10:32 AM, Gabriel Dos Reis
>> <gdr@integrable-solutions.net> wrote:
>>> On Tue, Apr 3, 2012 at 8:13 PM, David Edelsohn <dje.gcc@gmail.com> wrote:
>>>> On Tue, Apr 3, 2012 at 1:37 PM, Diego Novillo <dnovillo@google.com> wrote:
>>>>>
>>>>> We would like to start the process to make GCC 4.8 build in C++ mode by
>>>>> default.
>>>>>
>>>>> The mechanics of the change are simple enough.  I volunteer to test changing
>>>>> the default on all primary targets (assuming I can get them from the GCC
>>>>> build farm).
>>>>
>>>> I appreciate the motivation, but this may cause major problems on
>>>> non-GNU/Linux platforms.  Testing on all primary targets is not
>>>> enough.
>>>>
>>>> Do you expect GCC to be able to bootstrap starting from a vendor C++
>>>> compiler or will this require G++?
>>>
>>> I would expect that we use C++03, and any C++ compiler.
>>
>> Yes.  Thus, for stage1 we should force -std=c++03 -pedantic if we
>> build with GCC to
>> avoid creep in of GNU features.
>
> Fully agreed.
>
>> Btw, I think we should only start forcing C++ when 1) there is a
>> branch/patch out
>> that shows benefit from using C++.  I previously mentioned that I'd like to see
>> 2) a patch that _properly_ wraps a C++ class for consumption by our garbage
>> collector (thus, not a hack that works for a specific case but infrastructure
>> that we think will work for _all_ cases, including libstdc++ container use).
>
> I was actually thinking starting with abstractions that do not interact directly
> with the memory manager, because I would like us to get our feet wet
> before doing the full plunge.  Such a work would be confined to a part of
> the compiler (say the C++ front-end).  Any particular reason you would
> like to start
> with the garbage collector which touches just about anything?

Because the garbage collector is the thing that will block reasonable use
of C++ if we cannot get it working.  And because of the fear that if we
don't show how to do it _right_ first then people will start inventing a dozent
different ways of making it work for a special case.

Note that I don't think it will touch everything.  I remember we discussed how
to do it and basically settled on something like

template <class T>
struct gc_mark {
  static void mark (T *) {}
}

and specializations that actually do something meaningful.

which we can provide specializations for all existing types walked by
gengtype trivially.  This would provide a way to support GCing objects
whose types are not "supported" by gengtype - gengtype would simply
emit gc_mark<T>::mark () calls which are trivially optimized away
if there is nothing to mark.

That said - somebody would need to prototype that, and VEC is a good
candidate I think because it's used both with GC and non-GC memory.

Richard.

> -- Gaby

Re: Switching to C++ by default in 4.8

[Richard Guenther]

On Wed, Apr 4, 2012 at 11:59 AM, Richard Guenther
<richard.guenther@gmail.com> wrote:
> On Wed, Apr 4, 2012 at 11:15 AM, Gabriel Dos Reis
> <gdr@integrable-solutions.net> wrote:
>> On Wed, Apr 4, 2012 at 4:06 AM, Richard Guenther
>> <richard.guenther@gmail.com> wrote:
>>> On Wed, Apr 4, 2012 at 10:32 AM, Gabriel Dos Reis
>>> <gdr@integrable-solutions.net> wrote:
>>>> On Tue, Apr 3, 2012 at 8:13 PM, David Edelsohn <dje.gcc@gmail.com> wrote:
>>>>> On Tue, Apr 3, 2012 at 1:37 PM, Diego Novillo <dnovillo@google.com> wrote:
>>>>>>
>>>>>> We would like to start the process to make GCC 4.8 build in C++ mode by
>>>>>> default.
>>>>>>
>>>>>> The mechanics of the change are simple enough.  I volunteer to test changing
>>>>>> the default on all primary targets (assuming I can get them from the GCC
>>>>>> build farm).
>>>>>
>>>>> I appreciate the motivation, but this may cause major problems on
>>>>> non-GNU/Linux platforms.  Testing on all primary targets is not
>>>>> enough.
>>>>>
>>>>> Do you expect GCC to be able to bootstrap starting from a vendor C++
>>>>> compiler or will this require G++?
>>>>
>>>> I would expect that we use C++03, and any C++ compiler.
>>>
>>> Yes.  Thus, for stage1 we should force -std=c++03 -pedantic if we
>>> build with GCC to
>>> avoid creep in of GNU features.
>>
>> Fully agreed.
>>
>>> Btw, I think we should only start forcing C++ when 1) there is a
>>> branch/patch out
>>> that shows benefit from using C++.  I previously mentioned that I'd like to see
>>> 2) a patch that _properly_ wraps a C++ class for consumption by our garbage
>>> collector (thus, not a hack that works for a specific case but infrastructure
>>> that we think will work for _all_ cases, including libstdc++ container use).
>>
>> I was actually thinking starting with abstractions that do not interact directly
>> with the memory manager, because I would like us to get our feet wet
>> before doing the full plunge.  Such a work would be confined to a part of
>> the compiler (say the C++ front-end).  Any particular reason you would
>> like to start
>> with the garbage collector which touches just about anything?
>
> Because the garbage collector is the thing that will block reasonable use
> of C++ if we cannot get it working.  And because of the fear that if we
> don't show how to do it _right_ first then people will start inventing a dozent
> different ways of making it work for a special case.
>
> Note that I don't think it will touch everything.  I remember we discussed how
> to do it and basically settled on something like
>
> template <class T>
> struct gc_mark {
>  static void mark (T *) {}
> }
>
> and specializations that actually do something meaningful.
>
> which we can provide specializations for all existing types walked by
> gengtype trivially.  This would provide a way to support GCing objects
> whose types are not "supported" by gengtype - gengtype would simply
> emit gc_mark<T>::mark () calls which are trivially optimized away
> if there is nothing to mark.
>
> That said - somebody would need to prototype that, and VEC is a good
> candidate I think because it's used both with GC and non-GC memory.

This will, of course, be also a challenge for various non-GCC host C++
compilers ;)  (let's hope they get this part of templates right ... thus,
let's avoid the need to do partial specialization at least).

> Richard.
>
>> -- Gaby

Re: Switching to C++ by default in 4.8

[Diego Novillo]

On 4/4/12 5:06 AM, Richard Guenther wrote:

> Btw, I think we should only start forcing C++ when 1) there is a
> branch/patch out
> that shows benefit from using C++.  I previously mentioned that I'd like to see
> 2) a patch that _properly_ wraps a C++ class for consumption by our garbage
> collector (thus, not a hack that works for a specific case but infrastructure
> that we think will work for _all_ cases, including libstdc++ container use).

My idea was to start with something like converting VEC() which would 
require dealing with GC.

I did not intend to make the conversion and the switch as a single 
operation, however.  Seemed like too much to change in a single patch.

> So - I'll veto the switch unless I see 1) and 2).  1) and 2) can be combined
> by transitioning vec.h to a C++ template class, with proper GC support.
> (not sure that I can veto anything - heh)

Well, none of us can, really.  Except maybe RMs in the context of 
release branches.


Diego.

Re: Switching to C++ by default in 4.8

[Richard Guenther]

On Wed, Apr 4, 2012 at 1:20 PM, Diego Novillo <dnovillo@google.com> wrote:
> On 4/4/12 5:06 AM, Richard Guenther wrote:
>
>> Btw, I think we should only start forcing C++ when 1) there is a
>> branch/patch out
>> that shows benefit from using C++.  I previously mentioned that I'd like
>> to see
>> 2) a patch that _properly_ wraps a C++ class for consumption by our
>> garbage
>> collector (thus, not a hack that works for a specific case but
>> infrastructure
>> that we think will work for _all_ cases, including libstdc++ container
>> use).
>
>
> My idea was to start with something like converting VEC() which would
> require dealing with GC.
>
> I did not intend to make the conversion and the switch as a single
> operation, however.  Seemed like too much to change in a single patch.
>
>
>> So - I'll veto the switch unless I see 1) and 2).  1) and 2) can be
>> combined
>> by transitioning vec.h to a C++ template class, with proper GC support.
>> (not sure that I can veto anything - heh)

I think vec.h is the canonical example of something that we agree on that
using C++ is an improvement and a case where we have to get GC support
right.

If you say the changes doing GC "right" and transforming vec.h are too big
to be done together, then well.  You only know if you did things right
if you have both the "new" GC and a user (vec.h in C++).  So yes, maybe
too big for a patch but not too big for a branch (where you could merge
the GC infrastructure changes separately from the vec.h change).  But
both need to be developed together.

Oh, and did we address all the annoyances of debugging gcc when it's
compiled by a C++ compiler? ...

Richard.

> Well, none of us can, really.  Except maybe RMs in the context of release
> branches.
>
>
> Diego.

Re: Switching to C++ by default in 4.8

[Tom Tromey]

>>>>> "Richard" == Richard Guenther <richard.guenther@gmail.com> writes:

Richard> Oh, and did we address all the annoyances of debugging gcc when it's
Richard> compiled by a C++ compiler? ...

If you mean gdb problems, please file bugs.

Tom

Re: Switching to C++ by default in 4.8

[Richard Guenther]

On Wed, Apr 4, 2012 at 4:12 PM, Tom Tromey <tromey@redhat.com> wrote:
>>>>>> "Richard" == Richard Guenther <richard.guenther@gmail.com> writes:
>
> Richard> Oh, and did we address all the annoyances of debugging gcc when it's
> Richard> compiled by a C++ compiler? ...
>
> If you mean gdb problems, please file bugs.

I think I filed the most annoying one already, passing cut&pasted addresses
to inferior calls and gdb doing funny overload resolution on the pointer types.
Not sure what its status is.

Richard.

> Tom

Re: Switching to C++ by default in 4.8

[Richard Guenther]

On Wed, Apr 4, 2012 at 4:45 PM, Richard Guenther
<richard.guenther@gmail.com> wrote:
> On Wed, Apr 4, 2012 at 4:12 PM, Tom Tromey <tromey@redhat.com> wrote:
>>>>>>> "Richard" == Richard Guenther <richard.guenther@gmail.com> writes:
>>
>> Richard> Oh, and did we address all the annoyances of debugging gcc when it's
>> Richard> compiled by a C++ compiler? ...
>>
>> If you mean gdb problems, please file bugs.
>
> I think I filed the most annoying one already, passing cut&pasted addresses
> to inferior calls and gdb doing funny overload resolution on the pointer types.
> Not sure what its status is.

Seems unfixed: http://sourceware.org/bugzilla/show_bug.cgi?id=13356

> Richard.
>
>> Tom

Re: Switching to C++ by default in 4.8

[Chiheng Xu]

On Wed, Apr 4, 2012 at 7:38 PM, Richard Guenther
<richard.guenther@gmail.com> wrote:
>
> Oh, and did we address all the annoyances of debugging gcc when it's
> compiled by a C++ compiler? ...
>

Probably, if you can refrain from using some "advance" C++
features(namespace, template, etc.),  you will not have such
annoyances.

-- 
Chiheng Xu

Re: Switching to C++ by default in 4.8

[Robert Dewar]

On 4/13/2012 9:34 PM, Chiheng Xu wrote:
> On Wed, Apr 4, 2012 at 7:38 PM, Richard Guenther
> <richard.guenther@gmail.com>  wrote:
>>
>> Oh, and did we address all the annoyances of debugging gcc when it's
>> compiled by a C++ compiler? ...
>>
>
> Probably, if you can refrain from using some "advance" C++
> features(namespace, template, etc.),  you will not have such
> annoyances.

To me namespaces are fundamental in terms of the advantages that
moving to C++ can give in a large project, I would never regard
them as some "advanced" feature to be avoided. If namespaces
cause trouble for the debugger, that's surprising and problematic!
>

Re: Switching to C++ by default in 4.8

[Chiheng Xu]

On Sat, Apr 14, 2012 at 5:09 PM, Robert Dewar <dewar@adacore.com> wrote:
> On 4/13/2012 9:34 PM, Chiheng Xu wrote:
>>
>> On Wed, Apr 4, 2012 at 7:38 PM, Richard Guenther
>> <richard.guenther@gmail.com>  wrote:
>>>
>>>
>>> Oh, and did we address all the annoyances of debugging gcc when it's
>>> compiled by a C++ compiler? ...
>>>
>>
>> Probably, if you can refrain from using some "advance" C++
>> features(namespace, template, etc.),  you will not have such
>> annoyances.
>
>
> To me namespaces are fundamental in terms of the advantages that
> moving to C++ can give in a large project, I would never regard
> them as some "advanced" feature to be avoided. If namespaces
> cause trouble for the debugger, that's surprising and problematic!
>>
>>
>

If debugger fully support namespace, that will be nice. I just say,
in case debugger have trouble with namespace, you can avoid it.

But personally, when I write C++ code, I never use namespace.  I
always prefix my class name(and corresponding source file names) with
proper module name, and put the all source files of a module in its
dedicated sub-directory .  This make class name globally unique
throughout the project, and facilitate further re-factoring(searching
and replacing).

When using namespace,  people can and tend to use the same name in
different namespaces,  this seems like a advantage, but I see it as a
disadvantage. If you want to change a name in one namespace to some
other more accurate/proper name,  you use some search tools to search
all the references of the name, you will find that the name is
probably also used in other namespaces, so you just can't use "replace
all" command to replace all references with the new name, you must
manually replace them one by one. Is this what you want ?.

And, frankly speaking, I don't like "::".   For example A::B, sometime
it means name B in namespace A, sometime it means member B of class A.
This depend whether A is class or namespace. But when you first read
code, this information is unclear, you must guess, until you have read
enough code to known what A is.


-- 
Chiheng Xu

Re: Switching to C++ by default in 4.8

[Robert Dewar]

On 4/14/2012 6:02 AM, Chiheng Xu wrote:

> If debugger fully support namespace, that will be nice. I just say,
> in case debugger have trouble with namespace, you can avoid it.
>
> But personally, when I write C++ code, I never use namespace.  I
> always prefix my class name(and corresponding source file names) with
> proper module name, and put the all source files of a module in its
> dedicated sub-directory .  This make class name globally unique
> throughout the project, and facilitate further re-factoring(searching
> and replacing).

I find that rather a horrible substitute for proper use of namespaces.
I know it is common, partly because that's what you have to do in C,
and partly because namespac3es were added late
>
> When using namespace,  people can and tend to use the same name in
> different namespaces,  this seems like a advantage, but I see it as a
> disadvantage.

I think that is a seriously misguided position. There is a good reason
for adding namespaces (Ada has always had this kind of capability in
the form of packages, and the package concept in Ada is, to Ada
programmers, one of its most powerful features). Since you never use
namespaces, it is not surprising that you do not appreicate their
importance.

To me, the ability to make extensive use of namespaces is one of
the strong arguments for switching to C++

> If you want to change a name in one namespace to some
> other more accurate/proper name,  you use some search tools to search
> all the references of the name, you will find that the name is
> probably also used in other namespaces, so you just can't use "replace
> all" command to replace all references with the new name, you must
> manually replace them one by one. Is this what you want ?.

You use proper tools that do the replacement just of references to
the entity whose name you want to change. It is often the case that
people avoid use of features because of a lack of proper tools, but
certainly there are tools that can do this kind of intelligent
replacement (GPS from AdaCore is one such example, but we certainly
wouldn't suggest it was unique in this respect!)

Re: Switching to C++ by default in 4.8

[Jonathan Wakely]

On 14 April 2012 11:02, Chiheng Xu wrote:
>
> If debugger fully support namespace, that will be nice. I just say,
> in case debugger have trouble with namespace, you can avoid it.

So it's completely unfounded speculation then.

> But personally, when I write C++ code, I never use namespace.  I
> always prefix my class name(and corresponding source file names) with
> proper module name, and put the all source files of a module in its
> dedicated sub-directory .  This make class name globally unique
> throughout the project, and facilitate further re-factoring(searching
> and replacing).

Find'n'replace is not refactoring.

Re: Switching to C++ by default in 4.8

[Gabriel Dos Reis]

On Sat, Apr 14, 2012 at 4:09 AM, Robert Dewar <dewar@adacore.com> wrote:
> On 4/13/2012 9:34 PM, Chiheng Xu wrote:
>>
>> On Wed, Apr 4, 2012 at 7:38 PM, Richard Guenther
>> <richard.guenther@gmail.com>  wrote:
>>>
>>>
>>> Oh, and did we address all the annoyances of debugging gcc when it's
>>> compiled by a C++ compiler? ...
>>>
>>
>> Probably, if you can refrain from using some "advance" C++
>> features(namespace, template, etc.),  you will not have such
>> annoyances.
>
>
> To me namespaces are fundamental in terms of the advantages that
> moving to C++ can give in a large project, I would never regard
> them as some "advanced" feature to be avoided. If namespaces
> cause trouble for the debugger, that's surprising and problematic!

Indeed, the notion that 'namspace' is "advance" is troublesome.
Similarly I would find any notion that simple uses  and definitions
of templates (functions, datatypes) "advanced" a bit specious.

Re: Switching to C++ by default in 4.8

[Robert Dewar]

On 4/14/2012 6:39 AM, Gabriel Dos Reis wrote:

> Indeed, the notion that 'namspace' is "advance" is troublesome.
> Similarly I would find any notion that simple uses  and definitions
> of templates (functions, datatypes) "advanced" a bit specious.

Indeed! In the case of templates there is a real issue, in that
we all know that misuse of templates can get completely out of
hand, but to suggest banning all templates is not a supportable
notion.

Re: Switching to C++ by default in 4.8

[Chiheng Xu]

On Sat, Apr 14, 2012 at 7:07 PM, Robert Dewar <dewar@adacore.com> wrote:
> hand, but to suggest banning all templates is not a supportable
> notion.
>

Why ?


-- 
Chiheng Xu

Re: Switching to C++ by default in 4.8

[Jonathan Wakely]

On 16 April 2012 10:36, Chiheng Xu wrote:
> On Sat, Apr 14, 2012 at 7:07 PM, Robert Dewar <dewar@adacore.com> wrote:
>> hand, but to suggest banning all templates is not a supportable
>> notion.
>>
>
> Why ?

Because they're useful.

Re: Switching to C++ by default in 4.8

[Robert Dewar]

On 4/16/2012 5:36 AM, Chiheng Xu wrote:
> On Sat, Apr 14, 2012 at 7:07 PM, Robert Dewar<dewar@adacore.com>  wrote:
>> hand, but to suggest banning all templates is not a supportable
>> notion.
>>
>
> Why ?
>
>
Because some simple uses of templates are very useful, and
not problematic from any point of view.

Re: Switching to C++ by default in 4.8

[Pedro Lamarão]

On 04/04/2012 08:20 AM, Diego Novillo wrote:
> On 4/4/12 5:06 AM, Richard Guenther wrote:
>
>> Btw, I think we should only start forcing C++ when 1) there is a
>> branch/patch out
>> that shows benefit from using C++. I previously mentioned that I'd
>> like to see
>> 2) a patch that _properly_ wraps a C++ class for consumption by our
>> garbage
>> collector (thus, not a hack that works for a specific case but
>> infrastructure
>> that we think will work for _all_ cases, including libstdc++ container
>> use).
>
> My idea was to start with something like converting VEC() which would
> require dealing with GC.

Is anyone currently working or this?

I'm not experienced in the code base, but this project seems fascinating.

--
  P.

Re: Switching to C++ by default in 4.8

[Richard Guenther]

On Thu, Apr 5, 2012 at 2:41 PM, Pedro Lamarão <pedro.lamarao@gmail.com> wrote:
> On 04/04/2012 08:20 AM, Diego Novillo wrote:
>>
>> On 4/4/12 5:06 AM, Richard Guenther wrote:
>>
>>> Btw, I think we should only start forcing C++ when 1) there is a
>>> branch/patch out
>>> that shows benefit from using C++. I previously mentioned that I'd
>>> like to see
>>> 2) a patch that _properly_ wraps a C++ class for consumption by our
>>> garbage
>>> collector (thus, not a hack that works for a specific case but
>>> infrastructure
>>> that we think will work for _all_ cases, including libstdc++ container
>>> use).
>>
>>
>> My idea was to start with something like converting VEC() which would
>> require dealing with GC.
>
>
> Is anyone currently working or this?
>
> I'm not experienced in the code base, but this project seems fascinating.

I'm not aware of anyone - so go ahead (if you happen to have a copyright
assignment on file).  Try to avoid to have to adjust vec.h users at start,
thus keep the macro wrappings (to the extent this is possible, of course).
The GC part is most interesting, the vec.h part should be quite obvious.

Richard.

> --
>  P.
>
>

Re: Switching to C++ by default in 4.8

[Diego Novillo]

On Thu, Apr 5, 2012 at 09:04, Richard Guenther
<richard.guenther@gmail.com> wrote:
> On Thu, Apr 5, 2012 at 2:41 PM, Pedro Lamarão <pedro.lamarao@gmail.com> wrote:
>>
>> Is anyone currently working or this?
>>
>> I'm not experienced in the code base, but this project seems fascinating.
>
> I'm not aware of anyone - so go ahead (if you happen to have a copyright
> assignment on file).


I will be, after the switch to C++ is done.  Pedro, if you do have a
copyright assignment, feel free to start working on this.  I suggest
creating a branch for this (I can handle that today).  If you need
forms for the copyright assignment, let me know and I'll forward them
to you.


Diego.

Re: Switching to C++ by default in 4.8

[Richard Guenther]

On Thu, Apr 5, 2012 at 4:21 PM, Diego Novillo <dnovillo@google.com> wrote:
> On Thu, Apr 5, 2012 at 09:04, Richard Guenther
> <richard.guenther@gmail.com> wrote:
>> On Thu, Apr 5, 2012 at 2:41 PM, Pedro Lamarão <pedro.lamarao@gmail.com> wrote:
>>>
>>> Is anyone currently working or this?
>>>
>>> I'm not experienced in the code base, but this project seems fascinating.
>>
>> I'm not aware of anyone - so go ahead (if you happen to have a copyright
>> assignment on file).
>
>
> I will be, after the switch to C++ is done.

Which means never, because I think it's a prerequesite for switching?

;)

Richard.

> Pedro, if you do have a
> copyright assignment, feel free to start working on this.  I suggest
> creating a branch for this (I can handle that today).  If you need
> forms for the copyright assignment, let me know and I'll forward them
> to you.
>
>
> Diego.

Re: Switching to C++ by default in 4.8

[Diego Novillo]

On Thu, Apr 5, 2012 at 10:24, Richard Guenther
<richard.guenther@gmail.com> wrote:

> Which means never, because I think it's a prerequesite for switching?

No.  I was not clear.  By "done", I meant that GCC builds with C++ in
all the platforms we can test.

I'm sending a testing plan later today with the list of targets I
think should be tested.  I am expecting to do some adjusting patches
to get all the targets working.

Whether the vec.h conversion is committed simultaneously with the C++
switch is a minor issue.  The cleanup patches for C++ will certainly
need to be committed first.


Diego.

Re: Switching to C++ by default in 4.8

[David Edelsohn]

On Thu, Apr 5, 2012 at 10:36 AM, Diego Novillo <dnovillo@google.com> wrote:
> On Thu, Apr 5, 2012 at 10:24, Richard Guenther
> <richard.guenther@gmail.com> wrote:
>
>> Which means never, because I think it's a prerequesite for switching?
>
> No.  I was not clear.  By "done", I meant that GCC builds with C++ in
> all the platforms we can test.
>
> I'm sending a testing plan later today with the list of targets I
> think should be tested.  I am expecting to do some adjusting patches
> to get all the targets working.

I tried bootstrapping on AIX using C++.

I am able to bootstrap using G++, but not with IBM xlC.  xlC is able
to compile the GCC source code (with a lot of warning messages), but
the build fails when the build passes GCC-specific no exception flags
to xlC.

NOEXCEPTION_FLAGS = -fno-exceptions -fno-rtti

xlc -c -fno-exceptions -fno-rtti conftest.c

does succeed, but

xlc -fno-exceptions -fno-rtti conftest.c

fails.  I don't think -fno-rtti -fno-exceptions does what GCC expects.

Also, I noticed that although GCC is configured with
--enable-build-with-cxx , the configure tests use $CC, which might not
be accurate.

- David

Re: Switching to C++ by default in 4.8

[Gabriel Dos Reis]

On Thu, Apr 5, 2012 at 3:16 PM, David Edelsohn <dje.gcc@gmail.com> wrote:
> On Thu, Apr 5, 2012 at 10:36 AM, Diego Novillo <dnovillo@google.com> wrote:
>> On Thu, Apr 5, 2012 at 10:24, Richard Guenther
>> <richard.guenther@gmail.com> wrote:
>>
>>> Which means never, because I think it's a prerequesite for switching?
>>
>> No.  I was not clear.  By "done", I meant that GCC builds with C++ in
>> all the platforms we can test.
>>
>> I'm sending a testing plan later today with the list of targets I
>> think should be tested.  I am expecting to do some adjusting patches
>> to get all the targets working.
>
> I tried bootstrapping on AIX using C++.
>
> I am able to bootstrap using G++, but not with IBM xlC.  xlC is able
> to compile the GCC source code (with a lot of warning messages), but
> the build fails when the build passes GCC-specific no exception flags
> to xlC.
>
> NOEXCEPTION_FLAGS = -fno-exceptions -fno-rtti
>
> xlc -c -fno-exceptions -fno-rtti conftest.c
>
> does succeed, but
>
> xlc -fno-exceptions -fno-rtti conftest.c
>
> fails.  I don't think -fno-rtti -fno-exceptions does what GCC expects.

Thanks for these data.  I think -fno-rtti and -fno-exceptions don't make
much sense at the linker level so we should leave them out, and use
them only when "compiling", e.g. with "-c".

>
> Also, I noticed that although GCC is configured with
> --enable-build-with-cxx , the configure tests use $CC, which might not
> be accurate.

that is correct.  I suspect a patch for the switch will switch to $CXX.

-- Gaby

Re: Switching to C++ by default in 4.8

[David Edelsohn]

On Thu, Apr 5, 2012 at 4:35 PM, Gabriel Dos Reis
<gdr@integrable-solutions.net> wrote:

>> xlc -fno-exceptions -fno-rtti conftest.c
>>
>> fails.  I don't think -fno-rtti -fno-exceptions does what GCC expects.
>
> Thanks for these data.  I think -fno-rtti and -fno-exceptions don't make
> much sense at the linker level so we should leave them out, and use
> them only when "compiling", e.g. with "-c".

It is used when compiling, e.g. gcov.c, but when compiling and linking
directly from source without an intermediate object file.

- David

Re: Switching to C++ by default in 4.8

[Richard Guenther]

On Fri, Apr 6, 2012 at 2:11 AM, David Edelsohn <dje.gcc@gmail.com> wrote:
> On Thu, Apr 5, 2012 at 4:35 PM, Gabriel Dos Reis
> <gdr@integrable-solutions.net> wrote:
>
>>> xlc -fno-exceptions -fno-rtti conftest.c
>>>
>>> fails.  I don't think -fno-rtti -fno-exceptions does what GCC expects.
>>
>> Thanks for these data.  I think -fno-rtti and -fno-exceptions don't make
>> much sense at the linker level so we should leave them out, and use
>> them only when "compiling", e.g. with "-c".
>
> It is used when compiling, e.g. gcov.c, but when compiling and linking
> directly from source without an intermediate object file.

These flags should be only used for stage2+ or when compiling with GCC.
Did you try to bootstrap with xlc or did you use --disable-bootstrap?  gcov.c
is supposed to be compiled with the built GCC C++ compiler.

Richard.

> - David

Re: Switching to C++ by default in 4.8

[David Edelsohn]

On Mon, Apr 9, 2012 at 6:37 AM, Richard Guenther
<richard.guenther@gmail.com> wrote:

> These flags should be only used for stage2+ or when compiling with GCC.
> Did you try to bootstrap with xlc or did you use --disable-bootstrap?  gcov.c
> is supposed to be compiled with the built GCC C++ compiler.

I was attempting to bootstrap with xlc and xlC -- the IBM C and C++
native compilers.

- David

Re: Switching to C++ by default in 4.8

[Pedro Lamarão]

2012/4/5 Diego Novillo <dnovillo@google.com>

> I will be, after the switch to C++ is done.  Pedro, if you do have a
> copyright assignment, feel free to start working on this.  I suggest
> creating a branch for this (I can handle that today).  If you need
> forms for the copyright assignment, let me know and I'll forward them
> to you.

(Second attempt, to avoid text/html in Gmail.)

I think I have an appropriate copyright assignment for contributing to
GCC -- recently, an old patch of mine was reused an applied. Perhaps I
misunderstood some of the conditions and would have to submit more
documentation this time. I'm not sure.

I think I have a viable approach to refactor VEC into a template class
while keeping all files intact. The only implication is changing
CC_FOR_BUILD to use COMPILER etc. Perhaps someone wiser might want to
do something better to ensure genflags etc. compile with C++. Whenever
the branch is ready, or people want to review, or both, I can submit
patches.

--
Pedro Lamarão ∷ http://www.pedro.lamarao.nom.br/

"Sanity consists in the faculty of adjusting ideas in proper
proportion." - Aleister Crowley

Re: Switching to C++ by default in 4.8

[Diego Novillo]

On 4/10/12 6:04 PM, Pedro Lamarão wrote:
> 2012/4/5 Diego Novillo<dnovillo@google.com>
>
>> I will be, after the switch to C++ is done.  Pedro, if you do have a
>> copyright assignment, feel free to start working on this.  I suggest
>> creating a branch for this (I can handle that today).  If you need
>> forms for the copyright assignment, let me know and I'll forward them
>> to you.
>
> (Second attempt, to avoid text/html in Gmail.)
>
> I think I have an appropriate copyright assignment for contributing to
> GCC -- recently, an old patch of mine was reused an applied. Perhaps I
> misunderstood some of the conditions and would have to submit more
> documentation this time. I'm not sure.

Yes, if you've already signed paperwork for GCC, then we do not need 
anything else.

> I think I have a viable approach to refactor VEC into a template class
> while keeping all files intact. The only implication is changing
> CC_FOR_BUILD to use COMPILER etc. Perhaps someone wiser might want to
> do something better to ensure genflags etc. compile with C++. Whenever
> the branch is ready, or people want to review, or both, I can submit
> patches.

Great, thanks.  Let me setup a branch.  I'll contact you later with 
instructions.


Diego.

Re: Switching to C++ by default in 4.8

[Bernd Schmidt]

On 04/04/2012 11:06 AM, Richard Guenther wrote:
> So - I'll veto the switch unless I see 1) and 2).  1) and 2) can be combined
> by transitioning vec.h to a C++ template class, with proper GC support.
> (not sure that I can veto anything - heh)

I don't think I can veto anything, but I'll go on the record again
saying that I don't think this entire plan is a good idea. Write a new
project in C++? Absolutely. Convert a large existing one to a different
language? A huge waste of time that will distract us for years from
actual user-visible changes.

I also find debugging C++ in gdb somewhat more annoying than debugging
plain C, and at the moment I always go back to a stage1 compiler.


Bernd

Re: Switching to C++ by default in 4.8

[Richard Guenther]

On Wed, Apr 4, 2012 at 1:50 PM, Bernd Schmidt <bernds@codesourcery.com> wrote:
> On 04/04/2012 11:06 AM, Richard Guenther wrote:
>> So - I'll veto the switch unless I see 1) and 2).  1) and 2) can be combined
>> by transitioning vec.h to a C++ template class, with proper GC support.
>> (not sure that I can veto anything - heh)
>
> I don't think I can veto anything, but I'll go on the record again
> saying that I don't think this entire plan is a good idea. Write a new
> project in C++? Absolutely. Convert a large existing one to a different
> language? A huge waste of time that will distract us for years from
> actual user-visible changes.

I agree for the idea of converting all of GCC to C++ (whatever that means).
I disagree for the part making the internal infrastructure easier to use,
understand and maintain.  Which means targeting mostly isolated sub-systems,
like vec.h (and other various containers), double-int.[ch] (and other various
way of representing and working with constants).  Making tree or gimple a
C++ class with inheritance and whatever is indeed a huge waste of time
and existing developer ressources (that, if only because they have to adapt
and maintain two completely different code-bases over some time).

I expect the GCC core to maintain written in C, compiled by C++.

> I also find debugging C++ in gdb somewhat more annoying than debugging
> plain C, and at the moment I always go back to a stage1 compiler.

Indeed - I'd be worried if my debugging efficiency decreases by more than 5%.

Richard.

Re: Switching to C++ by default in 4.8

[Diego Novillo]

On 4/4/12 8:04 AM, Richard Guenther wrote:

> I agree for the idea of converting all of GCC to C++ (whatever that means).

Right.  The conversion that does happen, can be gradual.  One other big 
advantage I see in this effort, is the transition to commonly used 
programming idioms and patterns.  This will lower barriers of entry to 
new developers, which is crucial to the long term survival of the 
project.  I've heard many new developers (experienced compiler 
developers even) express frustration at the obtuse and obscure patterns 
they find in GCC.

> I disagree for the part making the internal infrastructure easier to use,
> understand and maintain.  Which means targeting mostly isolated sub-systems,
> like vec.h (and other various containers), double-int.[ch] (and other various
> way of representing and working with constants).  Making tree or gimple a
> C++ class with inheritance and whatever is indeed a huge waste of time
> and existing developer ressources (that, if only because they have to adapt
> and maintain two completely different code-bases over some time).
>
> I expect the GCC core to maintain written in C, compiled by C++.

I'm not sure about that long term, but I agree that this will likely be 
true for several releases.  We want to be careful, of course. 
Particularly with the core sub-systems.

>> I also find debugging C++ in gdb somewhat more annoying than debugging
>> plain C, and at the moment I always go back to a stage1 compiler.
>
> Indeed - I'd be worried if my debugging efficiency decreases by more than 5%.

We should take this opportunity to help improve gdb by filing bugs.


Diego.

Re: Switching to C++ by default in 4.8

[Lawrence Crowl]

On 4/4/12, Richard Guenther <richard.guenther@gmail.com> wrote:
> On Apr 4, 2012 Bernd Schmidt <bernds@codesourcery.com> wrote:
> > On 04/04/2012 11:06 AM, Richard Guenther wrote:
> > > So - I'll veto the switch unless I see 1) and 2).  1) and 2)
> > > can be combined by transitioning vec.h to a C++ template class,
> > > with proper GC support.  (not sure that I can veto anything
> > > - heh)
> >
> > I don't think I can veto anything, but I'll go on the record
> > again saying that I don't think this entire plan is a good
> > idea. Write a new project in C++? Absolutely. Convert a large
> > existing one to a different language? A huge waste of time that
> > will distract us for years from actual user-visible changes.
>
> I agree for the idea of converting all of GCC to C++ (whatever
> that means).  I disagree for the part making the internal
> infrastructure easier to use, understand and maintain.  Which
> means targeting mostly isolated sub-systems, like vec.h (and
> other various containers), double-int.[ch] (and other various
> way of representing and working with constants).  Making tree
> or gimple a C++ class with inheritance and whatever is indeed
> a huge waste of time and existing developer ressources (that,
> if only because they have to adapt and maintain two completely
> different code-bases over some time).

Trees are presently a significant problem in that many static errors
become dynamic errors, which entails more debugging.

> I expect the GCC core to maintain written in C, compiled by C++.

Converting VECs to C++ vectors vector would provide significant code
clarity benefits.  The files in which that is done would necessarily
be C++ only.

> > I also find debugging C++ in gdb somewhat more annoying than
> > debugging plain C, and at the moment I always go back to a
> > stage1 compiler.
>
> Indeed - I'd be worried if my debugging efficiency decreases by
> more than 5%.

If the number of debugging sessions was reduced by the same amount,
the result would be a net wash.

-- 
Lawrence Crowl

Re: Switching to C++ by default in 4.8

[Richard Guenther]

On Wed, Apr 4, 2012 at 7:53 PM, Lawrence Crowl <crowl@google.com> wrote:
> On 4/4/12, Richard Guenther <richard.guenther@gmail.com> wrote:
>> On Apr 4, 2012 Bernd Schmidt <bernds@codesourcery.com> wrote:
>> > On 04/04/2012 11:06 AM, Richard Guenther wrote:
>> > > So - I'll veto the switch unless I see 1) and 2).  1) and 2)
>> > > can be combined by transitioning vec.h to a C++ template class,
>> > > with proper GC support.  (not sure that I can veto anything
>> > > - heh)
>> >
>> > I don't think I can veto anything, but I'll go on the record
>> > again saying that I don't think this entire plan is a good
>> > idea. Write a new project in C++? Absolutely. Convert a large
>> > existing one to a different language? A huge waste of time that
>> > will distract us for years from actual user-visible changes.
>>
>> I agree for the idea of converting all of GCC to C++ (whatever
>> that means).  I disagree for the part making the internal
>> infrastructure easier to use, understand and maintain.  Which
>> means targeting mostly isolated sub-systems, like vec.h (and
>> other various containers), double-int.[ch] (and other various
>> way of representing and working with constants).  Making tree
>> or gimple a C++ class with inheritance and whatever is indeed
>> a huge waste of time and existing developer ressources (that,
>> if only because they have to adapt and maintain two completely
>> different code-bases over some time).
>
> Trees are presently a significant problem in that many static errors
> become dynamic errors, which entails more debugging.

How do you expect tree errors to become static?  By using derived
types everywhere?  Note that this would only be possible in a _very_
limited sub-set of places.

>> I expect the GCC core to maintain written in C, compiled by C++.
>
> Converting VECs to C++ vectors vector would provide significant code
> clarity benefits.  The files in which that is done would necessarily
> be C++ only.

I already had VECs as the very first and best example why C++ might
be good.

>> > I also find debugging C++ in gdb somewhat more annoying than
>> > debugging plain C, and at the moment I always go back to a
>> > stage1 compiler.
>>
>> Indeed - I'd be worried if my debugging efficiency decreases by
>> more than 5%.
>
> If the number of debugging sessions was reduced by the same amount,
> the result would be a net wash.

I have no expectation that the number of debug sessions will be reduced.

Richard.

> --
> Lawrence Crowl

Re: Switching to C++ by default in 4.8

[Lawrence Crowl]

On 4/5/12, Richard Guenther <richard.guenther@gmail.com> wrote:
> On Apr 4, 2012 Lawrence Crowl <crowl@google.com> wrote:
> > On 4/4/12, Richard Guenther <richard.guenther@gmail.com> wrote:
> > > Making tree or gimple a C++ class with inheritance and
> > > whatever is indeed a huge waste of time and existing developer
> > > ressources (that, if only because they have to adapt and
> > > maintain two completely different code-bases over some time).
> >
> > Trees are presently a significant problem in that many static
> > errors become dynamic errors, which entails more debugging.
>
> How do you expect tree errors to become static?  By using derived
> types everywhere?  Note that this would only be possible in a
> _very_ limited sub-set of places.

Yes, a class hierarchy that directly represents the type hierarchy
already implicit in trees.  With that structure in place, functions
that require a certain kind of tree as a parameter can say so
directly in the parameter list.  Functions that return a certain
kind of tree can say so in the return type.  Calling a function
that is inappropriate to the type will result in a static error.

Certainly there are cases where the type must be made more specific,
and getting the wrong type here would necessarily be a dynamic check.
However, the number of dynamic checks can be substantially reduced.
To provide a specific example, suppose I have a common_decl *p and
need to do extra work if it is a var_decl.

do_general_work (p);
if (var_decl *q = p->to_var ())
{
  do_var_work_1 (q);
  do_var_work_2 (q);
  do_var_work_3 (q);
  do_var_work_4 (q);
}

The only dynamic work is in the pointer conversion.  All other
function calls can be statically typed.

> > > I expect the GCC core to maintain written in C, compiled
> > > by C++.
> >
> > Converting VECs to C++ vectors vector would provide significant
> > code clarity benefits.  The files in which that is done would
> > necessarily be C++ only.
>
> I already had VECs as the very first and best example why C++
> might be good.

But my point was that if we're using a C++ vector, the files are
not written in C any more.

> > > > I also find debugging C++ in gdb somewhat more annoying
> > > > than debugging plain C, and at the moment I always go back
> > > > to a stage1 compiler.
> > >
> > > Indeed - I'd be worried if my debugging efficiency decreases
> > > by more than 5%.
> >
> > If the number of debugging sessions was reduced by the same
> > amount, the result would be a net wash.
>
> I have no expectation that the number of debug sessions will
> be reduced.

On the other hand, I do.  There are many instances were I've debugged
a problem to realize that it could have been a static type error.

-- 
Lawrence Crowl

Re: Switching to C++ by default in 4.8

[Richard Guenther]

On Thu, Apr 5, 2012 at 10:06 PM, Lawrence Crowl <crowl@google.com> wrote:
> On 4/5/12, Richard Guenther <richard.guenther@gmail.com> wrote:
>> On Apr 4, 2012 Lawrence Crowl <crowl@google.com> wrote:
>> > On 4/4/12, Richard Guenther <richard.guenther@gmail.com> wrote:
>> > > Making tree or gimple a C++ class with inheritance and
>> > > whatever is indeed a huge waste of time and existing developer
>> > > ressources (that, if only because they have to adapt and
>> > > maintain two completely different code-bases over some time).
>> >
>> > Trees are presently a significant problem in that many static
>> > errors become dynamic errors, which entails more debugging.
>>
>> How do you expect tree errors to become static?  By using derived
>> types everywhere?  Note that this would only be possible in a
>> _very_ limited sub-set of places.
>
> Yes, a class hierarchy that directly represents the type hierarchy
> already implicit in trees.  With that structure in place, functions
> that require a certain kind of tree as a parameter can say so
> directly in the parameter list.  Functions that return a certain
> kind of tree can say so in the return type.  Calling a function
> that is inappropriate to the type will result in a static error.
>
> Certainly there are cases where the type must be made more specific,
> and getting the wrong type here would necessarily be a dynamic check.
> However, the number of dynamic checks can be substantially reduced.
> To provide a specific example, suppose I have a common_decl *p and
> need to do extra work if it is a var_decl.
>
> do_general_work (p);
> if (var_decl *q = p->to_var ())
> {
>  do_var_work_1 (q);
>  do_var_work_2 (q);
>  do_var_work_3 (q);
>  do_var_work_4 (q);
> }
>
> The only dynamic work is in the pointer conversion.  All other
> function calls can be statically typed.

Ok.  But the above represents a completely different programming
style than what we use currently.  We do

  if (is_var_decl (p))
    {
       do_var_work_1 (p);
...
    }

so what I was refering to was static errors we get when we are
able to promote function argument / return types to more specific
sub-classes.

>> > > I expect the GCC core to maintain written in C, compiled
>> > > by C++.
>> >
>> > Converting VECs to C++ vectors vector would provide significant
>> > code clarity benefits.  The files in which that is done would
>> > necessarily be C++ only.
>>
>> I already had VECs as the very first and best example why C++
>> might be good.
>
> But my point was that if we're using a C++ vector, the files are
> not written in C any more.

Of course - the whole point was to switch to C++ and start using C++
features.  The point I wanted to raise is that the switch to C++ should
happen with a change that is useful and that includes getting GC "right".
Converting vec.h is such a change.

Richard.

>> > > > I also find debugging C++ in gdb somewhat more annoying
>> > > > than debugging plain C, and at the moment I always go back
>> > > > to a stage1 compiler.
>> > >
>> > > Indeed - I'd be worried if my debugging efficiency decreases
>> > > by more than 5%.
>> >
>> > If the number of debugging sessions was reduced by the same
>> > amount, the result would be a net wash.
>>
>> I have no expectation that the number of debug sessions will
>> be reduced.
>
> On the other hand, I do.  There are many instances were I've debugged
> a problem to realize that it could have been a static type error.
>
> --
> Lawrence Crowl

Re: Switching to C++ by default in 4.8

[Lawrence Crowl]

On 4/9/12, Richard Guenther <richard.guenther@gmail.com> wrote:
> On Thu, Apr 5, 2012 at 10:06 PM, Lawrence Crowl <crowl@google.com> wrote:
>> On 4/5/12, Richard Guenther <richard.guenther@gmail.com> wrote:
>>> How do you expect tree errors to become static?  By using derived
>>> types everywhere?  Note that this would only be possible in a
>>> _very_ limited sub-set of places.
>>
>> Yes, a class hierarchy that directly represents the type hierarchy
>> already implicit in trees.  With that structure in place, functions
>> that require a certain kind of tree as a parameter can say so
>> directly in the parameter list.  Functions that return a certain
>> kind of tree can say so in the return type.  Calling a function
>> that is inappropriate to the type will result in a static error.
>>
>> Certainly there are cases where the type must be made more specific,
>> and getting the wrong type here would necessarily be a dynamic check.
>> However, the number of dynamic checks can be substantially reduced.
>> To provide a specific example, suppose I have a common_decl *p and
>> need to do extra work if it is a var_decl.
>>
>> do_general_work (p);
>> if (var_decl *q = p->to_var ())
>> {
>>  do_var_work_1 (q);
>>  do_var_work_2 (q);
>>  do_var_work_3 (q);
>>  do_var_work_4 (q);
>> }
>>
>> The only dynamic work is in the pointer conversion.  All other
>> function calls can be statically typed.
>
> Ok.  But the above represents a completely different programming
> style than what we use currently.  We do
>
>   if (is_var_decl (p))
>     {
>        do_var_work_1 (p);
> ...
>     }
>
> so what I was refering to was static errors we get when we are
> able to promote function argument / return types to more specific
> sub-classes.

Certainly fully exploiting a class hierarchy will require a
migration of the source base.  That can happen incrementally over
time.  In the meantime, there are other tasks that will show more
immediate progress.

>>> > > I expect the GCC core to maintain written in C, compiled
>>> > > by C++.
>>> >
>>> > Converting VECs to C++ vectors vector would provide significant
>>> > code clarity benefits.  The files in which that is done would
>>> > necessarily be C++ only.
>>>
>>> I already had VECs as the very first and best example why C++
>>> might be good.
>>
>> But my point was that if we're using a C++ vector, the files are
>> not written in C any more.
>
> Of course - the whole point was to switch to C++ and start using
> C++ features.  The point I wanted to raise is that the switch to
> C++ should happen with a change that is useful and that includes
> getting GC "right".  Converting vec.h is such a change.

A build conversion to C++ is a precondition to any source change
using C++, though the two could be bundled into one patch.  In any
event, I agree that the conversion needs to provide value. Vectors
and hash tables are a good early target.

-- 
Lawrence Crowl

Re: Switching to C++ by default in 4.8

[Jakub Jelinek]

On Mon, Apr 09, 2012 at 10:55:46AM -0700, Lawrence Crowl wrote:
> A build conversion to C++ is a precondition to any source change
> using C++, though the two could be bundled into one patch.  In any
> event, I agree that the conversion needs to provide value. Vectors
> and hash tables are a good early target.

Hash tables?  Ugh, what is wrong with the hash tables we have right now in
GCC?

	Jakub

Re: Switching to C++ by default in 4.8

[Lawrence Crowl]

On 4/9/12, Jakub Jelinek <jakub@redhat.com> wrote:
> On Mon, Apr 09, 2012 at 10:55:46AM -0700, Lawrence Crowl wrote:
> > A build conversion to C++ is a precondition to any source change
> > using C++, though the two could be bundled into one patch.  In any
> > event, I agree that the conversion needs to provide value. Vectors
> > and hash tables are a good early target.
>
> Hash tables?  Ugh, what is wrong with the hash tables we have
> right now in GCC?

Lots of boiler plate involving casting to void*.  Some of that
boiler plate makes the optimizer less effective.

-- 
Lawrence Crowl

Re: Switching to C++ by default in 4.8

[Jakub Jelinek]

On Mon, Apr 09, 2012 at 11:51:56AM -0700, Lawrence Crowl wrote:
> On 4/9/12, Jakub Jelinek <jakub@redhat.com> wrote:
> > On Mon, Apr 09, 2012 at 10:55:46AM -0700, Lawrence Crowl wrote:
> > > A build conversion to C++ is a precondition to any source change
> > > using C++, though the two could be bundled into one patch.  In any
> > > event, I agree that the conversion needs to provide value. Vectors
> > > and hash tables are a good early target.
> >
> > Hash tables?  Ugh, what is wrong with the hash tables we have
> > right now in GCC?
> 
> Lots of boiler plate involving casting to void*.  Some of that
> boiler plate makes the optimizer less effective.

Have you any numbers that back that up?

	Jakub

Re: Switching to C++ by default in 4.8

[Lawrence Crowl]

On 4/9/12, Jakub Jelinek <jakub@redhat.com> wrote:
> On Mon, Apr 09, 2012 at 11:51:56AM -0700, Lawrence Crowl wrote:
>> On 4/9/12, Jakub Jelinek <jakub@redhat.com> wrote:
>> > On Mon, Apr 09, 2012 at 10:55:46AM -0700, Lawrence Crowl wrote:
>> > > A build conversion to C++ is a precondition to any source change
>> > > using C++, though the two could be bundled into one patch.  In any
>> > > event, I agree that the conversion needs to provide value. Vectors
>> > > and hash tables are a good early target.
>> >
>> > Hash tables?  Ugh, what is wrong with the hash tables we have
>> > right now in GCC?
>>
>> Lots of boiler plate involving casting to void*.  Some of that
>> boiler plate makes the optimizer less effective.
>
> Have you any numbers that back that up?

Not for the optimizer claim, as the conversion hasn't been done yet.

-- 
Lawrence Crowl

Re: Switching to C++ by default in 4.8

[Richard Guenther]

On Mon, Apr 9, 2012 at 8:51 PM, Lawrence Crowl <crowl@google.com> wrote:
> On 4/9/12, Jakub Jelinek <jakub@redhat.com> wrote:
>> On Mon, Apr 09, 2012 at 10:55:46AM -0700, Lawrence Crowl wrote:
>> > A build conversion to C++ is a precondition to any source change
>> > using C++, though the two could be bundled into one patch.  In any
>> > event, I agree that the conversion needs to provide value. Vectors
>> > and hash tables are a good early target.
>>
>> Hash tables?  Ugh, what is wrong with the hash tables we have
>> right now in GCC?
>
> Lots of boiler plate involving casting to void*.  Some of that
> boiler plate makes the optimizer less effective.

Optimizers ignore pointer types, so that assertion cannot be true.

Richard.

> --
> Lawrence Crowl

Re: Switching to C++ by default in 4.8

[Lawrence Crowl]

On 4/10/12, Richard Guenther <richard.guenther@gmail.com> wrote:
> On Apr 9, 2012 Lawrence Crowl <crowl@google.com> wrote:
> > On 4/9/12, Jakub Jelinek <jakub@redhat.com> wrote:
> > > On Mon, Apr 09, 2012 at 10:55:46AM -0700, Lawrence Crowl wrote:
> > > > A build conversion to C++ is a precondition to any source
> > > > change using C++, though the two could be bundled into
> > > > one patch.  In any event, I agree that the conversion
> > > > needs to provide value. Vectors and hash tables are a good
> > > > early target.
> > >
> > > Hash tables?  Ugh, what is wrong with the hash tables we have
> > > right now in GCC?
> >
> > Lots of boiler plate involving casting to void*.  Some of that
> > boiler plate makes the optimizer less effective.
>
> Optimizers ignore pointer types, so that assertion cannot be true.

The standard says they need not ignore them.

I was thinking more about iterating over the contents.  What in the
current code is an indirect function call inside of a loop becomes
mostly be inline functions in a C++ iterator style.  The loop is now
fully graspable by the optimizer.

-- 
Lawrence Crowl

Re: Switching to C++ by default in 4.8

[Jakub Jelinek]

On Tue, Apr 10, 2012 at 06:35:58PM -0700, Lawrence Crowl wrote:
> The standard says they need not ignore them.
> 
> I was thinking more about iterating over the contents.  What in the
> current code is an indirect function call inside of a loop becomes
> mostly be inline functions in a C++ iterator style.  The loop is now
> fully graspable by the optimizer.

That comes with its cost though, as we have hundreds of hashtables for
various kinds of types, you'd get hundreds of different instantiations of
the hash table code.  hashtab.c is significantly more I-cache friendly
than that.  If a hash table doesn't need to be rehashed and the *with_hash
routines are used, only the eq_f callback is called a few times (on each
collision).

	Jakub

Re: Switching to C++ by default in 4.8

[Dave Korn]

On 11/04/2012 07:55, Jakub Jelinek wrote:
> On Tue, Apr 10, 2012 at 06:35:58PM -0700, Lawrence Crowl wrote:
>> The standard says they need not ignore them.
>>
>> I was thinking more about iterating over the contents.  What in the
>> current code is an indirect function call inside of a loop becomes
>> mostly be inline functions in a C++ iterator style.  The loop is now
>> fully graspable by the optimizer.
> 
> That comes with its cost though, as we have hundreds of hashtables for
> various kinds of types, you'd get hundreds of different instantiations of
> the hash table code.  hashtab.c is significantly more I-cache friendly
> than that.  

  Hmm, is that necessarily the case?  GCC is big and I-caches are small; it
could well be the case that hashtab.c gets evicted very regularly from the
cache, and is only usually constant in it during the course of one individual
loop.  It wouldn't be any more expensive to map in any one hashtab C++
specialisation vs. another, and they'd all individually be of the same scale
as the C hashtab.o code, so unless we have many nested loops that use one kind
of hashtab in the outer loop and a different one in the inner loop, we could
still end up pretty much where we started from in terms of I-cache usage.

  I expect profiling would immediately show up whether the two approaches made
any significant difference or not, probably very visibly, but I wouldn't
dismiss doing the experiment out-of-hand.  If the inlining improvements exceed
the extra cost of paging, switching to C++ would be justified.

    cheers,
      DaveK

Re: Switching to C++ by default in 4.8

[Richard Guenther]

On Wed, Apr 11, 2012 at 3:35 AM, Lawrence Crowl <crowl@google.com> wrote:
> On 4/10/12, Richard Guenther <richard.guenther@gmail.com> wrote:
>> On Apr 9, 2012 Lawrence Crowl <crowl@google.com> wrote:
>> > On 4/9/12, Jakub Jelinek <jakub@redhat.com> wrote:
>> > > On Mon, Apr 09, 2012 at 10:55:46AM -0700, Lawrence Crowl wrote:
>> > > > A build conversion to C++ is a precondition to any source
>> > > > change using C++, though the two could be bundled into
>> > > > one patch.  In any event, I agree that the conversion
>> > > > needs to provide value. Vectors and hash tables are a good
>> > > > early target.
>> > >
>> > > Hash tables?  Ugh, what is wrong with the hash tables we have
>> > > right now in GCC?
>> >
>> > Lots of boiler plate involving casting to void*.  Some of that
>> > boiler plate makes the optimizer less effective.
>>
>> Optimizers ignore pointer types, so that assertion cannot be true.
>
> The standard says they need not ignore them.
>
> I was thinking more about iterating over the contents.  What in the
> current code is an indirect function call inside of a loop becomes
> mostly be inline functions in a C++ iterator style.  The loop is now
> fully graspable by the optimizer.

We already use C++ iterator "style" and there are nearly no indirect
function calls involved (unless you use the walk_*_with_* routines,
which I detest, and you get the same when you use C++ foreach ()
style).

Richard.

>
> --
> Lawrence Crowl

Re: Switching to C++ by default in 4.8

[Chiheng Xu]

On Tue, Apr 10, 2012 at 2:22 AM, Jakub Jelinek <jakub@redhat.com> wrote:
> On Mon, Apr 09, 2012 at 10:55:46AM -0700, Lawrence Crowl wrote:
>> A build conversion to C++ is a precondition to any source change
>> using C++, though the two could be bundled into one patch.  In any
>> event, I agree that the conversion needs to provide value. Vectors
>> and hash tables are a good early target.
>
> Hash tables?  Ugh, what is wrong with the hash tables we have right now in
> GCC?
>

He probably mean to wrap hash table in C++ class.


-- 
Chiheng Xu

Re: Switching to C++ by default in 4.8

[Chiheng Xu]

On Mon, Apr 9, 2012 at 6:40 PM, Richard Guenther
<richard.guenther@gmail.com> wrote:
>>
>> Certainly there are cases where the type must be made more specific,
>> and getting the wrong type here would necessarily be a dynamic check.
>> However, the number of dynamic checks can be substantially reduced.
>> To provide a specific example, suppose I have a common_decl *p and
>> need to do extra work if it is a var_decl.
>>
>> do_general_work (p);
>> if (var_decl *q = p->to_var ())
>> {
>>  do_var_work_1 (q);
>>  do_var_work_2 (q);
>>  do_var_work_3 (q);
>>  do_var_work_4 (q);
>> }
>>
>> The only dynamic work is in the pointer conversion.  All other
>> function calls can be statically typed.
>
> Ok.  But the above represents a completely different programming
> style than what we use currently.  We do
>
>  if (is_var_decl (p))
>    {
>       do_var_work_1 (p);
> ...
>    }
>
> so what I was refering to was static errors we get when we are
> able to promote function argument / return types to more specific
> sub-classes.
>

What about this:
if(is_var_decl(p)) {
     var_decl * p_var_decl = (var_decl *) p;
     do_var_work_1 (p_var_decl);
}else if(is_type_decl(p)){
     type_decl * p_type_decl = (type_decl *) p;
     do_type_work_2 (p_type_decl);
}else if(is_field_decl(p)){
     field_decl * p_field_decl = (field_decl *) p;
     do_field_work_3 (p_field_decl);
}


-- 
Chiheng Xu

Re: Switching to C++ by default in 4.8

[Lawrence Crowl]

On 4/13/12, Chiheng Xu <chiheng.xu@gmail.com> wrote:
> On Apr 9, 2012, Richard Guenther <richard.guenther@gmail.com> wrote:
>>> Certainly there are cases where the type must be made more specific,
>>> and getting the wrong type here would necessarily be a dynamic check.
>>> However, the number of dynamic checks can be substantially reduced.
>>> To provide a specific example, suppose I have a common_decl *p and
>>> need to do extra work if it is a var_decl.
>>>
>>> do_general_work (p);
>>> if (var_decl *q = p->to_var ())
>>> {
>>>  do_var_work_1 (q);
>>>  do_var_work_2 (q);
>>>  do_var_work_3 (q);
>>>  do_var_work_4 (q);
>>> }
>>>
>>> The only dynamic work is in the pointer conversion.  All other
>>> function calls can be statically typed.
>>
>> Ok.  But the above represents a completely different programming
>> style than what we use currently.  We do
>>
>>  if (is_var_decl (p))
>>    {
>>       do_var_work_1 (p);
>> ...
>>    }
>>
>> so what I was refering to was static errors we get when we are
>> able to promote function argument / return types to more specific
>> sub-classes.
>
> What about this:
> if(is_var_decl(p)) {
>      var_decl * p_var_decl = (var_decl *) p;
>      do_var_work_1 (p_var_decl);
> }else if(is_type_decl(p)){
>      type_decl * p_type_decl = (type_decl *) p;
>      do_type_work_2 (p_type_decl);
> }else if(is_field_decl(p)){
>      field_decl * p_field_decl = (field_decl *) p;
>      do_field_work_3 (p_field_decl);
> }

That approach will certainly work, but makes the correctness of
the assignment contingent on the condition being right.  If the
condition changes in appropriately, you can get a bug.  Even so,
I think what you suggest is a good intermediate step.

-- 
Lawrence Crowl

Re: Switching to C++ by default in 4.8

[Xinliang David Li]

On Wed, Apr 4, 2012 at 5:04 AM, Richard Guenther
<richard.guenther@gmail.com> wrote:
> On Wed, Apr 4, 2012 at 1:50 PM, Bernd Schmidt <bernds@codesourcery.com> wrote:
>> On 04/04/2012 11:06 AM, Richard Guenther wrote:
>>> So - I'll veto the switch unless I see 1) and 2).  1) and 2) can be combined
>>> by transitioning vec.h to a C++ template class, with proper GC support.
>>> (not sure that I can veto anything - heh)
>>
>> I don't think I can veto anything, but I'll go on the record again
>> saying that I don't think this entire plan is a good idea. Write a new
>> project in C++? Absolutely. Convert a large existing one to a different
>> language? A huge waste of time that will distract us for years from
>> actual user-visible changes.
>
> I agree for the idea of converting all of GCC to C++ (whatever that means).
> I disagree for the part making the internal infrastructure easier to use,
> understand and maintain.  Which means targeting mostly isolated sub-systems,
> like vec.h (and other various containers), double-int.[ch] (and other various
> way of representing and working with constants).  Making tree or gimple a
> C++ class with inheritance and whatever is indeed a huge waste of time
> and existing developer ressources (that, if only because they have to adapt
> and maintain two completely different code-bases over some time).
>
> I expect the GCC core to maintain written in C, compiled by C++.


GCC's current C programming APIs (both browsing APIs and
creator/factory APIs) are somewhat primitive and too low level. I
expect switching to C++ can significantly make GCC more modern
looking. It can greatly improve readability and productivity (for
simplifying transformation and instrumentation development). C++
features should not be be abused (e.g., MI, VI etc), but we should not
miss on basic C++ features.

Class hierarchy is one such feature that is useful. Assuming we have
two hierarchies for gcc: one for values rooted at ValExp, and one for
gimple stmts rooted at GimpInst.

1) For IR browsing,
   *) all the macro accessors can be eliminated -- a big plus for debugging;
   *) gcc implementation has lots of hard coded TREE_OPERAND (exp, nn)

     e.g.
            exp->as_component_ref().get_field() ..
            exp->as_mem_access().get_base() ...
            exp->as_mem_acesss().get_address() --> produces the
address expression for memory access
            exp->as_mem_access().get_alias_handle ()

            gimple_inst->serialize (&fixup_list) --> a virtual
function overriden by actual instruction types that knows its byte
code format.

For experienced GCC developers, current APIs won't a problem at all --
but it does become a big minus for newbies and in the long run will
hurt gcc community.

2) IR manipulation APIs -- the problem seems more serious. It seems
GCC prefers low level APIs so that incremental update of derived data
(control flow, SSA) can be easier -- but that does not have to be the
case -- high level APIs can hide most of the update from the
programmer.

 Example:   Create a a simple assignment instruction from a load (this
example comes from Asan implementation in gcc by Kostya)

 t = build1 (INDIRECT_REF, some_type,
              build1 (VIEW_CONVERT_EXPR, some_type, addr));
  t = force_gimple_operand (t, &stmts, false, NULL_TREE);
  gimple_seq_add_seq (&seq, stmts);
  the_value = make_rename_temp (shadow_type, "__var_name");
  g = gimple_build_assign (the_value, t);
  nm = make_ssa_name (the_value, g);
  gimple_assign_set_lhs (g, nm);


This can be as simple as (by hiding the gimplification, ssa name creation etc)

   new_assign_insn = gimple::new_load_insn (INDIRECT_REF, some_type, addr_exp);
   new_assign_insn->get_lhs()->as_ssa_name()->get_val_decl()->setname("...");

The creator interface can also take a form that accepts the addr_insn
that produces the address.

Another example:

Instrument a BB1 so that it is guarded:

if (counts > sampling_rate) // BB0
  {
      counts = 0;
      ORIGINAL BB1 code
  } // BB2


It can be as simple as the following:

basic_block bb0, bb1;

gimple_br_inst = gimple::new_cond_br (value:new_cmp_exp (....),
                                                                  bb1,
/* taken branch* /

&bb2, /* fall through */

&bb2, /* merge point */

&bb0 /* New predecessor */);
reset_count = gimple:new_store_insn (..., bb1, insert_before);


If the current APIs are used to do the coding, it will take how X
times more API calls which is non-readable for human beings.


thanks,

David

>
>> I also find debugging C++ in gdb somewhat more annoying than debugging
>> plain C, and at the moment I always go back to a stage1 compiler.
>
> Indeed - I'd be worried if my debugging efficiency decreases by more than 5%.
>
> Richard.

Re: Switching to C++ by default in 4.8

[Jakub Jelinek]

On Mon, Apr 09, 2012 at 04:34:32PM -0700, Xinliang David Li wrote:
> Class hierarchy is one such feature that is useful. Assuming we have
> two hierarchies for gcc: one for values rooted at ValExp, and one for
> gimple stmts rooted at GimpInst.
> 
> 1) For IR browsing,
>    *) all the macro accessors can be eliminated -- a big plus for debugging;

Not that clear, if all the macros are replaced by tons of inline functions,
the debugging experience can be actually significantly worse.  Already some the
inline functions used like tree_operand_length used by TREE_OPERAND_LENGTH
macro are extremely annoying from debugging POV.

>    *) gcc implementation has lots of hard coded TREE_OPERAND (exp, nn)
> 
>      e.g.
>             exp->as_component_ref().get_field() ..
>             exp->as_mem_access().get_base() ...
>             exp->as_mem_acesss().get_address() --> produces the
> address expression for memory access
>             exp->as_mem_access().get_alias_handle ()
> 
>             gimple_inst->serialize (&fixup_list) --> a virtual
> function overriden by actual instruction types that knows its byte
> code format.

That silently assumes we want to change basic GIMPLE/tree data structures
to virtual classes, which is a significant change that has a significant
cost as well.  E.g. all such changed data structures grow by a virtual
pointer field.  Those data structures are heavily optimized for memory
footprint.
Not to mention it is very questionable if the above stuff is more readable
than what we currently have.

	Jakub

Re: Switching to C++ by default in 4.8

[Michael Matz]

Hi,

On Tue, 10 Apr 2012, Jakub Jelinek wrote:

> >    *) gcc implementation has lots of hard coded TREE_OPERAND (exp, nn)
> > 
> >      e.g.
> >             exp->as_component_ref().get_field() ..
> >             exp->as_mem_access().get_base() ...
> >             exp->as_mem_acesss().get_address() --> produces the
> > address expression for memory access
> >             exp->as_mem_access().get_alias_handle ()
> > 
> >             gimple_inst->serialize (&fixup_list) --> a virtual
> > function overriden by actual instruction types that knows its byte
> > code format.
> 
> That silently assumes we want to change basic GIMPLE/tree data structures
> to virtual classes, which is a significant change that has a significant
> cost as well.  E.g. all such changed data structures grow by a virtual
> pointer field.  Those data structures are heavily optimized for memory
> footprint.
> Not to mention it is very questionable if the above stuff is more readable
> than what we currently have.

Actually it's not questionable.  The above stuff is _horrible_.


Ciao,
Michael.

Re: Switching to C++ by default in 4.8

[David Edelsohn]

On Tue, Apr 10, 2012 at 8:26 AM, Michael Matz <matz@suse.de> wrote:
> Hi,
>
> On Tue, 10 Apr 2012, Jakub Jelinek wrote:
>
>> >    *) gcc implementation has lots of hard coded TREE_OPERAND (exp, nn)
>> >
>> >      e.g.
>> >             exp->as_component_ref().get_field() ..
>> >             exp->as_mem_access().get_base() ...
>> >             exp->as_mem_acesss().get_address() --> produces the
>> > address expression for memory access
>> >             exp->as_mem_access().get_alias_handle ()
>> >
>> >             gimple_inst->serialize (&fixup_list) --> a virtual
>> > function overriden by actual instruction types that knows its byte
>> > code format.
>>
>> That silently assumes we want to change basic GIMPLE/tree data structures
>> to virtual classes, which is a significant change that has a significant
>> cost as well.  E.g. all such changed data structures grow by a virtual
>> pointer field.  Those data structures are heavily optimized for memory
>> footprint.
>> Not to mention it is very questionable if the above stuff is more readable
>> than what we currently have.
>
> Actually it's not questionable.  The above stuff is _horrible_.

There seem to be at least four parts to this discussion about benefits of C++:

1) Object-oriented and class-based design
2) Optimization benefit or challenge
3) Debugging
4) C++ syntax

Hopefully all will benefit and they all support one another, but they
are not inherently linked and dependent upon each other.

Developers who are used to C++ will be comfortable with / familiar
with the syntax above and developers who are used to GCC's current
syntax will not like the change.  The real challenge is that there are
many more developers familiar with C++ syntax than with GCC internals
syntax.  If we could allow each group their own view, life would be
much better.

Also, it will be more convenient to make this change incrementally,
but the GCC community probably will not see much benefit until the
transition is complete.  That also means developers asserting benefits
need to be realistic and separate their end vision from what actually
can be achieved in the short and medium term.

- David

Re: Switching to C++ by default in 4.8

[Gabriel Dos Reis]

On Tue, Apr 10, 2012 at 10:50 AM, David Edelsohn <dje.gcc@gmail.com> wrote:

> Also, it will be more convenient to make this change incrementally,
> but the GCC community probably will not see much benefit until the
> transition is complete.  That also means developers asserting benefits
> need to be realistic and separate their end vision from what actually
> can be achieved in the short and medium term.

Fully agreed.

-- Gaby

Re: Switching to C++ by default in 4.8

[Diego Novillo]

On 4/10/12 12:05 PM, Gabriel Dos Reis wrote:
> On Tue, Apr 10, 2012 at 10:50 AM, David Edelsohn<dje.gcc@gmail.com>  wrote:
>
>> Also, it will be more convenient to make this change incrementally,
>> but the GCC community probably will not see much benefit until the
>> transition is complete.  That also means developers asserting benefits
>> need to be realistic and separate their end vision from what actually
>> can be achieved in the short and medium term.
>
> Fully agreed.

Indeed.  My personal take on this is that it is going to be a gradual 
(for some glacially slow) change.  I think that debating these points in 
the abstract gains us very little.

Instead, each patch and/or API re-design should be discussed 
individually.  Patches will have specific metrics that can be collected. 
  API changes will be more of a bike shed, but it will at least lead to 
more concrete discussions.

The end goal for me is simple: modernize the code base to make it more 
attractive to future developers.  There is some balancing act to be 
done, in that we should cater to the existing developers as well.  But 
it is easier for us, we already know the code and can influence the 
transition.


Diego.

Re: Switching to C++ by default in 4.8

[Richard Guenther]

On Tue, Apr 10, 2012 at 6:13 PM, Diego Novillo <dnovillo@google.com> wrote:
> On 4/10/12 12:05 PM, Gabriel Dos Reis wrote:
>>
>> On Tue, Apr 10, 2012 at 10:50 AM, David Edelsohn<dje.gcc@gmail.com>
>>  wrote:
>>
>>> Also, it will be more convenient to make this change incrementally,
>>> but the GCC community probably will not see much benefit until the
>>> transition is complete.  That also means developers asserting benefits
>>> need to be realistic and separate their end vision from what actually
>>> can be achieved in the short and medium term.
>>
>>
>> Fully agreed.
>
>
> Indeed.  My personal take on this is that it is going to be a gradual (for
> some glacially slow) change.  I think that debating these points in the
> abstract gains us very little.
>
> Instead, each patch and/or API re-design should be discussed individually.
>  Patches will have specific metrics that can be collected.  API changes will
> be more of a bike shed, but it will at least lead to more concrete
> discussions.
>
> The end goal for me is simple: modernize the code base to make it more
> attractive to future developers.  There is some balancing act to be done, in
> that we should cater to the existing developers as well.  But it is easier
> for us, we already know the code and can influence the transition.

I think it's important to let the C folks slowly accomodate with C++, thus
do not jump-start with even possibly questionable API changes.  There
are a _lot_ of "obvious" candidates that are even well contained (thus no
fear of a can of partial-C++ transitions) like the various containers we use
and APIs which are not in wide-spread use, like the cgraph API (which Honza
is about to turn upside down).

I also agree that

  exp->as_component_ref().get_field()

is exceptionally bad.  Both for the compile-time of the above expressions
(three function calls that all are need to be inlined?!) and readability.
And I've spent quite some time with various C++ codebases.  None was
as ugly as the above (and yes, I consider the LLVM C++ style exceptionally
ugly as well).

So, please no, do not even try to start the flamewar on C++-ifying trees
or gimple.  Not in the next three years at least.

Propose a nice and usable C++ _plugin_ API that encapsulates trees and
GIMPLE.  _Then_ we can talk.

Thanks,
Richard.

>
> Diego.

Re: Switching to C++ by default in 4.8

[Xinliang David Li]

On Wed, Apr 11, 2012 at 2:16 AM, Richard Guenther
<richard.guenther@gmail.com> wrote:
> On Tue, Apr 10, 2012 at 6:13 PM, Diego Novillo <dnovillo@google.com> wrote:
>> On 4/10/12 12:05 PM, Gabriel Dos Reis wrote:
>>>
>>> On Tue, Apr 10, 2012 at 10:50 AM, David Edelsohn<dje.gcc@gmail.com>
>>>  wrote:
>>>
>>>> Also, it will be more convenient to make this change incrementally,
>>>> but the GCC community probably will not see much benefit until the
>>>> transition is complete.  That also means developers asserting benefits
>>>> need to be realistic and separate their end vision from what actually
>>>> can be achieved in the short and medium term.
>>>
>>>
>>> Fully agreed.
>>
>>
>> Indeed.  My personal take on this is that it is going to be a gradual (for
>> some glacially slow) change.  I think that debating these points in the
>> abstract gains us very little.
>>
>> Instead, each patch and/or API re-design should be discussed individually.
>>  Patches will have specific metrics that can be collected.  API changes will
>> be more of a bike shed, but it will at least lead to more concrete
>> discussions.
>>
>> The end goal for me is simple: modernize the code base to make it more
>> attractive to future developers.  There is some balancing act to be done, in
>> that we should cater to the existing developers as well.  But it is easier
>> for us, we already know the code and can influence the transition.
>
> I think it's important to let the C folks slowly accomodate with C++, thus
> do not jump-start with even possibly questionable API changes.  There
> are a _lot_ of "obvious" candidates that are even well contained (thus no
> fear of a can of partial-C++ transitions) like the various containers we use
> and APIs which are not in wide-spread use, like the cgraph API (which Honza
> is about to turn upside down).

I think this is a good plan to move forward -- I also agree cgraph is
a good candidate. Other candidates include optimization driver/pass
manager, IR text dumper, persistent IR dumper/reader etc.


>
> I also agree that
>
>  exp->as_component_ref().get_field()
>
> is exceptionally bad.  Both for the compile-time of the above expressions
> (three function calls that all are need to be inlined?!)

I find this less convincing -- the compile time cost should be very
small -- and it may also allow more compile time saving:

X* derived = p->asX();  // runtime assertion done once.
derived->do_x_1 ();
derived->do_x_2 ();
....

As compared with a fat interface case:

G* generic = p;
DO_X_1 (generic);   // runtime assertion needed
DO_X_2 (generic);   // runtime assertion needed
...

> and readability.

This is again very subjective -- and the style can be hidden under a
macro. The benefit of using C++ API is not for the style change, but
for proper interface partition.

> And I've spent quite some time with various C++ codebases.  None was
> as ugly as the above (and yes, I consider the LLVM C++ style exceptionally
> ugly as well).


well, many people will probably disagree here.

>
> So, please no, do not even try to start the flamewar on C++-ifying trees
> or gimple.  Not in the next three years at least.
>
> Propose a nice and usable C++ _plugin_ API that encapsulates trees and
> GIMPLE.  _Then_ we can talk.


I think keeping the core APIs in C is fine even though there are more
work to make the current C APIs more user friendly. It might be a good
idea to move the core APIs into a separate directory.


thanks,

David

>
> Thanks,
> Richard.
>
>>
>> Diego.

Re: Switching to C++ by default in 4.8

[Xinliang David Li]

On Tue, Apr 10, 2012 at 5:26 AM, Michael Matz <matz@suse.de> wrote:
> Hi,
>
> On Tue, 10 Apr 2012, Jakub Jelinek wrote:
>
>> >    *) gcc implementation has lots of hard coded TREE_OPERAND (exp, nn)
>> >
>> >      e.g.
>> >             exp->as_component_ref().get_field() ..
>> >             exp->as_mem_access().get_base() ...
>> >             exp->as_mem_acesss().get_address() --> produces the
>> > address expression for memory access
>> >             exp->as_mem_access().get_alias_handle ()
>> >
>> >             gimple_inst->serialize (&fixup_list) --> a virtual
>> > function overriden by actual instruction types that knows its byte
>> > code format.
>>
>> That silently assumes we want to change basic GIMPLE/tree data structures
>> to virtual classes, which is a significant change that has a significant
>> cost as well.  E.g. all such changed data structures grow by a virtual
>> pointer field.  Those data structures are heavily optimized for memory
>> footprint.
>> Not to mention it is very questionable if the above stuff is more readable
>> than what we currently have.
>
> Actually it's not questionable.  The above stuff is _horrible_.
>

Specifics please.  It is _horrible_ because you are more used to the
existing way and the new style does not match your taste or they are
very hard to understand and use?

David


>
> Ciao,
> Michael.

Re: Switching to C++ by default in 4.8

[Michael Matz]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 986 bytes --]

Hi,

On Tue, 10 Apr 2012, Xinliang David Li wrote:

> >> >             exp->as_component_ref().get_field() ..

> > Actually it's not questionable.  The above stuff is _horrible_.
> 
> Specifics please.  It is _horrible_ because you are more used to the 
> existing way and the new style does not match your taste or they are 
> very hard to understand and use?

Your style (I wouldn't call it The New Style) is visually distracting, and 
therefore harder to understand and use, longer to write and full of 
syntactic noise without any whitespace.  Quite frankly, how anyone could 
ever say that

  exp->as_component_ref().get_field()

is easier to read/write/use than

  GET_FIELD_DECL (exp)

(say when we #define GET_FIELD_DECL(x) TREE_OPERAND(x,1)), with or without 
all-caps, is completely beyond me.  I pretty much hope that we never see 
the ugliness of the first way in GCCs code base.  Even in C++ it's 
possible to write non-spaghetti code.


Ciao,
Michael.

Re: Switching to C++ by default in 4.8

[Xinliang David Li]

On Tue, Apr 10, 2012 at 9:24 AM, Michael Matz <matz@suse.de> wrote:
> Hi,
>
> On Tue, 10 Apr 2012, Xinliang David Li wrote:
>
>> >> >             exp->as_component_ref().get_field() ..
>
>> > Actually it's not questionable.  The above stuff is _horrible_.
>>
>> Specifics please.  It is _horrible_ because you are more used to the
>> existing way and the new style does not match your taste or they are
>> very hard to understand and use?
>
> Your style (I wouldn't call it The New Style) is visually distracting, and
> therefore harder to understand and use, longer to write and full of
> syntactic noise without any whitespace.  Quite frankly, how anyone could
> ever say that
>
>  exp->as_component_ref().get_field()
>
> is easier to read/write/use than
>
>  GET_FIELD_DECL (exp)
>
> (say when we #define GET_FIELD_DECL(x) TREE_OPERAND(x,1)), with or without
> all-caps, is completely beyond me.  I pretty much hope that we never see
> the ugliness of the first way in GCCs code base.  Even in C++ it's
> possible to write non-spaghetti code.


As you said, this is still about taste -- and I agree the preference
to style is totally subjective. Changing to C++ style API will needed
to be justified by other things such as better static type checking,
elimination of unnecessary opcode checking when the most derived type
is known in the context etc.

Defining macros like GET_FIELD_DECL to replace TREE_OPERAND(...) is an
improvement by itself, but it can not prevent user from directly using
TREE_OPERAND(x,...) directly.

David

>
>
> Ciao,
> Michael.

Re: Switching to C++ by default in 4.8

[Torvald Riegel]

On Tue, 2012-04-10 at 18:24 +0200, Michael Matz wrote:
> Hi,
> 
> On Tue, 10 Apr 2012, Xinliang David Li wrote:
> 
> > >> >             exp->as_component_ref().get_field() ..
> 
> > > Actually it's not questionable.  The above stuff is _horrible_.
> > 
> > Specifics please.  It is _horrible_ because you are more used to the 
> > existing way and the new style does not match your taste or they are 
> > very hard to understand and use?
> 
> Your style (I wouldn't call it The New Style) is visually distracting, and 
> therefore harder to understand and use, longer to write and full of 
> syntactic noise without any whitespace.  Quite frankly, how anyone could 
> ever say that
> 
>   exp->as_component_ref().get_field()
> 
> is easier to read/write/use than
> 
>   GET_FIELD_DECL (exp)
> 
> (say when we #define GET_FIELD_DECL(x) TREE_OPERAND(x,1)), with or without 
> all-caps, is completely beyond me.  I pretty much hope that we never see 
> the ugliness of the first way in GCCs code base.  Even in C++ it's 
> possible to write non-spaghetti code.

I don't see how this is spaghetti code.  It it slightly longer, but
that's just the case in this specific example.

Think about programmers new to GCC for a second, and about code
completion tools.  It seems to me that with such a tool it's much easier
to navigate from exp to the field, than having to scan through a much
larger number of accessor functions / macros (GET_*).  The former
example starts at the source (exp) and yields/"builds" the result; the
latter names some function and then says applies it to the source.  Why
is the former so much worse?  To me, the former's structure is easier to
see, and if I would have to put the spaghetti tag on something, then the
latter.

Also, how do you envision code completion to work with the latter?  Type
exp first, and then have it show which functions take arguments
compatible with exp, and then replace it?  If a programmer doesn't
remember all of the GCC APIs, code completion tools are very convenient.

Torvald

Re: Switching to C++ by default in 4.8

[Eric Botcazou]

> Think about programmers new to GCC for a second, and about code
> completion tools.  It seems to me that with such a tool it's much easier
> to navigate from exp to the field, than having to scan through a much
> larger number of accessor functions / macros (GET_*).  The former
> example starts at the source (exp) and yields/"builds" the result; the
> latter names some function and then says applies it to the source.  Why
> is the former so much worse?

Because it takes x3 characters/x3 time to type/x3 slots in your memory?

> To me, the former's structure is easier to see, and if I would have to put
> the spaghetti tag on something, then the latter.

Spaghetti isn't really the best wording, gratuitous obfuscation is better. :-)

-- 
Eric Botcazou

Re: Switching to C++ by default in 4.8

[Torvald Riegel]

On Tue, 2012-04-10 at 19:59 +0200, Eric Botcazou wrote:
> > Think about programmers new to GCC for a second, and about code
> > completion tools.  It seems to me that with such a tool it's much easier
> > to navigate from exp to the field, than having to scan through a much
> > larger number of accessor functions / macros (GET_*).  The former
> > example starts at the source (exp) and yields/"builds" the result; the
> > latter names some function and then says applies it to the source.  Why
> > is the former so much worse?
> 
> Because it takes x3 characters/x3 time to type/x3 slots in your memory?

I hope this is meant to be ironic.

Or are you really saying that the number of characters determines how
quickly/easily a brain can remember/find something like an API
item/keyword/...?  If so, and if we assume that GET, FIELD, and DECL are
the most likely (sub-)parts of function names shouldn't it be G_F_D
(exp) then? ;)


Torvald

Re: Switching to C++ by default in 4.8

[Eric Botcazou]

> Or are you really saying that the number of characters determines how
> quickly/easily a brain can remember/find something like an API
> item/keyword/...?  If so, and if we assume that GET, FIELD, and DECL are
> the most likely (sub-)parts of function names shouldn't it be G_F_D
> (exp) then? ;)

The number of tokens.  GET_FIELD_DECL has 2 tokens (GET and FIELD_DECL) while 
exp->as_component_ref().get_field() has 3x more.

-- 
Eric Botcazou

Re: Switching to C++ by default in 4.8

[Torvald Riegel]

On Tue, 2012-04-10 at 23:12 +0200, Eric Botcazou wrote:
> > Or are you really saying that the number of characters determines how
> > quickly/easily a brain can remember/find something like an API
> > item/keyword/...?  If so, and if we assume that GET, FIELD, and DECL are
> > the most likely (sub-)parts of function names shouldn't it be G_F_D
> > (exp) then? ;)
> 
> The number of tokens.  GET_FIELD_DECL has 2 tokens (GET and FIELD_DECL) while 
> exp->as_component_ref().get_field() has 3x more.

I can't derive a definition of "token" from your example that seems
meaningful.  It can't be parser tokens I assume, because you split
GET_FIELD_DECL (but why in 2 not 3?).  Same for "exp->..."; where are
the 8 tokens? (Or did you in fact mean 3 times as much, so 6?).  In any
case, that suggests that the tokenization you had in mind is not obvious
(or perhaps just not to me).

Following another comment in the thread, what are the concepts you'd
like to be included, and which don't you want to be included?  Next
step, is this actually tied to saying FOO(exp) vs. exp->foo(), or could
your favorite (compression of) concepts be as well expressed with the
latter?

Re: Switching to C++ by default in 4.8

[Eric Botcazou]

> I can't derive a definition of "token" from your example that seems
> meaningful.  It can't be parser tokens I assume, because you split
> GET_FIELD_DECL (but why in 2 not 3?).

FIELD_DECL is a single object, see tree.def.

> Following another comment in the thread, what are the concepts you'd
> like to be included, and which don't you want to be included?  Next
> step, is this actually tied to saying FOO(exp) vs. exp->foo(), or could
> your favorite (compression of) concepts be as well expressed with the
> latter?

I'm entirely of DJ's opinion here: C vs C++ is not the same argument as style A 
vs style B.  I don't think that it would be desirable to fundamentally change 
the current style, at least to start adding -> and . all over the place.

-- 
Eric Botcazou

Re: Switching to C++ by default in 4.8

[Torvald Riegel]

On Wed, 2012-04-11 at 01:14 +0200, Eric Botcazou wrote:
> > I can't derive a definition of "token" from your example that seems
> > meaningful.  It can't be parser tokens I assume, because you split
> > GET_FIELD_DECL (but why in 2 not 3?).
> 
> FIELD_DECL is a single object, see tree.def.

So, you only know it's 2 tokens once you know all of tree.def?  I'm
aware that this is just some arbitrary example, but I believe this
actually strengthens the concern I had.

Re: Switching to C++ by default in 4.8

[Eric Botcazou]

> So, you only know it's 2 tokens once you know all of tree.def?  I'm
> aware that this is just some arbitrary example, but I believe this
> actually strengthens the concern I had.

Well, if you don't know of FIELD_DECL, you won't go very far, really.

-- 
Eric Botcazou

Re: Switching to C++ by default in 4.8

[Torvald Riegel]

On Wed, 2012-04-11 at 23:13 +0200, Eric Botcazou wrote:
> > So, you only know it's 2 tokens once you know all of tree.def?  I'm
> > aware that this is just some arbitrary example, but I believe this
> > actually strengthens the concern I had.
> 
> Well, if you don't know of FIELD_DECL, you won't go very far, really.

We are discussing a general style here, not this arbitrary example. (If
I am mistakenly assuming that, sorry; but then your original comparison
doesn't seem to be fair because you compare a shortcut against a verbose
form).

So assume the general case, GET_FOO_BAR (exp).  Is this about the BAR of
FOO, FOO of BAR, or FOOBAR?  If we have two concepts named FOOBAR for
different arguments, do we need GET_FOO_BAR_THIS and GET_FOO_BAR_THAT?
Point is, if there is no context that partitions items, you have to name
them differently, and you get less locality and reuse when thinking
about something.  That's for the long tail of course, shortcuts for the
most common stuff can still be used.
That's at least what I was commenting on.

Re: Switching to C++ by default in 4.8

[Dave Korn]

On 11/04/2012 22:13, Eric Botcazou wrote:
>> So, you only know it's 2 tokens once you know all of tree.def?  I'm
>> aware that this is just some arbitrary example, but I believe this
>> actually strengthens the concern I had.
> 
> Well, if you don't know of FIELD_DECL, you won't go very far, really.
> 

  But still, wouldn't it be nice and enhance clarity to be able to use a
different character/token between GET and FIELD_DECL than between FIELD and DECL?

  (Anyway, I still think we should start by just redefining GET_FIELD_DECL et.
al. as C++ inline functions - or macros that invoke C++ inline functions, or
whatever else that works better for whatever reason, regardless of the
implementation details - and let the existing code continue to use them in
exactly the same way as before.)

    cheers,
      DaveK

Re: Switching to C++ by default in 4.8

[Richard Guenther]

On Tue, Apr 10, 2012 at 7:29 PM, Torvald Riegel <triegel@redhat.com> wrote:
> On Tue, 2012-04-10 at 18:24 +0200, Michael Matz wrote:
>> Hi,
>>
>> On Tue, 10 Apr 2012, Xinliang David Li wrote:
>>
>> > >> >             exp->as_component_ref().get_field() ..
>>
>> > > Actually it's not questionable.  The above stuff is _horrible_.
>> >
>> > Specifics please.  It is _horrible_ because you are more used to the
>> > existing way and the new style does not match your taste or they are
>> > very hard to understand and use?
>>
>> Your style (I wouldn't call it The New Style) is visually distracting, and
>> therefore harder to understand and use, longer to write and full of
>> syntactic noise without any whitespace.  Quite frankly, how anyone could
>> ever say that
>>
>>   exp->as_component_ref().get_field()
>>
>> is easier to read/write/use than
>>
>>   GET_FIELD_DECL (exp)
>>
>> (say when we #define GET_FIELD_DECL(x) TREE_OPERAND(x,1)), with or without
>> all-caps, is completely beyond me.  I pretty much hope that we never see
>> the ugliness of the first way in GCCs code base.  Even in C++ it's
>> possible to write non-spaghetti code.
>
> I don't see how this is spaghetti code.  It it slightly longer, but
> that's just the case in this specific example.
>
> Think about programmers new to GCC for a second, and about code
> completion tools.

Honestly I care 1000 times more for existing GCC developers.  Before
new programmers will have an easier time with GCC _existing_ GCC
developers will have to spend at least two GCC release cycles (that's
very optimistic) turning the GCC codebase upside-down.  Every
existing GCC developer you lose on that way will slow down that
process and for every existing GCC developer you probably need more
that one "new" GCC developer starting.

It's very easy for me to do the math and conclude that losing even _one_
experienced existing GCC developer makes this whole transition-to-C++
thing a non-starter.

>  It seems to me that with such a tool it's much easier
> to navigate from exp to the field, than having to scan through a much
> larger number of accessor functions / macros (GET_*).  The former
> example starts at the source (exp) and yields/"builds" the result; the
> latter names some function and then says applies it to the source.  Why
> is the former so much worse?  To me, the former's structure is easier to
> see, and if I would have to put the spaghetti tag on something, then the
> latter.

Sounds more like missed features or bugs in the tools you use.  Heh,
after all our complaints that C++ will be harder to debug are deflected
to "that are gdb missing features / bugs".  So - file bugs against Eclipse
(or whatever new and shiny programmers use these days), that it does
not work well with a codebase like GCC.

Richard.

Re: Switching to C++ by default in 4.8

[Torvald Riegel]

On Wed, 2012-04-11 at 11:24 +0200, Richard Guenther wrote:
> On Tue, Apr 10, 2012 at 7:29 PM, Torvald Riegel <triegel@redhat.com> wrote:
> > Think about programmers new to GCC for a second, and about code
> > completion tools.
> 
> Honestly I care 1000 times more for existing GCC developers.  Before
> new programmers will have an easier time with GCC _existing_ GCC
> developers will have to spend at least two GCC release cycles (that's
> very optimistic) turning the GCC codebase upside-down.  Every
> existing GCC developer you lose on that way will slow down that
> process and for every existing GCC developer you probably need more
> that one "new" GCC developer starting.
> 
> It's very easy for me to do the math and conclude that losing even _one_
> experienced existing GCC developer makes this whole transition-to-C++
> thing a non-starter.

I agree that less work-force in the transition would be a problem.  But
is C++ (perceived to be) so bad that it would make people change their
jobs?  I mean, we're not talking about the experienced hobbyists here,
or are we?

However, the concern you raised is only one part of the problem.  The
other is that, put in a simplified way, GCC is competing with LLVM about
new and/or non-fulltime-compiler developers.  For me, it looks like LLVM
is more appealing to them, and I believe part of the reason for that is
the codebase.
Now, how many release cycles do we have until LLVM is basically good
enough to be used as a distro compiler (e.g., until code quality and
confidence in bug freedom is sufficiently similar)?  If we haven't
ensured that GCC is appealing by this time, why should new programmers
then start considering GCC and not just go by default to LLVM?

> 
> >  It seems to me that with such a tool it's much easier
> > to navigate from exp to the field, than having to scan through a much
> > larger number of accessor functions / macros (GET_*).  The former
> > example starts at the source (exp) and yields/"builds" the result; the
> > latter names some function and then says applies it to the source.  Why
> > is the former so much worse?  To me, the former's structure is easier to
> > see, and if I would have to put the spaghetti tag on something, then the
> > latter.
> 
> Sounds more like missed features or bugs in the tools you use.  Heh,
> after all our complaints that C++ will be harder to debug are deflected
> to "that are gdb missing features / bugs".  So - file bugs against Eclipse
> (or whatever new and shiny programmers use these days), that it does
> not work well with a codebase like GCC.

Please don't dismiss this so easily.  Of course this is just an example
and nothing major, but I believe many people will use tab completion on
the shell, for example, and code completion is really similar.  On the
shell, or with paths names, you start with typing something, then can
navigate from this context you provided.  That just works better when
you say context->function instead of function(context).
And I'm not a cognitive psychologist, but to me, seeing the context
first when reading left-to-right is also slightly easier to read.

Re: Switching to C++ by default in 4.8

[Richard Guenther]

On Wed, Apr 11, 2012 at 2:57 PM, Torvald Riegel <triegel@redhat.com> wrote:
> On Wed, 2012-04-11 at 11:24 +0200, Richard Guenther wrote:
>> On Tue, Apr 10, 2012 at 7:29 PM, Torvald Riegel <triegel@redhat.com> wrote:
>> > Think about programmers new to GCC for a second, and about code
>> > completion tools.
>>
>> Honestly I care 1000 times more for existing GCC developers.  Before
>> new programmers will have an easier time with GCC _existing_ GCC
>> developers will have to spend at least two GCC release cycles (that's
>> very optimistic) turning the GCC codebase upside-down.  Every
>> existing GCC developer you lose on that way will slow down that
>> process and for every existing GCC developer you probably need more
>> that one "new" GCC developer starting.
>>
>> It's very easy for me to do the math and conclude that losing even _one_
>> experienced existing GCC developer makes this whole transition-to-C++
>> thing a non-starter.
>
> I agree that less work-force in the transition would be a problem.  But
> is C++ (perceived to be) so bad that it would make people change their
> jobs?  I mean, we're not talking about the experienced hobbyists here,
> or are we?

Until some company puts money behind converting to C++ then yes,
it's the hobbyists (or the non-hobbyists in their spare time).

> However, the concern you raised is only one part of the problem.  The
> other is that, put in a simplified way, GCC is competing with LLVM about
> new and/or non-fulltime-compiler developers.  For me, it looks like LLVM
> is more appealing to them, and I believe part of the reason for that is
> the codebase.
> Now, how many release cycles do we have until LLVM is basically good
> enough to be used as a distro compiler (e.g., until code quality and
> confidence in bug freedom is sufficiently similar)?  If we haven't
> ensured that GCC is appealing by this time, why should new programmers
> then start considering GCC and not just go by default to LLVM?

If you look at the existing developer base then the majority of it is paid.
And frankly while empolyers may listen to their employees, switching
from GCC to LLVM is not something they'd do based on a C++ vs. C
implementation language (but maybe based on availability of consulting
services or new employees or viability of using LLVM for weird architectures
or simply based on customer demand).

>>
>> >  It seems to me that with such a tool it's much easier
>> > to navigate from exp to the field, than having to scan through a much
>> > larger number of accessor functions / macros (GET_*).  The former
>> > example starts at the source (exp) and yields/"builds" the result; the
>> > latter names some function and then says applies it to the source.  Why
>> > is the former so much worse?  To me, the former's structure is easier to
>> > see, and if I would have to put the spaghetti tag on something, then the
>> > latter.
>>
>> Sounds more like missed features or bugs in the tools you use.  Heh,
>> after all our complaints that C++ will be harder to debug are deflected
>> to "that are gdb missing features / bugs".  So - file bugs against Eclipse
>> (or whatever new and shiny programmers use these days), that it does
>> not work well with a codebase like GCC.
>
> Please don't dismiss this so easily.  Of course this is just an example
> and nothing major, but I believe many people will use tab completion on
> the shell, for example, and code completion is really similar.  On the
> shell, or with paths names, you start with typing something, then can
> navigate from this context you provided.  That just works better when
> you say context->function instead of function(context).
> And I'm not a cognitive psychologist, but to me, seeing the context
> first when reading left-to-right is also slightly easier to read.

Well, but mult (add (x, y), z) is easier to understand than x.add (y).mult (z)
because operator precedence is visible.

Similar for doit (a, b) compared to a.doit (b) (or b.doit (a) - what preference
is there for two inputs?).  So you likely end up with a mix anyway.

Richard.

Re: Switching to C++ by default in 4.8

[Gabriel Dos Reis]

On Wed, Apr 11, 2012 at 8:13 AM, Richard Guenther
<richard.guenther@gmail.com> wrote:

>> Please don't dismiss this so easily.  Of course this is just an example
>> and nothing major, but I believe many people will use tab completion on
>> the shell, for example, and code completion is really similar.  On the
>> shell, or with paths names, you start with typing something, then can
>> navigate from this context you provided.  That just works better when
>> you say context->function instead of function(context).
>> And I'm not a cognitive psychologist, but to me, seeing the context
>> first when reading left-to-right is also slightly easier to read.
>
> Well, but mult (add (x, y), z) is easier to understand than x.add (y).mult (z)
> because operator precedence is visible.

that might be true but I do not think C++ wants you to write x.add(y).mult(z).

-- Gaby

Re: Switching to C++ by default in 4.8

[Torvald Riegel]

On Wed, 2012-04-11 at 15:13 +0200, Richard Guenther wrote:
> On Wed, Apr 11, 2012 at 2:57 PM, Torvald Riegel <triegel@redhat.com> wrote:
> > On Wed, 2012-04-11 at 11:24 +0200, Richard Guenther wrote:
> >> On Tue, Apr 10, 2012 at 7:29 PM, Torvald Riegel <triegel@redhat.com> wrote:
> >> > Think about programmers new to GCC for a second, and about code
> >> > completion tools.
> >>
> >> Honestly I care 1000 times more for existing GCC developers.  Before
> >> new programmers will have an easier time with GCC _existing_ GCC
> >> developers will have to spend at least two GCC release cycles (that's
> >> very optimistic) turning the GCC codebase upside-down.  Every
> >> existing GCC developer you lose on that way will slow down that
> >> process and for every existing GCC developer you probably need more
> >> that one "new" GCC developer starting.
> >>
> >> It's very easy for me to do the math and conclude that losing even _one_
> >> experienced existing GCC developer makes this whole transition-to-C++
> >> thing a non-starter.
> >
> > I agree that less work-force in the transition would be a problem.  But
> > is C++ (perceived to be) so bad that it would make people change their
> > jobs?  I mean, we're not talking about the experienced hobbyists here,
> > or are we?
> 
> Until some company puts money behind converting to C++ then yes,
> it's the hobbyists (or the non-hobbyists in their spare time).

That is not what I said.  The question I raised is whether a change to
C++ aimed at growing the developer base would actually make full-time
GCC developers change their jobs.

What you are questioning is whether a single company would make itself
responsible for the conversion.  This is two different questions.

And elsewhere in the thread, you assert that if the conversion happened,
other developers would stop working on it (i.e., my question above).  If
this would indeed be the case, nobody would fulfill your request (money
behind the conversion).  So let's look at the first one first.

> 
> > However, the concern you raised is only one part of the problem.  The
> > other is that, put in a simplified way, GCC is competing with LLVM about
> > new and/or non-fulltime-compiler developers.  For me, it looks like LLVM
> > is more appealing to them, and I believe part of the reason for that is
> > the codebase.
> > Now, how many release cycles do we have until LLVM is basically good
> > enough to be used as a distro compiler (e.g., until code quality and
> > confidence in bug freedom is sufficiently similar)?  If we haven't
> > ensured that GCC is appealing by this time, why should new programmers
> > then start considering GCC and not just go by default to LLVM?
> 
> If you look at the existing developer base then the majority of it is paid.
> And frankly while empolyers may listen to their employees, switching
> from GCC to LLVM is not something they'd do based on a C++ vs. C
> implementation language (but maybe based on availability of consulting
> services or new employees or viability of using LLVM for weird architectures
> or simply based on customer demand).

Makes sense.  But you also say that a switch in the language doesn't
really matter for paid developers (or their employers), so why is there
then such a strong opposition towards a switch? (assuming that the
switch might have benefits to new developers..)

Also, AFAICT, LLVM is attracting more new paid developers than GCC, or
not?  For them, they don't have to switch from GCC to LLVM, they simply
don't start with GCC.  That is certainly due to differences in the
license to some extent, but if employers believe that they can get their
employees to a quicker start when using LLVM, then this is bad for GCC.

> >>
> >> >  It seems to me that with such a tool it's much easier
> >> > to navigate from exp to the field, than having to scan through a much
> >> > larger number of accessor functions / macros (GET_*).  The former
> >> > example starts at the source (exp) and yields/"builds" the result; the
> >> > latter names some function and then says applies it to the source.  Why
> >> > is the former so much worse?  To me, the former's structure is easier to
> >> > see, and if I would have to put the spaghetti tag on something, then the
> >> > latter.
> >>
> >> Sounds more like missed features or bugs in the tools you use.  Heh,
> >> after all our complaints that C++ will be harder to debug are deflected
> >> to "that are gdb missing features / bugs".  So - file bugs against Eclipse
> >> (or whatever new and shiny programmers use these days), that it does
> >> not work well with a codebase like GCC.
> >
> > Please don't dismiss this so easily.  Of course this is just an example
> > and nothing major, but I believe many people will use tab completion on
> > the shell, for example, and code completion is really similar.  On the
> > shell, or with paths names, you start with typing something, then can
> > navigate from this context you provided.  That just works better when
> > you say context->function instead of function(context).
> > And I'm not a cognitive psychologist, but to me, seeing the context
> > first when reading left-to-right is also slightly easier to read.
> 
> Well, but mult (add (x, y), z) is easier to understand than x.add (y).mult (z)
> because operator precedence is visible.
> 
> Similar for doit (a, b) compared to a.doit (b) (or b.doit (a) - what preference
> is there for two inputs?).  So you likely end up with a mix anyway.

Yes.  But mult, add, and the doit don't have a single context, they have
two.  On the other hand, consider two-input but single-context examples
such as read(obj, property) vs. obj.read(property); which makes the
context more easily visible?

So, it's not about the number of inputs, it's whether there is a
dominating context.  You have that, for example,  when starting
navigating a graph from somewhere (eg, CFG), adding leafs to a tree
node, getting or setting properties of an object, etc.
I would guess that such operations are pretty common, more so than
operations with more than one context.

Also, I don't think anyone is arguing for a one-size-fits-all approach
here.  A mix isn't a problem really, as long as it easily reveals the
structure of the program logic (e.g., stuff like contexts, or operator
precedence as you mention).

Re: Switching to C++ by default in 4.8

[Xinliang David Li]

On Wed, Apr 11, 2012 at 6:13 AM, Richard Guenther
<richard.guenther@gmail.com> wrote:
> On Wed, Apr 11, 2012 at 2:57 PM, Torvald Riegel <triegel@redhat.com> wrote:
>> On Wed, 2012-04-11 at 11:24 +0200, Richard Guenther wrote:
>>> On Tue, Apr 10, 2012 at 7:29 PM, Torvald Riegel <triegel@redhat.com> wrote:
>>> > Think about programmers new to GCC for a second, and about code
>>> > completion tools.
>>>
>>> Honestly I care 1000 times more for existing GCC developers.  Before
>>> new programmers will have an easier time with GCC _existing_ GCC
>>> developers will have to spend at least two GCC release cycles (that's
>>> very optimistic) turning the GCC codebase upside-down.  Every
>>> existing GCC developer you lose on that way will slow down that
>>> process and for every existing GCC developer you probably need more
>>> that one "new" GCC developer starting.
>>>
>>> It's very easy for me to do the math and conclude that losing even _one_
>>> experienced existing GCC developer makes this whole transition-to-C++
>>> thing a non-starter.
>>
>> I agree that less work-force in the transition would be a problem.  But
>> is C++ (perceived to be) so bad that it would make people change their
>> jobs?  I mean, we're not talking about the experienced hobbyists here,
>> or are we?
>
> Until some company puts money behind converting to C++ then yes,
> it's the hobbyists (or the non-hobbyists in their spare time).
>
>> However, the concern you raised is only one part of the problem.  The
>> other is that, put in a simplified way, GCC is competing with LLVM about
>> new and/or non-fulltime-compiler developers.  For me, it looks like LLVM
>> is more appealing to them, and I believe part of the reason for that is
>> the codebase.
>> Now, how many release cycles do we have until LLVM is basically good
>> enough to be used as a distro compiler (e.g., until code quality and
>> confidence in bug freedom is sufficiently similar)?  If we haven't
>> ensured that GCC is appealing by this time, why should new programmers
>> then start considering GCC and not just go by default to LLVM?
>
> If you look at the existing developer base then the majority of it is paid.
> And frankly while empolyers may listen to their employees, switching
> from GCC to LLVM is not something they'd do based on a C++ vs. C
> implementation language (but maybe based on availability of consulting
> services or new employees or viability of using LLVM for weird architectures
> or simply based on customer demand).

Yes, GCC is still in some comfortable zones such as generated code
quality, performance, etc, but the advantage and gap is quickly
reducing (e.g, LLVM is the default compiler in Xcode) -- and other
advantages in LLVM (will soon) outweigh its disadvantages. It has a
very modern frontend Clang which is *very* attractive to application
developers (better diagnostics, better IDE integration, easier to
develop tools on, lean and mean etc); and believe it or not, their
compiler developer base is also growing just for the perception it is
more modern and it is easier to develop on (and words are spreading;
there were also independent investigations on ease of development on
some compiler features in gcc and LLVM from new developers and the
result is in favor of LLVM).

thanks,

David



>
>>>
>>> >  It seems to me that with such a tool it's much easier
>>> > to navigate from exp to the field, than having to scan through a much
>>> > larger number of accessor functions / macros (GET_*).  The former
>>> > example starts at the source (exp) and yields/"builds" the result; the
>>> > latter names some function and then says applies it to the source.  Why
>>> > is the former so much worse?  To me, the former's structure is easier to
>>> > see, and if I would have to put the spaghetti tag on something, then the
>>> > latter.
>>>
>>> Sounds more like missed features or bugs in the tools you use.  Heh,
>>> after all our complaints that C++ will be harder to debug are deflected
>>> to "that are gdb missing features / bugs".  So - file bugs against Eclipse
>>> (or whatever new and shiny programmers use these days), that it does
>>> not work well with a codebase like GCC.
>>
>> Please don't dismiss this so easily.  Of course this is just an example
>> and nothing major, but I believe many people will use tab completion on
>> the shell, for example, and code completion is really similar.  On the
>> shell, or with paths names, you start with typing something, then can
>> navigate from this context you provided.  That just works better when
>> you say context->function instead of function(context).
>> And I'm not a cognitive psychologist, but to me, seeing the context
>> first when reading left-to-right is also slightly easier to read.
>
> Well, but mult (add (x, y), z) is easier to understand than x.add (y).mult (z)
> because operator precedence is visible.
>
> Similar for doit (a, b) compared to a.doit (b) (or b.doit (a) - what preference
> is there for two inputs?).  So you likely end up with a mix anyway.
>
> Richard.

Re: Switching to C++ by default in 4.8

[Andrew Pinski]

On Wed, Apr 11, 2012 at 10:24 AM, Xinliang David Li <davidxl@google.com> wrote:
> On Wed, Apr 11, 2012 at 6:13 AM, Richard Guenther
> <richard.guenther@gmail.com> wrote:
>> On Wed, Apr 11, 2012 at 2:57 PM, Torvald Riegel <triegel@redhat.com> wrote:
>>> On Wed, 2012-04-11 at 11:24 +0200, Richard Guenther wrote:
>>>> On Tue, Apr 10, 2012 at 7:29 PM, Torvald Riegel <triegel@redhat.com> wrote:
>>>> > Think about programmers new to GCC for a second, and about code
>>>> > completion tools.
>>>>
>>>> Honestly I care 1000 times more for existing GCC developers.  Before
>>>> new programmers will have an easier time with GCC _existing_ GCC
>>>> developers will have to spend at least two GCC release cycles (that's
>>>> very optimistic) turning the GCC codebase upside-down.  Every
>>>> existing GCC developer you lose on that way will slow down that
>>>> process and for every existing GCC developer you probably need more
>>>> that one "new" GCC developer starting.
>>>>
>>>> It's very easy for me to do the math and conclude that losing even _one_
>>>> experienced existing GCC developer makes this whole transition-to-C++
>>>> thing a non-starter.
>>>
>>> I agree that less work-force in the transition would be a problem.  But
>>> is C++ (perceived to be) so bad that it would make people change their
>>> jobs?  I mean, we're not talking about the experienced hobbyists here,
>>> or are we?
>>
>> Until some company puts money behind converting to C++ then yes,
>> it's the hobbyists (or the non-hobbyists in their spare time).
>>
>>> However, the concern you raised is only one part of the problem.  The
>>> other is that, put in a simplified way, GCC is competing with LLVM about
>>> new and/or non-fulltime-compiler developers.  For me, it looks like LLVM
>>> is more appealing to them, and I believe part of the reason for that is
>>> the codebase.
>>> Now, how many release cycles do we have until LLVM is basically good
>>> enough to be used as a distro compiler (e.g., until code quality and
>>> confidence in bug freedom is sufficiently similar)?  If we haven't
>>> ensured that GCC is appealing by this time, why should new programmers
>>> then start considering GCC and not just go by default to LLVM?
>>
>> If you look at the existing developer base then the majority of it is paid.
>> And frankly while empolyers may listen to their employees, switching
>> from GCC to LLVM is not something they'd do based on a C++ vs. C
>> implementation language (but maybe based on availability of consulting
>> services or new employees or viability of using LLVM for weird architectures
>> or simply based on customer demand).
>
> Yes, GCC is still in some comfortable zones such as generated code
> quality, performance, etc, but the advantage and gap is quickly
> reducing (e.g, LLVM is the default compiler in Xcode) -- and other
> advantages in LLVM (will soon) outweigh its disadvantages. It has a
> very modern frontend Clang which is *very* attractive to application
> developers (better diagnostics, better IDE integration, easier to
> develop tools on, lean and mean etc); and believe it or not, their
> compiler developer base is also growing just for the perception it is
> more modern and it is easier to develop on (and words are spreading;
> there were also independent investigations on ease of development on
> some compiler features in gcc and LLVM from new developers and the
> result is in favor of LLVM).

The main reason why LLVM is the default compiler in XCode is license
rather any technical reason.
And GCC usually has better diagnostic than clang except in those few
areas which it does not (those some might say those areas are the most
important ones).

I have known people who does not want to deal with GCC because they
are very anti GPL or GNU rather than GCC having a clean/modern
interface.

It is hard to win those guys over but those are the ones which are
spreading in some cases FUD about GCC.

-- Pinski

Re: Switching to C++ by default in 4.8

[Xinliang David Li]

On Wed, Apr 11, 2012 at 11:17 AM, Andrew Pinski <pinskia@gmail.com> wrote:
> On Wed, Apr 11, 2012 at 10:24 AM, Xinliang David Li <davidxl@google.com> wrote:
>> On Wed, Apr 11, 2012 at 6:13 AM, Richard Guenther
>> <richard.guenther@gmail.com> wrote:
>>> On Wed, Apr 11, 2012 at 2:57 PM, Torvald Riegel <triegel@redhat.com> wrote:
>>>> On Wed, 2012-04-11 at 11:24 +0200, Richard Guenther wrote:
>>>>> On Tue, Apr 10, 2012 at 7:29 PM, Torvald Riegel <triegel@redhat.com> wrote:
>>>>> > Think about programmers new to GCC for a second, and about code
>>>>> > completion tools.
>>>>>
>>>>> Honestly I care 1000 times more for existing GCC developers.  Before
>>>>> new programmers will have an easier time with GCC _existing_ GCC
>>>>> developers will have to spend at least two GCC release cycles (that's
>>>>> very optimistic) turning the GCC codebase upside-down.  Every
>>>>> existing GCC developer you lose on that way will slow down that
>>>>> process and for every existing GCC developer you probably need more
>>>>> that one "new" GCC developer starting.
>>>>>
>>>>> It's very easy for me to do the math and conclude that losing even _one_
>>>>> experienced existing GCC developer makes this whole transition-to-C++
>>>>> thing a non-starter.
>>>>
>>>> I agree that less work-force in the transition would be a problem.  But
>>>> is C++ (perceived to be) so bad that it would make people change their
>>>> jobs?  I mean, we're not talking about the experienced hobbyists here,
>>>> or are we?
>>>
>>> Until some company puts money behind converting to C++ then yes,
>>> it's the hobbyists (or the non-hobbyists in their spare time).
>>>
>>>> However, the concern you raised is only one part of the problem.  The
>>>> other is that, put in a simplified way, GCC is competing with LLVM about
>>>> new and/or non-fulltime-compiler developers.  For me, it looks like LLVM
>>>> is more appealing to them, and I believe part of the reason for that is
>>>> the codebase.
>>>> Now, how many release cycles do we have until LLVM is basically good
>>>> enough to be used as a distro compiler (e.g., until code quality and
>>>> confidence in bug freedom is sufficiently similar)?  If we haven't
>>>> ensured that GCC is appealing by this time, why should new programmers
>>>> then start considering GCC and not just go by default to LLVM?
>>>
>>> If you look at the existing developer base then the majority of it is paid.
>>> And frankly while empolyers may listen to their employees, switching
>>> from GCC to LLVM is not something they'd do based on a C++ vs. C
>>> implementation language (but maybe based on availability of consulting
>>> services or new employees or viability of using LLVM for weird architectures
>>> or simply based on customer demand).
>>
>> Yes, GCC is still in some comfortable zones such as generated code
>> quality, performance, etc, but the advantage and gap is quickly
>> reducing (e.g, LLVM is the default compiler in Xcode) -- and other
>> advantages in LLVM (will soon) outweigh its disadvantages. It has a
>> very modern frontend Clang which is *very* attractive to application
>> developers (better diagnostics, better IDE integration, easier to
>> develop tools on, lean and mean etc); and believe it or not, their
>> compiler developer base is also growing just for the perception it is
>> more modern and it is easier to develop on (and words are spreading;
>> there were also independent investigations on ease of development on
>> some compiler features in gcc and LLVM from new developers and the
>> result is in favor of LLVM).
>
> The main reason why LLVM is the default compiler in XCode is license
> rather any technical reason.
> And GCC usually has better diagnostic than clang except in those few
> areas which it does not (those some might say those areas are the most
> important ones).
>
> I have known people who does not want to deal with GCC because they
> are very anti GPL or GNU rather than GCC having a clean/modern
> interface.
>
> It is hard to win those guys over but those are the ones which are
> spreading in some cases FUD about GCC.
>

Possibly true -- it might be a good idea to collect more data to
backup any claims here.

David

> -- Pinski

Re: Switching to C++ by default in 4.8

[Ian Lance Taylor]

Andrew Pinski <pinskia@gmail.com> writes:

> The main reason why LLVM is the default compiler in XCode is license
> rather any technical reason.

Yes.

> And GCC usually has better diagnostic than clang except in those few
> areas which it does not (those some might say those areas are the most
> important ones).

No.  clang's diagnostics for C++ are much much better than GCC's.
Obviously GCC's can improve, but today clang's are much better.

Ian

Re: Switching to C++ by default in 4.8

[Miles Bader]

Ian Lance Taylor <iant@google.com> writes:
>> And GCC usually has better diagnostic than clang except in those few
>> areas which it does not (those some might say those areas are the most
>> important ones).
>
> No.  clang's diagnostics for C++ are much much better than GCC's.
> Obviously GCC's can improve, but today clang's are much better.

Meh.  Clang's diagnostics are often pretty good, and it's rightly lauded
for that, but the "OMG clang totally murders gcc for diagnostics!" meme
(which seems to be staple of clang's unfortunately large fanboi
contingent) is an exaggeration.  Clang's diagnostics are not _that_
good, gcc's are [currently] not that bad, and the situations where the
difference is the most noticeable tend to be obscure.

(remember: Only Henry Spencer can say "No." and really get away with
it...)

-miles

-- 
Non-combatant, n. A dead Quaker.

Re: Switching to C++ by default in 4.8

[James Dennett]

On Wed, Apr 11, 2012 at 11:11 PM, Miles Bader <miles@gnu.org> wrote:
> Ian Lance Taylor <iant@google.com> writes:
>>> And GCC usually has better diagnostic than clang except in those few
>>> areas which it does not (those some might say those areas are the most
>>> important ones).
>>
>> No.  clang's diagnostics for C++ are much much better than GCC's.
>> Obviously GCC's can improve, but today clang's are much better.
>
> Meh.  Clang's diagnostics are often pretty good, and it's rightly lauded
> for that, but the "OMG clang totally murders gcc for diagnostics!" meme
> (which seems to be staple of clang's unfortunately large fanboi
> contingent) is an exaggeration.

Yes, the most extreme advocates (of anything) tend to get lost in a
land of exaggeration.

> Clang's diagnostics are not _that_ good,

I'd agree there.

> gcc's are [currently] not that bad,

But for common cases (and a lot of less common ones) they're nowhere
near as good as Clang's...

> and the situations where the
> difference is the most noticeable tend to be obscure.

Here, based on experience, I disagree.  I often have non-experts
mention to me just how surprisingly clear/useful they've found Clang's
error messages (with cause), and that essentially never happened for
gcc's error messages.  There are many common cases where Clang
correctly identifies the user's mistake, and gcc reports something
that is formally correct but much harder to map back to what the user
did wrong.

I don't disagree that gcc's diagnostics have greatly improved, and
seem to continue to do so, but they're still a long way behind.  Which
isn't to say that Clang doesn't have issues -- some fraction of the
time I find Clang's diagnostics to be pretty awful, and I'm so used to
deciphering gcc's messages that I often don't notice how far removed
they are from the underlying problem.

However, this gets dangerously close to thread-jacking, and I don't
want to digress too far into GCC vs Clang comparisons.  The two are
different and have somewhat different goals, and IMO competition is
good for the community overall.

-- James

Re: Switching to C++ by default in 4.8

[Jonathan Wakely]

On 11 April 2012 18:24, Xinliang David Li wrote:
>
> Yes, GCC is still in some comfortable zones such as generated code
> quality, performance, etc, but the advantage and gap is quickly
> reducing (e.g, LLVM is the default compiler in Xcode) -- and other
> advantages in LLVM (will soon) outweigh its disadvantages. It has a
> very modern frontend Clang which is *very* attractive to application
> developers (better diagnostics, better IDE integration, easier to
...

GCC's diagnostics have got a lot better recently.

The http://clang.llvm.org/diagnostics.html page compares clang's
diagnostics to GCC 4.2, which was outdated long before that page was
written.

It doesn't help GCC's cause when people keep repeating that outdated info :-)

Re: Switching to C++ by default in 4.8

[Pedro Alves]

On 04/11/2012 07:26 PM, Jonathan Wakely wrote:

> GCC's diagnostics have got a lot better recently.
> 
> The http://clang.llvm.org/diagnostics.html page compares clang's
> diagnostics to GCC 4.2, which was outdated long before that page was
> written.
> 
> It doesn't help GCC's cause when people keep repeating that outdated info :-)


Spelling out the obvious, IWBVN if someone from the gcc camp did a
similar comparison using a current gcc.  Is there such a page somewhere?

-- 
Pedro Alves

Re: Switching to C++ by default in 4.8

[Xinliang David Li]

On Wed, Apr 11, 2012 at 11:26 AM, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
> On 11 April 2012 18:24, Xinliang David Li wrote:
>>
>> Yes, GCC is still in some comfortable zones such as generated code
>> quality, performance, etc, but the advantage and gap is quickly
>> reducing (e.g, LLVM is the default compiler in Xcode) -- and other
>> advantages in LLVM (will soon) outweigh its disadvantages. It has a
>> very modern frontend Clang which is *very* attractive to application
>> developers (better diagnostics, better IDE integration, easier to
> ...
>
> GCC's diagnostics have got a lot better recently.
>

Proof? A similar page from gcc would be more helpful here.

> The http://clang.llvm.org/diagnostics.html page compares clang's
> diagnostics to GCC 4.2, which was outdated long before that page was
> written.
>
> It doesn't help GCC's cause when people keep repeating that outdated info :-)

Well -- because there is no up-to-date information for people to look at :(.

David

Re: Switching to C++ by default in 4.8

[Jonathan Wakely]

On 11 April 2012 21:00, Xinliang David Li <davidxl@google.com> wrote:
> On Wed, Apr 11, 2012 at 11:26 AM, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
>> On 11 April 2012 18:24, Xinliang David Li wrote:
>>>
>>> Yes, GCC is still in some comfortable zones such as generated code
>>> quality, performance, etc, but the advantage and gap is quickly
>>> reducing (e.g, LLVM is the default compiler in Xcode) -- and other
>>> advantages in LLVM (will soon) outweigh its disadvantages. It has a
>>> very modern frontend Clang which is *very* attractive to application
>>> developers (better diagnostics, better IDE integration, easier to
>> ...
>>
>> GCC's diagnostics have got a lot better recently.
>>
>
> Proof? A similar page from gcc would be more helpful here.

It's all in bugzilla.  Look for Nathan Froyd's checkins e.g. regarding
missing semi-colons after class declarations and reasons for overload
resolution failure and template argument deduction failures.  And
Manu's work on many diagnostic issues includes the brand new caret
diagnostics.

I don't need proof, I see the benefits every day.  Those who need
convincing should feel free to do the comparisons themselves :-)

I can provide testcases for which G++ produces far superior results to clang++.

>> The http://clang.llvm.org/diagnostics.html page compares clang's
>> diagnostics to GCC 4.2, which was outdated long before that page was
>> written.
>>
>> It doesn't help GCC's cause when people keep repeating that outdated info :-)
>
> Well -- because there is no up-to-date information for people to look at :(.

I get my views on their relative merits from actually using GCC and
clang, not from out of date webpages.

Re: Switching to C++ by default in 4.8

[Ian Lance Taylor]

Jonathan Wakely <jwakely.gcc@gmail.com> writes:

> I get my views on their relative merits from actually using GCC and
> clang, not from out of date webpages.

Me too, and I think clang's are better.

Simply having caret diagnostics and good suggestions are quite important
for people who are not C++ experts.

Ian

Re: Switching to C++ by default in 4.8

[Richard Guenther]

2012/4/11 Paweł Sikora <pluto@agmk.net>:
> On Wednesday 11 of April 2012 14:57:53 Torvald Riegel wrote:
>
>
>
>> Now, how many release cycles do we have until LLVM is basically good
>
>> enough to be used as a distro compiler
>
>
>
> freebsd-9 switches to clang/llvm as a distro compiler.
>
> some info @ http://wiki.freebsd.org/BuildingFreeBSDWithClang

Only because we are so evil to not maintain their GPL v2 GCC 4.2.2 codebase
anymore :P

Richard.

Re: Switching to C++ by default in 4.8

[Bernd Schmidt]

On 04/11/2012 02:57 PM, Torvald Riegel wrote:
> However, the concern you raised is only one part of the problem.  The
> other is that, put in a simplified way, GCC is competing with LLVM about
> new and/or non-fulltime-compiler developers.  For me, it looks like LLVM
> is more appealing to them, and I believe part of the reason for that is
> the codebase.

There seem to be other opinions as well, some voiced in this thread,
which just supports my argument that you can't do it right for everyone.
Part of the reason LLVM is appealing may just be advertising, which we
don't do at all, perhaps due to the deep-seated inferiority complex we
have about gcc.

> Now, how many release cycles do we have until LLVM is basically good
> enough to be used as a distro compiler (e.g., until code quality and
> confidence in bug freedom is sufficiently similar)?  If we haven't
> ensured that GCC is appealing by this time, why should new programmers
> then start considering GCC and not just go by default to LLVM?

Maybe we should concentrate on our own strengths. Improve the
optimizers, support more targets well, fully implement language
standards, etc.  Spending developer time on something fruitless like a
language switch has an opportunity cost, it just gives competing
projects more time to catch up in areas that matter for users.


Bernd

Re: Switching to C++ by default in 4.8

[Xinliang David Li]

On Wed, Apr 11, 2012 at 6:21 AM, Bernd Schmidt <bernds@codesourcery.com> wrote:
> On 04/11/2012 02:57 PM, Torvald Riegel wrote:
>> However, the concern you raised is only one part of the problem.  The
>> other is that, put in a simplified way, GCC is competing with LLVM about
>> new and/or non-fulltime-compiler developers.  For me, it looks like LLVM
>> is more appealing to them, and I believe part of the reason for that is
>> the codebase.
>
> There seem to be other opinions as well, some voiced in this thread,
> which just supports my argument that you can't do it right for everyone.
> Part of the reason LLVM is appealing may just be advertising, which we
> don't do at all, perhaps due to the deep-seated inferiority complex we
> have about gcc.

yes -- GCC is not considered old and not 'cool' -- so it is hard to
advertise. One criteria to see GCC's future popularity is how widely
it is adopted by academia ..

>
>> Now, how many release cycles do we have until LLVM is basically good
>> enough to be used as a distro compiler (e.g., until code quality and
>> confidence in bug freedom is sufficiently similar)?  If we haven't
>> ensured that GCC is appealing by this time, why should new programmers
>> then start considering GCC and not just go by default to LLVM?
>
> Maybe we should concentrate on our own strengths. Improve the
> optimizers, support more targets well, fully implement language
> standards, etc.  Spending developer time on something fruitless like a
> language switch has an opportunity cost, it just gives competing
> projects more time to catch up in areas that matter for users.

but LLVM is not standing still either ..


David
>
>
> Bernd

Re: Switching to C++ by default in 4.8

[Basile Starynkevitch]

On Wed, 11 Apr 2012 10:30:36 -0700
Xinliang David Li <davidxl@google.com> wrote:
[..]
> 
> yes -- GCC is not considered old and not 'cool' -- so it is hard to
> advertise. One criteria to see GCC's future popularity is how widely
> it is adopted by academia ..


Do you mean used by academia (including teaching programming with students using GCC), or
do you mean that academia is teaching the internals of GCC, and e.g. have lots of e.g.
PhD students & professors doing their research using and *improving* GCC.

My feeling is that the plugin ability of GCC should help academia to work more on (that
is, "inside") GCC, to only to use GCC.

(and I am not very very optimistic, in particular because the internal APIs of GCC are
not very well documented, not very well agreed upon...).

Cheers.

-- 
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***

Re: Switching to C++ by default in 4.8

[Gabriel Dos Reis]

On Wed, Apr 11, 2012 at 1:37 PM, Basile Starynkevitch
<basile@starynkevitch.net> wrote:
> On Wed, 11 Apr 2012 10:30:36 -0700
> Xinliang David Li <davidxl@google.com> wrote:
> [..]
>>
>> yes -- GCC is not considered old and not 'cool' -- so it is hard to
>> advertise. One criteria to see GCC's future popularity is how widely
>> it is adopted by academia ..
>
>
> Do you mean used by academia (including teaching programming with students using GCC), or
> do you mean that academia is teaching the internals of GCC, and e.g. have lots of e.g.
> PhD students & professors doing their research using and *improving* GCC.

I don't see how acceptable plugins for GCC would make my students' life
easy for the projects they are currently working on.  But, I can see
other projects
with less invasive structures -- but then there are many alternative
infrastructures
out there that would make such projects just as easy (starting with eclipse or
clang) for the kind of things academia is usually excited about.

-- Gaby

Re: Switching to C++ by default in 4.8

[Xinliang David Li]

On Wed, Apr 11, 2012 at 11:37 AM, Basile Starynkevitch
<basile@starynkevitch.net> wrote:
> On Wed, 11 Apr 2012 10:30:36 -0700
> Xinliang David Li <davidxl@google.com> wrote:
> [..]
>>
>> yes -- GCC is not considered old and not 'cool' -- so it is hard to
>> advertise. One criteria to see GCC's future popularity is how widely
>> it is adopted by academia ..
>
>
> Do you mean used by academia (including teaching programming with students using GCC), or
> do you mean that academia is teaching the internals of GCC, and e.g. have lots of e.g.
> PhD students & professors doing their research using and *improving* GCC.

I mean to use GCC infrastructure to do research such as program
analysis and develop very advanced optimization techniques.

>
> My feeling is that the plugin ability of GCC should help academia to work more on (that
> is, "inside") GCC, to only to use GCC.

Plugins can be useful for function level work. For IPA, plugins
probably won't be useful. For instance, if someone wants to develop
very advanced CS/FS sensitive alias analysis in GCC and demonstrate
performance, the aliaser should provide good update APIs to allow the
new analysis results to be usable by backend components
(transparently) without worrying about how the data can be used.

>
> (and I am not very very optimistic, in particular because the internal APIs of GCC are
> not very well documented, not very well agreed upon...).
>

And old plugins can get out of sync with core IRs easily due to lack
of good data isolation/hiding.

If gcc has a well defined streaming format and standard ir
reader/writer, it will make tool developers very happy.

David


> Cheers.
>
> --
> Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
> email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
> 8, rue de la Faiencerie, 92340 Bourg La Reine, France
> *** opinions {are only mine, sont seulement les miennes} ***

Re: Switching to C++ by default in 4.8

[Ludovic Courtès]

Hi,

Basile Starynkevitch <basile@starynkevitch.net> skribis:

> My feeling is that the plugin ability of GCC should help academia to work more on (that
> is, "inside") GCC, to only to use GCC.

Yes, except that, on one hand, they have a library stack with stable
APIs, and on the other, an otherwise quite stable API that GCC hackers
say “should not be used” by plug-ins.

This, together with LLVM being in fashion, tends to push “academia” away
from GCC, I think.

Thanks,
Ludo’.

Re: Switching to C++ by default in 4.8

[Dave Korn]

On 11/04/2012 14:21, Bernd Schmidt wrote:
> On 04/11/2012 02:57 PM, Torvald Riegel wrote:
>> However, the concern you raised is only one part of the problem.  The
>> other is that, put in a simplified way, GCC is competing with LLVM about
>> new and/or non-fulltime-compiler developers.  For me, it looks like LLVM
>> is more appealing to them, and I believe part of the reason for that is
>> the codebase.
> 
> There seem to be other opinions as well, some voiced in this thread,
> which just supports my argument that you can't do it right for everyone.
> Part of the reason LLVM is appealing may just be advertising, which we
> don't do at all, perhaps due to the deep-seated inferiority complex we
> have about gcc.

  Inferiority complex?  I think this thread suggests (and perhaps the -Wall
thread too) that we're more in danger of complacently resting on our laurels.
 We have huge inertia, but just because we've always been the big name in
embedded toolkits doesn't mean we always will be.

    cheers,
      DaveK

Re: Switching to C++ by default in 4.8

[Jonathan Wakely]

On 11 April 2012 13:57, Torvald Riegel wrote:
> Now, how many release cycles do we have until LLVM is basically good
> enough to be used as a distro compiler (e.g., until code quality and
> confidence in bug freedom is sufficiently similar)?  If we haven't
> ensured that GCC is appealing by this time, why should new programmers
> then start considering GCC and not just go by default to LLVM?

Well it would need a C++ standard library that works on GNU/Linux
first, unless distros want to rely on a compiler+stdlib combination
that isn't supported by either the compiler vendor or the stdlib
vendor.  Not many distros have their own libstdc++ developers and
although I think it's good that libstdc++ works with clang, supporting
it is not high on my priority list.

Re: Switching to C++ by default in 4.8

[Xinliang David Li]

On Wed, Apr 11, 2012 at 5:57 AM, Torvald Riegel <triegel@redhat.com> wrote:
> On Wed, 2012-04-11 at 11:24 +0200, Richard Guenther wrote:
>> On Tue, Apr 10, 2012 at 7:29 PM, Torvald Riegel <triegel@redhat.com> wrote:
>> > Think about programmers new to GCC for a second, and about code
>> > completion tools.
>>
>> Honestly I care 1000 times more for existing GCC developers.  Before
>> new programmers will have an easier time with GCC _existing_ GCC
>> developers will have to spend at least two GCC release cycles (that's
>> very optimistic) turning the GCC codebase upside-down.  Every
>> existing GCC developer you lose on that way will slow down that
>> process and for every existing GCC developer you probably need more
>> that one "new" GCC developer starting.
>>
>> It's very easy for me to do the math and conclude that losing even _one_
>> experienced existing GCC developer makes this whole transition-to-C++
>> thing a non-starter.
>
> I agree that less work-force in the transition would be a problem.  But
> is C++ (perceived to be) so bad that it would make people change their
> jobs?  I mean, we're not talking about the experienced hobbyists here,
> or are we?
>
> However, the concern you raised is only one part of the problem.  The
> other is that, put in a simplified way, GCC is competing with LLVM about
> new and/or non-fulltime-compiler developers.  For me, it looks like LLVM
> is more appealing to them, and I believe part of the reason for that is
> the codebase.
> Now, how many release cycles do we have until LLVM is basically good
> enough to be used as a distro compiler (e.g., until code quality and
> confidence in bug freedom is sufficiently similar)?  If we haven't
> ensured that GCC is appealing by this time, why should new programmers
> then start considering GCC and not just go by default to LLVM?

Yes -- this should be the main motivation factor for GCC to make major
changes or even leapfrog -- LLVM is also more than 10 years old.

David


>
>>
>> >  It seems to me that with such a tool it's much easier
>> > to navigate from exp to the field, than having to scan through a much
>> > larger number of accessor functions / macros (GET_*).  The former
>> > example starts at the source (exp) and yields/"builds" the result; the
>> > latter names some function and then says applies it to the source.  Why
>> > is the former so much worse?  To me, the former's structure is easier to
>> > see, and if I would have to put the spaghetti tag on something, then the
>> > latter.
>>
>> Sounds more like missed features or bugs in the tools you use.  Heh,
>> after all our complaints that C++ will be harder to debug are deflected
>> to "that are gdb missing features / bugs".  So - file bugs against Eclipse
>> (or whatever new and shiny programmers use these days), that it does
>> not work well with a codebase like GCC.
>
> Please don't dismiss this so easily.  Of course this is just an example
> and nothing major, but I believe many people will use tab completion on
> the shell, for example, and code completion is really similar.  On the
> shell, or with paths names, you start with typing something, then can
> navigate from this context you provided.  That just works better when
> you say context->function instead of function(context).
> And I'm not a cognitive psychologist, but to me, seeing the context
> first when reading left-to-right is also slightly easier to read.
>

Re: Switching to C++ by default in 4.8

[Tobias Burnus]

Torvald Riegel wrote:
> On Wed, 2012-04-11 at 11:24 +0200, Richard Guenther wrote:
>> >  Honestly I care 1000 times more for existing GCC developers.  Before
>> >  new programmers will have an easier time with GCC_existing_  GCC
>> >  developers will have to spend at least two GCC release cycles (that's
>> >  very optimistic) turning the GCC codebase upside-down.  Every
>> >  existing GCC developer you lose on that way will slow down that
>> >  process and for every existing GCC developer you probably need more
>> >  that one "new" GCC developer starting.
>> >
>> >  It's very easy for me to do the math and conclude that losing even_one_
>> >  experienced existing GCC developer makes this whole transition-to-C++
>> >  thing a non-starter.
> I agree that less work-force in the transition would be a problem.  But
> is C++ (perceived to be) so bad that it would make people change their
> jobs?  I mean, we're not talking about the experienced hobbyists here,
> or are we?

I hope we are! At least GCC's Fortran front end is mostly developed by 
experienced hobbyist - and I know some who do not want to learn C++ to 
be able to continue with the project. However, I have some confidence 
that the changes will be such that no developer will give up.

In any case, the gfortran front end cannot really afford to loose 
developers, given that it is a hobbyist* project and given that 
attracting new developers is difficult.

Tobias

* In terms of the development; I assume that those who use it for 
embedded systems or on the top500 supercomputers, at aircraft 
manufactures, weather services or for academic research get paid. ;-)

Re: Switching to C++ by default in 4.8

[Torvald Riegel]

On Wed, 2012-04-11 at 21:30 +0200, Tobias Burnus wrote:
> Torvald Riegel wrote:
> > On Wed, 2012-04-11 at 11:24 +0200, Richard Guenther wrote:
> >> >  Honestly I care 1000 times more for existing GCC developers.  Before
> >> >  new programmers will have an easier time with GCC_existing_  GCC
> >> >  developers will have to spend at least two GCC release cycles (that's
> >> >  very optimistic) turning the GCC codebase upside-down.  Every
> >> >  existing GCC developer you lose on that way will slow down that
> >> >  process and for every existing GCC developer you probably need more
> >> >  that one "new" GCC developer starting.
> >> >
> >> >  It's very easy for me to do the math and conclude that losing even_one_
> >> >  experienced existing GCC developer makes this whole transition-to-C++
> >> >  thing a non-starter.
> > I agree that less work-force in the transition would be a problem.  But
> > is C++ (perceived to be) so bad that it would make people change their
> > jobs?  I mean, we're not talking about the experienced hobbyists here,
> > or are we?
> 
> I hope we are! At least GCC's Fortran front end is mostly developed by 
> experienced hobbyist - and I know some who do not want to learn C++ to 
> be able to continue with the project. However, I have some confidence 
> that the changes will be such that no developer will give up.

To avoid any misunderstandings, I'd like to stress that my comment was
explicitly a reply to Richard's comment about paid developers.  I do
think that non-full-time developers are important for the project,
that's why I raised the point of attracting new developers in the first
place.  I guess it doesn't really make a difference for our discussion
whether those developers are hobbyist, paid to work on something minor
or some project, or just experimenting with new stuff (e.g.,
researchers);  what they likely have in common is that they need to get
meaningful stuff done fast but don't have the time to master every
corner of GCC first.

In contrast, if you're working on something full-time for several years,
then yes, you'll know everything about it, including all the weird bits,
workarounds, and idioms; any change then has a cost.
But if the amount of this required information is large (e.g., the code
base is complicated, full of unexpected surprises, or just cannot be
worked on in a localized fashion), then non-full-time developers have a
hard time working with GCC;  every time they switch from their other
projects / day job / ... to working on GCC, the context switch cost is
huge.  Same applies when starting to work on GCC for the first time.

Regarding learning C++, I wouldn't worry much about this.  If you look
at the list that Lawrence Crowl sent, for example, lots of the example
benefits in there are pretty transparent if you just use them, and easy
to learn.  Perhaps some slightly more advanced C++ knowledge is required
when adding core data structures, but these will follow common patterns
too I suppose.  

Torvald

Re: Switching to C++ by default in 4.8

[Dave Korn]

On 11/04/2012 20:30, Tobias Burnus wrote:

> In any case, the gfortran front end cannot really afford to loose
> developers, given that it is a hobbyist* project and given that
> attracting new developers is difficult.
> 
> Tobias
> 
> * In terms of the development; I assume that those who use it for
> embedded systems or on the top500 supercomputers, at aircraft
> manufactures, weather services or for academic research get paid. ;-)

  ;-) Maybe you could work together to twist some arms in management?

    cheers,
      DaveK

Re: Switching to C++ by default in 4.8

[Dave Korn]

On 11/04/2012 13:57, Torvald Riegel wrote:

> Please don't dismiss this so easily.  Of course this is just an example
> and nothing major, but I believe many people will use tab completion on
> the shell, for example, and code completion is really similar.  On the
> shell, or with paths names, you start with typing something, then can
> navigate from this context you provided.  That just works better when
> you say context->function instead of function(context).


  Say, didn't someone submit a patch at some point to provide a
completion-mode for GCC invoked from the command-line?  And didn't we (the
list) suggest that that would make a lot of sense when combined with the
incremental/gccserver branch?  Did anything ever happen about that?

    cheers,
      DaveK

Re: Switching to C++ by default in 4.8

[DJ Delorie]

Michael Matz <matz@suse.de> writes:
> syntactic noise without any whitespace.  Quite frankly, how anyone could 
> ever say that
>
>   exp->as_component_ref().get_field()
>
> is easier to read/write/use than
>
>   GET_FIELD_DECL (exp)

C vs C++ is not the same argument as style A vs style B.  Your argument
could just as easily been this way:

> syntactic noise without any whitespace.  Quite frankly, how anyone could 
> ever say that
>
>   exp.get_field_decl()
>
> is easier to read/write/use than
>
>   GET_DECL (GET_FIELD (AS_COMPONENT (exp)))

The choice of language does not force you to choose a style, those are
independent choices.

Re: Switching to C++ by default in 4.8

[Dave Korn]

On 10/04/2012 17:24, Michael Matz wrote:
> Hi,
> 
> On Tue, 10 Apr 2012, Xinliang David Li wrote:
> 
>>>>>             exp->as_component_ref().get_field() ..
> 
>>> Actually it's not questionable.  The above stuff is _horrible_.
>> Specifics please.  It is _horrible_ because you are more used to the 
>> existing way and the new style does not match your taste or they are 
>> very hard to understand and use?
> 
> Your style (I wouldn't call it The New Style) is visually distracting, and 
> therefore harder to understand and use, longer to write and full of 
> syntactic noise without any whitespace.  Quite frankly, how anyone could 
> ever say that
> 
>   exp->as_component_ref().get_field()
> 
> is easier to read/write/use than
> 
>   GET_FIELD_DECL (exp)
> 
> (say when we #define GET_FIELD_DECL(x) TREE_OPERAND(x,1)), with or without 
> all-caps, is completely beyond me.  I pretty much hope that we never see 
> the ugliness of the first way in GCCs code base.  Even in C++ it's 
> possible to write non-spaghetti code.

  So isn't

#define GET_FIELD_DECL(exp) ((exp)->as_component_ref().get_field())

the simple solution to that one?

    cheers,
      DaveK

Re: Switching to C++ by default in 4.8

[Xinliang David Li]

On Tue, Apr 10, 2012 at 1:46 AM, Jakub Jelinek <jakub@redhat.com> wrote:
> On Mon, Apr 09, 2012 at 04:34:32PM -0700, Xinliang David Li wrote:
>> Class hierarchy is one such feature that is useful. Assuming we have
>> two hierarchies for gcc: one for values rooted at ValExp, and one for
>> gimple stmts rooted at GimpInst.
>>
>> 1) For IR browsing,
>>    *) all the macro accessors can be eliminated -- a big plus for debugging;
>
> Not that clear, if all the macros are replaced by tons of inline functions,
> the debugging experience can be actually significantly worse.  Already some the
> inline functions used like tree_operand_length used by TREE_OPERAND_LENGTH
> macro are extremely annoying from debugging POV.

What is the root cause of the annoyance? Mixing macros and inline
functions does not sound good, but using deeply nested macros do not
seem to help the debugging situation either.

>
>>    *) gcc implementation has lots of hard coded TREE_OPERAND (exp, nn)
>>
>>      e.g.
>>             exp->as_component_ref().get_field() ..
>>             exp->as_mem_access().get_base() ...
>>             exp->as_mem_acesss().get_address() --> produces the
>> address expression for memory access
>>             exp->as_mem_access().get_alias_handle ()
>>
>>             gimple_inst->serialize (&fixup_list) --> a virtual
>> function overriden by actual instruction types that knows its byte
>> code format.
>
> That silently assumes we want to change basic GIMPLE/tree data structures
> to virtual classes, which is a significant change that has a significant
> cost as well.  E.g. all such changed data structures grow by a virtual
> pointer field.  Those data structures are heavily optimized for memory
> footprint.

Not really -- not having flat interfaces as we have today does not
mean virtual functions have to be used -- this is just implementation
detail.

> Not to mention it is very questionable if the above stuff is more readable
> than what we currently have.

The above is just quickly cooked up examples. A carefully designed C++
based API can be self documenting and make the client code very
readable. It is hard to believe that there is no room for improvement
in GCC.

thanks,

David

>
>        Jakub

Re: Switching to C++ by default in 4.8

[Jakub Jelinek]

On Tue, Apr 10, 2012 at 09:22:56AM -0700, Xinliang David Li wrote:
> On Tue, Apr 10, 2012 at 1:46 AM, Jakub Jelinek <jakub@redhat.com> wrote:
> > On Mon, Apr 09, 2012 at 04:34:32PM -0700, Xinliang David Li wrote:
> >> Class hierarchy is one such feature that is useful. Assuming we have
> >> two hierarchies for gcc: one for values rooted at ValExp, and one for
> >> gimple stmts rooted at GimpInst.
> >>
> >> 1) For IR browsing,
> >>    *) all the macro accessors can be eliminated -- a big plus for debugging;
> >
> > Not that clear, if all the macros are replaced by tons of inline functions,
> > the debugging experience can be actually significantly worse.  Already some the
> > inline functions used like tree_operand_length used by TREE_OPERAND_LENGTH
> > macro are extremely annoying from debugging POV.
> 
> What is the root cause of the annoyance? Mixing macros and inline
> functions does not sound good, but using deeply nested macros do not
> seem to help the debugging situation either.

That when stepping through code in the debugger you keep enterring/exiting
these one liner inlines, most of them really should be at least by default
considered just as normal statements (e.g. glibc heavily uses artificial
attribute for those, still gdb doesn't hide those by default).

> > Not to mention it is very questionable if the above stuff is more readable
> > than what we currently have.
> 
> The above is just quickly cooked up examples. A carefully designed C++
> based API can be self documenting and make the client code very
> readable. It is hard to believe that there is no room for improvement
> in GCC.

Do you have examples?  E.g. I haven't touched gold, because, while it is a new
C++ codebase, looks completely unreadable to me, similarly libdw C++ stuff.
A carefully designed C based API can be self documenting and make the code
very readable as well, often more so.

	Jakub

Re: Switching to C++ by default in 4.8

[Gabriel Dos Reis]

On Tue, Apr 10, 2012 at 11:39 AM, Jakub Jelinek <jakub@redhat.com> wrote:
>> What is the root cause of the annoyance? Mixing macros and inline
>> functions does not sound good, but using deeply nested macros do not
>> seem to help the debugging situation either.
>
> That when stepping through code in the debugger you keep enterring/exiting
> these one liner inlines, most of them really should be at least by default
> considered just as normal statements (e.g. glibc heavily uses artificial
> attribute for those, still gdb doesn't hide those by default).

so, this is a good candidate for PR to fill against GDB then?  It
sounds like it would
beneficial not just to GCC but to a broader community.

-- Gaby

Re: Switching to C++ by default in 4.8

[Diego Novillo]

On 4/10/12 12:42 PM, Gabriel Dos Reis wrote:
> On Tue, Apr 10, 2012 at 11:39 AM, Jakub Jelinek<jakub@redhat.com>  wrote:
>>> What is the root cause of the annoyance? Mixing macros and inline
>>> functions does not sound good, but using deeply nested macros do not
>>> seem to help the debugging situation either.
>>
>> That when stepping through code in the debugger you keep enterring/exiting
>> these one liner inlines, most of them really should be at least by default
>> considered just as normal statements (e.g. glibc heavily uses artificial
>> attribute for those, still gdb doesn't hide those by default).
>
> so, this is a good candidate for PR to fill against GDB then?  It
> sounds like it would
> beneficial not just to GCC but to a broader community.

Yes, I think there is a bug against gdb already and, in fact, I remember 
seeing an implementation of some new gdb functionality that would help here.

Tom, I'm thinking of that patch on black listing functions.  There was 
also the idea of a command that would only step in the outermost 
function call of an expression.

My memory is hazy, but I know there is some work going on in this area.


Diego.

Re: Switching to C++ by default in 4.8

[Tom Tromey]

>>>>> "Diego" == Diego Novillo <dnovillo@google.com> writes:

Diego> Tom, I'm thinking of that patch on black listing functions.  There was
Diego> also the idea of a command that would only step in the outermost
Diego> function call of an expression.

That patch went in.  The new command is called "skip".

I don't think anybody has worked on stepping into just the outermost
function call of an expression.

Tom

Re: Switching to C++ by default in 4.8

[Diego Novillo]

On 4/12/12 3:40 PM, Tom Tromey wrote:
>>>>>> "Diego" == Diego Novillo<dnovillo@google.com>  writes:
>
> Diego>  Tom, I'm thinking of that patch on black listing functions.  There was
> Diego>  also the idea of a command that would only step in the outermost
> Diego>  function call of an expression.
>
> That patch went in.  The new command is called "skip".

Nice!  What version of gdb has this support?


> I don't think anybody has worked on stepping into just the outermost
> function call of an expression.

I think we can workaround most issues with 'skip'.


Thanks.  Diego.

Re: Switching to C++ by default in 4.8

[Tom Tromey]

>>>>> "Diego" == Diego Novillo <dnovillo@google.com> writes:

Diego> Nice!  What version of gdb has this support?

7.4.

Tom

Re: Switching to C++ by default in 4.8

[Torvald Riegel]

On Tue, 2012-04-10 at 18:39 +0200, Jakub Jelinek wrote:
> On Tue, Apr 10, 2012 at 09:22:56AM -0700, Xinliang David Li wrote:
> > > Not to mention it is very questionable if the above stuff is more readable
> > > than what we currently have.
> > 
> > The above is just quickly cooked up examples. A carefully designed C++
> > based API can be self documenting and make the client code very
> > readable. It is hard to believe that there is no room for improvement
> > in GCC.
> 
> Do you have examples?

I hate to bring this up, but in my personal experience, getting started
with LLVM was _much_ easier than with GCC.  LLVM is a much newer
codebase, so that's an advantage unrelated to the language.
Nonetheless, the grouping/context/ease-of-navigation provided by
namespaces, objects, etc. is indeed valuable in my opinion.

Torvald

Re: Switching to C++ by default in 4.8

[Miles Bader]

Torvald Riegel <triegel@redhat.com> writes:
> I hate to bring this up, but in my personal experience, getting started
> with LLVM was _much_ easier than with GCC.  LLVM is a much newer
> codebase, so that's an advantage unrelated to the language.

I dunno, I've some experience with LLVM as well, and I actually found
it rather more difficult to "get started with" than gcc...

Part of this is, of course, is that gcc has excellent internals
documentation, whereas LLVM's is almost non-existant, but LLVM's much
more "proper C++" coding style didn't seem to help a whole lot with
making it understandable (and if anything may have made it _worse_).
Gcc's code, while insanely nasty in places (reload...), generally
seems to be written in a straight-forward manner that I found fairly
easy to follow (given some persistence).

Of course C++ could help a little in slimming down gcc's code
(e.g. using constructors/destructors, etc).

-Miles

-- 
Carefully crafted initial estimates reward you not only with
reduced computational effort, but also with understanding and
increased self-esteem.         -- Numerical methods in C,
  Chapter 9. "Root Finding and Nonlinear Sets of Equations"

Re: Switching to C++ by default in 4.8

[Bernd Schmidt]

On 04/10/2012 11:39 PM, Miles Bader wrote:
> Torvald Riegel <triegel@redhat.com> writes:
>> I hate to bring this up, but in my personal experience, getting started
>> with LLVM was _much_ easier than with GCC.  LLVM is a much newer
>> codebase, so that's an advantage unrelated to the language.
> 
> I dunno, I've some experience with LLVM as well, and I actually found
> it rather more difficult to "get started with" than gcc...
> 
> Part of this is, of course, is that gcc has excellent internals
> documentation, whereas LLVM's is almost non-existant, but LLVM's much
> more "proper C++" coding style didn't seem to help a whole lot with
> making it understandable (and if anything may have made it _worse_).

My guess would be that there is no right and wrong here, it really
depends on what any given individual is familiar with. For example, I
certainly wouldn't have guessed that a GET_FIELD_DECL macro would cause
problems for autocompletion, since I personally don't use that kind of
thing.

However, what's important in a project is to pick conventions and stick
to them. For example, a lot of people initially loathe the GNU C
indentation style, but professional developers adapt themselves to
whatever style a project has chosen. There is nothing to be gained but
anarchy if personal preferences lead to churn of the "let's reindent" or
"let's rewrite in <my favourite language>" kind.

In the short term, a partial conversion to C++ gains us nothing. Even
ignoring the bugs inevitably caused by any such project, we'll end up
with a strange mish-mash of styles for a very long time, which instead
of helping anyone can only lead to confusion. I don't see anyone
committing to invest the time in converting even an entire subsystem let
alone the whole compiler. Maybe a subsystem conversion would be a good
thing to try on a branch and then present the results to the community
for evaluation. This would be better than lowering the barrier now for
all sorts of random but uncoordinated conversion efforts.


Bernd

Re: Switching to C++ by default in 4.8

[Eric Botcazou]

> In the short term, a partial conversion to C++ gains us nothing. Even
> ignoring the bugs inevitably caused by any such project, we'll end up
> with a strange mish-mash of styles for a very long time, which instead
> of helping anyone can only lead to confusion. I don't see anyone
> committing to invest the time in converting even an entire subsystem let
> alone the whole compiler. Maybe a subsystem conversion would be a good
> thing to try on a branch and then present the results to the community
> for evaluation. This would be better than lowering the barrier now for
> all sorts of random but uncoordinated conversion efforts.

IMO the killer conversion would be vec.[ch], which is a very clever piece of 
code but is almost impossible to use without copy-and-pasting existing cases.
I think that a proper C++ implementation would be a very convincing argument.

-- 
Eric Botcazou

Re: Switching to C++ by default in 4.8

[Gabriel Dos Reis]

On Tue, Apr 10, 2012 at 6:27 PM, Eric Botcazou <ebotcazou@adacore.com> wrote:
>> In the short term, a partial conversion to C++ gains us nothing. Even
>> ignoring the bugs inevitably caused by any such project, we'll end up
>> with a strange mish-mash of styles for a very long time, which instead
>> of helping anyone can only lead to confusion. I don't see anyone
>> committing to invest the time in converting even an entire subsystem let
>> alone the whole compiler. Maybe a subsystem conversion would be a good
>> thing to try on a branch and then present the results to the community
>> for evaluation. This would be better than lowering the barrier now for
>> all sorts of random but uncoordinated conversion efforts.
>
> IMO the killer conversion would be vec.[ch], which is a very clever piece of
> code but is almost impossible to use without copy-and-pasting existing cases.
> I think that a proper C++ implementation would be a very convincing argument.

when you say that, do you mean you would prefer and expect:
  1. native C++ style, or
  2. you would like the C-style round-about and paraphrasing to remain
unperturbed
?

The reason I ask is that I expect a "proper" C++ implementation would come
with a C++-native style of usage.

-- Gaby

Re: Switching to C++ by default in 4.8

[Eric Botcazou]

> when you say that, do you mean you would prefer and expect:
>   1. native C++ style, or
>   2. you would like the C-style round-about and paraphrasing to remain
> unperturbed
> ?
>
> The reason I ask is that I expect a "proper" C++ implementation would come
> with a C++-native style of usage.

I don't think that implementing vec.[ch] in C++ would necessarily entail that 
big a change of style; adding 1 -> per line is OK, adding 3 is something else.

-- 
Eric Botcazou

Re: Switching to C++ by default in 4.8

[Gabriel Dos Reis]

On Wed, Apr 11, 2012 at 2:42 AM, Eric Botcazou <ebotcazou@adacore.com> wrote:
>> when you say that, do you mean you would prefer and expect:
>>   1. native C++ style, or
>>   2. you would like the C-style round-about and paraphrasing to remain
>> unperturbed
>> ?
>>
>> The reason I ask is that I expect a "proper" C++ implementation would come
>> with a C++-native style of usage.
>
> I don't think that implementing vec.[ch] in C++ would necessarily entail that
> big a change of style; adding 1 -> per line is OK, adding 3 is something else.

Expressing an idea in C takes me more lines (roughly 2-3 fold) than
in C++, so I am a bit puzzled by your observation.

-- Gaby

Re: Switching to C++ by default in 4.8

[Eric Botcazou]

> Expressing an idea in C takes me more lines (roughly 2-3 fold) than
> in C++, so I am a bit puzzled by your observation.

We're specifically discussing vec.[ch] here, which is a clever attempt at 
implementing vectors in C, with macro magic all over the place.

-- 
Eric Botcazou

Re: Switching to C++ by default in 4.8

[Jeff Law]

On 04/11/2012 02:10 AM, Eric Botcazou wrote:
>> Expressing an idea in C takes me more lines (roughly 2-3 fold) than
>> in C++, so I am a bit puzzled by your observation.
>
> We're specifically discussing vec.[ch] here, which is a clever attempt at
> implementing vectors in C, with macro magic all over the place.
>
So can someone convert vec.[ch] on a branch so that we can see exactly 
what the cost/benefits are for situation that most believe is the most 
compelling for switching?

If that's successful, then propose and convert second hunk on that same 
branch to show that the benefits aren't isolated to vec.[ch].

I tend to think there's benefit to moving to a subset of C++, but I have 
some of the concerns raised by Jakub and others.  Being able to see 
firsthand how the code changes from a readability standpoint, how the 
changes affect compilation speed, bootstrap times, debugability, etc 
would be a big step towards relieving some of those concerns.

Jeff

Re: Switching to C++ by default in 4.8

[Jakub Jelinek]

On Wed, Apr 11, 2012 at 01:27:29AM +0200, Eric Botcazou wrote:
> > In the short term, a partial conversion to C++ gains us nothing. Even
> > ignoring the bugs inevitably caused by any such project, we'll end up
> > with a strange mish-mash of styles for a very long time, which instead
> > of helping anyone can only lead to confusion. I don't see anyone
> > committing to invest the time in converting even an entire subsystem let
> > alone the whole compiler. Maybe a subsystem conversion would be a good
> > thing to try on a branch and then present the results to the community
> > for evaluation. This would be better than lowering the barrier now for
> > all sorts of random but uncoordinated conversion efforts.
> 
> IMO the killer conversion would be vec.[ch], which is a very clever piece of 
> code but is almost impossible to use without copy-and-pasting existing cases.
> I think that a proper C++ implementation would be a very convincing argument.

But IMHO not sufficient for a switch.  The GCC C++ proponents should do more
on a branch to convince.  Yes, the syntactic suger for vec.h isn't very
nice, but the actual implementation is very clever and heavily tuned for
GCC's needs; if we convert to C++ just because of vec.[ch], we open
ourselves to what is being discussed in this thread, people who would like
to turn GCC codebase into yet another LLVM, which not everybody finds
actually very readable and maintainable code, would start doing so.

	Jakub

Re: Switching to C++ by default in 4.8

[Gabriel Dos Reis]

On Wed, Apr 11, 2012 at 2:01 AM, Jakub Jelinek <jakub@redhat.com> wrote:
> On Wed, Apr 11, 2012 at 01:27:29AM +0200, Eric Botcazou wrote:
>> > In the short term, a partial conversion to C++ gains us nothing. Even
>> > ignoring the bugs inevitably caused by any such project, we'll end up
>> > with a strange mish-mash of styles for a very long time, which instead
>> > of helping anyone can only lead to confusion. I don't see anyone
>> > committing to invest the time in converting even an entire subsystem let
>> > alone the whole compiler. Maybe a subsystem conversion would be a good
>> > thing to try on a branch and then present the results to the community
>> > for evaluation. This would be better than lowering the barrier now for
>> > all sorts of random but uncoordinated conversion efforts.
>>
>> IMO the killer conversion would be vec.[ch], which is a very clever piece of
>> code but is almost impossible to use without copy-and-pasting existing cases.
>> I think that a proper C++ implementation would be a very convincing argument.
>
> But IMHO not sufficient for a switch.  The GCC C++ proponents should do more
> on a branch to convince.  Yes, the syntactic suger for vec.h isn't very
> nice, but the actual implementation is very clever and heavily tuned for
> GCC's needs; if we convert to C++ just because of vec.[ch], we open
> ourselves to what is being discussed in this thread, people who would like
> to turn GCC codebase into yet another LLVM, which not everybody finds
> actually very readable and maintainable code, would start doing so.

I have been having difficulty following the twists and the turns and
the goal post moving.
Are you essentially requiring to see GCC rewritten in C++ before we
switch to C++?

-- Gaby

Re: Switching to C++ by default in 4.8

[Jakub Jelinek]

On Wed, Apr 11, 2012 at 02:45:55AM -0500, Gabriel Dos Reis wrote:
> On Wed, Apr 11, 2012 at 2:01 AM, Jakub Jelinek <jakub@redhat.com> wrote:
> > On Wed, Apr 11, 2012 at 01:27:29AM +0200, Eric Botcazou wrote:
> >> > In the short term, a partial conversion to C++ gains us nothing. Even
> >> > ignoring the bugs inevitably caused by any such project, we'll end up
> >> > with a strange mish-mash of styles for a very long time, which instead
> >> > of helping anyone can only lead to confusion. I don't see anyone
> >> > committing to invest the time in converting even an entire subsystem let
> >> > alone the whole compiler. Maybe a subsystem conversion would be a good
> >> > thing to try on a branch and then present the results to the community
> >> > for evaluation. This would be better than lowering the barrier now for
> >> > all sorts of random but uncoordinated conversion efforts.
> >>
> >> IMO the killer conversion would be vec.[ch], which is a very clever piece of
> >> code but is almost impossible to use without copy-and-pasting existing cases.
> >> I think that a proper C++ implementation would be a very convincing argument.
> >
> > But IMHO not sufficient for a switch.  The GCC C++ proponents should do more
> > on a branch to convince.  Yes, the syntactic suger for vec.h isn't very
> > nice, but the actual implementation is very clever and heavily tuned for
> > GCC's needs; if we convert to C++ just because of vec.[ch], we open
> > ourselves to what is being discussed in this thread, people who would like
> > to turn GCC codebase into yet another LLVM, which not everybody finds
> > actually very readable and maintainable code, would start doing so.
> 
> I have been having difficulty following the twists and the turns and
> the goal post moving.
> Are you essentially requiring to see GCC rewritten in C++ before we
> switch to C++?

No, but I'd like to see more than just vec.[ch] conversion alone and see what
benefits it actually brings to GCC if any with real numbers of what it means
to compile time, compilation memory usage, etc.

	Jakub

Re: Switching to C++ by default in 4.8

[Bernd Schmidt]

On 04/11/2012 09:45 AM, Gabriel Dos Reis wrote:
> I have been having difficulty following the twists and the turns and
> the goal post moving.
> Are you essentially requiring to see GCC rewritten in C++ before we
> switch to C++?

Frankly, despite all this discussion, we still don't really know what
the people who insist on a C++ conversion actually want to do. We've
seen trivial suggestions like rewriting vec.[ch], which isn't really
going to make a big difference in the grand scheme of things, but
everything else has remained vague. At the GCC gathering last year we
saw a presentation which made me feel like language features had just
gone in search of possible applications, which doesn't fill me with a
lot of confidence either.

So yes, I would like some significant part rewritten in the way the C++
folks would like to see it, so we can actually judge what we will get.
And that's moving my personal goal post from "hell no" somewhere closer
to what the C++ proponents would like.

The incremental approach (tearing down the barrier of stage1 being
compiled in C first and then getting things in piecewise) may seem like
a path of less resistance, but we can't afford to have a thread like
this for every change, and I wouldn't like to see us decide after 100
patches that the end result sucks and we have to either live with it or
revert the lot.

IMO, gimple might be worth trying to convert, since it's the newest code
in gcc and presumably already half-way to what people consider a
"modern" style (lots of annoying little functions that get in the way
while debugging).

But I suspect that when such a branch has been done, it will still come
down to personal preference as to which variant is best. This is why I
still think the whole thing is deeply misguided, as it's not about
objective technical issues, but merely about language preferences, and
everyone has a different one. You can't match everyone's taste in a big
project, and thus real developers have to adapt to a project, not the
other way round. Discussions like this are a toxic distraction from real
work.

IMO it would be best if we could find a majority of global reviewers to
speak out and say once and for all "no, this just isn't happening", so
we can drop all this nonsense and get back to improving the compiler for
users. The second best thing would be to have a branch with actual work
done for us to consider.


Bernd

Re: Switching to C++ by default in 4.8

[Richard Guenther]

On Wed, Apr 11, 2012 at 2:34 PM, Bernd Schmidt <bernds@codesourcery.com> wrote:
> On 04/11/2012 09:45 AM, Gabriel Dos Reis wrote:
>> I have been having difficulty following the twists and the turns and
>> the goal post moving.
>> Are you essentially requiring to see GCC rewritten in C++ before we
>> switch to C++?
>
> Frankly, despite all this discussion, we still don't really know what
> the people who insist on a C++ conversion actually want to do. We've
> seen trivial suggestions like rewriting vec.[ch], which isn't really
> going to make a big difference in the grand scheme of things, but
> everything else has remained vague. At the GCC gathering last year we
> saw a presentation which made me feel like language features had just
> gone in search of possible applications, which doesn't fill me with a
> lot of confidence either.
>
> So yes, I would like some significant part rewritten in the way the C++
> folks would like to see it, so we can actually judge what we will get.
> And that's moving my personal goal post from "hell no" somewhere closer
> to what the C++ proponents would like.
>
> The incremental approach (tearing down the barrier of stage1 being
> compiled in C first and then getting things in piecewise) may seem like
> a path of less resistance, but we can't afford to have a thread like
> this for every change, and I wouldn't like to see us decide after 100
> patches that the end result sucks and we have to either live with it or
> revert the lot.
>
> IMO, gimple might be worth trying to convert, since it's the newest code
> in gcc and presumably already half-way to what people consider a
> "modern" style (lots of annoying little functions that get in the way
> while debugging).
>
> But I suspect that when such a branch has been done, it will still come
> down to personal preference as to which variant is best. This is why I
> still think the whole thing is deeply misguided, as it's not about
> objective technical issues, but merely about language preferences, and
> everyone has a different one. You can't match everyone's taste in a big
> project, and thus real developers have to adapt to a project, not the
> other way round. Discussions like this are a toxic distraction from real
> work.
>
> IMO it would be best if we could find a majority of global reviewers to
> speak out and say once and for all "no, this just isn't happening", so
> we can drop all this nonsense and get back to improving the compiler for
> users. The second best thing would be to have a branch with actual work
> done for us to consider.

Frankly I'd say the second best thing is the first best thing.  Show us the
code!  Then we decide.  It does not work the other way around.

Richard.

Re: Switching to C++ by default in 4.8

[Xinliang David Li]

On Wed, Apr 11, 2012 at 5:47 AM, Richard Guenther
<richard.guenther@gmail.com> wrote:
> On Wed, Apr 11, 2012 at 2:34 PM, Bernd Schmidt <bernds@codesourcery.com> wrote:
>> On 04/11/2012 09:45 AM, Gabriel Dos Reis wrote:
>>> I have been having difficulty following the twists and the turns and
>>> the goal post moving.
>>> Are you essentially requiring to see GCC rewritten in C++ before we
>>> switch to C++?
>>
>> Frankly, despite all this discussion, we still don't really know what
>> the people who insist on a C++ conversion actually want to do. We've
>> seen trivial suggestions like rewriting vec.[ch], which isn't really
>> going to make a big difference in the grand scheme of things, but
>> everything else has remained vague. At the GCC gathering last year we
>> saw a presentation which made me feel like language features had just
>> gone in search of possible applications, which doesn't fill me with a
>> lot of confidence either.
>>
>> So yes, I would like some significant part rewritten in the way the C++
>> folks would like to see it, so we can actually judge what we will get.
>> And that's moving my personal goal post from "hell no" somewhere closer
>> to what the C++ proponents would like.
>>
>> The incremental approach (tearing down the barrier of stage1 being
>> compiled in C first and then getting things in piecewise) may seem like
>> a path of less resistance, but we can't afford to have a thread like
>> this for every change, and I wouldn't like to see us decide after 100
>> patches that the end result sucks and we have to either live with it or
>> revert the lot.
>>
>> IMO, gimple might be worth trying to convert, since it's the newest code
>> in gcc and presumably already half-way to what people consider a
>> "modern" style (lots of annoying little functions that get in the way
>> while debugging).
>>
>> But I suspect that when such a branch has been done, it will still come
>> down to personal preference as to which variant is best. This is why I
>> still think the whole thing is deeply misguided, as it's not about
>> objective technical issues, but merely about language preferences, and
>> everyone has a different one. You can't match everyone's taste in a big
>> project, and thus real developers have to adapt to a project, not the
>> other way round. Discussions like this are a toxic distraction from real
>> work.
>>
>> IMO it would be best if we could find a majority of global reviewers to
>> speak out and say once and for all "no, this just isn't happening", so
>> we can drop all this nonsense and get back to improving the compiler for
>> users. The second best thing would be to have a branch with actual work
>> done for us to consider.
>
> Frankly I'd say the second best thing is the first best thing.  Show us the
> code!  Then we decide.  It does not work the other way around.
>

That may not be always the best strategy to move forward. Some level
of discussions and agreement can be reached I think.

thanks,

David


> Richard.

Re: Switching to C++ by default in 4.8

[Gabriel Dos Reis]

On Wed, Apr 11, 2012 at 7:34 AM, Bernd Schmidt <bernds@codesourcery.com> wrote:
> On 04/11/2012 09:45 AM, Gabriel Dos Reis wrote:
>> I have been having difficulty following the twists and the turns and
>> the goal post moving.
>> Are you essentially requiring to see GCC rewritten in C++ before we
>> switch to C++?
>
> Frankly, despite all this discussion, we still don't really know what
> the people who insist on a C++ conversion actually want to do. We've
> seen trivial suggestions like rewriting vec.[ch], which isn't really
> going to make a big difference in the grand scheme of things, but
> everything else has remained vague. At the GCC gathering last year we
> saw a presentation which made me feel like language features had just
> gone in search of possible applications, which doesn't fill me with a
> lot of confidence either.
>
> So yes, I would like some significant part rewritten in the way the C++
> folks would like to see it, so we can actually judge what we will get.
> And that's moving my personal goal post from "hell no" somewhere closer
> to what the C++ proponents would like.
>
> The incremental approach (tearing down the barrier of stage1 being
> compiled in C first and then getting things in piecewise) may seem like
> a path of less resistance, but we can't afford to have a thread like
> this for every change, and I wouldn't like to see us decide after 100
> patches that the end result sucks and we have to either live with it or
> revert the lot.
>
> IMO, gimple might be worth trying to convert, since it's the newest code
> in gcc and presumably already half-way to what people consider a
> "modern" style (lots of annoying little functions that get in the way
> while debugging).
>
> But I suspect that when such a branch has been done, it will still come
> down to personal preference as to which variant is best. This is why I
> still think the whole thing is deeply misguided, as it's not about
> objective technical issues, but merely about language preferences, and
> everyone has a different one. You can't match everyone's taste in a big
> project, and thus real developers have to adapt to a project, not the
> other way round. Discussions like this are a toxic distraction from real
> work.
>
> IMO it would be best if we could find a majority of global reviewers to
> speak out and say once and for all "no, this just isn't happening", so
> we can drop all this nonsense and get back to improving the compiler for
> users. The second best thing would be to have a branch with actual work
> done for us to consider.

The reason why I am mystified is that the people who seem to argue
that it would be pointless to convert the existing codebase to C++ seem
to be the same people who insist on seeing significant part of GCC
converted to C++ before we switch to *building* stage1 with a C++ compiler.

-- Gaby

Re: Switching to C++ by default in 4.8

[Jakub Jelinek]

On Wed, Apr 11, 2012 at 08:20:05AM -0500, Gabriel Dos Reis wrote:
> The reason why I am mystified is that the people who seem to argue
> that it would be pointless to convert the existing codebase to C++ seem
> to be the same people who insist on seeing significant part of GCC
> converted to C++ before we switch to *building* stage1 with a C++ compiler.

What is so puzzling about it?  If we don't have a proof that what the GCC in
C++ proponents are wanting is actually beneficial for GCC, then just
switching building stage1 to C++ is not a step in the right direction,
it removes options from those that build GCC or at least makes building
GCC unnecessarily bigger hassle.
If the switch followed by several conversions to C++ is done on a branch
only and the merits are then judged afterwards, we don't do the problematic
step on the trunk until it actually gives some benefits (if ever).

	Jakub

Re: Switching to C++ by default in 4.8

[Gabriel Dos Reis]

On Wed, Apr 11, 2012 at 8:28 AM, Jakub Jelinek <jakub@redhat.com> wrote:
> On Wed, Apr 11, 2012 at 08:20:05AM -0500, Gabriel Dos Reis wrote:
>> The reason why I am mystified is that the people who seem to argue
>> that it would be pointless to convert the existing codebase to C++ seem
>> to be the same people who insist on seeing significant part of GCC
>> converted to C++ before we switch to *building* stage1 with a C++ compiler.
>
> What is so puzzling about it?

what is puzzling is that if people believe it is pointless to convert
the existing
codebase to C++, why are they insisting to see that happen before
*building* stage1 with a C++ compiler?

> If we don't have a proof that what the GCC in
> C++ proponents are wanting is actually beneficial for GCC, then just
> switching building stage1 to C++ is not a step in the right direction,

There is a distinction between converting existing codebase to C++
(which some people think is pointless) and making it possible to add
*new functionalities* written in C++.

> it removes options from those that build GCC or at least makes building
> GCC unnecessarily bigger hassle.

If that is your real point, how requiring people to rewrite GCC in C++
before the switch to *build* statge1 with a C++ compiler is going to
fix that or address that?

> If the switch followed by several conversions to C++ is done on a branch
> only and the merits are then judged afterwards, we don't do the problematic
> step on the trunk until it actually gives some benefits (if ever).

But the primary goal isn't to convert GCC to C++, but to allow new
functionalities
to be written in C++.

-- Gaby

Re: Switching to C++ by default in 4.8

[David Edelsohn]

On Wed, Apr 11, 2012 at 9:28 AM, Jakub Jelinek <jakub@redhat.com> wrote:
> On Wed, Apr 11, 2012 at 08:20:05AM -0500, Gabriel Dos Reis wrote:
>> The reason why I am mystified is that the people who seem to argue
>> that it would be pointless to convert the existing codebase to C++ seem
>> to be the same people who insist on seeing significant part of GCC
>> converted to C++ before we switch to *building* stage1 with a C++ compiler.
>
> What is so puzzling about it?  If we don't have a proof that what the GCC in
> C++ proponents are wanting is actually beneficial for GCC, then just
> switching building stage1 to C++ is not a step in the right direction,
> it removes options from those that build GCC or at least makes building
> GCC unnecessarily bigger hassle.
> If the switch followed by several conversions to C++ is done on a branch
> only and the merits are then judged afterwards, we don't do the problematic
> step on the trunk until it actually gives some benefits (if ever).

Part of the reason this discussion is not reaching a consensus is
because it is not addressing the real issue.  The challenge is how to
make GCC an attractive platform for developers -- how to attract new
developers.

Among FOSS compilers, LLVM attracts developers.  Other than licensing
and politics and marketing, the anecdotal comments from developers
mention C++ as a technical reason.

And other than existing GCC developers who are comfortable with the
current C codebase, I think some participants in this thread are
concerned that the C++ complaint is a red herring.  In other words,
some developers resist GCC because it does not match their comfort
zone and when asked for a technical reason, C++ is an easy answer.  I
think some members of the GCC community have a nagging concern that
even if GCC goes through the pain of transitioning to C++, it will not
move the ball on attracting developers, but will divert resources and
will discourage existing developers.

We can experiment with C++ for style and debugging and optimization.
But, fundamentally, we cannot perform the real experiment which is:
Will transitioning GCC to G++ attract more developers to GCC.

- David

Re: Switching to C++ by default in 4.8

[Xinliang David Li]

On Wed, Apr 11, 2012 at 7:44 AM, David Edelsohn <dje.gcc@gmail.com> wrote:
> On Wed, Apr 11, 2012 at 9:28 AM, Jakub Jelinek <jakub@redhat.com> wrote:
>> On Wed, Apr 11, 2012 at 08:20:05AM -0500, Gabriel Dos Reis wrote:
>>> The reason why I am mystified is that the people who seem to argue
>>> that it would be pointless to convert the existing codebase to C++ seem
>>> to be the same people who insist on seeing significant part of GCC
>>> converted to C++ before we switch to *building* stage1 with a C++ compiler.
>>
>> What is so puzzling about it?  If we don't have a proof that what the GCC in
>> C++ proponents are wanting is actually beneficial for GCC, then just
>> switching building stage1 to C++ is not a step in the right direction,
>> it removes options from those that build GCC or at least makes building
>> GCC unnecessarily bigger hassle.
>> If the switch followed by several conversions to C++ is done on a branch
>> only and the merits are then judged afterwards, we don't do the problematic
>> step on the trunk until it actually gives some benefits (if ever).
>
> Part of the reason this discussion is not reaching a consensus is
> because it is not addressing the real issue.  The challenge is how to
> make GCC an attractive platform for developers -- how to attract new
> developers.
>
> Among FOSS compilers, LLVM attracts developers.  Other than licensing
> and politics and marketing, the anecdotal comments from developers
> mention C++ as a technical reason.
>
> And other than existing GCC developers who are comfortable with the
> current C codebase, I think some participants in this thread are
> concerned that the C++ complaint is a red herring.  In other words,
> some developers resist GCC because it does not match their comfort
> zone and when asked for a technical reason, C++ is an easy answer.  I
> think some members of the GCC community have a nagging concern that
> even if GCC goes through the pain of transitioning to C++, it will not
> move the ball on attracting developers, but will divert resources and
> will discourage existing developers.

On the other hand, it may also attract additional resources to help
out. Not changing anything is certainly not going to help here.

thanks,

David

Re: Switching to C++ by default in 4.8

[Xinliang David Li]

Mostly agreed. In particular, the discussions should be more concrete
-- instead of voting on moving everything to C++ which can create a
huge chaos, we should first carefully partition the components that
are candidates for the migration (as mentioned by Richard). For
instance,

1) core APIs
   a) tree based
   b) GIMPLE
   c) RTL

2) Call Graph component

3) Utility (vec, hash etc)

4) IR streamer and reader

5) IR text dumper

6) optimization driver and pass manager

7) Alias manager

8) Loop managers etc

9) Global Symbol table (do we even have one other than varpool ?)

10) Type table (non existing)

11) Local symbol table (almost non existing)

12) Bitwise data flow framework

13) target model

14) ...

and

*) CPP and parser (should I mention Clang? :) )

The direction for each component can be voted and the migration plan
and roadmaps can also be determined before hand.

For C++ifying any component, the owner/driver needs to come up with
detailed proposal first. There should also be some new style
guidelines. For instance, when migrating to STL container classes,
should they be used in 'raw' form, or some kind of GCC style wrapper
classes are defined, etc.

thanks,

David



On Wed, Apr 11, 2012 at 5:34 AM, Bernd Schmidt <bernds@codesourcery.com> wrote:
> On 04/11/2012 09:45 AM, Gabriel Dos Reis wrote:
>> I have been having difficulty following the twists and the turns and
>> the goal post moving.
>> Are you essentially requiring to see GCC rewritten in C++ before we
>> switch to C++?
>
> Frankly, despite all this discussion, we still don't really know what
> the people who insist on a C++ conversion actually want to do. We've
> seen trivial suggestions like rewriting vec.[ch], which isn't really
> going to make a big difference in the grand scheme of things, but
> everything else has remained vague. At the GCC gathering last year we
> saw a presentation which made me feel like language features had just
> gone in search of possible applications, which doesn't fill me with a
> lot of confidence either.
>
> So yes, I would like some significant part rewritten in the way the C++
> folks would like to see it, so we can actually judge what we will get.
> And that's moving my personal goal post from "hell no" somewhere closer
> to what the C++ proponents would like.
>
> The incremental approach (tearing down the barrier of stage1 being
> compiled in C first and then getting things in piecewise) may seem like
> a path of less resistance, but we can't afford to have a thread like
> this for every change, and I wouldn't like to see us decide after 100
> patches that the end result sucks and we have to either live with it or
> revert the lot.
>
> IMO, gimple might be worth trying to convert, since it's the newest code
> in gcc and presumably already half-way to what people consider a
> "modern" style (lots of annoying little functions that get in the way
> while debugging).
>
> But I suspect that when such a branch has been done, it will still come
> down to personal preference as to which variant is best. This is why I
> still think the whole thing is deeply misguided, as it's not about
> objective technical issues, but merely about language preferences, and
> everyone has a different one. You can't match everyone's taste in a big
> project, and thus real developers have to adapt to a project, not the
> other way round. Discussions like this are a toxic distraction from real
> work.
>
> IMO it would be best if we could find a majority of global reviewers to
> speak out and say once and for all "no, this just isn't happening", so
> we can drop all this nonsense and get back to improving the compiler for
> users. The second best thing would be to have a branch with actual work
> done for us to consider.
>
>
> Bernd

Re: Switching to C++ by default in 4.8

[Eric Botcazou]

> But IMHO not sufficient for a switch.  The GCC C++ proponents should do
> more on a branch to convince.  Yes, the syntactic suger for vec.h isn't
> very nice, but the actual implementation is very clever and heavily tuned
> for GCC's needs; if we convert to C++ just because of vec.[ch], we open
> ourselves to what is being discussed in this thread, people who would like
> to turn GCC codebase into yet another LLVM, which not everybody finds
> actually very readable and maintainable code, would start doing so.

Maybe, but if we don't convert vec.[ch], there is no point in using C++ at all.
We could put in place a strict containment policy: no one is allowed to write 
non-C code for modules that haven't been explicitly approved.  Conversions on 
a module level are done on a branch and merged into mainline as a whole.  And 
state prominently that there is no long term goal towards a complete rewrite 
of the compiler in full-blown C++, so that people don't waste time making big 
plans for such a rewrite.

-- 
Eric Botcazou

Re: Switching to C++ by default in 4.8

[Richard Guenther]

On Wed, Apr 11, 2012 at 10:06 AM, Eric Botcazou <ebotcazou@adacore.com> wrote:
>> But IMHO not sufficient for a switch.  The GCC C++ proponents should do
>> more on a branch to convince.  Yes, the syntactic suger for vec.h isn't
>> very nice, but the actual implementation is very clever and heavily tuned
>> for GCC's needs; if we convert to C++ just because of vec.[ch], we open
>> ourselves to what is being discussed in this thread, people who would like
>> to turn GCC codebase into yet another LLVM, which not everybody finds
>> actually very readable and maintainable code, would start doing so.
>
> Maybe, but if we don't convert vec.[ch], there is no point in using C++ at all.

Definitely agreed.

> We could put in place a strict containment policy: no one is allowed to write
> non-C code for modules that haven't been explicitly approved.  Conversions on
> a module level are done on a branch and merged into mainline as a whole.  And
> state prominently that there is no long term goal towards a complete rewrite
> of the compiler in full-blown C++, so that people don't waste time making big
> plans for such a rewrite.

That's why we use C for building stage1 ;)  And we should continue to do so
until a sufficient part of GCC uses C++ in a way people agree to (thus, people,
please start a branch).

Richard.

> --
> Eric Botcazou

Re: Switching to C++ by default in 4.8

[Xinliang David Li]

On Tue, Apr 10, 2012 at 9:39 AM, Jakub Jelinek <jakub@redhat.com> wrote:
> On Tue, Apr 10, 2012 at 09:22:56AM -0700, Xinliang David Li wrote:
>> On Tue, Apr 10, 2012 at 1:46 AM, Jakub Jelinek <jakub@redhat.com> wrote:
>> > On Mon, Apr 09, 2012 at 04:34:32PM -0700, Xinliang David Li wrote:
>> >> Class hierarchy is one such feature that is useful. Assuming we have
>> >> two hierarchies for gcc: one for values rooted at ValExp, and one for
>> >> gimple stmts rooted at GimpInst.
>> >>
>> >> 1) For IR browsing,
>> >>    *) all the macro accessors can be eliminated -- a big plus for debugging;
>> >
>> > Not that clear, if all the macros are replaced by tons of inline functions,
>> > the debugging experience can be actually significantly worse.  Already some the
>> > inline functions used like tree_operand_length used by TREE_OPERAND_LENGTH
>> > macro are extremely annoying from debugging POV.
>>
>> What is the root cause of the annoyance? Mixing macros and inline
>> functions does not sound good, but using deeply nested macros do not
>> seem to help the debugging situation either.
>
> That when stepping through code in the debugger you keep enterring/exiting
> these one liner inlines, most of them really should be at least by default
> considered just as normal statements (e.g. glibc heavily uses artificial
> attribute for those, still gdb doesn't hide those by default).
>
>> > Not to mention it is very questionable if the above stuff is more readable
>> > than what we currently have.
>>
>> The above is just quickly cooked up examples. A carefully designed C++
>> based API can be self documenting and make the client code very
>> readable. It is hard to believe that there is no room for improvement
>> in GCC.
>
> Do you have examples?  E.g. I haven't touched gold, because, while it is a new
> C++ codebase, looks completely unreadable to me, similarly libdw C++ stuff.
> A carefully designed C based API can be self documenting and make the code
> very readable as well, often more so.

Personally I think the core APIs should be abstract enough to hide IR
details, and high level (possibly multi-level) to allow efficient code
manipulation -- be it C or C++. However I think this is really more
about the general perceptions and how future developers feel about it.

thanks,

David

>
>        Jakub

Re: Switching to C++ by default in 4.8

[Marek Polacek]

On Tue, Apr 10, 2012 at 10:54:01AM -0700, Xinliang David Li wrote:
> manipulation -- be it C or C++. However I think this is really more
> about the general perceptions and how future developers feel about it.

If GCC would ever be in C++, that would be a very strong argument for
me _not_ to touch it.

	Marek

Re: Switching to C++ by default in 4.8

[Xinliang David Li]

On Wed, Apr 11, 2012 at 5:43 AM, Marek Polacek <polacek@redhat.com> wrote:
> On Tue, Apr 10, 2012 at 10:54:01AM -0700, Xinliang David Li wrote:
>> manipulation -- be it C or C++. However I think this is really more
>> about the general perceptions and how future developers feel about it.
>
> If GCC would ever be in C++, that would be a very strong argument for
> me _not_ to touch it.
>

haha -- I guess a survey in gcc@ would help here :)

David

>        Marek

Re: Switching to C++ by default in 4.8

[Lawrence Crowl]

On 4/10/12, Jakub Jelinek <jakub@redhat.com> wrote:
> That when stepping through code in the debugger you keep
> enterring/exiting these one liner inlines, most of them really
> should be at least by default considered just as normal statements
> (e.g. glibc heavily uses artificial attribute for those, still
> gdb doesn't hide those by default).

You do want to step into those inline functions, except when you do.
In the short term, we can make the debugger behave as though they did
not exist.  In the longer term, we really want debugging tools that
help C++ programmers.  One way to get there is to use C++ ourselves.

> > The above is just quickly cooked up examples. A carefully
> > designed C++ based API can be self documenting and make the
> > client code very readable. It is hard to believe that there is
> > no room for improvement in GCC.
>
> Do you have examples?  E.g. I haven't touched gold, because,
> while it is a new C++ codebase, looks completely unreadable to
> me, similarly libdw C++ stuff.  A carefully designed C based API
> can be self documenting and make the code very readable as well,
> often more so.

If you just look at any decently sized code base, it'll look pretty
much unreadable.  The question is how quickly can someone who learns
the base vocabulary can produce reasonable modifications.

There are many places where C++ can help substantially.  For example:

() The C++ postfix member function call syntax means that following
a chain of attributes is a linear read of the expression.  With C
function call syntax, you need to read the expression inside out.

() C++ has both overloaded functions and member functions, so you can
use the same verb to talk about several different kinds of objects.
With C function names, we have to invent a new function name for
each type.  Such names are longer and burden both the author and
the reader of the code.

() Standard C++ idioms enable mashing program components with ease.
The C++ standard library is based on mixing and matching algorithms
and data structures, via the common idiom of iterators.

() The overloadable operator new means that memory can be
_implicitly_ allocated in the right place.

() Constructors and destructors reduce the number of places in the
code where you need to do explicit memory management. Without garbage
collection, leaks are less frequent.  With garbage collection, you
have much less active garbage, and can run longer between collection
runs.  Indeed, a conservative collector would be sufficient.

() Constructors and destructors also neatly handle actions that
must occur in pairs.  The classic example is mutex lock and unlock.
Within GCC, timevar operations need to happen in pairs.

() Class hierarchies (even without virtual functions) can directly
represent type relationships, which means that a debugger dump of
a C++ type has little unnecessary information, as opposed to the
present union of structs approach with GCC trees.

() Class hierarchies also mean that programmers can distinguish
in the pointer types that a function needs a decl parameter,
without having to say 'all trees' versus 'a very specific tree'.
The static type checking avoids run-time bugs.

I have written compilers in both C and C++.  I much prefer the
latter.

-- 
Lawrence Crowl

Re: Switching to C++ by default in 4.8

[Richard Guenther]

On Wed, Apr 11, 2012 at 4:24 AM, Lawrence Crowl <crowl@google.com> wrote:
> On 4/10/12, Jakub Jelinek <jakub@redhat.com> wrote:
>> That when stepping through code in the debugger you keep
>> enterring/exiting these one liner inlines, most of them really
>> should be at least by default considered just as normal statements
>> (e.g. glibc heavily uses artificial attribute for those, still
>> gdb doesn't hide those by default).
>
> You do want to step into those inline functions, except when you do.
> In the short term, we can make the debugger behave as though they did
> not exist.  In the longer term, we really want debugging tools that
> help C++ programmers.  One way to get there is to use C++ ourselves.

Fix the debugger first please.

>> > The above is just quickly cooked up examples. A carefully
>> > designed C++ based API can be self documenting and make the
>> > client code very readable. It is hard to believe that there is
>> > no room for improvement in GCC.
>>
>> Do you have examples?  E.g. I haven't touched gold, because,
>> while it is a new C++ codebase, looks completely unreadable to
>> me, similarly libdw C++ stuff.  A carefully designed C based API
>> can be self documenting and make the code very readable as well,
>> often more so.
>
> If you just look at any decently sized code base, it'll look pretty
> much unreadable.  The question is how quickly can someone who learns
> the base vocabulary can produce reasonable modifications.
>
> There are many places where C++ can help substantially.  For example:
>
> () The C++ postfix member function call syntax means that following
> a chain of attributes is a linear read of the expression.  With C
> function call syntax, you need to read the expression inside out.

It's a matter of what you are used to (consider LISP).

> () C++ has both overloaded functions and member functions, so you can
> use the same verb to talk about several different kinds of objects.
> With C function names, we have to invent a new function name for
> each type.  Such names are longer and burden both the author and
> the reader of the code.

Agreed.  Function overloading is one of the nice things that does not
automatically make the code-base look "partial C++".  Likewise
operator overloading can make things like

            bit_offset = double_int_add (bit_offset,
                                         tree_to_double_int
                                           (DECL_FIELD_BIT_OFFSET (field)));

be just

           bit_offset = bit_offset + DECL_FIELD_BIT_OFFSET (field);

it still looks like C but with some C++ "magic".

> () Standard C++ idioms enable mashing program components with ease.
> The C++ standard library is based on mixing and matching algorithms
> and data structures, via the common idiom of iterators.

Sort-of agreed.  Though iterator-style (and more so functor style) was never
one of my favorite.

> () The overloadable operator new means that memory can be
> _implicitly_ allocated in the right place.

Implicit allocation is bad.  In a compiler you want to _see_ where you
spend memory.

> () Constructors and destructors reduce the number of places in the
> code where you need to do explicit memory management. Without garbage
> collection, leaks are less frequent.  With garbage collection, you
> have much less active garbage, and can run longer between collection
> runs.  Indeed, a conservative collector would be sufficient.

Time will tell.

> () Constructors and destructors also neatly handle actions that
> must occur in pairs.  The classic example is mutex lock and unlock.
> Within GCC, timevar operations need to happen in pairs.

Agreed.

> () Class hierarchies (even without virtual functions) can directly
> represent type relationships, which means that a debugger dump of
> a C++ type has little unnecessary information, as opposed to the
> present union of structs approach with GCC trees.

In GCC trees only the "base" is a union, and it is so as implementation
detail.  That gdb does not grok a 'tree' well is because gdb is stupid.
All the information is there.

> () Class hierarchies also mean that programmers can distinguish
> in the pointer types that a function needs a decl parameter,
> without having to say 'all trees' versus 'a very specific tree'.
> The static type checking avoids run-time bugs.

True.  In a very limited set of cases.  C++ is not powerful enough
to express pointer-to-everything-that-would-be-considered-a-gimple-val.
Maybe C++ is not the right choice after all?  (I suppose C++ concepts
would have helped here? pointer-to-tree-that-fulfils-is_gimple_val ...
(though is_gimple_val is not be a static property).

> I have written compilers in both C and C++.  I much prefer the
> latter.

Did you ever try to convert an existing large C codebase to C++?
I would not expect a very good result and rather start from scratch.
So I don't see that we ever arrive (or want to arrive) at a pure C++-style
GCC.  Instead I expect we end up (and desire to end up) with GCC
compiled with a C++ compiler that uses C++ features to make the
existing style more readable and maintainable.

Richard.

> --
> Lawrence Crowl

Re: Switching to C++ by default in 4.8

[Xinliang David Li]

On Wed, Apr 11, 2012 at 2:43 AM, Richard Guenther
<richard.guenther@gmail.com> wrote:
> On Wed, Apr 11, 2012 at 4:24 AM, Lawrence Crowl <crowl@google.com> wrote:
>> On 4/10/12, Jakub Jelinek <jakub@redhat.com> wrote:
>>> That when stepping through code in the debugger you keep
>>> enterring/exiting these one liner inlines, most of them really
>>> should be at least by default considered just as normal statements
>>> (e.g. glibc heavily uses artificial attribute for those, still
>>> gdb doesn't hide those by default).
>>
>> You do want to step into those inline functions, except when you do.
>> In the short term, we can make the debugger behave as though they did
>> not exist.  In the longer term, we really want debugging tools that
>> help C++ programmers.  One way to get there is to use C++ ourselves.
>
> Fix the debugger first please.
>
>>> > The above is just quickly cooked up examples. A carefully
>>> > designed C++ based API can be self documenting and make the
>>> > client code very readable. It is hard to believe that there is
>>> > no room for improvement in GCC.
>>>
>>> Do you have examples?  E.g. I haven't touched gold, because,
>>> while it is a new C++ codebase, looks completely unreadable to
>>> me, similarly libdw C++ stuff.  A carefully designed C based API
>>> can be self documenting and make the code very readable as well,
>>> often more so.
>>
>> If you just look at any decently sized code base, it'll look pretty
>> much unreadable.  The question is how quickly can someone who learns
>> the base vocabulary can produce reasonable modifications.
>>
>> There are many places where C++ can help substantially.  For example:
>>
>> () The C++ postfix member function call syntax means that following
>> a chain of attributes is a linear read of the expression.  With C
>> function call syntax, you need to read the expression inside out.
>
> It's a matter of what you are used to (consider LISP).
>
>> () C++ has both overloaded functions and member functions, so you can
>> use the same verb to talk about several different kinds of objects.
>> With C function names, we have to invent a new function name for
>> each type.  Such names are longer and burden both the author and
>> the reader of the code.
>
> Agreed.  Function overloading is one of the nice things that does not
> automatically make the code-base look "partial C++".  Likewise
> operator overloading can make things like
>
>            bit_offset = double_int_add (bit_offset,
>                                         tree_to_double_int
>                                           (DECL_FIELD_BIT_OFFSET (field)));
>
> be just
>
>           bit_offset = bit_offset + DECL_FIELD_BIT_OFFSET (field);
>
> it still looks like C but with some C++ "magic".
>

Function overloading is both bless and curse. It makes code look
better, but may reduce debuggability.


>> () Standard C++ idioms enable mashing program components with ease.
>> The C++ standard library is based on mixing and matching algorithms
>> and data structures, via the common idiom of iterators.
>
> Sort-of agreed.  Though iterator-style (and more so functor style) was never
> one of my favorite.
>
>> () The overloadable operator new means that memory can be
>> _implicitly_ allocated in the right place.
>
> Implicit allocation is bad.  In a compiler you want to _see_ where you
> spend memory.

overload operator new per class allows memory management easier --
many different allocation policies (e.g pool based) can be easily
implemented.


>
>> () Constructors and destructors reduce the number of places in the
>> code where you need to do explicit memory management. Without garbage
>> collection, leaks are less frequent.  With garbage collection, you
>> have much less active garbage, and can run longer between collection
>> runs.  Indeed, a conservative collector would be sufficient.
>
> Time will tell.
>
>> () Constructors and destructors also neatly handle actions that
>> must occur in pairs.  The classic example is mutex lock and unlock.
>> Within GCC, timevar operations need to happen in pairs.
>
> Agreed.
>
>> () Class hierarchies (even without virtual functions) can directly
>> represent type relationships, which means that a debugger dump of
>> a C++ type has little unnecessary information, as opposed to the
>> present union of structs approach with GCC trees.
>
> In GCC trees only the "base" is a union, and it is so as implementation
> detail.  That gdb does not grok a 'tree' well is because gdb is stupid.
> All the information is there.
>
>> () Class hierarchies also mean that programmers can distinguish
>> in the pointer types that a function needs a decl parameter,
>> without having to say 'all trees' versus 'a very specific tree'.
>> The static type checking avoids run-time bugs.
>
> True.  In a very limited set of cases.  C++ is not powerful enough
> to express pointer-to-everything-that-would-be-considered-a-gimple-val.
> Maybe C++ is not the right choice after all?  (I suppose C++ concepts
> would have helped here? pointer-to-tree-that-fulfils-is_gimple_val ...
> (though is_gimple_val is not be a static property).
>
>> I have written compilers in both C and C++.  I much prefer the
>> latter.
>
> Did you ever try to convert an existing large C codebase to C++?
> I would not expect a very good result and rather start from scratch.
> So I don't see that we ever arrive (or want to arrive) at a pure C++-style
> GCC.  Instead I expect we end up (and desire to end up) with GCC
> compiled with a C++ compiler that uses C++ features to make the
> existing style more readable and maintainable.

I like your proposal (from my reading) about keeping core APIs in C,
while the rest can be migrated (gradually).

thanks,

David
>
> Richard.
>
>> --
>> Lawrence Crowl

Re: Switching to C++ by default in 4.8

[Paweł Sikora]

On Wednesday 11 of April 2012 11:43:36 Richard Guenther wrote:

> > () The overloadable operator new means that memory can be
> > _implicitly_ allocated in the right place.
> 
> Implicit allocation is bad.  In a compiler you want to _see_ where you
> spend memory.

in c++ you can overload new/delete operators for each class and track
all these allocations with provided allocator. please consider following
example: http://pastebin.com/UmBGWMTH
you can bind polls, gc or anything else you want for any class
and just use the new/delete keywords in sources as usual.
in pure C you need to call the right malloc_*/free_* variants for each class.

> > () Class hierarchies also mean that programmers can distinguish
> > in the pointer types that a function needs a decl parameter,
> > without having to say 'all trees' versus 'a very specific tree'.
> > The static type checking avoids run-time bugs.
> 
> True.  In a very limited set of cases.  C++ is not powerful enough
> to express pointer-to-everything-that-would-be-considered-a-gimple-val.
> Maybe C++ is not the right choice after all?  (I suppose C++ concepts
> would have helped here? pointer-to-tree-that-fulfils-is_gimple_val ...
> (though is_gimple_val is not be a static property).

hmm :)
the c# provides a nice constraints engine (google the 'where' keyword)
and the so-called duck-typing (c# 4.0) which might simplfy the source
code that operates on ast nodes.

Re: Switching to C++ by default in 4.8

[Lawrence Crowl]

On 4/11/12, Richard Guenther <richard.guenther@gmail.com> wrote:
> On Apr 11, 2012 Lawrence Crowl <crowl@google.com> wrote:
> > On 4/10/12, Jakub Jelinek <jakub@redhat.com> wrote:
> > > That when stepping through code in the debugger you keep
> > > enterring/exiting these one liner inlines, most of them
> > > really should be at least by default considered just as normal
> > > statements (e.g. glibc heavily uses artificial attribute for
> > > those, still gdb doesn't hide those by default).
> >
> > You do want to step into those inline functions, except when
> > you do.  In the short term, we can make the debugger behave
> > as though they did not exist.  In the longer term, we really
> > want debugging tools that help C++ programmers.  One way to
> > get there is to use C++ ourselves.
>
> Fix the debugger first please.

And when the debugger says "show us you're using C++ first", what do
we do?  Based on discussions that I have had, this problem is real.

> > > > The above is just quickly cooked up examples. A carefully
> > > > designed C++ based API can be self documenting and make
> > > > the client code very readable. It is hard to believe that
> > > > there is no room for improvement in GCC.
> > >
> > > Do you have examples?  E.g. I haven't touched gold, because,
> > > while it is a new C++ codebase, looks completely unreadable to
> > > me, similarly libdw C++ stuff.  A carefully designed C based
> > > API can be self documenting and make the code very readable
> > > as well, often more so.
> >
> > If you just look at any decently sized code base, it'll look
> > pretty much unreadable.  The question is how quickly can
> > someone who learns the base vocabulary can produce reasonable
> > modifications.
> >
> > There are many places where C++ can help substantially.
> > For example:
> >
> > () The C++ postfix member function call syntax means that
> > following a chain of attributes is a linear read of the
> > expression.  With C function call syntax, you need to read the
> > expression inside out.
>
> It's a matter of what you are used to (consider LISP).

Certainly.  When I was learning to ride horses, every time I would
get comfortable, my instructor would say, now do it this other way.
It was very uncomfortable, but I got over that and improved my
riding.  I went through that same transition when I was switching
to C++.

> > () C++ has both overloaded functions and member functions,
> > so you can use the same verb to talk about several different
> > kinds of objects.  With C function names, we have to invent
> > a new function name for each type.  Such names are longer and
> > burden both the author and the reader of the code.
>
> Agreed.  Function overloading is one of the nice things that
> does not automatically make the code-base look "partial C++".
> Likewise operator overloading can make things like
>
> bit_offset = double_int_add (bit_offset,
>     tree_to_double_int (DECL_FIELD_BIT_OFFSET (field)));
>
> be just
>
> bit_offset = bit_offset + DECL_FIELD_BIT_OFFSET (field);
>
> it still looks like C but with some C++ "magic".
>
> > () Standard C++ idioms enable mashing program components
> > with ease.  The C++ standard library is based on mixing and
> > matching algorithms and data structures, via the common idiom
> > of iterators.
>
> Sort-of agreed.  Though iterator-style (and more so functor style)
> was never one of my favorite.
>
> > () The overloadable operator new means that memory can be
> > _implicitly_ allocated in the right place.
>
> Implicit allocation is bad.  In a compiler you want to _see_
> where you spend memory.

The operator new is explicit, but the source of the memory for
that allocation is implicit.  You want to be able to _change_
where you allocate memory without touching half the source base.
Operator new overloads enable that precisely because you do not
have to say where the memory comes from each time you allocate.

> > () Constructors and destructors reduce the number of places in
> > the code where you need to do explicit memory management. Without
> > garbage collection, leaks are less frequent.  With garbage
> > collection, you have much less active garbage, and can run
> > longer between collection runs.  Indeed, a conservative collector
> > would be sufficient.
>
> Time will tell.
>
> > () Constructors and destructors also neatly handle actions that
> > must occur in pairs.  The classic example is mutex lock and
> > unlock.  Within GCC, timevar operations need to happen in pairs.
>
> Agreed.
>
> > () Class hierarchies (even without virtual functions) can
> > directly represent type relationships, which means that a
> > debugger dump of a C++ type has little unnecessary information,
> > as opposed to the present union of structs approach with
> > GCC trees.
>
> In GCC trees only the "base" is a union, and it is so as
> implementation detail.  That gdb does not grok a 'tree' well is
> because gdb is stupid.  All the information is there.

It is an implementation detail that causes friction with the
programming environment.

> > () Class hierarchies also mean that programmers can distinguish
> > in the pointer types that a function needs a decl parameter,
> > without having to say 'all trees' versus 'a very specific tree'.
> > The static type checking avoids run-time bugs.
>
> True.  In a very limited set of cases.  C++ is not powerful enough to
> express pointer-to-everything-that-would-be-considered-a-gimple-val.
> Maybe C++ is not the right choice after all?  (I suppose C++ concepts
> would have helped here? pointer-to-tree-that-fulfils-is_gimple_val
> ...  (though is_gimple_val is not be a static property).
>
> > I have written compilers in both C and C++.  I much prefer
> > the latter.
>
> Did you ever try to convert an existing large C codebase to C++?
> I would not expect a very good result and rather start from
> scratch.  So I don't see that we ever arrive (or want to arrive)
> at a pure C++-style GCC.  Instead I expect we end up (and desire
> to end up) with GCC compiled with a C++ compiler that uses C++
> features to make the existing style more readable and maintainable.

While I didn't start the process, I have worked on a C++ compiler
that was in transition from a C source base to a C++ source base.
The parts of the compiler that didn't need much attention still
had a C style.  The parts that did need attention, or provided
immediate benefit, changed to a C++ style fairly rapidly.  Even so,
after more than a decade, the compiler had a mix of styles.  For all
I know, it may still have a mix.

One of the changes I made was to convert an enum into a class
with member functions, etc.  The functional change required more
information than the enum could represent.  The enum was passed in
a single register, while the class was copied for each parameter.
Assignment changed from register-to-register into memcpy.  So,
the instruction overhead for this type jumped substantially.
After 20,000 lines modified in this change, I benchmarked the
compiler and it was 1% faster.  Yes, faster.  The reason is that in
the process I reorganized the associated parsing and error checking.
I took a micro-optimization hit, but won a bigger macro-optimization.

The essential benefit of C++ is that it is easier to write and
use good abstractions, which enables higher-level changes for
higher-level effects.

-- 
Lawrence Crowl

Re: Switching to C++ by default in 4.8

[Chiheng Xu]

On Wed, Apr 11, 2012 at 10:24 AM, Lawrence Crowl <crowl@google.com> wrote:
> On 4/10/12, Jakub Jelinek <jakub@redhat.com> wrote:
>> That when stepping through code in the debugger you keep
>> enterring/exiting these one liner inlines, most of them really
>> should be at least by default considered just as normal statements
>> (e.g. glibc heavily uses artificial attribute for those, still
>> gdb doesn't hide those by default).
>
> You do want to step into those inline functions, except when you do.
> In the short term, we can make the debugger behave as though they did
> not exist.  In the longer term, we really want debugging tools that
> help C++ programmers.  One way to get there is to use C++ ourselves.
>
>> > The above is just quickly cooked up examples. A carefully
>> > designed C++ based API can be self documenting and make the
>> > client code very readable. It is hard to believe that there is
>> > no room for improvement in GCC.
>>
>> Do you have examples?  E.g. I haven't touched gold, because,
>> while it is a new C++ codebase, looks completely unreadable to
>> me, similarly libdw C++ stuff.  A carefully designed C based API
>> can be self documenting and make the code very readable as well,
>> often more so.
>
> If you just look at any decently sized code base, it'll look pretty
> much unreadable.  The question is how quickly can someone who learns
> the base vocabulary can produce reasonable modifications.
>
> There are many places where C++ can help substantially.  For example:
>
> () The C++ postfix member function call syntax means that following
> a chain of attributes is a linear read of the expression.  With C
> function call syntax, you need to read the expression inside out.
>
> () C++ has both overloaded functions and member functions, so you can
> use the same verb to talk about several different kinds of objects.
> With C function names, we have to invent a new function name for
> each type.  Such names are longer and burden both the author and
> the reader of the code.
>
> () Standard C++ idioms enable mashing program components with ease.
> The C++ standard library is based on mixing and matching algorithms
> and data structures, via the common idiom of iterators.
>
> () The overloadable operator new means that memory can be
> _implicitly_ allocated in the right place.
>
> () Constructors and destructors reduce the number of places in the
> code where you need to do explicit memory management. Without garbage
> collection, leaks are less frequent.  With garbage collection, you
> have much less active garbage, and can run longer between collection
> runs.  Indeed, a conservative collector would be sufficient.
>
> () Constructors and destructors also neatly handle actions that
> must occur in pairs.  The classic example is mutex lock and unlock.
> Within GCC, timevar operations need to happen in pairs.
>
> () Class hierarchies (even without virtual functions) can directly
> represent type relationships, which means that a debugger dump of
> a C++ type has little unnecessary information, as opposed to the
> present union of structs approach with GCC trees.
>
> () Class hierarchies also mean that programmers can distinguish
> in the pointer types that a function needs a decl parameter,
> without having to say 'all trees' versus 'a very specific tree'.
> The static type checking avoids run-time bugs.
>
> I have written compilers in both C and C++.  I much prefer the
> latter.
>

What you said sounds correct(mostly) for me. But I think the big
benefit of C++ (or any other modern language that support OO design)
is that C++ is more consistent with modern software engineering
practice : high cohesion and low coupling. C++ allow you to write
excellent code more easily than C. Actually, you don't need to write
C++ code to use C++.  I think you compiler guys should know very well
how each line of C++ code is translated to C code, just as C
programmers normally know very well how each line of C code is
translated to assembly code. So, using which language is not a big
deal. It is all about the methodology, the style. You can think in
C++, imaging the classes, objects in mind, and use your brain to
translate this "in-brain" code to C++ or C code, whatever you like.

The reason why GCC's code is very hard to hack is not simple. In part,
this is because GCC use a very old, extremely hard to understand build
system. In part, this is because GCC developer are more focused on
fixing bugs or adding new features, rather than re-factoring GCC's
code itself.  For example, for a .c file that have 15 years old,
people tend to fix its bugs to make it more and more ugly, rather to
rewrite it.

But I think the big reason is that, GCC tend to have extremely large
.c files, which is typical > 6000 LOC. If you look at LLVM, there are
rarely source code files that is > 2000 LOC.  Typical LLVM source code
files have 1000~2000 LOC.  Just separating  a source code file of 6000
LOC to several small files or file sections of 1000 LOC can improve
the code significantly.  Why has this not been done before ?  GCC
developers are reluctant to re-factoring their code may be the reason.
And, as the .c file grows, it become even harder to re-factor.
Thinking in C++ can help you write smaller, easier to understand,
easier to maintain code(C or C++), which have high cohesion and low
coupling.

And I think the file names of GCC's source can also be changed more
friendly to newbies, using some notion of FQN(fully qualified name)
may be good.


As for plug-in API, I think using C style API is OK. Thinking of Win32
API, the API is C, but it supports C++ notion of
object/encapsulation/polymorphism, so you can easily write wrapper API
in C++, namely MFC. I mean , to provide a C style API and provide a
C++ wrapper library for this API, then you can use both C and C++ in
you plug-in.

As for experimenting C++ in GCC, I suggest , at first, using C++ only
in the internal of a pass implementation or a module,  not exposing
C++ interface to other part of code. Namely, the interfaces between
between modules are still C,  but he implementations can be written in
either C or C++ or both.

And I predict that C++ will not have any positive impact on
performance(compile time or run time).

-- 
Chiheng Xu

Re: Switching to C++ by default in 4.8

[Richard Guenther]

On Thu, Apr 12, 2012 at 11:28 AM, Chiheng Xu <chiheng.xu@gmail.com> wrote:
>
> The reason why GCC's code is very hard to hack is not simple. In part,
> this is because GCC use a very old, extremely hard to understand build
> system. In part, this is because GCC developer are more focused on
> fixing bugs or adding new features, rather than re-factoring GCC's
> code itself.  For example, for a .c file that have 15 years old,
> people tend to fix its bugs to make it more and more ugly, rather to
> rewrite it.
>
> But I think the big reason is that, GCC tend to have extremely large
> .c files, which is typical > 6000 LOC. If you look at LLVM, there are
> rarely source code files that is > 2000 LOC.  Typical LLVM source code
> files have 1000~2000 LOC.  Just separating  a source code file of 6000
> LOC to several small files or file sections of 1000 LOC can improve
> the code significantly.  Why has this not been done before ?  GCC
> developers are reluctant to re-factoring their code may be the reason.
> And, as the .c file grows, it become even harder to re-factor.
> Thinking in C++ can help you write smaller, easier to understand,
> easier to maintain code(C or C++), which have high cohesion and low
> coupling.
>
> And I think the file names of GCC's source can also be changed more
> friendly to newbies, using some notion of FQN(fully qualified name)
> may be good.

I think one of the reasons is a tools deficiency - at least subversion (which
we use) is not able to track code motion, so if you dig in the revision history
you will need more intermediate steps, but more important, rely on 2nd level
information (like the ChangeLog entry) to tell where a function was moved from.

Still some refactoring happens (I think mostly trying to remove APIs
is important).
But yes, I think we never renamed files ... I suppose when we start moving
things into sub-directories that would be a good time to re-think names.  At
least subversion can handle file-renames just fine ;)

Yes, files are too big - but splitting them is not easy unless you can
figure out
a hierarchy that you can expose.  The largest file is dwarf2out.c with
22825 lines,
but the average is more like 2000 (just looking at gcc/*.c files).
There are only
23 files bigger than 6000 lines (out of 356), so the situation is not as bad as
you paint it.  But yes, looking at filenames hardly tells you about its contents
anymore.

Richard.

Re: Switching to C++ by default in 4.8

[Chiheng Xu]

On Thu, Apr 12, 2012 at 6:30 PM, Richard Guenther
<richard.guenther@gmail.com> wrote:
>
> Yes, files are too big - but splitting them is not easy unless you can
> figure out
> a hierarchy that you can expose.  The largest file is dwarf2out.c with
> 22825 lines,
> but the average is more like 2000 (just looking at gcc/*.c files).
> There are only
> 23 files bigger than 6000 lines (out of 356), so the situation is not as bad as
> you paint it.  But yes, looking at filenames hardly tells you about its contents
> anymore.
>

Average file size is not relevant here.  You should consider how many
code are in files that are big.  In gcc/ sub-directory, there are
about 600 source files(.c and .h).  63 of them (10%) exceed 100 KB,
which contribute over 50% of the total source file size of the
directory. 75 of them(13%) is between 50 KB to 100 KB, which
contribute 25% of the  total source file size of the directory.
The rest,  440 or so of them, is below 50 KB, which contribute 75% of
the  total source file size of the directory. Some of this files are
so small that some merging is needed.

So, I can say, most of the GCC source code is in large files.

And this also hold for language front-ends.

-- 
Chiheng Xu

Re: Switching to C++ by default in 4.8

[Chiheng Xu]

On Sat, Apr 14, 2012 at 9:15 AM, Chiheng Xu <chiheng.xu@gmail.com> wrote:
> The rest,  440 or so of them, is below 50 KB, which contribute 75% of
The rest,  440 or so of them, is below 50 KB, which contribute 25% of

-- 
Chiheng Xu

Re: Switching to C++ by default in 4.8

[Robert Dewar]

On 4/13/2012 9:15 PM, Chiheng Xu wrote:

> So, I can say, most of the GCC source code is in large files.
>
> And this also hold for language front-ends.

I see nothing inherently desirable about having all small files.
For example, in GNAT, yes, some files are large, sem_ch3 (semantic
analysis for chapter 3 stuff which includes all of type handling)
is large (over 20,000 lines 750KB, but nothing would be gained
(and something would be lost) by trying to split this file up.

As long as all your tools can handle large files nicely, and
as long as the internal organization of the large file is
clean and clear, I see no problem.
>

Re: Switching to C++ by default in 4.8

[Chiheng Xu]

On Sat, Apr 14, 2012 at 5:08 PM, Robert Dewar <dewar@adacore.com> wrote:
> On 4/13/2012 9:15 PM, Chiheng Xu wrote:
>
>> So, I can say, most of the GCC source code is in large files.
>>
>> And this also hold for language front-ends.
>
>
> I see nothing inherently desirable about having all small files.
> For example, in GNAT, yes, some files are large, sem_ch3 (semantic
> analysis for chapter 3 stuff which includes all of type handling)
> is large (over 20,000 lines 750KB, but nothing would be gained
> (and something would be lost) by trying to split this file up.
>
> As long as all your tools can handle large files nicely, and
> as long as the internal organization of the large file is
> clean and clear, I see no problem.
>>
>>
>

Actually, I only partially agree with you on this. And I didn't say
smaller is necessarily better.
But normally, high cohesion and low coupling code tend not be large.
Normally large files tend to export only few highly related entry
points. Most of the functions in large file are sub-routines(directly
or indirectly) of the entry points. The functions can be divided into
several groups or layers, each group or layer can form a conceptual
sub-module. I often see GCC developer divide functions in large file
into sub-modules by prefix them with sub-module specific prefix and
group them together.  This is good,  but not enough. If the functions
in sub-modules are put in separate files,  then the code will be more
manageable than not doing so. This is because the
interfaces/boundaries between sub-modules are more clear, and the code
have higher cohesion and lower coupling.


-- 
Chiheng Xu

Re: Switching to C++ by default in 4.8

[Robert Dewar]

On 4/14/2012 6:38 AM, Chiheng Xu wrote:

> Actually, I only partially agree with you on this. And I didn't say
> smaller is necessarily better.
> But normally, high cohesion and low coupling code tend not be large.
> Normally large files tend to export only few highly related entry
> points. Most of the functions in large file are sub-routines(directly
> or indirectly) of the entry points. The functions can be divided into
> several groups or layers, each group or layer can form a conceptual
> sub-module. I often see GCC developer divide functions in large file
> into sub-modules by prefix them with sub-module specific prefix and
> group them together.  This is good,  but not enough. If the functions
> in sub-modules are put in separate files,  then the code will be more
> manageable than not doing so. This is because the
> interfaces/boundaries between sub-modules are more clear, and the code
> have higher cohesion and lower coupling.

I find the claim unconvincing in practice, it is possible to have code
in separate files with unclear interfaces and boundaries, and code in
single files with perfectly clear interfaces and boundaries. You can
claim without evidence that there is a causal relation here but that
is simply not the case in my experience.
>
>

Re: Switching to C++ by default in 4.8

[Paweł Sikora]

On Tuesday 10 of April 2012 10:46:14 Jakub Jelinek wrote:
> On Mon, Apr 09, 2012 at 04:34:32PM -0700, Xinliang David Li wrote:
> > Class hierarchy is one such feature that is useful. Assuming we have
> > two hierarchies for gcc: one for values rooted at ValExp, and one for
> > gimple stmts rooted at GimpInst.
> > 
> > 1) For IR browsing,
> >    *) all the macro accessors can be eliminated -- a big plus for debugging;
> 
> Not that clear, if all the macros are replaced by tons of inline functions,
> the debugging experience can be actually significantly worse.

debugabilty can be improved with set of gdb python pretty printers
which could present gcc's structures in human readable form (instead of union mix).

Re: Switching to C++ by default in 4.8

[Dave Korn]

On 10/04/2012 17:41, Paweł Sikora wrote:
> On Tuesday 10 of April 2012 10:46:14 Jakub Jelinek wrote:
>> On Mon, Apr 09, 2012 at 04:34:32PM -0700, Xinliang David Li wrote:
>>> Class hierarchy is one such feature that is useful. Assuming we have 
>>> two hierarchies for gcc: one for values rooted at ValExp, and one for 
>>> gimple stmts rooted at GimpInst.
>>> 
>>> 1) For IR browsing, *) all the macro accessors can be eliminated -- a
>>> big plus for debugging;
>> Not that clear, if all the macros are replaced by tons of inline
>> functions, the debugging experience can be actually significantly worse.
> 
> debugabilty can be improved with set of gdb python pretty printers which
> could present gcc's structures in human readable form (instead of union
> mix).
> 

  Would that be much different from "call debug_tree(x)" which we already have?

    cheers,
      DaveK

Re: Switching to C++ by default in 4.8

[Andrew Pinski]

2012/4/10 Dave Korn <dave.korn.cygwin@gmail.com>:
> On 10/04/2012 17:41, Paweł Sikora wrote:
>> On Tuesday 10 of April 2012 10:46:14 Jakub Jelinek wrote:
>>> On Mon, Apr 09, 2012 at 04:34:32PM -0700, Xinliang David Li wrote:
>>>> Class hierarchy is one such feature that is useful. Assuming we have
>>>> two hierarchies for gcc: one for values rooted at ValExp, and one for
>>>> gimple stmts rooted at GimpInst.
>>>>
>>>> 1) For IR browsing, *) all the macro accessors can be eliminated -- a
>>>> big plus for debugging;
>>> Not that clear, if all the macros are replaced by tons of inline
>>> functions, the debugging experience can be actually significantly worse.
>>
>> debugabilty can be improved with set of gdb python pretty printers which
>> could present gcc's structures in human readable form (instead of union
>> mix).
>>
>
>  Would that be much different from "call debug_tree(x)" which we already have?

To the user no but the python pretty printers can be used without a
running process and without extra stack size. (both are useful as then
we can use with core files and with an overflow stack).

Thanks,
Andrew Pinski

Re: Switching to C++ by default in 4.8

[Richard Guenther]

2012/4/10 Dave Korn <dave.korn.cygwin@gmail.com>:
> On 10/04/2012 17:41, Paweł Sikora wrote:
>> On Tuesday 10 of April 2012 10:46:14 Jakub Jelinek wrote:
>>> On Mon, Apr 09, 2012 at 04:34:32PM -0700, Xinliang David Li wrote:
>>>> Class hierarchy is one such feature that is useful. Assuming we have
>>>> two hierarchies for gcc: one for values rooted at ValExp, and one for
>>>> gimple stmts rooted at GimpInst.
>>>>
>>>> 1) For IR browsing, *) all the macro accessors can be eliminated -- a
>>>> big plus for debugging;
>>> Not that clear, if all the macros are replaced by tons of inline
>>> functions, the debugging experience can be actually significantly worse.
>>
>> debugabilty can be improved with set of gdb python pretty printers which
>> could present gcc's structures in human readable form (instead of union
>> mix).
>>
>
>  Would that be much different from "call debug_tree(x)" which we already have?

Not really, but it would be easier to customize.  I would like to see less
debug_* routines in favor of some gdb python code.  Heh, maybe we
could even use the (non-existant) new plugin introspection API for that!

Richard.

>    cheers,
>      DaveK
>

Re: Switching to C++ by default in 4.8

[Lawrence Crowl]

On 4/10/12, Jakub Jelinek <jakub@redhat.com> wrote:
> On Mon, Apr 09, 2012 at 04:34:32PM -0700, Xinliang David Li wrote:
> > Class hierarchy is one such feature that is useful. Assuming we
> > have two hierarchies for gcc: one for values rooted at ValExp,
> > and one for gimple stmts rooted at GimpInst.
> >
> > 1) For IR browsing,
> > *) all the macro accessors can be eliminated -- a big plus
> > for debugging;
>
> Not that clear, if all the macros are replaced by tons of
> inline functions, the debugging experience can be actually
> significantly worse.  Already some the inline functions used
> like tree_operand_length used by TREE_OPERAND_LENGTH macro are
> extremely annoying from debugging POV.

We have options availble to supress those functions in the debugger.
Longer term, better debugger support for C++ is the right thing
to do.

> > *) gcc implementation has lots of hard coded
> > TREE_OPERAND (exp, nn)
> >
> > e.g.
> >   exp->as_component_ref().get_field() ..
> >   exp->as_mem_access().get_base() ...
> >   exp->as_mem_acesss().get_address()
> >   --> produces the address expression for memory access
> >   exp->as_mem_access().get_alias_handle ()
> >   gimple_inst->serialize (&fixup_list)
> >   --> a virtual function overriden by actual instruction types
> >   that knows its byte code format.
>
> That silently assumes we want to change basic GIMPLE/tree data
> structures to virtual classes, which is a significant change
> that has a significant cost as well.

I think he was explicit about virtual functions.  By virtual classes
did you mean virtual bases or classes with virtual functions?
I have not seen a need for virtual classes.  In any event, much
of this work could be done without virtual functions, though that
would not be my choice due to the added overhead and complexity.

> E.g. all such changed data structures grow by a virtual pointer
> field.  Those data structures are heavily optimized for memory
> footprint.  Not to mention it is very questionable if the above
> stuff is more readable than what we currently have.

A virtual pointer can reduce the size because the dynamic type
can encode quite a bit of information that is currently encoded
in bitfields.

In addition, while the current data structures are densely packed,
they are not necessarily information rich.  In the PPH branch,
we found that near half the pointers we were streaming were null,
which says that many of the fields are unused.  This information
could be shifted to auxilary tables.

-- 
Lawrence Crowl

Re: Switching to C++ by default in 4.8

[Chiheng Xu]

On Tue, Apr 10, 2012 at 4:46 PM, Jakub Jelinek <jakub@redhat.com> wrote:
> On Mon, Apr 09, 2012 at 04:34:32PM -0700, Xinliang David Li wrote:
>> Class hierarchy is one such feature that is useful. Assuming we have
>> two hierarchies for gcc: one for values rooted at ValExp, and one for
>> gimple stmts rooted at GimpInst.
>>
>> 1) For IR browsing,
>>    *) all the macro accessors can be eliminated -- a big plus for debugging;
>
> Not that clear, if all the macros are replaced by tons of inline functions,
> the debugging experience can be actually significantly worse.  Already some the
> inline functions used like tree_operand_length used by TREE_OPERAND_LENGTH
> macro are extremely annoying from debugging POV.
>

To avoid debugging POV, in the code, a line of code can be used to
convert it to the right pointer type and assign it to a temp variable.
This line of code can be optimized away, but temp variable of the
right pointer type can improve debuggability.

>>    *) gcc implementation has lots of hard coded TREE_OPERAND (exp, nn)
>>
>>      e.g.
>>             exp->as_component_ref().get_field() ..
>>             exp->as_mem_access().get_base() ...
>>             exp->as_mem_acesss().get_address() --> produces the
>> address expression for memory access
>>             exp->as_mem_access().get_alias_handle ()
>>
>>             gimple_inst->serialize (&fixup_list) --> a virtual
>> function overriden by actual instruction types that knows its byte
>> code format.
>
> That silently assumes we want to change basic GIMPLE/tree data structures
> to virtual classes, which is a significant change that has a significant
> cost as well.  E.g. all such changed data structures grow by a virtual
> pointer field.  Those data structures are heavily optimized for memory
> footprint.
> Not to mention it is very questionable if the above stuff is more readable
> than what we currently have.
>

Agree.


-- 
Chiheng Xu

Re: Switching to C++ by default in 4.8

[Chiheng Xu]

On Tue, Apr 10, 2012 at 4:46 PM, Jakub Jelinek <jakub@redhat.com> wrote:
>
>>    *) gcc implementation has lots of hard coded TREE_OPERAND (exp, nn)
>>
>>      e.g.
>>             exp->as_component_ref().get_field() ..
>>             exp->as_mem_access().get_base() ...
>>             exp->as_mem_acesss().get_address() --> produces the
>> address expression for memory access
>>             exp->as_mem_access().get_alias_handle ()
>>
>>             gimple_inst->serialize (&fixup_list) --> a virtual
>> function overriden by actual instruction types that knows its byte
>> code format.
>
> That silently assumes we want to change basic GIMPLE/tree data structures
> to virtual classes, which is a significant change that has a significant
> cost as well.  E.g. all such changed data structures grow by a virtual
> pointer field.  Those data structures are heavily optimized for memory
> footprint.
> Not to mention it is very questionable if the above stuff is more readable
> than what we currently have.
>

And I want to say that tree/gimple/rtl are compiler's data(or state),
not compiler's text(or logic), the most important thing about them is
how to access their fields.


-- 
Chiheng Xu

Re: Switching to C++ by default in 4.8

[Chiheng Xu]

On Sat, Apr 14, 2012 at 11:47 AM, Chiheng Xu <chiheng.xu@gmail.com> wrote:
>
> And I want to say that tree/gimple/rtl are compiler's data(or state),
> not compiler's text(or logic), the most important thing about them is
> how to access their fields.
>

Given the above assumption, now I doubt the necessity of accessor
macros or C++ getter/setter method.

Is "tree->code" more direct and efficient than "TREE_CODE(tree)" or
"tree->get_code()" ?


-- 
Chiheng Xu

Re: Switching to C++ by default in 4.8

[Duncan Sands]

>> And I want to say that tree/gimple/rtl are compiler's data(or state),
>> not compiler's text(or logic), the most important thing about them is
>> how to access their fields.
>>
>
> Given the above assumption, now I doubt the necessity of accessor
> macros or C++ getter/setter method.
>
> Is "tree->code" more direct and efficient than "TREE_CODE(tree)" or
> "tree->get_code()" ?

On a side note, the dragonegg plugin (which is written in C++) defines

   /// isa - Return true if the given tree has the specified code.
   template<enum tree_code code> bool isa(const_tree t) {
     return TREE_CODE(t) == code;
   }

which lets you write things like

   if (isa<INTEGRAL_TYPE>(t)) ...

and so on.

While this is a bit more compact than "if (TREE_CODE(t) == INTEGRAL_TYPE",
the main advantage to my mind is that it is a standard C++ idiom that should
be natural for many C++ programmers.

Ciao, Duncan.

Re: Switching to C++ by default in 4.8

[Chiheng Xu]

On Mon, Apr 16, 2012 at 3:48 PM, Duncan Sands <baldrick@free.fr> wrote:
>>> And I want to say that tree/gimple/rtl are compiler's data(or state),
>>> not compiler's text(or logic), the most important thing about them is
>>> how to access their fields.
>>>
>>
>> Given the above assumption, now I doubt the necessity of accessor
>> macros or C++ getter/setter method.
>>
>> Is "tree->code" more direct and efficient than "TREE_CODE(tree)" or
>> "tree->get_code()" ?
>
>
> On a side note, the dragonegg plugin (which is written in C++) defines
>
>  /// isa - Return true if the given tree has the specified code.
>  template<enum tree_code code> bool isa(const_tree t) {
>    return TREE_CODE(t) == code;
>  }
>
> which lets you write things like
>
>  if (isa<INTEGRAL_TYPE>(t)) ...
>
> and so on.
>
> While this is a bit more compact than "if (TREE_CODE(t) == INTEGRAL_TYPE",

Sorry, I totally disagree with you.

Your code :

 /// isa - Return true if the given tree has the specified code.
 template<enum tree_code code> bool isa(const_tree t) {
   return TREE_CODE(t) == code;
 }

 if (isa<INTEGRAL_TYPE>(t)) ...

can be easily replaced by :

bool tree_is_a(const_tree t, enum tree_code code)
{
   return TREE_CODE(t) == code;
}

if(tree_is_a(t, INTEGRAL_TYPE)) ...

Your code is like a abuse of template.

And, I think GCC developers would more like "if (TREE_CODE(t) ==
INTEGRAL_TYPE)" style code than the above code.

my proposal is
if (t->code == INTEGRAL_TYPE){
      integral_type  p_integer_type =  (integral_type) t;
      do_some_work_integral_type(p_integer_type);
}


> the main advantage to my mind is that it is a standard C++ idiom that should
> be natural for many C++ programmers.
>
I don't know what you mean by saying the "standard C++ idiom". Do you
mean abuse of template or the use of getter/setter method ?
In the first case, I will not comment any more.

But if you mean that getter/setter method is the "standard C++ idiom",
I want to say something.

In my understanding, getter/setter methods are used in GUI programming
area, where user level C++ objects encapsulate kernel objects.
People use getter/setter methods to access the properties of kernel
object. C++ object use getter/setter method to capture user's request
and forward it to kernel. This is the simple case.

Sometimes, C++ GUI library add artificial properties that do not
directly correspond to kernel object's properties. The values of these
properties are store in C++ object, not in kernel object.  Getter
methods of these artificial properties are simple, just retrieve the
values stored in C++ object. But, setter methods need to do more work,
besides storing values in C++ object,  normally, several calls to the
kernel API is needed to manipulate the kernel object.

But in GCC, we don't need to wrap kernel object, and we don't have
artificial properties. So, I see no necessity of getter/setter
methods.

Why GCC currently have TREE_CODE() or TREE_TYPE() macros ?
My understanding is that this is because C language does not support
inheritance. The field names in base type does not go directly into
derived type.  In C, "p_derived_type->field_of_base_type" does not
work. You must use "p_derived_type->m_base_type.field_of_base_type" .
For multilevel of derivation, the expression is even longer.
Apparently, this is not as clear as
FIELD_OF_BASE_TYPE(p_derived_type).

But once you use C++, there will be no such trouble.
"p_derived_type->field_of_base_type" just works regardless of the
levels of derivation !


-- 
Chiheng Xu

Re: Switching to C++ by default in 4.8

[Oleg Endo]

On Mon, 2012-04-16 at 04:11 +0800, Chiheng Xu wrote:
> On Sat, Apr 14, 2012 at 11:47 AM, Chiheng Xu <chiheng.xu@gmail.com> wrote:
> >
> > And I want to say that tree/gimple/rtl are compiler's data(or state),
> > not compiler's text(or logic), the most important thing about them is
> > how to access their fields.
> >
> 
> Given the above assumption, now I doubt the necessity of accessor
> macros or C++ getter/setter method.

According to my experience, it doesn't take more time/effort to write
"tree->code ()" instead of "tree->code" and such getter functions allow
for easier refactoring etc.  If you omit the getters/setters you can't
express things such as immutable objects (well you still could with
const ivars but...), and you'll always have to have the ivar...

> 
> Is "tree->code" more direct and efficient than "TREE_CODE(tree)" or
> "tree->get_code()" ?

What do you mean by efficient?  All of them will (most likely) end up as
the same machine code.  But still, there's a reason why there's a
TREE_CODE getter which is supposed to be used instead of writing
"tree->base.code" everywhere...

Cheers,
Oleg

Re: Switching to C++ by default in 4.8

[Chiheng Xu]

On Tue, Apr 17, 2012 at 2:52 AM, Oleg Endo <oleg.endo@t-online.de> wrote:
> On Mon, 2012-04-16 at 04:11 +0800, Chiheng Xu wrote:
>> On Sat, Apr 14, 2012 at 11:47 AM, Chiheng Xu <chiheng.xu@gmail.com> wrote:
>> >
>> > And I want to say that tree/gimple/rtl are compiler's data(or state),
>> > not compiler's text(or logic), the most important thing about them is
>> > how to access their fields.
>> >
>>
>> Given the above assumption, now I doubt the necessity of accessor
>> macros or C++ getter/setter method.
>
> According to my experience, it doesn't take more time/effort to write
> "tree->code ()" instead of "tree->code" and such getter functions allow
> for easier refactoring etc.  If you omit the getters/setters you can't
> express things such as immutable objects (well you still could with
> const ivars but...), and you'll always have to have the ivar...
>
Sorry,  I don't know what is the benefit of const ivars.
But if you use "tree->code" instead of "tree->code()", the compiler
know very well whether you intend to read or write a piece of memory.
The const-ness is clear. I doubt how the compiler optimizer can
further optimize it.

>>
>> Is "tree->code" more direct and efficient than "TREE_CODE(tree)" or
>> "tree->get_code()" ?
>
> What do you mean by efficient?  All of them will (most likely) end up as
> the same machine code.

By saying "efficient", I probably mean compile time is reduced( macro
expansion + optimizing, or inlining + optimizing, are avoided).
I also probably mean reduced .h file size( the definitions of accessor
macros and C++ getter/setter inline methods, are avoided).

-- 
Chiheng Xu

Re: Switching to C++ by default in 4.8

[Oleg Endo]

On Wed, 2012-04-18 at 06:03 +0800, Chiheng Xu wrote:
> >
> Sorry,  I don't know what is the benefit of const ivars.

I didn't say there's a benefit of using const ivars in this hypothetical
case.  It's just another possible option of doing certain things.

> But if you use "tree->code" instead of "tree->code()", the compiler
> know very well whether you intend to read or write a piece of memory.
> The const-ness is clear. I doubt how the compiler optimizer can
> further optimize it.

I didn't say that either...

> By saying "efficient", I probably mean compile time is reduced( macro
> expansion + optimizing, or inlining + optimizing, are avoided).
> I also probably mean reduced .h file size( the definitions of accessor
> macros and C++ getter/setter inline methods, are avoided).
> 

...then probably I wasn't aware of the fact that this is about
optimizing for compile time.  If that's the case, maybe the topic of the
thread should be changed to avoid further confusion.

Cheers,
Oleg

Re: Switching to C++ by default in 4.8

[Richard Guenther]

On Tue, Apr 10, 2012 at 1:34 AM, Xinliang David Li <davidxl@google.com> wrote:
> On Wed, Apr 4, 2012 at 5:04 AM, Richard Guenther
> <richard.guenther@gmail.com> wrote:
>> On Wed, Apr 4, 2012 at 1:50 PM, Bernd Schmidt <bernds@codesourcery.com> wrote:
>>> On 04/04/2012 11:06 AM, Richard Guenther wrote:
>>>> So - I'll veto the switch unless I see 1) and 2).  1) and 2) can be combined
>>>> by transitioning vec.h to a C++ template class, with proper GC support.
>>>> (not sure that I can veto anything - heh)
>>>
>>> I don't think I can veto anything, but I'll go on the record again
>>> saying that I don't think this entire plan is a good idea. Write a new
>>> project in C++? Absolutely. Convert a large existing one to a different
>>> language? A huge waste of time that will distract us for years from
>>> actual user-visible changes.
>>
>> I agree for the idea of converting all of GCC to C++ (whatever that means).
>> I disagree for the part making the internal infrastructure easier to use,
>> understand and maintain.  Which means targeting mostly isolated sub-systems,
>> like vec.h (and other various containers), double-int.[ch] (and other various
>> way of representing and working with constants).  Making tree or gimple a
>> C++ class with inheritance and whatever is indeed a huge waste of time
>> and existing developer ressources (that, if only because they have to adapt
>> and maintain two completely different code-bases over some time).
>>
>> I expect the GCC core to maintain written in C, compiled by C++.
>
>
> GCC's current C programming APIs (both browsing APIs and
> creator/factory APIs) are somewhat primitive and too low level. I
> expect switching to C++ can significantly make GCC more modern
> looking. It can greatly improve readability and productivity (for
> simplifying transformation and instrumentation development). C++
> features should not be be abused (e.g., MI, VI etc), but we should not
> miss on basic C++ features.
>
> Class hierarchy is one such feature that is useful. Assuming we have
> two hierarchies for gcc: one for values rooted at ValExp, and one for
> gimple stmts rooted at GimpInst.
>
> 1) For IR browsing,
>   *) all the macro accessors can be eliminated -- a big plus for debugging;
>   *) gcc implementation has lots of hard coded TREE_OPERAND (exp, nn)
>
>     e.g.
>            exp->as_component_ref().get_field() ..
>            exp->as_mem_access().get_base() ...
>            exp->as_mem_acesss().get_address() --> produces the
> address expression for memory access
>            exp->as_mem_access().get_alias_handle ()
>
>            gimple_inst->serialize (&fixup_list) --> a virtual
> function overriden by actual instruction types that knows its byte
> code format.
>
> For experienced GCC developers, current APIs won't a problem at all --
> but it does become a big minus for newbies and in the long run will
> hurt gcc community.
>
> 2) IR manipulation APIs -- the problem seems more serious. It seems
> GCC prefers low level APIs so that incremental update of derived data
> (control flow, SSA) can be easier -- but that does not have to be the
> case -- high level APIs can hide most of the update from the
> programmer.
>
>  Example:   Create a a simple assignment instruction from a load (this
> example comes from Asan implementation in gcc by Kostya)
>
>  t = build1 (INDIRECT_REF, some_type,
>               build1 (VIEW_CONVERT_EXPR, some_type, addr));
>   t = force_gimple_operand (t, &stmts, false, NULL_TREE);
>   gimple_seq_add_seq (&seq, stmts);
>   the_value = make_rename_temp (shadow_type, "__var_name");
>   g = gimple_build_assign (the_value, t);
>  nm = make_ssa_name (the_value, g);
>  gimple_assign_set_lhs (g, nm);
>
>
> This can be as simple as (by hiding the gimplification, ssa name creation etc)
>
>   new_assign_insn = gimple::new_load_insn (INDIRECT_REF, some_type, addr_exp);
>   new_assign_insn->get_lhs()->as_ssa_name()->get_val_decl()->setname("...");
>
> The creator interface can also take a form that accepts the addr_insn
> that produces the address.
>
> Another example:
>
> Instrument a BB1 so that it is guarded:
>
> if (counts > sampling_rate) // BB0
>  {
>      counts = 0;
>      ORIGINAL BB1 code
>  } // BB2
>
>
> It can be as simple as the following:
>
> basic_block bb0, bb1;
>
> gimple_br_inst = gimple::new_cond_br (value:new_cmp_exp (....),
>                                                                  bb1,
> /* taken branch* /
>
> &bb2, /* fall through */
>
> &bb2, /* merge point */
>
> &bb0 /* New predecessor */);
> reset_count = gimple:new_store_insn (..., bb1, insert_before);
>
>
> If the current APIs are used to do the coding, it will take how X
> times more API calls which is non-readable for human beings.

The above is non-readable to me neither.  That we miss a helper
to do the split-the-cfg-here-with-a-conditional-branch-and-bbs-for-true-false
does not mean that such helper has to use whatever fancy C++ interface.
What's wrong with a C helper for the above?  Why is it easier in C++ at all?

And you want to contribute the 10+ man years to consistently(!) transition
GCC to such API?

Sorry, but you cannot magically transform GCC to something more modern.
Thus it will be isolated "leaf" modules that will see conversion.  I don't hold
my breath for even converting the gimple bits, not to even think about trees
(or RTL).

Sorry.

Richard.

>
> thanks,
>
> David
>
>>
>>> I also find debugging C++ in gdb somewhat more annoying than debugging
>>> plain C, and at the moment I always go back to a stage1 compiler.
>>
>> Indeed - I'd be worried if my debugging efficiency decreases by more than 5%.
>>
>> Richard.

Re: Switching to C++ by default in 4.8

[Xinliang David Li]

On Tue, Apr 10, 2012 at 4:14 AM, Richard Guenther
<richard.guenther@gmail.com> wrote:
> On Tue, Apr 10, 2012 at 1:34 AM, Xinliang David Li <davidxl@google.com> wrote:
>> On Wed, Apr 4, 2012 at 5:04 AM, Richard Guenther
>> <richard.guenther@gmail.com> wrote:
>>> On Wed, Apr 4, 2012 at 1:50 PM, Bernd Schmidt <bernds@codesourcery.com> wrote:
>>>> On 04/04/2012 11:06 AM, Richard Guenther wrote:
>>>>> So - I'll veto the switch unless I see 1) and 2).  1) and 2) can be combined
>>>>> by transitioning vec.h to a C++ template class, with proper GC support.
>>>>> (not sure that I can veto anything - heh)
>>>>
>>>> I don't think I can veto anything, but I'll go on the record again
>>>> saying that I don't think this entire plan is a good idea. Write a new
>>>> project in C++? Absolutely. Convert a large existing one to a different
>>>> language? A huge waste of time that will distract us for years from
>>>> actual user-visible changes.
>>>
>>> I agree for the idea of converting all of GCC to C++ (whatever that means).
>>> I disagree for the part making the internal infrastructure easier to use,
>>> understand and maintain.  Which means targeting mostly isolated sub-systems,
>>> like vec.h (and other various containers), double-int.[ch] (and other various
>>> way of representing and working with constants).  Making tree or gimple a
>>> C++ class with inheritance and whatever is indeed a huge waste of time
>>> and existing developer ressources (that, if only because they have to adapt
>>> and maintain two completely different code-bases over some time).
>>>
>>> I expect the GCC core to maintain written in C, compiled by C++.
>>
>>
>> GCC's current C programming APIs (both browsing APIs and
>> creator/factory APIs) are somewhat primitive and too low level. I
>> expect switching to C++ can significantly make GCC more modern
>> looking. It can greatly improve readability and productivity (for
>> simplifying transformation and instrumentation development). C++
>> features should not be be abused (e.g., MI, VI etc), but we should not
>> miss on basic C++ features.
>>
>> Class hierarchy is one such feature that is useful. Assuming we have
>> two hierarchies for gcc: one for values rooted at ValExp, and one for
>> gimple stmts rooted at GimpInst.
>>
>> 1) For IR browsing,
>>   *) all the macro accessors can be eliminated -- a big plus for debugging;
>>   *) gcc implementation has lots of hard coded TREE_OPERAND (exp, nn)
>>
>>     e.g.
>>            exp->as_component_ref().get_field() ..
>>            exp->as_mem_access().get_base() ...
>>            exp->as_mem_acesss().get_address() --> produces the
>> address expression for memory access
>>            exp->as_mem_access().get_alias_handle ()
>>
>>            gimple_inst->serialize (&fixup_list) --> a virtual
>> function overriden by actual instruction types that knows its byte
>> code format.
>>
>> For experienced GCC developers, current APIs won't a problem at all --
>> but it does become a big minus for newbies and in the long run will
>> hurt gcc community.
>>
>> 2) IR manipulation APIs -- the problem seems more serious. It seems
>> GCC prefers low level APIs so that incremental update of derived data
>> (control flow, SSA) can be easier -- but that does not have to be the
>> case -- high level APIs can hide most of the update from the
>> programmer.
>>
>>  Example:   Create a a simple assignment instruction from a load (this
>> example comes from Asan implementation in gcc by Kostya)
>>
>>  t = build1 (INDIRECT_REF, some_type,
>>               build1 (VIEW_CONVERT_EXPR, some_type, addr));
>>   t = force_gimple_operand (t, &stmts, false, NULL_TREE);
>>   gimple_seq_add_seq (&seq, stmts);
>>   the_value = make_rename_temp (shadow_type, "__var_name");
>>   g = gimple_build_assign (the_value, t);
>>  nm = make_ssa_name (the_value, g);
>>  gimple_assign_set_lhs (g, nm);
>>
>>
>> This can be as simple as (by hiding the gimplification, ssa name creation etc)
>>
>>   new_assign_insn = gimple::new_load_insn (INDIRECT_REF, some_type, addr_exp);
>>   new_assign_insn->get_lhs()->as_ssa_name()->get_val_decl()->setname("...");
>>
>> The creator interface can also take a form that accepts the addr_insn
>> that produces the address.
>>
>> Another example:
>>
>> Instrument a BB1 so that it is guarded:
>>
>> if (counts > sampling_rate) // BB0
>>  {
>>      counts = 0;
>>      ORIGINAL BB1 code
>>  } // BB2
>>
>>
>> It can be as simple as the following:
>>
>> basic_block bb0, bb1;
>>
>> gimple_br_inst = gimple::new_cond_br (value:new_cmp_exp (....),
>>                                                                  bb1,
>> /* taken branch* /
>>
>> &bb2, /* fall through */
>>
>> &bb2, /* merge point */
>>
>> &bb0 /* New predecessor */);
>> reset_count = gimple:new_store_insn (..., bb1, insert_before);
>>
>>
>> If the current APIs are used to do the coding, it will take how X
>> times more API calls which is non-readable for human beings.
>
> The above is non-readable to me neither.  That we miss a helper
> to do the split-the-cfg-here-with-a-conditional-branch-and-bbs-for-true-false
> does not mean that such helper has to use whatever fancy C++ interface.
> What's wrong with a C helper for the above?  Why is it easier in C++ at all?

yes -- I lumped two things together. I care about the high level APIs
more than I care about C++.


>
> And you want to contribute the 10+ man years to consistently(!) transition
> GCC to such API?
>

Transitioning to wrapper APIs above is certainly worth the effort. It
make GCC code lean and mean. Currently there are lots of code
duplication with cut&paste.


> Sorry, but you cannot magically transform GCC to something more modern.
> Thus it will be isolated "leaf" modules that will see conversion.  I don't hold
> my breath for even converting the gimple bits, not to even think about trees
> (or RTL).
>
> Sorry.

No need to be sorry.  I don't see it happening magically either. If it
needs to be done, it will be carefully designed and incremental.

thanks,

David

>
> Richard.
>
>>
>> thanks,
>>
>> David
>>
>>>
>>>> I also find debugging C++ in gdb somewhat more annoying than debugging
>>>> plain C, and at the moment I always go back to a stage1 compiler.
>>>
>>> Indeed - I'd be worried if my debugging efficiency decreases by more than 5%.
>>>
>>> Richard.

Re: Switching to C++ by default in 4.8

[Chiheng Xu]

On Wed, Apr 4, 2012 at 8:04 PM, Richard Guenther
<richard.guenther@gmail.com> wrote:
>
> I agree for the idea of converting all of GCC to C++ (whatever that means).
> I disagree for the part making the internal infrastructure easier to use,
> understand and maintain.  Which means targeting mostly isolated sub-systems,
> like vec.h (and other various containers), double-int.[ch] (and other various
> way of representing and working with constants).  Making tree or gimple a
> C++ class with inheritance and whatever is indeed a huge waste of time
> and existing developer ressources (that, if only because they have to adapt
> and maintain two completely different code-bases over some time).
>
> I expect the GCC core to maintain written in C, compiled by C++.
>

Making tree or gimple or even rtl a C++ class with inheritance should be easy.

Current functions and accessor macros can be preserved.

for example:

C:

typedef struct base_type_tag {
     int m_data_1;
} base_type;

typedef struct derived_type_tag {
     struct base_type base;
     int m_data_2;
} derived_type;

#define BASE_TYPE_ACCESSOR_MACRO_1(a)   ...
#define DERIVED_TYPE_ACCESSOR_MACRO_2(a)   ...

int base_type _func_1(base_type * p_base, ...)
{
}

int derived_type_func_2(derived_type * p_derived, ...)
{
}


C++:

class base_type {
     int m_data_1;
     getter_1();
     setter_1();
     method_1();
};

class derived_type : public base_type {
     int m_data_2;
     getter_2();
     setter_2();
     method_2();
};


#define BASE_TYPE_ACCESSOR_MACRO_1(a)   ...
#define DERIVED_TYPE_ACCESSOR_MACRO_2(a)   ...

int base_type _func_1(base_type * p_base, ...)
{
}

int derived_type_func_2(derived_type * p_derived, ...)
{
}

base_type::getter_1()
{
}

base_type::setter_1()
{
}

base_type::method_1()
{
}

derived_type::getter_2()
{
}

derived_type::setter_2()
{
}

derived_type::method_2()
{
}


-- 
Chiheng Xu

Re: Switching to C++ by default in 4.8

[Diego Novillo]

On 4/3/12 9:13 PM, David Edelsohn wrote:

> I appreciate the motivation, but this may cause major problems on
> non-GNU/Linux platforms.  Testing on all primary targets is not
> enough.

I can test on other targets, as well.  What targets do you have in mind? 
  If I don't have access to them, I'll need volunteers to test my patch.


Diego.

Re: Switching to C++ by default in 4.8

[Tristan Gingold]

On Apr 3, 2012, at 7:37 PM, Diego Novillo wrote:

> 
> We would like to start the process to make GCC 4.8 build in C++ mode by default.
> 
> The mechanics of the change are simple enough.  I volunteer to test changing the default on all primary targets (assuming I can get them from the GCC build farm).

Is it already possible to build stage1 with c++ ?

The VMS targets are not yet ready with build in C++ mode.  This target is somewhat special because it can be built only with a cross-compiler (we don't support regular 3 stages native builds because there is no complete and working well enough UNIX emulation tools).

I started to build g++ (and gfortran) for ia64 and alpha VMS in order to prepare this transition, but having a soft path would be better to me.


(Clearly VMS is not a blocking target for the GCC community - that's not the point).

Tristan.

Re: Switching to C++ by default in 4.8

[Ian Lance Taylor]

Tristan Gingold <gingold@adacore.com> writes:

> On Apr 3, 2012, at 7:37 PM, Diego Novillo wrote:
>
>> 
>> We would like to start the process to make GCC 4.8 build in C++ mode by default.
>> 
>> The mechanics of the change are simple enough.  I volunteer to test changing the default on all primary targets (assuming I can get them from the GCC build farm).
>
> Is it already possible to build stage1 with c++ ?

Yes.  There are two relevant configure options: --enable-build-with-cxx
and --enable-build-poststage1-with-cxx.  Currently the first defaults to
no and the second defaults to yes.  The change in question would be
making the first default to yes.


> The VMS targets are not yet ready with build in C++ mode.  This target
> is somewhat special because it can be built only with a cross-compiler
> (we don't support regular 3 stages native builds because there is no
> complete and working well enough UNIX emulation tools).
>
> I started to build g++ (and gfortran) for ia64 and alpha VMS in order
> to prepare this transition, but having a soft path would be better to
> me.

Sounds like you would need to have a C++ cross-compiler for VMS.  What
are the issues with making that work?

Ian

Re: Switching to C++ by default in 4.8

[Tristan Gingold]

On Apr 4, 2012, at 3:12 PM, Ian Lance Taylor wrote:

> Tristan Gingold <gingold@adacore.com> writes:
> 
>> On Apr 3, 2012, at 7:37 PM, Diego Novillo wrote:
>> 
>>> 
>>> We would like to start the process to make GCC 4.8 build in C++ mode by default.
>>> 
>>> The mechanics of the change are simple enough.  I volunteer to test changing the default on all primary targets (assuming I can get them from the GCC build farm).
>> 
>> Is it already possible to build stage1 with c++ ?
> 
> Yes.  There are two relevant configure options: --enable-build-with-cxx

Ah thanks, I missed this option.

> and --enable-build-poststage1-with-cxx.  Currently the first defaults to
> no and the second defaults to yes.  The change in question would be
> making the first default to yes.
> 
> 
>> The VMS targets are not yet ready with build in C++ mode.  This target
>> is somewhat special because it can be built only with a cross-compiler
>> (we don't support regular 3 stages native builds because there is no
>> complete and working well enough UNIX emulation tools).
>> 
>> I started to build g++ (and gfortran) for ia64 and alpha VMS in order
>> to prepare this transition, but having a soft path would be better to
>> me.
> 
> Sounds like you would need to have a C++ cross-compiler for VMS.  What
> are the issues with making that work?

For ia64, g++ is working on simple examples (and for the testsuite).  But building gcc will be a better test.

For Alpha, gas crashes during libstdc++ build.  From initial investigation, this looks manageable.  But Alpha object format is quite old, and has no support for comdat (but weak symbols should work).  I only have worked on g++ for Alpha for a few days.

Tristan.

Re: Switching to C++ by default in 4.8

[Gabriel Dos Reis]

On Wed, Apr 4, 2012 at 8:32 AM, Tristan Gingold <gingold@adacore.com> wrote:

> For Alpha, gas crashes during libstdc++ build.  From initial investigation, this looks manageable.  But Alpha object format is quite old, and has no support for comdat (but weak symbols should work).

I believe weak symbols should suffice, if the object file does not have comdat.

-- Gaby

Re: Switching to C++ by default in 4.8

[Tristan Gingold]

On Apr 4, 2012, at 4:37 PM, Gabriel Dos Reis wrote:

> On Wed, Apr 4, 2012 at 8:32 AM, Tristan Gingold <gingold@adacore.com> wrote:
> 
>> For Alpha, gas crashes during libstdc++ build.  From initial investigation, this looks manageable.  But Alpha object format is quite old, and has no support for comdat (but weak symbols should work).
> 
> I believe weak symbols should suffice, if the object file does not have comdat.

That's also my understanding from reading various gcc pieces.  But these features (aliases and weak) was never well-tested in the Alpha VMS case.

Tristan.