[Bug preprocessor/16621] [4.0 Regression] C4x fails miserably

[zack at codesourcery dot com]

--- Additional Comments From zack at codesourcery dot com  2004-11-27 20:25 
---
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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16621

[Bug preprocessor/16621] [4.0 Regression] C4x fails miserably

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-27 
20:14 ---
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.

-- 
   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16621

[Bug preprocessor/16621] [4.0 Regression] C4x fails miserably

[giovannibajo at libero dot it]

--- Additional Comments From giovannibajo at libero dot it  2004-11-27 
20:13 ---
Reopening until someone builds a C4x compiler and test it first-hand.

-- 
   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16621

[Bug preprocessor/16621] [4.0 Regression] C4x fails miserably

[steven at gcc dot gnu dot org]

--- Additional Comments From steven at gcc dot gnu dot org  2004-11-27 
20:10 ---
Have you actually verified that this is fixed?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16621

[Bug preprocessor/16621] [4.0 Regression] C4x fails miserably

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-27 
19:15 ---
But again ways this is now fixed.

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16621

[Bug preprocessor/16621] [4.0 Regression] C4x fails miserably

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-27 
19:13 ---
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.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16621

[Bug preprocessor/16621] [4.0 Regression] C4x fails miserably

[neroden at gcc dot gnu dot org]

--- Additional Comments From neroden at gcc dot gnu dot org  2004-11-27 
18:44 ---
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? 

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16621

[Bug preprocessor/16621] [4.0 Regression] C4x fails miserably

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-27 
00:36 ---
Any news on this bug, it has been opened for a while now (4 months) and no news 
about it.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16621