To avoid confusion it is best to add the save attribute to such locally initialized variables explicitly, even though this is redundant. GCC Bugzilla – Bug13249 Error when using COMMON Last modified: 2004-06-22 14:03:39 UTC Home | New | Browse | Search | [?] | Reports | Help | NewAccount | Log In s1.f90 > subroutine s1(x) > use foo > real x > intrinsic sin > x = sin(x) > end subroutine s1 > > subroutine second_sub(i,a) integer :: i real :: a ... this contact form
This is not a problem in Fortran 95 which allows one to nullify a pointer on declaration. Richard can probably answer this better than I; as he was a member of J3 and editor for the F95/2003 standard. Disallow redeclaration of USE-associated COMMON-block. Leo 2010/10/1 Stephan Kramer
Subtle danger with overloading (=) to assign pointers One must be careful with overloading the assignment operator. I'll check that out and see how it works. John. The restriction given is not a constraint and so a Fortran processor is not required to diagnose the nonstandard usage to be standard conformant.
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 if (first_entry) then nullify(local_table) ; first_entry = .false. On some compilers it is possible to set the record length as follows: open(unit=6, recl = 2147483646) On other compilers unit 6 is preconnected and the record length cannot be changed. For many compilers the default record length is very large (e.g., 2147483647) giving the appearance of stream I/O.
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)? > cat fcn.f90 function No, IMHO. 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 Example: Code: PGI$ cat testm.f90 MODULE TESTM TYPE A_TYPE INTEGER :: AN_INT END TYPE A_TYPE COMMON /acommon/ A, B TYPE(A_TYPE) :: A, B !DEC$ ATTRIBUTES DLLEXPORT :: /acommon/ CONTAINS SUBROUTINE PRINT_A
Yet gfortran complains the following: > > > > > > In file blas.for:5 > > > > > > INTRINSIC SIN > > > > > Is the following code legal? Format For Printing -XML -Clone This Bug -Top of page Home | New | Browse | Search | [?] | Reports | Help | NewAccount | Log In Remember [x] | Open Source libraries Technology PGI Unified Binary MPI Debugging PGI Accelerator with OpenACC Common Compiler Feedback Format CUDA Fortran CUDA-x86 Products HPC Products PGI Workstation PGI Server PGI CDK Cluster Development
THIS IS WRONG call incb(x) print *, x end program main subroutine incb(a) ! weblink Allocatable arrays require the user to manually create and delete them, and should only be used if automatic creation and deletion is not the desired behavior. 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 Removing the call to check_used apparently fixes the problem and does not cause regressions, BUT I guess it is there for a purpose...
net | experience comes from bad judgment.. > > > domain: summertriangle | -- Mark Twain > > > Why this prohibition? > > Richard can This is false. C USES UNROLLED LOOPS FOR INCREMENTS EQUAL TO ONE. http://birdsallgraphics.com/error-cannot/error-cannot-change-visible-in-onshow-or-onhide.php See platt.f90 and truss.f90.
See Bob's citation. THIS IS THE RIGHT WAY interface subroutine incb(a) real, dimension(:) :: a end subroutine incb end interface x = 0. I forgot to add the correct files to the makefile, for I put the module in a seperate file (grid.F).
Thanks for the report! 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 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. real function kinetic_energy(v) real, dimension(:), intent(in) :: v integer i !
net | experience comes from bad judgement. once pr15481 is fixed." Comment 14 CVS Commits 2004-06-29 18:56:50 UTC Subject: Bug 13249 CVSROOT: /cvs/gcc Module name: gcc Changes by: firstname.lastname@example.org 2004-06-29 18:56:47 Modified files: gcc/fortran : decl.c dump-parse-tree.c gfortran.h In James' words: "Notice that for this to really work, the actual argument, 'a', must be declared with the target attribute. http://birdsallgraphics.com/error-cannot/error-cannot-change-visible-onshow-onhide.php In this example, it is permitted to leave out the interface altogether since routines without interfaces are treated as Fortran77 style routines by default.
Unify with traverse_symtree. (gfc_traverse_ns): Call gfc_traverse_symtree according to new interface. (save_symbol): Remove setting of removed attribute. * trans-common.c (gfc_sym_mangled_common_id): Change to take 'char *' argument instead of 'gfc_symbol'. (build_common_decl, new_segment, translate_common): associated(local_table)) then allocate(local_table(size(this))) endif local_table = ... ... Thanks. Mon, 06 Jul 2009 06:32:38 GMT Michael Metcal#2 / 5 Questions about Fortran 2003 "volatile" From John Reid: Quote:>> 1.
Should a compiler report violations of constraints C1232 and C1233 in these examples? > cat s8.f90 subroutine s8() implicit none interface subroutine Furthermore, to simplify the syntax one might be tempted to use an overloaded assignment operator (=). Pointers are the most error prone and should only be used when allocatable arrays are not possible, e.g., when one desires an array to be a component of a derived type. THIS IS ANOTHER RIGHT WAY module inc contains subroutine incb(a) !
Danger with interfaces to Fortran 77 subroutines program main real, dimension(5) :: x ! 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.