[Bug ipa/114408] New: Crash when invoking strcmp multiple times with -fsanitize=undefined -O1 -fanalyzer -flto

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114408 Bug ID: 114408 Summary: Crash when invoking strcmp multiple times with -fsanitize=undefined -O1 -fanalyzer -flto Product: gcc Version: 14.0 Status: UNCONFIRMED

[Bug rtl-optimization/114176] New: Failure to optimize out useless stack spill when array is present in union

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114176 Bug ID: 114176 Summary: Failure to optimize out useless stack spill when array is present in union Product: gcc Version: 14.0 Status: UNCONFIRMED Severity:

[Bug c++/113812] Comma expression parsed as declaration when ambiguous type name cast is present

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113812 --- Comment #2 from Gabriel Ravier --- Also I guess this is a simpler minimal example: void f(int x) { int(x), 0; }

[Bug c++/113812] New: Comma expression parsed as declaration when ambiguous type name cast is present

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113812 Bug ID: 113812 Summary: Comma expression parsed as declaration when ambiguous type name cast is present Product: gcc Version: 14.0 Status: UNCONFIRMED

[Bug c/113650] New: __builtin_nonlocal_goto ICEs when passed 0 as arguments

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113650 Bug ID: 113650 Summary: __builtin_nonlocal_goto ICEs when passed 0 as arguments Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal

[Bug middle-end/107845] __builtin_init_trampoline ICEs on invalid arguments

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107845 --- Comment #2 from Gabriel Ravier --- I'll add that the new `__builtin_init_heap_trampoline` builtin also ICEs when given the same arguments, presumably for the same reasons (thus, an extra bug report doesn't seem very useful)

[Bug c/113647] New: __builtin_eh_return_data_regno ICEs when passed -1 as argument

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113647 Bug ID: 113647 Summary: __builtin_eh_return_data_regno ICEs when passed -1 as argument Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal

[Bug c/29970] mixing ({...}) with VLA leads to massive breakage

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29970 Gabriel Ravier changed: What|Removed |Added CC||gabravier at gmail dot com --- Comment

[Bug middle-end/111378] Missed optimization for comparing with exact_log2 constants

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111378 --- Comment #5 from Gabriel Ravier --- It does seem as though this transformation is not particularly favorable on most platforms. In fact, it seems as though the opposite transformation (which Clang does on many targets, along with MSVC) would

[Bug c/113262] New: ICE when using [[gnu::copy("")]] attribute

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113262 Bug ID: 113262 Summary: ICE when using [[gnu::copy("")]] attribute Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c

[Bug middle-end/109986] missing fold (~a | b) ^ a => ~(a & b)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109986 Gabriel Ravier changed: What|Removed |Added CC||gabravier at gmail dot com ---

[Bug tree-optimization/94911] Failure to optimize comparisons of VLA sizes

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94911 --- Comment #5 from Gabriel Ravier --- Also, as an extra note, w.r.t. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94911#c3, I've just noticed that I had indeed made a separate bug report at https://gcc.gnu.org/PR94912 (which ended up being

[Bug target/104375] [x86] Failure to recognize bzhi pattern when shr is present

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104375 --- Comment #4 from Gabriel Ravier --- So should the bug be marked as fixed or... ?

[Bug tree-optimization/98966] Failure to optimize conditional or with 1 based on boolean condition to direct or

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98966 --- Comment #3 from Gabriel Ravier --- Appears to be fixed on trunk.

[Bug tree-optimization/96930] Failure to optimize out arithmetic with bigger size when it can't matter with division transformed into right shift

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96930 --- Comment #11 from Gabriel Ravier --- It appears like this is fixed on trunk, I think ?

[Bug rtl-optimization/96692] Failure to optimize xor+or+xor to andnot+xor

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96692 --- Comment #3 from Gabriel Ravier --- This seems to be fixed on trunk now, I think ?

[Bug target/95427] Failure to avoid emitting rbp initialization when doing 256-bit memory store

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95427 --- Comment #2 from Gabriel Ravier --- Still appears to be fixed on trunk.

[Bug tree-optimization/94908] Failure to optimally optimize certain shuffle patterns

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94908 --- Comment #3 from Gabriel Ravier --- Looks like this gives much better output now.

[Bug tree-optimization/94899] Failure to optimize out add before compare with INT_MIN

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94899 --- Comment #7 from Gabriel Ravier --- I don't know if I've missed something obvious but this still appears to be fixed.

[Bug tree-optimization/94782] Simple multiplication-related arithmetic not optimized to direct multiplication

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94782 --- Comment #2 from Gabriel Ravier --- Appears to be fixed on trunk.

[Bug tree-optimization/90838] Detect table-based ctz implementation

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90838 --- Comment #19 from Gabriel Ravier --- (In reply to Jakub Jelinek from comment #14) > The patch does: > +  bool zero_ok = CTZ_DEFINED_VALUE_AT_ZERO (TYPE_MODE (type), ctzval) > == 2; > + > +  /* Skip if there is no value defined at 

[Bug tree-optimization/90838] Detect table-based ctz implementation

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90838 Gabriel Ravier changed: What|Removed |Added CC||gabravier at gmail dot com --- Comment

[Bug tree-optimization/92342] [10/11/12/13 Regression] a small missed transformation into x?b:0

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92342 --- Comment #29 from Gabriel Ravier --- Looks like the patch fixes this bug, unless I'm missing something.

[Bug middle-end/107115] Wrong codegen from TBAA under stores that change effective type?

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107115 --- Comment #14 from Gabriel Ravier --- Actually I think there's some aliasing violations in the C++ code w.r.t. the re-usage of `p4` after another object has been created in its place so I think this code would be more correct: void

[Bug middle-end/107115] Wrong codegen from TBAA under stores that change effective type?

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107115 Gabriel Ravier changed: What|Removed |Added CC||gabravier at gmail dot com ---

[Bug c/107845] New: __builtin_init_trampoline ICEs on invalid arguments

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107845 Bug ID: 107845 Summary: __builtin_init_trampoline ICEs on invalid arguments Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3

[Bug c/107840] New: ICE when compiling cursed setjmp/longjmp that uses __builtin_call_with_static_chain

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107840 Bug ID: 107840 Summary: ICE when compiling cursed setjmp/longjmp that uses __builtin_call_with_static_chain Product: gcc Version: 13.0 Status: UNCONFIRMED

[Bug c/106535] GCC doesn't reject non-constant initializer if -pedantic is specified but does so in any other circumstances

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106535 --- Comment #3 from Gabriel Ravier --- Considering the comment appears to be from 1993 (see commit d9fc6069c69564ce7fecd9ca0ce1bbe0b3c130ef), it having become wrong since then doesn't seem particularly surprising :p

[Bug c/106535] GCC doesn't reject non-constant initializer if -pedantic is specified but does so in any other circumstances

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106535 Gabriel Ravier changed: What|Removed |Added Keywords||accepts-invalid, |

[Bug c/106535] New: GCC doesn't reject non-constant initializer if -pedantic is specified but does so in any other circumstances

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106535 Bug ID: 106535 Summary: GCC doesn't reject non-constant initializer if -pedantic is specified but does so in any other circumstances Product: gcc Version: 13.0

[Bug tree-optimization/94920] Failure to optimize abs pattern from arithmetic with selected operands based on comparisons with 0

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94920 --- Comment #4 from Gabriel Ravier --- So, is this fully fixed, or did I miss something ?

[Bug tree-optimization/106245] New: Failure to optimize (u8)(a << 7) >> 7 pattern to a & 1

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106245 Bug ID: 106245 Summary: Failure to optimize (u8)(a << 7) >> 7 pattern to a & 1 Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3

[Bug tree-optimization/106244] New: Failure to optimize (1 << x) & 1 to `x == 0` if separated into multiple statements

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106244 Bug ID: 106244 Summary: Failure to optimize (1 << x) & 1 to `x == 0` if separated into multiple statements Product: gcc Version: 13.0 Status: UNCONFIRMED

[Bug tree-optimization/106243] New: Failure to optimize (0 - x) & 1 on vector type

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106243 Bug ID: 106243 Summary: Failure to optimize (0 - x) & 1 on vector type Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component:

[Bug tree-optimization/94899] Failure to optimize out add before compare with INT_MIN

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94899 --- Comment #6 from Gabriel Ravier --- Can confirm that this appears to be fixed.

[Bug tree-optimization/105983] New: Failure to optimize (b != 0) && (a >= b) as well as the same pattern with binary and

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105983 Bug ID: 105983 Summary: Failure to optimize (b != 0) && (a >= b) as well as the same pattern with binary and Product: gcc Version: 13.0 Status: UNCONFIRMED

[Bug tree-optimization/105777] New: Failure to optimize __builtin_mul_overflow with constant operand to add+cmp check

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105777 Bug ID: 105777 Summary: Failure to optimize __builtin_mul_overflow with constant operand to add+cmp check Product: gcc Version: 13.0 Status: UNCONFIRMED

[Bug tree-optimization/105776] New: Failure to recognize __builtin_mul_overflow pattern

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105776 Bug ID: 105776 Summary: Failure to recognize __builtin_mul_overflow pattern Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3

[Bug target/105773] New: [Aarch64] Failure to optimize and+cmp to tst

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105773 Bug ID: 105773 Summary: [Aarch64] Failure to optimize and+cmp to tst Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component:

[Bug tree-optimization/102583] [x86] Failure to optimize 32-byte integer vector conversion to 16-byte float vector properly when converting upper part with -mavx2

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102583 --- Comment #7 from Gabriel Ravier --- Can confirm it is indeed fixed

[Bug target/105328] New: [x86] Failure to optimize out test instruction after add

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105328 Bug ID: 105328 Summary: [x86] Failure to optimize out test instruction after add Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal

[Bug target/104412] New: [Aarch64] Failure to optimize vector initialization from int64s

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104412 Bug ID: 104412 Summary: [Aarch64] Failure to optimize vector initialization from int64s Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal

[Bug target/104409] New: [Aarch64] Crash when compiling source code of any significant size with -march=armv8.7-a

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104409 Bug ID: 104409 Summary: [Aarch64] Crash when compiling source code of any significant size with -march=armv8.7-a Product: gcc Version: 12.0 Status: UNCONFIRMED

[Bug target/104401] New: [x86] Failure to recognize min/max pattern using pcmp+pblendv

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104401 Bug ID: 104401 Summary: [x86] Failure to recognize min/max pattern using pcmp+pblendv Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal

[Bug tree-optimization/104394] New: Failure to optimize vector pattern for x < 0

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104394 Bug ID: 104394 Summary: Failure to optimize vector pattern for x < 0 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component:

[Bug target/104371] [x86] Failure to use optimize pxor+pcmpeqb+pmovmskb+cmp 0xFFFF pattern to ptest

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104371 --- Comment #2 from Gabriel Ravier --- Although I agree the pattern doesn't seem that useful at first, I've seen it crop up in several places, such as: - in pixman: https://github.com/servo/pixman/blob/master/pixman/pixman-sse2.c on line 181 -

[Bug tree-optimization/104376] New: Failure to optimize clz equivalent to clz

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104376 Bug ID: 104376 Summary: Failure to optimize clz equivalent to clz Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component:

[Bug target/104375] New: [x86] Failure to recognize bzhi patter nwhen shr is present

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104375 Bug ID: 104375 Summary: [x86] Failure to recognize bzhi patter nwhen shr is present Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal

[Bug target/104371] New: [x86] Failure to use optimize pxor+pcmpeqb+pmovmskb+cmp 0xFFFF pattern to ptest

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104371 Bug ID: 104371 Summary: [x86] Failure to use optimize pxor+pcmpeqb+pmovmskb+cmp 0x pattern to ptest Product: gcc Version: 12.0 Status: UNCONFIRMED

[Bug tree-optimization/104360] New: Failure to optimize abs pattern on vector types

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104360 Bug ID: 104360 Summary: Failure to optimize abs pattern on vector types Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component:

[Bug target/104357] New: [Aarch64] Failure to use csinv instead of mvn+csel where possible

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104357 Bug ID: 104357 Summary: [Aarch64] Failure to use csinv instead of mvn+csel where possible Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal

[Bug target/104315] [AArch64] Failure to optimize 8-bit bitreverse pattern

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104315 --- Comment #1 from Gabriel Ravier --- PS: I've just stumbled upon the more generic case, which would be this code: unsigned int stb_bitreverse(unsigned int n) { n = ((n & 0x) >> 1) | ((n & 0x) << 1); n = ((n & 0x)

[Bug target/104315] New: [AArch64] Failure to optimize 8-bit bitreverse pattern

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104315 Bug ID: 104315 Summary: [AArch64] Failure to optimize 8-bit bitreverse pattern Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3

[Bug middle-end/96159] atomic creates incorrect code for possible isaligned struct

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96159 Gabriel Ravier changed: What|Removed |Added CC||gabravier at gmail dot com --- Comment

[Bug c/103343] Invalid codegen when comparing pointer to one past the end and then dereferencing that pointer

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103343 --- Comment #3 from Gabriel Ravier --- Well the code does not invoke undefined behavior here, it just so happens that `p == (x + 1)` because `y` happens to be laid out in memory after `x` (note: this isn't a guarantee, of course, but GCC can't

[Bug c/103343] New: Invalid codegen when comparing pointer to one past the end and then dereferencing that pointer

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103343 Bug ID: 103343 Summary: Invalid codegen when comparing pointer to one past the end and then dereferencing that pointer Product: gcc Version: 12.0 Status: UNCONFIRMED

[Bug c/102939] Ridiculously long compilation times on (admittedly itself ridiculous) pointer declaration

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102939 --- Comment #4 from Gabriel Ravier --- (In reply to Hans-Peter Nilsson from comment #3) > (In reply to Gabriel Ravier from comment #0) > ... > > #define PTR4 PTR3 PTR3 PTR3 PTR3 PTR3 PTR3 PTR3 PTR3 PTR3 PTR3 > > #define PTR5 PTR4 PTR4 PTR4 PTR4

[Bug c/102939] New: Ridiculously long compilation times on (admittedly ridiculous) pointer declaration

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102939 Bug ID: 102939 Summary: Ridiculously long compilation times on (admittedly ridiculous) pointer declaration Product: gcc Version: 11.2.1 Status: UNCONFIRMED

[Bug tree-optimization/102927] Failure to optimize series of if-else to use array when possible

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102927 --- Comment #5 from Gabriel Ravier --- Um, what ? How is this invalid, exactly ? Are you saying foo is faster than baz (in which case it seems the opposite optimization should be implemented for baz and bar), or that this optimization just

[Bug tree-optimization/102927] New: Failure to optimize series of if-else to use array when possible

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102927 Bug ID: 102927 Summary: Failure to optimize series of if-else to use array when possible Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal

[Bug c++/31573] -Wall-all to enable all warnings

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31573 --- Comment #11 from Gabriel Ravier --- Well, that does help, although it is still a significant annoyance that would take more than its fair share of time to handle. (Also, is it still really that much of a concern anymore that users would

[Bug c++/31573] -Wall-all to enable all warnings

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31573 Gabriel Ravier changed: What|Removed |Added CC||gabravier at gmail dot com --- Comment

[Bug c++/102820] New: Failure to compile void{}

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102820 Bug ID: 102820 Summary: Failure to compile void{} Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++

[Bug rtl-optimization/15792] missed subreg optimization

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15792 Gabriel Ravier changed: What|Removed |Added CC||gabravier at gmail dot com --- Comment

[Bug target/102758] New: [x86] Failure to use registers optimally when swapping between (identically represented) vector types

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102758 Bug ID: 102758 Summary: [x86] Failure to use registers optimally when swapping between (identically represented) vector types Product: gcc Version: 12.0 Status:

[Bug target/95740] Failure to avoid using the stack when interpreting a float as an integer when it is modified afterwards

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95740 --- Comment #3 from Gabriel Ravier --- I've also encountered what looks like a duplicate of this bug, although I'm not sure but it seems likely: int foo(float f) { union { float f; int i; } z = { .f = f }; return z.i - 1; }

[Bug tree-optimization/102738] New: Failure to optimize right shift of 128-bit value after it's already been shifted by 127

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102738 Bug ID: 102738 Summary: Failure to optimize right shift of 128-bit value after it's already been shifted by 127 Product: gcc Version: 12.0 Status: UNCONFIRMED

[Bug target/102737] New: [x86] Failure to optimize out bad register usage involving int->double conversion

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102737 Bug ID: 102737 Summary: [x86] Failure to optimize out bad register usage involving int->double conversion Product: gcc Version: 12.0 Status: UNCONFIRMED

[Bug tree-optimization/102679] New: Failure to optimize out 64-bit multiplication to 32-bit multiplication when possible in circumstances involving modifying a 64-bit variable that gets converted to 3

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102679 Bug ID: 102679 Summary: Failure to optimize out 64-bit multiplication to 32-bit multiplication when possible in circumstances involving modifying a 64-bit variable that gets

[Bug tree-optimization/102676] Failure to optimize out malloc/nothrow allocation that's only used for bool checking

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102676 --- Comment #2 from Gabriel Ravier --- Well, I think the assumption LLVM is making is that the allocation, being unused, can just be eliminated and considered to have always succeeded. I don't see how that would contradict the standard,

[Bug tree-optimization/102676] New: Failure to optimize out malloc/nothrow allocation that's only used for bool checking

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102676 Bug ID: 102676 Summary: Failure to optimize out malloc/nothrow allocation that's only used for bool checking Product: gcc Version: 12.0 Status: UNCONFIRMED

[Bug target/102672] New: [AArch64] Failure to optimize to using stp instead of 2 strs when possible

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102672 Bug ID: 102672 Summary: [AArch64] Failure to optimize to using stp instead of 2 strs when possible Product: gcc Version: 12.0 Status: UNCONFIRMED Severity:

[Bug c++/102623] New: Failure to detect destructed scalar objects in consteval function

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102623 Bug ID: 102623 Summary: Failure to detect destructed scalar objects in consteval function Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal

[Bug target/102591] Failure to optimize search for value in vector-sized area to use SIMD

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102591 --- Comment #2 from Gabriel Ravier --- memcpy can fail on unaligned memory ??? I used it specifically to avoid this problem ! (also, LLVM's code, I am pretty sure, does not have any issue with alignment, as it uses either AVX instructions

[Bug target/102591] New: Failure to optimize search for value in vector-sized area to use SIMD

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102591 Bug ID: 102591 Summary: Failure to optimize search for value in vector-sized area to use SIMD Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal

[Bug target/85730] complex code for modifying lowest byte in a 4-byte vector

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85730 --- Comment #4 from Gabriel Ravier --- That's a bit odd, really - I'm just using the latest released sub-versions of each of these (except for GCC 6 since I only have access to it through Godbolt which doesn't have GCC 6.5), i.e. GCC 6.4, 7.5,

[Bug target/85730] complex code for modifying lowest byte in a 4-byte vector

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85730 Gabriel Ravier changed: What|Removed |Added CC||gabravier at gmail dot com --- Comment

[Bug target/102583] New: [x86] Failure to optimize 32-byte integer vector conversion to 16-byte float vector properly when converting upper part with -mavx2

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102583 Bug ID: 102583 Summary: [x86] Failure to optimize 32-byte integer vector conversion to 16-byte float vector properly when converting upper part with -mavx2 Product: gcc

[Bug tree-optimization/102580] New: Failure to optimize signed division to unsigned division when dividend can't be negative

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102580 Bug ID: 102580 Summary: Failure to optimize signed division to unsigned division when dividend can't be negative Product: gcc Version: 12.0 Status: UNCONFIRMED

[Bug tree-optimization/102579] New: Failure to optimize out allocation if volatile read is present in the middle

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102579 Bug ID: 102579 Summary: Failure to optimize out allocation if volatile read is present in the middle Product: gcc Version: 12.0 Status: UNCONFIRMED Severity:

[Bug target/102575] New: Failure to optimize double _Complex stores to use largest loads/stores possible

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

[Bug tree-optimization/102494] New: Failure to optimize out vector reduction properly especially when using OpenMP

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

[Bug target/101543] extra zeroing of empty struct argument/return value

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101543 --- Comment #4 from Gabriel Ravier --- Nevermind, didn't see this was an aarch64 bug

[Bug target/101543] extra zeroing of empty struct argument/return value

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101543 Gabriel Ravier changed: What|Removed |Added CC||gabravier at gmail dot com ---

[Bug rtl-optimization/7061] Access of bytes in struct parameters

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=7061 Gabriel Ravier changed: What|Removed |Added CC||gabravier at gmail dot com --- Comment

[Bug target/102438] New: [x86-64] Failure to optimize out random extra store+load in vector code when memcpy is used

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

[Bug c/54192] -fno-trapping-math by default?

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54192 Gabriel Ravier changed: What|Removed |Added CC||gabravier at gmail dot com --- Comment

[Bug target/48297] Suboptimal optimization of boolean expression addition

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48297 Gabriel Ravier changed: What|Removed |Added CC||gabravier at gmail dot com --- Comment

[Bug target/102402] New: Seemingly suboptimal optimization of jmp/cmovcc for conditionally loading constants

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

[Bug tree-optimization/102393] Failure to optimize 2 8-bit stores into a single 16-bit store

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;

[Bug tree-optimization/102393] New: Failure to optimize 2 8-bit stores into a single 16-bit store

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

[Bug tree-optimization/102391] Failure to optimize adjacent 8-bit loads into a single bigger load

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

[Bug tree-optimization/102392] New: Failure to optimize out sign extension when input is non-negative

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

[Bug tree-optimization/102391] New: Failure to optimize 2 8-bit loads into a single 16-bit load

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

[Bug target/102224] [9/10/11/12 regession] wrong code for `x * copysign(1.0, x)`

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

[Bug target/102224] [9/10/11/12 regession] wrong code for `x * copysign(1.0, x)`

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]

[Bug target/102224] [12 regession] wrong code for `x * copysign(1.0, x)`

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.

[Bug tree-optimization/102224] Incorrect compile on `x * copysign(1.0, x)`

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

[Bug tree-optimization/102224] Incorrect compile on `x * copysign(1.0, x)`

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)

[Bug tree-optimization/102224] Incorrect compile on `x * copysign(1.0, x)`

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)

  1   2   >