[Bug middle-end/90859] [OMP] Mappings for VLA different depending on 'target { c && { ! lp64 } }'

2019-06-20 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90859

Thomas Schwinge  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-06-20
 Ever confirmed|0   |1

--- Comment #2 from Thomas Schwinge  ---
Experimenting on x86_64-pc-linux-gnu with '-m32', this depends on the data type
used for 'array_so'.  If I change 'uint32_t' to 'unsigned int', I see the same
strange behavior.  If however I change it to 'unsigned long', the issue goes
away, as it does for 'unsigned short', for example.  The code inside the region
is the same (aside from some type casting); in particular there aren't any
'array' references.


Per 'gcc-testresults' received so far, the issue does not appear (thus, 'FAIL'
for this 'scan-tree-dump') on powerpc-ibm-aix7.2.0.0, aarch64-suse-linux-gnu
with '-mabi=ilp32' (manually confirmed), s390x-ibm-linux-gnu with '-m31',
i686-apple-darwin9, powerpc-apple-darwin9, x86_64-apple-darwin16,
x86_64-apple-darwin17.

[Bug fortran/90743] Fortran 'allocatable' in OpenACC/OpenMP target offloading regions

2019-06-18 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90743

Thomas Schwinge  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #6 from Thomas Schwinge  ---
(In reply to Dominique d'Humieres from comment #4)
> Is this PR valid or not?

Yes.  More test cases are needed, and code changes, too, to support other
clauses.

[Bug fortran/85221] [openacc] ICE in install_var_field, at omp-low.c:657

2019-06-18 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85221

--- Comment #2 from Thomas Schwinge  ---
Author: tschwinge
Date: Tue Jun 18 22:15:43 2019
New Revision: 272453

URL: https://gcc.gnu.org/viewcvs?rev=272453=gcc=rev
Log:
[PR85221] Set 'omp declare target', 'omp declare target link' attributes for
Fortran OpenACC 'declare'd variables

gcc/fortran/
PR fortran/85221
* trans-decl.c (add_attributes_to_decl): Handle OpenACC 'declare'
directive.
gcc/testsuite/
PR fortran/85221
* gfortran.dg/goacc/declare-3.f95: New file.

Added:
trunk/gcc/testsuite/gfortran.dg/goacc/declare-3.f95
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-decl.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/90921] Fortran OpenACC 'declare' directive's module handling causes duplicate data clauses

2019-06-18 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90921

--- Comment #1 from Thomas Schwinge  ---
Author: tschwinge
Date: Tue Jun 18 22:15:53 2019
New Revision: 272454

URL: https://gcc.gnu.org/viewcvs?rev=272454=gcc=rev
Log:
[PR90921] Fortran OpenACC 'declare' directive's module handling causes
duplicate data clauses

gcc/fortran/
PR fortran/90921
* trans-decl.c (finish_oacc_declare): Reset module_oacc_clauses
before scanning each namespace.
gcc/testsuite/
PR fortran/90921
* gfortran.dg/goacc/declare-3.f95: Update.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-decl.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/goacc/declare-3.f95

[Bug middle-end/90859] [OMP] Mappings for VLA different depending on 'target { c && { ! lp64 } }'

2019-06-18 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90859

--- Comment #1 from Thomas Schwinge  ---
Author: tschwinge
Date: Tue Jun 18 22:15:16 2019
New Revision: 272452

URL: https://gcc.gnu.org/viewcvs?rev=272452=gcc=rev
Log:
[PR90859] Document status quo for "[OMP] Mappings for VLA different depending
on 'target { c && { ! lp64 } }'"

gcc/testsuite/
PR middle-end/90859
* c-c++-common/goacc/firstprivate-mappings-1.c: Update.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/goacc/firstprivate-mappings-1.c

[Bug fortran/90743] Fortran 'allocatable' in OpenACC/OpenMP target offloading regions

2019-06-18 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90743

--- Comment #5 from Thomas Schwinge  ---
Author: tschwinge
Date: Tue Jun 18 22:14:24 2019
New Revision: 272447

URL: https://gcc.gnu.org/viewcvs?rev=272447=gcc=rev
Log:
[PR90743] Fortran 'allocatable' with OpenACC data/OpenMP 'target' 'map' clauses

Test what OpenMP 5.0 has to say on this topic.  And, do the same for OpenACC.

libgomp/
PR fortran/90743
* oacc-parallel.c (GOACC_parallel_keyed): Handle NULL mapping
case.
* testsuite/libgomp.fortran/target-allocatable-1-1.f90: New file.
* testsuite/libgomp.fortran/target-allocatable-1-2.f90: Likewise.
* testsuite/libgomp.oacc-fortran/allocatable-1-1.f90: Likewise.
* testsuite/libgomp.oacc-fortran/allocatable-1-2.f90: Likewise.

Added:
trunk/libgomp/testsuite/libgomp.fortran/target-allocatable-1-1.f90
trunk/libgomp/testsuite/libgomp.fortran/target-allocatable-1-2.f90
trunk/libgomp/testsuite/libgomp.oacc-fortran/allocatable-1-1.f90
trunk/libgomp/testsuite/libgomp.oacc-fortran/allocatable-1-2.f90
Modified:
trunk/libgomp/ChangeLog
trunk/libgomp/oacc-parallel.c

[Bug middle-end/90861] OpenACC 'declare' not cleaning up for VLAs

2019-06-18 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90861

--- Comment #1 from Thomas Schwinge  ---
Author: tschwinge
Date: Tue Jun 18 22:14:14 2019
New Revision: 272446

URL: https://gcc.gnu.org/viewcvs?rev=272446=gcc=rev
Log:
[PR90861] Document status quo for OpenACC 'declare' not cleaning up for VLAs

gcc/testsuite/
PR testsuite/90861
* c-c++-common/goacc/declare-pr90861.c: New file.
libgomp/
PR testsuite/90861
* testsuite/libgomp.oacc-c-c++-common/declare-vla.c: Update.

Added:
trunk/gcc/testsuite/c-c++-common/goacc/declare-pr90861.c
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/libgomp/ChangeLog
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/declare-vla.c

[Bug middle-end/90868] Duplicate OpenACC 'declare' directives for `extern` variables

2019-06-18 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90868

--- Comment #1 from Thomas Schwinge  ---
Author: tschwinge
Date: Tue Jun 18 22:14:04 2019
New Revision: 272445

URL: https://gcc.gnu.org/viewcvs?rev=272445=gcc=rev
Log:
[PR90868] Document status quo for duplicate OpenACC 'declare' directives for
'extern' variables

gcc/testsuite/
PR testsuite/90868
* c-c++-common/goacc/declare-1.c: Update.
* c-c++-common/goacc/declare-2.c: Likewise.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/goacc/declare-1.c
trunk/gcc/testsuite/c-c++-common/goacc/declare-2.c

[Bug middle-end/90862] OpenACC 'declare' ICE when nested inside another construct

2019-06-18 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90862

--- Comment #1 from Thomas Schwinge  ---
Author: tschwinge
Date: Tue Jun 18 22:13:54 2019
New Revision: 272444

URL: https://gcc.gnu.org/viewcvs?rev=272444=gcc=rev
Log:
[PR90862] OpenACC 'declare' ICE when nested inside another construct

gcc/
PR middle-end/90862
* omp-low.c (check_omp_nesting_restrictions): Handle
GF_OMP_TARGET_KIND_OACC_DECLARE.
gcc/testsuite/
PR middle-end/90862
* c-c++-common/goacc/declare-1.c: Update.
* c-c++-common/goacc/declare-2.c: Likewise.
libgomp/
PR middle-end/90862
* testsuite/libgomp.oacc-c-c++-common/declare-1.c: Update.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/omp-low.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/goacc/declare-1.c
trunk/gcc/testsuite/c-c++-common/goacc/declare-2.c
trunk/libgomp/ChangeLog
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/declare-1.c

[Bug middle-end/90862] OpenACC 'declare' ICE when nested inside another construct

2019-06-18 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90862

Thomas Schwinge  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-06-18
   Assignee|unassigned at gcc dot gnu.org  |tschwinge at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug fortran/90921] New: Fortran OpenACC 'declare' directive's module handling causes duplicate data clauses

2019-06-18 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90921

Bug ID: 90921
   Summary: Fortran OpenACC 'declare' directive's module handling
causes duplicate data clauses
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: openacc
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: jules at gcc dot gnu.org
  Target Milestone: ---

As reported in
<http://mid.mail-archive.com/20181004140413.2147eca1@squid.athome>.

[Bug fortran/85221] [openacc] ICE in install_var_field, at omp-low.c:657

2019-06-18 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85221

Thomas Schwinge  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-06-18
  Component|middle-end  |fortran
   Assignee|unassigned at gcc dot gnu.org  |tschwinge at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug middle-end/90868] Duplicate OpenACC 'declare' directives for `extern` variables

2019-06-13 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90868

Thomas Schwinge  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2019-06-13
   Assignee|unassigned at gcc dot gnu.org  |tschwinge at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug middle-end/90868] New: Duplicate OpenACC 'declare' directives for `extern` variables

2019-06-13 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90868

Bug ID: 90868
   Summary: Duplicate OpenACC 'declare' directives for `extern`
variables
   Product: gcc
   Version: 10.0
   URL: https://github.com/OpenACC/openacc-spec/issues/194
Status: UNCONFIRMED
  Keywords: openacc
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
  Target Milestone: ---

Working on getting clarified what the intended behavior should be.

[Bug middle-end/90862] New: OpenACC 'declare' ICE when nested inside another construct

2019-06-12 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90862

Bug ID: 90862
   Summary: OpenACC 'declare' ICE when nested inside another
construct
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: openacc
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
  Target Milestone: ---

For example:

#pragma acc data
{
#pragma acc declare [...]
}

[...]: internal compiler error: in check_omp_nesting_restrictions, at
omp-low.c:3121

The fix is the obvious one.

[Bug middle-end/90861] New: OpenACC 'declare' not cleaning up for VLAs

2019-06-12 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90861

Bug ID: 90861
   Summary: OpenACC 'declare' not cleaning up for VLAs
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: openacc
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
  Target Milestone: ---

Given:

#define N_f1 1000
int A_f1[N_f1];
#pragma acc declare copy(A_f1)

..., in '-fdump-tree-gimple' we get the expected:

  try
{
  #pragma omp target oacc_declare map(to:A_f1 [len: 4000])
}
  finally
{
  #pragma omp target oacc_declare map(from:A_f1)
  A_f1 = {CLOBBER};
}

However, given:

int N_f2 = 1000;
int A_f2[N_f2];
#pragma acc declare copy(A_f2)

..., the cleanup ('from') is missing, so device memory gets allocated
corresponding to local variable 'A_f2', but isn't deallocated and deassociated
from the stack address of 'A_f2' when that one goes out of scope.  As stack
space will be re-used in different functions called consecutively, libgomp will
then abort because of 'libgomp: Trying to map into device
[0x7ffd86278870..0x7ffd86279810) object when [0x7ffd86278880..0x7ffd86279820)
is already mapped', if running two such VLA functions consecutively, for
example.  This can be easily seen with the
'libgomp.oacc-c-c++-common/declare-vla.c' test case, when duplicating its
'main' function into two functions, which are then called consecutively.

'libgomp.oacc-c-c++-common/declare-vla.c' has been added in r246381 for
PR80029; I don't know what the behavior would've been before that.

In <http://mid.mail-archive.com/874ly0h7dc.fsf@euler.schwinge.homeip.net> there
are unanswered questions, but I'm not sure if they're relevant to this problem
here.

[Bug middle-end/90859] New: [OMP] Mappings for VLA different depending on 'target { c && { ! lp64 } }'

2019-06-12 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90859

Bug ID: 90859
   Summary: [OMP] Mappings for VLA different depending on 'target
{ c && { ! lp64 } }'
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: openacc
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

I noticed the following (with OpenACC, not yet tried to reproduce with OpenMP
'target').  Is there something wrong, or can that behavior be explained?

Only 'sizeof array' appears in the offloaded region, yet for 'target { c && { !
lp64 } }' (only!), the gimplifier also creates a mapping for the array itself.

static void
vla (int array_li)
{
  _Complex double array[array_li];
  uint32_t array_so;
#pragma acc parallel \
  copyout (array_so) \
  /* The gimplifier has created an implicit 'firstprivate' clause for the
array
 length.
 { dg-final { scan-tree-dump {(?n)#pragma omp target oacc_parallel
map\(from:array_so \[len: 4\]\) firstprivate\(} omplower } } */ \
  /* For C, non-LP64, the gimplifier has also created a mapping for the
array
 itself.
 { dg-final { scan-tree-dump {(?n)#pragma omp target oacc_parallel
map\(from:array_so \[len: 4\]\) firstprivate\(array_li.[0-9]+\)
map\(tofrom:\(\*array.[0-9]+\) \[len: D\.[0-9]+\]\) map\(firstprivate:array
\[pointer assign, bias: 0\]\) \[} omplower { target { c && { ! lp64 } } } } }
*/ \
  {
array_so = sizeof array;
  }
  if (array_so != sizeof array)
__builtin_abort ();
}

[Bug middle-end/90779] Fortran array initialization in offload regions

2019-06-07 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90779

Thomas Schwinge  changed:

   What|Removed |Added

   Keywords||openacc
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-06-07
 CC||jakub at gcc dot gnu.org,
   ||tschwinge at gcc dot gnu.org
Summary|Fortran array   |Fortran array
   |initialization in OpenMP|initialization in offload
   |offload regions |regions
 Ever confirmed|0   |1

--- Comment #1 from Thomas Schwinge  ---
Same for OpenACC ('!$acc parallel copyout(v)').


Thsi sounds similar to PR85063,
<http://mid.mail-archive.com/9e02d449-0c4a-88a8-0aac-1d353d321b74@mentor.com>
"[PATCH, PR85063] Fix switch conversion in offloading functions".

[Bug other/76739] Add support dynamically allocated multi-dimensional arrays in OpenACC data clauses

2019-06-06 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=76739

Thomas Schwinge  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW
 CC||tschwinge at gcc dot gnu.org
   Assignee|chunglin.tang at gmail dot com |unassigned at gcc dot 
gnu.org

--- Comment #1 from Thomas Schwinge  ---
Nobody is actively working on that right now.


Initial pieces got into the OpenACC development branch (gomp-4_0-branch at that
time, r244259),
<http://mid.mail-archive.com/9bd92682-c1d3-5530-4f76-fdc68318d8e9@mentor.com>. 
That got forward-ported to later development branches.

As far as I know, that work is not yet ready for trunk inclusion.

[Bug fortran/90742] OpenACC/OpenMP target offloading: Fortran 'allocatable' scalars in 'firstprivate' clauses

2019-06-06 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90742

Thomas Schwinge  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2019-06-06
 Ever confirmed|0   |1

--- Comment #1 from Thomas Schwinge  ---
Jakub, is my understanding correct, that when a Fortran 'allocatable' is used
in a 'firstprivate' clause on an OpenMP 'target' construct, then that should do
"the obvious" thing?  (But it currently isn't.)  That is, behave similar as a
Fortran 'allocatable' used in a 'map' clause.  (Which does work as expected.)

I do note that OpenMP 5.0 doesn't seem to contain any words on this
specifically (in contrast to 'allocatable' with a 'map' clause; see 2.19.7.1
"'map' Clause", near the end), but I suppose (!) that's just because a
'firstprivate' clause need not be concerned about the case of "exit from the
region".  (Relate to how 2.19.4.5 "'lastprivate' Clause" in turn *does* talk
about 'allocatable' in context of "exit from [...]".)

(..., and then similarly also for a 'private' clause, as much as applicable,
which I have not yet checked.)

Cesar's patch "[OpenACC] Add support for firstprivate Fortran allocatable
scalars" (see link above) would fix at least some aspects of this (for OpenACC
only).

Also, so far, I only consider scalars.

[Bug fortran/90743] Fortran 'allocatable' in OpenACC/OpenMP target offloading regions

2019-06-05 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90743

Thomas Schwinge  changed:

   What|Removed |Added

Summary|Device-side 'malloc' for|Fortran 'allocatable' in
   |Fortran 'allocatable'   |OpenACC/OpenMP target
   |scalar  |offloading regions

--- Comment #2 from Thomas Schwinge  ---
Thanks for your comment; I wasn't aware of the (default) '-frealloc-lhs'
behavior (PR90741), and indeed that's supported inside offloading regions, too.

(In reply to Jakub Jelinek from comment #1)
> The code in the region could deallocate (c) or
> do similar stuff, and while that might be undefined with some offloading
> specs under some conditions, there are many cases where it must be valid.

Indeed that's not permitted per my reading of OpenMP 5.0 -- but it does seem to
work in the GCC implementation, inside an offloading region to 'deallocate' and
then re-'allocate', which seems to make the device object "detached" from the
host object.  Is that something we should thus be testing (with a comment:
"implementation-defined behavior"), or should we not test such things?

[Bug fortran/90743] New: Device-side 'malloc' for Fortran 'allocatable' scalar

2019-06-04 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90743

Bug ID: 90743
   Summary: Device-side 'malloc' for Fortran 'allocatable' scalar
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: openacc, openmp
  Severity: enhancement
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

As '-fdump-tree-original' shows, for:

program main
  implicit none
  integer, allocatable :: c

  allocate (c)

  c = 25

  !$omp target map(from: c)
  !$acc parallel copyout(c)
  c = 52
  !$acc end parallel
  !$omp end target

  if (c /= 52) stop 2

  deallocate (c)
end program main

... we currently generate code as follows:

[...]
  *c = 25;
  #pragma omp target map(from:*c) map(alloc:c [pointer assign, bias: 0])
{
  {
{
  if (c != 0B) goto L.3;
  c = (integer(kind=4) *) __builtin_malloc (4);
  L.3:;
  *c = 52;
}
  }
}
[...]

Same for OpenACC.

At least in the case of nvptx offloading that I just tried, we're not actually
executing that 'malloc' on the device.  Will this always be the case?  Could
code generation then be changed to turn this into an 'abort', to make this less
surprising for the human reader?

---

I just saw Jakub's Comment 1 in PR90741, so I suppose the 'c = 52' assignment
is where this device-side 'malloc' is coming from.

[Bug fortran/90742] New: OpenACC/OpenMP target offloading: Fortran 'allocatable' scalars in 'firstprivate' clauses

2019-06-04 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90742

Bug ID: 90742
   Summary: OpenACC/OpenMP target offloading: Fortran
'allocatable' scalars in 'firstprivate' clauses
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: openacc, openmp
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: jakub at gcc dot gnu.org, jules at gcc dot gnu.org
  Target Milestone: ---

Created attachment 46449
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46449=edit
libgomp.oacc-fortran/allocatable-scalar-1.f90

For OpenACC/OpenMP target offloading, Fortran 'allocatable' scalars in
'firstprivate' clauses don't work, with nvptx offloading: "libgomp:
cuStreamSynchronize error: unspecified launch failure (perhaps abort was
called)"; see the first half of the attached test case.  Should they not work
in the same way as they do for regular data clauses; see the second half of the
attached test case?


Submitted originally as part of
<http://mid.mail-archive.com/486f1f87-16b3-46b5-17f5-6857756d4115@codesourcery.com>
"[gomp4] add support for allocatable scalars in OpenACC declare constructs"
(which in turn depends on
<http://mid.mail-archive.com/86f51209-c59d-a4cf-297d-9a072823aa61@codesourcery.com>
"[gomp4] add support for fortran allocate support with declare create", and the
patches to enable 'GOMP_MAP_FIRSTPRIVATE_INT' for OpenACC 'firstprivate'), and
recently re-submitted as part of
<http://mid.mail-archive.com/20180920195908.04486d45@squid.athome> '[PATCH,
OpenACC] Fortran "declare create"/allocate support for OpenACC', Cesar also
once singled out the changes to make this work (but for OpenACC only):
<http://mid.mail-archive.com/1f88e441-d3da-5b59-4278-058ff1368a73@codesourcery.com>
"[PATCH][OpenACC] Add support for firstprivate Fortran allocatable scalars".

The latter patch still applies, and makes the OpenACC (but not OpenMP) case
work by means of the following '-fdump-tree-omplower' changes:

[...]
-.omp_data_arr.28.a = 
+a.32 = a;
+.omp_data_arr.28.a = a.32;
 .omp_data_arr.28.b = 
 #pragma omp target oacc_parallel firstprivate(a) map(from:b [len:
4]) [child fn: MAIN__._omp_fn.0 (.omp_data_arr.28, .omp_data_sizes.29,
.omp_data_kinds.30)]
   {
 .omp_data_i = (const struct .omp_data_t.25 & restrict)
&.omp_data_arr.28;
 D.3974 = .omp_data_i->a;
 a.27 = *D.3974;
-a = a.27;
+a.28 = a.27;
+a = 
 a.5 = a;
 b.6 = *a.5;
[...]

I'm currently working on figuring out if that's correct (OpenACC/OpenMP
standards, and then the GCC implementation), but will appreciate any insights.  

(The old code version cited above shows what likely causes the 'SIGSEGV' on the
device: dereferencing a host pointer.)


Also need to look up how that relates to the changes done for PR77371
(<http://mid.mail-archive.com/21a94405-6cb7-e474-1e14-727de6939eaf@mentor.com>),
and PR85879
(<http://mid.mail-archive.com/34d2a115-c01c-26c1-57d9-4989a0a00095@mentor.com>),
where the latter's commit r261025 subsumed the former's changes.

[Bug fortran/90741] New: Unreachable second '__builtin_malloc' for scalar 'allocatable'

2019-06-04 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90741

Bug ID: 90741
   Summary: Unreachable second '__builtin_malloc' for scalar
'allocatable'
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
  Target Milestone: ---

Based on trunk r271854, I noticed that for the following simple Fortran code:

program main
  implicit none
  integer, allocatable :: a

  allocate (a)

  a = 50

  deallocate (a)
end program main

... the following appears in the '-fdump-tree-original' dump:

[...]
  a = (integer(kind=4) *) __builtin_malloc (4);
  if (a == 0B)
{ 
  _gfortran_os_error (&"Allocation would exceed memory
limit"[1]{lb: 1 sz: 1});
}
}
  if (a != 0B) goto L.1;
  a = (integer(kind=4) *) __builtin_malloc (4);
  L.1:;
  *a = 50;
  if (a == 0B)
{ 
  _gfortran_runtime_error_at (&"At line 9 of file [...]"[1]{lb: 1 sz:
1}, &"Attempt to DEALLOCATE unallocated \'%s\'"[1]{lb: 1 sz: 1}, &"a"[1]{lb: 1
sz: 1});
}
  else
{ 
  __builtin_free ((void *) a);
}
  a = 0B;
}

I have not looked up where/why that second '__builtin_malloc' is emitted.  At
least in this simple case, it's unreachable, so it's not a memory leak.

[Bug libgomp/90596] New: 'GOACC_parallel_keyed' should use 'GOMP_MAP_VARS_TARGET'

2019-05-23 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90596

Bug ID: 90596
   Summary: 'GOACC_parallel_keyed' should use
'GOMP_MAP_VARS_TARGET'
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: openacc
  Severity: enhancement
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

'GOACC_parallel_keyed' currently calls 'gomp_map_vars' with
'GOMP_MAP_VARS_OPENACC' instead of 'GOMP_MAP_VARS_TARGET', and does its own
'devaddrs' management, split between there and the device plugin.  When
switching to 'GOMP_MAP_VARS_TARGET', it would benefit from 'gomp_coalesce_buf'
handling, and thus avoid each one device memory allocation, copy from host to
device, device memory deallocation call per kernel launch.

[Bug libgomp/90593] OpenACC 'acc_async_sync' need not imply synchronizing after every intermediate step but rather just once, at the end

2019-05-23 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90593

Thomas Schwinge  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-05-23
 Ever confirmed|0   |1

--- Comment #1 from Thomas Schwinge  ---
I wonder how this would relate to r237070 "[OpenACC] Make reduction arguments
addressable", where we currently in the front ends explicitly look for 'async'
clauses being present.

[Bug libgomp/90593] New: OpenACC 'acc_async_sync' need not imply synchronizing after every intermediate step but rather just once, at the end

2019-05-23 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90593

Bug ID: 90593
   Summary: OpenACC 'acc_async_sync' need not imply synchronizing
after every intermediate step but rather just once, at
the end
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: openacc
  Severity: enhancement
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: cltang at gcc dot gnu.org, jakub at gcc dot gnu.org
  Target Milestone: ---
Target: nvptx

Before r271128 "OpenACC 'async' re-work", we had the following TODO comment in
'libgomp/plugin/plugin-nvptx.c', 'select_stream_for_async':

/* NOTE: AFAICT there's no particular need for acc_async_sync to map to the
   null stream, and in fact better performance may be obtainable if it
doesn't
   (because the null stream enforces overly-strict synchronisation with
   respect to other streams for legacy reasons, and that's probably not
   needed with OpenACC).  Maybe investigate later.  */
if (async == acc_async_sync)
  stream = ptx_dev->null_stream;

That code and comment is now gone, but the issue not resolved.  Nowadays,
instead of mapping 'acc_async_sync' to the 'NULL' 'aq', 'acc_async_sync' would
get its own, separate 'aq', and, as far as possible/feasible, we'd use that one
to launch all intermediate steps, and then synchronize just once, at the end.

Basically, that means to turn:

#pragma acc parallel [data clauses] // default 'async(acc_async_sync)'
{ [...] }

... into something like:

#pragma acc parallel [data clauses] async([internal])
{ [...] }
#pragma acc wait([internal])

..., so inside 'GOACC_parallel_*', asynchronously launch (on one specific 'aq')
all the data transfers needed per the data clauses, and then the GPU kernel
launch itself, and only then synchronize.

This should allow for hiding latencies that occur when initiating multiple GPU
memory transfers.

[Bug tree-optimization/90591] New: Avoid unnecessary data transfer out of OMP construct

2019-05-23 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90591

Bug ID: 90591
   Summary: Avoid unnecessary data transfer out of OMP construct
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: openacc, openmp
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

The reverse side of PR90573.  For (all too common!) code like:

int i;
#pragma acc kernels // implicit 'copy(i)', or 'copyout(i)' with PR90573
  {
for (i = 0; i < N; ++i)
  [...]
  }
#pragma acc kernels // implicit 'copy(i)', or 'copyout(i)' with PR90573
  {
for (i = N - 1; i >= 0; --i)
  [...]
  }
['i' never read here]

In addition that we can avoid unnecessary data transfer into each OMP construct
(PR90573), we also don't need to copy 'i' out in such scenarios, so can
optimize 'copy' to 'copyin', or 'copyout' to 'create'.

[Bug tree-optimization/90510] [10 Regression] Unnecessary permutation

2019-05-23 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90510

--- Comment #6 from Thomas Schwinge  ---
Author: tschwinge
Date: Thu May 23 08:22:56 2019
New Revision: 271540

URL: https://gcc.gnu.org/viewcvs?rev=271540=gcc=rev
Log:
[PR90510] Adjust 'brig.dg/test/gimple/packed.hsail'

... for r271463 "Fix PR90510, VEC_PERM -> BIT_INSERT folding".

gcc/testsuite/
PR middle-end/90510
* brig.dg/test/gimple/packed.hsail: Adjust.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/brig.dg/test/gimple/packed.hsail

[Bug tree-optimization/90573] Avoid unnecessary data transfer into OMP construct

2019-05-22 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90573

--- Comment #1 from Thomas Schwinge  ---
Probably some of these transformation should come with compiler diagnostics,
especially for explicit clauses.

For example, need to relate this to 'OMP_CLAUSE_FIRSTPRIVATE_IMPLICIT': PR70550
(r234779, r234824, r234826).

PR72781?

Or "the other way round", PR69876?

[Bug tree-optimization/90573] New: Avoid unnecessary data transfer into OMP construct

2019-05-22 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90573

Bug ID: 90573
   Summary: Avoid unnecessary data transfer into OMP construct
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: openacc, openmp
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

As mentioned in PR90067: "it might generally be beneficial to have a pass
promoting 'firstprivate(x)' with a dominating write operation on 'x' to
'private(x)'".  This will avoid unnecessary data transfer for (all too common!)
code like:

int i;
#pragma acc parallel loop // implicit 'firstprivate(i)'
for (i = 0; i < N; ++i)
  [...]

Similarly, there are cases where 'copy(x)' can be optimized to 'copyout(x)', or
'copyin(x)' to 'create(x)'.

This need not apply to implicit clauses only, but also to explicit ones, when
the user can't observe any difference.

The same applies to certain OpenMP clauses too, I suppose.

[Bug middle-end/90114] Predetermined private levels for variables declared in OpenACC accelerator routines

2019-05-21 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90114

Thomas Schwinge  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #3 from Thomas Schwinge  ---
(In reply to Dominique d'Humieres from comment #2)
> Is it fixed?

No, I just committed a few test cases to document the status quo.

[Bug fortran/90067] Loop variables in Fortran 'do' statements within a compute construct must be predetermined private

2019-05-21 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90067

Thomas Schwinge  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #3 from Thomas Schwinge  ---
(In reply to Dominique d'Humieres from comment #2)
> Is it fixed?

No, I just committed a few test cases to document the status quo.

[Bug c/89433] Repeated use of the OpenACC 'routine' directive

2019-05-17 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89433

--- Comment #4 from Thomas Schwinge  ---
Author: tschwinge
Date: Fri May 17 19:13:15 2019
New Revision: 271344

URL: https://gcc.gnu.org/viewcvs?rev=271344=gcc=rev
Log:
[PR89433] Use 'oacc_verify_routine_clauses' for C/C++ OpenACC 'routine'
directives

gcc/
PR middle-end/89433
* omp-general.c (oacc_build_routine_dims): Move some of its
processing into...
(oacc_verify_routine_clauses): ... this new function.
* omp-general.h (oacc_verify_routine_clauses): New prototype.
gcc/c/
PR c/89433
* c-parser.c (c_parser_oacc_routine): Normalize order of clauses.
(c_finish_oacc_routine): Call oacc_verify_routine_clauses.
gcc/cp/
PR c++/89433
* parser.c (cp_parser_oacc_routine)
(cp_parser_late_parsing_oacc_routine): Normalize order of clauses.
(cp_finalize_oacc_routine): Call oacc_verify_routine_clauses.
gcc/testsuite/
PR testsuite/89433
* c-c++-common/goacc/routine-2.c: Update, and move some test
into...
* c-c++-common/goacc/routine-level-of-parallelism-1.c: ... this
new file.

Added:
trunk/gcc/testsuite/c-c++-common/goacc/routine-level-of-parallelism-1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-parser.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/omp-general.c
trunk/gcc/omp-general.h
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/goacc/routine-2.c

[Bug c/89433] Repeated use of the OpenACC 'routine' directive

2019-05-17 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89433

--- Comment #5 from Thomas Schwinge  ---
Author: tschwinge
Date: Fri May 17 19:13:26 2019
New Revision: 271345

URL: https://gcc.gnu.org/viewcvs?rev=271345=gcc=rev
Log:
[PR89433] Repeated use of the C/C++ OpenACC 'routine' directive

gcc/
PR middle-end/89433
* omp-general.c (oacc_verify_routine_clauses): Change formal
parameters.  Add checking if already marked with an OpenACC
'routine' directive.  Adjust all users.
gcc/c/
PR c/89433
* c-parser.c (c_finish_oacc_routine): Rework checking if already
marked with an OpenACC 'routine' directive.
gcc/cp/
PR c++/89433
* parser.c (cp_finalize_oacc_routine): Rework checking if already
marked with an OpenACC 'routine' directive.
gcc/testsuite/
PR testsuite/89433
* c-c++-common/goacc/routine-5.c: Update.
* c-c++-common/goacc/routine-level-of-parallelism-1.c: Likewise.
* c-c++-common/goacc/routine-level-of-parallelism-2.c: New file.

Added:
trunk/gcc/testsuite/c-c++-common/goacc/routine-level-of-parallelism-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-parser.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/omp-general.c
trunk/gcc/omp-general.h
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/goacc/routine-5.c
trunk/gcc/testsuite/c-c++-common/goacc/routine-level-of-parallelism-1.c
trunk/gcc/testsuite/gfortran.dg/goacc/routine-level-of-parallelism-1.f90

[Bug c/89433] Repeated use of the OpenACC 'routine' directive

2019-05-17 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89433

--- Comment #3 from Thomas Schwinge  ---
Author: tschwinge
Date: Fri May 17 19:13:04 2019
New Revision: 271343

URL: https://gcc.gnu.org/viewcvs?rev=271343=gcc=rev
Log:
[PR89433] Refer to OpenACC 'routine' clauses from "omp declare target"
attribute

gcc/c-family/
PR c/89433
* c-attribs.c (c_common_attribute_table): Set min_len to -1 for
"omp declare target".
gcc/c/
PR c/89433
* c-parser.c (c_finish_oacc_routine): Refer to OpenACC 'routine'
clauses from "omp declare target" attribute.
gcc/cp/
PR c++/89433
* parser.c (cp_finalize_oacc_routine): Refer to OpenACC 'routine'
clauses from "omp declare target" attribute.
gcc/fortran/
PR fortran/89433
* f95-lang.c (gfc_attribute_table): Set min_len to -1 for "omp
declare target".
* trans-decl.c (add_attributes_to_decl): Refer to OpenACC
'routine' clauses from "omp declare target" attribute.
gcc/testsuite/
PR testsuite/89433
* c-c++-common/goacc/classify-routine.c: Update.
* gfortran.dg/goacc/classify-routine.f95: Likewise.

Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-attribs.c
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-parser.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/f95-lang.c
trunk/gcc/fortran/trans-decl.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/goacc/classify-routine.c
trunk/gcc/testsuite/gfortran.dg/goacc/classify-routine.f95

[Bug tree-optimization/90488] OpenACC Profiling Interface: callbacks from the OpenACC implementation into user code

2019-05-16 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90488

--- Comment #1 from Thomas Schwinge  ---
I filed  "OpenACC Profiling
Interface: callbacks branching out of an OpenACC construct/executable
directive", hoping to get some aspects of this clarified/restricted.


(In reply to my comment #0)
> I suppose this is due to the 'GOACC_parallel_keyed' function (implementing
> the OpenACC 'parallel' construct) being tagged as some kind of "leaf"
> function?  It's not in 'gcc/omp-builtins.def', however.  But indeed, if in
> 'gcc/tree-ssa-structalias.c' I disable the special handling for
> 'BUILT_IN_GOACC_PARALLEL' in function 'find_func_aliases_for_builtin_call'
> or 'ipa_pta_execute', then this example behaves as expected.  (Tom added
> this IPA-PTA handling in late 2015; CCed, in case you have any input.)

What this is doing, per my superficial understanding, is "look through" the
'BUILT_IN_GOACC_PARALLEL' internal-function call, into the attached region. 
Thus it doesn't notice that callbacks now may by triggered by the
'GOACC_parallel_keyed' function, before and after the attached region executes.

[Bug tree-optimization/90488] New: OpenACC Profiling Interface: callbacks from the OpenACC implementation into user code

2019-05-15 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90488

Bug ID: 90488
   Summary: OpenACC Profiling Interface: callbacks from the
OpenACC implementation into user code
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: openacc, wrong-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: jakub at gcc dot gnu.org, vries at gcc dot gnu.org
  Target Milestone: ---

As a short summary, the OpenACC Profiling Interface (soon to be committed to
trunk) causes for callbacks from the OpenACC implementation into user code.

For example:

#include 

static int ev_count;

static void cb_any_event (acc_prof_info *prof_info, acc_event_info
*event_info, acc_api_info *api_info)
{
  __builtin_printf ("E");
  ++ev_count;
}

int main()
{
  acc_prof_register (acc_ev_compute_construct_start, cb_any_event,
acc_reg);

  ev_count = 0;
#pragma acc parallel
  // Callback into 'cb_any_event' for 'acc_ev_compute_construct_start'.
  {
  }
  __builtin_printf ("%d\n", ev_count);

  return 0;
}

With optimizations enabled, this will print "E0" instead of the expected "E1",
meaning that the callback function 'cb_any_event' does get invoked, but the
compiler still thinks that this one cannot possibly change the value of
'ev_count'.

I suppose this is due to the 'GOACC_parallel_keyed' function (implementing the
OpenACC 'parallel' construct) being tagged as some kind of "leaf" function? 
It's not in 'gcc/omp-builtins.def', however.  But indeed, if in
'gcc/tree-ssa-structalias.c' I disable the special handling for
'BUILT_IN_GOACC_PARALLEL' in function 'find_func_aliases_for_builtin_call' or
'ipa_pta_execute', then this example behaves as expected.  (Tom added this
IPA-PTA handling in late 2015; CCed, in case you have any input.)

I would then assume that this is not a problem in the common case that the
OpenACC Profiling Interface "library" (the part that is providing and
registering the callbacks) is distinct (separate translation unit) from the
actual user code (containing the OpenACC directives).


For the same reason, we'll probably also have to remove the "nothrow" attribute
for all these builtins/functions (that can cause callbacks to happen)?  (Given
that a callback may "throw", as I understand this?)


All this will probably have adverse effects on compiler optimizations?  :-(

[Bug testsuite/90481] New: Unclean DejaGnu global state after ERROR in one '*.exp' file

2019-05-15 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90481

Bug ID: 90481
   Summary: Unclean DejaGnu global state after ERROR in one
'*.exp' file
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
  Target Milestone: ---

A co-worker had recently ran into this -- which I happened to remember, and now
managed to relate to what I'd just ran into ;-) -- so that shall be sufficient
evidence to file this issue.

In libgomp testing (but probably not specific to that), we saw Fortran files
attempted to be compiled in C++ mode.

My (unproven) theory is as follows.  As usually 'check-*' targets do,
'check-target-libgomp' also runs several '*.exp' files in succession.  Each of
these establishes some DejaGnu global state, which is taken care by the
respective '*.exp' file to clean it up at the end of each '*.exp' file.  For me
now, 'libgomp.oacc-c++/c++.exp' aborted with an ERROR (that's OK -- while it
was running, I removed a file it was later looking for), but due to that, it
then didn't clean up its global state, and the next file,
'libgomp.oacc-fortran/fortran.exp' didn't start with the expected clean global
state, so failed to properly initialize, thus the Fortran files being compiled
in C++ mode.

I'd mentioned before
(<http://mid.mail-archive.com/87ef7roh0f.fsf@euler.schwinge.homeip.net>) that
I'm not happy about this behavior of DejaGnu/'runtest' of not starting each
'*.exp' file with a clean global state, but that's how it currently is.  (I
have not looked whether there's an actual reason for that.)

[Bug middle-end/90417] New: OpenACC 'loop' construct's implicit/explicit 'auto' vs. 'independent' clauses

2019-05-09 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90417

Bug ID: 90417
   Summary: OpenACC 'loop' construct's implicit/explicit 'auto'
vs. 'independent' clauses
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: openacc
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
  Target Milestone: ---

There is some confusion in GCC as well as also in the OpenACC specifiaction
about OpenACC 'loop' constructs' implicit/explicit 'auto' vs. 'independent'
clauses, depending on what the parent compute construct is, or if an orphaned
'loop' construct, and, whether a 'gang', 'worker', 'vector' clause is allowed
together with an 'auto' clause, and whether that then implies 'independent' or
doesn't.  Etc.  This is currently getting clarified by the OpenACC technical
committee.

[Bug target/89221] --enable-frame-pointer does not work as intended

2019-05-09 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89221

--- Comment #5 from Thomas Schwinge  ---
Author: tschwinge
Date: Thu May  9 09:51:59 2019
New Revision: 271028

URL: https://gcc.gnu.org/viewcvs?rev=271028=gcc=rev
Log:
[PR89221] Continue to default to '--disable-frame-pointer' for x86 GNU systems

The recent trunk r270914 for PR89221 "--enable-frame-pointer does not work as
intended" fixed a scripting defect in the x86 '--enable-frame-pointer'
handling.

This has the side effect that, for example, for '--target=i686-gnu' this is now
enabled by default: 'USE_IX86_FRAME_POINTER=1' is added to 'tm_defines'.  Given
that it's highly unlikely that anyone would now suddenly want
'--enable-frame-pointer' as the default for any kind of GNU system, I'm
changing the default back for GNU systems, to match that of a 'target_os' of
'linux* | darwin[8912]*'.

gcc/
PR target/89221
* configure.ac (--enable-frame-pointer): Disable by default for
GNU systems.
* configure: Regenerate.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/configure
trunk/gcc/configure.ac

[Bug target/87835] nvptx offloading: libgomp.oacc-c-c++-common/asyncwait-1.c execution test intermittently fails at -O2

2019-05-08 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87835

--- Comment #8 from Thomas Schwinge  ---
Author: tschwinge
Date: Wed May  8 10:03:04 2019
New Revision: 271005

URL: https://gcc.gnu.org/viewcvs?rev=271005=gcc=rev
Log:
Address compiler diagnostics in libgomp.oacc-c-c++-common/pr87835.c

source-gcc/libgomp/testsuite/libgomp.oacc-c-c++-common/pr87835.c: In
function 'main':
source-gcc/libgomp/testsuite/libgomp.oacc-c-c++-common/pr87835.c:45:
warning: ignoring #pragma loop gang [-Wunknown-pragmas]
   45 | #pragma loop gang
  |
source-gcc/libgomp/testsuite/libgomp.oacc-c-c++-common/pr87835.c:19:7:
warning: unused variable 'b' [-Wunused-variable]
   19 |   int b[n];
  |   ^

libgomp/
PR target/87835
* testsuite/libgomp.oacc-c-c++-common/pr87835.c: Update.

trunk r271004

Modified:
branches/gcc-9-branch/libgomp/ChangeLog
branches/gcc-9-branch/libgomp/testsuite/libgomp.oacc-c-c++-common/pr87835.c

[Bug target/87835] nvptx offloading: libgomp.oacc-c-c++-common/asyncwait-1.c execution test intermittently fails at -O2

2019-05-08 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87835

--- Comment #7 from Thomas Schwinge  ---
Author: tschwinge
Date: Wed May  8 10:01:30 2019
New Revision: 271004

URL: https://gcc.gnu.org/viewcvs?rev=271004=gcc=rev
Log:
Address compiler diagnostics in libgomp.oacc-c-c++-common/pr87835.c

source-gcc/libgomp/testsuite/libgomp.oacc-c-c++-common/pr87835.c: In
function 'main':
source-gcc/libgomp/testsuite/libgomp.oacc-c-c++-common/pr87835.c:45:
warning: ignoring #pragma loop gang [-Wunknown-pragmas]
   45 | #pragma loop gang
  |
source-gcc/libgomp/testsuite/libgomp.oacc-c-c++-common/pr87835.c:19:7:
warning: unused variable 'b' [-Wunused-variable]
   19 |   int b[n];
  |   ^

libgomp/
PR target/87835
* testsuite/libgomp.oacc-c-c++-common/pr87835.c: Update.

Modified:
trunk/libgomp/ChangeLog
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/pr87835.c

[Bug driver/90386] New: Offloading: libgfortran, libm dependencies

2019-05-08 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90386

Bug ID: 90386
   Summary: Offloading: libgfortran, libm dependencies
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: openacc, openmp
  Severity: normal
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

Offloading code generation may depend on libgfortran, or libm, for example,
when compiling Fortran code, or when OMP regions use math functions.  Currently
you manually have to specify 'gfortran -foffload=-lgfortran' (implicit
'-lgfortran', but not implicit '-foffload=-lgfortran' for offloading code
generation), or have to specify '-lm -foffload=-lm' ('-lm' alone should be
sufficient?).

See <http://mid.mail-archive.com/87h9m9e1qj.fsf@schwinge.name> for some more
details, from a few years ago.

[Bug target/87833] [9/10 Regression] Intel MIC (emulated) offloading: "relocation [...] can not be used when making a shared object; recompile with -fPIC"

2019-05-02 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87833

Thomas Schwinge  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #2 from Thomas Schwinge  ---
(In reply to H.J. Lu from comment #1)
> Do you have a testcase?

Thought that would be obvious from the report.  Configure GCC for Intel MIC
(emulated) offloading, then run the libgomp testsuite.

[Bug target/87833] [9/10 Regression] Intel MIC (emulated) offloading: "relocation [...] can not be used when making a shared object; recompile with -fPIC"

2019-04-30 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87833

Thomas Schwinge  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-04-30
Summary|Intel MIC (emulated)|[9/10 Regression] Intel MIC
   |offloading: "relocation |(emulated) offloading:
   |[...] can not be used when  |"relocation [...] can not
   |making a shared object; |be used when making a
   |recompile with -fPIC"   |shared object; recompile
   ||with -fPIC"
 Ever confirmed|0   |1

[Bug middle-end/90247] Reconsider OpenACC implicit data attributes for pointers

2019-04-25 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90247

Thomas Schwinge  changed:

   What|Removed |Added

 Status|UNCONFIRMED |SUSPENDED
   Last reconfirmed||2019-04-25
 Ever confirmed|0   |1

--- Comment #1 from Thomas Schwinge  ---
Suspended until we get clarification about the (at least future) intention of
the OpenACC specification.

[Bug middle-end/90247] New: Reconsider OpenACC implicit data attributes for pointers

2019-04-25 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90247

Bug ID: 90247
   Summary: Reconsider OpenACC implicit data attributes for
pointers
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: openacc
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
  Target Milestone: ---

We've been reading the OpenACC specification such that a pointer variable is a
scalar (not an array), and thus gets an implicit 'firstprivate' clause (not
some kind of 'copy' clause).  This is not what users appear to expect:

int *p = (int *) malloc([...})
#pragma acc enter data create (p[0:100])

#pragma acc parallel loop // implicit 'firstprivate(p)'
for ([i])
  p[i] = [...]

#pragma acc enter data copyout (p[0:100])

The implicit 'firstprivate' clause will not translate the host 'p' to the
corresponding device 'p' that has been 'create'd above, but will copy the host
pointer value untranslated, leading to run-time failure upon dereferencing the
host 'p' on the device.  What users instead would like is what OpenMP calls
"zero-length array section" mapping.

There is discussion that the OpenACC specification is moving into that
direction.

A patch has been proposed,
<http://mid.mail-archive.com/e4c72dcf-95b6-b919-64c6-a3e8c22d74df@codesourcery.com>,
but needs work.


Then, there are similar considerations to be made for other such data mapping
cases/constructs (not listed here now).

[Bug fortran/90048] Fortran OpenACC 'private' clause rejected for predetermined private loop iteration variable

2019-04-17 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90048

--- Comment #2 from Thomas Schwinge  ---
Author: tschwinge
Date: Wed Apr 17 08:34:20 2019
New Revision: 270406

URL: https://gcc.gnu.org/viewcvs?rev=270406=gcc=rev
Log:
[PR90048] Fortran OpenACC 'private' clause rejected for predetermined private
loop iteration variable

gcc/fortran/
PR fortran/90048
* openmp.c (gfc_resolve_do_iterator): Handle sharing_clauses for
OpenACC, too.
(gfc_resolve_oacc_blocks): Populate sharing_clauses with private
clauses.
gcc/testsuite/
PR fortran/90048
* gfortran.dg/goacc/private-explicit-kernels-1.f95: New file.
* gfortran.dg/goacc/private-explicit-parallel-1.f95: Likewise.
* gfortran.dg/goacc/private-explicit-routine-1.f95: Likewise.

Added:
trunk/gcc/testsuite/gfortran.dg/goacc/private-explicit-kernels-1.f95
trunk/gcc/testsuite/gfortran.dg/goacc/private-explicit-parallel-1.f95
trunk/gcc/testsuite/gfortran.dg/goacc/private-explicit-routine-1.f95
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/openmp.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/90114] Predetermined private levels for variables declared in OpenACC accelerator routines

2019-04-17 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90114

--- Comment #1 from Thomas Schwinge  ---
Author: tschwinge
Date: Wed Apr 17 08:34:10 2019
New Revision: 270405

URL: https://gcc.gnu.org/viewcvs?rev=270405=gcc=rev
Log:
[PR90067, PR90114] Document Fortran OpenACC predetermined private status quo

gcc/testsuite/
PR fortran/90067
PR fortran/90114
* gfortran.dg/goacc/private-1.f95: Remove file.
* gfortran.dg/goacc/private-2.f95: Likewise.
* gfortran.dg/goacc/private-predetermined-kernels-1.f95: New file.
* gfortran.dg/goacc/private-predetermined-parallel-1.f95:
Likewise.
* gfortran.dg/goacc/private-predetermined-routine-1.f95: Likewise.

Added:
trunk/gcc/testsuite/gfortran.dg/goacc/private-predetermined-kernels-1.f95
trunk/gcc/testsuite/gfortran.dg/goacc/private-predetermined-parallel-1.f95
trunk/gcc/testsuite/gfortran.dg/goacc/private-predetermined-routine-1.f95
Removed:
trunk/gcc/testsuite/gfortran.dg/goacc/private-1.f95
trunk/gcc/testsuite/gfortran.dg/goacc/private-2.f95
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug fortran/90067] Loop variables in Fortran 'do' statements within a compute construct must be predetermined private

2019-04-17 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90067

--- Comment #1 from Thomas Schwinge  ---
Author: tschwinge
Date: Wed Apr 17 08:34:10 2019
New Revision: 270405

URL: https://gcc.gnu.org/viewcvs?rev=270405=gcc=rev
Log:
[PR90067, PR90114] Document Fortran OpenACC predetermined private status quo

gcc/testsuite/
PR fortran/90067
PR fortran/90114
* gfortran.dg/goacc/private-1.f95: Remove file.
* gfortran.dg/goacc/private-2.f95: Likewise.
* gfortran.dg/goacc/private-predetermined-kernels-1.f95: New file.
* gfortran.dg/goacc/private-predetermined-parallel-1.f95:
Likewise.
* gfortran.dg/goacc/private-predetermined-routine-1.f95: Likewise.

Added:
trunk/gcc/testsuite/gfortran.dg/goacc/private-predetermined-kernels-1.f95
trunk/gcc/testsuite/gfortran.dg/goacc/private-predetermined-parallel-1.f95
trunk/gcc/testsuite/gfortran.dg/goacc/private-predetermined-routine-1.f95
Removed:
trunk/gcc/testsuite/gfortran.dg/goacc/private-1.f95
trunk/gcc/testsuite/gfortran.dg/goacc/private-2.f95
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/90115] New: OpenACC: predetermined private levels for variables declared in blocks

2019-04-16 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90115

Bug ID: 90115
   Summary: OpenACC: predetermined private levels for variables
declared in blocks
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: openacc, wrong-code
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
  Target Milestone: ---

OpenACC 2.7 (same in 2.6), in section 2.6.1. "Variables with Predetermined Data
Attributes" mandates that "Variables declared in a C block that is executed in
'vector-partitioned' mode are private to the thread associated with each vector
lane. Variables declared in a C block that is executed in 'worker-partitioned'
'vector-single' mode are private to the worker and shared across the threads
associated with the vector lanes of that worker. Variables declared in a C
block that is executed in 'worker-single' mode are private to the gang and
shared across the threads associated with the workers and vector lanes of that
gang".

[Bug middle-end/90114] New: Predetermined private levels for variables declared in OpenACC accelerator routines

2019-04-16 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90114

Bug ID: 90114
   Summary: Predetermined private levels for variables declared in
OpenACC accelerator routines
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: openacc, wrong-code
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
  Target Milestone: ---

OpenACC 2.7 (same in 2.6), in section 2.6.1. "Variables with Predetermined Data
Attributes" mandates that "Variables declared in 'seq' routine are private to
the thread that made the call. Variables declared in 'vector' routine are
private to the worker that made the call and shared across the threads
associated with the vector lanes of that worker. Variables declared in 'worker'
or 'gang' routine are private to the gang that made the call and shared across
the threads associated with the workers and vector lanes of that gang".

[Bug fortran/90111] New: Placement of Fortran OpenACC 'routine' directive inside 'specification-part'

2019-04-16 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90111

Bug ID: 90111
   Summary: Placement of Fortran OpenACC 'routine' directive
inside 'specification-part'
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: openacc, rejects-valid
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
  Target Milestone: ---

OpenACC 2.7 (same in 2.6), in section 2.15.1. "Routine Directive" states that
"In Fortran, the 'routine' directive without a name may appear within the
specification part of a subroutine or function definition, or within an
interface body for a subroutine or function in an interface block, and applies
to the containing subroutine or function. The 'routine' directive with a name
may appear in the specification part of a subroutine, function or module, and
applies to the named subroutine or function".

It therefore seems wrong to me that the following gets rejected:

subroutine s
  !$acc routine seq
  implicit none
  integer :: i

  i = 0
end subroutine s

2 |   !$acc routine seq
  |   2
3 |   implicit none
  |   1containi
Error: IMPLICIT NONE statement at (1) cannot follow !$ACC ROUTINE statement
at (2)

Or am I misunderstanding something about 'implicit-stmt'?  But at least for the
'routine' directive without a name, which always implicitly applies to the
containing subprogram etc., this placement should not matter at all (thus, the
above be valid).

I have not looked for any other such rejects-valid constructs.

[Bug fortran/90067] New: Loop variables in Fortran 'do' statements within a compute construct must be predetermined private

2019-04-12 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90067

Bug ID: 90067
   Summary: Loop variables in Fortran 'do' statements within a
compute construct must be predetermined private
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: openacc
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
  Target Milestone: ---

Found while working on PR90048.

OpenACC 2.6 (same in 2.7), in section 2.6.1. "Variables with Predetermined Data
Attributes" states that "The loop variable in a C 'for' statement or Fortran
'do' statement that is associated with a loop directive is predetermined to be
private to each thread that will execute each iteration of the loop.  Loop
variables in Fortran 'do' statements within a compute construct are
predetermined to be private to the thread that executes the loop".

Regarding the latter, for Fortran 'do' statements that are not directly
associated with a 'loop' directive, when these 'do' statements are (somewhere)
nested inside a 'loop' construct, we implement this in the front end by adding
a 'private' clause to the containing 'loop' construct, but when these 'do'
statements are not (somewhere) nested inside a 'loop' construct, we do not add
a 'private' clause to the containing compute construct.  For example, for:

  integer :: i
  !$acc parallel
  do i = 1, 100
  end do
  !$acc end parallel

..., we do not in the front end add a 'private(i)' clause to the 'parallel'
construct.

By the rules as presented in section 2.5. "Compute Constructs", the gimplifier
will then fix this up by adding a 'firstprivate' clause, in the common case of
the 'parallel' construct (same for the 'serial' construct, but a 'copy' clause
for the 'kernels' construct!).

While it might generally be beneficial to have a pass promoting
'firstprivate(x)' with a dominating write operation on 'x' to 'private(x)',
here it would be better (and much simpler) to handle this in the front end.

[Bug fortran/90048] Fortran OpenACC 'private' clause rejected for predetermined private loop iteration variable

2019-04-12 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90048

Thomas Schwinge  changed:

   What|Removed |Added

Summary|Fortran OpenACC 'private'   |Fortran OpenACC 'private'
   |clause rejected for |clause rejected for
   |implicitly private loop |predetermined private loop
   |iteration variable  |iteration variable

--- Comment #1 from Thomas Schwinge  ---
(Summary corrected to say "predetermined private" instead of "implicitly
private".)


OpenACC 2.6 (same in 2.7), in section 2.6.1. "Variables with Predetermined Data
Attributes" states that "The loop variable in a C 'for' statement or Fortran
'do' statement that is associated with a loop directive is predetermined to be
private to each thread that will execute each iteration of the loop.  Loop
variables in Fortran 'do' statements within a compute construct are
predetermined to be private to the thread that executes the loop".

It also states in section 2.6. "Data Environment" that "Variables with
predetermined data attributes may not appear in a data clause that conflicts
with that data attribute", which can be understood to mean that such variables
may (redundantly) appear in clauses that conform with that data attribute.

[Bug fortran/90048] Fortran OpenACC 'private' clause rejected for implicitly private loop iteration variable

2019-04-11 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90048

Thomas Schwinge  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-04-11
   Assignee|unassigned at gcc dot gnu.org  |tschwinge at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug fortran/90048] New: Fortran OpenACC 'private' clause rejected for implicitly private loop iteration variable

2019-04-11 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90048

Bug ID: 90048
   Summary: Fortran OpenACC 'private' clause rejected for
implicitly private loop iteration variable
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: openacc, rejects-valid
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
  Target Milestone: ---

... as reported in <https://gcc.gnu.org/ml/gcc-patches/2017-01/msg02164.html>,
later re-posted in <https://gcc.gnu.org/ml/gcc-patches/2018-08/msg00531.html>.

[Bug fortran/90030] Fortran OMP array data alignment

2019-04-10 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90030

Thomas Schwinge  changed:

   What|Removed |Added

   Keywords||openmp
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-04-10
   Assignee|unassigned at gcc dot gnu.org  |tschwinge at gcc dot 
gnu.org
Summary|Fortran OpenACC subarray|Fortran OMP array data
   |data alignment  |alignment
 Ever confirmed|0   |1

--- Comment #1 from Thomas Schwinge  ---
Reduced test case, added OpenMP variant.

<https://gcc.gnu.org/ml/gcc-patches/2019-04/msg00380.html>.

[Bug fortran/90030] New: Fortran OpenACC subarray data alignment

2019-04-09 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90030

Bug ID: 90030
   Summary: Fortran OpenACC subarray data alignment
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: openacc
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

As reported by Cesar in
<https://gcc.gnu.org/ml/gcc-patches/2015-09/msg01664.html>, and later
re-submitted in <https://gcc.gnu.org/ml/gcc-patches/2018-08/msg01911.html>.

> In both OpenACC and OpenMP, each subarray has at least two data mappings
> associated with them, one for the pointer and another for the data in
> the array section (fortan also has a pset mapping). One problem I
> observed in fortran is that array section data is casted to char *.
> Consequently, when lower_omp_target assigns alignment for the subarray
> data, it does so incorrectly. This is a problem on nvptx if you have a
> data clause such as
> 
>   integer foo
>   real*8 bar (100)
>   
>   !$acc data copy (foo, bar(1:100))
> 
> Here, the data associated with bar could get aligned on a 4 byte
> boundary instead of 8 byte. That causes problems on nvptx targets.
> 
> My fix for this is to prevent the fortran front end from casting the
> data pointers to char *. I only prevented casting on the code which
> handles OMP_CLAUSE_MAP. The subarrays associated with OMP_CLAUSE_SHARED
> also get casted to char *, but I left those as-is because I'm not that
> familiar with how non-OpenMP target regions get lowered.

[Bug tree-optimization/89499] [7/8/9 Regression] ICE in expand_UNIQUE, at internal-fn.c:2605

2019-04-05 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89499

--- Comment #5 from Thomas Schwinge  ---
Created attachment 46094
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46094=edit
[WIP] [PR89499] CIF_OPENACC_ROUTINE_MISMATCH

(In reply to Thomas Schwinge from comment #4)
> Unless there is an OpenACC 'bind' clause involved (also 'nohost' clause?)
> (which are not yet implemented, so not relevant in this discussion), it is
> permissible (and worthwhile for the usual reasons) to inline such functions
> into one another, given proper nesting of OpenACC levels of parallelism. 
> The latter is enforced by construction, by detecting improper caller/callee
> combinations (for example, trying to call a 'gang' routine from a 'vector'
> context).
> 
> By construction, 'IFN_UNIQUE' etc. can only appear in 'oacc function'
> functions.
> 
> There are 'oacc function' functions that do not contain 'IFN_UNIQUE' etc.
> (for example, 'seq' functions, such as math library functions), but which
> might still benefit from inlining.

And, in particular, also the C++ 'acc_on_device' forwarding function with
correctly typed argument.  (See 'openacc.h'.)

> I suppose it is fine to do inlining if the outer function will then be
> handled by 'oaccdevlow'.
> 
> And, I suppose it will be reasonable to forbid inlining of 'oacc function'
> functions into non-'oacc function' functions

..., and this breaks said 'acc_on_device' case...  :-/

This is: the '#pragma acc routine' 'inline' function 'acc_on_device' is
regularely called from non-'#pragma acc routine' functions.

It becomes worse if the C++ forwarding function with correctly typed argument
is actually marked 'always_inline' -- as it probably should be?

So, this has to be permitted.

> because in that case you're
> not applying any OpenACC parallelism anyway, at least for a backportable ICE
> fix, then later possibly more logic added to allow that.
> 
> That will probably be reasonably simple to implement; I'll give it some
> further thought, and testing.

Attaching my WIP patch for that, anyway.

But, as discussed, it seems that it'll have to be a bit more elaborate: do
allow such inlining after all.  I'm still pondering how to best do that.  (a)
Clean up the unexpected stuff at the place where it currently ICEs (by
refactoring stuff currently done in 'oaccdevlow'?).  (b) When the problematic
inlining happens, tag the inlined-into function such that 'oaccdevlow' will
then clean it up in there.  (c) Go as far as cloning the '#pragma acc routine'
functions early, so that the "host" function doesn't get the OpenACC magic
applied, but only the "OMP" one does.  (If this has other benefits maybe, by
not cluttering the "hose" code with OpenACC magic?)

Option (b) would be something similar to what Jakub had suggested:

(In reply to Jakub Jelinek from comment #3)
> Or it is inlinable, but we need some cleanup, in that case perhaps have some
> cfun->* flag that would be initially set to whether the function has
> oacc_get_fn_attrib and would be ored into functions into which those
> functions were inlined, and then the oaccdevlower pass would clean that
> stuff up or whatever.

I think I'll look into that option first, try to locate the places where such
processing is to happen, and leave option (c) for later.

[Bug tree-optimization/89499] [7/8/9 Regression] ICE in expand_UNIQUE, at internal-fn.c:2605

2019-03-27 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89499

Thomas Schwinge  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |tschwinge at gcc dot 
gnu.org

--- Comment #4 from Thomas Schwinge  ---
Thanks for the report, and initial analysis.

Unless there is an OpenACC 'bind' clause involved (also 'nohost' clause?)
(which are not yet implemented, so not relevant in this discussion), it is
permissible (and worthwhile for the usual reasons) to inline such functions
into one another, given proper nesting of OpenACC levels of parallelism.  The
latter is enforced by construction, by detecting improper caller/callee
combinations (for example, trying to call a 'gang' routine from a 'vector'
context).

By construction, 'IFN_UNIQUE' etc. can only appear in 'oacc function'
functions.

There are 'oacc function' functions that do not contain 'IFN_UNIQUE' etc. (for
example, 'seq' functions, such as math library functions), but which might
still benefit from inlining.

I suppose it is fine to do inlining if the outer function will then be handled
by 'oaccdevlow'.

And, I suppose it will be reasonable to forbid inlining of 'oacc function'
functions into non-'oacc function' functions, because in that case you're not
applying any OpenACC parallelism anyway, at least for a backportable ICE fix,
then later possibly more logic added to allow that.

That will probably be reasonably simple to implement; I'll give it some further
thought, and testing.

[Bug fortran/72741] Fortran OpenACC routine directive doesn't properly handle clauses specifying the level of parallelism

2019-03-21 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72741

--- Comment #14 from Thomas Schwinge  ---
Author: tschwinge
Date: Thu Mar 21 20:13:44 2019
New Revision: 269858

URL: https://gcc.gnu.org/viewcvs?rev=269858=gcc=rev
Log:
[PR72741] Properly handle clauses specifying the level of parallelism for
'external' Fortran OpenACC routines

..., so as to also for these enable the generic middle end OMP code to verify
proper nesting of loops/routines regarding their levels of parallelism.

gcc/fortran/
PR fortran/72741
* openmp.c (gfc_match_oacc_routine): Set the level of parallelism
for all variants.
(gfc_resolve_oacc_routines): Call gfc_add_omp_declare_target.
gcc/testsuite/
PR fortran/72741
* c-c++-common/goacc/routine-3-extern.c: New file.
* c-c++-common/goacc/routine-3.c: Adjust.
* c-c++-common/goacc/routine-4-extern.c: New file.
* c-c++-common/goacc/routine-4.c: Adjust.
* gfortran.dg/goacc/routine-module-3.f90: New file.
* gfortran.dg/goacc/routine-external-level-of-parallelism-1.f: New
file.
* gfortran.dg/goacc/routine-external-level-of-parallelism-2.f:
Likewise.

Added:
trunk/gcc/testsuite/c-c++-common/goacc/routine-3-extern.c
  - copied, changed from r269857,
trunk/gcc/testsuite/c-c++-common/goacc/routine-3.c
trunk/gcc/testsuite/c-c++-common/goacc/routine-4-extern.c
  - copied, changed from r269857,
trunk/gcc/testsuite/c-c++-common/goacc/routine-4.c
   
trunk/gcc/testsuite/gfortran.dg/goacc/routine-external-level-of-parallelism-1.f
   
trunk/gcc/testsuite/gfortran.dg/goacc/routine-external-level-of-parallelism-2.f
trunk/gcc/testsuite/gfortran.dg/goacc/routine-module-3.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/openmp.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/goacc/routine-3.c
trunk/gcc/testsuite/c-c++-common/goacc/routine-4.c

[Bug fortran/89773] Fortran OpenACC 'routine' directive refuses procedures with implicit EXTERNAL attribute

2019-03-21 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89773

--- Comment #1 from Thomas Schwinge  ---
Author: tschwinge
Date: Thu Mar 21 20:02:42 2019
New Revision: 269857

URL: https://gcc.gnu.org/viewcvs?rev=269857=gcc=rev
Log:
[PR89773] Fortran OpenACC 'routine' directive refuses procedures with implicit
EXTERNAL attribute

gcc/fortran/
PR fortran/89773
* gfortran.h (gfc_oacc_routine_name): Add loc member.
(gfc_resolve_oacc_routines): Declare.
* openmp.c (gfc_match_oacc_routine): Move some error checking
into...
(gfc_resolve_oacc_routines): ... this new function.
* resolve.c (resolve_codes): Call it.
gcc/testsuite/
PR fortran/89773
* gfortran.dg/goacc/pr89773.f90: New file.
* gfortran.dg/goacc/pr77765.f90: Adjust.
* gfortran.dg/goacc/routine-6.f90: Adjust, and extend.

Added:
trunk/gcc/testsuite/gfortran.dg/goacc/pr89773.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/openmp.c
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/goacc/pr77765.f90
trunk/gcc/testsuite/gfortran.dg/goacc/routine-6.f90

[Bug fortran/72741] Fortran OpenACC routine directive doesn't properly handle clauses specifying the level of parallelism

2019-03-21 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72741

--- Comment #13 from Thomas Schwinge  ---
Author: tschwinge
Date: Thu Mar 21 19:54:51 2019
New Revision: 269856

URL: https://gcc.gnu.org/viewcvs?rev=269856=gcc=rev
Log:
[PR72741] The name in a Fortran OpenACC 'routine' directive refers to the
containing subroutine or function

gcc/fortran/
PR fortran/72741
* openmp.c (gfc_match_oacc_routine): Clarify.
gcc/testsuite/
PR fortran/72741
* gfortran.dg/goacc/routine-module-mod-1.f90: Update.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/openmp.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/goacc/routine-module-mod-1.f90

[Bug fortran/72741] Fortran OpenACC routine directive doesn't properly handle clauses specifying the level of parallelism

2019-03-21 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72741

--- Comment #12 from Thomas Schwinge  ---
Author: tschwinge
Date: Thu Mar 21 19:44:45 2019
New Revision: 269855

URL: https://gcc.gnu.org/viewcvs?rev=269855=gcc=rev
Log:
[PR72741] Encode OpenACC 'routine' directive's level of parallelism inside
Fortran module files

If 'use'ing with an old GCC a new module file (with OpenACC 'routine'
directive's level of parallelism encoded), then that expectedly fails as
follows:

f951: Fatal Error: Reading module 'routine_module_mod_1' at line 27 column
21: find_enum(): Enum not found

If 'use'ing with a new GCC an old module file (without OpenACC 'routine'
directive's level of parallelism encoded), then that (silently) continues to
accept the module file, and will proceed with the previous, erroneous behavior.

These seem to be acceptable compromises, instead of incrementing 'MOD_VERSION'.

gcc/fortran/
PR fortran/72741
* module.c (verify_OACC_ROUTINE_LOP_NONE): New function.
(enum ab_attribute): Add AB_OACC_ROUTINE_LOP_GANG,
AB_OACC_ROUTINE_LOP_WORKER, AB_OACC_ROUTINE_LOP_VECTOR,
AB_OACC_ROUTINE_LOP_SEQ.
(attr_bits): Add these.
(mio_symbol_attribute): Handle these.
gcc/testsuite/
PR fortran/72741
* gfortran.dg/goacc/routine-module-1.f90: New file.
* gfortran.dg/goacc/routine-module-2.f90: Likewise.
* gfortran.dg/goacc/routine-module-mod-1.f90: Likewise.

Added:
trunk/gcc/testsuite/gfortran.dg/goacc/routine-module-1.f90
trunk/gcc/testsuite/gfortran.dg/goacc/routine-module-2.f90
trunk/gcc/testsuite/gfortran.dg/goacc/routine-module-mod-1.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/module.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/56408] Fix dependency handling of testsuite/gfortran.dg

2019-03-21 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56408

--- Comment #17 from Thomas Schwinge  ---
Author: tschwinge
Date: Thu Mar 21 19:31:30 2019
New Revision: 269853

URL: https://gcc.gnu.org/viewcvs?rev=269853=gcc=rev
Log:
[testsuite] Fix 'dg-compile-aux-modules' diagnostic

gcc/testsuite/
PR fortran/56408
* gcc.target/powerpc/ppc-fortran/ppc-fortran.exp
(dg-compile-aux-modules): Fix diagnostic.
* gfortran.dg/coarray/caf.exp (dg-compile-aux-modules): Likewise.
* gfortran.dg/dg.exp (dg-compile-aux-modules): Likewise.

trunk r269851

Modified:
branches/gcc-7-branch/gcc/testsuite/ChangeLog
   
branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/ppc-fortran/ppc-fortran.exp
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/coarray/caf.exp
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/dg.exp

[Bug fortran/56408] Fix dependency handling of testsuite/gfortran.dg

2019-03-21 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56408

--- Comment #16 from Thomas Schwinge  ---
Author: tschwinge
Date: Thu Mar 21 19:31:09 2019
New Revision: 269852

URL: https://gcc.gnu.org/viewcvs?rev=269852=gcc=rev
Log:
[testsuite] Fix 'dg-compile-aux-modules' diagnostic

gcc/testsuite/
PR fortran/56408
* gcc.target/powerpc/ppc-fortran/ppc-fortran.exp
(dg-compile-aux-modules): Fix diagnostic.
* gfortran.dg/coarray/caf.exp (dg-compile-aux-modules): Likewise.
* gfortran.dg/dg.exp (dg-compile-aux-modules): Likewise.

trunk r269851

Modified:
branches/gcc-8-branch/gcc/testsuite/ChangeLog
   
branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/ppc-fortran/ppc-fortran.exp
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/coarray/caf.exp
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/dg.exp

[Bug fortran/56408] Fix dependency handling of testsuite/gfortran.dg

2019-03-21 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56408

--- Comment #15 from Thomas Schwinge  ---
Author: tschwinge
Date: Thu Mar 21 19:29:57 2019
New Revision: 269851

URL: https://gcc.gnu.org/viewcvs?rev=269851=gcc=rev
Log:
[testsuite] Fix 'dg-compile-aux-modules' diagnostic

gcc/testsuite/
PR fortran/56408
* gcc.target/powerpc/ppc-fortran/ppc-fortran.exp
(dg-compile-aux-modules): Fix diagnostic.
* gfortran.dg/coarray/caf.exp (dg-compile-aux-modules): Likewise.
* gfortran.dg/dg.exp (dg-compile-aux-modules): Likewise.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/powerpc/ppc-fortran/ppc-fortran.exp
trunk/gcc/testsuite/gfortran.dg/coarray/caf.exp
trunk/gcc/testsuite/gfortran.dg/dg.exp

[Bug fortran/56408] Fix dependency handling of testsuite/gfortran.dg

2019-03-21 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56408

--- Comment #14 from Thomas Schwinge  ---
Author: tschwinge
Date: Thu Mar 21 19:17:12 2019
New Revision: 269850

URL: https://gcc.gnu.org/viewcvs?rev=269850=gcc=rev
Log:
[testsuite, Fortran] Apply DejaGnu 1.4.4 work-around also to
'gfortran.dg/coarray/caf.exp:dg-compile-aux-modules'

See trunk r215293.  This unifies all 'dg-compile-aux-modules' instances.

gcc/testsuite/
PR fortran/56408
* gfortran.dg/coarray/caf.exp (dg-compile-aux-modules): Workaround
missing nexted dg-test call support in dejaGNU 1.4.4.

trunk r269848

Modified:
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/coarray/caf.exp

[Bug fortran/56408] Fix dependency handling of testsuite/gfortran.dg

2019-03-21 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56408

--- Comment #12 from Thomas Schwinge  ---
Author: tschwinge
Date: Thu Mar 21 19:16:29 2019
New Revision: 269848

URL: https://gcc.gnu.org/viewcvs?rev=269848=gcc=rev
Log:
[testsuite, Fortran] Apply DejaGnu 1.4.4 work-around also to
'gfortran.dg/coarray/caf.exp:dg-compile-aux-modules'

See trunk r215293.  This unifies all 'dg-compile-aux-modules' instances.

gcc/testsuite/
PR fortran/56408
* gfortran.dg/coarray/caf.exp (dg-compile-aux-modules): Workaround
missing nexted dg-test call support in dejaGNU 1.4.4.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/coarray/caf.exp

[Bug fortran/56408] Fix dependency handling of testsuite/gfortran.dg

2019-03-21 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56408

--- Comment #13 from Thomas Schwinge  ---
Author: tschwinge
Date: Thu Mar 21 19:16:54 2019
New Revision: 269849

URL: https://gcc.gnu.org/viewcvs?rev=269849=gcc=rev
Log:
[testsuite, Fortran] Apply DejaGnu 1.4.4 work-around also to
'gfortran.dg/coarray/caf.exp:dg-compile-aux-modules'

See trunk r215293.  This unifies all 'dg-compile-aux-modules' instances.

gcc/testsuite/
PR fortran/56408
* gfortran.dg/coarray/caf.exp (dg-compile-aux-modules): Workaround
missing nexted dg-test call support in dejaGNU 1.4.4.

trunk r269848

Modified:
branches/gcc-8-branch/gcc/testsuite/ChangeLog
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/coarray/caf.exp

[Bug fortran/29383] Fortran 2003/F95[TR15580:1999]: Floating point exception (IEEE) support

2019-03-21 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29383

--- Comment #18 from Thomas Schwinge  ---
Author: tschwinge
Date: Thu Mar 21 18:57:39 2019
New Revision: 269846

URL: https://gcc.gnu.org/viewcvs?rev=269846=gcc=rev
Log:
[testsuite, Fortran] Consistently set 'DEFAULT_FFLAGS'

In the same 'runtest' instance, 'global' variables persist from one '*.exp'
file to another.

All other '*.exp' files are using " -pedantic-errors" instead of the empty
string as the default for 'DEFAULT_FFLAGS'.  Thus this setting of
'DEFAULT_FFLAGS' is not idempotent, depends on whether
'gfortran.dg/ieee/ieee.exp', or an other defining '*.exp' file is executed
first.

gcc/testsuite/
PR fortran/29383
* gfortran.dg/ieee/ieee.exp (DEFAULT_FFLAGS): Set the same as in
other '*.exp' files.

trunk r269845

Modified:
branches/gcc-8-branch/gcc/testsuite/ChangeLog
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/ieee/ieee.exp

[Bug fortran/29383] Fortran 2003/F95[TR15580:1999]: Floating point exception (IEEE) support

2019-03-21 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29383

--- Comment #19 from Thomas Schwinge  ---
Author: tschwinge
Date: Thu Mar 21 18:57:56 2019
New Revision: 269847

URL: https://gcc.gnu.org/viewcvs?rev=269847=gcc=rev
Log:
[testsuite, Fortran] Consistently set 'DEFAULT_FFLAGS'

In the same 'runtest' instance, 'global' variables persist from one '*.exp'
file to another.

All other '*.exp' files are using " -pedantic-errors" instead of the empty
string as the default for 'DEFAULT_FFLAGS'.  Thus this setting of
'DEFAULT_FFLAGS' is not idempotent, depends on whether
'gfortran.dg/ieee/ieee.exp', or an other defining '*.exp' file is executed
first.

gcc/testsuite/
PR fortran/29383
* gfortran.dg/ieee/ieee.exp (DEFAULT_FFLAGS): Set the same as in
other '*.exp' files.

trunk r269845

Modified:
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/ieee/ieee.exp

[Bug fortran/29383] Fortran 2003/F95[TR15580:1999]: Floating point exception (IEEE) support

2019-03-21 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29383

--- Comment #17 from Thomas Schwinge  ---
Author: tschwinge
Date: Thu Mar 21 18:54:50 2019
New Revision: 269845

URL: https://gcc.gnu.org/viewcvs?rev=269845=gcc=rev
Log:
[testsuite, Fortran] Consistently set 'DEFAULT_FFLAGS'

In the same 'runtest' instance, 'global' variables persist from one '*.exp'
file to another.

All other '*.exp' files are using " -pedantic-errors" instead of the empty
string as the default for 'DEFAULT_FFLAGS'.  Thus this setting of
'DEFAULT_FFLAGS' is not idempotent, depends on whether
'gfortran.dg/ieee/ieee.exp', or an other defining '*.exp' file is executed
first.

gcc/testsuite/
PR fortran/29383
* gfortran.dg/ieee/ieee.exp (DEFAULT_FFLAGS): Set the same as in
other '*.exp' files.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/ieee/ieee.exp

[Bug fortran/89787] New: Fortran OpenACC 'routine' directive: parent namespace(s)

2019-03-21 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89787

Bug ID: 89787
   Summary: Fortran OpenACC 'routine' directive: parent
namespace(s)
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: openacc
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: aldot at gcc dot gnu.org
  Target Milestone: ---

See the suggested 'gfc_find_symtree' changes and then 'gfc_find_sym_tree'
comment in <https://gcc.gnu.org/ml/fortran/2018-10/msg8.html>.  We'll need
to understand how to constuct such (nested?) namespaces, need test cases.

[Bug fortran/89773] Fortran OpenACC 'routine' directive refuses procedures with implicit EXTERNAL attribute

2019-03-20 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89773

Thomas Schwinge  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-03-20
 Ever confirmed|0   |1

[Bug fortran/89773] New: Fortran OpenACC 'routine' directive refuses procedures with implicit EXTERNAL attribute

2019-03-20 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89773

Bug ID: 89773
   Summary: Fortran OpenACC 'routine' directive refuses procedures
with implicit EXTERNAL attribute
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: openacc
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: tschwinge at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
  Target Milestone: ---

... as mentioned in
<http://mid.mail-archive.com/9e1f3bc5-2da8-1aae-67b0-bf478a53dd2a@codesourcery.com>.

[Bug target/65181] Support for alloca in nvptx

2019-03-14 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65181

Thomas Schwinge  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-03-14
 CC|bernds at gcc dot gnu.org  |vries at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Thomas Schwinge  ---
(In reply to Martin Liška from comment #2)
> Can the bug be marked as resolved?

No.

(In reply to Thomas Schwinge from comment #0)
> There is no alloca in PTX, but can it perhaps be implemented using PTX local
> memory?

..., and for "gang-private"/"gang-local" memory (PTX '.shared'), this
supposedly will need cooperation with the GPU kernel launching
('cuLaunchKernel'), specifying "the amount of dynamic shared memory that will
be available to each thread block"?

[Bug fortran/83515] ICE: Invalid expression in gfc_element_size

2019-03-12 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83515

Thomas Schwinge  changed:

   What|Removed |Added

   Last reconfirmed|2017-12-22 00:00:00 |2019-3-12
 CC||tschwinge at gcc dot gnu.org

--- Comment #4 from Thomas Schwinge  ---
(In reply to DIL from comment #2)
> For GFORTRAN 6.4.0 and earlier, the relevant compiler bug has been fixed in
> 78300.

Are you saying that the exact same bug reappeared here, which had previously
been discussed and fixed in PR78300?


(In reply to G. Steinmetz from comment #3)
> Simplified : [...]

Thanks, ICE confirmed/still present.

[Bug c/89433] Repeated use of the OpenACC 'routine' directive

2019-02-28 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89433

--- Comment #2 from Thomas Schwinge  ---
Author: tschwinge
Date: Thu Feb 28 20:31:36 2019
New Revision: 269287

URL: https://gcc.gnu.org/viewcvs?rev=269287=gcc=rev
Log:
[PR72741, PR89433] Repeated use of the Fortran OpenACC 'routine' directive

gcc/fortran/
PR fortran/72741
PR fortran/89433
* openmp.c (gfc_match_oacc_routine): Handle repeated use of the
Fortran OpenACC 'routine' directive.
gcc/testsuite/
PR fortran/72741
PR fortran/89433
* gfortran.dg/goacc/routine-multiple-directives-1.f90: New file.
* gfortran.dg/goacc/routine-multiple-directives-2.f90: Likewise.

Added:
trunk/gcc/testsuite/gfortran.dg/goacc/routine-multiple-directives-1.f90
trunk/gcc/testsuite/gfortran.dg/goacc/routine-multiple-directives-2.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/openmp.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/72741] Fortran OpenACC routine directive doesn't properly handle clauses specifying the level of parallelism

2019-02-28 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72741

--- Comment #10 from Thomas Schwinge  ---
Author: tschwinge
Date: Thu Feb 28 20:31:23 2019
New Revision: 269286

URL: https://gcc.gnu.org/viewcvs?rev=269286=gcc=rev
Log:
[PR72741] For all Fortran OpenACC 'routine' directive variants check for
multiple clauses specifying the level of parallelism

gcc/fortran/
PR fortran/72741
* gfortran.h (enum oacc_routine_lop): Add OACC_ROUTINE_LOP_ERROR.
* openmp.c (gfc_oacc_routine_lop, gfc_match_oacc_routine): Use it.
* trans-decl.c (add_attributes_to_decl): Likewise.
gcc/testsuite/
PR fortran/72741
* gfortran.dg/goacc/routine-multiple-lop-clauses-1.f90: New file.

Added:
trunk/gcc/testsuite/gfortran.dg/goacc/routine-multiple-lop-clauses-1.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/openmp.c
trunk/gcc/fortran/trans-decl.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/72741] Fortran OpenACC routine directive doesn't properly handle clauses specifying the level of parallelism

2019-02-28 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72741

--- Comment #11 from Thomas Schwinge  ---
Author: tschwinge
Date: Thu Feb 28 20:31:36 2019
New Revision: 269287

URL: https://gcc.gnu.org/viewcvs?rev=269287=gcc=rev
Log:
[PR72741, PR89433] Repeated use of the Fortran OpenACC 'routine' directive

gcc/fortran/
PR fortran/72741
PR fortran/89433
* openmp.c (gfc_match_oacc_routine): Handle repeated use of the
Fortran OpenACC 'routine' directive.
gcc/testsuite/
PR fortran/72741
PR fortran/89433
* gfortran.dg/goacc/routine-multiple-directives-1.f90: New file.
* gfortran.dg/goacc/routine-multiple-directives-2.f90: Likewise.

Added:
trunk/gcc/testsuite/gfortran.dg/goacc/routine-multiple-directives-1.f90
trunk/gcc/testsuite/gfortran.dg/goacc/routine-multiple-directives-2.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/openmp.c
trunk/gcc/testsuite/ChangeLog

[Bug c/89433] Repeated use of the OpenACC 'routine' directive

2019-02-28 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89433

--- Comment #1 from Thomas Schwinge  ---
Author: tschwinge
Date: Thu Feb 28 20:31:01 2019
New Revision: 269285

URL: https://gcc.gnu.org/viewcvs?rev=269285=gcc=rev
Log:
[PR72741, PR89433] Accept intrinsic symbols in Fortran OpenACC 'routine'
directives

gcc/fortran/
PR fortran/72741
PR fortran/89433
* openmp.c (gfc_match_oacc_routine): Accept intrinsic symbols.
gcc/testsuite/
PR fortran/72741
PR fortran/89433
* gfortran.dg/goacc/routine-6.f90: Update
* gfortran.dg/goacc/routine-intrinsic-1.f: New file.
* gfortran.dg/goacc/routine-intrinsic-2.f: Likewise.

Added:
trunk/gcc/testsuite/gfortran.dg/goacc/routine-intrinsic-1.f
trunk/gcc/testsuite/gfortran.dg/goacc/routine-intrinsic-2.f
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/openmp.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/goacc/routine-6.f90

[Bug fortran/72741] Fortran OpenACC routine directive doesn't properly handle clauses specifying the level of parallelism

2019-02-28 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72741

--- Comment #9 from Thomas Schwinge  ---
Author: tschwinge
Date: Thu Feb 28 20:31:01 2019
New Revision: 269285

URL: https://gcc.gnu.org/viewcvs?rev=269285=gcc=rev
Log:
[PR72741, PR89433] Accept intrinsic symbols in Fortran OpenACC 'routine'
directives

gcc/fortran/
PR fortran/72741
PR fortran/89433
* openmp.c (gfc_match_oacc_routine): Accept intrinsic symbols.
gcc/testsuite/
PR fortran/72741
PR fortran/89433
* gfortran.dg/goacc/routine-6.f90: Update
* gfortran.dg/goacc/routine-intrinsic-1.f: New file.
* gfortran.dg/goacc/routine-intrinsic-2.f: Likewise.

Added:
trunk/gcc/testsuite/gfortran.dg/goacc/routine-intrinsic-1.f
trunk/gcc/testsuite/gfortran.dg/goacc/routine-intrinsic-2.f
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/openmp.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/goacc/routine-6.f90

[Bug target/89504] New: Checking ICE in 'gcc.dg/rtl/x86_64/pro_and_epilogue.c'

2019-02-26 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89504

Bug ID: 89504
   Summary: Checking ICE in 'gcc.dg/rtl/x86_64/pro_and_epilogue.c'
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-checking
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
 Build: x86_64-pc-linux-gnu

Comparing a '--enable-checking=yes' build with a
'--enable-checking=yes,extra,df,fold,rtl' build of r269110 (but this started
much, much earlier, but can't tell exactly when), I see:

[-PASS:-]{+FAIL: gcc.dg/rtl/x86_64/pro_and_epilogue.c (internal compiler
error)+}
{+FAIL:+} gcc.dg/rtl/x86_64/pro_and_epilogue.c (test for excess errors)
[-PASS:-]{+FAIL:+} gcc.dg/rtl/x86_64/pro_and_epilogue.c scan-rtl-dump-times
pro_and_epilogue "NOTE_INSN_PROLOGUE_END" 1
[-PASS:-]{+FAIL:+} gcc.dg/rtl/x86_64/pro_and_epilogue.c scan-rtl-dump-times
pro_and_epilogue "simple_return" 2

during RTL pass: pro_and_epilogue
dump file: pro_and_epilogue.c.288r.pro_and_epilogue
[...]/gcc/testsuite/gcc.dg/rtl/x86_64/pro_and_epilogue.c: In function
'test_1':
[...]/gcc/testsuite/gcc.dg/rtl/x86_64/pro_and_epilogue.c:103:1: internal
compiler error: in df_scan_verify, at df-scan.c:4233
0x5ffb7f df_scan_verify()
[...]/gcc/df-scan.c:4233
0xb729f8 df_verify()
[...]/gcc/df-core.c:1817
0xb72a87 df_analyze_1
[...]/gcc/df-core.c:1213
0xca4fb2 thread_prologue_and_epilogue_insns()
[...]/gcc/function.c:5840
0xca5872 rest_of_handle_thread_prologue_and_epilogue
[...]/gcc/function.c:6342
0xca5872 execute
[...]/gcc/function.c:6384

[Bug middle-end/89503] New: Checking ICE in 'gcc.dg/warn-strlen-no-nul.c'

2019-02-26 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89503

Bug ID: 89503
   Summary: Checking ICE in 'gcc.dg/warn-strlen-no-nul.c'
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-checking, ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
 Build: x86_64-pc-linux-gnu

Comparing a '--enable-checking=yes' build with a
'--enable-checking=yes,extra,df,fold,rtl' build of r269110 (but this started
earlier, but can't tell exactly when), I see:

[-PASS:-]{+FAIL:+} gcc.dg/warn-strlen-no-nul.c  (test for warnings, line
100)
[-PASS:-]{+FAIL:+} gcc.dg/warn-strlen-no-nul.c  (test for warnings, line
101)
[-PASS:-]{+FAIL:+} gcc.dg/warn-strlen-no-nul.c  (test for warnings, line
103)
[...]
[-PASS:-]{+FAIL:+} gcc.dg/warn-strlen-no-nul.c  (test for warnings, line
230)
[-PASS:-]{+FAIL:+} gcc.dg/warn-strlen-no-nul.c  (test for warnings, line
231)
[-PASS:-]{+FAIL:+} gcc.dg/warn-strlen-no-nul.c  (test for warnings, line
232)
PASS: gcc.dg/warn-strlen-no-nul.c  (test for warnings, line 26)
[-PASS:-]{+FAIL:+} gcc.dg/warn-strlen-no-nul.c  (test for warnings, line
27)
[-PASS:-]{+FAIL:+} gcc.dg/warn-strlen-no-nul.c  (test for warnings, line
276)
[-PASS:-]{+FAIL:+} gcc.dg/warn-strlen-no-nul.c  (test for warnings, line
277)
[...]
[-PASS:-]{+FAIL:+} gcc.dg/warn-strlen-no-nul.c  (test for warnings, line
74)
[-PASS:-]{+FAIL:+} gcc.dg/warn-strlen-no-nul.c  (test for warnings, line
75)
[-PASS:-]{+FAIL:+} gcc.dg/warn-strlen-no-nul.c  (test for warnings, line
76)
PASS: gcc.dg/warn-strlen-no-nul.c  (test for warnings, line 8)
[-PASS:-]{+FAIL:+} gcc.dg/warn-strlen-no-nul.c  (test for warnings, line
81)
[-PASS:-]{+FAIL:+} gcc.dg/warn-strlen-no-nul.c  (test for warnings, line
85)
[-PASS:-]{+FAIL:+} gcc.dg/warn-strlen-no-nul.c  (test for warnings, line
92)
[-PASS:-]{+FAIL:+} gcc.dg/warn-strlen-no-nul.c  (test for warnings, line
96)
[-PASS:-]{+FAIL:+} gcc.dg/warn-strlen-no-nul.c  (test for warnings, line
98)
[-PASS:-]{+FAIL:+} gcc.dg/warn-strlen-no-nul.c  (test for warnings, line
99)
[-PASS:-]{+FAIL: gcc.dg/warn-strlen-no-nul.c (internal compiler error)+}
{+FAIL:+} gcc.dg/warn-strlen-no-nul.c (test for excess errors)

[...]/gcc/testsuite/gcc.dg/warn-strlen-no-nul.c: In function 'test_26':
[...]/gcc/testsuite/gcc.dg/warn-strlen-no-nul.c:26:1: warning: 'strlen'
argument missing terminating nul [-Wstringop-overflow=]
[...]/gcc/testsuite/gcc.dg/warn-strlen-no-nul.c:8:12: note: referenced
argument declared here
[...]/gcc/testsuite/gcc.dg/warn-strlen-no-nul.c:26:1: internal compiler
error: fold check: original tree changed by fold
0xc5ce8f fold_check_failed
[...]/gcc/fold-const.c:12106
0xc90d44 fold(tree_node*)
[...]/gcc/fold-const.c:12083
0xa4935e c_fully_fold_internal
[...]/gcc/c/c-fold.c:626
0xa4bb07 c_fully_fold(tree_node*, bool, bool*, bool)
[...]/gcc/c/c-fold.c:125
0xa123c7 convert_arguments
[...]/gcc/c/c-typeck.c:3542
0xa123c7 build_function_call_vec(unsigned int, vec, tree_node*, vec*, vec*)
[...]/gcc/c/c-typeck.c:3084
0xa2ef11 c_parser_postfix_expression_after_primary
[...]/gcc/c/c-parser.c:9591
0xa207a1 c_parser_postfix_expression
[...]/gcc/c/c-parser.c:9270
0xa2a35f c_parser_unary_expression
[...]/gcc/c/c-parser.c:7380
0xa2b9cf c_parser_cast_expression
[...]/gcc/c/c-parser.c:7222
0xa2bc48 c_parser_binary_expression
[...]/gcc/c/c-parser.c:7025
0xa2cc15 c_parser_conditional_expression
[...]/gcc/c/c-parser.c:6759
0xa2d240 c_parser_expr_no_commas
[...]/gcc/c/c-parser.c:6676
0xa2d4a1 c_parser_expression
[...]/gcc/c/c-parser.c:9727
0xa2dbc7 c_parser_expression_conv
[...]/gcc/c/c-parser.c:9760
0xa3d17b c_parser_statement_after_labels
[...]/gcc/c/c-parser.c:5610
0xa3f27a c_parser_compound_statement_nostart
[...]/gcc/c/c-parser.c:5148
0xa3f808 c_parser_compound_statement
[...]/gcc/c/c-parser.c:4982
0xa40f12 c_parser_declaration_or_fndef
[...]/gcc/c/c-parser.c:2354
0xa47f6f c_parser_external_declaration
[...]/gcc/c/c-parser.c:1653

[Bug fortran/72741] Fortran OpenACC routine directive doesn't properly handle clauses specifying the level of parallelism

2019-02-22 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72741

--- Comment #8 from Thomas Schwinge  ---
Author: tschwinge
Date: Fri Feb 22 10:50:35 2019
New Revision: 269105

URL: https://gcc.gnu.org/viewcvs?rev=269105=gcc=rev
Log:
[PR72741] Use 'oacc_build_routine_dims' for Fortran OpenACC 'routine'
directives, too

... instead of having an incomplete local implementation.

With these changes in place, we can then also revert the work-around r267213
"[nvptx] Unify C/Fortran routine handling in nvptx_goacc_validate_dims".

gcc/fortran/
PR fortran/72741
* gfortran.h (oacc_routine_lop): New enum.
(symbol_attribute): Use it.
* openmp.c (gfc_oacc_routine_dims): Replace with...
(gfc_oacc_routine_lop): ... this new function.
(gfc_match_oacc_routine): Adjust.
* trans-decl.c (add_attributes_to_decl): Likewise.
gcc/
PR fortran/72741
* omp-general.c (oacc_replace_fn_attrib): Mostly split out into...
(oacc_replace_fn_attrib_attr): ... this new function.
* omp-general.h (oacc_replace_fn_attrib_attr): New prototype.
* config/nvptx/nvptx.c (nvptx_goacc_validate_dims_1): Revert
workaround.
gcc/testsuite/
PR fortran/72741
* gfortran.dg/goacc/classify-routine.f95: Adjust.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/nvptx/nvptx.c
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/openmp.c
trunk/gcc/fortran/trans-decl.c
trunk/gcc/omp-general.c
trunk/gcc/omp-general.h
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/goacc/classify-routine.f95

[Bug ipa/78027] [6 Regression] ICE in new_oacc_loop_routine, at omp-low.c:19000

2019-02-22 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78027

--- Comment #11 from Thomas Schwinge  ---
Author: tschwinge
Date: Fri Feb 22 10:50:02 2019
New Revision: 269103

URL: https://gcc.gnu.org/viewcvs?rev=269103=gcc=rev
Log:
Silence '-Whsa' diagnostic in 'gfortran.dg/goacc/pr78027.f90'

... which has been present (with HSA offloading configured) ever since this
test case got added.

gcc/testsuite/
PR fortran/78027
* gfortran.dg/goacc/pr78027.f90: Add 'dg-additional-options
"-Wno-hsa"'.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/goacc/pr78027.f90

[Bug c/89433] New: Repeated use of the OpenACC 'routine' directive

2019-02-21 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89433

Bug ID: 89433
   Summary: Repeated use of the OpenACC 'routine' directive
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: openacc
  Severity: normal
  Priority: P3
 Component: c
  Assignee: tschwinge at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
Depends on: 72741
  Target Milestone: ---

We found that it's not correct that we currently unconditionally diagnose an
error for repeated use of the OpenACC 'routine' directive on one
function/declaration.  (For reference, it is also permissible for an "ordinary"
function to have several declarations plus a definition, as long as these are
compatible.)  This is, the following shall be valid:

#pragma acc routine worker
void f(void)
{
}
#pragma acc routine (f) worker
#pragma acc routine worker
extern void f(void);

Within one translation unit, we just remove the existing diagnostic, and
declare it user error if any two usages are not compatible, but in that case we
try to be helpful, and produce a compile-time diagnostic.  For incompatible use
spanning over multiple translation units, it will be more difficult to produce
meaningful diagnostics/semantics.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72741
[Bug 72741] Fortran OpenACC routine directive doesn't properly handle clauses
specifying the level of parallelism

[Bug c/87924] OpenACC wait clauses without async-arguments

2019-02-19 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87924

--- Comment #3 from Thomas Schwinge  ---
Author: tschwinge
Date: Tue Feb 19 16:04:17 2019
New Revision: 269020

URL: https://gcc.gnu.org/viewcvs?rev=269020=gcc=rev
Log:
[PR87924] OpenACC wait clauses without async-arguments: remove XFAILs

... which the recent r269016 didn't do.

gcc/testsuite/
PR c/87924
* c-c++-common/goacc/asyncwait-5.c: Remove XFAILs.
* gfortran.dg/goacc/asyncwait-5.f: Likewise.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/goacc/asyncwait-5.c
trunk/gcc/testsuite/gfortran.dg/goacc/asyncwait-5.f

[Bug libgomp/82864] Stop using GOMP_OFFLOAD_openacc_async_set_async

2019-02-19 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82864

Thomas Schwinge  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-02-19
   Assignee|unassigned at gcc dot gnu.org  |cltang at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Thomas Schwinge  ---
(In reply to Tom de Vries from comment #0)
> [...]
> It is a bit odd though that we're asking the target plugin to keep this
> state. [...]

(In reply to Tom de Vries from comment #1)
> Hmm, I found this on openacc-gcc-7-branch:
> ...
> commit cd69c58db3f41ac72c20bc9b780772ab7e0c113e
> Author: Chung-Lin Tang 
> Date:   Tue Jul 25 15:02:26 2017 +
> 
> OpenACC async re-work
> 
> ...
> 
> libgomp/
> 
> (GOMP_OFFLOAD_openacc_async_set_async): Remove.

Indeed, Chung-Lin, please reference this PR82864 in your "async re-work"
changes.

[Bug tree-optimization/89376] ICE: Segmentation fault (in oacc_entry_exit_ok_1)

2019-02-19 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89376

Thomas Schwinge  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-02-19
 CC||tschwinge at gcc dot gnu.org,
   ||vries at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug fortran/72715] ICE in gfc_trans_omp_do, at fortran/trans-openmp.c:3164

2019-02-14 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72715

Thomas Schwinge  changed:

   What|Removed |Added

   Keywords|ice-on-invalid-code, openmp |openacc
 Status|NEW |ASSIGNED
   Last reconfirmed|2016-07-27 00:00:00 |2019-2-14
 CC||burnus at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |tschwinge at gcc dot 
gnu.org

--- Comment #5 from Thomas Schwinge  ---
Thanks for the report (Gerhard), and patch (Cesar); ICE addressed in trunk
r268875, like done for OpenMP in PR60127, trunk r210331.

[Bug middle-end/89099] New: Have "-fopt-info" show the original source code context

2019-01-29 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89099

Bug ID: 89099
   Summary: Have "-fopt-info" show the original source code
context
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: enhancement
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
  Target Milestone: ---

It would be useful to have "-fopt-info" show the original source code context.

For example, we've got diagnostics like:

[...]/asyncwait-1.c: In function 'main':
[...]/asyncwait-1.c:14:11: warning: unused parameter 'argc'
[-Wunused-parameter]
   14 | main (int argc, char **argv)
  |   ^~~~

..., but "-fopt-info" only prints a terse form:

[...]
[...]/asyncwait-1.c:480:9: optimized: assigned OpenACC gang loop
parallelism
[...]

... without showing any of the original source code context.

This should be enabled by default, if possible, but disabled by some flag (can
just use "-fno-diagnostics-show-caret" here, too?).

[Bug libgomp/87835] nvptx offloading: libgomp.oacc-c-c++-common/asyncwait-1.c execution test intermittently fails at -O2

2019-01-18 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87835

--- Comment #3 from Thomas Schwinge  ---
Created attachment 45457
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45457=edit
[WIP] libgomp.oacc-c-c++-common/asyncwait-1.c debug

(In reply to Tom de Vries from comment #2)
> (In reply to Tom de Vries from comment #1)
> > (In reply to Thomas Schwinge from comment #0)
> > > After r264397 "[nvptx] Remove use of CUDA unified memory in libgomp", I'm
> > > seeing (intermittently only, and only on some systems):
> > 
> > I see the failure reproduced consistently with a Quadro M1200.

Oh, good -- in a way ;-) -- that it's consistently reproducable for you.  For
me, the failure is rather rare.

> > > I have not yet analyzed what's causing this, but I have some ideas about
> > > pending patches that might cure it.

Unfortunately, the patches I've been thinking of either are on trunk already,
or can't possibly be related to this problem.

The 'async'/'wait' clauses/directives in the test case look correct.

> do you intend to address this before stage4 closes?

I'd like to, yes.


Here is my current status.


With "-O2":

[...]
  nvptx_exec: kernel main$_omp_fn$37: launch gangs=32, workers=1,
vectors=32
  nvptx_exec: kernel main$_omp_fn$37: finished
  GOACC_data_end: restore mappings
  GOACC_data_end: mappings restored
[abort]

In addition to "main$_omp_fn$37", sometimes also seen with "main$_omp_fn$25",
"main$_omp_fn$29", "main$_omp_fn$33".

So far only seen with OpenACC 'kernels' constructs, but not with the very
similar 'parallel' ones earlier in the file.

For example, without "DEBUG_K":

[...]
  nvptx_exec: kernel main$_omp_fn$37: launch gangs=32, workers=1,
vectors=32
  nvptx_exec: kernel main$_omp_fn$37: finished
GOACC_wait -2 1
goacc_wait -2 1
goacc_wait   1
  GOACC_data_end: restore mappings
  GOACC_data_end: mappings restored
1007 c[64] 0
1019 e[64] 13
1007 c[65] 0
1019 e[65] 13
1007 c[66] 0
1019 e[66] 13
[...]
1007 c[125] 0
1019 e[125] 13
1007 c[126] 0
1019 e[126] 13
1007 c[127] 0
1019 e[127] 13

With "DEBUG_K":

[...]
  nvptx_exec: kernel main$_omp_fn$37: launch gangs=1, workers=1, vectors=32
  nvptx_exec: kernel main$_omp_fn$37: finished
GOACC_wait -2 1
goacc_wait -2 1
goacc_wait   1
966 c[64] 0
966 c[65] 0
966 c[66] 0
[...]
966 c[125] 0
966 c[126] 0
966 c[127] 0

So, the compute kernel ("main$_omp_fn$37") doesn't find the "c" array properly
initialized, even though they're enqueued on the same 'async', so have to
execute in proper order by definition.

I've only ever seen this with the "c" array.

Sometimes that's starting already with index 0 (often seen with
"main$_omp_fn$29"), or as late as index 100 (rarely).


When running under "valgrind", repeatedly until there's an "abort", that
doesn't print anything suspicious.


Might this perhaps be a latent issue in OpenACC 'kernels' plus 'async', now
uncovered by the r264397 "[nvptx] Remove use of CUDA unified memory in libgomp"
commit?

[Bug c++/87863] [9 Regression] c-c++-common/gomp/gridify-{2,3}.c ICE

2018-12-21 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87863

Thomas Schwinge  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #3 from Thomas Schwinge  ---
(In reply to Richard Biener from comment #1)
> Guess it needs --enable-hsa or so?

"--enable-offload-targets=hsa", and I also use "--enable-checking=yes", in case
that's relevant.


(In reply to Martin Jambor from comment #2)
> Mine.

Thanks!

[Bug libgomp/87064] [9 regression] libgomp.oacc-fortran/reduction-3.f90 fails starting with r263751

2018-12-21 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87064

Thomas Schwinge  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-12-21
 Ever confirmed|0   |1

--- Comment #9 from Thomas Schwinge  ---
I have not yet myself seen that regression, and there's no obvious error in the
test case.  If vector level reductions generally had some problem, I hope we'd
seen things FAIL more widely.  Strange.

(In reply to seurer from comment #0)
> Note this fails on powerpc64 le but not be
> 
> # of expected passes  11
> # of unexpected failures  1
> FAIL: libgomp.oacc-fortran/reduction-3.f90 -DACC_DEVICE_TYPE_host=1
> -DACC_MEM_SHARED=1  -O1  execution test

You're (still?) reproducibly seeing that problem?

[Bug libgomp/88495] An OpenACC async queue is always synchronized with itself

2018-12-14 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88495

--- Comment #1 from Thomas Schwinge  ---
Author: tschwinge
Date: Fri Dec 14 20:43:02 2018
New Revision: 267152

URL: https://gcc.gnu.org/viewcvs?rev=267152=gcc=rev
Log:
[PR88495] An OpenACC async queue is always synchronized with itself

An OpenACC async queue is always synchronized with itself, so invocations like
"#pragma acc wait(0) async(0)", or "acc_wait_async (0, 0)" don't make a lot of
sense, but are still valid.

libgomp/
PR libgomp/88495
* plugin/plugin-nvptx.c (nvptx_wait_async): Don't refuse
"identical parameters".
* testsuite/libgomp.oacc-c-c++-common/asyncwait-nop-1.c: Update.
* testsuite/libgomp.oacc-c-c++-common/lib-80.c: Remove.

Removed:
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-80.c
Modified:
trunk/libgomp/ChangeLog
trunk/libgomp/plugin/plugin-nvptx.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/asyncwait-nop-1.c

[Bug libgomp/88484] OpenACC wait directive without wait argument but with async clause

2018-12-14 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88484

--- Comment #1 from Thomas Schwinge  ---
Author: tschwinge
Date: Fri Dec 14 20:42:50 2018
New Revision: 267151

URL: https://gcc.gnu.org/viewcvs?rev=267151=gcc=rev
Log:
[PR88484] OpenACC wait directive without wait argument but with async clause

We don't correctly handle "#pragma acc wait async (a)" for "a >= 0", handling
as a no-op whereas it should enqueue the appropriate wait operations on
"async (a)".

libgomp/
PR libgomp/88484
* oacc-parallel.c (GOACC_wait): Correct handling for "async >= 0".
* testsuite/libgomp.oacc-c-c++-common/asyncwait-nop-1.c: New file.

Added:
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/asyncwait-nop-1.c
Modified:
trunk/libgomp/ChangeLog
trunk/libgomp/oacc-parallel.c

  1   2   3   4   5   >