On Wed, 2 Nov 2016, James Greenhalgh wrote:
> OK, I've reworked the patch along those lines. I noticed that the original
> logic looked for
>
> && TARGET_FLT_EVAL_METHOD != 0
>
> And I no longer make that check. Is that something I need to reinstate?
No, the replacement logic should imply
On Fri, Oct 28, 2016 at 09:09:55PM +, Joseph Myers wrote:
> On Fri, 14 Oct 2016, James Greenhalgh wrote:
>
> > +/* If the join of the implicit precision in which the target will compute
> > + floating-point values and the standard precision in which the target
> > will
> > + compute value
On Fri, 14 Oct 2016, James Greenhalgh wrote:
> +/* If the join of the implicit precision in which the target will compute
> + floating-point values and the standard precision in which the target will
> + compute values is not equal to the standard precision, then the target
> + is either unp
On Fri, Sep 30, 2016 at 05:32:01PM +, Joseph Myers wrote:
> On Fri, 30 Sep 2016, James Greenhalgh wrote:
>
> >/* float.h needs to know this. */
> > + /* We already have the option -fno-fp-int-builtin-inexact to ensure
> > + certain built-in functions follow TS 18661-1 semantics. It
On Fri, 30 Sep 2016, James Greenhalgh wrote:
>/* float.h needs to know this. */
> + /* We already have the option -fno-fp-int-builtin-inexact to ensure
> + certain built-in functions follow TS 18661-1 semantics. It might be
> + reasonable to have a new option to enable FLT_EVAL_METH
