This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GCC switch to C11 causes many testsuite compiler diagnostics


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]