Florian Weimer <fwei...@redhat.com> writes:
> * 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.
Right. The issues with anything Bison (and friends) were usually missing
declarations because of the header dependencies. Nothing intrinsic.
In fact, I can't even remember anything where Bison et. al generated
bad code purely by virtue of the version (even though sometimes comments
would suggest that, I never found any evidence for it, and it was
always the fault of the project itself which we'd then fix).
So, not worried.
>
> 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
