Bug 241402

Summary: gcc fails to build Hoard 3.6.x
Product: [Fedora] Fedora Reporter: Quanah Gibson-Mount <quanah>
Component: gcc4Assignee: Jakub Jelinek <jakub>
Status: CLOSED CURRENTRELEASE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 4   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: 4.1.1-51.fc6 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-05-28 07:48:14 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
preprocessor source none

Description Quanah Gibson-Mount 2007-05-25 18:36:44 UTC
Description of problem:

gcc fails to build hoard with an internal compiler error.

Version-Release number of selected component (if applicable):

4.0.2

How reproducible:
Always

Steps to Reproduce:
1. Download Hoard from http://www.hoard.org/
2. make linux-gcc-x86
3. Error will occur
  
Actual results:

tlab.h:86: internal compiler error: in build_call, at cp/call.c:323
Please submit a full bug report,

Expected results:

libhoard.so would be built

Additional info:

g++ -v
Using built-in specs.
Target: i386-redhat-linuxConfigured with: ../configure --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info --enable-shared
--enable-threads=posix --enable-checking=release --with-system-zlib
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile
--enable-languages=c,c++,objc,java,f95,ada --enable-java-awt=gtk
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre
--host=i386-redhat-linuxThread model: posix
gcc version 4.0.2 20051125 (Red Hat 4.0.2-8)

cat /etc/redhat-release 
Fedora Core release 4 (Stentz)


Error output:

make[1]: Entering directory `/home/build/p4/main/ThirdParty/hoard/hoard-3.6.1.1/src'
g++ -I/usr/include/nptl -static -malign-double -pipe -march=pentium4 -O3
-finline-limit=20000 -fomit-frame-pointer -finline-functions  -DNDEBUG  -I.
-Iheaplayers -Iheaplayers/util -D_REENTRANT=1 -shared libhoard.cpp -Bsymbolic -o
libhoard.so -ldl -lpthread
tlab.h: In member function âvoid Hoard::ThreadLocalAllocationBuffer<NumBins,
getSizeClass, getClassSize, LargestObject, LocalHeapThreshold, SuperblockType,
SuperblockSize, ParentHeap>::free(void*) [with int NumBins = 55, int (*
getSizeClass)(size_t) = HL::bins<Header, 65536>::getSizeClass [with Header =
Hoard::TheHeader], size_t (* getClassSize)(int) = HL::bins<Header,
65536>::getClassSize [with Header = Hoard::TheHeader], int LargestObject = 256,
int LocalHeapThreshold = 262144, SuperblockType =
Hoard::HoardSuperblock<HL::SpinLockType, 65536, Hoard::SmallHeap>, int
SuperblockSize = 65536, ParentHeap = Hoard::HoardHeapType]â:
libhoard.cpp:139:   instantiated from here
tlab.h:86: internal compiler error: in build_call, at cp/call.c:323
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://bugzilla.redhat.com/bugzilla> for instructions.
Preprocessed source stored into /tmp/ccr6JELD.out file, please attach this to
your bugreport.
make[1]: *** [linux-gcc-x86] Error 1

Comment 1 Quanah Gibson-Mount 2007-05-25 18:36:45 UTC
Created attachment 155473 [details]
preprocessor source

Comment 2 Jakub Jelinek 2007-05-28 07:48:14 UTC
This compiles just fine with gcc-4.1.1-51.fc6 (current FC6 gcc), FC4 is no
longer supported.

Comment 3 Quanah Gibson-Mount 2007-05-29 16:51:41 UTC
Yes, I'm quite aware that it works on later releases.  Amazing that RH was able
to break GCC, since 4.0.2 can build Hoard just fine on other distros.

Comment 4 Jakub Jelinek 2007-05-29 17:11:14 UTC
Same or similar snapshot date?  You know, 4.0.2 magic number doesn't mean much,
there has been almost 6 months in between 4.0.2 and 4.0.3 releases and some
distros call already anything starting with 4.0.1 + 1day 4.0.2.  This is far
more probably an upstream bug, either fixed after 20051125 or newly introduced
before that, especially given that the above looks like C++ frontend bug and
branches/redhat/gcc-4_0-branch didn't have any gcc/cp/ changes from
branches/gcc-4_0-branch it tracked.