Programming Languages on Power

Power Programming Languages

IBM Power, including the AIX, IBM i, and Linux operating systems, support a wide range of programming languages, catering to both traditional enterprise applications and modern development needs.


#Power


#Servers
#Programminglanguages
 View Only

  • 1.  Two issues with IBM XLC compiler

    Posted 05/02/22 09:38 AM
    Hello,

    I've been trying to make a project XLC compatible (currently, gcc and clang work completely fine). I currently cannot build the project due to two issues. Maybe somebody can help me out here, because googling did not help me.

    Issue 1: My code uses the fast xxHash library, which uses Altivec intrinsics. Using gcc/clang, they compile fine. However, using `xlC_at`, I get the following error:

    ```
    In file included from /scratch/maximilian.boether/ma-code/build-release-xlc/_deps/xxhash-src/xxhash.c:43:
    /scratch/maximilian.boether/ma-code/build-release-xlc/_deps/xxhash-src/cmake_unofficial/../xxhash.h:4146:36: error: 1540-2993 The builtin "__builtin_altivec_vmulouw" is not supported.
    xxh_u64x2 const product = XXH_vec_mulo((xxh_u32x4)data_key, shuffled);
    ^
    /scratch/maximilian.boether/ma-code/build-release-xlc/_deps/xxhash-src/cmake_unofficial/../xxhash.h:3125:24: note: expanded from macro 'XXH_vec_mulo'
    # define XXH_vec_mulo __builtin_altivec_vmulouw
    ^
    1 error generated.
    Error while processing /scratch/maximilian.boether/ma-code/build-release-xlc/_deps/xxhash-src/xxhash.c.
    make[3]: *** [_deps/xxhash-src/build/CMakeFiles/xxhash.dir/build.make:75: _deps/xxhash-src/build/CMakeFiles/xxhash.dir/__/xxhash.c.o] Error 1
    make[2]: *** [CMakeFiles/Makefile2:459: _deps/xxhash-src/build/CMakeFiles/xxhash.dir/all] Error 2
    make[2]: *** Waiting for unfinished jobs....
    ```

    What could cause this error? I am on a Power9 CPU.

    Issue 2: My program also makes use of spdlog and fmt, two well known C++ libraries. XLC currently fails to compile fmt:

    ```
    1500-036: (I) The NOSTRICT option (default at OPT(3)) has the potential to alter the semantics of a program. Please refer to documentation on the STRICT/NOSTRICT option for more information.
    1500-004: (U) INTERNAL COMPILER ERROR while compiling fmt::v8::detail::dragonbox::remove_trailing_zeros(uint64_t &). Compilation ended. Contact your Service Representative and provide the following information: Internal abort. For more information visit: http://www.ibm.com/support/docview.wss?uid=swg21110810
    1586-346 (U) An error occurred during code generation. The code generation return code was 1.
    make[3]: *** [_deps/spdlog-build/CMakeFiles/spdlog.dir/build.make:153: _deps/spdlog-build/CMakeFiles/spdlog.dir/src/fmt.cpp.o] Error 1
    make[2]: *** [CMakeFiles/Makefile2:433: _deps/spdlog-build/CMakeFiles/spdlog.dir/all] Error 2
    1500-036: (I) The NOSTRICT option (default at OPT(3)) has the potential to alter the semantics of a program. Please refer to documentation on the STRICT/NOSTRICT option for more information.
    1500-004: (U) INTERNAL COMPILER ERROR while compiling fmt::v8::detail::dragonbox::remove_trailing_zeros(uint64_t &). Compilation ended. Contact your Service Representative and provide the following information: Internal abort. For more information visit: http://www.ibm.com/support/docview.wss?uid=swg21110810
    1586-346 (U) An error occurred during code generation. The code generation return code was 1.
    make[3]: *** [_deps/fmt-build/CMakeFiles/fmt.dir/build.make:75: _deps/fmt-build/CMakeFiles/fmt.dir/src/format.cc.o] Error 1
    make[2]: *** [CMakeFiles/Makefile2:407: _deps/fmt-build/CMakeFiles/fmt.dir/all] Error 2
    make[1]: *** [CMakeFiles/Makefile2:497: test/CMakeFiles/hashmap-test.dir/rule] Error 2
    make: *** [Makefile:283: hashmap-test] Error 2
    ```

    I unfortunately have no idea what could cause this "internal compiler error". If you have experience with fmt/spdlog, any help would be much appreciated.

    Thank you so much!

    Best,
    Maximilian


    ------------------------------
    Maximilian Böther
    ------------------------------

    #C/C++andFortran


  • 2.  RE: Two issues with IBM XLC compiler

    Posted 05/03/22 06:47 AM
    Hi Maximilian

    For the first problem, it appears that the xxHash library is using a gcc-specific builtin (__builtin_altivec_vmulouw).  The GCC and XL teams collaborated on unified builtin names and published them as the Vector Intrinsics Programming Reference Specification (https://openpowerfoundation.org/specifications/vectorintrinsicprogrammingreference/).  GCC, XL, and clang implement this specification.  vec_mulo is documented on page 151 of this document.

    To fix the error above, change:
    # define XXH_vec_mulo __builtin_altivec_vmulouw
    to
    # define XXH_vec_mulo vec_mulo

    This should make the code portable to all compilers on Power.  If the source does not #include altivec.h, it needs to do so.
    ​

    ------------------------------
    Rafik Zurob
    ------------------------------



  • 3.  RE: Two issues with IBM XLC compiler

    Posted 05/03/22 07:01 AM
    Edited by Rafik Zurob 05/03/22 07:03 AM
    For the second problem, what version of the compiler are you using?  (You can get it via "xlC -qversion").  Which version of cmake?  (You can get it via "cmake --version").

    I cloned the library using the instructions from https://cppget.org/spdlog .  (Is this the right one?) 
    $ git clone https://github.com/gabime/spdlog.git
$ cd spdlog && mkdir build && cd build

    I then set CC to point at xlc and CXX to point at xlC and ran cmake 3.17 followed by make.  The build was successful.

    $ cmake ..
    -- The CXX compiler identification is XLClang 16.1.1.11
    -- Check for working CXX compiler: /opt/ibm/xlC/16.1.1/bin/xlC
    -- Check for working CXX compiler: /opt/ibm/xlC/16.1.1/bin/xlC - works
    -- Detecting CXX compiler ABI info
    -- Detecting CXX compiler ABI info - done
    -- Detecting CXX compile features
    -- Detecting CXX compile features - done
    -- Build spdlog: 1.10.0
    -- Looking for C++ include pthread.h
    -- Looking for C++ include pthread.h - found
    -- Performing Test CMAKE_HAVE_LIBC_PTHREAD
    -- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Success
    -- Found Threads: TRUE
    -- Build type: Release
    -- Generating example(s)
    -- Generating install
    -- Configuring done
    -- Generating done
    -- Build files have been written to: /scratch/rzurob/2/spdlog/build
    $ make -j 20
    Scanning dependencies of target spdlog
    [ 20%] Building CXX object CMakeFiles/spdlog.dir/src/color_sinks.cpp.o
    [ 20%] Building CXX object CMakeFiles/spdlog.dir/src/spdlog.cpp.o
    [ 30%] Building CXX object CMakeFiles/spdlog.dir/src/stdout_sinks.cpp.o
    [ 40%] Building CXX object CMakeFiles/spdlog.dir/src/file_sinks.cpp.o
    [ 50%] Building CXX object CMakeFiles/spdlog.dir/src/async.cpp.o
    [ 70%] Building CXX object CMakeFiles/spdlog.dir/src/fmt.cpp.o
    [ 70%] Building CXX object CMakeFiles/spdlog.dir/src/cfg.cpp.o
    1500-030: (I) INFORMATION: fmt::v8::detail::format_dragon(fmt::v8::detail::fp, bool, int, buffer<char> &, int &): Additional optimization may be attained by recompiling and specifying MAXMEM option with a value greater than 8192.
    1500-030: (I) INFORMATION: spdlog::pattern_formatter::handle_flag_<spdlog::details::null_scoped_padder>(char, details::padding_info): Additional optimization may be attained by recompiling and specifying MAXMEM option with a value greater than 8192.
    [ 80%] Linking CXX static library libspdlog.a
    [ 80%] Built target spdlog
    Scanning dependencies of target example
    [ 90%] Building CXX object example/CMakeFiles/example.dir/example.cpp.o
    1500-030: (I) INFORMATION: fmt::v8::detail::parse_replacement_field<char, format_handler &>(const char *, const char *, format_handler &&): Additional optimization may be attained by recompiling and specifying MAXMEM option with a value greater than 8192.
    [100%] Linking CXX executable example
    [100%] Built target example
    $

    The xlC version I used is 16.01.0001.0011.  If this is the right library and the compiler above fails for you, I suggest trying the following:
    1. Compile with "-qxflag=except" which should give us more information about where the abort is coming from.
    2. Try to reduce the optimization level to -O2 or -O0.  (As shown above, -O3 works for me, but this might help by making the compiler back off the optimization that's causing the abort on your system.)
    3. I doubt this will help, but just in case:  Increase your stack and data limits.  "ulimit -s unlimited" and "ulimit -d unlimited"

    ------------------------------
    Rafik Zurob
    ------------------------------



  • 4.  RE: Two issues with IBM XLC compiler

    Posted 05/04/22 06:27 AM
    Thank you so much for your answers.

    Regarding the first problem, thank you for your insights. The xxHash developers apparently had some issues with `vec_mulo`, see lines 3487 and following. However, I have created a PR that just uses the `vec_*` intrinsics on Power, which builds locally for me. Not sure about endianness and correctness here, though, and these are the issues that the devs discuss in the comments in lines 3487 following.

    Regarding the second problem, if I do it like you do, it works for me as well. However, I have built a MWE that uses fmt/spdlog as a library: 

    ```
    git clone https://github.com/MaxiBoether/ibm-xlc-crash-mwe
    cd ibm-xlc-crash-mwe
    mkdir build
    cd build
    CXX=/opt/ibm/xlC/16.1.1/bin/xlC CC=/opt/ibm/xlC/16.1.1/bin/xlc cmake ..
    CXX=/opt/ibm/xlC/16.1.1/bin/xlC CC=/opt/ibm/xlC/16.1.1/bin/xlc make
    ```

    leads to

    ```
    1500-036: (I) The NOSTRICT option (default at OPT(3)) has the potential to alter the semantics of a program. Please refer to documentation on the STRICT/NOSTRICT option for more information.
    1500-004: (U) INTERNAL COMPILER ERROR while compiling fmt::v8::detail::dragonbox::remove_trailing_zeros(uint64_t &). Compilation ended. Contact your Service Representative and provide the following information: Internal abort. For more information visit: http://www.ibm.com/support/docview.wss?uid=swg21110810
    1586-346 (U) An error occurred during code generation. The code generation return code was 1.
    make[2]: *** [_deps/spdlog-build/CMakeFiles/spdlog.dir/build.make:153: _deps/spdlog-build/CMakeFiles/spdlog.dir/src/fmt.cpp.o] Error 1
    make[2]: *** Waiting for unfinished jobs....
    1500-036: (I) The NOSTRICT option (default at OPT(3)) has the potential to alter the semantics of a program. Please refer to documentation on the STRICT/NOSTRICT option for more information.
    1500-004: (U) INTERNAL COMPILER ERROR while compiling fmt::v8::detail::dragonbox::remove_trailing_zeros(uint64_t &). Compilation ended. Contact your Service Representative and provide the following information: Internal abort. For more information visit: http://www.ibm.com/support/docview.wss?uid=swg21110810
    1586-346 (U) An error occurred during code generation. The code generation return code was 1.
    make[2]: *** [_deps/fmt-build/CMakeFiles/fmt.dir/build.make:75: _deps/fmt-build/CMakeFiles/fmt.dir/src/format.cc.o] Error 1
    make[1]: *** [CMakeFiles/Makefile2:145: _deps/fmt-build/CMakeFiles/fmt.dir/all] Error 2
    make[1]: *** Waiting for unfinished jobs....
    make[1]: *** [CMakeFiles/Makefile2:171: _deps/spdlog-build/CMakeFiles/spdlog.dir/all] Error 2
    make: *** [Makefile:91: all] Error 2
    ```

    I am using XL for Linux version 16.01.0001.0003. If I use the `-qxflag=except` flag, the error is as follows:
    ```
    [ 69%] Building CXX object _deps/spdlog-build/CMakeFiles/spdlog.dir/src/fmt.cpp.o
    Exception: reason = 1
    Traceback:
    Line ? Displ 0000000000001F84 as_power
    Line ? Displ 0000000000000EF0 as_text
    Line ? Displ 00000000000011FC as
    Line ? Displ 00000000000004A0 IPRA.$invoke_tobey
    Line ? Displ 0000000000000D68 xlator_main
    Line ? Displ 00000000000000D8 main
    1500-036: (I) The NOSTRICT option (default at OPT(3)) has the potential to alter the semantics of a program. Please refer to documentation on the STRICT/NOSTRICT option for more information.
    xlator_terminate..000000000000005C main..00000000000001AC
    1586-346 (U) An error occurred during code generation. The code generation return code was 1.
    make[2]: *** [_deps/spdlog-build/CMakeFiles/spdlog.dir/build.make:153: _deps/spdlog-build/CMakeFiles/spdlog.dir/src/fmt.cpp.o] Error 1
    make[2]: *** Waiting for unfinished jobs....
    Exception: reason = 1
    Traceback:
    Line ? Displ 0000000000001F84 as_power
    Line ? Displ 0000000000000EF0 as_text
    Line ? Displ 00000000000011FC as
    Line ? Displ 00000000000004A0 IPRA.$invoke_tobey
    Line ? Displ 0000000000000D68 xlator_main
    Line ? Displ 00000000000000D8 main
    1500-036: (I) The NOSTRICT option (default at OPT(3)) has the potential to alter the semantics of a program. Please refer to documentation on the STRICT/NOSTRICT option for more information.
    xlator_terminate..000000000000005C main..00000000000001AC
    1586-346 (U) An error occurred during code generation. The code generation return code was 1.
    make[2]: *** [_deps/fmt-build/CMakeFiles/fmt.dir/build.make:75: _deps/fmt-build/CMakeFiles/fmt.dir/src/format.cc.o] Error 1
    make[1]: *** [CMakeFiles/Makefile2:145: _deps/fmt-build/CMakeFiles/fmt.dir/all] Error 2
    make[1]: *** Waiting for unfinished jobs....
    ```

    The problem does not occur in debug builds, i.e., -O0. You can try using `cmake .. -DCMAKE_BUILD_TYPE=DEBUG` instead, this works for me.

    Thank you so much for your help so far, I hope we can track the issue down :) 

    Best,
    Maximilian

    ------------------------------
    Maximilian Böther
    ------------------------------

    Original Message


  • 5.  RE: Two issues with IBM XLC compiler

    Posted 05/04/22 08:58 AM
    Hi Maximilian

    I can reproduce the error with PTF 3 (16.1.1.3).  It appears to be fixed in PTF9 and above.  The latest PTF is currently 11.  You can get the latest PTF from Fix Central.

    Note:  I can build the library successfully on RHEL 8.x and Ubuntu 20.x.  I tried RHEL 7.x, but that fails due to C++ header problems.  (I suspect the headers on RHEL 7.x are way too old for this source.)


    ------------------------------
    Rafik Zurob
    ------------------------------

    Original Message


  • 6.  RE: Two issues with IBM XLC compiler

    Posted 05/04/22 09:36 AM
    Edited by Rafik Zurob 05/04/22 09:39 AM
    For vec_mulo, I forgot about the endianness.  The o in the name refers to "odd".  i.e. multiply the odd elements of the vector.  The problem is that odd and even are reversed depending on whether you start counting the elements from left to right or right to left.

    In general, when the Power hardware is running in big endian mode, it is supposed to use big-endian vector element order and when it is running in little endian mode, it is supposed to use little-endian element order.  But the vector hardware instructions added in Power7, like vmulouw and vmuleuw, used big-endian vector element order even when the hardware was running in little-endian mode.  This wasn't caught in time because there were no operating systems on Power that ran in little-endian mode.  The compilers tried to fix this in various ways:  vec_mulo was implemented to use little-endian vector element order on ppc64le by making the compiler emit vmuleuw.  At one point, gcc and xlc supported -maltivec=be / -maltivec=le to let the user choose what vector element order to use.

    Looking at xxhash.h, it appears the developers wanted to work around this by emitting the instruction directly and not relying on whether the compiler tried to "correct" the vector element order.  Clang's __builtin_altivec_vmulouw just gives your the hardware instruction (i.e. in big-endian vector element order).  But you might notice that for gcc they're using inline asm.  The reason is that gcc's __builtin_altivec_vmulouw is like vec_mulo.  Both will give you little-endian vector element order.

    In summary, it appears the code really wants vmulouw.  The inline asm path used in the header for GCC will always work for XLC 16.1.1 too.  (XLC 16.1.1 can be identified using the __ibmxl__ macro.)

    ------------------------------
    Rafik Zurob
    ------------------------------

    Original Message


Related Content