Am Thu, 30 Apr 2015 14:27:15 +0000
schrieb "Jens Bauer" <doctor@who.no>:

> I was wondering... Would it be possible to make selective
> TypeInfo ?
> -Eg. Only add TypeInfo for those things that really need it.

'really need it' is quite subjective. IIRC TypeInfo is mostly used for GC, AA and sometimes arrays. You won't use most of this anyway and you can still use a library template base Array/AA so this is easy to avoid. TypeInfo is also required for type-safe runtime variadics. Nobody uses these.

I think one place where you really need it is downcasting class objects. But you only need a small subset of class TypeInfo for that.

> Am Thu, 30 Apr 2015 14:27:15 +0000
> schrieb "Jens Bauer" <doctor@who.no>:
>> I was wondering... Would it be possible to make selective TypeInfo ?
>> -Eg. Only add TypeInfo for those things that really need it.
>
{snip}
On Thursday, 30 April 2015 at 19:24:14 UTC, Johannes Pfau wrote:
> I think one place where you really need it is downcasting class objects.

Casting was what I was thinking of, because when I needed to do a dynamic_cast in C++, I only needed it for one, maybe two classes.
Thus if being able to enable it selectively for one out of 10 classes, it might help on the memory footprint.

On Thursday, 15 January 2015 at 12:01:05 UTC, Johannes Pfau wrote:
>
> After some google-fu:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=192
> Considering this was filed in 2000 I'd say it's not very likely to get
> fixed soon :-(
>
> So the best option is probably to get rid of this problem by patching
> the compiler (@notypeinfo or -fnortti).

Looks like someone picked up on this and submitted a patch:  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=192#c9   Cool!!  But I still have yet to test it.

-fnortti would still be most welcome.

Mike

On Sunday, 10 May 2015 at 09:54:51 UTC, Mike wrote:

> Looks like someone picked up on this and submitted a patch:  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=192#c9   Cool!!  But I still have yet to test it.

Damn!  Didn't work.

On 10 May 2015 at 14:48, Mike via D.gnu <d.gnu@puremagic.com> wrote:
> On Sunday, 10 May 2015 at 09:54:51 UTC, Mike wrote:
>
>> Looks like someone picked up on this and submitted a patch: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=192#c9   Cool!!  But I still have yet to test it.
>
>
> Damn!  Didn't work.
>

Not sure what you're using to build, but it seems reliant on -ffunction-sections -fdata-sections -fmerge-constants - or at least the latter two of those options.

Did you try the minimum test in the PR?

On Sunday, 10 May 2015 at 13:20:42 UTC, Iain Buclaw wrote:
>
> Not sure what you're using to build, but it seems reliant on
> -ffunction-sections -fdata-sections -fmerge-constants - or at least
> the latter two of those options.
>
> Did you try the minimum test in the PR?

I'm using the cross-compiler built with this script:  https://github.com/JinShil/arm-none-eabi-gdc/blob/master/arm-none-eabi-gdc.sh

I compiled with -ffunction-sections -fdata-sections -fmerge-constants, and a few other variants.  I link with --gc-sections.

For a test program, I'm using my LCD demo here:  https://github.com/JinShil/stm32f42_discovery_demo

The only way I can get a minimal binary is to compile to assembly, use this sed hack (https://github.com/JinShil/stm32f42_discovery_demo/blob/master/build.d#L69) to put strings into their own section, and then compile the modified assembly.

Without the sed hack, my binary is 450k.  With the sed hack it's 6k.

The binary seems to fill .rodata with the TypeInfo.name field.  Here's a small sample of what that looks like in the binary:

 801fa00 6572616c 2e526567 69737465 72212830  eral.Register!(0
 801fa10 2c206361 73742841 63636573 73293729  , cast(Access)7)
 801fa20 2e526567 69737465 722e4269 74212831  .Register.Bit!(1
 801fa30 312c2063 61737428 4d757461 62696c69  1, cast(Mutabili
 801fa40 74792932 292e4269 74000000 6d6d696f  ty)2).Bit...mmio
 801fa50 2e506572 69706865 72616c21 28414842  .Peripheral!(AHB
 801fa60 312c2031 35333630 292e5065 72697068  1, 15360).Periph

Those are the types instantiated with my mmio template library.  Here's a sample:  https://github.com/JinShil/stm32f42_discovery_demo/blob/master/source/stm32f42/flash.d

It appears the TypeInfo.name field is not put into its own section even though I compile with -fdata-sections.  I guess I'll have to inspect the binary compiled with the patch to see what's happening.

Mike

On Sunday, 10 May 2015 at 12:48:55 UTC, Mike wrote:
> On Sunday, 10 May 2015 at 09:54:51 UTC, Mike wrote:
>
>> Looks like someone picked up on this and submitted a patch:  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=192#c9   Cool!!  But I still have yet to test it.
>
> Damn!  Didn't work.

Bug report submitted here: http://bugzilla.gdcproject.org/show_bug.cgi?id=184