IFC Gotchas. 
Author Message
 IFC Gotchas.

Hello,

I remember reading on this list some time ago that Intel's ifc is not
too shabby for a free (on Linux, anyways) fortran compiler, but that
it includes quite a number of surprises and gotchas.  Can anyone here
elaborate?  I would really like to get a nice comprehensive feel for
what the limitations are with this compiler, but I don't know where
such information is already available in an easy-to-digest manner.



Fri, 03 Mar 2006 01:46:13 GMT  
 IFC Gotchas.

Quote:

> I remember reading on this list some time ago that Intel's ifc is not
> too shabby for a free (on Linux, anyways) Fortran compiler, but that
> it includes quite a number of surprises and gotchas.  Can anyone here
> elaborate?  I would really like to get a nice comprehensive feel for
> what the limitations are with this compiler, but I don't know where
> such information is already available in an easy-to-digest manner.

The only two issues I had with ifc have been rectified.

The older versions of the compiler (v5 and v6?) used a fairly
idiosyncratic method for storing their module information. The
latest versions (v7+) are much easier to use in this regard--they
produce .mod files which are searched for in the include path.

I couldn't use the ISO_VARYING_STRING module--it produced internal
compiler errors. This has been recitified as of version 7.1 build
20030822Z.

In general I have also seen fewer internal compiler errors, I used
to get some weird ones but I never bothered reporting them because
I could work around them easily enough.

The documentation is good-- a nice verbose user manual and easy to
use reference manuals as well in pdf and convenient searchable
html format.

The premier support was pretty good as well, seeing as I haven't
paid a bean for the compiler. I reported my problem with the
ISO_VARYING_STRING module and it was fixed within a few weeks--I
didn't say it was critical. They also acknowledged my bug report
and kept me up to date with the progress and told me when it was
fixed.

ifc doesn't support the extension to f95 which allows allows
allocatable arrays in user defined types (which has been discussed
a little on c.l.f recently).

Hope that helps,

Cheerio

Aidan

--
Remove famous (dead) Italian author plus full-stop to send me email (don't
blame me about the spelling of Alighieri -- it is the sysadmin's fault!)



Fri, 03 Mar 2006 08:31:25 GMT  
 IFC Gotchas.

Quote:

> Hello,

> I remember reading on this list some time ago that Intel's ifc is not
> too shabby for a free (on Linux, anyways) Fortran compiler, but that
> it includes quite a number of surprises and gotchas.  Can anyone here
> elaborate?  I would really like to get a nice comprehensive feel for
> what the limitations are with this compiler, but I don't know where
> such information is already available in an easy-to-digest manner.

If you call it a "gotcha," you definitely need to read the .pdf documents,
and pay attention to the options.  If you are used to g77, here are some
roughly equivalent options (supposing you mean ia32):
g77                                                     ifc
-ffast-math -funroll-loops -O2                          (default)
-march-pentium4 -mfpmath=sse -O2 -ffast-math -funroll-loops     -xW -vec- -ftz
-fno-second-underscore                                  (default)
-ffloat-store                                           -fp_port
-funroll-loops -O2                                      -mp
-fprofile-arcs                                          -prof_gen
-fbranch-probabilities                                  -prof_use
-ff90                                                   (default)
-fbounds-check                                          -C
(default)                                               -WB  (allow dimension (1) for (*))
-Wall                                                   -CU -CV
-fbounds-check                                          -CB

-ftz, if it works (only with SSE options), applies only when compiling the
main program, while (according to my recent observation), the equivalent
sub-feature of -ffast-math applies at link time.

Beyond that, your question is non-specific enough that almost any answer
might be somewhat valid.

The "free"ness of the compilers have much different sense.  In either case,
you should be reading the agreements.

-
--
Tim Prince



Fri, 03 Mar 2006 09:02:48 GMT  
 IFC Gotchas.

Quote:

> Hello,

> I remember reading on this list some time ago that Intel's ifc is not
> too shabby for a free (on Linux, anyways) Fortran compiler, but that
> it includes quite a number of surprises and gotchas.  Can anyone here
> elaborate?  I would really like to get a nice comprehensive feel for
> what the limitations are with this compiler, but I don't know where
> such information is already available in an easy-to-digest manner.

I've been using it for a couple of years now. It's got a LOT better
but here are some of the issues we are still working around
(DISCLAIMER: some may have been fixed in recent releases - I don't
have time to check all the workarounds every release):

1. Using parameters (instead of literals) for types in user defined
kinds which contain pointers directly or indirectly to variables of
the same kind causes a compiler crash.

2. Compiler has a tendency to optimise out logical operations which
are not constant if NaNs are considered.

3. The inheritance rules of public and private names in modules are
broken.

4. Where a dummy argument of intent(in) is of a type with pointer
components, the compiler allows changing the allocation state of the
pointer but not changing the value. This is the wrong way
round. Fortunately you can fool the compiler by pointing a local
pointer at the pointer component and working through that.

5. With debugging symbols on (-g), local variable symbol tables for
module procedures appear to be mangled. This might be a problem with
gcc-f95.

6. Because it is non-free (as in speech) it is dependent on gcc
version. Currently there are issues with gcc2.3, although in my
experience these only affect the de{*filter*} which is shipped, not the
compiler.

7. No ieee or allocatable array tr support (although this has been
promised for the next major version).

Once again, apologies to intel if any of these have been fixed
recently, although I have no reason to believe they have been.

Regards,

David



Fri, 03 Mar 2006 16:50:35 GMT  
 IFC Gotchas.
For your information:

Both Polyhedron: http://www.polyhedron.com/
and us: http://ftp.aset.psu.edu/pub/ger/fortran/test/results.txt
have run the latest Linux version of Intel IFC (7.1).

Skip Knoble, Penn State


-|Hello,
-|
-|I remember reading on this list some time ago that Intel's ifc is not
-|too shabby for a free (on Linux, anyways) Fortran compiler, but that
-|it includes quite a number of surprises and gotchas.  Can anyone here
-|elaborate?  I would really like to get a nice comprehensive feel for
-|what the limitations are with this compiler, but I don't know where
-|such information is already available in an easy-to-digest manner.

   Herman D. (Skip) Knoble, Research Associate
   (a computing professional for 38 years)

   Web: http://www.personal.psu.edu/hdk
   Penn State Information Technology Services
    Academic Services and Emerging Technologies
     Graduate Education and Research Services
   Penn State University
     214C Computer Building
     University Park, PA 16802-21013
   Phone:+1 814 865-0818   Fax:+1 814 863-7049



Fri, 03 Mar 2006 21:39:58 GMT  
 IFC Gotchas.
...

Quote:
> 4. Where a dummy argument of intent(in) is of a type with pointer
> components, the compiler allows changing the allocation state of the
> pointer but not changing the value. This is the wrong way
> round. [...]

On the other hand, that's the rule I think should be adopted.  Neither
is part of the standard yet.  Since you describe a workaround, that's
even a stronger argument for the semantics I prefer (and IFC does).
Maybe that particular part of the proposed document can be changed
by pressure from the public review.

--
J. Giles



Sat, 04 Mar 2006 02:33:12 GMT  
 IFC Gotchas.

Quote:
> Hello,

> I remember reading on this list some time ago that Intel's ifc is not
> too shabby for a free (on Linux, anyways) Fortran compiler, but that
> it includes quite a number of surprises and gotchas.  Can anyone here
> elaborate?  I would really like to get a nice comprehensive feel for
> what the limitations are with this compiler, but I don't know where
> such information is already available in an easy-to-digest manner.

Upside:

   Intel Fortran makes very fast run-time executables when it works.

   Documentation is comprehensive in a "reference" sense, but it
   is not particularly tutorial.  I.e. it says roughly what is there
   but not generally what you probably want to do.

Downside:

   Compile time messages are vague and a real pain, don't always
   provide a line number (e.g. the ubiquitous undeclared mistyped variable),
   and this cascades into far more errors, as usually an error will
   cause the whole module to fail compilation.   If you compile in emacs
   and use its error-message parsing the net result means you will go
   to a line which is the wrong source of the error.   This means
   you will have to manually look back in the compiler output to find
   the real error.  Since it doesn't have a line number attached you
   will have to search in your own code to find the subroutine.  And
   what makes this worse is that you cannot turn off the informational
   messages spitting out a line for every subroutine/function compiled,
   so that you have to search for one line among dozens manually.

   The Intel Fortran 8.0 beta helps significantly here.  Error messages
   are better.

   But this is only a minor problem compared to actual bugs.

   In my experience the compiler has had a number of bugs in code
   generation and crashing during compilation.   (I have had probably
   a dozen reproduced bugs sent to their tech support).

   The biggest problem is that the run-time debugging and informational
   facilities don't work well and neither does the de{*filter*}.  Even
   with all checking options on it is frequent to get core dumps.  

   I have essentially given up on ifc during some development.  By
   contrast, the NAG compiler is extremely reliable (I have never
   found a significant bug in 5 years), gives good error
   messages, and the run-time checking is usually quite effective and
   precise.   But its generated code runs between 50% to 100% slower than
   Intel's on my various programs.

   NAG is one of the less expensive commercial compilers.



Sat, 04 Mar 2006 05:06:48 GMT  
 IFC Gotchas.

Quote:


> ...
> > 4. Where a dummy argument of intent(in) is of a type with pointer
> > components, the compiler allows changing the allocation state of the
> > pointer but not changing the value. This is the wrong way
> > round. [...]

> On the other hand, that's the rule I think should be adopted.  Neither
> is part of the standard yet.  Since you describe a workaround, that's
> even a stronger argument for the semantics I prefer (and IFC does).
> Maybe that particular part of the proposed document can be changed
> by pressure from the public review.

> --
> J. Giles

I thought this was specified by the standard (which is why I claimed
that IFC is wrong). M+R p81 states:

"If a dummy argument is of a dervied type with pointer components, its
intent attribute refers to the pointer association status of those
components. For example, if the intent is in, no pointer assignment,
allocation or deallocation is permitted. The intent attribute has no
bearing on the values of the targets of pointer components."

When I hit this issue with IFC last year, I queried on this newsgroup
whether this was in fact the behaviour required by the
standard. Richard Maine responded in the affirmative, although he did
state that the relevent section of the standard had caused
interpretation issues.

The relevant thread is available on google at:

http://groups.google.com/groups?threadm=ue7kktdb19.fsf%40altair.dfrc....

regards,

David



Sat, 04 Mar 2006 15:58:35 GMT  
 IFC Gotchas.


Quote:

> I thought this was specified by the standard (which is why I claimed
> that IFC is wrong). M+R p81 states:

> "If a dummy argument is of a dervied type with pointer components, its
> intent attribute refers to the pointer association status of those
> components. For example, if the intent is in, no pointer assignment,
> allocation or deallocation is permitted. The intent attribute has no
> bearing on the values of the targets of pointer components."

> When I hit this issue with IFC last year, I queried on this newsgroup
> whether this was in fact the behaviour required by the
> standard. Richard Maine responded in the affirmative, although he did
> state that the relevent section of the standard had caused
> interpretation issues.

Yes, and when it was resolved, the paragraph you quote was changed somewhat
to correspond to the interpretation. It now reads (as of the 2002 printing):
"If a dummy argument is of a derived type with pointer components, its
<intent> attribute also refers to the pointer association status of those
components. For example, if the intent is <in>, no pointer assignment,
allocation, or deallocation is permitted." The changes are thus to add
'also' and to delete the last sentence.

Regards,

Mike Metcalf



Sat, 04 Mar 2006 23:09:28 GMT  
 IFC Gotchas.

Quote:

> Yes, and when it was resolved, the paragraph you quote was changed somewhat
> to correspond to the interpretation. It now reads (as of the 2002 printing):
> "If a dummy argument is of a derived type with pointer components, its
> <intent> attribute also refers to the pointer association status of those
> components. For example, if the intent is <in>, no pointer assignment,
> allocation, or deallocation is permitted." The changes are thus to add
> 'also' and to delete the last sentence.

> Regards,

> Mike Metcalf

I wasn't aware that there was another printing. Are there many
significant changes? Also, do you have public plans about future
editions of the book (either for f95 or for f2k)? My current copy
which I bought when I started programming in Fortran at the beginning
of 2000 is showing the signs of its very heavy use so I was
contemplating replacing it before something impartant falls out. If
there is a new and improved version, I'll definitely go and buy it
(plus there's the fact that Messrs M+R definitely deserve a second set
of royalties from me :-).

Regards,

David



Sat, 04 Mar 2006 23:27:33 GMT  
 IFC Gotchas.


Quote:

> I wasn't aware that there was another printing. Are there many
> significant changes?

No, just a series of changes because of interpretations and some minor
improvements. There was a printing in 2002 followed by another this year.

Quote:
> Also, do you have public plans about future
> editions of the book (either for f95 or for f2k)?

We announced some time ago that we plan "Fortran 95/2003 Explained" for
2004. We are happy that we shall be joined by Malcolm Cohen of NAG as a
third author.

Quote:
> My current copy
> which I bought when I started programming in Fortran at the beginning
> of 2000 is showing the signs of its very heavy use so I was
> contemplating replacing it before something impartant falls out. If
> there is a new and improved version, I'll definitely go and buy it
> (plus there's the fact that Messrs M+R definitely deserve a second set
> of royalties from me :-).

Thanks for the kind thought. Bulk orders are also gratefully encouraged!

Regards,

Mike Metcalf



Sat, 04 Mar 2006 23:55:30 GMT  
 IFC Gotchas.

Quote:



> > I wasn't aware that there was another printing. Are there many
> > significant changes?

> No, just a series of changes because of interpretations and some minor
> improvements. There was a printing in 2002 followed by another this year.

> > Also, do you have public plans about future
> > editions of the book (either for f95 or for f2k)?

> We announced some time ago that we plan "Fortran 95/2003 Explained" for
> 2004. We are happy that we shall be joined by Malcolm Cohen of NAG as a
> third author.

I missed the announcement, but: Woohoo!

Is Amazon or the like accepting advance orders yet? :o)

cheers,

paulv

--
Paul van Delst

Ph: (301)763-8000 x7748
Fax:(301)763-8545



Sun, 05 Mar 2006 00:04:14 GMT  
 IFC Gotchas.

Quote:



>> ...
>>> 4. Where a dummy argument of intent(in) is of a type with pointer
>>> components, the compiler allows changing the allocation state of the
>>> pointer but not changing the value. This is the wrong way
>>> round. [...]

>> On the other hand, that's the rule I think should be adopted.  Neither
>> is part of the standard yet.  Since you describe a workaround, that's
>> even a stronger argument for the semantics I prefer (and IFC does).
>> Maybe that particular part of the proposed document can be changed
>> by pressure from the public review.

>> --
>> J. Giles

> I thought this was specified by the standard (which is why I claimed
> that IFC is wrong). M+R p81 states:

> "If a dummy argument is of a dervied type with pointer components, its
> intent attribute refers to the pointer association status of those
> components. For example, if the intent is in, no pointer assignment,
> allocation or deallocation is permitted. The intent attribute has no
> bearing on the values of the targets of pointer components."

I misread your original article.  I thought you were referring to dummy
arguments that have the pointer attribute, not to dummy arguments that
have components with the pointer attribute.  It is the behavior of dummy
arguments that themselves actually have the pointer attribute that I was
addressing.  It is not allowed in the present standard (F95) to specify
an INTENT for pointer attributed dummy arguments.  The proposed
F2kV allows it with the same semantics that you state for pointer
components.

--
J. Giles



Sun, 05 Mar 2006 01:00:09 GMT  
 
 [ 13 post ] 

 Relevant Pages 

1. Most annoying Java gotchas

2. wxPython gotchas

3. Modul gotchas:)

4. Win32Com: VB5 COM server gotchas

5. FORTRAN "gotchas", and how to aviod them

6. can't compile programs in ifc

7. Problem running IFC on Debian

8. ifc v8.0 run-time crash (TRANSPOSE intrinsic)

9. testing programs in lapack does not run with ifc 7.1

10. why segfault for large ifc-compiled executable?

11. IFC 8.0 Error on Unformatted writing

12. Problem with Intel ifort (ifc) 8.0 compiler

 

 
Powered by phpBB® Forum Software