From: Ilmir Usmanov <i.usmanov@samsung.com>
To: Thomas Schwinge <thomas@codesourcery.com>
Cc: fortran@gcc.gnu.org, Tobias Burnus <burnus@net-b.de>,
gcc-patches@gcc.gnu.org, David Malcolm <dmalcolm@redhat.com>,
Mikael Morin <mikael.morin@sfr.fr>
Subject: Re: Fix logic error in Fortran OpenACC parsing
Date: Fri, 08 May 2015 11:24:00 -0000 [thread overview]
Message-ID: <554C9CDF.7000605@samsung.com> (raw)
In-Reply-To: <87d22endfn.fsf@schwinge.name>
Hi!
On 06.05.2015 14:38, Thomas Schwinge wrote:
> Hi!
>
> On Tue, 5 May 2015 15:38:03 -0400, David Malcolm <dmalcolm@redhat.com> 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
> <http://news.gmane.org/find-root.php?message_id=%3C52E1595D.9000007%40samsung.com%3E>
> 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 <thomas@codesourcery.com>
> 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 <mikael.morin@sfr.fr>.
> ---
> 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.
next prev parent reply other threads:[~2015-05-08 11:24 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-16 15:08 [RFC stage 1] Proposed new warning: -Wmisleading-indentation David Malcolm
2015-04-16 17:27 ` Mike Stump
2015-04-21 16:13 ` David Malcolm
2015-04-21 16:40 ` Trevor Saunders
2015-04-21 16:43 ` Manuel López-Ibáñez
2015-04-21 17:05 ` Mike Stump
2015-04-21 18:14 ` Manuel López-Ibáñez
2015-04-21 23:35 ` David Malcolm
2015-04-28 23:50 ` [PATCH 1/3] Implement -Wmisleading-indentation (v4) David Malcolm
2015-04-28 23:52 ` [PATCH 2/3] Fix spurious semicolons David Malcolm
2015-04-29 0:10 ` Jeff Law
2015-04-28 23:53 ` [PATCH 3/3] Fix indentation issues seen by -Wmisleading-indentation David Malcolm
2015-04-29 0:25 ` Jeff Law
2015-04-29 12:35 ` Mikael Morin
2015-05-05 19:44 ` David Malcolm
2015-05-06 11:38 ` Fix logic error in Fortran OpenACC parsing (was: [PATCH 3/3] Fix indentation issues seen by -Wmisleading-indentation) Thomas Schwinge
2015-05-08 11:24 ` Ilmir Usmanov [this message]
2015-07-27 14:37 ` Fix logic error in Fortran OpenACC parsing Thomas Schwinge
2015-05-11 21:23 ` [PATCH 1/3] Implement -Wmisleading-indentation (v4) Jeff Law
2015-05-12 21:28 ` David Malcolm
2015-05-12 21:47 ` David Malcolm
2015-08-18 14:13 ` PR67192 (Was: Re: [PATCH 1/3] Implement -Wmisleading-indentation (v4)) Andreas Arnez
2015-04-16 18:29 ` [RFC stage 1] Proposed new warning: -Wmisleading-indentation Manuel López-Ibáñez
2015-04-17 14:42 ` Tom Tromey
2015-04-17 16:12 ` Manuel López-Ibáñez
2015-04-28 23:13 ` Joseph Myers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=554C9CDF.7000605@samsung.com \
--to=i.usmanov@samsung.com \
--cc=burnus@net-b.de \
--cc=dmalcolm@redhat.com \
--cc=fortran@gcc.gnu.org \
--cc=gcc-patches@gcc.gnu.org \
--cc=mikael.morin@sfr.fr \
--cc=thomas@codesourcery.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).