PPC64 - may have problems with atomic make check tests

[hppritcha]

@opoplawski is reporting a problem with the 2.0.2 rc1 candidate on PPC64:

There's a suspect PR #2178 - looks like only major change with PPC atomics between 2.0.1 (where the make distcheck works) and 2.0.2rc.

https://www.mail-archive.com/devel@lists.open-mpi.org//msg19851.html

[hppritcha]

@hjelmn if you are able to reproduce please try. Otherwise, @jjhursey could someone from IBM take a look at this?

[PHHargrove]

FWIW I tested the same RC on multiple PPC64 w/o failures of "make check".
On big-endian POWER7, my coverage included gcc-4.4.7 and 4.8.3, as well as xlc-13.1.
On little-endian POWER8, my coverage included gcc-4.9.2, xlc-13.1 and pgi-16.10.

Additionally, I have just now tried gcc-6.2 on both platforms and pass "make check" just fine.

v2.x defaults to using the gcc builtin atomics when present. So, changes to the inline asm in PR #2178 might be unrelated unless some non-default configure flags or a compiler was used which lacks GNU inline asm support (note xlc-13.1 for Linux does provide the gcc builtins).

[opoplawski]

Full Fedora build logs:
ppc64le - https://kojipkgs.fedoraproject.org//work/tasks/704/16970704/build.log
ppc64 - https://kojipkgs.fedoraproject.org//work/tasks/706/16970706/build.log

gcc is 6.2.1-2.fc26

[PHHargrove]

I am able to reproduce by configuring with --disable-builtin-atomics, with both gcc-4.x and gcc-6.2 on both big-endian POWER7 and little-endian POWER8.

@hjelmn my OpenPOWER VM you used for PR #2178 has gcc-5.4, but I suspect (given failures w/ 4.x and 6.2) that it will also reproduce the problem if you lack alternatives.

[opoplawski]

I see this in the configure logs:

checking if gcc supports GCC inline assembly... yes
checking if gcc supports DEC inline assembly... no
checking if gcc supports XLC inline assembly... no
checking for assembly format... default-.text-.globl-:--.L-@-1-1-0-1-1
checking for assembly architecture... POWERPC64
checking for builtin atomics... BUILTIN_NO
checking for pre-built assembly file... no (not in asm-data)
checking whether possible to generate assembly file... yes
checking for atomic assembly filename... atomic-local.s

[PHHargrove]

@opoplawski Yes, I also noticed checking for builtin atomics... BUILTIN_NO in your logs, though I do not know the cause. However, it does explain why I didn't find this in my previous testing, and why --disable-builtin-atomics reproduces it.

[opoplawski]

It turns out that the default for --enable-builtin-atomics is disabled if not specified. Is that expected? Should I be specifying --enable-builtin-atomics in my builds?

[PHHargrove]

@opoplawski

I realize now that my original (no error) builds included --enable-debug while my later ones removed that flag in addition to adding --disable-builtin-atomics. So, I am not certain any longer about what I claimed about which atomics are enabled by default and about the correlation between disabling the builtins and reproducing your error.

I am going to step away from this issue now, and leave it to Nathan and Josh (who probably have a better idea how to fix the problem).

[opoplawski]

I'll note that it looks like if I set --enable-builtin-atomics my builds succeed: https://koji.fedoraproject.org/koji/taskinfo?taskID=17005965

[hppritcha]

@opoplawski is it okay to require --enable-builtin-atomics for your purposes for 2.0.2?

[opoplawski]

Seems fine to me - I know nothing about these options though.