[Bug c/95049] New: GCC never terminates with trivial input program

[luis at luismarques dot eu]

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

Bug ID: 95049
   Summary: GCC never terminates with trivial input program
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: luis at luismarques dot eu
  Target Milestone: ---

Since at least GCC 9.1 the following trivial program results in an infinite
compilation time when compiling with -O2 or higher. This continues to happen
with GCC trunk as of the date of filing this bug.

void a() {
  for (int b; b; b = !b) {
  }
}

[Bug other/95722] New: libatomic crashes on __atomic_load of const object

[luis at luismarques dot eu]

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

Bug ID: 95722
   Summary: libatomic crashes on __atomic_load of const object
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: luis at luismarques dot eu
  Target Milestone: ---

With this code in `test.c`:

```
struct S {
int x;
int y;
int z;
};

int main() {
__attribute__((aligned(16))) static const _Atomic struct S a;
struct S b;
b = a;
}
```

On x86_64 I get:

```
$ gcc test.c -latomic && ./a.out 
Segmentation fault (core dumped)
```

It crashes on a `lock cmpxchg16b` with the address of `a`, so I imagine the
libatomic implementation is dispatching to an optimized __atomic_load case
where the code assumes it can get a (mutable) lock from the object itself, and
when it tries to acquire that lock it writes to `.rodata`, causing the crash.