[Bug fortran/45186] New: Gfortran 4.5.0 emits wrong linenumbers

[Bug fortran/45186] New: Gfortran 4.5.0 emits wrong linenumbers

[nikolay at totalviewtech dot com]

This is pretty widespread. I have attached one example, but I see it in many
programs. 
How to repeat:
Compile with -g 
Do a next couple of times: Notice, that PC is jumping back and forth. Also
notice, that there is no linenumbers for lines 19 20 and 27


-- 
           Summary: Gfortran 4.5.0 emits wrong linenumbers
           Product: gcc
           Version: 4.5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: nikolay at totalviewtech dot com


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

[Bug fortran/45186] Gfortran 4.5.0 emits wrong linenumbers

[nikolay at totalviewtech dot com]

------- Comment #1 from nikolay at totalviewtech dot com  2010-08-04 21:03 -------
Created an attachment (id=21397)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21397&action=view)
example


-- 


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

[Bug fortran/45186] [4.5/4.6 Regression] Gfortran 4.5.0 emits wrong linenumbers

[jv244 at cam dot ac dot uk]

------- Comment #2 from jv244 at cam dot ac dot uk  2010-08-05 11:13 -------
confirmed with 4.5/4.6, works with 4.3/4.4. Compiling with
-fdump-tree-all-lineno and looking into tx_f90_pointers.f90.003t.original shows
that most of the lineno info has disappeared in 4.5.


-- 

jv244 at cam dot ac dot uk changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
           Keywords|                            |wrong-debug
   Last reconfirmed|0000-00-00 00:00:00         |2010-08-05 11:13:14
               date|                            |
            Summary|Gfortran 4.5.0 emits wrong  |[4.5/4.6 Regression]
                   |linenumbers                 |Gfortran 4.5.0 emits wrong
                   |                            |linenumbers


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

[Bug fortran/45186] [4.5/4.6 Regression] Gfortran 4.5.0 emits wrong linenumbers

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.5.2


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

[Bug fortran/45186] [4.5/4.6 Regression] Gfortran 4.5.0 emits wrong linenumbers

[mikael at gcc dot gnu dot org]

------- Comment #3 from mikael at gcc dot gnu dot org  2010-08-13 09:33 -------
Might be related to pr41359 (whose patch was not committed). 


-- 


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

[Bug fortran/45186] [4.5/4.6 Regression] Gfortran 4.5.0 emits wrong linenumbers

[jv244 at cam dot ac dot uk]

------- Comment #4 from jv244 at cam dot ac dot uk  2010-08-13 10:11 -------
(In reply to comment #3)
> Might be related to pr41359 (whose patch was not committed). 

I think it is unrelated, since this used to work in 4.3, while pr41359 never
worked AFAICT. Nevertheless, would be nice to commit the patch in pr41359,
maybe there is a lucky side-effect. 

I think there is are no line-number tests in gfortran's testsuite. Would be a
good thing to establish. 


-- 


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

[Bug fortran/45186] [4.5/4.6 Regression] Gfortran 4.5.0 emits wrong linenumbers

[jvdelisle at gcc dot gnu dot org]

------- Comment #5 from jvdelisle at gcc dot gnu dot org  2010-08-13 15:11 -------
I will try the other patch and see what this does.


-- 


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

[Bug fortran/45186] [4.5/4.6 Regression] Gfortran 4.5.0 emits wrong linenumbers

[jvdelisle at gcc dot gnu dot org]

------- Comment #6 from jvdelisle at gcc dot gnu dot org  2010-08-13 17:24 -------
With or without the other patch, the gimple code has:

main (integer(kind=4) argc, character(kind=1) * * argv)
[tx_f90_pointers.f90 : 30:0] {
  integer(kind=4) D.1535;
  static integer(kind=4) options.0[8] = {68, 511, 0, 0, 0, 1, 0, 1};

  [tx_f90_pointers.f90 : 30:0] _gfortran_set_args (argc, argv);
  [tx_f90_pointers.f90 : 30:0] _gfortran_set_options (8, [tx_f90_pointers.f90 :
30] &options.0[0]);
  [tx_f90_pointers.f90 : 30:0] test ();
  [tx_f90_pointers.f90 : 30:0] D.1535 = 0;
  [tx_f90_pointers.f90 : 30:0] return D.1535;
}


test ()
[tx_f90_pointers.f90 : 3:0] {
  integer(kind=4) D.1540;
  integer(kind=4) array1[10];
  integer(kind=4) array2[100];
  integer(kind=4) i;
  struct array1_integer(kind=4) p1;
  struct array1_integer(kind=4) p11;

  [tx_f90_pointers.f90 : 3:0] p1.data = 0B;
  [tx_f90_pointers.f90 : 3:0] p11.data = 0B;
  [tx_f90_pointers.f90 : 12:0] p1.data = 0B;
  [tx_f90_pointers.f90 : 3:0] i = 1;
  [tx_f90_pointers.f90 : 3:0] if (i <= 10) goto <D.1537>; else goto <D.1538>;
  <D.1537>:
  <D.1539>:
  [tx_f90_pointers.f90 : 3:0] {
    logical(kind=4) D.1529;

    [tx_f90_pointers.f90 : 15:0] D.1540 = i + -1;
    [tx_f90_pointers.f90 : 15:0] array1[D.1540] = i;
    L.1:
    [tx_f90_pointers.f90 : 3:0] D.1529 = i == 10;
    [tx_f90_pointers.f90 : 3:0] i = i + 1;
    [tx_f90_pointers.f90 : 3:0] if (D.1529 != 0) goto L.2; else goto <D.1541>;
    <D.1541>:
  }
  [tx_f90_pointers.f90 : 3:0] goto <D.1539>;
  <D.1538>:
  L.2:
  [tx_f90_pointers.f90 : 3:0] p1.dtype = 265;
  [tx_f90_pointers.f90 : 3:0] p1.dim[0].lbound = 1;
  [tx_f90_pointers.f90 : 3:0] p1.dim[0].ubound = 5;
  [tx_f90_pointers.f90 : 3:0] p1.dim[0].stride = -2;
  [tx_f90_pointers.f90 : 3:0] p1.data = &array1[8];
  [tx_f90_pointers.f90 : 3:0] p1.offset = 2;
  [tx_f90_pointers.f90 : 3:0] p11.dtype = 265;
  [tx_f90_pointers.f90 : 3:0] p11.dim[0].lbound = 1;
  [tx_f90_pointers.f90 : 3:0] p11.dim[0].ubound = 5;
  [tx_f90_pointers.f90 : 3:0] p11.dim[0].stride = 2;
  [tx_f90_pointers.f90 : 3:0] p11.data = &array1[0];
  [tx_f90_pointers.f90 : 3:0] p11.offset = -2;
  [tx_f90_pointers.f90 : 23:0] i = 1;
  [tx_f90_pointers.f90 : 3:0] p1.dtype = 265;
  [tx_f90_pointers.f90 : 3:0] p1.dim[0].lbound = 1;
  [tx_f90_pointers.f90 : 3:0] p1.dim[0].ubound = 10;
  [tx_f90_pointers.f90 : 3:0] p1.dim[0].stride = 1;
  [tx_f90_pointers.f90 : 3:0] p1.data = &array2[0];
  [tx_f90_pointers.f90 : 3:0] p1.offset = -1;
  [tx_f90_pointers.f90 : 28:0] p11 = p1;
}

The entire DO LOOP is one line.


-- 


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

[Bug fortran/45186] [4.5/4.6 Regression] Gfortran 4.5.0 emits wrong linenumbers

[jv244 at cam dot ac dot uk]

------- Comment #7 from jv244 at cam dot ac dot uk  2010-08-13 18:20 -------
(In reply to comment #6)
> With or without the other patch, the gimple code has:

isn't the gimple output showing linenumbers even in the case where the
.original dump is missing them ?


-- 


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

[Bug fortran/45186] [4.5/4.6 Regression] Gfortran 4.5.0 emits wrong linenumbers

[jakub at gcc dot gnu dot org]

------- Comment #8 from jakub at gcc dot gnu dot org  2010-08-16 10:16 -------
I'm pretty sure this was caused by PR41714 and that there are many places
missing locus passing.  Either the trans_code change should be reverted, so
that it handles also STATEMENT_LISTs, or many changes in the FE needs to be
adjusted.


-- 


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

[Bug fortran/45186] [4.5/4.6 Regression] Gfortran 4.5.0 emits wrong linenumbers

[jakub at gcc dot gnu dot org]

------- Comment #9 from jakub at gcc dot gnu dot org  2010-08-16 10:47 -------
Created an attachment (id=21488)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21488&action=view)
gcc46-pr45186.patch

So, IMNSHO, either we use something like in this patch, Richard probably won't
like it, but the FE isn't really prepared to maintain locus properly
everywhere, or you need to be prepared to handle not just dozens, but around
thousand places:
grep -w build[0-9] trans*.c | wc -l
38
grep -w build[0-9]_v trans*.c | wc -l
158
grep -w fold_build[0-9] trans*.c | wc -l
734

Perhaps the build*_v macros could be changed to use fold_build*_loc instead of
fold_build and pass input_location, but then there are still those > 700
fold_build* calls, which would need to be turned into fold_build*_loc.
I don't think it is reasonable to do that for 4.5 at least, and for 4.6 only if
somebody has a lot of time in his hands.


-- 


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

[Bug fortran/45186] [4.5/4.6 Regression] Gfortran 4.5.0 emits wrong linenumbers

[jakub at gcc dot gnu dot org]

------- Comment #10 from jakub at gcc dot gnu dot org  2010-08-17 06:55 -------
Subject: Bug 45186

Author: jakub
Date: Tue Aug 17 06:55:25 2010
New Revision: 163293

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163293
Log:
        PR fortran/45186
        * trans.c (gfc_annotate_with_location): New function.
        (trans_code): Use it.

Modified:
    branches/gcc-4_5-branch/gcc/fortran/ChangeLog
    branches/gcc-4_5-branch/gcc/fortran/trans.c


-- 


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

[Bug fortran/45186] [4.6 Regression] Gfortran 4.5.0 emits wrong linenumbers

[jakub at gcc dot gnu dot org]

------- Comment #11 from jakub at gcc dot gnu dot org  2010-08-17 09:25 -------
Should be fixed for 4.5.2, 4.6 will use a different approach.


-- 

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[4.5/4.6 Regression]        |[4.6 Regression] Gfortran
                   |Gfortran 4.5.0 emits wrong  |4.5.0 emits wrong
                   |linenumbers                 |linenumbers


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

[Bug fortran/45186] [4.6 Regression] Gfortran 4.5.0 emits wrong linenumbers

[jv244 at cam dot ac dot uk]

-- 

jv244 at cam dot ac dot uk changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.5.2                       |4.6.0


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

[Bug fortran/45186] [4.6 Regression] Gfortran 4.5.0 emits wrong linenumbers

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2


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

[Bug fortran/45186] [4.6 Regression] Gfortran 4.5.0 emits wrong linenumbers

[burnus at gcc dot gnu dot org]

------- Comment #12 from burnus at gcc dot gnu dot org  2010-09-02 14:04 -------
Subject: Bug 45186

Author: burnus
Date: Thu Sep  2 14:04:06 2010
New Revision: 163776

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163776
Log:
2010-09-02  Tobias Burnus  <burnus@net-b.de>

        PR fortran/45186
        * trans-common.c (create_common): Change build[0-9] to
        build[0-9]_loc.
        * trans-const.c (gfc_conv_constant_to_tree,
        gfc_conv_constant_to_tree): Ditto.
        * trans-decl.c (gfc_build_qualified_array, build_entry_thunks,
        gfc_get_fake_result_decl, gfc_trans_auto_character_variable,
        add_argument_checking, create_main_function,
        gfc_generate_return): Ditto.
        * trans-types.c (gfc_get_dtype, gfc_get_array_type_bounds):
        * Ditto.
        * trans-stmt.c (allocate_temp_for_forall_nest_1,
        compute_inner_temp_size, compute_overall_iter_number,
        generate_loop_for_rhs_to_temp, generate_loop_for_temp_to_lhs,
        gfc_conv_elemental_dependencies, gfc_do_allocate,
        gfc_evaluate_where_mask, gfc_trans_allocate,
        gfc_trans_arithmetic_if, gfc_trans_call,
        gfc_trans_character_select, gfc_trans_deallocate,
        gfc_trans_do, gfc_trans_do_while, gfc_trans_forall_1,
        gfc_trans_forall_loop, gfc_trans_goto, gfc_trans_if_1,
        gfc_trans_integer_select, gfc_trans_logical_select,
        gfc_trans_pointer_assign_need_temp, gfc_trans_return,
        gfc_trans_simple_do, gfc_trans_sync, gfc_trans_where_2,
        gfc_trans_where_assign) Ditto.


Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/trans-common.c
    trunk/gcc/fortran/trans-const.c
    trunk/gcc/fortran/trans-decl.c
    trunk/gcc/fortran/trans-stmt.c
    trunk/gcc/fortran/trans-types.c


-- 


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

[Bug fortran/45186] [4.6 Regression] Gfortran 4.5.0 emits wrong linenumbers

[burnus at gcc dot gnu dot org]

------- Comment #13 from burnus at gcc dot gnu dot org  2010-09-03 19:41 -------
Subject: Bug 45186

Author: burnus
Date: Fri Sep  3 19:41:11 2010
New Revision: 163838

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163838
Log:
2010-09-03  Tobias Burnus  <burnus@net-b.de>

        PR fortran/45186
        * trans-intrinsic.c (gfc_conv_intrinsic_sign,
        gfc_conv_intrinsic_leadz): Use build_call_expr_loc instead
        of build_call_expr.
        * trans-expr.c (gfc_conv_expr_present, gfc_conv_missing_dummy,
        gfc_conv_string_length, gfc_conv_substring,
        gfc_conv_component_ref, gfc_conv_unary_op, gfc_conv_powi,
        gfc_conv_cst_int_power, gfc_conv_string_tmp, gfc_conv_concat_op,
        gfc_conv_expr_op, gfc_build_compare_string,
        gfc_set_interface_mapping_bounds, gfc_conv_subref_array_arg,
        gfc_conv_derived_to_class, conv_isocbinding_procedure,
        gfc_conv_procedure_call, fill_with_spaces,
        gfc_trans_string_copy, gfc_trans_alloc_subarray_assign,
        gfc_trans_structure_assign, gfc_trans_pointer_assignment,
        gfc_trans_scalar_assign, gfc_trans_zero_assign,
        gfc_trans_array_copy, gfc_trans_array_constructor_copy): Change
        fold_build[0-9] to fold_build[0-9]_loc.
        * trans-io.c (set_parameter_const, set_parameter_value,
        set_parameter_ref, gfc_convert_array_to_string, set_string,
        set_internal_unit, io_result, set_error_locus,
        nml_get_addr_expr, build_dt): Ditto.
        * trans-openmp.c (gfc_omp_clause_default_ctor,
        gfc_omp_clause_copy_ctor, gfc_omp_clause_assign_op,
        gfc_trans_omp_array_reduction, gfc_trans_omp_atomic,
        gfc_trans_omp_do): Ditto.
        * trans.c (gfc_add_modify, gfc_build_addr_expr,
        gfc_build_array_ref, gfc_trans_runtime_error_vararg,
        gfc_trans_runtime_check, gfc_call_malloc,
        gfc_allocate_with_status, gfc_allocate_array_with_status,
        gfc_call_free, gfc_deallocate_with_status,
        gfc_call_realloc): Ditto.


Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/trans-expr.c
    trunk/gcc/fortran/trans-intrinsic.c
    trunk/gcc/fortran/trans-io.c
    trunk/gcc/fortran/trans-openmp.c
    trunk/gcc/fortran/trans.c


-- 


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

[Bug fortran/45186] [4.6 Regression] Gfortran 4.5.0 emits wrong linenumbers

[burnus at gcc dot gnu dot org]

------- Comment #14 from burnus at gcc dot gnu dot org  2010-09-05 18:10 -------
Subject: Bug 45186

Author: burnus
Date: Sun Sep  5 18:10:11 2010
New Revision: 163879

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163879
Log:
2010-09-05  Tobias Burnus  <burnus@net-b.de>

        PR fortran/45186
        * trans-intrinsic.c (gfc_conv_intrinsic_sign,
        gfc_conv_intrinsic_leadz): Use build_call_expr_loc instead
        of build_call_expr.
        * trans-expr.c (gfc_conv_expr_present, gfc_conv_missing_dummy,
        gfc_conv_string_length, gfc_conv_substring,
        gfc_conv_component_ref, gfc_conv_unary_op, gfc_conv_powi,
        gfc_conv_cst_int_power, gfc_conv_string_tmp, gfc_conv_concat_op,
        gfc_conv_expr_op, gfc_build_compare_string,
        gfc_set_interface_mapping_bounds, gfc_conv_subref_array_arg,
        gfc_conv_derived_to_class, conv_isocbinding_procedure,
        gfc_conv_procedure_call, fill_with_spaces,
        gfc_trans_string_copy, gfc_trans_alloc_subarray_assign,
        gfc_trans_structure_assign, gfc_trans_pointer_assignment,
        gfc_trans_scalar_assign, gfc_trans_zero_assign,
        gfc_trans_array_copy, gfc_trans_array_constructor_copy): Change
        fold_build[0-9] to fold_build[0-9]_loc.
        * trans-io.c (set_parameter_const, set_parameter_value,
        set_parameter_ref, gfc_convert_array_to_string, set_string,
        set_internal_unit, io_result, set_error_locus,
        nml_get_addr_expr, build_dt): Ditto.
        * trans-openmp.c (gfc_omp_clause_default_ctor,
        gfc_omp_clause_copy_ctor, gfc_omp_clause_assign_op,
        gfc_trans_omp_array_reduction, gfc_trans_omp_atomic,
        gfc_trans_omp_do): Ditto.
        * trans.c (gfc_add_modify, gfc_build_addr_expr,
        gfc_build_array_ref, gfc_trans_runtime_error_vararg,
        gfc_trans_runtime_check, gfc_call_malloc,
        gfc_allocate_with_status, gfc_allocate_array_with_status,
        gfc_call_free, gfc_deallocate_with_status,
        gfc_call_realloc): Ditto.


Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/convert.c
    trunk/gcc/fortran/f95-lang.c
    trunk/gcc/fortran/trans-intrinsic.c


-- 


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

[Bug fortran/45186] [4.6 Regression] Gfortran 4.5.0 emits wrong linenumbers

[burnus at gcc dot gnu dot org]

------- Comment #15 from burnus at gcc dot gnu dot org  2010-09-07 11:37 -------
Created an attachment (id=21725)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21725&action=view)
tree.h patch tp add build[0-9]_loc

(In reply to comment #9)
> grep -w build[0-9] trans*.c | wc -l
> 38
> grep -w build[0-9]_v trans*.c | wc -l
> 158

That part requires the attached patch to add build[0-9]_loc to gcc/tree.h. The
patch still needs to be build with all languages - and then "make -k check"
regtested ...

> grep -w fold_build[0-9] trans*.c | wc -l
> 734

That's now down to
  trans-array.c:198
and down to 117 in my local tree.


-- 


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

[Bug fortran/45186] [4.6 Regression] Gfortran 4.5.0 emits wrong linenumbers

[burnus at gcc dot gnu dot org]

------- Comment #16 from burnus at gcc dot gnu dot org  2010-09-07 15:29 -------
(In reply to comment #15)
> Created an attachment (id=21725)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21725&action=view) [edit]

+#define build6_loc(l,c,t1,t2,t3,t4,t5,t6,t7) \
+  build1_stat_loc (l,c,t1,t2,t3,t4,t5,t6,t7 MEM_STAT_INFO)

The last line should use -6- and not -1-, i.e. build1_stat_loc ->
build6_stat_loc


-- 


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

[Bug fortran/45186] [4.6 Regression] Gfortran 4.5.0 emits wrong linenumbers

[burnus at gcc dot gnu dot org]

------- Comment #17 from burnus at gcc dot gnu dot org  2010-09-07 19:03 -------
Subject: Bug 45186

Author: burnus
Date: Tue Sep  7 19:03:41 2010
New Revision: 163964

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163964
Log:
2010-09-07  Tobias Burnus <burnus@net-b.de>

        PR fortran/45186
        * trans-array.c (gfc_conv_descriptor_data_get,
        gfc_conv_descriptor_data_set, gfc_conv_descriptor_data_addr,
        gfc_conv_descriptor_offset, gfc_conv_descriptor_dtype,
        gfc_conv_descriptor_dimension, gfc_conv_descriptor_stride,
        gfc_conv_descriptor_lbound, gfc_conv_descriptor_ubound,
        gfc_conv_shift_descriptor_lbound,
        gfc_set_loop_bounds_from_array_spec,
        gfc_trans_allocate_array_storage, gfc_trans_create_temp_array,
        gfc_conv_array_transpose, gfc_get_iteration_count,
        gfc_grow_array, gfc_trans_array_ctor_element,
        gfc_trans_array_constructor_subarray,
        gfc_trans_array_constructor_value,
        constant_array_constructor_loop_size,
        gfc_trans_array_constructor,
        gfc_set_vector_loop_bounds, gfc_trans_array_bound_check,
        gfc_conv_array_index_offset, gfc_conv_scalarized_array_ref,
        gfc_conv_array_ref, gfc_trans_preloop_setup,
        gfc_trans_scalarized_loop_end, gfc_conv_ss_startstride,
        gfc_conv_loop_setup, gfc_conv_array_extent_dim,
        gfc_conv_descriptor_size, gfc_array_init_size,
        gfc_array_allocate, gfc_array_deallocate,
        gfc_trans_array_bounds, gfc_trans_auto_array_allocation,
        gfc_trans_dummy_array_bias, gfc_get_dataptr_offset,
        get_array_charlen, gfc_conv_expr_descriptor,
        array_parameter_size, gfc_conv_array_parameter,
        gfc_trans_dealloc_allocated, get_full_array_size,
        duplicate_allocatable,
        structure_alloc_comps): Change fold_build[0-9] to
        fold_build[0-9]_loc.
        (duplicate_allocatable, structure_alloc_comps,
        gfc_duplicate_allocatable): Add space after function name.


Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/trans-array.c


-- 


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

[Bug fortran/45186] [4.6 Regression] Gfortran 4.5.0 emits wrong linenumbers

[burnus at gcc dot gnu dot org]

------- Comment #18 from burnus at gcc dot gnu dot org  2010-09-09 19:33 -------
(In reply to comment #0)
> This is pretty widespread. I have attached one example

That's now mostly fixed - though one patch is pending. Now
  gfortran -fdump-tree-original-lineno
generates mostly sensible line numbers.

For the given example, only for the DO loop the line numbers are a bit counter
intuitive, given the line numbers
    14    do i = 1,10
    15       array1(i) = i
    16    end do

the dump of the internal representation (shown in a C-like syntax) is:

  [debug.f90 : 14] i = 1;
  [debug.f90 : 15] if ([debug.f90 : 15] i <= 10)
...
         [debug.f90 : 15] array1[[debug.f90 : 15] (integer(kind=8)) i + -1] =
i;
         L.1:;
         [debug.f90 : 15] D.1577 = [debug.f90 : 15] i == 10;
         [debug.f90 : 15] i = [debug.f90 : 15] i + 1;
         [debug.f90 : 15] if (D.1577) goto L.2;

The "i = 1" is in the expected line - as is the "array1(i) = i" assignment, but
the loop increment and the exit conditions I would expect in line 14 and not in
line 15.

If no one else does, I will have a look after the last "input_location" patch
has been committed. I expect that there are more cases where the annotation is
slightly misplaced.


If one looks at GCC 4.4, one finds:
  [debug.f90 : 14] i = 1;
  [debug.f90 : 14] if (i <= 10)
         [debug.f90 : 15] array1[(integer(kind=8)) i + -1] = i;
         L.1:;
         D.1550 = i == 10;
         i = i + 1;
         if (D.1550) goto L.2;

Thus, the first loop condition is in the proper line (14) while there is no
line number associated with the loop increment and the exit condition.


-- 


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

[Bug fortran/45186] [4.6 Regression] Gfortran 4.5.0 emits wrong linenumbers

[burnus at gcc dot gnu dot org]

------- Comment #19 from burnus at gcc dot gnu dot org  2010-09-10 06:02 -------
Subject: Bug 45186

Author: burnus
Date: Fri Sep 10 06:01:50 2010
New Revision: 164143

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164143
Log:
2010-09-10  Tobias Burnus  <burnus@net-b.de>

        PR fortran/45186
        * trans.h (build1_stat_loc, build2_stat_loc, build3_stat_loc,
        build4_stat_loc): New inline functions.
        (build1_loc, build2_loc, build3_loc, build4_loc): New macros.
        (build1_v, build2_v, build3_v, build4_v): Use input_location
        as locus.
        * trans-array.c (gfc_trans_scalarized_loop_end,
        gfc_conv_array_parameter): Replace build[1-4] by build[1-4]_loc.
        * trans.c (gfc_build_addr_expr, gfc_build_array_ref,
        gfc_finish_wrapped_block): Ditto.
        * trans-decl.c (gfc_init_default_dt, init_intent_out_dt): Ditto.
        * trans-expr.c (gfc_conv_missing_dummy,
        gfc_trans_alloc_subarray_assign, gfc_trans_zero_assign): Ditto.
        * trans-openmp.c (gfc_omp_clause_default_ctor,
        gfc_trans_omp_critical, gfc_trans_omp_parallel,
        gfc_trans_omp_parallel_do, gfc_trans_omp_parallel_sections,
        gfc_trans_omp_parallel_workshare, gfc_trans_omp_sections
        gfc_trans_omp_single, gfc_trans_omp_task,
        gfc_trans_omp_workshare): Ditto.


Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/trans-array.c
    trunk/gcc/fortran/trans-decl.c
    trunk/gcc/fortran/trans-expr.c
    trunk/gcc/fortran/trans-openmp.c
    trunk/gcc/fortran/trans.c
    trunk/gcc/fortran/trans.h


-- 


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

[Bug fortran/45186] [4.6 Regression] Gfortran 4.5.0 emits wrong linenumbers

[jv244 at cam dot ac dot uk]

------- Comment #20 from jv244 at cam dot ac dot uk  2010-09-10 06:36 -------
Tobias,

many thanks for working on this... I mentioned this before in the PR, but it
would be very good if some line number testcases were added to the regression
tests. Both for performance measurements and debugging, this is essential info,
and it is too remarkable good lineno info could 'disappear' from a released
(4.5) compiler just like that.

If there would be some semi-automatic way of checking the lineno quality (such
as e.g. in the original dump line numbers should always increase??), I'd be
happy to give it a try on CP2K. 

Joost


-- 


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

[Bug fortran/45186] [4.6 Regression] Gfortran 4.5.0 emits wrong linenumbers

[burnus at gcc dot gnu dot org]

------- Comment #21 from burnus at gcc dot gnu dot org  2010-09-10 07:25 -------
(In reply to comment #20)
> many thanks for working on this... I mentioned this before in the PR, but it
> would be very good if some line number testcases were added to the regression
> tests.

I concur - with -dump-tree-original-lineno this should be possible.

> If there would be some semi-automatic way of checking the lineno quality (such
> as e.g. in the original dump line numbers should always increase??)

No! As the example in comment 18 shows the line numbers should not always
monotonically  increase. Or at least I expect the "i = i + 1" to be associated
with the line
   do i = 1, 10
rather than with the line
      a(i) = b(i)
as the gfortran currently does. If you disagree, I can simply close this PR as
fixed ;-)


-- 


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