-ffreestanding option

[Johannes Pfau via D.gnu]

Am Tue, 05 May 2015 11:37:17 +0000
schrieb "Mike" <none at none.com>:

> So, perhaps in my ignorance, I have to say that I don't need a
> -ffreestanding option, but I don't consider myself much of an
> expert in this field.  If you know of a need for the
> -ffreestanding option, please let it be known.
> 
> What I really need is more granular control of the language
> features, either by adding compiler switches, or delegating
> implementation to the runtime.  My dream would be to have runtime
> .di files inform the compiler what the language features look
> like, and have the compiler use that information to generate
> optimized code or compiler errors if the runtime doesn't provide
> what everything compiler needs.

Isn't this simply two ways of looking at the same thing? You want to
disable language features (I guess mostly those requiring runtime
hooks), -ffreestanding disables all these features.

I realize you want fine-grained control. But then:

-ffreestanding:
   -fno-exceptions
   -fno-rtti
   -fno-gc
   -fno-invariants
   -fno-moduleinfo
   -fno-string-switch
   -fno-utf-support (foreach over utf strings)
   -fno-boundscheck
   -fno-switch-error

From an implementation point of view these are the same and
fine-grained switches are easy to support.

Access using .di is then simple to add as well. If the compiler is
clever it can look if the required features/hooks are implemented. This
requires some compiler work. Simpler alternative: Enum values in
special d module (e.g. rt.config) enum RUNTIME_SUPPORTS_GC = false;

> 
> At the moment, the most pressing issue for me is the phony
> support I have to add for TypeInfo and the removal of dead code
> (or lack there of) due to GCC bug 192.  Some binaries I've
> created are so full of TypeInfo stuff that I can't even get them
> to fit in my MCU's flash memory for testing and debugging.  Not
> to mention the added upload time it takes, diminishing the
> efficiency of my development cycle.

I'll implement fno-rtti next weekend. We can think about more
fine-grained solutions in the future but fno-rtti should be a good
start.

> I remember from previous discussions that there was work to be
> done in binutils to get better LTO and dead-code removal.  I'd be
> interested in hearing more details about that too.
> 
> Thanks for the continued support,
> 
> Mike