[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