hi guys. The build instructions from Volker seem to work ok on my AIX machine up to a point. Using V11 of the XLC compiler I hit a compiler bug. When I move to the latest V12 version I get this below in the build log.. Seems to be a pretty hard failure - any advice? Cheers Steve Compiling /home/spoole/repos/aix-ppc/jdk7u/hotspot/src/share/vm/ci/ciObject.cpp rm -f ciObject.o xlC_r -DAIX -DPPC64 -DASSERT -DDEBUG -I/home/spoole/repos/aix-ppc/jdk7u/hotspot/src/share/vm/prims -I/home/spoole/repos/aix-ppc/jdk7u/hotspot/src/share/vm -I/home/spoole/repos/aix-ppc/jdk7u/hotspot/src/share/vm/precompiled -I/home/spoole/repos/aix-ppc/jdk7u/hotspot/src/cpu/ppc/vm -I/home/spoole/repos/aix-ppc/jdk7u/hotspot/src/os_cpu/aix_ppc/vm -I/home/spoole/repos/aix-ppc/jdk7u/hotspot/src/os/aix/vm -I/home/spoole/repos/aix-ppc/jdk7u/hotspot/src/os/posix/vm -I../generated -DHOTSPOT_RELEASE_VERSION="\"23.2-b04\"" -DHOTSPOT_BUILD_TARGET="\"jvmg\"" -DHOTSPOT_BUILD_USER="\"spoole\"" -DHOTSPOT_LIB_ARCH=\"ppc64\" -DHOTSPOT_VM_DISTRO="\"OpenJDK\"" -DTARGET_OS_FAMILY_aix -DTARGET_ARCH_ppc -DTARGET_ARCH_MODEL_ppc_64 -DTARGET_OS_ARCH_aix_ppc -DTARGET_OS_ARCH_MODEL_aix_ppc_64 -DTARGET_COMPILER_xlc -qpic=large -qnortti -qnoeh -D_REENTRANT -q64 -DCC_INTERP -g -q64 -qlanglvl=c99vla -qlanglvl=noredefmac -qsuppress=1540-0198 -qsuppress=1540-1090 -qsuppress=1500-010 -DSAFEFETCH_STUBS -DINCLUDE_TRACE -c -qmakedep=gcc -MF ../generated/dependencies/ciObject.o.d -o ciObject.o /home/spoole/repos/aix-ppc/jdk7u/hotspot/src/share/vm/ci/ciObject.cpp "/home/spoole/repos/aix-ppc/jdk7u/hotspot/src/share/vm/memory/allocation.hpp", line 112.7: 1540-0300 (S) The "private" member "class StackObj" cannot be accessed. "/home/spoole/repos/aix-ppc/jdk7u/hotspot/src/share/vm/prims/methodHandleWalk.hpp", line 272.7: 1540-0719 (I) The previous message was produced while processing the implicit member function "MethodHandleCompiler::~MethodHandleCompiler()". "/home/spoole/repos/aix-ppc/jdk7u/hotspot/src/share/vm/ci/ciMethodHandle.cpp", line 69.3: 1540-0700 (I) The previous message was produced while processing "ciMethodHandle::get_adapter_impl(bool)".
Hi Steve, sorry to say it, but I'm pretty sure this is yet another XLC bug and one of the reasons why we are still tied to XLC 10 (which is a shame!). I could reproduce the error with a version of XLC 12: IBM XL C/C++ for AIX, V12.1 (5765-J02, 5725-C72) Version: 12.01.0000.0000 Unfortunately the 12 compiler is just on a test system where I can't compile the whole JDK. But I could narrow the problem down to the following little, self contained C++ program (based on the original HotSpot sources): /////////////////////////////////////////////private.cpp//////////////////////////////////////////////////////// class FOO { public: ~FOO() {} }; class StackObj { public: void operator delete(void* p) {} }; class MethodHandleWalker : StackObj { FOO foo; }; class MethodHandleCompiler : public MethodHandleWalker { }; int main(int argc, char* argv[]) { { MethodHandleCompiler mh; } return 1; } /////////////////////////////////////////////private.cpp//////////////////////////////////////////////////////// If compiled with XLC 12, it provokes the very same error message:
xlC_r -q64 -c -o /tmp/a.out ~/Bugs/xlC/private.cpp "/sapmnt/home1/d046063/Bugs/xlC/private.cpp", line 11.28: 1540-0198 (W) The omitted keyword "private" is assumed for base class "StackObj". "/sapmnt/home1/d046063/Bugs/xlC/private.cpp", line 6.7: 1540-0300 (S) The "private" member "class StackObj" cannot be accessed. "/sapmnt/home1/d046063/Bugs/xlC/private.cpp", line 15.7: 1540-0719 (I) The previous message was produced while processing the implicit member function "MethodHandleCompiler::~MethodHandleCompiler()". "/sapmnt/home1/d046063/Bugs/xlC/private.cpp", line 18.5: 1540-0700 (I) The previous message was produced while processing "main(int, char *[])".
This code works with all other compilers we know (at least XLC 10, GCC 4, MS Visual Studio, HP aCC, Sun Studio) an I'm pretty sure that XLC 12 is wrong. The problem is that XLC claims that the "StackObj" class is not accessible from within the synthetically generated destructor of the class "MethodHandleCompiler". That is true, because "StackObj" is a private base class "MethodHandleWalker" from which "MethodHandleCompiler" inherits. But that's not the point here! The synthetically generated destructor of the class "MethodHandleCompiler" (i.e. "MethodHandleCompiler::~MethodHandleCompiler()") only has to destruct the members of "MethodHandleCompiler" and call the destructor of its base classes. And in turn, the synthetically generated destructor of its base class "MethodHandleWalker" could access its base class "StackObj" very well! We would be really deeply grateful if you could escalate this bug to your internal XLC compiler group colleagues. After all, the HotSpot code is more than 10 years old C++ code which doesn't use neither Exception Handling nor RTTI and only some very simple template constructs and I think this code should be correctly compilable by every reasonably decent C++ compiler nowadays. After all, your XLC team can freely access and build the OpenJDK sources so it should be not too hard for them to reproduce this and maybe other problems. Regards, Volker On Mon, Nov 12, 2012 at 11:38 AM, Steve Poole <spoole@linux.vnet.ibm.com> wrote:
hi guys. The build instructions from Volker seem to work ok on my AIX machine up to a point.
Using V11 of the XLC compiler I hit a compiler bug. When I move to the latest V12 version I get this below in the build log..
Seems to be a pretty hard failure - any advice?
Cheers Steve
Compiling /home/spoole/repos/aix-ppc/jdk7u/hotspot/src/share/vm/ci/ciObject.cpp rm -f ciObject.o xlC_r -DAIX -DPPC64 -DASSERT -DDEBUG -I/home/spoole/repos/aix-ppc/jdk7u/hotspot/src/share/vm/prims -I/home/spoole/repos/aix-ppc/jdk7u/hotspot/src/share/vm -I/home/spoole/repos/aix-ppc/jdk7u/hotspot/src/share/vm/precompiled -I/home/spoole/repos/aix-ppc/jdk7u/hotspot/src/cpu/ppc/vm -I/home/spoole/repos/aix-ppc/jdk7u/hotspot/src/os_cpu/aix_ppc/vm -I/home/spoole/repos/aix-ppc/jdk7u/hotspot/src/os/aix/vm -I/home/spoole/repos/aix-ppc/jdk7u/hotspot/src/os/posix/vm -I../generated -DHOTSPOT_RELEASE_VERSION="\"23.2-b04\"" -DHOTSPOT_BUILD_TARGET="\"jvmg\"" -DHOTSPOT_BUILD_USER="\"spoole\"" -DHOTSPOT_LIB_ARCH=\"ppc64\" -DHOTSPOT_VM_DISTRO="\"OpenJDK\"" -DTARGET_OS_FAMILY_aix -DTARGET_ARCH_ppc -DTARGET_ARCH_MODEL_ppc_64 -DTARGET_OS_ARCH_aix_ppc -DTARGET_OS_ARCH_MODEL_aix_ppc_64 -DTARGET_COMPILER_xlc -qpic=large -qnortti -qnoeh -D_REENTRANT -q64 -DCC_INTERP -g -q64 -qlanglvl=c99vla -qlanglvl=noredefmac -qsuppress=1540-0198 -qsuppress=1540-1090 -qsuppress=1500-010 -DSAFEFETCH_STUBS -DINCLUDE_TRACE -c -qmakedep=gcc -MF ../generated/dependencies/ciObject.o.d -o ciObject.o /home/spoole/repos/aix-ppc/jdk7u/hotspot/src/share/vm/ci/ciObject.cpp "/home/spoole/repos/aix-ppc/jdk7u/hotspot/src/share/vm/memory/allocation.hpp", line 112.7: 1540-0300 (S) The "private" member "class StackObj" cannot be accessed. "/home/spoole/repos/aix-ppc/jdk7u/hotspot/src/share/vm/prims/methodHandleWalk.hpp", line 272.7: 1540-0719 (I) The previous message was produced while processing the implicit member function "MethodHandleCompiler::~MethodHandleCompiler()". "/home/spoole/repos/aix-ppc/jdk7u/hotspot/src/share/vm/ci/ciMethodHandle.cpp", line 69.3: 1540-0700 (I) The previous message was produced while processing "ciMethodHandle::get_adapter_impl(bool)".
Yes, and what I forgot to say: Steve, could you please, please try with XLC 10 just to verify that besides all these C++ compiler bugs, the general build is working and is producing reasonable results. I think this is really very important such that we can finally get started with the work on the class library (for JDK 7 and 8). Thank you and best regards, Volker On Mon, Nov 12, 2012 at 6:28 PM, Volker Simonis <volker.simonis@gmail.com> wrote:
Hi Steve,
sorry to say it, but I'm pretty sure this is yet another XLC bug and one of the reasons why we are still tied to XLC 10 (which is a shame!). I could reproduce the error with a version of XLC 12:
IBM XL C/C++ for AIX, V12.1 (5765-J02, 5725-C72) Version: 12.01.0000.0000
Unfortunately the 12 compiler is just on a test system where I can't compile the whole JDK. But I could narrow the problem down to the following little, self contained C++ program (based on the original HotSpot sources):
/////////////////////////////////////////////private.cpp//////////////////////////////////////////////////////// class FOO { public: ~FOO() {} };
class StackObj { public: void operator delete(void* p) {} };
class MethodHandleWalker : StackObj { FOO foo; };
class MethodHandleCompiler : public MethodHandleWalker { };
int main(int argc, char* argv[]) {
{ MethodHandleCompiler mh; }
return 1; } /////////////////////////////////////////////private.cpp////////////////////////////////////////////////////////
If compiled with XLC 12, it provokes the very same error message:
xlC_r -q64 -c -o /tmp/a.out ~/Bugs/xlC/private.cpp "/sapmnt/home1/d046063/Bugs/xlC/private.cpp", line 11.28: 1540-0198 (W) The omitted keyword "private" is assumed for base class "StackObj". "/sapmnt/home1/d046063/Bugs/xlC/private.cpp", line 6.7: 1540-0300 (S) The "private" member "class StackObj" cannot be accessed. "/sapmnt/home1/d046063/Bugs/xlC/private.cpp", line 15.7: 1540-0719 (I) The previous message was produced while processing the implicit member function "MethodHandleCompiler::~MethodHandleCompiler()". "/sapmnt/home1/d046063/Bugs/xlC/private.cpp", line 18.5: 1540-0700 (I) The previous message was produced while processing "main(int, char *[])".
This code works with all other compilers we know (at least XLC 10, GCC 4, MS Visual Studio, HP aCC, Sun Studio) an I'm pretty sure that XLC 12 is wrong. The problem is that XLC claims that the "StackObj" class is not accessible from within the synthetically generated destructor of the class "MethodHandleCompiler". That is true, because "StackObj" is a private base class "MethodHandleWalker" from which "MethodHandleCompiler" inherits.
But that's not the point here! The synthetically generated destructor of the class "MethodHandleCompiler" (i.e. "MethodHandleCompiler::~MethodHandleCompiler()") only has to destruct the members of "MethodHandleCompiler" and call the destructor of its base classes. And in turn, the synthetically generated destructor of its base class "MethodHandleWalker" could access its base class "StackObj" very well!
We would be really deeply grateful if you could escalate this bug to your internal XLC compiler group colleagues. After all, the HotSpot code is more than 10 years old C++ code which doesn't use neither Exception Handling nor RTTI and only some very simple template constructs and I think this code should be correctly compilable by every reasonably decent C++ compiler nowadays.
After all, your XLC team can freely access and build the OpenJDK sources so it should be not too hard for them to reproduce this and maybe other problems.
Regards, Volker
On Mon, Nov 12, 2012 at 11:38 AM, Steve Poole <spoole@linux.vnet.ibm.com> wrote:
hi guys. The build instructions from Volker seem to work ok on my AIX machine up to a point.
Using V11 of the XLC compiler I hit a compiler bug. When I move to the latest V12 version I get this below in the build log..
Seems to be a pretty hard failure - any advice?
Cheers Steve
Compiling /home/spoole/repos/aix-ppc/jdk7u/hotspot/src/share/vm/ci/ciObject.cpp rm -f ciObject.o xlC_r -DAIX -DPPC64 -DASSERT -DDEBUG -I/home/spoole/repos/aix-ppc/jdk7u/hotspot/src/share/vm/prims -I/home/spoole/repos/aix-ppc/jdk7u/hotspot/src/share/vm -I/home/spoole/repos/aix-ppc/jdk7u/hotspot/src/share/vm/precompiled -I/home/spoole/repos/aix-ppc/jdk7u/hotspot/src/cpu/ppc/vm -I/home/spoole/repos/aix-ppc/jdk7u/hotspot/src/os_cpu/aix_ppc/vm -I/home/spoole/repos/aix-ppc/jdk7u/hotspot/src/os/aix/vm -I/home/spoole/repos/aix-ppc/jdk7u/hotspot/src/os/posix/vm -I../generated -DHOTSPOT_RELEASE_VERSION="\"23.2-b04\"" -DHOTSPOT_BUILD_TARGET="\"jvmg\"" -DHOTSPOT_BUILD_USER="\"spoole\"" -DHOTSPOT_LIB_ARCH=\"ppc64\" -DHOTSPOT_VM_DISTRO="\"OpenJDK\"" -DTARGET_OS_FAMILY_aix -DTARGET_ARCH_ppc -DTARGET_ARCH_MODEL_ppc_64 -DTARGET_OS_ARCH_aix_ppc -DTARGET_OS_ARCH_MODEL_aix_ppc_64 -DTARGET_COMPILER_xlc -qpic=large -qnortti -qnoeh -D_REENTRANT -q64 -DCC_INTERP -g -q64 -qlanglvl=c99vla -qlanglvl=noredefmac -qsuppress=1540-0198 -qsuppress=1540-1090 -qsuppress=1500-010 -DSAFEFETCH_STUBS -DINCLUDE_TRACE -c -qmakedep=gcc -MF ../generated/dependencies/ciObject.o.d -o ciObject.o /home/spoole/repos/aix-ppc/jdk7u/hotspot/src/share/vm/ci/ciObject.cpp "/home/spoole/repos/aix-ppc/jdk7u/hotspot/src/share/vm/memory/allocation.hpp", line 112.7: 1540-0300 (S) The "private" member "class StackObj" cannot be accessed. "/home/spoole/repos/aix-ppc/jdk7u/hotspot/src/share/vm/prims/methodHandleWalk.hpp", line 272.7: 1540-0719 (I) The previous message was produced while processing the implicit member function "MethodHandleCompiler::~MethodHandleCompiler()". "/home/spoole/repos/aix-ppc/jdk7u/hotspot/src/share/vm/ci/ciMethodHandle.cpp", line 69.3: 1540-0700 (I) The previous message was produced while processing "ciMethodHandle::get_adapter_impl(bool)".
On 12 Nov 2012, at 17:32, Volker Simonis <volker.simonis@gmail.com> wrote:
Yes, and what I forgot to say:
Steve, could you please, please try with XLC 10 just to verify that besides all these C++ compiler bugs, the general build is working and is producing reasonable results. I think this is really very important such that we can finally get started with the work on the class library (for JDK 7 and 8).
Yes will do and will take your excellent testcase to the compiler guys.
Thank you and best regards, Volker
On Mon, Nov 12, 2012 at 6:28 PM, Volker Simonis <volker.simonis@gmail.com> wrote:
Hi Steve,
sorry to say it, but I'm pretty sure this is yet another XLC bug and one of the reasons why we are still tied to XLC 10 (which is a shame!). I could reproduce the error with a version of XLC 12:
IBM XL C/C++ for AIX, V12.1 (5765-J02, 5725-C72) Version: 12.01.0000.0000
Unfortunately the 12 compiler is just on a test system where I can't compile the whole JDK. But I could narrow the problem down to the following little, self contained C++ program (based on the original HotSpot sources):
/////////////////////////////////////////////private.cpp//////////////////////////////////////////////////////// class FOO { public: ~FOO() {} };
class StackObj { public: void operator delete(void* p) {} };
class MethodHandleWalker : StackObj { FOO foo; };
class MethodHandleCompiler : public MethodHandleWalker { };
int main(int argc, char* argv[]) {
{ MethodHandleCompiler mh; }
return 1; } /////////////////////////////////////////////private.cpp////////////////////////////////////////////////////////
If compiled with XLC 12, it provokes the very same error message:
xlC_r -q64 -c -o /tmp/a.out ~/Bugs/xlC/private.cpp "/sapmnt/home1/d046063/Bugs/xlC/private.cpp", line 11.28: 1540-0198 (W) The omitted keyword "private" is assumed for base class "StackObj". "/sapmnt/home1/d046063/Bugs/xlC/private.cpp", line 6.7: 1540-0300 (S) The "private" member "class StackObj" cannot be accessed. "/sapmnt/home1/d046063/Bugs/xlC/private.cpp", line 15.7: 1540-0719 (I) The previous message was produced while processing the implicit member function "MethodHandleCompiler::~MethodHandleCompiler()". "/sapmnt/home1/d046063/Bugs/xlC/private.cpp", line 18.5: 1540-0700 (I) The previous message was produced while processing "main(int, char *[])".
This code works with all other compilers we know (at least XLC 10, GCC 4, MS Visual Studio, HP aCC, Sun Studio) an I'm pretty sure that XLC 12 is wrong. The problem is that XLC claims that the "StackObj" class is not accessible from within the synthetically generated destructor of the class "MethodHandleCompiler". That is true, because "StackObj" is a private base class "MethodHandleWalker" from which "MethodHandleCompiler" inherits.
But that's not the point here! The synthetically generated destructor of the class "MethodHandleCompiler" (i.e. "MethodHandleCompiler::~MethodHandleCompiler()") only has to destruct the members of "MethodHandleCompiler" and call the destructor of its base classes. And in turn, the synthetically generated destructor of its base class "MethodHandleWalker" could access its base class "StackObj" very well!
We would be really deeply grateful if you could escalate this bug to your internal XLC compiler group colleagues. After all, the HotSpot code is more than 10 years old C++ code which doesn't use neither Exception Handling nor RTTI and only some very simple template constructs and I think this code should be correctly compilable by every reasonably decent C++ compiler nowadays.
After all, your XLC team can freely access and build the OpenJDK sources so it should be not too hard for them to reproduce this and maybe other problems.
Regards, Volker
On Mon, Nov 12, 2012 at 11:38 AM, Steve Poole <spoole@linux.vnet.ibm.com> wrote:
hi guys. The build instructions from Volker seem to work ok on my AIX machine up to a point.
Using V11 of the XLC compiler I hit a compiler bug. When I move to the latest V12 version I get this below in the build log..
Seems to be a pretty hard failure - any advice?
Cheers Steve
Compiling /home/spoole/repos/aix-ppc/jdk7u/hotspot/src/share/vm/ci/ciObject.cpp rm -f ciObject.o xlC_r -DAIX -DPPC64 -DASSERT -DDEBUG -I/home/spoole/repos/aix-ppc/jdk7u/hotspot/src/share/vm/prims -I/home/spoole/repos/aix-ppc/jdk7u/hotspot/src/share/vm -I/home/spoole/repos/aix-ppc/jdk7u/hotspot/src/share/vm/precompiled -I/home/spoole/repos/aix-ppc/jdk7u/hotspot/src/cpu/ppc/vm -I/home/spoole/repos/aix-ppc/jdk7u/hotspot/src/os_cpu/aix_ppc/vm -I/home/spoole/repos/aix-ppc/jdk7u/hotspot/src/os/aix/vm -I/home/spoole/repos/aix-ppc/jdk7u/hotspot/src/os/posix/vm -I../generated -DHOTSPOT_RELEASE_VERSION="\"23.2-b04\"" -DHOTSPOT_BUILD_TARGET="\"jvmg\"" -DHOTSPOT_BUILD_USER="\"spoole\"" -DHOTSPOT_LIB_ARCH=\"ppc64\" -DHOTSPOT_VM_DISTRO="\"OpenJDK\"" -DTARGET_OS_FAMILY_aix -DTARGET_ARCH_ppc -DTARGET_ARCH_MODEL_ppc_64 -DTARGET_OS_ARCH_aix_ppc -DTARGET_OS_ARCH_MODEL_aix_ppc_64 -DTARGET_COMPILER_xlc -qpic=large -qnortti -qnoeh -D_REENTRANT -q64 -DCC_INTERP -g -q64 -qlanglvl=c99vla -qlanglvl=noredefmac -qsuppress=1540-0198 -qsuppress=1540-1090 -qsuppress=1500-010 -DSAFEFETCH_STUBS -DINCLUDE_TRACE -c -qmakedep=gcc -MF ../generated/dependencies/ciObject.o.d -o ciObject.o /home/spoole/repos/aix-ppc/jdk7u/hotspot/src/share/vm/ci/ciObject.cpp "/home/spoole/repos/aix-ppc/jdk7u/hotspot/src/share/vm/memory/allocation.hpp", line 112.7: 1540-0300 (S) The "private" member "class StackObj" cannot be accessed. "/home/spoole/repos/aix-ppc/jdk7u/hotspot/src/share/vm/prims/methodHandleWalk.hpp", line 272.7: 1540-0719 (I) The previous message was produced while processing the implicit member function "MethodHandleCompiler::~MethodHandleCompiler()". "/home/spoole/repos/aix-ppc/jdk7u/hotspot/src/share/vm/ci/ciMethodHandle.cpp", line 69.3: 1540-0700 (I) The previous message was produced while processing "ciMethodHandle::get_adapter_impl(bool)".
And the answer is : #-- Build times ---------- Target debug_build Start 2012-11-13 14:20:19 End 2012-11-13 14:57:17 00:00:23 corba 00:00:09 hotspot 00:00:44 jaxp 00:01:43 jaxws 00:33:15 jdk 00:00:44 langtools 00:36:58 TOTAL it builds for me with AIX 7.1 and XLC 10 However I had to create links in /usr/bin for xlc_r and xlC_r back to the vac directories I didnt investigate if this was my problem or a generic one. I do know that the links are not created automatically so either my paths were wrong or the build has a expectation for the location of the compilers. On 13 Nov 2012, at 08:53, Steve Poole <spoole@linux.vnet.ibm.com> wrote:
On 12 Nov 2012, at 17:32, Volker Simonis <volker.simonis@gmail.com> wrote:
Yes, and what I forgot to say:
Steve, could you please, please try with XLC 10 just to verify that besides all these C++ compiler bugs, the general build is working and is producing reasonable results. I think this is really very important such that we can finally get started with the work on the class library (for JDK 7 and 8).
Yes will do and will take your excellent testcase to the compiler guys.
Thank you and best regards, Volker
On Mon, Nov 12, 2012 at 6:28 PM, Volker Simonis <volker.simonis@gmail.com> wrote:
Hi Steve,
sorry to say it, but I'm pretty sure this is yet another XLC bug and one of the reasons why we are still tied to XLC 10 (which is a shame!). I could reproduce the error with a version of XLC 12:
IBM XL C/C++ for AIX, V12.1 (5765-J02, 5725-C72) Version: 12.01.0000.0000
Unfortunately the 12 compiler is just on a test system where I can't compile the whole JDK. But I could narrow the problem down to the following little, self contained C++ program (based on the original HotSpot sources):
/////////////////////////////////////////////private.cpp//////////////////////////////////////////////////////// class FOO { public: ~FOO() {} };
class StackObj { public: void operator delete(void* p) {} };
class MethodHandleWalker : StackObj { FOO foo; };
class MethodHandleCompiler : public MethodHandleWalker { };
int main(int argc, char* argv[]) {
{ MethodHandleCompiler mh; }
return 1; } /////////////////////////////////////////////private.cpp////////////////////////////////////////////////////////
If compiled with XLC 12, it provokes the very same error message:
xlC_r -q64 -c -o /tmp/a.out ~/Bugs/xlC/private.cpp "/sapmnt/home1/d046063/Bugs/xlC/private.cpp", line 11.28: 1540-0198 (W) The omitted keyword "private" is assumed for base class "StackObj". "/sapmnt/home1/d046063/Bugs/xlC/private.cpp", line 6.7: 1540-0300 (S) The "private" member "class StackObj" cannot be accessed. "/sapmnt/home1/d046063/Bugs/xlC/private.cpp", line 15.7: 1540-0719 (I) The previous message was produced while processing the implicit member function "MethodHandleCompiler::~MethodHandleCompiler()". "/sapmnt/home1/d046063/Bugs/xlC/private.cpp", line 18.5: 1540-0700 (I) The previous message was produced while processing "main(int, char *[])".
This code works with all other compilers we know (at least XLC 10, GCC 4, MS Visual Studio, HP aCC, Sun Studio) an I'm pretty sure that XLC 12 is wrong. The problem is that XLC claims that the "StackObj" class is not accessible from within the synthetically generated destructor of the class "MethodHandleCompiler". That is true, because "StackObj" is a private base class "MethodHandleWalker" from which "MethodHandleCompiler" inherits.
But that's not the point here! The synthetically generated destructor of the class "MethodHandleCompiler" (i.e. "MethodHandleCompiler::~MethodHandleCompiler()") only has to destruct the members of "MethodHandleCompiler" and call the destructor of its base classes. And in turn, the synthetically generated destructor of its base class "MethodHandleWalker" could access its base class "StackObj" very well!
We would be really deeply grateful if you could escalate this bug to your internal XLC compiler group colleagues. After all, the HotSpot code is more than 10 years old C++ code which doesn't use neither Exception Handling nor RTTI and only some very simple template constructs and I think this code should be correctly compilable by every reasonably decent C++ compiler nowadays.
After all, your XLC team can freely access and build the OpenJDK sources so it should be not too hard for them to reproduce this and maybe other problems.
Regards, Volker
On Mon, Nov 12, 2012 at 11:38 AM, Steve Poole <spoole@linux.vnet.ibm.com> wrote:
hi guys. The build instructions from Volker seem to work ok on my AIX machine up to a point.
Using V11 of the XLC compiler I hit a compiler bug. When I move to the latest V12 version I get this below in the build log..
Seems to be a pretty hard failure - any advice?
Cheers Steve
Compiling /home/spoole/repos/aix-ppc/jdk7u/hotspot/src/share/vm/ci/ciObject.cpp rm -f ciObject.o xlC_r -DAIX -DPPC64 -DASSERT -DDEBUG -I/home/spoole/repos/aix-ppc/jdk7u/hotspot/src/share/vm/prims -I/home/spoole/repos/aix-ppc/jdk7u/hotspot/src/share/vm -I/home/spoole/repos/aix-ppc/jdk7u/hotspot/src/share/vm/precompiled -I/home/spoole/repos/aix-ppc/jdk7u/hotspot/src/cpu/ppc/vm -I/home/spoole/repos/aix-ppc/jdk7u/hotspot/src/os_cpu/aix_ppc/vm -I/home/spoole/repos/aix-ppc/jdk7u/hotspot/src/os/aix/vm -I/home/spoole/repos/aix-ppc/jdk7u/hotspot/src/os/posix/vm -I../generated -DHOTSPOT_RELEASE_VERSION="\"23.2-b04\"" -DHOTSPOT_BUILD_TARGET="\"jvmg\"" -DHOTSPOT_BUILD_USER="\"spoole\"" -DHOTSPOT_LIB_ARCH=\"ppc64\" -DHOTSPOT_VM_DISTRO="\"OpenJDK\"" -DTARGET_OS_FAMILY_aix -DTARGET_ARCH_ppc -DTARGET_ARCH_MODEL_ppc_64 -DTARGET_OS_ARCH_aix_ppc -DTARGET_OS_ARCH_MODEL_aix_ppc_64 -DTARGET_COMPILER_xlc -qpic=large -qnortti -qnoeh -D_REENTRANT -q64 -DCC_INTERP -g -q64 -qlanglvl=c99vla -qlanglvl=noredefmac -qsuppress=1540-0198 -qsuppress=1540-1090 -qsuppress=1500-010 -DSAFEFETCH_STUBS -DINCLUDE_TRACE -c -qmakedep=gcc -MF ../generated/dependencies/ciObject.o.d -o ciObject.o /home/spoole/repos/aix-ppc/jdk7u/hotspot/src/share/vm/ci/ciObject.cpp "/home/spoole/repos/aix-ppc/jdk7u/hotspot/src/share/vm/memory/allocation.hpp", line 112.7: 1540-0300 (S) The "private" member "class StackObj" cannot be accessed. "/home/spoole/repos/aix-ppc/jdk7u/hotspot/src/share/vm/prims/methodHandleWalk.hpp", line 272.7: 1540-0719 (I) The previous message was produced while processing the implicit member function "MethodHandleCompiler::~MethodHandleCompiler()". "/home/spoole/repos/aix-ppc/jdk7u/hotspot/src/share/vm/ci/ciMethodHandle.cpp", line 69.3: 1540-0700 (I) The previous message was produced while processing "ciMethodHandle::get_adapter_impl(bool)".
Hi Steve, what a great success!!! Congratulations:)
From your build times I suppose you used the J9 as bootstrap JDK, right? (or you must be on a really REALLY fast box).
Regarding 'xlc', I think the build only expects to find it in the PATH which was always the case on our machines. One of my colleagues just told me that "officially released" versions create these links by default while this has to be done manually for "internal versions". Regards, Volker On Tue, Nov 13, 2012 at 4:05 PM, Steve Poole <spoole@linux.vnet.ibm.com> wrote:
And the answer is :
#-- Build times ---------- Target debug_build Start 2012-11-13 14:20:19 End 2012-11-13 14:57:17 00:00:23 corba 00:00:09 hotspot 00:00:44 jaxp 00:01:43 jaxws 00:33:15 jdk 00:00:44 langtools 00:36:58 TOTAL
it builds for me with AIX 7.1 and XLC 10
However I had to create links in /usr/bin for xlc_r and xlC_r back to the vac directories I didnt investigate if this was my problem or a generic one. I do know that the links are not created automatically so either my paths were wrong or the build has a expectation for the location of the compilers.
On 13 Nov 2012, at 08:53, Steve Poole <spoole@linux.vnet.ibm.com> wrote:
On 12 Nov 2012, at 17:32, Volker Simonis <volker.simonis@gmail.com> wrote:
Yes, and what I forgot to say:
Steve, could you please, please try with XLC 10 just to verify that besides all these C++ compiler bugs, the general build is working and is producing reasonable results. I think this is really very important such that we can finally get started with the work on the class library (for JDK 7 and 8).
Yes will do and will take your excellent testcase to the compiler guys.
Thank you and best regards, Volker
On Mon, Nov 12, 2012 at 6:28 PM, Volker Simonis <volker.simonis@gmail.com> wrote:
Hi Steve,
sorry to say it, but I'm pretty sure this is yet another XLC bug and one of the reasons why we are still tied to XLC 10 (which is a shame!). I could reproduce the error with a version of XLC 12:
IBM XL C/C++ for AIX, V12.1 (5765-J02, 5725-C72) Version: 12.01.0000.0000
Unfortunately the 12 compiler is just on a test system where I can't compile the whole JDK. But I could narrow the problem down to the following little, self contained C++ program (based on the original HotSpot sources):
/////////////////////////////////////////////private.cpp//////////////////////////////////////////////////////// class FOO { public: ~FOO() {} };
class StackObj { public: void operator delete(void* p) {} };
class MethodHandleWalker : StackObj { FOO foo; };
class MethodHandleCompiler : public MethodHandleWalker { };
int main(int argc, char* argv[]) {
{ MethodHandleCompiler mh; }
return 1; } /////////////////////////////////////////////private.cpp////////////////////////////////////////////////////////
If compiled with XLC 12, it provokes the very same error message:
xlC_r -q64 -c -o /tmp/a.out ~/Bugs/xlC/private.cpp
"/sapmnt/home1/d046063/Bugs/xlC/private.cpp", line 11.28: 1540-0198 (W) The omitted keyword "private" is assumed for base class "StackObj". "/sapmnt/home1/d046063/Bugs/xlC/private.cpp", line 6.7: 1540-0300 (S) The "private" member "class StackObj" cannot be accessed. "/sapmnt/home1/d046063/Bugs/xlC/private.cpp", line 15.7: 1540-0719 (I) The previous message was produced while processing the implicit member function "MethodHandleCompiler::~MethodHandleCompiler()". "/sapmnt/home1/d046063/Bugs/xlC/private.cpp", line 18.5: 1540-0700 (I) The previous message was produced while processing "main(int, char *[])".
This code works with all other compilers we know (at least XLC 10, GCC 4, MS Visual Studio, HP aCC, Sun Studio) an I'm pretty sure that XLC 12 is wrong. The problem is that XLC claims that the "StackObj" class is not accessible from within the synthetically generated destructor of the class "MethodHandleCompiler". That is true, because "StackObj" is a private base class "MethodHandleWalker" from which "MethodHandleCompiler" inherits.
But that's not the point here! The synthetically generated destructor of the class "MethodHandleCompiler" (i.e. "MethodHandleCompiler::~MethodHandleCompiler()") only has to destruct the members of "MethodHandleCompiler" and call the destructor of its base classes. And in turn, the synthetically generated destructor of its base class "MethodHandleWalker" could access its base class "StackObj" very well!
We would be really deeply grateful if you could escalate this bug to your internal XLC compiler group colleagues. After all, the HotSpot code is more than 10 years old C++ code which doesn't use neither Exception Handling nor RTTI and only some very simple template constructs and I think this code should be correctly compilable by every reasonably decent C++ compiler nowadays.
After all, your XLC team can freely access and build the OpenJDK sources so it should be not too hard for them to reproduce this and maybe other problems.
Regards, Volker
On Mon, Nov 12, 2012 at 11:38 AM, Steve Poole <spoole@linux.vnet.ibm.com> wrote:
hi guys. The build instructions from Volker seem to work ok on my AIX machine up to a point.
Using V11 of the XLC compiler I hit a compiler bug. When I move to the latest V12 version I get this below in the build log..
Seems to be a pretty hard failure - any advice?
Cheers Steve
Compiling /home/spoole/repos/aix-ppc/jdk7u/hotspot/src/share/vm/ci/ciObject.cpp rm -f ciObject.o xlC_r -DAIX -DPPC64 -DASSERT -DDEBUG -I/home/spoole/repos/aix-ppc/jdk7u/hotspot/src/share/vm/prims -I/home/spoole/repos/aix-ppc/jdk7u/hotspot/src/share/vm -I/home/spoole/repos/aix-ppc/jdk7u/hotspot/src/share/vm/precompiled -I/home/spoole/repos/aix-ppc/jdk7u/hotspot/src/cpu/ppc/vm -I/home/spoole/repos/aix-ppc/jdk7u/hotspot/src/os_cpu/aix_ppc/vm -I/home/spoole/repos/aix-ppc/jdk7u/hotspot/src/os/aix/vm -I/home/spoole/repos/aix-ppc/jdk7u/hotspot/src/os/posix/vm -I../generated -DHOTSPOT_RELEASE_VERSION="\"23.2-b04\"" -DHOTSPOT_BUILD_TARGET="\"jvmg\"" -DHOTSPOT_BUILD_USER="\"spoole\"" -DHOTSPOT_LIB_ARCH=\"ppc64\" -DHOTSPOT_VM_DISTRO="\"OpenJDK\"" -DTARGET_OS_FAMILY_aix -DTARGET_ARCH_ppc -DTARGET_ARCH_MODEL_ppc_64 -DTARGET_OS_ARCH_aix_ppc -DTARGET_OS_ARCH_MODEL_aix_ppc_64 -DTARGET_COMPILER_xlc -qpic=large -qnortti -qnoeh -D_REENTRANT -q64 -DCC_INTERP -g -q64 -qlanglvl=c99vla -qlanglvl=noredefmac -qsuppress=1540-0198 -qsuppress=1540-1090 -qsuppress=1500-010 -DSAFEFETCH_STUBS -DINCLUDE_TRACE -c -qmakedep=gcc -MF ../generated/dependencies/ciObject.o.d -o ciObject.o /home/spoole/repos/aix-ppc/jdk7u/hotspot/src/share/vm/ci/ciObject.cpp "/home/spoole/repos/aix-ppc/jdk7u/hotspot/src/share/vm/memory/allocation.hpp", line 112.7: 1540-0300 (S) The "private" member "class StackObj" cannot be accessed. "/home/spoole/repos/aix-ppc/jdk7u/hotspot/src/share/vm/prims/methodHandleWalk.hpp", line 272.7: 1540-0719 (I) The previous message was produced while processing the implicit member function "MethodHandleCompiler::~MethodHandleCompiler()". "/home/spoole/repos/aix-ppc/jdk7u/hotspot/src/share/vm/ci/ciMethodHandle.cpp", line 69.3: 1540-0700 (I) The previous message was produced while processing "ciMethodHandle::get_adapter_impl(bool)".
My builds are somewhat bogus as I didn't do a complete build in one pass. I have one cooking now. We'll see what it says later. I am using your bootstrap build not j9. On 13 Nov 2012, at 16:41, Volker Simonis <volker.simonis@gmail.com> wrote:
Hi Steve,
what a great success!!! Congratulations:)
From your build times I suppose you used the J9 as bootstrap JDK, right? (or you must be on a really REALLY fast box).
Regarding 'xlc', I think the build only expects to find it in the PATH which was always the case on our machines. One of my colleagues just told me that "officially released" versions create these links by default while this has to be done manually for "internal versions".
Regards, Volker
On Tue, Nov 13, 2012 at 4:05 PM, Steve Poole <spoole@linux.vnet.ibm.com> wrote:
And the answer is :
#-- Build times ---------- Target debug_build Start 2012-11-13 14:20:19 End 2012-11-13 14:57:17 00:00:23 corba 00:00:09 hotspot 00:00:44 jaxp 00:01:43 jaxws 00:33:15 jdk 00:00:44 langtools 00:36:58 TOTAL
it builds for me with AIX 7.1 and XLC 10
However I had to create links in /usr/bin for xlc_r and xlC_r back to the vac directories I didnt investigate if this was my problem or a generic one. I do know that the links are not created automatically so either my paths were wrong or the build has a expectation for the location of the compilers.
On 13 Nov 2012, at 08:53, Steve Poole <spoole@linux.vnet.ibm.com> wrote:
On 12 Nov 2012, at 17:32, Volker Simonis <volker.simonis@gmail.com> wrote:
Yes, and what I forgot to say:
Steve, could you please, please try with XLC 10 just to verify that besides all these C++ compiler bugs, the general build is working and is producing reasonable results. I think this is really very important such that we can finally get started with the work on the class library (for JDK 7 and 8).
Yes will do and will take your excellent testcase to the compiler guys.
Thank you and best regards, Volker
On Mon, Nov 12, 2012 at 6:28 PM, Volker Simonis <volker.simonis@gmail.com> wrote:
Hi Steve,
sorry to say it, but I'm pretty sure this is yet another XLC bug and one of the reasons why we are still tied to XLC 10 (which is a shame!). I could reproduce the error with a version of XLC 12:
IBM XL C/C++ for AIX, V12.1 (5765-J02, 5725-C72) Version: 12.01.0000.0000
Unfortunately the 12 compiler is just on a test system where I can't compile the whole JDK. But I could narrow the problem down to the following little, self contained C++ program (based on the original HotSpot sources):
/////////////////////////////////////////////private.cpp//////////////////////////////////////////////////////// class FOO { public: ~FOO() {} };
class StackObj { public: void operator delete(void* p) {} };
class MethodHandleWalker : StackObj { FOO foo; };
class MethodHandleCompiler : public MethodHandleWalker { };
int main(int argc, char* argv[]) {
{ MethodHandleCompiler mh; }
return 1; } /////////////////////////////////////////////private.cpp////////////////////////////////////////////////////////
If compiled with XLC 12, it provokes the very same error message:
xlC_r -q64 -c -o /tmp/a.out ~/Bugs/xlC/private.cpp
"/sapmnt/home1/d046063/Bugs/xlC/private.cpp", line 11.28: 1540-0198 (W) The omitted keyword "private" is assumed for base class "StackObj". "/sapmnt/home1/d046063/Bugs/xlC/private.cpp", line 6.7: 1540-0300 (S) The "private" member "class StackObj" cannot be accessed. "/sapmnt/home1/d046063/Bugs/xlC/private.cpp", line 15.7: 1540-0719 (I) The previous message was produced while processing the implicit member function "MethodHandleCompiler::~MethodHandleCompiler()". "/sapmnt/home1/d046063/Bugs/xlC/private.cpp", line 18.5: 1540-0700 (I) The previous message was produced while processing "main(int, char *[])".
This code works with all other compilers we know (at least XLC 10, GCC 4, MS Visual Studio, HP aCC, Sun Studio) an I'm pretty sure that XLC 12 is wrong. The problem is that XLC claims that the "StackObj" class is not accessible from within the synthetically generated destructor of the class "MethodHandleCompiler". That is true, because "StackObj" is a private base class "MethodHandleWalker" from which "MethodHandleCompiler" inherits.
But that's not the point here! The synthetically generated destructor of the class "MethodHandleCompiler" (i.e. "MethodHandleCompiler::~MethodHandleCompiler()") only has to destruct the members of "MethodHandleCompiler" and call the destructor of its base classes. And in turn, the synthetically generated destructor of its base class "MethodHandleWalker" could access its base class "StackObj" very well!
We would be really deeply grateful if you could escalate this bug to your internal XLC compiler group colleagues. After all, the HotSpot code is more than 10 years old C++ code which doesn't use neither Exception Handling nor RTTI and only some very simple template constructs and I think this code should be correctly compilable by every reasonably decent C++ compiler nowadays.
After all, your XLC team can freely access and build the OpenJDK sources so it should be not too hard for them to reproduce this and maybe other problems.
Regards, Volker
On Mon, Nov 12, 2012 at 11:38 AM, Steve Poole <spoole@linux.vnet.ibm.com> wrote:
hi guys. The build instructions from Volker seem to work ok on my AIX machine up to a point.
Using V11 of the XLC compiler I hit a compiler bug. When I move to the latest V12 version I get this below in the build log..
Seems to be a pretty hard failure - any advice?
Cheers Steve
Compiling /home/spoole/repos/aix-ppc/jdk7u/hotspot/src/share/vm/ci/ciObject.cpp rm -f ciObject.o xlC_r -DAIX -DPPC64 -DASSERT -DDEBUG -I/home/spoole/repos/aix-ppc/jdk7u/hotspot/src/share/vm/prims -I/home/spoole/repos/aix-ppc/jdk7u/hotspot/src/share/vm -I/home/spoole/repos/aix-ppc/jdk7u/hotspot/src/share/vm/precompiled -I/home/spoole/repos/aix-ppc/jdk7u/hotspot/src/cpu/ppc/vm -I/home/spoole/repos/aix-ppc/jdk7u/hotspot/src/os_cpu/aix_ppc/vm -I/home/spoole/repos/aix-ppc/jdk7u/hotspot/src/os/aix/vm -I/home/spoole/repos/aix-ppc/jdk7u/hotspot/src/os/posix/vm -I../generated -DHOTSPOT_RELEASE_VERSION="\"23.2-b04\"" -DHOTSPOT_BUILD_TARGET="\"jvmg\"" -DHOTSPOT_BUILD_USER="\"spoole\"" -DHOTSPOT_LIB_ARCH=\"ppc64\" -DHOTSPOT_VM_DISTRO="\"OpenJDK\"" -DTARGET_OS_FAMILY_aix -DTARGET_ARCH_ppc -DTARGET_ARCH_MODEL_ppc_64 -DTARGET_OS_ARCH_aix_ppc -DTARGET_OS_ARCH_MODEL_aix_ppc_64 -DTARGET_COMPILER_xlc -qpic=large -qnortti -qnoeh -D_REENTRANT -q64 -DCC_INTERP -g -q64 -qlanglvl=c99vla -qlanglvl=noredefmac -qsuppress=1540-0198 -qsuppress=1540-1090 -qsuppress=1500-010 -DSAFEFETCH_STUBS -DINCLUDE_TRACE -c -qmakedep=gcc -MF ../generated/dependencies/ciObject.o.d -o ciObject.o /home/spoole/repos/aix-ppc/jdk7u/hotspot/src/share/vm/ci/ciObject.cpp "/home/spoole/repos/aix-ppc/jdk7u/hotspot/src/share/vm/memory/allocation.hpp", line 112.7: 1540-0300 (S) The "private" member "class StackObj" cannot be accessed. "/home/spoole/repos/aix-ppc/jdk7u/hotspot/src/share/vm/prims/methodHandleWalk.hpp", line 272.7: 1540-0719 (I) The previous message was produced while processing the implicit member function "MethodHandleCompiler::~MethodHandleCompiler()". "/home/spoole/repos/aix-ppc/jdk7u/hotspot/src/share/vm/ci/ciMethodHandle.cpp", line 69.3: 1540-0700 (I) The previous message was produced while processing "ciMethodHandle::get_adapter_impl(bool)".
Build times for my 100% clean build #-- Build times ---------- Target debug_build Start 2012-11-13 17:32:23 End 2012-11-13 19:07:42 00:13:05 corba 00:04:07 hotspot 00:05:08 jaxp 00:06:22 jaxws 01:01:54 jdk 00:04:43 langtools 01:35:19 TOTAL On 13 Nov 2012, at 17:08, Steve Poole <spoole@linux.vnet.ibm.com> wrote:
My builds are somewhat bogus as I didn't do a complete build in one pass. I have one cooking now. We'll see what it says later. I am using your bootstrap build not j9.
On 13 Nov 2012, at 16:41, Volker Simonis <volker.simonis@gmail.com> wrote:
Hi Steve,
what a great success!!! Congratulations:)
From your build times I suppose you used the J9 as bootstrap JDK, right? (or you must be on a really REALLY fast box).
Regarding 'xlc', I think the build only expects to find it in the PATH which was always the case on our machines. One of my colleagues just told me that "officially released" versions create these links by default while this has to be done manually for "internal versions".
Regards, Volker
On Tue, Nov 13, 2012 at 4:05 PM, Steve Poole <spoole@linux.vnet.ibm.com> wrote:
And the answer is :
#-- Build times ---------- Target debug_build Start 2012-11-13 14:20:19 End 2012-11-13 14:57:17 00:00:23 corba 00:00:09 hotspot 00:00:44 jaxp 00:01:43 jaxws 00:33:15 jdk 00:00:44 langtools 00:36:58 TOTAL
it builds for me with AIX 7.1 and XLC 10
However I had to create links in /usr/bin for xlc_r and xlC_r back to the vac directories I didnt investigate if this was my problem or a generic one. I do know that the links are not created automatically so either my paths were wrong or the build has a expectation for the location of the compilers.
On 13 Nov 2012, at 08:53, Steve Poole <spoole@linux.vnet.ibm.com> wrote:
On 12 Nov 2012, at 17:32, Volker Simonis <volker.simonis@gmail.com> wrote:
Yes, and what I forgot to say:
Steve, could you please, please try with XLC 10 just to verify that besides all these C++ compiler bugs, the general build is working and is producing reasonable results. I think this is really very important such that we can finally get started with the work on the class library (for JDK 7 and 8).
Yes will do and will take your excellent testcase to the compiler guys.
Thank you and best regards, Volker
On Mon, Nov 12, 2012 at 6:28 PM, Volker Simonis <volker.simonis@gmail.com> wrote:
Hi Steve,
sorry to say it, but I'm pretty sure this is yet another XLC bug and one of the reasons why we are still tied to XLC 10 (which is a shame!). I could reproduce the error with a version of XLC 12:
IBM XL C/C++ for AIX, V12.1 (5765-J02, 5725-C72) Version: 12.01.0000.0000
Unfortunately the 12 compiler is just on a test system where I can't compile the whole JDK. But I could narrow the problem down to the following little, self contained C++ program (based on the original HotSpot sources):
/////////////////////////////////////////////private.cpp//////////////////////////////////////////////////////// class FOO { public: ~FOO() {} };
class StackObj { public: void operator delete(void* p) {} };
class MethodHandleWalker : StackObj { FOO foo; };
class MethodHandleCompiler : public MethodHandleWalker { };
int main(int argc, char* argv[]) {
{ MethodHandleCompiler mh; }
return 1; } /////////////////////////////////////////////private.cpp////////////////////////////////////////////////////////
If compiled with XLC 12, it provokes the very same error message:
xlC_r -q64 -c -o /tmp/a.out ~/Bugs/xlC/private.cpp
"/sapmnt/home1/d046063/Bugs/xlC/private.cpp", line 11.28: 1540-0198 (W) The omitted keyword "private" is assumed for base class "StackObj". "/sapmnt/home1/d046063/Bugs/xlC/private.cpp", line 6.7: 1540-0300 (S) The "private" member "class StackObj" cannot be accessed. "/sapmnt/home1/d046063/Bugs/xlC/private.cpp", line 15.7: 1540-0719 (I) The previous message was produced while processing the implicit member function "MethodHandleCompiler::~MethodHandleCompiler()". "/sapmnt/home1/d046063/Bugs/xlC/private.cpp", line 18.5: 1540-0700 (I) The previous message was produced while processing "main(int, char *[])".
This code works with all other compilers we know (at least XLC 10, GCC 4, MS Visual Studio, HP aCC, Sun Studio) an I'm pretty sure that XLC 12 is wrong. The problem is that XLC claims that the "StackObj" class is not accessible from within the synthetically generated destructor of the class "MethodHandleCompiler". That is true, because "StackObj" is a private base class "MethodHandleWalker" from which "MethodHandleCompiler" inherits.
But that's not the point here! The synthetically generated destructor of the class "MethodHandleCompiler" (i.e. "MethodHandleCompiler::~MethodHandleCompiler()") only has to destruct the members of "MethodHandleCompiler" and call the destructor of its base classes. And in turn, the synthetically generated destructor of its base class "MethodHandleWalker" could access its base class "StackObj" very well!
We would be really deeply grateful if you could escalate this bug to your internal XLC compiler group colleagues. After all, the HotSpot code is more than 10 years old C++ code which doesn't use neither Exception Handling nor RTTI and only some very simple template constructs and I think this code should be correctly compilable by every reasonably decent C++ compiler nowadays.
After all, your XLC team can freely access and build the OpenJDK sources so it should be not too hard for them to reproduce this and maybe other problems.
Regards, Volker
On Mon, Nov 12, 2012 at 11:38 AM, Steve Poole <spoole@linux.vnet.ibm.com> wrote:
hi guys. The build instructions from Volker seem to work ok on my AIX machine up to a point.
Using V11 of the XLC compiler I hit a compiler bug. When I move to the latest V12 version I get this below in the build log..
Seems to be a pretty hard failure - any advice?
Cheers Steve
Compiling /home/spoole/repos/aix-ppc/jdk7u/hotspot/src/share/vm/ci/ciObject.cpp rm -f ciObject.o xlC_r -DAIX -DPPC64 -DASSERT -DDEBUG -I/home/spoole/repos/aix-ppc/jdk7u/hotspot/src/share/vm/prims -I/home/spoole/repos/aix-ppc/jdk7u/hotspot/src/share/vm -I/home/spoole/repos/aix-ppc/jdk7u/hotspot/src/share/vm/precompiled -I/home/spoole/repos/aix-ppc/jdk7u/hotspot/src/cpu/ppc/vm -I/home/spoole/repos/aix-ppc/jdk7u/hotspot/src/os_cpu/aix_ppc/vm -I/home/spoole/repos/aix-ppc/jdk7u/hotspot/src/os/aix/vm -I/home/spoole/repos/aix-ppc/jdk7u/hotspot/src/os/posix/vm -I../generated -DHOTSPOT_RELEASE_VERSION="\"23.2-b04\"" -DHOTSPOT_BUILD_TARGET="\"jvmg\"" -DHOTSPOT_BUILD_USER="\"spoole\"" -DHOTSPOT_LIB_ARCH=\"ppc64\" -DHOTSPOT_VM_DISTRO="\"OpenJDK\"" -DTARGET_OS_FAMILY_aix -DTARGET_ARCH_ppc -DTARGET_ARCH_MODEL_ppc_64 -DTARGET_OS_ARCH_aix_ppc -DTARGET_OS_ARCH_MODEL_aix_ppc_64 -DTARGET_COMPILER_xlc -qpic=large -qnortti -qnoeh -D_REENTRANT -q64 -DCC_INTERP -g -q64 -qlanglvl=c99vla -qlanglvl=noredefmac -qsuppress=1540-0198 -qsuppress=1540-1090 -qsuppress=1500-010 -DSAFEFETCH_STUBS -DINCLUDE_TRACE -c -qmakedep=gcc -MF ../generated/dependencies/ciObject.o.d -o ciObject.o /home/spoole/repos/aix-ppc/jdk7u/hotspot/src/share/vm/ci/ciObject.cpp "/home/spoole/repos/aix-ppc/jdk7u/hotspot/src/share/vm/memory/allocation.hpp", line 112.7: 1540-0300 (S) The "private" member "class StackObj" cannot be accessed. "/home/spoole/repos/aix-ppc/jdk7u/hotspot/src/share/vm/prims/methodHandleWalk.hpp", line 272.7: 1540-0719 (I) The previous message was produced while processing the implicit member function "MethodHandleCompiler::~MethodHandleCompiler()". "/home/spoole/repos/aix-ppc/jdk7u/hotspot/src/share/vm/ci/ciMethodHandle.cpp", line 69.3: 1540-0700 (I) The previous message was produced while processing "ciMethodHandle::get_adapter_impl(bool)".
participants (2)
-
Steve Poole
-
Volker Simonis