[Bug debug/67192] Backward-goto in loop can get wrong line number

["manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |manu at gcc dot gnu.org

--- Comment #8 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Andreas Arnez from comment #7)
> I'm curious why this would lead to the problem seen, and whether that's
> working as intended.  When looking at c_finish_loop(), I see:
> 	      SET_EXPR_LOCATION (t, start_locus);
> where t seems to be the GOTO_EXPR for the backward-goto and start_locus is
> the location of the beginning of the loop.  Naively I would conclude that
> the GOTO_EXPR is intended to have the location of the *beginning* of the
> loop.  But neither before nor after your patch this seems to be the case?

No, it is the goto that corresponds to the loop exit:

      /* If we have an exit condition, then we build an IF with gotos either
         out of the loop, or to the top of it.  If there's no exit condition,
         then we just build a jump back to the top.  */
      exit = build_and_jump (&LABEL_EXPR_LABEL (top));

however, that exit does not have a valid location, thus it is added at add_stmt
a few lines below:

  if (CAN_HAVE_LOCATION_P (t) && code != LABEL_EXPR)
    {
      if (!EXPR_HAS_LOCATION (t))
        SET_EXPR_LOCATION (t, input_location);
    }

It is surprising that c_parser_peek_token changes input_location and this
doesn't mess up everything else. I wonder what is the benefit of having
input_location at all if we need to keep saving and restoring it all the time.

Does GCC work at all if input_location is saved and restored in
c_parser_peek_token? I guess not, it seems too much still relies in
input_location being magically right.
>From gcc-bugs-return-495125-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Aug 18 19:56:58 2015
Return-Path: <gcc-bugs-return-495125-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 119616 invoked by alias); 18 Aug 2015 19:56:58 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 119572 invoked by uid 55); 18 Aug 2015 19:56:54 -0000
From: "fxcoudert at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libfortran/66936] io/unix.c gratuitously uses S_IRWXG and S_IRWXO on the basis that umask() is available
Date: Tue, 18 Aug 2015 19:56:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libfortran
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: fxcoudert at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Resolution: FIXED
X-Bugzilla-Priority: P5
X-Bugzilla-Assigned-To: fxcoudert at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-66936-4-WBIQ1xmV6g@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-66936-4@http.gcc.gnu.org/bugzilla/>
References: <bug-66936-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-08/txt/msg01267.txt.bz2
Content-length: 462

https://gcc.gnu.org/bugzilla/show_bug.cgi?idf936

--- Comment #19 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
Author: fxcoudert
Date: Tue Aug 18 19:56:20 2015
New Revision: 226988

URL: https://gcc.gnu.org/viewcvs?rev"6988&root=gcc&view=rev
Log:
        PR libfortran/66936
        * io/unix.c (__MINGW32__): Undefine HAVE_UMASK.

Modified:
    branches/gcc-5-branch/libgfortran/ChangeLog
    branches/gcc-5-branch/libgfortran/io/unix.c