Re: [Patch, fortran, pr65548, addendum] [5/6 Regression] gfc_conv_procedure_call
Hi Thomas,
thanks for the review. Commited as r223738 with the changes (new testcase,
double space in dg-do).
Regards,
Andre
On Wed, 27 May 2015 08:38:07 +0200
Thomas Koenig tkoe...@netcologne.de wrote:
Hi Andre,
Because this patch is obvious I plan to commit it tomorrow if no one
objects?!
The patch itself is obviously OK.
About the test case: In general, it is better not to change existing
test cases unless absolutely necessary (e.g. adjust an error message).
This makes it easier to track regressions.
I would prefer if you made a new test case from your existing one,
with the changes you did and a small explanation of what was
tested in the comments.
If you are worried about runtime for an additonal test, you can use the
! { dg-do run }
hack (notice the two spaces between the dg-do and the run) to have the
test case execute only once.
OK with that change.
Regards
Thomas
--
Andre Vehreschild * Email: vehre ad gmx dot de
Re: [Patch, fortran, pr65548, addendum] [5/6 Regression] gfc_conv_procedure_call
Hi Andre,
Because this patch is obvious I plan to commit it tomorrow if no one objects?!
The patch itself is obviously OK.
About the test case: In general, it is better not to change existing
test cases unless absolutely necessary (e.g. adjust an error message).
This makes it easier to track regressions.
I would prefer if you made a new test case from your existing one,
with the changes you did and a small explanation of what was
tested in the comments.
If you are worried about runtime for an additonal test, you can use the
! { dg-do run }
hack (notice the two spaces between the dg-do and the run) to have the
test case execute only once.
OK with that change.
Regards
Thomas
Re: [Patch, fortran, pr65548, addendum] [5/6 Regression] gfc_conv_procedure_call
Hi all,
unfortunately introduced the latest optimization for this patch an ICE in
pFUnit again. The issue occurs when the -fbounds-check is used while
allocating an array of non-polymorphic or intrinsic type. It is caused by the
location of the gfc_expr of e3rhs not set which is needed to generate the
runtime error messages of the bounds check.
Bootstraps and regtests ok on x86_64-linux-gnu/f21.
Because this patch is obvious I plan to commit it tomorrow if no one objects?!
Regards,
Andre
On Wed, 20 May 2015 16:58:19 +0200
Andre Vehreschild ve...@gmx.de wrote:
Hi all,
Mikael, thanks for the review. Committed as r223445 (without the else-branch).
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
pr65548_6.clog
Description: Binary data
diff --git a/gcc/fortran/trans-stmt.c b/gcc/fortran/trans-stmt.c
index 2c0304b..81943b0 100644
--- a/gcc/fortran/trans-stmt.c
+++ b/gcc/fortran/trans-stmt.c
@@ -5362,6 +5362,7 @@ gfc_trans_allocate (gfc_code * code)
bug. */
newsym-n.sym-attr.referenced = 1;
e3rhs-expr_type = EXPR_VARIABLE;
+ e3rhs-where = code-expr3-where;
/* Set the symbols type, upto it was BT_UNKNOWN. */
newsym-n.sym-ts = e3rhs-ts;
/* Check whether the expr3 is array valued. */
diff --git a/gcc/testsuite/gfortran.dg/allocate_with_source_5.f90 b/gcc/testsuite/gfortran.dg/allocate_with_source_5.f90
index 500f0f0..06dfcad 100644
--- a/gcc/testsuite/gfortran.dg/allocate_with_source_5.f90
+++ b/gcc/testsuite/gfortran.dg/allocate_with_source_5.f90
@@ -1,4 +1,5 @@
! { dg-do run }
+! { dg-options -fbounds-check }
!
! Contributed by Juergen Reuter
! Check that pr65548 is fixed.
@@ -146,7 +147,7 @@ program test
if (any(abs(phs%m_in - [42.0, 42.0]) 1E-6)) call abort()
o%n = 2
- allocate (o%val(2,4))
+ allocate (o%val(0:1,4))
call o%make()
o2%n = 3
