gfortran error format (was: Re: Emacs and GFortran)

gfortran error format (was: Re: Emacs and GFortran)

[François-Xavier Coudert]

Hi,

This discussion is heating a bit, wasting everybody's time. I've
opened a bugzilla PR for this bug: PR 29689
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29689).

If someone wants to propose a complete patch (against subversion
mainline) that works, regression-tests fine, please send it and it
will be reviewed like any other patch.

If anyone, not willing to write a patch, has ideas on what exactly the
change should be, please add them to the PR . Please include examples
of how the error messages would then look like, including simple cases
and more tricky ones (multi-loci, included files, etc.). Having (a)
convincing proposal(s) for the change is more than half the work, and
will probably help a wandering developer to implement it.

Finally, if you want to add to the list of "tricky cases we have to
make sure behave right after the change", please add a comment in the
PR.


PS: One thing that I would like to note, however: changing the format
of error messages is not something we can do out of the blue. Some
tools already handle the gfortran error messages, so we probably don't
want to make life too hard for them. This implies, in my humble
opinion, that this bans a change of format for already realeased
branches.

FX

Re: gfortran error format (was: Re: Emacs and GFortran)

[Alfred M. Szmidt]

   If someone wants to propose a complete patch (against subversion
   mainline) that works, regression-tests fine, please send it and it
   will be reviewed like any other patch.

A purposed patch that makes gfortran follow the GCS is already
purposed and submitted, two version of it one backward compatible (g77
style) and one that is not exist.  It has been repeated a billion
times that gfortran does not have to follow the GCS to the letter,
only allow to jump to the error location.  If you or anyone else
wishes to do that, please do, but this is not what was requested.

   PS: One thing that I would like to note, however: changing the
   format of error messages is not something we can do out of the
   blue. Some tools already handle the gfortran error messages, so we
   probably don't want to make life too hard for them.

I already purposed a backward compatible version of the format that
should work with tools that parse the "old" format, this is what g77
did for example; this fact has also been repeated several times now.


I do not wish to spend any more on this, so this will be my last
message on the topic, I think it is clear what should be done, and
what is requested is a trivial change but people being stubborn and
making up excuses.

Re: gfortran error format (was: Re: Emacs and GFortran)

[Steve Kargl]

On Thu, Nov 02, 2006 at 03:20:23PM +0100, Alfred M. Szmidt wrote:
> 
> A purposed patch that makes gfortran follow the GCS is already
> purposed and submitted, two version of it one backward compatible (g77
> style) and one that is not exist.  It has been repeated a billion
> times that gfortran does not have to follow the GCS to the letter,
> only allow to jump to the error location.  If you or anyone else
> wishes to do that, please do, but this is not what was requested.
> 

I already showed you that those two purposed and submitted
patches cause over 2000 regression in the gfortran testsuite.

-- 
Steve

Re: gfortran error format

[David Kastrup]

"François-Xavier Coudert" <fxcoudert@gmail.com> writes:

> Hi,
>
> This discussion is heating a bit, wasting everybody's time. I've
> opened a bugzilla PR for this bug: PR 29689
> (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29689).

[...]

Thanks for directing the discussion to the proper place.  It seems
like that's the best bet for arriving at a solution eventually.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: gfortran error format (was: Re: Emacs and GFortran)

[Richard Stallman]

    If someone wants to propose a complete patch (against subversion
    mainline) that works, regression-tests fine, please send it and it
    will be reviewed like any other patch.

A change to make GFortran comply with GNU standards should be reviewed
for correctness, of course, but not "like any other patch".
Maintainers should keep in mind that this is a problem that needs to
be fixed.  If users don't provide a suitable patch, the maintainers
should procure for one to be written.

Re: gfortran error format (was: Re: Emacs and GFortran)

[Erik Edelmann]

On Fri, Nov 03, 2006 at 02:08:17AM -0500, Richard Stallman wrote:
>     If someone wants to propose a complete patch (against subversion
>     mainline) that works, regression-tests fine, please send it and it
>     will be reviewed like any other patch.
> 
> A change to make GFortran comply with GNU standards should be reviewed
> for correctness, of course, but not "like any other patch".
> Maintainers should keep in mind that this is a problem that needs to
> be fixed.  If users don't provide a suitable patch, the maintainers
> should procure for one to be written.

We will, sooner or later. But there are 123 other bugs (enhancement
requests not counted) in Bugzilla for Gfortran right now. They need to
be fixed too.   We see no reason to give higher priority to this bug
than to the others.

If GNU standard conformance for error messages is more important/urgent
than ICE-on-valid-code and rejects-valid-code in your opinion, feel free
to argue about it.  If you are really convincing, I promise to put it as
the next item on my personal TODO-list.  Otherwise I'll concentrate on
fixing a few other bugs first.


        Erik

Re: gfortran error format (was: Re: Emacs and GFortran)

[Brooks Moses]

Richard Stallman wrote:
>     If someone wants to propose a complete patch (against subversion
>     mainline) that works, regression-tests fine, please send it and it
>     will be reviewed like any other patch.
> 
> A change to make GFortran comply with GNU standards should be reviewed
> for correctness, of course, but not "like any other patch".
> Maintainers should keep in mind that this is a problem that needs to
> be fixed.  If users don't provide a suitable patch, the maintainers
> should procure for one to be written.

Well, most of the other GFortran patches are also for problems that need 
to be fixed.  :)

In any case, I believe that the patch I checked into the GCC mainline a 
few hours ago fixes the important parts of this particular problem, and 
you should find that the error messages are now properly parsable 
without special treatment.  If that's still not the case, please let me 
know.

- Brooks

Re: gfortran error format (was: Re: Emacs and GFortran)

[François-Xavier Coudert]

> We will, sooner or later. But there are 123 other bugs (enhancement
> requests not counted) in Bugzilla for Gfortran right now. They need to
> be fixed too.   We see no reason to give higher priority to this bug
> than to the others.

To end the discussion, I'll note that Brooks Moses, with approval of
Steve Kargl and help from Jerry DeLisle for the testing, commited the
change to error.c along with the correct change to the testsuite
framework:

http://gcc.gnu.org/ml/fortran/2006-11/msg00060.html

Now, can we get our mailing-list back? :)

FX

Re: gfortran error format

[Stefan Monnier]

> In any case, I believe that the patch I checked into the GCC mainline a few
> hours ago fixes the important parts of this particular problem, and you
> should find that the error messages are now properly parsable without
> special treatment.  If that's still not the case, please let me know.

Thank you,


        Stefan

Re: gfortran error format (was: Re: Emacs and GFortran)

[Richard Stallman]

    We will, sooner or later. But there are 123 other bugs (enhancement
    requests not counted) in Bugzilla for Gfortran right now. They need to
    be fixed too.   We see no reason to give higher priority to this bug
    than to the others.

I understand you can't fix all bugs right away.  Since I don't know
what those other bugs are, I have no opinion on their relative
priority.  But that is not the crucial point.

The crucial point here is to give this bug a substantial positive
priority -- to acknowledge that this is "something we need to fix"
rather than "you users can fix it if you like".  It doesn't have to be
highest priority, but it does have to be substantial and positive.