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
Extended-Pr
Hi,
On Tue, 2020-11-24 at 08:50 +0100, Richard Biener wrote:
> On Tue, Nov 24, 2020 at 8:45 AM Jakub Jelinek wrote:
> > I agree with Richard and I'd lean towards -gdwarf32/-gdwarf64, even
> > when DWARF 32 is released in 81 years from now or how many, it would
> > use -gdwarf-32.
>
> Works for m
On Tue, Nov 24, 2020 at 12:04:45PM +0100, Mark Wielaard wrote:
> Hi,
>
> On Tue, 2020-11-24 at 08:50 +0100, Richard Biener wrote:
> > On Tue, Nov 24, 2020 at 8:45 AM Jakub Jelinek wrote:
> > > I agree with Richard and I'd lean towards -gdwarf32/-gdwarf64, even
> > > when DWARF 32 is released in 8
On 11/23/20 12:04 PM, Richard Biener wrote:
> On Mon, Nov 23, 2020 at 10:53 AM Marius Hillenbrand via Gcc
> wrote:
>>
>> Hi,
>>
>> Digging into a test case failure with section anchors, I found
>> dependence analysis return false negatives, leading to bad optimization
>> by cse1. Two variables are
On Tue, Nov 24, 2020 at 12:14 PM Marius Hillenbrand
wrote:
>
> On 11/23/20 12:04 PM, Richard Biener wrote:
> > On Mon, Nov 23, 2020 at 10:53 AM Marius Hillenbrand via Gcc
> > wrote:
> >>
> >> Hi,
> >>
> >> Digging into a test case failure with section anchors, I found
> >> dependence analysis ret
Hi!
Ping. Anybody got an opinion on the approach we should take?
Grüße
Thomas
On 2020-11-03T15:21:40+0100, I wrote:
> Hi!
>
> I've investigated some more.
>
> On 2020-11-03T13:31:53+0100, I wrote:
>> Help. Save the attached file as 'gcc/testsuite/c-c++-common/goacc/l_.c',
>> and then run:
>
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
> numbers
* 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 macro
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 im
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 the
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 differe
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 al
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 4:11 AM, Jakub Jelinek via Gcc wrote:
> On Tue, Nov 24, 2020 at 12:04:45PM +0100, Mark Wielaard wrote:
>> Hi,
>>
>> On Tue, 2020-11-24 at 08:50 +0100, Richard Biener wrote:
>>> On Tue, Nov 24, 2020 at 8:45 AM Jakub Jelinek wrote:
I agree with Richard and I'd lean towards -gdwar
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 Szabolcs
On Mon, Nov 23, 2020 at 11:45 PM Jakub Jelinek wrote:
>
> On Mon, Nov 23, 2020 at 06:38:16PM -0800, David Blaikie via Gcc wrote:
> > > I would pick -gdwarf32/-gdwarf64 (are we sure the DWARF spec will
> > > never reach version 32 or 64?
> > > maybe -g32 / -g64 similar to -m32/-m64 are good enough?
On Tue, Nov 24, 2020 at 3:11 AM Jakub Jelinek wrote:
>
> On Tue, Nov 24, 2020 at 12:04:45PM +0100, Mark Wielaard wrote:
> > Hi,
> >
> > On Tue, 2020-11-24 at 08:50 +0100, Richard Biener wrote:
> > > On Tue, Nov 24, 2020 at 8:45 AM Jakub Jelinek wrote:
> > > > I agree with Richard and I'd lean tow
> Sure enough - I was more getting at "would Clang's choice here have
> much/any influence on GCC's choice in the future"? (ie: Is GCC
> interested in compatibility with Clang?)
I'd say yes, but this criterion comes second after consistency with itself.
The latter dictates a -g switch so, once thi
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 e
On Wed, 25 Nov 2020, (Cron Daemon) via Gccadmin wrote:
> === Working on: master ===
> branch pulled and checked out
> 61 revisions since last Daily bump
> Traceback (most recent call last):
> File "../gcc-changelog/git_update_version.py", line 143, in
> update_current_branch()
> File "../
Hi!
I have a C floating point comparison (a <= b && a >= b), which
test_for_singularity turns into (a <= b && a == b) and vectorizer turns
into ((a <= b) & (a == b)). So far so good.
eliminate_redundant_comparison, however, turns it into just (a == b).
I don't think this is correct, because (a <
On Tue, Nov 24, 2020 at 5:19 PM Joseph Myers wrote:
>
> On Wed, 25 Nov 2020, (Cron Daemon) via Gccadmin wrote:
>
> > === Working on: master ===
> > branch pulled and checked out
> > 61 revisions since last Daily bump
> > Traceback (most recent call last):
> > File "../gcc-changelog/git_update_ve
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 i
Hello, I am PRACHURYA PRAN SARMA from India, I am a first year Computer
science and engineering student and I want to contribute and work in the
lovely organisation. I know c language and I am learning c++ too. I am also
going to participate in GSoC 2021.
Thank you.
On Wed, 25 Nov 2020, Ilya Leoshkevich via Gcc wrote:
I have a C floating point comparison (a <= b && a >= b), which
test_for_singularity turns into (a <= b && a == b) and vectorizer turns
into ((a <= b) & (a == b)). So far so good.
eliminate_redundant_comparison, however, turns it into just (a
25 matches
Mail list logo
