[Bug c/98168] New: Optimization that can lead to security vulnerabilities

[jpegqs at gmail dot com via Gcc-bugs]

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

Bug ID: 98168
   Summary: Optimization that can lead to security vulnerabilities
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jpegqs at gmail dot com
  Target Milestone: ---

Created attachment 49692
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49692&action=edit
bounds.c

I encountered a bug (98159) that you refused to fix because it is "undefined
behavior". But this code proves that this "compiler" behavior can lead to
security vulnerabilities in some software.

Here GCC thinks that if both signed integers are positive, then the sum of
these integers is also positive. And removes the next bounds check for the
negative values (it could be written different, but this is the common way).

int test(int a, int b, int *buf) {
  if (a >= 0 && b >= 0) {
a += b;
// let's check that we are not reading outside the buffer
if (a >= 0 && a < 8) return buf[a];
  }
  return -1;
}

So this code supposed to read the element A+B from a buffer of 8 values. And if
the sum is out of the buffer, then return -1. But when compiling with GCC
-O2/O3 on x86/x86_64 (and possibly others), you can pass A=0x7fff,
B=0x7fff and access buf[-2] (as with any negative value except -1).

Thus, optimizations that falsely assume that the target machine is performing
signed integer saturation when it is not - should be considered dangerous.

In my opinion, UB in C has a different purpose, it exists because C is a
low-level language and in most cases can use a single machine instruction for a
general operation. So for compilers it should be "target machine behavior", not
"we can do anything". And compilers must maintain this behavior while removing
some operations when optimizing the code.

[Bug c++/101786] New: P1143R2 constinit implementation is incomplete (joining with thread_local)

[jpegqs at gmail dot com via Gcc-bugs]

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

Bug ID: 101786
   Summary: P1143R2 constinit implementation is incomplete
(joining with thread_local)
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jpegqs at gmail dot com
CC: mpolacek at gcc dot gnu.org
  Target Milestone: ---

The paper says:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1143r2.html

> constinit can also be useful to compilers for non-initializing declarations
> of thread_local variables:
> 
> extern thread_local constinit x;
> int f() { return x; }
> 
> Without constinit, runtime code must be executed to perform a check of a
> guard variable and conditionally initialize x each time it is used. (Other
> techniques exist, but this approach is common.) If the variable is known to
> have constant initialization, this can be avoided.

Let's fix the missing type for x and try:

extern thread_local constinit int x;
int f() { return x; }

In case of compilation, GCC does not remove the TLS wrapper function as it
should according to this paper:

_ZTW1x:
pushrbp
mov rbp, rsp
mov eax, OFFSET FLAT:_ZTH1x
testrax, rax
je  .L2
call_ZTH1x
.L2:
mov rdx, QWORD PTR fs:0
mov rax, QWORD PTR x@gottpoff[rip]
add rax, rdx
pop rbp
ret
_Z1fv:
pushrbp
mov rbp, rsp
call_ZTW1x
mov eax, DWORD PTR [rax]
pop rbp
ret

The code it should produce should look like this: 

_Z1fv:
pushrbp
mov rbp, rsp
mov rax, QWORD PTR x@gottpoff[rip]
mov eax, DWORD PTR fs:[rax]
pop rbp
ret

What I can get now is only by replacing "thread_local constinit" with
"__thread".

Clang implements this feature.

[Bug c++/110226] New: GCC ignores include of non-existent header

[jpegqs at gmail dot com via Gcc-bugs]

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

Bug ID: 110226
   Summary: GCC ignores include of non-existent header
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jpegqs at gmail dot com
  Target Milestone: ---

Try compiling this code with g++:

#if __has_include("quadmath123.h")
#endif
#include 

You shouldn't have "quadmath123.h", but GCC will compile this without error.
Reproduced in every version of GCC since __has_include was supported (GCC
4.9.2).

Occurs in Boost headers when  is not installed.