# Very big ramble about associates

**URL:** <https://fortran-lang.discourse.group/t/very-big-ramble-about-associates/7594>\
**Category:** Uncategorized\
**Created:** [March 11, 2024, 8:40pm UTC](https://fortran-lang.discourse.group/t/very-big-ramble-about-associates/7594 "2024-03-11T20:40:20Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![gronki](https://avatars.discourse-cdn.com/v4/letter/g/a88e4f/32.png) [@gronki](https://fortran-lang.discourse.group/u/gronki)\
**Post date:** [March 11, 2024, 8:40pm UTC](https://fortran-lang.discourse.group/t/very-big-ramble-about-associates/7594/1 "2024-03-11T20:40:20Z")

</div>

So I left my code unattended for about 2 years. One of the big selling points of Fortran, at least the way I see it, is that the codes should not “age” as fast as some younger ecosystems, such as Python. Meanwhile, jumping from gfortran 12 to 13, my code would not compile anymore, with an `associate` statement that I would consider correct:

```auto
././src/findstar.f90:96:49:

   96 | associate (ilo => max(xymax(1) - rslice, 1), &
      | 1
Error: Symbol ‘ilo’ at (1) has no IMPLICIT type
<ERROR> Compilation failed for object " src_findstar.f90.o "
<ERROR> stopping due to failed compilation

```

Moving over to `ifort` or `ifx`, both segfault at the second line of this little block:

```fortran
          associate (calibarea => frame_flat % data(33:n1-32, 33:n2-32))
            frame_flat % data(:,:) = frame_flat % data / average_safe(calibarea)
          end associate

```

where `frame_flat%data` is an associated (yes, tested that) `real` pointer and `average_safe` is a boring function that basically averages over non-nan values:

```fortran

  pure function average_safe_2d(x) result(m)
    use iso_fortran_env, only: int64
    real(fp), intent(in) :: x(:,:)
    real(fp) :: m
    integer :: i, j
    integer(int64) :: n

    m = 0; n = 0
    do j = 1, size(x, 2)
      do i = 1, size(x, 1)
        if (ieee_is_normal(x(i,j))) then
          m = m + x(i,j)
          n = n + 1
        end if
      end do
    end do
    m = m / n
  end function

```

Making the code to compile with either of them would require changing many, many places in the code for no good reason… so I resigned to just compiling and running my code in a Docker container with gfortran 12, which last seemed to worked. What to do…

Have a sunny day!  
Dominik

---

<div class="post-metadata">

**Author:** ![PierU](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/pieru/32/1848_2.png) [@PierU](https://fortran-lang.discourse.group/u/PierU)\
**Post date:** [March 12, 2024, 7:39am UTC](https://fortran-lang.discourse.group/t/very-big-ramble-about-associates/7594/2 "2024-03-12T07:39:18Z")

</div>

Could you post a MRE that shows the problem?

---

<div class="post-metadata">

**Author:** ![gronki](https://avatars.discourse-cdn.com/v4/letter/g/a88e4f/32.png) [@gronki](https://fortran-lang.discourse.group/u/gronki)\
**Post date:** [November 12, 2024, 11:33pm UTC](https://fortran-lang.discourse.group/t/very-big-ramble-about-associates/7594/3 "2024-11-12T23:33:01Z")

</div>

Late update, but whatever regression it was between gfortran 12 and 13 that caused these errors, was resolved in 14, and my code now compiles correctly again. I think I just doubted for a moment that choosing Fortran as a way to write long-lasting code that does not obsolete was a good choice. But after update everything seems to be back on track 🙂

I did not post the minimal reproducible example because i could not find one. Any kind of reduction in the code made the error disappear and I failed to produce it – otherwise I would add a gfortran bug.

---

<div class="post-metadata">

**Author:** ![ivanpribec](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/ivanpribec/32/3290_2.png) [@ivanpribec](https://fortran-lang.discourse.group/u/ivanpribec)\
**Post date:** [November 13, 2024, 1:08am UTC](https://fortran-lang.discourse.group/t/very-big-ramble-about-associates/7594/4 "2024-11-13T01:08:35Z")

</div>

A pointer error occurs in the associate snippet I posted here: [Pure procedure and intent(out) polymorphic pointer argument - #15 by ivanpribec](https://fortran-lang.discourse.group/t/pure-procedure-and-intent-out-polymorphic-pointer-argument/8830/15) (gfortran accepts it, ifx and flang reject it)

The error about the missing implicit type in gfortran still occurs under some circumstances: [117347 – Associate with derived type array constructor](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117347)

I hope it will be fixed eventually. (Thanks to all gfortran volunteers!)