From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29990 invoked by alias); 19 Dec 2016 10:59:37 -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 29973 invoked by uid 89); 19 Dec 2016 10:59:36 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=onlinedocs, There's, Theres, H*r:192.168.100 X-Spam-User: qpsmtpd, 2 recipients X-HELO: mail-wm0-f66.google.com Received: from mail-wm0-f66.google.com (HELO mail-wm0-f66.google.com) (74.125.82.66) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 19 Dec 2016 10:59:26 +0000 Received: by mail-wm0-f66.google.com with SMTP id a20so17947427wme.2; Mon, 19 Dec 2016 02:59:25 -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:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=J1Ps1T2JTUjSV6LM3kQYe5SPOJZ2vs7gnWcD1lJM8RY=; b=pdBYx+HXHgv7X4T50KG/E41jM0KP51znYakV08W2B1YhLbTzOmvnR9ThAPNwHk/JMH gu7/ATSstjvC6QxsnpTASA6PJidebeQ0Nx8sA5FIf04Z9SxvHNsX5kyTsGwEl6vqRW/q Gs6Q30cah5epnh2g8phsNcM1XV4t6Yzs/lFmXa4PHrRLwUz7U9dTQUl8kSW9vGtpqlMy FBEPOr8EHfpl/Z9mgL+jlk9UwiacgR8QPbpS6mWxfJjzkA38RxlCUnU9yUXdMS7qiuoa yvwsfWoYOt1ZqMqz+AMBm+YcN5hwyInxMtEgHIKqwpioLQSbOS2FoOGdQhaiIqv8DQtn J3hA== X-Gm-Message-State: AIkVDXLdo5gy6gRVtYqe6pv/xK7rSLj7z3eBf1aeL/nS5ykdQOlAARNAHfpzofkcSWvXdw== X-Received: by 10.28.111.139 with SMTP id c11mr13907466wmi.139.1482145164236; Mon, 19 Dec 2016 02:59:24 -0800 (PST) Received: from [192.168.100.5] (chp127.enscp.fr. [193.51.253.127]) by smtp.gmail.com with ESMTPSA id w18sm16698657wme.9.2016.12.19.02.59.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Dec 2016 02:59:23 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: [PATCH] Remove unused libgfortran functions From: FX In-Reply-To: Date: Mon, 19 Dec 2016 11:44:00 -0000 Cc: Fortran List , GCC Patches Content-Transfer-Encoding: quoted-printable Message-Id: References: <1481892792-406-1-git-send-email-blomqvist.janne@gmail.com> <09EA6A5E-6461-41BB-9E40-06A33F87C565@gmail.com> To: Janne Blomqvist X-SW-Source: 2016-12/txt/msg01581.txt.bz2 > Yes, I agree (in general, though I was thinking of making the new one > "GFORTRAN_7" to match the release series). Given that there will not be a 1-to-1 mapping of release series with major = ABI versions (hopefully!), I don=E2=80=99t think this is a good idea. It wi= ll make people confused. > 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. Agreed. > 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. Another issue is that we have some documented, user-callable functions that= currently live in the __gfortran_ =E2=80=9Cnamespace=E2=80=9D, e.g. the mi= xed-language routines (https://gcc.gnu.org/onlinedocs/gfortran/Non-Fortran-= Main-Program.html). We want to avoid changing those for no reason, and so f= or consistency I think we should keep everything under __gfortran_=20 FX