public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c/16852] New: cc1 fails attempting to allocate too much memory
@ 2004-08-02 5:08 lucier at math dot purdue dot edu
2004-08-03 6:50 ` [Bug rtl-optimization/16852] " pinskia at gcc dot gnu dot org
` (8 more replies)
0 siblings, 9 replies; 10+ messages in thread
From: lucier at math dot purdue dot edu @ 2004-08-02 5:08 UTC (permalink / raw)
To: gcc-bugs
gcc -I../include -no-cpp-precomp -Wall -W -Wno-unused -O1 -fno-math-errno
-fschedule-insns2 -fno-trapping-math -fno-strict-aliasing -fomit-frame-pointer
-fPIC -fno-common -g -save-temps -save-temps -DHAVE_CONFIG_H -c _t-c-1.c
gcc: unrecognized option `-no-cpp-precomp'
*** malloc: vm_allocate(size=1990995968) failed (error code=3)
*** malloc[5586]: error: Can't allocate region
cc1: out of memory allocating 1990994304 bytes after a total of 0 bytes
make[1]: *** [_t-c-1.o] Error 1
make: *** [all] Error 1
[descartes:~/programs/gambc40b4-devel] lucier% gcc -v
Reading specs from /pkgs/gcc-mainline/lib/gcc/powerpc-apple-darwin7.4.0/3.5.0/specs
Configured with: ../configure --prefix=/pkgs/gcc-mainline
Thread model: posix
gcc version 3.5.0 20040730 (experimental)
The input file is at
http://www.math.purdue.edu/~lucier/GNATS/GNATS-11/_t-c-1.i.gz
--
Summary: cc1 fails attempting to allocate too much memory
Product: gcc
Version: 3.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: lucier at math dot purdue dot edu
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: powerpc-apple-darwin7.4.0
GCC host triplet: powerpc-apple-darwin7.4.0
GCC target triplet: powerpc-apple-darwin7.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16852
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug rtl-optimization/16852] cc1 fails attempting to allocate too much memory
2004-08-02 5:08 [Bug c/16852] New: cc1 fails attempting to allocate too much memory lucier at math dot purdue dot edu
@ 2004-08-03 6:50 ` pinskia at gcc dot gnu dot org
2004-08-03 6:51 ` pinskia at gcc dot gnu dot org
` (7 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2004-08-03 6:50 UTC (permalink / raw)
To: gcc-bugs
--
What |Removed |Added
----------------------------------------------------------------------------
Component|c |rtl-optimization
Keywords| |ice-on-valid-code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16852
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug rtl-optimization/16852] cc1 fails attempting to allocate too much memory
2004-08-02 5:08 [Bug c/16852] New: cc1 fails attempting to allocate too much memory lucier at math dot purdue dot edu
2004-08-03 6:50 ` [Bug rtl-optimization/16852] " pinskia at gcc dot gnu dot org
@ 2004-08-03 6:51 ` pinskia at gcc dot gnu dot org
2004-08-03 6:56 ` pinskia at gcc dot gnu dot org
` (6 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2004-08-03 6:51 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From pinskia at gcc dot gnu dot org 2004-08-03 06:51 -------
#0 0x9002b9bc in exit ()
#1 0x0040cbd4 in xexit (code=1) at /Users/apinski/src/devel/clean/gcc/libiberty/xexit.c:52
#2 0x004021c4 in xmalloc_failed (size=1990994304) at /Users/apinski/src/devel/clean/gcc/
libiberty/xmalloc.c:132
#3 0x00402254 in xcalloc (nelem=248874288, elsize=8) at /Users/apinski/src/devel/clean/gcc/
libiberty/xmalloc.c:161
#4 0x00343904 in global_alloc (file=0x0) at /Users/apinski/src/devel/clean/gcc/gcc/global.c:527
#5 0x001f64e8 in rest_of_compilation () at /Users/apinski/src/devel/clean/gcc/gcc/passes.c:693
#6 0x001f74a0 in execute_pass_list (pass=0x57234c) at /Users/apinski/src/devel/clean/gcc/gcc/
tree-optimize.c:453
#7 0x001f76f8 in tree_rest_of_compilation (fndecl=0x7e0380, nested_p=0 '\0') at /Users/apinski/src/
devel/clean/gcc/gcc/tree-optimize.c:556
#8 0x0001c2d8 in c_expand_body (fndecl=0x7e0380) at /Users/apinski/src/devel/clean/gcc/gcc/c-
decl.c:6377
#9 0x001e499c in cgraph_expand_function (node=0xd92080) at /Users/apinski/src/devel/clean/gcc/
gcc/cgraphunit.c:801
#10 0x001e4b64 in cgraph_assemble_pending_functions () at /Users/apinski/src/devel/clean/gcc/gcc/
cgraphunit.c:296
#11 0x001e5368 in cgraph_finalize_function (decl=0x7e0380, nested=0 '\0') at /Users/apinski/src/
devel/clean/gcc/gcc/cgraphunit.c:377
#12 0x0001c500 in c_finalize (fndecl=0x7e0380) at /Users/apinski/src/devel/clean/gcc/gcc/c-decl.c:
6247
#13 0x0001cb08 in finish_function () at /Users/apinski/src/devel/clean/gcc/gcc/c-decl.c:6349
#14 0x000047d0 in yyparse () at c-parse.y:368
#15 0x0000896c in c_parse_file () at c-parse.y:2966
#16 0x0004fd80 in c_common_parse_file (set_yydebug=1) at /Users/apinski/src/devel/clean/gcc/gcc/
c-opts.c:1090
#17 0x0008ea1c in toplev_main (argc=5693780, argv=0x41502540) at /Users/apinski/src/devel/
clean/gcc/gcc/toplev.c:981
#18 0x000020c8 in _start (argc=14, argv=0xbffff9d5, envp=0xbffffa11) at /SourceCache/Csu/
Csu-49/crt.c:268
#19 0x00001f3c in start ()
(gdb) up
#1 0x0040cbd4 in xexit (code=1) at /Users/apinski/src/devel/clean/gcc/libiberty/xexit.c:52
52 exit (code);
(gdb)
#2 0x004021c4 in xmalloc_failed (size=1990994304) at /Users/apinski/src/devel/clean/gcc/
libiberty/xmalloc.c:132
132 xexit (1);
(gdb)
#3 0x00402254 in xcalloc (nelem=248874288, elsize=8) at /Users/apinski/src/devel/clean/gcc/
libiberty/xmalloc.c:161
161 xmalloc_failed (nelem * elsize);
(gdb)
#4 0x00343904 in global_alloc (file=0x0) at /Users/apinski/src/devel/clean/gcc/gcc/global.c:527
527 conflicts = xcalloc (max_allocno * allocno_row_words, sizeof (INT_TYPE));
(gdb) l
522 allocno_row_words = (max_allocno + INT_BITS - 1) / INT_BITS;
523
524 /* We used to use alloca here, but the size of what it would try to
525 allocate would occasionally cause it to exceed the stack limit and
526 cause unpredictable core dumps. Some examples were > 2Mb in size. */
527 conflicts = xcalloc (max_allocno * allocno_row_words, sizeof (INT_TYPE));
528
529 allocnos_live = xmalloc (allocno_row_words * sizeof (INT_TYPE));
530
531 /* If there is work to be done (at least one reg to allocate),
(gdb) p max_allocno
$1 = <unknown type>
(gdb) p allocno_row_words
$2 = <unknown type>
(gdb) p (int)allocno_row_words
$3 = 1972
(gdb) p (int)max_allocno
$4 = 126204
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16852
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug rtl-optimization/16852] cc1 fails attempting to allocate too much memory
2004-08-02 5:08 [Bug c/16852] New: cc1 fails attempting to allocate too much memory lucier at math dot purdue dot edu
2004-08-03 6:50 ` [Bug rtl-optimization/16852] " pinskia at gcc dot gnu dot org
2004-08-03 6:51 ` pinskia at gcc dot gnu dot org
@ 2004-08-03 6:56 ` pinskia at gcc dot gnu dot org
2004-08-03 23:34 ` lucier at math dot purdue dot edu
` (5 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2004-08-03 6:56 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From pinskia at gcc dot gnu dot org 2004-08-03 06:56 -------
This is failing when allocating the registers.
Seems like there are a large number of code in this function.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16852
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug rtl-optimization/16852] cc1 fails attempting to allocate too much memory
2004-08-02 5:08 [Bug c/16852] New: cc1 fails attempting to allocate too much memory lucier at math dot purdue dot edu
` (2 preceding siblings ...)
2004-08-03 6:56 ` pinskia at gcc dot gnu dot org
@ 2004-08-03 23:34 ` lucier at math dot purdue dot edu
2004-08-05 6:33 ` [Bug rtl-optimization/16852] [3.5 Regression] " pinskia at gcc dot gnu dot org
` (4 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: lucier at math dot purdue dot edu @ 2004-08-03 23:34 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From lucier at math dot purdue dot edu 2004-08-03 23:34 -------
Subject: Re: cc1 fails attempting to allocate too much memory
On Tuesday, August 3, 2004, at 01:56 AM, pinskia at gcc dot gnu dot
org wrote:
> Seems like there are a large number of code in this function.
Well, yes, but it worked on June 19 when I filed this unrelated bug
report:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16088
Brad
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16852
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug rtl-optimization/16852] [3.5 Regression] cc1 fails attempting to allocate too much memory
2004-08-02 5:08 [Bug c/16852] New: cc1 fails attempting to allocate too much memory lucier at math dot purdue dot edu
` (3 preceding siblings ...)
2004-08-03 23:34 ` lucier at math dot purdue dot edu
@ 2004-08-05 6:33 ` pinskia at gcc dot gnu dot org
2004-09-01 4:13 ` lucier at math dot purdue dot edu
` (3 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2004-08-05 6:33 UTC (permalink / raw)
To: gcc-bugs
--
What |Removed |Added
----------------------------------------------------------------------------
Summary|cc1 fails attempting to |[3.5 Regression] cc1 fails
|allocate too much memory |attempting to allocate too
| |much memory
Target Milestone|--- |3.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16852
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug rtl-optimization/16852] [3.5 Regression] cc1 fails attempting to allocate too much memory
2004-08-02 5:08 [Bug c/16852] New: cc1 fails attempting to allocate too much memory lucier at math dot purdue dot edu
` (4 preceding siblings ...)
2004-08-05 6:33 ` [Bug rtl-optimization/16852] [3.5 Regression] " pinskia at gcc dot gnu dot org
@ 2004-09-01 4:13 ` lucier at math dot purdue dot edu
2004-09-01 4:34 ` pinskia at gcc dot gnu dot org
` (2 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: lucier at math dot purdue dot edu @ 2004-09-01 4:13 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From lucier at math dot purdue dot edu 2004-09-01 04:13 -------
With commands like this:
cvs update -D "July 22, 2004"
I found that the example program compiled on July 20 and didn't on July 24.
Bootstrap failed on July 22.
I'll work on this more later.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16852
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug rtl-optimization/16852] [3.5 Regression] cc1 fails attempting to allocate too much memory
2004-08-02 5:08 [Bug c/16852] New: cc1 fails attempting to allocate too much memory lucier at math dot purdue dot edu
` (5 preceding siblings ...)
2004-09-01 4:13 ` lucier at math dot purdue dot edu
@ 2004-09-01 4:34 ` pinskia at gcc dot gnu dot org
2004-09-01 18:12 ` lucier at math dot purdue dot edu
2004-09-08 19:45 ` pinskia at gcc dot gnu dot org
8 siblings, 0 replies; 10+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2004-09-01 4:34 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From pinskia at gcc dot gnu dot org 2004-09-01 04:34 -------
Hmm, the only thing major that went into between those days were Deigo's aliasing changes (and
some cleanups which should not have any effect on code generation at all).
Which was:
2004-07-22 Diego Novillo <dnovillo@redhat.com>
* tree-into-ssa.c (set_livein_block): Fix typo in comment.
(rewrite_ssa_into_ssa): Start iterating over SSA names at 1.
Release SSA names that have been re-renamed.
....
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16852
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug rtl-optimization/16852] [3.5 Regression] cc1 fails attempting to allocate too much memory
2004-08-02 5:08 [Bug c/16852] New: cc1 fails attempting to allocate too much memory lucier at math dot purdue dot edu
` (6 preceding siblings ...)
2004-09-01 4:34 ` pinskia at gcc dot gnu dot org
@ 2004-09-01 18:12 ` lucier at math dot purdue dot edu
2004-09-08 19:45 ` pinskia at gcc dot gnu dot org
8 siblings, 0 replies; 10+ messages in thread
From: lucier at math dot purdue dot edu @ 2004-09-01 18:12 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From lucier at math dot purdue dot edu 2004-09-01 18:12 -------
Subject: Re: [3.5 Regression] cc1 fails attempting to allocate too much memory
It worked on July 23, and didn't work on July 24.
Brad
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16852
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug rtl-optimization/16852] [3.5 Regression] cc1 fails attempting to allocate too much memory
2004-08-02 5:08 [Bug c/16852] New: cc1 fails attempting to allocate too much memory lucier at math dot purdue dot edu
` (7 preceding siblings ...)
2004-09-01 18:12 ` lucier at math dot purdue dot edu
@ 2004-09-08 19:45 ` pinskia at gcc dot gnu dot org
8 siblings, 0 replies; 10+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2004-09-08 19:45 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From pinskia at gcc dot gnu dot org 2004-09-08 19:45 -------
Fixed.
--
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution| |FIXED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16852
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2004-09-08 19:45 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-08-02 5:08 [Bug c/16852] New: cc1 fails attempting to allocate too much memory lucier at math dot purdue dot edu
2004-08-03 6:50 ` [Bug rtl-optimization/16852] " pinskia at gcc dot gnu dot org
2004-08-03 6:51 ` pinskia at gcc dot gnu dot org
2004-08-03 6:56 ` pinskia at gcc dot gnu dot org
2004-08-03 23:34 ` lucier at math dot purdue dot edu
2004-08-05 6:33 ` [Bug rtl-optimization/16852] [3.5 Regression] " pinskia at gcc dot gnu dot org
2004-09-01 4:13 ` lucier at math dot purdue dot edu
2004-09-01 4:34 ` pinskia at gcc dot gnu dot org
2004-09-01 18:12 ` lucier at math dot purdue dot edu
2004-09-08 19:45 ` pinskia at gcc dot gnu dot org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).