From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16701 invoked by alias); 23 Mar 2015 15:49:52 -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 16679 invoked by uid 89); 23 Mar 2015 15:49:51 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 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.15.19) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Mon, 23 Mar 2015 15:49:50 +0000 Received: from vepi2 ([88.75.104.20]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MYg42-1YwdZa3g7m-00VSg0; Mon, 23 Mar 2015 16:49:45 +0100 Date: Mon, 23 Mar 2015 15:49:00 -0000 From: Andre Vehreschild To: Mikael Morin Cc: GCC-Fortran-ML , GCC-Patches-ML , Antony Lewis Subject: Re: [Patch 1/2, Fortran, pr60322] [OOP] Incorrect bounds on polymorphic dummy array Message-ID: <20150323164943.76daeabe@vepi2> In-Reply-To: <551029F7.4080601@sfr.fr> References: <20150226181717.480e282c@vepi2> <551006FF.1080704@sfr.fr> <20150323134357.6af740d1@vepi2> <551029F7.4080601@sfr.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UI-Out-Filterresults: notjunk:1; X-SW-Source: 2015-03/txt/msg01193.txt.bz2 Hi Mikael, > This pointer stuff is very difficult to swallow to me. I totally understand. When doing the patch I had to restart twice, because I mixed up the development on the class arrays so completely, that I couldn't get it right again. > I understand that for classes, the CLASS_DATA (sym)->pointer is always > set, but almost everywhere the checks for pointerness are like > (sym->ts.type != BT_CLASS && sym->attr.pointer) > || (sym->ts.type == BT_CLASS && CLASS_DATA (sym)->attr.class_pointer) > and I don't see a convincing reason to have it different here. I see your point. Currently I am bootstraping and regtesting some patches for commit. While this is running, my machine is nearly unusable. I will look into this as soon, as my machine allows, but probably not before tomorrow. > At least gfc_is_nodesc_array should return 0 if sym->ts.type == BT_CLASS > which solves the problem there; for the other cases, I think that > class_pointer should be looked at. gfc_build_class_symbol clears the > sym->attr.pointer flag for class containers so it doesn't make sense to > test that flag. Completely right again. But I figured, that because sym->attr.pointer is never set for BT_CLASS there is no harm to check it and furthermore no need to guard it by checking whether ts.type == BT_CLASS. Fortunately not checking for class_pointer in _data's attr, didn't throw any regressions. Thinking about it now, I also think that it is probably safer to add the check for the class_pointer attribute were attr.pointer is checked on the sym, having the expression like you pointed out: > (sym->ts.type != BT_CLASS && sym->attr.pointer) > || (sym->ts.type == BT_CLASS && CLASS_DATA (sym)->attr.class_pointer) Regards, Andre -- Andre Vehreschild * Email: vehre ad gmx dot de