r320982 - Revert r320978 "No -fsanitize=function warning when calling noexcept function through non-noexcept pointer in C++17"

[Richard Smith via cfe-commits]

On 18 Dec 2017 15:23, "Stephan Bergmann via cfe-commits" <
cfe-commits at lists.llvm.org> wrote:

On 12/18/2017 03:05 PM, Richard Smith wrote:

> Can we just strip the noexcept from the function type before emitting the
> fsan type info?
>

As is apparently already done when emitting the (not noexcept-annotated)
__cxxabiv1::__function_type_info referenced from a noexcept-annotated
__cxxabiv1::__pointer_type_info?

That would indeed look like a better way to address this, then.  But
wouldn't that also prevent -fsanitize=function from finding mismatches
where a non-noexcept function is called through a noexcept pointer, as in

  void f() {}
  void g(void (*p)() noexcept) { p(); }
  int main() { g(reinterpret_cast<void (*)() noexcept>(f)); }


That call seems OK to me; if the function does throw, std::terminate() will
be called.

On 18 Dec 2017 13:52, "Stephan Bergmann via cfe-commits" <
> cfe-commits at lists.llvm.org <mailto:cfe-commits at lists.llvm.org>> wrote:
>
>     Author: sberg
>     Date: Mon Dec 18 05:51:48 2017
>     New Revision: 320982
>
>     URL: http://llvm.org/viewvc/llvm-project?rev=320982&view=rev
>     <http://llvm.org/viewvc/llvm-project?rev=320982&view=rev>
>     Log:
>     Revert r320978 "No -fsanitize=function warning when calling noexcept
>     function through non-noexcept pointer in C++17"
>
>     At least
>     <http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-android/
>     builds/6013/steps/annotate/logs/stdio
>     <http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-android/
>     builds/6013/steps/annotate/logs/stdio>> complains about
>     __ubsan::__ubsan_handle_function_type_mismatch_abort (compiler-rt
>     lib/ubsan/ubsan_handlers.cc) returning now despite being declared
>     'noreturn', so
>     looks like a different approach is needed for the
>     function_type_mismatch check
>     to be called also in cases that may ultimately succeed.
>
>     Modified:
>          cfe/trunk/lib/CodeGen/CGExpr.cpp
>
>     Modified: cfe/trunk/lib/CodeGen/CGExpr.cpp
>     URL:
>     http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CG
> Expr.cpp?rev=320982&r1=320981&r2=320982&view=diff
>     <http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/C
> GExpr.cpp?rev=320982&r1=320981&r2=320982&view=diff>
>     ============================================================
> ==================
>     --- cfe/trunk/lib/CodeGen/CGExpr.cpp (original)
>     +++ cfe/trunk/lib/CodeGen/CGExpr.cpp Mon Dec 18 05:51:48 2017
>     @@ -4504,14 +4504,10 @@ RValue CodeGenFunction::EmitCall(QualTyp
>                 Builder.CreateICmpEQ(CalleeRTTI, FTRTTIConst);
>             llvm::Constant *StaticData[] = {
>               EmitCheckSourceLocation(E->getLocStart()),
>     -        EmitCheckTypeDescriptor(CalleeType),
>     -        cast<FunctionProtoType>(FnType)->isNothrow(getContext())
>     -          ? llvm::Constant::getNullValue(FTRTTIConst->getType())
>     -          : FTRTTIConst
>     +        EmitCheckTypeDescriptor(CalleeType)
>             };
>             EmitCheck(std::make_pair(CalleeRTTIMatch,
>     SanitizerKind::Function),
>     -                SanitizerHandler::FunctionTypeMismatch, StaticData,
>     -                {CalleePtr, CalleeRTTI});
>     +                SanitizerHandler::FunctionTypeMismatch, StaticData,
>     CalleePtr);
>
>             Builder.CreateBr(Cont);
>             EmitBlock(Cont);
>
_______________________________________________
cfe-commits mailing list
cfe-commits at lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20171219/c04d4fc1/attachment-0001.html>