unnormal Intel 80-bit long doubles and isnanl
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-Precision Floating-Point Encodings and Pseudo-Denormals" and listed in Table 8-3 in the Intel 64 and IA-32 Architectures Software Developer’s Manual Volume 1:Basic Architecture. As per the manual, these numbers are considered unsupported and generate an invalid-operation exception if they are used as operands to any floating point instructions. The question of this email is how the toolchain (including glibc) should treat these numbers since as things stand today, glibc and gcc disagree when it comes to isnanl. 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. gcc on the other hand, simply uses the number in a floating point comparison and uses the parity flag (which indicates an unordered compare, signalling a NaN) to decide if the number is a NaN. The unnormal numbers behave like NaNs in this respect, in that they set the parity flag and with -fsignalling-nans, would result in an invalid-operation exception. As a result, __builtin_isnanl returns 1 for an unnormal number. So the question is, which behaviour should be considered correct? Strictly speaking, unnormal numbers are listed separately from NaNs in the document and as such are distinct from NaNs. So on the question of "is nan?" the answer ought to be "No". On the flip side, the behaviour described (and experienced through code) is exactly the same as a NaN, i.e. a floating point operation sets the parity flag and generates an invalid-operation exception. So if it looks like a NaN, behaves like a NaN, then even if the document hints (and it is just a hint right, since it doesn't specifically state it?) that it's different, it likely is a NaN. What's more, one of the fixes to glibc[1] assumes that __builtin_isnanl will do the right thing. 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 ensure that inputs to isnanl are never unnormal. Thoughts? Siddhesh [1] https://sourceware.org/git/?p=glibc.git;h=0474cd5de60448f31d7b872805257092faa626e4
Re: DWARF64 gcc/clang flag discussion
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 me. Let's go with -gdwarf32/64. I don't have a strong opinion, so if that is the consensus, lets go with that. The only open question (which I wanted to avoid by picking -f...) is whether it enables generating debuginfo as is normal when using any -goption, or whether you need another -goption to explicitly turn on debuginfo generation when using -gdwarf32/64? My preference would be that any option starting with -g enables debuginfo generation and no additional -g is needed to keep things consistent. Cheers, Mark
Re: DWARF64 gcc/clang flag discussion
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 81 years from now or how many, it would > > > use -gdwarf-32. > > > > Works for me. Let's go with -gdwarf32/64. > > I don't have a strong opinion, so if that is the consensus, lets go > with that. The only open question (which I wanted to avoid by picking > -f...) is whether it enables generating debuginfo as is normal when > using any -goption, or whether you need another -goption to explicitly > turn on debuginfo generation when using -gdwarf32/64? My preference > would be that any option starting with -g enables debuginfo generation > and no additional -g is needed to keep things consistent. I think we lost that consistency already, I think -gsplit-dwarf has been changed quite recently not to imply -g. That said, for -gdwarf32/64, I think it is more sensible to enable debug info than not to. Jakub
Re: Dependence analysis with section anchors?
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 synthetically constructed aliases. One is
>> addressed relative to the section anchor and the other using a symbol
>> ref, yet write_dependence_p() claims that they could not alias. I can
>> reproduce that miscompile on aarch64, ppc64, and s390x. How is
>> write_dependence_p() supposed to handle such cases with section anchors?
>>
>>
>> Example: (simplified version of gcc.c-torture/execute/alias-2.c)
>> int off; // causing nonzero offset of a to the section anchor
>> int a;
>> extern int b __attribute__ ((alias("a")));
>> /* ... */
>> int main()
>> b=1; <-- uses symbol_ref to b
>> a=2; <-- uses the section anchor + offset 4
>> if (b!=2)
>>__builtin_abort ();
>> return 0;
>> }
>>
>> so write_dependence gets to compare the canonicalized addresses
>> (const:DI (plus:DI (symbol_ref:DI ("*.LANCHOR0") [flags 0x182])
>> (const_int 4 [0x4])))
>> and
>> (symbol_ref:DI ("b") [flags 0x602] )
>> and
>>
[...]
>
> If the above is all we get to see then we have to give up when either
> of the address is based on a section anchor and we know the other
> one could possibly be refered through a section anchor.
>
> In those cases we have to rely on MEM_EXPRs for disambiguation
> which, for the anchored address, is unfortunately lost?
Actually, both mem rtx have their MEM_EXPRs attached, in the cases I
looked at.
for example
(mem/c:SI (const:DI (plus:DI
(symbol_ref:DI ("*.LANCHOR0") [flags 0x182])
(const_int 4 [0x4]))) [1 a+0 S4 A32])
We could add a check for cases where MEM_EXPRs are available and clearly
indicate aliasing or overlap. That check would happen before the other
methods that only look at partial information (e.g., base_alias_check,
memrefs_conflict_p) -- to catch such clear cases without the risk of
making the other checks more pessimistic.
>
>> (see also https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92294 for the
>> initial report on aarch64 and my full example)
>>
>> Marius
--
Marius Hillenbrand
Linux on Z development
IBM Deutschland Research & Development GmbH
Vors. des Aufsichtsrats: Gregor Pillen / Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht
Stuttgart, HRB 243294
Re: Dependence analysis with section anchors?
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 return false negatives, leading to bad optimization
> >> by cse1. Two variables are synthetically constructed aliases. One is
> >> addressed relative to the section anchor and the other using a symbol
> >> ref, yet write_dependence_p() claims that they could not alias. I can
> >> reproduce that miscompile on aarch64, ppc64, and s390x. How is
> >> write_dependence_p() supposed to handle such cases with section anchors?
> >>
> >>
> >> Example: (simplified version of gcc.c-torture/execute/alias-2.c)
> >> int off; // causing nonzero offset of a to the section anchor
> >> int a;
> >> extern int b __attribute__ ((alias("a")));
> >> /* ... */
> >> int main()
> >> b=1; <-- uses symbol_ref to b
> >> a=2; <-- uses the section anchor + offset 4
> >> if (b!=2)
> >>__builtin_abort ();
> >> return 0;
> >> }
> >>
> >> so write_dependence gets to compare the canonicalized addresses
> >> (const:DI (plus:DI (symbol_ref:DI ("*.LANCHOR0") [flags 0x182])
> >> (const_int 4 [0x4])))
> >> and
> >> (symbol_ref:DI ("b") [flags 0x602] )
> >> and
> >>
> [...]
> >
> > If the above is all we get to see then we have to give up when either
> > of the address is based on a section anchor and we know the other
> > one could possibly be refered through a section anchor.
> >
> > In those cases we have to rely on MEM_EXPRs for disambiguation
> > which, for the anchored address, is unfortunately lost?
>
> Actually, both mem rtx have their MEM_EXPRs attached, in the cases I
> looked at.
>
> for example
> (mem/c:SI (const:DI (plus:DI
>(symbol_ref:DI ("*.LANCHOR0") [flags 0x182])
>
>
>(const_int 4 [0x4]))) [1 a+0 S4 A32])
>
> We could add a check for cases where MEM_EXPRs are available and clearly
> indicate aliasing or overlap. That check would happen before the other
> methods that only look at partial information (e.g., base_alias_check,
> memrefs_conflict_p) -- to catch such clear cases without the risk of
> making the other checks more pessimistic.
But you can't rely on must-alias for may-alias queries so that will just
paper over the existing issue in most of the cases ...
Richard.
>
>
> >
> >> (see also https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92294 for the
> >> initial report on aarch64 and my full example)
> >>
> >> Marius
>
> --
> Marius Hillenbrand
> Linux on Z development
> IBM Deutschland Research & Development GmbH
> Vors. des Aufsichtsrats: Gregor Pillen / Geschäftsführung: Dirk Wittkopp
> Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht
> Stuttgart, HRB 243294
Re: DejaGnu diagnostics checking confused, possibly related to 'dg-line'?
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:
>>
>> $ make check-gcc-c++ RUNTESTFLAGS=--all\ goacc.exp=l_.c
>>
>> As expected for '-std=c++98' testing, which comes first:
>>
>> PASS: c-c++-common/goacc/l_.c -std=c++98 (test for errors, line 14)
>> PASS: c-c++-common/goacc/l_.c -std=c++98 (test for warnings, line 11)
>> PASS: c-c++-common/goacc/l_.c -std=c++98 (test for excess errors)
>> WARNING: dg-line var l1 defined, but not used
>> WARNING: dg-line var l2 defined, but not used
>> WARNING: dg-line var l3 defined, but not used
>>
>> But then it goes on with '-std=c++14', etc. testing:
>>
>> UNRESOLVED: c-c++-common/goacc/l_.c -std=c++14 (test for errors, line
>> 14)
>> PASS: c-c++-common/goacc/l_.c -std=c++14 (test for warnings, line 11)
>> PASS: c-c++-common/goacc/l_.c -std=c++14 (test for excess errors)
>> WARNING: dg-line var l1 defined, but not used
>> WARNING: dg-line var l2 defined, but not used
>> WARNING: dg-line var l3 defined, but not used
>> UNRESOLVED: c-c++-common/goacc/l_.c -std=c++17 (test for errors, line
>> 14)
>> PASS: c-c++-common/goacc/l_.c -std=c++17 (test for warnings, line 11)
>> PASS: c-c++-common/goacc/l_.c -std=c++17 (test for excess errors)
>> WARNING: dg-line var l1 defined, but not used
>> WARNING: dg-line var l2 defined, but not used
>> WARNING: dg-line var l3 defined, but not used
>> UNRESOLVED: c-c++-common/goacc/l_.c -std=c++2a (test for errors, line
>> 14)
>> PASS: c-c++-common/goacc/l_.c -std=c++2a (test for warnings, line 11)
>> PASS: c-c++-common/goacc/l_.c -std=c++2a (test for excess errors)
>> WARNING: dg-line var l1 defined, but not used
>> WARNING: dg-line var l2 defined, but not used
>> WARNING: dg-line var l3 defined, but not used
>>
>> === g++ Summary ===
>>
>> # of expected passes9
>> # of unresolved testcases 3
>>
>> Why is suddenly the "test for errors, line 14" an UNRESOLVED? (The
>> compiler diagnostics are as expected. This testcase doesn't depend on
>> '-std=[...]' at all.)
>>
>> And now the "funny" thing: if I disable any of the 'dg-line' directives,
>> it works as expected, all-PASS. But note that "test for errors, line 14"
>> doesn't even use a 'dg-line'-captured line number. (It uses absoute line
>> numbers. Same issue visible when using relative ones, or when actually
>> using 'dg-line' for these.)
>>
>>
>> I reduced this from a much bigger testcase, and had originally found this
>> not with 'check-gcc-c++' but with 'check-gcc-c': things worked fine as
>> long as testing just a single testcase, but broke when testing several.
>> (Again the symptom was that the first testcase worked fine, but the
>> following ones had an unexpecte UNRESOLVED for the first 'dg-error' (only
>> for the first!).) Supposedly, 'check-gcc-c++' with a single testcase but
>> testing several variants is exhibiting the same problem.
>
> The problem is indeed related to the "WARNING: dg-line var [...] defined,
> but not used" diagnostics. These are produced via DejaGnu 'warning'
> calls, which increments 'warncnt', and once that reaches
> 'warning_threshold' (default per '/usr/share/dejagnu/framework.exp' is:
> 'set warning_threshold 3'), this triggers UNRESOLVED via
> '/usr/share/dejagnu/framework.exp:record_test'. That this UNRESOLVED
> appears for the *next* testcase, must be considered some kind of bug
> (improper use of 'warning'?), I suppose.
>
> The following works around that:
>
> --- gcc/testsuite/lib/gcc-dg.exp
> +++ gcc/testsuite/lib/gcc-dg.exp
> @@ -1008,6 +1008,8 @@ if { [info procs saved-dg-test] == [list] } {
> } else {
> regsub {^saved_linenr_} $varname "" org_varname
> warning "dg-line var $org_varname defined, but not used"
> + global warncnt
> + incr warncnt -1
> }
> }
> unset save_linenr_varnames
>
> ..., or:
>
> --- gcc/testsuite/lib/gcc-dg.exp
> +++ gcc/testsuite/lib/gcc-dg.exp
> @@ -1007,7 +1007,7 @@ if { [info procs saved-dg-test] == [list] } {
> eval unset $varname_used
> } else {
> regsub {^saved_linenr_} $varname "" org_varname
> - warning "dg-line var $org_varname defined, but not used"
> + verbose "WARNING: dg-line var $org_varname defined, but not
> used" 0
> }
> }
> unset save_linenr_varnames
>
> ..., or hopefully something less hacky.
>
>
> The question is, what quality/severity should the "dg-line var [...]
> defined, but not used" diagnostic have?
>
> For example, "FAIL":
>
Re: unnormal Intel 80-bit long doubles and isnanl
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 are mentioned in "8.2.2 Unsupported Double Extended-Precision > Floating-Point Encodings and Pseudo-Denormals" and listed in Table 8-3 in > the Intel 64 and IA-32 Architectures Software Developer’s Manual Volume > 1:Basic Architecture. > > As per the manual, these numbers are considered unsupported and generate an > invalid-operation exception if they are used as operands to any floating > point instructions. The question of this email is how the toolchain > (including glibc) should treat these numbers since as things stand today, > glibc and gcc disagree when it comes to isnanl. 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. > 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 different here. > > gcc on the other hand, simply uses the number in a floating point comparison > and uses the parity flag (which indicates an unordered compare, signalling a > NaN) to decide if the number is a NaN. The unnormal numbers behave like > NaNs in this respect, in that they set the parity flag and with > -fsignalling-nans, would result in an invalid-operation exception. As a > result, __builtin_isnanl returns 1 for an unnormal number. compiling isnanl to a quiet fp compare is wrong with -fsignalling-nans: classification is not supposed to signal exceptions for snan. > > So the question is, which behaviour should be considered correct? Strictly > speaking, unnormal numbers are listed separately from NaNs in the document > and as such are distinct from NaNs. So on the question of "is nan?" the > answer ought to be "No". > > On the flip side, the behaviour described (and experienced through code) is > exactly the same as a NaN, i.e. a floating point operation sets the parity > flag and generates an invalid-operation exception. So if it looks like a > NaN, behaves like a NaN, then even if the document hints (and it is just a > hint right, since it doesn't specifically state it?) that it's different, it > likely is a NaN. What's more, one of the fixes to glibc[1] assumes that > __builtin_isnanl will do the right thing. > > 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 ensure that inputs to isnanl are never unnormal. > > Thoughts? > > Siddhesh > > [1] > https://sourceware.org/git/?p=glibc.git;h=0474cd5de60448f31d7b872805257092faa626e4
Re: unnormal Intel 80-bit long doubles and isnanl
* 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 has the wrong signature for trap representation checks. It's macro, so in theory we could make it behave in any way we want, but I think it's awkward to pass a dereferenced pointer as a macro argument when it's as best unclear whether the dereferencing operation itself triggers undefined behavior. We can avoid that if we do not make these representations trap representations, but give them a defined meaning. >> 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 different here. I think you are right. Thanks, Florian -- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
Re: unnormal Intel 80-bit long doubles and isnanl
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 impression too. 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 different here. gcc on the other hand, simply uses the number in a floating point comparison and uses the parity flag (which indicates an unordered compare, signalling a NaN) to decide if the number is a NaN. The unnormal numbers behave like NaNs in this respect, in that they set the parity flag and with -fsignalling-nans, would result in an invalid-operation exception. As a result, __builtin_isnanl returns 1 for an unnormal number. compiling isnanl to a quiet fp compare is wrong with -fsignalling-nans: classification is not supposed to signal exceptions for snan. I agree, but I think that issue with __builtin_isnanl is orthogonal to the question about unnormals. Once that is fixed in gcc, we could actually use __builtin_isnanl all the time in glibc for isnanl. Siddhesh
Re: unnormal Intel 80-bit long doubles and isnanl
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 them as FP_NAN >> would break the least amount of code. > > That's my impression too. > >>> 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 different here. >> >>> >>> gcc on the other hand, simply uses the number in a floating point comparison >>> and uses the parity flag (which indicates an unordered compare, signalling a >>> NaN) to decide if the number is a NaN. The unnormal numbers behave like >>> NaNs in this respect, in that they set the parity flag and with >>> -fsignalling-nans, would result in an invalid-operation exception. As a >>> result, __builtin_isnanl returns 1 for an unnormal number. >> >> compiling isnanl to a quiet fp compare is wrong with >> -fsignalling-nans: classification is not supposed to >> signal exceptions for snan. > > I agree, but I think that issue with __builtin_isnanl is orthogonal to the > question about unnormals. Once that is fixed in gcc, we could actually use > __builtin_isnanl all the time in glibc for isnanl. > > Siddhesh 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 align with glibc behavior?
Re: unnormal Intel 80-bit long doubles and isnanl
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 different here. The mc68881 doesn't trap on unnormal numbers, it implicitly converts such input representations to normal, denormal or zero, as appropriate. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: unnormal Intel 80-bit long doubles and isnanl
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 align with glibc behavior? The gcc ml is also in cc (apologies to those getting 2-3 copies of this!) so I'm hoping to get feedback from both communities to arrive and a consensus. gcc currently considers unnormals as NaN. I think that is the right behaviour and would like glibc to align with that but before making such a proposal for glibc, I wanted to make sure that this gcc behaviour is defined because currently there is nothing that makes that clear. Siddhesh
Re: unnormal Intel 80-bit long doubles and isnanl
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 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 impression too. > > > >>> 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 different here. > >> > >>> > >>> gcc on the other hand, simply uses the number in a floating point > >>> comparison > >>> and uses the parity flag (which indicates an unordered compare, > >>> signalling a > >>> NaN) to decide if the number is a NaN. The unnormal numbers behave like > >>> NaNs in this respect, in that they set the parity flag and with > >>> -fsignalling-nans, would result in an invalid-operation exception. As a > >>> result, __builtin_isnanl returns 1 for an unnormal number. > >> > >> 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 agree, but I think that issue with __builtin_isnanl is orthogonal to the > > question about unnormals. Once that is fixed in gcc, we could actually use > > __builtin_isnanl all the time in glibc for isnanl. > > > > Siddhesh > > 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 align with glibc behavior? I think GCC should follow standards and in case they do not apply do sth reasonable - which I think classifying those as NaN is. Richard.
Re: DWARF64 gcc/clang flag discussion
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 -gdwarf32/-gdwarf64, even when DWARF 32 is released in 81 years from now or how many, it would use -gdwarf-32. >>> Works for me. Let's go with -gdwarf32/64. >> I don't have a strong opinion, so if that is the consensus, lets go >> with that. The only open question (which I wanted to avoid by picking >> -f...) is whether it enables generating debuginfo as is normal when >> using any -goption, or whether you need another -goption to explicitly >> turn on debuginfo generation when using -gdwarf32/64? My preference >> would be that any option starting with -g enables debuginfo generation >> and no additional -g is needed to keep things consistent. > I think we lost that consistency already, I think -gsplit-dwarf has been > changed quite recently not to imply -g. > > That said, for -gdwarf32/64, I think it is more sensible to enable debug > info than not to. That works for me. jeff
Re: unnormal Intel 80-bit long doubles and isnanl
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 is talking about this: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66462 Siddhesh
Re: DWARF64 gcc/clang flag discussion
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?) > > > > Any sense of a good way to break the tie/uncertainty? > > > > Alternatively: If Clang picks something here (likely from within this > > range of candidates - though given I've got a fair bit of say on the > > Clang side, and if left to me, I'd probably lean heavily on the > > -fdwarf32/64 side), is it likely that choice will tend to be adopted > > by GCC? I'd rather not get out of sync, but I expect a bit hard to get > > a conclusion on the GCC side without patches in progress, etc. Got a > > sense of who are the people who would likely be deciders/patch > > approvers for such a naming choice on the GCC side? > > Depends on what it would choose. 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 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. I understand that the actual collision isn't likely - but the proximity in phrasing seems liable to be confusing to users. (especially if it has different semantics re: enabling debug info and my understanding/reading of other threads was that folks were generally in agreement that we should try to avoid having debug-info-affecting flags that also enable debug info, instead trying to keep them more orthogonal, I think?) - Dave
Re: DWARF64 gcc/clang flag discussion
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 towards -gdwarf32/-gdwarf64, even > > > > when DWARF 32 is released in 81 years from now or how many, it would > > > > use -gdwarf-32. > > > > > > Works for me. Let's go with -gdwarf32/64. > > > > I don't have a strong opinion, so if that is the consensus, lets go > > with that. The only open question (which I wanted to avoid by picking > > -f...) is whether it enables generating debuginfo as is normal when > > using any -goption, or whether you need another -goption to explicitly > > turn on debuginfo generation when using -gdwarf32/64? My preference > > would be that any option starting with -g enables debuginfo generation > > and no additional -g is needed to keep things consistent. > > I think we lost that consistency already, I think -gsplit-dwarf has been > changed quite recently not to imply -g. My understanding was that that change hasn't gone in at this point, in part because of the issue of changing the semantics of an existing flag and discussions around whether -g implies debug info. Could you confirm if this change has been made in GCC? as it may be important to make a similar change in Clang for consistency. Not that Split DWARF would be the first example of -g flags that don't imply -g. (-ggnu-pubnames, I think, comes to mind) > That said, for -gdwarf32/64, I think it is more sensible to enable debug > info than not to. Given my (& I think others on both GCC and Clang from what I gathered from the previous threads) fairly strong desire to allow selecting features without enabling debug info - perhaps it'd make sense for Clang to implement -fdwarf32/64 and then can implement -gdwarf32/64 for compatibility whenever GCC does (without implementing -gdwarf32/64 with potentially differing semantics than GCC re: enabling debug info) Seems these conversations end up with a bunch of different perspectives which is compounding the inconsistencies/variety in flags. If there's general agreement that -g* flags should imply -g, maybe we could carveout the possibility then that -f flags can affect debug info generation but don't enable it? For users who want to be able to change build-wide settings while having potentially per-library/per-file customization. (eg: I want to turn down the debug info emission on this file (to, say, -gmlt) but I don't want to force debug info on for this file regardless of build settings) - Dave
Re: DWARF64 gcc/clang flag discussion
> 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 this is established, what -g switch can indeed be coordinated. -- Eric Botcazou
Re: unnormal Intel 80-bit long doubles and isnanl
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 ensure that inputs to isnanl are never unnormal. 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 they result in buffer overflows, infinite loops or similar, that's fixed as a bug. Note that there are lots of libm function implementations, not just isnanl, which work by looking at the encoding without considering the possibility it might be one of the kinds of encodings (other than sNaN) that cannot result from floating-point arithmetic. This includes both ldbl-96 implementations in C and implementations in assembly for i386 and x86_64, and probably implementations for m68k and ia64 as well. iscanonical is the only operation in glibc that deliberately tries to detect and produce defined results for these encodings. -- Joseph S. Myers jos...@codesourcery.com
Re: Cron sh /home/gccadmin/scripts/update_version_git
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 "../gcc-changelog/git_update_version.py", line 100, in > update_current_branch > % (commit.hexsha, head.hexsha)) > File "/tmp/tmp.yGFjw60tQz/gcc-changelog/git_repository.py", line 76, in > parse_git_revisions > commit_to_info_hook=commit_to_info) > File "/tmp/tmp.yGFjw60tQz/gcc-changelog/git_commit.py", line 281, in > __init__ > self.info = self.commit_to_info_hook(self.revert_commit) > File "/tmp/tmp.yGFjw60tQz/gcc-changelog/git_repository.py", line 37, in > commit_to_info > c = repo.commit(commit) > File "/home/gccadmin/.local/lib/python3.6/site-packages/git/repo/base.py", > line 480, in commit > return self.rev_parse(str(rev) + "^0") > File "/home/gccadmin/.local/lib/python3.6/site-packages/git/repo/fun.py", > line 213, in rev_parse > obj = name_to_object(repo, rev[:start]) > File "/home/gccadmin/.local/lib/python3.6/site-packages/git/repo/fun.py", > line 147, in name_to_object > raise BadName(name) > gitdb.exc.BadName: Ref 'c4fa3728ab4f78984a549894e0e8c4d6a253e540,' did not > resolve to an object I don't know where that comma after the commit id came from, but something appears to have broken the update_version_git cron job. -- Joseph S. Myers jos...@codesourcery.com
Reassociation and trapping operations
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 <= b) traps and (a == b) doesn't. The following helps: --- a/gcc/tree-ssa-reassoc.c +++ b/gcc/tree-ssa-reassoc.c @@ -2144,7 +2144,7 @@ eliminate_redundant_comparison (enum tree_code opcode, if (TREE_CODE (curr->op) != SSA_NAME) return false; def1 = SSA_NAME_DEF_STMT (curr->op); - if (!is_gimple_assign (def1)) + if (!is_gimple_assign (def1) || gimple_could_trap_p (def1)) return false; lcode = gimple_assign_rhs_code (def1); if (TREE_CODE_CLASS (lcode) != tcc_comparison) @@ -2160,7 +2160,7 @@ eliminate_redundant_comparison (enum tree_code opcode, if (TREE_CODE (oe->op) != SSA_NAME) continue; def2 = SSA_NAME_DEF_STMT (oe->op); - if (!is_gimple_assign (def2)) + if (!is_gimple_assign (def2) || gimple_could_trap_p (def2)) continue; rcode = gimple_assign_rhs_code (def2); if (TREE_CODE_CLASS (rcode) != tcc_comparison) However, I couldn't help noticing that other parts of reassociation pass use stmt_could_throw_p, and trapping is mentioned only in one place. Is this intentional? Shouldn't both throwing and trapping block reassociation? Best regards, Ilya
Re: Cron sh /home/gccadmin/scripts/update_version_git
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_version.py", line 143, in > > update_current_branch() > > File "../gcc-changelog/git_update_version.py", line 100, in > > update_current_branch > > % (commit.hexsha, head.hexsha)) > > File "/tmp/tmp.yGFjw60tQz/gcc-changelog/git_repository.py", line 76, in > > parse_git_revisions > > commit_to_info_hook=commit_to_info) > > File "/tmp/tmp.yGFjw60tQz/gcc-changelog/git_commit.py", line 281, in > > __init__ > > self.info = self.commit_to_info_hook(self.revert_commit) > > File "/tmp/tmp.yGFjw60tQz/gcc-changelog/git_repository.py", line 37, in > > commit_to_info > > c = repo.commit(commit) > > File > > "/home/gccadmin/.local/lib/python3.6/site-packages/git/repo/base.py", line > > 480, in commit > > return self.rev_parse(str(rev) + "^0") > > File "/home/gccadmin/.local/lib/python3.6/site-packages/git/repo/fun.py", > > line 213, in rev_parse > > obj = name_to_object(repo, rev[:start]) > > File "/home/gccadmin/.local/lib/python3.6/site-packages/git/repo/fun.py", > > line 147, in name_to_object > > raise BadName(name) > > gitdb.exc.BadName: Ref 'c4fa3728ab4f78984a549894e0e8c4d6a253e540,' did not > > resolve to an object > > I don't know where that comma after the commit id came from, but something > appears to have broken the update_version_git cron job. Could it be commit ce2d9549f2b2bcb70a1a6f8f4e776e1ed427546b Author: Ulrich Weigand Date: Tue Nov 24 19:30:01 2020 +0100 Revert: "Fix -ffast-math flags handling inconsistencies" This reverts commit c4fa3728ab4f78984a549894e0e8c4d6a253e540, ^^^ which caused a regression in the default for flag_excess_precision. -- H.J.
Re: unnormal Intel 80-bit long doubles and isnanl
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 input), but if they result in buffer overflows, infinite loops or similar, that's fixed as a bug. Knowing what to call these numbers would be the first step towards knowing what to do with them, which is why I considered classification the first thing to tackle. Note that there are lots of libm function implementations, not just isnanl, which work by looking at the encoding without considering the possibility it might be one of the kinds of encodings (other than sNaN) that cannot result from floating-point arithmetic. This includes both ldbl-96 implementations in C and implementations in assembly for i386 and x86_64, and probably implementations for m68k and ia64 as well. iscanonical is the only operation in glibc that deliberately tries to detect and produce defined results for these encodings. Once we have consensus on what unnormals are, it will be much easier for me to work through the toolchain and ensure that we consistently treat them as NaNs. 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? Siddhesh
For contribution and participation
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.
Re: Reassociation and trapping operations
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 == b). I don't think this is correct, because (a <= b) traps and (a == b) doesn't. Hello, let me just mention the old https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53805 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53806 There has been some debate about the exact meaning of -ftrapping-math, but don't let that stop you. -- Marc Glisse
