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

See Also:
Known to work:
Known to fail:
Last reconfirmed:

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

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.

GCC 2.96 and 3.x release

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

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
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
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
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

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.