New webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8218136.1/
- adjusted globalDefinitions_xlc.hpp - fixed some copyright years Best regards, Matthias > -----Original Message----- > From: Baesken, Matthias > Sent: Freitag, 1. Februar 2019 11:16 > To: 'David Holmes' <david.hol...@oracle.com>; 'hotspot- > d...@openjdk.java.net' <hotspot-...@openjdk.java.net> > Cc: 'build-dev@openjdk.java.net' <build-dev@openjdk.java.net> > Subject: RE: RFR : 8218136: minor hotspot adjustments for xlclang++ from > xlc16 on AIX > > > > > Confused. Which other xlc compilers set __GNUC_ as you are changing this > > for all of them? Though to be honest I don't understand this whole > > section anyway - we have a lengthy comment saying why you can't > > necessarily assign NULL to an integer type and to use NULL_WORD instead > > but then it's defined as NULL anyway! I wonder if we used to have some > > other conditions there where it was something different > > Hi David , not sure but I guess the #ifdef __GNUC__ came from > linux/gcc and was copied to the aix / xlc file when the port was done back > then . > See : > > globalDefinitions_gcc.hpp > > 118#ifdef __GNUC__ > 119 #ifdef _LP64 > 120 #define NULL_WORD 0L > 121 #else > 122 // Cast 0 to intptr_t rather than int32_t since they are not the same > type > 123 // on platforms such as Mac OS X. > 124 #define NULL_WORD ((intptr_t)0) > 125 #endif > 126#else > 127 #define NULL_WORD NULL > 128#endif > > The NULL_WORD is mostly used in x86-only coding. But also used at some > (but few) places in shared coding , like : > > intptr_t* addr; > *addr = NULL_WORD; > > intptr_t _callee_registers[RegisterMap::reg_count]; > _callee_registers[i] = src != NULL ? *src : NULL_WORD; > > > > In any case having an if and else that do exactly the same thing seems > rather > > pointless to me. > > > > Yes I agree , I think I remove the #ifdef ... #else and just define > #define > NULL_WORD NULL for AIX . > > Best regards, Matthias > > > > -----Original Message----- > > From: David Holmes <david.hol...@oracle.com> > > Sent: Freitag, 1. Februar 2019 05:24 > > To: Baesken, Matthias <matthias.baes...@sap.com>; 'hotspot- > > d...@openjdk.java.net' <hotspot-...@openjdk.java.net> > > Cc: 'build-dev@openjdk.java.net' <build-dev@openjdk.java.net> > > Subject: Re: RFR : 8218136: minor hotspot adjustments for xlclang++ from > > xlc16 on AIX > > > > Hi Matthias, > > > > On 1/02/2019 12:50 am, Baesken, Matthias wrote: > > > Please review this small webrev . It contains a few changes for > > > building > > hotspot on AIX with xlclang++ / xlc16 . > > > ( most likely switching to xlclang++ / xlc16 will be a must once we > > introduce C++11/14 features ) > > > > > > Some comments on the changes : > > > > > > > > > - porting_aix.cpp : workaround for demangle.h (does not work with > > xlclang++) > > > > Can't comment as I know nothing about it. > > > > > - arguments.cpp/hpp : the UNSUPPORTED_OPTON macro lead to > > assigning false to AllocateHeapAt which is a bad idea (and does not work > > with xlclang++) > > > > Good catch! > > > > > - globalDefinitions_xlc.hpp : xlclang++ sets __GNUC__ so we must not > > have #error ... in this case > > > > Confused. Which other xlc compilers set __GNUC_ as you are changing this > > for all of them? Though to be honest I don't understand this whole > > section anyway - we have a lengthy comment saying why you can't > > necessarily assign NULL to an integer type and to use NULL_WORD instead > > but then it's defined as NULL anyway! I wonder if we used to have some > > other conditions there where it was something different? In any case > > having an if and else that do exactly the same thing seems rather > > pointless to me. > > > > Thanks, > > David > > > > > > > > > > > > Bug/webrev : > > > > > > https://bugs.openjdk.java.net/browse/JDK-8218136 > > > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8218136.0/ > > > > > > > > > Thanks, Matthias > > >
