IFX 2024.2.0 Internal Compiler Error: Common blocks with same name and -g

[KP_14]

This is a greatly simplified snippet from a program that causes an internal compiler error in IFX 2024.2.0.

Commands:

"ifx -g -c usedModule.F90 -o obj/usedModule.o -module obj"

"ifx -g -c mainModule.F90 -o obj/mainModule.o -module obj"

Version: 2024.2.0 Build 20240602

Error: "error #5623: **Internal compiler error: internal abort**"

The usage of a common block with the same name being included in modules in this manner seems to produce the error. While renaming one of the common blocks fixes the issue, I am not able to make changes to this code.

VARS.CMN

    COMMON / FOO / VAR1

    INTEGER VAR1

VARS01.CMN

    COMMON / FOO / VAR101

    INTEGER VAR101

usedModule.F90

MODULE usedModule

#include 'VARS01.CMN'

    PRIVATE
    PUBLIC :: USEDSUB

    CONTAINS

    SUBROUTINE USEDSUB

    END SUBROUTINE USEDSUB

END MODULE usedModule

mainModule.F90

MODULE mainModule

USE usedModule

#include 'VARS.CMN'
#include 'VARS01.CMN'

    PRIVATE
    PUBLIC :: MAINSUB

    CONTAINS

    SUBROUTINE MAINSUB

    END SUBROUTINE MAINSUB

END MODULE mainModule

[jimdempseyatthecove]

Your usedModule contains "#include 'VARS01.CMN'"

which declares COMMON / FOO / VAR101

mainModule contiains:

   USE usedModule ! which declares COMMON / FOO / VAR101

   #include 'VARS.CMN" ! which (presumably) appends VAR1 to / FOO /

   # include "VARS01.CMN"  ! which (presumably) appends VAR101 to / FOO / and which now is duplicated.

Try either: removing  # include "VARS01.CMN" from mainModule

or Removing both #include statements from and inserting  #include 'VARS.CMN"  in usedModule

****Caution, the order in which the #includes occur specify the placement of the variables in the common block

 As you originally written it, had it worked, it would have been ambiguous as to which variable came first.

If Steve L. sees this, maybe he can comment on the extensibilities of a COMMON in a module by another common in a different module.

(assuming you get the order of the variables in the way intended)

Jim Dempsey

[Steve_Lionel]

---

@jimdempseyatthecove wrote:

If Steve L. sees this, maybe he can comment on the extensibilities of a COMMON in a module by another common in a different module.

"Named common blocks of the same name shall be of the same size in all scoping units of a program in which they appear, but blank common blocks may be of different sizes." (F2023 8.10.2.5, emphasis mine)

Since the common block is named, it's not allowed to have different sizes in different scoping units. If it had been a blank (unnamed) common block, that would be OK. That said, an internal compiler error is never OK.

The Windows and Linux linkers don't detect this error, and the allocated size ends up being whichever one was seen first - I recall that the OpenVMS linker did complain about mismatched sizes. Back in the CVF days, we even had a tool you could run across objects to check this for you.

[KP_14]

Thanks for the information. I tried both removing #include 'VARS01.CMN' from mainModule and removing both includes from mainModule in tandem with inserting #include 'VARS.CMN' in usedModule. Both compiled without issue. I also tried adding #include 'VARS.CMN' before the other include in usedModule to match mainModule just for good measure. There was no ICE as well.

I am unable to make the appropriate change to this code myself unfortunately otherwise I would change the includes. A patch for ifx to prevent an ICE in this case would be appreciated. In the meantime, we can continue using ifort (version 2021.13.0 compiles without error).