Report from the additional type errors for GCC 14 BoF at Cauldron

[Arsen Arsenović]

Sam James via Gcc <gcc@gcc.gnu.org> writes:

> Florian Weimer via Gcc <gcc@gcc.gnu.org> writes:
>
>> My understanding of the consensus goes as follows:
>>
>> * We want to make some changes in this area for GCC 14.
>> * We should do the same thing that Clang does: default to the relevant
>>   -Werror= options.
>> * Unlike regular warnings, these warnings-as-errors should also apply
>>   to system headers.
>> * At least implict-int and implicit-function-declaration should be
>>   upgraded to errors in this way.
>> * It's too early to make the () changes and bool-as-keyword from C2X
>>   for GCC 14.
>> * We should fix the missing scope of the int-conversion warnings
>>   (PR109827).  Likweise for incompatible-pointer-types (PR109826).
>>
>> Is this summary accurate?
>>
>
> I wasn't there, but this reflects my understanding & what I would've
> said if I could've attended.
>
>> I think the open issues are:
>>
>> * Do we want to implement something else beside implicit-int and
>>   implicit-function-declaration?  (Candidates are int-conversion and
>>   incompatible-pointer-types, and the void vs non-void part of
>>   return-type, maybe others as previously discussed on the list.)
>
> Ideally, I'd like both int-conversion + incompatible-pointer-types in
> this cycle, but if we have to defer one, I'd say to keep int-conversion.

+1, this seems reasonable.  I'm not sure I can imagine any even
half-legitimate use for falling off the end of functions and similar, so
perhaps we should also take return-type?  Is that part of C23?

> A lot of the low hanging fruit is already fixed there, with the only
> big remaining blocker being Vala (which is a
> compiler/transpiler). They've indicated they're not that fussed
> unless/until GCC changes.
>
> Putting it another way: I don't think waiting a year or two
> would actually help the situation much.

Yes, at best it helps with the schedule.

>> * How do we divide up the test suite cleanup work?
>
> Once there's some patches to work with, I'm happy to do a good
> chunk (obviously).
>
> IIRC Jakub and others indicated that the priority is to preserve
> the test cases (and hence pass appropriate flags) rather than fix them
> up, to avoid inadvertently testing the wrong thing.

We could possibly even automate that, by checking what new errors
appeared per testcase and inverting them.

>>
>> Thanks,
>> Florian


-- 
Arsen Arsenović
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 381 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc/attachments/20230927/5b380a52/attachment-0001.sig>