[Bug testsuite/80221] Contrib script to rewrite testcase from absolute to relative line numbers

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80221

--- Comment #9 from Thomas Schwinge  ---
You could further optimize the script to omit "." locations: if the "dg-*"
directive actually is placed on the appropriate line already.

[Bug testsuite/80092] Add effective-target keywords for unsupported nvptx features

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80092

Thomas Schwinge  changed:

   What|Removed |Added

 Target||nvptx
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-23
 Ever confirmed|0   |1

--- Comment #2 from Thomas Schwinge  ---
(In reply to Tom de Vries from comment #0)
> Atm, when running for target nvptx, we run into unsupported features in the
> tests.
> 
> F.i. in the g++ testsuite:
> ...
> $ grep -c "sorry, unimplemented:" g++.log 
> 12693
> ...

... a lot...

> more in detail:
> ...
> $ grep "sorry, unimplemented:" g++.log | sed 's/.*sorry, unimplemented://' |
> dos2unix | sort -u 
>  converting lambda which uses '...' to function pointer
>  global constructors not supported on this target
>  global destructors not supported on this target
>  indirect jumps are not available on this target
>  mangling __underlying_type
>  non-trivial designated initializers not supported
>  passing arguments to ellipsis of inherited constructor 'B::B(int, ...)
> [inherited from A]'
>  target cannot support alloca.
>  target cannot support nonlocal goto.
> ...
> 
> All those tests are FAILs, while they should be UNSUPPORTED.
> 
> In principle, having those as FAILs is not a problem when regression
> testing. We can compare tests results, and only look at changes.
> 
> But it's better to introduce effective-target keywords for those features,
> and mark the tests as such. That will reduce the noise rate because of
> unsupported features being used or not due to code generation changes.

But that will be a rather huge effort to do -- and to keep up to date.  Is that
really worth it?

[Bug sanitizer/77631] no symbols in backtrace shown by ASan when debug info is split

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77631

--- Comment #8 from Thomas Schwinge  ---
(In reply to myself from comment #6)
> This has been (with low priority) on my long TODO list
> for some time: ever since I started using -gsplit-dwarf and noticed that
> GCC's Internal Compiler Error (ICE) backtraces no longer were as useful as
> they used to be -- at least I suppose that's the very same underlying issue.

Well, as it turns out, reading the *.dwo files generated by -gsplit-dwarf is
actually a different issue than the "debuglink" case discussed here.  So,
that's to stay on my long TODO list for a little longer...  ;-)

[Bug target/79939] [nvptx] gcc hangs in nvptx_assemble_value

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79939

Thomas Schwinge  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-03-15
   Assignee|unassigned at gcc dot gnu.org  |vries at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug target/80035] [nvptx] non-returning function call causes ptxas sigsegv

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80035

Thomas Schwinge  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-03-15
   Assignee|unassigned at gcc dot gnu.org  |vries at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug sanitizer/77631] no symbols in backtrace shown by ASan when debug info is split

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77631

Thomas Schwinge  changed:

   What|Removed |Added

 CC||tschwinge at gcc dot gnu.org

--- Comment #6 from Thomas Schwinge  ---
Denis, very nice!  This has been (with low priority) on my long TODO list for
some time: ever since I started using -gsplit-dwarf and noticed that GCC's
Internal Compiler Error (ICE) backtraces no longer were as useful as they used
to be -- at least I suppose that's the very same underlying issue.  (To
verify/confirm, I'll later test your patch unless somebody else beats me to
it.)

[Bug translation/79638] Wrongly extracted source string "tid.y;"

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79638

Thomas Schwinge  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||tschwinge at gcc dot gnu.org
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |tschwinge at gcc dot 
gnu.org

--- Comment #1 from Thomas Schwinge  ---
Fixed in r245623.  (But I have not regenerated the gcc.pot file.)

[Bug other/79543] New: Inappropriate "ld --version" checking

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79543

Bug ID: 79543
   Summary: Inappropriate "ld --version" checking
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: jakub at gcc dot gnu.org, jsm28 at gcc dot gnu.org
  Target Milestone: ---

libgomp (and, from a quick scan, also other places of GCC/other target
libraries) conditionally use certain linker features, depending on linker
version numbers.  For example, linker version scripts in libgomp; see
LIBGOMP_BUILD_VERSIONED_SHLIB, LIBGOMP_BUILD_VERSIONED_SHLIB_GNU usage in
libgomp/Makefile.am, which are defined in libgomp/acinclude.m4 based on the
enable_symvers value, which is set by some logic depending on "ld --version"
output.  Looking at one specific build's libgomp/config.log, I see:

[...]
configure:16132: checking if the linker ([...]/gcc/collect-ld) is GNU ld
configure:16147: result: yes
[...]
configure:16389: WARNING: === Linker version 1125 is too old for
configure:16391: WARNING: === full symbol versioning support in this
release of GCC.
configure:16393: WARNING: === You would need to upgrade your binutils to
version
configure:16395: WARNING: === 21400 or later and rebuild GCC.
configure:16404: WARNING: === Symbol versioning will be disabled.
[...]

Now, what is this "1125" linker version?

$ [...]/gcc/collect-ld --version
GNU ld (Sourcery CodeBench ([...]) Lite 2015.11-[...]) 2.25.51

..., and then apply the "magic" used in libgomp/acinclude.m4 to compute
libgomp_gnu_ld_version:

$ [...]/gcc/collect-ld --version | sed -e 's/GNU gold /GNU ld /;s/GNU ld
version /GNU ld /;s/GNU ld ([^)]*) /GNU ld /;s/GNU ld \([0-9.][0-9.]*\).*/\1/;
q' | awk -F. '{ if (NF<3) $3=0; print ($1*100+$2)*100+$3 }'
1125

"1125" instead of the expected "22551".  That's pretty weird, and I suppose it
may be causing all kinds of "interesting" issues, when using a linker that has
been configured to override/augment its version string?

Joseph told me that "the correct logic for finding the version number is to
take everything after the last space on the first line of the output, as per
the GNU Coding Standards.  (It's possible some very old binutils versions may
not have properly formatted output; my view is that each GCC version should
have a minimum corresponding binutils version, no more than say five years old,
for targets using GNU binutils.)"

Yet better, obviously, would be to not rely on such version-based decisions at
all.

(Hopefully, similar parsing is not also being done for "as --version", or other
tools, and this was just a one-off problem, possibly originally introduced in
libstdc++-v3/acinclude.m4, 15 years ago, and the copied from there to other
target libraries?  I haven't looked in detail.)


(For reference, this is the root cause for the issue reported in
<http://mid.mail-archive.com/6351bfaf-d64e-5f73-9749-78b469dba5fa@mentor.com>.)

[Bug translation/79332] Several bugs related to translation in gcc 7.1-b20170101

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79332

Thomas Schwinge  changed:

   What|Removed |Added

 CC||tschwinge at gcc dot gnu.org

--- Comment #5 from Thomas Schwinge  ---
I had already raised the config/nvptx/nvptx.c "tid.y" issue in
<http://mid.mail-archive.com/87inpofbl6.fsf@euler.schwinge.homeip.net>.

(In reply to jos...@codesourcery.com from comment #4)
> That would be the %e / %n extraction intended for spec strings.  In this 
> case, I think splitting the string constant between the % and the n should 
> avoid the %n extraction without affecting the actual use of this string.

Seems like a nice, nonintrusive solution (to be accompanied with a comment
about the string splitting).  I'll send a patch for that one.

[Bug middle-end/79236] [7 Regression] Many libgomp tests fail if configured with --enable-offload-targets=nvptx-none but NVidia HW or libcuda.so.1 unavailable

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79236

Thomas Schwinge  changed:

   What|Removed |Added

 CC||tschwinge at gcc dot gnu.org

--- Comment #5 from Thomas Schwinge  ---
For the record: ever since the OpenMP nvptx offloading patches got committed
(specifically, probably after "OpenMP loop cloning for SIMT execution"), I had
seen for -m32 multilib testing of a x86_64-linux-gnu configuration the same set
of FAILs described in comment0.  Confirming that this is now also resolved in
r244924, thanks.

[Bug c/79227] New: Questionable -Wmisleading-indentation diagnostic in HSAIL-Tools

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79227

Bug ID: 79227
   Summary: Questionable -Wmisleading-indentation diagnostic in
HSAIL-Tools
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: dmalcolm at gcc dot gnu.org, ppalka at gcc dot gnu.org
  Target Milestone: ---

Created attachment 40576
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40576=edit
reduced "HSAILValidatorBase.cpp" file

I don't have any strong opinion, so I'm asking you to please check the
following.

Compiling <https://github.com/HSAFoundation/HSAIL-Tools>, commit
12220b0ddccd4559e979906bfd65fb49fcdd7854 with Ubuntu GCC 6.2.0-5ubuntu12, the
build aborts:

[...]/libHSAIL/HSAILValidatorBase.cpp: In member function 'virtual bool
HSAIL_ASM::PropValidator::checkOperandKind(HSAIL_ASM::Inst, unsigned int,
unsigned int*, unsigned int, bool) const':
[...]/libHSAIL/HSAILValidatorBase.cpp:395:37: error: this 'if' clause does
not guard... [-Werror=misleading-indentation]
 case OPERAND_VAL_FUNC:  if (isCodeRef(opr,
BRIG_KIND_DIRECTIVE_FUNCTION) ||
 ^~
[...]/libHSAIL/HSAILValidatorBase.cpp:396:110: note: ...this statement, but
the latter is misleadingly indented as if it is guarded by the 'if'
 isCodeRef(opr,
BRIG_KIND_DIRECTIVE_INDIRECT_FUNCTION))  return true; break;
   
  ^
cc1plus: all warnings being treated as errors

I'm attaching a reduced "HSAILValidatorBase.cpp" file, showing the issue for
both C and C++ compilation.

Should the code be considered well-formed enough to not warn in this case?

[Bug target/78875] -fstack-protector on powerpc64 now always use TLS, won't work for kernel/firmware

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78875

Thomas Schwinge  changed:

   What|Removed |Added

 CC||tschwinge at gcc dot gnu.org

--- Comment #3 from Thomas Schwinge  ---
See also PR29838.

[Bug target/29838] -fstack-protector shouldn't use TLS in freestanding mode

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29838

--- Comment #12 from Thomas Schwinge  ---
See also PR78875.

[Bug tree-optimization/78024] [7 regression] test cases gfortran.dg/goacc/routine-4.f90 and also routine-5.f90 fail starting with r241296

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78024

--- Comment #9 from Thomas Schwinge  ---
Author: tschwinge
Date: Tue Jan 10 13:02:00 2017
New Revision: 244265

URL: https://gcc.gnu.org/viewcvs?rev=244265=gcc=rev
Log:
[PR tree-optimization/78024] Clear basic block flags before using BB_VISITED
for OpenACC loops processing

Backport from gcc-6-branch r244264:

gcc/
2017-01-10  Thomas Schwinge  

PR tree-optimization/78024
* omp-low.c (oacc_loop_discovery): Call clear_bb_flags.

Backport from trunk r241334:

gcc/testsuite/
2016-10-19  Thomas Schwinge  

PR tree-optimization/78024
* gcc.dg/goacc/loop-processing-1.c: New file.

Added:
branches/gomp-4_0-branch/gcc/testsuite/gcc.dg/goacc/loop-processing-1.c
Modified:
branches/gomp-4_0-branch/gcc/ChangeLog.gomp
branches/gomp-4_0-branch/gcc/omp-low.c
branches/gomp-4_0-branch/gcc/testsuite/ChangeLog.gomp

[Bug tree-optimization/78024] [7 regression] test cases gfortran.dg/goacc/routine-4.f90 and also routine-5.f90 fail starting with r241296

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78024

--- Comment #8 from Thomas Schwinge  ---
Author: tschwinge
Date: Tue Jan 10 13:00:31 2017
New Revision: 244264

URL: https://gcc.gnu.org/viewcvs?rev=244264=gcc=rev
Log:
[PR tree-optimization/78024] Clear basic block flags before using BB_VISITED
for OpenACC loops processing

gcc/
PR tree-optimization/78024
* omp-low.c (oacc_loop_discovery): Call clear_bb_flags.

Backport from trunk r241334:

gcc/testsuite/
2016-10-19  Thomas Schwinge  

PR tree-optimization/78024
* gcc.dg/goacc/loop-processing-1.c: New file.

Added:
branches/gcc-6-branch/gcc/testsuite/gcc.dg/goacc/loop-processing-1.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/omp-low.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug target/78831] New: [nvptx] -mgomp -Os init_softstack_frame ICE

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78831

Bug ID: 78831
   Summary: [nvptx] -mgomp -Os init_softstack_frame ICE
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: amonakov at gcc dot gnu.org
  Target Milestone: ---
Target: nvptx

For nvptx' "mgomp" multilib, some change in (r242761,r243672] is causing a
number of "-Os" test cases to run into an ICE, for example:

$ build-gcc/gcc/xgcc -Bbuild-gcc/gcc/ -c
source-gcc/gcc/testsuite/gcc.c-torture/compile/20020604-1.c -Os -mgomp
source-gcc/gcc/testsuite/gcc.c-torture/compile/20020604-1.c: In function
'foo':
source-gcc/gcc/testsuite/gcc.c-torture/compile/20020604-1.c:91:1: internal
compiler error: in init_softstack_frame, at config/nvptx/nvptx.c:1051
 }
 ^
0xe73417 init_softstack_frame
[...]/source-gcc/gcc/config/nvptx/nvptx.c:1051
0xe73417 nvptx_declare_function_name(_IO_FILE*, char const*, tree_node
const*)
[...]/source-gcc/gcc/config/nvptx/nvptx.c:1238
0xe537e0 assemble_start_function(tree_node*, char const*)
[...]/source-gcc/gcc/varasm.c:1835
0x7fe8f7 rest_of_handle_final
[...]/source-gcc/gcc/final.c:4473
0x7fe8f7 execute
[...]/source-gcc/gcc/final.c:4548

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

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78027

Thomas Schwinge  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
  Component|fortran |ipa
   Assignee|unassigned at gcc dot gnu.org  |cesar at gcc dot gnu.org

--- Comment #3 from Thomas Schwinge  ---
.

[Bug middle-end/78153] strlen return value can be assumed to be less than PTRDIFF_MAX

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78153

Thomas Schwinge  changed:

   What|Removed |Added

 CC||tschwinge at gcc dot gnu.org

--- Comment #4 from Thomas Schwinge  ---
(In reply to Andreas Schwab from comment #2)
> raised STORAGE_ERROR : stack overflow or erroneous memory access
> make[3]: *** [../../gcc/ada/gcc-interface/Make-lang.in:119: ada/osint.o]
> Error 1

This presumably has been addressed in PR78501.

[Bug other/70945] Offloading: compatibility of target and offloading toolchains

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70945

--- Comment #6 from Thomas Schwinge  ---
Author: tschwinge
Date: Wed Oct 19 21:24:37 2016
New Revision: 241355

URL: https://gcc.gnu.org/viewcvs?rev=241355=gcc=rev
Log:
[PR other/70945] Handle function_glibc_finite_math in offloading

gcc/
PR other/70945
* targhooks.c (default_libc_has_function): Update comment.
* target.def (libc_has_function): Likewise.
* doc/tm.texi: Regenerate.
* coretypes.h (enum function_class): Add
function_glibc_finite_math.
* config/darwin.c (darwin_libc_has_function): Handle it.
* lto-streamer.h (enum lto_section_type): Rename
LTO_section_offload_table to LTO_section_offload_data.  Adjust all
users.
* lto-cgraph.c (void output_offload_data): New function, split out
of output_offload_tables.  Adjust all users.  Stream the target's
function_glibc_finite_math property.
(input_offload_data): New function, split out of
input_offload_tables.  Adjust all users.  Handle mismatch between
the target's and the offloading target's
function_glibc_finite_math property.
libgomp/
PR other/70945
* testsuite/libgomp.oacc-c-c++-common/pr70945-1.c: New file.

Added:
   
branches/gomp-4_0-branch/libgomp/testsuite/libgomp.oacc-c-c++-common/pr70945-1.c
Modified:
branches/gomp-4_0-branch/gcc/ChangeLog.gomp
branches/gomp-4_0-branch/gcc/config/darwin.c
branches/gomp-4_0-branch/gcc/coretypes.h
branches/gomp-4_0-branch/gcc/doc/tm.texi
branches/gomp-4_0-branch/gcc/lto-cgraph.c
branches/gomp-4_0-branch/gcc/lto-streamer-out.c
branches/gomp-4_0-branch/gcc/lto-streamer.h
branches/gomp-4_0-branch/gcc/lto/lto.c
branches/gomp-4_0-branch/gcc/target.def
branches/gomp-4_0-branch/gcc/targhooks.c
branches/gomp-4_0-branch/libgomp/ChangeLog.gomp

[Bug libfortran/74755] libgfortran: build breaks if localtime_r prototype is present, but definition is not

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=74755

Thomas Schwinge  changed:

   What|Removed |Added

 Status|WAITING |SUSPENDED
 CC||nathan at gcc dot gnu.org,
   ||tschwinge at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |tschwinge at gcc dot 
gnu.org

--- Comment #3 from Thomas Schwinge  ---
Nathan applied a workaround in trunk r239836,
<https://gcc.gnu.org/ml/gcc-patches/2016-08/msg01993.html>.

(For the record, at least with a "combined" source tree, you don't explicitly
have to configure --with-newlib to make this work, as --with-newlib will be
passed by the build system.)

I still think this should really be fixed in newlib, and that the configure
auto-detection should be re-enabled then.

Nathan's trunk r239836 caused the following changes in
[build]/nvptx-none/libgfortran/config.h:

 /* Define to 1 if you have the `gmtime_r' function. */
-/* #undef HAVE_GMTIME_R */
+#define HAVE_GMTIME_R 1

 /* Define to 1 if you have the `localtime_r' function. */
-/* #undef HAVE_LOCALTIME_R */
+#define HAVE_LOCALTIME_R 1

 /* Define to 1 if you have the `mkstemp' function. */
-/* #undef HAVE_MKSTEMP */
+#define HAVE_MKSTEMP 1

 /* Define to 1 if you have the `strtold' function. */
-#define HAVE_STRTOLD 1
+/* #undef HAVE_STRTOLD */

..., accompanied by a few test case regressions, because some of these
hardwired routines are not actually available in the nvptx newlib port.

[Bug lto/77458] nvptx offloading ICEs after "Implement C _FloatN, _FloatNx types"

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77458

Thomas Schwinge  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Thomas Schwinge  ---
Fixed in r241338.

[Bug lto/77458] nvptx offloading ICEs after "Implement C _FloatN, _FloatNx types"

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77458

--- Comment #1 from Thomas Schwinge  ---
Author: tschwinge
Date: Wed Oct 19 10:48:46 2016
New Revision: 241338

URL: https://gcc.gnu.org/viewcvs?rev=241338=gcc=rev
Log:
[PR lto/77458] Avoid ICE in offloading with differing _FloatN, _FloatNx types

gcc/
PR lto/77458
* tree-core.h (enum tree_index): Put the complex types after their
component types.
* tree-streamer.c (verify_common_node_recorded): New function.
(preload_common_nodes) : Use it.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-core.h
trunk/gcc/tree-streamer.c

[Bug tree-optimization/78024] [7 regression] test cases gfortran.dg/goacc/routine-4.f90 and also routine-5.f90 fail starting with r241296

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78024

Thomas Schwinge  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from Thomas Schwinge  ---
(In reply to rguent...@suse.de from comment #6)
> On Wed, 19 Oct 2016, tschwinge at gcc dot gnu.org wrote:
> > (In reply to Richard Biener from comment #4)
> > > Well, must be another missing BB_VISITED clearing then.
> > 
> > I wonder why you didn't see that regression in your testing?
> 
> I did but didn't thought it was my patch (oacc should be unrelated).

Well, compiler optimizations also work for (and, occasionally break) OpenACC
code.  ;-)

> I also assumed the posted patch was already committed (as I approved it)

Committed in r241334.

[Bug tree-optimization/78024] [7 regression] test cases gfortran.dg/goacc/routine-4.f90 and also routine-5.f90 fail starting with r241296

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78024

Thomas Schwinge  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #5 from Thomas Schwinge  ---
(In reply to myself from comment #3)
> I'll have a look later today, but if someone is able to do so now, please
> verify whether 
> does fix this issue?

It does.  Asking once again: OK to commit?

(In reply to Richard Biener from comment #4)
> Well, must be another missing BB_VISITED clearing then.

I wonder why you didn't see that regression in your testing?

[Bug tree-optimization/78024] [7 regression] test cases gfortran.dg/goacc/routine-4.f90 and also routine-5.f90 fail starting with r241296

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78024

Thomas Schwinge  changed:

   What|Removed |Added

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

--- Comment #3 from Thomas Schwinge  ---
I'll have a look later today, but if someone is able to do so now, please
verify whether <https://gcc.gnu.org/ml/gcc-patches/2016-10/msg01478.html> does
fix this issue?

[Bug lto/77954] New: LTO_STREAMER_DEBUG ICE with OpenMP SIMD clones

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77954

Bug ID: 77954
   Summary: LTO_STREAMER_DEBUG ICE with OpenMP SIMD clones
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: openmp
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: jakub at gcc dot gnu.org, rguenth at gcc dot gnu.org
  Target Milestone: ---

If you enable gcc/lto-streamer.h:LTO_STREAMER_DEBUG, the
libgomp.fortran/declare-simd-4.f90 test case will run into an ICE, because of
gcc/lto-streamer.c:lto_orig_address_remove failing in "gcc_assert (slot)".

If Intel MIC (emulated) offloading is enabled,
libgomp.c/examples-4/declare_target-5.c and
libgomp.fortran/examples-4/declare_target-5.f90 fail in the same way.

I have not analyzed whether that is a real problem, or "just" a problem with
LTO_STREAMER_DEBUG -- but bootstrap build and full testsuite run with
LTO_STREAMER_DEBUG enabled doesn't exhibit any additional problems.

[Bug fortran/77371] [6/7 Regression] ICE in force_constant_size, at gimplify.c:671 (... and others)

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77371

Thomas Schwinge  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #5 from Thomas Schwinge  ---
.

[Bug fortran/74600] [openacc] duplicate data map error

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=74600

Thomas Schwinge  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Thomas Schwinge  ---
Cesar posted patch: ,
waiting for review.

[Bug fortran/72743] ICE in get_constraint_for_ssa_var, at tree-ssa-structalias.c:2958

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72743

Thomas Schwinge  changed:

   What|Removed |Added

   Keywords||openacc
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |cltang at gcc dot 
gnu.org

--- Comment #7 from Thomas Schwinge  ---
Patch review in .

[Bug fortran/74600] [openacc] duplicate data map error

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=74600

Thomas Schwinge  changed:

   What|Removed |Added

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

[Bug lto/77458] New: nvptx offloading ICEs after "Implement C _FloatN, _FloatNx types"

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77458

Bug ID: 77458
   Summary: nvptx offloading ICEs after "Implement C _FloatN,
_FloatNx types"
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: openacc
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: tschwinge at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: jakub at gcc dot gnu.org, jsm28 at gcc dot gnu.org
  Target Milestone: ---

As of the PR32187 commit r239625 "Implement C _FloatN, _FloatNx types", nvptx
offloading is broken, ICEs in LTO stream-in.  Probably some kind of data-type
mismatch that is not visible with Intel MIC offloading (using the same data
types) but explodes with nvptx.  I'm having a look.

[Bug fortran/74600] [openacc] duplicate data map error

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=74600

Thomas Schwinge  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-08-12
 Ever confirmed|0   |1

--- Comment #1 from Thomas Schwinge  ---
(In reply to cesar from comment #0)
> This issue is present on at least gomp-4_0-branch with nvptx offloading. I
> wasn't able to try trunk because it stopped building on nvptx as of Aug 11,

Yep, PR74755.

> so I'll retest trunk once that problem has been resolved.

So just test a trunk revision a little earlier ;-) -- anyway, confirmed for
trunk, too.  (I have not looked at the Fortran source code file itself.)

[Bug libfortran/74755] New: libgfortran: build breaks if localtime_r prototype is present, but definition is not

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=74755

Bug ID: 74755
   Summary: libgfortran: build breaks if localtime_r prototype is
present, but definition is not
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: cesar at gcc dot gnu.org
  Target Milestone: ---
Target: nvptx

As of GCC trunk r239356 "Replace KISS PRNG with xorshift1024* using per-thread
state", libgfortran/intrinsics/random.c fails to build when using nvptx-newlib,
<https://github.com/MentorEmbedded/nvptx-newlib>:

In file included from
[...]/source-gcc/libgfortran/intrinsics/random.c:41:0:
[...]/source-gcc/libgfortran/intrinsics/time_1.h:92:1: error: static
declaration of 'localtime_r' follows non-static declaration
 localtime_r (const time_t * timep, struct tm * result)
 ^~~
In file included from [...]/source-gcc/newlib/libc/include/stdio.h:29:0,
 from [...]/source-gcc/libgfortran/libgfortran.h:42,
 from [...]/source-gcc/libgfortran/intrinsics/random.c:27:
[...]/source-gcc/newlib/libc/include/time.h:69:12: note: previous
declaration of 'localtime_r' was here
 struct tm *_EXFUN(localtime_r, (const time_t *__restrict,
^
make[3]: *** [random.lo] Error 1

libgfortran/configure doesn't "#define HAVE_LOCALTIME_R", because of:

unresolved symbol localtime_r
collect2: error: ld returned 1 exit status

..., and thus libgfortran/intrinsics/time_1.h attempts to provide "static
inline" replacement code, but that (unsurprisingly; "static inline" vs.
"extern") has a conflicting signature to the prototype in nvptx-newlib header
files, where a prototype of localtime_r is declared despite not providing a
definition.

I suppose that needs to be fixed in nvptx-newlib, unless this (localtime_r
prototype present, but definition not) is a configuration that needs to be
supported in libgfortran?

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

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72741

Thomas Schwinge  changed:

   What|Removed |Added

   Assignee|cesar at gcc dot gnu.org   |tschwinge at gcc dot 
gnu.org

--- Comment #7 from Thomas Schwinge  ---
<https://gcc.gnu.org/ml/gcc-patches/2016-08/msg00932.html>.

(In reply to cesar from comment #6)
> a) The fortran pretty printer doesn't know about generic tree notes.
> Consequently, I don't think build_oacc_routine_dims would be able to report
> any errors unless we add support for tree notes in that pretty printer.

I've not (yet?) into any such problems.  Phew.  ;-)

> b) The fortran FE handle errors slightly differently from the c FE. Instead
> of catching the error early and aborting immediately, you're method will
> defer the error handling to after the FE has parsed everything. I'm not sure
> if this is a problem or not.

It seems to work fine, and, as discussed, something like that will be needed
anyway, once we get to support the OpenACC device_type clause.

> c) That oacc_function information needs to be captured for fortran module
> .mod files, and those .mod files don't require tree node attributes.
> Postponing that attribute requires separate functions to manipulate the
> routine clauses.

ACK.  Still very much TODO in my WIP patch.

> d) gfc_oacc_routine_dims is already creating an oacc_function attribute for
> routines. This attribute is a single enum instead of the individual clauses.
> I like that because its more self contained.

As discussed, it actually seems easier conceptually (maybe not in terms of
"boilerplate code") to handle these separately, and we need to do that for
being able to generate the desired compile-time diagnostics.

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

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72741

--- Comment #5 from Thomas Schwinge  ---
(In reply to cesar from comment #4)
> I could be mistaken, but I don't think there's anything we can do about that
> test case because fortran doesn't have file scope. Specifically, in your
> example,
> 
> SUBROUTINE r_w
>   IMPLICIT NONE
>   INTEGER :: i
>   !$ACC ROUTINE WORKER
> 
>   !$ACC LOOP
>   DO i = 1, 12345
>   END DO
> END SUBROUTINE r_w
> 
> PROGRAM main
>   IMPLICIT NONE
>   EXTERNAL :: r_w
>   !$ACC ROUTINE (r_w) GANG
> 
>   !$ACC PARALLEL
>   CALL r_w
>   !$ACC END PARALLEL
> END PROGRAM main
> 
> from program main's perspective, r_w should be an acc routine with a gang
> attribute, but that's only because the end user included an explicit
> 'external' function declaration. I'm not sure how to catch mismatched
> function declarations in fortran

Maybe I'm assuming too much about the Fortran front end, but I assumed that the
"SUBROUTINE r_w" would create some kind of decl, and the later "!$ACC ROUTINE
(r_w)" would look up some kind of decl (that is, the
gfc_find_function/gfc_find_subroutine/gfc_find_symtree stuff in
gfc_match_oacc_routine), and these decls both have some kind of "attributes"
attached to them, and once these two decls are "paired"/"merged", we can then
see whether these "attributes" match or conflict.  I assume some very similar
verification is done in the Fortran front end for other checking between
definition and use of any kind of routines, for example?

Are you saying that's not how the Fortran front end operates, and the
"SUBROUTINE r_w" and the later "PROGRAM main" do see completly detached "decl
spaces"?  Then indeed, we can't verify this in the Fortran front end, but...

> especially if lto is not enabled. If lto
> is enabled, we could add some more checking in pass oacc_device_lower.

..., as discussed before, something like that is the final goal that I'm
working on, and for that...

> But I
> don't think there's anything else to do in the fortran front end.

..., please implement the changes I asked you to implement in Comment 3, #c3,
or elaborate why that doesn't make sense.

[Bug fortran/72743] ICE in get_constraint_for_ssa_var, at tree-ssa-structalias.c:2958

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72743

Thomas Schwinge  changed:

   What|Removed |Added

   Last reconfirmed|2016-07-29 00:00:00 |2016-8-9
 CC||marxin at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org,
   ||tschwinge at gcc dot gnu.org

--- Comment #4 from Thomas Schwinge  ---
Confirmed.  Probably Dominique's x86_64-apple-darwin15 configuration has
something differently in symbol visibility or some such, which hides this
problem.

Richard, you're probably thinking of PR70856 when you say this sounds familiar.
 Indeed this looks similar, but it's still a new/different problem.  Do you or
Martin (who fixed PR70856) have any plans to look into this issue here?

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

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72741

--- Comment #3 from Thomas Schwinge  ---
Created attachment 39064
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39064=edit
Fortran routine directive with a name

Cesar, thanks for your initial fix.

Please have a look at the new file I'm attaching.  Clearly, the two OpenACC
routine directives are conflicting; this illustrates my earlier point 'from a
quick look it seems as if for a routine directive with a name (such as: "!$acc
routine (function_1) gang"), any clauses specified are generally not evaluated
to determine the specified function's level of parallelism'.  No compiler
diagnostic is being created for that.

Instead of fixing just that specific problem only, please (also) verify and
implement my following ideas (separate patch?).  In early parsing in the front
end, do not check for routine dimension errors (we can't do that anyway, if you
take the device_type clause into account).  That is, remove
gcc/fortran/openmp.c:gfc_oacc_routine_dims.  Instead of the "dims" you compute
from the clauses in gcc/fortran/openmp.c:gfc_match_oacc_routine and save in
attr.oacc_function, just store all clauses (gfc_omp_clauses) in that "attr". 
If that is not feasible (I don't know how "attr" is processed in the following,
also regarding Fortran modules etc.), then have "attr" contain *separate*
members for all clauses that apply to the OpenACC routine directive: gang,
worker, vector, seq, bind, nohost.  Then, move the "multiple loop axes"
checking into gcc/fortran/trans-decl.c:add_attributes_to_decl.  As this
function has access to all gfc_omp_clauses corresponding to the decl (or, at
least all individual OpenACC routine clauses), this should then ideally just
call gcc/fortran/trans-openmp.c:gfc_trans_omp_clauses to translate the Fortran
OMP clauses representation into OMP_CLAUSE trees.  (Notice that on
gomp-4_0-branch, gcc/fortran/trans-decl.c:add_attributes_to_decl already
contains some incomplete, ad-hoc code to handle the nohost clause; you can
ignore that stuff for the moment -- if you put the infrastructure in place for
the clauses specifying the level of parallelism, we can then later add
bind/nohost handling.)  Instead of the manual "oacc function" attribute
construction, then call gcc/omp-low.c:build_oacc_routine_dims and
gcc/omp-low.c:replace_oacc_fn_attrib, as I had commented earlier.

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

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72741

Thomas Schwinge  changed:

   What|Removed |Added

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

[Bug middle-end/72781] New: -Wuninitialized false positives in OpenMP code

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72781

Bug ID: 72781
   Summary: -Wuninitialized false positives in OpenMP code
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Keywords: openmp
  Severity: minor
  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: ---

Perhaps similar to PR70550, I found another case of -Wuninitialized false
positives in OpenMP code (at least given my limited understanding of the OpenMP
clauses involved here): for example, when compiling
libgomp/testsuite/libgomp.fortran/simd3.f90 you'll see:

[...]/libgomp.fortran/simd3.f90:58:0: Warning: 'v' may be used
uninitialized in this function [-Wmaybe-uninitialized]
[...]/libgomp.fortran/simd3.f90:54:0: note: 'v' was declared here
[...]/libgomp.fortran/simd3.f90:58:0: Warning: 'u' may be used
uninitialized in this function [-Wmaybe-uninitialized]
[...]/libgomp.fortran/simd3.f90:54:0: note: 'u' was declared here
[...]

54  integer :: p(1024), u, v, i, s, foo
55  s = 0
56  !$omp parallel
57  !$omp do simd linear(k : m + 1) reduction(+: s) lastprivate(u, v) &
58  !$omp & schedule (static, 32)
59  do i = 1, 1024
60a(i) = a(i) * p(i)
61u = p(i) + k
62k = k + m + 1
63v = p(i) + k
64s = s + p(i) + k
65  end do
66  !$omp end do simd
67  !$omp end parallel

(Let me again raise my suggestion to actually run the libgomp testsuite with
-Wall...)

In the "gimple" dump I see "shared" clauses be added on the "omp parallel"
construct for variables referenced inside it -- I guess that's where the
warning originates?  This will be easier to resolve for someone who has a
better understanding of these OpenMP clauses.

[Bug middle-end/70895] OpenACC: loop reduction does not work. Output is zero.

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70895

Thomas Schwinge  changed:

   What|Removed |Added

 Status|WAITING |ASSIGNED
 CC||cltang at gcc dot gnu.org
  Component|fortran |middle-end
   Assignee|tschwinge at gcc dot gnu.org   |cltang at gcc dot 
gnu.org

--- Comment #5 from Thomas Schwinge  ---
We've gotten that aspect of the OpenACC specification clarified as follows
(comments inside parens are mine): "A scalar variable referenced in a parallel
construct without predetermined (already implemented) or explicitly determined
data attributes (already implemented) will have its data attributes implicitly
determined as described in this paragraph. If the scalar variable appears in a
reduction clause on the parallel construct (already implemented), or in a
reduction clause on a loop construct in the parallel construct (relevant for
this PR70895), or is assigned in an atomic construct in the parallel construct
(another change), the scalar variable is treated as if it appeared in a copy
clause for the parallel construct. In all other cases, the scalar variable is
treated as if it appeared in a firstprivate clause for the parallel construct
(already implemented)."

Chung-Lin, please sanity-check that this will make work Ralph's example program
as attached, and then implement these semantics for trunk, gcc-6-branch,
gomp-4_0-branch (gcc/gimplify.c; hopefully the same patch will do for all three
branches; please shout if not).  In addition to Ralph's example program as
attached, also add ample testsuite coverage, for various nesting of OpenACC
constructs, for all of C, C++, and Fortran.

If the change is non-trivial to detect that a "scalar variable [...] is
assigned in an atomic construct" ("another change" above), please leave that
aspect aside for the moment.

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

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72741

Bug ID: 72741
   Summary: Fortran OpenACC routine directive doesn't properly
handle clauses specifying the level of parallelism
   Product: gcc
   Version: 7.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: ---

Created attachment 39028
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39028=edit
Fortran test case

The Fortran OpenACC routine directive doesn't diagnose if there are clauses
specifying conflicting levels of parallelism (such as: "!$acc routine gang
worker").  Also, from a quick look it seems as if for a routine directive with
a name (such as: "!$acc routine (function_1) gang"), any clauses specified are
generally not evaluated to determine the specified function's level of
parallelism.

(Note that unless Cesar's recent
<http://news.gmane.org/find-root.php?message_id=%3C5776D55A.4030002%40codesourcery.com%3E>
"[PATCH] OpenACC routines in fortran modules" is applied, a routine directive
for intrinsic functions (such as: "!$acc routine (ABORT) seq") will be
generally flagged as invalid.)

[Bug libgomp/71959] [OpenACC] #pragma acc parallel leads to segfault in x86_64-pc-linux-gnu-accel-nvptx-none-gcc

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71959

Thomas Schwinge  changed:

   What|Removed |Added

   Keywords||openacc
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-07-27
 CC||cesar at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #4 from Thomas Schwinge  ---
Yes, unfortunately, C++ reference data types are not yet supported.  Can you
implement this differently?  It's on the TODO list.

[Bug middle-end/71893] New: gfortran.dg ICEs in gcc/tree-ssa-pre.c; -fcode-hoisting?

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71893

Bug ID: 71893
   Summary: gfortran.dg ICEs in gcc/tree-ssa-pre.c;
-fcode-hoisting?
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org, steven at gcc dot gnu.org
  Target Milestone: ---
Target: nvptx

Testing gfortran.dg for nvptx-none on r238326, there are a number of ICEs in
gcc/tree-ssa-pre.c.  I reproduced "gfortran.dg/bounds_check_10.f90 -O2"
manually, and the ICE disappears when reverting r238242, or when specifying
-fno-code-hoisting.  (Of course, it may be a latent issue, just now exposed by
-fcode-hoisting.)

Program received signal SIGSEGV, Segmentation fault.
0x00cfcb6e in get_expr_value_id (expr=expr@entry=0x0) at
[...]/source-gcc/gcc/tree-ssa-pre.c:682
682   switch (expr->kind)
(gdb) bt
#0  0x00cfcb6e in get_expr_value_id (expr=expr@entry=0x0) at
[...]/source-gcc/gcc/tree-ssa-pre.c:682
#1  0x00d058a2 in find_or_generate_expression
(block=block@entry=0x768f2680, op=op@entry=0x7697f3a0,
stmts=stmts@entry=0x7fffca70) at [...]/source-gcc/gcc/tree-ssa-pre.c:2672
#2  0x00d06454 in create_component_ref_by_pieces_1
(block=block@entry=0x768f2680, ref=ref@entry=0x17ef190,
operand=operand@entry=0x7fffc82c, stmts=stmts@entry=0x7fffca70) at
[...]/source-gcc/gcc/tree-ssa-pre.c:2590
#3  0x00d06190 in create_component_ref_by_pieces_1
(block=block@entry=0x768f2680, ref=ref@entry=0x17ef190,
operand=operand@entry=0x7fffc82c, stmts=stmts@entry=0x7fffca70) at
[...]/source-gcc/gcc/tree-ssa-pre.c:2556
#4  0x00d05f42 in create_component_ref_by_pieces_1
(block=block@entry=0x768f2680, ref=ref@entry=0x17ef190,
operand=operand@entry=0x7fffc82c, stmts=stmts@entry=0x7fffca70) at
[...]/source-gcc/gcc/tree-ssa-pre.c:2514
#5  0x00d06647 in create_component_ref_by_pieces
(block=block@entry=0x768f2680, ref=0x17ef190,
stmts=stmts@entry=0x7fffca70) at [...]/source-gcc/gcc/tree-ssa-pre.c:2657
#6  0x00d06a45 in create_expression_by_pieces
(block=block@entry=0x768f2680, expr=0x190a088,
stmts=stmts@entry=0x7fffca70, type=0x768e2b28) at
[...]/source-gcc/gcc/tree-ssa-pre.c:2799
#7  0x00d08483 in do_hoist_insertion
(block=block@entry=0x768f2680) at [...]/source-gcc/gcc/tree-ssa-pre.c:3541
#8  0x00d0b54e in insert_aux (block=block@entry=0x768f2680,
do_pre=do_pre@entry=true, do_hoist=do_hoist@entry=true) at
[...]/source-gcc/gcc/tree-ssa-pre.c:3615
#9  0x00d0b592 in insert_aux (block=block@entry=0x768f2618,
do_pre=do_pre@entry=true, do_hoist=do_hoist@entry=true) at
[...]/source-gcc/gcc/tree-ssa-pre.c:3622
#10 0x00d0b592 in insert_aux (block=0x768f2548,
do_pre=, do_hoist=) at
[...]/source-gcc/gcc/tree-ssa-pre.c:3622
#11 0x00d0b693 in insert () at
[...]/source-gcc/gcc/tree-ssa-pre.c:3646
#12 0x00d0ba06 in (anonymous namespace)::pass_pre::execute
(this=0x1752760, fun=0x769575e8) at
[...]/source-gcc/gcc/tree-ssa-pre.c:5011
#13 0x00a9b6cd in execute_one_pass (pass=pass@entry=0x1752760) at
[...]/source-gcc/gcc/passes.c:2344
#14 0x00a9bce8 in execute_pass_list_1 (pass=0x1752760) at
[...]/source-gcc/gcc/passes.c:2428
#15 0x00a9bcfa in execute_pass_list_1 (pass=0x17516e0) at
[...]/source-gcc/gcc/passes.c:2429
#16 0x00a9bd45 in execute_pass_list (fn=0x769575e8,
pass=) at [...]/source-gcc/gcc/passes.c:2439
#17 0x007541ad in cgraph_node::expand
(this=this@entry=0x7695d000) at [...]/source-gcc/gcc/cgraphunit.c:1983
#18 0x00755c84 in expand_all_functions () at
[...]/source-gcc/gcc/cgraphunit.c:2119
#19 symbol_table::compile (this=this@entry=0x768d2000) at
[...]/source-gcc/gcc/cgraphunit.c:2475
#20 0x00757e7a in symbol_table::finalize_compilation_unit
(this=0x768d2000) at [...]/source-gcc/gcc/cgraphunit.c:2565
#21 0x00b639ad in compile_file () at
[...]/source-gcc/gcc/toplev.c:490
#22 0x00562eeb in do_compile () at
[...]/source-gcc/gcc/toplev.c:1998
#23 toplev::main (this=this@entry=0x7fffce50, argc=argc@entry=18,
argv=argv@entry=0x7fffcf58) at [...]/source-gcc/gcc/toplev.c:2132
#24 0x00564a87 in main (argc=18, argv=0x7fffcf58) at
[...]/source-gcc/gcc/main.c:39
(gdb) frame 1
#1  0x00d058a2 in find_or_generate_expression
(block=block@entry=0x768f2680, op=op@entry=0x7697f3a0,
stmts=stmts@entry=0x7fffca70) at [...]/source-gcc/gcc/tree-ssa-pre.c:2672
2672  unsigned int lookfor = get_expr_value_id (expr);

Unexpectedly, "expr" 

[Bug lto/71535] ICE in LTO1 with -fopenmp offloading

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71535

Thomas Schwinge  changed:

   What|Removed |Added

 CC||tschwinge at gcc dot gnu.org

--- Comment #2 from Thomas Schwinge  ---
The is the OpenMP variant of OpenACC's PR71499.

[Bug lto/71499] ICE in LTO1 when attempting NVPTX offloading (-fopenacc)

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71499

Thomas Schwinge  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-29
 CC||tschwinge at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Thomas Schwinge  ---
The is the OpenACC variant of OpenMP's PR71535.

You need to add "#pragma acc routine" for function "test".  (Of course, we
shouldn't run into an ICE nevertheless.)

[Bug middle-end/71373] Handle more OMP_CLAUSE_* in nested function decomposition

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71373

--- Comment #9 from Thomas Schwinge  ---
Author: tschwinge
Date: Mon Jun 13 16:37:29 2016
New Revision: 237386

URL: https://gcc.gnu.org/viewcvs?rev=237386=gcc=rev
Log:
[PR middle-end/71373] Document missing OMP_CLAUSE_* in gcc/tree-nested.c

gcc/
PR middle-end/71373
* tree-nested.c (convert_nonlocal_omp_clauses)
(convert_local_omp_clauses): Document missing OMP_CLAUSE_*.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-nested.c

[Bug tree-optimization/71520] Missing cross-jumping of switch cases

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71520

Thomas Schwinge  changed:

   What|Removed |Added

 CC||tschwinge at gcc dot gnu.org

--- Comment #3 from Thomas Schwinge  ---
Out of interest, I've also started to look into GIMPLE_SWITCH issues a bit, at
the end of last week (low priority for me, though).  One of my test cases
should be similar to the one you're addressing with your patch; will test.

[Bug middle-end/71373] Handle more OMP_CLAUSE_* in nested function decomposition

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71373

Thomas Schwinge  changed:

   What|Removed |Added

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

--- Comment #7 from Thomas Schwinge  ---
Created attachment 38681
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38681=edit
Document missing OMP_CLAUSE_* in gcc/tree-nested.c

(In reply to Jakub Jelinek from comment #6)
> OMP_CLAUSE_UNIFORM
> OMP_CLAUSE_INBRANCH
> OMP_CLAUSE_NOTINBRANCH
> 
> The above 3 clauses are only allowed in the declare simd directive, so
> nothing tree-nested.c sees.
> 
> OMP_CLAUSE__LOOPTEMP_
> OMP_CLAUSE__SIMDUID_

(Also OMP_CLAUSE__GRIDDIM_.)

> These clauses are only added during omp lowering, tree-nested happens before
> that.
> 
> OMP_CLAUSE_FOR
> OMP_CLAUSE_PARALLEL
> OMP_CLAUSE_SECTIONS
> OMP_CLAUSE_TASKGROUP
> 
> These clauses are only allowed on cancel and cancellation point directives,
> which are at this point already lowered into a function call with numerical
> value.

> There is gcc_unreachable, IMHO no need to list them explicitly

It is a good thing in my opinion: the next curious reader of this code doesn't
have to wonder why some OMP_CLAUSE_* are missing here.

> and doing the
> same thing as the default, I'm afraid gcc is unable to optimize that.

Being curious about that, I'm confirming that using the patch I'm attaching. 
That's surprising to me!  The code size doesn't improve much (0.42 % in my
case), but I would have expected it to stay the same.  Can you tell off-hand
where I would have to look, to teach GCC how to optimize such constructs? 
There should be relatively common, I would think?  (Setting the PR to
"suspended" until that is resolved.)

[Bug middle-end/71373] Handle more OMP_CLAUSE_* in nested function decomposition

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71373

Thomas Schwinge  changed:

   What|Removed |Added

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

--- Comment #5 from Thomas Schwinge  ---
Fixed OpenACC clauses handling on trunk in r237291, gcc-6-branch in r237296,
and gomp-4_0-branch in r237300.


>From a quick look it appears as if the following OpenMP-specific clauses also
are not being handled:

  * OMP_CLAUSE_UNIFORM
  * OMP_CLAUSE__LOOPTEMP_
  * OMP_CLAUSE_INBRANCH
  * OMP_CLAUSE_NOTINBRANCH
  * OMP_CLAUSE_FOR
  * OMP_CLAUSE_PARALLEL
  * OMP_CLAUSE_SECTIONS
  * OMP_CLAUSE_TASKGROUP
  * OMP_CLAUSE__SIMDUID_
  * OMP_CLAUSE__GRIDDIM_

If these are in fact unreachable in gcc/tree-nested.c, I suggest to document
that with `gcc_unreachable` `case`s, and otherwise specific handling needs to
be implemented -- which I would just have done, but for some clauses, given my
limited OpenMP knowledge, I couldn't easily tell how these need to be handled,
or couldn't easily come up with valid test cases.  (Thus un-assigning myself.)

[Bug middle-end/71373] Handle more OMP_CLAUSE_* in nested function decomposition

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71373
Bug 71373 depends on bug 71381, which changed state.

Bug 71381 Summary: C/C++ OpenACC cache directive rejects valid syntax
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71381

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

[Bug c/71381] C/C++ OpenACC cache directive rejects valid syntax

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71381

Thomas Schwinge  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |6.2

--- Comment #5 from Thomas Schwinge  ---
Fixed on trunk in r237290, gcc-6-branch in r237295, and gomp-4_0-branch in
r237299.

[Bug middle-end/71373] Handle more OMP_CLAUSE_* in nested function decomposition

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71373

--- Comment #4 from Thomas Schwinge  ---
Author: tschwinge
Date: Fri Jun 10 10:12:36 2016
New Revision: 237300

URL: https://gcc.gnu.org/viewcvs?rev=237300=gcc=rev
Log:
[PR middle-end/71373] Handle more OMP_CLAUSE_* in nested function decomposition

Backport trunk r237291:

gcc/
* gimplify.c (gimplify_adjust_omp_clauses): Discard
OMP_CLAUSE_TILE.
* omp-low.c (scan_sharing_clauses): Don't expect OMP_CLAUSE_TILE.
gcc/testsuite/
* c-c++-common/goacc/combined-directives.c: XFAIL tree scanning
for OpenACC tile clauses.
* gfortran.dg/goacc/combined-directives.f90: Likewise.

gcc/
PR middle-end/71373
* tree-nested.c (convert_nonlocal_omp_clauses)
(convert_local_omp_clauses): Handle OMP_CLAUSE_ASYNC,
OMP_CLAUSE_WAIT, OMP_CLAUSE_INDEPENDENT, OMP_CLAUSE_AUTO,
OMP_CLAUSE__CACHE_, OMP_CLAUSE_TILE.
gcc/testsuite/
PR middle-end/71373
* gcc.dg/goacc/nested-function-1.c: New file.
* gcc.dg/goacc/nested-function-2.c: Likewise.
* gcc.dg/goacc/pr71373.c: Likewise.
* gfortran.dg/goacc/cray-2.f95: Likewise.
* gfortran.dg/goacc/loop-1-2.f95: Likewise.
* gfortran.dg/goacc/loop-3-2.f95: Likewise.
* gfortran.dg/goacc/cray.f95: Update.
* gfortran.dg/goacc/loop-1.f95: Likewise.
* gfortran.dg/goacc/loop-3.f95: Likewise.
* gfortran.dg/goacc/subroutines.f90: Update, and rename to...
* gfortran.dg/goacc/nested-function-1.f90: ... this new file.
libgomp/testsuite/
PR middle-end/71373
* libgomp.oacc-c/nested-function-1.c: New file.
* libgomp.oacc-c/nested-function-2.c: Likewise.
* libgomp.oacc-fortran/nested-function-1.f90: Likewise.
* libgomp.oacc-fortran/nested-function-2.f90: Likewise.
* libgomp.oacc-fortran/nested-function-3.f90: Likewise.

Added:
branches/gomp-4_0-branch/gcc/testsuite/gcc.dg/goacc/nested-function-1.c
branches/gomp-4_0-branch/gcc/testsuite/gcc.dg/goacc/nested-function-2.c
branches/gomp-4_0-branch/gcc/testsuite/gcc.dg/goacc/pr71373.c
branches/gomp-4_0-branch/gcc/testsuite/gfortran.dg/goacc/cray-2.f95
  - copied, changed from r237299,
branches/gomp-4_0-branch/gcc/testsuite/gfortran.dg/goacc/cray.f95
branches/gomp-4_0-branch/gcc/testsuite/gfortran.dg/goacc/loop-1-2.f95
  - copied, changed from r237299,
branches/gomp-4_0-branch/gcc/testsuite/gfortran.dg/goacc/loop-1.f95
branches/gomp-4_0-branch/gcc/testsuite/gfortran.dg/goacc/loop-3-2.f95
  - copied, changed from r237299,
branches/gomp-4_0-branch/gcc/testsuite/gfortran.dg/goacc/loop-3.f95
   
branches/gomp-4_0-branch/gcc/testsuite/gfortran.dg/goacc/nested-function-1.f90
   
branches/gomp-4_0-branch/libgomp/testsuite/libgomp.oacc-c/nested-function-1.c
   
branches/gomp-4_0-branch/libgomp/testsuite/libgomp.oacc-c/nested-function-2.c
   
branches/gomp-4_0-branch/libgomp/testsuite/libgomp.oacc-fortran/nested-function-1.f90
   
branches/gomp-4_0-branch/libgomp/testsuite/libgomp.oacc-fortran/nested-function-2.f90
   
branches/gomp-4_0-branch/libgomp/testsuite/libgomp.oacc-fortran/nested-function-3.f90
Removed:
branches/gomp-4_0-branch/gcc/testsuite/gfortran.dg/goacc/subroutines.f90
Modified:
branches/gomp-4_0-branch/gcc/ChangeLog.gomp
branches/gomp-4_0-branch/gcc/gimplify.c
branches/gomp-4_0-branch/gcc/omp-low.c
branches/gomp-4_0-branch/gcc/testsuite/ChangeLog.gomp
   
branches/gomp-4_0-branch/gcc/testsuite/c-c++-common/goacc/combined-directives.c
   
branches/gomp-4_0-branch/gcc/testsuite/gfortran.dg/goacc/combined-directives.f90
branches/gomp-4_0-branch/gcc/testsuite/gfortran.dg/goacc/cray.f95
branches/gomp-4_0-branch/gcc/testsuite/gfortran.dg/goacc/loop-1.f95
branches/gomp-4_0-branch/gcc/testsuite/gfortran.dg/goacc/loop-3.f95
branches/gomp-4_0-branch/gcc/tree-nested.c
branches/gomp-4_0-branch/libgomp/ChangeLog.gomp

[Bug c/71381] C/C++ OpenACC cache directive rejects valid syntax

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71381

--- Comment #4 from Thomas Schwinge  ---
Author: tschwinge
Date: Fri Jun 10 10:12:22 2016
New Revision: 237299

URL: https://gcc.gnu.org/viewcvs?rev=237299=gcc=rev
Log:
[PR c/71381] C/C++ OpenACC cache directive rejects valid syntax

libgomp/
PR c/71381
* testsuite/libgomp.oacc-fortran/cache-1.f90: Remove file.

Backport trunk r237290:

gcc/c/
PR c/71381
* c-parser.c (c_parser_omp_variable_list) :
Loosen checking.
gcc/cp/
PR c/71381
* parser.c (cp_parser_omp_var_list_no_open) :
Loosen checking.
gcc/fortran/
PR c/71381
* openmp.c (gfc_match_oacc_cache): Add comment.
gcc/testsuite/
PR c/71381
* c-c++-common/goacc/cache-1.c: Update.  Move invalid usage tests
to...
* c-c++-common/goacc/cache-2.c: ... this new file.
* gfortran.dg/goacc/cache-1.f95: Move invalid usage tests to...
* gfortran.dg/goacc/cache-2.f95: ... this new file.
* gfortran.dg/goacc/coarray.f95: Update OpenACC cache directive
usage.
* gfortran.dg/goacc/cray.f95: Likewise.
* gfortran.dg/goacc/loop-1.f95: Likewise.
libgomp/
PR c/71381
* testsuite/libgomp.oacc-c-c++-common/cache-1.c: #include
"../../../gcc/testsuite/c-c++-common/goacc/cache-1.c".
* testsuite/libgomp.oacc-fortran/cache-1.f95: New file.

gcc/
* omp-low.c (scan_sharing_clauses): Don't expect
OMP_CLAUSE__CACHE_.

Added:
branches/gomp-4_0-branch/gcc/testsuite/c-c++-common/goacc/cache-2.c
  - copied, changed from r237298,
branches/gomp-4_0-branch/gcc/testsuite/c-c++-common/goacc/cache-1.c
branches/gomp-4_0-branch/gcc/testsuite/gfortran.dg/goacc/cache-2.f95
branches/gomp-4_0-branch/libgomp/testsuite/libgomp.oacc-fortran/cache-1.f95
Removed:
branches/gomp-4_0-branch/libgomp/testsuite/libgomp.oacc-fortran/cache-1.f90
Modified:
branches/gomp-4_0-branch/gcc/ChangeLog.gomp
branches/gomp-4_0-branch/gcc/c/ChangeLog.gomp
branches/gomp-4_0-branch/gcc/c/c-parser.c
branches/gomp-4_0-branch/gcc/cp/ChangeLog.gomp
branches/gomp-4_0-branch/gcc/cp/parser.c
branches/gomp-4_0-branch/gcc/fortran/ChangeLog.gomp
branches/gomp-4_0-branch/gcc/fortran/openmp.c
branches/gomp-4_0-branch/gcc/omp-low.c
branches/gomp-4_0-branch/gcc/testsuite/ChangeLog.gomp
branches/gomp-4_0-branch/gcc/testsuite/c-c++-common/goacc/cache-1.c
branches/gomp-4_0-branch/gcc/testsuite/gfortran.dg/goacc/cache-1.f95
branches/gomp-4_0-branch/gcc/testsuite/gfortran.dg/goacc/coarray.f95
branches/gomp-4_0-branch/gcc/testsuite/gfortran.dg/goacc/cray.f95
branches/gomp-4_0-branch/gcc/testsuite/gfortran.dg/goacc/loop-1.f95
branches/gomp-4_0-branch/libgomp/ChangeLog.gomp
   
branches/gomp-4_0-branch/libgomp/testsuite/libgomp.oacc-c-c++-common/cache-1.c

[Bug middle-end/71373] Handle more OMP_CLAUSE_* in nested function decomposition

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71373

--- Comment #3 from Thomas Schwinge  ---
Author: tschwinge
Date: Fri Jun 10 09:46:18 2016
New Revision: 237296

URL: https://gcc.gnu.org/viewcvs?rev=237296=gcc=rev
Log:
[PR middle-end/71373] Handle more OMP_CLAUSE_* in nested function decomposition

Backport trunk r237291:

gcc/
* gimplify.c (gimplify_adjust_omp_clauses): Discard
OMP_CLAUSE_TILE.
* omp-low.c (scan_sharing_clauses): Don't expect OMP_CLAUSE_TILE.
gcc/testsuite/
* c-c++-common/goacc/combined-directives.c: XFAIL tree scanning
for OpenACC tile clauses.
* gfortran.dg/goacc/combined-directives.f90: Likewise.

gcc/
PR middle-end/71373
* tree-nested.c (convert_nonlocal_omp_clauses)
(convert_local_omp_clauses): Handle OMP_CLAUSE_ASYNC,
OMP_CLAUSE_WAIT, OMP_CLAUSE_INDEPENDENT, OMP_CLAUSE_AUTO,
OMP_CLAUSE__CACHE_, OMP_CLAUSE_TILE.
gcc/testsuite/
PR middle-end/71373
* gcc.dg/goacc/nested-function-1.c: New file.
* gcc.dg/goacc/nested-function-2.c: Likewise.
* gcc.dg/goacc/pr71373.c: Likewise.
* gfortran.dg/goacc/cray-2.f95: Likewise.
* gfortran.dg/goacc/loop-1-2.f95: Likewise.
* gfortran.dg/goacc/loop-3-2.f95: Likewise.
* gfortran.dg/goacc/cray.f95: Update.
* gfortran.dg/goacc/loop-1.f95: Likewise.
* gfortran.dg/goacc/loop-3.f95: Likewise.
* gfortran.dg/goacc/subroutines.f90: Update, and rename to...
* gfortran.dg/goacc/nested-function-1.f90: ... this new file.
libgomp/testsuite/
PR middle-end/71373
* libgomp.oacc-c/nested-function-1.c: New file.
* libgomp.oacc-c/nested-function-2.c: Likewise.
* libgomp.oacc-fortran/nested-function-1.f90: Likewise.
* libgomp.oacc-fortran/nested-function-2.f90: Likewise.
* libgomp.oacc-fortran/nested-function-3.f90: Likewise.

Added:
branches/gcc-6-branch/gcc/testsuite/gcc.dg/goacc/nested-function-1.c
branches/gcc-6-branch/gcc/testsuite/gcc.dg/goacc/nested-function-2.c
branches/gcc-6-branch/gcc/testsuite/gcc.dg/goacc/pr71373.c
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/goacc/cray-2.f95
  - copied, changed from r237295,
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/goacc/cray.f95
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/goacc/loop-1-2.f95
  - copied, changed from r237295,
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/goacc/loop-1.f95
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/goacc/loop-3-2.f95
  - copied, changed from r237295,
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/goacc/loop-3.f95
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/goacc/nested-function-1.f90
branches/gcc-6-branch/libgomp/testsuite/libgomp.oacc-c/nested-function-1.c
branches/gcc-6-branch/libgomp/testsuite/libgomp.oacc-c/nested-function-2.c
   
branches/gcc-6-branch/libgomp/testsuite/libgomp.oacc-fortran/nested-function-1.f90
   
branches/gcc-6-branch/libgomp/testsuite/libgomp.oacc-fortran/nested-function-2.f90
   
branches/gcc-6-branch/libgomp/testsuite/libgomp.oacc-fortran/nested-function-3.f90
Removed:
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/goacc/subroutines.f90
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/gimplify.c
branches/gcc-6-branch/gcc/omp-low.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog
   
branches/gcc-6-branch/gcc/testsuite/c-c++-common/goacc/combined-directives.c
   
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/goacc/combined-directives.f90
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/goacc/cray.f95
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/goacc/loop-1.f95
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/goacc/loop-3.f95
branches/gcc-6-branch/gcc/tree-nested.c
branches/gcc-6-branch/libgomp/ChangeLog

[Bug c/71381] C/C++ OpenACC cache directive rejects valid syntax

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71381

--- Comment #3 from Thomas Schwinge  ---
Author: tschwinge
Date: Fri Jun 10 09:46:04 2016
New Revision: 237295

URL: https://gcc.gnu.org/viewcvs?rev=237295=gcc=rev
Log:
[PR c/71381] C/C++ OpenACC cache directive rejects valid syntax

Backport trunk r237290:

gcc/c/
PR c/71381
* c-parser.c (c_parser_omp_variable_list) :
Loosen checking.
gcc/cp/
PR c/71381
* parser.c (cp_parser_omp_var_list_no_open) :
Loosen checking.
gcc/fortran/
PR c/71381
* openmp.c (gfc_match_oacc_cache): Add comment.
gcc/testsuite/
PR c/71381
* c-c++-common/goacc/cache-1.c: Update.  Move invalid usage tests
to...
* c-c++-common/goacc/cache-2.c: ... this new file.
* gfortran.dg/goacc/cache-1.f95: Move invalid usage tests to...
* gfortran.dg/goacc/cache-2.f95: ... this new file.
* gfortran.dg/goacc/coarray.f95: Update OpenACC cache directive
usage.
* gfortran.dg/goacc/cray.f95: Likewise.
* gfortran.dg/goacc/loop-1.f95: Likewise.
libgomp/
PR c/71381
* testsuite/libgomp.oacc-c-c++-common/cache-1.c: #include
"../../../gcc/testsuite/c-c++-common/goacc/cache-1.c".
* testsuite/libgomp.oacc-fortran/cache-1.f95: New file.

gcc/
* omp-low.c (scan_sharing_clauses): Don't expect
OMP_CLAUSE__CACHE_.

Added:
branches/gcc-6-branch/gcc/testsuite/c-c++-common/goacc/cache-2.c
  - copied, changed from r237294,
branches/gcc-6-branch/gcc/testsuite/c-c++-common/goacc/cache-1.c
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/goacc/cache-2.f95
branches/gcc-6-branch/libgomp/testsuite/libgomp.oacc-fortran/cache-1.f95
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/c/ChangeLog
branches/gcc-6-branch/gcc/c/c-parser.c
branches/gcc-6-branch/gcc/cp/ChangeLog
branches/gcc-6-branch/gcc/cp/parser.c
branches/gcc-6-branch/gcc/fortran/ChangeLog
branches/gcc-6-branch/gcc/fortran/openmp.c
branches/gcc-6-branch/gcc/omp-low.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog
branches/gcc-6-branch/gcc/testsuite/c-c++-common/goacc/cache-1.c
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/goacc/cache-1.f95
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/goacc/coarray.f95
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/goacc/cray.f95
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/goacc/loop-1.f95
branches/gcc-6-branch/libgomp/ChangeLog
branches/gcc-6-branch/libgomp/testsuite/libgomp.oacc-c-c++-common/cache-1.c

[Bug middle-end/71373] Handle more OMP_CLAUSE_* in nested function decomposition

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71373

--- Comment #2 from Thomas Schwinge  ---
Author: tschwinge
Date: Fri Jun 10 09:22:51 2016
New Revision: 237291

URL: https://gcc.gnu.org/viewcvs?rev=237291=gcc=rev
Log:
[PR middle-end/71373] Handle more OMP_CLAUSE_* in nested function decomposition

gcc/
* gimplify.c (gimplify_adjust_omp_clauses): Discard
OMP_CLAUSE_TILE.
* omp-low.c (scan_sharing_clauses): Don't expect OMP_CLAUSE_TILE.
gcc/testsuite/
* c-c++-common/goacc/combined-directives.c: XFAIL tree scanning
for OpenACC tile clauses.
* gfortran.dg/goacc/combined-directives.f90: Likewise.

gcc/
PR middle-end/71373
* tree-nested.c (convert_nonlocal_omp_clauses)
(convert_local_omp_clauses): Handle OMP_CLAUSE_ASYNC,
OMP_CLAUSE_WAIT, OMP_CLAUSE_INDEPENDENT, OMP_CLAUSE_AUTO,
OMP_CLAUSE__CACHE_, OMP_CLAUSE_TILE.
gcc/testsuite/
PR middle-end/71373
* gcc.dg/goacc/nested-function-1.c: New file.
* gcc.dg/goacc/nested-function-2.c: Likewise.
* gcc.dg/goacc/pr71373.c: Likewise.
* gfortran.dg/goacc/cray-2.f95: Likewise.
* gfortran.dg/goacc/loop-1-2.f95: Likewise.
* gfortran.dg/goacc/loop-3-2.f95: Likewise.
* gfortran.dg/goacc/cray.f95: Update.
* gfortran.dg/goacc/loop-1.f95: Likewise.
* gfortran.dg/goacc/loop-3.f95: Likewise.
* gfortran.dg/goacc/subroutines.f90: Update, and rename to...
* gfortran.dg/goacc/nested-function-1.f90: ... this new file.
libgomp/testsuite/
PR middle-end/71373
* libgomp.oacc-c/nested-function-1.c: New file.
* libgomp.oacc-c/nested-function-2.c: Likewise.
* libgomp.oacc-fortran/nested-function-1.f90: Likewise.
* libgomp.oacc-fortran/nested-function-2.f90: Likewise.
* libgomp.oacc-fortran/nested-function-3.f90: Likewise.

Added:
trunk/gcc/testsuite/gcc.dg/goacc/nested-function-1.c
trunk/gcc/testsuite/gcc.dg/goacc/nested-function-2.c
trunk/gcc/testsuite/gcc.dg/goacc/pr71373.c
trunk/gcc/testsuite/gfortran.dg/goacc/cray-2.f95
  - copied, changed from r237290,
trunk/gcc/testsuite/gfortran.dg/goacc/cray.f95
trunk/gcc/testsuite/gfortran.dg/goacc/loop-1-2.f95
  - copied, changed from r237290,
trunk/gcc/testsuite/gfortran.dg/goacc/loop-1.f95
trunk/gcc/testsuite/gfortran.dg/goacc/loop-3-2.f95
  - copied, changed from r237290,
trunk/gcc/testsuite/gfortran.dg/goacc/loop-3.f95
trunk/gcc/testsuite/gfortran.dg/goacc/nested-function-1.f90
trunk/libgomp/testsuite/libgomp.oacc-c/nested-function-1.c
trunk/libgomp/testsuite/libgomp.oacc-c/nested-function-2.c
trunk/libgomp/testsuite/libgomp.oacc-fortran/nested-function-1.f90
trunk/libgomp/testsuite/libgomp.oacc-fortran/nested-function-2.f90
trunk/libgomp/testsuite/libgomp.oacc-fortran/nested-function-3.f90
Removed:
trunk/gcc/testsuite/gfortran.dg/goacc/subroutines.f90
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimplify.c
trunk/gcc/omp-low.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/goacc/combined-directives.c
trunk/gcc/testsuite/gfortran.dg/goacc/combined-directives.f90
trunk/gcc/testsuite/gfortran.dg/goacc/cray.f95
trunk/gcc/testsuite/gfortran.dg/goacc/loop-1.f95
trunk/gcc/testsuite/gfortran.dg/goacc/loop-3.f95
trunk/gcc/tree-nested.c
trunk/libgomp/ChangeLog

[Bug c/71381] C/C++ OpenACC cache directive rejects valid syntax

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71381

--- Comment #2 from Thomas Schwinge  ---
Author: tschwinge
Date: Fri Jun 10 09:22:38 2016
New Revision: 237290

URL: https://gcc.gnu.org/viewcvs?rev=237290=gcc=rev
Log:
[PR c/71381] C/C++ OpenACC cache directive rejects valid syntax

gcc/c/
PR c/71381
* c-parser.c (c_parser_omp_variable_list) :
Loosen checking.
gcc/cp/
PR c/71381
* parser.c (cp_parser_omp_var_list_no_open) :
Loosen checking.
gcc/fortran/
PR c/71381
* openmp.c (gfc_match_oacc_cache): Add comment.
gcc/testsuite/
PR c/71381
* c-c++-common/goacc/cache-1.c: Update.  Move invalid usage tests
to...
* c-c++-common/goacc/cache-2.c: ... this new file.
* gfortran.dg/goacc/cache-1.f95: Move invalid usage tests to...
* gfortran.dg/goacc/cache-2.f95: ... this new file.
* gfortran.dg/goacc/coarray.f95: Update OpenACC cache directive
usage.
* gfortran.dg/goacc/cray.f95: Likewise.
* gfortran.dg/goacc/loop-1.f95: Likewise.
libgomp/
PR c/71381
* testsuite/libgomp.oacc-c-c++-common/cache-1.c: #include
"../../../gcc/testsuite/c-c++-common/goacc/cache-1.c".
* testsuite/libgomp.oacc-fortran/cache-1.f95: New file.

gcc/
* omp-low.c (scan_sharing_clauses): Don't expect
OMP_CLAUSE__CACHE_.

Added:
trunk/gcc/testsuite/c-c++-common/goacc/cache-2.c
  - copied, changed from r237289,
trunk/gcc/testsuite/c-c++-common/goacc/cache-1.c
trunk/gcc/testsuite/gfortran.dg/goacc/cache-2.f95
trunk/libgomp/testsuite/libgomp.oacc-fortran/cache-1.f95
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/fortran/ChangeLog
trunk/gcc/fortran/openmp.c
trunk/gcc/omp-low.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/goacc/cache-1.c
trunk/gcc/testsuite/gfortran.dg/goacc/cache-1.f95
trunk/gcc/testsuite/gfortran.dg/goacc/coarray.f95
trunk/gcc/testsuite/gfortran.dg/goacc/cray.f95
trunk/gcc/testsuite/gfortran.dg/goacc/loop-1.f95
trunk/libgomp/ChangeLog
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/cache-1.c

[Bug other/65095] Adapt OpenMP diagnostic messages for OpenACC

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65095

Thomas Schwinge  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-03
 Ever confirmed|0   |1

--- Comment #1 from Thomas Schwinge  ---
Cesar fixed a few in r236678.

[Bug middle-end/71373] Handle more OMP_CLAUSE_* in nested function decomposition

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71373

Thomas Schwinge  changed:

   What|Removed |Added

   Keywords||patch
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-06-03
 Depends on||71381
 Ever confirmed|0   |1

--- Comment #1 from Thomas Schwinge  ---
First patch approved,
.
 Waiting for PR71381.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71381
[Bug 71381] C/C++ OpenACC cache directive rejects valid syntax

[Bug c/71381] C/C++ OpenACC cache directive rejects valid syntax

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71381

Thomas Schwinge  changed:

   What|Removed |Added

   Keywords||patch
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-06-03
 CC||jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Thomas Schwinge  ---
Patch waiting for approval:
.

[Bug c/71381] New: C/C++ OpenACC cache directive rejects valid syntax

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71381

Bug ID: 71381
   Summary: C/C++ OpenACC cache directive rejects valid syntax
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: openacc, rejects-valid
  Severity: normal
  Priority: P3
 Component: c
  Assignee: tschwinge at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
  Target Milestone: ---

[Bug middle-end/71373] New: Handle more OMP_CLAUSE_* in nested function decomposition

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71373

Bug ID: 71373
   Summary: Handle more OMP_CLAUSE_* in nested function
decomposition
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: openacc, openmp
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: tschwinge at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

We don't handle several OMP_CLAUSE_* in nested function decomposition
(gcc/tree-nested.c), which will result in ICEs.

[Bug fortran/63859] Fortran OpenACC declare directive

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63859

Thomas Schwinge  changed:

   What|Removed |Added

 CC||tschwinge at gcc dot gnu.org
Summary|OpenACC DEVICE_RESIDENT |Fortran OpenACC declare
   |clause  |directive

--- Comment #2 from Thomas Schwinge  ---
The status of the Fortran OpenACC declare directive again came up in
<http://news.gmane.org/find-root.php?message_id=%3C87wpmaqlii.fsf%40kepler.schwinge.homeip.net%3E>,
and needs to be looked into.

[Bug libffi/65567] ERROR: tcl error sourcing /test/gnu/gcc/gcc/libffi/testsuite/libffi.complex/complex.exp

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65567

--- Comment #5 from Thomas Schwinge  ---
Author: tschwinge
Date: Mon May 23 14:54:04 2016
New Revision: 236594

URL: https://gcc.gnu.org/viewcvs?rev=236594=gcc=rev
Log:
[PR libffi/65567] libffi: Fix, and simply libffi_feature_test

libffi/
PR libffi/65567
* testsuite/lib/libffi.exp (libffi_feature_test): Fix, and simply.

Modified:
trunk/libffi/ChangeLog
trunk/libffi/testsuite/lib/libffi.exp

[Bug libffi/65567] ERROR: tcl error sourcing /test/gnu/gcc/gcc/libffi/testsuite/libffi.complex/complex.exp

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65567

--- Comment #6 from Thomas Schwinge  ---
Author: tschwinge
Date: Mon May 23 15:00:41 2016
New Revision: 236595

URL: https://gcc.gnu.org/viewcvs?rev=236595=gcc=rev
Log:
[PR libffi/65567] libffi: Fix, and simply libffi_feature_test

Backport trunk r236594:

libffi/
PR libffi/65567
* testsuite/lib/libffi.exp (libffi_feature_test): Fix, and simply.

Modified:
branches/gcc-6-branch/libffi/ChangeLog
branches/gcc-6-branch/libffi/testsuite/lib/libffi.exp

[Bug libffi/65567] ERROR: tcl error sourcing /test/gnu/gcc/gcc/libffi/testsuite/libffi.complex/complex.exp

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65567

--- Comment #7 from Thomas Schwinge  ---
Author: tschwinge
Date: Mon May 23 15:03:08 2016
New Revision: 236596

URL: https://gcc.gnu.org/viewcvs?rev=236596=gcc=rev
Log:
[PR libffi/65567] libffi: Fix, and simply libffi_feature_test

Backport trunk r236594:

libffi/
PR libffi/65567
* testsuite/lib/libffi.exp (libffi_feature_test): Fix, and simply.

Modified:
branches/gcc-5-branch/libffi/ChangeLog
branches/gcc-5-branch/libffi/testsuite/lib/libffi.exp

[Bug other/70945] Offloading: compatibility of target and offloading toolchains

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70945

Thomas Schwinge  changed:

   What|Removed |Added

  Attachment #38484|0   |1
is obsolete||

--- Comment #5 from Thomas Schwinge  ---
Comment on attachment 38484
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38484
0001-function_glibc_finite_math.patch

Revised patch: [PR other/70945] Handle function_glibc_finite_math in
offloading,
.

[Bug target/70738] Add -mgeneral-regs-only option

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70738

Thomas Schwinge  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
   Last reconfirmed||2016-05-23
 Resolution|FIXED   |---
 Ever confirmed|0   |1

--- Comment #5 from Thomas Schwinge  ---
.

[Bug target/70860] [nvptx] Revisit cfun->machine->doing_call

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70860

--- Comment #2 from Thomas Schwinge  ---
Author: tschwinge
Date: Tue May 17 16:08:37 2016
New Revision: 236326

URL: https://gcc.gnu.org/viewcvs?rev=236326=gcc=rev
Log:
[PR target/70860] [nvptx] Handle NULL cfun in nvptx_libcall_value

Backport GCC trunk r235748:

gcc/
PR target/70860
* config/nvptx/nvptx.c (nvptx_libcall_value): Handle NULL cfun.
(nvptx_function_value): Assert non-NULL cfun.

Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/nvptx/nvptx.c

[Bug other/70945] Offloading: compatibility of target and offloading toolchains

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70945

Thomas Schwinge  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-05-13
   Assignee|unassigned at gcc dot gnu.org  |tschwinge at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Thomas Schwinge  ---
Created attachment 38484
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38484=edit
0001-function_glibc_finite_math.patch

(In reply to Alexander Monakov from comment #1)
> Basically I'd say that host compilation environment establishes an ABI
> baseline that the accel environment must follow.

Generally, ACK.

> In your finite-math
> example, the problem exists due to an ABI extension in Glibc (note that the
> custom name could equally happen to be __glibc_log_finite).  You'd see the
> same issue trying to run a new binary on old Glibc systems that didn't have
> that symbol yet, and now Glibc itself is bound to carry that entrypoint
> forever.

ACK.

> And note that the issue is not limited to math symbols either: with
> -D_FORTIFY_SOURCE, plain 'printf' may become '__printf_chk', which would
> also fail to link on Newlib.

ACK, but let's concentrate on the math functions for the moment.

> Is there any actual issue with Fortran functions? [...]

That was meant to be a "motivational example", why users may expect to be able
to use math functions also in offloaded C/C++ regions.

I'm attaching a patch that shows a different approach, instead of adding a lot
of glibc-specific "__[function]_finite" entry points to the nvptx newlib, which
don't belong into there, really.

Basically, we add a new property function_glibc_finite_math
(gcc/coretypes.h:enum function_class), stream that in the target compiler
(gcc/lto-cgraph.c:output_offload_tables), and when reading it back in in the
offloading compilers (gcc/lto-cgraph.c:input_offload_tables), if the offloading
compiler's property doesn't match the of the target compiler, for all
references to external math functions, we 'check whether the assembler name for
"[function]" has been set to "__[function]_finite" [...], and if yes, reset
it'.

We could get rid of this heuristic (the property function_glibc_finite_math in
combination with matching declarations' names) if the target compiler's early
code transformation stages would accurately "describe" what they're doing, but
that sounds like having to add some special/new "attributes" to glibc's
, which sounds more complicated.  I think the heuristic is
safe enough; symbol names prefixed with an underscore are in the implementation
namespace.

What do you think of that?

[Bug other/71101] New: ICE in libcpp/line-map.c:linemap_macro_map_lookup very early in offloading compilation lto1 front end

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71101

Bug ID: 71101
   Summary: ICE in libcpp/line-map.c:linemap_macro_map_lookup very
early in offloading compilation lto1 front end
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: openacc, openmp
  Severity: minor
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

I'm running into an ICE in libcpp/line-map code, when in GDB doing a "call
debug_tree(decl)", very early in a lto1 front end that is reading in an
offloading compilation stream.  That setting will be a bit difficult to
reproduce, but perhaps the following information gives enough clues already? 
(Putting David in CC as he's done a lot of line-map changes recently -- but I'm
not claiming that any of his changes are actually related to this.)

Is it maybe just "too early" to call debug_tree in that situation, or should
that be handled in some way or another?

Breakpoint 2, lto_register_function_decl_in_symtab
(data_in=data_in@entry=0x15832b0, decl=0x76989d20, ix=ix@entry=175) at
[...]/source-gcc/gcc/lto/lto.c:871
871 {

Here I manually call:

(gdb) call debug_tree(decl)
 >
QI
size 
unit size 
align 8 symtab 0 alias set -1 structural equality
arg-types 
chain >>>
addressable nothrow staticlto1: internal compiler error: in
linemap_macro_map_lookup, at libcpp/line-map.c:984

(Notice the ICE message starting after "addressable nothrow static".)  That's
the following linemap_assert:

/* Given a source location yielded by a macro map, returns that map.
   Since the set is built chronologically, the logical lines are
   monotonic decreasing, and so the list is sorted and we can use a
   binary search.  */

static const line_map_macro *
linemap_macro_map_lookup (struct line_maps *set, source_location line)
{
  unsigned int md, mn, mx;
  const struct line_map_macro *cached, *result;

  if (IS_ADHOC_LOC (line))
line = set->location_adhoc_data_map.data[line &
MAX_SOURCE_LOCATION].locus;

  linemap_assert (line >= LINEMAPS_MACRO_LOWEST_LOCATION (set));

Rebuilding that part with "-O0", I see the following backtrace:

#1  0x00fd4373 in linemap_macro_map_lookup
(set=set@entry=0x77ff5000, line=line@entry=2) at
[...]/source-gcc/libcpp/line-map.c:986
#2  0x00fd5131 in linemap_lookup (set=set@entry=0x77ff5000,
line=line@entry=2) at [...]/source-gcc/libcpp/line-map.c:920
#3  0x00fd62c4 in linemap_location_in_system_header_p
(set=0x77ff5000, location=2) at [...]/source-gcc/libcpp/line-map.c:1191
#4  0x009a2202 in print_node (file=0x76e91640
<_IO_2_1_stderr_>, prefix=prefix@entry=0x1105de0 "",
node=node@entry=0x76989d20, indent=indent@entry=0) at
[...]/source-gcc/gcc/print-tree.c:373
#5  0x009a6380 in debug_tree (node=0x76989d20) at
[...]/source-gcc/gcc/print-tree.c:976
#6  
[...]
(gdb) frame 1
#1  0x00fd4373 in linemap_macro_map_lookup
(set=set@entry=0x77ff5000, line=line@entry=2) at
[...]/source-gcc/libcpp/line-map.c:986
986   linemap_assert (line >= LINEMAPS_MACRO_LOWEST_LOCATION (set));
(gdb) print line
$1 = 2
(gdb) print set
$2 = (line_maps *) 0x77ff5000
(gdb) print *set
$3 = {info_ordinary = {maps = 0x0, allocated = 0, used = 0, cache = 0},
info_macro = {maps = 0x0, allocated = 0, used = 0, cache = 0}, depth = 0,
trace_includes = false, highest_location = 1, highest_line = 1, max_column_hint
= 0, reallocator = 0xa403b0 <realloc_for_line_map(void*, size_t)>,
round_alloc_size = 0x5a9b10 <ggc_round_alloc_size(unsigned long)>,
location_adhoc_data_map = {htab = 0x157e550, curr_loc = 0, allocated = 0, data
= 0x0}, builtin_location = 1, seen_line_directive = false, default_range_bits =
5, num_optimized_ranges = 0, num_unoptimized_ranges = 0}
(gdb) call line_table_dump(0,set,-1,-1)
# of ordinary maps:  0
# of macro maps: 0
Include stack depth: 0
Highest location:1

Ordinary line maps


Macro line maps


If that helps any: running through this again, I see "line" is not considered
"IS_ADHOC_LOC":

(gdb) list
974monotonic decreasing, and so the list is sorted and we can use a
975binary search.  */
976
977 static const line_map_macro *
978 linemap_macro_map_lookup (struct line_maps *set, source_location
line)
979 {
980   unsigned int md, mn, mx;
981   const struct line_map_macro *cached, *result;
982
983   

[Bug bootstrap/71071] [7 regression] ICE --enable-checking=fold : fold check: original tree changed by fold

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71071

Thomas Schwinge  changed:

   What|Removed |Added

 CC||tschwinge at gcc dot gnu.org

--- Comment #11 from Thomas Schwinge  ---
Created attachment 38481
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38481=edit
pre-rpcessed newlib/libc/stdlib/dtoa.c for nvptx-none

I also bisected a nvptx-none "fold check" ICE to be caused/triggered by the
recent r236117:

build-gcc-offload-nvptx-none/gcc/cc1 -fpreprocessed dtoa.i -g -O2
-fno-builtin
 quorem _dtoa_r
[...]/source-gcc/newlib/libc/stdlib/dtoa.c: In function '_dtoa_r':
[...]/source-gcc/newlib/libc/stdlib/dtoa.c:269:2: internal compiler error:
fold check: original tree changed by fold
  "NaN";
  ^

#1  0x0050fe29 in fold_check_failed (ret=,
expr=0x76a4b640) at [...]/source-gcc/gcc/fold-const.c:12099
#2  0x007f4f48 in fold_build2_stat_loc (loc=loc@entry=2147483836,
code=code@entry=TRUTH_ANDIF_EXPR, type=0x768d2690,
op0=op0@entry=0x76a4b640, op1=0x76a4b668) at
[...]/source-gcc/gcc/fold-const.c:12358
#3  0x005d7090 in c_fully_fold_internal
(expr=expr@entry=0x76a4b618, in_init=in_init@entry=false,
maybe_const_operands=maybe_const_operands@entry=0x7fffbf0a,
maybe_const_itself=maybe_const_itself@entry=0x7fffbf0d,
for_int_const=for_int_const@entry=false) at [...]/source-gcc/gcc/c/c-fold.c:457
#4  0x005d521a in c_fully_fold_internal
(expr=expr@entry=0x76a4a4b0, in_init=in_init@entry=false,
maybe_const_operands=maybe_const_operands@entry=0x7fffbf5e,
maybe_const_itself=maybe_const_itself@entry=0x7fffbf5f,
for_int_const=for_int_const@entry=false) at [...]/source-gcc/gcc/c/c-fold.c:482
#5  0x005d840b in c_fully_fold (expr=expr@entry=0x76a4a4b0,
in_init=in_init@entry=false, maybe_const=0x7fffbf5e, maybe_const@entry=0x0)
at [...]/source-gcc/gcc/c/c-fold.c:90
#6  0x00595803 in build_modify_expr
(location=location@entry=45810496, lhs=lhs@entry=0x76a49240,
lhs_origtype=lhs_origtype@entry=0x768e4a80,
modifycode=modifycode@entry=NOP_EXPR, rhs_loc=rhs_loc@entry=45818464,
rhs=, rhs@entry=0x76a4a4b0,
rhs_origtype=rhs_origtype@entry=0x768e4a80) at
[...]/source-gcc/gcc/c/c-typeck.c:5697
#7  0x005a674d in c_parser_expr_no_commas
(parser=parser@entry=0x76995000, after=after@entry=0x0,
omp_atomic_lhs=omp_atomic_lhs@entry=0x0) at
[...]/source-gcc/gcc/c/c-parser.c:6313
#8  0x005a6da5 in c_parser_expression
(parser=parser@entry=0x76995000) at [...]/source-gcc/gcc/c/c-parser.c:8450
#9  0x005a78aa in c_parser_expression_conv
(parser=parser@entry=0x76995000) at [...]/source-gcc/gcc/c/c-parser.c:8483
#10 0x005be3da in c_parser_statement_after_labels
(parser=parser@entry=0x76995000, if_p=if_p@entry=0x0,
chain=chain@entry=0x0) at [...]/source-gcc/gcc/c/c-parser.c:5285
#11 0x005c034c in c_parser_compound_statement_nostart
(parser=0x76995000) at [...]/source-gcc/gcc/c/c-parser.c:4859
#12 0x005c0c3f in c_parser_compound_statement
(parser=parser@entry=0x76995000) at [...]/source-gcc/gcc/c/c-parser.c:4694
#13 0x005bfcfd in c_parser_if_body (if_tinfo=...,
if_p=0x7fffc3ff, parser=0x76995000) at
[...]/source-gcc/gcc/c/c-parser.c:5384
#14 c_parser_if_statement (chain=0x0, if_p=0x0, parser=0x76995000) at
[...]/source-gcc/gcc/c/c-parser.c:5502
#15 c_parser_statement_after_labels (parser=parser@entry=0x76995000,
if_p=if_p@entry=0x0, chain=chain@entry=0x0) at
[...]/source-gcc/gcc/c/c-parser.c:5139
#16 0x005c034c in c_parser_compound_statement_nostart
(parser=0x76995000) at [...]/source-gcc/gcc/c/c-parser.c:4859
#17 0x005c0c3f in c_parser_compound_statement
(parser=parser@entry=0x76995000) at [...]/source-gcc/gcc/c/c-parser.c:4694
#18 0x005c2111 in c_parser_declaration_or_fndef
(parser=parser@entry=0x76995000, fndef_ok=fndef_ok@entry=true,
static_assert_ok=static_assert_ok@entry=true, empty_ok=empty_ok@entry=true,
nested=nested@entry=false, start_attr_ok=start_attr_ok@entry=true,
objc_foreach_object_declaration=objc_foreach_object_declaration@entry=0x0,
omp_declare_simd_clauses=..., omp_declare_simd_clauses@entry=...,
oacc_routine_clauses=oacc_routine_clauses@entry=0x0) at
[...]/source-gcc/gcc/c/c-parser.c:2106
#19 0x005cb797 in c_parser_external_declaration
(parser=0x76995000) at [...]/source-gcc/gcc/c/c-parser.c:1550
#20 0x005cc2aa in c_parser_translation_unit (parser=0x76995000)
at [...]/source-gcc/gcc/c/c-parser.c:1431
#21 c_parse_file () at [...]/source-gcc/gcc/c/c-parser.c:17916
#22 0x00630b43 in c_common_parse_file () at
[...]/source-gcc/gcc/c-family/c-opts.c:1064
#23 0x0

[Bug fortran/70598] Fortran OpenACC host_data construct ICE

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70598

Thomas Schwinge  changed:

   What|Removed |Added

   Keywords||patch
 CC||tschwinge at gcc dot gnu.org
   Target Milestone|7.0 |6.2

--- Comment #3 from Thomas Schwinge  ---
In
<http://news.gmane.org/find-root.php?message_id=%3C2b4f59d5-be38-2814-27bb-73aa7ffb4b8f%40codesourcery.com%3E>,
Chung-Lin has now posted a patch (pending review) that should make the OpenACC
host_data construct usable in GCC Fortran.  (Problem discussed in
<http://news.gmane.org/find-root.php?message_id=%3C878u0o6wwj.fsf%40kepler.schwinge.homeip.net%3E>
before.)

[Bug fortran/70856] [6/7 Regression] ICE with -fopenacc in get_constraint_for_ssa_var, at tree-ssa-structalias.c:2952

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70856

Thomas Schwinge  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org,
   ||tschwinge at gcc dot gnu.org,
   ||vries at gcc dot gnu.org

--- Comment #3 from Thomas Schwinge  ---
I had a cursory look at that one.  Differently from PR70857, the ICE triggers
here the second time that pass_ipa_pta is run (all_late_ipa_passes), and not
the first one (which is only active if "-fopenacc" is in effect; Tom CCed for
your information anyway).  This is "fixed" ;-) by reverting the r233734 changes
for PR69951 "[Bug tree-optimization/69951] wrong code at -O1 and above on
x86_64-linux-gnu":

2016-02-26  Richard Biener  <rguent...@suse.de>

PR tree-optimization/69551
* tree-ssa-structalias.c (get_constraint_for_ssa_var): When
looking through aliases adjust DECL_PT_UID to refer to the
ultimate alias target.

--- gcc/tree-ssa-structalias.c
+++ gcc/tree-ssa-structalias.c
@@ -2943,6 +2943,14 @@ get_constraint_for_ssa_var (tree t, vec
*results, bool address_p)
   if (node && node->alias && node->analyzed)
{
  node = node->ultimate_alias_target ();
+ /* Canonicalize the PT uid of all aliases to the ultimate target.
+???  Hopefully the set of aliases can't change in a way that
+changes the ultimate alias target.  */
+ gcc_assert ((! DECL_PT_UID_SET_P (node->decl)
+  || DECL_PT_UID (node->decl) == DECL_UID
(node->decl))
+ && (! DECL_PT_UID_SET_P (t)
+ || DECL_PT_UID (t) == DECL_UID (node->decl)));
+ DECL_PT_UID (t) = DECL_UID (node->decl);
  t = node->decl;
}
 }

(gdb) call node->debug()
A.4.3435/10 (A.4) @0x76a7f800
  Type: variable definition analyzed
  Visibility: prevailing_def_ironly artificial
  References: 
  Referring: A.1.3429/6 (alias)MAIN__/0 (read)
  Availability: available
  Varpool flags: initialized used-by-single-function read-only
const-value-known
(gdb) call debug_tree(node->decl)
 
unit size 
align 32 symtab 0 alias set 9 canonical type 0x768e6540
precision 32
pointer_to_this >
type_2 DI
size 
unit size 
align 32 symtab 0 alias set 9 canonical type 0x76a91b28
domain 
DI size  unit size 
align 64 symtab 0 alias set -1 canonical type 0x76a91540
precision 64 min  max >
pointer_to_this >
readonly constant static ignored DI file ../pr70856-z1.f90 line 3 col 0
size  unit size 
align 64 context  initial >
(gdb) call debug_tree(t)
 
unit size 
align 32 symtab 0 alias set 9 canonical type 0x768e6540
precision 32
pointer_to_this >
type_2 DI
size 
unit size 
align 32 symtab 0 alias set 9 canonical type 0x76a911f8
domain 
DI size  unit size 
align 64 symtab 0 alias set -1 canonical type 0x76a91540
precision 64 min  max >
pointer_to_this >
readonly constant static ignored DI file ../pr70856-z1.f90 line 2 col 0
size  unit size 
align 64 context >

[Bug hsa/70857] [6/7 Regression] ICE with -fopenmp -fopenacc in insert_vi_for_tree, at tree-ssa-structalias.c:2813

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70857

Thomas Schwinge  changed:

   What|Removed |Added

   Keywords||openacc
 CC||tschwinge at gcc dot gnu.org,
   ||vries at gcc dot gnu.org

--- Comment #3 from Thomas Schwinge  ---
I had a cursory look at this.  The ICE with
gcc/testsuite/gfortran.dg/gomp/gridify-1.f90 occurs for "-fopenacc -fopenmp
-O1", and disappears for "-fno-openacc", or alternatively to that, also
disappears if "hsa" offloading is disabled using the "-foffload" option. 
Backtrace:

#1  0x00da4d7c in insert_vi_for_tree (t=0x768d7258,
vi=vi@entry=0x20b8d40) at [...]/source-gcc/gcc/tree-ssa-structalias.c:2821
#2  0x00da9edb in create_function_info_for (decl=0x76a8ed20,
name=0x76a946c0 "vector_square_._omp_fn.0", 
add_id=add_id@entry=false, nonlocal_p=nonlocal_p@entry=false) at
[...]/source-gcc/gcc/tree-ssa-structalias.c:5686
#3  0x00daf7c9 in ipa_pta_execute () at
[...]/source-gcc/gcc/tree-ssa-structalias.c:7703
#4  0x00db0a62 in (anonymous namespace)::pass_ipa_pta::execute
(this=0x1fa35e0) at [...]/source-gcc/gcc/tree-ssa-structalias.c:8041
#5  0x00afdd3d in execute_one_pass (pass=pass@entry=0x1fa35e0) at
[...]/source-gcc/gcc/passes.c:2344
#6  0x00afeac2 in execute_ipa_pass_list (pass=0x1fa35e0) at
[...]/source-gcc/gcc/passes.c:2774
#7  0x00afeaee in execute_ipa_pass_list (pass=0x1fa3580) at
[...]/source-gcc/gcc/passes.c:2786
#8  0x007e3805 in ipa_passes () at
[...]/source-gcc/gcc/cgraphunit.c:2266
#9  symbol_table::compile (this=this@entry=0x768d10a8) at
[...]/source-gcc/gcc/cgraphunit.c:2405
#10 0x007e5b9a in symbol_table::finalize_compilation_unit
(this=0x768d10a8) at [...]/source-gcc/gcc/cgraphunit.c:2565
#11 0x00bc3a8a in compile_file () at
[...]/source-gcc/gcc/toplev.c:488
#12 0x005fd99d in do_compile () at
[...]/source-gcc/gcc/toplev.c:1987
#13 toplev::main (this=this@entry=0x7fffcd60, argc=argc@entry=27,
argv=argv@entry=0x7fffce68) at [...]/source-gcc/gcc/toplev.c:2095
#14 0x005ff4d7 in main (argc=27, argv=0x7fffce68) at
[...]/source-gcc/gcc/main.c:39

This is the first pass_ipa_pta, run within pass_ipa_oacc, if "-fopenacc" is in
effect.  (That is required for OpenACC kernels processing; Tom CCed for your
information.)

(gdb) break insert_vi_for_tree
Breakpoint 4 at 0xd94660: file [...]/source-gcc/gcc/tree-ssa-structalias.c,
line 2817.
(gdb) c
Continuing.
Breakpoint 4, insert_vi_for_tree (t=0x76aa50e0, vi=0x2091340)
Breakpoint 4, insert_vi_for_tree (t=0x768d7258, vi=0x2091430)
Breakpoint 4, insert_vi_for_tree (t=0x76a7f680, vi=0x2091480)
Breakpoint 4, insert_vi_for_tree (t=0x76a8ee00, vi=0x20914d0)
Breakpoint 4, insert_vi_for_tree (t=0x768d72d0, vi=0x20915c0)
Breakpoint 4, insert_vi_for_tree (t=0x76a7f500, vi=0x2091610)
Breakpoint 4, insert_vi_for_tree (t=0x76a8ed20, vi=0x2091660)
Breakpoint 4, insert_vi_for_tree (t=0x768d7258, vi=0x2091750)

That is, unexpectedly, the same "t" that we've already seen in the second hit
of that breakpoint, and thus the second gcc_assert will trigger:

/* Map from trees to variable infos.  */
static hash_map<tree, varinfo_t> *vi_for_tree;
[...]
/* Insert ID as the variable id for tree T in the vi_for_tree map.  */

static void
insert_vi_for_tree (tree t, varinfo_t vi)
{
  gcc_assert (vi);
  gcc_assert (!vi_for_tree->put (t, vi));
}

(gdb) call debug_tree(t)
 >
ignored VOID file
source-gcc/gcc/testsuite/gfortran.dg/gomp/gridify-1.f90 line 7 col 0
align 8 context >

[Bug other/71064] New: nvptx offloading: "long double" data type

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71064

Bug ID: 71064
   Summary: nvptx offloading: "long double" data type
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: openacc
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: amonakov at gcc dot gnu.org, bernds at gcc dot gnu.org,
jakub at gcc dot gnu.org, nathan at gcc dot gnu.org
Blocks: 70945
  Target Milestone: ---

Offloading to nvptx (that is, OpenACC only, currently) does not support the
"long double" data type:

int main()
{
  long double ld;

#pragma acc parallel copyout(ld)
  ld = 0.0L;

  if (ld != 0.0L)
__builtin_abort();

  return 0;
}

... results in: "lto1: fatal error: unsupported mode XF".

The PTX ISA does not support a floating point data type with more than 64-bits.
 (It's generally tuned for speed instead of precision, and does not strive for
full IEEE-754 conformance.)

We can either continue to error out (in a more user-friendly way).  Or,
(perhaps only for "-ffast-math" or similar?) implement "long double" with the
maximum available precision (that is, that of "double"; this will require
conversion at run time of "long double" values at the offloading boundary),
whilst perhaps emitting a warning about the reduced precision.  Unless that's
what's required because GCC generally does it that way, it does not appear
appealing to add a lot of "soft-fp" support code to emulate the target's
higher-precision "long double" data type for the nvptx offloading target.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70945
[Bug 70945] Offloading: compatibility of target and offloading toolchains

[Bug driver/68463] Offloading fails when some objects are compiled with LTO and some without

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68463

Thomas Schwinge  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 CC||jnorris at gcc dot gnu.org,
   ||tschwinge at gcc dot gnu.org
 Resolution|FIXED   |---
   Assignee|unassigned at gcc dot gnu.org  |jnorris at gcc dot 
gnu.org

--- Comment #6 from Thomas Schwinge  ---
Per
<http://news.gmane.org/find-root.php?message_id=%3C573200B5.7050302%40codesourcery.com%3E>:
PowerPC GNU/Linux target fixed on trunk in r236098; still needs to be fixed on
gcc-6-branch.

[Bug other/70945] New: Offloading: compatibility of target and offloading toolchains

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70945

Bug ID: 70945
   Summary: Offloading: compatibility of target and offloading
toolchains
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: openacc, openmp
  Severity: enhancement
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

It has been established that for offloading compilation, the target and
offloading toolchains need to be compatible (for example: data types; bit-wise
copying of data).

For OpenACC/OpenMP, offloading is implemented such that the target compiler
already applies certains transformations to the source code before handing over
to the offloading compilers an intermediate representation of the relevant
pieces.

Looking at one specific example: inclusion of  under the presence of
-ffinite-math-only (as implied by -ffast-math, or -Ofast).  The (glibc)
 will then (__FINITE_MATH_ONLY__) include  for
"special entry points to use when the compiler got told to only expect finite
results".  In the configuration that I'm looking at right now, this works by
diverting the math functions' assembler names from "[function]" to
"__[function]_finite".  This is a "bits/[...]" header file, that is applicable
only to this one target's glibc configuration.  For nvptx offloading, for
example, we use newlib which doesn't provide these finite math entry points, so
when using the "log" function in offloaded code, you'll see the compilation
fail because of "unresolved symbol __log_finite".

The problem basically is that there is a mis-match between early
transformations done by the target compiler (such as via header files, or done
early in the compiler internally), that are not actually valid for the
offloading compilers.  Instead of playing "rat race", trying to make the target
and offloading toolchains/compilers/ABIs match completely (which probably isn't
even possible in the general case), can we maybe find a better solution?

Of course, this problem is applicable only if we agree that it is valid to use
such functions in offlodead regions, which indeed is debatable for a lot of
standard library functions, but for math functions clearly users expect to be
allowed to use them.  Also consider Fortran, where such functions are actually
part of the language.

[Bug fortran/70895] OpenACC: loop reduction does not work. Output is zero.

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70895

--- Comment #3 from Thomas Schwinge  ---
(In reply to cesar from comment #2)
> Furthermore, as Thomas mentioned, gcc-6 does not automatically assign
> parallelism to loops inside parallel regions.

:-) GCC 6.1 does do that that.

> Consequently, you need to
> explicitly use num_gangs, num_workers and vector_length to determine the
> amount of parallelism and gang, worker and vector to partition the acc loops
> accordingly.

GCC 6.1 by default will configure nvptx offloading for 32 gangs, 32 workers,
and a vector length of 32 (so, you don't need to specify "num_gangs()
num_workers() vector_length()" clauses).  What it will not do (and what was the
point of my earlier note in #c1), is assign more than one of OpenACC's
parallelism levels (gang, worker, vector) to a one-level loop constructs, which
is why you'll want to specify "gang worker vector" clauses for the loop
construct.

[Bug target/70860] [nvptx] Revisit cfun->machine->doing_call

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70860

--- Comment #1 from Thomas Schwinge  ---
Author: tschwinge
Date: Mon May  2 11:25:17 2016
New Revision: 235748

URL: https://gcc.gnu.org/viewcvs?rev=235748=gcc=rev
Log:
[PR target/70860] [nvptx] Handle NULL cfun in nvptx_libcall_value

gcc/
PR target/70860
* config/nvptx/nvptx.c (nvptx_libcall_value): Handle NULL cfun.
(nvptx_function_value): Assert non-NULL cfun.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/nvptx/nvptx.c

[Bug fortran/70895] OpenACC: loop reduction does not work. Output is zero.

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70895

Thomas Schwinge  changed:

   What|Removed |Added

   Keywords||openacc
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-05-02
 CC||cesar at gcc dot gnu.org,
   ||nathan at gcc dot gnu.org,
   ||tschwinge at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |tschwinge at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Thomas Schwinge  ---
(In reply to Ralph Trenkler from comment #0)
> Created attachment 38389 [details]
> compiler configure command line, compiler call, program in f90, *.i-file

Thanks for that!

> Problem with OpenACC: The output of the attached fortran 90 program
> "acc-test-04.f90" is zero but not "pi" (3.14...), as it should be. The
> compiler version is 6.1.0.

There is no "copy(pi)" or "reduction(+:pi)" clause on the outer "acc parallel"
construct, so the offloaded computation of "pi" will not be copied back; hence
the result of zero.  (Cesar CCed; please shout if I'm interpreting the OpenACC
2.0a specification wrongly.)

Also, due to the gang/worker/vector loop scheduling algorithm that's currently
used, you'll want to add explicit "gang worker vector" clauses to the one-level
"acc loop" construct.  (Nathan CCed for your information.)

Do you have any further questions?

[Bug target/70860] New: [nvptx] Revisit cfun->machine->doing_call

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70860

Bug ID: 70860
   Summary: [nvptx] Revisit cfun->machine->doing_call
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: amonakov at gcc dot gnu.org, bernds at gcc dot gnu.org,
nathan at gcc dot gnu.org
  Target Milestone: ---
Target: nvptx

The r235511 changes for PR70760 exposed a problem in
gcc/config/nvptx/nvptx.c:nvptx_libcall_value, and Richard generally found that
one "fishy", and "suggest[ed] to remove cfun->machine->doing_call and revisit
the reason why it was added for PTX", see
<http://news.gmane.org/find-root.php?message_id=%3Calpine.LSU.2.11.1604281241260.13384%40t29.fhfr.qr%3E>
and following.

[Bug middle-end/70828] broken array-type subarrays inside acc data in openacc

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70828

Thomas Schwinge  changed:

   What|Removed |Added

   Keywords||openmp
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-04-28
 CC||jakub at gcc dot gnu.org
   Assignee|cesar at gcc dot gnu.org   |unassigned at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Thomas Schwinge  ---
(In reply to cesar from comment #0)
> Created attachment 38351 [details]
> broken subarray

Translating that one to OpenMP ("acc data copy(a[10:80])" -> "omp target data
map(a[10:80])", and "acc parallel loop" -> "omp target"), the issue also
reproduces for OpenMP.

> Given an array-typed subarray with a non-zero base element on an acc data
> construct, the gimplifier will implicitly add a pcopy clause for any
> parallel and kernels construct which uses that array. The pcopy is correct,
> but this pcopy expects the entire array to be present on the accelerator.
> This ultimately results in a runtime failure when the base of the subarray
> is not element zero.
> 
> This problem can be reproduced with the attached test case in trunk and
> gcc-6.

OpenACC 2.0a says that "[...] the compiler will implicitly determine data
attributes for variables that are referenced in the compute construct that do
not appear in a data clause on the compute construct or a lexically containing
data construct and do not have predetermined data attributes [...]".  Indeed we
here have a "lexically containing data construct", so the compiler should use
that instead of implicitly determining conflicting (whole array) data
attributes.

Jakub, what's your take for OpenMP?  From a quick scan of OpenMP 4.5, 2.15.5
"Data-mapping Attribute Rules and Clauses", in combination with 2.10.4 "target
Construct", to me it also appears as if the intention is that the outer target
data construct already defines the definitive data attributes for the array
inside the target region, without wanting the compiler to implicitly determine
conflicting (whole array) data attributes for the target region?

[Bug other/51153] OpenACC implementation

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51153

Thomas Schwinge  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |6.0

--- Comment #6 from Thomas Schwinge  ---
(In reply to Tobias Burnus from comment #4)
> The basic implementation is now (= GCC 5) in:

> See also https://gcc.gnu.org/wiki/OpenACC

Compared to GCC 5, the GCC 6 release series includes a much improved
implementation of the OpenACC 2.0a specification.  See
 or the OpenACC wiki page for a
high-level overview.

> I think this PR can now be closed
> and instead one could concentrate on the remaining issues elsewhere (PRs
> with 'openacc' keyword, pending patches).

ACK.

[Bug testsuite/68242] [gomp4] FAIL: libgomp.oacc-c-c++-common/reduction-2.c -DACC_DEVICE_TYPE_host=1 execution test

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68242

Thomas Schwinge  changed:

   What|Removed |Added

  Component|libgomp |testsuite
   Assignee|nathan at gcc dot gnu.org  |cesar at gcc dot gnu.org
   Target Milestone|--- |7.0

--- Comment #5 from Thomas Schwinge  ---
(In reply to vries from comment #0)
> I observe when testing gomp4_0-branch on x86_64 with -m32:
> ...
> FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/reduction-2.c
> -DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1 -foffload=disable execution test
> ...

(In reply to Thomas Schwinge from comment #2)
> Yes, I had reported that to Cesar in
>  schwinge.homeip.net%3E>, but it has not yet been fixed.  (Same for the other
> items that I reported in this email.)

Now seen on trunk.

[Bug middle-end/70626] bogus results in 'acc parallel loop' reductions

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70626

Thomas Schwinge  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-04-12
 Ever confirmed|0   |1

[Bug tree-optimization/70545] [openacc] gfortran.dg/goacc/kernels-loop-n.f95 not parallelized

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70545

Thomas Schwinge  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-04-11
 CC||tschwinge at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug fortran/70598] Fortran OpenACC host_data construct ICE

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70598

Thomas Schwinge  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-04-08
   Target Milestone|--- |7.0
 Ever confirmed|0   |1

[Bug fortran/70598] New: Fortran OpenACC host_data construct ICE

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70598

Bug ID: 70598
   Summary: Fortran OpenACC host_data construct ICE
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: openacc
  Severity: major
  Priority: P3
 Component: fortran
  Assignee: cltang at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

As once reported in
<http://news.gmane.org/find-root.php?message_id=%3C87r3j4lcrd.fsf%40kepler.schwinge.homeip.net%3E>
and thereabouts, there is no execution (libgomp) testing of the Fortran OpenACC
host_data construct, and the one test case present on gomp-4_0-branch,
libgomp.oacc-fortran/host_data-1.f90, runs into an ICE (for trunk as well as
gomp-4_0-branch).  Please have a look at that, and also increase test coverage
(for example, by translating C/C++ execution (libgomp) test cases, if
applicable).

As the implementation of OpenACC host_data/use_device has been completely
re-done during patch review (to match OpenMP's use_device_ptr clause), I
suppose it's possible that there is some middle end infrastructure missing to
deal with constructs generated by the Fortran front end.  Maybe Jakub can
advise on that, in case he's already started implementing the Fortran support
for OpenMP (which is currently missing).  Or maybe the ICE is due to something
completely different.  ;-)

[Bug testsuite/70580] [gomp4] -O0 execution testing FAILs for libgomp.oacc-c-c++-common/if-1.c

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70580

Thomas Schwinge  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Component|middle-end  |testsuite
 Resolution|--- |FIXED

--- Comment #2 from Thomas Schwinge  ---
.

[Bug testsuite/70579] [gomp4] -O0 execution testing FAILs for libgomp.oacc-c-c++-common/host_data-1.c

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70579

Thomas Schwinge  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Component|middle-end  |testsuite
 Resolution|--- |FIXED

--- Comment #2 from Thomas Schwinge  ---
.

[Bug middle-end/70579] [gomp4] -O0 execution testing FAILs for libgomp.oacc-c-c++-common/host_data-1.c

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70579

--- Comment #1 from Thomas Schwinge  ---
Author: tschwinge
Date: Fri Apr  8 08:31:40 2016
New Revision: 234823

URL: https://gcc.gnu.org/viewcvs?rev=234823=gcc=rev
Log:
[PR testsuite/70579, PR testsuite/70580] Fix test cases failing because of the
compiler's "avoid offloading" decision

libgomp/
PR testsuite/70579
PR testsuite/70580
* testsuite/libgomp.oacc-c-c++-common/host_data-1.c: Initialize
the runtime for acc_device_nvidia.
* testsuite/libgomp.oacc-c-c++-common/if-1.c: Cope with
"avoid offloading" situation.
* libgomp.texi (Enabling OpenACC): Elaborate on interactions of
"avoid offloading".

Modified:
branches/gomp-4_0-branch/libgomp/ChangeLog.gomp
branches/gomp-4_0-branch/libgomp/libgomp.texi
   
branches/gomp-4_0-branch/libgomp/testsuite/libgomp.oacc-c-c++-common/host_data-1.c
branches/gomp-4_0-branch/libgomp/testsuite/libgomp.oacc-c-c++-common/if-1.c

[Bug middle-end/70580] [gomp4] -O0 execution testing FAILs for libgomp.oacc-c-c++-common/if-1.c

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70580

--- Comment #1 from Thomas Schwinge  ---
Author: tschwinge
Date: Fri Apr  8 08:31:40 2016
New Revision: 234823

URL: https://gcc.gnu.org/viewcvs?rev=234823=gcc=rev
Log:
[PR testsuite/70579, PR testsuite/70580] Fix test cases failing because of the
compiler's "avoid offloading" decision

libgomp/
PR testsuite/70579
PR testsuite/70580
* testsuite/libgomp.oacc-c-c++-common/host_data-1.c: Initialize
the runtime for acc_device_nvidia.
* testsuite/libgomp.oacc-c-c++-common/if-1.c: Cope with
"avoid offloading" situation.
* libgomp.texi (Enabling OpenACC): Elaborate on interactions of
"avoid offloading".

Modified:
branches/gomp-4_0-branch/libgomp/ChangeLog.gomp
branches/gomp-4_0-branch/libgomp/libgomp.texi
   
branches/gomp-4_0-branch/libgomp/testsuite/libgomp.oacc-c-c++-common/host_data-1.c
branches/gomp-4_0-branch/libgomp/testsuite/libgomp.oacc-c-c++-common/if-1.c

[Bug middle-end/70580] [gomp4] -O0 execution testing FAILs for libgomp.oacc-c-c++-common/if-1.c

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70580

Thomas Schwinge  changed:

   What|Removed |Added

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

[Bug middle-end/70579] [gomp4] -O0 execution testing FAILs for libgomp.oacc-c-c++-common/host_data-1.c

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70579

Thomas Schwinge  changed:

   What|Removed |Added

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

[Bug middle-end/70580] New: [gomp4] -O0 execution testing FAILs for libgomp.oacc-c-c++-common/if-1.c

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70580

Bug ID: 70580
   Summary: [gomp4] -O0 execution testing FAILs for
libgomp.oacc-c-c++-common/if-1.c
   Product: gcc
   Version: 6.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: ---

PASSes in trunk.

[Bug middle-end/70579] New: [gomp4] -O0 execution testing FAILs for libgomp.oacc-c-c++-common/host_data-1.c

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70579

Bug ID: 70579
   Summary: [gomp4] -O0 execution testing FAILs for
libgomp.oacc-c-c++-common/host_data-1.c
   Product: gcc
   Version: 6.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: ---

PASSes in trunk.

[Bug libgomp/69414] [OpenACC] "!$acc update self" does not provide expected result

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69414

Thomas Schwinge  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
Version|5.3.0   |5.0
 Resolution|--- |FIXED
   Assignee|jnorris at gcc dot gnu.org |tschwinge at gcc dot 
gnu.org
   Target Milestone|--- |5.4

--- Comment #6 from Thomas Schwinge  ---
In r234806 now also fixed on gcc-5-branch.

[Bug libgomp/69414] [OpenACC] "!$acc update self" does not provide expected result

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69414

--- Comment #5 from Thomas Schwinge  ---
Author: tschwinge
Date: Thu Apr  7 11:43:30 2016
New Revision: 234806

URL: https://gcc.gnu.org/viewcvs?rev=234806=gcc=rev
Log:
[PR libgomp/69414] Fix handling of subarrays with update directive

libgomp/
Backport trunk r234428:

2016-03-23  James Norris  
Daichi Fukuoka 

PR libgomp/69414
* oacc-mem.c (delete_copyout, update_dev_host): Fix device address.
* testsuite/libgomp.oacc-c-c++-common/update-1.c: Additional tests.
* testsuite/libgomp.oacc-c-c++-common/update-1-2.c: Likewise.
* testsuite/libgomp.oacc-fortran/update-1.f90: New file.

Added:
branches/gcc-5-branch/libgomp/testsuite/libgomp.oacc-fortran/update-1.f90
Modified:
branches/gcc-5-branch/libgomp/ChangeLog
branches/gcc-5-branch/libgomp/oacc-mem.c
   
branches/gcc-5-branch/libgomp/testsuite/libgomp.oacc-c-c++-common/update-1-2.c
   
branches/gcc-5-branch/libgomp/testsuite/libgomp.oacc-c-c++-common/update-1.c

[Bug ipa/70348] [6 Regression][openacc] ICE in visit_ref_for_mod_analysis, at ipa-prop.c

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70348

Thomas Schwinge  changed:

   What|Removed |Added

   Assignee|tschwinge at gcc dot gnu.org   |cesar at gcc dot gnu.org

--- Comment #8 from Thomas Schwinge  ---
Cesar is now looking into resolving the OpenACC reduction issues.