On Jan 5, 2015, at 14:48 , Jeffrey Walton <[email protected]> wrote:
>> 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.
Well, even the latest release of Apple clang does not support this flag. And
since I’ve had unpleasant experience of having compiled code running correctly
when built by Xcode clang, but crashing with SEGV when built by clang installed
via Macports - I chose to stay away from Macports clang (and from Macports
gcc-4.9, which cannot produce a working CryptoPP).
Or do I need an extra tool to employ -fsanitize=undefined?
> 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.
