This is the mail archive of the
mailing list for the GCC project.
Re: [RFC PATCH] diagnose built-in declarations without prototype (PR 83656)
- From: Jeff Law <law at redhat dot com>
- To: Martin Sebor <msebor at gmail dot com>, Jakub Jelinek <jakub at redhat dot com>
- Cc: Gcc Patch List <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 5 Jul 2018 13:44:22 -0600
- Subject: Re: [RFC PATCH] diagnose built-in declarations without prototype (PR 83656)
- References: <email@example.com> <firstname.lastname@example.org> <20180627152728.GB7166@tucnak> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org>
On 07/04/2018 11:32 AM, Martin Sebor wrote:
> On 07/03/2018 08:33 PM, Jeff Law wrote:
>>> But since the number of warnings here hasn't changed, the ones
>>> in GCC logs predate my changes. So updating the tests seems
>>> like an improvement to consider independently of the patch.
>> Agreed. I'm still wary of proceeding given the general concerns about
>> configure tests. It's good that GCC's configury bits aren't affected,
>> but I'm not sure we can generalize a whole lot from that.
> So what's the next step? I'm open to relaxing the warning
> so it only triggers with -Wall or -Wextra and not by default
> if that's considered necessary.
I'm not sure :-) The problem is we have notable potential to break
things and do so in ways that are going to be painful to find.
Having them only turn on for -Wextra might be an compromise position.
But even if we do that I don't really see how we take the next step (ie,
adding it to Wall).
> At the same time, the instances of the warning we have seen
> have all been issued for the configure tests for years and
> we have not seen any new instances of it as a result of
> this change, so the concern that the patch might lead to some
> more while at the same time accepting the ones we know about
> doesn't make sense to me.
Again, I don't think we can generalize much from the GCC autoconf
scripts and the failure modes are going to be extremely painful to track
down to this change.
While we have this concern with every new warning or enhancements to
existing warnings, this specific instance is worse because of how it
interacts with relatively common configury code.