Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!samsung!spool2.mu.edu!uwm.edu!bionet!agate!ucbvax!BRL.MIL!glennrp
From: glennrp@BRL.MIL (Glenn Randers-Pehrson, TBD|WMB)
Newsgroups: comp.sys.sgi
Subject: more IRIX 3.3.1 f77 -O2 bugs
Message-ID: <9101141152.aa05375@TBD2.BRL.MIL>
Date: 14 Jan 91 16:52:55 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: U.S. Army Ballistic Research Laboratory, APG, MD
Lines: 41


I have encountered several more bugs with the IRIX 3.3.1 f77 compiler
when used with -O2.  These are worse than the one I reported last week,
in that the compiler silently produces bogus code, instead of the core
dump.  I'll provide sources to anyone who is interested.

One class of statements causing problems involves the INQUIRE statement,
where the same logical variable appears in several INQUIRE statements,
as "isopen" in
        inquire(8,opened=isopen)
        if(isopen)....
        inquire(9,opened=isopen)
        if(isopen)...
The optimizer apparently does not recognize that the INQUIRE statement
assigns a new value to "isopen".

Another seems to involve an assumption by the programmer about storage
association, that the optimizer apparently did not recognize:

        subroutine sub(array))
        dimension array(6)
        common /a/ j,r(5)
        do 10 i=1,6
   10   r(i-1)=array(i)

The loop is supposed to copy the contents of the first element of "array"
into "j", without doing a float-to-integer conversion.  In the code, "j"
does get properly defined, but the optimizer gets goofed up later on in
the program, with entirely different variables.  When I rewrote this coding
to be a little more explicit, but still horrible to look at, then the problem
went away.

        subroutine sub(array))
        dimension array(6)
        common /a/ j,r(5)
        equivalence (rj,j)
        rj=array(1)
        do 10 i=2,5
   10   r(i-1)=array(i)

...Glenn Randers-Pehrson <glennrp@brl.mil>