In article <fvq52g$6j...@aioe.org>, Bil Kleb <Bil.K...@NASA.gov> wrote:
>Hi,
>This request just went out to our team:
> itemize what we would want out of a compiler-writer visit
>I can only think of two related questions: ... >Other ideas?
What areas of the F2003 standard are causing you the most pain to implement?
When do you think you'll be able to release a full f2003 compiler?
What areas of the F2008 standard do you think will cause you the most pain to implement?
When do you think you'll be able to release a full f2008 compiler?
-- John Harper, School of Mathematics, Statistics and Computer Science, Victoria University, PO Box 600, Wellington 6140, New Zealand e-mail john.har...@vuw.ac.nz phone (+64)(4)463 6780 fax (+64)(4)463 5045
On May 6, 1:38 pm, Bil Kleb <Bil.K...@NASA.gov> wrote:
> Hi,
> This request just went out to our team:
> itemize what we would want out of a compiler-writer visit
> I can only think of two related questions:
> What areas of the F95 cause the most pain w.r.t. optimization?
Same for F2003. I think allocation upon assignment is one "painful" area, as discussed here recently.
> What can we do as code developers to "help" the compiler?
> Other ideas?
When will you have a Fortran 2003 compiler?
If a compiler offers free updates for the next N months, will they have a Fortran 2003 compiler in N months?
What is your timeline on adding specific features? If g95 has a Fortran 2003 feature, I'll be more likely to employ it if Intel Fortran has it now or will have it in a few months.
> itemize what we would want out of a compiler-writer visit
> I can only think of two related questions:
> What areas of the F95 cause the most pain w.r.t. optimization?
> What can we do as code developers to "help" the compiler? > <snip>
Others have suggested asking about F2003. I would suggest asking about detecting more fundamental problems with the source code, i.e., illegal modifiable aliasing, array out of bound checks, memory leaks, etc. For optimization/memory management you might ask about stack versus heap alloction.
On 2008-05-06, Bil Kleb <Bil.K...@NASA.gov> wrote:
> What can we do as code developers to "help" the compiler?
If you think something is broken, submit bug reports through the appropriate channels, with self-contained, preferably small test cases. Indicate what you expected of the compiler, and what happened instead.
If the compiler in question happens to be a "bazaar" - style open-source project, you can also volunteer to fix bugs :-)
Thomas Koenig wrote: > On 2008-05-06, Bil Kleb <Bil.K...@NASA.gov> wrote:
>> What can we do as code developers to "help" the compiler?
> If you think something is broken, submit bug reports through > the appropriate channels, [..]
I feel you've taken this second, related question out of context with the first:
What areas of the F95 cause the most pain w.r.t. optimization?
I meant "help" in terms of what coding conventions (e.g., using INTENT, using TARGET, unrolling array syntax, unrolling derived types in calling arguments, and so forth) should we, as code writers, adopt to "help" the compiler more easily produce optimized code.
In article <slrng23vs0.46r.tkoe...@meiner.onlinehome.de>, Thomas Koenig <tkoe...@netcologne.de> wrote:
>If you think something is broken, submit bug reports through >the appropriate channels, with self-contained, preferably small >test cases.
In many cases, a self-contained small test case is not necessary, and generating the self-contained small test case can take a long time. Telling users that you prefer one can cause many bugs to go unreported.
You can look in the PathScale manuals for some text suggesting bug types for which finding a small example isn't worth the end-users effort.
>If the compiler in question happens to be a "bazaar" - style >open-source project, you can also volunteer to fix bugs :-)
I've submitted patches to "cathedral" style open source projects, and they were used.
> In article <fvq52g$6j...@aioe.org>, Bil Kleb <Bil.K...@NASA.gov> wrote:
> >Hi,
> >This request just went out to our team:
> > itemize what we would want out of a compiler-writer visit
> >I can only think of two related questions: > ... > >Other ideas?
> What areas of the F2003 standard are causing you the most pain to > implement?
> When do you think you'll be able to release a full f2003 compiler?
> What areas of the F2008 standard do you think will cause you the most > pain to implement?
> When do you think you'll be able to release a full f2008 compiler?
> -- John Harper, School of Mathematics, Statistics and Computer Science, > Victoria University, PO Box 600, Wellington 6140, New Zealand > e-mail john.har...@vuw.ac.nz phone (+64)(4)463 6780 fax (+64)(4)463 5045
All these questions are interesting (especially the release of F2003 and F2008 compilers) but I would prefer the answers :-(
> What areas of the F95 cause the most pain w.r.t. optimization?
> What can we do as code developers to "help" the compiler?
Don't write illegal code probably is the most important thing to do to "help" the optimizer. One very common error is procedure calls like "proc(a, a)", where both dummy arguments can alter its value. This screws up optimizer in aliasing. Another common problem is common block declaration mismatch in different scoping units because they may end up with different alignments. Many other small things like try to avoid equivalence. One piece of suggestion you may hear from the optimizer is, don't try to optimize your code by yourself, let the optimizer do its job :-)
