INTEGER PARAMETER initialized with BOZ literal retains its BOZ literal status

[jwmwalrus]

Hi.

The latest IFX seems to allow initialization of INTEGER PARAMETERs with BOZ literals, but further usage does not interpret such parameters as INTEGERs.

The following code

use ISO_C_BINDING
implicit none
integer(C_INT), parameter :: IN_CLOSE_WRITE = z'00000008'                       !! Writtable file was closed
integer(C_INT), parameter :: IN_CLOSE_NOWRITE = z'00000010'                     !! Unwrittable file closed
integer(C_INT), parameter :: IN_CLOSE = ior(IN_CLOSE_WRITE, IN_CLOSE_NOWRITE)   !! Close
end

Throws this error

$ ifx -V -stand f2023 -standard-semantics /media/vmshare/ior_boz.f90 
Intel(R) Fortran Compiler for applications running on Intel(R) 64, Version 2025.0.1 Build 20241113
Copyright (C) 1985-2024 Intel Corporation. All rights reserved.

 Intel(R) Fortran 25.0-1205.1
/media/vmshare/ior_boz.f90(5): error #8336: The arguments I and J must not both be boz-literal-constant.   [IOR]
integer(C_INT), parameter :: IN_CLOSE = ior(IN_CLOSE_WRITE, IN_CLOSE_NOWRITE)   !! Close
----------------------------------------^
compilation aborted for /media/vmshare/ior_boz.f90 (code 1)
debian@d

As I understand it, a BOZ literal is untyped, until assigned to an object with a specific type.

So my questions: is the code standard conforming but the feature is not ready yet in IFX?  Or are INTEGER PARAMETERs supposed to propagate its "initialized-through-boz-literal" status?

[Steve_Lionel]

The code is conforming to F2023, and BOZ status does not "propagate". You've declared the entities as INTEGER, so that's what they are. Intel Fortran has allowed using a BOZ constant to set the value of a PARAMETER for many, many years (as did DEC/Compaq Fortran before it.) This error message is puzzling to me.

[jwmwalrus]

---

@Steve_Lionel wrote:

Intel Fortran has allowed using a BOZ constant to set the value of a PARAMETER for many, many years...

---

Yes, I meant to say, "...without a warning when the -stand flag is given", which is the behavior I get with ifort.

Thanks for confirming the code is standard conforming, and that the error is an odd one.

[Xiaoping_D_Intel]

A bug report has been opened. We will fix it in the future product.

[Ron_Green]

This issue was fixed in version 2025.2.0

[jwmwalrus]

Hi.

I have a variation of this one, using enums:

use ISO_C_BINDING
implicit none

enum, bind(C)
    enumerator :: IN_CLOSE_WRITE = z'00000008'                       !! Writtable file was closed
    enumerator :: IN_CLOSE_NOWRITE = z'00000010'                     !! Unwrittable file closed
    enumerator :: IN_CLOSE = ior(IN_CLOSE_WRITE, IN_CLOSE_NOWRITE)   !! Close
end enum

print*,IN_CLOSE_WRITE
end

The latest ifx throws

$ ifx -V boz-enums.f90
Intel(R) Fortran Compiler for applications running on Intel(R) 64, Version 2025.3.3 Build 20260319
Copyright (C) 1985-2026 Intel Corporation. All rights reserved.

 Intel(R) Fortran 25.0-1601.5
boz-enums.f90(7): error #8336: The arguments I and J must not both be boz-literal-constant.   [IOR]
    enumerator :: IN_CLOSE = ior(IN_CLOSE_WRITE, IN_CLOSE_NOWRITE)   !! Close
-----------------------------^
compilation aborted for boz-enums.f90 (code 1)

So, my questions once again: Since an enumerator doesn't explicitly state integer(C_INT) as type, is is the compiler right at complaining here? Is the code standard-conforming?

[FortranFan]

---

@jwmwalrus wrote:

..

The latest ifx throws

$ ifx -V boz-enums.f90
Intel(R) Fortran Compiler for applications running on Intel(R) 64, Version 2025.3.3 Build 20260319
Copyright (C) 1985-2026 Intel Corporation. All rights reserved.

 Intel(R) Fortran 25.0-1601.5
boz-enums.f90(7): error #8336: The arguments I and J must not both be boz-literal-constant.   [IOR]
    enumerator :: IN_CLOSE = ior(IN_CLOSE_WRITE, IN_CLOSE_NOWRITE)   !! Close
-----------------------------^
compilation aborted for boz-enums.f90 (code 1)

..

@Igor_V_Intel / @Xiaoping_D_Intel  / @Shiquan_Su :

It appears IFX treats IN_CLOSE_WRITE / IN_CLOSE_NOWRITE as "boz-literal-constant" in OP's code rather than as enumerators viz. named integer constants.  May you please discuss with Intel Fortran team and follow up with an incident report as appropriate?

Thank you,

[Igor_V_Intel]

Thank you for reporting it. Yes, it is a bug and I escalated it (CMPLRLLVM-75261)

[jwmwalrus]

Thanks for the notification, @Ron_Green .

This is a huge step in my attempt to migrate from ifort to ifx ---since I have like a million BOZ-literals that were never wrapped in INT(...) (I just suppresed the specific ifort warning).

[Steve_Lionel]

The code is not standard conforming as the standard does not allow a BOZ literal as an interoperable enumerator value. To make this standard conforming, place the BOZ literals inside INT().

[jwmwalrus]

Hi @Steve_Lionel , thanks for the reply.

So, since the code is not standard conforming, it's actually a regression in regards to ifort's behavior (which is able to compile the code without issue).

$ ifort -V -diag-disable=10448 -standard-semantics -stand f23 boz-enums.f90 && ./a.out 
Intel(R) Fortran Intel(R) 64 Compiler Classic for applications running on Intel(R) 64, Version 2021.13.1 Build 20240703_000000
Copyright (C) 1985-2024 Intel Corporation.  All rights reserved.

 Intel(R) Fortran 2021.13.1-1693
GNU ld (GNU Binutils for Debian) 2.44
 8

 ifort doesn't even throw a warning, though ---as it does for non-int-wrapped BOZ literals anywhere else.

[jwmwalrus]

@Steve_Lionel I see that the standards committee has ongoing work related to C23's explicit underlying type (i.e., a KIND selector) for interoperable enums. Would that work (if it makes it to F2028) lift the no-BOZ restriction? I mean

enum(KIND = C_LONG), bind(C)
    enumerator :: IN_CLOSE_WRITE = z'00000008'                       !! Writtable file was closed
    enumerator :: IN_CLOSE_NOWRITE = z'00000010'                     !! Unwrittable file closed
    enumerator :: IN_CLOSE = ior(IN_CLOSE_WRITE, IN_CLOSE_NOWRITE)   !! Close
end enum

would effectively be the same as `integer(C_LONG), parameter ...`, wouldn't it?

[Steve_Lionel]

I was mistaken in saying that your code was nonstandard - the standard allows a BOZ as "the initialization for a named constant or variable of type integer or real". So, the compiler introduced a bug here. The BOZ is implicitly converted to the type of the named constant and should not carry forward its origin as a BOZ. My apologies for misrepresenting things earlier.

[jwmwalrus]

Thanks for the reply and verification.

So, if the code is standard-conforming, the issue is the same as before ---i.e., they fixed it for PARAMETER, but not for ENUMERATOR.