Bug 22392 - Huge memory usage and infinite(?) loop with -fno-enforce-eh-specs
Summary: Huge memory usage and infinite(?) loop with -fno-enforce-eh-specs
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: rtl-optimization (show other bugs)
Version: 4.0.2
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: compile-time-hog, memory-hog
Depends on:
Blocks: 20826
  Show dependency treegraph
 
Reported: 2005-07-10 12:00 UTC by Debian GCC Maintainers
Modified: 2007-04-28 14:21 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments
Test case (200.21 KB, application/octet-stream)
2005-07-10 12:01 UTC, Debian GCC Maintainers
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Debian GCC Maintainers 2005-07-10 12:00:41 UTC
[ forwarded from http://bugs.debian.org/317563 ]

The test case chews up 789m of memory and then doesn't seem to progress
for at least 10 minutes with -O2 -fno-enforce-eh-specs. Functions showing up
prominently in a profile are:

samples  %        symbol name
34188    22.3480  bitmap_set_bit
18170    11.8774  free_deps
17475    11.4231  sched_analyze_insn
14018     9.1633  alloc_INSN_LIST
10173     6.6499  free_list
6100      3.9874  free_INSN_LIST_list
3946      2.5794  bitmap_bit_p
2442      1.5963  build_tree_conflict_graph

With just -O2, it finishes in 1:09 minute using 341m. With g++ 4.1, it finishes
in 1:21 using 148m even with -fno-enforce-eh-specs. g++-3.4 doesn't like this
test case.

This is on alphaev68-linux. The original report was on powerpc.
Comment 1 Debian GCC Maintainers 2005-07-10 12:01:40 UTC
Created attachment 9237 [details]
Test case
Comment 2 Andrew Pinski 2005-07-10 18:12:28 UTC
This is the scheduler messing up which is normal with big BBs.
Comment 3 Andrew Pinski 2005-07-25 01:53:03 UTC
I think this is the same bug as PR 20826.
Comment 4 Falk Hueffner 2007-04-28 14:21:07 UTC
Not a problem in 4.1 anymore, so let's close it.