Re: [wwwdocs] document modula-2 in gcc-13/changes.html (and index.html)

[Gerald Pfeifer]

Hi Gaius,

apologies, I thought you had pushed the updated patch and only now 
realized it's not in yet.

Please look into the few bits below and then go ahead and push.

On Mon, 6 Feb 2023, Gaius Mulley wrote:
>   * htdocs/frontends.html: An update to say the front end is now in
>   the development trunk.

Here we'd usually simply say

  * frontends: The Modula-2 front end is now on the 
  development trunk.

skiping "An update to say", or at least "An update to" and the "htdocs/" 
port (and adding which front end).

>   * htdocs/gcc-13/changes.html: A description of which dialects are
>   supported and the user level front end changes so far.

  * gcc-13: Note which Modula-2 dialects are...

>   * htdocs/index.html: Proposed news entry.

  * index: Announce Modula-2 inclusion 

(or something like that).

>   * htdocs/onlinedocs/index.html: PDF, PS and HTML documentation
>   links.
  * onlinedocs: Add links to Modula-2 documentation


> +The compiler is operational with GCC 10, GCC 11 GCC 12 (on
   
...GCC 11, and GCC 12...

> +GNU/Linux x86 systems).  The front end is now in the GCC development
> +trunk (GCC 13).  The front end is mostly written in Modula-2 and it
>  includes a bootstrap tool which translates Modula-2 into C/C++.

How about "It is mostly written in Modula-2 and includes..." to avoid
repetition of "the front end"?


Thank you,
Gerald

Re: [PATCH] Always define `WIN32_LEAN_AND_MEAN` before

[Xi Ruoyao via Gcc-patches]

On Sat, 2023-01-07 at 06:52 +, Jonathan Yong via Gcc-patches wrote:
> On 1/6/23 18:10, Jakub Jelinek wrote:
> > On Sat, Jan 07, 2023 at 02:01:05AM +0800, LIU Hao via Gcc-patches
> > wrote:
> > > libgomp/
> > > 
> > > PR middle-end/108300
> > > * config/mingw32/proc.c: Define `WIN32_LEAN_AND_MEAN`
> > > before
> > > .
> > 
> > This change is ok for trunk.
> > 
> > Jakub
> > 
> 
> Pushed to master branch, thanks LH.

The patch touches libgo (w/o mentioning it in the ChangeLog).  I guess
you need to contribute the libgo part into the upstream Go runtime or
the change will be undone when Ian merges libgo next time.

-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

Re: [PATCH][stage1] Remove conditionals around free()

[Jerry D via Gcc-patches]

On 3/3/23 3:32 PM, Iain Sandoe wrote:




On 3 Mar 2023, at 23:11, Bernhard Reutner-Fischer via Fortran 
 wrote:

On 2 March 2023 02:23:10 CET, Jerry D  wrote:

On 3/1/23 4:07 PM, Steve Kargl via Fortran wrote:

On Wed, Mar 01, 2023 at 10:28:56PM +0100, Bernhard Reutner-Fischer via Fortran 
wrote:

  libgfortran/caf/single.c |6 ++
  libgfortran/io/async.c   |6 ++
  libgfortran/io/format.c  |3 +--
  libgfortran/io/transfer.c|6 ++
  libgfortran/io/unix.c|3 +--


The Fortran ones are OK.



The only question I have: Is free posix compliant on all platforms?

For example ming64 or mac?


OSX / macOS are [certified] Posix compliant - but to unix03 (and might be 
missing features declared as optional at that revision, or features from later 
Posix versions).

In the case of free() man says:
"The free() function deallocates the memory allocation pointed to by ptr. If 
ptr is a NULL pointer, no operation is performed.”

Iain



  It seems sometimes we run into things like this once in a while.


I think we have the -liberty to cater even for non compliant systems either 
way, if you please excuse the pun. That's not an excuse on POSIX systems, imho.



I am certainly not a C++ expert but it seems to me this all begs for 
automatic finalization where one would not have to invoke free at all. 
I suspect the gfortran frontend is not designed for such things.





Otherwise I have no issue at all.  It is a lot cleaner.

Jerry

Re: [PATCH 01/07] RISC-V: Add auto-vectorization support

[Kito Cheng via Gcc-patches]

Hi Michael Collison:

It's REALLY NOT OK that you didn't mention RiVAI and Ju-Zhe in either
changelog or add he as co-author,
apparently you HAVE references and even copy his code from
https://github.com/riscv-collab/riscv-gcc/tree/riscv-gcc-rvv-next

Re: [PATCH v5] c++: -Wdangling-reference with reference wrapper [PR107532]

[Jason Merrill via Gcc-patches]

On 3/3/23 12:50, Marek Polacek wrote:

On Fri, Mar 03, 2023 at 11:25:06AM -0500, Jason Merrill wrote:

On 3/2/23 16:24, Marek Polacek wrote:

On Wed, Mar 01, 2023 at 04:53:23PM -0500, Jason Merrill wrote:

@@ -13791,12 +13830,39 @@ std_pair_ref_ref_p (tree t)
 const int& y = (f(1), 42); // NULL_TREE
 const int& z = f(f(1)); // f(f(1))
-   EXPR is the initializer.  */
+   EXPR is the initializer.  If ARG_P is true, we're processing an argument
+   to a function; the point is to distinguish between, for example,
+
+ Ref::inner (_EXPR )
+
+   where we shouldn't warn, and
+
+ Ref::inner (_EXPR )>)
+
+   where we should warn (Ref is a reference_like_class_p so we see through
+   it.  */
static tree
-do_warn_dangling_reference (tree expr)
+do_warn_dangling_reference (tree expr, bool arg_p)
{
  STRIP_NOPS (expr);
+  if (TREE_CODE (expr) == ADDR_EXPR)
+expr = TREE_OPERAND (expr, 0);


I think if we move this here, we also need to check that expr before
STRIP_NOPS had REFERENCE_TYPE.  OK with that change.


Sorry but I don't think I can do that.  There can be CONVERT_EXPRs
that need to be stripped, whether arg_p or !arg_p.  For example, we can get
(const int *) f ((const int &) _EXPR >)
for
const int& r5 = (42, f(10));


I meant that we only want to strip ADDR_EXPR if 'expr' at the start of the
function had REFERENCE_TYPE, corresponding to


 /* Check that this argument initializes a reference, except
for
the argument initializing the object of a member function.  */
 if (!DECL_NONSTATIC_MEMBER_FUNCTION_P (fndecl)
 && !TYPE_REF_P (TREE_TYPE (arg)))
   continue;


above the code for stripping an ADDR_EXPR from an argument that your patch
removes.


I see.


If the original expr is a pointer rather than a reference, we don't want to
complain about it pointing to a temporary.


Ug, I can't make it work.  When we recurse, I can no longer check
fndecl.  How about just moving the stripping back where it was?


Sure.


-- >8 --
Here, -Wdangling-reference triggers where it probably shouldn't, causing
some grief.  The code in question uses a reference wrapper with a member
function returning a reference to a subobject of a non-temporary object:

   const Plane & meta = fm.planes().inner();

I've tried a few approaches, e.g., checking that the member function's
return type is the same as the type of the enclosing class (which is
the case for member functions returning *this), but that then breaks
Wdangling-reference4.C with std::optional.

This patch adjusts do_warn_dangling_reference so that we look through
reference wrapper classes (meaning, has a reference member and a
constructor taking the same reference type, or is std::reference_wrapper
or std::ranges::ref_view) and don't warn for them, supposing that the
member function returns a reference to a non-temporary object.

PR c++/107532

gcc/cp/ChangeLog:

* call.cc (reference_like_class_p): New.
(do_warn_dangling_reference): Add new bool parameter.  See through
reference_like_class_p.

gcc/testsuite/ChangeLog:

* g++.dg/warn/Wdangling-reference8.C: New test.
* g++.dg/warn/Wdangling-reference9.C: New test.
---
  gcc/cp/call.cc| 92 ---
  .../g++.dg/warn/Wdangling-reference8.C| 77 
  .../g++.dg/warn/Wdangling-reference9.C| 21 +
  3 files changed, 176 insertions(+), 14 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/warn/Wdangling-reference8.C
  create mode 100644 gcc/testsuite/g++.dg/warn/Wdangling-reference9.C

diff --git a/gcc/cp/call.cc b/gcc/cp/call.cc
index 048b2b052f8..62536573633 100644
--- a/gcc/cp/call.cc
+++ b/gcc/cp/call.cc
@@ -13779,6 +13779,45 @@ std_pair_ref_ref_p (tree t)
return true;
  }
  
+/* Return true if a class CTYPE is either std::reference_wrapper or

+   std::ref_view, or a reference wrapper class.  We consider a class
+   a reference wrapper class if it has a reference member and a
+   constructor taking the same reference type.  */
+
+static bool
+reference_like_class_p (tree ctype)
+{
+  tree tdecl = TYPE_NAME (TYPE_MAIN_VARIANT (ctype));
+  if (decl_in_std_namespace_p (tdecl))
+{
+  tree name = DECL_NAME (tdecl);
+  return (name
+ && (id_equal (name, "reference_wrapper")
+ || id_equal (name, "ref_view")));
+}
+  for (tree fields = TYPE_FIELDS (ctype);
+   fields;
+   fields = DECL_CHAIN (fields))
+{
+  if (TREE_CODE (fields) != FIELD_DECL || DECL_ARTIFICIAL (fields))
+   continue;
+  tree type = TREE_TYPE (fields);
+  if (!TYPE_REF_P (type))
+   continue;
+  /* OK, the field is a reference member.  Do we have a constructor
+taking its type?  */
+  for (tree fn : ovl_range (CLASSTYPE_CONSTRUCTORS (ctype)))
+   {
+ tree args = FUNCTION_FIRST_USER_PARMTYPE (fn);
+ if (args
+ && same_type_p 

Ping: [PATCH 1/2] testsuite: Provide means to regexp in multiline patterns

[Hans-Peter Nilsson via Gcc-patches]

Ping...

> From: Hans-Peter Nilsson 
> Date: Fri, 24 Feb 2023 20:16:03 +0100
> 
> Ok to commit?
> -- >8 --
> Those multi-line-patterns are literal.  Sometimes a regexp
> needs to be matched.  This is a start: just three elements
> are supported: "(" ")" and the compound ")?" (and on second
> thought, it can be argued that "(...)" alone is not useful).
> Note that Tcl "string map" is documented to have the desired
> effect: a once-over but no re-recognitions of previously
> replaced mapped elements.  Also, drop a doubled "containing".
> 
> testsuite:
>   * lib/multiline.exp (_build_multiline_regex): Map
>   "{re:" to "(", ":re}" to ")" and ":re?}" to ")?".
> ---
>  gcc/testsuite/lib/multiline.exp | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/gcc/testsuite/lib/multiline.exp b/gcc/testsuite/lib/multiline.exp
> index 5eccf2bbebc1..f746bc3a618e 100644
> --- a/gcc/testsuite/lib/multiline.exp
> +++ b/gcc/testsuite/lib/multiline.exp
> @@ -297,7 +297,7 @@ proc _get_lines { filename first_line last_line } {
>  
>  # Convert $multiline from a list of strings to a multiline regex
>  # We need to support matching arbitrary followup text on each line,
> -# to deal with comments containing containing DejaGnu directives.
> +# to deal with comments containing DejaGnu directives.
>  
>  proc _build_multiline_regex { multiline index } {
>  verbose "_build_multiline_regex: $multiline $index" 4
> @@ -307,7 +307,10 @@ proc _build_multiline_regex { multiline index } {
>   verbose "  line: $line" 4
>  
>   # We need to escape "^" and other regexp metacharacters.
> - set line [string map {"^" "\\^"
> + set line [string map {"\{re:" "("
> +   ":re?\}" ")?"
> +   ":re\}" ")"
> +   "^" "\\^"
> "(" "\\("
> ")" "\\)"
> "[" "\\["
> -- 
> 2.30.2
> 

Re: Patch ping

[Joseph Myers]

On Wed, 1 Mar 2023, Jakub Jelinek via Gcc-patches wrote:

> Hi!
> 
> I'd like to ping a few pending patches:
> 
> https://gcc.gnu.org/pipermail/gcc-patches/2022-November/607534.html
>   - PR107846 - P1 - c-family: Account for integral promotions of left shifts 
> for -Wshift-overflow warning

OK.

> https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606973.html
>   - PR107465 - P2 - c-family: Fix up -Wsign-compare BIT_NOT_EXPR handling

OK.

> https://gcc.gnu.org/pipermail/gcc-patches/2022-November/607104.html
>   - PR107465 - P2 - c-family: Incremental fix for -Wsign-compare BIT_NOT_EXPR 
> handling

OK.

-- 
Joseph S. Myers
jos...@codesourcery.com

[COMMITTED] testsuite: Skip gcc.dg/ipa/pr77653.c for CRIS

[Hans-Peter Nilsson via Gcc-patches]

CRIS defines DATA_ALIGNMENT such that alignment can be
applied differently to different data of the same type, when
"references to it must bind to the current definition"
(varasm.cc:align_variable).  Here, it means that more
alignment is then applied to g, but not f, so the test-case
fails because another message is emitted than the expected:
a same-alignment test dominates the not-discardable test,
and we get "Not unifying; original and alias have
incompatible alignments" rather than "Not unifying; alias
cannot be created; target is discardable".  Because this
DATA_ALIGNMENT behavior for CRIS depends on target options,
and this test is already artificial by the use of -fcommon,
better skip it.

* gcc.dg/ipa/pr77653.c: Skip for cris-*-*.
---
 gcc/testsuite/gcc.dg/ipa/pr77653.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/gcc/testsuite/gcc.dg/ipa/pr77653.c 
b/gcc/testsuite/gcc.dg/ipa/pr77653.c
index 2fddb7eab548..16df3fff6a41 100644
--- a/gcc/testsuite/gcc.dg/ipa/pr77653.c
+++ b/gcc/testsuite/gcc.dg/ipa/pr77653.c
@@ -1,5 +1,6 @@
 /* { dg-require-alias "" } */
 /* { dg-options "-O2 -fcommon -fdump-ipa-icf-details"  } */
+/* { dg-skip-if "Can align g more than f" { cris-*-* } } */
 
 int a, b, c, d, e, h, i, j, k, l;
 const int f;
-- 
2.30.2

[COMMITTED] testsuite: Skip gcc.dg/ifcvt-4.c for CRIS

[Hans-Peter Nilsson via Gcc-patches]

CRIS has no conditional execution and no conditional moves.

* gcc.dg/ifcvt-4.c: Add cris-*-* to skip list.
---
 gcc/testsuite/gcc.dg/ifcvt-4.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.dg/ifcvt-4.c b/gcc/testsuite/gcc.dg/ifcvt-4.c
index 46245f0d0698..8b2583d00e92 100644
--- a/gcc/testsuite/gcc.dg/ifcvt-4.c
+++ b/gcc/testsuite/gcc.dg/ifcvt-4.c
@@ -2,7 +2,7 @@
 /* { dg-additional-options "-misel" { target { powerpc*-*-* } } } */
 /* { dg-additional-options "-march=z196" { target { s390x-*-* } } } */
 /* { dg-additional-options "-mtune-ctrl=^one_if_conv_insn" { target { i?86-*-* 
x86_64-*-* } } } */
-/* { dg-skip-if "Multiple set if-conversion not guaranteed on all subtargets" 
{ "arm*-*-* avr-*-* hppa*64*-*-* visium-*-*" riscv*-*-* msp430-*-* nios2-*-* 
pru-*-* } }  */
+/* { dg-skip-if "Multiple set if-conversion not guaranteed on all subtargets" 
{ "arm*-*-* avr-*-* cris-*-* hppa*64*-*-* visium-*-*" riscv*-*-* msp430-*-* 
nios2-*-* pru-*-* } }  */
 /* { dg-skip-if "" { "s390x-*-*" } { "-m31" } }  */
 
 typedef int word __attribute__((mode(word)));
-- 
2.30.2

[COMMITTED] testsuite: Fix various scan-assembler identifiers not handling _-prefix

[Hans-Peter Nilsson via Gcc-patches]

Committed as obvious.
-- >8 --
* g++.dg/cpp0x/pr84497.C: Handle USER_LABEL_PREFIX == "_" on
scan-assembler identifiers.
* gcc.dg/debug/btf/btf-enum64-1.c, gcc.dg/ipa/symver1.c: Ditto.
---
 gcc/testsuite/g++.dg/cpp0x/pr84497.C  | 6 +++---
 gcc/testsuite/gcc.dg/debug/btf/btf-enum64-1.c | 6 +++---
 gcc/testsuite/gcc.dg/ipa/symver1.c| 4 ++--
 3 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/gcc/testsuite/g++.dg/cpp0x/pr84497.C 
b/gcc/testsuite/g++.dg/cpp0x/pr84497.C
index 7eb1aee474e3..be5a9d359ec5 100644
--- a/gcc/testsuite/g++.dg/cpp0x/pr84497.C
+++ b/gcc/testsuite/g++.dg/cpp0x/pr84497.C
@@ -34,6 +34,6 @@ extern thread_local Container container_obj;
 int main() { return !(_obj && _obj && _obj);}
 #endif
 
-// { dg-final { scan-assembler ".weak\[ \t\]*_ZTH8base_obj" } }
-// { dg-final { scan-assembler ".weak\[ \t\]*_ZTH11derived_obj" } }
-// { dg-final { scan-assembler ".weak\[ \t\]*_ZTH13container_obj" } }
+// { dg-final { scan-assembler ".weak\[ \t\]*_?_ZTH8base_obj" } }
+// { dg-final { scan-assembler ".weak\[ \t\]*_?_ZTH11derived_obj" } }
+// { dg-final { scan-assembler ".weak\[ \t\]*_?_ZTH13container_obj" } }
diff --git a/gcc/testsuite/gcc.dg/debug/btf/btf-enum64-1.c 
b/gcc/testsuite/gcc.dg/debug/btf/btf-enum64-1.c
index e443d4c8c00f..5d1487c1183a 100644
--- a/gcc/testsuite/gcc.dg/debug/btf/btf-enum64-1.c
+++ b/gcc/testsuite/gcc.dg/debug/btf/btf-enum64-1.c
@@ -3,9 +3,9 @@
 /* { dg-do compile } */
 /* { dg-options "-O0 -gbtf -dA" } */
 
-/* { dg-final { scan-assembler-times "\[\t \].size\[\t \]myenum1,\[\t \]8" 1 } 
} */
-/* { dg-final { scan-assembler-times "\[\t \].size\[\t \]myenum2,\[\t \]8" 1 } 
} */
-/* { dg-final { scan-assembler-times "\[\t \].size\[\t \]myenum3,\[\t \]8" 1 } 
} */
+/* { dg-final { scan-assembler-times "\[\t \].size\[\t \]_?myenum1,\[\t \]8" 1 
} } */
+/* { dg-final { scan-assembler-times "\[\t \].size\[\t \]_?myenum2,\[\t \]8" 1 
} } */
+/* { dg-final { scan-assembler-times "\[\t \].size\[\t \]_?myenum3,\[\t \]8" 1 
} } */
 /* { dg-final { scan-assembler-times "\[\t \]0x1303\[\t 
\]+\[^\n\]*btt_info" 2 } } */
 /* { dg-final { scan-assembler-times "\[\t \]0x9303\[\t 
\]+\[^\n\]*btt_info" 1 } } */
 /* { dg-final { scan-assembler-times "\[\t \]0xffaa\[\t 
\]+\[^\n\]*bte_value_lo32" 2 } } */
diff --git a/gcc/testsuite/gcc.dg/ipa/symver1.c 
b/gcc/testsuite/gcc.dg/ipa/symver1.c
index 2cd025836697..d120ed5d76b1 100644
--- a/gcc/testsuite/gcc.dg/ipa/symver1.c
+++ b/gcc/testsuite/gcc.dg/ipa/symver1.c
@@ -8,5 +8,5 @@ int foo()
   return 2;
 }
 
-/* { dg-final { scan-assembler ".symver.*foo, foo@VER_2" } } */
-/* { dg-final { scan-assembler ".symver.*foo, foo@VER_3" } } */
+/* { dg-final { scan-assembler ".symver.*foo, _?foo@VER_2" } } */
+/* { dg-final { scan-assembler ".symver.*foo, _?foo@VER_3" } } */
-- 
2.30.2

RISC-V: Add auto-vectorization support

[juzhe.zhong]

>> This series of patches adds foundational support for RISC-V 
>> autovectorization. These patches are based on the current upstream rvv 
>> vector intrinsic support and is not a new implementation. Most of the 
>> implementation consists of adding the new vector cost model, the 
>> autovectorization patterns themselves and target hooks.
>> This implementation only provides support for integer addition and 
>> subtraction as a proof of concept.
>> As discussed on this list, if these patches are approved they will be 
>> merged into a "auto-vectorization" branch once gcc-13 branches for release.
>> There are two known issues related to crashes (assert failures) 
>> associated with tree vectorization; one of which I have sent a patch for 
>> and have received feedback. I will be sending a patch for the second 
>> issue tomorrow.

These patches have so many issues:
1. You should not arithmetic operation without supporting auto-vectorization 
load/stores.
2. RVV cost model is totally incorrect since they are just my experimental work 
without any
benchmark tuning.
3. ICE in auto-vectorization base on current upstream framework.
4. The vector-length/LMUL compile option is not ratified, we can't push the 
unratified
compile option. The compile option should be consistent with LLVM.
5. The current RVV instruction machine descriptions are not stable, you can not 
support auto-vec
base on unstable machine descriptions.
etc. so many issues.

So I totally disagree this set of pathes. These patches are coming from my 
original ugly experimental 
RVV work in RISC-V repo:
https://github.com/riscv-collab/riscv-gcc/tree/riscv-gcc-rvv-next  that I 
already abandoned (I no longer maintained). 

Currently, we (I && kito) have finished all intrinsics (except segment 
instructions) and machine descriptions,
we will keep testing and fine-tunning && fix bugs until GCC 13 release.  We 
should wait until machine descriptions
are stable to support auto-vec. So don't do any auto-vec during stage 4 in GCC 
13 plz. 

I have an elegent implementation in my downstream.
And I will start to auto-vec when GCC 14 is open.

Thanks.


juzhe.zh...@rivai.ai

Re: [PATCH][stage1] Remove conditionals around free()

[Iain Sandoe]

> On 3 Mar 2023, at 23:11, Bernhard Reutner-Fischer via Fortran 
>  wrote:
> 
> On 2 March 2023 02:23:10 CET, Jerry D  wrote:
>> On 3/1/23 4:07 PM, Steve Kargl via Fortran wrote:
>>> On Wed, Mar 01, 2023 at 10:28:56PM +0100, Bernhard Reutner-Fischer via 
>>> Fortran wrote:
  libgfortran/caf/single.c |6 ++
  libgfortran/io/async.c   |6 ++
  libgfortran/io/format.c  |3 +--
  libgfortran/io/transfer.c|6 ++
  libgfortran/io/unix.c|3 +--
>>> 
>>> The Fortran ones are OK.
>>> 
>> 
>> The only question I have: Is free posix compliant on all platforms?
>> 
>> For example ming64 or mac?

OSX / macOS are [certified] Posix compliant - but to unix03 (and might be 
missing features declared as optional at that revision, or features from later 
Posix versions).

In the case of free() man says:
"The free() function deallocates the memory allocation pointed to by ptr. If 
ptr is a NULL pointer, no operation is performed.”

Iain


>>  It seems sometimes we run into things like this once in a while.
> 
> I think we have the -liberty to cater even for non compliant systems either 
> way, if you please excuse the pun. That's not an excuse on POSIX systems, 
> imho.
> 
>> 
>> Otherwise I have no issue at all.  It is a lot cleaner.
>> 
>> Jerry

[pushed] analyzer: start adding test coverage for OpenMP [PR109016]

[David Malcolm via Gcc-patches]

Successfully tested on x86_64-pc-linux-gnu.
Pushed to trunk as r13-6467-gdf0184906a7b86.

gcc/testsuite/ChangeLog:
PR analyzer/109016
* gcc.dg/analyzer/omp-parallel-for-1.c: New test.
* gcc.dg/analyzer/omp-parallel-for-get-min.c: New test.

Signed-off-by: David Malcolm 
---
 .../gcc.dg/analyzer/omp-parallel-for-1.c  | 21 
 .../analyzer/omp-parallel-for-get-min.c   | 24 +++
 2 files changed, 45 insertions(+)
 create mode 100644 gcc/testsuite/gcc.dg/analyzer/omp-parallel-for-1.c
 create mode 100644 gcc/testsuite/gcc.dg/analyzer/omp-parallel-for-get-min.c

diff --git a/gcc/testsuite/gcc.dg/analyzer/omp-parallel-for-1.c 
b/gcc/testsuite/gcc.dg/analyzer/omp-parallel-for-1.c
new file mode 100644
index 000..dae940dac20
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/analyzer/omp-parallel-for-1.c
@@ -0,0 +1,21 @@
+/* { dg-additional-options "-fopenmp -Wall" } */
+
+typedef struct _Image
+{
+  int columns, rows;
+} Image;
+
+extern int get_num_threads(void);
+
+void
+test (Image* image)
+{
+  int y;
+
+#pragma omp parallel for schedule(static) \
+  num_threads(get_num_threads ())
+
+  for (y = 0; y < image->rows; y++) {
+/* [...snip...] */
+  }
+}
diff --git a/gcc/testsuite/gcc.dg/analyzer/omp-parallel-for-get-min.c 
b/gcc/testsuite/gcc.dg/analyzer/omp-parallel-for-get-min.c
new file mode 100644
index 000..a7e64e1a3a8
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/analyzer/omp-parallel-for-get-min.c
@@ -0,0 +1,24 @@
+/* Reduced from ImageMagick-7.1.0-57's MagickCore/attribute.c: 
GetEdgeBackgroundColor */
+
+/* { dg-additional-options "-fopenmp -Wall" } */
+
+extern double get_census (void);
+
+double
+test()
+{
+  double census[4], edge_census;
+  int i;
+
+#pragma omp parallel for schedule(static)
+
+  for (i = 0; i < 4; i++) {
+census[i] = get_census ();
+  }
+  edge_census = (-1.0);
+  for (i = 0; i < 4; i++)
+if (census[i] > edge_census) { /* { dg-bogus "use of uninitialized value" 
} */
+  edge_census = census[i];
+}
+  return edge_census;
+}
-- 
2.26.3

Re: [PATCH][stage1] Remove conditionals around free()

[Bernhard Reutner-Fischer via Gcc-patches]

On 2 March 2023 02:23:10 CET, Jerry D  wrote:
>On 3/1/23 4:07 PM, Steve Kargl via Fortran wrote:
>> On Wed, Mar 01, 2023 at 10:28:56PM +0100, Bernhard Reutner-Fischer via 
>> Fortran wrote:
>>>   libgfortran/caf/single.c |6 ++
>>>   libgfortran/io/async.c   |6 ++
>>>   libgfortran/io/format.c  |3 +--
>>>   libgfortran/io/transfer.c|6 ++
>>>   libgfortran/io/unix.c|3 +--
>> 
>> The Fortran ones are OK.
>> 
>
>The only question I have: Is free posix compliant on all platforms?
>
>For example ming64 or mac?  It seems sometimes we run into things like this 
>once in a while.

I think we have the -liberty to cater even for non compliant systems either 
way, if you please excuse the pun. That's not an excuse on POSIX systems, imho.

>
>Otherwise I have no issue at all.  It is a lot cleaner.
>
>Jerry

Re: [PATCH] wwwdocs: Document several further C++23 changes

[Gerald Pfeifer]

On Thu, 2 Mar 2023, Jakub Jelinek wrote:
> +  A new statement attribute for C++23  href="https://wg21.link/p1774r8;>P1774R8 Portable
> +  assumptions support also in C or older C++:

This reads a bit odd to me: is there a comma missing after P1774R8?
And maybe a colon before? Or something like that?

Gerald

[committed] analyzer: provide placeholder implementation of sprintf

[David Malcolm via Gcc-patches]

Previously, the analyzer lacked a known_function implementation of
sprintf, and thus would handle calls to sprintf with the "anything could
happen" fallback.

Whilst working on PR analyzer/107565 I noticed that this was preventing
a lot of genuine memory leaks from being reported for Doom; fixing
thusly.

Integration testing of the effect of the patch shows a big increase in
true positives due to the case mentioned in Doom, and one new false
positive (in pcre2), which I'm tracking as PR analyzer/109014.

Comparison:
  GOOD:  67 -> 123 (+56); 10.91% -> 18.33%
   BAD: 547 -> 548 (+1)

where the affected warnings/projects are:
 
  -Wanalyzer-malloc-leak:
GOOD:  0 -> 56 (+56);  0.00% -> 41.48%
 BAD: 79
  True positives: 0 -> 56 (+56)
(all in Doom)

  -Wanalyzer-use-of-uninitialized-value:
GOOD: 0;  0.00%
 BAD: 80 -> 81 (+1)
  False positives:
pcre2-10.42: 0 -> 1 (+1)

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r13-6466-g56572a08ec4a0f.

gcc/analyzer/ChangeLog:
* kf.cc (class kf_sprintf): New.
(register_known_functions): Register it.

gcc/testsuite/ChangeLog:
* gcc.dg/analyzer/doom-d_main-IdentifyVersion.c: New test.
* gcc.dg/analyzer/sprintf-1.c: New test.
* gcc.dg/analyzer/sprintf-concat.c: New test.

Signed-off-by: David Malcolm 
---
 gcc/analyzer/kf.cc|  29 ++
 .../analyzer/doom-d_main-IdentifyVersion.c| 272 ++
 gcc/testsuite/gcc.dg/analyzer/sprintf-1.c |  64 +
 .../gcc.dg/analyzer/sprintf-concat.c  |  35 +++
 4 files changed, 400 insertions(+)
 create mode 100644 gcc/testsuite/gcc.dg/analyzer/doom-d_main-IdentifyVersion.c
 create mode 100644 gcc/testsuite/gcc.dg/analyzer/sprintf-1.c
 create mode 100644 gcc/testsuite/gcc.dg/analyzer/sprintf-concat.c

diff --git a/gcc/analyzer/kf.cc b/gcc/analyzer/kf.cc
index 3a91b6bd6eb..c4485153e1b 100644
--- a/gcc/analyzer/kf.cc
+++ b/gcc/analyzer/kf.cc
@@ -778,6 +778,34 @@ kf_strchr::impl_call_post (const call_details ) const
 }
 }
 
+/* Handler for "sprintf".
+ int sprintf(char *str, const char *format, ...);
+*/
+
+class kf_sprintf : public known_function
+{
+public:
+  bool matches_call_types_p (const call_details ) const final override
+  {
+return (cd.num_args () >= 2
+   && cd.arg_is_pointer_p (0)
+   && cd.arg_is_pointer_p (1));
+  }
+
+  void impl_call_pre (const call_details ) const final override
+  {
+/* For now, merely assume that the destination buffer gets set to a
+   new svalue.  */
+region_model *model = cd.get_model ();
+region_model_context *ctxt = cd.get_ctxt ();
+const svalue *dst_ptr = cd.get_arg_svalue (0);
+const region *dst_reg
+  = model->deref_rvalue (dst_ptr, cd.get_arg_tree (0), ctxt);
+const svalue *content = cd.get_or_create_conjured_svalue (dst_reg);
+model->set_value (dst_reg, content, ctxt);
+  }
+};
+
 /* Handler for "__builtin_stack_restore".  */
 
 class kf_stack_restore : public known_function
@@ -990,6 +1018,7 @@ register_known_functions (known_function_manager )
 kfm.add (BUILT_IN_MEMSET, make_unique ());
 kfm.add (BUILT_IN_MEMSET_CHK, make_unique ());
 kfm.add (BUILT_IN_REALLOC, make_unique ());
+kfm.add (BUILT_IN_SPRINTF, make_unique ());
 kfm.add (BUILT_IN_STACK_RESTORE, make_unique ());
 kfm.add (BUILT_IN_STACK_SAVE, make_unique ());
 kfm.add (BUILT_IN_STRCHR, make_unique ());
diff --git a/gcc/testsuite/gcc.dg/analyzer/doom-d_main-IdentifyVersion.c 
b/gcc/testsuite/gcc.dg/analyzer/doom-d_main-IdentifyVersion.c
new file mode 100644
index 000..982b9b74349
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/analyzer/doom-d_main-IdentifyVersion.c
@@ -0,0 +1,272 @@
+/* Reduced from Doom's d_main.c, which is under the GPLv2 or later.  */
+
+/* { dg-additional-options "-Wno-analyzer-too-complex" } */
+
+typedef __SIZE_TYPE__ size_t;
+typedef struct _IO_FILE FILE;
+
+extern int
+printf(const char* __restrict, ...);
+
+extern int
+sprintf(char* __restrict __s, const char* __restrict, ...)
+  __attribute__((__nothrow__));
+
+extern void*
+malloc(size_t __size) __attribute__((__nothrow__, __leaf__))
+__attribute__((__malloc__)) __attribute__((__alloc_size__(1)));
+extern char*
+getenv(const char* __name) __attribute__((__nothrow__, __leaf__))
+__attribute__((__nonnull__(1)));
+extern int
+access(const char* __name, int __type) __attribute__((__nothrow__, __leaf__))
+__attribute__((__nonnull__(1)));
+extern char*
+strcpy(char* __restrict __dest, const char* __restrict __src)
+  __attribute__((__nothrow__, __leaf__)) __attribute__((__nonnull__(1, 2)));
+extern size_t
+strlen(const char* __s) __attribute__((__nothrow__, __leaf__))
+__attribute__((__pure__)) __attribute__((__nonnull__(1)));
+
+typedef enum
+{
+  shareware,
+  registered,
+  commercial,
+
+  retail,
+  indetermined
+
+} GameMode_t;
+
+typedef enum
+{
+  doom,
+  doom2,
+  pack_tnt,
+  pack_plut,
+  none
+
+} 

[pushed] testsuite: remove XFAIL in gcc.dg/analyzer/pr99716-1.c [PR108988]

[David Malcolm via Gcc-patches]

Jakub's r13-6441-gdbeccab7a1f5dc fix for PR tree-optimization/108988
has fixed this failing analyzer test.

Successfully tested on x86_64-pc-linux-gnu.
Pushed to trunk as r13-6465-gd3ef73867e3f70.

gcc/testsuite/ChangeLog:
PR tree-optimization/108988
* gcc.dg/analyzer/pr99716-1.c (test_2): Remove xfail.

Signed-off-by: David Malcolm 
---
 gcc/testsuite/gcc.dg/analyzer/pr99716-1.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/gcc/testsuite/gcc.dg/analyzer/pr99716-1.c 
b/gcc/testsuite/gcc.dg/analyzer/pr99716-1.c
index 4fae368f321..2ccdcc73a5c 100644
--- a/gcc/testsuite/gcc.dg/analyzer/pr99716-1.c
+++ b/gcc/testsuite/gcc.dg/analyzer/pr99716-1.c
@@ -27,11 +27,7 @@ test_2 (void)
 FILE *fp = fopen ("/tmp/test", "w");
 fprintf (fp, "hello");
   }
-} /* { dg-warning "leak of FILE 'fp'" "" { xfail *-*-* } } */
-/* TODO: fails on some targets due to fprintf call being optimized to
-   __builtin_fwrite with a size argument (idx 2) that fails
-   gimple_builtin_call_types_compatible_p, and thus the known_function
-   for __builtin_fwrite not being used (PR middle-end/108988).  */
+} /* { dg-warning "leak of FILE 'fp'" } */
 
 FILE *fp3;
 
-- 
2.26.3

Re: [PATCH] wwwdocs: Document several further C++23 changes

[Gerald Pfeifer]

On Thu, 2 Mar 2023, Jakub Jelinek wrote:
> Tobias mentioned on IRC that assume attribute wasn't mentioned in
> changes.html.  The P1774R8 entry was missing for C++, so I went through
> projects/cxx-status.html#cxx23 and filled in all the missing papers
> which have been implemented newly in GCC 13, plus a small note for C family
> about assume attribute.

Nice!

There was a small markup issue -- unclosed  -- which I fixed 
thusly.

Gerald


commit ec6f12dc7c229ba1662706c14083e6f3a78e2760
Author: Gerald Pfeifer 
Date:   Fri Mar 3 23:53:21 2023 +0100

gcc-13: Properly close an 

diff --git a/htdocs/gcc-13/changes.html b/htdocs/gcc-13/changes.html
index 839b73d0..cb6a9ec2 100644
--- a/htdocs/gcc-13/changes.html
+++ b/htdocs/gcc-13/changes.html
@@ -184,7 +184,7 @@ a work-in-progress.
   
   A new statement attribute for C++23 https://wg21.link/p1774r8;>P1774R8 Portable
   assumptions support also in C or older C++:
-https://gcc.gnu.org/onlinedocs/gcc/Statement-Attributes.html#index-assume-statement-attribute;>__attribute__((assume(EXPR)));
+  https://gcc.gnu.org/onlinedocs/gcc/Statement-Attributes.html#index-assume-statement-attribute;>__attribute__((assume(EXPR)));
   
 
 

Re: [wwwdocs] Document allocator_traits::rebind_alloc assertion with GCC 13

[Gerald Pfeifer]

On Thu, 2 Mar 2023, Jonathan Wakely via Gcc-patches wrote:
> Pushed to wwwdocs.

Thank you!

> +If an allocator type AllocT

Note that HTML 5 complains about the use of  and we are using  
instead.

I just pushed the following patch addressing that. (The diff looks a bit 
bigger due to changes re line breaks.)

Gerald


commit 5a75fbda8c3c647b2ef659ffe67a031ee957abe6
Author: Gerald Pfeifer 
Date:   Fri Mar 3 23:41:36 2023 +0100

gcc-13: Use  instead of 

diff --git a/htdocs/gcc-13/porting_to.html b/htdocs/gcc-13/porting_to.html
index 953e1453..733bb254 100644
--- a/htdocs/gcc-13/porting_to.html
+++ b/htdocs/gcc-13/porting_to.html
@@ -150,8 +150,8 @@ previous behavior.
 GCC 13 now checks that allocators used with the standard library
 can be "rebound" to allocate memory for a different type,
 as required by the allocator requirements in the C++ standard.
-If an allocator type AllocT
-cannot be correctly rebound to another type AllocU,
+If an allocator type AllocT
+cannot be correctly rebound to another type AllocU,
 you will get an error like this:
 
 
@@ -161,26 +161,27 @@ you will get an error like this:
 
 
 The assertion checks that rebinding an allocator to its own value type is a
-no-op, which will be true if its rebind member is defined correctly.
+no-op, which will be true if its rebind member is defined 
correctly.
 If rebinding it to its own value type produces a different type,
 then the allocator cannot be used with the standard library.
 
 
 
-The most common cause of this error is an allocator type 
AllocT
-that derives from std::allocatorT but does not provide its own
-rebind member. When the standard library attempts to rebind the
-allocator using AllocT::rebindU it finds the
-std::allocatorT::rebindU member from the base class,
-and the result is std::allocatorU instead of
-AllocU.
+The most common cause of this error is an allocator type
+AllocT that derives from
+std::allocatorT but does not provide its own
+rebind member. When the standard library attempts to rebind the
+allocator using AllocT::rebindU it finds the
+std::allocatorT::rebindU member from the base
+class, and the result is std::allocatorU instead of
+AllocU.
 
 
 
-The solution is to provide a correct rebind member as shown below.
-A converting constructor must also be provided, so that that an
-AllocU can be constructed from an AllocT,
-and vice versa:
+The solution is to provide a correct rebind member as shown
+below.  A converting constructor must also be provided, so that that an
+AllocU can be constructed from an
+AllocT, and vice versa:
 
 
 templateclass T
@@ -197,9 +198,10 @@ class Alloc
 
 
 
-Since C++20, there is no rebind member in std::allocator,
-so deriving your own allocator types from std::allocator is simpler
-and doesn't require the derived allocator to provide its own rebind.
+Since C++20, there is no rebind member in
+std::allocator, so deriving your own allocator types from
+std::allocator is simpler and doesn't require the derived
+allocator to provide its own rebind.
 For compatibility with previous C++ standards, the member should still be
 provided. The converting constructor is still required even in C++20.
 

Re: [PATCH] Fortran: fix CLASS attribute handling [PR106856]

[Steve Kargl via Gcc-patches]

On Fri, Mar 03, 2023 at 10:24:07PM +0100, Mikael Morin wrote:
> Hello,
> 
> Le 03/03/2023 à 20:57, Steve Kargl via Fortran a écrit :
> > On Thu, Mar 02, 2023 at 11:03:48PM +0100, Harald Anlauf via Fortran wrote:
> > > -  if (attr->class_ok)
> > > -/* Class container has already been built.  */
> > > +  /* Class container has already been built with same name.  */
> > > +  if (attr->class_ok
> > > +  && ts->u.derived->components->attr.dimension >= attr->dimension
> > > +  && ts->u.derived->components->attr.codimension >= attr->codimension
> > > +  && ts->u.derived->components->attr.class_pointer >= attr->pointer
> > > +  && ts->u.derived->components->attr.allocatable >= 
> > > attr->allocatable)
> > 
> > I suppose I'm a bit confused here.  dimension, codimension,
> > pointer and allocatable are 1-bit bitfields in the attr
> > struct.  These can have the values 0 and 1, so the above
> > conditionals are always true.
> > 
> as I understand it, they aren't if attr has attributes that aren't already
> set in the class container's first component.
> a >= b == !(a < b) and if a and b are boolean-valued, a < b == !a && b.
> Admittedly, I haven't tested the logic like Harald has.
> 

Mikael, thanks for smacking me with the clue stick.  I had to do a quick
test to see the trees.

% cc -o z a.c && ./z
a.i = 0,  b.i = 0, a.i >= b.i = 1
a.i = 1,  b.i = 0, a.i >= b.i = 1
a.i = 1,  b.i = 1, a.i >= b.i = 1
a.i = 0,  b.i = 1, a.i >= b.i = 0

I was overlooking the last case.  So, the above is an all
or nothing test.

-- 
steve

Re: [PATCH 2/2] Rework 128-bit complex multiply and divide.

[Segher Boessenkool]

Hi!

On Fri, Feb 03, 2023 at 12:53:05AM -0500, Michael Meissner wrote:
> This patch reworks how the complex multiply and divide built-in functions are
> done.

> I tested all 3 patchs for PR target/107299 on:

Is this part of the proposed commit message?  As Ke Wen pointed out, it
is wrong.  Most of your mail does not belong in a commit message at all,
but some probably does?  Please do this clearer with future patches.

>   * config/rs6000/rs6000.cc (create_complex_muldiv): Delete.
>   (init_float128_ieee): Delete code to switch complex multiply and divide
>   for long double.

I like this kind of patch :-)

> +/* Internal function to return the built-in function id for the complex
> +   multiply operation for a given mode.  */
> +
> +static inline built_in_function
> +complex_multiply_builtin_code (machine_mode mode)
> +{
> +  return (built_in_function) (BUILT_IN_COMPLEX_MUL_MIN + mode
> +   - MIN_MODE_COMPLEX_FLOAT);
> +}

There should be an assert that the mode is as expected
  gcc_assert (IN_RANGE (mode, MIN_MODE_COMPLEX_FLOAT, MAX_MODE_COMPLEX_FLOAT));
or such.

Using more temporaries should make this simpler as well, obviate the
need for explicit casts, and make everything fit on short lines.

> +static inline built_in_function
> +complex_divide_builtin_code (machine_mode mode)
> +{
> +  return (built_in_function) (BUILT_IN_COMPLEX_DIV_MIN + mode
> +   - MIN_MODE_COMPLEX_FLOAT);
> +}

Ditto ofc.

> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/powerpc/divic3-1.c
> @@ -0,0 +1,18 @@
> +/* { dg-do compile { target { powerpc*-*-* } } } */

Leave the target clause out.

> +/* { dg-require-effective-target powerpc_p8vector_ok } */
> +/* { dg-require-effective-target longdouble128 } */
> +/* { dg-require-effective-target ppc_float128_sw } */
> +/* { dg-options "-O2 -mpower8-vector -mabi=ieeelongdouble -Wno-psabi" } */

It would be nice if you did not try to add -mpower8-vector in more
testcases :-(

Is -Wno-psabi needed here?  What is the error you get without it / on
which configurations?  Cargo-culting hiding the warnings makes you see
fewer warnings, but that is the opposite of a good idea.

> +/* { dg-final { scan-assembler "bl __divtc3" } } */

This name depends on what object format and ABI is in use (some have an
extra leading underscore, or a dot, or whatever).


Segher

Re: [PATCH] Fortran: fix CLASS attribute handling [PR106856]

[Mikael Morin]

Hello,

Le 03/03/2023 à 20:57, Steve Kargl via Fortran a écrit :

On Thu, Mar 02, 2023 at 11:03:48PM +0100, Harald Anlauf via Fortran wrote:

-  if (attr->class_ok)
-/* Class container has already been built.  */
+  /* Class container has already been built with same name.  */
+  if (attr->class_ok
+  && ts->u.derived->components->attr.dimension >= attr->dimension
+  && ts->u.derived->components->attr.codimension >= attr->codimension
+  && ts->u.derived->components->attr.class_pointer >= attr->pointer
+  && ts->u.derived->components->attr.allocatable >= attr->allocatable)


I suppose I'm a bit confused here.  dimension, codimension,
pointer and allocatable are 1-bit bitfields in the attr
struct.  These can have the values 0 and 1, so the above
conditionals are always true.

as I understand it, they aren't if attr has attributes that aren't 
already set in the class container's first component.

a >= b == !(a < b) and if a and b are boolean-valued, a < b == !a && b.
Admittedly, I haven't tested the logic like Harald has.


The rest of the patch looks reasonable.  If Tobias has no
objections or comments, it's ok to commit once the above
is explained.



I have two comments, one about the handling of as and sym->as, which I 
quite don't understand, but I haven't had time to write something about it.

The other is about this:

+  else if (sym->ts.type == BT_CLASS
+  && sym->ts.u.derived->attr.is_class
+  && sym->old_symbol && sym->old_symbol->as == CLASS_DATA (sym)->as)
+sym->old_symbol->as = NULL;
Can this be avoided?  The management of symbol versions should not need 
any manual change.  In principle, either the modified symbols are 
committed, or (in case of error) the previous symbols are restored, but 
there shouldn't be any need for restoring a modified previous symbol.


I guess it's a matter of memory management, because 
gfc_build_class_symbol copies the AS pointer to the class descriptor, 
but I think using gfc_copy_array_spec there or adding the condition 
above to free_old_symbol would be preferable.

Re: [PATCH] Fortran: fix CLASS attribute handling [PR106856]

[Harald Anlauf via Gcc-patches]

Hi Steve,

Am 03.03.23 um 20:57 schrieb Steve Kargl via Gcc-patches:

On Thu, Mar 02, 2023 at 11:03:48PM +0100, Harald Anlauf via Fortran wrote:

-  if (attr->class_ok)
-/* Class container has already been built.  */
+  /* Class container has already been built with same name.  */
+  if (attr->class_ok
+  && ts->u.derived->components->attr.dimension >= attr->dimension
+  && ts->u.derived->components->attr.codimension >= attr->codimension
+  && ts->u.derived->components->attr.class_pointer >= attr->pointer
+  && ts->u.derived->components->attr.allocatable >= attr->allocatable)


I suppose I'm a bit confused here.  dimension, codimension,
pointer and allocatable are 1-bit bitfields in the attr
struct.  These can have the values 0 and 1, so the above
conditionals are always true.


thanks for looking into it.

The above part is from the original draft.  I thought I could
generate testcases that allow to exercise this part, and found
a new case that is not covered by the patch and still ICEs:

subroutine bar (x)
  class(*):: x
  dimension   :: x(:)
  allocatable :: x
end

:-(

We'll need to revisit the logic...


The rest of the patch looks reasonable.  If Tobias has no
objections or comments, it's ok to commit once the above
is explained.



Thanks,
Harald

Re: [PATCH 1/2] PR target/107299: Fix build issue when long double is IEEE 128-bit

[Segher Boessenkool]

Hi!

On Fri, Feb 03, 2023 at 12:49:12AM -0500, Michael Meissner wrote:
> This patch updates the IEEE 128-bit types used in libgcc.
> 
> At the moment, we cannot build GCC when the target uses IEEE 128-bit long
> doubles, such as building the compiler for a native Fedora 36 system.  The
> build dies when it is trying to build the _mulkc3.c and _divkc3 modules.
> 
> This patch changes libgcc to use long double for the IEEE 128-bit base type if
> long double is IEEE 128-bit, and it uses _Float128 otherwise.  The built-in
> functions are adjusted to be the correct version based on the IEEE 128-bit 
> base
> type used.

Please make it much clearer (in the code as well as in the commit
message) that this is a workaround for problems elsewhere.  It
complicates already complicated things that should not be all that
complex in the first place :-(

It is not clear to me that this is good to have at all -- it causes new
non-trivial problems after all -- but you say it allows people to at
least bootstrap, in more cases than before.

So with comments like I said above: okay for trunk.  And not okay for
any backports.

Thanks,


Segher

Re: [libstdc++] Use __gthread_join in jthread/95989

[Alexandre Oliva via Gcc-patches]

On Mar  3, 2023, Alexandre Oliva  wrote:

> Hello, Florian,
> On Mar  3, 2023, Florian Weimer  wrote:

>> * Alexandre Oliva via Gcc-patches:
>>> +// Make sure it's not optimized out, not even with LTO.
>>> +asm ("" : : "rm" (depend));

>> If the m constraint is used, this may never emit the symbol name and
>> thus not create a reference after all.

> But that is no longer the pthread symbol itself, it's the symbol of a
> static member function with vague linkage that, because the compiler
> believes the asm statement will reference it, will still be output, and
> it's that function body that will refer to and thus pull in the symbols
> we need.

> Now, hmm, maybe with per-function sections, the compiler will emit it,
> but with section gc, the linker may drop it, so we might lose the needed
> function body.  When performing LTO with an LTO-enabled libstdc++.

Wait, no, you had me going but it's really fine.  What would be in
memory is a *pointer* to the function, so the function would still be
referenced by whatever initialized the pointer, so it wouldn't get GCed.

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

Re: [libstdc++] Use __gthread_join in jthread/95989

[Alexandre Oliva via Gcc-patches]

Hello, Florian,

On Mar  3, 2023, Florian Weimer  wrote:

> * Alexandre Oliva via Gcc-patches:
>> +// Make sure it's not optimized out, not even with LTO.
>> +asm ("" : : "rm" (depend));

> If the m constraint is used, this may never emit the symbol name and
> thus not create a reference after all.

But that is no longer the pthread symbol itself, it's the symbol of a
static member function with vague linkage that, because the compiler
believes the asm statement will reference it, will still be output, and
it's that function body that will refer to and thus pull in the symbols
we need.

Now, hmm, maybe with per-function sections, the compiler will emit it,
but with section gc, the linker may drop it, so we might lose the needed
function body.  When performing LTO with an LTO-enabled libstdc++.

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

Re: [libstdc++] Use __gthread_join in jthread/95989

[Florian Weimer]

* Alexandre Oliva via Gcc-patches:

> +// Make sure it's not optimized out, not even with LTO.
> +asm ("" : : "rm" (depend));

If the m constraint is used, this may never emit the symbol name and
thus not create a reference after all.

Re: [PATCH] libstdc++: testsuite: async.cc early timeout

[Alexandre Oliva via Gcc-patches]

On Feb  3, 2023, Jonathan Wakely  wrote:

> This one slipped through the cracks, sorry.

Oh, nice, thanks, I'd missed the review too, for a whole month :-)

I've just found the unread message.  I'll have a happier weekend.  I did
not even recall this patch was still pending, and this very test was the
one remaining issue for which I got occasional fails on
arm-vx7r2/gcc-12, and I still hadn't started looking into it.

We may still have other fails in this test (we used to have two
different fail modes in async.cc, the other is probably yet to be
upstreamed, but it was just an xfail), but this is progress :-)

> The patch is OK for trunk now (and should still apply cleanly).

Thanks, I'm checking it in now.

>> for  libstdc++-v3/ChangeLog
>> 
>> * testsuite/30_threads/async/async.cc (test04): Initialize
>> steady_start, renamed from steady_begin, next to slow_start.
>> Increase tolerance for final wait.

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

Re: [PATCH] Fortran: fix CLASS attribute handling [PR106856]

[Steve Kargl via Gcc-patches]

On Thu, Mar 02, 2023 at 11:03:48PM +0100, Harald Anlauf via Fortran wrote:
> -  if (attr->class_ok)
> -/* Class container has already been built.  */
> +  /* Class container has already been built with same name.  */
> +  if (attr->class_ok
> +  && ts->u.derived->components->attr.dimension >= attr->dimension
> +  && ts->u.derived->components->attr.codimension >= attr->codimension
> +  && ts->u.derived->components->attr.class_pointer >= attr->pointer
> +  && ts->u.derived->components->attr.allocatable >= attr->allocatable)

I suppose I'm a bit confused here.  dimension, codimension, 
pointer and allocatable are 1-bit bitfields in the attr
struct.  These can have the values 0 and 1, so the above
conditionals are always true.

The rest of the patch looks reasonable.  If Tobias has no 
objections or comments, it's ok to commit once the above
is explained.

-- 
Steve

Re: [libstdc++] Use __gthread_join in jthread/95989

[Alexandre Oliva via Gcc-patches]

On Mar  3, 2023, Jonathan Wakely  wrote:

> On Fri, 3 Mar 2023 at 18:12, Jonathan Wakely  wrote:

>> And those expressions aren't ever optimized away as unused?

> Oh, I missed that they're called after casting them

*nod*

> That would be UB to call them through the wrong pointer type, so the
> compiler could decide they're unreachable

Ugh, indeed.  We can drop the cast and add the required parameters if it
ever becomes an issue.  Here's what I've just installed.


link pthread_join from std::thread ctor

Like pthread_create, pthread_join may fail to be statically linked in
absent strong uses, so add to user code strong references to both when
std::thread objects are created.


for  libstdc++-v3/ChangeLog

PR libstdc++/104852
PR libstdc++/95989
PR libstdc++/52590
* include/bits/std_thread.h (thread::_M_thread_deps): New
static implicitly-inline member function.
(std::thread template ctor): Pass it to _M_start_thread.
* src/c++11/thread.cc (thread::_M_start_thread): Name depend
parameter, force it live on entry.
---
 libstdc++-v3/include/bits/std_thread.h |   24 +---
 libstdc++-v3/src/c++11/thread.cc   |   10 --
 2 files changed, 25 insertions(+), 9 deletions(-)

diff --git a/libstdc++-v3/include/bits/std_thread.h 
b/libstdc++-v3/include/bits/std_thread.h
index adbd3928ff783..e88c07fbd4f0f 100644
--- a/libstdc++-v3/include/bits/std_thread.h
+++ b/libstdc++-v3/include/bits/std_thread.h
@@ -132,6 +132,22 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 thread() noexcept = default;
 
 #ifdef _GLIBCXX_HAS_GTHREADS
+  private:
+// This adds to user code that creates std:thread objects (because
+// it is called by the template ctor below) strong references to
+// pthread_create and pthread_join, which ensures they are both
+// linked in even during static linking.  We can't depend on
+// gthread calls to bring them in, because those may use weak
+// references.
+static void
+_M_thread_deps_never_run() {
+#ifdef GTHR_ACTIVE_PROXY
+  reinterpret_cast(_create)();
+  reinterpret_cast(_join)();
+#endif
+}
+
+  public:
 template>>
   explicit
@@ -142,18 +158,12 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
  "std::thread arguments must be invocable after conversion to rvalues"
  );
 
-#ifdef GTHR_ACTIVE_PROXY
-   // Create a reference to pthread_create, not just the gthr weak symbol.
-   auto __depend = reinterpret_cast(_create);
-#else
-   auto __depend = nullptr;
-#endif
using _Wrapper = _Call_wrapper<_Callable, _Args...>;
// Create a call wrapper with DECAY_COPY(__f) as its target object
// and DECAY_COPY(__args)... as its bound argument entities.
_M_start_thread(_State_ptr(new _State_impl<_Wrapper>(
  std::forward<_Callable>(__f), std::forward<_Args>(__args)...)),
-   __depend);
+   _M_thread_deps_never_run);
   }
 #endif // _GLIBCXX_HAS_GTHREADS
 
diff --git a/libstdc++-v3/src/c++11/thread.cc b/libstdc++-v3/src/c++11/thread.cc
index 2d5ffaf678e97..c91f7b02e1f3f 100644
--- a/libstdc++-v3/src/c++11/thread.cc
+++ b/libstdc++-v3/src/c++11/thread.cc
@@ -154,8 +154,11 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   }
 
   void
-  thread::_M_start_thread(_State_ptr state, void (*)())
+  thread::_M_start_thread(_State_ptr state, void (*depend)())
   {
+// Make sure it's not optimized out, not even with LTO.
+asm ("" : : "rm" (depend));
+
 if (!__gthread_active_p())
   {
 #if __cpp_exceptions
@@ -190,8 +193,11 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   }
 
   void
-  thread::_M_start_thread(__shared_base_type __b, void (*)())
+  thread::_M_start_thread(__shared_base_type __b, void (*depend)())
   {
+// Make sure it's not optimized out, not even with LTO.
+asm ("" : : "rm" (depend));
+
 auto ptr = __b.get();
 // Create a reference cycle that will be broken in the new thread.
 ptr->_M_this_ptr = std::move(__b);


-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

[committed] d: Document that TypeInfo-based va_arg is not implemented [PR108763]

[Iain Buclaw via Gcc-patches]

Hi,

GDC's run-time library doesn't implement the RTTI-based overload of
va_arg, document it on the missing features page.

Bootstrapped and regression tested, committed to mainline.

Regards,
Iain.

---
PR d/108763

gcc/d/ChangeLog:

* implement-d.texi (Missing Features): Document that TypeInfo-based
va_arg is not implemented.
---
 gcc/d/implement-d.texi | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/gcc/d/implement-d.texi b/gcc/d/implement-d.texi
index 89a17916a83..039e5fbd24e 100644
--- a/gcc/d/implement-d.texi
+++ b/gcc/d/implement-d.texi
@@ -2511,4 +2511,10 @@ version (GNU)
 @}
 @end smallexample
 
+@item TypeInfo-based va_arg
+The Digital Mars D compiler implements a version of @code{core.vararg.va_arg}
+that accepts a run-time @code{TypeInfo} argument for use when the static type
+is not known.  This function is not implemented by GNU D.  It is more portable
+to use variadic template functions instead.
+
 @end table
-- 
2.37.2

Re: [PATCH] cygwin: Don't try to support multilibs [PR107998]

[Jakub Jelinek via Gcc-patches]

On Wed, Feb 22, 2023 at 01:02:58PM +, Jonathan Yong wrote:
> On 2/22/23 09:25, Jakub Jelinek wrote:
> > As discussed in the PR, t-cygwin-w64 file has been introduced in 2013
> > and has one important problem, two different multilib options -m64 and -m32,
> > but MULTILIB_DIRNAMES with just one word in it.
> > Before the genmultilib sanity checking was added, my understanding is that
> > this essentially resulted in effective --disable-multilib,
> > $ gcc -print-multi-lib
> > .;
> > ;@m32
> > $ gcc -print-multi-directory
> > .
> > $ gcc -print-multi-directory -m64
> > .
> > $ gcc -print-multi-directory -m32
> > 
> > $ gcc -print-multi-os-directory
> > ../lib
> > $ gcc -print-multi-os-directory -m64
> > ../lib
> > $ gcc -print-multi-os-directory -m32
> > ../lib32
> > and because of the way e.g. config-ml.in operates
> > multidirs=
> > for i in `${CC-gcc} --print-multi-lib 2>/dev/null`; do
> >dir=`echo $i | sed -e 's/;.*$//'`
> >if [ "${dir}" = "." ]; then
> >  true
> >else
> >  if [ -z "${multidirs}" ]; then
> >multidirs="${dir}"
> >  else
> >multidirs="${multidirs} ${dir}"
> >  fi
> >fi
> > done
> > dir was . first time (and so nothing was done) and empty
> > second time, multidirs empty too, so multidirs was set to empty
> > like it would be with --disable-multilib.
> > 
> > With the added sanity checking the build fails unless --disable-multilib
> > is used in configure (dunno whether people usually configure that way
> > on cygwin).
> > 
> > > From what has been said in the PR, multilibs were not meant to be 
> > > supported
> > and e.g. cygwin headers probably aren't ready for it.
> > 
> > So the following patch just removes the file with the (incorrect) multilib
> > stuff instead of fixing it (say by setting MULTILIB_DIRNAMES to 64 32).
> > 
> > I have no way to test this though, no Windows around, can anyone please
> > test this?  I just would like to get some progress on the P1s we have...
> > 
> > 2023-02-22  Jakub Jelinek  
> > 
> > PR target/107998
> > * config.gcc (x86_64-*-cygwin*): Don't add i386/t-cygwin-w64 into
> > $tmake_file.
> > * config/i386/t-cygwin-w64: Remove.
> > 
> > --- gcc/config.gcc.jj   2023-02-18 12:38:30.803025062 +0100
> > +++ gcc/config.gcc  2023-02-21 17:07:12.143164563 +0100
> > @@ -2105,7 +2105,7 @@ x86_64-*-cygwin*)
> > need_64bit_isa=yes
> > tm_file="${tm_file} i386/unix.h i386/bsd.h i386/gas.h i386/cygming.h 
> > i386/cygwin.h i386/cygwin-w64.h i386/cygwin-stdint.h"
> > xm_file=i386/xm-cygwin.h
> > -   tmake_file="${tmake_file} i386/t-cygming t-slibgcc i386/t-cygwin-w64"
> > +   tmake_file="${tmake_file} i386/t-cygming t-slibgcc"
> > target_gtfiles="$target_gtfiles \$(srcdir)/config/i386/winnt.cc"
> > extra_options="${extra_options} i386/cygming.opt i386/cygwin.opt"
> > extra_objs="${extra_objs} winnt.o winnt-stubs.o"
> > --- gcc/config/i386/t-cygwin-w64.jj 2020-01-12 11:54:36.333414616 +0100
> > +++ gcc/config/i386/t-cygwin-w642023-02-21 17:06:44.121572616 +0100
> > @@ -1,3 +0,0 @@
> > -MULTILIB_OPTIONS = m64/m32
> > -MULTILIB_DIRNAMES = 64
> > -MULTILIB_OSDIRNAMES = ../lib ../lib32
> 
> Achim, mind looking at this?
> Resending due to mail client problems, hopefully not a duplicate.

NightStrike on IRC said he has tested the patch and it worked fine.

Is the patch ok for trunk then?

Jakub

Re: [PATCHv4] [AARCH64] Fix PR target/103100 -mstrict-align and memset on not aligned buffers

[Andrew Pinski via Gcc-patches]

On Thu, Feb 9, 2023 at 7:54 PM Andrew Pinski via Gcc-patches
 wrote:
>
> The problem here is that aarch64_expand_setmem does not change the alignment
> for strict alignment case.
> This is version 4 of the fix, major changes from the last version is fixing
> the way store pairs are handled which allows handling of storing 2 SI mode
> at a time.
> This also adds a testcase to show a case with -mstrict-align we can do
> the store word pair stores.
>
> OK? Bootstrapped and tested on aarch64-linux-gnu with no regressions.

Ping?

>
> PR target/103100
>
> gcc/ChangeLog:
>
> * config/aarch64/aarch64.cc (aarch64_gen_store_pair):
> Add support for SImode.
> (aarch64_set_one_block_and_progress_pointer):
> Add use_pair argument and rewrite and simplifying the
> code.
> (aarch64_can_use_pair_load_stores): New function.
> (aarch64_expand_setmem): Rewrite mode selection to
> better handle strict alignment and non ld/stp pair case.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/aarch64/memset-strict-align-1.c: Update test.
> Reduce the size down to 207 and make s1 global and aligned
> to 16 bytes.
> * gcc.target/aarch64/memset-strict-align-2.c: New test.
> * gcc.target/aarch64/memset-strict-align-3.c: New test.
> ---
>  gcc/config/aarch64/aarch64.cc | 136 ++
>  .../aarch64/memset-strict-align-1.c   |  19 ++-
>  .../aarch64/memset-strict-align-2.c   |  14 ++
>  .../aarch64/memset-strict-align-3.c   |  15 ++
>  4 files changed, 113 insertions(+), 71 deletions(-)
>  create mode 100644 gcc/testsuite/gcc.target/aarch64/memset-strict-align-2.c
>  create mode 100644 gcc/testsuite/gcc.target/aarch64/memset-strict-align-3.c
>
> diff --git a/gcc/config/aarch64/aarch64.cc b/gcc/config/aarch64/aarch64.cc
> index 5c40b6ed22a..3eaf9bd608a 100644
> --- a/gcc/config/aarch64/aarch64.cc
> +++ b/gcc/config/aarch64/aarch64.cc
> @@ -8850,6 +8850,9 @@ aarch64_gen_store_pair (machine_mode mode, rtx mem1, 
> rtx reg1, rtx mem2,
>  {
>switch (mode)
>  {
> +case E_SImode:
> +  return gen_store_pair_sw_sisi (mem1, reg1, mem2, reg2);
> +
>  case E_DImode:
>return gen_store_pair_dw_didi (mem1, reg1, mem2, reg2);
>
> @@ -24896,42 +24899,49 @@ aarch64_expand_cpymem (rtx *operands)
> SRC is a register we have created with the duplicated value to be set.  */
>  static void
>  aarch64_set_one_block_and_progress_pointer (rtx src, rtx *dst,
> -   machine_mode mode)
> +   machine_mode mode, bool use_pairs)
>  {
> +  rtx reg = src;
>/* If we are copying 128bits or 256bits, we can do that straight from
>   the SIMD register we prepared.  */
> -  if (known_eq (GET_MODE_BITSIZE (mode), 256))
> -{
> -  mode = GET_MODE (src);
> -  /* "Cast" the *dst to the correct mode.  */
> -  *dst = adjust_address (*dst, mode, 0);
> -  /* Emit the memset.  */
> -  emit_insn (aarch64_gen_store_pair (mode, *dst, src,
> -aarch64_progress_pointer (*dst), 
> src));
> -
> -  /* Move the pointers forward.  */
> -  *dst = aarch64_move_pointer (*dst, 32);
> -  return;
> -}
>if (known_eq (GET_MODE_BITSIZE (mode), 128))
> -{
> -  /* "Cast" the *dst to the correct mode.  */
> -  *dst = adjust_address (*dst, GET_MODE (src), 0);
> -  /* Emit the memset.  */
> -  emit_move_insn (*dst, src);
> -  /* Move the pointers forward.  */
> -  *dst = aarch64_move_pointer (*dst, 16);
> -  return;
> -}
> -  /* For copying less, we have to extract the right amount from src.  */
> -  rtx reg = lowpart_subreg (mode, src, GET_MODE (src));
> +mode = GET_MODE(src);
> +  else
> +/* For copying less, we have to extract the right amount from src.  */
> +reg = lowpart_subreg (mode, src, GET_MODE (src));
>
>/* "Cast" the *dst to the correct mode.  */
>*dst = adjust_address (*dst, mode, 0);
>/* Emit the memset.  */
> -  emit_move_insn (*dst, reg);
> +  if (use_pairs)
> +emit_insn (aarch64_gen_store_pair (mode, *dst, reg,
> +  aarch64_progress_pointer (*dst),
> +  reg));
> +  else
> +emit_move_insn (*dst, reg);
> +
>/* Move the pointer forward.  */
>*dst = aarch64_progress_pointer (*dst);
> +  if (use_pairs)
> +*dst = aarch64_progress_pointer (*dst);
> +}
> +
> +/* Returns true if size can be used as a store/load pair.
> +   This is a helper function for aarch64_expand_setmem and others. */
> +static bool
> +aarch64_can_use_pair_load_stores (unsigned HOST_WIDE_INT size)
> +{
> +  /* For DI and SI modes, we can use store pairs.  */
> +  if (size == GET_MODE_BITSIZE (DImode)
> +  || size == GET_MODE_BITSIZE (SImode))
> +return true;
> +  /* For TI mode, we will use store pairs only if
> + 

Re: [libstdc++] Use __gthread_join in jthread/95989

[Jonathan Wakely via Gcc-patches]

On Fri, 3 Mar 2023 at 18:12, Jonathan Wakely  wrote:

>
>
> On Fri, 3 Mar 2023 at 17:47, Alexandre Oliva  wrote:
>
>> On Mar  3, 2023, Jonathan Wakely  wrote:
>>
>> > On Fri, 3 Mar 2023 at 09:33, Jonathan Wakely 
>> wrote:
>> >> Jakub previously suggested doing this for PR 61841, which was a similar
>> >> problem with pthread_create:
>> >>
>> >> __asm ("" : : "r" (_create)); would not be optimized away.
>> >>
>> >>
>> >> That would avoid the multiple copies.
>>
>> Not really.  There would be multiple copies of the code that loads
>> pthread_create's address.  And we don't really need the address, a
>> single never-executed call would do.  I've explored these possibilities
>> a bit, and here's what I've come up with: a private static member
>> function that we output in units that instantiate the thread template
>> ctor, to pass its address to _M_start_thread.  Since it's never actually
>> called, we don't really need the hacks in some of the alternatives I
>> left in place, mainly for your enjoyment.
>>
>> They all work equally well, just as efficient per-instantiation at
>> runtime, a little different space and loading overheads, but the last
>> one, that is enabled, is my favorite: only PLT relocations, that we'd
>> likely get anyway, no full-address resolution, and as-short-as-possible
>> calls, enough to get a relocation with a strong reference to pull the
>> symbol in when linking, but as short as possible call sequences, because
>> of the type cast.
>>
>
> And those expressions aren't ever optimized away as unused?
>

Oh, I missed that they're called after casting them, I didn't notice the
trailing ().

That would be UB to call them through the wrong pointer type, so the
compiler could decide they're unreachable, but it seems to work for now.

Thanks!

Re: [libstdc++] Use __gthread_join in jthread/95989

[Jonathan Wakely via Gcc-patches]

On Fri, 3 Mar 2023 at 17:47, Alexandre Oliva  wrote:

> On Mar  3, 2023, Jonathan Wakely  wrote:
>
> > On Fri, 3 Mar 2023 at 09:33, Jonathan Wakely  wrote:
> >> Jakub previously suggested doing this for PR 61841, which was a similar
> >> problem with pthread_create:
> >>
> >> __asm ("" : : "r" (_create)); would not be optimized away.
> >>
> >>
> >> That would avoid the multiple copies.
>
> Not really.  There would be multiple copies of the code that loads
> pthread_create's address.  And we don't really need the address, a
> single never-executed call would do.  I've explored these possibilities
> a bit, and here's what I've come up with: a private static member
> function that we output in units that instantiate the thread template
> ctor, to pass its address to _M_start_thread.  Since it's never actually
> called, we don't really need the hacks in some of the alternatives I
> left in place, mainly for your enjoyment.
>
> They all work equally well, just as efficient per-instantiation at
> runtime, a little different space and loading overheads, but the last
> one, that is enabled, is my favorite: only PLT relocations, that we'd
> likely get anyway, no full-address resolution, and as-short-as-possible
> calls, enough to get a relocation with a strong reference to pull the
> symbol in when linking, but as short as possible call sequences, because
> of the type cast.
>

And those expressions aren't ever optimized away as unused?


>
> As a bonus, I put in (in the last minute, after my test runs) something
> to keep even LTO happy: the asm statements to prevent depend from being
> optimized out in _M_start_thread.  In non-LTO, its impact should be
> virtually zero.
>
> How does this look?  (minus the #if 0/#elif 0/.../#else)
>

Looks good, thanks for going the extra mile to check all the alternatives,
and the futureproofing it for LTO.

OK for trunk.

Re: [PATCH] gcc: Fix gdbhooks.py VecPrinter for vec<> as well as vec<>* [PR109006]

[Jakub Jelinek via Gcc-patches]

On Fri, Mar 03, 2023 at 06:07:48PM +, Jonathan Wakely via Gcc-patches wrote:
> This fixes Jakub's second testcase. The printer needs to do slightly
> different things depending on whether the gdbval obejct is a vec or a
> pointer to a vec.
> 
> OK for trunk?
> 
> -- >8 --
> 
> gcc/ChangeLog:
> 
>   PR middle-end/109006
>   * gdbhooks.py (VecPrinter): Handle vec as well as vec*.

Yes, thanks.

Jakub

Re: [PATCH] [libstdc++] [prettyprint] add local std::string use to more tests

[Jonathan Wakely via Gcc-patches]

On Fri, 3 Mar 2023 at 17:50, Alexandre Oliva via Libstdc++ <
libstd...@gcc.gnu.org> wrote:

>
> We're getting regressions after ugprading to GDB 13 in a few of the
> libstdc++ pretty-printing tests.  It might seem like a GDB regression,
> but that update has a new symbol reader, and Tom Tromey says it
> exposes a latent problem in the pretty-printer, namely, when a name is
> not defined locally in the local translation unit, GDB will look for
> it in other units, and if multiple different definitions are
> available, there are no guarantees as to which one it will find.
>
> Since libstdc++ contains units in which std::string maps to different
> types, in order to ensure the tests get the std::string definition we
> expect, we need std::string to be present in the debug information for
> the test itself, as we already do in other tests.
>
> Regstrapped on x86_64-linux-gnu.  Ok to install?
>

OK, thanks.

[PATCH] gcc: Fix gdbhooks.py VecPrinter for vec<> as well as vec<>* [PR109006]

[Jonathan Wakely via Gcc-patches]

This fixes Jakub's second testcase. The printer needs to do slightly
different things depending on whether the gdbval obejct is a vec or a
pointer to a vec.

OK for trunk?

-- >8 --

gcc/ChangeLog:

PR middle-end/109006
* gdbhooks.py (VecPrinter): Handle vec as well as vec*.
---
 gcc/gdbhooks.py | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/gcc/gdbhooks.py b/gcc/gdbhooks.py
index 78e6c97c30d..e29bd458909 100644
--- a/gcc/gdbhooks.py
+++ b/gcc/gdbhooks.py
@@ -461,13 +461,16 @@ class VecPrinter:
 return
 m_vecpfx = self.gdbval['m_vecpfx']
 m_num = m_vecpfx['m_num']
-typ = self.gdbval.type
+val = self.gdbval
+typ = val.type
 if typ.code == gdb.TYPE_CODE_PTR:
 typ = typ.target()
-typ = typ.template_argument(0) # the type T
-m_vecdata = (self.gdbval.address + 1).cast(typ.pointer())
+else:
+val = val.address
+typ_T = typ.template_argument(0) # the type T
+vecdata = (val + 1).cast(typ_T.pointer())
 for i in range(m_num):
-yield ('[%d]' % i, m_vecdata[i])
+yield ('[%d]' % i, vecdata[i])
 
 ##
 
-- 
2.39.2

[PATCH] [rs6000] adjust return_pc debug attrs

[Alexandre Oliva via Gcc-patches]

Some of the rs6000 call patterns, on some ABIs, issue multiple opcodes
out of a single call insn, but the call (bl) or jump (b) is not always
the last opcode in the sequence.

This does not seem to be a problem for exception handling tables, but
the return_pc attribute in the call graph output in dwarf2+ debug
information, that takes the address of a label output right after the
call, does not match the value of the link register even for non-tail
calls.  E.g., with ABI_AIX or ABI_ELFv2, such code as:

  foo ();

outputs:

  bl foo
  nop
 LVL#:
[...]
  .8byte .LVL#  # DW_AT_call_return_pc

but debug info consumers may rely on the return_pc address, and draw
incorrect conclusions from its off-by-4 value.

This patch introduces infrastructure for targets to add an offset to
the label issued after the call_insn to set the call_return_pc
attribute, and uses that on rs6000 to account for nop and l opcodes
issued after actual call opcode as part of call insns output patterns.


for  gcc/ChangeLog

* target.def (call_offset_return_label): New hook.
* gcc/doc/tm.texi.in (TARGET_CALL_OFFSET_RETURN_LABEL): Add
placeholder.
* gcc/doc/tm.texi: Rebuild.
* dwarf2out.cc (struct call_arg_loc_node): Record call_insn
instad of call_arg_loc_note.
(add_AT_lbl_id): Add optional offset argument.
(gen_call_site_die): Compute and pass on a return pc offset.
(gen_subprogram_die): Move call_arg_loc_note computation...
(dwarf2out_var_location): ... from here.  Set call_insn.
* config/rs6000/rs6000.cc (TARGET_CALL_OFFSET_RETURN_LABEL):
Override.
(rs6000_call_offset_return_label): New.
* config/rs6000/rs6000.md (call_needs_return_offset): New
attribute.  Set it on call patterns that may require
offsetting.
---
 gcc/config/rs6000/rs6000.cc |   37 +
 gcc/config/rs6000/rs6000.md |   24 
 gcc/doc/tm.texi |7 +++
 gcc/doc/tm.texi.in  |2 ++
 gcc/dwarf2out.cc|   26 +-
 gcc/target.def  |9 +
 6 files changed, 96 insertions(+), 9 deletions(-)

diff --git a/gcc/config/rs6000/rs6000.cc b/gcc/config/rs6000/rs6000.cc
index 8e0b0d022db2f..edbc7a011886c 100644
--- a/gcc/config/rs6000/rs6000.cc
+++ b/gcc/config/rs6000/rs6000.cc
@@ -1760,6 +1760,9 @@ static const struct attribute_spec 
rs6000_attribute_table[] =
 
 #undef TARGET_UPDATE_IPA_FN_TARGET_INFO
 #define TARGET_UPDATE_IPA_FN_TARGET_INFO rs6000_update_ipa_fn_target_info
+
+#undef TARGET_CALL_OFFSET_RETURN_LABEL
+#define TARGET_CALL_OFFSET_RETURN_LABEL rs6000_call_offset_return_label
 
 
 /* Processor table.  */
@@ -14593,6 +14596,40 @@ rs6000_assemble_integer (rtx x, unsigned int size, int 
aligned_p)
   return default_assemble_integer (x, size, aligned_p);
 }
 
+/* Return the offset to be added to the label output after CALL_INSN
+   to compute the address to be placed in DW_AT_call_return_pc.  Some
+   call insns output nop or l after bl, so the return address would be
+   wrong without this offset.  */
+
+static int
+rs6000_call_offset_return_label (rtx_insn *call_insn)
+{
+  /* We don't expect SEQUENCEs in this port.  */
+  gcc_checking_assert (GET_CODE (call_insn) == CALL_INSN);
+
+  enum attr_call_needs_return_offset cnro
+= get_attr_call_needs_return_offset (call_insn);
+
+  if (cnro == CALL_NEEDS_RETURN_OFFSET_NONE)
+return 0;
+
+  if (rs6000_pcrel_p ())
+return 0;
+  else if (DEFAULT_ABI == ABI_AIX || DEFAULT_ABI == ABI_ELFv2)
+/* rs6000_call_template_1 outputs a nop after non-sibcall insns;
+   we mark sibcall insns with NONE rather than DIRECT, so we
+   should have returned zero above.
+   rs6000_indirect_call_template_1 outputs an l insn after
+   indirect calls in these ABIs.  */
+return -4;
+  else if (DEFAULT_ABI == ABI_V4)
+return 0;
+  else if (DEFAULT_ABI == ABI_DARWIN)
+return 0;
+  else
+return 0;
+}
+
 /* Return a template string for assembly to emit when making an
external call.  FUNOP is the call mem argument operand number.  */
 
diff --git a/gcc/config/rs6000/rs6000.md b/gcc/config/rs6000/rs6000.md
index 81bffb04ceb0c..7dc73b21af731 100644
--- a/gcc/config/rs6000/rs6000.md
+++ b/gcc/config/rs6000/rs6000.md
@@ -342,6 +342,12 @@ (define_attr "max_prefixed_insns" "" (const_int 1))
 ;; num_insns and recurse).
 (define_attr "length" "" (const_int 4))
 
+;; Calls that output insns after bl need DW_AT_call_return_pc to be
+;; adjusted.  rs6000_call_offset_return_label uses this attribute to
+;; conservatively recognize the relevant patterns.
+(define_attr "call_needs_return_offset" "none,direct,indirect"
+  (const_string "none"))
+
 ;; Processor type -- this attribute must exactly match the processor_type
 ;; enumeration in rs6000-opts.h.
 (define_attr "cpu"
@@ -11355,6 +11361,7 @@ (define_insn "*call_indirect_nonlocal_sysv"
   return 

Re: [PATCH] gcc: Adjust gdbhooks.py VecPrinter for vec layout changes

[Jonathan Wakely via Gcc-patches]

On Fri, 3 Mar 2023 at 17:01, Jakub Jelinek  wrote:

> On Fri, Mar 03, 2023 at 05:45:59PM +0100, Jakub Jelinek via Gcc-patches
> wrote:
> > On Fri, Mar 03, 2023 at 04:44:39PM +, Jonathan Wakely via
> Gcc-patches wrote:
> > > OK for trunk?
> > >
> > > gcc/ChangeLog:
> > >
> >
> > Please add
> >   PR middle-end/109006
> > here
> > > * gdbhooks.py (VecPrinter): Adjust for new vec layout.
> >
> > Ok with that, thanks.
>
> Though, trying it on another vector it doesn't work in that case.
> Testcase:
> int
> foo (void)
> {
>   return 1;
> }
> gdb ./cc1 -quiet -O2 test.c
> b pass_reassoc::execute
> r
> p debug_bb_n (2)
> p $1->preds
> (gdb) p $1->preds
> $2 = 0x7fffea2d1f50 = { address 0x10058>}
> (gdb) p $1->succs
> $3 = 0x7fffea3010a0 = {}
>
> But if I try to print it the hard way:
> (gdb) p ((edge_def**)(&$1->preds.m_vecpfx+1))[0]
> $4 =  2)>
> (gdb) p ((edge_def**)(&$1->succs.m_vecpfx+1))[0]
> $5 =  EXIT)>
>

Here's a fix for that testcase:

--- a/gcc/gdbhooks.py
+++ b/gcc/gdbhooks.py
@@ -462,10 +462,13 @@ class VecPrinter:
 m_vecpfx = self.gdbval['m_vecpfx']
 m_num = m_vecpfx['m_num']
 typ = self.gdbval.type
+val = self.gdbval
 if typ.code == gdb.TYPE_CODE_PTR:
 typ = typ.target()
+else:
+val = val.address
 typ = typ.template_argument(0) # the type T
-m_vecdata = (self.gdbval.address + 1).cast(typ.pointer())
+m_vecdata = (val + 1).cast(typ.pointer())
 for i in range(m_num):
 yield ('[%d]' % i, m_vecdata[i])

[PATCH] c++: error with constexpr operator() [PR107939]

[Marek Polacek via Gcc-patches]

Similarly to PR107938, this also started with r11-557, whereby cp_finish_decl
can call check_initializer even in a template for a constexpr initializer.

Here we are rejecting

  extern const Q q;

  template
  constexpr auto p = q(0);

even though q has a constexpr operator().  It's deemed non-const by
decl_maybe_constant_var_p because even though 'q' is const it is not
of integral/enum type.  I think the fix is for p_c_e to treat q(0) as
potentially-constant, as below.

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/12?

PR c++/107939

gcc/cp/ChangeLog:

* constexpr.cc (is_constexpr_function_object): New.
(potential_constant_expression_1): Treat an object with constexpr
operator() as potentially-constant.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1y/var-templ74.C: Remove dg-error.
* g++.dg/cpp1y/var-templ77.C: New test.
---
 gcc/cp/constexpr.cc  | 23 ++-
 gcc/testsuite/g++.dg/cpp1y/var-templ74.C |  2 +-
 gcc/testsuite/g++.dg/cpp1y/var-templ77.C | 14 ++
 3 files changed, 37 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp1y/var-templ77.C

diff --git a/gcc/cp/constexpr.cc b/gcc/cp/constexpr.cc
index acf9847a4d1..7d786f332b4 100644
--- a/gcc/cp/constexpr.cc
+++ b/gcc/cp/constexpr.cc
@@ -8929,6 +8929,24 @@ check_for_return_continue (tree *tp, int *walk_subtrees, 
void *data)
   return NULL_TREE;
 }
 
+/* Return true iff TYPE is a class with constexpr operator().  */
+
+static bool
+is_constexpr_function_object (tree type)
+{
+  if (!CLASS_TYPE_P (type))
+return false;
+
+  for (tree f = TYPE_FIELDS (type); f; f = DECL_CHAIN (f))
+if (TREE_CODE (f) == FUNCTION_DECL
+   && DECL_OVERLOADED_OPERATOR_P (f)
+   && DECL_OVERLOADED_OPERATOR_IS (f, CALL_EXPR)
+   && DECL_DECLARED_CONSTEXPR_P (f))
+  return true;
+
+  return false;
+}
+
 /* Return true if T denotes a potentially constant expression.  Issue
diagnostic as appropriate under control of FLAGS.  If WANT_RVAL is true,
an lvalue-rvalue conversion is implied.  If NOW is true, we want to
@@ -9160,7 +9178,10 @@ potential_constant_expression_1 (tree t, bool want_rval, 
bool strict, bool now,
  }
else if (fun)
   {
-   if (RECUR (fun, rval))
+   if (VAR_P (fun)
+   && is_constexpr_function_object (TREE_TYPE (fun)))
+ /* Could be an object with constexpr operator().  */;
+   else if (RECUR (fun, rval))
  /* Might end up being a constant function pointer.  */;
else
  return false;
diff --git a/gcc/testsuite/g++.dg/cpp1y/var-templ74.C 
b/gcc/testsuite/g++.dg/cpp1y/var-templ74.C
index 4e2e800a6eb..c76a7d949ac 100644
--- a/gcc/testsuite/g++.dg/cpp1y/var-templ74.C
+++ b/gcc/testsuite/g++.dg/cpp1y/var-templ74.C
@@ -9,7 +9,7 @@ struct Q {
 extern const Q q;
 
 template
-constexpr const Q* p = q(0); // { dg-bogus "not usable" "PR107939" { xfail 
*-*-* } }
+constexpr const Q* p = q(0);
 
 void
 g ()
diff --git a/gcc/testsuite/g++.dg/cpp1y/var-templ77.C 
b/gcc/testsuite/g++.dg/cpp1y/var-templ77.C
new file mode 100644
index 000..b480f54b001
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1y/var-templ77.C
@@ -0,0 +1,14 @@
+// PR c++/107939
+// { dg-do compile { target c++14 } }
+
+struct Q {
+  struct P {
+const Q* p;
+  };
+  int n;
+  constexpr P operator()(int) const { return {this}; }
+};
+
+extern const Q q;
+template
+constexpr auto p = q(0);

base-commit: 9056d0df830c5a295d7594d517d409d10476990d
-- 
2.39.2

[PATCH v5] c++: -Wdangling-reference with reference wrapper [PR107532]

[Marek Polacek via Gcc-patches]

On Fri, Mar 03, 2023 at 11:25:06AM -0500, Jason Merrill wrote:
> On 3/2/23 16:24, Marek Polacek wrote:
> > On Wed, Mar 01, 2023 at 04:53:23PM -0500, Jason Merrill wrote:
> > > > @@ -13791,12 +13830,39 @@ std_pair_ref_ref_p (tree t)
> > > > const int& y = (f(1), 42); // NULL_TREE
> > > > const int& z = f(f(1)); // f(f(1))
> > > > -   EXPR is the initializer.  */
> > > > +   EXPR is the initializer.  If ARG_P is true, we're processing an 
> > > > argument
> > > > +   to a function; the point is to distinguish between, for example,
> > > > +
> > > > + Ref::inner (_EXPR )
> > > > +
> > > > +   where we shouldn't warn, and
> > > > +
> > > > + Ref::inner (_EXPR )>)
> > > > +
> > > > +   where we should warn (Ref is a reference_like_class_p so we see 
> > > > through
> > > > +   it.  */
> > > >static tree
> > > > -do_warn_dangling_reference (tree expr)
> > > > +do_warn_dangling_reference (tree expr, bool arg_p)
> > > >{
> > > >  STRIP_NOPS (expr);
> > > > +  if (TREE_CODE (expr) == ADDR_EXPR)
> > > > +expr = TREE_OPERAND (expr, 0);
> > > 
> > > I think if we move this here, we also need to check that expr before
> > > STRIP_NOPS had REFERENCE_TYPE.  OK with that change.
> > 
> > Sorry but I don't think I can do that.  There can be CONVERT_EXPRs
> > that need to be stripped, whether arg_p or !arg_p.  For example, we can get
> > (const int *) f ((const int &) _EXPR >)
> > for
> > const int& r5 = (42, f(10));
> 
> I meant that we only want to strip ADDR_EXPR if 'expr' at the start of the
> function had REFERENCE_TYPE, corresponding to
> 
> > /* Check that this argument initializes a reference, except
> > for
> > the argument initializing the object of a member function.  */
> > if (!DECL_NONSTATIC_MEMBER_FUNCTION_P (fndecl)
> > && !TYPE_REF_P (TREE_TYPE (arg)))
> >   continue;
> 
> above the code for stripping an ADDR_EXPR from an argument that your patch
> removes.

I see.

> If the original expr is a pointer rather than a reference, we don't want to
> complain about it pointing to a temporary.

Ug, I can't make it work.  When we recurse, I can no longer check
fndecl.  How about just moving the stripping back where it was?

-- >8 --
Here, -Wdangling-reference triggers where it probably shouldn't, causing
some grief.  The code in question uses a reference wrapper with a member
function returning a reference to a subobject of a non-temporary object:

  const Plane & meta = fm.planes().inner();

I've tried a few approaches, e.g., checking that the member function's
return type is the same as the type of the enclosing class (which is
the case for member functions returning *this), but that then breaks
Wdangling-reference4.C with std::optional.

This patch adjusts do_warn_dangling_reference so that we look through
reference wrapper classes (meaning, has a reference member and a
constructor taking the same reference type, or is std::reference_wrapper
or std::ranges::ref_view) and don't warn for them, supposing that the
member function returns a reference to a non-temporary object.

PR c++/107532

gcc/cp/ChangeLog:

* call.cc (reference_like_class_p): New.
(do_warn_dangling_reference): Add new bool parameter.  See through
reference_like_class_p.

gcc/testsuite/ChangeLog:

* g++.dg/warn/Wdangling-reference8.C: New test.
* g++.dg/warn/Wdangling-reference9.C: New test.
---
 gcc/cp/call.cc| 92 ---
 .../g++.dg/warn/Wdangling-reference8.C| 77 
 .../g++.dg/warn/Wdangling-reference9.C| 21 +
 3 files changed, 176 insertions(+), 14 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/warn/Wdangling-reference8.C
 create mode 100644 gcc/testsuite/g++.dg/warn/Wdangling-reference9.C

diff --git a/gcc/cp/call.cc b/gcc/cp/call.cc
index 048b2b052f8..62536573633 100644
--- a/gcc/cp/call.cc
+++ b/gcc/cp/call.cc
@@ -13779,6 +13779,45 @@ std_pair_ref_ref_p (tree t)
   return true;
 }
 
+/* Return true if a class CTYPE is either std::reference_wrapper or
+   std::ref_view, or a reference wrapper class.  We consider a class
+   a reference wrapper class if it has a reference member and a
+   constructor taking the same reference type.  */
+
+static bool
+reference_like_class_p (tree ctype)
+{
+  tree tdecl = TYPE_NAME (TYPE_MAIN_VARIANT (ctype));
+  if (decl_in_std_namespace_p (tdecl))
+{
+  tree name = DECL_NAME (tdecl);
+  return (name
+ && (id_equal (name, "reference_wrapper")
+ || id_equal (name, "ref_view")));
+}
+  for (tree fields = TYPE_FIELDS (ctype);
+   fields;
+   fields = DECL_CHAIN (fields))
+{
+  if (TREE_CODE (fields) != FIELD_DECL || DECL_ARTIFICIAL (fields))
+   continue;
+  tree type = TREE_TYPE (fields);
+  if (!TYPE_REF_P (type))
+   continue;
+  /* OK, the field is a reference member.  Do we have a constructor
+

[PATCH] [libstdc++] [prettyprint] add local std::string use to more tests

[Alexandre Oliva via Gcc-patches]

We're getting regressions after ugprading to GDB 13 in a few of the
libstdc++ pretty-printing tests.  It might seem like a GDB regression,
but that update has a new symbol reader, and Tom Tromey says it
exposes a latent problem in the pretty-printer, namely, when a name is
not defined locally in the local translation unit, GDB will look for
it in other units, and if multiple different definitions are
available, there are no guarantees as to which one it will find.

Since libstdc++ contains units in which std::string maps to different
types, in order to ensure the tests get the std::string definition we
expect, we need std::string to be present in the debug information for
the test itself, as we already do in other tests.

Regstrapped on x86_64-linux-gnu.  Ok to install?


for  libstdc++-v3/ChangeLog

* testsuite/libstdc++-pretty-printers/80276.cc: Add
std::string to debug info.
* testsuite/libstdc++-pretty-printers/libfundts.cc: Likewise.


Change-Id: I928617d44679c63d634c26f6db17d7580a9bcd8f
TN: W223-034
---
 .../testsuite/libstdc++-prettyprinters/80276.cc|5 +
 .../libstdc++-prettyprinters/libfundts.cc  |6 ++
 2 files changed, 11 insertions(+)

diff --git a/libstdc++-v3/testsuite/libstdc++-prettyprinters/80276.cc 
b/libstdc++-v3/testsuite/libstdc++-prettyprinters/80276.cc
index db4de593808e3..1d6b0207106a6 100644
--- a/libstdc++-v3/testsuite/libstdc++-prettyprinters/80276.cc
+++ b/libstdc++-v3/testsuite/libstdc++-prettyprinters/80276.cc
@@ -36,6 +36,11 @@ int
 main()
 {
   using namespace std;
+  // Ensure debug info for std::string is issued in the local
+  // translation unit, so that GDB won't pick up any alternate
+  // std::string notion that might be present in libstdc++.so.
+  string bah = "hi";
+  (void)bah;
   unique_ptr*>>> p1;
   unique_ptr*>>[]> p2;
   unique_ptr*>>[10]> p3;
diff --git a/libstdc++-v3/testsuite/libstdc++-prettyprinters/libfundts.cc 
b/libstdc++-v3/testsuite/libstdc++-prettyprinters/libfundts.cc
index b1c91033cc8e6..29e8bc8f194e3 100644
--- a/libstdc++-v3/testsuite/libstdc++-prettyprinters/libfundts.cc
+++ b/libstdc++-v3/testsuite/libstdc++-prettyprinters/libfundts.cc
@@ -32,6 +32,12 @@ using std::experimental::string_view;
 int
 main()
 {
+  // Ensure debug info for std::string is issued in the local
+  // translation unit, so that GDB won't pick up any alternate
+  // std::string notion that might be present in libstdc++.so.
+  std::string bah = "hi";
+  (void)bah;
+
   string_view str = "string";
 // { dg-final { note-test str "\"string\"" } }
 

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

Re: [libstdc++] Use __gthread_join in jthread/95989

[Alexandre Oliva via Gcc-patches]

On Mar  3, 2023, Jonathan Wakely  wrote:

> On Fri, 3 Mar 2023 at 09:33, Jonathan Wakely  wrote:
>> Jakub previously suggested doing this for PR 61841, which was a similar
>> problem with pthread_create:
>> 
>> __asm ("" : : "r" (_create)); would not be optimized away.
>> 
>> 
>> That would avoid the multiple copies.

Not really.  There would be multiple copies of the code that loads
pthread_create's address.  And we don't really need the address, a
single never-executed call would do.  I've explored these possibilities
a bit, and here's what I've come up with: a private static member
function that we output in units that instantiate the thread template
ctor, to pass its address to _M_start_thread.  Since it's never actually
called, we don't really need the hacks in some of the alternatives I
left in place, mainly for your enjoyment.

They all work equally well, just as efficient per-instantiation at
runtime, a little different space and loading overheads, but the last
one, that is enabled, is my favorite: only PLT relocations, that we'd
likely get anyway, no full-address resolution, and as-short-as-possible
calls, enough to get a relocation with a strong reference to pull the
symbol in when linking, but as short as possible call sequences, because
of the type cast.

As a bonus, I put in (in the last minute, after my test runs) something
to keep even LTO happy: the asm statements to prevent depend from being
optimized out in _M_start_thread.  In non-LTO, its impact should be
virtually zero.

How does this look?  (minus the #if 0/#elif 0/.../#else)


link pthread_join from std::thread ctor

Like pthread_create, pthread_join may fail to be statically linked in
absent strong uses, so add to user code strong references to both when
std::thread objects are created.


for  libstdc++-v3/ChangeLog

* include/bits/std_thread.h (thread::_M_thread_deps): New
static inline function.
(std::thread template ctor): Pass it to _M_start_thread.
* src/c++11/thread.cc (thread::_M_start_thread): Name depend
parameter, force it live on entry.
---
 libstdc++-v3/include/bits/std_thread.h |   51 
 libstdc++-v3/src/c++11/thread.cc   |   10 +-
 2 files changed, 52 insertions(+), 9 deletions(-)

diff --git a/libstdc++-v3/include/bits/std_thread.h 
b/libstdc++-v3/include/bits/std_thread.h
index adbd3928ff783..3ffd2a823a698 100644
--- a/libstdc++-v3/include/bits/std_thread.h
+++ b/libstdc++-v3/include/bits/std_thread.h
@@ -132,6 +132,49 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 thread() noexcept = default;
 
 #ifdef _GLIBCXX_HAS_GTHREADS
+  private:
+// This adds to user code that creates std:thread objects (because
+// it is called by the template ctor below) strong references to
+// pthread_create and pthread_join, which ensures they are both
+// linked in even during static linking.  We can't depend on
+// gthread calls to bring them in, because those may use weak
+// references.
+static void
+_M_thread_deps_never_run() {
+#ifdef GTHR_ACTIVE_PROXY
+#if 0
+  static auto const __attribute__ ((__used__)) _M_create = pthread_create;
+  static auto const __attribute__ ((__used__)) _M_join = pthread_join;
+#elif 0
+  pthread_t thr;
+  pthread_create (, nullptr, nullptr, nullptr);
+  pthread_join (thr, nullptr);
+#elif 0
+  asm goto ("" : : : : _M_never_run);
+  if (0)
+   {
+   _M_never_run:
+ pthread_t thr;
+ pthread_create (, nullptr, nullptr, nullptr);
+ pthread_join (thr, nullptr);
+   }
+#elif 0
+  bool _M_skip_always = false;
+  asm ("" : "+rm" (_M_skip_always));
+  if (__builtin_expect (_M_skip_always, false))
+   {
+ pthread_t thr;
+ pthread_create (, nullptr, nullptr, nullptr);
+ pthread_join (thr, nullptr);
+   }
+#else
+  reinterpret_cast(_create)();
+  reinterpret_cast(_join)();
+#endif
+#endif
+}
+
+  public:
 template>>
   explicit
@@ -142,18 +185,12 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
  "std::thread arguments must be invocable after conversion to rvalues"
  );
 
-#ifdef GTHR_ACTIVE_PROXY
-   // Create a reference to pthread_create, not just the gthr weak symbol.
-   auto __depend = reinterpret_cast(_create);
-#else
-   auto __depend = nullptr;
-#endif
using _Wrapper = _Call_wrapper<_Callable, _Args...>;
// Create a call wrapper with DECAY_COPY(__f) as its target object
// and DECAY_COPY(__args)... as its bound argument entities.
_M_start_thread(_State_ptr(new _State_impl<_Wrapper>(
  std::forward<_Callable>(__f), std::forward<_Args>(__args)...)),
-   __depend);
+   _M_thread_deps_never_run);
   }
 #endif // _GLIBCXX_HAS_GTHREADS
 
diff --git a/libstdc++-v3/src/c++11/thread.cc b/libstdc++-v3/src/c++11/thread.cc
index 2d5ffaf678e97..c91f7b02e1f3f 100644
--- a/libstdc++-v3/src/c++11/thread.cc
+++ 

Re: [PATCH] swap: Fix incorrect lane extraction by vec_extract() [PR106770]

[Segher Boessenkool]

Hi!

On Fri, Mar 03, 2023 at 04:29:57PM +0530, Surya Kumari Jangala wrote:
> On 27/02/23 9:58 pm, Segher Boessenkool wrote:
> > On Wed, Jan 04, 2023 at 01:58:19PM +0530, Surya Kumari Jangala wrote:
> >> + register swaps of permuting loads/stores have been removed.  */
> > 
> > If it really means only exactly this, then the name isn't so good.
> 
> There is another bit in this class named "web_not_optimizable". This stands 
> for webs that cannot be optimized. I am reusing this name for the new bit I 
> am adding, and I have named this bit as "web_is_optimized".

"optimizable" and "optimized" are very different things.  Both are not
saying much at all, making this worse :-(

"swaps_can_be_removed" and "swaps_have_been_removed" maybe, or
"swaps_will_be_removed" which is closer to the truth it seems?  The
future tense in that is important.

> >> + Note that special handling should be done only for those 
> >> + swappable insns that are present in webs optimized above.  */
> >> +  for (i = 0; i < e; ++i)
> >> +if (insn_entry[i].is_swappable && insn_entry[i].special_handling &&
> >> +!(insn_entry[i].special_handling == SH_NOSWAP_LD || 
> >> +  insn_entry[i].special_handling == SH_NOSWAP_ST))
> >>{
> >>swap_web_entry* root_entry
> >>  = (swap_web_entry*)((_entry[i])->unionfind_root ());
> >> -  if (!root_entry->web_not_optimizable)
> >> +  if (root_entry->web_is_optimized)
> >>  handle_special_swappables (insn_entry, i);
> >>}
> > 
> > Why this change?
> 
> The swap pass analyzes vector computations and removes unnecessary doubleword 
> swaps (xxswapdi instructions). The swap pass first constructs webs and 
> removes swap instructions if possible. If the web contains operations that 
> are sensitive to element order (ie, insns requiring special handling), such 
> as an extract, then such instructions should be modified. For example, for an 
> extract operation the lane is changed.

[Please limit your line lengths to something reasonable :-)  It is hard
to edit and even read like this.  70 or 72 is a usual max length in
email, allowing a few levels of quoting before wrapping on standard
terminals.]

> However, the swap pass is changing element order of an extract operation that 
> is present in unoptimized webs. Unoptimized webs are those for which register 
> swaps were not removed, one of the reasons being that there are no 
> loads/stores present in this web. For such webs, element order of extract 
> operation should not be changed.
> Hence, we first mark webs that can be optimized, and only for such webs we 
> call the routine handle_special_swappables() to modify operations sensitive 
> to element order.
> One type of insns that are handled by handle_special_swappables() are 
> non-permuting loads/stores. These insns are converted to permuting 
> loads/stores. This conversion is needed because a permuting load/store is 
> converted into a simple load/store during the final assembly code generation. 
> Whereas, non-permuting loads/stores are converted into a load/store and a 
> swap instruction.
> So we first go thru all the webs, and for permuting loads/stores we find the 
> associated register swaps and mark them for removal. And for non-permuting 
> loads/stores, we convert them to permuting loads/stores. All such webs are 
> marked as 'optimized'
> Then we go thru all the webs again, and for those marked 'optimized', we call 
> handle_special_swappables() to handle insns that require special handling.

Hrm.  So something like "optimizable_with_special_handling"?

That is still way more vague than wanted, of course.

Two big issues:

1) The code seems to duplicate a lot of existing code.  Can things be
factored better?  This is very good for maintainability.
2) Related a bit, please create a new function if you need to add a
large amount of code.

Restructuring existing code is fine, that is even needed to keep code in
good shape.  Please do that in a separate patch (typically before the
rest of the series), which makes reviewing it much simpler: one patch
that can even be largish but that really changes nothing, and one
hopefully small one that does the real meat.  The former is easier to
review because there are only two things to consider: is the new
structure good, and does the patch really not change things?  The latter
patch will be much easier to review as well, because it has ultra focus
on the actual new code :-)

Looking forward to what you come up with,


Segher

Re: [PATCH] amdgcn: Add instruction patterns for conditional min/max operations

[Paul-Antoine Arras]

Le 02/03/2023 à 18:18, Andrew Stubbs a écrit :

On 01/03/2023 16:56, Paul-Antoine Arras wrote:

This patch introduces instruction patterns for conditional min and max
operations (cond_{f|s|u}{max|min}) in the GCN machine description. It 
also allows the exec register to be saved in SGPRs to avoid spilling 
to memory.

Tested on GCN3 Fiji gfx803.

OK for trunk?


Not quite yet, but it's only a few cosmetic issues, I think.


+(define_insn_and_split "3"
+  [(set (match_operand:V_DI 0 "register_operand"  "=  v")
+    (minmaxop:V_DI
+  (match_operand:V_DI 1 "gcn_alu_operand" "%  v")
+  (match_operand:V_DI 2 "gcn_alu_operand" "   v")))
+    (clobber (reg:DI VCC_REG))]


No need to make it commutative when the two operands have the same 
constraints. There's a few more instances of this later.



+    if ( == smin ||  == smax)
+  emit_insn (gen_vec_cmpdi (vcc, minp ? gen_rtx_LT 
(VOIDmode, 0, 0) :
+    gen_rtx_GT (VOIDmode, 0, 0), 
operands[1], operands[2]));

+    else
+  emit_insn (gen_vec_cmpdi (vcc, minp ? gen_rtx_LTU 
(VOIDmode, 0, 0) :
+    gen_rtx_GTU (VOIDmode, 0, 0), 
operands[1], operands[2]));

+


Long lines need to be wrapped, here and elsewhere.


The amended patch attached should fix those issues. Let me know if it 
looks good to you.

--
PA
From cdb2d170091d87b0a5968cca49fc34ac434bb54c Mon Sep 17 00:00:00 2001
From: Paul-Antoine Arras 
Date: Wed, 1 Mar 2023 17:20:21 +0100
Subject: [PATCH] amdgcn: Add instruction patterns for conditional min/max
 operations

gcc/ChangeLog:

	* config/gcn/gcn-valu.md (3_exec): Add patterns for
	{s|u}{max|min} in QI, HI and DI modes.
	(3): Add pattern for {s|u}{max|min} in DI mode.
	(cond_): Add pattern for cond_f{max|min}.
	(cond_): Add pattern for cond_{s|u}{max|min}.
	* config/gcn/gcn.cc (gcn_spill_class): Allow the exec register to be
	saved in SGPRs.

gcc/testsuite/ChangeLog:

	* gcc.target/gcn/cond_fmaxnm_1.c: New test.
	* gcc.target/gcn/cond_fmaxnm_1_run.c: New test.
	* gcc.target/gcn/cond_fmaxnm_2.c: New test.
	* gcc.target/gcn/cond_fmaxnm_2_run.c: New test.
	* gcc.target/gcn/cond_fmaxnm_3.c: New test.
	* gcc.target/gcn/cond_fmaxnm_3_run.c: New test.
	* gcc.target/gcn/cond_fmaxnm_4.c: New test.
	* gcc.target/gcn/cond_fmaxnm_4_run.c: New test.
	* gcc.target/gcn/cond_fmaxnm_5.c: New test.
	* gcc.target/gcn/cond_fmaxnm_5_run.c: New test.
	* gcc.target/gcn/cond_fmaxnm_6.c: New test.
	* gcc.target/gcn/cond_fmaxnm_6_run.c: New test.
	* gcc.target/gcn/cond_fmaxnm_7.c: New test.
	* gcc.target/gcn/cond_fmaxnm_7_run.c: New test.
	* gcc.target/gcn/cond_fmaxnm_8.c: New test.
	* gcc.target/gcn/cond_fmaxnm_8_run.c: New test.
	* gcc.target/gcn/cond_fminnm_1.c: New test.
	* gcc.target/gcn/cond_fminnm_1_run.c: New test.
	* gcc.target/gcn/cond_fminnm_2.c: New test.
	* gcc.target/gcn/cond_fminnm_2_run.c: New test.
	* gcc.target/gcn/cond_fminnm_3.c: New test.
	* gcc.target/gcn/cond_fminnm_3_run.c: New test.
	* gcc.target/gcn/cond_fminnm_4.c: New test.
	* gcc.target/gcn/cond_fminnm_4_run.c: New test.
	* gcc.target/gcn/cond_fminnm_5.c: New test.
	* gcc.target/gcn/cond_fminnm_5_run.c: New test.
	* gcc.target/gcn/cond_fminnm_6.c: New test.
	* gcc.target/gcn/cond_fminnm_6_run.c: New test.
	* gcc.target/gcn/cond_fminnm_7.c: New test.
	* gcc.target/gcn/cond_fminnm_7_run.c: New test.
	* gcc.target/gcn/cond_fminnm_8.c: New test.
	* gcc.target/gcn/cond_fminnm_8_run.c: New test.
	* gcc.target/gcn/cond_smax_1.c: New test.
	* gcc.target/gcn/cond_smax_1_run.c: New test.
	* gcc.target/gcn/cond_smin_1.c: New test.
	* gcc.target/gcn/cond_smin_1_run.c: New test.
	* gcc.target/gcn/cond_umax_1.c: New test.
	* gcc.target/gcn/cond_umax_1_run.c: New test.
	* gcc.target/gcn/cond_umin_1.c: New test.
	* gcc.target/gcn/cond_umin_1_run.c: New test.
	* gcc.target/gcn/smax_1.c: New test.
	* gcc.target/gcn/smax_1_run.c: New test.
	* gcc.target/gcn/smin_1.c: New test.
	* gcc.target/gcn/smin_1_run.c: New test.
	* gcc.target/gcn/umax_1.c: New test.
	* gcc.target/gcn/umax_1_run.c: New test.
	* gcc.target/gcn/umin_1.c: New test.
	* gcc.target/gcn/umin_1_run.c: New test.
---
 gcc/config/gcn/gcn-valu.md| 137 +-
 gcc/config/gcn/gcn.cc |   2 +-
 gcc/testsuite/gcc.target/gcn/cond_fmaxnm_1.c  |  33 +
 .../gcc.target/gcn/cond_fmaxnm_1_run.c|  32 
 gcc/testsuite/gcc.target/gcn/cond_fmaxnm_2.c  |  33 +
 .../gcc.target/gcn/cond_fmaxnm_2_run.c|  31 
 gcc/testsuite/gcc.target/gcn/cond_fmaxnm_3.c  |  35 +
 .../gcc.target/gcn/cond_fmaxnm_3_run.c|  32 
 gcc/testsuite/gcc.target/gcn/cond_fmaxnm_4.c  |  35 +
 .../gcc.target/gcn/cond_fmaxnm_4_run.c|  32 
 gcc/testsuite/gcc.target/gcn/cond_fmaxnm_5.c  |   9 ++
 .../gcc.target/gcn/cond_fmaxnm_5_run.c|   4 +
 gcc/testsuite/gcc.target/gcn/cond_fmaxnm_6.c  |   9 ++
 .../gcc.target/gcn/cond_fmaxnm_6_run.c|   4 +
 

Re: [PATCH] gcc: Adjust gdbhooks.py VecPrinter for vec layout changes

[Jakub Jelinek via Gcc-patches]

On Fri, Mar 03, 2023 at 05:45:59PM +0100, Jakub Jelinek via Gcc-patches wrote:
> On Fri, Mar 03, 2023 at 04:44:39PM +, Jonathan Wakely via Gcc-patches 
> wrote:
> > OK for trunk?
> > 
> > gcc/ChangeLog:
> > 
> 
> Please add
>   PR middle-end/109006
> here
> > * gdbhooks.py (VecPrinter): Adjust for new vec layout.
> 
> Ok with that, thanks.

Though, trying it on another vector it doesn't work in that case.
Testcase:
int
foo (void)
{
  return 1;
}
gdb ./cc1 -quiet -O2 test.c
b pass_reassoc::execute
r
p debug_bb_n (2)
p $1->preds
(gdb) p $1->preds
$2 = 0x7fffea2d1f50 = {}
(gdb) p $1->succs
$3 = 0x7fffea3010a0 = {}

But if I try to print it the hard way:
(gdb) p ((edge_def**)(&$1->preds.m_vecpfx+1))[0]
$4 =  2)>
(gdb) p ((edge_def**)(&$1->succs.m_vecpfx+1))[0]
$5 =  EXIT)>

> > diff --git a/gcc/gdbhooks.py b/gcc/gdbhooks.py
> > index c9dea9bf828..78e6c97c30d 100644
> > --- a/gcc/gdbhooks.py
> > +++ b/gcc/gdbhooks.py
> > @@ -461,7 +461,11 @@ class VecPrinter:
> >  return
> >  m_vecpfx = self.gdbval['m_vecpfx']
> >  m_num = m_vecpfx['m_num']
> > -m_vecdata = self.gdbval['m_vecdata']
> > +typ = self.gdbval.type
> > +if typ.code == gdb.TYPE_CODE_PTR:
> > +typ = typ.target()
> > +typ = typ.template_argument(0) # the type T
> > +m_vecdata = (self.gdbval.address + 1).cast(typ.pointer())
> >  for i in range(m_num):
> >  yield ('[%d]' % i, m_vecdata[i])

Jakub

Re: [PATCH] gcc: Adjust gdbhooks.py VecPrinter for vec layout changes

[Jakub Jelinek via Gcc-patches]

On Fri, Mar 03, 2023 at 04:44:39PM +, Jonathan Wakely via Gcc-patches wrote:
> OK for trunk?
> 
> gcc/ChangeLog:
> 

Please add
PR middle-end/109006
here
>   * gdbhooks.py (VecPrinter): Adjust for new vec layout.

Ok with that, thanks.

>  gcc/gdbhooks.py | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/gcc/gdbhooks.py b/gcc/gdbhooks.py
> index c9dea9bf828..78e6c97c30d 100644
> --- a/gcc/gdbhooks.py
> +++ b/gcc/gdbhooks.py
> @@ -461,7 +461,11 @@ class VecPrinter:
>  return
>  m_vecpfx = self.gdbval['m_vecpfx']
>  m_num = m_vecpfx['m_num']
> -m_vecdata = self.gdbval['m_vecdata']
> +typ = self.gdbval.type
> +if typ.code == gdb.TYPE_CODE_PTR:
> +typ = typ.target()
> +typ = typ.template_argument(0) # the type T
> +m_vecdata = (self.gdbval.address + 1).cast(typ.pointer())
>  for i in range(m_num):
>  yield ('[%d]' % i, m_vecdata[i])
>  
> -- 
> 2.39.2

Jakub

[PATCH] gcc: Adjust gdbhooks.py VecPrinter for vec layout changes

[Jonathan Wakely via Gcc-patches]

OK for trunk?

gcc/ChangeLog:

* gdbhooks.py (VecPrinter): Adjust for new vec layout.
---
 gcc/gdbhooks.py | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/gcc/gdbhooks.py b/gcc/gdbhooks.py
index c9dea9bf828..78e6c97c30d 100644
--- a/gcc/gdbhooks.py
+++ b/gcc/gdbhooks.py
@@ -461,7 +461,11 @@ class VecPrinter:
 return
 m_vecpfx = self.gdbval['m_vecpfx']
 m_num = m_vecpfx['m_num']
-m_vecdata = self.gdbval['m_vecdata']
+typ = self.gdbval.type
+if typ.code == gdb.TYPE_CODE_PTR:
+typ = typ.target()
+typ = typ.template_argument(0) # the type T
+m_vecdata = (self.gdbval.address + 1).cast(typ.pointer())
 for i in range(m_num):
 yield ('[%d]' % i, m_vecdata[i])
 
-- 
2.39.2

Re: [PATCH v4] c++: -Wdangling-reference with reference wrapper [PR107532]

[Jason Merrill via Gcc-patches]

On 3/2/23 16:24, Marek Polacek wrote:

On Wed, Mar 01, 2023 at 04:53:23PM -0500, Jason Merrill wrote:

@@ -13791,12 +13830,39 @@ std_pair_ref_ref_p (tree t)
const int& y = (f(1), 42); // NULL_TREE
const int& z = f(f(1)); // f(f(1))
-   EXPR is the initializer.  */
+   EXPR is the initializer.  If ARG_P is true, we're processing an argument
+   to a function; the point is to distinguish between, for example,
+
+ Ref::inner (_EXPR )
+
+   where we shouldn't warn, and
+
+ Ref::inner (_EXPR )>)
+
+   where we should warn (Ref is a reference_like_class_p so we see through
+   it.  */
   static tree
-do_warn_dangling_reference (tree expr)
+do_warn_dangling_reference (tree expr, bool arg_p)
   {
 STRIP_NOPS (expr);
+  if (TREE_CODE (expr) == ADDR_EXPR)
+expr = TREE_OPERAND (expr, 0);


I think if we move this here, we also need to check that expr before
STRIP_NOPS had REFERENCE_TYPE.  OK with that change.


Sorry but I don't think I can do that.  There can be CONVERT_EXPRs
that need to be stripped, whether arg_p or !arg_p.  For example, we can get
(const int *) f ((const int &) _EXPR >)
for
const int& r5 = (42, f(10));


I meant that we only want to strip ADDR_EXPR if 'expr' at the start of 
the function had REFERENCE_TYPE, corresponding to


/* Check that this argument initializes a reference, except for 
   the argument initializing the object of a member function.  */

if (!DECL_NONSTATIC_MEMBER_FUNCTION_P (fndecl)
&& !TYPE_REF_P (TREE_TYPE (arg)))
  continue;


above the code for stripping an ADDR_EXPR from an argument that your 
patch removes.


If the original expr is a pointer rather than a reference, we don't want 
to complain about it pointing to a temporary.


Jason

Re: [PATCH 0/2] LoongArch: testsuite: Fix tests related to stack

[Mike Stump via Gcc-patches]

On Mar 3, 2023, at 12:40 AM, Xi Ruoyao via Gcc-patches 
 wrote:
> 
> Some trivial test case fixes.  Ok for trunk?

Ok.

Re: [PATCH] c++: thinko in extract_local_specs [PR108998]

[Jason Merrill via Gcc-patches]

On 3/3/23 09:58, Patrick Palka wrote:

In order to fix PR100295, r13-4730-g18499b9f848707 attempted to make
extract_local_specs walk the given pattern twice, ignoring unevaluated
operands the first time around so that we prefer to process a local
specialization in an evaluated context if it appears in one (we process
a local specialization once even if it appears multiple times in the
pattern).

But there's a thinko in the patch, namely that we don't actually walk
the pattern twice, because we reuse the visited set for the second walk
(to avoid processing a local specialization twice), and the root node
(and any nodes leading up to an unevaluated operand) is considered
visited already.  So the patch effectively made extract_local_specs
ignore unevaluated operands altogether, which this testcase demonstrates
isn't quite safe (extract_local_specs never sees 'aa' and we don't save
its local specialization, so we later try to specialize 'aa' on the spot
with the args {{int},{42}} which causes us to nonsensically substitute
its auto with 42.)

This patch fixes this by walking only the trees we skipped over during
the first walk the second time around.

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk/12?


OK.


PR c++/108998

gcc/cp/ChangeLog:

* pt.cc (el_data::skipped_trees): New data member.
(extract_locals_r): Push to skipped_trees any unevaluated
contexts that we skipped over.
(extract_local_specs): During the second walk, consider only
the trees in skipped_trees.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/lambda-generic11.C: New test.
---
  gcc/cp/pt.cc  | 10 +-
  gcc/testsuite/g++.dg/cpp2a/lambda-generic11.C | 13 +
  2 files changed, 22 insertions(+), 1 deletion(-)
  create mode 100644 gcc/testsuite/g++.dg/cpp2a/lambda-generic11.C

diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
index ba1b3027513..85136df1730 100644
--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -13052,6 +13052,8 @@ public:
tsubst_flags_t complain;
/* True iff we don't want to walk into unevaluated contexts.  */
bool skip_unevaluated_operands = false;
+  /* The unevaluated contexts that we avoided walking.  */
+  auto_vec skipped_trees;
  
el_data (tsubst_flags_t c)

  : extra (NULL_TREE), complain (c) {}
@@ -13066,6 +13068,7 @@ extract_locals_r (tree *tp, int *walk_subtrees, void 
*data_)
if (data.skip_unevaluated_operands
&& unevaluated_p (TREE_CODE (*tp)))
  {
+  data.skipped_trees.safe_push (*tp);
*walk_subtrees = 0;
return NULL_TREE;
  }
@@ -13168,8 +13171,13 @@ extract_local_specs (tree pattern, tsubst_flags_t 
complain)
   context).  */
data.skip_unevaluated_operands = true;
cp_walk_tree (, extract_locals_r, , );
+  /* Now walk the unevaluated contexts we skipped the first time around.  */
data.skip_unevaluated_operands = false;
-  cp_walk_tree (, extract_locals_r, , );
+  for (tree t : data.skipped_trees)
+{
+  data.visited.remove (t);
+  cp_walk_tree (, extract_locals_r, , );
+}
return data.extra;
  }
  
diff --git a/gcc/testsuite/g++.dg/cpp2a/lambda-generic11.C b/gcc/testsuite/g++.dg/cpp2a/lambda-generic11.C

new file mode 100644
index 000..418650699e3
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/lambda-generic11.C
@@ -0,0 +1,13 @@
+// PR c++/108999
+// { dg-do compile { target c++20 } }
+
+template
+void ice(T a) {
+  auto aa = a;
+  auto lambda = []() {
+if constexpr (sizeof(aa) + I != 42) {}
+  };
+  lambda.template operator()<0>();
+}
+
+template void ice(int);

Re: [PATCH] c++, v2: Don't defer local statics initialized with constant expressions [PR108702]

[Jason Merrill via Gcc-patches]

On 3/3/23 10:18, Jakub Jelinek wrote:

On Thu, Mar 02, 2023 at 11:48:04AM -0500, Jason Merrill wrote:

The stmtexpr19.C testcase used to be rejected as it has a static
variable in statement expression in constexpr context, but as that
static variable is initialized by constant expression, when P2647R1
was implemented we agreed to make it valid.

Now, as reported, the testcase compiles fine, but doesn't actually link
because the static variable isn't defined anywhere, and with -flto ICEs
because of this problem.  This is because we never
varpool_node::finalize_decl those vars, the constant expression in which
the DECL_EXPR is present for the static VAR_DECL is folded (constant
evaluated) into just the address of the VAR_DECL.


Would it make sense to define it when we see the DECL_EXPR in constant
evaluation?


So like this?


OK, thanks.


Passes GXX_TESTSUITE_STDS=98,11,14,17,20,2b make check-g++ so far.

2023-03-03  Jakub Jelinek  

PR c++/108702
* constexpr.cc: Include toplev.h.
(cxx_eval_constant_expression) : When seeing a local
static initialized by constant expression outside of a constexpr
function which has been deferred by make_rtl_for_nonlocal_decl,
call rest_of_decl_compilation on it.

* g++.dg/ext/stmtexpr19.C: Use dg-do link rather than dg-do compile.

--- gcc/cp/constexpr.cc.jj  2023-03-03 00:34:44.113679918 +0100
+++ gcc/cp/constexpr.cc 2023-03-03 13:26:57.602871900 +0100
@@ -40,6 +40,7 @@ along with GCC; see the file COPYING3.
  #include "attribs.h"
  #include "fold-const.h"
  #include "intl.h"
+#include "toplev.h"
  
  static bool verify_constant (tree, bool, bool *, bool *);

  #define VERIFY_CONSTANT(X)\
@@ -7127,6 +7128,24 @@ cxx_eval_constant_expression (const cons
break;
  }
  
+	/* make_rtl_for_nonlocal_decl could have deferred emission of

+  a local static var, but if it appears in a statement expression
+  which is constant expression evaluated to e.g. just the address
+  of the variable, its DECL_EXPR will never be seen during
+  gimple lowering's record_vars_into as the statement expression
+  will not be in the IL at all.  */
+   if (VAR_P (r)
+   && TREE_STATIC (r)
+   && !DECL_REALLY_EXTERN (r)
+   && DECL_FUNCTION_SCOPE_P (r)
+   && !var_in_maybe_constexpr_fn (r)
+   && decl_constant_var_p (r))
+ {
+   varpool_node *node = varpool_node::get (r);
+   if (node == NULL || !node->definition)
+ rest_of_decl_compilation (r, 0, at_eof);
+ }
+
if (AGGREGATE_TYPE_P (TREE_TYPE (r))
|| VECTOR_TYPE_P (TREE_TYPE (r)))
  {
--- gcc/testsuite/g++.dg/ext/stmtexpr19.C.jj2023-02-09 15:52:29.623359240 
+0100
+++ gcc/testsuite/g++.dg/ext/stmtexpr19.C   2023-03-03 12:24:20.217186735 
+0100
@@ -1,6 +1,6 @@
  // PR c++/81073
  // { dg-options "" }
-// { dg-do compile { target c++11 } }
+// { dg-do link { target c++11 } }
  
  struct test { const int *addr; };
  



Jakub

[PATCH] c++, v2: Don't defer local statics initialized with constant expressions [PR108702]

[Jakub Jelinek via Gcc-patches]

On Thu, Mar 02, 2023 at 11:48:04AM -0500, Jason Merrill wrote:
> > The stmtexpr19.C testcase used to be rejected as it has a static
> > variable in statement expression in constexpr context, but as that
> > static variable is initialized by constant expression, when P2647R1
> > was implemented we agreed to make it valid.
> > 
> > Now, as reported, the testcase compiles fine, but doesn't actually link
> > because the static variable isn't defined anywhere, and with -flto ICEs
> > because of this problem.  This is because we never
> > varpool_node::finalize_decl those vars, the constant expression in which
> > the DECL_EXPR is present for the static VAR_DECL is folded (constant
> > evaluated) into just the address of the VAR_DECL.
> 
> Would it make sense to define it when we see the DECL_EXPR in constant
> evaluation?

So like this?
Passes GXX_TESTSUITE_STDS=98,11,14,17,20,2b make check-g++ so far.

2023-03-03  Jakub Jelinek  

PR c++/108702
* constexpr.cc: Include toplev.h.
(cxx_eval_constant_expression) : When seeing a local
static initialized by constant expression outside of a constexpr
function which has been deferred by make_rtl_for_nonlocal_decl,
call rest_of_decl_compilation on it.

* g++.dg/ext/stmtexpr19.C: Use dg-do link rather than dg-do compile.

--- gcc/cp/constexpr.cc.jj  2023-03-03 00:34:44.113679918 +0100
+++ gcc/cp/constexpr.cc 2023-03-03 13:26:57.602871900 +0100
@@ -40,6 +40,7 @@ along with GCC; see the file COPYING3.
 #include "attribs.h"
 #include "fold-const.h"
 #include "intl.h"
+#include "toplev.h"
 
 static bool verify_constant (tree, bool, bool *, bool *);
 #define VERIFY_CONSTANT(X) \
@@ -7127,6 +7128,24 @@ cxx_eval_constant_expression (const cons
break;
  }
 
+   /* make_rtl_for_nonlocal_decl could have deferred emission of
+  a local static var, but if it appears in a statement expression
+  which is constant expression evaluated to e.g. just the address
+  of the variable, its DECL_EXPR will never be seen during
+  gimple lowering's record_vars_into as the statement expression
+  will not be in the IL at all.  */
+   if (VAR_P (r)
+   && TREE_STATIC (r)
+   && !DECL_REALLY_EXTERN (r)
+   && DECL_FUNCTION_SCOPE_P (r)
+   && !var_in_maybe_constexpr_fn (r)
+   && decl_constant_var_p (r))
+ {
+   varpool_node *node = varpool_node::get (r);
+   if (node == NULL || !node->definition)
+ rest_of_decl_compilation (r, 0, at_eof);
+ }
+
if (AGGREGATE_TYPE_P (TREE_TYPE (r))
|| VECTOR_TYPE_P (TREE_TYPE (r)))
  {
--- gcc/testsuite/g++.dg/ext/stmtexpr19.C.jj2023-02-09 15:52:29.623359240 
+0100
+++ gcc/testsuite/g++.dg/ext/stmtexpr19.C   2023-03-03 12:24:20.217186735 
+0100
@@ -1,6 +1,6 @@
 // PR c++/81073
 // { dg-options "" }
-// { dg-do compile { target c++11 } }
+// { dg-do link { target c++11 } }
 
 struct test { const int *addr; };
 


Jakub

Re: [PATCH] s390: Fix ifcvt test cases

[Andreas Krebbel via Gcc-patches]

On 3/2/23 19:13, Robin Dapp wrote:
> Hi,
> 
> we seem to flip flop between the "high" and "not low" variants of load on
> condition.  Accept both in the affected test cases.
> 
> Going to commit this as obvious.
> 
> Regards
>  Robin
> 
> --
> 
> gcc/testsuite/ChangeLog:
> 
>   * gcc.target/s390/ifcvt-two-insns-bool.c: Allow "high" and
>   "not low or equal" load on condition variant.
>   * gcc.target/s390/ifcvt-two-insns-int.c: Dito.
>   * gcc.target/s390/ifcvt-two-insns-long.c: Dito.

Ok. Thanks!

Andreas

> ---
>  gcc/testsuite/gcc.target/s390/ifcvt-two-insns-bool.c | 4 ++--
>  gcc/testsuite/gcc.target/s390/ifcvt-two-insns-int.c  | 4 ++--
>  gcc/testsuite/gcc.target/s390/ifcvt-two-insns-long.c | 4 ++--
>  3 files changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/gcc/testsuite/gcc.target/s390/ifcvt-two-insns-bool.c 
> b/gcc/testsuite/gcc.target/s390/ifcvt-two-insns-bool.c
> index 1027ddceb935..a56bc4676143 100644
> --- a/gcc/testsuite/gcc.target/s390/ifcvt-two-insns-bool.c
> +++ b/gcc/testsuite/gcc.target/s390/ifcvt-two-insns-bool.c
> @@ -3,8 +3,8 @@
>  /* { dg-do run } */
>  /* { dg-options "-O2 -march=z13 -mzarch --save-temps" } */
>  
> -/* { dg-final { scan-assembler "lochih\t%r.?,1" } } */
> -/* { dg-final { scan-assembler "locrh\t.*" } } */
> +/* { dg-final { scan-assembler "lochi(?:h|nle)\t%r.?,1" } } */
> +/* { dg-final { scan-assembler "locr(?:h|nle)\t.*" } } */
>  #include 
>  #include 
>  #include 
> diff --git a/gcc/testsuite/gcc.target/s390/ifcvt-two-insns-int.c 
> b/gcc/testsuite/gcc.target/s390/ifcvt-two-insns-int.c
> index fc6946f2466d..64b8a732290e 100644
> --- a/gcc/testsuite/gcc.target/s390/ifcvt-two-insns-int.c
> +++ b/gcc/testsuite/gcc.target/s390/ifcvt-two-insns-int.c
> @@ -3,8 +3,8 @@
>  /* { dg-do run } */
>  /* { dg-options "-O2 -march=z13 -mzarch --save-temps" } */
>  
> -/* { dg-final { scan-assembler "lochih\t%r.?,1" } } */
> -/* { dg-final { scan-assembler "locrh\t.*" } } */
> +/* { dg-final { scan-assembler "lochi(h|nle)\t%r.?,1" } } */
> +/* { dg-final { scan-assembler "locr(?:h|nle)\t.*" } } */
>  #include 
>  #include 
>  #include 
> diff --git a/gcc/testsuite/gcc.target/s390/ifcvt-two-insns-long.c 
> b/gcc/testsuite/gcc.target/s390/ifcvt-two-insns-long.c
> index 51af4985247a..f2d784e762a8 100644
> --- a/gcc/testsuite/gcc.target/s390/ifcvt-two-insns-long.c
> +++ b/gcc/testsuite/gcc.target/s390/ifcvt-two-insns-long.c
> @@ -3,8 +3,8 @@
>  /* { dg-do run } */
>  /* { dg-options "-O2 -march=z13 -mzarch --save-temps" } */
>  
> -/* { dg-final { scan-assembler "locghih\t%r.?,1" } } */
> -/* { dg-final { scan-assembler "locgrh\t.*" } } */
> +/* { dg-final { scan-assembler "locghi(?:h|nle)\t%r.?,1" } } */
> +/* { dg-final { scan-assembler "locgr(?:h|nle)\t.*" } } */
>  
>  #include 
>  #include 

Re: [PATCH] s390: libatomic: Fix 16 byte atomic {cas,load,store}

[Andreas Krebbel via Gcc-patches]

On 3/2/23 16:24, Stefan Schulze Frielinghaus wrote:
> This is a follow-up to commit a4c6bd0821099f6b8c0f64a96ffd9d01a025c413
> introducing a runtime check for alignment for 16 byte atomic
> compare-exchange, load, and store.
> 
> Bootstrapped and regtested on s390.
> Ok for mainline and gcc-{12,11,10}?
> 
> libatomic/ChangeLog:
> 
>   * config/s390/cas_n.c: New file.
>   * config/s390/load_n.c: New file.
>   * config/s390/store_n.c: New file.

Ok. Thanks!

Andreas

> ---
>  libatomic/config/s390/cas_n.c   | 65 +
>  libatomic/config/s390/load_n.c  | 57 +
>  libatomic/config/s390/store_n.c | 54 +++
>  3 files changed, 176 insertions(+)
>  create mode 100644 libatomic/config/s390/cas_n.c
>  create mode 100644 libatomic/config/s390/load_n.c
>  create mode 100644 libatomic/config/s390/store_n.c
> 
> diff --git a/libatomic/config/s390/cas_n.c b/libatomic/config/s390/cas_n.c
> new file mode 100644
> index 000..44b7152ca5d
> --- /dev/null
> +++ b/libatomic/config/s390/cas_n.c
> @@ -0,0 +1,65 @@
> +/* Copyright (C) 2018-2023 Free Software Foundation, Inc.
> +
> +   This file is part of the GNU Atomic Library (libatomic).
> +
> +   Libatomic is free software; you can redistribute it and/or modify it
> +   under the terms of the GNU General Public License as published by
> +   the Free Software Foundation; either version 3 of the License, or
> +   (at your option) any later version.
> +
> +   Libatomic is distributed in the hope that it will be useful, but WITHOUT 
> ANY
> +   WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS
> +   FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> +   more details.
> +
> +   Under Section 7 of GPL version 3, you are granted additional
> +   permissions described in the GCC Runtime Library Exception, version
> +   3.1, as published by the Free Software Foundation.
> +
> +   You should have received a copy of the GNU General Public License and
> +   a copy of the GCC Runtime Library Exception along with this program;
> +   see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
> +   .  */
> +
> +#include 
> +
> +
> +/* Analog to config/s390/exch_n.c.  */
> +
> +#if !DONE && N == 16
> +bool
> +SIZE(libat_compare_exchange) (UTYPE *mptr, UTYPE *eptr, UTYPE newval,
> +   int smodel, int fmodel UNUSED)
> +{
> +  if (!((uintptr_t)mptr & 0xf))
> +{
> +  return __atomic_compare_exchange_n (
> + (UTYPE *)__builtin_assume_aligned (mptr, 16), eptr, newval, false,
> + __ATOMIC_SEQ_CST, __ATOMIC_RELAXED);
> +}
> +  else
> +{
> +  UTYPE oldval;
> +  UWORD magic;
> +  bool ret;
> +
> +  pre_seq_barrier (smodel);
> +  magic = protect_start (mptr);
> +
> +  oldval = *mptr;
> +  ret = (oldval == *eptr);
> +  if (ret)
> + *mptr = newval;
> +  else
> + *eptr = oldval;
> +
> +  protect_end (mptr, magic);
> +  post_seq_barrier (smodel);
> +
> +  return ret;
> +}
> +}
> +#define DONE 1
> +#endif /* N == 16 */
> +
> +#include "../../cas_n.c"
> diff --git a/libatomic/config/s390/load_n.c b/libatomic/config/s390/load_n.c
> new file mode 100644
> index 000..335d2f8b2c3
> --- /dev/null
> +++ b/libatomic/config/s390/load_n.c
> @@ -0,0 +1,57 @@
> +/* Copyright (C) 2018-2023 Free Software Foundation, Inc.
> +
> +   This file is part of the GNU Atomic Library (libatomic).
> +
> +   Libatomic is free software; you can redistribute it and/or modify it
> +   under the terms of the GNU General Public License as published by
> +   the Free Software Foundation; either version 3 of the License, or
> +   (at your option) any later version.
> +
> +   Libatomic is distributed in the hope that it will be useful, but WITHOUT 
> ANY
> +   WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS
> +   FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> +   more details.
> +
> +   Under Section 7 of GPL version 3, you are granted additional
> +   permissions described in the GCC Runtime Library Exception, version
> +   3.1, as published by the Free Software Foundation.
> +
> +   You should have received a copy of the GNU General Public License and
> +   a copy of the GCC Runtime Library Exception along with this program;
> +   see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
> +   .  */
> +
> +#include 
> +
> +
> +/* Analog to config/s390/exch_n.c.  */
> +
> +#if !DONE && N == 16
> +UTYPE
> +SIZE(libat_load) (UTYPE *mptr, int smodel)
> +{
> +  if (!((uintptr_t)mptr & 0xf))
> +{
> +  return __atomic_load_n ((UTYPE *)__builtin_assume_aligned (mptr, 16),
> +   __ATOMIC_SEQ_CST);
> +}
> +  else
> +{
> +  UTYPE ret;
> +  UWORD magic;
> +
> +  pre_seq_barrier (smodel);
> +  magic = protect_start 

Re: [PATCH] s390: Use arch14 instead of z16 for -march=native.

[Andreas Krebbel via Gcc-patches]

On 3/2/23 19:17, Robin Dapp wrote:
> Hi,
> 
> When compiling on a system where binutils do not yet support the 'z16'
> name assembling fails with -march=native which we currently interpret
> as -march=z16 (on a z16 machine).  This patch uses -march=arch14
> instead.
> 
> Is it OK?

Ok. Thanks!

Andreas


> 
> Regards
>  Robin
> 
> --
> 
> gcc/ChangeLog:
> 
>   * config/s390/driver-native.cc (s390_host_detect_local_cpu): Use
>   arch14 instead of z16.
> ---
>  gcc/config/s390/driver-native.cc | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/gcc/config/s390/driver-native.cc 
> b/gcc/config/s390/driver-native.cc
> index 563da45c7f6e..3b9c1e1ca5df 100644
> --- a/gcc/config/s390/driver-native.cc
> +++ b/gcc/config/s390/driver-native.cc
> @@ -125,10 +125,10 @@ s390_host_detect_local_cpu (int argc, const char **argv)
> break;
>   case 0x3931:
>   case 0x3932:
> -   cpu = "z16";
> +   cpu = "arch14";
> break;
>   default:
> -   cpu = "z16";
> +   cpu = "arch14";
> break;
>   }
>   }

[PATCH] c++: thinko in extract_local_specs [PR108998]

[Patrick Palka via Gcc-patches]

In order to fix PR100295, r13-4730-g18499b9f848707 attempted to make
extract_local_specs walk the given pattern twice, ignoring unevaluated
operands the first time around so that we prefer to process a local
specialization in an evaluated context if it appears in one (we process
a local specialization once even if it appears multiple times in the
pattern).

But there's a thinko in the patch, namely that we don't actually walk
the pattern twice, because we reuse the visited set for the second walk
(to avoid processing a local specialization twice), and the root node
(and any nodes leading up to an unevaluated operand) is considered
visited already.  So the patch effectively made extract_local_specs
ignore unevaluated operands altogether, which this testcase demonstrates
isn't quite safe (extract_local_specs never sees 'aa' and we don't save
its local specialization, so we later try to specialize 'aa' on the spot
with the args {{int},{42}} which causes us to nonsensically substitute
its auto with 42.)

This patch fixes this by walking only the trees we skipped over during
the first walk the second time around.

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk/12?

PR c++/108998

gcc/cp/ChangeLog:

* pt.cc (el_data::skipped_trees): New data member.
(extract_locals_r): Push to skipped_trees any unevaluated
contexts that we skipped over.
(extract_local_specs): During the second walk, consider only
the trees in skipped_trees.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/lambda-generic11.C: New test.
---
 gcc/cp/pt.cc  | 10 +-
 gcc/testsuite/g++.dg/cpp2a/lambda-generic11.C | 13 +
 2 files changed, 22 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/lambda-generic11.C

diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
index ba1b3027513..85136df1730 100644
--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -13052,6 +13052,8 @@ public:
   tsubst_flags_t complain;
   /* True iff we don't want to walk into unevaluated contexts.  */
   bool skip_unevaluated_operands = false;
+  /* The unevaluated contexts that we avoided walking.  */
+  auto_vec skipped_trees;
 
   el_data (tsubst_flags_t c)
 : extra (NULL_TREE), complain (c) {}
@@ -13066,6 +13068,7 @@ extract_locals_r (tree *tp, int *walk_subtrees, void 
*data_)
   if (data.skip_unevaluated_operands
   && unevaluated_p (TREE_CODE (*tp)))
 {
+  data.skipped_trees.safe_push (*tp);
   *walk_subtrees = 0;
   return NULL_TREE;
 }
@@ -13168,8 +13171,13 @@ extract_local_specs (tree pattern, tsubst_flags_t 
complain)
  context).  */
   data.skip_unevaluated_operands = true;
   cp_walk_tree (, extract_locals_r, , );
+  /* Now walk the unevaluated contexts we skipped the first time around.  */
   data.skip_unevaluated_operands = false;
-  cp_walk_tree (, extract_locals_r, , );
+  for (tree t : data.skipped_trees)
+{
+  data.visited.remove (t);
+  cp_walk_tree (, extract_locals_r, , );
+}
   return data.extra;
 }
 
diff --git a/gcc/testsuite/g++.dg/cpp2a/lambda-generic11.C 
b/gcc/testsuite/g++.dg/cpp2a/lambda-generic11.C
new file mode 100644
index 000..418650699e3
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/lambda-generic11.C
@@ -0,0 +1,13 @@
+// PR c++/108999
+// { dg-do compile { target c++20 } }
+
+template
+void ice(T a) {
+  auto aa = a;
+  auto lambda = []() {
+if constexpr (sizeof(aa) + I != 42) {}
+  };
+  lambda.template operator()<0>();
+}
+
+template void ice(int);
-- 
2.40.0.rc0.57.g454dfcbddf

[PATCH] moxie: enable LRA

[Anthony Green]

Committed as obviously correct.  Enable LRA for the moxie port.

gcc/ChangeLog:

* config/moxie/moxie.cc (TARGET_LRA_P): Remove.


diff --git a/gcc/config/moxie/moxie.cc b/gcc/config/moxie/moxie.cc
index dcf87ef98a1..2132b6e48a3 100644
--- a/gcc/config/moxie/moxie.cc
+++ b/gcc/config/moxie/moxie.cc
@@ -616,9 +616,6 @@ moxie_legitimate_address_p (machine_mode mode 
ATTRIBUTE_UNUSED,
 #undef  TARGET_FUNCTION_ARG_ADVANCE
 #define TARGET_FUNCTION_ARG_ADVANCEmoxie_function_arg_advance
 
-#undef TARGET_LRA_P
-#define TARGET_LRA_P hook_bool_void_false
-
 #undef  TARGET_ADDR_SPACE_LEGITIMATE_ADDRESS_P
 #define TARGET_ADDR_SPACE_LEGITIMATE_ADDRESS_P moxie_legitimate_address_p

[PATCH] moxie: use define_memory_constraint

[Anthony Green]

Committed as obviously correct.  Required to make LRA for moxie work.

gcc/ChangeLog:

* config/moxie/constraints.md (A, B, W): Change
define_constraint to define_memory_constraint.


diff --git a/gcc/config/moxie/constraints.md b/gcc/config/moxie/constraints.md
index 16c64b28b59..78e8e9813fd 100644
--- a/gcc/config/moxie/constraints.md
+++ b/gcc/config/moxie/constraints.md
@@ -22,19 +22,19 @@
 ;; Constraints
 ;; -
 
-(define_constraint "A"
+(define_memory_constraint "A"
   "An absolute address."
   (and (match_code "mem")
(ior (match_test "GET_CODE (XEXP (op, 0)) == SYMBOL_REF")
(match_test "GET_CODE (XEXP (op, 0)) == LABEL_REF")
(match_test "GET_CODE (XEXP (op, 0)) == CONST"
 
-(define_constraint "B"
+(define_memory_constraint "B"
   "An offset address."
   (and (match_code "mem")
(match_test "moxie_offset_address_p (op)")))
 
-(define_constraint "W"
+(define_memory_constraint "W"
   "A register indirect memory operand."
   (and (match_code "mem")
(match_test "REG_P (XEXP (op, 0))

Re: [PATCH] diagnostics: Fix up selftests with $COLUMNS < 42 [PR108973]

[David Malcolm via Gcc-patches]

On Fri, 2023-03-03 at 10:35 +0100, Jakub Jelinek wrote:
> Hi!
> 
> As mentioned in the PR, GCC's diagnostics self-tests fail if $COLUMNS
> < 42.
> Guarding each self-test with if (get_terminal_width () > 41) or
> similar
> would be a maintainance nightmare (PR has a patch to do so without
> reformatting to make it work for $COLUMNS in [30, 41] inclusive, but
> I'm afraid going down to $COLUMNS 1 would mean marking everything).
> Furthermore, the self-tests don't really emit stuff to the terminal,
> but into a buffer, so using get_terminal_width () for it seems
> inappropriate.  The following patch makes sure
> test_diagnostic_context
> constructor uses at least 80 columns wide caret max width, of course
> some tests override it already if they want to test for behavior in
> narrower
> cases.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, plus tested
> on self-tests with $COLUMNS down to 1, ok for trunk?
> 
> 2023-03-03  Jakub Jelinek  
> 
> PR testsuite/108973
> * selftest-diagnostic.cc
> (test_diagnostic_context::test_diagnostic_context): Ensure
> caret_max_width isn't smaller than 80.
> 
> --- gcc/selftest-diagnostic.cc.jj   2023-01-02 09:32:31.991146491
> +0100
> +++ gcc/selftest-diagnostic.cc  2023-03-02 10:05:17.974321025 +0100
> @@ -41,6 +41,7 @@ test_diagnostic_context::test_diagnostic
>    show_column = true;
>    start_span = start_span_cb;
>    min_margin_width = 6;
> +  caret_max_width = MAX (caret_max_width, 80);
>  }

Thanks for working on this.

Patch is OK, but I wonder if it would even better to just hardcode
caret_max_width as 80 here, to better eliminate that influence from
from the environment in the unit tests?  I think all of the tests that
modify caret_max_width do so after the ctor has run.

Dave

Re: [PATCHv2, gfortran] Escalate failure when Hollerith constant to real conversion fails [PR103628]

[Tobias Burnus]

Hi Haochen,

On 03.03.23 10:56, HAO CHEN GUI via Gcc-patches wrote:

Sure, I will merge it into the patch and do the regression test.

Thanks :-)

Additionally, Kewen suggested:

Since this test case is powerpc only, I think it can be moved to 
gcc/testsuite/gcc.target/powerpc/ppc-fortran/ppc-fortran.expgcc.target/powerpc/ppc-fortran.

Which sounds reasonable.

Test cases under gcc.target are tested by check-gcc-c. It greps "warning"
and "error" (C style, lower case) from the output while check-gcc-fortran
greps "Warning" and "Error" (upper case). As the test case needs to check
the "Warning" and "Error" messages. I have to put it in gfortran.dg
directory. What's your opinion?


Thanks for digging and giving a reason.

Looks as if at some point, adapting
gcc/testsuite/gcc.target/powerpc/ppc-fortran/ppc-fortran.exp to handle
this as well could make sense.

But placing it - as you did - under gcc/testsuite/gfortran.dg is fine
and surely the simpler solution. Thus, leave it as it.

Thanks,

Tobias




Gui Haochen
Thanks

-
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] apply debug-remap to file names in .su files

[Rasmus Villemoes]

On 13/02/2023 20.27, Rasmus Villemoes wrote:
> The .su files generated with -fstack-usage are arguably debug info. In
> order to make builds more reproducible, apply the same remapping logic
> to the recorded file names as for when producing the debug info
> embedded in the object files.
> 
> To this end, teach print_decl_identifier() a new
> PRINT_DECL_REMAP_DEBUG flag and use that from output_stack_usage_1().
> 

ping

Re: [PATCH] libiberty: fix memory leak in pex-win32.c and refactor

[Richard Biener via Gcc-patches]

On Thu, Mar 2, 2023 at 3:02 PM Costas Argyris  wrote:
>
> Thanks for the review.
>
> What is the next step please?

Somebody pushed the patch already.

Richard.

> Thanks,
> Costas
>
> On Thu, 2 Mar 2023 at 10:08, Richard Biener  
> wrote:
>>
>> On Thu, Mar 2, 2023 at 10:21 AM Costas Argyris  
>> wrote:
>> >
>> > I forgot to mention that:
>> >
>> > 1) The CreateProcess documentation
>> >
>> > https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createprocessa
>> >
>> > doesn't mention anything about taking ownership of this or any other 
>> > buffer passed to it.
>>
>> Thanks - thus the patch is OK.
>>
>> Thanks,
>> Richard.
>>
>> > 2) The cmdline buffer gets created by the argv_to_cmdline function
>> >
>> > https://github.com/gcc-mirror/gcc/blob/master/libiberty/pex-win32.c#L339
>> >
>> > which has this comment right above it:
>> >
>> > /* Return a Windows command-line from ARGV.  It is the caller's
>> >responsibility to free the string returned.  */
>> >
>> > Thanks,
>> > Costas
>> >
>> > On Thu, 2 Mar 2023 at 07:32, Richard Biener  
>> > wrote:
>> >>
>> >> On Wed, Mar 1, 2023 at 7:14 PM Costas Argyris via Gcc-patches
>> >>  wrote:
>> >> >
>> >> > Hi
>> >> >
>> >> > It seems that the win32_spawn function in libiberty/pex-win32.c is 
>> >> > leaking
>> >> > the cmdline buffer in 2/3 exit scenarios (it is only free'd in 1/3).
>> >> > The
>> >> > problem here is that the cleanup code is written 3 times, one at each 
>> >> > exit
>> >> > scenario.
>> >> >
>> >> > The proposed attached refactoring has the cleanup code appearing just 
>> >> > once
>> >> > and is executed for all exit scenarios, reducing the likelihood of such
>> >> > leaks in the future.
>> >>
>> >> One could imagine that CreateProcess in case of success takes ownership of
>> >> the buffer pointed to by cmdline?  If you can confirm it is not then the 
>> >> patch
>> >> looks OK to me.
>> >>
>> >> Thanks,
>> >> Richard.
>> >>
>> >> > Thanks,
>> >> > Costas

Re: [PATCH] waccess: Fix two -Wnonnull warning issues [PR108986]

[Richard Biener via Gcc-patches]

On Fri, 3 Mar 2023, Jakub Jelinek wrote:

> Hi!
> 
> The following patch fixes 2 issues with the -Wnonnull warning.
> 
> One, fixed by the second hunk, is that the warning wording is bogus
> since r11-3305, instead of printing
> warning: argument 1 to ‘int[static 7]’ is null where non-null expected 
> [-Wnonnull]
> it prints
> warning: argument 1 to ‘int[static 28]’ is null where non-null expected 
> [-Wnonnull]
> access_size is measured in bytes, so obviously will be correct as array
> number of elements only if it is 1 byte element array.
> In the function, access_nelts is either constant (if sizidx == -1) or
> when the array size is determined by some other parameter, I believe a value
> passed to that argument.
> Later on we query the range of it:
>   if (get_size_range (m_ptr_qry.rvals, access_nelts, stmt, sizrng, 1))
> which I bet must just return accesS_nelts in sizrng[0] and [1] if it is
> constant.  access_size is later computed as:
>   tree access_size = NULL_TREE;
>   if (tree_int_cst_sgn (sizrng[0]) >= 0)
> {
>   if (COMPLETE_TYPE_P (argtype))
> {
> ...
> wide_int minsize = wi::to_wide (sizrng[0], prec);
> minsize *= wi::to_wide (argsize, prec);
> access_size = wide_int_to_tree (sizetype, minsize);
>   }
> }
>   else
> access_size = access_nelts;
> }
> and immediately after this the code does:
>   if (integer_zerop (ptr))
> {
>   if (sizidx >= 0 && tree_int_cst_sgn (sizrng[0]) > 0)
> {
> some other warning wording
> }
>   else if (access_size && access.second.static_p)
> {
> this spot
> }
> }
> So, because argtype is complete, access_size has been multiplied by
> argsize, but in case of this exact warning ("this spot" above)
> I believe access_nelts must be really constant, otherwise
> "some other warning wording" would handle it.  So, I think access_nelts
> is exactly what we want to print there.
> 
> The other problem is that since the introduction of -Wdangling-pointer
> in r12-6606, the pass has early and late instances and while lots of
> stuff in the pass is guarded on being done in the late pass only,
> this particular function is not, furthermore it is emitting two different
> warnings in a loop and already messes up with stuff like clearing
> warning suppression for one of the warning (ugh!).  The end effect is
> that we warn twice about the same problem, once in the early and once in
> the late pass.  Now, e.g. with -O2 -Wall we warn just once, during the
> early pass, as it is then optimized away, so I think just making this
> late warning only wouldn't be best.  This patch instead returns early
> if either of the warnings is suppressed on the call stmt already.
> I think if one of the passes warned on it already (even if say on some other
> argument), then warning again (even on some other argument) is unnecessary,
> if both problems are visible in the same pass we'll still warn about both.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

OK.

Thanks,
Richard.

> 2023-03-03  Jakub Jelinek  
> 
>   PR c/108986
>   * gimple-ssa-warn-access.cc (pass_waccess::maybe_check_access_sizes):
>   Return immediately if OPT_Wnonnull or OPT_Wstringop_overflow_ is
>   suppressed on stmt.  For [static %E] warning, print access_nelts
>   rather than access_size.  Fix up comment wording.
> 
>   * gcc.dg/Wnonnull-8.c: New test.
> 
> --- gcc/gimple-ssa-warn-access.cc.jj  2023-02-22 20:50:27.418519815 +0100
> +++ gcc/gimple-ssa-warn-access.cc 2023-03-02 19:04:24.744280016 +0100
> @@ -3318,6 +3318,10 @@ void
>  pass_waccess::maybe_check_access_sizes (rdwr_map *rwm, tree fndecl, tree 
> fntype,
>   gimple *stmt)
>  {
> +  if (warning_suppressed_p (stmt, OPT_Wnonnull)
> +  || warning_suppressed_p (stmt, OPT_Wstringop_overflow_))
> +return;
> +
>auto_diagnostic_group adg;
>  
>/* Set if a warning has been issued for any argument (used to decide
> @@ -3501,7 +3505,7 @@ pass_waccess::maybe_check_access_sizes (
> if (warning_at (loc, OPT_Wnonnull,
> "argument %i to %<%T[static %E]%> "
> "is null where non-null expected",
> -   ptridx + 1, argtype, access_size))
> +   ptridx + 1, argtype, access_nelts))
>   arg_warned = OPT_Wnonnull;
>   }
>  
> @@ -3593,7 +3597,7 @@ pass_waccess::maybe_check_access_sizes (
>   "in a call with type %qT", fntype);
>  }
>  
> -  /* Set the bit in case if was cleared and not set above.  */
> +  /* Set the bit in case it was cleared and not set above.  */
>if (opt_warned != no_warning)
>  suppress_warning (stmt, opt_warned);
>  }
> --- gcc/testsuite/gcc.dg/Wnonnull-8.c.jj  

Re: [PATCH] driver: toplev: Fix a typo

[Richard Biener via Gcc-patches]

On Fri, Mar 3, 2023 at 9:58 AM Xi Ruoyao via Gcc-patches
 wrote:
>
> On Fri, 2023-03-03 at 16:54 +0800, Xi Ruoyao wrote:
> > The driver emits a warning when -fstack-check and
> > -fstack-clash-protection are used together, but the message refers to
> > "-fstack-clash_protection" (underline instead of dash).
>
> Forgot: Ok for trunk?  Though I think it's obvious but let's follow the
> procedure :).

OK.

> > gcc/ChangeLog:
> >
> > * toplev.cc (process_options): Fix the spelling of
> > "-fstack-clash-protection".
> > ---
> >  gcc/toplev.cc | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/gcc/toplev.cc b/gcc/toplev.cc
> > index 4c15d4f542e..109c9d58cbd 100644
> > --- a/gcc/toplev.cc
> > +++ b/gcc/toplev.cc
> > @@ -1580,7 +1580,7 @@ process_options (bool no_backend)
> >if (flag_stack_check != NO_STACK_CHECK &&
> > flag_stack_clash_protection)
> >  {
> >warning_at (UNKNOWN_LOCATION, 0,
> > - "%<-fstack-check=%> and %<-fstack-clash_protection%>
> > are "
> > + "%<-fstack-check=%> and %<-fstack-clash-protection%>
> > are "
> >   "mutually exclusive; disabling %<-fstack-check=%>");
> >flag_stack_check = NO_STACK_CHECK;
> >  }
>
> --
> Xi Ruoyao 
> School of Aerospace Science and Technology, Xidian University

Re: [PATCH] -Wdangling-pointer: don't mark SSA lhs sets as stores

[Richard Biener via Gcc-patches]

On Fri, Mar 3, 2023 at 9:30 AM Alexandre Oliva  wrote:
>
> On Feb 17, 2023, Richard Biener  wrote:
>
> >> * gimple-ssa-warn-access.cc
> >> (pass_waccess::check_dangling_stores): Skip non-stores.
> >>
> >> for  gcc/testsuite/ChangeLog
> >>
> >> * g++.dg/warn/Wdangling-pointer.C (warn_init_ref_member): Add
> >> two new variants, one fixed, one xfailed.
> >> * c-c++-common/Wdangling-pointer-5.c
> >> (nowarn_store_arg_store_arg): Add now-expected warnings.
>
> Ping?
> https://gcc.gnu.org/pipermail/gcc-patches/2023-February/612186.html

I was hoping Martin would chime in, but he didn't.

So - OK.

Thanks,
Richard.

>
> --
> Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
>Free Software Activist   GNU Toolchain Engineer
> Disinformation flourishes because many people care deeply about injustice
> but very few check the facts.  Ask me about 

Re: [PATCH] testsuite: Do not expect partial vectorization for s390.

[Richard Biener via Gcc-patches]

On Thu, Mar 2, 2023 at 7:24 PM Robin Dapp via Gcc-patches
 wrote:
>
> Hi,
>
> this patch changes SLP test expectations.  As we only vectorize when no
> more than one rgroup is present, no vectorization is performed.
>
> I was also considering using a separate target selector (something like
> vect_partial_vectors_bias_m1) but as the number of testcases is limited
> that would probably not simplify things much for now.
>
> Is this OK?

OK

> Regards
>  Robin
>
> --
>
> gcc/testsuite/ChangeLog:
>
> * gcc.dg/vect/slp-3.c: Adapt test expectation.
> * gcc.dg/vect/slp-multitypes-11.c: Likewise.
> * gcc.dg/vect/slp-perm-8.c: Likewise.
> ---
>  gcc/testsuite/gcc.dg/vect/slp-3.c | 8 
>  gcc/testsuite/gcc.dg/vect/slp-multitypes-11.c | 4 ++--
>  gcc/testsuite/gcc.dg/vect/slp-perm-8.c| 4 ++--
>  3 files changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/gcc/testsuite/gcc.dg/vect/slp-3.c 
> b/gcc/testsuite/gcc.dg/vect/slp-3.c
> index 80ded1840ad2..4b9a58662305 100644
> --- a/gcc/testsuite/gcc.dg/vect/slp-3.c
> +++ b/gcc/testsuite/gcc.dg/vect/slp-3.c
> @@ -141,8 +141,8 @@ int main (void)
>return 0;
>  }
>
> -/* { dg-final { scan-tree-dump-times "vectorized 3 loops" 1 "vect" { target 
> { ! { vect_partial_vectors || vect32 } } } } } */
> -/* { dg-final { scan-tree-dump-times "vectorized 4 loops" 1 "vect" { target 
> { vect_partial_vectors || vect32 } } } } */
> -/* { dg-final { scan-tree-dump-times "vectorizing stmts using SLP" 3 "vect" 
> { target { ! { vect_partial_vectors || vect32 } } } } }*/
> -/* { dg-final { scan-tree-dump-times "vectorizing stmts using SLP" 4 "vect" 
> { target { vect_partial_vectors || vect32 } } } } */
> +/* { dg-final { scan-tree-dump-times "vectorized 3 loops" 1 "vect" { target 
> { ! { vect_partial_vectors || vect32 } || s390_vx } } } } */
> +/* { dg-final { scan-tree-dump-times "vectorized 4 loops" 1 "vect" { target 
> { vect_partial_vectors || vect32 } && { ! s390_vx } } } } */
> +/* { dg-final { scan-tree-dump-times "vectorizing stmts using SLP" 3 "vect" 
> { target { ! { vect_partial_vectors || vect32 } || s390_vx } } } }*/
> +/* { dg-final { scan-tree-dump-times "vectorizing stmts using SLP" 4 "vect" 
> { target { vect_partial_vectors || vect32 } && { ! s390_vx } } } } */
>
> diff --git a/gcc/testsuite/gcc.dg/vect/slp-multitypes-11.c 
> b/gcc/testsuite/gcc.dg/vect/slp-multitypes-11.c
> index 96218861cd61..dbf93ee6bb37 100644
> --- a/gcc/testsuite/gcc.dg/vect/slp-multitypes-11.c
> +++ b/gcc/testsuite/gcc.dg/vect/slp-multitypes-11.c
> @@ -50,6 +50,6 @@ int main (void)
>
>  /* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect"  { target 
> vect_unpack } } } */
>  /* The epilogues are vectorized using partial vectors.  */
> -/* { dg-final { scan-tree-dump-times "vectorizing stmts using SLP" 1 "vect"  
> { target { vect_unpack && {! vect_partial_vectors_usage_1 } } xfail { 
> vect_variable_length && vect_load_lanes } } } } */
> -/* { dg-final { scan-tree-dump-times "vectorizing stmts using SLP" 2 "vect"  
> { target { vect_unpack && vect_partial_vectors_usage_1 } xfail { 
> vect_variable_length && vect_load_lanes } } } } */
> +/* { dg-final { scan-tree-dump-times "vectorizing stmts using SLP" 1 "vect"  
> { target { vect_unpack && { {! vect_partial_vectors_usage_1 } || s390_vx } } 
> xfail { vect_variable_length && vect_load_lanes } } } } */
> +/* { dg-final { scan-tree-dump-times "vectorizing stmts using SLP" 2 "vect"  
> { target { vect_unpack && vect_partial_vectors_usage_1 && { ! s390_vx } } 
> xfail { vect_variable_length && vect_load_lanes } } } } */
>
> diff --git a/gcc/testsuite/gcc.dg/vect/slp-perm-8.c 
> b/gcc/testsuite/gcc.dg/vect/slp-perm-8.c
> index 9e59832fb8b7..4023670d4459 100644
> --- a/gcc/testsuite/gcc.dg/vect/slp-perm-8.c
> +++ b/gcc/testsuite/gcc.dg/vect/slp-perm-8.c
> @@ -60,9 +60,9 @@ int main (int argc, const char* argv[])
>  }
>
>  /* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect" { target 
> { vect_perm_byte } } } } */
> -/* { dg-final { scan-tree-dump-times "vectorizing stmts using SLP" 1 "vect" 
> { target { vect_perm3_byte && { { ! vect_load_lanes } && {! 
> vect_partial_vectors_usage_1 } } } } } } */
> +/* { dg-final { scan-tree-dump-times "vectorizing stmts using SLP" 1 "vect" 
> { target { vect_perm3_byte && { { ! vect_load_lanes } && { {! 
> vect_partial_vectors_usage_1 } || s390_vx } } } } } } */
>  /* The epilogues are vectorized using partial vectors.  */
> -/* { dg-final { scan-tree-dump-times "vectorizing stmts using SLP" 2 "vect" 
> { target { vect_perm3_byte && { { ! vect_load_lanes } && 
> vect_partial_vectors_usage_1 } } } } } */
> +/* { dg-final { scan-tree-dump-times "vectorizing stmts using SLP" 2 "vect" 
> { target { vect_perm3_byte && { { ! vect_load_lanes } && 
> vect_partial_vectors_usage_1 && { ! s390_vx } } } } } } */
>  /* { dg-final { scan-tree-dump-times "vectorizing stmts using SLP" 0 "vect" 
> { target vect_load_lanes } } } */
>  /* { dg-final 

[PATCH] tree-optimization/109002 - partial PRE miscompilation

[Richard Biener via Gcc-patches]

Partial PRE ends up miscompiling the testcase in PR109002, likely
involving a corner case when inifinite loops are involved.  The
following avoids the miscompilation by addressing a long-standing
oddity that manifests in odd partial partial redundancies eliminated
that are full redundancies.  The oddity is that while we properly
PHI translate the PA_IN set from the successors when computing
PA_OUT but we fail to do the same for ANTIC_IN which is supposed
to be unioned.  That results in expressions with wrong virtual
operands being placed in the PA_OUT/IN sets and the pruning
machinery to go wrong because it assumes the expressions in the
sets have virtual operands that are valid in the respective blocks.

Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.

PR tree-optimization/109002
* tree-ssa-pre.cc (compute_partial_antic_aux): Properly
PHI-translate ANTIC_IN.

* gcc.dg/torture/pr109002.c: New testcase.
---
 gcc/testsuite/gcc.dg/torture/pr109002.c | 27 +
 gcc/tree-ssa-pre.cc | 20 --
 2 files changed, 41 insertions(+), 6 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/torture/pr109002.c

diff --git a/gcc/testsuite/gcc.dg/torture/pr109002.c 
b/gcc/testsuite/gcc.dg/torture/pr109002.c
new file mode 100644
index 000..5575a4b9edc
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/torture/pr109002.c
@@ -0,0 +1,27 @@
+/* { dg-do run } */
+/* { dg-additional-options "-ftree-pre -ftree-partial-pre" } */
+
+extern void exit (int);
+
+int g;
+int h;
+
+void __attribute__((noipa)) bar ()
+{
+  if (g)
+exit (0);
+}
+
+int main(void)
+{
+  for (int i = 0; ; i++) {
+  for (int j = 0; j < g; j++);
+  if (i & 1) {
+ if (h)
+   continue;
+ if (g)
+   bar ();
+ g = 1;
+  }
+  }
+}
diff --git a/gcc/tree-ssa-pre.cc b/gcc/tree-ssa-pre.cc
index f77732d75c3..37cad36f2de 100644
--- a/gcc/tree-ssa-pre.cc
+++ b/gcc/tree-ssa-pre.cc
@@ -2364,11 +2364,14 @@ compute_partial_antic_aux (basic_block block,
  unsigned int i;
  bitmap_iterator bi;
 
- FOR_EACH_EXPR_ID_IN_SET (ANTIC_IN (e->dest), i, bi)
-   bitmap_value_insert_into_set (PA_OUT,
- expression_for_id (i));
  if (!gimple_seq_empty_p (phi_nodes (e->dest)))
{
+ bitmap_set_t antic_in = bitmap_set_new ();
+ phi_translate_set (antic_in, ANTIC_IN (e->dest), e);
+ FOR_EACH_EXPR_ID_IN_SET (antic_in, i, bi)
+   bitmap_value_insert_into_set (PA_OUT,
+ expression_for_id (i));
+ bitmap_set_free (antic_in);
  bitmap_set_t pa_in = bitmap_set_new ();
  phi_translate_set (pa_in, PA_IN (e->dest), e);
  FOR_EACH_EXPR_ID_IN_SET (pa_in, i, bi)
@@ -2377,9 +2380,14 @@ compute_partial_antic_aux (basic_block block,
  bitmap_set_free (pa_in);
}
  else
-   FOR_EACH_EXPR_ID_IN_SET (PA_IN (e->dest), i, bi)
- bitmap_value_insert_into_set (PA_OUT,
-   expression_for_id (i));
+   {
+ FOR_EACH_EXPR_ID_IN_SET (ANTIC_IN (e->dest), i, bi)
+   bitmap_value_insert_into_set (PA_OUT,
+ expression_for_id (i));
+ FOR_EACH_EXPR_ID_IN_SET (PA_IN (e->dest), i, bi)
+   bitmap_value_insert_into_set (PA_OUT,
+ expression_for_id (i));
+   }
}
}
 }
-- 
2.35.3

Re: [PATCH] swap: Fix incorrect lane extraction by vec_extract() [PR106770]

[Surya Kumari Jangala via Gcc-patches]

On 27/02/23 9:58 pm, Segher Boessenkool wrote:
> Hi!
> 
> On Wed, Jan 04, 2023 at 01:58:19PM +0530, Surya Kumari Jangala wrote:
>> In the routine rs6000_analyze_swaps(), special handling of swappable
>> instructions is done even if the webs that contain the swappable
>> instructions are not optimized, i.e., the webs do not contain any
>> permuting load/store instructions along with the associated register
>> swap instructions. Doing special handling in such webs will result in
>> the extracted lane being adjusted unnecessarily for vec_extract.
>>
>> Modifying swappable instructions is also incorrect in webs where
>> loads/stores on quad word aligned addresses are changed to lvx/stvx.
>> Similarly, in webs where swap(load(vector constant)) instructions are
>> replaced with load(swapped vector constant), the swappable
>> instructions should not be modified.
>>
>> 2023-01-04  Surya Kumari Jangala  
>>
>> gcc/
>>  PR rtl-optimization/106770
>>  * rs6000-p8swap.cc (rs6000_analyze_swaps): .
> 
> Please add an entry?  Or multiple ones, actually.  Describe all changes.
Ok

> 
>> --- a/gcc/config/rs6000/rs6000-p8swap.cc
>> +++ b/gcc/config/rs6000/rs6000-p8swap.cc
>> @@ -179,6 +179,9 @@ class swap_web_entry : public web_entry_base
>>unsigned int special_handling : 4;
>>/* Set if the web represented by this entry cannot be optimized.  */
>>unsigned int web_not_optimizable : 1;
>> +  /* Set if the web represented by this entry has been optimized, ie,
> 
> s/ie/i.e./
> 
>> + register swaps of permuting loads/stores have been removed.  */
> 
> If it really means only exactly this, then the name isn't so good.

There is another bit in this class named "web_not_optimizable". This stands for 
webs that cannot be optimized. I am reusing this name for the new bit I am 
adding, and I have named this bit as "web_is_optimized".

> 
>> +  unsigned int web_is_optimized : 1;
> 
> And if it is as general as the name suggests, then the comment is no
> good.  Which is it?  :-)
> 
>>/* For each load and store in an optimizable web (which implies
>>   the loads and stores are permuting), find the associated
>>   register swaps and mark them for removal.  Due to various
>> - optimizations we may mark the same swap more than once.  Also
>> - perform special handling for swappable insns that require it.  */
>> + optimizations we may mark the same swap more than once. Fix up
>> + the non-permuting loads and stores by converting them into
>> + permuting ones.  */
> 
> Two spaces after a full stop is correct.  Please put that back.
Ok

> 
> Is it a good idea convert from/to swapping load/stores in this pass at
> all?  Doesdn't that belong elsewhere?  Like, in combine, where we
> already should do this.  Why does that not work> 
>> -if (!root_entry->web_not_optimizable)
>> +if (!root_entry->web_not_optimizable) {
> 
> Blocks start on a new line, indented.
Ok

> 
>>mark_swaps_for_removal (insn_entry, i);
>> +  root_entry->web_is_optimized = true;
> 
> Indent using tabs where possible.
Ok

> 
>> +swap_web_entry* root_entry
>> +  = (swap_web_entry*)((_entry[i])->unionfind_root ());
> 
> Space before *, in all cases. Space before the second (.  There are too
> many brackets here, too.
Ok

> 
>> +  /* Perform special handling for swappable insns that require it. 
> 
> No trailing spaces.
Ok

> 
>> + Note that special handling should be done only for those 
>> + swappable insns that are present in webs optimized above.  */
>> +  for (i = 0; i < e; ++i)
>> +if (insn_entry[i].is_swappable && insn_entry[i].special_handling &&
>> +!(insn_entry[i].special_handling == SH_NOSWAP_LD || 
>> +  insn_entry[i].special_handling == SH_NOSWAP_ST))
>>{
>>  swap_web_entry* root_entry
>>= (swap_web_entry*)((_entry[i])->unionfind_root ());
>> -if (!root_entry->web_not_optimizable)
>> +if (root_entry->web_is_optimized)
>>handle_special_swappables (insn_entry, i);
>>}
> 
> Why this change?

The swap pass analyzes vector computations and removes unnecessary doubleword 
swaps (xxswapdi instructions). The swap pass first constructs webs and removes 
swap instructions if possible. If the web contains operations that are 
sensitive to element order (ie, insns requiring special handling), such as an 
extract, then such instructions should be modified. For example, for an extract 
operation the lane is changed.
However, the swap pass is changing element order of an extract operation that 
is present in unoptimized webs. Unoptimized webs are those for which register 
swaps were not removed, one of the reasons being that there are no loads/stores 
present in this web. For such webs, element order of extract operation should 
not be changed.
Hence, we first mark webs that can be optimized, and only for such webs we call 
the routine handle_special_swappables() to modify operations sensitive to 
element order.

[PATCH] waccess: Fix two -Wnonnull warning issues [PR108986]

[Jakub Jelinek via Gcc-patches]

Hi!

The following patch fixes 2 issues with the -Wnonnull warning.

One, fixed by the second hunk, is that the warning wording is bogus
since r11-3305, instead of printing
warning: argument 1 to ‘int[static 7]’ is null where non-null expected 
[-Wnonnull]
it prints
warning: argument 1 to ‘int[static 28]’ is null where non-null expected 
[-Wnonnull]
access_size is measured in bytes, so obviously will be correct as array
number of elements only if it is 1 byte element array.
In the function, access_nelts is either constant (if sizidx == -1) or
when the array size is determined by some other parameter, I believe a value
passed to that argument.
Later on we query the range of it:
  if (get_size_range (m_ptr_qry.rvals, access_nelts, stmt, sizrng, 1))
which I bet must just return accesS_nelts in sizrng[0] and [1] if it is
constant.  access_size is later computed as:
  tree access_size = NULL_TREE;
  if (tree_int_cst_sgn (sizrng[0]) >= 0)
{
  if (COMPLETE_TYPE_P (argtype))
{
...
wide_int minsize = wi::to_wide (sizrng[0], prec);
minsize *= wi::to_wide (argsize, prec);
access_size = wide_int_to_tree (sizetype, minsize);
  }
}
  else
access_size = access_nelts;
}
and immediately after this the code does:
  if (integer_zerop (ptr))
{
  if (sizidx >= 0 && tree_int_cst_sgn (sizrng[0]) > 0)
{
some other warning wording
}
  else if (access_size && access.second.static_p)
{
this spot
}
}
So, because argtype is complete, access_size has been multiplied by
argsize, but in case of this exact warning ("this spot" above)
I believe access_nelts must be really constant, otherwise
"some other warning wording" would handle it.  So, I think access_nelts
is exactly what we want to print there.

The other problem is that since the introduction of -Wdangling-pointer
in r12-6606, the pass has early and late instances and while lots of
stuff in the pass is guarded on being done in the late pass only,
this particular function is not, furthermore it is emitting two different
warnings in a loop and already messes up with stuff like clearing
warning suppression for one of the warning (ugh!).  The end effect is
that we warn twice about the same problem, once in the early and once in
the late pass.  Now, e.g. with -O2 -Wall we warn just once, during the
early pass, as it is then optimized away, so I think just making this
late warning only wouldn't be best.  This patch instead returns early
if either of the warnings is suppressed on the call stmt already.
I think if one of the passes warned on it already (even if say on some other
argument), then warning again (even on some other argument) is unnecessary,
if both problems are visible in the same pass we'll still warn about both.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

2023-03-03  Jakub Jelinek  

PR c/108986
* gimple-ssa-warn-access.cc (pass_waccess::maybe_check_access_sizes):
Return immediately if OPT_Wnonnull or OPT_Wstringop_overflow_ is
suppressed on stmt.  For [static %E] warning, print access_nelts
rather than access_size.  Fix up comment wording.

* gcc.dg/Wnonnull-8.c: New test.

--- gcc/gimple-ssa-warn-access.cc.jj2023-02-22 20:50:27.418519815 +0100
+++ gcc/gimple-ssa-warn-access.cc   2023-03-02 19:04:24.744280016 +0100
@@ -3318,6 +3318,10 @@ void
 pass_waccess::maybe_check_access_sizes (rdwr_map *rwm, tree fndecl, tree 
fntype,
gimple *stmt)
 {
+  if (warning_suppressed_p (stmt, OPT_Wnonnull)
+  || warning_suppressed_p (stmt, OPT_Wstringop_overflow_))
+return;
+
   auto_diagnostic_group adg;
 
   /* Set if a warning has been issued for any argument (used to decide
@@ -3501,7 +3505,7 @@ pass_waccess::maybe_check_access_sizes (
  if (warning_at (loc, OPT_Wnonnull,
  "argument %i to %<%T[static %E]%> "
  "is null where non-null expected",
- ptridx + 1, argtype, access_size))
+ ptridx + 1, argtype, access_nelts))
arg_warned = OPT_Wnonnull;
}
 
@@ -3593,7 +3597,7 @@ pass_waccess::maybe_check_access_sizes (
"in a call with type %qT", fntype);
 }
 
-  /* Set the bit in case if was cleared and not set above.  */
+  /* Set the bit in case it was cleared and not set above.  */
   if (opt_warned != no_warning)
 suppress_warning (stmt, opt_warned);
 }
--- gcc/testsuite/gcc.dg/Wnonnull-8.c.jj2023-03-02 17:28:24.323898410 
+0100
+++ gcc/testsuite/gcc.dg/Wnonnull-8.c   2023-03-02 17:27:51.804376322 +0100
@@ -0,0 +1,14 @@
+/* PR c/108986 */
+/* { dg-do compile } */
+/* { dg-options "-Wall" } */
+
+void
+foo (int a[static 7])
+{
+}
+
+int
+main ()

Re: [PATCH] gimple-fold: Fix up fputs -> fwrite folding [PR108988]

[Richard Biener via Gcc-patches]

On Fri, 3 Mar 2023, Jakub Jelinek wrote:

> Hi!
> 
> gimple_fold_builtin_fputs when folding fputs into fwrite emits the third
> argument (INTEGER_CST) with incorrect type - get_maxval_strlen or c_strlen
> return ssizetype, while fwrite argument is size_type_node.
> The following patch fixes that, I've skimmed through the rest of
> gimple-fold.cc and in all other places get_maxval_strlen/c_strlen result
> was fold_converted to size_type_node already (or GIMPLE cast stmt has been
> emitted directly etc.).
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

OK.

> 2023-03-03  Jakub Jelinek  
> 
>   PR tree-optimization/108988
>   * gimple-fold.cc (gimple_fold_builtin_fputs): Fold len to
>   size_type_node before passing it as argument to fwrite.  Formatting
>   fixes.
> 
> --- gcc/gimple-fold.cc.jj 2023-02-28 11:38:28.957868160 +0100
> +++ gcc/gimple-fold.cc2023-03-02 10:34:42.791504589 +0100
> @@ -2954,8 +2954,7 @@ gimple_fold_builtin_fputs (gimple_stmt_i
>/* Get the length of the string passed to fputs.  If the length
>   can't be determined, punt.  */
>tree len = get_maxval_strlen (arg0, SRK_STRLEN);
> -  if (!len
> -  || TREE_CODE (len) != INTEGER_CST)
> +  if (!len || TREE_CODE (len) != INTEGER_CST)
>  return false;
>  
>switch (compare_tree_int (len, 1))
> @@ -2972,9 +2971,10 @@ gimple_fold_builtin_fputs (gimple_stmt_i
>   if (!fn_fputc)
> return false;
>  
> - gimple *repl = gimple_build_call (fn_fputc, 2,
> -  build_int_cst
> -  (integer_type_node, p[0]), arg1);
> + gimple *repl
> +   = gimple_build_call (fn_fputc, 2,
> +build_int_cst (integer_type_node, p[0]),
> +arg1);
>   replace_call_with_call_and_fold (gsi, repl);
>   return true;
> }
> @@ -2990,8 +2990,9 @@ gimple_fold_builtin_fputs (gimple_stmt_i
>   if (!fn_fwrite)
> return false;
>  
> - gimple *repl = gimple_build_call (fn_fwrite, 4, arg0,
> -  size_one_node, len, arg1);
> + gimple *repl
> +   = gimple_build_call (fn_fwrite, 4, arg0, size_one_node,
> +fold_convert (size_type_node, len), arg1);
>   replace_call_with_call_and_fold (gsi, repl);
>   return true;
>}
> 
>   Jakub
> 
> 

-- 
Richard Biener 
SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg,
Germany; GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman;
HRB 36809 (AG Nuernberg)

Re: [PATCHv2, gfortran] Escalate failure when Hollerith constant to real conversion fails [PR103628]

[HAO CHEN GUI via Gcc-patches]

Hi Tobias,

在 2023/3/3 17:29, Tobias Burnus 写道:
> But could you also include the 'gcc/fortran/intrinsic.cc' change
> proposed in
> https://gcc.gnu.org/pipermail/gcc-patches/2023-March/613030.html (and
> acknowledged by Steve)? 

Sure, I will merge it into the patch and do the regression test.

Additionally, Kewen suggested:
>> Since this test case is powerpc only, I think it can be moved to 
>> gcc/testsuite/gcc.target/powerpc/ppc-fortran.
> 
> Which sounds reasonable.

Test cases under gcc.target are tested by check-gcc-c. It greps "warning"
and "error" (C style, lower case) from the output while check-gcc-fortran
greps "Warning" and "Error" (upper case). As the test case needs to check
the "Warning" and "Error" messages. I have to put it in gfortran.dg
directory. What's your opinion?

Gui Haochen
Thanks

Re: [PATCH] libstdc++: Update Solaris baselines for GCC 13.0

[Jonathan Wakely via Gcc-patches]

On Tue, 21 Feb 2023 at 08:34, Rainer Orth wrote:

> This patch updates the libstdc++ Solaris baselines for GCC 13.
>
> Tested on i386-pc-solaris2.11 and sparc-sun-solaris2.11 (Solaris 11.3
> and 11.4).
>
> Ok for trunk?
>

OK, thanks.

Re: [libstdc++] Use __gthread_join in jthread/95989

[Jonathan Wakely via Gcc-patches]

On Fri, 3 Mar 2023 at 09:33, Jonathan Wakely  wrote:

>
>
> On Fri, 3 Mar 2023 at 08:20, Alexandre Oliva via Libstdc++ <
> libstd...@gcc.gnu.org> wrote:
>
>> On Feb 17, 2023, Jonathan Wakely  wrote:
>>
>> > The proper fix is to ensure the program has a non-weak reference to
>> > pthread_join without extra help (or use a recent glibc where it always
>> > works).
>>
>> Indeed!  How about this?  Regstrapped on x86_64-linux-gnu, also tested
>> on arm-vx7r2 (gcc-12); verified that strong references are present in
>> 95989.o, but not in libstdc++.a or .so.  Ok to install?
>>
>> (nit: the static local in a ctor of a template class may make for
>> multiple copies.  Maybe a non-template always-inline function called by
>> all instantiations would be better.)
>>
>
> Yeah, that does seem less than ideal.
>
> Jakub previously suggested doing this for PR 61841, which was a similar
> problem with pthread_create:
>
> __asm ("" : : "r" (_create)); would not be optimized away.
>
>
> That would avoid the multiple copies.
>

As Jakub pointed out, it adds a scheduling barrier, but a few cycles when
creating a new thread is probably not even measurable.


>
> Alternatively we could get really creative and cast the addresses of both
> _create and _join to uintptr_t and XOR them, and pass that
> as the __depend argument (which is never actually dereferenced, it's only
> there to create a link-time dependency).
>

I should be clear that I don't think the creative solution is a good idea.
And if we ever support building libstdc++ with LTO it will become visible
that the argument is unused, and we'd need something like the asm
dependency anyway.



>
>
>
>>
>>
>> link pthread_join from std::thread ctor
>>
>> Like pthread_create, pthread_join may fail to be statically linked in
>> absent strong uses, so add to user code strong references to both when
>> std::thread objects are created.
>>
>>
>> for  libstdc++-v3/ChangeLog
>>
>> * include/bits/std_thread.h (std::thread ctor): Add strong
>> reference to pthread_join.
>>
>> ---
>>  libstdc++-v3/include/bits/std_thread.h |1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/libstdc++-v3/include/bits/std_thread.h
>> b/libstdc++-v3/include/bits/std_thread.h
>> index adbd3928ff783..4bda350fa2c7b 100644
>> --- a/libstdc++-v3/include/bits/std_thread.h
>> +++ b/libstdc++-v3/include/bits/std_thread.h
>> @@ -145,6 +145,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>>  #ifdef GTHR_ACTIVE_PROXY
>> // Create a reference to pthread_create, not just the gthr weak
>> symbol.
>> auto __depend = reinterpret_cast(_create);
>> +   static auto __attribute__((__used__)) __depend_join =
>> _join;
>>  #else
>> auto __depend = nullptr;
>>  #endif
>>
>>
>> --
>> Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
>>Free Software Activist   GNU Toolchain Engineer
>> Disinformation flourishes because many people care deeply about injustice
>> but very few check the facts.  Ask me about 
>>
>>

[PATCH] gimple-fold: Fix up fputs -> fwrite folding [PR108988]

[Jakub Jelinek via Gcc-patches]

Hi!

gimple_fold_builtin_fputs when folding fputs into fwrite emits the third
argument (INTEGER_CST) with incorrect type - get_maxval_strlen or c_strlen
return ssizetype, while fwrite argument is size_type_node.
The following patch fixes that, I've skimmed through the rest of
gimple-fold.cc and in all other places get_maxval_strlen/c_strlen result
was fold_converted to size_type_node already (or GIMPLE cast stmt has been
emitted directly etc.).

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

2023-03-03  Jakub Jelinek  

PR tree-optimization/108988
* gimple-fold.cc (gimple_fold_builtin_fputs): Fold len to
size_type_node before passing it as argument to fwrite.  Formatting
fixes.

--- gcc/gimple-fold.cc.jj   2023-02-28 11:38:28.957868160 +0100
+++ gcc/gimple-fold.cc  2023-03-02 10:34:42.791504589 +0100
@@ -2954,8 +2954,7 @@ gimple_fold_builtin_fputs (gimple_stmt_i
   /* Get the length of the string passed to fputs.  If the length
  can't be determined, punt.  */
   tree len = get_maxval_strlen (arg0, SRK_STRLEN);
-  if (!len
-  || TREE_CODE (len) != INTEGER_CST)
+  if (!len || TREE_CODE (len) != INTEGER_CST)
 return false;
 
   switch (compare_tree_int (len, 1))
@@ -2972,9 +2971,10 @@ gimple_fold_builtin_fputs (gimple_stmt_i
if (!fn_fputc)
  return false;
 
-   gimple *repl = gimple_build_call (fn_fputc, 2,
-build_int_cst
-(integer_type_node, p[0]), arg1);
+   gimple *repl
+ = gimple_build_call (fn_fputc, 2,
+  build_int_cst (integer_type_node, p[0]),
+  arg1);
replace_call_with_call_and_fold (gsi, repl);
return true;
  }
@@ -2990,8 +2990,9 @@ gimple_fold_builtin_fputs (gimple_stmt_i
if (!fn_fwrite)
  return false;
 
-   gimple *repl = gimple_build_call (fn_fwrite, 4, arg0,
-size_one_node, len, arg1);
+   gimple *repl
+ = gimple_build_call (fn_fwrite, 4, arg0, size_one_node,
+  fold_convert (size_type_node, len), arg1);
replace_call_with_call_and_fold (gsi, repl);
return true;
   }

Jakub

[PATCH] diagnostics: Fix up selftests with $COLUMNS < 42 [PR108973]

[Jakub Jelinek via Gcc-patches]

Hi!

As mentioned in the PR, GCC's diagnostics self-tests fail if $COLUMNS < 42.
Guarding each self-test with if (get_terminal_width () > 41) or similar
would be a maintainance nightmare (PR has a patch to do so without
reformatting to make it work for $COLUMNS in [30, 41] inclusive, but
I'm afraid going down to $COLUMNS 1 would mean marking everything).
Furthermore, the self-tests don't really emit stuff to the terminal,
but into a buffer, so using get_terminal_width () for it seems
inappropriate.  The following patch makes sure test_diagnostic_context
constructor uses at least 80 columns wide caret max width, of course
some tests override it already if they want to test for behavior in narrower
cases.

Bootstrapped/regtested on x86_64-linux and i686-linux, plus tested
on self-tests with $COLUMNS down to 1, ok for trunk?

2023-03-03  Jakub Jelinek  

PR testsuite/108973
* selftest-diagnostic.cc
(test_diagnostic_context::test_diagnostic_context): Ensure
caret_max_width isn't smaller than 80.

--- gcc/selftest-diagnostic.cc.jj   2023-01-02 09:32:31.991146491 +0100
+++ gcc/selftest-diagnostic.cc  2023-03-02 10:05:17.974321025 +0100
@@ -41,6 +41,7 @@ test_diagnostic_context::test_diagnostic
   show_column = true;
   start_span = start_span_cb;
   min_margin_width = 6;
+  caret_max_width = MAX (caret_max_width, 80);
 }
 
 test_diagnostic_context::~test_diagnostic_context ()

Jakub

Re: [libstdc++] Use __gthread_join in jthread/95989

[Jonathan Wakely via Gcc-patches]

On Fri, 3 Mar 2023 at 08:20, Alexandre Oliva via Libstdc++ <
libstd...@gcc.gnu.org> wrote:

> On Feb 17, 2023, Jonathan Wakely  wrote:
>
> > The proper fix is to ensure the program has a non-weak reference to
> > pthread_join without extra help (or use a recent glibc where it always
> > works).
>
> Indeed!  How about this?  Regstrapped on x86_64-linux-gnu, also tested
> on arm-vx7r2 (gcc-12); verified that strong references are present in
> 95989.o, but not in libstdc++.a or .so.  Ok to install?
>
> (nit: the static local in a ctor of a template class may make for
> multiple copies.  Maybe a non-template always-inline function called by
> all instantiations would be better.)
>

Yeah, that does seem less than ideal.

Jakub previously suggested doing this for PR 61841, which was a similar
problem with pthread_create:

__asm ("" : : "r" (_create)); would not be optimized away.


That would avoid the multiple copies.

Alternatively we could get really creative and cast the addresses of both
_create and _join to uintptr_t and XOR them, and pass that
as the __depend argument (which is never actually dereferenced, it's only
there to create a link-time dependency).



>
>
> link pthread_join from std::thread ctor
>
> Like pthread_create, pthread_join may fail to be statically linked in
> absent strong uses, so add to user code strong references to both when
> std::thread objects are created.
>
>
> for  libstdc++-v3/ChangeLog
>
> * include/bits/std_thread.h (std::thread ctor): Add strong
> reference to pthread_join.
>
> ---
>  libstdc++-v3/include/bits/std_thread.h |1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/libstdc++-v3/include/bits/std_thread.h
> b/libstdc++-v3/include/bits/std_thread.h
> index adbd3928ff783..4bda350fa2c7b 100644
> --- a/libstdc++-v3/include/bits/std_thread.h
> +++ b/libstdc++-v3/include/bits/std_thread.h
> @@ -145,6 +145,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>  #ifdef GTHR_ACTIVE_PROXY
> // Create a reference to pthread_create, not just the gthr weak
> symbol.
> auto __depend = reinterpret_cast(_create);
> +   static auto __attribute__((__used__)) __depend_join =
> _join;
>  #else
> auto __depend = nullptr;
>  #endif
>
>
> --
> Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
>Free Software Activist   GNU Toolchain Engineer
> Disinformation flourishes because many people care deeply about injustice
> but very few check the facts.  Ask me about 
>
>

Re: [PATCH] libgccjit: Fix a failing test

[Guillaume Gomez via Gcc-patches]

Thanks!

Le jeu. 2 mars 2023 à 23:54, David Malcolm  a écrit :

> On Thu, 2023-03-02 at 23:35 +0100, Guillaume Gomez wrote:
> > I don't have push rights so if you could push it, it'd be super
> > appreciated!
>
> Done, as r13-6425-g6b432c0f777ab9; I took the liberty of slightly
> tweaking the subject line to add a "jit, testsuite: " prefix.
>
> Thanks again for the patch
> Dave
>
>

Re: [PATCHv2, gfortran] Escalate failure when Hollerith constant to real conversion fails [PR103628]

[Tobias Burnus]

Hi Haochen,

thanks for fixing 'gcc/fortran/target-memory.cc'.

But could you also include the 'gcc/fortran/intrinsic.cc' change
proposed in
https://gcc.gnu.org/pipermail/gcc-patches/2023-March/613030.html (and
acknowledged by Steve)?

This will replace "Unclassifiable statement" by "Cannot simplify
expression" which is a bit more helpful.

(After doing so, at least the dg-error in your testcase needs to be
updated; I assume that it won't affect other testcases, but that needs
to be checked. – And you should update the comment in the testcase as
well - and in text you will put in the commit log, if applicable.)

Additionally, Kewen suggested:

Since this test case is powerpc only, I think it can be moved to 
gcc/testsuite/gcc.target/powerpc/ppc-fortran.


Which sounds reasonable.


Otherwise it looks good to me.

On 03.03.23 10:12, HAO CHEN GUI wrote:

Hi,
   The patch escalates the failure when Hollerith constant to real conversion
fails in native_interpret_expr. It finally reports an "Unclassifiable
statement" error.

   The patch of pr95450 added a verification for decoding/encoding checking
in native_interpret_expr. native_interpret_expr may fail on real type
conversion and returns a NULL tree then. But upper layer calls don't handle
the failure so that an ICE is reported when the verification fails.

   IBM long double is an example. It doesn't have a unique memory presentation
for some real values. So it may not pass the verification. The new test
case shows the problem.

   Compared to last version, this version moves the mpfr_init after NULL tree
test and fixes the format problem according to Tobias's advice. Thanks a lot.


(The format issue was actually spotted by Bernhard.)

Thanks for working on this!

Tobias

PS: One can also discuss Steve's suggestion about deprecating Holleriths / 
guarding
the support behind some flag. But I think that's unrelated to this bug fix 
patch and
should be discussed/done separately.



ChangeLog
2023-03-01  Haochen Gui 

gcc/
  PR target/103628
  * fortran/target-memory.cc (gfc_interpret_float): Return FAIL when
  native_interpret_expr gets a NULL tree.
  * fortran/arith.cc (gfc_hollerith2real): Return NULL when
  gfc_interpret_float fails.

gcc/testsuite/
  PR target/103628
  * gfortran.dg/pr103628.f90: New.

patch.diff
diff --git a/gcc/fortran/arith.cc b/gcc/fortran/arith.cc
index c0d12cfad9d..d3d38c7eb6a 100644
--- a/gcc/fortran/arith.cc
+++ b/gcc/fortran/arith.cc
@@ -2752,10 +2752,12 @@ gfc_hollerith2real (gfc_expr *src, int kind)
result = gfc_get_constant_expr (BT_REAL, kind, >where);

hollerith2representation (result, src);
-  gfc_interpret_float (kind, (unsigned char *) result->representation.string,
-result->representation.length, result->value.real);
-
-  return result;
+  if (gfc_interpret_float (kind,
+(unsigned char *) result->representation.string,
+result->representation.length, result->value.real))
+return result;
+  else
+return NULL;
  }

  /* Convert character to real.  The constant will be padded or truncated.  */
diff --git a/gcc/fortran/target-memory.cc b/gcc/fortran/target-memory.cc
index 7ce7d736629..0c47aa6b842 100644
--- a/gcc/fortran/target-memory.cc
+++ b/gcc/fortran/target-memory.cc
@@ -416,11 +416,14 @@ gfc_interpret_float (int kind, unsigned char *buffer, 
size_t buffer_size,
   mpfr_t real)
  {
gfc_set_model_kind (kind);
-  mpfr_init (real);
-  gfc_conv_tree_to_mpfr (real,
-  native_interpret_expr (gfc_get_real_type (kind),
- buffer, buffer_size));

+  tree source = native_interpret_expr (gfc_get_real_type (kind), buffer,
+buffer_size);
+  if (!source)
+return 0;
+
+  mpfr_init (real);
+  gfc_conv_tree_to_mpfr (real, source);
return size_float (kind);
  }

diff --git a/gcc/testsuite/gfortran.dg/pr103628.f90 
b/gcc/testsuite/gfortran.dg/pr103628.f90
new file mode 100644
index 000..e49aefc18fd
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr103628.f90
@@ -0,0 +1,14 @@
+! { dg-do compile { target powerpc*-*-* } }
+! { dg-options "-O2 -mabi=ibmlongdouble" }
+
+! Test to ensure that it reports an "Unclassifiable statement" error
+! instead of throwing an ICE when the memory represent of the HOLLERITH
+! string is not unique with ibm long double encoding.
+
+program main
+  integer, parameter :: k = 16
+  real(kind = k):: b = 4h1234
+end program main
+
+! { dg-warning "Conversion from HOLLERITH" "warning" { target powerpc*-*-* } 
10 }
+! { dg-error "Unclassifiable statement" "error" { target powerpc*-*-* } 10 }

-
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] [arm] adjust tests for quotes around +cdecp

[Kyrylo Tkachov via Gcc-patches]

> -Original Message-
> From: Gcc-patches  bounces+kyrylo.tkachov=arm@gcc.gnu.org> On Behalf Of Alexandre
> Oliva via Gcc-patches
> Sent: Friday, March 3, 2023 8:24 AM
> To: Christophe Lyon 
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH] [arm] adjust tests for quotes around +cdecp
> 
> Hello, Christophe,
> 
> On Feb 22, 2023, Christophe Lyon  wrote:
> 
> > OK thanks for the clarification.
> 
> > (and for the other cleanup patches!)
> 
> Was this meant as approval?  I hadn't taken it as such.
> 

This is ok. I would have considered it an obvious patch 
Thanks,
Kyrill

> Otherwise, please consider this a ping :-)
> https://gcc.gnu.org/pipermail/gcc-patches/2023-February/612188.html
> 
> Thanks,
> 
> --
> Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
>Free Software Activist   GNU Toolchain Engineer
> Disinformation flourishes because many people care deeply about injustice
> but very few check the facts.  Ask me about 

RE: [PATCH] [arm] adjust expectations for armv8_2-fp16-move-[12].c

[Kyrylo Tkachov via Gcc-patches]

> -Original Message-
> From: Alexandre Oliva 
> Sent: Friday, February 17, 2023 7:12 AM
> To: gcc-patches@gcc.gnu.org
> Cc: ni...@redhat.com; Richard Earnshaw 
> Subject: [PATCH] [arm] adjust expectations for armv8_2-fp16-move-[12].c
> 
> 
> Commit 3a7ba8fd0cda387809e4902328af2473662b6a4a, a patch for
> tree-ssa-sink, enabled the removal of basic blocks in ways that
> affected the generated code for both of these tests, deviating from
> the expectations of the tests.
> 
> The simplest case is that of -2, in which the edge unsplitting ends up
> enabling a conditional return rather than a conditional branch to a
> set-and-return block.  That looks like an improvement to me, but the
> condition in which the branch or the return takes place can be
> reasonably reversed (and, with the current code, it is), I've relaxed
> the pattern in the test so as to accept reversed and unreversed
> conditions applied to return or branch opcodes.
> 
> The situation in -1 is a little more elaborate: conditional branches
> based on FP compares in test_select_[78] are initially expanded with
> CCFPE compare-and-cbranch on G{T,E}, but when ce2 turns those into a
> cmove, because now we have a different fallthrough block, the
> condition is reversed, and that lands us with a compare-and-cmove
> sequence that needs CCFP for UNL{E,T}.  The insn output reverses the
> condition and swaps the cmove input operands, so the vcmp and vsel
> insns come out the same except for the missing 'e' (for the compare
> mode) in vcmp, so, since such reversals could have happened to any of
> the tests depending on legitimate basic block layout, I've combined
> the vcmp and vcmpe counts.
> 
> I see room for improving cmove sequence generation, e.g. trying direct
> and reversed conditions and selecting the cheapest one (which would
> require CCFP conditions to be modeled as more expensive than CCFPE),
> or for some other machine-specific (peephole2?) optimization to turn
> CCFP-requiring compare and cmove into CCFPE compare and swapped-
> inputs
> cmove, but I haven't tried that.
> 
> Regstrapped on x86_64-linux-gnu.
> Tested on arm-vxworks7 (gcc-12) and arm-eabi (trunk).  Ok to install?

The changes in the patch are okay for now. We can look at other improvements 
separately.
Thanks,
Kyrill

> 
> for  gcc/testsuite/ChangeLog
> 
>   * gcc.target/arm/armv8_2-fp16-move-1.c: Combine vcmp and vcmpe
>   expected counts into a single pattern.
>   * gcc.target/arm/armv8_2-fp16-move-2.c: Accept conditional
>   return and reversed conditions.
> ---
>  gcc/testsuite/gcc.target/arm/armv8_2-fp16-move-1.c |3 +--
>  gcc/testsuite/gcc.target/arm/armv8_2-fp16-move-2.c |2 +-
>  2 files changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/gcc/testsuite/gcc.target/arm/armv8_2-fp16-move-1.c
> b/gcc/testsuite/gcc.target/arm/armv8_2-fp16-move-1.c
> index 009bb8d1575a4..444c4a3353555 100644
> --- a/gcc/testsuite/gcc.target/arm/armv8_2-fp16-move-1.c
> +++ b/gcc/testsuite/gcc.target/arm/armv8_2-fp16-move-1.c
> @@ -196,5 +196,4 @@ test_compare_5 (__fp16 a, __fp16 b)
>  /* { dg-final { scan-assembler-not {vcmp\.f16} } }  */
>  /* { dg-final { scan-assembler-not {vcmpe\.f16} } }  */
> 
> -/* { dg-final { scan-assembler-times {vcmp\.f32} 4 } }  */
> -/* { dg-final { scan-assembler-times {vcmpe\.f32} 8 } }  */
> +/* { dg-final { scan-assembler-times {vcmpe?\.f32} 12 } }  */
> diff --git a/gcc/testsuite/gcc.target/arm/armv8_2-fp16-move-2.c
> b/gcc/testsuite/gcc.target/arm/armv8_2-fp16-move-2.c
> index fcb857f29ff15..dff57ac8147c2 100644
> --- a/gcc/testsuite/gcc.target/arm/armv8_2-fp16-move-2.c
> +++ b/gcc/testsuite/gcc.target/arm/armv8_2-fp16-move-2.c
> @@ -8,4 +8,4 @@ test_select (__fp16 a, __fp16 b, __fp16 c)
>  {
>return (a < b) ? b : c;
>  }
> -/* { dg-final { scan-assembler "bmi" } } */
> +/* { dg-final { scan-assembler "bx?(mi|pl)" } } */
> 
> --
> Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
>Free Software Activist   GNU Toolchain Engineer
> Disinformation flourishes because many people care deeply about injustice
> but very few check the facts.  Ask me about 

Re: [PATCHv2, gfortran] Escalate failure when Hollerith constant to real conversion fails [PR103628]

[HAO CHEN GUI via Gcc-patches]

Hi,
  The patch passed regression test on Power linux platforms. Sorry for missing
the information.

Gui Haochen

在 2023/3/3 17:12, HAO CHEN GUI via Gcc-patches 写道:
> Hi,
>   The patch escalates the failure when Hollerith constant to real conversion
> fails in native_interpret_expr. It finally reports an "Unclassifiable
> statement" error.
> 
>   The patch of pr95450 added a verification for decoding/encoding checking
> in native_interpret_expr. native_interpret_expr may fail on real type
> conversion and returns a NULL tree then. But upper layer calls don't handle
> the failure so that an ICE is reported when the verification fails.
> 
>   IBM long double is an example. It doesn't have a unique memory presentation
> for some real values. So it may not pass the verification. The new test
> case shows the problem.
> 
>   Compared to last version, this version moves the mpfr_init after NULL tree
> test and fixes the format problem according to Tobias's advice. Thanks a lot.
> 
> Gui Haochen
> Thanks
> 
> ChangeLog
> 2023-03-01  Haochen Gui 
> 
> gcc/
>   PR target/103628
>   * fortran/target-memory.cc (gfc_interpret_float): Return FAIL when
>   native_interpret_expr gets a NULL tree.
>   * fortran/arith.cc (gfc_hollerith2real): Return NULL when
>   gfc_interpret_float fails.
> 
> gcc/testsuite/
>   PR target/103628
>   * gfortran.dg/pr103628.f90: New.
> 
> patch.diff
> diff --git a/gcc/fortran/arith.cc b/gcc/fortran/arith.cc
> index c0d12cfad9d..d3d38c7eb6a 100644
> --- a/gcc/fortran/arith.cc
> +++ b/gcc/fortran/arith.cc
> @@ -2752,10 +2752,12 @@ gfc_hollerith2real (gfc_expr *src, int kind)
>result = gfc_get_constant_expr (BT_REAL, kind, >where);
> 
>hollerith2representation (result, src);
> -  gfc_interpret_float (kind, (unsigned char *) result->representation.string,
> -result->representation.length, result->value.real);
> -
> -  return result;
> +  if (gfc_interpret_float (kind,
> +(unsigned char *) result->representation.string,
> +result->representation.length, result->value.real))
> +return result;
> +  else
> +return NULL;
>  }
> 
>  /* Convert character to real.  The constant will be padded or truncated.  */
> diff --git a/gcc/fortran/target-memory.cc b/gcc/fortran/target-memory.cc
> index 7ce7d736629..0c47aa6b842 100644
> --- a/gcc/fortran/target-memory.cc
> +++ b/gcc/fortran/target-memory.cc
> @@ -416,11 +416,14 @@ gfc_interpret_float (int kind, unsigned char *buffer, 
> size_t buffer_size,
>mpfr_t real)
>  {
>gfc_set_model_kind (kind);
> -  mpfr_init (real);
> -  gfc_conv_tree_to_mpfr (real,
> -  native_interpret_expr (gfc_get_real_type (kind),
> - buffer, buffer_size));
> 
> +  tree source = native_interpret_expr (gfc_get_real_type (kind), buffer,
> +buffer_size);
> +  if (!source)
> +return 0;
> +
> +  mpfr_init (real);
> +  gfc_conv_tree_to_mpfr (real, source);
>return size_float (kind);
>  }
> 
> diff --git a/gcc/testsuite/gfortran.dg/pr103628.f90 
> b/gcc/testsuite/gfortran.dg/pr103628.f90
> new file mode 100644
> index 000..e49aefc18fd
> --- /dev/null
> +++ b/gcc/testsuite/gfortran.dg/pr103628.f90
> @@ -0,0 +1,14 @@
> +! { dg-do compile { target powerpc*-*-* } }
> +! { dg-options "-O2 -mabi=ibmlongdouble" }
> +
> +! Test to ensure that it reports an "Unclassifiable statement" error
> +! instead of throwing an ICE when the memory represent of the HOLLERITH
> +! string is not unique with ibm long double encoding.
> +
> +program main
> +  integer, parameter :: k = 16
> +  real(kind = k):: b = 4h1234
> +end program main
> +
> +! { dg-warning "Conversion from HOLLERITH" "warning" { target powerpc*-*-* } 
> 10 }
> +! { dg-error "Unclassifiable statement" "error" { target powerpc*-*-* } 10 }

RE: [PATCH] [PR51534] [arm] split out pr51534 test for softfp

[Kyrylo Tkachov via Gcc-patches]

> -Original Message-
> From: Alexandre Oliva 
> Sent: Friday, February 17, 2023 7:14 AM
> To: gcc-patches@gcc.gnu.org
> Cc: ni...@redhat.com; Richard Earnshaw 
> Subject: [PATCH] [PR51534] [arm] split out pr51534 test for softfp
> 
> 
> The test uses arm_hard_ok and arm_softfp_ok as if they were mutually
> exclusive, but they test whether the corresponding -mfloat-abi= flag
> is usable, not whether it is in effect, so it is possible for both to
> pass, and then the test comes out with incorrect expectations
> whichever the default float-abi is.
> 
> Separate the test into hard and softfp variants, and extend the softfp
> variant to accept both ARM and Thumb opcodes; it unwarrantedly assumed
> the latter.
> 
> Regstrapped on x86_64-linux-gnu.
> Tested on arm-vxworks7 (gcc-12) and arm-eabi (trunk).  Ok to install?

Ok.
Thanks,
Kyrill

> 
> for  gcc/testsuite/ChangeLog
> 
>   PR target/51534
>   * gcc.target/arm/pr51534.c: Split softfp variant into...
>   * gcc.target/arm/pr51534s.c: ... this, and support ARM too.
> ---
>  gcc/testsuite/gcc.target/arm/pr51534.c  |9 ++--
>  gcc/testsuite/gcc.target/arm/pr51534s.c |   72
> +++
>  2 files changed, 76 insertions(+), 5 deletions(-)
>  create mode 100644 gcc/testsuite/gcc.target/arm/pr51534s.c
> 
> diff --git a/gcc/testsuite/gcc.target/arm/pr51534.c
> b/gcc/testsuite/gcc.target/arm/pr51534.c
> index 5e121f5fb9946..ba21259bee554 100644
> --- a/gcc/testsuite/gcc.target/arm/pr51534.c
> +++ b/gcc/testsuite/gcc.target/arm/pr51534.c
> @@ -1,9 +1,9 @@
>  /* Test the vector comparison intrinsics when comparing to immediate zero.
> */
> 
> -/* { dg-do assemble } */
> +/* { dg-do assemble { target { arm_hard_ok } } } */
>  /* { dg-require-effective-target arm_neon_ok } */
> -/* { dg-options "-save-temps -O3" } */
> +/* { dg-options "-save-temps -mfloat-abi=hard -O3" } */
>  /* { dg-add-options arm_neon } */
> 
>  #include 
> @@ -64,9 +64,8 @@ GEN_COND_TESTS(vceq)
>  /* { dg-final { scan-assembler-times "vceq\.i8\[ \]+\[qQ\]\[0-9\]+,
> \[qQ\]\[0-9\]+, #0" 4 } } */
>  /* { dg-final { scan-assembler-times "vceq\.i16\[\]+\[qQ\]\[0-9\]+,
> \[qQ\]\[0-9\]+, #0" 4 } } */
>  /* { dg-final { scan-assembler-times "vceq\.i32\[\]+\[qQ\]\[0-9\]+,
> \[qQ\]\[0-9\]+, #0" 4 } } */
> -/* { dg-final { scan-assembler-times "vmov\.i32\[\]+\[dD\]\[0-9\]+,
> #0x" 3 { target { arm_hard_ok } } } } */
> -/* { dg-final { scan-assembler-times "vmov\.i32\[\]+\[qQ\]\[0-9\]+,
> #4294967295" 3 { target { arm_hard_ok } } } } */
> -/* { dg-final { scan-assembler-times "mov\[  \]+r\[0-9\]+, #-1" 6 { target {
> arm_softfp_ok } } } } */
> +/* { dg-final { scan-assembler-times "vmov\.i32\[\]+\[dD\]\[0-9\]+,
> #0x" 3 } } */
> +/* { dg-final { scan-assembler-times "vmov\.i32\[\]+\[qQ\]\[0-9\]+,
> #4294967295" 3 } } */
> 
>  /* And ensure we don't have unexpected output too.  */
>  /* { dg-final { scan-assembler-not "vc\[gl\]\[te\]\.u\[0-9\]+\[
>   \]+\[qQdD\]\[0-9\]+, \[qQdD\]\[0-9\]+, #0" } } */
> diff --git a/gcc/testsuite/gcc.target/arm/pr51534s.c
> b/gcc/testsuite/gcc.target/arm/pr51534s.c
> new file mode 100644
> index 0..b1638919c2f75
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/arm/pr51534s.c
> @@ -0,0 +1,72 @@
> +/* Test the vector comparison intrinsics when comparing to immediate
> zero.
> +   */
> +
> +/* { dg-do assemble { target { arm_softfp_ok } } } */
> +/* { dg-require-effective-target arm_neon_ok } */
> +/* { dg-options "-save-temps -mfloat-abi=softfp -O3" } */
> +/* { dg-add-options arm_neon } */
> +
> +#include 
> +
> +#define GEN_TEST(T, D, C, R) \
> +  R test_##C##_##T (T a) { return C (a, D (0)); }
> +
> +#define GEN_DOUBLE_TESTS(S, T, C) \
> +  GEN_TEST (T, vdup_n_s##S, C##_s##S, u##T) \
> +  GEN_TEST (u##T, vdup_n_u##S, C##_u##S, u##T)
> +
> +#define GEN_QUAD_TESTS(S, T, C) \
> +  GEN_TEST (T, vdupq_n_s##S, C##q_s##S, u##T) \
> +  GEN_TEST (u##T, vdupq_n_u##S, C##q_u##S, u##T)
> +
> +#define GEN_COND_TESTS(C) \
> +  GEN_DOUBLE_TESTS (8, int8x8_t, C) \
> +  GEN_DOUBLE_TESTS (16, int16x4_t, C) \
> +  GEN_DOUBLE_TESTS (32, int32x2_t, C) \
> +  GEN_QUAD_TESTS (8, int8x16_t, C) \
> +  GEN_QUAD_TESTS (16, int16x8_t, C) \
> +  GEN_QUAD_TESTS (32, int32x4_t, C)
> +
> +GEN_COND_TESTS(vcgt)
> +GEN_COND_TESTS(vcge)
> +GEN_COND_TESTS(vclt)
> +GEN_COND_TESTS(vcle)
> +GEN_COND_TESTS(vceq)
> +
> +/* Scan for expected outputs.  */
> +/* { dg-final { scan-assembler "vcgt\.s8\[   \]+\[dD\]\[0-9\]+, \[dD\]\[0-
> 9\]+, #0" } } */
> +/* { dg-final { scan-assembler "vcgt\.s16\[  \]+\[dD\]\[0-9\]+, \[dD\]\[0-
> 9\]+, #0" } } */
> +/* { dg-final { scan-assembler "vcgt\.s32\[  \]+\[dD\]\[0-9\]+, \[dD\]\[0-
> 9\]+, #0" } } */
> +/* { dg-final { scan-assembler "vcgt\.s8\[   \]+\[qQ\]\[0-9\]+, \[qQ\]\[0-
> 9\]+, #0" } } */
> +/* { dg-final { scan-assembler "vcgt\.s16\[  \]+\[qQ\]\[0-9\]+, \[qQ\]\[0-
> 9\]+, #0" } } */
> +/* { dg-final { scan-assembler "vcgt\.s32\[  \]+\[qQ\]\[0-9\]+, \[qQ\]\[0-
> 

Re: Re: [PATCH] RISC-V: Optimize the MASK opt generation

[Feng Wang]

On 2023-03-03 16:54  jiawei wrote:
>
>The Mask flag in the single TargetVariable is not enough due to more
>and more extensions were added.So I optimize the defination of Mask
>flag, please refer to the below case:
>There are some new MASK flags for 'v' extension(ZVL32B,ZVL64B,...,ZVL65536B),
>but these MASK flags can't store into x_target_flags,because the total number
>of MASK flags exceed 32. In this patch we can write it like this in this 
>scence.
>
>TargetVariable
>int riscv_zvl_flags
>
>Mask(ZVL32B) in TargetVariable(riscv_zvl_flags)
>
>The corresponding MASK and TARGET will be automatically generated.
>
>gcc/ChangeLog:
>
>    * config/riscv/riscv-opts.h   Delete below definations
>    (MASK_ZICSR): Delete;
>    (MASK_ZIFENCEI): Delete;
>    (TARGET_ZICSR): Delete;
>    (TARGET_ZIFENCEI): Delete;
>    (MASK_ZAWRS): Delete;
>    (TARGET_ZAWRS): Delete;
>    (MASK_ZBA): Delete;
>    (MASK_ZBB): Delete;
>    (MASK_ZBC): Delete;
>    (MASK_ZBS): Delete;
>    (TARGET_ZBA): Delete;
>    (TARGET_ZBB): Delete;
>    (TARGET_ZBC): Delete;
>    (TARGET_ZBS): Delete;
>    (MASK_ZFINX): Delete;
>    (MASK_ZDINX): Delete;
>    (MASK_ZHINX): Delete;
>    (MASK_ZHINXMIN): Delete;
>    (TARGET_ZFINX): Delete;
>    (TARGET_ZDINX): Delete;
>    (TARGET_ZHINX): Delete;
>    (TARGET_ZHINXMIN): Delete;
>    (MASK_ZBKB): Delete;
>    (MASK_ZBKC): Delete;
>    (MASK_ZBKX): Delete;
>    (MASK_ZKNE): Delete;
>    (MASK_ZKND): Delete;
>    (MASK_ZKNH): Delete;
>    (MASK_ZKR): Delete;
>    (MASK_ZKSED): Delete;
>    (MASK_ZKSH): Delete;
>    (MASK_ZKT): Delete;
>    (TARGET_ZBKB): Delete;
>    (TARGET_ZBKC): Delete;
>    (TARGET_ZBKX): Delete;
>    (TARGET_ZKNE): Delete;
>    (TARGET_ZKND): Delete;
>    (TARGET_ZKNH): Delete;
>    (TARGET_ZKR): Delete;
>    (TARGET_ZKSED): Delete;
>    (TARGET_ZKSH): Delete;
>    (TARGET_ZKT): Delete;
>    (MASK_VECTOR_ELEN_32): Delete;
>    (MASK_VECTOR_ELEN_64): Delete;
>    (MASK_VECTOR_ELEN_FP_32): Delete;
>    (MASK_VECTOR_ELEN_FP_64): Delete;
>    (TARGET_VECTOR_ELEN_32): Delete;
>    (TARGET_VECTOR_ELEN_64): Delete;
>    (TARGET_VECTOR_ELEN_FP_32): Delete;
>    (TARGET_VECTOR_ELEN_FP_64): Delete;
>    (MASK_ZVL32B): Delete;
>    (MASK_ZVL64B): Delete;
>    (MASK_ZVL128B): Delete;
>    (MASK_ZVL256B): Delete;
>    (MASK_ZVL512B): Delete;
>    (MASK_ZVL1024B): Delete;
>    (MASK_ZVL2048B): Delete;
>    (MASK_ZVL4096B): Delete;
>    (MASK_ZVL8192B): Delete;
>    (MASK_ZVL16384B): Delete;
>    (MASK_ZVL32768B): Delete;
>    (MASK_ZVL65536B): Delete;
>    (TARGET_ZVL32B): Delete;
>    (TARGET_ZVL64B): Delete;
>    (TARGET_ZVL128B): Delete;
>    (TARGET_ZVL256B): Delete;
>    (TARGET_ZVL512B): Delete;
>    (TARGET_ZVL1024B): Delete;
>    (TARGET_ZVL2048B): Delete;
>    (TARGET_ZVL4096B): Delete;
>    (TARGET_ZVL8192B): Delete;
>    (TARGET_ZVL16384B): Delete;
>    (TARGET_ZVL32768B): Delete;
>    (TARGET_ZVL65536B): Delete;
>    (MASK_ZICBOZ): Delete;
>    (MASK_ZICBOM): Delete;
>    (MASK_ZICBOP): Delete;
>    (TARGET_ZICBOZ): Delete;
>    (TARGET_ZICBOM): Delete;
>    (TARGET_ZICBOP): Delete;
>    (MASK_ZFHMIN): Delete;
>    (MASK_ZFH): Delete;
>    (TARGET_ZFHMIN): Delete;
>    (TARGET_ZFH): Delete;
>    (MASK_ZMMUL): Delete;
>    (TARGET_ZMMUL): Delete;
>    (MASK_SVINVAL): Delete;
>    (MASK_SVNAPOT): Delete;
>    (TARGET_SVINVAL): Delete;
>    (TARGET_SVNAPOT): Delete;
>    * config/riscv/riscv.opt: Add new Mask defination.
>    * opt-functions.awk:  Add new function to find the index
>  of target variable from extra_target_vars.
>    * opt-read.awk:   Add new function to store the Mask flags.
>    * opth-gen.awk:   Add new function to output the defination of
>  Mask Macro and Target Macro.
>---
> gcc/config/riscv/riscv-opts.h | 115 --
> gcc/config/riscv/riscv.opt    |  90 ++
> gcc/opt-functions.awk |  11 
> gcc/opt-read.awk  |  16 -
> gcc/opth-gen.awk  |  22 +++
> 5 files changed, 138 insertions(+), 116 deletions(-)
>
>diff --git a/gcc/config/riscv/riscv-opts.h b/gcc/config/riscv/riscv-opts.h
>index 25fd85b09b1..7cf28838cb5 100644
>--- a/gcc/config/riscv/riscv-opts.h
>+++ b/gcc/config/riscv/riscv-opts.h
>@@ -66,121 +66,6 @@ enum stack_protector_guard {
>   SSP_TLS,/* per-thread canary in TLS block */
>   SSP_GLOBAL  /* global canary */
> };
>-
>-#define MASK_ZICSR    (1 << 0)
>-#define MASK_ZIFENCEI (1 << 1)
>-
>-#define TARGET_ZICSR    ((riscv_zi_subext & MASK_ZICSR) != 0)
>-#define TARGET_ZIFENCEI ((riscv_zi_subext & 

[PATCHv2, gfortran] Escalate failure when Hollerith constant to real conversion fails [PR103628]

[HAO CHEN GUI via Gcc-patches]

Hi,
  The patch escalates the failure when Hollerith constant to real conversion
fails in native_interpret_expr. It finally reports an "Unclassifiable
statement" error.

  The patch of pr95450 added a verification for decoding/encoding checking
in native_interpret_expr. native_interpret_expr may fail on real type
conversion and returns a NULL tree then. But upper layer calls don't handle
the failure so that an ICE is reported when the verification fails.

  IBM long double is an example. It doesn't have a unique memory presentation
for some real values. So it may not pass the verification. The new test
case shows the problem.

  Compared to last version, this version moves the mpfr_init after NULL tree
test and fixes the format problem according to Tobias's advice. Thanks a lot.

Gui Haochen
Thanks

ChangeLog
2023-03-01  Haochen Gui 

gcc/
PR target/103628
* fortran/target-memory.cc (gfc_interpret_float): Return FAIL when
native_interpret_expr gets a NULL tree.
* fortran/arith.cc (gfc_hollerith2real): Return NULL when
gfc_interpret_float fails.

gcc/testsuite/
PR target/103628
* gfortran.dg/pr103628.f90: New.

patch.diff
diff --git a/gcc/fortran/arith.cc b/gcc/fortran/arith.cc
index c0d12cfad9d..d3d38c7eb6a 100644
--- a/gcc/fortran/arith.cc
+++ b/gcc/fortran/arith.cc
@@ -2752,10 +2752,12 @@ gfc_hollerith2real (gfc_expr *src, int kind)
   result = gfc_get_constant_expr (BT_REAL, kind, >where);

   hollerith2representation (result, src);
-  gfc_interpret_float (kind, (unsigned char *) result->representation.string,
-  result->representation.length, result->value.real);
-
-  return result;
+  if (gfc_interpret_float (kind,
+  (unsigned char *) result->representation.string,
+  result->representation.length, result->value.real))
+return result;
+  else
+return NULL;
 }

 /* Convert character to real.  The constant will be padded or truncated.  */
diff --git a/gcc/fortran/target-memory.cc b/gcc/fortran/target-memory.cc
index 7ce7d736629..0c47aa6b842 100644
--- a/gcc/fortran/target-memory.cc
+++ b/gcc/fortran/target-memory.cc
@@ -416,11 +416,14 @@ gfc_interpret_float (int kind, unsigned char *buffer, 
size_t buffer_size,
 mpfr_t real)
 {
   gfc_set_model_kind (kind);
-  mpfr_init (real);
-  gfc_conv_tree_to_mpfr (real,
-native_interpret_expr (gfc_get_real_type (kind),
-   buffer, buffer_size));

+  tree source = native_interpret_expr (gfc_get_real_type (kind), buffer,
+  buffer_size);
+  if (!source)
+return 0;
+
+  mpfr_init (real);
+  gfc_conv_tree_to_mpfr (real, source);
   return size_float (kind);
 }

diff --git a/gcc/testsuite/gfortran.dg/pr103628.f90 
b/gcc/testsuite/gfortran.dg/pr103628.f90
new file mode 100644
index 000..e49aefc18fd
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr103628.f90
@@ -0,0 +1,14 @@
+! { dg-do compile { target powerpc*-*-* } }
+! { dg-options "-O2 -mabi=ibmlongdouble" }
+
+! Test to ensure that it reports an "Unclassifiable statement" error
+! instead of throwing an ICE when the memory represent of the HOLLERITH
+! string is not unique with ibm long double encoding.
+
+program main
+  integer, parameter :: k = 16
+  real(kind = k):: b = 4h1234
+end program main
+
+! { dg-warning "Conversion from HOLLERITH" "warning" { target powerpc*-*-* } 
10 }
+! { dg-error "Unclassifiable statement" "error" { target powerpc*-*-* } 10 }

RE: [PATCH] [arm] complete vmsr/vmrs blank and case adjustments

[Kyrylo Tkachov via Gcc-patches]

> -Original Message-
> From: Alexandre Oliva 
> Sent: Friday, February 17, 2023 7:36 AM
> To: gcc-patches@gcc.gnu.org
> Cc: ni...@redhat.com; Richard Earnshaw ;
> ramana@gmail.com; Kyrylo Tkachov ;
> Andrea Corallo 
> Subject: [PATCH] [arm] complete vmsr/vmrs blank and case adjustments
> 
> 
> Back in September last year, some of the vmsr and vmrs patterns had an
> extraneous blank removed, and the case of register names lowered, but
> another instance remained, and so did a few testcases.
> 
> Regstrapped on x86_64-linux-gnu.
> Tested on arm-vxworks7 (gcc-12) and arm-eabi (trunk).  Ok to install?

Ok. I would have subjectively considered this obvious though 
Thanks,
Kyrill

> 
> for  gcc/ChangeLog
> 
>   * config/arm/vfp.md (*thumb2_movsi_vfp): Drop blank after tab
>   after vmsr and vmrs, and lower the case of P0.
> 
> for  gcc/testsuite/ChangeLog
> 
>   * gcc.target/arm/acle/cde-mve-full-assembly.c: Drop blank
>   after tab after vmsr, and lower the case of P0.
> ---
>  gcc/config/arm/vfp.md  |4
>  .../gcc.target/arm/acle/cde-mve-full-assembly.c|  264 
> ++--
>  2 files changed, 134 insertions(+), 134 deletions(-)
> 
> diff --git a/gcc/config/arm/vfp.md b/gcc/config/arm/vfp.md
> index f34f35e1185e2..60e7ba35d8b25 100644
> --- a/gcc/config/arm/vfp.md
> +++ b/gcc/config/arm/vfp.md
> @@ -312,9 +312,9 @@ (define_insn "*thumb2_movsi_vfp"
>  case 12: case 13:
>return output_move_vfp (operands);
>  case 14:
> -  return \"vmsr\\t P0, %1\";
> +  return \"vmsr\\tp0, %1\";
>  case 15:
> -  return \"vmrs\\t %0, P0\";
> +  return \"vmrs\\t%0, p0\";
>  case 16:
>return \"mcr\\tp10, 7, %1, cr1, cr0, 0\\t @SET_FPSCR\";
>  case 17:
> diff --git a/gcc/testsuite/gcc.target/arm/acle/cde-mve-full-assembly.c
> b/gcc/testsuite/gcc.target/arm/acle/cde-mve-full-assembly.c
> index d025c3391fbe5..72f330185944a 100644
> --- a/gcc/testsuite/gcc.target/arm/acle/cde-mve-full-assembly.c
> +++ b/gcc/testsuite/gcc.target/arm/acle/cde-mve-full-assembly.c
> @@ -534,80 +534,80 @@
> contain back references).  */
>  /*
>  ** test_cde_vcx1q_mfloat16x8_tintint:
> -**   (?:vmov\.i32q0, #0  @ v16qi|vmsr P0, r2 @ movhi)
> -**   (?:vmov\.i32q0, #0  @ v16qi|vmsr P0, r2 @ movhi)
> +**   (?:vmov\.i32q0, #0  @ v16qi|vmsrp0, r2  @ movhi)
> +**   (?:vmov\.i32q0, #0  @ v16qi|vmsrp0, r2  @ movhi)
>  **   vpst
>  **   vcx1t   p0, q0, #32
>  **   bx  lr
>  */
>  /*
>  ** test_cde_vcx1q_mfloat32x4_tintint:
> -**   (?:vmov\.i32q0, #0  @ v16qi|vmsr P0, r2 @ movhi)
> -**   (?:vmov\.i32q0, #0  @ v16qi|vmsr P0, r2 @ movhi)
> +**   (?:vmov\.i32q0, #0  @ v16qi|vmsrp0, r2  @ movhi)
> +**   (?:vmov\.i32q0, #0  @ v16qi|vmsrp0, r2  @ movhi)
>  **   vpst
>  **   vcx1t   p0, q0, #32
>  **   bx  lr
>  */
>  /*
>  ** test_cde_vcx1q_muint8x16_tintint:
> -**   (?:vmov\.i32q0, #0  @ v16qi|vmsr P0, r2 @ movhi)
> -**   (?:vmov\.i32q0, #0  @ v16qi|vmsr P0, r2 @ movhi)
> +**   (?:vmov\.i32q0, #0  @ v16qi|vmsrp0, r2  @ movhi)
> +**   (?:vmov\.i32q0, #0  @ v16qi|vmsrp0, r2  @ movhi)
>  **   vpst
>  **   vcx1t   p0, q0, #32
>  **   bx  lr
>  */
>  /*
>  ** test_cde_vcx1q_muint16x8_tintint:
> -**   (?:vmov\.i32q0, #0  @ v16qi|vmsr P0, r2 @ movhi)
> -**   (?:vmov\.i32q0, #0  @ v16qi|vmsr P0, r2 @ movhi)
> +**   (?:vmov\.i32q0, #0  @ v16qi|vmsrp0, r2  @ movhi)
> +**   (?:vmov\.i32q0, #0  @ v16qi|vmsrp0, r2  @ movhi)
>  **   vpst
>  **   vcx1t   p0, q0, #32
>  **   bx  lr
>  */
>  /*
>  ** test_cde_vcx1q_muint32x4_tintint:
> -**   (?:vmov\.i32q0, #0  @ v16qi|vmsr P0, r2 @ movhi)
> -**   (?:vmov\.i32q0, #0  @ v16qi|vmsr P0, r2 @ movhi)
> +**   (?:vmov\.i32q0, #0  @ v16qi|vmsrp0, r2  @ movhi)
> +**   (?:vmov\.i32q0, #0  @ v16qi|vmsrp0, r2  @ movhi)
>  **   vpst
>  **   vcx1t   p0, q0, #32
>  **   bx  lr
>  */
>  /*
>  ** test_cde_vcx1q_muint64x2_tintint:
> -**   (?:vmov\.i32q0, #0  @ v16qi|vmsr P0, r2 @ movhi)
> -**   (?:vmov\.i32q0, #0  @ v16qi|vmsr P0, r2 @ movhi)
> +**   (?:vmov\.i32q0, #0  @ v16qi|vmsrp0, r2  @ movhi)
> +**   (?:vmov\.i32q0, #0  @ v16qi|vmsrp0, r2  @ movhi)
>  **   vpst
>  **   vcx1t   p0, q0, #32
>  **   bx  lr
>  */
>  /*
>  ** test_cde_vcx1q_mint8x16_tintint:
> -**   (?:vmov\.i32q0, #0  @ v16qi|vmsr P0, r2 @ movhi)
> -**   (?:vmov\.i32q0, #0  @ v16qi|vmsr P0, r2 @ movhi)
> +**   (?:vmov\.i32q0, #0  @ v16qi|vmsrp0, r2  @ movhi)
> +**   (?:vmov\.i32q0, #0  @ v16qi|vmsrp0, r2  @ movhi)
>  **   vpst
>  **   vcx1t   p0, q0, #32
>  **   bx  lr
>  */
>  /*
>  ** test_cde_vcx1q_mint16x8_tintint:
> -**   (?:vmov\.i32q0, #0  @ v16qi|vmsr P0, r2 @ movhi)
> -**   (?:vmov\.i32q0, #0  @ v16qi|vmsr P0, r2 @ movhi)
> +**   (?:vmov\.i32q0, #0  @ v16qi|vmsrp0, r2  @ movhi)
> 

RE: [PATCH] [PR104882] [arm] require mve hw for mve run test

[Kyrylo Tkachov via Gcc-patches]

> -Original Message-
> From: Alexandre Oliva 
> Sent: Friday, February 17, 2023 7:39 AM
> To: gcc-patches@gcc.gnu.org
> Cc: ni...@redhat.com; Richard Earnshaw ;
> ramana@gmail.com; Kyrylo Tkachov 
> Subject: [PATCH] [PR104882] [arm] require mve hw for mve run test
> 
> 
> The pr104882.c test is an execution test, but arm_v8_1m_mve_ok only
> tests for compile-time support.  Add a requirement for mve hardware.
> 
> Regstrapped on x86_64-linux-gnu.
> Tested on arm-vxworks7 (gcc-12) and arm-eabi (trunk).  Ok to install?

Ok.
Thanks,
Kyrill

> 
> for  gcc/testsuite/ChangeLog
> 
>   PR target/104882
>   * gcc.target/arm/simd/pr104882.c: Require mve hardware.
> ---
>  gcc/testsuite/gcc.target/arm/simd/pr104882.c |1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/gcc/testsuite/gcc.target/arm/simd/pr104882.c
> b/gcc/testsuite/gcc.target/arm/simd/pr104882.c
> index ae9709af42f22..1ea7a14836f54 100644
> --- a/gcc/testsuite/gcc.target/arm/simd/pr104882.c
> +++ b/gcc/testsuite/gcc.target/arm/simd/pr104882.c
> @@ -1,4 +1,5 @@
>  /* { dg-do run } */
> +/* { dg-require-effective-target arm_mve_hw } */
>  /* { dg-require-effective-target arm_v8_1m_mve_ok } */
>  /* { dg-add-options arm_v8_1m_mve } */
>  /* { dg-additional-options "-O2" } */
> 
> --
> Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
>Free Software Activist   GNU Toolchain Engineer
> Disinformation flourishes because many people care deeply about injustice
> but very few check the facts.  Ask me about 

Re: [PATCH] driver: toplev: Fix a typo

[Xi Ruoyao via Gcc-patches]

On Fri, 2023-03-03 at 16:54 +0800, Xi Ruoyao wrote:
> The driver emits a warning when -fstack-check and
> -fstack-clash-protection are used together, but the message refers to
> "-fstack-clash_protection" (underline instead of dash).

Forgot: Ok for trunk?  Though I think it's obvious but let's follow the
procedure :).

> gcc/ChangeLog:
> 
> * toplev.cc (process_options): Fix the spelling of
> "-fstack-clash-protection".
> ---
>  gcc/toplev.cc | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/gcc/toplev.cc b/gcc/toplev.cc
> index 4c15d4f542e..109c9d58cbd 100644
> --- a/gcc/toplev.cc
> +++ b/gcc/toplev.cc
> @@ -1580,7 +1580,7 @@ process_options (bool no_backend)
>    if (flag_stack_check != NO_STACK_CHECK &&
> flag_stack_clash_protection)
>  {
>    warning_at (UNKNOWN_LOCATION, 0,
> - "%<-fstack-check=%> and %<-fstack-clash_protection%>
> are "
> + "%<-fstack-check=%> and %<-fstack-clash-protection%>
> are "
>   "mutually exclusive; disabling %<-fstack-check=%>");
>    flag_stack_check = NO_STACK_CHECK;
>  }

-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

Re: [PATCH] RISC-V: Optimize the MASK opt generation

[jiawei]

> The Mask flag in the single TargetVariable is not enough due to more> and 
> more extensions were added.So I optimize the defination of Mask> flag, please 
> refer to the below case:> There are some new MASK flags for 'v' 
> extension(ZVL32B,ZVL64B,...,ZVL65536B),> but these MASK flags can't store 
> into x_target_flags,because the total number> of MASK flags exceed 32. In 
> this patch we can write it like this in this scence.> > TargetVariable> int 
> riscv_zvl_flags> > Mask(ZVL32B) in TargetVariable(riscv_zvl_flags)> > The 
> corresponding MASK and TARGET will be automatically generated.> > 
> gcc/ChangeLog:> > * config/riscv/riscv-opts.h   Delete below 
> definations> (MASK_ZICSR): Delete;> (MASK_ZIFENCEI): Delete;> 
> (TARGET_ZICSR): Delete;> (TARGET_ZIFENCEI): Delete;> 
> (MASK_ZAWRS): Delete;> (TARGET_ZAWRS): Delete;> (MASK_ZBA): 
> Delete;> (MASK_ZBB): Delete;> (MASK_ZBC): Delete;> 
> (MASK_ZBS): Delete;> (TARGET_ZBA): Delete;> (TARGET_ZBB): 
> Delete;> (TARGET_ZBC): Delete;> (TARGET_ZBS): Delete;>
>  (MASK_ZFINX): Delete;> (MASK_ZDINX): Delete;> (MASK_ZHINX): 
> Delete;> (MASK_ZHINXMIN): Delete;> (TARGET_ZFINX): Delete;>   
>   (TARGET_ZDINX): Delete;> (TARGET_ZHINX): Delete;> 
> (TARGET_ZHINXMIN): Delete;> (MASK_ZBKB): Delete;> 
> (MASK_ZBKC): Delete;> (MASK_ZBKX): Delete;> (MASK_ZKNE): 
> Delete;> (MASK_ZKND): Delete;> (MASK_ZKNH): Delete;> 
> (MASK_ZKR): Delete;> (MASK_ZKSED): Delete;> (MASK_ZKSH): 
> Delete;> (MASK_ZKT): Delete;> (TARGET_ZBKB): Delete;> 
> (TARGET_ZBKC): Delete;> (TARGET_ZBKX): Delete;> 
> (TARGET_ZKNE): Delete;> (TARGET_ZKND): Delete;> 
> (TARGET_ZKNH): Delete;> (TARGET_ZKR): Delete;> 
> (TARGET_ZKSED): Delete;> (TARGET_ZKSH): Delete;> 
> (TARGET_ZKT): Delete;> (MASK_VECTOR_ELEN_32): Delete;> 
> (MASK_VECTOR_ELEN_64): Delete;> (MASK_VECTOR_ELEN_FP_32): Delete;>
>  (MASK_VECTOR_ELEN_FP_64): Delete;> (TARGET_VECTOR_ELEN_32): 
> Delete;> (TARGET_VECTOR_ELEN_64): Delete;> 
> (TARGET_VECTOR_ELEN_FP_32): Delete;> (TARGET_VECTOR_ELEN_FP_64): 
> Delete;> (MASK_ZVL32B): Delete;> (MASK_ZVL64B): Delete;>  
>(MASK_ZVL128B): Delete;> (MASK_ZVL256B): Delete;> 
> (MASK_ZVL512B): Delete;> (MASK_ZVL1024B): Delete;> 
> (MASK_ZVL2048B): Delete;> (MASK_ZVL4096B): Delete;> 
> (MASK_ZVL8192B): Delete;> (MASK_ZVL16384B): Delete;> 
> (MASK_ZVL32768B): Delete;> (MASK_ZVL65536B): Delete;> 
> (TARGET_ZVL32B): Delete;> (TARGET_ZVL64B): Delete;> 
> (TARGET_ZVL128B): Delete;> (TARGET_ZVL256B): Delete;> 
> (TARGET_ZVL512B): Delete;> (TARGET_ZVL1024B): Delete;> 
> (TARGET_ZVL2048B): Delete;> (TARGET_ZVL4096B): Delete;> 
> (TARGET_ZVL8192B): Delete;> (TARGET_ZVL16384B): Delete;> 
> (TARGET_ZVL32768B): Delete;> (TARGET_ZVL65536B): Delete;> 
> (MASK_ZICBOZ): Delete;> (MASK_ZICBOM): Delete;> 
> (MASK_ZICBOP): Delete;> (TARGET_ZICBOZ): Delete;> 
> (TARGET_ZICBOM): Delete;> (TARGET_ZICBOP): Delete;> 
> (MASK_ZFHMIN): Delete;> (MASK_ZFH): Delete;> (TARGET_ZFHMIN): 
> Delete;> (TARGET_ZFH): Delete;> (MASK_ZMMUL): Delete;>
>  (TARGET_ZMMUL): Delete;> (MASK_SVINVAL): Delete;> 
> (MASK_SVNAPOT): Delete;> (TARGET_SVINVAL): Delete;> 
> (TARGET_SVNAPOT): Delete;> * config/riscv/riscv.opt: Add new Mask 
> defination.> * opt-functions.awk:  Add new function to find the 
> index>   of target variable from 
> extra_target_vars.> * opt-read.awk:   Add new function to 
> store the Mask flags.> * opth-gen.awk:   Add new function to 
> output the defination of>   Mask Macro and 
> Target Macro.> --->  gcc/config/riscv/riscv-opts.h | 115 
> -->  gcc/config/riscv/riscv.opt|  90 
> ++>  gcc/opt-functions.awk |  11 >  
> gcc/opt-read.awk  |  16 ->  gcc/opth-gen.awk  |  
> 22 +++>  5 files changed, 138 insertions(+), 116 deletions(-)> > diff 
> --git a/gcc/config/riscv/riscv-opts.h b/gcc/config/riscv/riscv-opts.h> index 
> 25fd85b09b1..7cf28838cb5 100644> --- a/gcc/config/riscv/riscv-opts.h> +++ 
> b/gcc/config/riscv/riscv-opts.h> @@ -66,121 +66,6 @@ enum 
> stack_protector_guard {>SSP_TLS,/* per-thread canary in TLS block */>
> SSP_GLOBAL/* global canary */>  };> -> -#define MASK_ZICSR(1 << 

Re: [PATCH] [arm] adjust tests for quotes around +cdecp

[Christophe Lyon via Gcc-patches]

On 3/3/23 09:24, Alexandre Oliva wrote:

Hello, Christophe,

On Feb 22, 2023, Christophe Lyon  wrote:


OK thanks for the clarification.



(and for the other cleanup patches!)


Was this meant as approval?  I hadn't taken it as such.


Unfortunately, no, I don't have such powers :-)



Otherwise, please consider this a ping :-)
https://gcc.gnu.org/pipermail/gcc-patches/2023-February/612188.html

Thanks,

[PATCH] driver: toplev: Fix a typo

[Xi Ruoyao via Gcc-patches]

The driver emits a warning when -fstack-check and
-fstack-clash-protection are used together, but the message refers to
"-fstack-clash_protection" (underline instead of dash).

gcc/ChangeLog:

* toplev.cc (process_options): Fix the spelling of
"-fstack-clash-protection".
---
 gcc/toplev.cc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/toplev.cc b/gcc/toplev.cc
index 4c15d4f542e..109c9d58cbd 100644
--- a/gcc/toplev.cc
+++ b/gcc/toplev.cc
@@ -1580,7 +1580,7 @@ process_options (bool no_backend)
   if (flag_stack_check != NO_STACK_CHECK && flag_stack_clash_protection)
 {
   warning_at (UNKNOWN_LOCATION, 0,
- "%<-fstack-check=%> and %<-fstack-clash_protection%> are "
+ "%<-fstack-check=%> and %<-fstack-clash-protection%> are "
  "mutually exclusive; disabling %<-fstack-check=%>");
   flag_stack_check = NO_STACK_CHECK;
 }
-- 
2.39.2

Re: [PATCH] RISC-V: Optimize the MASK opt generation

[jiawei]

The Mask flag in the single TargetVariable is not enough due to more
and more extensions were added.So I optimize the defination of Mask
flag, please refer to the below case:
There are some new MASK flags for 'v' extension(ZVL32B,ZVL64B,...,ZVL65536B),
but these MASK flags can't store into x_target_flags,because the total number
of MASK flags exceed 32. In this patch we can write it like this in this scence.

TargetVariable
int riscv_zvl_flags

Mask(ZVL32B) in TargetVariable(riscv_zvl_flags)

The corresponding MASK and TARGET will be automatically generated.

gcc/ChangeLog:

* config/riscv/riscv-opts.h   Delete below definations
(MASK_ZICSR): Delete;
(MASK_ZIFENCEI): Delete;
(TARGET_ZICSR): Delete;
(TARGET_ZIFENCEI): Delete;
(MASK_ZAWRS): Delete;
(TARGET_ZAWRS): Delete;
(MASK_ZBA): Delete;
(MASK_ZBB): Delete;
(MASK_ZBC): Delete;
(MASK_ZBS): Delete;
(TARGET_ZBA): Delete;
(TARGET_ZBB): Delete;
(TARGET_ZBC): Delete;
(TARGET_ZBS): Delete;
(MASK_ZFINX): Delete;
(MASK_ZDINX): Delete;
(MASK_ZHINX): Delete;
(MASK_ZHINXMIN): Delete;
(TARGET_ZFINX): Delete;
(TARGET_ZDINX): Delete;
(TARGET_ZHINX): Delete;
(TARGET_ZHINXMIN): Delete;
(MASK_ZBKB): Delete;
(MASK_ZBKC): Delete;
(MASK_ZBKX): Delete;
(MASK_ZKNE): Delete;
(MASK_ZKND): Delete;
(MASK_ZKNH): Delete;
(MASK_ZKR): Delete;
(MASK_ZKSED): Delete;
(MASK_ZKSH): Delete;
(MASK_ZKT): Delete;
(TARGET_ZBKB): Delete;
(TARGET_ZBKC): Delete;
(TARGET_ZBKX): Delete;
(TARGET_ZKNE): Delete;
(TARGET_ZKND): Delete;
(TARGET_ZKNH): Delete;
(TARGET_ZKR): Delete;
(TARGET_ZKSED): Delete;
(TARGET_ZKSH): Delete;
(TARGET_ZKT): Delete;
(MASK_VECTOR_ELEN_32): Delete;
(MASK_VECTOR_ELEN_64): Delete;
(MASK_VECTOR_ELEN_FP_32): Delete;
(MASK_VECTOR_ELEN_FP_64): Delete;
(TARGET_VECTOR_ELEN_32): Delete;
(TARGET_VECTOR_ELEN_64): Delete;
(TARGET_VECTOR_ELEN_FP_32): Delete;
(TARGET_VECTOR_ELEN_FP_64): Delete;
(MASK_ZVL32B): Delete;
(MASK_ZVL64B): Delete;
(MASK_ZVL128B): Delete;
(MASK_ZVL256B): Delete;
(MASK_ZVL512B): Delete;
(MASK_ZVL1024B): Delete;
(MASK_ZVL2048B): Delete;
(MASK_ZVL4096B): Delete;
(MASK_ZVL8192B): Delete;
(MASK_ZVL16384B): Delete;
(MASK_ZVL32768B): Delete;
(MASK_ZVL65536B): Delete;
(TARGET_ZVL32B): Delete;
(TARGET_ZVL64B): Delete;
(TARGET_ZVL128B): Delete;
(TARGET_ZVL256B): Delete;
(TARGET_ZVL512B): Delete;
(TARGET_ZVL1024B): Delete;
(TARGET_ZVL2048B): Delete;
(TARGET_ZVL4096B): Delete;
(TARGET_ZVL8192B): Delete;
(TARGET_ZVL16384B): Delete;
(TARGET_ZVL32768B): Delete;
(TARGET_ZVL65536B): Delete;
(MASK_ZICBOZ): Delete;
(MASK_ZICBOM): Delete;
(MASK_ZICBOP): Delete;
(TARGET_ZICBOZ): Delete;
(TARGET_ZICBOM): Delete;
(TARGET_ZICBOP): Delete;
(MASK_ZFHMIN): Delete;
(MASK_ZFH): Delete;
(TARGET_ZFHMIN): Delete;
(TARGET_ZFH): Delete;
(MASK_ZMMUL): Delete;
(TARGET_ZMMUL): Delete;
(MASK_SVINVAL): Delete;
(MASK_SVNAPOT): Delete;
(TARGET_SVINVAL): Delete;
(TARGET_SVNAPOT): Delete;
* config/riscv/riscv.opt: Add new Mask defination.
* opt-functions.awk:  Add new function to find the index
  of target variable from extra_target_vars.
* opt-read.awk:   Add new function to store the Mask flags.
* opth-gen.awk:   Add new function to output the defination of
  Mask Macro and Target Macro.
---
 gcc/config/riscv/riscv-opts.h | 115 --
 gcc/config/riscv/riscv.opt|  90 ++
 gcc/opt-functions.awk |  11 
 gcc/opt-read.awk  |  16 -
 gcc/opth-gen.awk  |  22 +++
 5 files changed, 138 insertions(+), 116 deletions(-)

diff --git a/gcc/config/riscv/riscv-opts.h b/gcc/config/riscv/riscv-opts.h
index 25fd85b09b1..7cf28838cb5 100644
--- a/gcc/config/riscv/riscv-opts.h
+++ b/gcc/config/riscv/riscv-opts.h
@@ -66,121 +66,6 @@ enum stack_protector_guard {
   SSP_TLS, /* per-thread canary in TLS block */
   SSP_GLOBAL   /* global canary */
 };
-
-#define MASK_ZICSR(1 << 0)
-#define MASK_ZIFENCEI (1 << 1)
-
-#define TARGET_ZICSR((riscv_zi_subext & MASK_ZICSR) != 0)
-#define TARGET_ZIFENCEI ((riscv_zi_subext & MASK_ZIFENCEI) != 0)
-
-#define MASK_ZAWRS   (1 << 0)
-#define TARGET_ZAWRS ((riscv_za_subext & MASK_ZAWRS) != 0)
-
-#define MASK_ZBA  (1 << 

[PATCH 2/2] LoongArch: testsuite: Adjust stack offsets in stack-check-cfa tests

[Xi Ruoyao via Gcc-patches]

Once upon the time we used to save two registers unnecessarily, costing
16 bytes.  Now the issue seems fixed (not sure by which commit though),
adjust the stack offsets to reflex the change.

gcc/testsuite/ChangeLog:

* gcc.target/loongarch/stack-check-cfa-1.c (dg-final): Adjust
expected stack offset.
* gcc.target/loongarch/stack-check-cfa-2.c (dg-final): Likewise.
---
 gcc/testsuite/gcc.target/loongarch/stack-check-cfa-1.c | 2 +-
 gcc/testsuite/gcc.target/loongarch/stack-check-cfa-2.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/testsuite/gcc.target/loongarch/stack-check-cfa-1.c 
b/gcc/testsuite/gcc.target/loongarch/stack-check-cfa-1.c
index 3533fe7b685..cd72154f46c 100644
--- a/gcc/testsuite/gcc.target/loongarch/stack-check-cfa-1.c
+++ b/gcc/testsuite/gcc.target/loongarch/stack-check-cfa-1.c
@@ -6,7 +6,7 @@
 #define SIZE 128*1024
 #include "stack-check-prologue.h"
 
-/* { dg-final { scan-assembler-times {\.cfi_def_cfa_offset 131088} 1 } } */
+/* { dg-final { scan-assembler-times {\.cfi_def_cfa_offset 131072} 1 } } */
 /* { dg-final { scan-assembler-times {\.cfi_def_cfa_offset 0} 1 } } */
 
 /* Checks that the CFA notes are correct for every sp adjustment.  */
diff --git a/gcc/testsuite/gcc.target/loongarch/stack-check-cfa-2.c 
b/gcc/testsuite/gcc.target/loongarch/stack-check-cfa-2.c
index e5e711105ac..3e5ca05b2da 100644
--- a/gcc/testsuite/gcc.target/loongarch/stack-check-cfa-2.c
+++ b/gcc/testsuite/gcc.target/loongarch/stack-check-cfa-2.c
@@ -6,7 +6,7 @@
 #define SIZE 1280*1024 + 512
 #include "stack-check-prologue.h"
 
-/* { dg-final { scan-assembler-times {\.cfi_def_cfa_offset 1311248} 1 } } */
+/* { dg-final { scan-assembler-times {\.cfi_def_cfa_offset 1311232} 1 } } */
 /* { dg-final { scan-assembler-times {\.cfi_def_cfa_offset 0} 1 } } */
 
 /* Checks that the CFA notes are correct for every sp adjustment.  */
-- 
2.39.2

[PATCH 1/2] LoongArch: testsuite: Disable stack protector for some tests

[Xi Ruoyao via Gcc-patches]

Stack protector will affect stack layout and break the expectation of
these tests, causing test failures if GCC is configured with
--enable-default-ssp.

gcc/testsuite/ChangeLog:

* gcc.target/loongarch/prolog-opt.c (dg-options): Add
-fno-stack-protector.
* gcc.target/loongarch/stack-check-cfa-1.c (dg-options):
Likewise.
* gcc.target/loongarch/stack-check-cfa-2.c (dg-options):
Likewise.
---
 gcc/testsuite/gcc.target/loongarch/prolog-opt.c| 2 +-
 gcc/testsuite/gcc.target/loongarch/stack-check-cfa-1.c | 2 +-
 gcc/testsuite/gcc.target/loongarch/stack-check-cfa-2.c | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/gcc/testsuite/gcc.target/loongarch/prolog-opt.c 
b/gcc/testsuite/gcc.target/loongarch/prolog-opt.c
index 0470a1f1eee..e6a64263384 100644
--- a/gcc/testsuite/gcc.target/loongarch/prolog-opt.c
+++ b/gcc/testsuite/gcc.target/loongarch/prolog-opt.c
@@ -1,7 +1,7 @@
 /* Test that LoongArch backend stack drop operation optimized.  */
 
 /* { dg-do compile } */
-/* { dg-options "-O2 -mabi=lp64d" } */
+/* { dg-options "-O2 -mabi=lp64d -fno-stack-protector" } */
 /* { dg-final { scan-assembler "addi.d\t\\\$r3,\\\$r3,-16" } } */
 
 extern int printf (char *, ...);
diff --git a/gcc/testsuite/gcc.target/loongarch/stack-check-cfa-1.c 
b/gcc/testsuite/gcc.target/loongarch/stack-check-cfa-1.c
index f0c6877fc25..3533fe7b685 100644
--- a/gcc/testsuite/gcc.target/loongarch/stack-check-cfa-1.c
+++ b/gcc/testsuite/gcc.target/loongarch/stack-check-cfa-1.c
@@ -1,5 +1,5 @@
 /* { dg-do compile } */
-/* { dg-options "-O2 -fstack-clash-protection --param 
stack-clash-protection-guard-size=16 -funwind-tables" } */
+/* { dg-options "-O2 -fstack-clash-protection --param 
stack-clash-protection-guard-size=16 -funwind-tables -fno-stack-protector" } */
 /* { dg-require-effective-target supports_stack_clash_protection } */
 /* { dg-skip-if "" { *-*-* } { "-fstack-check" } { "" } } */
 
diff --git a/gcc/testsuite/gcc.target/loongarch/stack-check-cfa-2.c 
b/gcc/testsuite/gcc.target/loongarch/stack-check-cfa-2.c
index c6e07bc561a..e5e711105ac 100644
--- a/gcc/testsuite/gcc.target/loongarch/stack-check-cfa-2.c
+++ b/gcc/testsuite/gcc.target/loongarch/stack-check-cfa-2.c
@@ -1,5 +1,5 @@
 /* { dg-do compile } */
-/* { dg-options "-O2 -fstack-clash-protection --param 
stack-clash-protection-guard-size=16 -funwind-tables" } */
+/* { dg-options "-O2 -fstack-clash-protection --param 
stack-clash-protection-guard-size=16 -funwind-tables -fno-stack-protector" } */
 /* { dg-require-effective-target supports_stack_clash_protection } */
 /* { dg-skip-if "" { *-*-* } { "-fstack-check" } { "" } } */
 
-- 
2.39.2

[PATCH 0/2] LoongArch: testsuite: Fix tests related to stack

[Xi Ruoyao via Gcc-patches]

Some trivial test case fixes.  Ok for trunk?

Xi Ruoyao (2):
  LoongArch: testsuite: Disable stack protector for some tests
  LoongArch: testsuite: Adjust stack offsets in stack-check-cfa tests

 gcc/testsuite/gcc.target/loongarch/prolog-opt.c| 2 +-
 gcc/testsuite/gcc.target/loongarch/stack-check-cfa-1.c | 4 ++--
 gcc/testsuite/gcc.target/loongarch/stack-check-cfa-2.c | 4 ++--
 3 files changed, 5 insertions(+), 5 deletions(-)

-- 
2.39.2

Re: [PATCH] -Wdangling-pointer: don't mark SSA lhs sets as stores

[Alexandre Oliva via Gcc-patches]

On Feb 17, 2023, Richard Biener  wrote:

>> * gimple-ssa-warn-access.cc
>> (pass_waccess::check_dangling_stores): Skip non-stores.
>> 
>> for  gcc/testsuite/ChangeLog
>> 
>> * g++.dg/warn/Wdangling-pointer.C (warn_init_ref_member): Add
>> two new variants, one fixed, one xfailed.
>> * c-c++-common/Wdangling-pointer-5.c
>> (nowarn_store_arg_store_arg): Add now-expected warnings.

Ping?
https://gcc.gnu.org/pipermail/gcc-patches/2023-February/612186.html

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

Re: [PATCH] [arm] adjust expectations for armv8_2-fp16-move-[12].c

[Alexandre Oliva via Gcc-patches]

On Feb 17, 2023, Alexandre Oliva  wrote:

>   * gcc.target/arm/armv8_2-fp16-move-1.c: Combine vcmp and vcmpe
>   expected counts into a single pattern.
>   * gcc.target/arm/armv8_2-fp16-move-2.c: Accept conditional
>   return and reversed conditions.

Ping?
https://gcc.gnu.org/pipermail/gcc-patches/2023-February/612190.html

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

Re: [PATCH] [PR51534] [arm] split out pr51534 test for softfp

[Alexandre Oliva via Gcc-patches]

On Feb 17, 2023, Alexandre Oliva  wrote:

>   PR target/51534
>   * gcc.target/arm/pr51534.c: Split softfp variant into...
>   * gcc.target/arm/pr51534s.c: ... this, and support ARM too.

Ping?
https://gcc.gnu.org/pipermail/gcc-patches/2023-February/612189.html

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

Re: [PATCH] [arm] complete vmsr/vmrs blank and case adjustments

[Alexandre Oliva via Gcc-patches]

On Feb 20, 2023, Andrea Corallo via Gcc-patches  wrote:

> Alexandre Oliva  writes:
>> Back in September last year, some of the vmsr and vmrs patterns had an
>> extraneous blank removed, and the case of register names lowered, but
>> another instance remained, and so did a few testcases.

> I'm not approver but LGTM, thanks for fixing this.

Ping on this one as well.
https://gcc.gnu.org/pipermail/gcc-patches/2023-February/612192.html

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about