Prev: calling a recursive function in fortran 77 ?
Next: equivalent in fortran of the IDL "where" function
From: glen herrmannsfeldt on 26 Mar 2010 01:04
robert.corbett(a)sun.com wrote:
(snip)

> There are a couple of points that are unlikely to cause
> problems, but which are, theoretically, possible problems.
> The first is that the Fortran standards do not require an
> implementation to use the same layout for textually
> identical type definitions. The second is that an
> implementation might add some padding between elements of
> arrays to make address arithmetic easier. The
> implementation need not provide the padding for scalar
> variables and components. In practice, every implementation
> of which I am aware always uses the same padding whether a
> variable is a scalar or an array.

C sizeof is required to including any padding needed for
an array. I believe that means that the padding is there
even for a scalar, as you need to be able to memcpy() a
scalar struct based on its sizeof.

Also, I believe that C does require the same layout for
texttually identical struct definitions. It seems that
would apply to BIND(C) structures, too.

Sizing not related to C interoperability might not
including such padding.

-- glen
From: glen herrmannsfeldt on 26 Mar 2010 01:09
Richard Maine <nospam(a)see.signature> wrote:
(snip)

> I would say that the most obvious culprit is that, as per the comment,
> C_SIZEOF is an f2008 feature. Since GFortran doesn't (yet?) claim to be
> even a full f2003 compiler, much less f2008, you can't necessarily count
> on f2008 features.

> Given that James appears to have gotten it to work with GFortran, I
> posit that perhaps this function might have been fairly recently added
> and that he has a newer version of GFortran than you do. While I don't
> know that to be so, it seems like a good guess.

You might also want the -std=f2008 command line option.
The version I have doesn't yet allow that, but presumably
versions with Fortran 2008 features will add it.

-- glen
From: robert.corbett on 26 Mar 2010 02:40
On Mar 25, 10:04 pm, glen herrmannsfeldt <g...(a)ugcs.caltech.edu>
wrote:

> C sizeof is required to including any padding needed for
> an array. I believe that means that the padding is there
> even for a scalar, as you need to be able to memcpy() a
> scalar struct based on its sizeof.
>
> Also, I believe that C does require the same layout for
> texttually identical struct definitions. It seems that
> would apply to BIND(C) structures, too.

Yes the Fortran standards require the same layout for
identical BIND(C) types and sequence types, even they
derive from different type definitions. One bit of
nastiness regarding numeric sequence types is that the
standards require them to be laid out in ways that can
violate some machines' data alignment requirements.

> Sizing not related to C interoperability might not
> including such padding.

AFAIK, no implementation has taken advantage of that
freedom, but, yes, the standard offers it. Several
implementors have threatened to reorder the fields of
a derived type to allow more efficient data packing
and/or access, but I do not think any implementor has
yet had the guts to do it. I certainly do not propose
to be the first.

Bob Corbett
From: Richard Maine on 26 Mar 2010 02:57
<robert.corbett(a)sun.com> wrote:

> I can believe the NAGWare compiler would not support LOC.
> Sun stopped purchasing a license for the NAG compiler
> during the lean times, so it has been a while since I used
> it. I do wonder if there is a second compiler that does not
> support LOC.

I suspect so, but as I said, the NAG compiler alone is more than enough
instance for me and I haven't kept a list.

Now that I'm retired, I have a lot more limited selection of compilers
to experiment with to make such lists. The NAG compiler would account
for 50% of the ones I have handy at the moment on this machine. Yes, the
other 50% appears to have a LOC. By my measurement, 50% is a lot less
than "almost always." Before I retired, I had a lot larger selection of
compilers that I could test, but the NAG one (well, ones) probably
accounted for more like 90% of my use.

Of course, I'm thinking only about reasonably current f90+ compilers. If
one allows older f90 compilers as well as current ones, I'd go from
suspecting so to being willing to bet on it.

And if one allows f77 compilers, then lots of them didn't have LOC,
paticularly if one looks for that exact spelling.

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
From: Richard Maine on 26 Mar 2010 03:03
<robert.corbett(a)sun.com> wrote:

> One bit of
> nastiness regarding numeric sequence types is that the
> standards require them to be laid out in ways that can
> violate some machines' data alignment requirements.

That kind of issue isn't new to numeric sequence types either. Common
has had that issue for a long time, notably with double precision, which
can end up misaligned. I recall dealing with some f77 compilers that
just could not compile valid f77 code into something that actually
worked if there were such common misalignments. Others violated the
standard's layout requirements (thus possibly breaking things) in order
to make it work. I recall SUN at least having an option to make the code
conform to the standard's layout requirements and still work, but it
gave you a prominent warning that the result would run slowly.

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7 8
Prev: calling a recursive function in fortran 77 ?
Next: equivalent in fortran of the IDL "where" function