On 09.12.23 18:38, Thiago Macieira wrote: > On Friday, 8 December 2023 18:51:19 PST Marc Mutz via Development wrote: >> I think we need to mandate that if you want qint128 support, then you >> must compile with gnu++NN, which is actually the default on both GCC and >> Clang. We seem to switch that off (-ansi on). > > Now answering the point you actually raised: > > I agree. If you want to use our qint128 API, you should use a standard C++ > library that knows about it too. You can mismatch at your own risk. > > That only brings the problem that QtCore and QtTest must support int128 if the > library *can* support it. We must either switch to non-strict mode in > compiling those two libraries or we must ignore our own flag in them. Neither > option is appetising.
Update: we're compiling Qt in non-strict (= default) mode now. tst_qglobal is compiled in both modes and headersclean continues to build in strict mode. This should fix the issue for qint128, but it looks like we still have some work to do for NativeFloat16 (cf. https://codereview.qt-project.org/c/qt/qtbase/+/581994) Thanks, Marc -- Marc Mutz <marc.m...@qt.io> (he/his) Principal Software Engineer The Qt Company Erich-Thilo-Str. 10 12489 Berlin, Germany www.qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
