14.08.2019, 23:53, "Allan Sandfeld Jensen" :
> On Tuesday, 13 August 2019 18:13:05 CEST Thiago Macieira wrote:
>> On Tuesday, 13 August 2019 00:50:48 PDT Friedemann Kleint wrote:
>> > Hi,
>> >
>> > > VC++ 2019
>> >
>> > Just for the record, this compiler still has a number of optimizer
On Tuesday, 13 August 2019 18:13:05 CEST Thiago Macieira wrote:
> On Tuesday, 13 August 2019 00:50:48 PDT Friedemann Kleint wrote:
> > Hi,
> >
> > > VC++ 2019
> >
> > Just for the record, this compiler still has a number of optimizer bugs,
> > see https://bugreports.qt.io/browse/QTQAINFRA-2875
On 2019-08-13 09:50, Friedemann Kleint wrote:
> VC++ 2019
Just for the record, this compiler still has a number of optimizer
bugs,
see https://bugreports.qt.io/browse/QTQAINFRA-2875 .
Also JFTR: Peppe found one of the bugs rumoured to be a MSVC bug was a
problem in _our_ code, the
On Tuesday, 13 August 2019 00:50:48 PDT Friedemann Kleint wrote:
> Hi,
>
>
> > VC++ 2019
>
>
> Just for the record, this compiler still has a number of optimizer bugs,
> see https://bugreports.qt.io/browse/QTQAINFRA-2875 .
Unfortunately, despite those, it's still the best available. MSVC
> On 12 Aug 2019, at 22:17, Thiago Macieira wrote:
>
>> On Monday, 12 August 2019 00:17:58 PDT Lars Knoll wrote:
>> As mentioned in my blog, it would be good to move forward with the C++
>> version we use for Qt 6 and ideally move it to C++17.
>
> Someone with iOS knowledge please address the
Hi,
> VC++ 2019
Just for the record, this compiler still has a number of optimizer bugs,
see https://bugreports.qt.io/browse/QTQAINFRA-2875 .
Regards, Friedemann
--
Friedemann Kleint
The Qt Company GmbH
___
Development mailing list
On 2019-08-12 22:34, Thiago Macieira wrote:
On Monday, 12 August 2019 08:11:38 PDT Thiago Macieira wrote:
distributions and Android SDKs use.
Any word on what Clang the Android SDK we'll require uses?
NDK r19 and NDK r20 are shipped with clang 8.0, which according to
On Monday, 12 August 2019 13:34:25 PDT Mutz, Marc via Development wrote:
> > QByteArray, due to its dual string / byte array nature, will continue
> > to
> > operate on char.
>
> It was a mistake to merge QCString and QByteArray back then. This design
> doesn't work. Python 2 realized it, and we
On Monday, 12 August 2019 13:23:45 PDT Christian Gagneraud wrote:
> On Mon, 12 Aug 2019, 22:13 Thiago Macieira,
>
> wrote:
> > On Monday, 12 August 2019 13:03:47 PDT Mutz, Marc via Development wrote:
> > > The milestone is std::byte, which which we could put QByteArray on a
> > > sound basis.
On 2019-08-12 22:13, Thiago Macieira wrote:
On Monday, 12 August 2019 13:03:47 PDT Mutz, Marc via Development
wrote:
The milestone is std::byte, which which we could put QByteArray on a
sound basis. And char8_t, which would make QUtf8String(View) fly.
QByteArray, due to its dual string / byte
On Mon, 12 Aug 2019, 22:13 Thiago Macieira,
wrote:
> On Monday, 12 August 2019 13:03:47 PDT Mutz, Marc via Development wrote:
> > The milestone is std::byte, which which we could put QByteArray on a
> > sound basis. And char8_t, which would make QUtf8String(View) fly.
>
> QByteArray, due to its
On Monday, 12 August 2019 00:17:58 PDT Lars Knoll wrote:
> As mentioned in my blog, it would be good to move forward with the C++
> version we use for Qt 6 and ideally move it to C++17.
Someone with iOS knowledge please address the C++17 issue reported on the
interest list and provide a
On Monday, 12 August 2019 13:03:47 PDT Mutz, Marc via Development wrote:
> The milestone is std::byte, which which we could put QByteArray on a
> sound basis. And char8_t, which would make QUtf8String(View) fly.
QByteArray, due to its dual string / byte array nature, will continue to
operate on
On 2019-08-12 21:33, Thiago Macieira wrote:
[...]
Is there any really cool or
important feature for us to require GCC 8, instead of 7? Like the
enforced
copy elision we'll need to deprecate QMutexLocker.
We don't need guaranteed copy elision, we need CTAD for that. If we have
CTAD, we can
On 2019-08-12 14:34, Allan Sandfeld Jensen wrote:
On Monday, 12 August 2019 14:21:25 CEST Ville Voutilainen wrote:
On Mon, 12 Aug 2019 at 15:10, Allan Sandfeld Jensen
wrote:
> explicit(bool): We use some ugly patterns in places to simulate this.
Can you point me to those? I do know what
On Mon, 12 Aug 2019, 21:37 Thiago Macieira,
wrote:
> On Monday, 12 August 2019 08:11:38 PDT Thiago Macieira wrote:
> > distributions and Android SDKs use.
>
> Any word on what Clang the Android SDK we'll require uses?
>
Clang 8 AFAIK, and let's not forget about their push of libc++ (Vs gnu
On Monday, 12 August 2019 08:11:38 PDT Thiago Macieira wrote:
> distributions and Android SDKs use.
Any word on what Clang the Android SDK we'll require uses?
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
On Monday, 12 August 2019 10:57:34 PDT Giuseppe D'Angelo via Development
wrote:
> Il 12/08/19 17:11, Thiago Macieira ha scritto:
> > I think we should aim for something that is modern, but not bleeding edge
> > today. For a release in late 2020, we should expect that people may want
> > to
> >
Il 12/08/19 17:11, Thiago Macieira ha scritto:
I think we should aim for something that is modern, but not bleeding edge
today. For a release in late 2020, we should expect that people may want to
use with close-to-2-year-old Linux distros. I would prefer they didn't, but I
think it's reasonable
On Monday, 12 August 2019 00:45:01 PDT Allan Sandfeld Jensen wrote:
> Why not the latest for all the compilers, like gcc 9 and clang 8? I assumed
> we would use the 5.15 LTS to justify requiring the latest available
> compiler on all platforms.
>
> Especially clang 6 is a bit old. I know for
On Monday, 12 August 2019 04:07:41 PDT Tony Sarajärvi wrote:
> How about ICC 19?
> https://software.intel.com/en-us/articles/intel-c-compiler-190-for-linux-rel
> ease-notes-for-intel-parallel-studio-xe-2019
>
> -T
ICC should only be supported at the latest version at the time of launch. So
we
On Monday, 12 August 2019 14:21:25 CEST Ville Voutilainen wrote:
> On Mon, 12 Aug 2019 at 15:10, Allan Sandfeld Jensen
wrote:
> > explicit(bool): We use some ugly patterns in places to simulate this.
>
> Can you point me to those? I do know what such patterns are in
> general, std::optional and
On Mon, 12 Aug 2019 at 15:10, Allan Sandfeld Jensen wrote:
> explicit(bool): We use some ugly patterns in places to simulate this.
Can you point me to those? I do know what such patterns are in
general, std::optional and std::tuple
are full of it. :)
> Integrating feature-test macros: Could
Note that "red" in the page does not always mean unsupported, but also that
nobody tested if the feature is present.
> On 12. Aug 2019, at 14:07, Allan Sandfeld Jensen wrote:
>
> On Monday, 12 August 2019 09:58:39 CEST Lars Knoll wrote:
>> I’d personally be favour of using newer version of
On Monday, 12 August 2019 09:58:39 CEST Lars Knoll wrote:
> I’d personally be favour of using newer version of gcc/clang, but I’m not
> sure we gain a lot with it, as Apple clang is then probably the limiting
> factor. But we could upgrade that to Apple Clang 11 as well.
Yeah, I was looking
mailing list
Subject: Re: [Development] Supported compilers for Qt 6
On Mon, 12 Aug 2019 at 12:16, Lars Knoll wrote:
> > We gain a slightly better baseline wrt. bugs; GCC for instance
> > doesn't backport to closed branches, and GCC 7 is already closed,
> > and 8 will follow
On Mon, 12 Aug 2019 at 12:16, Lars Knoll wrote:
> > We gain a slightly better baseline wrt. bugs; GCC for instance doesn't
> > backport to closed branches, and GCC 7 is already
> > closed, and 8 will follow relatively quickly. While we can't keep up
> > with that during our (especially LTS)
> On 12 Aug 2019, at 10:54, Ville Voutilainen
> wrote:
>
> On Mon, 12 Aug 2019 at 11:00, Lars Knoll wrote:
>> Here’s the baseline I would like to propose:
>>
>> VC++ 2019
>> GCC 8
>> Clang 6
>> Apple Clang 10.0
>>
>> Why not the latest for all the compilers, like gcc 9 and clang 8? I
On Mon, 12 Aug 2019 at 11:00, Lars Knoll wrote:
> Here’s the baseline I would like to propose:
>
> VC++ 2019
> GCC 8
> Clang 6
> Apple Clang 10.0
>
> Why not the latest for all the compilers, like gcc 9 and clang 8? I assumed we
> would use the 5.15 LTS to justify requiring the latest available
> On 12. Aug 2019, at 09:58, Lars Knoll wrote:
>
>
>
>> On 12 Aug 2019, at 09:45, Allan Sandfeld Jensen wrote:
>>
>> On Monday, 12 August 2019 09:17:58 CEST Lars Knoll wrote:
>>> Hi,
>>>
>>> As mentioned in my blog, it would be good to move forward with the C++
>>> version we use for Qt 6
On 12 Aug 2019, at 09:45, Allan Sandfeld Jensen
mailto:k...@carewolf.com>> wrote:
On Monday, 12 August 2019 09:17:58 CEST Lars Knoll wrote:
Hi,
As mentioned in my blog, it would be good to move forward with the C++
version we use for Qt 6 and ideally move it to C++17. That implies that we
On Monday, 12 August 2019 09:17:58 CEST Lars Knoll wrote:
> Hi,
>
> As mentioned in my blog, it would be good to move forward with the C++
> version we use for Qt 6 and ideally move it to C++17. That implies that we
> need to drop some older compilers for Qt 6. As 5.15 is going to be an LTS
>
Hi,
As mentioned in my blog, it would be good to move forward with the C++ version
we use for Qt 6 and ideally move it to C++17. That implies that we need to drop
some older compilers for Qt 6. As 5.15 is going to be an LTS release, I don’t
think this is going to be a huge problem.
Here’s the
33 matches
Mail list logo
