Oops! fixed a typo in the summary.

Can't reproduce with
double a = __DBL_MAX__ + __FLT_MAX__;
in x86_64-linux -> x86_64-apple-darwin10 cross (not even when using precompiled header).
So, please provide preprocessed testcase, and if possible in gdb also when it fails the assertion 
p *node
p *node->value.macro
p node->value.macro->exp.tokens[0]
p node->value.macro->exp.tokens[1]
etc.

On powerpc-apple-darwin9 at revision 160627, the minimal command is

/opt/gcc/darwin_buildw/prev-gcc/xgcc -B/opt/gcc/darwin_buildw/prev-gcc/ -c -DIN_GCC_FRONTEND -g -mdynamic-no-pic -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -Wold-style-definition -Wc++-compat -fno-common -DHAVE_CONFIG_H -I. -Ijava -I../../gcc-4.6-work/gcc -I../../gcc-4.6-work/gcc/java -I../../gcc-4.6-work/include -I../../gcc-4.6-work/libcpp/include -I/sw/include -I../../gcc-4.6-work/libdecnumber -I../../gcc-4.6-work/libdecnumber/dpd -I../libdecnumber -I/sw/include -DCLOOG_PPL_BACKEND ../../gcc-4.6-work/gcc/java/jcf-dump.c

The ICE disappears if -g is removed for any optimization, it also disappears with -save-temps.

> p *node
> p *node->value.macro
> p node->value.macro->exp.tokens[0]
> p node->value.macro->exp.tokens[1]

I did not find a way to make it works (my knowledge of gdb is => NULL). The backtrace is


#0  0x00274ff4 in fancy_abort ()
#1  0x00081b94 in lazy_hex_fp_value ()
#2  0x007ce888 in enter_macro_context ()
#3  0x007cf6ac in cpp_get_token ()
#4  0x007cf8e0 in cpp_get_token_with_location ()
#5  0x0008b15c in c_lex_with_flags ()
#6  0x0003f894 in c_lex_one_token ()
#7  0x00045404 in c_parser_cast_expression ()
#8  0x00045b00 in c_parser_binary_expression ()
#9  0x00045c08 in c_parser_conditional_expression ()
#10 0x00046158 in c_parser_expr_no_commas ()
#11 0x000466c8 in c_parser_expression ()
#12 0x00046c50 in c_parser_expression_conv ()
#13 0x0004bda0 in c_parser_statement_after_labels ()
#14 0x0004cd94 in c_parser_compound_statement_nostart ()
#15 0x0004e470 in c_parser_compound_statement ()
#16 0x0004eb44 in c_parser_declaration_or_fndef ()
#17 0x000519f4 in c_parse_file ()
#18 0x000920bc in c_common_parse_file ()
#19 0x00565c50 in toplev_main ()
#20 0x00001fbc in start ()

I'll attach the preprocessed source.

Created attachment 20901 [details]
preprocessed source

Can't reproduce with cross even on that preprocessed source.
Just run
gdb ./cc1 -O2 pr44509.i
and in gdb type:
r
up
p *node
p *node->value.macro
p node->value.macro->exp.tokens[0]
p node->value.macro->exp.tokens[1]

> Just run
> gdb ./cc1 -O2 pr44509.i

The *.i files compile without ICE, see comment #3:


> The ICE disappears if -g is removed for any optimization, it also disappears
> with -save-temps.
    ^^^^^^^^^^^^^^

[karma] darwin_buildw/gcc% ../prev-gcc/cc1 -g -O2 jcf-dump.i
 __sputc isascii __istype __isctype __wcwidth isalnum isalpha isblank iscntrl isdigit isgraph islower isprint ispunct isspace isupper isxdigit toascii
...

 TOTAL                 :  11.28             2.92            15.35              21030 kB
Extra diagnostic checks enabled; compiler may run slowly.
Configure with --enable-checking=release to disable checks.

From what I can grab from the different failures, I got the impression that '/usr/include/float.h' is not properly included, but this is indeed an uneducated guess.

There should not be a /usr/include/float.h but the gcc internal header should
be included.  Please check if that is the case and/or if your /usr/include/float.h
provides defines for __DBL_MAX__ or __FLT_MAX__

> There should not be a /usr/include/float.h but the gcc internal header should
> be included.  Please check if that is the case 

I don't understand what I am supposed to do (please use baby English;-). Why did I suspect a problem with float.h? because if on x86_64-apple-darwin10.3.0 I remove -gtoggle, the ICE is replaced by an error:

[macbook] p_build/gcc% /opt/gcc/p_build/prev-gcc/xgcc -B/opt/gcc/p_build/prev-gcc/ -c -g -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -Wold-style-definition -Wc++-compat -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I../../p_work/gcc -I../../p_work/gcc/build -I../../p_work/include -I../../p_work/libcpp/include -I/opt/sw64/include -I../../p_work/libdecnumber -I../../p_work/libdecnumber/dpd -I../libdecnumber -I/opt/sw64/include -DCLOOG_PPL_BACKEND ../../p_work/gcc/genautomata.c 
In file included from /usr/include/math.h:28:0,
                 from ../../p_work/gcc/genautomata.c:117:
/usr/include/architecture/i386/math.h: In function '__inline_isnormald':
/usr/include/architecture/i386/math.h:192:166: error: '__DBL_MIN__' undeclared (first use in this function)
/usr/include/architecture/i386/math.h:192:166: note: each undeclared identifier is reported only once for each function it appears in
/usr/include/architecture/i386/math.h: In function '__inline_isnormal':
/usr/include/architecture/i386/math.h:193:177: error: invalid operands to binary << (have 'long double' and 'int')

instead of

[macbook] p_build/gcc% /opt/gcc/p_build/prev-gcc/xgcc -B/opt/gcc/p_build/prev-gcc/ -c -g -gtoggle -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -Wold-style-definition -Wc++-compat -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I../../p_work/gcc -I../../p_work/gcc/build -I../../p_work/include -I../../p_work/libcpp/include -I/opt/sw64/include -I../../p_work/libdecnumber -I../../p_work/libdecnumber/dpd -I../libdecnumber -I/opt/sw64/include -DCLOOG_PPL_BACKEND ../../p_work/gcc/genautomata.c 
In file included from /usr/include/math.h:28:0,
                 from ../../p_work/gcc/genautomata.c:117:
/usr/include/architecture/i386/math.h: In function '__inline_isnormalf':
/usr/include/architecture/i386/math.h:191:163: error: invalid operands to binary >= (have 'float' and 'double_int')
/usr/include/architecture/i386/math.h: In function '__inline_isnormald':
/usr/include/architecture/i386/math.h:192:163: error: invalid operands to binary >= (have 'double' and 'double_int')
/usr/include/architecture/i386/math.h: In function '__inline_isnormal':
/usr/include/architecture/i386/math.h:193:2: internal compiler error: Segmentation fault

> and/or if your
> /usr/include/float.h
> provides defines for __DBL_MAX__ or __FLT_MAX__

AFAICT the answer is yes also for DBL_MIN.

Can you attach all headers that get included instead of attaching preprocessed
source?  Thx.

> Can you attach all headers that get included instead of attaching preprocessed
> source?  Thx.

How am I supposed to know what are "all headers that get included"? Please assume zero knowledge from my side and provide full modi operandi.

This is a failure to manage memory type of error, and -E will never be able to grab a testcase.  I'm in the long slow process of manually trimming down a testcase, but it is slow going.  Essentially replace #include with a emacs buffer insert of that file and repeat.  Then, trim down things while ensuring it still fails.  gdb isn't happy for me, as this is a stage2 failure, not a stage1 failure, and debugging requires access to the .o files.  The values in question are 0 and 0.  If I remove a #define BLABLA_H, then the problem goes away, meaning the slightest sneeze, and this just shimmers.

Instead of spending too much time on testsuite reduction, perhaps if you could put a breakpoint on builtin_define_with_hex_fp_value where
lazy_hex_fp_values[XXX].macro is initialized (for XXX being the idx which crashes later on), see the content of what it points to and its tokens,
then put a breakpoint on lazy_hex_fp_value and see what it contains at that point, if it changed (it shouldn't), rerun and put a watchpoint on whatever actually changed in between the two to see where it gets clobbered and why.

Argh, I thought macro is allocated using _cpp_aligned_alloc, but apparently it is allocated using GC:
  if (pfile->hash_table->alloc_subobject)
    macro = (cpp_macro *) pfile->hash_table->alloc_subobject
      (sizeof (cpp_macro));
  else
    macro = (cpp_macro *) _cpp_aligned_alloc (pfile, sizeof (cpp_macro));
So lazy_hex_fp_values will need to be GTY marked.

This issue appears to be suppressed by --enable-checking=release.

powerpc64-darwin9;

failed in stage3:
In file included from /usr/include/math.h:26:0,
                 from /GCC/gcc-live-trunk/gcc/genautomata.c:117:
/usr/include/architecture/ppc/math.h: In function ‘__inline_isnormalf’:
/usr/include/architecture/ppc/math.h:216:3: internal compiler error: in lazy_hex_fp_value, at c-family/c-cppbuiltin.c:987

when I re-ran bootstrap as a single process - I noticed the following warnings:
---
number -I/GCC/gcc-live-trunk/gcc/../libdecnumber/dpd -I../libdecnumber     \
                -o build/gencondmd.o build/gencondmd.c
/GCC/gcc-live-trunk/gcc/config/rs6000/rs6000.md:5608:1: warning: implicit declaration of function ‘RS6000_RECIP_HAVE_RSQRT_P’ [-Wimplicit-function-declaration]
---
               -DBASEVER="\"4.6.0\"" /GCC/gcc-live-trunk/gcc/c-family/c-cppbuiltin.c -o c-family/c-cppbuiltin.o
/GCC/gcc-live-trunk/gcc/c-family/c-cppbuiltin.c: In function ‘builtin_define_with_hex_fp_value’:
/GCC/gcc-live-trunk/gcc/c-family/c-cppbuiltin.c:1023:7: warning: enum conversion in assignment is invalid in C++ [-Wc++-compat]
-----

See also pr44512.

Created attachment 20906 [details]
gcc46-pr44509.patch

Untested patch.

With the patch in comment #17, x86_64-apple-darwin10 bootstrapped without problem. Thanks.

Subject: Bug 44509

Author: jakub
Date: Mon Jun 14 12:30:29 2010
New Revision: 160729

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160729
Log:
	PR bootstrap/44509
	* c-config-lang.in (gtfiles): Add c-family/c-cppbuiltin.c.
	* c-family/c-cppbuiltin.c: Include gt-c-family-c-cppbuiltin.h.
	(lazy_hex_fp_values, lazy_hex_fp_value_count): Add GTY(()) markers.
	(lazy_hex_fp_value, builtin_define_with_hex_fp_value): Use
	ggc_strdup instead of xstrdup.

	* gcc.dg/pr44509.c: New test.

Added:
    trunk/gcc/testsuite/gcc.dg/pr44509.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/c-config-lang.in
    trunk/gcc/c-family/c-cppbuiltin.c
    trunk/gcc/testsuite/ChangeLog

Could the patch in comment #17 explain the following failures?

FAIL: gcc.dg/torture/builtin-math-5.c  -O0  scan-tree-dump-times original "cexpf" 2
FAIL: gcc.dg/torture/builtin-math-5.c  -O0  scan-tree-dump-times original "cexp " 2
FAIL: gcc.dg/torture/builtin-math-5.c  -O0  scan-tree-dump-times original "cexpl" 2
FAIL: gcc.dg/torture/builtin-math-5.c  -O0  scan-tree-dump-times original "cpowf" 18
FAIL: gcc.dg/torture/builtin-math-5.c  -O0  scan-tree-dump-times original "cpow " 18
FAIL: gcc.dg/torture/builtin-math-5.c  -O0  scan-tree-dump-times original "cpowl" 18

where I get respectively 1 and 17.

Fixed, sorry for the breakage.

(In reply to comment #20)
> Could the patch in comment #17 explain the following failures? ...

False alarm! AFAICT the failures where due to messed up libs for mpfr and mpc while trying to update to mpfr 3.0. Sorry for the noise.