error #188: enumerated type mixed with another type

[jeffhammond]

I understand that Intel 16 is not listed as a supported compiler on http://criterion.readthedocs.org/en/latest/setup.html#installation, but from what I can find online, this appears to be a valid compiler error.

I observe this when the Intel compiler is operating in GCC 4.3.0 and GCC 5.1.0 compatibility modes.

Thanks.

jhammond@cori09:~/OFI/Criterion/build> rm -rf *
jhammond@cori09:~/OFI/Criterion/build> cmake ..
-- The C compiler identification is Intel 16.0.0.20150815
-- Check for working C compiler: /opt/cray/craype/2.4.2/bin/cc
-- Check for working C compiler: /opt/cray/craype/2.4.2/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Updating submodules to their latest/fixed versions
-- (this can take a while, please be patient)
Submodule path 'dependencies/libcsptr': checked out '2762164acfaa712fea7dec6ed760ff88f7d2e026'
-- no specific version given for submodule libcsptr, checking out master
-- checking out libcsptr's commit/tag master
-- no specific version given for submodule dyncall, checking out master
-- checking out dyncall's commit/tag master
-- Checking prototype strtok_s for HAVE_STRTOK_S - False
-- Found PkgConfig: /usr/bin/pkg-config (found version "0.28") 
-- checking for one of the modules 'check'
-- The CXX compiler identification is Intel 16.0.0.20150815
-- Check for working CXX compiler: /opt/cray/craype/2.4.2/bin/CC
-- Check for working CXX compiler: /opt/cray/craype/2.4.2/bin/CC -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Found Gettext: /usr/bin/msgmerge (found version "0.17") 
-- Looking for dgettext
-- Looking for dgettext - found
-- Found Libintl: /usr/include  
-- Looking for clock_gettime in rt
-- Looking for clock_gettime in rt - found
-- Could NOT find PCRE (missing:  PCRE_LIBRARY PCRE_INCLUDE_DIR) 
-- Configuring done
-- Generating done
-- Build files have been written to: /global/homes/j/jhammond/OFI/Criterion/build
jhammond@cori09:~/OFI/Criterion/build> cmake --build .
Scanning dependencies of target dyncall_s
[  2%] Building C object dependencies/dyncall/dyncall/CMakeFiles/dyncall_s.dir/dyncall_call.S.o
[  4%] Building C object dependencies/dyncall/dyncall/CMakeFiles/dyncall_s.dir/dyncall_vector.c.o
[  7%] Building C object dependencies/dyncall/dyncall/CMakeFiles/dyncall_s.dir/dyncall_struct.c.o
[  9%] Building C object dependencies/dyncall/dyncall/CMakeFiles/dyncall_s.dir/dyncall_api.c.o
[ 12%] Building C object dependencies/dyncall/dyncall/CMakeFiles/dyncall_s.dir/dyncall_callvm.c.o
[ 14%] Building C object dependencies/dyncall/dyncall/CMakeFiles/dyncall_s.dir/dyncall_callvm_base.c.o
[ 17%] Building C object dependencies/dyncall/dyncall/CMakeFiles/dyncall_s.dir/dyncall_callf.c.o
Linking C static library libdyncall_s.a
[ 17%] Built target dyncall_s
Scanning dependencies of target csptr
[ 19%] Building C object dependencies/libcsptr/CMakeFiles/csptr.dir/src/mman.c.o
icc: command line warning #10006: ignoring unknown option '-Wno-unused-result'
/global/homes/j/jhammond/OFI/Criterion/dependencies/libcsptr/src/mman.c(104): error #188: enumerated type mixed with another type
              .kind = SHARED | ARRAY,
                      ^

/global/homes/j/jhammond/OFI/Criterion/dependencies/libcsptr/src/mman.c(202): error #188: enumerated type mixed with another type
              .kind = args->kind | ARRAY,
                      ^

compilation aborted for /global/homes/j/jhammond/OFI/Criterion/dependencies/libcsptr/src/mman.c (code 2)
gmake[2]: *** [dependencies/libcsptr/CMakeFiles/csptr.dir/src/mman.c.o] Error 2
gmake[1]: *** [dependencies/libcsptr/CMakeFiles/csptr.dir/all] Error 2
gmake: *** [all] Error 2

[Snaipe]

Interesting. I guess icc doesn't like enum compositions -- I'll see what I can do after installing the compiler.

[jeffhammond]

In the event that you are not fabulously wealthy, the Intel Free Software Tools page may be useful, particularly the program for open source contributors.

[Snaipe]

It seems that icc fails to compile dyncall_call.S on my end, is your target system perhaps 32-bit ?

[jeffhammond]

I am running on a 64-bit Cray XC40 supercomputer with Intel Haswell processors (NERSC Cori).

> uname -a
Linux cori12 3.0.101-0.46-default #1 SMP Wed Dec 17 11:04:10 UTC 2014 (8356111) x86_64 x86_64 x86_64 GNU/Linux

[Snaipe]

I fixed all the errors that icc raised, but ultimately I'm still having compilation issues with dyncall, which weirdly does not seem to happen on your end. Does everything works for you now?

I'm going to ask on the dyncall mailing lists if I can do something about the dyncall/icc issue.

[jeffhammond]

It is possible that I have a patched version of CMake for this machine that works around dynamic library issues and that this has the side-effect of fixing this issue for me.

Can you isolate the dyncall issue, i.e. give me the naked build command so I can try to reproduce what you see?

[Snaipe]

Here's a full log of what's happening: http://paste.awesom.eu/raw/TylG

However, I had to patch (see attached file) dyncall's CMakeLists.txt because it wouldn't add -fPIC otherwise.

If left unpatched, the resulting log is very similar to what happens, except it fails when producing libdyncall_s.a, since the linker would not be able to relocate the object files.

dyncall-cmakelists.patch

[Snaipe]

The naked command that fails to compile dyncall_call.S is simply icc -fPIC -o CMakeFiles/dyncall_s.dir/dyncall_call.S.o -c ../dependencies/dyncall/dyncall/dyncall_call.S from within the build directory.

[Snaipe]

Ok, I fixed the issue locally and sent a patch upstream to dyncall. Criterion now compiles normally with icc/icpc.