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

Simple Program Gets WRONG Answer (equivalencing integers and reals)

elazarus
Beginner
695 Views

We frequently hide integers in real variables (typically real arrays hiding both reals and integers). This small program gets to the crux of the problem we are having. The actual software has been in use for 30 years and this is the first time (Intel compiler) we have ever seen this behavior.

program test
real r
integer j
equivalence (r,j)
real a
integer ia
equivalence(a,ia)
ia = 54
r = a
write(6,*) 'j=', j
call exit
end

The program prints out ZERO; I expected 54. SIZEOF yields 4 for all variables. If I print IA and A in HEX or OCTAL, IA looks like "54"; A is completely different; don't HEX and OCTAL formats just look at bit patterns? I believe my compiler optimization is set to -O0.

earl

0 Kudos
4 Replies
elazarus
Beginner
694 Views

MORE INFORMATION:

The program runs correctly under -O1 and -O2, but not under -O0. So the question remains: why?

The bad news is that we can't use -O2 because the optimization "breaks" several of our routines. We now have to determine if we can live with -O1.

0 Kudos
Kevin_D_Intel
Employee
695 Views

I am seeing the expected results of 54 at all opt-levels (-O0, -O1, -O2, -O3) with the current 11.0.069 compiler on both IA-32 and Intel 64.

$ ifort -V -O0 eqiv.f90;./a.out

Intel Fortran Intel 64 Compiler Professional for applications running on Intel 64, Version 11.0 Build 20080930 Package ID: l_cprof_p_11.0.069

Copyright (C) 1985-2008 Intel Corporation. All rights reserved.

Intel Fortran 11.0-1549

GNU ld version 2.16.91.0.5 20051219 (SUSE Linux)

j= 54

$ ifort -V -O1 eqiv.f90;./a.out

Intel Fortran Intel 64 Compiler Professional for applications running on Intel 64, Version 11.0 Build 20080930 Package ID: l_cprof_p_11.0.069

Copyright (C) 1985-2008 Intel Corporation. All rights reserved.

Intel Fortran 11.0-1549

GNU ld version 2.16.91.0.5 20051219 (SUSE Linux)

j= 54

$ ifort -V -O2 eqiv.f90;./a.out

Intel Fortran Intel 64 Compiler Professional for applications running on Intel 64, Version 11.0 Build 20080930 Package ID: l_cprof_p_11.0.069

Copyright (C) 1985-2008 Intel Corporation. All rights reserved.

Intel Fortran 11.0-1549

GNU ld version 2.16.91.0.5 20051219 (SUSE Linux)

j= 54

$> ifort -V -O3 eqiv.f90;./a.out

Intel Fortran Intel 64 Compiler Professional for applications running on Intel 64, Version 11.0 Build 20080930 Package ID: l_cprof_p_11.0.069

Copyright (C) 1985-2008 Intel Corporation. All rights reserved.

Intel Fortran 11.0-1549

GNU ld version 2.16.91.0.5 20051219 (SUSE Linux)

j= 54

What specific Intel compiler are you using (ifort V)?

If you are not using our latest 11.0 Release, could you?

0 Kudos
elazarus
Beginner
695 Views

We are running V10.1, so that may be the problem. I'll close this thread based on your reply. Unfortunately, we are a large corporatiion and software changes required a room full of approvals, but that is our problem.

thanks

0 Kudos
Steven_L_Intel1
Employee
695 Views
Quoting - elazarus

We frequently hide integers in real variables (typically real arrays hiding both reals and integers). This small program gets to the crux of the problem we are having. The actual software has been in use for 30 years and this is the first time (Intel compiler) we have ever seen this behavior.

program test
real r
integer j
equivalence (r,j)
real a
integer ia
equivalence(a,ia)
ia = 54
r = a
write(6,*) 'j=', j
call exit
end

The program prints out ZERO; I expected 54. SIZEOF yields 4 for all variables. If I print IA and A in HEX or OCTAL, IA looks like "54"; A is completely different; don't HEX and OCTAL formats just look at bit patterns? I believe my compiler optimization is set to -O0.

earl

This coding practice is very dangerous and likely to fail. If you do all the assignments with integers it should be ok, but as soon as you say "r=a" you will run into things such as the processor converting signaling NaNs to quiet NaNs and, what I think is affecting you, treating denormals as zero. An integer 54 is, when treated as a single-precision real, a denormalized value and, depending on the compiler mode, denormals are flushed to zero on access.

This is a bug in your code and I am surprised it took you so long to trip over it.

0 Kudos
Reply