From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4755 invoked by alias); 18 Aug 2010 14:41:02 -0000 Received: (qmail 4672 invoked by uid 48); 18 Aug 2010 14:40:41 -0000 Date: Wed, 18 Aug 2010 14:41:00 -0000 Message-ID: <20100818144041.4671.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug fortran/44945] [4.6 Regression] Wrong decl for module vars / FAIL: gfortran.dg/char_array_structure_constructor.f90 In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "mikael 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: 2010-08/txt/msg01468.txt.bz2 ------- Comment #28 from mikael at gcc dot gnu dot org 2010-08-18 14:40 ------- (In reply to comment #27) > This is a very good suggestion. I will have a think about how to implement it > and will come back to you. It is consistent with what I had in mind to improve > the efficiency of module reading. ie. read_module proceeds as follows: > > (i) On encountering a USE statement, look for the module gsym. If it does not > exist, use read_module, as at present, to construct the namespace, without any > exclusions or renames; > (ii) In the current scope, create symtrees using the ONLY and the renames and > point to the symbols in the gsym namespace; > (iii) Subsequent USEs of the same module proceed by using the gsym namespace. Hello, I have been trying a similar approach before. One problem you may encounter is that symbols have non-shareable parts. For examples symbol attributes such as access or use_rename can differ between symbols associated to the same entity. I tried to split gfc_symbol into an entity-specific part and a symbol-specific part but that led to huge changes throughout the frontend and to the associated regressions, so that I eventually gave up. A possible way might be to clone the symbol, and keep a pointer to the original one so that we can get the original backend_decl from it. Maybe you will have a different path and won't encounter this problem at all. Good luck anyway, that seems the way to go :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44945