$ cat t.i int i[2]; $ gcc-c4x t.i t.i:1: error: size of array `i' is too large $ gcc-c4x gcc-c4x (GCC) 3.5.0 20040718 (experimental) Seems like this pretty much inhibits real-world use of this compiler :-) It was suggested that this is libcpp using HOST_WIDE_INT, but I've put the bug in `target' for now anyway until we understand the problem better.
Zack you had said that libcpp should not dependent on HOST_WIDE_INT, here is the bug filed for that since it effects C4x. Confirmed.
Any news on this bug, it has been opened for a while now (4 months) and no news about it.
libcpp no longer uses HOST_WIDE_INT. The computation which leads to the error is done in c-decl.c in "target arithmetic" as follows: /* Compute the maximum valid index, that is, size - 1. Do the calculation in index_type, so that if it is a variable the computations will be done in the proper mode. */ itype = fold (build2 (MINUS_EXPR, index_type, convert (index_type, size), convert (index_type, size_one_node))); /* If that overflowed, the array is too big. ??? While a size of INT_MAX+1 technically shouldn't cause an overflow (because we subtract 1), the overflow is recorded during the conversion to index_type, before the subtraction. Handling this case seems like an unnecessary complication. */ if (TREE_OVERFLOW (itype)) { error ("size of array %qs is too large", name); type = error_mark_node; continue; } This looks OK. Steven, can you possibly check to see whether this bug still exists in mainline?
Yes libcpp still uses HOST_WIDE_INT: include/cpplib.h:typedef unsigned HOST_WIDE_INT cpp_num_part; plus we use cpp_num_part all over the place in libcpp.
But again ways this is now fixed.
Have you actually verified that this is fixed?
Reopening until someone builds a C4x compiler and test it first-hand.
Yes I did verify it was fixed: [zhivago:gcc/objdir-c4x/gcc] pinskia% cat t.c int i[2]; [zhivago:gcc/objdir-c4x/gcc] pinskia% ./cc1 -version t.c GNU C version 4.0.0 20041126 (experimental) (c4x-unknown-elf) compiled by GNU C version 3.3 20030304 (Apple Computer, Inc. build 1495). GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 options passed: options enabled: -falign-loops -fargument-alias -fbranch-count-reg -fcommon -feliminate-unused-debug-types -ffinite-math-only -ffunction-cse -fgcse-lm -fident -fivopts -fkeep-static-consts -fleading-underscore -floop-optimize2 -fpeephole -freg-struct-return -fsched-interblock -fsched-spec -fsched-stalled-insns-dep -fsplit-ivs-in-unroller -ftree-loop-im -ftree-loop-ivcanon -ftree-loop-optimize -funsafe-math-optimizations -fvar-tracking -fzero-initialized-in-bss -mrptb -m40 -mparallel-insns -mparallel-mpy -maliases Execution times (seconds) parser : 0.01 (33%) usr 0.00 ( 0%) sys 0.02 (10%) wall symout : 0.00 ( 0%) usr 0.01 (25%) sys 0.01 ( 5%) wall TOTAL : 0.03 0.04 0.21 Extra diagnostic checks enabled; compiler may run slowly. Configure with --disable-checking to disable checks.
Subject: Re: [4.0 Regression] C4x fails miserably I have no plans to do anything about this bug. Someone who cares about C4x should look at it. zw