Format width recommendation (V12 warning)

[lklawrie]

Here's the warning that is generated:

remark #8293: Recommended relationship between field width 'W', the number of fractional digits 'D' and the number of exponential digits 'E' in this edit descriptor is 'W>=D+E+5'.
501 FORMAT(' Fuel Supply, ', A, ',', G12.6E2, ',' , G12.6E2, ',' , G12.6E2, ',', G12.6E2)


is this coming from a standard or just a "good" idea from the compiler authors?

Linda

[lklawrie]

Never mind -- I see the info in the documentation.

Linda

[IanH]

For more v12 warning fun compile with "/stand:f08". It will take your coding back about twenty years!

[lklawrie]

Right, if this is standard 08, why's it telling me a bunch of stuff wasn't in Fortran 90?

warning #7520: A data-initialization-expr on a component-def-stmt was not in Fortran 90.

It seems to know it's standard:
error #7262: Allowing a variable name that is not an array-variable-name as an actual argument for a corresponding array dummy is not standard Fortran 2008.

and errors out even though it's not supposed to (standard as warning errors).

[Steven_L_Intel1]

Did you specify standards warnings should be errors?

/stand:f08 isn't documented and while accepted it doesn't work right.

[lklawrie]

No, I have standards warnings should not be errors.

Thought it might be fun to follow the recommendation -- obvious there is some more work to do. Not important (that is, I'm sure there are more important issues than looking at undocumented "features").

Linda

[Steven_L_Intel1]

Linda,

The problem with /stand:f08 was fixed for Composer XE 2011 Update 6. We've tried to find all the places in the compiler where /stand:f08 should suppress the warning - if you or anyone else finds a case we didn't, please let us know.

[lklawrie]

Not sure if there is a problem or not. The warning is still there. It's just a warning. I don't have any standards checking turned on. (still there in Update 8)

[Steven_L_Intel1]

The warning in the first post is not a standards warning, it's a "usage" warning. You can turn it off if you like. I just wanted to follow-up on the /stand:f08 issue.

[ALICE_Y_]

Dear Steve, Could u please tell me, how to disable the warning in user window other than DOS?

[lklawrie]

You disable warnings (though this appears to be a "remark") by /Qdiag-disable:

[Steven_L_Intel1]

If you are using Visual Studio, you can supply any additional command line options, where a project property is not provided, on the Command Line property page.

[WHeat_]

Dear Steve,

I have the same message when I compile with a old program wrotten in Fortran 77 using Visual Studio

I have another question :

error #6633: The type of the actual argument differs from the type of the dummy argument.  ?

Adel

[Steven_L_Intel1]

Well, that's an error according to the standard. For example, you have a subroutine that takes an INTEGER argument but you pass a REAL to it, or more often, it takes a REAL(8) but you pass a REAL(4). We have a feature that can check for argument consistency even with old-style programs that use external procedures. It can find errors in code that went undetected before.

The error message tells you the point of the call, the routine name and the argument name. Check to see what doesn't match and fix it.

[dboggs]

Steve,

I get quite a few of these type mismatch "errors (according to the standard," especially in older programs, and as far as I can tell the codes still work. I do want (philosopically that is) to square things up--just to avoid the warnings if nothing else--but sometimes it is pretty inconvenient to do so. Can you comment on the necessity or advisability of treating these "errors"?

[Steven_L_Intel1]

Sometimes these mismatches are deliberate choices by the programmer and are harmless. Sometimes they're unintended and can result in unpredictable execution. Sometimes they're deliberate and still harmful. The only way to know for sure is to analyze the program in question. Mismatches involving REALs can be particularly troublesome in that you get wrong values rather than outright errors Data corruption is another possibility.

If you want to run with the blade guard removed, turn off Diagnostics > Check Routine Interfaces. But I don't recommend this.

[WHeat_]

Dear Steve,

how can I create and compile programs in Fixed Form ( Fortran 77)  using Visual Studio and Intel Visual ?

Thanks

[TimP]

WHeat. wrote:

Dear Steve,

how can I create and compile programs in Fixed Form ( Fortran 77)  using Visual Studio and Intel Visual ?

Thanks

This doesn't appear relevant to the preceding entries in this thread.

Fixed form (Fortran 77 standard) source (ifort option /fixed) is the default for .f and .for file names. Either GUI or command line will work accordingly.  There aren't any options to cater to the rare cases where f77 differs from or was less well defined than successor standards.

[Steven_L_Intel1]

WHeat,

If you have existing fixed-form sources, make sure they have the .f or .for file type and simply add them to your project. If you want to create new fixed-form files, which I don't recommend, that's one of the choices when you go to add a new Fortran source file. As Tim says, nothing more is typically needed.

If you have more questions, please start a new thread in the forum.