JDK-8253375 : OSX build fails with Xcode 12.0 (12A7209)
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 11,15,16
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2020-09-18
  • Updated: 2022-01-05
  • Resolved: 2020-09-30
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 11 JDK 13 JDK 15 JDK 16 Other
11.0.10-oracleFixed 13.0.6Fixed 15.0.2Fixed 16 b18Fixed openjdk8u302Fixed
Related Reports
Duplicate :  
JDK-8253302 - hotspot build warning in src/hotspot/share/runtime/sharedRuntime.cpp with clang version 12.0.0
Relates :  
JDK-8253868 - CodeSection::initialize_shared_locs buffer argument types and sizes are opaque
Description
Attempting to compile src/hotspot/share/runtime/sharedRuntime.cpp with Xcode 12.0 for a slowdebug build produces

/Users/hohensee/workspaces/jdk/src/hotspot/share/runtime/sharedRuntime.cpp:2849:85: error: expression does not compute the number of elements in this array; element type is 'double', not 'relocInfo' [-Werror,-Wsizeof-array-div]
      buffer.insts()->initialize_shared_locs((relocInfo*)locs_buf, sizeof(locs_buf) / sizeof(relocInfo));
                                                                          ~~~~~~~~  ^
/Users/hohensee/workspaces/jdk/src/hotspot/share/runtime/sharedRuntime.cpp:2848:14: note: array 'locs_buf' declared here
      double locs_buf[20];
             ^
/Users/hohensee/workspaces/jdk/src/hotspot/share/runtime/sharedRuntime.cpp:2849:85: note: place parentheses around the 'sizeof(relocInfo)' expression to silence this warning
      buffer.insts()->initialize_shared_locs((relocInfo*)locs_buf, sizeof(locs_buf) / sizeof(relocInfo));
                                                                                    ^
1 error generated.

Correct code to do the same thing exists in src/hotspot/share/c1/c1_Compilation.cpp at line 325, vis

  int locs_buffer_size = 20 * (relocInfo::length_limit + sizeof(relocInfo));
  char* locs_buffer = NEW_RESOURCE_ARRAY(char, locs_buffer_size);
  code->insts()->initialize_shared_locs((relocInfo*)locs_buffer,
                                        locs_buffer_size / sizeof(relocInfo));

A quick fix would be just to copy it into sharedRuntime.cpp, but a better one would define a macro in relocInfo.hpp for use in such circumstances, e.g.

#define RELOCINFO_BUFFER_SIZE (20 * (relocInfo::length_limit + sizeof(relocInfo)))
Comments
The summary is incorrect, and somehow all but one of us failed to notice, including of course me!. I've removed the "parens" part from the 8u summary.
17-05-2021
Approving for 8u, but this part of the summary seems odd: ", add parens around ?: in CSystemColors:getColor" There is no such change in the patch. Can this be removed for the 8u version?
17-05-2021
Still your request only makes sense after xcode12 support will be added to openjdk8u. Right now it sounds like - this change will improve support of build system which is not supported ( by 8) anyway. We at Azul build macos-aarch jdk8 with xcode12 ( and intelmac with xcode9, as building it with 4.6.x became problematic) as well, but not bringing every other xcode12 patch to upstream as it may break jdk8 for others. ( pbuffers removal for example). So maybe it's better (for other vendors) to keep this patch at amazon's repo until xcode12 (if ever) support for jdk8u is added or just change justification and let us know how have you tested it against xcode4.x as well. Regards.
28-04-2021
There are multiple requests to make 8u buildable on OSX 10.15+/Xcode 12. See the threads https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-March/013480.html https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-March/013546.html We at Amazon have been building 8u with Xcode 12 for some months, and this issue is on our backport list.
28-04-2021
Hello Excuse me, but what's the point of backporting this to openjdk8u sicne it's not supporting xcode 5+ anyway ? There is no way to test this won't break anything for openjdk8u/other downstream vendors. We had few changes in the past which broke macos/openjdk8u/xcode4.X, why would you want to risk once again ? this fix looks safe enough tho.
28-04-2021
Fix Request (8u). Fixes a build problem with Xcode 12. No risk, syntax-only change, applies cleanly.
28-04-2021
Fix Request (15u). Fixes a build problem with Xcode 12. No risk, syntax-only change, applies cleanly.
05-11-2020
Fix Request (13u) Fixes a build problem with Xcode 12. No risk, syntax-only change, applies almost cleanly, issues with jdk16's patch due to context after the patched code. jdk11's fix applies cleanly
29-10-2020
Fix Request (11u). Fixes a build problem with Xcode 12. No risk, syntax-only change, applies cleanly.
30-09-2020
Changeset: f80a6066 Author: Paul Hohensee <phh@openjdk.org> Date: 2020-09-30 12:16:25 +0000 URL: https://git.openjdk.java.net/jdk/commit/f80a6066
30-09-2020
ILW = MLM = P4
22-09-2020
This was filed yesterday as JDK-8253302. One of them should be closed as a duplicate.
19-09-2020