When one attempts to compile the subroutine given below with PGI
"pgf90" version 5.1 (Linux/x86), it generates error messages:

     Lowering Error: visit symbol entry1(529) which was replaced by
      entries(528)
     Lowering Error: visit symbol entry2(530) which was replaced by
      entries(528)
     PGF90-F-0000-Internal compiler error. Errors in Lowering       2
     (entries.f: 19)
      PGF90/any Linux/x86 5.1-3: compilation aborted

Has this been fixed in later editions of "pgf90" (to which I do
not presently have access) ?

Thanks --

Carlie J. Coats, Jr.                        carlie.coats@baronams.com
Environmental Modeling Center               carlie_coats@ncsu.edu
Baron Advanced Meteorological Systems, LLC
---------------------------------------------------------------------
         REAL FUNCTION ENTRIES
             IMPLICIT NONE
             REAL     ENTRY1, ENTRY2
             ENTRIES = 0.0
         RETURN

         ENTRY ENTRY1
             ENTRY1 = 1.0
             RETURN

         ENTRY ENTRY2
             ENTRY2 = 2.0
             RETURN

         CONTAINS

             SUBROUTINE  FOO
                 WRITE( *,*) 'Phooey!'
                 RETURN
             END SUBROUTINE  FOO

         END

Can't answer your question, but I threw your example at g95 and Salford 
ftn95. Both complain. g95:
In file entries.f90:1

         REAL FUNCTION ENTRIES
                     1
Error: Syntax error in data declaration at (1)
In file entries.f90:7

         ENTRY ENTRY1
                    1
Error: ENTRY statement at (1) cannot appear within a PROGRAM
In file entries.f90:11

         ENTRY ENTRY2
                    1
Error: ENTRY statement at (1) cannot appear within a PROGRAM

ftn95:
ERROR C:\PVE5\fortran\work\entries.F90 1:  'E' found after FUNCTION 
where a comma was expected
ERROR C:\PVE5\fortran\work\entries.F90 2:  Statement ordering error - 
IMPLICIT NONE cannot appear after type definition statements
ERROR C:\PVE5\fortran\work\entries.F90 5:  RETURN cannot be inside a 
PROGRAM block
ERROR C:\PVE5\fortran\work\entries.F90 7:  ENTRY cannot appear inside a 
main program block
ERROR C:\PVE5\fortran\work\entries.F90 7:  Compilation abandoned

Writing ENTRIES() fixes the problem, although neither compiler insists 
on a blank argument list for ENTRY1 or ENTRY2.
In message <EK1Ye.12244$%i1.6620@trnddc09>, Carlie J. Coats 
<carlie@jyarborough.com> writes
>When one attempts to compile the subroutine given below with PGI
>"pgf90" version 5.1 (Linux/x86), it generates error messages:
>
>    Lowering Error: visit symbol entry1(529) which was replaced by
>     entries(528)
>    Lowering Error: visit symbol entry2(530) which was replaced by
>     entries(528)
>    PGF90-F-0000-Internal compiler error. Errors in Lowering       2
>    (entries.f: 19)
>     PGF90/any Linux/x86 5.1-3: compilation aborted
>
>Has this been fixed in later editions of "pgf90" (to which I do
>not presently have access) ?
>
>Thanks --
>
>Carlie J. Coats, Jr.                        carlie.coats@baronams.com
>Environmental Modeling Center               carlie_coats@ncsu.edu
>Baron Advanced Meteorological Systems, LLC
>---------------------------------------------------------------------
>        REAL FUNCTION ENTRIES
>            IMPLICIT NONE
>            REAL     ENTRY1, ENTRY2
>            ENTRIES = 0.0
>        RETURN
>
>        ENTRY ENTRY1
>            ENTRY1 = 1.0
>            RETURN
>
>        ENTRY ENTRY2
>            ENTRY2 = 2.0
>            RETURN
>
>        CONTAINS
>
>            SUBROUTINE  FOO
>                WRITE( *,*) 'Phooey!'
>                RETURN
>            END SUBROUTINE  FOO
>
>        END
>

-- 
John Mansell  john at wcompsys dot co dot uk

Carlie J. Coats wrote:
> When one attempts to compile the subroutine given below with PGI
> "pgf90" version 5.1 (Linux/x86), it generates error messages:
> 
>     Lowering Error: visit symbol entry1(529) which was replaced by
>      entries(528)
>     Lowering Error: visit symbol entry2(530) which was replaced by
>      entries(528)
>     PGF90-F-0000-Internal compiler error. Errors in Lowering       2
>     (entries.f: 19)
>      PGF90/any Linux/x86 5.1-3: compilation aborted
> 
> Has this been fixed in later editions of "pgf90" (to which I do
> not presently have access) ?

Apart from any errors in your code....

I skipped v5.1 altogether and went to v5.2. Colleagues of mine had problems when one machine (which 
had v5.1-2) compiled and ran code (mostly) correctly, but when the same code was compiled and run on 
a different machine (which had v5.1-3), it no longer ran (due to a compiler bug that caused a 
spurious run-time error). When you do get access to v5.2, make sure it's release 4, i.e. v5.2-4. Or 
better yet, go for v6.0 which finally fixed some lingering (albeit minor) bugs ... although it 
introduced some new annoyances (I have v6.0-5).

cheers,

paulv

-- 
Paul van Delst
CIMSS @ NOAA/NCEP/EMC

In article <toaIJzMyURMDJAph@raspberries.net>,
 John Mansell <j.mansell@raspberries.net> wrote:

> Can't answer your question, but I threw your example at g95 and Salford 
> ftn95. Both complain. g95:
> In file entries.f90:1
> 
>          REAL FUNCTION ENTRIES

Probably because the parens required by the standard are missing. You 
need them for a function statement, even if there are no arguments. (A 
subroutine statement is different in this regard).

The other errors are consequences of this one. If the compiler hasn't 
figured out that it is in a function subprogram, things fall apart.

-- 
Richard Maine                       |  Good judgment comes from experience;
email: my first.last at org.domain  |  experience comes from bad judgment.
org: nasa, domain: gov              |        -- Mark Twain

Richard E Maine wrote:
> In article <toaIJzMyURMDJAph@raspberries.net>,
>  John Mansell <j.mansell@raspberries.net> wrote:
> 
> 
>>Can't answer your question, but I threw your example at g95 and Salford 
>>ftn95. Both complain. g95:
>>In file entries.f90:1
>>
>>         REAL FUNCTION ENTRIES
> 
> 
> Probably because the parens required by the standard are missing. You 
> need them for a function statement, even if there are no arguments. (A 
> subroutine statement is different in this regard).
> 
> The other errors are consequences of this one. If the compiler hasn't 
> figured out that it is in a function subprogram, things fall apart.

Unfortunately, no, it is not just a missing-arglist-parens bug.
A quick check proves that.

And the original (*much* more complex) case from which this was
abstracted had a 6-arg arg-list, enclosed of course in parentheses.

The good news is that they seem to have fixed the problem in v6

-- 

Carlie J. Coats, Jr.                        carlie.coats@baronams.com
Environmental Modeling Center               carlie_coats@ncsu.edu
c/o North Carolina State University                   MEAS Department
1125 Jordan Hall                                      Campus Box 8208
Raleigh, NC 27695           phone: (919)515-7076 / fax: (919)515-7802
"My opinions are my own, and I've got *lots* of them!"