This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: [PATCH] Remove unused libgfortran functions
- From: Steve Kargl <sgk at troutmask dot apl dot washington dot edu>
- To: Janne Blomqvist <blomqvist dot janne at gmail dot com>
- Cc: FX <fxcoudert at gmail dot com>, Fortran List <fortran at gcc dot gnu dot org>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Fri, 16 Dec 2016 10:50:21 -0800
- Subject: Re: [PATCH] Remove unused libgfortran functions
- Authentication-results: sourceware.org; auth=none
- References: <1481892792-406-1-git-send-email-blomqvist.janne@gmail.com> <09EA6A5E-6461-41BB-9E40-06A33F87C565@gmail.com> <CAO9iq9HxAG3TK=NiH+4i_u7PyCj8-6e+r5hfDbLY4ohUdq5wQQ@mail.gmail.com>
- Reply-to: kargl at uw dot edu
On Fri, Dec 16, 2016 at 07:46:01PM +0200, Janne Blomqvist wrote:
> On Fri, Dec 16, 2016 at 4:02 PM, FX <fxcoudert@gmail.com> wrote:
> > A few questions:
> >
> > 1. Regarding gfortran.map, shouldn’t we just flatten out all the 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.
That's an interessting question. All of the intrinsic subprogams
in Section 13 of the standard are required by the implementation.
This suggests that _GFortran should be used. The Fortran standard
does allow a processor to supply additional intrinsic subprograms
beyond those in Section 13 (e.g., all of the g77 compatibility
routines). I think we should simply use the same prefix. I'll
leave the choice to whoever does the work. :-)
--
Steve