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

same_type_as() in constant expressions

DataScientist
Valued Contributor I
1,344 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
1,236 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
10 Replies
Steve_Lionel
Honored Contributor III
1,311 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
1,307 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
1,296 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
1,293 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
1,237 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
1,225 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
1,220 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
1,214 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
1,203 Views

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

0 Kudos
DataScientist
Valued Contributor I
1,217 Views

fantastic! Thank you.

0 Kudos
Reply