CVF6.6B - !DEC$IF parsing - Is it as it should be?

CVF6.6B - !DEC$IF parsing - Is it as it should be?

I upgraded to 6.6B and I was pleasantly surprised how it caught few errors that were left unnoticed in 6.6A (misordered names in USE,ONLY lists and a few assumed-shape/assumed-array/scalar argument mismatches). However, apparently parsing of !DEC$IF parsing was changed as well. The following program:

!DEC$DEFINE _ENGLISH
PROGRAM Test

!DEC$IF DEFINED (_ENGLISH)
      WRITE(*,*)
!DEC$ELSE
      CALL ErrHandler('a' // &
            STRING(isiftse(i),9)'b'
            STRING(isifrasab,9),2)

!DEC$ENDIF

END PROGRAM Test

Produces
D:UsersDujaCodeTestTest.f90(9) : Error: Unbalanced parentheses
STRING(isifrasab,9),2)
Not all syntax errors in a code that is supposedly not compiled will trigger such errors -- mostly, it is sensitive to some combinations with line continuations. Now, I recall Steve said once that !DEC$IF is not semantically identical to #ifdef...#endif. Should I file a bug report or is this as it should be? (But if it is, I can't figure out the rules?).

Jugoslav

Jugoslav www.xeffort.com
8 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

What do you think this should have done? The code in the ELSE clause looks very strange to me - definitely incorrect. I'm not sure what your complaint is.

!DEC$ IF is not like #ifdef in that !DEC$ IF operates on entire statements, not source lines.

Steve

Steve - Intel Developer Support

I see now. Forget it -- just a minor inconvenience. The actual code between ELSE...ENDIF where it popped out was never meant to be compiled at all (long story). My point was -- why should compiler even care about the contents of "commented" code. 6.6A acted as if !DEC$IF was line-based, not statement-based.

Jugoslav

Jugoslav www.xeffort.com

6.6A was still statement-based but text that would not be compiled was still run through syntax analysis. I think we have it in 6.6B that it won't complain about code it won't compile.

Steve

Steve - Intel Developer Support

It appears to be complaining in this case. Seems to only care if there are too many ")". One would expect this code to be ignored.

James

Oh, I get it now... Sometimes I'm a bit slow to catch on...

Steve

Steve - Intel Developer Support

Should I file a bug report or I may consider it already done?

Jugoslav

Jugoslav www.xeffort.com

I'll take care of it - thanks.

Steve

Steve - Intel Developer Support

Leave a Comment

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