Re: Vectorizing HIRLAM 4: complicated access patterns examined.

[Toon Moene <moene at knmi dot nl>]

> I just read your contribution to the 2005 gcc summit about gfortran
> and HIRLAM. The two PRs(18283 and 21034) you wrote about are now
> fixed. LOC is now available. That just leaves some of the extra
> functionality of FLUSH(IOSTAT?), does it not? Would it compile
> completely if I were to add that functionality?

I still have to construct a bug report of something that confuses the 
parser and that basically looks like this:

      IMPLICIT CHARACTER*8 (Y)
      CHARACTER*11 Y1, Y2, Y3
      ...
      YA = 'D' // Y1 // Y2(1:3) // Y3(1:3) //
     1     // YB(1:5)
           1
Unclassifiable statement at (1)

Unfortunately, if I reduce the code to this one (continued) line and the 
necessary declarations, it doesn't fail ;-)

All the other problems are with non-standard code (like flush, getarg, 
et al.), where I have to find standard-conforming solutions.  Note that 
I'm used to the fact that with almost all OS/compiler combinations we 
have to make a few local mods, because different compilers support 
different extensions (not surprising ...)

> Given the scale of your code, it would be a triumph worth reporting if
> we could get it up and running with gfortran.

Yep.  I'm convinced that by the time we hold the 2006 GCC summit I can 
not only compile all of HIRLAM, but present a running example and 
profiled runs, to direct optimizations.

Cheers,

--
Toon Moene, KNMI, The Netherlands
Phone: +31 30 2206443; e-mail: moene@knmi.nl