This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Switching to C++ by default in 4.8

On Wed, Apr 4, 2012 at 11:59 AM, Richard Guenther
<> wrote:
> On Wed, Apr 4, 2012 at 11:15 AM, Gabriel Dos Reis
> <> wrote:
>> On Wed, Apr 4, 2012 at 4:06 AM, Richard Guenther
>> <> wrote:
>>> On Wed, Apr 4, 2012 at 10:32 AM, Gabriel Dos Reis
>>> <> wrote:
>>>> On Tue, Apr 3, 2012 at 8:13 PM, David Edelsohn <> wrote:
>>>>> On Tue, Apr 3, 2012 at 1: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).
>>>>> 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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]