topic why won't this compile? in Intel® Fortran Compiler

why won't this compile?

WSinc — Sat, 26 May 2012 20:29:14 GMT

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?

why won't this compile?

mecej4 — Sat, 26 May 2012 20:35:45 GMT

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.

why won't this compile?

WSinc — Sat, 26 May 2012 23:38:50 GMT

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.

why won't this compile?

TimP — Sun, 27 May 2012 10:52:34 GMT

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?

why won't this compile?

mecej4 — Sun, 27 May 2012 13:52:59 GMT

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.

why won't this compile?

lklawrie — Sun, 27 May 2012 14:45:06 GMT

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

why won't this compile?

WSinc — Sun, 27 May 2012 15:45:08 GMT

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.

why won't this compile?

TimP — Sun, 27 May 2012 16:04:16 GMT

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.