Home > Cannot Change > Cannot Change Attributes Of Use-associated Symbol

Cannot Change Attributes Of Use-associated Symbol

Disallow redeclaration of USE-associated COMMON-block. Is the following code legal? Uncommenting the following statement !! Should a compiler report violations of constraints C1232 and C1233 in these examples? > cat s8.f90 subroutine s8() implicit none interface subroutine weblink

Fix bug with empty common. (var_element): Adapt to new common structures. * match.h (gfc_get_common): Declare. * module.c: Add 2004 to copyright years, add commons to module file layout description. (ab_attribute, attr_bits, Comment 5 Dan Nicolaescu 2004-05-13 23:15:46 UTC > This is marked as rejects-valid, but the line > > COMMON /AN_EXAMPLE/ > > does not look valid at all to me. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.3831&r2=1.3832 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.fortran-torture/compile/name_clash.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1 Comment 12 Tobias Schlüter 2004-06-09 13:09:10 UTC Worked around in the previous commit. John. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57141

Quote:>> 3. Does the standard forbid the use of the "volatile" attribute with a > function result variable (and, if so, where in the document is the > prohibition)? > 3. Not to mention a module, once compiled, should contain all the information necessary for the USE statement. ! causes the error go away !

Is the following code legal? As Paul has pointed out, this is a deeper issue which is also relevant in PR 13575 and PR 13372. Yet gfortran complains the following: > > > > > In file blas.for:5 > > > > >        INTRINSIC SIN > > > >         beginners "let"/"random" question 5.

C USES UNROLLED LOOPS FOR INCREMENTS EQUAL TO ONE. For example, the following (valid) code is rejected: MODULE MOD INTEGER FOO END PROGRAM MAIN USE MOD COMMON /FOO/ BAR END This pattern is common in some spec benchmarks. Thus thanks from the gfortran team. 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.

The error message is not emitted if the declaration of R is uncommented. ! -- test.f90 MODULE M INTRINSIC :: NULL !! Now that I think I can help with. In PR 13575 I outlined a non-invasive solu^H^H^H^Hfix, which might get us working again. In section 11.2.1, the standard seems to say that one can add the "volatile" attribute to the local instance of an entity accessed via host association.

s1.f90 > subroutine s1(x) >     use foo >     real x >     intrinsic sin >     x = sin(x) > end subroutine s1 > > https://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux-and-mac-os-x/topic/270770 foo.f90 module foo real sin end module foo ! 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 ! 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

Added: trunk/gcc/testsuite/gfortran.dg/null_8.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/testsuite/ChangeLog Comment 4 Tobias Burnus 2013-05-05 14:05:04 UTC FIXED on the trunk (GCC 4.9). have a peek at these guys Regarding gfortran, these problems are now tracked as PR30520. causes the error go away ! But no compiler yet claims to fully conform to F2003.

Cheers, Jim From: robert.corbett on 15 Sep 2009 23:48 On Sep 15, 8:15 pm, Hifi-Comp wrote:> I am wondering what INTRINSIC statement does for us. Not a member? If nobody can see why this check is needed, I will submit the patch to remove the check. check over here when i use ifort to compile, I got the error:This array or function or substring is invalid in constant expressions. [NULL] type(ClusterNode),pointer :: son1=>null() !

Yes, I know these workarounds can be awkward in some cases. I don't think that restriction was well thought out. Quote:>> 2.

Is the following code legal? > cat mod13.f90 module mod13 implicit none integer :: v13 end module mod13 > cat mod13a.f90 module

In section 11.2.1, the standard seems to say that one can add the >> "volatile" attribute to the local instance of an entity accessed via >> host association. net | experience comes from bad judgement. You do > not need that line. > > Cheers > Stephan > > > >> >> 2010/9/30 Stephan Kramer > > >> >> >> On The fact that one coule imagine how this > > might make sense doesn't negate the prohibition that Bob cited. > > > -- > > Richard Maine      

I'm >> unable to >> declare the subroutine external inside the module itself, nor in >> the >> program which is using it. URL: Next message: [petsc-users] petsc and meshless type method: Forming parallel coefficient matrix Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] More information When more than one compiler disagrees with my reading of the standard, I tend to doubt myself, so I appreciate the confirmation.--Steve Tue, 14 Jul 2009 13:09:50 GMT Page http://electrictricycle.net/cannot-change/cannot-change-attributes-of-remote-files.html Thanks for finding these bugs - all compiler vendors are glad to have such alert customers which find bugs for them.

Could you take a look please? As a patch is has been posted and thus gfortran will get fixed in the next few days. (There are some special cases, which are not that easily fixable, however, and Comment 13 Tobias Schlüter 2004-06-22 14:03:39 UTC that should be "... Index Nav: [DateIndex] [SubjectIndex] [AuthorIndex] [ThreadIndex] Message Nav: [DatePrev][DateNext] [ThreadPrev][ThreadNext] Other format: [Raw text] [Bug fortran/57141] New: Cannot change attributes of USE-associated intrinsic From: "roger.ferrer at bsc dot es"

You can directly call it from within the module itself. So there is no conflict in their declarations and being brought together into the same scoping unit. REAL, POINTER :: R(:) => NULL() END MODULE M MODULE M_INTERN USE M IMPLICIT NONE REAL, POINTER :: ARR(:) => NULL() END MODULE M_INTERN ! -- end of test.f90 $ gfortran Ronald W Green (Intel) Thu, 05/05/2011 - 10:27 there is not enough context to tell you anything.

such as > > INTRINSIC SIN, COS, ABS > > It seems gfortran and CVF treat this statement differently. Steve Lionel Developer Products Division Intel Corporation Nashua, NH User communities for Intel Software Development Products http://softwareforums.intel.com/ Intel Fortran Support http://developer.intel.com/software/products/support/ My Fortran blog http://www.intel.com/software/drfortran Wed, 08 Jul string.join(["Tk 4.2p2", "Python 1.4", "Win32", "free"], "for") 6. Followup to "Fortran calling "c", and "c" calling Fortran 7.

In f2003, you just omit the keyword "module" and it no longer has the silly restriction. SIN in module test and intrinsic SIN are both generic name, and more important, they're distinguishable. minimum end type ClusterNode 1. ANNOUNCE: new "plus"- and "dash"-patches available for Tcl7.5a2/Tk4.1a2 Powered by phpBB Forum Software INTRINSIC STATEMENT for functions overloaded for user defined types in [Fortran] Prev: reading config fileNext:

Not declaring it external at all >> results in >> the following compilation error: >> >> /net/users/csg/csg4035/master/workdir/src/main.F:97: undefined >> reference >> to `__grid_MOD_readgrid' >> >> (the module is here is named Comment 2 Tobias Burnus 2013-05-03 08:59:48 UTC decl.c's gfc_match_null has: gfc_intrinsic_symbol (sym); if (sym->attr.proc != PROC_INTRINSIC && (!gfc_add_procedure(&sym->attr, PROC_INTRINSIC, sym->name, NULL) || !gfc_add_function (&sym->attr, sym->name, NULL))) return MATCH_ERROR; Failing is the The restriction given is not a constraint and so a Fortran processor is not required to diagnose the nonstandard usage to be standard conformant.