why won't this compile?

why won't this compile?

billsincl's picture

it teels me the arguments are not compatible, but I don't see why.

When I make the function into a subroutine
there are NO error messages.

Is this a compiler bug?

AttachmentSize
Download test11.f90390 bytes
8 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.
mecej4's picture

The compiler reads the source code that you give it and the messages it gives, if any, correspond to that source code. It does not matter what that source code was formerly, since the compiler sees only the present version.

Perhaps your problem is caused by your use of COUNT as a function name, given that COUNT is an intrinsic function. When you change your function COUNT to a subroutine, the intrinsic function is used where there is a function reference, and the subroutine is not called.

The program will probably give incorrect results if the intrinsic COUNT does not do the same thing as your function COUNT. The compiler may not be able to catch such errors.

billsincl's picture

OK, but why doesn't the source editor ALERT me when I am trying to use an intririnsic function?

Also, if I am using it in a non-standard way, shouldn't it tell me that?

I can easily change the name of the function of course.

TimP (Intel)'s picture

If you think the compiler or editor should relieve you of the responsibility of cracking a book, you could at least check what another compiler tells you:
$ gfortran test11.f90
test11.f90:3.13:

bc = count(b)
1
Error: 'mask' argument of 'count' intrinsic at (1) must be a logical array

Then, if you think the ifort message is too cryptic and you could have learned enough from the gfortran comment without studying EXTERNAL and/or explicit interfaces, you could file a feature request on your premier.intel.com account.

If you're asking for syntax checking in the GUI while entering your program, you really ought to study the conclusions others may have reached on that idea. How many people still use Turbo Pascal?

mecej4's picture

To put it crudely, if the Intel compiler attempted to be a nanny, most professional users would object loudly. There is nothing "nonstandard" about your program, nor does the Fortran standard prohibit you from shooting yourself in the foot.

Current versions of Fortran have so many intrinsic functions and keywords that few people can be expected to remember them all. That is why the keywords, unlike in some other languages, are not reserved. There are almost no restrictions in Fortran on your preempting keywords and intrinsic functions with entities of the same names in user namespace. For example, you can have

REAL :: integer
INTEGER :: real
LOGICAL :: TRUE = .false.

and so forth, if you insist.

The programmer has quite a bit of freedom, and the responsibility to exercise that freedom judiciously.

lklawrie's picture

Your program probably would have compiled had it been in a Module or if you had declared an External for Count.

Linda
billsincl's picture

All I am asking is that it ALERTS us if we try to use an intrinsic function ( in the editor), by using a color code,
in the same way that it does for certain KEY WORDS, like DO or IF. If we use those by accident, we can get all kinds of weird errors that are hard to track down.

Sure, one can crack a book as you put it, but that's sometimes rather inconvenient.

Is that gfortran accesable to all of us? I like it when they are more explicit.

TimP (Intel)'s picture

When making compiler comparisons with Windows gfortran, I use one of the compilers on the cygwin.com setup menu; either the 32-bit cygwin compiler or the 64-bit mingw.

Login to leave a comment.