- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page