[llvm-dev] [cfe-dev] Zero length function pointer equality (original) (raw)

David Blaikie via llvm-dev llvm-dev at lists.llvm.org
Fri Jul 24 18:39:55 PDT 2020

Looks perfect to me!

well, a couple of questions: Why a noop, rather than int3/ud2/etc? Might be worth using the existing code that places such an instruction when building at -O0? & you mention that this causes problems on Windows - but ICF done by the Windows linker does not cause such problems? (I'd have thought they'd result in the same situation - two functions described as being at the same address?) is there a quick summary of why those two cases turn out differently?

On Fri, Jul 24, 2020 at 6:17 AM Hans Wennborg <hans at chromium.org> wrote:

Maybe we can just expand this to always apply: https://reviews.llvm.org/D32330 On Fri, Jul 24, 2020 at 2:46 AM David Blaikie via cfe-dev <cfe-dev at lists.llvm.org> wrote: > > LLVM can produce zero length functions from cases like this (when > optimizations are enabled): > _> void f1() { builtinunreachable(); } > int f2() { /* missing return statement */ } > > This code is valid, so long as the functions are never called. > > I believe C++ requires that all functions have a distinct address (ie: > &f1 != &f2) and LLVM optimizes code on this basis (assert(f1 == f2) > gets optimized into an unconditional assertion failure) > > But these zero length functions can end up with identical addresses. > > I'm unaware of anything in the C++ spec (or the LLVM langref) that > would indicate that would allow distinct functions to have identical > addresses - so should we do something about this in the LLVM backend? > add a little padding? a nop instruction? (if we're adding an > instruction anyway, perhaps we might as well make it an int3?) > > (I came across this due to DWARF issues with zero length functions & > thinking about if/how this should be supported) _> ________________________ > cfe-dev mailing list > cfe-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

More information about the llvm-dev mailing list