- ppc-aix-port-dev - openjdk.org

RFR(s): 8205582: PPC64: RTM: Fix counter for aborts on nested transactions
by Gustavo Romero 18 Jul '18

18 Jul '18

Hi, Could the following change be reviewed please? bug : https://bugs.openjdk.java.net/browse/JDK-8205582 webrev: http://cr.openjdk.java.net/~gromero/8205582/v1/ It fixes the RTM counter for nested aborts (rtm lock aborts type 5) by extracting and checking bits in the Transactional Level field of TEXASR register. It also fixes the memory conflict counter (rtm lock aborts type 2). Power TM status register supports two bits to inform two different types of memory conflict between threads: non-transactional and transactional. According to how the jtreg RTM tests are designed the memory conflict counter counts non-transactional conflicts: on TestPrintPreciseRTMLockingStatistics a RTM lock is held on a static variable while another thread without any synchronization (non-trasactional) tries to modify the same variable. Hence that small adjustment satisfies the TestPrintPreciseRTMLockingStatistics making it pass on Power. The memory conflict counter is not used in any other place besides by the RTM precise statistics (no decision is made by the JVM based on that amount). This change partially fixes some failures in compiler/rtm/print/TestPrintPreciseRTMLockingStatistics.java regarding the nested and memory conflict abort counters. The remaining issue will be fixed by aborting on calling JNI (next RFR). Thank you and best regards, Gustavo

3 12

RFR(s): 8205580: PPC64: RTM: Don't retry lock on abort if abort was intentional
by Gustavo Romero 18 Jul '18

18 Jul '18

Hi, Could the following change be reviewed please? bug : https://bugs.openjdk.java.net/browse/JDK-8205580 webrev: http://cr.openjdk.java.net/~gromero/8205580/v1/ It changes the behavior of rtm_retry_lock_on_abort() by avoiding retry if abort was a deliberate abort, i.e. caused by a 'tabort r0' instruction. On Intel bit 1 in abort_status_Reg (which communicates the abort status) is always clear when a 'xabort 0' instruction is executed in order to inform that a transactional retry /can not/ succeed on retry. So rtm_retry_lock_on_abort() on Intel, on finding bit 1 clear in abort_status_Reg, skips the retry (don't retry). Currently on Power rtm_retry_lock_on_abort() is just checking the persistent bit (if set => skip) which /is not set/ by 'tabort r0'. Hence rtm_retry_lock_on_abort() does retry to lock on an intentional abort caused by 'tabort'. It leads, for instance when -XX:RTMRetryCount=1, to the following discrepancy between Intel and Power regarding the number of retries/aborts: [Power] # rtm locks total (estimated): 3 # rtm lock aborts : 3 # rtm lock aborts 0: 3 # rtm lock aborts 1: 3 # rtm lock aborts 2: 0 # rtm lock aborts 3: 0 # rtm lock aborts 4: 0 # rtm lock aborts 5: 0 [Intel] # rtm locks total (estimated): 2 # rtm lock aborts : 2 # rtm lock aborts 0: 2 # rtm lock aborts 1: 2 # rtm lock aborts 2: 0 # rtm lock aborts 3: 0 # rtm lock aborts 4: 0 # rtm lock aborts 5: 0 So for -XX:RTMRetryCount=X: on Power the number of aborts is: X*2+1 [1 first failure + 1 rtm_retry_lock_on_abort() + 1 rtm_retry_lock_on_busy()]; on Intel the number of aborts is: X+1 [1 first failure + 1 rtm_retry_lock_on_busy()] This change fixes that discrepancy by using bit "Abort" in TEXASR register (abort_status_Reg) that tells if a transaction was aborted due to a 'tabort' instruction and skip the retry if such a bit is set. It fixes the following tests: +Passed: compiler/rtm/locking/TestRTMRetryCount.java +Passed: compiler/rtm/locking/TestRTMAbortThreshold.java Thank you and best regards, Gustavo

3 7

RFR(s): 8205581: PPC64: RTM: Fix abort on native calls
by Gustavo Romero 18 Jul '18

18 Jul '18

Hi, Could the following change be reviewed please? bug : https://bugs.openjdk.java.net/browse/JDK-8205581 webrev: http://cr.openjdk.java.net/~gromero/8205581/v1/ It forces a transactional state to abort before calling native methods, before calling runtime, and on uncommon trap checking, mostly because transaction will be aborted soon or latter in either case, similarly to what happens on Intel. The abort instruction (tabort) is only emitted if UseRTMLocking is "true" and any 'tabort' instruction is treated as a 'nop' instruction if TM state is non-transactional. It fixes the following tests: +Passed: compiler/rtm/print/TestPrintPreciseRTMLockingStatistics.java +Passed: compiler/rtm/locking/TestRTMDeoptOnHighAbortRatio.java Thank you and best regards, Gustavo

3 6

Filed 8207404: MulticastSocket tests failing on Aix
by Nasser Ebrahim 18 Jul '18

18 Jul '18

Lindenmaier, Goetz goetz.lindenmaier at sap.com Tue Jul 17 14:40:29 UTC 2018 > is there anyone at IBM interested in looking at this issue? > https://bugs.openjdk.java.net/browse/JDK-8207404 Yes Goetz. I will analyze the issue and get back to you. Thank you, Nasser Ebrahim

2 1

Filed 8207404: MulticastSocket tests failing on Aix
by Lindenmaier, Goetz 17 Jul '18

17 Jul '18

Hi, is there anyone at IBM interested in looking at this issue? https://bugs.openjdk.java.net/browse/JDK-8207404 We see this failing on our systems all the time. I'll problem list these tests. Best regards, Goetz.

1 0

RFR(S): 8207011: Remove uses of the register storage class specifier
by Mikael Vidstedt 12 Jul '18

12 Jul '18

Please review the below change which removes *most* uses of the register keyword/storage class specifier. Bug: https://bugs.openjdk.java.net/browse/JDK-8207011 <https://bugs.openjdk.java.net/browse/JDK-8207011> Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8207011/webrev.01/open/webrev/ <http://cr.openjdk.java.net/~mikael/webrevs/8207011/webrev.01/open/webrev/> * Background (from the bug) The C/C++ register keyword/storage class specifier may have made a difference many moons ago, but the C++11 standard deprecated it, and starting with C++17 it is a reserved keyword. Some compilers emit deprecation warnings even when targeting earlier C++ standards such as C++14. * Commentary The one case where the register keyword remains is when compiling (effectively) inline assembly with gcc, patterns like: address os::current_stack_pointer() { … #else // gcc register void *esp __asm__ (SPELL_REG_SP); return (address) esp; #endif } Removing the register keyword here breaks the code, and gcc does *not* complain about using it for these patterns, so I chose to leave it there. An alternative to that would be to always use the “clang” style mov instruction. I know there is another thread[1] discussing how to move forward with the current_stack_pointer on clang 4.0. I’ll keep my eyes on that to make sure we don’t collide (and cc:ing Martin for good luck). Would appreciate some help from the respective porting folks to verify the aix/ppc/s390 changes. Cheers, Mikael [1] http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2018-July/029099… <http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2018-July/029099…>

3 2

RFR(xs): 8204935: [aix] TOC overflow in libjvm.so (release build)
by Thomas Stüfe 13 Jun '18

13 Jun '18

Hi all, may I have reviews for this small build fix: Bug: https://bugs.openjdk.java.net/browse/JDK-8204935 webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8204935-aix-toc-overflow/webrev.… We finally have reached the point where even the standard (not gtest) release build libjvm.so got too large and blew its TOC. Hurray for templates. On the bright side, no need to keep different flags for different libjvm variants anymore. Kudos to whoever added auto-automake to the build, that makes these kind of changes really easier :) Thank you, Best Regards, Thomas

4 6

FYI JDK-8204240 has some platform specific change
by Roland Westrelin 13 Jun '18

13 Jun '18

One of my changes being reviewed on hotspot-compiler-dev has some platform specific changes: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2018-June/02930… I took a quick look at the ppc code and it is fine AFAICT but one of you may want to verify. Roland.

1 0

RFR : 8204541 Correctly support AIX xlC 13.1 symbol visibility flags
by Ichiroh Takiguchi 08 Jun '18

08 Jun '18

Hello. Could you review it ? Bug: https://bugs.openjdk.java.net/browse/JDK-8204541 Change: http://cr.openjdk.java.net/~clanger/webrevs/8204541.0/ Thanks, Ichiroh Takiguchi IBM Japan, Ltd. -------- Original Message -------- Subject: RE: RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1 Date: 2018-06-07 20:43 From: "Langer, Christoph" <christoph.langer(a)sap.com> To: Ichiroh Takiguchi <takiguc(a)linux.vnet.ibm.com> Cc: "'build-dev(a)openjdk.java.net'" <build-dev(a)openjdk.java.net>, "ppc-aix-port-dev(a)openjdk.java.net" <ppc-aix-port-dev(a)openjdk.java.net>, "core-libs-dev(a)openjdk.java.net" <core-libs-dev(a)openjdk.java.net>, "Lindenmaier, Goetz" <goetz.lindenmaier(a)sap.com>, "Baesken, Matthias" <matthias.baesken(a)sap.com> Hi Ichiroh, your proposal seems to make sense. I have created a bug for this: https://bugs.openjdk.java.net/browse/JDK-8204541 Can you please generate a webrev (referencing this bug, -c option of webrev.ksh) and mail it over to me. Then I'll upload it and you can post an official RFR mail. Best regards Christoph > -----Original Message----- > From: Ichiroh Takiguchi [mailto:takiguc@linux.vnet.ibm.com] > Sent: Dienstag, 5. Juni 2018 08:59 > To: Baesken, Matthias <matthias.baesken(a)sap.com> > Cc: Langer, Christoph <christoph.langer(a)sap.com>; 'build- > dev(a)openjdk.java.net' <build-dev(a)openjdk.java.net>; ppc-aix-port- > dev(a)openjdk.java.net; core-libs-dev(a)openjdk.java.net; Lindenmaier, > Goetz <goetz.lindenmaier(a)sap.com> > Subject: RE: RFR : 8202322: AIX: symbol visibility flags not support on > xlc 12.1 > > Hello Matthias and Christoph. > Thank you for your explanations. > > I did not have enough knowledge about "visibility". > > I created following patches. > > ================================ > diff -r 02934b0d661b > src/java.base/share/native/libjimage/NativeImageBuffer.cpp > --- a/src/java.base/share/native/libjimage/NativeImageBuffer.cpp Wed > May > 30 14:46:28 2018 +0200 > +++ b/src/java.base/share/native/libjimage/NativeImageBuffer.cpp Tue > Jun > 05 12:10:41 2018 +0900 > @@ -39,7 +39,9 @@ > #include "imageFile.hpp" > #include "inttypes.hpp" > #include "jimage.hpp" > +#if !defined(_AIX) > #include "osSupport.hpp" > +#endif > > #include "jdk_internal_jimage_NativeImageBuffer.h" > > diff -r 02934b0d661b src/java.base/unix/native/include/jni_md.h > --- a/src/java.base/unix/native/include/jni_md.h Wed May 30 14:46:28 > 2018 +0200 > +++ b/src/java.base/unix/native/include/jni_md.h Tue Jun 05 12:10:41 > 2018 +0900 > @@ -29,7 +29,8 @@ > #ifndef __has_attribute > #define __has_attribute(x) 0 > #endif > -#if (defined(__GNUC__) && ((__GNUC__ > 4) || (__GNUC__ == 4) && > (__GNUC_MINOR__ > 2))) || __has_attribute(visibility) > +#if (defined(__GNUC__) && ((__GNUC__ > 4) || (__GNUC__ == 4) && > (__GNUC_MINOR__ > 2))) || __has_attribute(visibility) \ > + || (defined(_AIX) && (defined(__xlC__) && (__xlC__ >= 0xD01))) > #ifdef ARM > #define JNIEXPORT > __attribute__((externally_visible,visibility("default"))) > #define JNIIMPORT > __attribute__((externally_visible,visibility("default"))) > ================================ > > If "osSupport.hpp" was included, XLC++ compiler complained. > I could not understand, which part was invalid... > I'm not sure, "osSupport.hpp" is really required on > NativeImageBuffer.cpp or not... > > I added __xlC__ macro to determine XLC/C++'s version# into jni_md.h. > [1] > 0xD01 means 13.1 by hexadecimal. > > I checked symbol table by "dump -Tv -X64". [2] > It seemed it was fine, some symbols were hidden. > > Does someone review my code? > > [1] > https://www.ibm.com/support/knowledgecenter/en/SSGH2K_13.1.3/com.i > bm.xlc1313.aix.doc/compiler_ref/xlmacros.html > [2] > https://www.ibm.com/developerworks/aix/library/au-aix-symbol- > visibility/index.html > > On 2018-06-01 21:12, Baesken, Matthias wrote: > > Hi , my change 8202322 just handled the fact that the > > visibility - flags are not supported with xlc 12.1 , so setting > > them generated a TON of compile - time warnings . > > > > The introduction of the "-qvisibility=hidden" came with the > > mapfile removal changes : > > > > 8200358: Remove mapfiles for JDK executables > > http://hg.openjdk.java.net/jdk/jdk/rev/210cf224b690 > > > > 8200178: Remove mapfiles for JDK native libraries > > http://hg.openjdk.java.net/jdk/jdk/rev/396ea30afbd5 > > > > I guess it might need further testing+adjustments to make the > > "visibility hiding" work nicely with XLC13 , but currently we > > build only with XLC12 . > > > > As a workaround you might want to remove the "-qvisibility=hidden" > > setting for XLC 13 as well , like I did for XLC12 with the change > > 8202322 . > > > > > > Best regards, Matthias > > > > > > > > > >> -----Original Message----- > >> From: Langer, Christoph > >> Sent: Freitag, 1. Juni 2018 10:57 > >> To: Ichiroh Takiguchi <takiguc(a)linux.vnet.ibm.com> > >> Cc: Baesken, Matthias <matthias.baesken(a)sap.com>; 'build- > >> dev(a)openjdk.java.net' <build-dev(a)openjdk.java.net>; ppc-aix-port- > >> dev(a)openjdk.java.net; core-libs-dev(a)openjdk.java.net; Lindenmaier, > >> Goetz <goetz.lindenmaier(a)sap.com> > >> Subject: RE: RFR : 8202322: AIX: symbol visibility flags not support > >> on xlc 12.1 > >> > >> Hi Ichiroh, > >> > >> we do not use the XLC 13 compiler on AIX yet here at SAP and I believe > >> nobody of my colleagues has played with it yet. So you are on a new > >> playground here 😊 > >> > >> However, I believe the idea in OpenJDK with the abolition of map files > >> is that > >> symbols should be invisible externally unless they are declared > >> exported, > >> e.g. JNIEXPORT. So I would think "-qvisibility=hidden" should be the > >> correct > >> default and whatever JNIEXPORT expands to should contain the right > >> attributes to get that symbol visible. > >> > >> Can you check if either my assumption is completely wrong, JNIEXPORT > >> does > >> not expand to the right thing, XLC 13 has a bug or maybe just sume > >> specific > >> required symbols are not declared correctly? > >> > >> Best regards > >> Christoph > >> > >> > -----Original Message----- > >> > From: Ichiroh Takiguchi [mailto:takiguc@linux.vnet.ibm.com] > >> > Sent: Donnerstag, 31. Mai 2018 09:55 > >> > To: Langer, Christoph <christoph.langer(a)sap.com> > >> > Cc: Baesken, Matthias <matthias.baesken(a)sap.com>; 'build- > >> > dev(a)openjdk.java.net' <build-dev(a)openjdk.java.net>; ppc-aix-port- > >> > dev(a)openjdk.java.net; core-libs-dev(a)openjdk.java.net; Lindenmaier, > >> > Goetz <goetz.lindenmaier(a)sap.com> > >> > Subject: RE: RFR : 8202322: AIX: symbol visibility flags not support on xlc > 12.1 > >> > > >> > Hello. > >> > 8202322 was integrated into jdk-11+15. > >> > I'm using XLC 13.1.3 on AIX 7.1.4. > >> > Build was failed because of "-qvisibility=hidden" on > >> > make/lib/LibCommon.gmk. > >> > According to "XL C/C++ for AIX 13.1.3" documentation [1], > >> > "-qvisibility=hidden" cannot create shared libraries entry points. > >> > For example, libverify.so was there, but entry points were not resolved > >> > by "-lverify" option. > >> > I think it should be "-qvisibility=default" (I tried, it worked) > >> > or "-qvisibility=protected" (I had not tried) ? > >> > I'm not familiar with -qvisibility option, but I'd like to find out > >> > right way. > >> > > >> > [1] > >> > > >> > https://www.ibm.com/support/knowledgecenter/SSGH3R_13.1.3/com.ibm. > >> > xlcpp1313.aix.doc/compiler_ref/opt_visibility.html > >> > > >> > On 2018-05-16 16:08, Langer, Christoph wrote: > >> > > Hi Matthias, > >> > > > >> > > yes, reviewed. > >> > > > >> > > Best regards > >> > > Christoph > >> > > > >> > > From: Baesken, Matthias > >> > > Sent: Mittwoch, 16. Mai 2018 09:06 > >> > > To: Langer, Christoph <christoph.langer(a)sap.com>; > >> > > 'build-dev(a)openjdk.java.net' <build-dev(a)openjdk.java.net>; > >> > > ppc-aix-port-dev(a)openjdk.java.net; core-libs-dev(a)openjdk.java.net > >> > > Cc: Lindenmaier, Goetz <goetz.lindenmaier(a)sap.com> > >> > > Subject: RE: RFR : 8202322: AIX: symbol visibility flags not support on > >> > > xlc 12.1 > >> > > > >> > > Hi Christoph can I add you as second reviewer (other reviewer was > >> > > Erik Joelsson) can push the change ? > >> > > > >> > > Best regards, Matthias > >> > > > >> > > > >> > > > >> > > From: Langer, Christoph > >> > > Sent: Donnerstag, 26. April 2018 16:38 > >> > > To: Baesken, Matthias > >> > > <matthias.baesken(a)sap.com<mailto:matthias.baesken@sap.com>>; > >> > > 'build-dev(a)openjdk.java.net' > >> > > <build-dev(a)openjdk.java.net<mailto:build- > dev(a)openjdk.java.net>>; > >> > > ppc-aix-port-dev(a)openjdk.java.net<mailto:ppc-aix-port- > >> > dev(a)openjdk.java.net>; > >> > > core-libs-dev(a)openjdk.java.net<mailto:core-libs- > >> dev(a)openjdk.java.net> > >> > > Cc: Simonis, Volker > >> > > <volker.simonis(a)sap.com<mailto:volker.simonis@sap.com>> > >> > > Subject: RE: RFR : 8202322: AIX: symbol visibility flags not support on > >> > > xlc 12.1 > >> > > > >> > > Hi Matthias, > >> > > > >> > > to me the change in principal looks good. > >> > > > >> > > I'm wondering if it is possible to do a comparison like xlc < 13 (e.g. > >> > > extract major number before the first dot, then compare numerically) > - > >> > > but maybe it is too complicated and the current single version > compare > >> > > suits our needs ? > >> > > > >> > > Best regards > >> > > Christoph > >> > > > >> > > From: Baesken, Matthias > >> > > Sent: Donnerstag, 26. April 2018 16:14 > >> > > To: 'build-dev(a)openjdk.java.net' > >> > > <build-dev(a)openjdk.java.net<mailto:build- > dev(a)openjdk.java.net>>; > >> > > ppc-aix-port-dev(a)openjdk.java.net<mailto:ppc-aix-port- > >> > dev(a)openjdk.java.net>; > >> > > core-libs-dev(a)openjdk.java.net<mailto:core-libs- > >> dev(a)openjdk.java.net> > >> > > Cc: Langer, Christoph > >> > > <christoph.langer(a)sap.com<mailto:christoph.langer@sap.com>>; > >> Simonis, > >> > > Volker <volker.simonis(a)sap.com<mailto:volker.simonis@sap.com>> > >> > > Subject: RFR : 8202322: AIX: symbol visibility flags not support on xlc > >> > > 12.1 > >> > > > >> > > Hello , could you please review this small adjustment to the symbol > >> > > visibility compilation settings on AIX ? > >> > > Currently we use XLC 12.1 to compile JDK on AIX . > >> > > > >> > > However XLC 12.1 does not support the "-qvisibility=hidden" > >> > > setting currently set on AIX. > >> > > It was introduced with XLC 13.1 . Christoph found some info about it > >> > > here : > >> > > > >> > > https://www.ibm.com/developerworks/aix/library/au-aix-symbol- > >> > visibility-part2/index.html > >> > > > >> > > Setting it only generates hundreds of warnings in the build log , > >> > > warnings look like this : > >> > > XlC12.1 > >> > > > >> > > bash-4.4$ xlC -qversion > >> > > IBM XL C/C++ for AIX, V12.1 (5765-J02, 5725-C72) > >> > > Version: 12.01.0000.0019 > >> > > > >> > > bash-4.4$ xlC -qvisibility=hidden sizeof.c -o sizeof_aixxlc > >> > > 1506-173 (W) Option visibility=hidden is not valid. Enter xlC for list > >> > > of valid options. > >> > > > >> > > Compare to XLC13.1 > >> > > > >> > > bash-3.00$ xlC -qversion > >> > > IBM XL C/C++ for AIX, V13.1 (5725-C72, 5765-J07) > >> > > Version: 13.01.0000.0008 > >> > > bash-3.00$ xlC -qvisibility=default sizeof.c -o sizeof_aixxlc > >> > > bash-3.00$ xlC -qvisibility=hidden sizeof.c -o sizeof_aixxlc > >> > > > >> > > > >> > > So it is better to avoid setting these flags when using xlc12.1 . > >> > > Please review : > >> > > > >> > > Bug : > >> > > > >> > > https://bugs.openjdk.java.net/browse/JDK-8202322 > >> > > > >> > > Change : > >> > > > >> > > http://cr.openjdk.java.net/~mbaesken/webrevs/8202322/ > >> > > > >> > > > >> > > Best regards, Matthias

2 3

RE: RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1
by Ichiroh Takiguchi 07 Jun '18

07 Jun '18

Hello. 8202322 was integrated into jdk-11+15. I'm using XLC 13.1.3 on AIX 7.1.4. Build was failed because of "-qvisibility=hidden" on make/lib/LibCommon.gmk. According to "XL C/C++ for AIX 13.1.3" documentation [1], "-qvisibility=hidden" cannot create shared libraries entry points. For example, libverify.so was there, but entry points were not resolved by "-lverify" option. I think it should be "-qvisibility=default" (I tried, it worked) or "-qvisibility=protected" (I had not tried) ? I'm not familiar with -qvisibility option, but I'd like to find out right way. [1] https://www.ibm.com/support/knowledgecenter/SSGH3R_13.1.3/com.ibm.xlcpp1313… On 2018-05-16 16:08, Langer, Christoph wrote: > Hi Matthias, > > yes, reviewed. > > Best regards > Christoph > > From: Baesken, Matthias > Sent: Mittwoch, 16. Mai 2018 09:06 > To: Langer, Christoph <christoph.langer(a)sap.com>; > 'build-dev(a)openjdk.java.net' <build-dev(a)openjdk.java.net>; > ppc-aix-port-dev(a)openjdk.java.net; core-libs-dev(a)openjdk.java.net > Cc: Lindenmaier, Goetz <goetz.lindenmaier(a)sap.com> > Subject: RE: RFR : 8202322: AIX: symbol visibility flags not support on > xlc 12.1 > > Hi Christoph can I add you as second reviewer (other reviewer was > Erik Joelsson) can push the change ? > > Best regards, Matthias > > > > From: Langer, Christoph > Sent: Donnerstag, 26. April 2018 16:38 > To: Baesken, Matthias > <matthias.baesken(a)sap.com<mailto:matthias.baesken@sap.com>>; > 'build-dev(a)openjdk.java.net' > <build-dev(a)openjdk.java.net<mailto:build-dev@openjdk.java.net>>; > ppc-aix-port-dev(a)openjdk.java.net<mailto:ppc-aix-port-dev@openjdk.java.net>; > core-libs-dev(a)openjdk.java.net<mailto:core-libs-dev@openjdk.java.net> > Cc: Simonis, Volker > <volker.simonis(a)sap.com<mailto:volker.simonis@sap.com>> > Subject: RE: RFR : 8202322: AIX: symbol visibility flags not support on > xlc 12.1 > > Hi Matthias, > > to me the change in principal looks good. > > I'm wondering if it is possible to do a comparison like xlc < 13 (e.g. > extract major number before the first dot, then compare numerically) - > but maybe it is too complicated and the current single version compare > suits our needs ? > > Best regards > Christoph > > From: Baesken, Matthias > Sent: Donnerstag, 26. April 2018 16:14 > To: 'build-dev(a)openjdk.java.net' > <build-dev(a)openjdk.java.net<mailto:build-dev@openjdk.java.net>>; > ppc-aix-port-dev(a)openjdk.java.net<mailto:ppc-aix-port-dev@openjdk.java.net>; > core-libs-dev(a)openjdk.java.net<mailto:core-libs-dev@openjdk.java.net> > Cc: Langer, Christoph > <christoph.langer(a)sap.com<mailto:christoph.langer@sap.com>>; Simonis, > Volker <volker.simonis(a)sap.com<mailto:volker.simonis@sap.com>> > Subject: RFR : 8202322: AIX: symbol visibility flags not support on xlc > 12.1 > > Hello , could you please review this small adjustment to the symbol > visibility compilation settings on AIX ? > Currently we use XLC 12.1 to compile JDK on AIX . > > However XLC 12.1 does not support the "-qvisibility=hidden" > setting currently set on AIX. > It was introduced with XLC 13.1 . Christoph found some info about it > here : > > https://www.ibm.com/developerworks/aix/library/au-aix-symbol-visibility-par… > > Setting it only generates hundreds of warnings in the build log , > warnings look like this : > XlC12.1 > > bash-4.4$ xlC -qversion > IBM XL C/C++ for AIX, V12.1 (5765-J02, 5725-C72) > Version: 12.01.0000.0019 > > bash-4.4$ xlC -qvisibility=hidden sizeof.c -o sizeof_aixxlc > 1506-173 (W) Option visibility=hidden is not valid. Enter xlC for list > of valid options. > > Compare to XLC13.1 > > bash-3.00$ xlC -qversion > IBM XL C/C++ for AIX, V13.1 (5725-C72, 5765-J07) > Version: 13.01.0000.0008 > bash-3.00$ xlC -qvisibility=default sizeof.c -o sizeof_aixxlc > bash-3.00$ xlC -qvisibility=hidden sizeof.c -o sizeof_aixxlc > > > So it is better to avoid setting these flags when using xlc12.1 . > Please review : > > Bug : > > https://bugs.openjdk.java.net/browse/JDK-8202322 > > Change : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8202322/ > > > Best regards, Matthias

3 4