On Sun Apr 13, 2025 at 9:18 PM CEST, Nicolas Boulenguez wrote: > Hello.
Hello! > Please skip v14 and review v15. A diff with v13 is attached. > The full v15 is at > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114065, but my SMTP > server refused them as attachments. Ok! (from previous mail) > I wonder what is blocking patch 3. > It fixes one word in the documentation. Yes, this patch can be merged of course. Since your previous mail, we have been reviewing your changes and started testing them against our ecosystem. > Patch 1 implements the new > Ada.Calendar_Conversions.To_{Duration,Struct_Timespec}64 with > System.C_Time, as already done for the unsuffixed version in v13. > It adds a comment explaining that the conversion fails when the C > struct cannot represent the value, even if Long_Long_Integer can. The changes look pretty good with a lot of duplication removed, thanks! The main issue we currently see is that some application code doesn't build. In particular gprbuild needs to be adjusted following your changes. We don't want to split the ecosystem between code that builds with latest compiler only and code that builds with older compilers only. We're currently discussing the possible solutions. The case of gprbuild is very localized and comes from the removal of the Timeval type in the GNAT.Sockets.Thin_Common package, but we fear that this pattern may exist in many other applications. Testing the changes is not straightforward as we need to adjust many downstream projects (gprbuild as already mentioned, but also many custom runtimes that now fail to build, and probably others that we will discover as we fix previous failures...). > Patch 2 selects the time64 symbols for C time functions in the > 32bits/time64/glibc case with explicit External_Names (instead of > duplicating a test is several files in v13), so that glibc/musl > specifics are only written once in s-oscons-tplt.c. This one looks great but we also need to test it carefully before merging it. > Do these changes answer your concerns? In part yes, thank you very much. As you've probably already seen, it's too late to expect the change to be merged in 15, the branch has been forked yesterday (but even last week was already too short to leave enough time for review and testing, especially during stage4). As GCC 16 cycle has just started, we'll iterate with our testing and hopefully will manage to have this merged as part of the forthcoming stage1. Best regards, Marc Poulhiès
