Re: GCC switch to C11 causes many testsuite compiler diagnostics

[Doug Evans <dje@google.com>]

On Fri, Oct 31, 2014 at 12:23 PM, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
>> Date: Fri, 31 Oct 2014 12:02:11 -0700
>> From: Doug Evans <dje@google.com>
>>
>> On Thu, Oct 30, 2014 at 9:23 AM, Andreas Arnez <arnez@linux.vnet.ibm.com> wrote:
>> > On Sat, Oct 25 2014, Mark Kettenis wrote:
>> >
>> >>> Date: Sat, 25 Oct 2014 11:03:34 -0600
>> >>> From: Sandra Loosemore <sandra@codesourcery.com>
>> >>>
>> >>> Comparing my latest nios2 test results (with Pedro's thread patch) with
>> >>> those from a checkout a couple weeks old, I noticed I had some new
>> >>> ERRORs due to apparent compilation failures.  I tracked this down to the
>> >>> recent change on GCC mainline (r216247) to make the default C dialect
>> >>> GNU11, which enables -Wimplicit-int and -Wimplicit-function-declaration
>> >>> by default.  I started working on a patch to fix the offending
>> >>> testcases, but realized that there are hundreds of them.  :-(
>> >>>
>> >>> So, before I invest a lot more time on this, is updating the GDB
>> >>> testsuite to use a more modern C dialect the Right Thing To Do?  I'm
>> >>> also wondering if it's really necessary to support compilers that can't
>> >>> handle function prototypes in the testsuite (not defining PROTOTYPES
>> >>> seems to be the default, in fact).
>> >>
>> >> We've quite deliberately kept around a variety of C dialects and
>> >> coding styles to make sure GDB works with whatever style people use.
>> >> Having the majority of the tests use K&R style function declarations
>> >> is probably not so useful anymore.  But there are some tests that
>> >> deliberately use K&_R style code to test whether GDB handles them
>> >> properly.  So blind conversion is probably not a good idea.
>> >
>> > Do you know off hand which tests deliberately use K&R style code?  Maybe
>> > you'd like to verify that none of them is deleted by this patch series:
>> >
>> >   https://sourceware.org/ml/gdb-patches/2014-10/msg00802.html
>>
>> fwiw, I think this is the way to proceed.
>>
>> Find/pick a few tests that are explicitly for K&R, mark them as such,
>> and move on.
>> Life's short and there are so many vastly more important things to do than
>> worry about losing some K&R coverage.  If an issue turns up, we'll have
>> real data to support a real K&R test.
>
> FWIW, those that explicitly and unconditionally use "set prototypes 0"
> are deliberately testing K&R stuff.  And it would probably make sense
> to run callfuncs.exp in both modes on all platforms.

Ah, righto.

Can we migrate all other tests?