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