On Wednesday, 2 July 2014 at 16:03:47 UTC, Iain Buclaw via
Digitalmars-d wrote:
Only matters if you have to implement it in your backend
You have to implement it in the backend if D requires strict
IEEE754 conformance?
Vectors are treated differently from floats
How can you then let the compiler vectorize? You can't. Meaning,
your code will run very slow.
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.
I don't agree. If your code produce denormal numbers then it
matters a lot if they are forced to zero or not. Just think about
divison by zero traps. Why would this only be a library issue?
If you write portable code you shouldn't have to second guess
what the compiler does. It either guarantees that denormal
numbers are not flushed to zero, or it does not. If it does not
then D does not require IEEE754 and you will have to think about
this when you write your code.
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.
I don't really understand the reasoning here. Is D Intel x86
specific? Meaning, it is a system level programming language on
x86 only and something arbitrary on other platforms?
Either D requires IEEE754 strict mode, or it does not. It matters
what the default is.
