rsmith added a comment.
In D89212#2324127 <https://reviews.llvm.org/D89212#2324127>, @rjmccall wrote:
> This seems like a good idea in the abstract; we'll need to figure out what
> the practical consequences are.
Looks like it triggers warnings in Abseil at least; there, the code looks like
this:
// spinlock.h
void AbslInternalSpinLockDelay();
inline void lock(...) {
AbslInternalSpinLockDelay();
}
// spinlock.cc
__attribute__((weak)) void AbslInternalSpinLockDelay() { ... }
... and adding the `weak` attribute to the declaration would change the meaning
of the program (we want an `external` reference, not an `extern_weak`
reference).
Perhaps we should only warn if the function is not defined in the same
translation unit? If it is defined, then I think its address can never be null,
and CodeGen will emit it with the correct linkage. We still have the problem
that `==` comparisons against pointers to the function can incorrectly evaluate
to `false`, but I think that's really a problem with aliases rather than with
weakness. (C++ requires that `void f(), g(); bool b = f == g;` initializes `b`
to `false` even though the only correct answer is that we don't know; we refuse
to evaluate the comparison if either `f` or `g` is weak, but I think that's
only really addressing the problem that they could both be null, not that they
could have the same non-null address, since the latter problem isn't specific
to weak declarations. I think the constant evaluator is being
overly-conservative, and could evaluate `f == g` to `false` if `f` and `g` are
both weak but at least one of them is defined locally, under the
language-guaranteed assumption that distinct functions have different
addresses. And perhaps we should have a way of declaring a function as
potentially aliasing another function without actually defining the function as
an alias, as a way to turn off that assumption independent of weakness?)
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D89212/new/
https://reviews.llvm.org/D89212
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
