Re: [Patch, Fortran] PR 45186 - Improve location of expressions for debugging

[Mikael Morin <mikael dot morin at sfr dot fr>]

On Wednesday 13 October 2010 10:28:57 Tobias Burnus wrote:
>   PR 45186 is "[4.6 Regression] Gfortran 4.5.0 emits wrong linenumbers".
> While most of it was fixed, I found two cases where the location was
> wrong or at least surprising. That's fixes with the following patch. I
> am sure there are more cases, but I intent to close the PR after those
> fixes are in.
> 
> Currently, one has surprising locations (cf. -fdump-tree-original-lineno
> [note the "-lineno"]) for:
>    if (cond)
>      a = b
>    end if
> as the condition has the line number of "a = b". Analogously for
>    do while (cond)
>       j = i
>    end do
> 
> For DO loops,
>    do i = 1, 2  ! or "i = 1, 2, k" which is handled differently
>      j = i
>      k = j
>    end do
> many generated expressions are in the "j = i" or in the "k = i" line.
> When trying, also use -fcheck=do to generate get more expressions.
> 
> While for "if (cond)" and for "do while(cond)" the line number is
> naturally given by the DO/IF statement, for DO loops it gets more
> complicated: To which line do you associate the loop-exit check, the
> initializations, the increment, ...? The patch mostly puts them into the
> DO line.

I agree with all the above. However, about the implementation, I don't like 
this :

> -
> -tree
> -gfc_trans_runtime_error_vararg (bool error, locus* where, const char*
> msgid, -                               va_list ap)
> +static tree
> +trans_runtime_error_vararg (location_t loc, bool error, locus* where,
> +                               const char* msgid, va_list ap)

and the similar change(s). 
locus' gfc_linebuf has a source_location field, and location_t is typedef-ed 
from source_location in input.h. 
So having both a locus and a location_t arg seems to duplicate the location 
information.  

For the rest of the patch, I'm wondering whether we could remove dependency on 
input_location completely (I mean, in the PR45186 area), that is rely on 
gfc_expr's locus, gfc_code's locus or tree's EXPR_LOCATION only (provided they 
are correctly set of course).

Mikael