[Interest] building Qt 4.8.7 with gcc 5 and link-time optimisation on Linux

[Thiago Macieira]

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 tried the options. I'll see if I
> > can
> > reproduce the issue and report back.
> 
> Sadly, I can. I cannot find any definition of QT_COMPILER_SUPPORTS_SSE4_2
> (is it maybe generated dynamically?!). 

It should be in qconfig.h.

> I checked, it's not auto-vectorised
> code by the compiler that uses SSE4, but indeed that block of code in
> qhash.cpp that shouldn't be included with -mno-sse4.2 . I'm a bit at a loss
> re: how to debug this. I'm guessing that you'd have noticed if clang didn't
> handle macros like QT_COMPILER_SUPPORTS(x) -> (QT_COMPILER_SUPPORTS_ ## x -
> 0) correctly!

The first thing to check is whether those macros did expand as expected. Check 
the preprocessed source of qhash.cpp (with the exact same compiler flags, only 
replacing -c with -E). Are the _mm_crc32_xxx calls there?

For Clang, QT_COMPILER_SUPPORTS_HERE(x) expands to a check defined(__x__) [in 
this case, if __SSE4_2__ is defined].

Ah, that is actually the issue.

You're on OS X. All 64-bit Mac hardware supports SSE 4.2, so that feature is 
always enabled when compiling 64-bit code. The -no-sse4.2 option has no effect 
on 64-bit, the same way that the -no-ssse3 option has no effect in 32-bit code.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center