[Search for users]
[Overall Top Noters]
[List of all Conferences]
[Download this site]
Title: | PL/I Notes |
|
Moderator: | PEROIT::LUCIA |
|
Created: | Sat Jan 25 1986 |
Last Modified: | Wed May 14 1997 |
Last Successful Update: | Fri Jun 06 1997 |
Number of topics: | 707 |
Total number of notes: | 2472 |
703.0. "UNREACH (again)" by CSC64::HENNING (A rose with no thorns) Tue Mar 11 1997 16:53
A customer states that, in some cases, the PLIG-I-UNREACH messages
generated by DEC PL/I for OpenVMS Alpha are totally bogus. He asserts
that the optimizer shouldn't return the UNREACH message if it cannot
guarantee the value of a variable that is evaluated in an IF-THEN-ELSE
sequence where both the IF and ELSE cases return() from the procedure.
My thought is that UNREACH is appropriate, if statements that follow
the IF-THEN-ELSE sequence won't be executed -- even if the only
statement that follows is an END statement.
I've attached his comments to the end of this message. Is he on
target? Should the UNREACH message cite the IF-THEN-ELSE or the END
statement? Should I IPMT this behavior? If not, can you explain the
reason for the behavior the customer describes?
Thanks,
Mary
------------------------------------------------------------------------
Customer comments:
Yes, I understand that the axp optimizer has more new "features" than
the vax optimizer. "propagation of values" and other sophisticated
optimization techniques can correctly produce the "code can never be
reached" message, and be fully compliant with the ANSI PLI language
spec.
But, this particular optimizer "feature" is what most folks call a
"bug". another example follows. this one shows that REGARDLESS OF THE
IF TEST VALUE, THE COMPILER ISSUES THE MESSAGE, "code can never be
reached". this is NOT what the compiler is supposed to do. we have
all kinds of code that computes or receives some sort of switch value.
that value determines the return value in an IF or SELECT statement.
there is NO WAY that the optimizer can be CORRECTLY determining that
"code can never be reached". the message and compiler behavior is just
plain wrong.
$ TYPE TEST.PLI
tmp:procedure (switch) returns(fixed) ;
dcl switch fixed ;
if switch = 0 then return(0); else return(1);
end tmp;
$ PLI TEST
if switch = 0 then return(0); else return(1);
^
%PLIG-I-UNREACH, code can never be executed at label
at line number 3 in file USER1:[HENNING]TEST.PLI;4
%PLIG-I-SUMMARY, Completed with 0 errors, 0 warnings, and
1 informational messages.
T.R | Title | User | Personal Name | Date | Lines |
---|
703.1 | | SPECXN::DERAMO | Dan D'Eramo | Wed Mar 12 1997 11:33 | 5 |
| I'm sure it has been reported before, but it should be okay to
ipmt it to Uniprise again if it still happens in V4.1. Level
<s3> as they can use /WARN=NOINFO to suppress it.
Dan
|