Fortran

[Kjell Carlsson]

Hi
I have a problem with Fortran ver. 7.5. Open VMS/Alpha ver. 7.3-1. Latest ECOs are installed.
The program uses mailbox qio for reading and iosb to receive completion status.
When a message is received iosb(1) is set to 1 when typed out. But when used in a logical expression it is .false. If I copy iosb(1) to an integer*4 and then type the integer*4 the result is 0.
Compilation is done with the following switches: /OLD_F77/SHOW=NOMAP/EXTE/ALIGNMENT=(COMMONS=(NATURAL,NOMULTILANGUAGE),RECORDS=NATURAL)/NOWARNING=(NOALIGN,USAGE) /CHECK=ALL
If I add the switch /NOOPTI the program works fine.
Does anyone have experience of this.

Best regards KjellC

[Ian Miller.]

whats the FORTRAN equivilent of the C type qualifier volatile which prevents a variable being stored in a register?

As the IOSB is being modified by VMS at KAST level then there may be this sort of of problem.

[Antoniov.]

Kjell,
I'd found problem like you using cobol so since some years I compile without optimier (always /NOOPT); same using C.

Bye
Antoniov

[Kjell Carlsson]

Thank you Ian

The syntax is equal in Fortran and C. I tried VOLATILE and it works!

Best regards Kjell

[Willem Grooters]

Kjell,

I0SB is a structure that is filled asynchronously (in respect to normal code stream and therefore it must be volatile. True for all this type of local storage....

[Hein van den Heuvel]

antoniov...

>Feb 9, 2004 13:52:57 GMT unassigned
>--------------------------------------------
>Kjell,
> I'd found problem like you using cobol so > since some years I compile without
> optimier (always /NOOPT); same using C.

We (hp employees :-) thank you for buying bigger, and more powerful machines then you might need.
But if this pushes the VMS solutions out of an acceptable price/performance target then we would really prefer you start compiling with optimizers turned to the max again.

Your end users will be grateful (after you verified your code in a test environment).

These days 10-out-of-10 so called optimizer bugs are straight programming errors. Please allow the compilers to do what they are good at: make your programs use the cpu optimally.
If in the process they highlight broken/sloppy code, then be grateful for that catch! It is just finding problems waiting to happen!

primo example... the code in this topic!

please reconsider,

Regards,
Hein (not really speaking for HP, just speaking my mind).

[Antoniov.]

Hello Hein,
what does mean 10-out-of-10?
About optimitier of compiler my experience was very bad.
In 1996 I buyed C and Cobol for OpenVMS V6.2; I had to porting my programs from vax platform to axp.
After I spend my money and my time using /OPT qualifier, I tryed without it and software becamed more stable. Since 1996 I never tryed to activate them.
I known my compiler are very old (Cobol is V2.1-253 and C is v5.xx) and sometimes I think it's the time to upgrade; but before this fantastic forum I wasn't find a stuff help (I hope it's understandable term) so I worked using read & try method and I've gone into defensive mode.

Yes, I'm reconsidering this; for example:
- I'm pushing my customer to migrate to V7.3 while one year ago I hint them to change platform!
- I'm reading every day the vms documentation and I'm restarting to try some recent software.
Hein, step by step I'll try also /OPT but I have to find old my documentation (of 1996); then I'll post question to this forum as I did about some other question.

Regards,
Antoniov

[John Gillings]

Antoniov,

>what does mean 10-out-of-10?

He means pretty much all reported optimizer problems are really problems in the user's own code. In my experience this are, I'd put the ratio at about 80:1 - that is for every real compiler bug I see, there are 80 reports that turn out to be the user's problem.

> After I spend my money and my time
>using /OPT qualifier, I tryed without it
>and software becamed more stable. Since >1996 I never tryed to activate them

I have to agree strongly with Hein. Compiler optimization is your friend!

If you have any program which behaves any differently with or without /OPT (except in terms of performance!) then it's almost certainly a result of a bug in your code.

You're much better off compiling and testing with /OPT and finding all your bugs than "papering over" them with /NOOPT. (Personally, I even use /DEBUG/OPT despite the compiler warning)

If you believe you have found any compiler bug (including optimizer bugs), please log a service case with your local CSC. The engineer will either find the bug in your code ;-), or submit the problem to engineering to be fixed.

We can't fix problems we don't know about!

[Willem Grooters]

For John and Hein:

There ARE some odd things in optimation to reckon with. For instance, as I found in a Pascal program, where the formal argument was defined as "packed array[len] of char", cheking out len to determine what data had been passed; processing depended od that size. With /NOOPT is was ok, with /OPT it failed....AFAIK this method is a valid (dirty) construction, the optimizer could not handle properly (in our view). The manuals didn't warn us on this!

[Antoniov.]

Hello John (and Hein),
thanks for your explain.
In my mind, before tracking a bug compiler, I check for my code and read all documentation I can; yes, I agree most report aren't compiler bugs (however compiler it's not God); I known perfectly the situation because I wrote my personal cobol++ precompiler (written in c).
About report of bug, here in Italy before HP, a little software house as mine was submitted as a man see a bug.

I'll report the bugs in next days, after I find most precise documentation. I tell you, still today, debugger doesn't work well: sometimes show a wrong listing of cobol source code.

Regards
Antoniov