JDK-8259288 : Debug build failure with clang-10 due to -Wimplicit-int-float-conversion
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 16,17
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2021-01-06
  • Updated: 2022-05-23
  • Resolved: 2021-04-22
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 17
17 b20Fixed
Related Reports
Relates :  
JDK-8287052 - comparing double to max_intx gives unexpected results
Relates :  
JDK-8258010 - Debug build failure with clang-10 due to -Wdeprecated-copy
Description
After suppressing the Wdeprecated-copy warining, another error occurs.

* For target hotspot_variant-server_libjvm_objs_threadHeapSampler.o:
/home/haosun01/tmp/build-err/jdk_src/src/hotspot/share/runtime/threadHeapSampler.cpp:397:33: error: implicit conversion from 'unsigned long' to 'double' changes value from 18446744073709551615 to 18446744073709551616 [-Werror,-Wimplicit-int-float-conversion]
  assert(result > 0 && result < SIZE_MAX, "Result is not in an acceptable range.");
                              ~ ^~~~~~~~
/usr/include/stdint.h:227:22: note: expanded from macro 'SIZE_MAX'
# define SIZE_MAX (18446744073709551615UL)
                                 ^~~~~~~~~~~~~~~~~~~~~~
 

-Wimplicit-int-float-conversion was first introduced in clang 10.
Comments
[~haosun], I agree.
23-05-2022
Hi [~dlong], I agree with your point. 1. the program behavior is not changed after my patch. As you said, this patch simply muted the compilation warnings, but didn't fix the potential safety issue. 2. As you said, it's unsafe to use `(double) SIZE_MAX`. Function pick_next_geometric_sample() is designed to get `interval` in range (0, SIZE_MAX). But it returns (0, SIZE_MAX] finally due to the unsafe cast of SIZE_MAX to `double` type. After reading the related code, I think we probably needn't fix this. Here is my findings. 1. The possible range of `result`: As commented at L376, variable `q` is in range of [1, 2**26]. Then, variable `log_val` falls in range of [-26, 0]. And variable `result` can be 0, or "26*log(2.0)*get_sampling_interval() + 1" As function get_sampling_interval() returns an integer value, hence we can say `results` falls in range of [- 26*log(2.0)*INT32_MAX+1, 26*log(2.0)*INT32_MAX+1]. Since `result > 0' is checked, we only care about the check for the maximum value of `result`, i.e. result < (double) SIZE_MAX. Note that I think `results` cannot be NaN and INF. 2. On 32-bit platforms, it's not an issue, as UINT32_MAX can be represented by `double` type in an accurate way. 3. On 64-bit platforms, I think the possible maximum value of `result`, i.e. 26*log(2.0)*INT32_MAX+1, is much less than (double)UINT64_MAX, and the check still works. Hence, in my opinion we may needn't fix it. May I have your opinion here? Thanks in advance.
23-05-2022
Thanks for pointing it out. I will fix it soon.
20-05-2022
An explicit cast may not be the correct fix here. See JDK-8287052 for a similar issue.
19-05-2022
Changeset: 28c35aed Author: Hao Sun <haosun@openjdk.org> Committer: David Holmes <dholmes@openjdk.org> Date: 2021-04-22 04:41:52 +0000 URL: https://git.openjdk.java.net/jdk/commit/28c35aed
22-04-2021