https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89764
Bug ID: 89764
Summary: ubsan diagnostic on generic lambdas decayed to
function pointers
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: patrick.a.moran at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone: ---
Created attachment 45992
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45992&action=edit
The minimal reproduction as a separate file
I've observed this on a vanilla built-from-source gcc 8.3.0. You can reproduce
by running (with the attached repro.cpp)
gcc -fsanitize=undefined repro.cpp -o repro && ./repro
You get the error message
repro.cpp:2:34: runtime error: member call on null pointer of type 'const
struct __lambda0'
The error does occur if a generic lambda with an empty capture is used, but the
error does not occur if a non-generic lambda with an empty capture is used (ie,
if you alter the repro to replace the "auto" with an "int", the error goes
away).
I know that by 8.1.5.1.6, the produced function point need only have "the same
effect as invoking the closure type’s function call operator", so requiring the
closure object to still be alive for the free function to be called is probably
one of the permitted behaviors, but I was hoping that this was unintentional,
particularly since that is true of non-generic lambdas. Being able to use
lambdas with empty captures to generate free functions is an ergonomic win for
us.
