From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id C1E263858C2C; Sat, 25 Nov 2023 10:11:03 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C1E263858C2C
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1700907063;
	bh=LArg/fK8rxFVaP0jTyhFK/vGcDovlts7P8cBHuBVkBo=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=s4tI8guimHaQlqMhLcgDazQsJXXOSvSuNlMft/zOAq5/V217/TRkv6i61yRYDBogn
	 cL5Jkm0AF4RLYai7SjC0nRweUhxz2vUCzQ5XPNbikSajmwMSXS+0bjZVWEqdVeRvPx
	 9arvdsYfTeGx2/7mgsZazxR0RGxy4cDqyI/uHjzI=
From: "fxcoudert at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/100651] [11/12/13/14 Regression] Weird memory
 corruption with multiple triggers
Date: Sat, 25 Nov 2023 10:11:02 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Version: 11.1.0
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: fxcoudert at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P4
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 11.5
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: cc cf_reconfirmed_on cf_gcctarget
Message-ID: <bug-100651-4-vmWzw6CZZ9@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-100651-4@http.gcc.gnu.org/bugzilla/>
References: <bug-100651-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
List-Id: <gcc-bugs.sourceware.org>

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

Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fxcoudert at gcc dot gnu.o=
rg
   Last reconfirmed|2021-07-29 00:00:00         |2023-11-25
             Target|x86_64-linux-gnu,           |
                   |x86_64-apple-darwin         |

--- Comment #10 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org>=
 ---
Further reduced to this:

meau /tmp $ cat a.f90
program main
  character(:), allocatable :: err_msg
  call to_int(err_msg)
  print *, 'allocated :', allocated(err_msg)
  print *, err_msg(1:7)
  print *, 'len :      ', len(err_msg)
  print *, 'err_msg :  ', err_msg
contains
  subroutine assert_code(err_msg)
    character(:), optional, allocatable :: err_msg
    err_msg =3D 'foo bar'
  end
  subroutine to_int(err_msg)
    character(:), optional, allocatable :: err_msg
    call assert_code(err_msg)
  end
end
meau /tmp $ gfortran a.f90 -O0 -g && ./a.out
 allocated : T
 foo bar
 len :          39026212
Operating system error: Cannot allocate memory
Memory allocation failure in xrealloc


The problem is in the code generated for the to_int subroutine, handling the
optional aspect. We can see above that the string is allocated and set
correctly. However, the length is not correctly set. You can see from the d=
ump:

__attribute__((fn spec (". w ")))
void to_int (character(kind=3D1)[1:*_err_msg] * * err_msg, integer(kind=3D8=
) *
_err_msg)
{
  {
    character(kind=3D1)[1:*_err_msg] * * D.3001;
    integer(kind=3D8) D.3002;

    D.3001 =3D err_msg !=3D 0B ? err_msg : 0B;
    D.3002 =3D err_msg !=3D 0B ? *_err_msg : 0;
    assert_code (D.3001, &D.3002);
  }
}

The string length passed as second argument to assert_code is a pointer to a
local variable, and its value will not be propagated back into _err_msg (the
string length passed to to_int).=