Bug 84088 - [8 Regression][nvptx] libgomp.oacc-fortran/declare-*.f90 execution fails
Summary: [8 Regression][nvptx] libgomp.oacc-fortran/declare-*.f90 execution fails
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 8.0
: P3 normal
Target Milestone: 8.0
Assignee: Paul Thomas
URL:
Keywords: wrong-code
Depends on:
Blocks:
 
Reported: 2018-01-28 23:25 UTC by Tom de Vries
Modified: 2018-02-01 07:31 UTC (History)
3 users (show)

See Also:
Host:
Target: nvptx
Build:
Known to work:
Known to fail:
Last reconfirmed: 2018-01-31 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tom de Vries 2018-01-28 23:25:31 UTC
@r257131, with GOMP_NVPTX_JIT=-O0, driver version 384.111, geforce 710, and cuda 8.0, kernel version 4.13.0-32-generic:
...
FAIL: libgomp.oacc-fortran/declare-1.f90 -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0  -O0  execution test
FAIL: libgomp.oacc-fortran/declare-1.f90 -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0  -O1  execution test
FAIL: libgomp.oacc-fortran/declare-1.f90 -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0  -O2  execution test
FAIL: libgomp.oacc-fortran/declare-1.f90 -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0  -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
FAIL: libgomp.oacc-fortran/declare-1.f90 -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0  -O3 -g  execution test
FAIL: libgomp.oacc-fortran/declare-1.f90 -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0  -Os  execution test
FAIL: libgomp.oacc-fortran/declare-2.f90 -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0  -O0  execution test
FAIL: libgomp.oacc-fortran/declare-2.f90 -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0  -O1  execution test
FAIL: libgomp.oacc-fortran/declare-2.f90 -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0  -O2  execution test
FAIL: libgomp.oacc-fortran/declare-2.f90 -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0  -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
FAIL: libgomp.oacc-fortran/declare-2.f90 -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0  -O3 -g  execution test
FAIL: libgomp.oacc-fortran/declare-2.f90 -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0  -Os  execution test
FAIL: libgomp.oacc-fortran/declare-4.f90 -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0  -O0  execution test
FAIL: libgomp.oacc-fortran/declare-4.f90 -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0  -O1  execution test
FAIL: libgomp.oacc-fortran/declare-4.f90 -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0  -O2  execution test
FAIL: libgomp.oacc-fortran/declare-4.f90 -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0  -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
FAIL: libgomp.oacc-fortran/declare-4.f90 -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0  -O3 -g  execution test
FAIL: libgomp.oacc-fortran/declare-4.f90 -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0  -Os  execution test
FAIL: libgomp.oacc-fortran/declare-5.f90 -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0  -O0  execution test
FAIL: libgomp.oacc-fortran/declare-5.f90 -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0  -O1  execution test
FAIL: libgomp.oacc-fortran/declare-5.f90 -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0  -O2  execution test
FAIL: libgomp.oacc-fortran/declare-5.f90 -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0  -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
FAIL: libgomp.oacc-fortran/declare-5.f90 -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0  -O3 -g  execution test
FAIL: libgomp.oacc-fortran/declare-5.f90 -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0  -Os  execution test
...
Comment 1 Tom de Vries 2018-01-29 07:08:49 UTC
(In reply to Tom de Vries from comment #0)
> @r257131, with GOMP_NVPTX_JIT=-O0, driver version 384.111, geforce 710, and
> cuda 8.0, kernel version 4.13.0-32-generic:

Same result without GOMP_NVPTX_JIT=-O0.

And same result with GOMP_NVPTX_JIT=-O0 on driver version 384.111, quadro m1200, cuda 7.5, kernel version 4.13.0-31-generic.
Comment 2 Tom de Vries 2018-01-29 08:29:24 UTC
Minimal version:
...
! { dg-do run }                                                                                                    

module vars
  implicit none
  integer z
  !$acc declare create (z)                                                                                         
end module vars

program main
  use vars
  use openacc
  implicit none

  if (acc_is_present (z) .neqv. .true.) call abort

end program
...
Comment 3 Tom de Vries 2018-01-29 11:15:19 UTC
Bisect points to commit r257065:
...
commit d9c7c3e3f6eb4621f929474e0ba44e7d61584431 (HEAD)
Author: pault <pault@138bc75d-0d04-0410-961f-82ee72b054a4>
Date:   Thu Jan 25 19:09:40 2018 +0000

    2018-25-01  Paul Thomas  <pault@gcc.gnu.org>
    
            PR fortran/37577
            * array.c (gfc_match_array_ref): If standard earlier than F2008
            it is an error if the reference dimension is greater than 7.
            libgfortran.h : Increase GFC_MAX_DIMENSIONS to 15. Change the
            dtype masks and shifts accordingly.
            * trans-array.c (gfc_conv_descriptor_dtype): Use the dtype
            type node to check the field.
            (gfc_conv_descriptor_dtype): Access the rank field of dtype.
            (duplicate_allocatable_coarray): Access the rank field of the
            dtype descriptor rather than the dtype itself.
            * trans-expr.c (get_scalar_to_descriptor_type): Store the type
            of 'scalar' on entry and use its TREE_TYPE if it is ARRAY_TYPE
            (ie. a character).
            (gfc_conv_procedure_call): Pass TREE_OPERAND (tmp,0) to
            get_scalar_to_descriptor_type if the actual expression is a
            constant.
            (gfc_trans_structure_assign): Assign the rank directly to the
            dtype rank field.
            * trans-intrinsic.c (gfc_conv_intrinsic_rank): Cast the result
            to default integer kind.
            (gfc_conv_intrinsic_sizeof): Obtain the element size from the
            'elem_len' field of the dtype.
            * trans-io.c (gfc_build_io_library_fndecls): Replace
            gfc_int4_type_node with dtype_type_node where necessary.
            (transfer_namelist_element): Use gfc_get_dtype_rank_type for
            scalars.
            * trans-types.c : Provide 'get_dtype_type_node' to acces the
            dtype_type_node and, if necessary, build it.
            The maximum size of an array element is now determined by the
            maximum value of size_t.
            Update the description of the array descriptor, including the
            type def for the dtype_type.
            (gfc_get_dtype_rank_type): Build a constructor for the dtype.
            Distinguish RECORD_TYPEs that are BT_DERIVED or BT_CLASS.
            (gfc_get_array_descriptor_base): Change the type of the dtype
            field to dtype_type_node.
            (gfc_get_array_descr_info): Get the offset to the rank field of
            the dtype.
            * trans-types.h : Add a prototype for 'get_dtype_type_node ()'.
            * trans.h : Define the indices of the dtype fields.
    
    2018-25-01  Paul Thomas  <pault@gcc.gnu.org>
    
            PR fortran/37577
            * gfortran.dg/coarray_18.f90: Allow dimension 15 for F2008.
            * gfortran.dg/coarray_lib_this_image_2.f90: Change 'array1' to
            'array01' in the tree dump comparison.
            * gfortran.dg/coarray_lib_token_4.f90: Likewise.
            * gfortran.dg/inline_sum_1.f90: Similar - allow two digits.
            * gfortran.dg/rank_1.f90: Allow dimension 15 for F2008.
    
    2018-25-01  Paul Thomas  <pault@gcc.gnu.org>
    
            PR fortran/37577
            * caf/single.c (_gfortran_caf_failed_images): Access the 'type'
            and 'elem_len' fields of the dtype instead of the shifts.
            (_gfortran_caf_stopped_images): Likewise.
            * intrinsics/associated.c (associated): Compare the 'type' and
            'elem_len' fields instead of the dtype.
            * caf/date_and_time.c : Access the dtype fields rather using
            shifts and masks.
            * io/transfer.c (transfer_array ): Comment on item count.
            (set_nml_var,st_set_nml_var): Change dtype type and use fields.
            (st_set_nml_dtio_var): Likewise.
            * libgfortran.h : Change definition of GFC_ARRAY_DESCRIPTOR and
            add a typedef for the dtype_type. Change the GFC_DTYPE_* macros
            to access the dtype fields.
    
    
    
    git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@257065 138bc75d-0d04-0410-961f-82ee72b054a4
...

Will reconfirm with full build.
Comment 4 Tom de Vries 2018-01-29 11:43:22 UTC
(In reply to Tom de Vries from comment #3)
> Will reconfirm with full build.

Did clean builds of r257064 and r257065. Minimal test passes at r257064, fails at r257065. Confirmed.
Comment 5 Tom de Vries 2018-01-29 15:25:23 UTC
Hmm. Probably this failure would have been picked up by libgomp-plugin-host_nonshm.
Comment 6 Paul Thomas 2018-01-29 18:20:55 UTC
(In reply to Tom de Vries from comment #5)
> Hmm. Probably this failure would have been picked up by
> libgomp-plugin-host_nonshm.

Hi Tom,

Although my patch caused it, I am not in a position to pick this one up - I am unable to reproduce it and do not have access to the target you are using. In addition, libgomp and all its workings are, as far as I am concerned, one of the arcane mysteries of gcc.

I am perfectly happy to put in some time to help but I do not even know where to start.

Sorry

Paul
Comment 7 Tom de Vries 2018-01-30 10:33:23 UTC
(In reply to Paul Thomas from comment #6)
> (In reply to Tom de Vries from comment #5)
> > Hmm. Probably this failure would have been picked up by
> > libgomp-plugin-host_nonshm.
> 
> Hi Tom,
> 
> Although my patch caused it, I am not in a position to pick this one up - I
> am unable to reproduce it and do not have access to the target you are
> using. In addition, libgomp and all its workings are, as far as I am
> concerned, one of the arcane mysteries of gcc.
> 
> I am perfectly happy to put in some time to help but I do not even know
> where to start.

I may have found a way to reproduce the problem without libgomp (disclaimer: I have no idea whether this testcase if valid fortran or not).

Consider this testcase:
...
  implicit none
  integer(kind=4) z

  call foo (z)

contains
  subroutine foo (a)
    type (*), dimension (..), contiguous :: a
    print *, sizeof(a)
  end subroutine foo

end program
...

compiled like this:
...
$ gfortran -O2 test.f90
...

gives:
...
$ ./a.out 
                    8
...

Previously, the testcase printed 4 instead of 8.
Comment 8 Tom de Vries 2018-01-30 10:59:52 UTC
> > am unable to reproduce it and do not have access to the target you are
> > using.

> I may have found a way to reproduce the problem without libgomp

Forgot to mention: on x86_64, so you should be able to reproduce this.
Comment 9 paul.richard.thomas@gmail.com 2018-01-30 18:42:49 UTC
Ha! Thanks...

In the main programme:
    struct array00_integer(kind=4) desc.3;

    desc.3.dtype = {.elem_len=8, .rank=0, .type=11};
    desc.3.data = (void * restrict) &z;
    foo (&desc.3);

At least foo is reporting the correct result. I'm onto it.

Paul


On 30 January 2018 at 10:59, vries at gcc dot gnu.org
<gcc-bugzilla@gcc.gnu.org> wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84088
>
> --- Comment #8 from Tom de Vries <vries at gcc dot gnu.org> ---
>> > am unable to reproduce it and do not have access to the target you are
>> > using.
>
>> I may have found a way to reproduce the problem without libgomp
>
> Forgot to mention: on x86_64, so you should be able to reproduce this.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
Comment 10 Paul Thomas 2018-01-31 09:51:33 UTC
I'll take this and deal with it this evening.

The problem lies in trans-expr.c(gfc_conv_scalar_to_descriptor), which was touched in the patch as was the code around the call to it from gfc_conv_procedure_call.

You will note that not only is elem_len = 8 in comment #9 but the type is 11, which is also wrong.

Thanks for the testcase with which I can reproduce the problem.

Paul
Comment 11 Paul Thomas 2018-01-31 20:29:07 UTC
Author: pault
Date: Wed Jan 31 20:28:35 2018
New Revision: 257262

URL: https://gcc.gnu.org/viewcvs?rev=257262&root=gcc&view=rev
Log:
2018-01-31  Paul Thomas  <pault@gcc.gnu.org>

	PR fortran/84088
	* trans-expr.c (gfc_conv_procedure_call): If the parm expr is
	an address expression passed to an assumed rank dummy, convert
	to an indirect reference.

2018-01-31  Paul Thomas  <pault@gcc.gnu.org>

	PR fortran/84088
	* gfortran.dg/pr84088.f90 : New test.


Added:
    trunk/gcc/testsuite/gfortran.dg/pr84088.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/trans-expr.c
    trunk/gcc/testsuite/ChangeLog
Comment 12 Tom de Vries 2018-02-01 07:31:37 UTC
Patch committed with non-openacc test-case from comment 7.

Marking resolved-fixed.