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 10/30/14, 9:07 AM, Andreas Arnez wrote:
> On Sat, Oct 25 2014, Sandra Loosemore wrote:
> 
>> 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.  :-(
> 
> The warnings appear in our S390 testing as well, so I've been working on
> a fix already, as announced here:
> 
>   https://sourceware.org/ml/gdb-testers/2014-q4/msg00037.html
> 
> In the meantime I've completed a patch set; maybe you'd like to check
> that it does fix the warnings on NIOS2:
> 
>   https://sourceware.org/ml/gdb-patches/2014-10/msg00802.html
> 
>>
>> 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).
> 
> AFAIK there's no need to support pre-C89 compilers that can't handle
> function prototypes.  GDB itself can't be compiled with such a compiler,
> and many GDB test cases wouldn't work either.
> 
> --
> Andreas

I looked at your patch, but haven't replied because I'm still waffling
about it.

In theory, GDB could be handed an executable that was built in 1988 and
most debugging actions would work.  In practice, the old executable is
unlikely to run on any modern hardware, and we've already decided not to
expend much effort to support old hardware.

Where things are a little murkier is K&R-style source code.  There was a
lot out there at one time, but most (all?) maintained sources have been
converted sometime in the intervening quarter-century.

Perhaps the thing to do is pose this as a trivia quiz - what K&R sources
are still being built and debugged on today's systems?

Stan
stan@codesourcery.com



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