[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference turris::pli

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.RTitleUserPersonal
Name
DateLines
703.1SPECXN::DERAMODan D'EramoWed Mar 12 1997 11:335
        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