This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Patch, Fortran] PR33310, PR33284: Add conflicts between PARAMETER and Bind(C); between ENTRY and INTRINSIC
- From: Steve Kargl <sgk at troutmask dot apl dot washington dot edu>
- To: Tobias Burnus <burnus at net-b dot de>
- Cc: "'fortran at gcc dot gnu dot org'" <fortran at gcc dot gnu dot org>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 5 Sep 2007 07:32:08 -0700
- Subject: Re: [Patch, Fortran] PR33310, PR33284: Add conflicts between PARAMETER and Bind(C); between ENTRY and INTRINSIC
- References: <46DEB633.1000702@net-b.de>
On Wed, Sep 05, 2007 at 03:59:15PM +0200, Tobias Burnus wrote:
> :ADDPATCH fortran:
>
> Currently,
> INTEGER, PARAMETER, BIND(C) :: bar = 5
> is accepted (in the specification part of a module). However, this does
> not make sense as "bar" is no variable.
>
> >From the Fortran standard:
>
> "The BIND attribute for a variable or common block specifies that it is
> capable of interoperating with a C variable that has external linkage
> (15.3)."
>
> I would argue that a symbol with a PARAMETER attribute is not a
> "variable" but a "named constant" and thus BIND(C) is invalid.
>
> * * *
>
> SUBROUTINE a
> intrinsic cos
> entry cos(x)
> real x
> x = 0
> end subroutine
>
>
> is accepted. I did not verify this in the standard, but I sincerely
> doubt that a symbol can be both an intrinsic procedure and an entry
> (procedure). Additionally, ifort and NAG f95 agree that this is
> invalid. (ENTRY already conflicts with external, subroutine, procedure,
> function.)
>
> Build and regression tested on x86_64-unknown-linux-gnu with no
> regressions (ignoring the failues at -O3 [c_char_tests.f03 and do_3.F90].)
> OK for the trunk?
>
You forgot to add the patch.
--
Steve