User account creation filtered due to spam.
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
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.
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
From: Nathanael Nerode <email@example.com>
To: Laurent.Deniau@cern.ch, Ovidiu.Achim@cern.ch, firstname.lastname@example.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)
#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)
#63 0x080ab6b4 in main (argc=3, argv=0xbffffbf4) at ../../gcc/gcc/main.c:37
Hope this helps...
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.