From: robert.corbett@sun.com
Newsgroups: comp.lang.fortran
Subject: Re: READ-statement and a segmentation fault
Date: 24 Oct 2006 21:52:29 -0700
Message-ID: <1161751949.661974.10900@f16g2000cwb.googlegroups.com>

Dick Hendrickson wrote:
> robert.corbett@sun.com wrote:
> > Dick Hendrickson wrote:
> >> robert.corbett@sun.com wrote:
> >>> Great!  Then there should be no objection to adding language to the
> >>> standard prohibiting bogus function calls to be added via the
> >>> "mathematical equivalence" rule.
> >>>
> >> Before you get too excited, remember I started out by saying
> >> "fuzzy memory" and the last sentence started with "If".  So,
> >> there's some room for negotiation.
> >>
> >> More seriously, adding a rule that tries to say A=B can't be
> >> evaluated "as if" it were A=B + 0*F(X) doesn't seem useful.
> >> Nobody seriously thinks that would ever happen.  True, the current
> >> rules could be read to say it could happen ("as if" is pretty open
> >> ended), but it doesn't happen.  The current fuzzy definition of
> >> "mathematical equivalence" works because A) everybody wants it to
> >> work, B) everybody intuitively knows what it means, C) we don't want
> >> to unecessarily prevent future breakthroughs in optimization or
> >> debugging.  I once worked on a compiler that "evaluated" ARRAY(I,J)
> >> as if it were FUNCTION(ARRAY, I, J, ...) where the ... had the
> >> declared array bounds and the function did bounds checking.  It
> >> was a half-baked scheme to let us "check the box" on a procurement
> >> that required some debugging capabilities.  I would be a shame to
> >> prevent something quasi-useful like this in order to clarify
> >> something that "nobody" gets wrong in practice.  At least, that's
> >> my personal opinion today ;).
> >
> > So, let's take the example of the substring operation I gave before.
> > Would you say that it is standard -conforming for the substring
> > operation STR(F():N) to evaluate the function reference F() twice?
> > If not, why not?
>
> No, it's not (in my opinion) standard conforming.  [I'm truly NOT
> trying to be insulting here.]  It's not standard conforming because
> it makes no sense in the context of the general case that user written
> external functions that are separately compiled often have side effects.
> Chapter 1 says something like "the purpose of this standard is to
> promote portability, reliability, ..."   How can "portability" be
> promoted or enhanced if F() is evaluated two (or more, what the heck)
> times?  It can't!  Many of the statements in F2003 read better if
> the phrase "use 1950s or 1960s common sense here" were added.  The
> standard can't possibly rule out every conceivable way to do
> something (odd?) to a statement.
>
> I think the same arguments applies to those nuts (two of whom drank
> my wine in my house last weekend!) who say that a statement like
>     A = user_function_with_side_effects()
> doesn't have to evaluate the function.  How on earth does that improve
> portability or reliability?   Rather than try to interpret a specific
> sentence in a narrow way, people need to step back a tad and look
> at the purpose of the language.
>
> If I hadn't had a heckuva day and a martini I probably would have
> phrased this differently.
>
> Dick Hendrickson

I think you missed my point.  I must not have been clear enough.

I believe that the standard should not allow a conforming processor
to evaluate a function reference where the referenced function has
side effects more than once.  The standard, if the mathematical
equivalence rule is taken literally, says that it can.  I intended the
example of STR(F():N) as an example where an implementor might
use the mathematical equivalence rule to claim he has the right to
evaluate the function reference F() more than once.  Nothing
currently in the standard contradicts such a claim.

You state, in essence, that a literal reading of the Fortran standard
would allow evaluating a single function reference more than once,
but that such a reading is unreasonable.  I agree that it is
undesireable for a processor to do so.  Therefore, I believe that
the standard should prohibit a processor from doing so.  I don't
believe it is in anyone's interest to encourage people to think that
if a portion of the Fortran standard taken literally is unreasonable,
it should be ignored.

Much of what the Fortran standard says seems unreasonable to
many people.  In another recent thread, people were surprised to
learn that the standard allows the expression RAND() + RAND()
to be evaluated as 2*RAND().  A literal reading of the standard
makes it clear that that transformation is allowed, but many
people find that interpretation unreasonable.

I have seen instances where changes to the membership of J3
have changed the committee's interpretation of portions of the
standard.  The same text that was interpreted one way at one
meeting was interpreted the opposite way in a later meeting.
The only difference was who attended the meetings.

The standard as written is an informal document, and so is
subject to differing interpretations.  Nonetheless, the text of the
standard should be made as tight as it can be made to avoid as
many misinterpretations as possible.

One simple way of eliminating the possibility of some
misinterpretations would be to add examples illustrating the
complicated features of the language.  One of the maddening
features of the current standard is that it has many examples of
the simple features of the language, which people are likely to
understand without assistance, but few examples of the
complicated features, which routinely trip people up.  For
example, the semantics given in Section 12.3 of the standard
"Characteristics of procedures" have been misinterpreted by
many people, even members of the committee.  There is not
a single example in that section.

Bob Corbett

From: robert.corbett@sun.com
Newsgroups: comp.lang.fortran
Subject: Re: elemental function question regarding use of array slices
Date: Tue, 16 Feb 2010 21:25:07 -0800 (PST)
Message-ID: <ef5ce665-5aa8-4096-a9b9-4210b82e7982@d27g2000yqf.googlegroups.com>

On Feb 16, 2:14 pm, Paul van Delst <paul.vande...@noaa.gov> wrote:
> glen herrmannsfeldt wrote:
> > Paul van Delst <paul.vande...@noaa.gov> wrote:
> > (snip)
>
> >>  ELEMENTAL FUNCTION Cloud_Add( cld1, cld2 ) RESULT( cldsum )
> > (snip)
> >> that is overloaded with OPERATOR(+),
> > (snip)
>
> >>    IF ( atm1%n_Clouds > 0 ) THEN
> >>      nc = atm1%n_Clouds
> >>      atmsum%Cloud(1:nc) = atmsum%Cloud(1:nc) + atm2%Cloud(1:nc=
)
> >>    END IF
> > (snip)
> >> When invoked, the line
>
> >>  atmsum%Cloud(1:nc) = atmsum%Cloud(1:nc) + atm2%Cloud(1:nc)
>
> >> causes a segfault. When I change it to the more usual
>
> >>  atmsum%Cloud = atmsum%Cloud + atm2%Cloud
>
> >> everything is fine. No segfault and results are correct.
>
> > What is the value of nc at that point?  If it is nowhere near
> > the value it should have, then segfault is likely.  If it is,
> > then I would wonder about compiler bugs.
>
> > I notice that nc comes from atm1, but atm2 is used in the sum.
> > I would print nc as a debugging aid until the problem was fixed.
>
> Well, I can't print it out since the function is elemental,

You can if you use a technique I call "lying."  Declare the function to
be elemental in the code that calls it, but do not declare it elemental
in the code that defines it.  You might need to break the function out
into a file of its own to compile it.  Of course, you should do this only
for debugging, never for production code.

Bob Corbett