From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 71681 invoked by alias); 8 May 2015 11:54:25 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 71662 invoked by uid 89); 8 May 2015 11:54:24 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients X-HELO: mout.gmx.net Received: from mout.gmx.net (HELO mout.gmx.net) (212.227.17.21) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Fri, 08 May 2015 11:54:23 +0000 Received: from localhost ([88.75.104.20]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MTwYX-1YiCNe35QP-00Qg2Z; Fri, 08 May 2015 13:54:19 +0200 Date: Fri, 08 May 2015 11:54:00 -0000 From: Andre Vehreschild To: Mikael Morin Cc: GCC-Patches-ML , GCC-Fortran-ML Subject: Re: [Patch, fortran, pr65894, v1] [6 Regression] severe regression in gfortran 6.0.0 Message-ID: <20150508135417.0e15f8d1@gmx.de> In-Reply-To: <554B9447.9060701@sfr.fr> References: <20150507115242.10f4061c@gmx.de> <554B9447.9060701@sfr.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-UI-Out-Filterresults: notjunk:1; X-SW-Source: 2015-05/txt/msg00647.txt.bz2 Hi Mikael, at first I tried to fix this issue with the scalarizer, too, but I could not grasp how the scalarizer was working. Do you have any documentation, how it= is meant to be? I mean, I have read the comments in the code, but those are sp= arse and the multitude of routines the scalarizer is split up into doesn't help either. Anyway, because not a single line of code from my patch is left, this has t= o be your patch now. Thanks for finding a better solution.=20 I do not have the privileges to do a review so I can't help you there. Good luck finding a reviewer. Regards, Andre On Thu, 07 May 2015 18:35:19 +0200 Mikael Morin wrote: > Le 07/05/2015 11:52, Andre Vehreschild a =C3=A9crit : > > Hi all, > >=20 > > my work on pr60322 caused a regression on trunk. This patch fixes it. T= he > > regression had two causes: > > 1. Not taking the correct attribute for BT_CLASS objects with allocatab= le > > components into account (chunk 1), and > > 2. taking the address of an address (chunk 2). When a class or derived = typed > > scalar object is to be returned as a reference and a scalarizer is > > present, then the address of the address of the object was returned. The > > former code was meant to return the address of an array element for whi= ch > > taking the address was ok. The patch now prevents taking the additional > > address when the object is scalar. > >=20 > Hello, >=20 > The "chunk 2" fix should go in gfc_conv_expr, so that > gfc_add_loop_ss_code's "can_be_null_ref" condition matches the one in > gfc_conv_expr. Both functions work together, if references are > generated in gfc_add_loop_ss_code, they should be used as reference in > gfc_conv_expr. Same if values are generated. >=20 > About the condition of the first chunk, I don't understand what it's > good for. >=20 > So I propose the attached patch instead. > It creates a new function to decide between reference and value, so that > gfc_add_loop_ss_code and gfc_conv_expr are kept in sync. > As the new function needs information about the dummy argument, the > dummy symbol is saved to a new field in gfc_ss_info. > And the "chunk 1" condition is reverted to its previous state. > The testcase is yours. >=20 > regression tested on x86_64-unknown-linux-gnu. OK for trunk? >=20 > Mikael >=20 >=20 >=20 >=20 >=20 --=20 Andre Vehreschild * Email: vehre ad gmx dot de=20