Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
28456 Discussions

Compiler bug(s) with implied-DO array initialisation inside derived type across modules

Alan_Briolat
Beginner
332 Views

I've found some strange behaivour in derived type constructors when the following criteria are met:

  • A derived type contains an array
  • The array's initialisation expression contains an implied-DO
  • The value expression in the implied-DO is a numeric literal
  • The derived type's constructor is called from a module other than that which defines the derived type

The attached file shows the cases I've tested and the behaviour that they cause.  In summary:

  • Using an implied-DO like (0, i = 1, 5) causes a compiler error, but (0*i, i = 1, 5) does not
  • These compiler errors occur where the derived type's constructor is called, not at the implied-DO
  • The errors do not occur within the same module as the derived type definition, only other modules
0 Kudos
3 Replies
Steven_L_Intel1
Employee
332 Views

Thanks - I appreciate the detailed test case. I'm investigating and will escalate the issue to the developers. Issue ID is DPD200248580.

0 Kudos
Alan_Briolat
Beginner
332 Views

After working around this by using 0*i in the code that was having these problems, I still found myself triggering bugs.  I'm not sure if this is the same bug or related, but the existance of an implied-DO initialisation causes all kinds of strange behaviour that depends on the arrangement of elements within the derived type.  I've attached more test cases.  I'm guessing this one might be some kind of alignment-related bug in ifort's handling of derived type definitions in modules, and like the other problem it only occurs when constructors are called from outside of the module the derived type is defined in.

0 Kudos
Steven_L_Intel1
Employee
332 Views

Thanks - I'll give this to the developers as well.

0 Kudos
Reply