Contents of PO file 'cpplib-13.1-b20230212.sr.po'

2023-02-25 Thread Translation Project Robot 


cpplib-13.1-b20230212.sr.po.gz
Description: Binary data
The Translation Project robot, in the
name of your translation coordinator.

New Serbian PO file for 'cpplib' (version 13.1-b20230212)

2023-02-25 Thread Translation Project Robot 
Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'cpplib' has been submitted
by the Serbian team of translators.  The file is available at:

https://translationproject.org/latest/cpplib/sr.po

(This file, 'cpplib-13.1-b20230212.sr.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

https://translationproject.org/latest/cpplib/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

https://translationproject.org/domain/cpplib.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

[Patch] gcc.c-torture/compile/103818.c: enable for llp64 too

2023-02-25 Thread Jonathan Yong via Gcc-patches 
Patch OK for master branch? I did not see any obvious issues to exclude 
LLP64 specifically.From 9c770936c4c6ffb59d15e5c1ce331494ba102250 Mon Sep 17 00:00:00 2001
From: Jonathan Yong <10wa...@gmail.com>
Date: Sun, 26 Feb 2023 06:34:04 +
Subject: [PATCH] gcc.c-torture/compile/103818.c: enable for llp64 too

gcc/testsuite/ChangeLog:

	* gcc.c-torture/compile/103818.c: enable test for llp64.

Signed-off-by: Jonathan Yong <10wa...@gmail.com>
---
 gcc/testsuite/gcc.c-torture/compile/103818.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.c-torture/compile/103818.c b/gcc/testsuite/gcc.c-torture/compile/103818.c
index e6cbe7860cf..63090534f4c 100644
--- a/gcc/testsuite/gcc.c-torture/compile/103818.c
+++ b/gcc/testsuite/gcc.c-torture/compile/103818.c
@@ -1,4 +1,4 @@
-/* { dg-do compile { target lp64 } } */
+/* { dg-do compile { target { lp64 || lp64 } } } */
 struct A { int b[1]; };
 
 void
-- 
2.39.2

Re: [Patch] More LLP64 fixes and __PIC__ values fixes for PE targets

2023-02-25 Thread NightStrike via Gcc-patches 
On Tue, Feb 14, 2023, 05:42 Jonathan Yong via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:

> Attached patches OK?


Ping

Re: [Patch] harden-sls-6.c: fix warning on LLP64

2023-02-25 Thread NightStrike via Gcc-patches 
On Wed, Feb 15, 2023, 08:45 Jonathan Yong via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:

> gcc/testsuite/ChangeLog:
>
>  * gcc.target/i386/harden-sls-6.c: fix warning on LLP64
>  targets.
>
> Attached patch OK?


Ping

Re: [PATCH v3 04/11] riscv: thead: Add support for the XTheadBs ISA extension

2023-02-25 Thread Hans-Peter Nilsson 
On Fri, 24 Feb 2023, Christoph Muellner wrote:
> diff --git a/gcc/config/riscv/thead.md b/gcc/config/riscv/thead.md
> index 158e9124c3a..2c684885850 100644
> --- a/gcc/config/riscv/thead.md
> +++ b/gcc/config/riscv/thead.md
> @@ -29,3 +29,14 @@ (define_insn "*th_addsl"
>"th.addsl\t%0,%3,%1,%2"
>[(set_attr "type" "bitmanip")
> (set_attr "mode" "")])
> +
> +;; XTheadBs
> +
> +(define_insn "*th_tst"
> +  [(set (match_operand:X 0 "register_operand" "=r")
> + (zero_extract:X (match_operand:X 1 "register_operand" "r")
> + (const_int 1)
> + (match_operand 2 "immediate_operand" "i")))]

(Here and same elsewhere.)

You're unlikely to get other constant operands in that pattern, 
but FWIW, the actual matching pair for just CONST_INT is 
"const_int_operand" for the predicate and "n" for the 
constraint.  Using the right predicate and constraint will also 
help the generated part of recog be a few nanoseconds faster. ;)

brgds, H-P

Re: Rust: In 'type_for_mode' langhook also consider all 'int_n' modes/types (was: Modula-2 / Rust: Many targets failing)

2023-02-25 Thread Jan-Benedict Glaw 
Hi Thomas,

On Wed, 2023-02-22 12:25:01 +0100, Thomas Schwinge  
wrote:
> On 2022-12-19T22:23:45+0100, Jan-Benedict Glaw  wrote:
> >  Rust related issues
> > =
> >
> >  --target=msp430-elfbare
> > ~
> >   /var/lib/laminar/run/gcc-msp430-elfbare/24/toolchain-build/./gcc/xgcc 
> > -B/var/lib/laminar/run/gcc-msp430-elfbare/24/toolchain-build/./gcc/  -xrust 
> > -frust-incomplete-and-experimental-compiler-do-not-use -nostdinc /dev/null 
> > -S -o /dev/null -fself-test=../../gcc/gcc/testsuite/selftests
> >   : internal compiler error: Segmentation fault
> >   0xf2efbf crash_signal
> > ../../gcc/gcc/toplev.cc:314
> >   0x120c8c7 build_function_type(tree_node*, tree_node*, bool)
> > ../../gcc/gcc/tree.cc:7360
> >   0x120cc20 build_function_type_list(tree_node*, ...)
> > ../../gcc/gcc/tree.cc:7442
> >   0x120d16b build_common_builtin_nodes()
> > ../../gcc/gcc/tree.cc:9883
> >   0x8449b4 grs_langhook_init
> > ../../gcc/gcc/rust/rust-lang.cc:132
> >   0x8427b2 lang_dependent_init
> > ../../gcc/gcc/toplev.cc:1815
> >   0x8427b2 do_compile
> > ../../gcc/gcc/toplev.cc:2110
> >   Please submit a full bug report, with preprocessed source (by using 
> > -freport-bug).
> >   Please include the complete backtrace with any bug report.
> >   See  for instructions.
> >   make[1]: *** [../../gcc/gcc/rust/Make-lang.in:275: s-selftest-rust] 
> > Error 1
> 
> See also 
> "Test failure on msp430-elfbare target".

Confirm: fixed upstream
(http://toolchain.lug-owl.de/laminar/jobs/gcc-msp430-elf/65)

Thanks,
  Jan-Benedict

-- 


signature.asc
Description: PGP signature

Re: [PATCH v2 0/5] A small Texinfo refinement

2023-02-25 Thread Thomas Schwinge 
Hi Arsen!

Thanks for caring about the documentation infrastructure!

On 2023-02-23T11:27:09+0100, Arsen Arsenović via Gcc-patches 
 wrote:
> The commit "docs: Reorder @opindex to be before corresponding options"

> https://gcc.gnu.org/pipermail/gcc-patches/2023-February/612616.html
> His idea of automatically checking for this error pattern will be
> implemented separately, after I figure out how best to do that.  The
> code that was involved in making this patchset is too primitive to
> apply globally.

But please don't spend too much time on that idea, if that turns out to
require non-trivial Texinfo parsing.

Given that you've now fixed up the existing disordered instances, I
suppose not many new ones are going be introduced, assuming that people
extend the documentation by looking at the existing, now-good context.


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] testsuite: Don't include multiline patterns in the the pass/fail log

2023-02-25 Thread Hans-Peter Nilsson via Gcc-patches 
> From: David Malcolm 
> Date: Fri, 24 Feb 2023 14:07:02 -0500
> Old-Content-Type: text/plain; charset="UTF-8"
> Old-Content-Transfer-Encoding: base64
> Content-Type: TEXT/plain; charset=iso-8859-1
> 
> On Fri, 2023-02-24 at 18:54 +0100, Hans-Peter Nilsson wrote:
> > Ok to commit?
> 
> Looks good to me [1]
> 
> Thanks
> Dave

Thanks!

> [1] though FWIW although I wrote this code, my DejaGnu skills are weak
> and I'm not a testsuite maintainer :-/

But that "ok", reflecting your logging intent, makes the
patch obvious!  So, committed, per below.

Also, I noticed overuse of the term "regexp", so
s/regexp/pattern/g, where g also includes the subject of
this mail.  My mind was on the follow-up patchset starting at
"https://gcc.gnu.org/pipermail/gcc-patches/2023-February/612810.html;
where I accidentally left you out for CC, but now inviting
to have a look.

JFTR: Regarding the "escaped_regex" in the context of this patch,
that's when the pattern has been frobbed into a simple
rexexp, a glob, but that's internal.

brgds, H-P
(PS. quoted contents below also reworded)

> > 
> > -- >8 --
> > I see overlong lines in the output when a test fails, for
> > example for a bug exposed for cris-elf and pru-elf in
> > gcc.dg/analyzer/allocation-size-multiline-3.c:
> > 
> > Running /x/gcc/testsuite/gcc.dg/analyzer/analyzer.exp ...
> > FAIL: gcc.dg/analyzer/allocation-size-multiline-3.c expected
> > multiline pattern lines 16-25 not found: "\s*int32_t \*ptr = alloca
> > \(99\);[^\n\r]*\n  \^~\n  'test_constant_99':
> > events 1-2[^\n\r]*\n    \|[^\n\r]*\n    \|   int32_t \*ptr = alloca
> > \(99\);[^\n\r]*\n    \|  \^~\n   
> > \|  \|[^\n\r]*\n    \|  \(1\)
> > allocated 99 bytes here[^\n\r]*\n    \|  \(2\)
> > assigned to 'int32_t \*' \{aka 'int \*'\} here; 'sizeof \(int32_t
> > \{aka int\}\)' is '4'[^\n\r]*\n    \|[^\n\r]*\n"
> > FAIL: gcc.dg/analyzer/allocation-size-multiline-3.c expected
> > multiline pattern lines 34-43 not found: "   int32_t \*ptr = alloca
> > \(n \* 2\);[^\n\r]*\n  \^~\n  'test_symbolic':
> > events 1-2[^\n\r]*\n    \|[^\n\r]*\n    \|   int32_t \*ptr = alloca
> > \(n \* 2\);[^\n\r]*\n    \|  \^~\n   
> > \|  \|[^\n\r]*\n    \|  \(1\)
> > allocated 'n \* 2' bytes here[^\n\r]*\n    \|  \(2\)
> > assigned to 'int32_t \*' \{aka 'int \*'\} here; 'sizeof \(int32_t
> > \{aka int\}\)' is '4'[^\n\r]*\n    \|[^\n\r]*\n"
> > FAIL: gcc.dg/analyzer/allocation-size-multiline-3.c (test for excess
> > errors)
> > 
> > That multiline-pattern-quoted-on-a-single-line is redundant
> > when also outputting "lines 16-25" and "lines 34-43".  It's
> > also so noisy that it can be mistaken for a testsuite error.
> > If there's a need to inspect it, it can be seen at
> > verbose-level 4, i.e. persons interested in seeing it
> > without editing sources can just add "-v -v -v -v".
> > 
> > Let's "prune" the pattern from regular output, instead producing:
> > Running /x/gcc/testsuite/gcc.dg/analyzer/analyzer.exp ...
> > FAIL: gcc.dg/analyzer/allocation-size-multiline-3.c expected
> > multiline pattern lines 16-25 not found
> > FAIL: gcc.dg/analyzer/allocation-size-multiline-3.c expected
> > multiline pattern lines 34-43 not found
> > FAIL: gcc.dg/analyzer/allocation-size-multiline-3.c (test for excess
> > errors)
> > 
> > * lib/multiline.exp (handle-multiline-outputs): Don't include
> > the
> > quoted multiline pattern in the pass/fail output.
> > ---
> >  gcc/testsuite/lib/multiline.exp | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/gcc/testsuite/lib/multiline.exp
> > b/gcc/testsuite/lib/multiline.exp
> > index 84ba9216642e..5eccf2bbebc1 100644
> > --- a/gcc/testsuite/lib/multiline.exp
> > +++ b/gcc/testsuite/lib/multiline.exp
> > @@ -169,9 +169,9 @@ proc handle-multiline-outputs { text } {
> > # Use "regsub" to attempt to prune the pattern from $text
> > if {[regsub -line $rexp $text "" text]} {
> >     # The multiline pattern was pruned.
> > -   ${maybe_x}pass "$title was found: \"$escaped_regex\""
> > +   ${maybe_x}pass "$title was found"
> > } else {
> > -   ${maybe_x}fail "$title not found: \"$escaped_regex\""
> > +   ${maybe_x}fail "$title not found"
> > }
> >  
> > set index [expr $index + 1]
>

[PATCH, committed] Fortran: fix memory leak with real to integer conversion warning

2023-02-25 Thread Harald Anlauf via Gcc-patches 
Dear all,

while checking f951 for memory leaks on testcases that appeared
relevant during work on pr108924, I found that the conversion
warning triggered by do_subscript_6.f90 uses a code path that
forgot to mpfr_clear a used variable.

The attached obvious patch fixes this - verified by valgrind.

Pushed to mainline as r13-6344-g03c60e525bea13 .

Thanks,
Harald

From 03c60e525bea13c15edd2f64cd582f168fe80bfb Mon Sep 17 00:00:00 2001
From: Harald Anlauf 
Date: Sat, 25 Feb 2023 19:05:38 +0100
Subject: [PATCH] Fortran: fix memory leak with real to integer conversion
 warning

gcc/fortran/ChangeLog:

	* arith.cc (gfc_real2int): Clear mpfr variable after use.
---
 gcc/fortran/arith.cc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/gcc/fortran/arith.cc b/gcc/fortran/arith.cc
index d0d1c0b03d2..37aeaf1b186 100644
--- a/gcc/fortran/arith.cc
+++ b/gcc/fortran/arith.cc
@@ -2257,6 +2257,7 @@ gfc_real2int (gfc_expr *src, int kind)
 			   gfc_typename (>ts), >where);
 	  did_warn = true;
 	}
+  mpfr_clear (f);
 }
   if (!did_warn && warn_conversion_extra)
 {
--
2.35.3

Re: fortran: Reuse associated_dummy memory if previously allocated [PR108923]

2023-02-25 Thread Mikael Morin 

Le 25/02/2023 à 18:20, Harald Anlauf a écrit :

Hi Mikael,

Am 25.02.23 um 17:35 schrieb Mikael Morin:

Hello,

Harald found a testcase with memory still leaking despite my previous
patch for PR108923.
That patch was fixing a leak caused by absence of memory release, the
attached patch fixes a leak caused by pointer overwrite.

I haven't investigated why sort_actual is called several times( which
causes the memory leak) nor tried to avoid that.  Theoretically, one
could assert that the previous associated_dummy value is the same as the
one to be written (it should be the same at each sort_actual
invocation), but I have preferred to silently overwrite, and fix just
the memory problem.

Manually tested on Harald's testcase (predcom-1.f) and ran the full
fortran testsuite on x86_64-pc-linux-gnu.

OK for master and 12 and 11?


LGTM.  OK for master and 12-branch.

It appears that 11-branch is significantly different in the respective
places.  get_intrinsic_dummy_arg does not exist there, so this patch
seems to not apply there.  Or am I missing something?

No you're right.  I had forgotten that a simplified patch had been used 
to fix pr97896 on the 11 branch.  Thanks.

Re: fortran: Reuse associated_dummy memory if previously allocated [PR108923]

2023-02-25 Thread Harald Anlauf via Gcc-patches 

Hi Mikael,

Am 25.02.23 um 17:35 schrieb Mikael Morin:

Hello,

Harald found a testcase with memory still leaking despite my previous
patch for PR108923.
That patch was fixing a leak caused by absence of memory release, the
attached patch fixes a leak caused by pointer overwrite.

I haven't investigated why sort_actual is called several times( which
causes the memory leak) nor tried to avoid that.  Theoretically, one
could assert that the previous associated_dummy value is the same as the
one to be written (it should be the same at each sort_actual
invocation), but I have preferred to silently overwrite, and fix just
the memory problem.

Manually tested on Harald's testcase (predcom-1.f) and ran the full
fortran testsuite on x86_64-pc-linux-gnu.

OK for master and 12 and 11?


LGTM.  OK for master and 12-branch.

It appears that 11-branch is significantly different in the respective
places.  get_intrinsic_dummy_arg does not exist there, so this patch
seems to not apply there.  Or am I missing something?

Thanks for the patch!

Harald

fortran: Reuse associated_dummy memory if previously allocated [PR108923]

2023-02-25 Thread Mikael Morin 

Hello,

Harald found a testcase with memory still leaking despite my previous 
patch for PR108923.
That patch was fixing a leak caused by absence of memory release, the 
attached patch fixes a leak caused by pointer overwrite.


I haven't investigated why sort_actual is called several times( which 
causes the memory leak) nor tried to avoid that.  Theoretically, one 
could assert that the previous associated_dummy value is the same as the 
one to be written (it should be the same at each sort_actual 
invocation), but I have preferred to silently overwrite, and fix just 
the memory problem.


Manually tested on Harald's testcase (predcom-1.f) and ran the full 
fortran testsuite on x86_64-pc-linux-gnu.


OK for master and 12 and 11?
From 9b88208ec4130712d33d5c7ed74fc17466624a0c Mon Sep 17 00:00:00 2001
From: Mikael Morin 
Date: Sat, 25 Feb 2023 16:27:24 +0100
Subject: [PATCH] fortran: Reuse associated_dummy memory if previously
 allocated [PR108923]

This avoids making the associted_dummy field point to a new memory chunk
if it's already pointing somewhere, in which case doing so would leak the
previously allocated chunk.

gcc/fortran/ChangeLog:

	* intrinsic.cc (get_intrinsic_dummy_arg,
	set_intrinsic_dummy_arg): Rename the former to the latter.
	Remove the return value, add a reference to the lhs as argument,
	and do the pointer assignment inside the function.  Don't do
	it if the pointer is already non-NULL.
	(sort_actual): Update caller.
---
 gcc/fortran/intrinsic.cc | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/gcc/fortran/intrinsic.cc b/gcc/fortran/intrinsic.cc
index 17ee999c3b9..e69e541efe0 100644
--- a/gcc/fortran/intrinsic.cc
+++ b/gcc/fortran/intrinsic.cc
@@ -4259,15 +4259,14 @@ remove_nullargs (gfc_actual_arglist **ap)
 }
 
 
-static gfc_dummy_arg *
-get_intrinsic_dummy_arg (gfc_intrinsic_arg *intrinsic)
+static void
+set_intrinsic_dummy_arg (gfc_dummy_arg *_arg, gfc_intrinsic_arg *intrinsic)
 {
-  gfc_dummy_arg * const dummy_arg = gfc_get_dummy_arg ();
+  if (dummy_arg == NULL)
+dummy_arg = gfc_get_dummy_arg ();
 
   dummy_arg->intrinsicness = GFC_INTRINSIC_DUMMY_ARG;
   dummy_arg->u.intrinsic = intrinsic;
-
-  return dummy_arg;
 }
 
 
@@ -4430,7 +4429,7 @@ do_sort:
   if (a == NULL)
 	a = gfc_get_actual_arglist ();
 
-  a->associated_dummy = get_intrinsic_dummy_arg (f);
+  set_intrinsic_dummy_arg (a->associated_dummy, f);
 
   if (actual == NULL)
 	*ap = a;
-- 
2.39.1

[COMMITTED] gcc: xtensa: fix PR target/108919

2023-02-25 Thread Max Filippov via Gcc-patches 
gcc/
PR target/108919

* config/xtensa/xtensa-protos.h
(xtensa_prepare_expand_call): Rename to xtensa_expand_call.
* config/xtensa/xtensa.cc (xtensa_prepare_expand_call): Rename
to xtensa_expand_call.
(xtensa_expand_call): Emit the call and add a clobber expression
for the static chain to it in case of windowed ABI.
* config/xtensa/xtensa.md (call, call_value, sibcall)
(sibcall_value): Call xtensa_expand_call and complete expansion
right after that call.

gcc/testsuite/
* gcc.target/xtensa/pr108919.c: New test.
---
 gcc/config/xtensa/xtensa-protos.h  |  2 +-
 gcc/config/xtensa/xtensa.cc| 25 +++-
 gcc/config/xtensa/xtensa.md| 12 --
 gcc/testsuite/gcc.target/xtensa/pr108919.c | 46 ++
 4 files changed, 79 insertions(+), 6 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/xtensa/pr108919.c

diff --git a/gcc/config/xtensa/xtensa-protos.h 
b/gcc/config/xtensa/xtensa-protos.h
index ecd0f0c8d108..c81cf94323ac 100644
--- a/gcc/config/xtensa/xtensa-protos.h
+++ b/gcc/config/xtensa/xtensa-protos.h
@@ -53,7 +53,7 @@ extern void xtensa_expand_atomic (enum rtx_code, rtx, rtx, 
rtx, bool);
 extern void xtensa_emit_loop_end (rtx_insn *, rtx *);
 extern char *xtensa_emit_branch (bool, rtx *);
 extern char *xtensa_emit_movcc (bool, bool, bool, rtx *);
-extern void xtensa_prepare_expand_call (int, rtx *);
+extern void xtensa_expand_call (int, rtx *);
 extern char *xtensa_emit_call (int, rtx *);
 extern char *xtensa_emit_sibcall (int, rtx *);
 extern bool xtensa_tls_referenced_p (rtx);
diff --git a/gcc/config/xtensa/xtensa.cc b/gcc/config/xtensa/xtensa.cc
index e52fba082550..5044bc25c2fe 100644
--- a/gcc/config/xtensa/xtensa.cc
+++ b/gcc/config/xtensa/xtensa.cc
@@ -2183,8 +2183,10 @@ xtensa_emit_movcc (bool inverted, bool isfp, bool 
isbool, rtx *operands)
 
 
 void
-xtensa_prepare_expand_call (int callop, rtx *operands)
+xtensa_expand_call (int callop, rtx *operands)
 {
+  rtx call;
+  rtx_insn *call_insn;
   rtx addr = XEXP (operands[callop], 0);
 
   if (flag_pic && SYMBOL_REF_P (addr)
@@ -2202,6 +2204,27 @@ xtensa_prepare_expand_call (int callop, rtx *operands)
 Pmode);
   XEXP (operands[callop], 0) = reg;
 }
+
+  call = gen_rtx_CALL (VOIDmode, operands[callop], operands[callop + 1]);
+
+  if (callop)
+call = gen_rtx_SET (operands[0], call);
+
+  call_insn = emit_call_insn (call);
+
+  if (TARGET_WINDOWED_ABI)
+{
+  /*
+   * Windowed xtensa ABI specifies that static chain pointer is passed
+   * in memory below the caller's stack pointer, which means that the
+   * callee may clobber it if it's a non-leaf function.
+   * Add the clobber expression for the static chain to the function call
+   * expression list so that it is not assumed to be live across the call.
+   */
+  rtx clob = gen_rtx_CLOBBER (Pmode, xtensa_static_chain (NULL, false));
+  CALL_INSN_FUNCTION_USAGE (call_insn) =
+   gen_rtx_EXPR_LIST (Pmode, clob, CALL_INSN_FUNCTION_USAGE (call_insn));
+}
 }
 
 
diff --git a/gcc/config/xtensa/xtensa.md b/gcc/config/xtensa/xtensa.md
index cf25beb83d54..b60dec2447f3 100644
--- a/gcc/config/xtensa/xtensa.md
+++ b/gcc/config/xtensa/xtensa.md
@@ -2333,7 +2333,8 @@
 (match_operand 1 "" ""))]
   ""
 {
-  xtensa_prepare_expand_call (0, operands);
+  xtensa_expand_call (0, operands);
+  DONE;
 })
 
 (define_insn "call_internal"
@@ -2353,7 +2354,8 @@
  (match_operand 2 "" "")))]
   ""
 {
-  xtensa_prepare_expand_call (1, operands);
+  xtensa_expand_call (1, operands);
+  DONE;
 })
 
 (define_insn "call_value_internal"
@@ -2373,7 +2375,8 @@
 (match_operand 1 "" ""))]
   "!TARGET_WINDOWED_ABI"
 {
-  xtensa_prepare_expand_call (0, operands);
+  xtensa_expand_call (0, operands);
+  DONE;
 })
 
 (define_insn "sibcall_internal"
@@ -2393,7 +2396,8 @@
  (match_operand 2 "" "")))]
   "!TARGET_WINDOWED_ABI"
 {
-  xtensa_prepare_expand_call (1, operands);
+  xtensa_expand_call (1, operands);
+  DONE;
 })
 
 (define_insn "sibcall_value_internal"
diff --git a/gcc/testsuite/gcc.target/xtensa/pr108919.c 
b/gcc/testsuite/gcc.target/xtensa/pr108919.c
new file mode 100644
index ..300b6fd10a99
--- /dev/null
+++ b/gcc/testsuite/gcc.target/xtensa/pr108919.c
@@ -0,0 +1,46 @@
+/* { dg-do run } */
+/* { dg-options "-O2" } */
+
+
+#ifdef __XTENSA_CALL0_ABI__
+void __xtensa_libgcc_window_spill (void)
+{
+}
+#else
+void __xtensa_libgcc_window_spill (void);
+#endif
+
+__attribute__((noinline)) void h (void)
+{
+  __xtensa_libgcc_window_spill ();
+}
+
+int f (int u, int v)
+{
+  int a = u;
+  int s;
+
+  __attribute__((noinline,pure)) int nested1 (int b)
+  {
+  h();
+  return a + b;
+  }
+
+  __attribute__((noinline,pure)) int nested2 (int b)
+  {
+  h();
+  return a - b;
+  }
+
+  s = nested1 (v);
+  s += nested2 (v);
+  return s;

Re: [PATCH] gcc: xtensa: fix PR target/108919

2023-02-25 Thread Max Filippov via Gcc-patches 
Hi Suwa-san,

On Sat, Feb 25, 2023 at 3:33 AM Takayuki 'January June' Suwa
 wrote:
> On 2023/02/25 19:01, Max Filippov wrote:
> > diff --git a/gcc/config/xtensa/xtensa.cc b/gcc/config/xtensa/xtensa.cc
> > index e52fba082550..babe7f0ebd68 100644
> > --- a/gcc/config/xtensa/xtensa.cc
> > +++ b/gcc/config/xtensa/xtensa.cc
> > @@ -2183,8 +2183,10 @@ xtensa_emit_movcc (bool inverted, bool isfp, bool 
> > isbool, rtx *operands)
> >
> >
> >  void
> > -xtensa_prepare_expand_call (int callop, rtx *operands)
> > +xtensa_expand_call (int callop, rtx *operands)
> >  {
> > +  rtx call;
> > +  rtx call_insn;
>
> ;; This should be rtx_insn* rather than rtx,
> -  rtx call_insn;
> +  rtx_insn *call_insn;
>
> >rtx addr = XEXP (operands[callop], 0);
> >
> >if (flag_pic && SYMBOL_REF_P (addr)
> > @@ -2202,6 +2204,27 @@ xtensa_prepare_expand_call (int callop, rtx 
> > *operands)
> >Pmode);
> >XEXP (operands[callop], 0) = reg;
> >  }
> > +
> > +  call = gen_rtx_CALL (VOIDmode, operands[callop], operands[callop + 1]);
> > +
> > +  if (callop)
> > +call_insn = emit_call_insn (gen_rtx_SET (operands[0], call));
> > +  else
> > +call_insn = emit_call_insn (call);
>
> ;; Simpler,
>call = gen_rtx_CALL (VOIDmode, operands[callop], operands[callop + 1]);
> -
>if (callop)
> -call_insn = emit_call_insn (gen_rtx_SET (operands[0], call));
> -  else
> -call_insn = emit_call_insn (call);
> +call = gen_rtx_SET (operands[0], call);
> +  call_insn = emit_call_insn (call);

Thank you for the review!

> (I had just removed "WIP" from the set of backported patches to the 
> esp8266/Arduino toolchain,
> so I am worried that it was a bit premature, but relieved soon to find that 
> it has nothing to do
> with the CALL0 ABI...)

Unrelated indeed, just popped up during the recent testing.

-- 
Thanks.
-- Max

Re: [PATCH] gcc: xtensa: fix PR target/108919

2023-02-25 Thread Takayuki 'January June' Suwa via Gcc-patches 
Hello, Max:

On 2023/02/25 19:01, Max Filippov wrote:

> gcc/
>   PR target/108919
> 
>   * config/xtensa/xtensa-protos.h
>   (xtensa_prepare_expand_call): Rename to xtensa_expand_call.
>   * config/xtensa/xtensa.cc (xtensa_prepare_expand_call): Rename
>   to xtensa_expand_call.
>   (xtensa_expand_call): Emit the call and add a clobber expression
>   for the static chain to it in case of windowed ABI.
>   * config/xtensa/xtensa.md (call, call_value, sibcall)
>   (sibcall_value): Call xtensa_expand_call and complete expansion
>   right after that call.
> 
> gcc/testduite/
>   * gcc.target/xtensa/pr108919.c: New test.
> ---
>  gcc/config/xtensa/xtensa-protos.h  |  2 +-
>  gcc/config/xtensa/xtensa.cc| 25 +++-
>  gcc/config/xtensa/xtensa.md| 12 --
>  gcc/testsuite/gcc.target/xtensa/pr108919.c | 46 ++
>  4 files changed, 79 insertions(+), 6 deletions(-)
>  create mode 100644 gcc/testsuite/gcc.target/xtensa/pr108919.c
> 
> diff --git a/gcc/config/xtensa/xtensa-protos.h 
> b/gcc/config/xtensa/xtensa-protos.h
> index ecd0f0c8d108..c81cf94323ac 100644
> --- a/gcc/config/xtensa/xtensa-protos.h
> +++ b/gcc/config/xtensa/xtensa-protos.h
> @@ -53,7 +53,7 @@ extern void xtensa_expand_atomic (enum rtx_code, rtx, rtx, 
> rtx, bool);
>  extern void xtensa_emit_loop_end (rtx_insn *, rtx *);
>  extern char *xtensa_emit_branch (bool, rtx *);
>  extern char *xtensa_emit_movcc (bool, bool, bool, rtx *);
> -extern void xtensa_prepare_expand_call (int, rtx *);
> +extern void xtensa_expand_call (int, rtx *);
>  extern char *xtensa_emit_call (int, rtx *);
>  extern char *xtensa_emit_sibcall (int, rtx *);
>  extern bool xtensa_tls_referenced_p (rtx);
> diff --git a/gcc/config/xtensa/xtensa.cc b/gcc/config/xtensa/xtensa.cc
> index e52fba082550..babe7f0ebd68 100644
> --- a/gcc/config/xtensa/xtensa.cc
> +++ b/gcc/config/xtensa/xtensa.cc
> @@ -2183,8 +2183,10 @@ xtensa_emit_movcc (bool inverted, bool isfp, bool 
> isbool, rtx *operands)
>  
>  
>  void
> -xtensa_prepare_expand_call (int callop, rtx *operands)
> +xtensa_expand_call (int callop, rtx *operands)
>  {
> +  rtx call;
> +  rtx call_insn;

;; This should be rtx_insn* rather than rtx,
-  rtx call_insn;
+  rtx_insn *call_insn;

>rtx addr = XEXP (operands[callop], 0);
>  
>if (flag_pic && SYMBOL_REF_P (addr)
> @@ -2202,6 +2204,27 @@ xtensa_prepare_expand_call (int callop, rtx *operands)
>Pmode);
>XEXP (operands[callop], 0) = reg;
>  }
> +
> +  call = gen_rtx_CALL (VOIDmode, operands[callop], operands[callop + 1]);
> +
> +  if (callop)
> +call_insn = emit_call_insn (gen_rtx_SET (operands[0], call));
> +  else
> +call_insn = emit_call_insn (call);

;; Simpler,
   call = gen_rtx_CALL (VOIDmode, operands[callop], operands[callop + 1]);
-
   if (callop)
-call_insn = emit_call_insn (gen_rtx_SET (operands[0], call));
-  else
-call_insn = emit_call_insn (call);
+call = gen_rtx_SET (operands[0], call);
+  call_insn = emit_call_insn (call);

> +
> +  if (TARGET_WINDOWED_ABI)
> +{
> +  /*
> +   * Windowed xtensa ABI specifies that static chain pointer is passed
> +   * in memory below the caller stack pointer, which means that the 
> callee
> +   * will likely clobber it if it's a non-leaf function.
> +   * Add the clobber expression for the static chain to the function call
> +   * expression list so that it is not assumed to be live across the 
> call.
> +   */
> +  rtx clob = gen_rtx_CLOBBER (Pmode, xtensa_static_chain (NULL, false));
> +  CALL_INSN_FUNCTION_USAGE (call_insn) =
> + gen_rtx_EXPR_LIST (Pmode, clob, CALL_INSN_FUNCTION_USAGE (call_insn));
> +}
>  }
>  
>  
> diff --git a/gcc/config/xtensa/xtensa.md b/gcc/config/xtensa/xtensa.md
> index cf25beb83d54..b60dec2447f3 100644
> --- a/gcc/config/xtensa/xtensa.md
> +++ b/gcc/config/xtensa/xtensa.md
> @@ -2333,7 +2333,8 @@
>(match_operand 1 "" ""))]
>""
>  {
> -  xtensa_prepare_expand_call (0, operands);
> +  xtensa_expand_call (0, operands);
> +  DONE;
>  })
>  
>  (define_insn "call_internal"
> @@ -2353,7 +2354,8 @@
> (match_operand 2 "" "")))]
>""
>  {
> -  xtensa_prepare_expand_call (1, operands);
> +  xtensa_expand_call (1, operands);
> +  DONE;
>  })
>  
>  (define_insn "call_value_internal"
> @@ -2373,7 +2375,8 @@
>(match_operand 1 "" ""))]
>"!TARGET_WINDOWED_ABI"
>  {
> -  xtensa_prepare_expand_call (0, operands);
> +  xtensa_expand_call (0, operands);
> +  DONE;
>  })
>  
>  (define_insn "sibcall_internal"
> @@ -2393,7 +2396,8 @@
> (match_operand 2 "" "")))]
>"!TARGET_WINDOWED_ABI"
>  {
> -  xtensa_prepare_expand_call (1, operands);
> +  xtensa_expand_call (1, operands);
> +  DONE;
>  })
>  
>  (define_insn "sibcall_value_internal"
> diff --git a/gcc/testsuite/gcc.target/xtensa/pr108919.c 
>

[PATCH] gcc: xtensa: fix PR target/108919

2023-02-25 Thread Max Filippov via Gcc-patches 
gcc/
PR target/108919

* config/xtensa/xtensa-protos.h
(xtensa_prepare_expand_call): Rename to xtensa_expand_call.
* config/xtensa/xtensa.cc (xtensa_prepare_expand_call): Rename
to xtensa_expand_call.
(xtensa_expand_call): Emit the call and add a clobber expression
for the static chain to it in case of windowed ABI.
* config/xtensa/xtensa.md (call, call_value, sibcall)
(sibcall_value): Call xtensa_expand_call and complete expansion
right after that call.

gcc/testduite/
* gcc.target/xtensa/pr108919.c: New test.
---
 gcc/config/xtensa/xtensa-protos.h  |  2 +-
 gcc/config/xtensa/xtensa.cc| 25 +++-
 gcc/config/xtensa/xtensa.md| 12 --
 gcc/testsuite/gcc.target/xtensa/pr108919.c | 46 ++
 4 files changed, 79 insertions(+), 6 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/xtensa/pr108919.c

diff --git a/gcc/config/xtensa/xtensa-protos.h 
b/gcc/config/xtensa/xtensa-protos.h
index ecd0f0c8d108..c81cf94323ac 100644
--- a/gcc/config/xtensa/xtensa-protos.h
+++ b/gcc/config/xtensa/xtensa-protos.h
@@ -53,7 +53,7 @@ extern void xtensa_expand_atomic (enum rtx_code, rtx, rtx, 
rtx, bool);
 extern void xtensa_emit_loop_end (rtx_insn *, rtx *);
 extern char *xtensa_emit_branch (bool, rtx *);
 extern char *xtensa_emit_movcc (bool, bool, bool, rtx *);
-extern void xtensa_prepare_expand_call (int, rtx *);
+extern void xtensa_expand_call (int, rtx *);
 extern char *xtensa_emit_call (int, rtx *);
 extern char *xtensa_emit_sibcall (int, rtx *);
 extern bool xtensa_tls_referenced_p (rtx);
diff --git a/gcc/config/xtensa/xtensa.cc b/gcc/config/xtensa/xtensa.cc
index e52fba082550..babe7f0ebd68 100644
--- a/gcc/config/xtensa/xtensa.cc
+++ b/gcc/config/xtensa/xtensa.cc
@@ -2183,8 +2183,10 @@ xtensa_emit_movcc (bool inverted, bool isfp, bool 
isbool, rtx *operands)
 
 
 void
-xtensa_prepare_expand_call (int callop, rtx *operands)
+xtensa_expand_call (int callop, rtx *operands)
 {
+  rtx call;
+  rtx call_insn;
   rtx addr = XEXP (operands[callop], 0);
 
   if (flag_pic && SYMBOL_REF_P (addr)
@@ -2202,6 +2204,27 @@ xtensa_prepare_expand_call (int callop, rtx *operands)
 Pmode);
   XEXP (operands[callop], 0) = reg;
 }
+
+  call = gen_rtx_CALL (VOIDmode, operands[callop], operands[callop + 1]);
+
+  if (callop)
+call_insn = emit_call_insn (gen_rtx_SET (operands[0], call));
+  else
+call_insn = emit_call_insn (call);
+
+  if (TARGET_WINDOWED_ABI)
+{
+  /*
+   * Windowed xtensa ABI specifies that static chain pointer is passed
+   * in memory below the caller stack pointer, which means that the callee
+   * will likely clobber it if it's a non-leaf function.
+   * Add the clobber expression for the static chain to the function call
+   * expression list so that it is not assumed to be live across the call.
+   */
+  rtx clob = gen_rtx_CLOBBER (Pmode, xtensa_static_chain (NULL, false));
+  CALL_INSN_FUNCTION_USAGE (call_insn) =
+   gen_rtx_EXPR_LIST (Pmode, clob, CALL_INSN_FUNCTION_USAGE (call_insn));
+}
 }
 
 
diff --git a/gcc/config/xtensa/xtensa.md b/gcc/config/xtensa/xtensa.md
index cf25beb83d54..b60dec2447f3 100644
--- a/gcc/config/xtensa/xtensa.md
+++ b/gcc/config/xtensa/xtensa.md
@@ -2333,7 +2333,8 @@
 (match_operand 1 "" ""))]
   ""
 {
-  xtensa_prepare_expand_call (0, operands);
+  xtensa_expand_call (0, operands);
+  DONE;
 })
 
 (define_insn "call_internal"
@@ -2353,7 +2354,8 @@
  (match_operand 2 "" "")))]
   ""
 {
-  xtensa_prepare_expand_call (1, operands);
+  xtensa_expand_call (1, operands);
+  DONE;
 })
 
 (define_insn "call_value_internal"
@@ -2373,7 +2375,8 @@
 (match_operand 1 "" ""))]
   "!TARGET_WINDOWED_ABI"
 {
-  xtensa_prepare_expand_call (0, operands);
+  xtensa_expand_call (0, operands);
+  DONE;
 })
 
 (define_insn "sibcall_internal"
@@ -2393,7 +2396,8 @@
  (match_operand 2 "" "")))]
   "!TARGET_WINDOWED_ABI"
 {
-  xtensa_prepare_expand_call (1, operands);
+  xtensa_expand_call (1, operands);
+  DONE;
 })
 
 (define_insn "sibcall_value_internal"
diff --git a/gcc/testsuite/gcc.target/xtensa/pr108919.c 
b/gcc/testsuite/gcc.target/xtensa/pr108919.c
new file mode 100644
index ..300b6fd10a99
--- /dev/null
+++ b/gcc/testsuite/gcc.target/xtensa/pr108919.c
@@ -0,0 +1,46 @@
+/* { dg-do run } */
+/* { dg-options "-O2" } */
+
+
+#ifdef __XTENSA_CALL0_ABI__
+void __xtensa_libgcc_window_spill (void)
+{
+}
+#else
+void __xtensa_libgcc_window_spill (void);
+#endif
+
+__attribute__((noinline)) void h (void)
+{
+  __xtensa_libgcc_window_spill ();
+}
+
+int f (int u, int v)
+{
+  int a = u;
+  int s;
+
+  __attribute__((noinline,pure)) int nested1 (int b)
+  {
+  h();
+  return a + b;
+  }
+
+  __attribute__((noinline,pure)) int nested2 (int b)
+  {
+  h();
+  return a - b;
+  }
+
+  s = nested1 (v);
+

[PATCH v2] rs6000: fmr gets used instead of faster xxlor [PR93571]

2023-02-25 Thread Ajit Agarwal via Gcc-patches 
Hello All:

Here is the patch that uses xxlor instead of fmr where possible.
Performance results shows that fmr is better in power9 and 
power10 architectures whereas xxlor is better in power7 and
power 8 architectures. fmr is the only option before p7.

Bootstrapped and regtested on powerpc64-linux-gnu

Thanks & Regards
Ajit

rs6000: Use xxlor instead of fmr where possible

Replaces fmr with xxlor instruction for power7 and power8
architectures whereas for power9 and power10 keep fmr
instruction.

Perf measurement results:

Power9 fmr:  201,847,661 cycles.
Power9 xxlor: 201,877,78 cycles.
Power8 fmr: 200,901,043 cycles.
Power8 xxlor: 201,020,518 cycles.
Power7 fmr: 201,059,524 cycles.
Power7 xxlor: 201,042,851 cycles.

2023-02-25  Ajit Kumar Agarwal  

gcc/ChangeLog:

* config/rs6000/rs6000.md (*movdf_hardfloat64): Use xxlor for power7
and power8 and fmr for power9 and power10.
---
 gcc/config/rs6000/rs6000.md | 44 +++--
 1 file changed, 28 insertions(+), 16 deletions(-)

diff --git a/gcc/config/rs6000/rs6000.md b/gcc/config/rs6000/rs6000.md
index 81bffb04ceb..e101f7f5fc1 100644
--- a/gcc/config/rs6000/rs6000.md
+++ b/gcc/config/rs6000/rs6000.md
@@ -354,7 +354,7 @@ (define_attr "cpu"
   (const (symbol_ref "(enum attr_cpu) rs6000_tune")))
 
 ;; The ISA we implement.
-(define_attr "isa" "any,p5,p6,p7,p7v,p8v,p9,p9v,p9kf,p9tf,p10"
+(define_attr "isa" "any,p5,p6,p7,p7v,p8v,p7p8v,p9,p9v,p9kf,p9tf,p10"
   (const_string "any"))
 
 ;; Is this alternative enabled for the current CPU/ISA/etc.?
@@ -402,6 +402,11 @@ (define_attr "enabled" ""
  (and (eq_attr "isa" "p10")
  (match_test "TARGET_POWER10"))
  (const_int 1)
+  
+ (and (eq_attr "isa" "p7p8v")
+ (match_test "TARGET_VSX && !TARGET_P9_VECTOR"))
+ (const_int 1)
+
 ] (const_int 0)))
 
 ;; If this instruction is microcoded on the CELL processor
@@ -8436,27 +8441,29 @@ (define_insn "*mov_softfloat32"
 
 (define_insn "*mov_hardfloat64"
   [(set (match_operand:FMOVE64 0 "nonimmediate_operand"
-   "=m,   d,  d,  ,   wY,
- ,Z,  ,  ,  !r,
+   "=m,   d,  ,  ,   wY,
+ ,Z,  wa, ,  !r,
  YZ,  r,  !r, *c*l,   !r,
-*h,   r,  ,   wa")
+*h,   r,  ,   d,  wn,
+wa")
(match_operand:FMOVE64 1 "input_operand"
-"d,   m,  d,  wY, ,
- Z,   ,   ,  ,  ,
+"d,   m,  ,  wY, ,
+ Z,   ,   wa, ,  ,
  r,   YZ, r,  r,  *h,
- 0,   ,   r,  eP"))]
+ 0,   ,   r,  d,  wn,
+ eP"))]
   "TARGET_POWERPC64 && TARGET_HARD_FLOAT
&& (gpc_reg_operand (operands[0], mode)
|| gpc_reg_operand (operands[1], mode))"
   "@
stfd%U0%X0 %1,%0
lfd%U1%X1 %0,%1
-   fmr %0,%1
+   xxlor %x0,%x1,%x1
lxsd %0,%1
stxsd %1,%0
lxsdx %x0,%y1
stxsdx %x1,%y0
-   xxlor %x0,%x1,%x1
+   fmr %0,%1
xxlxor %x0,%x0,%x0
li %0,0
std%U0%X0 %1,%0
@@ -8467,23 +8474,28 @@ (define_insn "*mov_hardfloat64"
nop
mfvsrd %0,%x1
mtvsrd %x0,%1
+   fmr %0,%1
+   fmr %0,%1
#"
   [(set_attr "type"
-"fpstore, fpload, fpsimple,   fpload, fpstore,
+"fpstore, fpload, veclogical, fpload, fpstore,
  fpload,  fpstore,veclogical, veclogical, integer,
  store,   load,   *,  mtjmpr, mfjmpr,
- *,   mfvsr,  mtvsr,  vecperm")
+ *,   mfvsr,  mtvsr,  fpsimple,   fpsimple,
+ vecperm")
(set_attr "size" "64")
(set_attr "isa"
-"*,   *,  *,  p9v,p9v,
- p7v, p7v,*,  *,  *,
- *,   *,  *,  *,  *,
- *,   p8v,p8v,p10")
+"*,   *,  p7p8v,p9v,p9v,
+ p7v, p7v,*,   *,  *,
+ *,   *,  *,   *,  *,
+ *,   p8v,p8v, *,  *,
+ p10")
(set_attr "prefixed"
 "*,   *,  *,  *,  *,
  *,   *,  *,  *,  *,
  *,   *,  *,  *,  *,
- *,   *,  *,  *")])
+ *,   *,  *,  *,  *,
+ *")])
 
 ;;   STD  LD   MR  MT MF G-const
 ;;

Re: [Patch] Fortran/OpenMP: Fix mapping of array descriptors and deferred-length strings

2023-02-25 Thread Thomas Schwinge 
Hi Tobias!

On 2023-02-23T17:42:08+0100, Tobias Burnus  wrote:
> (Side note: this patch has been committed to OG12 as 
> http://gcc.gnu.org/g:55a18d47442 )

I see og12 commit 55a18d4744258e3909568e425f9f473c49f9d13f
"Fortran/OpenMP: Fix mapping of array descriptors and deferred-length strings"
regress existing test cases as follows:

[-PASS:-]{+FAIL:+} gfortran.dg/goacc/finalize-1.f   -O   
scan-tree-dump-times gimple "(?n)#pragma omp target oacc_exit_data 
map\\(delete:MEM <[^>]+> \\[\\(integer\\(kind=.\\)\\[0:\\] \\*\\)_[0-9]+\\] 
\\[len: [^\\]]+\\]\\) map\\(to:del_f_p \\[pointer set, len: [0-9]+\\]\\) 
map\\(alloc:del_f_p\\.data \\[pointer assign, bias: [^\\]]+\\]\\) finalize$" 1
PASS: gfortran.dg/goacc/finalize-1.f   -O   scan-tree-dump-times gimple 
"(?n)#pragma omp target oacc_exit_data map\\(delete:del_f \\[len: [0-9]+\\]\\) 
finalize$" 1
PASS: gfortran.dg/goacc/finalize-1.f   -O   scan-tree-dump-times gimple 
"(?n)#pragma omp target oacc_exit_data map\\(force_from:MEM <[^>]+> 
\\[\\(integer\\(kind=.\\)\\[0:\\] \\*\\)_[0-9]+\\] \\[len: [^\\]]+\\]\\) 
map\\(to:cpo_f_p \\[pointer set, len: [0-9]+\\]\\) map\\(alloc:cpo_f_p\\.data 
\\[pointer assign, bias: [^\\]]+\\]\\) finalize$" 1
PASS: gfortran.dg/goacc/finalize-1.f   -O   scan-tree-dump-times gimple 
"(?n)#pragma omp target oacc_exit_data map\\(force_from:cpo_f \\[len: 
[0-9]+\\]\\) finalize$" 1
@@ -54679,7 +54679,7 @@ PASS: gfortran.dg/goacc/finalize-1.f   -O   
scan-tree-dump-times gimple "(?n)#pr
PASS: gfortran.dg/goacc/finalize-1.f   -O   scan-tree-dump-times original 
"(?n)#pragma acc exit data map\\(from:\\*\\(integer\\(kind=.\\)\\[0:\\] \\*\\) 
parm\\.1\\.data \\[len: [^\\]]+\\]\\) map\\(to:cpo_f_p \\[pointer set, len: 
[0-9]+\\]\\) map\\(alloc:\\(integer\\(kind=1\\)\\[0:\\] \\* restrict\\) 
cpo_f_p\\.data \\[pointer assign, bias: \\(.*int.*\\) parm\\.1\\.data - 
\\(.*int.*\\) cpo_f_p\\.data\\]\\) finalize;$" 1
PASS: gfortran.dg/goacc/finalize-1.f   -O   scan-tree-dump-times original 
"(?n)#pragma acc exit data map\\(from:cpo_f\\) finalize;$" 1
PASS: gfortran.dg/goacc/finalize-1.f   -O   scan-tree-dump-times original 
"(?n)#pragma acc exit data map\\(from:cpo_r\\);$" 1
[-PASS:-]{+FAIL:+} gfortran.dg/goacc/finalize-1.f   -O   
scan-tree-dump-times original "(?n)#pragma acc exit data 
map\\(release:\\*\\(integer\\(kind=.\\)\\[0:\\] \\*\\) parm\\.0\\.data \\[len: 
[^\\]]+\\]\\) map\\(to:del_f_p \\[pointer set, len: [0-9]+\\]\\) 
map\\(alloc:\\(integer\\(kind=1\\)\\[0:\\] \\* restrict\\) del_f_p\\.data 
\\[pointer assign, bias: \\(.*int.*\\) parm\\.0\\.data - \\(.*int.*\\) 
del_f_p\\.data\\]\\) finalize;$" 1
PASS: gfortran.dg/goacc/finalize-1.f   -O   scan-tree-dump-times original 
"(?n)#pragma acc exit data map\\(release:del_f\\) finalize;$" 1
PASS: gfortran.dg/goacc/finalize-1.f   -O   scan-tree-dump-times original 
"(?n)#pragma acc exit data map\\(release:del_r\\);$" 1
PASS: gfortran.dg/goacc/finalize-1.f   -O  (test for excess errors)

[-PASS:-]{+FAIL:+} gfortran.dg/gomp/pr78260-2.f90   -O   
scan-tree-dump-times original "#pragma omp target data 
map\\(tofrom:\\*\\(integer\\(kind=4\\)\\[0:\\] \\* restrict\\) __result->data 
\\[len: D.[0-9]+ \\* 4\\]\\) map\\(to:\\*__result \\[pointer set, len: ..\\]\\) 
map\\(alloc:\\(integer\\(kind=4\\)\\[0:\\] \\* restrict\\) __result->data 
\\[pointer assign, bias: 0\\]\\) map\\(alloc:__result \\[pointer assign, bias: 
0\\]\\)" 1
[-PASS:-]{+FAIL:+} gfortran.dg/gomp/pr78260-2.f90   -O   
scan-tree-dump-times original "#pragma omp target data 
map\\(tofrom:\\*\\(integer\\(kind=4\\)\\[0:\\] \\* restrict\\) arr.data \\[len: 
D.[0-9]+ \\* 4\\]\\) map\\(to:arr \\[pointer set, len: ..\\]\\) 
map\\(alloc:\\(integer\\(kind=4\\)\\[0:\\] \\* restrict\\) arr.data \\[pointer 
assign, bias: 0\\]\\)" 1
PASS: gfortran.dg/gomp/pr78260-2.f90   -O   scan-tree-dump-times original 
"#pragma omp target data map\\(tofrom:\\*__result.0\\) map\\(alloc:__result.0 
\\[pointer assign, bias: 0\\]\\)" 2
PASS: gfortran.dg/gomp/pr78260-2.f90   -O   scan-tree-dump-times original 
"#pragma omp target data map\\(tofrom:__result_f1\\)" 1
PASS: gfortran.dg/gomp/pr78260-2.f90   -O   scan-tree-dump-times original 
"#pragma omp target update to\\(\\*\\(integer\\(kind=4\\)\\[0:\\] \\* 
restrict\\) __result->data \\[len: D.[0-9]+ \\* 4\\]\\)" 1

Do to the scan patterns need adjusting, or is something wrong?


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