On 2 July 2014 12:42, via Digitalmars-d <digitalmars-d@puremagic.com> wrote: > On Wednesday, 2 July 2014 at 08:52:25 UTC, Iain Buclaw via Digitalmars-d > wrote: >> >> The crucial thing here is that the layout of float/double types are >> IEEE 754 are compatible. :) > > > That's nice of course, if you import/export, but hardly the only crucial > thing. > > Implied correctness and warnings when assumptions break is also important… > > >> These behaviours you describe only affect the FP control functions in >> std.math, which are the only thing platform specific, and can only be >> written in inline assembly anyway... > > > It affects the backend.
Only matters if you have to implement it in your backend > It affects vectorization. (NEON is not IEEE754 AFAIK) Vectors are treated differently from floats > It affects what a conforming D compiler is allowed to do. That depends what you mean be 'conforming'. > It affects versioning. > > E.g. you can have a flags IEEE754_STRICT or IEE754_HAS_NAN etc and use > versioning that dectects the wrong compiler-mode. Affects only library maintainers, but I haven't looked too much into what gcc offers as a platform regarding this. The ARM market is terrible, and it will certainly be the case that we *can't* have a one size fits all solution. But in the standard libraries we can certainly keep strictly in line with the most conforming chips, so if you wish to support X you may do so in a platform-specific fork. This is certainly not unusual for druntime (eg: minilibd) Regards Iain