For those who need/use Cray pointers, support has been 
committed to the gfortran source code and it will be
available when gcc 4.1.0 is released.  The code was
developed by Asher Langton at LLNL.  This was the 
second most requested feature for g77 (full F90 support
is/was #1).  Asher also submitted several small programs
for the gfortran testsuite that suggest that Cray pointer
support is implemented correctly, but as always, bugs could
be lurking.  If you try the compiler and find a bug (or
think you've found a bug), please submit a report to 
GCC's bugzilla or to fortran at gcc dot gnu dot org.

If you are a daring soul, you can download the GCC source
code for 4.1.0 and compile a version of gfortran for testing.
If you grab binaries from the gfortran wiki, then you'll 
want binaries created from sources newer than 24 Oct 05.

PS:  A morsel to chew on.  OpenMP support is under
development and I believe targeted for GCC 4.2.

-- 
Steve
http://troutmask.apl.washington.edu/~kargl/

Steven G. Kargl wrote:
> If you try the compiler and find a bug (or
> think you've found a bug), please submit a report to 
> GCC's bugzilla or to fortran at gcc dot gnu dot org.

Hi Steven,

This is probably a silly question, but what constitutes a bug? By that I mean, how does 
one differentiate between an unimplemented feature and a bug? E.g. I'm getting compiler 
errors like so:

   END INTERFACE OPERATOR (.EqualTo.)
                                    1
Error: Expecting 'END INTERFACE OPERATOR (.compare_float.)' at (1)

The same code compiles with <<insert any compiler name here>> so I'm assuming it's an 
unimplemented feature, but it used to be that gfortran actually said that when it came 
across something it didn't grok.

cheers,

paulv

p.s. Thanks for the download info/confirmation in my other post.

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

Paul Van Delst <Paul.vanDelst@noaa.gov> wrote:

>    END INTERFACE OPERATOR (.EqualTo.)
>                                     1
> Error: Expecting 'END INTERFACE OPERATOR (.compare_float.)' at (1)
> 
> The same code compiles with <<insert any compiler name here>> so I'm
> assuming it's an unimplemented feature,

I'd be a lot more interested in seeing the code than in making
judgements based on what other compilers happened to do. Is the
compiler justified in its complaint? If the interface block in question
started with a reference to .compare_float., then it sure can't end with
a reference to .EqualTo., and it would be a bug for the other compiler
to accept it. I've never heard of any "feature" even vaguely like "let
the end interface say something completely different from what it ought
to." (The closest approximation is that I think things like == count as
matching things like .eq.; I'd have to check to be sure, but I think
that's allowed).

If the .compare_float. is just something that gfortran dreamed up from
its own innards, or perhaps if matching of the beggining and end of
interfaces has gotten messed up, that's a different matter.

-- 
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

In article <djm9bd$ep3$1@news.nems.noaa.gov>,
	Paul Van Delst <Paul.vanDelst@noaa.gov> writes:
> Steven G. Kargl wrote:
>> If you try the compiler and find a bug (or
>> think you've found a bug), please submit a report to 
>> GCC's bugzilla or to fortran at gcc dot gnu dot org.
> 
> This is probably a silly question, but what constitutes a bug?

The only silly question is the question that is never asked. :-)

> By that I mean, how does one differentiate between an unimplemented
> feature and a bug?

If it's in the Standard and gfortran does not properly handle the
feature, it's a bug.  If you get a GFC_TODO message, this indicates
the feature isn't implemented yet and we know about the problem
(ie., to me this isn't a bug just a really big annoyance :(  ).   

> E.g. I'm getting compiler errors like so:
> 
>    END INTERFACE OPERATOR (.EqualTo.)
>                                     1
> Error: Expecting 'END INTERFACE OPERATOR (.compare_float.)' at (1)
> 
> The same code compiles with <<insert any compiler name here>> so
> I'm assuming it's an unimplemented feature, but it used to be that
> gfortran actually said that when it came across something it didn't
> grok.

Ugh!  It's worst than you think.  gfortran (and g95) have a hand
written scanner/parser.  If is runs into a possible problem, the
scanner/parser tries to back up and perhaps take an alternate
path.  Unfortunately, this sometimes confuses the error recovery
code particular when an END XXX goes AWOL.  Then we get a cascade
of error messages.  (I haven't used g95 in a long time.  I'm 
guessing Andy has fixed this problem.)  Based on the error message
above, I'm guessing you have

interface operator (.compare_float.)
   yada1
   yada2
end interface operator (.compare_float.)

interface operator (.equalto.)
   yada3
   yada4
end interface operator (.equalto.)

gfortran thinks there's a problem near yada2, the scanner does not back
up properly and in so doing the "end interface operator (.compare_float.)"
gets eaten.

I haven't seen a bug report with this type of error message, so
I would call this a bug of some sort.  If your code isn't proprietary,
you can send a quick email to fortran@gcc.  Hopefully, you can reduce
it to a short code, if not some of us on the mailing list will do it.

-- 
Steve
http://troutmask.apl.washington.edu/~kargl/

In article <1h4zt30.l6zgaz1kyx12zN%nospam@see.signature>,
	nospam@see.signature (Richard E Maine) writes:
> Paul Van Delst <Paul.vanDelst@noaa.gov> wrote:
> 
>>    END INTERFACE OPERATOR (.EqualTo.)
>>                                     1
>> Error: Expecting 'END INTERFACE OPERATOR (.compare_float.)' at (1)
>> 
>> The same code compiles with <<insert any compiler name here>> so I'm
>> assuming it's an unimplemented feature,
> 

(snip)

> If the .compare_float. is just something that gfortran dreamed up from
> its own innards, or perhaps if matching of the beggining and end of
> interfaces has gotten messed up, that's a different matter.

Without seeing the code, I suspect this is the case.  I finally
got David Bailey's mpfun90 module to compile.  During my hacking,
I found that sometimes an "END XXX" statement would go AWOL, and
then gfortran's error recovery code would get confused.

-- 
Steve
http://troutmask.apl.washington.edu/~kargl/

Steven G. Kargl wrote:

> Ugh!  It's worst than you think.  gfortran (and g95) have a hand
> written scanner/parser.  If is runs into a possible problem, the
> scanner/parser tries to back up and perhaps take an alternate
> path.  Unfortunately, this sometimes confuses the error recovery
> code particular when an END XXX goes AWOL.  Then we get a cascade
> of error messages.  (I haven't used g95 in a long time.  I'm 
> guessing Andy has fixed this problem.)  Based on the error message
> above, I'm guessing you have
> 
> interface operator (.compare_float.)
>    yada1
>    yada2
> end interface operator (.compare_float.)
> 
> interface operator (.equalto.)
>    yada3
>    yada4
> end interface operator (.equalto.)

The actual code snippet is

   PUBLIC :: Compare_Float
   PUBLIC :: OPERATOR (.EqualTo.)
   PUBLIC :: OPERATOR (.GreaterThan.)
   PUBLIC :: OPERATOR (.LessThan.)

   INTERFACE Compare_Float
     MODULE PROCEDURE Compare_Float_Single
     MODULE PROCEDURE Compare_Float_Double
   END INTERFACE Compare_Float

   INTERFACE OPERATOR (.EqualTo.)
     MODULE PROCEDURE Is_Equal_To_Single
     MODULE PROCEDURE Is_Equal_To_Double
   END INTERFACE OPERATOR (.EqualTo.)

etc... for (.GreaterThan.) and (.LessThan.) operators

"Compare_Float" is just a regular old function, but the others are operators I use like so
   IF ( x .EqualTo. y ) THEN
     ....
   END IF

I don't know where the reference to ".compare_float." (i.e. prefixed and suffixed with the 
period symbols "."'s) comes from. Certainly not from the source code.

> gfortran thinks there's a problem near yada2, the scanner does not back
> up properly and in so doing the "end interface operator (.compare_float.)"
> gets eaten.
> 
> I haven't seen a bug report with this type of error message, so
> I would call this a bug of some sort.  If your code isn't proprietary,
> you can send a quick email to fortran@gcc.  Hopefully, you can reduce
> it to a short code, if not some of us on the mailing list will do it.

I will send it in. The code is pretty small to start with (mostly documentation).

cheers,

paulv

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