< cfields>
but for clang, it sounds like anything pre-processesed could still end up with SIGILL :(
< cfields>
will refresh my memory and have a look tomorrow.
< gmaxwell>
hm? you cannot use -msse4.2 on a file with functions that will be called on a system without it... as the insstructions could end up anywhere.
< gmaxwell>
g++ at least has the ability to push the compile flags on a function by function basis and has a linker override, so we could avoid writing the detection ourselves... I dunno if clang supports those extensions yet though.
<@wumpus>
gmaxwell: right
< cfields>
gmaxwell: leveldb checks at runtime before calling it
< gmaxwell>
cfields: 'it'? meaning any file compiled with -msse4.2 ?
<@wumpus>
the program needs to check yourself before calling into it, and there should be no global cons/destructors in the file
< cfields>
gmaxwell: the object is segregated, yes.
<@wumpus>
there should be only one file compiled with msse4.2
<@wumpus>
the only place where I could see it potentially go wrong is on whole-program-optimization
<@wumpus>
cfields: yep! exactly as it shoudl be
< cfields>
wumpus: and the fact that the check itself is compiled with sse4.2 :(
< cfields>
i wish that'd broken that out separately
<@wumpus>
yea, the check itself must be outside that file
<@wumpus>
otherwise it's kind of self-defeating
< cfields>
it's not though :(
<@wumpus>
unless you use openssl-style detection (catch SIGILL)
<@wumpus>
but that's not necessary for intel
<@wumpus>
seems that should be an upstream patch then
<@wumpus>
gah,clang documentation site is offline
< cfields>
wumpus: yea. I suspect it probably always works in practice because the compiler doesn't find any useful sse4.2 optilms to use for the cpuid check. But it always could, and break.
<@wumpus>
it could break once the compiler becomes smarter
< cfields>
right. upstream patch to break it out 100% would be cleaner. Will do.
<@wumpus>
I don't know enough about the standard to be able to state whether that's a bug in the compiler (as this is still experimental) or makes sense because of the new spec
<@wumpus>
luckily we now pass std=c++11 so don't have to worry about it