<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi all!<br>
<br>
<div class="moz-cite-prefix">Bill Long wrote:y<br>
</div>
<blockquote cite="mid:5B1BDAEA-6AE6-4A1F-977A-CC76BA04B358@cray.com"
type="cite">
<pre wrap="">On Feb 5, 2014, at 12:26 PM, Craig Rasmussen <a class="moz-txt-link-rfc2396E" href="mailto:rasmus@cas.uoregon.edu"><rasmus@cas.uoregon.edu></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Surprisingly, the latest gfortran supports type(*) and dimension(..) partially, as in it will act like IGNORE_TKR (I think) but actually doesn't pass the new C descriptors yet.
</pre>
</blockquote>
<pre wrap="">
Right. I’ve been using gfortran 4.9 for some time to compile mpi_f08 and associated modules. But not execute. The Cray compiler does support the C descriptors, but gfortran is not quite there yet. I think the gfortran plan is to switch all of their dope vectors to the C descriptor format, which is a much bigger change.
</pre>
</blockquote>
<br>
GCC/gfortran 4.9 is currently in stage 3 - regression fixes only.
Judging from the last years, the release will be end of March to
April (up to beginning of May). My bet would be mid of April -
giving some larger last-minute changes.<br>
<br>
Background regarding gfortran: The reason for the switch for the
dope vector is an unfortunate choice in the early history of
gfortran. It stores the stride as multiples of the element size
instead of using byte-based stride multipliers and it stores the
upper bound instead of the extend. I think both are incompatible
with the TS (or at least with some earlier draft of the TS).<br>
<br>
Side note: using a stride instead of a stride multiplier also causes
some problems with valid Fortran 90's array(::s)%comp data access
and the current descriptor also only permits for 8 dimensions
(0...7) - thus the change is unavoidable. And when doing a switch,
one can also base it on the TS descriptor.<br>
<br>
About 70% of the conversion is already done on a branch
(unfortunately, no progress has been made for several months). Main
remaining task is to ensure that the C descriptor has a lower bound
of 0 (for nonallocatable/pointer arrays) and - even worse - to
ensure that the stride-multiplier works well (i.e. converting all
accesses while trying to avoid unnecessary regressions with regards
to vectorization). Unfortunately, touching one part requires changes
throught the code. Let's see whether the conversion can be completed
this year (for GCC 4.10).<br>
<br>
Tobias<br>
</body>
</html>