On Tuesday, 26 May 2026 00:51:35 Pacific Daylight Time Marc Mutz via Development wrote: > It means it didn't blow up at some customer first (for all we know)
For all we know, it did. We did not root-cause to which version of GCC applies the optimisation, so we don't know how long the latent bug has been there. I could reproduce the issue with three different versions (14, 15 and 16) and GCC 14 is from 2024, so the issue has been reproducible for at lest two years. I did *not* test with 13 or earlier versions. That said, we have *not* observed it in QList, QByteArray and QString. It showed up in SimpleVector, and it might have shown up there *only* because it's simple. Therefore, even though the bug has been latent since Qt 5.0, for all we know it has never expressed itself and never would have. > Several highly-esteemed developers and two chat bots concluded that this is > a compiler bug. BTW, my prompt to Claude was: I have a test bug that looks like a compiler problem. It could be a source problem, but I don't think so. When running @tests/auto/corelib/tools/qarraydata/tst_qarraydata.cpp test arrayDataOps, I get the following output: ... The compiled assembly is @tst_qarraydata.cpp.s and the object file is @tst_qarraydata.cpp.o So I did tell it that the problem could be a compiler bug. That's probably confirmation bias, because I had concluded the same. But in any case, it found the exact same piece of assembly I had and concluded the exact same thing: the cached size wasn't updated. What we both got wrong is the attribution: the issue wasn't a compiler bug, but a source code bug that caused UB. > To me, this issue reinforces what I have known to be true for years, to wit: > - the compiler is more clever than you, you MUST NOT fall into UB, > regardless of whether _you_ think it's benign (even if you think you can > prove it) > - only features shouldn't be picked back, in particular > - test changes should always be picked back, with a XFAIL, if necessary > - refactorings should always be picked back (or not done at all) > - bugfixes should always be picked back Agreed in principle, but in practice it's hard. First, some bugfixes are themselves risky or change behaviour, so applying the fix may not be a good idea. That's a subjective question. Second, very often a bugfix happens after a feature has changed the code, which wasn't picked packwards. Picking the bugfix is not trivial either, due to unavoidable conflicts, as you've seen. That's natural, though. -- Thiago Macieira - thiago.macieira (AT) intel.com Principal Engineer - Intel DCG - Platform & Sys. Eng.
smime.p7s
Description: S/MIME cryptographic signature
-- Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
