'compilation failure using gcc 4.7.2'

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-hotspot-runtime-dev
Subject:    compilation failure using gcc 4.7.2
From:       david.r.chase () oracle ! com (David Chase)
Date:       2012-11-30 15:42:11
Message-ID: D3AEFD26-0369-49D6-9FF4-A212B5A24145 () oracle ! com
[Download RAW message or body]

You might try --with-extra-cxx-flags=-fpermissive, since it is a C++ problem, not a C \
problem, and maybe the scripts are that picky with their flags.

HOWEVER, when I tried this using gcc 4.8 (because it is what I had handy, and it \
showed the same problem when I tried it) I got a different failure with

Compiling /Users/dr2chase/work/hotspot-comp/hotspot/src/share/vm/memory/blockOffsetTable.cpp
 Assembling /Users/dr2chase/work/hotspot-comp/hotspot/src/os_cpu/bsd_x86/vm/bsd_x86_64.s
 Compiling /Users/dr2chase/work/hotspot-comp/hotspot/src/share/vm/opto/buildOopMap.cpp
 /Users/dr2chase/work/hotspot-comp/hotspot/src/os_cpu/bsd_x86/vm/bsd_x86_64.s:24:Rest \
of line ignored. 1st junk character valued 40 ((). \
/Users/dr2chase/work/hotspot-comp/hotspot/src/os_cpu/bsd_x86/vm/bsd_x86_64.s:25:Rest \
of line ignored. 1st junk character valued 40 ((). \
/Users/dr2chase/work/hotspot-comp/hotspot/src/os_cpu/bsd_x86/vm/bsd_x86_64.s:26:Rest \
of line ignored. 1st junk character valued 40 (().

etc.

Line 24 of that file is:
#ifdef __APPLE__
which contains no instances of "(" (character 40), so I am somewhat puzzled.

This was on a Mac running Mountain Lion, everything latest.latest, but also with gcc \
4.8 instead of the stock 4.2

I tried --with-extra-cflags=-fpermissive instead, and got the same result.

If you have a few minutes to spend you might try the cxx flag, but with 4.7, and see \
if you get a happier result.

David


On 2012-11-30, at 9:45 AM, BILL PITTORE <bill.pittore at oracle.com> wrote:

> Not familiar enough with the new build system to comment on that. As to it still \
> failing, I wonder if the gcc doc is incorrect?  Have not actually tried this \
> myself. 
> bill
> 
> 
> 
> On 11/30/2012 7:48 AM, Peter Levart wrote:
> > On 11/15/2012 04:04 PM, BILL PITTORE wrote:
> > > Looks like this behavior is called out in the 4.7.2 manual as a "Known cause of \
> > > trouble with GCC"; section 11.8.2 in the 4.7.2 manual. Using the -fpermissive \
> > > flag forces gcc to older more permissive behavior. 
> > > bill
> > 
> > Hi Bill,
> > 
> > Do you know where to put this option in the new build system?
> > 
> > I tried with:
> > 
> > ../autoconf/configure --with-extra-cflags=-fpermissive
> > 
> > and I noticed it gets put into some makefiles:
> > 
> > ./build/linux-x86_64-normal-server-release/hotspot-spec.gmk:
> > 
> > EXTRA_CFLAGS=-fpermissive
> > 
> > ./build/linux-x86_64-normal-server-release/spec.gmk:
> > 
> > # using 'configure --with-extra-cflags=-fpermissive'
> > CFLAGS_JDKLIB:=  -W -Wall -Wno-unused -Wno-parentheses -pipe                      \
> > -D_GNU_SOURCE -D_REENTRANT -D_LARGEFILE64_SOURCE -fno-omit-frame-pointer \
> > -D_LP64=1 -D_LITTLE_ENDIAN -DLINUX -DNDEBUG -DARCH='"amd64"' -Damd64 \
> > -DRELEASE='"1.8.0-internal"' \
> > -I/home/peter/work/hg/jdk8-tl/build/linux-x86_64-normal-server-release/jdk/include \
> > -I/home/peter/work/hg/jdk8-tl/build/linux-x86_64-normal-server-release/jdk/include/linux \
> > -I/home/peter/work/hg/jdk8-tl/jdk/src/share/javavm/export \
> > -I/home/peter/work/hg/jdk8-tl/jdk/src/solaris/javavm/export \
> > -I/home/peter/work/hg/jdk8-tl/jdk/src/share/native/common \
> > -I/home/peter/work/hg/jdk8-tl/jdk/src/solaris/native/common -fpermissive \
> > -fno-strict-aliasing -fPIC CFLAGS_JDKEXE:=  -W -Wall -Wno-unused -Wno-parentheses \
> > -pipe                           -D_GNU_SOURCE -D_REENTRANT -D_LARGEFILE64_SOURCE \
> > -fno-omit-frame-pointer -D_LP64=1 -D_LITTLE_ENDIAN -DLINUX -DNDEBUG \
> > -DARCH='"amd64"' -Damd64 -DRELEASE='"1.8.0-internal"' \
> > -I/home/peter/work/hg/jdk8-tl/build/linux-x86_64-normal-server-release/jdk/include \
> > -I/home/peter/work/hg/jdk8-tl/build/linux-x86_64-normal-server-release/jdk/include/linux \
> > -I/home/peter/work/hg/jdk8-tl/jdk/src/share/javavm/export \
> > -I/home/peter/work/hg/jdk8-tl/jdk/src/solaris/javavm/export \
> > -I/home/peter/work/hg/jdk8-tl/jdk/src/share/native/common \
> > -I/home/peter/work/hg/jdk8-tl/jdk/src/solaris/native/common -fpermissive \
> > -fno-strict-aliasing 
> > 
> > ... but I still get this error.
> > 
> > Regards, Peter
> > 
> > > 
> > > 
> > > 
> > > On 11/14/2012 11:39 PM, David Holmes wrote:
> > > > On 15/11/2012 2:13 PM, Coleen Phillimore wrote:
> > > > > 
> > > > > David,
> > > > > 
> > > > > I think adding this-> to these is the best way to fix these, and we've
> > > > > been fixing similar bugs the same way. I don't think anyone preferred
> > > > > adding "using" directives, at least for this sort of compilation error.
> > > > 
> > > > That should have been debated when 7172226 was fixed. Personally I think \
> > > > adding this-> all over the place is a PITA, particularly as each tweak of gcc \
> > > > seems to add a need for more of them in more places. 
> > > > > I'm not sure why the compilation error exists. It seems that the
> > > > > compiler should be able to resolve these calls with the same template
> > > > > instantiation as the function, but I guess not.
> > > > 
> > > > I'm not going to even try and guess what a C++ compiler might or might not be \
> > > > able to do :) But yes it seems natural to me that given foo() the first place \
> > > > you look for foo() is in "this" :( But I'm not a compiler writer. ;-) 
> > > > Cheers,
> > > > David
> > > > 
> > > > > 
> > > > > Coleen
> > > > > 
> > > > > On 11/4/2012 5:28 PM, David Holmes wrote:
> > > > > > Hi Peter,
> > > > > > 
> > > > > > I think we have lost some changes through the NPG integration. This
> > > > > > code was updated by Mikael Gerdin under:
> > > > > > 
> > > > > > 7172226: HotSpot fails to build with GCC 4.7 because of stricter c++
> > > > > > argument dependent lookup
> > > > > > 
> > > > > > http://hg.openjdk.java.net/jdk8/jdk8/hotspot/diff/a297b0e14605/src/share/vm/memory/binaryTreeDictionary.cpp \
> > > > > >  
> > > > > > 
> > > > > > but the NPG changes by Jon under
> > > > > > 
> > > > > > 7045397: NPG: Add freelists to class loader arenas
> > > > > > 
> > > > > > http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/685df3c6f84b
> > > > > > 
> > > > > > http://hg.openjdk.java.net/jdk8/jdk8/hotspot/diff/685df3c6f84b/src/share/vm/memory/binaryTreeDictionary.cpp \
> > > > > >  
> > > > > > 
> > > > > > seems to have undone those changes in part.
> > > > > > 
> > > > > > The preferred fix was to add "using" directives rather than writing
> > > > > > fully-qualified names.
> > > > > > 
> > > > > > David
> > > > > > 
> > > > > > On 5/11/2012 7:09 AM, Peter Levart wrote:
> > > > > > > Hi,
> > > > > > > 
> > > > > > > Current head of jdk8/hotspot repository (3790:4d37eb50b9b1) can not be
> > > > > > > built with gcc 4.7.2.
> > > > > > > 
> > > > > > > I had to make the following changes to compile with gcc 4.7.2 (on
> > > > > > > linux):
> > > > > > > 
> > > > > > > 
> > > > > > > diff -r 4d37eb50b9b1 src/share/vm/memory/binaryTreeDictionary.cpp
> > > > > > > --- a/src/share/vm/memory/binaryTreeDictionary.cpp Thu Nov 01 14:11:16
> > > > > > > 2012 -0700
> > > > > > > +++ b/src/share/vm/memory/binaryTreeDictionary.cpp Sun Nov 04 22:07:29
> > > > > > > 2012 +0100
> > > > > > > @@ -239,7 +239,7 @@
> > > > > > > } else {
> > > > > > > if (nextTC == NULL) {
> > > > > > > // Removing chunk at tail of list
> > > > > > > - link_tail(prevFC);
> > > > > > > + this->link_tail(prevFC);
> > > > > > > }
> > > > > > > // Chunk is interior to the list
> > > > > > > prevFC->link_after(nextTC);
> > > > > > > @@ -296,7 +296,7 @@
> > > > > > > 
> > > > > > > Chunk_t* fc = tail();
> > > > > > > fc->link_after(chunk);
> > > > > > > - link_tail(chunk);
> > > > > > > + this->link_tail(chunk);
> > > > > > > 
> > > > > > > assert(!tail() || size() == tail()->size(), "Wrong sized chunk in
> > > > > > > list");
> > > > > > > FreeList_t<Chunk_t>::increment_count();
> > > > > > > @@ -323,7 +323,7 @@
> > > > > > > chunk->link_after(fc);
> > > > > > > } else {
> > > > > > > assert(tail() == NULL, "List is inconsistent");
> > > > > > > - link_tail(chunk);
> > > > > > > + this->link_tail(chunk);
> > > > > > > }
> > > > > > > head()->link_after(chunk);
> > > > > > > assert(!head() || size() == head()->size(), "Wrong sized chunk in
> > > > > > > list");
> > > > > > > @@ -940,7 +940,7 @@
> > > > > > > void do_tree(TreeList<Chunk_t, FreeList_t>* tl) {
> > > > > > > if (tl != NULL) {
> > > > > > > do_tree(tl->left());
> > > > > > > - do_list(tl);
> > > > > > > + this->do_list(tl);
> > > > > > > do_tree(tl->right());
> > > > > > > }
> > > > > > > }
> > > > > > > @@ -952,7 +952,7 @@
> > > > > > > void do_tree(TreeList<Chunk_t, FreeList_t>* tl) {
> > > > > > > if (tl != NULL) {
> > > > > > > do_tree(tl->right());
> > > > > > > - do_list(tl);
> > > > > > > + this->do_list(tl);
> > > > > > > do_tree(tl->left());
> > > > > > > }
> > > > > > > }
> > > > > > > @@ -1008,7 +1008,7 @@
> > > > > > > bool do_tree(TreeList<Chunk_t, FreeList_t>* tl) {
> > > > > > > if (tl != NULL) {
> > > > > > > if (do_tree(tl->left())) return true;
> > > > > > > - if (do_list(tl)) return true;
> > > > > > > + if (this->do_list(tl)) return true;
> > > > > > > if (do_tree(tl->right())) return true;
> > > > > > > }
> > > > > > > return false;
> > > > > > > @@ -1022,7 +1022,7 @@
> > > > > > > bool do_tree(TreeList<Chunk_t, FreeList_t>* tl) {
> > > > > > > if (tl != NULL) {
> > > > > > > if (do_tree(tl->right())) return true;
> > > > > > > - if (do_list(tl)) return true;
> > > > > > > + if (this->do_list(tl)) return true;
> > > > > > > if (do_tree(tl->left())) return true;
> > > > > > > }
> > > > > > > return false;
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > Regards, Peter
> > > > > > > 
> > > > > 
> > > 
> > > 
> > 
> 
> 


[prev in list] [next in list] [prev in thread] [next in thread]
Configure | About | News | Add a list | Sponsored by KoreLogic