Movatterモバイル変換

This is the mail archive of thelibc-alpha@sourceware.orgmailing list for theglibc project.

Re: [PATCH 3/4] Add ILP32 support to aarch64

• From: Steve Ellcey <sellcey at cavium dot com>
• To: Joseph Myers <joseph at codesourcery dot com>
• Cc: libc-alpha <libc-alpha at sourceware dot org>
• Date: Thu, 03 Aug 2017 11:22:26 -0700
• Subject: Re: [PATCH 3/4] Add ILP32 support to aarch64
• Authentication-results: sourceware.org; auth=none
• Authentication-results: spf=none (sender IP is ) smtp.mailfrom=Steve dot Ellcey at cavium dot com;
• References: <1501774579.3962.54.camel@cavium.com> <alpine.DEB.2.20.1708031744530.24143@digraph.polyomino.org.uk>
• Reply-to: sellcey at cavium dot com
• Spamdiagnosticmetadata: NSPM
• Spamdiagnosticoutput: 1:99

On Thu, 2017-08-03 at 17:47 +0000, Joseph Myers wrote:> On Thu, 3 Aug 2017, Steve Ellcey wrote:> > > > > +#if OREG_SIZE == 32> > +  /* The rounding step may set FE_INEXEXACT and converting to a 32> > bit> > +     value may set FE_INVALID.  We do not want FE_INEXACT set when> > +     FE_INVALID has been set.  */> > +  if (libc_fetestexcept_aarch64 (FE_INVALID))> > +    libc_feclearexcept_aarch64 (FE_INEXACT);> > +#endif> This sort of thing is never correct, because it would clear an> "inexact" > exception that was already set on entry to the function, and> functions > other than <fenv.h> specified to do so should never clear already-> raised > exceptions.> > (Also, typo "FE_INEXEXACT".)I hadn't considered that.  So maybe I could save the environment(feholdexcept), do the calculation and see which exceptions, if any,got raised.  Then restore the original environment (fesetenv) and raiseone or the other exceptions if needed.  Does that sound like a workablesolution?Steve Ellceysellcey@cavium.com

• Follow-Ups:
  • Re: [PATCH 3/4] Add ILP32 support to aarch64
    • From: Joseph Myers

• References:
  • [PATCH 3/4] Add ILP32 support to aarch64
    • From: Steve Ellcey
  • Re: [PATCH 3/4] Add ILP32 support to aarch64
    • From: Joseph Myers