compile fails on Ubuntu with setjump() error for efea10417cf790a4378abcf58bfcc80731e847bc

[TJamesCorcoran]

this

git clone https://github.com/UpstandingHackers/hammer
cd hammer
scons

gives

scons: Reading SConscript files ...
scons: done reading SConscript files.
scons: Building targets ...
gcc -o build/opt/src/backends/regex.os -c -std=gnu99 -Wall -Wextra -Werror -Wno-unused-parameter -Wno-attributes -Wno-unused-variable -O3 -fPIC build/opt/src/backends/regex.c
build/opt/src/backends/regex.c: In function 'run_trace':
build/opt/src/backends/regex.c:209:75: error: argument 'trace' might be clobbered by 'longjmp' or 'vfork' [-Werror=clobbered]
 HParseResult *run_trace(HAllocator *mm__, HRVMProg *orig_prog, HRVMTrace *trace, const uint8_t *input, int len) {
                                                                           ^
cc1: all warnings being treated as errors
scons: *** [build/opt/src/backends/regex.os] Error 1

this uname -a

gives this

Linux bromine 3.13.0-74-generic #118-Ubuntu SMP Thu Dec 17 22:52:10 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

[abiggerhammer]

Thanks for reporting. We've run into this problem in the build with one of our bindings enabled (see https://travis-ci.org/UpstandingHackers/hammer/jobs/111613865#L1092) but this is the first time someone's run into it without.

[abiggerhammer]

Reproduced on a stock Ubuntu 14.04 VM. Using gcc, scons fails as you describe, though scons --variant=debug works. -O2 and -O1 both fail, so I dumped all the -O1 flags into CFLAGS (except for -fdelayed-branch) … and it compiled successfully. However, under clang, both the optimised and debug variants build. Are you able to build the debug variant under gcc? How about clang?

@thequux suspects this may be an issue with gcc's nondeterminism. We'll keep investigating.

[abiggerhammer]

Turns out gcc -O<level> -Q --help=optimizers shows you what optimisations are turned on for a certain optimization level. It also turns out the list is different from the one in the docs above. Still debugging.

[pesco]

For the record, we worked around a similar issue in the course of #155 before this surfaced in #160.