[PATCH] avoid treating more incompatible redeclarations as builtin-ins [PR94040]

[Martin Sebor]

On 3/18/20 1:04 PM, Jakub Jelinek wrote:
> On Wed, Mar 18, 2020 at 12:57:18PM -0600, Martin Sebor via Gcc-patches wrote:
>> I noticed this last night:
>>
>>    https://sourceware.org/pipermail/glibc-cvs/2020q1/069150.html
>>
>> Presumably that's the fix.
> 
> Or maybe for REAL_TYPE just care here about TYPE_MODE which should be all
> that matters?  If double and long double are the same, it isn't a big deal.
> And similarly for INTEGER_TYPEs only care about TYPE_MODE/TYPE_PRECISION?
> If unsigned long and unsigned long long are the same, why should we care?

There are a few reasons why diagnosing incompatible declarations
(of built-ins or any other kind) is helpful even for same size
types.

First, -Wbuiltin-declaration-mismatch is documented to "warn if
a built-in function is declared with an incompatible signature."
Distinct types like unsigned long and long long are incompatible
and redeclaring functions with incompatible argument types (or
return types) makes their signatures incompatible, and the code
undefined.  Detecting incompatibilities is the purpose of
the warning, irrespective of whether or not a subset of them
might be considered "big deal" in some situations[*].

Second, the TYPE_MODE test isn't sufficient to discriminate between
signed and unsigned types with the same precision, and those can
cause subtle bugs to go undetected.

Third, built-in type mismatches tend to cause us headaches (such
as ICEs) in parts of the compiler (the middle-end or other parts
of the front ends) that are updated with the assumption of type
compatibility in the C/C++ sense.  They are an unnecessary gotcha
to keep in mind that's easy to forget about or not get exactly
right and that leads to wasted resources: users or testers
reporting them as bugs and developers fixing them at the end
of each release.

The overly loose matching based on TYPE_MODE was in place before
GCC 8.  Since then, we have been tightening up these checks.  It
would be a step backward to change direction and start encouraging
sloppy code, glossing over latent bugs, and exposing ourselves to
more reports of ICEs.  Specialized projects like Glibc that have
a legitimate need for declaring symbols with incompatible types
have the option to disable either the warnings or the built-ins
themselves.  Nothing indicates that this practice is commonplace
or that GCC is too strict (it is still more permissive than
the same option in Clang that predates GCC's by a number of
years.)

Martin

[*] As a precedent for warning on similarly "benign" mismatches
consider issuing -Wformat when passing same size arguments to
directives like %i, %li, and %lli, or (for issuing "portability"
warnings for code that's fully valid and safe for the current
target), -Wchar-subscripts when -fno-signed-char is in effect.