Alpha to Integrity application porting - issue

[Richard Brodie_1]

I think the moral is that it is easier to get your code to compile without warnings, than it is to work out what the consequences of not doing so are.

[Richard Brodie_1]

It is documented in the language reference guide:

"Arguments to functions that have no prototype in scope are not converted to the types of the parameters. Instead, the expressions in the argument list are converted according to the following rules:

• Any arguments of type float are converted to double .

http://h71000.www7.hp.com/commercial/c/docs/6180profile_014.html#func_arg_convert_sec

[Jenwae]

Hi All,

Thank you for helping in our issues. It helps to have so many expertise around.

To Richard and Steven, thank you, Your explanation provided the solution to Issue #2 regarding the float variable. By doing proper prototyping, the mystery is resolved. (We had prototype the function foo, but without the argument type).

We are still mystified with Issue #1.

Although we have compiled our application with /FLOAT=g_float, sometimes when computing on certain double variable (read from the file), it crashed. I have debugged and examine the value /binary, and it all shows zeroes. I think the FLTINV is triggered on the double field read from the file.

I reproduce my query below.

1) On certain occasion, the application will crash with SYSTEM-F-FLTINV, floating invalid operation.

For example, at the source line:

     double my_double = 0;

     my_double = 1st_common_double_field_read_from_file + 2nd_common_double_field_read_from_file;

Thank you,

James

[abrsvc]

RE: FLTINV message

Per the definition/format of a G_Float number, the above message will likely appear if the sign bit is set and the exponent bits are zero(0).  This would appear as 80000000 hex if you look at a register value and 00000080hex if in memory.  This is per the Alpha arch reference pg 2-5.

I realize that this is on an I64 machine, but I believe that the same rules apply regarding the sign bit and exponent portion.  Verify the bit layout with the debugger.

Dan

[Dennis Handly]

>We had prototype the function foo, but without the argument type.

This is a K&R prototype, next to useless.  It might be helpful if you port your application to C++ or C99, at least to get the strong type checking.

[Ph Vouters]

As a side note, running the VMS debugger and doing DBG> SHOW SYMBOL/TYPE variable might have helped you pinpoint the problem quicker. Be aware that I did not test on your actual case. This is just a free advice.

[Ph Vouters]

About dealing with VAX Floats on Itanium, this document proves that it is always better to deal with IEEE floats if code performance is an issue. The document is viewable at :

http://vouters.dyndns.org/tima/OpenVMS-IA64-VAX-IEEE-floats-Performances_on_double_operations.html

Philippe

[jreagan]

Note that Ph's analysis of D vs T is the worst case.  D_FLOAT conversion is very ugly compared to G to T (and T to G).  The layout of D float requires more code to detect various invalid floatings, NaNs, etc.  The D-to-T routine is much more complicated (more instructions and more registers) than G-to-T.  The S-to-F isn't a picnic either to handle all the edge conditions. 

IEEE is much preferred on Itanium (which is why we changed the default) but if you have to use a VAX floating format, G would be my pick.