Many Warnings with Clang 4.0.1 on OSX

[ax3l]

EVPath 4.4.0 throws a lot of noisy warnings in ADIOS 2.5.0 when compiled with Clang 4.0.1 on OSX (Apple-Darwin13.4.0).

Reference: https://dev.azure.com/conda-forge/feedstock-builds/_build/results?buildId=76704 in conda-forge/adios2-feedstock#8

Related to, but not causing the build error in ornladios/ADIOS2#1804

Compiler: Clang 4.0.1 on Apple-Darwin13.4.0

Generated warnings from -Wformat, dominantly in CMtrace_out functions and formatters: warnings.txt

[eisenhauer]

Hi Axel! Happy to clean this up, but likely I need to be able to reproduce to know it's better. I have easy access to OSX 10.14.6, and am not seeing these errors with Apples Clang 11.0.0. But I know that Apples versioning isn't synced with Clang's. Suggestions on how I can reproduce this?

[ax3l]

Hi and thanks for your help!
I am also just using OSX on conda-forge to ship ADIOS2 artifacts to users. I think the main problem is the assumption of the that timings in string formatters (-Wformat) are of type long while they are ints on OSX.

The compiler complains about __darwin_suseconds_t which is the size of int32 on OSX. This happens via TRACE_TIME_PRINTDETAILS where tv.tv_usec is not casted to long but printed as %ld:
https://github.com/GTkorvo/evpath/blob/v4.4.0/cm_internal.h#L550
https://github.com/GTkorvo/evpath/blob/v4.4.0/cm_internal.h#L554

Probably that missing cast is all that is missing, the implementation detail that timeval::tv_usec is implemented as long equivalent on 64bit GNU/Linux and as 32bit int on recent OSX/FreeBSD?

As a side note, I see the printf formatters in CMtrace_out use %lx which is unsigned, but you might want to use %ld which is signed long int (aka long): https://stackoverflow.com/a/26223663/2719194

[eisenhauer]

So, yes, I see what would seem to be the nature of the issue in the warnings your getting. What I'm quite curious about is why I'm not seeing these particular warnings, not to avoid fixing it, but really to make sure there's not something else going on too. I loaded clang-9, rather than using the XCode version, and verified that __darwin_suseconds_t is indeed int32, but still no warnings.
Looking at my OSX build, it looks like CMake is finding clock_gettime(), therefore we're using the true condition in that "#ifdef HAVE_CLOCK_GETTIME" in cm_internal.h. I can force that to be undefined to help ensure that I've got the right fix, but it would be nice to know why you're getting different results from CMake. clock_gettime supposedly appeare=d in OSX 10.12. I'd been assuming that "Apple-Darwin13.4.0" might map to OSX 10.13.4, but maybe it's something different?

[ax3l]

It might be the specific compile flags, the build on conda-forge above uses

CXXFLAGS=-march=core2 -mtune=haswell -mssse3 -ftree-vectorize -fPIC -fPIE -fstack-protector-strong -O2 -pipe -stdlib=libc++ -fvisibility-inlines-hidden -std=c++14 -fmessage-length=0 -I$PREFIX/include -fdebug-prefix-map=$SRC_DIR=/usr/local/src/conda/adios2-2.5.0 -fdebug-prefix-map=$PREFIX=/usr/local/src/conda-prefix
+DEBUG_CXXFLAGS=-march=core2 -mtune=haswell -mssse3 -ftree-vectorize -fPIC -fPIE -fstack-protector-strong -O2 -pipe -stdlib=libc++ -fvisibility-inlines-hidden -std=c++14 -fmessage-length=0 -Og -g -Wall -Wextra -I$PREFIX/include -fdebug-prefix-map=$SRC_DIR=/usr/local/src/conda/adios2-2.5.0 -fdebug-prefix-map=$PREFIX=/usr/local/src/conda-prefix
14

so specifically -std=c++14 -O2 -pipe -stdlib=libc++ -Wall -Wextra

[eisenhauer]

Hmm. EVPath is all C, not C++, so I wouldn't think those flags would actually be applied even in the ADIOS2 build, though of course something else, like in CFLAGS, might be causing it. I've pushed a change into EVPath that seems to fix the TRACE_TIME_PRINTDETAILS warnings (at least when I force the use of clock_gettime). Probably what I should do is to create conda recipes for EVPath (and all its dependencies in GTKorvo) to try to sort things out more directly. But that might be a longer-term thing. Short term, I'll do a PR to pull these changes into ADIOS2 and hopefully we can see where that leaves us.

[eisenhauer]

OK, the PR containing the tweak to the TRACE_TIME_PRINTDETAILS has been merged with ADIOS2 master. Hopefully it cleans this stuff up for you. (I'm poking at Conda with the GTkorvo software stack each as separate packages, which would help get this sorted out a bit more directly.)

[ax3l]

It's #28 I guess? Thanks a lot!

I will close this now and re-open if this should re-appear.