arphaman added inline comments.
================
Comment at: include/clang/Sema/AnalysisBasedWarnings.h:93
- void IssueWarnings(Policy P, FunctionScopeInfo *fscope,
- const Decl *D, const BlockExpr *blkExpr);
+ void IssueWarnings(Policy P, FunctionScopeInfo *fscope, Decl *D,
+ const BlockExpr *blkExpr);
----------------
Quuxplusone wrote:
> If you remove the coupling between -fno-strict-return and -Wreturn-type, then
> you won't need to remove `const` in all these places. I think that alone is a
> good enough reason not to couple them.
That's a fair point, I've thought about it a bit more and decided to get rid of
the "-Wreturn-type" heuristic. If anything I can try a follow-up patch later if
we really end up needing it, but I don't think so.
================
Comment at: lib/CodeGen/CodeGenFunction.cpp:1078
+ QualType T = FD->getReturnType();
+ if (T.isTriviallyCopyableType(Context)) {
+ // Avoid the optimization for functions that return trivially copyable
----------------
Quuxplusone wrote:
> Peanut-gallery question: Does `isTriviallyCopyableType` also check that the
> type is trivially destructible and/or default-constructible? Do those things
> matter?
Yes for trivially destructible, since it calls
`CXXRecordDecl::isTriviallyCopyable()` which checks. No for trivially
default-constructible, I fixed that.
I think that for us it doesn't really matter that much, since we're mostly
worried about C code compiled in C++ mode.
================
Comment at: lib/CodeGen/CodeGenFunction.cpp:1173
+ } else if (CGM.getCodeGenOpts().StrictReturn ||
+ shouldUseUndefinedBehaviorReturnOptimization(FD, getContext()))
{
+ if (CGM.getCodeGenOpts().OptimizationLevel == 0)
----------------
Quuxplusone wrote:
> I'd expect this to look more like
>
> bool ShouldOmitUnreachable = !CGM.getCodeGenOpts().StrictReturn &&
> FD->getReturnType().isTriviallyCopyableType(Context);
> // same ifs as the old code
> if (!ShouldOmitUnreachable) {
> Builder.CreateUnreachable();
> Builder.ClearInsertionPoint();
> }
>
> Or in fact, is there a good reason this codepath isn't piggybacking on
> `FD->hasImplicitReturnZero()`? Why not just give every function
> `hasImplicitReturnZero` when `-fno-strict-return` is in effect?
>
> At which point, `-fno-strict-return` might seem like the wrong name; you
> could just call it something like `-fimplicit-return-zero`, which would also
> have the minor benefit of making the `-fno-*` option the default.
> Or in fact, is there a good reason this codepath isn't piggybacking on
> FD->hasImplicitReturnZero()? Why not just give every function
> hasImplicitReturnZero when -fno-strict-return is in effect?
I understand your suggestion, but I'd prefer not to set `hasImplicitReturnZero`
for all functions, since then Sema won't warn about the missing return, which
we still want.
> At which point, -fno-strict-return might seem like the wrong name; you could
> just call it something like -fimplicit-return-zero, which would also have the
> minor benefit of making the -fno-* option the default.
I don't think a name like "-fimplicit-return-zero" is appropriate, since it
implies that the compiler guarantees a return of a zero value. This might
mislead users as they might think that they can use the return value without
triggering undefined behaviour, which isn't true.
Repository:
rL LLVM
https://reviews.llvm.org/D27163
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
