[Fortran] PR60576 Fix out-of-bounds problem

Submitted by Tobias Burnus on March 24, 2014, 11:59 p.m.

Details

Message ID 5330C6E0.4040103@net-b.de
State New
Headers show

Commit Message

Tobias Burnus March 24, 2014, 11:59 p.m.
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.

Comments

Tobias Burnus March 27, 2014, 8:05 p.m.
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.
Paul Richard Thomas March 28, 2014, 11:30 a.m.
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 <burnus@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.
>
>

Patch hide | download patch | download mbox

2014-03-25  Mikael Morin  <mikael@gcc.gnu.org>
	    Tobias Burnus  <burnus@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)