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

[luto at kernel dot org via Gcc-bugs]

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 think this analogy is off.  Maybe for most questionable optimization or
codegen options it would apply, but -ffast-math is more like:

Patient: Doctor, it hurts me when my neighbor does this.
Doctor: Then tell your neighbor not to read that and to read the fine print on
the box.

If nitroglycerin pills have side effects and patients need to read the label,
maybe fine.  But if they start exploding and breaking other peoples' windows,
that's a whole different problem.

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

[luto at kernel dot org via Gcc-bugs]

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

[luto at kernel dot org via Gcc-bugs]

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
-fcf-protection=stack exists at all.  If not, then I'm wondering why your patch
seems to be effectively hardcoding "stack" mode for SJLJ?

You could probably fix this bug differently by changing __builtin_setjmp() to
store 0 for SSP in "none" mode.  Then at least -fcf-protection=none wouldn't
emit CET code.

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

[luto at kernel dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98997

Bug ID: 98997
   Summary: Linking mismatched -fcf-protection objects generates
incorrect code
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  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; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ cat cet1.c
#include 

void test(jmp_buf buf)
{
__builtin_longjmp(buf, 1);
}
$ cat cet2.c
#include 

void test(jmp_buf buf);

int main()
{
jmp_buf buf;
if (__builtin_setjmp(buf) == 0)
test(buf);
return 0;
}
$ gcc -c -O2 cet1.c -fcf-protection=full
$ gcc -c -O2 cet2.c
$ gcc -o cet -O2 cet1.o cet2.o
$ ./cet
Illegal instruction (core dumped)

Presumably the magic CET fixup in the builtin setjmp/longjmp requires that
matching code is generated for both.  I'm testing on a non-CET system.

I haven't even tried to figure out if anything sensible happens to the CET GNU
property, but I think the current GCC behavior is impolite at best.  I think
GCC should do one of a few things:

1. Generate working code.

2. Fail to link.

3. At least document this pitfall very clearly.

I really hope this doesn't affect shared objects.

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

[luto at kernel dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48877

Andy Lutomirski  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #3 from Andy Lutomirski  ---
(In reply to Ivan Sorokin from comment #2)
> Modern GCC doesn't generate excessive moves for this example. It looks like
> the problem was fixed in 4.9.0: https://godbolt.org/z/MqE7sP .
> 
> I think the bug can be closed now.

Indeed.