On 10/18/2017 11:16 AM, Jakub Jelinek wrote: > On Wed, Oct 18, 2017 at 11:00:30AM +0200, Martin Liška wrote: >> Hi. >> >> I would like to use this thread to slightly describe differences in GCC and >> LLVM. >> I compared options support by both and: >> >> UBSAN: >> >> 1) >> gcc: error: unrecognized argument to -fsanitize= option: ‘nullability-arg’ >> gcc: error: unrecognized argument to -fsanitize= option: ‘nullability-assign’ >> gcc: error: unrecognized argument to -fsanitize= option: ‘nullability-return’ > > I believe those are for diagnostic of some Objective-C addition, some > _Nullable and _Nonnull keywords on (pointer) types. Seems LLVM supports it > as an > extension even for C/C++.
Ok. > >> I guess it's covered by -fsanitize=nonnull-attribute and >> -fsanitize=returns-nonnull-attribute. >> One can't have in GCC a local variable with non-null attribute >> (nullability-assign), right? >> >> 2) unsigned-integer-overflow >> >> As documented, not being a real UBSAN. Do we want that or seen as not useful? > > This one is not implemented on purpose, it doesn't make any sense to me. Works for me. > >> 3) function >> >> Indirect function pointer comparison using RTTI in C++. Would it be useful? >> Ideas? > > Dunno what this one is about. $ cat indir.cpp void foo(void) { } struct A { static int bar(void) { return 0; } }; void call (int (*f) (void)) { f(); } int main() { A a; call ((int (*) (void))&foo); } $ ~/bin/llvm/bin/clang++ -fsanitize=function /tmp/indir.cpp && ./a.out /tmp/indir.cpp:10:3: runtime error: call to function foo() through pointer to incorrect function type 'int (*)()' (/tmp/a.out+0x42b9b0): note: foo() defined here > > 4) builtin > > Which I've posted yesterday patch for. I noticed, thanks! > >> ASAN: >> >> For ASAN, there's quite up-to-date page: >> https://github.com/google/sanitizers/wiki/AddressSanitizerClangVsGCC-(5.0-vs-7.1) >> >> The page is quite up-to-date. Currently we should cover all what LLVM >> supports. Am I right? Or is there any interesting >> feature we miss? > > As I said on IRC, we probably should be redirecting at sanopt or asan pass > __builtin_memcpy etc. calls to __asan_memcpy etc. I'll take a look. Martin > > Jakub >