On Tue, Dec 12, 2017 at 2:43 PM, Joseph Myers wrote:
> On Tue, 12 Dec 2017, Jakub Jelinek wrote:
>
>> Any other functions that are using ATTR_MATHFN_FPROUNDING_ERRNO or
>> ATTR_MATHFN_FPROUNDING and aren't affected by fesetround?
>
> drem, fmod, frexp, ilogb, modf, remainder, remquo, significand s
On Tue, 12 Dec 2017, Jakub Jelinek wrote:
> Any other functions that are using ATTR_MATHFN_FPROUNDING_ERRNO or
> ATTR_MATHFN_FPROUNDING and aren't affected by fesetround?
drem, fmod, frexp, ilogb, modf, remainder, remquo, significand should all
be independent of the rounding mode.
--
Joseph S.
On Tue, Dec 12, 2017 at 09:08:10AM +0100, Richard Biener wrote:
> On Mon, Dec 11, 2017 at 11:34 PM, Joseph Myers
> wrote:
> > On Mon, 11 Dec 2017, Steve Ellcey wrote:
> >
> >> the attribute. The other is why the function would be pure with
> >> -fno-math-errno but const otherwise. I would think
On Mon, Dec 11, 2017 at 11:34 PM, Joseph Myers wrote:
> On Mon, 11 Dec 2017, Steve Ellcey wrote:
>
>> the attribute. The other is why the function would be pure with
>> -fno-math-errno but const otherwise. I would think that the -fno-math-errno
>> version would be const (stricter than pure) sinc
On Mon, 11 Dec 2017, Steve Ellcey wrote:
> the attribute. The other is why the function would be pure with
> -fno-math-errno but const otherwise. I would think that the -fno-math-errno
> version would be const (stricter than pure) since it is not setting
> errno. Finally, how can I check if -fr
I have a question about the attributes that GCC is putting on the
nexttoward/nextafter builtin functions. This issue started when
ToT glibc ran into a problem when building with ToT GCC after Martin
Sebor added a patch to GCC that tightened up the attribute checking
that GCC does.
The line belo
