Issue with exp for double precision complex numbers with ifort and ifx

[DmitryKopelevich]

I'm using

ifort  2021.10.0 20230609
and

ifx 2023.2.0 20230721

I've ran into the following issue: Programs compiled with ifort and ifx incorrectly compute exponentials of double-precision complex numbers and return Infinity or 0 instead of the actual value. Below is a simple test code:

program test
        double complex :: x = (0.d0, 0.d0)
        print *, exp(x)
end program test

If I compile this code with ifort, the output is

(Infinity,0.000000000000000E+000)

If I compile the code with ifx, the output is different, but is still wrong:

 (0.000000000000000E+000,0.000000000000000E+000)

The issue appears to only arise with double precision complex numbers; the results are correct for single precision complex, double precision real etc.

Is this a known issue with these compilers?

[mecej4]

On Windows 11, using ifort Version 2021.10.0 Build 20230609 and ifx Version 2023.2.0 Build 20230627, with /Od or /QxAVX2, I observed no such problems. Both the 64-bit EXEs from those compilations output the correct result, (1.00000000000000,0.000000000000000E+000).

[DmitryKopelevich]

Thank you for checking this. The issue may actually be the type of a CPU that I am using: I ran into this problem on older computers, with Intel Xeon E5410 and Intel Xeon E5620. On a somewhat newer computer, with Intel Core i5-4440, EXP works fine. But even on the old computers, the GNU compiler (gfortran) produces correct results. Is the Intel compiler not recommended to be used with old CPUs?

[mecej4]

It is also possible that the error originates in a  library (a system library that provides math functions, such as libm.so, or another library provided with the compiler).

Please list the version of the operating system and the compiler options that will allow the error to be reproduced.

[DmitryKopelevich]

To run the above test, I did not use any flags (i.e., I just typed "ifort test.f90" or "ifx test.f90", where test.f90 is the above test program). I am running Ubuntu 22.04 on all 3 computers on which I performed the test.

- On those computers that failed the test, I'm running the server version of Ubuntu, with kernel 5.15.0-78-generic

- On the computer that passed the test, I am running the desktop version, with kernel 5.19.0-50-generic

[Barbara_P_Intel]

I just ran this on Ubuntu 22.04.2 LTS with 5.15.47+prerelease4684  kernel and the same compilers you have, @DmitryKopelevich. I got the correct answers. I did not set any compiler options.

The older Intel processors are still supported by the compilers. The default architecture is SSE2. I couldn't find the architecture info for the processors you mention.

You might try compiling with -xhost. That will generate code for the processor that you are compiling on. 

[DmitryKopelevich]

Unfortunately, -xhost did not help either. I'll see if upgrading the linux kernel will help.

[mecej4]

According to this data sheet, the E5620 supports SSE4.2 instructions.

[DmitryKopelevich]

I tried to explicitly compile for SSE4.2 instructions using the option "-arch SSE4.2" and got the following error: " error #10236: File not found: 'SSE4.2'". I was able to compile with "-arch SSE3" and "-arch SSE2" options without errors, but then the executable was producing the incorrect result.

I wonder if the "File not found" error for SSE4.2 is a clue.

[Barbara_P_Intel]

Try -xSSE4.2.

That "File not found" message isn't relevant. That looks like a bug with -arch and the ifx and ifort drivers. I've never used that compiler option. I'll look into that.

[DmitryKopelevich]

Unfortunately, it didn't help. It compiles with the -xSSE4.2 flag, but the compiled code still produces the same incorrect result.

Another observation: the result depends on which computer I am running the code on, not where I compile it. I.e., if I compile the code on the computer that produces a wrong result but run the code on a different computer, it produces the correct result. And vice versa.

[Ron_Green]

Let's gather more data on the "bad" computer.  Use the -# option to dump all the defines, includes, and paths to libs used in the compilation:

ifort -# test.f90

and post the output.  There may be a clue in there.

[Ron_Green]

Another question - are you building/compiling test.f90 on one computer but running on these older CPU systems?  On the older systems, is there an older version of the Intel Fortran Runtime Libraries, what we used to call the "redistributable libraries"? 

one way to tell

if you compile test.f90 to test.exe, move the test.exe to the old computer.

Then do

ldd test.exe

and send the output.  this will tell us if it's picking up an older incompatible Fortran Runtime Library

[DmitryKopelevich]

Normally, I compile on the same computer on which I run the program; I just tried running the code on a different computer this one time to see if it gives me any clues.

Here is the output of ifort -# test.f90 

/opt/intel/oneapi/compiler/2023.2.1/linux/bin/intel64/../../bin/intel64/fortcom  \
    -D__INTEL_COMPILER=2021 \
    -D__INTEL_COMPILER_UPDATE=10 \
    -D__unix__ \
    -D__unix \
    -D__linux__ \
    -D__linux \
    -D__gnu_linux__ \
    -Dunix \
    -Dlinux \
    -D__ELF__ \
    -D__x86_64 \
    -D__x86_64__ \
    -D__amd64 \
    -D__amd64__ \
    -D__INTEL_COMPILER_BUILD_DATE=20230609 \
    -D__INTEL_OFFLOAD \
    -D__MMX__ \
    -D__SSE__ \
    -D__SSE_MATH__ \
    -D__SSE2__ \
    -D__SSE2_MATH__ \
    -D__pentium4 \
    -D__pentium4__ \
    -D__tune_pentium4__ \
    -I. \
    -I/opt/intel/oneapi/tbb/2021.10.0/env/../include \
    -I/opt/intel/oneapi/mpi/2021.10.0//include \
    -I/opt/intel/oneapi/mkl/2023.2.0/include \
    -I/opt/intel/oneapi/ipp/2021.9.0/include \
    -I/opt/intel/oneapi/ippcp/2021.8.0/include \
    -I/opt/intel/oneapi/ipp/2021.9.0/include \
    -I/opt/intel/oneapi/dpl/2022.2.0/linux/include \
    -I/opt/intel/oneapi/dpcpp-ct/2023.2.0/include \
    -I/opt/intel/oneapi/dnnl/2023.2.0/cpu_dpcpp_gpu_dpcpp/include \
    -I/opt/intel/oneapi/dev-utilities/2021.10.0/include \
    -I/opt/intel/oneapi/dal/2023.2.0/include \
    -I/opt/intel/oneapi/compiler/2023.2.1/linux/lib/oclfpga/include \
    -I/opt/intel/oneapi/ccl/2021.10.0/include/cpu_gpu_dpcpp \
    -I/global/apps/gromacs-4.5.6-gnu/share/gromacs/top \
    -I/home/kopelev/dkopelev/soft-matter/1.1/force-field \
    -I/home/kopelev/dkopelev/soft-matter/1.1/force-field/slipid.ff \
    -I/opt/intel/oneapi/compiler/2023.2.1/linux/bin/intel64/../../compiler/include/intel64 \
    -I/opt/intel/oneapi/compiler/2023.2.1/linux/bin/intel64/../../compiler/include/icc \
    -I/opt/intel/oneapi/compiler/2023.2.1/linux/bin/intel64/../../compiler/include \
    -I/usr/local/include \
    -I/usr/lib/gcc/x86_64-linux-gnu/11/include \
    -I/usr/include/ \
    -I/usr/include \
    -I/usr/include/x86_64-linux-gnu \
    -omp_simd \
    -O2 \
    "-reentrancy threaded" \
    -simd \
    -offload_host \
    -mGLOB_em64t=TRUE \
    -mP1OPT_version=2021.10.0-intel64 \
    -mGLOB_diag_file=/tmp/iforta208Yq.diag \
    -mGLOB_long_size_64 \
    -mGLOB_routine_pointer_size_64 \
    -mGLOB_source_language=GLOB_SOURCE_LANGUAGE_F90 \
    -mP2OPT_static_promotion \
    -mGLOB_pack_sort_init_list \
    -mP1OPT_print_version=FALSE \
    -mCG_use_gas_got_workaround=F \
    -mP2OPT_align_option_used=TRUE \
    -mGLOB_gcc_version=1140 \
    -mGLOB_options_string=-# \
    -mGLOB_cxx_limited_range=FALSE \
    -mCG_extend_parms=FALSE \
    -mGLOB_compiler_bin_directory=/opt/intel/oneapi/compiler/2023.2.1/linux/bin/intel64/../../bin/intel64 \
    -mGLOB_as_output_backup_file_name=/tmp/ifortF9uRCTas_.s \
    -mGLOB_dashboard_use_source_name \
    -mIPOPT_activate \
    -mIPOPT_lite \
    -mGLOB_uarch_tuning=0x0 \
    -mGLOB_product_id_code=0x22006d91 \
    -mCG_bnl_movbe=T \
    -mP3OPT_use_mspp_call_convention \
    -mP2OPT_subs_out_of_bound=FALSE \
    -mP2OPT_disam_type_based_disam=2 \
    -mGLOB_ansi_alias \
    -mPGOPTI_value_profile_use=T \
    -mGLOB_opt_report_use_source_name \
    -mGLOB_offload_mode=1 \
    -mGLOB_offload_no_openmp=TRUE \
    -mP2OPT_offload_unique_var_string=ifort0441341851YjGn7P \
    -mP2OPT_hlo_level=2 \
    -mP2OPT_hlo \
    -mP2OPT_hpo_rtt_control=0 \
    -mIPOPT_args_in_regs=0 \
    -mP2OPT_disam_assume_nonstd_intent_in=FALSE \
    -mGLOB_imf_mapping_library=/opt/intel/oneapi/compiler/2023.2.1/linux/bin/intel64/../../bin/intel64/libiml_attr.so \
    -mIPOPT_single_file_compile_and_link=TRUE \
    -mPGOPTI_gen_threadsafe_level=0 \
    -mIPOPT_lto_object_enabled \
    -mIPOPT_lto_object_value=1 \
    -mIPOPT_obj_output_file_name=/tmp/iforta208Yq.o \
    -mIPOPT_whole_archive_fixup_file_name=/tmp/ifortwarch0ScWBZ \
    -mGLOB_linker_version=2.38 \
    -mGLOB_linker=ld \
    -mGLOB_driver_tempfile_name=/tmp/iforttempfile7zQmx4 \
    -mP3OPT_asm_target=P3OPT_ASM_TARGET_GAS \
    -mGLOB_async_unwind_tables=TRUE \
    -mGLOB_obj_output_file=/tmp/iforta208Yq.o \
    -mGLOB_source_dialect=GLOB_SOURCE_DIALECT_FORTRAN \
    -mP1OPT_source_file_name=a.f90 \
    -mP1OPT_full_source_file_name=/kopelev/dkopelev/a.f90 \
    -mP2OPT_symtab_type_copy=true \
    a.f90

ld  \
    /usr/lib/gcc/x86_64-linux-gnu/11/../../../x86_64-linux-gnu/Scrt1.o \
    /usr/lib/gcc/x86_64-linux-gnu/11/../../../x86_64-linux-gnu/crti.o \
    /usr/lib/gcc/x86_64-linux-gnu/11/crtbeginS.o \
    --eh-frame-hdr \
    --build-id \
    -dynamic-linker \
    /lib64/ld-linux-x86-64.so.2 \
    -m \
    elf_x86_64 \
    -plugin \
    /opt/intel/oneapi/compiler/2023.2.1/linux/bin/intel64/../../bin/intel64/../../lib/icx-lto.so \
    -o \
    a.out \
    /opt/intel/oneapi/compiler/2023.2.1/linux/bin/intel64/../../compiler/lib/intel64_lin/for_main.o \
    -L/opt/intel/oneapi/tbb/2021.10.0/env/../lib/intel64/gcc4.8 \
    -L/opt/intel/oneapi/mpi/2021.10.0//libfabric/lib \
    -L/opt/intel/oneapi/mpi/2021.10.0//lib/release \
    -L/opt/intel/oneapi/mpi/2021.10.0//lib \
    -L/opt/intel/oneapi/mkl/2023.2.0/lib/intel64 \
    -L/opt/intel/oneapi/ipp/2021.9.0/lib/intel64 \
    -L/opt/intel/oneapi/ippcp/2021.8.0/lib/intel64 \
    -L/opt/intel/oneapi/ipp/2021.9.0/lib/intel64 \
    -L/opt/intel/oneapi/dnnl/2023.2.0/cpu_dpcpp_gpu_dpcpp/lib \
    -L/opt/intel/oneapi/dal/2023.2.0/lib/intel64 \
    -L/opt/intel/oneapi/compiler/2023.2.1/linux/compiler/lib/intel64_lin \
    -L/opt/intel/oneapi/compiler/2023.2.1/linux/lib \
    -L/opt/intel/oneapi/ccl/2021.10.0/lib/cpu_gpu_dpcpp \
    -L/opt/intel/oneapi/compiler/2023.2.1/linux/bin/intel64/../../compiler/lib/intel64_lin \
    -L/opt/intel/oneapi/mpi/2021.10.0//libfabric/lib/../lib/ \
    -L/opt/intel/oneapi/mpi/2021.10.0//lib/../lib/ \
    -L/opt/intel/oneapi/dnnl/2023.2.0/cpu_dpcpp_gpu_dpcpp/lib/../lib/ \
    -L/opt/intel/oneapi/compiler/2023.2.1/linux/lib/../lib/ \
    -L/usr/lib/gcc/x86_64-linux-gnu/11/ \
    -L/usr/lib/gcc/x86_64-linux-gnu/11/../../../x86_64-linux-gnu/ \
    -L/usr/lib/gcc/x86_64-linux-gnu/11/../../../../lib64 \
    -L/usr/lib/gcc/x86_64-linux-gnu/11/../../../../lib/ \
    -L/lib/x86_64-linux-gnu/ \
    -L/lib/../lib64 \
    -L/lib/../lib/ \
    -L/usr/lib/x86_64-linux-gnu/ \
    -L/usr/lib/../lib64 \
    -L/usr/lib/../lib/ \
    -L/opt/intel/oneapi/tbb/2021.10.0/env/../lib/intel64/gcc4.8/ \
    -L/opt/intel/oneapi/mpi/2021.10.0//libfabric/lib/ \
    -L/opt/intel/oneapi/mpi/2021.10.0//lib/release/ \
    -L/opt/intel/oneapi/mpi/2021.10.0//lib/ \
    -L/opt/intel/oneapi/mkl/2023.2.0/lib/intel64/ \
    -L/opt/intel/oneapi/ipp/2021.9.0/lib/intel64/ \
    -L/opt/intel/oneapi/ippcp/2021.8.0/lib/intel64/ \
    -L/opt/intel/oneapi/dnnl/2023.2.0/cpu_dpcpp_gpu_dpcpp/lib/ \
    -L/opt/intel/oneapi/dal/2023.2.0/lib/intel64/ \
    -L/opt/intel/oneapi/compiler/2023.2.1/linux/compiler/lib/intel64_lin/ \
    -L/opt/intel/oneapi/compiler/2023.2.1/linux/lib/ \
    -L/opt/intel/oneapi/ccl/2021.10.0/lib/cpu_gpu_dpcpp/ \
    -L/usr/lib/gcc/x86_64-linux-gnu/11/../../../ \
    -L/lib64 \
    -L/lib/ \
    -L/usr/lib64 \
    -L/usr/lib \
    /tmp/iforta208Yq.o \
    -Bdynamic \
    -Bstatic \
    -lifport \
    -lifcoremt \
    -limf \
    -lsvml \
    -Bdynamic \
    -lm \
    -Bstatic \
    -lipgo \
    -lirc \
    -Bdynamic \
    -lpthread \
    -Bstatic \
    -lsvml \
    -Bdynamic \
    -lc \
    -lgcc \
    -lgcc_s \
    -Bstatic \
    -lirc_s \
    -Bdynamic \
    -ldl \
    -lc \
    /usr/lib/gcc/x86_64-linux-gnu/11/crtendS.o \
    /usr/lib/gcc/x86_64-linux-gnu/11/../../../x86_64-linux-gnu/crtn.o

rm /tmp/ifortdashvQ7ybaM
rm /tmp/ifortdummyiiNb4q.c
rm /tmp/ifortsearchdirsVWKjaG
rm /tmp/ifortgccdashvgJRpIE
rm /tmp/iforta208Yq.o
rm /tmp/ifortF9uRCTas_.s
rm /tmp/ifortldashvHc6WqN
rm /tmp/iforttempfile7zQmx4
rm /tmp/ifortargdRkXKi
rm /tmp/iforta208Yq.o

This is the output I get when I run ldd test.ext on the old computer for an executable compiled on the new computer:

        linux-vdso.so.1 (0x00007ffc7795f000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x000014626245c000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x0000146262234000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x0000146262212000)
        /lib64/ld-linux-x86-64.so.2 (0x0000146262557000)

[Ron_Green]

Your output is in line with what I see on my Ubu 22.04 server. 

As was mentioned above, the EXP function in Fortran is calling into the cexp() function in libm on your system. 

On mine this is

ldd a.out

linux-vdso.so.1 (0x00007ffd6ed5f000)

libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fd7a26ff000)

libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fd7a24d7000)

libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fd7a24b5000)

/lib64/ld-linux-x86-64.so.2 (0x00007fd7a27f0000)

These older systems, these are also running Ubuntu 22.04 with gcc 11 right?  Do they have the oneapi 2023.2 tools installed on them?  Do they have anything under /opt/intel ?  Any old psxe directories?

you can try to build on a 'good' system with -static.  Then bring the binary over and see what the results are.  THis way we aren't relying on the executable finding a compatible libm or intel runtime library.

I don't have access to servers as old as yours.

ron

[DmitryKopelevich]

Yes, the older systems also run Ubuntu 22.04 with gcc 11. In terms of OS, the difference between the old and new systems is that the new system runs a desktop Ubuntu whereas the old system runs a server Ubuntu. I'm not sure if that's important in this case.

The old systems do have oneapi 2023.2 tools installed on them. The /opt/intel directory contains directory oneapi. There are no psxe directories.

I've tried compiling with the "-static" flag on the new computer and then running on the old computer, but the result is still the same! Does this suggest a CPU issue?

Something else I've noticed (on both old and new systems): "apt list --upgradable" gives the following list:

intel-oneapi-compiler-cpp-eclipse-cfg/all 2023.2.1-16 all [upgradable from: 2023.2.1-16]
intel-oneapi-compiler-dpcpp-cpp-and-cpp-classic/all 2023.2.1-16 amd64 [upgradable from: 2023.2.1-16]
intel-oneapi-compiler-dpcpp-cpp/all 2023.2.1-16 amd64 [upgradable from: 2023.2.1-16]
intel-oneapi-compiler-dpcpp-eclipse-cfg/all 2023.2.1-16 all [upgradable from: 2023.2.1-16]
intel-oneapi-compiler-fortran/all 2023.2.1-16 amd64 [upgradable from: 2023.2.1-16]

When I do "apt upgrade intel-oneapi-compiler-fortran, it goes through the motion of upgrading, but afterwards "apt list --upgradable" returns exactly the same list, as if nothing got upgraded. I doubt it is related to the problem with cdexp, but thought I'd mention it.

[mecej4]

On the system where you see an incorrect result, you can see if the problem originates in the math library, libm.so, by compiling and running a C test program that calls cexp(). For such a test, you do not even have to have a Fortran compiler installed on the system.

For example, compile and run the following test code using the system C compiler (gcc, probably).

#include <stdio.h>
#include <math.h>
#include <complex.h>

int main(){
  double complex x = 0.0 + 0.0*I;
  double complex z;
  z = cexp(x);
  printf("cexp(%.2f + %.2fi) = %.2f + %.2fi\n",
     creal(x), cimag(x), creal(z), cimag(z));
}

Compile, link and run with the commands

gcc ctest.c -lm
./a.out

[DmitryKopelevich]

I've tried this and it works when I use the GNU C compiler (gcc). However, it doesn't work when I use the Intel compilers (icc and icx):

$ gcc test.c -lm
$ ./a.out
cexp(0.00 + 0.00i) = 1.00 + 0.00i
$ icc test.c -lm
$ ./a.out
cexp(0.00 + 0.00i) = inf + 0.00i
$ icx test.c -lm
$ ./a.out
cexp(0.00 + 0.00i) = inf + 0.00i

[Ron_Green · Accepted solution]

For the Intel compilers, let's turn off our libimf and libsvml.  Use this option

-no-intel-lib=libimf,libsvml

[DmitryKopelevich]

It worked! It produces the correct result when I turn off those libraries

[Ron_Green]

we were able to find the bug in cexp().  it is the fallback path for older CPUs.  A fix is in the works.

bug id is CMPLRLLVM-50689