Bug 42146 - ICE in tree_low_cst
Summary: ICE in tree_low_cst
Alias: None
Product: gcc
Classification: Unclassified
Component: c (show other bugs)
Version: unknown
: P5 normal
Target Milestone: 4.6.2
Assignee: Not yet assigned to anyone
Keywords: ice-on-valid-code
Depends on:
Blocks: 42611
  Show dependency treegraph
Reported: 2009-11-22 15:46 UTC by Andy Hutchinson
Modified: 2012-03-03 14:18 UTC (History)
4 users (show)

See Also:
Host: i686-pc-linux-gnu
Target: avr-unknown-none
Known to work: 4.6.2, 4.7.0
Known to fail: 4.6.1
Last reconfirmed: 2011-07-04 14:31:29


Note You need to log in before you can comment on or make changes to this bug.
Description Andy Hutchinson 2009-11-22 15:46:57 UTC
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
Comment 1 Georg-Johann Lay 2011-07-04 14:31:29 UTC
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
Comment 2 joseph@codesourcery.com 2011-07-04 15:23:07 UTC
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 
Comment 3 Georg-Johann Lay 2011-07-04 15:27:57 UTC
err sorry, does "c" fit better?

gcc.dg/large-size-array-4.c also triggers the ICE.
Comment 4 Richard Biener 2011-07-04 15:35:45 UTC
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.
Comment 5 Georg-Johann Lay 2012-03-03 14:18:02 UTC
Appears to be fixed somewhere between 4.6.1 and 4.6.2