public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libfortran/63930] New: libgfortran should use 'abort ()' instead of 'exit (2)' for run-time errors
@ 2014-11-18 10:37 ludo at gnu dot org
  2015-07-05 12:41 ` [Bug libfortran/63930] " fxcoudert at gcc dot gnu.org
                   ` (4 more replies)
  0 siblings, 5 replies; 6+ messages in thread
From: ludo at gnu dot org @ 2014-11-18 10:37 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63930

            Bug ID: 63930
           Summary: libgfortran should use 'abort ()' instead of 'exit
                    (2)' for run-time errors
           Product: gcc
           Version: 4.9.2
            Status: UNCONFIRMED
          Severity: minor
          Priority: P3
         Component: libfortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: ludo at gnu dot org

libgfortran/runtime/error.c uses "exit (2)" in a few places to handle run-time
errors.  I would suggest replacing these calls with "abort ()".

The rationale is that using "abort" would make things more convenient for
users: one could inspect the core dump, or, when running the program in GDB,
directly get a prompt upon SIGABRT instead of having to resort to "catch
syscall exit_group".

Thanks.


^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Bug libfortran/63930] libgfortran should use 'abort ()' instead of 'exit (2)' for run-time errors
  2014-11-18 10:37 [Bug libfortran/63930] New: libgfortran should use 'abort ()' instead of 'exit (2)' for run-time errors ludo at gnu dot org
@ 2015-07-05 12:41 ` fxcoudert at gcc dot gnu.org
  2015-07-05 18:52 ` anlauf at gmx dot de
                   ` (3 subsequent siblings)
  4 siblings, 0 replies; 6+ messages in thread
From: fxcoudert at gcc dot gnu.org @ 2015-07-05 12:41 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63930

Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2015-07-05
                 CC|                            |fxcoudert at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #1 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
On the other hand, using exit() guarantees nicely closing the program, closing
files, etc. which is useful to users. abort()'ing is useful for power users,
but probably more confusing for other users: why is it aborting if it already
gave an error message? Bailing out with error message and non-zero error code
seems much more in line with what software generally does.

Using exit() is in line with what other Fortran compilers do for runtime
errors, and we have consistently done that for years, so I would be very
cautious about changing this behavior.


^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Bug libfortran/63930] libgfortran should use 'abort ()' instead of 'exit (2)' for run-time errors
  2014-11-18 10:37 [Bug libfortran/63930] New: libgfortran should use 'abort ()' instead of 'exit (2)' for run-time errors ludo at gnu dot org
  2015-07-05 12:41 ` [Bug libfortran/63930] " fxcoudert at gcc dot gnu.org
@ 2015-07-05 18:52 ` anlauf at gmx dot de
  2015-07-05 18:53 ` anlauf at gmx dot de
                   ` (2 subsequent siblings)
  4 siblings, 0 replies; 6+ messages in thread
From: anlauf at gmx dot de @ 2015-07-05 18:52 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63930

Harald Anlauf <anlauf at gmx dot de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |anlauf at gmx dot de

--- Comment #2 from Harald Anlauf <anlauf at gmx dot de> ---
I think that there is a fundamental need to rewrite the handling of
runtime errors in gfortran.  Since 4.7 I do often not get useful
backtraces with certain kinds of fatal errors like array-bounds
violation, see PR/53739.  I use the patch I suggested there in my
private installations, but this doesn't help my colleagues at work.

I think a fatal runtime error does not require a nice termination
of the program, including closing of files etc.
However, this might require a general review - and classification -
of runtime errors:

- fatal (illegal operations like bad pointers/addresses etc.)
- severe (e.g. failed ALLOCATE?)
- soft (e.g. "file not found" in an OPEN statement)

I'm not sure where I'd place floating point exceptions; their
severity might even be configurable.

(Note: I'm writing this as nobody seems to care about PR/53739).


^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Bug libfortran/63930] libgfortran should use 'abort ()' instead of 'exit (2)' for run-time errors
  2014-11-18 10:37 [Bug libfortran/63930] New: libgfortran should use 'abort ()' instead of 'exit (2)' for run-time errors ludo at gnu dot org
  2015-07-05 12:41 ` [Bug libfortran/63930] " fxcoudert at gcc dot gnu.org
  2015-07-05 18:52 ` anlauf at gmx dot de
@ 2015-07-05 18:53 ` anlauf at gmx dot de
  2015-07-05 20:01 ` kargl at gcc dot gnu.org
  2015-09-04 22:09 ` fxcoudert at gcc dot gnu.org
  4 siblings, 0 replies; 6+ messages in thread
From: anlauf at gmx dot de @ 2015-07-05 18:53 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63930

--- Comment #3 from Harald Anlauf <anlauf at gmx dot de> ---
(In reply to Harald Anlauf from comment #2)
> I think that there is a fundamental need to rewrite the handling of
> runtime errors in gfortran.  Since 4.7 I do often not get useful
> backtraces with certain kinds of fatal errors like array-bounds
> violation, see PR/53739.  I use the patch I suggested there in my
> private installations, but this doesn't help my colleagues at work.
> 
> I think a fatal runtime error does not require a nice termination
> of the program, including closing of files etc.
> However, this might require a general review - and classification -
> of runtime errors:
> 
> - fatal (illegal operations like bad pointers/addresses etc.)
> - severe (e.g. failed ALLOCATE?)
> - soft (e.g. "file not found" in an OPEN statement)
> 
> I'm not sure where I'd place floating point exceptions; their
> severity might even be configurable.
> 
> (Note: I'm writing this as nobody seems to care about PR/53739).

Sorry, that should have been PR 53379.


^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Bug libfortran/63930] libgfortran should use 'abort ()' instead of 'exit (2)' for run-time errors
  2014-11-18 10:37 [Bug libfortran/63930] New: libgfortran should use 'abort ()' instead of 'exit (2)' for run-time errors ludo at gnu dot org
                   ` (2 preceding siblings ...)
  2015-07-05 18:53 ` anlauf at gmx dot de
@ 2015-07-05 20:01 ` kargl at gcc dot gnu.org
  2015-09-04 22:09 ` fxcoudert at gcc dot gnu.org
  4 siblings, 0 replies; 6+ messages in thread
From: kargl at gcc dot gnu.org @ 2015-07-05 20:01 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63930

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kargl at gcc dot gnu.org

--- Comment #4 from kargl at gcc dot gnu.org ---
(In reply to Harald Anlauf from comment #2)
>
> I think that there is a fundamental need to rewrite the handling of
> runtime errors in gfortran.

(snip)

> (Note: I'm writing this as nobody seems to care about PR/53739).

Anything else you want us to do for you?

If it isn't clear from my question, I find your above statement
to be incredibly offensive.  Personally, I think this PR and 
53379 should be closed with WONTFIX.


^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Bug libfortran/63930] libgfortran should use 'abort ()' instead of 'exit (2)' for run-time errors
  2014-11-18 10:37 [Bug libfortran/63930] New: libgfortran should use 'abort ()' instead of 'exit (2)' for run-time errors ludo at gnu dot org
                   ` (3 preceding siblings ...)
  2015-07-05 20:01 ` kargl at gcc dot gnu.org
@ 2015-09-04 22:09 ` fxcoudert at gcc dot gnu.org
  4 siblings, 0 replies; 6+ messages in thread
From: fxcoudert at gcc dot gnu.org @ 2015-09-04 22:09 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63930

Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|---                         |WONTFIX

--- Comment #5 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
Closing this one as WONTFIX: we shouldn't abort() for run-time errors. But we
can print backtraces, which is PR53379, and is about to be fixed.


^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2015-09-04 22:09 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-11-18 10:37 [Bug libfortran/63930] New: libgfortran should use 'abort ()' instead of 'exit (2)' for run-time errors ludo at gnu dot org
2015-07-05 12:41 ` [Bug libfortran/63930] " fxcoudert at gcc dot gnu.org
2015-07-05 18:52 ` anlauf at gmx dot de
2015-07-05 18:53 ` anlauf at gmx dot de
2015-07-05 20:01 ` kargl at gcc dot gnu.org
2015-09-04 22:09 ` fxcoudert at gcc dot gnu.org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).