From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 107160 invoked by alias); 8 May 2015 11:24:23 -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 107142 invoked by uid 89); 8 May 2015 11:24:22 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients X-HELO: mailout3.w1.samsung.com Received: from mailout3.w1.samsung.com (HELO mailout3.w1.samsung.com) (210.118.77.13) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Fri, 08 May 2015 11:24:20 +0000 MIME-version: 1.0 Content-type: text/plain; charset=utf-8; format=flowed Received: from eucpsbgm1.samsung.com (unknown [203.254.199.244]) by mailout3.w1.samsung.com (Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5 2014)) with ESMTP id <0NO100LWK3OGKV90@mailout3.w1.samsung.com>; Fri, 08 May 2015 12:24:16 +0100 (BST) Received: from eusync2.samsung.com ( [203.254.199.212]) by eucpsbgm1.samsung.com (EUCPMTA) with SMTP id D3.52.04846.0EC9C455; Fri, 8 May 2015 12:24:16 +0100 (BST) Content-transfer-encoding: 8BIT Received: from [106.109.9.156] by eusync2.samsung.com (Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5 2014)) with ESMTPA id <0NO1005A73OF0P50@eusync2.samsung.com>; Fri, 08 May 2015 12:24:16 +0100 (BST) Message-id: <554C9CDF.7000605@samsung.com> Date: Fri, 08 May 2015 11:24:00 -0000 From: Ilmir Usmanov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 To: Thomas Schwinge Cc: fortran@gcc.gnu.org, Tobias Burnus , gcc-patches@gcc.gnu.org, David Malcolm , Mikael Morin Subject: Re: Fix logic error in Fortran OpenACC parsing References: <5536936F.8090004@gmail.com> <1430265776-8157-1-git-send-email-dmalcolm@redhat.com> <1430265776-8157-3-git-send-email-dmalcolm@redhat.com> <5540CA39.7070308@sfr.fr> <1430854683.32584.275.camel@surprise> <87d22endfn.fsf@schwinge.name> In-reply-to: <87d22endfn.fsf@schwinge.name> X-IsSubscribed: yes X-SW-Source: 2015-05/txt/msg00644.txt.bz2 Hi! On 06.05.2015 14:38, Thomas Schwinge wrote: > Hi! > > On Tue, 5 May 2015 15:38:03 -0400, David Malcolm wrote: >> On Wed, 2015-04-29 at 14:10 +0200, Mikael Morin wrote: >>> Le 29/04/2015 02:02, David Malcolm a écrit : >>>> diff --git a/gcc/fortran/parse.c b/gcc/fortran/parse.c >>>> index 2c7c554..30e4eab 100644 >>>> --- a/gcc/fortran/parse.c >>>> +++ b/gcc/fortran/parse.c >>>> @@ -4283,7 +4283,7 @@ parse_oacc_structured_block (gfc_statement acc_st) >>>> unexpected_eof (); >>>> else if (st != acc_end_st) >>>> gfc_error ("Expecting %s at %C", gfc_ascii_statement (acc_end_st)); >>>> - reject_statement (); >>>> + reject_statement (); >>>> } >>>> while (st != acc_end_st); >>>> >>> I think this one is a bug; there should be braces around 'gfc_error' and >>> 'reject_statement'. If 'st' is 'acc_end_st', as it shall be, the statement is rejected. So, this is a bug. > >>> At least that's the pattern in 'parse_oacc_loop', and how the >>> 'unexpected_statement' function is used. >> FWIW, Jeff had approved that patch, so I've committed the patch to trunk >> (as r222823), making the indentation reflect the block structure. >> >> Thomas: should the >> reject_statement (); >> call in the above be guarded by the >> else if (st != acc_end_st) >> clause? > Indeed, this seems to be a bug that has been introduced very early in the > OpenACC Fortran front end development -- see how the > parse_oacc_structured_block function evolved in the patches posted in > > and following (Ilmir, CCed "just in case"). I also see that the > corresponding OpenMP code, parse_omp_structured_block, just calls > unexpected_statement, which Ilmir's initial patch also did, but at some > point, he then changed this to the current code: gfc_error followed by > reject_statement, as cited above -- I would guess for the reason to get a > better error message? (Tobias, should this thus also be done for OpenMP, > and/or extend unexpected_statement accordingly?) That's true. I've checked abandoned openacc-1_0-branch and I used unexpected_statement there (there still odd *_acc_* naming presents instead of new-and-shiny *_oacc_* one), but, as you mentioned, I've changed this for better error reporting... and introduced the bug. > > And then, I'm a bit confused: is it "OK" that despite this presumed logic > error, which affects all (?) valid executions of this parsing code, we're > not running into any issues with the OpenACC Fortran front end test > cases? I think, this is OK, since this is an !$ACC END _smth_ statement and it shall not present in the AST. So, it is abandoned later anyway ;) (if I remember correctly, during gfc_clear_new_st call). Although the bug does not affect the logic, it is still a bug. > OK for trunk? From my point of view, OK. > > commit 068eebfa63b2b4c8849ed5fd2c9d0a130586dfb0 > Author: Thomas Schwinge > Date: Wed May 6 13:18:18 2015 +0200 > > Fix logic error in Fortran OpenACC parsing > > gcc/fortran/ > * parse.c (parse_oacc_structured_block): Fix logic error. > Reported by Mikael Morin . > --- > gcc/fortran/parse.c | 6 ++++-- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git gcc/fortran/parse.c gcc/fortran/parse.c > index 30e4eab..e977498 100644 > --- gcc/fortran/parse.c > +++ gcc/fortran/parse.c > @@ -4282,8 +4282,10 @@ parse_oacc_structured_block (gfc_statement acc_st) > if (st == ST_NONE) > unexpected_eof (); > else if (st != acc_end_st) > - gfc_error ("Expecting %s at %C", gfc_ascii_statement (acc_end_st)); > - reject_statement (); > + { > + gfc_error ("Expecting %s at %C", gfc_ascii_statement (acc_end_st)); > + reject_statement (); > + } > } > while (st != acc_end_st); > > > > Grüße, > Thomas -- Ilmir.