On(c)e more: optimizer failure

On(c)e more: optimizer failure

[Stefan Kanthak]

Hi,

the following snippet is from the nextafter() function of
<http://www.netlib.no/netlib/toms/722>

--- repro.c ---
#define Zero 0.0
double nextafter(double argx, double argy)
{
    double z = argx;

    if (isnan(argx) || isnan(argy)) return argx + argy;

    if (argx == argy) return argx;

    if (argx != Zero)
        if (((argx < Zero) && (argx < argy))
         || ((argx > Zero) && (argx > argy)))
            z += 1.0;
        else
            z -= 1.0;
    return z;
}
--- EOF ---

I expect that GCC knows DeMorgan's rules and is able to
simplify/optimize the last if-statement to

        if ((argx < Zero) == (argx < argy))

Unfortunately GCC fails to do so: see the lines from
label .L20: to label L7

$ gcc -m64 -O3 -o- -S
...
nextafter:
        ucomisd %xmm1, %xmm0
        jp      .L19
        pxor    %xmm2, %xmm2
        movl    $1, %edx
        ucomisd %xmm2, %xmm0
        setp    %al
        cmovne  %edx, %eax
        testb   %al, %al
        je      .L3
        ucomisd %xmm1, %xmm0
        setp    %al
        cmove   %eax, %edx
        testb   %dl, %dl
        jne     .L20
.L3:
        ret
.L20:
        comisd  %xmm0, %xmm2
        ja      .L21
.L4:
        comisd  %xmm2, %xmm0
        jbe     .L7
        comisd  %xmm1, %xmm0
        jbe     .L7
.L6:
        addsd   .LC1(%rip), %xmm0
        ret
.L21:
        comisd  %xmm0, %xmm1
        ja      .L6
        jmp     .L4
.L7:
        subsd   .LC1(%rip), %xmm0
        ret
.L19:
        addsd   %xmm1, %xmm0
        ret
.LC1:
        .long   0
        .long   1072693248

Stefan

Re: On(c)e more: optimizer failure

[Matt Godbolt]

I believe your example doesn't take into account that the values can be NaN
which compares false in all situations. If you allow the compiler to
optimize without supporting NaN (-ffast-math), I think it generates the
code you want: https://godbolt.org/z/1ra7zcsnd

--matt

On Sat, Aug 21, 2021 at 1:59 PM Stefan Kanthak <stefan.kanthak@nexgo.de>
wrote:

> Hi,
>
> the following snippet is from the nextafter() function of
> <http://www.netlib.no/netlib/toms/722>
>
> --- repro.c ---
> #define Zero 0.0
> double nextafter(double argx, double argy)
> {
>     double z = argx;
>
>     if (isnan(argx) || isnan(argy)) return argx + argy;
>
>     if (argx == argy) return argx;
>
>     if (argx != Zero)
>         if (((argx < Zero) && (argx < argy))
>          || ((argx > Zero) && (argx > argy)))
>             z += 1.0;
>         else
>             z -= 1.0;
>     return z;
> }
> --- EOF ---
>
> I expect that GCC knows DeMorgan's rules and is able to
> simplify/optimize the last if-statement to
>
>         if ((argx < Zero) == (argx < argy))
>
> Unfortunately GCC fails to do so: see the lines from
> label .L20: to label L7
>
> $ gcc -m64 -O3 -o- -S
> ...
> nextafter:
>         ucomisd %xmm1, %xmm0
>         jp      .L19
>         pxor    %xmm2, %xmm2
>         movl    $1, %edx
>         ucomisd %xmm2, %xmm0
>         setp    %al
>         cmovne  %edx, %eax
>         testb   %al, %al
>         je      .L3
>         ucomisd %xmm1, %xmm0
>         setp    %al
>         cmove   %eax, %edx
>         testb   %dl, %dl
>         jne     .L20
> .L3:
>         ret
> .L20:
>         comisd  %xmm0, %xmm2
>         ja      .L21
> .L4:
>         comisd  %xmm2, %xmm0
>         jbe     .L7
>         comisd  %xmm1, %xmm0
>         jbe     .L7
> .L6:
>         addsd   .LC1(%rip), %xmm0
>         ret
> .L21:
>         comisd  %xmm0, %xmm1
>         ja      .L6
>         jmp     .L4
> .L7:
>         subsd   .LC1(%rip), %xmm0
>         ret
> .L19:
>         addsd   %xmm1, %xmm0
>         ret
> .LC1:
>         .long   0
>         .long   1072693248
>
> Stefan
>


-- 
Matt
(he/him)

Re: On(c)e more: optimizer failure

[Stefan Kanthak]

Matt Godbolt <matt@godbolt.org> wrote:

> I believe your example doesn't take into account that the values can be NaN
> which compares false in all situations.

That's a misbelief!
Please notice the first if-clause, which rules out NaNs for both arguments.
Also notice that GCC did NOT generate JP after the 4 COMISD instructions
in question, i.e. it knew that NaNs had been ruled out.
I included the 3 initial if-clauses just to give GCC enough rope to hang 
himself.

> If you allow the compiler to
> optimize without supporting NaN (-ffast-math), I think it generates the
> code you want: https://godbolt.org/z/1ra7zcsnd

Replace
     if (isnan(argx) || isnan(argy)) return argx + argy;
with
     if ((argx != argx) || (argy != argy)) return argx + argy;
then feed the changed snippet to compiler explorer again, with and without
-ffast-math

Stefan
 
> --matt
> 
> On Sat, Aug 21, 2021 at 1:59 PM Stefan Kanthak <stefan.kanthak@nexgo.de>
> wrote:
> 
>> Hi,
>>
>> the following snippet is from the nextafter() function of
>> <http://www.netlib.no/netlib/toms/722>
>>
>> --- repro.c ---
>> #define Zero 0.0
>> double nextafter(double argx, double argy)
>> {
>>     double z = argx;
>>
>>     if (isnan(argx) || isnan(argy)) return argx + argy;
>>
>>     if (argx == argy) return argx;
>>
>>     if (argx != Zero)
>>         if (((argx < Zero) && (argx < argy))
>>          || ((argx > Zero) && (argx > argy)))
>>             z += 1.0;
>>         else
>>             z -= 1.0;
>>     return z;
>> }
>> --- EOF ---
>>
>> I expect that GCC knows DeMorgan's rules and is able to
>> simplify/optimize the last if-statement to
>>
>>         if ((argx < Zero) == (argx < argy))
>>
>> Unfortunately GCC fails to do so: see the lines from
>> label .L20: to label L7
>>
>> $ gcc -m64 -O3 -o- -S
>> ...
>> nextafter:
>>         ucomisd %xmm1, %xmm0
>>         jp      .L19
>>         pxor    %xmm2, %xmm2
>>         movl    $1, %edx
>>         ucomisd %xmm2, %xmm0
>>         setp    %al
>>         cmovne  %edx, %eax
>>         testb   %al, %al
>>         je      .L3
>>         ucomisd %xmm1, %xmm0
>>         setp    %al
>>         cmove   %eax, %edx
>>         testb   %dl, %dl
>>         jne     .L20
>> .L3:
>>         ret
>> .L20:
>>         comisd  %xmm0, %xmm2
>>         ja      .L21
>> .L4:
>>         comisd  %xmm2, %xmm0
>>         jbe     .L7
>>         comisd  %xmm1, %xmm0
>>         jbe     .L7
>> .L6:
>>         addsd   .LC1(%rip), %xmm0
>>         ret
>> .L21:
>>         comisd  %xmm0, %xmm1
>>         ja      .L6
>>         jmp     .L4
>> .L7:
>>         subsd   .LC1(%rip), %xmm0
>>         ret
>> .L19:
>>         addsd   %xmm1, %xmm0
>>         ret
>> .LC1:
>>         .long   0
>>         .long   1072693248
>>
>> Stefan
>>
> 
> 
> -- 
> Matt
> (he/him)
>

Re: On(c)e more: optimizer failure

[Matt Godbolt]

Ok! Thanks; sorry for the misunderstanding on my side.

--matt

On Sat, Aug 21, 2021 at 2:53 PM Stefan Kanthak <stefan.kanthak@nexgo.de>
wrote:

> Matt Godbolt <matt@godbolt.org> wrote:
>
> > I believe your example doesn't take into account that the values can be
> NaN
> > which compares false in all situations.
>
> That's a misbelief!
> Please notice the first if-clause, which rules out NaNs for both arguments.
> Also notice that GCC did NOT generate JP after the 4 COMISD instructions
> in question, i.e. it knew that NaNs had been ruled out.
> I included the 3 initial if-clauses just to give GCC enough rope to hang
> himself.
>
> > If you allow the compiler to
> > optimize without supporting NaN (-ffast-math), I think it generates the
> > code you want: https://godbolt.org/z/1ra7zcsnd
>
> Replace
>      if (isnan(argx) || isnan(argy)) return argx + argy;
> with
>      if ((argx != argx) || (argy != argy)) return argx + argy;
> then feed the changed snippet to compiler explorer again, with and without
> -ffast-math
>
> Stefan
>
> > --matt
> >
> > On Sat, Aug 21, 2021 at 1:59 PM Stefan Kanthak <stefan.kanthak@nexgo.de>
> > wrote:
> >
> >> Hi,
> >>
> >> the following snippet is from the nextafter() function of
> >> <http://www.netlib.no/netlib/toms/722>
> >>
> >> --- repro.c ---
> >> #define Zero 0.0
> >> double nextafter(double argx, double argy)
> >> {
> >>     double z = argx;
> >>
> >>     if (isnan(argx) || isnan(argy)) return argx + argy;
> >>
> >>     if (argx == argy) return argx;
> >>
> >>     if (argx != Zero)
> >>         if (((argx < Zero) && (argx < argy))
> >>          || ((argx > Zero) && (argx > argy)))
> >>             z += 1.0;
> >>         else
> >>             z -= 1.0;
> >>     return z;
> >> }
> >> --- EOF ---
> >>
> >> I expect that GCC knows DeMorgan's rules and is able to
> >> simplify/optimize the last if-statement to
> >>
> >>         if ((argx < Zero) == (argx < argy))
> >>
> >> Unfortunately GCC fails to do so: see the lines from
> >> label .L20: to label L7
> >>
> >> $ gcc -m64 -O3 -o- -S
> >> ...
> >> nextafter:
> >>         ucomisd %xmm1, %xmm0
> >>         jp      .L19
> >>         pxor    %xmm2, %xmm2
> >>         movl    $1, %edx
> >>         ucomisd %xmm2, %xmm0
> >>         setp    %al
> >>         cmovne  %edx, %eax
> >>         testb   %al, %al
> >>         je      .L3
> >>         ucomisd %xmm1, %xmm0
> >>         setp    %al
> >>         cmove   %eax, %edx
> >>         testb   %dl, %dl
> >>         jne     .L20
> >> .L3:
> >>         ret
> >> .L20:
> >>         comisd  %xmm0, %xmm2
> >>         ja      .L21
> >> .L4:
> >>         comisd  %xmm2, %xmm0
> >>         jbe     .L7
> >>         comisd  %xmm1, %xmm0
> >>         jbe     .L7
> >> .L6:
> >>         addsd   .LC1(%rip), %xmm0
> >>         ret
> >> .L21:
> >>         comisd  %xmm0, %xmm1
> >>         ja      .L6
> >>         jmp     .L4
> >> .L7:
> >>         subsd   .LC1(%rip), %xmm0
> >>         ret
> >> .L19:
> >>         addsd   %xmm1, %xmm0
> >>         ret
> >> .LC1:
> >>         .long   0
> >>         .long   1072693248
> >>
> >> Stefan
> >>
> >
> >
> > --
> > Matt
> > (he/him)
> >
>


-- 
Matt
(he/him)

Re: On(c)e more: optimizer failure

[Jakub Jelinek]

On Sat, Aug 21, 2021 at 09:40:16PM +0200, Stefan Kanthak wrote:
> > I believe your example doesn't take into account that the values can be NaN
> > which compares false in all situations.
> 
> That's a misbelief!
> Please notice the first if-clause, which rules out NaNs for both arguments.
> Also notice that GCC did NOT generate JP after the 4 COMISD instructions
> in question, i.e. it knew that NaNs had been ruled out.

GCC doesn't do value range propagation of floating point values, not even
the special ones like NaNs, infinities, +/- zeros etc., and without that the
earlier ifs aren't taken into account for the earlier code.

Also, as you have been told already, sending these mails to gcc mailing list
is a very bad idea, unless somebody jumps on it immediately and implements
it, they will be effectively forgotten.  You should file missed
optimizations into gcc bugzilla where they can be seen any time.

	Jakub

Re: On(c)e more: optimizer failure

[Stefan Kanthak]

Jakub Jelinek <jakub@redhat.com> wrote:

> On Sat, Aug 21, 2021 at 09:40:16PM +0200, Stefan Kanthak wrote:
>> > I believe your example doesn't take into account that the values can be NaN
>> > which compares false in all situations.
>> 
>> That's a misbelief!
>> Please notice the first if-clause, which rules out NaNs for both arguments.
>> Also notice that GCC did NOT generate JP after the 4 COMISD instructions
>> in question, i.e. it knew that NaNs had been ruled out.
> 
> GCC doesn't do value range propagation of floating point values, not even
> the special ones like NaNs, infinities, +/- zeros etc., and without that the
> earlier ifs aren't taken into account for the earlier code.

Ouch, to bad! That was but the very least expectation I had.
And indeed, removing the 3 other if-clauses doesn't change how the
final if-clause gets translated.

Sorry Matt, we were both wrong with our assumptions.

> Also, as you have been told already, sending these mails to gcc mailing list
> is a very bad idea, unless somebody jumps on it immediately and implements
> it, they will be effectively forgotten.  You should file missed
> optimizations into gcc bugzilla where they can be seen any time.

I don't have a bugzilla account, and I don't use GCC for anything serious.

Stefan

Re: On(c)e more: optimizer failure

[Gabriel Ravier]

On 8/21/21 10:19 PM, Stefan Kanthak wrote:
> Jakub Jelinek <jakub@redhat.com> wrote:
>
>> On Sat, Aug 21, 2021 at 09:40:16PM +0200, Stefan Kanthak wrote:
>>>> I believe your example doesn't take into account that the values can be NaN
>>>> which compares false in all situations.
>>> That's a misbelief!
>>> Please notice the first if-clause, which rules out NaNs for both arguments.
>>> Also notice that GCC did NOT generate JP after the 4 COMISD instructions
>>> in question, i.e. it knew that NaNs had been ruled out.
>> GCC doesn't do value range propagation of floating point values, not even
>> the special ones like NaNs, infinities, +/- zeros etc., and without that the
>> earlier ifs aren't taken into account for the earlier code.
> Ouch, to bad! That was but the very least expectation I had.
> And indeed, removing the 3 other if-clauses doesn't change how the
> final if-clause gets translated.
>
> Sorry Matt, we were both wrong with our assumptions.
>
>> Also, as you have been told already, sending these mails to gcc mailing list
>> is a very bad idea, unless somebody jumps on it immediately and implements
>> it, they will be effectively forgotten.  You should file missed
>> optimizations into gcc bugzilla where they can be seen any time.
> I don't have a bugzilla account, and I don't use GCC for anything serious.
>
> Stefan

It's *that* demanding for you to create a Bugzilla account ? From my 
experience, creating a Bugzilla account takes around 30 seconds (though 
I suppose you'd have to wait for a bit if automatic account creation is 
temporarily disabled), it quite honestly feels as though you've spent 
far more time writing out these e-mails and talking here on the mailing 
list than that.

On Bugzilla I've had some optimization bug reports of mine take months 
to get a response and more to get fixed, but at least something happened 
after a while: if I just went on the mailing list it's incredibly likely 
they'd have been completely and utterly lost to time (it's not that GCC 
devs don't like the mailing list, but there's a reason a *bug tracking 
system* is used...)

Re: On(c)e more: optimizer failure

[Jonathan Wakely]

On Sun, 22 Aug 2021, 06:38 Gabriel Ravier wrote:

> On 8/21/21 10:19 PM, Stefan Kanthak wrote:
> > I don't have a bugzilla account, and I don't use GCC for anything
> serious.
> >
> > Stefan
>
> It's *that* demanding for you to create a Bugzilla account ? From my
> experience, creating a Bugzilla account takes around 30 seconds (though
> I suppose you'd have to wait for a bit if automatic account creation is
> temporarily disabled),


Yes, if creating an account online fails you just have to send one email
and we'll create it manually.

Re: On(c)e more: optimizer failure

[Stefan Kanthak]

Gabriel Ravier <gabravier@gmail.com> wrote:

> On 8/21/21 10:19 PM, Stefan Kanthak wrote:
>> Jakub Jelinek <jakub@redhat.com> wrote:

[...]

>>> GCC doesn't do value range propagation of floating point values, not even
>>> the special ones like NaNs, infinities, +/- zeros etc., and without that the
>>> earlier ifs aren't taken into account for the earlier code.
>> Ouch, to bad! That was but the very least expectation I had.
>> And indeed, removing the 3 other if-clauses doesn't change how the
>> final if-clause gets translated.

[...]

>>> You should file missed optimizations into gcc bugzilla where they can be
>>> seen any time.

You should better implement such missing optimisations your users might
expect from a mature compiler.

>> I don't have a bugzilla account, and I don't use GCC for anything serious.
>>
>> Stefan
> 
> It's *that* demanding for you to create a Bugzilla account ?

You (and everybody else) if free to use GCC bugzilla.
Everybody and me is but also free NOT to use GCC bugzilla.

Stefan

Re: On(c)e more: optimizer failure

[Jonathan Wakely]

On Sun, 22 Aug 2021, 22:27 Stefan Kanthak, <stefan.kanthak@nexgo.de> wrote:

> Gabriel Ravier <gabravier@gmail.com> wrote:
>
> > On 8/21/21 10:19 PM, Stefan Kanthak wrote:
> >> Jakub Jelinek <jakub@redhat.com> wrote:
>
> [...]
>
> >>> GCC doesn't do value range propagation of floating point values, not
> even
> >>> the special ones like NaNs, infinities, +/- zeros etc., and without
> that the
> >>> earlier ifs aren't taken into account for the earlier code.
> >> Ouch, to bad! That was but the very least expectation I had.
> >> And indeed, removing the 3 other if-clauses doesn't change how the
> >> final if-clause gets translated.
>
> [...]
>
> >>> You should file missed optimizations into gcc bugzilla where they can
> be
> >>> seen any time.
>
> You should better implement such missing optimisations your users might
> expect from a mature compiler.
>
> >> I don't have a bugzilla account, and I don't use GCC for anything
> serious.
> >>
> >> Stefan
> >
> > It's *that* demanding for you to create a Bugzilla account ?
>
> You (and everybody else) if free to use GCC bugzilla.
> Everybody and me is but also free NOT to use GCC bugzilla.
>


Then your reports are likely to get ignored. It's that simple.

If you are really interested in helping to improve GCC you should file bugs
the same way everybody else does.

Re: On(c)e more: optimizer failure

[Gabriel Ravier]

On 8/22/21 11:22 PM, Stefan Kanthak wrote:
> Gabriel Ravier <gabravier@gmail.com> wrote:
>
>> On 8/21/21 10:19 PM, Stefan Kanthak wrote:
>>> Jakub Jelinek <jakub@redhat.com> wrote:
> [...]
>
>>>> You should file missed optimizations into gcc bugzilla where they can be
>>>> seen any time.
> You should better implement such missing optimisations your users might
> expect from a mature compiler.
>
>>> I don't have a bugzilla account, and I don't use GCC for anything serious.
>>>
>>> Stefan
>> It's *that* demanding for you to create a Bugzilla account ?
> You (and everybody else) if free to use GCC bugzilla.
> Everybody and me is but also free NOT to use GCC bugzilla.
>
> Stefan

Yes, you are free not to use the GCC Bugzilla. And GCC developers are 
free to prefer to see bug reports be made to the GCC Bugzilla, as it is 
the place dedicated to GCC bug reports, made specifically for that 
purpose and with the infrastructure to handle it.

What would you think if you had a Github or a Gitlab repository and some 
people felt the need to randomly e-mail you about bugs they found 
instead of filing them using the dedicated Issues system there ? And 
what would you say if, upon being recommended to use that system, they 
said that they are "free not to use" the system dedicated to helping 
them reporting bugs when reporting bugs ? To me, that would just sound 
rude and like they don't actually want to help find and fix bugs.

Re: On(c)e more: optimizer failure

[Stefan Kanthak]

Gabriel Ravier <gabravier@gmail.com> wrote:

> On 8/22/21 11:22 PM, Stefan Kanthak wrote:

[ 2bugzilla | !2bugzilla ]

>> You (and everybody else) if free to use GCC bugzilla.
>> Everybody and me is but also free NOT to use GCC bugzilla.
>>
>> Stefan
> 
> Yes, you are free not to use the GCC Bugzilla. And GCC developers are 
> free to prefer to see bug reports be made to the GCC Bugzilla, as it is 
> the place dedicated to GCC bug reports, made specifically for that 
> purpose and with the infrastructure to handle it.
> 
> What would you think if you had a Github or a Gitlab repository and some 
> people felt the need to randomly e-mail you about bugs they found 
> instead of filing them using the dedicated Issues system there ? And 
> what would you say if, upon being recommended to use that system, they 
> said that they are "free not to use" the system dedicated to helping 
> them reporting bugs when reporting bugs ? To me, that would just sound 
> rude and like they don't actually want to help find and fix bugs.

That's a VERY WILD and of course RUDE SPECULATION:
0. I'm old school, I don't use git-something.
1. I explicitly invite everybody who reads my web pages or uses code I
   publish there to send bug reports, comments, feedback, flames, ...
   per mail!
Before you ask: I receive quite some mail from complete strangers, even
bug reports.

I consider the statement on <https://gcc.gnu.org/lists.html>

| gcc is a high volume list for general development discussions about GCC.
| Anything relevant to the development or testing of GCC and not covered
  ~~~~~~~~~~~~~~~~~~~~~~~~                ~~~~~~~~~~~~~~
| by other mailing lists is suitable for discussion here.

as such an invitation too.

Stefan

JFTR: do you consider your wild speculations to be on-topic here?

Re: On(c)e more: optimizer failure

[Gabriel Ravier]

On 8/23/21 3:46 PM, Stefan Kanthak wrote:
 > Gabriel Ravier <gabravier@gmail.com> wrote:
 >
 >> On 8/22/21 11:22 PM, Stefan Kanthak wrote:
 >
 > [ 2bugzilla | !2bugzilla ]
 >
 >>> You (and everybody else) if free to use GCC bugzilla.
 >>> Everybody and me is but also free NOT to use GCC bugzilla.
 >>>
 >>> Stefan
 >>
 >> Yes, you are free not to use the GCC Bugzilla. And GCC developers are
 >> free to prefer to see bug reports be made to the GCC Bugzilla, as it is
 >> the place dedicated to GCC bug reports, made specifically for that
 >> purpose and with the infrastructure to handle it.
 >>
 >> What would you think if you had a Github or a Gitlab repository and 
some
 >> people felt the need to randomly e-mail you about bugs they found
 >> instead of filing them using the dedicated Issues system there ? And
 >> what would you say if, upon being recommended to use that system, they
 >> said that they are "free not to use" the system dedicated to helping
 >> them reporting bugs when reporting bugs ? To me, that would just sound
 >> rude and like they don't actually want to help find and fix bugs.
 >
 > That's a VERY WILD and of course RUDE SPECULATION:
 > 0. I'm old school, I don't use git-something.
 > 1. I explicitly invite everybody who reads my web pages or uses code I
 >    publish there to send bug reports, comments, feedback, flames, ...
 >    per mail!
 > Before you ask: I receive quite some mail from complete strangers, even
 > bug reports.

If you want an example that does not involve git: Let us assume some of 
your users started to randomly use rather impractical means of reporting 
bugs to you, like sending you letters or randomly accosting you in the 
street about them. It would be possible to try and handle those bugs, 
but would you not try to redirect those users to more practical means of 
making bug reports ?

Note that *you* may find e-mail to be a practical way of handling bug 
reports, but from what I know, the GCC development team have found that 
impractical and much less efficient than using a bug tracker, especially 
on such a huge project as GCC: if all the bugs that are reported on the 
Bugzilla were instead reported here and all the discussion about them 
was done here, then today there would have been no less than:
- 12 e-mails about new bugs, and
- 159 e-mails relating to existing bugs

 >
 > I consider the statement on <https://gcc.gnu.org/lists.html>
 >
 > | gcc is a high volume list for general development discussions about 
GCC.
 > | Anything relevant to the development or testing of GCC and not covered
 >   ~~~~~~~~~~~~~~~~~~~~~~~~                ~~~~~~~~~~~~~~
 > | by other mailing lists is suitable for discussion here.
 >
 > as such an invitation too.

While this might imply in some way that this mailing list might be 
appropriate for this purpose, would it have taken that much time to also 
take a look at the GCC homepage ? The sidebar has an entire "Bugs" 
section, including a link literally called "How to report", which states 
directly to "Please submit your bug report directly to the GCC bug 
tracker." and links to https://gcc.gnu.org/bugzilla/

 >
 > Stefan
 >
 > JFTR: do you consider your wild speculations to be on-topic here?

I suppose I should apologize: I did not intend to make any accusations 
here. I simply could not think at the time of any other reasons why you 
would be so hostile to the idea of using Bugzilla (when you've been 
explicitly told that sending issues to the mailing list is close to 
equivalent to sending them to /dev/null) and, not being a native English 
speaker, I must have formulated the message more aggressively than I 
intended. I also had been rather angered by you saying "You should 
better implement such missing optimisations your users might expect from 
a mature compiler" which I misinterpreted (at least, I hope so) as being 
some kind of threat.

Re: On(c)e more: optimizer failure

[Stefan Kanthak]

Gabriel Ravier <gabravier@gmail.com> wrote:

> On 8/23/21 3:46 PM, Stefan Kanthak wrote:

>> JFTR: do you consider your wild speculations to be on-topic here?
>
> I suppose I should apologize: I did not intend to make any accusations 
> here.

No need to, I can stand a little heat.

[...]

> I also had been rather angered by you saying "You should better implement
> such missing optimisations your users might expect from a mature compiler"
> which I misinterpreted (at least, I hope so) as being some kind of threat.

You did (the misinterpretation).
This was my direct reply to Jakub's
| You should file missed optimizations into gcc bugzilla where they can be
| seen any time.
Read it as "You should implement missing optimisations (independent from
a bug report) so your users get better code all the time."
The emphasis is on "You should" as well as "all the time."

Stefan

Re: On(c)e more: optimizer failure

[Manuel López-Ibáñez]

FWIW: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24021

Cheers,

Manuel.

Re: On(c)e more: optimizer failure

[Stefan Kanthak]

Manuel López-Ibáñez <manuel.lopez-ibanez@uma.es> wrote:

> FWIW: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24021

Thanks.
So this bug may soon have a driver's license in some countries...

One more for the road:

$ cat wtf.c
double wtf(double x) {
    return sqrt(x * x); // can the square ever be negative?
}
$ gcc -m64 -o- -O3 -S
...
        mulsd   %xmm0, %xmm0
        pxor    %xmm1, %xmm1
        ucomisd %xmm0, %xmm1
        ja      .L10
        sqrtsd  %xmm0, %xmm0
        ret
.L10:
        jmp     sqrt
...

Is the special case 0.0 worth the almost always taken, thus wrong
predicted branch?

JFTR: the PXOR incurs two cycles penalty on many Intel processors!
      Better use XORPD there.

Stefan