JDK-8308288: Fix xlc17 clang warnings in shared code #14146

JoKern65 · 2023-05-25T09:14:14Z

When using the new xlc17 compiler (based on a recent clang) to build OpenJDk on AIX , we run into various "warnings as errors".
Some of those are in shared codebase and could be addressed by small adjustments.
A lot of those changes are in hotspot, some might be somewhere else in the OpenJDK C/C++ code.

Progress

Change must be properly reviewed (1 review required, with at least 1 Reviewer)
Change must not contain extraneous whitespace
Commit message must refer to an issue

Issue

JDK-8308288: Fix xlc17 clang warnings in shared code

Reviewers

Phil Race (@prrace - Reviewer)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/14146/head:pull/14146
$ git checkout pull/14146

Update a local copy of the PR:
$ git checkout pull/14146
$ git pull https://git.openjdk.org/jdk.git pull/14146/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 14146

View PR using the GUI difftool:
$ git pr show -t 14146

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/14146.diff

Webrev

Link to Webrev Comment

bridgekeeper · 2023-05-25T09:15:44Z

👋 Welcome back JoKern65! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

openjdk · 2023-05-25T09:18:18Z

@JoKern65 The following labels will be automatically applied to this pull request:

build
client
core-libs
hotspot
serviceability

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 /label pull request command.

mlbridge · 2023-05-25T09:28:21Z

Webrevs

01: Full - Incremental (da38fb2d)
00: Full (2699fdce)

MBaesken · 2023-05-25T12:55:33Z

In the macro define checks, you both check macros _AIX and AIX, sometimes this, sometimes that. Might be possible to just use one of the two for consistency, but I am fine with using both as well, leave this up to you.

kimbarrett

Sorry, but I can't review the warning suppressions. Without more information
about exactly what warnings are being suppressed and where, I have no way to
evaluate whether suppression is an appropriate response. It could be that some
of the warnings are correctly pointing out (possibly serious) flaws that
really need to be fixed. Continuing to hide them doesn't seem like a winning
strategy to me.

I also suggest avoiding omnibus changes like this when possible (which it is
here). Just because it's all about removing warnings from a new toolchain
doesn't make it a cohesive change. That makes it harder to review and to
manage the review, because it is larger and affects a wide range of areas, so
may need many reviewers. And the whole thing might get stalled by discussion
of one piece.

kimbarrett · 2023-05-25T14:40:19Z

make/modules/java.desktop/lib/Awt2dLibraries.gmk

@@ -692,6 +701,15 @@ ifeq ($(ENABLE_HEADLESS_ONLY), false)
      LIBSPLASHSCREEN_CFLAGS += -DPNG_POWERPC_VSX_OPT=0
    endif
  endif
+  # temporarily disable PNG_POWERPC_VSX_OPT which would be set, because
+  # if defined(__PPC64__) && defined(__ALTIVEC__) && defined(__VSX__)
+  # is true, the then needed libpng function .png_init_filter_functions_vsx


kimbarrett · 2023-05-25T15:04:32Z

src/hotspot/share/utilities/globalDefinitions_xlc.hpp

+    && defined(__open_xl_version__) && __open_xl_version__ >= 17
+  #undef malloc
+  extern void *malloc(size_t) asm("vec_malloc");
+#endif


Wow! And I don't mean that in a good way. I'm not questioning whether this is correct, just commenting
on how crazy it seems that such a thing might be needed.

The crazy thing is that malloc is defined! That means all places where we use the term malloc are getting replaced without such a workaround. (E.g. for log tags.)

So, we do this only for malloc? Not for calloc, posix_memalign, realloc etc? What about free?

As ugly as defining malloc is (and I remember QADRT), I hesitate about removing that define.

Removing that define and hard-coding it here assumes 1) our replacement is equivalent (ok, easy to check) 2) it will always be equivalent in future AIX versions 3) pointers it returns work with the unchanged free() and realloc() the system provides, and will always do so.

I don't know... I would not do this just to get rid of a warning.

This one is not just to get rid of a warning. We get real test errors because malloc gets replaced by vec_malloc in log tags.

This one is not just to get rid of a warning. We get real test errors because malloc gets replaced by vec_malloc in log tags.

That does not invalidate my argument, nor does it answer my question. Those test errors could be also fixed by renaming the log tag. Maybe that would be the better way.

Also, I'm curious, why does it not complain about "free", which is a logtag as well?

I am basically worried that undefining malloc, even if it seems harmless now, exposes us to difficult-to-investigate problems down the road, since it depends on how the libc devs will reform those macros in the future. I would prefer a simple solution that does not depend on how the libc includes evolve.

Is it possible to see the stdlib.h source code that is being a problem? Maybe more eyes can come up
with a better solution, or at least come to a better understanding of why we have to go this way.

Technically it's our fault. The standard library is permitted to provide a
macro replacements for (nearly?) any function. (C99 7.1.3/1 3rd bullet) But
it's really annoying. Presumably AIX is only doing so for a subset of the
allocation functions, e.g. not "free" for example.

Having "malloc" defined as a macro seems like it should raise all kinds of
havoc, not just around log tags. Consider our "os::malloc" function? The
preprocessor knows nothing about C++ namespace qualifiers.

kimbarrett · 2023-05-25T15:18:41Z

test/jdk/java/io/File/libGetXSpace.c

@@ -125,7 +125,7 @@ Java_GetXSpace_getSpace0
    }
 #else
    struct statfs buf;
-    int result = statfs((const char*)chars, &buf);
+    int result = statfs((char*)chars, &buf);


Is this working around a bug in IBM's declaration?

Also, pre-existing, the cast seems really suspicious. The type of chars is jchar*, which is a
sequence of 16bit characters. Does this actually work? If so, how?

This is IBMs declaration of statfs
extern int statfs(char *, struct statfs *);
So the compiler will not accept a const char*
Indeed I do not know if this ever worked, but my change makes it not worse.

Here is the documentation of statfs on AIX https://www.ibm.com/docs/en/aix/7.2?topic=s-statfs-fstatfs-statfs64-fstatfs64-ustat-subroutine (showing the IBM declaration Joachim told us) .

Also, pre-existing, the cast seems really suspicious. The type of chars is jchar*, which is a sequence of 16bit characters. Does this actually work? If so, how?

Probably a jchar to char conversion would be needed for the array elements, maybe like this here (or is there a better utility function in the codebase) ? See jCharArrayToCKCharArray

jdk/src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c

Line 644 in 199b1bf

void jCharArrayToCKCharArray(JNIEnv *env, const jcharArray jArray, CK_CHAR_PTR *ckpArray, CK_ULONG_PTR ckpLength)

I am not aware of an AIX statfs for wchars but maybe I miss something. But it is a separate issue of Java_GetXSpace_getSpace0 anyway and should be handled in another bug.

JoKern65 · 2023-05-26T10:05:56Z

Here are the reasons for the disabled warnings in make/modules/java.base/Lib.gmk
DISABLED_WARNINGS_clang_aix_DefaultProxySelector.c := deprecated-non-prototype,
DISABLED_WARNINGS_clang_aix_NetworkInterface.c := gnu-pointer-arith,
DISABLED_WARNINGS_clang_aix_UnixNativeDispatcher.c := undef, \

src/java.base/unix/native/libnet/DefaultProxySelector.c:378:41:22: error: passing arguments to a function without a prototype is deprecated in all versions of C and is not supported in C2x [-Werror,-Wdeprecated-non-prototype]
proxies = (*g_proxy_resolver_lookup)(resolver, uri, NULL, &error);
^

src/java.base/unix/native/libnet/NetworkInterface.c:1612:24: error: arithmetic on a pointer to void is a GNU extension [-Werror,-Wgnu-pointer-arith]
end = (void *)nddp + size;
~~~~~~~~~~~~ ^

src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c:1251:7: error: '_ALLBSD_SOURCE' is not defined, evaluates to 0 [-Werror,-Wundef]
#elif _ALLBSD_SOURCE
^

JoKern65 · 2023-05-26T10:18:37Z

Here are the reasons for the disabled warnings in make/modules/java.base/lib/CoreLibraries.gmk
DISABLED_WARNINGS_clang_aix_ProcessHandleImpl_unix.c := sign-compare,
DISABLED_WARNINGS_clang_aix := gnu-pointer-arith,
DISABLED_WARNINGS_clang := gnu-pointer-arith format-nonliteral deprecated-non-prototype, \

src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:638 comparison of integers of different signs: 'int' and 'unsigned long'
if (ret < sizeof(psinfo_t)) {
^

src/java.base/aix/native/libjli/java_md_aix.c:42:38: error: arithmetic on a pointer to void is a GNU extension [-Werror,-Wgnu-pointer-arith]
addr < p->ldinfo_textorg + p->ldinfo_textsize) {
~~~~~~~~~~~~~~~~~ ^

src/java.base/share/native/libzip/zlib/inffast.c:74:20: error: a function definition without a prototype is deprecated in all versions of C and is not supported in C2x [-Werror,-Wdeprecated-non-prototype]
void ZLIB_INTERNAL inflate_fast(strm, start)
^
src/java.base/share/native/libjli/java.c:2311:22: error: format string is not a string literal [-Werror,-Wformat-nonliteral]
vfprintf(stderr, fmt, vl);
^~~

MBaesken · 2023-05-26T10:21:56Z

src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c:1251:7: error: '_ALLBSD_SOURCE' is not defined, evaluates to 0 [-Werror,-Wundef]
#elif _ALLBSD_SOURCE

Should probably better be
#elif defined(_ALLBSD_SOURCE)

MBaesken · 2023-05-26T10:43:29Z

src/java.base/share/native/libjli/java.c:2311:22: error: format string is not a string literal [-Werror,-Wformat-nonliteral] vfprintf(stderr, fmt, vl); ^~~

We disable this warning too for clang on all platforms in BUILD_LIBJLI ( DISABLED_WARNINGS_clang := format-nonliteral deprecated-non-prototype, \ ), so I think we should do it the same way for BUILD_LIBJLI_STATIC on AIX.

MBaesken · 2023-05-26T10:52:07Z

Here are the reasons for the disabled warnings in make/modules/java.base/lib/CoreLibraries.gmk DISABLED_WARNINGS_clang_aix_ProcessHandleImpl_unix.c := sign-compare, DISABLED_WARNINGS_clang_aix := gnu-pointer-arith, DISABLED_WARNINGS_clang := gnu-pointer-arith format-nonliteral deprecated-non-prototype, \

src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:638 comparison of integers of different signs: 'int' and 'unsigned long' if (ret < sizeof(psinfo_t)) { ^

fread returns a size_t on Linux and AIX, could you please check Mac/BSD too ?

jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c

Line 636 in d3b9b36

ret = fread(psinfo, 1, sizeof(psinfo_t), fp);

We should probably change to size_t ret (from type int), then the warning would not occur, correct ?

JoKern65 · 2023-05-26T12:15:05Z

Here are the reasons for the disabled warnings in make/modules/java.desktop/lib/Awt2dLibraries.gmk

src/java.desktop/unix/native/common/awt/awt_GraphicsEnv.h:53:12: error: a function declaration without a prototype is deprecated in all versions of C and is treated as a zero-parameter prototype in C2x, conflicting with a previous declaration [-Werror,-Wdeprecated-non-prototype]
extern int XShmQueryExtension();
^
/usr/include/X11/extensions/XShm.h:91:6: note: conflicting prototype is here
Bool XShmQueryExtension(
^
solved by adding line (generic, because several source files are involved)
DISABLED_WARNINGS_clang_aix := deprecated-non-prototype, \

src/java.desktop/unix/native/libawt_xawt/xawt/awt_Taskbar.c:158:11: error: using the result of an assignment as a condition without parentheses [-Werror,-Wparentheses]
if (m = fp_unity_launcher_entry_get_quicklist(entry)) {
~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
solved by adding line
DISABLED_WARNINGS_clang_aix_awt_Taskbar.c := parentheses, \

src/java.desktop/share/native/common/java2d/opengl/OGLPaints.c:581:48: error: format string is not a string literal [-Werror,-Wformat-nonliteral]
snprintf(cycleCode, sizeof(cycleCode), noCycleCode, texCoordCalcCode);
^~~~~~~~~~~
solved by adding line
DISABLED_WARNINGS_clang_aix_OGLPaints.c := format-nonliteral, \

src/java.desktop/share/native/common/java2d/opengl/OGLBufImgOps.c:153:48: error: format string is not a string literal [-Werror,-Wformat-nonliteral]
snprintf(finalSource, sizeof(finalSource), convolveShaderSource,
^~~~~~~~~~~~~~~~~~~~
solved by adding line
DISABLED_WARNINGS_clang_aix_OGLBufImgOps.c := format-nonliteral, \

src/java.desktop/unix/native/libawt_xawt/awt/gtk2_interface.c:1095:41: error: '&&' within '||' [-Werror,-Wlogical-op-parentheses]
if ((synth_state & MOUSE_OVER) != 0 && (synth_state & PRESSED) == 0 ||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~
src/java.desktop/unix/native/libawt_xawt/awt/gtk2_interface.c:1180:29: error: using the result of an assignment as a condition without parentheses [-Werror,-Wparentheses]
if (init_result = (NULL == gtk2_widgets[_GTK_CHECK_MENU_ITEM_TYPE]))
~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
solved by adding line
DISABLED_WARNINGS_clang_aix_gtk2_interface.c := parentheses logical-op-parentheses, \

src/java.desktop/unix/native/libawt_xawt/awt/gtk3_interface.c:903:29: error: using the result of an assignment as a condition without parentheses [-Werror,-Wparentheses]
if (init_result = (NULL == gtk3_widgets[_GTK_BUTTON_TYPE]))
~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
solved by adding line
DISABLED_WARNINGS_clang_aix_gtk3_interface.c := parentheses, \

src/java.desktop/unix/native/libawt_xawt/awt/sun_awt_X11_GtkFileDialogPeer.c:87:26: error: using the result of an assignment as a condition without parentheses [-Werror,-Wparentheses]
if (pendingException = (*env)->ExceptionOccurred(env)) {
~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
solved by adding line
DISABLED_WARNINGS_clang_aix_sun_awt_X11_GtkFileDialogPeer.c := parentheses, \

src/java.desktop/aix/native/libawt_xawt/awt/awt_InputMethod.c:1969:32: error: comparison of integers of different signs: 'Window' (aka 'unsigned long') and 'jlong' (aka 'long') [-Werror,-Wsign-compare]
if (currentFocusWindow != w) {
~~~~~~~~~~~~~~~~~~ ^ ~
solved by adding line
DISABLED_WARNINGS_clang_aix_awt_InputMethod.c := sign-compare, \

JoKern65 · 2023-05-26T12:16:29Z

Here is the reason for the disabled warning in make/modules/java.security.jgss/Lib.gmk

src/java.security.jgss/share/native/libj2gss/NativeUtil.h:30:
/data/d042520/pr/jdk/src/java.security.jgss/share/native/libj2gss/gssapi.h:48:5: error: 'TARGET_OS_MAC' is not defined, evaluates to 0 [-Werror,-Wundef]
#if TARGET_OS_MAC && (defined(ppc) || defined(ppc64) || defined(i386) || defined(x86_64))
^
make/modules/java.security.jgss/Lib.gmk add line
DISABLED_WARNINGS_clang_aix := undef, \

JoKern65 · 2023-05-26T12:17:27Z

Here is the reason for the disabled warning in make/modules/jdk.jdwp.agent/Lib.gmk

src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c:718:33: error: suggest braces around initialization of subobject [-Werror,-Wmissing-braces]
struct in6_addr mappedAny = IN6ADDR_ANY_INIT;
^~~~~~~~~~~~~~~~
/usr/include/netinet/in.h:454:32: note: expanded from macro 'IN6ADDR_ANY_INIT'
#define IN6ADDR_ANY_INIT {0, 0, 0, 0}
solved by adding line
DISABLED_WARNINGS_clang_aix := missing-braces, \

TheRealMDoerr · 2023-05-26T13:35:30Z

Just a side note: The warning elimination is new for AIX compilers. We had given it up at earlier times: https://bugs.openjdk.org/browse/JDK-8202325
I still appreciate if we can get warning free and it makes sense to review all of them. But, I wouldn't require it for JDK21.

coleenp · 2023-05-30T18:42:54Z

src/hotspot/share/runtime/javaThread.cpp

+#ifdef _AIX
+#include <alloca.h>
+#endif
+


Could these conditionals be included in globalDefinitions_xlc.hpp instead?

In principle the #include <alloca.h> could be included in globalDefinitions_xlc.hpp. But alloca.h implements it with a
#undef alloca
#define alloca(size) __builtin_alloca (size)
If this new global define does not introduce new trouble (even in future coding) when it is seen in every source, we can go this way.
Are there any obstacles from anyone else?

At least the whole jdk actually builds with #include <alloca.h> in globalDefinitions_xlc.hpp

prrace

I am Ok with the client-libs changes here. I did not look at anything else.
So you'll need more approvals before its ready to push.

openjdk · 2023-05-31T20:26:44Z

@JoKern65 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 details.

After integration, the commit message for the final commit will be:

8308288: Fix xlc17 clang warnings in shared code

Reviewed-by: prr

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 89 new commits pushed to the master branch:

8dbd384: 8308678: (fs) UnixPath::toRealPath needs additional permissions when running with SM (macOS)
c3cd481: 8304914: Use OperatingSystem, Architecture, and Version in jpackage
eae1f59: 8309159: Some minor comment and code cleanup in jdk/com/sun/jdi/PopFramesTest.java
45473ef: 8309230: ProblemList jdk/incubator/vector/Float64VectorTests.java on aarch64
78aa5f3: 8299505: findVirtual on array classes incorrectly restricts the receiver type
42ca6e6: 8308022: update for deprecated sprintf for java.base
1264902: 8308316: Default decomposition mode in Collator
70670b4: 8308872: enhance logging and some exception in krb5/Config.java
024d9b1: 8308910: Allow executeAndLog to accept running process
25b9803: 8308917: C2 SuperWord::output: assert before bailout with CountedLoopReserveKit
... and 79 more: https://git.openjdk.org/jdk/compare/4500bb7a676b9208337590880cfde45f264e4baf...master

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.

As you do not have Committer status in this project an existing Committer must agree to sponsor your change. Possible candidates are the reviewers of this PR (@kimbarrett, @prrace) but any other Committer may sponsor as well.

➡️ To flag this PR as ready for integration with the above commit message, type /integrate in a new comment. (Afterwards, your sponsor types /sponsor in a new comment to perform the integration).

JoKern65 · 2023-06-01T13:07:56Z

Hi,

As this PR is big and spans several components I split
off the java.base, java.desktop and the sercivability/security
issues into extra JBS issues.
https://bugs.openjdk.org/browse/JDK-8309219 Fix xlc17 clang 1.5 warnings in java.base
https://bugs.openjdk.org/browse/JDK-8309224 Fix xlc17 clang 1.5 warnings in java.desktop
https://bugs.openjdk.org/browse/JDK-8309225 Fix xlc17 clang 1.5 warnings in security and servicability
I’ll move the changes from this pull request into new pull requests.
I will incorporate the requested changes right in the new PRs.
I will reuse this issue 8308388 for the hotspot changes but come up
with a new, smaller PR.
@colleenp, I will move alloca.h to the globalDefinitions_xlc.hpp.
@prrace, I will come up with an identical PR for the client
files (java.desktop), but improve the comment as @kimbarrett proposed
@MBaesken, I will use AIX and take up some of the other fixes you proposed.

I guess we need to find a way to fix the issue with the malloc
in globalDefinitions_xlc.hpp in the upcoming PR for hotspot.

Thanks for your help so far!

JoKern65 · 2023-06-01T13:08:28Z

Hi,

As this PR is big and spans several components I split
off the java.base, java.desktop and the sercivability/security
issues into extra JBS issues.
https://bugs.openjdk.org/browse/JDK-8309219 Fix xlc17 clang 1.5 warnings in java.base
https://bugs.openjdk.org/browse/JDK-8309224 Fix xlc17 clang 1.5 warnings in java.desktop
https://bugs.openjdk.org/browse/JDK-8309225 Fix xlc17 clang 1.5 warnings in security and servicability
I’ll move the changes from this pull request into new pull requests.
I will incorporate the requested changes right in the new PRs.
I will reuse this issue 8308388 for the hotspot changes but come up
with a new, smaller PR.
@colleenp, I will move alloca.h to the globalDefinitions_xlc.hpp.
@prrace, I will come up with an identical PR for the client
files (java.desktop), but improve the comment as @kimbarrett proposed
@MBaesken, I will use AIX and take up some of the other fixes you proposed.

I guess we need to find a way to fix the issue with the malloc
in globalDefinitions_xlc.hpp in the upcoming PR for hotspot.

Thanks for your help so far!

JDK-8308288

9a18959

openjdk bot added serviceability serviceability-dev@openjdk.org hotspot hotspot-dev@openjdk.org build build-dev@openjdk.org client client-libs-dev@openjdk.org core-libs core-libs-dev@openjdk.org labels May 25, 2023

white space

2699fdc

openjdk bot added the rfr Pull request is ready for review label May 25, 2023

kimbarrett reviewed May 25, 2023

View reviewed changes

forgotton _

da38fb2

coleenp reviewed May 30, 2023

View reviewed changes

prrace approved these changes May 31, 2023

View reviewed changes

openjdk bot added the ready Pull request is ready to be integrated label May 31, 2023

JoKern65 closed this Jun 1, 2023

This was referenced Jun 1, 2023

JDK-8309224: Fix xlc17 clang 15 warnings in java.desktop #14263

Closed

JDK-8309219: Fix xlc17 clang 15 warnings in java.base #14281

Closed

JDK-8309225: Fix xlc17 clang 15 warnings in security and servicability #14282

Closed

JoKern65 deleted the JDK-8308288 branch June 2, 2023 11:18

JoKern65 mentioned this pull request Jun 2, 2023

JDK-8308288: Fix xlc17 clang warnings and build errors in hotspot #14283

Closed

3 tasks

tstuefe mentioned this pull request Mar 29, 2024

8329257: AIX: Switch HOTSPOT_TOOLCHAIN_TYPE from xlc to gcc #18536

Closed

3 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

JDK-8308288: Fix xlc17 clang warnings in shared code #14146

JDK-8308288: Fix xlc17 clang warnings in shared code #14146

JoKern65 commented May 25, 2023 •

edited by openjdk bot

Loading

bridgekeeper bot commented May 25, 2023

openjdk bot commented May 25, 2023

mlbridge bot commented May 25, 2023 •

edited

Loading

MBaesken commented May 25, 2023

kimbarrett left a comment

kimbarrett May 25, 2023

kimbarrett May 25, 2023

TheRealMDoerr May 25, 2023

tstuefe May 26, 2023

TheRealMDoerr May 26, 2023

tstuefe May 27, 2023

tstuefe May 27, 2023

kimbarrett May 27, 2023

kimbarrett May 30, 2023

kimbarrett May 25, 2023

JoKern65 May 25, 2023

MBaesken May 26, 2023

MBaesken May 26, 2023

JoKern65 commented May 26, 2023 •

edited

Loading

JoKern65 commented May 26, 2023

MBaesken commented May 26, 2023

MBaesken commented May 26, 2023 •

edited

Loading

MBaesken commented May 26, 2023

JoKern65 commented May 26, 2023 •

edited

Loading

JoKern65 commented May 26, 2023

JoKern65 commented May 26, 2023

TheRealMDoerr commented May 26, 2023

coleenp May 30, 2023

JoKern65 May 30, 2023

JoKern65 May 31, 2023

prrace left a comment

openjdk bot commented May 31, 2023

JoKern65 commented Jun 1, 2023

JoKern65 commented Jun 1, 2023

JDK-8308288: Fix xlc17 clang warnings in shared code #14146

JDK-8308288: Fix xlc17 clang warnings in shared code #14146

Conversation

JoKern65 commented May 25, 2023 • edited by openjdk bot Loading

Progress

Issue

Reviewers

Reviewing

Webrev

bridgekeeper bot commented May 25, 2023

openjdk bot commented May 25, 2023

mlbridge bot commented May 25, 2023 • edited Loading

Webrevs

MBaesken commented May 25, 2023

kimbarrett left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

JoKern65 commented May 26, 2023 • edited Loading

JoKern65 commented May 26, 2023

MBaesken commented May 26, 2023

MBaesken commented May 26, 2023 • edited Loading

MBaesken commented May 26, 2023

JoKern65 commented May 26, 2023 • edited Loading

JoKern65 commented May 26, 2023

JoKern65 commented May 26, 2023

TheRealMDoerr commented May 26, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

prrace left a comment

Choose a reason for hiding this comment

openjdk bot commented May 31, 2023

JoKern65 commented Jun 1, 2023

JoKern65 commented Jun 1, 2023

JoKern65 commented May 25, 2023 •

edited by openjdk bot

Loading

mlbridge bot commented May 25, 2023 •

edited

Loading

JoKern65 commented May 26, 2023 •

edited

Loading

MBaesken commented May 26, 2023 •

edited

Loading

JoKern65 commented May 26, 2023 •

edited

Loading