User account creation filtered due to spam.

Bug 8068 - [3.2/3.3 regression] exceedingly high (infinite) memory usage
Summary: [3.2/3.3 regression] exceedingly high (infinite) memory usage
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: c (show other bugs)
Version: 2.96
: P1 critical
Target Milestone: ---
Assignee: Richard Henderson
URL:
Keywords: ice-on-valid-code
Depends on:
Blocks:
 
Reported: 2002-09-27 00:46 UTC by laurent.deniau
Modified: 2008-05-28 12:37 UTC (History)
2 users (show)

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


Attachments
gcc-bug.c (319 bytes, application/octet-stream)
2003-05-21 15:16 UTC, laurent.deniau
Details

Note You need to log in before you can comment on or make changes to this bug.
Description laurent.deniau 2002-09-27 00:46:02 UTC
The code attached crashes gcc and g++ release >= 2.96 with
any optimization option (including -O0).
If we change the addition ('+') by an xor ('^') into the
macro STATICHASHSTR32_ then all the releases compile
it with success and provide the correct result. The problem
is not comming from cpp since -E gives the right expanded
output and as noticed into the gcc message, the problem is
comming from cc1. We haven't found any bug report about
this problem.

Release:
GCC 2.96 and 3.x release

Environment:
Various i386 linux platform using GCC 2.91, 2.95.2, 2.96,
3.0.4, 3.1 and 3.2.

How-To-Repeat:
try to compile the attached code... Warning, this will use
block/slow down your system during 10-30 seconds since all
the memory will be used.
Comment 1 laurent.deniau 2002-09-27 00:46:02 UTC
Fix:
no idea...
Comment 2 Wolfgang Bangerth 2002-11-27 08:04:14 UTC
State-Changed-From-To: open->analyzed
State-Changed-Why: Confirmed. This is a regression w.r.t. 2.95 which compiled
    this just fine. Present 3.2.1 and 3.3 are eating up
    memory and an extraordinarily high rate and seemingly 
    unboundedly. I don't know whether the compile can finish,
    but several 100 MB for such a simple code is way too much
    anyway.
Comment 3 Nathanael C. Nerode 2003-01-01 10:23:51 UTC
From: Nathanael Nerode <neroden@twcny.rr.com>
To: Laurent.Deniau@cern.ch, Ovidiu.Achim@cern.ch, gcc-gnats@gcc.gnu.org,
   gcc-bugs@gcc.gnu.org, nobody@gcc.gnu.org
Cc:  
Subject: Re: c++/8068
Date: Wed, 1 Jan 2003 10:23:51 -0500

 I did a gdb backtrace on this.
 
 There's a very dense recursion going on.
 
 #49 0x0812b1b1 in fold (expr=0x64e2c020) at ../../gcc/gcc/fold-const.c:5505
 #50 0x0812513e in extract_muldiv (t=0x455b1de0, c=0x5fa18020, code=MULT_EXPR,
     wide_type=0x0) at ../../gcc/gcc/fold-const.c:4304
 #51 0x08124c75 in extract_muldiv (t=0x4a9c6ee0, c=0x5fa18020, code=MULT_EXPR,
     wide_type=0x0) at ../../gcc/gcc/fold-const.c:4179
 #52 0x0812b1b1 in fold (expr=0x5fa18040) at ../../gcc/gcc/fold-const.c:5505
 ...
 These three entries are repeated over and over and over again.  The one in 
 'fold' is the entry point.
 
 So this is a (near?) infinite recursion in the constant folding code.  Ick.
 
 The top of the backtrace is:
 
 #55 0x0812b1b1 in fold (expr=0x551ef060) at ../../gcc/gcc/fold-const.c:5505
 #56 0x0807a441 in build_binary_op (code=MULT_EXPR, orig_op0=0x551ef020,
     orig_op1=0x551ef040, convert_p=1) at ../../gcc/gcc/c-typeck.c:2579
 #57 0x08078860 in parser_build_binary_op (code=MULT_EXPR, arg1=0x551ef020,
     arg2=0x551ef040) at ../../gcc/gcc/c-typeck.c:1755
 #58 0x0804ab30 in yyparse () at c-parse.y:540
 #59 0x08063cbd in c_common_parse_file (set_yydebug=0)
     at ../../gcc/gcc/c-lex.c:161
 #60 0x0825fc86 in compile_file () at ../../gcc/gcc/toplev.c:2128
 #61 0x08264bb6 in do_compile () at ../../gcc/gcc/toplev.c:5352
 #62 0x08264c0f in toplev_main (argc=3, argv=0xbffffbf4)
     at ../../gcc/gcc/toplev.c:5382
 #63 0x080ab6b4 in main (argc=3, argv=0xbffffbf4) at ../../gcc/gcc/main.c:37
 
 Hope this helps...
Comment 4 Richard Henderson 2003-02-16 08:30:17 UTC
Responsible-Changed-From-To: unassigned->rth
Responsible-Changed-Why: .
Comment 5 Richard Henderson 2003-02-16 08:30:17 UTC
State-Changed-From-To: analyzed->closed
State-Changed-Why: http://gcc.gnu.org/ml/gcc-patches/2003-02/msg01311.html
Comment 6 Alexander Carmeli 2008-05-28 12:37:37 UTC
Richard,

This is the root cause of the problem: I agree with you that an overflow can occur and there is no way to guarantee the resulting value.

However, it must be a 32-bit value.

It cannot all of a sudden become a 64-bit value, and that's the violation of the standard that I see.

Alex.