Format width recommendation (V12 warning)

Format width recommendation (V12 warning)

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

Linda
19 posts / 0 nouveau(x)
Dernière contribution
Reportez-vous à notre Notice d'optimisation pour plus d'informations sur les choix et l'optimisation des performances dans les produits logiciels Intel.

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

Linda

Linda

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

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).

Linda
Portrait de Steve Lionel (Intel)

Did you specify standards warnings should be errors?

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

Steve

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

Linda
Portrait de Steve Lionel (Intel)

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.

Steve

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)

Linda
Portrait de Steve Lionel (Intel)

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.

Steve

Dear Steve,

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

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

Linda
Portrait de Steve Lionel (Intel)

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.

Steve
Portrait de 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

Portrait de Steve Lionel (Intel)

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.

Steve

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"?

Portrait de Steve Lionel (Intel)

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.

Steve
Portrait de WHeat.

Dear Steve,

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

Thanks

 

Quote:

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.

Portrait de Steve Lionel (Intel)

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.

Steve

Connectez-vous pour laisser un commentaire.