On Fri, 27 Nov 2020, Florian Weimer via Gcc wrote:
> The nature of these non-normal numbers is that the CPU does not produce
> them. I think we should make sure that glibc doesn't, either, with
> obvious exceptions such as memcpy. But beyond that, I don't know.
Exceptions probably also include
* Siddhesh Poyarekar:
> On 11/27/20 5:01 PM, Florian Weimer wrote:
>> I think the last part (the “bug”) is new. I welcome a consensus along
>> those lines. I just want to highlight this aspect.
>
> Should we consider fixing behaviour if the bug manifests in a user
> application and not in glibc
On 11/27/20 5:01 PM, Florian Weimer wrote:
I think the last part (the “bug”) is new. I welcome a consensus along
those lines. I just want to highlight this aspect.
Should we consider fixing behaviour if the bug manifests in a user
application and not in glibc itself? i.e. a crash because
* Joseph Myers:
> glibc effectively treats them as unspecified behavior - we don't expect
> them to produce any particular meaningful function return value (this
> includes the possibility that such an invalid encoding might be returned
> by a function given such an encoding as input), but if
On 11/26/20 12:57 AM, Joseph Myers wrote:
I think it would be a pain to maintain test coverage for unnormals (and
presumably all the other kinds of unsupported operands, and you'd need to
work out what semantics you want for pseudo-denormals as well since those
are the one kind of such
On Wed, 25 Nov 2020, Siddhesh Poyarekar wrote:
> Would you agree to treating unnormals as NaNs and consequently have glibc
> provide that guarantee in the library instead of either declaring it undefined
> or maintaining the status quo, i.e. keeping it unspecified?
I think it would be a pain to
On 11/25/20 2:58 AM, Joseph Myers wrote:
glibc effectively treats them as unspecified behavior - we don't expect
them to produce any particular meaningful function return value (this
includes the possibility that such an invalid encoding might be returned
by a function given such an encoding as
On Tue, 24 Nov 2020, Siddhesh Poyarekar wrote:
> The third alternative (which seems like a step back to me, but will concede
> that it is a valid resolution) is to state that unnormal input to isnanl would
> result in undefined behaviour and hence it is the responsibility of the
> application to
On 11/24/20 8:13 PM, Richard Biener wrote:
compiling isnanl to a quiet fp compare is wrong with
-fsignalling-nans: classification is not supposed to
signal exceptions for snan.
Can you open a bugreport for this? Note that the option is likely
to invoke isnanl from libm ...
I believe
On Tue, Nov 24, 2020 at 3:20 PM Adhemerval Zanella via Gcc
wrote:
>
>
>
> On 24/11/2020 10:59, Siddhesh Poyarekar wrote:
> > On 11/24/20 7:11 PM, Szabolcs Nagy wrote:
> >> ideally fpclassify (and other classification macros) would
> >> handle all representations.
> >>
> >> architecturally invalid
On 11/24/20 7:46 PM, Adhemerval Zanella wrote:
Which is the currently take from gcc developers on this semantic change of
__builtin_isnanl? Are they considering current behavior of non classifying
the 'unnormal' as NAN the expected behavior and waiting glibc to follow
it or are they willing to
On Nov 24 2020, Szabolcs Nagy via Gcc wrote:
>> glibc evaluates the bit pattern of the 80-bit long double and in the
>> process, ignores the integer bit, i.e. bit 63. As a result, it considers
>> the unnormal number as a valid long double and isnanl returns 0.
>
> i think m68k and x86 are
On 24/11/2020 10:59, Siddhesh Poyarekar wrote:
> On 11/24/20 7:11 PM, Szabolcs Nagy wrote:
>> ideally fpclassify (and other classification macros) would
>> handle all representations.
>>
>> architecturally invalid or trap representations can be a
>> non-standard class but i think classifying
On 11/24/20 7:11 PM, Szabolcs Nagy wrote:
ideally fpclassify (and other classification macros) would
handle all representations.
architecturally invalid or trap representations can be a
non-standard class but i think classifying them as FP_NAN
would break the least amount of code.
That's my
* Szabolcs Nagy:
> ideally fpclassify (and other classification macros) would
> handle all representations.
>
> architecturally invalid or trap representations can be a
> non-standard class but i think classifying them as FP_NAN
> would break the least amount of code.
I think the fpclassify
The 11/24/2020 16:23, Siddhesh Poyarekar wrote:
> Hi,
>
> The Intel 80-bit long double format has a concept of "unnormal" numbers that
> have a non-zero exponent and zero integer bit (i.e. bit 63) in the mantissa;
> all valid long double numbers have their integer bit set to 1. Unnormal
>
Hi,
The Intel 80-bit long double format has a concept of "unnormal" numbers
that have a non-zero exponent and zero integer bit (i.e. bit 63) in the
mantissa; all valid long double numbers have their integer bit set to 1.
Unnormal numbers are mentioned in "8.2.2 Unsupported Double
17 matches
Mail list logo
