Compiler out of memory with too many args to max()

[uha]

The below code compiles successfully and within a second with ifx versions 2024.2.1 and 2025.0.0. With version 2025.2.0 it uses all available memory (10+ GB) and then VS (and other programs) stop responding, I killed it after a few minutes. In the real world application it does report an error: "handle_memory_allocation_error: out of memory" followed by what looks like a stack trace and:
error #5629: **Internal compiler error: abort signal raised** Please report this error along with the circumstances in which it occurred in a Software Problem Report. Note: File and line given may not be explicit cause of this error.
compilation aborted for [...].f90 (code 3)

program max_of_38
  implicit none
  real(8) :: a1,a2,a3,a4,a5,a6,a7,a8,a9,a10
  real(8) :: a11,a12,a13,a14,a15,a16,a17,a18,a19,a20
  real(8) :: a21,a22,a23,a24,a25,a26,a27,a28,a29,a30
  real(8) :: a31,a32,a33,a34,a35,a36,a37,a38
  real(8) :: maxval

  a1=1; a2=2; a3=3; a4=4; a5=5; a6=6; a7=7; a8=8; a9=9; a10=10
  a11=11; a12=12; a13=13; a14=14; a15=15; a16=16; a17=17; a18=18; a19=19; a20=20
  a21=21; a22=22; a23=23; a24=24; a25=25; a26=26; a27=27; a28=28; a29=29; a30=30
  a31=31; a32=32; a33=33; a34=34; a35=35; a36=36; a37=37; a38=38

  maxval = max(a1,a2,a3,a4,a5,a6,a7,a8,a9,a10, &
               a11,a12,a13,a14,a15,a16,a17,a18,a19,a20, &
               a21,a22,a23,a24,a25,a26,a27,a28,a29,a30, &
               a31,a32,a33,a34,a35,a36,a37,a38)

  write(*,*) "Maximum value is:", maxval
end program max_of_38

 The obvious workaround is to split the max() call, apparently it can cope with "just" 19 arguments. 

[dajum81]

I want to say we have seen the compiler using 50+ GB of memory on many small models and dying with out of memory errors as well.  Hoping to see a fix for this soon.

Dave

[garraleta_fortran]

Can't compile

[bflynt1]

Why not use an array instead of 38 variables?

real(8), dimension(38) :: a

a(1) = 1
a(2) = 2
...
a(38) = 38

amax = maxval(a)

[andrew_4619]

Yes is compile for a long time ( 30 seconds) and then throws an error.

The code below works fine using an array constructor which is a quite minimalistic workaround.

program max_of_38
  implicit none
  real(8) :: a1,a2,a3,a4,a5,a6,a7,a8,a9,a10
  real(8) :: a11,a12,a13,a14,a15,a16,a17,a18,a19,a20
  real(8) :: a21,a22,a23,a24,a25,a26,a27,a28,a29,a30
  real(8) :: a31,a32,a33,a34,a35,a36,a37,a38
  real(8) :: maxy

  a1=1; a2=2; a3=3; a4=4; a5=5; a6=6; a7=7; a8=8; a9=9; a10=10
  a11=11; a12=12; a13=13; a14=14; a15=15; a16=16; a17=17; a18=18; a19=19; a20=20
  a21=21; a22=22; a23=23; a24=24; a25=25; a26=26; a27=27; a28=28; a29=29; a30=30
  a31=31; a32=32; a33=33; a34=34; a35=35; a36=36; a37=37; a38=38

  maxy   = maxval([a1,a2,a3,a4,a5,a6,a7,a8,a9,a10, &
               a11,a12,a13,a14,a15,a16,a17,a18,a19,a20, &
               a21,a22,a23,a24,a25,a26,a27,a28,a29,a30, &
               a31,a32,a33,a34,a35,a36,a37,a38])

  write(*,*) "Maximum value is:", maxy
end program max_of_38

[JFH]

In my Linux Ubuntu system that program compiled fast and ran correctly with ifx 2025.2.0

[dajum81]

As the original poster noted in this real program he gets the same error.  This was a sample model, so suggesting work-arounds doesn't help.  The point of a sample model is to give Intel something they can use to debug the compiler.  We get the same error in our huge code, so my hope is that this sample program helps Intel fix the error in the compiler.  Trying to isolate the problem in a huge code isn't easy.   @uha did you submit a bug to intel? Or hoping that they get it from here?

Dave

[andrew_4619]

Yes I understand that it is a bug and needs some fix. The "workaround" I suggested is a simple solution of changing max to maxval and adding [ ]. The intrinsic maxval is designed to work on arrays that can have large numbers of  elements, I would expect the intrinsic max would be designed to be efficient with a small number of args normally two in 99.9% of usage!

[uha]

Dave, I have not submitted a bug report, in the past usually Intel have picked it up from here.

Indeed the purpose of the post was to demonstrate the issue, still I like the workaround idea of converting to an array: It´s even less intrusive than splitting the call! I also agree that it is pobably a rare case to have so many args to max. It´s one of these dusty corners of our code, unchanged for 20 years or more...