Bug 11944 - [3.3/3.4 Regression] Error recovery problem with undeclared array bounds
Summary: [3.3/3.4 Regression] Error recovery problem with undeclared array bounds
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: c (show other bugs)
Version: 3.4.0
: P2 minor
Target Milestone: 3.4.0
Assignee: Andrew Pinski
URL:
Keywords: error-recovery, ice-on-invalid-code, monitored, patch
Depends on:
Blocks:
 
Reported: 2003-08-16 09:03 UTC by Falk Hueffner
Modified: 2004-01-17 04:22 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2003-12-24 18:30:26


Attachments
patch to c-common.c (372 bytes, patch)
2003-12-23 10:51 UTC, Andrew Pinski
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Falk Hueffner 2003-08-16 09:03:17 UTC
falk@juist:/tmp% cat test.c       
void f(int const[foo]);

falk@juist:/tmp% gcc -v -c -O3 test.c 
Reading specs from
/usr/local/stow/gcc-2003.08.08/bin/../lib/gcc/alphaev68-unknown-linux-gnu/3.4/specs
Configured with: ../configure --disable-nls --enable-languages=c :
(reconfigured) ../configure --disable-nls --enable-languages=c++
Thread model: posix
gcc version 3.4 20030808 (experimental)
 /usr/local/stow/gcc-2003.08.08/bin/../libexec/gcc/alphaev68-unknown-linux-gnu/3.4/cc1 -quiet -v -iprefix /usr/local/stow/gcc-2003.08.08/bin/../lib/gcc/alphaev68-unknown-linux-gnu/3.4/ test.c -quiet -dumpbase test.c -mcpu=ev67 -auxbase test -O3 -version -o /tmp/ccqADKby.s
ignoring nonexistent directory
"/usr/local/stow/gcc-2003.08.08/bin/../lib/gcc/alphaev68-unknown-linux-gnu/3.4/../../../../alphaev68-unknown-linux-gnu/include"
ignoring nonexistent directory "NONE/include"
ignoring duplicate directory
"/usr/local/lib/gcc/alphaev68-unknown-linux-gnu/3.4/include"
ignoring nonexistent directory
"/usr/local/lib/gcc/alphaev68-unknown-linux-gnu/3.4/../../../../alphaev68-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/stow/gcc-2003.08.08/bin/../lib/gcc/alphaev68-unknown-linux-gnu/3.4/include
 /usr/local/include
 /usr/include
End of search list.
GNU C version 3.4 20030808 (experimental) (alphaev68-unknown-linux-gnu)
        compiled by GNU C version 3.4 20030808 (experimental).
GGC heuristics: --param ggc-min-expand=64 --param ggc-min-heapsize=64064
test.c:1: error: `foo' undeclared here (not in a function)
test.c:1: internal compiler error: tree check: expected class 't', have 'x'
(error_mark) in get_qualified_type, at tree.c:2850
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.
Comment 1 Andrew Pinski 2003-08-16 13:00:36 UTC
I can confirm it on the mainline (20030815).


From Phil's regression hunter: Search converges between 2001-06-03-trunk (#22) and 2001-06-
10-trunk (#23).
Comment 2 Mark Mitchell 2003-10-16 09:28:19 UTC
Postponed until GCC 3.3.3.
Comment 3 Andrew Pinski 2003-10-19 22:18:21 UTC
Postponing to 3.4 because this is an error recovery problem and most likely there will not 
a 3.3.3 release.
Comment 4 Volker Reichelt 2003-12-08 23:49:51 UTC
Well, I dunno whether this is really a regression.
All release versions of the compiler do ICE :-(
Comment 5 Mark Mitchell 2003-12-16 17:19:55 UTC
According to Volker, this is not a regression, so I have removed the target
milestone.
Comment 6 Andrew Pinski 2003-12-20 20:23:25 UTC
It is a regression but not of any released versions though, targeting 3.5.0 then.
Comment 7 Andrew Pinski 2003-12-23 10:50:04 UTC
Here is the backtrace:
#0  0x000a12d0 in build_type_copy (type=0x40bba2c0) at /Volumes/UFS_Partition/
pinskia/src/fsf/gcc-clean/src/gcc/tree.c:2946
#1  0x000a124c in build_qualified_type (type=0x40bba2c0, type_quals=1) at /Volumes/
UFS_Partition/pinskia/src/fsf/gcc-clean/src/gcc/tree.c:2925
#2  0x0003ffd0 in c_build_qualified_type (type=0x40bba2c0, type_quals=1) at /Volumes/
UFS_Partition/pinskia/src/fsf/gcc-clean/src/gcc/c-common.c:2801
#3  0x0001c870 in grokdeclarator (declarator=0x0, declspecs=0x40d43228, 
decl_context=PARM, initialized=0, width=0x0) at /Volumes/UFS_Partition/pinskia/src/fsf/
gcc-clean/src/gcc/c-decl.c:4332
#4  0x000195d8 in push_parm_decl (parm=0x40d432b8) at /Volumes/UFS_Partition/
pinskia/src/fsf/gcc-clean/src/gcc/c-decl.c:3026
#5  0x00008938 in yyparse () at c-parse.y:2457
#6  0x0000a2b0 in c_parse_file () at c-parse.y:3037
#7  0x0005aa20 in c_common_parse_file (set_yydebug=0) at /Volumes/UFS_Partition/
pinskia/src/fsf/gcc-clean/src/gcc/c-opts.c:1216
#8  0x000f0ec8 in compile_file () at /Volumes/UFS_Partition/pinskia/src/fsf/gcc-clean/src/
gcc/toplev.c:1804
#9  0x000f74f4 in do_compile () at /Volumes/UFS_Partition/pinskia/src/fsf/gcc-clean/src/
gcc/toplev.c:4594
#10 0x000f75d8 in toplev_main (argc=14, argv=0xbffffbc0) at /Volumes/UFS_Partition/
pinskia/src/fsf/gcc-clean/src/gcc/toplev.c:4634
#11 0x00089c14 in main (argc=14, argv=0xbffffbc0) at /Volumes/UFS_Partition/pinskia/
src/fsf/gcc-clean/src/gcc/main.c:35

The line it is dying on (m is NULL, type is error_mark_node):
2946      TYPE_NEXT_VARIANT (t) = TYPE_NEXT_VARIANT (m);

I have a fix I think that will fix this.
Comment 8 Andrew Pinski 2003-12-23 10:51:35 UTC
Created attachment 5360 [details]
patch to c-common.c

This patch should fix it but I have not tested it yet.
Comment 9 Andrew Pinski 2003-12-23 19:30:13 UTC
I have a patch so take over.
Comment 10 Andrew Pinski 2003-12-23 19:32:06 UTC
Easy enough fix for 3.4.
Comment 11 Andrew Pinski 2003-12-24 17:40:58 UTC
My patch fixes it. will submit it soon.
Comment 12 Andrew Pinski 2003-12-24 18:30:26 UTC
Patch here: <http://gcc.gnu.org/ml/gcc-patches/2003-12/msg02052.html>
Comment 13 Andrew Pinski 2003-12-25 16:23:27 UTC
Fixed for 3.4.