[cfe-dev] [EXTERNAL] Issue where Lambda capture of reference to globals doesn't actually capture anything

[Arthur O'Dwyer via cfe-dev]

On Mon, Oct 26, 2020 at 8:14 PM Richard Smith via cfe-dev <
cfe-dev at lists.llvm.org> wrote:
> On Mon, 26 Oct 2020 at 16:57, Lewis, Cannada via cfe-dev <
cfe-dev at lists.llvm.org> wrote:
>>
>> I’m not a standards reading expert but does
>>
>> Note 7:
>> An id-expression that is not an odr-use refers to the original entity,
never to a member of the closure type.
>> However, such an id-expression can still cause the implicit capture of
the entity.
>> — end note
>>
>> From the text imply that the program https://godbolt.org/z/feKxdK is
actually implementation defined? Or does gcc have a bug here?
>
> GCC has a bug, according to the standard wording. The mention of myfoo
does not constitute an odr-use, so is not rewritten to use the capture.
Clang's behavior is correct per the standard wording.
>
> The standard rule is certainly surprising in this particular case. I
think the rule in question is driven by the desire for adding a
capture-default to a valid lambda to not change its meaning. For example:
https://godbolt.org/z/nrWsvj

Hmm. It's insane that you can use local variable `x` inside a lambda that
doesn't capture anything; I wasn't aware of that. If the formal wording
really says you can do that, then that seems like a formal-wording bug to
me.
GCC and Clang disagree in a different way about whether it's okay to
dereference a *pointer* inside a lambda without capturing it; here it's GCC
that is doing the crazy thing, and Clang that is reasonably refusing to
compile a reference to `x` when `x` hasn't been captured.
https://godbolt.org/z/bjbr3f

The rules about when compilers are able to "constant-fold" away variables
that otherwise would need to be captured, strikes me as similar in spirit
to the rules about when compilers are able to "constant-fold" away
complicated expressions in constant expressions. Some compilers seem to be
trying to be "helpful" by letting the optimizer's knowledge leak into the
front-end, and some are following the same rules as one's "head compiler"
would.

–Arthur
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20201027/f10be80a/attachment.html>