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

Linux: Crash Using Variable Format Expressions ('<>')

uha
Novice
666 Views

I´m compiling (ifx -o test -O0 -g -traceback -check all MyTest.f90) the following code (MyTest.f90) on Linux (wsl/Ubuntu):

program mytest
  implicit none
  integer :: n = 5
  write(*, '(i5)'  ) 12345
  write(*, '(i<n>)') 12345
end program

 Running it the first write statement does as expected, the second gives a stack overflow when "-check" is specified or segmentation fault without "-check" or when using ifort instead.

 

ifx version is 2024.2.1, ifort 2021.13.1.

No problem with the same code on Windows with oneApi 2025. I have not yet tried 2025 on Linux.

 

0 Kudos
1 Solution
Steve_Lionel
Honored Contributor III
313 Views

I am not Intel, but I have some theories as to why there is a difference. VFEs are a very tricky thing to implement, and I'd guess that they had to be shoehorned into LLVM somehow and the implementation is suboptimal, especially in the presence of OpenMP. If I were still in Intel support, I would not consider this a bug, but rather a usage that deserves some further investigation.

My recommendation is to recode the application to not use this ancient extension. The standard Fortran language now has features that can eliminate the need for VFEs.

View solution in original post

8 Replies
andrew_4619
Honored Contributor III
647 Views
<n> should work but it is not standard Fortran it is an extension. There are plenty of ways of doing things with standard conforming Fortran, if you want minimum width for example just ust i0 format.
uha
Novice
629 Views

Thanks for pointing out this is non-standard, I was not aware of that.

0 Kudos
uha
Novice
569 Views

The reason I even started building on Linux was the hope to find the reason for a major performance degression in our production code (windows) moving from ifort to ifx. Now here you go, it is the use of variable format expressions!

In one module I use it to indent logging. I made a comparison of this module´s runtime for combinations of using/not using variable format expressions (<x>?), ifx/ifort and different numbers of threads as the code in question is omp-parallelized (all writes in locked sections of course).

The result shows that with ifort there is no significant performance difference with/without variable format expressions. Using ifx however performance is significantly worse with variable format expressions even for single threaded runs, and as more threads are added performance plumets.

These are the test results:

 

<x>?   | Compiler | Threads | runtime
-------+----------+---------+--------
TRUE   | ifx      | 1       |  2.545  
TRUE   | ifx      | 2       |  3.832  
TRUE   | ifx      | 4       |  9.882  
TRUE   | ifx      | 8       | 17.48  
TRUE   | ifort    | 1       |  0.952  
TRUE   | ifort    | 2       |  0.542  
TRUE   | ifort    | 4       |  0.337  
TRUE   | ifort    | 8       |  0.321  
FALSE  | ifx      | 1       |  0.845  
FALSE  | ifx      | 2       |  0.5    
FALSE  | ifx      | 4       |  0.35   
FALSE  | ifx      | 8       |  0.302  
FALSE  | ifort    | 1       |  1.045  
FALSE  | ifort    | 2       |  0.473  
FALSE  | ifort    | 4       |  0.293  
FALSE  | ifort    | 8       |  0.372  

 

I´ll replace all variable format expressions, no problem - I´m mainly reporting this for other´s reference. Maybe it would make sense to warn against using this feature while it behaves like this? Or on Linux have compilation fail rather than execution if it cannot be fixed?

0 Kudos
andrew_4619
Honored Contributor III
500 Views
If you have standards checking on you will get warnings. As to why there is a speed difference I have no ideas.
0 Kudos
uha
Novice
345 Views

Intel, do you acknowledge this as a bug?

0 Kudos
Steve_Lionel
Honored Contributor III
314 Views

I am not Intel, but I have some theories as to why there is a difference. VFEs are a very tricky thing to implement, and I'd guess that they had to be shoehorned into LLVM somehow and the implementation is suboptimal, especially in the presence of OpenMP. If I were still in Intel support, I would not consider this a bug, but rather a usage that deserves some further investigation.

My recommendation is to recode the application to not use this ancient extension. The standard Fortran language now has features that can eliminate the need for VFEs.

uha
Novice
311 Views

Thanks for the insight, Steve, very interesting, especially the possible relation to OpenMP. I agree it is not a big deal to replace VFE, although I kind of like the readability. I have already replaced all usages now, still a bit curious about how this will be handled.

0 Kudos
Steve_Lionel
Honored Contributor III
245 Views

Unless one of the Intel support people want to pick this up, I'd assume it won't be looked at unless someone with paid support complains about it. Even if they do, I'd expect the reaction of the developers would be to treat it as low priority, and I would not blame them.

Reply