Bug 35681 - wrong result for vector subscripted array expression in MVBITS
wrong result for vector subscripted array expression in MVBITS
Status: RESOLVED FIXED
Product: gcc
Classification: Unclassified
Component: fortran
4.4.0
: P3 normal
: 4.4.0
Assigned To: Mikael Morin
: wrong-code
Depends on:
Blocks: 32834
  Show dependency treegraph
 
Reported: 2008-03-24 19:39 UTC by Dick Hendrickson
Modified: 2009-01-29 17:35 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail: 4.4.0
Last reconfirmed: 2008-11-14 13:01:53


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dick Hendrickson 2008-03-24 19:39:52 UTC
The following program prints out the wrong results when an
array with vector valued subscript is used in an expression
as the FROM argument and also used as the TO argument.
The array case gives different results from a similar
scalar DO loop.

If a different array is used in the FROM argument, the array
results are the same as the scalar results.

I'd guess that you aren't recognizing
(ILA1(NFV3))
as an expression and copying it to a temp before invoking
MVBITS.

Dick Hendrickson


      program YA0017

! gcc version 4.4.0 20080312 (experimental) [trunk revision 133139] (GCC)

      INTEGER ILA1(10)
      INTEGER ILA2(10)
      INTEGER ICA3(10), nfv3(10)
      ILA1 = (/1,2,3,4,5,6,7,8,9,10/)
      ILA2 = (/1,2,3,4,5,6,7,8,9,10/)
      ica3 = (/1,2,3,4,5,6,7,8,9,10/)
      nfv3 = (/9,9,6,2,4,9,2,9,6,10/)

      DO J1 = 1,10
        CALL MVBITS(Ila1(NFV3(J1)),2,4,ILA2(J1), 3)
      ENDDO

      CALL MVBITS ((ILA1(NFV3)), 2, 4, ILA1, 3)       !fails

      print *, 'first test'
      DO J1 = 1,10
      IF (ILA1(J1) .NE. ILA2(J1))
     $ print *, 'j1 = ', j1, '  vvs = ', nfv3(j1),
     $ '  scalar =', ila2(j1), '  vector = ', ila1(j1)
      ENDDO


      ILA1 = (/1,2,3,4,5,6,7,8,9,10/)
      ILA2 = (/1,2,3,4,5,6,7,8,9,10/)
      ica3 = (/1,2,3,4,5,6,7,8,9,10/)
      nfv3 = (/9,9,6,2,4,9,2,9,6,10/)

      DO J1 = 1,10
        CALL MVBITS(Ica3(NFV3(J1)),2,4,ILA2(J1), 3)
      ENDDO

      CALL MVBITS ((Ica3(NFV3)), 2, 4, ILA1, 3)      !works

      print *, 'second test'
      DO J1 = 1,10
      IF (ILA1(J1) .NE. ILA2(J1))
     $ print *, 'j1 = ', j1, '  vvs = ', nfv3(j1),
     $ '  scalar =', ila2(j1), '  vector = ', ila1(j1)
      ENDDO
      END 


-------------------------------------------------------
results
C:\g_experiments\gfortran>gfortran ya0017.f
C:\g_experiments\gfortran>a
 first test
 j1 =            4   vvs =            2   scalar =           4   vector =
    36
 j1 =            5   vvs =            4   scalar =          13   vector =
    77
 j1 =            7   vvs =            2   scalar =           7   vector =
    39
 j1 =            9   vvs =            6   scalar =           9   vector =
    41
 second test
Comment 1 Francois-Xavier Coudert 2008-03-28 15:18:30 UTC
Reduced testcase:

  integer, dimension(10) :: ILA1 = (/1,2,3,4,5,6,7,8,9,10/)
  call mvbits ((ILA1((/9,9,6,2,4,9,2,9,6,10/))), 2, 4, ILA1, 3)
  write (*,'(10(I3))') ila1
  end 

output is:
   17 18 11 36 77 22 39 16 41 18
while it should be:
   17 18 11  4 13 22  7 16  9 18


I don't know if it related, but the following compiles and segfault at runtime:

  integer, dimension(10) :: ILA1 = (/1,2,3,4,5,6,7,8,9,10/)
  call mvbits ((ILA1((/9/))), 2, 4, ILA1, 3)
  write (*,'(10(I3))') ila1
  end 

while it gives a strange error message with -fbounds-check:

At line 2 of file a.f90
Fortran runtime error: Array reference out of bounds for array 'ila1', upper bound of dimension 1  exceeded (68 > 10)
Comment 2 Dominique d'Humieres 2008-03-28 15:29:05 UTC
For the second test in comment #1, ifort gives:

fortcom: Error: pr35681_2.f90, line 2: The shapes of the arguments do not conform.   [MVBITS]
  call mvbits ((ILA1((/9/))), 2, 4, ILA1, 3)
------------------------------------^

Comment 3 Dick Hendrickson 2008-03-28 15:48:42 UTC
Subject: Re:  wrong result for vector subscripted array expression in MVBITS

Right, in case you haven't found it yet, the first paragraph of
12.7.3, page 214, says effectively
that all of the arguments must be conformable with the TO argument.  I
was mildly amused
that a significant restriction on MVBITS came in the paragraph before
the one that
explicitly discusses MVBITS.

Dick Hendrickson

On 28 Mar 2008 15:29:05 -0000, dominiq at lps dot ens dot fr
<gcc-bugzilla@gcc.gnu.org> wrote:
>
>
>  ------- Comment #2 from dominiq at lps dot ens dot fr  2008-03-28 15:29 -------
>  For the second test in comment #1, ifort gives:
>
>  fortcom: Error: pr35681_2.f90, line 2: The shapes of the arguments do not
>  conform.   [MVBITS]
>
>   call mvbits ((ILA1((/9/))), 2, 4, ILA1, 3)
>  ------------------------------------^
>
>
>  --
>
>
>
>
>  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35681
>
>  ------- You are receiving this mail because: -------
>  You reported the bug, or are watching the reporter.
>
Comment 4 Dominique d'Humieres 2008-03-28 16:22:12 UTC
It looks like a missing temporary:

  integer, dimension(10) :: ILA1 = (/1,2,3,4,5,6,7,8,9,10/), ILA2, ILA3
  ILA3 = (/9,9,6,2,4,9,2,9,6,10/)
  print '(10(I3))', ILA1((/9,9,6,2,4,9,2,9,6,10/))
  ILA2 = ILA1
  do i = 1, 10
     call mvbits (ila2(ila3(i)), 2, 4, ila2(i), 3)
  end do
  write (*,'(10(I3))') ila2
  ILA2 = ILA1
  call mvbits ((ILA1((/9,9,6,2,4,9,2,9,6,10/))), 2, 4, ILA2, 3)
  write (*,'(10(I3))') ila2
  call mvbits ((ILA1((/9,9,6,2,4,9,2,9,6,10/))), 2, 4, ILA1, 3)
  write (*,'(10(I3))') ila1
  if (any(ila1 /= ila2)) call abort()
  end 

yields

  9  9  6  2  4  9  2  9  6 10
 17 18 11 36 77 22 39 16 41 18
 17 18 11  4 13 22  7 16  9 18
 17 18 11 36 77 22 39 16 41 18
Abort

Comment 5 Daniel Kraft 2008-10-14 16:20:44 UTC
I will look at this and try to work it out, taking it for now.
Comment 6 Daniel Kraft 2008-10-16 16:32:30 UTC
Fixed the accepts-invalid mentioned in comment #1 (patch posted at http://gcc.gnu.org/ml/fortran/2008-10/msg00145.html) on trunk, but the main problem here is still there, I'll start to work on it directly now.
Comment 7 Daniel Kraft 2008-10-18 08:27:10 UTC
I'm having some difficulties seeing what the problem really is...  My understanding of elemental procedures so far is that they should be more or less equivalent to looping over the arguments and then performing them as the standard seems to enforce the order and such is not important...  What do I miss?  Is the following program supposed to swap the elements in a and b?

PROGRAM main
  IMPLICIT NONE
  INTEGER :: a(2)

  a = (/ 1, 2 /)
  CALL copy (a((/ 2, 1 /)), a)
  PRINT *, a

  STOP

CONTAINS

  ELEMENTAL SUBROUTINE copy (a, b)
    IMPLICIT NONE
    INTEGER, INTENT(IN) :: a
    INTEGER, INTENT(OUT) :: b

    b = a
  END SUBROUTINE copy

END PROGRAM main

This prints "2 2" at the moment, which seems quite reasonable to me; or does the standard enforce it should print "2 1"?  If so, where can I find the details about this (i.e. need temporaries only for INTENT(IN) arguments that are TARGETS or also passed to INTENT(*OUT) parameters, or also for INTENT(INOUT) ones...)?
Comment 8 Dominique d'Humieres 2008-10-18 09:31:11 UTC
(In reply to comment #7)
> This prints "2 2" at the moment, which seems quite reasonable to me; or does
> the standard enforce it should print "2 1"?

ifort returns "2 2" and g95 "2 1".  As far as I understand the scalarization of elemental procedures, I think g95 is right. Considering the following modification of the code:

PROGRAM main
  IMPLICIT NONE
  INTEGER :: i, a(2), b(2)

  a = (/ 1, 2 /)
  b = (/ 2, 1 /)
  CALL copy (a((/ 2, 1 /)), a)
  PRINT *, a
  a = (/ 1, 2 /)
  do i = 1, 2
     CALL copy (a(b(i)), a(i))
  end do
  PRINT *, a
  a = (/ 1, 2 /)
  do i = 2, 1, -1
     CALL copy (a(b(i)), a(i))
  end do
  PRINT *, a

  STOP

CONTAINS

  ELEMENTAL SUBROUTINE copy (a, b)
    IMPLICIT NONE
    INTEGER, INTENT(IN) :: a
    INTEGER, INTENT(OUT) :: b

    b = a
  END SUBROUTINE copy

END PROGRAM main

which gives:

           2           1
           2           2
           2           2
           1           1

i.e., a result depending on the order of the scalar do loop, my understanding is that a temporary is required.

Comment 9 Tobias Burnus 2008-10-18 10:20:50 UTC
(In reply to comment #8)
> ifort returns "2 2" and g95 "2 1".  As far as I understand the scalarization
> of elemental procedures, I think g95 is right.

sunf95, openf95, NAG f95 and pathscale's pathf95 also return 2 1; Portland group's pgf95 has "2 2".

I think we need an array temporary if an a variable appears twice in an argument list, if one of these arguments has an array section (except for whole-array sections "(:)").

Special care might be necessary: Pointers as actual argument and  elemental functions of the type  array = func(array(section)), I'm not sure and need to re-read the standard.
Comment 10 Tobias Burnus 2008-10-18 11:36:01 UTC
Somehow reading the bug report first before replying helps ... Ignore the crap I just wrote.

Dick's (comment 0)
      CALL MVBITS ((ILA1(NFV3)), 2, 4, ILA1, 3)       !fails
is valid as the first and the fourth argument don't refer to the same variable - the first argument is an expression for which a temporary needs to be created.

Ditto for FX's (comment 1)
  call mvbits ((ILA1((/9/))), 2, 4, ILA1, 3)

However, comment 7's
  CALL copy (a((/ 2, 1 /)), a)
is wrong as one passes twice the same variable - once as array section and once as whole array. There an outer ( ... ) is missing which is needed to makes this an expression.

For a lengthy answer including where to find it in the standard, see:
 http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/160867d13fd90927/


Seemingly somewhere  (x)  is simplified to x (= EXPR_VARIABLE) and thus no temporary is created - or something like that. For non-elemental procedures this was fixed in gfortran 4.3; before foo((x),x) was optimized to foo((x),x).

One can probably ignore all examples after comment 1 and start with looking why no temporary is created for comment 1 - afterwards one needs to check comment 0.
Comment 11 Dick Hendrickson 2008-10-18 17:02:06 UTC
Subject: Re:  wrong result for vector subscripted array expression in MVBITS

Also, MVBITS is a special case.  See the top of page 215 in the F95
standard.  The FROM
and TO arguments are allowed to be the same variable.  The other thing
about overlapping
variables is (2) on page 205, which is a long way from the section
header and is often
overlooked (at least I missed it once).

I'm off to help paint my granddaughter's bedroom, so I can't think
much about this.

Somewhere, along time ago, there was a smallish test program of the form
            subroutine xxx(a,b)
            b = b+1
            print *, a,b
            end
and then a ton of call statements of the forms

           a = 99
           call xxx ((a),a)
           or
           call xxx( 1*a,a)
           or
           call xxx(a+0, a)
...
which might be a good thing to invent as a way to check that you
aren't oversimplifing
actual expressions.

Dick Hendrickson


On Sat, Oct 18, 2008 at 6:36 AM, burnus at gcc dot gnu dot org
<gcc-bugzilla@gcc.gnu.org> wrote:
>
>
> ------- Comment #10 from burnus at gcc dot gnu dot org  2008-10-18 11:36 -------
> Somehow reading the bug report first before replying helps ... Ignore the crap
> I just wrote.
>
> Dick's (comment 0)
>      CALL MVBITS ((ILA1(NFV3)), 2, 4, ILA1, 3)       !fails
> is valid as the first and the fourth argument don't refer to the same variable
> - the first argument is an expression for which a temporary needs to be
> created.
>
> Ditto for FX's (comment 1)
>  call mvbits ((ILA1((/9/))), 2, 4, ILA1, 3)
>
> However, comment 7's
>  CALL copy (a((/ 2, 1 /)), a)
> is wrong as one passes twice the same variable - once as array section and once
> as whole array. There an outer ( ... ) is missing which is needed to makes this
> an expression.
>
> For a lengthy answer including where to find it in the standard, see:
>
> http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/160867d13fd90927/
>
>
> Seemingly somewhere  (x)  is simplified to x (= EXPR_VARIABLE) and thus no
> temporary is created - or something like that. For non-elemental procedures
> this was fixed in gfortran 4.3; before foo((x),x) was optimized to foo((x),x).
>
> One can probably ignore all examples after comment 1 and start with looking why
> no temporary is created for comment 1 - afterwards one needs to check comment
> 0.
>
>
> --
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35681
>
> ------- You are receiving this mail because: -------
> You reported the bug, or are watching the reporter.
>
Comment 12 Paul Thomas 2008-10-19 14:34:03 UTC
To put the arguments succinctly, this is a double problem (apart from the conformity issue):

(i) The original test case is losing the EXPR_PARENTHESES for some reason.  ie. there is no question that in this case a temporary should be made for the 'FROM' actual argument.

(ii) 12.7.3    Elemental subroutine actual arguments
"An elemental subroutine is one that has only scalar dummy arguments, but may have array actual arguments. In a reference to an elemental subroutine, either all actual arguments shall be scalar, or all actual arguments associated with INTENT (OUT) and INTENT (INOUT) dummy arguments shall be arrays of the same shape and the remaining actual arguments shall be conformable with them. In the case that the actual arguments associated with INTENT (OUT) and INTENT (INOUT) dummy arguments are arrays, the values of the elements, if any, of the results are the same as would be obtained if the subroutine had been applied separately, in any order, to corresponding elements of each array actual argument. In a reference to the intrinsic subroutine MVBITS, the actual arguments corresponding to the TO and FROM dummy arguments may be the same variable. Apart from this, the actual arguments in a reference to an elemental subroutine must satisfy the restrictions of 12.4.1.6."

Since the 'TO' and 'FROM' arguments can alias in MVBITS and the results must be order independent, the test case should also create a temporary, even without enclosing parentheses.  For the reason described before trans-stmt.c(gfc_conv_elemental_dependencies) this should be the 'TO' variable and should be done on the basis of a dependency between 'TO' and 'FROM' to be safe.

The implementation is complicated by the resolved_sym for MVBITS not carrying formal arguments so that gfc_conv_elemental_dependencies does nothing, even if it is "spoon-fed" the call.

Paul puts thinking hat on!


Comment 13 Daniel Kraft 2008-10-19 14:46:53 UTC
Paul, thanks for stepping into the party :)

My plan for working on this is to look at the first part of the problem for now (the lost parentheses, this is a general ELEMENTAL problem, as my (invalid) test from comment #7 also fails for adding parentheses around the first argument).  I hope this can be fixed quite straight forward if I find the problem.

After this, we can look at the MVBITS specific part.  I think this is a reasonable way to work on this problem; what do you think?
Comment 14 Daniel Kraft 2008-10-19 16:16:23 UTC
Actually, the parentheses aren't lost and *do* get honoured, but the temporary is only inside the scalarization loop and thus not the full array temporary we want; the problem is that the actual argument expressions (and thus the EXPR_OP) gets translated inside gfc_conv_function_call which is only inside the scalarization loop for ELEMENTAL calls and thus only a scalar temporary.

A possible approach for solving this problem in a way that looks more or less clean to me would be to translate call expression arguments in gfc_trans_call before gfc_conv_function_call, i.e. before even generating the ELEMENTAL scalarization loop.  This would however of course be a somewhat intrusive patch and I want to make sure you agree with this plan.  Or is there some other way I'm not aware of?  I'm just thinking that moving this expression translation that would take care of parentheses and friends would not involve any "new" code but rather reorganize the existing one and thus utilize what's already there to its best.
Comment 15 Daniel Kraft 2008-11-01 13:27:42 UTC
Subject: Bug 35681

Author: domob
Date: Sat Nov  1 13:26:19 2008
New Revision: 141516

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141516
Log:
2008-11-01  Daniel Kraft  <d@domob.eu>

	PR fortran/35681
	* gfortran.h (struct gfc_code): New field `resolved_isym'.
	* trans.h (gfc_build_memcpy_call): Made public.
	* trans-array.h (gfc_trans_create_temp_array): New argument `initial'.
	* intrinsic.c (gfc_intrinsic_sub_interface): Set resolved_isym.
	* iresolve.c (create_formal_for_intents): New helper method.
	(gfc_resolve_mvbits): Put dummy formal arglist on resolved_sym.
	* resolve.c (resolve_call): Initialize resolved_isym to NULL.
	* trans-array.c (gfc_trans_allocate_array_storage): New argument
	`initial' to allow initializing the allocated storage to some initial
	value copied from another array.
	(gfc_trans_create_temp_array): Allow initialization of the temporary
	with a copy of some other array by using the new extension.
	(gfc_trans_array_constructor): Pass NULL_TREE for initial argument.
	(gfc_conv_loop_setup): Ditto.
	* trans-intrinsic.c (gfc_conv_intrinsic_array_transfer): Ditto.
	* trans-expr.c (gfc_conv_function_call): Ditto.
	(gfc_build_memcpy_call): Made public.
	* trans-stmt.c (gfc_conv_elemental_dependencies): Initialize created
	temporary for INTENT(INOUT) arguments to the value of the mirrored
	array and clean up the temporary as very last intructions in the created
	block.
	* trans.c (gfc_trans_code): For EXEC_CALL, see if we have a MVBITS call
	and enable elemental dependency checking if we have.

2008-11-01  Daniel Kraft  <d@domob.eu>

	PR fortran/35681
	* gfortran.dg/mvbits_4.f90: New test.

Added:
    trunk/gcc/testsuite/gfortran.dg/mvbits_4.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/gfortran.h
    trunk/gcc/fortran/intrinsic.c
    trunk/gcc/fortran/iresolve.c
    trunk/gcc/fortran/resolve.c
    trunk/gcc/fortran/trans-array.c
    trunk/gcc/fortran/trans-array.h
    trunk/gcc/fortran/trans-expr.c
    trunk/gcc/fortran/trans-intrinsic.c
    trunk/gcc/fortran/trans-stmt.c
    trunk/gcc/fortran/trans.c
    trunk/gcc/fortran/trans.h
    trunk/gcc/testsuite/ChangeLog

Comment 16 Daniel Kraft 2008-11-01 13:37:10 UTC
This commit implements correct dependency and temporary handling if the arguments to MVBITS are *not* expressions; thus it does not yet fix the original test, although it fixes it if the parentheses are taken off the first argument.  This other problem with ELEMENTAL scalarization will be part 2...
Comment 17 Daniel Kraft 2008-11-13 17:16:47 UTC
Unassigning myself.  Mikael will probably want to take the missing part on with his pending patch :)
Comment 18 Mikael Morin 2008-11-14 13:01:52 UTC
(In reply to comment #17)
> Unassigning myself.  Mikael will probably want to take the missing part on with
> his pending patch :)
> 
Regressions are making my life tough right now, but I will succeed in the end. :)
Taking it.
Comment 19 Mikael Morin 2008-11-16 22:46:34 UTC
Subject: Bug 35681

Author: mikael
Date: Sun Nov 16 22:45:10 2008
New Revision: 141931

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141931
Log:
2008-11-16  Mikael Morin <mikael.morin@tele2.fr>

	PR fortran/35681
	* dependency.c (gfc_check_argument_var_dependency): Add
	elemental check flag. Issue a warning if we find a dependency
	but don't generate a temporary. Add the case of an elemental
	function call as actual argument to an elemental procedure.
	Add the case of an operator expression as actual argument
	to an elemental procedure.
	(gfc_check_argument_dependency): Add elemental check flag.
	Update calls to gfc_check_argument_var_dependency.
	(gfc_check_fncall_dependency): Add elemental check flag.
	Update call to gfc_check_argument_dependency.
	* trans-stmt.c (gfc_trans_call): Make call to
	gfc_conv_elemental_dependency unconditional, but with a flag
	whether we should check dependencies between variables.
	(gfc_conv_elemental_dependency): Add elemental check flag.
	Update call to gfc_check_fncall_dependency.
	* trans-expr.c (gfc_trans_arrayfunc_assign): Update call to
	gfc_check_fncall_dependency.
	* resolve.c (find_noncopying_intrinsics): Update call to
	gfc_check_fncall_dependency.
	* dependency.h (enum gfc_dep_check): New enum.
	(gfc_check_fncall_dependency): Update prototype.

2008-11-16  Mikael Morin <mikael.morin@tele2.fr>

	PR fortran/35681
	* gfortran.dg/elemental_dependency_1.f90: New test.


Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/dependency.c
    trunk/gcc/fortran/dependency.h
    trunk/gcc/fortran/resolve.c
    trunk/gcc/fortran/trans-expr.c
    trunk/gcc/fortran/trans-stmt.c
    trunk/gcc/testsuite/ChangeLog

Comment 20 Tobias Burnus 2008-11-23 19:07:54 UTC
Mikael, Daniel: Have I missed something or is everything in this PR fixed in 4.4 ("trunk") and only some 4.3 back porting is needed?
Comment 21 Mikael Morin 2008-11-24 12:15:29 UTC
Subject: Bug 35681

Author: mikael
Date: Mon Nov 24 12:13:59 2008
New Revision: 142154

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142154
Log:
2008-11-24  Mikael Morin <mikael.morin@tele2.fr>

	PR fortran/35681
	* dependency.c (gfc_check_argument_var_dependency): Add
	elemental check flag. Issue a warning if we find a dependency
	but don't generate a temporary. Add the case of an elemental
	function call as actual argument to an elemental procedure.
	Add the case of an operator expression as actual argument
	to an elemental procedure.
	(gfc_check_argument_dependency): Add elemental check flag.
	Update calls to gfc_check_argument_var_dependency.
	(gfc_check_fncall_dependency): Add elemental check flag.
	Update call to gfc_check_argument_dependency.
	* trans-stmt.c (gfc_trans_call): Make call to
	gfc_conv_elemental_dependency unconditional, but with a flag
	whether we should check dependencies between variables.
	(gfc_conv_elemental_dependency): Add elemental check flag.
	Update call to gfc_check_fncall_dependency.
	* trans-expr.c (gfc_trans_arrayfunc_assign): Update call to
	gfc_check_fncall_dependency.
	* resolve.c (find_noncopying_intrinsics): Update call to
	gfc_check_fncall_dependency.
	* dependency.h (enum gfc_dep_check): New enum.
	(gfc_check_fncall_dependency): Update prototype.

2008-11-24  Mikael Morin <mikael.morin@tele2.fr>

	PR fortran/35681
	* gfortran.dg/elemental_dependency_1.f90: New test.


Modified:
    branches/gcc-4_3-branch/gcc/fortran/ChangeLog
    branches/gcc-4_3-branch/gcc/fortran/dependency.c
    branches/gcc-4_3-branch/gcc/fortran/dependency.h
    branches/gcc-4_3-branch/gcc/fortran/resolve.c
    branches/gcc-4_3-branch/gcc/fortran/trans-expr.c
    branches/gcc-4_3-branch/gcc/fortran/trans-stmt.c
    branches/gcc-4_3-branch/gcc/testsuite/ChangeLog

Comment 22 Mikael Morin 2008-11-24 12:25:48 UTC
Argh!!
elemental_dependency_1.f90 was not committed.
Comment 23 Mikael Morin 2008-11-24 12:38:49 UTC
Subject: Bug 35681

Author: mikael
Date: Mon Nov 24 12:37:25 2008
New Revision: 142155

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142155
Log:
2008-11-24  Mikael Morin <mikael.morin@tele2.fr>

	PR fortran/35681
	* gfortran.dg/elemental_dependency_1.f90: Really commit it.


Added:
    trunk/gcc/testsuite/gfortran.dg/elemental_dependency_1.f90
Modified:
    trunk/gcc/testsuite/ChangeLog

Comment 24 Mikael Morin 2008-11-24 12:48:19 UTC
Subject: Bug 35681

Author: mikael
Date: Mon Nov 24 12:46:57 2008
New Revision: 142156

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142156
Log:
2008-11-24  Mikael Morin  <mikael.morin@tele2.fr>

	PR fortran/35681
	* gfortran.dg/elemental_dependency_1.f90: Really commit it.


Added:
    branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/elemental_dependency_1.f90
Modified:
    branches/gcc-4_3-branch/gcc/testsuite/ChangeLog

Comment 25 Mikael Morin 2008-11-24 13:10:11 UTC
(In reply to comment #22)
> Argh!!
> elemental_dependency_1.f90 was not committed.
> 
Fixed now, sorry for the noise.


(In reply to comment #20)
> Mikael, Daniel: Have I missed something or is everything in this PR fixed in
> 4.4 ("trunk") and only some 4.3 back porting is needed?
> 
Sorry for forgetting about it. 
Yes, I think it is fixed, and I've just back-ported.
closing now.
Comment 26 Paul Thomas 2008-11-24 19:14:42 UTC
Subject: Bug 35681

Author: pault
Date: Mon Nov 24 19:13:12 2008
New Revision: 142169

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142169
Log:
2008-11-24  Steven G. Kargl  <kargls@comcast.net>

	PR fortran/37792
	* fortran/resolve.c (resolve_fl_variable): Simplify the
	initializer if there is one.

2008-11-24  Steven G. Kargl  <kargls@comcast.net>

	PR fortran/37792
	* gfortran.dg/arithmetic_overflow_1.f90: New test.

2008-11-24  Mikael Morin  <mikael.morin@tele2.fr>

	PR fortran/35681
	* gfortran.dg/elemental_dependency_1.f90: Correct strings in test.


Added:
    branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/arithmetic_overflow_1.f90
Modified:
    branches/gcc-4_3-branch/gcc/fortran/ChangeLog
    branches/gcc-4_3-branch/gcc/fortran/resolve.c
    branches/gcc-4_3-branch/gcc/testsuite/ChangeLog
    branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/elemental_dependency_1.f90

Comment 27 Mikael Morin 2009-01-04 19:12:36 UTC
Subject: Bug 35681

Author: mikael
Date: Sun Jan  4 19:12:16 2009
New Revision: 143057

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143057
Log:
2009-01-04  Mikael Morin  <mikael.morin@tele2.fr>

	PR fortran/35681
	* ChangeLog-2008: Fix function name.

	PR fortran/38487
	* dependency.c (gfc_check_argument_var_dependency):
	Move the check for pointerness inside the if block
	so that it doesn't affect the return value.

	PR fortran/38669
	* trans-stmt.c (gfc_trans_call):
	Add the dependency code after the loop bounds calculation one.

2009-01-04  Mikael Morin  <mikael.morin@tele2.fr>

	PR fortran/38669
	* gfortran.dg/elemental_dependency_3.f90: New test.
	* gfortran.dg/elemental_subroutine_7.f90: New test.


Added:
    trunk/gcc/testsuite/gfortran.dg/elemental_dependency_3.f90
    trunk/gcc/testsuite/gfortran.dg/elemental_subroutine_7.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/ChangeLog-2008
    trunk/gcc/fortran/dependency.c
    trunk/gcc/fortran/trans-stmt.c
    trunk/gcc/testsuite/ChangeLog

Comment 28 Mikael Morin 2009-01-14 20:53:34 UTC
Subject: Bug 35681

Author: mikael
Date: Wed Jan 14 20:53:18 2009
New Revision: 143383

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143383
Log:
2009-01-14  Mikael Morin  <mikael.morin@tele2.fr>

	PR fortran/35681
	* ChangeLog: Fix function name.

	PR fortran/38487
	* dependency.c (gfc_check_argument_var_dependency):
	Move the check for pointerness inside the if block
	so that it doesn't affect the return value.

	PR fortran/38669
	* trans-stmt.c (gfc_trans_call):
	Add the dependency code after the loop bounds calculation one.

2009-01-14  Mikael Morin  <mikael.morin@tele2.fr>

	PR fortran/38669
	* gfortran.dg/elemental_dependency_3.f90: New test.
	* gfortran.dg/elemental_subroutine_7.f90: New test.


Added:
    branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/elemental_dependency_3.f90
    branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/elemental_subroutine_7.f90
Modified:
    branches/gcc-4_3-branch/gcc/fortran/ChangeLog
    branches/gcc-4_3-branch/gcc/fortran/dependency.c
    branches/gcc-4_3-branch/gcc/fortran/trans-stmt.c
    branches/gcc-4_3-branch/gcc/testsuite/ChangeLog