arphaman added inline comments.

================
Comment at: include/clang/Driver/Options.td:1324
+  HelpText<"Use C++ undefined behaviour optimization for control flow paths"
+     "that reach the end of the function without executing a required return">;
+def fno_strict_return : Flag<["-"], "fno-strict-return">, Group<f_Group>,
----------------
mehdi_amini wrote:
> Quuxplusone wrote:
> > Nit: looks like Clang spells it "behavior"?
> > 
> > Nit: I'm still pedantically uncomfortable with describing the strict-return 
> > behavior as an "optimization". I suggest rephrasing this as 
> > "-fstrict-return: Treat control flow paths that fall off the end of a 
> > non-void function as unreachable."
> > 
> > (I notice that neither -fstrict-aliasing nor -fstrict-overflow have any 
> > help text at all.)
> >  I suggest rephrasing this as "-fstrict-return: Treat control flow paths 
> > that fall off the end of a non-void function as unreachable."
> 
> Is it an accurate description? `-fno-strict-return` would only disable this 
> for trivial types.
> Nit: looks like Clang spells it "behavior"?

Thanks, I forgot to use the US spelling.

> Nit: I'm still pedantically uncomfortable with describing the strict-return 
> behavior as an "optimization". I suggest rephrasing this as "-fstrict-return: 
> Treat control flow paths that fall off the end of a non-void function as 
> unreachable."

I like your suggestion, but Mehdi brought up a good point. Maybe "Always treat 
control flow paths that fall off the end of a non-void function as unreachable" 
would be better, since then `-fno-strict-return` would imply that the 
optimisation can still be used sometimes, like for the non-trivially 
destructible types.


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

Reply via email to