[MLton] rounding modes and minimum gcc version

Matthew Fluet fluet at tti-c.org
Sun Apr 19 05:09:59 PDT 2009

On Sat, 18 Apr 2009, Adam Goode wrote:
> On 04/18/2009 11:15 PM, Matthew Fluet wrote:
>> On Sat, 18 Apr 2009, Adam Goode wrote:
>>> Looking into IEEE rounding mode stuff more, it looks like for gcc, if
>>> the rounding mode is going to be changed, then -frounding-math must be
>>> set, or else behavior is undefined. Otherwise, gcc could perform
>>> constant folding assuming the default rounding mode. I believe all of
>>> the runtime and anything compiled with the C backend must have this flag
>>> (but only if the rounding mode is actually ever changed from SML, is it
>>> easy to tell?).
>> I don't think this is necessary; do you have an example program that
>> exhibits a bug?
> No, I'm not seeing a particular bug, just in working on fixing up some ARM
> rounding mode bugs was told that "If you don't use -frounding-math (or the
> pragma) you are guaranteeing that code in the object will only ever execute
> with the default rounding mode."
> http://sourceware.org/ml/libc-ports/2009-04/msg00020.html
> Here is the gcc option:
> http://gcc.gnu.org/onlinedocs/gcc-4.3.3/gcc/Optimize-Options.html#index-frounding_002dmath-744
> And C99 says:
> "If part of a program tests floating-point status flags, sets
> floating-point control modes, or runs under non-default mode settings,
> but was translated with the state for the FENV_ACCESS pragma ÿÿÿÿoffÿÿÿÿ,
> the behavior is undefined."
> -frounding-math sets the default for FENV_ACCESS (which is otherwise
> unimplemented in gcc), and so if you try to read or set the rounding
> mode without -frounding-math, C99 allows for arbitrary behavior. I know
> this is silly, but why not set the option?

I guess there is no real harm.


More information about the MLton mailing list