--- Comment #9 from rguenth at gcc dot gnu dot org 2008-12-30 10:17 ---
I expect there to be a "simple" memleak regarding to floating point constant
handling.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38666
--- Comment #8 from sergstesh at yahoo dot com 2008-12-30 00:08 ---
(In reply to comment #7)
> (In reply to comment #6)
> > My primary concern is segmentation fault, not the cases when 'gcc' can't
> > allocate enough memory and reports the problem clearly.
>
> The seg fault is most like
--- Comment #6 from sergstesh at yahoo dot com 2008-12-30 00:00 ---
(In reply to comment #5)
> The function is simply too big and we likely use most of the memory computing
> and storing the const reals. A case for closer investigation.
>
(In reply to comment #5)
> The function is sim
--- Comment #4 from sergstesh at yahoo dot com 2008-12-29 22:45 ---
Just to make sure - my OS is 32 bits SUSE-10.3, though the CPU is 64 bits
capable.
--
sergstesh at yahoo dot com changed:
What|Removed |Added
--
--- Comment #3 from sergstesh at yahoo dot com 2008-12-29 21:57 ---
No problem occurs with -O0; with -O2, -O3 'gcc' also exits gracefully:
cc1: out of memory allocating 4283978752 bytes after a total of 228749312 bytes
.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38666
--- Comment #2 from sergstesh at yahoo dot com 2008-12-29 21:53 ---
The bug is data-dependent. If inside the 'for' loop I replace all the
coefficients with 1.0, the failure is graceful:
cc1: out of memory allocating 4054207356 bytes after a total of 105562112 bytes
.
--
http://gcc.
--- Comment #1 from sergstesh at yahoo dot com 2008-12-29 21:50 ---
Created an attachment (id=17005)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17005&action=view)
'gcc_bug.i.gz' file produced by 'gcc' and 'gzip' from the input 'gcc_bug.c' one
Source with all the files included.
