[Bug sanitizer/84508] Load of misaligned address using _mm_load_sd

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84508 --- Comment #23 from Jeffrey Walton --- (In reply to Peter Cordes from comment #22) > [...] > That instruction is useless and should never be used in asm except for > code-alignment reasons (1 byte longer than MOVLPS, same length as MOVSD, all >

[Bug driver/81358] libatomic not automatically linked with C11 code

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81358 --- Comment #13 from Jeffrey Walton --- Add a mee too. When using sanitizers, like -fsanitize=undefined, the compiler driver is not adding the necessary libraries to link the program. Ugh...

[Bug rtl-optimization/106568] -freorder-blocks-algorithm appears to causes a crash in stable code, no way to disable it

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106568 --- Comment #20 from Jeffrey Walton --- Hi Andrew. I went through the list of options that are enabled at -O2 from [1]. I built the library with each option separately at "-DNDEBUG -g2 -O2 -fno-xxx". Here is the list of suspects. I seem to

[Bug rtl-optimization/106568] -freorder-blocks-algorithm appears to causes a crash in stable code, no way to disable it

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106568 --- Comment #19 from Jeffrey Walton --- Created attachment 53427 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53427=edit Test script to build library at -O2 with -fno-xxx Test script to build library at -O2 with -fno-xxx

[Bug rtl-optimization/106568] -freorder-blocks-algorithm appears to causes a crash in stable code, no way to disable it

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106568 --- Comment #18 from Jeffrey Walton --- (In reply to Andrew Pinski from comment #17) > The other thing to try is -fstack-reuse=none. No joy with -fstack-reuse=none. The crash is still present.

[Bug rtl-optimization/106568] -freorder-blocks-algorithm appears to causes a crash in stable code, no way to disable it

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106568 --- Comment #15 from Jeffrey Walton --- It looks like -fno-strict-aliasing cleared the crash. This is bad because I thought we did not violate aliasing rules. Let me try to find it.

[Bug rtl-optimization/106568] -freorder-blocks-algorithm appears to causes a crash in stable code, no way to disable it

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106568 --- Comment #14 from Jeffrey Walton --- (In reply to Jeffrey Walton from comment #13) > (In reply to Andrew Pinski from comment #12) > > Can you try -fno-reorder-blocks-and-partition adding to the options? > > This would not be the first time

[Bug rtl-optimization/106568] -freorder-blocks-algorithm appears to causes a crash in stable code, no way to disable it

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106568 --- Comment #13 from Jeffrey Walton --- (In reply to Andrew Pinski from comment #12) > Can you try -fno-reorder-blocks-and-partition adding to the options? > This would not be the first time this option caused issues with EH. No joy with

[Bug rtl-optimization/106568] -freorder-blocks-algorithm appears to causes a crash in stable code, no way to disable it

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106568 --- Comment #10 from Jeffrey Walton --- I'm not sure if this is helpful, but Valgrind is showing invalid reads in the unwind gear: $ valgrind ./cryptest.exe vv 51 ==27339== Memcheck, a memory error detector ==27339== Copyright (C) 2002-2022,

[Bug rtl-optimization/106568] -freorder-blocks-algorithm appears to causes a crash in stable code, no way to disable it

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106568 --- Comment #9 from Jeffrey Walton --- (In reply to Andrew Pinski from comment #8) > (In reply to Jeffrey Walton from comment #7) > > Try putting a breakpoint on the following functions: > _Unwind_RaiseException > _Unwind_ForcedUnwind >

[Bug rtl-optimization/106568] -freorder-blocks-algorithm appears to causes a crash in stable code, no way to disable it

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106568 --- Comment #7 from Jeffrey Walton --- (In reply to Andrew Pinski from comment #6) > >And the program does not take the exception path. Instead it segfaults. > > If I read the backtrace correctly, it is trying to resume an unwind because > it

[Bug rtl-optimization/106568] -freorder-blocks-algorithm appears to causes a crash in stable code, no way to disable it

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106568 --- Comment #5 from Jeffrey Walton --- (In reply to Andrew Pinski from comment #3) > Though there might be an EH issue but there has not been an EH issue for a > long time . This is an interesting observation. The stack trace shows frame #0

[Bug c++/106568] New: -freorder-blocks-algorithm appears to causes a crash in stable code, no way to disable it

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106568 Bug ID: 106568 Summary: -freorder-blocks-algorithm appears to causes a crash in stable code, no way to disable it Product: gcc Version: 12.1.1 Status: UNCONFIRMED

[Bug target/104455] Cannot select -march=armv7-a using GCC 11

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104455 Jeffrey Walton changed: What|Removed |Added Resolution|INVALID |FIXED --- Comment #4 from Jeffrey

[Bug target/104455] Cannot select -march=armv7-a using GCC 11

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104455 --- Comment #2 from Jeffrey Walton --- (In reply to Richard Earnshaw from comment #1) > What's the configuration of the compiler? Eg, the output of gcc -v Thanks Richard. I set-up a Debian Qemu/Chroot for armhf. I can now duplicate the

[Bug c++/104455] New: Cannot select -march=armv7-a using GCC 11

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104455 Bug ID: 104455 Summary: Cannot select -march=armv7-a using GCC 11 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++

[Bug driver/103863] We need a warning for loss of no-exec stacks

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103863 --- Comment #2 from Jeffrey Walton --- (In reply to Andrew Pinski from comment #1) > I think the warning needs to be implemented in the linker rather than in GCC > because the linker is what decides if there are executable stacks are needed >

[Bug c/103863] New: We need a warning for loss of no-exec stacks

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103863 Bug ID: 103863 Summary: We need a warning for loss of no-exec stacks Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component:

[Bug target/96168] GCC support for Apple Silicon (Arm64) on macOS requested

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96168 Jeffrey Walton changed: What|Removed |Added CC||noloader at gmail dot com --- Comment

[Bug target/82735] _mm256_zeroupper does not invalidate previously computed registers

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82735 --- Comment #6 from Jeffrey Walton --- Add 9.3 to the know to fail list: $ gcc --version gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0 Copyright (C) 2019 Free Software Foundation, Inc.

[Bug target/82735] _mm256_zeroupper does not invalidate previously computed registers

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82735 --- Comment #5 from Jeffrey Walton --- I think we are seeing this bug in the field. We are catching lots of failed self tests as we test on multiple platforms, including Ubuntu 14 ERS and Ubuntu 16 LTS. The problem makes GCC 4.8.4 through 7.5

[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431 --- Comment #40 from Jeffrey Walton --- Still a problem in 2021.

[Bug c++/98416] POWER8: SIGILL handler does not restart properly after signal using GCC 10.2.1

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98416 --- Comment #3 from Jeffrey Walton --- (In reply to Andrew Pinski from comment #2) > This is invalid. > The instruction which is failing is: > 9c: f0 00 02 d0 xxspltib vs0,0 > > Which is only valid in power9 and above. > You need to mark

[Bug c++/98416] POWER8: SIGILL handler does not restart properly after signal using GCC 10.2.1

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98416 --- Comment #1 from Jeffrey Walton --- Created attachment 49831 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49831=edit Disassembly of ppc_power9.o Created with 'objdump --disassemble ppc_power9.o | c++filt > ppc_power9.disass'.

[Bug c++/98416] New: POWER8: SIGILL handler does not restart properly after signal using GCC 10.2.1

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98416 Bug ID: 98416 Summary: POWER8: SIGILL handler does not restart properly after signal using GCC 10.2.1 Product: gcc Version: 10.2.1 Status: UNCONFIRMED

[Bug middle-end/93644] [10/11 Regression] spurious -Wreturn-local-addr with PHI of PHI

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93644 --- Comment #13 from Jeffrey Walton --- On Wed, Dec 16, 2020 at 9:05 PM eggert at cs dot ucla.edu wrote: > ... > (B) there's no way to shut off the false alarm, not even with '# pragma GCC > diagnostic ignored "-Wreturn-local-addr"'.