Prev: reading config file
Next: IMSL, NAG Fortran Library vs. Open Source libraries
From: Hifi-Comp on 15 Sep 2009 23:15
I am wondering what INTRINSIC statement does for us. such as

INTRINSIC SIN, COS, ABS

It seems gfortran and CVF treat this statement differently. For a code
containing three files:

test1.f90
PROGRAM Main
USE TEST

TYPE (DN)::DX
DX=DN(1.0D0,1.0D0)
write(*,*) SIN(DX)

END PROGRAM Main

DNAD.f90
MODULE TEST

TYPE,PUBLIC:: DN
REAL(8)::x
REAL(8)::xp
END TYPE DN

PUBLIC SIN
INTERFACE SIN
MODULE PROCEDURE SIN_D ! obtain sine of a dual number, ELEMENTAL
END INTERFACE

CONTAINS

ELEMENTAL FUNCTION SIN_D(u) RESULT(res)
TYPE (DN), INTENT(IN)::u
TYPE (DN)::res

res%x = SIN(u%x)
res%xp= u%xp*COS(u%x)

END FUNCTION SIN_D

END MODULE TEST

blas.for

FUNCTION DDOT(N,DX,INCX,DY,
+INCY)
USE TEST
TYPE (DN) DDOT
INTRINSIC SIN

C
C FORMS THE DOT PRODUCT OF TWO VECTORS.
C USES UNROLLED LOOPS FOR INCREMENTS EQUAL TO ONE.
C JACK DONGARRA, LINPACK, 3/11/78.
C
TYPE (DN) DX(*),DY(*),DTEMP
INTEGER I,INCX,INCY,IX,IY,M,MP1,N
60 DDOT = DTEMP
RETURN
END

CVF can successfully compile it. Yet gfortran complains the following:

In file blas.for:5

INTRINSIC SIN
1
Error: Cannot change attributes of USE-associated symbol at (1)


From: Jim Xia on 15 Sep 2009 23:31

> CVF can successfully compile it. Yet gfortran complains the following:
>
> In file blas.for:5
>
>        INTRINSIC SIN
>                    1
> Error: Cannot change attributes of USE-associated symbol at (1)

This looks like a bug in gfortran. SIN in module test and intrinsic
SIN are both generic name, and more important, they're
distinguishable. So there is no conflict in their declarations and
being brought together into the same scoping unit.

Cheers,

Jim
From: robert.corbett on 15 Sep 2009 23:48
On Sep 15, 8:15 pm, Hifi-Comp <wenbinyu.hea...(a)gmail.com> wrote:
> I am wondering what INTRINSIC statement does for us. such as
>
> INTRINSIC SIN, COS, ABS
>
> It seems gfortran and CVF treat this statement differently. For a code
> containing three files:
>
> test1.f90
> PROGRAM Main
> USE TEST
>
> TYPE (DN)::DX
> DX=DN(1.0D0,1.0D0)
> write(*,*) SIN(DX)
>
> END PROGRAM Main
>
> DNAD.f90
> MODULE TEST
>
> TYPE,PUBLIC:: DN
> REAL(8)::x
> REAL(8)::xp
> END TYPE DN
>
> PUBLIC SIN
> INTERFACE SIN
> MODULE PROCEDURE SIN_D ! obtain sine of a dual number, ELEMENTAL
> END INTERFACE
>
> CONTAINS
>
> ELEMENTAL FUNCTION SIN_D(u) RESULT(res)
> TYPE (DN), INTENT(IN)::u
> TYPE (DN)::res
>
> res%x = SIN(u%x)
> res%xp= u%xp*COS(u%x)
>
> END FUNCTION SIN_D
>
> END MODULE TEST
>
> blas.for
>
> FUNCTION DDOT(N,DX,INCX,DY,
> +INCY)
> USE TEST
> TYPE (DN) DDOT
> INTRINSIC SIN
>
> C
> C FORMS THE DOT PRODUCT OF TWO VECTORS.
> C USES UNROLLED LOOPS FOR INCREMENTS EQUAL TO ONE.
> C JACK DONGARRA, LINPACK, 3/11/78.
> C
> TYPE (DN) DX(*),DY(*),DTEMP
> INTEGER I,INCX,INCY,IX,IY,M,MP1,N
> 60 DDOT = DTEMP
> RETURN
> END
>
> CVF can successfully compile it. Yet gfortran complains the following:
>
> In file blas.for:5
>
> INTRINSIC SIN
> 1
> Error: Cannot change attributes of USE-associated symbol at (1)

The function DDOT is not standard conformant.Section 11.2.1 of the
Fortran 2003 standard states

The local identifier of an entitymade accessible by a
USE statement shall not appear in any other
nonexecutable statement that would cause any attribute
(5.1.2) of the entity to be specified in the scoping
unit that contains the USE statement, except that it
may appear in a PUBLIC or PRIVATE statement in the
scoping unit of a module and it may be given the
ASYNCHRONOUS or VOLATILE attribute.

The restriction given is not a constraint and so a Fortran
processor is not required to diagnose the nonstandard usage
to be standard conformant.

Bob Corbett
From: steve on 16 Sep 2009 13:25
On Sep 16, 4:11 am, Hifi-Comp <wenbinyu.hea...(a)gmail.com> wrote:
> On Sep 16, 2:25 am, nos...(a)see.signature (Richard Maine) wrote:
>
>
>
> > Jim Xia <jim...(a)hotmail.com> wrote:
> > > > CVF can successfully compile it. Yet gfortran complains the following:
>
> > > > In file blas.for:5
>
> > > >        INTRINSIC SIN
> > > >                    1
> > > > Error: Cannot change attributes of USE-associated symbol at (1)
>
> > > This looks like a bug in gfortran.  SIN in module test and intrinsic
> > > SIN are both generic name, and more important, they're
> > > distinguishable.  So there is no conflict in their declarations and
> > > being brought together into the same scoping unit.
>
> > I disagree. See Bob's citation. The fact that one coule imagine how this
> > might make sense doesn't negate the prohibition that Bob cited.
>
> > --
> > Richard Maine                    | Good judgment comes from experience;
> > email: last name at domain . net | experience comes from bad judgment.
> > domain: summertriangle           |  -- Mark Twain
>
> Why this prohibition?

Richard can probably answer this better than I; as he was a member of
J3 and editor for the F95/2003 standard. A blank prohibition would
remove the need for placing constraints, possibly hundreds of
constraints,
throughout the standard. Not to mention a module, once compiled,
should
contain all the information necessary for the USE statement.

! foo.f90
module foo
real sin
end module foo

! s1.f90
subroutine s1(x)
use foo
real x
intrinsic sin
x = sin(x)
end subroutine s1

! s2.f90
subroutine s2(x)
use foo
real x
external sin
x = sin(x)
end subroutine s2

!sin.f90
function sin(x)
real sin
real x
sin = x
end function sin

! z.f90
program z
use foo
real x
x = sin(x)
end program z

gfc -o z foo.f90 s1.f90 s2.f90 z.f90 sin.f90
gfc -o z foo.f90 s2.f90 s1.f90 z.f90 sin.f90

Which sin is USEd in program z given the two command lines?


>How one can get around of this with a possible
> automatic change to the original source?

Don't use 'INTRINSIC SIN' in this code. It doesn't do what you
think it does.

--
steve
From: Hifi-Comp on 16 Sep 2009 21:28
On Sep 16, 1:25 pm, steve <kar...(a)comcast.net> wrote:
> On Sep 16, 4:11 am, Hifi-Comp <wenbinyu.hea...(a)gmail.com> wrote:
>
>
>
>
>
> > On Sep 16, 2:25 am, nos...(a)see.signature (Richard Maine) wrote:
>
> > > Jim Xia <jim...(a)hotmail.com> wrote:
> > > > > CVF can successfully compile it. Yet gfortran complains the following:
>
> > > > > In file blas.for:5
>
> > > > >        INTRINSIC SIN
> > > > >                    1
> > > > > Error: Cannot change attributes of USE-associated symbol at (1)
>
> > > > This looks like a bug in gfortran.  SIN in module test and intrinsic
> > > > SIN are both generic name, and more important, they're
> > > > distinguishable.  So there is no conflict in their declarations and
> > > > being brought together into the same scoping unit.
>
> > > I disagree. See Bob's citation. The fact that one coule imagine how this
> > > might make sense doesn't negate the prohibition that Bob cited.
>
> > > --
> > > Richard Maine                    | Good judgment comes from experience;
> > > email: last name at domain . net | experience comes from bad judgment..
> > > domain: summertriangle           |  -- Mark Twain
>
> > Why this prohibition?
>
> Richard can probably answer this better than I; as he was a member of
> J3 and editor for the F95/2003 standard.  A blank prohibition would
> remove the need for placing constraints, possibly hundreds of
> constraints,
> throughout the standard.  Not to mention a module, once compiled,
> should
> contain all the information necessary for the USE statement.
>
> ! foo.f90
> module foo
>    real sin
> end module foo
>
> ! s1.f90
> subroutine s1(x)
>     use foo
>     real x
>     intrinsic sin
>     x = sin(x)
> end subroutine s1
>
> ! s2.f90
> subroutine s2(x)
>    use foo
>    real x
>    external sin
>    x = sin(x)
> end subroutine s2
>
> !sin.f90
> function sin(x)
>    real sin
>    real x
>    sin = x
> end function sin
>
> ! z.f90
> program z
>     use foo
>     real x
>     x = sin(x)
> end program z
>
> gfc -o z foo.f90 s1.f90 s2.f90 z.f90 sin.f90
> gfc -o z foo.f90 s2.f90 s1.f90 z.f90 sin.f90
>
> Which sin is USEd in program z given the two command lines?
>
> >How one can get around of this with a possible
> > automatic change to the original source?
>
> Don't use 'INTRINSIC SIN' in this code.  It doesn't do what you
> think it does.
>
> --
> steve- Hide quoted text -
>
> - Show quoted text -

What INTRINSIC does for us in addition to pass a procedure name as an
argument?
 |  Next  |  Last
Pages: 1 2 3
Prev: reading config file
Next: IMSL, NAG Fortran Library vs. Open Source libraries