Message ID | 20230711131105.19203-1-alx@kernel.org |
---|---|
Headers | show |
Series | Use -fno-delete-null-pointer-checks to build glibc | expand |
* Alejandro Colomar via Libc-alpha: > In file included from ../include/sys/cdefs.h:10, > from ../include/features.h:503, > from ../assert/assert.h:35, > from ../include/assert.h:1, > from gconv_conf.c:19: > ../include/dirent.h:53:17: error: expected ‘)’ before numeric constant > 53 | __nonnull (4) attribute_hidden; > | ^ This is a typo, it should be __nonnull ((4)). The __nonnull redefinition simply hides it for now. Thanks, Florian
On 2023-07-11 15:18, Florian Weimer wrote: > * Alejandro Colomar via Libc-alpha: > >> In file included from ../include/sys/cdefs.h:10, >> from ../include/features.h:503, >> from ../assert/assert.h:35, >> from ../include/assert.h:1, >> from gconv_conf.c:19: >> ../include/dirent.h:53:17: error: expected ‘)’ before numeric constant >> 53 | __nonnull (4) attribute_hidden; >> | ^ > > This is a typo, it should be __nonnull ((4)). > > The __nonnull redefinition simply hides it for now. Thanks. I'll fix it. Cheers, Alex > > Thanks, > Florian >
On Tue, 2023-07-11 at 15:11 +0200, Alejandro Colomar wrote: > Florian reported that there's -fno-delete-null-pointer-checks to tell > the compiler to not optimize, and only warn about incorrect uses of null > pointers. One potential problem is -fno-delete-null-pointer-checks not only disables optimizations based on __nonnull, but also disables the optimizations based on other provable non-null pointer values. So maybe we should run a benchmark to see if there is some severe degradation, if there is any we may fix it by moving null checks away from hot paths.
On 2023-07-11 15:22, Xi Ruoyao wrote: > On Tue, 2023-07-11 at 15:11 +0200, Alejandro Colomar wrote: >> Florian reported that there's -fno-delete-null-pointer-checks to tell >> the compiler to not optimize, and only warn about incorrect uses of null >> pointers. > > One potential problem is -fno-delete-null-pointer-checks not only > disables optimizations based on __nonnull, but also disables the > optimizations based on other provable non-null pointer values. So maybe > we should run a benchmark to see if there is some severe degradation, if > there is any we may fix it by moving null checks away from hot paths. > Sure; I don't know how to run those, so I'll provide the patches, and will let any of you run the benchmarks (or point me to some documentation to learn how to run them). Cheers, Alex