This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: ICE in change_address at emit_rtl.c
- From: mike stump <mrs at windriver dot com>
- To: gdr at codesourcery dot com, zack at codesourcery dot com
- Cc: gcc at gcc dot gnu dot org, mark at codesourcery dot com, neil at daikokuya dot demon dot co dot uk
- Date: Sat, 24 Nov 2001 21:13:11 -0800 (PST)
- Subject: Re: ICE in change_address at emit_rtl.c
> Date: Sat, 24 Nov 2001 16:41:55 -0800
> From: Zack Weinberg <zack@codesourcery.com>
> To: Gabriel Dos Reis <gdr@codesourcery.com>
> 2. As few spurious errors reported to the user as possible. This is
> one place where ERROR_MARK_NODE really falls down. Consider these
> ill-formed declarations:
> double int number;
> typedef struct foo foo_t[;
> These will both provoke error cascades in the current compiler,
?
double int number;
int maif() {
number = 1;
number1 = 1;
}
seems to do the right thing?
> mainly because 'number' and 'foo_t' don't get entered into the
> symbol table, so we issue errors every time they are used, even if
> the use would have been valid given a valid declaration.
> For instance,
> inline int foo(void) { syntax error; }
> should become "extern int foo(void);" for purpose of further processing.
It already does:
double int number;
void maif() {
number = 1;
number1 = 1;
}
void sdf() {
syntax error
}
void mae() {
int a = sdf();
}
terr.c:1: two or more data types in declaration of `number'
terr.c: In function `maif':
terr.c:5: `number1' undeclared (first use in this function)
terr.c:5: (Each undeclared identifier is reported only once
terr.c:5: for each function it appears in.)
terr.c: In function `sdf':
terr.c:9: `syntax' undeclared (first use in this function)
terr.c:9: parse error before "error"
terr.c: In function `mae':
terr.c:13: void value not ignored as it ought to be
Did I construct a testcase that was too simple?