From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 37895 invoked by alias); 3 Aug 2015 15:40:17 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 37872 invoked by uid 89); 3 Aug 2015 15:40:16 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients X-HELO: smtp24.services.sfr.fr Received: from smtp24.services.sfr.fr (HELO smtp24.services.sfr.fr) (93.17.128.82) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Mon, 03 Aug 2015 15:40:10 +0000 Received: from filter.sfr.fr (localhost [86.72.15.106]) by msfrf2411.sfr.fr (SMTP Server) with ESMTP id 046727000093; Mon, 3 Aug 2015 17:40:07 +0200 (CEST) Authentication-Results: sfrmc.priv.atos.fr; dkim=none (no signature); dkim-adsp=none (no policy) header.from=mikael.morin@sfr.fr Received: from tolstoi.localhost (106.15.72.86.rev.sfr.net [86.72.15.106]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by msfrf2411.sfr.fr (SMTP Server) with ESMTP id 22C067000087; Mon, 3 Aug 2015 17:40:06 +0200 (CEST) X-SFR-UUID: 20150803154006142.22C067000087@msfrf2411.sfr.fr Subject: Re: [Bug fortran/52846] [F2008] Support submodules - part 3/3 To: Paul Richard Thomas References: <55B10B58.9000302@sfr.fr> <00370BD5-507A-42BF-9D59-E868BBAD3C94@sourceryinstitute.org> <55BF4611.70609@sfr.fr> Cc: Damian Rouson , "Bader, Reinhold" , "fortran@gcc.gnu.org" , gcc-patches , "salvatore.filippone@uniroma2.it" From: Mikael Morin Message-ID: <55BF8B43.5030600@sfr.fr> Date: Mon, 03 Aug 2015 15:40:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2015-08/txt/msg00089.txt.bz2 Le 03/08/2015 14:36, Paul Richard Thomas a écrit : > Dear Mikael, > > Thanks for your green light! > > I have been mulling over the trans-decl part of the patch and having > been wondering if it is necessary. You mean marking entities as public? Or setting the hidden visibility attribute? Or both? I think both are necessary. > Without optimization, private > entities can be linked to. Given the discussion concerning the > combination of submodules and private entities, I wonder if this is > not sufficient? Within submodule scope, an advisory could be given for > undefined references to suggest recompiling the module without > optimization or making the entities public. > About recompiling without optimization: If the module contains no code, I guess that would be OK. But otherwise, it would be pretty bad. And one would have to do the same for submodules of a submodule: the parent submodule would be compiled without optimization. :-( About making the entities public: I think the goal of submodules is providing a way to specify a (hopefully) stable interface free of any internal implementation details that users would start playing with if the opportunity was given to them. Making all entities public would go against that. I've been reading about the hidden visibility attribute since you submitted the 3/3 patch(es). I think it's the right thing. :-) Mikael