Re: [PATCH] Fortran: Add IEEE_SIGNBIT and IEEE_FMA functions

[Thomas Koenig via Gcc-patches]

Hi FX,


Maybe the ping is a bit early, as you know I’m not very active anymore, so I do 
not know what are the current policies. In particular, how much leeway do I 
have to commit the patch if there is no comment from another maintainer?

I am fairly confident about the code, because I wrote the original IEEE 
implementation so I know it very well. I believe it would probably be better to 
commit this and have it tested on mainline, that wait for too long. I intend to 
submit further patches and improvements in this area, once those are merged.



Looks good in principle.

Just a couple of remarks:

Both of these functions are new with Fortran 2018, could you add
a standards version check?

And, more general: I don't think we document which part of the IEEE
arithmetic we support. It might be a good idea to add that to the manual
(but not for this patch).

So, OK with the version check.

Best regards

Thomas

Re: c: New C2x keywords

[Richard Biener via Gcc-patches]

> Am 07.09.2022 um 00:11 schrieb Joseph Myers :
> 
> C2x follows C++ in making alignas, alignof, bool, false,
> static_assert, thread_local and true keywords; implement this
> accordingly.  This implementation makes them normal keywords in C2x
> mode just like any other keyword (C2x leaves open the possibility of
> implementation using predefined macros instead - thus, there aren't
> any testcases asserting that they aren't macros).  As in C++ and
> previous versions of C, true and false are handled like signed 1 and 0
> in #if (there was an intermediate state in some C2x drafts where they
> had different macro expansions that were unsigned in #if).
> 
> Bootstrapped with no regressions for x86_64-pc-linux-gnu.  OK to commit 
> (stdalign.h and stdbool.h changes)?

Ok.

Thanks,
Richard 


> As with the removal of unprototyped functions, this change has a high
> risk of breaking some old code and people doing GNU/Linux distribution
> builds may wish to see how much is broken in a build with a -std=gnu2x
> default.
> 
> gcc/
>* ginclude/stdalign.h [defined __STDC_VERSION__ &&
>__STDC_VERSION__ > 201710L]: Disable all content.
>* ginclude/stdbool.h [defined __STDC_VERSION__ && __STDC_VERSION__
>> 201710L] (bool, true, false): Do not define.
> 
> gcc/c-family/
>* c-common.cc (c_common_reswords): Use D_C2X instead of D_CXXONLY
>for alignas, alignof, bool, false, static_assert, thread_local and
>true.
> 
> gcc/c/
>* c-parser.cc (c_parser_static_assert_declaration_no_semi)
>(c_parser_alignas_specifier, c_parser_alignof_expression): Allow
>for C2x spellings of keywords.
>(c_parser_postfix_expression): Handle RID_TRUE and RID_FALSE.
> 
> gcc/testsuite/
>* gcc.dg/c11-keywords-1.c, gcc.dg/c2x-align-1.c,
>gcc.dg/c2x-align-6.c, gcc.dg/c2x-bool-2.c,
>gcc.dg/c2x-static-assert-3.c, gcc.dg/c2x-static-assert-4.c,
>gcc.dg/c2x-thread-local-1.c: New tests.
>* gcc.dg/c2x-bool-1.c: Update expectations.
> 
> libcpp/
>* include/cpplib.h (struct cpp_options): Add true_false.
>* expr.cc (eval_token): Check true_false not cplusplus to
>determine whether to handle true and false keywords.
>* init.cc (struct lang_flags): Add true_false.
>(lang_defaults): Update.
>(cpp_set_lang): Set true_false.
> 
> diff --git a/gcc/c-family/c-common.cc b/gcc/c-family/c-common.cc
> index 9746504195b..0a5b7e120c9 100644
> --- a/gcc/c-family/c-common.cc
> +++ b/gcc/c-family/c-common.cc
> @@ -459,11 +459,11 @@ const struct c_common_resword c_common_reswords[] =
>   { "__GIMPLE",RID_GIMPLE,D_CONLY },
>   { "__PHI",RID_PHI,D_CONLY },
>   { "__RTL",RID_RTL,D_CONLY },
> -  { "alignas",RID_ALIGNAS,D_CXXONLY | D_CXX11 | D_CXXWARN },
> -  { "alignof",RID_ALIGNOF,D_CXXONLY | D_CXX11 | D_CXXWARN },
> +  { "alignas",RID_ALIGNAS,D_C2X | D_CXX11 | D_CXXWARN },
> +  { "alignof",RID_ALIGNOF,D_C2X | D_CXX11 | D_CXXWARN },
>   { "asm",RID_ASM,D_ASM },
>   { "auto",RID_AUTO,0 },
> -  { "bool",RID_BOOL,D_CXXONLY | D_CXXWARN },
> +  { "bool",RID_BOOL,D_C2X | D_CXXWARN },
>   { "break",RID_BREAK,0 },
>   { "case",RID_CASE,0 },
>   { "catch",RID_CATCH,D_CXX_OBJC | D_CXXWARN },
> @@ -489,7 +489,7 @@ const struct c_common_resword c_common_reswords[] =
>   { "explicit",RID_EXPLICIT,D_CXXONLY | D_CXXWARN },
>   { "export",RID_EXPORT,D_CXXONLY | D_CXXWARN },
>   { "extern",RID_EXTERN,0 },
> -  { "false",RID_FALSE,D_CXXONLY | D_CXXWARN },
> +  { "false",RID_FALSE,D_C2X | D_CXXWARN },
>   { "float",RID_FLOAT,0 },
>   { "for",RID_FOR,0 },
>   { "friend",RID_FRIEND,D_CXXONLY | D_CXXWARN },
> @@ -515,15 +515,15 @@ const struct c_common_resword c_common_reswords[] =
>   { "signed",RID_SIGNED,0 },
>   { "sizeof",RID_SIZEOF,0 },
>   { "static",RID_STATIC,0 },
> -  { "static_assert",RID_STATIC_ASSERT, D_CXXONLY | D_CXX11 | D_CXXWARN },
> +  { "static_assert",RID_STATIC_ASSERT, D_C2X | D_CXX11 | D_CXXWARN },
>   { "static_cast",RID_STATCAST,D_CXXONLY | D_CXXWARN },
>   { "struct",RID_STRUCT,0 },
>   { "switch",RID_SWITCH,0 },
>   { "template",RID_TEMPLATE,D_CXXONLY | D_CXXWARN },
>   { "this",RID_THIS,D_CXXONLY | D_CXXWARN },
> -  { "thread_local",RID_THREAD,D_CXXONLY | D_CXX11 | D_CXXWARN },
> +  { "thread_local",RID_THREAD,D_C2X | D_CXX11 | D_CXXWARN },
>   { "throw",RID_THROW,D_CXX_OBJC | D_CXXWARN },
> -  { "true",RID_TRUE,D_CXXONLY | D_CXXWARN },
> +  { "true",RID_TRUE,D_C2X | D_CXXWARN },
>   { "try",RID_TRY,D_CXX_OBJC | D_CXXWARN },
>   { "typedef",RID_TYPEDEF,0 },
>   { "typename",RID_TYPENAME,D_CXXONLY | D_CXXWARN },
> diff --git 

Re: [PATCH] Using pli(paddi) and rotate to build 64bit constants

[Jiufu Guo via Gcc-patches]

"Kewen.Lin"  writes:

> Hi!
>
>> +
>> +  /* Use paddi for the low 32 bits.  */
>> +  if (ud2 != 0 && ud1 != 0 && can_use_paddi)
>> +emit_move_insn (dest, gen_rtx_PLUS (DImode, dest,
>> +GEN_INT ((ud2 << 16) | ud1)));
>> +
>> +  /* Use oris, ori for low 32 bits.  */
>> +  if (ud2 != 0 && (ud1 == 0 || !can_use_paddi))
>> +emit_move_insn (ud1 != 0 ? dest : dest,
>
> Nit: "ud1 != 0 ? dest : dest" => dest
Thanks! Yes, only 'dest' is ok.
>
>> +gen_rtx_IOR (DImode, dest, GEN_INT (ud2 << 16)));
>> +  if (ud1 != 0 && (ud2 == 0 || !can_use_paddi))
>> +emit_move_insn (dest, gen_rtx_IOR (DImode, dest, GEN_INT (ud1)));
>> +}
>> +}
>>else
>>  {
>>temp = !can_create_pseudo_p () ? dest : gen_reg_rtx (DImode);
>> diff --git a/gcc/testsuite/gcc.target/powerpc/pr106550.c 
>> b/gcc/testsuite/gcc.target/powerpc/pr106550.c
>> new file mode 100644
>> index 000..d023fac4676
>> --- /dev/null
>> +++ b/gcc/testsuite/gcc.target/powerpc/pr106550.c
>> @@ -0,0 +1,14 @@
>> +/* PR target/106550 */
>> +/* { dg-options "-O2 -mdejagnu-cpu=power10" } */
>> +/* { dg-require-effective-target power10_ok } */
>> +
>> +void
>> +foo (unsigned long long *a)
>> +{
>> +  *a++ = 0x020805006106003; /* pli+pli+rldimi */
>> +  *a++ = 0x2351847027482577;/* pli+pli+rldimi */  
>> +}
>> +
>> +/* { dg-final { scan-assembler-times {\mpli\M} 4 } } */
>> +/* { dg-final { scan-assembler-times {\mrldimi\M} 2 } } */
>> +
>> diff --git a/gcc/testsuite/gcc.target/powerpc/pr106550_1.c 
>> b/gcc/testsuite/gcc.target/powerpc/pr106550_1.c
>> new file mode 100644
>> index 000..48f76ca3da9
>> --- /dev/null
>> +++ b/gcc/testsuite/gcc.target/powerpc/pr106550_1.c
>> @@ -0,0 +1,22 @@
>> +/* PR target/106550 */
>> +/* { dg-require-effective-target power10_ok } */
>> +/* { dg-options "-O2 -mdejagnu-cpu=power10 -fdisable-rtl-split1" } */
>> +/* force the constant splitter run after RA: -fdisable-rtl-split1.  */
>> +
>> +void
>> +foo (unsigned long long *a)
>> +{
>> +  /* Test oris/ori is used where paddi does not work with 'r0'. */
>> +  register long long d asm("r0") = 0x1245abcef9240dec; /* pli+sldi+oris+ori 
>> */
>> +  long long n;
>> +  asm("cntlzd %0, %1" : "=r"(n) : "r"(d));
>> +  *a++ = n;
>> +
>> +  *a++ = 0x235a8470a748ULL; /* pli+sldi+oris*/
>> +  *a++ = 0x23a18470b677ULL; /* pli+sldi+ori*/
>
> Nit: I guess you want one space at the separated end of these two comment 
> lines
> since the comment lines at the other places have.  :)
Yeap, thanks for your careful review!

BR,
Jeff(Jiufu)
>
> BR,
> Kewen

Re: [PATCH] Using pli(paddi) and rotate to build 64bit constants

[Jiufu Guo via Gcc-patches]

Segher Boessenkool  writes:

> Hi!
>
> On Tue, Sep 06, 2022 at 08:27:56PM +0800, Jiufu Guo wrote:
>> +  if (can_create_pseudo_p ())
>> +{
>> +  /* pli A,H + pli B,L + rldimi A,B,32,0.  */
>
> A is the low one and B is the high one (the one that needs to be
> shifted).  rl[wd]imi is one of our very few insns that has the output
> register as one of the input registers as well.  "Good" to see not just
> the compiler has problems with this, but humans do as well!  ;-)
Yes, A is the low part and B is the high.
Thanks for catch this!

>
> Otherwise looks good to me.  Okay for trunk with that fixed somehow.
> Thanks!

Thanks again!

BR,
Jeff(Jiufu)
>
>
> Segher

Re: [PATCH] c++: Implement C++23 P2266R1, Simpler implicit move [PR101165]

[Jason Merrill via Gcc-patches]

On 9/3/22 12:42, Marek Polacek wrote:

This patch implements https://wg21.link/p2266, which, once again,
changes the implicit move rules.  Here's a brief summary of various
changes in this area:

r125211: Introduced moving from certain lvalues when returning them
r171071: CWG 1148, enable move from value parameter on return
r212099: CWG 1579, it's OK to call a converting ctor taking an rvalue
r251035: CWG 1579, do maybe-rvalue overload resolution twice
r11-2411: Avoid calling const copy ctor on implicit move
r11-2412: C++20 implicit move changes, remove the fallback overload
   resolution, allow move on throw of parameters and implicit
  move of rvalue references

P2266 enables the implicit move for functions that return references.  This
was a one-line change: check TYPE_REF_P.  That is, we will now perform
a move in

   X&& foo (X&& x) {
 return x;
   }

P2266 also removes the fallback overload resolution, but this was
resolved by r11-2412: we only do convert_for_initialization with
LOOKUP_PREFER_RVALUE in C++17 and older.


I wonder if we want to extend the current C++20 handling to the older 
modes for GCC 13?  Not in this patch, but as a followup.



P2266 also says that a returned move-eligible id-expression is always an
xvalue.  This required some further short, but nontrivial changes,
especially when it comes to deduction, because we have to pay attention
to whether we have auto, auto&& (which is like T&&), or decltype(auto)
with (un)parenthesized argument.  In C++23,

   decltype(auto) f(int&& x) { return (x); }
   auto&& f(int x) { return x; }

both should deduce to 'int&&' but

   decltype(auto) f(int x) { return x; }

should deduce to 'int'.  A cornucopia of tests attached.  I've also
verified that we behave like clang++.

xvalue_p seemed to be broken: since the introduction of clk_implicit_rval,
it cannot use '==' when checking for clk_rvalueref.

Since this change breaks code, it's only enabled in C++23.  In
particular, this code will not compile in C++23:

   int& g(int&& x) { return x; }


Nice that the C++20 compatibility is so simple!


because x is now treated as an rvalue, and you can't bind a non-const lvalue
reference to an rvalue.

There's one FIXME in elision1.C:five, which we should compile but reject
with "passing 'Mutt' as 'this' argument discards qualifiers".  That
looks bogus to me, I think I'll open a PR for it.


Let's fix that now, I think.


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

PR c++/101165

gcc/c-family/ChangeLog:

* c-cppbuiltin.cc (c_cpp_builtins): Define __cpp_implicit_move.

gcc/cp/ChangeLog:

* call.cc (reference_binding): Check clk_implicit_rval in C++20 only.
* cp-tree.h (unparenthesized_id_or_class_member_access_p): Declare.
* pt.cc (unparenthesized_id_or_class_member_access_p): New function,
broken out of...
(do_auto_deduction): ...here.  Use it.
* tree.cc (xvalue_p): Check & clk_rvalueref, not == clk_rvalueref.
* typeck.cc (check_return_expr): In C++23, maybe call
treat_lvalue_as_rvalue_p before do_auto_deduction.  Allow implicit
move for functions returning a reference as well.

gcc/testsuite/ChangeLog:

* g++.dg/conversion/pr41426.C: Add dg-error for C++23.
* g++.dg/cpp0x/elision_weak.C: Likewise.
* g++.dg/cpp0x/move-return3.C: Only link in c++20_down.
* g++.dg/cpp1y/decltype-auto2.C: Add dg-error for C++23.
* g++.dg/cpp1y/lambda-generic-89419.C: Likewise.
* g++.dg/cpp23/feat-cxx2b.C: Test __cpp_implicit_move.
* g++.dg/gomp/pr56217.C: Only compile in c++20_down.
* g++.dg/warn/Wno-return-local-addr.C: Add dg-error for C++23.
* g++.dg/warn/Wreturn-local-addr.C: Adjust dg-error.
* g++.old-deja/g++.brendan/crash55.C: Add dg-error for C++23.
* g++.old-deja/g++.jason/temporary2.C: Likewise.
* g++.old-deja/g++.mike/p2846b.C: Only run in c++20_down.
* g++.dg/cpp1y/decltype-auto6.C: New test.
* g++.dg/cpp23/decltype1.C: New test.
* g++.dg/cpp23/decltype2.C: New test.
* g++.dg/cpp23/elision1.C: New test.
* g++.dg/cpp23/elision2.C: New test.
* g++.dg/cpp23/elision3.C: New test.
* g++.dg/cpp23/elision4.C: New test.
* g++.dg/cpp23/elision5.C: New test.
* g++.dg/cpp23/elision6.C: New test.
* g++.dg/cpp23/elision7.C: New test.
---
  gcc/c-family/c-cppbuiltin.cc  |   1 +
  gcc/cp/call.cc|   2 +-
  gcc/cp/cp-tree.h  |   1 +
  gcc/cp/pt.cc  |  33 +++--
  gcc/cp/tree.cc|   2 +-
  gcc/cp/typeck.cc  |  28 -
  gcc/testsuite/g++.dg/conversion/pr41426.C |  10 +-
  gcc/testsuite/g++.dg/cpp0x/elision_weak.C |   4 +-
  gcc/testsuite/g++.dg/cpp0x/move-return3.C |   3 +-
  

[PATCH RFA] libstdc++: small dynamic_cast optimization

[Jason Merrill via Gcc-patches]

An email discussion of optimizing EH led me to wonder why we weren't doing
this already.  Not that this change affects EH at all.

Tested x86_64-pc-linux-gnu.  Does this seem worthwhile?

libstdc++-v3/ChangeLog:

* libsupc++/dyncast.cc (__dynamic_cast): Avoid virtual function
call in simple success case.
---
 libstdc++-v3/libsupc++/dyncast.cc | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/libstdc++-v3/libsupc++/dyncast.cc 
b/libstdc++-v3/libsupc++/dyncast.cc
index 853c911a4cf..616e4c05766 100644
--- a/libstdc++-v3/libsupc++/dyncast.cc
+++ b/libstdc++-v3/libsupc++/dyncast.cc
@@ -71,6 +71,12 @@ __dynamic_cast (const void *src_ptr,// object started 
from
   if (whole_prefix->whole_type != whole_type)
 return NULL;
 
+  // Avoid virtual function call in the simple success case.
+  if (src2dst >= 0
+  && src2dst == -prefix->whole_object
+  && *whole_type == *dst_type)
+return const_cast  (whole_ptr);
+
   whole_type->__do_dyncast (src2dst, __class_type_info::__contained_public,
 dst_type, whole_ptr, src_type, src_ptr, result);
   if (!result.dst_ptr)

base-commit: 0a2fba3697411c07a8330abfe7460ce62bce5e7f
-- 
2.31.1

libgo patch committed: Ignore __morestack in runtime.Callers

[Ian Lance Taylor via Gcc-patches]

This libgo patch ignores the __morestack function in runtime.Callers.
We were ignoring all functions starting with "__morestack_", but not
the function "__morestack" itself.  Without this change, some tests
such as recover.go started failing recently, though I'm not sure
exactly what changed.  Bootstrapped and ran Go testsuite on
x86_64-pc-linux-gnu.  Committed to mainline.

Ian
c0852b51b7a68ada822955eb7ef83d933cc33e47
diff --git a/gcc/go/gofrontend/MERGE b/gcc/go/gofrontend/MERGE
index ca797045d66..dce38e727a7 100644
--- a/gcc/go/gofrontend/MERGE
+++ b/gcc/go/gofrontend/MERGE
@@ -1,4 +1,4 @@
-d53e8a0e94e34dc609e34dd5e404debda2640cfb
+6543b7fc6da533eb976b37649a925e7fd5a521fa
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
diff --git a/libgo/runtime/go-callers.c b/libgo/runtime/go-callers.c
index 31783696a08..1d4dee66279 100644
--- a/libgo/runtime/go-callers.c
+++ b/libgo/runtime/go-callers.c
@@ -107,7 +107,7 @@ callback (void *data, uintptr_t pc, const char *filename, 
int lineno,
   p = function;
   if (__builtin_strncmp (p, "___", 3) == 0)
++p;
-  if (__builtin_strncmp (p, "__morestack_", 12) == 0)
+  if (__builtin_strncmp (p, "__morestack", 11) == 0)
return 0;
 }
   else if (filename != NULL)

Re: [PATCH] libcpp, v3: Named universal character escapes and delimited escape sequence tweaks

[Jason Merrill via Gcc-patches]

On 9/3/22 06:54, Jakub Jelinek wrote:

On Sat, Sep 03, 2022 at 12:29:52PM +0200, Jakub Jelinek wrote:

On Thu, Sep 01, 2022 at 03:00:28PM -0400, Jason Merrill wrote:

We might as well use the same flag name, and document it to mean what it
currently means for GCC.


Ok, following patch introduces -Wunicode (on by default).


It looks like this is handling \N{abc}, for which "incomplete" seems like
the wrong description; it's complete, just wrong, and the diagnostic doesn't
help correct it.


And also will emit the is not a valid universal character with did you mean
if it matches loosely, otherwise will use the not terminated with } after
... wording.

Ok if it passes bootstrap/regtest?


OK, thanks.


Actually, treating the !strict case like the strict case except for always
warning instead of error if outside of literals is simpler.

The following version does that.  The only difference on the testcases is in
the
int f = a\N{abc});
cases where it emits different diagnostics.

2022-09-03  Jakub Jelinek  

libcpp/
* include/cpplib.h (struct cpp_options): Add cpp_warn_unicode member.
(enum cpp_warning_reason): Add CPP_W_UNICODE.
* init.cc (cpp_create_reader): Initialize cpp_warn_unicode.
* charset.cc (_cpp_valid_ucn): In possible identifier contexts, don't
handle \u{ or \N{ specially in -std=c* modes except -std=c++2{3,b}.
In possible identifier contexts, don't emit an error and punt
if \N isn't followed by {, or if \N{} surrounds some lower case
letters or _.  In possible identifier contexts when not C++23, don't
emit an error but warning about unknown character names and treat as
separate tokens.  When treating as separate tokens \u{ or \N{, emit
warnings.
gcc/
* doc/invoke.texi (-Wno-unicode): Document.
gcc/c-family/
* c.opt (Winvalid-utf8): Use ObjC instead of objC.  Remove
" in comments" from description.
(Wunicode): New option.
gcc/testsuite/
* c-c++-common/cpp/delimited-escape-seq-4.c: New test.
* c-c++-common/cpp/delimited-escape-seq-5.c: New test.
* c-c++-common/cpp/delimited-escape-seq-6.c: New test.
* c-c++-common/cpp/delimited-escape-seq-7.c: New test.
* c-c++-common/cpp/named-universal-char-escape-5.c: New test.
* c-c++-common/cpp/named-universal-char-escape-6.c: New test.
* c-c++-common/cpp/named-universal-char-escape-7.c: New test.
* g++.dg/cpp23/named-universal-char-escape1.C: New test.
* g++.dg/cpp23/named-universal-char-escape2.C: New test.

--- libcpp/include/cpplib.h.jj  2022-09-03 09:35:41.465984642 +0200
+++ libcpp/include/cpplib.h 2022-09-03 11:30:57.250677870 +0200
@@ -565,6 +565,10 @@ struct cpp_options
   2 if it should be a pedwarn.  */
unsigned char cpp_warn_invalid_utf8;
  
+  /* True if libcpp should warn about invalid forms of delimited or named

+ escape sequences.  */
+  bool cpp_warn_unicode;
+
/* True if -finput-charset= option has been used explicitly.  */
bool cpp_input_charset_explicit;
  
@@ -675,7 +679,8 @@ enum cpp_warning_reason {

CPP_W_CXX20_COMPAT,
CPP_W_EXPANSION_TO_DEFINED,
CPP_W_BIDIRECTIONAL,
-  CPP_W_INVALID_UTF8
+  CPP_W_INVALID_UTF8,
+  CPP_W_UNICODE
  };
  
  /* Callback for header lookup for HEADER, which is the name of a

--- libcpp/init.cc.jj   2022-09-01 09:47:23.729892618 +0200
+++ libcpp/init.cc  2022-09-03 11:19:10.954452329 +0200
@@ -228,6 +228,7 @@ cpp_create_reader (enum c_lang lang, cpp
CPP_OPTION (pfile, warn_date_time) = 0;
CPP_OPTION (pfile, cpp_warn_bidirectional) = bidirectional_unpaired;
CPP_OPTION (pfile, cpp_warn_invalid_utf8) = 0;
+  CPP_OPTION (pfile, cpp_warn_unicode) = 1;
CPP_OPTION (pfile, cpp_input_charset_explicit) = 0;
  
/* Default CPP arithmetic to something sensible for the host for the

--- libcpp/charset.cc.jj2022-09-01 14:19:47.462235851 +0200
+++ libcpp/charset.cc   2022-09-03 12:42:41.800923600 +0200
@@ -1448,7 +1448,11 @@ _cpp_valid_ucn (cpp_reader *pfile, const
if (str[-1] == 'u')
  {
length = 4;
-  if (str < limit && *str == '{')
+  if (str < limit
+ && *str == '{'
+ && (!identifier_pos
+ || CPP_OPTION (pfile, delimited_escape_seqs)
+ || !CPP_OPTION (pfile, std)))
{
  str++;
  /* Magic value to indicate no digits seen.  */
@@ -1462,8 +1466,22 @@ _cpp_valid_ucn (cpp_reader *pfile, const
else if (str[-1] == 'N')
  {
length = 4;
+  if (identifier_pos
+ && !CPP_OPTION (pfile, delimited_escape_seqs)
+ && CPP_OPTION (pfile, std))
+   {
+ *cp = 0;
+ return false;
+   }
if (str == limit || *str != '{')
-   cpp_error (pfile, CPP_DL_ERROR, "'\\N' not followed by '{'");
+   {
+ if (identifier_pos)
+   {
+ *cp = 0;
+ return false;
+   }
+ cpp_error (pfile, 

Re: [PATCH] Using pli(paddi) and rotate to build 64bit constants

[Kewen.Lin via Gcc-patches]

Hi!

> +
> +   /* Use paddi for the low 32 bits.  */
> +   if (ud2 != 0 && ud1 != 0 && can_use_paddi)
> + emit_move_insn (dest, gen_rtx_PLUS (DImode, dest,
> + GEN_INT ((ud2 << 16) | ud1)));
> +
> +   /* Use oris, ori for low 32 bits.  */
> +   if (ud2 != 0 && (ud1 == 0 || !can_use_paddi))
> + emit_move_insn (ud1 != 0 ? dest : dest,

Nit: "ud1 != 0 ? dest : dest" => dest

> + gen_rtx_IOR (DImode, dest, GEN_INT (ud2 << 16)));
> +   if (ud1 != 0 && (ud2 == 0 || !can_use_paddi))
> + emit_move_insn (dest, gen_rtx_IOR (DImode, dest, GEN_INT (ud1)));
> + }
> +}
>else
>  {
>temp = !can_create_pseudo_p () ? dest : gen_reg_rtx (DImode);
> diff --git a/gcc/testsuite/gcc.target/powerpc/pr106550.c 
> b/gcc/testsuite/gcc.target/powerpc/pr106550.c
> new file mode 100644
> index 000..d023fac4676
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/powerpc/pr106550.c
> @@ -0,0 +1,14 @@
> +/* PR target/106550 */
> +/* { dg-options "-O2 -mdejagnu-cpu=power10" } */
> +/* { dg-require-effective-target power10_ok } */
> +
> +void
> +foo (unsigned long long *a)
> +{
> +  *a++ = 0x020805006106003; /* pli+pli+rldimi */
> +  *a++ = 0x2351847027482577;/* pli+pli+rldimi */  
> +}
> +
> +/* { dg-final { scan-assembler-times {\mpli\M} 4 } } */
> +/* { dg-final { scan-assembler-times {\mrldimi\M} 2 } } */
> +
> diff --git a/gcc/testsuite/gcc.target/powerpc/pr106550_1.c 
> b/gcc/testsuite/gcc.target/powerpc/pr106550_1.c
> new file mode 100644
> index 000..48f76ca3da9
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/powerpc/pr106550_1.c
> @@ -0,0 +1,22 @@
> +/* PR target/106550 */
> +/* { dg-require-effective-target power10_ok } */
> +/* { dg-options "-O2 -mdejagnu-cpu=power10 -fdisable-rtl-split1" } */
> +/* force the constant splitter run after RA: -fdisable-rtl-split1.  */
> +
> +void
> +foo (unsigned long long *a)
> +{
> +  /* Test oris/ori is used where paddi does not work with 'r0'. */
> +  register long long d asm("r0") = 0x1245abcef9240dec; /* pli+sldi+oris+ori 
> */
> +  long long n;
> +  asm("cntlzd %0, %1" : "=r"(n) : "r"(d));
> +  *a++ = n;
> +
> +  *a++ = 0x235a8470a748ULL; /* pli+sldi+oris*/
> +  *a++ = 0x23a18470b677ULL; /* pli+sldi+ori*/

Nit: I guess you want one space at the separated end of these two comment lines
since the comment lines at the other places have.  :)

BR,
Kewen

[PATCH] c: fix uninitialized c_expr::m_decimal [PR106830]

[David Malcolm via Gcc-patches]

I added c_expr::m_decimal in r13-2386-gbedfca647a9e9c1a as part of the
implementation of -Wxor-used-as-pow, but I missed various places where
the field needed to be initialized.

Fixed thusly (based on searching for places that assign to
the original_code field).

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.

OK for trunk?

Thanks
Dave


gcc/c-family/ChangeLog:
PR c/106830
* c-warn.cc (check_for_xor_used_as_pow): Don't try checking
values that don't fit in uhwi.

gcc/c/ChangeLog:
PR c/106830
* c-parser.cc (c_parser_initelt): Initialize m_decimal.
(c_parser_cast_expression): Likewise.
(c_parser_alignof_expression): Likewise.
(c_parser_postfix_expression_after_paren_type): Likewise.
(c_parser_postfix_expression_after_primary): Likewise.
(c_parser_expression): Likewise.
(c_parser_omp_variable_list): Likewise.
(c_parser_transaction_expression): Likewise.
* c-tree.h (c_expr::set_error): Likewise.
* c-typeck.cc (c_expr_sizeof_expr): Likewise.
(parser_build_unary_op): Likewise.
(parser_build_binary_op): Likewise.
(digest_init): Likewise.
(pop_init_level): Likewise.
* gimple-parser.cc (c_parser_gimple_call_internal): Likewise.

gcc/testsuite/ChangeLog:
PR c/106830
* gcc.dg/Wxor-used-as-pow-pr106830.c: New test.

Signed-off-by: David Malcolm 
---
 gcc/c-family/c-warn.cc   |  9 +++--
 gcc/c/c-parser.cc| 12 
 gcc/c/c-tree.h   |  3 ++-
 gcc/c/c-typeck.cc|  7 +++
 gcc/c/gimple-parser.cc   |  5 +
 gcc/testsuite/gcc.dg/Wxor-used-as-pow-pr106830.c |  6 ++
 6 files changed, 35 insertions(+), 7 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/Wxor-used-as-pow-pr106830.c

diff --git a/gcc/c-family/c-warn.cc b/gcc/c-family/c-warn.cc
index ed79cc3ca40..6742f447ff5 100644
--- a/gcc/c-family/c-warn.cc
+++ b/gcc/c-family/c-warn.cc
@@ -3809,12 +3809,9 @@ check_for_xor_used_as_pow (location_t lhs_loc, tree 
lhs_val,
   location_t operator_loc,
   tree rhs_val)
 {
-  /* Only complain if both args are non-negative integer constants.  */
-  if (!(TREE_CODE (lhs_val) == INTEGER_CST
-   && tree_int_cst_sgn (lhs_val) >= 0))
-return;
-  if (!(TREE_CODE (rhs_val) == INTEGER_CST
-   && tree_int_cst_sgn (rhs_val) >= 0))
+  /* Only complain if both args are non-negative integer constants that fit
+ in uhwi.  */
+  if (!tree_fits_uhwi_p (lhs_val) || !tree_fits_uhwi_p (rhs_val))
 return;
 
   /* Only complain if the LHS is 2 or 10.  */
diff --git a/gcc/c/c-parser.cc b/gcc/c/c-parser.cc
index 72db5b527f8..600ba4429ed 100644
--- a/gcc/c/c-parser.cc
+++ b/gcc/c/c-parser.cc
@@ -5462,6 +5462,7 @@ c_parser_initelt (c_parser *parser, struct obstack * 
braced_init_obstack)
= objc_build_message_expr (rec, args);
  mexpr.original_code = ERROR_MARK;
  mexpr.original_type = NULL;
+ mexpr.m_decimal = 0;
  /* Now parse and process the remainder of the
 initializer, starting with this message
 expression as a primary-expression.  */
@@ -8144,6 +8145,7 @@ c_parser_cast_expression (c_parser *parser, struct c_expr 
*after)
set_c_expr_source_range (, cast_loc, expr.get_finish ());
   ret.original_code = ERROR_MARK;
   ret.original_type = NULL;
+  ret.m_decimal = 0;
   return ret;
 }
   else
@@ -8460,6 +8462,7 @@ c_parser_alignof_expression (c_parser *parser)
   ret.original_code = ERROR_MARK;
   ret.original_type = NULL;
   set_c_expr_source_range (, start_loc, end_loc);
+  ret.m_decimal = 0;
   return ret;
 }
   else
@@ -8479,6 +8482,7 @@ c_parser_alignof_expression (c_parser *parser)
   ret.original_code = ERROR_MARK;
   ret.original_type = NULL;
   set_c_expr_source_range (, start_loc, end_loc);
+  ret.m_decimal = 0;
   return ret;
 }
 }
@@ -10369,6 +10373,7 @@ c_parser_postfix_expression_after_paren_type (c_parser 
*parser,
   expr.value = build_compound_literal (start_loc, type, init.value, non_const,
   alignas_align);
   set_c_expr_source_range (, init.src_range);
+  expr.m_decimal = 0;
   expr.original_code = ERROR_MARK;
   expr.original_type = NULL;
   if (type != error_mark_node
@@ -10583,6 +10588,7 @@ c_parser_postfix_expression_after_primary (c_parser 
*parser,
  set_c_expr_source_range (, start, finish);
  expr.original_code = ERROR_MARK;
  expr.original_type = NULL;
+ expr.m_decimal = 0;
  break;
case CPP_OPEN_PAREN:
  /* Function call.  */
@@ -10631,6 +10637,7 @@ c_parser_postfix_expression_after_primary (c_parser 
*parser,
= 

[PATCH 1/2] libstdc++: Optimize is_void and is_null_pointer

[Patrick Palka via Gcc-patches]

Instead of defining these in terms of a helper class template
and the relatively expensive __remove_cv_t, just declare four
explicit specializations of the main template, one for each choice
of cv-quals.

Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
The is_void change alone reduces memory usage for join.cc by
almost 1%.

libstdc++-v3/ChangeLog:

* include/std/type_traits (__is_void_helper): Remove.
(is_void): Make the primary template derive from false_type,
and define four explicit specializations that derive from
true_type.
(__is_null_pointer_helper, is_null_pointer): Likewise.
---
 libstdc++-v3/include/std/type_traits | 48 ++--
 1 file changed, 31 insertions(+), 17 deletions(-)

diff --git a/libstdc++-v3/include/std/type_traits 
b/libstdc++-v3/include/std/type_traits
index e4d167939d9..b83e7257a9f 100644
--- a/libstdc++-v3/include/std/type_traits
+++ b/libstdc++-v3/include/std/type_traits
@@ -289,23 +289,30 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   // __remove_cv_t (std::remove_cv_t for C++11).
   template
 using __remove_cv_t = typename remove_cv<_Tp>::type;
+  /// @endcond
 
   // Primary type categories.
 
-  template
-struct __is_void_helper
+  /// is_void
+  template
+struct is_void
 : public false_type { };
 
   template<>
-struct __is_void_helper
+struct is_void
 : public true_type { };
-  /// @endcond
 
-  /// is_void
-  template
-struct is_void
-: public __is_void_helper<__remove_cv_t<_Tp>>::type
-{ };
+  template<>
+struct is_void
+: public true_type { };
+
+  template<>
+struct is_void
+: public true_type { };
+
+  template<>
+struct is_void
+: public true_type { };
 
   /// @cond undocumented
   template
@@ -571,19 +578,26 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
 #define __cpp_lib_is_null_pointer 201309L
 
-  template
-struct __is_null_pointer_helper
+  /// is_null_pointer (LWG 2247).
+  template
+struct is_null_pointer
 : public false_type { };
 
   template<>
-struct __is_null_pointer_helper
+struct is_null_pointer
 : public true_type { };
 
-  /// is_null_pointer (LWG 2247).
-  template
-struct is_null_pointer
-: public __is_null_pointer_helper<__remove_cv_t<_Tp>>::type
-{ };
+  template<>
+struct is_null_pointer
+: public true_type { };
+
+  template<>
+struct is_null_pointer
+: public true_type { };
+
+  template<>
+struct is_null_pointer
+: public true_type { };
 
   /// __is_nullptr_t (deprecated extension).
   /// @deprecated Non-standard. Use `is_null_pointer` instead.
-- 
2.37.3.518.g79f2338b37

[PATCH 2/2] libstdc++: Optimize is_reference

[Patrick Palka via Gcc-patches]

Instead of defining is_reference in terms of is_lvalue_reference
and is_rvalue_reference, just define it directly.

Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
This reduces memory usage of join.cc by 1%.

libstdc++-v3/ChangeLog:

* include/std/type_traits (is_reference): Make the primary
template derive from false_type.  Define two partial
specializations that derive from true_type.
---
 libstdc++-v3/include/std/type_traits | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/libstdc++-v3/include/std/type_traits 
b/libstdc++-v3/include/std/type_traits
index b83e7257a9f..94e73eafd2f 100644
--- a/libstdc++-v3/include/std/type_traits
+++ b/libstdc++-v3/include/std/type_traits
@@ -611,8 +611,17 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   /// is_reference
   template
 struct is_reference
-: public __or_,
-   is_rvalue_reference<_Tp>>::type
+: public false_type
+{ };
+
+  template
+struct is_reference<_Tp&>
+: public true_type
+{ };
+
+  template
+struct is_reference<_Tp&&>
+: public true_type
 { };
 
   /// is_arithmetic
-- 
2.37.3.518.g79f2338b37

[GCC13][Patch][V4][PATCH 1/2] Add a new option -fstrict-flex-arrays[=n] and new attribute strict_flex_arrays

[Qing Zhao via Gcc-patches]

Add the following new option -fstrict-flex-arrays[=n] and a corresponding
attribute strict_flex_arrays to GCC:

'-fstrict-flex-arrays'
 Treat the trailing array of a structure as a flexible array member
 in a stricter way.  The positive form is equivalent to
 '-fstrict-flex-arrays=3', which is the strictest.  A trailing array
 is treated as a flexible array member only when it is declared as a
 flexible array member per C99 standard onwards.  The negative form
 is equivalent to '-fstrict-flex-arrays=0', which is the least
 strict.  All trailing arrays of structures are treated as flexible
 array members.

'-fstrict-flex-arrays=LEVEL'
 Treat the trailing array of a structure as a flexible array member
 in a stricter way.  The value of LEVEL controls the level of
 strictness.

 The possible values of LEVEL are the same as for the
 'strict_flex_arrays' attribute (*note Variable Attributes::).

 You can control this behavior for a specific trailing array field
 of a structure by using the variable attribute 'strict_flex_arrays'
 attribute (*note Variable Attributes::).

'strict_flex_arrays (LEVEL)'
 The 'strict_flex_arrays' attribute should be attached to the
 trailing array field of a structure.  It specifies the level of
 strictness of treating the trailing array field of a structure as a
 flexible array member.  LEVEL must be an integer betwen 0 to 3.

 LEVEL=0 is the least strict level, all trailing arrays of
 structures are treated as flexible array members.  LEVEL=3 is the
 strictest level, only when the trailing array is declared as a
 flexible array member per C99 standard onwards ('[]'), it is
 treated as a flexible array member.

 There are two more levels in between 0 and 3, which are provided to
 support older codes that use GCC zero-length array extension
 ('[0]') or one-size array as flexible array member ('[1]'): When
 LEVEL is 1, the trailing array is treated as a flexible array
 member when it is declared as either '[]', '[0]', or '[1]'; When
 LEVEL is 2, the trailing array is treated as a flexible array
 member when it is declared as either '[]', or '[0]'.

 This attribute can be used with or without the
 '-fstrict-flex-arrays'.  When both the attribute and the option
 present at the same time, the level of the strictness for the
 specific trailing array field is determined by the attribute.

gcc/c-family/ChangeLog:

* c-attribs.cc (handle_strict_flex_arrays_attribute): New function.
(c_common_attribute_table): New item for strict_flex_arrays.
* c.opt: (fstrict-flex-arrays): New option.
(fstrict-flex-arrays=): New option.

gcc/c/ChangeLog:

* c-decl.cc (flexible_array_member_type_p): New function.
(one_element_array_type_p): Likewise.
(zero_length_array_type_p): Likewise.
(add_flexible_array_elts_to_size): Call new utility
routine flexible_array_member_type_p.
(is_flexible_array_member_p): New function.
(finish_struct): Set the new DECL_NOT_FLEXARRAY flag.

gcc/cp/ChangeLog:

* module.cc (trees_out::core_bools): Stream out new bit
decl_not_flexarray.
(trees_in::core_bools): Stream in new bit decl_not_flexarray.

gcc/ChangeLog:

* doc/extend.texi: Document strict_flex_arrays attribute.
* doc/invoke.texi: Document -fstrict-flex-arrays[=n] option.
* print-tree.cc (print_node): Print new bit decl_not_flexarray.
* tree-core.h (struct tree_decl_common): New bit field
decl_not_flexarray.
* tree-streamer-in.cc (unpack_ts_decl_common_value_fields): Stream
in new bit decl_not_flexarray.
* tree-streamer-out.cc (pack_ts_decl_common_value_fields): Stream
out new bit decl_not_flexarray.
* tree.cc (array_at_struct_end_p): Update it with the new bit field
decl_not_flexarray.
* tree.h (DECL_NOT_FLEXARRAY): New flag.

gcc/testsuite/ChangeLog:

* g++.dg/strict-flex-array-1.C: New test.
* gcc.dg/strict-flex-array-1.c: New test.
---
 gcc/c-family/c-attribs.cc  |  47 
 gcc/c-family/c.opt |   7 ++
 gcc/c/c-decl.cc| 130 +++--
 gcc/cp/module.cc   |   2 +
 gcc/doc/extend.texi|  25 
 gcc/doc/invoke.texi|  27 -
 gcc/print-tree.cc  |   8 +-
 gcc/testsuite/g++.dg/strict-flex-array-1.C |  31 +
 gcc/testsuite/gcc.dg/strict-flex-array-1.c |  31 +
 gcc/tree-core.h|   5 +-
 gcc/tree-streamer-in.cc|   1 +
 gcc/tree-streamer-out.cc   |   1 +
 gcc/tree.cc|  45 +--
 gcc/tree.h |  14 ++-
 14 files changed, 346 insertions(+), 28 deletions(-)

[GCC13][Patch][V4][PATCH 2/2] Use array_at_struct_end_p in __builtin_object_size [PR101836]

[Qing Zhao via Gcc-patches]

Use array_at_struct_end_p to determine whether the trailing array
of a structure is flexible array member in __builtin_object_size.

gcc/ChangeLog:

PR tree-optimization/101836
* tree-object-size.cc (addr_object_size): Use array_at_struct_end_p
to determine a flexible array member reference.

gcc/testsuite/ChangeLog:

PR tree-optimization/101836
* gcc.dg/pr101836.c: New test.
* gcc.dg/pr101836_1.c: New test.
* gcc.dg/pr101836_2.c: New test.
* gcc.dg/pr101836_3.c: New test.
* gcc.dg/pr101836_4.c: New test.
* gcc.dg/pr101836_5.c: New test.
* gcc.dg/strict-flex-array-2.c: New test.
* gcc.dg/strict-flex-array-3.c: New test.
---
 gcc/testsuite/gcc.dg/pr101836.c| 60 ++
 gcc/testsuite/gcc.dg/pr101836_1.c  | 60 ++
 gcc/testsuite/gcc.dg/pr101836_2.c  | 60 ++
 gcc/testsuite/gcc.dg/pr101836_3.c  | 60 ++
 gcc/testsuite/gcc.dg/pr101836_4.c  | 60 ++
 gcc/testsuite/gcc.dg/pr101836_5.c  | 60 ++
 gcc/testsuite/gcc.dg/strict-flex-array-2.c | 60 ++
 gcc/testsuite/gcc.dg/strict-flex-array-3.c | 60 ++
 gcc/tree-object-size.cc| 16 +++---
 9 files changed, 487 insertions(+), 9 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/pr101836.c
 create mode 100644 gcc/testsuite/gcc.dg/pr101836_1.c
 create mode 100644 gcc/testsuite/gcc.dg/pr101836_2.c
 create mode 100644 gcc/testsuite/gcc.dg/pr101836_3.c
 create mode 100644 gcc/testsuite/gcc.dg/pr101836_4.c
 create mode 100644 gcc/testsuite/gcc.dg/pr101836_5.c
 create mode 100644 gcc/testsuite/gcc.dg/strict-flex-array-2.c
 create mode 100644 gcc/testsuite/gcc.dg/strict-flex-array-3.c

diff --git a/gcc/testsuite/gcc.dg/pr101836.c b/gcc/testsuite/gcc.dg/pr101836.c
new file mode 100644
index ..efad02cfe899
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr101836.c
@@ -0,0 +1,60 @@
+/* -fstrict-flex-arrays is aliased with -ftrict-flex-arrays=3, which is the
+   strictest, only [] is treated as flexible array.  */ 
+/* PR tree-optimization/101836 */
+/* { dg-do run } */
+/* { dg-options "-O2 -fstrict-flex-arrays" } */
+
+#include 
+
+#define expect(p, _v) do { \
+size_t v = _v; \
+if (p == v) \
+printf("ok:  %s == %zd\n", #p, p); \
+else \
+   {  \
+  printf("WAT: %s == %zd (expected %zd)\n", #p, p, v); \
+ __builtin_abort (); \
+   } \
+} while (0);
+
+struct trailing_array_1 {
+int a;
+int b;
+int c[4];
+};
+
+struct trailing_array_2 {
+int a;
+int b;
+int c[1];
+};
+
+struct trailing_array_3 {
+int a;
+int b;
+int c[0];
+};
+struct trailing_array_4 {
+int a;
+int b;
+int c[];
+};
+
+void __attribute__((__noinline__)) stuff(
+struct trailing_array_1 *normal,
+struct trailing_array_2 *trailing_1,
+struct trailing_array_3 *trailing_0,
+struct trailing_array_4 *trailing_flex)
+{
+expect(__builtin_object_size(normal->c, 1), 16);
+expect(__builtin_object_size(trailing_1->c, 1), 4);
+expect(__builtin_object_size(trailing_0->c, 1), 0);
+expect(__builtin_object_size(trailing_flex->c, 1), -1);
+}
+
+int main(int argc, char *argv[])
+{
+stuff((void *)argv[0], (void *)argv[0], (void *)argv[0], (void *)argv[0]);
+
+return 0;
+}
diff --git a/gcc/testsuite/gcc.dg/pr101836_1.c 
b/gcc/testsuite/gcc.dg/pr101836_1.c
new file mode 100644
index ..e2931ce1012e
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr101836_1.c
@@ -0,0 +1,60 @@
+/* -fstrict-flex-arrays=3 is the strictest, only [] is treated as
+   flexible array.  */ 
+/* PR tree-optimization/101836 */
+/* { dg-do run } */
+/* { dg-options "-O2 -fstrict-flex-arrays=3" } */
+
+#include 
+
+#define expect(p, _v) do { \
+size_t v = _v; \
+if (p == v) \
+printf("ok:  %s == %zd\n", #p, p); \
+else \
+   {  \
+  printf("WAT: %s == %zd (expected %zd)\n", #p, p, v); \
+ __builtin_abort (); \
+   } \
+} while (0);
+
+struct trailing_array_1 {
+int a;
+int b;
+int c[4];
+};
+
+struct trailing_array_2 {
+int a;
+int b;
+int c[1];
+};
+
+struct trailing_array_3 {
+int a;
+int b;
+int c[0];
+};
+struct trailing_array_4 {
+int a;
+int b;
+int c[];
+};
+
+void __attribute__((__noinline__)) stuff(
+struct trailing_array_1 *normal,
+struct trailing_array_2 *trailing_1,
+struct trailing_array_3 *trailing_0,
+struct trailing_array_4 *trailing_flex)
+{
+expect(__builtin_object_size(normal->c, 1), 16);
+expect(__builtin_object_size(trailing_1->c, 1), 4);
+expect(__builtin_object_size(trailing_0->c, 1), 0);
+expect(__builtin_object_size(trailing_flex->c, 1), -1);
+}
+
+int main(int argc, char *argv[])
+{
+stuff((void *)argv[0], (void *)argv[0], (void *)argv[0], (void *)argv[0]);
+
+ 

[GCC13][Patch][V4][PATCH 0/2] Add a new option -fstrict-flex-array[=n] and attribute strict_flex_array(n) and use it in PR101836

[Qing Zhao via Gcc-patches]

This is the 4th version of the patch set.
Compare to the 3rd version, the following are the major change:

1. delete all the warnings for the confliction between -std and
-fstrict-flex-arrays per our discussion.
2. delete all the related testing cases for these warnings.
3. update all the wording changes, and documentation format changes
recommanded by Joseph.
I have bootstrapped and regression tested on both aarch64 and x86, no issues.

Let me know if you have any comments on the patches.

thanks.

Qing Zhao (2):
  Add a new option -fstrict-flex-arrays[=n] and new attribute
strict_flex_arrays
  Use array_at_struct_end_p in __builtin_object_size [PR101836]

 gcc/c-family/c-attribs.cc  |  47 
 gcc/c-family/c.opt |   7 ++
 gcc/c/c-decl.cc| 130 +++--
 gcc/cp/module.cc   |   2 +
 gcc/doc/extend.texi|  25 
 gcc/doc/invoke.texi|  27 -
 gcc/print-tree.cc  |   8 +-
 gcc/testsuite/g++.dg/strict-flex-array-1.C |  31 +
 gcc/testsuite/gcc.dg/pr101836.c|  60 ++
 gcc/testsuite/gcc.dg/pr101836_1.c  |  60 ++
 gcc/testsuite/gcc.dg/pr101836_2.c  |  60 ++
 gcc/testsuite/gcc.dg/pr101836_3.c  |  60 ++
 gcc/testsuite/gcc.dg/pr101836_4.c  |  60 ++
 gcc/testsuite/gcc.dg/pr101836_5.c  |  60 ++
 gcc/testsuite/gcc.dg/strict-flex-array-1.c |  31 +
 gcc/testsuite/gcc.dg/strict-flex-array-2.c |  60 ++
 gcc/testsuite/gcc.dg/strict-flex-array-3.c |  60 ++
 gcc/tree-core.h|   5 +-
 gcc/tree-object-size.cc|  16 ++-
 gcc/tree-streamer-in.cc|   1 +
 gcc/tree-streamer-out.cc   |   1 +
 gcc/tree.cc|  45 +--
 gcc/tree.h |  14 ++-
 23 files changed, 833 insertions(+), 37 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/strict-flex-array-1.C
 create mode 100644 gcc/testsuite/gcc.dg/pr101836.c
 create mode 100644 gcc/testsuite/gcc.dg/pr101836_1.c
 create mode 100644 gcc/testsuite/gcc.dg/pr101836_2.c
 create mode 100644 gcc/testsuite/gcc.dg/pr101836_3.c
 create mode 100644 gcc/testsuite/gcc.dg/pr101836_4.c
 create mode 100644 gcc/testsuite/gcc.dg/pr101836_5.c
 create mode 100644 gcc/testsuite/gcc.dg/strict-flex-array-1.c
 create mode 100644 gcc/testsuite/gcc.dg/strict-flex-array-2.c
 create mode 100644 gcc/testsuite/gcc.dg/strict-flex-array-3.c

-- 
2.31.1

Re: [PATCH] Improve converting between 128-bit modes that use the same format

[Segher Boessenkool]

On Fri, Sep 02, 2022 at 01:51:33PM -0400, Michael Meissner wrote:
> On Tue, Aug 23, 2022 at 04:13:45PM -0500, Segher Boessenkool wrote:
> > Please do not send new patches as replies to other patches.
> 
> This was sent as a new patch.

It probably was the partially copied to the mail body subject line that
confused me.  Sorry.

> > On Thu, Aug 18, 2022 at 05:48:29PM -0400, Michael Meissner wrote:
> > > mprove converting between 128-bit modes that use the same format.
> >
> > You are missing some characters?  But this is an edited version of the
> > subject anyway.  Just don't do that (neither the copying or the
> > editing), it just confuses things.
> 
> That is the first line from the git commit, which git format-patch puts as the
> subject.  I accidently deleted a few extra characters when trimming it down (I
> remove the From:, etc. lines from the format-patch output).  But I can just
> delete this line if desired.

Don't copy that line in the first place?  Don't copy *anything* in fact,
the way you copied stuff in that other patch (which is very hard to
review, so it will have to wait a bit more) makes it impossible to
apply the patch (which whould be just git-am).

> > Please factor this patch into more pieces, pieces that can be reviewed
> > more easily, pieces that change one thing only.

Please do this.  It is the biggest problem I have with most of your
patches: you seem to save up development of a week, and then send it out
as big omnibus patch an hour or two before my weekend.  This is not
ideal.

> > > +(define_expand "extendkfif2"
> > > +  [(set (match_operand:IF 0 "gpc_reg_operand")
> > > + (float_extend:IF (match_operand:KF 1 "gpc_reg_operand")))]
> > > +  "TARGET_FLOAT128_TYPE"
> > > +{
> > > +  rs6000_expand_float128_convert (operands[0], operands[1], false);
> > > +  DONE;
> > > +})
> > 
> > This does not belong here.
> > 
> > It really shouldn't *exist* at all: this is *not* a float_extend!  It is
> > not converting to a wider mode (as required!), but not even to a mode of
> > higher precision: both IFmode and KFmode can represent (finite, normal)
> > numbers the other can not.
> 
> We know that TFmode (if -mabi=ieeelongdouble) and KFmode are the same, just
> like TFmode (if -mabi=ibmlongdouble) and IFmode are the same.  But RTL does 
> not
> know that these modes use the same representation.  So to convert between 
> them,
> it needs to use either FLOAT_EXTEND or FLOAT_TRUNCATE, depending on which
> precision each of the three modes have (i.e. rs6000-modes.h).  So you need
> these conversions in RTL.

You have "extends" also when it is to a lower precision!

Also, let me say this again: this needs to be solved.  We cannot make
real progress as long as we keep pretending every pait of floating point
modes can be ordered.

> Unfortunately, you can't just use SUBREG before register allocation is done.

Why not?  It isn't valid (in all cases) *after* RA, but before is fine.

But you do not want a subreg, you need a conversion.

> > But it certainly does not belong here in the middle of no-op moves.

This is still very true.

> So for example, for IBM floating point my current patches are:

> But for the IEEE side, combining the two insns won't work, since going from
> TFmode to KFmode will generate a FLOAT_TRUNCATE instead of a FLOAT_EXTEND.

Yes.  Please just fix the code depending on fundamentally wrong and
unworkable assumptions, instead of adding perpetually worse workarounds
that make things more rickety all the time.

When you added this IF/KF/TF ordering stuff first, I was amazed that it
worked as well as it did.  And this was perhaps the best we could do for
GCC 10, sure.  But the problem should have been fixed since, there is no
sane way forward without doing that.

> > > +;; Convert between KFmode and TFmode when -mabi=ieeelongdouble
> > > +(define_insn_and_split "*extendkftf2_internal"
> > 
> > Same for IEEE128.  And this isn't a conversion at all (it's a no-op
> > move), please don't confuse things by saying it is.
> 
> That is how RTL goes between modes.  Without a whole lot of changes to the
> machine independent portion of the compiler, I don't see anyway of avoiding 
> the
> converts.

It is not a conversion, not in RTL either.  It changes mode, it doesn't
change values.  That is not the same thing.  It's a subreg (one of the
five overloaded meanings of subregs, but :-) )

> > > +(define_insn_and_split "*extendtfif2_internal"
> > > +  [(set (match_operand:IF 0 "gpc_reg_operand" "=d,")
> > > + (float_extend:IF
> > > +  (match_operand:TF 1 "input_operand" "0,d")))]
> > > +   "FLOAT128_IBM_P (TFmode)"
> > > +  "#"
> > > +  "&& reload_completed"
> > 
> > Why would this ever need reload_completed?  It is a no-op move!
> 
> Various predicates do not allow SUBREG's of these types before register
> allocation.

Modes, not types, and I do not understand what you mean.  Please show an
example?

Either way that is not a reason to do fully the wrong thing.  It might
make doing the 

c: New C2x keywords

[Joseph Myers]

C2x follows C++ in making alignas, alignof, bool, false,
static_assert, thread_local and true keywords; implement this
accordingly.  This implementation makes them normal keywords in C2x
mode just like any other keyword (C2x leaves open the possibility of
implementation using predefined macros instead - thus, there aren't
any testcases asserting that they aren't macros).  As in C++ and
previous versions of C, true and false are handled like signed 1 and 0
in #if (there was an intermediate state in some C2x drafts where they
had different macro expansions that were unsigned in #if).

Bootstrapped with no regressions for x86_64-pc-linux-gnu.  OK to commit 
(stdalign.h and stdbool.h changes)?

As with the removal of unprototyped functions, this change has a high
risk of breaking some old code and people doing GNU/Linux distribution
builds may wish to see how much is broken in a build with a -std=gnu2x
default.

gcc/
* ginclude/stdalign.h [defined __STDC_VERSION__ &&
__STDC_VERSION__ > 201710L]: Disable all content.
* ginclude/stdbool.h [defined __STDC_VERSION__ && __STDC_VERSION__
> 201710L] (bool, true, false): Do not define.

gcc/c-family/
* c-common.cc (c_common_reswords): Use D_C2X instead of D_CXXONLY
for alignas, alignof, bool, false, static_assert, thread_local and
true.

gcc/c/
* c-parser.cc (c_parser_static_assert_declaration_no_semi)
(c_parser_alignas_specifier, c_parser_alignof_expression): Allow
for C2x spellings of keywords.
(c_parser_postfix_expression): Handle RID_TRUE and RID_FALSE.

gcc/testsuite/
* gcc.dg/c11-keywords-1.c, gcc.dg/c2x-align-1.c,
gcc.dg/c2x-align-6.c, gcc.dg/c2x-bool-2.c,
gcc.dg/c2x-static-assert-3.c, gcc.dg/c2x-static-assert-4.c,
gcc.dg/c2x-thread-local-1.c: New tests.
* gcc.dg/c2x-bool-1.c: Update expectations.

libcpp/
* include/cpplib.h (struct cpp_options): Add true_false.
* expr.cc (eval_token): Check true_false not cplusplus to
determine whether to handle true and false keywords.
* init.cc (struct lang_flags): Add true_false.
(lang_defaults): Update.
(cpp_set_lang): Set true_false.

diff --git a/gcc/c-family/c-common.cc b/gcc/c-family/c-common.cc
index 9746504195b..0a5b7e120c9 100644
--- a/gcc/c-family/c-common.cc
+++ b/gcc/c-family/c-common.cc
@@ -459,11 +459,11 @@ const struct c_common_resword c_common_reswords[] =
   { "__GIMPLE",RID_GIMPLE, D_CONLY },
   { "__PHI",   RID_PHI,D_CONLY },
   { "__RTL",   RID_RTL,D_CONLY },
-  { "alignas", RID_ALIGNAS,D_CXXONLY | D_CXX11 | D_CXXWARN },
-  { "alignof", RID_ALIGNOF,D_CXXONLY | D_CXX11 | D_CXXWARN },
+  { "alignas", RID_ALIGNAS,D_C2X | D_CXX11 | D_CXXWARN },
+  { "alignof", RID_ALIGNOF,D_C2X | D_CXX11 | D_CXXWARN },
   { "asm", RID_ASM,D_ASM },
   { "auto",RID_AUTO,   0 },
-  { "bool",RID_BOOL,   D_CXXONLY | D_CXXWARN },
+  { "bool",RID_BOOL,   D_C2X | D_CXXWARN },
   { "break",   RID_BREAK,  0 },
   { "case",RID_CASE,   0 },
   { "catch",   RID_CATCH,  D_CXX_OBJC | D_CXXWARN },
@@ -489,7 +489,7 @@ const struct c_common_resword c_common_reswords[] =
   { "explicit",RID_EXPLICIT,   D_CXXONLY | D_CXXWARN },
   { "export",  RID_EXPORT, D_CXXONLY | D_CXXWARN },
   { "extern",  RID_EXTERN, 0 },
-  { "false",   RID_FALSE,  D_CXXONLY | D_CXXWARN },
+  { "false",   RID_FALSE,  D_C2X | D_CXXWARN },
   { "float",   RID_FLOAT,  0 },
   { "for", RID_FOR,0 },
   { "friend",  RID_FRIEND, D_CXXONLY | D_CXXWARN },
@@ -515,15 +515,15 @@ const struct c_common_resword c_common_reswords[] =
   { "signed",  RID_SIGNED, 0 },
   { "sizeof",  RID_SIZEOF, 0 },
   { "static",  RID_STATIC, 0 },
-  { "static_assert",RID_STATIC_ASSERT, D_CXXONLY | D_CXX11 | D_CXXWARN },
+  { "static_assert",RID_STATIC_ASSERT, D_C2X | D_CXX11 | D_CXXWARN },
   { "static_cast", RID_STATCAST,   D_CXXONLY | D_CXXWARN },
   { "struct",  RID_STRUCT, 0 },
   { "switch",  RID_SWITCH, 0 },
   { "template",RID_TEMPLATE,   D_CXXONLY | D_CXXWARN },
   { "this",RID_THIS,   D_CXXONLY | D_CXXWARN },
-  { "thread_local",RID_THREAD, D_CXXONLY | D_CXX11 | D_CXXWARN },
+  { "thread_local",RID_THREAD, D_C2X | D_CXX11 | D_CXXWARN },
   { "throw",   RID_THROW,  D_CXX_OBJC | D_CXXWARN },
-  { "true",RID_TRUE,   D_CXXONLY | D_CXXWARN },
+  { "true",RID_TRUE,   D_C2X | D_CXXWARN },
   { "try", RID_TRY,D_CXX_OBJC | D_CXXWARN },
   { "typedef", RID_TYPEDEF,0 },
   { "typename",RID_TYPENAME,   D_CXXONLY 

Re: [PATCH] d: Fix #error You must define PREFERRED_DEBUGGING_TYPE if DWARF is not supported (PR105659)

[Iain Buclaw via Gcc-patches]

Excerpts from Iain Buclaw's message of September 6, 2022 7:02 pm:
> Excerpts from Rainer Orth's message of September 6, 2022 4:25 pm:
>> Hi Iain,
>> 
 there is indeed ;-)  The previous d21 emits
 
 binary./266566/gcc/d21
 version   v2.100.1
 
 predefs GNU D_Version2 LittleEndian GNU_DWARF2_Exceptions
 GNU_StackGrowsDown GNU_InlineAsm assert D_PreConditions D_PostConditions
 D_Invariants D_ModuleInfo D_Exceptions D_TypeInfo all X86 D_HardFloat
 Posix Solaris CppRuntime_Gcc
 
 while the patched one gives
 
 core.exception.ArrayIndexError@/var/gcc/reghunt/master/gcc/d/dmd/root/stringtable.d(291):
 index [3530971477] is out of bounds for array of length 0
 gcc.deh(505): uncaught exception
 : internal compiler error: Abort
 0x96d5b6c crash_signal
/var/gcc/reghunt/master/gcc/toplev.cc:314
 
>>>
>>> Excellent, and the stage1 compiler?
>> 
>> binary./prev-gcc/d21
>> version   v2.100.1
>> 
>> predefs   GNU D_Version2 LittleEndian GNU_DWARF2_Exceptions 
>> GNU_StackGrowsDown GNU_InlineAsm assert D_PreConditions D_PostConditions 
>> D_Invariants D_ModuleInfo D_Exceptions D_TypeInfo all X86 D_HardFloat Posix 
>> Solaris CppRuntime_Gcc
>> 
>> So identical to the pre-patch one.
>> 
>> Just in case, here's the stacktrace of the crashing d21, filtered
>> through c++filt -s dlang:
>> 
>> Thread 2 received signal SIGABRT, Aborted.
>> [Switching to Thread 1 (LWP 1)]
>> 0xfe1be2e5 in __lwp_sigqueue () from /lib/libc.so.1
>> (gdb) bt
>> #0  0xfe1be2e5 in __lwp_sigqueue () from /lib/libc.so.1
>> #1  0xfe1b62cf in thr_kill () from /lib/libc.so.1
>> #2  0xfe0ed662 in raise () from /lib/libc.so.1
>> #3  0xfe0bae74 in abort () from /lib/libc.so.1
>> #4  0x0a8e786d in gcc.deh.terminate(immutable(char)[], uint) (msg=..., 
>> line=) at 
>> /var/gcc/reghunt/master/libphobos/libdruntime/gcc/deh.d:414
>> #5  0x0a8e7ab3 in _d_throw (object=) at 
>> /var/gcc/reghunt/master/libphobos/libdruntime/gcc/deh.d:505
>> #6  0x0a8edf02 in onArrayIndexError (index=, 
>> length=, file=..., line=) at 
>> /var/gcc/reghunt/master/libphobos/libdruntime/core/exception.d:650
>> #7  0x0a8edf3d in _d_arraybounds_indexp (file=, 
>> line=, index=, length=) at 
>> /var/gcc/reghunt/master/libphobos/libdruntime/core/exception.d:848
>> #8  0x08ffc17a in 
>> dmd.root.stringtable.StringTable!(dmd.identifier.Identifier).StringTable.findSlot(uint,
>>  scope const(char)[]) const (this=..., hash=, str=...) at 
>> /var/gcc/reghunt/master/gcc/d/dmd/root/stringtable.d:291
> 
> Yeah, I don't see how that could trigger, as the value of `i` is always
> adjusted to `i &= (table.length - 1)` (it uses quadratic probing to search
> the hash table).
> 
> The logic of the compiler doesn't appear to have changed, but the data
> layout may have, so I'm suspecting an issue that was always there has
> now surfaced to the fore.
> 

Yes, this is data related. The DSO registry picks up nothing in the
miscompiled stage2 compiler, leaving all data uninitialized.  The stage1
compiler works, and runs all module constructors ahead of compilation.

Iain.

[PATCH v2] libstdc++: Add pretty printer for std::stringstreams

[Philipp Fent via Gcc-patches]

To display (o-,i-)stringstreams in the common case, we just print the
underlying stringbuf, without the many ios_base members. In the
unconventional case that the underlying streambuf was redirected, we
report the redirected target.

Signed-off-by: Philipp Fent 
---
 libstdc++-v3/python/libstdcxx/v6/printers.py  | 56 +++
 .../libstdc++-prettyprinters/debug.cc | 15 +
 .../libstdc++-prettyprinters/simple.cc| 15 +
 .../libstdc++-prettyprinters/simple11.cc  | 15 +
 4 files changed, 101 insertions(+)

diff --git a/libstdc++-v3/python/libstdcxx/v6/printers.py 
b/libstdc++-v3/python/libstdcxx/v6/printers.py
index d70c8d5d616..bd4289c1c62 100644
--- a/libstdc++-v3/python/libstdcxx/v6/printers.py
+++ b/libstdc++-v3/python/libstdcxx/v6/printers.py
@@ -969,6 +969,57 @@ class StdStringPrinter:
 def display_hint (self):
 return 'string'
 
+def access_streambuf_ptrs(streambuf):
+"Access the streambuf put area pointers"
+pbase = streambuf['_M_out_beg']
+pptr = streambuf['_M_out_cur']
+egptr = streambuf['_M_in_end']
+return pbase, pptr, egptr
+
+class StdStringBufPrinter:
+"Print a std::basic_stringbuf"
+
+def __init__(self, _, val):
+self.val = val
+
+def to_string(self):
+(pbase, pptr, egptr) = access_streambuf_ptrs(self.val)
+# Logic from basic_stringbuf::_M_high_mark()
+if pptr:
+if not egptr or pptr > egptr:
+return pbase.string(length = pptr - pbase)
+else:
+return pbase.string(length = egptr - pbase)
+return self.val['_M_string']
+
+def display_hint(self):
+return 'string'
+
+class StdStringStreamPrinter:
+"Print a std::basic_stringstream"
+
+def __init__(self, typename, val):
+self.val = val
+self.typename = typename
+
+# Check if the stream was redirected:
+# This is essentially: val['_M_streambuf'] == 
val['_M_stringbuf'].address
+# However, GDB can't resolve the virtual inheritance, so we do that 
manually
+basetype = [f.type for f in val.type.fields() if f.is_base_class][0]
+gdb.set_convenience_variable('__stream', val.cast(basetype).address)
+self.streambuf = gdb.parse_and_eval('$__stream->rdbuf()')
+self.was_redirected = self.streambuf != val['_M_stringbuf'].address
+
+def to_string(self):
+if self.was_redirected:
+return "%s redirected to %s" % (self.typename, 
self.streambuf.dereference())
+return self.val['_M_stringbuf']
+
+def display_hint(self):
+if self.was_redirected:
+return None
+return 'string'
+
 class Tr1HashtableIterator(Iterator):
 def __init__ (self, hashtable):
 self.buckets = hashtable['_M_buckets']
@@ -2232,6 +2283,11 @@ def build_libstdcxx_dictionary ():
 libstdcxx_printer.add_version('std::', 'initializer_list',
   StdInitializerListPrinter)
 libstdcxx_printer.add_version('std::', 'atomic', StdAtomicPrinter)
+libstdcxx_printer.add_version('std::', 'basic_stringbuf', 
StdStringBufPrinter)
+libstdcxx_printer.add_version('std::__cxx11::', 'basic_stringbuf', 
StdStringBufPrinter)
+for sstream in ('istringstream', 'ostringstream', 'stringstream'):
+libstdcxx_printer.add_version('std::', 'basic_' + sstream, 
StdStringStreamPrinter)
+libstdcxx_printer.add_version('std::__cxx11::', 'basic_' + sstream, 
StdStringStreamPrinter)
 
 # std::regex components
 libstdcxx_printer.add_version('std::__detail::', '_State',
diff --git a/libstdc++-v3/testsuite/libstdc++-prettyprinters/debug.cc 
b/libstdc++-v3/testsuite/libstdc++-prettyprinters/debug.cc
index 98bbc182551..3c6195591c5 100644
--- a/libstdc++-v3/testsuite/libstdc++-prettyprinters/debug.cc
+++ b/libstdc++-v3/testsuite/libstdc++-prettyprinters/debug.cc
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -110,6 +111,20 @@ main()
   __gnu_cxx::slist::iterator slliter = sll.begin();
 // { dg-final { note-test slliter {47} } }
 
+  std::stringstream sstream;
+  sstream << "abc";
+// { dg-final { note-test sstream "\"abc\"" } }
+  std::stringstream ssin("input", std::ios::in);
+// { dg-final { note-test ssin "\"input\"" } }
+  std::istringstream ssin2("input");
+// { dg-final { note-test ssin2 "\"input\"" } }
+  std::ostringstream ssout;
+  ssout << "out";
+// { dg-final { note-test ssout "\"out\"" } }
+  std::stringstream redirected("xxx");
+  
static_cast&>(redirected).rdbuf(sstream.rdbuf());
+// { dg-final { regexp-test redirected {std::.*stringstream redirected to .*} 
} }
+
   std::cout << "\n";
   return 0;// Mark SPOT
 }
diff --git a/libstdc++-v3/testsuite/libstdc++-prettyprinters/simple.cc 
b/libstdc++-v3/testsuite/libstdc++-prettyprinters/simple.cc
index 1f85775bff0..1609ae2c8db 100644
--- a/libstdc++-v3/testsuite/libstdc++-prettyprinters/simple.cc
+++ 

[wwdocs PATCH RFA] contribute: link to kernel doc about patch email

[Jason Merrill via Gcc-patches]

It occurred to me that it would be useful to link to the kernel's documentation
for emailing patches.  OK?

---
 htdocs/contribute.html | 5 +
 1 file changed, 5 insertions(+)

diff --git a/htdocs/contribute.html b/htdocs/contribute.html
index c985b87d..60bcf3f8 100644
--- a/htdocs/contribute.html
+++ b/htdocs/contribute.html
@@ -237,6 +237,11 @@ changing.)  For further information on our source 
repository, see
 the Anonymous read-only Git access and Read-write Git access pages.
 
+Many mail clients break patches pasted into the message body, primarily by
+wrapping long lines.  See
+https://www.kernel.org/doc/html/latest/process/email-clients.html;>
+the Linux kernel documentation for ways to work around this.
+
 (Everything listed here still applies if you can check in the patch
 without further approval under the GCC write access policies, except

base-commit: bc2d2c50bcb470c7020526c3a628267f84509aeb
-- 
2.31.1

[pushed] c++: C++23 operator[] allows default arguments

[Jason Merrill via Gcc-patches]

This usage was intended to be allowed by P2128, but it didn't make it into
the final wording.  Fixed by CWG 2507.

Tested x86_64-pc-linux-gnu, applying to trunk.

DR2507

gcc/cp/ChangeLog:

* decl.cc (grok_op_properties): Return sooner for C++23 op[].

gcc/testsuite/ChangeLog:

* g++.dg/cpp23/subscript8.C: New test.
---
 gcc/cp/decl.cc  | 11 +--
 gcc/testsuite/g++.dg/cpp23/subscript8.C |  7 +++
 2 files changed, 12 insertions(+), 6 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp23/subscript8.C

diff --git a/gcc/cp/decl.cc b/gcc/cp/decl.cc
index b72b2a8456b..6d20765f40c 100644
--- a/gcc/cp/decl.cc
+++ b/gcc/cp/decl.cc
@@ -15331,6 +15331,11 @@ grok_op_properties (tree decl, bool complain)
"operator ()".  */
 return true;
 
+  /* C++23 allows an arbitrary number of parameters and default arguments for
+ operator[], and none of the other checks below apply.  */
+  if (operator_code == ARRAY_REF && cxx_dialect >= cxx23)
+return true;
+
   if (operator_code == COND_EXPR)
 {
   /* 13.4.0.3 */
@@ -15344,10 +15349,6 @@ grok_op_properties (tree decl, bool complain)
 {
   if (!arg)
{
- /* Variadic.  */
- if (operator_code == ARRAY_REF && cxx_dialect >= cxx23)
-   break;
-
  error_at (loc, "%qD must not have variable number of arguments",
decl);
  return false;
@@ -15408,8 +15409,6 @@ grok_op_properties (tree decl, bool complain)
 case OVL_OP_FLAG_BINARY:
   if (arity != 2)
{
- if (operator_code == ARRAY_REF && cxx_dialect >= cxx23)
-   break;
  error_at (loc,
methodp
? G_("%qD must have exactly one argument")
diff --git a/gcc/testsuite/g++.dg/cpp23/subscript8.C 
b/gcc/testsuite/g++.dg/cpp23/subscript8.C
new file mode 100644
index 000..fe000359d41
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp23/subscript8.C
@@ -0,0 +1,7 @@
+// DR2507: Allow default arguments
+// { dg-additional-options {-std=c++23} }
+
+struct A
+{
+  void operator[](int, int = 42);
+};

base-commit: 0a4a2667dc115ca73b552fcabf8570620dfbe55f
-- 
2.31.1

Re: [PATCH v2, rs6000] Change insn condition from TARGET_64BIT to TARGET_POWERPC64 for VSX scalar extract/insert instructions

[Segher Boessenkool]

Hi!

On Mon, Sep 05, 2022 at 02:36:30PM +0800, HAO CHEN GUI wrote:
> On 2/9/2022 下午 11:56, Segher Boessenkool wrote:
> >> -  const signed long __builtin_vsx_scalar_extract_exp (double);
> >> +  const unsigned long long __builtin_vsx_scalar_extract_exp (double);
> >>  VSEEDP xsxexpdp {}
> >>
> >> -  const signed long __builtin_vsx_scalar_extract_sig (double);
> >> +  const unsigned long long __builtin_vsx_scalar_extract_sig (double);
> >>  VSESDP xsxsigdp {}
> > This also brings these legacy builtins in line with the vec_ versions,
> > which are the preferred builtins (they are defined in the PVIPR).
> 
> The return type of vec_ version built-ins are different than their definition
> in PVIPR. In PVIPR, they're vector unsigned int or vector unsigned long long.
> Shall we correct them?
> 
>   const vd __builtin_vsx_extract_exp_dp (vd);
> VEEDP xvxexpdp {}
> 
>   const vf __builtin_vsx_extract_exp_sp (vf);
> VEESP xvxexpsp {}
> 
>   const vd __builtin_vsx_extract_sig_dp (vd);
> VESDP xvxsigdp {}
> 
>   const vf __builtin_vsx_extract_sig_sp (vf);
> VESSP xvxsigsp {}

Those are the vsx_ versions.  I'm not sure what you're asking.

It won't be easy at all to change types from vector integer to vector
float, it will break all over.  A compatibility nightmare.  It is better
if you can show the current stuff cannot ever work, it's not a problem
to replace it in that case.

> >> --- a/gcc/testsuite/gcc.target/powerpc/bfp/scalar-extract-exp-0.c
> >> +++ b/gcc/testsuite/gcc.target/powerpc/bfp/scalar-extract-exp-0.c
> >> @@ -1,7 +1,8 @@
> >> -/* { dg-do compile { target { powerpc*-*-* } } } */
> >> -/* { dg-require-effective-target lp64 } */
> >> -/* { dg-require-effective-target powerpc_p9vector_ok } */
> >> +/* { dg-do compile { target { powerpc*-*-linux* } } } */
> > Why?
> The powerpc*-*-linux* is no need as bfp.exp excludes AIX and Darwin.
> I will modify it.

And powerpc*-*-* is guaranteed in all of gcc.target/powerpc/, so you
need no target clause at all here.

> >>  /* { dg-options "-mdejagnu-cpu=power9" } */
> >> +/* { dg-additional-options "-mpowerpc64" } */
> >> +/* { dg-require-effective-target has_arch_ppc64 } */
> > This is guaranteed already by that -mpowerpc64.
> > 
> > It probably is best if you do not add -mpowerpc64 at all.  That solves
> > both problems, is simpler, and gives better coverage as well :-)
> > 
> > So just use has_arch_ppc64 instead of lp64.  That makes it run on a
> > strict superset of cases :-)
> We commonly do regression test with -m32 and -m64. So if -mpowerpc64 is
> not added, the combination of "-m32/-mpowerpc64" is not tested.

make -k -j60 check 
RUNTESTFLAGS="--target_board=unix'{-m64,-m32,-m32/-mpowerpc64}'"

It is fine to not test -m32/-mpowerpc64 so often, and certaionly not
something I will ask everyone to always do :-)


Segher

Re: [PATCH 1/3] STABS: remove -gstabs and -gxcoff functionality

[David Edelsohn via Gcc-patches]

* dwarf2out.cc (XCOFF_DEBUGGING_INFO): Likewise.
(HAVE_XCOFF_DWARF_EXTRAS): Likewise.
(output_fde): Likewise.
(output_call_frame_info): Likewise.
(have_macinfo): Likewise.
(add_AT_loc_list): Likewise.
(add_AT_view_list): Likewise.
(output_compilation_unit_header): Likewise.
(output_pubnames): Likewise.
(output_aranges): Likewise.
(output_line_info): Likewise.
(output_macinfo): Likewise.
(dwarf2out_finish): Likewise.
(dwarf2out_early_finish): Likewise.

These changes are not correct and break AIX bootstrap.

Those changes are not related to stabs support.  We agreed to remove stabs and

XCOFF stabs support, not GCC DWARF debugging support for AIX.

Also

* configure: Regenerate. Likewise.
* configure.ac: Likewise.

does not list that tests for HAVE_XCOFF_DWARF_EXTRAS was removed, so
the ChangeLog was not accurate.

Again, that test is required for AIX is not part of stabs support.


Please revert this change so that AIX can continue to be bootstrapped
and tested, and we can work together to test a corrected patch.

Thanks, David


On Tue, Sep 6, 2022 at 12:31 PM David Edelsohn  wrote:

> I fully support the plan to remove stabs support, but this patch broke
> bootstrap on AIX.  It seems rather bad policy to remove support for a
> feature without ensuring that the removal does not negatively impact the
> targets touched by the patch.  I should have been explicitly copied on
> these patches and I should have been asked to test the patches before they
> were installed, if for no other reason than politeness and consideration.
>
> Thanks, David
>
>
>

Re: [PATCH] d: Fix #error You must define PREFERRED_DEBUGGING_TYPE if DWARF is not supported (PR105659)

[Iain Buclaw via Gcc-patches]

Excerpts from Rainer Orth's message of September 6, 2022 4:25 pm:
> Hi Iain,
> 
>>> there is indeed ;-)  The previous d21 emits
>>> 
>>> binary./266566/gcc/d21
>>> version   v2.100.1
>>> 
>>> predefs GNU D_Version2 LittleEndian GNU_DWARF2_Exceptions
>>> GNU_StackGrowsDown GNU_InlineAsm assert D_PreConditions D_PostConditions
>>> D_Invariants D_ModuleInfo D_Exceptions D_TypeInfo all X86 D_HardFloat
>>> Posix Solaris CppRuntime_Gcc
>>> 
>>> while the patched one gives
>>> 
>>> core.exception.ArrayIndexError@/var/gcc/reghunt/master/gcc/d/dmd/root/stringtable.d(291):
>>> index [3530971477] is out of bounds for array of length 0
>>> gcc.deh(505): uncaught exception
>>> : internal compiler error: Abort
>>> 0x96d5b6c crash_signal
>>> /var/gcc/reghunt/master/gcc/toplev.cc:314
>>> 
>>
>> Excellent, and the stage1 compiler?
> 
> binary./prev-gcc/d21
> version   v2.100.1
> 
> predefs   GNU D_Version2 LittleEndian GNU_DWARF2_Exceptions 
> GNU_StackGrowsDown GNU_InlineAsm assert D_PreConditions D_PostConditions 
> D_Invariants D_ModuleInfo D_Exceptions D_TypeInfo all X86 D_HardFloat Posix 
> Solaris CppRuntime_Gcc
> 
> So identical to the pre-patch one.
> 
> Just in case, here's the stacktrace of the crashing d21, filtered
> through c++filt -s dlang:
> 
> Thread 2 received signal SIGABRT, Aborted.
> [Switching to Thread 1 (LWP 1)]
> 0xfe1be2e5 in __lwp_sigqueue () from /lib/libc.so.1
> (gdb) bt
> #0  0xfe1be2e5 in __lwp_sigqueue () from /lib/libc.so.1
> #1  0xfe1b62cf in thr_kill () from /lib/libc.so.1
> #2  0xfe0ed662 in raise () from /lib/libc.so.1
> #3  0xfe0bae74 in abort () from /lib/libc.so.1
> #4  0x0a8e786d in gcc.deh.terminate(immutable(char)[], uint) (msg=..., 
> line=) at 
> /var/gcc/reghunt/master/libphobos/libdruntime/gcc/deh.d:414
> #5  0x0a8e7ab3 in _d_throw (object=) at 
> /var/gcc/reghunt/master/libphobos/libdruntime/gcc/deh.d:505
> #6  0x0a8edf02 in onArrayIndexError (index=, length= out>, file=..., line=) at 
> /var/gcc/reghunt/master/libphobos/libdruntime/core/exception.d:650
> #7  0x0a8edf3d in _d_arraybounds_indexp (file=, 
> line=, index=, length=) at 
> /var/gcc/reghunt/master/libphobos/libdruntime/core/exception.d:848
> #8  0x08ffc17a in 
> dmd.root.stringtable.StringTable!(dmd.identifier.Identifier).StringTable.findSlot(uint,
>  scope const(char)[]) const (this=..., hash=, str=...) at 
> /var/gcc/reghunt/master/gcc/d/dmd/root/stringtable.d:291

Yeah, I don't see how that could trigger, as the value of `i` is always
adjusted to `i &= (table.length - 1)` (it uses quadratic probing to search
the hash table).

The logic of the compiler doesn't appear to have changed, but the data
layout may have, so I'm suspecting an issue that was always there has
now surfaced to the fore.

Iain.

Re: [PATCH] Using pli(paddi) and rotate to build 64bit constants

[Segher Boessenkool]

Hi!

On Tue, Sep 06, 2022 at 08:27:56PM +0800, Jiufu Guo wrote:
> +  if (can_create_pseudo_p ())
> + {
> +   /* pli A,H + pli B,L + rldimi A,B,32,0.  */

A is the low one and B is the high one (the one that needs to be
shifted).  rl[wd]imi is one of our very few insns that has the output
register as one of the input registers as well.  "Good" to see not just
the compiler has problems with this, but humans do as well!  ;-)

Otherwise looks good to me.  Okay for trunk with that fixed somehow.
Thanks!


Segher

Re: [PATCH 1/3] STABS: remove -gstabs and -gxcoff functionality

[David Edelsohn via Gcc-patches]

I fully support the plan to remove stabs support, but this patch broke
bootstrap on AIX.  It seems rather bad policy to remove support for a
feature without ensuring that the removal does not negatively impact the
targets touched by the patch.  I should have been explicitly copied on
these patches and I should have been asked to test the patches before they
were installed, if for no other reason than politeness and consideration.

Thanks, David

Re: OpenMP patch ping

[Tobias Burnus]

Follow-up patch ping (updated)

The first listed patches are smaller + should be quicker to be reviewable,
but in terms of priority, it would be good to make some progress on the
larger patches below as well. Especially as the first patches are only
mine ...

Smaller patches
(i) preparing for true reverse offload
 [Patches are rather independent + not complete for offloading.
  I have WIP patch for: finish mapping handling in target.c;
  follow-up to nvptx plugin patch (see there), GCN support
  (stack handling patch + reverse offload func).]
* [Patch][1/3] libgomp: Prepare for reverse offload fn lookup
https://gcc.gnu.org/pipermail/gcc-patches/2022-August/600333.html
* [Patch][2/3] GCN: libgomp+mkoffload.cc: Prepare for reverse offload fn lookup
https://gcc.gnu.org/pipermail/gcc-patches/2022-August/600340.html
* Re: [Patch][2/3][v2] nvptx: libgomp+mkoffload.cc: Prepare for reverse offload 
fn lookup
https://gcc.gnu.org/pipermail/gcc-patches/2022-August/600527.html
* [Patch] libgomp/nvptx: Prepare for reverse-offload callback handling
https://gcc.gnu.org/pipermail/gcc-patches/2022-August/600381.html
* [Patch] libgomp: Add reverse-offload splay tree
https://gcc.gnu.org/pipermail/gcc-patches/2022-August/600390.html

(ii) Other smaller patches:
* [Patch] OpenMP/Fortran: Permit end-clause on directive
https://gcc.gnu.org/pipermail/gcc-patches/2022-August/600433.html
* [Patch] libgomp.texi: Document libmemkind + nvptx/gcn specifics
https://gcc.gnu.org/pipermail/gcc-patches/2022-August/600494.html
* [wwwdocs] gcc-13/changes.html + projects/gomp/: OpenMP update
https://gcc.gnu.org/pipermail/gcc-patches/2022-September/600864.html

(iii) And an RFC patch:
* [Patch] OpenMP: Document ompx warnings + add Fortran omx warning [PR106670]
https://gcc.gnu.org/pipermail/gcc-patches/2022-August/600490.html



Backlog:


On 16.08.22 19:28, Tobias Burnus wrote:

* [Patch] OpenMP, libgomp, gimple: omp_get_max_teams, omp_set_num_teams, and 
omp_{gs}et_teams_thread_limit on offload devices
 https://gcc.gnu.org/pipermail/gcc-patches/2022-August/599278.html
[Depends on just-reviewed nearly ready by-device env patch.
Might see an update tomorrow/next days, once the env patch is revised again.]

* [PATCH 0/3] OpenMP SIMD routines

[Part 1/2 + 2/2 are in; still missing is 3/3]
"[PATCH 3/3] vect: inbranch SIMD clones"
https://gcc.gnu.org/pipermail/gcc-patches/2022-August/599490.html


[PATCH 0/6] OpenMP 5.0: Fortran 
"declare
 mapper" support
https://gcc.gnu.org/pipermail/gcc-patches/2022-June/596036.html
Some review might make sense already; the final commit depends on:
"OpenMP 5.0: C & C++ "declare mapper" support (plus struct rework, etc.)"
which is currently being reworked (cf. links in "PPS"); the much revised
patch is now regression free but still needs to be cleaned up, split and
(re)submitted by Julian.



* [PATCH 0/5] [gfortran] Support for allocate directive (OpenMP 5.0)
 https://gcc.gnu.org/pipermail/gcc-patches/2022-January/588367.html
(already older - but I missed to ping it.)

* [PATCH 00/17] openmp, nvptx, amdgcn: 5.0 Memory Allocators
 https://gcc.gnu.org/pipermail/gcc-patches/2022-July/597976.html
 * Unified-Shared Memory & Pinned Memory

Depending on those:

* [PATCH] OpenMP, libgomp: Handle unified shared memory in 
omp_target_is_accessible.
 https://gcc.gnu.org/pipermail/gcc-patches/2022-May/594187.html

* [PATCH, OpenMP, Fortran] requires unified_shared_memory 1/2: adjust 
libgfortran memory allocators
 https://gcc.gnu.org/pipermail/gcc-patches/2022-August/599703.html
 (Fortran part, required for ...)
* Re: [PATCH, OpenMP, Fortran] requires unified_shared_memory 2/2: insert USM 
allocators into libgfortran
 https://gcc.gnu.org/pipermail/gcc-patches/2022-September/601059.html

And finally:

* [PATCH, libgomp] Fix chunk_size<1 for dynamic schedule
 https://gcc.gnu.org/pipermail/gcc-patches/2022-August/599332.html
(Side remark: some other debugging support like showing the mapping being done 
as stderr output or ... would be nice as well; might depend on a 
libgomp-debug.so and/or -f...(sanitize=openmp or ...); the other open-source 
compiler has something similar.)
Tobias

PS: I hope the list above and the one below is somewhat complete...

* * *

PPS: Tracking patches pending (re)submissions, just that it is not
forgotten on our side:
(revised)
* [PATCH] OpenMP, libgomp: Environment variable syntax extension.
 https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598770.html
Nearly ready – except for minor review comments.

* [PATCH] openmp: fix max_vf setting for amdgcn offloading
 https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598265.html
→ To be updated for review comments.
(Side note: we should at some point find a way to improve target-specific
handling; similar to the are-exceptions-supported issue of PR101544 but
there are more.)

* [OpenMP, nvptx] Use bar.sync/arrive for barriers when tasking is not used

RE: [PATCH] arm: unified syntax for libgcc clear_cache

[Kyrylo Tkachov via Gcc-patches]

Hi Seija,

> -Original Message-
> From: Gcc-patches  bounces+kyrylo.tkachov=arm@gcc.gnu.org> On Behalf Of Seija Kijin via
> Gcc-patches
> Sent: Thursday, August 11, 2022 2:36 PM
> To: gcc-patches@gcc.gnu.org
> Subject: [PATCH] arm: unified syntax for libgcc clear_cache
> 
> The patch to convert all thumb1 code in libgcc to unified syntax
> omitted changing all swi instructions to the current name: svc.
> 
> This patch fixes this case.

This is ok, thanks.
Do you need someone to commit this for you?

Kyrill

> 
> ---
>  libgcc/config/arm/lib1funcs.S | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libgcc/config/arm/lib1funcs.S b/libgcc/config/arm/lib1funcs.S
> index 8c39c9f20a2b..19fa1462ccf3 100644
> --- a/libgcc/config/arm/lib1funcs.S
> +++ b/libgcc/config/arm/lib1funcs.S
> @@ -1522,7 +1522,7 @@ LSYM(Lover12):
>   add r7, r7, #2
>  #endif
>   mov r2, #0
> - swi 0
> + svc 0
>   do_pop {r7}
>   RET
>   FUNC_END clear_cache

Re: [PATCH] d: Fix #error You must define PREFERRED_DEBUGGING_TYPE if DWARF is not supported (PR105659)

[Rainer Orth]

Hi Iain,

>> there is indeed ;-)  The previous d21 emits
>> 
>> binary./266566/gcc/d21
>> version   v2.100.1
>> 
>> predefs GNU D_Version2 LittleEndian GNU_DWARF2_Exceptions
>> GNU_StackGrowsDown GNU_InlineAsm assert D_PreConditions D_PostConditions
>> D_Invariants D_ModuleInfo D_Exceptions D_TypeInfo all X86 D_HardFloat
>> Posix Solaris CppRuntime_Gcc
>> 
>> while the patched one gives
>> 
>> core.exception.ArrayIndexError@/var/gcc/reghunt/master/gcc/d/dmd/root/stringtable.d(291):
>> index [3530971477] is out of bounds for array of length 0
>> gcc.deh(505): uncaught exception
>> : internal compiler error: Abort
>> 0x96d5b6c crash_signal
>>  /var/gcc/reghunt/master/gcc/toplev.cc:314
>> 
>
> Excellent, and the stage1 compiler?

binary./prev-gcc/d21
version   v2.100.1

predefs   GNU D_Version2 LittleEndian GNU_DWARF2_Exceptions GNU_StackGrowsDown 
GNU_InlineAsm assert D_PreConditions D_PostConditions D_Invariants D_ModuleInfo 
D_Exceptions D_TypeInfo all X86 D_HardFloat Posix Solaris CppRuntime_Gcc

So identical to the pre-patch one.

Just in case, here's the stacktrace of the crashing d21, filtered
through c++filt -s dlang:

Thread 2 received signal SIGABRT, Aborted.
[Switching to Thread 1 (LWP 1)]
0xfe1be2e5 in __lwp_sigqueue () from /lib/libc.so.1
(gdb) bt
#0  0xfe1be2e5 in __lwp_sigqueue () from /lib/libc.so.1
#1  0xfe1b62cf in thr_kill () from /lib/libc.so.1
#2  0xfe0ed662 in raise () from /lib/libc.so.1
#3  0xfe0bae74 in abort () from /lib/libc.so.1
#4  0x0a8e786d in gcc.deh.terminate(immutable(char)[], uint) (msg=..., 
line=) at 
/var/gcc/reghunt/master/libphobos/libdruntime/gcc/deh.d:414
#5  0x0a8e7ab3 in _d_throw (object=) at 
/var/gcc/reghunt/master/libphobos/libdruntime/gcc/deh.d:505
#6  0x0a8edf02 in onArrayIndexError (index=, length=, file=..., line=) at 
/var/gcc/reghunt/master/libphobos/libdruntime/core/exception.d:650
#7  0x0a8edf3d in _d_arraybounds_indexp (file=, line=, index=, length=) at 
/var/gcc/reghunt/master/libphobos/libdruntime/core/exception.d:848
#8  0x08ffc17a in 
dmd.root.stringtable.StringTable!(dmd.identifier.Identifier).StringTable.findSlot(uint,
 scope const(char)[]) const (this=..., hash=, str=...) at 
/var/gcc/reghunt/master/gcc/d/dmd/root/stringtable.d:291
#9  0x08ffc37e in 
dmd.root.stringtable.StringTable!(dmd.identifier.Identifier).StringTable.update(scope
 const(char)[]) (this=..., str=...) at 
/var/gcc/reghunt/master/gcc/d/dmd/root/stringtable.d:184
#10 0x08ffc7b9 in dmd.identifier.Identifier.idPool(const(char)[], bool) 
(isAnonymous=false, s=...) at /var/gc110
#16 toplev::main (this=, argc=, argv=) at /var/gcc/reghunt/master/gcc/toplev.cc:2277
#17 0x0a828851 in main (argc=3, argv=0xfeffdb98) at 
/var/gcc/reghunt/master/gcc/main.cc:39

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: [PATCH] d: Fix #error You must define PREFERRED_DEBUGGING_TYPE if DWARF is not supported (PR105659)

[Iain Buclaw via Gcc-patches]

Excerpts from Rainer Orth's message of September 6, 2022 2:04 pm:
> Hi Iain,
> 
>> Is there a difference in output from `./gcc/d21 -quiet -v` ?
>>
>> Pay attention to any predefs that have suddenly appeared or disappeared.
> 
> there is indeed ;-)  The previous d21 emits
> 
> binary./266566/gcc/d21
> version   v2.100.1
> 
> predefs   GNU D_Version2 LittleEndian GNU_DWARF2_Exceptions 
> GNU_StackGrowsDown GNU_InlineAsm assert D_PreConditions D_PostConditions 
> D_Invariants D_ModuleInfo D_Exceptions D_TypeInfo all X86 D_HardFloat Posix 
> Solaris CppRuntime_Gcc
> 
> while the patched one gives
> 
> core.exception.ArrayIndexError@/var/gcc/reghunt/master/gcc/d/dmd/root/stringtable.d(291):
>  index [3530971477] is out of bounds for array of length 0
> gcc.deh(505): uncaught exception
> : internal compiler error: Abort
> 0x96d5b6c crash_signal
>   /var/gcc/reghunt/master/gcc/toplev.cc:314
> 

Excellent, and the stage1 compiler?

Iain.

Re: [PATCH] expand: Convert cst - x into cst xor x.

[Robin Dapp via Gcc-patches]

> cost might also depend on the context in case flag setting
> behavior differs for xor vs sub (on x86 sub looks strictly more
> powerful here).  The same is probably true when looking for
> a combination with another bitwise operation.
> 
> Btw, why not perform the optimization in expand_binop?  That
> for example already does
> 
>   if (binoptab == sub_optab && CONST_INT_P (op1))
> {
>   op1 = negate_rtx (mode, op1);
>   binoptab = add_optab;
> }
> 
> alternatively a targets expander can do the selection as well.

I was under the impression optabs/expand_binops is only supposed to
"optimize" when it's clear that it is an optimization/canonicalization.
I didn't see other functions there trying two alternatives and also none
seems to use range information already.

Regarding the proper costing (including the surroundings): is it even
possible to encompass everything in such a localized decision? A
target's expander decision would also not take this into account when
deciding? If so, should we not perform this conversion generally and not
only target specifc?

Regards
 Robin

Re: [PATCH] Fortran: Add IEEE_SIGNBIT and IEEE_FMA functions

[FX via Gcc-patches]

ping on that patch from last week

Maybe the ping is a bit early, as you know I’m not very active anymore, so I do 
not know what are the current policies. In particular, how much leeway do I 
have to commit the patch if there is no comment from another maintainer?

I am fairly confident about the code, because I wrote the original IEEE 
implementation so I know it very well. I believe it would probably be better to 
commit this and have it tested on mainline, that wait for too long. I intend to 
submit further patches and improvements in this area, once those are merged.

Best,
FX



> Le 31 août 2022 à 16:22, FX  a écrit :
> 
> Hum, slightly amended patch, after checking 32-bit results on another linux 
> machine.
> The test for FMA has been made a bit less strict, because otherwise we have 
> surprised on 387 arithmetic due to excess precision.
> 
> Final patch is attached. Regression-tested on x86_64-pc-linux-gnu, both 32- 
> and 64-bit.
> OK to commit?
> 
> FX
> 
> <0001-fortran-Add-IEEE_SIGNBIT-and-IEEE_FMA-functions.patch>

[PING^2][PATCH][gdb/build] Fix build breaker with --enabled-shared

[Tom de Vries via Gcc-patches]

On 7/12/22 15:42, Tom de Vries wrote:

[ dropped gdb-patches, since already applied there. ]

On 6/27/22 15:38, Tom de Vries wrote:

On 6/27/22 15:03, Tom de Vries wrote:

Hi,

When building gdb with --enabled-shared, I run into:
...
ld: build/zlib/libz.a(libz_a-inffast.o): relocation R_X86_64_32S 
against \
   `.rodata' can not be used when making a shared object; recompile 
with -fPIC

ld: build/zlib/libz.a(libz_a-inflate.o): warning: relocation against \
   `inflateResetKeep' in read-only section `.text'
collect2: error: ld returned 1 exit status
make[3]: *** [libbfd.la] Error 1
...

This is a regression since commit a08bdb159bb ("[gdb/build] Fix 
gdbserver

build with -fsanitize=thread").

The problem is that a single case statement in configure is shared to 
handle
special requirements for both the host libiberty and host zlib, which 
has the

effect that only one is handled.

Fix this by handling libiberty and zlib each in its own case statement.

Build on x86_64-linux, with and without --enable-shared.

OK for gcc trunk?





Ping^2.

Thanks,
- Tom


To fix the buildbot breakage, I already pushed to the gdb repo.

Thanks,
- Tom



[gdb/build] Fix build breaker with --enabled-shared

ChangeLog:

2022-06-27  Tom de Vries  

* configure.ac: Set extra_host_libiberty_configure_flags and
extra_host_zlib_configure_flags in separate case statements.
* configure: Regenerate.

---
  configure    | 8 ++--
  configure.ac | 8 ++--
  2 files changed, 12 insertions(+), 4 deletions(-)

diff --git a/configure b/configure
index aac80b88d70..be433ef6d5d 100755
--- a/configure
+++ b/configure
@@ -6962,13 +6962,18 @@ fi
  # Sometimes we have special requirements for the host libiberty.
  extra_host_libiberty_configure_flags=
-extra_host_zlib_configure_flags=
  case " $configdirs " in
    *" lto-plugin "* | *" libcc1 "* | *" gdbserver "*)
  # When these are to be built as shared libraries, the same 
applies to

  # libiberty.
  extra_host_libiberty_configure_flags=--enable-shared
  ;;
+esac
+
+
+# Sometimes we have special requirements for the host zlib.
+extra_host_zlib_configure_flags=
+case " $configdirs " in
    *" bfd "*)
  # When bfd is to be built as a shared library, the same applies to
  # zlib.
@@ -6979,7 +6984,6 @@ case " $configdirs " in
  esac
-
  # Produce a warning message for the subdirs we can't configure.
  # This isn't especially interesting in the Cygnus tree, but in the 
individual
  # FSF releases, it's important to let people know when their 
machine isn't

diff --git a/configure.ac b/configure.ac
index 29f74d10b5a..1651cbf3b02 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2342,13 +2342,18 @@ fi
  # Sometimes we have special requirements for the host libiberty.
  extra_host_libiberty_configure_flags=
-extra_host_zlib_configure_flags=
  case " $configdirs " in
    *" lto-plugin "* | *" libcc1 "* | *" gdbserver "*)
  # When these are to be built as shared libraries, the same 
applies to

  # libiberty.
  extra_host_libiberty_configure_flags=--enable-shared
  ;;
+esac
+AC_SUBST(extra_host_libiberty_configure_flags)
+
+# Sometimes we have special requirements for the host zlib.
+extra_host_zlib_configure_flags=
+case " $configdirs " in
    *" bfd "*)
  # When bfd is to be built as a shared library, the same applies to
  # zlib.
@@ -2357,7 +2362,6 @@ case " $configdirs " in
  fi
  ;;
  esac
-AC_SUBST(extra_host_libiberty_configure_flags)
  AC_SUBST(extra_host_zlib_configure_flags)
  # Produce a warning message for the subdirs we can't configure.

[PATCH] tree-optimization/106754 - fix compute_control_dep_chain defect

[Richard Biener via Gcc-patches]

The following handles the situation of a loop exit along the
control path to the PHI def or from there to the use in a different
way, aoviding premature abort of the walks as noticed in the two
cases where the exit is outermost (gcc.dg/uninit-pred-11.c) or
wrapped in a condition that is on the path (gcc.dg/uninit-pred-12.c).
Instead of handling such exits during recursion we now pick them
up in the parent when walking post-dominators.  That requires an
additional post-dominator walk at the outermost level which is
facilitated by splitting out the walk to a helper function and
the existing wrapper added earlier.

The patch also removes the bogus early exit from
uninit_analysis::init_use_preds, fixing a simplified version
of the PR106155 testcase.

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

PR tree-optimization/106754
* gimple-predicate-analysis.cc (compute_control_dep_chain_pdom):
New function, split out from compute_control_dep_chain.  Handle
loop-exit like conditions here by pushing to the control vector.
(compute_control_dep_chain): Adjust and streamline dumping.
In the wrapper perform a post-dominator walk as well.
(uninit_analysis::init_use_preds): Remove premature early exit.

* gcc.dg/uninit-pred-12.c: New testcase.
* gcc.dg/uninit-pr106155-1.c: Likewise.
---
 gcc/gimple-predicate-analysis.cc | 186 +--
 gcc/testsuite/gcc.dg/uninit-pr106155-1.c |  40 +
 gcc/testsuite/gcc.dg/uninit-pred-12.c|  34 +
 3 files changed, 180 insertions(+), 80 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/uninit-pr106155-1.c
 create mode 100644 gcc/testsuite/gcc.dg/uninit-pred-12.c

diff --git a/gcc/gimple-predicate-analysis.cc b/gcc/gimple-predicate-analysis.cc
index ac34b7007a6..5dade458947 100644
--- a/gcc/gimple-predicate-analysis.cc
+++ b/gcc/gimple-predicate-analysis.cc
@@ -981,6 +981,94 @@ dfs_mark_dominating_region (edge exit, basic_block dom, 
int flag,
   return true;
 }
 
+static bool
+compute_control_dep_chain (basic_block dom_bb, const_basic_block dep_bb,
+  vec cd_chains[], unsigned *num_chains,
+  vec _cd_chain, unsigned *num_calls,
+  unsigned in_region, unsigned depth,
+  bool *complete_p);
+
+/* Helper for compute_control_dep_chain that walks the post-dominator
+   chain from CD_BB up unto TARGET_BB looking for paths to DEP_BB.  */
+
+static bool
+compute_control_dep_chain_pdom (basic_block cd_bb, const_basic_block dep_bb,
+   basic_block target_bb,
+   vec cd_chains[], unsigned *num_chains,
+   vec _cd_chain, unsigned *num_calls,
+   unsigned in_region, unsigned depth,
+   bool *complete_p)
+{
+  bool found_cd_chain = false;
+  while (cd_bb != target_bb)
+{
+  if (cd_bb == dep_bb)
+   {
+ /* Found a direct control dependence.  */
+ if (*num_chains < MAX_NUM_CHAINS)
+   {
+ if (DEBUG_PREDICATE_ANALYZER && dump_file)
+   fprintf (dump_file, "%*s pushing { %s }\n",
+depth, "", format_edge_vec (cur_cd_chain).c_str ());
+ cd_chains[*num_chains] = cur_cd_chain.copy ();
+ (*num_chains)++;
+   }
+ found_cd_chain = true;
+ /* Check path from next edge.  */
+ break;
+   }
+
+  /* If the dominating region has been marked avoid walking outside.  */
+  if (in_region != 0 && !(cd_bb->flags & in_region))
+   break;
+
+  /* Count the number of steps we perform to limit compile-time.
+This should cover both recursion and the post-dominator walk.  */
+  if (*num_calls > (unsigned)param_uninit_control_dep_attempts)
+   {
+ if (dump_file)
+   fprintf (dump_file, "param_uninit_control_dep_attempts "
+"exceeded: %u\n", *num_calls);
+ *complete_p = false;
+ break;
+   }
+  ++*num_calls;
+
+  /* Check if DEP_BB is indirectly control-dependent on DOM_BB.  */
+  if (!single_succ_p (cd_bb)
+ && compute_control_dep_chain (cd_bb, dep_bb, cd_chains,
+   num_chains, cur_cd_chain,
+   num_calls, in_region, depth + 1,
+   complete_p))
+   {
+ found_cd_chain = true;
+ break;
+   }
+
+  /* The post-dominator walk will reach a backedge only
+from a forwarder, otherwise it should choose to exit
+the SCC.  */
+  if (single_succ_p (cd_bb)
+ && single_succ_edge (cd_bb)->flags & EDGE_DFS_BACK)
+   break;
+  basic_block prev_cd_bb = cd_bb;
+  cd_bb = get_immediate_dominator (CDI_POST_DOMINATORS, cd_bb);
+  if (cd_bb == EXIT_BLOCK_PTR_FOR_FN (cfun))
+   

Re: [PATCH] Handle > INF and < INF correctly in range-op-float.cc

[Koning, Paul via Gcc-patches]

> On Sep 6, 2022, at 8:06 AM, Jakub Jelinek via Gcc-patches 
>  wrote:
> 
> On Tue, Sep 06, 2022 at 01:47:43PM +0200, Aldy Hernandez wrote:
>> Question...for !HONOR_NANS or !HONOR_INFINITIES or whatever, say the
>> range for the domain is [-MIN, +MAX] for the min and max representable
>> numbers.  What happens for MAX+1?  Is that undefined?  I wonder what
>> real.cc does for that.
> 
> I'm afraid I have no idea.
> 
> The formats without Inf/NaN are:
> spu_single_format
> vax_{f,d,g}_format
> arm_half_format

Actually, DEC (VAX and PDP-11) float does have NaN; signaling NaN to be precise.

paul

Re: [PATCH 1/2] Using pli(paddi) and rotate to build 64bit constants

[Jiufu Guo via Gcc-patches]

Segher Boessenkool  writes:

> On Mon, Sep 05, 2022 at 02:25:29PM +0800, Jiufu Guo wrote:
>> > On Fri, Sep 02, 2022 at 02:56:21PM +0800, Jiufu Guo wrote:
>> > Or force the testcase to use r0 some other way.  Well, "forcing" cannot
>> > be done, but we can probably encourage it (via a local register asm for
>> > example, or by tying the var to the output of an asm that is hard reg 0,
>> > or perhaps there are other ways as well :-) )
>> Specify register is very helpful here! Both below two cases could help
>> register 0 to be selected for a variable.  Great!  Thanks!
>
>> >> The reason of using "(?n)^\s+[a-z]" is to keep this test case pass no
>> >> matter the splitter running before or after RA.
>> >
>> > Ah.  Some short comment in the testcase please?
>> Thanks.  We can check individual instructions to check better asm
>> pli+pli+rldimi is generated, since the splitter could run in split1 pass.
>
> It's always a tradeoff: if we scan for too specific code the testcase
> will need a lot of maintenance, and that does not scale.  If on the
> other hand we do test less than we really want, well, that is less than
> we really want to test :-)
Yes :)
>
> The changes / additions we agreed to are preapproved btw.  But please
> post the thing you eventually commit to the mailing list :-)
Sure! I updated the patch for testcases and also for code part; I would
submit for review before commit again for new comments. :)

The updated patch is as:
https://gcc.gnu.org/pipermail/gcc-patches/2022-September/601150.html

Thanks again!


BR,
Jeff(Jiufu)

>
>
> Segher

Re: [PATCH] Handle > INF and < INF correctly in range-op-float.cc

[Aldy Hernandez via Gcc-patches]

On Tue, Sep 6, 2022 at 2:17 PM Richard Biener
 wrote:
>
> On Tue, Sep 6, 2022 at 2:06 PM Jakub Jelinek  wrote:
> >
> > On Tue, Sep 06, 2022 at 01:47:43PM +0200, Aldy Hernandez wrote:
> > > Question...for !HONOR_NANS or !HONOR_INFINITIES or whatever, say the
> > > range for the domain is [-MIN, +MAX] for the min and max representable
> > > numbers.  What happens for MAX+1?  Is that undefined?  I wonder what
> > > real.cc does for that.
> >
> > I'm afraid I have no idea.
> >
> > The formats without Inf/NaN are:
> > spu_single_format
> > vax_{f,d,g}_format
> > arm_half_format
> >
> > Never had the "pleasure" to work with any of these.
> > Looking at encode_vax_*, it seems both GCC internal inf and nan are
> > most likely are encoded as maximum or minimum representable numbers
> > (depending on sign), and encode_ieee_half for !fmt->has_inf does too
> > (for !fmt->has_nans it seems to "encode" the nan mantissa bits into
> > highest possible exponent).  encode_ieee_single (for spu) uses
> > maximum or minimum representable numbers for any infinities or nans.
> > What they actually do at runtime is something I can't really check,
> > but one would hope it is saturating...
>
> I'd simply do what we do for -ffinite-math-only - just pretend you don't
> cross the maximum/minmum value and effectively saturate the range.

Yeah, that sounds reasonable.  I take it I can assume that MAX+1 is
undefined for -ffinite-math-only?  So I'm free to saturate, etc?

Ok, crazy hypothetical talk...

if (x > y)

For -ffinite-math-only, on the true side, can I assume:

x: MIN + 1 ULP
y: MAX - 1 ULP

range-op for integers did all sorts of stuff like that, and we ended
up optimizing some interesting cases...as well as driving the middle
end warnings crazy :-P.

Aldy

Re: [PATCH] expand: Convert cst - x into cst xor x.

[Richard Biener via Gcc-patches]

On Tue, Sep 6, 2022 at 11:42 AM Robin Dapp  wrote:
>
> Hi,
>
> posting this separately from PR91213 now.  I wrote an s390 test and most
> likely it could also be done for x86 which will give it broader coverage.
>
> Depending on the backend it might be better to convert
>   cst - x
> into
>   cst xor x
> if cst + 1 is a power of two and 0 <= x <= cst.  This patch compares
> both sequences and emits the less expensive one.
>
> Does this look like a viable approach? Bootstrapped and regtested on
> s390[x], waited with x86 tests until a first round of comments.

cost might also depend on the context in case flag setting
behavior differs for xor vs sub (on x86 sub looks strictly more
powerful here).  The same is probably true when looking for
a combination with another bitwise operation.

Btw, why not perform the optimization in expand_binop?  That
for example already does

  if (binoptab == sub_optab && CONST_INT_P (op1))
{
  op1 = negate_rtx (mode, op1);
  binoptab = add_optab;
}

alternatively a targets expander can do the selection as well.

Richard.

> Regards
>  Robin
>
> gcc/ChangeLog:
>
> PR middle-end/91213
> * expr.cc (expand_expr_real_2): Call new function.
> (maybe_optimize_cst_sub): New function.
> * expr.h (maybe_optimize_cst_sub): Define.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/s390/cst-minus-var.c: New test.
>
> ---
>  gcc/expr.cc   | 79 +++
>  gcc/expr.h|  2 +
>  gcc/testsuite/gcc.target/s390/cst-minus-var.c | 55 +
>  3 files changed, 136 insertions(+)
>  create mode 100644 gcc/testsuite/gcc.target/s390/cst-minus-var.c
>
> diff --git a/gcc/expr.cc b/gcc/expr.cc
> index 80bb1b8a4c5b..80f25720d7b6 100644
> --- a/gcc/expr.cc
> +++ b/gcc/expr.cc
> @@ -9397,6 +9397,21 @@ expand_expr_real_2 (sepops ops, rtx target,
> machine_mode tmode,
>   return simplify_gen_binary (MINUS, mode, op0, op1);
> }
>
> +  /* Convert const - A to const xor A if integer_pow2p (const + 1)
> +and 0 <= A <= const.  */
> +  if (code == MINUS_EXPR
> + && SCALAR_INT_MODE_P (mode)
> + && TREE_CODE (treeop0) == INTEGER_CST
> + && TREE_CODE (TREE_TYPE (treeop1)) == INTEGER_TYPE
> + && wi::exact_log2 (wi::to_widest (treeop0) + 1) != -1)
> +   {
> + rtx res = maybe_optimize_cst_sub (code, treeop0, treeop1,
> +   mode, unsignedp, type,
> +   target, subtarget);
> + if (res)
> +   return res;
> +   }
> +
>/* No sense saving up arithmetic to be done
>  if it's all in the wrong mode to form part of an address.
>  And force_operand won't know whether to sign-extend or
> @@ -12692,6 +12707,70 @@ maybe_optimize_mod_cmp (enum tree_code code,
> tree *arg0, tree *arg1)
>return code == EQ_EXPR ? LE_EXPR : GT_EXPR;
>  }
>
> +/* Convert const - A to const xor A if integer_pow2p (const + 1)
> +   and 0 <= A <= const.  */
> +
> +rtx
> +maybe_optimize_cst_sub (enum tree_code code, tree treeop0, tree treeop1,
> +   machine_mode mode, int unsignedp, tree type,
> +   rtx target, rtx subtarget)
> +{
> +  gcc_checking_assert (code == MINUS_EXPR);
> +  gcc_checking_assert (SCALAR_INT_MODE_P (mode));
> +  gcc_checking_assert (TREE_CODE (treeop0) == INTEGER_CST);
> +  gcc_checking_assert (TREE_CODE (TREE_TYPE (treeop1)) == INTEGER_TYPE);
> +  gcc_checking_assert (wi::exact_log2 (wi::to_widest (treeop0) + 1) != -1);
> +
> +  if (!optimize)
> +return NULL_RTX;
> +
> +  optab this_optab;
> +  rtx op0, op1;
> +
> +  if (wi::leu_p (tree_nonzero_bits (treeop1), tree_nonzero_bits (treeop0)))
> +{
> +  expand_operands (treeop0, treeop1, subtarget, , ,
> +  EXPAND_NORMAL);
> +  bool speed_p = optimize_insn_for_speed_p ();
> +  do_pending_stack_adjust ();
> +  start_sequence ();
> +  this_optab = optab_for_tree_code (MINUS_EXPR, type,
> +   optab_default);
> +  rtx subi = expand_binop (mode, this_optab, op0, op1, target,
> +  unsignedp, OPTAB_LIB_WIDEN);
> +
> +  rtx_insn *sub_insns = get_insns ();
> +  end_sequence ();
> +  start_sequence ();
> +  this_optab = optab_for_tree_code (BIT_XOR_EXPR, type,
> +   optab_default);
> +  rtx xori = expand_binop (mode, this_optab, op0, op1, target,
> +  unsignedp, OPTAB_LIB_WIDEN);
> +  rtx_insn *xor_insns = get_insns ();
> +  end_sequence ();
> +  unsigned sub_cost = seq_cost (sub_insns, speed_p);
> +  unsigned xor_cost = seq_cost (xor_insns, speed_p);
> +  /* If costs are the same then use as tie breaker the other other
> +factor.  */
> +  if (sub_cost == xor_cost)
> +   {
> + sub_cost = 

[PATCH] Using pli(paddi) and rotate to build 64bit constants

[Jiufu Guo via Gcc-patches]

Hi,

Test cases are updated/added, and code is refined as the comments in the
review for previous version:
https://gcc.gnu.org/pipermail/gcc-patches/2022-September/600768.html

As mentioned in PR106550, since pli could support 34bits immediate, we could
use less instructions(3insn would be ok) to build 64bits constant with pli.

For example, for constant 0x020805006106003, we could generate it with:
asm code1:
pli 9,101736451 (0x6106003)
sldi 9,9,32
paddi 9,9, 213 (0x0208050)

or asm code2:
pli 10, 213
pli 9, 101736451
rldimi 9, 10, 32, 0

The asm code2 would be better.
This patch generates the asm code2 in split1 pass, this patch also supports
to generate asm code1 when splitter is only after RA.

This patch pass boostrap and regtest on ppc64. P10 testing is running.
Thanks for any comments!

BR,
Jeff(Jiufu)

PR target/106550

gcc/ChangeLog:

* config/rs6000/rs6000.cc (rs6000_emit_set_long_const): Use pli.

gcc/testsuite/ChangeLog:

* gcc.target/powerpc/pr106550.c: New test.
* gcc.target/powerpc/pr106550_1.c: New test.

---
 gcc/config/rs6000/rs6000.cc   | 35 +++
 gcc/testsuite/gcc.target/powerpc/pr106550.c   | 14 
 gcc/testsuite/gcc.target/powerpc/pr106550_1.c | 22 
 3 files changed, 71 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/powerpc/pr106550.c
 create mode 100644 gcc/testsuite/gcc.target/powerpc/pr106550_1.c

diff --git a/gcc/config/rs6000/rs6000.cc b/gcc/config/rs6000/rs6000.cc
index 2f3146e56f8..c05b7869141 100644
--- a/gcc/config/rs6000/rs6000.cc
+++ b/gcc/config/rs6000/rs6000.cc
@@ -10181,6 +10181,41 @@ rs6000_emit_set_long_const (rtx dest, HOST_WIDE_INT c)
gen_rtx_IOR (DImode, copy_rtx (temp),
 GEN_INT (ud1)));
 }
+  else if (TARGET_PREFIXED)
+{
+  if (can_create_pseudo_p ())
+   {
+ /* pli A,H + pli B,L + rldimi A,B,32,0.  */
+ temp = gen_reg_rtx (DImode);
+ rtx temp1 = gen_reg_rtx (DImode);
+ emit_move_insn (temp, GEN_INT ((ud4 << 16) | ud3));
+ emit_move_insn (temp1, GEN_INT ((ud2 << 16) | ud1));
+
+ emit_insn (gen_rotldi3_insert_3 (dest, temp, GEN_INT (32), temp1,
+  GEN_INT (0x)));
+   }
+  else
+   {
+ /* pli A,H + sldi A,32 + paddi A,A,L.  */
+ emit_move_insn (dest, GEN_INT ((ud4 << 16) | ud3));
+
+ emit_move_insn (dest, gen_rtx_ASHIFT (DImode, dest, GEN_INT (32)));
+
+ bool can_use_paddi = REGNO (dest) != FIRST_GPR_REGNO;
+
+ /* Use paddi for the low 32 bits.  */
+ if (ud2 != 0 && ud1 != 0 && can_use_paddi)
+   emit_move_insn (dest, gen_rtx_PLUS (DImode, dest,
+   GEN_INT ((ud2 << 16) | ud1)));
+
+ /* Use oris, ori for low 32 bits.  */
+ if (ud2 != 0 && (ud1 == 0 || !can_use_paddi))
+   emit_move_insn (ud1 != 0 ? dest : dest,
+   gen_rtx_IOR (DImode, dest, GEN_INT (ud2 << 16)));
+ if (ud1 != 0 && (ud2 == 0 || !can_use_paddi))
+   emit_move_insn (dest, gen_rtx_IOR (DImode, dest, GEN_INT (ud1)));
+   }
+}
   else
 {
   temp = !can_create_pseudo_p () ? dest : gen_reg_rtx (DImode);
diff --git a/gcc/testsuite/gcc.target/powerpc/pr106550.c 
b/gcc/testsuite/gcc.target/powerpc/pr106550.c
new file mode 100644
index 000..d023fac4676
--- /dev/null
+++ b/gcc/testsuite/gcc.target/powerpc/pr106550.c
@@ -0,0 +1,14 @@
+/* PR target/106550 */
+/* { dg-options "-O2 -mdejagnu-cpu=power10" } */
+/* { dg-require-effective-target power10_ok } */
+
+void
+foo (unsigned long long *a)
+{
+  *a++ = 0x020805006106003; /* pli+pli+rldimi */
+  *a++ = 0x2351847027482577;/* pli+pli+rldimi */  
+}
+
+/* { dg-final { scan-assembler-times {\mpli\M} 4 } } */
+/* { dg-final { scan-assembler-times {\mrldimi\M} 2 } } */
+
diff --git a/gcc/testsuite/gcc.target/powerpc/pr106550_1.c 
b/gcc/testsuite/gcc.target/powerpc/pr106550_1.c
new file mode 100644
index 000..48f76ca3da9
--- /dev/null
+++ b/gcc/testsuite/gcc.target/powerpc/pr106550_1.c
@@ -0,0 +1,22 @@
+/* PR target/106550 */
+/* { dg-require-effective-target power10_ok } */
+/* { dg-options "-O2 -mdejagnu-cpu=power10 -fdisable-rtl-split1" } */
+/* force the constant splitter run after RA: -fdisable-rtl-split1.  */
+
+void
+foo (unsigned long long *a)
+{
+  /* Test oris/ori is used where paddi does not work with 'r0'. */
+  register long long d asm("r0") = 0x1245abcef9240dec; /* pli+sldi+oris+ori */
+  long long n;
+  asm("cntlzd %0, %1" : "=r"(n) : "r"(d));
+  *a++ = n;
+
+  *a++ = 0x235a8470a748ULL; /* pli+sldi+oris*/
+  *a++ = 0x23a18470b677ULL; /* pli+sldi+ori*/
+}
+
+/* { dg-final { scan-assembler-times {\mpli\M} 3 } } */
+/* { dg-final { scan-assembler-times {\msldi\M} 3 } } */
+/* { dg-final { scan-assembler-times {\moris\M} 2 } } */
+/* { dg-final { scan-assembler-times {\mori\M} 

Re: [PATCH] Handle > INF and < INF correctly in range-op-float.cc

[Richard Biener via Gcc-patches]

On Tue, Sep 6, 2022 at 2:06 PM Jakub Jelinek  wrote:
>
> On Tue, Sep 06, 2022 at 01:47:43PM +0200, Aldy Hernandez wrote:
> > Question...for !HONOR_NANS or !HONOR_INFINITIES or whatever, say the
> > range for the domain is [-MIN, +MAX] for the min and max representable
> > numbers.  What happens for MAX+1?  Is that undefined?  I wonder what
> > real.cc does for that.
>
> I'm afraid I have no idea.
>
> The formats without Inf/NaN are:
> spu_single_format
> vax_{f,d,g}_format
> arm_half_format
>
> Never had the "pleasure" to work with any of these.
> Looking at encode_vax_*, it seems both GCC internal inf and nan are
> most likely are encoded as maximum or minimum representable numbers
> (depending on sign), and encode_ieee_half for !fmt->has_inf does too
> (for !fmt->has_nans it seems to "encode" the nan mantissa bits into
> highest possible exponent).  encode_ieee_single (for spu) uses
> maximum or minimum representable numbers for any infinities or nans.
> What they actually do at runtime is something I can't really check,
> but one would hope it is saturating...

I'd simply do what we do for -ffinite-math-only - just pretend you don't
cross the maximum/minmum value and effectively saturate the range.

Richard.

> Jakub
>

[COMMITTED] xtensa: gcc: add static PIE support

[Max Filippov via Gcc-patches]

gcc/
* config/xtensa/linux.h (LINK_SPEC): Add static-pie.
---
 gcc/config/xtensa/linux.h | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/gcc/config/xtensa/linux.h b/gcc/config/xtensa/linux.h
index 540e4bf538f8..bc7bee71517d 100644
--- a/gcc/config/xtensa/linux.h
+++ b/gcc/config/xtensa/linux.h
@@ -54,9 +54,10 @@ along with GCC; see the file COPYING3.  If not see
 #define LINK_SPEC \
  "%{shared:-shared} \
   %{!shared: \
-%{!static: \
+%{!static:%{!static-pie: \
   %{rdynamic:-export-dynamic} \
-  -dynamic-linker " GNU_USER_DYNAMIC_LINKER "} \
+  -dynamic-linker " GNU_USER_DYNAMIC_LINKER "}} \
+%{static-pie:-static -pie --no-dynamic-linker -z text} \
 %{static:-static}} \
   %{mabi=windowed:--abi-windowed} \
   %{mabi=call0:--abi-call0}"
-- 
2.30.2

Re: [PATCH] Handle > INF and < INF correctly in range-op-float.cc

[Jakub Jelinek via Gcc-patches]

On Tue, Sep 06, 2022 at 01:47:43PM +0200, Aldy Hernandez wrote:
> Question...for !HONOR_NANS or !HONOR_INFINITIES or whatever, say the
> range for the domain is [-MIN, +MAX] for the min and max representable
> numbers.  What happens for MAX+1?  Is that undefined?  I wonder what
> real.cc does for that.

I'm afraid I have no idea.

The formats without Inf/NaN are:
spu_single_format
vax_{f,d,g}_format
arm_half_format

Never had the "pleasure" to work with any of these.
Looking at encode_vax_*, it seems both GCC internal inf and nan are
most likely are encoded as maximum or minimum representable numbers
(depending on sign), and encode_ieee_half for !fmt->has_inf does too
(for !fmt->has_nans it seems to "encode" the nan mantissa bits into
highest possible exponent).  encode_ieee_single (for spu) uses
maximum or minimum representable numbers for any infinities or nans.
What they actually do at runtime is something I can't really check,
but one would hope it is saturating...

Jakub

Re: [PATCH] d: Fix #error You must define PREFERRED_DEBUGGING_TYPE if DWARF is not supported (PR105659)

[Rainer Orth]

Hi Iain,

> Is there a difference in output from `./gcc/d21 -quiet -v` ?
>
> Pay attention to any predefs that have suddenly appeared or disappeared.

there is indeed ;-)  The previous d21 emits

binary./266566/gcc/d21
version   v2.100.1

predefs   GNU D_Version2 LittleEndian GNU_DWARF2_Exceptions GNU_StackGrowsDown 
GNU_InlineAsm assert D_PreConditions D_PostConditions D_Invariants D_ModuleInfo 
D_Exceptions D_TypeInfo all X86 D_HardFloat Posix Solaris CppRuntime_Gcc

while the patched one gives

core.exception.ArrayIndexError@/var/gcc/reghunt/master/gcc/d/dmd/root/stringtable.d(291):
 index [3530971477] is out of bounds for array of length 0
gcc.deh(505): uncaught exception
: internal compiler error: Abort
0x96d5b6c crash_signal
/var/gcc/reghunt/master/gcc/toplev.cc:314

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: [PATCH] OpenMP, libgomp: Environment variable syntax extension.

[Jakub Jelinek via Gcc-patches]

On Wed, Aug 31, 2022 at 12:56:25PM +0200, Marcel Vollweiler wrote:
> libgomp/ChangeLog:
> 
>   * config/gcn/icv-device.c (omp_get_default_device): Return device-
>   specific ICV.
>   (omp_get_max_teams): Added for GCN devices.
>   (omp_set_num_teams): Likewise.
>   (ialias): Likewise.
>   * config/nvptx/icv-device.c (omp_get_default_device): Return device-
>   specific ICV.
>   (omp_get_max_teams): Added for NVPTX devices.
>   (omp_set_num_teams): Likewise.
>   (ialias): Likewise.
>   * env.c (struct gomp_icv_list): New struct to store entries of initial
>   ICV values.
>   (struct gomp_offload_icv_list): New struct to store entries of device-
>   specific ICV values that are copied to the device and back.
>   (struct gomp_default_icv_values): New struct to store default values of
>   ICVs according to the OpenMP standard.
>   (parse_schedule): Generalized for different variants of OMP_SCHEDULE.
>   (print_env_var_error): Function that prints an error for invalid values
>   for ICVs.
>   (parse_unsigned_long_1): Removed getenv. Generalized.

2 spaces after . instead of just one

>   (parse_unsigned_long): Likewise.
>   (parse_int_1): Likewise.
>   (parse_int): Likewise.
>   (parse_int_secure): Likewise.
>   (parse_unsigned_long_list): Likewise.
>   (parse_target_offload): Likewise.
>   (parse_bind_var): Likewise.
>   (parse_stacksize): Likewise.
>   (parse_boolean): Likewise.
>   (parse_wait_policy): Likewise.
>   (parse_allocator): Likewise.
>   (omp_display_env): Extended to output different variants of environment
>   variables.
>   (print_schedule): New helper function for omp_display_env which prints
>   the values of run_sched_var.
>   (print_proc_bind): New helper function for omp_display_env which prints
>   the values of proc_bind_var.
>   (enum gomp_parse_type): Collection of types used for parsing environment
>   variables.
>   (ENTRY): Preprocess string lengths of environment variables.
>   (OMP_VAR_CNT): Preprocess table size.
>   (OMP_HOST_VAR_CNT): Likewise.
>   (INT_MAX_STR_LEN): Constant for the maximal number of digits of a device
>   number.
>   (gomp_get_icv_flag): Returns if a flag for a particular ICV is set.
>   (gomp_set_icv_flag): Sets a flag for a particular ICV.
>   (print_device_specific_icvs): New helper function for omp_display_env to
>   print device specific ICV values.
>   (get_device_num): New helper function for parse_device_specific.
>   Extracts the device number from an environment variable name.
>   (get_icv_member_addr): Gets the memory address for a particular member
>   of an ICV struct.
>   (gomp_get_initial_icv_item): Get a list item of gomp_initial_icv_list.
>   (initialize_icvs): New function to initialize a gomp_initial_icvs
>   struct.
>   (add_initial_icv_to_list): Adds an ICV struct to gomp_initial_icv_list.
>   (startswith): Checks if a string starts with a given prefix.
>   (initialize_env): Extended to parse the new syntax of environment
>   variables.
>   * icv-device.c (omp_get_max_teams): Added.
>   (ialias): Likewise.
>   (omp_set_num_teams): Likewise.
>   * icv.c (omp_set_num_teams): Moved to icv-device.c.
>   (omp_get_max_teams): Likewise.
>   (ialias): Likewise.
>   * libgomp-plugin.h (GOMP_DEVICE_NUM_VAR): Removed.
>   (GOMP_ADDITIONAL_ICVS): New target-side struct that
>   holds the designated ICVs of the target device.
>   * libgomp.h (enum gomp_icvs): Collection of ICVs.
>   (enum gomp_device_num): Definition of device numbers for _ALL, _DEV, and
>   no suffix.
>   (enum gomp_env_suffix): Collection of possible suffixes of environment
>   variables.
>   (struct gomp_initial_icvs): Contains all ICVs for which we need to store
>   initial values.
>   (struct gomp_default_icv):New struct to hold ICVs for which we need
>   to store initial values.
>   (struct gomp_icv_list): Definition of a linked list that is used for
>   storing ICVs for the devices and also for _DEV, _ALL, and without
>   suffix.
>   (struct gomp_offload_icvs): New struct to hold ICVs that are copied to
>   a device.
>   (struct gomp_offload_icv_list): Definition of a linked list that holds
>   device-specific ICVs that are copied to devices.
>   (gomp_get_initial_icv_item): Get a list item of gomp_initial_icv_list.
>   (gomp_get_icv_flag): Returns if a flag for a particular ICV is set.
>   * plugin/plugin-gcn.c (GOMP_OFFLOAD_load_image): Extended to read
>   further ICVs from the offload image.
>   * plugin/plugin-nvptx.c (GOMP_OFFLOAD_load_image): Likewise.
>   * target.c (gomp_get_offload_icv_item): Get a list item of
>   gomp_offload_icv_list.
>   (get_gomp_offload_icvs): New. Returns the ICV values
>   

Re: [PATCH] Handle > INF and < INF correctly in range-op-float.cc

[Aldy Hernandez via Gcc-patches]

On Tue, Sep 6, 2022 at 9:59 AM Jakub Jelinek  wrote:
>
> On Tue, Sep 06, 2022 at 09:49:55AM +0200, Aldy Hernandez wrote:
> > On Tue, Sep 6, 2022 at 9:44 AM Jakub Jelinek  wrote:
> > >
> > > On Tue, Sep 06, 2022 at 09:40:59AM +0200, Aldy Hernandez wrote:
> > > > if (x <= Inf)
> > >
> > > This will be [-Inf, Inf] !NAN on the true side and
> > > NAN (either sign) on the false side indeed.
> > >
> > > > if (x < -Inf)
> > >
> > > will be NAN (either sign) on the true side and
> > > [-Inf, Inf] !NAN on the false side.
> >
> > Sweet, that's exactly what I thought, thus the patch.
> >
> > Furthermore, for !HONOR_NANS I would expect the NAN sides above to be
> > UNDEFINED/unreachable.  That is, the false side of x <= Inf when
> > !HONOR_NANS is unreachable.
>
> In practice, there is no real format that has NaNs and doesn't have Infs
> or vice versa and similarly we have just one switch to cover both Infinities
> and NaNs, so either both are supported, or neither of them, or both
> are supported but neither of them should appear in a valid program
> (-ffinite-math-only on most floating point formats).
> So the answer in that case is a little bit fuzzy because one shouldn't
> compare against infinity in that case (or for !MODE_HAS_INFINITIES even
> can't).  But sure, if NaNs aren't possible or can't appear and you compare
> x <= Largest_possible_float, then it is always true and so UNDEFINED on the
> false edge.

OK, let's leave it as undefined to be consistent.

Come to think of it, perhaps we could represent the endpoints
(varying, [x, +INF], etc) as the min/max representable values for the
type (for !HONOR_NANS).  I don't think it would make a big difference,
but we might get better results for some corner cases.

Question...for !HONOR_NANS or !HONOR_INFINITIES or whatever, say the
range for the domain is [-MIN, +MAX] for the min and max representable
numbers.  What happens for MAX+1?  Is that undefined?  I wonder what
real.cc does for that.

Attached is the final version of the patch I'm pushing.  Tested (+mpfr
tests) on x86-64 Linux.

Aldy
From fd52ffb9997becafa31c5109b50fe274da12aed8 Mon Sep 17 00:00:00 2001
From: Aldy Hernandez 
Date: Tue, 6 Sep 2022 08:20:54 +0200
Subject: [PATCH] Handle > INF and < INF correctly in range-op-float.cc

The gfortran.dg/minlocval*.f90 tests are generating conditionals past
the infinities.  For example:

	if (x <= +Inf)
	  foo (x);
	else
	  bar (x);

It seems to me that the only possible value for x on the false side is
either NAN or undefined (for !HONOR_NANS).

gcc/ChangeLog:

	* range-op-float.cc (build_le): Handle NANs and going past infinity.
	(build_lt): Same.
	(build_ge): Same.
	(build_gt): Same.
	(foperator_lt::op1_range): Avoid adjustments to range if build_*
	returned false.
	(foperator_lt::op2_range): Same.
	(foperator_le::op1_range): Same.
	(foperator_le::op2_range): Same.
	(foperator_gt::op1_range): Same.
	(foperator_gt::op2_range): Same.

gcc/testsuite/ChangeLog:

	* gcc.dg/tree-ssa/vrp-float-inf-1.c: New test.
---
 gcc/range-op-float.cc | 99 ++-
 .../gcc.dg/tree-ssa/vrp-float-inf-1.c | 15 +++
 2 files changed, 90 insertions(+), 24 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/vrp-float-inf-1.c

diff --git a/gcc/range-op-float.cc b/gcc/range-op-float.cc
index 050f07a9867..5fbbaa1fb36 100644
--- a/gcc/range-op-float.cc
+++ b/gcc/range-op-float.cc
@@ -224,36 +224,79 @@ frange_drop_ninf (frange , tree type)
 
 // (X <= VAL) produces the range of [-INF, VAL].
 
-static void
+static bool
 build_le (frange , tree type, const REAL_VALUE_TYPE )
 {
+  if (real_isnan ())
+{
+  r.set_undefined ();
+  return false;
+}
   r.set (type, dconstninf, val);
+  return true;
 }
 
 // (X < VAL) produces the range of [-INF, VAL).
 
-static void
+static bool
 build_lt (frange , tree type, const REAL_VALUE_TYPE )
 {
+  if (real_isnan ())
+{
+  r.set_undefined ();
+  return false;
+}
+  // < -INF is outside the range.
+  if (real_isinf (, 1))
+{
+  if (HONOR_NANS (type))
+	frange_set_nan (r, type);
+  else
+	r.set_undefined ();
+  return false;
+}
   // Hijack LE because we only support closed intervals.
   build_le (r, type, val);
+  return true;
 }
 
 // (X >= VAL) produces the range of [VAL, +INF].
 
-static void
+static bool
 build_ge (frange , tree type, const REAL_VALUE_TYPE )
 {
+  if (real_isnan ())
+{
+  r.set_undefined ();
+  return false;
+}
   r.set (type, val, dconstinf);
+  return true;
 }
 
 // (X > VAL) produces the range of (VAL, +INF].
 
-static void
+static bool
 build_gt (frange , tree type, const REAL_VALUE_TYPE )
 {
+  if (real_isnan ())
+{
+  r.set_undefined ();
+  return false;
+}
+  // > +INF is outside the range.
+  if (real_isinf (, 0))
+{
+  if (HONOR_NANS (type))
+	frange_set_nan (r, type);
+  else
+	r.set_undefined ();
+  return false;
+}
+
   // Hijack GE because we only support closed 

Re: [PATCH] msp430: Mark unused attribute

[Nick Clifton via Gcc-patches]

Hi Jan-Benedict,


gcc/ChangeLog:
* config/msp430/msp430.cc (msp430_single_op_cost): Mark unused argument.



Okay for HEAD?


Patch approved - please apply.   (I think that this patch would also count as
an "obvious" fix, but thanks for asking anyway).

Cheers
  Nick

[PATCH] Fix use predicate computation for uninit analysis

[Richard Biener via Gcc-patches]

In uninit analysis we try to prove that a use is always properly guarded
so it is never reached when the used value is not initialized.  This
fails to be conservative when during the computation of the use
predicate components of the || .. || .. chain are dropped so we have
to detect this case and fall back to the conservative computation.

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

* gimple-predicate-analysis.cc (compute_control_dep_chain):
Add output flag to indicate whether we possibly have dropped
any chains.  Return whether the info is complete from the
wrapping overload.
(uninit_analysis::init_use_preds): Adjust accordingly, with
a workaround for PR106754.
(uninit_analysis::init_from_phi_def): Properly guard the
case where we complete an empty chain.
---
 gcc/gimple-predicate-analysis.cc | 54 +++-
 1 file changed, 39 insertions(+), 15 deletions(-)

diff --git a/gcc/gimple-predicate-analysis.cc b/gcc/gimple-predicate-analysis.cc
index ef2906ebc51..ac34b7007a6 100644
--- a/gcc/gimple-predicate-analysis.cc
+++ b/gcc/gimple-predicate-analysis.cc
@@ -990,13 +990,16 @@ dfs_mark_dominating_region (edge exit, basic_block dom, 
int flag,
*NUM_CALLS is the number of recursive calls to control unbounded
recursion.
Return true if the information is successfully computed, false if
-   there is no control dependence or not computed.  */
+   there is no control dependence or not computed.
+   *COMPLETE_P is set to false if we stopped walking due to limits.
+   In this case there might be missing chains.  */
 
 static bool
 compute_control_dep_chain (basic_block dom_bb, const_basic_block dep_bb,
   vec cd_chains[], unsigned *num_chains,
   vec _cd_chain, unsigned *num_calls,
-  unsigned in_region = 0, unsigned depth = 0)
+  unsigned in_region, unsigned depth,
+  bool *complete_p)
 {
   /* In our recursive calls this doesn't happen.  */
   if (single_succ_p (dom_bb))
@@ -1009,6 +1012,7 @@ compute_control_dep_chain (basic_block dom_bb, 
const_basic_block dep_bb,
   if (dump_file)
fprintf (dump_file, "MAX_CHAIN_LEN exceeded: %u\n", cur_chain_len);
 
+  *complete_p = false;
   return false;
 }
 
@@ -1077,6 +1081,7 @@ compute_control_dep_chain (basic_block dom_bb, 
const_basic_block dep_bb,
  if (dump_file)
fprintf (dump_file, "param_uninit_control_dep_attempts "
 "exceeded: %u\n", *num_calls);
+ *complete_p = false;
  break;
}
  ++*num_calls;
@@ -1085,7 +1090,8 @@ compute_control_dep_chain (basic_block dom_bb, 
const_basic_block dep_bb,
  if (!single_succ_p (cd_bb)
  && compute_control_dep_chain (cd_bb, dep_bb, cd_chains,
num_chains, cur_cd_chain,
-   num_calls, in_region, depth + 1))
+   num_calls, in_region, depth + 1,
+   complete_p))
{
  found_cd_chain = true;
  break;
@@ -1109,6 +1115,9 @@ compute_control_dep_chain (basic_block dom_bb, 
const_basic_block dep_bb,
   return found_cd_chain;
 }
 
+/* Wrapper around the compute_control_dep_chain worker above.  Returns
+   true when the collected set of chains in CD_CHAINS is complete.  */
+
 static bool
 compute_control_dep_chain (basic_block dom_bb, const_basic_block dep_bb,
   vec cd_chains[], unsigned *num_chains,
@@ -1117,8 +1126,11 @@ compute_control_dep_chain (basic_block dom_bb, 
const_basic_block dep_bb,
   auto_vec cur_cd_chain;
   unsigned num_calls = 0;
   unsigned depth = 0;
-  return compute_control_dep_chain (dom_bb, dep_bb, cd_chains, num_chains,
-   cur_cd_chain, _calls, in_region, depth);
+  bool complete_p = true;
+  compute_control_dep_chain (dom_bb, dep_bb, cd_chains, num_chains,
+cur_cd_chain, _calls, in_region, depth,
+_p);
+  return complete_p;
 }
 
 /* Implemented simplifications:
@@ -1888,6 +1900,10 @@ bool
 uninit_analysis::init_use_preds (predicate _preds, basic_block def_bb,
 basic_block use_bb)
 {
+  if (DEBUG_PREDICATE_ANALYZER && dump_file)
+fprintf (dump_file, "init_use_preds (def_bb = %u, use_bb = %u)\n",
+def_bb->index, use_bb->index);
+
   gcc_assert (use_preds.is_empty ()
  && dominated_by_p (CDI_DOMINATORS, use_bb, def_bb));
 
@@ -1919,17 +1935,20 @@ uninit_analysis::init_use_preds (predicate _preds, 
basic_block def_bb,
   unsigned num_chains = 0;
   auto_vec dep_chains[MAX_NUM_CHAINS];
 
-  if (!compute_control_dep_chain (cd_root, use_bb, dep_chains, _chains))
+  if 

Re: [PATCH] riscv: implement TARGET_MODE_REP_EXTENDED

[Alexander Monakov via Gcc-patches]

On Mon, 5 Sep 2022, Philipp Tomsich wrote:

> +riscv_mode_rep_extended (scalar_int_mode mode, scalar_int_mode mode_rep)
> +{
> +  /* On 64-bit targets, SImode register values are sign-extended to DImode.  
> */
> +  if (TARGET_64BIT && mode == SImode && mode_rep == DImode)
> +return SIGN_EXTEND;

I think this leads to a counter-intuitive requirement that a hand-written
inline asm must sign-extend its output operands that are bound to either
signed or unsigned 32-bit lvalues. Will compiler users be aware of that?

Moreover, without adjusting TARGET_TRULY_NOOP_TRUNCATION this should cause
miscompilation when a 64-bit variable is truncated to 32 bits: the pre-existing
hook says that nothing needs to be done to truncate, but the new hook says
that the result of the truncation is properly sign-extended.

The documentation for TARGET_MODE_REP_EXTENDED warns about that:

In order to enforce the representation of mode, TARGET_TRULY_NOOP_TRUNCATION
should return false when truncating to mode. 

Alexander

Re: [PATCH 2/2] libstdc++: Add pretty printer for std::stringstream

[Jonathan Wakely via Gcc-patches]

Thanks for the patch. Comments below.


On Sun, 4 Sept 2022 at 19:48, Philipp Fent via Libstdc++
 wrote:
>
> Signed-off-by: Philipp Fent 
> ---
>  libstdc++-v3/python/libstdcxx/v6/printers.py  | 37 +++
>  .../libstdc++-prettyprinters/debug.cc |  5 +++
>  .../libstdc++-prettyprinters/simple.cc|  5 +++
>  .../libstdc++-prettyprinters/simple11.cc  |  5 +++
>  4 files changed, 52 insertions(+)
>
> diff --git a/libstdc++-v3/python/libstdcxx/v6/printers.py 
> b/libstdc++-v3/python/libstdcxx/v6/printers.py
> index d70c8d5d616..5083f693387 100644
> --- a/libstdc++-v3/python/libstdcxx/v6/printers.py
> +++ b/libstdc++-v3/python/libstdcxx/v6/printers.py
> @@ -969,6 +969,39 @@ class StdStringPrinter:
>  def display_hint (self):
>  return 'string'
>
> +class StdStringBufPrinter:
> +"Print a std::basic_stringbuf"
> +
> +def __init__(self, _, val):
> +self.val = val
> +
> +def to_string(self):
> +pbase = self.val['_M_out_beg']
> +pptr = self.val['_M_out_cur']
> +egptr = self.val['_M_in_end']

It would be nice to encapsulate this into a generic helper for all
streambufs, as this part isn't specific to basic_stringbuf. We could
then reuse it for printing spanbufs and other types in future. It
could be a function that takes a streambuf and returns a tuple of
(pbase, pptr, egptr).

> +# Logic from basic_stringbuf::_M_high_mark()
> +if pptr:
> +if not egptr or pptr > egptr:
> +return pbase.string(length = pptr - pbase)
> +else:
> +return pbase.string(length = pptr - egptr)

Shouldn't this be egptr - pbase?

This suggests the tests are inadequate. I think this bug would have
been found by a test something like:

std::stringstream ssin("input", std::ios::in);
// { dg-final { note-test ssin "\"input\"" } }

The (egptr - pbase) case is also needed for printing an istringstream.

> +return self.val['_M_string']
> +
> +def display_hint(self):
> +return 'string'
> +
> +class StdStringStreamPrinter:
> +"Print a std::basic_stringstream"
> +
> +def __init__(self, _, val):
> +self.val = val
> +
> +def to_string(self):
> +return self.val['_M_stringbuf']

This assumes that the stream is still using its stringbuf, which is
probably true 99% of the time, but isn't guaranteed. In the following
situation, the printer would give potentially misleading output:

std::stringstream ss("xxx");
ss.rdbuf(std::cin.rdbuf());

I wonder if we want to have a check that self.val['_M_streambuf'] ==
self.val['_M_stringbuf'].address

Alternatively, don't provide a printer for the stringstream at all,
just for the stringbuf, and then when GDB uses its default display for
the stringstream it will show that member.


> +
> +def display_hint(self):
> +return 'string'
> +
>  class Tr1HashtableIterator(Iterator):
>  def __init__ (self, hashtable):
>  self.buckets = hashtable['_M_buckets']
> @@ -2232,6 +2265,10 @@ def build_libstdcxx_dictionary ():
>  libstdcxx_printer.add_version('std::', 'initializer_list',
>StdInitializerListPrinter)
>  libstdcxx_printer.add_version('std::', 'atomic', StdAtomicPrinter)
> +libstdcxx_printer.add_version('std::', 'basic_stringbuf', 
> StdStringBufPrinter)
> +libstdcxx_printer.add_version('std::__cxx11::', 'basic_stringbuf', 
> StdStringBufPrinter)
> +libstdcxx_printer.add_version('std::', 'basic_stringstream', 
> StdStringStreamPrinter)
> +libstdcxx_printer.add_version('std::__cxx11::', 'basic_stringstream', 
> StdStringStreamPrinter)

Wouldn't we want it for ostringstream and istringstream too?

Re: [PATCH 1/2] libstdc++: Fix pretty printer tests of tuple indexes

[Jonathan Wakely via Gcc-patches]

On Tue, 6 Sept 2022 at 02:07, Will Hawkins  wrote:
>
> Confirming that patch 1 of 2 *does* fix the failing tests here (x86-64).
>
> Will
>
> PS: Please tell me if emails like this are helpful or not. Just trying to 
> help!

Thanks. I wasn't even seeing the failing tests, due to errors from GDB:

Dwarf Error: wrong version in compilation unit header (is 5, should be
2, 3, or 4) [in module
/home/jwakely/build/powerpc64le-unknown-linux-gnu/lib
stdc++-v3/testsuite/cxx11.exe

This meant they were UNSUPPORTED on my test machine.

I've pushed Philipp's [PATCH 1/2] now. Thank you both.


>
> On Sun, Sep 4, 2022 at 2:48 PM Philipp Fent via Libstdc++
>  wrote:
> >
> > Signed-off-by: Philipp Fent 
> > ---
> >  libstdc++-v3/testsuite/libstdc++-prettyprinters/48362.cc | 2 +-
> >  libstdc++-v3/testsuite/libstdc++-prettyprinters/cxx11.cc | 4 ++--
> >  2 files changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/libstdc++-v3/testsuite/libstdc++-prettyprinters/48362.cc 
> > b/libstdc++-v3/testsuite/libstdc++-prettyprinters/48362.cc
> > index cc91803e247..af335d0d3c7 100644
> > --- a/libstdc++-v3/testsuite/libstdc++-prettyprinters/48362.cc
> > +++ b/libstdc++-v3/testsuite/libstdc++-prettyprinters/48362.cc
> > @@ -29,7 +29,7 @@ main()
> >  // { dg-final { note-test t1 {empty std::tuple} } }
> >
> >std::tuple> t2{ "Johnny", 5, {} };
> > -// { dg-final { regexp-test t2 {std::tuple containing = {\[1\] = "Johnny", 
> > \[2\] = 5, \[3\] = empty std::tuple}} } }
> > +// { dg-final { regexp-test t2 {std::tuple containing = {\[0\] = "Johnny", 
> > \[1\] = 5, \[2\] = empty std::tuple}} } }
> >
> >std::cout << "\n";
> >return 0; // Mark SPOT
> > diff --git a/libstdc++-v3/testsuite/libstdc++-prettyprinters/cxx11.cc 
> > b/libstdc++-v3/testsuite/libstdc++-prettyprinters/cxx11.cc
> > index f97640a0189..bc5978ee69d 100644
> > --- a/libstdc++-v3/testsuite/libstdc++-prettyprinters/cxx11.cc
> > +++ b/libstdc++-v3/testsuite/libstdc++-prettyprinters/cxx11.cc
> > @@ -166,9 +166,9 @@ main()
> >  // { dg-final { note-test runiq_ptr {std::unique_ptr = {get() = 0x0}} 
> > } }
> >
> >ExTuple tpl(6,7);
> > -// { dg-final { note-test tpl {std::tuple containing = {[1] = 6, [2] = 7}} 
> > } }
> > +// { dg-final { note-test tpl {std::tuple containing = {[0] = 6, [1] = 7}} 
> > } }
> >ExTuple  = tpl;
> > -// { dg-final { note-test rtpl {std::tuple containing = {[1] = 6, [2] = 
> > 7}} } }
> > +// { dg-final { note-test rtpl {std::tuple containing = {[0] = 6, [1] = 
> > 7}} } }
> >
> >std::error_code e0;
> >// { dg-final { note-test e0 {std::error_code = { }} } }
> > --
> > 2.37.3
> >
>

Re: [PATCH] d: Fix #error You must define PREFERRED_DEBUGGING_TYPE if DWARF is not supported (PR105659)

[Iain Buclaw via Gcc-patches]

Excerpts from Rainer Orth's message of September 6, 2022 9:42 am:
> Hi Iain,
> 
>> Excerpts from Richard Biener's message of September 1, 2022 8:28 am:
>>> On Wed, Aug 31, 2022 at 9:21 PM Iain Buclaw  wrote:
>>> 
>>> Ah yes - I think, even if a bit verbose, this is exactly how it was supposed
>>> to be?
>>> 
>>> OK from my side.
>>> 
>>
>> To access the TARGET macros from arm-d.cc, arm-protos.h had to be
>> included (after tm_p.h was removed).
>>
>> All ~200 configurations in contrib/config-list.mk now build again with
>> the D front-end enabled.
> 
> unfortunately, this patch broke all Solaris configs
> (i386-pc-solaris2.11, sparc-sun-solaris2.11, sparcv9-sun-solaris2.11).
> libphobos configure in stage2 fails with
> 
> can compile D sources
> configure:5402: /var/gcc/regression/master/11.4-gcc/build/./gcc/gdc 
> -B/var/gcc/regression/master/11.4-gcc/build/./gcc/ 
> -B/vol/gcc/i386-pc-solaris2.11/bin/ -B/vol/gcc/i386-pc-solaris2.11/lib/ 
> -isystem /vol/gcc/i386-pc-solaris2.11/include -isystem 
> /vol/gcc/i386-pc-solaris2.11/sys-include   -fno-checking -c -fno-druntime 
> -nostdinc -I /vol/gcc/src/hg/master/local/libphobos/libdruntime  -g -O2   
> conftest.d >&5
> core.exception.ArrayIndexError@/vol/gcc/src/hg/master/local/gcc/d/dmd/root/stringtable.d(291):
>  index [3530971477] is out of bounds for array of length 0
> gcc.deh(505): uncaught exception
> 
> I don't yet see why, though.

Hi Rainer,

Is there a difference in output from `./gcc/d21 -quiet -v` ?

Pay attention to any predefs that have suddenly appeared or disappeared.

Regards,
Iain.

Re: [PATCH] nvptx: Silence unused variable warning

[Tom de Vries via Gcc-patches]

On 8/28/22 13:09, Jan-Benedict Glaw wrote:

Hi!

The nvptx backend defines ASM_OUTPUT_DEF along with
ASM_OUTPUT_DEF_FROM_DECLS.  Much like the rs6000 coff target, nvptx
triggers an unused variable warning:

/usr/lib/gcc-snapshot/bin/g++  -fno-PIE -c   -g -O2   -DIN_GCC  
-DCROSS_DIRECTORY_STRUCTURE   -fno-exceptions -fno-rtti 
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings 
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic 
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common 
 -DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. 
-I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include 
-I../../gcc/gcc/../libcody  -I../../gcc/gcc/../libdecnumber 
-I../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber 
-I../../gcc/gcc/../libbacktrace   -o varasm.o -MT varasm.o -MMD -MP -MF 
./.deps/varasm.TPo ../../gcc/gcc/varasm.cc
../../gcc/gcc/varasm.cc: In function 'void 
output_constant_pool_contents(rtx_constant_pool*)':
../../gcc/gcc/varasm.cc:4318:21: error: unused variable 'name' 
[-Werror=unused-variable]
  4318 | const char *name = XSTR (desc->sym, 0);
   | ^~~~
cc1plus: all warnings being treated as errors
make[1]: *** [Makefile:1145: varasm.o] Error 1


Fixed the same way:

diff --git a/gcc/config/nvptx/nvptx.h b/gcc/config/nvptx/nvptx.h
index ed72c253191..71297440566 100644
--- a/gcc/config/nvptx/nvptx.h
+++ b/gcc/config/nvptx/nvptx.h
@@ -321,6 +321,9 @@ struct GTY(()) machine_function
  #define ASM_OUTPUT_DEF(FILE,LABEL1,LABEL2)\
do  \
  { \
+  (void) (FILE);   \
+  (void) (LABEL1); \
+  (void) (LABEL2); \
gcc_unreachable (); \
  } \
while (0)


Ok for HEAD?



LGTM.

Thanks,
- Tom

[PATCH] Enable shrink wrapping for the RISC-V target.

[mtsamis]

This commit implements the target macros (TARGET_SHRINK_WRAP_*) that
enable separate shrink wrapping for function prologues/epilogues in
RISC-V.

Tested against SPEC CPU 2017, this change always has a net-positive
effect on the dynamic instruction count.  See the following table for
the breakdown on how this reduces the number of dynamic instructions
per workload on a like-for-like (i.e., same config file; suppressing
shrink-wrapping with -fno-shrink-wrap):

 # dynamic instructions
w/o shrink-wrap   w/ shrink-wrap  reduction
500.perlbench_r   12657167865931262156218578 3560568015   0.28%
500.perlbench_r779224795689 76533700902513887786664   1.78%
500.perlbench_r724087331471 71130715252212780178949   1.77%
502.gcc_r  204259864844 194517006339 9742858505   4.77%
502.gcc_r  244047794302 23155583472212491959580   5.12%
502.gcc_r  230896069400 221877703011 9018366389   3.91%
502.gcc_r  192130616624 183856450605 8274166019   4.31%
502.gcc_r  258875074079 2477562032268870853   4.30%
505.mcf_r  662653430325 660678680547 1974749778   0.30%
520.omnetpp_r  985114167068 93419131015450922856914   5.17%
523.xalancbmk_r927037633578 921688937650 5348695928   0.58%
525.x264_r 490953958454 490565583447  388375007   0.08%
525.x264_r19946622944211993171932425 1490361996   0.07%
525.x264_r18976171204501896062750609 1554369841   0.08%
531.deepsjeng_r   1695189878907166930413041125885748496   1.53%
541.leela_r   192594122189790086119828040361024   1.46%
548.exchange2_r   20738162279442073816226729   1215   0.00%
557.xz_r   379572090003 379057409041  514680962   0.14%
557.xz_r   953117469352 952680431430  437037922   0.05%
557.xz_r   536859579650 536456690164  402889486   0.08%
 18421773405376   18223938521833   197834883543   1.07%  totals

Signed-off-by: Manolis Tsamis 

gcc/ChangeLog:

* config/riscv/riscv.cc (struct machine_function): Add array to store
register wrapping information.
(riscv_for_each_saved_reg): Skip registers that are wrapped separetely.
(riscv_get_separate_components): New function.
(riscv_components_for_bb): Likewise.
(riscv_disqualify_components): Likewise.
(riscv_process_components): Likewise.
(riscv_emit_prologue_components): Likewise.
(riscv_emit_epilogue_components): Likewise.
(riscv_set_handled_components): Likewise.
(TARGET_SHRINK_WRAP_GET_SEPARATE_COMPONENTS): Define.
(TARGET_SHRINK_WRAP_COMPONENTS_FOR_BB): Likewise.
(TARGET_SHRINK_WRAP_DISQUALIFY_COMPONENTS): Likewise.
(TARGET_SHRINK_WRAP_EMIT_PROLOGUE_COMPONENTS): Likewise.
(TARGET_SHRINK_WRAP_EMIT_EPILOGUE_COMPONENTS): Likewise.
(TARGET_SHRINK_WRAP_SET_HANDLED_COMPONENTS): Likewise.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/shrink-wrap-1.c: New test.

---

 gcc/config/riscv/riscv.cc | 187 +-
 .../gcc.target/riscv/shrink-wrap-1.c  |  25 +++
 2 files changed, 210 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/riscv/shrink-wrap-1.c

diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index 5a0adffb5ce..3b633149a9a 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -25,6 +25,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "config.h"
 #include "system.h"
 #include "coretypes.h"
+#include "backend.h"
 #include "tm.h"
 #include "rtl.h"
 #include "regs.h"
@@ -52,6 +53,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "optabs.h"
 #include "bitmap.h"
 #include "df.h"
+#include "function-abi.h"
 #include "diagnostic.h"
 #include "builtins.h"
 #include "predict.h"
@@ -147,6 +149,11 @@ struct GTY(())  machine_function {
 
   /* The current frame information, calculated by riscv_compute_frame_info.  */
   struct riscv_frame_info frame;
+
+  /* The components already handled by separate shrink-wrapping, which should
+ not be considered by the prologue and epilogue.  */
+  bool reg_is_wrapped_separately[FIRST_PSEUDO_REGISTER];
+
 };
 
 /* Information about a single argument.  */
@@ -4209,7 +4216,7 @@ riscv_for_each_saved_reg (HOST_WIDE_INT sp_offset, 
riscv_save_restore_fn fn,
   for (unsigned int regno = GP_REG_FIRST; regno <= GP_REG_LAST; regno++)
 if (BITSET_P (cfun->machine->frame.mask, regno - GP_REG_FIRST))
   {
-   bool handle_reg = TRUE;
+   bool handle_reg = !cfun->machine->reg_is_wrapped_separately[regno];
 
/* If this is a normal return in a function that calls the eh_return
   builtin, then do not restore the eh return data registers as that
@@ -4240,9 +4247,11 @@ riscv_for_each_saved_reg 

Re: [COMMITTED] Be even more conservative in intersection of NANs.

[Aldy Hernandez via Gcc-patches]

On Tue, Sep 6, 2022, 11:09 Richard Biener 
wrote:

> On Tue, Sep 6, 2022 at 9:21 AM Aldy Hernandez  wrote:
> >
> > On Mon, Sep 5, 2022 at 2:16 PM Richard Biener
> >  wrote:
> > >
> > > On Mon, Sep 5, 2022 at 1:45 PM Aldy Hernandez 
> wrote:
> > > >
> > > > On Mon, Sep 5, 2022 at 12:38 PM Richard Biener
> > > >  wrote:
> > > > >
> > > > > On Mon, Sep 5, 2022 at 12:24 PM Aldy Hernandez 
> wrote:
> > > > > >
> > > > > > On Mon, Sep 5, 2022 at 11:53 AM Richard Biener
> > > > > >  wrote:
> > > > > > >
> > > > > > > On Mon, Sep 5, 2022 at 11:41 AM Aldy Hernandez <
> al...@redhat.com> wrote:
> > > > > > > >
> > > > > > > > On Mon, Sep 5, 2022 at 11:18 AM Richard Biener
> > > > > > > >  wrote:
> > > > > > > > >
> > > > > > > > > On Mon, Sep 5, 2022 at 11:12 AM Aldy Hernandez <
> al...@redhat.com> wrote:
> > > > > > > > > >
> > > > > > > > > > On Mon, Sep 5, 2022 at 11:06 AM Jakub Jelinek <
> ja...@redhat.com> wrote:
> > > > > > > > > > >
> > > > > > > > > > > On Mon, Sep 05, 2022 at 11:00:54AM +0200, Richard
> Biener wrote:
> > > > > > > > > > > > On Mon, Sep 5, 2022 at 8:24 AM Aldy Hernandez via
> Gcc-patches
> > > > > > > > > > > >  wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > Intersecting two ranges where one is a NAN is
> keeping the sign bit of
> > > > > > > > > > > > > the NAN range.  This is not correct as the sign
> bits may not match.
> > > > > > > > > > > > >
> > > > > > > > > > > > > I think the only time we're absolutely sure about
> the intersection of
> > > > > > > > > > > > > a NAN and something else, is when both are a NAN
> with exactly the same
> > > > > > > > > > > > > properties (sign bit).  If we're intersecting two
> NANs of differing
> > > > > > > > > > > > > sign, we can decide later whether that's undefined
> or just a NAN with
> > > > > > > > > > > > > no known sign.  For now I've done the latter.
> > > > > > > > > > > > >
> > > > > > > > > > > > > I'm still mentally working on intersections
> involving NANs, especially
> > > > > > > > > > > > > if we want to keep track of signbits.  For now,
> let's be extra careful
> > > > > > > > > > > > > and only do things we're absolutely sure about.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Later we may want to fold the intersect of
> [NAN,NAN] and say [3,5]
> > > > > > > > > > > > > with the posibility of NAN, to a NAN, but I'm not
> 100% sure.
> > > > > > > > > > > >
> > > > > > > > > > > > The intersection of [NAN, NAN] and [3, 5] is empty.
> The intersection
> > > > > > > > > > > > of [NAN, NAN] and VARYING is [NAN, NAN].
> > > > > > > > > > >
> > > > > > > > > > > I think [3.0, 5.0] printed that way currently means U
> maybe NAN,
> > > > > > > > > > > it would be [3.0, 5.0] !NAN if it was known not to be
> NAN.
> > > > > > > > > >
> > > > > > > > > > Right.  I don't print any of the "maybe" properties,
> just if they're
> > > > > > > > > > definitely set or definitely clear.  I'm open to
> suggestions as to how
> > > > > > > > > > to display them.  Perhaps NAN, !NAN, ?NAN.
> > > > > > > > >
> > > > > > > > > There's no NAN tristate.  Your "definitely NAN" would be
> simply
> > > > > > > > > ][ NAN, that is, the value range only contains NAN.  Your
> !NAN
> > > > > > > > > is  and non NAN.  Likewise for the sign,
> the
> > > > > > > > > range either includes -NAN and NAN or one or none of those.
> > > > > > > > > For signed zeros you either have [-0, upper-bound] or [0,
> upper-bound]
> > > > > > > > > where it either includes both -0 and 0 or just one of them
> > > > > > > >
> > > > > > > > But there is a tristate.  We may definitely have a NAN,
> definitely not
> > > > > > > > have a NAN, or the state of the NAN is unknown.
> > > > > > >
> > > > > > > Sure.  But we are talking about sets of values a variable can
> have
> > > > > > > (a value "range" where "range" is a bit misleading for
> something
> > > > > > > like a NAN).  The set of possible values either includes
> > > > > > > NAN (or -NAN and +NAN) or it doesn't include NAN (or -NAN and
> +NAN).
> > > > > > > A set cannot include or not include a "maybe NAN".
> > > > > > >
> > > > > > > >  Say [3,5] ?NAN.
> > > > > > > > That's [3,5] with the possibility of a NAN.  On the true
> side of x >=
> > > > > > > > 5.0, we'd have [5.0, INF] !NAN.  On the false side we'd have
> [-INF,
> > > > > > > > 5.0] ?NAN.
> > > > > > >
> > > > > > > On the true side of x >= 5.0 the set of values is described by
> > > > > > > the [5., +INF] range.  On the false side the set is described
> > > > > > > by the union of the range [-INF, 5.0] and the { -NAN, +NAN }
> > > > > > > set.
> > > > > > >
> > > > > > > There's no may-NAN.  There's also no ?4.0, the range either
> > > > > > > includes 4.0 or it doesn't.
> > > > > >
> > > > > > Ah, ok.  I see where the confusion lies.  You're missing that we
> don't
> > > > > > have sub-ranges like we do for irange.  We only have two
> endpoints and
> > > > > > a set of flags.  So we can't represent [3,4] U NAN "elegantly".
> > > > > > However, we 

RE: [PATCH][committed] aarch64: Suggest an -mcpu option when user passes CPU name to -march

[Kyrylo Tkachov via Gcc-patches]

> -Original Message-
> From: Richard Earnshaw 
> Sent: Monday, September 5, 2022 2:43 PM
> To: Kyrylo Tkachov ; gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH][committed] aarch64: Suggest an -mcpu option when
> user passes CPU name to -march
> 
> 
> 
> On 05/09/2022 14:35, Kyrylo Tkachov via Gcc-patches wrote:
> > Hi all,
> >
> > This small patch helps users who confuse -march and -mcpu on AArch64.
> > Sometimes users pass -march with a CPU name, where they most likely
> wanted to
> > use -mcpu, which would select the right architecture features *and* tune
> for
> > their desired CPU. Currently we'll just error out with an unkown
> architecture
> > message and list the valid architecture options.
> > With this patch we check if their string matches a known CPU and suggest
> they
> > use an -mcpu option instead.
> >
> > So compiling with -march=neoverse-n1 will now give the error:
> > cc1: error: unknown value 'neoverse-n1' for '-march'
> > cc1: note: valid arguments are: armv8-a armv8.1-a armv8.2-a armv8.3-a
> armv8.4-a armv8.5-a armv8.6-a armv8.7-a armv8.8-a armv8-r armv9-a
> > cc1: note: did you mean '-mcpu=neoverse-n1'?
> >
> > Bootstrapped and tested on aarch64-none-linux-gnu.
> > Pushing to trunk.
> > Thanks,
> > Kyrill
> >
> > gcc/ChangeLog:
> >
> > * config/aarch64/aarch64.cc (aarch64_validate_march): Check if
> invalid arch
> > string is a valid -mcpu string and emit hint.
> >
> > gcc/testsuite/ChangeLog:
> >
> > * gcc.target/aarch64/spellcheck_10.c: New test.
> 
> What about the reverse case, passing an architecture to -mcpu?

It'd be good to warn for that too, though I think it's a somewhat less common 
error.
It can be a separate patch in any case.
Thanks,
Kyrill

> 
> R.

[PATCH] expand: Convert cst - x into cst xor x.

[Robin Dapp via Gcc-patches]

Hi,

posting this separately from PR91213 now.  I wrote an s390 test and most
likely it could also be done for x86 which will give it broader coverage.

Depending on the backend it might be better to convert
  cst - x
into
  cst xor x
if cst + 1 is a power of two and 0 <= x <= cst.  This patch compares
both sequences and emits the less expensive one.

Does this look like a viable approach? Bootstrapped and regtested on
s390[x], waited with x86 tests until a first round of comments.

Regards
 Robin

gcc/ChangeLog:

PR middle-end/91213
* expr.cc (expand_expr_real_2): Call new function.
(maybe_optimize_cst_sub): New function.
* expr.h (maybe_optimize_cst_sub): Define.

gcc/testsuite/ChangeLog:

* gcc.target/s390/cst-minus-var.c: New test.

---
 gcc/expr.cc   | 79 +++
 gcc/expr.h|  2 +
 gcc/testsuite/gcc.target/s390/cst-minus-var.c | 55 +
 3 files changed, 136 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/s390/cst-minus-var.c

diff --git a/gcc/expr.cc b/gcc/expr.cc
index 80bb1b8a4c5b..80f25720d7b6 100644
--- a/gcc/expr.cc
+++ b/gcc/expr.cc
@@ -9397,6 +9397,21 @@ expand_expr_real_2 (sepops ops, rtx target,
machine_mode tmode,
  return simplify_gen_binary (MINUS, mode, op0, op1);
}

+  /* Convert const - A to const xor A if integer_pow2p (const + 1)
+and 0 <= A <= const.  */
+  if (code == MINUS_EXPR
+ && SCALAR_INT_MODE_P (mode)
+ && TREE_CODE (treeop0) == INTEGER_CST
+ && TREE_CODE (TREE_TYPE (treeop1)) == INTEGER_TYPE
+ && wi::exact_log2 (wi::to_widest (treeop0) + 1) != -1)
+   {
+ rtx res = maybe_optimize_cst_sub (code, treeop0, treeop1,
+   mode, unsignedp, type,
+   target, subtarget);
+ if (res)
+   return res;
+   }
+
   /* No sense saving up arithmetic to be done
 if it's all in the wrong mode to form part of an address.
 And force_operand won't know whether to sign-extend or
@@ -12692,6 +12707,70 @@ maybe_optimize_mod_cmp (enum tree_code code,
tree *arg0, tree *arg1)
   return code == EQ_EXPR ? LE_EXPR : GT_EXPR;
 }

+/* Convert const - A to const xor A if integer_pow2p (const + 1)
+   and 0 <= A <= const.  */
+
+rtx
+maybe_optimize_cst_sub (enum tree_code code, tree treeop0, tree treeop1,
+   machine_mode mode, int unsignedp, tree type,
+   rtx target, rtx subtarget)
+{
+  gcc_checking_assert (code == MINUS_EXPR);
+  gcc_checking_assert (SCALAR_INT_MODE_P (mode));
+  gcc_checking_assert (TREE_CODE (treeop0) == INTEGER_CST);
+  gcc_checking_assert (TREE_CODE (TREE_TYPE (treeop1)) == INTEGER_TYPE);
+  gcc_checking_assert (wi::exact_log2 (wi::to_widest (treeop0) + 1) != -1);
+
+  if (!optimize)
+return NULL_RTX;
+
+  optab this_optab;
+  rtx op0, op1;
+
+  if (wi::leu_p (tree_nonzero_bits (treeop1), tree_nonzero_bits (treeop0)))
+{
+  expand_operands (treeop0, treeop1, subtarget, , ,
+  EXPAND_NORMAL);
+  bool speed_p = optimize_insn_for_speed_p ();
+  do_pending_stack_adjust ();
+  start_sequence ();
+  this_optab = optab_for_tree_code (MINUS_EXPR, type,
+   optab_default);
+  rtx subi = expand_binop (mode, this_optab, op0, op1, target,
+  unsignedp, OPTAB_LIB_WIDEN);
+
+  rtx_insn *sub_insns = get_insns ();
+  end_sequence ();
+  start_sequence ();
+  this_optab = optab_for_tree_code (BIT_XOR_EXPR, type,
+   optab_default);
+  rtx xori = expand_binop (mode, this_optab, op0, op1, target,
+  unsignedp, OPTAB_LIB_WIDEN);
+  rtx_insn *xor_insns = get_insns ();
+  end_sequence ();
+  unsigned sub_cost = seq_cost (sub_insns, speed_p);
+  unsigned xor_cost = seq_cost (xor_insns, speed_p);
+  /* If costs are the same then use as tie breaker the other other
+factor.  */
+  if (sub_cost == xor_cost)
+   {
+ sub_cost = seq_cost (sub_insns, !speed_p);
+ xor_cost = seq_cost (xor_insns, !speed_p);
+   }
+
+  if (sub_cost <= xor_cost)
+   {
+ emit_insn (sub_insns);
+ return subi;
+   }
+
+  emit_insn (xor_insns);
+  return xori;
+}
+
+  return NULL_RTX;
+}
+
 /* Optimize x - y < 0 into x < 0 if x - y has undefined overflow.  */

 void
diff --git a/gcc/expr.h b/gcc/expr.h
index 08b59b8d869a..43ea11042d26 100644
--- a/gcc/expr.h
+++ b/gcc/expr.h
@@ -326,6 +326,8 @@ extern tree string_constant (tree, tree *, tree *,
tree *);
 extern tree byte_representation (tree, tree *, tree *, tree *);

 extern enum tree_code maybe_optimize_mod_cmp (enum tree_code, tree *,
tree *);
+extern rtx maybe_optimize_cst_sub (enum tree_code, tree, tree,
+

[PATCH] tree-optimization/106844 - fix ICE in init_use_preds

[Richard Biener via Gcc-patches]

The following fixes an oversight in the last change to
compute_control_dep_chain where we have to return whether we found
a chain.

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

PR tree-optimization/106844
* gimple-predicate-analysis.cc (compute_control_dep_chain):
Return whether we found a chain.

* gcc.dg/pr106844.c: New testcase.
---
 gcc/gimple-predicate-analysis.cc |  2 +-
 gcc/testsuite/gcc.dg/pr106844.c  | 16 
 2 files changed, 17 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.dg/pr106844.c

diff --git a/gcc/gimple-predicate-analysis.cc b/gcc/gimple-predicate-analysis.cc
index 681047deee7..ef2906ebc51 100644
--- a/gcc/gimple-predicate-analysis.cc
+++ b/gcc/gimple-predicate-analysis.cc
@@ -1077,7 +1077,7 @@ compute_control_dep_chain (basic_block dom_bb, 
const_basic_block dep_bb,
  if (dump_file)
fprintf (dump_file, "param_uninit_control_dep_attempts "
 "exceeded: %u\n", *num_calls);
- return false;
+ break;
}
  ++*num_calls;
 
diff --git a/gcc/testsuite/gcc.dg/pr106844.c b/gcc/testsuite/gcc.dg/pr106844.c
new file mode 100644
index 000..df68d76f257
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr106844.c
@@ -0,0 +1,16 @@
+/* { dg-do compile } */
+/* { dg-options "-O -Wuninitialized --param uninit-control-dep-attempts=1" } */
+
+struct {
+  int count;
+  int array[8];
+} fde_merge_v1;
+
+void
+fde_merge_i2() {
+  unsigned i1;
+  do
+while (i1 && fde_merge_v1.array[i1 - 1]) /* { dg-warning "uninitialized" } 
*/
+  i1--;
+  while (fde_merge_i2);
+}
-- 
2.35.3

Re: [COMMITTED] Be even more conservative in intersection of NANs.

[Richard Biener via Gcc-patches]

On Tue, Sep 6, 2022 at 9:21 AM Aldy Hernandez  wrote:
>
> On Mon, Sep 5, 2022 at 2:16 PM Richard Biener
>  wrote:
> >
> > On Mon, Sep 5, 2022 at 1:45 PM Aldy Hernandez  wrote:
> > >
> > > On Mon, Sep 5, 2022 at 12:38 PM Richard Biener
> > >  wrote:
> > > >
> > > > On Mon, Sep 5, 2022 at 12:24 PM Aldy Hernandez  wrote:
> > > > >
> > > > > On Mon, Sep 5, 2022 at 11:53 AM Richard Biener
> > > > >  wrote:
> > > > > >
> > > > > > On Mon, Sep 5, 2022 at 11:41 AM Aldy Hernandez  
> > > > > > wrote:
> > > > > > >
> > > > > > > On Mon, Sep 5, 2022 at 11:18 AM Richard Biener
> > > > > > >  wrote:
> > > > > > > >
> > > > > > > > On Mon, Sep 5, 2022 at 11:12 AM Aldy Hernandez 
> > > > > > > >  wrote:
> > > > > > > > >
> > > > > > > > > On Mon, Sep 5, 2022 at 11:06 AM Jakub Jelinek 
> > > > > > > > >  wrote:
> > > > > > > > > >
> > > > > > > > > > On Mon, Sep 05, 2022 at 11:00:54AM +0200, Richard Biener 
> > > > > > > > > > wrote:
> > > > > > > > > > > On Mon, Sep 5, 2022 at 8:24 AM Aldy Hernandez via 
> > > > > > > > > > > Gcc-patches
> > > > > > > > > > >  wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > Intersecting two ranges where one is a NAN is keeping 
> > > > > > > > > > > > the sign bit of
> > > > > > > > > > > > the NAN range.  This is not correct as the sign bits 
> > > > > > > > > > > > may not match.
> > > > > > > > > > > >
> > > > > > > > > > > > I think the only time we're absolutely sure about the 
> > > > > > > > > > > > intersection of
> > > > > > > > > > > > a NAN and something else, is when both are a NAN with 
> > > > > > > > > > > > exactly the same
> > > > > > > > > > > > properties (sign bit).  If we're intersecting two NANs 
> > > > > > > > > > > > of differing
> > > > > > > > > > > > sign, we can decide later whether that's undefined or 
> > > > > > > > > > > > just a NAN with
> > > > > > > > > > > > no known sign.  For now I've done the latter.
> > > > > > > > > > > >
> > > > > > > > > > > > I'm still mentally working on intersections involving 
> > > > > > > > > > > > NANs, especially
> > > > > > > > > > > > if we want to keep track of signbits.  For now, let's 
> > > > > > > > > > > > be extra careful
> > > > > > > > > > > > and only do things we're absolutely sure about.
> > > > > > > > > > > >
> > > > > > > > > > > > Later we may want to fold the intersect of [NAN,NAN] 
> > > > > > > > > > > > and say [3,5]
> > > > > > > > > > > > with the posibility of NAN, to a NAN, but I'm not 100% 
> > > > > > > > > > > > sure.
> > > > > > > > > > >
> > > > > > > > > > > The intersection of [NAN, NAN] and [3, 5] is empty.  The 
> > > > > > > > > > > intersection
> > > > > > > > > > > of [NAN, NAN] and VARYING is [NAN, NAN].
> > > > > > > > > >
> > > > > > > > > > I think [3.0, 5.0] printed that way currently means U maybe 
> > > > > > > > > > NAN,
> > > > > > > > > > it would be [3.0, 5.0] !NAN if it was known not to be NAN.
> > > > > > > > >
> > > > > > > > > Right.  I don't print any of the "maybe" properties, just if 
> > > > > > > > > they're
> > > > > > > > > definitely set or definitely clear.  I'm open to suggestions 
> > > > > > > > > as to how
> > > > > > > > > to display them.  Perhaps NAN, !NAN, ?NAN.
> > > > > > > >
> > > > > > > > There's no NAN tristate.  Your "definitely NAN" would be simply
> > > > > > > > ][ NAN, that is, the value range only contains NAN.  Your !NAN
> > > > > > > > is  and non NAN.  Likewise for the sign, the
> > > > > > > > range either includes -NAN and NAN or one or none of those.
> > > > > > > > For signed zeros you either have [-0, upper-bound] or [0, 
> > > > > > > > upper-bound]
> > > > > > > > where it either includes both -0 and 0 or just one of them
> > > > > > >
> > > > > > > But there is a tristate.  We may definitely have a NAN, 
> > > > > > > definitely not
> > > > > > > have a NAN, or the state of the NAN is unknown.
> > > > > >
> > > > > > Sure.  But we are talking about sets of values a variable can have
> > > > > > (a value "range" where "range" is a bit misleading for something
> > > > > > like a NAN).  The set of possible values either includes
> > > > > > NAN (or -NAN and +NAN) or it doesn't include NAN (or -NAN and +NAN).
> > > > > > A set cannot include or not include a "maybe NAN".
> > > > > >
> > > > > > >  Say [3,5] ?NAN.
> > > > > > > That's [3,5] with the possibility of a NAN.  On the true side of 
> > > > > > > x >=
> > > > > > > 5.0, we'd have [5.0, INF] !NAN.  On the false side we'd have 
> > > > > > > [-INF,
> > > > > > > 5.0] ?NAN.
> > > > > >
> > > > > > On the true side of x >= 5.0 the set of values is described by
> > > > > > the [5., +INF] range.  On the false side the set is described
> > > > > > by the union of the range [-INF, 5.0] and the { -NAN, +NAN }
> > > > > > set.
> > > > > >
> > > > > > There's no may-NAN.  There's also no ?4.0, the range either
> > > > > > includes 4.0 or it doesn't.
> > > > >
> > > > > Ah, ok.  I see where the confusion lies.  You're missing that we don't
> > > > > have sub-ranges like we do 

Re: [PATCH] msp430: Mark unused attribute

[Richard Biener via Gcc-patches]

On Tue, Sep 6, 2022 at 9:57 AM Jan-Benedict Glaw  wrote:
>
> Hi Nick!
>
> This patch fixes a small warning in the msp430 backend (tested for
> --target=msp430-elf and --target=msp430-elfbare).
>
> .../gcc/configure --prefix=... --enable-werror-always --enable-languages=all 
> --disable-gcov --disable-shared --disable-threads --target=msp430-elf 
> --without-headers
> [...]
> make V=1 all-gcc
> [...]
> /usr/lib/gcc-snapshot/bin/g++  -fno-PIE -c   -g -O2   -DIN_GCC  
> -DCROSS_DIRECTORY_STRUCTURE   -fno-exceptions -fno-rtti 
> -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings 
> -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic 
> -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror 
> -fno-common  -DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. 
> -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include 
> -I../../gcc/gcc/../libcody  -I../../gcc/gcc/../libdecnumber 
> -I../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber 
> -I../../gcc/gcc/../libbacktrace   -o msp430.o -MT msp430.o -MMD -MP -MF 
> ./.deps/msp430.TPo ../../gcc/gcc/config/msp430/msp430.cc
> ../../gcc/gcc/config/msp430/msp430.cc: In function 'int 
> msp430_single_op_cost(rtx, bool, rtx)':
> ../../gcc/gcc/config/msp430/msp430.cc:1463:49: error: unused parameter 
> 'outer_rtx' [-Werror=unused-parameter]
>  1463 | msp430_single_op_cost (rtx dst, bool speed, rtx outer_rtx)
>   | ^
> cc1plus: all warnings being treated as errors
> make[1]: *** [Makefile:2440: msp430.o] Error 1
> make[1]: Leaving directory 
> '/var/lib/laminar/run/gcc-msp430-elf/1/toolchain-build/gcc'
> make: *** [Makefile:4584: all-gcc] Error 2
>
>
>
> 2022-09-06  Jan-Benedict Glaw  
>
> gcc/ChangeLog:
> * config/msp430/msp430.cc (msp430_single_op_cost): Mark unused 
> argument.
>
> diff --git a/gcc/config/msp430/msp430.cc b/gcc/config/msp430/msp430.cc
> index 7a378ceac56..2909cabd3ff 100644
> --- a/gcc/config/msp430/msp430.cc
> +++ b/gcc/config/msp430/msp430.cc
> @@ -1460,7 +1460,7 @@ msp430_get_inner_dest_code (rtx x)
>  /* Calculate the cost of an MSP430 single-operand instruction, for operand 
> DST
> within the RTX OUTER_RTX, optimizing for speed if SPEED is true.  */
>  static int
> -msp430_single_op_cost (rtx dst, bool speed, rtx outer_rtx)
> +msp430_single_op_cost (rtx dst, bool speed, rtx outer_rtx ATTRIBUTE_UNUSED)

You can just drop the argument identifier since we're C++ now.  Or use
rtx /* outer_rtx */
for documentation purposes.

OK with that change.

Richard.

>  {
>enum rtx_code dst_code = GET_CODE (dst);
>const struct single_op_cost *cost_p;
>
>
>
> Okay for HEAD?
>
> Thanks,
>   Jan-Benedict
>
> --

[PATCH] tree-optimization/106841 - gather and hybrid SLP

[Richard Biener via Gcc-patches]

Hybrid SLP detection currently fails to consider a not direct
offset operand of a scatter/gather operation.  The following fixes
this.

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

PR tree-optimization/106841
* tree-vect-slp.cc (vect_detect_hybrid_slp): Also process
scatter/gather offset.

* g++.dg/vect/pr106841.cc: New testcase.
---
 gcc/testsuite/g++.dg/vect/pr106841.cc | 52 +++
 gcc/tree-vect-slp.cc  |  9 +
 2 files changed, 61 insertions(+)
 create mode 100644 gcc/testsuite/g++.dg/vect/pr106841.cc

diff --git a/gcc/testsuite/g++.dg/vect/pr106841.cc 
b/gcc/testsuite/g++.dg/vect/pr106841.cc
new file mode 100644
index 000..7458bc15a25
--- /dev/null
+++ b/gcc/testsuite/g++.dg/vect/pr106841.cc
@@ -0,0 +1,52 @@
+// { dg-do compile }
+// { dg-additional-options "-O3 -ffast-math" }
+// { dg-additional-options "-march=bdver2" { target x86_64-*-* } }
+
+struct R3 {
+  double z;
+  R3(R3 A, R3 B) : z(B.z - A.z) {}
+  double norme() { return z; }
+};
+struct TBoundaryEdge {
+  int *vertices[2];
+  int [](int i) { return *vertices[i]; }
+};
+struct Mesh {
+  int vertices;
+  TBoundaryEdge *bedges;
+  int operator()(int ) { return  -  }
+  TBoundaryEdge be(int i) { return bedges[i]; }
+};
+template  struct GenericElement {
+  typedef typename Data::V Vertex;
+  static const int nv = Data::NbOfVertices;
+  Vertex *vertices[nv];
+  double mes;
+  void set(int *iv, Vertex *v0) {
+for (int i = 0; i < nv; ++i)
+  vertices[i] = v0 + iv[i];
+mes = Data::mesure(vertices);
+  }
+};
+struct DataSeg3 {
+  static const int NbOfVertices = 2;
+  typedef R3 V;
+  static double mesure(V *pv[]) { return R3(*pv[0], *pv[1]).norme(); }
+};
+struct MeshS {
+  MeshS();
+};
+template  struct Movemesh_Op { void foo(Mesh, DataSeg3::V *) const; };
+template <> void Movemesh_Op::foo(Mesh pTh, DataSeg3::V *v0) const {
+  GenericElement *bS = new GenericElement[8];
+  for (int ibe = 0; ibe < 8; ibe++) {
+TBoundaryEdge K(pTh.be(ibe));
+int iv[2];
+for (int i = 0; i < 2; i++) {
+  int &__trans_tmp_2 = K[i];
+  iv[i] = pTh(__trans_tmp_2);
+}
+bS[ibe].set(iv, v0);
+  }
+  MeshS T_Th;
+}
diff --git a/gcc/tree-vect-slp.cc b/gcc/tree-vect-slp.cc
index b10f69da133..3fa2dc96dda 100644
--- a/gcc/tree-vect-slp.cc
+++ b/gcc/tree-vect-slp.cc
@@ -5799,6 +5799,15 @@ vect_detect_hybrid_slp (loop_vec_info loop_vinfo)
 to use walk_gimple_op.  */
   wi.is_lhs = 0;
   walk_gimple_op (stmt_info->stmt, vect_detect_hybrid_slp, );
+  /* For gather/scatter make sure to walk the offset operand, that
+can be a scaling and conversion away.  */
+  gather_scatter_info gs_info;
+  if (STMT_VINFO_GATHER_SCATTER_P (stmt_info)
+ && vect_check_gather_scatter (stmt_info, loop_vinfo, _info))
+   {
+ int dummy;
+ vect_detect_hybrid_slp (_info.offset, , );
+   }
 }
 }
 
-- 
2.35.3

Re: [r13-2446 Regression] FAIL: gfortran.dg/gomp/doacross-5.f90 -O (test for excess errors) on Linux/x86_64

[Jakub Jelinek via Gcc-patches]

On Tue, Sep 06, 2022 at 10:12:39AM +0200, Tobias Burnus wrote:
> On 06.09.22 09:49, Jakub Jelinek wrote:
> > On Tue, Sep 06, 2022 at 07:54:05AM +0800, haochen.jiang via Gcc-patches 
> > wrote:
> > >  Fortran/openmp: Partial OpenMP 5.2 doacross and omp_cur_iteration 
> > > support
> > > caused
> > > FAIL: gfortran.dg/gomp/doacross-5.f90   -O   (test for errors, line 28)
> > Seems this is still being diagnosed in the FE when it should be deferred to
> > the middle-end now (only when we find out if it is doacross or not).
> 
> I concur – and at some point during patch writing, I had this snippeted
> removed (given that the testcase required it) – but for some reasons, it
> got mangled in again. I have now removed it again/in GCC mainline –
> after successful regtesting.
> 
> Committed as r13-2491-gd6582c662ca0da05c74fa3183e1bc2cadcb21424

Thanks.

Jakub

[PATCH] testsuite/s390: Add -mzarch to ifcvt test cases.

[Robin Dapp via Gcc-patches]

Hi,

this adds a missing -mzarch to some ifcvt test cases.

Going to commit this as obvious in some days barring objections.

Regards
 Robin

gcc/testsuite/ChangeLog:

* gcc.target/s390/ifcvt-one-insn-bool.c: Add -mzarch.
* gcc.target/s390/ifcvt-one-insn-char.c: Dito.
* gcc.target/s390/ifcvt-two-insns-bool.c: Dito.
* gcc.target/s390/ifcvt-two-insns-int.c: Dito.
* gcc.target/s390/ifcvt-two-insns-long.c: Add -mzarch and split
scan into lp64 and ! lp64.

---
 gcc/testsuite/gcc.target/s390/ifcvt-one-insn-bool.c  | 2 +-
 gcc/testsuite/gcc.target/s390/ifcvt-one-insn-char.c  | 2 +-
 gcc/testsuite/gcc.target/s390/ifcvt-two-insns-bool.c | 2 +-
 gcc/testsuite/gcc.target/s390/ifcvt-two-insns-int.c  | 2 +-
 gcc/testsuite/gcc.target/s390/ifcvt-two-insns-long.c | 8 ++--
 5 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/gcc/testsuite/gcc.target/s390/ifcvt-one-insn-bool.c
b/gcc/testsuite/gcc.target/s390/ifcvt-one-insn-bool.c
index 0a96b71f4583..0c8c2f879a69 100644
--- a/gcc/testsuite/gcc.target/s390/ifcvt-one-insn-bool.c
+++ b/gcc/testsuite/gcc.target/s390/ifcvt-one-insn-bool.c
@@ -1,7 +1,7 @@
 /* Check load on condition for bool.  */

 /* { dg-do compile { target { s390*-*-* } } } */
-/* { dg-options "-O2 -march=z13" } */
+/* { dg-options "-O2 -march=z13 -mzarch" } */

 /* { dg-final { scan-assembler "lochinh\t%r.?,1" } } */
 #include 
diff --git a/gcc/testsuite/gcc.target/s390/ifcvt-one-insn-char.c
b/gcc/testsuite/gcc.target/s390/ifcvt-one-insn-char.c
index 9c3d041618b3..8c8e0ae02dfc 100644
--- a/gcc/testsuite/gcc.target/s390/ifcvt-one-insn-char.c
+++ b/gcc/testsuite/gcc.target/s390/ifcvt-one-insn-char.c
@@ -1,7 +1,7 @@
 /* Check load on condition for global char.  */

 /* { dg-do compile { target { s390*-*-* } } } */
-/* { dg-options "-O2 -march=z13" } */
+/* { dg-options "-O2 -march=z13 -mzarch" } */

 /* { dg-final { scan-assembler "locrnh\t%r.?,%r.?" } } */
 #include 
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 df0416a71d83..1027ddceb935 100644
--- a/gcc/testsuite/gcc.target/s390/ifcvt-two-insns-bool.c
+++ b/gcc/testsuite/gcc.target/s390/ifcvt-two-insns-bool.c
@@ -1,7 +1,7 @@
 /* Check if conversion for two instructions.  */

 /* { dg-do run } */
-/* { dg-options "-O2 -march=z13 --save-temps" } */
+/* { dg-options "-O2 -march=z13 -mzarch --save-temps" } */

 /* { dg-final { scan-assembler "lochih\t%r.?,1" } } */
 /* { dg-final { scan-assembler "locrh\t.*" } } */
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 181173b91e97..fc6946f2466d 100644
--- a/gcc/testsuite/gcc.target/s390/ifcvt-two-insns-int.c
+++ b/gcc/testsuite/gcc.target/s390/ifcvt-two-insns-int.c
@@ -1,7 +1,7 @@
 /* Check if conversion for two instructions.  */

 /* { dg-do run } */
-/* { dg-options "-O2 -march=z13 --save-temps" } */
+/* { dg-options "-O2 -march=z13 -mzarch --save-temps" } */

 /* { dg-final { scan-assembler "lochih\t%r.?,1" } } */
 /* { dg-final { scan-assembler "locrh\t.*" } } */
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 c66ef6cfdead..09f6899f01ec 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,12 @@
 /* { dg-do run } */
 /* { dg-options "-O2 -march=z13 --save-temps" } */

-/* { dg-final { scan-assembler "locghih\t%r.?,1" } } */
-/* { dg-final { scan-assembler "locgrh\t.*" } } */
+/* { dg-final { scan-assembler "locghih\t%r.?,1" } { target { lp64 } } */
+/* { dg-final { scan-assembler "locgrh\t.*" } { target { lp64 } } */
+
+/* { dg-final { scan-assembler "lochih\t%r.?,1" } { target { ! lp64 } } */
+/* { dg-final { scan-assembler "locrh\t.*" } { target { ! lp64 } } */
+
 #include 
 #include 
 #include 
-- 
2.31.1

Re: [r13-2446 Regression] FAIL: gfortran.dg/gomp/doacross-5.f90 -O (test for excess errors) on Linux/x86_64

[Tobias Burnus]

On 06.09.22 09:49, Jakub Jelinek wrote:

On Tue, Sep 06, 2022 at 07:54:05AM +0800, haochen.jiang via Gcc-patches wrote:

 Fortran/openmp: Partial OpenMP 5.2 doacross and omp_cur_iteration support
caused
FAIL: gfortran.dg/gomp/doacross-5.f90   -O   (test for errors, line 28)

Seems this is still being diagnosed in the FE when it should be deferred to
the middle-end now (only when we find out if it is doacross or not).


I concur – and at some point during patch writing, I had this snippeted
removed (given that the testcase required it) – but for some reasons, it
got mangled in again. I have now removed it again/in GCC mainline –
after successful regtesting.

Committed as r13-2491-gd6582c662ca0da05c74fa3183e1bc2cadcb21424

Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
commit d6582c662ca0da05c74fa3183e1bc2cadcb21424
Author: Tobias Burnus 
Date:   Tue Sep 6 10:02:13 2022 +0200

Fix Fortran/openmp: Partial OpenMP 5.2 doacross

This removed a checking snippet which accidentally was left in in commit
r13-2446-g938cda536019cd6a1bc0dd2346381185b420bbf8 ; this caused
fails in gfortran.dg/gomp/doacross-5.f90 (added in that very commit).
Note that a similar but refined check is now done in the middle end.
(The ME version additionally checks whether doacross is present.)

gcc/fortran/
* openmp.cc (resolve_omp_clauses): Remove ordered/linear
check as it is handled now in the middle end.
---
 gcc/fortran/openmp.cc | 4 
 1 file changed, 4 deletions(-)

diff --git a/gcc/fortran/openmp.cc b/gcc/fortran/openmp.cc
index 5142fd7c608..457e983663b 100644
--- a/gcc/fortran/openmp.cc
+++ b/gcc/fortran/openmp.cc
@@ -7625,10 +7625,6 @@ resolve_omp_clauses (gfc_code *code, gfc_omp_clauses *omp_clauses,
 			linear_op = n->u.linear.op;
 			  }
 		  }
-		else if (omp_clauses->orderedc)
-		  gfc_error ("LINEAR clause specified together with "
- "ORDERED clause with argument at %L",
- >where);
 		else if (n->u.linear.op != OMP_LINEAR_REF
 			 && n->sym->ts.type != BT_INTEGER)
 		  gfc_error ("LINEAR variable %qs must be INTEGER "

Re: [PATCH] Handle > INF and < INF correctly in range-op-float.cc

[Jakub Jelinek via Gcc-patches]

On Tue, Sep 06, 2022 at 09:49:55AM +0200, Aldy Hernandez wrote:
> On Tue, Sep 6, 2022 at 9:44 AM Jakub Jelinek  wrote:
> >
> > On Tue, Sep 06, 2022 at 09:40:59AM +0200, Aldy Hernandez wrote:
> > > if (x <= Inf)
> >
> > This will be [-Inf, Inf] !NAN on the true side and
> > NAN (either sign) on the false side indeed.
> >
> > > if (x < -Inf)
> >
> > will be NAN (either sign) on the true side and
> > [-Inf, Inf] !NAN on the false side.
> 
> Sweet, that's exactly what I thought, thus the patch.
> 
> Furthermore, for !HONOR_NANS I would expect the NAN sides above to be
> UNDEFINED/unreachable.  That is, the false side of x <= Inf when
> !HONOR_NANS is unreachable.

In practice, there is no real format that has NaNs and doesn't have Infs
or vice versa and similarly we have just one switch to cover both Infinities
and NaNs, so either both are supported, or neither of them, or both
are supported but neither of them should appear in a valid program
(-ffinite-math-only on most floating point formats).
So the answer in that case is a little bit fuzzy because one shouldn't
compare against infinity in that case (or for !MODE_HAS_INFINITIES even
can't).  But sure, if NaNs aren't possible or can't appear and you compare
x <= Largest_possible_float, then it is always true and so UNDEFINED on the
false edge.

Jakub

[PATCH] msp430: Mark unused attribute

[Jan-Benedict Glaw]

Hi Nick!

This patch fixes a small warning in the msp430 backend (tested for
--target=msp430-elf and --target=msp430-elfbare).

.../gcc/configure --prefix=... --enable-werror-always --enable-languages=all 
--disable-gcov --disable-shared --disable-threads --target=msp430-elf 
--without-headers
[...]
make V=1 all-gcc
[...]
/usr/lib/gcc-snapshot/bin/g++  -fno-PIE -c   -g -O2   -DIN_GCC  
-DCROSS_DIRECTORY_STRUCTURE   -fno-exceptions -fno-rtti 
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings 
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic 
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common 
 -DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. 
-I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include 
-I../../gcc/gcc/../libcody  -I../../gcc/gcc/../libdecnumber 
-I../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber 
-I../../gcc/gcc/../libbacktrace   -o msp430.o -MT msp430.o -MMD -MP -MF 
./.deps/msp430.TPo ../../gcc/gcc/config/msp430/msp430.cc
../../gcc/gcc/config/msp430/msp430.cc: In function 'int 
msp430_single_op_cost(rtx, bool, rtx)':
../../gcc/gcc/config/msp430/msp430.cc:1463:49: error: unused parameter 
'outer_rtx' [-Werror=unused-parameter]
 1463 | msp430_single_op_cost (rtx dst, bool speed, rtx outer_rtx)
  | ^
cc1plus: all warnings being treated as errors
make[1]: *** [Makefile:2440: msp430.o] Error 1
make[1]: Leaving directory 
'/var/lib/laminar/run/gcc-msp430-elf/1/toolchain-build/gcc'
make: *** [Makefile:4584: all-gcc] Error 2



2022-09-06  Jan-Benedict Glaw  

gcc/ChangeLog:
* config/msp430/msp430.cc (msp430_single_op_cost): Mark unused argument.

diff --git a/gcc/config/msp430/msp430.cc b/gcc/config/msp430/msp430.cc
index 7a378ceac56..2909cabd3ff 100644
--- a/gcc/config/msp430/msp430.cc
+++ b/gcc/config/msp430/msp430.cc
@@ -1460,7 +1460,7 @@ msp430_get_inner_dest_code (rtx x)
 /* Calculate the cost of an MSP430 single-operand instruction, for operand DST
within the RTX OUTER_RTX, optimizing for speed if SPEED is true.  */
 static int
-msp430_single_op_cost (rtx dst, bool speed, rtx outer_rtx)
+msp430_single_op_cost (rtx dst, bool speed, rtx outer_rtx ATTRIBUTE_UNUSED)
 {
   enum rtx_code dst_code = GET_CODE (dst);
   const struct single_op_cost *cost_p;



Okay for HEAD?

Thanks,
  Jan-Benedict

-- 


signature.asc
Description: PGP signature

Re: [PATCH] Handle > INF and < INF correctly in range-op-float.cc

[Aldy Hernandez via Gcc-patches]

On Tue, Sep 6, 2022 at 9:44 AM Jakub Jelinek  wrote:
>
> On Tue, Sep 06, 2022 at 09:40:59AM +0200, Aldy Hernandez wrote:
> > if (x <= Inf)
>
> This will be [-Inf, Inf] !NAN on the true side and
> NAN (either sign) on the false side indeed.
>
> > if (x < -Inf)
>
> will be NAN (either sign) on the true side and
> [-Inf, Inf] !NAN on the false side.

Sweet, that's exactly what I thought, thus the patch.

Furthermore, for !HONOR_NANS I would expect the NAN sides above to be
UNDEFINED/unreachable.  That is, the false side of x <= Inf when
!HONOR_NANS is unreachable.

Agreed?

Aldy

Re: [r13-2446 Regression] FAIL: gfortran.dg/gomp/doacross-5.f90 -O (test for excess errors) on Linux/x86_64

[Jakub Jelinek via Gcc-patches]

On Tue, Sep 06, 2022 at 07:54:05AM +0800, haochen.jiang via Gcc-patches wrote:
> On Linux/x86_64,
> 
> 938cda536019cd6a1bc0dd2346381185b420bbf8 is the first bad commit
> commit 938cda536019cd6a1bc0dd2346381185b420bbf8
> Author: Tobias Burnus 
> Date:   Mon Sep 5 18:05:24 2022 +0200
> 
> Fortran/openmp: Partial OpenMP 5.2 doacross and omp_cur_iteration support
> 
> caused
> 
> FAIL: gfortran.dg/gomp/doacross-5.f90   -O   (test for errors, line 28)
> FAIL: gfortran.dg/gomp/doacross-5.f90   -O   (test for errors, line 42)
> FAIL: gfortran.dg/gomp/doacross-5.f90   -O   (test for errors, line 48)
> FAIL: gfortran.dg/gomp/doacross-5.f90   -O   (test for errors, line 55)
> FAIL: gfortran.dg/gomp/doacross-5.f90   -O   (test for errors, line 70)
> FAIL: gfortran.dg/gomp/doacross-5.f90   -O   (test for errors, line 82)
> FAIL: gfortran.dg/gomp/doacross-5.f90   -O  (test for excess errors)

Seems this is still being diagnosed in the FE when it should be deferred to
the middle-end now (only when we find out if it is doacross or not).

If you really want to diagnose it in the FE (and do the doacross discovery
there too), I think the testcase needs to be split into 2, because the FE
errors apparently result in the gimplifier or omp lowering not being done
at all.

Jakub

Re: [PATCH] Handle > INF and < INF correctly in range-op-float.cc

[Jakub Jelinek via Gcc-patches]

On Tue, Sep 06, 2022 at 09:40:59AM +0200, Aldy Hernandez wrote:
> if (x <= Inf)

This will be [-Inf, Inf] !NAN on the true side and
NAN (either sign) on the false side indeed.

> if (x < -Inf)

will be NAN (either sign) on the true side and
[-Inf, Inf] !NAN on the false side.

Jakub

Re: [PATCH] d: Fix #error You must define PREFERRED_DEBUGGING_TYPE if DWARF is not supported (PR105659)

[Rainer Orth]

Hi Iain,

> Excerpts from Richard Biener's message of September 1, 2022 8:28 am:
>> On Wed, Aug 31, 2022 at 9:21 PM Iain Buclaw  wrote:
>>>
>>> Excerpts from Joseph Myers's message of August 31, 2022 7:16 pm:
>>> > On Wed, 31 Aug 2022, Iain Buclaw via Gcc-patches wrote:
>>> >
>>> >> Excerpts from Joseph Myers's message of August 30, 2022 11:53 pm:
>>> >> > On Fri, 26 Aug 2022, Richard Biener via Gcc-patches wrote:
>>> >> >
>>> >> >> I was hoping Joseph would chime in here - I recollect debugging
>>> >> >> this kind
>>> >> >> of thing and a thread about this a while back but unfortunately I do 
>>> >> >> not
>>> >> >> remember the details here (IIRC some things get included where they
>>> >> >> better should not be).
>>> >> >
>>> >> > See 
>>> >> > .
>>> >> > Is there some reason it's problematic to avoid having defaults.h or
>>> >> > ${cpu_type}/${cpu_type}.h included in tm_d.h, and instead have
>>> >> > tm_d.h only
>>> >> > include D-specific headers?
>>> >> >
>>> >>
>>> >> In targets such as arm-elf, we still need to pull in definitions from
>>> >> ${cpu_type}/${cpu_type}-d.cc into default-d.cc.
>>> >>
>>> >> All I can think that might suffice is having D-specific prototype
>>> >> headers in all targets as ${cpu_type}/${cpu_type}-d.h.
>>> >
>>> > As long as those prototypes don't involve any types that depend on an
>>> > inclusion of tm.h, that should be fine.
>>> >
>>>
>>> Updated patch that does what I described.
>> 
>> Ah yes - I think, even if a bit verbose, this is exactly how it was supposed
>> to be?
>> 
>> OK from my side.
>> 
>
> To access the TARGET macros from arm-d.cc, arm-protos.h had to be
> included (after tm_p.h was removed).
>
> All ~200 configurations in contrib/config-list.mk now build again with
> the D front-end enabled.

unfortunately, this patch broke all Solaris configs
(i386-pc-solaris2.11, sparc-sun-solaris2.11, sparcv9-sun-solaris2.11).
libphobos configure in stage2 fails with

can compile D sources
configure:5402: /var/gcc/regression/master/11.4-gcc/build/./gcc/gdc 
-B/var/gcc/regression/master/11.4-gcc/build/./gcc/ 
-B/vol/gcc/i386-pc-solaris2.11/bin/ -B/vol/gcc/i386-pc-solaris2.11/lib/ 
-isystem /vol/gcc/i386-pc-solaris2.11/include -isystem 
/vol/gcc/i386-pc-solaris2.11/sys-include   -fno-checking -c -fno-druntime 
-nostdinc -I /vol/gcc/src/hg/master/local/libphobos/libdruntime  -g -O2   
conftest.d >&5
core.exception.ArrayIndexError@/vol/gcc/src/hg/master/local/gcc/d/dmd/root/stringtable.d(291):
 index [3530971477] is out of bounds for array of length 0
gcc.deh(505): uncaught exception

I don't yet see why, though.

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: [PATCH] Handle > INF and < INF correctly in range-op-float.cc

[Aldy Hernandez via Gcc-patches]

On Tue, Sep 6, 2022 at 9:35 AM Jakub Jelinek  wrote:
>
> On Tue, Sep 06, 2022 at 09:29:01AM +0200, Aldy Hernandez wrote:
> > The gfortran.dg/minlocval*.f90 tests are generating conditionals past
> > the infinities.  For example:
> >
> >   if (x <= +Inf)
> > foo (x);
> >   else
> > bar (x);
> >
> > It seems to me that the only possible value for x on the false side is
> > either NAN or undefined (for !HONOR_NANS).
>
> No, none of the ==, <, <=, >, >= comparisons are ever true if one
> or both operands are NaN (only != will be true in those cases from the
> standard comparisons, when not counting UNORDERED_EXPR and the likes).
> So, x < -Inf or x > +Inf are always false, we just can't optimize those
> away without -ffast-math because they could raise an exception on sNaN.
> But I think not optimizing such operations away if we care about exceptions
> is the duty of DCE etc.

No, no. I'm not talking about optimizing them away.  I'm talking about
representing what is going on in the IL.

For example, for:

if (x > 5.0)
  foo (x); // {5.0, +Inf] !NAN
else
  bar (x); // [-Inf, 5.0] ?NAN

So on the true side we know x is in the {5.0, +Inf] range, plus we
know it can't be a NAN.  On the false side we know x is either [-Inf,
5.0] or a NAN.

What I'm trying to do is represent the possible ranges for the false side of:

if (x <= Inf)
...

Aldy

Re: [PATCH] Handle > INF and < INF correctly in range-op-float.cc

[Jakub Jelinek via Gcc-patches]

On Tue, Sep 06, 2022 at 09:29:01AM +0200, Aldy Hernandez wrote:
> The gfortran.dg/minlocval*.f90 tests are generating conditionals past
> the infinities.  For example:
> 
>   if (x <= +Inf)
> foo (x);
>   else
> bar (x);
> 
> It seems to me that the only possible value for x on the false side is
> either NAN or undefined (for !HONOR_NANS).

No, none of the ==, <, <=, >, >= comparisons are ever true if one
or both operands are NaN (only != will be true in those cases from the
standard comparisons, when not counting UNORDERED_EXPR and the likes).
So, x < -Inf or x > +Inf are always false, we just can't optimize those
away without -ffast-math because they could raise an exception on sNaN.
But I think not optimizing such operations away if we care about exceptions
is the duty of DCE etc.

Jakub

[committed] openmp: Fix ICE when splitting invalid depend(source)/depend(sink:vec) [PR106836]

[Jakub Jelinek via Gcc-patches]

Hi!

As we now create OMP_CLAUSE_DOACROSS rather than OMP_CLAUSE_DEPEND when
depend is used with source/sink modifiers, c_omp_split_clauses can see
OMP_CLAUSE_DOACROSS clause too before we diagnose it as erroneous.

The following patch treats it like OMP_CLAUSE_DEPEND during
the splitting but adds an assertion.

Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk.

2022-09-06  Jakub Jelinek  

PR c/106836
* c-omp.cc (c_omp_split_clauses): Handle OMP_CLAUSE_DOACROSS.

* c-c++-common/gomp/pr106836.c: New test.

--- gcc/c-family/c-omp.cc.jj2022-09-03 09:41:34.846006111 +0200
+++ gcc/c-family/c-omp.cc   2022-09-05 15:00:00.386360743 +0200
@@ -1877,6 +1877,12 @@ c_omp_split_clauses (location_t loc, enu
case OMP_CLAUSE_DEPEND:
  s = C_OMP_CLAUSE_SPLIT_TARGET;
  break;
+   case OMP_CLAUSE_DOACROSS:
+ /* This can happen with invalid depend(source) or
+depend(sink:vec) on target combined with other constructs.  */
+ gcc_assert (OMP_CLAUSE_DOACROSS_DEPEND (clauses));
+ s = C_OMP_CLAUSE_SPLIT_TARGET;
+ break;
case OMP_CLAUSE_NUM_TEAMS:
  s = C_OMP_CLAUSE_SPLIT_TEAMS;
  break;
--- gcc/testsuite/c-c++-common/gomp/pr106836.c.jj   2022-09-05 
15:09:28.715774353 +0200
+++ gcc/testsuite/c-c++-common/gomp/pr106836.c  2022-09-05 15:08:49.273300853 
+0200
@@ -0,0 +1,9 @@
+/* PR c/106836 */
+
+void
+foo (void)
+{
+#pragma omp target parallel depend (source)/* { dg-error 
"'depend\\\(source\\\)' is only allowed in 'omp ordered'" } */
+  ;
+#pragma omp taskwait
+}

Jakub

[PATCH] Handle > INF and < INF correctly in range-op-float.cc

[Aldy Hernandez via Gcc-patches]

The gfortran.dg/minlocval*.f90 tests are generating conditionals past
the infinities.  For example:

if (x <= +Inf)
  foo (x);
else
  bar (x);

It seems to me that the only possible value for x on the false side is
either NAN or undefined (for !HONOR_NANS).

Is this correct, or is there some other FP nuance I'm unaware of?

gcc/ChangeLog:

* range-op-float.cc (build_lt): Handle < -INF.
(build_gt): Handle > +INF.

gcc/testsuite/ChangeLog:

* gcc.dg/tree-ssa/vrp-float-inf-1.c: New test.
---
 gcc/range-op-float.cc  | 18 ++
 .../gcc.dg/tree-ssa/vrp-float-inf-1.c  | 15 +++
 2 files changed, 33 insertions(+)
 create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/vrp-float-inf-1.c

diff --git a/gcc/range-op-float.cc b/gcc/range-op-float.cc
index 050f07a9867..4515bbf0b7e 100644
--- a/gcc/range-op-float.cc
+++ b/gcc/range-op-float.cc
@@ -235,6 +235,15 @@ build_le (frange , tree type, const REAL_VALUE_TYPE )
 static void
 build_lt (frange , tree type, const REAL_VALUE_TYPE )
 {
+  if (real_isinf (, 1))
+{
+  if (HONOR_NANS (type))
+   frange_set_nan (r, type);
+  else
+   r.set_undefined ();
+  return;
+}
+
   // Hijack LE because we only support closed intervals.
   build_le (r, type, val);
 }
@@ -252,6 +261,15 @@ build_ge (frange , tree type, const REAL_VALUE_TYPE )
 static void
 build_gt (frange , tree type, const REAL_VALUE_TYPE )
 {
+  if (real_isinf (, 0))
+{
+  if (HONOR_NANS (type))
+   frange_set_nan (r, type);
+  else
+   r.set_undefined ();
+  return;
+}
+
   // Hijack GE because we only support closed intervals.
   build_ge (r, type, val);
 }
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/vrp-float-inf-1.c 
b/gcc/testsuite/gcc.dg/tree-ssa/vrp-float-inf-1.c
new file mode 100644
index 000..1d21cce41e6
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/vrp-float-inf-1.c
@@ -0,0 +1,15 @@
+// { dg-do compile }
+// { dg-options "-O2 -fdump-tree-evrp-details" }
+
+void foo ();
+void bar (double);
+
+void funky(double f, double g)
+{
+  if (f <= __builtin_inf ())
+foo ();
+  else
+bar (f);
+}
+
+// { dg-final { scan-tree-dump-not " Inf,  Inf" "evrp" } }
-- 
2.37.1

Re: [COMMITTED] Be even more conservative in intersection of NANs.

[Aldy Hernandez via Gcc-patches]

On Mon, Sep 5, 2022 at 2:16 PM Richard Biener
 wrote:
>
> On Mon, Sep 5, 2022 at 1:45 PM Aldy Hernandez  wrote:
> >
> > On Mon, Sep 5, 2022 at 12:38 PM Richard Biener
> >  wrote:
> > >
> > > On Mon, Sep 5, 2022 at 12:24 PM Aldy Hernandez  wrote:
> > > >
> > > > On Mon, Sep 5, 2022 at 11:53 AM Richard Biener
> > > >  wrote:
> > > > >
> > > > > On Mon, Sep 5, 2022 at 11:41 AM Aldy Hernandez  
> > > > > wrote:
> > > > > >
> > > > > > On Mon, Sep 5, 2022 at 11:18 AM Richard Biener
> > > > > >  wrote:
> > > > > > >
> > > > > > > On Mon, Sep 5, 2022 at 11:12 AM Aldy Hernandez  
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > On Mon, Sep 5, 2022 at 11:06 AM Jakub Jelinek 
> > > > > > > >  wrote:
> > > > > > > > >
> > > > > > > > > On Mon, Sep 05, 2022 at 11:00:54AM +0200, Richard Biener 
> > > > > > > > > wrote:
> > > > > > > > > > On Mon, Sep 5, 2022 at 8:24 AM Aldy Hernandez via 
> > > > > > > > > > Gcc-patches
> > > > > > > > > >  wrote:
> > > > > > > > > > >
> > > > > > > > > > > Intersecting two ranges where one is a NAN is keeping the 
> > > > > > > > > > > sign bit of
> > > > > > > > > > > the NAN range.  This is not correct as the sign bits may 
> > > > > > > > > > > not match.
> > > > > > > > > > >
> > > > > > > > > > > I think the only time we're absolutely sure about the 
> > > > > > > > > > > intersection of
> > > > > > > > > > > a NAN and something else, is when both are a NAN with 
> > > > > > > > > > > exactly the same
> > > > > > > > > > > properties (sign bit).  If we're intersecting two NANs of 
> > > > > > > > > > > differing
> > > > > > > > > > > sign, we can decide later whether that's undefined or 
> > > > > > > > > > > just a NAN with
> > > > > > > > > > > no known sign.  For now I've done the latter.
> > > > > > > > > > >
> > > > > > > > > > > I'm still mentally working on intersections involving 
> > > > > > > > > > > NANs, especially
> > > > > > > > > > > if we want to keep track of signbits.  For now, let's be 
> > > > > > > > > > > extra careful
> > > > > > > > > > > and only do things we're absolutely sure about.
> > > > > > > > > > >
> > > > > > > > > > > Later we may want to fold the intersect of [NAN,NAN] and 
> > > > > > > > > > > say [3,5]
> > > > > > > > > > > with the posibility of NAN, to a NAN, but I'm not 100% 
> > > > > > > > > > > sure.
> > > > > > > > > >
> > > > > > > > > > The intersection of [NAN, NAN] and [3, 5] is empty.  The 
> > > > > > > > > > intersection
> > > > > > > > > > of [NAN, NAN] and VARYING is [NAN, NAN].
> > > > > > > > >
> > > > > > > > > I think [3.0, 5.0] printed that way currently means U maybe 
> > > > > > > > > NAN,
> > > > > > > > > it would be [3.0, 5.0] !NAN if it was known not to be NAN.
> > > > > > > >
> > > > > > > > Right.  I don't print any of the "maybe" properties, just if 
> > > > > > > > they're
> > > > > > > > definitely set or definitely clear.  I'm open to suggestions as 
> > > > > > > > to how
> > > > > > > > to display them.  Perhaps NAN, !NAN, ?NAN.
> > > > > > >
> > > > > > > There's no NAN tristate.  Your "definitely NAN" would be simply
> > > > > > > ][ NAN, that is, the value range only contains NAN.  Your !NAN
> > > > > > > is  and non NAN.  Likewise for the sign, the
> > > > > > > range either includes -NAN and NAN or one or none of those.
> > > > > > > For signed zeros you either have [-0, upper-bound] or [0, 
> > > > > > > upper-bound]
> > > > > > > where it either includes both -0 and 0 or just one of them
> > > > > >
> > > > > > But there is a tristate.  We may definitely have a NAN, definitely 
> > > > > > not
> > > > > > have a NAN, or the state of the NAN is unknown.
> > > > >
> > > > > Sure.  But we are talking about sets of values a variable can have
> > > > > (a value "range" where "range" is a bit misleading for something
> > > > > like a NAN).  The set of possible values either includes
> > > > > NAN (or -NAN and +NAN) or it doesn't include NAN (or -NAN and +NAN).
> > > > > A set cannot include or not include a "maybe NAN".
> > > > >
> > > > > >  Say [3,5] ?NAN.
> > > > > > That's [3,5] with the possibility of a NAN.  On the true side of x 
> > > > > > >=
> > > > > > 5.0, we'd have [5.0, INF] !NAN.  On the false side we'd have [-INF,
> > > > > > 5.0] ?NAN.
> > > > >
> > > > > On the true side of x >= 5.0 the set of values is described by
> > > > > the [5., +INF] range.  On the false side the set is described
> > > > > by the union of the range [-INF, 5.0] and the { -NAN, +NAN }
> > > > > set.
> > > > >
> > > > > There's no may-NAN.  There's also no ?4.0, the range either
> > > > > includes 4.0 or it doesn't.
> > > >
> > > > Ah, ok.  I see where the confusion lies.  You're missing that we don't
> > > > have sub-ranges like we do for irange.  We only have two endpoints and
> > > > a set of flags.  So we can't represent [3,4] U NAN "elegantly".
> > > > However, we can do it with [3,4] ?NAN.  This is by design, but not
> > > > permanent.  I don't have infinite time to work on frange on this cycle
> > > > (I 

[COMMITTED] C-SKY: Fix missing operand when do spilt for cskyv2_addcc and cskyv2_addcc_invert.

[Xianmiao Qu via Gcc-patches]

It will cause ICE when compiling the case:
gcc/testsuite/gcc.dg/params/blocksort-part.c

gcc/
* config/csky/csky.md (cskyv2_addcc): Fix missing operand.
(cskyv2_addcc_invert): Likewise.
---
 gcc/config/csky/csky.md | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/gcc/config/csky/csky.md b/gcc/config/csky/csky.md
index 6b05930a9fb..6a6592902ef 100644
--- a/gcc/config/csky/csky.md
+++ b/gcc/config/csky/csky.md
@@ -1279,7 +1279,8 @@
   "reload_completed && !rtx_equal_p (operands[0], operands[1])"
   [(set (match_dup 0)
(if_then_else:SI (ne (reg:CC CSKY_CC_REGNUM) (const_int 0))
-(plus:SI (match_dup 0) (match_dup 2]
+(plus:SI (match_dup 0) (match_dup 2))
+(match_dup 0)))]
   {
 emit_insn (gen_movf (copy_rtx (operands[0]),
 copy_rtx (operands[1]),
@@ -1305,7 +1306,8 @@
   "reload_completed && !rtx_equal_p (operands[0], operands[1])"
   [(set (match_dup 0)
(if_then_else:SI (eq (reg:CC CSKY_CC_REGNUM) (const_int 0))
-(plus:SI (match_dup 0) (match_dup 2]
+(plus:SI (match_dup 0) (match_dup 2))
+(match_dup 0)))]
   {
 emit_insn (gen_movt (copy_rtx (operands[0]),
 copy_rtx (operands[1]),
-- 
2.17.1

[Ada] Fix internal error on double renaming of private constant

[Marc Poulhiès via Gcc-patches]

The first renaming uses the type of the full view of the constant but not
the second, which introduces problematic view conversions downstream.

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* gcc-interface/trans.cc (Full_View_Of_Private_Constant): New
function returning the Full_View of a private constant, after
looking through a chain of renamings, if any.
(Identifier_to_gnu): Call it on the entity.  Small cleanup.diff --git a/gcc/ada/gcc-interface/trans.cc b/gcc/ada/gcc-interface/trans.cc
--- a/gcc/ada/gcc-interface/trans.cc
+++ b/gcc/ada/gcc-interface/trans.cc
@@ -1088,6 +1088,28 @@ Gigi_Types_Compatible (Entity_Id type, Entity_Id def_type)
   return false;
 }
 
+/* Return the full view of a private constant E, or of a renaming thereof, if
+   its type has discriminants, and Empty otherwise.  */
+
+static Entity_Id
+Full_View_Of_Private_Constant (Entity_Id E)
+{
+  while (Present (Renamed_Object (E)) && Is_Entity_Name (Renamed_Object (E)))
+E = Entity (Renamed_Object (E));
+
+  if (Ekind (E) != E_Constant || No (Full_View (E)))
+return Empty;
+
+  const Entity_Id T = Etype (E);
+
+  if (Is_Private_Type (T)
+  && (Has_Unknown_Discriminants (T)
+	  || (Present (Full_View (T)) && Has_Discriminants (Full_View (T)
+return Full_View (E);
+
+  return Empty;
+}
+
 /* Subroutine of gnat_to_gnu to translate GNAT_NODE, an N_Identifier, to a GCC
tree, which is returned.  GNU_RESULT_TYPE_P is a pointer to where we should
place the result type.  */
@@ -1095,21 +1117,19 @@ Gigi_Types_Compatible (Entity_Id type, Entity_Id def_type)
 static tree
 Identifier_to_gnu (Node_Id gnat_node, tree *gnu_result_type_p)
 {
-  /* The entity of GNAT_NODE and its type.  */
-  Node_Id gnat_entity = (Nkind (gnat_node) == N_Defining_Identifier
-			 || Nkind (gnat_node) == N_Defining_Operator_Symbol)
-			? gnat_node : Entity (gnat_node);
-  Node_Id gnat_entity_type = Etype (gnat_entity);
+  Entity_Id gnat_entity = (Nkind (gnat_node) == N_Defining_Identifier
+			   || Nkind (gnat_node) == N_Defining_Operator_Symbol)
+			  ? gnat_node : Entity (gnat_node);
+  Entity_Id gnat_result_type;
+  tree gnu_result, gnu_result_type;
   /* If GNAT_NODE is a constant, whether we should use the initialization
  value instead of the constant entity, typically for scalars with an
  address clause when the parent doesn't require an lvalue.  */
-  bool use_constant_initializer = false;
+  bool use_constant_initializer;
   /* Whether we should require an lvalue for GNAT_NODE.  Needed in
  specific circumstances only, so evaluated lazily.  < 0 means
  unknown, > 0 means known true, 0 means known false.  */
-  int require_lvalue = -1;
-  Entity_Id gnat_result_type;
-  tree gnu_result, gnu_result_type;
+  int require_lvalue;
 
   /* If the Etype of this node is not the same as that of the Entity, then
  something went wrong, probably in generic instantiation.  However, this
@@ -1118,25 +1138,17 @@ Identifier_to_gnu (Node_Id gnat_node, tree *gnu_result_type_p)
  may have been changed to a subtype by Exp_Ch3.Adjust_Discriminants.  */
   gcc_assert (!Is_Object (gnat_entity)
 	  || Ekind (gnat_entity) == E_Discriminant
-	  || Etype (gnat_node) == gnat_entity_type
-	  || Gigi_Types_Compatible (Etype (gnat_node), gnat_entity_type));
+	  || Etype (gnat_node) == Etype (gnat_entity)
+	  || Gigi_Types_Compatible (Etype (gnat_node),
+	Etype (gnat_entity)));
 
-  /* If this is a reference to a deferred constant whose partial view is an
+  /* If this is a reference to a deferred constant whose partial view is of
  unconstrained private type, the proper type is on the full view of the
- constant, not on the full view of the type, which may be unconstrained.
-
- This may be a reference to a type, for example in the prefix of the
- attribute Position, generated for dispatching code (see Make_DT in
- exp_disp,adb). In that case we need the type itself, not is parent,
- in particular if it is a derived type  */
-  if (Ekind (gnat_entity) == E_Constant
-  && Is_Private_Type (gnat_entity_type)
-  && (Has_Unknown_Discriminants (gnat_entity_type)
-	  || (Present (Full_View (gnat_entity_type))
- 	  && Has_Discriminants (Full_View (gnat_entity_type
-  && Present (Full_View (gnat_entity)))
+ constant, not on the full view of the type which may be unconstrained.  */
+  const Entity_Id gnat_full_view = Full_View_Of_Private_Constant (gnat_entity);
+  if (Present (gnat_full_view))
 {
-  gnat_entity = Full_View (gnat_entity);
+  gnat_entity = gnat_full_view;
   gnat_result_type = Etype (gnat_entity);
 }
   else
@@ -1184,7 +1196,13 @@ Identifier_to_gnu (Node_Id gnat_node, tree *gnu_result_type_p)
 	= lvalue_required_p (gnat_node, gnu_result_type, true, false);
   use_constant_initializer = !require_lvalue;
 }
+  else
+{
+  require_lvalue = -1;
+  use_constant_initializer = false;
+  

[Ada] Fix problematic line debug info attached to call to finalizer

[Marc Poulhiès via Gcc-patches]

The End_Label is not defined for body nodes so a small tweak is needed.

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* gcc-interface/trans.cc (At_End_Proc_to_gnu): Use the End_Label of
the child Handled_Statement_Sequence for body nodes.
(set_end_locus_from_node): Minor tweaks.diff --git a/gcc/ada/gcc-interface/trans.cc b/gcc/ada/gcc-interface/trans.cc
--- a/gcc/ada/gcc-interface/trans.cc
+++ b/gcc/ada/gcc-interface/trans.cc
@@ -3806,18 +3806,27 @@ static void
 At_End_Proc_to_gnu (Node_Id gnat_node)
 {
   tree proc_decl = gnat_to_gnu (At_End_Proc (gnat_node));
+  Node_Id gnat_end_label;
 
   /* When not optimizing, disable inlining of finalizers as this can
  create a more complex CFG in the parent function.  */
   if (!optimize || optimize_debug)
 DECL_DECLARED_INLINE_P (proc_decl) = 0;
 
+  /* Retrieve the end label attached to the node, if any.  */
+  if (Nkind (gnat_node) == N_Handled_Sequence_Of_Statements)
+gnat_end_label = End_Label (gnat_node);
+  else if (Present (Handled_Statement_Sequence (gnat_node)))
+gnat_end_label = End_Label (Handled_Statement_Sequence (gnat_node));
+  else
+gnat_end_label = Empty;
+
   /* If there is no end label attached, we use the location of the At_End
  procedure because Expand_Cleanup_Actions might reset the location of
-  the enclosing construct to that of an inner statement.  */
+ the enclosing construct to that of an inner statement.  */
   add_cleanup (build_call_n_expr (proc_decl, 0),
-	   Present (End_Label (gnat_node))
-	   ? End_Label (gnat_node) : At_End_Proc (gnat_node));
+	   Present (gnat_end_label)
+	   ? gnat_end_label : At_End_Proc (gnat_node));
 }
 
 /* Subroutine of gnat_to_gnu to translate GNAT_NODE, an N_Subprogram_Body.  */
@@ -10418,7 +10427,6 @@ set_end_locus_from_node (tree gnu_node, Node_Id gnat_node)
 	gnat_end_label = End_Label (Handled_Statement_Sequence (gnat_node));
   else
 	gnat_end_label = Empty;
-
   break;
 
 case N_Package_Declaration:
@@ -10439,7 +10447,7 @@ set_end_locus_from_node (tree gnu_node, Node_Id gnat_node)
  transient block does not receive the sloc of a source condition.  */
   if (!Sloc_to_locus (Sloc (gnat_node), _locus,
   No (gnat_end_label)
-  && (Nkind (gnat_node) == N_Block_Statement)))
+  && Nkind (gnat_node) == N_Block_Statement))
 return false;
 
   switch (TREE_CODE (gnu_node))

[Ada] Fix missing name for access type in generic instantiation

[Marc Poulhiès via Gcc-patches]

Pointer types aren't named types in C so we need to take extra care in Ada
to make sure that the name of access types is preserved.

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* gcc-interface/utils.cc (gnat_pushdecl): Preserve named
TYPE_DECLs consistently for all kind of pointer types.diff --git a/gcc/ada/gcc-interface/utils.cc b/gcc/ada/gcc-interface/utils.cc
--- a/gcc/ada/gcc-interface/utils.cc
+++ b/gcc/ada/gcc-interface/utils.cc
@@ -868,6 +868,13 @@ gnat_pushdecl (tree decl, Node_Id gnat_node)
 	}
 }
 
+/* Pointer types aren't named types in the C sense so we need to generate a
+   typedef in DWARF for them.  Also do that for fat pointer types because,
+   even though they are named types in the C sense, they are still the XUP
+   types created for the base array type at this point.  */
+#define TYPE_IS_POINTER_P(NODE) \
+  (TREE_CODE (NODE) == POINTER_TYPE || TYPE_IS_FAT_POINTER_P (NODE))
+
   /* For the declaration of a type, set its name either if it isn't already
  set or if the previous type name was not derived from a source name.
  We'd rather have the type named with a real name and all the pointer
@@ -877,18 +884,14 @@ gnat_pushdecl (tree decl, Node_Id gnat_node)
 {
   tree t = TREE_TYPE (decl);
 
-  /* Pointer types aren't named types in the C sense so we need to generate
- a typedef in DWARF for them and make sure it is preserved, unless the
- type is artificial.  */
+  /* For pointer types, make sure the typedef is generated and preserved
+	 in DWARF, unless the type is artificial.  */
   if (!(TYPE_NAME (t) && TREE_CODE (TYPE_NAME (t)) == TYPE_DECL)
-	  && (TREE_CODE (t) != POINTER_TYPE || DECL_ARTIFICIAL (decl)))
+	  && (!TYPE_IS_POINTER_P (t) || DECL_ARTIFICIAL (decl)))
 	;
   /* For pointer types, create the DECL_ORIGINAL_TYPE that will generate
-	 the typedef in DWARF.  Also do that for fat pointer types because,
-	 even though they are named types in the C sense, they are still the
-	 XUP types created for the base array type at this point.  */
-  else if (!DECL_ARTIFICIAL (decl)
-	   && (TREE_CODE (t) == POINTER_TYPE || TYPE_IS_FAT_POINTER_P (t)))
+	 the typedef in DWARF.  */
+  else if (TYPE_IS_POINTER_P (t) && !DECL_ARTIFICIAL (decl))
 	{
 	  tree tt = build_variant_type_copy (t);
 	  TYPE_NAME (tt) = decl;
@@ -920,9 +923,8 @@ gnat_pushdecl (tree decl, Node_Id gnat_node)
 	 to all parallel types too thanks to gnat_set_type_context.  */
   if (t)
 	for (t = TYPE_MAIN_VARIANT (t); t; t = TYPE_NEXT_VARIANT (t))
-	  /* ??? Because of the previous kludge, we can have variants of fat
-	 pointer types with different names.  */
-	  if (!(TYPE_IS_FAT_POINTER_P (t)
+	  /* Skip it for pointer types to preserve the typedef.  */
+	  if (!(TYPE_IS_POINTER_P (t)
 		&& TYPE_NAME (t)
 		&& TREE_CODE (TYPE_NAME (t)) == TYPE_DECL))
 	{
@@ -932,6 +934,8 @@ gnat_pushdecl (tree decl, Node_Id gnat_node)
 	 deferred_decl_context);
 	}
 }
+
+#undef TYPE_IS_POINTER_P
 }
 
 /* Create a record type that contains a SIZE bytes long field of TYPE with a

[Ada] Retain Has_Private_View flag for actuals of inlined subprograms

[Marc Poulhiès via Gcc-patches]

When instantiating a body to inline (either because frontend inlining is
enabled with switch -gnatN or because of inlining-for-proof in GNATprove
mode) we rewrite occurrences of formal parameters into the corresponding
actual parameters. Then we switch type views, so that if the formal had
a full view in the body to inline then the corresponding actual will
have a full view in the particular inlined body.

However, when rewriting occurrences of the formal parameter we were
losing information about whether the formal had a private view.

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* inline.adb (Process_Formals): Preserve Has_Private_View flag while
rewriting formal into actual parameters.diff --git a/gcc/ada/inline.adb b/gcc/ada/inline.adb
--- a/gcc/ada/inline.adb
+++ b/gcc/ada/inline.adb
@@ -3367,6 +3367,8 @@ package body Inline is
  E   : Entity_Id;
  Ret : Node_Id;
 
+ Had_Private_View : Boolean;
+
   begin
  if Is_Entity_Name (N) and then Present (Entity (N)) then
 E := Entity (N);
@@ -3380,13 +3382,21 @@ package body Inline is
--  subtype is private at the call point but its full view is
--  visible to the body, then the inlined tree here must be
--  analyzed with the full view).
+   --
+   --  The Has_Private_View flag is cleared by rewriting, so it
+   --  must be explicitly saved and restored, just like when
+   --  instantiating the body to inline.
 
if Is_Entity_Name (A) then
+  Had_Private_View := Has_Private_View (N);
   Rewrite (N, New_Occurrence_Of (Entity (A), Sloc (N)));
+  Set_Has_Private_View (N, Had_Private_View);
   Check_Private_View (N);
 
elsif Nkind (A) = N_Defining_Identifier then
+  Had_Private_View := Has_Private_View (N);
   Rewrite (N, New_Occurrence_Of (A, Sloc (N)));
+  Set_Has_Private_View (N, Had_Private_View);
   Check_Private_View (N);
 
--  Numeric literal

[Ada] Enable lock free protected implementation by default

[Marc Poulhiès via Gcc-patches]

In the past, the Lock_Free aspect of a protected type (including an
anonymous type) defaulted to False. In the case where an explicit
"Lock_Free => True" aspect specification would be legal, the aspect now
defaults to True (which means that a lock-free implementation is used to
implement the type's protected operations); this is like the previous
behavior of the compiler with the -gnatd9 switch specified. Support for
the Lock_Free attribute (which should not be confused with the Lock_Free
aspect) is removed.

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* debug.adb: Remove comment regarding the -gnatd9 switch.
* doc/gnat_rm/implementation_defined_attributes.rst: Remove all
mention of the Lock_Free attribute.
* gnat_rm.texi, gnat_ugn.texi: Regenerate.
* exp_attr.adb, sem_attr.adb: Remove all mention of the former
Attribute_Lock_Free enumeration element of the Attribute_Id type.
* sem_ch9.adb
(Allows_Lock_Free_Implementation): Remove the Debug_Flag_9 test.
Return False in the case of a protected function whose result type
requires use of the secondary stack.
(Satisfies_Lock_Free_Requirements): This functions checks for
certain constructs and returns False if one is found. In the case
of a protected function, there is no need to check to see if the
protected object is being modified. So it is ok to omit *some*
checks in the case of a protected function. But other checks which
are required (e.g., the test for a reference to a variable that is
not part of the protected object) were being incorrectly omitted.
This could result in accepting "Lock_Free => True" aspect
specifications that should be rejected.
* snames.adb-tmpl: Name_Lock_Free no longer requires special
treatment in Get_Pragma_Id or Is_Pragma_Name (because it is no
longer an attribute name).
* snames.ads-tmpl: Move the declaration of Name_Lock_Free to
reflect the fact that it is no longer the name of an attribute.
Delete Attribute_Lock_Free from the Attribute_Id enumeration type.

patch.diff.gz
Description: application/gzip

[Ada] Improve documentation of validation checking control switches

[Marc Poulhiès via Gcc-patches]

Correct incorrect text and clarify unclear text that has been identified
in the "Validity Checking" section of the GNAT UG.

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* doc/gnat_ugn/building_executable_programs_with_gnat.rst:
Improve -gnatVa, -gnatVc, -gnatVd, -gnatVe, -gnatVf, -gnatVo,
-gnatVp, -gnatVr, and -gnatVs switch descriptions.
* gnat_ugn.texi: Regenerate.diff --git a/gcc/ada/doc/gnat_ugn/building_executable_programs_with_gnat.rst b/gcc/ada/doc/gnat_ugn/building_executable_programs_with_gnat.rst
--- a/gcc/ada/doc/gnat_ugn/building_executable_programs_with_gnat.rst
+++ b/gcc/ada/doc/gnat_ugn/building_executable_programs_with_gnat.rst
@@ -4455,7 +4455,7 @@ to the default checks required by Ada as described above.
 
   All validity checks are turned on.
   That is, :switch:`-gnatVa` is
-  equivalent to ``gnatVcdfimoprst``.
+  equivalent to ``gnatVcdefimoprst``.
 
 
 .. index:: -gnatVc  (gcc)
@@ -4463,8 +4463,8 @@ to the default checks required by Ada as described above.
 :switch:`-gnatVc`
   *Validity checks for copies.*
 
-  The right hand side of assignments, and the initializing values of
-  object declarations are validity checked.
+  The right-hand side of assignments, and the (explicit) initializing values
+  of object declarations are validity checked.
 
 
 .. index:: -gnatVd  (gcc)
@@ -4472,12 +4472,14 @@ to the default checks required by Ada as described above.
 :switch:`-gnatVd`
   *Default (RM) validity checks.*
 
-  Some validity checks are done by default following normal Ada semantics
-  (RM 13.9.1 (9-11)).
-  A check is done in case statements that the expression is within the range
-  of the subtype. If it is not, Constraint_Error is raised.
-  For assignments to array components, a check is done that the expression used
-  as index is within the range. If it is not, Constraint_Error is raised.
+  Some validity checks are required by Ada (see RM 13.9.1 (9-11)); these
+  (and only these) validity checks are enabled by default.
+  For case statements (and case expressions) that lack a "when others =>"
+  choice, a check is made that the value of the selector expression
+  belongs to its nominal subtype. If it does not, Constraint_Error is raised.
+  For assignments to array components (and for indexed components in some
+  other contexts), a check is made that each index expression belongs to the
+  corresponding index subtype. If it does not, Constraint_Error is raised.
   Both these validity checks may be turned off using switch :switch:`-gnatVD`.
   They are turned on by default. If :switch:`-gnatVD` is specified, a subsequent
   switch :switch:`-gnatVd` will leave the checks turned on.
@@ -4490,28 +4492,31 @@ to the default checks required by Ada as described above.
 .. index:: -gnatVe  (gcc)
 
 :switch:`-gnatVe`
-  *Validity checks for elementary components.*
-
-  In the absence of this switch, assignments to record or array components are
-  not validity checked, even if validity checks for assignments generally
-  (:switch:`-gnatVc`) are turned on. In Ada, assignment of composite values do not
-  require valid data, but assignment of individual components does. So for
-  example, there is a difference between copying the elements of an array with a
-  slice assignment, compared to assigning element by element in a loop. This
-  switch allows you to turn off validity checking for components, even when they
-  are assigned component by component.
+  *Validity checks for scalar components.*
 
+  In the absence of this switch, assignments to scalar components of
+  enclosing record or array objects are not validity checked, even if
+  validity checks for assignments generally (:switch:`-gnatVc`) are turned on.
+  Specifying this switch enables such checks.
+  This switch has no effect if the :switch:`-gnatVc` switch is not specified.
 
 .. index:: -gnatVf  (gcc)
 
 :switch:`-gnatVf`
   *Validity checks for floating-point values.*
 
-  In the absence of this switch, validity checking occurs only for discrete
-  values. If :switch:`-gnatVf` is specified, then validity checking also applies
+  Specifying this switch enables validity checking for floating-point
+  values in the same contexts where validity checking is enabled for
+  other scalar values.
+  In the absence of this switch, validity checking is not performed for
+  floating-point values. This takes precedence over other statements about
+  performing validity checking for scalar objects in various scenarios.
+  One way to look at it is that if this switch is not set, then whenever
+  any of the other rules in this section use the word "scalar" they
+  really mean "scalar and not floating-point".
+  If :switch:`-gnatVf` is specified, then validity checking also applies
   for floating-point values, and NaNs and infinities are considered invalid,
-  as well as out of range values for constrained types. Note that this means
-  that standard IEEE infinity mode is not allowed. 

[Ada] Disable lock free protected implementation if target lacks support

[Marc Poulhiès via Gcc-patches]

Do not select a lock free implementation if Targparm.Support_Atomic_Primitives
is False (which indicates that the target cannot support it).

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* sem_ch9.adb
(Allows_Lock_Free_Implementation): Return False if
Support_Atomic_Primitives is False.diff --git a/gcc/ada/sem_ch9.adb b/gcc/ada/sem_ch9.adb
--- a/gcc/ada/sem_ch9.adb
+++ b/gcc/ada/sem_ch9.adb
@@ -64,6 +64,7 @@ with Sinfo;  use Sinfo;
 with Sinfo.Nodes;use Sinfo.Nodes;
 with Sinfo.Utils;use Sinfo.Utils;
 with Style;
+with Targparm;   use Targparm;
 with Tbuild; use Tbuild;
 with Uintp;  use Uintp;
 
@@ -649,6 +650,10 @@ package body Sem_Ch9 is
 --  Start of processing for Satisfies_Lock_Free_Requirements
 
 begin
+   if not Support_Atomic_Primitives_On_Target then
+  return False;
+   end if;
+
--  Get the number of errors detected by the compiler so far
 
if Lock_Free_Given then

[Ada] Restore missing Aggregate aspect for Ada.Containers.Ordered_Sets.Set

[Marc Poulhiès via Gcc-patches]

Ada RM A.18.9 includes a specification of the Aggregate aspect for the type
Ada.Containers.Ordered_Sets. That aspect specification was deliberately
commented out in a-coorse.ads at one time, but that workaround is no longer
needed.

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* libgnat/a-coorse.ads: Restore Aggregate aspect specification for
type Set.diff --git a/gcc/ada/libgnat/a-coorse.ads b/gcc/ada/libgnat/a-coorse.ads
--- a/gcc/ada/libgnat/a-coorse.ads
+++ b/gcc/ada/libgnat/a-coorse.ads
@@ -57,9 +57,9 @@ is
type Set is tagged private
with Constant_Indexing => Constant_Reference,
 Default_Iterator  => Iterate,
-Iterator_Element  => Element_Type;
---  Aggregate => (Empty   => Empty,
---Add_Unnamed => Include);
+Iterator_Element  => Element_Type,
+Aggregate => (Empty   => Empty,
+  Add_Unnamed => Include);
 
pragma Preelaborable_Initialization (Set);
 

[Ada] Handle new At_End expansion during unnesting

[Marc Poulhiès via Gcc-patches]

This patch modifies the marking of nested subprograms requiring static links,
so that the changes made to "At end" procedures get handled properly.

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* exp_unst.adb
(Visit_Node): Add N_Block_Statement to the enclosing construct
case since they can now have "At end" procedures. Also, recognize
calls from "At end" procedures when recording subprograms.diff --git a/gcc/ada/exp_unst.adb b/gcc/ada/exp_unst.adb
--- a/gcc/ada/exp_unst.adb
+++ b/gcc/ada/exp_unst.adb
@@ -938,7 +938,7 @@ package body Exp_Unst is
--  subprogram. As above, the called entity must be local and
--  not imported.
 
-   when N_Handled_Sequence_Of_Statements =>
+   when N_Handled_Sequence_Of_Statements | N_Block_Statement =>
   if Present (At_End_Proc (N))
 and then Scope_Within (Entity (At_End_Proc (N)), Subp)
 and then not Is_Imported (Entity (At_End_Proc (N)))
@@ -1184,6 +1184,15 @@ package body Exp_Unst is
 
   Register_Subprogram (Ent, N);
 
+  --  Record a call from an At_End_Proc
+
+  if Present (At_End_Proc (N))
+and then Scope_Within (Entity (At_End_Proc (N)), Subp)
+and then not Is_Imported (Entity (At_End_Proc (N)))
+  then
+ Append_Unique_Call ((N, Ent, Entity (At_End_Proc (N;
+  end if;
+
   --  We make a recursive call to scan the subprogram body, so
   --  that we can save and restore Current_Subprogram.
 

[Ada] Fix formal parameters list for secondary stack allocation procedure

[Marc Poulhiès via Gcc-patches]

The introduction of the Alignment parameter for the secondary stack
allocator in previous change was missing the corresponding change in the
Build_Allocate_Deallocate_Proc when creating the formal parameters list.

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* exp_util.adb (Build_Allocate_Deallocate_Proc): Add
Alignment_Param in the formal list for calls to SS_Allocate.diff --git a/gcc/ada/exp_util.adb b/gcc/ada/exp_util.adb
--- a/gcc/ada/exp_util.adb
+++ b/gcc/ada/exp_util.adb
@@ -1293,7 +1293,8 @@ package body Exp_Util is
--  Gigi expects a different profile in the Secondary_Stack_Pool
--  case. There must be no uses of the two missing formals
--  (i.e., Pool_Param and Alignment_Param) in this case.
-   Formal_Params := New_List (Address_Param, Size_Param);
+   Formal_Params := New_List
+ (Address_Param, Size_Param, Alignment_Param);
 else
Formal_Params := New_List (
  Pool_Param, Address_Param, Size_Param, Alignment_Param);

[Ada] Enforce matching of extra formals

[Marc Poulhiès via Gcc-patches]

This patch enforces matching of extra formals in overridden subprograms,
subprogram renamings, and subprograms to which attributes 'Access,
'Unchecked_Access, or 'Unrestricted_Access is applied (for these access
cases the subprogram is checked against its corresponding subprogram
type).

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* debug.adb
(Debug_Flag_Underscore_X): Switch added temporarily to allow
disabling extra formal checks.

* exp_attr.adb
(Expand_N_Attribute_Reference [access types]): Add extra formals
to the subprogram referenced in the prefix of 'Unchecked_Access,
'Unrestricted_Access or 'Access; required to check that its extra
formals match the extra formals of the corresponding subprogram
type.

* exp_ch3.adb
(Stream_Operation_OK): Declaration moved to the public part of the
package.
(Validate_Tagged_Type_Extra_Formals): New subprogram.
(Expand_Freeze_Record_Type): Improve the code that takes care of
adding the extra formals of dispatching primitives; extended to
add also the extra formals to renamings of dispatching primitives.

* exp_ch3.ads
(Stream_Operation_OK): Declaration moved from the package body.

* exp_ch6.adb
(Has_BIP_Extra_Formal): Subprogram declaration moved to the public
part of the package. In addition, a parameter has been added to
disable an assertion that requires its use with frozen entities.
(Expand_Call_Helper): Enforce assertion checking extra formals on
thunks.
(Is_Build_In_Place_Function): Return False for entities with
foreign convention.
(Make_Build_In_Place_Call_In_Object_Declaration): Occurrences of
Is_Return_Object replaced by the local variable
Is_OK_Return_Object that evaluates to False for scopes with
foreign convention.
(Might_Have_Tasks): Fix check of class-wide limited record types.
(Needs_BIP_Task_Actuals): Remove assertion to allow calling this
function in more contexts; in addition it returns False for
functions returning objects with foreign convention.
(Needs_BIP_Finalization_Master): Likewise.
(Needs_BIP_Alloc_Form): Likewise.

* exp_ch6.ads
(Stream_Operation_OK): Declaration moved from the package body. In
addition, a parameter has been added to disable assertion that
requires its use with frozen entities.

* freeze.adb
(Check_Itype): Add extra formals to anonymous access subprogram
itypes.
(Freeze_Expression): Improve code that disables the addition of
extra formals to functions with foreign convention.
(Check_Extra_Formals): Moved to package Sem_Ch6 as
Extra_Formals_OK.
(Freeze_Subprogram): Add extra formals to non-dispatching
subprograms.

* sem_ch3.adb
(Access_Subprogram_Declaration): Defer the addition of extra
formals to the freezing point so that we know the convention.
(Check_Anonymous_Access_Component): Likewise.
(Derive_Subprogram): Fix documentation.

* sem_ch6.adb
(Check_Anonymous_Return): Fix check of access to class-wide
limited record types.
(Check_Untagged_Equality): Placed in alphabetical order.
(Extra_Formals_OK): Subprogram moved from freeze.adb.
(Extra_Formals_Match_OK): New subprogram.
(Has_BIP_Formals): New subprogram.
(Has_Extra_Formals): New subprograms.
(Needs_Accessibility_Check_Extra): New subprogram.
(Needs_Constrained_Extra): New subprogram.
(Parent_Subprogram): New subprogram.
(Add_Extra_Formal): Minor code cleanup.
(Create_Extra_Formals): Enforce matching extra formals on
overridden and aliased entities.
(Has_Reliable_Extra_Formals): New subprogram.

* sem_ch6.ads
(Extra_Formals_OK): Subprogram moved from freeze.adb.
(Extra_Formals_Match_OK): New subprogram.

* sem_eval.adb
(Compile_Time_Known_Value): Improve predicate to avoid assertion
failure; found working on this ticket; this change does not affect
the behavior of the compiler because this subprogram has an
exception handler that returns False when the assertion fails.

* sem_util.adb
(Needs_Result_Accessibility_Level): Do not return False for
dispatching operations compiled with Ada_Version < 2012 since they
they may be overridden by primitives compiled with Ada_Version >=
Ada_2012.

patch.diff.gz
Description: application/gzip

[Ada] Cleanup unnecessary shadowing in expansion of attribute Old

[Marc Poulhiès via Gcc-patches]

Code cleanup; semantics is unaffected.

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* exp_attr.adb (Expand_N_Attribute_Reference [Attribute_Old]):
Remove unnecessary local constant that was shadowing another
constant with the same initial value.diff --git a/gcc/ada/exp_attr.adb b/gcc/ada/exp_attr.adb
--- a/gcc/ada/exp_attr.adb
+++ b/gcc/ada/exp_attr.adb
@@ -4884,7 +4884,6 @@ package body Exp_Attr is
   -
 
   when Attribute_Old => Old : declare
- Typ : constant Entity_Id := Etype (N);
  CW_Temp : Entity_Id;
  CW_Typ  : Entity_Id;
  Decl: Node_Id;

[Ada] Slice length computation bug in Generic_Bounded_Length generics

[Marc Poulhiès via Gcc-patches]

In some cases involving null slices, the Slice subprograms (both the
  function and the procedure) in each of the three Generic_Bounded_Length
  generic packages (for String, Wide_String, and Wide_Wide_String)
  could raise Constraint_Error in cases where this is incorrect.

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* libgnat/a-strsup.adb, libgnat/a-stwisu.adb, libgnat/a-stzsup.adb
(Super_Slice function and procedure): fix slice length computation.diff --git a/gcc/ada/libgnat/a-strsup.adb b/gcc/ada/libgnat/a-strsup.adb
--- a/gcc/ada/libgnat/a-strsup.adb
+++ b/gcc/ada/libgnat/a-strsup.adb
@@ -1651,10 +1651,9 @@ package body Ada.Strings.Superbounded with SPARK_Mode is
 raise Index_Error;
  end if;
 
- if High >= Low then
-Result.Data (1 .. High - Low + 1) := Source.Data (Low .. High);
-Result.Current_Length := High - Low + 1;
- end if;
+ Result.Current_Length := (if Low > High then 0 else High - Low + 1);
+ Result.Data (1 .. Result.Current_Length) :=
+   Source.Data (Low .. High);
   end return;
end Super_Slice;
 
@@ -1671,12 +1670,8 @@ package body Ada.Strings.Superbounded with SPARK_Mode is
  raise Index_Error;
   end if;
 
-  if High >= Low then
- Target.Data (1 .. High - Low + 1) := Source.Data (Low .. High);
- Target.Current_Length := High - Low + 1;
-  else
- Target.Current_Length := 0;
-  end if;
+  Target.Current_Length := (if Low > High then 0 else High - Low + 1);
+  Target.Data (1 .. Target.Current_Length) := Source.Data (Low .. High);
end Super_Slice;
 



diff --git a/gcc/ada/libgnat/a-stwisu.adb b/gcc/ada/libgnat/a-stwisu.adb
--- a/gcc/ada/libgnat/a-stwisu.adb
+++ b/gcc/ada/libgnat/a-stwisu.adb
@@ -1497,7 +1497,7 @@ package body Ada.Strings.Wide_Superbounded is
 raise Index_Error;
  end if;
 
- Result.Current_Length := High - Low + 1;
+ Result.Current_Length := (if Low > High then 0 else High - Low + 1);
  Result.Data (1 .. Result.Current_Length) := Source.Data (Low .. High);
   end return;
end Super_Slice;
@@ -1513,10 +1513,10 @@ package body Ada.Strings.Wide_Superbounded is
 or else High > Source.Current_Length
   then
  raise Index_Error;
-  else
- Target.Current_Length := High - Low + 1;
- Target.Data (1 .. Target.Current_Length) := Source.Data (Low .. High);
   end if;
+
+  Target.Current_Length := (if Low > High then 0 else High - Low + 1);
+  Target.Data (1 .. Target.Current_Length) := Source.Data (Low .. High);
end Super_Slice;
 



diff --git a/gcc/ada/libgnat/a-stzsup.adb b/gcc/ada/libgnat/a-stzsup.adb
--- a/gcc/ada/libgnat/a-stzsup.adb
+++ b/gcc/ada/libgnat/a-stzsup.adb
@@ -1498,11 +1498,11 @@ package body Ada.Strings.Wide_Wide_Superbounded is
or else High > Source.Current_Length
  then
 raise Index_Error;
- else
-Result.Current_Length := High - Low + 1;
-Result.Data (1 .. Result.Current_Length) :=
-  Source.Data (Low .. High);
  end if;
+
+ Result.Current_Length := (if Low > High then 0 else High - Low + 1);
+ Result.Data (1 .. Result.Current_Length) :=
+   Source.Data (Low .. High);
   end return;
end Super_Slice;
 
@@ -1517,10 +1517,10 @@ package body Ada.Strings.Wide_Wide_Superbounded is
 or else High > Source.Current_Length
   then
  raise Index_Error;
-  else
- Target.Current_Length := High - Low + 1;
- Target.Data (1 .. Target.Current_Length) := Source.Data (Low .. High);
   end if;
+
+  Target.Current_Length := (if Low > High then 0 else High - Low + 1);
+  Target.Data (1 .. Target.Current_Length) := Source.Data (Low .. High);
end Super_Slice;
 

[Ada] Fix comment about mapping of parameters and inlining static funcs

[Marc Poulhiès via Gcc-patches]

Fix glitch in a cross-reference in comment.

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* inline.adb (Replace_Formal): Fix name of the referenced routine.diff --git a/gcc/ada/inline.adb b/gcc/ada/inline.adb
--- a/gcc/ada/inline.adb
+++ b/gcc/ada/inline.adb
@@ -4699,8 +4699,9 @@ package body Inline is
procedure Inline_Static_Function_Call (N : Node_Id; Subp : Entity_Id) is
 
   function Replace_Formal (N : Node_Id) return Traverse_Result;
-  --  Replace each occurrence of a formal with the corresponding actual,
-  --  using the mapping created by Establish_Mapping_For_Inlined_Call.
+  --  Replace each occurrence of a formal with the
+  --  corresponding actual, using the mapping created
+  --  by Establish_Actual_Mapping_For_Inlined_Call.
 
   function Reset_Sloc (Nod : Node_Id) return Traverse_Result;
   --  Reset the Sloc of a node to that of the call itself, so that errors

[Ada] Place "at end" on body nodes

[Marc Poulhiès via Gcc-patches]

This patch fixes a bug where finalization code might refer to variables
outside their lifetime. The previous version moved declarations into the
Handled_Statement_Sequence (HSS), so that the "at end" handler of the
HSS could handle exceptions raised by those declarations. The
First_Real_Statement field was used to find the first statement after
the moved declarations. In addition, if the HSS already had exception
handlers, it was wrapped in another layer of block_statement. This
doesn't work if there are variable-sized objects allocated on the
(primary) stack, because the stack will be popped before the "at end" is
invoked.

In the new version, we allow "at end" on nodes such as
N_Subprogram_Body, in addition to HSS. We modify gigi so that such an
"at end" applies to the whole body (declarations and HSS) by extending
support for At_End_Proc mechanism to N_Block_Statement and N_*_Body
nodes. This also removes the support for First_Real_Statement. In
particular, an exception raised by the declarations will trigger the "at
end". We no longer move declarations into the HSS, we no longer have a
First_Real_Statement field, and we no longer do the wrapping mentioned
above.

This change requires various other changes, in cases where we depended
on the First_Real_Statement and the moving/wrapping mentioned above.

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* gen_il-fields.ads
(First_Real_Statement): Remove this field.
* gen_il-gen-gen_nodes.adb: Remove the First_Real_Statement field.
Add the At_End_Proc field to nodes that have both Declarations and
HSS.
* sinfo.ads
(At_End_Proc): Document new semantics.
(First_Real_Statement): Remove comment.
* exp_ch11.adb
(Expand_N_Handled_Sequence_Of_Statements): Remove
First_Real_Statement.
* exp_ch7.adb
(Build_Cleanup_Statements): Remove "Historical note"; it doesn't
seem useful, and we have revision history.
(Create_Finalizer): Insert the finalizer later, typically in the
statement list, in some cases.
(Build_Finalizer_Call): Attach the "at end" handler to the parent
of the HSS node in most cases, so it applies to declarations.
(Expand_Cleanup_Actions): Remove Wrap_HSS_In_Block and the call to
it. Remove the code that moves declarations. Remove some redundant
code.
* exp_ch9.adb
(Build_Protected_Entry): Copy the At_End_Proc.
(Build_Protected_Subprogram_Body): Reverse the sense of Exc_Safe,
to avoid double negatives. Remove "Historical note" as in
exp_ch7.adb.
(Build_Unprotected_Subprogram_Body): Copy the At_End_Proc from the
protected version.
(Expand_N_Conditional_Entry_Call): Use First (Statements(...))
instead of First_Real_Statement(...).
(Expand_N_Task_Body): Put the Abort_Undefer call at the beginning
of the declarations, rather than in the HSS. Use First
(Statements(...)) instead of First_Real_Statement(...). Copy the
At_End_Proc.
* inline.adb
(Has_Initialized_Type): Return False if the declaration does not
come from source.
* libgnarl/s-tpoben.ads
(Lock_Entries, Lock_Entries_With_Status): Document when these
things raise Program_Error. It's not clear that
Lock_Entries_With_Status ought to be raising exceptions, but at
least it's documented now.
* sem.ads: Minor comment fixes.
* sem_ch6.adb
(Analyze_Subprogram_Body_Helper): Use First (Statements(...))
instead of First_Real_Statement(...).
(Analyze_Null_Procedure): Minor comment fix.
* sem_util.adb
(Might_Raise): Return True for N_Raise_Expression. Adjust the part
about exceptions generated by the back end to match the reality of
what the back end generates.
(Update_First_Real_Statement): Remove.
* sem_util.ads: Remove First_Real_Statement from comment.
* sinfo-utils.ads
(First_Real_Statement): New function that always returns Empty.
This should be removed once gnat-llvm and codepeer have been
updated to not refer to First_Real_Statement.
* sprint.adb
(Sprint_At_End_Proc): Deal with printing At_End_Proc.
* sem_prag.adb: Minor comment fixes.
* gcc-interface/trans.cc (At_End_Proc_to_gnu): New function.
(Subprogram_Body_to_gnu): Call it to handle an At_End_Proc.
(Handled_Sequence_Of_Statements_to_gnu): Likewise. Remove the
support for First_Real_Statement and clean up the rest.
(Exception_Handler_to_gnu): Do not push binding levels.
(Compilation_Unit_to_gnu): Adjust call to process_decls.
(gnat_to_gnu) : Likewise. :
Likewise. : Likewise. :
Likewise and call At_End_Proc_to_gnu to handle an At_End_Proc.
: Likewise.
(process_decls): Remove 

[Ada] Temporarily simplify legality checks for Inox case statements

[Marc Poulhiès via Gcc-patches]

INOX (which is enabled via -gnatX) supports composite case-statement selectors.
As a temporary measure, simplify the coverage-related compile-time checks
for such case statements via two changes: an others choice is always
required for such a case statement, and no legality checks relating to
overlapping of case choices are performed.

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* sem_case.adb: Define a new Boolean constant,
Simplified_Composite_Coverage_Rules, initialized to True. Setting
this constant to True has two effects: 1- Representative value
sets are not fully initialized - this is done to avoid capacity
problems, as well as for performance. 2- In
Check_Case_Pattern_Choices, the only legality check performed is a
check that a "when others =>" choice is present.diff --git a/gcc/ada/sem_case.adb b/gcc/ada/sem_case.adb
--- a/gcc/ada/sem_case.adb
+++ b/gcc/ada/sem_case.adb
@@ -106,6 +106,14 @@ package body Sem_Case is
 
package Composite_Case_Ops is
 
+  Simplified_Composite_Coverage_Rules : constant Boolean := True;
+  --  Indicates that, as a temporary stopgap, we implement
+  --  simpler coverage-checking rules when casing on a
+  --  composite selector:
+  -- 1) Require that an Others choice must be given, regardless
+  --of whether all possible values are covered explicitly.
+  -- 2) No legality checks regarding overlapping choices.
+
   function Box_Value_Required (Subtyp : Entity_Id) return Boolean;
   --  If result is True, then the only allowed value (in a choice
   --  aggregate) for a component of this (sub)type is a box. This rule
@@ -263,7 +271,6 @@ package body Sem_Case is
  type Bound_Values is array (Positive range <>) of Node_Id;
 
   end Choice_Analysis;
-
end Composite_Case_Ops;
 
procedure Expand_Others_Choice
@@ -2526,6 +2533,14 @@ package body Sem_Case is
for P in Part_Id loop
   Insert_Representative (Component_Bounds (P).Low, P);
end loop;
+
+   if Simplified_Composite_Coverage_Rules then
+  --  Omit other representative values to avoid capacity
+  --  problems building data structures only used in
+  --  compile-time checks that will not be performed.
+  return Result;
+   end if;
+
for C of Choices_Bounds loop
   if not C.Is_Others then
  for P in Part_Id loop
@@ -3368,8 +3383,6 @@ package body Sem_Case is
  
 
  procedure Check_Case_Pattern_Choices is
---  ??? Need to Free/Finalize value sets allocated here.
-
 package Ops is new Composite_Case_Ops.Choice_Analysis
   (Case_Statement => N);
 use Ops;
@@ -3394,8 +3407,14 @@ package body Sem_Case is
 
Covered : Value_Set := Empty;
--  The union of all alternatives seen so far
-
 begin
+   if Composite_Case_Ops.Simplified_Composite_Coverage_Rules then
+  if not (for some Choice of Info => Choice.Is_Others) then
+ Error_Msg_N ("others choice required", N);
+  end if;
+  return;
+   end if;
+
for Choice of Info loop
   if Choice.Is_Others then
  Others_Seen := True;

[Ada] Document change to legality checks for Inox case statements

[Marc Poulhiès via Gcc-patches]

INOX (which is enabled via -gnatX) supports composite case-statement selectors.
As a temporary measure, simplify the coverage-related compile-time checks
for such case statements via two changes: an others choice is always
required for such a case statement, and no legality checks relating to
overlapping of case choices are performed.

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* doc/gnat_rm/implementation_defined_pragmas.rst: Document new
temporary rule that a "when others =>" case choice must be given
when casing on a composite selector.
* gnat_rm.texi: Regenerate.diff --git a/gcc/ada/doc/gnat_rm/implementation_defined_pragmas.rst b/gcc/ada/doc/gnat_rm/implementation_defined_pragmas.rst
--- a/gcc/ada/doc/gnat_rm/implementation_defined_pragmas.rst
+++ b/gcc/ada/doc/gnat_rm/implementation_defined_pragmas.rst
@@ -2262,7 +2262,8 @@ of GNAT specific extensions are recognized as follows:
   will not be executed if the earlier alternative "matches"). All possible
   values of the composite type shall be covered. The composite type of the
   selector shall be an array or record type that is neither limited
-  class-wide.
+  class-wide. Currently, a "when others =>" case choice is required; it is
+  intended that this requirement will be relaxed at some point.
 
   If a subcomponent's subtype does not meet certain restrictions, then
   the only value that can be specified for that subcomponent in a case


diff --git a/gcc/ada/gnat_rm.texi b/gcc/ada/gnat_rm.texi
--- a/gcc/ada/gnat_rm.texi
+++ b/gcc/ada/gnat_rm.texi
@@ -3717,7 +3717,8 @@ set shall be a proper subset of the second (and the later alternative
 will not be executed if the earlier alternative “matches”). All possible
 values of the composite type shall be covered. The composite type of the
 selector shall be an array or record type that is neither limited
-class-wide.
+class-wide. Currently, a “when others =>” case choice is required; it is
+intended that this requirement will be relaxed at some point.
 
 If a subcomponent’s subtype does not meet certain restrictions, then
 the only value that can be specified for that subcomponent in a case

[Ada] Cope with scalar subtypes that have a non-scalar basetype.

[Marc Poulhiès via Gcc-patches]

In some cases, the compiler builds a subtype entity Typ such that
Is_Scalar (Typ) is True and Is_Scalar (Base_Type (Typ)) is False.
This comes up in some cases involving a subtype of a private type,
where the full view of the private type is a scalar type. In such a
situation, it may also be the case that Is_Enumeration_Type (Typ) is True
and Is_Enumeration_Type (Base_Type (Typ)) is False. Some code incorrectly
assumed that if a subtype is known to be a scalar (respectively, enumeration)
type, then the same must be true of the base type of that subtype. Fix that
code to handle the case where that assumption does not hold.

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* exp_attr.adb
(Attribute_Valid): Ensure that PBtyp is initialized to a value for
which Is_Scalar_Type is True.
* checks.adb
(Determine_Range): Call Implemention_Base_Type instead of
Base_Type in order to ensure that result is suitable for passing
to Enum_Pos_To_Rep.diff --git a/gcc/ada/checks.adb b/gcc/ada/checks.adb
--- a/gcc/ada/checks.adb
+++ b/gcc/ada/checks.adb
@@ -5094,7 +5094,8 @@ package body Checks is
 --  Don't deal with enumerated types with non-standard representation
 
 or else (Is_Enumeration_Type (Typ)
-   and then Present (Enum_Pos_To_Rep (Base_Type (Typ
+   and then Present (Enum_Pos_To_Rep
+   (Implementation_Base_Type (Typ
 
 --  Ignore type for which an error has been posted, since range in
 --  this case may well be a bogosity deriving from the error. Also


diff --git a/gcc/ada/exp_attr.adb b/gcc/ada/exp_attr.adb
--- a/gcc/ada/exp_attr.adb
+++ b/gcc/ada/exp_attr.adb
@@ -7103,7 +7103,10 @@ package body Exp_Attr is
   --  See separate sections below for the generated code in each case.
 
   when Attribute_Valid => Valid : declare
- PBtyp : Entity_Id := Base_Type (Validated_View (Ptyp));
+ PBtyp : Entity_Id := Implementation_Base_Type (Validated_View (Ptyp));
+ pragma Assert (Is_Scalar_Type (PBtyp)
+  or else Serious_Errors_Detected > 0);
+
  --  The scalar base type, looking through private types
 
  Save_Validity_Checks_On : constant Boolean := Validity_Checks_On;

[Ada] Fix a bug in the contract of formal ordered sets

[Marc Poulhiès via Gcc-patches]

There are 2 main issues in the postcondition of the function Replace
of the formal ordered sets, in the sub package Generic_Keys. One is
related to the fact that when the element is changed, the key is
also changed. The second one is due to the fact that the arrival of
the new element might modify the ordering of the set and thus
the Positions might be modified.
As a consequence, the postcondition might be false and thus fail
at runtime.

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* libgnat/a-cforse.ads (Replace): Fix the postcondition.diff --git a/gcc/ada/libgnat/a-cforse.ads b/gcc/ada/libgnat/a-cforse.ads
--- a/gcc/ada/libgnat/a-cforse.ads
+++ b/gcc/ada/libgnat/a-cforse.ads
@@ -1598,7 +1598,7 @@ is
 
  --  Key now maps to New_Item
 
- and Element (Container, Key) = New_Item
+ and Element (Container, Find (Container, Key)'Old) = New_Item
 
  --  New_Item is contained in Container
 
@@ -1622,8 +1622,9 @@ is
 E_Right  => Elements (Container),
 P_Left   => Positions (Container)'Old,
 P_Right  => Positions (Container),
-Position => Find (Container, Key))
- and Positions (Container) = Positions (Container)'Old;
+Position => Find (Container, Key)'Old)
+ and P.Keys_Included (Positions (Container),
+  Positions (Container)'Old);
 
   procedure Exclude (Container : in out Set; Key : Key_Type) with
 Global => null,

[Ada] Correctly round Value attribute for floating point in more cases

[Marc Poulhiès via Gcc-patches]

This provides correct rounding in the IEEE 754 sense for the Value attribute
of floating-point types in more cases, by switching from tables of powers of
10 to tables of powers of 5 for precomputed values, thus making it possible
to use a single divide for denormals and normalized numbers just above them.

Although this significantly increases the size of the tables, object files
for them are still quite small (1, 2 and 4 KB respectively on x86-64).

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* libgnat/s-powflt.ads (Powfive): New constant array.
* libgnat/s-powlfl.ads (Powfive): Likewise.
(Powfive_100): New constant.
(Powfive_200): Likewise.
(Powfive_300): Likewise.
* libgnat/s-powllf.ads (Powfive): New constant array.
(Powfive_100): New constant.
(Powfive_200): Likewise.
(Powfive_300): Likewise.
* libgnat/s-valflt.ads (Impl): Replace Powten with Powfive and pass
Null_Address for the address of large constants.
* libgnat/s-vallfl.ads (Impl): Replace Powten with Powfive and pass
the address of large constants.
* libgnat/s-valllf.ads (Impl): Likewise.
* libgnat/s-valrea.ads (System.Val_Real): Replace Powten_Address
with Powfive_Address and add Powfive_{1,2,3}00_Address parameters.
* libgnat/s-valrea.adb (Is_Large_Type): New boolean constant.
(Is_Very_Large_Type): Likewise.
(Maxexp32): Change value of 10 to that of 5.
(Maxexp64): Likewise.
(Maxexp80): Likewise.
(Integer_to_Real): Use a combination of tables of powers of 5 and
scaling if the base is 10.
(Large_Powten): Rename into...
(Large_Powfive): ...this.  Add support for large constants.
(Large_Powfive): New overloaded function for very large exponents.diff --git a/gcc/ada/libgnat/s-powflt.ads b/gcc/ada/libgnat/s-powflt.ads
--- a/gcc/ada/libgnat/s-powflt.ads
+++ b/gcc/ada/libgnat/s-powflt.ads
@@ -29,17 +29,41 @@
 --  --
 --
 
---  This package provides a powers of ten table used for real conversions
+--  This package provides tables of powers used for real conversions
 
 package System.Powten_Flt is
pragma Pure;
 
Maxpow_Exact : constant := 10;
-   --  Largest power of ten exactly representable with Float. It is equal to
+   --  Largest power of five exactly representable with Float. It is equal to
--  floor (M * log 2 / log 5), when M is the size of the mantissa (24).
+   --  It also works for any number of the form 5*(2**N) and in particular 10.
 
Maxpow : constant := Maxpow_Exact * 2;
-   --  Largest power of ten exactly representable with a double Float
+   --  Largest power of five exactly representable with double Float
+
+   Powfive : constant array (0 .. Maxpow, 1 .. 2) of Float :=
+ [00 => [5.0**00, 0.0],
+  01 => [5.0**01, 0.0],
+  02 => [5.0**02, 0.0],
+  03 => [5.0**03, 0.0],
+  04 => [5.0**04, 0.0],
+  05 => [5.0**05, 0.0],
+  06 => [5.0**06, 0.0],
+  07 => [5.0**07, 0.0],
+  08 => [5.0**08, 0.0],
+  09 => [5.0**09, 0.0],
+  10 => [5.0**10, 0.0],
+  11 => [5.0**11, 5.0**11 - Float'Machine (5.0**11)],
+  12 => [5.0**12, 5.0**12 - Float'Machine (5.0**12)],
+  13 => [5.0**13, 5.0**13 - Float'Machine (5.0**13)],
+  14 => [5.0**14, 5.0**14 - Float'Machine (5.0**14)],
+  15 => [5.0**15, 5.0**15 - Float'Machine (5.0**15)],
+  16 => [5.0**16, 5.0**16 - Float'Machine (5.0**16)],
+  17 => [5.0**17, 5.0**17 - Float'Machine (5.0**17)],
+  18 => [5.0**18, 5.0**18 - Float'Machine (5.0**18)],
+  19 => [5.0**19, 5.0**19 - Float'Machine (5.0**19)],
+  20 => [5.0**20, 5.0**20 - Float'Machine (5.0**20)]];
 
Powten : constant array (0 .. Maxpow, 1 .. 2) of Float :=
  [00 => [1.0E+00, 0.0],


diff --git a/gcc/ada/libgnat/s-powlfl.ads b/gcc/ada/libgnat/s-powlfl.ads
--- a/gcc/ada/libgnat/s-powlfl.ads
+++ b/gcc/ada/libgnat/s-powlfl.ads
@@ -29,17 +29,74 @@
 --  --
 --
 
---  This package provides a powers of ten table used for real conversions
+--  This package provides tables of powers used for real conversions
 
 package System.Powten_LFlt is
pragma Pure;
 
Maxpow_Exact : constant := 22;
-   --  Largest power of ten exactly representable with Long_Float. It is equal
+   --  Largest power of five exactly representable with Long_Float. It is equal
--  to floor (M * log 2 / log 5), when M is the size of the mantissa (53).
+   --  It also works for any number of the form 5*(2**N) and in particular 10.
 
Maxpow : constant := Maxpow_Exact * 2;
-   --  Largest power of ten exactly representable with a double Long_Float
+   --  Largest 

[Ada] Bad Valid_Scalars result if signed int component type signed has partial view.

[Marc Poulhiès via Gcc-patches]

For an object X of a composite type, the attribute X'Valid_Scalars should
return False if and only if there exists at least one invalid scalar
subcomponent of X. The validity test for a scalar part may include a
range test. In some cases involving a private type that is implemented as
a signed integer type, this range test was incorrectly implemented using
unsigned comparisons. For an enclosing object X, this could result in
X'Valid_Scalars yielding the wrong Boolean result. Such an incorrect
result would almost always be False, although an incorrect True result is
theoretically possible (this would require that both bounds of the
component subtype are negative and that the invalid component has a positive
value).

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* exp_attr.adb
(Make_Range_Test): In determining which subtype's First and Last
attributes are to be queried as part of a range test, call
Validated_View in order to get a scalar (as opposed to private)
subtype.
(Attribute_Valid): In determining whether to perform a signed or
unsigned comparison for a range test, call Validated_View in order
to get a scalar (as opposed to private) type. Also correct a typo
which, by itself, is the source of the problem reported for this
ticket.diff --git a/gcc/ada/exp_attr.adb b/gcc/ada/exp_attr.adb
--- a/gcc/ada/exp_attr.adb
+++ b/gcc/ada/exp_attr.adb
@@ -7103,7 +7103,8 @@ package body Exp_Attr is
   --  See separate sections below for the generated code in each case.
 
   when Attribute_Valid => Valid : declare
- PBtyp : Entity_Id := Base_Type (Ptyp);
+ PBtyp : Entity_Id := Base_Type (Validated_View (Ptyp));
+ --  The scalar base type, looking through private types
 
  Save_Validity_Checks_On : constant Boolean := Validity_Checks_On;
  --  Save the validity checking mode. We always turn off validity
@@ -7150,21 +7151,27 @@ package body Exp_Attr is
Temp := Duplicate_Subexpr (Pref);
 end if;
 
-return
-  Make_In (Loc,
-Left_Opnd  => Unchecked_Convert_To (PBtyp, Temp),
-Right_Opnd =>
-  Make_Range (Loc,
-Low_Bound  =>
-  Unchecked_Convert_To (PBtyp,
-Make_Attribute_Reference (Loc,
-  Prefix => New_Occurrence_Of (Ptyp, Loc),
-  Attribute_Name => Name_First)),
-High_Bound =>
-  Unchecked_Convert_To (PBtyp,
-Make_Attribute_Reference (Loc,
-  Prefix => New_Occurrence_Of (Ptyp, Loc),
-  Attribute_Name => Name_Last;
+declare
+   Val_Typ : constant Entity_Id := Validated_View (Ptyp);
+begin
+   return
+ Make_In (Loc,
+   Left_Opnd  => Unchecked_Convert_To (PBtyp, Temp),
+   Right_Opnd =>
+ Make_Range (Loc,
+   Low_Bound  =>
+ Unchecked_Convert_To (PBtyp,
+   Make_Attribute_Reference (Loc,
+ Prefix =>
+   New_Occurrence_Of (Val_Typ, Loc),
+ Attribute_Name => Name_First)),
+   High_Bound =>
+ Unchecked_Convert_To (PBtyp,
+   Make_Attribute_Reference (Loc,
+ Prefix =>
+   New_Occurrence_Of (Val_Typ, Loc),
+ Attribute_Name => Name_Last;
+end;
  end Make_Range_Test;
 
  --  Local variables
@@ -7186,13 +7193,6 @@ package body Exp_Attr is
 
  Validity_Checks_On := False;
 
- --  Retrieve the base type. Handle the case where the base type is a
- --  private enumeration type.
-
- if Is_Private_Type (PBtyp) and then Present (Full_View (PBtyp)) then
-PBtyp := Full_View (PBtyp);
- end if;
-
  --  Floating-point case. This case is handled by the Valid attribute
  --  code in the floating-point attribute run-time library.
 
@@ -7462,7 +7462,7 @@ package body Exp_Attr is
Uns  : constant Boolean :=
 Is_Unsigned_Type (Ptyp)
   or else (Is_Private_Type (Ptyp)
-and then Is_Unsigned_Type (Btyp));
+and then Is_Unsigned_Type (PBtyp));
Size : Uint;
P: Node_Id := Pref;
 

[Ada] ICE handling discriminant-dependent index constraint for access component

[Marc Poulhiès via Gcc-patches]

The compiler would fail with an internal error in some cases involving
a discriminated record type that provides a discriminant-dependent index
constraint for the subtype of a component of an access-to-array type when a
dereference of that component of some object is mentioned in a pre- or
postcondition expression.

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* sem_ch4.adb
(Analyze_Selected_Component): Define new Boolean-valued function,
Constraint_Has_Unprefixed_Discriminant_Reference, which takes a
subtype that is subject to a discriminant-dependent constraint and
returns True if any of the constraint values are unprefixed
discriminant names. Usually, the Etype of a selected component
node is set to Etype of the component. However, in the case of an
access-to-array component for which this predicate returns True,
we instead use the base type of the Etype of the component.
Normally such problematic discriminant references are addressed by
calling Build_Actual_Subtype_Of_Component, but that doesn't work
if Full_Analyze is False.diff --git a/gcc/ada/sem_ch4.adb b/gcc/ada/sem_ch4.adb
--- a/gcc/ada/sem_ch4.adb
+++ b/gcc/ada/sem_ch4.adb
@@ -4814,6 +4814,14 @@ package body Sem_Ch4 is
   Is_Single_Concurrent_Object : Boolean;
   --  Set True if the prefix is a single task or a single protected object
 
+  function Constraint_Has_Unprefixed_Discriminant_Reference
+(Typ : Entity_Id) return Boolean;
+  --  Given a subtype that is subject to a discriminant-dependent
+  --  constraint, returns True if any of the values of the constraint
+  --  (i.e., any of the index values for an index constraint, any of
+  --  the discriminant values for a discriminant constraint)
+  --  are unprefixed discriminant names.
+
   procedure Find_Component_In_Instance (Rec : Entity_Id);
   --  In an instance, a component of a private extension may not be visible
   --  while it was visible in the generic. Search candidate scope for a
@@ -4842,6 +4850,56 @@ package body Sem_Ch4 is
   --  _Procedure, and collect all its interpretations (since it may be an
   --  overloaded interface primitive); otherwise return False.
 
+  --
+  -- Constraint_Has_Unprefixed_Discriminant_Reference --
+  --
+
+  function Constraint_Has_Unprefixed_Discriminant_Reference
+(Typ : Entity_Id) return Boolean
+  is
+
+ function Is_Discriminant_Name (N : Node_Id) return Boolean is
+   ((Nkind (N) = N_Identifier)
+  and then (Ekind (Entity (N)) = E_Discriminant));
+  begin
+ if Is_Array_Type (Typ) then
+declare
+   Index : Node_Id := First_Index (Typ);
+   Rng   : Node_Id;
+begin
+   while Present (Index) loop
+  Rng := Index;
+  if Nkind (Rng) = N_Subtype_Indication then
+ Rng := Range_Expression (Constraint (Rng));
+  end if;
+
+  if Nkind (Rng) = N_Range then
+ if Is_Discriminant_Name (Low_Bound (Rng))
+   or else Is_Discriminant_Name (High_Bound (Rng))
+ then
+return True;
+ end if;
+  end if;
+
+  Next_Index (Index);
+   end loop;
+end;
+ else
+declare
+   Elmt : Elmt_Id := First_Elmt (Discriminant_Constraint (Typ));
+begin
+   while Present (Elmt) loop
+  if Is_Discriminant_Name (Node (Elmt)) then
+ return True;
+  end if;
+  Next_Elmt (Elmt);
+   end loop;
+end;
+ end if;
+
+ return False;
+  end Constraint_Has_Unprefixed_Discriminant_Reference;
+
   
   -- Find_Component_In_Instance --
   
@@ -5289,6 +5347,33 @@ package body Sem_Ch4 is
  end;
   end if;
 
+   --  If Etype (Comp) is an access type whose designated subtype
+   --  is constrained by an unprefixed discriminant value,
+   --  then ideally we would build a new subtype with an
+   --  appropriately prefixed discriminant value and use that
+   --  instead, as is done in Build_Actual_Subtype_Of_Component.
+   --  That turns out to be difficult in this context (with
+   --  Full_Analysis = False, we could be processing a selected
+   --  component that occurs in a Postcondition pragma;
+   --  PPC pragmas are odd because they can contain references
+   --  to formal 

[Ada] Tune message for illegal aspect Relaxed_Initialization

[Marc Poulhiès via Gcc-patches]

Error message about illegal aspect Relaxed_Initialization was lacking a
whitespace character.

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* sem_ch13.adb (Analyze_Aspect_Relaxed_Initialization): Fix error
template.diff --git a/gcc/ada/sem_ch13.adb b/gcc/ada/sem_ch13.adb
--- a/gcc/ada/sem_ch13.adb
+++ b/gcc/ada/sem_ch13.adb
@@ -2293,7 +2293,7 @@ package body Sem_Ch13 is
 then
Error_Msg_Name_1 := Nam;
Error_Msg_N
- ("expression of aspect %" &
+ ("expression of aspect % " &
   "must be static", Aspect);
 end if;
 

[Ada] Improve detection of illegal Iterable aspects

[Marc Poulhiès via Gcc-patches]

Handling of aspect Iterable was lacking guards against illegal code, so
the compiler either crashed or emitted cryptic errors while expanding
loops that rely on this aspect.

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* doc/gnat_rm/implementation_defined_aspects.rst
(Aspect Iterable): Include Last and Previous primitives in
syntactic and semantic description.
* exp_attr.adb
(Expand_N_Attribute_Reference): Don't expect attributes like
Iterable that can only appear in attribute definition clauses.
* sem_ch13.adb
(Analyze_Attribute_Definition_Clause): Prevent crash on
non-aggregate Iterable attribute; improve basic diagnosis of
attribute values.
(Resolve_Iterable_Operation): Improve checks for illegal
primitives in aspect Iterable, e.g. with wrong number of formal
parameters.
(Validate_Iterable_Aspect): Prevent crashes on syntactically
illegal aspect expression.
* sem_util.adb
(Get_Cursor_Type): Fix style.
* gnat_ugn.texi, gnat_rm.texi: Regenerate.diff --git a/gcc/ada/doc/gnat_rm/implementation_defined_aspects.rst b/gcc/ada/doc/gnat_rm/implementation_defined_aspects.rst
--- a/gcc/ada/doc/gnat_rm/implementation_defined_aspects.rst
+++ b/gcc/ada/doc/gnat_rm/implementation_defined_aspects.rst
@@ -317,23 +317,27 @@ The following is a typical example of use:
   type List is private with
   Iterable => (First   => First_Cursor,
Next=> Advance,
-   Has_Element => Cursor_Has_Element,
-  [Element => Get_Element]);
+   Has_Element => Cursor_Has_Element
+ [,Element => Get_Element]
+ [,Last=> Last_Cursor]
+ [,Previous=> Retreat]);
 
-* The value denoted by ``First`` must denote a primitive operation of the
-  container type that returns a ``Cursor``, which must a be a type declared in
+* The values of ``First`` and ``Last`` are primitive operations of the
+  container type that return a ``Cursor``, which must be a type declared in
   the container package or visible from it. For example:
 
 .. code-block:: ada
 
   function First_Cursor (Cont : Container) return Cursor;
+  function Last_Cursor  (Cont : Container) return Cursor;
 
-* The value of ``Next`` is a primitive operation of the container type that takes
-  both a container and a cursor and yields a cursor. For example:
+* The values of ``Next`` and ``Previous`` are primitive operations of the container type that take
+  both a container and a cursor and yield a cursor. For example:
 
 .. code-block:: ada
 
   function Advance (Cont : Container; Position : Cursor) return Cursor;
+  function Retreat (Cont : Container; Position : Cursor) return Cursor;
 
 * The value of ``Has_Element`` is a primitive operation of the container type
   that takes both a container and a cursor and yields a boolean. For example:


diff --git a/gcc/ada/exp_attr.adb b/gcc/ada/exp_attr.adb
--- a/gcc/ada/exp_attr.adb
+++ b/gcc/ada/exp_attr.adb
@@ -2079,7 +2079,8 @@ package body Exp_Attr is
 
   case Id is
 
-  --  Attributes related to Ada 2012 iterators
+  --  Attributes related to Ada 2012 iterators. They are only allowed in
+  --  attribute definition clauses and should never be expanded.
 
   when Attribute_Constant_Indexing
  | Attribute_Default_Iterator
@@ -2088,7 +2089,7 @@ package body Exp_Attr is
  | Attribute_Iterator_Element
  | Attribute_Variable_Indexing
   =>
- null;
+ raise Program_Error;
 
   --  Internal attributes used to deal with Ada 2012 delayed aspects. These
   --  were already rejected by the parser. Thus they shouldn't appear here.


diff --git a/gcc/ada/gnat_rm.texi b/gcc/ada/gnat_rm.texi
--- a/gcc/ada/gnat_rm.texi
+++ b/gcc/ada/gnat_rm.texi
@@ -9774,33 +9774,37 @@ The following is a typical example of use:
 type List is private with
 Iterable => (First   => First_Cursor,
  Next=> Advance,
- Has_Element => Cursor_Has_Element,
-[Element => Get_Element]);
+ Has_Element => Cursor_Has_Element
+   [,Element => Get_Element]
+   [,Last=> Last_Cursor]
+   [,Previous=> Retreat]);
 @end example
 
 
 @itemize *
 
 @item 
-The value denoted by @code{First} must denote a primitive operation of the
-container type that returns a @code{Cursor}, which must a be a type declared in
+The values of @code{First} and @code{Last} are primitive operations of the
+container type that return a @code{Cursor}, which must be a type declared in
 the container package or visible from it. For example:
 @end itemize
 
 @example
 function First_Cursor (Cont : Container) return Cursor;
+function Last_Cursor  (Cont : Container) return Cursor;
 @end example
 
 
 @itemize *
 
 @item 
-The 

[Ada] Add formal verification dependencies to libgnat

[Marc Poulhiès via Gcc-patches]

Spec units for verification of the GNAT standard library with GNATprove
must be listed as part of the libgnat package, as otherwise libadalang
will complain about missing dependencies.

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* Makefile.rtl (GNATRTL_NONTASKING_OBJS): Include
System.Value_U_Spec and System.Value_I_Spec units.diff --git a/gcc/ada/Makefile.rtl b/gcc/ada/Makefile.rtl
--- a/gcc/ada/Makefile.rtl
+++ b/gcc/ada/Makefile.rtl
@@ -778,6 +778,7 @@ GNATRTL_NONTASKING_OBJS= \
   s-vaenu8$(objext) \
   s-vafi32$(objext) \
   s-vafi64$(objext) \
+  s-vaispe$(objext) \
   s-valboo$(objext) \
   s-valcha$(objext) \
   s-valflt$(objext) \
@@ -796,6 +797,7 @@ GNATRTL_NONTASKING_OBJS= \
   s-valuns$(objext) \
   s-valuti$(objext) \
   s-valwch$(objext) \
+  s-vauspe$(objext) \
   s-veboop$(objext) \
   s-vector$(objext) \
   s-vercon$(objext) \