Thanks; I've committed it to trunk as r201552.
On Tue, 2013-08-06 at 14:53 -0700, Mike Stump wrote:
> Ok.
>
> On Aug 6, 2013, at 3:43 AM, Dominique Dhumieres wrote:
> >> Hence plugins that create passes will need to be built with RTTI
> >> disabled in order to link against gcc, or they will fail
Ok.
On Aug 6, 2013, at 3:43 AM, Dominique Dhumieres wrote:
>> Hence plugins that create passes will need to be built with RTTI
>> disabled in order to link against gcc, or they will fail to load, with
>> an error like: ...
>
> The same holds for darwin, hence the following patch is needed:
>
>
On Tue, 2013-08-06 at 12:43 +0200, Dominique Dhumieres wrote:
> > Hence plugins that create passes will need to be built with RTTI
> > disabled in order to link against gcc, or they will fail to load, with
> > an error like: ...
>
> The same holds for darwin, hence the following patch is needed:
>
> Hence plugins that create passes will need to be built with RTTI
> disabled in order to link against gcc, or they will fail to load, with
> an error like: ...
The same holds for darwin, hence the following patch is needed:
--- ../_clean/gcc/testsuite/lib/plugin-support.exp 2013-08-05
22:5
On 07/26/2013 09:04 AM, David Malcolm wrote:
With the conversion of passes to C++ classes, plugins that add custom
passes must create them by creating their own derived classes of the
relevant subclass of opt_pass. gcc itself is built with -fno-rtti,
hence there is no RTTI available for the opt_
With the conversion of passes to C++ classes, plugins that add custom
passes must create them by creating their own derived classes of the
relevant subclass of opt_pass. gcc itself is built with -fno-rtti,
hence there is no RTTI available for the opt_pass class hierarchy.
Hence plugins that creat
