- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This triggers an ICE with ifort 2021.5.0.
The workaround is obvious (don't name a block after a variable name!) but I thought I would report the ICE nonetheless.
PROGRAM P
INTEGER :: I
I : BLOCK
END BLOCK I
END
Now, if the declaration for I is removed (using implicit typing for I, as shown below), the whole thing compiles without issue. It's probably an additional bug, although I am not sure about what the standard says about block construct names colliding with the names of variables or parameters. Somebody may want to chime in here.
PROGRAM P
I : BLOCK
END BLOCK I
END
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This block of ICE is fixed in the latest compiler release. Both ifort and ifx now print the error message without the ICE.
These compilers are included in oneAPI 2022.3.
Give them a try!
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The identifier for a named construct is a "Class (1)" local identifier and cannot share a name with a local variable. Your second example doesn't have any variables, so no problem.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Why does this not trigger an error instead of an ICE -- just wandering
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I get error #6444: Not a valid construct name. [I]
Before Fatal: There has been an internal compiler error (C0000005)
So not so bad IMO.....
( Fortran Compiler Classic 2021.5.0 [Intel(R) 64] )
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@Steve_Lionel , yes, I should have thought twice before posting my second example, ha ha.
I am not too concerned by the bug (after all as noted by @andrew_4619 the compiler is nice enough to issue an error before ice-ing). I just report this in the spirit of completeness.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
But no ICE with the same code for a named DO loop or ASSOCIATE construct only with BLOCK.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
God, Santa and Dr Fortran work in mysterious ways is the best answer to the unsolvable unknown.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
ASSOCIATE is F2003, BLOCK is F2008 so a later code addition. Bugs come with adding or changing things......
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hate a block of ice unless it's in an iced coffee!
I filed a bug for this, CMPLRIL0-34580. I'll let you know when it's fixed.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Some recent research work shows that caffeine is an insecticide. Still I prefer my fix in a a red can.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This block of ICE is fixed in the latest compiler release. Both ifort and ifx now print the error message without the ICE.
These compilers are included in oneAPI 2022.3.
Give them a try!

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page