-
Notifications
You must be signed in to change notification settings - Fork 149
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
8329826: GCC 12 reports some compiler error when building jdk8 #479
Conversation
Hi @kuenking, welcome to this OpenJDK project and thanks for contributing! We do not recognize you as Contributor and need to ensure you have signed the Oracle Contributor Agreement (OCA). If you have not signed the OCA, please follow the instructions. Please fill in your GitHub username in the "Username" field of the application. Once you have signed the OCA, please let us know by writing If you already are an OpenJDK Author, Committer or Reviewer, please click here to open a new issue so that we can record that fact. Please use "Add GitHub user kuenking" as summary for the issue. If you are contributing this work on behalf of your employer and your employer has signed the OCA, please let us know by writing |
❗ This change is not yet ready to be integrated. |
5e4af7d
to
a3b10aa
Compare
@kuenking Please do not rebase or force-push to an active PR as it invalidates existing review comments. Note for future reference, the bots always squash all changes into a single commit automatically as part of the integration. See OpenJDK Developers’ Guide for more information. |
Webrevs
|
The I have not seen other failures. Are they specific to certain architectures? We should not be introducing changes uniquely to 8u unless it is really necessary, so we need to look at this code in later JDKs. |
Thank you very much for your code review and also suggest.
Even though I modified gcc.make to fix the '-Werror=stringop-overflow=' problem. I also get the following error :
About I'll test it on x86 architecture, and I'll report back with the results. |
@@ -212,7 +212,7 @@ ifeq ($(USE_CLANG), true) | |||
WARNINGS_ARE_ERRORS += -Wno-return-type -Wno-empty-body | |||
endif | |||
|
|||
WARNING_FLAGS = -Wpointer-arith -Wsign-compare -Wundef -Wunused-function -Wunused-value -Wformat=2 -Wreturn-type | |||
WARNING_FLAGS = -Wpointer-arith -Wsign-compare -Wundef -Wunused-function -Wunused-value -Wformat=2 -Wreturn-type -Wno-stringop-overflow |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
disabling the warning instead of fixing the code is not the proper way to deal with this
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for your code review.
The same solution is used in later JDK versions. https://bugs.openjdk.org/browse/JDK-8320212 ;
So JDK8 can also use this solution.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, rather the other way round: please fix that in later JDK versions as well.
I’m only the Debian packager for JDK 8, so I have no relationship to the other versions. This doesn’t make my critique invalid.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks. Ok, I'll try to fix it forward through the code;
Since I'm not sure how many errors there are yet, this may take a while. I'll try;
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi mirabilos,
I looked up some information; reference: https://gcc.gnu.org/bugzilla/show_bug.cgi? ID=106297. I also found that the gcc12 in my test environment was not a pure version but a version after secondary development, which affected the misjudgment of the jdk8 compilation error.
I built and tested using https://ftp.gnu.org/gnu/gcc/. The -Werror=stringop-overflow= error does not exist, and hotspot/src/share/vm/gc_implementation/g1/concurrentMark.cpp does not need to be modified.
The verification is as follows:
Therefore, I think the changes in gcc.make and concurrentMark.cpp should be removed.
thanks;
@@ -66,7 +66,7 @@ CXXFLAGS += -DASSERT | |||
|
|||
# CFLAGS_WARN holds compiler options to suppress/enable warnings. | |||
# Compiler warnings are treated as errors | |||
CFLAGS_WARN = $(WARNINGS_ARE_ERRORS) | |||
CFLAGS_WARN = $(WARNINGS_ARE_ERRORS) -Wno-register |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
that’s probably okay to ignore
if (o != NULL) { | ||
ciInstanceKlass* k = o->as_instance()->java_lang_Class_klass()->as_instance_klass(); | ||
field = k->get_field_by_offset(_offset, true); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is useless papering over, not a fix, and not even good because it makes the code less legible at no gain.
Better to convert the two assert
s to actual checks which abort the control flow of the function if triggered.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(disclaimer: I am not a reviewer)
This proposed change doesn't really handle the case where o == NULL, although it makes the compiler happy. I propose something like:
assert(o != NULL, "must be constant");
if (o != NULL) {
ciInstanceKlass* k = o->as_instance()->java_lang_Class_klass()->as_instance_klass();
ciField* field = k->get_field_by_offset(_offset, true);
assert(field != NULL, "missing field");
BasicType basic_elem_type = field->layout_type();
_is_ptr_to_narrowoop = UseCompressedOops && (basic_elem_type == T_OBJECT ||
basic_elem_type == T_ARRAY);
} else {
_is_ptr_to_narrowoop = (?? I am not familiar enough with this code to put a suggestion here)
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, don’t assert
and if
something. (The compiler may delete one of these two under Undefined Behaviour rules.)
I’ve not looked at the callers, but returning an error or throwing an exception if o == NULL
would be best. Do not rely on assert
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a good suggestion, I will try to fix it, refer to https://github.com/openjdk/jdk/blob/ad78b7fa67ba30cab2e8f496e4c765be15deeca6/src/hotspot/share/opto/type.cpp#L3560C3-L3572
thanks.
Mailing list message from Simon Tooke on jdk8u-dev: mirabilos, we cannot see your comments until you either sign the OCA or On 4/16/24 10:38 AM, mirabilos wrote: |
Mailing list message from Thorsten Glaser on jdk8u-dev: On Tue, 7 May 2024, Simon Tooke wrote:
Huh? Okay, I?ll have to find out what that is then?
Funny: all posts on this mailing list regarding code issues have bye, |
Mailing list message from Simon Tooke on jdk8u-dev: On 4/15/24 9:38 PM, Kun Wang wrote:
The issue in? hotspot/src/share/vm/opto/type.cpp:2556 (potential NULL I have see some other issues for GCC 14 (and the latest clang/Xcode), -- |
0cab9c8
to
0d98297
Compare
@kuenking Please do not rebase or force-push to an active PR as it invalidates existing review comments. Note for future reference, the bots always squash all changes into a single commit automatically as part of the integration. See OpenJDK Developers’ Guide for more information. |
@kuenking This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration! |
@kuenking This pull request has been inactive for more than 8 weeks and will now be automatically closed. If you would like to continue working on this pull request in the future, feel free to reopen it! This can be done using the |
Env:
ldd (GNU libc) 2.38
gcc (GCC) 12.3.1
Test the PR patch;
Build release/fastdebug/slowdebug version pass
Reported issue : https://bugs.openjdk.org/browse/JDK-8329826
Progress
Issue
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk8u-dev.git pull/479/head:pull/479
$ git checkout pull/479
Update a local copy of the PR:
$ git checkout pull/479
$ git pull https://git.openjdk.org/jdk8u-dev.git pull/479/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 479
View PR using the GUI difftool:
$ git pr show -t 479
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk8u-dev/pull/479.diff
Webrev
Link to Webrev Comment