Based on my records, all issues that can lead to silent miscompilation because of altered configure probes (autoconf/CMake and a few others) have been addressed, or there are at least Bugzilla bugs filed for them. There could be some gaps due to lack of architecture capture, general rawhide churn, or configure scripts running late during the build, which we do not reach due to a previous build failure. But these gaps should fairly small, I hope. It's also not a new problem—while fixing newly introduced errors, we encountered cases where autoconf probes had already been failing unexpectedly for a long time because of typos or missing #include directives. I originally wanted to fix the int-conversion issues next. That package set is fairly small (about 60 packages). But it's more or less a coin toss whether the compiler errors is due to a missing cast due to C type system limitations, or indicative of a real problem (typically manifesting as a crash at run time if the code is ever executed). The latter can be quite difficult to fix and may require domain-specific knowledge. Just adding the cast in both cases just obscures the crash or misbehavior in the second case, and robs us of an opportunity to fix this properly. I see what I can do to fix packages, but it's unlikely that it will going to be all of them. Looking at the calendar and the projected time when GCC 14 will land in the buildroot, I think we missed the window where a GCC 13 version with a preview of these C front end changes would have been beneficial to Fedora developers. It would have also created an awkward issue where __GNUC__ is 13, but the compiler behaves in part like GCC 14. This is relevant if it's necessary to suppress (or treat as warnings) -Wreturn-mismatch diagnostics, which only exist in GCC 14. This brings me to my final point. We still don't have a solution for Vala. I plan to look at valac soon and see what we can do to keep things at least compiling with GCC 14 (after re-running valac). 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
