[llvm-bugs] [Bug 35886] Inconsistent narrowing errors

[via llvm-bugs]

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

Shane <FreeBSD at Shaneware.biz> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|INVALID                     |---
             Status|RESOLVED                    |REOPENED

--- Comment #2 from Shane <FreeBSD at Shaneware.biz> ---
While the compiler defaults used in that particular build are the reason for
seeing the results I reported as errors and not warnings, it doesn't change the
inconsistent results that I have reported. You can use clang 3.8 with
-std=c++11 and get the same result, you can also use -Wno-error=c++11-narrowing
and turn the errors into warnings, but that doesn't change the inconsistencies
- some narrowing is reported and some is ignored, or in some cases the types
used in a calculation are larger than needed which causes narrowing when the
final type is the same.

Using a literal in a float array initialisation it is treated as a double value
while assigning the same literal to a single float variable it is treated as a
float.

float d = 1.8;
float e = 1.0 - d;           // here 1.0 is a float - OK
float f[2] = { 1.0 - d, e }; // here 1.0 is a double so gets narrowed to a
float

test.cpp:44:20: error: non-constant-expression cannot be narrowed from type
'double' to 'float' in initializer list
      [-Wc++11-narrowing]
    float f[2] = { 1.0 - d, e }; // here 1.0 is a double so gets narrowed to a
float
                   ^~~~~~~
test.cpp:44:20: note: insert an explicit cast to silence this issue
    float f[2] = { 1.0 - d, e }; // here 1.0 is a double so gets narrowed to a
float
                   ^~~~~~~
                   static_cast<float>( )

So the first array item appears to be calculated by interpreting the literal as
a double so the float used in the calculation would also be promoted to a
double, then the result gets narrowed to a float, whether that is treated as an
error or warning depends on the settings but it is still inconsistent compared
to the previous line and sounds like some excessive conversion steps are being
taken, so manually casting this value is wanted for the optimisation rather
than turning it into a warning and ignoring it.

Also the example of passing a long to an int function parameter or returning a
long as an int function value is ignored when (I think) it should give the same
narrowing warning or error as assigning a variable to a smaller one.

-- 
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/20180111/df0d47ff/attachment.html>