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

[manu at gcc dot 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.