Floating point problems when using /ARCH=HOST in PASCAL compile

[Chris Barratt]

OpenVMS 7.3-2
Pascal 5.8-92

Recently we tried to use the /ARCHITECTURE=HOST qualifier on our PASCAL program compiles, but have run into a problem with one of our subroutines.

A number of problems have been encountered,
- depending on how a couple of real variables are initialised, the program may crash at run-time with a SYSTEM-F-FLTINV error
- when I get past this problem, I see an add operation between 2 reals that only works correctly the first time
- a "<" comparison between 2 reals does not work correctly

Removing the /ARCHITECT qualifier fixes these problems.

I am working on a test case and will most likely log a call with support, but wondered if there is any known issues out there that might help.

Thanks,
Chris

[John Gillings]

Chris,

Please log a case so we can work out if this is an application or compiler issue. Post source code with your case.

[Chris Barratt]

I have my test case ready now, but will not be able to log a call until next Monday.
In the meantime, I have attached a ZIP file with the test case components in it.

Cheers,
chris

P.S. Is there a way to log call electronically ?

[John Gillings]

Chris,
Please send me mail.

[Ian Miller.]

Cris,
you may be able to log a call via Support Case Manager
http://www5.itrc.hp.com/service/mcm/homepageRequest.do

[John Reagan]

What Alpha machine are you using? Do a

$ write sys$output f$getsyi("hw_name")

and post the results.

The /ARCH=HOST qualifier allows the code generator to use instructions available on the host machine. By default, the compiler still uses the older "GENERIC" model which is based loosely on the EV4 instruction set. Notably, it does not include byte and word instructions. Using /ARCH=HOST on any modern Alpha will get you byte/word instructions and probably others. However, it does not change floating point behavior in any notable way. Other than new instructions to move directly between floating and integer registers, the floating instruction set for Alpha has been quite stable over the lifetime.

I'm going to guess that with /ARCH=HOST, different instructions were used or perhaps just different registers were used which uncovered an uninitialized variable in your program.

Have you compiled with /USAGE=ALL/CHECK=ALL? That might help you find something.

If you still have problems and have a small example, send it to either John Gillings or myself. We'll be glad to help out.

John
Pascal Project Leader

[Jan van den Ende]

Chris,

reading your question and John's answer, the more suspicious trait in me tried to combine the two and cooked up a scenario where you did your compile on a more recent CPU, and then the run on an older CPU (of course, on both sides of the extra functionality boundery).

Can you positively dismiss this possibility?

Or even, John, is my logic correct, or am I seeing ghosts?

just EUR 0.02

Proost.

Have one on me.

Jan

[Chris Barratt]

Thanks John and Jan.

Each node in our cluster (there are 3) is a COMPAQ Alphaserver DS20E 666 MHz (from f$getsyi).

I am only compiling and running on the development machine.

Have logged the case with John Gillings now, with a simple test case. My bet is as JR says, and it is an uninitialised variable or some such - however, the test case involved cutting down all the code in the original programs, so I thought I may have found a case like that.

One feature of this problem that I have not commented on so far is that the problems happen within a subroutine. Any floating point stuff in the main program works fine.

Thanks,
Chris

[John Gillings · Accepted solution]

For those interested in looking at the code, UNZIP Chris's ZIP file onto an OpenVMS system and SET FILE/ATTR=RFM:VAR then edit the files and remove any junk at the end.

ZIP still doesn't really understand OpenVMS files :-(

The root cause appears to be a PACKED RECORD declaration. This has resulted in most of the fields in the record (Floats, quads and integers) being unaligned. I think there may be something wrong with the code Pascal is generating to fix up the alignments, but that needs to be confirmed by John Reagan. Regardless, the fix is simply to remove the word "PACKED" from the declaration.

There is no need to pack records. On Alpha and IA64 the effect is to inhibit alignment and kill performance. In this case, the alignment costs a whole 2 bytes. Moving one field from the beginning to the end of the record would eliminate even that cost (and, besides, the additional code to deal with misaligned fields takes up a whole lot more than just 2 bytes!)

You need to care about alignment on Alpha, and even more so on IA64. In Pascal, compile your code with /LIST/SHOW=STRUCT, then SEARCH the LISting file for "Align" this will show any record fields that the compiler has identified as misaligned.

[John Reagan]

JohnG and I have exchanged some private email. While his observation that removing PACKED helps, using PACKED should never get the wrong answer. PACKED should only result in smaller data structures and probably additional code to access the poorly aligned data. Since the compiler knows the fields are poorly aligned, it should not generate code that gets alignment faults in case you asked yourself that question.

I've downloaded the .ZIP file and will look closer at it today based on some information that JohnG sent me.