From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 59294 invoked by alias); 31 Aug 2015 21:12:51 -0000 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 Received: (qmail 59263 invoked by uid 48); 31 Aug 2015 21:12:47 -0000 From: "fxcoudert at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/53379] [4.9/5/6 Regression] No backtrace generated for array bounds violation Date: Mon, 31 Aug 2015 21:12:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: fortran X-Bugzilla-Version: 4.7.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: fxcoudert at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P4 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.9.4 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2015-08/txt/msg02160.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D53379 Francois-Xavier Coudert changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fxcoudert at gcc dot gnu.o= rg --- Comment #22 from Francois-Xavier Coudert = --- (In reply to Joost VandeVondele from comment #21) > Since it is mostly a 'taste' issue when to emit a backtrace or not, I thi= nk > it makes sense to just make it an option flag, either never or always emi= t a > backtrace. The flag '-fbacktrace' already exists and it could imply gener= ate > a backtrace on every 'error termination', run time error, or deadly signa= ls.=20 >=20 > I would find that very useful. I strongly second that. Backtraces are useful for those informed, and can be turned off (or ignored) by the non expert. So, I think every error terminat= ion should print a backtrace. That is: any case where we call abort(), or call exit() with non-zero statu= s. Except, possibly, user-specified non-zero status (like "STOP 42"). PS: Regarding the argument that many runtime errors already indicate the so= urce file and line number for the error, well=E2=80=A6 a backtrace has much more= indication since it indicates the entire code path for the error. >>From gcc-bugs-return-496019-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Aug 31 21:49:48 2015 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 32944 invoked by alias); 31 Aug 2015 21:49:46 -0000 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 Delivered-To: mailing list gcc-bugs@gcc.gnu.org Received: (qmail 32900 invoked by uid 48); 31 Aug 2015 21:49:41 -0000 From: "jb at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/67414] [5 Regression] Error message on failed allocate Date: Mon, 31 Aug 2015 21:49:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: fortran X-Bugzilla-Version: 5.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: jb at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_file_loc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2015-08/txt/msg02161.txt.bz2 Content-length: 570 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67414 Janne Blomqvist changed: What |Removed |Added ---------------------------------------------------------------------------- URL| |https://gcc.gnu.org/ml/gcc- | |patches/2015-08/msg01909.ht | |ml --- Comment #2 from Janne Blomqvist --- Patch: https://gcc.gnu.org/ml/gcc-patches/2015-08/msg01909.html