[PATCH] improve detection of incompatible redeclarations (PR 97882)

Martin Sebor msebor@gmail.com
Thu Feb 4 20:07:34 GMT 2021


On 2/4/21 9:48 AM, Martin Sebor wrote:
> On 2/3/21 5:15 PM, Joseph Myers wrote:
>> On Wed, 3 Feb 2021, Martin Sebor via Gcc-patches wrote:
>>
>>> +/* Return true of T1 and T2 are matching types for the purposes of
>>> +   redeclaring a variable or a function without a prototype (i.e.,
>>> +   considering just its return type).  */
>>
>> I think this comment is confusing (it suggests it's checking something
>> looser than the notion of compatibility checked by comptypes, but it's
>> actually checking something stricter).  But I also think it's wrong to do
>> anything restricted to the return type.
>>
>> For example, I think the following should be rejected, as enum E and
>> unsigned int end up incompatible and quite likely ABI-incompatible.
>>
>> enum E;
>> void f(enum E);
>> void f(unsigned int);
>> enum E { x = 1ULL << 63 };
>>
>> Maybe the ICE is specific to the case of return types, but I think the
>> same rules about type compatibility should apply regardless of precisely
>> where the incomplete enum type appears.
> 
> Ah, it's even more wide-spread than I realized.
> 
>>
>> I'd expect the natural fix for this PR to involve making
>> comptypes_internal treat an incomplete enum as incompatible with an
>> integer type.  Only if that causes too many problems should we then look
>> at other approaches.
>>
> 
> Let me look into it then.

Okay, that's much simpler.  Thanks for nudging me in the right
direction!  How's the attached patch? Retested on x86_64-linux.

Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gcc-97882.diff
Type: text/x-patch
Size: 27253 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc-patches/attachments/20210204/2be7e688/attachment-0001.bin>


More information about the Gcc-patches mailing list