From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4814 invoked by alias); 25 Feb 2002 00:41:11 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 4735 invoked from network); 25 Feb 2002 00:41:09 -0000 Received: from unknown (HELO cygnus.com) (205.180.230.5) by sources.redhat.com with SMTP; 25 Feb 2002 00:41:09 -0000 Received: from cse.cygnus.com (cse.cygnus.com [205.180.230.236]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id QAA14297; Sun, 24 Feb 2002 16:41:07 -0800 (PST) Received: from free.redhat.lsd.ic.unicamp.br (vpnuser.sfbay.redhat.com [10.255.17.130] (may be forged)) by cse.cygnus.com (8.8.8+Sun/8.6.4) with ESMTP id QAA21929; Sun, 24 Feb 2002 16:41:04 -0800 (PST) Received: (from aoliva@localhost) by free.redhat.lsd.ic.unicamp.br (8.11.6/8.11.6) id g1P0f3R20685; Sun, 24 Feb 2002 21:41:03 -0300 To: gcc-patches@gcc.gnu.org, gcc@gcc.gnu.org Subject: Re: Test distilled from -gdwarf-2 -O3 bootstrap failure References: From: Alexandre Oliva Organization: GCC Team, Red Hat Date: Sun, 24 Feb 2002 18:03:00 -0000 In-Reply-To: Alexandre Oliva's message of "24 Feb 2002 13:59:27 -0300" Message-ID: User-Agent: Gnus/5.0805 (Gnus v5.8.5) Emacs/20.7 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-SW-Source: 2002-02/txt/msg01444.txt.bz2 --=-=-= Content-length: 2746 On Feb 24, 2002, Alexandre Oliva wrote: > I'm going to try and debug this problem, so this is just a heads up. Ok, I've figured out what's going on. In the first round of expanding C bodies, f3() is deemed too big to be tree-inlined, so generation of RTL is not deferred for it, but generation of assembly is. f4() is compiled to RTL and then assembly is generated for it, because it's referenced (by itself :-(, so f3() has to be emitted out-of-line because it couldn't be inlined. In the second round(), we generate RTL for f1() and f2(), but they are never emitted because they are inlined. After generating assembly for f3(), however, we get in trouble because: - the inlined block from f1() contains the statement expression passed as an argument from f2 - the block copied from f1() was marked as ABSTRACT when we started generating debugging info for the inlined f2: dwarf2out_abstract_function() set the abstract flag in all blocks within f2, irregardless of whether they came from other functions. I tried to skip blocks from f1(), but then we'd try to expand the initializer of its argument and lose. It appears to me that we should be emitting debugging info for f1() just like for f2(), but the test for the block abstractness prevents that: blocks of inlined functions into inlined functions will always be marked as abstract. I'm now testing two different patches for the problem. The first removes the test for abstractness of the block; the second simply arranges for us to generate declarations of the block. The latter is enough to prevent the crash, and it seems reasonable under the principle that, if we don't generate debugging info for the whole block, we must at least generate it for the initializers of the parameters, as we'd have done had we not chosen to generate debugging info for the function. However, it appears to me that the former should be the right approach, since I don't see why handling f1 should be any different from f2. We might emit more debugging info than necessary, though (but I'm not really sure about it). Anyhow, it actually fails to bootstrap, as some labels referenced in the debugging info don't make it to the output. So I'm leaning towards the second patch, but if others agree the former would be better, I'll dig deeper :-) For reference, here's the testcase I'm going to install in gcc.dg/debug (thanks Jakub!) as soon as a patch for the bug is approved, and the two candidate patches I'm testing (the first one actually fails to bootstrap, while the second is doing well, but I have doubts as to the correctness of the generated info). ChangeLog entries missing because this is not a patch submission, just a RFC. So... any comments? --=-=-= Content-Type: text/x-c Content-Disposition: inline; filename=20020224-1.c Content-length: 686 /* { dg-do compile } */ #define UNUSED __attribute__((unused)) #define EXT __extension__ int undef(void); inline static void f1 (int i UNUSED) { } inline static void f2 (void) { f1 (EXT ({ int t1 UNUSED; undef (); })); } inline static void f3 (void) { int v1 UNUSED; int v2 UNUSED; EXT ({ int t2 UNUSED; if (0) undef (); 0; }) && EXT ({ int t3 UNUSED; if (0) undef (); 0; }); if (1) { undef (); if (1) f2 (); } { undef (); } } inline static void f4 (void) { EXT ({ undef (); 1; }) && EXT ({ int t4 UNUSED = ({ 1; }); 1; }); { } EXT ({ int t5 UNUSED; if (0) undef (); 0; }); f4 (); undef (); f3 (); return; } --=-=-= Content-Type: text/x-patch Content-Disposition: inline; filename=dwarf2-inlined-full.patch Content-length: 556 Index: gcc/dwarf2out.c =================================================================== RCS file: /home/aoliva/cygnus/uberbaum/gcc/dwarf2out.c,v retrieving revision 1.356 diff -u -p -r1.356 dwarf2out.c --- gcc/dwarf2out.c 21 Feb 2002 23:03:14 -0000 1.356 +++ gcc/dwarf2out.c 25 Feb 2002 00:14:58 -0000 @@ -10554,7 +10554,7 @@ gen_inlined_subroutine_die (stmt, contex dw_die_ref context_die; int depth; { - if (! BLOCK_ABSTRACT (stmt)) + if (1) { dw_die_ref subr_die = new_die (DW_TAG_inlined_subroutine, context_die, stmt); --=-=-= Content-Type: text/x-patch Content-Disposition: inline; filename=dwarf2-inlined-decls.patch Content-length: 590 Index: gcc/dwarf2out.c =================================================================== RCS file: /home/aoliva/cygnus/uberbaum/gcc/dwarf2out.c,v retrieving revision 1.356 diff -u -p -r1.356 dwarf2out.c --- gcc/dwarf2out.c 21 Feb 2002 23:03:14 -0000 1.356 +++ gcc/dwarf2out.c 25 Feb 2002 00:06:30 -0000 @@ -10574,6 +10574,8 @@ gen_inlined_subroutine_die (stmt, contex decls_for_scope (stmt, subr_die, depth); current_function_has_inlines = 1; } + else + decls_for_scope (stmt, context_die, depth); } /* Generate a DIE for a field in a record, or structure. */ --=-=-= Content-length: 289 -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Red Hat GCC Developer aoliva@{cygnus.com, redhat.com} CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org} Free Software Evangelist Professional serial bug killer --=-=-=--