Am Tue, 05 May 2015 11:37:17 +0000 schrieb "Mike" <n...@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
