8253375: OSX build fails with Xcode 12.0 (12A7209) #348
Conversation
|
👋 Welcome back phh! A progress list of the required criteria for merging this PR into |
|
@phohensee This issue is referenced in the PR title - it will now be updated. |
|
@phohensee Setting summary to |
|
@phohensee The following labels will be automatically applied to this pull request: When this pull request is ready to be reviewed, an RFR email will be sent to the corresponding mailing lists. If you would like to change these labels, use the |
openjdk
bot
added
hotspot
|
/cc build |
|
@phohensee |
|
@phohensee The |
|
@phohensee |
Webrevs
|
|
@phohensee This change now passes all automated pre-integration checks. ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for more details. After integration, the commit message for the final commit will be: You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed. At the time when this comment was updated there had been 12 new commits pushed to the
As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details. ➡️ To integrate this PR with the above commit message to the |
| @@ -2848,7 +2848,7 @@ void AdapterHandlerLibrary::create_native_wrapper(const methodHandle& method) { | |||
| BufferBlob* buf = buffer_blob(); // the temporary code buffer in CodeCache | |||
| if (buf != NULL) { | |||
| CodeBuffer buffer(buf); | |||
| double locs_buf[20]; | |||
| short locs_buf[80]; | |||
There was a problem hiding this comment.
This code is just weird. Why is the locs_buf array not declared to be the desired type? If the compiler rejects double because it isn't relocInfo* then why does it accept short? And if it accepts short will it accept int or long long or int64_t? Using int64_t would be a clearer change. Though semantically this code is awful. :( Should it be intptr_t ?
There was a problem hiding this comment.
Currently we have in the existing code various kind of buffers passed into initialize_shared_locs that compile nicely on all supported compilers and on Xcode 12 as well ,see
c1_Compilation.cpp
326 char* locs_buffer = NEW_RESOURCE_ARRAY(char, locs_buffer_size);
327 code->insts()->initialize_shared_locs((relocInfo*)locs_buffer,
sharedRuntime.cpp
2681 CodeBuffer buffer(buf);
2682 short buffer_locs[20];
2683 buffer.insts()->initialize_shared_locs((relocInfo*)buffer_locs,
2684 sizeof(buffer_locs)/sizeof(relocInfo));
So probably using short would be consistent to what we do already in the coding at another place (looking into relocInfo it would be probably better to use unsigned short or to typedef unsigned short in the relocInfo class and use the typedef).
There was a problem hiding this comment.
No, don't do this. In the original, double is used to obtain the desired
alignmnent. Changing the element type to short reduces the alignment
requirement for the variable. initialize_shared_locs will then adjust the
alignment, potentially shrinking the effective array size. So this is a
real change that I think shouldn't be made.
I think changing the declaration for locs_buf to any of the following gives
equivalent behavior to the current code. I don't know whether any of them
will trigger the new clang warning though. I don't have access to that
version right now, and the documentation for the warning is useless (like so
much of clang's warning options documentation).
(1) alignas(double) char locs_buf[20 * sizeof(double)];
(but alignas is not yet in the "permitted features" list in the Style Guide:
https://bugs.openjdk.java.net/browse/JDK-8252584)
(2) union { char locs_buf[20 * sizeof(double)]; double align; };
(3) std::aligned_storage_t<20 * sizeof(double)> locs_buf;
and change (relocInfo*)locs_buf => (relocInfo*)&locs_buf
and #include <type_traits>
This has the benefit of being explicit that we're just stack allocating a
block of storage.
I'll make a wild guess that (1) and (2) will still warn, though char arrays
are somewhat special in the language so maybe they won't. I'm pretty sure
(3) should do the trick.
| @@ -126,7 +126,7 @@ + (void)reloadColors { | |||
| + (NSColor*)getColor:(NSUInteger)colorIndex useAppleColor:(BOOL)useAppleColor { | |||
| NSColor* result = nil; | |||
|
|
|||
| if (colorIndex < (useAppleColor) ? sun_lwawt_macosx_LWCToolkit_NUM_APPLE_COLORS : java_awt_SystemColor_NUM_COLORS) { | |||
| if (colorIndex < ((useAppleColor) ? sun_lwawt_macosx_LWCToolkit_NUM_APPLE_COLORS : java_awt_SystemColor_NUM_COLORS)) { | |||
There was a problem hiding this comment.
This looks like a plain old bug fix, nothing really to do with the compiler upgrade. The new compiler presumably just has a new warning that brought attention to the problem. As such, I don't think it belongs in a PR that's about issues related to the compiler upgrade. Someone might want to backport just this fix, for example.
There was a problem hiding this comment.
Hello Kim, Paul - so should we open a separate bug for the src/java.desktop/macosx/native/libawt_lwawt/awt/CSystemColors.m issue because it might be a general problem just uncovered by the new compiler ?
Paul , do you want to do this ? Or should I open a bug and post a separate change for the useAppleColor check in CSystemColors.m ?
There was a problem hiding this comment.
I created
https://bugs.openjdk.java.net/browse/JDK-8253791
8253791: Issue with useAppleColor check in CSystemColors.m
for this issue (Kim and Paul are fine to have a separate JBS issue for this)
|
Mailing list message from Kim Barrett on awt-dev:
[I tried submitting this comment through the github UI and somehow managed to lose |
|
Mailing list message from Kim Barrett on awt-dev:
Another variant that probably avoids both the warning and avoids any C++14 features: (4) union { char data[20 * sizeof(double)]; double align; } locs_buf; |
|
I checked Kim Barrett's proposals (1) and (2) on my machine (MacOS 10.15, Xcode 12.0). Both proposals make the warning go away. Another note, actually, it's more like a question: |
|
Mailing list message from Kim Barrett on 2d-dev:
It?s ?odd? but I think it?s more or less okay. Here and in other uses we seem to be allocating |
|
Mailing list message from Kim Barrett on 2d-dev:
I think so. |
|
Mailing list message from Kim Barrett on 2d-dev:
That?s *not* consistent, because of buffer alignment. The call to NEW_RESOURCE_ARRAY is going Since initialize_shared_locs specifically adjusts the alignment, some downstream use of the buffer |
There was a problem hiding this comment.
The proposed (updated) change does NOT compile on my machine (MacOS 10.15.6, Xcode 12.0):
sharedRuntime.cpp:2860:46: error: cannot cast from type 'struct (anonymous struct at sharedRuntime.cpp:2859:7)' to pointer type 'relocInfo *'
You will have to use a union (option (2) as proposed by Kim Barrett far above. I proved that variant compiles on my machine.
|
Mailing list message from Kim Barrett on 2d-dev:
Did you use the change from the PR, or apply it manually. That looks like the error one would get if |
|
/integrate |
openjdk
bot
added
integrated
|
@phohensee Since your change was applied there have been 17 commits pushed to the
Your commit was automatically rebased without conflicts. Pushed as commit f80a606. 💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored. |
Please review this small patch to enable the OSX build using Xcode 12.0.
Thanks,
Paul
/issue add JDK-8253375
/summary Replace double array with short array in AdapterHandlerLibrary::create_native_wrapper, add parens around ?: in CSystemColors:getColor
Progress
Issue
Reviewers
Download
$ git fetch https://git.openjdk.java.net/jdk pull/348/head:pull/348$ git checkout pull/348