public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/110622] New: x86: Miscompilation at O1 level (O0 is working)
@ 2023-07-11 6:28 malat at debian dot org
2023-07-11 6:29 ` [Bug c++/110622] " malat at debian dot org
` (15 more replies)
0 siblings, 16 replies; 17+ messages in thread
From: malat at debian dot org @ 2023-07-11 6:28 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110622
Bug ID: 110622
Summary: x86: Miscompilation at O1 level (O0 is working)
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: malat at debian dot org
Target Milestone: ---
I can trigger an assertion in highway unit test suite on Debian/i386 when using
-O1 (does not happen at -O0).
Symptoms:
[...]
f32x2: Log1p(5.5968112995194757e-20) expected 5.5968112995194757e-20 actual 0
ulp 5.28754e+08 max ulp 3
[...]
For some reason the code return exactly zero (0) during a math computation of a
log1p function. The code runs fine at O2 on all other Debian arches (amd64,
mipsel, armel, ppc32 ...).
Since the return value is exactly 0, I suspect this is not a case of excess
precision (x87). This is not a hardware issue as I can reproduce it on multiple
hosts (Debian buildds machine, and x86 porterbox).
If I extract the math logic and call it in a `main` function, then the compiler
is able to optimize the code correctly (even at O2) and return appropriate
result (correct tolerance).
I did not observe any suspicious behavior under valgrind and/or -fsanitize.
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug c++/110622] x86: Miscompilation at O1 level (O0 is working)
2023-07-11 6:28 [Bug c++/110622] New: x86: Miscompilation at O1 level (O0 is working) malat at debian dot org
@ 2023-07-11 6:29 ` malat at debian dot org
2023-07-11 6:30 ` malat at debian dot org
` (14 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: malat at debian dot org @ 2023-07-11 6:29 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110622
--- Comment #1 from Mathieu Malaterre <malat at debian dot org> ---
For reference:
* https://github.com/google/highway/issues/1488#issuecomment-1621528097
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug c++/110622] x86: Miscompilation at O1 level (O0 is working)
2023-07-11 6:28 [Bug c++/110622] New: x86: Miscompilation at O1 level (O0 is working) malat at debian dot org
2023-07-11 6:29 ` [Bug c++/110622] " malat at debian dot org
@ 2023-07-11 6:30 ` malat at debian dot org
2023-07-11 6:31 ` pinskia at gcc dot gnu.org
` (13 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: malat at debian dot org @ 2023-07-11 6:30 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110622
--- Comment #2 from Mathieu Malaterre <malat at debian dot org> ---
Created attachment 55518
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55518&action=edit
Preprocessed source
% /usr/bin/g++-13 -save-temps -DHWY_STATIC_DEFINE -DTOOLCHAIN_MISS_ASM_HWCAP_H
-I/home/mathieu/Perso/highway -O1 -fPIE -fvisibility=hidden
-fvisibility-inlines-hidden -Wno-builtin-macro-redefined
-D__DATE__=\"redacted\" -D__TIMESTAMP__=\"redacted\" -D__TIME__=\"redacted\"
-fmerge-all-constants -Wall -Wextra -Wconversion -Wsign-conversion -Wvla
-Wnon-virtual-dtor -fmath-errno -fno-exceptions -DHWY_IS_TEST=1
-DGTEST_HAS_PTHREAD=1 -MD -MT
CMakeFiles/math_test.dir/hwy/contrib/math/math_test.cc.o -MF
CMakeFiles/math_test.dir/hwy/contrib/math/math_test.cc.o.d -o
CMakeFiles/math_test.dir/hwy/contrib/math/math_test.cc.o -c
/home/mathieu/Perso/highway/hwy/contrib/math/math_test.cc
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug c++/110622] x86: Miscompilation at O1 level (O0 is working)
2023-07-11 6:28 [Bug c++/110622] New: x86: Miscompilation at O1 level (O0 is working) malat at debian dot org
2023-07-11 6:29 ` [Bug c++/110622] " malat at debian dot org
2023-07-11 6:30 ` malat at debian dot org
@ 2023-07-11 6:31 ` pinskia at gcc dot gnu.org
2023-07-11 6:33 ` malat at debian dot org
` (12 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-07-11 6:31 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110622
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
See Also| |https://github.com/google/h
| |ighway/issues/1488#issuecom
| |ment-1621528097
--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Does adding -fexcess-precision=standard help? What about -ffloat-store ?
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug c++/110622] x86: Miscompilation at O1 level (O0 is working)
2023-07-11 6:28 [Bug c++/110622] New: x86: Miscompilation at O1 level (O0 is working) malat at debian dot org
` (2 preceding siblings ...)
2023-07-11 6:31 ` pinskia at gcc dot gnu.org
@ 2023-07-11 6:33 ` malat at debian dot org
2023-07-11 6:33 ` malat at debian dot org
` (11 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: malat at debian dot org @ 2023-07-11 6:33 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110622
--- Comment #4 from Mathieu Malaterre <malat at debian dot org> ---
Here is my current state of work:
*
https://github.com/malaterre/highway/commit/771ca57d2d29b48f91beae033f6854f9b2dfb730
I am open to suggestion to further reduce the test case, as I am not familiar
with those sort of symptoms and how to drive c-reduce in this case.
Thanks all
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug c++/110622] x86: Miscompilation at O1 level (O0 is working)
2023-07-11 6:28 [Bug c++/110622] New: x86: Miscompilation at O1 level (O0 is working) malat at debian dot org
` (3 preceding siblings ...)
2023-07-11 6:33 ` malat at debian dot org
@ 2023-07-11 6:33 ` malat at debian dot org
2023-07-11 6:38 ` pinskia at gcc dot gnu.org
` (10 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: malat at debian dot org @ 2023-07-11 6:33 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110622
--- Comment #5 from Mathieu Malaterre <malat at debian dot org> ---
> Does adding -fexcess-precision=standard help? What about -ffloat-store ?
highway is c++ only. Those flags are C only
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug c++/110622] x86: Miscompilation at O1 level (O0 is working)
2023-07-11 6:28 [Bug c++/110622] New: x86: Miscompilation at O1 level (O0 is working) malat at debian dot org
` (4 preceding siblings ...)
2023-07-11 6:33 ` malat at debian dot org
@ 2023-07-11 6:38 ` pinskia at gcc dot gnu.org
2023-07-11 6:44 ` [Bug target/110622] " malat at debian dot org
` (9 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-07-11 6:38 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110622
--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Mathieu Malaterre from comment #5)
> > Does adding -fexcess-precision=standard help? What about -ffloat-store ?
>
> highway is c++ only. Those flags are C only
No they are not. -fexcess-precision=standard C++ was added for GCC 13.
-ffloat-store is generic middle-end option and has been supported by all
front-ends since at least GCC 3.
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug target/110622] x86: Miscompilation at O1 level (O0 is working)
2023-07-11 6:28 [Bug c++/110622] New: x86: Miscompilation at O1 level (O0 is working) malat at debian dot org
` (5 preceding siblings ...)
2023-07-11 6:38 ` pinskia at gcc dot gnu.org
@ 2023-07-11 6:44 ` malat at debian dot org
2023-07-11 8:25 ` malat at debian dot org
` (8 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: malat at debian dot org @ 2023-07-11 6:44 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110622
Mathieu Malaterre <malat at debian dot org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |INVALID
Status|UNCONFIRMED |RESOLVED
--- Comment #7 from Mathieu Malaterre <malat at debian dot org> ---
Either `-fexcess-precision=standard` or `-ffloat-store` makes the symptoms go
away (tested at -O2).
Sorry for the noise. Thanks for the quick suggestion.
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug target/110622] x86: Miscompilation at O1 level (O0 is working)
2023-07-11 6:28 [Bug c++/110622] New: x86: Miscompilation at O1 level (O0 is working) malat at debian dot org
` (6 preceding siblings ...)
2023-07-11 6:44 ` [Bug target/110622] " malat at debian dot org
@ 2023-07-11 8:25 ` malat at debian dot org
2023-09-21 9:44 ` malat at debian dot org
` (7 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: malat at debian dot org @ 2023-07-11 8:25 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110622
Mathieu Malaterre <malat at debian dot org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|INVALID |DUPLICATE
--- Comment #8 from Mathieu Malaterre <malat at debian dot org> ---
*** This bug has been marked as a duplicate of bug 323 ***
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug target/110622] x86: Miscompilation at O1 level (O0 is working)
2023-07-11 6:28 [Bug c++/110622] New: x86: Miscompilation at O1 level (O0 is working) malat at debian dot org
` (7 preceding siblings ...)
2023-07-11 8:25 ` malat at debian dot org
@ 2023-09-21 9:44 ` malat at debian dot org
2023-09-21 9:48 ` [Bug target/110622] x87: Miscompilation at O2 level (O1 " malat at debian dot org
` (6 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: malat at debian dot org @ 2023-09-21 9:44 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110622
Mathieu Malaterre <malat at debian dot org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|DUPLICATE |---
Status|RESOLVED |UNCONFIRMED
--- Comment #9 from Mathieu Malaterre <malat at debian dot org> ---
(In reply to Mathieu Malaterre from comment #7)
> Either `-fexcess-precision=standard` or `-ffloat-store` makes the symptoms
> go away (tested at -O2).
The above statement is 100% accurate. However I still believe the optimizer is
doing a little too much on a limited range of values. Let me provide a reduce
test case.
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug target/110622] x87: Miscompilation at O2 level (O1 is working)
2023-07-11 6:28 [Bug c++/110622] New: x86: Miscompilation at O1 level (O0 is working) malat at debian dot org
` (8 preceding siblings ...)
2023-09-21 9:44 ` malat at debian dot org
@ 2023-09-21 9:48 ` malat at debian dot org
2023-09-21 9:51 ` malat at debian dot org
` (5 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: malat at debian dot org @ 2023-09-21 9:48 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110622
--- Comment #10 from Mathieu Malaterre <malat at debian dot org> ---
Created attachment 55959
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55959&action=edit
cvise reduced test case
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug target/110622] x87: Miscompilation at O2 level (O1 is working)
2023-07-11 6:28 [Bug c++/110622] New: x86: Miscompilation at O1 level (O0 is working) malat at debian dot org
` (9 preceding siblings ...)
2023-09-21 9:48 ` [Bug target/110622] x87: Miscompilation at O2 level (O1 " malat at debian dot org
@ 2023-09-21 9:51 ` malat at debian dot org
2023-09-21 9:56 ` malat at debian dot org
` (4 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: malat at debian dot org @ 2023-09-21 9:51 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110622
--- Comment #11 from Mathieu Malaterre <malat at debian dot org> ---
Typical setup:
g++ -fno-asynchronous-unwind-tables -fno-exceptions -fno-rtti -DHIDESYMPTOM
-std=c++11 -g -m32 -fexcess-precision=fast -O2 -o works math_test.cc
-Wfatal-errors -Wall -Wextra -Wpedantic -Wconversion -Werror
and:
g++ -fno-asynchronous-unwind-tables -fno-exceptions -fno-rtti -std=c++11 -g
-m32 -fexcess-precision=fast -O2 -o fails math_test.cc -Wfatal-errors -Wall
-Wextra -Wpedantic -Wconversion -Werror
You can observe that the only difference is that I am preventing an elision :
```
% grep -A2 HIDE math_test.cc
#ifdef HIDESYMPTOM
asm volatile("" : "+r"(y.raw[0]) : : "memory");
#endif
```
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug target/110622] x87: Miscompilation at O2 level (O1 is working)
2023-07-11 6:28 [Bug c++/110622] New: x86: Miscompilation at O1 level (O0 is working) malat at debian dot org
` (10 preceding siblings ...)
2023-09-21 9:51 ` malat at debian dot org
@ 2023-09-21 9:56 ` malat at debian dot org
2023-09-21 13:33 ` pinskia at gcc dot gnu.org
` (3 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: malat at debian dot org @ 2023-09-21 9:56 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110622
--- Comment #12 from Mathieu Malaterre <malat at debian dot org> ---
I am seeing a difference in result (log1p computation) in the range:
4318952042648305665 - 0x1.0000000000001p-64
4368493837572636672 - 0x1.002p-53
the other values seems to match expectation of log1p computation.
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug target/110622] x87: Miscompilation at O2 level (O1 is working)
2023-07-11 6:28 [Bug c++/110622] New: x86: Miscompilation at O1 level (O0 is working) malat at debian dot org
` (11 preceding siblings ...)
2023-09-21 9:56 ` malat at debian dot org
@ 2023-09-21 13:33 ` pinskia at gcc dot gnu.org
2023-09-21 13:42 ` malat at debian dot org
` (2 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-09-21 13:33 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110622
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |DUPLICATE
Status|UNCONFIRMED |RESOLVED
--- Comment #13 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Mathieu Malaterre from comment #12)
> I am seeing a difference in result (log1p computation) in the range:
>
> 4318952042648305665 - 0x1.0000000000001p-64
> 4368493837572636672 - 0x1.002p-53
>
> the other values seems to match expectation of log1p computation.
But you used excess-precision=fast
*** This bug has been marked as a duplicate of bug 323 ***
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug target/110622] x87: Miscompilation at O2 level (O1 is working)
2023-07-11 6:28 [Bug c++/110622] New: x86: Miscompilation at O1 level (O0 is working) malat at debian dot org
` (12 preceding siblings ...)
2023-09-21 13:33 ` pinskia at gcc dot gnu.org
@ 2023-09-21 13:42 ` malat at debian dot org
2023-09-21 13:45 ` xry111 at gcc dot gnu.org
2023-09-21 14:29 ` malat at debian dot org
15 siblings, 0 replies; 17+ messages in thread
From: malat at debian dot org @ 2023-09-21 13:42 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110622
--- Comment #14 from Mathieu Malaterre <malat at debian dot org> ---
(In reply to Andrew Pinski from comment #13)
> (In reply to Mathieu Malaterre from comment #12)
> > I am seeing a difference in result (log1p computation) in the range:
> >
> > 4318952042648305665 - 0x1.0000000000001p-64
> > 4368493837572636672 - 0x1.002p-53
> >
> > the other values seems to match expectation of log1p computation.
>
> But you used excess-precision=fast
>
> *** This bug has been marked as a duplicate of bug 323 ***
AFAIK bug #323 does not mention my trick:
asm volatile("" : "+r"(y.raw[0]) : : "memory");
That simple line totally changed the optimizer code generation.
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug target/110622] x87: Miscompilation at O2 level (O1 is working)
2023-07-11 6:28 [Bug c++/110622] New: x86: Miscompilation at O1 level (O0 is working) malat at debian dot org
` (13 preceding siblings ...)
2023-09-21 13:42 ` malat at debian dot org
@ 2023-09-21 13:45 ` xry111 at gcc dot gnu.org
2023-09-21 14:29 ` malat at debian dot org
15 siblings, 0 replies; 17+ messages in thread
From: xry111 at gcc dot gnu.org @ 2023-09-21 13:45 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110622
--- Comment #15 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
(In reply to Mathieu Malaterre from comment #14)
> (In reply to Andrew Pinski from comment #13)
> > (In reply to Mathieu Malaterre from comment #12)
> > > I am seeing a difference in result (log1p computation) in the range:
> > >
> > > 4318952042648305665 - 0x1.0000000000001p-64
> > > 4368493837572636672 - 0x1.002p-53
> > >
> > > the other values seems to match expectation of log1p computation.
> >
> > But you used excess-precision=fast
> >
> > *** This bug has been marked as a duplicate of bug 323 ***
>
> AFAIK bug #323 does not mention my trick:
>
> asm volatile("" : "+r"(y.raw[0]) : : "memory");
>
> That simple line totally changed the optimizer code generation.
Because in x87 the excessive precision only exists in x87 stack-like registers.
The "memory" clobber forces a store and reload for all non-register variables,
thus the value is truncated into a normal double value and the excessive
precision is lost.
There are infinite ways to work around an issue, but it does not mean PR 323
must mention all of them.
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug target/110622] x87: Miscompilation at O2 level (O1 is working)
2023-07-11 6:28 [Bug c++/110622] New: x86: Miscompilation at O1 level (O0 is working) malat at debian dot org
` (14 preceding siblings ...)
2023-09-21 13:45 ` xry111 at gcc dot gnu.org
@ 2023-09-21 14:29 ` malat at debian dot org
15 siblings, 0 replies; 17+ messages in thread
From: malat at debian dot org @ 2023-09-21 14:29 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110622
--- Comment #16 from Mathieu Malaterre <malat at debian dot org> ---
(In reply to Xi Ruoyao from comment #15)
> (In reply to Mathieu Malaterre from comment #14)
> > (In reply to Andrew Pinski from comment #13)
> > > (In reply to Mathieu Malaterre from comment #12)
> > > > I am seeing a difference in result (log1p computation) in the range:
> > > >
> > > > 4318952042648305665 - 0x1.0000000000001p-64
> > > > 4368493837572636672 - 0x1.002p-53
> > > >
> > > > the other values seems to match expectation of log1p computation.
> > >
> > > But you used excess-precision=fast
> > >
> > > *** This bug has been marked as a duplicate of bug 323 ***
> >
> > AFAIK bug #323 does not mention my trick:
> >
> > asm volatile("" : "+r"(y.raw[0]) : : "memory");
> >
> > That simple line totally changed the optimizer code generation.
>
> Because in x87 the excessive precision only exists in x87 stack-like
> registers. The "memory" clobber forces a store and reload for all
> non-register variables, thus the value is truncated into a normal double
> value and the excessive precision is lost.
>
> There are infinite ways to work around an issue, but it does not mean PR 323
> must mention all of them.
Oh, I see. Basically my trick is convoluted `-ffloat-store`.
I finally took myself by the hand and convinced me with a simple code:
```
// gcc -m32 -fexcess-precision=fast -O2 t.c
#include <inttypes.h>
#include <stdint.h>
#include <stdio.h>
#include <string.h>
[[gnu::noipa]] void test(uint64_t v, double x, double y) {
const double y2 = x + 1.0;
if (y != y2)
printf("error %" PRIu64 " %.17g %a\n", v, x, x);
else
printf("ok %" PRIu64 " %.17g %a\n", v, x, x);
}
void main() {
uint64_t kSamplesPerRange = 4000, start = 0, stop = 9218868437227405311;
uint64_t step = (stop / kSamplesPerRange);
for (uint64_t value_bits = start; value_bits <= stop; value_bits += step) {
double value;
memcpy(&value, &value_bits, sizeof value);
double x = value;
double y = x + 1.0;
test(value_bits, x, y);
}
}
```
please accept my apologies for the noise.
^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2023-09-21 14:29 UTC | newest]
Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-07-11 6:28 [Bug c++/110622] New: x86: Miscompilation at O1 level (O0 is working) malat at debian dot org
2023-07-11 6:29 ` [Bug c++/110622] " malat at debian dot org
2023-07-11 6:30 ` malat at debian dot org
2023-07-11 6:31 ` pinskia at gcc dot gnu.org
2023-07-11 6:33 ` malat at debian dot org
2023-07-11 6:33 ` malat at debian dot org
2023-07-11 6:38 ` pinskia at gcc dot gnu.org
2023-07-11 6:44 ` [Bug target/110622] " malat at debian dot org
2023-07-11 8:25 ` malat at debian dot org
2023-09-21 9:44 ` malat at debian dot org
2023-09-21 9:48 ` [Bug target/110622] x87: Miscompilation at O2 level (O1 " malat at debian dot org
2023-09-21 9:51 ` malat at debian dot org
2023-09-21 9:56 ` malat at debian dot org
2023-09-21 13:33 ` pinskia at gcc dot gnu.org
2023-09-21 13:42 ` malat at debian dot org
2023-09-21 13:45 ` xry111 at gcc dot gnu.org
2023-09-21 14:29 ` malat at debian dot org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).