On Tue, May 9, 2023 at 8:16 AM Florian Weimer via Gcc <gcc@gcc.gnu.org> wrote:
> TL;DR: This message is about turning implicit-int, > implicit-function-declaration, and possibly int-conversion into errors > for GCC 14. > > A few of you might remember that I've been looking into turning some > type errors from warnings into errors by default. Mainly I've been > looking at implicit function declarations because in too many cases, the > synthesized declaration does not match the prototype used at function > definition and can cause subtle ABI issues. > > To recap, the main challenge is that GCC has to serve disparate groups > of users: some use GCC for writing programs themselves, but others just > need GCC to build sources that they have obtained from somewhere. The > first group benefits from more type errors because they catch errors > earlier during development (experience shows that compiler warnings are > easy to miss in a long build log). The second group might find these > errors challenging because the sources they have no longer build. > Hi, Florian Thanks for working on this and proposing this. Yes, GCC has two, distinct user groups / use cases, but GCC also has a very unique and crucial role, as the foundation for a large portion of the GNU/Linux and FOSS software ecosystem. This proposal is missing a motivation for this change, especially making new errors the default. GCC needs to be proactive, not reactive, without annoying and frustrating its user base. Clang has been making some aggressive changes in warnings, but its constituency expects that. Developers who want that experience already will use Clang, so why annoy developers who prefer the GCC experience and behavior? The new warnings and errors help some developers and improve software security, but also drive some developers away, or at least cause them to reass their choice of toolchain. Maybe we need additional front-end aliases "gcclang" and "gcclang++" for GCC to provide an experience more like Clang for those who desire that. GCC isn't Clang and I fear that GCC is going down a path that annoys and frustrates both user groups -- it's not sufficiently aggressive for those who prefer Clang and it's too aggressive for those who wish backward compatibility. Thoughts? Thanks, David > > To see how large the impact is on that second group, we've mostly > removed implicit function declarations and implicit ints from Fedora: > > <https://fedoraproject.org/wiki/Changes/PortingToModernC> > <https://fedoraproject.org/wiki/Toolchain/PortingToModernC> > > Roughly 870 packages out of ~14,500 that have GCC present during the > build needed fixing (or flagging that they can't be built with the > additional errors), so 6%. Most of the changes are mechanical in > nature, like adding additional headers to configure checks. For about > ~150 packages, automated patching could be used to rewrite problematic > built-in checks generated by long-obsolete autoconf versions. > > Some of these changes prevent the compiler behavior for altering the > build results silently because the new errors changed the outcome of > autoconf checks. (We had one of those in libstdc++, changing the ABI on > GNU/Linux because futex support oculd no longer be detected.) > Unfortunately, I did not record numbers about them, but think those were > quite rare; most autoconf problems were also accompanied with other > problems, or the incorrect results from autoconf led to build failures > later. So it seems to me that the risk that the second group mentioned > above would silently get unexpected build results is fairly low. > > Where possible, we tried to upstream patches, to simplify sharing across > distributions and to help those who compile upstream sources directly. > We also benefited from other distributions upstreaming changes along > similar lines (notably Gentoo for their Clang 16 project, but also from > Homebrew to a lesser extent). > > An area we started exploring only recently for Fedora is implicit > conversions between integers and pointers (covered by -Wint-conversion). > These add another ~170 packages, but some of those are false positives > (due to our instrumented compiler approach) that do not change the build > outcome at all. I'm still negotiating whether we have the capacity to > develop fixes for these packages proactively. > > I brought up the matter with distributions, and the feedback was neutral > (not overly negative, as in “this would be the end of the world for > us”). > > < > https://discourse.nixos.org/t/rfc-more-c-errors-by-default-in-gcc-14/27390 > > > <https://lists.debian.org/debian-gcc/2023/04/msg00015.html> > < > https://lists.opensuse.org/archives/list/fact...@lists.opensuse.org/thread/5OL76NH5AX75WOTZ43O3ZF2JOS3ABBXL/#QZLCA5YPN5CWSS7BCC6TNBC6N7RFTW7J > > > > (I tried to contact Arch, but my message didn't make it past the > moderators, it seems.) > > All in all, the whole situation is not great, but it still seems > manageable to me. > > Anyway, thanks for reading this far. > > I would like to suggest to turn implicit-int, > implicit-function-declaration, and possibly int-conversion from warnings > into errors for GCC 14. This would give upstream projects roughly > another year to make new releases with compatibility fixes that have > been contributed so far. I do not think waiting longer, until GCC 15, > would make a meaningful difference because any upstream project that > does not release within the next 12 months is not likely to release in > the next 24 months, either. > > Regarding mechanics of the necessary opt out facility, Clang used > -Werror=… by default, but that seems a bit hackish to me. Presently, we > cannot use -std=gnu89 etc. to opt out because there are packages which > require both C89-only language features and C99-style inlining, which is > currently not a combination supported by GCC (but maybe that could be > changed). Some build systems do not treat CFLAGS and CXXFLAGS as fully > separate, and a flag approach that works for C and C++ without > introducing any new warnings would be most convenient. So maybe we > could use -fpermissive for C as well. > > One fairly big GCC-internal task is to clear up the C test suite so that > it passes with the new compiler defaults. I already have an offer of > help for that, so I think we can complete this work in a reasonable time > frame. > > I have no data how big the compatibility impact of turning > incompatible-pointer-types into errors will be. For now, int-conversion > has higher priority. However, it looks like another change that could > benefit developers (the first group). > > I do not plan to work specifically on C2X compatibility fixes for now > (to support bool-as-keyword, for example), but I could imagine a similar > project a few years from now, fewer than 25 hopefully, that would enable > GCC to make the switch to C2X by default. > > Thanks, > Florian > >
