This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Switching to C++ by default in 4.8
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