Like its c++ counterpart, the fortran FE incorrectly records the line
locations of combined acc loop directives when it lowers the construct
to gimple. Usually this isn't a problem because the fortran FE is able
to report problems with acc loops itself. However, there will be
inaccuracies if the ME tries to use those locations. I had originally
posted the patch here
<https://gcc.gnu.org/ml/gcc-patches/2017-02/msg01256.html>, but Thomas
asked me to put it in a separate patch.
This patch has been applied to gomp-4_0-branch.
Cesar
2017-02-22 Cesar Philippidis <ce...@codesourcery.com>
gcc/fortran/
* trans-openmp.c (gfc_trans_oacc_combined_directive): Set the
location of combined acc loops.
diff --git a/gcc/fortran/trans-openmp.c b/gcc/fortran/trans-openmp.c
index 0b16af6..8688425 100644
--- a/gcc/fortran/trans-openmp.c
+++ b/gcc/fortran/trans-openmp.c
@@ -3818,6 +3818,7 @@ gfc_trans_oacc_combined_directive (gfc_code *code)
enum tree_code construct_code;
bool scan_nodesc_arrays = false;
hash_set<gfc_symbol *> *array_set = NULL;
+ location_t loc = input_location;
switch (code->op)
{
@@ -3849,6 +3850,9 @@ gfc_trans_oacc_combined_directive (gfc_code *code)
pushlevel ();
stmt = gfc_trans_omp_do (code, EXEC_OACC_LOOP, pblock, loop_clauses, NULL);
+ if (CAN_HAVE_LOCATION_P (stmt))
+ SET_EXPR_LOCATION (stmt, loc);
+
if (array_set && array_set->elements ())
gfc_add_expr_to_block (&inner, stmt);
@@ -3864,8 +3868,7 @@ gfc_trans_oacc_combined_directive (gfc_code *code)
delete array_set;
}
- stmt = build2_loc (input_location, construct_code, void_type_node, stmt,
- oacc_clauses);
+ stmt = build2_loc (loc, construct_code, void_type_node, stmt, oacc_clauses);
gfc_add_expr_to_block (&block, stmt);
gfc_free_omp_clauses (loop_clauses);
