Dne 30. 11. 23 v 18:09 Florian Weimer napsal(a):
This message is realted to: <https://fedoraproject.org/wiki/Changes/PortingToModernC> <https://fedoraproject.org/wiki/Toolchain/PortingToModernC> The final patches for GCC 14 are currently under upstream review and should land very soon. Earlier, I had received feedback that the larger community desires just one transition, so we end up with the following warnings which turn into errors by default: -Wimplicit-function-declaration -Wimplicit-int -Wint-conversion -Wreturn-mismatch (new, previously part of -Wreturn-types) -Wdeclaration-missing-parameter-type (new, previously unnamed) -Wincompatible-pointer-types Only the first two were covered in the initial Fedora conversion work. I've done another round of test builds with an instrumented GCC for all errors, and the numbers of problematic packages I have today are: autoconf all only implicit-function-declaration 53 21 implicit-int 2 0 int-conversion 99 33 return-mismatch 13 2 declaration-missing-parameter-type 0 0 incompatible-pointer-types 374 50 487 89 (I've updated the change page to describe those diagnostics briefly.) The numbers don't add up because one package can have multiple issues. Some of the reported issues are false positives, although the GCC instrumentation is a bit better than it used to be. The autoconf column covers packages which are particularly at risk for silent miscompilation because of incorrect detection of build system features. This is based on file name heuristics and includes more than just autoconf proper. As you can see, the incompatible-pointer-types issues are a bit of a problem. We fixed over 800 packages during the first round, and now it looks like we are only two thirds done. It is unlikely that I will be able to work on all these issues myself or with help from the people around me. I just suggested to GCC upstream that we may have to reconsider including this change in the GCC 14 release. Consequently, my priorities are as follows: * Try to resolve the autoconf issues in packages, to reduce the risk of silent miscompilation. * Integrate a backport of the GCC 14 changes into the rawhide GCC 13 version (rawhide only, not Fedora 39 or 38). This will allow us to isolate these issues from GCC 14 issues that typically occur during the upcoming mass rebuild. * Produce the final redhat-rpm-config integration, using -fpermissive for _build_type_safety_c 0, and -Wno-error= options for the higher type safety levels. This obviously depends on -fpermissive and and the new warning names becoming available in rawhide, which is another reason for the GCC 13 backport. * Come up with a way to resolve the Vala situation, likely by embedded “#pragma GCC diagnostic” in the generated C source files. Vala is currently not able to generate type-safe C, and is unlikely that this going to change soon. (The numbers above do not include packages which have failures in Vala code only.) In some cases, there is nothing that can be done about this on the Vala source code side. Not all of these type errors are harmless, of course, but I don't see a way to deal with this except by telling GCC to be less picky. I'm attaching package maintainer lists, generated using the find-package-maintainers script from fthe <https://pagure.io/fedora-misc-package-utilities/> repository, for both the full package set, and the autoconf-impacted package set. Build logs with results from the instrumentation are available here; <https://gitlab.com/fweimer-rh/fedora-modernc-logs/> We delete logs from that repository as packages get fixed.
How often this happens? It seems that there might be upstream fix for rubygem-curb, so if I update the package, how soon I'll know it helped?
Thx Vít
Again, some of these are false positives. The second link at the start has instructions for a COPR repository if you want to verify things locally (sadly the Koji build target is currently not in working order). Thanks, Florian -- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature
-- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
