[Fwd: (j3.2006) Fortran 2003 compiler features]

[Dominique Dhumieres]

> If it's trivial, why not propose a patch?

--- math.f90    Thu May 13 08:41:07 2004
+++ math_db.f90 Wed Feb  7 22:20:52 2007
@@ -24,7 +24,7 @@
    real(kind=8) q, two8, half8
    complex(kind=4) cr
    complex(kind=8) cq
-   external dotest, dotest2
+   external dotest, dotestc
 
    two4 = 2.0
    two8 = 2.0_8

> If you propose the patch, that means you've done the debugging and the
> regression testing (which takes about three hours, give or take).  If I
> write the patch, I have to do the testing -- and, usually, when I'm
> working on gfortran work, I'm wanting to use my build machine for testing
> other things.  It also means that once I've done the testing (and any
> debugging and retesting), I have to spend probably 10-15 minutes creating
> the diff file to post, writing the changelog, posting the message here
> and to gcc-patches@ that describes the change, and then some time later
> once someone else has approved it, I need to apply it.

For this example, does not this sound like "nuking a fly"?  There are two
"external" subroutines 'dotest' and 'dotestc' in the file and no other file
supplied in which dotest2 could be present.  Do you seriously think that
gfortran is that bad that it requires three hours of regtesting to conclude
that it is safe to fix the obvious typo?  Does not this fall under the
"obvious rule" with a fix "en passant" by someone having the permission?
If the procedure you are describing in your mail is required for this case,
I understand better why you have so few volunteers.

Do you realize that I don't know how to use SVN in the context of gcc,
that my gcc build is done through fink, and so on.  Indeed I think I am 
not stupid enough to be unable to learn part of what I would need, but
do you really think I'll go for it on the above example?

Now when I reported the problem was not the typo, I had the feeling that
g95 was overcautious to try (and fail) to link to dotest2 on the assumption
that it could be a BLOCK DATA. I probably left my question too implicit to
get an answer.

> If the reason for the hanging is the recursive I/O, I frankly do not
> think solving that bug is worth our time.

Allow me to strongly disagree with you on this point.  Apparently "ICE on
invalid code" are kept as low priority bugs to be fixed some day.  Why a
much more annoying misbehavior on invalid code could be brushed aside like
that.  Between an ICE and hanging or infinite loop on valid/invalid code, I
do not hesitate a second to choose the former, even I understand that you
do not find it aesthetic.  And indeed I find the trade off between
easthetism and efficiency in the gfortran life is debatable.

> There's a difference between a PR saying "this is a bug that should be
> fixed" and a PR saying "a diagnostic message on this error would be a
> helpful enhancement".

Note that when I open a PR, I never say it should be fixed, I only say I
"have seen this behavior which does not seem right" and, when I have doubt
about it, I ask the question on the gfortran list before filling a PR. In
the present case I only think the behavior on an invalid code is so bad
that it should have the same status as an "ICE on invalid code", low
priority but to do some day.

> "a diagnostic message on this error would be a helpful enhancement".

The diagnostic message is not the same thing as avoiding hanging or
infinite loop.  I have never required that in PR30617 (did I requested
anaything in it?), although I have said it would be a helpful enhancement
in this list.

> Still, though, it should only be run if we have some reason to expect
> that it might give wrong answers.

Does not the noise I am making question the methodology?  There was no
reason that I will do something as stupid as running the executable to find
it hanging.  For me bugs are only the unexpected, I am pretty sure that if
you were expecting a bug you'ld try to fix it before seeing it (or add a
warning or a "to do" ICE).

Dominique