Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
28853 Discussions

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

DmitryKopelevich
Beginner
4,035 Views

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?

0 Kudos
1 Solution
Ron_Green
Moderator
3,429 Views

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

 

-no-intel-lib=libimf,libsvml

 

 

View solution in original post

0 Kudos
21 Replies
mecej4
Honored Contributor III
3,726 Views

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).

0 Kudos
DmitryKopelevich
Beginner
3,720 Views

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?

0 Kudos
mecej4
Honored Contributor III
3,696 Views

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.

0 Kudos
DmitryKopelevich
Beginner
3,672 Views

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

 

0 Kudos
Barbara_P_Intel
Employee
3,634 Views

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. 

 

0 Kudos
DmitryKopelevich
Beginner
3,602 Views

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

0 Kudos
mecej4
Honored Contributor III
3,583 Views

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

0 Kudos
DmitryKopelevich
Beginner
3,556 Views

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.

0 Kudos
Barbara_P_Intel
Employee
3,517 Views

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.

 

0 Kudos
DmitryKopelevich
Beginner
3,502 Views

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.

0 Kudos
Ron_Green
Moderator
3,476 Views

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.

0 Kudos
Ron_Green
Moderator
3,475 Views

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

 

 

0 Kudos
DmitryKopelevich
Beginner
3,397 Views

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)
0 Kudos
Ron_Green
Moderator
3,367 Views

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

0 Kudos
DmitryKopelevich
Beginner
3,359 Views

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.

0 Kudos
mecej4
Honored Contributor III
3,301 Views

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

 

 

0 Kudos
DmitryKopelevich
Beginner
3,218 Views

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

 

0 Kudos
Ron_Green
Moderator
3,430 Views

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

 

-no-intel-lib=libimf,libsvml

 

 

0 Kudos
DmitryKopelevich
Beginner
3,138 Views

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

0 Kudos
Ron_Green
Moderator
3,108 Views

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

 

 

Reply