On Sunday 26 July 2015 12:24:04 René J. V. Bertin wrote:
> Thiago Macieira wrote:
> >> %> clang -dM -E -xc /dev/null | fgrep -i SSE
> >> #define __SSE2_MATH__ 1
> >> #define __SSE2__ 1
> >> #define __SSE3__ 1
> >> #define __SSE_MATH__ 1
> >> #define __SSE__ 1
> >> #define __SSSE3__ 1
> >
> > This
Thiago Macieira wrote:
>> %> clang -dM -E -xc /dev/null | fgrep -i SSE
>> #define __SSE2_MATH__ 1
>> #define __SSE2__ 1
>> #define __SSE3__ 1
>> #define __SSE_MATH__ 1
>> #define __SSE__ 1
>> #define __SSSE3__ 1
>
> This confirms it enables SSS3 by default, but not SSE4.1.
I didn't check this y
On Saturday 25 July 2015 09:50:06 René J. V. Bertin wrote:
> > Because it can't be disabled in the compiler. It *always* generates those
> > instructions.
>
> ...
>
> > That's incorrect. SSE4.2 is enabled in your compiler because you're using
> > Apple's build of Clang.
>
> I don't think it's as
Thiago Macieira wrote:
>> > For Clang, QT_COMPILER_SUPPORTS_HERE(x) expands to a check defined(__x__)
>> > [in this case, if __SSE4_2__ is defined].
...
>
> __SSE4_2__ isn't defined anywhere you'll see. It's pre-defined by the
> compiler.
Well yes of course, I know that. I meant the declaration
On Friday 24 July 2015 21:17:24 René J. V. Bertin wrote:
> Thiago Macieira wrote:
> > For Clang, QT_COMPILER_SUPPORTS_HERE(x) expands to a check defined(__x__)
> > [in this case, if __SSE4_2__ is defined].
>
> I had a hunch it'd be that, but must have missed the actual macro definition
> where thi
Thiago Macieira wrote:
> For Clang, QT_COMPILER_SUPPORTS_HERE(x) expands to a check defined(__x__) [in
> this case, if __SSE4_2__ is defined].
I had a hunch it'd be that, but must have missed the actual macro definition
where this would have become evident (I was working remotely, so only used
On Friday 24 July 2015 14:23:08 René J. V. Bertin wrote:
> René J. V. Bertin wrote:
> >> That shouldn't happen. QT_COMPILER_SUPPORTS_SSE4_2 should not be defined,
> >> so this wouldn't evaluate to true:
> >>
> >> #if QT_COMPILER_SUPPORTS_HERE(SSE4_2)
> >
> > That's what I figured and that's why I
René J. V. Bertin wrote:
>> That shouldn't happen. QT_COMPILER_SUPPORTS_SSE4_2 should not be defined, so
>> this wouldn't evaluate to true:
>>
>> #if QT_COMPILER_SUPPORTS_HERE(SSE4_2)
>
> That's what I figured and that's why I tried the options. I'll see if I can
> reproduce the issue and report
Thiago Macieira wrote:
>> If this were a local build I'd just skip the LTO for QtScript, but the build
>> is to be handled by a LauncPad PPA
>
> Add to script.pro:
> QMAKE_CXXFLAGS -= -flto
This is enough for QtScript (with a similar QMAKE_LFLAGS statement).
However, for QtWebkit it is not
Thiago Macieira wrote:
>> But what about the fact that that those intrinsics are still used even when
>> configure is called with -no-sse4.1 and -no-sse4.2?
>
> That shouldn't happen. QT_COMPILER_SUPPORTS_SSE4_2 should not be defined, so
> this wouldn't evaluate to true:
>
> #if QT_COMPILER_SUPP
On Thursday 23 July 2015 23:03:25 René J. V. Bertin wrote:
> > I will not take a patch that disables CRC32 due to a compiler bug in an
> > unsupported configuration (LTO), especially if it's already fixed in the
> > latest version.
>
> But what about the fact that that those intrinsics are still u
Thiago Macieira wrote:
> You'll need to test with upstream Clang 3.7 and 3.8 to verify whether the
> issue is fixed. Apple's "random point in the release cycle plus random set of
> patches" Clang is not a good testbed for reporting compiler failures.
I'd agree with you if it weren't so damn diffi
On Thursday 23 July 2015 20:35:48 René J. V. Bertin wrote:
> Thiago Macieira wrote:
> > So this is a compiler bug.
> >
> > Sorry, please try GCC.
>
> On OS X?!
If you want the feature, either switch compilers or fix the bug in this
compiler. The only other option is to stop using the feature.
Thiago Macieira wrote:
> So this is a compiler bug.
>
> Sorry, please try GCC.
On OS X?!
R
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
On Thursday 23 July 2015 11:01:58 René J.V. Bertin wrote:
> Thiago Macieira wrote:
> > That's qhash.cpp (the only place where we use _mm_crc32_xxx()).
> >
> > This sounds like qhash.cpp was compiled with -march=native but *linked*
> > without. Can you confirm that you see the compiler options pass
On Thursday 23 July 2015 10:31:01 René J. V. Bertin wrote:
> And actually, I'm now fooling around with a project that just builds qtbase
> (5.4.2), and it seems that I need -r even immediately after calling
> configure.
configure should generate exactly one Makefile: the top-level.
> > That's als
Thiago Macieira wrote:
> That's qhash.cpp (the only place where we use _mm_crc32_xxx()).
>
> This sounds like qhash.cpp was compiled with -march=native but *linked*
> without. Can you confirm that you see the compiler options passed on the
> linker command-line (-O2 -march=native, etc.)?
Well, e
Thiago Macieira wrote:
> That won't work if you already have a build. The propagation only works if
> there are no subdirectory Makefiles yet.
>
> If you need to regenerate all the Makefiles, add -r (recursive):
>
> qmake -r -config ltcg $srcdir
Actually, I did, because without -r nothing happe
On Wednesday 22 July 2015 23:20:40 René J. V. Bertin wrote:
> Thiago Macieira wrote:
> > $ git name-rev --tags 1bd27f24fb7f7d82f4b67cffe43e0af644709106
> > 1bd27f24fb7f7d82f4b67cffe43e0af644709106 tags/v5.4.0-alpha1~525
> >
> > It should work on 5.4 then. The fix for static libraries came with 5.4
Thiago Macieira wrote:
> $ git name-rev --tags 1bd27f24fb7f7d82f4b67cffe43e0af644709106
> 1bd27f24fb7f7d82f4b67cffe43e0af644709106 tags/v5.4.0-alpha1~525
>
> It should work on 5.4 then. The fix for static libraries came with 5.4.1,
> though.
Ha, indeed, it's a little bit more complicated when do
On Wednesday 22 July 2015 21:57:57 René J. V. Bertin wrote:
> > qtbase:
> > ./configure [...]
> > qmake -config ltcg
>
> When was that syntax introduced? I'm getting an error trying it even with
> qmake 5.4.2 .
$ git name-rev --tags 1bd27f24fb7f7d82f4b67cffe43e0af644709106
1bd27f24fb7f7d82f4b67c
Thiago Macieira wrote:
> No need to look further. Neither QtScript nor QtWebKit will link with LTO.
> Turn it off for those two.
Ahhh ...
> Also, for QtGui (in both Qt 4 and 5), you need to be careful with the code for
> SSE2 and SSSE3. Until I applied certain fixes to Qt 5, those would cause t
On Wednesday 22 July 2015 19:50:27 René J.V. Bertin wrote:
> Hi,
>
> I'm experimenting with gcc-5.1 and link-time optimisation on Linux. I
> configure with
>
> CC = gcc-5
> CXX = g++-5
> CFLAGS += -O3 -ftracer -ftree-vectorize -flto -fuse-linker-plugin
> CXXFLAGS += -O3 -ftracer -ftree-vectorize
23 matches
Mail list logo
