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

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

[Florian Weimer]

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 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.)
* How do we divide up the test suite cleanup work?

Thanks,
Florian

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

[Jakub Jelinek]

On Tue, Sep 26, 2023 at 10:28:34AM +0200, Florian Weimer via Gcc wrote:
> 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.

I think it doesn't have to be necessarily using defaulting to -Werror=,
-Werror= involves diagnostic_classify_diagnostic etc.
It could very well be also just testing if the corresponding warning
option isn't explicitly (OPTION_SET_P) disabled and isn't explicitly
-Wno-error=OPTION and c99 or later and conditionally based on that
use error (which would print the [-W...] part though) or warning.
The former would be in system headers too, the latter wouldn't.
We need to decide what exact options we want to turn those errors (and/or
warnings) off or on, -Wno-implicit-int, -w, -Wno-error,
-Wno-error=implicit-int, ...

	Jakub

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

[Florian Weimer]

* Jakub Jelinek:

> On Tue, Sep 26, 2023 at 10:28:34AM +0200, Florian Weimer via Gcc wrote:
>> 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.
>
> I think it doesn't have to be necessarily using defaulting to -Werror=,
> -Werror= involves diagnostic_classify_diagnostic etc.
> It could very well be also just testing if the corresponding warning
> option isn't explicitly (OPTION_SET_P) disabled and isn't explicitly
> -Wno-error=OPTION and c99 or later and conditionally based on that
> use error (which would print the [-W...] part though) or warning.
> The former would be in system headers too, the latter wouldn't.
> We need to decide what exact options we want to turn those errors (and/or
> warnings) off or on, -Wno-implicit-int, -w, -Wno-error,
> -Wno-error=implicit-int, ...

I didn't mean to be prescriptive about implementation details, sorry.

With Clang, -w and -Wno-error have no effect on those error-by-default
warnings, too.  And I don't think Clang supports suppressing warnings
from system headers.

Thanks,
Florian

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

[Jeff Law]

On 9/26/23 02:28, Florian Weimer via Gcc wrote:
> 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, so I can't attest to accuracy.  It does look like a 
reasonable plan for gcc-14 though.

> 
> 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.)
> * How do we divide up the test suite cleanup work?
Not to open a can of worms, but shouldn't these be evaluated along the 
same basic criteria?  ie, what's Clang doing here, are these 
warnings-as-errors and thus apply to system headers, etc.  ANd the 
biggie, do any of these issues tend to mask correctness errors in the 
wild at a level roughly similar to implicit 
int/implicit-function-declaration?

Jeff

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

[Florian Weimer]

* Jeff Law:

>> 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.)
>> * How do we divide up the test suite cleanup work?

> Not to open a can of worms, but shouldn't these be evaluated along the
> same basic criteria?  ie, what's Clang doing here, are these
> warnings-as-errors and thus apply to system headers, etc.  ANd the
> biggie, do any of these issues tend to mask correctness errors in the
> wild at a level roughly similar to implicit
> int/implicit-function-declaration?

At present, it is not possible to evaluate them using the same basic
criteria because we don't have the answer to your last question.  I have
an instrumented compiler for -Wint-conversion, but have not had a chance
yet to run a distribution rebuild with it.

Thanks,
Florian

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

[Sam James]

Jeff Law via Gcc <gcc@gcc.gnu.org> writes:

> On 9/26/23 02:28, Florian Weimer via Gcc wrote:
>> 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, so I can't attest to accuracy.  It does look like a
> reasonable plan for gcc-14 though.
>
>> 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.)
>> * How do we divide up the test suite cleanup work?
> Not to open a can of worms, but shouldn't these be evaluated along the
> same basic criteria?  ie, what's Clang doing here, are these
> warnings-as-errors and thus apply to system headers, etc.  ANd the
> biggie, do any of these issues tend to mask correctness errors in the
> wild at a level roughly similar to implicit
> int/implicit-function-declaration?

My experience from doing the big rebuilds in Gentoo and working on
patches is that int-conversion often comes up with completely broken code
like wrong strerror_r variant (glibc vs musl) or with structs being
initialised with the wrong members (not using C99 desig. initialisers
and then differences with padding or similar). I don't think I can
recall a harmless hit.

Incompatible pointer types are a mix - sometimes it's harmless, but
a lot of the infringers aren't great (again often indicating wrong
prototypes being used or missing feature test macros). It's helped
to find a lot of typos as well. The only real snag (which isn't
a big deal IMO) is that it'll flag up attribute mismatches for
function pointer types, at least with Clang, but that's not a big
deal.

Clang has done both of these (technically Clang has only done
incompatible *function* pointer types rather than all incompatible
pointer types, at least for now though).

>
> Jeff

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

[Sam James]

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.

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.

> * 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.

>
> Thanks,
> Florian

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

[Arsen Arsenović]

[-- Attachment #1: Type: text/plain, Size: 2470 bytes --]


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ć

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 381 bytes --]

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

[Florian Weimer]

* Arsen Arsenović via Gcc:

> 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?

Falling of the end of the function is legitimate if a no-return function
is called and not annotated as such, among other things.  I don't think
we should warn or error for that by default.

The issue I'm concerned about is about “return;” in a function not
returning void, or “return expr;” in a function returning void.  This
looks like related to implict int return types for functions.  It's not
part of C99.  There is no separate -W switch to control this warning.
It is on by default (as required by C99), unlike other aspects of
-Wreturn-type.

Thanks,
Florian

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

[Anaya Shah]

[-- Attachment #1: Type: text/plain, Size: 3016 bytes --]

Hello,

I apologise for this problem, but I've been recieving emails regarding the
project you are working on.
However, I'm unable to understand the context of this project.
But it looks exciting!

I would be thankful if you can help me through the project framework, and
share the exact details, so that I can understand it and start working
today itself. I would also highly appreciate if you could guide me thorugh
the steps and instruct me on what I'm expected to do.
I'm currently a 3rd year B.Tech-Computer Science student.
Good day!

Thank-you,
Anaya Shah


On Wed, 27 Sept, 2023, 10:16 Florian Weimer via Gcc, <gcc@gcc.gnu.org>
wrote:

> * Arsen Arsenović via Gcc:
>
> > 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?
>
> Falling of the end of the function is legitimate if a no-return function
> is called and not annotated as such, among other things.  I don't think
> we should warn or error for that by default.
>
> The issue I'm concerned about is about “return;” in a function not
> returning void, or “return expr;” in a function returning void.  This
> looks like related to implict int return types for functions.  It's not
> part of C99.  There is no separate -W switch to control this warning.
> It is on by default (as required by C99), unlike other aspects of
> -Wreturn-type.
>
> Thanks,
> Florian
>
>