Known bugs of ifor8.1 on itanium?

[Morales__Juan]

Hi,

We are going through a painful change of compiler versions from 7.1 to 8.1 on Itanium machines running Linux. We only moved from 7. 1 to 8.1 to be able to install the SIGFPE handler. That now works!! However, a bunch of compiler misbehavior has been triggered throughout the code. Examples are:

1 - it does not respect (or propely resolve)IF statements when comparing very small reals (near machine precision).. We have to recode about 5 different sections of code (in different routines) to make it work.. 7.1 worked fine with the same code (no problems on AIX/IRIX/OSF/WinXP/HPUX/HPUX-IA64)

2 - sometimes if certain variables are "SAVE"d, the IF statements behave properly. It does not happen in debug mode. We lowered optimization levels from -O3 to -O2, and no difference.. 7.1 ocassionally needed "SAVE"d variables, but this time is going beyond tolerable..

3 - The most bizarre of them all is the following:

....

CSTRING = 'OLD'

CALL MAKDIR(CSTRING, 'STOP',CRESLT)

...

SUBROUTINE (CSTRING,CERACT,CRESLT)

CHARACTER*(*) CSTRING,CERACT,CRESLT

WRITE(*,*) 'Value = ' , CSTRING

..

END

When run, the print out is:

Value = old

However, if the value of CSTRING is anything else, for example, OLD1, the proper output is done (OLD1)..

Has anybody gone through such problems,

Regards,

Juan Carlos

[Steven_L_Intel1]

It is not clear to me, from what you have written, that the behavior you note is due to compiler bugs. You may have been relying on unpredictable behavior. The third entry, I'm afraid, I don't understand - the code does not match your description.

If you believe there are errors in the compiler, please submit complete examples and a description of the incorrect behavior to us at Intel Premier Support - we'll be glad to investigate.

[Morales__Juan]

HI Steve,

Thanks for your comments.. I must admit that I have not been able to reproduce the behavior in an isolated simplified routine, like the one Intel Premier Support would love to see. However, I have seen a lot of compiler bugs around (usually bizarre ones), not only Intel's..

Sample statements for theinteger comparisonslook as follows:

...

WRITE(*,*) 'NVAL = ', NVAL_ZN

WRITE(*,*) 'Volume = ', TOTALVOL

IF (NVAL_ZN .GE. IONE) THEN

TURBLS = TURBLS_USR / TOTALVOL

END IF

...

The output will be

NVAL = 0

TOTALVOL = 0.

Then a floating point error occurs..Sure, it is dividing by zero...

However, if the WRITE statements are within the IF, the code works..

I have other ones with real comparison as well.

For the third entry in the previous email.. You said the code does not match the description.. Where does it not match? It is an extract, not complete code.. Is it the upper case input, but lower case output?

So far, we just turned off the SIGFPE handler calls.. The code seems to run properly (150 test cases are running as expected)

As I find time, I will try to isolate/reproduce the problem into something I can pass along to Intel Premier Support. Would object code (*.o)+source code(*.F)for the failing routine+ plus a non-stripped core dumpbe helpful tothem somehow?

Regards,

Juan Carlos

[Steven_L_Intel1]

Sorry, had missed the lowercase. But I can't imagine how that can be due to a compiler bug. Without seeing a complete program, I can't speculate further.

Sorry also to say that we can't do much with core dumps. We need complete sources so that we can build the application and run it here. If you are using a third-party library, you can provide us the library, but lack of sources may make it difficult to analyze. We won't accept just objects and isolated routine sources.

I've seen compiler bugs too - more than I care to count. But not every application failure or bizarre behavior is due to a compiler bug.

Message Edited by sblionel on 03-15-2005 11:16 AM