[llvm-bugs] [Bug 34700] New: alpha.deadcode.UnreachableCode can't be disabled for unreachable-asserts

via llvm-bugs llvm-bugs at lists.llvm.org
Fri Sep 22 03:22:28 PDT 2017


https://bugs.llvm.org/show_bug.cgi?id=34700

            Bug ID: 34700
           Summary: alpha.deadcode.UnreachableCode can't be disabled for
                    unreachable-asserts
           Product: clang
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Static Analyzer
          Assignee: kremenek at apple.com
          Reporter: tss at iki.fi
                CC: llvm-bugs at lists.llvm.org

My code marks supposedly-unreachable code paths with i_unreached(), which is a
macro expanding to my own assert-like function marked with
__attribute__((noreturn)). It would be nice if clang didn't complain that these
i_unreached() code paths are unreachable, because that's intentional. I tried
defining it out for scan-builds, but that results in even more (and scarier)
false positives, because clang doesn't always understand that some of the
unreachable code paths really are unreachable.

Perhaps code paths that end up in a function marked with noreturn attribute
shouldn't be complained about? Or a new __attribute__((unreachable)) could be
created?

Simple test demonstrating the problem:

#include <stdlib.h>
#define i_unreached() abort()
int main(void)
{
        int a = 1;
        if (a == 1) return 0;
        i_unreached();
}

% scan-build -o scan-build -enable-checker alpha.deadcode.UnreachableCode clang
test2.c -o test
scan-build: Using '/usr/local/bin/clang' for static analysis
test2.c:7:2: warning: This statement is never executed
        i_unreached();
        ^~~~~~~~~~~~~

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20170922/4a8b19ae/attachment.html>


More information about the llvm-bugs mailing list