different behaviour for different optimisation

[daldystultz]

Dear ifort users: (Ron Green perchance?)

I've recently purchased an intel fortran compiler for my mac OS 10.5.8, and it seems to have come with *no* documentation, nothing resembling the old FORTRAN manuals that adorned every programmer's desk "back in the day". The man pages are useless to me, and so I am stuck bugging this chat group. Sorry if this seems elementary...

With the compiler setting:

ifort -c -o shkset2d.o -O2 -diag-disable remark -m32 shset2d.f

(one routine of 300), my program runs just fine. With

ifort -c -o shkset2d.o -g -debug-parameters -check -fpe1 -traceback -m32 shkset2d.f

I get:

forrtl: severe (193): Run-Time Check Failure. The variable 'roundsc_$ROUNDSC' is being used without being defined

Image PC Routine Line Source

xdzeus36 00A086BF Unknown Unknown Unknown

xdzeus36 00A07AEB Unknown Unknown Unknown

xdzeus36 009C2CF0 Unknown Unknown Unknown

xdzeus36 00984D3B Unknown Unknown Unknown

xdzeus36 00986751 Unknown Unknown Unknown

xdzeus36 0084B79C _roundsc_ 226 roundsc.f

xdzeus36 00789AB5 _shkset2d_ 1403 shkset2d.f

xdzeus36 0050C18D _setup_ 1265 setup.f

xdzeus36 004D35BC _mstart_ 1489 mstart.f

xdzeus36 00001C4B _MAIN__ 1194 zeus3d.f

xdzeus36 00001B3D Unknown Unknown Unknown

xdzeus36 00001AC6 Unknown Unknown Unknown

Unknown 00000001 Unknown Unknown Unknown

roundsc is a real*8 function that shkset2d calls. Line 1403 in shkset2d that uses roundsc for the first time is:

dx1tr = roundsc ( x1dx2a(j+1) - x1a(i+1), isig )

and yes, it looks like roundsc is being used without first being evaluated, if the compiler somehow thinks roundsc is a 2-D array! But surely it's smarter than that! I even declare roundsc to be external. So what gives?

I need to debug this code and thus the compiler settings, and so it's not as simple as saying "well, just use the first setting that worked".

Part of the problem and frustration with migrating to ifort is the lack of useful documentation. I have no clue what compiler settings to use (again, useless man pages), and all the settings I do have are from nudges from various people as answers for other things that went wrong. I would love to have a manual that says things like "If you want to debug and check for x, y, and z, use this setting"; you know, the top-ten compiler settings used by most users. The man pages have *no* examples of any use to me. It's also frustrating that ifort would require you to set a compiler option to enable parameters to be read from a debugger, for crying out loud. Of course I want to access the parameters!!!!! Why must I ask for them??!!?? If I have to ask specifically for parameters to be accessible with a long compiler option such as-debug-parameters, no wonder the man pages are so cluttered. ifort is the most difficult FORTRAN compiler I have ever migrated to, and I'd abandon it were it not the only compiler I seem to be able to use with TotalView.

Advice? Pointers?

Thanks one and all.

Cheers, David.

[Ron_Green]

Quoting - daldystultz

Dear ifort users: (Ron Green perchance?)

I've recently purchased an intel fortran compiler for my mac OS 10.5.8, and it seems to have come with *no* documentation, nothing resembling the old FORTRAN manuals that adorned every programmer's desk "back in the day". The man pages are useless to me, and so I am stuck bugging this chat group. Sorry if this seems elementary...

With the compiler setting:

ifort -c -o shkset2d.o -O2 -diag-disable remark -m32 shset2d.f

(one routine of 300), my program runs just fine. With

ifort -c -o shkset2d.o -g -debug-parameters -check -fpe1 -traceback -m32 shkset2d.f

I get:

forrtl: severe (193): Run-Time Check Failure. The variable 'roundsc_$ROUNDSC' is being used without being defined

Image PC Routine Line Source

xdzeus36 00A086BF Unknown Unknown Unknown

xdzeus36 00A07AEB Unknown Unknown Unknown

xdzeus36 009C2CF0 Unknown Unknown Unknown

xdzeus36 00984D3B Unknown Unknown Unknown

xdzeus36 00986751 Unknown Unknown Unknown

xdzeus36 0084B79C _roundsc_ 226 roundsc.f

xdzeus36 00789AB5 _shkset2d_ 1403 shkset2d.f

xdzeus36 0050C18D _setup_ 1265 setup.f

xdzeus36 004D35BC _mstart_ 1489 mstart.f

xdzeus36 00001C4B _MAIN__ 1194 zeus3d.f

xdzeus36 00001B3D Unknown Unknown Unknown

xdzeus36 00001AC6 Unknown Unknown Unknown

Unknown 00000001 Unknown Unknown Unknown

roundsc is a real*8 function that shkset2d calls. Line 1403 in shkset2d that uses roundsc for the first time is:

dx1tr = roundsc ( x1dx2a(j+1) - x1a(i+1), isig )

and yes, it looks like roundsc is being used without first being evaluated, if the compiler somehow thinks roundsc is a 2-D array! But surely it's smarter than that! I even declare roundsc to be external. So what gives?

I need to debug this code and thus the compiler settings, and so it's not as simple as saying "well, just use the first setting that worked".

Part of the problem and frustration with migrating to ifort is the lack of useful documentation. I have no clue what compiler settings to use (again, useless man pages), and all the settings I do have are from nudges from various people as answers for other things that went wrong. I would love to have a manual that says things like "If you want to debug and check for x, y, and z, use this setting"; you know, the top-ten compiler settings used by most users. The man pages have *no* examples of any use to me. It's also frustrating that ifort would require you to set a compiler option to enable parameters to be read from a debugger, for crying out loud. Of course I want to access the parameters!!!!! Why must I ask for them??!!?? If I have to ask specifically for parameters to be accessible with a long compiler option such as-debug-parameters, no wonder the man pages are so cluttered. ifort is the most difficult FORTRAN compiler I have ever migrated to, and I'd abandon it were it not the only compiler I seem to be able to use with TotalView.

Advice? Pointers?

Thanks one and all.

Cheers, David.

David,

The compiler comes with a set of html docs that should be installed in /opt/intel/Compiler/11.1/058/Documentation/en_US/documentation_f.html

Sometimes the Mac OS Finder will not show /opt. If this is the case, open up Safari or Firefox and point the URL to:

file:///opt/intel/Compiler/11.1/058/Documentation/en_US/documentation_f.html

and that is not a typo, there are 3 slashes after file:

Sometimes I get lazy an point to file:///opt/intel and a file browser window pops up to let you navigate down from there. Handy since I have several versions of the compiler under /opt/intel

The compiler is not confused, the stack trace shows that the call tree went down into function roundsc. What is in roundsc.f at line 226? This is where the compiler thinks the function return name is being used on the right-hand-side of an expression prior to being defined. Here is an example:

Testme.f90
----------
1 program testme
2 external roundsc
3 real*8 :: roundsc, foo
4
5 foo = roundsc()
6
7 end
8
9 real*8 function roundsc()
10
11 print*, "roundsc is ", roundsc
12 roundsc = 42
13 print*, "roundsc is ", roundsc
14
15 end function roundsc

-------

I realize the function declaration is 'old school' so zero points for style. Anyhow, without checking:

FordPrefect:~ rwgreen$ ifort -o testme testme.f90
FordPrefect:~ rwgreen$ ./testme
roundsc is 0.000000000000000E+000
roundsc is 42.0000000000000

but with checking:
FordPrefect:~ rwgreen$ ifort -o testme testme.f90 -check -g -traceback
FordPrefect:~ rwgreen$ ./testme
forrtl: severe (193): Run-Time Check Failure. The variable 'roundsc_$ROUNDSC' is being used without being defined
Image PC Routine Line Source
testme 000000010006DE1C Unknown Unknown Unknown
testme 000000010006C954 Unknown Unknown Unknown
testme 0000000100045027 Unknown Unknown Unknown
testme 000000010001B518 Unknown Unknown Unknown
testme 000000010001BF78 Unknown Unknown Unknown
testme 000000010000134E _roundsc_ 11 testme.f90
testme 00000001000012BE _MAIN__ 5 testme.f90
testme 000000010000128C Unknown Unknown Unknown
testme 0000000100001224 Unknown Unknown Unknown

You might try what I did and put a print*, statement before line 226 in roundsc.f and print the function return value. My guess is some branch is taken in roundsc() such that the return value is used before being set. even something like:

if ( roundsc .eq. 0 ) then
roundsc = 42.0
end if

could cause the runtime check for uninitialized variables to flag the error. You can selectively use -check to specify all the other checks excluding uninit: -check pointers,arg_temp_created,format for example.

If your documentation is not present where I said it should be, I want to know about it. We have an outstanding issue on newer Mac Pro systems where IDB is not installed, but so far we think it's isolated to Nehalem processor based Mac Pros (2009 models).

ron

[Steven_L_Intel1]

I think you misunderstand what "parameters" means here. It does not mean routine arguments, but rather, PARAMETER constants, of which there may be thousands declared in INCLUDE files. Most users don't need to get the values of PARAMETER constants in the debugger, but if you do, we can do that. It requires a lot of extra work in the compiler and enlarges the generated object, so it is not the default.

[daldystultz]

Hi Ron:

Thanks for coming to the rescue---again!

Line 226 is the end statement. Here are the guts of roundsc:

if (isigfig .le. 0) return

q1 = abs(scalar)

if (q1 .le. tiny) return

q1 = log10 ( q1 )

q2 = sign ( 0.5d0, q1 )

i1 = isigfig - int ( q1 + q2 + 0.5d0 )

i2 = min ( -3, isigfig - 14 )

q1 = 10.0d0**i1

q2 = 10.0d0**i2

q3 = sign ( q2, scalar )

roundsc = dnint ( scalar * q1 + q3 ) / q1

c

return

end

The 200+ lines above are common deck declarations and comments that have nothing to do with how the function runs. Yes, there is the *conditional* return right at the beginning as you foresaw. As it turns out, isigfig = 12, and this return statement is not executed. Even still, it complains that roundsc is not initialised? It is! This is the first compiler that has flagged this even with initialisation traps set, so I wonder if the intel compiler isn't being a little too aggressive here.

So, its the -check that is checking for uninitialised variables, huhn? Who knew? Here I thought it was just checking array bounds. You suggest

-check pointers,arg_temp_created,format

What, pray tell, are these? This may be, I'm afraid, another example of why I find the intel options so user-hostile. Long, largely I would argue unnecessary option settings for what ought to be standard checking. i.e., there ought to be a single setting, -check would be nice, that checks the obvious things like array bounds and creation of NaNs and nothing else. There also ought to be a 5-10 page document that includes this along with the other 5% of the options that get 95% of the use. You'll hear me harp about this a lot---from my end it just seems like an obvious thing to do.

So, to correct this "error", I should probably just set roundsc = scalar (an input variable) right before the first if statement. Correct?

I shall look for the documents you suggested, though I do seem to recall finding these to be rather overwhelming to find anything in. Let me give them another look, and I will let you know. I do know that I do not have IDB. I looked for it as an alternative to TotalView when TV was acting up, and it wasn't there. The person who was sitting with me at my Mac was surprised as he said he is used to having idb wherever ifort is installed.

Thanks again.

Cheers, David.

[daldystultz]

Quoting - Steve Lionel (Intel)

I think you misunderstand what "parameters" means here. It does not mean routine arguments, but rather, PARAMETER constants, of which there may be thousands declared in INCLUDE files. Most users don't need to get the values of PARAMETER constants in the debugger, but if you do, we can do that. It requires a lot of extra work in the compiler and enlarges the generated object, so it is not the default.

Hi Steve:

I think of a parameter as something in a parameter statement, typically used to dimension an array, and these are what are not available to the debugger without that long compiler option. I can't imagine an application that would have *thousands* of parameters declared, but if one were, I can't see how that would make the object so much larger than what the presumably many thousands of variables already create. While debugging, one is rarely concerned about the size of the executable---we're not going for speed here, we're trying to find a bug---and none of the many FORTRAN compilers I have ever used in 25 years has ever required me to be aware enough of the options to ask for parameters to be available in the debugger. It seems to me that the user-friendly approach would be to have an option to *exclude* parameters which a savvy user would know to ask for. What intel has done is to design a compiler---without suitable documentation I might add---that expects a novice to know enough to seek out an option to include parameters; something that this programmer with 25 years of computing experience had to have pointed out to him!

Cheers, David.

[daldystultz]

Ron:

Yes, my setting roundsc to scalar just before the first if statement did the trick. I'll let you know about those documents.

Thanks again!

Cheers, David.

[Ron_Green]

Quoting - daldystultz

Hi Ron:

Thanks for coming to the rescue---again!

Line 226 is the end statement. Here are the guts of roundsc:

if (isigfig .le. 0) return

q1 = abs(scalar)

if (q1 .le. tiny) return

q1 = log10 ( q1 )

q2 = sign ( 0.5d0, q1 )

i1 = isigfig - int ( q1 + q2 + 0.5d0 )

i2 = min ( -3, isigfig - 14 )

q1 = 10.0d0**i1

q2 = 10.0d0**i2

q3 = sign ( q2, scalar )

roundsc = dnint ( scalar * q1 + q3 ) / q1

c

return

end

The 200+ lines above are common deck declarations and comments that have nothing to do with how the function runs. Yes, there is the *conditional* return right at the beginning as you foresaw. As it turns out, isigfig = 12, and this return statement is not executed. Even still, it complains that roundsc is not initialised? It is! This is the first compiler that has flagged this even with initialisation traps set, so I wonder if the intel compiler isn't being a little too aggressive here.

So, its the -check that is checking for uninitialised variables, huhn? Who knew? Here I thought it was just checking array bounds. You suggest

-check pointers,arg_temp_created,format

What, pray tell, are these? This may be, I'm afraid, another example of why I find the intel options so user-hostile. Long, largely I would argue unnecessary option settings for what ought to be standard checking. i.e., there ought to be a single setting, -check would be nice, that checks the obvious things like array bounds and creation of NaNs and nothing else. There also ought to be a 5-10 page document that includes this along with the other 5% of the options that get 95% of the use. You'll hear me harp about this a lot---from my end it just seems like an obvious thing to do.

So, to correct this "error", I should probably just set roundsc = scalar (an input variable) right before the first if statement. Correct?

I shall look for the documents you suggested, though I do seem to recall finding these to be rather overwhelming to find anything in. Let me give them another look, and I will let you know. I do know that I do not have IDB. I looked for it as an alternative to TotalView when TV was acting up, and it wasn't there. The person who was sitting with me at my Mac was surprised as he said he is used to having idb wherever ifort is installed.

Thanks again.

Cheers, David.

Good, I am glad that fixed the issue. And the code is no doubt better off for the change.

If you need floating point checks, you will also need to add -fpe0 or -fpe0 -no-ftz

Here is the documentation on this:

-fpe0:

Floating-point invalid, divide-by-zero, and overflow exceptions are enabled. If any such exceptions occur, execution is aborted. This option sets the -ftz (Linux and Mac OS X) or /Qftz (Windows) option; therefore underflow results will be set to zero unless you explicitly specify -no-ftz (Linux and Mac OS X)

So if you are concerned about trapping denormals, you will want -fpe0 -no-ftz

There a good number of -check options, so I recommend browsing through those:
file:///opt/intel/Compiler/11.1/058/Documentation/en_US/compiler_f/com.intel.compilers.ifort.docset/Contents/Resources/Documents/ifort/doc_files/index.htm - from there navigate to Compiler Options -> Alphabetical Compiler Options.

I have a task in my 'to do someday soon' list to write an 'Essential Guide to Intel Compiler Options'. The 11.1 launch and some other tasks have sapped my time lately. I hope to dig out of this hole in the next couple of weeks and get working on it. I appreciate the encouragement to do so.

ron

[Steven_L_Intel1]

How many Fortran compilers have you used that permitted viewing PARAMETER constants in the debugger. I've surveyed quite a few and this is rare. Intel didn't create that option - it first surfaced in VAX Fortran in the 1980s. The DEC team reimplemented it in DEC Fortran 90, and then had to do it yet again for Intel Fortran due to differences in the code generators.

You'll have to trust me when I say that there are many applications that have thousands of PARAMETER constants. These come from library INCLUDE files. The option is very useful and prevents compile times from going through the roof for some applications.

[daldystultz]

Quoting - Ronald W. Green (Intel)

Good, I am glad that fixed the issue. And the code is no doubt better off for the change.

If you need floating point checks, you will also need to add -fpe0 or -fpe0 -no-ftz

I have a task in my 'to do someday soon' list to write an 'Essential Guide to Intel Compiler Options'. The 11.1 launch and some other tasks have sapped my time lately. I hope to dig out of this hole in the next couple of weeks and get working on it. I appreciate the encouragement to do so.

ron

Yes, it is a change that the code needed. I'm just surprised that the error message cropped up when the situation was that roundsc was, in fact, being set. But I am persuaded that this is a good thing, as this would have bitten me at some point down the line when the condition wasn't true.

I've been using -fpe1. So what does -fpe1 do or not do that -fpe0 does?

I would love to have a copy of your Essential guide" whenever it is ready for someone to browse through it or proof it.

Thanks again Ron.

Cheers, David

[daldystultz]

Quoting - Steve Lionel (Intel)

How many Fortran compilers have you used that permitted viewing PARAMETER constants in the debugger. I've surveyed quite a few and this is rare. Intel didn't create that option - it first surfaced in VAX Fortran in the 1980s. The DEC team reimplemented it in DEC Fortran 90, and then had to do it yet again for Intel Fortran due to differences in the code generators.

You'll have to trust me when I say that there are many applications that have thousands of PARAMETER constants. These come from library INCLUDE files. The option is very useful and prevents compile times from going through the roof for some applications.

Hi Steve:

Ummm, well, Cray's old DDT and CDBX using their compiler CF77 and CFT77, Sun's DBX and window-based debugger using their F77, and the AIX version of DBX using their version of F77 all let me check parameter values when I needed to remind myself of what the array size was, for example. I couldn't change these values like I could variables, but I could always check them. I forget whether or not Convex' compiler and debugger allowed me to look at parameters---too many years ago and too seldom used. It is true I have not done any extensive debugging with F90 or F95 compilers, and I've never used DEC compilers. Perhaps this is the difference?

In any case, I take your word on it! I've learned something new, and thank you for your contribution to this discussion.

Cheers, David.