[Bug c/71613] Useful warnings silenced when macros from system headers are used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71613
Tavian Barnes changed:
What|Removed |Added
CC||tavianator at gmail dot com
--- Comment #11 from Tavian Barnes ---
Mostly commenting to make this searchable in case someone else runs into it:
-Wtsan is also affected by this:
$ cat foo.c
#include
int main(void) {
atomic_thread_fence(memory_order_relaxed);
__atomic_thread_fence(__ATOMIC_RELAXED);
return 0;
}
$ gcc -c -fsanitize=thread foo.c
foo.c: In function ‘main’:
foo.c:5:9: warning: ‘atomic_thread_fence’ is not supported with
‘-fsanitize=thread’ [-Wtsan]
5 | __atomic_thread_fence(__ATOMIC_RELAXED);
| ^~~
[Bug sanitizer/113430] Trivial program segfaults intermittently with ASAN with large CONFIG_ARCH_MMAP_RND_BITS in kernel configuration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113430 --- Comment #5 from Tavian Barnes --- (In reply to Xi Ruoyao from comment #3) > Updated the title to make it more precise. > > Note that even with Linux 6.7 the default value of CONFIG_ARCH_MMAP_RND_BITS > is still 28 (32 is set by some distro maintainer who apparently does not > know this will hit the sanitizer runtime), so "since Linux 6.7" is just > misleading. Yep agreed. I didn't expect such a patch from Arch, so I assumed it was a change in the default kernel config. For completeness, here's the Arch bug: https://gitlab.archlinux.org/archlinux/packaging/packages/linux/-/issues/20
[Bug sanitizer/113430] New: Trivial program segfaults intermittently with ASAN since Linux 6.7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113430
Bug ID: 113430
Summary: Trivial program segfaults intermittently with ASAN
since Linux 6.7
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: tavianator at gmail dot com
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
Target Milestone: ---
Since updating to Linux 6.7, I'm getting intermittent segfaults with ASAN and
ASLR enabled.
$ cat foo.c
int main(void) {
return 0;
}
$ gcc -fsanitize=address foo.c -o foo
$ while ./foo; do :; done
AddressSanitizer:DEADLYSIGNAL
=
==337494==ERROR: AddressSanitizer: SEGV on unknown address 0x636c68879e78 (pc
0x7dde493b538f bp 0x sp 0x7ffc78949970 T0)
==337494==The signal is caused by a READ memory access.
AddressSanitizer:DEADLYSIGNAL
AddressSanitizer: nested bug in the same thread, aborting.
tavianator@graphene $ gcc --version
gcc (GCC) 13.2.1 20230801
Copyright (C) 2023 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.
$ uname -a
Linux graphene 6.7.0-arch3-1 #1 SMP PREEMPT_DYNAMIC Sat, 13 Jan 2024 14:37:14
+ x86_64 GNU/Linux
Here's the backtrace:
(gdb) set disable-randomization off
(gdb) run
Starting program: /home/tavianator/code/bfs/foo
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
Program received signal SIGSEGV, Segmentation fault.
do_lookup_x (undef_name=undef_name@entry=0x761941b3e6d8
"_thread_db_sizeof_pthread", new_hash=new_hash@entry=3872132951,
old_hash=old_hash@entry=0x716f0cc8, ref=0x0,
result=result@entry=0x716f0cd0, scope=, i=0,
version=0x0, flags=3, skip=, type_class=0, undef_map=) at dl-lookup.c:405
405 const ElfW(Sym) *symtab = (const void *) D_PTR (map,
l_info[DT_SYMTAB]);
(gdb) bt
#0 do_lookup_x (undef_name=undef_name@entry=0x761941b3e6d8
"_thread_db_sizeof_pthread", new_hash=new_hash@entry=3872132951,
old_hash=old_hash@entry=0x716f0cc8, ref=0x0,
result=result@entry=0x716f0cd0, scope=, i=0,
version=0x0, flags=3, skip=, type_class=0, undef_map=) at dl-lookup.c:405
#1 0x7619421e20b8 in _dl_lookup_symbol_x (undef_name=0x761941b3e6d8
"_thread_db_sizeof_pthread", undef_map=, ref=0x716f0d58,
symbol_scope=,
version=0x0, type_class=0, flags=3, skip_map=0x0) at dl-lookup.c:793
#2 0x76194197300e in do_sym (handle=, name=0x761941b3e6d8
"_thread_db_sizeof_pthread", who=0x761941afffb3
<__sanitizer::ThreadDescriptorSize()+35>,
vers=vers@entry=0x0, flags=flags@entry=2) at dl-sym.c:146
#3 0x761941973331 in _dl_sym (handle=, name=, who=) at dl-sym.c:195
#4 0x7619418a6ae8 in dlsym_doit (a=a@entry=0x716f0fc0) at dlsym.c:40
#5 0x7619421d94e1 in __GI__dl_catch_exception
(exception=exception@entry=0x716f0f20, operate=0x7619418a6ad0 ,
args=0x716f0fc0) at dl-catch.c:237
#6 0x7619421d9603 in _dl_catch_error (objname=0x716f0f78,
errstring=0x716f0f80, mallocedp=0x716f0f77, operate=,
args=) at dl-catch.c:256
#7 0x7619418a64f7 in _dlerror_run (operate=operate@entry=0x7619418a6ad0
, args=args@entry=0x716f0fc0) at dlerror.c:138
#8 0x7619418a6b75 in dlsym_implementation (dl_caller=,
name=, handle=) at dlsym.c:54
#9 ___dlsym (handle=, name=) at dlsym.c:68
#10 0x761941afffb3 in __sanitizer::ThreadDescriptorSize () at
/usr/src/debug/gcc/gcc/libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cpp:298
#11 0x761941b017ae in __sanitizer::ThreadDescriptorSize () at
/usr/src/debug/gcc/gcc/libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cpp:294
#12 __sanitizer::GetTls (size=0x716f1098, addr=0x7619421b0040) at
/usr/src/debug/gcc/gcc/libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cpp:498
#13 __sanitizer::GetThreadStackAndTls (main=true,
stk_addr=stk_addr@entry=0x7619421b0020, stk_size=stk_size@entry=0x716f10a0,
tls_addr=tls_addr@entry=0x7619421b0040,
tls_size=tls_size@entry=0x716f1098) at
/usr/src/debug/gcc/gcc/libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cpp:595
#14 0x761941af0ff4 in __asan::AsanThread::SetThreadStackAndTls
(this=this@entry=0x7619421b, options=) at
/usr/src/debug/gcc/gcc/libsanitizer/asan/asan_thread.h:77
#15 0x761941af14ee in __asan::AsanThread::Init
(this=this@entry=0x7619421b, options=options@entry=0x0) at
/usr/src/debug/gcc/gcc/libsanitizer/asan/asan_thread.cpp:234
#16 0x761941af19e5 in __asan::AsanThread::ThreadStart
[Bug middle-end/112748] memmove(ptr, ptr, n) call optimized out even at -O0 with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112748 --- Comment #2 from Tavian Barnes --- (In reply to Andrew Pinski from comment #1) > Does -fsanitize=address remove it? Yes, it's still removed with -fsanitize=address. While ASAN is necessary to check that the memory is really allocated, UBSAN should at least check that ptr is not NULL. So it shouldn't be removed in either case.
[Bug c/112748] New: memmove(ptr, ptr, n) call optimized out even at -O0 with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112748
Bug ID: 112748
Summary: memmove(ptr, ptr, n) call optimized out even at -O0
with -fsanitize=undefined
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: tavianator at gmail dot com
Target Milestone: ---
This is counter-productive, as I wrote the memmove() specifically to get the
sanitizers to check that ptr really points to a big enough allocation.
$ cat foo.c
typedef __SIZE_TYPE__ size_t;
void *memmove(void *dest, void *src, size_t n);
void foo(void *ptr, size_t n) {
memmove(ptr, ptr, n);
}
$ gcc -O0 -fsanitize=undefined -S foo.c
$ cat foo.s
.file "foo.c"
.text
.globl foo
.type foo, @function
foo:
.LFB0:
.cfi_startproc
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq%rsp, %rbp
.cfi_def_cfa_register 6
movq%rdi, -8(%rbp)
movq%rsi, -16(%rbp)
nop
popq%rbp
.cfi_def_cfa 7, 8
ret
.cfi_endproc
.LFE0:
.size foo, .-foo
.ident "GCC: (GNU) 13.2.1 20230801"
.section.note.GNU-stack,"",@progbits
[Bug middle-end/94787] Failure to detect single bit popcount pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94787 Tavian Barnes changed: What|Removed |Added CC||tavianator at gmail dot com --- Comment #4 from Tavian Barnes --- (In reply to Wilco from comment #3) > I actually posted a patch for this and popcount(x) > 1 given the reverse > transformation is faster on all targets - even if they have popcount > instruction (since they are typically more expensive). This is true on x86 > as well, (x-1) u (x ^ -x)
[Bug target/106952] Missed optimization: x < y ? x : y not lowered to minss
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106952 --- Comment #2 from Tavian Barnes --- (In reply to Alexander Monakov from comment #1) > Note, your 'max' function is the same as 'min' (the issue remains with that > corrected). Whoops, thanks. Also I just noticed that GCC 12.2 does better (but not perfect) with #define min(x, y) ((x) < (y) ? (x) : (y)) #define max(x, y) ((x) > (y) ? (x) : (y)) instead of the inline functions. Doesn't seem to help GCC trunk though.
[Bug target/106952] New: Missed optimization: x < y ? x : y not lowered to minss
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106952
Bug ID: 106952
Summary: Missed optimization: x < y ? x : y not lowered to
minss
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: tavianator at gmail dot com
Target Milestone: ---
Created attachment 53580
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53580=edit
Assembly from gcc -O3 -S bug.c
The following is an implementation of a ray/axis-aligned box intersection test:
struct ray {
float origin[3];
float dir_inv[3];
};
struct box {
float min[3];
float max[3];
};
static inline float min(float x, float y) {
return x < y ? x : y;
}
static inline float max(float x, float y) {
return x < y ? x : y;
}
_Bool intersection(const struct ray *ray, const struct box *box) {
float tmin = 0.0, tmax = 1.0 / 0.0;
for (int i = 0; i < 3; ++i) {
float t1 = (box->min[i] - ray->origin[i]) * ray->dir_inv[i];
float t2 = (box->max[i] - ray->origin[i]) * ray->dir_inv[i];
tmin = min(max(t1, tmin), max(t2, tmin));
tmax = max(min(t1, tmax), min(t2, tmax));
}
return tmin < tmax;
}
However, gcc -O3 doesn't use minss/maxss for every min()/max(). Instead, some
of them are lowered to conditional jumps which regresses performance
significantly since the branches are unpredictable.
Simpler variants like
tmin = max(tmin, min(t1, t2));
tmax = min(tmax, max(t1, t2));
get the desired codegen, but that behaves differently if t1 or t2 is NaN.
"Bisecting" with godbolt.org, it seems this is an old regression: 4.8.5 was
good, but 4.9.0 was bad.
