From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 96164 invoked by alias); 16 Dec 2016 17:46:07 -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 96123 invoked by uid 89); 16 Dec 2016 17:46:04 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=painful, sk:fxcoude, fxcoudertgmailcom, U*fxcoudert X-Spam-User: qpsmtpd, 2 recipients X-HELO: mail-yb0-f178.google.com Received: from mail-yb0-f178.google.com (HELO mail-yb0-f178.google.com) (209.85.213.178) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 16 Dec 2016 17:46:03 +0000 Received: by mail-yb0-f178.google.com with SMTP id v78so41072618ybe.3; Fri, 16 Dec 2016 09:46:02 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=3czy33gGBSDQSLa1hzm7Y5OBUjMKNF06qukElm6BLGA=; b=ixVkJsBtoaQi1+CZORkXl/u3u+2B821RAqr0MKbJjxP0cCggrNVhrEXltsNIxizIRl dKVl3/H00h6UCOMUbV5Q7tfYwHo+ESqU91FV+zgyYlgUmXFl6cHCLHZU23/V1mgrGWxJ vv10Efu6cGfyM5Cd+g41cmNijuLNabrAnvjMOZarlzOPwRpy4hNKeMlYn0KPKhzORORY jhfXxNRtgc6SFTuc5SFEb1I9k34N26gKV1YUMuqMlBhxK0kiWpMOfoyloKrtlh+XjX/c +wG2+iYAr6BGCs59hIRVHPMibR2izO48g5giFhD4PT7s1PmRSV7X2T2mmYUX48w7pjVp mvFg== X-Gm-Message-State: AIkVDXIEJFxjVn88xO8s9AwvSQXMo+/g4YIqw/2m8iRum+mc1NUYzPH4zg6F4FqJPXHqewmXjrb6/oy2YuptYg== X-Received: by 10.37.24.11 with SMTP id 11mr3106725yby.1.1481910361507; Fri, 16 Dec 2016 09:46:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.160.104 with HTTP; Fri, 16 Dec 2016 09:46:01 -0800 (PST) In-Reply-To: <09EA6A5E-6461-41BB-9E40-06A33F87C565@gmail.com> References: <1481892792-406-1-git-send-email-blomqvist.janne@gmail.com> <09EA6A5E-6461-41BB-9E40-06A33F87C565@gmail.com> From: Janne Blomqvist Date: Fri, 16 Dec 2016 17:46:00 -0000 Message-ID: Subject: Re: [PATCH] Remove unused libgfortran functions To: FX Cc: Fortran List , GCC Patches Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2016-12/txt/msg01501.txt.bz2 On Fri, Dec 16, 2016 at 4:02 PM, FX wrote: > A few questions: > > 1. Regarding gfortran.map, shouldn=E2=80=99t we just flatten out all th= e symbols from GFORTRAN_1.0 to GFORTRAN_1.7 into a single new GFORTRAN_2.0 = group (while removing the ones we are getting rid of)? Yes, I agree (in general, though I was thinking of making the new one "GFORTRAN_7" to match the release series). There's also other things, like e.g. ISO_C_BINDING helper functions living under the __iso_c_binding namespace, instead of under _gfortran like everything else. And while we're at it, should we place everything under "__gfortran" or "_GFortran", that is, with two underscores or one underscore followed by a capital letter which in the C world is reserved for the implementation? Though it's not clear to me whether libgfortran can claim to be part of "the implementation" vs. being generic user code. > 2. While we are breaking the ABI, shouldn=E2=80=99t we reorder the arra= y argument to the libgfortran_set_options to remove unused fields? Hmm, yes, probably. Can you add it to the libgfortranAbiCleanup page on the wiki. Or better yet, get cracking, there's a lot to do.. ;-/ > 3. What will happen to people who try to run older compiled codes with = newer library versions? Will it fail with an error message? Segfault? Do we= have a way to make it fail in a better way? It won't work, since old binaries are linked against libgfortran.so.3, and GFortran 7 will provide libgfortran.so.4. But of course, you can have both the so.3 and so.4 installed in parallel. The problem occurs, say, when you have lib A that links against so.3 and lib B that links against so.4, and your application wants to use both. In particular if one or both of libs A and B are proprietary libs and you can't recompile them against the same so version.. But also for the free software world, these rebuild the world transitions tend to be painful, which is why we have been so careful to not needlessly break the ABI. But now it seems we'll have such an ABI transition both for GCC 7 and 8, but that's another story.. :( --=20 Janne Blomqvist