> CXXFLAGS += -fsanitize=undefined
>
> Hmm… Do we need this?
On occasion.
When Whirlpool was failing its self tests under Intel's compiler (ICPC
and ICC), I used Clang and its undefined behavior sanitizer to locate
the offending code. That's where this mess came from (from misc.h):
template <class T> inline T rotrMod(T x, unsigned int y)
{
y %= sizeof(T)*8;
return T((x>>y) | (x<<(sizeof(T)*8-y)));
}
The modular reduction side stepped the undefined behavior by keeping
the shift amount less than or equal to a register size.
I also use -fsanitize=undefined and -fsanitize=address on my patches
to ensure they are not introducing undefined behavior or memory
errors. (In addition to -Wall -Wextra).
Clang's Asan (Address Sanitizer) is a good tool. It performs dynamic
analysis, all its positives are real hits, and does not emulate some
instructions like Valgrind.
Jeff
On Mon, Jan 5, 2015 at 6:33 AM, Mobile Mouse <[email protected]> wrote:
> On Jan 5, 2015, at 0:09 , Jeffrey Walton <[email protected]> wrote:
>
> Hmm, OK. Won’t impact me, as I don’t use non-Apple clang any more, but makes
> sense for the Crypto++ distro.
>
>
> Check it out... I'm on OS X 10.8.5, fully patched. No more "clang
> version" string - only "clang" string:
>
>
> Oh, I did - my logic was “this patch doesn’t make things worse for me, but
> helps somebody else”.
> As I said, it works.
>
> Sadly, I'm the guy who gave the string to Wei :( Its was around 2011
> or 2012, back when Apple provided Clang, and the version string was
> something like "Apple clang version ...". Now its "Apple LLVM ..."
> with a Clang version number. And if you build from scratch (or use a
> distro), its only "clang" string.
>
>
> It’s OK, you’ve atoned for your sin. :-)
>
> Now it’s Apple’s time. :-)
>
> # These are required on newer Mac OS X, as somehow they aren't set
> # up automatically even when the native CPU supports them.
> CXXFLAGS += -maes -mpclmul -mavx2
>
>
> I'm still using older stuff. I refused the OS X 10.9 upgrade because
> of moving the KeyChain to the iCloud. I don't do clouds.
>
>
> You mean - the older CPU that doesn’t have AES-NI, etc.?
>
> Do you know of any OS X machines that are [internet] accessible to test on?
>
>
> :-( Sorry, I don’t.
>
> It does not need CXXFLAGS (I think) because it’s linking only. Thanks for
> catching missing LDFLAGS! I’ve added them.
>
>
> The compiler driver (CXX) is invoking the linker (LD). The compiler
> driver will pick up some flags and automatically perform some linker
> magic (like implicitly adding libraries). To convince yourself, change
> CXXFLAGS to:
>
> CXXFLAGS += -stdlib=libc++
>
>
> Yes, but since I already have “-stdlib=…” in LDLIBFLAGS (setting matching
> what’s in CXXFLAGS!) that is passed to the linker, is it worth bothering?
>
> CXXFLAGS += -fsanitize=undefined
>
>
> Hmm… Do we need this?
>
> And let me know how linking goes ;) You can test it with a `make dynamic`.
>
>
> :-)
>
> I abhor “-arch x86_64 -arch i386”
>
> I've kinda grown to like it. The fat binaries make it easy to a
> library to a project. Maybe I'm getting too lazy in my old age.
>
>
> I don’t have spare disk space, and I don’t have a non-64-bit machines any
> more. So no point to complicate life with fat binaries for me.
>
> BTW, cryptopp-5.6.2 builds nicely with Apple native clang (Xode-6.1), and
> with gcc-4.8.3. However with gcc-4.9.1 the compiled executable
> (statically-linked!) crashes:
--
--
You received this message because you are subscribed to the "Crypto++ Users"
Google Group.
To unsubscribe, send an email to [email protected].
More information about Crypto++ and this group is available at
http://www.cryptopp.com.
---
You received this message because you are subscribed to the Google Groups
"Crypto++ Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
