v2.x: configury: fix asm atomic detection

[ggouaillardet]

there is no need to look for an assembly file when BUILTIN_GCC is used

Fixes #3032
Refs #3036

Signed-off-by: Gilles Gouaillardet [email protected]

(cherry picked from commit 2f4013c)

[ggouaillardet]

@hppritcha @rhc54 this fixes #3032
my analysis is that configure displays a false positive, and GCC builtin atomics are used.
so imho, this is not a blocker, though this would be nice to have when 2.1.0 is released

[ggouaillardet]

@hjelmn @rhc54 is opal/asm/asm-data.txt x86_64 is referred as AMD64.
my guess is that comes back from the Opteron debut days.

since this is not specific to AMD processors, should we rename this as X86_64 to avoid any confusion ? (this is a genuine question, and as far as i am concerned, i am fine with AMD64)
if we can reach a consensus, i will be happy to update the PR
fwiw, 32 bits is referred as IA32, so this could also be renamed to X86_32 or something else but vendor neutral.

[rhc54]

rename: absolutely! The two archs have diverged over time, and it is definitely misleading and confusing.

[ggouaillardet]

done in #3041
will cherry-pick after it passes CI

[hppritcha]

Is this fixing a correctness problem that impacts applications?

[rhc54]

probably could wait for 2.1.1

[jsquyres]

Breakdown of the two commits:

1. The AMD64->x86_64 rename feels cosmetic (misleading, yes, but no one has complained for quite a long time). Feels like it can wait for v2.1.1.
2. The BUILTIN_GCC fix feels like an optimization -- i.e., prevent some additional configure checks that aren't necessary if we're using builtins. This also feels like it can be deferred to v2.1.1.

Please let me know if these are wrong (i.e., this PR is needed for v2.1.0). Thanks!

[ggouaillardet]

@jsquyres the issue was initially reported by @rhc54 on #3032
here is a snippet of the configure output

11:10:41 checking for assembly architecture... AMD64
11:10:41 checking for builtin atomics... BUILTIN_GCC
11:10:41 checking for pre-built assembly file... no (atomic-amd64-linux
11:10:41 amd64-linux-nongas.s not found)
11:10:41 checking whether possible to generate assembly file... failed
11:10:41 configure: WARNING: Could not build atomic operations assembly file.
11:10:41 configure: WARNING: There will be no atomic operations for this build.
11:10:41 checking for atomic assembly filename... none

at first glance, an end user might legitimately think atomic operations could not be built because his/her genuine Intel processor was misidentified as an AMD processor.

the truth is everything is working just fine

• the processor is detected as a vendor neutral x86_64 (this is fixed by the AMD64-X86_64 rename commit)
• since BUILTIN_GCC atomics are used, there is no need to use the atomic operations assembly file,
  so there is no need to build it nor display a warning (once again, atomics are built though the warning message says otherwise), and this is fixed by the BUILTIN_GCC commit.

bottom line

• a bogus and misleading warning message is displayed
• BUILTIN_GCC atomics are built on x86_64 platforms
• AMD64 should be read as vendor neutral x86_64

strictly speaking, and imho, this PR is not mandatory for v2.1.0, though it would be nice
to add a few words about it in the README so confused users (if any) can be pointed to.

[jsquyres]

@ggouaillardet Thanks for the explanation.

@hppritcha Yes, perhaps we should add something to README.