[Flang] Using BOZ constant as the SOURCE= argument of intrinsic TRANSFER triggered a compile time error.

[DanielCChen]

Consider the following code

real(4), parameter :: r4_ep = transfer (Z'34000000', 1.0_4)
end

This seems to be a reasonable extension to use BOZ constant.

Flang is currently disallowing it as

error: Semantic errors in t.f
./t.f:1:41: error: Typeless (BOZ) not allowed for 'source=' argument
  real(4), parameter :: r4_ep = transfer (Z'34000000', 1.0_4)
                                          ^^^^^^^^^^^

Both ifort and XLF compile the code successfully.

[llvmbot]

@llvm/issue-subscribers-flang-frontend

Author: Daniel Chen (DanielCChen)

Consider the following code ``` real(4), parameter :: r4_ep = transfer (Z'34000000', 1.0_4) end

This seems to be a reasonable extension to use BOZ constant.

Flang is currently disallowing it as

error: Semantic errors in t.f
./t.f:1:41: error: Typeless (BOZ) not allowed for 'source=' argument
real(4), parameter :: r4_ep = transfer (Z'34000000', 1.0_4)
^^^^^^^^^^^

Both ifort and XLF compile the code successfully.
</details>

[klausler]

Use the INT or REAL intrinsic function, probably with a KIND= argument, around the BOZ literal, so that it is clear what the size of the BOZ literal is. Without that information the TRANSFER is ambiguous.

[DanielCChen]

Use the INT or REAL intrinsic function, probably with a KIND= argument, around the BOZ literal, so that it is clear what the size of the BOZ literal is. Without that information the TRANSFER is ambiguous.

The result type of TRANSFER is based on the MOLD argument, which is real*4 in this case.
Should the compiler be able to figure out the physical representation of the BOZ constant, then compare with the MOLD?

[klausler]

Use the INT or REAL intrinsic function, probably with a KIND= argument, around the BOZ literal, so that it is clear what the size of the BOZ literal is. Without that information the TRANSFER is ambiguous.

The result type of TRANSFER is based on the MOLD argument, which is real*4 in this case. Should the compiler be able to figure out the physical representation of the BOZ constant, then compare with the MOLD?

My point relates to the source, not the mold. Without knowing the size of the source, the semantics of TRANSFER are not well-defined. And the size of a BOZ literal is not well defined in the standard, which is why it is allowed in only a few specific contexts.

[DanielCChen]

Right. XLF assumes the type of SOURCE the same as the MOLD and we generate (after remove the PARAMETER attribute)

@r4_ep = internal global float 0x3E80000000000000, align 4

Is it reasonable?

[klausler]

How is 0x3E80000000000000 a 32-bit F.P. value? How is it a reasonable result from transfer (Z'34000000', 1.0_4)?

[DanielCChen]

How is 0x3E80000000000000 a 32-bit F.P. value? How is it a reasonable result from transfer (Z'34000000', 1.0_4)?

We implemented the transfer(REAL(Z'34000000'), 1.0_4) as you suggested as a source code wordaround in the compiler.
I supposed I can change our test cases. Just thought this may be a reasonable compiler extension.

[kargl]

How is 0x3E80000000000000 a 32-bit F.P. value? How is it a reasonable result from transfer (Z'34000000', 1.0_4)?

We implemented the transfer(REAL(Z'34000000'), 1.0_4) as you suggested as a source code wordaround in the compiler. I supposed I can change our test cases. Just thought this may be a reasonable compiler extension.

Gfortran rejects your code.

% gfcx -c a.f90
a.f90:1:40:

 1 | real(4), parameter :: r4_ep = transfer (Z'34000000', 1.0_4)
    |                                        1
 Error: BOZ literal constant at (1) cannot be an actual argument to 'transfer'

Note, a BOZ is defined in F2023 to be typeless. The requirement on SOURCE in 16.9.212
is SOURCE shall be a scalar or array of any type.

[DanielCChen]

How is 0x3E80000000000000 a 32-bit F.P. value? How is it a reasonable result from transfer (Z'34000000', 1.0_4)?

We implemented the transfer(REAL(Z'34000000'), 1.0_4) as you suggested as a source code wordaround in the compiler. I supposed I can change our test cases. Just thought this may be a reasonable compiler extension.

Gfortran rejects your code.

% gfcx -c a.f90
a.f90:1:40:

 1 | real(4), parameter :: r4_ep = transfer (Z'34000000', 1.0_4)
    |                                        1
 Error: BOZ literal constant at (1) cannot be an actual argument to 'transfer'

Note, a BOZ is defined in F2023 to be typeless. The requirement on SOURCE in 16.9.212 is SOURCE shall be a scalar or array of any type.

Right. It is not standard conforming. Flang and some other compilers added the extension to allow BOZ to be interchangeable with REAL or INTEGER type. The code in this issue is another case that I think could be added to the extension list.