https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91512
Thomas Koenig <tkoenig at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|--- |10.0 Summary|Fortran compile time |[10 Regression] Fortran |regression. |compile time regression. --- Comment #3 from Thomas Koenig <tkoenig at gcc dot gnu.org> --- (In reply to Sunil Pandey from comment #2) > phase opt and generate : 47.72 ( 97%) 0.24 ( 77%) 48.04 ( > 96%) 118205 kB ( 89%) So, phase_opt_and_generate appears to be something strange. What the patch did was to change the way for subarrays that are packed because they are passed to an old-style argument, like this: module x implicit none contains subroutine bar(a, n) integer, intent(in) :: n integer, intent(in), dimension(n) :: a print *,a end subroutine bar end module x program main use x implicit none integer, parameter :: n = 10 integer, dimension(n) :: a integer :: i a = [(i,i=1,n)] call bar(a(n:1:-1),n) end program main After the patch, the packing is done in the front end, which means that the optimizers can see through it and possibly inline the procedures, or do other optimizations. If these optimizations hit some quadratic (or worse) behavior, this could lead to long compilation times. I would assume that your code has a lot of places where code like the above occurs, is that the case?