Use of C11 atomics in Hercules fails to compile due to compiler errors at certain levels

[ghost]

Presumably due to the CPU being a model name : Intel(R) Celeron(R) CPU G550 @ 2.60GHz

Running make after ./configure --disable-interlocked-access-facility-2 works fine.

But: Otherwise, make terminates due to error compiling hatomic.h with

/bin/bash ./libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I.  -I. -I./decNumber -I. -DPKGDATADIR=\"/usr/local/share/hercules\" -DMODULESDIR=\"/usr/local/lib/hercules\" -DHERC_LOCALEDIR=\"/usr/local/share/locale\"  -W -Wall  -g3 -ggdb3 -O3 -march=native -m128bit-long-double -minline-stringops-dynamically -fomit-frame-pointer -MT hsys.lo -MD -MP -MF .deps/hsys.Tpo -c -o hsys.lo hsys.c
 gcc -DHAVE_CONFIG_H -I. -I. -I./decNumber -I. -DPKGDATADIR=\"/usr/local/share/hercules\" -DMODULESDIR=\"/usr/local/lib/hercules\" -DHERC_LOCALEDIR=\"/usr/local/share/locale\" -W -Wall -g3 -ggdb3 -O3 -march=native -m128bit-long-double -minline-stringops-dynamically -fomit-frame-pointer -MT hsys.lo -MD -MP -MF .deps/hsys.Tpo -c hsys.c  -fPIC -DPIC -o .libs/hsys.o
In file included from hatomic.h:85:0,
                 from hstdinc.h:244,
                 from hsys.c:8:
hatomic.h:88:10: error: missing binary operator before token "("
 #if 2 == ATOMIC_CHAR_LOCK_FREE && !defined(DISABLE_IAF2)
         ^      
Makefile:2077: recipe for target 'hsys.lo' failed
make[2]: *** [hsys.lo] Error 1
make[2]: Leaving directory '/home/mike/Downloads/hyperion-master'
Makefile:2099: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/home/mike/Downloads/hyperion-master'
Makefile:1540: recipe for target 'all' failed
make: *** [all] Error 2

[ivan-w]

The issue is with some compilers which break C11 by having ATOMIC_CHAR_LOCK_FREE not a preprocessor constant.

--Ivan

[jphartmann]

And your bypass is the correct way to handle this.

[jphartmann]

What is your compiler level? And distro?

[ghost]

gcc version 4.9.2 (Ubuntu 4.9.2-10ubuntu13) Ubuntu 15.04

[ivan-w]

Note that we are in conflict John & I about this. (friendly conflict - no worries)

I'm still not convinced that we DO need to check if a char atomic operation should necessarily lock free (c11 operations may or may not be lock free but the end result is the same - it's just the implementation that is different).

Furthermore, this could be resolved at compile time (not at preprocessor time) - at which point the end result is the same but would work on implementations that do not treat ATOMIC_CHAR_LOCK_FREE as a preprocessor constant.

--Ivan

[ghost]

So it has nothing to do with the capabilties of the CPU. I got sidetracked by the rather cheap Celeron on my one machine, whereas all my other tests where on OpensSUSE 13.1, albeit Core-i7. In that case the title of the issue would be wrong and I suppose it can be closed anyhow. The compile failure in hatomic.h is disconcerting at first but the comments in the code gave some hints on what to do. Thanks a lot.

[dasdman]

GCC 4.9 stdatomic.h and Clang 3.6 packaging are in error.

[ivan-w]

In error agreed

But the error is easy to get by...

Either we do NOT look for lock free atomic operations (because I am still not convinced we need to check it) or...

We turn the test into a "compiler" test instead of a preprocessor test (the results are the SAME when using optimization) because although the ATOMIC_*_LOCK_FREE macros are not preprocessor constants (as they should be) they are C constants and are evaluated at compilation timer (so are evaluated then - and not at run time).

--Ivan

[jphartmann]

Clang 3.6 C11 atomics work on Ubuntu 14.4. I installed it with synaptic.

So don't blindly test the compiler version.

[xychix]

This also happens for me on kali 2 (sane) in virtual box

root@hercules:~/mainframe/hyperion# uname -a Linux hercules 4.0.0-kali1-686-pae #1 SMP Debian 4.0.4-1+kali2 (2015-06-03) i686 GNU/Linux

root@hercules:~/mainframe/hyperion# gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/i586-linux-gnu/4.9/lto-wrapper Target: i586-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.9.2-10' --with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.9 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-i386/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-i386 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-i386 --with-arch-directory=i386 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-targets=all --enable-multiarch --with-arch-32=i586 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=i586-linux-gnu --host=i586-linux-gnu --target=i586-linux-gnu Thread model: posix gcc version 4.9.2 (Debian 4.9.2-10) root@hercules:~/mainframe/hyperion#

I've followed http://pastebin.com/raw/umhdBsPu

./configure --enable-cckd-bzip2 --enable-regina-rexx --disable-interlocked-access-facility-2

seems to help out there.

[ivan-w]

Mark,

C11 atomics are broken in both gcc 4.9 and clang 3.5 (Some of the constants which are guaranteed by C11 to be resolved as preprocessor constants are actually function calls).

Using clang 3.6 (but you may have to install it yourself) produces a clean build with IAF2 enabled.

--Ivan

On 1/13/2016 9:44 PM, Mark Bergman (xychix) wrote:

This also happens for me on kali 2 (sane) in virtual box

Linux hercules 4.0.0-kali1-686-pae #1 SMP Debian 4.0.4-1+kali2 (2015-06-03) i686 GNU/Linux root@hercules:~/mainframe/hyperion# gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/i586-linux-gnu/4.9/lto-wrapper Target: i586-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.9.2-10' --with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.9 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-i386/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-i386 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-i386 --with-arch-directory=i386 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-targets=all --enable-multiarch --with-ar ch-32=i5 86 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=i586-linux-gnu --host=i586-linux-gnu --target=i586-linux-gnu Thread model: posix gcc version 4.9.2 (Debian 4.9.2-10) root@hercules:~/mainframe/hyperion# |

I've followed http://pastebin.com/raw/umhdBsPu

./configure --enable-cckd-bzip2 --enable-regina-rexx --disable-interlocked-access-facility-2

seems to help out there.

— Reply to this email directly or view it on GitHub https://github.com/hercules-390/hyperion/issues/76#issuecomment-171426832.

[Fish-Git]

I believe @dasdman was supposed to be working on a "fix" for this issue (workaround really), but since we have not heard back from him in quite some time I can only presume he's swamped with other things, so I am going to mark this issue as "STALLED".

[srorso]

Issue also affects Debian 8.4 (Jesse); symptoms exactly as reported in FanDjango's original post. ATOMIC_*_LOCK_FREE are defined in stdatomic.h as macros, not as preprocessor contstants, exactly as described as Ivan wrote in his 22-Oct-2015 post.

Interesting note: /usr/include/c++/4.9.2/bits/atomic.base.h does define ATOMIC_*_LOCK_FREE as preprocessor constants in the form:

define ATOMIC_LOCK_FREE GCC_ATOMIC___LOCK_FREE

Output from bldlvlck:

OK autoconf requires 2.64, found 2.69 OK automake requires 1.9, found 1.14.1 OK flex requires 2.5, found 2.5.39 OK gawk requires 3.0, found 4.1.1 OK gcc requires 3, found 4.9.2 OK grep requires 1, found 2.20 OK m4 requires 1.4.6, found 1.4.17 OK make requires 3.79, found 4.0 OK perl requires 5.6, found 5.20.2 OK sed requires 3.02, found 4.2.2

Output excerpt from make after configure with no options:

/bin/bash ./libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I.  -I. -I./decNumber -I. -DPKGDATADIR=\"/usr/local/share/hercules\" -DMODULESDIR=\"/usr/local/lib/hercules\" -DHERC_LOCALEDIR=\"/usr/local/share/locale\"  -W -Wall  -g3 -ggdb3 -O3 -march=native -m128bit-long-double -minline-stringops-dynamically -fomit-frame-pointer -MT hsys.lo -MD -MP -MF .deps/hsys.Tpo -c -o hsys.lo hsys.c
 gcc -DHAVE_CONFIG_H -I. -I. -I./decNumber -I. -DPKGDATADIR=\"/usr/local/share/hercules\" -DMODULESDIR=\"/usr/local/lib/hercules\" -DHERC_LOCALEDIR=\"/usr/local/share/locale\" -W -Wall -g3 -ggdb3 -O3 -march=native -m128bit-long-double -minline-stringops-dynamically -fomit-frame-pointer -MT hsys.lo -MD -MP -MF .deps/hsys.Tpo -c hsys.c  -fPIC -DPIC -o .libs/hsys.o
In file included from hatomic.h:85:0,
                 from hstdinc.h:247,
                 from hsys.c:8:
hatomic.h:88:44: error: missing binary operator before token "("
 #if 2 == ATOMIC_CHAR_LOCK_FREE && !defined(DISABLE_IAF2)
              ^
Makefile:2082: recipe for target 'hsys.lo' failed
make[2]: *** [hsys.lo] Error 1

[Fish-Git]

Fixed in commit f71ec1f7fa231707f4e65cce5c8803c67a8f518b

[Fish-Git]

@FanDjango, @ivan-w, @jphartmann, @dasdman and @xychix (and anyone else not listed who are also impacted by this issue or are otherwise experiencing the same problem):

I am temporarily re-opening this issue to obtain feedback regarding a subsequent patch I've developed that I'm hoping does a better job at resolving this issue once and for all.

You can download my patch via the following GitHub gist:

• c11-hatomics.patch

The above patch defines a new macro function (called HC_GET_C11_LOCK_FREE_VALUE) that configure.ac uses to obtain the actual ATOMIC_CHAR_LOCK_FREE value, regardless of whether it is defined as a constant numeric value (as it should be per C11 specs) or as a return code value from a run-time function call (as it is for broken versions of GCC).

It then uses this value to define a new, differently named, config.h macro to that same value (which the hatomics.h header file then uses to make its decision with).

The version of gcc and clang that I have is not one of the broken versions so I am unable to adequately test it myself, which is why I'm asking those of you who do have (are running with) a broken version of gcc/clang (Ivan and FanDjango and xychix) to please download and apply my patch to current git (f71ec1f7fa231707f4e65cce5c8803c67a8f518b) and then re-do ./autogen.sh && ./configure ... && make to see whether or not it successfully resolves this issue. (Please remember to not specify the --disable-interlocked-access-facility-2 workaround when you do your configure too!)

As for Ivan, John, Mark and Steve, being fellow Hercules developers, I'd appreciate your feedback regarding the patch's overall look and feel (implementation/technique).

Thanks!

[Fish-Git]

As for Ivan, John and Mark, being fellow Hercules developers, ...

(OOPS!) A thousand pardons, Steve! GitHub didn't list your name in its list of participants for some reason (either that or I'm just blind). I would very much appreciate your feedback as well of course since you too are also a fellow Hercules developer!

(I can't believe I left him out! How totally embarrassing!)

[srorso]

Hi Fish:

No worries....so please don't worry.

I'll take a look tomorrow. I've seen this issue when I build on Debian but that doesn't happen often because I've buried myself in binary floating point.

I'm glad you're tackling this....I'll benefit when I run the *nix validation of Softfloat 3a.

Best regards, Steve Orso

On Jul 21, 2016, at 1:42 PM, Fish-Git notifications@github.com wrote:

As for Ivan, John and Mark, being fellow Hercules developers, ...

(OOPS!) A thousand pardons, Steve! GitHub didn't list your name in its list of participants for some reason (either that or I'm just blind). I would very much appreciate your feedback as well of course since you too are also a fellow Hercules developer!

(I can't believe I left him out! How totally embarrassing!)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[ghost]

Hi all,

unfortunately I no longer have the environment where the the problem occurred so I cannot confirm.

Best Regards and thanks!

[srorso]

Hi Fish:

I'm not very good at automake (hint: I am not good at all at automake)...but your patch seems clear, well thought-out, and relatively easy for humans to understand.  

It seems slightly silly to have to run ten trivial c compiles to get a correct answer to the question of whether the atomics are lock-free, but a correct answer is an absolute requirement.  I am not sure how one could better given the difference between broken GCC and C11 compliant compilers.  

By the way, thanks for catching the mis-spelling in EXTPKG_DIRS.  There's lots of lint left in my test cases, and I'm grateful to anyone with the inclination to point out what does not make sense or is simply wrong.  Humans have to understand the code too....  

Back to the world of BFP.  History lesson coming....

Best Regards, Steve Orso

[Fish-Git]

unfortunately I no longer have the environment where the the problem occurred so I cannot confirm.

Oh well. @ivan-w? What about you? I believe you were one of the people that had a broken version of gcc. Does the patch work for you?

[Fish-Git]

dasdman called me on the phone to point out that we shouldn't be testing only SAFE_ATOMIC_CHAR_LOCK_FREE but rather we should also be checking SAFE_ATOMIC_SHORT_LOCK_FREE, SAFE_ATOMIC_LONG_LOCK_FREE and SAFE_ATOMIC_LLONG_LOCK_FREE too (and possibly SAFE_ATOMIC_POINTER_LOCK_FREE as well) since our H_ATOMIC_OP macro is after all designed for not just 8-bit (char) atomic operations but also 16-bit, 32-bit and 64-bit atomic operations as well:

    #if SAFE_ATOMIC_CHAR_LOCK_FREE    == ALWAYS_ATOMIC && \
        SAFE_ATOMIC_SHORT_LOCK_FREE   == ALWAYS_ATOMIC && \
        SAFE_ATOMIC_LONG_LOCK_FREE    == ALWAYS_ATOMIC && \
        SAFE_ATOMIC_LLONG_LOCK_FREE   == ALWAYS_ATOMIC && \
        SAFE_ATOMIC_POINTER_LOCK_FREE == ALWAYS_ATOMIC
      #define CAN_IAF2      IAF2_C11_STANDARD_ATOMICS

He said it was important not just for the previously mentioned reason but also because some compilers might not define all types identically. That is, it's possible for it to have atomic char support but not short, long or llong. That is to say, we shouldn't presume if char operations are always atomic that short, long and llong operations are also always atomic, so we should be testing each of them.

I will update my patch appropriately.

[Fish-Git]

(Oops!) I just noticed I'm testing SAFE ATOMIC... instead of C11 ATOMIC...!

The above tweak should be:

    #if C11_ATOMIC_CHAR_LOCK_FREE    == ALWAYS_ATOMIC && \
        C11_ATOMIC_SHORT_LOCK_FREE   == ALWAYS_ATOMIC && \
        C11_ATOMIC_LONG_LOCK_FREE    == ALWAYS_ATOMIC && \
        C11_ATOMIC_LLONG_LOCK_FREE   == ALWAYS_ATOMIC && \
        C11_ATOMIC_POINTER_LOCK_FREE == ALWAYS_ATOMIC
      #define CAN_IAF2      IAF2_C11_STANDARD_ATOMICS

I'll fix that too.

[ivan-w]

On 7/23/2016 2:52 PM, Fish-Git wrote:

dasdman called me on the phone to point out that we shouldn't be testing /only/ |SAFE_ATOMIC_CHAR_LOCK_FREE| but rather we should /also/ be checking |SAFE_ATOMIC_SHORT_LOCK_FREE|, |SAFE_ATOMIC_LONG_LOCK_FREE| and |SAFE_ATOMIC_LLONG_LOCK_FREE| too (and possibly |SAFE_ATOMIC_POINTER_LOCK_FREE| as well) since our |H_ATOMIC_OP| macro is after all designed for not just 8-bit (char) atomic operations but also 16-bit, 32-bit and 64-bit atomic operations as well:

 #if  SAFE_ATOMIC_CHAR_LOCK_FREE    == ALWAYS_ATOMIC && \
     SAFE_ATOMIC_SHORT_LOCK_FREE   == ALWAYS_ATOMIC && \
     SAFE_ATOMIC_LONG_LOCK_FREE    == ALWAYS_ATOMIC && \
     SAFE_ATOMIC_LLONG_LOCK_FREE   == ALWAYS_ATOMIC && \
     SAFE_ATOMIC_POINTER_LOCK_FREE == ALWAYS_ATOMIC
   #define  CAN_IAF2       IAF2_C11_STANDARD_ATOMICS

He said it was important not just for the previously mentioned reason but also because some compilers might not define all types identically. That is, it's possible for it to have atomic char support but not short, long or llong. That is to say, we shouldn't presume if char operations are always atomic that short, long and llong operations are also always atomic, so we should be testing each of them.

I will update my patch appropriately.

Do we need anything other than 8 bit byte atomic operations ?

Again although IAF2 guarantees that a OI/NI/XI/OIY/NIY/XIY is seen as complete by all other components when the instruction completes (operand synchronization), no other instruction requires this. Namely, update consistency doesn't require this (it only requires that WHEN it is seen, it is not seen as done or not done - but not anything in between).

But then again, I could be wrong !

--Ivan

[ivan-w]

On 7/23/2016 3:16 PM, Fish-Git wrote:

(Oops!) I just noticed I'm testing `SAFE/ATOMIC... instead of _C11__ATOMIC...! The above tweak _should/ be:

 #if  C11_ATOMIC_CHAR_LOCK_FREE    == ALWAYS_ATOMIC && \
     C11_ATOMIC_SHORT_LOCK_FREE   == ALWAYS_ATOMIC && \
     C11_ATOMIC_LONG_LOCK_FREE    == ALWAYS_ATOMIC && \
     C11_ATOMIC_LLONG_LOCK_FREE   == ALWAYS_ATOMIC && \
     C11_ATOMIC_POINTER_LOCK_FREE == ALWAYS_ATOMIC
   #define  CAN_IAF2       IAF2_C11_STANDARD_ATOMICS

I'll fix that too.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/hercules-390/hyperion/issues/76#issuecomment-234717707, or mute the thread https://github.com/notifications/unsubscribe-auth/ABjMW7u5T60UY0pgdRkuQHgS3oLchD6Eks5qYhRIgaJpZM4GT2_W.

Unless I am wrong, IAF2 is ONLY for immediate 1 byte logical operations.... so CHAR_LOCK_FREE should be sufficient.

(Then again, and again WHY does it HAVE to be LOCK free ?)

--Ivan

[jphartmann]

Ivan is right; IAF2 is one-byte operands exclusively. (Load And Add also requires atomic access, but that is another kettle of fish as it is IAF1 ;-)

To answer Ivan's question:

If you call an atomic operation function that is not lock free, then the subroutine obtains a lock that protects the operation from other atomic operations, but not necessarily from storage references in general, just as PLO does not interoperate with CS.

After all we have to cast real storage to atomic_ to be able to call the atomic function. So we are cheating. The only way to be sure we aren't found out is to ensure that no hidden locks are acquired.

Spinning on assignment as done by gcc on Intel is OK; it is still atomic.

OK Ivan? Can we put this to rest now?

[ivan-w]

I'm going to say this :

This is an implementation issue. (If IAF2 requires an external lock - I don't care)

Can I live with the restriction : Absolutely ! (It would certainly hamper performances). I'm just worried about the complications implied about something that will be VERY rare and will occur on exotic architectures.

Ivan

[ivan-w]

John, Fish, all...

I guess I didn't read your answer thoroughly enough before answering...

Your explanation is satisfactory to me and makes sense now !

It now DOES make sense to me that in order to implement IAF2, lock free C11 operations are a requirement.

All my apologies for all the unnecessary fuss about all this...

On a side note, Fish's implementation to circumvent the broken GCC C11 implementation does pass my basic compile test (gcc 4.9.2 implementation is broken at compile time - since the macro is not a preprocessor macro, but not at run time - the generated code looks appropriate for an IAF2 implementation at least on x86_64).

Thanks for all your hard work guys !

Ivan

[dlrourke]

I'm using VS 15 CE (with the include for win32.mak). With your new (as of 35 minutes ago) updates, a build of hyperion with VS 15 CE now fails because stdatomic.h can't be found in the usual places.

[Fish-Git]

Damn! I didn't bother to test w/VS2015. Sorry about that Dan. :(

I'll re-open and look into this right away and get back to you. I'm sure it's probably something simple.

[Fish-Git]

s/b fixed now by commit 74427d518d8fad91a0f4b81084f32263508be634

Closing.

[Fish-Git]

This issue is closely related to issue #36

[ivan-w]

I will try building herc on MSVC VS2015 and check that IAF2 is available.

Ivan

[ivan-w]

Pulled GIT a few minutes ago :

HHC01413I Hercules version 4.0.0.8604-g74427d5 (4.0.0.8604)

And....

HHC00890I Facility( INTERLOCKED_ACCESS_2 ) Enabled

Built with VS2015 CE

So it looks good.

Ivan

[jphartmann]

I am reopening this issue because people continue to find differently broken compilers out there.

[Fish-Git]

Thomas Valerio reported the following in the main hercules-390 group:

(Note: system is CentOS 6.8)

[root@thirty-six src]# mkdir hyperion-master
[root@thirty-six src]# git clone
https://github.com/hercules-390/hyperion.git hyperion-master/
Initialized empty Git repository in /usr/local/src/hyperion-master/.git/
remote: Counting objects: 43188, done.
remote: Compressing objects: 100% (114/114), done.
remote: Total 43188 (delta 47), reused 0 (delta 0), pack-reused 43074
Receiving objects: 100% (43188/43188), 19.05 MiB | 9.77 MiB/s, done.
Resolving deltas: 100% (33673/33673), done.
[root@thirty-six src]# cd hyperion-master/
[root@thirty-six hyperion-master]# ./autogen.sh
Note: if you do not see a 'All processing successfully completed.'
message when this script completes, then something went wrong and
you should examine the output to try and determine what it was that
went wrong.

aclocal... OK. (25% done)
autoheader... OK. (50% done)
automake... OK. (75% done)
autoconf... OK. (100% done)

All processing successfully completed.

You may now run ./configure in order to create a custom Makefile
that is suitable for your platform and environment.
[root@thirty-six hyperion-master]# ./configure
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking target system type... x86_64-unknown-linux-gnu

...

config.status: creating man/Makefile
config.status: creating m4/Makefile
config.status: creating decNumber/Makefile
config.status: creating config.h
config.status: executing depfiles commands
[root@thirty-six hyperion-master]# make
make all-recursive
make[1]: Entering directory `/usr/local/src/hyperion-master'
Making all in decNumber
make[2]: Entering directory `/usr/local/src/hyperion-master/decNumber'
CC decContext.lo
CC decimal32.lo
CC decimal64.lo

...

CC cpu.lo
In file included from cpu.c:1915:
cpu.c: In function 'z900_run_cpu':
cpu.c:1721: warning: variable 'regs' might be clobbered by 'longjmp' or
'vfork'
cpu.c: In function 's370_run_cpu':
cpu.c:1721: warning: variable 'regs' might be clobbered by 'longjmp' or
'vfork'
In file included from cpu.c:1909:
cpu.c: In function 's390_run_cpu':
cpu.c:1721: warning: variable 'regs' might be clobbered by 'longjmp' or
'vfork'
CC crypto.lo
CC dat.lo
CC decimal.lo
CC dfp.lo
CC diagmssf.lo
CC diagnose.lo
CC dyn76.lo
CC ecpsvm.lo
CC esame.lo
esame.c: In function 's370_and_immediate_y':
esame.c:6670: warning: implicit declaration of function '__atomic_and_fetch'
esame.c:6670: error: '__ATOMIC_SEQ_CST' undeclared (first use in this
function)
esame.c:6670: error: (Each undeclared identifier is reported only once
esame.c:6670: error: for each function it appears in.)
esame.c: In function 's370_exclusive_or_immediate_y':
esame.c:7050: warning: implicit declaration of function '__atomic_xor_fetch'
esame.c:7050: error: '__ATOMIC_SEQ_CST' undeclared (first use in this
function)
esame.c: In function 's370_or_immediate_y':
esame.c:7418: warning: implicit declaration of function '__atomic_or_fetch'
esame.c:7418: error: '__ATOMIC_SEQ_CST' undeclared (first use in this
function)
In file included from esame.c:8468:
esame.c: In function 'z900_and_immediate_y':
esame.c:6670: error: '__ATOMIC_SEQ_CST' undeclared (first use in this
function)
esame.c: In function 'z900_exclusive_or_immediate_y':
esame.c:7050: error: '__ATOMIC_SEQ_CST' undeclared (first use in this
function)
esame.c: In function 'z900_or_immediate_y':
esame.c:7418: error: '__ATOMIC_SEQ_CST' undeclared (first use in this
function)
make[2]: *** [esame.lo] Error 1
make[2]: Leaving directory `/usr/local/src/hyperion-master'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/local/src/hyperion-master'
make: *** [all] Error 2
[root@thirty-six hyperion-master]

Thomas? What does your ./configure report for:

checking if C11 atomics are available...

Does it report 'yes'? Or 'no'?

[Fish-Git]

And of course we need to know your compiler details too, as requested by John in the main hercules-390 group.

[Fish-Git]

Thomas contacted me off list and I found my bug. Should be fixed now as/of commit e43b2061124c5fb1fad708decef0e1672213e978. Closing issue. Let's hope it now stays closed!