Intel fortran language reference manual

Therefore, programmers who wanted to write subroutines which would accept an array of unknown total size would use a last dimension of 1. This worked because the last upper bound is not needed to calculate the position of an element in a Fortran array, and compilers of the time didn't have array bounds checking or if they did it could be disabled.

It included a new "assumed-size" array feature which had already shown up as an extension in many vendors' compilers. So now there was a standard-conforming way to say "I don't know what the upper bound is", yet there were still thousands of existing programs that used the old 1 convention and more compilers supported bounds-checking, even at compile-time VAX FORTRAN did this, for example.

These old programs would suddenly start getting errors, which was not desirable - the Fortran tradition is provide as much upward compatibility as possible. What to do? The a rray in the above example has a single dimension with lower bound 1 and an implicit upper bound of the total number of elements in the array that was passed, though most compilers don't pass that information and just treat the upper bound as infinite questions two and three.

If you have a multi-dimension array with upper bounds other than the last of 1, then 1 is what you get. Ask Dr. Fortran Hey! Who are you calling "obsolescent"? Fortran didn't receive any appropriate questions for his column this time, so he's going to take on a topic that is sure to raise a ruckus each time it is brought up in the comp.

But Fortran 90 formally introduced the concept of "language evolution" with the goal of removing from the language certain features that had more modern counterparts in the new language. The Fortran 90 standard added two lists of features, "Deleted" and "Obsolescent". The "Deleted" list, features no longer in the language, was empty in Fortran The "Obsolescent" list contained nine features of Fortran 77 which, to quote the standard, "are redundant and for which better methods are available in Fortran If the use of these features has become insignificant in Fortran programs, it is recommended that future Fortran standards committees consider deleting them from the next revision.

It is recommended that the next Fortran standards committee consider for deletion only those language features that appear in the list of obsolescent features. It is recommended that processors supporting the Fortran language continue to support these features as long as they continue to be widely used in Fortran programs. Proponents of "cleaning up" the language argued that it would make compiler implementors' jobs easier. The compiler vendors disagreed; most said that they would not remove support for any features since they knew that users continue to compile old programs.

Furthermore, deleting a feature from the language means that there is no official description of how that feature, if still supported, interacts with other language features. Descriptions of obsolescent features in the standard appeared in a small font and compilers were to provide the ability to issue diagnostics for the use of obsolete features.

Now we come to Fortran Keep in mind that the Fortran 90 standard did not say that the next standard HAD to delete any of the previously-designated "obsolescent" features, but that's exactly what the standards committee did. Six of the nine "obsolescent" features numbers 2, 4, 6, 7, 8 and 9 above were "deleted".

And guess what - that meant that a valid Fortran 77 program was no longer a valid Fortran 95 program! But never fear: DVF and indeed most vendors' compilers will continue to support the deleted features with optional diagnostics informing you of the fact, of course. The Fortran 95 list of obsolescent features includes the remaining items of the above list from Fortran 90 1, 3 and 5 , as well as several new additions. Are you sitting down? Here's the new list:. Needless to say, the inclusion of fixed-form source on this list has raised a LOT of eyebrows Fortran doesn't see these disappearing from users' code anytime soon.

So does this mean that some of these features will be deleted in the next standard, currently called "Fortran "? The standards committee has agreed to NOT move any features from the "obsolescent" list to the "deleted" list for F2K, and furthermore, is not proposing any additions to the "obsolescent" list. So it would appear that, for now, anyway, the "concept of language evolution" excludes extinction, and that should make Fortran programmers around the world breathe easier.

In this issue, Dr. Back in the "good old days" of Fortran programming, when lowercase letters hadn't been invented yet and we strung our core memory wires by hand, programmers knew that local variables lived in fixed memory locations and, of course, took advantage of that, writing code such as this:. The idea was that the value of the local variable I was preserved between calls to routine SUB, so that subsequent calls would get successive values of I.

Many of these same programmers assumed that variables were zero-initialized as well. However, the Fortran language didn't make such promises and, with the advent of improved optimization and "split lifetime analysis" which could make variables live in registers or on the stack, programs which made such assumptions could break. To accommodate the useful notion of a local variable whose definition status is preserved across routine calls, Fortran 77 added the SAVE statement. Fortran 90 removed that last clause for local variables, so that an "initially defined" local variable is implicitly SAVEd, but the catch about redefinition still applies to variables in named COMMON blocks.

One common misconception is that SAVE implies static fixed address allocation for a variable. This is not so - in fact, if the compiler can determine that a SAVEd variable is always defined before use, then it could decide to make that variable live in a non-static register or stack location.

This has been a big shock to some programmers who figured that the values would stay around. If you want the array to remain there, use SAVE. First, it is a lways a good idea to tell the compiler what you want, rather than making assumptions based on a current implementation. Compilers keep getting smarter and what "works" today might not work next year.

Proper use of SAVE can also aid with error reporting - some compilers will suppress "use before defined" warnings for variables with an explicit SAVE attribute. It's also good to let the human who reads your code know that you are assuming the variable's value is preserved. That's why Dr. It seems so simple, doesn't it?

Which bit pattern s represent true, and which represent false? And what bit patterns do. On all of these questions, the Fortran standard is silent. Indeed, according to the standard, you shouldn't be able to tell! How is this?

For example, if you have:. The answer is "it depends", and the result may even vary within a single implementation. Many other Fortran compilers adopt the C definition of zero being false and non-zero being true.

Either way, the result of the expression J. For example, the value 1 or would both test as true using Compaq Fortran. Just in case you were wondering, Compaq Fortran uses a binary value of -1 for the literal. The real trouble with making assumptions about the internal value of LOGICALs is when you try testing them for "equality" against another logical expression.

The way many Fortran programmers would naturally do this is as follows:. The Fortran language defines two operators exclusively for use on logical values,. So the above test would be properly written as:. In the Doctor's experience, not too many Fortran programmers use. However, there is one aspect of these operators you need to be aware of A customer recently sent us a program that contained the following statement:. The complaint was that the compiler "generated bad code.

This meant that the statement was treated as if it had been:. The Doctor's prescription here is to always use parentheses! That way you'll be sure that the compiler interprets the expression the way you meant it to! And you therefore don't have to learn the operator precedence table you can find in chapter 4 of the Compaq Fortran Language Reference Manual!

One of the more obscure error messages you can get at run time is Access Violation, which the Visual Fortran run-time library reports as error number The documentation says that it is a "system error," meaning that it is detected by the operating system, but many users think they're being told that their system itself has a problem. In this article, I'll explain what an access violation is, what programming mistakes can cause it to occur, and how to resolve them.

The "32 bit" means that a memory address is 32 bits in size, potentially having over four billion possible addresses. The other important aspect of virtual memory is that only those address ranges currently being used exist at all - others are not represented. It's like a telephone book, which has pages for only those names of people who live in the city.

If a phone book had to include a space for every possible name, every city and town's phone book would fill rooms! When your program starts to run, Windows allocates creates just enough virtual memory to hold the static fixed code and data in the executable.

As the program runs, it may ask to allocate additional memory, for example, through calls to ALLOCATE or malloc, either directly by your code or indirectly by the run-time library. Each allocation creates a new range of now-valid virtual addresses which didn't exist before. When the program ends, Windows automatically deallocates all the virtual memory the program used. Since not every possible bit value represents a currently valid address, what happens if you try to access read from or write to an invalid address?

Yes, that's right, you get an "Access Violation"! Probably the most common address involved in an access violation is zero. Because a zero address is typically reserved as meaning "not defined", Windows and most operating systems deliberately leaves unallocated the first group of addresses page starting at zero.

This means that an attempt to access through an uninitialized address will result in an error. You can also get an access violation trying to access memory with a non-zero addres s when that memory's address range hasn't yet been allocated.

Another type of access violation is where the address space exists but is protected. Usually, the address space in question is set up as "read only," so an attempt to write to it will result in an access violation.

In Visual Fortran, the most common cause of this is passing a constant as an argument to a routine that then tries to modify the argument. Visual Fortran, as of version 6, asks the linker to put constants in a read-only address space.

It is a violation of the standard to modify a constant argument. If you are running your application in the debugger, the debugger will stop at the point of the access violation. You may need to use the Context menu in the debugger to look at the statements of a caller of the code where the error occurred, but this can usually give you a good idea of what might be wrong.

Compare argument lists carefully and look for the mistake of trying to modify a constant. Rebuild with bounds and argument checking enabled, if it's not already on it is by default in Debug configurations created with V6 and later. Note from Steve - As of December , Intel Fortran does not put constants in read-only image sections.

That will be enabled in an update due in January Current versions of the compiler do support the. As I was walking up the stair I met a man who wasn't there. He wasn't there again today. I wish, I wish he'd stay away. Hughes Mearns Up through Fortran 77, there was no Fortran standard-conforming way of calling a routine with a different number of arguments than it was declared as having. This didn't stop people from omitting arguments, but whether or not it worked was highly implementation and argument dependent.

For example, you can often get away with omitting numeric scalar arguments but not CHARACTER or arguments used in adjustable array bounds expressions, as code in the called routine's "prologue" tries to reference the missing data, often resulting in an access violation see Don't Touch Me There.

Fortran 90 introduced the concept of optional arguments and a standard-conforming way of omitting said optional arguments. Many users eagerly seized upon this and started using the new feature, but soon got tripped up and confused because they didn't follow all of the rules the standard lays out.

The Doctor is here to help. First things first. For example:. The standard prohibits you from accessing an omitted argument, so use PRESENT to test to see if the argument is present before touching it. That part is simple. The part that people tend to miss, though, is that the use of OPTIONAL arguments means that an explicit interface for the routine is required to be visible to the caller.

If you don't have an explicit interface, the compiler doesn't know that it has to pass a n "I'm not here" value usually an address of zero for the argument being omitted, and you could get an access violation or wrong results. The "omitted-ness" is passed along and can be tested by the other routine.

There are some additional aspects of optional arguments, such as the use of keyword names in argument lists, that are worth learning about.

The Doctor highly recommends this for your reading pleasure. There will be a quiz next week just kidding! One of Fortran's greatest strengths is its ability to manipulate real numbers. It is astonishing, however, that many Fortran programmers lack even a rudimentary understanding of them. In this series, perhaps we can acquire a better understanding and, at the very least, see how some of the "experts" deal with problems.

If we start with the positive whole numbers, what we find is that both integers and real numbers are internally represented as sums of powers of 2. The main exceptional value is zero. If you view zero as a power of two, perhaps it's time to increase your medication Now negative numbers are somewhat different.

For integers, we are talking two's complement arithmetic normally , but for real numbers we just turn on the sign bit in the real number, which the hardware designers so nicely provided. That's all well and good for whole numbers, but how about decimal fractions like. Only now it's the negative powers of two. So, for example,. In point of fact. As powers of two, both ARE exactly representable.

My personal favorites tend to be F and Z. So let's take an up-close and personal look at some whole numbers first and then some fractions. Try the following program printing small whole numbers, both as integers and as reals :. The integers form a nice progression of bits look at the "b" formatted column. If we look at the reals, using "b" or "z" format, we see a similar pattern. Notice that zero is the same for both integer and real although for a real we CAN represent Look at 2.

There is only a single bit set! And it's way up in the exponent field. How can this be? Normally we would observe that a real number IEEE comprises a sign high, left bit, an exponent 8 bits for single precision -- real , and a fraction the remaining, rightmost 23 bits.

When we "normalize" any real number, the fraction gets shifted so that the high bit is "1" and the exponent adjusted accordingly. But if the high bit is always "1", we can elect to just discard it to save space and add precision , and generally this is done.

So the fraction is really the rightmost 23 bits PLUS a "hidden" bit of 1. For a number like 2. If you look carefully, you will observe that 2. But 3. And, of course, there are also appropriate exponent bits to the far left perhaps discussed in more detail in a later article.

Notice that in these real numbers there are quite a few zeros in the fraction rightmost 23 bits. ALL small integer values will look like this! The fraction before tossing the hidden bit would be and afterwards is just , so there are lots of zeros still to the right.

This is a good indication that we are dealing with an "exact" value not proof, but it happens a lot. Notice that we used a very "wide" format -- f This is a VERY useful trick The result is:. So these are the first few negative powers of two. Just like the positive powers from the first example, these all have a zero fraction after tossing the hidden bit.

Notice that the actual values in f format all end in "5". And the 5 keeps moving to the next column. This means that ANY fractional sum will also end in 5. The consequence is that if you provide a fraction whose last nonzero digit is NOT 5 like 0. This is a VERY important point. You say, "So what.

And while some fractions ending in 5 CAN be represented, many cannot. Consider 5. Notice that the others, while "close" to. Some are a little bigger, some smaller popularly called "nines disease".

In fact, with the exception of 0. Observe, however, that only when a wide format is used is this apparent. With a smaller format width, most of these will look just fine due to rounding! We see that the closest representable real number to 3. Once again, notice the use of an even wider format to help get a better look at the numbers! Keep in mind that for a statement like:. Neither of these conversions is easy, but thankfully the Fortran compiler and runtime library perform all of this heavy lifting!

Try to figure out where the "unlucky 13" went!? Look for the answers in Part II of this article in a future newsletter issue.

Win32 Corner is a new feature of the newsletter that illustrates how to use Win32 API routines to do commonly requested tasks. The ShellExecute API routine is handy for opening a web page, or any document using its natural editing tool. It's equivalent to right clicking on a file and selecting Open - or you can also choose the default action whatever is listed first , Print or Edit.

I've found it most useful for opening a web page with the user's default browser. Try building and running shellexecute. In our last issue, the Good Doctor covered the topic of optional arguments, noting that an explicit interface was required. Since explicit interfaces seem to be a common point of confusion for those new to Fortran 90, and some not so new , we'll cover this subject in more detail.

In Fortran terminology, an interface is a declaration of some other procedure that supplies details, including:. Prior to Fortran 90, the only kind of interface was implicit , meaning that the compiler assumed that a routine call matched the actual routine - all you could do was specify the type of a function. The standard required that "the actual arguments The explicit interface , introduced with Fortran 90, allows you to tell the compiler many more details about the called routine.

This additional information allows a compiler to check for consistency in routine calls and also enables features such as optional arguments that depend on changes in the way the routine is called. While there are many good reasons why you should always use explicit interfaces, including better error checking and improved run-time performance avoiding unnecessary copy-in, copy-out code , there are some cases where you are required to have an explicit interface visible.

Multi-Platform Release Note - The name of the latest Solaris operating environment release is Solaris 7 but some documentation and path or package path names may still use Solaris 2. Related Books The following books augment this manual and provide essential information: Fortran User's Guide --provides information on command line options and how to use the compilers.

Fortran Library Reference -gives details on the language and routines. Solaris Books The following Solaris manuals and guides provide additional useful information: The Solaris Linker and Libraries Guide --gives information on linking and libraries. Note - To access AnswerBook2 documents, Solaris 2. Open a document in the index by clicking the document's title.

To find out more see: Online Help. What Typographic Changes Mean The following table describes the typographic changes used in this book.

Use ls -a to list all files. These are called class options. You must be root to do this. Standards are discussed in Chapter 1. Shell Prompts in Command Examples The following table shows the default system prompt and superuser prompt for the C shell, Bourne shell, and Korn shell.

The names of commands, files, and directories; on-screen computer output. Edit your. I think we'd prefer that you not reference a beta in a paper. Usually this manual would be like the name: - so the Compiler 15 is not a problem, just want to make sure I am using the correct numbers. We're doing away with the document numbers, so I don't recommend you reference those. Intel is based in Santa Clara, California. Use whichever makes the most sense for your use.

Intel Corporation. Santa Clara, California: Intel. I have never explored what happens prior to year zero from now , and the function likely may not work in that domain.

But I also don't think there is an upper limit, so perhaps you could simply add an offset of , to the year. My take from Paul's post is that there are , days in years since year 1 or estimated as 52,,, minutes in , years. I would not go to the detail of leap years. With the number of earthquake events you are identifying, should you also consider some form of location restriction or are you looking at the whole world.

I am also wondering if this study is based on probability of an event taking place anywhere or is there any location reference? There is an argument that events at M4 and below can be "man-made" so the change of this influence over , years may make these difficult to assess. I suspect this may be what you are studying. Chris, I was interested to see your Julian day conversion, which is different from one I obtained many years ago.