Dear Reinhold, I am glad that it was not just me being anxious about the issue!
For a day or two, I am somewhat distracted by loading up a new Lenovo workstation and installing a xeon phi on it. Given the current insane low price of the BC31S1P, I thought to see how best to allow gfortran to make use of the Knight's Corner vector processor. I will start with a vector class and associated methods. Combined with coarrays, it should be possible to get a reasonable performance out of the phi. After that, well we will see... Cheers Paul On 11 August 2015 at 13:17, Bader, Reinhold <reinhold.ba...@lrz.de> wrote: > Hello Paul, > > To my knowledge, the J3 interp F08/128 was triggered by a question coming > from Bill Long from Cray. > The interp's text was written by the Fortran standard's editor. So there is > no direct relation to this thread. > > F08/0142 (useless submodules) was in turn triggered by the example given for > F08/128, by Daniel Chen from IBM. > And indeed this seems to have caused some grief to other implementors. > > Cheers > Reinhold > >> -----Ursprüngliche Nachricht----- >> Von: Paul Richard Thomas [mailto:paul.richard.tho...@gmail.com] >> Gesendet: Dienstag, 11. August 2015 12:28 >> An: Bader, Reinhold <reinhold.ba...@lrz.de> >> Cc: Toon Moene <t...@moene.org>; Mikael Morin <mikael.mo...@sfr.fr>; >> Damian Rouson <dam...@sourceryinstitute.org>; fort...@gcc.gnu.org; gcc- >> patches <gcc-patches@gcc.gnu.org>; salvatore.filipp...@uniroma2.it >> Betreff: Re: [Bug fortran/52846] [F2008] Support submodules - part 3/3 >> >> Dear All, >> >> Has this been occasioned by this thread or have other makes encountered the >> same difficulty in implementation? >> >> Cheers >> >> Paul >> >> On 10 August 2015 at 20:57, Bader, Reinhold <reinhold.ba...@lrz.de> wrote: >> > Hello Toon, all else, >> > >> > a bit unfortunate, in my opinion (I was present at the discussion). >> > I've in the meantime taken some effort to implement what the design >> > pattern experts might call an "abstract factory with full dependency >> > inversion" as a bare-bones framework and have attached an archive with >> > three >> variants: >> > >> > * pre_interp contains the code that is presently valid (and indeed >> > compiles fine >> > with both gfortran and ifort), but would become invalid due to indirect >> > parent module access >> > * post_interp contains a variant that uses a helper module (mod_glue) to >> > avoid >> > the indirect ancestor use access (if there is a more concise way to do >> > this, >> > I'd like to know ... up to now this is the best I can do) >> > * post_interp_v2 another shorter variant that pushes the extension types >> > into >> a submodule >> > (with the disadvantage that these types are not really reusable, and >> > that the monster module problem is shifted to a monster submodule, or a >> chain of >> > submodules) >> > You may need to edit the Makefiles to build. >> > >> > I would of course like to know how people feel about reintroducing >> > this restriction, especially since the only reason given was that >> > ancestor module access and its use association overriding host >> > association would confuse users ... which is a problem which in my >> > opinion could have been dealt with in a slightly different manner >> > without removing the permission for indirect parent >> > module-referencing use statements. It is not clear to me whether >> *implementations* other than gfortran have problems with this, though. >> > >> > More germane to this thread's discussion actually is another interp >> > that was also passed, and which appears entirely uncontroversial: >> > http://j3-fortran.org/doc/meeting/207/15-209.txt >> > It seems to me that this would permit avoiding generation of the .smod >> > files for modules that do not specify an separate module procedure >> > interface. >> > >> > Cheers >> > Reinhold >> > >> >> -----Ursprüngliche Nachricht----- >> >> >> >> Although I do not immediately know if this is relevant for *this* >> >> debate, J3 passed the following (attached) interpretation on >> >> submodules the past week (it still has to go to several mail ballots, >> >> but still), overwhelmingly prefering option 3: >> >> >> >> [attached] >> >> >> >> Kind regards, >> >> >> >> -- >> >> Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 >> >> Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: >> >> http://moene.org/~toon/; weather: http://moene.org/~hirlam/ Progress >> >> of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news >> >> >> >> -- >> Outside of a dog, a book is a man's best friend. Inside of a dog it's too >> dark to >> read. >> >> Groucho Marx -- Outside of a dog, a book is a man's best friend. Inside of a dog it's too dark to read. Groucho Marx
