Hi,

I just noticed that your code relies on __SSE3__ (and __SSSE3__) being defined for the SSE3 (and SSSE3) code paths to be generated. I'm compiling using ICC in Visual Studio, with /QxHost (on a Core i7) and neither symbol is being automatically defined.

I'm not sure if this is specific to ICC or whether the same is true under VC++.

Tom

We don't "rely" on that, we just check whether it's defined to see if the user has enabled SSE3.

No current architecture has SSE3 enabled by default, because in each architecture line, there are CPU's that don't have SSE3.

For example:
x86-64 doesn't have SSE3 by default because AMD Athlon 64 CPUs only have SSE2.

If you want SSE3, you need to enable it explicitly, see your compiler's docs.

Yeah I've defined it now. I was just assuming that those were constants which GCC (say) defined automatically based on the target machine.

Maybe you should sign-post this in the docs somewhere? (Or maybe you have already but I just missed it?)

Thanks.

To clarify:

__SSE3__ is automatically defined by the compiler whenever the SSE3 instruction set is enabled.

for example with GCC you do:

g++ -msse3 ...

you never define __SSE3__ manually.

Ahha well that was my point. I'm having to define __SSE3__ manually on ICC, despite having the architecture switch etc.

I'm not sure what ICC is defining instead.

Ah? I thought it would do the same as GCC (i don't have icc here).

OK, that's very interesting, let us know when you know the correct symbol to check for.

indeed it seems ICC does not define the same macro for each OS, here is the doc for linux:

http://software.intel.com/sites/product ... os_lin.htm

and here for windows:

http://software.intel.com/sites/product ... os_win.htm

So if it's really the case then I don't know how to detect them...

Ahh good find. The doc I saw gave me the impression that it was at least supposed to define __SSE3__ etc., so I was rather assuming it was a bug when using /QxHost. I created a thread on the Intel forums here:

http://software.intel.com/en-us/forums/ ... pic/68780/

No replies as yet though.

OK it seems from that thread that it's just a compiler bug, so there's no need on your end to change anything.

Tom

ok, thank you for the information.