[prev in list] [next in list] [prev in thread] [next in thread]
List: openjdk-ppc-aix-port-dev
Subject: Building on AIX
From: spoole () linux ! vnet ! ibm ! com (Steve Poole)
Date: 2012-11-13 19:54:21
Message-ID: 4700053D-3909-4C92-9164-1DA0A10162D0 () linux ! vnet ! ibm ! com
[Download RAW message or body]
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 at 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 at 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 at 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 at linux.vnet.ibm.com> wrote:
> > >
> > >
> > > On 12 Nov 2012, at 17:32, Volker Simonis <volker.simonis at 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 at 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 at 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)".
> > >
> > >
> > >
> > >
> >
>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic