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

[Antoniov.]

Hello,
I notice a debugger limitation (not a bug); I can't set a breakpoint after a loop. See follow code (Cobol):
MyCode.
move 1 to I;
perform until (I > 10)
add 1 to I;
end-perform. <-- Try set BP after here!
Same in c code:
void MyFunction ()
{
int I;
while (I <= 10)
{
I++;
} <-- Try set BP after here!
}

There is a way to set any breakpoint after loop exit?

Bye
Antoniov

[Martin P.J. Zinser]

Hello Antonio,

even as a non-hp employee I strongly agree with Hein and John ;-) Compiling /noopt or even worse /stand=vaxc just asks for more trouble later on. Try to get a "Clean" compile (i.e. not warnings and informationals!) and you will be much happier if you do have to revisit, develop the code later on.

Greetings, Martin

[John Gillings]

Antoniov,

Debugging optimized code can be difficult. First point - on Alpha (or indeed ANY RISC processor), it's pretty much impossible to have NO optimization at all.

Each line of code generates a (potentially large) number of instructions. RISC processors MUST "interleave" instructions from various lines of code, to keep the instruction pipeline full, or performance is woeful. So /NOOPTIMIZE is really just the minimum level possible.

The dilemma for the DEBUG developers is -do we tag each individual instruction as the "real" line of code that it comes from and put up with "STEP" bouncing all over the code as each instruction is executed, or do we try to keep instructions in logical groups and give the programmer a less jumpy path? This is particularly evident in COBOL programs because each line typically generates a lot of instructions, and most lines are highly "dispersable". This is one reason compilers recommend /NOOPTIMIZE when compiling with /DEBUG - because it's easier to get a reasonably consistent correlation between the execution stream and the source.

It's just a matter of getting used to different ways of debugging code. When debugging code compiled /OPTIMIZE, it sometimes helps to look at the actual instruction stream, though on Alpha this can be fairly daunting (and just wait 'till you see IA64, yikes!).

To your specific question about break points. There are source code constructs that don't generate any code at all, with or without /OPTIMIZE. The COBOL END-PERFORM is one example. If you attempt to set a break point at that line, DEBUG issues a message, giving the previous and next executable lines. For example:

DBG> SET BREAK %LINE 12
DEBUG-E-LINEINFO, no line 12, previous line is 10, next line is 14

So, if you want the break inside the loop, choose the previous line. If you want it outside the loop, choose the next line. The same applies to lines containing end of block "}" in C, and other equivalent constructs, or any other non-executable source lines (such as comments), in any language.

[Antoniov.]

Hello John,
as you known I don't use /OPT so /DEBUG is already /NOOPT.
I hope somebody can help as set a breakpoint at the xit of a loop; I known I can set a BP on next line of loop but if loop hasn't any line after it's not possible intercept; I tryed writing a statement CONTINUE that's a No Operation statement but compiler remove line.
Next week I'll enable /OPT for C and Cobol.

Regards
Antoniov

[John Gillings]

Antoniov,

> hope somebody can help as set a breakpoint at the xit of a loop; I known I can set a BP on next line of loop but if loop hasn't any line after it's not possible intercept;

In COBOL "end-perform" cannot be the last line in the program, so there must be *A* following line, even if it's (apparently) a long way away.

If this doesn't answer your question, please start a new thread with a *complete* example program.