Am Wed, 06 May 2015 02:44:53 +0000 schrieb "Mike" <n...@none.com>:
> On Tuesday, 5 May 2015 at 17:27:05 UTC, Johannes Pfau wrote: > > Am Tue, 05 May 2015 08:41:13 -0700 > > schrieb Dan Olson <zans.is.for.c...@yahoo.com>: > > > >> Iain Buclaw via Digitalmars-d <digitalmars-d@puremagic.com> > >> writes: > >> > >> > If the cost is too much (ie: there is no heap), then we > >> > should be > >> > able to stop emutls from kicking in by preventing the D > >> > frontend > >> > from returning true on isThreadLocal calls. > >> > >> Iain, I think something like this would be good in GDC. Makes > >> it so > >> much easier to compile for no thread environments. > > > > I'm not really sure about this. It's trivial to implement but it > > generates a semantic difference which harms code portability > > (e.g. if > > you have code where you want a global variable, don't mark it as > > __gshared and then move to an environment with threads). > > I'm coming around and feeling inclined to agree with this. One > of the things I want to avoid is creatIng an embedded dialect of > the D. I hope D for microcontrollers, kernels and such looks > very much like the idiomatic D in the application programming > domain. > > What I would like to see, however, is a friendly compiler error > like "This platform does not support thread-local storage. > Please decorate your global variables with __gshared." rather > than "undefined reference '_d_get_address'" from the linker. > > > Mike That's easy: https://github.com/D-Programming-microD/GDC/commit/d5677e03f40f4eb548e520728c5071a0b4445d24 (Well, the error message could be a little bit friendlier ;-)
