Re: [Patch, fortran] PR fortran/82376 - Duplicate function call using -fcheck=pointer

2021-04-25 Thread Paul Richard Thomas via Fortran
Hi José!

The fix is fine.

Note however that the testcase will pass even without the fix because you
haven't included the
! { dg-options "-fcheck=pointer" }.

In fact, I suggest that you use the version of the tescase that I have
attached that does not run but counts the number of occurrences of 'new' in
the tree dump.

OK for master, certainly for 11-branch, when it is open again, and for
10-branch after a wait.

Are you reliant on others to commit and push your patches or have you done
the FSF paperwork?

Thanks

Paul




On Thu, 22 Apr 2021 at 21:50, José Rui Faustino de Sousa via Fortran <
fortran@gcc.gnu.org> wrote:

> Hi All!
>
> Proposed patch to:
>
> PR82376 - Duplicate function call using -fcheck=pointer
>
> Patch tested only on x86_64-pc-linux-gnu.
>
> Evaluate function result and then pass a pointer, instead of a reference
> to the function itself, thus avoiding multiple evaluations of the function.
>
> Thank you very much.
>
> Best regards,
> José Rui
>
> Fortran: Fix double function call with -fcheck=pointer [PR]
>
> gcc/fortran/ChangeLog:
>
> PR fortran/82376
> * trans-expr.c (gfc_conv_procedure_call): Evaluate function result
> and then pass a pointer.
>
> gcc/testsuite/ChangeLog:
>
> PR fortran/82376
> * gfortran.dg/PR82376.f90: New test.
>
>

-- 
"If you can't explain it simply, you don't understand it well enough" -
Albert Einstein
! { dg-do compile }
! { dg-options "-fdump-tree-original -fcheck=pointer" }
!
! Test the fix for PR82376. The pointer check was doubling up the call
! to new. The fix reduces the count of 'new' from 5 to 4.
!
! Contributed by José Rui Faustino de Sousa  
!
program main_p

  integer, parameter :: n = 10

  type :: foo_t
integer, pointer :: v =>null()
  end type foo_t

  integer, save :: pcnt = 0

  type(foo_t) :: int
  integer :: i

  do i = 1, n
call init(int, i)
if(.not.associated(int%v)) stop 1
if(int%v/=i) stop 2
if(pcnt/=i) stop 3
  end do

contains

  function new(data) result(this)
integer, target, intent(in) :: data

integer, pointer :: this

nullify(this)
this => data
pcnt = pcnt + 1
return
  end function new

  subroutine init(this, data)
type(foo_t), intent(out) :: this
integer, intent(in)  :: data

call set(this, new(data))
return
  end subroutine init

  subroutine set(this, that)
type(foo_t), intent(inout) :: this
integer, target, intent(in):: that

this%v => that
return
  end subroutine set

end program main_p
! { dg-final { scan-tree-dump-times "new" 4 "original" } }

Re: [Patch, Fortran, Update] PR98301 Re: RANDOM_INIT() and coarray Fortran

2021-04-25 Thread Steve Kargl via Fortran
On Sat, Apr 24, 2021 at 12:49:45PM +0200, Andre Vehreschild wrote:
> Hi Steve, hi all,
> 
> thank you for pointing that out, Steve. When I started the work, I told
> myself, that I have to remember to add your patch to the submit. Well, that 
> did
> not last for more than eight hours and I had forgotten.
> 
> So here is now the combination of Steve's and my patch (attached).
> 
> Bootstrapped and regtested ok on x86_64/f33.
> 
> @Steve: Is this your correct mail address for the changelog or do you prefer a
> different one?
> 
> Regards,
>   Andre
> 
> Changelog:
> 
> Steve Kargl  
> 
> PR fortran/98301 - random_init() is broken
> 
> Correct implementation of random_init() when -fcoarray=lib is given.
> 
> gcc/fortran/ChangeLog:
> 
>   PR fortran/98301
>   * trans-decl.c (gfc_build_builtin_function_decls): Move decl.
>   * trans-intrinsic.c (conv_intrinsic_random_init): Use bool for
>   lib-call of caf_random_init instead of logical (4-byte).
>   * trans.h: Add tree var for random_init.
> 
> libgfortran/ChangeLog:
> 
>   PR fortran/98301
>   * caf/libcaf.h (_gfortran_caf_random_init): New function.
>   * caf/single.c (_gfortran_caf_random_init): New function.
>   * gfortran.map: Added fndecl.
>   * intrinsics/random_init.f90: Implement random_init.
> 

Andre,

The patch looks fine to me.  I wonder, however, if we should 
comment out all of the shared memory stuff, i.e., the _cas_
stuff.  I don't know when Thomas/Nicolas will merge their 
work-in-progress.

-- 
steve