From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18632 invoked by alias); 28 Apr 2008 16:42:42 -0000 Received: (qmail 18410 invoked by uid 48); 28 Apr 2008 16:41:56 -0000 Date: Mon, 28 Apr 2008 16:42:00 -0000 Message-ID: <20080428164156.18408.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug libfortran/36044] user-requested backtrace In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "burnus at gcc dot gnu dot org" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2008-04/txt/msg02006.txt.bz2 ------- Comment #3 from burnus at gcc dot gnu dot org 2008-04-28 16:41 ------- > > I think compiling with -fbacktrace and calling the STOP intrinsic should > > emit a backtrace. I think it should not. For abort(), I think a backtrace is ok, but for STOP there should be no backtrace. Using stop is a quite normal way to stop a program because a condition has not be met, e.g stop 'Could not file "inp"' If one finds afterwards dozens of lines of backtrace the actual message is no longer visible. In my opinion, ifort shows too often a backtrace. > I don't think it does. Try abort(). (Though I do not recall whether it works, I think it does.) > Anyway I'm looking for a solution that keeps the > program running after the backtrace. This can be sometimes indeed be handy, though I have never used it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36044