diff mbox

Fix up Fortran line numbers (PR fortran/45186)

Message ID 20100816204538.GB702@tyan-ft48-01.lab.bos.redhat.com
State New
Headers show

Commit Message

Jakub Jelinek Aug. 16, 2010, 8:45 p.m. UTC
Hi!

As discussed on IRC and in the PR, this patch fixes Fortran line info
by basically going back to what GCC 4.4 did.  The FE doesn't pass
input_location to all the various build*/fold_build*/build*_v
functions/macros when it creates the trees, there are more than 1000
of such places.

Ok for 4.5 (for which changing those 1000 places isn't really desirable)?
What about 4.6?

Bootstrapped/regtested on x86_64-linux and i686-linux.

2010-08-16  Jakub Jelinek  <jakub@redhat.com>

	PR fortran/45186
	* trans.c (gfc_annotate_with_location): New function.
	(trans_code): Use it.


	Jakub

Comments

Tobias Burnus Aug. 16, 2010, 9:18 p.m. UTC | #1
Jakub Jelinek wrote:
> As discussed on IRC and in the PR, this patch fixes Fortran line info
> by basically going back to what GCC 4.4 did.  The FE doesn't pass
> input_location to all the various build*/fold_build*/build*_v
> functions/macros when it creates the trees, there are more than 1000
> of such places.
>
> Ok for 4.5 (for which changing those 1000 places isn't really desirable)?
> What about 4.6?
> Bootstrapped/regtested on x86_64-linux and i686-linux.

OK for 4.5.

For 4.6 I think one should really consider changing the 700-odd 
fold_build* to fold_build*_loc; for the build* (and build*_v) calls, I 
have to figure out (a) whether is is needed to add the locus and (b) if 
so, how to do this - there are no build*_loc functions. I fear we won't 
do the _loc fix if one commits your patch to the 4.6 trunk.

Thanks for the patch!

Tobias
H.J. Lu Aug. 19, 2010, 6:21 p.m. UTC | #2
On Mon, Aug 16, 2010 at 1:45 PM, Jakub Jelinek <jakub@redhat.com> wrote:
> Hi!
>
> As discussed on IRC and in the PR, this patch fixes Fortran line info
> by basically going back to what GCC 4.4 did.  The FE doesn't pass
> input_location to all the various build*/fold_build*/build*_v
> functions/macros when it creates the trees, there are more than 1000
> of such places.
>
> Ok for 4.5 (for which changing those 1000 places isn't really desirable)?
> What about 4.6?
>
> Bootstrapped/regtested on x86_64-linux and i686-linux.
>
> 2010-08-16  Jakub Jelinek  <jakub@redhat.com>
>
>        PR fortran/45186
>        * trans.c (gfc_annotate_with_location): New function.
>        (trans_code): Use it.
>

This patch caused:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45344

Do you need to update those Fortran testcases?
diff mbox

Patch

--- gcc/fortran/trans.c.jj	2010-08-11 21:08:00.000000000 +0200
+++ gcc/fortran/trans.c	2010-08-16 12:37:45.000000000 +0200
@@ -1055,6 +1055,29 @@  gfc_set_backend_locus (locus * loc)
   input_location = loc->lb->location;
 }
 
+/* Annotate statement or statement list T with location LOC.  */
+
+static void
+gfc_annotate_with_location (tree t, location_t loc)
+{
+  if (TREE_CODE (t) == STATEMENT_LIST)
+    {
+      tree_stmt_iterator i;
+
+      for (i = tsi_start (t); !tsi_end_p (i); tsi_next (&i))
+	gfc_annotate_with_location (tsi_stmt (i), loc);
+      return;
+    }
+  if (TREE_CODE (t) == COMPOUND_EXPR)
+    {
+      gfc_annotate_with_location (TREE_OPERAND (t, 0), loc);
+      gfc_annotate_with_location (TREE_OPERAND (t, 1), loc);
+    }
+  if (TREE_CODE (t) == LABEL_EXPR || !TREE_SIDE_EFFECTS (t))
+    return;
+  if (CAN_HAVE_LOCATION_P (t) && ! EXPR_HAS_LOCATION (t))
+    SET_EXPR_LOCATION (t, loc);
+}
 
 /* Translate an executable statement. The tree cond is used by gfc_trans_do.
    This static function is wrapped by gfc_trans_code_cond and
@@ -1312,9 +1335,8 @@  trans_code (gfc_code * code, tree cond)
 
       if (res != NULL_TREE && ! IS_EMPTY_STMT (res))
 	{
-	  if (TREE_CODE (res) != STATEMENT_LIST)
-	    SET_EXPR_LOCATION (res, input_location);
-	    
+	  gfc_annotate_with_location (res, input_location);
+
 	  /* Add the new statement to the block.  */
 	  gfc_add_expr_to_block (&block, res);
 	}