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

2022-11-28 Thread shaohua.li at inf dot ethz.ch via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107893 --- Comment #4 from Li Shaohua --- (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,

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

2022-11-28 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107893 --- Comment #3 from Richard Biener --- 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

2022-11-28 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107893 --- Comment #2 from Richard Biener --- 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

2022-11-28 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107893 --- Comment #1 from Jakub Jelinek --- 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.