[LLVMbugs] [Bug 22579] New: merging of code can lead to misleading line number information; add flag to disable it in some cases?

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=22579

            Bug ID: 22579
           Summary: merging of code can lead to misleading line number
                    information; add flag to disable it in some cases?
           Product: clang
           Version: 3.3
          Hardware: PC
                OS: FreeBSD
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: llvm at insonuit.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

In cases where several lines of code are merged together to share instructions,
llvm
currently picks a single line number to 'represent' those in the DWARF.  This
can lead
to misleading backtraces.

An example from our source base is a large function with some 20 assertion
failure
points.  If any of those assertions fails, the backtrace will point to a single
one
of them, because all of them share the code to our assertion failure function. 
This
is, in part, because that function has __attribute((noreturn)).

We could remove that attribute, but that opens us up to warnings based on
static
analysis of the code.

If there were a flag to disable the code merging which is happening here, we
could
get useful backtraces.

For example, code like this

  extern int do_assert(const char *, int, const char *, ...)
__attribute((noreturn));

  void try(int a)
  {
    if (a & 1)
      do_assert("one", 0, "");
    if (a & 2)
      do_assert("two", 0, "");
    if (a & 4)
      do_assert("three", 0, "");
  }

generates a single call to do_assert.  This is normally a Good Thing, but it
has been
confusing some of our developers (and we don't care that much).

Changing __attribute((noreturn)) to __attribute((analyzer_noreturn)) seems like
it
might be a path forward, but it triggers missing-return-value warnings for code
like

  int val(int a)
  {
    if (a == 1) return 1;
    if (a == 2) return 2;
    do_assert("bad a", 0, "");
  }

Interestingly, it does *not* trigger a number of other warnings, such as
uninitialized
variables in the default case of a switch, so perhaps this is a case where this
warning
should have been disabled [somehow] by the analyzer_noreturn attribute?

An alternative would be to avoid generating line numbers in the DWARF at all
for this
type of merged code.  That might be reasonable too.

-- 
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/20150213/b8f26bf0/attachment.html>