Re: [Patch, fortran] PR52012 - [4.6/4.7 Regression] Wrong-code with realloc on assignment and RESHAPE w/ ORDER=

Dear Tobias and Dominique,

> As "tmp" is a local variable, it is unallocated until the assignment. Thus,
> it should get as lower bound  "lbound(rhs-expr)", which is [1,1]. But currently
> it has result "[0, 0]".

Indeed, I set it to [0,0] on the grounds that it is unallocated.  I
will check but I am rather sure that the library will return [0,0] for
an unallocated result.

> I have done little testing with your patch, but it seems that
> the lbound is off by one (0 instead of 1) when doing a reallocation.

See above - I am aware of that - thanks.

I'll do some more on this at lunchtime.

Cheers

Paul

Re: [Patch, Fortran] PR52059 - Scalarizing fix - only add array ref to a variable

On 31.01.2012 23:22, Tobias Burnus wrote:
> Dear all,
>
> I have no idea about the scalarizer, but the attached patch fixes the
> test case and somehow adding an array ref to a scalar looks odd to me ...
>
??
The condition is about an array without array ref, isn't it?
We can't access the "array" part of the "data" union without checking 
before that it is an array.

To be clear the added if branch is there to catch temporaries created by 
the trans-stmt.c part of the regressing patch.  Those had no array ref, 
but gfc_conv_variable (they are temporaries for variables) expects one.
I thought I would have to revert the trans-expr.c part and try to detect 
temporaries somewhere else, but it seems your patch would do just fine.

> (Before the regression-causing patch, only the "else" branch existed.)
>
> Build and regtested on x86-64-linux.
> OK for the trunk?
>
OK, and thanks for it.

Mikael

PS: gfc_conv_derived_to_class has only the "else" branch, but has to 
handle elementals too; I wouldn't be surprised if there was a problem 
with it.

Re: [Patch, Fortran] PR 52024 - fix .mod issue with type-bound operator check

On 31.01.2012 23:41, Tobias Burnus wrote:
>
> Tobias Burnus wrote:
>> Unfortunately, it turns out that the check does not handle inheritance
>> well. At least I would expect that the attached test case is valid
>> (and it compiles with NAG 5.1), but it is rejected with GCC 4.6 and 4.7.
>
> Actually, I withdraw that comment.

OK without the FIXME then.  Thanks

Mikael

Re: [Patch, Fortran] PR 52024 - fix .mod issue with type-bound operator check

Dear Tobias,

> +! Contributed by Dominique d'Humieres

My contribution has only been to have the test in my files
(I have not even been able to keep the source of it! shame on me

> +    procedure :: gt_cmp =>  gt_cmp_int

With this change the ICE goes away even without the patch. Thus
I think it should not be included in the test.

Thanks for the patch,

Dominique

Cleanup of left-over module files in testsuite?

Hi all,

I tried to modify the source files of the gfortran.fortran-torture
part of the testsuite so that module files should be cleaned up
afterwards.  However, this does not work.
Does anybody see what I'm doing wrong?

Cheers,
Harald

Index: gcc/testsuite/gfortran.fortran-torture/compile/module_expr.f90
===================================================================
--- gcc/testsuite/gfortran.fortran-torture/compile/module_expr.f90	(revision 183807)
+++ gcc/testsuite/gfortran.fortran-torture/compile/module_expr.f90	(working copy)
 <at>  <at>  -16,3 +16,4  <at>  <at> 
    use module_expr_1
    use module_expr_2
 end program
+! { dg-final { cleanup-modules "module_expr_1 module_expr_2" } }
Index: gcc/testsuite/gfortran.fortran-torture/compile/pr33276.f90
===================================================================
--- gcc/testsuite/gfortran.fortran-torture/compile/pr33276.f90	(revision 183807)
+++ gcc/testsuite/gfortran.fortran-torture/compile/pr33276.f90	(working copy)
 <at>  <at>  -25,3 +25,4  <at>  <at> 
      end if
    end subroutine
 end
+! { dg-final { cleanup-modules "foo" } }
Index: gcc/testsuite/gfortran.fortran-torture/compile/pr42781.f90

Re: Cleanup of left-over module files in testsuite?

Hi Harald,

> Does anybody see what I'm doing wrong?

AFAICR there is no dg-final in gfortran.fortran-torture/*/*.exp.
I have had a look a while ago, but I cannot remember what I have
proposed, except that my attempt did not succeed;-(

Cheers,

Dominique

Re: Cleanup of left-over module files in testsuite?

On 01.02.2012 23:10, Harald Anlauf wrote:
> Hi all,
>
> I tried to modify the source files of the gfortran.fortran-torture
> part of the testsuite so that module files should be cleaned up
> afterwards.  However, this does not work.
> Does anybody see what I'm doing wrong?
>
As far as I know, the source files are not even parsed to find some dg-* 
dejagnu directive(s) in them.  No need to say that no attempt is made to 
process those directives then.

Mikael

Re: [Patch, fortran] PR52012 - [4.6/4.7 Regression] Wrong-code with realloc on assignment and RESHAPE w/ ORDER=

Dear Dominique and Tobias,

I am a little concerned about this:\
   real, dimension(:,:), allocatable :: tmp
   tmp = matmul(a,b)
   if (any (lbound (tmp) .ne. [1,1])) call abort

>> As "tmp" is a local variable, it is unallocated until the assignment. Thus,
>> it should get as lower bound  "lbound(rhs-expr)", which is [1,1]. But currently
>> it has result "[0, 0]".

I would agree with you if the test were if (any (lbound (tmp(:)) .ne.
[1,1])) call abort.  However, for a full array, as in the testcase,
the lbound should be that returned by matmul.  For an unallocated
result, this is zero.

Cheers

Paul

Re: [Patch, fortran] PR52012 - [4.6/4.7 Regression] Wrong-code with realloc on assignment and RESHAPE w/ ORDER=

Dear Paul,

Fist, I have taken the time to look at the standard. For LBOUND,
UBOUND, SIZE, and SHAPE, it says:

> ARRAY shall be an array of any type. It shall not be an unallocated allocatable variable
> or a pointer that is not associated.

(+ constraints for "assumed-size array" and SIZE, SHAPE, and UBOUND). My reading of the "shall"
is that the burden is on the user and not on the compiler (it is not presently detected at compile
time by gfortran).

So when you write

> For an unallocated result, this is zero.

this can only be internal representation and AFAICT it is not reset on deallocation.

> the lbound should be that returned by matmul

Here I have a doubt: should it be 1 (it cannot be 0)? this could be supported by
Element (i; j) of the result has the value SUM (MATRIX A (i, :) * MATRIX B (:, j)) ...
involving section; or the lower bounds of DIM==1 for a and DIM==2 for b?

I think this should be the lbound of the lhs array after the assignment.

Quick thoughts for the time being: I have to run!

Cheers,

Re: [Patch, fortran] PR52012 - [4.6/4.7 Regression] Wrong-code with realloc on assignment and RESHAPE w/ ORDER=

Dear Paul,

On Thu, Feb 02, 2012 at 10:14:13AM +0100, Paul Richard Thomas wrote:
> I am a little concerned about this:\
>    real, dimension(:,:), allocatable :: tmp
>    tmp = matmul(a,b)
>    if (any (lbound (tmp) .ne. [1,1])) call abort
> 
> >> As "tmp" is a local variable, it is unallocated until the assignment. Thus,
> >> it should get as lower bound  "lbound(rhs-expr)", which is [1,1]. But currently
> >> it has result "[0, 0]".
> 
> I would agree with you if the test were if (any (lbound (tmp(:)) .ne.
> [1,1])) call abort.  However, for a full array, as in the testcase,
> the lbound should be that returned by matmul.  For an unallocated
> result, this is zero.

I am lost. At least for realloc_on_assign_7.f03's

  subroutine pr48746
    integer, parameter :: m=10, n=12, count=4
    real :: a(m, count), b(count, n), c(m, n)
    real, dimension(:,:), allocatable :: tmp
    tmp = matmul(a,b)

One has "a(10,4), b(4, 12)" and thus
  lbound (matmul (a, b)) == [1, 1]
  ubound (matmul (a, b)) == [10, 12]

There is no allocatable involved at all in the RHS. And - in Fortran -