The test trunk/gcc/testsuite/gcc.dg/large-size-array-2.c causes ICE on AVR target. /* PR c/25309 */ /* { dg-do compile } */ /* { dg-options "-O2" } */ static char * name[] = { [0x80000000] = "bar" }; /* { dg-error "too large" "" { target { { ! lp64 } && { ! llp64 } } } 6 } */ llp645503.c:2:6: error: size of array 'dummy' is negative Executing on host: /media/verbatim/gcchead/obj-dir/gcc/xgcc -B/media/verbatim/gcchead/obj-dir/gcc/ /media/verbatim/gcchead/trunk/gcc/testsuite/gcc.dg/large-size-array-2.c -O2 -DSTACK_SIZE=2048 -DNO_TRAMPOLINES -S -DSIGNAL_SUPPRESS -mmcu=atmega128 -o large-size-array-2.s (timeout = 300) /media/verbatim/gcchead/trunk/gcc/testsuite/gcc.dg/large-size-array-2.c:6:3: internal compiler error: in tree_low_cst, at tree.c:6199
This bug is still present in 4.7.0 trunk (AVR 175811). As far as I can see, it's not a target bug. But unsure about the correct component, I cose "translation" as of following stack trace: Breakpoint 1, fancy_abort (file=0x88ef420 "../../../gcc.gnu.org/trunk/gcc/tree.c", line=6510, function=0x88f0dfb "tree_low_cst") at ../../../gcc.gnu.org/trunk/gcc/diagnostic.c:893 (gdb) bt #0 fancy_abort (file=0x88ef420 "../../../gcc.gnu.org/trunk/gcc/tree.c", line=6510, function=0x88f0dfb "tree_low_cst") at ../../../gcc.gnu.org/trunk/gcc/diagnostic.c:893 #1 0x086b6681 in tree_low_cst (t=0xb7dcf3d4, pos=1) at ../../../gcc.gnu.org/trunk/gcc/tree.c:6510 #2 0x0810020c in process_init_element (value={value = 0xb7dc3ea0, original_code = STRING_CST, original_type = 0x0}, implicit=0 '\0', braced_init_obstack=0xbfffe27c) at ../../../gcc.gnu.org/trunk/gcc/c-typeck.c:8303 #3 0x0811fc17 in c_parser_initval (parser=0xb7dd5ab8, after=0x0, braced_init_obstack=0xbfffe27c) at ../../../gcc.gnu.org/trunk/gcc/c-parser.c:3894 #4 0x0811f547 in c_parser_braced_init (parser=0xb7dd5ab8, type=0xb7d4e618, nested_p=0 '\0') at ../../../gcc.gnu.org/trunk/gcc/c-parser.c:3868 #5 0x08113e5b in c_parser_declaration_or_fndef (parser=0xb7dd5ab8, fndef_ok=1 '\001', static_assert_ok=<value optimized out>, empty_ok=1 '\001', nested=0 '\0', start_attr_ok=<value optimized out>, objc_foreach_object_declaration=0x0) at ../../../gcc.gnu.org/trunk/gcc/c-parser.c:3608 #6 0x0812308a in c_parser_external_declaration (parser=0xb7dd5ab8) at ../../../gcc.gnu.org/trunk/gcc/c-parser.c:1335 #7 0x081238cb in c_parse_file () at ../../../gcc.gnu.org/trunk/gcc/c-parser.c:1223 #8 0x0816a775 in c_common_parse_file () at ../../../gcc.gnu.org/trunk/gcc/c-family/c-opts.c:1094 #9 0x084c548e in compile_file () at ../../../gcc.gnu.org/trunk/gcc/toplev.c:548 #10 0x084c754d in do_compile () at ../../../gcc.gnu.org/trunk/gcc/toplev.c:1895 #11 0x084c76c5 in toplev_main (argc=19, argv=0xbfffe544) at ../../../gcc.gnu.org/trunk/gcc/toplev.c:1967 #12 0x08183df2 in main (argc=717, argv=0x0) at ../../../gcc.gnu.org/trunk/gcc/main.c:36 (gdb)
On Mon, 4 Jul 2011, gjl at gcc dot gnu.org wrote: > As far as I can see, it's not a target bug. But unsure about the correct > component, I cose "translation" as of following stack trace: I can't see any possible reason in this stack trace for someone to think "translation" - that is, bugs in internationalization of the compiler's diagnostic output - is appropriate. The strack trace suggests a front-end bug - but a target-specific front-end bug that it will be up to people caring about relevant targets to investigate and fix if they want it fixed.
err sorry, does "c" fit better? gcc.dg/large-size-array-4.c also triggers the ICE.
tree_low_cst asserts something about the ability to represent the constant in a HOST_WIDE_INT which has a target-specific (minimal) width. In your case HOST_WIDE_INT is 32bit where indeed 0x80000000 is not positive. Now the question is what's the difference between the i686 x avr vs. the native i686 behavior? That's what you need to investigate.
Appears to be fixed somewhere between 4.6.1 and 4.6.2