Richard Sandiford <richard.sandif...@linaro.org> writes: > Jan Hubicka <hubi...@ucw.cz> writes: >> the problem is sign overflow in time computation. Time should be >> capped by MAX_TIME and we compute MAX_TIME * INLINE_SIZE_SCALE * >> 2. This happens to be >2^31 & <2^32 so we overflow here because of use >> of signed arithmetics. >> >> Index: ipa-inline-analysis.c >> =================================================================== >> --- ipa-inline-analysis.c (revision 179266) >> +++ ipa-inline-analysis.c (working copy) >> @@ -92,7 +92,7 @@ along with GCC; see the file COPYING3. >> /* Estimate runtime of function can easilly run into huge numbers with many >> nested loops. Be sure we can compute time * INLINE_SIZE_SCALE in >> integer. >> For anything larger we use gcov_type. */ >> -#define MAX_TIME 1000000 >> +#define MAX_TIME 500000 >> >> /* Number of bits in integer, but we really want to be stable across >> different >> hosts. */ > > Could you update the comment too? ("time * INLINE_SIZE_SCALE * 2")
OK, I did it myself. Tested on x86_64-linux-gnu and applied as obvious. Richard gcc/ * ipa-inline-analysis.c (MAX_TIME): Update comment. Index: gcc/ipa-inline-analysis.c =================================================================== --- gcc/ipa-inline-analysis.c 2011-10-03 09:10:21.000000000 +0100 +++ gcc/ipa-inline-analysis.c 2011-10-03 09:10:55.633044417 +0100 @@ -90,8 +90,8 @@ Software Foundation; either version 3, o #include "alloc-pool.h" /* Estimate runtime of function can easilly run into huge numbers with many - nested loops. Be sure we can compute time * INLINE_SIZE_SCALE in integer. - For anything larger we use gcov_type. */ + nested loops. Be sure we can compute time * INLINE_SIZE_SCALE * 2 in an + integer. For anything larger we use gcov_type. */ #define MAX_TIME 500000 /* Number of bits in integer, but we really want to be stable across different