This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug fortran/20248] gfortran: intrinsics and std=f95, inconsistency with other compilers
- From: "anlauf at hep dot tu-darmstadt dot de" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 28 Feb 2005 22:11:01 -0000
- Subject: [Bug fortran/20248] gfortran: intrinsics and std=f95, inconsistency with other compilers
- References: <20050228131630.20248.anlauf@hep.tu-darmstadt.de>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Additional Comments From anlauf at hep dot tu-darmstadt dot de 2005-02-28 22:11 -------
But is it consistently handled as an intrinsic?
Modify the program by adding the line
intrinsic :: iargc
and compile without -std=f95.
Now the name gets mapped to _gfortran_iargc, which is reasonable.
If I declare it as external, then it becomes iargc_. So far so good.
Adding -std=f95 makes the compilation fail with the error message
In file iargc.f90:3
integer :: iargc
1
Error: Intrinsic at (1) does not exist
but only if iargc is declared as intrinsic.
Thus, a symbol that is _neither_ declared as intrinsic nor external
can change its behavior under the language level flag: it is mapped
to the intrinsic name in one case (no -std=f95), and to the
external name in the other.
This is why I consider it surprising and undesirable.
A better way would be to have a separate flag to control
the behavior and availability of such intrinsics separately,
independent of the standard conformance flags.
--
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |UNCONFIRMED
Resolution|INVALID |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20248