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 6099C3857015; Wed, 15 Jul 2020 21:10:31 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 6099C3857015
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
 s=default; t=1594847431;
 bh=yd4/hLDNj49p148X6oqo4AOOEdMeF8ZFIrzhI0mRY0Y=;
 h=From:To:Subject:Date:In-Reply-To:References:From;
 b=jlSer3F7UE70tQdo5oUrtBJ4OGbDY1pKJE/7b/1+gnwdQIRwvhAUembcTQcyRdRrR
 LxkjGU4j3PBrDLucK0JtErPgHDxlBzzoSwrjmFFAhavrzTcDMQ3R7MyZP8fpUM23l4
 grRfx2JiS5LyoLztnQUieY9RTcGaahfwZbcp5crA=
From: "burnus at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug testsuite/96212] new test case libgomp.fortran/alloc-3.F fails
 in r11-2101
Date: Wed, 15 Jul 2020 21:10:31 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: testsuite
X-Bugzilla-Version: 11.0
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: burnus at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-96212-4-a6RfiWhxjP@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-96212-4@http.gcc.gnu.org/bugzilla/>
References: <bug-96212-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
X-BeenThere: gcc-bugs@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc-bugs mailing list <gcc-bugs.gcc.gnu.org>
List-Unsubscribe: <http://gcc.gnu.org/mailman/options/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-request@gcc.gnu.org?subject=help>
List-Subscribe: <http://gcc.gnu.org/mailman/listinfo/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Jul 2020 21:10:31 -0000

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

--- Comment #2 from Tobias Burnus <burnus at gcc dot gnu.org> ---
(In reply to Bill Seurer from comment #1)
> After running on a few more machines this appears to be a BE only issue.

alloc-1.F90 uses a proper interface (Fortran module). alloc-3.F uses a head=
er
file with the old-style Fortran 66/77 way of just having
   external subroutine_name
or
   external function_name
   integer function_name  ! <- data type the function returns.

Thus, by this declaration the compiler does not know how the interface actu=
ally
looks like. In principle, it could (and should?!?) deduce the interface from
the first procedure call =E2=80=93 and create the declaration from the use.=
 However, it
doesn't do this.

My bet is that the actually used argument-passing of caller and callee diff=
ers
on PowerPC and, hence, it fails.

Solution?
* XFAIL?
* Changing the way in gfortran how the external-function declaration is
generated?=