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

same_type_as() in constant expressions

DataScientist
Valued Contributor I
2,417 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,309 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,384 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,380 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,369 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,366 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,310 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,298 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,293 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,287 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,276 Views

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

0 Kudos
DataScientist
Valued Contributor I
2,290 Views

fantastic! Thank you.

0 Kudos
Igor_V_Intel
Moderator
921 Views

This bug is fixed in ifx 2025.0 compiler version.


0 Kudos
Reply