Home > Archive > Fortran > April 2005 > ifort switches for mod files and line-number output
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
ifort switches for mod files and line-number output
|
|
| Phony Account 2005-04-22, 8:57 am |
| Hi,
I am running the latest ifort on windows, and from the output of the
ifort -help could not find switches to:
- generate a mod file
- enable the executable to print line-numbers of a the program when it
crashes.
I could not find a complete description of the ifort command in the pdf
documentation that I got.
Thanks,
Mirko
| |
| Jan Vorbrüggen 2005-04-22, 8:57 am |
| > - generate a mod file
In every compiler I know, this is done automatically whenever a MODULE
statement is encountered - just as the corresponding module file is read
whenever a USE statement is encountered. I can't really think of an
alternative implementation.
Now, what that module file is named, where it is stored, and where the
compiler searches for them when it sees a USE, that can be different, and
in particular the Intel compiler had a somewhat exotic, hard-to-use way
of doing it. AIUI, it nowadays does the "obvious" thing as most other
compilers do.
> - enable the executable to print line-numbers of a the program when it
> crashes.
That's a function of the RTL in conjuction with debugging information stored
in the object files and executables. I believe nowadays the Intel compiler
does this automatically unless you strip the executable of all symbols,
showing its DEC heritage. Why don't you generate an exception on purpose in
a little test program and see what happens?
Jan
| |
| Steve Lionel 2005-04-22, 3:59 pm |
| On Fri, 22 Apr 2005 11:05:48 GMT, Phony Account <phaccount@nycap.rr.com>
wrote:
>I am running the latest ifort on windows, and from the output of the
>ifort -help could not find switches to:
>
>- generate a mod file
There is no switch for that - it happens automatically when you compile a
module source
>- enable the executable to print line-numbers of a the program when it
>crashes.
/traceback
>I could not find a complete description of the ifort command in the pdf
>documentation that I got.
There is complete documentation of the command options provided in the Command
Options Quick Reference and the User's Guide. To view the documentation
index, select Start,,Programs..Intel Software Development Tools..Intel Fortran
Compiler 8.1..Documentation Index
For more help with Intel Fortran, please visit our user forum or contact Intel
Premier Support (links below).
Steve Lionel
Software Products Division
Intel Corporation
Nashua, NH
User communities for Intel Software Development Products
http://softwareforums.intel.com/
Intel Fortran Support
http://developer.intel.com/software/products/support/
| |
| Phony Account 2005-04-25, 8:58 am |
| Steve Lionel wrote:
> On Fri, 22 Apr 2005 11:05:48 GMT, Phony Account <phaccount@nycap.rr.com>
> wrote:
>
>
>
>
> There is no switch for that - it happens automatically when you compile a
> module source
>
>
My reason for asking was the make-file and compilation script at the
back of the "f95/03 explained" book. I am still getting used to the
compilation cycle. For my little app, I often have to run make twice,
once even three times :-).
I think that I will try to implement their little script that stores the
mod file into a temp directory, checks whether the .mod file has
actually changed, and only if it did, bring it into the "active"
directory (where all the source,obj,exe files are).
>
>
> /traceback
>
>
>
Thanks. It is obvious now that I read its description.
>
> There is complete documentation of the command options provided in the Command
> Options Quick Reference and the User's Guide. To view the documentation
> index, select Start,,Programs..Intel Software Development Tools..Intel Fortran
> Compiler 8.1..Documentation Index
>
I'll check into it.
> For more help with Intel Fortran, please visit our user forum or contact Intel
> Premier Support (links below).
>
I will try it out, but I must admit, this forum's response is fast, and
that is one big appeal to post here.
>
> Steve Lionel
> Software Products Division
> Intel Corporation
> Nashua, NH
>
> User communities for Intel Software Development Products
> http://softwareforums.intel.com/
> Intel Fortran Support
> http://developer.intel.com/software/products/support/
Thank you.
| |
| Richard Edgar 2005-04-25, 3:59 pm |
| Phony Account wrote:
> My reason for asking was the make-file and compilation script at the
> back of the "f95/03 explained" book. I am still getting used to the
> compilation cycle. For my little app, I often have to run make twice,
> once even three times :-).
If you have to run make more than once to produce a target, then there's
something wrong with your makefile. The 'compilation cascade' should
only be cause for a coffee break, not multiple runs of make.
Richard
| |
| Steve Lionel 2005-04-25, 3:59 pm |
| On Mon, 25 Apr 2005 11:13:38 GMT, Phony Account <phaccount@nycap.rr.com>
wrote:
>I will try it out, but I must admit, this forum's response is fast, and
>that is one big appeal to post here.
Well, we can fix that.... :-) Vendor-specific questions really should be
addressed through vendor channels. For Intel Fortran, we have an active user
forum, plus the official support channel of Intel Premier Support.
Steve Lionel
Software Products Division
Intel Corporation
Nashua, NH
User communities for Intel Software Development Products
http://softwareforums.intel.com/
Intel Fortran Support
http://developer.intel.com/software/products/support/
| |
| Phony Account 2005-04-26, 4:01 am |
| Richard Edgar wrote:
> Phony Account wrote:
>
>
>
> If you have to run make more than once to produce a target, then there's
> something wrong with your makefile. The 'compilation cascade' should
> only be cause for a coffee break, not multiple runs of make.
>
> Richard
See, I am used to the LaTeX compile cycle, where one usually does have
to do multiple compiles in order for all the cross-referencing to be
correct.
(If you have no idea what I am referring to just disregard it :-)
Anyway, I found a write-up on a dept of theoretical chemistry at the
university of west. australia that also discusses how to deal with mod
files, and avoid the compilation cascade. Seems to work for now,
although I have not used it extensively.
Mirko
| |
| Phony Account 2005-04-26, 4:01 am |
| Steve Lionel wrote:
> On Mon, 25 Apr 2005 11:13:38 GMT, Phony Account <phaccount@nycap.rr.com>
> wrote:
>
>
>
>
> Well, we can fix that.... :-) Vendor-specific questions really should be
> addressed through vendor channels. For Intel Fortran, we have an active user
> forum, plus the official support channel of Intel Premier Support.
>
>
> Steve Lionel
> Software Products Division
> Intel Corporation
> Nashua, NH
Thanks Steve. I will pay more attention to the intel forums. My ahem,
bias, stems from experiences with some other, to remain un-named,
software vendor.
>
> User communities for Intel Software Development Products
> http://softwareforums.intel.com/
> Intel Fortran Support
> http://developer.intel.com/software/products/support/
Also, were you involved with DEC fortran, about a decade ago?
| |
| Tim Prince 2005-04-26, 4:01 am |
|
"Phony Account" <phaccount@nycap.rr.com> wrote in message
news:z5gbe.8006$Bc7.5381@twister.nyroc.rr.com...
> Steve Lionel wrote:
>
> Thanks Steve. I will pay more attention to the intel forums. My ahem,
> bias, stems from experiences with some other, to remain un-named, software
> vendor.
>
> Also, were you involved with DEC fortran, about a decade ago?
| |
| Tim Prince 2005-04-26, 4:01 am |
|
"Phony Account" <phaccount@nycap.rr.com> wrote in message
news:z5gbe.8006$Bc7.5381@twister.nyroc.rr.com...
> Steve Lionel wrote:
>
> Thanks Steve. I will pay more attention to the intel forums. My ahem,
> bias, stems from experiences with some other, to remain un-named, software
> vendor.
> Also, were you involved with DEC fortran, about a decade ago?
Yes, he's the same Steve who has taken care of this series of Fortran
compilers since that time.
As all current Fortran compiler vendors make a sincere effort to comply with
the standards, there should be no problem asking generic Fortran questions
here. When it comes to questions which apply specifically to Intel
compilers, I second Steve's advice. Many experts are watching both forums
in question.
You are encouraged also to make use of your compiler vendor's support
system. Several have built an excellent record over the long term.
| |
| Richard Edgar 2005-04-26, 8:59 am |
| Phony Account wrote:
>
> See, I am used to the LaTeX compile cycle, where one usually does have
> to do multiple compiles in order for all the cross-referencing to be
> correct.
You still don't need to keep running make, though. The default target
just needs to run LaTeX a few times (and, of course, BibTeX). Only if
your LaTeX source is causing problems (like label lengths changing,
changing page numbers, which then change the labels...) should more than
a single invocation of make be needed.
Richard
| |
| Pierre Asselin 2005-04-26, 4:00 pm |
| Phony Account <phaccount@nycap.rr.com> wrote:
> See, I am used to the LaTeX compile cycle, where one usually does have
> to do multiple compiles in order for all the cross-referencing to be
> correct.
But that's also a Makefile issue:
.SUFFIXES:: .dvi .tex
.tex.dvi:
latex $<;
while grep -s Rerun $*.log; do latex $<; done
Now a "make toto.dvi" will re-run LaTeX as many times as necessary.
--
pa at panix dot com
| |
| Phony Account 2005-04-27, 3:58 am |
| Pierre Asselin wrote:
> Phony Account <phaccount@nycap.rr.com> wrote:
>
>
>
> But that's also a Makefile issue:
>
> .SUFFIXES:: .dvi .tex
>
> .tex.dvi:
> latex $<;
> while grep -s Rerun $*.log; do latex $<; done
>
> Now a "make toto.dvi" will re-run LaTeX as many times as necessary.
>
Man, are we off-topic :-) But let me study this one. I have not seen
this application of while grep yet.
Thanks,
Mirko
|
|
|
|
|