INTEGER*N statements

INTEGER*N statements

Are statements such as INTEGER*1, INTEGER*2, ... allowed by INTEL FORTRAN?

9 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.



Steve - Intel Developer Support


I'm sorry for my last post. The problem stemmed from the number of continuation lines exceeding whatever the short limit is in Intel FORTRAN. Somewhere near 100 .. probably 96. I can't find a switch to increase the number of continuation lines which is a bear when rehosting someone else's code. I think the number has been increased to 512 in an 8 beta version but I can't set a development environment based on a beta.

Thanks again for the response.

Yes, ifc 7.1 limits continuations to 99.

I would suggest finding a way to not need so many continuations, as this can cause portability problems. The standard says 19 for fixed form, 39 for free-form.


Steve - Intel Developer Support

Unfortunately, it is not my code. We are rehosting existing ages old flight simulation code (real flight simulators for the Marines not the Microsoft stuff .. lol) that ran on a SGI to a pc running Linux. The Linux kernel has been patched to allow CPU restriction. The original authors liked to use one line per entry in
common statements. I doubled up the entries and have gotten around the problem.

I'm about halfway through the rehost and haven't encountered any other probs so your FORTRAN seems to work ok at least until we actually execute the code. Your FORTRAN links without probs so far with gnat Ada, g++, and gcc. I use gnatmake as the linker with --LINK=c++ without any unresolves in the FORTRAN realm so things look OK unless I am missing something.

I've rehosted several thousand lines of code to Intel FORTRAN - Linux. I've found two things that are a downer.

1. The limit on continuation lines regardless of what the spec says. Other FORTRAN's have extensions that bypass that spec.

2. Intrinsic generics such as IAND don't assume that a constant parameter is the same data type as the other parameter. For instance, IAND(JINT2VAR, 5) bombs because the compiler doesn't recognize 5 as an INT2 constant.

I know these are petty but I've done a major rehost and am just letting you know what are the pains.

The next major release of the compiler will allow up to 511 continuation lines. ifc goes way beyond the standard here, but apparently you want even more! :-)

In your IAND case, 2 isn't an INT2 constant - the standard says it's "default integer". However, the next major release will allow this combination as an extension.

I will comment that you should try to stick to standard-conforming code where you can. Relying on extensions can get you into trouble, especially if a vendor implements an extension different from what you expect. If you're using non-default kinds, the generally accepted way of doing this is to declare PARAMETER constants that define the kind values, and then use the kind values in the code, for example:

integer, parameter :: int2 = selected_int_kind(4)
integer(int2) :: i,j
j = iand(i,2_int2)


Steve - Intel Developer Support

You hit the nail on the head there Steve in sticking to the standards. I've been doing this for 25 years and am pretty anal (can I say that online?) about standards. Even down to the number of spaces for indents which is a company standard.

However, a lot of stuff, especially in flight simulation, gets rehosted nowadays to Linux PC's from the Gould/Harris/SGI/VAX(ugh) mini's of 15 years ago. Your upcoming extensions will be nice for those projects.

New projects ... I suggest, as Steve suggests, do not use extensions ... Learn to type and spend the extra 2 percent effort and avoid problems down the line.

I will say that I sympathize with those porting old code that worked on F77 compilers but not with F90 compilers, due to the F90 standard defining things that F77 compilers treated differently. Dealing with "kinds" is one of the more common problems here, especially for real numbers.


Steve - Intel Developer Support

Leave a Comment

Please sign in to add a comment. Not a member? Join today