On Fri, 19 Sep 2014, Joseph S. Myers wrote:
> On Thu, 18 Sep 2014, Joseph S. Myers wrote:
>
> > On Thu, 18 Sep 2014, Uros Bizjak wrote:
> >
> > > OK for mainline and release branches.
> >
> > I've omitted ia64 from the targets in the testcase in the release branch
> > version, given the lack o
On Thu, 18 Sep 2014, Joseph S. Myers wrote:
> On Thu, 18 Sep 2014, Uros Bizjak wrote:
>
> > OK for mainline and release branches.
>
> I've omitted ia64 from the targets in the testcase in the release branch
> version, given the lack of any definition of FP_TRAPPING_EXCEPTIONS at all
> there.
>
On Thu, 18 Sep 2014, Uros Bizjak wrote:
> OK for mainline and release branches.
I've omitted ia64 from the targets in the testcase in the release branch
version, given the lack of any definition of FP_TRAPPING_EXCEPTIONS at all
there.
(I think a definition as (~_fcw & 0x3f) should work for ia6
On Wed, Sep 17, 2014 at 9:47 PM, Joseph S. Myers
wrote:
> The i386 sfp-machine.h defines FP_TRAPPING_EXCEPTIONS in a way that is
> always wrong: it treats a set bit as indicating the exception is
> trapping, when actually a set bit (both for 387 and SSE floating
> point) indicates it is masked, an
The i386 sfp-machine.h defines FP_TRAPPING_EXCEPTIONS in a way that is
always wrong: it treats a set bit as indicating the exception is
trapping, when actually a set bit (both for 387 and SSE floating
point) indicates it is masked, and a clear bit indicates it is
trapping. This patch fixes this bu