From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22407 invoked by alias); 8 Sep 2008 15:31:28 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 22394 invoked by uid 22791); 8 Sep 2008 15:31:24 -0000 X-Spam-Status: No, hits=3.4 required=5.0 tests=AWL,BAYES_05,BOTNET,KAM_MX,RDNS_DYNAMIC,SPF_FAIL X-Spam-Check-By: sourceware.org Date: Mon, 08 Sep 2008 15:31:00 -0000 From: Jan Kratochvil To: Sami Wagiaalla Cc: Project Archer Subject: Re: using directive patch Message-ID: <20080908153043.GA17506@host0.dyn.jankratochvil.net> References: <48BED230.1070209@redhat.com> <20080907183612.GA7304@host0.dyn.jankratochvil.net> <48C5418C.8060300@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48C5418C.8060300@redhat.com> User-Agent: Mutt/1.5.18 (2008-05-17) X-SW-Source: 2008-q3/txt/msg00186.txt.bz2 On Mon, 08 Sep 2008 17:15:24 +0200, Sami Wagiaalla wrote: >> I expect that after fixing this GCC Bug the testcase included below (*1) will >> fail due to the line `using_directives = NULL;' in finish_block() - IMO it >> should restore (not reset) the original using-directives context. Due to the >> GCC Bug the GDB Bug is not reproducible. > > Come to think of it I dont think that the line `using_directives = > NULL;' is needed in finish_block(), but but I thought that the context > is restored by the caller in this case, as the caller is the one who > 'pops' the context (like the line 'using_directives = > new->using_directives;' in read_func_scope). Same should be done for > read_lexical_block_scope. Is this correct ? I do not want to comment more without having a right DWARF at hand (either by fixed GCC PR 37410 or fixed up for one testcase by hand). Roughly I think using_directives should be rather updatedalready in pop_context(). Moreover the variables local_symbols, param_symbols and using_directives should be replaced by direct references to current context_stack[context_stack_depth] (as suggested by Tom T.). But such cleanup I find as an unrelated patch (which this namespaces fix may make sense to have dependent on). Regards, Jan