<tumbleweed>
I hadn't ran into that bit of gcc-14 yet
<tumbleweed>
ah, yeah I see non-expat things caught up in that too
<ztrawhcse>
tumbleweed: debian has cleverly decided to add one out of the four warnings to gcc 13 as well, in order to detect time64 ABI breakages iirc. unclear why they don't test the other 3 ABI breaking issues as well
<ztrawhcse>
it is much easier to do mass rebuild tests and fix all issues at once, if you ask me
<ztrawhcse>
instead of waiting for gcc 14
<tumbleweed>
the time64 work wasn't related to gcc-14
<sam_>
no, it was
<sam_>
they cherry-picked some, but not all, of the helpful warnings->errors for the time64 work
<tumbleweed>
to help detect time64 bugs
<tumbleweed>
I think
<tumbleweed>
I see gcc's advice here is to declare a pragma turning it back to a warning
<sam_>
that's not what the advice is lol
<sam_>
the advice is to fix it
<tumbleweed>
under "Accommodating C code generators"
<sam_>
yes, as a workaround, if you can't get the C code generator fixed, like Vala
<sam_>
but mattip already fixed loads of these issues in pypy I reported
<ztrawhcse>
tumbleweed: I am aware that the gcc 14 changes aren't directly related to time64, the point is that gcc 14 causes certain types of broken code that get miscompiled by time64, to instead report a useful error and fail to build at all. in fact it reports a useful error even without switching to time64
<ztrawhcse>
and that's the thing. Debian could have just done a transition to "test for horrible ABI breaking issues that lead to crashes" by passing all four errors -- and made it easier to handle gcc 14 later on down the line
<tumbleweed>
yep
<tumbleweed>
but the people doing time64 were burned out enough by getting that done