eclipse / omr

Eclipse OMR™ Cross platform components for building reliable, high performance language runtimes
http://www.eclipse.org/omr
Other
933 stars 392 forks source link

Supported C++ features document is out of date #7359

Open ThanHenderson opened 3 weeks ago

ThanHenderson commented 3 weeks ago

The document here: https://github.com/eclipse/omr/blob/master/doc/SupportedC%2B%2BFeatures.md outlines the minimum-supported C++ compiler versions and thus the available C++ features. However, this document appears to be out of date.

e.g. an excerpt from the extension repo building instructions states:

gcc

The minimum accepted version of gcc is 5.0. Older versions will generate a warning by configure and are unlikely to work.

The JDK is currently known to be able to compile with at least version 11.2 of gcc.

In general, any version between these two should be usable.

but the document talks about 4.4.7 being the minimum supported GCC version, suggesting there is a divergence between the documented supported features and the actual. e.g. an rg nullptr reveals nullptr being used a few times in the codebase, but this list suggests that it is unsupported.

We should audit and update this document to get a better idea of which features we can use.

ThanHenderson commented 3 weeks ago

Info from extension repos: JDK8: https://github.com/ibmruntimes/openj9-openjdk-jdk8/blob/c1470c8cffd73bfdd07ff63c25ff71da14cbb54f/common/autoconf/flags.m4#L528 (at least minimum of 6 for GCC)

JDK11: https://github.com/ibmruntimes/openj9-openjdk-jdk11/blob/839808e0d9f5c314f56d26ab57a0b0ac618c0e22/make/autoconf/toolchain.m4#L54-L59

JDK17: https://github.com/ibmruntimes/openj9-openjdk-jdk17/blob/7dfa0915ce2887d4dadc5d7d22e836edd5935c5a/make/autoconf/toolchain.m4#L52-L56

JDK21: https://github.com/ibmruntimes/openj9-openjdk-jdk21/blob/cbd5117c34619bfb4b5e6cf11815a118df44bc9a/make/autoconf/toolchain.m4#L52-L56

Potentially other relevant info: https://github.com/eclipse-openj9/openj9/blob/master/doc/release-notes/0.43/0.43.md

ThanHenderson commented 3 weeks ago

Conversations internally about AIX is that the xlC support is for v13 and up (13, 16, & 17), and V2R3 for z/OS.

ThanHenderson commented 2 weeks ago

@pshipton Are gcc 10.3 for Linux and VS 2022 for Windows the appropriate versions here? From the 0.43 release notes: linux windows

Do you know of any consumers of OMR that are relying on older versions?

pshipton commented 2 weeks ago

The z/OS compile machines for IBM Java 8 are 2.1 Agreed AIX is min xlC v13 (IBM Java 8). We also compile on PPC BE which is also v13. It's being retired hopefully but it's not retired yet. PPC LE just uses gcc now, not xlC. Mac is missing from the list, the OpenJ9 compilers are listed in https://eclipse-openj9.github.io/openj9-docs/openj9_support/ The minimum gcc used for OpenJ9 is 10.3 and the minimum VS used is 2022. That doesn't mean older versions won't work, but we don't test them. Perhaps older version are fine since xlC 13 limits what can be used.

Where did you get the "excerpt from the OpenJ9 building instructions"?

I don't know about other consumers of OMR. @0xdaryl @mstoodle may know.

ThanHenderson commented 2 weeks ago

Thanks for the clarification, Peter. It'll help me determine which features we could safely use.

The excerpt was from the extension repos, not OpenJ9s instructions.

0xdaryl commented 2 weeks ago

I agree the document should be kept up to date, and thank you @ThanHenderson for looking at that.

While I am generally in favour of continuously raising the bar to allow more C++ features to be used, I think we need to be a bit more gradual about it (e.g., a jump from gcc 4.4.7 to 10.3 is pretty big in one go so perhaps we find something in between). Also remember that Eclipse OMR is an independent project from Eclipse OpenJ9, and while OpenJ9 is an important consumer, the OMR project can't base all its decisions on OpenJ9's requirements.

Moving up the compiler level is the kind of thing that should be announced to the community for awareness. I think the OMR release boundaries are appropriate for these kinds of changes (we have the 0.2.0 release planned for end of June, and every 3 months thereafter). If you have a compiler level proposal in between 4.4.7 and 10.3 for end of June please share for consideration.

To address your question, at one point a couple of years ago I am aware there was a project exploring the use of OMR that required an older gcc version (because their build infrastructure was unable to move up right away). That may no longer be a requirement for them and enough time has passed that OMR could make the case to gradually increase its minimum supported compiler level. Perhaps @mstoodle can weigh in on whether this is still a requirement.

mstoodle commented 2 weeks ago

at one point a couple of years ago I am aware there was a project exploring the use of OMR that required an older gcc version (because their build infrastructure was unable to move up right away). That may no longer be a requirement for them and enough time has passed that OMR could make the case to gradually increase its minimum supported compiler level. Perhaps @mstoodle can weigh in on whether this is still a requirement.

I know the project you're referring to: it's not a requirement any more. I think it more comes down to consistent availability of features across the full set of platforms we and our stakeholders need to support. Otherwise, I'm happy for the bar to move up.

ThanHenderson commented 2 weeks ago

I think a safe bet for the gcc version is 7.3 since that is the version that released with the spectre mitigation patch. And talking to the IBM SDK release team in India, 7.3 is what the JDK8 release still uses.

From a C++ feature standpoint, gcc was C++11 complete by release 4.8, so any release after that is not C++11 feature limiting for platforms compiling with gcc. It will be the other platforms which dictate the supported features, for which I've obtained the following minimum versions:

Edit: clarity, these are the compiler versions used for compiling the JCL only, so I guess they don't affect our code (OpenJ9 nor OMR). But my first sentence of this comment still applies.

pshipton commented 2 weeks ago

And talking to the IBM SDK release team in India, 7.3 is what the JDK8 release still uses.

Just FYI, the OpenJ9 part of the IBM SDK uses 11.2, it's only other components that may still be using 7.3.

ThanHenderson commented 2 weeks ago

I propose bumping the documentation and development to: