[Bug target/55522] -funsafe-math-optimizations is unexpectedly harmful, especially w/ -shared

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522 --- Comment #16 from Andy Lutomirski --- (In reply to Andrew Pinski from comment #13) > Patient: Doctor it hurts when I do this. > Doctor: then don't do that and if you read the instructions I gave you I > told you I would hurt this way. I

[Bug target/98997] Linking mismatched -fcf-protection objects generates incorrect code

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98997 --- Comment #4 from Andy Lutomirski --- I should add: on brief inspection, that patch looks like an ABI break for -fcf-protection=none

[Bug target/98997] Linking mismatched -fcf-protection objects generates incorrect code

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98997 --- Comment #3 from Andy Lutomirski --- What is -fcf-protection=stack actually supposed to do as compared to -fcf-protection=none? Is it valid to run code compiled with -fcf-protection=none with SHSTK enabled? If so, then I wonder why

[Bug target/98997] New: Linking mismatched -fcf-protection objects generates incorrect code

Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: luto at kernel dot org Target Milestone: --- $ gcc --version gcc (GCC) 10.2.1 20201125 (Red Hat 10.2.1-9) Copyright (C) 2020 Free Software Foundation, Inc. This is free software

[Bug rtl-optimization/48877] Inline asm for rdtsc generates silly code

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48877 Andy Lutomirski changed: What|Removed |Added Resolution|--- |FIXED Status|NEW

[Bug c++/53234] [c++0x] unfriendly error message for missing move constructor

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53234 --- Comment #2 from Andy Lutomirski --- *** Bug 57998 has been marked as a duplicate of this bug. ***

[Bug c++/57998] Unhelpful error message when a class has no move constructor

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57998 Andy Lutomirski changed: What|Removed |Added Resolution|--- |DUPLICATE

[Bug libstdc++/91357] New: _GLIBCXX_ASSERTIONS rejects possibly-valid code

: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: luto at kernel dot org Target Milestone: --- Created attachment 46672 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46672=edit Example For a non-empty vector v, calling v.operator[](v.size()) fi

[Bug target/84908] retpoline weirdness: 7.3.0-1 and 4.8.5-16: with -fPIC: R_X86_64_PC32 against undefined symbol `__x86_indirect_thunk_rax'

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84908 --- Comment #13 from Andy Lutomirski --- I find this whole discussion very confusing. The problem has nothing to do with relocations AFAICT. The problem is that gcc is (as requested) generating retpolines, and it's set up to do it by calling

[Bug target/84908] retpoline weirdness: 7.3.0-1 and 4.8.5-16: with -fPIC: R_X86_64_PC32 against undefined symbol `__x86_indirect_thunk_rax'

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84908 Andy Lutomirski changed: What|Removed |Added CC||luto at kernel dot org --- Comment #9

[Bug target/81825] New: x86_64 stack realignment code is suboptimal

: target Assignee: unassigned at gcc dot gnu.org Reporter: luto at kernel dot org Target Milestone: --- I compiled this: void func() { int var __attribute__((aligned(32))); asm volatile ("" :: "m" (var)); } using gcc (GCC) 7.1.1 20170622 (Red

[Bug target/81708] The x86 stack canary location should be customizable

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81708 --- Comment #7 from Andy Lutomirski --- Hmm. This is a big improvement, but it's still going to be awkward to use -- if we want to use a normal Linux percpu variable, we're stuck putting it in a fixed location that's known at compile time as

[Bug target/81490] x86: Handling of symbol ranges for __seg_fs/__seg_gs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81490 --- Comment #28 from Andy Lutomirski --- hjl, I don't understand what problem you're trying to solve here. Your patch makes it relatively straightforward to access global variables using __seg_gs if the environment sets up the %gs base exactly

[Bug target/81708] The x86 stack canary location should be customizable

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81708 --- Comment #2 from Andy Lutomirski --- (In reply to H. Peter Anvin from comment #1) > Well, you can choose between "__stack_chk_guard(%rip)" and "%gs:40"... :) Wow, I guess I didn't even consider the former. That would be option 5:

[Bug target/81490] x86: Handling of symbol ranges for __seg_fs/__seg_gs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81490 --- Comment #21 from Andy Lutomirski --- Re: the stack canary, I filed bug 81708. It seems to me that __seg_gs is analogous and users should be able to directly specify the addressing mode.

[Bug target/81708] New: The x86 stack canary location should be customizable

Component: target Assignee: unassigned at gcc dot gnu.org Reporter: luto at kernel dot org Target Milestone: --- There are four credible ways to find the stack canary: 1. %fs:symbol 2. %fs:symbol(%rip) [with a PCREL relocation] 3. %gs:symbol 4. %gs:symbol(%rip) (Obviously

[Bug target/81490] x86: Handling of symbol ranges for __seg_fs/__seg_gs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81490 --- Comment #20 from Andy Lutomirski --- We have issues putting modules more than 2G from the main kernel no matter what, but I don't see what this has to do with %gs addressing. I still think that GCC should let us directly control the

[Bug target/81490] x86: Handling of symbol ranges for __seg_fs/__seg_gs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81490 --- Comment #14 from Andy Lutomirski --- (In reply to H. Peter Anvin from comment #13) > On July 20, 2017 10:47:54 AM PDT, ubizjak at gmail dot com > wrote: > >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81490 >

[Bug target/81490] x86: Handling of symbol ranges for __seg_fs/__seg_gs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81490 Andy Lutomirski changed: What|Removed |Added CC||luto at kernel dot org --- Comment #8

[Bug target/68491] libgcc calls __get_cpuid with 0 level breaks on early 486

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68491 Andy Lutomirski changed: What|Removed |Added CC||luto at kernel dot org --- Comment #9

[Bug rtl-optimization/66795] Incorrect and missed optimizations of __builtin_frame_address

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66795 --- Comment #2 from Andy Lutomirski --- (In reply to Andrew Pinski from comment #1) > The code below is invalid as __builtin_frame_address is only for reading > from the current frame. If this code is invalid, then what exactly is valid code

[Bug target/70146] missed-optimization: i386 hidden references should use PC32 relocations instead of GOTOFF

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70146 --- Comment #6 from Andy Lutomirski --- The PLT case could be reduced significantly by -fno-plt, but the TLS issue is just sad. I don't suppose it could be fixed with just toolchain changes while retaining compatibility with existing libc

[Bug target/70146] missed-optimization: i386 hidden references should use PC32 relocations instead of GOTOFF

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70146 --- Comment #3 from Andy Lutomirski --- I think a similar optimization could be applied to default-visibility references as well. For example, gcc can generate things like this: call__x86.get_pc_thunk.ax addl

[Bug target/70148] New: Feature request: allow overriding the SSP canary location

Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: luto at kernel dot org Target Milestone: --- The 32-bit x86 Linux kernel jumps through ridiculous hoops to but the SSP canary where GCC expects it. (If I had been paying attention when

[Bug target/70146] New: missed-optimization: i386 hidden references should use PC32 relocations instead of GOTOFF

Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: luto at kernel dot org Target Milestone: --- If I compile: extern char foo[] __attribute__((visibility("hidden"))); char *get_foo(void) {

[Bug target/55522] -funsafe-math-optimizations is unexpectedly harmful, especially w/ -shared

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522 Andy Lutomirski changed: What|Removed |Added Severity|enhancement |major --- Comment #9 from Andy