On Wed, Apr 4, 2012 at 11:15 AM, Gabriel Dos Reis
<g...@integrable-solutions.net> wrote:
> On Wed, Apr 4, 2012 at 4:06 AM, Richard Guenther
> <richard.guent...@gmail.com> wrote:
>> On Wed, Apr 4, 2012 at 10:32 AM, Gabriel Dos Reis
>> <g...@integrable-solutions.net> wrote:
>>> On Tue, Apr 3, 2012 at 8:13 PM, David Edelsohn <dje....@gmail.com> wrote:
>>>> On Tue, Apr 3, 2012 at 1:37 PM, Diego Novillo <dnovi...@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
