Prev: How you can save fuel and the environment
Next: gfortran and C interoperability problem
From: Steve Lionel on 11 Jan 2010 21:24
On 1/11/2010 4:49 PM, Tobias Burnus wrote:

> By the way, how do you (let's say as vendor) decide that you support all
> of Fortran 2003? It seems to be a rather difficult problem; surely, you
> follow some list (e.g. the Fortran Forum's one), you may look at the
> "what's new" list of the Fortran 2003 standard, but it is very easy to
> miss minor changes, e.g. that types without components are allowed -
> something which is a not very visible change in the standard. There is a
> huge number of such changes, several of which might get easily missed.

A very good question. From my perspective, it's when you *think* you
have all the features implemented - you've gone through various lists
and checked off everything. As you say, there are lots of little changes
that can be missed this way, so the position I'd take is "we think we
have it all, anything missing is a bug". Since there's no official
conformance testing suite, that's really the best you can hope for.

Realistically, I expect vendors to be finding and fixing missing bits,
like the one you mentioned, for years after claiming "full" support. One
we tripped over recently was that you can omit the keyword MODULE in
MODULE PROCEDURE in an interface body.

--
Steve Lionel
Developer Products Division
Intel Corporation
Nashua, NH

For email address, replace "invalid" with "com"

User communities for Intel Software Development Products
http://software.intel.com/en-us/forums/
Intel Software Development Products Support
http://software.intel.com/sites/support/
My Fortran blog
http://www.intel.com/software/drfortran
From: Richard Maine on 11 Jan 2010 22:02
Steve Lionel <steve.lionel(a)intel.invalid> wrote:

> On 1/11/2010 5:57 PM, jwm wrote:

> > What I really like about ifort's implementation, is the fact it works
> > without enabling reallocation on assignment.
>
> That's the way it works *now*. When we first released 11.1 with this
> feature, you needed the switch. When this came to my attention I took
> out my baseball bat - er - had a quiet word with the developers, and
> they fixed it. My argument was that we have the switch (-assume
> realloc_lhs) for the benefit of programs written to F90/F95 that used
> allocatable arrays and were required to allocate them. Allocatable
> character strings were new and the implicit reallocation was the best
> part of it, so reallocation should be the default. Sometimes developers
> get a bit too close to the code and need help seeing the bigger picture....

Ah good. Sounds like we are on the same "page" then and I don't have to
get out my baseball bat to use on you. :-) See my parallel followup
where I was asking what jwm meant by that statement. I got perhaps a bit
emphatic in making what I think are simillar comments to yours above.
Sounds like he meant the "right" thing (IMO).

> While on the subject of allocatable characters, I've run across more
> than one customer who thought that automatic allocation should happen on
> a READ. Nice idea, but that's not the way it's written in the standard.

Yup. I've heard simillar comments - some here. It would require a bit of
care to define such a thing, though that's not to say it would be
impossible. It would certainly have to at least be a bit of a special
case because doing it in full generality is trivially ambiguous.
(Imagine reading x,y, where both are allocatable). Also, doing it
trivially would have problems with conflicts with existing
standard-conforming code. It is currently valid to do

read(unit) x

where x is allocatable and is allocated to something smaller than the
record size. One can't reasonably break such existing code in a new
standard. There are ways to avoid that problem. I'm not sure what I
would favor, but muliple options clearly exist.

One option I have heard mentioned is to do the allocation only if the
array was previously unallocated. That couldn't conflict with any
previously legal code, but it might be slightly annoying to have to
explicitly deallocate before the read if you wanted that behavior.
Another option might be some kind of specifier in the read statement to
say you wanted the behavior. Well, I'm not trying to seriously design
such a thing right here - just pointing out that it could be done.

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
From: jwm on 11 Jan 2010 22:34
On Jan 11, 7:09 pm, nos...(a)see.signature (Richard Maine) wrote:
> jwm <jwmwal...(a)gmail.com> wrote:
> > What I really like about ifort's implementation, is the fact it works
> > without enabling reallocation on assignment.
>
> I'm confused about what you mean there. Do you perhaps mean that
> allocatable character length reallocation on assignment works without
> having to enable an option to do reallocation of allocatable arrays on
> assignment? If so, that I suppose I could see.
>
> ...

Yes, that's what I meant; sorry for the ambiguity. I used to make the
mistake of under-/oversizing the right-hand side of an array
assignment to often, so having reallocation on assignment only for
allocatable length characters, works better for me. Besides, right
now ifort's documentation states that such feature (-assume
realloc_lhs) "may cause extra overhead at run time".
From: glen herrmannsfeldt on 12 Jan 2010 02:02
Steve Lionel <steve.lionel(a)intel.invalid> wrote:
(snip)

> While on the subject of allocatable characters, I've run across more
> than one customer who thought that automatic allocation should happen on
> a READ. Nice idea, but that's not the way it's written in the standard.

Nice idea, and most interpreted languages do it. Most compiled
languages don't, as you don't know the length until you have
actually read it, at least into a buffer.

Maybe not so bad for characters if there is a reasonable length
limit, but then someone will want automatic allocation for
reading in arrays.

read(*,*) A

to read in an entire file into an appropriately allocated A.

Even more, into a two-dimensional array with the appropriate
number of rows and columns.

-- glen

From: jfh on 12 Jan 2010 16:38
On Jan 11, 10:27 pm, Tobias Burnus <bur...(a)net-b.de> wrote:
> On 01/11/2010 09:16 AM, Dieter Britz wrote:
>
> > Are there any real Fortran 2003 compilers available? What I have seen
> > is compilers that are said to have "most" of 2003. Or have I just not
> > found the right ones?
>
> I think the Cray has: As far as I understood it, supports all of Fortran
> 2003. IBM's xlf comes close, but seemingly still lacks user-defined
> derived-type I/O.
>
> See: ACM Fortran Forum's December 2009 issue,
>  http://doi.acm.org/10.1145/1667140.1667145
> orhttp://fortranwiki.org/fortran/show/Fortran+2003+status(from the
> August 2009 issue of ACM Fortran Forum).
>
> (Note: I think the "N" for Cray under "international characterset" just
> means that it does not support UTF-8 - but that's permitted by the
> Fortran 2003 standard.)
>
> If you talk about normal PC hardware, I think the answer is no. NAG
> nagfor v5.2, Intel's ifort v11.1, and GCC's gfortran v4.5 support a lot,
> but still there are many features unimplemented. Or in other words: One
> can do most things one wants to do - Fortran 2003 wise - but
> unfortunately one need to have the list of supported features ready to
> make sure no unsupported feature slips into one's code. (Add in
> addition, as the features get implemented in a slightly different order,
> finding a common subset is even harder and more restrictive.)
>
> Tobias
>
> PS: Just for curiosity, which of gfortran's missing Fortran 2003
> features do you miss most?
> (Planned for 4.6 are ASSOCIATE construct, fixing bugs in the current
> polymorphism support, implementation of unlimited polymorphism, and true
> asynchronous I/O; what really will be implemented? - only the future can
> tell, which is typical for the more erratic development of a
> volunteer-based software development.)

The f2003 feature I miss most is being allowed to put elemental
intrinsics with logical, real or complex arguments in an
initialization expression. The following program compiles and runs
with g95 but none of the other 3 compilers I have tried, one of which
is gfortran.

integer,parameter:: dp = kind(1d0), &
hperhaps = selected_real_kind(precision(1._dp)+1),&
hp = merge(hperhaps,dp,hperhaps>0)
real(hp),parameter:: pi = acos(-1._hp)
print *,'hp =',hp,'precision =',precision(1._hp)
print *,'pi =',pi
end

It may be that my gfortran has been superseded: unfortunately our
systems people don't think updating it is their highest priority. My
compile-time experience is below:

rimu[~]$ gfortran -v
Using built-in specs.
Target: i386-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --
infodir=/usr/share/info --enable-shared --enable-threads=posix --
enable-checking=release --with-system-zlib --enable-__cxa_atexit --
disable-libunwind-exceptions --enable-libgcj-multifile --enable-
languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --
disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.4.2-
gcj-1.4.2.0/jre --with-cpu=generic --host=i386-redhat-linux
Thread model: posix
gcc version 4.1.2 20080704 (Red Hat 4.1.2-46)
rimu[~]$ gfortran testinit.f90
In file testinit.f90:4

real(hp),parameter:: pi = acos(-1._hp)
1
Error: Constant expression required at (1)
In file testinit.f90:5

print *,'hp =',hp,'precision =',precision(1._hp)
1
Error: Missing kind-parameter at (1)
rimu[~]$

John Harper
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: How you can save fuel and the environment
Next: gfortran and C interoperability problem