ifx list of flags enabled with -O2

[Miguel_V_]

Hello,

Background: We are switching from ifort to ifx our simulation code of about 25000 Fortran routines, when we compile it with ifx using -O1, our non-regression tests work, but when we compile it with -O2,  a few hundreds tests fail (out of 50000 tests), due to several causes, like crashes, or numerical errors.

It is really hard to investigate/debug where the errors are, because the numerical simulation tests could be quite large in terms of size or time. What we would like to do is to disable only the optimization flag(s) that are causing the problem. Just switching from -O2 to O1 is not an option due huge performance loss.

The question is: What are the optimization flags enabled in ifx when you use -O2 ? For both, Linux and Windows. Currently we are using ifx 2025.2.1. I searched the Intel documentation, but I couldn't find the specific list of flags.

We would like to try removing the optimization flags one by one until we find the one(s) that are causing the test to fail. We cannot isolate minimum code examples for bug reports, because our code is quite large and complex.

Thanks in advance.

[Arjen_Markus]

You might try to find this out using the compiler_options() intrinsic function. The result may not be detailed, but it might work. If you were to use the gfortran compiler, you'd get a very long list. ifx and ifort give a trifle more compact answers.

[Miguel_V_]

Thanks a lot Arjen, I didn't know about this intrinsic. Unfortunately ifx doesn't give extra details.

      program compiler
      use iso_fortran_env
      print '(4a)', 'This file was compiled by ',
     &        compiler_version(), ' using the options ',
     &        compiler_options()
      end

$ ifx -O2 -o compiler compiler.f 
$ ./compiler 
This file was compiled by Intel(R) Fortran Compiler for applications running on Intel(R) 64, Version 2025.2.1 Build 20250806 using the options -O2 -o compiler

Indeed, gfortran gives more information:

$ gfortran -O2 -o compiler compiler.f 
$ ./compiler 
This file was compiled by GCC version 14.2.1 20250110 (Red Hat 14.2.1-13) using the options -ffixed-form -mtune=generic -march=x86-64-v2 -O2 -foffload-options=-l_GCC_gfortran -foffload-options=-l_GCC_m -fpre-include=/usr/include/finclude/math-vector-fortran.h

[MarcGrodent]

Please have a look at this main page from the compiler reference documentation:

https://www.intel.com/content/www/us/en/docs/fortran-compiler/developer-guide-reference/2025-2/compiler-options-001.html 

You will find some interesting topics listed at the end.

For example:

- Optimization options (giving details about the -O2 level):

https://www.intel.com/content/www/us/en/docs/fortran-compiler/developer-guide-reference/2025-2/optimization-options.html 

https://www.intel.com/content/www/us/en/docs/fortran-compiler/developer-guide-reference/2025-2/o-001.html 

- Optimization report options:

https://www.intel.com/content/www/us/en/docs/fortran-compiler/developer-guide-reference/2025-2/optimization-report-options.html 

[Miguel_V_]

Thank you MarcGrodent,

I already checked these links. But for example, it says that -O2 enables 'dead-code elimination', but it doesn't say which flag controls it (maybe there is no flag). The list of optimization flags doesn't say which ones are enabled on -O1, nor -O2, nor -O3.

I would like to know specifically for -O2 to avoid recompiling the whole project so many times to test combinations of flags, and then run thousands of non-regression tests for each combination.

In particular we detected we are experiencing 'dead variable elimination' on some routines, but it's dificult to trace on which ones, at some point the program just gives incorrect results using ifx -O2.

[Steve_Lionel]

There is no such list - optimization levels do not consist of a set of separate options. There are many options to adjust optimization, but the O switch is not a shorthand for a set of other switches, as some optimizations are tied only to the O level.

I agree with the suggestion to turn on optimization reporting. I'd also suggest using "binary search" to find which source(s), when compiled with -O2, cause the problem.  You compile half with O2 and half with O0 or O1 - is the problem still there? Take the half compiled with O2 and compile half with O1, etc. When I was doing compiler support, this was the fastest way of focusing on the problem.

[Miguel_V_]

Finding the sources where the incorrect results are is not the problem. The problem is that the optimization done witn ifx -O2 is incorrect. The code works correctly (all 50000 non-regression tests) when compiled with ifort -O2 and with ifx -O1.

We have identified several routines where the results are incorrect, and we could compile these routines with only -O1. But we would rather not, because of the performance loss. We would like to know what optimization flags are safe to enable beside -O1. For that we would like to know which ones are the equivalent to using -O2. If there is no such list we will need to try the full list of advanced-optimization one by one, which is costly in time and resources.

I did try the optimization report, in a specific routine where we detected a problem with dead variables optimization, but the report doesn't give information about the optimized variable. The report gives information that optimization has been done in some loops of the routine. That's was not useful for our problem.

We could also start declaring variables as VOLATILE, but that doesn't really solve the problem of dead variables optimization. Because  it's not clear which ones need to be declared like that. And we would need to start doing that in thousands of routines.

[MarcGrodent]

Have you considered updating the Fortran compiler?

The version you're using (ifx 2025.2.1) was released a year ago. As far as I know, quite a few improvements and bug fixes have been made since then. I'm not saying it will solve all your issues, but it's probably something worth trying.

[Steve_Lionel]

If I were still working for Intel, I'd ask you to put together as small a reproducer as you can and submit it. I'd ask that you also include the full application project and any data needed to reproduce. Since you say you have already identified the affected sources, this may be easier. But I also agree with Marc that you should first update the compiler to see if the problem is still there.