Comment from peanut gallery,
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40856
> This code should produce the same results with -std=g++11 and -std=c++11
> I will not object to patches tweaking the condition and positively reviewed
> by fellow maintainers.
It sounds like the GCC
On Tuesday 9 July 2024 03:33:16 GMT-7 Marc Mutz via Development wrote:
> We should really try to fix this before 6.8.0 (LTS).
I won't have time for QDataStream and especially QTextStream & QDebug, which
are required for QMetaType.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal
We should really try to fix this before 6.8.0 (LTS).
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
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
On Friday, 8 December 2023 18:51:19 PST Marc Mutz via Development wrote:
> After spending countless hours between Ivan and myself fighting GCC's
> mysteriously-vanishing support for __int128_t (= qint128),
> it turns out that with -ansi/-std=c++NN, not even the most basic of
> work:
Il 09/12/23 03:51, Marc Mutz via Development ha scritto:
After spending countless hours between Ivan and myself fighting GCC's
mysteriously-vanishing support for __int128_t (= qint128),
it turns out that with -ansi/-std=c++NN, not even the most basic of
work: std::is_signed_v is_false_! I
Hi,
After spending countless hours between Ivan and myself fighting GCC's
mysteriously-vanishing support for __int128_t (= qint128),
it turns out that with -ansi/-std=c++NN, not even the most basic of
work: std::is_signed_v is _false_! I repeat: _FALSE_.
The following is /my/ professional