Bug 28385 - g++ -O hangs while compiling file
g++ -O hangs while compiling file
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: gcc (Show other bugs)
7.0
i386 Linux
high Severity high
: ---
: ---
Assigned To: Jakub Jelinek
David Lawrence
:
: 31937 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-02-19 23:56 EST by David Baron
Modified: 2005-10-31 17:00 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-02-21 16:23:47 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
nsStyleContext.ii - preprocessed source (428.62 KB, text/plain)
2001-02-19 23:57 EST, David Baron
no flags Details

  None (edit)
Description David Baron 2001-02-19 23:56:41 EST
As of this afternoon, g++ hangs while compiling nsStyleContext.cpp in the
Mozilla tree with -O2.  I'll attach the preprocessed output to make for
easy testing.  Given nsStyleContext.ii that I will attach, the command

c++ -c -o nsStyleContext.o -O2 nsStyleContext.ii

hangs, while the command

c++ -c -o nsStyleContext.o nsStyleContext.ii

works correctly.

I'm seeing this with gcc-2.96-70 and -O2.  tor reports the same problem
with gcc-2.96-74 and -O (rather than -O2).  mao reports it with
gcc-2.96-69.
Comment 1 David Baron 2001-02-19 23:57:44 EST
Created attachment 10440 [details]
nsStyleContext.ii - preprocessed source
Comment 2 Jakub Jelinek 2001-02-20 06:36:31 EST
Thanks. Actually, CVS head hangs on this as well.
The culprit is:
inline void CalcSidesFor(const nsIFrame* aFrame, const nsStyleSides& aSides,
                         PRUint8 aSpacing,
                         const nscoord* aEnumTable, PRInt32 aNumEnums,
                         nsMargin& aResult)
{
  nsStyleCoord coord;

  aResult.left = CalcSideFor(aFrame, aSides.GetLeft(coord), aSpacing, 3,
                             aEnumTable, aNumEnums);
  aResult.top = CalcSideFor(aFrame, aSides.GetTop(coord), aSpacing, 0,
                            aEnumTable, aNumEnums);
  aResult.right = CalcSideFor(aFrame, aSides.GetRight(coord), aSpacing, 1,
                              aEnumTable, aNumEnums);
  aResult.bottom = CalcSideFor(aFrame, aSides.GetBottom(coord), aSpacing, 2,
                               aEnumTable, aNumEnums);
}
and the tree based inlining for some reason does not limit itself in doing
further and further inlines of itself in this case (because CalcSideFor indirectly
calls CalcSidesFor). I'll try to simplify it first.
Comment 3 Akkana 2001-02-20 15:18:36 EST
With -O (not O3) and with gcc-2.96-54, it takes a long time, and finally gives
up with:
Cannot allocate 892625676 bytes after allocating 16260924 bytes
Comment 4 Jakub Jelinek 2001-02-20 15:22:17 EST
I've narrowed it down to a 3K testcase and it really does not hang, it just
does a lot of inlining and eats gobs of memory (if I remove one of the 4
routines for inlining, it actually succeeds on my 256MB box, otherwise I never
had the patience to let it finish). I hope I'll know more tomorrow.
Comment 5 Christopher Blizzard 2001-02-21 15:16:59 EST
Any movement on this?  It's a real killer.
Comment 6 Jakub Jelinek 2001-02-21 16:23:43 EST
Yes, I think I've fixed this by:
http://gcc.gnu.org/ml/gcc-patches/2001-02/msg01310.html
Mark Mitchell approved it, if Jason Merrill does not have anything
against it until tomorrow, I'll commit it and will include it into
gcc-c++-2.96-76.
Comment 7 David Baron 2001-02-23 14:25:32 EST
Are you committing the patch to both the gcc trunk and the gcc 3.0 branch?  I
sure hope this is fixed in gcc 3.0 also.
Comment 8 Jakub Jelinek 2001-02-23 15:42:54 EST
Sure, I've commited it to both branch and head.
Comment 9 Jakub Jelinek 2001-03-16 05:36:24 EST
*** Bug 31937 has been marked as a duplicate of this bug. ***

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