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

same_type_as() in constant expressions

DataScientist
Valued Contributor I
2,209 Views

The expression,

integer, parameter :: offset = merge(1, 0, same_type_as(x_type(), y_type()))

yields an error with ifort (but not with gfortran).

error #6263: This intrinsic function is invalid in constant expressions. [SAME_TYPE_AS]

Which behavior is standard-conforming?

1 Solution
Steve_Lionel
Honored Contributor III
2,101 Views

It is definitely a bug. I thought I had submitted a ticket on specification inquiry expressions a longtime ago but can't find it in my issue history. The Intel compiler completely misses the standard's support of these in constant expressions.

View solution in original post

0 Kudos
11 Replies
Steve_Lionel
Honored Contributor III
2,176 Views

My opinion is that Intel is correct. SAME_TYPE_AS() here is a "specification inquiry" (which Intel has gotten wrong before), but the restrictions on using this in a constant expression are:

a specification inquiry where each designator or argument is
 (a) a constant expression or
 (b) a variable whose properties inquired about are not
   (i) assumed,
   (ii) deferred, or
   (iii) defined by an expression that is not a constant expression,

 

In this case, xtype() and ytype() aren't constant expressions nor variables. (Since you didn't include the definition of these, I don't know what they are, but the syntax does tell me they don't qualify.)

0 Kudos
DataScientist
Valued Contributor I
2,172 Views

I expected that the following would be standard conforming, but Intel ifort issues a compile error (unlike gfortran):
```
type :: x_type; end type
type :: y_type; end type
type(x_type), parameter :: x = x_type()
type(y_type), parameter :: y = y_type()
integer, parameter :: offset = merge(0, 1, same_type_as(x, y))
print *, offset
end
```
I do not see why this should not be standard-conforming. Everything is compile-time constant. Here is a test: https://godbolt.org/z/G65aaj6e5

0 Kudos
Steve_Lionel
Honored Contributor III
2,161 Views

I think this is the more general case of Intel Fortran not properly supporting specification inquiries in constant expressions. 

0 Kudos
DataScientist
Valued Contributor I
2,158 Views

Can we say this is an ifort BUG so that it hopefully gets picked up by the developers?

0 Kudos
Steve_Lionel
Honored Contributor III
2,102 Views

It is definitely a bug. I thought I had submitted a ticket on specification inquiry expressions a longtime ago but can't find it in my issue history. The Intel compiler completely misses the standard's support of these in constant expressions.

0 Kudos
DataScientist
Valued Contributor I
2,090 Views

Thank you. I cannot change the title anymore to add a BUG tag. But if you have already submitted a ticket, that should be enough.

0 Kudos
Barbara_P_Intel
Employee
2,085 Views

@Steve_Lionel, I couldn't find a bug report on this invalid error message, but maybe my search skills are lacking.

I filed a bug report, CMPLRLLVM-53005. I'll let you know its progress to a fix.



Steve_Lionel
Honored Contributor III
2,079 Views

Thanks, Barbara. My recollection is that the compiler is simply not allowing "specification inquiry" expressions in constant expressions. Specification Inquiry expressions are described in F2018 10.1.11p3, and 10.1.12 (Constant expressions) says the following is allowed:

(4) a specification inquiry where each designator or argument is
25 (a) a constant expression or
26 (b) a variable whose properties inquired about are not
27 (i) assumed,
28 (ii) deferred, or
29 (iii) defined by an expression that is not a constant expression,

0 Kudos
Barbara_P_Intel
Employee
2,068 Views

Thanks for the details, @Steve_Lionel. I added the info to the bug report. 

0 Kudos
DataScientist
Valued Contributor I
2,082 Views

fantastic! Thank you.

0 Kudos
Igor_V_Intel
Employee
713 Views

This bug is fixed in ifx 2025.0 compiler version.


0 Kudos
Reply