On Tue, 28 Jan 2020 at 10:08, Dmitry Vyukov <dvyukov@xxxxxxxxxx> wrote: > > On Tue, Jan 28, 2020 at 8:33 AM Ard Biesheuvel > <ard.biesheuvel@xxxxxxxxxx> wrote: > > > > > Should be fixed by > > > > > > > > > > https://lore.kernel.org/linux-efi/20200121093912.5246-1-ardb@xxxxxxxxxx/ > > > > > > > > Cc kasan-devel@ > > > > > > > > If everyone has to disable KASAN for the whole subdirectories like this, I am worried about we are losing testing coverage fairly quickly. Is there a bug in compiler? > > > > > > My understanding is that this is invalid C code in the first place, > > > no? It just happened to compile with some compilers, some options and > > > probably only with high optimization level. > > > > No, this is not true. The whole point of favoring IS_ENABLED(...) over > > #ifdef ... has always been that the code remains visible to the > > compiler, regardless of whether the option is selected or not, but > > that it gets optimized away entirely. The linker errors prove that > > there is dead code remaining in the object files, which means we can > > no longer rely on IS_ENABLED() to work as intended. > > I agree that exposing more code to compiler is good, I prefer to do it > as well. But I don't see how this proves anything wrt this particular > code being invalid C. Called functions still need to be defined. There > is no notion of dead code in C. Yes, this highly depends on compiler, > options, optimization level, etc. Some combinations may work, some > won't. E.g. my compiler compiles it just fine (clang 10) without > disabling instrumentation... what does it prove? I don't know. > > To clarify: I completely don't object to patching this case in gcc > with -O2, it just may be hard to find anybody willing to do this work > if we are talking about fixing compilation of invalid code. > I don't mind simply disabling KASAN altogether for this code if nobody can be bothered to fix the compiler.
