From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27834 invoked by alias); 27 Jan 2015 20:09:21 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 27681 invoked by uid 48); 27 Jan 2015 20:09:15 -0000 From: "burnus at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/63861] OpenACC coarray ICE (also with OpenMP?) Date: Tue, 27 Jan 2015 20:09:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: fortran X-Bugzilla-Version: 5.0 X-Bugzilla-Keywords: openacc, openmp X-Bugzilla-Severity: normal X-Bugzilla-Who: burnus at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2015-01/txt/msg03145.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63861 --- Comment #4 from Tobias Burnus --- Comment 3 fixed two issues with gcc/testsuite/gfortran.dg/goacc/coarray.f95. Still to do: * gcc/testsuite/gfortran.dg/goacc/coarray_2.f90 contains a FIXME for a "reduction(+:a)" variable. For an allocatable scalar coarray, that will lead to an ICE in an assignment "a = 0". The problem seems to relate to calling alloc_scalar_allocatable_for_assignment from gfc_trans_assignment_1, which shall not be called at all. (The semantics say that for coarrays those shall always be allocated, when used and noreallocation shall be done. Coarray (de)allocations are always colletively done across all images (= processes)). I wonder whether there are similar other issues; the same no-realloc also applies to allocatable array coarrays. * One probably should check for coindexed variables (e.g. "a[i]" or "b(1:8)[5]", where the "[...]" refers to a remote image). For everything handled as pointer or within an offloaded region, that won't work and should be invalid. At places where a temporary is fine, it can be used (cf. dumps with -fcoarray=lib). I have no idea whether there is an issue in either the OpenMP/OpenACC directives or whether it would be testable for target/acc kernels/parallel regions. Probably only for those declaring a procedure ("routine") to be offloadable.