On Thu, 11 Oct 2018, Wilco Dijkstra wrote:
> Hi,
>
> > Note that "will ever set errno" includes possibly setting it in the
> > future, since code may be built with one libm version and used with
> > another. So it wouldn't be correct to have a "never sets errno" attribute
> > on glibc logb /
On Thu, 11 Oct 2018, Wilco Dijkstra wrote:
> For the new math functions all errno handling is already done in a
> single function so you could do something like: if (want_errno)
> set_errno (error).
want_errno being a global (or TLS) variable gets into the same problems as
_LIB_VERSION; you wa
Hi,
> if (math_errhandling & MATH_ERRNO) == 0 a math
> function may still set errno.
>
> it can only set it if there was an error though,
> not arbitrarily clobber it, but this means that
>
> (1) reordering errno access around math calls is
> invalid even with -fno-math-errno.
It's typically th
Hi,
> Note that "will ever set errno" includes possibly setting it in the
> future, since code may be built with one libm version and used with
> another. So it wouldn't be correct to have a "never sets errno" attribute
> on glibc logb / lround / llround / lrint / llrint / fma / remquo (missin
Joseph Myers wrote:
> On Mon, 8 Oct 2018, Richard Biener wrote:
>> So I think it would be fine if we'd have -fno-math-errno as documented
>> and then the C library would annotate their math functions according
>> to whether they will ever set errno or not. Once a math function is
>> const or pure
Hi Jeff,
> So I went back and reviewed all the discussion around this. I'm still
> having trouble getting comfortable with flipping the default -- unless
> we know ahead of time that the target runtime doesn't set errno on any
> of the math routines. That implies a target hook to describe the
>
On 10/4/18 1:43 PM, Joseph Myers wrote:
> On Thu, 4 Oct 2018, Jeff Law wrote:
>
>>> I doubt you could prove that without LTO of the whole program because an
>>> errno value set by a libm function call could always be checked in the
>>> caller of whatever function is being compiled.
>> Right, but
On Mon, 8 Oct 2018, Richard Biener wrote:
> So I think it would be fine if we'd have -fno-math-errno as documented
> and then the C library would annotate their math functions according
> to whether they will ever set errno or not. Once a math function is
> const or pure it cannot ever set errno
On Thu, Oct 4, 2018 at 9:43 PM Joseph Myers wrote:
>
> On Thu, 4 Oct 2018, Jeff Law wrote:
>
> > > I doubt you could prove that without LTO of the whole program because an
> > > errno value set by a libm function call could always be checked in the
> > > caller of whatever function is being compil
On Thu, 4 Oct 2018, Jeff Law wrote:
> > I doubt you could prove that without LTO of the whole program because an
> > errno value set by a libm function call could always be checked in the
> > caller of whatever function is being compiled.
> Right, but if you have a series of calls like
>
>
>
On 10/4/18 11:29 AM, Joseph Myers wrote:
> On Wed, 3 Oct 2018, Jeff Law wrote:
>
>> That led me to wonder if we could prove that for the majority of FP
>> intensive codes that even if the library set errno that nobody could
>> possibly be reading it, then we could in large part treat those builtin
On Wed, 3 Oct 2018, Jeff Law wrote:
> That led me to wonder if we could prove that for the majority of FP
> intensive codes that even if the library set errno that nobody could
> possibly be reading it, then we could in large part treat those builtin
> calls as -fno-math-errno (we'd mark them some
On 04/10/18 14:25, Jeff Law wrote:
> On 10/4/18 6:37 AM, Richard Biener wrote:
>> On Thu, Oct 4, 2018 at 2:06 PM Joseph Myers wrote:
>>>
>>> On Thu, 4 Oct 2018, Richard Biener wrote:
>>>
The other issue is that we're treating -fno-math-errno as disabling
errno handling in general (not on
On 10/4/18 6:37 AM, Richard Biener wrote:
> On Thu, Oct 4, 2018 at 2:06 PM Joseph Myers wrote:
>>
>> On Thu, 4 Oct 2018, Richard Biener wrote:
>>
>>> The other issue is that we're treating -fno-math-errno as disabling
>>> errno handling in general (not only for math functions). That would
>>
>> A
On Thu, 4 Oct 2018, Richard Biener wrote:
> So it means that GCC may elide errno setting (by inlining a function for
> example) but otherwise assume nothing else?
Yes, on systems where libm functions do in fact set errno (but it can also
assume that only the actual errno variable is clobbered,
On Thu, Oct 4, 2018 at 2:06 PM Joseph Myers wrote:
>
> On Thu, 4 Oct 2018, Richard Biener wrote:
>
> > The other issue is that we're treating -fno-math-errno as disabling
> > errno handling in general (not only for math functions). That would
>
> Also, is it treated as meaning the math functions
On Thu, 4 Oct 2018, Richard Biener wrote:
> The other issue is that we're treating -fno-math-errno as disabling
> errno handling in general (not only for math functions). That would
Also, is it treated as meaning the math functions *do not set errno* (so a
load of errno (or of anything that mig
On Thu, Oct 4, 2018 at 1:10 AM Jeff Law wrote:
>
> On 9/4/18 9:27 AM, Wilco Dijkstra wrote:
> >
> > ping
> >
> >
> >
> >
> > From: Wilco Dijkstra
> > Sent: 18 June 2018 15:01
> > To: GCC Patches
> > Cc: nd; Joseph Myers
> > Subject: [PATCH v3] Change default to -fno-math-errno
> >
> >
> > GCC curr
On 9/4/18 9:27 AM, Wilco Dijkstra wrote:
>
> ping
>
>
>
>
> From: Wilco Dijkstra
> Sent: 18 June 2018 15:01
> To: GCC Patches
> Cc: nd; Joseph Myers
> Subject: [PATCH v3] Change default to -fno-math-errno
>
>
> GCC currently defaults to -fmath-errno. This generates code assuming math
> fu
ping
From: Wilco Dijkstra
Sent: 18 June 2018 15:01
To: GCC Patches
Cc: nd; Joseph Myers
Subject: [PATCH v3] Change default to -fno-math-errno
GCC currently defaults to -fmath-errno. This generates code assuming math
functions set errno and the application checks errno. Few applications
On Wed, 27 Jun 2018, Wilco Dijkstra wrote:
> Joseph Myers wrote:
> > On Tue, 26 Jun 2018, Wilco Dijkstra wrote:
>
> > > That looks incorrect indeed but that's mostly a problem with -fmath-errno
> > > as it
> > > would result in GCC assuming the function is const/pure when in fact it
> > > isn't
Joseph Myers wrote:
> On Tue, 26 Jun 2018, Wilco Dijkstra wrote:
> > That looks incorrect indeed but that's mostly a problem with -fmath-errno
> > as it
> > would result in GCC assuming the function is const/pure when in fact it
> > isn't.
> > Does ATTR_MATHFN_FPROUNDING imply that errno is dead
On Tue, 26 Jun 2018, Wilco Dijkstra wrote:
> > If the library does not set errno, clearly -fno-math-errno by default is
> > appropriate (and is the default on Darwin).
>
> Various librarys no longer set errno nowadays, for example BSD, MUSL, Bionic
> etc. For GLIBC 3.0 I'd propose to drop settin
Joseph Myers wrote:
> On Thu, 21 Jun 2018, Jeff Law wrote:
>
> > I think all this implies that the setting of -fno-math-errno by default
> > really depends on the math library in use since it's the library that
> > has to arrange for either errno to get set or for an exception to be raised.
>
> If
On Thu, 21 Jun 2018, Jeff Law wrote:
> I think all this implies that the setting of -fno-math-errno by default
> really depends on the math library in use since it's the library that
> has to arrange for either errno to get set or for an exception to be raised.
If the library does not set errno,
On 06/18/2018 10:46 AM, Joseph Myers wrote:
> On Mon, 18 Jun 2018, Jeff Law wrote:
>
>> So do we need to set or check math_errhandling & MATH_ERRNO at all? Or
>
> That's a matter for libc (glibc currently sets it based on __FAST_MATH__ /
> __NO_MATH_ERRNO__, but fails to avoid including MATH_ER
On 06/19/2018 02:29 AM, Richard Biener wrote:
> On Mon, Jun 18, 2018 at 4:01 PM Wilco Dijkstra wrote:
>>
>> GCC currently defaults to -fmath-errno. This generates code assuming math
>> functions set errno and the application checks errno. Few applications
>> test errno and various systems and ma
Richard Biener wrote:
> There are a number of regression tests that check for errno handling
> (I added some to avoid aliasing for example). Please make sure to
> add explicit -fmath-errno to those that do not already have it set
> (I guess such patch would be obvious and independent of this one)
On Mon, Jun 18, 2018 at 4:01 PM Wilco Dijkstra wrote:
>
> GCC currently defaults to -fmath-errno. This generates code assuming math
> functions set errno and the application checks errno. Few applications
> test errno and various systems and math libraries no longer set errno since it
> is optio
On Mon, 18 Jun 2018, Jeff Law wrote:
> So do we need to set or check math_errhandling & MATH_ERRNO at all? Or
That's a matter for libc (glibc currently sets it based on __FAST_MATH__ /
__NO_MATH_ERRNO__, but fails to avoid including MATH_ERREXCEPT in the
definition for configurations not suppo
On 06/18/2018 08:01 AM, Wilco Dijkstra wrote:
> GCC currently defaults to -fmath-errno. This generates code assuming math
> functions set errno and the application checks errno. Few applications
> test errno and various systems and math libraries no longer set errno since it
> is optional. GCC g
31 matches
Mail list logo
