This is GCC Bugzilla

This is GCC Bugzilla Version 2.20+

Full Text Bug Listing

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.

Fix:
no idea...

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.

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

Responsible-Changed-From-To: unassigned->rth
Responsible-Changed-Why: .

State-Changed-From-To: analyzed->closed
State-Changed-Why: http://gcc.gnu.org/ml/gcc-patches/2003-02/msg01311.html

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.