[Bug sanitizer/107893] New: gcc trunk at -O0 (UBSan) misses a Null-pointer-dereference

[Bug sanitizer/107893] New: gcc trunk at -O0 (UBSan) misses a Null-pointer-dereference

[shaohua.li at inf dot ethz.ch]

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

            Bug ID: 107893
           Summary: gcc trunk at -O0 (UBSan) misses a
                    Null-pointer-dereference
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: sanitizer
          Assignee: unassigned at gcc dot gnu.org
          Reporter: shaohua.li at inf dot ethz.ch
                CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
                    jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at gcc dot gnu.org
  Target Milestone: ---

For the following code, `gcc-trunk -O0 -fsanitize=undefined 
-fno-sanitize-recover=all` misses the NULL-pointer-dereference, while
`gcc-trunk -Ox -fsanitize=address  -fno-sanitize-recover=all` (x=1, 2, 3, or s)
can detect it.

I checked gcc8/9/10/11/12 and they all have this issue.

clang can detect it at all optimization levels.

Compiler explorer: https://godbolt.org/z/85qfdccse

% cat a.c
int main() {
  int *a = 0;
   (a[1] | a[0]) >> 056;
}
%
% gcc-tk -O0 -fsanitize=undefined -fno-sanitize-recover=all -w a.c &&./a.out
Segmentation fault
% gcc-tk -O1 -fsanitize=undefined -fno-sanitize-recover=all -w a.c &&./a.out
a.c:3:13: runtime error: load of null pointer of type 'int'
%

[Bug sanitizer/107893] gcc trunk at -O0 (UBSan) misses a Null-pointer-dereference

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
You don't store the shift result anywhere and there are no side-effects in the
expression, so nothing prevents the compiler from optimizing out the whole
expression.

[Bug sanitizer/107893] gcc trunk at -O0 (UBSan) misses a Null-pointer-dereference

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
Well, it first performs the a[1] access which segfaults, isn't that expected?

[Bug sanitizer/107893] gcc trunk at -O0 (UBSan) misses a Null-pointer-dereference

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
That is,

int main() {
  int *a = 0;
   (a[0] | a[1]) >> 056;
}

works at -O0:

t.c:3:6: runtime error: load of null pointer of type 'int'

[Bug sanitizer/107893] gcc trunk at -O0 (UBSan) misses a Null-pointer-dereference

[shaohua.li at inf dot ethz.ch]

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

--- Comment #4 from Li Shaohua <shaohua.li at inf dot ethz.ch> ---
(In reply to Richard Biener from comment #3)
> That is,
> 
> int main() {
>   int *a = 0;
>    (a[0] | a[1]) >> 056;
> }
> 
> works at -O0:
> 
> t.c:3:6: runtime error: load of null pointer of type 'int'

Yes, the a[1] access caused the segfault. For clang's UBsan, it emits an error
message for a[1]:

a.c:3:5: runtime error: applying non-zero offset 4 to null pointer
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior a.c:3:5 in


Is there a way for gcc's UBsan to warn such errors?