On 28 January 2014 13:25, Johannes Pfau <nospam@example.com> wrote:
> Am Tue, 28 Jan 2014 13:10:52 +0000
> schrieb Iain Buclaw <ibuclaw@gdcproject.org>:
>
>> On 28 January 2014 02:27, Daniel Murphy <yebbliesnospam@gmail.com> wrote:
>> >> I would have to seriously consider keeping or forking cppmangle once it is visual studio-afied....
>> >
>> >
>> > It should be trivial to let Target choose the mangler.
>>
>> That isn't half the point.  Anyway, I've had some plans with cppmangler for sometime now.
>
> Somehow sounds like you want to hook into the g++ frontend to do the mangling?

Nah... Keep the same implementation. I was thinking more along the lines of using bells and whistles that are GDC specific.  For example: targetm.mangle_type - which is needed if we want compatible C++ mangling on ARM for va_list or vector types.

As for g++ frontend mangle.c, we would require having some form of -fabi-version=n switch; which is a bit exper.  And besides I don't feel like satisfying the need of some lone guy out there who requires C++ mangling ABI greater than v.3 from D.

Regards
Iain

Am Tue, 28 Jan 2014 16:00:50 +0000
schrieb Iain Buclaw <ibuclaw@gdcproject.org>:

> > Somehow sounds like you want to hook into the g++ frontend to do the mangling?
> 
> Nah... Keep the same implementation. I was thinking more along the lines of using bells and whistles that are GDC specific.  For example: targetm.mangle_type - which is needed if we want compatible C++ mangling on ARM for va_list or vector types.
> 
> As for g++ frontend mangle.c, we would require having some form of -fabi-version=n switch; which is a bit exper.  And besides I don't feel like satisfying the need of some lone guy out there who requires C++ mangling ABI greater than v.3 from D.
> 
> Regards
> Iain

That sounds reasonable. I had a quick look on how difficult it is to hook into another frontend in GCC some time ago and IIRC it's almost impossible so I was kinda surprised.