* Report from the additional type errors for GCC 14 BoF at Cauldron @ 2023-09-26 8:28 Florian Weimer 2023-09-26 9:22 ` Jakub Jelinek ` (2 more replies) 0 siblings, 3 replies; 10+ messages in thread From: Florian Weimer @ 2023-09-26 8:28 UTC (permalink / raw) To: gcc 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Report from the additional type errors for GCC 14 BoF at Cauldron 2023-09-26 8:28 Report from the additional type errors for GCC 14 BoF at Cauldron Florian Weimer @ 2023-09-26 9:22 ` Jakub Jelinek 2023-09-26 12:04 ` Florian Weimer 2023-09-26 12:22 ` Jeff Law 2023-09-26 18:40 ` Sam James 2 siblings, 1 reply; 10+ messages in thread From: Jakub Jelinek @ 2023-09-26 9:22 UTC (permalink / raw) To: Florian Weimer; +Cc: gcc 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Report from the additional type errors for GCC 14 BoF at Cauldron 2023-09-26 9:22 ` Jakub Jelinek @ 2023-09-26 12:04 ` Florian Weimer 0 siblings, 0 replies; 10+ messages in thread From: Florian Weimer @ 2023-09-26 12:04 UTC (permalink / raw) To: Jakub Jelinek; +Cc: gcc * 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Report from the additional type errors for GCC 14 BoF at Cauldron 2023-09-26 8:28 Report from the additional type errors for GCC 14 BoF at Cauldron Florian Weimer 2023-09-26 9:22 ` Jakub Jelinek @ 2023-09-26 12:22 ` Jeff Law 2023-09-26 13:42 ` Florian Weimer 2023-09-26 18:49 ` Sam James 2023-09-26 18:40 ` Sam James 2 siblings, 2 replies; 10+ messages in thread From: Jeff Law @ 2023-09-26 12:22 UTC (permalink / raw) To: Florian Weimer, gcc 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Report from the additional type errors for GCC 14 BoF at Cauldron 2023-09-26 12:22 ` Jeff Law @ 2023-09-26 13:42 ` Florian Weimer 2023-09-26 18:49 ` Sam James 1 sibling, 0 replies; 10+ messages in thread From: Florian Weimer @ 2023-09-26 13:42 UTC (permalink / raw) To: Jeff Law; +Cc: gcc * 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Report from the additional type errors for GCC 14 BoF at Cauldron 2023-09-26 12:22 ` Jeff Law 2023-09-26 13:42 ` Florian Weimer @ 2023-09-26 18:49 ` Sam James 1 sibling, 0 replies; 10+ messages in thread From: Sam James @ 2023-09-26 18:49 UTC (permalink / raw) To: Jeff Law; +Cc: Florian Weimer, gcc 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Report from the additional type errors for GCC 14 BoF at Cauldron 2023-09-26 8:28 Report from the additional type errors for GCC 14 BoF at Cauldron Florian Weimer 2023-09-26 9:22 ` Jakub Jelinek 2023-09-26 12:22 ` Jeff Law @ 2023-09-26 18:40 ` Sam James 2023-09-26 22:06 ` Arsen Arsenović 2 siblings, 1 reply; 10+ messages in thread From: Sam James @ 2023-09-26 18:40 UTC (permalink / raw) To: Florian Weimer; +Cc: gcc 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Report from the additional type errors for GCC 14 BoF at Cauldron 2023-09-26 18:40 ` Sam James @ 2023-09-26 22:06 ` Arsen Arsenović 2023-09-27 4:44 ` Florian Weimer 0 siblings, 1 reply; 10+ messages in thread From: Arsen Arsenović @ 2023-09-26 22:06 UTC (permalink / raw) To: Sam James; +Cc: Florian Weimer, gcc [-- 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 --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Report from the additional type errors for GCC 14 BoF at Cauldron 2023-09-26 22:06 ` Arsen Arsenović @ 2023-09-27 4:44 ` Florian Weimer 2023-09-27 8:52 ` Anaya Shah 0 siblings, 1 reply; 10+ messages in thread From: Florian Weimer @ 2023-09-27 4:44 UTC (permalink / raw) To: Arsen Arsenović via Gcc; +Cc: Sam James, Arsen Arsenović * 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Report from the additional type errors for GCC 14 BoF at Cauldron 2023-09-27 4:44 ` Florian Weimer @ 2023-09-27 8:52 ` Anaya Shah 0 siblings, 0 replies; 10+ messages in thread From: Anaya Shah @ 2023-09-27 8:52 UTC (permalink / raw) To: Florian Weimer; +Cc: Arsen Arsenović via Gcc [-- 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 > > ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2023-09-27 8:53 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2023-09-26 8:28 Report from the additional type errors for GCC 14 BoF at Cauldron Florian Weimer 2023-09-26 9:22 ` Jakub Jelinek 2023-09-26 12:04 ` Florian Weimer 2023-09-26 12:22 ` Jeff Law 2023-09-26 13:42 ` Florian Weimer 2023-09-26 18:49 ` Sam James 2023-09-26 18:40 ` Sam James 2023-09-26 22:06 ` Arsen Arsenović 2023-09-27 4:44 ` Florian Weimer 2023-09-27 8:52 ` Anaya Shah
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).