Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Beginner
23 Views

Standard conformance warning and vectorization directives

Jump to solution

Hi,

I always compile my code with the option /stand:f08 (I just saw there is now a /stand:15) as I like to check for standard conformance. However when using vectorization directives (such as !DIR$ ivdep) I get the following warning (with Intel Parallel Studio XE 2016.3):

warning #6477: Fortran 2008 does not allow this statement or directive.

Is there any way to disable this warning for directives, or at least locally? I can see that such directives may make the code non conforming, but completely disabling the option /stand:f08 is not right in my view, as it would prevent the compiler of showing many interesting warnings in other parts of the code. Many compiler can disable some warnings at a line/block level using pragma. Is it also possible with the Intel Fortran compiler?

 

0 Kudos

Accepted Solutions
Highlighted
Valued Contributor III
21 Views

Hervé Martin wrote:

Well, I know of Qdiag-disable. Unfortunately it is a file-wide (or project-wide) setting. I would prefer something allowing to disable locally the warning (like a C++ pragma)...

Well, the !DIR$ statements in your code for vectorization, etc. should lead to SPECIFIC warnings: #6477 and so forth.  So why would you not want project-wide setting to suppress those specific warnings with /Qdiag-disable: 6477, nnnn, ..?

View solution in original post

0 Kudos
21 Replies
Highlighted
Valued Contributor III
21 Views
0 Kudos
Highlighted
Beginner
21 Views

Well, I know of Qdiag-disable. Unfortunately it is a file-wide (or project-wide) setting. I would prefer something allowing to disable locally the warning (like a C++ pragma)...

0 Kudos
Highlighted
Valued Contributor III
22 Views

Hervé Martin wrote:

Well, I know of Qdiag-disable. Unfortunately it is a file-wide (or project-wide) setting. I would prefer something allowing to disable locally the warning (like a C++ pragma)...

Well, the !DIR$ statements in your code for vectorization, etc. should lead to SPECIFIC warnings: #6477 and so forth.  So why would you not want project-wide setting to suppress those specific warnings with /Qdiag-disable: 6477, nnnn, ..?

View solution in original post

0 Kudos
Highlighted
21 Views

>>Well, the !DIR$ statements in your code for vectorization, etc. should lead to SPECIFIC warnings: #6477 and so forth.  So why would you not want project-wide setting to suppress those specific warnings with /Qdiag-disable: 6477, nnnn, ..?

You might want to turn them off one at a time after you certify correctness. A large project may have 100's of these instances.

*** PSEUDO implementation:

!dir$ option :: diag-disable(push,6477)
.... code ...
!dir$ option :: diag-disable(pop)

*** end PSEUDO implementation

The above is a conceptualization, actual implementation may be entirely different. The jist is to have a means to disable/enable warnings via annotations within the source code.

Jim Dempsey

0 Kudos
Highlighted
Valued Contributor III
21 Views

Equally Jim in your case you could disable the warning an add a line like:

!dir$:'check vectorisation result here then remove me'

General Compiler Directive: Specifies a character string to be sent to the standard output device during the first compiler pass; this aids debugging.

!DIR$ MESSAGE:string

 

0 Kudos
Highlighted
Beginner
21 Views

Oh, I had not realized that these were specific warnings for directives only. I use only a few directives, so disabling them with /Qdiag-disable at file level is Ok. However I still feel it would be a useful feature to have pragmas to disable warnings (not just these ones, any warning) at specific locations...

0 Kudos
Highlighted
Black Belt
21 Views

How would you disable the warning for the use of a directive that disables a warning?
 

0 Kudos
Highlighted
Beginner
21 Views

I am not sure I really understand your question. While I am OK with the idea of disabling specific warnings at the file level, a very welcome feature would be something similar to what is possible with the Intel C++ compiler:

#pragma warning push
#pragma warning(disable:111111)
! some Fortran code producing a warning 111111
#pragma warning pop

Between the two pragma warning, the warning with Id 111111 is disabled. This is much more elegant that at the file level. But like I said before, as long as the warning is very specific, it is most of the time OK to disable it for a whole file.

0 Kudos
Highlighted
21 Views

Andrew,

Your suggestion just adds more clutter to the diagnostic (warnings) output....

However, one could

a) enable the specific warning (not disable it)
b) produce a test compile to generate the standards conformance warnings
c) edit the source code to emit "Check out this questionable code"
d) globaly disable the specific warnings
e) Then enter iterative process of certifying correctness, removing each emission of "Check out this questionable code" on a case by case basis.

The above may be suitable if you are just doing a conversion/verification. However, if you are adding code, you run into the issue of the new code needing the conformance checks, preferably without regenerating warnings you are not interested in reviewing.

Jim Dempsey 

0 Kudos
Highlighted
21 Views

Herve',

That is essentially what I was suggesting.

The C++ community found it a valuable enough feature to include.

Jim

0 Kudos
Highlighted
Valued Contributor III
21 Views

jimdempseyatthecove wrote:

Herve',

That is essentially what I was suggesting.

The C++ community found it a valuable enough feature to include.

Jim

Jim,

I think what IanH is implying is the 'infinite loop' that per Intel's interpretation of the Fortran standard, any use of a directive will itself trigger a "standards" warning if /stand compiler option is in effect.

Intel staff,

If any of you is following this, what OP and the rest of the readers can learn is to know where in the Fortran standard does it say statement directives are"not allowed"?  Consider the following simple code based on Intel Fortran documentation itself and the compiler warning about line 15.  From what I can tell, the Fortran standard is completely silent about what follows the comment delimiter, so why the warning in the first place?  I think OP will benefit from your explanation about this.

program p

   implicit none

   integer, parameter :: N = 1
   integer :: A(N)
   integer :: B(N)
   integer :: INDARR(N)
   integer :: I

   A = 1
   B = 42
   INDARR = [( I, I = 1,N) ]

   !dir$ ivdep
   do I = 1, N
      A(INDARR(I)) = A(INDARR(I)) + B(I)
   end do

   print *, "A = ", A

   stop

end program p
Compiling with Intel(R) Visual Fortran Compiler 17.0.0.072 [Intel(R) 64]...
p.f90
p.f90(15): warning #6477: Fortran 2015 does not allow this statement or directive.

 

0 Kudos
Highlighted
Employee
21 Views

Yes, I've been following. I've inquired about your question. Stay tuned...

0 Kudos
Highlighted
21 Views

Although this is off topic...

In regards to FortranFan's post #12, it might be handy (for !dir$ ivdep) for the Debug build to optionally assert the loop invariance.

Jim Dempsey

0 Kudos
Highlighted
Employee
21 Views

To quote and paraphrase Development’s guidance, they write “the standard does not say anything about what a processor might do with things in a comment line (which is what !dir$ looks like).”

Also, that is it is not unusual for compilers to offer extensions, and that’s what !dir$ ivdep is.

On the matter of messages, they advise that we chose to give messages for directives we recognize, either syntax messages or standards warnings, believing that would be helpful to users.  For example, if you have a big complicated program, and did not realize it depended on Intel-specific directives, and you try to compile/run it with gfortran, we believe it to be helpful to be notified that <whatever> was non-standard.

0 Kudos
Highlighted
Valued Contributor III
21 Views

Kevin D. (Intel) wrote:

To quote and paraphrase Development’s guidance, they write “the standard does not say anything about what a processor might do with things in a comment line (which is what !dir$ looks like).”

Also, that is it is not unusual for compilers to offer extensions, and that’s what !dir$ ivdep is.

On the matter of messages, they advise that we chose to give messages for directives we recognize, either syntax messages or standards warnings, believing that would be helpful to users.  For example, if you have a big complicated program, and did not realize it depended on Intel-specific directives, and you try to compile/run it with gfortran, we believe it to be helpful to be notified that <whatever> was non-standard.

Kevin,

Thanks for your follow-up.  I think there are a couple of issues with Intel's approach:

1) The wording of the warning itself appears misleading to me, "Fortran 2015 does not allow this statement or directive."  Please correct me if I'm wrong, but I do NOT see anything in the standard that "does not allow" the comment statement and the directive implied therein.  So if Intel indeed wants to help developers and wishes to throw a warning, I suggest modified wording along the lines of "An Intel-specific directive is in effect for block of code in lines nn through mm.  Run-time execution of this block may differ across platforms and compilers." or something along such lines.

2) More importantly, the idea that the directive is non-standard is, in and of itself, questionable and debatable.  More often than not, it would appear the use of directives *does something* that is outside the scope of the standard, or the standard might be either neutral or silent on the issue.  But that does not mean it is non-standard - a very subtle point for Intel Fortran team to consider.  Take the code in Message #12 above for example: does the standard stipulate or disallow anything that Intel might do to optimize and vectorize code based on the assertion implied with !DIR$ IVDEP - I do not think so, there is nothing I see that is non-standard with the DO loop in lines 16 through 18 following the statement directive and I would think that is the relevant aspect here which is addressed by the standard.  Thus I disagree, and perhaps some others would as well, with the view it is non-standard.

I'll appreciate greatly if you can feed this back to your development and they will refine the approach in Intel Fortran.

Thanks,

0 Kudos
Highlighted
21 Views

The development team had an extended discussion of this issue some 8-9 years ago. Initially I was on the side of directives being treated as comments if not recognized, but I eventually was persuaded that directives were "statements with funny syntax" and that standards warnings for them were appropriate. In many cases, directives are inserted to change the behavior or even interpretation of the program. They are the equivalent of statements even though they take the form of a comment. We came down on the side of directives being treated as if they were nonstandard statements and thus subject to standards warnings. Yes, it's true that some directives affect performance only, but others do not. The programmer adds directives to change how the compiler interprets the source, thus they are effectively language syntax.

0 Kudos
Highlighted
21 Views

Steve,

Consider this:

!dir$ ivdep nowarn

.or.

!dir nowarn
!dir$ ivedp

The developer can then "hush" specific warnings.

Jim Dempsey

0 Kudos
Highlighted
21 Views

We already provide /Qdiag-disable to disable many specific diagnostics. Some experimenting tells me that while we have a diagnostic specific to directives (7025), we also have one that names both directives and statements (6477) and I have at least one test case that displays both for a single directive!

It seems to me that a good solution is to have directives always use 7025 so you can disable it if you want.

Adding a directive to disable warnings for directives seems a bit strange to me.

0 Kudos
Highlighted
21 Views

>>Adding a directive to disable warnings for directives seems a bit strange to me.

It is not to me. You may have 10's or 100's of these statements within the program...

... in the event the warning is pointing out a coding error (due to the loop NOT being ivdep), then compiling with the standards checking (and getting 10's or 100's) warnings, provides you with a convenient "to do" list of the loops that need to be certified as correct (meaning actually ivdep). Then as you certify correctness, you can then instruct the compiler NOT to generate the warning on the specific statement you just certified as correct. IOW it shortens up your to do list.

Jim Dempsey

0 Kudos