Fix for --enable-checking ICE on __extension__
Zack Weinberg
zack@wolery.cumb.org
Tue Feb 22 10:33:00 GMT 2000
On Thu, Feb 17, 2000 at 01:34:47AM -0800, Richard Henderson wrote:
> On Wed, Feb 16, 2000 at 09:35:40PM -0800, Zack Weinberg wrote:
> > Right now, any use of __extension__ will cause an ICE when
> > --enable-checking is on. The trouble is in c-parse.in which wraps up
> > an integer in a tree node for no apparent reason, and does it wrong.
> > The fix is to change it to use the <itype> field of yyval instead.
>
> Um.. perhaps it was done wrong, but you should go back and look at
>
> 2000-01-18 Martin v. L÷wis <loewis@informatik.hu-berlin.de>
>
> * c-parse.in (SAVE_WARN_FLAGS): Create an INTEGER_CST.
> (RESTORE_WARN_FLAGS): Unpack it.
> Change semantic type of extension to ttype.
> * c-common.c (split_specs_attrs): Expect an INTEGER_CST.
>
> and see if the crash Martin was seeing is still fixed.
Oops... my patch puts his crash back. Never mind.
Here's what I'm trying to solve:
$ cat test.c
__extension__
extern long long int __strtoll_internal (__const char *__restrict __nptr,
char **__restrict __endptr,
int __base, int __group);
__extension__ extern __inline long long int
strtoll (__const char *__restrict __nptr, char **__restrict __endptr,
int __base)
{
return __strtoll_internal (__nptr, __endptr, __base, 0);
}
$ ./cc1 test.c
strtoll {GC 69k -> 55k in 0.010}
test2.c:11: Tree check: expected integer_cst, have (null)
test2.c:11: Internal compiler error in `yyparse', at c-parse.y:270
Please submit a full bug report.
I'll have another look at this today.
zw
More information about the Gcc-patches
mailing list