Ok, classify this one as "fun"

Q: When is an array not an array? A: When it is a Fortran90 allocatable array, and you are pulling out your remaining (&^&$#% hair trying to pass it to a C routine.

Ok, I have found some hope, appealing to some F2003 bits which this compiler supports. But still … the most likely scenarios is that I have to create an array of pointers to get to the data … which means that we are likely to have some memory performance hit. This is in conjunction with a Cuda port we are proof-of-concepting for a customer. I wish that nVidia would make Cuda friendly with Fortran as well as C/C++ … much scientific computing is still done in Fortran, and this isn’t legacy bits … this is active development and expansion. Yeah, Portland Group will have a compiler pragma set for Fortran which will enable code to be run on the accelerator. This is IMO the right direction (and curiously quite similar to something we had in a business plan 4 years ago when trying to raise capital for an accelerator company). But it will still require work to be made to work. Until then we are generally (stuck with) using C/C++ based accelerators, and needing some cross language love. Creating arrays of pointers (or having to create these in inner loops) is a really good way to kill performance. And no, rewriting the code just to use the accelerator is the wrong approach. We know, the customers we spoke to about this over the years were all aligned on this. No one is going to recode all of their app just to use an accelerator. They will use the accelerator if the cost is low … in hardware, software, and porting effort (e.g. focus on the time expensive areas).