https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102575
Bug ID: 102575
Summary: Failure to optimize double _Complex stores to use
largest loads/stores possible
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102494
Bug ID: 102494
Summary: Failure to optimize out vector reduction properly
especially when using OpenMP
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101543
--- Comment #4 from Gabriel Ravier ---
Nevermind, didn't see this was an aarch64 bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101543
Gabriel Ravier changed:
What|Removed |Added
CC||gabravier at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=7061
Gabriel Ravier changed:
What|Removed |Added
CC||gabravier at gmail dot com
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102438
Bug ID: 102438
Summary: [x86-64] Failure to optimize out random extra
store+load in vector code when memcpy is used
Product: gcc
Version: 12.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54192
Gabriel Ravier changed:
What|Removed |Added
CC||gabravier at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48297
Gabriel Ravier changed:
What|Removed |Added
CC||gabravier at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102402
Bug ID: 102402
Summary: Seemingly suboptimal optimization of jmp/cmovcc for
conditionally loading constants
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Seve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102393
--- Comment #3 from Gabriel Ravier ---
It seems odd that the equivalent 32-bit pattern, i.e. this:
void HeaderWriteU32LE(int offset, uint32_t value, uint8_t *RomHeader)
{
RomHeader[offset] = value;
RomHeader[offset + 1] = value >> 8;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102393
Bug ID: 102393
Summary: Failure to optimize 2 8-bit stores into a single
16-bit store
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102391
Gabriel Ravier changed:
What|Removed |Added
Summary|Failure to optimize 2 8-bit |Failure to optimize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102392
Bug ID: 102392
Summary: Failure to optimize out sign extension when input is
non-negative
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102391
Bug ID: 102391
Summary: Failure to optimize 2 8-bit loads into a single 16-bit
load
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102224
--- Comment #7 from Gabriel Ravier ---
Also, `-ffast-math` seems to "fix" this, since in that case the code is
recognized as an ABS_EXPR pattern and as such results in the same code being
emitted without the xor. Is there any reason this isn't t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102224
Gabriel Ravier changed:
What|Removed |Added
Summary|[12 regession] wrong code |[9/10/11/12 regession]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102224
--- Comment #5 from Gabriel Ravier ---
Actually it seems to me like this is a GCC 9 regression, ever since this
pattern exists: GCC 9, 10 and 11 emit the exact same faulty code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102224
--- Comment #3 from Gabriel Ravier ---
Also seems like this might be unique to x86 as this compiles fine on Aarch64
(though while it doesn't try to do anything stupid like xoring the result with
itself, it does still not optimize the XOR_SIGN to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102224
--- Comment #2 from Gabriel Ravier ---
(PS: by "x and y" I mean "the two arguments". If they're the same, GCC should
obviously just optimize this to an abs as that's what it ends up being)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102224
--- Comment #1 from Gabriel Ravier ---
(Note: this is a miscompile because it compiles as equivalent to `return 0;` as
that's what `xorps xmm0, xmm0` will do)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102224
Bug ID: 102224
Summary: Incorrect compile on `x * copysign(1.0, x)`
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96563
--- Comment #3 from Gabriel Ravier ---
It seems like GCC does better for the unrolled case as of now on trunk and
seemingly since GCC 11, though the operation is done in a different way due to
`((unsigned)x <= 9) ? 8 : 4;` being expanded differen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98908
--- Comment #9 from Gabriel Ravier ---
PS: I had missed at the time that the bug wasn't present in GCC 10/9/8 though,
so perhaps it should be considered as having been a GCC 11 regression that got
fixed in trunk ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98908
--- Comment #8 from Gabriel Ravier ---
Well, fixing a bug filed in 2021 in GCC 9 seems quite hard. Are you confused
about the nature of the bug ? The first example in the description *is* the one
whose optimization the bug is about, and it is the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98908
--- Comment #6 from Gabriel Ravier ---
Also the second example wasn't misoptimized, on the contrary it was the most
reasonable portable function I could write that would work equivalently to the
first *and* that GCC would optimize ideally.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98908
--- Comment #5 from Gabriel Ravier ---
It may have been doing it in GCC 8 (and 9, and 10), but it didn't in 11, and
presumably this was also the case in trunk back in February.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98908
--- Comment #2 from Gabriel Ravier ---
This seems to have been fixed in trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96615
--- Comment #3 from Gabriel Ravier ---
It seems to be optimized into nothing as of right now
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95187
--- Comment #3 from Gabriel Ravier ---
Seems to be fixed since GCC 11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25186
Gabriel Ravier changed:
What|Removed |Added
CC||gabravier at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24333
Gabriel Ravier changed:
What|Removed |Added
CC||gabravier at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95427
--- Comment #1 from Gabriel Ravier ---
Seems to be fixed in trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95787
--- Comment #3 from Gabriel Ravier ---
nvm that's only if I use `-march=znver3`. Seems like it might be a tuning
issue, then ? Unless znver3 triggers patterns that specifically solve this...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95787
--- Comment #2 from Gabriel Ravier ---
Seems to be fixed on trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95845
--- Comment #2 from Gabriel Ravier ---
This appears to be fixed in trunk, GCC seems to use a movq now instead of a
movlps on x86.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100931
--- Comment #4 from Gabriel Ravier ---
Ah sorry for not clarifying. I get this bug for `-O3 -mtune=x` where x is one
of generic, core2, nehalem, westmere, sandybridge, ivybridge, haswell,
broadwell, znver1, znver2 and znver3. I have checked all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95405
--- Comment #4 from Gabriel Ravier ---
Ah, I see. Didn't think there was a constructor involved and/or that GIMPLE
would keep it implicit like this...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95405
Gabriel Ravier changed:
What|Removed |Added
CC||gabravier at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100931
Bug ID: 100931
Summary: [x86-64] Failure to optimize 2 32-bit stores converted
to a 64-bit store into using movabs instead of loading
from a constant
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152
Gabriel Ravier changed:
What|Removed |Added
CC||gabravier at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99887
Bug ID: 99887
Summary: Failure to optimize log2 pattern to clz
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optim
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99163
Bug ID: 99163
Summary: Odd error message when using `main` with
-pedantic-errors
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99088
Bug ID: 99088
Summary: Failure to error on recursive template instantiation
in a reasonable time
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99069
Bug ID: 99069
Summary: Failure to optimize bool selection pattern
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-op
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98984
Gabriel Ravier changed:
What|Removed |Added
Summary|Failure to optimize out |Failure to optimize out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98984
Bug ID: 98984
Summary: Failure to optinize out float conversion from long
long->float->char conversion
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98977
Bug ID: 98977
Summary: [x86] Failure to optimize consecutive sub flags usage
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98966
Bug ID: 98966
Summary: Failure to optimize conditional or with 1 based on
boolean condition to direct or
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98961
Bug ID: 98961
Summary: Failure to optimize successive comparisons with 0 into
clz
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98960
Bug ID: 98960
Summary: Failure to optimize accumulate loop to mul
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-op
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98957
Bug ID: 98957
Summary: [x86] Odd code generation for 8-bit left shift
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98956
Bug ID: 98956
Summary: Failure to optimize out boolean left shift
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-op
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98955
Bug ID: 98955
Summary: Failure to optimize shift+compare to single shift
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98954
Bug ID: 98954
Summary: Failure to optimize left shift+and pattern
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-op
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98953
Bug ID: 98953
Summary: Failure to optimize two reads from adjacent addresses
into one
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92168
Gabriel Ravier changed:
What|Removed |Added
CC||gabravier at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98934
Bug ID: 98934
Summary: Very poor code generation for SSE 8-bit vector right
shift
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98927
Bug ID: 98927
Summary: Code using _mm_extract_epi16 compiles with -O3 but not
on other optimization modes
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98909
--- Comment #1 from Gabriel Ravier ---
PS: The same pattern with `unsigned` replacing `int` can be optimized to
`return x & 1;` (done by LLVM, but not by GCC).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98909
Bug ID: 98909
Summary: Failure to optimize odd loop pattern
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimiza
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98908
Bug ID: 98908
Summary: Failure to optimize arithmetic involving struct
members into operating on the entire struct
Product: gcc
Version: 11.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98907
Bug ID: 98907
Summary: Failure to optimize abs pattern
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98703
Bug ID: 98703
Summary: Failure to optimize out non-zero check relative to
multiplication overflow check
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96599
--- Comment #4 from Gabriel Ravier ---
That makes sense, I had forgotten it was UB and Clang didn't seem to diagnose
this in any way, and I must have forgotten to check with GCC.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98648
--- Comment #4 from Gabriel Ravier ---
This code :
typedef int64_t v2di __attribute__((vector_size(16)));
v2di f(__m128 val)
{
return (~(v2di)_mm_set_ps1(0.0f) & (v2di)val);
}
is optimized better (and is equivalent, if I understand the se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98647
--- Comment #2 from Gabriel Ravier ---
I have just looked at the ABI and it just says that floats/doubles are passed
in SSE registers, but does not seem to explicitly specify whether the upper
bits are cleared or not (it explicitly specifies that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98648
Bug ID: 98648
Summary: Failure to optimize out no-op vector operation using
andnot
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98647
Bug ID: 98647
Summary: Failure to optimize out convertion from float to
vector type
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96674
--- Comment #4 from Gabriel Ravier ---
I'd assume those are for older test cases: __attribute__((noipa)) makes more
sense (at least to me) considering it's made specifically to prevent
inter-procedural optimization (which __attribute__((noinline)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96674
--- Comment #2 from Gabriel Ravier ---
Isn't __attribute__((noipa)) usually used instead of __attribute__((noinline))
?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98567
Bug ID: 98567
Summary: Failure to optimize using ZF flag from blsi
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96930
--- Comment #6 from Gabriel Ravier ---
For this exact code :
unsigned f(unsigned a, unsigned b)
{
return a / (unsigned long long)(1U << b);
}
compiled with a trunk-based GCC built yesterday for x86-64-linux-gnu configured
with: ../gcc-trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96930
--- Comment #4 from Gabriel Ravier ---
> The testcase seems to be optimized into return a >> b; and already e.g. GCC
> 4.4 does that.
> So it is unclear why this has been reported and what difference you found.
What I observed is that it is opt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98438
--- Comment #5 from Gabriel Ravier ---
If you're wondering, the `using x = y;` syntax is roughly equivalent to
`typedef y x;`, and the code just expects _Up to be the unsigned counterpart of
_Tp, but here are the details as demanded by https://gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98438
--- Comment #4 from Gabriel Ravier ---
Created attachment 49865
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49865&action=edit
Pre-processed source of a file reproducing the bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98438
--- Comment #2 from Gabriel Ravier ---
Directly based off the emitted GIMPLE, here's a self-contained example that
emits the same assembly I was observing before :
using _Tp = int;
using _Up = unsigned;
_Tp f(_Tp __a, _Tp __b)
{
_Up __sign_bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98443
Bug ID: 98443
Summary: Failure to optimize out vector operations into a
constant when possible
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56389
Gabriel Ravier changed:
What|Removed |Added
CC||gabravier at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98438
Bug ID: 98438
Summary: Rather bad optimization of midpoint implementation for
__int128 (and other types)
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98399
Bug ID: 98399
Summary: x86: Awful code generation for shifting vectors
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89581
Gabriel Ravier changed:
What|Removed |Added
CC||gabravier at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98337
Bug ID: 98337
Summary: Failure to optimize out on-stack array construction
when unneeded
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98334
Bug ID: 98334
Summary: Failure to optimally optimize add loop to mul
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98304
Bug ID: 98304
Summary: Failure to optimize bitwise arithmetic pattern
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98303
Bug ID: 98303
Summary: [x86] Bad register allocation when reproducing
assembly code
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98299
--- Comment #3 from Gabriel Ravier ---
PS: The optimization seems to already occur for simpler cases such as powers of
2, e.g. :
int f1(int n)
{
while (n >= 64)
n -= 64;
return n;
}
is optimized into `return (n <= 63) ? n : (n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98299
--- Comment #2 from Gabriel Ravier ---
At the very least, it seems like a worthwhile pattern to recognize in -O3, even
if only to avoid vectorizing it, i.e. have similar effects to what happens if
you add `if (n >= 1000) __builtin_unreachable();`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98299
Bug ID: 98299
Summary: Failure to optimize sub loop into modulo-based pattern
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98289
Bug ID: 98289
Summary: [x86] Suboptimal optimization of stack usage when
function call to cold function is not needed
Product: gcc
Version: 11.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98254
Bug ID: 98254
Summary: Failure to optimize simple pattern for
__builtin_convertvector
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98167
Gabriel Ravier changed:
What|Removed |Added
Summary|[x86] Failure to optimize |[x86] Failure to optimize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98167
Bug ID: 98167
Summary: [x86] Failure to optimize operation on indentically
shuffled operand into a shuffle of the result of the
operation
Product: gcc
Version: 11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98109
Bug ID: 98109
Summary: Seemingly wrong warnings from -Wnonnull when combined
with -O2 -fsanitize=undefined
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98060
Bug ID: 98060
Summary: Failure to optimize cmp+setnb+add to cmp+sbb
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: targe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95922
--- Comment #3 from Gabriel Ravier ---
Hm, I guess with the andn it avoids a move, though that isn't much. I posted
this here months ago actually, so idk really what I was thinking... I guess it
might help in some further transformations, but it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97887
Bug ID: 97887
Summary: Failure to optimize neg plus div to avoid using x87
floating point stack
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31799
Gabriel Ravier changed:
What|Removed |Added
CC||gabravier at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97873
Bug ID: 97873
Summary: Failure to optimize abs optimally (at least one
useless instruction on x86)
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: norm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70547
Gabriel Ravier changed:
What|Removed |Added
CC||gabravier at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97743
Bug ID: 97743
Summary: Failure to optimize boolean multiplication to select
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
101 - 200 of 204 matches
Mail list logo
