This method will happily accept double values for float constants that are clearly out of range or have precision beyond the acceptable precision of a float. The current implementation accepts all double values as valid for float. It shouldn't do that. Simply casting double -> float -> double and comparing the two doubles doesn't work well as a test because of rounding errors and/or conversion errors from decimal notation in AsmParser. Hex conversions work fine as long as the value is a valid FP double.
Created attachment 189 [details] Test case for "float" range This test case just makes sure that double values can be assigned to double constants, float values can be assigned to float constants, but double values cannot be assigned to float constants.
Test case added here: http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20041206/021805.html
Patches to fix: http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20041206/021807.html http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20041206/021808.html Bug Resolved.
Although the patch passed the nightly test and the regression test, it didn't work on all platforms due to buggy std::numeric_limits<...> implementations. We tried some math.h things too, but that didn't work. The patch was reverted so this bug is open until we can find something that works on all platforms.
Its unclear to me how this should be implemented. What I want to do is make sure that the range of double values accepted for a FloatTy is within range for the float type. The cast thing doesn't work, neither does limits checking (because std::numeric_limits<float> isn't portable or doesn't work everywhere). There are things in math.h that could be used but they are also unreliable from platform to plaform so .. what do we do? I'm thinking along these lines: float FV = float(V); double DV = double(FV); return isinf(V) || isnan(V) || V == DV Any other ideas?
That seems reasonable to me. I really have no idea what the right check is. Putting something in at the start of the 1.5 cycle that tests clean seems reasonable though. -Chris
Fixed. Patches Here: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20051219/030358.html http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20051219/030359.html http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20051219/030360.html
This is a pernicious little bug. Reopened until a solution can be found that doesn't cause tests to fail.
Not happening for 1.7. I don't think this bug really makes sense. Should we just close it as wontfix? -Chris
This bug has been around for a long time, we don't have a better solution than the current one, and it isn't really affecting anything. So, its WONTFIX'd