I've just opened a pull request for -fno-rtti at [1]. The frontend part
needs to go into DMD but I'd like some testing feedback first. This is
especially important as I had literally no time to test this
updated code ;-) Please provide feedback here or at [1].


-fno-rtti should provide nice, readable error messages:
test.d:22:14: error: Can't use typeid: TypeInfo disabled using
-fno-rtti switch.
     auto a = typeid(A);
              ^
It's however likely that I missed some cases. If you get linker errors
or a backend ICE instead of a nice error message please report that.



This also prevents the frontend from searching for TypeInfo in object.d which means you can remove those useless fake declarations. A minimal object.d now looks like this:
------------
module object;

class Object
{
}
------------
It can also be empty if you don't need support for classes. If GDC still complains about missing TypeInfo please report that.


Note: right now the -fno-rtti switch is not hooked up with -fno-emit-moduleinfo. So you'll probably want all 'fno-invariants -fno-rtti -fno-emit-moduleinfo' options.

[1] https://github.com/D-Programming-GDC/GDC/pull/100

On Sunday, 10 May 2015 at 17:45:30 UTC, Johannes Pfau wrote:
> I've just opened a pull request for -fno-rtti at [1]. The frontend part
> needs to go into DMD but I'd like some testing feedback first. This is
> especially important as I had literally no time to test this
> updated code ;-) Please provide feedback here or at [1].
>

Thanks for doing this!

I tested my LCD demo and I get the following errors,

Compiler command
----------------
arm-none-eabi-gdc -c -O3 -nophoboslib -nostdinc -nodefaultlibs -nostdlib -mthumb -mcpu=cortex-m4 -fno-bounds-check -fno-invariants -fno-in -fno-out -fno-emit-moduleinfo -fno-rtti -ffunction-sections -fdata-sections {some_imports} {my_source_files} -o binary/firmware.o

Compiler output
---------------
source/stm32f42/trace.d:58:5: error: Can't use array literal: TypeInfo disabled using -fno-rtti switch.
     [
     ^
cc1d: error: Can't use typeid: TypeInfo disabled using -fno-rtti switch.
source/gcc/attribute.d:10:12: error: template instance gcc.attribute.Attribute!string error instantiating
     return Attribute!A(args);
            ^
source/gcc/attribute.d:13:45: note: instantiated from here: attribute!(string)
 public enum inline = gcc.attribute.attribute("forceinline");


Here's the code causing the error
---------------------------------

https://github.com/JinShil/stm32f42_discovery_demo/blob/master/source/stm32f42/trace.d#L57
private void semihostingWrite(in void* ptr, in uint length)
{
  uint[3] message = [ 2, cast(uint)ptr, length];  // line 58
  semihostingInvoke(0x05, &message);
}

// attribute.d
/*************/
private struct Attribute(A...)
{
  A args;
}

https://github.com/JinShil/stm32f42_discovery_demo/blob/master/source/gcc/attribute.d
auto attribute(A...)(A args) if(A.length > 0 && is(A[0] == string))
{
  // line 10
  return Attribute!A(args);
}

//line 13
public enum inline = gcc.attribute.attribute("forceinline");
public enum naked = gcc.attribute.attribute("naked");


Without the -fno-rtti switch, everything builds fine.

Mike

Am Mon, 11 May 2015 12:20:46 +0000
schrieb "Mike" <none@none.com>:

> On Sunday, 10 May 2015 at 17:45:30 UTC, Johannes Pfau wrote:
> > I've just opened a pull request for -fno-rtti at [1]. The
> > frontend part
> > needs to go into DMD but I'd like some testing feedback first.
> > This is
> > especially important as I had literally no time to test this
> > updated code ;-) Please provide feedback here or at [1].
> >
> 
> Thanks for doing this!
> 
> I tested my LCD demo and I get the following errors,
> 
> Compiler command
> ----------------
> arm-none-eabi-gdc -c -O3 -nophoboslib -nostdinc -nodefaultlibs -nostdlib -mthumb -mcpu=cortex-m4 -fno-bounds-check -fno-invariants -fno-in -fno-out -fno-emit-moduleinfo -fno-rtti -ffunction-sections -fdata-sections {some_imports} {my_source_files} -o binary/firmware.o
> 
> Compiler output
> ---------------
> source/stm32f42/trace.d:58:5: error: Can't use array literal:
> TypeInfo disabled using -fno-rtti switch.
>       [
>       ^
I really need to make that test smarter. Static array init of course
doesn't require TypeInfo. As a workaround you could remove this check:
https://github.com/D-Programming-GDC/GDC/pull/100/files#diff-5960d486a42197785b9eee4ba95c6b95L4082

> cc1d: error: Can't use typeid: TypeInfo disabled using -fno-rtti
> switch.
> source/gcc/attribute.d:10:12: error: template instance
> gcc.attribute.Attribute!string error instantiating
>       return Attribute!A(args);
>              ^
> source/gcc/attribute.d:13:45: note: instantiated from here:
> attribute!(string)
>   public enum inline = gcc.attribute.attribute("forceinline");
> 

Strange. I'll debug this later this week.

> 
> Here's the code causing the error
> ---------------------------------
> 
> https://github.com/JinShil/stm32f42_discovery_demo/blob/master/source/stm32f42/trace.d#L57
> private void semihostingWrite(in void* ptr, in uint length)
> {
>    uint[3] message = [ 2, cast(uint)ptr, length];  // line 58
>    semihostingInvoke(0x05, &message);
> }
> 
> // attribute.d
> /*************/
> private struct Attribute(A...)
> {
>    A args;
> }
> 
> https://github.com/JinShil/stm32f42_discovery_demo/blob/master/source/gcc/attribute.d
> auto attribute(A...)(A args) if(A.length > 0 && is(A[0] ==
> string))
> {
>    // line 10
>    return Attribute!A(args);
> }
> 
> //line 13
> public enum inline = gcc.attribute.attribute("forceinline");
> public enum naked = gcc.attribute.attribute("naked");
> 
> 
> Without the -fno-rtti switch, everything builds fine.
> 
> Mike

Am Mon, 11 May 2015 12:20:46 +0000
schrieb "Mike" <none@none.com>:

> source/stm32f42/trace.d:58:5: error: Can't use array literal:
> TypeInfo disabled using -fno-rtti switch.
>       [
>       ^
> cc1d: error: Can't use typeid: TypeInfo disabled using -fno-rtti
> switch.
> source/gcc/attribute.d:10:12: error: template instance
> gcc.attribute.Attribute!string error instantiating
>       return Attribute!A(args);
>              ^

The compiler was still building the xopEquals and xopCMP functions. These use TypeInfo internally but they're also only accessible through TypeInfo. Solution: We should not generate these functions with -fno-rtti. Bonus points: You don't need _xopEquals in object.d anymore.


The array error should also be fixed. I've updated the pull
request so you can give it another try.
Thanks for the testing feedback!

On Thursday, 14 May 2015 at 15:21:46 UTC, Johannes Pfau wrote:
            ^
>
> The compiler was still building the xopEquals and xopCMP functions.
> These use TypeInfo internally but they're also only accessible through
> TypeInfo. Solution: We should not generate these functions with
> -fno-rtti. Bonus points: You don't need _xopEquals in object.d anymore.
>
>
> The array error should also be fixed. I've updated the pull
> request so you can give it another try.

I tested again with the latest changes.  Removing the TypeInfo faking reduced my runtime implementation to essentially nothing _d_run_main and a few aliases.  My demo builds fine and the resulting binary went from 459k to 6k.  The binary also executes as expected, and with such a small binary, I can flash my hardware is less than 500ms.

My test is not very thorough, though, as I intentionally use very little of the language, but this feature is really a great enabler for me, and I think we'll have what we need to make a minimal runtime and toolchain package for C-like bare-metal programming in D.

Thanks for the great work.  If there's anything more I can do to move this progress forward, please let me know.

Mike