[Bug fortran/115260] New: Corruption of derived type data when array temporarys of type occur

[Bug fortran/115260] New: Corruption of derived type data when array temporarys of type occur

[steve.mullerworth at metoffice dot gov.uk]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115260

            Bug ID: 115260
           Summary: Corruption of derived type data when array temporarys
                    of type occur
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: steve.mullerworth at metoffice dot gov.uk
  Target Milestone: ---

Created attachment 58301
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58301&action=edit
Compile with -Og or more to illustrate issue

I have a 2D (or more than 2D) array of a derived type. The derived type
contains one or more allocatable arrays of reals or integers.

If I call a subroutine with a part of the 2D array *such that an array
temporary is created* then data in the arrays within the derived type are
corrupted on return: the first few items of data in each array are corrupted.

The example program demonstrates calling subroutines in a way that don't use
temporary arrays and then in a way that does use temporary arrays, printing the
arrays as it progresses. On return from the final call that results in array
temporaries, the issue is that the arrays of reals and integers have different
values in the first few elements.

The amount of corruption in the allocatable arrays appears to be a certain
number of bits, so a real64 has half the corruption of an integer32. The number
of bits seems platform dependent. Mosty 128 bits on Godbolt Compiler Explorer
and my desktop old-ish Intel (Intel(R) Xeon(R) Gold 6132 CPU @ 2.60GHz). But
256 bits on ARM Genoa (AMD EPYC 7763 64-Core) for some reason – it’s another
64-bit CPU.

Started happening from gcc10.2 up to head of trunk (according to the Compiler
Explorer). Affects -Og or above. -O0 is fine. Use -fcheck=all to show up
creation of array temporaries at last call.

Link to Compiler Explorer example:

https://godbolt.org/z/971evY8sn

[Bug fortran/115260] Corruption of derived type data when array temporarys of type occur

[anlauf at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115260

anlauf at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to work|                            |9.5.0
   Last reconfirmed|                            |2024-05-28
           Priority|P3                          |P4
      Known to fail|                            |10.5.0, 11.4.0, 12.3.0,
                   |                            |13.3.0, 14.1.0, 15.0
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1
           Keywords|                            |wrong-code

--- Comment #1 from anlauf at gcc dot gnu.org ---
Confirmed.

The tree-dump suggests that the unpack frees the component arrays data, idata
so that the final prints access freed memory.

In the testcase this only happens for the explicit-size dummies when they
are intent(inout), but not for intent(in).

[Bug fortran/115260] Corruption of derived type data when array temporarys of type occur

[anlauf at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115260

--- Comment #2 from anlauf at gcc dot gnu.org ---
Created attachment 58346
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58346&action=edit
Reduced testcase

Reduced for subsequent analysis.

[Bug fortran/115260] Corruption of derived type data when array temporarys of type occur

[anlauf at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115260

--- Comment #3 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #2)
> Created attachment 58346 [details]
> Reduced testcase
> 
> Reduced for subsequent analysis.

Further datapoint: replacing the dummy argument

    type(field_type), intent(inout) :: fieldset(1:4)

by

    type(field_type), contiguous    :: fieldset( : )

always leads to corruption.