Re: [Patch, Fortran] PR60576 Fix out-of-bounds problem

[Paul Richard Thomas]

Dear Tobias,

This is, of course, fine since it is 'obvious' (in my opinion at least).

Thanks for the patch

Paul

On 27 March 2014 21:05, Tobias Burnus bur...@net-b.de wrote:
 An early * PING* for this wrong-code issue.


 Tobias Burnus wrote:

 This patch fixes part of the problems of the PR. The problem is that one
 assigns an array descriptor to an assumed-rank array descriptor. The latter
 has for BT_CLASS the size of max_dim (reason: we have first the data array
 and than vtab). With true, one takes the TREE_TYPE from the LHS (i.e.
 the assumed-rank variable) and as the type determines how many bytes the
 range assignment copies, one reads max_dimension elements from the RHS array
 - which can be too much.

 Testcase: Already in the testsuite, even if it only fails under special
 conditions.

 Build and regtested on x86-64-gnu-linux.
 OK for the trunk and 4.8?

 Tobias

 PS: I haven't investigated the issues Jakub is seeing. With valgrind, they
 do not pop up and my attempt to build with all checking enabled, failed with
 configure or compile errors.





-- 
The knack of flying is learning how to throw yourself at the ground and miss.
   --Hitchhikers Guide to the Galaxy

Re: [Patch, Fortran] PR60576 Fix out-of-bounds problem

[Tobias Burnus]

An early * PING* for this wrong-code issue.

Tobias Burnus wrote:
This patch fixes part of the problems of the PR. The problem is that 
one assigns an array descriptor to an assumed-rank array descriptor. 
The latter has for BT_CLASS the size of max_dim (reason: we have first 
the data array and than vtab). With true, one takes the 
TREE_TYPE from the LHS (i.e. the assumed-rank variable) and as the 
type determines how many bytes the range assignment copies, one reads 
max_dimension elements from the RHS array - which can be too much.


Testcase: Already in the testsuite, even if it only fails under 
special conditions.


Build and regtested on x86-64-gnu-linux.
OK for the trunk and 4.8?

Tobias

PS: I haven't investigated the issues Jakub is seeing. With valgrind, 
they do not pop up and my attempt to build with all checking enabled, 
failed with configure or compile errors.

[Patch, Fortran] PR60576 Fix out-of-bounds problem

[Tobias Burnus]

This patch fixes part of the problems of the PR. The problem is that one 
assigns an array descriptor to an assumed-rank array descriptor. The 
latter has for BT_CLASS the size of max_dim (reason: we have first the 
data array and than vtab). With true, one takes the TREE_TYPE from 
the LHS (i.e. the assumed-rank variable) and as the type determines how 
many bytes the range assignment copies, one reads max_dimension elements 
from the RHS array - which can be too much.


Testcase: Already in the testsuite, even if it only fails under special 
conditions.


Build and regtested on x86-64-gnu-linux.
OK for the trunk and 4.8?

Tobias

PS: I haven't investigated the issues Jakub is seeing. With valgrind, 
they do not pop up and my attempt to build with all checking enabled, 
failed with configure or compile errors.
2014-03-25  Mikael Morin  mik...@gcc.gnu.org
	Tobias Burnus  bur...@net-b.de

	PR fortran/
	* trans-expr.c (gfc_conv_derived_to_class): Avoid
	generation of out-of-bounds range expr.

diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c
index f5350bb..30931a3 100644
--- a/gcc/fortran/trans-expr.c
+++ b/gcc/fortran/trans-expr.c
@@ -424,7 +426,11 @@ gfc_conv_derived_to_class (gfc_se *parmse, gfc_expr *e,
 	  gfc_conv_expr_descriptor (parmse, e);
 
 	  if (e-rank != class_ts.u.derived-components-as-rank)
-	class_array_data_assign (block, ctree, parmse-expr, true);
+	{
+	  gcc_assert (class_ts.u.derived-components-as-type
+			  == AS_ASSUMED_RANK);
+	  class_array_data_assign (block, ctree, parmse-expr, false);
+	}
 	  else
 	{
 	  if (gfc_expr_attr (e).codimension)