Binaryen: Cannot build binaryen

[Razican]

Hello, I'm trying to build the software by cloning and then by doing cmake . && make, but I'm getting this error:

[ 74%] Building CXX object CMakeFiles/wasm-opt.dir/src/tools/wasm-opt.cpp.o
In file included from /binaryen/src/tools/wasm-opt.cpp:36:0:
/binaryen/src/tools/fuzzing.h: In member function ‘wasm::Expression* wasm::TranslateToFuzzReader::makeConst(wasm::WasmType)’:
/binaryen/src/tools/fuzzing.h:1324:5: error: ‘first’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
   T pickGivenNum(size_t num, T first, Args... args) {
     ^~~~~~~~~~~~
cc1plus: all warnings being treated as errors
make[2]: *** [CMakeFiles/wasm-opt.dir/build.make:63: CMakeFiles/wasm-opt.dir/src/tools/wasm-opt.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:117: CMakeFiles/wasm-opt.dir/all] Error 2
make: *** [Makefile:130: all] Error 2

I'm guessing it's using GCC to compile, this is my version:

Using built-in specs.
COLLECT_GCC=c++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap --enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-gcc-major-version-only --with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --with-isl --enable-libmpx --enable-offload-targets=nvptx-none --without-cuda-driver --enable-gnu-indirect-function --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 7.2.1 20170915 (Red Hat 7.2.1-2) (GCC)

It seems that it detected a potential uninitialized variable usage, and warnings are errors by default.

[kripken]

I saw that too with recent gcc, and filed an upstream bug.

It's tricky to work around, I didn't find a way, except from using older gcc, or clang.

[Razican]

Not sure, but maybe a null comparison of first before returning it could fix the warning, but I haven't programmed in C++ for a long time, so I will probably be wrong.

[kripken]

It has an integer type, though, so comparing to a null pointer isn't valid. But if you have time, just trying a bunch of stuff might find something - I gave up eventually, but I might have missed it.

[Razican]

I would probably need some more information on what the code does. Is first always an integer different from 0?

This would fix the warning:

  template<typename T, typename... Args>
  T pickGivenNum(size_t num, T first, Args... args) {
    if (num == 0 && first) return first;
    return pickGivenNum<T>(num - 1, args...);
  }

but I guess it can be 0. In any case, something in those lines could work.

Another option would be to temporarily pass the -Wno-uninitialized flag to the compiler. Where could I do that?

[kripken]

Yeah, it can be 0. It also can't be uninitialized - it's some weird internal bug in gcc, it gets confused by too many templates I guess...

Good point about the flag. The CMakeLists.txt file is the right place - we should add it, but it should only be for gcc in the versions we know have this bug, and with a TODO to remove it once they fix it. Would be great if you can make a PR with that.

[binji]

Might be nicer to have it inline at the location in the source, using diagnostic pragmas and checking the version via a predefined macro.

[daurnimator]

Never use -Werror in a release make file (use it for development only)! My C compiler introducing new warnings shouldn't break your software.

[kripken]

Fair point, maybe we should build by default without it, but then we'd need to test on the bots both with and without it, which is double the time.

[froydnj]

Since #1301 got merged, can we close this, @kripken?

[kripken]

Hmm, one remaining topic mentioned above is whether we should built with -Werror or not. Perhaps it should be on for testing, but not on by default for users? Or perhaps it's better to see errors even there and get reports on them?

[froydnj]

Hmm, one remaining topic mentioned above is whether we should built with -Werror or not. Perhaps it should be on for testing, but not on by default for users? Or perhaps it's better to see errors even there and get reports on them?

I think that's a separate bug; I've filed #1387 for discussion on that.

[kripken]

Makes sense, thanks.