# Curious result with ASSOCIATE

**URL:** <https://fortran-lang.discourse.group/t/curious-result-with-associate/9593>\
**Category:** Help\
**Created:** [April 17, 2025, 9:41am UTC](https://fortran-lang.discourse.group/t/curious-result-with-associate/9593 "2025-04-17T09:41:08Z")\
**Posts on this page:** 12\
**Page:** 1

<div class="post-metadata">

**Author:** ![Arjen](https://avatars.discourse-cdn.com/v4/letter/a/b9bd4f/32.png) [@Arjen](https://fortran-lang.discourse.group/u/Arjen)\
**Post date:** [April 17, 2025, 9:41am UTC](https://fortran-lang.discourse.group/t/curious-result-with-associate/9593/1 "2025-04-17T09:41:09Z")

</div>

I am trying to use ASSOCIATE in a somewhat creative way:

```fortran
program moa_assoc
    implicit none

    integer, parameter :: n = 20
    real, dimension(n,n) :: x, y

    x = 1.0

    !
    ! Use x also for result
    !
    associate( a => x(3:n,:), b => x(1:n-2,:), c => x(2:n-1,:) )
        c = a + b
    end associate

    write(*,'(20f5.1)') x(:,2)

    !
    ! Use y instead
    !
    x = 1.0
    y = 1.0

    associate( a => x(3:n,:), b => x(1:n-2,:), c => y(2:n-1,:) )
        c = a + b
    end associate

    write(*,'(20f5.1)') y(:,2)
end program moa_assoc

```

While I will probably get the right answer in the full application I have in mind, I am curious as to the difference between the two ASSOCIATE blocks. The result is this:

```auto
  1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 9.0 10.0 11.0 12.0 13.0 14.0 15.0 16.0 17.0 18.0 19.0 1.0
  1.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 1.0

```

I expected the first line to be the same as the second one, but either I am mistaken or there is something odd about this use of ASSOCIATE. I got this result with both gfortran and ifx.

So, is my understanding of ASSOCIATE less than perfect or is the outcome wrong?

---

<div class="post-metadata">

**Author:** ![vmagnin](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/vmagnin/32/28_2.png) [@vmagnin](https://fortran-lang.discourse.group/u/vmagnin)\
**Post date:** [April 17, 2025, 9:53am UTC](https://fortran-lang.discourse.group/t/curious-result-with-associate/9593/2 "2025-04-17T09:53:27Z")

</div>

In the first case, in the implicit loops, I think `x(2,:)` is modified then used to compute `x(3,:)`, etc. In the second case, it is `y()` which is modified step by step and it does not impact the following computations.

---

<div class="post-metadata">

**Author:** ![Arjen](https://avatars.discourse-cdn.com/v4/letter/a/b9bd4f/32.png) [@Arjen](https://fortran-lang.discourse.group/u/Arjen)\
**Post date:** [April 17, 2025, 10:01am UTC](https://fortran-lang.discourse.group/t/curious-result-with-associate/9593/3 "2025-04-17T10:01:55Z")

</div>

Indeed, that is how I explain the result myself, but the question is: is this the correct behaviour? I would think that the ASSOCIATE construct would, magically, result in code where array operations are used, as that is superficially the nature of the statement. In that case, the left-hand side should remain untouched until the right-hand side has been evaluated.

---

<div class="post-metadata">

**Author:** ![vmagnin](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/vmagnin/32/28_2.png) [@vmagnin](https://fortran-lang.discourse.group/u/vmagnin)\
**Post date:** [April 17, 2025, 10:04am UTC](https://fortran-lang.discourse.group/t/curious-result-with-associate/9593/4 "2025-04-17T10:04:11Z")

</div>

> [@Arjen](#):
>
> In that case, the left-hand side should remain untouched until the right-hand side has been evaluated.

It would imply a copy operation, either on the left-hand side (before computation) or the right-hand side (after computation).

---

<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:** [April 17, 2025, 10:41am UTC](https://fortran-lang.discourse.group/t/curious-result-with-associate/9593/5 "2025-04-17T10:41:17Z")

</div>

Once again, the standard text is quite vague on some important points, and I really can’t tell if your code is standard conforming or not…

But I’m not surprised by the result: for, I usually see the ASSOCIATE construct as it is was a kind of inlined internal subroutine, and I see the associate names as if they were dummy arguments. So, you are in an equivalent situation where you are modifying a dummy argument that is aliased to another dummy argument, which is forbidden.

---

<div class="post-metadata">

**Author:** ![Arjen](https://avatars.discourse-cdn.com/v4/letter/a/b9bd4f/32.png) [@Arjen](https://fortran-lang.discourse.group/u/Arjen)\
**Post date:** [April 17, 2025, 11:08am UTC](https://fortran-lang.discourse.group/t/curious-result-with-associate/9593/6 "2025-04-17T11:08:54Z")

</div>

Thanks, my application would use the second kind of use, so there the problem of updating an aliased dummy argument as it were, would not play a role. It simply surprised me, henve my question.

---

<div class="post-metadata">

**Author:** ![urbanjost](https://avatars.discourse-cdn.com/v4/letter/u/0ea827/32.png) [@urbanjost](https://fortran-lang.discourse.group/u/urbanjost)\
**Post date:** [April 17, 2025, 12:42pm UTC](https://fortran-lang.discourse.group/t/curious-result-with-associate/9593/7 "2025-04-17T12:42:39Z")

</div>

Indeed initially surprising, but I think the standard does declare that non-conforming as it does say in the description for ASSOCIATE:

```
  • If selector is not a variable or is a variable that has a vector
    subscript, associate‐name shall not appear in a variable definition
    context.

```

So since C has a vector subscript, it cannot appear on the LHS, if I am reading that right.  
But I would then expect the compiler to produce an error or warning. Is the compiler obligated to produce an error or warning? Am I reading that wrong? As that says that using Y with a subscript for C is also not allowed.

---

<div class="post-metadata">

**Author:** ![jwmwalrus](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/jwmwalrus/32/4483_2.png) [@jwmwalrus](https://fortran-lang.discourse.group/u/jwmwalrus)\
**Post date:** [April 17, 2025, 1:10pm UTC](https://fortran-lang.discourse.group/t/curious-result-with-associate/9593/8 "2025-04-17T13:10:08Z")

</div>

> [@urbanjost](#):
>
> So since C has a vector subscript, it cannot appear on the LHS,

I think that by `vector subscript`, the standard refers to something like `c([1,2,4,5])`, which is not the case here.

Here `c => x(2:n-1,:)` is a `variable` (i.e., `designator` → `array-section`, etc.), not an expression.

---

<div class="post-metadata">

**Author:** ![urbanjost](https://avatars.discourse-cdn.com/v4/letter/u/0ea827/32.png) [@urbanjost](https://fortran-lang.discourse.group/u/urbanjost)\
**Post date:** [April 17, 2025, 3:09pm UTC](https://fortran-lang.discourse.group/t/curious-result-with-associate/9593/9 "2025-04-17T15:09:28Z")

</div>

Ahhh, that makes more sense. I was reading that simply as “subscript”. I do not think I have ever used “vector subscripts” so I did not even realize that had a different meaning than that.

Same goes for multiple-subscript, subscript-triplet, multiple-subscript-triplet  
for the most part.

The compilers back that up, reporting an error if “J=123” is uncommented.

```fortran
! vector-subscript
integer :: i(3)

   i=[10,20,30]
   write(*,*)i([3,2,1])

   i([2,3,1])=[(k,k=11,33,11)]
   write(*,*)i

   i=[10,20,30]
   associate(j=>i([2,3,1]))
   write(*,*)j
   !j=123 ! DOES PRODUCE COMPILE-TIME ERROR

end associate

end

```

---

<div class="post-metadata">

**Author:** ![RonShepard](https://avatars.discourse-cdn.com/v4/letter/r/a3d4f5/32.png) [@RonShepard](https://fortran-lang.discourse.group/u/RonShepard)\
**Post date:** [April 17, 2025, 4:52pm UTC](https://fortran-lang.discourse.group/t/curious-result-with-associate/9593/10 "2025-04-17T16:52:15Z")

</div>

> [@PierU](#):
>
> But I’m not surprised by the result: for, I usually see the ASSOCIATE construct as it is was a kind of inlined internal subroutine, and I see the associate names as if they were dummy arguments.

I think this is correct, but I don’t see those kinds of limitations (like aliasing restrictions) mentioned in the standard.

If you add the statements

```auto
    x = 1.0
    x(2:n-1,:) = x(3:n,:) + x(1:n-2,:)
    write(*,'(20f5.1)') x(:,2)

```

then with gfortran you see that the, presumably correct, results are the same as using the separate variable `y(:,:)` on the lhs.

Also, if you replace `c=a+b` with `x(2:n-1,:)=a+b` in the first ASSOCIATE block, then the same, presumably incorrect, results are generated. In this case, the “dummy arguments” would still violate the aliasing restrictions, so it makes the same mistake when computing the results.

That still does not say whether this is a programmer error or a compiler error, just that the ASSOCIATE restrictions appear to be consistent with dummy argument restrictions for this one compiler.

---

<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:** [April 18, 2025, 10:50am UTC](https://fortran-lang.discourse.group/t/curious-result-with-associate/9593/11 "2025-04-18T10:50:00Z")

</div>

> [@RonShepard](#):
>
> I think this is correct, but I don’t see those kinds of limitations (like aliasing restrictions) mentioned in the standard.

I can’t find such restrictions either. This means that in theory the example posted by the OP should work (i.e. the 2 results should be identical).

But this puts a lot of burden on the compiler to sort out what is aliased to what, because the user can’t help the compiler with the “pointer/target” attributes here.

---

<div class="post-metadata">

**Author:** ![Arjen](https://avatars.discourse-cdn.com/v4/letter/a/b9bd4f/32.png) [@Arjen](https://fortran-lang.discourse.group/u/Arjen)\
**Post date:** [April 18, 2025, 12:26pm UTC](https://fortran-lang.discourse.group/t/curious-result-with-associate/9593/12 "2025-04-18T12:26:42Z")

</div>

Well, it does not really matter for my use case, but it was surprising. I have always been surprised anyhow by the flexibility of ASSOCIATE.
