topic Re: Alpha to Integrity application porting - issue in Operating System - OpenVMS

Alpha to Integrity application porting - issue

Jenwae — Wed, 11 Jul 2012 08:51:02 GMT

Hi All,

I have a Fortran application running on Alpha 8.3 re-written in C and now being ported to Integrity.

The application reads from and writes to legacy binary data files on disk.

We have re-compiled the C application with the option /FLOAT=G_FLOAT to support the data files.

Everything seems to run just fine, except for 2 issues we recently encountered:

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

For example, at the source line:

double my_local_double;

my_local_double += common_double_variable_read_from_file;

2) We have variables declared as float. Apparently, after compiling in g_float, the data in the float changed.

So we wrote a small program to test out.

The value changed after passed to a subroutine/function.

For example, in MYPROGRAM.C

int main() {

float my_local_float = 12233.00

printf(" Float value = %f", my_local_float");

foo(my_local_float);

return

}

In FOO.C

void foo(float x) {

printf(" Float value = %f", x);

return;

}

The value printed in MYPROGRAM.C is different than in FOO.C

Any advice is appreciated.

Thank you,

James

Re: Alpha to Integrity application porting - issue

Eberhard Heuser — Wed, 11 Jul 2012 11:27:49 GMT

Strange:

#include <stdio.h>
    void foo(float x) {
      printf(" Float value = %f", x);
      return;
    }

int main() {

       float my_local_float = 12233.00;
       printf(" Float value = %f", my_local_float);
       foo(my_local_float);
    }

$ cc/float=g_float tf.c

$ link tk

$ r tf

Float value = 12233.000000 Float value = 12233.000000

$ cc/version
HP C V7.3-020 on OpenVMS IA64 V8.4

+ all actual patches (i.e. CRTL)

Eberhard

Re: Alpha to Integrity application porting - issue

abrsvc — Wed, 11 Jul 2012 12:45:33 GMT

One thing that would be helpful here is knowing what the actual difference is. Please provide the actual output from the programs as listed that show the problem. Also, you initially describe using double, yet the supplied program uses standard float. Where is the problem, with double float or float?

If you can show the different values, please also print out the variables in hex. An examination of the actual stored binary (in hex) will be helpful as well.

Dan

Re: Alpha to Integrity application porting - issue

Duncan Morris — Wed, 11 Jul 2012 13:07:46 GMT

Look out for your compiler warnings!

$ ty test.c
int main() {
       float my_local_float = 12233.00;
       printf(" Float value = %f", my_local_float);
       foo(my_local_float);
       return 1;
    }
void foo(float x) {
      printf(" Float value = %f", x);
      return;
    }

produces:

$ cc/ver
HP C V7.3-020 on OpenVMS IA64 V8.4
$ cc/float=g_float test

printf(" Float value = %f", my_local_float);
.......^
%CC-I-IMPLICITFUNC, In this statement, the identifier "printf" is implicitly declared as a function.
at line number 3 in file SYS$SYSROOT:[SYSMGR]TEST.C;2

foo(my_local_float);
.......^
%CC-I-IMPLICITFUNC, In this statement, the identifier "foo" is implicitly declared as a function.
at line number 4 in file SYS$SYSROOT:[SYSMGR]TEST.C;2

void foo(float x) {
.....^
%CC-W-NOTCOMPATIMP, In this declaration, the type of the function "foo" is not compatible with the earlier implicit declaration of "
foo" at line number 4 in file SYS$SYSROOT:[SYSMGR]TEST.C;2.
at line number 7 in file SYS$SYSROOT:[SYSMGR]TEST.C;2

$ link test
%ILINK-W-COMPWARN, compilation warnings
module: TEST
file: SYS$SYSROOT:[SYSMGR]TEST.OBJ;3

$ run test
Float value = 12233.000000 Float value = 1.811661

but

$ ty test.c
void foo(float x) {
      printf(" Float value = %f", x);
      return;
    }
int main() {
       float my_local_float = 12233.00;
       printf(" Float value = %f", my_local_float);
       foo(my_local_float);
       return 1;
    }
$ cc/float=g_float test

      printf(" Float value = %f", x);
......^
%CC-I-IMPLICITFUNC, In this statement, the identifier "printf" is implicitly declared as a function.
at line number 2 in file SYS$SYSROOT:[SYSMGR]TEST.C;3
$ link test
$ run test
Float value = 12233.000000 Float value = 12233.000000
$

Duncan

Re: Alpha to Integrity application porting - issue

abrsvc — Wed, 11 Jul 2012 13:27:18 GMT

If you have shown the same as the original poster, then this is clearly an indication that the "bits" of the variable are being interpreted differently (as one would expect).

The variables are passed by reference. In other words the memory address of the variable is passed NOT the actual variable value. This means that at address A, the bits are interpreted as a G_float using 64 bits and in the FOO routine, address A is interpreted as a float using 32 bits.

All floating numbers are composed of 3 parts:
1) Sign bit
2) Exponent
3) fraction bits

For G_float, bits 0-51 are part of the fraction

Note that the fraction portion of hte G_float will be the only part used if the address is viewed as a standard 32 bit floating variable. Thus the difference in reported value.

Dan

Re: Alpha to Integrity application porting - issue

Craig A Berry — Wed, 11 Jul 2012 15:02:32 GMT

@abrsvc wrote:

The variables are passed by reference.

No, in C they are passed by value, but the value placed on the stack is in the format of the caller. If the function called expects a different format, bad things happen.

For the OP question #1. Are you absolutely certain the data read from the file are G_FLOAT, not D_FLOAT and that there aren't other problems such as structure member alignment in the move from Fortran to C? Have you stepped through the program in the debugger and done

examine/g_float common_double_variable_read_from_file

examine/d_float common_double_variable_read_from_file

?

For question #2, are you sure you are recompiling both modules myprogram.c and foo.c with the same floating point options? If one is compiled with /G_FLOAT and one is not, you will very likely get the symptom you are seeing or worse.

Re: Alpha to Integrity application porting - issue

Hein van den Heuvel — Wed, 11 Jul 2012 20:37:44 GMT

     double my_local_double;
     my_local_double += common_double_variable_read_from_file;

As presented, that's broken / unpredictable code because my_local_double is not initialized.

Try:

double my_local_double = 0;

fwiw,

Hein.

Re: Alpha to Integrity application porting - issue

Jenwae — Wed, 11 Jul 2012 21:26:16 GMT

Hi All,

Thank you for your review and replies.

Here is my response/clarifcation to your queries.

To Eberhard:

Yes, strange indeed. If routine Foo is declared in the same file as main, then both float values printed out are the same, REGARDLESS if the compile option /FLOAT=ieee_float or /FLOAT=g_float is used.

However, if Foo is declared as a separate C file, then it gets interesting.

When compiled with ieee_float, result is normal. With /FLOAT=g_float, the values are mangled

Here what I got when I compiled BOTH the C files (myprogram.c, foo.c) with cc/float=g_float, and linked as link myprogram, foo.

Float value in main = 12233.000000 (hex)=e48040e7)
Float value in Foo = 1.811661 (hex=fc90401c)

To ABSRVC (Dan):

We actually encountered 2 issues.

The 2nd issue is with the float variable, which I wrote simple C programs to prove the point.

The output is as displayed above.

To Duncan:

Yes, if we put the FOO routine in the same file as the main (MYPROGRAM.C), then we don't have a problem (whether we compile with IEEE_FLOAT or G_FLOAT).

The float value changes only when FOO routine is in its own file (FOO.C), and we compile both files (FOO.C and MYPROGRAM.C) with G_FLOAT. Why is this not documented by HP, or maybe I'm overlooking something.

To Craig:

Yes, I compiled both C files with the same /FLOAT option. With /FLOAT=IEEE_FLOAT, no problem, but with /FLOAT=G_FLOAT, I get mangled float variable values.

For your 1st query, yes, those FP data are G_FLOAT.

I did step through, and when I examine in BINARY, it shows zeroes.

examine/binary common_double_variable_read_from_file

I will examine in g_float and d_float and let you know the outcome.

To Hein:

I did init the local variable double.

But I think the FLTINV exception is triggered by the common_double_variable_read_from_file.

double my_local_double = 0;

my_local_double += common_double_variable_read_from_file;

Any clarification is appreciated. I'm trying to avoid doing Database conversion,

Thank you so much!

Joel

Re: Alpha to Integrity application porting - issue

John Gillings — Wed, 11 Jul 2012 21:30:13 GMT

James,

>We have re-compiled the C application with the option /FLOAT=G_FLOAT to support the data files.

I'd recommend you bite the bullet and convert everything to the native floating format of your new system (IEEE). Making the application non-standard for the sake of some legacy data files is a bad tradeoff. You risk the consequences of floating format mismatches (which is almost certainly what's going on here), as well as potential performance issues.

Build yourself a small program to convert the data in any existing files. In theory this should be very simple and very easy to validate. Tag the data files so you can tell if they're in the wrong format. The extra effort will be well worth it in the long run, even if there's a lot of data. You don't need to convert everything up front, just as needed. (Indeed, you could even build a conversion step into the application itself, making it transparent to users).

Re: Alpha to Integrity application porting - issue

jreagan — Wed, 11 Jul 2012 21:42:29 GMT

How did you compile the Fortran application?

Don't forget that the default changed from VAX F/G on Alpha to IEEE S/T on Itanium. It changed for BOTH Fortran and C. And the /IEEE_MODE changed from FAST to DENORM.

Re: Alpha to Integrity application porting - issue

Steven Schweda — Wed, 11 Jul 2012 22:12:28 GMT

Re: Alpha to Integrity application porting - issue

Richard Brodie_1 — Thu, 12 Jul 2012 10:54:27 GMT

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.

Re: Alpha to Integrity application porting - issue

Richard Brodie_1 — Thu, 12 Jul 2012 12:47:52 GMT

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

Re: Alpha to Integrity application porting - issue

Jenwae — Thu, 12 Jul 2012 16:51:44 GMT

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

Re: Alpha to Integrity application porting - issue

abrsvc — Thu, 12 Jul 2012 17:02:44 GMT

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

Re: Alpha to Integrity application porting - issue

Steven Schweda — Thu, 12 Jul 2012 17:09:52 GMT

Re: Alpha to Integrity application porting - issue

Dennis Handly — Fri, 13 Jul 2012 10:37:10 GMT

>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.

Re: Alpha to Integrity application porting - issue

Ph Vouters — Sat, 21 Jul 2012 14:38:49 GMT

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.

Re: Alpha to Integrity application porting - issue

Ph Vouters — Sat, 21 Jul 2012 15:55:04 GMT

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

Re: Alpha to Integrity application porting - issue

jreagan — Mon, 23 Jul 2012 18:57:19 GMT

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.