https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63888
--- Comment #8 from Kostya Serebryany <kcc at gcc dot gnu.org> --- (sorry for delay, I missed the last comment) > Generally, we do want to instrument even artificial variables, and on many > of them buffer overflow is possible. Yea, agree. > > > I.e. is a buffer overflow on these variables possible? > > > > If we don't instrument them we won't report an ODR violation. > > > > >> GCC with -fmerge-all-constants also merges many read-only constants, > > >> even addressable ones, when they have the same content. > > > > Then I guess we may have other false positives. > > We may want to disable -fmerge-all-constants under asan > > You haven't responded about the language thing, there is no such thing as > ODR in C or Fortran, so you shouldn't report it. In LLVM, I do not (and should not) know what source language is being compiled. The differences between languages are represented in the linkage types of the globals. E.g. a regular global in C will not be instrumented at all unless -fno-common is given. I.e. the difference is not in the source language but in the linkage type of the globals. % clang -S -o - -emit-llvm glob.c @GLOBAL = common global i32 0, align 4 % clang -S -o - -emit-llvm glob.c -fno-common @GLOBAL = global i32 0, align 4 % clang++ -x c++ -S -o - -emit-llvm glob.c @GLOBAL = global i32 0, align 4 Can you give an example in C where we do not want to check for ODRs, yet the basic asan instrumentation is legal? > There are 31 (or 63) bits left in __has_dynamic_init field, can't one bit be > used for whether ODR should be reported or not? That will still mean an API change, something I like to avoid when possible.
