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.