Re: [Patch] Fortran: Support OpenMP's 'allocate' directive for stack vars

[Thomas Schwinge]

Hi Tobias!

On 2023-10-13T15:29:52+0200, Tobias Burnus  wrote:
> => Updated patch attached

When cherry-picking this commit 2d3dbf0eff668bed5f5f168b3cafd8590c54
"Fortran: Support OpenMP's 'allocate' directive for stack vars" on top of
slightly older GCC sources (mentioning that just in case that's
relevant), in a configuration with offloading enabled (only), I see:

+FAIL: gfortran.dg/gomp/allocate-13.f90   -O  (internal compiler error: 
tree code 'statement_list' is not supported in LTO streams)
+FAIL: gfortran.dg/gomp/allocate-13.f90   -O  (test for excess errors)

during IPA pass: modref
[...]/gcc/testsuite/gfortran.dg/gomp/allocate-13.f90:10:3: internal 
compiler error: tree code 'statement_list' is not supported in LTO streams
0x13374fd lto_write_tree
[...]/gcc/lto-streamer-out.cc:561
0x13374fd lto_output_tree_1
[...]/gcc/lto-streamer-out.cc:599
0x133f55b DFS::DFS(output_block*, tree_node*, bool, bool, bool)
[...]/gcc/lto-streamer-out.cc:899
0x1340287 lto_output_tree(output_block*, tree_node*, bool, bool)
[...]/gcc/lto-streamer-out.cc:1865
0x134197a output_function
[...]/gcc/lto-streamer-out.cc:2436
0x134197a lto_output()
[...]/gcc/lto-streamer-out.cc:2807
0x13d0551 write_lto
[...]/gcc/passes.cc:2774
0x13d0551 ipa_write_summaries_1
[...]/gcc/passes.cc:2838
0x13d0551 ipa_write_summaries()
[...]/gcc/passes.cc:2894
0x1002f2c ipa_passes
[...]/gcc/cgraphunit.cc:2251
0x1002f2c symbol_table::compile()
[...]/gcc/cgraphunit.cc:2331
0x10056b7 symbol_table::compile()
[...]/gcc/cgraphunit.cc:2311
0x10056b7 symbol_table::finalize_compilation_unit()
[...]/gcc/cgraphunit.cc:2583

Similarly:

+FAIL: libgomp.fortran/allocate-6.f90   -O  (internal compiler error: tree 
code 'statement_list' is not supported in LTO streams)

+FAIL: libgomp.fortran/allocate-7.f90   -O  (internal compiler error: tree 
code 'statement_list' is not supported in LTO streams)


Grüße
 Thomas


> Fortran: Support OpenMP's 'allocate' directive for stack vars
>
> gcc/fortran/ChangeLog:
>
>   * gfortran.h (ext_attr_t): Add omp_allocate flag.
>   * match.cc (gfc_free_omp_namelist): Void deleting same
>   u2.allocator multiple times now that a sequence can use
>   the same one.
>   * openmp.cc (gfc_match_omp_clauses, gfc_match_omp_allocate): Use
>   same allocator expr multiple times.
>   (is_predefined_allocator): Make static.
>   (gfc_resolve_omp_allocate): Update/extend restriction checks;
>   remove sorry message.
>   (resolve_omp_clauses): Reject corarrays in allocate/allocators
>   directive.
>   * parse.cc (check_omp_allocate_stmt): Permit procedure pointers
>   here (rejected later) for less misleading diagnostic.
>   * trans-array.cc (gfc_trans_auto_array_allocation): Propagate
>   size for GOMP_alloc and location to which it should be added to.
>   * trans-decl.cc (gfc_trans_deferred_vars): Handle 'omp allocate'
>   for stack variables; sorry for static variables/common blocks.
>   * trans-openmp.cc (gfc_trans_omp_clauses): Evaluate 'allocate'
>   clause's allocator only once; fix adding expressions to the
>   block.
>   (gfc_trans_omp_single): Pass a block to gfc_trans_omp_clauses.
>
> gcc/ChangeLog:
>
>   * gimplify.cc (gimplify_bind_expr): Handle Fortran's
>   'omp allocate' for stack variables.
>
> libgomp/ChangeLog:
>
>   * libgomp.texi (OpenMP Impl. Status): Mention that Fortran now
>   supports the allocate directive for stack variables.
>   * testsuite/libgomp.fortran/allocate-5.f90: New test.
>   * testsuite/libgomp.fortran/allocate-6.f90: New test.
>   * testsuite/libgomp.fortran/allocate-7.f90: New test.
>   * testsuite/libgomp.fortran/allocate-8.f90: New test.
>
> gcc/testsuite/ChangeLog:
>
>   * c-c++-common/gomp/allocate-14.c: Fix directive name.
>   * c-c++-common/gomp/allocate-15.c: Likewise.
>   * c-c++-common/gomp/allocate-9.c: Fix comment typo.
>   * gfortran.dg/gomp/allocate-4.f90: Remove sorry dg-error.
>   * gfortran.dg/gomp/allocate-7.f90: Likewise.
>   * gfortran.dg/gomp/allocate-10.f90: New test.
>   * gfortran.dg/gomp/allocate-11.f90: New test.
>   * gfortran.dg/gomp/allocate-12.f90: New test.
>   * gfortran.dg/gomp/allocate-13.f90: New test.
>   * gfortran.dg/gomp/allocate-14.f90: New test.
>   * gfortran.dg/gomp/allocate-15.f90: New test.
>   * gfortran.dg/gomp/allocate-8.f90: New test.
>   * gfortran.dg/gomp/allocate-9.f90: New test.
>
>  gcc/fortran/gfortran.h   |   1 +
>  gcc/fortran/match.cc |   9 +-
>  gcc/fortran/openmp.cc|  62 +++-
>  gcc/fortran/parse.cc |   8 +-
>  gcc/fortran/trans-array.cc 

Re: [PING] [PATCH] Harmonize headers between both dg-extract-results scripts

[Thomas Schwinge]

Hi!

On 2023-09-29T08:52:24-0600, Jeff Law  wrote:
> On 9/29/23 02:19, Paul Iannetta wrote:
>> On Tue, Sep 26, 2023 at 08:29:11AM -0600, Jeff Law wrote:
>>> On 9/25/23 03:55, Paul Iannetta wrote:
 On Mon, Sep 18, 2023 at 08:39:34AM +0200, Paul Iannetta wrote:
> On Thu, Sep 14, 2023 at 04:24:33PM +0200, Paul Iannetta wrote:
>> This is a small patch so that both dg-extract-results.py and
>> dg-extract-results.sh share the same header.  In particular, it fixes
>> the fact that the regexp r'^Test Run By (\S+) on (.*)$' was never
>> matched in the python file.

Thanks for looking into this!

I confirm that 'Test run by' lines now appear in
'contrib/dg-extract-results.py'-filtered '*.sum' files.

However, a number of upper-case 'Test Run By' instances do remain in GCC
sources:

$ git grep --cached 'Test Run By'
contrib/dg-extract-results.py:# and in which the second is the 
associated 'Test Run By' line.
contrib/dglib.pm:   } elsif(/^(Test Run By \S+ on|runtest 
completed at) ... (.{3}) (\d{1,2}) (\d{1,2}):(\d{1,2}):(\d{1,2}) (\d{4})/) {
gcc/testsuite/ada/acats/run_all.sh:display "Test Run By $USER on `date`"
gotools/Makefile.am:@echo "Test Run By $${USER} on `date`" > 
gotools.head
gotools/Makefile.in:@NATIVE_TRUE@   @echo "Test Run By $${USER} on 
`date`" > gotools.head
libgo/Makefile.am:  @echo "Test Run By $${USER} on `date`" > libgo.head
libgo/Makefile.in:  @echo "Test Run By $${USER} on `date`" > libgo.head

..., and I observe the following "regression" via the upper-case instance
in 'gcc/testsuite/ada/acats/run_all.sh':

--- [...]/gcc/testsuite/ada/acats/acats.sum
+++ [...]/gcc/testsuite/ada/acats/acats.sum
@@ -1,4 +1,3 @@
-Test Run By tschwing on Sun Sep 17 22:02:20 CEST 2023
=== acats configuration ===
[...]

(The upper-case 'echo's in gotools ('[...]/gotools/gotools.sum') and
libgo ('[...]/[...]/libgo/libgo.sum') evidently are not affected by your
change; presumably this testing doesn't use
'contrib/dg-extract-results.py'.)

Is this (case variants) maybe something that has changed in DejaGnu at
some point in time?  (I have not checked.)

I suggest that we adapt all remaining upper-case instances in GCC,
similar to your change.  And/or, as applicable, recognize both variants
(or ignore case distinctions generally)?


> By the way, the bash script dg-extract-results.sh checks whether
> python is available by invoking python.  However, it seems that the
> policy on newer machines is to not provide python as a symlink (at
> least on Ubuntu 22.04 and above; and RHEL 8).  Therefore, we might
> want to also check against python3 so that the bash script does not
> fail to find python even though it is available.

See  "'python' vs. 'python3'".


>> May I ask to you commit it to trunk on my behalf?

> Done.  Thanks for letting me know you didn't have write access.

Given Paul's (and colleagues'?) ongoing work on GCC (Kalray KVX back end,
complex numbers support), is it maybe now time to enable Git write access
for him (them?)?

, "write after approval".


>> Author: Paul Iannetta 
>> Date:   Thu Sep 14 15:43:58 2023 +0200
>>
>>   Harmonize headers between both dg-extract-results scripts
>>
>>   The header of the python version looked like:
>>   Target is ...
>>   Host   is ...
>>   The header of the bash version looked like:
>>   Test run by ... on ...
>>   Target is ...
>>
>>   After this change both headers look like:
>>   Test run by ... on ...
>>   Target is ...
>>   Host   is ...
>>
>>   The order of the tests is not the same but since dg-cmp-results.sh 
>> it
>>   does not matter much.
>>
>>   contrib/ChangeLog:
>>
>>   2023-09-14  Paul Iannetta  
>>
>>   * dg-extract-results.py: Print the "Test run" line.
>>   * dg-extract-results.sh: Print the "Host" line.

>> diff --git a/contrib/dg-extract-results.py 
>> b/contrib/dg-extract-results.py
>> index 30aa68771d4..34da1808c5f 100644
>> --- a/contrib/dg-extract-results.py
>> +++ b/contrib/dg-extract-results.py
>> @@ -113,7 +113,7 @@ class Prog:
>>  # Whether to create .sum rather than .log output.
>>  self.do_sum = True
>>  # Regexps used while parsing.
>> -self.test_run_re = re.compile (r'^Test Run By (\S+) on (.*)$')
>> +self.test_run_re = re.compile (r'^Test run by (\S+) on (.*)$')
>>  self.tool_re = re.compile (r'^\t\t=== (.*) tests ===$')
>>  self.result_re = re.compile 
>> (r'^(PASS|XPASS|FAIL|XFAIL|UNRESOLVED'
>>   
>> r'|WARNING|ERROR|UNSUPPORTED|UNTESTED'
>> diff --git a/contrib/dg-extrac

Re: [Patch] OpenMP: Add ME support for 'omp allocate' stack variables

[Thomas Schwinge]

Hi Tobias!

No need to change anything now, but in case that's useful later:

On 2023-09-18T14:22:50+0200, Tobias Burnus  wrote:
> --- /dev/null
> +++ b/libgomp/testsuite/libgomp.c/allocate-4.c
> @@ -0,0 +1,84 @@
> +/* TODO: move to ../libgomp.c-c++-common once C++ is implemented. */
> +/* NOTE: { target c } is unsupported with with the C compiler.  */
> +[...]

..., just noting that '{ target c }', '{ target c++ }' are trivial to
implement; see libgomp OpenACC testing:

libgomp/testsuite/libgomp.oacc-c/c.exp:proc check_effective_target_c { } {
libgomp/testsuite/libgomp.oacc-c/c.exp-return 1
libgomp/testsuite/libgomp.oacc-c/c.exp-}
libgomp/testsuite/libgomp.oacc-c/c.exp:proc check_effective_target_c++ { } {
libgomp/testsuite/libgomp.oacc-c/c.exp-return 0
libgomp/testsuite/libgomp.oacc-c/c.exp-}

libgomp/testsuite/libgomp.oacc-c++/c++.exp:proc check_effective_target_c { } {
libgomp/testsuite/libgomp.oacc-c++/c++.exp-return 0
libgomp/testsuite/libgomp.oacc-c++/c++.exp-}
libgomp/testsuite/libgomp.oacc-c++/c++.exp:proc check_effective_target_c++ { } {
libgomp/testsuite/libgomp.oacc-c++/c++.exp-return 1
libgomp/testsuite/libgomp.oacc-c++/c++.exp-}


Grüße
 Thomas


> --- /dev/null
> +++ b/libgomp/testsuite/libgomp.c/allocate-5.c
> @@ -0,0 +1,126 @@
> +/* TODO: move to ../libgomp.c-c++-common once C++ is implemented. */
> +/* NOTE: { target c } is unsupported with with the C compiler.  */
> +[...]

> --- /dev/null
> +++ b/libgomp/testsuite/libgomp.c/allocate-6.c
> @@ -0,0 +1,319 @@
> +/* TODO: move to ../libgomp.c-c++-common once C++ is implemented. */
> +/* NOTE: { target c } is unsupported with with the C compiler.  */
> +[...]
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955

Re: [Patch] OpenMP: Add ME support for 'omp allocate' stack variables

[Thomas Schwinge]

Hi Tobias!

On 2023-10-18T11:53:30+0200, Tobias Burnus  wrote:
> On 18.10.23 11:44, Thomas Schwinge wrote:
>> No need to change anything now, but in case that's useful later:
>> [...]
>> ..., just noting that '{ target c }', '{ target c++ }' are trivial to
>> implement; see libgomp OpenACC testing:
>>
>> libgomp/testsuite/libgomp.oacc-c/c.exp:proc check_effective_target_c { } {
>
> Shouldn't we rather do something like the following (untested)?
>
> --- a/libgomp/testsuite/lib/libgomp.exp
> +++ b/libgomp/testsuite/lib/libgomp.exp
> @@ -26,2 +26,3 @@ load_gcc_lib timeout.exp
>   load_gcc_lib file-format.exp
> +load_gcc_lib target-supports.exp
>   load_gcc_lib target-supports-dg.exp

'gcc/testsuite/lib/target-supports.exp' defines:

# Return 1 if the language for the compiler under test is C.

proc check_effective_target_c { } {
global tool
if [string match $tool "gcc"] {
return 1
}
 return 0
}

# Return 1 if the language for the compiler under test is C++.

proc check_effective_target_c++ { } {
global tool
if { [string match $tool "g++"] || [string match $tool "libstdc++"] } {
return 1
}
 return 0
}

However, (per my understanding; not verified) 'tool == libgomp' for
libgomp testing, so that doesn't work.


Grüße
 Thomas
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955

Re: [Patch] nvptx: Use fatal_error when -march= is missing not an assert [PR111093]

[Thomas Schwinge]

Hi Tobias!

On 2023-10-16T11:18:45+0200, Tobias Burnus  wrote:
> While mkoffload ensures that there is always a -march=, nvptx's
> cc1 can also be run directly.
>
> In my case, I wanted to know which target-specific #define are
> available; hence, I did run:
>accel/nvptx-none/cc1 -E -dM < /dev/null
> which gave an ICE. After some debugging, the reasons was
> clear (missing -march=) but somehow a (fatal) error would have been
> nicer than an ICE + debugging.
>
> OK for mainline?

Yes, thanks.  I think I prefer this over hard-coding some default
'ptx_isa_option' -- but may be convinced otherwise (incremental change),
if that's maybe more convenient for others?  (Roger?)


Grüße
 Thomas


> nvptx: Use fatal_error when -march= is missing not an assert [PR111093]
>
> gcc/ChangeLog:
>
>   PR target/111093
>   * config/nvptx/nvptx.cc (nvptx_option_override): Issue fatal error
>   instead of an assert ICE when no -march= has been specified.
>
> diff --git a/gcc/config/nvptx/nvptx.cc b/gcc/config/nvptx/nvptx.cc
> index edef39fb5e1..634c31673be 100644
> --- a/gcc/config/nvptx/nvptx.cc
> +++ b/gcc/config/nvptx/nvptx.cc
> @@ -335,8 +335,9 @@ nvptx_option_override (void)
>init_machine_status = nvptx_init_machine_status;
>
>/* Via nvptx 'OPTION_DEFAULT_SPECS', '-misa' always appears on the command
> - line.  */
> -  gcc_checking_assert (OPTION_SET_P (ptx_isa_option));
> + line; but handle the case that the compiler is not run via the driver.  
> */
> +  if (!OPTION_SET_P (ptx_isa_option))
> +fatal_error (UNKNOWN_LOCATION, "%<-march=%> must be specified");
>
>handle_ptx_version_option ();
>
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955

Enable top-level recursive 'autoreconf' (was: Hints on reconfiguring GCC)

[Thomas Schwinge]

Hi!

On 2023-10-18T15:42:18+0100, R jd <3246251196r...@gmail.com> wrote:
> I guess I can ask, why there is not a recursive approach for configuring
> GCC. e.g. AC_SUBDIRS in the top level?

('AC_CONFIG_SUBDIRS' you mean.)  You know, often it just takes someone to
ask the right questions...  ;-)

What do people think about the attached
"Enable top-level recursive 'autoreconf'"?  Only lightly tested, so far.


Grüße
 Thomas


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
>From 43127e5643337ca407071ad93bccbc716024352e Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Thu, 19 Oct 2023 10:28:30 +0200
Subject: [PATCH] Enable top-level recursive 'autoreconf'

	* configure.ac: At end of file, instantiate 'AC_CONFIG_SUBDIRS'
	for all relevant directories.
	* configure: Regenerate.
---
 configure| 102 ++-
 configure.ac |  36 ++
 2 files changed, 136 insertions(+), 2 deletions(-)

diff --git a/configure b/configure
index 8fc163d36bd..fcb4d591334 100755
--- a/configure
+++ b/configure
@@ -584,7 +584,8 @@ PACKAGE_URL=
 
 ac_unique_file="move-if-change"
 enable_option_checking=no
-ac_subst_vars='LTLIBOBJS
+ac_subst_vars='subdirs
+LTLIBOBJS
 LIBOBJS
 compare_exclusions
 stage2_werror_flag
@@ -909,7 +910,37 @@ READELF_FOR_TARGET
 STRIP_FOR_TARGET
 WINDRES_FOR_TARGET
 WINDMC_FOR_TARGET'
-
+ac_subdirs_all='c++tools
+fixincludes
+gcc
+gcc/m2
+gnattools
+gotools
+intl
+libada
+libatomic
+libbacktrace
+libcc1
+libcody
+libcpp
+libdecnumber
+libffi
+libgcc
+libgfortran
+libgm2
+libgo
+libgomp
+libiberty
+libitm
+libobjc
+libphobos
+libquadmath
+libsanitizer
+libssp
+libstdc++-v3
+libvtv
+lto-plugin
+zlib'
 
 # Initialize some variables set by options.
 ac_init_help=
@@ -20081,3 +20112,70 @@ if test -n "$ac_unrecognized_opts" && test "$enable_option_checking" != no; then
 $as_echo "$as_me: WARNING: unrecognized options: $ac_unrecognized_opts" >&2;}
 fi
 
+
+# Enable top-level recursive 'autoreconf' by enumerating all relevant
+# directories here.  This is intentionally done at end of 'configure.ac',
+# *after* 'AC_OUTPUT', so that we don't attempt to prematurely 'configure'
+# these directories when the top-level 'configure' is invoked.
+subdirs="$subdirs c++tools"
+
+subdirs="$subdirs fixincludes"
+
+subdirs="$subdirs gcc"
+
+subdirs="$subdirs gcc/m2"
+
+subdirs="$subdirs gnattools"
+
+subdirs="$subdirs gotools"
+
+subdirs="$subdirs intl"
+
+subdirs="$subdirs libada"
+
+subdirs="$subdirs libatomic"
+
+subdirs="$subdirs libbacktrace"
+
+subdirs="$subdirs libcc1"
+
+subdirs="$subdirs libcody"
+
+subdirs="$subdirs libcpp"
+
+subdirs="$subdirs libdecnumber"
+
+subdirs="$subdirs libffi"
+
+subdirs="$subdirs libgcc"
+
+subdirs="$subdirs libgfortran"
+
+subdirs="$subdirs libgm2"
+
+subdirs="$subdirs libgo"
+
+subdirs="$subdirs libgomp"
+
+subdirs="$subdirs libiberty"
+
+subdirs="$subdirs libitm"
+
+subdirs="$subdirs libobjc"
+
+subdirs="$subdirs libphobos"
+
+subdirs="$subdirs libquadmath"
+
+subdirs="$subdirs libsanitizer"
+
+subdirs="$subdirs libssp"
+
+subdirs="$subdirs libstdc++-v3"
+
+subdirs="$subdirs libvtv"
+
+subdirs="$subdirs lto-plugin"
+
+subdirs="$subdirs zlib"
+
diff --git a/configure.ac b/configure.ac
index 1d16530140a..0d37d30196e 100644
--- a/configure.ac
+++ b/configure.ac
@@ -3944,3 +3944,39 @@ AC_CONFIG_FILES([Makefile],
extrasub_host="$extrasub_host"
extrasub_target="$extrasub_target"])
 AC_OUTPUT
+
+# Enable top-level recursive 'autoreconf' by enumerating all relevant
+# directories here.  This is intentionally done at end of 'configure.ac',
+# *after* 'AC_OUTPUT', so that we don't attempt to prematurely 'configure'
+# these directories when the top-level 'configure' is invoked.
+AC_CONFIG_SUBDIRS([c++tools])
+AC_CONFIG_SUBDIRS([fixincludes])
+AC_CONFIG_SUBDIRS([gcc])
+AC_CONFIG_SUBDIRS([gcc/m2])
+AC_CONFIG_SUBDIRS([gnattools])
+AC_CONFIG_SUBDIRS([gotools])
+AC_CONFIG_SUBDIRS([intl])
+AC_CONFIG_SUBDIRS([libada])
+AC_CONFIG_SUBDIRS([libatomic])
+AC_CONFIG_SUBDIRS([libbacktrace])
+AC_CONFIG_SUBDIRS([libcc1])
+AC_CONFIG_SUBDIRS([libcody])
+AC_CONFIG_SUBDIRS([libcpp])
+AC_CONFIG_SUBDIRS([libdecnumber])
+AC_CONFIG_SUBDIRS([libffi])
+AC_CONFIG_SUBDIRS([libgcc])
+AC_CONFIG_SUBDIRS([libgfortran])
+AC_CONFIG_SUBDIRS([libgm2])
+AC_CONFIG_SUBDIRS([libgo])
+AC_CONFIG_SUBDIRS([libgomp])
+AC_CONFIG_SUBDIRS([libiberty])
+AC_CONFIG_SUBDIRS([libitm])
+AC_CONFIG_SUBDIRS([libobjc])
+AC_CONFIG_SUBDIRS([libphobos])
+AC_CONFIG_SUBDIRS([libquadmath])
+AC_CONFIG_SUBDIRS([libsanitizer])
+AC_CONFIG_SUBDIRS([libssp])
+AC_CONFIG_SUBDIRS([libstdc++-v3])
+AC_CONFIG_SUBDIRS([libvtv])
+AC_CONFIG_SUBDIRS([lto-plugin])
+AC_CONFIG_SUBDIRS([zlib])
-- 
2.34.1

Re: Enable top-level recursive 'autoreconf'

[Thomas Schwinge]

Hi!

On 2023-10-19T11:57:33+0200, Andreas Schwab  wrote:
> On Okt 19 2023, Thomas Schwinge wrote:
>> On 2023-10-18T15:42:18+0100, R jd <3246251196r...@gmail.com> wrote:
>>> I guess I can ask, why there is not a recursive approach for configuring
>>> GCC. e.g. AC_SUBDIRS in the top level?
>>
>> ('AC_CONFIG_SUBDIRS' you mean.)  You know, often it just takes someone to
>> ask the right questions...  ;-)
>>
>> What do people think about the attached
>> "Enable top-level recursive 'autoreconf'"?  Only lightly tested, so far.
>
> The top-level files are shared with binutils-gdb, which has a different
> set of subdirs.

Good point, thanks!  Fortunately, the failure mode for non-existing
directories is non-fatal (skipped with 'subdirectory [...] not present'
diagnostic); with my original "Enable top-level recursive 'autoreconf'"
(also re-attached) applied to Binutils/GDB Git master branch, we get:

$ PATH=[...] autoreconf -v
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal
autoreconf: configure.ac: tracing
autoreconf: configure.ac: subdirectory c++tools not present
autoreconf: configure.ac: subdirectory fixincludes not present
autoreconf: configure.ac: subdirectory gcc not present
autoreconf: configure.ac: subdirectory gcc/m2 not present
autoreconf: configure.ac: subdirectory gnattools not present
autoreconf: configure.ac: subdirectory gotools not present
autoreconf: configure.ac: adding subdirectory intl to autoreconf
autoreconf: Entering directory `intl'
[...]
autoreconf: Leaving directory `intl'
autoreconf: configure.ac: subdirectory libada not present
autoreconf: configure.ac: subdirectory libatomic not present
autoreconf: configure.ac: adding subdirectory libbacktrace to autoreconf
autoreconf: Entering directory `libbacktrace'
[...]

So we could (a) simply list *all* directories in the shared top-level
'configure.ac', or (b) configure GCC vs. other projrcts via a non-shared
file ('m4_include([config/AC_CONFIG_SUBDIRS.m4])' or similar -- is there
an established procedure for non-shared top-level files)?  (I don't have
a strong preference either way.)

It's just GCC and Binutils/GDB, or are the top-level files also shared
with additional projects?


Grüße
 Thomas


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
>From 43127e5643337ca407071ad93bccbc716024352e Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Thu, 19 Oct 2023 10:28:30 +0200
Subject: [PATCH] Enable top-level recursive 'autoreconf'

	* configure.ac: At end of file, instantiate 'AC_CONFIG_SUBDIRS'
	for all relevant directories.
	* configure: Regenerate.
---
 configure| 102 ++-
 configure.ac |  36 ++
 2 files changed, 136 insertions(+), 2 deletions(-)

diff --git a/configure b/configure
index 8fc163d36bd..fcb4d591334 100755
--- a/configure
+++ b/configure
@@ -584,7 +584,8 @@ PACKAGE_URL=
 
 ac_unique_file="move-if-change"
 enable_option_checking=no
-ac_subst_vars='LTLIBOBJS
+ac_subst_vars='subdirs
+LTLIBOBJS
 LIBOBJS
 compare_exclusions
 stage2_werror_flag
@@ -909,7 +910,37 @@ READELF_FOR_TARGET
 STRIP_FOR_TARGET
 WINDRES_FOR_TARGET
 WINDMC_FOR_TARGET'
-
+ac_subdirs_all='c++tools
+fixincludes
+gcc
+gcc/m2
+gnattools
+gotools
+intl
+libada
+libatomic
+libbacktrace
+libcc1
+libcody
+libcpp
+libdecnumber
+libffi
+libgcc
+libgfortran
+libgm2
+libgo
+libgomp
+libiberty
+libitm
+libobjc
+libphobos
+libquadmath
+libsanitizer
+libssp
+libstdc++-v3
+libvtv
+lto-plugin
+zlib'
 
 # Initialize some variables set by options.
 ac_init_help=
@@ -20081,3 +20112,70 @@ if test -n "$ac_unrecognized_opts" && test "$enable_option_checking" != no; then
 $as_echo "$as_me: WARNING: unrecognized options: $ac_unrecognized_opts" >&2;}
 fi
 
+
+# Enable top-level recursive 'autoreconf' by enumerating all relevant
+# directories here.  This is intentionally done at end of 'configure.ac',
+# *after* 'AC_OUTPUT', so that we don't attempt to prematurely 'configure'
+# these directories when the top-level 'configure' is invoked.
+subdirs="$subdirs c++tools"
+
+subdirs="$subdirs fixincludes"
+
+subdirs="$subdirs gcc"
+
+subdirs="$subdirs gcc/m2"
+
+subdirs="$subdirs gnattools"
+
+subdirs="$subdirs gotools"
+
+subdirs="$subdirs intl"
+
+subdirs="$subdir

Re: [PATCH 1/3] testsuite: Unbork multilib testing on RISC-V (and any target really)

[Thomas Schwinge]

Hi!

First, Vineet, great that you've now tracked this down!  :-) Indeed
"early exit" vs. 'torture-finish' was exactly the issue that I suspected.

It may not be what you originally intended, but I hope at least you've
learned some things about DejaGnu/TCL...  ;-P

Yesterday, I actually had begun looking into this.  To avoid the big
download and having to wait for a lot of packages to be build with your
'riscv-gnu-toolchain' recipe:
,
I intended to do just a quick GCC build on compile farm gcc92, which
(a) didn't turn out to be quick, and (b) eventually failed due to

"Bootstrap on RISC-V on Ubuntu 22.04 LTS: bits/libc-header-start.h: No such 
file or directory"...

(I'm now running 'riscv-gnu-toolchain' to verify this, and another thing.)

Before we push your patch, let me please verify that it indeed doesn't
change any 'gcc.misc-tests/i386-prefetch.exp' semantics, and:

On 2023-05-31T19:13:01+0100, Iain Sandoe via Gcc-patches 
 wrote:
>> On 31 May 2023, at 18:57, Jeff Law via Gcc-patches  
>> wrote:
>> On 5/31/23 10:25, Vineet Gupta wrote:
>>> Multilib testing on trunk is currently busted (and surprisingly this
>>> affects any/all targets but it seems nobody cares). We currently get the
>>> following splat:
>> I wouldn't say that nobody cares, it just hasn't bubbled up on anyone's 
>> priority list yet (most developers aren't working on targets that make heavy 
>> use of multilibs).

So I regularely do build x86_64 GNU/Linux with default '-m64' plus '-m32'
multilib -- but of course, there's no "early exit" for those, as there's
no 'string match "* -march=*" " [board_info target multilib_flags] "'...

>> But probably more importantly, this problem seems to not be triggering on 
>> all multilib targets.  For example, I just examined my tester's build logs 
>> and couldn't see this on the H8/300 or V850 ports.  Which begs the question, 
>> why?

..., which may be the case for those, too?  In other words: the problem
only shows up if '-march=[...]' appears in the flags, which indeed may
not be a common thing?  I'll cross-verify this with x86_64 and
'-march=[...]' flags.

And, I still intend to figure out why this issue apparently disappears
with my recent 'LTO_TORTURE_OPTIONS' patches reverted:
.


Otherwise:

> I do have a multilib problem [with libgomp] on Darwin (which has been noticed 
> : https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109951) but it is not obvious 
> how the fix proposed would solve this - unless it’s some subtle change in 
> global content for the multilib options.
>
> (testing anyway)

No, this is really a separate issue.  I understand what's happening, and
have an idea about how to address this that I'll post later.


Grüße
 Thomas
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955

Re: [PATCH 1/3] testsuite: Unbork multilib testing on RISC-V (and any target really)

[Thomas Schwinge]

Hi!

On 2023-06-01T09:24:20+0200, I wrote:
> First, Vineet, great that you've now tracked this down!  :-) Indeed
> "early exit" vs. 'torture-finish' was exactly the issue that I suspected.
>
> It may not be what you originally intended, but I hope at least you've
> learned some things about DejaGnu/TCL...  ;-P
>
> Yesterday, I actually had begun looking into this.  To avoid the big
> download and having to wait for a lot of packages to be build with your
> 'riscv-gnu-toolchain' recipe:
> ,
> I intended to do just a quick GCC build on compile farm gcc92, which
> (a) didn't turn out to be quick, and (b) eventually failed due to
> 
> "Bootstrap on RISC-V on Ubuntu 22.04 LTS: bits/libc-header-start.h: No such 
> file or directory"...
>
> (I'm now running 'riscv-gnu-toolchain' to verify this, and another thing.)

If running that with just 'RUNTESTFLAGS="i386-prefetch.exp"', I get:

[...]
Schedule of variations:
riscv-sim/-march=rv32imac/-mabi=ilp32/-mcmodel=medlow
riscv-sim/-march=rv32imafdc/-mabi=ilp32d/-mcmodel=medlow
riscv-sim/-march=rv64imac/-mabi=lp64/-mcmodel=medlow
riscv-sim/-march=rv64imafdc/-mabi=lp64d/-mcmodel=medlow

Running target riscv-sim/-march=rv32imac/-mabi=ilp32/-mcmodel=medlow
[...]
Running [...]/gcc.misc-tests/i386-prefetch.exp ...

=== gcc Summary for 
riscv-sim/-march=rv32imac/-mabi=ilp32/-mcmodel=medlow ===

Running target riscv-sim/-march=rv32imafdc/-mabi=ilp32d/-mcmodel=medlow
[...]
Running [...]/gcc.misc-tests/i386-prefetch.exp ...
ERROR: tcl error sourcing [...]/gcc.misc-tests/i386-prefetch.exp.
ERROR: tcl error code NONE
ERROR: torture-init: LTO_TORTURE_OPTIONS is not empty as expected
[...]

..., which indeed complains about 'LTO_TORTURE_OPTIONS' (which relates to
my recent changes in that area, which I now do understand, see below).

The issue is that indeed 'torture-init' now does set
'LTO_TORTURE_OPTIONS', whereas 'torture_without_loops',
'torture_with_loops' are set only when 'set-torture-options' is called.

> Before we push your patch, let me please verify that it indeed doesn't
> change any 'gcc.misc-tests/i386-prefetch.exp' semantics

Done.

> and:
>
> On 2023-05-31T19:13:01+0100, Iain Sandoe via Gcc-patches 
>  wrote:
>>> On 31 May 2023, at 18:57, Jeff Law via Gcc-patches 
>>>  wrote:
>>> On 5/31/23 10:25, Vineet Gupta wrote:
 Multilib testing on trunk is currently busted (and surprisingly this
 affects any/all targets but it seems nobody cares). We currently get the
 following splat:
>>> I wouldn't say that nobody cares, it just hasn't bubbled up on anyone's 
>>> priority list yet (most developers aren't working on targets that make 
>>> heavy use of multilibs).
>
> So I regularely do build x86_64 GNU/Linux with default '-m64' plus '-m32'
> multilib -- but of course, there's no "early exit" for those, as there's
> no 'string match "* -march=*" " [board_info target multilib_flags] "'...
>
>>> But probably more importantly, this problem seems to not be triggering on 
>>> all multilib targets.  For example, I just examined my tester's build logs 
>>> and couldn't see this on the H8/300 or V850 ports.  Which begs the 
>>> question, why?
>
> ..., which may be the case for those, too?  In other words: the problem
> only shows up if '-march=[...]' appears in the flags, which indeed may
> not be a common thing?  I'll cross-verify this with x86_64 and
> '-march=[...]' flags.

That is the crucial thing indeed.  Vineet, please note that in the Git
commit log.  That is, instead of "Multilib testing", say "Multilib
testing involving '-march=[...]' flags", or similar.

The ERRORs do reproduce with x86_64 GNU/Linux with:


RUNTESTFLAGS='--target_board=unix\{-m32,-m64,-march=generic,-march=generic\} 
i386-prefetch.exp'

..., for example.  Here, '-m32' behaves as expected, '-m64' behaves as
expected, the first '-march=generic' does the 'torture-init' and "early
exit", the second '-march=generic' then again does 'torture-init' and
runs into the error condition.

> And, I still intend to figure out why this issue apparently disappears
> with my recent 'LTO_TORTURE_OPTIONS' patches reverted:
> .

In the "old world", 'torture-init', *not* followed by
'set-torture-options', *not* followed by 'torture-finish', then another
'torture-init' was not a problem -- but in the "new world" it now is.

This also explains my confusion; the original report was:

ERROR: torture-init: torture_without_loops is not empty as expected

..., note: not 'LTO_TORTURE_OPTIONS' but 'torture_without_loops', and
those I'd not directly touched in my recent changes, which had made me
confused.

The 'torture_without_loops' error condition now does arise if there's a
'torture-init', *not* followed by 'set-torture-options

Re: [PATCH 2/3] RISC-V: Add missing torture-init and torture-finish for rvv.exp

[Thomas Schwinge]

Hi!

On 2023-05-31T09:25:33-0700, Vineet Gupta  wrote:
> From: Kito Cheng 
>
> This is in line with recent test harness expectations and is a
> preventive change as it doesn't actually fix any errors.
>
> gcc/testsuite/ChangeLog:
>
>   * gcc.target/riscv/rvv/rvv.exp: Add torture-init and
>   torture-finish.
>
> Signed-off-by: Vineet Gupta 
> ---
>  gcc/testsuite/gcc.target/riscv/rvv/rvv.exp | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/gcc/testsuite/gcc.target/riscv/rvv/rvv.exp 
> b/gcc/testsuite/gcc.target/riscv/rvv/rvv.exp
> index 5e69235a268c..7ab7456d1d15 100644
> --- a/gcc/testsuite/gcc.target/riscv/rvv/rvv.exp
> +++ b/gcc/testsuite/gcc.target/riscv/rvv/rvv.exp
> @@ -39,6 +39,7 @@ if [istarget riscv32-*-*] then {
>
>  # Initialize `dg'.
>  dg-init
> +torture-init
>
>  # Main loop.
>  set CFLAGS "$DEFAULT_CFLAGS -march=$gcc_march -mabi=$gcc_mabi -O3"
> @@ -90,5 +91,7 @@ foreach op $AUTOVEC_TEST_OPTS {
>  dg-runtest [lsort [glob -nocomplain 
> $srcdir/$subdir/autovec/vls-vlmax/*.\[cS\]]] \
>   "-std=c99 -O3 -ftree-vectorize --param 
> riscv-autovec-preference=fixed-vlmax" $CFLAGS
>
> +torture-finish
> +
>  # All done.
>  dg-finish

I suggest to drop this patch: 'gcc.target/riscv/rvv/rvv.exp' isn't doing
anything with torture testing flags etc., but (in addition to
'dg-runtest') just calls 'gcc-dg-runtest', which internally does
'torture-init', 'torture-finish' -- like in a number of other '*.exp'
files.  As you say, this patch "doesn't actually fix any errors".


Grüße
 Thomas
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955

Consider '--with-build-sysroot=[...]' for target libraries' build-tree testing (instead of build-time 'CC' etc.) [PR109951]

[Thomas Schwinge]

 lappend ALWAYS_CFLAGS 
> "additional_flags=--sysroot=$SYSROOT_CFLAGS_FOR_TARGET"
> + }

Need 'global SYSROOT_CFLAGS_FOR_TARGET'.

Need to change:

-   lappend ALWAYS_CFLAGS 
"additional_flags=--sysroot=$SYSROOT_CFLAGS_FOR_TARGET"
+   lappend ALWAYS_CFLAGS "additional_flags=$SYSROOT_CFLAGS_FOR_TARGET"

..., as 'SYSROOT_CFLAGS_FOR_TARGET' already includes '--sysroot=' prefix.

> --- libgomp/testsuite/libgomp-test-support.exp.in (revision 279954)
> +++ libgomp/testsuite/libgomp-test-support.exp.in (working copy)
> @@ -1,5 +1,3 @@
> -set GCC_UNDER_TEST {@CC@}

Also need to capture 'SYSROOT_CFLAGS_FOR_TARGET' here, so that it's then
available at test time.

> --- Makefile.tpl  (revision 279954)
> +++ Makefile.tpl  (working copy)
> @@ -322,6 +322,7 @@ RAW_CXX_TARGET_EXPORTS = \
>
>  NORMAL_TARGET_EXPORTS = \
>   $(BASE_TARGET_EXPORTS) \
> + SYSROOT_CFLAGS_FOR_TARGET="$(SYSROOT_CFLAGS_FOR_TARGET)"; export 
> SYSROOT_CFLAGS_FOR_TARGET; \
>   CXX="$(CXX_FOR_TARGET) $(XGCC_FLAGS_FOR_TARGET) $$TFLAGS"; export CXX;

With that one moved into the generic 'BASE_TARGET_EXPORTS', adapting
things to the current state of affaris plus some polishing, the attached
"Consider '--with-build-sysroot=[...]' for target libraries' build-tree testing 
(instead of build-time 'CC' etc.) [PR109951]"
appears to be doing the right thing per my (limited, so far) testing.

Will you, Maciej, please test that this doesn't break your setting?

Will you, Iain, please test that this does address
<https://gcc.gnu.org/PR109951>
"libgomp, testsuite: non-native multilib c++ tests fail on Darwin"?

Anybody got any other comments?

Once that's all clear, we may either push this one already, and then I
work on applying the same changes to other target libraries
incrementally, or do all that at once.  I suppose: "push this one
already", to restore Iain's testing as well as giving these changes some
wider exposure, and in parallel "I work on applying the same changes to
other target libraries incrementally"?


Grüße
 Thomas


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
>From ab5d1d3ef91b2ad7e1ed262c9487f727b79ceb3f Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Thu, 1 Jun 2023 23:07:37 +0200
Subject: [PATCH] Consider '--with-build-sysroot=[...]' for target libraries'
 build-tree testing (instead of build-time 'CC' etc.) [PR109951]

	PR testsuite/109951
	* Makefile.tpl (BASE_TARGET_EXPORTS): Add
	'SYSROOT_CFLAGS_FOR_TARGET'.
	* Makefile.in: Regenerate.
	libgomp/
	* configure.ac: Revert earlier changes, instead
	'AC_SUBST(SYSROOT_CFLAGS_FOR_TARGET)'.
	* Makefile.in: Regenerate.
	* configure: Likewise.
	* testsuite/Makefile.in: Likewise.
	* testsuite/lib/libgomp.exp (libgomp_init): Remove
	"Fix up '-funconfigured-libstdc++-v3' in 'GXX_UNDER_TEST'" code.
	If '--with-build-sysroot=[...]' was specified, use it for
	build-tree testing.
	* testsuite/libgomp-site-extra.exp.in (GCC_UNDER_TEST)
	(GXX_UNDER_TEST, GFORTRAN_UNDER_TEST): Don't set.
	(SYSROOT_CFLAGS_FOR_TARGET): Set.
	* testsuite/libgomp.c++/c++.exp (lang_source_re)
	(lang_include_flags): Set for build-tree testing.
	* testsuite/libgomp.oacc-c++/c++.exp (lang_source_re)
	(lang_include_flags): Likewise.

Co-authored-by: Chung-Lin Tang 
---
 Makefile.in |  1 +
 Makefile.tpl|  1 +
 libgomp/Makefile.in |  2 +-
 libgomp/configure   | 17 -
 libgomp/configure.ac| 15 +++
 libgomp/testsuite/Makefile.in   |  2 +-
 libgomp/testsuite/lib/libgomp.exp   | 18 +-
 libgomp/testsuite/libgomp-site-extra.exp.in |  4 +---
 libgomp/testsuite/libgomp.c++/c++.exp   |  6 ++
 libgomp/testsuite/libgomp.oacc-c++/c++.exp  |  6 ++
 10 files changed, 29 insertions(+), 43 deletions(-)

diff --git a/Makefile.in b/Makefile.in
index b559454cc90..e75bd98bde5 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -320,6 +320,7 @@ BASE_TARGET_EXPORTS = \
 	RANLIB="$(RANLIB_FOR_TARGET)"; export RANLIB; \
 	READELF="$(READELF_FOR_TARGET)"; export READELF; \
 	STRIP="$(STRIP_FOR_TARGET)"; export STRIP; \
+	SYSROOT_CFLAGS_FOR_TARGET="$(SYSROOT_CFLAGS_FOR_TARGET)"; export SYSROOT_CFLAGS_FOR_TARGET; \
 	WINDRES="$(WINDRES_FOR_TARGET)"; export WINDRES; \
 	WINDMC="$(WINDMC_FOR_TARGET)"; export WI

Add 'libgomp.{,oacc-}fortran/fortran-torture_execute_math.f90'

[Thomas Schwinge]

Hi!

OK to push the attached
"Add 'libgomp.{,oacc-}fortran/fortran-torture_execute_math.f90'"?


Grüße
 Thomas


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
>From 0d5095d8cd2d68113890a39a7fdb649198e576c1 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Fri, 2 Jun 2023 23:11:00 +0200
Subject: [PATCH] Add
 'libgomp.{,oacc-}fortran/fortran-torture_execute_math.f90'

	gcc/testsuite/
	* gfortran.fortran-torture/execute/math.f90: Enhance for optional
	OpenACC, OpenMP 'target' usage.
	libgomp/
	* testsuite/libgomp.fortran/fortran-torture_execute_math.f90: New.
	* testsuite/libgomp.oacc-fortran/fortran-torture_execute_math.f90:
	Likewise.
---
 .../gfortran.fortran-torture/execute/math.f90 | 23 +--
 .../fortran-torture_execute_math.f90  |  4 
 .../fortran-torture_execute_math.f90  |  5 
 3 files changed, 30 insertions(+), 2 deletions(-)
 create mode 100644 libgomp/testsuite/libgomp.fortran/fortran-torture_execute_math.f90
 create mode 100644 libgomp/testsuite/libgomp.oacc-fortran/fortran-torture_execute_math.f90

diff --git a/gcc/testsuite/gfortran.fortran-torture/execute/math.f90 b/gcc/testsuite/gfortran.fortran-torture/execute/math.f90
index 17cc78f7a10..e71f669304f 100644
--- a/gcc/testsuite/gfortran.fortran-torture/execute/math.f90
+++ b/gcc/testsuite/gfortran.fortran-torture/execute/math.f90
@@ -1,9 +1,14 @@
 ! Program to test mathematical intrinsics
+
+! See also 'libgomp/testsuite/libgomp.fortran/fortran-torture_execute_math.f90'; thus the '!$omp' directives.
+! See also 'libgomp/testsuite/libgomp.oacc-fortran/fortran-torture_execute_math.f90'; thus the '!$acc' directives.
+
 subroutine dotest (n, val4, val8, known)
implicit none
real(kind=4) val4, known
real(kind=8) val8
integer n
+   !$acc routine seq
 
if (abs (val4 - known) .gt. 0.001) STOP 1
if (abs (real (val8, kind=4) - known) .gt. 0.001) STOP 2
@@ -14,17 +19,20 @@ subroutine dotestc (n, val4, val8, known)
complex(kind=4) val4, known
complex(kind=8) val8
integer n
+   !$acc routine seq
+
if (abs (val4 - known) .gt. 0.001) STOP 3
if (abs (cmplx (val8, kind=4) - known) .gt. 0.001) STOP 4
 end subroutine
 
-program testmath
+subroutine testmath
implicit none
real(kind=4) r, two4, half4
real(kind=8) q, two8, half8
complex(kind=4) cr
complex(kind=8) cq
external dotest, dotestc
+   !$acc routine seq
 
two4 = 2.0
two8 = 2.0_8
@@ -96,5 +104,16 @@ program testmath
cq = log ((-1.0_8, -1.0_8))
call dotestc (21, cr, cq, (0.3466, -2.3562))
 
-end program
+end subroutine
 
+program main
+   implicit none
+   external testmath
+
+   !$acc serial
+   !$omp target
+   call testmath
+   !$acc end serial
+   !$omp end target
+
+end program
diff --git a/libgomp/testsuite/libgomp.fortran/fortran-torture_execute_math.f90 b/libgomp/testsuite/libgomp.fortran/fortran-torture_execute_math.f90
new file mode 100644
index 000..3348a0bb3ad
--- /dev/null
+++ b/libgomp/testsuite/libgomp.fortran/fortran-torture_execute_math.f90
@@ -0,0 +1,4 @@
+! { dg-do run }
+! { dg-additional-options -foffload-options=-lm }
+
+include '../../../gcc/testsuite/gfortran.fortran-torture/execute/math.f90'
diff --git a/libgomp/testsuite/libgomp.oacc-fortran/fortran-torture_execute_math.f90 b/libgomp/testsuite/libgomp.oacc-fortran/fortran-torture_execute_math.f90
new file mode 100644
index 000..1b2ac440762
--- /dev/null
+++ b/libgomp/testsuite/libgomp.oacc-fortran/fortran-torture_execute_math.f90
@@ -0,0 +1,5 @@
+! { dg-do run }
+!TODO { dg-prune-output {using 'vector_length \(32\)', ignoring 1} }
+! { dg-additional-options -foffload-options=-lm }
+
+include '../../../gcc/testsuite/gfortran.fortran-torture/execute/math.f90'
-- 
2.34.1

driver: Forward '-lgfortran', '-lm' to offloading compilation

[Thomas Schwinge]

Hi!

OK to push the attached
"driver: Forward '-lgfortran', '-lm' to offloading compilation"?
(We didn't have a PR open for that, or did we?)


Grüße
 Thomas


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
>From 5d3cb866cad3bbcf47c5e66825e5710e86cc017e Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Mon, 5 Jun 2023 11:26:37 +0200
Subject: [PATCH] driver: Forward '-lgfortran', '-lm' to offloading compilation

..., so that users don't manually need to specify
'-foffload-options=-lgfortran', '-foffload-options=-lm' in addition to
'-lgfortran', '-lm' (specified manually, or implicitly by the driver).

	gcc/
	* gcc.cc (driver_handle_option): Forward host '-lgfortran', '-lm'
	to offloading compilation.
	* config/gcn/mkoffload.cc (main): Adjust.
	* config/nvptx/mkoffload.cc (main): Likewise.
	* doc/invoke.texi (foffload-options): Update example.
	libgomp/
	* testsuite/libgomp.fortran/fortran.exp (lang_link_flags): Don't
	set.
	* testsuite/libgomp.oacc-fortran/fortran.exp (lang_link_flags):
	Likewise.
	* testsuite/libgomp.c/simd-math-1.c: Remove
	'-foffload-options=-lm'.
	* testsuite/libgomp.fortran/fortran-torture_execute_math.f90:
	Likewise.
	* testsuite/libgomp.oacc-fortran/fortran-torture_execute_math.f90:
	Likewise.
---
 gcc/config/gcn/mkoffload.cc   | 12 
 gcc/config/nvptx/mkoffload.cc | 12 
 gcc/doc/invoke.texi   |  5 +-
 gcc/gcc.cc| 56 +++
 libgomp/testsuite/libgomp.c/simd-math-1.c |  1 -
 .../fortran-torture_execute_math.f90  |  1 -
 libgomp/testsuite/libgomp.fortran/fortran.exp |  2 -
 .../fortran-torture_execute_math.f90  |  1 -
 .../libgomp.oacc-fortran/fortran.exp  |  2 -
 9 files changed, 82 insertions(+), 10 deletions(-)

diff --git a/gcc/config/gcn/mkoffload.cc b/gcc/config/gcn/mkoffload.cc
index 988c12318fd..8b608bf024e 100644
--- a/gcc/config/gcn/mkoffload.cc
+++ b/gcc/config/gcn/mkoffload.cc
@@ -946,6 +946,18 @@ main (int argc, char **argv)
   else if (startswith (argv[i], STR))
 	gcn_stack_size = atoi (argv[i] + strlen (STR));
 #undef STR
+  /* Translate host into offloading libraries.  */
+  else if (strcmp (argv[i], "-l_GCC_gfortran") == 0
+	   || strcmp (argv[i], "-l_GCC_m") == 0)
+	{
+	  /* Elide '_GCC_'.  */
+	  size_t i_dst = strlen ("-l");
+	  size_t i_src = strlen ("-l_GCC_");
+	  char c;
+	  do
+	c = argv[i][i_dst++] = argv[i][i_src++];
+	  while (c != '\0');
+	}
 }
 
   if (!(fopenacc ^ fopenmp))
diff --git a/gcc/config/nvptx/mkoffload.cc b/gcc/config/nvptx/mkoffload.cc
index 6cdea45cffe..aaea9fb320d 100644
--- a/gcc/config/nvptx/mkoffload.cc
+++ b/gcc/config/nvptx/mkoffload.cc
@@ -649,6 +649,18 @@ main (int argc, char **argv)
   else if (strcmp (argv[i], "-dumpbase") == 0
 	   && i + 1 < argc)
 	dumppfx = argv[++i];
+  /* Translate host into offloading libraries.  */
+  else if (strcmp (argv[i], "-l_GCC_gfortran") == 0
+	   || strcmp (argv[i], "-l_GCC_m") == 0)
+	{
+	  /* Elide '_GCC_'.  */
+	  size_t i_dst = strlen ("-l");
+	  size_t i_src = strlen ("-l_GCC_");
+	  char c;
+	  do
+	c = argv[i][i_dst++] = argv[i][i_src++];
+	  while (c != '\0');
+	}
 }
   if (!(fopenacc ^ fopenmp))
 fatal_error (input_location, "either %<-fopenacc%> or %<-fopenmp%> "
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index d2d639c92d4..7b3a2a74459 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -2716,9 +2716,8 @@ the @option{-foffload-options=@var{target-list}=@var{options}} form.  The
 Typical command lines are
 
 @smallexample
--foffload-options=-lgfortran -foffload-options=-lm
--foffload-options="-lgfortran -lm" -foffload-options=nvptx-none=-latomic
--foffload-options=amdgcn-amdhsa=-march=gfx906 -foffload-options=-lm
+-foffload-options='-fno-math-errno -ffinite-math-only' -foffload-options=nvptx-none=-latomic
+-foffload-options=amdgcn-amdhsa=-march=gfx906 -foffload-options=-O3
 @end smallexample
 
 @opindex fopenacc
diff --git a/gcc/gcc.cc b/gcc/gcc.cc
index 2ccca00d603..15995206856 100644
--- a/gcc/gcc.cc
+++ b/gcc/gcc.cc
@@ -47,6 +47,9 @@ compilation is specified by a string called a "spec".  */
 #include "opts-jobserver.h"
 #include "common/common-target.h"
 
+#ifndef MATH_LIBRARY
+#define MATH_LIBRARY "m"
+#endif
 
 
 /* Manage the manipulation of env vars.
@@ -4117,6 +4120,48 @@ next_item:
 }
 }
 

Support 'UNSUPPORTED: [...]: exception handling disabled' for libstdc++ testing (was: Support in the GCC(/C++) test suites for '-fno-exceptions')

[Thomas Schwinge]

Hi!

On 2023-06-06T20:31:21+0100, Jonathan Wakely  wrote:
> On Tue, 6 Jun 2023 at 20:14, Thomas Schwinge 
> wrote:
>> This issue comes up in context of me working on C++ support for GCN and
>> nvptx target.  Those targets shall default to '-fno-exceptions' -- or,
>> "in other words", '-fexceptions' is not supported.  (Details omitted
>> here.)
>>
>> It did seem clear to me that with such a configuration it'll be hard to
>> get clean test results.  Then I found code in
>> 'gcc/testsuite/lib/gcc-dg.exp:gcc-dg-prune':
>>
>> # If exceptions are disabled, mark tests expecting exceptions to be
>> enabled
>> # as unsupported.
>> if { ![check_effective_target_exceptions_enabled] } {
>> if [regexp "(^|\n)\[^\n\]*: error: exception handling disabled"
>> $text] {
>> return "::unsupported::exception handling disabled"
>> }
>>
>> ..., which, in a way, sounds as if the test suite generally is meant to
>> produce useful results for '-fno-exceptions', nice surprise!
>>
>> Running x86_64-pc-linux-gnu (not yet GCN, nvptx) 'make check' with:
>>
>> RUNTESTFLAGS='--target_board=unix/-fno-exceptions\{,-m32\}'
>>
>> ..., I find that indeed this does work for a lot of test cases, where we
>> then get (random example):
>>
>>  PASS: g++.dg/coroutines/pr99710.C  (test for errors, line 23)
>> -PASS: g++.dg/coroutines/pr99710.C (test for excess errors)
>> +UNSUPPORTED: g++.dg/coroutines/pr99710.C: exception handling disabled
>>
>> ..., due to:
>>
>>  [...]/g++.dg/coroutines/pr99710.C: In function 'task my_coro()':
>> +[...]/g++.dg/coroutines/pr99710.C:18:10: error: exception handling
>> disabled, use '-fexceptions' to enable
>>  [...]/g++.dg/coroutines/pr99710.C:23:7: error: await expressions are
>> not permitted in handlers
>>  compiler exited with status 1
>>
>> But, we're nowhere near clean test results: PASS -> FAIL as well as
>> XFAIL -> XPASS regressions, due to 'error: exception handling disabled'
>> precluding other diagnostics seems to be one major issue.
>>
>> Is there interest in me producing the obvious (?) changes to those test
>> cases, such that compiler g++ as well as target library libstdc++ test
>> results are reasonably clean?  (If you think that's all "wasted effort",
>> then I suppose I'll just locally ignore any FAILs/XPASSes/UNRESOLVEDs
>> that appear in combination with
>> 'UNSUPPORTED: [...]: exception handling disabled'.)
>
> I would welcome that for libstdc++.

Assuming no issues found in testing, OK to push the attached
"Support 'UNSUPPORTED: [...]: exception handling disabled' for libstdc++ 
testing"?
(Thanks, Jozef!)

> I do sometimes run the libstdc++ tests
> with "unusual" options, like -fno-exceptions and -fno-rtti (e.g. today I've
> been fixing FAILs that only happen with -fexcess-precision=standard). I
> just manually ignore the tests that fail for -fno-exceptions, but it would
> be great if they were automatically skipped as UNSUPPORTED.
>
> We already have a handful of tests that use #if __cpp_exceptions to make
> those parts conditional on exception support. We also have exactly one test
> that is currently UNSUPPORTED when -fno-exceptions is used:
> testsuite/18_support/nested_exception/rethrow_if_nested-term.cc:// {
> dg-skip-if "" { *-*-* } { "-fno-exceptions" } }

ACK -- that'll only work for explicit '-fno-exceptions', but not for
implicit (say, via 'CC1PLUS_SPEC'), right?  So, indeed:

> That could be changed to use an effective target keyword instead.

I'll look into that later.

> To add an effective-target to the libstdc++ testsuite would be as simple as:
>
> --- a/libstdc++-v3/testsuite/lib/libstdc++.exp
> +++ b/libstdc++-v3/testsuite/lib/libstdc++.exp
> @@ -1421,6 +1421,14 @@ proc check_effective_target_tzdb { } {
> }]
> }
>
> +# Return 1 if exception handling is enabled.
> +proc check_effective_target_exceptions_enabled { } {
> +return [check_v3_target_prop_cached et_eh {
> +   set cond "defined __cpp_exceptions"
> +   return [v3_check_preprocessor_condition eh $cond]
> +}]
> +}
> +

Well, we don't even need to do that, because:

> However, you probably want to add it to the main testsuite instead, which
> would be a little more involved (the v3_check_preprocessor_condition proc
> is specific to libstdc++).

..., this 

Re: Support 'UNSUPPORTED: [...]: exception handling disabled' for libstdc++ testing (was: Support in the GCC(/C++) test suites for '-fno-exceptions')

[Thomas Schwinge]

Hi!

On 2023-06-07T09:12:31+0100, Jonathan Wakely  wrote:
> On Wed, 7 Jun 2023 at 08:13, Thomas Schwinge wrote:
>> On 2023-06-06T20:31:21+0100, Jonathan Wakely  wrote:
>> > On Tue, 6 Jun 2023 at 20:14, Thomas Schwinge 
>> > wrote:
>> >> This issue comes up in context of me working on C++ support for GCN and
>> >> nvptx target.  Those targets shall default to '-fno-exceptions' -- or,
>> >> "in other words", '-fexceptions' is not supported.  (Details omitted
>> >> here.)
>> >>
>> >> It did seem clear to me that with such a configuration it'll be hard to
>> >> get clean test results.  Then I found code in
>> >> 'gcc/testsuite/lib/gcc-dg.exp:gcc-dg-prune':
>> >>
>> >> # If exceptions are disabled, mark tests expecting exceptions to be
>> >> enabled
>> >> # as unsupported.
>> >> if { ![check_effective_target_exceptions_enabled] } {
>> >> if [regexp "(^|\n)\[^\n\]*: error: exception handling disabled"
>> >> $text] {
>> >> return "::unsupported::exception handling disabled"
>> >> }
>> >>
>> >> ..., which, in a way, sounds as if the test suite generally is meant to
>> >> produce useful results for '-fno-exceptions', nice surprise!
>> >>
>> >> Running x86_64-pc-linux-gnu (not yet GCN, nvptx) 'make check' with:
>> >>
>> >> RUNTESTFLAGS='--target_board=unix/-fno-exceptions\{,-m32\}'
>> >>
>> >> ..., I find that indeed this does work for a lot of test cases, where we
>> >> then get (random example):
>> >>
>> >>  PASS: g++.dg/coroutines/pr99710.C  (test for errors, line 23)
>> >> -PASS: g++.dg/coroutines/pr99710.C (test for excess errors)
>> >> +UNSUPPORTED: g++.dg/coroutines/pr99710.C: exception handling
>> disabled
>> >>
>> >> ..., due to:
>> >>
>> >>  [...]/g++.dg/coroutines/pr99710.C: In function 'task my_coro()':
>> >> +[...]/g++.dg/coroutines/pr99710.C:18:10: error: exception handling
>> >> disabled, use '-fexceptions' to enable
>> >>  [...]/g++.dg/coroutines/pr99710.C:23:7: error: await expressions
>> are
>> >> not permitted in handlers
>> >>  compiler exited with status 1
>> >>
>> >> But, we're nowhere near clean test results: PASS -> FAIL as well as
>> >> XFAIL -> XPASS regressions, due to 'error: exception handling disabled'
>> >> precluding other diagnostics seems to be one major issue.
>> >>
>> >> Is there interest in me producing the obvious (?) changes to those test
>> >> cases, such that compiler g++ as well as target library libstdc++ test
>> >> results are reasonably clean?  (If you think that's all "wasted effort",
>> >> then I suppose I'll just locally ignore any FAILs/XPASSes/UNRESOLVEDs
>> >> that appear in combination with
>> >> 'UNSUPPORTED: [...]: exception handling disabled'.)
>> >
>> > I would welcome that for libstdc++.
>>
>> Assuming no issues found in testing, OK to push the attached
>> "Support 'UNSUPPORTED: [...]: exception handling disabled' for libstdc++
>> testing"?
>> (Thanks, Jozef!)
>
> Yes please.

Pushed commit r14-1604-g5faaabef3819434d13fcbf749bd07bfc98ca7c3c
"Support 'UNSUPPORTED: [...]: exception handling disabled' for libstdc++ 
testing"
to master branch, as posted.

For one-week-old GCC commit 2720bbd597f56742a17119dfe80edc2ba86af255,
x86_64-pc-linux-gnu, I see no changes without '-fno-exceptions' (as
expected), and otherwise:

=== libstdc++ Summary for [-unix-]{+unix/-fno-exceptions+} 
===

# of expected passes[-15044-]{+12877+}
# of unexpected failures[-5-]{+10+}
# of expected failures  [-106-]{+77+}
{+# of unresolved testcases 6+}
# of unsupported tests  [-747-]{+1846+}

As expected, there's a good number of (random example):

-PASS: 18_support/105387.cc (test for excess errors)
-PASS: 18_support/105387.cc execution test
+UNSUPPORTED: 18_support/105387.cc: exception handling disabled

..., plus the following:

[-PASS:-]{+FAIL:+} 23_containers/vector/capacity/constexpr.cc (test for 
excess errors)


[...]/libstdc++-v3/testsuite/23_containers/vector/capacity/constexpr.cc:101: 
error: non-

Remove 'gcc/testsuite/g++.dg/warn/Wfree-nonheap-object.s' (was: [PATCH] add -Wmismatched-new-delete to middle end (PR 90629))

[Thomas Schwinge]

Hi!

On 2020-11-03T16:56:48-0700, Martin Sebor via Gcc-patches 
 wrote:
> Attached is a simple middle end implementation of detection of
> mismatched pairs of calls to C++ new and delete, along with
> a substantially enhanced implementation of -Wfree-nonheap-object.

This eventually became commit dce6c58db87ebf7f4477bd3126228e73e497
"Add support for detecting mismatched allocation/deallocation calls".
Already in this original patch submission:

> diff --git a/gcc/testsuite/g++.dg/warn/Wfree-nonheap-object.s 
> b/gcc/testsuite/g++.dg/warn/Wfree-nonheap-object.s
> new file mode 100644
> index 000..e69de29bb2d

OK to push the attached
"Remove 'gcc/testsuite/g++.dg/warn/Wfree-nonheap-object.s'"?


Grüße
 Thomas


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
>From d04c97b40a07bd2a3205d9de8577024f5d26aba0 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Wed, 7 Jun 2023 16:01:39 +0200
Subject: [PATCH] Remove 'gcc/testsuite/g++.dg/warn/Wfree-nonheap-object.s'

..., which, presumably, was added by mistake in
commit dce6c58db87ebf7f4477bd3126228e73e497
"Add support for detecting mismatched allocation/deallocation calls".

	gcc/testsuite/
	* g++.dg/warn/Wfree-nonheap-object.s: Remove.
---
 gcc/testsuite/g++.dg/warn/Wfree-nonheap-object.s | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 delete mode 100644 gcc/testsuite/g++.dg/warn/Wfree-nonheap-object.s

diff --git a/gcc/testsuite/g++.dg/warn/Wfree-nonheap-object.s b/gcc/testsuite/g++.dg/warn/Wfree-nonheap-object.s
deleted file mode 100644
index e69de29bb2d..000
-- 
2.34.1

Tighten 'dg-warning' alternatives in 'c-c++-common/Wfree-nonheap-object{,-2,-3}.c' (was: [PATCH] correct -Wmismatched-new-delete (PR 98160, 98166))

[Thomas Schwinge]

;malloc \\(dealloc_float\\)' 
> attribute ignored with deallocation functions declared 'inline'" }
> +
> +void test_nowarn_float (int n)
> +{
> +  {
> +float *p = alloc_float (n);
> +dealloc_float (p);
> +  }
> +
> +  {
> +float *p = alloc_float (n);
> +dealloc_float (p + 2);
> +  }
> +}
> diff --git a/gcc/testsuite/c-c++-common/Wfree-nonheap-object.c 
> b/gcc/testsuite/c-c++-common/Wfree-nonheap-object.c
> new file mode 100644
> index 000..dfbb296e9a7
> --- /dev/null
> +++ b/gcc/testsuite/c-c++-common/Wfree-nonheap-object.c
> @@ -0,0 +1,50 @@
> +/* Verify that built-in forms of functions can be used interchangeably
> +   with their ordinary (library) forms in attribute malloc.
> +   { dg-do compile }
> +   { dg-options "-Wall" } */
> +
> +char* f (void) __attribute__ ((malloc (__builtin_free)));
> +
> +#if __cplusplus
> +extern "C" {
> +#endif
> +
> +void free (void*);
> +
> +#if __cplusplus
> +}
> +#endif
> +
> +char* g (void) __attribute__ ((malloc (free)));
> +
> +
> +void test_nowarm (void)
> +{
> +  char *p = f ();
> +  free (p);
> +
> +  p = g ();
> +  free (p);
> +
> +  p = f ();
> +  __builtin_free (p);
> +
> +  p = g ();
> +  __builtin_free (p);
> +}
> +
> +
> +void test_warn (void)
> +{
> +  char *p = f ();
> +  free (p + 1);   // { dg-warning "'free|void free\\(void\\*\\)' 
> called on pointer 'p|' with nonzero offset" }
> +
> +  p = g ();
> +  free (p + 2);   // { dg-warning "'free|void free\\(void\\*\\)' 
> called on pointer 'p|' with nonzero offset" }
> +
> +  p = f ();
> +  __builtin_free (p + 3); // { dg-warning "'__builtin_free|void 
> __builtin_free\\(void\\*\\)' called on pointer 'p|' with nonzero 
> offset" }
> +
> +  p = g ();
> +  __builtin_free (p + 4); // { dg-warning "'__builtin_free|void 
> __builtin_free\\(void\\*\\)' called on pointer 'p|' with nonzero 
> offset" }
> +}


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
>From d9039d3d5b410075e2afa3a5a635f7399f072edd Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Wed, 7 Jun 2023 16:24:26 +0200
Subject: [PATCH] Tighten 'dg-warning' alternatives in
 'c-c++-common/Wfree-nonheap-object{,-2,-3}.c'

..., added in commit fe7f75cf16783589eedbab597e6d0b8d35d7e470
"Correct/improve maybe_emit_free_warning (PR middle-end/98166, PR c++/57111, PR middle-end/98160)".

These use alternatives like, for example, "AB|CDE|FG", but what really must've
been meant is "A(B|C)D(E|F)G".  The former variant also does "work": it matches
any of "AB", or "CDE", or "FG", which are components of the latter variant.
(That means, the former variant matches too loosely.)

	gcc/testsuite/
	* c-c++-common/Wfree-nonheap-object-2.c: Tighten 'dg-warning'
	alternatives.
	* c-c++-common/Wfree-nonheap-object-3.c: Likewise.
	* c-c++-common/Wfree-nonheap-object.c: Likewise.
---
 gcc/testsuite/c-c++-common/Wfree-nonheap-object-2.c | 2 +-
 gcc/testsuite/c-c++-common/Wfree-nonheap-object-3.c | 6 +++---
 gcc/testsuite/c-c++-common/Wfree-nonheap-object.c   | 8 
 3 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/gcc/testsuite/c-c++-common/Wfree-nonheap-object-2.c b/gcc/testsuite/c-c++-common/Wfree-nonheap-object-2.c
index 0aedf1babbc..a2dbd181e33 100644
--- a/gcc/testsuite/c-c++-common/Wfree-nonheap-object-2.c
+++ b/gcc/testsuite/c-c++-common/Wfree-nonheap-object-2.c
@@ -32,7 +32,7 @@ void test_nowarn_int (int n)
 inline void
 dealloc_long (long *p)
 {
-  __builtin_free (p); // { dg-warning "'__builtin_free|void __builtin_free\\(void\\*\\)' called on pointer 'p|' with nonzero offset" }
+  __builtin_free (p); // { dg-warning "'(__builtin_free|void __builtin_free\\(void\\*\\))' called on pointer '(p|)' with nonzero offset" }
 }
 
 __attribute__ ((malloc (dealloc_long)))
diff --git a/gcc/testsuite/c-c++-common/Wfree-nonheap-object-3.c b/gcc/testsuite/c-c++-common/Wfree-nonheap-object-3.c
index 41a5b50362e..8f20de8455f 100644
--- a/gcc/testsuite/c-c++-common/Wfree-nonheap-object-3.c
+++ b/gcc/testsuite/c-c++-common/Wfree-nonheap-object-3.c
@@ -22,7 +22,7 @@ void test_nowarn_int (int n)
 
   {
 int *p = alloc_int (n);
-__builtin_free (p + 1);   // { dg-warning "'__builtin_free|void __builtin_free\\(void\\*\\)&#

[ping] Add 'libgomp.{, oacc-}fortran/fortran-torture_execute_math.f90'

[Thomas Schwinge]

Hi!

On 2023-06-05T14:18:48+0200, I wrote:
> OK to push the attached
> "Add 'libgomp.{,oacc-}fortran/fortran-torture_execute_math.f90'"?

Ping.


Grüße
 Thomas


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
>From 0d5095d8cd2d68113890a39a7fdb649198e576c1 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Fri, 2 Jun 2023 23:11:00 +0200
Subject: [PATCH] Add
 'libgomp.{,oacc-}fortran/fortran-torture_execute_math.f90'

	gcc/testsuite/
	* gfortran.fortran-torture/execute/math.f90: Enhance for optional
	OpenACC, OpenMP 'target' usage.
	libgomp/
	* testsuite/libgomp.fortran/fortran-torture_execute_math.f90: New.
	* testsuite/libgomp.oacc-fortran/fortran-torture_execute_math.f90:
	Likewise.
---
 .../gfortran.fortran-torture/execute/math.f90 | 23 +--
 .../fortran-torture_execute_math.f90  |  4 
 .../fortran-torture_execute_math.f90  |  5 
 3 files changed, 30 insertions(+), 2 deletions(-)
 create mode 100644 libgomp/testsuite/libgomp.fortran/fortran-torture_execute_math.f90
 create mode 100644 libgomp/testsuite/libgomp.oacc-fortran/fortran-torture_execute_math.f90

diff --git a/gcc/testsuite/gfortran.fortran-torture/execute/math.f90 b/gcc/testsuite/gfortran.fortran-torture/execute/math.f90
index 17cc78f7a10..e71f669304f 100644
--- a/gcc/testsuite/gfortran.fortran-torture/execute/math.f90
+++ b/gcc/testsuite/gfortran.fortran-torture/execute/math.f90
@@ -1,9 +1,14 @@
 ! Program to test mathematical intrinsics
+
+! See also 'libgomp/testsuite/libgomp.fortran/fortran-torture_execute_math.f90'; thus the '!$omp' directives.
+! See also 'libgomp/testsuite/libgomp.oacc-fortran/fortran-torture_execute_math.f90'; thus the '!$acc' directives.
+
 subroutine dotest (n, val4, val8, known)
implicit none
real(kind=4) val4, known
real(kind=8) val8
integer n
+   !$acc routine seq
 
if (abs (val4 - known) .gt. 0.001) STOP 1
if (abs (real (val8, kind=4) - known) .gt. 0.001) STOP 2
@@ -14,17 +19,20 @@ subroutine dotestc (n, val4, val8, known)
complex(kind=4) val4, known
complex(kind=8) val8
integer n
+   !$acc routine seq
+
if (abs (val4 - known) .gt. 0.001) STOP 3
if (abs (cmplx (val8, kind=4) - known) .gt. 0.001) STOP 4
 end subroutine
 
-program testmath
+subroutine testmath
implicit none
real(kind=4) r, two4, half4
real(kind=8) q, two8, half8
complex(kind=4) cr
complex(kind=8) cq
external dotest, dotestc
+   !$acc routine seq
 
two4 = 2.0
two8 = 2.0_8
@@ -96,5 +104,16 @@ program testmath
cq = log ((-1.0_8, -1.0_8))
call dotestc (21, cr, cq, (0.3466, -2.3562))
 
-end program
+end subroutine
 
+program main
+   implicit none
+   external testmath
+
+   !$acc serial
+   !$omp target
+   call testmath
+   !$acc end serial
+   !$omp end target
+
+end program
diff --git a/libgomp/testsuite/libgomp.fortran/fortran-torture_execute_math.f90 b/libgomp/testsuite/libgomp.fortran/fortran-torture_execute_math.f90
new file mode 100644
index 000..3348a0bb3ad
--- /dev/null
+++ b/libgomp/testsuite/libgomp.fortran/fortran-torture_execute_math.f90
@@ -0,0 +1,4 @@
+! { dg-do run }
+! { dg-additional-options -foffload-options=-lm }
+
+include '../../../gcc/testsuite/gfortran.fortran-torture/execute/math.f90'
diff --git a/libgomp/testsuite/libgomp.oacc-fortran/fortran-torture_execute_math.f90 b/libgomp/testsuite/libgomp.oacc-fortran/fortran-torture_execute_math.f90
new file mode 100644
index 000..1b2ac440762
--- /dev/null
+++ b/libgomp/testsuite/libgomp.oacc-fortran/fortran-torture_execute_math.f90
@@ -0,0 +1,5 @@
+! { dg-do run }
+!TODO { dg-prune-output {using 'vector_length \(32\)', ignoring 1} }
+! { dg-additional-options -foffload-options=-lm }
+
+include '../../../gcc/testsuite/gfortran.fortran-torture/execute/math.f90'
-- 
2.34.1

[ping] driver: Forward '-lgfortran', '-lm' to offloading compilation

[Thomas Schwinge]

Hi!

On 2023-06-05T14:25:18+0200, I wrote:
> OK to push the attached
> "driver: Forward '-lgfortran', '-lm' to offloading compilation"?
> (We didn't have a PR open for that, or did we?)

Ping.


Grüße
 Thomas


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
>From 5d3cb866cad3bbcf47c5e66825e5710e86cc017e Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Mon, 5 Jun 2023 11:26:37 +0200
Subject: [PATCH] driver: Forward '-lgfortran', '-lm' to offloading compilation

..., so that users don't manually need to specify
'-foffload-options=-lgfortran', '-foffload-options=-lm' in addition to
'-lgfortran', '-lm' (specified manually, or implicitly by the driver).

	gcc/
	* gcc.cc (driver_handle_option): Forward host '-lgfortran', '-lm'
	to offloading compilation.
	* config/gcn/mkoffload.cc (main): Adjust.
	* config/nvptx/mkoffload.cc (main): Likewise.
	* doc/invoke.texi (foffload-options): Update example.
	libgomp/
	* testsuite/libgomp.fortran/fortran.exp (lang_link_flags): Don't
	set.
	* testsuite/libgomp.oacc-fortran/fortran.exp (lang_link_flags):
	Likewise.
	* testsuite/libgomp.c/simd-math-1.c: Remove
	'-foffload-options=-lm'.
	* testsuite/libgomp.fortran/fortran-torture_execute_math.f90:
	Likewise.
	* testsuite/libgomp.oacc-fortran/fortran-torture_execute_math.f90:
	Likewise.
---
 gcc/config/gcn/mkoffload.cc   | 12 
 gcc/config/nvptx/mkoffload.cc | 12 
 gcc/doc/invoke.texi   |  5 +-
 gcc/gcc.cc| 56 +++
 libgomp/testsuite/libgomp.c/simd-math-1.c |  1 -
 .../fortran-torture_execute_math.f90  |  1 -
 libgomp/testsuite/libgomp.fortran/fortran.exp |  2 -
 .../fortran-torture_execute_math.f90  |  1 -
 .../libgomp.oacc-fortran/fortran.exp  |  2 -
 9 files changed, 82 insertions(+), 10 deletions(-)

diff --git a/gcc/config/gcn/mkoffload.cc b/gcc/config/gcn/mkoffload.cc
index 988c12318fd..8b608bf024e 100644
--- a/gcc/config/gcn/mkoffload.cc
+++ b/gcc/config/gcn/mkoffload.cc
@@ -946,6 +946,18 @@ main (int argc, char **argv)
   else if (startswith (argv[i], STR))
 	gcn_stack_size = atoi (argv[i] + strlen (STR));
 #undef STR
+  /* Translate host into offloading libraries.  */
+  else if (strcmp (argv[i], "-l_GCC_gfortran") == 0
+	   || strcmp (argv[i], "-l_GCC_m") == 0)
+	{
+	  /* Elide '_GCC_'.  */
+	  size_t i_dst = strlen ("-l");
+	  size_t i_src = strlen ("-l_GCC_");
+	  char c;
+	  do
+	c = argv[i][i_dst++] = argv[i][i_src++];
+	  while (c != '\0');
+	}
 }
 
   if (!(fopenacc ^ fopenmp))
diff --git a/gcc/config/nvptx/mkoffload.cc b/gcc/config/nvptx/mkoffload.cc
index 6cdea45cffe..aaea9fb320d 100644
--- a/gcc/config/nvptx/mkoffload.cc
+++ b/gcc/config/nvptx/mkoffload.cc
@@ -649,6 +649,18 @@ main (int argc, char **argv)
   else if (strcmp (argv[i], "-dumpbase") == 0
 	   && i + 1 < argc)
 	dumppfx = argv[++i];
+  /* Translate host into offloading libraries.  */
+  else if (strcmp (argv[i], "-l_GCC_gfortran") == 0
+	   || strcmp (argv[i], "-l_GCC_m") == 0)
+	{
+	  /* Elide '_GCC_'.  */
+	  size_t i_dst = strlen ("-l");
+	  size_t i_src = strlen ("-l_GCC_");
+	  char c;
+	  do
+	c = argv[i][i_dst++] = argv[i][i_src++];
+	  while (c != '\0');
+	}
 }
   if (!(fopenacc ^ fopenmp))
 fatal_error (input_location, "either %<-fopenacc%> or %<-fopenmp%> "
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index d2d639c92d4..7b3a2a74459 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -2716,9 +2716,8 @@ the @option{-foffload-options=@var{target-list}=@var{options}} form.  The
 Typical command lines are
 
 @smallexample
--foffload-options=-lgfortran -foffload-options=-lm
--foffload-options="-lgfortran -lm" -foffload-options=nvptx-none=-latomic
--foffload-options=amdgcn-amdhsa=-march=gfx906 -foffload-options=-lm
+-foffload-options='-fno-math-errno -ffinite-math-only' -foffload-options=nvptx-none=-latomic
+-foffload-options=amdgcn-amdhsa=-march=gfx906 -foffload-options=-O3
 @end smallexample
 
 @opindex fopenacc
diff --git a/gcc/gcc.cc b/gcc/gcc.cc
index 2ccca00d603..15995206856 100644
--- a/gcc/gcc.cc
+++ b/gcc/gcc.cc
@@ -47,6 +47,9 @@ compilation is specified by a string called a "spec".  */
 #include "opts-jobserver.h"
 #include "common/common-target.h"
 
+#ifndef MATH_LIBRARY
+#define MATH_LIBRARY "m"
+#endif
 
 
 /* Manage the manipulatio

Fix typo in 'libgomp.c/target-51.c' (was: [patch] OpenMP: Set default-device-var with OMP_TARGET_OFFLOAD=mandatory)

[Thomas Schwinge]

the host device is available" to
include a comma before 'but', for consistency with the other existing
diagnostics (cited above)?


Grüße
 Thomas


> +
> +int
> +main ()
> +{
> +  int x;
> +  #pragma omp target map(tofrom:x)
> +x = 5;
> +  if (x != 5)
> +__builtin_abort ();
> +  return 0;
> +}


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
>From 2464d87db542b87a1d276637f334e9c6eb35be64 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Wed, 14 Jun 2023 09:25:15 +0200
Subject: [PATCH] Fix typo in 'libgomp.c/target-51.c'

..., and therefore, given 'target offload_device':

PASS: libgomp.c/target-51.c (test for excess errors)
PASS: libgomp.c/target-51.c execution test
[-FAIL:-]{+PASS:+} libgomp.c/target-51.c output pattern test

Fix-up for recent commit 18c8b56c7d67a9e37acf28822587786f0fc0efbc
"OpenMP: Set default-device-var with OMP_TARGET_OFFLOAD=mandatory".

	libgomp/
	* testsuite/libgomp.c/target-51.c: Fix typo.
---
 libgomp/testsuite/libgomp.c/target-51.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libgomp/testsuite/libgomp.c/target-51.c b/libgomp/testsuite/libgomp.c/target-51.c
index 7d09bceacd58..cf9e690263e9 100644
--- a/libgomp/testsuite/libgomp.c/target-51.c
+++ b/libgomp/testsuite/libgomp.c/target-51.c
@@ -10,7 +10,7 @@
 /* See comment in target-50.c/target-50.c for why the output differs.  */
 
 /* { dg-output ".*libgomp: OMP_TARGET_OFFLOAD is set to MANDATORY but only the host device is available.*" { target { ! offload_device } } } */
-/* { dg-output ".*libgomp: OMP_TARGET_OFFLOAD is set to MANDATORY but device not found.*" { target offload_device } } */
+/* { dg-output ".*libgomp: OMP_TARGET_OFFLOAD is set to MANDATORY, but device not found.*" { target offload_device } } */
 
 int
 main ()
-- 
2.39.2

Re: [committed] OpenMP: Cleanups related to the 'present' modifier

[Thomas Schwinge]

Hi Tobias!

On 2023-06-12T18:44:23+0200, Tobias Burnus  wrote:
> Cleanup follow up to
>r14-1579-g4ede915d5dde93 "openmp: Add support for the 'present' modifier"
> committed 6 days ago.
>
> Namely:
> * Replace for the program → libgomp ABI 
> GOMP_MAP_PRESENT_[ALLOC,TO,FROM,TOFROM]
>by the preexisting GOMP_MAP_FORCE_PRESENT but keep the other enum values
>(and use them until gimplifcation).
>
> * Improve wording if a non-existing/unsupported map-type modifier was used
>by not referring to 'omp target' as it could be also target (enter/exit) 
> data.
>+ Add a testcase for enter/exit data + data.
>
> * Unify + improve wording shown for 'present' when not present on the device.
>
> * Extend in the testcases to check that data actually gets copied with
>'target update' and 'map when the 'present' modifier is present.
>
> Committed as Rev. r14-1736-g38944ec2a6fa10

> OpenMP: Cleanups related to the 'present' modifier
>
> Reduce number of enum values passed to libgomp as
> GOMP_MAP_PRESENT_{TO,TOFROM,FROM,ALLOC} have the same semantic as
> GOMP_MAP_FORCE_PRESENT (i.e. abort if not present, otherwise ignore);
> that's different to GOMP_MAP_ALWAYS_PRESENT_{TO,TOFROM,FROM} which also
> abort if not present but copy data when present. This is is a follow-up to
> the commit r14-1579-g4ede915d5dde93 done 6 days ago.

Great, that matches how I thought this should be done (re our 2023-06-07
GCC IRC discussion).

> Additionally, the commit [...]
> extends testcases a tiny bit.

> gcc/testsuite/ChangeLog:

> * gfortran.dg/gomp/target-update-1.f90: Likewise.

That one addressed fixed 
"gfortran.dg/gomp/target-update-1.f90 fails after r14-1579-g4ede915d5dde93".

> --- a/include/gomp-constants.h
> +++ b/include/gomp-constants.h

|  #define GOMP_MAP_FLAG_PRESENT(GOMP_MAP_FLAG_SPECIAL_5 \
|| GOMP_MAP_FLAG_SPECIAL_0)

Couldn't/shouldn't we now get rid of this 'GOMP_MAP_FLAG_PRESENT'...

|  #define GOMP_MAP_FLAG_ALWAYS_PRESENT (GOMP_MAP_FLAG_SPECIAL_2 \
|| GOMP_MAP_FLAG_PRESENT)

..., as it is only used in 'GOMP_MAP_FLAG_ALWAYS_PRESENT' here...

> @@ -136,14 +136,6 @@ enum gomp_map_kind
> device.  */
>  GOMP_MAP_ALWAYS_TOFROM = (GOMP_MAP_FLAG_SPECIAL_2
>| GOMP_MAP_TOFROM),
> -/* Must already be present.  */
> -GOMP_MAP_PRESENT_ALLOC = (GOMP_MAP_FLAG_PRESENT | 
> GOMP_MAP_ALLOC),
> -/* Must already be present, copy to device.  */
> -GOMP_MAP_PRESENT_TO =(GOMP_MAP_FLAG_PRESENT | GOMP_MAP_TO),
> -/* Must already be present, copy from device.  */
> -GOMP_MAP_PRESENT_FROM =  (GOMP_MAP_FLAG_PRESENT | GOMP_MAP_FROM),
> -/* Must already be present, copy to and from device.  */
> -GOMP_MAP_PRESENT_TOFROM =(GOMP_MAP_FLAG_PRESENT | 
> GOMP_MAP_TOFROM),
>  /* Must already be present, unconditionally copy to device.  */
>  GOMP_MAP_ALWAYS_PRESENT_TO = (GOMP_MAP_FLAG_ALWAYS_PRESENT
>| GOMP_MAP_TO),
> @@ -205,7 +197,13 @@ enum gomp_map_kind
>  /* An attach or detach operation.  Rewritten to the appropriate type 
> during
> gimplification, depending on directive (i.e. "enter data" or
> parallel/kernels region vs. "exit data").  */
> -GOMP_MAP_ATTACH_DETACH = (GOMP_MAP_LAST | 3)
> +GOMP_MAP_ATTACH_DETACH = (GOMP_MAP_LAST | 3),
> +/* Must already be present - all of following map to 
> GOMP_MAP_FORCE_PRESENT
> +   as no data transfer is needed.  */
> +GOMP_MAP_PRESENT_ALLOC = (GOMP_MAP_LAST | 4),
> +GOMP_MAP_PRESENT_TO =(GOMP_MAP_LAST | 5),
> +GOMP_MAP_PRESENT_FROM =  (GOMP_MAP_LAST | 6),
> +GOMP_MAP_PRESENT_TOFROM =(GOMP_MAP_LAST | 7)
>};
>
>  #define GOMP_MAP_COPY_TO_P(X) \
> @@ -243,7 +241,8 @@ enum gomp_map_kind
>(((X) & GOMP_MAP_FLAG_SPECIAL_BITS) == GOMP_MAP_FLAG_FORCE)
>
>  #define GOMP_MAP_PRESENT_P(X) \
> -  (((X) & GOMP_MAP_FLAG_PRESENT) == GOMP_MAP_FLAG_PRESENT)
> +  (((X) & GOMP_MAP_FLAG_PRESENT) == GOMP_MAP_FLAG_PRESENT \
> +   || (X) == GOMP_MAP_FORCE_PRESENT)

..., and this 'GOMP_MAP_PRESENT_P' should look for
'GOMP_MAP_FLAG_ALWAYS_PRESENT' instead of 'GOMP_MAP_FLAG_PRESENT' (plus
'GOMP_MAP_FORCE_PRESENT')?

Instead of the current effective 'GOMP_MAP_FLAG_ALWAYS_PRESENT':

GOMP_MAP_FLAG_SPECIAL_0
| GOMP_MAP_FLAG_SPECIAL_2
| GOMP_MAP_FLAG_SPECIAL_5

..., it could/should use a simpler flag combination?  (My idea is that
this later make usage of flag bits for other purposes easier -- but I've
not verified that in depth.)


Grüße
 Thomas
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf

Add 'libgomp.{,oacc-}fortran/fortran-torture_execute_math.f90'

[Thomas Schwinge]

Hi!

On 2023-06-13T13:11:38+0200, Tobias Burnus  wrote:
> On 13.06.23 12:42, Thomas Schwinge wrote:
>> On 2023-06-05T14:18:48+0200, I wrote:
>>> OK to push the attached
>>> "Add 'libgomp.{,oacc-}fortran/fortran-torture_execute_math.f90'"?
>>
>> Subject: [PATCH] Add
>>   'libgomp.{,oacc-}fortran/fortran-torture_execute_math.f90'
>>
>>   gcc/testsuite/
>>   * gfortran.fortran-torture/execute/math.f90: Enhance for optional
>>   OpenACC, OpenMP 'target' usage.
>
> I think it is more readable with a linebreak here and with "OpenACC
> 'serial' and OpenMP ..." instead of "OpenACC, OpenMP".
>
> What I would like to see a hint somewhere in the commit log that the
> libgomp files include the gfortran.fortran-torture file. I don't care
> whether you add the hint before the changelog items as free text – or in
> the bullet above (e.g. "as it is included in libgomp/testsuite") – or
> after "New." in the following bullet list.
>
>>   libgomp/
>>   * testsuite/libgomp.fortran/fortran-torture_execute_math.f90: New.
>>   * testsuite/libgomp.oacc-fortran/fortran-torture_execute_math.f90:
>>   Likewise.
>
>> ---
>>   .../gfortran.fortran-torture/execute/math.f90 | 23 +--
>>   .../fortran-torture_execute_math.f90  |  4 
>>   .../fortran-torture_execute_math.f90  |  5 
>>   3 files changed, 30 insertions(+), 2 deletions(-)
>>   create mode 100644 
>> libgomp/testsuite/libgomp.fortran/fortran-torture_execute_math.f90
>>   create mode 100644 
>> libgomp/testsuite/libgomp.oacc-fortran/fortran-torture_execute_math.f90
>>
>> diff --git a/gcc/testsuite/gfortran.fortran-torture/execute/math.f90 
>> b/gcc/testsuite/gfortran.fortran-torture/execute/math.f90
>> index 17cc78f7a10..e71f669304f 100644
>> --- a/gcc/testsuite/gfortran.fortran-torture/execute/math.f90
>> +++ b/gcc/testsuite/gfortran.fortran-torture/execute/math.f90
>> @@ -1,9 +1,14 @@
>>   ! Program to test mathematical intrinsics
>> +
>> +! See also 
>> 'libgomp/testsuite/libgomp.fortran/fortran-torture_execute_math.f90'; thus 
>> the '!$omp' directives.
>> +! See also 
>> 'libgomp/testsuite/libgomp.oacc-fortran/fortran-torture_execute_math.f90'; 
>> thus the '!$acc' directives.
>
> Likewise here: it is not completely obvious that this file is 'include'd
> by the other testcases.
>
> Maybe add a line "! This file is also included in:" and remove the "See
> also" or some creative variant of it.
>
> Minor remark: The OpenMP part is OK, but strict reading of the spec
> requires an "omp declare target' if a subroutine is in a different
> compilation unit. And according the glossary, that's the case here. In
> practice, it also works without as it is in the same translation unit.
> (compilation unit = for C/C++: translation unit, for Fortran:
> subprogram). I think the HPE/Cray compiler will complain, but maybe only
> when used with modules and not with subroutine subprograms. (As many
> compilers write a .mod file for modules, a late change of attributes can
> be more problematic.)
>
> Otherwise LGTM.

Thanks for the review.  I've now pushed
commit e76af2162c7b768ef0a913d485c51a80b08a1020
"Add 'libgomp.{,oacc-}fortran/fortran-torture_execute_math.f90'", see
attached.

> PS: I assume that you have check it with both with an in-build-tree and
> an in-install-tree testsuite run.

I happened to have (..., but don't think it'd make a relevant difference
here?)


Grüße
 Thomas


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
>From e76af2162c7b768ef0a913d485c51a80b08a1020 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Fri, 2 Jun 2023 23:11:00 +0200
Subject: [PATCH] Add
 'libgomp.{,oacc-}fortran/fortran-torture_execute_math.f90'

..., via 'include'ing the existing 'gfortran.fortran-torture/execute/math.f90',
which therefore is enhanced for optional OpenACC 'serial', OpenMP 'target'
usage.

	gcc/testsuite/
	* gfortran.fortran-torture/execute/math.f90: Enhance for optional
	OpenACC 'serial', OpenMP 'target' usage.
	libgomp/
	* testsuite/libgomp.fortran/fortran-torture_execute_math.f90: New.
	* testsuite/libgomp.oacc-fortran/fortran-torture_execute_math.f90:
	Likewise.
---
 .../gfortran.fort

libgomp testsuite: Don't handle 'lang_link_flags'

[Thomas Schwinge]

Hi!

Any objections to pushing the attached
"libgomp testsuite: Don't handle 'lang_link_flags'"?


Grüße
 Thomas


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
>From b3d33dc858fffeeed83735e55d86963e2297a78d Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Mon, 5 Jun 2023 11:45:41 +0200
Subject: [PATCH] libgomp testsuite: Don't handle 'lang_link_flags'

..., which as of recent commit 4bcb46b3ade1796c5a57b294f5cca25f00671cac
"driver: Forward '-lgfortran', '-lm' to offloading compilation" is unused,
and we don't anticipate any new usage.

	libgomp/
	* testsuite/lib/libgomp.exp (libgomp_target_compile): Don't handle
	'lang_link_flags'.
---
 libgomp/testsuite/lib/libgomp.exp | 4 
 1 file changed, 4 deletions(-)

diff --git a/libgomp/testsuite/lib/libgomp.exp b/libgomp/testsuite/lib/libgomp.exp
index 1c4af9a8a2c..fb2bce38e28 100644
--- a/libgomp/testsuite/lib/libgomp.exp
+++ b/libgomp/testsuite/lib/libgomp.exp
@@ -277,10 +277,6 @@ proc libgomp_target_compile { source dest type options } {
 	lappend options "ldflags=-L${blddir}/${lang_library_path}"
 	}
 }
-global lang_link_flags
-if { [info exists lang_link_flags] } {
-	lappend options "ldflags=${lang_link_flags}"
-}
 
 if { [target_info needs_status_wrapper] != "" && [info exists gluefile] } {
 	lappend options "libs=${gluefile}"
-- 
2.34.1

Align a 'OMP_TARGET_OFFLOAD=mandatory' diagnostic with others (was: Fix typo in 'libgomp.c/target-51.c' (was: [patch] OpenMP: Set default-device-var with OMP_TARGET_OFFLOAD=mandatory))

[Thomas Schwinge]

Hi!

On 2023-06-14T11:42:22+0200, Tobias Burnus  wrote:
> On 14.06.23 10:09, Thomas Schwinge wrote:
>> Let me know if I should also adjust the new 'target { ! offload_device }'
>> diagnostic "[...] MANDATORY but only the host device is available" to
>> include a comma before 'but', for consistency with the other existing
>> diagnostics (cited above)?
>
> I think it makes sense to be consistent. Thus: Yes, please add the commas.

I've pushed commit f2ef1dabbc18eb6efc0eb47bbb0eebbc6d72e09e
"Align a 'OMP_TARGET_OFFLOAD=mandatory' diagnostic with others", see
attached.


Grüße
 Thomas


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
>From f2ef1dabbc18eb6efc0eb47bbb0eebbc6d72e09e Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Wed, 14 Jun 2023 12:44:05 +0200
Subject: [PATCH] Align a 'OMP_TARGET_OFFLOAD=mandatory' diagnostic with others

On 2023-06-14T11:42:22+0200, Tobias Burnus  wrote:
> On 14.06.23 10:09, Thomas Schwinge wrote:
>> Let me know if I should also adjust the new 'target { ! offload_device }'
>> diagnostic "[...] MANDATORY but only the host device is available" to
>> include a comma before 'but', for consistency with the other existing
>> diagnostics (cited above)?
>
> I think it makes sense to be consistent. Thus: Yes, please add the commas.

Fix-up for recent commit 18c8b56c7d67a9e37acf28822587786f0fc0efbc
"OpenMP: Set default-device-var with OMP_TARGET_OFFLOAD=mandatory".

	libgomp/
	* target.c (resolve_device): Align a
	'OMP_TARGET_OFFLOAD=mandatory' diagnostic with others.
	* testsuite/libgomp.c/target-51.c: Adjust.
---
 libgomp/target.c| 4 ++--
 libgomp/testsuite/libgomp.c/target-51.c | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/libgomp/target.c b/libgomp/target.c
index f1020fad601b..e39ef8f6e82a 100644
--- a/libgomp/target.c
+++ b/libgomp/target.c
@@ -152,8 +152,8 @@ resolve_device (int device_id, bool remapped)
 	return NULL;
   if (gomp_target_offload_var == GOMP_TARGET_OFFLOAD_MANDATORY
 	  && gomp_get_num_devices () == 0)
-	gomp_fatal ("OMP_TARGET_OFFLOAD is set to MANDATORY but only the host "
-		"device is available");
+	gomp_fatal ("OMP_TARGET_OFFLOAD is set to MANDATORY, "
+		"but only the host device is available");
   else if (device_id == omp_invalid_device)
 	gomp_fatal ("omp_invalid_device encountered");
   else if (gomp_target_offload_var == GOMP_TARGET_OFFLOAD_MANDATORY)
diff --git a/libgomp/testsuite/libgomp.c/target-51.c b/libgomp/testsuite/libgomp.c/target-51.c
index cf9e690263e9..bbe9ade6e24b 100644
--- a/libgomp/testsuite/libgomp.c/target-51.c
+++ b/libgomp/testsuite/libgomp.c/target-51.c
@@ -9,7 +9,7 @@
 
 /* See comment in target-50.c/target-50.c for why the output differs.  */
 
-/* { dg-output ".*libgomp: OMP_TARGET_OFFLOAD is set to MANDATORY but only the host device is available.*" { target { ! offload_device } } } */
+/* { dg-output ".*libgomp: OMP_TARGET_OFFLOAD is set to MANDATORY, but only the host device is available.*" { target { ! offload_device } } } */
 /* { dg-output ".*libgomp: OMP_TARGET_OFFLOAD is set to MANDATORY, but device not found.*" { target offload_device } } */
 
 int
-- 
2.39.2

Re: [r14-1805 Regression] FAIL: c-c++-common/Wfree-nonheap-object-3.c -std=gnu++98 (test for warnings, line 45) on Linux/x86_64

[Thomas Schwinge]

Hi!

On 2023-06-15T08:50:59+0800, "haochen.jiang via Gcc-patches" 
 wrote:
> On Linux/x86_64,

Actually: generally...

> 9c03391ba447ff86038d6a34c90ae737c3915b5f is the first bad commit
> commit 9c03391ba447ff86038d6a34c90ae737c3915b5f
> Author: Thomas Schwinge 
> Date:   Wed Jun 7 16:24:26 2023 +0200
>
> Tighten 'dg-warning' alternatives in 
> 'c-c++-common/Wfree-nonheap-object{,-2,-3}.c'
>
> caused
>
> FAIL: c-c++-common/Wfree-nonheap-object-3.c  -std=gnu++14 (test for excess 
> errors)
> FAIL: c-c++-common/Wfree-nonheap-object-3.c  -std=gnu++14  (test for 
> warnings, line 45)
> FAIL: c-c++-common/Wfree-nonheap-object-3.c  -std=gnu++17 (test for excess 
> errors)
> FAIL: c-c++-common/Wfree-nonheap-object-3.c  -std=gnu++17  (test for 
> warnings, line 45)
> FAIL: c-c++-common/Wfree-nonheap-object-3.c  -std=gnu++20 (test for excess 
> errors)
> FAIL: c-c++-common/Wfree-nonheap-object-3.c  -std=gnu++20  (test for 
> warnings, line 45)
> FAIL: c-c++-common/Wfree-nonheap-object-3.c  -std=gnu++98 (test for excess 
> errors)
> FAIL: c-c++-common/Wfree-nonheap-object-3.c  -std=gnu++98  (test for 
> warnings, line 45)

Indeed.  Sorry -- not sure how that escaped my testing.  I already did
have the fix in a different Git commit (but not in my testing build).
Pushed to master branch commit df071fbd467f0cb379ef41d74792fc5e6c8c
"Fix 'dg-warning' in 'c-c++-common/Wfree-nonheap-object-3.c' for C++",
see attached.


Grüße
 Thomas


> with GCC configured with
>
> ../../gcc/configure 
> --prefix=/export/users/haochenj/src/gcc-bisect/master/master/r14-1805/usr 
> --enable-clocale=gnu --with-system-zlib --with-demangler-in-ld 
> --with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl 
> --enable-libmpx x86_64-linux --disable-bootstrap
>
> To reproduce:
>
> $ cd {build_dir}/gcc && make check 
> RUNTESTFLAGS="dg.exp=c-c++-common/Wfree-nonheap-object-3.c 
> --target_board='unix{-m32}'"
> $ cd {build_dir}/gcc && make check 
> RUNTESTFLAGS="dg.exp=c-c++-common/Wfree-nonheap-object-3.c 
> --target_board='unix{-m32\ -march=cascadelake}'"
> $ cd {build_dir}/gcc && make check 
> RUNTESTFLAGS="dg.exp=c-c++-common/Wfree-nonheap-object-3.c 
> --target_board='unix{-m64}'"
> $ cd {build_dir}/gcc && make check 
> RUNTESTFLAGS="dg.exp=c-c++-common/Wfree-nonheap-object-3.c 
> --target_board='unix{-m64\ -march=cascadelake}'"
>
> (Please do not reply to this email, for question about this report, contact 
> me at haochen dot jiang at intel.com)


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
>From df071fbd467f0cb379ef41d74792fc5e6c8c Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Wed, 7 Jun 2023 17:12:01 +0200
Subject: [PATCH] Fix 'dg-warning' in 'c-c++-common/Wfree-nonheap-object-3.c'
 for C++

[...]/c-c++-common/Wfree-nonheap-object-3.c:57:24: warning: 'malloc (dealloc_float)' attribute ignored with deallocation functions declared 'inline' [-Wattributes]
[...]/c-c++-common/Wfree-nonheap-object-3.c:51:1: note: deallocation function declared here
[...]/c-c++-common/Wfree-nonheap-object-3.c: In function 'void test_nowarn_int(int)':
[...]/c-c++-common/Wfree-nonheap-object-3.c:25:20: warning: 'void __builtin_free(void*)' called on pointer 'p' with nonzero offset 4 [-Wfree-nonheap-object]
[...]/c-c++-common/Wfree-nonheap-object-3.c:24:24: note: returned from 'int* alloc_int(int)'
[...]/c-c++-common/Wfree-nonheap-object-3.c: In function 'void test_nowarn_long(int)':
[...]/c-c++-common/Wfree-nonheap-object-3.c:45:18: warning: 'void dealloc_long(long int*)' called on pointer '' with nonzero offset 8 [-Wfree-nonheap-object]
[...]/c-c++-common/Wfree-nonheap-object-3.c:44:26: note: returned from 'long int* alloc_long(int)'
In function 'void dealloc_float(float*)',
inlined from 'void test_nowarn_float(int)' at [...]/c-c++-common/Wfree-nonheap-object-3.c:68:19:
[...]/c-c++-common/Wfree-nonheap-object-3.c:53:18: warning: 'void __builtin_free(void*)' called on pointer '' with nonzero offset 8 [-Wfree-nonheap-object]
[...]/c-c++-common/Wfree-nonheap-object-3.c: In function 'void test_nowarn_float(int)':
[...]/c-c++-common/Wfree-nonheap-object-3.c:67:28: note: returned from 'float* alloc_float(int)'
PASS: c-c++-common/Wfree-nonheap-object-3.

Skip a number of C++ test cases for '-fno-exceptions' testing (was: Support in the GCC(/C++) test suites for '-fno-exceptions')

[Thomas Schwinge]

Hi!

On 2023-06-06T20:31:21+0100, Jonathan Wakely  wrote:
> On Tue, 6 Jun 2023 at 20:14, Thomas Schwinge  wrote:
>> This issue comes up in context of me working on C++ support for GCN and
>> nvptx target.  Those targets shall default to '-fno-exceptions' -- or,
>> "in other words", '-fexceptions' is not supported.  (Details omitted
>> here.)
>>
>> It did seem clear to me that with such a configuration it'll be hard to
>> get clean test results.  Then I found code in
>> 'gcc/testsuite/lib/gcc-dg.exp:gcc-dg-prune':
>>
>> # If exceptions are disabled, mark tests expecting exceptions to be 
>> enabled
>> # as unsupported.
>> if { ![check_effective_target_exceptions_enabled] } {
>> if [regexp "(^|\n)\[^\n\]*: error: exception handling disabled" 
>> $text] {
>> return "::unsupported::exception handling disabled"
>> }
>>
>> ..., which, in a way, sounds as if the test suite generally is meant to
>> produce useful results for '-fno-exceptions', nice surprise!
>>
>> Running x86_64-pc-linux-gnu (not yet GCN, nvptx) 'make check' with:
>>
>> RUNTESTFLAGS='--target_board=unix/-fno-exceptions\{,-m32\}'
>>
>> ..., I find that indeed this does work for a lot of test cases, where we
>> then get (random example):
>>
>>  PASS: g++.dg/coroutines/pr99710.C  (test for errors, line 23)
>> -PASS: g++.dg/coroutines/pr99710.C (test for excess errors)
>> +UNSUPPORTED: g++.dg/coroutines/pr99710.C: exception handling disabled
>>
>> ..., due to:
>>
>>  [...]/g++.dg/coroutines/pr99710.C: In function 'task my_coro()':
>> +[...]/g++.dg/coroutines/pr99710.C:18:10: error: exception handling
>> disabled, use '-fexceptions' to enable
>>  [...]/g++.dg/coroutines/pr99710.C:23:7: error: await expressions are
>> not permitted in handlers
>>  compiler exited with status 1
>>
>> But, we're nowhere near clean test results: PASS -> FAIL as well as
>> XFAIL -> XPASS regressions, due to 'error: exception handling disabled'
>> precluding other diagnostics seems to be one major issue.
>>
>> Is there interest in me producing the obvious (?) changes to those test
>> cases, such that compiler g++ as well as target library libstdc++ test
>> results are reasonably clean?  (If you think that's all "wasted effort",
>> then I suppose I'll just locally ignore any FAILs/XPASSes/UNRESOLVEDs
>> that appear in combination with
>> 'UNSUPPORTED: [...]: exception handling disabled'.)
>
> I would welcome that for libstdc++. I do sometimes run the libstdc++ tests
> with "unusual" options, like -fno-exceptions and -fno-rtti (e.g. today I've
> been fixing FAILs that only happen with -fexcess-precision=standard). I
> just manually ignore the tests that fail for -fno-exceptions, but it would
> be great if they were automatically skipped as UNSUPPORTED.

Per your and my changes a few days ago, we've already got libstdc++
covered, with the sole exception of:

PASS: 27_io/basic_ostream/inserters_arithmetic/pod/23875.cc (test for 
excess errors)
[-PASS:-]{+FAIL:+} 27_io/basic_ostream/inserters_arithmetic/pod/23875.cc 
execution test

terminate called after throwing an instance of 'std::bad_cast'
  what():  std::bad_cast

(Low priority for me.)

Not having heard anything contrary regarding the compiler side of things,
I've now been working on that, see below.

> We already have a handful of tests that use #if __cpp_exceptions to make
> those parts conditional on exception support.

Yes, that's an option not for all but certainly for some test cases.
(I'm not looking into that now -- but this may in fact be a good
beginner-level task, will add to <https://gcc.gnu.org/wiki/EasyHacks>).

>> Otherwise, a number of test cases need DejaGnu directives
>> conditionalized on 'target exceptions_enabled'.

Before I get to such things, even simpler: OK to push the attached
"Skip a number of C++ test cases for '-fno-exceptions' testing"?


>> (Or,
>> 'error: exception handling disabled' made a "really late" diagnostic, so
>> that it doesn't preclude other diagnostics?  I'll have a look.  Well,
>> maybe something like: in fact do not default to '-fno-exceptions', but
>> instead emit 'error: exception handling disabled' only if in a "really
>> late" pass we run into exceptions-related constructs that we cannot
>> support.  Th

Skip a number of C++ "split files" test cases for '-fno-exceptions' testing (was: Skip a number of C++ test cases for '-fno-exceptions' testing (was: Support in the GCC(/C++) test suites for '-fno-exc

[Thomas Schwinge]

Hi!

On 2023-06-15T17:15:54+0200, I wrote:
> On 2023-06-06T20:31:21+0100, Jonathan Wakely  wrote:
>> On Tue, 6 Jun 2023 at 20:14, Thomas Schwinge  wrote:
>>> This issue comes up in context of me working on C++ support for GCN and
>>> nvptx target.  Those targets shall default to '-fno-exceptions' -- or,
>>> "in other words", '-fexceptions' is not supported.  (Details omitted
>>> here.)
>>>
>>> It did seem clear to me that with such a configuration it'll be hard to
>>> get clean test results.  Then I found code in
>>> 'gcc/testsuite/lib/gcc-dg.exp:gcc-dg-prune':
>>>
>>> # If exceptions are disabled, mark tests expecting exceptions to be 
>>> enabled
>>> # as unsupported.
>>> if { ![check_effective_target_exceptions_enabled] } {
>>> if [regexp "(^|\n)\[^\n\]*: error: exception handling disabled" 
>>> $text] {
>>> return "::unsupported::exception handling disabled"
>>> }
>>>
>>> ..., which, in a way, sounds as if the test suite generally is meant to
>>> produce useful results for '-fno-exceptions', nice surprise!
>>>
>>> Running x86_64-pc-linux-gnu (not yet GCN, nvptx) 'make check' with:
>>>
>>> RUNTESTFLAGS='--target_board=unix/-fno-exceptions\{,-m32\}'
>>>
>>> ..., I find that indeed this does work for a lot of test cases, where we
>>> then get (random example):
>>>
>>>  PASS: g++.dg/coroutines/pr99710.C  (test for errors, line 23)
>>> -PASS: g++.dg/coroutines/pr99710.C (test for excess errors)
>>> +UNSUPPORTED: g++.dg/coroutines/pr99710.C: exception handling disabled
>>>
>>> ..., due to:
>>>
>>>  [...]/g++.dg/coroutines/pr99710.C: In function 'task my_coro()':
>>> +[...]/g++.dg/coroutines/pr99710.C:18:10: error: exception handling
>>> disabled, use '-fexceptions' to enable
>>>  [...]/g++.dg/coroutines/pr99710.C:23:7: error: await expressions are
>>> not permitted in handlers
>>>  compiler exited with status 1
>>>
>>> But, we're nowhere near clean test results: PASS -> FAIL as well as
>>> XFAIL -> XPASS regressions, due to 'error: exception handling disabled'
>>> precluding other diagnostics seems to be one major issue.
>>>
>>> Is there interest in me producing the obvious (?) changes to those test
>>> cases, such that compiler g++ as well as target library libstdc++ test
>>> results are reasonably clean?  (If you think that's all "wasted effort",
>>> then I suppose I'll just locally ignore any FAILs/XPASSes/UNRESOLVEDs
>>> that appear in combination with
>>> 'UNSUPPORTED: [...]: exception handling disabled'.)
>>
>> I would welcome that for libstdc++. [...]

> Not having heard anything contrary regarding the compiler side of things,
> I've now been working on that, see below.

>>> Otherwise, a number of test cases need DejaGnu directives
>>> conditionalized on 'target exceptions_enabled'.
>
> Before I get to such things, even simpler: OK to push the attached
> "Skip a number of C++ test cases for '-fno-exceptions' testing"?

Similarly, OK to push the attached
"Skip a number of C++ "split files" test cases for '-fno-exceptions' testing"?


Grüße
 Thomas


>>> (Or,
>>> 'error: exception handling disabled' made a "really late" diagnostic, so
>>> that it doesn't preclude other diagnostics?  I'll have a look.  Well,
>>> maybe something like: in fact do not default to '-fno-exceptions', but
>>> instead emit 'error: exception handling disabled' only if in a "really
>>> late" pass we run into exceptions-related constructs that we cannot
>>> support.  That'd also avoid PASS -> UNSUPPORTED "regressions" when
>>> exception handling in fact gets optimized away, for example.  I like that
>>> idea, conceptually -- but is it feasible to implement..?)
>>
>> IMHO just [...] using [an effective target keyword] in test
>> selectors seems simpler, and doesn't require changes to the compiler, just
>> the tests.
>
> I still like the idea, but yes, I've mentally put it on file "for later"
> (ha, ha, ha...) -- it doesn't seem obvious to implement.
>
>
> Grüße
>  Thomas


-
Siemens Ele

Skip a number of C++ 'g++.dg/tree-prof/' test cases for '-fno-exceptions' testing (was: Skip a number of C++ test cases for '-fno-exceptions' testing (was: Support in the GCC(/C++) test suites for '-f

[Thomas Schwinge]

Hi!

On 2023-06-15T17:15:54+0200, I wrote:
> On 2023-06-06T20:31:21+0100, Jonathan Wakely  wrote:
>> On Tue, 6 Jun 2023 at 20:14, Thomas Schwinge  wrote:
>>> This issue comes up in context of me working on C++ support for GCN and
>>> nvptx target.  Those targets shall default to '-fno-exceptions' -- or,
>>> "in other words", '-fexceptions' is not supported.  (Details omitted
>>> here.)
>>>
>>> It did seem clear to me that with such a configuration it'll be hard to
>>> get clean test results.  Then I found code in
>>> 'gcc/testsuite/lib/gcc-dg.exp:gcc-dg-prune':
>>>
>>> # If exceptions are disabled, mark tests expecting exceptions to be 
>>> enabled
>>> # as unsupported.
>>> if { ![check_effective_target_exceptions_enabled] } {
>>> if [regexp "(^|\n)\[^\n\]*: error: exception handling disabled" 
>>> $text] {
>>> return "::unsupported::exception handling disabled"
>>> }
>>>
>>> ..., which, in a way, sounds as if the test suite generally is meant to
>>> produce useful results for '-fno-exceptions', nice surprise!
>>>
>>> Running x86_64-pc-linux-gnu (not yet GCN, nvptx) 'make check' with:
>>>
>>> RUNTESTFLAGS='--target_board=unix/-fno-exceptions\{,-m32\}'
>>>
>>> ..., I find that indeed this does work for a lot of test cases, where we
>>> then get (random example):
>>>
>>>  PASS: g++.dg/coroutines/pr99710.C  (test for errors, line 23)
>>> -PASS: g++.dg/coroutines/pr99710.C (test for excess errors)
>>> +UNSUPPORTED: g++.dg/coroutines/pr99710.C: exception handling disabled
>>>
>>> ..., due to:
>>>
>>>  [...]/g++.dg/coroutines/pr99710.C: In function 'task my_coro()':
>>> +[...]/g++.dg/coroutines/pr99710.C:18:10: error: exception handling
>>> disabled, use '-fexceptions' to enable
>>>  [...]/g++.dg/coroutines/pr99710.C:23:7: error: await expressions are
>>> not permitted in handlers
>>>  compiler exited with status 1
>>>
>>> But, we're nowhere near clean test results: PASS -> FAIL as well as
>>> XFAIL -> XPASS regressions, due to 'error: exception handling disabled'
>>> precluding other diagnostics seems to be one major issue.
>>>
>>> Is there interest in me producing the obvious (?) changes to those test
>>> cases, such that compiler g++ as well as target library libstdc++ test
>>> results are reasonably clean?  (If you think that's all "wasted effort",
>>> then I suppose I'll just locally ignore any FAILs/XPASSes/UNRESOLVEDs
>>> that appear in combination with
>>> 'UNSUPPORTED: [...]: exception handling disabled'.)
>>
>> I would welcome that for libstdc++. [...]

> Not having heard anything contrary regarding the compiler side of things,
> I've now been working on that, see below.

>>> Otherwise, a number of test cases need DejaGnu directives
>>> conditionalized on 'target exceptions_enabled'.
>
> Before I get to such things, even simpler: OK to push the attached
> "Skip a number of C++ test cases for '-fno-exceptions' testing"?

Similarly, OK to push the attached
"Skip a number of C++ 'g++.dg/tree-prof/' test cases for '-fno-exceptions' 
testing"?


Grüße
 Thomas


>>> (Or,
>>> 'error: exception handling disabled' made a "really late" diagnostic, so
>>> that it doesn't preclude other diagnostics?  I'll have a look.  Well,
>>> maybe something like: in fact do not default to '-fno-exceptions', but
>>> instead emit 'error: exception handling disabled' only if in a "really
>>> late" pass we run into exceptions-related constructs that we cannot
>>> support.  That'd also avoid PASS -> UNSUPPORTED "regressions" when
>>> exception handling in fact gets optimized away, for example.  I like that
>>> idea, conceptually -- but is it feasible to implement..?)
>>
>> IMHO just [...] using [an effective target keyword] in test
>> selectors seems simpler, and doesn't require changes to the compiler, just
>> the tests.
>
> I still like the idea, but yes, I've mentally put it on file "for later"
> (ha, ha, ha...) -- it doesn't seem obvious to implement.
>
>
> Grüße
>  Thomas


-
Siemens E

Re: [committed] - Re: [patch] OpenMP/Fortran: Non-rectangular loops with constant steps other than 1 or -1 [PR107424]

[Thomas Schwinge]

Hi Tobias!

On 2023-07-19T10:26:12+0200, Tobias Burnus  wrote:
> Now committed as Rev. r14-2634-g85da0b40538fb0

On devel/omp/gcc-13 branch, the corresponding
commit b003e6511754dce475f7f5b0c5cd887a177e41b3
"OpenMP/Fortran: Non-rectangular loops with constant steps other than 1 or -1 
[PR107424]"
introduces a regression:

PASS: libgomp.fortran/loop-transforms/unroll-2.f90   -O0  (test for excess 
errors)
[-PASS:-]{+FAIL:+} libgomp.fortran/loop-transforms/unroll-2.f90   -O0  
execution test

Etc.

spawn [open ...]
   4
   8
  10
  11

Program aborted. Backtrace:
#0  0x400f9c in test
at [...]/libgomp.fortran/loop-transforms/unroll-2.f90:85
#1  0x400fd3 in main
at [...]/libgomp.fortran/loop-transforms/unroll-2.f90:59


Grüße
 Thomas


> Changes:
>
> * I missed to updated another 'sorry' (msg wording change) - now fixed;
> I also added it to the sorry-testcase file non-rectangular-loop-5.f90.
>
> * I decided to retire the PR as several issues have been fixed and the
> original title did not fit any more. The remaining issue is now tracked
> in PR110735 (i.e. handling step != const, both the generic and possibly
> a simpler special case).
>
> * I added a link to the PR to libgomp.texi such that one can find out
> what is only partially supported for Fortran.
>
> Thanks,
>
> Tobias
>
> PS: Otherwise, the following still applies:
>
> On 18.07.23 14:11, Tobias Burnus wrote:
>> Comments regarding the validity of the Fortran assumptions are welcome!
>>
>> This patch now uses a 'simple' loop for OpenMP loops with
>> a constant loop-step size. Before, it only did so for step = ±1.
>> (Otherwise, a count variable is used from which the original
>> loop index variable is calculated from.)
>>
>> For details, see the attached patch or
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107424#c12
>> (comment 12 + 14 plus the email linked in comment 12).
>>
>> Comments? Remarks? If there are none, I will relatively soonish
>> commit the attached patch to mainline, only.

> commit 85da0b40538fb0d17d89de1e7905984668e3dfef
> Author: Tobias Burnus 
> Date:   Wed Jul 19 10:18:49 2023 +0200
>
> OpenMP/Fortran: Non-rectangular loops with constant steps other than 1 or 
> -1 [PR107424]
>
> Before this commit, gfortran produced with OpenMP for 'do i = 1,10,2'
> the code
>   for (count.0 = 0; count.0 < 5; count.0 = count.0 + 1)
> i = count.0 * 2 + 1;
>
> While such an inner loop can be collapsed, a non-rectangular could not.
> With this commit and for all constant loop steps, a simple loop such
> as 'for (i = 1; i <= 10; i = i + 2)' is created. (Before only for the
> constant steps of 1 and -1.)
>
> The constant step permits to know the direction (increasing/decreasing)
> that is required for the loop condition.
>
> The new code is only valid if one assumes no overflow of the loop 
> variable.
> However, the Fortran standard can be read that this must be ensured by
> the user. Namely, the Fortran standard requires (F2023, 10.1.5.2.4):
> "The execution of any numeric operation whose result is not defined by
> the arithmetic used by the processor is prohibited."
>
> And, for DO loops, F2023's "11.1.7.4.3 The execution cycle" has the
> following: The number of loop iterations handled by an iteration count,
> which would permit code like 'do i = huge(i)-5, huge(i),4'. However,
> in step (3), this count is not only decremented by one but also:
>   "... The DO variable, if any, is incremented by the value of the
>   incrementation parameter m3."
> And for the example above, 'i' would be 'huge(i)+3' in the last
> execution cycle, which exceeds the largest model number and should
> render the example as invalid.
>
> PR fortran/107424
>
> gcc/fortran/ChangeLog:
>
> * trans-openmp.cc (gfc_nonrect_loop_expr): Accept all
> constant loop steps.
> (gfc_trans_omp_do): Likewise; use sign to determine
> loop direction.
>
> libgomp/ChangeLog:
>
> * libgomp.texi (Impl. Status 5.0): Add link to new PR110735.
> * testsuite/libgomp.fortran/non-rectangular-loop-1.f90: Enable
> commented tests.
> * testsuite/libgomp.fortran/non-rectangular-loop-1a.f90: Remove
> test file; tests are in non-rectangular-loop-1.f90.
> * testsuite/libgomp.fortran/non-rectangular-loop-5.f90: Change
> testcase to use a non-constant step to retain the 'sorry' test.
> * testsuite/libgomp.fortran/non-rectangular-loop-6.f90: New test.
>
> gcc/testsuite/ChangeLog:
>
> * gfortran.dg/gomp/linear-2.f90: Update dump to remove
> the additional count variable.
> ---
>  gcc/fortran/trans-openmp.cc|  18 +-
>  gcc/testsuite/gfortran.dg/gomp/linear-2.f90|   4 +-
>  libgomp/libgomp.t

Re: [PATCH, OpenACC 2.7, v2] Implement host_data must have use_device clause requirement

[Thomas Schwinge]

Hi Chung-Lin!

On 2023-07-13T18:54:00+0800, Chung-Lin Tang  wrote:
> On 2023/6/16 5:13 PM, Thomas Schwinge wrote:
>> OK with one small change, please -- unless there's a reason for doing it
>> this way: [...]

> I've adjusted the Fortran implementation as you described. Yes, I agree this 
> way
> more fits current Fortran FE conventions.
>
> I've re-tested the attached v2 patch, will commit later this week if no major
> objections.

ACK, thanks.


Grüße
 Thomas


> gcc/c/ChangeLog:
>
>   * c-parser.cc (c_parser_oacc_host_data): Add checking requiring OpenACC
>   host_data construct to have an use_device clause.
>
> gcc/cp/ChangeLog:
>
>   * parser.cc (cp_parser_oacc_host_data): Add checking requiring OpenACC
>   host_data construct to have an use_device clause.
>
> gcc/fortran/ChangeLog:
>
>   * openmp.cc (resolve_omp_clauses): Add checking requiring
>   OpenACC host_data construct to have an use_device clause.
>
> gcc/testsuite/ChangeLog:
>
>   * c-c++-common/goacc/host_data-2.c: Adjust testcase.
>   * gfortran.dg/goacc/host_data-error.f90: New testcase.
>   * gfortran.dg/goacc/pr71704.f90: Adjust testcase.
> diff --git a/gcc/c/c-parser.cc b/gcc/c/c-parser.cc
> index 24a6eb6e459..80920b31f83 100644
> --- a/gcc/c/c-parser.cc
> +++ b/gcc/c/c-parser.cc
> @@ -18461,8 +18461,13 @@ c_parser_oacc_host_data (location_t loc, c_parser 
> *parser, bool *if_p)
>tree stmt, clauses, block;
>
>clauses = c_parser_oacc_all_clauses (parser, OACC_HOST_DATA_CLAUSE_MASK,
> -"#pragma acc host_data");
> -
> +"#pragma acc host_data", false);
> +  if (!omp_find_clause (clauses, OMP_CLAUSE_USE_DEVICE_PTR))
> +{
> +  error_at (loc, "% construct requires % 
> clause");
> +  return error_mark_node;
> +}
> +  clauses = c_finish_omp_clauses (clauses, C_ORT_ACC);
>block = c_begin_omp_parallel ();
>add_stmt (c_parser_omp_structured_block (parser, if_p));
>stmt = c_finish_oacc_host_data (loc, clauses, block);
> diff --git a/gcc/cp/parser.cc b/gcc/cp/parser.cc
> index 5e2b5cba57e..beb5b632e5e 100644
> --- a/gcc/cp/parser.cc
> +++ b/gcc/cp/parser.cc
> @@ -45895,8 +45895,15 @@ cp_parser_oacc_host_data (cp_parser *parser, 
> cp_token *pragma_tok, bool *if_p)
>unsigned int save;
>
>clauses = cp_parser_oacc_all_clauses (parser, OACC_HOST_DATA_CLAUSE_MASK,
> - "#pragma acc host_data", pragma_tok);
> -
> + "#pragma acc host_data", pragma_tok,
> + false);
> +  if (!omp_find_clause (clauses, OMP_CLAUSE_USE_DEVICE_PTR))
> +{
> +  error_at (pragma_tok->location,
> + "% construct requires % clause");
> +  return error_mark_node;
> +}
> +  clauses = finish_omp_clauses (clauses, C_ORT_ACC);
>block = begin_omp_parallel ();
>save = cp_parser_begin_omp_structured_block (parser);
>cp_parser_statement (parser, NULL_TREE, false, if_p);
> diff --git a/gcc/fortran/openmp.cc b/gcc/fortran/openmp.cc
> index 8efc4b3ecfa..f7af02845de 100644
> --- a/gcc/fortran/openmp.cc
> +++ b/gcc/fortran/openmp.cc
> @@ -8764,6 +8764,12 @@ resolve_omp_clauses (gfc_code *code, gfc_omp_clauses 
> *omp_clauses,
>  "% clause", &omp_clauses->detach->where);
>  }
>
> +  if (openacc
> +  && code->op == EXEC_OACC_HOST_DATA
> +  && omp_clauses->lists[OMP_LIST_USE_DEVICE] == NULL)
> +gfc_error ("% construct at %L requires % 
> clause",
> +&code->loc);
> +
>if (omp_clauses->assume)
>  gfc_resolve_omp_assumptions (omp_clauses->assume);
>  }
> diff --git a/gcc/testsuite/c-c++-common/goacc/host_data-2.c 
> b/gcc/testsuite/c-c++-common/goacc/host_data-2.c
> index b3093e575ff..862a764eb3a 100644
> --- a/gcc/testsuite/c-c++-common/goacc/host_data-2.c
> +++ b/gcc/testsuite/c-c++-common/goacc/host_data-2.c
> @@ -8,7 +8,9 @@ void
>  f (void)
>  {
>int v2 = 3;
> -#pragma acc host_data copy(v2) /* { dg-error ".copy. is not valid for 
> ..pragma acc host_data." } */
> +#pragma acc host_data copy(v2)
> +  /* { dg-error ".copy. is not valid for ..pragma acc host_data." "" { 
> target *-*-* } .-1 } */
> +  /* { dg-error ".host_data. construct requires .use_device. clause" "" { 
> target *-*-* } .-2 } */
>;
>
>  #pragma acc host_data use_device(v2)
> @@ -20,6 +22,9 @@ f (void)
>/* { dg-error ".use_device_ptr. va

Re: [PATCH, OpenACC 2.7] readonly modifier support in front-ends

[Thomas Schwinge]

Hi Chung-Lin, Tobias!

On 2023-07-11T02:33:58+0800, Chung-Lin Tang  wrote:
> this patch contains support for the 'readonly' modifier in copyin clauses
> and the cache directive.

Thanks!

> As we discussed earlier, the work for actually linking this to middle-end
> points-to analysis is a somewhat non-trivial issue. This first patch allows
> the language feature to be used in OpenACC directives first (with no effect 
> for now).
> The middle-end changes are probably going to be a later patch.

ACK.

> (Also CCing Tobias because of the Fortran bits)

A few specific GCC/Fortran questions for Tobias below, and some more
review comments for Chung-Lin:

> --- a/gcc/c/c-parser.cc
> +++ b/gcc/c/c-parser.cc
> @@ -14059,7 +14059,8 @@ c_parser_omp_variable_list (c_parser *parser,
>
>  static tree
>  c_parser_omp_var_list_parens (c_parser *parser, enum omp_clause_code kind,
> -   tree list, bool allow_deref = false)
> +   tree list, bool allow_deref = false,
> +   bool *readonly = NULL)
>  {
>/* The clauses location.  */
>location_t loc = c_parser_peek_token (parser)->location;
> @@ -14067,6 +14068,20 @@ c_parser_omp_var_list_parens (c_parser *parser, enum 
> omp_clause_code kind,
>matching_parens parens;
>if (parens.require_open (parser))
>  {
> +  if (readonly != NULL)
> + {
> +   c_token *token = c_parser_peek_token (parser);
> +   if (token->type == CPP_NAME
> +   && !strcmp (IDENTIFIER_POINTER (token->value), "readonly")
> +   && c_parser_peek_2nd_token (parser)->type == CPP_COLON)
> + {
> +   c_parser_consume_token (parser);
> +   c_parser_consume_token (parser);
> +   *readonly = true;
> + }
> +   else
> + *readonly = false;
> + }
>list = c_parser_omp_variable_list (parser, loc, kind, list, 
> allow_deref);
>parens.skip_until_found_close (parser);
>  }

Instead of doing this in 'c_parser_omp_var_list_parens', I think it's
clearer to have this special 'readonly :' parsing logic in the two places
where it's used.  For example (random), like 'ancestor :' is parsed in
'c_parser_omp_clause_device', or 'conditional :' is parsed in
'c_parser_omp_clause_lastprivate'.  (Yes, this does duplicate a bit of
code, but that's easy enough to follow along.)

The existing 'enum omp_clause_code kind', 'bool allow_deref' actually
affect the parsing process; the new 'bool readonly' only propagates a
flag.

> @@ -14084,7 +14099,11 @@ c_parser_omp_var_list_parens (c_parser *parser, enum 
> omp_clause_code kind,
> OpenACC 2.6:
> no_create ( variable-list )
> attach ( variable-list )
> -   detach ( variable-list ) */
> +   detach ( variable-list )
> +
> +   OpenACC 2.7:
> +   copyin (readonly : variable-list )
> + */
>
>  static tree
>  c_parser_oacc_data_clause (c_parser *parser, pragma_omp_clause c_kind,
> @@ -14135,11 +14154,22 @@ c_parser_oacc_data_clause (c_parser *parser, 
> pragma_omp_clause c_kind,
>  default:
>gcc_unreachable ();
>  }
> +
> +  /* Turn on readonly modifier parsing for copyin clause.  */
> +  bool readonly = false, *readonly_ptr = NULL;
> +  if (c_kind == PRAGMA_OACC_CLAUSE_COPYIN)
> +readonly_ptr = &readonly;
> +
>tree nl, c;
> -  nl = c_parser_omp_var_list_parens (parser, OMP_CLAUSE_MAP, list, true);
> +  nl = c_parser_omp_var_list_parens (parser, OMP_CLAUSE_MAP, list, true,
> +  readonly_ptr);

That is, similar to 'c_parser_omp_clause_device', or
'c_parser_omp_clause_lastprivate', inline 'c_parser_omp_var_list_parens'
here, and only for 'PRAGMA_OACC_CLAUSE_COPYIN' parse 'readonly :', then
(for all) use 'c_parser_omp_variable_list' etc. instead of
'c_parser_omp_var_list_parens', then set 'readonly':

>for (c = nl; c != list; c = OMP_CLAUSE_CHAIN (c))
> -OMP_CLAUSE_SET_MAP_KIND (c, kind);
> +{
> +  OMP_CLAUSE_SET_MAP_KIND (c, kind);
> +  if (readonly)
> + OMP_CLAUSE_MAP_READONLY (c) = 1;
> +}
>
>return nl;

> @@ -18212,6 +18242,9 @@ c_parser_omp_structured_block (c_parser *parser, bool 
> *if_p)
>  /* OpenACC 2.0:
> # pragma acc cache (variable-list) new-line
>
> +   OpenACC 2.7:
> +   # pragma acc cache (readonly: variable-list) new-line
> +
> LOC is the location of the #pragma token.
>  */
>
> @@ -18219,8 +18252,14 @@ static tree
>  c_parser_oacc_cache (location_t loc, c_parser *parser)
>  {
>tree stmt, clauses;
> +  bool readonly;
> +
> +  clauses = c_parser_omp_var_list_parens (parser, OMP_CLAUSE__CACHE_, NULL,
> +   false, &readonly);
> +  if (readonly)
> +for (tree c = clauses; c; c = OMP_CLAUSE_CHAIN (c))
> +  OMP_CLAUSE__CACHE__READONLY (c) = 1;
>
> -  clauses = c_parser_omp_var_list_parens (parser, OMP_CLAUSE__CACHE_, NULL);
>clauses = c_finish_omp_clauses (clauses, C_ORT_ACC);
>
>c_parser_skip_to_pragma_eol (parser);

Similarly.

> --- a/gcc/c

List myself as "nvptx port" maintainer (was: Thomas Schwinge appointed co-maintainer of the nvptx backend)

[Thomas Schwinge]

Hi!

On 2023-07-19T23:41:47+0200, Gerald Pfeifer  wrote:
> It's my pleasure to announce Thomas Schwinge as co-maintainer of the
> nvptx backend.
>
> Congratulations and Happy Hacking, Thomas! Please go ahead and update
> MAINTAINERS accordingly.
>
> Gerald (on behalf of the steering committee)

Thanks!  I've pushed commit 28e3d361ba0cfa7ea2f90706159a144eaf4b650e
'List myself as "nvptx port" maintainer', see attached.


Grüße
 Thomas


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
>From 28e3d361ba0cfa7ea2f90706159a144eaf4b650e Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Tue, 25 Jul 2023 21:17:52 +0200
Subject: [PATCH] List myself as "nvptx port" maintainer

	* MAINTAINERS: List myself as "nvptx port" maintainer.
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index b626d89fe34..e9b11b43a0f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -102,6 +102,7 @@ nds32 port		Shiva Chen		
 nios2 port		Chung-Lin Tang		
 nios2 port		Sandra Loosemore	
 nvptx port		Tom de Vries		
+nvptx port		Thomas Schwinge		
 or1k port		Stafford Horne		
 pdp11 port		Paul Koning		
 powerpcspe port		Andrew Jenner		
-- 
2.34.1

Re: [patch] OpenMP: Call cuMemcpy2D/cuMemcpy3D for nvptx for omp_target_memcpy_rect

[Thomas Schwinge]

mp;dst_off_sz2)
> +   || __builtin_mul_overflow (src_offsets[2], element_size,
> +  &src_off_sz2))
> + return EINVAL;
> +  ret = devp->memcpy3d_func (dst_id, src_id, vol_sz2, volume[1], 
> volume[0],
> +  dst, dst_off_sz2, dst_offsets[1],
> +  dst_offsets[0], dst_sz2, dst_dimensions[1],
> +  src, src_off_sz2, src_offsets[1],
> +  src_offsets[0], src_sz2, src_dimensions[1]);
> +  if (ret != -1)
> + return ret ? 0 : EINVAL;
> +}
>
>for (i = 1; i < num_dims; i++)
>  if (__builtin_mul_overflow (dst_slice, dst_dimensions[i], &dst_slice)
> @@ -4585,7 +4670,7 @@ omp_target_memcpy_rect_worker (void *dst, const void 
> *src, size_t element_size,
>  volume + 1, dst_offsets + 1,
>  src_offsets + 1, dst_dimensions + 1,
>  src_dimensions + 1, dst_devicep,
> -src_devicep);
> +src_devicep, tmp_size, tmp);
>if (ret)
>   return ret;
>dst_off += dst_slice;
> @@ -4608,9 +4693,6 @@ omp_target_memcpy_rect_check (void *dst, const void 
> *src, int dst_device_num,
>if (ret)
>  return ret;
>
> -  if (*src_devicep != NULL && *dst_devicep != NULL && *src_devicep != 
> *dst_devicep)
> -return EINVAL;
> -
>return 0;
>  }
>
> @@ -4624,18 +4706,36 @@ omp_target_memcpy_rect_copy (void *dst, const void 
> *src,
>struct gomp_device_descr *dst_devicep,
>struct gomp_device_descr *src_devicep)
>  {
> -  if (src_devicep)
> +  size_t tmp_size = 0;
> +  void *tmp = NULL;
> +  bool lock_src;
> +  bool lock_dst;
> +
> +  lock_src = (src_devicep
> +   && (!dst_devicep
> +   || src_devicep == dst_devicep
> +   || !(src_devicep->capabilities
> +& GOMP_OFFLOAD_CAP_SHARED_MEM)));

Similar doubt than above re "'GOMP_OFFLOAD_CAP_SHARED_MEM' actually
reachable"?

> +  lock_dst = (dst_devicep
> +   && (!lock_src
> +   || (src_devicep != dst_devicep
> +   && !(dst_devicep->capabilities
> +& GOMP_OFFLOAD_CAP_SHARED_MEM;
> +  if (lock_src)
>  gomp_mutex_lock (&src_devicep->lock);
> -  else if (dst_devicep)
> +  if (lock_dst)
>  gomp_mutex_lock (&dst_devicep->lock);

(Pre-existing issue, and I've not myself tried to figure out the details
at this time -- why do we actually lock the devices here, and in similar
other places?)

>int ret = omp_target_memcpy_rect_worker (dst, src, element_size, num_dims,
>  volume, dst_offsets, src_offsets,
>  dst_dimensions, src_dimensions,
> -dst_devicep, src_devicep);
> -  if (src_devicep)
> +dst_devicep, src_devicep,
> +&tmp_size, &tmp);
> +  if (lock_src)
>  gomp_mutex_unlock (&src_devicep->lock);
> -  else if (dst_devicep)
> +  if (lock_dst)
>  gomp_mutex_unlock (&dst_devicep->lock);
> +  if (tmp)
> +free (tmp);
>
>return ret;
>  }
> @@ -4976,6 +5076,8 @@ gomp_load_plugin_for_device (struct gomp_device_descr 
> *device,
>DLSYM (free);
>DLSYM (dev2host);
>DLSYM (host2dev);
> +  DLSYM (memcpy2d);
> +  DLSYM (memcpy3d);

With 'DLSYM' used here, won't that fail if these symbols don't actually
exist (like for 'libgomp/plugin/plugin-gcn.c')?


I'm attaching the humble beginnings of a follow-on patch; feel free to
use.


Grüße
 Thomas


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
>From ed85b983970fb42be2e1db172a0d7e20c484ed06 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Thu, 27 Jul 2023 15:46:26 +0200
Subject: [PATCH] Re: OpenMP: Call cuMemcpy2D/cuMemcpy3D for nvptx for
 omp_target_memcpy_rect

---
 include/cuda/cuda.h | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/include/cuda/cuda.h b/include/cuda/cuda.h
index 09c3c2b8dbe..d556a130379 100644
--- a/include/cuda/cuda.h
+++ b/include/cuda/cuda.h
@@ -147,7 +147,7 @@ typedef struct {
 
   size_t dstXInBytes, dstY;
   CUmemorytype dstMemoryType;
-  const void *dstHost;
+  void *dstHost;
   CUdeviceptr dstDevice;
   CUarray dstArray;
   size_t dstPitch;
@@ -162,16 +162,16 @@ typedef struct {
   const void *srcHost;
   CUdeviceptr srcDevice;
   CUarray srcArray;
-  void *dummy;
+  void *reserved0;
   size_t srcPitch, srcHeight;
 
   size_t dstXInBytes, dstY, dstZ;
   size_t dstLOD;
   CUmemorytype dstMemoryType;
-  const void *dstHost;
+  void *dstHost;
   CUdeviceptr dstDevice;
   CUarray dstArray;
-  void *dummy2;
+  void *reserved1;
   size_t dstPitch, dstHeight;
 
   size_t WidthInBytes, Height, Depth;
-- 
2.34.1

[PING^2] nvptx: forward '-v' command-line option to assembler, linker

[Thomas Schwinge]

Hi Tom!

Ping.


Grüße
 Thomas


On 2022-06-07T17:41:16+0200, I wrote:
> Hi!
>
> On 2022-05-30T09:06:21+0200, Tobias Burnus  wrote:
>> On 29.05.22 22:49, Thomas Schwinge wrote:
>>> Not sure if that's what you had in mind, but what do you think about the
>>> attached "nvptx: forward '-v' command-line option to assembler, linker"?
>>> OK to push to GCC master branch (after merging
>>> <https://github.com/MentorEmbedded/nvptx-tools/pull/37>
>>> "Put '-v' verbose output onto stderr instead of stdout")?
>>
>> I was mainly thinking of some way to have it available — which
>> '-foffload-options=-Wa,-v' already permits on the GCC side. (Once the
>> nvptx-tools patch actually makes use of the '-v'.)
>
> (Merged a week ago.)
>
>> If I understand your patch correctly, this patch now causes 'gcc -v' to
>> imply 'gcc -v -Wa,-v'. I think that's okay, since 'gcc -v' already
>> outputs a lot of lines and those lines can be helpful to understand what
>> happens and what not.
>
> ACK.
>
>> Tom, your thoughts on this?
>
> Ping.
>
>
> Grüße
>  Thomas


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
>From 17c35607d4927299b0c4bd19dd6fd205c85c4a4b Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Sun, 29 May 2022 22:31:43 +0200
Subject: [PATCH] nvptx: forward '-v' command-line option to assembler, linker

For example, for offloading compilation with '-save-temps -v', before vs. after
word-diff then looks like:

[...]
 [...]/build-gcc-offload-nvptx-none/gcc/as {+-v -v+} -o ./a.xnvptx-none.mkoffload.o ./a.xnvptx-none.mkoffload.s
{+Verifying sm_30 code with sm_35 code generation.+}
{+ ptxas -c -o /dev/null ./a.xnvptx-none.mkoffload.o --gpu-name sm_35 -O0+}
[...]
 [...]/build-gcc-offload-nvptx-none/gcc/collect2 {+-v -v+} -o ./a.xnvptx-none.mkoffload [...] @./a.xnvptx-none.mkoffload.args.1 -lgomp -lgcc -lc -lgcc
{+collect2 version 12.0.1 20220428 (experimental)+}
{+[...]/build-gcc-offload-nvptx-none/gcc/collect-ld -v -v -o ./a.xnvptx-none.mkoffload [...] ./a.xnvptx-none.mkoffload.o -lgomp -lgcc -lc -lgcc+}
{+Linking ./a.xnvptx-none.mkoffload.o as 0+}
{+trying lib libc.a+}
{+trying lib libgcc.a+}
{+trying lib libgomp.a+}
{+Resolving abort+}
{+Resolving acc_on_device+}
{+Linking libgomp.a::oacc-init.o/ as 1+}
{+Linking libc.a::lib_a-abort.o/   as 2+}
[...]

(This depends on <https://github.com/MentorEmbedded/nvptx-tools/pull/37>
"Put '-v' verbose output onto stderr instead of stdout".)

	gcc/
	* config/nvptx/nvptx.h (ASM_SPEC, LINK_SPEC): Define.
---
 gcc/config/nvptx/nvptx.h | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/gcc/config/nvptx/nvptx.h b/gcc/config/nvptx/nvptx.h
index ed72c253191..b184f1d0150 100644
--- a/gcc/config/nvptx/nvptx.h
+++ b/gcc/config/nvptx/nvptx.h
@@ -27,6 +27,13 @@
 
 /* Run-time Target.  */
 
+/* Assembler supports '-v' option; handle similar to
+   '../../gcc.cc:asm_options', 'HAVE_GNU_AS'.  */
+#define ASM_SPEC "%{v}"
+
+/* Linker supports '-v' option.  */
+#define LINK_SPEC "%{v}"
+
 #define STARTFILE_SPEC "%{mmainkernel:crt0.o}"
 
 #define TARGET_CPU_CPP_BUILTINS() nvptx_cpu_cpp_builtins ()
-- 
2.25.1

[PING] nvptx: Allow '--with-arch' to override the default '-misa' (was: nvptx multilib setup)

[Thomas Schwinge]

Hi Tom!

Ping.


Grüße
 Thomas


On 2022-06-15T23:18:10+0200, I wrote:
> Hi Tom!
>
> On 2022-05-13T16:20:14+0200, I wrote:
>> On 2022-02-04T13:09:29+0100, Tom de Vries via Gcc  wrote:
>>> On 2/4/22 08:21, Thomas Schwinge wrote:
>>>> On 2022-02-03T13:35:55+, "vries at gcc dot gnu.org via Gcc-bugs" 
>>>>  wrote:
>>>>> I've tested this using (recommended) driver 470.94 on boards:
>>
>>>>> while iterating over dimensions { -mptx=3.1 , -mptx=6.3 } x { 
>>>>> GOMP_NVPTX_JIT=-O0,  }.
>>>>
>>>> Do you use separate (nvptx-none offload target only?) builds for
>>>> different '-mptx' variants (likewise: '-misa'), or have you hacked up the
>>>> multilib configuration?
>>>
>>> Neither, I'm using --target_board=unix/foffload= for that.
>>
>> ACK, I see.  So these flags then only affect GCC/nvptx code generation
>> for the actual user code (here: GCC libgomp test cases), but for the
>> GCC/nvptx target libraries (such as: libc, libm, libgfortran, libgomp --
>> the latter especially relevant for OpenMP), it uses PTX code from one of
>> the two "pre-compiled" GCC/nvptx multilibs: default or '-mptx=3.1'.
>>
>> Meaning, one can't just use such a flag for "completely building code"
>> for a specific configuration.  Random example,
>> '-foffload-options=nvptx-none=-march=sm_75': as GCC/nvptx target
>> libraries aren't being built for '-march=sm_75' multilib,
>> '-foffload-options=nvptx-none=-march=sm_75' uses the default multilib,
>> which isn't '-march=sm_75'.
>>
>>
>>>   ('gcc/config/nvptx/t-nvptx:MULTILIB_OPTIONS'
>>>> etc., I suppose?)  Should we add a few representative configurations to
>>>> be built by default?  And/or, should we have a way to 'configure' per
>>>> user needs (I suppose: '--with-multilib-list=[...]', as supported for a
>>>> few other targets?)?  (I see there's also a new
>>>> '--with-multilib-generator=[...]', haven't looked in detail.)  No matter
>>>> which way: again, combinatorial explosion is a problem, of course...
>>>
>>> As far as I know, the gcc build doesn't finish when switching default to
>>> higher than sm_35, so there's little point to go to a multilib setup at
>>> this point.  But once we fix that, we could reconsider, otherwise,
>>> things are likely to regress again.
>>
>> As far as I remember, several issues have been fixed.  Still waiting for
>> Roger's "middle-end: Support ABIs that pass FP values as wider integers"
>> or something similar, but that PR104489 issue is being worked around by
>> "Limit HFmode support to mexperimental", if I got that right.
>>
>> Now I'm not suggesting we should now enable all or any random GCC/nvptx
>> multilibs, to get all these variants of GCC/nvptx target libraries built;
>> especially also given that GCC/nvptx code generation currently doesn't
>> make too much use of the new capabilities.
>>
>> However, we do have a specific request that a customer would like to be
>> able to change at GCC 'configure' time the GCC/nvptx default multilib
>> (including that being used for building corresponding GCC/nvptx target
>> libraries).
>>
>> Per 'gcc/doc/install.texi', I do see that some GCC targets allow for
>> GCC 'configure'-time '--with-multilib-list=[...]', or
>> '--with-multilib-generator=[...]', and I suppose we could be doing
>> something similar?  But before starting implementing, I'd like your
>> input, as you'll be the one to approve in the end.  And/or, maybe you've
>> already made up your own ideas about that?
>
> So, instead of "random GCC/nvptx multilib configuration" (last
> paragraph), I've come up with a way to implement our customer's request
> (second last paragraph): 'configure' GCC/nvptx '--with-arch=sm_70'.
>
> I think I've implemented this in a way so that "random GCC/nvptx multilib
> configuration" may eventually be implemented on top of that.  For easy
> review/testing I've split my changes into three commits, see attached
> "nvptx: Make default '-misa=sm_30' explicit",
> "nvptx: Introduce dummy multilib option for default '-misa=sm_30'",
> "nvptx: Allow '--with-arch' to override the default '-mis

Define 'OMP_REQUIRES_[...]', 'GOMP_REQUIRES_[...]' in a single place (was: [Patch] OpenMP: Move omp requires checks to libgomp)

[Thomas Schwinge]

Hi!

On 2022-06-08T05:56:02+0200, Tobias Burnus  wrote:
> This is based on Chung-Lin's patch at 
> https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563393.html

> --- a/include/gomp-constants.h
> +++ b/include/gomp-constants.h

> +/* Flag values for requires-directive features, must match corresponding
> +   OMP_REQUIRES_* values in gcc/omp-general.h.  */
> +#define GOMP_REQUIRES_UNIFIED_ADDRESS   0x10
> +#define GOMP_REQUIRES_UNIFIED_SHARED_MEMORY 0x20
> +#define GOMP_REQUIRES_REVERSE_OFFLOAD   0x80

To make things more failure proof, OK to push the attached
"Define 'OMP_REQUIRES_[...]', 'GOMP_REQUIRES_[...]' in a single place"?


Grüße
 Thomas


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
>From bd1aa5bc96e141a85bb53d61a5c7531e09ea3cf6 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Tue, 5 Jul 2022 11:04:46 +0200
Subject: [PATCH] Define 'OMP_REQUIRES_[...]', 'GOMP_REQUIRES_[...]' in a
 single place

Clean up for recent commit 683f11843974f0bdf42f79cdcbb0c2b43c7b81b0
"OpenMP: Move omp requires checks to libgomp".

	gcc/
	* omp-general.h (enum omp_requires): Use 'GOMP_REQUIRES_[...]'.
	include/
	* gomp-constants.h (OMP_REQUIRES_[...]): Update comment.
---
 gcc/omp-general.h| 8 
 include/gomp-constants.h | 3 +--
 2 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/gcc/omp-general.h b/gcc/omp-general.h
index 7a94831e8f5..74e90e1a71a 100644
--- a/gcc/omp-general.h
+++ b/gcc/omp-general.h
@@ -126,12 +126,12 @@ extern int oacc_get_ifn_dim_arg (const gimple *stmt);
 
 enum omp_requires {
   OMP_REQUIRES_ATOMIC_DEFAULT_MEM_ORDER = 0xf,
-  OMP_REQUIRES_UNIFIED_ADDRESS = 0x10,
-  OMP_REQUIRES_UNIFIED_SHARED_MEMORY = 0x20,
+  OMP_REQUIRES_UNIFIED_ADDRESS = GOMP_REQUIRES_UNIFIED_ADDRESS,
+  OMP_REQUIRES_UNIFIED_SHARED_MEMORY = GOMP_REQUIRES_UNIFIED_SHARED_MEMORY,
   OMP_REQUIRES_DYNAMIC_ALLOCATORS = 0x40,
-  OMP_REQUIRES_REVERSE_OFFLOAD = 0x80,
+  OMP_REQUIRES_REVERSE_OFFLOAD = GOMP_REQUIRES_REVERSE_OFFLOAD,
   OMP_REQUIRES_ATOMIC_DEFAULT_MEM_ORDER_USED = 0x100,
-  OMP_REQUIRES_TARGET_USED = 0x200
+  OMP_REQUIRES_TARGET_USED = GOMP_REQUIRES_TARGET_USED,
 };
 
 extern GTY(()) enum omp_requires omp_requires_mask;
diff --git a/include/gomp-constants.h b/include/gomp-constants.h
index 3e3078f082e..84316f953d0 100644
--- a/include/gomp-constants.h
+++ b/include/gomp-constants.h
@@ -341,8 +341,7 @@ enum gomp_map_kind
 #define GOMP_DEPEND_MUTEXINOUTSET	4
 #define GOMP_DEPEND_INOUTSET		5
 
-/* Flag values for requires-directive features, must match corresponding
-   OMP_REQUIRES_* values in gcc/omp-general.h.  */
+/* Flag values for OpenMP 'requires' directive features.  */
 #define GOMP_REQUIRES_UNIFIED_ADDRESS   0x10
 #define GOMP_REQUIRES_UNIFIED_SHARED_MEMORY 0x20
 #define GOMP_REQUIRES_REVERSE_OFFLOAD   0x80
-- 
2.35.1

Restore 'GOMP_offload_unregister_ver' functionality (was: [Patch][v5] OpenMP: Move omp requires checks to libgomp)

[Thomas Schwinge]

Hi!

On 2022-07-01T15:06:05+0200, Tobias Burnus  wrote:
> Attached is the updated patch. Main changes: [...]

This is now a great implementation of cross-component communication
(host/offloading compilers, runtime), thanks!  I'm sure this will be
usable (or at least instructing) for further purposes, too.

> - Uses GOMP_register_var to pass the mask to libgomp

Like 'GOMP_offload_register_ver', also 'GOMP_offload_unregister_ver'
needs to be adjusted correspondingly.  OK to push the attached
"Restore 'GOMP_offload_unregister_ver' functionality"?  (Currently
testing.)

> (and no longer a weak variable)

... which actually removed my "contribution" (hack!) to this patch.  ;-)


Grüße
 Thomas


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
>From 9a49a3e1e4d3def7b48beccdde6fa9f218719244 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Tue, 5 Jul 2022 18:23:15 +0200
Subject: [PATCH] Restore 'GOMP_offload_unregister_ver' functionality

The recent commit 683f11843974f0bdf42f79cdcbb0c2b43c7b81b0
"OpenMP: Move omp requires checks to libgomp" changed the
'GOMP_offload_register_ver' interface but didn't change
'GOMP_offload_unregister_ver' accordingly, so we're no longer
actually unregistering.

	gcc/
	* config/gcn/mkoffload.cc (process_obj): Clarify 'target_data' ->
	'[...]_data'.
	* config/nvptx/mkoffload.cc (process): Likewise.
	libgomp/
	* target.c (GOMP_offload_register_ver): Clarify 'target_data' ->
	'data'.
	(GOMP_offload_unregister_ver): Likewise.  Fix up 'target_data',
	and add 'assert'.
---
 gcc/config/gcn/mkoffload.cc   |  8 
 gcc/config/nvptx/mkoffload.cc |  8 
 libgomp/target.c  | 33 ++---
 3 files changed, 34 insertions(+), 15 deletions(-)

diff --git a/gcc/config/gcn/mkoffload.cc b/gcc/config/gcn/mkoffload.cc
index b8b3fecfcb4..d2464332275 100644
--- a/gcc/config/gcn/mkoffload.cc
+++ b/gcc/config/gcn/mkoffload.cc
@@ -692,13 +692,13 @@ process_obj (FILE *in, FILE *cfile, uint32_t omp_requires)
 	   len);
 
   fprintf (cfile,
-	   "static const struct gcn_image_desc {\n"
+	   "static const struct gcn_data {\n"
 	   "  uintptr_t omp_requires_mask;\n"
 	   "  const struct gcn_image *gcn_image;\n"
 	   "  unsigned kernel_count;\n"
 	   "  const struct hsa_kernel_description *kernel_infos;\n"
 	   "  unsigned global_variable_count;\n"
-	   "} target_data = {\n"
+	   "} gcn_data = {\n"
 	   "  %d,\n"
 	   "  &gcn_image,\n"
 	   "  sizeof (gcn_kernels) / sizeof (gcn_kernels[0]),\n"
@@ -723,7 +723,7 @@ process_obj (FILE *in, FILE *cfile, uint32_t omp_requires)
   fprintf (cfile, "static __attribute__((constructor)) void init (void)\n"
 	   "{\n"
 	   "  GOMP_offload_register_ver (%#x, __OFFLOAD_TABLE__,"
-	   " %d/*GCN*/, &target_data);\n"
+	   " %d/*GCN*/, &gcn_data);\n"
 	   "};\n",
 	   GOMP_VERSION_PACK (GOMP_VERSION, GOMP_VERSION_GCN),
 	   GOMP_DEVICE_GCN);
@@ -731,7 +731,7 @@ process_obj (FILE *in, FILE *cfile, uint32_t omp_requires)
   fprintf (cfile, "static __attribute__((destructor)) void fini (void)\n"
 	   "{\n"
 	   "  GOMP_offload_unregister_ver (%#x, __OFFLOAD_TABLE__,"
-	   " %d/*GCN*/, &target_data);\n"
+	   " %d/*GCN*/, &gcn_data);\n"
 	   "};\n",
 	   GOMP_VERSION_PACK (GOMP_VERSION, GOMP_VERSION_GCN),
 	   GOMP_DEVICE_GCN);
diff --git a/gcc/config/nvptx/mkoffload.cc b/gcc/config/nvptx/mkoffload.cc
index d8c81eb0547..0fa5f4423bf 100644
--- a/gcc/config/nvptx/mkoffload.cc
+++ b/gcc/config/nvptx/mkoffload.cc
@@ -310,7 +310,7 @@ process (FILE *in, FILE *out, uint32_t omp_requires)
   fprintf (out, "\n};\n\n");
 
   fprintf (out,
-	   "static const struct nvptx_tdata {\n"
+	   "static const struct nvptx_data {\n"
 	   "  uintptr_t omp_requires_mask;\n"
 	   "  const struct ptx_obj *ptx_objs;\n"
 	   "  unsigned ptx_num;\n"
@@ -318,7 +318,7 @@ process (FILE *in, FILE *out, uint32_t omp_requires)
 	   "  unsigned var_num;\n"
 	   "  const struct nvptx_fn *fn_names;\n"
 	   "  unsigned fn_num;\n"
-	   "} target_data = {\n"
+	   "} nvptx_data = {\n"
 	   "  %d, ptx_objs, sizeof (ptx_objs) / sizeof (ptx_objs[0]),\n"
 	   "  var_mappings,"
 	   "  sizeof (var_mappings) / sizeof (var_mappings[0]),\n"
@@ -344,7 +344,7 @@ process (FILE *in, FILE *out, uint3

Fix Intel MIC 'mkoffload' for OpenMP 'requires' (was: [Patch] OpenMP: Move omp requires checks to libgomp)

[Thomas Schwinge]

Hi!

On 2022-06-08T05:56:02+0200, Tobias Burnus  wrote:
> This is based on Chung-Lin's patch at 
> https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563393.html

> PS: I have not fully tested the intelmic version.

As part of my standard testing, I'm reporting that it got completely
broken.  ;'-) Your commit 683f11843974f0bdf42f79cdcbb0c2b43c7b81b0
"OpenMP: Move omp requires checks to libgomp" states:
"When the device lto1 runs, it extracts the data for mkoffload. The
latter than passes the value on to GOMP_offload_register_ver."
That's not implemented for Intel MIC 'mkoffload', so we always run into
'gcc/lto-cgraph.cc:input_offload_tables':

+#ifdef ACCEL_COMPILER
+  char *omp_requires_file = getenv ("GCC_OFFLOAD_OMP_REQUIRES_FILE");
+  if (omp_requires_file == NULL || omp_requires_file[0] == '\0')
+fatal_error (input_location, "GCC_OFFLOAD_OMP_REQUIRES_FILE unset");

..., and all offloading compilation fail with that 'fatal_error'.  OK to
push the attached "Fix Intel MIC 'mkoffload' for OpenMP 'requires'"?
(Currently testing.)


Grüße
 Thomas


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
>From afd77646d7ced9f58fb49667e37ee4e21dd6fc53 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Tue, 5 Jul 2022 12:21:33 +0200
Subject: [PATCH] Fix Intel MIC 'mkoffload' for OpenMP 'requires'

Similar to how the other 'mkoffload's got changed in
recent commit 683f11843974f0bdf42f79cdcbb0c2b43c7b81b0
"OpenMP: Move omp requires checks to libgomp".

This also means finally switching Intel MIC 'mkoffload' to
'GOMP_offload_register_ver', 'GOMP_offload_unregister_ver',
making 'GOMP_offload_register', 'GOMP_offload_unregister'
legacy entry points.

	gcc/
	* config/i386/intelmic-mkoffload.cc (generate_host_descr_file)
	(prepare_target_image, main): Handle OpenMP 'requires'.
	(generate_host_descr_file): Switch to 'GOMP_offload_register_ver',
	'GOMP_offload_unregister_ver'.
	libgomp/
	* target.c (GOMP_offload_register, GOMP_offload_unregister):
	Denote as legacy entry points.
	* testsuite/libgomp.c-c++-common/requires-1.c: Enable for all
	'target offloading_enabled'.
	* testsuite/libgomp.c-c++-common/requires-5.c: Likewise.
	* testsuite/libgomp.c-c++-common/requires-7.c: Likewise.
	* testsuite/libgomp.fortran/requires-1.f90: Likewise.
---
 gcc/config/i386/intelmic-mkoffload.cc | 56 +++
 libgomp/target.c  |  4 ++
 .../libgomp.c-c++-common/requires-1.c |  2 +-
 .../libgomp.c-c++-common/requires-5.c |  2 +-
 .../libgomp.c-c++-common/requires-7.c |  2 +-
 .../testsuite/libgomp.fortran/requires-1.f90  |  2 +-
 6 files changed, 52 insertions(+), 16 deletions(-)

diff --git a/gcc/config/i386/intelmic-mkoffload.cc b/gcc/config/i386/intelmic-mkoffload.cc
index c683d6f473e..596f6f107b8 100644
--- a/gcc/config/i386/intelmic-mkoffload.cc
+++ b/gcc/config/i386/intelmic-mkoffload.cc
@@ -370,7 +370,7 @@ generate_target_offloadend_file (const char *target_compiler)
 
 /* Generates object file with the host side descriptor.  */
 static const char *
-generate_host_descr_file (const char *host_compiler)
+generate_host_descr_file (const char *host_compiler, uint32_t omp_requires)
 {
   char *dump_filename = concat (dumppfx, "_host_descr.c", NULL);
   const char *src_filename = save_temps
@@ -386,39 +386,50 @@ generate_host_descr_file (const char *host_compiler)
   if (!src_file)
 fatal_error (input_location, "cannot open '%s'", src_filename);
 
+  fprintf (src_file, "#include \n\n");
+
   fprintf (src_file,
 	   "extern const void *const __OFFLOAD_TABLE__;\n"
 	   "extern const void *const __offload_image_intelmic_start;\n"
 	   "extern const void *const __offload_image_intelmic_end;\n\n"
 
-	   "static const void *const __offload_target_data[] = {\n"
+	   "static const struct intelmic_data {\n"
+	   "  uintptr_t omp_requires_mask;\n"
+	   "  const void *const image_start;\n"
+	   "  const void *const image_end;\n"
+	   "} intelmic_data = {\n"
+	   "  %d,\n"
 	   "  &__offload_image_intelmic_start, &__offload_image_intelmic_end\n"
-	   "};\n\n");
+	   "};\n\n", omp_requires);
 
   fprintf (src_file,
 	   "#ifdef __cplusplus\n"
 	   "extern \"C\"\n"
 	   "#endif\n"
-	   "void GOMP_offload_register (const void *, int, const void *);\n"
+

Re: Fix Intel MIC 'mkoffload' for OpenMP 'requires' (was: [Patch] OpenMP: Move omp requires checks to libgomp)

[Thomas Schwinge]

Hi Tobias!

On 2022-07-06T13:29:14+0200, Tobias Burnus  wrote:
> On 06.07.22 13:04, Thomas Schwinge wrote:
>> On 2022-06-08T05:56:02+0200, Tobias Burnus  wrote:
>>> PS: I have not fully tested the intelmic version.
>> As part of my standard testing, I'm reporting that it got completely
>> broken.  ;'-)
>
> Interesting. Because intelmic-mkoffload.cc calls GOMP_offload_register
> and not GOMP_offload_register_ver - and that call path should be unchanged.

True indeed for that code path...

> However, I missed that I had an assert that GCC_OFFLOAD_OMP_REQUIRES_FILE is
> set.

..., but not for that one.

> Thus, an alternative is to change that into an 'if'.
> But I concur that updating intelmic-mkoffload.cc is nicer! Thanks!

ACK.


> Regarding:
>> -! { dg-do link { target { offload_target_nvptx || offload_target_amdgcn } } 
>> }
>> +! { dg-do link { target offloading_enabled } }
> This patch looks wrong. We are not interested whether there is an offloading 
> device
> available or not - but whether the offloading compiler is running.
>
> Those are completely independent. Obviously, offloading can be configured but 
> not
> being present. (That's the usual case for testing distro builds but also can
> occur elsewhere.)
> And also the reverse if possible - usually because of -foffload=... but when 
> GCC is
> configured with --enable-offload-defaulted, also other combinations are 
> possible.
>
>
> I think the proper check would be write and use an 'offload_target_any',
> i.e. OFFLOAD_TARGET_NAMES= being present and nonempty.
>
> Cf. check_effective_target_offload_target_nvptx / ..._amdgcn and
> libgomp_check_effective_target_offload_target
> in libgomp/testsuite/lib/libgomp.exp
>
> Possible patch (untested):
>
> # Return 1 if compiling for some offload target(s)
> proc check_effective_target_offload_target_any { } {
>  return [libgomp_check_effective_target_offload_target ""]
> }
>
> At least if I understand the following correctly, "" should work:
>  return [string match "*:$target_name*:*" ":$gcc_offload_targets:"]

:-) Haha, that's actually *exactly* what I had implemented first!  But
then I realized that 'target offloading_enabled' is doing exactly that:
check that offloading compilation is configured -- not that "there is an
offloading device available or not" as you seem to understand?  Or am I
confused there?

I do however agree that (generally) replacing 'target offloading_enabled'
with a new 'target offload_target_any' would seem appropriate (as a
separate patch), because that would also do the right thing when running
libgomp testing with non-default '-foffload=[...]', including
'-foffload=disable'.

For checking "offloading device available" we'd use
'check_effective_target_offload_device[...]'.


Grüße
 Thomas


> Thanks for taking care of the patch fallout!
>
> Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955

Re: Restore 'GOMP_offload_unregister_ver' functionality (was: [Patch][v5] OpenMP: Move omp requires checks to libgomp)

[Thomas Schwinge]

Hi Tobias!

On 2022-07-06T15:59:59+0200, Tobias Burnus  wrote:
> On 06.07.22 12:42, Thomas Schwinge wrote:
>> --- a/libgomp/target.c
>> +++ b/libgomp/target.c

>>   /* This function should be called from every offload image while unloading.

>>   GOMP_offload_unregister_ver (unsigned version, const void *host_table,

>> /* Remove image from array of pending images.  */
>> +  bool found = false;
>> for (i = 0; i < num_offload_images; i++)
>>   if (offload_images[i].target_data == target_data)
>> {
>>  offload_images[i] = offload_images[--num_offload_images];
>> +found = true;
>>  break;
>> }
>> +  assert (found);
>>
>> gomp_mutex_unlock (®ister_lock);
>>   }
>
> ... I don't like that libgomp crashes without any helpful message in that 
> case.
>
> In my opinion:
> * Either we assume that it is unlikely to occur - ignore it.
>(Matches the current implementation: do nothing.)
> * Or we want to have some diagnostic in case it occurs. But in that case,
>it should be some explicit diagnostic printed by gomp_error or gomp_fatal.
>IMHO, gomp_error is better than gomp_fatal as libgomp then continues 
> cleaning
>up after this error, which IMHO makes more sense that just aborting.

I'd be fine to change this into a 'gomp_error', but I don't think it's
necessary.  Maybe that wasn't obvious (and I should add a source code
comment), but my point here is that this situation really should never
arise (hence, if it does: internal error, thus 'assert').  Or, in other
words, such a check should've been present in the original implementation
already -- and would then have flagged your patch as being incomplete in
that function.

Thinking about it again, shouldn't we also add a corresponding
sanity-check ('assert') to 'GOMP_offload_register_ver', such that the
newly registered offload image must not already be present in
'offload_images'?  (Isn't that understanding also supported by the
'break' in 'if (offload_images[i].target_data == target_data)' in
'GOMP_offload_unregister_ver', as cited above: that no duplicates are
expected?)

That's at least my understanding of the situation; happy to hear if I'm
wrong.  (It's a pity that we're totally devoid of test cases for dynamic
registration/unregistration of offload images...)

Anyway: it's totally fine to address (or not, if so desired) this
sanity-check aspect independently of the other changes, so I've backed
that out, and then pushed to master branch
commit 3f05e03d6cfdf723ca0556318b6a9aa37be438e7
"Restore 'GOMP_offload_unregister_ver' functionality", see attached.


Grüße
 Thomas


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
>From 3f05e03d6cfdf723ca0556318b6a9aa37be438e7 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Tue, 5 Jul 2022 18:23:15 +0200
Subject: [PATCH] Restore 'GOMP_offload_unregister_ver' functionality

The recent commit 683f11843974f0bdf42f79cdcbb0c2b43c7b81b0
"OpenMP: Move omp requires checks to libgomp" changed the
'GOMP_offload_register_ver' interface but didn't change
'GOMP_offload_unregister_ver' accordingly, so we're no longer
actually unregistering.

	gcc/
	* config/gcn/mkoffload.cc (process_obj): Clarify 'target_data' ->
	'[...]_data'.
	* config/nvptx/mkoffload.cc (process): Likewise.
	libgomp/
	* target.c (GOMP_offload_register_ver): Clarify 'target_data' ->
	'data'.
	(GOMP_offload_unregister_ver): Likewise.  Fix up 'target_data'.
---
 gcc/config/gcn/mkoffload.cc   |  8 
 gcc/config/nvptx/mkoffload.cc |  8 
 libgomp/target.c  | 30 +++---
 3 files changed, 31 insertions(+), 15 deletions(-)

diff --git a/gcc/config/gcn/mkoffload.cc b/gcc/config/gcn/mkoffload.cc
index b8b3fecfcb4..d2464332275 100644
--- a/gcc/config/gcn/mkoffload.cc
+++ b/gcc/config/gcn/mkoffload.cc
@@ -692,13 +692,13 @@ process_obj (FILE *in, FILE *cfile, uint32_t omp_requires)
 	   len);
 
   fprintf (cfile,
-	   "static const struct gcn_image_desc {\n"
+	   "static const struct gcn_data {\n"
 	   "  uintptr_t omp_requires_mask;\n"
 	   "  const struct gcn_image *gcn_image;\n"
 	   "  unsigned kernel_count;\n"
 	   "  const struct hsa_kernel_description *kernel_infos;\n"
 	   "  unsigned global_variable_count;\n"
-	   "} target_data = {\n"
+	   "} gc

Adjust 'libgomp.c-c++-common/requires-3.c' (was: [Patch][v4] OpenMP: Move omp requires checks to libgomp)

[Thomas Schwinge]

Hi!

In preparation for other changes:

On 2022-06-29T16:33:02+0200, Tobias Burnus  wrote:
> --- /dev/null
> +++ b/libgomp/testsuite/libgomp.c-c++-common/requires-3-aux.c
> @@ -0,0 +1,11 @@
> +/* { dg-skip-if "" { *-*-* } } */
> +
> +#pragma omp requires unified_address
> +
> +int x;
> +
> +void foo (void)
> +{
> +  #pragma omp target
> +  x = 1;
> +}

> --- /dev/null
> +++ b/libgomp/testsuite/libgomp.c-c++-common/requires-3.c
> @@ -0,0 +1,24 @@
> +/* { dg-do link { target offloading_enabled } } */

Not expected to see 'offloading_enabled' here...

> +/* { dg-additional-sources requires-3-aux.c } */
> +
> +/* Check diagnostic by device-compiler's lto1.

..., because of this note ^.

> +   Other file uses: 'requires unified_address'.  */
> +
> +#pragma omp requires unified_address,unified_shared_memory
> +
> +int a[10];
> +extern void foo (void);
> +
> +int
> +main (void)
> +{
> +  #pragma omp target
> +  for (int i = 0; i < 10; i++)
> +a[i] = 0;
> +
> +  foo ();
> +  return 0;
> +}
> +
> +/* { dg-error "OpenMP 'requires' directive with non-identical clauses in 
> multiple compilation units: 'unified_address, unified_shared_memory' vs. 
> 'unified_address'" "" { target *-*-* } 0 }  */
> +/* { dg-excess-errors "Ignore messages like: errors during merging of 
> translation units|mkoffload returned 1 exit status" } */

OK to push the attached "Adjust 'libgomp.c-c++-common/requires-3.c'"?


Grüße
 Thomas


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
>From 6a4031b351680bdbfe3cdb9ac4e4a3aa59e4ca84 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Thu, 7 Jul 2022 09:59:45 +0200
Subject: [PATCH] Adjust 'libgomp.c-c++-common/requires-3.c'

As documented, this one does "Check diagnostic by device-compiler's lto1".
Indeed there are none when compiling with '-foffload=disable' with an
offloading-enabled compiler, so we should use 'offload_target_[...]', as
used in other similar test cases.

Follow-up to recent commit 683f11843974f0bdf42f79cdcbb0c2b43c7b81b0
"OpenMP: Move omp requires checks to libgomp".

	libgomp/
	* testsuite/libgomp.c-c++-common/requires-3.c: Adjust.
---
 libgomp/testsuite/libgomp.c-c++-common/requires-3.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libgomp/testsuite/libgomp.c-c++-common/requires-3.c b/libgomp/testsuite/libgomp.c-c++-common/requires-3.c
index 4b07ffdd09b..7091f400ef0 100644
--- a/libgomp/testsuite/libgomp.c-c++-common/requires-3.c
+++ b/libgomp/testsuite/libgomp.c-c++-common/requires-3.c
@@ -1,4 +1,4 @@
-/* { dg-do link { target offloading_enabled } } */
+/* { dg-do link { target { offload_target_nvptx || offload_target_amdgcn } } } */
 /* { dg-additional-sources requires-3-aux.c } */
 
 /* Check diagnostic by device-compiler's lto1.
-- 
2.35.1

Enhance 'libgomp.c-c++-common/requires-4.c', 'libgomp.c-c++-common/requires-5.c' testing (was: [Patch][v4] OpenMP: Move omp requires checks to libgomp)

[Thomas Schwinge]

Hi!

In preparation for other changes:

On 2022-06-29T16:33:02+0200, Tobias Burnus  wrote:
> --- /dev/null
> +++ b/libgomp/testsuite/libgomp.c-c++-common/requires-4-aux.c
> @@ -0,0 +1,13 @@
> +/* { dg-skip-if "" { *-*-* } } */
> +
> +#pragma omp requires reverse_offload
> +
> +/* Note: The file does not have neither of:
> +   declare target directives, device constructs or device routines.  */
> +
> +int x;
> +
> +void foo (void)
> +{
> +  x = 1;
> +}

> --- /dev/null
> +++ b/libgomp/testsuite/libgomp.c-c++-common/requires-4.c
> @@ -0,0 +1,23 @@
> +/* { dg-do link { target offloading_enabled } } */
> +/* { dg-additional-options "-flto" } */
> +/* { dg-additional-sources requires-4-aux.c } */
> +
> +/* Check diagnostic by device-compiler's or host compiler's lto1.
> +   Other file uses: 'requires reverse_offload', but that's inactive as
> +   there are no declare target directives, device constructs nor device 
> routines  */
> +
> +#pragma omp requires unified_address,unified_shared_memory
> +
> +int a[10];
> +extern void foo (void);
> +
> +int
> +main (void)
> +{
> +  #pragma omp target
> +  for (int i = 0; i < 10; i++)
> +a[i] = 0;
> +
> +  foo ();
> +  return 0;
> +}

> --- /dev/null
> +++ b/libgomp/testsuite/libgomp.c-c++-common/requires-5-aux.c
> @@ -0,0 +1,11 @@
> +/* { dg-skip-if "" { *-*-* } } */
> +
> +#pragma omp requires unified_shared_memory, unified_address, reverse_offload
> +
> +int x;
> +
> +void foo (void)
> +{
> +  #pragma omp target
> +  x = 1;
> +}

> --- /dev/null
> +++ b/libgomp/testsuite/libgomp.c-c++-common/requires-5.c
> @@ -0,0 +1,20 @@
> +/* { dg-do run { target { offload_target_nvptx || offload_target_amdgcn } } 
> } */
> +/* { dg-additional-sources requires-5-aux.c } */
> +
> +#pragma omp requires unified_shared_memory, unified_address, reverse_offload
> +
> +int a[10];
> +extern void foo (void);
> +
> +int
> +main (void)
> +{
> +  #pragma omp target
> +  for (int i = 0; i < 10; i++)
> +a[i] = 0;
> +
> +  foo ();
> +  return 0;
> +}
> +
> +/* { dg-output "devices present but 'omp requires unified_address, 
> unified_shared_memory, reverse_offload' cannot be fulfilled" } */

(The latter diagnostic later got conditionalized by 'GOMP_DEBUG=1'.)

OK to push the attached "Enhance 'libgomp.c-c++-common/requires-4.c',
'libgomp.c-c++-common/requires-5.c' testing"?


Grüße
 Thomas


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
>From ae14ccbd050d0b49073d5ea09de3e2af63f8c674 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Thu, 7 Jul 2022 09:45:42 +0200
Subject: [PATCH] Enhance 'libgomp.c-c++-common/requires-4.c',
 'libgomp.c-c++-common/requires-5.c' testing

These should compile and link and execute in all configurations; host-fallback
execution, which we may actually verify.

Follow-up to recent commit 683f11843974f0bdf42f79cdcbb0c2b43c7b81b0
"OpenMP: Move omp requires checks to libgomp".

	libgomp/
	* testsuite/libgomp.c-c++-common/requires-4.c: Enhance testing.
	* testsuite/libgomp.c-c++-common/requires-5.c: Likewise.
---
 .../libgomp.c-c++-common/requires-4.c  | 17 -
 .../libgomp.c-c++-common/requires-5.c  | 18 +++---
 2 files changed, 23 insertions(+), 12 deletions(-)

diff --git a/libgomp/testsuite/libgomp.c-c++-common/requires-4.c b/libgomp/testsuite/libgomp.c-c++-common/requires-4.c
index 128fdbb8463..deb04368108 100644
--- a/libgomp/testsuite/libgomp.c-c++-common/requires-4.c
+++ b/libgomp/testsuite/libgomp.c-c++-common/requires-4.c
@@ -1,22 +1,29 @@
-/* { dg-do link { target offloading_enabled } } */
 /* { dg-additional-options "-flto" } */
 /* { dg-additional-sources requires-4-aux.c } */
 
-/* Check diagnostic by device-compiler's or host compiler's lto1.
+/* Check no diagnostic by device-compiler's or host compiler's lto1.
Other file uses: 'requires reverse_offload', but that's inactive as
there are no declare target directives, device constructs nor device routines  */
 
+/* For actual offload execution, prints the following (only) if GOMP_DEBUG=1:
+   "devices present but 'omp requires unified_address, unified_shared_memory, reverse_offload' cannot be fulfilled"
+   and does host-fallback execution.  */
+
 #pragma omp requires unified_address,unified_shared_memory
 
-int a[10];
+int a[10] = { 0 };
 extern void foo (void);
 
 int
 ma

Re: Enhance 'libgomp.c-c++-common/requires-4.c', 'libgomp.c-c++-common/requires-5.c' testing (was: [Patch][v4] OpenMP: Move omp requires checks to libgomp)

[Thomas Schwinge]

Hi Tobias!

On 2022-07-07T11:36:34+0200, Tobias Burnus  wrote:
> On 07.07.22 10:42, Thomas Schwinge wrote:
>> In preparation for other changes:
> ...
>> On 2022-06-29T16:33:02+0200, Tobias Burnus  wrote:
>>> +/* { dg-output "devices present but 'omp requires unified_address, 
>>> unified_shared_memory, reverse_offload' cannot be fulfilled" } */
>> (The latter diagnostic later got conditionalized by 'GOMP_DEBUG=1'.)
>> OK to push the attached "Enhance 'libgomp.c-c++-common/requires-4.c',
>> 'libgomp.c-c++-common/requires-5.c' testing"?
> ...
>>  libgomp/
>>  * testsuite/libgomp.c-c++-common/requires-4.c: Enhance testing.
>>  * testsuite/libgomp.c-c++-common/requires-5.c: Likewise.
> ...
>> --- a/libgomp/testsuite/libgomp.c-c++-common/requires-4.c
>> +++ b/libgomp/testsuite/libgomp.c-c++-common/requires-4.c
>> @@ -1,22 +1,29 @@
>> -/* { dg-do link { target offloading_enabled } } */
>>   /* { dg-additional-options "-flto" } */
>>   /* { dg-additional-sources requires-4-aux.c } */
>>
>> -/* Check diagnostic by device-compiler's or host compiler's lto1.
>> +/* Check no diagnostic by device-compiler's or host compiler's lto1.
>
> I note that without ENABLE_OFFLOADING that there is never any lto1
> diagnostic.
>
> However, given that no diagnostic is expected, it also works for "!
> offloading_enabled".
>
> Thus, the change fine.

ACK.

>>  Other file uses: 'requires reverse_offload', but that's inactive as
>>  there are no declare target directives, device constructs nor device 
>> routines  */
>>
>> +/* For actual offload execution, prints the following (only) if 
>> GOMP_DEBUG=1:
>> +   "devices present but 'omp requires unified_address, 
>> unified_shared_memory, reverse_offload' cannot be fulfilled"
>> +   and does host-fallback execution.  */
>
> The latter is only true when also device code is produced – and a device
> is available for that/those device types. I think that's what you imply
> by "For actual offload execution"

ACK.

> but it is a bit hidden.
>
> Maybe s/For actual offload execution, prints/It may print/ is clearer?

I've settled on:

/* Depending on offload device capabilities, it may print something like the
   following (only) if GOMP_DEBUG=1:
   "devices present but 'omp requires unified_address, 
unified_shared_memory, reverse_offload' cannot be fulfilled"
   and in that case does host-fallback execution.  */

> In principle, it would be nice if we could test for the output, but
> currently setting an env var for remote execution does not work, yet.
> Cf. https://gcc.gnu.org/pipermail/gcc-patches/2022-July/597773.html

Right, I'm aware of that issue with remote testing, and that's why I
didn't propose such output verification.  (In a few other test cases, we
do have 'dg-set-target-env-var GOMP_DEBUG "1"', which then at present are
UNSUPPORTED for remote testing.)

> When set, we could use offload_target_nvptx etc. (..._amdgcn, ..._any)
> to test – as this guarantees that it is compiled for that device + the
> device is available.

Use 'target offload_device_nvptx', not 'target offload_target_nvptx',
etc.  ;-)

>> +
>>   #pragma omp requires unified_address,unified_shared_memory
>>
>> -int a[10];
>> +int a[10] = { 0 };
>>   extern void foo (void);
>>
>>   int
>>   main (void)
>>   {
>> -  #pragma omp target
>> +  #pragma omp target map(to: a)
>
> Hmm, I wonder whether I like it or not. Without, there is an implicit
> "map(tofrom:a)". On the other hand, OpenMP permits that – even with
> unified-shared memory – the implementation my copy the data to the
> device. (For instance, to permit faster access to "a".)
>
> Thus, ...
>
>> +  for (int i = 0; i < 10; i++)
>> +a[i] = i;
>> +
>> for (int i = 0; i < 10; i++)
>> -a[i] = 0;
>> +if (a[i] != i)
>> +  __builtin_abort ();
> ... this condition (back on the host) could also fail with USM. However,
> given that to my knowledge no USM implementation actually copies the
> data, I believe it is fine.

Right, this is meant to describe/test the current GCC master branch
behavior, where USM isn't supported, so I didn't consider that.  But I
agree, a source code comment should be added:

   As no offload devices support USM at present, we may verify host-fallback
   execution by absence of separate memory spaces.  */

> (Disclaimer: I 

Re: Fix Intel MIC 'mkoffload' for OpenMP 'requires' (was: [Patch] OpenMP: Move omp requires checks to libgomp)

[Thomas Schwinge]

Hi Tobias!

On 2022-07-06T15:30:57+0200, Tobias Burnus  wrote:
> On 06.07.22 14:38, Thomas Schwinge wrote:
>> :-) Haha, that's actually *exactly* what I had implemented first!  But
>> then I realized that 'target offloading_enabled' is doing exactly that:
>> check that offloading compilation is configured -- not that "there is an
>> offloading device available or not" as you seem to understand?  Or am I
>> confused there?
>
> I think as you mentioned below – there is a difference.

Eh, thanks for un-confusing me on that aspect!  There's a reason after
all that 'offloading_enabled' lives in 'gcc/testsuite/lib/'...

> And that difference,
> I explicitly maked use of: [...]

> Granted, as the other files do not use -foffload=..., it should not
> make a difference - but, still, replacing it unconditionally
> with 'target offloading_enabled' feels wrong.

ACK!

I've pushed to master branch
commit 9ef714539cb7cc1cd746312fd5dcc987bf167471
"Fix Intel MIC 'mkoffload' for OpenMP 'requires'", see attached.


Grüße
 Thomas


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
>From 9ef714539cb7cc1cd746312fd5dcc987bf167471 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Tue, 5 Jul 2022 12:21:33 +0200
Subject: [PATCH] Fix Intel MIC 'mkoffload' for OpenMP 'requires'

Similar to how the other 'mkoffload's got changed in
recent commit 683f11843974f0bdf42f79cdcbb0c2b43c7b81b0
"OpenMP: Move omp requires checks to libgomp".

This also means finally switching Intel MIC 'mkoffload' to
'GOMP_offload_register_ver', 'GOMP_offload_unregister_ver',
making 'GOMP_offload_register', 'GOMP_offload_unregister'
legacy entry points.

	gcc/
	* config/i386/intelmic-mkoffload.cc (generate_host_descr_file)
	(prepare_target_image, main): Handle OpenMP 'requires'.
	(generate_host_descr_file): Switch to 'GOMP_offload_register_ver',
	'GOMP_offload_unregister_ver'.
	libgomp/
	* target.c (GOMP_offload_register, GOMP_offload_unregister):
	Denote as legacy entry points.
	* testsuite/lib/libgomp.exp
	(check_effective_target_offload_target_any): New proc.
	* testsuite/libgomp.c-c++-common/requires-1.c: Enable for
	'offload_target_any'.
	* testsuite/libgomp.c-c++-common/requires-3.c: Likewise.
	* testsuite/libgomp.c-c++-common/requires-7.c: Likewise.
	* testsuite/libgomp.fortran/requires-1.f90: Likewise.
---
 gcc/config/i386/intelmic-mkoffload.cc | 56 +++
 libgomp/target.c  |  4 ++
 libgomp/testsuite/lib/libgomp.exp |  5 ++
 .../libgomp.c-c++-common/requires-1.c |  2 +-
 .../libgomp.c-c++-common/requires-3.c |  2 +-
 .../libgomp.c-c++-common/requires-7.c |  2 +-
 .../testsuite/libgomp.fortran/requires-1.f90  |  2 +-
 7 files changed, 57 insertions(+), 16 deletions(-)

diff --git a/gcc/config/i386/intelmic-mkoffload.cc b/gcc/config/i386/intelmic-mkoffload.cc
index c683d6f473e..596f6f107b8 100644
--- a/gcc/config/i386/intelmic-mkoffload.cc
+++ b/gcc/config/i386/intelmic-mkoffload.cc
@@ -370,7 +370,7 @@ generate_target_offloadend_file (const char *target_compiler)
 
 /* Generates object file with the host side descriptor.  */
 static const char *
-generate_host_descr_file (const char *host_compiler)
+generate_host_descr_file (const char *host_compiler, uint32_t omp_requires)
 {
   char *dump_filename = concat (dumppfx, "_host_descr.c", NULL);
   const char *src_filename = save_temps
@@ -386,39 +386,50 @@ generate_host_descr_file (const char *host_compiler)
   if (!src_file)
 fatal_error (input_location, "cannot open '%s'", src_filename);
 
+  fprintf (src_file, "#include \n\n");
+
   fprintf (src_file,
 	   "extern const void *const __OFFLOAD_TABLE__;\n"
 	   "extern const void *const __offload_image_intelmic_start;\n"
 	   "extern const void *const __offload_image_intelmic_end;\n\n"
 
-	   "static const void *const __offload_target_data[] = {\n"
+	   "static const struct intelmic_data {\n"
+	   "  uintptr_t omp_requires_mask;\n"
+	   "  const void *const image_start;\n"
+	   "  const void *const image_end;\n"
+	   "} intelmic_data = {\n"
+	   "  %d,\n"
 	   "  &__offload_image_intelmic_start, &__offload_image_intelmic_end\n"
-	   "};\n\n");
+	   "};\n\n", omp_requires);
 
   fprintf (src_file,
 	   "#ifdef __cplusplus\n"
 	   "extern \"C\"\n"
 	 

Fix one issue in OpenMP 'requires' directive diagnostics (was: [Patch][v5] OpenMP: Move omp requires checks to libgomp)

[Thomas Schwinge]

else
> + {
> +   error ("OpenMP % directive with %qs specified "
> +  "only in some compilation units", buf2);
> +   inform (UNKNOWN_LOCATION, "%qs has %qs",
> +   val != OMP_REQUIRES_TARGET_USED ? fn2 : fn1,
> +   buf2);
> +   inform (UNKNOWN_LOCATION, "but %qs has not",
> +   val != OMP_REQUIRES_TARGET_USED ? fn1 : fn2);
> + }
> +   error_emitted = true;
> + }
>   }
> else
>   fatal_error (input_location,


Grüße
 Thomas


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
>From 2271282f127366e785601242a46d4aa668bd6660 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Thu, 7 Jul 2022 15:11:03 +0200
Subject: [PATCH] Fix one issue in OpenMP 'requires' directive diagnostics

Fix-up for recent commit 683f11843974f0bdf42f79cdcbb0c2b43c7b81b0
"OpenMP: Move omp requires checks to libgomp".

	gcc/
	* lto-cgraph.cc (input_offload_tables) : Correct
	'fn2' computation.
	libgomp/
	* testsuite/libgomp.c-c++-common/requires-1.c: Add 'dg-note's.
	* testsuite/libgomp.c-c++-common/requires-2.c: Likewise.
	* testsuite/libgomp.c-c++-common/requires-3.c: Likewise.
	* testsuite/libgomp.c-c++-common/requires-7.c: Likewise.
	* testsuite/libgomp.fortran/requires-1.f90: Likewise.
---
 gcc/lto-cgraph.cc   | 2 +-
 libgomp/testsuite/libgomp.c-c++-common/requires-1.c | 4 +++-
 libgomp/testsuite/libgomp.c-c++-common/requires-2.c | 4 +++-
 libgomp/testsuite/libgomp.c-c++-common/requires-3.c | 4 +++-
 libgomp/testsuite/libgomp.c-c++-common/requires-7.c | 7 ++-
 libgomp/testsuite/libgomp.fortran/requires-1.f90| 5 +
 6 files changed, 21 insertions(+), 5 deletions(-)

diff --git a/gcc/lto-cgraph.cc b/gcc/lto-cgraph.cc
index 48629651e31..6d9c36ea8b6 100644
--- a/gcc/lto-cgraph.cc
+++ b/gcc/lto-cgraph.cc
@@ -1879,7 +1879,7 @@ input_offload_tables (bool do_force_output)
 			 && TREE_CODE (tmp_decl) != TRANSLATION_UNIT_DECL)
 			tmp_decl = DECL_CONTEXT (tmp_decl);
 		  if (tmp_decl != NULL_TREE)
-			fn2 = IDENTIFIER_POINTER (DECL_NAME (requires_decl));
+			fn2 = IDENTIFIER_POINTER (DECL_NAME (tmp_decl));
 		}
 
 		  char buf1[sizeof ("unified_address, unified_shared_memory, "
diff --git a/libgomp/testsuite/libgomp.c-c++-common/requires-1.c b/libgomp/testsuite/libgomp.c-c++-common/requires-1.c
index ab9a8ddfcde..31996f1ecf6 100644
--- a/libgomp/testsuite/libgomp.c-c++-common/requires-1.c
+++ b/libgomp/testsuite/libgomp.c-c++-common/requires-1.c
@@ -20,5 +20,7 @@ main (void)
   return 0;
 }
 
-/* { dg-error "OpenMP 'requires' directive with non-identical clauses in multiple compilation units: 'unified_shared_memory' vs. 'unified_address'" "" { target *-*-* } 0 }  */
+/* { dg-error "OpenMP 'requires' directive with non-identical clauses in multiple compilation units: 'unified_shared_memory' vs. 'unified_address'" "" { target *-*-* } 0 }
+ { dg-note {requires-1\.c' has 'unified_shared_memory'} {} { target *-*-* } 0 }
+ { dg-note {requires-1-aux\.c' has 'unified_address'} {} { target *-*-* } 0 } */
 /* { dg-excess-errors "Ignore messages like: errors during merging of translation units|mkoffload returned 1 exit status" } */
diff --git a/libgomp/testsuite/libgomp.c-c++-common/requires-2.c b/libgomp/testsuite/libgomp.c-c++-common/requires-2.c
index be1830d0c46..b20e154b0c7 100644
--- a/libgomp/testsuite/libgomp.c-c++-common/requires-2.c
+++ b/libgomp/testsuite/libgomp.c-c++-common/requires-2.c
@@ -21,5 +21,7 @@ main (void)
   return 0;
 }
 
-/* { dg-error "OpenMP 'requires' directive with 'unified_shared_memory' specified only in some compilation units" "" { target *-*-* } 0 }  */
+/* { dg-error "OpenMP 'requires' directive with 'unified_shared_memory' specified only in some compilation units" "" { target *-*-* } 0 }
+ { dg-note {requires-2\.c' has 'unified_shared_memory'} {} { target *-*-* } 0 }
+ { dg-note {but '[^']*requires-2-aux\.c' has not} {} { target *-*-* } 0 } */
 /* { dg-excess-errors "Ignore messages like: errors during merging of translation units|mkoffload returned 1 exit status" } */
diff --git a/libgomp/testsuite/libgomp.c-c++-common/requires-3.c b/libgomp/testsuite/libgomp.c-c++-common/requires-3.c
index 1c204c8a21e..a549a19ebb

Re: Fix one issue in OpenMP 'requires' directive diagnostics (was: [Patch][v5] OpenMP: Move omp requires checks to libgomp)

[Thomas Schwinge]

Hi!

On 2022-07-07T15:56:28+0200, Tobias Burnus  wrote:
> On 07.07.22 15:26, Thomas Schwinge wrote:
>> On 2022-07-01T23:08:16+0200, Tobias Burnus 
>> wrote:
>>> Updated version attached – I hope I got everything right, but I start to
>>> get tired, I am not 100% sure.
>> ..., and so the obligatory copy'n'past-o;-)  crept in:
> ...
>>> + if (tmp_decl != NULL_TREE)
>>> +   fn2 = IDENTIFIER_POINTER (DECL_NAME (requires_decl));
>>> +   }
>> ... here: tmp_decl' not 'requires_decl'.  OK to push the attached
>> "Fix one issue in OpenMP 'requires' directive diagnostics"?
> Good that you spotted it and thanks for testing + fixing it!
>> I'd even push that one "as obvious", but thought I'd ask whether you
>> maybe have a quick idea about the XFAILs that I'm adding?  (I'm otherwise
>> not planning on resolving that issue at this time.)
>
> (This question relates to what's printed if there is no 
> TRANSLATION_UNIT_DECL.)
> [...]

Thanks for the explanation, makes sense.

> Regarding the xfail: I think it is fine to have this xfail, but as it is
> clear why inform points to /tmp/cc*.o, you could reword the TODO to
> state why it goes wrong.

Done:

TODO We're currently not streaming location information for the OpenMP
directives used in 'requires-7-aux.c', so we're not seeing the source file
name here (but a temporary '*.o' instead; for details, see
<https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598011.html>):
{ dg-note {requires-7-aux\.c' has 'unified_address'} {} { xfail *-*-* } 0 }
..., but we may still verify that the rest of the diagnostic is correct:
{ dg-note {' has 'unified_address'} {} { target *-*-* } 0 }

With just that changed, I've pushed to master branch
commit faa0c328ee65f0d6d65d6e20181d26e336071919
"Fix one issue in OpenMP 'requires' directive diagnostics", see attached.


Grüße
 Thomas


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
>From faa0c328ee65f0d6d65d6e20181d26e336071919 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Thu, 7 Jul 2022 15:11:03 +0200
Subject: [PATCH] Fix one issue in OpenMP 'requires' directive diagnostics

Fix-up for recent commit 683f11843974f0bdf42f79cdcbb0c2b43c7b81b0
"OpenMP: Move omp requires checks to libgomp".

	gcc/
	* lto-cgraph.cc (input_offload_tables) : Correct
	'fn2' computation.
	libgomp/
	* testsuite/libgomp.c-c++-common/requires-1.c: Add 'dg-note's.
	* testsuite/libgomp.c-c++-common/requires-2.c: Likewise.
	* testsuite/libgomp.c-c++-common/requires-3.c: Likewise.
	* testsuite/libgomp.c-c++-common/requires-7.c: Likewise.
	* testsuite/libgomp.fortran/requires-1.f90: Likewise.
---
 gcc/lto-cgraph.cc   |  2 +-
 libgomp/testsuite/libgomp.c-c++-common/requires-1.c |  4 +++-
 libgomp/testsuite/libgomp.c-c++-common/requires-2.c |  4 +++-
 libgomp/testsuite/libgomp.c-c++-common/requires-3.c |  4 +++-
 libgomp/testsuite/libgomp.c-c++-common/requires-7.c | 10 +-
 libgomp/testsuite/libgomp.fortran/requires-1.f90|  8 
 6 files changed, 27 insertions(+), 5 deletions(-)

diff --git a/gcc/lto-cgraph.cc b/gcc/lto-cgraph.cc
index 48629651e31..6d9c36ea8b6 100644
--- a/gcc/lto-cgraph.cc
+++ b/gcc/lto-cgraph.cc
@@ -1879,7 +1879,7 @@ input_offload_tables (bool do_force_output)
 			 && TREE_CODE (tmp_decl) != TRANSLATION_UNIT_DECL)
 			tmp_decl = DECL_CONTEXT (tmp_decl);
 		  if (tmp_decl != NULL_TREE)
-			fn2 = IDENTIFIER_POINTER (DECL_NAME (requires_decl));
+			fn2 = IDENTIFIER_POINTER (DECL_NAME (tmp_decl));
 		}
 
 		  char buf1[sizeof ("unified_address, unified_shared_memory, "
diff --git a/libgomp/testsuite/libgomp.c-c++-common/requires-1.c b/libgomp/testsuite/libgomp.c-c++-common/requires-1.c
index ab9a8ddfcde..31996f1ecf6 100644
--- a/libgomp/testsuite/libgomp.c-c++-common/requires-1.c
+++ b/libgomp/testsuite/libgomp.c-c++-common/requires-1.c
@@ -20,5 +20,7 @@ main (void)
   return 0;
 }
 
-/* { dg-error "OpenMP 'requires' directive with non-identical clauses in multiple compilation units: 'unified_shared_memory' vs. 'unified_address'" "" { target *-*-* } 0 }  */
+/* { dg-error "OpenMP 'requires' directive with non-identical clauses in multiple compilation units: 'unified_shared_memory' vs. 'unified_address'" "" { target *-*-* } 0 }
+ { dg-note {requires-1\.c'

Enhance '_Pragma' diagnostics verification in OMP C/C++ test cases (was: [PATCH] c: Fix location for _Pragma tokens [PR97498])

[Thomas Schwinge]

Hi!

On 2022-07-10T16:51:11-0400, Lewis Hyatt via Gcc-patches 
 wrote:
> On Sat, Jul 9, 2022 at 11:59 PM Jeff Law via Gcc-patches
>  wrote:
>> On 7/9/2022 2:52 PM, Lewis Hyatt via Gcc-patches wrote:
>> > PR97498 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97498) is another PR
>> > related to the fact that imprecise locations for _Pragma result in
>> > counterintuitive behavior for GCC diagnostic pragmas

>> > I think the main source of problems for all remaining issues is that we use
>> > the global input_location for deciding when/if a diagnostic should apply. I
>> > think it should be eventually doable to eliminate this, and rather properly
>> > resolve the token locations to the place they need to be
>> I've long wanted to see our dependency on input_location be diminished
>> with the goal of making it go away completely.
> [...]

> Then I will plan to work on
> eliminating input_location from c-pragma.cc as a longer term goal.

Great; I too am looking forward to that.  There, and then elsewhere,
everywhere.  :-)

>> > The rest of [patch] is just tweaking a couple tests which were sensitive 
>> > to the
>> > location being output. In all these cases, the new locations seem more
>> > informative to me than the old ones.

ACK, thanks.

On top of that, I've just pushed to master branch
commit 06b2a2abe26554c6f9365676683d67368cbba206
"Enhance '_Pragma' diagnostics verification in OMP C/C++ test cases", see
attached.


Grüße
 Thomas


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
>From 06b2a2abe26554c6f9365676683d67368cbba206 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Mon, 11 Jul 2022 09:33:19 +0200
Subject: [PATCH] Enhance '_Pragma' diagnostics verification in OMP C/C++ test
 cases

Follow-up to recent commit 0587cef3d7962a8b0f44779589ba2920dd3d71e5
"c: Fix location for _Pragma tokens [PR97498]".

	gcc/testsuite/
	* c-c++-common/gomp/pragma-3.c: Enhance '_Pragma' diagnostics
	verification.
	* c-c++-common/gomp/pragma-5.c: Likewise.
	libgomp/
	* testsuite/libgomp.oacc-c-c++-common/reduction-5.c: Enhance
	'_Pragma' diagnostics verification.
---
 gcc/testsuite/c-c++-common/gomp/pragma-3.c| 8 +---
 gcc/testsuite/c-c++-common/gomp/pragma-5.c| 8 +---
 libgomp/testsuite/libgomp.oacc-c-c++-common/reduction-5.c | 8 +---
 3 files changed, 15 insertions(+), 9 deletions(-)

diff --git a/gcc/testsuite/c-c++-common/gomp/pragma-3.c b/gcc/testsuite/c-c++-common/gomp/pragma-3.c
index ae18e9b8886..3e1b2111c3d 100644
--- a/gcc/testsuite/c-c++-common/gomp/pragma-3.c
+++ b/gcc/testsuite/c-c++-common/gomp/pragma-3.c
@@ -2,13 +2,15 @@
 /* PR preprocessor/103165  */
 
 #define inner(...) #__VA_ARGS__ ; _Pragma("omp error severity(warning) message (\"Test\") at(compilation)") /* { dg-line inner_location } */
-#define outer(...) inner(__VA_ARGS__)
+#define outer(...) inner(__VA_ARGS__) /* { dg-line outer_location } */
 
 void
 f (void)
 {
-  const char *str = outer(inner(1,2));
-  /* { dg-warning "'pragma omp error' encountered: Test" "inner expansion" { target *-*-* } inner_location } */
+  const char *str = outer(inner(1,2)); /* { dg-line str_location } */
+  /* { dg-warning "35:'pragma omp error' encountered: Test" "" { target *-*-* } inner_location }
+ { dg-note "20:in expansion of macro 'inner'" "" { target *-*-* } outer_location }
+ { dg-note "21:in expansion of macro 'outer'" "" { target *-*-* } str_location } */
 }
 
 #if 0
diff --git a/gcc/testsuite/c-c++-common/gomp/pragma-5.c b/gcc/testsuite/c-c++-common/gomp/pragma-5.c
index 8124f701502..173c25e803a 100644
--- a/gcc/testsuite/c-c++-common/gomp/pragma-5.c
+++ b/gcc/testsuite/c-c++-common/gomp/pragma-5.c
@@ -2,13 +2,15 @@
 /* PR preprocessor/103165  */
 
 #define inner(...) #__VA_ARGS__ ; _Pragma   (	"   omp		error severity   (warning)	message (\"Test\") at(compilation)" ) /* { dg-line inner_location } */
-#define outer(...) inner(__VA_ARGS__)
+#define outer(...) inner(__VA_ARGS__) /* { dg-line outer_location } */
 
 void
 f (void)
 {
-  const char *str = outer(inner(1,2));
-  /* { dg-warning "'pragma omp error' encountered: Test" "inner expansion" { target *-*-* } inner_location } */
+  const char *str = outer(inner(1,2)); /* { dg-line str_location } */
+  /* { dg-warning "35:'pragma omp error' encountered: Test" "" { target *-*-* } inner_location }
+ { dg-note &quo

XFAIL 'offloading_enabled' diagnostics issue in 'libgomp.oacc-c-c++-common/reduction-5.c' [PR101551] (was: Enhance '_Pragma' diagnostics verification in OMP C/C++ test cases)

[Thomas Schwinge]

Hi!

On 2022-07-11T11:27:12+0200, I wrote:
> [...], I've just pushed to master branch
> commit 06b2a2abe26554c6f9365676683d67368cbba206
> "Enhance '_Pragma' diagnostics verification in OMP C/C++ test cases"

> --- a/libgomp/testsuite/libgomp.oacc-c-c++-common/reduction-5.c
> +++ b/libgomp/testsuite/libgomp.oacc-c-c++-common/reduction-5.c
> @@ -17,7 +17,7 @@ const int n = 100;
>  #define check_reduction(gwv_par, gwv_loop)   \
>{  \
>s1 = 2; s2 = 5;\
> -DO_PRAGMA (acc parallel gwv_par copy (s1, s2))   \
> +DO_PRAGMA (acc parallel gwv_par copy (s1, s2)) /* { dg-line DO_PRAGMA_loc } 
> */ \
>  DO_PRAGMA (acc loop gwv_loop reduction (+:s1, s2))   \
>  for (i = 0; i < n; i++)  \
>{  \
> @@ -45,8 +45,10 @@ main (void)
>
>/* Nvptx targets require a vector_length or 32 in to allow spinlocks with
>   gangs.  */
> -  check_reduction (num_workers (nw) vector_length (vl), worker);
> -  /* { dg-warning "region is vector partitioned but does not contain vector 
> partitioned code" "test1" { target *-*-* } pragma_loc } */
> +  check_reduction (num_workers (nw) vector_length (vl), worker); /* { 
> dg-line check_reduction_loc }
> +  /* { dg-warning "22:region is vector partitioned but does not contain 
> vector partitioned code" "" { target *-*-* } pragma_loc }
> + { dg-note "1:in expansion of macro 'DO_PRAGMA'" "" { target *-*-* } 
> DO_PRAGMA_loc }
> + { dg-note "3:in expansion of macro 'check_reduction'" "" { target *-*-* 
> } check_reduction_loc } */

Oh my, PR101551 "[offloading] Differences in diagnostics etc."
strikes again...  The latter two 'note' diagnostics are currently
only emitted in non-offloading configurations.  I've now pushed to
master branch commit 3723aedaad20a129741c2f6f3c22b3dd1220a3fc
"XFAIL 'offloading_enabled' diagnostics issue in
'libgomp.oacc-c-c++-common/reduction-5.c' [PR101551]", see attached.


Grüße
 Thomas


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
>From 3723aedaad20a129741c2f6f3c22b3dd1220a3fc Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Tue, 12 Jul 2022 08:17:37 +0200
Subject: [PATCH] XFAIL 'offloading_enabled' diagnostics issue in
 'libgomp.oacc-c-c++-common/reduction-5.c' [PR101551]

Fix-up for recent commit 06b2a2abe26554c6f9365676683d67368cbba206
"Enhance '_Pragma' diagnostics verification in OMP C/C++ test cases".
Supposedly it's the same issue as in
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101551#c2>, where I'd
noted that:

| [...] with an offloading-enabled build of GCC we're losing
| "note: in expansion of macro '[...]'" diagnostics.
| (Effectively '-ftrack-macro-expansion=0'?)

	PR middle-end/101551
	libgomp/
	* testsuite/libgomp.oacc-c-c++-common/reduction-5.c: XFAIL
	'offloading_enabled' diagnostics issue.
---
 libgomp/testsuite/libgomp.oacc-c-c++-common/reduction-5.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/libgomp/testsuite/libgomp.oacc-c-c++-common/reduction-5.c b/libgomp/testsuite/libgomp.oacc-c-c++-common/reduction-5.c
index 72094609f0f..ddccfe89e73 100644
--- a/libgomp/testsuite/libgomp.oacc-c-c++-common/reduction-5.c
+++ b/libgomp/testsuite/libgomp.oacc-c-c++-common/reduction-5.c
@@ -45,10 +45,11 @@ main (void)
 
   /* Nvptx targets require a vector_length or 32 in to allow spinlocks with
  gangs.  */
-  check_reduction (num_workers (nw) vector_length (vl), worker); /* { dg-line check_reduction_loc }
+  check_reduction (num_workers (nw) vector_length (vl), worker); /* { dg-line check_reduction_loc } */
   /* { dg-warning "22:region is vector partitioned but does not contain vector partitioned code" "" { target *-*-* } pragma_loc }
- { dg-note "1:in expansion of macro 'DO_PRAGMA'" "" { target *-*-* } DO_PRAGMA_loc }
- { dg-note "3:in expansion of macro 'check_reduction'" "" { target *-*-* } check_reduction_loc } */
+ { dg-note "1:in expansion of macro 'DO_PRAGMA'" "" { target *-*-* xfail offloading_enabled } DO_PRAGMA_loc }
+ { dg-note "3:in expansion of macro 'check_reduction'" "" { target *-*-* xfail offloading_enabled } check_reduction_loc }
+ TODO See PR101551 for 'offloading_enabled' XFAILs.  */
   check_reduction (vector_length (vl), vector);
   check_reduction (num_gangs (ng) num_workers (nw) vector_length (vl), gang
 		   worker vector);
-- 
2.35.1

[PING^3] nvptx: forward '-v' command-line option to assembler, linker

[Thomas Schwinge]

Hi Tom!

Ping.


Grüße
 Thomas


On 2022-07-05T16:58:54+0200, I wrote:
> Hi Tom!
>
> Ping.
>
>
> Grüße
>  Thomas
>
>
> On 2022-06-07T17:41:16+0200, I wrote:
>> Hi!
>>
>> On 2022-05-30T09:06:21+0200, Tobias Burnus  wrote:
>>> On 29.05.22 22:49, Thomas Schwinge wrote:
>>>> Not sure if that's what you had in mind, but what do you think about the
>>>> attached "nvptx: forward '-v' command-line option to assembler, linker"?
>>>> OK to push to GCC master branch (after merging
>>>> <https://github.com/MentorEmbedded/nvptx-tools/pull/37>
>>>> "Put '-v' verbose output onto stderr instead of stdout")?
>>>
>>> I was mainly thinking of some way to have it available — which
>>> '-foffload-options=-Wa,-v' already permits on the GCC side. (Once the
>>> nvptx-tools patch actually makes use of the '-v'.)
>>
>> (Merged a week ago.)
>>
>>> If I understand your patch correctly, this patch now causes 'gcc -v' to
>>> imply 'gcc -v -Wa,-v'. I think that's okay, since 'gcc -v' already
>>> outputs a lot of lines and those lines can be helpful to understand what
>>> happens and what not.
>>
>> ACK.
>>
>>> Tom, your thoughts on this?
>>
>> Ping.
>>
>>
>> Grüße
>>  Thomas


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
>From 17c35607d4927299b0c4bd19dd6fd205c85c4a4b Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Sun, 29 May 2022 22:31:43 +0200
Subject: [PATCH] nvptx: forward '-v' command-line option to assembler, linker

For example, for offloading compilation with '-save-temps -v', before vs. after
word-diff then looks like:

[...]
 [...]/build-gcc-offload-nvptx-none/gcc/as {+-v -v+} -o ./a.xnvptx-none.mkoffload.o ./a.xnvptx-none.mkoffload.s
{+Verifying sm_30 code with sm_35 code generation.+}
{+ ptxas -c -o /dev/null ./a.xnvptx-none.mkoffload.o --gpu-name sm_35 -O0+}
[...]
 [...]/build-gcc-offload-nvptx-none/gcc/collect2 {+-v -v+} -o ./a.xnvptx-none.mkoffload [...] @./a.xnvptx-none.mkoffload.args.1 -lgomp -lgcc -lc -lgcc
{+collect2 version 12.0.1 20220428 (experimental)+}
{+[...]/build-gcc-offload-nvptx-none/gcc/collect-ld -v -v -o ./a.xnvptx-none.mkoffload [...] ./a.xnvptx-none.mkoffload.o -lgomp -lgcc -lc -lgcc+}
{+Linking ./a.xnvptx-none.mkoffload.o as 0+}
{+trying lib libc.a+}
{+trying lib libgcc.a+}
{+trying lib libgomp.a+}
{+Resolving abort+}
{+Resolving acc_on_device+}
{+Linking libgomp.a::oacc-init.o/ as 1+}
{+Linking libc.a::lib_a-abort.o/   as 2+}
[...]

(This depends on <https://github.com/MentorEmbedded/nvptx-tools/pull/37>
"Put '-v' verbose output onto stderr instead of stdout".)

	gcc/
	* config/nvptx/nvptx.h (ASM_SPEC, LINK_SPEC): Define.
---
 gcc/config/nvptx/nvptx.h | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/gcc/config/nvptx/nvptx.h b/gcc/config/nvptx/nvptx.h
index ed72c253191..b184f1d0150 100644
--- a/gcc/config/nvptx/nvptx.h
+++ b/gcc/config/nvptx/nvptx.h
@@ -27,6 +27,13 @@
 
 /* Run-time Target.  */
 
+/* Assembler supports '-v' option; handle similar to
+   '../../gcc.cc:asm_options', 'HAVE_GNU_AS'.  */
+#define ASM_SPEC "%{v}"
+
+/* Linker supports '-v' option.  */
+#define LINK_SPEC "%{v}"
+
 #define STARTFILE_SPEC "%{mmainkernel:crt0.o}"
 
 #define TARGET_CPU_CPP_BUILTINS() nvptx_cpu_cpp_builtins ()
-- 
2.25.1

[PING^2] nvptx: Allow '--with-arch' to override the default '-misa' (was: nvptx multilib setup)

[Thomas Schwinge]

Hi Tom!

Ping.


Grüße
 Thomas


On 2022-07-05T16:59:23+0200, I wrote:
> Hi Tom!
>
> Ping.
>
>
> Grüße
>  Thomas
>
>
> On 2022-06-15T23:18:10+0200, I wrote:
>> Hi Tom!
>>
>> On 2022-05-13T16:20:14+0200, I wrote:
>>> On 2022-02-04T13:09:29+0100, Tom de Vries via Gcc  wrote:
>>>> On 2/4/22 08:21, Thomas Schwinge wrote:
>>>>> On 2022-02-03T13:35:55+, "vries at gcc dot gnu.org via Gcc-bugs" 
>>>>>  wrote:
>>>>>> I've tested this using (recommended) driver 470.94 on boards:
>>>
>>>>>> while iterating over dimensions { -mptx=3.1 , -mptx=6.3 } x { 
>>>>>> GOMP_NVPTX_JIT=-O0,  }.
>>>>>
>>>>> Do you use separate (nvptx-none offload target only?) builds for
>>>>> different '-mptx' variants (likewise: '-misa'), or have you hacked up the
>>>>> multilib configuration?
>>>>
>>>> Neither, I'm using --target_board=unix/foffload= for that.
>>>
>>> ACK, I see.  So these flags then only affect GCC/nvptx code generation
>>> for the actual user code (here: GCC libgomp test cases), but for the
>>> GCC/nvptx target libraries (such as: libc, libm, libgfortran, libgomp --
>>> the latter especially relevant for OpenMP), it uses PTX code from one of
>>> the two "pre-compiled" GCC/nvptx multilibs: default or '-mptx=3.1'.
>>>
>>> Meaning, one can't just use such a flag for "completely building code"
>>> for a specific configuration.  Random example,
>>> '-foffload-options=nvptx-none=-march=sm_75': as GCC/nvptx target
>>> libraries aren't being built for '-march=sm_75' multilib,
>>> '-foffload-options=nvptx-none=-march=sm_75' uses the default multilib,
>>> which isn't '-march=sm_75'.
>>>
>>>
>>>>   ('gcc/config/nvptx/t-nvptx:MULTILIB_OPTIONS'
>>>>> etc., I suppose?)  Should we add a few representative configurations to
>>>>> be built by default?  And/or, should we have a way to 'configure' per
>>>>> user needs (I suppose: '--with-multilib-list=[...]', as supported for a
>>>>> few other targets?)?  (I see there's also a new
>>>>> '--with-multilib-generator=[...]', haven't looked in detail.)  No matter
>>>>> which way: again, combinatorial explosion is a problem, of course...
>>>>
>>>> As far as I know, the gcc build doesn't finish when switching default to
>>>> higher than sm_35, so there's little point to go to a multilib setup at
>>>> this point.  But once we fix that, we could reconsider, otherwise,
>>>> things are likely to regress again.
>>>
>>> As far as I remember, several issues have been fixed.  Still waiting for
>>> Roger's "middle-end: Support ABIs that pass FP values as wider integers"
>>> or something similar, but that PR104489 issue is being worked around by
>>> "Limit HFmode support to mexperimental", if I got that right.
>>>
>>> Now I'm not suggesting we should now enable all or any random GCC/nvptx
>>> multilibs, to get all these variants of GCC/nvptx target libraries built;
>>> especially also given that GCC/nvptx code generation currently doesn't
>>> make too much use of the new capabilities.
>>>
>>> However, we do have a specific request that a customer would like to be
>>> able to change at GCC 'configure' time the GCC/nvptx default multilib
>>> (including that being used for building corresponding GCC/nvptx target
>>> libraries).
>>>
>>> Per 'gcc/doc/install.texi', I do see that some GCC targets allow for
>>> GCC 'configure'-time '--with-multilib-list=[...]', or
>>> '--with-multilib-generator=[...]', and I suppose we could be doing
>>> something similar?  But before starting implementing, I'd like your
>>> input, as you'll be the one to approve in the end.  And/or, maybe you've
>>> already made up your own ideas about that?
>>
>> So, instead of "random GCC/nvptx multilib configuration" (last
>> paragraph), I've come up with a way to implement our customer's request
>> (second last paragraph): 'configure' GCC/nvptx '--with-arch=sm_70'.
>>
>> I think I've implemented this in a way so that "random GCC/nvptx mult

[PING^4] nvptx: forward '-v' command-line option to assembler, linker

[Thomas Schwinge]

Hi Tom!

Ping.


Grüße
 Thomas


On 2022-07-13T10:41:23+0200, I wrote:
> Hi Tom!
>
> Ping.
>
>
> Grüße
>  Thomas
>
>
> On 2022-07-05T16:58:54+0200, I wrote:
>> Hi Tom!
>>
>> Ping.
>>
>>
>> Grüße
>>  Thomas
>>
>>
>> On 2022-06-07T17:41:16+0200, I wrote:
>>> Hi!
>>>
>>> On 2022-05-30T09:06:21+0200, Tobias Burnus  wrote:
>>>> On 29.05.22 22:49, Thomas Schwinge wrote:
>>>>> Not sure if that's what you had in mind, but what do you think about the
>>>>> attached "nvptx: forward '-v' command-line option to assembler, linker"?
>>>>> OK to push to GCC master branch (after merging
>>>>> <https://github.com/MentorEmbedded/nvptx-tools/pull/37>
>>>>> "Put '-v' verbose output onto stderr instead of stdout")?
>>>>
>>>> I was mainly thinking of some way to have it available — which
>>>> '-foffload-options=-Wa,-v' already permits on the GCC side. (Once the
>>>> nvptx-tools patch actually makes use of the '-v'.)
>>>
>>> (Merged a week ago.)
>>>
>>>> If I understand your patch correctly, this patch now causes 'gcc -v' to
>>>> imply 'gcc -v -Wa,-v'. I think that's okay, since 'gcc -v' already
>>>> outputs a lot of lines and those lines can be helpful to understand what
>>>> happens and what not.
>>>
>>> ACK.
>>>
>>>> Tom, your thoughts on this?
>>>
>>> Ping.
>>>
>>>
>>> Grüße
>>>  Thomas


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
>From 17c35607d4927299b0c4bd19dd6fd205c85c4a4b Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Sun, 29 May 2022 22:31:43 +0200
Subject: [PATCH] nvptx: forward '-v' command-line option to assembler, linker

For example, for offloading compilation with '-save-temps -v', before vs. after
word-diff then looks like:

[...]
 [...]/build-gcc-offload-nvptx-none/gcc/as {+-v -v+} -o ./a.xnvptx-none.mkoffload.o ./a.xnvptx-none.mkoffload.s
{+Verifying sm_30 code with sm_35 code generation.+}
{+ ptxas -c -o /dev/null ./a.xnvptx-none.mkoffload.o --gpu-name sm_35 -O0+}
[...]
 [...]/build-gcc-offload-nvptx-none/gcc/collect2 {+-v -v+} -o ./a.xnvptx-none.mkoffload [...] @./a.xnvptx-none.mkoffload.args.1 -lgomp -lgcc -lc -lgcc
{+collect2 version 12.0.1 20220428 (experimental)+}
{+[...]/build-gcc-offload-nvptx-none/gcc/collect-ld -v -v -o ./a.xnvptx-none.mkoffload [...] ./a.xnvptx-none.mkoffload.o -lgomp -lgcc -lc -lgcc+}
{+Linking ./a.xnvptx-none.mkoffload.o as 0+}
{+trying lib libc.a+}
{+trying lib libgcc.a+}
{+trying lib libgomp.a+}
{+Resolving abort+}
{+Resolving acc_on_device+}
{+Linking libgomp.a::oacc-init.o/ as 1+}
{+Linking libc.a::lib_a-abort.o/   as 2+}
[...]

(This depends on <https://github.com/MentorEmbedded/nvptx-tools/pull/37>
"Put '-v' verbose output onto stderr instead of stdout".)

	gcc/
	* config/nvptx/nvptx.h (ASM_SPEC, LINK_SPEC): Define.
---
 gcc/config/nvptx/nvptx.h | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/gcc/config/nvptx/nvptx.h b/gcc/config/nvptx/nvptx.h
index ed72c253191..b184f1d0150 100644
--- a/gcc/config/nvptx/nvptx.h
+++ b/gcc/config/nvptx/nvptx.h
@@ -27,6 +27,13 @@
 
 /* Run-time Target.  */
 
+/* Assembler supports '-v' option; handle similar to
+   '../../gcc.cc:asm_options', 'HAVE_GNU_AS'.  */
+#define ASM_SPEC "%{v}"
+
+/* Linker supports '-v' option.  */
+#define LINK_SPEC "%{v}"
+
 #define STARTFILE_SPEC "%{mmainkernel:crt0.o}"
 
 #define TARGET_CPU_CPP_BUILTINS() nvptx_cpu_cpp_builtins ()
-- 
2.25.1

[PING^3] nvptx: Allow '--with-arch' to override the default '-misa' (was: nvptx multilib setup)

[Thomas Schwinge]

Hi Tom!

Ping.


Grüße
 Thomas


On 2022-07-13T10:42:44+0200, I wrote:
> Hi Tom!
>
> Ping.
>
>
> Grüße
>  Thomas
>
>
> On 2022-07-05T16:59:23+0200, I wrote:
>> Hi Tom!
>>
>> Ping.
>>
>>
>> Grüße
>>  Thomas
>>
>>
>> On 2022-06-15T23:18:10+0200, I wrote:
>>> Hi Tom!
>>>
>>> On 2022-05-13T16:20:14+0200, I wrote:
>>>> On 2022-02-04T13:09:29+0100, Tom de Vries via Gcc  wrote:
>>>>> On 2/4/22 08:21, Thomas Schwinge wrote:
>>>>>> On 2022-02-03T13:35:55+, "vries at gcc dot gnu.org via Gcc-bugs" 
>>>>>>  wrote:
>>>>>>> I've tested this using (recommended) driver 470.94 on boards:
>>>>
>>>>>>> while iterating over dimensions { -mptx=3.1 , -mptx=6.3 } x { 
>>>>>>> GOMP_NVPTX_JIT=-O0,  }.
>>>>>>
>>>>>> Do you use separate (nvptx-none offload target only?) builds for
>>>>>> different '-mptx' variants (likewise: '-misa'), or have you hacked up the
>>>>>> multilib configuration?
>>>>>
>>>>> Neither, I'm using --target_board=unix/foffload= for that.
>>>>
>>>> ACK, I see.  So these flags then only affect GCC/nvptx code generation
>>>> for the actual user code (here: GCC libgomp test cases), but for the
>>>> GCC/nvptx target libraries (such as: libc, libm, libgfortran, libgomp --
>>>> the latter especially relevant for OpenMP), it uses PTX code from one of
>>>> the two "pre-compiled" GCC/nvptx multilibs: default or '-mptx=3.1'.
>>>>
>>>> Meaning, one can't just use such a flag for "completely building code"
>>>> for a specific configuration.  Random example,
>>>> '-foffload-options=nvptx-none=-march=sm_75': as GCC/nvptx target
>>>> libraries aren't being built for '-march=sm_75' multilib,
>>>> '-foffload-options=nvptx-none=-march=sm_75' uses the default multilib,
>>>> which isn't '-march=sm_75'.
>>>>
>>>>
>>>>>   ('gcc/config/nvptx/t-nvptx:MULTILIB_OPTIONS'
>>>>>> etc., I suppose?)  Should we add a few representative configurations to
>>>>>> be built by default?  And/or, should we have a way to 'configure' per
>>>>>> user needs (I suppose: '--with-multilib-list=[...]', as supported for a
>>>>>> few other targets?)?  (I see there's also a new
>>>>>> '--with-multilib-generator=[...]', haven't looked in detail.)  No matter
>>>>>> which way: again, combinatorial explosion is a problem, of course...
>>>>>
>>>>> As far as I know, the gcc build doesn't finish when switching default to
>>>>> higher than sm_35, so there's little point to go to a multilib setup at
>>>>> this point.  But once we fix that, we could reconsider, otherwise,
>>>>> things are likely to regress again.
>>>>
>>>> As far as I remember, several issues have been fixed.  Still waiting for
>>>> Roger's "middle-end: Support ABIs that pass FP values as wider integers"
>>>> or something similar, but that PR104489 issue is being worked around by
>>>> "Limit HFmode support to mexperimental", if I got that right.
>>>>
>>>> Now I'm not suggesting we should now enable all or any random GCC/nvptx
>>>> multilibs, to get all these variants of GCC/nvptx target libraries built;
>>>> especially also given that GCC/nvptx code generation currently doesn't
>>>> make too much use of the new capabilities.
>>>>
>>>> However, we do have a specific request that a customer would like to be
>>>> able to change at GCC 'configure' time the GCC/nvptx default multilib
>>>> (including that being used for building corresponding GCC/nvptx target
>>>> libraries).
>>>>
>>>> Per 'gcc/doc/install.texi', I do see that some GCC targets allow for
>>>> GCC 'configure'-time '--with-multilib-list=[...]', or
>>>> '--with-multilib-generator=[...]', and I suppose we could be doing
>>>> something similar?  But before starting implementing, I'd like your
>>>> input, as you'll be the one to approve in the end.  And/or, maybe you've
>>>> already ma

[PING^5] nvptx: forward '-v' command-line option to assembler, linker

[Thomas Schwinge]

Hi Tom!

Ping.


Grüße
 Thomas


On 2022-07-20T14:44:36+0200, I wrote:
> Hi Tom!
>
> Ping.
>
>
> Grüße
>  Thomas
>
>
> On 2022-07-13T10:41:23+0200, I wrote:
>> Hi Tom!
>>
>> Ping.
>>
>>
>> Grüße
>>  Thomas
>>
>>
>> On 2022-07-05T16:58:54+0200, I wrote:
>>> Hi Tom!
>>>
>>> Ping.
>>>
>>>
>>> Grüße
>>>  Thomas
>>>
>>>
>>> On 2022-06-07T17:41:16+0200, I wrote:
>>>> Hi!
>>>>
>>>> On 2022-05-30T09:06:21+0200, Tobias Burnus  wrote:
>>>>> On 29.05.22 22:49, Thomas Schwinge wrote:
>>>>>> Not sure if that's what you had in mind, but what do you think about the
>>>>>> attached "nvptx: forward '-v' command-line option to assembler, linker"?
>>>>>> OK to push to GCC master branch (after merging
>>>>>> <https://github.com/MentorEmbedded/nvptx-tools/pull/37>
>>>>>> "Put '-v' verbose output onto stderr instead of stdout")?
>>>>>
>>>>> I was mainly thinking of some way to have it available — which
>>>>> '-foffload-options=-Wa,-v' already permits on the GCC side. (Once the
>>>>> nvptx-tools patch actually makes use of the '-v'.)
>>>>
>>>> (Merged a week ago.)
>>>>
>>>>> If I understand your patch correctly, this patch now causes 'gcc -v' to
>>>>> imply 'gcc -v -Wa,-v'. I think that's okay, since 'gcc -v' already
>>>>> outputs a lot of lines and those lines can be helpful to understand what
>>>>> happens and what not.
>>>>
>>>> ACK.
>>>>
>>>>> Tom, your thoughts on this?
>>>>
>>>> Ping.
>>>>
>>>>
>>>> Grüße
>>>>  Thomas


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
>From 17c35607d4927299b0c4bd19dd6fd205c85c4a4b Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Sun, 29 May 2022 22:31:43 +0200
Subject: [PATCH] nvptx: forward '-v' command-line option to assembler, linker

For example, for offloading compilation with '-save-temps -v', before vs. after
word-diff then looks like:

[...]
 [...]/build-gcc-offload-nvptx-none/gcc/as {+-v -v+} -o ./a.xnvptx-none.mkoffload.o ./a.xnvptx-none.mkoffload.s
{+Verifying sm_30 code with sm_35 code generation.+}
{+ ptxas -c -o /dev/null ./a.xnvptx-none.mkoffload.o --gpu-name sm_35 -O0+}
[...]
 [...]/build-gcc-offload-nvptx-none/gcc/collect2 {+-v -v+} -o ./a.xnvptx-none.mkoffload [...] @./a.xnvptx-none.mkoffload.args.1 -lgomp -lgcc -lc -lgcc
{+collect2 version 12.0.1 20220428 (experimental)+}
{+[...]/build-gcc-offload-nvptx-none/gcc/collect-ld -v -v -o ./a.xnvptx-none.mkoffload [...] ./a.xnvptx-none.mkoffload.o -lgomp -lgcc -lc -lgcc+}
{+Linking ./a.xnvptx-none.mkoffload.o as 0+}
{+trying lib libc.a+}
{+trying lib libgcc.a+}
{+trying lib libgomp.a+}
{+Resolving abort+}
{+Resolving acc_on_device+}
{+Linking libgomp.a::oacc-init.o/ as 1+}
{+Linking libc.a::lib_a-abort.o/   as 2+}
[...]

(This depends on <https://github.com/MentorEmbedded/nvptx-tools/pull/37>
"Put '-v' verbose output onto stderr instead of stdout".)

	gcc/
	* config/nvptx/nvptx.h (ASM_SPEC, LINK_SPEC): Define.
---
 gcc/config/nvptx/nvptx.h | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/gcc/config/nvptx/nvptx.h b/gcc/config/nvptx/nvptx.h
index ed72c253191..b184f1d0150 100644
--- a/gcc/config/nvptx/nvptx.h
+++ b/gcc/config/nvptx/nvptx.h
@@ -27,6 +27,13 @@
 
 /* Run-time Target.  */
 
+/* Assembler supports '-v' option; handle similar to
+   '../../gcc.cc:asm_options', 'HAVE_GNU_AS'.  */
+#define ASM_SPEC "%{v}"
+
+/* Linker supports '-v' option.  */
+#define LINK_SPEC "%{v}"
+
 #define STARTFILE_SPEC "%{mmainkernel:crt0.o}"
 
 #define TARGET_CPU_CPP_BUILTINS() nvptx_cpu_cpp_builtins ()
-- 
2.25.1

[PING^4] nvptx: Allow '--with-arch' to override the default '-misa' (was: nvptx multilib setup)

[Thomas Schwinge]

Hi Tom!

Ping.


Grüße
 Thomas


On 2022-07-20T14:46:03+0200, I wrote:
> Hi Tom!
>
> Ping.
>
>
> Grüße
>  Thomas
>
>
> On 2022-07-13T10:42:44+0200, I wrote:
>> Hi Tom!
>>
>> Ping.
>>
>>
>> Grüße
>>  Thomas
>>
>>
>> On 2022-07-05T16:59:23+0200, I wrote:
>>> Hi Tom!
>>>
>>> Ping.
>>>
>>>
>>> Grüße
>>>  Thomas
>>>
>>>
>>> On 2022-06-15T23:18:10+0200, I wrote:
>>>> Hi Tom!
>>>>
>>>> On 2022-05-13T16:20:14+0200, I wrote:
>>>>> On 2022-02-04T13:09:29+0100, Tom de Vries via Gcc  
>>>>> wrote:
>>>>>> On 2/4/22 08:21, Thomas Schwinge wrote:
>>>>>>> On 2022-02-03T13:35:55+, "vries at gcc dot gnu.org via Gcc-bugs" 
>>>>>>>  wrote:
>>>>>>>> I've tested this using (recommended) driver 470.94 on boards:
>>>>>
>>>>>>>> while iterating over dimensions { -mptx=3.1 , -mptx=6.3 } x { 
>>>>>>>> GOMP_NVPTX_JIT=-O0,  }.
>>>>>>>
>>>>>>> Do you use separate (nvptx-none offload target only?) builds for
>>>>>>> different '-mptx' variants (likewise: '-misa'), or have you hacked up 
>>>>>>> the
>>>>>>> multilib configuration?
>>>>>>
>>>>>> Neither, I'm using --target_board=unix/foffload= for that.
>>>>>
>>>>> ACK, I see.  So these flags then only affect GCC/nvptx code generation
>>>>> for the actual user code (here: GCC libgomp test cases), but for the
>>>>> GCC/nvptx target libraries (such as: libc, libm, libgfortran, libgomp --
>>>>> the latter especially relevant for OpenMP), it uses PTX code from one of
>>>>> the two "pre-compiled" GCC/nvptx multilibs: default or '-mptx=3.1'.
>>>>>
>>>>> Meaning, one can't just use such a flag for "completely building code"
>>>>> for a specific configuration.  Random example,
>>>>> '-foffload-options=nvptx-none=-march=sm_75': as GCC/nvptx target
>>>>> libraries aren't being built for '-march=sm_75' multilib,
>>>>> '-foffload-options=nvptx-none=-march=sm_75' uses the default multilib,
>>>>> which isn't '-march=sm_75'.
>>>>>
>>>>>
>>>>>>   ('gcc/config/nvptx/t-nvptx:MULTILIB_OPTIONS'
>>>>>>> etc., I suppose?)  Should we add a few representative configurations to
>>>>>>> be built by default?  And/or, should we have a way to 'configure' per
>>>>>>> user needs (I suppose: '--with-multilib-list=[...]', as supported for a
>>>>>>> few other targets?)?  (I see there's also a new
>>>>>>> '--with-multilib-generator=[...]', haven't looked in detail.)  No matter
>>>>>>> which way: again, combinatorial explosion is a problem, of course...
>>>>>>
>>>>>> As far as I know, the gcc build doesn't finish when switching default to
>>>>>> higher than sm_35, so there's little point to go to a multilib setup at
>>>>>> this point.  But once we fix that, we could reconsider, otherwise,
>>>>>> things are likely to regress again.
>>>>>
>>>>> As far as I remember, several issues have been fixed.  Still waiting for
>>>>> Roger's "middle-end: Support ABIs that pass FP values as wider integers"
>>>>> or something similar, but that PR104489 issue is being worked around by
>>>>> "Limit HFmode support to mexperimental", if I got that right.
>>>>>
>>>>> Now I'm not suggesting we should now enable all or any random GCC/nvptx
>>>>> multilibs, to get all these variants of GCC/nvptx target libraries built;
>>>>> especially also given that GCC/nvptx code generation currently doesn't
>>>>> make too much use of the new capabilities.
>>>>>
>>>>> However, we do have a specific request that a customer would like to be
>>>>> able to change at GCC 'configure' time the GCC/nvptx default multilib
>>>>> (including that being used for building corresponding GCC/nvptx target
>>>>> libraries).
>>>>>
>>

Re: [PATCH Rust front-end v1 2/4] Add Rust lang TargetHooks for i386 and x86_64

[Thomas Schwinge]

Hi!

On 2022-07-27T14:40:38+0100, "herron.philip--- via Gcc-patches" 
 wrote:
> This patch introduces a new set of interfaces to define the target info as
> expected by the rust front-end. It takes advantage of the information
> within gcc/config/target directories which gets called by the front-end
> to populate rust front-end datastructures by calling into:
> builtin_rust_info. This patch has been isolated to find if we are
> approaching this in an idiomatic way and is compilable without the
> rust-front-end code.

I suppose the general approach may be fine, as is similarly implemented
by other languages' front ends in GCC.

> We have received many patches here which gives us the target hook info for
> most platforms

But this is all so much WIP and full of TODO notes, and has no test cases
at all!, that I still don't really see much value in keeping the current
implementations of 'TARGET_RUST_CPU_INFO', 'TARGET_RUST_OS_INFO', etc.
Applying "[HACK] Disable 'TARGET_RUST_CPU_INFO', 'TARGET_RUST_OS_INFO'"
that I've attached, we're not seeing any change in 'make check-rust'
results, for example.

In my opinion, the current implementation should be backed out from the
main development branch (would also reduce pain in merges from GCC
upstream, as mentioned before), and then be developed (quite possibly
based on the current implementation) individually for all GCC
configurations that we'd like to support (with 'sorry' otherwise), in a
coherent way, instead of trying to guess all possible target options as
done by the current implementation.  And, with all relevant test cases
getting added, of course.  That is, at this time, restrict outselves to
GCC configurations that we're actually supporting and testing.

Have we even figured out which of those target options are actually
mandated for a conforming Rust programming language implementation (that
is, users would potentially rely on these)?

As far as I can tell, 'rustc' defines target options here:
<https://github.com/rust-lang/rust/tree/master/compiler/rustc_target/src/spec>,
and you may use 'rustc --print=cfg' to dump for the current
configuration?

> but getting the normal x86 done correctly will define if
> the other patches are done correctly.

Yes -- but I'm not sure this is it really, in its current WIPy,
un-tested, un-verified form:

> gcc/config/ChangeLog:

> * gnu.h: add new macro GNU_USER_TARGET_RUST_OS_INFO
>   * dragonfly.h: define TARGET_RUST_OS_INFO
>   * freebsd-spec.h: define FBSD_TARGET_RUST_OS_INFO
>   * freebsd.h: define guard for TARGET_RUST_OS_INFO
>   * fuchsia.h: define TARGET_RUST_OS_INFO
>   * kfreebsd-gnu.h: define GNU_USER_TARGET_RUST_OS_INFO
>   * kopensolaris-gnu.h: define GNU_USER_TARGET_RUST_OS_INFO
>   * linux-android.h: define ANDROID_TARGET_RUST_OS_INFO
>   * linux.h: define GNU_USER_TARGET_RUST_OS_INFO
>   * netbsd.h: define NETBSD_TARGET_RUST_OS_INFO
>   * openbsd.h: define OPENBSD_TARGET_RUST_OS_INFO
>   * phoenix.h: define TARGET_RUST_OS_INFO
>   * sol2.h: define TARGET_RUST_OS_INFO
>   * vxworks.h: define VXWORKS_TARGET_RUST_OS_INFO
>   * vxworksae.h: define VXWORKS_TARGET_RUST_OS_INFO
>
> gcc/config/i386/ChangeLog:
>
> * crtdll.h: define EXTRA_TARGET_RUST_OS_INFO
> * cygming.h: define TARGET_RUST_OS_INFO
> * cygwin.h: define EXTRA_TARGET_RUST_OS_INFO
> * darwin.h: define TARGET_RUST_OS_INFO
> * djgpp.h: likewise
> * gnu-user-common.h: define TARGET_RUST_OS_INFO
> * i386-protos.h: prototype for ix86_rust_target_cpu_info
> * i386-rust.cc: new file to generate the rust target host info
> * i386.h: define TARGET_RUST_CPU_INFO hook
> * linux-common.h: define hooks for target info
> * lynx.h: likewise
> * mingw32.h: likewise
> * netbsd-elf.h: likewise
> * netbsd64.h: likewise
> * nto.h: likewise
> * openbsdelf.h: likewise
> * rdos.h: likewise
> * rtemself.h: likewise
> * t-i386: add makefilke rule for i386-rust.cc
> * vxworks.h: define TARGET_RUST_OS_INFO


Grüße
 Thomas


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
>From a5688c5da3c9ffda614f4138e55f46b7078b9e3a Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Thu, 28 Jul 2022 12:04:28 +0200
Subject: [PATCH] [HACK] Disable 'TARGET_RUST_CPU_INFO', 'TARGET_RUST_OS_INFO'

---
 gcc/rust/rust-lang.cc| 2 ++
 gcc/rust/ru

Re: [PATCH Rust front-end v1 2/4] Add Rust lang TargetHooks for i386 and x86_64

[Thomas Schwinge]

Hi Phil!

On 2022-07-28T11:51:37+0100, Philip Herron  wrote:
> I think you are right here. There are parts in
> libstd/liballoc/libpanic which start to look for what CPU features are
> available iirc.

Aha, good.  That -- once we get there ;-) -- shall then guide us on the
target options we implement, in addition to what we find generally
necessary for a conforming Rust programming language implementation (as
I'd mentioned).

> libcore [...] just
> cares about target pointer width and endienness which is more
> generally available as macros.

Right, and these are already implemented in
'gcc/rust/rust-session-manager.cc:Session::init'.  (..., but also should
get some test cases added; I'll have a look at some point.)

> It seems more clear now that maybe for this v1 set of patches,
> possibly this stuff doesn't really matter right now until we compile
> libstd which seems like a much better approach in order to review the
> front-end code. I think i will apply your patch and revert these
> changes for now since we have the git history for them we can look at
> this more closely when we need it.

Unless this issue is time-critical, let me offer that instead of my
"[HACK] Disable 'TARGET_RUST_CPU_INFO', 'TARGET_RUST_OS_INFO'",
I'll cook up a proper patch, removing the implementations of
'TARGET_RUST_CPU_INFO', 'TARGET_RUST_OS_INFO', etc., but keeping the
general infrastructure in place (if I find that makes sense)?


Grüße
 Thomas


> On Thu, 28 Jul 2022 at 11:38, Thomas Schwinge  wrote:
>>
>> Hi!
>>
>> On 2022-07-27T14:40:38+0100, "herron.philip--- via Gcc-patches" 
>>  wrote:
>> > This patch introduces a new set of interfaces to define the target info as
>> > expected by the rust front-end. It takes advantage of the information
>> > within gcc/config/target directories which gets called by the front-end
>> > to populate rust front-end datastructures by calling into:
>> > builtin_rust_info. This patch has been isolated to find if we are
>> > approaching this in an idiomatic way and is compilable without the
>> > rust-front-end code.
>>
>> I suppose the general approach may be fine, as is similarly implemented
>> by other languages' front ends in GCC.
>>
>> > We have received many patches here which gives us the target hook info for
>> > most platforms
>>
>> But this is all so much WIP and full of TODO notes, and has no test cases
>> at all!, that I still don't really see much value in keeping the current
>> implementations of 'TARGET_RUST_CPU_INFO', 'TARGET_RUST_OS_INFO', etc.
>> Applying "[HACK] Disable 'TARGET_RUST_CPU_INFO', 'TARGET_RUST_OS_INFO'"
>> that I've attached, we're not seeing any change in 'make check-rust'
>> results, for example.
>>
>> In my opinion, the current implementation should be backed out from the
>> main development branch (would also reduce pain in merges from GCC
>> upstream, as mentioned before), and then be developed (quite possibly
>> based on the current implementation) individually for all GCC
>> configurations that we'd like to support (with 'sorry' otherwise), in a
>> coherent way, instead of trying to guess all possible target options as
>> done by the current implementation.  And, with all relevant test cases
>> getting added, of course.  That is, at this time, restrict outselves to
>> GCC configurations that we're actually supporting and testing.
>>
>> Have we even figured out which of those target options are actually
>> mandated for a conforming Rust programming language implementation (that
>> is, users would potentially rely on these)?
>>
>> As far as I can tell, 'rustc' defines target options here:
>> <https://github.com/rust-lang/rust/tree/master/compiler/rustc_target/src/spec>,
>> and you may use 'rustc --print=cfg' to dump for the current
>> configuration?
>>
>> > but getting the normal x86 done correctly will define if
>> > the other patches are done correctly.
>>
>> Yes -- but I'm not sure this is it really, in its current WIPy,
>> un-tested, un-verified form:
>>
>> > gcc/config/ChangeLog:
>>
>> > * gnu.h: add new macro GNU_USER_TARGET_RUST_OS_INFO
>> >   * dragonfly.h: define TARGET_RUST_OS_INFO
>> >   * freebsd-spec.h: define FBSD_TARGET_RUST_OS_INFO
>> >   * freebsd.h: define guard for TARGET_RUST_OS_INFO
>> >   * fuchsia.h: define TARGET_RUST_OS_INFO
>> >   * kfreebsd-g

[PING^6] nvptx: forward '-v' command-line option to assembler, linker

[Thomas Schwinge]

Hi Tom!

Ping.


Grüße
 Thomas


On 2022-07-27T17:48:46+0200, I wrote:
> Hi Tom!
>
> Ping.
>
>
> Grüße
>  Thomas
>
>
> On 2022-07-20T14:44:36+0200, I wrote:
>> Hi Tom!
>>
>> Ping.
>>
>>
>> Grüße
>>  Thomas
>>
>>
>> On 2022-07-13T10:41:23+0200, I wrote:
>>> Hi Tom!
>>>
>>> Ping.
>>>
>>>
>>> Grüße
>>>  Thomas
>>>
>>>
>>> On 2022-07-05T16:58:54+0200, I wrote:
>>>> Hi Tom!
>>>>
>>>> Ping.
>>>>
>>>>
>>>> Grüße
>>>>  Thomas
>>>>
>>>>
>>>> On 2022-06-07T17:41:16+0200, I wrote:
>>>>> Hi!
>>>>>
>>>>> On 2022-05-30T09:06:21+0200, Tobias Burnus  
>>>>> wrote:
>>>>>> On 29.05.22 22:49, Thomas Schwinge wrote:
>>>>>>> Not sure if that's what you had in mind, but what do you think about the
>>>>>>> attached "nvptx: forward '-v' command-line option to assembler, linker"?
>>>>>>> OK to push to GCC master branch (after merging
>>>>>>> <https://github.com/MentorEmbedded/nvptx-tools/pull/37>
>>>>>>> "Put '-v' verbose output onto stderr instead of stdout")?
>>>>>>
>>>>>> I was mainly thinking of some way to have it available — which
>>>>>> '-foffload-options=-Wa,-v' already permits on the GCC side. (Once the
>>>>>> nvptx-tools patch actually makes use of the '-v'.)
>>>>>
>>>>> (Merged a week ago.)
>>>>>
>>>>>> If I understand your patch correctly, this patch now causes 'gcc -v' to
>>>>>> imply 'gcc -v -Wa,-v'. I think that's okay, since 'gcc -v' already
>>>>>> outputs a lot of lines and those lines can be helpful to understand what
>>>>>> happens and what not.
>>>>>
>>>>> ACK.
>>>>>
>>>>>> Tom, your thoughts on this?
>>>>>
>>>>> Ping.
>>>>>
>>>>>
>>>>> Grüße
>>>>>  Thomas


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
>From 17c35607d4927299b0c4bd19dd6fd205c85c4a4b Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Sun, 29 May 2022 22:31:43 +0200
Subject: [PATCH] nvptx: forward '-v' command-line option to assembler, linker

For example, for offloading compilation with '-save-temps -v', before vs. after
word-diff then looks like:

[...]
 [...]/build-gcc-offload-nvptx-none/gcc/as {+-v -v+} -o ./a.xnvptx-none.mkoffload.o ./a.xnvptx-none.mkoffload.s
{+Verifying sm_30 code with sm_35 code generation.+}
{+ ptxas -c -o /dev/null ./a.xnvptx-none.mkoffload.o --gpu-name sm_35 -O0+}
[...]
 [...]/build-gcc-offload-nvptx-none/gcc/collect2 {+-v -v+} -o ./a.xnvptx-none.mkoffload [...] @./a.xnvptx-none.mkoffload.args.1 -lgomp -lgcc -lc -lgcc
{+collect2 version 12.0.1 20220428 (experimental)+}
{+[...]/build-gcc-offload-nvptx-none/gcc/collect-ld -v -v -o ./a.xnvptx-none.mkoffload [...] ./a.xnvptx-none.mkoffload.o -lgomp -lgcc -lc -lgcc+}
{+Linking ./a.xnvptx-none.mkoffload.o as 0+}
{+trying lib libc.a+}
{+trying lib libgcc.a+}
{+trying lib libgomp.a+}
{+Resolving abort+}
{+Resolving acc_on_device+}
{+Linking libgomp.a::oacc-init.o/ as 1+}
{+Linking libc.a::lib_a-abort.o/   as 2+}
[...]

(This depends on <https://github.com/MentorEmbedded/nvptx-tools/pull/37>
"Put '-v' verbose output onto stderr instead of stdout".)

	gcc/
	* config/nvptx/nvptx.h (ASM_SPEC, LINK_SPEC): Define.
---
 gcc/config/nvptx/nvptx.h | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/gcc/config/nvptx/nvptx.h b/gcc/config/nvptx/nvptx.h
index ed72c253191..b184f1d0150 100644
--- a/gcc/config/nvptx/nvptx.h
+++ b/gcc/config/nvptx/nvptx.h
@@ -27,6 +27,13 @@
 
 /* Run-time Target.  */
 
+/* Assembler supports '-v' option; handle similar to
+   '../../gcc.cc:asm_options', 'HAVE_GNU_AS'.  */
+#define ASM_SPEC "%{v}"
+
+/* Linker supports '-v' option.  */
+#define LINK_SPEC "%{v}"
+
 #define STARTFILE_SPEC "%{mmainkernel:crt0.o}"
 
 #define TARGET_CPU_CPP_BUILTINS() nvptx_cpu_cpp_builtins ()
-- 
2.25.1

[PING^5] nvptx: Allow '--with-arch' to override the default '-misa' (was: nvptx multilib setup)

[Thomas Schwinge]

Hi Tom!

Ping.


Grüße
 Thomas


On 2022-07-27T17:48:58+0200, I wrote:
> Hi Tom!
>
> Ping.
>
>
> Grüße
>  Thomas
>
>
> On 2022-07-20T14:46:03+0200, I wrote:
>> Hi Tom!
>>
>> Ping.
>>
>>
>> Grüße
>>  Thomas
>>
>>
>> On 2022-07-13T10:42:44+0200, I wrote:
>>> Hi Tom!
>>>
>>> Ping.
>>>
>>>
>>> Grüße
>>>  Thomas
>>>
>>>
>>> On 2022-07-05T16:59:23+0200, I wrote:
>>>> Hi Tom!
>>>>
>>>> Ping.
>>>>
>>>>
>>>> Grüße
>>>>  Thomas
>>>>
>>>>
>>>> On 2022-06-15T23:18:10+0200, I wrote:
>>>>> Hi Tom!
>>>>>
>>>>> On 2022-05-13T16:20:14+0200, I wrote:
>>>>>> On 2022-02-04T13:09:29+0100, Tom de Vries via Gcc  
>>>>>> wrote:
>>>>>>> On 2/4/22 08:21, Thomas Schwinge wrote:
>>>>>>>> On 2022-02-03T13:35:55+, "vries at gcc dot gnu.org via Gcc-bugs" 
>>>>>>>>  wrote:
>>>>>>>>> I've tested this using (recommended) driver 470.94 on boards:
>>>>>>
>>>>>>>>> while iterating over dimensions { -mptx=3.1 , -mptx=6.3 } x { 
>>>>>>>>> GOMP_NVPTX_JIT=-O0,  }.
>>>>>>>>
>>>>>>>> Do you use separate (nvptx-none offload target only?) builds for
>>>>>>>> different '-mptx' variants (likewise: '-misa'), or have you hacked up 
>>>>>>>> the
>>>>>>>> multilib configuration?
>>>>>>>
>>>>>>> Neither, I'm using --target_board=unix/foffload= for that.
>>>>>>
>>>>>> ACK, I see.  So these flags then only affect GCC/nvptx code generation
>>>>>> for the actual user code (here: GCC libgomp test cases), but for the
>>>>>> GCC/nvptx target libraries (such as: libc, libm, libgfortran, libgomp --
>>>>>> the latter especially relevant for OpenMP), it uses PTX code from one of
>>>>>> the two "pre-compiled" GCC/nvptx multilibs: default or '-mptx=3.1'.
>>>>>>
>>>>>> Meaning, one can't just use such a flag for "completely building code"
>>>>>> for a specific configuration.  Random example,
>>>>>> '-foffload-options=nvptx-none=-march=sm_75': as GCC/nvptx target
>>>>>> libraries aren't being built for '-march=sm_75' multilib,
>>>>>> '-foffload-options=nvptx-none=-march=sm_75' uses the default multilib,
>>>>>> which isn't '-march=sm_75'.
>>>>>>
>>>>>>
>>>>>>>   ('gcc/config/nvptx/t-nvptx:MULTILIB_OPTIONS'
>>>>>>>> etc., I suppose?)  Should we add a few representative configurations to
>>>>>>>> be built by default?  And/or, should we have a way to 'configure' per
>>>>>>>> user needs (I suppose: '--with-multilib-list=[...]', as supported for a
>>>>>>>> few other targets?)?  (I see there's also a new
>>>>>>>> '--with-multilib-generator=[...]', haven't looked in detail.)  No 
>>>>>>>> matter
>>>>>>>> which way: again, combinatorial explosion is a problem, of course...
>>>>>>>
>>>>>>> As far as I know, the gcc build doesn't finish when switching default to
>>>>>>> higher than sm_35, so there's little point to go to a multilib setup at
>>>>>>> this point.  But once we fix that, we could reconsider, otherwise,
>>>>>>> things are likely to regress again.
>>>>>>
>>>>>> As far as I remember, several issues have been fixed.  Still waiting for
>>>>>> Roger's "middle-end: Support ABIs that pass FP values as wider integers"
>>>>>> or something similar, but that PR104489 issue is being worked around by
>>>>>> "Limit HFmode support to mexperimental", if I got that right.
>>>>>>
>>>>>> Now I'm not suggesting we should now enable all or any random GCC/nvptx
>>>>>> multilibs, to get all these variants of GCC/nvptx target libraries built;
>>>>>> especially als

Re: [patch] libgomp: cuda.h and omp_target_memcpy_rect cleanup (was: [patch] OpenMP: Call cuMemcpy2D/cuMemcpy3D for nvptx for omp_target_memcpy_rect)

[Thomas Schwinge]

Hi Tobias!

On 2023-07-28T13:51:41+0200, Tobias Burnus  wrote:
> On 27.07.23 23:00, Thomas Schwinge wrote:
>>> +  else if (src_devicep != NULL
>>> +&& (dst_devicep == NULL
>>> +|| (dst_devicep->capabilities
>>> +& GOMP_OFFLOAD_CAP_SHARED_MEM)))
>> Are these 'GOMP_OFFLOAD_CAP_SHARED_MEM' actually reachable, given that
>> 'omp_target_memcpy_check' (via 'omp_target_memcpy_rect_check') clears out
>> the device to 'NULL' for 'GOMP_OFFLOAD_CAP_SHARED_MEM'?
>
> I have now undone this change – I did not dig deep enough into the
> function calls.
>
>
>>> +  else if (dst_devicep == NULL && src_devicep == NULL)
>>> + {
>>> +   memcpy ((char *) dst + dst_off, (const char *) src + src_off,
>>> +   length);
>>> +   ret = 1;
>>> + }
>>> else if (src_devicep == dst_devicep)
>>>ret = src_devicep->dev2dev_func (src_devicep->target_id,
>>> (char *) dst + dst_off,
>>> (const char *) src + src_off,
>>> length);
>> ..., but also left the intra-device case here -- which should now be dead
>> code here?
>
> Why? Unless I missed something, the old, the current, and the proposed
> (= old) code do still run this code.

It is now again reachable, but wasn't in the "intermediate state"
(without your follow-on change) -- at least per my understanding, which
may be gappy.

> I have not added an assert to confirm, but in any case, it is tested for
> in my recently added testcase - thus, we could add a 'printf' to confirm.

We're now back to the original code, which should be fine.

>>> +   else if (*tmp_size < length)
>>> + {
>>> +   *tmp_size = length;
>>> +   *tmp = realloc (*tmp, length);
>>> +   if (*tmp == NULL)
>>> + return ENOMEM;
>> If 'realloc' returns 'NULL', we should 'free' the original '*tmp'?
>>
>> Do we really need here the property here that if the re-allocation can't
>> be done in-place, 'realloc' copies the original content to the new?  In
>> other words, should we just unconditionally 'free' and re-'malloc' here,
>> instead of 'realloc'?
> I have now done so – but I am not really sure what's faster on average.
> If it can be enlarged, 'realloc' is faster, if it cannot free+malloc is
> better.

I have no proof, but would assume that the C library handles as
efficiently as 'realloc' the case of 'free' plus subsequent 'malloc' if
there's space available after the original allocation.

>> I haven't looked whether the re-use of 'tmp' for multiple calls to this
>> is then actually useful, or whether we should just always 'malloc', use,
>> 'free' the buffer here?

..., hence that suggestion.  But I agree what we've got now is good, just
one more idea: couldn't we now actually unify the (original) 'malloc' and
(original) 'realloc' case:

-if (*tmp_size == 0)
-  {
-*tmp_size = length;
-*tmp = malloc (length);
-if (*tmp == NULL)
-  return ENOMEM;
-  }
-else if (*tmp_size < length)
+if (*tmp_size < length)
   {
 *tmp_size = length;
 free (*tmp);
 *tmp = malloc (length);
 if (*tmp == NULL)
   return ENOMEM;
   }

(Untested.)

> Well, it can run in a hot loop – assume a C-array array[1024][1024][2]
> and copying array[:1024,:1024,0:1] (using OpenMP syntax) – i.e. 1048576
> times every other element. And therefore I would like to avoid repeated
> malloc/free in such a case. (But in general, interdevice copying should
> be very rare.)
>
> Actually, I think the realloc case is unreachable: for rectangular
> copies, as implied both by 'target update' with strided access and by
> 'omp_target_memcpy_rect', the size should be constant.

Worth an 'assert'?

Now I "only" don't understand the '__builtin_mul_overflow' computations
and error checks ('return EINVAL;') for the four cases handled in
'libgomp/target.c:omp_target_memcpy_rect_worker': for example, the
generic loop at end of function iterates over all 'num_dims', but the
specific earlier 'num_dims == N' cases don't.  But I suppose that's just
my own problem not understanding this API/code, and I'm not currently
planning on looking into this any further.  ;-)


Grüße
 Thomas
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955

RE: Machine Mode ICE in RISC-V when LTO

[Thomas Schwinge]

Hi!

On 2023-08-10T12:25:36+, "Li, Pan2"  wrote:
> Thanks Richard for comment, let me try to promote the table to unsigned short.

I have WIP work for this issue -- which I'd already raised a month ago:
<https://inbox.sourceware.org/87o7kxuq9s@euler.schwinge.homeip.net>:

On 2023-06-30T13:46:07+0200, Thomas Schwinge  wrote:
> In particular, the 'lto_mode_identity_table' changes would seem necessary
> to keep standard LTO ('-flto') functional for large 'machine_mode' size?

... which is exactly the problem you've now run into?

However, a simple:

-GTY(()) const unsigned char *lto_mode_identity_table;
+GTY(()) const unsigned short *lto_mode_identity_table;

..., or:

-GTY(()) const unsigned char *lto_mode_identity_table;
+GTY(()) const machine_mode *lto_mode_identity_table;

... is not sufficient: that runs into GTY issues, as the current
'unsigned char *lto_mode_identity_table' is (mis-)classified by
'gengtype' as a C string.  This happens to work for this case, but still
isn't right, and only works for 'char *' but not 'short *' etc.  I have
WIP work to tighten that.  ..., which got me into other GTY issues, and
so on...  ;-) (Richard already ACKed and I pushed some of the
prerequisite changes, but there's more to come.)  I'm still planning on
resolving all that mess, but I'm tight on time right now.

However, I have a different proposal, which should address your current
issue: simply, get rid of the 'lto_mode_identity_table', which is just
that: a 1-to-1 mapping of array index to value.  Instead, in
'gcc/lto/lto-common.cc:lto_file_finalize', for '!ACCEL_COMPILER', set
'file_data->mode_table = NULL', and in the users (only
'gcc/tree-streamer.h:bp_unpack_machine_mode'?), replace (untested):

-return (machine_mode) ib->file_data->mode_table[ix];
+return ib->file_data->mode_table ? ib->file_data->mode_table[ix] : ix;

Jakub, as the original author of 'lto_mode_identity_table' (see
commit db847fa8f2cca6139188b8dfa0a7064319b19193 (Subversion r221005)), is
there any reason not to do it this way?


Grüße
 Thomas


> -Original Message-
> From: Richard Biener 
> Sent: Thursday, August 10, 2023 7:08 PM
> To: Li, Pan2 
> Cc: richard.sandif...@arm.com; Thomas Schwinge ; 
> ja...@redhat.com; kito.ch...@gmail.com; Jeff Law ; 
> juzhe.zh...@rivai.ai; Wang, Yanzhang 
> Subject: Re: Machine Mode ICE in RISC-V when LTO
>
> On Thu, Aug 10, 2023 at 10:19 AM Li, Pan2  wrote:
>>
>> Hi all,
>>
>>
>>
>> Recently I found there is still some issues for the machine mode with LTO 
>> part by fixing one
>>
>> ICE (only when compile with LTO) in RISC-V backend in , aka below case.
>>
>>
>>
>> >> ../__RISC-V_INSTALL___/bin/riscv64-unknown-elf-g++ -O2 -flto 
>> >> gcc/testsuite/g++.dg/torture/vshuf-v4df.C -o test.elf
>>
>> during RTL pass: expand
>>
>> gcc/testsuite/g++.dg/torture/vshuf-main.inc: In function 'main':
>>
>> gcc/testsuite/g++.dg/torture/vshuf-main.inc:15:9: internal compiler error: 
>> in as_a, at machmode.h:381
>>
>>15 |   V r = __builtin_shuffle(in1[i], mask1[i]);
>>
>>   | ^
>>
>> 0x7e5b8e scalar_int_mode as_a(machine_mode)
>>
>> ../.././gcc/gcc/machmode.h:381
>>
>> 0x7eabdb scalar_mode as_a(machine_mode)
>>
>> ../.././gcc/gcc/expr.cc:332
>>
>> 0x7eabdb convert_mode_scalar
>>
>> ../.././gcc/gcc/expr.cc:325
>>
>> 0xb8485b store_expr(tree_node*, rtx_def*, int, bool, bool)
>>
>> ../.././gcc/gcc/expr.cc:6413
>>
>> 0xb8a556 store_field
>>
>> ../.././gcc/gcc/expr.cc:7648
>>
>> 0xb88f27 store_constructor(tree_node*, rtx_def*, int, poly_int<2u, long>, 
>> bool)
>>
>> ../.././gcc/gcc/expr.cc:7588
>>
>> 0xb8b8b8 expand_constructor
>>
>> ../.././gcc/gcc/expr.cc:8931
>>
>> 0xb76bc7 expand_expr_real_1(tree_node*, rtx_def*, machine_mode, 
>> expand_modifier, rtx_def**, bool)
>>
>> ../.././gcc/gcc/expr.cc:11170
>>
>> 0xb77ef7 expand_expr_real_1(tree_node*, rtx_def*, machine_mode, 
>> expand_modifier, rtx_def**, bool)
>>
>> ../.././gcc/gcc/expr.cc:10809
>>
>> 0xb83a80 store_expr(tree_node*, rtx_def*, int, bool, bool)
>>
>> ../.././gcc/gcc/expr.cc:6325
>>
>> 0xb851d9 expand_assignment(tree_node*, tree_node*, bool)
>>
>> ../.././gcc/gcc/expr.cc:6043
>>
>> 0xa48717 expand_gimple_stmt_1
&

[v3] OpenACC 2.7: default clause support for data constructs (was: [PATCH, OpenACC 2.7, v2] Implement default clause support for data constructs)

[Thomas Schwinge]

Hi!

On 2023-08-01T23:35:16+0800, Chung-Lin Tang  wrote:
> this is v2 of the patch for implementing the OpenACC 2.7 addition of
> default(none|present) support for data constructs.

Thanks!

> Instead of propagating an additional 'oacc_default_kind' for OpenACC,
> this patch does it in a more complete way: it directly propagates the
> gimplify_omp_ctx* pointer of the inner most context where we found
> a default-clause.

Right -- but reviewing this, it came upon me that we don't need any such
new code at all, and instead may in 'gcc/gimplify.cc:oacc_default_clause'
simply look through the 'ctx's to find the 'default' clause information.
This centralizes the logic in the one place where it's relevant.

> This supports displaying the location/type of OpenACC
> construct where the default-clause is in the error messages.

This is preserved...

> The testcases also have the multiple nested data construct testing added,
> where we can now have messages referring precisely to the exact innermost
> default clause that was active at that program point.

..., but we should also still 'inform' about the compute construct, where
the user is expected to add explicit data clauses (if not adding to the
'data' construct where the 'default(none)' clause appears):

> --- a/gcc/gimplify.cc
> +++ b/gcc/gimplify.cc

> @@ -7785,16 +7809,20 @@ oacc_default_clause (struct gimplify_omp_ctx *ctx, 
> tree decl, unsigned flags)

> -  else if (ctx->default_kind == OMP_CLAUSE_DEFAULT_NONE)
> +  else if (default_kind == OMP_CLAUSE_DEFAULT_NONE)
>  {
>error ("%qE not specified in enclosing OpenACC %qs construct",
> -  DECL_NAME (lang_hooks.decls.omp_report_decl (decl)), rkind);
> -  inform (ctx->location, "enclosing OpenACC %qs construct", rkind);
> -}
> -  else if (ctx->default_kind == OMP_CLAUSE_DEFAULT_PRESENT)
> +  DECL_NAME (lang_hooks.decls.omp_report_decl (decl)),
> +  oacc_region_type_name (ctx->region_type));
> +  inform (ctx->oacc_default_clause_ctx->location,
> +   "enclosing OpenACC %qs construct",
> +   oacc_region_type_name
> +   (ctx->oacc_default_clause_ctx->region_type));
> +}

That is, we should keep here the original 'inform' for 'ctx->location',
and *add another* 'inform' for 'ctx->oacc_default_clause_ctx->location'.
Otherwise that's confusing to users.

Instead of requiring another iteration through you, I've now implemented
that, and with test cases enhanced some more, pushed to master branch
commit bed993884b149851fe930b43cf11cbcdf05f1578
"OpenACC 2.7: default clause support for data constructs", see attached.


Grüße
 Thomas


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
>From bed993884b149851fe930b43cf11cbcdf05f1578 Mon Sep 17 00:00:00 2001
From: Chung-Lin Tang 
Date: Tue, 6 Jun 2023 03:46:29 -0700
Subject: [PATCH] OpenACC 2.7: default clause support for data constructs

This patch implements the OpenACC 2.7 addition of default(none|present) support
for data constructs.

Now, specifying "default(none|present)" on a data construct turns on same
default clause behavior for all lexically enclosed compute constructs (which
don't already themselves have a default clause).

gcc/c/ChangeLog:
	* c-parser.cc (OACC_DATA_CLAUSE_MASK): Add PRAGMA_OACC_CLAUSE_DEFAULT.

gcc/cp/ChangeLog:
	* parser.cc (OACC_DATA_CLAUSE_MASK): Add PRAGMA_OACC_CLAUSE_DEFAULT.

gcc/fortran/ChangeLog:
	* openmp.cc (OACC_DATA_CLAUSES): Add OMP_CLAUSE_DEFAULT.

gcc/ChangeLog:
	* gimplify.cc (oacc_region_type_name): New function.
	(oacc_default_clause): If no 'default' clause appears on this
	compute construct, see if one appears on a lexically containing
	'data' construct.
	(gimplify_scan_omp_clauses): Upon OMP_CLAUSE_DEFAULT case, set
	ctx->oacc_default_clause_ctx to current context.

gcc/testsuite/ChangeLog:
	* c-c++-common/goacc/default-3.c: Adjust testcase.
	* c-c++-common/goacc/default-4.c: Adjust testcase.
	* c-c++-common/goacc/default-5.c: Adjust testcase.
	* gfortran.dg/goacc/default-3.f95: Adjust testcase.
	* gfortran.dg/goacc/default-4.f: Adjust testcase.
	* gfortran.dg/goacc/default-5.f: Adjust testcase.

Co-authored-by: Thomas Schwinge 
---
 gcc/c/c-parser.cc |  1 +
 gcc/cp/parser.cc  |  1 +
 gcc/fortran/openmp.cc |  3 +-
 gcc/gimplify.cc   | 64 +++
 gcc/testsuite/c-c++-common/goacc/default-3.c  | 

Re: [PATCH, OpenACC 2.7] Implement host_data must have use_device clause requirement

[Thomas Schwinge]

Hi Chung-Lin!

On 2023-06-06T23:10:37+0800, Chung-Lin Tang  wrote:
> this patch implements the OpenACC 2.7 change requiring the host_data construct
> to have at least one use_device clause.

Thanks!

> This patch started out with a simple check during gimplify (much smaller 
> patch),

Heh, thanks for the explanation -- would've been my first question
otherweise.  ;-)

> but turned out that front-ends removed use_device clauses when they have 
> error,
> and the gimplify check started to echo a "no use_device clause" message in 
> such
> cases, which seem confusing for the user. So ended up adding the check in each
> front-end instead.

I presume that's also the reason why you're doing this check before
'c_finish_omp_clauses' etc.?

I'll clarify with the OpenACC Technical Committee whether really those
diagnostics are intended as "error" or should instead just be "warning".
After all, there's no actual problem with an OpenACC 'host_data' without
'use_device' clause (or no data clause on OpenACC 'data', 'enter data',
'exit data', 'update', etc.) -- it's just likely that the user missed
something.  That is, the OpenACC 2.7: "At least one 'use_device' clause
must appear" is addressing the user, not at the implementation (in my
current interpretation).  Depending on the outcome of that, we can easily
adjust GCC.

Note for later, independently of your work here:
'c_parser_oacc_enter_exit_data' etc. for its corresponding "has no data
movement clause" diagnostic actually does 'c_finish_omp_clauses' etc.
first -- maybe that should be changed accordingly.  (Actually, I note
that it's only OpenACC 3.0 that "Required at least one data clause on a
'data' construct, an 'enter data' directive, or an 'exit data'
directive", heh...  Per his internal 2014-10-17 email, Cesar implemented
the code of 'c_parser_oacc_enter_exit_data' etc. "similar to that of acc
update", which indeed already back then did require "At least one 'self',
'host', or 'device' clause".  Fortran does have the diagnostic for
OpenACC 'update', but it's missing for OpenACC 'enter data', 'exit data'
without data clause (have not checked other constructs with similar
requirements).)

> Tested on powerpc64le-linux/nvptx, x86_64-linux/amdgcn tests in progress 
> (expect
> no surprises). Is this okay for trunk?

OK with one small change, please -- unless there's a reason for doing it
this way:

> --- a/gcc/fortran/trans-openmp.cc
> +++ b/gcc/fortran/trans-openmp.cc
> @@ -4677,6 +4677,12 @@ gfc_trans_oacc_construct (gfc_code *code)
>   break;
>case EXEC_OACC_HOST_DATA:
>   construct_code = OACC_HOST_DATA;
> + if (code->ext.omp_clauses->lists[OMP_LIST_USE_DEVICE] == NULL)
> +   {
> + error_at (gfc_get_location (&code->loc),
> +   "% construct requires % clause");
> + return NULL_TREE;
> +   }
>   break;
>default:
>   gcc_unreachable ();

The OpenMP "must contain at least one [...] clause" checks are done in
'gcc/fortran/openmp.cc:resolve_omp_clauses'.  For consistency (or, to let
'gcc/fortran/trans-openmp.cc' continue to just deal with "directive
translation"), do similar for OpenACC 'host_data'?  (..., and we later
accordingly adjust 'gcc/fortran/openmp.cc:gfc_match_oacc_update', too?)


Grüße
 Thomas
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955

Re: [committed] libgomp: Fix OMP_TARGET_OFFLOAD=mandatory

[Thomas Schwinge]

Hi Tobias!

On 2023-06-16T17:57:10+0200, Tobias Burnus  wrote:
> Found an order problem caused by my r14-1801-g18c8b56c7d67a9 due to
> ordering issues related to the offloading initialization
> (gomp_init_targets_once).
>
> The testsuite did test various ways but only code such paths that
> initialized the library before ...
>
> Committed as Rev. r14-1893-g8216ca85037be9.

> commit 8216ca85037be9f4d5c20540522a22a4a93b660e
> Author: Tobias Burnus 
> Date:   Fri Jun 16 17:21:59 2023 +0200
>
> libgomp: Fix OMP_TARGET_OFFLOAD=mandatory
>
> It turned out that gomp_init_targets_once() was not run when directly
> calling 'omp target' or 'omp target (enter/exit) data' causing an
> abort with OMP_TARGET_OFFLOAD=mandatory wrongly claiming that no
> device is available. It was called a tiny bit later but few lines too
> late for updating the default-device-var.
>
> libgomp/ChangeLog:
>
> * target.c (resolve_device): Call gomp_get_num_devices early to 
> ensure
> gomp_init_targets_once was called before using default-device-var.

> --- a/libgomp/target.c
> +++ b/libgomp/target.c
> @@ -138,6 +138,10 @@ gomp_get_num_devices (void)
>  static struct gomp_device_descr *
>  resolve_device (int device_id, bool remapped)
>  {
> +  /* Get number of devices and thus ensure that 'gomp_init_targets_once' was
> + called, which must be done before using default_device_var.  */
> +  int num_devices = gomp_get_num_devices ();
> +
>if (remapped && device_id == GOMP_DEVICE_ICV)
>  {
>struct gomp_task_icv *icv = gomp_icv (false);
> @@ -151,7 +155,7 @@ resolve_device (int device_id, bool remapped)
>: omp_initial_device))
>   return NULL;
>if (gomp_target_offload_var == GOMP_TARGET_OFFLOAD_MANDATORY
> -   && gomp_get_num_devices () == 0)
> +   && num_devices == 0)
>   gomp_fatal ("OMP_TARGET_OFFLOAD is set to MANDATORY, "
>   "but only the host device is available");
>else if (device_id == omp_invalid_device)
> @@ -162,10 +166,10 @@ resolve_device (int device_id, bool remapped)
>
>return NULL;
>  }
> -  else if (device_id >= gomp_get_num_devices ())
> +  else if (device_id >= num_devices)
>  {
>if (gomp_target_offload_var == GOMP_TARGET_OFFLOAD_MANDATORY
> -   && device_id != num_devices_openmp)
> +   && device_id != num_devices)
>   gomp_fatal ("OMP_TARGET_OFFLOAD is set to MANDATORY, "
>   "but device not found");

I see the new tests PASS, but with offloading enabled (nvptx) also see:

PASS: libgomp.c/target-51.c (test for excess errors)
PASS: libgomp.c/target-51.c execution test
[-PASS:-]{+FAIL:+} libgomp.c/target-51.c output pattern test

... due to:

Output was:

libgomp: OMP_TARGET_OFFLOAD is set to MANDATORY, but device cannot be used 
for offloading

Should match:
.*libgomp: OMP_TARGET_OFFLOAD is set to MANDATORY, but device not found.*


Grüße
 Thomas


> diff --git a/libgomp/testsuite/libgomp.c/target-55.c 
> b/libgomp/testsuite/libgomp.c/target-55.c
> new file mode 100644
> index 000..1314b3c6963
> --- /dev/null
> +++ b/libgomp/testsuite/libgomp.c/target-55.c
> @@ -0,0 +1,20 @@
> +/* { dg-do run { target { offload_device } } } */
> +/* { dg-set-target-env-var OMP_TARGET_OFFLOAD "mandatory" } */
> +
> +/* Should pass - see target-55a.c for !offload_device */
> +
> +/* Check OMP_TARGET_OFFLOAD - it shall run on systems with offloading
> +   devices available and fail otherwise.  Note that this did always
> +   fail - as the device handling wasn't initialized before doing the
> +   mandatory checking.  */
> +
> +int
> +main ()
> +{
> +  int x = 1;
> +  #pragma omp target map(tofrom: x)
> +x = 5;
> +  if (x != 5)
> +__builtin_abort ();
> +  return 0;
> +}
> diff --git a/libgomp/testsuite/libgomp.c/target-55a.c 
> b/libgomp/testsuite/libgomp.c/target-55a.c
> new file mode 100644
> index 000..53978c3f405
> --- /dev/null
> +++ b/libgomp/testsuite/libgomp.c/target-55a.c
> @@ -0,0 +1,23 @@
> +/* { dg-do run { target { ! offload_device } } } */
> +/* { dg-set-target-env-var OMP_TARGET_OFFLOAD "mandatory" } */
> +
> +/* Should fail - see target-55a.c for offload_device */
> +
> +/* { dg-shouldfail "omp_invalid_device" } */
> +/* { dg-output ".*libgomp: OMP_TARGET_OFFLOAD is set to MANDATORY, but only 
> the host device is available.*" } */
> +
> +/* Check OMP_TARGET_OFFLOAD - it shall run on systems with offloading
> +   devices available and fail otherwise.  Note that this did always
> +   fail - as the device handling wasn't initialized before doing the
> +   mandatory checking.  */
> +
> +int
> +main ()
> +{
> +  int x = 1;
> +  #pragma omp target map(tofrom: x)
> +x = 5;
> +  if (x != 5)
> +__builtin_abort ();
> +  return 0;
> +}
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Ge

Re: [PATCH 2/2] rust: update usage of TARGET_AIX to TARGET_AIX_OS

[Thomas Schwinge]

Hi Paul!

On 2023-06-16T11:00:02-0500, "Paul E. Murphy via Gcc-patches" 
 wrote:
> This was noticed when fixing the gccgo usage of the macro, the
> rust usage is very similar.
>
> TARGET_AIX is defined as a non-zero value on linux/powerpc64le
> which may cause unexpected behavior.  TARGET_AIX_OS should be
> used to toggle AIX specific behavior.
>
> gcc/rust/ChangeLog:
>
>   * rust-object-export.cc [TARGET_AIX]: Rename and update
>   usage to TARGET_AIX_OS.

I don't have rights to formally approve this GCC/Rust change, but I'll
note that it follows "as obvious" (see
, "Obvious fixes") to the
corresponding GCC/Go change, which has been approved:
,
and which is where this GCC/Rust code has been copied from, so I suggest
you push both patches at once.


Grüße
 Thomas


> ---
>  gcc/rust/rust-object-export.cc | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/gcc/rust/rust-object-export.cc b/gcc/rust/rust-object-export.cc
> index 1143c767784..f9a395f6964 100644
> --- a/gcc/rust/rust-object-export.cc
> +++ b/gcc/rust/rust-object-export.cc
> @@ -46,8 +46,8 @@
>  #define RUST_EXPORT_SECTION_NAME ".rust_export"
>  #endif
>
> -#ifndef TARGET_AIX
> -#define TARGET_AIX 0
> +#ifndef TARGET_AIX_OS
> +#define TARGET_AIX_OS 0
>  #endif
>
>  /* Return whether or not GCC has reported any errors.  */
> @@ -91,7 +91,7 @@ rust_write_export_data (const char *bytes, unsigned int 
> size)
>  {
>gcc_assert (targetm_common.have_named_sections);
>sec = get_section (RUST_EXPORT_SECTION_NAME,
> -  TARGET_AIX ? SECTION_EXCLUDE : SECTION_DEBUG, NULL);
> +  TARGET_AIX_OS ? SECTION_EXCLUDE : SECTION_DEBUG, NULL);
>  }
>
>switch_to_section (sec);
> --
> 2.31.1
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955

Fix DejaGnu directive syntax error in 'libgomp.c/target-51.c' (was: [committed] libgomp.c/target-51.c: Accept more error-msg variants in dg-output (was: Re: [committed] libgomp: Fix OMP_TARGET_OFFLOAD

[Thomas Schwinge]

Hi!

On 2023-06-19T10:02:58+0200, Tobias Burnus  wrote:
> On 16.06.23 22:42, Thomas Schwinge wrote:
>> I see the new tests PASS, but with offloading enabled (nvptx) also see:
>>
>>  PASS: libgomp.c/target-51.c (test for excess errors)
>>  PASS: libgomp.c/target-51.c execution test
>>  [-PASS:-]{+FAIL:+} libgomp.c/target-51.c output pattern test
>>
>> ... due to:
>>
>>  Output was:
>>
>>  libgomp: OMP_TARGET_OFFLOAD is set to MANDATORY, but device cannot be 
>> used for offloading
>>
>>  Should match:
>>  .*libgomp: OMP_TARGET_OFFLOAD is set to MANDATORY, but device not 
>> found.*
>
> Thanks for the report. I can offer yet another wording for the same program – 
> and also
> with nvptx enabled:
>
> libgomp: OMP_TARGET_OFFLOAD is set to MANDATORY, but device cannot be used 
> for offloading
>
> And I can also offer (which is already in the testcase with "! 
> offload_device"):
>
> libgomp: OMP_TARGET_OFFLOAD is set to MANDATORY, but only the host device is 
> available
>
> I think I will just match "..., but .*" without distinguishing 
> check_effective_target_* ...
>
> ... which I now did in commit r14-1926-g01fe115ba7eafe (see also attached 
> patch).

Pushed commit de2d3b69eefde005759279d6739d9a0dbd2a05cc
"Fix DejaGnu directive syntax error in 'libgomp.c/target-51.c'",
see attached.


Grüße
 Thomas


> * * *
>
> With offloading, there are simply too many possibilities:
>
> * Not compiled with offloading support - vs. with (ENABLE_OFFLOADING)
> * Support compiled in but either compiler or library support not installed
>(requires configuring with --enable-offload-defaulted)
> * Offloading libgomp plugins there but no CUDA or hsa runtime libraries
> * The latter being installed but no device available
>
> Plus -foffload=disable or only enabling an (at runtime) unavailable or
> unsupported device type or other issues like CUDA and device present but
> an issue with the kernel driver (or similar half-broken states) or ...
>
> [And with remote testing issues related to dg-set-target-env-var and only
> few systems supporting offloading, a full test coverage is even harder.]
>
> Tobias


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
>From de2d3b69eefde005759279d6739d9a0dbd2a05cc Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Mon, 19 Jun 2023 12:20:15 +0200
Subject: [PATCH] Fix DejaGnu directive syntax error in 'libgomp.c/target-51.c'

ERROR: libgomp.c/target-51.c: unknown dg option: \} for "}"

Fix-up for recent commit 01fe115ba7eafebcf97bbac9e157038a003d0c85
"libgomp.c/target-51.c: Accept more error-msg variants in dg-output".

	libgomp/
	* testsuite/libgomp.c/target-51.c: Fix DejaGnu directive syntax
	error.
---
 libgomp/testsuite/libgomp.c/target-51.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libgomp/testsuite/libgomp.c/target-51.c b/libgomp/testsuite/libgomp.c/target-51.c
index db0363bfc14..7ff8122861f 100644
--- a/libgomp/testsuite/libgomp.c/target-51.c
+++ b/libgomp/testsuite/libgomp.c/target-51.c
@@ -9,7 +9,7 @@
 
 /* See comment in target-50.c/target-50.c for why the output differs.  */
 
-/* { dg-output ".*libgomp: OMP_TARGET_OFFLOAD is set to MANDATORY, but .*" } } */
+/* { dg-output ".*libgomp: OMP_TARGET_OFFLOAD is set to MANDATORY, but .*" } */
 
 int
 main ()
-- 
2.34.1

Re: [committed] amdgcn: minimal V64TImode vector support

[Thomas Schwinge]

Hi!

On 2023-06-19T12:37:52+0100, Andrew Stubbs  wrote:
> This patch adds just enough TImode vector support to use them for moving
> data about.

Andrew tells me this need not be worried about, but -- for my future self
searching email archives for FAILs/ICEs -- I'd like to at least document
here that commit 8aeabd9f63d8a54a5fa0b038ad4425a999e1cc75
"amdgcn: minimal V64TImode vector support" in '-march=gfx90a' testing
does regress:

[-PASS:-]{+FAIL: gcc.dg/pr78526.c (internal compiler error: in 
extract_insn, at recog.cc:2791)+}
{+FAIL:+} gcc.dg/pr78526.c (test for excess errors)

[...]/gcc/testsuite/gcc.dg/pr78526.c: In function 'foo':
[...]/gcc/testsuite/gcc.dg/pr78526.c:21:1: error: unrecognizable insn:
(insn 41 40 42 8 (set (reg:V4TI 443)
(vec_merge:V4TI (vec_duplicate:V4TI (reg:TI 433))
(reg:V4TI 443)
(ashift (const_int 1 [0x1])
(const_int 0 [0] 
"[...]/gcc/testsuite/gcc.dg/pr78526.c":13:11 -1
 (nil))
during RTL pass: vregs
[...]/gcc/testsuite/gcc.dg/pr78526.c:21:1: internal compiler error: in 
extract_insn, at recog.cc:2791
0x73d9f9 _fatal_insn(char const*, rtx_def const*, char const*, int, char 
const*)
[...]/gcc/rtl-error.cc:108
0x73da7a _fatal_insn_not_found(rtx_def const*, char const*, int, char 
const*)
[...]/gcc/rtl-error.cc:116
0xeb019e extract_insn(rtx_insn*)
[...]/gcc/recog.cc:2791
0xb2683c instantiate_virtual_regs_in_insn
[...]/gcc/function.cc:1611
0xb2683c instantiate_virtual_regs
[...]/gcc/function.cc:1984
0xb2683c execute
[...]/gcc/function.cc:2033

Similarly:

[-PASS:-]{+FAIL: gcc.dg/pr78540.c (internal compiler error: in 
extract_insn, at recog.cc:2791)+}
{+FAIL:+} gcc.dg/pr78540.c (test for excess errors)

[...]/gcc/testsuite/gcc.dg/pr78540.c: In function 'bar':
[...]/gcc/testsuite/gcc.dg/pr78540.c:27:1: error: unrecognizable insn:
(insn 68 67 69 2 (set (reg:V4TI 472)
(vec_merge:V4TI (vec_duplicate:V4TI (reg:TI 464))
(reg:V4TI 472)
(ashift (const_int 1 [0x1])
(reg:SI 474 
"[...]/gcc/testsuite/gcc.dg/pr78540.c":25:21 discrim 1 -1
 (nil))
during RTL pass: vregs
[...]/gcc/testsuite/gcc.dg/pr78540.c:27:1: internal compiler error: in 
extract_insn, at recog.cc:2791
0x73d9f9 _fatal_insn(char const*, rtx_def const*, char const*, int, char 
const*)
[...]/gcc/rtl-error.cc:108
0x73da7a _fatal_insn_not_found(rtx_def const*, char const*, int, char 
const*)
[...]/gcc/rtl-error.cc:116
0xeb019e extract_insn(rtx_insn*)
[...]/gcc/recog.cc:2791
0xb2683c instantiate_virtual_regs_in_insn
[...]/gcc/function.cc:1611
0xb2683c instantiate_virtual_regs
[...]/gcc/function.cc:1984
0xb2683c execute
[...]/gcc/function.cc:2033

Differently:

[-PASS:-]{+FAIL: gcc.dg/pr78575.c (internal compiler error: in 
gen_ds_bpermutevNm, at config/gcn/gcn.cc:1377)+}
{+FAIL:+} gcc.dg/pr78575.cg/ (test for excess errors)

during RTL pass: expand
[...]/gcc/testsuite/gcc.dg/pr78575.c: In function 'foo':
[...]/gcc/testsuite/gcc.dg/pr78575.c:10:1: internal compiler error: in 
gen_ds_bpermutevNm, at config/gcn/gcn.cc:1377
0x1390c33 gen_ds_bpermutevNm
[...]/gcc/config/gcn/gcn.cc:1376
0x13a0f3a gcn_vectorize_vec_perm_const
[...]/gcc/config/gcn/gcn.cc:4867
0xded44b expand_vec_perm_const(machine_mode, rtx_def*, rtx_def*, 
int_vector_builder > const&, machine_mode, rtx_def*)
[...]/gcc/optabs.cc:6456
0xaae98d expand_expr_real_2(separate_ops*, rtx_def*, machine_mode, 
expand_modifier)
[...]/gcc/expr.cc:10446
0x941803 expand_gimple_stmt_1
[...]/gcc/cfgexpand.cc:3984
0x941803 expand_gimple_stmt
[...]/gcc/cfgexpand.cc:4044
0x942eba expand_gimple_basic_block
[...]/gcc/cfgexpand.cc:6096
0x9453d3 execute
[...]/gcc/cfgexpand.cc:6831

That's all.  ;-)


Grüße
 Thomas


> This is primarily for the use of divmodv64di4, which will
> use TImode to return a pair of DImode values.
>
> The TImode vectors have no other operators defined, and there are no
> hardware instructions to support this mode, beyond load and store.
>
> Committed to mainline, and OG13 will follow shortly.
>
> Andrew

> amdgcn: minimal V64TImode vector support
>
> Just enough support for TImode vectors to exist, load, store, move,
> without any real instructions available.
>
> This is primarily for the use of divmodv64di4, which uses TImode to
> return a pair of DImode values.
>
> gcc/ChangeLog:
>
>   * config/gcn/gcn-protos.h (vgpr_4reg_mode_p): New function.
>   * config/gcn/gcn-valu.md (V_4REG, V_4REG_ALT): New iterators.
>   (V_MOV, V_MOV_ALT): Likewise.
>   (scalar_mode, SCALAR_MODE): Add TImode.
>   (vnsi, VnSI, vndi, VnDI)

Re: [PATCH, OpenACC 2.7] Implement default clause support for data constructs

[Thomas Schwinge]

Hi Chung-Lin!

On 2023-06-06T23:11:55+0800, Chung-Lin Tang  wrote:
> this patch implements the OpenACC 2.7 addition of default(none|present) 
> support
> for data constructs.

Thanks!

It wasn't clear to me what is supposed to happen, for example, for:

#pragma acc data default(none)
{
  #pragma acc data // no 'default' clause
  {
#pragma acc parallel

Specifically, does the "no 'default' clause" inner 'data' construct
invalidate the 'default(none)' clause of the outer 'data' construct?

In later revisions of the OpenACC specification, wording for 'default'
clause etc. generally has been changed; for example, OpenACC 3.3,
2.6.2 "Variables with Implicitly Determined Data Attributes" defines:

*Visible 'default' clause*: The nearest 'default' clause appearing on the 
compute construct or a lexically containing 'data' construct.

Therefore, in the example above, the 'default(none)' still holds.

> Apart from adjusting the front-ends for allowed clauses masks (for acc data),
> mostly implemented in gimplify.

ACK ('s%mostly%%') -- but a little bit differently, please:

> From 101305aee9b27c6df00d7c403e469bdf8d7f45a4 Mon Sep 17 00:00:00 2001
> From: Chung-Lin Tang 
> Date: Tue, 6 Jun 2023 03:46:29 -0700
> Subject: [PATCH 2/2] OpenACC 2.7: default clause support for data constructs
>
> This patch implements the OpenACC 2.7 addition of default(none|present) 
> support
> for data constructs.
>
> Now, specifying "default(none|present)" on a data construct turns on same
> default clause behavior for all enclosed compute constructs (which don't
> already themselves have a default clause).

Please say "lexically enclosed" -- it's that only, not any dynamic
extent.

> --- a/gcc/gimplify.cc
> +++ b/gcc/gimplify.cc
> @@ -225,6 +225,7 @@ struct gimplify_omp_ctx
>vec loop_iter_var;
>location_t location;
>enum omp_clause_default_kind default_kind;
> +  enum omp_clause_default_kind oacc_data_default_kind;
>enum omp_region_type region_type;
>enum tree_code code;
>bool combined_loop;
> @@ -459,6 +460,8 @@ new_omp_context (enum omp_region_type region_type)
>  c->default_kind = OMP_CLAUSE_DEFAULT_SHARED;
>else
>  c->default_kind = OMP_CLAUSE_DEFAULT_UNSPECIFIED;
> +  if (gimplify_omp_ctxp)
> +c->oacc_data_default_kind = gimplify_omp_ctxp->oacc_data_default_kind;
>c->defaultmap[GDMK_SCALAR] = GOVD_MAP;
>c->defaultmap[GDMK_SCALAR_TARGET] = GOVD_MAP;
>c->defaultmap[GDMK_AGGREGATE] = GOVD_MAP;

Instead of adding a new 'oacc_data_default_kind' to 'gimplify_omp_ctx',
let's please do this the other way round:

> @@ -12050,6 +12053,8 @@ gimplify_scan_omp_clauses (tree *list_p, gimple_seq 
> *pre_p,
>
>   case OMP_CLAUSE_DEFAULT:
> ctx->default_kind = OMP_CLAUSE_DEFAULT_KIND (c);

Here, we already preserve 'default' for whichever OMP construct.

> +   if (code == OACC_DATA)
> + ctx->oacc_data_default_kind = OMP_CLAUSE_DEFAULT_KIND (c);
> break;
>
>   case OMP_CLAUSE_INCLUSIVE:
> @@ -12098,6 +12103,21 @@ gimplify_scan_omp_clauses (tree *list_p, gimple_seq 
> *pre_p,
>   list_p = &OMP_CLAUSE_CHAIN (c);
>  }
>
> +  if ((code == OACC_PARALLEL
> +   || code == OACC_KERNELS
> +   || code == OACC_SERIAL)
> +  && ctx->default_kind == OMP_CLAUSE_DEFAULT_SHARED
> +  && ctx->oacc_data_default_kind != OMP_CLAUSE_DEFAULT_UNSPECIFIED)
> +{
> +  ctx->default_kind = ctx->oacc_data_default_kind;
> +
> +  /* Append actual default clause on compute construct. Not really needed
> +  for omp_notice_variable to work properly, but for debug dump files.  */
> +  c = build_omp_clause (UNKNOWN_LOCATION, OMP_CLAUSE_DEFAULT);
> +  OMP_CLAUSE_DEFAULT_KIND (c) = ctx->oacc_data_default_kind;
> +  *list_p = c;
> +}
> +
>ctx->clauses = *orig_list_p;
>gimplify_omp_ctxp = ctx;
>  }

Instead of this, in 'gimplify_omp_workshare', before the
'gimplify_scan_omp_clauses' call, do something like:

if ((ort & ORT_ACC)
&& !omp_find_clause (OMP_CLAUSES (expr), OMP_CLAUSE_DEFAULT))
  {
/* Determine effective 'default' clause for OpenACC compute construct.  
*/
for (struct gimplify_omp_ctx *ctx = gimplify_omp_ctxp; ctx; ctx = 
ctx->outer_context)
  {
if (ctx->region_type == ORT_ACC_DATA
&& ctx->default_kind != OMP_CLAUSE_DEFAULT_SHARED)
  {
[Append actual default clause on compute construct.]
break;
  }
  }
  }

That seems conceptually simpler to me?

For the 'build_omp_clause', does using 'ctx->location' instead of
'UNKNOWN_LOCATION' help diagnostics in any way?  Like if we add in
'gcc/gimplify.cc:oacc_default_clause',
'if (ctx->default_kind == OMP_CLAUSE_DEFAULT_NONE)' another 'inform' to
point to the 'data' construct's 'default' clause?  (But not sure if
that's easily done; otherwise don't.)

Similar to the ones you've already got, please also add a few test cases
for n

Re: [PATCH v3] Streamer: Fix out of range memory access of machine mode

[Thomas Schwinge]

Hi!

On 2023-06-21T15:58:24+0800, Pan Li via Gcc-patches  
wrote:
> We extend the machine mode from 8 to 16 bits already. But there still
> one placing missing from the streamer. It has one hard coded array
> for the machine code like size 256.
>
> In the lto pass, we memset the array by MAX_MACHINE_MODE count but the
> value of the MAX_MACHINE_MODE will grow as more and more modes are
> added. While the machine mode array in tree-streamer still leave 256 as is.
>
> Then, when the MAX_MACHINE_MODE is greater than 256, the memset of
> lto_output_init_mode_table will touch the memory out of range unexpected.

Uh.  :-O

> This patch would like to take the MAX_MACHINE_MODE as the size of the
> array in streamer, to make sure there is no potential unexpected
> memory access in future. Meanwhile, this patch also adjust some place
> which has MAX_MACHINE_MODE <= 256 assumption.

Thanks to Jakub and Richard for guidance re the offloading compilation
case, where we've got different 'MAX_MACHINE_MODE's between stream-out
and stream-in, and a modes mapping table.

However, with this patch, there are ICEs all over the place...  I'm
having a look.


Grüße
 Thomas


> gcc/ChangeLog:
>
>   * lto-streamer-in.cc (lto_input_mode_table): Stream in the mode
>   bits for machine mode table.
>   * lto-streamer-out.cc (lto_write_mode_table): Stream out the
>   HOST machine mode bits.
>   * lto-streamer.h (struct lto_file_decl_data): New fields mode_bits.
>   * tree-streamer.cc (streamer_mode_table): Take MAX_MACHINE_MODE
>   as the table size.
>   * tree-streamer.h (streamer_mode_table): Ditto.
>   (bp_pack_machine_mode): Take 1 << ceil_log2 (MAX_MACHINE_MODE)
>   as the packing limit.
>   (bp_unpack_machine_mode): Ditto.
> ---
>  gcc/lto-streamer-in.cc  | 12 
>  gcc/lto-streamer-out.cc | 11 ---
>  gcc/lto-streamer.h  |  2 ++
>  gcc/tree-streamer.cc|  2 +-
>  gcc/tree-streamer.h | 14 +-
>  5 files changed, 28 insertions(+), 13 deletions(-)
>
> diff --git a/gcc/lto-streamer-in.cc b/gcc/lto-streamer-in.cc
> index 2cb83406db5..2a0720b4e6f 100644
> --- a/gcc/lto-streamer-in.cc
> +++ b/gcc/lto-streamer-in.cc
> @@ -1985,8 +1985,6 @@ lto_input_mode_table (struct lto_file_decl_data 
> *file_data)
>  internal_error ("cannot read LTO mode table from %s",
>   file_data->file_name);
>
> -  unsigned char *table = ggc_cleared_vec_alloc (1 << 8);
> -  file_data->mode_table = table;
>const struct lto_simple_header_with_strings *header
>  = (const struct lto_simple_header_with_strings *) data;
>int string_offset;
> @@ -1998,16 +1996,22 @@ lto_input_mode_table (struct lto_file_decl_data 
> *file_data)
>   header->string_size, vNULL);
>bitpack_d bp = streamer_read_bitpack (&ib);
>
> +  unsigned mode_bits = bp_unpack_value (&bp, 5);
> +  unsigned char *table = ggc_cleared_vec_alloc (1 << 
> mode_bits);
> +
> +  file_data->mode_table = table;
> +  file_data->mode_bits = mode_bits;
> +
>table[VOIDmode] = VOIDmode;
>table[BLKmode] = BLKmode;
>unsigned int m;
> -  while ((m = bp_unpack_value (&bp, 8)) != VOIDmode)
> +  while ((m = bp_unpack_value (&bp, mode_bits)) != VOIDmode)
>  {
>enum mode_class mclass
>   = bp_unpack_enum (&bp, mode_class, MAX_MODE_CLASS);
>poly_uint16 size = bp_unpack_poly_value (&bp, 16);
>poly_uint16 prec = bp_unpack_poly_value (&bp, 16);
> -  machine_mode inner = (machine_mode) bp_unpack_value (&bp, 8);
> +  machine_mode inner = (machine_mode) bp_unpack_value (&bp, mode_bits);
>poly_uint16 nunits = bp_unpack_poly_value (&bp, 16);
>unsigned int ibit = 0, fbit = 0;
>unsigned int real_fmt_len = 0;
> diff --git a/gcc/lto-streamer-out.cc b/gcc/lto-streamer-out.cc
> index 5ab2eb4301e..36899283ded 100644
> --- a/gcc/lto-streamer-out.cc
> +++ b/gcc/lto-streamer-out.cc
> @@ -3196,6 +3196,11 @@ lto_write_mode_table (void)
>   if (inner_m != m)
> streamer_mode_table[(int) inner_m] = 1;
>}
> +
> +  /* Pack the mode_bits value within 5 bits (up to 31) in the beginning.  */
> +  unsigned mode_bits = ceil_log2 (MAX_MACHINE_MODE);
> +  bp_pack_value (&bp, mode_bits, 5);
> +
>/* First stream modes that have GET_MODE_INNER (m) == m,
>   so that we can refer to them afterwards.  */
>for (int pass = 0; pass < 2; pass++)
> @@ -3205,11 +3210,11 @@ lto_write_mode_table (void)
> machine_mode m = (machine_mode) i;
> if ((GET_MODE_INNER (m) == m) ^ (pass == 0))
>   continue;
> -   bp_pack_value (&bp, m, 8);
> +   bp_pack_value (&bp, m, mode_bits);
> bp_pack_enum (&bp, mode_class, MAX_MODE_CLASS, GET_MODE_CLASS (m));
> bp_pack_poly_value (&bp, GET_MODE_SIZE (m), 16);
> bp_pack_poly_value (&bp, GET_MODE_PRECISION (m), 16);
> -   bp_pack_value (&bp, GET_MODE_INNER (m), 8);
> +   bp_pack_value (&bp, GET_MODE_INNER (m), mode_bits);
>   

Re: Re: [PATCH v3] Streamer: Fix out of range memory access of machine mode

[Thomas Schwinge]

Hi!

On 2023-06-29T17:33:14+0800, "juzhe.zh...@rivai.ai"  
wrote:
> Not sure what happens you said ICEs all over the place...

Ah, sorry for not providing proper context here.  My comment was about
heterogeneous GCC configurations involving code offloading, like: x86_64
host with GCN, nvptx offload targets, which I'd been asked to test this
"Streamer: Fix out of range memory access of machine mode" for (in
private email) -- for good reasons, as we've now found.  ;-|


> Actually, even without this patch, current upstream GCC in RISCV port already 
> ICE all over the place:
>
> FAIL: gcc.target/riscv/rvv/autovec/partial/multiple_rgroup-3.c (internal 
> compiler error: tree check: expected none of vector_type, have vector_type in 
> divmod_candidate_p, at tree-ssa-math-opts.cc:4998)
> FAIL: gcc.target/riscv/rvv/autovec/partial/multiple_rgroup-3.c (test for 
> excess errors)
> FAIL: gcc.target/riscv/rvv/autovec/partial/slp_run-1.c (internal compiler 
> error: tree check: expected none of vector_type, have vector_type in 
> divmod_candidate_p, at tree-ssa-math-opts.cc:4998)
> FAIL: gcc.target/riscv/rvv/autovec/partial/slp_run-1.c (test for excess 
> errors)
> FAIL: gcc.target/riscv/rvv/autovec/partial/slp_run-17.c (internal compiler 
> error: tree check: expected none of vector_type, have vector_type in 
> divmod_candidate_p, at tree-ssa-math-opts.cc:4998)
> FAIL: gcc.target/riscv/rvv/autovec/partial/slp_run-17.c (test for excess 
> errors)
> FAIL: gcc.target/riscv/rvv/autovec/partial/multiple_rgroup_run-3.c (internal 
> compiler error: tree check: expected none of vector_type, have vector_type in 
> divmod_candidate_p, at tree-ssa-math-opts.cc:4998)
> FAIL: gcc.target/riscv/rvv/autovec/partial/multiple_rgroup_run-3.c (test for 
> excess errors)
> FAIL: gcc.target/riscv/rvv/autovec/partial/slp_run-2.c (internal compiler 
> error: tree check: expected none of vector_type, have vector_type in 
> divmod_candidate_p, at tree-ssa-math-opts.cc:4998)
> FAIL: gcc.target/riscv/rvv/autovec/partial/slp_run-2.c (test for excess 
> errors)
> FAIL: gcc.target/riscv/rvv/autovec/binop/narrow_run-1.c (internal compiler 
> error: tree check: expected none of vector_type, have vector_type in 
> divmod_candidate_p, at tree-ssa-math-opts.cc:4998)
> FAIL: gcc.target/riscv/rvv/autovec/binop/narrow_run-1.c (test for excess 
> errors)
> FAIL: gcc.target/riscv/rvv/autovec/partial/slp_run-16.c (internal compiler 
> error: tree check: expected none of vector_type, have vector_type in 
> divmod_candidate_p, at tree-ssa-math-opts.cc:4998)
> FAIL: gcc.target/riscv/rvv/autovec/partial/slp_run-16.c (test for excess 
> errors)
> FAIL: gcc.target/riscv/rvv/autovec/partial/slp_run-3.c (internal compiler 
> error: tree check: expected none of vector_type, have vector_type in 
> divmod_candidate_p, at tree-ssa-math-opts.cc:4998)
> FAIL: gcc.target/riscv/rvv/autovec/partial/slp_run-3.c (test for excess 
> errors)

That looks like a different issue, though?


Grüße
 Thomas


> From: Thomas Schwinge
> Date: 2023-06-29 17:29
> To: Pan Li
> CC: gcc-patches@gcc.gnu.org; juzhe.zh...@rivai.ai; rdapp@gmail.com; 
> jeffreya...@gmail.com; yanzhang.w...@intel.com; kito.ch...@gmail.com; 
> rguent...@suse.de; ja...@redhat.com; Tobias Burnus
> Subject: Re: [PATCH v3] Streamer: Fix out of range memory access of machine 
> mode
> Hi!
>
> On 2023-06-21T15:58:24+0800, Pan Li via Gcc-patches  
> wrote:
>> We extend the machine mode from 8 to 16 bits already. But there still
>> one placing missing from the streamer. It has one hard coded array
>> for the machine code like size 256.
>>
>> In the lto pass, we memset the array by MAX_MACHINE_MODE count but the
>> value of the MAX_MACHINE_MODE will grow as more and more modes are
>> added. While the machine mode array in tree-streamer still leave 256 as is.
>>
>> Then, when the MAX_MACHINE_MODE is greater than 256, the memset of
>> lto_output_init_mode_table will touch the memory out of range unexpected.
>
> Uh.  :-O
>
>> This patch would like to take the MAX_MACHINE_MODE as the size of the
>> array in streamer, to make sure there is no potential unexpected
>> memory access in future. Meanwhile, this patch also adjust some place
>> which has MAX_MACHINE_MODE <= 256 assumption.
>
> Thanks to Jakub and Richard for guidance re the offloading compilation
> case, where we've got different 'MAX_MACHINE_MODE's between stream-out
> and stream-in, and a modes mapping table.
>
> However, with this patch, there are ICEs all over the place...  I'm
> having a look.
>
>
> Grüße
> Thomas
>
>
>> gcc/ChangeLog:
>>
>>   * lto-streamer-in.cc (lto_input_mode_t

Re: [PATCH v3] Streamer: Fix out of range memory access of machine mode

[Thomas Schwinge]

Hi!

On 2023-06-29T11:29:57+0200, I wrote:
> On 2023-06-21T15:58:24+0800, Pan Li via Gcc-patches  
> wrote:
>> We extend the machine mode from 8 to 16 bits already. But there still
>> one placing missing from the streamer. It has one hard coded array
>> for the machine code like size 256.
>>
>> In the lto pass, we memset the array by MAX_MACHINE_MODE count but the
>> value of the MAX_MACHINE_MODE will grow as more and more modes are
>> added. While the machine mode array in tree-streamer still leave 256 as is.
>>
>> Then, when the MAX_MACHINE_MODE is greater than 256, the memset of
>> lto_output_init_mode_table will touch the memory out of range unexpected.
>
> Uh.  :-O
>
>> This patch would like to take the MAX_MACHINE_MODE as the size of the
>> array in streamer, to make sure there is no potential unexpected
>> memory access in future. Meanwhile, this patch also adjust some place
>> which has MAX_MACHINE_MODE <= 256 assumption.
>
> Thanks to Jakub and Richard for guidance re the offloading compilation
> case, where we've got different 'MAX_MACHINE_MODE's between stream-out
> and stream-in, and a modes mapping table.
>
> However, with this patch, there are ICEs all over the place...  I'm
> having a look.

Your patch has all the right ideas, there are just a few additional
changes necessary.  Please merge in the attached
"f into Streamer: Fix out of range memory access of machine mode", with
'Co-authored-by: Thomas Schwinge '.  This has
already survived compiler-side 'lto.exp' testing and
'check-target-libgomp' with Nvidia GPU offloading; AMD GPU testing is now
running (not expecting any bad surprises).  Will let you know by (my)
tomorrow morning in case there are any more problems.

Explanation:

>> --- a/gcc/lto-streamer-in.cc
>> +++ b/gcc/lto-streamer-in.cc
>> @@ -1985,8 +1985,6 @@ lto_input_mode_table (struct lto_file_decl_data 
>> *file_data)
>>  internal_error ("cannot read LTO mode table from %s",
>>   file_data->file_name);
>>
>> -  unsigned char *table = ggc_cleared_vec_alloc (1 << 8);
>> -  file_data->mode_table = table;
>>const struct lto_simple_header_with_strings *header
>>  = (const struct lto_simple_header_with_strings *) data;
>>int string_offset;
>> @@ -1998,16 +1996,22 @@ lto_input_mode_table (struct lto_file_decl_data 
>> *file_data)
>>   header->string_size, vNULL);
>>bitpack_d bp = streamer_read_bitpack (&ib);
>>
>> +  unsigned mode_bits = bp_unpack_value (&bp, 5);
>> +  unsigned char *table = ggc_cleared_vec_alloc (1 << 
>> mode_bits);
>> +
>> +  file_data->mode_table = table;
>> +  file_data->mode_bits = mode_bits;

Here, we set 'file_data->mode_bits' for the offloading case (where
'lto_input_mode_table' is called) -- but it's not set for the
non-offloading case (where 'lto_input_mode_table' isn't called).  (See my
'gcc/lto/lto-common.cc:lto_read_decls' change.)  That's "not currently a
problem", as 'file_data->mode_bits' isn't used anywhere...

>> --- a/gcc/lto-streamer.h
>> +++ b/gcc/lto-streamer.h
>> @@ -604,6 +604,8 @@ struct GTY(()) lto_file_decl_data
>>int order_base;
>>
>>int unit_base;
>> +
>> +  unsigned mode_bits;
>>  };

>>  inline machine_mode
>>  bp_unpack_machine_mode (struct bitpack_d *bp)
>>  {
>> -  return (machine_mode)
>> -((class lto_input_block *)
>> - bp->stream)->mode_table[bp_unpack_enum (bp, machine_mode, 1 << 8)];
>> +  int last = 1 << ceil_log2 (MAX_MACHINE_MODE);
>> +  lto_input_block *input_block = (class lto_input_block *) bp->stream;
>> +  int index = bp_unpack_enum (bp, machine_mode, last);
>> +
>> +  return (machine_mode) input_block->mode_table[index];
>>  }

..., but 'file_data->mode_bits' needs to be considered here, in the
stream-in for offloading, where 'file_data->mode_bits' -- that is, the
host 'MAX_MACHINE_MODE' -- very likely is different from the offload
device 'MAX_MACHINE_MODE'.

Easiest is in 'gcc/lto-streamer.h:class lto_input_block' to capture
'lto_file_decl_data *file_data' instead of just
'unsigned char *mode_table', and adjust all users.

That's it.  :-)

>> --- a/gcc/tree-streamer.h
>> +++ b/gcc/tree-streamer.h

>> @@ -108,15 +108,19 @@ inline void
>>  bp_pack_machine_mode (struct bitpack_d *bp, machine_mode mode)
>>  {
>>streamer_mod

Flip the nvptx port to LRA (was: [PATCH] Turn on LRA on all targets)

[Thomas Schwinge]

Hi!

On 2023-04-29T09:06:54-0600, Jeff Law via Gcc-patches  
wrote:
> On 4/29/23 07:37, Roger Sayle wrote:
>>
>> Segher Boessenkool wrote:
>>> I send this patch now so that people can start testing.
>>>
>>> --- a/gcc/config/nvptx/nvptx.cc
>>> +++ b/gcc/config/nvptx/nvptx.cc
>>> @@ -7601,9 +7601,6 @@ nvptx_asm_output_def_from_decls (FILE *stream, tree 
>>> name, tree value)
>>> #undef TARGET_ATTRIBUTE_TABLE
>>> #define TARGET_ATTRIBUTE_TABLE nvptx_attribute_table
>>>
>>> -#undef TARGET_LRA_P
>>> -#define TARGET_LRA_P hook_bool_void_false
>>> -
>>> #undef TARGET_LEGITIMATE_ADDRESS_P
>>> #define TARGET_LEGITIMATE_ADDRESS_P nvptx_legitimate_address_p
>>
>> I've tested Segher's patch on nvptx-none with make and make -k check and
>> can confirm there are no new regressions.

Confirmed.  Also, no change in nvptx target libraries built.  As
expected.

>> Nvptx is unique in that it
>> doesn't
>> use register allocation, i.e. GCC's only TARGET_NO_REGISTER_ALLOCATION
>> target,
>> so it's a little odd that it specifies which register allocator it doesn't
>> use.
>>
>> I hope this helps,
>
> It does.  Consider a patch which flips the nvptx port to LRA as
> pre-approved.

Pushed to master branch commit f7e3123638712773e8c01e17aae9dc64d9342016
"Flip the nvptx port to LRA", see attached.


Grüße
 Thomas


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
>From f7e3123638712773e8c01e17aae9dc64d9342016 Mon Sep 17 00:00:00 2001
From: Segher Boessenkool 
Date: Sun, 23 Apr 2023 16:47:52 +
Subject: [PATCH] Flip the nvptx port to LRA

... understanding that "turn on LRA" is an exaggeration here, given that nvptx
isn't actually doing register allocation ('TARGET_NO_REGISTER_ALLOCATION').

	gcc/
	* config/nvptx/nvptx.cc (TARGET_LRA_P): Remove.

Co-authored-by: Thomas Schwinge 
---
 gcc/config/nvptx/nvptx.cc | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/gcc/config/nvptx/nvptx.cc b/gcc/config/nvptx/nvptx.cc
index e3b0304d5376..16ed78030d73 100644
--- a/gcc/config/nvptx/nvptx.cc
+++ b/gcc/config/nvptx/nvptx.cc
@@ -7633,9 +7633,6 @@ nvptx_asm_output_def_from_decls (FILE *stream, tree name, tree value)
 #undef TARGET_ATTRIBUTE_TABLE
 #define TARGET_ATTRIBUTE_TABLE nvptx_attribute_table
 
-#undef TARGET_LRA_P
-#define TARGET_LRA_P hook_bool_void_false
-
 #undef TARGET_LEGITIMATE_ADDRESS_P
 #define TARGET_LEGITIMATE_ADDRESS_P nvptx_legitimate_address_p
 
-- 
2.39.2

LTO: Capture 'lto_file_decl_data *file_data' in 'class lto_input_block' (was: [PATCH v3] Streamer: Fix out of range memory access of machine mode)

[Thomas Schwinge]

Hi!

On 2023-06-29T22:14:59+0200, I wrote:
> [the new] 'file_data->mode_bits' needs to be considered [somewhere]
>
> Easiest is in 'gcc/lto-streamer.h:class lto_input_block' to capture
> 'lto_file_decl_data *file_data' instead of just
> 'unsigned char *mode_table', and adjust all users.

I've split this out as a preparational "no change in behavior" patch; is
"LTO: Capture 'lto_file_decl_data *file_data' in 'class lto_input_block'"
OK to push, see attached?


Grüße
 Thomas


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
>From 1b75a8680bdef16633e3fa2479832a1b71dae43f Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Thu, 29 Jun 2023 21:33:06 +0200
Subject: [PATCH] LTO: Capture 'lto_file_decl_data *file_data' in 'class
 lto_input_block'

... instead of just 'unsigned char *mode_table'.  Preparation for a forthcoming
change, where we need to capture an additional 'file_data' item, so it seems
easier to just capture that one proper.

	gcc/
	* lto-streamer.h (class lto_input_block): Capture
	'lto_file_decl_data *file_data' instead of just
	'unsigned char *mode_table'.
	* ipa-devirt.cc (ipa_odr_read_section): Adjust.
	* ipa-fnsummary.cc (inline_read_section): Likewise.
	* ipa-icf.cc (sem_item_optimizer::read_section): Likewise.
	* ipa-modref.cc (read_section): Likewise.
	* ipa-prop.cc (ipa_prop_read_section, read_replacements_section):
	Likewise.
	* ipa-sra.cc (isra_read_summary_section): Likewise.
	* lto-cgraph.cc (input_cgraph_opt_section): Likewise.
	* lto-section-in.cc (lto_create_simple_input_block): Likewise.
	* lto-streamer-in.cc (lto_read_body_or_constructor)
	(lto_input_toplevel_asms): Likewise.
	* tree-streamer.h (bp_unpack_machine_mode): Likewise.
	gcc/lto/
	* lto-common.cc (lto_read_decls): Adjust.
---
 gcc/ipa-devirt.cc  |  2 +-
 gcc/ipa-fnsummary.cc   |  2 +-
 gcc/ipa-icf.cc |  2 +-
 gcc/ipa-modref.cc  |  2 +-
 gcc/ipa-prop.cc|  4 ++--
 gcc/ipa-sra.cc |  2 +-
 gcc/lto-cgraph.cc  |  2 +-
 gcc/lto-section-in.cc  |  2 +-
 gcc/lto-streamer-in.cc |  6 +++---
 gcc/lto-streamer.h | 10 +-
 gcc/lto/lto-common.cc  |  2 +-
 gcc/tree-streamer.h|  6 +++---
 12 files changed, 21 insertions(+), 21 deletions(-)

diff --git a/gcc/ipa-devirt.cc b/gcc/ipa-devirt.cc
index 2c61a497cee..87529be4515 100644
--- a/gcc/ipa-devirt.cc
+++ b/gcc/ipa-devirt.cc
@@ -4147,7 +4147,7 @@ ipa_odr_read_section (struct lto_file_decl_data *file_data, const char *data,
   class data_in *data_in;
 
   lto_input_block ib ((const char *) data + main_offset, header->main_size,
-		  file_data->mode_table);
+		  file_data);
 
   data_in
 = lto_data_in_create (file_data, (const char *) data + string_offset,
diff --git a/gcc/ipa-fnsummary.cc b/gcc/ipa-fnsummary.cc
index a5f5a50c8a5..37c1edc2f3a 100644
--- a/gcc/ipa-fnsummary.cc
+++ b/gcc/ipa-fnsummary.cc
@@ -4528,7 +4528,7 @@ inline_read_section (struct lto_file_decl_data *file_data, const char *data,
   unsigned int f_count;
 
   lto_input_block ib ((const char *) data + main_offset, header->main_size,
-		  file_data->mode_table);
+		  file_data);
 
   data_in =
 lto_data_in_create (file_data, (const char *) data + string_offset,
diff --git a/gcc/ipa-icf.cc b/gcc/ipa-icf.cc
index cb9f768d85d..836d0914ded 100644
--- a/gcc/ipa-icf.cc
+++ b/gcc/ipa-icf.cc
@@ -2204,7 +2204,7 @@ sem_item_optimizer::read_section (lto_file_decl_data *file_data,
   unsigned int count;
 
   lto_input_block ib_main ((const char *) data + main_offset, 0,
-			   header->main_size, file_data->mode_table);
+			   header->main_size, file_data);
 
   data_in
 = lto_data_in_create (file_data, (const char *) data + string_offset,
diff --git a/gcc/ipa-modref.cc b/gcc/ipa-modref.cc
index e3196df8aa9..278b2dbd828 100644
--- a/gcc/ipa-modref.cc
+++ b/gcc/ipa-modref.cc
@@ -3816,7 +3816,7 @@ read_section (struct lto_file_decl_data *file_data, const char *data,
   unsigned int f_count;
 
   lto_input_block ib ((const char *) data + main_offset, header->main_size,
-		  file_data->mode_table);
+		  file_data);
 
   data_in
 = lto_data_in_create (file_data, (const char *) data + string_offset,
diff --git a/gcc/ipa-prop.cc b/gcc/ipa-prop.cc
index 704fe01b02c..8f2119b72e3 100644
--- a/gcc/ipa-prop.cc
+++ b/gcc/ipa-prop.cc
@@ -5337,7 +5337,7 @@ ipa_prop_read_section (struct lto_file_decl_data *file_data, const char *data,
   unsigned int count;
 
   lto_input_block ib_main ((const char *) data + main_offset,
-			   header->main_size, file_data->mode_table);
+			   header->main_size, file_data);
 
   data_in =
 lto_data_in_creat

[v4] Streamer: Fix out of range memory access of machine mode

[Thomas Schwinge]

Hi!

On 2023-06-30T01:39:39+, "Li, Pan2"  wrote:
> That’s very cool, thanks Thomas for help!

:-)

> Let’s wait the AMD test running result for the final version of the patch.

That's all looking good, too.

> From: juzhe.zh...@rivai.ai 
> Sent: Friday, June 30, 2023 9:27 AM

> Could you merge your patch after you tested?

I've done that, and with (already approved)
<https://inbox.sourceware.org/87v8f5uzob@euler.schwinge.homeip.net>
"LTO: Capture 'lto_file_decl_data *file_data' in 'class lto_input_block'"
split out, OK to push the attached
v4 "Streamer: Fix out of range memory access of machine mode"?


Grüße
 Thomas


> From: Thomas Schwinge<mailto:tho...@codesourcery.com>
> Date: 2023-06-30 04:14

> Subject: Re: [PATCH v3] Streamer: Fix out of range memory access of machine 
> mode
> Hi!
>
> On 2023-06-29T11:29:57+0200, I wrote:
>> On 2023-06-21T15:58:24+0800, Pan Li via Gcc-patches 
>> mailto:gcc-patches@gcc.gnu.org>> wrote:
>>> We extend the machine mode from 8 to 16 bits already. But there still
>>> one placing missing from the streamer. It has one hard coded array
>>> for the machine code like size 256.
>>>
>>> In the lto pass, we memset the array by MAX_MACHINE_MODE count but the
>>> value of the MAX_MACHINE_MODE will grow as more and more modes are
>>> added. While the machine mode array in tree-streamer still leave 256 as is.
>>>
>>> Then, when the MAX_MACHINE_MODE is greater than 256, the memset of
>>> lto_output_init_mode_table will touch the memory out of range unexpected.
>>
>> Uh.  :-O
>>
>>> This patch would like to take the MAX_MACHINE_MODE as the size of the
>>> array in streamer, to make sure there is no potential unexpected
>>> memory access in future. Meanwhile, this patch also adjust some place
>>> which has MAX_MACHINE_MODE <= 256 assumption.
>>
>> Thanks to Jakub and Richard for guidance re the offloading compilation
>> case, where we've got different 'MAX_MACHINE_MODE's between stream-out
>> and stream-in, and a modes mapping table.
>>
>> However, with this patch, there are ICEs all over the place...  I'm
>> having a look.
>
> Your patch has all the right ideas, there are just a few additional
> changes necessary.  Please merge in the attached
> "f into Streamer: Fix out of range memory access of machine mode", with
> 'Co-authored-by: Thomas Schwinge 
> mailto:tho...@codesourcery.com>>'.  This has
> already survived compiler-side 'lto.exp' testing and
> 'check-target-libgomp' with Nvidia GPU offloading; AMD GPU testing is now
> running (not expecting any bad surprises).  Will let you know by (my)
> tomorrow morning in case there are any more problems.
>
> Explanation:
>
>>> --- a/gcc/lto-streamer-in.cc
>>> +++ b/gcc/lto-streamer-in.cc
>>> @@ -1985,8 +1985,6 @@ lto_input_mode_table (struct lto_file_decl_data 
>>> *file_data)
>>>  internal_error ("cannot read LTO mode table from %s",
>>>   file_data->file_name);
>>>
>>> -  unsigned char *table = ggc_cleared_vec_alloc (1 << 8);
>>> -  file_data->mode_table = table;
>>>const struct lto_simple_header_with_strings *header
>>>  = (const struct lto_simple_header_with_strings *) data;
>>>int string_offset;
>>> @@ -1998,16 +1996,22 @@ lto_input_mode_table (struct lto_file_decl_data 
>>> *file_data)
>>>   header->string_size, vNULL);
>>>bitpack_d bp = streamer_read_bitpack (&ib);
>>>
>>> +  unsigned mode_bits = bp_unpack_value (&bp, 5);
>>> +  unsigned char *table = ggc_cleared_vec_alloc (1 << 
>>> mode_bits);
>>> +
>>> +  file_data->mode_table = table;
>>> +  file_data->mode_bits = mode_bits;
>
> Here, we set 'file_data->mode_bits' for the offloading case (where
> 'lto_input_mode_table' is called) -- but it's not set for the
> non-offloading case (where 'lto_input_mode_table' isn't called).  (See my
> 'gcc/lto/lto-common.cc:lto_read_decls' change.)  That's "not currently a
> problem", as 'file_data->mode_bits' isn't used anywhere...
>
>>> --- a/gcc/lto-streamer.h
>>> +++ b/gcc/lto-streamer.h
>>> @@ -604,6 +604,8 @@ struct GTY(()) lto_file_decl_data
>>>int order_base;
>>>
>>>int unit_base;
>>> +
>>> +  unsigned mode_bits;

Adjust LTO mode tables for "Machine_Mode: Extend machine_mode from 8 to 16 bits" (was: [PATCH] Machine_Mode: Extend machine_mode from 8 to 16 bits)

[Thomas Schwinge]

Hi!

On 2023-05-13T16:44:41+0800, Kito Cheng via Gcc-patches 
 wrote:
> Tried this patch and I ran into some issues, some variables are using
> unsigned char to hold machine mode and will have problems when the
> number of modes is larger than 255...
>
> And here is the fix:

> --- a/gcc/genmodes.cc
> +++ b/gcc/genmodes.cc
> @@ -1141,10 +1141,10 @@ inline __attribute__((__always_inline__))\n\
> #else\n\
> extern __inline__ __attribute__((__always_inline__, __gnu_inline__))\n\
> #endif\n\
> -unsigned char\n\
> +unsigned short\n\
> mode_inner_inline (machine_mode mode)\n\
> {\n\
> -  extern const unsigned char mode_inner[NUM_MACHINE_MODES];\n\
> +  extern const unsigned short mode_inner[NUM_MACHINE_MODES];\n\
>   gcc_assert (mode >= 0 && mode < NUM_MACHINE_MODES);\n\
>   switch (mode)\n\
> {");
> @@ -1529,7 +1529,7 @@ emit_mode_wider (void)
>   int c;
>   struct mode_data *m;
>
> -  print_decl ("unsigned char", "mode_next", "NUM_MACHINE_MODES");
> +  print_decl ("unsigned short", "mode_next", "NUM_MACHINE_MODES");

Etc.

Instead of 's%char%short', shouldn't we really be using
'enum machine_mode' here?  (I understand such a change may require some
further surgery, but wouldn't it be the correct thing to do?)


And, in context of working on
<https://inbox.sourceware.org/87mt0hcp12@euler.schwinge.homeip.net>
"Streamer: Fix out of range memory access of machine mode", I found
another one, see attached
'[WIP] Adjust LTO mode tables for "Machine_Mode: Extend machine_mode from 8 to 
16 bits"'
(..., which applies on top of the former.)  There, in fact, I did change
to 'enum machine_mode' instead of 's%char%short' -- correct?  Any
comments on the 'GTY' issues: (1) 'const' build error,
(2) '[build-gcc]/gcc/gtype-desc.cc' changes, and (3) is 'GTY((atomic))'
actually the right thing to use, here?

In particular, the 'lto_mode_identity_table' changes would seem necessary
to keep standard LTO ('-flto') functional for large 'machine_mode' size?


Bernhard: Fancy writing a Coccinelle check whether there are any more
places where we put what originally was a 'machine_mode' type into a
'char' (or, into a non-'machine_mode' generally)?  ;-) Hey, just a Friday
afternoon idea!


Grüße
 Thomas


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
>From 0fd8f65bb87b11ef8ae366a797aec572d67b284f Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Fri, 30 Jun 2023 13:23:55 +0200
Subject: [PATCH] [WIP] Adjust LTO mode tables for "Machine_Mode: Extend
 machine_mode from 8 to 16 bits"

---
 gcc/lto-streamer-in.cc |  2 +-
 gcc/lto-streamer.h | 56 +-
 gcc/lto/lto-common.cc  | 10 
 gcc/lto/lto-common.h   |  2 +-
 gcc/tree-streamer.h|  2 +-
 5 files changed, 63 insertions(+), 9 deletions(-)

diff --git a/gcc/lto-streamer-in.cc b/gcc/lto-streamer-in.cc
index 1876e1967ec..bbd44504ff8 100644
--- a/gcc/lto-streamer-in.cc
+++ b/gcc/lto-streamer-in.cc
@@ -1997,7 +1997,7 @@ lto_input_mode_table (struct lto_file_decl_data *file_data)
   bitpack_d bp = streamer_read_bitpack (&ib);
 
   unsigned mode_bits = bp_unpack_value (&bp, 5);
-  unsigned char *table = ggc_cleared_vec_alloc (1 << mode_bits);
+  machine_mode *table = ggc_cleared_vec_alloc (1 << mode_bits);
 
   file_data->mode_table = table;
   file_data->mode_bits = mode_bits;
diff --git a/gcc/lto-streamer.h b/gcc/lto-streamer.h
index 0556b34c837..4d83741e4c6 100644
--- a/gcc/lto-streamer.h
+++ b/gcc/lto-streamer.h
@@ -596,7 +596,61 @@ struct GTY(()) lto_file_decl_data
   hash_map * GTY((skip)) resolution_map;
 
   /* Mode translation table.  */
-  const unsigned char *mode_table;
+  /*TODO const
+With 'const', we get:
+
+gtype-desc.cc: In function 'void gt_pch_nx_lto_file_decl_data(void*)':
+gtype-desc.cc:6531:34: error: invalid conversion from 'const void*' to 'void*' [-fpermissive]
+ gt_pch_note_object ((*x).mode_table, x, gt_pch_p_18lto_file_decl_data);
+  ^
+In file included from [...]/source-gcc/gcc/hash-table.h:247:0,
+ from [...]/source-gcc/gcc/coretypes.h:486,
+ from gtype-desc.cc:23:
+[...]/source-gcc/gcc/ggc.h:47:12: note:   initializing argument 1 of 'int gt_pch_note_object(void*, void*, gt_note_pointers, size_t)'
+ extern int gt_pch_note_object (void *, void *, gt_note_po

Re: Adjust LTO mode tables for "Machine_Mode: Extend machine_mode from 8 to 16 bits" (was: [PATCH] Machine_Mode: Extend machine_mode from 8 to 16 bits)

[Thomas Schwinge]

Hi!

On 2023-06-30T20:45:38+0800, Kito Cheng  wrote:
>> On 2023-05-13T16:44:41+0800, Kito Cheng via Gcc-patches 
>>  wrote:
>> > Tried this patch and I ran into some issues, some variables are using
>> > unsigned char to hold machine mode and will have problems when the
>> > number of modes is larger than 255...
>> >
>> > And here is the fix:
>>
>> > --- a/gcc/genmodes.cc
>> > +++ b/gcc/genmodes.cc
>> > @@ -1141,10 +1141,10 @@ inline __attribute__((__always_inline__))\n\
>> > #else\n\
>> > extern __inline__ __attribute__((__always_inline__, __gnu_inline__))\n\
>> > #endif\n\
>> > -unsigned char\n\
>> > +unsigned short\n\
>> > mode_inner_inline (machine_mode mode)\n\
>> > {\n\
>> > -  extern const unsigned char mode_inner[NUM_MACHINE_MODES];\n\
>> > +  extern const unsigned short mode_inner[NUM_MACHINE_MODES];\n\
>> >   gcc_assert (mode >= 0 && mode < NUM_MACHINE_MODES);\n\
>> >   switch (mode)\n\
>> > {");
>> > @@ -1529,7 +1529,7 @@ emit_mode_wider (void)
>> >   int c;
>> >   struct mode_data *m;
>> >
>> > -  print_decl ("unsigned char", "mode_next", "NUM_MACHINE_MODES");
>> > +  print_decl ("unsigned short", "mode_next", "NUM_MACHINE_MODES");
>>
>> Etc.
>>
>> Instead of 's%char%short', shouldn't we really be using
>> 'enum machine_mode' here?  (I understand such a change may require some
>> further surgery, but wouldn't it be the correct thing to do?)
>
> Hmmm, I think maybe what we need is to leverage C++ language features
> to declare enum with underlying types like that:
>
> enum machine_mode : uint16_t

Eh, so that's the reason/confusion (or, at least some of it...) here: my
(naïve...) assumption has been that 'enum machine_mode' already does have
a fixed underlying type -- but apparently it does not, so defaults to
'unsigned int'!

(gdb) ptype lto_mode_identity_table
type = const enum machine_mode : unsigned int {E_VOIDmode, E_BLKmode, 
E_CCmode, [...], NUM_MACHINE_MODES = 130} *

So, yeah, should we fix that, and then generally use 'enum machine_mode'
instead of 'char' vs. 'short'?  (Or, which other "detail" do I fail to
recognize this time?)


Grüße
 Thomas
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955

Re: Adjust LTO mode tables for "Machine_Mode: Extend machine_mode from 8 to 16 bits" (was: [PATCH] Machine_Mode: Extend machine_mode from 8 to 16 bits)

[Thomas Schwinge]

Hi Jakub!

On 2023-06-30T18:37:59+0200, Jakub Jelinek  wrote:
> On Fri, Jun 30, 2023 at 08:45:38PM +0800, Kito Cheng wrote:
>> Hmmm, I think maybe what we need is to leverage C++ language features
>> to declare enum with underlying types like that:
>>
>> enum machine_mode : uint16_t
>
> What would be the advantage of doing that?
> I mean, on most hosts using unsigned rather than unsigned short is
> actually faster

Interesting, I had not considered that, and assumed we'd always
space-optimize such things.  But yes, I do see your point.

Is it worth adding some such rationale into a new "Data Types" (or
similar) section on ,
?

> and for the cases where we care about the size
> (e.g. mode in RTL, DECLs and the like) we already use enum bitfields.

So, which category does (current) 'unsigned char *mode_table' in
'gcc/lto-streamer.h:struct lto_file_decl_data' fall into?  Used in
'gcc/tree-streamer.h:bp_unpack_machine_mode', normally (non-offloading
case) doing "identity-lookup" via
'gcc/lto/lto-common.cc:lto_mode_identity_table'.  Should this turn into
'ENUM_BITFIELD (machine_mode)' ("native size") or
'ENUM_BITFIELD (machine_mode) : MACHINE_MODE_BITSIZE' (space-optimized)?


Grüße
 Thomas
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955

'unsigned int len' field in 'libcpp/include/symtab.h:struct ht_identifier' (was: [PATCH] pch: Fix streaming of strings with embedded null bytes)

[Thomas Schwinge]

Hi!

I came across this one here on my way working through another (somewhat
related) GTY issue.  I generally do understand the issue here, but do
have a question about 'unsigned int len' field in
'libcpp/include/symtab.h:struct ht_identifier':

On 2022-10-18T18:14:54-0400, Lewis Hyatt via Gcc-patches 
 wrote:
> When a GTY'ed struct is streamed to PCH, any plain char* pointers it contains
> (whether they live in GC-controlled memory or not) will be marked for PCH
> output by the routine gt_pch_note_object in ggc-common.cc. This routine
> special-cases plain char* strings, and in particular it uses strlen() to get
> their length.

Oh, wow, this special casing for strings...  8-|

> Thus it does not handle strings with embedded null bytes, but it
> is possible for something PCH cares about (such as a string literal token in a
> macro definition) to contain such embedded nulls. To fix that up, add a new
> GTY option "string_length" so that gt_pch_note_object can be informed the
> actual length it ought to use, and use it in the relevant libcpp structs
> (cpp_string and ht_identifier) accordingly.

For your test case:

> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/pch/pch-string-nulls.C
> @@ -0,0 +1,3 @@
> +// { dg-do compile { target c++11 } }
> +#include "pch-string-nulls.H"
> +static_assert (X[4] == '[' && X[5] == '!' && X[6] == ']', "error");

> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/pch/pch-string-nulls.Hs
> @@ -0,0 +1,2 @@
> +/* Note that there is a null byte following "ABC".  */
> +#define X R"(ABC^@[!])"

..., I understand how the following is necessary:

> --- a/libcpp/include/cpplib.h
> +++ b/libcpp/include/cpplib.h
> @@ -179,7 +179,11 @@ enum c_lang {CLK_GNUC89 = 0, CLK_GNUC99, CLK_GNUC11, 
> CLK_GNUC17, CLK_GNUC2X,
>  /* Payload of a NUMBER, STRING, CHAR or COMMENT token.  */
>  struct GTY(()) cpp_string {
>unsigned int len;
> -  const unsigned char *text;
> +
> +  /* TEXT is always null terminated (terminator not included in len); but 
> this
> + GTY markup arranges that PCH streaming works properly even if there is a
> + null byte in the middle of the string.  */
> +  const unsigned char * GTY((string_length ("1 + %h.len"))) text;
>  };

(That is, the test case FAILs with that one reverted.)

However, this one did confuse me:

> --- a/libcpp/include/symtab.h
> +++ b/libcpp/include/symtab.h
> @@ -29,7 +29,10 @@ along with this program; see the file COPYING3.  If not see
>  typedef struct ht_identifier ht_identifier;
>  typedef struct ht_identifier *ht_identifier_ptr;
>  struct GTY(()) ht_identifier {
> -  const unsigned char *str;
> +  /* This GTY markup arranges that the null-terminated identifier would still
> + stream to PCH correctly, if a null byte were to make its way into an
> + identifier somehow.  */
> +  const unsigned char * GTY((string_length ("1 + %h.len"))) str;
>unsigned int len;
>unsigned int hash_value;
>  };

I did wonder whether that's an actual or just a theoretical concern, to
have 'ht_identifier's with embedded NULs?  If an actual concern, can we
get a test case constructed?  Otherwise, should we revert this hunk,
given that we have this auto-'strlen' handling, ignorant of embedded
NULs, in a lot of other places?

But then I realized that possibly we do maintain 'len' here not for
correctness but as an optimization (trading an 'unsigned int' for
repeated 'strlen' calls)?  My quick testing with the attached
"[RFC] Verify no embedded NULs in 'struct ht_identifier'" might confirm
this theory: no regressions (..., but I didn't bootstrap, and ran only
parts of the testsuite).  (Not proposing that RFC for 'git push', of
course.)

If that's indeed the intention here, I shall change/add source code
commentary to describe this rationale for this dedicated 'len' field
(plus, that handling of embedded NULs falls out of that, automatically).

For reference, this 'len' field has existed "forever".  Before
'struct ht_identifier' was added in
commit 2a967f3d3a45294640e155381ef549e0b8090ad4 (Subversion r42334), we
had in 'gcc/cpplib.h:struct cpp_hashnode': 'unsigned short len', or
earlier 'length', earlier in 'gcc/cpphash.h:struct hashnode':
'unsigned short length', earlier 'size_t length' with comment:
"length of token, for quick comparison", erlier 'int length', ever since
the 'gcc/cpp*' files were added in
commit 7f2935c734c36f84ab62b20a04de465e19061333 (Subversion r9191).


Grüße
 Thomas


-
Siemens Electronic Design Automation G

GGC: Remove unused 'bool is_string' arguments to 'ggc_pch_{count,alloc,write}_object' (was: RFA - Remove GC zone allocator)

[Thomas Schwinge]

Hi!

On 2013-01-24T10:14:58-0500, Diego Novillo  wrote:
> [...] the patch [...] committed [...]

This did clean up some things:

> --- a/gcc/ggc-internal.h
> +++ b/gcc/ggc-internal.h
> @@ -55,8 +55,7 @@ extern struct ggc_pch_data *init_ggc_pch (void);
> of an object.  Update the ggc_pch_data structure with as much of
> that information as is necessary. The bool argument should be true
> if the object is a string.  */
> -extern void ggc_pch_count_object (struct ggc_pch_data *, void *, size_t, 
> bool,
> -   enum gt_types_enum);
> +extern void ggc_pch_count_object (struct ggc_pch_data *, void *, size_t, 
> bool);
>
>  /* Return the total size of the data to be written to hold all
> the objects previously passed to ggc_pch_count_object.  */
> @@ -69,8 +68,7 @@ extern void ggc_pch_this_base (struct ggc_pch_data *, void 
> *);
>  /* Assuming that the objects really do end up at the address
> passed to ggc_pch_this_base, return the address of this object.
> The bool argument should be true if the object is a string.  */
> -extern char *ggc_pch_alloc_object (struct ggc_pch_data *, void *, size_t, 
> bool,
> -enum gt_types_enum);
> +extern char *ggc_pch_alloc_object (struct ggc_pch_data *, void *, size_t, 
> bool);

> --- a/gcc/ggc-page.c
> +++ b/gcc/ggc-page.c

> @@ -2230,8 +2221,7 @@ init_ggc_pch (void)
>
>  void
>  ggc_pch_count_object (struct ggc_pch_data *d, void *x ATTRIBUTE_UNUSED,
> -   size_t size, bool is_string ATTRIBUTE_UNUSED,
> -   enum gt_types_enum type ATTRIBUTE_UNUSED)
> +   size_t size, bool is_string ATTRIBUTE_UNUSED)
>  {
>unsigned order;
>
> @@ -2274,8 +2264,7 @@ ggc_pch_this_base (struct ggc_pch_data *d, void *base)
>
>  char *
>  ggc_pch_alloc_object (struct ggc_pch_data *d, void *x ATTRIBUTE_UNUSED,
> -   size_t size, bool is_string ATTRIBUTE_UNUSED,
> -   enum gt_types_enum type ATTRIBUTE_UNUSED)
> +   size_t size, bool is_string ATTRIBUTE_UNUSED)
>  {
>unsigned order;
>char *result;

..., but left in other 'ATTRIBUTE_UNUSED's.

To enable another thing I'm working on, OK to push the attached clean-up
"GGC: Remove unused 'bool is_string' arguments to 
'ggc_pch_{count,alloc,write}_object'"?


Grüße
 Thomas


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
>From 1267d24dde89b2e8dfb8e5f3b6e2928052b344c5 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Sat, 1 Jul 2023 00:25:05 +0200
Subject: [PATCH] GGC: Remove unused 'bool is_string' arguments to
 'ggc_pch_{count,alloc,write}_object'

They're unused since the removal of 'gcc/ggc-zone.c' in 2013 Subversion r195426
(Git commit cd030c079e5e42fe3f49261fe01f384e6b7f0111) "Remove zone allocator".

Should any future 'gcc/ggc-[...].cc' ever need this again, it'll be a conscious
decision at that time.

	gcc/
	* ggc-internal.h (ggc_pch_count_object, ggc_pch_alloc_object)
	(ggc_pch_write_object): Remove 'bool is_string' argument.
	* ggc-common.cc: Adjust.
	* ggc-page.cc: Likewise.
---
 gcc/ggc-common.cc  |  9 +++--
 gcc/ggc-internal.h | 15 ++-
 gcc/ggc-page.cc|  6 +++---
 3 files changed, 12 insertions(+), 18 deletions(-)

diff --git a/gcc/ggc-common.cc b/gcc/ggc-common.cc
index db317f49993..173ab64cb73 100644
--- a/gcc/ggc-common.cc
+++ b/gcc/ggc-common.cc
@@ -336,8 +336,7 @@ ggc_call_count (ptr_data **slot, traversal_state *state)
 {
   struct ptr_data *d = *slot;
 
-  ggc_pch_count_object (state->d, d->obj, d->size,
-			d->note_ptr_fn == gt_pch_p_S);
+  ggc_pch_count_object (state->d, d->obj, d->size);
   state->count++;
   return 1;
 }
@@ -347,8 +346,7 @@ ggc_call_alloc (ptr_data **slot, traversal_state *state)
 {
   struct ptr_data *d = *slot;
 
-  d->new_addr = ggc_pch_alloc_object (state->d, d->obj, d->size,
-  d->note_ptr_fn == gt_pch_p_S);
+  d->new_addr = ggc_pch_alloc_object (state->d, d->obj, d->size);
   state->ptrs[state->ptrs_i++] = d;
   return 1;
 }
@@ -642,8 +640,7 @@ gt_pch_save (FILE *f)
   state.ptrs[i]->note_ptr_cookie,
   relocate_ptrs, &state);
   ggc_pch_write_object (state.d, state.f, state.ptrs[i]->obj,
-			state.ptrs[i]->new_addr, state.ptrs[i]->size,
-			state.ptrs[i]->note_ptr_fn == gt_pch_p_S);
+			state.ptrs[i]->new_addr, state.ptrs[i]->size);
   if (state.ptrs[i]->note_ptr_fn != gt_pch_p_S)
 	memcpy (state.ptrs[i]->ob

GTY: Explicitly reject 'string_length' option for (fields in) global variables (was: [PATCH] pch: Fix streaming of strings with embedded null bytes)

[Thomas Schwinge]

Hi!

On 2022-10-18T18:14:54-0400, Lewis Hyatt via Gcc-patches 
 wrote:
> [...] add a new
> GTY option "string_length" so that gt_pch_note_object can be informed the
> actual length it ought to use, [...]

> --- a/gcc/doc/gty.texi
> +++ b/gcc/doc/gty.texi
> @@ -196,7 +196,26 @@ static GTY((length("reg_known_value_size"))) rtx 
> *reg_known_value;
>  Note that the @code{length} option is only meant for use with arrays of
>  non-atomic objects, that is, objects that contain pointers pointing to
>  other GTY-managed objects.  For other GC-allocated arrays and strings
> -you should use @code{atomic}.
> +you should use @code{atomic} or @code{string_length}.
> +
> +@findex string_length
> +@item string_length ("@var{expression}")
> +
> +In order to simplify production of PCH, a structure member that is a plain
> +array of bytes (an optionally @code{const} and/or @code{unsigned} @code{char
> +*}) is treated specially by the infrastructure. Even if such an array has not
> +been allocated in GC-controlled memory, it will still be written properly 
> into
> +a PCH.  The machinery responsible for this needs to know the length of the
> +data; by default, the length is determined by calling @code{strlen} on the
> +pointer.  The @code{string_length} option specifies an alternate way to
> +determine the length, such as by inspecting another struct member:
> +
> +@smallexample
> +struct GTY(()) non_terminated_string @{
> +  size_t sz;
> +  const char * GTY((string_length ("%h.sz"))) data;
> +@};
> +@end smallexample

In preparation for another thing I'm working on, OK to push the attached
"GTY: Explicitly reject 'string_length' option for (fields in) global variables"
(with <https://inbox.sourceware.org/[TODO]> pointing to this message)?


Grüße
 Thomas


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
>From 9130fe7873c2e1b44ab2449bfe022837e26f710c Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Tue, 4 Jul 2023 11:46:50 +0200
Subject: [PATCH] GTY: Explicitly reject 'string_length' option for (fields in)
 global variables

This is preparational for another thing that I'm working on.  No change in
behavior -- other than a more explicit error message.

The 'string_length' option currently is not supported for (fields in) global
variables.  For example, if we apply the following (made-up) changes:

--- gcc/c-family/c-cppbuiltin.cc
+++ gcc/c-family/c-cppbuiltin.cc
@@ -1777 +1777 @@ struct GTY(()) lazy_hex_fp_value_struct
-  const char *hex_str;
+  const char * GTY((string_length("strlen(%h.hex_str) + 1"))) hex_str;

--- gcc/varasm.cc
+++ gcc/varasm.cc
@@ -66 +66 @@ along with GCC; see the file COPYING3.  If not see
-extern GTY(()) const char *first_global_object_name;
+extern GTY((string_length("strlen(%h.first_global_object_name) + 1"))) const char *first_global_object_name;

..., we get:

[...]
build/gengtype  \
-S [...]/source-gcc/gcc -I gtyp-input.list -w tmp-gtype.state
/bin/sh [...]/source-gcc/gcc/../move-if-change tmp-gtype.state gtype.state
build/gengtype  \
-r gtype.state
[...]/source-gcc/gcc/varasm.cc:66: global `first_global_object_name' has unknown option `string_length'
[...]/source-gcc/gcc/c-family/c-cppbuiltin.cc:1789: field `hex_str' of global `lazy_hex_fp_values[0]' has unknown option `string_length'
make[2]: *** [Makefile:2890: s-gtype] Error 1
[...]

These errors occur when writing "GC roots", where -- per my understanding --
'string_length' isn't relevant for actual GC purposes.  However, like
elsewhere, it is for PCH purposes, and simply accepting 'string_length' here
isn't sufficient: we'll still get '(gt_pointer_walker) >_pch_n_S' used in the
'struct ggc_root_tab' instances, and there's no easy way to change that to
instead use 'gt_pch_n_S2' with explicit 'size_t string_len' argument.  (At
least not sufficiently easy to justify spending any further time on, given that
I don't have an actual use for that feature.)

So, until an actual need arises, and/or to avoid the next person looking into
this having to figure out the same thing again, let's just document this
limitation:

[...]/source-gcc/gcc/varasm.cc:66: option `string_length' not supported for global `first_global_object_name'
[...]/source-gcc/gcc/c-family/c-cppbuiltin.cc:1789: option `string_length' not supported for field `hex_str' of global 

GTY: Enhance 'string_length' option documentation (was: 'unsigned int len' field in 'libcpp/include/symtab.h:struct ht_identifier' (was: [PATCH] pch: Fix streaming of strings with embedded null bytes)

[Thomas Schwinge]

Hi!

On 2023-07-04T15:56:23-0400, Lewis Hyatt via Gcc-patches 
 wrote:
> On Tue, Jul 4, 2023 at 11:50 AM Thomas Schwinge  
> wrote:
>> I came across this one here on my way working through another (somewhat
>> related) GTY issue.  I generally do understand the issue here, but do
>> have a question about 'unsigned int len' field in
>> 'libcpp/include/symtab.h:struct ht_identifier': [...]

> I don't think there is currently any possibility for a null byte to
> end up in an ht_identifier's string. I assumed that ht_identifier
> stores the length as an optimization (especially since it doesn't take
> up any extra space on 64-bit platforms, given the 32-bit hash code is
> stored as well there.) I created the string_length GTY markup mainly
> to support another patch that I have still pending review, which I
> thought would increase the likelihood of PCH needing to handle null
> bytes in general. When I did that, I added the markup to ht_identifier
> simply because the length was already there, so there was no reason
> not to add it. It does save a few cycles when streaming out the PCH,
> but I doubt it is meaningful.

Thanks for confirming.  OK thus to push the attached
"GTY: Enhance 'string_length' option documentation"?


Grüße
 Thomas


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
>From a31b6657c26ac70c6e03b8ad81cdcb873f905716 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Wed, 5 Jul 2023 08:38:49 +0200
Subject: [PATCH] GTY: Enhance 'string_length' option documentation

We're (currently) not aware of any actual use of 'ht_identifier's with NUL
characters embedded; its 'len' field appears to exist for optimization
purposes, since "forever".  Before 'struct ht_identifier' was added in
commit 2a967f3d3a45294640e155381ef549e0b8090ad4 (Subversion r42334), we had in
'gcc/cpplib.h:struct cpp_hashnode': 'unsigned short len', or earlier 'length',
earlier in 'gcc/cpphash.h:struct hashnode': 'unsigned short length', earlier
'size_t length' with comment: "length of token, for quick comparison", earlier
'int length', ever since the 'gcc/cpp*' files were added in
commit 7f2935c734c36f84ab62b20a04de465e19061333 (Subversion r9191).

This amends commit f3b957ea8b9dadfb1ed30f24f463529684b7a36a
"pch: Fix streaming of strings with embedded null bytes".

	gcc/
	* doc/gty.texi (GTY Options) : Enhance.
	libcpp/
	* include/symtab.h (struct ht_identifier): Document different
	rationale.
---
 gcc/doc/gty.texi| 11 +++
 libcpp/include/symtab.h |  4 +---
 2 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/gcc/doc/gty.texi b/gcc/doc/gty.texi
index 7bd064b5781..15f9fa07405 100644
--- a/gcc/doc/gty.texi
+++ b/gcc/doc/gty.texi
@@ -217,6 +217,17 @@ struct GTY(()) non_terminated_string @{
 @};
 @end smallexample
 
+Similarly, this is useful for (regular NUL-terminated) strings with
+NUL characters embedded (that the default @code{strlen} use would run
+afoul of):
+
+@smallexample
+struct GTY(()) multi_string @{
+  const char * GTY((string_length ("%h.len + 1"))) str;
+  size_t len;
+@};
+@end smallexample
+
 The @code{string_length} option currently is not supported for (fields
 in) global variables.
 @c <https://inbox.sourceware.org/87bkgqvlst@euler.schwinge.homeip.net>
diff --git a/libcpp/include/symtab.h b/libcpp/include/symtab.h
index c7ccc6db9f0..0c713f2ad30 100644
--- a/libcpp/include/symtab.h
+++ b/libcpp/include/symtab.h
@@ -29,9 +29,7 @@ along with this program; see the file COPYING3.  If not see
 typedef struct ht_identifier ht_identifier;
 typedef struct ht_identifier *ht_identifier_ptr;
 struct GTY(()) ht_identifier {
-  /* This GTY markup arranges that the null-terminated identifier would still
- stream to PCH correctly, if a null byte were to make its way into an
- identifier somehow.  */
+  /* We know the 'len'gth of the 'str'ing; use it in the GTY markup.  */
   const unsigned char * GTY((string_length ("1 + %h.len"))) str;
   unsigned int len;
   unsigned int hash_value;
-- 
2.34.1

GTY: Clean up obsolete 'bool needs_cast_p' field of 'gcc/gengtype.cc:struct walk_type_data' (was: [PATCH 3/3] remove gengtype support for param_is use_param, if_marked and splay tree allocators)

[Thomas Schwinge]

Hi!

On 2014-11-23T23:11:36-0500, tsaund...@mozilla.com wrote:
> gcc/
>
>   * plugin.c, plugin.def, ggc.h, ggc-common.c, gengtype.h, gengtype.c,
>   gengtype-state.c, gengtype-parse.c, gentype-lex.l, gcc-plugin.h,
>   doc/plugins.texi, doc/gty.texi: Remove support for if_marked and
>   param_is.

> --- a/gcc/gengtype.c
> +++ b/gcc/gengtype.c

> @@ -2861,39 +2733,6 @@ walk_type (type_p t, struct walk_type_data *d)
>if (d->used_length)
>  length = NULL;
>
> -[...]
> -   d->needs_cast_p = (t->kind != TYPE_POINTER
> -  && (nt->kind == TYPE_POINTER
> -  || nt->kind == TYPE_STRING));
> -[...]

OK to push the attached
"GTY: Clean up obsolete 'bool needs_cast_p' field of 'gcc/gengtype.cc:struct 
walk_type_data'"?
No change in the 'gengtype'-generated files in my test build.


Grüße
 Thomas


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
>From 12cad7f5b3bfd8b01c90f9e7817fd2d837f2802b Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Tue, 4 Jul 2023 22:47:48 +0200
Subject: [PATCH] GTY: Clean up obsolete 'bool needs_cast_p' field of
 'gcc/gengtype.cc:struct walk_type_data'

Last use disappeared in 2014 with
commit 63f5d5b818319129217e41bcb23db53f99ff11b0 (Subversion r218558)
"remove gengtype support for param_is use_param, if_marked and splay tree allocators".

	gcc/
	* gengtype.cc (struct walk_type_data): Remove 'needs_cast_p'.
	Adjust all users.
---
 gcc/gengtype.cc | 19 ---
 1 file changed, 8 insertions(+), 11 deletions(-)

diff --git a/gcc/gengtype.cc b/gcc/gengtype.cc
index 04dbb0de8bd..54d3c8aaec3 100644
--- a/gcc/gengtype.cc
+++ b/gcc/gengtype.cc
@@ -2447,7 +2447,6 @@ struct walk_type_data
   int used_length;
   type_p orig_s;
   const char *reorder_fn;
-  bool needs_cast_p;
   bool fn_wants_lvalue;
   bool in_record_p;
   int loopcounter;
@@ -2663,7 +2662,6 @@ walk_type (type_p t, struct walk_type_data *d)
   options_p oo;
   const struct nested_ptr_data *nested_ptr_d = NULL;
 
-  d->needs_cast_p = false;
   for (oo = d->opt; oo; oo = oo->next)
 if (strcmp (oo->name, "length") == 0 && oo->kind == OPTION_STRING)
   length = oo->info.string;
@@ -3186,7 +3184,6 @@ static void
 write_types_process_field (type_p f, const struct walk_type_data *d)
 {
   const struct write_types_data *wtd;
-  const char *cast = d->needs_cast_p ? "(void *)" : "";
   wtd = (const struct write_types_data *) d->cookie;
 
   switch (f->kind)
@@ -3195,8 +3192,8 @@ write_types_process_field (type_p f, const struct walk_type_data *d)
 case TYPE_UNDEFINED:
   gcc_unreachable ();
 case TYPE_POINTER:
-  oprintf (d->of, "%*s%s (%s%s", d->indent, "",
-	   wtd->subfield_marker_routine, cast, d->val);
+  oprintf (d->of, "%*s%s (%s", d->indent, "",
+	   wtd->subfield_marker_routine, d->val);
   if (wtd->param_prefix)
 	{
 	  if (f->u.p->kind == TYPE_SCALAR)
@@ -3229,8 +3226,8 @@ write_types_process_field (type_p f, const struct walk_type_data *d)
 	}
   oprintf (d->of, ");\n");
   if (d->reorder_fn && wtd->reorder_note_routine)
-	oprintf (d->of, "%*s%s (%s%s, %s, %s);\n", d->indent, "",
-		 wtd->reorder_note_routine, cast, d->val,
+	oprintf (d->of, "%*s%s (%s, %s, %s);\n", d->indent, "",
+		 wtd->reorder_note_routine, d->val,
 		 d->prev_val[3], d->reorder_fn);
   break;
 
@@ -3262,16 +3259,16 @@ write_types_process_field (type_p f, const struct walk_type_data *d)
 	   : nullptr);
 	  if (length_override)
 	{
-	  oprintf (d->of, "2 (%s%s, ", cast, d->val);
+	  oprintf (d->of, "2 (%s, ", d->val);
 	  output_escaped_param (d, length_override, "string_length");
 	}
 	  else
-	oprintf (d->of, " (%s%s", cast, d->val);
+	oprintf (d->of, " (%s", d->val);
 
 	  oprintf (d->of, ");\n");
 	  if (d->reorder_fn && wtd->reorder_note_routine)
-	oprintf (d->of, "%*s%s (%s%s, %s%s, %s);\n", d->indent, "",
-		 wtd->reorder_note_routine, cast, d->val, cast, d->val,
+	oprintf (d->of, "%*s%s (%s, %s, %s);\n", d->indent, "",
+		 wtd->reorder_note_routine, d->val, d->val,
 		 d->reorder_fn);
 	}
   break;
-- 
2.34.1

GTY: Clean up obsolete parametrized structs remnants (was: [PATCH 3/3] remove gengtype support for param_is use_param, if_marked and splay tree allocators)

[Thomas Schwinge]

Hi!

On 2014-11-23T23:11:36-0500, tsaund...@mozilla.com wrote:
> gcc/
>
>   * plugin.c, plugin.def, ggc.h, ggc-common.c, gengtype.h, gengtype.c,
>   gengtype-state.c, gengtype-parse.c, gentype-lex.l, gcc-plugin.h,
>   doc/plugins.texi, doc/gty.texi: Remove support for if_marked and
>   param_is.

> --- a/gcc/gengtype.h
> +++ b/gcc/gengtype.h

> @@ -153,11 +152,6 @@ enum typekind {
>TYPE_LANG_STRUCT, /* GCC front-end language specific structs.
> Various languages may have homonymous but
> different structs.  */
> -  TYPE_PARAM_STRUCT,/* Type for parametrized structs, e.g. hash_t
> -   hash-tables, ...  See (param_is, use_param,
> -   param1_is, param2_is,... use_param1,
> -   use_param_2,... use_params) GTY
> -   options.  */
>TYPE_USER_STRUCT   /* User defined type.  Walkers and markers for
>  this type are assumed to be provided by the
>  user.  */

OK to push the attached
"GTY: Clean up obsolete parametrized structs remnants"?


Grüße
 Thomas


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
>From 100039989c2bca5d98cb76a1bc3ef5b40bfc27ce Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Tue, 4 Jul 2023 22:47:48 +0200
Subject: [PATCH] GTY: Clean up obsolete parametrized structs remnants

Support removed in 2014 with
commit 63f5d5b818319129217e41bcb23db53f99ff11b0 (Subversion r218558)
"remove gengtype support for param_is use_param, if_marked and splay tree allocators".

	gcc/
	* gengtype-parse.cc: Clean up obsolete parametrized structs
	remnants.
	* gengtype.cc: Likewise.
---
 gcc/gengtype-parse.cc | 1 -
 gcc/gengtype.cc   | 6 ++
 2 files changed, 2 insertions(+), 5 deletions(-)

diff --git a/gcc/gengtype-parse.cc b/gcc/gengtype-parse.cc
index 2b2156c5f45..efee4171674 100644
--- a/gcc/gengtype-parse.cc
+++ b/gcc/gengtype-parse.cc
@@ -80,7 +80,6 @@ static const char *const token_names[] = {
   "...",
   "ptr_alias",
   "nested_ptr",
-  "a param_is option",
   "a number",
   "a scalar type",
   "an identifier",
diff --git a/gcc/gengtype.cc b/gcc/gengtype.cc
index 54d3c8aaec3..49ddba684af 100644
--- a/gcc/gengtype.cc
+++ b/gcc/gengtype.cc
@@ -1388,8 +1388,6 @@ adjust_field_rtx_def (type_p t, options_p ARG_UNUSED (opt))
At present:
- Converts pointer-to-char, with no length parameter, to TYPE_STRING;
- Similarly for arrays of pointer-to-char;
-   - Converts structures for which a parameter is provided to
- TYPE_PARAM_STRUCT;
- Handles "special" options.
 */
 
@@ -3654,7 +3652,7 @@ write_func_for_structure (type_p orig_s, type_p s,
 }
 
 
-/* Write out marker routines for STRUCTURES and PARAM_STRUCTS.  */
+/* Write out marker routines for STRUCTURES.  */
 
 static void
 write_types (outf_p output_header, type_p structures,
@@ -4002,7 +4000,7 @@ write_local_func_for_structure (const_type_p orig_s, type_p s)
   }
 }
 
-/* Write out local marker routines for STRUCTURES and PARAM_STRUCTS.  */
+/* Write out local marker routines for STRUCTURES.  */
 
 static void
 write_local (outf_p output_header, type_p structures)
-- 
2.34.1

GTY: Repair 'enum gty_token', 'token_names' desynchronization (was: [cxx-conversion] Support garbage-collected C++ templates)

[Thomas Schwinge]

Hi!

On 2012-08-10T11:06:46-0400, Diego Novillo  wrote:
>  * gengtype-lex.l (USER_GTY): Add pattern for "user".
>  * gengtype-parse.c (option): Handle USER_GTY.
>  (opts_have): New.
>  (type): Call it.
>  If the keyword 'user' is used, do not walk the fields
>  of the structure.
>  * gengtype.h (USER_GTY): Add.

These changes got incorporated in
commit 0823efedd0fb8669b7e840954bc54c3b2cf08d67 (Subversion r190402).

> --- a/gcc/gengtype-lex.l
> +++ b/gcc/gengtype-lex.l
> @@ -108,6 +108,7 @@ EOID  [^[:alnum:]_]
>   "enum"/{EOID}   { return ENUM; }
>   "ptr_alias"/{EOID}  { return PTR_ALIAS; }
>   "nested_ptr"/{EOID} { return NESTED_PTR; }
> +"user"/{EOID}{ return USER_GTY; }
>   [0-9]+  { return NUM; }
>   "param"[0-9]*"_is"/{EOID}   {
> *yylval = XDUPVAR (const char, yytext, yyleng, yyleng+1);

> --- a/gcc/gengtype-parse.c
> +++ b/gcc/gengtype-parse.c
> @@ -499,6 +499,10 @@ option (options_p prev)
> [...]

> --- a/gcc/gengtype.h
> +++ b/gcc/gengtype.h
> @@ -463,6 +463,7 @@ enum
>   ELLIPSIS,
>   PTR_ALIAS,
>   NESTED_PTR,
> +USER_GTY,
>   PARAM_IS,
>   NUM,
>   SCALAR,

This did add 'USER_GTY' to what nowadays is known as 'enum gty_token',
but didn't accordingly update 'gcc/gengtype-parse.c:token_names', leaving
those out of sync.  Updating 'gcc/gengtype-parse.c:token_value_format'
wasn't necessary, as:

/* print_token assumes that any token >= FIRST_TOKEN_WITH_VALUE may have
   a meaningful value to be printed.  */
FIRST_TOKEN_WITH_VALUE = PARAM_IS

This, in turn, got further confused -- or "fixed" -- by later changes:
2014 commit 63f5d5b818319129217e41bcb23db53f99ff11b0 (Subversion r218558)
"remove gengtype support for param_is use_param, if_marked and splay tree 
allocators",
which reciprocally missed corresponding clean-up.

OK to push the attached
"GTY: Repair 'enum gty_token', 'token_names' desynchronization"?


On top of that, I'll then re-submit an adjusted
<https://inbox.sourceware.org/873522vkmu@euler.schwinge.homeip.net>
"GTY: Clean up obsolete parametrized structs remnants".


Grüße
 Thomas


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
>From 8d2b040e825acdcddb7e1ff991fd538db13392f2 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Wed, 5 Jul 2023 11:10:55 +0200
Subject: [PATCH] GTY: Repair 'enum gty_token', 'token_names' desynchronization

For example, for the following (made-up) changes:

--- gcc/ggc-tests.cc
+++ gcc/ggc-tests.cc
@@ -258 +258 @@ class GTY((tag("1"))) some_subclass : public example_base
-class GTY((tag("2"))) some_other_subclass : public example_base
+class GTY((tag(user))) some_other_subclass : public example_base
@@ -384 +384 @@ test_chain_next ()
-struct GTY((user)) user_struct
+struct GTY((user user)) user_struct

..., we get unexpected "have a param_is option" diagnostics:

[...]
build/gengtype  \
-S [...]/source-gcc/gcc -I gtyp-input.list -w tmp-gtype.state
[...]/source-gcc/gcc/ggc-tests.cc:258: parse error: expected a string constant, have a param_is option
[...]/source-gcc/gcc/ggc-tests.cc:384: parse error: expected ')', have a param_is option
make[2]: *** [Makefile:2888: s-gtype] Error 1
[...]

This traces back to 2012 "Support garbage-collected C++ templates", which got
incorporated in commit 0823efedd0fb8669b7e840954bc54c3b2cf08d67
(Subversion r190402), which did add 'USER_GTY' to what nowadays is known as
'enum gty_token', but didn't accordingly update
'gcc/gengtype-parse.c:token_names', leaving those out of sync.  Updating
'gcc/gengtype-parse.c:token_value_format' wasn't necessary, as:

/* print_token assumes that any token >= FIRST_TOKEN_WITH_VALUE may have
   a meaningful value to be printed.  */
FIRST_TOKEN_WITH_VALUE = PARAM_IS

This, in turn, got further confused -- or "fixed" -- by later changes:
2014 commit 63f5d5b818319129217e41bcb23db53f99ff11b0 (Subversion r218558)
"remove gengtype support for param_is use_param, if_marked and splay tree allocators",
which reciprocally missed corresponding clean-up.

With that addressed via adding the missing '"user"' to 'token_names', and,
until

[v2] GTY: Clean up obsolete parametrized structs remnants (was: [PATCH 3/3] remove gengtype support for param_is use_param, if_marked and splay tree allocators)

[Thomas Schwinge]

Hi!

On 2023-07-05T10:16:09+0200, I wrote:
> On 2014-11-23T23:11:36-0500, tsaund...@mozilla.com wrote:
>> gcc/
>>
>>   * plugin.c, plugin.def, ggc.h, ggc-common.c, gengtype.h, gengtype.c,
>>   gengtype-state.c, gengtype-parse.c, gentype-lex.l, gcc-plugin.h,
>>   doc/plugins.texi, doc/gty.texi: Remove support for if_marked and
>>   param_is.
>
>> --- a/gcc/gengtype.h
>> +++ b/gcc/gengtype.h
>
>> @@ -153,11 +152,6 @@ enum typekind {
>>TYPE_LANG_STRUCT, /* GCC front-end language specific structs.
>> Various languages may have homonymous but
>> different structs.  */
>> -  TYPE_PARAM_STRUCT,/* Type for parametrized structs, e.g. hash_t
>> -   hash-tables, ...  See (param_is, use_param,
>> -   param1_is, param2_is,... use_param1,
>> -   use_param_2,... use_params) GTY
>> -   options.  */
>>TYPE_USER_STRUCT   /* User defined type.  Walkers and markers for
>>  this type are assumed to be provided by the
>>  user.  */
>
> OK to push the attached
> "GTY: Clean up obsolete parametrized structs remnants"?

Updated per
<https://inbox.sourceware.org/87jzveu08y@euler.schwinge.homeip.net>
"GTY: Repair 'enum gty_token', 'token_names' desynchronization", OK to
push the attached
v2 "GTY: Clean up obsolete parametrized structs remnants"?


Grüße
 Thomas


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
>From fed7429b8c19c4bed570d343169ba6a35ed088b0 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Tue, 4 Jul 2023 22:47:48 +0200
Subject: [PATCH] GTY: Clean up obsolete parametrized structs remnants

Support removed in 2014 with
commit 63f5d5b818319129217e41bcb23db53f99ff11b0 (Subversion r218558)
"remove gengtype support for param_is use_param, if_marked and splay tree allocators".

	gcc/
	* gengtype-parse.cc: Clean up obsolete parametrized structs
	remnants.
	* gengtype.cc: Likewise.
	* gengtype.h: Likewise.
---
 gcc/gengtype-parse.cc | 2 --
 gcc/gengtype.cc   | 6 ++
 gcc/gengtype.h| 3 +--
 3 files changed, 3 insertions(+), 8 deletions(-)

diff --git a/gcc/gengtype-parse.cc b/gcc/gengtype-parse.cc
index 8791b35a3da..6b6331cc228 100644
--- a/gcc/gengtype-parse.cc
+++ b/gcc/gengtype-parse.cc
@@ -82,7 +82,6 @@ static const char *const token_names[] = {
   "ptr_alias",
   "nested_ptr",
   "user",
-  "a param_is option",
   "a number",
   "a scalar type",
   "an identifier",
@@ -95,7 +94,6 @@ static const char *const token_names[] = {
 /* This array is indexed by token code minus FIRST_TOKEN_WITH_VALUE.  */
 /* Keep in sync with 'gengtype.h:enum gty_token'.  */
 static const char *const token_value_format[] = {
-  "%s",
   "'%s'",
   "'%s'",
   "'%s'",
diff --git a/gcc/gengtype.cc b/gcc/gengtype.cc
index 54d3c8aaec3..49ddba684af 100644
--- a/gcc/gengtype.cc
+++ b/gcc/gengtype.cc
@@ -1388,8 +1388,6 @@ adjust_field_rtx_def (type_p t, options_p ARG_UNUSED (opt))
At present:
- Converts pointer-to-char, with no length parameter, to TYPE_STRING;
- Similarly for arrays of pointer-to-char;
-   - Converts structures for which a parameter is provided to
- TYPE_PARAM_STRUCT;
- Handles "special" options.
 */
 
@@ -3654,7 +3652,7 @@ write_func_for_structure (type_p orig_s, type_p s,
 }
 
 
-/* Write out marker routines for STRUCTURES and PARAM_STRUCTS.  */
+/* Write out marker routines for STRUCTURES.  */
 
 static void
 write_types (outf_p output_header, type_p structures,
@@ -4002,7 +4000,7 @@ write_local_func_for_structure (const_type_p orig_s, type_p s)
   }
 }
 
-/* Write out local marker routines for STRUCTURES and PARAM_STRUCTS.  */
+/* Write out local marker routines for STRUCTURES.  */
 
 static void
 write_local (outf_p output_header, type_p structures)
diff --git a/gcc/gengtype.h b/gcc/gengtype.h
index 2122373edf2..13942900910 100644
--- a/gcc/gengtype.h
+++ b/gcc/gengtype.h
@@ -478,7 +478,6 @@ enum gty_token
   PTR_ALIAS,
   NESTED_PTR,
   USER_GTY,
-  UNUSED_PARAM_IS,
   NUM,
   SCALAR,
   ID,
@@ -489,7 +488,7 @@ enum gty_token
 
   /* print_token assumes that any token >= FIRST_TOKEN_WITH_VALUE may have
  a meaningful value to be printed.  */
-  FIRST_TOKEN_WITH_VALUE = UNUSED_PARAM_IS
+  FIRST_TOKEN_WITH_VALUE = NUM
 };
 
 
-- 
2.34.1

GGC, GTY: Tighten up a few things re 'reorder' option and strings

[Thomas Schwinge]

Hi!

OK to push the attached
"GGC, GTY: Tighten up a few things re 'reorder' option and strings"?


Grüße
 Thomas


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
>From 8751deeb7afdc8ece6a0645c8404f615144b1bd4 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Wed, 5 Jul 2023 15:34:56 +0200
Subject: [PATCH] GGC, GTY: Tighten up a few things re 'reorder' option and
 strings

..., which doesn't make sense in combination.

This, again, is primarily preparational for another change.

	gcc/
	* ggc-common.cc (gt_pch_note_reorder, gt_pch_save): Tighten up a
	few things re 'reorder' option and strings.
	* stringpool.cc (gt_pch_p_S): This is now 'gcc_unreachable'.
---
 gcc/ggc-common.cc | 18 ++
 gcc/stringpool.cc |  1 +
 2 files changed, 15 insertions(+), 4 deletions(-)

diff --git a/gcc/ggc-common.cc b/gcc/ggc-common.cc
index 173ab64cb73..bed7a9d4d02 100644
--- a/gcc/ggc-common.cc
+++ b/gcc/ggc-common.cc
@@ -314,6 +314,9 @@ gt_pch_note_reorder (void *obj, void *note_ptr_cookie,
   data = (struct ptr_data *)
 saving_htab->find_with_hash (obj, POINTER_HASH (obj));
   gcc_assert (data && data->note_ptr_cookie == note_ptr_cookie);
+  /* The GTY 'reorder' option doesn't make sense if we don't walk pointers,
+ such as for strings.  */
+  gcc_checking_assert (data->note_ptr_fn != gt_pch_p_S);
 
   data->reorder_fn = reorder_fn;
 }
@@ -636,12 +639,19 @@ gt_pch_save (FILE *f)
 	state.ptrs[i]->reorder_fn (state.ptrs[i]->obj,
    state.ptrs[i]->note_ptr_cookie,
    relocate_ptrs, &state);
-  state.ptrs[i]->note_ptr_fn (state.ptrs[i]->obj,
-  state.ptrs[i]->note_ptr_cookie,
-  relocate_ptrs, &state);
+  gt_note_pointers note_ptr_fn = state.ptrs[i]->note_ptr_fn;
+  gcc_checking_assert (note_ptr_fn != NULL);
+  /* 'gt_pch_p_S' enables certain special handling, but otherwise
+ corresponds to no 'note_ptr_fn'.  */
+  if (note_ptr_fn == gt_pch_p_S)
+	note_ptr_fn = NULL;
+  if (note_ptr_fn != NULL)
+	note_ptr_fn (state.ptrs[i]->obj, state.ptrs[i]->note_ptr_cookie,
+		 relocate_ptrs, &state);
   ggc_pch_write_object (state.d, state.f, state.ptrs[i]->obj,
 			state.ptrs[i]->new_addr, state.ptrs[i]->size);
-  if (state.ptrs[i]->note_ptr_fn != gt_pch_p_S)
+  if (state.ptrs[i]->reorder_fn != NULL
+	  || note_ptr_fn != NULL)
 	memcpy (state.ptrs[i]->obj, this_object, state.ptrs[i]->size);
 #if defined ENABLE_VALGRIND_ANNOTATIONS && defined VALGRIND_GET_VBITS
   if (UNLIKELY (get_vbits == 1))
diff --git a/gcc/stringpool.cc b/gcc/stringpool.cc
index 46aff39d7d5..8658e6ab52a 100644
--- a/gcc/stringpool.cc
+++ b/gcc/stringpool.cc
@@ -185,6 +185,7 @@ gt_pch_p_S (void *obj ATTRIBUTE_UNUSED, void *x ATTRIBUTE_UNUSED,
 	gt_pointer_operator op ATTRIBUTE_UNUSED,
 	void *cookie ATTRIBUTE_UNUSED)
 {
+  gcc_unreachable ();
 }
 
 /* PCH pointer-walking routine for strings.  */
-- 
2.34.1

GGC, GTY: No pointer walking for 'atomic' in PCH 'gt_pch_note_object' (was: Patch: New GTY ((atomic)) option)

[Thomas Schwinge]

Hi!

My original motivation for the following exercise what that, for example,
for: 'const unsigned char * GTY((atomic)) mode_table', we currently run
into 'const' mismatches, 'error: invalid conversion':

[...]
gtype-desc.cc: In function 'void gt_pch_nx_lto_file_decl_data(void*)':
gtype-desc.cc:6531:34: error: invalid conversion from 'const void*' to 
'void*' [-fpermissive]
 gt_pch_note_object ((*x).mode_table, x, 
gt_pch_p_18lto_file_decl_data);
  ^
In file included from [...]/source-gcc/gcc/hash-table.h:247:0,
 from [...]/source-gcc/gcc/coretypes.h:486,
 from gtype-desc.cc:23:
[...]/source-gcc/gcc/ggc.h:47:12: note:   initializing argument 1 of 'int 
gt_pch_note_object(void*, void*, gt_note_pointers, size_t)'
 extern int gt_pch_note_object (void *, void *, gt_note_pointers,
^
make[2]: *** [Makefile:1180: gtype-desc.o] Error 1
[...]

..., as I had reported as "'GTY' issues: (1) 'const' build error" in
<https://inbox.sourceware.org/87o7kxuq9s@euler.schwinge.homeip.net>
'Adjust LTO mode tables for "Machine_Mode: Extend machine_mode from 8 to 16 
bits"'.

That said:

On 2011-05-16T02:13:56+0200, "Nicola Pero"  
wrote:
> This patch adds a new GTY option, "atomic", which is similar to the identical 
> option you have with Boehm GC
> and which can be used with pointers to inform the GC/PCH machinery that they 
> point to an area of memory that
> contains no pointers (and hence needs no scanning).
>
> [...]

On top of that, OK to push the attached
"GGC, GTY: No pointer walking for 'atomic' in PCH 'gt_pch_note_object'"?
Appreciate review from a GGC, GTY-savvy person.

This depends on
<https://inbox.sourceware.org/87edlmtjwh@euler.schwinge.homeip.net>
"GGC, GTY: Tighten up a few things re 'reorder' option and strings".


Grüße
 Thomas


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
>From 2f12ce94166f411e4b9084b1c89738bb480343cc Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Tue, 4 Jul 2023 11:46:00 +0200
Subject: [PATCH] GGC, GTY: No pointer walking for 'atomic' in PCH
 'gt_pch_note_object'

Since it's inception in 2011 commit 555c3771903cc461949f06acf28f92fc067b6a1c
(Subversion r173996) "New GTY ((atomic)) option", the following rationale has
been given in (nowadays) 'gcc/gengtype.cc':

If a pointer type is marked as "atomic", we process the
field itself, but we don't walk the data that they point to.

There are two main cases where we walk types: to mark
pointers that are reachable, and to relocate pointers when
writing a PCH file.  In both cases, an atomic pointer is
itself marked or relocated, but the memory that it points
to is left untouched.  In the case of PCH, that memory will
be read/written unchanged to the PCH file.

Therefore, we may completely skip the boilerplate pointer walking, which we
didn't for PCH 'gt_pch_note_object'.

--- build-gcc/gcc/gt-c-c-decl.h	2023-06-26 08:59:55.120395571 +0200
+++ build-gcc/gcc/gt-c-c-decl.h	2023-07-05 15:58:36.286165439 +0200
@@ -1138,7 +1138,7 @@
 case TS_OPTIMIZATION:
   gt_pch_n_15cl_optimization ((*x).generic.optimization.opts);
   if ((*x).generic.optimization.optabs != NULL) {
-gt_pch_note_object ((*x).generic.optimization.optabs, x, gt_pch_p_14lang_tree_node);
+gt_pch_note_object ((*x).generic.optimization.optabs, x, NULL);
   }
   break;
 case TS_TARGET_OPTION:
--- build-gcc/gcc/gt-cp-tree.h	2023-06-26 08:59:55.120395571 +0200
+++ build-gcc/gcc/gt-cp-tree.h	2023-07-05 15:58:36.286165439 +0200
@@ -1452,7 +1452,7 @@
 case TS_OPTIMIZATION:
   gt_pch_n_15cl_optimization ((*x).generic.optimization.opts);
   if ((*x).generic.optimization.optabs != NULL) {
-gt_pch_note_object ((*x).generic.optimization.optabs, x, gt_pch_p_14lang_tree_node);
+gt_pch_note_object ((*x).generic.optimization.optabs, x, NULL);
   }
   break;
 case TS_TARGET_OPTION:
[...]

..., which is for 'gcc/tree-core.h':

struct GTY(()) tree_optimization_option {
  struct tree_base base;
  [...]
  struct cl_optimization *opts;
  [...]
  void *GTY ((atomic)) optabs;
  [...]

GGC: Remove 'const char *' 'gt_ggc_mx', 'gt_pch_nx' variants (was: [PATCH] support ggc hash_map and hash_set)

[Thomas Schwinge]

Hi!

On 2014-09-01T21:56:28-0400, tsaund...@mozilla.com wrote:
> [...] this part [...]

... became commit b086d5308de0d25444243f482f2f3d1dfd3a9a62
(Subversion r214834), which added GGC support to 'hash_map', 'hash_set',
and converted to those a number of 'htab' instances.

It doesn't really interfere with my ongoing work, but I have doubts about
two functions that were added here:

> --- a/gcc/ggc.h
> +++ b/gcc/ggc.h

> +static inline void
> +gt_ggc_mx (const char *s)
> +{
> +  ggc_test_and_set_mark (const_cast (s));
> +}
> +
> +static inline void
> +gt_pch_nx (const char *)
> +{
> +}

If (in current sources) I put '__builtin_abort' calls into these
functions, those don't trigger, so the functions are (currently) unused,
at least in my configuration.  Moreover, comparing these two to other
string-related 'gt_ggc_mx' functions in (nowadays) 'gcc/ggc-page.cc', and
string-related 'gt_pch_nx' functions in (nowadays) 'gcc/stringpool.cc'
(..., which already did exist back then in 2014), we find that this
'gt_ggc_mx' doesn't call 'gt_ggc_m_S', so doesn't get the special string
handling, and this 'gt_pch_nx' doesn't call 'gt_pch_n_S' and also doesn't
'gt_pch_note_object' manually, so I wonder how that ever worked?  So
maybe these two in fact never were used?  Should we dare to put in the
attached "GGC: Remove 'const char *' 'gt_ggc_mx', 'gt_pch_nx' variants"?


Grüße
 Thomas


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
>From a1341d0e75ab20ee9ba09a1a8428c9d3dd2fd54a Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Thu, 6 Jul 2023 17:44:35 +0200
Subject: [PATCH] GGC: Remove 'const char *' 'gt_ggc_mx', 'gt_pch_nx' variants

Those were added in 2014 commit b086d5308de0d25444243f482f2f3d1dfd3a9a62
(Subversion r214834) "support ggc hash_map  and hash_set".

If (in current sources) I put '__builtin_abort' calls into these functions,
those don't trigger, so the functions are (currently) unused, at least in my
configuration.  Moreover, comparing these two to other string-related
'gt_ggc_mx' functions in (nowadays) 'gcc/ggc-page.cc', and string-related
'gt_pch_nx' functions in (nowadays) 'gcc/stringpool.cc' (..., which already did
exist back then in 2014), we find that this 'gt_ggc_mx' doesn't call
'gt_ggc_m_S', so doesn't get the special string handling, and this 'gt_pch_nx'
doesn't call 'gt_pch_n_S' and also doesn't 'gt_pch_note_object' manually, so I
wonder how that ever worked?  So maybe these two in fact never were used?

	gcc/
	* ggc.h (gt_ggc_mx (const char *s), gt_pch_nx (const char *)):
	Remove.
---
 gcc/ggc.h | 11 ---
 1 file changed, 11 deletions(-)

diff --git a/gcc/ggc.h b/gcc/ggc.h
index 78eab7eaba6..1f3d665fc57 100644
--- a/gcc/ggc.h
+++ b/gcc/ggc.h
@@ -331,17 +331,6 @@ ggc_alloc_cleared_gimple_statement_stat (size_t s CXX_MEM_STAT_INFO)
   return (gimple *) ggc_internal_cleared_alloc (s PASS_MEM_STAT);
 }
 
-inline void
-gt_ggc_mx (const char *s)
-{
-  ggc_test_and_set_mark (const_cast (s));
-}
-
-inline void
-gt_pch_nx (const char *)
-{
-}
-
 inline void gt_pch_nx (bool) { }
 inline void gt_pch_nx (char) { }
 inline void gt_pch_nx (signed char) { }
-- 
2.34.1

Re: [PATCH] rust: build failure after NON_DEPENDENT_EXPR removal [PR111899]

[Thomas Schwinge]

Hi Patrick!

On 2023-10-20T13:36:30-0400, Patrick Palka  wrote:
> Built on x86_64-pc-linux-gnu, pushed to trunk as obvious (hopefully).
>
> -- >8 --
>
> This patch removes stray NON_DEPENDENT_EXPR checks following the removal
> of this tree code from the C++ FE.  (Since this restores the build I
> supppose it means the Rust FE never creates NON_DEPENDENT_EXPR trees in
> the first place, so no further analysis is needed.)

ACK, thanks!


For context: indeed, a non-trivial amount of C++ front end 'constexpr'
code was copied into the Rust front end, for implementing related Rust
functionality, mostly as part of the 2022 GSoC project
"Support for Constant Folding in Rust Frontend" (Faisal Abbas),
.

Yes, this should eventually be cleaned up (and merged with the original
C++ front end code, as much as feasible -- which I don't know whether or
to which extent it is).


Grüße
 Thomas


>   PR rust/111899
>
> gcc/rust/ChangeLog:
>
>   * backend/rust-constexpr.cc (potential_constant_expression_1):
>   Remove NON_DEPENDENT_EXPR handling.
>   * backend/rust-tree.cc (mark_exp_read): Likewise.
>   (mark_use): Likewise.
>   (lvalue_kind): Likewise.
> ---
>  gcc/rust/backend/rust-constexpr.cc | 1 -
>  gcc/rust/backend/rust-tree.cc  | 3 ---
>  2 files changed, 4 deletions(-)
>
> diff --git a/gcc/rust/backend/rust-constexpr.cc 
> b/gcc/rust/backend/rust-constexpr.cc
> index b28fa27b2d0..a7ae4166ea0 100644
> --- a/gcc/rust/backend/rust-constexpr.cc
> +++ b/gcc/rust/backend/rust-constexpr.cc
> @@ -6151,7 +6151,6 @@ potential_constant_expression_1 (tree t, bool 
> want_rval, bool strict, bool now,
>  case CLEANUP_POINT_EXPR:
>  case EXPR_STMT:
>  case PAREN_EXPR:
> -case NON_DEPENDENT_EXPR:
>/* For convenience.  */
>  case LOOP_EXPR:
>  case EXIT_EXPR:
> diff --git a/gcc/rust/backend/rust-tree.cc b/gcc/rust/backend/rust-tree.cc
> index 66e859cd70c..7040c75f825 100644
> --- a/gcc/rust/backend/rust-tree.cc
> +++ b/gcc/rust/backend/rust-tree.cc
> @@ -72,7 +72,6 @@ mark_exp_read (tree exp)
>  case ADDR_EXPR:
>  case INDIRECT_REF:
>  case FLOAT_EXPR:
> -case NON_DEPENDENT_EXPR:
>  case VIEW_CONVERT_EXPR:
>mark_exp_read (TREE_OPERAND (exp, 0));
>break;
> @@ -128,7 +127,6 @@ mark_use (tree expr, bool rvalue_p, bool read_p,
>switch (TREE_CODE (expr))
>  {
>  case COMPONENT_REF:
> -case NON_DEPENDENT_EXPR:
>recurse_op[0] = true;
>break;
>  case COMPOUND_EXPR:
> @@ -4520,7 +4518,6 @@ lvalue_kind (const_tree ref)
>lvalues.  */
>return (DECL_NONSTATIC_MEMBER_FUNCTION_P (ref) ? clk_none : 
> clk_ordinary);
>
> -case NON_DEPENDENT_EXPR:
>  case PAREN_EXPR:
>return lvalue_kind (TREE_OPERAND (ref, 0));
>
> --
> 2.42.0.411.g813d9a9188
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955

OpenMP/Fortran: Group handling of 'if' clause without and with modifier (was: [committed] Partial OpenMP 4.5 fortran support)

[Thomas Schwinge]

Hi!

On 2016-11-10T12:41:59+0100, Jakub Jelinek  wrote:
> gcc/fortran/

>   * gfortran.h [...]

>   (struct gfc_omp_clauses): Add [...]
>   [...]
>   [...] and if_exprs fields.

Etc.

OK to push (after testing) the attached
"OpenMP/Fortran: Group handling of 'if' clause without and with modifier"?
That makes an upcoming change a bit lighter.


Grüße
 Thomas


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
>From a6e15fe6b08e2ced98435739506f9fc10db96a63 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Tue, 24 Oct 2023 10:43:40 +0200
Subject: [PATCH] OpenMP/Fortran: Group handling of 'if' clause without and
 with modifier

The 'if' clause with modifier was introduced in
commit b4c3a85be96585374bf95c981ba2f602667cf5b7 (Subversion r242037)
"Partial OpenMP 4.5 fortran support", but -- in some instances -- didn't place
it next to the existing handling of 'if' clause without modifier.  Unify that;
no change in behavior.

	gcc/fortran/
	* dump-parse-tree.cc (show_omp_clauses): Group handling of 'if'
	clause without and with modifier.
	* frontend-passes.cc (gfc_code_walker): Likewise.
	* gfortran.h (gfc_omp_clauses): Likewise.
	* openmp.cc (gfc_free_omp_clauses): Likewise.
---
 gcc/fortran/dump-parse-tree.cc | 42 +-
 gcc/fortran/frontend-passes.cc |  4 ++--
 gcc/fortran/gfortran.h |  2 +-
 gcc/fortran/openmp.cc  |  4 ++--
 4 files changed, 26 insertions(+), 26 deletions(-)

diff --git a/gcc/fortran/dump-parse-tree.cc b/gcc/fortran/dump-parse-tree.cc
index 68122e3e6fd..cc4846e5d74 100644
--- a/gcc/fortran/dump-parse-tree.cc
+++ b/gcc/fortran/dump-parse-tree.cc
@@ -1593,6 +1593,27 @@ show_omp_clauses (gfc_omp_clauses *omp_clauses)
   show_expr (omp_clauses->if_expr);
   fputc (')', dumpfile);
 }
+  for (i = 0; i < OMP_IF_LAST; i++)
+if (omp_clauses->if_exprs[i])
+  {
+	static const char *ifs[] = {
+	  "CANCEL",
+	  "PARALLEL",
+	  "SIMD",
+	  "TASK",
+	  "TASKLOOP",
+	  "TARGET",
+	  "TARGET DATA",
+	  "TARGET UPDATE",
+	  "TARGET ENTER DATA",
+	  "TARGET EXIT DATA"
+	};
+  fputs (" IF(", dumpfile);
+  fputs (ifs[i], dumpfile);
+  fputs (": ", dumpfile);
+  show_expr (omp_clauses->if_exprs[i]);
+  fputc (')', dumpfile);
+}
   if (omp_clauses->final_expr)
 {
   fputs (" FINAL(", dumpfile);
@@ -1999,27 +2020,6 @@ show_omp_clauses (gfc_omp_clauses *omp_clauses)
   show_expr (omp_clauses->detach);
   fputc (')', dumpfile);
 }
-  for (i = 0; i < OMP_IF_LAST; i++)
-if (omp_clauses->if_exprs[i])
-  {
-	static const char *ifs[] = {
-	  "CANCEL",
-	  "PARALLEL",
-	  "SIMD",
-	  "TASK",
-	  "TASKLOOP",
-	  "TARGET",
-	  "TARGET DATA",
-	  "TARGET UPDATE",
-	  "TARGET ENTER DATA",
-	  "TARGET EXIT DATA"
-	};
-  fputs (" IF(", dumpfile);
-  fputs (ifs[i], dumpfile);
-  fputs (": ", dumpfile);
-  show_expr (omp_clauses->if_exprs[i]);
-  fputc (')', dumpfile);
-}
   if (omp_clauses->destroy)
 fputs (" DESTROY", dumpfile);
   if (omp_clauses->depend_source)
diff --git a/gcc/fortran/frontend-passes.cc b/gcc/fortran/frontend-passes.cc
index 536884b13f0..0378e0dba06 100644
--- a/gcc/fortran/frontend-passes.cc
+++ b/gcc/fortran/frontend-passes.cc
@@ -5652,6 +5652,8 @@ gfc_code_walker (gfc_code **c, walk_code_fn_t codefn, walk_expr_fn_t exprfn,
 			OMP_LIST_MAP, OMP_LIST_TO, OMP_LIST_FROM };
 		  size_t idx;
 		  WALK_SUBEXPR (co->ext.omp_clauses->if_expr);
+		  for (idx = 0; idx < OMP_IF_LAST; idx++)
+		WALK_SUBEXPR (co->ext.omp_clauses->if_exprs[idx]);
 		  WALK_SUBEXPR (co->ext.omp_clauses->final_expr);
 		  WALK_SUBEXPR (co->ext.omp_clauses->num_threads);
 		  WALK_SUBEXPR (co->ext.omp_clauses->chunk_size);
@@ -5667,8 +5669,6 @@ gfc_code_walker (gfc_code **c, walk_code_fn_t codefn, walk_expr_fn_t exprfn,
 		  WALK_SUBEXPR (co->ext.omp_clauses->num_tasks);
 		  WALK_SUBEXPR (co->ext.omp_clauses->priority);
 		  WALK_SUBEXPR (co->ext.omp_clauses->detach);
-		  for (idx = 0; idx < OMP_IF_LAST; idx++)
-		WALK_SUBEXPR (co->ext.omp_clauses->if_exprs[idx]);
 		  for (idx = 0; idx < ARRAY_SIZE (list_types); idx++)
 		for (n = co->ext.omp_clauses->lists[list_types[idx]];
 			 n; n = n->next)
diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
in

[PING] libffi: Consider '--with-build-sysroot=[...]' for target libraries' build-tree testing (instead of build-time 'CC' etc.) [PR109951] (was: [PATCH v5 GCC] libffi/test: Fix compilation for build s

[Thomas Schwinge]

Hi!

Ping.


Grüße
 Thomas


On 2023-09-12T12:58:27+0200, I wrote:
> Hi!
>
> On 2020-04-20T14:18:40+0100, "Maciej W. Rozycki via Gcc-patches" 
>  wrote:
>> Fix a problem with the libffi testsuite using a method to determine the
>> compiler to use resulting in the tool being different from one the
>> library has been built with, and causing a catastrophic failure from the
>> inability to actually choose any compiler at all in a cross-compilation
>> configuration.
>
> This has since, as far as I can tell, been resolved properly by H.J. Lu's
> GCC commit 5be7b66998127286fada45e4f23bd8a2056d553e,
> "libffi: Integrate build with GCC", and
> GCC commit 4824ed41ba7cd63e60fd9f8769a58b79935a90d1
> "libffi: Integrate testsuite with GCC testsuite".
>
>> Address this problem by providing a DejaGNU configuration file defining
>> the compiler to use, via the CC_FOR_TARGET TCL variable, set from $CC by
>> autoconf, which will have all the required options set for the target
>> compiler to build executables in the environment configured
>
> As we've found, this is conceptually problematic, as discussed in
> <https://inbox.sourceware.org/875y868a4b@euler.schwinge.homeip.net>
> "Consider '--with-build-sysroot=[...]' for target libraries' build-tree 
> testing (instead of build-time 'CC' etc.) [PR109951]".
> I therefore suggest to apply to GCC libffi the conceptually same changes
> as I've just pushed for libgomp:
> <https://inbox.sourceware.org/874jjzzqc2@euler.schwinge.homeip.net>
> "libgomp: Consider '--with-build-sysroot=[...]' for target libraries' 
> build-tree testing (instead of build-time 'CC' etc.) [PR91884, PR109951]".
> OK to push the attached
> "libffi: Consider '--with-build-sysroot=[...]' for target libraries' 
> build-tree testing (instead of build-time 'CC' etc.) [PR109951]"?
>
>
> Grüße
>  Thomas


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
>From 8b8654d04dcbb7f0a5947bc21efc5b9c60b3b6c6 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Mon, 11 Sep 2023 10:50:00 +0200
Subject: [PATCH] libffi: Consider '--with-build-sysroot=[...]' for target
 libraries' build-tree testing (instead of build-time 'CC' etc.) [PR109951]

Similar to commit fb5d27be272b71fb9026224535fc73f125ce3be7
"libgomp: Consider '--with-build-sysroot=[...]' for target libraries' build-tree testing (instead of build-time 'CC' etc.) [PR91884, PR109951]",
this is commit a0b48358cb1e70e161a87ec5deb7a4b25defba6b
"libffi/test: Fix compilation for build sysroot" done differently,
avoiding build-tree testing use of any random gunk that may appear in
build-time 'CC', 'CXX'.

	PR testsuite/109951
	libffi/
	* configure.ac: 'AC_SUBST(SYSROOT_CFLAGS_FOR_TARGET)'.
	: Don't set 'CC_FOR_TARGET', 'CXX_FOR_TARGET', instead
	set 'SYSROOT_CFLAGS_FOR_TARGET'.
	* Makefile.in: Regenerate.
	* configure: Likewise.
	* include/Makefile.in: Likewise.
	* man/Makefile.in: Likewise.
	* testsuite/Makefile.in: Likewise.
	* testsuite/lib/libffi.exp (libffi_target_compile): If
	'--with-build-sysroot=[...]' was specified, use it for build-tree
	testing.
---
 libffi/Makefile.in  |  1 +
 libffi/configure| 10 ++
 libffi/configure.ac |  5 +++--
 libffi/include/Makefile.in  |  1 +
 libffi/man/Makefile.in  |  1 +
 libffi/testsuite/Makefile.in|  1 +
 libffi/testsuite/lib/libffi.exp |  7 +++
 7 files changed, 20 insertions(+), 6 deletions(-)

diff --git a/libffi/Makefile.in b/libffi/Makefile.in
index 1d936b5c8a5..3a55212cc00 100644
--- a/libffi/Makefile.in
+++ b/libffi/Makefile.in
@@ -383,6 +383,7 @@ SED = @SED@
 SET_MAKE = @SET_MAKE@
 SHELL = @SHELL@
 STRIP = @STRIP@
+SYSROOT_CFLAGS_FOR_TARGET = @SYSROOT_CFLAGS_FOR_TARGET@
 TARGET = @TARGET@
 TARGETDIR = @TARGETDIR@
 TARGET_OBJ = @TARGET_OBJ@
diff --git a/libffi/configure b/libffi/configure
index 9eac9c907bf..f1efd6987a3 100755
--- a/libffi/configure
+++ b/libffi/configure
@@ -666,6 +666,7 @@ TESTSUBDIR_TRUE
 MAINT
 MAINTAINER_MODE_FALSE
 MAINTAINER_MODE_TRUE
+SYSROOT_CFLAGS_FOR_TARGET
 READELF
 CXXCPP
 CPP
@@ -11634,7 +11635,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 11637 "configure"
+#line 11638 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -11740,7 +11741,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 11743 "configure"
+#line 11744 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -15137,9 +15138,10 @@ _ACEOF
 
 
 
+
+
 cat > local.exp < local.exp <

[PING] libatomic: Consider '--with-build-sysroot=[...]' for target libraries' build-tree testing (instead of build-time 'CC' etc.) [PR109951] (was: [PATCH v4 1/5] libatomic/test: Fix compilation for b

[Thomas Schwinge]

Hi!

Ping.


Grüße
 Thomas


On 2023-09-12T13:03:28+0200, I wrote:
> Hi!
>
> On 2020-04-04T00:00:44+0100, "Maciej W. Rozycki via Gcc-patches" 
>  wrote:
>> Fix a problem with the libatomic testsuite using a method to determine
>> the compiler to use resulting in the tool being different from one the
>> library has been built with, and causing a catastrophic failure from the
>> lack of a suitable `--sysroot=' option where the `--with-build-sysroot='
>> configuration option has been used to build the compiler resulting in
>> the inability to link executables.
>>
>> Address this problem by providing a DejaGNU configuration file defining
>> the compiler to use, via the GCC_UNDER_TEST TCL variable, set from $CC
>> by autoconf, which will have all the required options set for the target
>> compiler to build executables in the environment configured
>
> As we've found, this is conceptually problematic, as discussed in
> <https://inbox.sourceware.org/875y868a4b@euler.schwinge.homeip.net>
> "Consider '--with-build-sysroot=[...]' for target libraries' build-tree 
> testing (instead of build-time 'CC' etc.)
> [PR109951]".
> I therefore suggest to apply to libatomic the conceptually same changes
> as I've just pushed for libgomp:
> <https://inbox.sourceware.org/874jjzzqc2@euler.schwinge.homeip.net>
> "libgomp: Consider '--with-build-sysroot=[...]' for target libraries' 
> build-tree testing (instead of build-time 'CC'
> etc.) [PR91884, PR109951]".
> OK to push the attached
> "libatomic: Consider '--with-build-sysroot=[...]' for target libraries' 
> build-tree testing (instead of build-time 'CC' etc.) [PR109951]"?
>
>
> Grüße
>  Thomas


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
>From 584bfb74e802b94c490b963bd05ed520b5c6e453 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Mon, 11 Sep 2023 11:36:31 +0200
Subject: [PATCH] libatomic: Consider '--with-build-sysroot=[...]' for target
 libraries' build-tree testing (instead of build-time 'CC' etc.) [PR109951]

Similar to commit fb5d27be272b71fb9026224535fc73f125ce3be7
"libgomp: Consider '--with-build-sysroot=[...]' for target libraries' build-tree testing (instead of build-time 'CC' etc.) [PR91884, PR109951]",
this is commit 5ff06d762a88077aff0fb637c931c64e6f47f93d
"libatomic/test: Fix compilation for build sysroot" done differently,
avoiding build-tree testing use of any random gunk that may appear in
build-time 'CC'.

	PR testsuite/109951
	libatomic/
	* configure.ac: 'AC_SUBST(SYSROOT_CFLAGS_FOR_TARGET)'.
	* Makefile.in: Regenerate.
	* configure: Likewise.
	* testsuite/Makefile.in: Likewise.
	* testsuite/lib/libatomic.exp (libatomic_init): If
	'--with-build-sysroot=[...]' was specified, use it for build-tree
	testing.
	* testsuite/libatomic-site-extra.exp.in (GCC_UNDER_TEST): Don't
	set.
	(SYSROOT_CFLAGS_FOR_TARGET): Set.
---
 libatomic/Makefile.in   | 1 +
 libatomic/configure | 7 +--
 libatomic/configure.ac  | 2 ++
 libatomic/testsuite/Makefile.in | 1 +
 libatomic/testsuite/lib/libatomic.exp   | 5 +
 libatomic/testsuite/libatomic-site-extra.exp.in | 2 +-
 6 files changed, 15 insertions(+), 3 deletions(-)

diff --git a/libatomic/Makefile.in b/libatomic/Makefile.in
index 83efe7d2694..2d2d64ee947 100644
--- a/libatomic/Makefile.in
+++ b/libatomic/Makefile.in
@@ -328,6 +328,7 @@ SET_MAKE = @SET_MAKE@
 SHELL = @SHELL@
 SIZES = @SIZES@
 STRIP = @STRIP@
+SYSROOT_CFLAGS_FOR_TARGET = @SYSROOT_CFLAGS_FOR_TARGET@
 VERSION = @VERSION@
 XCFLAGS = @XCFLAGS@
 XLDFLAGS = @XLDFLAGS@
diff --git a/libatomic/configure b/libatomic/configure
index 57f320753e1..629ad22e833 100755
--- a/libatomic/configure
+++ b/libatomic/configure
@@ -656,6 +656,7 @@ LIBAT_BUILD_VERSIONED_SHLIB_FALSE
 LIBAT_BUILD_VERSIONED_SHLIB_TRUE
 OPT_LDFLAGS
 SECTION_LDFLAGS
+SYSROOT_CFLAGS_FOR_TARGET
 enable_aarch64_lse
 libtool_VERSION
 MAINT
@@ -11402,7 +11403,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 11405 "configure"
+#line 11406 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -11508,7 +11509,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 11511 "configure&q

[PING^2] More '#ifdef ASM_OUTPUT_DEF' -> 'if (TARGET_SUPPORTS_ALIASES)' etc. (was: [PATCH][v2] Introduce TARGET_SUPPORTS_ALIASES)

[Thomas Schwinge]

Hi!

Ping.


Grüße
 Thomas


On 2023-09-19T10:47:56+0200, I wrote:
> Hi!
>
> Ping.
>
>
> Grüße
>  Thomas
>
>
> On 2023-09-08T14:02:50+0200, I wrote:
>> Hi!
>>
>> On 2017-08-10T15:42:13+0200, Jan Hubicka  wrote:
>>>> On 07/31/2017 11:57 AM, Yuri Gribov wrote:
>>>> > On Mon, Jul 31, 2017 at 9:04 AM, Martin Liška  wrote:
>>>> >> Doing the transformation suggested by Honza.
>>
>> ... which was:
>>
>> | On 2017-07-24T16:06:22+0200, Jan Hubicka  wrote:
>> | > we probably should turn ASM_OUTPUT_DEF ifdefs into a conditional 
>> compilation
>> | > incrementally.
>>
>>>> >From 78ee08b25d22125cb1fa248bac98ef1e84504761 Mon Sep 17 00:00:00 2001
>>>> From: marxin 
>>>> Date: Tue, 25 Jul 2017 13:11:28 +0200
>>>> Subject: [PATCH] Introduce TARGET_SUPPORTS_ALIASES
>>
>> ..., and got pushed as commit a8b522b483ebb8c972ecfde8779a7a6ec16aecd6
>> (Subversion r251048) "Introduce TARGET_SUPPORTS_ALIASES".
>>
>> I don't know if that was actually intentional here, or just an
>> "accident", but such changes actually allow that a back end may or may
>> not provide symbol aliasing support ('TARGET_SUPPORTS_ALIASES')
>> independent of '#ifdef ASM_OUTPUT_DEF', and in particular, depending not
>> just on static but instead on dynamic (run-time) configuration.  This is
>> relevant for the nvptx back end's '-malias' flag.
>>
>> There did remain a few instances where we currently still assume that
>> from '#ifdef ASM_OUTPUT_DEF' follows 'TARGET_SUPPORTS_ALIASES', which I'm
>> adjusting in the attached (with '--ignore-space-change', for easy review)
>> "More '#ifdef ASM_OUTPUT_DEF' -> 'if (TARGET_SUPPORTS_ALIASES)' etc.".
>> OK to push?
>>
>> These changes are necessary to cure nvptx regressions raised in
>> <https://inbox.sourceware.org/87iliurqt1@euler.schwinge.homeip.net>
>> "[nvptx] Use .alias directive for mptx >= 6.3", addressing the comment:
>> "[...] remains to be analyzed".
>>
>>
>> Grüße
>>  Thomas


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
>From 4c725226c3657adb775af274876de5077b8fbf45 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Thu, 7 Sep 2023 22:15:08 +0200
Subject: [PATCH] More '#ifdef ASM_OUTPUT_DEF' -> 'if
 (TARGET_SUPPORTS_ALIASES)' etc.

Per commit a8b522b483ebb8c972ecfde8779a7a6ec16aecd6 (Subversion r251048)
"Introduce TARGET_SUPPORTS_ALIASES", there is the idea that a back end may or
may not provide symbol aliasing support ('TARGET_SUPPORTS_ALIASES') independent
of '#ifdef ASM_OUTPUT_DEF', and in particular, depending not just on static but
instead on dynamic (run-time) configuration.  There did remain a few instances
where we currently still assume that from '#ifdef ASM_OUTPUT_DEF' follows
'TARGET_SUPPORTS_ALIASES'.  Change these to 'if (TARGET_SUPPORTS_ALIASES)',
similarly, or 'gcc_checking_assert (TARGET_SUPPORTS_ALIASES);'.

	gcc/
	* ipa-icf.cc (sem_item::target_supports_symbol_aliases_p):
	'gcc_checking_assert (TARGET_SUPPORTS_ALIASES);' before
	'return true;'.
	* ipa-visibility.cc (function_and_variable_visibility): Change
	'#ifdef ASM_OUTPUT_DEF' to 'if (TARGET_SUPPORTS_ALIASES)'.
	* varasm.cc (output_constant_pool_contents)
	[#ifdef ASM_OUTPUT_DEF]:
	'gcc_checking_assert (TARGET_SUPPORTS_ALIASES);'.
	(do_assemble_alias) [#ifdef ASM_OUTPUT_DEF]:
	'if (!TARGET_SUPPORTS_ALIASES)',
	'gcc_checking_assert (seen_error ());'.
	(assemble_alias): Change '#if !defined (ASM_OUTPUT_DEF)' to
	'if (!TARGET_SUPPORTS_ALIASES)'.
	(default_asm_output_anchor):
	'gcc_checking_assert (TARGET_SUPPORTS_ALIASES);'.
---
 gcc/ipa-icf.cc|  1 +
 gcc/ipa-visibility.cc |  8 +---
 gcc/varasm.cc | 13 ++---
 3 files changed, 16 insertions(+), 6 deletions(-)

diff --git a/gcc/ipa-icf.cc b/gcc/ipa-icf.cc
index 836d0914ded..bbdfd445397 100644
--- a/gcc/ipa-icf.cc
+++ b/gcc/ipa-icf.cc
@@ -218,6 +218,7 @@ sem_item::target_supports_symbol_aliases_p (void)
 #if !defined (ASM_OUTPUT_DEF) || (!defined(ASM_OUTPUT_WEAK_ALIAS) && !defined (ASM_WEAKEN_DECL))
   return false;
 #else
+  gcc_checking_assert (TARGET_SUPPORTS_ALIASES);
   return true;
 #endif
 }
diff --git a/gcc/ipa-visibility.cc b/gcc/ip

Re: [PATCH, OpenACC 2.7] Implement self clause for compute constructs

[Thomas Schwinge]

Hi!

On 2023-06-13T23:52:25+0800, Chung-Lin Tang via Gcc-patches 
 wrote:
> This patch implements the compiler side for the 'self' clause for compute 
> constructs:
> parallel, kernels, and serial.
>
> As you know, the actual "local device" device type for libgomp is not yet 
> implemented,
> so the libgomp side is basically just a simple duplicate of what 
> host-fallback is doing,

Thanks, and ACK.

> though everything else should be completed by this patch.

What also is missing is allowing nested OpenACC compute constructs, which
GCC currently rejects.  (Just removing the nesting restriction isn't
sufficient, I think: will also have to think about explicit/implicit data
(and other?) clauses in nested compute constructs, for example, so this
doesn't seem entirely trivial to implement.)  I'm fine to defer that item
until actual multicore CPU "device" support emerges (for avoidance of
doubt: we're not currently working on that).

> Tested on powerpc64le-linux/nvptx, x64_64-linux/amdgcn tests pending.
> Is this okay for trunk?

With minor textual conflicts resolved, I've pushed this to master branch
in commit 3a3596389c2e539cb8fd5dc5784a4e2afe193a2a
"OpenACC 2.7: Implement self clause for compute constructs", see
attached.


I'll then apply/submit a number of follow-on commits.


Grüße
 Thomas


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
>From 3a3596389c2e539cb8fd5dc5784a4e2afe193a2a Mon Sep 17 00:00:00 2001
From: Chung-Lin Tang 
Date: Tue, 13 Jun 2023 08:44:31 -0700
Subject: [PATCH] OpenACC 2.7: Implement self clause for compute constructs

This patch implements the 'self' clause for compute constructs: parallel,
kernels, and serial. This clause conditionally uses the local device
(the host mult-core CPU) as the executing device of the compute region.

The actual implementation of the "local device" device type inside libgomp
(presumably using pthreads) is still not yet completed, so the libgomp
side is still implemented the exact same as host-fallback mode. (so as of now,
it essentially behaves like the 'if' clause with the condition inverted)

gcc/c/ChangeLog:

	* c-parser.cc (c_parser_oacc_compute_clause_self): New function.
	(c_parser_oacc_all_clauses): Add new 'bool compute_p = false'
	parameter, add parsing of self clause when compute_p is true.
	(OACC_KERNELS_CLAUSE_MASK): Add PRAGMA_OACC_CLAUSE_SELF.
	(OACC_PARALLEL_CLAUSE_MASK): Likewise,
	(OACC_SERIAL_CLAUSE_MASK): Likewise.
	(c_parser_oacc_compute): Adjust call to c_parser_oacc_all_clauses to
	set compute_p argument to true.
	* c-typeck.cc (c_finish_omp_clauses): Add OMP_CLAUSE_SELF case.

gcc/cp/ChangeLog:

	* parser.cc (cp_parser_oacc_compute_clause_self): New function.
	(cp_parser_oacc_all_clauses): Add new 'bool compute_p = false'
	parameter, add parsing of self clause when compute_p is true.
	(OACC_KERNELS_CLAUSE_MASK): Add PRAGMA_OACC_CLAUSE_SELF.
	(OACC_PARALLEL_CLAUSE_MASK): Likewise,
	(OACC_SERIAL_CLAUSE_MASK): Likewise.
	(cp_parser_oacc_compute): Adjust call to c_parser_oacc_all_clauses to
	set compute_p argument to true.
	* pt.cc (tsubst_omp_clauses): Add OMP_CLAUSE_SELF case.
	* semantics.cc (c_finish_omp_clauses): Add OMP_CLAUSE_SELF case, merged
	with OMP_CLAUSE_IF case.

gcc/fortran/ChangeLog:

	* gfortran.h (typedef struct gfc_omp_clauses): Add self_expr field.
	* openmp.cc (enum omp_mask2): Add OMP_CLAUSE_SELF.
	(gfc_match_omp_clauses): Add handling for OMP_CLAUSE_SELF.
	(OACC_PARALLEL_CLAUSES): Add OMP_CLAUSE_SELF.
	(OACC_KERNELS_CLAUSES): Likewise.
	(OACC_SERIAL_CLAUSES): Likewise.
	(resolve_omp_clauses): Add handling for omp_clauses->self_expr.
	* trans-openmp.cc (gfc_trans_omp_clauses): Add handling of
	clauses->self_expr and building of OMP_CLAUSE_SELF tree clause.
	(gfc_split_omp_clauses): Add handling of self_expr field copy.

gcc/ChangeLog:

	* gimplify.cc (gimplify_scan_omp_clauses): Add OMP_CLAUSE_SELF case.
	(gimplify_adjust_omp_clauses): Likewise.
	* omp-expand.cc (expand_omp_target): Add OMP_CLAUSE_SELF expansion code,
	* omp-low.cc (scan_sharing_clauses): Add OMP_CLAUSE_SELF case.
	* tree-core.h (enum omp_clause_code): Add OMP_CLAUSE_SELF enum.
	* tree-nested.cc (convert_nonlocal_omp_clauses): Add OMP_CLAUSE_SELF
	case.
	(convert_local_omp_clauses): Likewise.
	* tree-pretty-print.cc (dump_omp_clause): Add OMP_CLAUSE_SELF case.
	* tree.cc (omp_clause_num_ops): Add OMP_CLAUSE_SELF entry.
	(omp_clause_code_name): Likewise.
	* tree.h (OMP_CLAUSE_SELF_EXPR): New macro.

gcc/testsuite/ChangeLog:

	* c-c++-common/goacc/self-clause-1.c: New test.
	* c-c++-common/goacc/self-clause-2.c: New test.
	* gfortran.dg/goacc/self.f95: New test.

include/ChangeLog:

	* gomp-constants.h (GOACC_FLAG_LOCAL_DEVICE): New flag bit value.

libgomp/ChangeLog:

	* oacc-parallel.c (GOACC_parallel_keyed): Add code to handle
	GO

Enable 'c-c++-common/goacc/{if,self}-clause-1.c' for C++ (was: [PATCH, OpenACC 2.7] Implement self clause for compute constructs)

[Thomas Schwinge]

Hi!

On 2023-10-25T10:57:06+0200, I wrote:
> With minor textual conflicts resolved, I've pushed this to master branch
> in commit 3a3596389c2e539cb8fd5dc5784a4e2afe193a2a
> "OpenACC 2.7: Implement self clause for compute constructs", see
> attached.
>
>
> I'll then apply/submit a number of follow-on commits.

> --- /dev/null
> +++ b/gcc/testsuite/c-c++-common/goacc/self-clause-1.c
> @@ -0,0 +1,22 @@
> +/* { dg-skip-if "not yet" { c++ } } */

Pushed to master branch commit 76cc5463227308c4dd2b70ccfe04d2b5361db0fe
"Enable 'c-c++-common/goacc/{if,self}-clause-1.c' for C++", see attached.

> +
> +void
> +f (int b)
> +{
> +  struct { int i; } *p;
> +
> +#pragma acc parallel self self(b) /* { dg-error "too many 'self' clauses" } 
> */
> +  ;
> +#pragma acc parallel self(*p) /* { dg-error "used struct type value where 
> scalar is required" } */
> +  ;
> +
> +#pragma acc kernels self self(b) /* { dg-error "too many 'self' clauses" } */
> +  ;
> +#pragma acc kernels self(*p) /* { dg-error "used struct type value where 
> scalar is required" } */
> +  ;
> +
> +#pragma acc serial self self(b) /* { dg-error "too many 'self' clauses" } */
> +  ;
> +#pragma acc serial self(*p) /* { dg-error "used struct type value where 
> scalar is required" } */
> +  ;
> +}


Grüße
 Thomas


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
>From 76cc5463227308c4dd2b70ccfe04d2b5361db0fe Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Fri, 20 Oct 2023 14:07:37 +0200
Subject: [PATCH] Enable 'c-c++-common/goacc/{if,self}-clause-1.c' for C++

As discovered via recent
commit 3a3596389c2e539cb8fd5dc5784a4e2afe193a2a
"OpenACC 2.7: Implement self clause for compute constructs",
'c-c++-common/goacc/if-clause-1.c', which the new
'c-c++-common/goacc/self-clause-1.c' was copied from, was not enabled for C++.

	gcc/testsuite/
	* c-c++-common/goacc/if-clause-1.c: Enable for C++
	* c-c++-common/goacc/self-clause-1.c: Likewise.
---
 gcc/testsuite/c-c++-common/goacc/if-clause-1.c   |  6 --
 gcc/testsuite/c-c++-common/goacc/self-clause-1.c | 14 ++
 2 files changed, 14 insertions(+), 6 deletions(-)

diff --git a/gcc/testsuite/c-c++-common/goacc/if-clause-1.c b/gcc/testsuite/c-c++-common/goacc/if-clause-1.c
index 85abf1659e9..d78520bdd1b 100644
--- a/gcc/testsuite/c-c++-common/goacc/if-clause-1.c
+++ b/gcc/testsuite/c-c++-common/goacc/if-clause-1.c
@@ -1,4 +1,4 @@
-/* { dg-skip-if "not yet" { c++ } } */
+/* See also 'self-clause-1.c'.  */
 
 void
 f (void)
@@ -6,5 +6,7 @@ f (void)
   struct { int i; } *p;
 #pragma acc data copyout(p) if(1) if(1) /* { dg-error "too many 'if' clauses" } */
   ;
-#pragma acc update device(p) if(*p) /* { dg-error "used struct type value where scalar is required" } */
+#pragma acc update device(p) if(*p)
+  /* { dg-error {used struct type value where scalar is required} {} { target c } .-1 }
+ { dg-error {could not convert '\* p' from 'f\(\)::' to 'bool'} {} { target c++ } .-2 } */
 }
diff --git a/gcc/testsuite/c-c++-common/goacc/self-clause-1.c b/gcc/testsuite/c-c++-common/goacc/self-clause-1.c
index ed5d072e81f..fe892bea210 100644
--- a/gcc/testsuite/c-c++-common/goacc/self-clause-1.c
+++ b/gcc/testsuite/c-c++-common/goacc/self-clause-1.c
@@ -1,4 +1,4 @@
-/* { dg-skip-if "not yet" { c++ } } */
+/* See also 'if-clause-1.c'.  */
 
 void
 f (int b)
@@ -7,16 +7,22 @@ f (int b)
 
 #pragma acc parallel self self(b) /* { dg-error "too many 'self' clauses" } */
   ;
-#pragma acc parallel self(*p) /* { dg-error "used struct type value where scalar is required" } */
+#pragma acc parallel self(*p)
+  /* { dg-error {used struct type value where scalar is required} {} { target c } .-1 }
+ { dg-error {could not convert '\* p' from 'f\(int\)::' to 'bool'} {} { target c++ } .-2 } */
   ;
 
 #pragma acc kernels self self(b) /* { dg-error "too many 'self' clauses" } */
   ;
-#pragma acc kernels self(*p) /* { dg-error "used struct type value where scalar is required" } */
+#pragma acc kernels self(*p)
+  /* { dg-error {used struct type value where scalar is required} {} { target c } .-1 }
+ { dg-error {could not convert '\* p' from 'f\(int\)::' to 'bool'} {} { target c++ } .-2 } */
   ;
 
 #pragma acc serial self self(b) /* { dg-error "too many 'self' clauses" } */
   ;
-#pragma acc serial self(*p) /* { dg-error "used struct type value where scalar is required" } */
+#pragma acc serial self(*p)
+  /* { dg-error {used struct type value where scalar is required} {} { target c } .-1 }
+ { dg-error {could not convert '\* p' from 'f\(int\)::' to 'bool'} {} { target c++ } .-2 } */
   ;
 }
-- 
2.34.1

Disentangle handling of OpenACC 'host', 'self' pragma tokens (was: [PATCH, OpenACC 2.7] Implement self clause for compute constructs)

[Thomas Schwinge]

Hi!

On 2023-10-25T10:57:06+0200, I wrote:
> With minor textual conflicts resolved, I've pushed this to master branch
> in commit 3a3596389c2e539cb8fd5dc5784a4e2afe193a2a
> "OpenACC 2.7: Implement self clause for compute constructs", see
> attached.
>
>
> I'll then apply/submit a number of follow-on commits.

I found this:

> --- a/gcc/c/c-parser.cc
> +++ b/gcc/c/c-parser.cc

>  static tree
>  c_parser_oacc_all_clauses (c_parser *parser, omp_clause_mask mask,
> -const char *where, bool finish_p = true)
> +const char *where, bool finish_p = true,
> +bool compute_p = false)
>  {
>tree clauses = NULL;
>bool first = true;
> @@ -18064,7 +18100,18 @@ c_parser_oacc_all_clauses (c_parser *parser, 
> omp_clause_mask mask,
>   c_parser_consume_token (parser);
>
>here = c_parser_peek_token (parser)->location;
> -  c_kind = c_parser_omp_clause_name (parser);
> +
> +  /* For OpenACC compute directives */
> +  if (compute_p
> +   && c_parser_next_token_is (parser, CPP_NAME)
> +   && !strcmp (IDENTIFIER_POINTER (c_parser_peek_token (parser)->value),
> +   "self"))
> + {
> +   c_kind = PRAGMA_OACC_CLAUSE_SELF;
> +   c_parser_consume_token (parser);
> + }
> +  else
> + c_kind = c_parser_omp_clause_name (parser);

..., and similarly in the C++ and (to a lesser extent) Fortran front ends
a bit twisted, and pushed to master branch
commit c92509d9fd98e02d17ab1610f696c88f606dcdf4
"Disentangle handling of OpenACC 'host', 'self' pragma tokens", see
attached.


Grüße
 Thomas


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
>From c92509d9fd98e02d17ab1610f696c88f606dcdf4 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Fri, 20 Oct 2023 14:47:58 +0200
Subject: [PATCH] Disentangle handling of OpenACC 'host', 'self' pragma tokens

'gcc/c-family/c-pragma.h:pragma_omp_clause' already defines
'PRAGMA_OACC_CLAUSE_SELF', but it has no longer been used for the 'update'
directive's 'self' clause as of 2018
commit 829c6349e96c5bfa8603aaef8858b38e237a2f33 (Subversion r261813)
"Update OpenACC data clause semantics to the 2.5 behavior".  That one instead
mapped the 'self' pragma token to the 'host' one (same semantics).  That means
that we're later not able to tell whether originally we had seen 'self' or
'host', which was OK as long as only the 'update' directive had a 'self'
clause.  However, as of recent commit 3a3596389c2e539cb8fd5dc5784a4e2afe193a2a
"OpenACC 2.7: Implement self clause for compute constructs", also OpenACC
compute constructs may have a 'self' clause -- with different semantics.  That
means, we need to know which OpenACC directive we're parsing clauses for, which
can be done in a simpler way than in that commit, similar to how the OpenMP
'to' clause is handled.

While at that, clarify that (already in OpenACC 2.0a)
"The 'host' clause is a synonym for the 'self' clause." -- not the other way
round.

	gcc/c/
	* c-parser.cc (c_parser_omp_clause_name): Return
	'PRAGMA_OACC_CLAUSE_SELF' for "self".
	(c_parser_oacc_data_clause, OACC_UPDATE_CLAUSE_MASK): Adjust.
	(c_parser_oacc_all_clauses): Remove 'bool compute_p' formal
	parameter, and instead locally determine whether we're called for
	an OpenACC compute construct or OpenACC 'update' directive.
	(c_parser_oacc_compute): Adjust.
	gcc/cp/
	* parser.cc (cp_parser_omp_clause_name): Return
	'PRAGMA_OACC_CLAUSE_SELF' for "self".
	(cp_parser_oacc_data_clause, OACC_UPDATE_CLAUSE_MASK): Adjust.
	(cp_parser_oacc_all_clauses): Remove 'bool compute_p' formal
	parameter, and instead locally determine whether we're called for
	an OpenACC compute construct or OpenACC 'update' directive.
	(cp_parser_oacc_compute): Adjust.
	gcc/fortran/
	* openmp.cc (omp_mask2): Split 'OMP_CLAUSE_HOST_SELF' into
	'OMP_CLAUSE_SELF', 'OMP_CLAUSE_HOST'.
	(gfc_match_omp_clauses, OACC_UPDATE_CLAUSES): Adjust.
---
 gcc/c/c-parser.cc | 38 +-
 gcc/cp/parser.cc  | 39 +--
 gcc/fortran/openmp.cc | 27 ++-
 3 files changed, 48 insertions(+), 56 deletions(-)

diff --git a/gcc/c/c-parser.cc b/gcc/c/c-parser.cc
index a82f5afeff7..5213a57a1ec 100644
--- 

Consistently order 'OMP_CLAUSE_SELF' right after 'OMP_CLAUSE_IF' (was: [PATCH, OpenACC 2.7] Implement self clause for compute constructs)

[Thomas Schwinge]

Hi!

On 2023-10-25T10:57:06+0200, I wrote:
> With minor textual conflicts resolved, I've pushed this to master branch
> in commit 3a3596389c2e539cb8fd5dc5784a4e2afe193a2a
> "OpenACC 2.7: Implement self clause for compute constructs", see
> attached.
>
>
> I'll then apply/submit a number of follow-on commits.

> From 3a3596389c2e539cb8fd5dc5784a4e2afe193a2a Mon Sep 17 00:00:00 2001
> From: Chung-Lin Tang 
> Date: Tue, 13 Jun 2023 08:44:31 -0700
> Subject: [PATCH] OpenACC 2.7: Implement self clause for compute constructs

> it essentially behaves like the 'if' clause with the condition inverted)

Pushed to master branch commit a5e919027fdb1900a6f2d64f763c99dbaf98aee6
"Consistently order 'OMP_CLAUSE_SELF' right after 'OMP_CLAUSE_IF'", see
attached.


Grüße
 Thomas


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
>From a5e919027fdb1900a6f2d64f763c99dbaf98aee6 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Mon, 23 Oct 2023 14:24:44 +0200
Subject: [PATCH] Consistently order 'OMP_CLAUSE_SELF' right after
 'OMP_CLAUSE_IF'

As noted in recent commit 3a3596389c2e539cb8fd5dc5784a4e2afe193a2a
"OpenACC 2.7: Implement self clause for compute constructs", the OpenACC 'self'
clause very much relates to the 'if' clause, and therefore copies a lot of the
latter's handling.  Therefore it makes sense to also place this handling in
proximity to that of the 'if' clause, which was done in a lot but not all
instances.

	gcc/
	* tree-core.h (omp_clause_code): Move 'OMP_CLAUSE_SELF' after
	'OMP_CLAUSE_IF'.
	* tree-pretty-print.cc (dump_omp_clause): Adjust.
	* tree.cc (omp_clause_num_ops, omp_clause_code_name): Likewise.
	* tree.h: Likewise.
---
 gcc/tree-core.h  |  6 +++---
 gcc/tree-pretty-print.cc | 13 +++--
 gcc/tree.cc  |  4 ++--
 gcc/tree.h   |  4 ++--
 4 files changed, 14 insertions(+), 13 deletions(-)

diff --git a/gcc/tree-core.h b/gcc/tree-core.h
index cfe37c1d627..4dc36827d32 100644
--- a/gcc/tree-core.h
+++ b/gcc/tree-core.h
@@ -389,6 +389,9 @@ enum omp_clause_code {
   /* OpenACC/OpenMP clause: if (scalar-expression).  */
   OMP_CLAUSE_IF,
 
+  /* OpenACC clause: self.  */
+  OMP_CLAUSE_SELF,
+
   /* OpenMP clause: num_threads (integer-expression).  */
   OMP_CLAUSE_NUM_THREADS,
 
@@ -527,9 +530,6 @@ enum omp_clause_code {
 
   /* OpenACC clause: nohost.  */
   OMP_CLAUSE_NOHOST,
-
-  /* OpenACC clause: self.  */
-  OMP_CLAUSE_SELF,
 };
 
 #undef DEFTREESTRUCT
diff --git a/gcc/tree-pretty-print.cc b/gcc/tree-pretty-print.cc
index 39ec1df9394..1fadd752d05 100644
--- a/gcc/tree-pretty-print.cc
+++ b/gcc/tree-pretty-print.cc
@@ -587,6 +587,13 @@ dump_omp_clause (pretty_printer *pp, tree clause, int spc, dump_flags_t flags)
   pp_right_paren (pp);
   break;
 
+case OMP_CLAUSE_SELF:
+  pp_string (pp, "self(");
+  dump_generic_node (pp, OMP_CLAUSE_SELF_EXPR (clause),
+			 spc, flags, false);
+  pp_right_paren (pp);
+  break;
+
 case OMP_CLAUSE_NUM_THREADS:
   pp_string (pp, "num_threads(");
   dump_generic_node (pp, OMP_CLAUSE_NUM_THREADS_EXPR (clause),
@@ -1453,12 +1460,6 @@ dump_omp_clause (pretty_printer *pp, tree clause, int spc, dump_flags_t flags)
 			 false);
   pp_right_paren (pp);
   break;
-case OMP_CLAUSE_SELF:
-  pp_string (pp, "self(");
-  dump_generic_node (pp, OMP_CLAUSE_SELF_EXPR (clause),
-			 spc, flags, false);
-  pp_right_paren (pp);
-  break;
 default:
   gcc_unreachable ();
 }
diff --git a/gcc/tree.cc b/gcc/tree.cc
index c38b09c431b..cfead156ddf 100644
--- a/gcc/tree.cc
+++ b/gcc/tree.cc
@@ -280,6 +280,7 @@ unsigned const char omp_clause_num_ops[] =
   1, /* OMP_CLAUSE__CONDTEMP_  */
   1, /* OMP_CLAUSE__SCANTEMP_  */
   1, /* OMP_CLAUSE_IF  */
+  1, /* OMP_CLAUSE_SELF */
   1, /* OMP_CLAUSE_NUM_THREADS  */
   1, /* OMP_CLAUSE_SCHEDULE  */
   0, /* OMP_CLAUSE_NOWAIT  */
@@ -326,7 +327,6 @@ unsigned const char omp_clause_num_ops[] =
   0, /* OMP_CLAUSE_IF_PRESENT */
   0, /* OMP_CLAUSE_FINALIZE */
   0, /* OMP_CLAUSE_NOHOST */
-  1, /* OMP_CLAUSE_SELF */
 };
 
 const char * const omp_clause_code_name[] =
@@ -372,6 +372,7 @@ const char * const omp_clause_code_name[] =
   "_condtemp_",
   "_scantemp_",
   "if",
+  "self",
   "num_threads",
   "schedule",
   "nowait",
@@ -418,7 +419,6 @@ const char * const omp_clause_code_name[] =
   "if_present",
   "finalize",
   "nohost",
-  "self",
 };
 
 /* Unless specific to OpenACC, we tend to internally mai

Extend test suite coverage for OpenACC 'self' clause for compute constructs (was: [PATCH, OpenACC 2.7] Implement self clause for compute constructs)

[Thomas Schwinge]

Hi!

On 2023-10-25T10:57:06+0200, I wrote:
> With minor textual conflicts resolved, I've pushed this to master branch
> in commit 3a3596389c2e539cb8fd5dc5784a4e2afe193a2a
> "OpenACC 2.7: Implement self clause for compute constructs", see
> attached.
>
>
> I'll then apply/submit a number of follow-on commits.

> From 3a3596389c2e539cb8fd5dc5784a4e2afe193a2a Mon Sep 17 00:00:00 2001
> From: Chung-Lin Tang 
> Date: Tue, 13 Jun 2023 08:44:31 -0700
> Subject: [PATCH] OpenACC 2.7: Implement self clause for compute constructs

>  .../c-c++-common/goacc/self-clause-1.c|  22 +
>  .../c-c++-common/goacc/self-clause-2.c|  17 +
>  gcc/testsuite/gfortran.dg/goacc/self.f95  |  53 +

>  .../libgomp.oacc-c-c++-common/self-1.c| 962 ++

I found that insufficient, and added some more.  Pushed to
master branch commit 047841a68ebf5f991e842961f9e54f3c10b94f2c
"Extend test suite coverage for OpenACC 'self' clause for compute constructs",
see attached.  This is mostly just adapting and cross-linking some
existing 'if' clause test cases.  (..., which turned up a problem when
the 'self' clause is used with OpenACC 'kernels'.)


Grüße
 Thomas


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
>From 047841a68ebf5f991e842961f9e54f3c10b94f2c Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Mon, 23 Oct 2023 14:53:29 +0200
Subject: [PATCH] Extend test suite coverage for OpenACC 'self' clause for
 compute constructs

... on top of what was provided in recent
commit 3a3596389c2e539cb8fd5dc5784a4e2afe193a2a
"OpenACC 2.7: Implement self clause for compute constructs".

	gcc/testsuite/
	* c-c++-common/goacc/if-clause-2.c: Enhance.
	* c-c++-common/goacc/self-clause-1.c: Likewise.
	* c-c++-common/goacc/self-clause-2.c: Likewise.
	* gfortran.dg/goacc/if.f95: Likewise.
	* gfortran.dg/goacc/kernels-tree.f95: Likewise.
	* gfortran.dg/goacc/parallel-tree.f95: Likewise.
	* gfortran.dg/goacc/self.f95: Likewise.
	libgomp/
	* testsuite/libgomp.oacc-c-c++-common/if-1.c: Enhance.
	* testsuite/libgomp.oacc-c-c++-common/self-1.c: Likewise.
	* testsuite/libgomp.oacc-fortran/if-1.f90: Likewise.
	* testsuite/libgomp.oacc-c-c++-common/if-self-1.c: New.
	* testsuite/libgomp.oacc-fortran/self-1.f90: Likewise.
---
 .../c-c++-common/goacc/if-clause-2.c  |   2 +
 .../c-c++-common/goacc/self-clause-1.c|   6 +
 .../c-c++-common/goacc/self-clause-2.c|  20 +
 gcc/testsuite/gfortran.dg/goacc/if.f95|  10 +-
 .../gfortran.dg/goacc/kernels-tree.f95|   5 +-
 .../gfortran.dg/goacc/parallel-tree.f95   |   3 +-
 gcc/testsuite/gfortran.dg/goacc/self.f95  |   8 +
 .../libgomp.oacc-c-c++-common/if-1.c  |   4 +
 .../libgomp.oacc-c-c++-common/if-self-1.c |  36 +
 .../libgomp.oacc-c-c++-common/self-1.c|   5 +
 .../testsuite/libgomp.oacc-fortran/if-1.f90   |   4 +
 .../testsuite/libgomp.oacc-fortran/self-1.f90 | 996 ++
 12 files changed, 1094 insertions(+), 5 deletions(-)
 create mode 100644 libgomp/testsuite/libgomp.oacc-c-c++-common/if-self-1.c
 create mode 100644 libgomp/testsuite/libgomp.oacc-fortran/self-1.f90

diff --git a/gcc/testsuite/c-c++-common/goacc/if-clause-2.c b/gcc/testsuite/c-c++-common/goacc/if-clause-2.c
index a48072509e1..71475521758 100644
--- a/gcc/testsuite/c-c++-common/goacc/if-clause-2.c
+++ b/gcc/testsuite/c-c++-common/goacc/if-clause-2.c
@@ -1,3 +1,5 @@
+/* See also 'self-clause-2.c'.  */
+
 /* { dg-additional-options "-fdump-tree-gimple" } */
 /* { dg-additional-options "--param=openacc-kernels=decompose" }
{ dg-additional-options "-fdump-tree-omp_oacc_kernels_decompose" } */
diff --git a/gcc/testsuite/c-c++-common/goacc/self-clause-1.c b/gcc/testsuite/c-c++-common/goacc/self-clause-1.c
index fe892bea210..28de3dc0584 100644
--- a/gcc/testsuite/c-c++-common/goacc/self-clause-1.c
+++ b/gcc/testsuite/c-c++-common/goacc/self-clause-1.c
@@ -5,6 +5,8 @@ f (int b)
 {
   struct { int i; } *p;
 
+#pragma acc parallel self(0) self(b) /* { dg-error "too many 'self' clauses" } */
+  ;
 #pragma acc parallel self self(b) /* { dg-error "too many 'self' clauses" } */
   ;
 #pragma acc parallel self(*p)
@@ -12,6 +14,8 @@ f (int b)
  { dg-error {could not convert '\* p' from 'f\(int\)::' to 'bool'} {} { target c++ } .-2 } */
   ;
 
+#pragma acc kernels self(0) self(b) /* { dg-error "too many 'self' clauses" } */
+  ;
 #pragma acc kernels self self(b) /* { dg-error "too many 'self' clauses" } */
   ;
 #pragma acc kernels self(*p)
@@ 

Handle OpenACC 'self' clause for compute constructs in OpenACC 'kernels' decomposition (was: Extend test suite coverage for OpenACC 'self' clause for compute constructs (was: [PATCH, OpenACC 2.7] Impl

[Thomas Schwinge]

Hi!

On 2023-10-25T11:29:52+0200, I wrote:
> On 2023-10-25T10:57:06+0200, I wrote:
>> With minor textual conflicts resolved, I've pushed this to master branch
>> in commit 3a3596389c2e539cb8fd5dc5784a4e2afe193a2a
>> "OpenACC 2.7: Implement self clause for compute constructs", see
>> attached.
>>
>>
>> I'll then apply/submit a number of follow-on commits.
>
>> From 3a3596389c2e539cb8fd5dc5784a4e2afe193a2a Mon Sep 17 00:00:00 2001
>> From: Chung-Lin Tang 
>> Date: Tue, 13 Jun 2023 08:44:31 -0700
>> Subject: [PATCH] OpenACC 2.7: Implement self clause for compute constructs
>
>>  .../c-c++-common/goacc/self-clause-1.c|  22 +
>>  .../c-c++-common/goacc/self-clause-2.c|  17 +
>>  gcc/testsuite/gfortran.dg/goacc/self.f95  |  53 +
>
>>  .../libgomp.oacc-c-c++-common/self-1.c| 962 ++
>
> I found that insufficient, and added some more.  Pushed to
> master branch commit 047841a68ebf5f991e842961f9e54f3c10b94f2c
> "Extend test suite coverage for OpenACC 'self' clause for compute constructs",
> see attached.  This is mostly just adapting and cross-linking some
> existing 'if' clause test cases.  (..., which turned up a problem when
> the 'self' clause is used with OpenACC 'kernels'.)

> --- /dev/null
> +++ b/libgomp/testsuite/libgomp.oacc-fortran/self-1.f90
> @@ -0,0 +1,996 @@
> +! OpenACC 'self' clause.
> +
> +! This is 'if-1.f90' with 'self(!cond)' instead of 'if(cond)' on compute
> +! constructs.
> +! ..., which the exception of certain 'kernels' constructs.

..., which I've then fixed up per master branch
commit 7b2ae64b68132c1c643cb34d58cd5eab6f9de652
"Handle OpenACC 'self' clause for compute constructs in OpenACC 'kernels' 
decomposition",
see attached.


Grüße
 Thomas


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
>From 7b2ae64b68132c1c643cb34d58cd5eab6f9de652 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Mon, 23 Oct 2023 15:28:30 +0200
Subject: [PATCH] Handle OpenACC 'self' clause for compute constructs in
 OpenACC 'kernels' decomposition

... to fix up recent commit 3a3596389c2e539cb8fd5dc5784a4e2afe193a2a
"OpenACC 2.7: Implement self clause for compute constructs" for that case.

	gcc/
	* omp-oacc-kernels-decompose.cc (omp_oacc_kernels_decompose_1):
	Handle 'OMP_CLAUSE_SELF' like 'OMP_CLAUSE_IF'.
	* omp-expand.cc (expand_omp_target): Handle 'OMP_CLAUSE_SELF' for
	'GF_OMP_TARGET_KIND_OACC_DATA_KERNELS'.
	gcc/testsuite/
	* c-c++-common/goacc/self-clause-2.c: Verify
	'--param=openacc-kernels=decompose'.
	* gfortran.dg/goacc/kernels-tree.f95: Adjust.
	libgomp/
	* oacc-parallel.c (GOACC_data_start): Handle
	'GOACC_FLAG_LOCAL_DEVICE'.
	(GOACC_parallel_keyed): Simplify accordingly.
	* testsuite/libgomp.oacc-fortran/self-1.f90: Adjust.
---
 gcc/omp-expand.cc   | 14 --
 gcc/omp-oacc-kernels-decompose.cc   | 15 ---
 .../c-c++-common/goacc/self-clause-2.c  |  6 ++
 .../gfortran.dg/goacc/kernels-tree.f95  |  2 +-
 libgomp/oacc-parallel.c | 17 +
 .../testsuite/libgomp.oacc-fortran/self-1.f90   | 15 +++
 6 files changed, 39 insertions(+), 30 deletions(-)

diff --git a/gcc/omp-expand.cc b/gcc/omp-expand.cc
index 8576b938102..5c6a7f2e381 100644
--- a/gcc/omp-expand.cc
+++ b/gcc/omp-expand.cc
@@ -10334,9 +10334,19 @@ expand_omp_target (struct omp_region *region)
 
   if ((c = omp_find_clause (clauses, OMP_CLAUSE_SELF)) != NULL_TREE)
 {
-  gcc_assert (is_gimple_omp_oacc (entry_stmt) && offloaded);
+  gcc_assert ((is_gimple_omp_oacc (entry_stmt) && offloaded)
+		  || (gimple_omp_target_kind (entry_stmt)
+		  == GF_OMP_TARGET_KIND_OACC_DATA_KERNELS));
 
-  edge e = split_block_after_labels (new_bb);
+  edge e;
+  if (offloaded)
+	e = split_block_after_labels (new_bb);
+  else
+	{
+	  gsi = gsi_last_nondebug_bb (new_bb);
+	  gsi_prev (&gsi);
+	  e = split_block (new_bb, gsi_stmt (gsi));
+	}
   basic_block cond_bb = e->src;
   new_bb = e->dest;
   remove_edge (e);
diff --git a/gcc/omp-oacc-kernels-decompose.cc b/gcc/omp-oacc-kernels-decompose.cc
index ffc0a8f813e..dfbb34935d0 100644
--- a/gcc/omp-oacc-kernels-decompose.cc
+++ b/gcc/omp-oacc-kernels-decompose.cc
@@ -1519,17 +1519,18 @@ omp_oacc_kernels_decompose_1 (gimple *kernels_stmt)
 	  break;
 	}
 	}
-  else 

Minor fixes for OpenACC/Fortran 'self' clause for compute constructs (was: [PATCH, OpenACC 2.7] Implement self clause for compute constructs)

[Thomas Schwinge]

Hi!

On 2023-10-25T10:57:06+0200, I wrote:
> With minor textual conflicts resolved, I've pushed this to master branch
> in commit 3a3596389c2e539cb8fd5dc5784a4e2afe193a2a
> "OpenACC 2.7: Implement self clause for compute constructs", see
> attached.
>
>
> I'll then apply/submit a number of follow-on commits.

Regarding the Fortran front end changes:

> From 3a3596389c2e539cb8fd5dc5784a4e2afe193a2a Mon Sep 17 00:00:00 2001
> From: Chung-Lin Tang 
> Date: Tue, 13 Jun 2023 08:44:31 -0700
> Subject: [PATCH] OpenACC 2.7: Implement self clause for compute constructs

> --- a/gcc/fortran/gfortran.h
> +++ b/gcc/fortran/gfortran.h
> @@ -1546,6 +1546,7 @@ typedef struct gfc_omp_clauses
>gfc_omp_namelist *lists[OMP_LIST_NUM];
>struct gfc_expr *if_expr;
>struct gfc_expr *if_exprs[OMP_IF_LAST];
> +  struct gfc_expr *self_expr;
>struct gfc_expr *final_expr;
>struct gfc_expr *num_threads;
>struct gfc_expr *chunk_size;

..., this needs to be handled in a few more places, I think...

> --- a/gcc/fortran/trans-openmp.cc
> +++ b/gcc/fortran/trans-openmp.cc

> @@ -6615,6 +6631,8 @@ gfc_split_omp_clauses (gfc_code *code,
> /* And this is copied to all.  */
> clausesa[GFC_OMP_SPLIT_TARGET].if_expr
>   = code->ext.omp_clauses->if_expr;
> +   clausesa[GFC_OMP_SPLIT_TARGET].self_expr
> + = code->ext.omp_clauses->self_expr;
> clausesa[GFC_OMP_SPLIT_TARGET].nowait
>   = code->ext.omp_clauses->nowait;
>   }

..., but this change isn't necessary: that function is for OpenMP only,
and generally doesn't (have to) care about OpenACC-only clauses.

OK to push the attached
"Minor fixes for OpenACC/Fortran 'self' clause for compute constructs",
or is anything more needed?


Also, I've filed <https://gcc.gnu.org/PR111938>
"Missing OpenACC/Fortran handling in 'gcc/fortran/frontend-passes.c'",
which applies generally, not just to the OpenACC 'self' clause on compute
constructs.


Grüße
 Thomas


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
>From 943de6d5f1498aabfc343bf5e9dd6c2b63fc55ed Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Fri, 20 Oct 2023 15:49:35 +0200
Subject: [PATCH] Minor fixes for OpenACC/Fortran 'self' clause for compute
 constructs

... to fix up recent commit 3a3596389c2e539cb8fd5dc5784a4e2afe193a2a
"OpenACC 2.7: Implement self clause for compute constructs".

	gcc/fortran/
	* dump-parse-tree.cc (show_omp_clauses): Handle 'self_expr'.
	* openmp.cc (gfc_free_omp_clauses): Likewise.
	* trans-openmp.cc (gfc_split_omp_clauses): Don't handle 'self_expr'.
---
 gcc/fortran/dump-parse-tree.cc | 6 ++
 gcc/fortran/openmp.cc  | 1 +
 gcc/fortran/trans-openmp.cc| 2 --
 3 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/gcc/fortran/dump-parse-tree.cc b/gcc/fortran/dump-parse-tree.cc
index cc4846e5d74..26391df46e6 100644
--- a/gcc/fortran/dump-parse-tree.cc
+++ b/gcc/fortran/dump-parse-tree.cc
@@ -1614,6 +1614,12 @@ show_omp_clauses (gfc_omp_clauses *omp_clauses)
   show_expr (omp_clauses->if_exprs[i]);
   fputc (')', dumpfile);
 }
+  if (omp_clauses->self_expr)
+{
+  fputs (" SELF(", dumpfile);
+  show_expr (omp_clauses->self_expr);
+  fputc (')', dumpfile);
+}
   if (omp_clauses->final_expr)
 {
   fputs (" FINAL(", dumpfile);
diff --git a/gcc/fortran/openmp.cc b/gcc/fortran/openmp.cc
index 2e2e23d567b..5e3cd0570bb 100644
--- a/gcc/fortran/openmp.cc
+++ b/gcc/fortran/openmp.cc
@@ -163,6 +163,7 @@ gfc_free_omp_clauses (gfc_omp_clauses *c)
   gfc_free_expr (c->if_expr);
   for (i = 0; i < OMP_IF_LAST; i++)
 gfc_free_expr (c->if_exprs[i]);
+  gfc_free_expr (c->self_expr);
   gfc_free_expr (c->final_expr);
   gfc_free_expr (c->num_threads);
   gfc_free_expr (c->chunk_size);
diff --git a/gcc/fortran/trans-openmp.cc b/gcc/fortran/trans-openmp.cc
index 82bbc41b388..00782ee1716 100644
--- a/gcc/fortran/trans-openmp.cc
+++ b/gcc/fortran/trans-openmp.cc
@@ -6631,8 +6631,6 @@ gfc_split_omp_clauses (gfc_code *code,
 	  /* And this is copied to all.  */
 	  clausesa[GFC_OMP_SPLIT_TARGET].if_expr
 	= code->ext.omp_clauses->if_expr;
-	  clausesa[GFC_OMP_SPLIT_TARGET].self_expr
-	= code->ext.omp_clauses->self_expr;
 	  clausesa[GFC_OMP_SPLIT_TARGET].nowait
 	= code->ext.omp_clauses->nowait;
 	}
-- 
2.34.1

Re: [NVPTX] Patch pings...

[Thomas Schwinge]

Hi Roger!

Thanks for your patience!  I very much know how it's frustrating...
I promise I'll get to your patches: in fact I already started looking
into these before the Cauldron, but ran into GCC/nvptx things that I
didn't understand but felt I need to understand/address first, then after
the Cauldron was out for late summer vacations, only recently returned,
and now catching up with things accumulated during that vacation time,
and then planning to resume GCC/nvptx work.


Grüße
 Thomas


On 2023-10-25T14:54:50+0100, "Roger Sayle"  wrote:
> Random fact: there have been no changes to nvptx.md in 2023 apart
> from Jakub's tree-wide update to the copyright years in early January.
>
> Please can I ping two of my of pending Nvidia nvptx patches:
>
> "Correct pattern for popcountdi2 insn in nvptx.md" from January
> https://gcc.gnu.org/pipermail/gcc-patches/2023-January/609571.html
>
> and
>
> "Update nvptx's bitrev2 pattern to use BITREVERSE rtx" from June
> https://gcc.gnu.org/pipermail/gcc-patches/2023-June/620994.html
>
> Both of these still apply cleanly (because nvptx.md hasn't changed).
>
> Thanks in advance,
> Roger
> --
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955