Bug 241402 - gcc fails to build Hoard 3.6.x
gcc fails to build Hoard 3.6.x
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: gcc4 (Show other bugs)
4
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-05-25 14:36 EDT by Quanah Gibson-Mount
Modified: 2007-11-30 17:12 EST (History)
0 users

See Also:
Fixed In Version: 4.1.1-51.fc6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-05-28 03:48:14 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
preprocessor source (434.43 KB, text/plain)
2007-05-25 14:36 EDT, Quanah Gibson-Mount
no flags Details

  None (edit)
Description Quanah Gibson-Mount 2007-05-25 14:36:44 EDT
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 14:36:45 EDT
Created attachment 155473 [details]
preprocessor source
Comment 2 Jakub Jelinek 2007-05-28 03:48:14 EDT
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 12:51:41 EDT
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 13:11:14 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.