* Eric Gallager:
>> diff --git a/gcc/testsuite/gcc.c-torture/compile/20080910-1.c
>> b/gcc/testsuite/gcc.c-torture/compile/20080910-1.c
>> index bf32775d401..911fb562790 100644
>> --- a/gcc/testsuite/gcc.c-torture/compile/20080910-1.c
>> +++ b/gcc/testsuite/gcc.c-torture/compile/20080910-1.c
>> @@ -1,5 +1,6 @@
>> /* This used to crash IRA with -O3 -fPIC.
>> See PR 37333. */
>> +/* { dg-additional-options "-fpermissive" } */
>> struct yy_buffer_state {
>> int yy_is_interactive;
>> };
>
> The fact that this one appears to be based on a scanner generated by
> flex gives me pause. Is code from flex/yacc/bison going to need
> -fpermissive in general, or is this just because it was generated by
> an old version? If it's only old versions that generate code requiring
> -fpermissive, when exactly did they stop doing that?
It can be a bit tricky to get bison, flex, and automake to work
together. The inter-dependencies can be challenging, and apparently
it's difficult to teach automake that generating a lexer or parser
produces both the implementation C file and a header file. There's a
fairly generic way to deal with this: write a custom header that
contains the necessary function declarations and include it everywhere.
It's not as elegant as using the generated headers, but that can be
difficult depending on the build system.
However, the problems with this test case aren't related to that. For
example, yy_fatal_error is undefined, but is a static function in the
code generated by flex. The test case has been preprocessed (that's how
_IO_getc got there), and the declarations from system headers have been
removed.
Thanks,
Florian
