[LLVMbugs] [Bug 21287] New: constexpr evaluation can generate spurious warnings (only) when other errors are reported

[bugzilla-daemon at llvm.org]

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

            Bug ID: 21287
           Summary: constexpr evaluation can generate spurious warnings
                    (only) when other errors are reported
           Product: clang
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++11
          Assignee: unassignedclangbugs at nondot.org
          Reporter: oneill+llvmbugs at cs.hmc.edu
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified

The following code produces a compiler warning, but *only* when it is already
complaining about some other error:

#include <cstdio>

template <int x, int y>
int spurious()
{
    constexpr int static_result = (x >= y) ? (1000 / (x/y)) : 0;
    return static_result;
}

int main()
{
    printf("%d %d\n", spurious<1,2>(), spurious<2,1>());

    // If you comment out the line below, the code compiles without warnings
    #error This error will trigger a spurious warning about division by zero

    return 0;
}

With Clang 3.5 and r219141 from trunk, it produces the following error:

spurious.cpp:15:6: error: This error will trigger a spurious warning about
      division by zero
    #error This error will trigger a spurious warning about division by zero
     ^
spurious.cpp:6:52: warning: division by zero is undefined [-Wdivision-by-zero]
    constexpr int static_result = (x >= y) ? (1000 / (x/y)) : 0;
                                                   ^ ~~~~~
spurious.cpp:12:23: note: in instantiation of function template specialization
      'spurious<1, 2>' requested here
    printf("%d %d\n", spurious<1,2>(), spurious<2,1>());
                      ^
1 warning and 1 error generated.

The error is wrong because the division-by-zero arm of the ternary operator
should not be evaluated (it's the true arm and the condition is false -- the
issue also arises if we flip the condition swap the arms around). 

When no other error is generated (e.g., comment out #error in the code), it
correctly generates the code, here's the llvm bitcode:

define i32 @main() #0 {
entry:
  %call2 = tail call i32 (i8*, ...)* @printf(i8* getelementptr inbounds ([7 x
i8]* @.str, i64 0, i64 0), i32 0, i32 500)
  ret i32 0
}

As you can see, the code ran properly and no division by zero occurred.

-- 
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/20141015/df7d46cd/attachment.html>