Re: [PATCH 2/2] xtensa: Implement new target hook: TARGET_CONSTANT_OK_FOR_CPROP_P

[Takayuki 'January June' Suwa via Gcc-patches]

On 2022/09/13 4:34, Max Filippov wrote:
Hi!

> On Sun, Sep 11, 2022 at 1:50 PM Takayuki 'January June' Suwa
>  wrote:
>>
>> This patch implements new target hook TARGET_CONSTANT_OK_FOR_CPROP_P in
>> order to exclude CONST_INTs that cannot fit into a MOVI machine instruction
>> from cprop.
>>
>> gcc/ChangeLog:
>>
>> * config/xtensa/xtensa.c (TARGET_CONSTANT_OK_FOR_CPROP_P):
>> New macro definition.
>> (xtensa_constant_ok_for_cprop_p):
>> Implement the hook as mentioned above.
>> ---
>>  gcc/config/xtensa/xtensa.cc | 20 +---
>>  1 file changed, 17 insertions(+), 3 deletions(-)
> 
> Regtested for target=xtensa-linux-uclibc, no new regressions.
> Committed to master.
> 

Oops, sorry, this patch doesn't have the prerequisite patch merged in, so 
please revert (that target hook isn't working yet).

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

[HAO CHEN GUI via Gcc-patches]

Hi Segher,

On 7/9/2022 上午 1:19, Segher Boessenkool wrote:
> 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 :-)

IMO, if we add "-mpowerpc64" into dg-options, the "-m32/-mpowerpc64" will be 
tested
automatically. It will increase the test coverage. So the concern is it 
increases test
time?

Thanks
Gui Haochen

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

[HAO CHEN GUI via Gcc-patches]

Hi Segher,

On 10/9/2022 上午 1:17, Segher Boessenkool wrote:
>> In rs6000-overload.def, the vsx_ version built-ins are overridden to vec_
>> version.
> How?  Where?

vec_ version built-ins are defined in rs6000-overload.def. Yes, they're fine
and in line with the definition in PVIPR.

[VEC_VEEDP, vec_extract_exp_dp, __builtin_vec_extract_exp_dp]
  vull __builtin_vec_extract_exp_dp (vd);
VEEDP  VEEDP_DEPR1

[VEC_VEESP, vec_extract_exp_sp, __builtin_vec_extract_exp_sp]
  vui __builtin_vec_extract_exp_sp (vf);
VEESP  VEESP_DEPR1

[VEC_VEE, vec_extract_exp, __builtin_vec_extract_exp]
  vui __builtin_vec_extract_exp (vf);
VEESP
  vull __builtin_vec_extract_exp (vd);
VEEDP

vec-extract-exp-2.c:12:3: note: overloaded builtin ‘__builtin_vec_extract_exp’ 
is implemented by builtin ‘__builtin_vsx_extract_exp_dp’

Thanks
Gui Haochen

Re: [PATCH] c++: Implement P1467R9 - Extended floating-point types and standard names compiler part except for bfloat16 [PR106652]

[Jakub Jelinek via Gcc-patches]

On Mon, Sep 12, 2022 at 10:52:35PM +0200, Jakub Jelinek via Gcc-patches wrote:
> Can't that be implemented as 2 conversions, convert BFmode to SFmode and
> then back to HFmode (or the other way around)?
> SFmode is a superset of both formats, so except for the raise exception on
> SNaN and conversion to QNaN extension to SFmode from both formats should be
> lossless?
> 
> In any case, the bfloat16 support is intended maybe for follow-up patches,
> not in this patch.

Well, the BF -> HF conversion could be done just by << 16 + SF -> HF
conversion too.
But for BF -> HF and HF -> BF conversions (C++ allows them only
for explicit casts, not implicit), the question is what library routine
name to use, because it is neither pure extension nor pure truncation.
But guess that is the case for PowerPC IFmode vs. KFmode.  And the backend
has both truncifkf2 and extendifkf2 named patterns which presumably do the
same thing.

Jakub

Re: [PATCH] c++: Implement P1467R9 - Extended floating-point types and standard names compiler part except for bfloat16 [PR106652]

[Jakub Jelinek via Gcc-patches]

On Mon, Sep 12, 2022 at 07:36:05PM +, Joseph Myers wrote:
> On Mon, 12 Sep 2022, Jakub Jelinek via Gcc-patches wrote:
> 
> > Now, I guess for the fixincludes it could also use
> > #  if !__GNUC_PREREQ (7, 0) || (defined __cplusplus && !__GNUC_PREREQ (13, 
> > 0))
> > where earlier GCC 13 snapshots would not be doing the fixincludes,
> > but the question is what to use for upstream glibc, because
> > there will be 13.0 snapshots where C++ doesn't support _Float{16,32,64,128}
> > and where it is essential to use what glibc has been doing previously
> > and using the #else would fail miserably, and then 13.0 snapshots where it
> > does support it and where using the if would fail miserably.
> 
> We don't claim in glibc to support old snapshots from master, so checking 
> for __GNUC_PREREQ (13, 0) and failing for such older GCC 13 versions is 
> fine.

Ok, makes sense, especially if it is applied on the glibc side a few months
after it is changed on the GCC side.  If it is applied immediately, there
could be people who have 2 weeks old GCC trunk snapshot and try it with latest
glibc, but if it will be say in December, it will be far less likely.

> > Conversion from BFmode to SFmode is easy, left shift by 16 and ought to be
> > implemented inline, SFmode -> BFmode conversion is harder,
> 
> Properly the right way for converting from BFmode to SFmode in the 
> presence of -fsignaling-nans should depend on how the result is used.  If 
> it's used for arithmetic, it's OK to have converted a BFmode signaling NaN 
> to an SFmode signaling NaN, but if e.g. the result is examined with 
> issignaling or otherwise stored so it may be significant later whether the 
> result is a quiet or signaling NaN, IEEE semantics would mean a signaling 
> NaN should be a converted to a quiet NaN with "invalid" raised.  Though I 
> don't know how far hardware instructions for BFmode attempt to follow IEEE 
> semantics.
> 
> (Cf. powerpc single-precision load instructions whose effect is defined as 
> a purely bitwise conversion from single to double precision, so that 
> single-precision load and store of a signaling NaN never end up converting 
> it to a quiet NaN even though the in-register format is double precision.)

Looking at HW instructions, I believe x86 F16C VCVTPH2PS and VCVTPS2PH
raise invalid on SNaN and turn it into QNaN and from what I can understand,
the AVX512F16 conversion insns like VCVTSH2SS and VCVTSS2SH do too,
but AVX512_BF16 VCVTNE2PS2BF16 doesn't raise any exceptions (and there is
no insn for the other direction).

> > (untested) and the question is if it should be implemented in libgcc
> > (and using soft-fp or not), or inline, or both depending on -Os.
> 
> Also if you try to do a direct conversion between BFmode and HFmode, 
> soft-fp's current support for conversions may not handle that case (where 
> one type has wider exponent range and other type has higher precision).

Can't that be implemented as 2 conversions, convert BFmode to SFmode and
then back to HFmode (or the other way around)?
SFmode is a superset of both formats, so except for the raise exception on
SNaN and conversion to QNaN extension to SFmode from both formats should be
lossless?

In any case, the bfloat16 support is intended maybe for follow-up patches,
not in this patch.

Jakub

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

[Jason Merrill via Gcc-patches]

On 9/8/22 18:54, Marek Polacek wrote:

On Tue, Sep 06, 2022 at 10:38:12PM -0400, Jason Merrill wrote:

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.


Can of worms.   The test is

   struct Mutt {
   operator int*() &&;
   };

   int* five(Mutt x) {
   return x;  // OK since C++20 because P1155
   }

'x' should be treated as an rvalue, therefore the operator fn taking
an rvalue ref to Mutt should be used to convert 'x' to int*.  We fail
because we don't treat 'x' as an rvalue because the function doesn't
return a class.  So the patch should be just

--- a/gcc/cp/typeck.cc
+++ b/gcc/cp/typeck.cc
@@ -10875,10 +10875,7 @@ check_return_expr (tree retval, bool *no_warning)
   Note that these conditions are similar to, but not as strict as,
  the conditions for the named return value optimization.  */
bool converted = false;
-  tree moved;
-  /* This is only interesting for class type.  */
-  if (CLASS_TYPE_P (functype)
- && (moved = treat_lvalue_as_rvalue_p (retval, /*return*/true)))
+  if (tree moved = treat_lvalue_as_rvalue_p (retval, /*return*/true))
 {
   if (cxx_dialect < cxx20)
 {

which fixes the test, but breaks a lot of middle-end warnings.  For instance
g++.dg/warn/nonnull3.C, where the patch above changes .gimple:

  bool A::foo (struct A * const this, <<< Unknown tree: offset_type >>> p)
  {
-  bool D.2146;
+  bool D.2150;
  
-  D.2146 = p != -1;

-  return D.2146;
+  p.0_1 = p;
+  D.2150 = p.0_1 != -1;
+  return D.2150;
  }

and we no longer get the warning.  I thought maybe I could undo the implicit
rvalue conversion in cp_fold, when it sees implicit_rvalue_p, but that didn't
work.  So currently I'm stuck.  Should we try to figure this out or push aside?


Can you undo the implicit rvalue conversion within check_return_expr, 
where we can still refer back to the original expression?


Or avoid the rvalue conversion if the return type is scalar?

Did you see my comments in the body of the patch?

Jason

Re: [PATCH] c++: remove '_sfinae' suffix from functions

[Jason Merrill via Gcc-patches]

On 9/9/22 08:52, Patrick Palka wrote:

Each of the following functions

   instantiate_non_dependent_expr
   get_target_expr
   require_complete_type
   abstract_virtuals_error
   cxx_constant_value

is (presumably for historical reasons) just a non-SFINAE-enabled wrapper
for the corresponding SFINAE-enabled version that's suffixed by '_sfinae'.
But this suffix is at best redundant since a 'complain' parameter already
conveys that a function is appropriately SFINAE-enabled, and having two
such versions of a function is cluttersome compared to just using a default
argument (and also no less error prone I think).

So this patch squashes the two versions of each of the above functions
by adding a default 'complain' argument to the SFINAE-enabled version
whose '_sfinae' suffix we then remove.

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


OK.


gcc/cp/ChangeLog:

* all.cc (build_conditional_expr): Adjust calls to
'_sfinae'-suffixed functions.
(build_temp): Likewise.
(convert_like_internal): Likewise.
(convert_arg_to_ellipsis): Likewise.
(build_over_call): Likewise.
(build_cxx_call): Likewise.
(build_new_method_call): Likewise.
* constexpr.cc (cxx_eval_outermost_constant_expr): Likewise.
(cxx_constant_value_sfinae): Rename to ...
(cxx_constant_value): ... this.  Document its default arguments.
(fold_non_dependent_expr): Adjust function comment.
* cp-tree.h (instantiate_non_dependent_expr_sfinae): Rename to ...
(instantiate_non_dependent_expr): ... this.  Give its 'complain'
parameter a default argument.
(get_target_expr_sfinae, get_target_expr): Likewise.
(require_complete_type_sfinae, require_complete_type): Likewise.
(abstract_virtuals_error_sfinae, abstract_virtuals_error):
Likewise.
(cxx_constant_value_sfinae, cxx_constant_value): Likewise.
* cvt.cc (build_up_reference): Adjust calls to '_sfinae'-suffixed
functions.
(ocp_convert): Likewise.
* decl.cc (build_explicit_specifier): Likewise.
* except.cc (build_noexcept_spec): Likewise.
* init.cc (build_new_1): Likewise.
* pt.cc (expand_integer_pack): Likewise.
(instantiate_non_dependent_expr_internal): Adjust function
comment.
(instantiate_non_dependent_expr): Rename to ...
(instantiate_non_dependent_expr_sfinae): ... this.  Document its
default argument.
(tsubst_init): Adjust calls to '_sfinae'-suffixed functions.
(fold_targs_r): Likewise.
* semantics.cc (finish_compound_literal): Likewise.
(finish_decltype_type): Likewise.
(cp_build_bit_cast): Likewise.
* tree.cc (build_cplus_new): Likewise.
(get_target_expr): Rename to ...
(get_target_expr_sfinae): ... this.  Document its default
argument.
* typeck.cc (require_complete_type): Rename to ...
(require_complete_type_sfinae): ... this.  Document its default
argument.
(cp_build_array_ref): Adjust calls to '_sfinae'-suffixed
functions.
(convert_arguments): Likewise.
(cp_build_binary_op): Likewise.
(build_static_cast_1): Likewise.
(cp_build_modify_expr): Likewise.
(convert_for_initialization): Likewise.
* typeck2.cc (abstract_virtuals_error): Rename to ...
(abstract_virtuals_error_sfinae): ... this. Document its default
argument.
(build_functional_cast_1): Adjust calls to '_sfinae'-suffixed
functions.
---
  gcc/cp/call.cc  | 22 +++---
  gcc/cp/constexpr.cc | 20 ++--
  gcc/cp/cp-tree.h| 23 +++
  gcc/cp/cvt.cc   |  4 ++--
  gcc/cp/decl.cc  |  2 +-
  gcc/cp/except.cc|  2 +-
  gcc/cp/init.cc  |  2 +-
  gcc/cp/pt.cc| 17 ++---
  gcc/cp/semantics.cc |  6 +++---
  gcc/cp/tree.cc  | 10 ++
  gcc/cp/typeck.cc| 21 -
  gcc/cp/typeck2.cc   | 33 ++---
  12 files changed, 62 insertions(+), 100 deletions(-)

diff --git a/gcc/cp/call.cc b/gcc/cp/call.cc
index d107a2814dc..7e9289fc2d0 100644
--- a/gcc/cp/call.cc
+++ b/gcc/cp/call.cc
@@ -5976,7 +5976,7 @@ build_conditional_expr (const op_location_t ,
 but now we sometimes wrap them in NOP_EXPRs so the test would
 fail.  */
if (CLASS_TYPE_P (TREE_TYPE (result)))
-   result = get_target_expr_sfinae (result, complain);
+   result = get_target_expr (result, complain);
/* If this expression is an rvalue, but might be mistaken for an
 lvalue, we must add a NON_LVALUE_EXPR.  */
result = rvalue (result);
@@ -7672,7 +7672,7 @@ build_temp (tree expr, tree type, int flags,
if ((lvalue_kind (expr) & clk_packed)
&& CLASS_TYPE_P (TREE_TYPE (expr))
&& !type_has_nontrivial_copy_init (TREE_TYPE 

[pushed] c++: auto member function and auto variable [PR106893]

[Jason Merrill via Gcc-patches]

As with PR105623, we need to call mark_single_function sooner to
resolve the type of a BASELINK.

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

PR c++/106893
PR c++/90451

gcc/cp/ChangeLog:

* decl.cc (cp_finish_decl): Call mark_single_function.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1y/auto-fn65.C: New test.
---
 gcc/cp/decl.cc |  3 +++
 gcc/testsuite/g++.dg/cpp1y/auto-fn65.C | 10 ++
 2 files changed, 13 insertions(+)
 create mode 100644 gcc/testsuite/g++.dg/cpp1y/auto-fn65.C

diff --git a/gcc/cp/decl.cc b/gcc/cp/decl.cc
index 4665a29a24d..88f283bc4bd 100644
--- a/gcc/cp/decl.cc
+++ b/gcc/cp/decl.cc
@@ -8140,6 +8140,9 @@ cp_finish_decl (tree decl, tree init, bool 
init_const_expr_p,
d_init = build_x_compound_expr_from_list (d_init, ELK_INIT,
  tf_warning_or_error);
  d_init = resolve_nondeduced_context (d_init, tf_warning_or_error);
+ /* Force auto deduction now.  Use tf_none to avoid redundant warnings
+on deprecated-14.C.  */
+ mark_single_function (d_init, tf_none);
}
   enum auto_deduction_context adc = adc_variable_type;
   if (DECL_DECOMPOSITION_P (decl))
diff --git a/gcc/testsuite/g++.dg/cpp1y/auto-fn65.C 
b/gcc/testsuite/g++.dg/cpp1y/auto-fn65.C
new file mode 100644
index 000..78bb004303b
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1y/auto-fn65.C
@@ -0,0 +1,10 @@
+// PR c++/106893
+// { dg-do compile { target c++14 } }
+
+template 
+struct CoordTraits
+{
+  static auto GetX(T const ) { return 1; }
+};
+typedef CoordTraits Traits;
+static constexpr auto GetX = Traits::GetX;

base-commit: 7c989a8ed47228bdd494a2f0d1f6fdd325f953d7
prerequisite-patch-id: cc4d1e7bcdd804ea5a1a64ea9a138d9279e5eaa8
-- 
2.31.1

[pushed] c++: cast to array of unknown bound [PR93259]

[Jason Merrill via Gcc-patches]

We already know to treat a variable of array-of-unknown-bound type as
dependent, we should do the same for arr{}.

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

PR c++/93259

gcc/cp/ChangeLog:

* pt.cc (type_dependent_expression_p): Treat a compound
literal of array-of-unknown-bound type like a variable.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/initlist-array17.C: New test.
---
 gcc/cp/pt.cc  |  6 +--
 gcc/testsuite/g++.dg/cpp0x/initlist-array17.C | 37 +++
 2 files changed, 40 insertions(+), 3 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/initlist-array17.C

diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
index ad9c2f9b180..31e3e391098 100644
--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -28082,11 +28082,11 @@ type_dependent_expression_p (tree expression)
  If the array has no length and has an initializer, it must be that
  we couldn't determine its length in cp_complete_array_type because
  it is dependent.  */
-  if (VAR_P (expression)
+  if (((VAR_P (expression) && DECL_INITIAL (expression))
+   || COMPOUND_LITERAL_P (expression))
   && TREE_TYPE (expression) != NULL_TREE
   && TREE_CODE (TREE_TYPE (expression)) == ARRAY_TYPE
-  && !TYPE_DOMAIN (TREE_TYPE (expression))
-  && DECL_INITIAL (expression))
+  && !TYPE_DOMAIN (TREE_TYPE (expression)))
return true;
 
   /* Pull a FUNCTION_DECL out of a BASELINK if we can.  */
diff --git a/gcc/testsuite/g++.dg/cpp0x/initlist-array17.C 
b/gcc/testsuite/g++.dg/cpp0x/initlist-array17.C
new file mode 100644
index 000..c4284a7b391
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/initlist-array17.C
@@ -0,0 +1,37 @@
+// PR c++/93259
+// { dg-do compile { target c++11 } }
+
+template  struct is_same;
+template  struct is_same { };
+
+using Array = int[];
+
+template 
+void bar1(Ts ...)
+{
+  auto && array = Array{ 1, 2, 3 };
+
+  is_same{}; // this fails, deduces array as int 
(&&) []
+}
+
+template 
+void bar2()
+{
+  auto && array = Array{ 1, 2, 3 };
+
+  is_same{};  // this fails, deduces array as 
int (&&) []
+}
+
+void bar3()
+{
+  auto && array = Array{ 1, 2, 3 };
+
+  is_same{}; // OK
+}
+
+int main()
+{
+  bar1(1, 2, 3);
+  bar2();
+  bar3();
+}

base-commit: 7c989a8ed47228bdd494a2f0d1f6fdd325f953d7
-- 
2.31.1

Re: [PATCH] c++: Implement P1467R9 - Extended floating-point types and standard names compiler part except for bfloat16 [PR106652]

[Joseph Myers]

On Mon, 12 Sep 2022, Jakub Jelinek via Gcc-patches wrote:

> Now, I guess for the fixincludes it could also use
> #  if !__GNUC_PREREQ (7, 0) || (defined __cplusplus && !__GNUC_PREREQ (13, 0))
> where earlier GCC 13 snapshots would not be doing the fixincludes,
> but the question is what to use for upstream glibc, because
> there will be 13.0 snapshots where C++ doesn't support _Float{16,32,64,128}
> and where it is essential to use what glibc has been doing previously
> and using the #else would fail miserably, and then 13.0 snapshots where it
> does support it and where using the if would fail miserably.

We don't claim in glibc to support old snapshots from master, so checking 
for __GNUC_PREREQ (13, 0) and failing for such older GCC 13 versions is 
fine.

> Conversion from BFmode to SFmode is easy, left shift by 16 and ought to be
> implemented inline, SFmode -> BFmode conversion is harder,

Properly the right way for converting from BFmode to SFmode in the 
presence of -fsignaling-nans should depend on how the result is used.  If 
it's used for arithmetic, it's OK to have converted a BFmode signaling NaN 
to an SFmode signaling NaN, but if e.g. the result is examined with 
issignaling or otherwise stored so it may be significant later whether the 
result is a quiet or signaling NaN, IEEE semantics would mean a signaling 
NaN should be a converted to a quiet NaN with "invalid" raised.  Though I 
don't know how far hardware instructions for BFmode attempt to follow IEEE 
semantics.

(Cf. powerpc single-precision load instructions whose effect is defined as 
a purely bitwise conversion from single to double precision, so that 
single-precision load and store of a signaling NaN never end up converting 
it to a quiet NaN even though the in-register format is double precision.)

> (untested) and the question is if it should be implemented in libgcc
> (and using soft-fp or not), or inline, or both depending on -Os.

Also if you try to do a direct conversion between BFmode and HFmode, 
soft-fp's current support for conversions may not handle that case (where 
one type has wider exponent range and other type has higher precision).

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

Re: [PATCH 2/2] xtensa: Implement new target hook: TARGET_CONSTANT_OK_FOR_CPROP_P

[Max Filippov via Gcc-patches]

On Sun, Sep 11, 2022 at 1:50 PM Takayuki 'January June' Suwa
 wrote:
>
> This patch implements new target hook TARGET_CONSTANT_OK_FOR_CPROP_P in
> order to exclude CONST_INTs that cannot fit into a MOVI machine instruction
> from cprop.
>
> gcc/ChangeLog:
>
> * config/xtensa/xtensa.c (TARGET_CONSTANT_OK_FOR_CPROP_P):
> New macro definition.
> (xtensa_constant_ok_for_cprop_p):
> Implement the hook as mentioned above.
> ---
>  gcc/config/xtensa/xtensa.cc | 20 +---
>  1 file changed, 17 insertions(+), 3 deletions(-)

Regtested for target=xtensa-linux-uclibc, no new regressions.
Committed to master.

-- 
Thanks.
-- Max

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

[Michael Meissner via Gcc-patches]

I submitted a new patch that rewrites what this patch was trying to do.  I
didn't see the original version I submitted on September 8th, so I just
reposted it.

https://gcc.gnu.org/pipermail/gcc-patches/2022-September/601504.html

-- 
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meiss...@linux.ibm.com

[PATCH] Update float 128-bit conversions

[Michael Meissner via Gcc-patches]

I had sent this out on Thrusday, but it doesn't seem to have gone out.

This patch is a rewrite of the patch submitted on August 18th:

| https://gcc.gnu.org/pipermail/gcc-patches/2022-August/599988.html

This patch reworks the conversions between 128-bit binary floating point types.
Previously, we would call rs6000_expand_float128_convert to do all conversions.
Now, we only define the conversions between the same representation that turn
into a NOP.  The appropriate extend or truncate insn is generated, and after
register allocation, it is converted to a move.

This patch also fixes two places where we want to override the external name
for the conversion function, and the wrong optab was used.  Previously,
rs6000_expand_float128_convert would handle the move or generate the call as
needed.  Now, it lets the machine independent code generate the call.  But if
we use the machine independent code to generate the call, we need to update the
name for two optabs where a truncate would be used in terms of converting
between the modes.  This patch updates those two optabs.

While I know you feel the whole area needs to be rewritten, I would think it is
better to make things work incrementally rather than waiting for some grand
rewrite (that may or may not occur).

With the current sources, we don't yet need this patch.  But we will need this
patch when a future patch is submitted that will change the internal __float128
type to use the _Float128 type when long double is IEEE 128-bit.  I'm trying to
break out the smaller patches that each can stand alone, without having a
single larger patch.  This future patch will fix various testsuite issues with
signalling NaNs when long double is IEEE 128-bit.

I tested this patch on:

1)  LE Power10 using --with-cpu=power10 --with-long-double-format=ieee
2)  LE Power10 using --with-cpu=power9  --with-long-double-format=ibm
3)  LE Power10 using --with-cpu=power8  --with-long-double-format=ibm
4)  LE Power10 using --with-cpu=power10 --with-long-double-format=ibm
5)  LE Power9  using --with-cpu=power9  --with-long-double-format=ibm
6)  BE Power7  using --with-cpu=power7  --with-long-double-format=ibm

There were no regressions in the bootstrap process or running the tests.  Can I
check this patch into the trunk?

2022-09-08   Michael Meissner  

gcc/

* config/rs6000/rs6000.cc (init_float128_ieee): Use the correct
float_extend or float_truncate optab based on how the machine converts
between IEEE 128-bit and IBM 128-bit.
* config/rs6000/rs6000.md (IFKF): Delete.
(IFKF_reg): Delete.
(extendiftf2): Rewrite to be a move if IFmode and TFmode are both IBM
128-bit.  Do not run if TFmode is IEEE 128-bit.
(extendifkf2): Delete.
(extendtfkf2): Delete.
(extendtfif2): Delete.
(trunciftf2): Delete.
(truncifkf2): Delete.
(trunckftf2): Delete.
(extendkftf2): Implement conversion of IEEE 128-bit types as a move.
(trunctfif2): Delete.
(trunctfkf2): Implement conversion of IEEE 128-bit types as a move.
(extendtf2_internal): Delete.
(extendtf2_internal): Delete.
---
 gcc/config/rs6000/rs6000.cc |   4 +-
 gcc/config/rs6000/rs6000.md | 177 ++--
 2 files changed, 50 insertions(+), 131 deletions(-)

diff --git a/gcc/config/rs6000/rs6000.cc b/gcc/config/rs6000/rs6000.cc
index a656cb32a47..6f822434ab0 100644
--- a/gcc/config/rs6000/rs6000.cc
+++ b/gcc/config/rs6000/rs6000.cc
@@ -11045,11 +11045,11 @@ init_float128_ieee (machine_mode mode)
   set_conv_libfunc (trunc_optab, SFmode, mode, "__trunckfsf2");
   set_conv_libfunc (trunc_optab, DFmode, mode, "__trunckfdf2");
 
-  set_conv_libfunc (sext_optab, mode, IFmode, "__trunctfkf2");
+  set_conv_libfunc (trunc_optab, mode, IFmode, "__trunctfkf2");
   if (mode != TFmode && FLOAT128_IBM_P (TFmode))
set_conv_libfunc (sext_optab, mode, TFmode, "__trunctfkf2");
 
-  set_conv_libfunc (trunc_optab, IFmode, mode, "__extendkftf2");
+  set_conv_libfunc (sext_optab, IFmode, mode, "__extendkftf2");
   if (mode != TFmode && FLOAT128_IBM_P (TFmode))
set_conv_libfunc (trunc_optab, TFmode, mode, "__extendkftf2");
 
diff --git a/gcc/config/rs6000/rs6000.md b/gcc/config/rs6000/rs6000.md
index ad5a4cf2ef8..838d38616b7 100644
--- a/gcc/config/rs6000/rs6000.md
+++ b/gcc/config/rs6000/rs6000.md
@@ -543,12 +543,6 @@ (define_mode_iterator FMOVE128_GPR [TI
 ; Iterator for 128-bit VSX types for pack/unpack
 (define_mode_iterator FMOVE128_VSX [V1TI KF])
 
-; Iterators for converting to/from TFmode
-(define_mode_iterator IFKF [IF KF])
-
-; Constraints for moving IF/KFmode.
-(define_mode_attr IFKF_reg [(IF "d") (KF "wa")])
-
 ; Whether a floating point move is ok, don't allow SD without hardware FP
 (define_mode_attr fmove_ok [(SF "")
(DF "")
@@ -9097,106 +9091,65 @@ (define_insn 

Re: [PATCH] Implement known/maybe fpclassify like API for frange.

[Jan-Benedict Glaw]

Hi Aldy!

On Mon, 2022-09-12 15:12:46 +0200, Aldy Hernandez  wrote:
> On Mon, Sep 12, 2022 at 10:48 AM Jan-Benedict Glaw  wrote:
> >
> > On Thu, 2022-09-08 12:56:24 +0200, Aldy Hernandez via Gcc-patches 
> >  wrote:
> >
> > > From 795baa0b044953e9f198f49e379374d633f43b47 Mon Sep 17 00:00:00 2001
> > > From: Aldy Hernandez 
> > > Date: Thu, 8 Sep 2022 08:11:43 +0200
> > > Subject: [PATCH] Implement known/maybe fpclassify like API for frange.
> > >
> > > gcc/ChangeLog:
[...]
> > > ---
> > >  gcc/gimple-range-fold.cc |  19 +++---
> > >  gcc/range-op-float.cc|  26 
> > >  gcc/value-range.cc   | 126 +++
> > >  gcc/value-range.h|  78 +++-
> > >  4 files changed, 170 insertions(+), 79 deletions(-)
> >
> > This triggers a selftest failure for pdp11:
> >
> > .../gcc/configure --prefix=... --enable-werror-always 
> > --enable-languages=all --disable-gcov --disable-shared --disable-threads 
> > --target=pdp11-aout --without-headers
> 
> I have just pushed a patch to fix this.
> 
> I have also added -ffinite-math-only selftests to my list of testing
> requirements for all future frange work.
> 
> Thanks for reporting this.

Thanks for the very quick fix, already confirmed here!

MfG, JBG

-- 


signature.asc
Description: PGP signature

Re: [PATCH 1/4] libstdc++: Add already-accepted testcase [PR106320]

[Jonathan Wakely via Gcc-patches]

On Mon, 12 Sep 2022, 17:46 Patrick Palka via Libstdc++, <
libstd...@gcc.gnu.org> wrote:

> Although PR106320 only affected the 10 and 11 branches, and the testcase
> from there was already correctly accepted on trunk and the 12 branch, we
> should also add the testcase to 12/trunk for inter-branch consistency.
>
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk/12?
>

Yes, good idea to add this.



> PR libstdc++/106320
>
> libstdc++-v3/ChangeLog:
>
> * testsuite/std/ranges/adaptors/join.cc (test13): New test.
> ---
>  libstdc++-v3/testsuite/std/ranges/adaptors/join.cc | 13 +
>  1 file changed, 13 insertions(+)
>
> diff --git a/libstdc++-v3/testsuite/std/ranges/adaptors/join.cc
> b/libstdc++-v3/testsuite/std/ranges/adaptors/join.cc
> index 8986f718229..530ab6663b5 100644
> --- a/libstdc++-v3/testsuite/std/ranges/adaptors/join.cc
> +++ b/libstdc++-v3/testsuite/std/ranges/adaptors/join.cc
> @@ -205,6 +205,18 @@ test12()
>}();
>  }
>
> +void
> +test13()
> +{
> +  // PR libstdc++/106320
> +  auto l = std::views::transform([](auto x) {
> +return x | std::views::transform([i=0](auto y) {
> +  return y;
> +});
> +  });
> +  std::vector> v{{5, 6, 7}};
> +  v | l | std::views::join;
> +}
>  int
>  main()
>  {
> @@ -220,4 +232,5 @@ main()
>test10();
>test11();
>test12();
> +  test13();
>  }
> --
> 2.37.3.542.gdd3f6c4cae
>
>

Re: [PATCH] PR rtl-optimization/106594: Preserve zero_extend when cheap.

[Segher Boessenkool]

On Mon, Sep 12, 2022 at 11:47:47AM -0500, Segher Boessenkool wrote:
> On Mon, Sep 12, 2022 at 12:40:31AM +0100, Roger Sayle wrote:
> > * gcc/combine.cc (expand_compound_operation): Don't expand/transform
> > ZERO_EXTEND or SIGN_EXTEND on targets where rtx_cost claims they are
> > cheap.  If gen_lowpart returns a SUBREG of something other than a
> > REG or a MEM, i.e. invalid RTL, return the original expression.
> 
> This needs testing and analysis on all platforms.

Btw.  This then needs to be of only the combine change.  Importantly not
the simplify changes, which should be a separate patch anyway: they
should be an improvment always (otherwise they are not okay anyway!)

The i386 patches should be separate and probably can be committed first,
too?  I haven't looked at those target things.

Other target will probably want changes as well?


Segher

Re: [PATCH v3] eliminate mutex in fast path of __register_frame

[Thomas Neumann via Gcc-patches]

Thanks for your feedback, I will update the patch in the next few days, 
addressing the comments and reorganizing classify_object_over_fdes. 
Concerning your question:



+
+restart:
+  struct btree_node *iter;
+  uintptr_t lock;
+  {
+    // Accessing the root node requires defending against concurrent 
pointer
+    // changes Thus we couple rootLock -> lock on root node -> 
validate rootLock


Can you elaborate a bit more in the comment on why it's necessary and 
sufficient to validate the containing node after "locking" the child node?



+    if (!version_lock_lock_optimistic (&(t->root_lock), ))
+  goto restart;
+    iter = RLOAD (t->root);
+    if (!version_lock_validate (&(t->root_lock), lock))
+  goto restart;
+    if (!iter)
+  return NULL;
+    uintptr_t child_lock;
+    if ((!btree_node_lock_optimistic (iter, _lock))
+    || (!version_lock_validate (&(t->root_lock), lock)))
+  goto restart;
+    lock = child_lock;
+  }
+
+  // Now we can walk down towards the right leaf node


We are reading here without explicit locks, i.e., memory can change 
behind our back at any time. Thus, before we act on a value that we have 
read, we must check if that value is still valid.

The invariants that we rely upon are:
I1) a node pointer will always be either a nullptr or point to a b-tree 
node. The node might have been logically deleted, but the memory will 
always remain valid due to our free list.
I2) The root pointer is only modified by a thread that holds an 
exclusive lock on root_lock.
I3) valide calls fail if a) somebody else currently holds the lock, or 
b) if the version value has changed since locking, which happens when 
somebody releases an exlusive lock.


Using that, the code does the following steps

1. We lock root_lock optimistic. In case of an exclusive lock we restart 
immediately, otherwise we remember the current version
2. We load the root pointer and store it in iter. iter might contain 
arbitrary garbage due to races
3. We validate the root_lock, and restart in case of errors. Now we know 
that a) nobody has locked the root exclusively or modified it since step 
1 (I3), and b) iter indeed points to the node that corresponds the to 
the version that we have read in step 1 (due to I2)


At this point we now that iter is indeed the right root pointer. If it 
is a nullptr we stop here. Otherwise we continue with


4. We lock the root node itself (iter), storing the validated version in 
child_lock. We need that lock to detect changes to the content of the 
root, the root_lock only protects the pointer to the root. Loading the 
lock is safe due to I1. As our tree can change at any point in time, we 
need another valide call on root_lock to make sure that we still have 
the right root pointer.



At this point we have both a pointer to the root node and an optimistic 
lock that allows us to detect changes to the content of the root. Thus, 
we can safely navigate down, any changes to the b-tree that could affect 
us, like, e.g., node splits in the root, will be detected when 
validating the lock.



I hope that answered both the necessary and sufficient part. As a 
general rule, you must always use the pair relax-atomic-read + validate 
to avoid data races. Acting on any value that you have not validated is 
unsafe, as you could get races.


Best

Thomas

[PATCH] c++: lambda capture of array with deduced bounds [PR106567]

[Jason Merrill via Gcc-patches]

We can't use the type of an array variable directly if we haven't deduced
its length yet.

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

PR c++/106567

gcc/cp/ChangeLog:

* lambda.cc (type_deducible_expression_p): Check
array_of_unknown_bound_p.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/lambda/lambda-array4.C: New test.
---
 gcc/cp/lambda.cc  |  1 +
 .../g++.dg/cpp0x/lambda/lambda-array4.C   | 29 +++
 2 files changed, 30 insertions(+)
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/lambda/lambda-array4.C

diff --git a/gcc/cp/lambda.cc b/gcc/cp/lambda.cc
index 3fb98a98057..3ee1fe9489e 100644
--- a/gcc/cp/lambda.cc
+++ b/gcc/cp/lambda.cc
@@ -198,6 +198,7 @@ type_deducible_expression_p (tree expr)
   tree t = non_reference (TREE_TYPE (expr));
   return (t && TREE_CODE (t) != TYPE_PACK_EXPANSION
  && !WILDCARD_TYPE_P (t) && !LAMBDA_TYPE_P (t)
+ && !array_of_unknown_bound_p (t)
  && !type_uses_auto (t));
 }
 
diff --git a/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-array4.C 
b/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-array4.C
new file mode 100644
index 000..94ec7f8457e
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-array4.C
@@ -0,0 +1,29 @@
+// PR c++/106567
+// { dg-do compile { target c++11 } }
+
+template 
+void urgh()
+{
+const V x[] = {V(0), V(1), V(2), V(0)};
+
+[&]() {
+for (auto& v : x) {}
+}();
+}
+
+void no_urgh()
+{
+using V = int;
+
+const V x[] = {V(0), V(1), V(2), V(0)};
+
+[&]() {
+for (auto& v : x) {}
+}();
+}
+
+int main()
+{
+no_urgh();
+urgh();
+}

base-commit: 8ef5fa4c56c82dfbd6e8fc5e4e08c4be843abc3e
-- 
2.31.1

[PATCH] libstdc++: Squelch -Wparentheses warning with debug iterators

[Patrick Palka via Gcc-patches]

I noticed compiling e.g. std/ranges/adaptors/join.cc with
-D_GLIBCXX_DEBUG -Wsystem-headers -Wall gives the warning:

  gcc/libstdc++-v3/include/debug/safe_iterator.h:477:9: warning: suggest 
parentheses around ‘&&’ within ‘||’ [-Wparentheses]

Tested on x86_64-pc-linux-gnu, does this look OK for trunk?

libstdc++-v3/ChangeLog:

* include/debug/safe_iterator.h (_GLIBCXX_DEBUG_VERIFY_OPERANDS):
Add parentheses to squelch -Wparentheses.
---
 libstdc++-v3/include/debug/safe_iterator.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libstdc++-v3/include/debug/safe_iterator.h 
b/libstdc++-v3/include/debug/safe_iterator.h
index 33f7a86478a..117dc93de60 100644
--- a/libstdc++-v3/include/debug/safe_iterator.h
+++ b/libstdc++-v3/include/debug/safe_iterator.h
@@ -40,7 +40,7 @@
 #endif
 
 #define _GLIBCXX_DEBUG_VERIFY_OPERANDS(_Lhs, _Rhs, _BadMsgId, _DiffMsgId) \
-  _GLIBCXX_DEBUG_VERIFY(!_Lhs._M_singular() && !_Rhs._M_singular() \
+  _GLIBCXX_DEBUG_VERIFY((!_Lhs._M_singular() && !_Rhs._M_singular())   \
|| (_Lhs._M_value_initialized() \
&& _Rhs._M_value_initialized()),\
_M_message(_BadMsgId)   \
-- 
2.37.3.542.gdd3f6c4cae

Re: [PATCH] PR rtl-optimization/106594: Preserve zero_extend when cheap.

[Segher Boessenkool]

Hi!

On Mon, Sep 12, 2022 at 12:40:31AM +0100, Roger Sayle wrote:
> * gcc/combine.cc (expand_compound_operation): Don't expand/transform
> ZERO_EXTEND or SIGN_EXTEND on targets where rtx_cost claims they are
> cheap.  If gen_lowpart returns a SUBREG of something other than a
> REG or a MEM, i.e. invalid RTL, return the original expression.

This needs testing and analysis on all platforms.

> @@ -7309,7 +7319,11 @@ expand_compound_operation (rtx x)
>if (modewidth >= pos + len)
>  {
>tem = gen_lowpart (mode, XEXP (x, 0));
> -  if (!tem || GET_CODE (tem) == CLOBBER)
> +  if (!tem
> +   || GET_CODE (tem) == CLOBBER
> +   || (GET_CODE (tem) == SUBREG
> +   && !REG_P (SUBREG_REG (tem))
> +   && !MEM_P (SUBREG_REG (tem
>   return x;

Why handle subregs of memory here?  Those are antiquated, and should go
away pretty soon.

All of {expand,make}_compound_operation should be removed.  But this is
non-trivial work.  All of {SIGN,ZERO}_EXTRACT should be eradicated as
well, in my opinion.


Segher

[PATCH 4/4] libstdc++: Implement ranges::slide_view from P2442R1

[Patrick Palka via Gcc-patches]

This also implements the LWG 3711 and 3712 changes to slide_view.

libstdc++-v3/ChangeLog:

* include/std/ranges (__detail::__slide_caches_nothing): Define.
(__detail::__slide_caches_last): Define.
(__detail::__slide_caches_first): Define.
(slide_view): Define.
(enable_borrowed_range): Define.
(slide_view::_Iterator): Define.
(slide_view::_Sentinel): Define.
(views::__detail::__can_slide_view): Define.
(views::_Slide, views::slide): Define.
* testsuite/std/ranges/adaptors/slide/1.cc: New test.
---
 libstdc++-v3/include/std/ranges   | 364 ++
 .../testsuite/std/ranges/adaptors/slide/1.cc  | 105 +
 2 files changed, 469 insertions(+)
 create mode 100644 libstdc++-v3/testsuite/std/ranges/adaptors/slide/1.cc

diff --git a/libstdc++-v3/include/std/ranges b/libstdc++-v3/include/std/ranges
index 7533b60c1d6..bbe4fa278d2 100644
--- a/libstdc++-v3/include/std/ranges
+++ b/libstdc++-v3/include/std/ranges
@@ -6314,6 +6314,370 @@ namespace views::__adaptor
 inline constexpr _Chunk chunk;
   }
 
+  namespace __detail
+  {
+template
+  concept __slide_caches_nothing = random_access_range<_Vp> && 
sized_range<_Vp>;
+
+template
+  concept __slide_caches_last
+  = !__slide_caches_nothing<_Vp> && bidirectional_range<_Vp> && 
common_range<_Vp>;
+
+template
+  concept __slide_caches_first
+  = !__slide_caches_nothing<_Vp> && !__slide_caches_last<_Vp>;
+  }
+
+  template
+requires view<_Vp>
+  class slide_view : public view_interface>
+  {
+_Vp _M_base;
+range_difference_t<_Vp> _M_n;
+[[no_unique_address]]
+  __detail::__maybe_present_t<__detail::__slide_caches_first<_Vp>,
+ __detail::_CachedPosition<_Vp>> 
_M_cached_begin;
+[[no_unique_address]]
+  __detail::__maybe_present_t<__detail::__slide_caches_last<_Vp>,
+ __detail::_CachedPosition<_Vp>> _M_cached_end;
+
+template class _Iterator;
+class _Sentinel;
+
+  public:
+constexpr explicit
+slide_view(_Vp __base, range_difference_t<_Vp> __n)
+: _M_base(std::move(__base)), _M_n(__n)
+{ __glibcxx_assert(__n > 0); }
+
+constexpr auto
+begin() requires (!(__detail::__simple_view<_Vp>
+   && __detail::__slide_caches_nothing))
+{
+  if constexpr (__detail::__slide_caches_first<_Vp>)
+   {
+ iterator_t<_Vp> __it;
+ if (_M_cached_begin._M_has_value())
+   __it = _M_cached_begin._M_get(_M_base);
+ else
+   {
+ __it = ranges::next(ranges::begin(_M_base), _M_n - 1, 
ranges::end(_M_base));
+ _M_cached_begin._M_set(_M_base, __it);
+   }
+ return _Iterator(ranges::begin(_M_base), std::move(__it), 
_M_n);
+   }
+  else
+   return _Iterator(ranges::begin(_M_base), _M_n);
+}
+
+constexpr auto
+begin() const requires __detail::__slide_caches_nothing
+{ return _Iterator(ranges::begin(_M_base), _M_n); }
+
+constexpr auto
+end() requires (!(__detail::__simple_view<_Vp>
+ && __detail::__slide_caches_nothing))
+{
+  if constexpr (__detail::__slide_caches_nothing<_Vp>)
+   return _Iterator(ranges::begin(_M_base) + 
range_difference_t<_Vp>(size()),
+   _M_n);
+  else if constexpr (__detail::__slide_caches_last<_Vp>)
+   {
+ iterator_t<_Vp> __it;
+ if (_M_cached_end._M_has_value())
+   __it = _M_cached_end._M_get(_M_base);
+ else
+   {
+ __it = ranges::prev(ranges::end(_M_base), _M_n - 1,
+ ranges::begin(_M_base));
+ _M_cached_end._M_set(_M_base, __it);
+   }
+ return _Iterator(std::move(__it), _M_n);
+   }
+  else if constexpr (common_range<_Vp>)
+   return _Iterator(ranges::end(_M_base), ranges::end(_M_base), 
_M_n);
+  else
+   return _Sentinel(ranges::end(_M_base));
+}
+
+constexpr auto
+end() const requires __detail::__slide_caches_nothing
+{ return begin() + range_difference_t(size()); }
+
+constexpr auto
+size() requires sized_range<_Vp>
+{
+  auto __sz = ranges::distance(_M_base) - _M_n + 1;
+  if (__sz < 0)
+   __sz = 0;
+  return __detail::__to_unsigned_like(__sz);
+}
+
+constexpr auto
+size() const requires sized_range
+{
+  auto __sz = ranges::distance(_M_base) - _M_n + 1;
+  if (__sz < 0)
+   __sz = 0;
+  return __detail::__to_unsigned_like(__sz);
+}
+  };
+
+  template
+slide_view(_Range&&, range_difference_t<_Range>) -> 
slide_view>;
+
+  template
+inline constexpr bool enable_borrowed_range>
+  = enable_borrowed_range<_Vp>;
+
+  template
+requires view<_Vp>
+  template
+  class slide_view<_Vp>::_Iterator
+  {
+using _Base = __detail::__maybe_const_t<_Const, _Vp>;
+static 

[PATCH 2/4] libstdc++: Implement LWG 3569 changes to join_view::_Iterator

[Patrick Palka via Gcc-patches]

Tested on x86_64-pc-linux-gnu, does this look OK for trunk only?

libstdc++-v3/ChangeLog:

* include/std/ranges (join_view::_Iterator::_M_satisfy):
Adjust resetting _M_inner as per LWG 3569.
(join_view::_Iterator::_M_inner): Wrap in std::optional
as per LWG 3569.
(join_view::_Iterator::_Iterator): Relax constraints as
per LWG 3569.
(join_view::_Iterator::operator*): Adjust as per LWG 3569.
(join_view::_Iterator::operator->): Likewise.
(join_view::_Iterator::operator++): Likewise.
(join_view::_Iterator::operator--): Likewise.
(join_view::_Iterator::iter_move): Likewise.
(join_view::_Iterator::iter_swap): Likewise.
* testsuite/std/ranges/adaptor/join.cc (test14): New test.
---
 libstdc++-v3/include/std/ranges   | 28 +--
 .../testsuite/std/ranges/adaptors/join.cc | 17 +++
 2 files changed, 30 insertions(+), 15 deletions(-)

diff --git a/libstdc++-v3/include/std/ranges b/libstdc++-v3/include/std/ranges
index 20eb4e82ac8..6297ce7cee3 100644
--- a/libstdc++-v3/include/std/ranges
+++ b/libstdc++-v3/include/std/ranges
@@ -2746,7 +2746,7 @@ namespace views::__adaptor
  }
 
if constexpr (_S_ref_is_glvalue)
- _M_inner = _Inner_iter();
+ _M_inner.reset();
  }
 
  static constexpr auto
@@ -2769,7 +2769,7 @@ namespace views::__adaptor
  using _Inner_iter = join_view::_Inner_iter<_Const>;
 
  _Outer_iter _M_outer = _Outer_iter();
- _Inner_iter _M_inner = _Inner_iter();
+ optional<_Inner_iter> _M_inner;
  _Parent* _M_parent = nullptr;
 
public:
@@ -2780,9 +2780,7 @@ namespace views::__adaptor
= common_type_t,
range_difference_t>>;
 
- _Iterator() requires (default_initializable<_Outer_iter>
-   && default_initializable<_Inner_iter>)
-   = default;
+ _Iterator() requires default_initializable<_Outer_iter> = default;
 
  constexpr
  _Iterator(_Parent* __parent, _Outer_iter __outer)
@@ -2801,7 +2799,7 @@ namespace views::__adaptor
 
  constexpr decltype(auto)
  operator*() const
- { return *_M_inner; }
+ { return **_M_inner; }
 
  // _GLIBCXX_RESOLVE_LIB_DEFECTS
  // 3500. join_view::iterator::operator->() is bogus
@@ -2809,7 +2807,7 @@ namespace views::__adaptor
  operator->() const
requires __detail::__has_arrow<_Inner_iter>
  && copyable<_Inner_iter>
- { return _M_inner; }
+ { return *_M_inner; }
 
  constexpr _Iterator&
  operator++()
@@ -2820,7 +2818,7 @@ namespace views::__adaptor
  else
return *_M_parent->_M_inner;
}();
-   if (++_M_inner == ranges::end(__inner_range))
+   if (++*_M_inner == ranges::end(__inner_range))
  {
++_M_outer;
_M_satisfy();
@@ -2850,9 +2848,9 @@ namespace views::__adaptor
  {
if (_M_outer == ranges::end(_M_parent->_M_base))
  _M_inner = ranges::end(*--_M_outer);
-   while (_M_inner == ranges::begin(*_M_outer))
- _M_inner = ranges::end(*--_M_outer);
-   --_M_inner;
+   while (*_M_inner == ranges::begin(*_M_outer))
+ *_M_inner = ranges::end(*--_M_outer);
+   --*_M_inner;
return *this;
  }
 
@@ -2879,14 +2877,14 @@ namespace views::__adaptor
 
  friend constexpr decltype(auto)
  iter_move(const _Iterator& __i)
- noexcept(noexcept(ranges::iter_move(__i._M_inner)))
- { return ranges::iter_move(__i._M_inner); }
+ noexcept(noexcept(ranges::iter_move(*__i._M_inner)))
+ { return ranges::iter_move(*__i._M_inner); }
 
  friend constexpr void
  iter_swap(const _Iterator& __x, const _Iterator& __y)
-   noexcept(noexcept(ranges::iter_swap(__x._M_inner, __y._M_inner)))
+   noexcept(noexcept(ranges::iter_swap(*__x._M_inner, *__y._M_inner)))
requires indirectly_swappable<_Inner_iter>
- { return ranges::iter_swap(__x._M_inner, __y._M_inner); }
+ { return ranges::iter_swap(*__x._M_inner, *__y._M_inner); }
 
  friend _Iterator;
  template friend struct _Sentinel;
diff --git a/libstdc++-v3/testsuite/std/ranges/adaptors/join.cc 
b/libstdc++-v3/testsuite/std/ranges/adaptors/join.cc
index 530ab6663b5..afc11d4bd7a 100644
--- a/libstdc++-v3/testsuite/std/ranges/adaptors/join.cc
+++ b/libstdc++-v3/testsuite/std/ranges/adaptors/join.cc
@@ -21,6 +21,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -217,6 +218,21 @@ test13()
   std::vector> v{{5, 6, 7}};
   v | l | std::views::join;
 }
+
+void
+test14()
+{
+  // LWG 3569: join_view fails to support ranges of ranges with
+  // 

[PATCH 3/4] libstdc++: Implement ranges::chunk_view from P2442R1

[Patrick Palka via Gcc-patches]

This also implements the LWG 3707, 3710 and 3712 changes to chunk_view.

libstdc++-v3/ChangeLog:

* include/std/ranges (__detail::__div_ceil): Define.
(chunk_view): Define.
(chunk_view::_OuterIter): Define.
(chunk_view::_OuterIter::value_type): Define.
(chunk_view::_InnerIter): Define.
(chunk_view<_Vp>): Define partial specialization for forward
ranges.
(enable_borrowed_range): Define.
(chunk_view<_Vp>::_Iterator): Define.
(views::__detail::__can_chunk_view): Define.
(views::_Chunk, views::chunk): Define.
* testsuite/std/ranges/adaptors/chunk/1.cc: New test.
---
 libstdc++-v3/include/std/ranges   | 538 ++
 .../testsuite/std/ranges/adaptors/chunk/1.cc  |  80 +++
 2 files changed, 618 insertions(+)
 create mode 100644 libstdc++-v3/testsuite/std/ranges/adaptors/chunk/1.cc

diff --git a/libstdc++-v3/include/std/ranges b/libstdc++-v3/include/std/ranges
index 6297ce7cee3..7533b60c1d6 100644
--- a/libstdc++-v3/include/std/ranges
+++ b/libstdc++-v3/include/std/ranges
@@ -5776,6 +5776,544 @@ namespace views::__adaptor
 
 inline constexpr auto pairwise_transform = adjacent_transform<2>;
   }
+
+  namespace __detail
+  {
+template
+constexpr _Tp __div_ceil(_Tp __num, _Tp __denom)
+{
+  _Tp __r = __num / __denom;
+  if (__num % __denom)
+   ++__r;
+  return __r;
+}
+  }
+
+  template
+requires input_range<_Vp>
+  class chunk_view : public view_interface>
+  {
+_Vp _M_base;
+range_difference_t<_Vp> _M_n;
+range_difference_t<_Vp> _M_remainder = 0;
+__detail::__non_propagating_cache> _M_current;
+
+class _OuterIter;
+class _InnerIter;
+
+  public:
+constexpr explicit
+chunk_view(_Vp __base, range_difference_t<_Vp> __n)
+  : _M_base(std::move(__base)), _M_n(__n)
+{ __glibcxx_assert(__n >= 0); }
+
+constexpr _Vp
+base() const & requires copy_constructible<_Vp>
+{ return _M_base; }
+
+constexpr _Vp
+base() &&
+{ return std::move(_M_base); }
+
+constexpr _OuterIter
+begin()
+{
+  _M_current = ranges::begin(_M_base);
+  _M_remainder = _M_n;
+  return _OuterIter(*this);
+}
+
+constexpr default_sentinel_t
+end() const noexcept
+{ return default_sentinel; }
+
+constexpr auto
+size() requires sized_range<_Vp>
+{
+  return __detail::__to_unsigned_like(__detail::__div_ceil
+ (ranges::distance(_M_base), _M_n));
+}
+
+constexpr auto
+size() const requires sized_range
+{
+  return __detail::__to_unsigned_like(__detail::__div_ceil
+ (ranges::distance(_M_base), _M_n));
+}
+  };
+
+  template
+chunk_view(_Range&&, range_difference_t<_Range>) -> 
chunk_view>;
+
+  template
+requires input_range<_Vp>
+  class chunk_view<_Vp>::_OuterIter
+  {
+chunk_view* _M_parent;
+
+constexpr explicit
+_OuterIter(chunk_view& __parent)
+  : _M_parent(std::__addressof(__parent))
+{ }
+
+friend chunk_view;
+
+  public:
+using iterator_concept = input_iterator_tag;
+using difference_type = range_difference_t<_Vp>;
+
+struct value_type;
+
+_OuterIter(_OuterIter&&) = default;
+_OuterIter& operator=(_OuterIter&&) = default;
+
+constexpr value_type
+operator*() const
+{
+  __glibcxx_assert(*this != default_sentinel);
+  return value_type(*_M_parent);
+}
+
+constexpr _OuterIter&
+operator++()
+{
+  __glibcxx_assert(*this != default_sentinel);
+  ranges::advance(*_M_parent->_M_current, _M_parent->_M_remainder,
+ ranges::end(_M_parent->_M_base));
+  _M_parent->_M_remainder = _M_parent->_M_n;
+  return *this;
+}
+
+constexpr void
+operator++(int)
+{ ++*this; }
+
+friend constexpr bool
+operator==(const _OuterIter& __x, default_sentinel_t)
+{
+  return *__x._M_parent->_M_current == ranges::end(__x._M_parent->_M_base)
+   && __x._M_parent->_M_remainder != 0;
+}
+
+friend constexpr difference_type
+operator-(default_sentinel_t, const _OuterIter& __x)
+requires sized_sentinel_for, iterator_t<_Vp>>
+{
+  const auto __dist = ranges::end(__x._M_parent->_M_base) - 
*__x._M_parent->_M_current;
+
+  if (__dist < __x._M_parent->_M_remainder)
+   return __dist == 0 ? 0 : 1;
+
+  return 1 + __detail::__div_ceil(__dist - __x._M_parent->_M_remainder,
+ __x._M_parent->_M_n);
+}
+
+friend constexpr difference_type
+operator-(const _OuterIter& __x, default_sentinel_t __y)
+requires sized_sentinel_for, iterator_t<_Vp>>
+{ return -(__y - __x); }
+  };
+
+  template
+requires input_range<_Vp>
+  struct chunk_view<_Vp>::_OuterIter::value_type : view_interface
+  {
+  private:
+chunk_view* _M_parent;
+
+constexpr explicit
+

[PATCH 1/4] libstdc++: Add already-accepted testcase [PR106320]

[Patrick Palka via Gcc-patches]

Although PR106320 only affected the 10 and 11 branches, and the testcase
from there was already correctly accepted on trunk and the 12 branch, we
should also add the testcase to 12/trunk for inter-branch consistency.

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

PR libstdc++/106320

libstdc++-v3/ChangeLog:

* testsuite/std/ranges/adaptors/join.cc (test13): New test.
---
 libstdc++-v3/testsuite/std/ranges/adaptors/join.cc | 13 +
 1 file changed, 13 insertions(+)

diff --git a/libstdc++-v3/testsuite/std/ranges/adaptors/join.cc 
b/libstdc++-v3/testsuite/std/ranges/adaptors/join.cc
index 8986f718229..530ab6663b5 100644
--- a/libstdc++-v3/testsuite/std/ranges/adaptors/join.cc
+++ b/libstdc++-v3/testsuite/std/ranges/adaptors/join.cc
@@ -205,6 +205,18 @@ test12()
   }();
 }
 
+void
+test13()
+{
+  // PR libstdc++/106320
+  auto l = std::views::transform([](auto x) {
+return x | std::views::transform([i=0](auto y) {
+  return y;
+});
+  });
+  std::vector> v{{5, 6, 7}};
+  v | l | std::views::join;
+}
 int
 main()
 {
@@ -220,4 +232,5 @@ main()
   test10();
   test11();
   test12();
+  test13();
 }
-- 
2.37.3.542.gdd3f6c4cae

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

[Martin Sebor via Gcc-patches]

On 9/6/22 18:28, Qing Zhao wrote:

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.


A minor problem with this phrasing was pointed out in the review
of the Clang option: https://reviews.llvm.org/D126864#inline-1282716
It would be good to avoid it here.  (I think qualifying the sentence
by adding "for the purposes of accessing the elements of such arrays"
might be one way to do it).


 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.



Since the attribute applies to just a single array declaration it
seems that its name should be strict_flex_array (i.e., singular,
without the trailing 's').

Martin



  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| 

Re: [PATCH] testsuite: gluefile file need to be prefixed

[Yvan Roux via Gcc-patches]

On Mon, Sep 12, 2022 at 05:09:57PM +0100, Richard Sandiford wrote:
> Yvan Roux  writes:
> > Hi Richard,
> > On Mon, Sep 12, 2022 at 12:56:52PM +0100, Richard Sandiford via Gcc-patches 
> > wrote:
> >> Torbjörn SVENSSON via Gcc-patches  writes:
> >> > PR/95720
> >> > When the status wrapper is used, the gluefile need to be prefixed with
> >> > -Wl, in order for the test cases to have the dump files with the
> >> > expected names.
> >> >
> >> > gcc/testsuite/ChangeLog:
> >> >
> >> > * gcc/testsuite/lib/g++.exp: Moved gluefile block to after
> >> >   flags have been prefixed for the target_compile call.
> >> > * gcc/testsuite/lib/gcc.exp: Likewise.
> >> > * gcc/testsuite/lib/wrapper.exp: Reset adjusted state flag.
> >> 
> >> I agree this looks right, but I'm curious how you ended up with the
> >> behaviour seen in comment 16.  I thought having:
> >> 
> >> if { [target_info needs_status_wrapper] != "" && [info exists 
> >> gluefile] } {
> >>lappend options "libs=${gluefile}"
> >>lappend options "ldflags=${wrap_flags}"
> >> }
> >> 
> >> before the dg-additional-files-options/gcc_adjusted_linker_flags would
> >> lead to the gluefile missing a "-Wl," first time round.  How is it that
> >> the gluefile still gets the "-Wl," and the -T misses it instead?
> >
> > The issue is that dg-additional-files-options/gcc_adjusted_linker_flags
> > add the "-Wl," prefix to the content of the global variable 
> > and not to the one of , thus if this chunk of code is placed
> > beforei,  is already populated with "libs=$gluefile" and lacks
> > the prefix.  Notice that this is the case only for the first test
> > compiled in a tested .exp file, the next ones will have the adjusted
> > gluefile content.
> >
> > For -T, this is another issue not covered by this patch, it is not
> > handled by  like "-Xlinker" thus a "-Wl,"
> > prefix is placed between -T and the linker file, we'll send another
> > patch to fix that issue.
> 
> Ah, OK, I thought the patch was fixing the -T issue too.
> If it's just fixing the ordering problem then it all makes sense. :-)
> 
> So yeah, the patch is OK for trunk, thanks.  Please follow the
> instructions on https://gcc.gnu.org/gitwrite.html to get write access
> (listing me as sponsor), but I can commit it for you if you prefer.
> 
> Richard

Thanks Richard, I've GCC write access, even if I didn't work on it for
several years, I'll try to commit it myself tomorrow to check if it
still works ;) but maybe Torbjorn would need a sponsorship for write
access.

Cheers,
Yvan
 
> >
> > Thanks,
> > Yvan
> >
> >> Thanks,
> >> Richard
> >> 
> >> > Co-Authored-By: Yvan ROUX 
> >> > Signed-off-by: Torbjörn SVENSSON 
> >> > ---
> >> >  gcc/testsuite/lib/g++.exp | 10 +-
> >> >  gcc/testsuite/lib/gcc.exp | 21 +++--
> >> >  gcc/testsuite/lib/wrapper.exp |  7 ++-
> >> >  3 files changed, 22 insertions(+), 16 deletions(-)
> >> >
> >> > diff --git a/gcc/testsuite/lib/g++.exp b/gcc/testsuite/lib/g++.exp
> >> > index 24ef068b239..16e61fb4ad4 100644
> >> > --- a/gcc/testsuite/lib/g++.exp
> >> > +++ b/gcc/testsuite/lib/g++.exp
> >> > @@ -303,11 +303,6 @@ proc g++_target_compile { source dest type options 
> >> > } {
> >> >  global flags_to_postpone
> >> >  global board_info
> >> >  
> >> > -if { [target_info needs_status_wrapper] != "" && [info exists 
> >> > gluefile] } {
> >> > -lappend options "libs=${gluefile}"
> >> > -lappend options "ldflags=${wrap_flags}"
> >> > -}
> >> > -
> >> >  global TEST_EXTRA_LIBS
> >> >  if [info exists TEST_EXTRA_LIBS] {
> >> >  lappend options "ldflags=$TEST_EXTRA_LIBS"
> >> > @@ -333,6 +328,11 @@ proc g++_target_compile { source dest type options 
> >> > } {
> >> >  
> >> >  set options [dg-additional-files-options $options $source]
> >> >  
> >> > +if { [target_info needs_status_wrapper] != "" && [info exists 
> >> > gluefile] } {
> >> > +lappend options "libs=${gluefile}"
> >> > +lappend options "ldflags=${wrap_flags}"
> >> > +}
> >> > +
> >> >  set result [target_compile $source $dest $type $options]
> >> >  
> >> >  if {[board_info $tboard exists multilib_flags]} {
> >> > diff --git a/gcc/testsuite/lib/gcc.exp b/gcc/testsuite/lib/gcc.exp
> >> > index 1b25ebec4cf..2f145d0fdf4 100644
> >> > --- a/gcc/testsuite/lib/gcc.exp
> >> > +++ b/gcc/testsuite/lib/gcc.exp
> >> > @@ -129,16 +129,6 @@ proc gcc_target_compile { source dest type options 
> >> > } {
> >> >  global flags_to_postpone
> >> >  global board_info
> >> >  
> >> > -if {[target_info needs_status_wrapper] != "" && \
> >> > -[target_info needs_status_wrapper] != "0" && \
> >> > -[info exists gluefile] } {
> >> > -lappend options "libs=${gluefile}"
> >> > -lappend options "ldflags=$wrap_flags"
> >> > -if { $type == "executable" } {
> >> > -set options [concat "{additional_flags=-dumpbase \"\"}" 
> 

Re: [PATCH] c++: Refer to internal linkage for -Wsubobject-linkage [PR86491]

[Jason Merrill via Gcc-patches]

Oops, failed to CC the list.

 Forwarded Message 
Subject: Re: [PATCH] c++: Refer to internal linkage for 
-Wsubobject-linkage [PR86491]

Date: Mon, 12 Sep 2022 12:09:38 -0400
From: Jason Merrill 
To: Jonathan Wakely 

On 7/23/22 07:31, Jonathan Wakely wrote:

I'll try that on Monday, thanks!

On Fri, 22 Jul 2022 at 22:30, Jason Merrill  wrote:


On 6/30/22 12:53, Jonathan Wakely via Gcc-patches wrote:

Tested powerpc64le-linux, OK for trunk?

-- >8 --

Since C++11 relaxed the requirement for template arguments to have
external linkage, it's possible to get -Wsubobject-linkage warnings
without using any anonymous namespaces. This confuses users when they
get diagnostics that refer to an anonymous namespace that doesn't exist
in their code.

This changes the diagnostic to say "has internal linkage" for C++11 and
later, which is accurate whether internal linkage is due to the 'static'
specifier, or due to the use of anonymous namespaces.

For C++98 template arguments declared with 'static' are ill-formed
anyway, so the only way this warning can arise is via anonymous
namespaces. That means the existing wording is accurate for C++98 and so
we can keep it.


I'd prefer to keep the existing wording for types that are actually in
an anonymous namespace.  Checking decl_anon_ns_mem_p seems like the way
to do that, though it would probably need to remove the existing type
shortcut and instead just do decl = TYPE_MAIN_DECL (decl).


I decided to follow up on this myself, and ended up renaming the current 
function as other users relied on its semantics.


Tested x86_64-pc-linux-gnu, applying to trunk.From 6cbff05579b8d1acfe953b69ba2710d6b36e830e Mon Sep 17 00:00:00 2001
From: Jonathan Wakely 
Date: Thu, 30 Jun 2022 17:53:26 +0100
Subject: [PATCH] c++: Refer to internal linkage for -Wsubobject-linkage
 [PR86491]
To: gcc-patches@gcc.gnu.org

Since C++11 relaxed the requirement for template arguments to have
external linkage, it's possible to get -Wsubobject-linkage warnings
without using any anonymous namespaces. This confuses users when they
get diagnostics that refer to an anonymous namespace that doesn't exist
in their code.

This changes the diagnostic to say "has internal linkage" for C++11 and
later, if the type isn't actually a member of the anonymous namespace.
Making that distinction involved renaming the current decl_anon_ns_mem_p to
something that better expresses its semantics.

For C++98 template arguments declared with 'static' are ill-formed
anyway, so the only way this warning can arise is via anonymous
namespaces. That means the existing wording is accurate for C++98 and so
we can keep it.

	PR c++/86491

gcc/cp/ChangeLog:

	* decl2.cc (constrain_class_visibility): Adjust wording of
	-Wsubobject-linkage for cases where anonymous
	namespaces aren't used.
	* tree.cc (decl_anon_ns_mem_p): Now only true for actual anonymous
	namespace members, rename old semantics to...
	(decl_internal_context_p): ...this.
	* cp-tree.h, name-lookup.cc, pt.cc: Adjust.

gcc/testsuite/ChangeLog:

	* g++.dg/warn/anonymous-namespace-3.C: Use separate dg-warning
	directives for C++98 and everything else.
	* g++.dg/warn/Wsubobject-linkage-5.C: New test.
---
 gcc/cp/cp-tree.h  |  3 +-
 gcc/cp/decl2.cc   | 39 ---
 gcc/cp/name-lookup.cc |  2 +-
 gcc/cp/pt.cc  |  2 +-
 gcc/cp/tree.cc| 12 +-
 .../g++.dg/warn/Wsubobject-linkage-5.C|  7 
 .../g++.dg/warn/anonymous-namespace-3.C   |  3 +-
 7 files changed, 48 insertions(+), 20 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/warn/Wsubobject-linkage-5.C

diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index 7b28405c3ac..e73d04f21d8 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -7874,7 +7874,8 @@ extern tree replace_placeholders		(tree, tree, bool * = NULL);
 extern bool find_placeholders			(tree);
 extern tree get_type_decl			(tree);
 extern tree decl_namespace_context		(tree);
-extern bool decl_anon_ns_mem_p			(const_tree);
+extern bool decl_anon_ns_mem_p			(tree);
+extern bool decl_internal_context_p		(const_tree);
 extern tree lvalue_type(tree);
 extern tree error_type(tree);
 extern int varargs_function_p			(const_tree);
diff --git a/gcc/cp/decl2.cc b/gcc/cp/decl2.cc
index cd188813bee..684a2d06dde 100644
--- a/gcc/cp/decl2.cc
+++ b/gcc/cp/decl2.cc
@@ -2851,7 +2851,7 @@ determine_visibility (tree decl)
   if (class_type)
 determine_visibility_from_class (decl, class_type);
 
-  if (decl_anon_ns_mem_p (decl))
+  if (decl_internal_context_p (decl))
 /* Names in an anonymous namespace get internal linkage.  */
 constrain_visibility (decl, VISIBILITY_ANON, false);
   else if (TREE_CODE (decl) != TYPE_DECL)
@@ -2965,16 +2965,21 @@ constrain_class_visibility (tree type)
 		  {
 		if (same_type_p (TREE_TYPE (t), nlt))
 		  warning 

Re: [PATCH] testsuite: gluefile file need to be prefixed

[Richard Sandiford via Gcc-patches]

Yvan Roux  writes:
> Hi Richard,
> On Mon, Sep 12, 2022 at 12:56:52PM +0100, Richard Sandiford via Gcc-patches 
> wrote:
>> Torbjörn SVENSSON via Gcc-patches  writes:
>> > PR/95720
>> > When the status wrapper is used, the gluefile need to be prefixed with
>> > -Wl, in order for the test cases to have the dump files with the
>> > expected names.
>> >
>> > gcc/testsuite/ChangeLog:
>> >
>> > * gcc/testsuite/lib/g++.exp: Moved gluefile block to after
>> >   flags have been prefixed for the target_compile call.
>> > * gcc/testsuite/lib/gcc.exp: Likewise.
>> > * gcc/testsuite/lib/wrapper.exp: Reset adjusted state flag.
>> 
>> I agree this looks right, but I'm curious how you ended up with the
>> behaviour seen in comment 16.  I thought having:
>> 
>> if { [target_info needs_status_wrapper] != "" && [info exists gluefile] 
>> } {
>>  lappend options "libs=${gluefile}"
>>  lappend options "ldflags=${wrap_flags}"
>> }
>> 
>> before the dg-additional-files-options/gcc_adjusted_linker_flags would
>> lead to the gluefile missing a "-Wl," first time round.  How is it that
>> the gluefile still gets the "-Wl," and the -T misses it instead?
>
> The issue is that dg-additional-files-options/gcc_adjusted_linker_flags
> add the "-Wl," prefix to the content of the global variable 
> and not to the one of , thus if this chunk of code is placed
> beforei,  is already populated with "libs=$gluefile" and lacks
> the prefix.  Notice that this is the case only for the first test
> compiled in a tested .exp file, the next ones will have the adjusted
> gluefile content.
>
> For -T, this is another issue not covered by this patch, it is not
> handled by  like "-Xlinker" thus a "-Wl,"
> prefix is placed between -T and the linker file, we'll send another
> patch to fix that issue.

Ah, OK, I thought the patch was fixing the -T issue too.
If it's just fixing the ordering problem then it all makes sense. :-)

So yeah, the patch is OK for trunk, thanks.  Please follow the
instructions on https://gcc.gnu.org/gitwrite.html to get write access
(listing me as sponsor), but I can commit it for you if you prefer.

Richard

>
> Thanks,
> Yvan
>
>> Thanks,
>> Richard
>> 
>> > Co-Authored-By: Yvan ROUX 
>> > Signed-off-by: Torbjörn SVENSSON 
>> > ---
>> >  gcc/testsuite/lib/g++.exp | 10 +-
>> >  gcc/testsuite/lib/gcc.exp | 21 +++--
>> >  gcc/testsuite/lib/wrapper.exp |  7 ++-
>> >  3 files changed, 22 insertions(+), 16 deletions(-)
>> >
>> > diff --git a/gcc/testsuite/lib/g++.exp b/gcc/testsuite/lib/g++.exp
>> > index 24ef068b239..16e61fb4ad4 100644
>> > --- a/gcc/testsuite/lib/g++.exp
>> > +++ b/gcc/testsuite/lib/g++.exp
>> > @@ -303,11 +303,6 @@ proc g++_target_compile { source dest type options } {
>> >  global flags_to_postpone
>> >  global board_info
>> >  
>> > -if { [target_info needs_status_wrapper] != "" && [info exists 
>> > gluefile] } {
>> > -  lappend options "libs=${gluefile}"
>> > -  lappend options "ldflags=${wrap_flags}"
>> > -}
>> > -
>> >  global TEST_EXTRA_LIBS
>> >  if [info exists TEST_EXTRA_LIBS] {
>> >lappend options "ldflags=$TEST_EXTRA_LIBS"
>> > @@ -333,6 +328,11 @@ proc g++_target_compile { source dest type options } {
>> >  
>> >  set options [dg-additional-files-options $options $source]
>> >  
>> > +if { [target_info needs_status_wrapper] != "" && [info exists 
>> > gluefile] } {
>> > +  lappend options "libs=${gluefile}"
>> > +  lappend options "ldflags=${wrap_flags}"
>> > +}
>> > +
>> >  set result [target_compile $source $dest $type $options]
>> >  
>> >  if {[board_info $tboard exists multilib_flags]} {
>> > diff --git a/gcc/testsuite/lib/gcc.exp b/gcc/testsuite/lib/gcc.exp
>> > index 1b25ebec4cf..2f145d0fdf4 100644
>> > --- a/gcc/testsuite/lib/gcc.exp
>> > +++ b/gcc/testsuite/lib/gcc.exp
>> > @@ -129,16 +129,6 @@ proc gcc_target_compile { source dest type options } {
>> >  global flags_to_postpone
>> >  global board_info
>> >  
>> > -if {[target_info needs_status_wrapper] != "" && \
>> > -  [target_info needs_status_wrapper] != "0" && \
>> > -  [info exists gluefile] } {
>> > -  lappend options "libs=${gluefile}"
>> > -  lappend options "ldflags=$wrap_flags"
>> > -  if { $type == "executable" } {
>> > -  set options [concat "{additional_flags=-dumpbase \"\"}" $options]
>> > -  }
>> > -}
>> > -
>> >  global TEST_EXTRA_LIBS
>> >  if [info exists TEST_EXTRA_LIBS] {
>> >lappend options "ldflags=$TEST_EXTRA_LIBS"
>> > @@ -170,6 +160,17 @@ proc gcc_target_compile { source dest type options } {
>> >  lappend options "timeout=[timeout_value]"
>> >  lappend options "compiler=$GCC_UNDER_TEST"
>> >  set options [dg-additional-files-options $options $source]
>> > +
>> > +if {[target_info needs_status_wrapper] != "" && \
>> > +  [target_info needs_status_wrapper] != "0" && \
>> > +  [info exists gluefile] } {
>> > +  lappend 

Re: [PATCH v3] eliminate mutex in fast path of __register_frame

[Jason Merrill via Gcc-patches]

On 6/26/22 05:13, Thomas Neumann via Gcc-patches wrote:

NOTE: A stress test program and a detailed walkthrough that breaks this
patch into manageable parts can be found here:
https://databasearchitects.blogspot.com/2022/06/making-unwinding-through-jit-ed-code.html

The __register_frame/__deregister_frame functions are used to register
unwinding frames from JITed code in a sorted list. That list itself
is protected by object_mutex, which leads to terrible performance
in multi-threaded code and is somewhat expensive even if single-threaded.
There was already a fast-path that avoided taking the mutex if no
frame was registered at all.

This commit eliminates both the mutex and the sorted list from
the atomic fast path, and replaces it with a btree that uses
optimistic lock coupling during lookup. This allows for fully parallel
unwinding and is essential to scale exception handling to large
core counts.

Changes since v2:
- fix contention problem during unlocking


Thanks!  The blog entries are very helpful for the review.

One general minor issue: Please add a period at the end of most comments.


libgcc/ChangeLog:

 * unwind-dw2-fde.c (release_registered_frames): Cleanup at shutdown.
 (__register_frame_info_table_bases): Use btree in atomic fast path.
 (__deregister_frame_info_bases): Likewise.
 (_Unwind_Find_FDE): Likewise.
 (base_from_object): Make parameter const.
 (get_pc_range_from_fdes): Compute PC range for lookup.
 (get_pc_range): Likewise.
 * unwind-dw2-fde.h (last_fde): Make parameter const.
 * unwind-dw2-btree.h: New file.
---
  libgcc/unwind-dw2-btree.h | 953 ++
  libgcc/unwind-dw2-fde.c   | 194 ++--
  libgcc/unwind-dw2-fde.h   |   2 +-
  3 files changed, 1113 insertions(+), 36 deletions(-)
  create mode 100644 libgcc/unwind-dw2-btree.h

diff --git a/libgcc/unwind-dw2-btree.h b/libgcc/unwind-dw2-btree.h
new file mode 100644
index 000..3b2b6871b46
--- /dev/null
+++ b/libgcc/unwind-dw2-btree.h
@@ -0,0 +1,953 @@
+/* Lock-free btree for manually registered unwind frames  */
+/* Copyright (C) 2022 Free Software Foundation, Inc.
+   Contributed by Thomas Neumann
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify it under
+the terms of the GNU General Public License as published by the Free
+Software Foundation; either version 3, or (at your option) any later
+version.
+
+GCC is distributed in the hope that it will be useful, but WITHOUT ANY
+WARRANTY; without even the implied warranty of MERCHANTABILITY or
+FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+for more details.
+
+Under Section 7 of GPL version 3, you are granted additional
+permissions described in the GCC Runtime Library Exception, version
+3.1, as published by the Free Software Foundation.
+
+You should have received a copy of the GNU General Public License and
+a copy of the GCC Runtime Library Exception along with this program;
+see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
+.  */
+
+#ifndef GCC_UNWIND_DW2_BTREE_H
+#define GCC_UNWIND_DW2_BTREE_H
+
+#include 
+
+// Common logic for version locks
+struct version_lock
+{
+  // The lock itself. The lowest bit indicates an exclusive lock,
+  // the second bit indicates waiting threads. All other bits are
+  // used as counter to recognize changes.
+  // Overflows are okay here, we must only prevent overflow to the
+  // same value within one lock_optimistic/validate
+  // range. Even on 32 bit platforms that would require 1 billion
+  // frame registrations within the time span of a few assembler
+  // instructions.
+  uintptr_t version_lock;
+};
+
+#ifdef __GTHREAD_HAS_COND
+// We should never get contention within the tree as it rarely changes.
+// But if we ever do get contention we use these for waiting
+static __gthread_mutex_t version_lock_mutex = __GTHREAD_MUTEX_INIT;
+static __gthread_cond_t version_lock_cond = __GTHREAD_COND_INIT;
+#endif
+
+// Initialize in locked state
+static inline void
+version_lock_initialize_locked_exclusive (struct version_lock *vl)
+{
+  vl->version_lock = 1;
+}
+
+// Try to lock the node exclusive
+static inline bool
+version_lock_try_lock_exclusive (struct version_lock *vl)
+{
+  uintptr_t state = __atomic_load_n (&(vl->version_lock), __ATOMIC_SEQ_CST);
+  if (state & 1)
+return false;
+  return __atomic_compare_exchange_n (&(vl->version_lock), , state | 1,
+ false, __ATOMIC_SEQ_CST,
+ __ATOMIC_SEQ_CST);
+}
+
+// Lock the node exclusive, blocking as needed
+static void
+version_lock_lock_exclusive (struct version_lock *vl)
+{
+#ifndef __GTHREAD_HAS_COND
+restart:
+#endif
+
+  // We should virtually never get contention here, as frame
+  // changes are rare
+  uintptr_t state = __atomic_load_n (&(vl->version_lock), __ATOMIC_SEQ_CST);
+  if 

Re: [PATCH] testsuite: gluefile file need to be prefixed

[Yvan Roux via Gcc-patches]

Hi Richard,

On Mon, Sep 12, 2022 at 12:56:52PM +0100, Richard Sandiford via Gcc-patches 
wrote:
> Torbjörn SVENSSON via Gcc-patches  writes:
> > PR/95720
> > When the status wrapper is used, the gluefile need to be prefixed with
> > -Wl, in order for the test cases to have the dump files with the
> > expected names.
> >
> > gcc/testsuite/ChangeLog:
> >
> > * gcc/testsuite/lib/g++.exp: Moved gluefile block to after
> >   flags have been prefixed for the target_compile call.
> > * gcc/testsuite/lib/gcc.exp: Likewise.
> > * gcc/testsuite/lib/wrapper.exp: Reset adjusted state flag.
> 
> I agree this looks right, but I'm curious how you ended up with the
> behaviour seen in comment 16.  I thought having:
> 
> if { [target_info needs_status_wrapper] != "" && [info exists gluefile] } 
> {
>   lappend options "libs=${gluefile}"
>   lappend options "ldflags=${wrap_flags}"
> }
> 
> before the dg-additional-files-options/gcc_adjusted_linker_flags would
> lead to the gluefile missing a "-Wl," first time round.  How is it that
> the gluefile still gets the "-Wl," and the -T misses it instead?

The issue is that dg-additional-files-options/gcc_adjusted_linker_flags
add the "-Wl," prefix to the content of the global variable 
and not to the one of , thus if this chunk of code is placed
beforei,  is already populated with "libs=$gluefile" and lacks
the prefix.  Notice that this is the case only for the first test
compiled in a tested .exp file, the next ones will have the adjusted
gluefile content.

For -T, this is another issue not covered by this patch, it is not
handled by  like "-Xlinker" thus a "-Wl,"
prefix is placed between -T and the linker file, we'll send another
patch to fix that issue.

Thanks,
Yvan

> Thanks,
> Richard
> 
> > Co-Authored-By: Yvan ROUX 
> > Signed-off-by: Torbjörn SVENSSON 
> > ---
> >  gcc/testsuite/lib/g++.exp | 10 +-
> >  gcc/testsuite/lib/gcc.exp | 21 +++--
> >  gcc/testsuite/lib/wrapper.exp |  7 ++-
> >  3 files changed, 22 insertions(+), 16 deletions(-)
> >
> > diff --git a/gcc/testsuite/lib/g++.exp b/gcc/testsuite/lib/g++.exp
> > index 24ef068b239..16e61fb4ad4 100644
> > --- a/gcc/testsuite/lib/g++.exp
> > +++ b/gcc/testsuite/lib/g++.exp
> > @@ -303,11 +303,6 @@ proc g++_target_compile { source dest type options } {
> >  global flags_to_postpone
> >  global board_info
> >  
> > -if { [target_info needs_status_wrapper] != "" && [info exists 
> > gluefile] } {
> > -   lappend options "libs=${gluefile}"
> > -   lappend options "ldflags=${wrap_flags}"
> > -}
> > -
> >  global TEST_EXTRA_LIBS
> >  if [info exists TEST_EXTRA_LIBS] {
> > lappend options "ldflags=$TEST_EXTRA_LIBS"
> > @@ -333,6 +328,11 @@ proc g++_target_compile { source dest type options } {
> >  
> >  set options [dg-additional-files-options $options $source]
> >  
> > +if { [target_info needs_status_wrapper] != "" && [info exists 
> > gluefile] } {
> > +   lappend options "libs=${gluefile}"
> > +   lappend options "ldflags=${wrap_flags}"
> > +}
> > +
> >  set result [target_compile $source $dest $type $options]
> >  
> >  if {[board_info $tboard exists multilib_flags]} {
> > diff --git a/gcc/testsuite/lib/gcc.exp b/gcc/testsuite/lib/gcc.exp
> > index 1b25ebec4cf..2f145d0fdf4 100644
> > --- a/gcc/testsuite/lib/gcc.exp
> > +++ b/gcc/testsuite/lib/gcc.exp
> > @@ -129,16 +129,6 @@ proc gcc_target_compile { source dest type options } {
> >  global flags_to_postpone
> >  global board_info
> >  
> > -if {[target_info needs_status_wrapper] != "" && \
> > -   [target_info needs_status_wrapper] != "0" && \
> > -   [info exists gluefile] } {
> > -   lappend options "libs=${gluefile}"
> > -   lappend options "ldflags=$wrap_flags"
> > -   if { $type == "executable" } {
> > -   set options [concat "{additional_flags=-dumpbase \"\"}" $options]
> > -   }
> > -}
> > -
> >  global TEST_EXTRA_LIBS
> >  if [info exists TEST_EXTRA_LIBS] {
> > lappend options "ldflags=$TEST_EXTRA_LIBS"
> > @@ -170,6 +160,17 @@ proc gcc_target_compile { source dest type options } {
> >  lappend options "timeout=[timeout_value]"
> >  lappend options "compiler=$GCC_UNDER_TEST"
> >  set options [dg-additional-files-options $options $source]
> > +
> > +if {[target_info needs_status_wrapper] != "" && \
> > +   [target_info needs_status_wrapper] != "0" && \
> > +   [info exists gluefile] } {
> > +   lappend options "libs=${gluefile}"
> > +   lappend options "ldflags=$wrap_flags"
> > +   if { $type == "executable" } {
> > +   set options [concat "{additional_flags=-dumpbase \"\"}" $options]
> > +   }
> > +}
> > +
> >  set return_val [target_compile $source $dest $type $options]
> >  
> >  if {[board_info $tboard exists multilib_flags]} {
> > diff --git a/gcc/testsuite/lib/wrapper.exp b/gcc/testsuite/lib/wrapper.exp
> > index 5a601b269da..4a7d56941fc 100644
> 

Re: [PATCH] PR rtl-optimization/106594: Preserve zero_extend when cheap.

[Richard Sandiford via Gcc-patches]

"Roger Sayle"  writes:
> Hi Richard,
>
>> "Roger Sayle"  writes:
>> > This patch addresses PR rtl-optimization/106594, a significant
>> > performance regression affecting aarch64 recently introduced (exposed)
>> > by one of my recent RTL simplification improvements.  Firstly many
>> > thanks to Tamar Christina for confirming that the core of this patch
>> > provides ~5% performance improvement on some on his benchmarks.
>> >
>> > GCC's combine pass uses the function expand_compound_operation to
>> > conceptually simplify/canonicalize SIGN_EXTEND and ZERO_EXTEND as a
>> > pair of shift operations, as not all targets support extension
>> > instructions [technically ZERO_EXTEND may potentially be simplified/
>> > canonicalized to an AND operation, but the theory remains the same].
>> 
>> Are you sure the reason is that not all targets support extension 
>> instructions?
>> I thought in practice this routine would only tend to see ZERO_EXTEND etc. if
>> those codes appeared in the original rtl insns.
>
> Excellent question.  My current understanding is that this subroutine is used
> for both SIGN_EXTEND/ZERO_EXTEND (for which may processors have instructions
> and even addressing mode support) and also SIGN_EXTRACT/ZERO_EXTRACT for
> which many platforms, really do need a pair of shift instructions. (or an 
> AND).
>
> The bit (to me) that that's suspicious is the exact wording of the comment...
>
>> >   /* Convert sign extension to zero extension, if we know that the high
>> >  bit is not set, as this is easier to optimize.  It will be converted
>> >  back to cheaper alternative in make_extraction.  */
>
> Notice that things are converted back in "make_extraction", and may not be
> getting converted back (based on empirical evidence) for non-extractions,
> i.e. extensions.  This code is being called for ZERO_EXTEND on a path that
> doesn't subsequently call make_compound.  As shown in the PR, there are
> code generation differences (that impact performance), but I agree there's
> some ambiguity around the intent of the original code.
>
> My personal preference is to write backend patterns that contain ZERO_EXTEND
> (or SIGN_EXTEND) rather than a pair of shifts, or an AND of a paradoxical 
> SUBREG.
> For example, the new patterns added to i386.md look (to me) "cleaner" than the
> forms that they complement/replace.  The burden is then on the middle-end to
> simplify {ZERO,SIGN}_EXTEND forms as efficiently as it would shifts or ANDs.

Yeah.  I think the intention is still that .md patterns match the
"compound" forms like zero_extend/sign_extend where possible.
AIUI the "expanded" from is just an internal thing, to reduce the
number of simplification rules needed, and combine is supposed to call
make_compound_operation before recog()nising the result.

But given that the simplification rules in simplify-rtx.cc (as opposed
to combine.cc itself) have to cope with passes that *don't* do this
canonicalisation, I'm not sure how much it really helps in practice.
And the cost of make_compound_operation failing to recognise the
(possibly quite convoluted) results of substituting into an expanded
compound operation can be quite severe.

> Interestingly, this is sometimes already the case, for example, we simplify
> (ffs (zero_extend ...)) in cases where we wouldn't simplify the equivalent
> (ffs (and ... 255)) [but these are perhaps also just missed optimizations].

Yeah, sounds like it.

Thanks,
Richard

> Thoughts?  I'll also dig more into the history of these (combine) functions.
>
> Cheers,
> Roger
> --

Re: Extend fold_vec_perm to fold VEC_PERM_EXPR in VLA manner

[Richard Sandiford via Gcc-patches]

Prathamesh Kulkarni  writes:
> On Mon, 5 Sept 2022 at 15:51, Richard Sandiford
>  wrote:
>>
>> Sorry for the slow reply.  I wrote a response a couple of weeks ago
>> but I think it get lost in a machine outage.
>>
>> Prathamesh Kulkarni  writes:
>> > Hi,
>> > The attached prototype patch extends fold_vec_perm to fold VEC_PERM_EXPR
>> > in VLA manner, and currently handles the following cases:
>> > (a) fixed len arg0, arg1 and fixed len sel.
>> > (b) fixed len arg0, arg1 and vla sel
>> > (c) vla arg0, arg1 and vla sel with arg0, arg1 being VECTOR_CST.
>> >
>> > It seems to work for the VLA tests written in
>> > test_vec_perm_vla_folding (), and am working thru the fallout observed in
>> > regression testing.
>> >
>> > Does the approach taken in the patch look in the right direction ?
>> > I am not sure if I have got the conversion from "sel_index"
>> > to index of either arg0, or arg1 entirely correct.
>> > I would be grateful for suggestions on the patch.
>> >
>> > Thanks,
>> > Prathamesh
>> >
>> > diff --git a/gcc/fold-const.cc b/gcc/fold-const.cc
>> > index 4f4ec81c8d4..5e12260211e 100644
>> > --- a/gcc/fold-const.cc
>> > +++ b/gcc/fold-const.cc
>> > @@ -85,6 +85,9 @@ along with GCC; see the file COPYING3.  If not see
>> >  #include "vec-perm-indices.h"
>> >  #include "asan.h"
>> >  #include "gimple-range.h"
>> > +#include "tree-pretty-print.h"
>> > +#include "gimple-pretty-print.h"
>> > +#include "print-tree.h"
>> >
>> >  /* Nonzero if we are folding constants inside an initializer or a C++
>> > manifestly-constant-evaluated context; zero otherwise.
>> > @@ -10496,40 +10499,6 @@ fold_mult_zconjz (location_t loc, tree type, tree 
>> > expr)
>> > build_zero_cst (itype));
>> >  }
>> >
>> > -
>> > -/* Helper function for fold_vec_perm.  Store elements of VECTOR_CST or
>> > -   CONSTRUCTOR ARG into array ELTS, which has NELTS elements, and return
>> > -   true if successful.  */
>> > -
>> > -static bool
>> > -vec_cst_ctor_to_array (tree arg, unsigned int nelts, tree *elts)
>> > -{
>> > -  unsigned HOST_WIDE_INT i, nunits;
>> > -
>> > -  if (TREE_CODE (arg) == VECTOR_CST
>> > -  && VECTOR_CST_NELTS (arg).is_constant ())
>> > -{
>> > -  for (i = 0; i < nunits; ++i)
>> > - elts[i] = VECTOR_CST_ELT (arg, i);
>> > -}
>> > -  else if (TREE_CODE (arg) == CONSTRUCTOR)
>> > -{
>> > -  constructor_elt *elt;
>> > -
>> > -  FOR_EACH_VEC_SAFE_ELT (CONSTRUCTOR_ELTS (arg), i, elt)
>> > - if (i >= nelts || TREE_CODE (TREE_TYPE (elt->value)) == VECTOR_TYPE)
>> > -   return false;
>> > - else
>> > -   elts[i] = elt->value;
>> > -}
>> > -  else
>> > -return false;
>> > -  for (; i < nelts; i++)
>> > -elts[i]
>> > -  = fold_convert (TREE_TYPE (TREE_TYPE (arg)), integer_zero_node);
>> > -  return true;
>> > -}
>> > -
>> >  /* Attempt to fold vector permutation of ARG0 and ARG1 vectors using SEL
>> > selector.  Return the folded VECTOR_CST or CONSTRUCTOR if successful,
>> > NULL_TREE otherwise.  */
>> > @@ -10537,45 +10506,149 @@ vec_cst_ctor_to_array (tree arg, unsigned int 
>> > nelts, tree *elts)
>> >  tree
>> >  fold_vec_perm (tree type, tree arg0, tree arg1, const vec_perm_indices 
>> > )
>> >  {
>> > -  unsigned int i;
>> > -  unsigned HOST_WIDE_INT nelts;
>> > -  bool need_ctor = false;
>> > +  poly_uint64 arg0_len = TYPE_VECTOR_SUBPARTS (TREE_TYPE (arg0));
>> > +  poly_uint64 arg1_len = TYPE_VECTOR_SUBPARTS (TREE_TYPE (arg1));
>> > +
>> > +  gcc_assert (known_eq (TYPE_VECTOR_SUBPARTS (type),
>> > + sel.length ()));
>> > +  gcc_assert (known_eq (arg0_len, arg1_len));
>> >
>> > -  if (!sel.length ().is_constant ())
>> > -return NULL_TREE;
>> > -  gcc_assert (known_eq (TYPE_VECTOR_SUBPARTS (type), nelts)
>> > -   && known_eq (TYPE_VECTOR_SUBPARTS (TREE_TYPE (arg0)), nelts)
>> > -   && known_eq (TYPE_VECTOR_SUBPARTS (TREE_TYPE (arg1)), nelts));
>> >if (TREE_TYPE (TREE_TYPE (arg0)) != TREE_TYPE (type)
>> >|| TREE_TYPE (TREE_TYPE (arg1)) != TREE_TYPE (type))
>> >  return NULL_TREE;
>> >
>> > -  tree *in_elts = XALLOCAVEC (tree, nelts * 2);
>> > -  if (!vec_cst_ctor_to_array (arg0, nelts, in_elts)
>> > -  || !vec_cst_ctor_to_array (arg1, nelts, in_elts + nelts))
>> > +  unsigned input_npatterns = 0;
>> > +  unsigned out_npatterns = sel.encoding ().npatterns ();
>> > +  unsigned out_nelts_per_pattern = sel.encoding ().nelts_per_pattern ();
>> > +
>> > +  /* FIXME: How to reshape fixed length vector_cst, so that
>> > + npatterns == vector.length () and nelts_per_pattern == 1 ?
>> > + It seems the vector is canonicalized to minimize npatterns.  */
>> > +
>> > +  if (arg0_len.is_constant ())
>> > +{
>> > +  /* If arg0, arg1 are fixed width vectors, and sel is VLA,
>> > + ensure that it is a dup sequence and has same period
>> > +  as input vector.  */
>> > +
>> > +  if (!sel.length ().is_constant ()
>> > +   && (sel.encoding 

RE: [PATCH] PR rtl-optimization/106594: Preserve zero_extend when cheap.

[Roger Sayle]

Hi Richard,

> "Roger Sayle"  writes:
> > This patch addresses PR rtl-optimization/106594, a significant
> > performance regression affecting aarch64 recently introduced (exposed)
> > by one of my recent RTL simplification improvements.  Firstly many
> > thanks to Tamar Christina for confirming that the core of this patch
> > provides ~5% performance improvement on some on his benchmarks.
> >
> > GCC's combine pass uses the function expand_compound_operation to
> > conceptually simplify/canonicalize SIGN_EXTEND and ZERO_EXTEND as a
> > pair of shift operations, as not all targets support extension
> > instructions [technically ZERO_EXTEND may potentially be simplified/
> > canonicalized to an AND operation, but the theory remains the same].
> 
> Are you sure the reason is that not all targets support extension 
> instructions?
> I thought in practice this routine would only tend to see ZERO_EXTEND etc. if
> those codes appeared in the original rtl insns.

Excellent question.  My current understanding is that this subroutine is used
for both SIGN_EXTEND/ZERO_EXTEND (for which may processors have instructions
and even addressing mode support) and also SIGN_EXTRACT/ZERO_EXTRACT for
which many platforms, really do need a pair of shift instructions. (or an AND).

The bit (to me) that that's suspicious is the exact wording of the comment...

> >   /* Convert sign extension to zero extension, if we know that the high
> >  bit is not set, as this is easier to optimize.  It will be converted
> >  back to cheaper alternative in make_extraction.  */

Notice that things are converted back in "make_extraction", and may not be
getting converted back (based on empirical evidence) for non-extractions,
i.e. extensions.  This code is being called for ZERO_EXTEND on a path that
doesn't subsequently call make_compound.  As shown in the PR, there are
code generation differences (that impact performance), but I agree there's
some ambiguity around the intent of the original code.

My personal preference is to write backend patterns that contain ZERO_EXTEND
(or SIGN_EXTEND) rather than a pair of shifts, or an AND of a paradoxical 
SUBREG.
For example, the new patterns added to i386.md look (to me) "cleaner" than the
forms that they complement/replace.  The burden is then on the middle-end to
simplify {ZERO,SIGN}_EXTEND forms as efficiently as it would shifts or ANDs.

Interestingly, this is sometimes already the case, for example, we simplify
(ffs (zero_extend ...)) in cases where we wouldn't simplify the equivalent
(ffs (and ... 255)) [but these are perhaps also just missed optimizations].

Thoughts?  I'll also dig more into the history of these (combine) functions.

Cheers,
Roger
--

Re: [PATCH] Implement known/maybe fpclassify like API for frange.

[Aldy Hernandez via Gcc-patches]

On Mon, Sep 12, 2022 at 10:48 AM Jan-Benedict Glaw  wrote:
>
> Hi Aldy!
>
> On Thu, 2022-09-08 12:56:24 +0200, Aldy Hernandez via Gcc-patches 
>  wrote:
>
> > From 795baa0b044953e9f198f49e379374d633f43b47 Mon Sep 17 00:00:00 2001
> > From: Aldy Hernandez 
> > Date: Thu, 8 Sep 2022 08:11:43 +0200
> > Subject: [PATCH] Implement known/maybe fpclassify like API for frange.
> >
> > gcc/ChangeLog:
> >
> >   * gimple-range-fold.cc
> >   (fold_using_range::range_of_builtin_int_call): Use fpclassify like 
> > API.
> >   * range-op-float.cc (finite_operand_p): Same.
> >   (finite_operands_p): Same.
> >   (foperator_lt::fold_range): Same.
> >   (foperator_le::fold_range): Same.
> >   (foperator_gt::fold_range): Same.
> >   (foperator_ge::fold_range): Same.
> >   (foperator_unordered::fold_range): Same.
> >   (foperator_unordered::op1_range): Same.
> >   (foperator_ordered::fold_range): Same.
> >   * value-range.cc (frange::set_nan): Same.
> >   (frange::set_signbit): Same.
> >   (frange::union_): Same.
> >   (frange::intersect): Same.
> >   (frange::operator==): Same.
> >   (frange::singleton_p): Same.
> >   (frange::verify_range): Same.
> >   (range_tests_nan): Same.
> >   (range_tests_floats): Same.
> >   * value-range.h(frange::known_finite): New.
> >   (frange::maybe_inf): New.
> >   (frange::known_inf): New.
> >   (frange::maybe_nan): New.
> >   (frange::known_nan): New.
> >   (frange::known_signbit): New.
> > ---
> >  gcc/gimple-range-fold.cc |  19 +++---
> >  gcc/range-op-float.cc|  26 
> >  gcc/value-range.cc   | 126 +++
> >  gcc/value-range.h|  78 +++-
> >  4 files changed, 170 insertions(+), 79 deletions(-)
>
> This triggers a selftest failure for pdp11:
>
> .../gcc/configure --prefix=... --enable-werror-always --enable-languages=all 
> --disable-gcov --disable-shared --disable-threads --target=pdp11-aout 
> --without-headers

I have just pushed a patch to fix this.

I have also added -ffinite-math-only selftests to my list of testing
requirements for all future frange work.

Thanks for reporting this.
Aldy

[COMMITTED] frange::set_signbit: Avoid changing sign when already in the correct sign.

[Aldy Hernandez via Gcc-patches]

We should avoid pessimizing the signbit when it's already correct.  In
this particular case we were trying to change the signbit to "unknown",
when it was obviously negative.

This test is actually slated for removal with my upcoming revamp of the
signbit and NAN tracking, per the conversations regarding tristate.  The
signbit will be removed in favor of keeping track of it in the range
itself, and NAN will just be a pair of boolean flags.  However, I don't
plan to disturb the tree until after Cauldron.

Tested on x86-64 Linux including mpfr tests.  Also tested selftests with
-ffinite-math-only on x86-64 as well as on a cross to pdp11-aout.

gcc/ChangeLog:

* value-range.cc (frange::set_signbit): Avoid changing sign when
already in the correct sign.
---
 gcc/value-range.cc | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/gcc/value-range.cc b/gcc/value-range.cc
index adcaaa2a69a..6f0609959b3 100644
--- a/gcc/value-range.cc
+++ b/gcc/value-range.cc
@@ -316,9 +316,13 @@ frange::set_signbit (fp_prop::kind k)
   // Ignore sign changes when they're set correctly.
   if (!maybe_nan ())
 {
-  if (real_less (_max, ))
+  // It's negative and we're trying to make it negative or varying.
+  if (real_less (_max, ) && (k == fp_prop::YES
+  || k == fp_prop::VARYING))
return;
-  if (real_less (, _min))
+  // It's positive and we're trying to make it positive or varying.
+  if (real_less (, _min) && (k == fp_prop::NO
+  || k == fp_prop::VARYING))
return;
 }
   // Adjust the range depending on the sign bit.
-- 
2.37.1

[PATCH] C-SKY: Fix unsigned comparison warning

[Jan-Benedict Glaw]

Hi!

When -mfloat-abi=hard support was added, a cast went missing that
used to silence a warning in common code:

/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 builtins.o -MT builtins.o -MMD -MP -MF 
./.deps/builtins.TPo ../../gcc/gcc/builtins.cc
In file included from ./tm.h:21,
 from ../../gcc/gcc/backend.h:28,
 from ../../gcc/gcc/builtins.cc:27:
../../gcc/gcc/builtins.cc: In function 'int apply_args_size()':
../../gcc/gcc/config/csky/csky.h:421:13: error: comparison of unsigned 
expression in '>= 0' is always true [-Werror=type-limits]
  421 |   (((REGNO) >= CSKY_FIRST_PARM_REGNUM\
../../gcc/gcc/builtins.cc:1444:13: note: in expansion of macro 
'FUNCTION_ARG_REGNO_P'
 1444 | if (FUNCTION_ARG_REGNO_P (regno))
  | ^~~~
cc1plus: all warnings being treated as errors
make[1]: *** [Makefile:1146: builtins.o] Error 1

The needed (int) cast is even mentioned in the comment above, so reinstate
it here.



2022-09-06  Jan-Benedict Glaw  

gcc/ChangeLog:
* config/csky/csky.h (FUNCTION_ARG_REGNO_P): Cast REGNO to (int)
to prevent warning.

diff --git a/gcc/config/csky/csky.h b/gcc/config/csky/csky.h
index 37410f0cda4..730d1b44ef1 100644
--- a/gcc/config/csky/csky.h
+++ b/gcc/config/csky/csky.h
@@ -418,7 +418,7 @@ typedef struct
The int cast is to prevent a complaint about unsigned comparison to
zero, since CSKY_FIRST_PARM_REGNUM is zero.  */
 #define FUNCTION_ARG_REGNO_P(REGNO)  \
-  (((REGNO) >= CSKY_FIRST_PARM_REGNUM\
+  (((int)(REGNO) >= CSKY_FIRST_PARM_REGNUM   \
 && (REGNO) < (CSKY_NPARM_REGS + CSKY_FIRST_PARM_REGNUM)) \
|| FUNCTION_VARG_REGNO_P(REGNO))
 

Ok for HEAD?

Thanks,
  Jan-Benedict

-- 


signature.asc
Description: PGP signature

Re: [Patch] nvptx/mkoffload.cc: Warn instead of error when reverse offload is not possible (was: Re: [Patch][2/3][v2] nvptx: libgomp+mkoffload.cc: Prepare for reverse offload fn lookup)

[Jakub Jelinek via Gcc-patches]

On Mon, Sep 12, 2022 at 02:02:16PM +0200, Tobias Burnus wrote:
> + {
> +   warning_at (input_location, 0,
> +   "% requires at "
> +   "least % for %<-march=%> - disabling "
> +   "offload-code generation for this device type");

I wonder whether it shouldn't talk about
-foffload-options=nvptx-none=-march=
instead of just -march=.

Otherwise LGTM.

Jakub

[COMMITTED] xtensa: gcc: fix builtin_apply return value

[Max Filippov via Gcc-patches]

xtensa may use up to 4 registers to return a value from a function, but
recognition of only one register in the xtensa_function_value_regno_p
and missing untyped_call pattern result in that only one register is
saved by the __builtin_apply and returned by the __builtin_apply_return.

gcc/
* config/xtensa/xtensa.cc (xtensa_function_value_regno_p):
Recognize all 4 return registers.
* config/xtensa/xtensa.h (GP_RETURN_REG_COUNT): New definition.
* config/xtensa/xtensa.md (untyped_call): New pattern.
---
 gcc/config/xtensa/xtensa.cc |  2 +-
 gcc/config/xtensa/xtensa.h  |  1 +
 gcc/config/xtensa/xtensa.md | 21 +
 3 files changed, 23 insertions(+), 1 deletion(-)

diff --git a/gcc/config/xtensa/xtensa.cc b/gcc/config/xtensa/xtensa.cc
index ac52c015a94c..f1b3331ea558 100644
--- a/gcc/config/xtensa/xtensa.cc
+++ b/gcc/config/xtensa/xtensa.cc
@@ -4472,7 +4472,7 @@ xtensa_libcall_value (machine_mode mode, const_rtx fun 
ATTRIBUTE_UNUSED)
 static bool
 xtensa_function_value_regno_p (const unsigned int regno)
 {
-  return (regno == GP_RETURN);
+  return (regno >= GP_RETURN && regno < GP_RETURN + GP_RETURN_REG_COUNT);
 }
 
 /* The static chain is passed in memory.  Provide rtx giving 'mem'
diff --git a/gcc/config/xtensa/xtensa.h b/gcc/config/xtensa/xtensa.h
index 0f3006d7af8f..16e3d55e8963 100644
--- a/gcc/config/xtensa/xtensa.h
+++ b/gcc/config/xtensa/xtensa.h
@@ -488,6 +488,7 @@ enum reg_class
point, and values of coprocessor and user-defined modes.  */
 #define GP_RETURN (GP_REG_FIRST + 2 + WINDOW_SIZE)
 #define GP_OUTGOING_RETURN (GP_REG_FIRST + 2)
+#define GP_RETURN_REG_COUNT 4
 
 /* Symbolic macros for the first/last argument registers.  */
 #define GP_ARG_FIRST (GP_REG_FIRST + 2)
diff --git a/gcc/config/xtensa/xtensa.md b/gcc/config/xtensa/xtensa.md
index f722ea562891..608110c20bcb 100644
--- a/gcc/config/xtensa/xtensa.md
+++ b/gcc/config/xtensa/xtensa.md
@@ -2305,6 +2305,27 @@
(set_attr "mode""none")
(set_attr "length"  "3")])
 
+(define_expand "untyped_call"
+  [(parallel [(call (match_operand 0 "")
+   (const_int 0))
+ (match_operand 1 "")
+ (match_operand 2 "")])]
+  ""
+{
+  int i;
+
+  emit_call_insn (gen_call (operands[0], const0_rtx));
+
+  for (i = 0; i < XVECLEN (operands[2], 0); i++)
+{
+  rtx set = XVECEXP (operands[2], 0, i);
+  emit_move_insn (SET_DEST (set), SET_SRC (set));
+}
+
+  emit_insn (gen_blockage ());
+  DONE;
+})
+
 (define_insn "entry"
   [(set (reg:SI A1_REG)
(unspec_volatile:SI [(match_operand:SI 0 "const_int_operand" "i")]
-- 
2.30.2

[Patch] nvptx/mkoffload.cc: Warn instead of error when reverse offload is not possible (was: Re: [Patch][2/3][v2] nvptx: libgomp+mkoffload.cc: Prepare for reverse offload fn lookup)

[Tobias Burnus]

On 09.09.22 17:36, Jakub Jelinek wrote:

Wonder if we instead shouldn't arrange for silent request for no PTX
offloading (or one with warning?) if sm_30 and reverse offload is needed.
Error might be too harsh, the program can still offload to GCN or host
just fine...


Attached patch now implements the warning. I think silently failing is
not the proper solution. It is too confusing and without telling the
user, they may not notice this issue.


I also changed the "progname" variable; it seems as if the only user is
the diagnostic machinery and it seems to make sense to have:

nvptx mkoffload: warning: 'omp requires reverse_offload' requires at least
'sm_35' for '-misa=' - disabling offload-code generation for this device type

instead of guessing whether "mkoffload" is for the host, gcn or nvptx. I know
that the common way is to use the binary name ("lto1") or ... but I still
think this prefix – which is the tool_name. Makes sense.

(BTW: gcc/config/i386/intelmic-mkoffload.cc uses "mkoffload-intelmic".)

I also changed "-misa=" in the diagnostic to "-march=" as Tom changed the 
default
from "-misa=" (now an alias) to "-march=" in GCC 12 (+plus added -march-map= in 
addition).

I also added a testcase for this – and updated the testsuite for the dg-warning.

OK for mainline?

Tobias

PS: As no code for nvptx is generated, there is no "device present bit not 
used" warning
with GOMP_DEBUG, but as there is a compile-time warning, I guess that's fine.


-
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
nvptx/mkoffload.cc: Warn instead of error when reverse offload is not possible

Reverse offload requests at least -misa=sm_35; with this patch, a warning
instead of an error is shown, still permitting reverse offload for all
other configured device types. This is achieved by not calling
GOMP_offload_register_ver (and stopping generating pointless 'static const char'
variables, once known.)

The tool_name as progname changes adds "nvptx " and "gcn " to the
"mkoffload: warning/error:" diagnostic.

gcc/ChangeLog:

	* config/nvptx/mkoffload.cc (process): Replace a fatal_error by
	a warning + not enabling offloading if -misa=sm_30 prevents
	reverse offload.
	(main): Use tool_name as progname for diagnostic.
	* config/gcn/mkoffload.cc (main): Likewise.

libgomp/ChangeLog:

	* libgomp.texi (Offload-Target Specifics: nvptx): Document
	that reverse offload requires >= -march=sm_35.
	* testsuite/libgomp.c-c++-common/requires-4.c: Build for nvptx
	with -misa=sm_35.
	* testsuite/libgomp.c-c++-common/requires-5.c: Likewise.
	* testsuite/libgomp.c-c++-common/requires-6.c: Likewise.
	* testsuite/libgomp.c-c++-common/reverse-offload-1.c: Likewise.
	* testsuite/libgomp.fortran/reverse-offload-1.f90: Likewise.
	* testsuite/libgomp.c/reverse-offload-sm30.c: New test.

 gcc/config/gcn/mkoffload.cc |  2 +-
 gcc/config/nvptx/mkoffload.cc   | 17 +
 libgomp/libgomp.texi|  3 +++
 libgomp/testsuite/libgomp.c-c++-common/requires-4.c |  1 +
 libgomp/testsuite/libgomp.c-c++-common/requires-5.c |  1 +
 libgomp/testsuite/libgomp.c-c++-common/requires-6.c |  2 ++
 .../testsuite/libgomp.c-c++-common/reverse-offload-1.c  |  1 +
 libgomp/testsuite/libgomp.c/reverse-offload-sm30.c  | 15 +++
 libgomp/testsuite/libgomp.fortran/reverse-offload-1.f90 |  1 +
 9 files changed, 38 insertions(+), 5 deletions(-)

diff --git a/gcc/config/gcn/mkoffload.cc b/gcc/config/gcn/mkoffload.cc
index 24d327355e3..64037806acf 100644
--- a/gcc/config/gcn/mkoffload.cc
+++ b/gcc/config/gcn/mkoffload.cc
@@ -805,7 +805,7 @@ main (int argc, char **argv)
   FILE *cfile = stdout;
   const char *outname = 0;
 
-  progname = "mkoffload";
+  progname = tool_name;
   diagnostic_initialize (global_dc, 0);
 
   obstack_init (_to_cleanup);
diff --git a/gcc/config/nvptx/mkoffload.cc b/gcc/config/nvptx/mkoffload.cc
index 834b2059aac..5f3e07ad066 100644
--- a/gcc/config/nvptx/mkoffload.cc
+++ b/gcc/config/nvptx/mkoffload.cc
@@ -324,9 +324,18 @@ process (FILE *in, FILE *out, uint32_t omp_requires)
 	{
 	  if (sm_ver && sm_ver[0] == '3' && sm_ver[1] == '0'
 	  && sm_ver[2] == '\n')
-	fatal_error (input_location,
-			 "% requires at least "
-			 "% for %<-misa=%>");
+	{
+	  warning_at (input_location, 0,
+			  "% requires at "
+			  "least % for %<-march=%> - disabling "
+			  "offload-code generation for this device type");
+	  /* As now an empty file is compiled and there is no call to
+		 GOMP_offload_register_ver, this device type is effectively
+		 disabled.  */
+	  fflush (out);
+	  ftruncate (fileno (out), 0);
+	  return;
+	}
 	  sm_ver2 = sm_ver;
 	  version2 = version;
 	}
@@ -526,7 +535,7 @@ main (int 

Re: [PATCH] testsuite: gluefile file need to be prefixed

[Richard Sandiford via Gcc-patches]

Torbjörn SVENSSON via Gcc-patches  writes:
> PR/95720
> When the status wrapper is used, the gluefile need to be prefixed with
> -Wl, in order for the test cases to have the dump files with the
> expected names.
>
> gcc/testsuite/ChangeLog:
>
> * gcc/testsuite/lib/g++.exp: Moved gluefile block to after
>   flags have been prefixed for the target_compile call.
> * gcc/testsuite/lib/gcc.exp: Likewise.
> * gcc/testsuite/lib/wrapper.exp: Reset adjusted state flag.

I agree this looks right, but I'm curious how you ended up with the
behaviour seen in comment 16.  I thought having:

if { [target_info needs_status_wrapper] != "" && [info exists gluefile] } {
lappend options "libs=${gluefile}"
lappend options "ldflags=${wrap_flags}"
}

before the dg-additional-files-options/gcc_adjusted_linker_flags would
lead to the gluefile missing a "-Wl," first time round.  How is it that
the gluefile still gets the "-Wl," and the -T misses it instead?

Thanks,
Richard

> Co-Authored-By: Yvan ROUX 
> Signed-off-by: Torbjörn SVENSSON 
> ---
>  gcc/testsuite/lib/g++.exp | 10 +-
>  gcc/testsuite/lib/gcc.exp | 21 +++--
>  gcc/testsuite/lib/wrapper.exp |  7 ++-
>  3 files changed, 22 insertions(+), 16 deletions(-)
>
> diff --git a/gcc/testsuite/lib/g++.exp b/gcc/testsuite/lib/g++.exp
> index 24ef068b239..16e61fb4ad4 100644
> --- a/gcc/testsuite/lib/g++.exp
> +++ b/gcc/testsuite/lib/g++.exp
> @@ -303,11 +303,6 @@ proc g++_target_compile { source dest type options } {
>  global flags_to_postpone
>  global board_info
>  
> -if { [target_info needs_status_wrapper] != "" && [info exists gluefile] 
> } {
> - lappend options "libs=${gluefile}"
> - lappend options "ldflags=${wrap_flags}"
> -}
> -
>  global TEST_EXTRA_LIBS
>  if [info exists TEST_EXTRA_LIBS] {
>   lappend options "ldflags=$TEST_EXTRA_LIBS"
> @@ -333,6 +328,11 @@ proc g++_target_compile { source dest type options } {
>  
>  set options [dg-additional-files-options $options $source]
>  
> +if { [target_info needs_status_wrapper] != "" && [info exists gluefile] 
> } {
> + lappend options "libs=${gluefile}"
> + lappend options "ldflags=${wrap_flags}"
> +}
> +
>  set result [target_compile $source $dest $type $options]
>  
>  if {[board_info $tboard exists multilib_flags]} {
> diff --git a/gcc/testsuite/lib/gcc.exp b/gcc/testsuite/lib/gcc.exp
> index 1b25ebec4cf..2f145d0fdf4 100644
> --- a/gcc/testsuite/lib/gcc.exp
> +++ b/gcc/testsuite/lib/gcc.exp
> @@ -129,16 +129,6 @@ proc gcc_target_compile { source dest type options } {
>  global flags_to_postpone
>  global board_info
>  
> -if {[target_info needs_status_wrapper] != "" && \
> - [target_info needs_status_wrapper] != "0" && \
> - [info exists gluefile] } {
> - lappend options "libs=${gluefile}"
> - lappend options "ldflags=$wrap_flags"
> - if { $type == "executable" } {
> - set options [concat "{additional_flags=-dumpbase \"\"}" $options]
> - }
> -}
> -
>  global TEST_EXTRA_LIBS
>  if [info exists TEST_EXTRA_LIBS] {
>   lappend options "ldflags=$TEST_EXTRA_LIBS"
> @@ -170,6 +160,17 @@ proc gcc_target_compile { source dest type options } {
>  lappend options "timeout=[timeout_value]"
>  lappend options "compiler=$GCC_UNDER_TEST"
>  set options [dg-additional-files-options $options $source]
> +
> +if {[target_info needs_status_wrapper] != "" && \
> + [target_info needs_status_wrapper] != "0" && \
> + [info exists gluefile] } {
> + lappend options "libs=${gluefile}"
> + lappend options "ldflags=$wrap_flags"
> + if { $type == "executable" } {
> + set options [concat "{additional_flags=-dumpbase \"\"}" $options]
> + }
> +}
> +
>  set return_val [target_compile $source $dest $type $options]
>  
>  if {[board_info $tboard exists multilib_flags]} {
> diff --git a/gcc/testsuite/lib/wrapper.exp b/gcc/testsuite/lib/wrapper.exp
> index 5a601b269da..4a7d56941fc 100644
> --- a/gcc/testsuite/lib/wrapper.exp
> +++ b/gcc/testsuite/lib/wrapper.exp
> @@ -22,7 +22,7 @@
>  # the compiler when compiling FILENAME.
>  
>  proc ${tool}_maybe_build_wrapper { filename args } {
> -global gluefile wrap_flags
> +global gluefile wrap_flags gcc_adjusted_linker_flags
>  
>  if { [target_info needs_status_wrapper] != "" \
>&& [target_info needs_status_wrapper] != "0" \
> @@ -43,6 +43,11 @@ proc ${tool}_maybe_build_wrapper { filename args } {
>   if { $result != "" } {
>   set gluefile [lindex $result 0]
>   set wrap_flags [lindex $result 1]
> +
> + # Reset the cached state of the adjusted flags
> + if { [info exists gcc_adjusted_linker_flags] } {
> + set gcc_adjusted_linker_flags 0
> + }
>   }
>  }
>  }

Re: [committed] libstdc++: Find make_error_code and make_error_condition via ADL only

[Jonathan Wakely via Gcc-patches]

On Mon, 12 Sept 2022 at 11:55, Daniel Krügler  wrote:
>
> Am Do., 8. Sept. 2022 um 20:30 Uhr schrieb Jonathan Wakely via
> Libstdc++ :
> >
> > Tested powerpc64le-linux, pushed to trunk.
> >
> > -- >8 --
> >
> > The new proposed resolution for LWG 3629 says that std::error_code and
> > std::error_condition should only use ADL to find their customization
> > points. This means we need to use a poison pill to prevent lookup from
> > finding overloads in the enclosing namespaces.
> >
> > We can also remove the forward declarations of std::make_error_code and
> > std::make_error_condition, because they aren't needed now. ADL can find
> > them anyway (when std is an associated namespace), and unqualified name
> > lookup will not (and should not) find them.
> >
> > libstdc++-v3/ChangeLog:
> >
> > * include/std/system_error (__adl_only::make_error_code): Add
> > deleted function.
> > (__adl_only::make_error_condition): Likewise.
> > (error_code::error_code(ErrorCodeEnum)): Add using-declaration
> > for deleted function.
> > (error_condition::error_condition(ErrorConditionEnum)):
> > Likewise.
> > * testsuite/19_diagnostics/error_code/cons/lwg3629.cc: New test.
> > * testsuite/19_diagnostics/error_condition/cons/lwg3629.cc: New 
> > test.
> > ---
> [..]
> > +// { dg-do compile { target c++11 } }
> > +
> > +// 3629. make_error_code and make_error_condition are customization points
> > +// Verify that make_error_code is looked up using ADL only.
> > +
> > +namespace user
> > +{
> > +  struct E1;
> > +}
> > +
> > +// N.B. not in associated namespace of E1, and declared before 
> > .
> > +user::E1 make_error_code(user::E1);
> > +
> > +#include  // declares std::make_error_code(future_errc)
> > +#include 
> > +
> > +namespace user
> > +{
> > +  struct E1
> > +  {
> > +operator std::error_code() const;
> > +  };
> > +
> > +  struct E2
> > +  {
> > +operator std::future_errc() const;
> > +  };
> > +
> > +  struct E3
> > +  {
> > +operator std::errc() const;
> > +  };
> > +}
> > +
> > +template<> struct std::is_error_code_enum : std::true_type { };
> > +template<> struct std::is_error_code_enum : std::true_type { };
> > +template<> struct std::is_error_code_enum : std::true_type { };
> > +
> > +// ::make_error_code(E1) should not be found by name lookup.
> > +std::error_code e1( user::E1{} ); // { dg-error "here" }
> > +
> > +// std::make_error_code(errc) should not be found by name lookup.
> > +std::error_code e2( user::E2{} ); // { dg-error "here" }
>
> (1) Unless I'm misunderstanding something here, the comment above
> doesn't match here, it should mention (std::)future_errc instead.
>
> > +// std::make_error_code(future_errc) should not be found by name lookup.
> > +std::error_code e3( user::E3{} ); // { dg-error "here" }
>
> (2) Unless I'm misunderstanding something here, the comment above
> doesn't match here, it should mention (std::)errc instead.
>
> > +// { dg-error "use of deleted function" "" { target *-*-* } 0 }
> > diff --git 
> > a/libstdc++-v3/testsuite/19_diagnostics/error_condition/cons/lwg3629.cc 
> > b/libstdc++-v3/testsuite/19_diagnostics/error_condition/cons/lwg3629.cc
> > new file mode 100644
> > index 000..e34b53de8a1
> > --- /dev/null
> > +++ b/libstdc++-v3/testsuite/19_diagnostics/error_condition/cons/lwg3629.cc
> > @@ -0,0 +1,48 @@
> > +// { dg-do compile { target c++11 } }
> > +
> > +// 3629. make_error_code and make_error_condition are customization points
> > +// Verify that make_error_condition is looked up using ADL only.
> > +
> > +namespace user
> > +{
> > +  struct E1;
> > +}
> > +
> > +// N.B. not in associated namespace of E1, and declared before 
> > .
> > +user::E1 make_error_condition(user::E1);
> > +
> > +#include  // declares std::make_error_condition(future_errc)
> > +#include 
> > +
> > +namespace user
> > +{
> > +  struct E1
> > +  {
> > +operator std::error_code() const;
> > +  };
> > +
> > +  struct E2
> > +  {
> > +operator std::future_errc() const;
> > +  };
> > +
> > +  struct E3
> > +  {
> > +operator std::errc() const;
> > +  };
> > +}
> > +
> > +template<> struct std::is_error_condition_enum : std::true_type 
> > { };
> > +template<> struct std::is_error_condition_enum : std::true_type 
> > { };
> > +template<> struct std::is_error_condition_enum : std::true_type 
> > { };
> > +
> > +// ::make_error_condition(E1) should not be found by name lookup.
> > +std::error_condition e1( user::E1{} ); // { dg-error "here" }
> > +
> > +// std::make_error_condition(errc) should not be found by name lookup.
> > +std::error_condition e2( user::E2{} ); // { dg-error "here" }
>
> Ditto here (1)
>
> > +// std::make_error_condition(future_errc) should not be found by name 
> > lookup.
> > +std::error_condition e3( user::E3{} ); // { dg-error "here" }
>
> Ditto here (2)


Good catch, thanks.

Fixed by the attached patch, tested x86_64-linux and pushed to trunk.
commit 

Re: [committed] libstdc++: Find make_error_code and make_error_condition via ADL only

[Daniel Krügler via Gcc-patches]

Am Do., 8. Sept. 2022 um 20:30 Uhr schrieb Jonathan Wakely via
Libstdc++ :
>
> Tested powerpc64le-linux, pushed to trunk.
>
> -- >8 --
>
> The new proposed resolution for LWG 3629 says that std::error_code and
> std::error_condition should only use ADL to find their customization
> points. This means we need to use a poison pill to prevent lookup from
> finding overloads in the enclosing namespaces.
>
> We can also remove the forward declarations of std::make_error_code and
> std::make_error_condition, because they aren't needed now. ADL can find
> them anyway (when std is an associated namespace), and unqualified name
> lookup will not (and should not) find them.
>
> libstdc++-v3/ChangeLog:
>
> * include/std/system_error (__adl_only::make_error_code): Add
> deleted function.
> (__adl_only::make_error_condition): Likewise.
> (error_code::error_code(ErrorCodeEnum)): Add using-declaration
> for deleted function.
> (error_condition::error_condition(ErrorConditionEnum)):
> Likewise.
> * testsuite/19_diagnostics/error_code/cons/lwg3629.cc: New test.
> * testsuite/19_diagnostics/error_condition/cons/lwg3629.cc: New test.
> ---
[..]
> +// { dg-do compile { target c++11 } }
> +
> +// 3629. make_error_code and make_error_condition are customization points
> +// Verify that make_error_code is looked up using ADL only.
> +
> +namespace user
> +{
> +  struct E1;
> +}
> +
> +// N.B. not in associated namespace of E1, and declared before 
> .
> +user::E1 make_error_code(user::E1);
> +
> +#include  // declares std::make_error_code(future_errc)
> +#include 
> +
> +namespace user
> +{
> +  struct E1
> +  {
> +operator std::error_code() const;
> +  };
> +
> +  struct E2
> +  {
> +operator std::future_errc() const;
> +  };
> +
> +  struct E3
> +  {
> +operator std::errc() const;
> +  };
> +}
> +
> +template<> struct std::is_error_code_enum : std::true_type { };
> +template<> struct std::is_error_code_enum : std::true_type { };
> +template<> struct std::is_error_code_enum : std::true_type { };
> +
> +// ::make_error_code(E1) should not be found by name lookup.
> +std::error_code e1( user::E1{} ); // { dg-error "here" }
> +
> +// std::make_error_code(errc) should not be found by name lookup.
> +std::error_code e2( user::E2{} ); // { dg-error "here" }

(1) Unless I'm misunderstanding something here, the comment above
doesn't match here, it should mention (std::)future_errc instead.

> +// std::make_error_code(future_errc) should not be found by name lookup.
> +std::error_code e3( user::E3{} ); // { dg-error "here" }

(2) Unless I'm misunderstanding something here, the comment above
doesn't match here, it should mention (std::)errc instead.

> +// { dg-error "use of deleted function" "" { target *-*-* } 0 }
> diff --git 
> a/libstdc++-v3/testsuite/19_diagnostics/error_condition/cons/lwg3629.cc 
> b/libstdc++-v3/testsuite/19_diagnostics/error_condition/cons/lwg3629.cc
> new file mode 100644
> index 000..e34b53de8a1
> --- /dev/null
> +++ b/libstdc++-v3/testsuite/19_diagnostics/error_condition/cons/lwg3629.cc
> @@ -0,0 +1,48 @@
> +// { dg-do compile { target c++11 } }
> +
> +// 3629. make_error_code and make_error_condition are customization points
> +// Verify that make_error_condition is looked up using ADL only.
> +
> +namespace user
> +{
> +  struct E1;
> +}
> +
> +// N.B. not in associated namespace of E1, and declared before 
> .
> +user::E1 make_error_condition(user::E1);
> +
> +#include  // declares std::make_error_condition(future_errc)
> +#include 
> +
> +namespace user
> +{
> +  struct E1
> +  {
> +operator std::error_code() const;
> +  };
> +
> +  struct E2
> +  {
> +operator std::future_errc() const;
> +  };
> +
> +  struct E3
> +  {
> +operator std::errc() const;
> +  };
> +}
> +
> +template<> struct std::is_error_condition_enum : std::true_type { 
> };
> +template<> struct std::is_error_condition_enum : std::true_type { 
> };
> +template<> struct std::is_error_condition_enum : std::true_type { 
> };
> +
> +// ::make_error_condition(E1) should not be found by name lookup.
> +std::error_condition e1( user::E1{} ); // { dg-error "here" }
> +
> +// std::make_error_condition(errc) should not be found by name lookup.
> +std::error_condition e2( user::E2{} ); // { dg-error "here" }

Ditto here (1)

> +// std::make_error_condition(future_errc) should not be found by name lookup.
> +std::error_condition e3( user::E3{} ); // { dg-error "here" }

Ditto here (2)

> +// { dg-error "use of deleted function" "" { target *-*-* } 0 }
> --
> 2.37.3

- Daniel

Re: [PATCH 1/2] Add new target hook: constant_ok_for_cprop_p

[Jeff Law via Gcc-patches]

On 9/12/22 01:35, Richard Biener via Gcc-patches wrote:

On Sun, Sep 11, 2022 at 10:51 PM Takayuki 'January June' Suwa via
Gcc-patches  wrote:

Hi,

Many RISC machines, as we know, have some restrictions on placing 
register-width constants in the source of load-immediate machine instructions, 
so the target must provide a solution for that in the machine description.

A naive way would be to solve it early, ie. to replace with read constants 
pooled in memory when expanding to RTL.

Alternatively, a more fancy approach would be to forgo placement in the constant pool 
until somewhere before the reload/LRA eg. the "split1" pass to give the 
optimization passes that involve immediates a chance to work.

If we choose the latter, we can expect better results with RTL if-conversion, 
constant folding, etc., but it often propagates constants that are too large in 
size to resolve to a simple load-immediate instruction.

This is because constant propagation has no way of telling about it, so this 
patch provides it.

What does prevent other passes like fwprop, CSE and PRE from doing the
same propagation?  Can that be the solution for
constant propagation as well?


I would think this should be driven by costing rather than a new hook.  
I'm pretty sure we already use costing to determine some of this stuff 
for CSE/PRE.



jeff

Re: [PATCH] PR rtl-optimization/106594: Preserve zero_extend when cheap.

[Richard Sandiford via Gcc-patches]

"Roger Sayle"  writes:
> This patch addresses PR rtl-optimization/106594, a significant performance
> regression affecting aarch64 recently introduced (exposed) by one of my
> recent RTL simplification improvements.  Firstly many thanks to
> Tamar Christina for confirming that the core of this patch provides ~5%
> performance improvement on some on his benchmarks.
>
> GCC's combine pass uses the function expand_compound_operation to
> conceptually simplify/canonicalize SIGN_EXTEND and ZERO_EXTEND as
> a pair of shift operations, as not all targets support extension
> instructions [technically ZERO_EXTEND may potentially be simplified/
> canonicalized to an AND operation, but the theory remains the same].

Are you sure the reason is that not all targets support extension
instructions?  I thought in practice this routine would only tend
to see ZEOR_EXTEND etc. if those codes appeared in the original rtl
insns.

Like you say earlier, I'd thought it was a (pure) canonicalisation
thing: try to have only one representation of an operation before
simplifying/combining, rather than multiple representations.  Then
make_compound_operation was supposed to do the opposite operation
after simplifying/combining.

On that basis…

> In that function, around line 7226 of combine.cc, there's an optimization
> that's remarkably similar to part of my recent simplify-rtx patch posted
> at https://gcc.gnu.org/pipermail/gcc-patches/2022-August/599196.html
> The comment above this code reads:
>
>   /* Convert sign extension to zero extension, if we know that the high
>  bit is not set, as this is easier to optimize.  It will be converted
>  back to cheaper alternative in make_extraction.  */
>
> which is exactly the SIGN_EXTEND to ZERO_EXTEND canonicalization that
> we now perform in simplify-rtx.  The significant difference is that this
> code checks the backend's RTL costs, via set_src_cost, and selects either
> the SIGN_EXTEND, the ZERO_EXTEND or the pair of SHIFTs depending on which
> is cheaper.
>
> The problem is that now that SIGN_EXTEND is converted to ZERO_EXTEND
> earlier, this transform/check is no longer triggered, and as a result the
> incoming ZERO_EXTEND is always converted to a pair of shifts, irrespective
> of the backend's costs.  The latent bug, revealed by benchmarking, is that
> we should avoid converting SIGN_EXTEND or ZERO_EXTEND into (slower) shifts
> on targets where extensions are cheap (i.e. a single instruction, that's
> cheaper than two shift instructions, or as cheap as an AND).

…I don't think the expectation was that shifts were cheaper than/as cheap
as the original expressions.  On most targets the shifts will be more
expensive.  It was more that we had (sometimes misplaced) faith in
make_compound_operation's being able to switch back to the compound
operations if they were supported/cheaper.

So it feels like taking rtx costs into account is muddying the waters.
But like you say, that line has already been crossed.  The (existing)
code in question is:

  /* Convert sign extension to zero extension, if we know that the high
 bit is not set, as this is easier to optimize.  It will be converted
 back to cheaper alternative in make_extraction.  */
  if (GET_CODE (x) == SIGN_EXTEND
  && HWI_COMPUTABLE_MODE_P (mode)
  && ((nonzero_bits (XEXP (x, 0), inner_mode)
   & ~(((unsigned HOST_WIDE_INT) GET_MODE_MASK (inner_mode)) >> 1))
  == 0))
{
  rtx temp = gen_rtx_ZERO_EXTEND (mode, XEXP (x, 0));
  rtx temp2 = expand_compound_operation (temp);

  /* Make sure this is a profitable operation.  */
  if (set_src_cost (x, mode, optimize_this_for_speed_p)
  > set_src_cost (temp2, mode, optimize_this_for_speed_p))
   return temp2;
  else if (set_src_cost (x, mode, optimize_this_for_speed_p)
   > set_src_cost (temp, mode, optimize_this_for_speed_p))
   return temp;
  else
   return x;
}

I can see an argument for using rtx costs to switch between an
expand_compound_operation of a SIGN_EXTEND and an expand_compound_operation
of a ZERO_EXTEND, given that this is one case where even e_c_o can't give
a single, unique representation.  But it feels odd to be returning an
unexpanded SIGN_EXTEND or ZERO_EXTEND when the purpose of the routine
is to expand them.  (And it rtx costs *are* supposed to influence the
choice between the SIGN_EXTEND-based and ZERO_EXTEND-based expansions,
it feels like we should have corresponding code for when the original
operation is a ZERO_EXTEND.)

Obviously Segher's call, not mine.  But given that we already have
the code above, I think it'd be worth clarifying what the
expand/make_compound_operation pair are supposed to do and when.

Thanks,
Richard

> This core fix (and performance improvement) is the first chunk of the
> attached patch.  Unfortunately (as is often the case), as soon as you
> tweak the RTL stream/canonical forms of instructions, you expose a number
> of missed 

[committed] doc: Fix typo in documentation of __float128 suffix

[Jonathan Wakely via Gcc-patches]

This typo has gone unnoticed for 15 years.  I had to check whether it
was supposed to say __float128 or _Float128, but based on the commit
that added it, the answer was obviously __float128.

Committed as obvious.

-- >8 --

gcc/ChangeLog:

* doc/extend.texi (Floating Types): Fix "_float128" typo.
---
 gcc/doc/extend.texi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index be3ea890c47..a5afb467d23 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -1109,7 +1109,7 @@ add, subtract, multiply, divide; unary arithmetic 
operators;
 relational operators; equality operators; and conversions to and from
 integer and other floating types.  Use a suffix @samp{w} or @samp{W}
 in a literal constant of type @code{__float80} or type
-@code{__ibm128}.  Use a suffix @samp{q} or @samp{Q} for @code{_float128}.
+@code{__ibm128}.  Use a suffix @samp{q} or @samp{Q} for @code{__float128}.
 
 In order to use @code{_Float128}, @code{__float128}, and @code{__ibm128}
 on PowerPC Linux systems, you must use the @option{-mfloat128} option. It is
-- 
2.37.3

Re: [PATCH] gcc: honour -ffile-prefix-map in ASM_MAP [PR93371]

[Rasmus Villemoes]

On 29/08/2022 11.29, Rasmus Villemoes wrote:
> -ffile-prefix-map is supposed to be a superset of -fmacro-prefix-map
> and -fdebug-prefix-map. However, when building .S or .s files, gas is
> not called with the appropriate --debug-prefix-map option when
> -ffile-prefix-map is used.
> 
> While the user can specify -fdebug-prefix-map when building assembly
> files via gcc, it's more ergonomic to also support -ffile-prefix-map;
> especially since for .S files that could contain the __FILE__ macro,
> one would then also have to specify -fmacro-prefix-map.
> 
> gcc:
>   PR driver/93371
>   * gcc.cc (ASM_MAP): Honour -ffile-prefix-map.
> ---
> 
> I've tested that this works as expected, both by looking at how gas is
> now invoked, and by running 'strings' on the generated .o file. But I
> don't know how to add something to the testsuite for this.

Is this ok for trunk? If so, how about older maintained branches?

And does anyone have ideas for how I could add a test case?


> 
> I stumbled on this since it came up on the U-Boot mailing list:
> https://lore.kernel.org/u-boot/4ed9f811-5244-54ef-b58e-83dba5151...@prevas.dk/
> .
> 
>  gcc/gcc.cc | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/gcc/gcc.cc b/gcc/gcc.cc
> index b6d562a92f0..44eafc60187 100644
> --- a/gcc/gcc.cc
> +++ b/gcc/gcc.cc
> @@ -878,7 +878,7 @@ proper position among the other output files.  */
>  #endif
>  
>  #ifdef HAVE_AS_DEBUG_PREFIX_MAP
> -#define ASM_MAP " %{fdebug-prefix-map=*:--debug-prefix-map %*}"
> +#define ASM_MAP " %{ffile-prefix-map=*:--debug-prefix-map %*} 
> %{fdebug-prefix-map=*:--debug-prefix-map %*}"
>  #else
>  #define ASM_MAP ""
>  #endif

Re: [PATCH v2] gcov: Respect triplet when looking for gcov

[Martin Liška]

On 9/12/22 11:39, Torbjorn SVENSSON wrote:
> On 2022-09-12 10:40, Martin Liška wrote:
>> On 9/12/22 09:06, Torbjorn SVENSSON via Gcc-patches wrote:
>>>
>>>
>>> On 2022-09-11 21:38, Mikael Morin wrote:
 Le 11/09/2022 à 18:04, Torbjorn SVENSSON a écrit :
> Can you fix it for me and submit it or do you want me to send a v3?

 For trivial things like this, there is no need for a v3 (nor was there for 
 a v2).
 Do you miss a git write account and need someone to push for you?
>>>
>>> Ok!
>>>
>>> I do not have any write access, so yes, please push it for me!
>>
>> Please attach a patch with git format-patch and I'm going to push it now.
>>
>> Cheers,
>> Martin
> 
> Patch attached as requested.

Thanks.

Pushed with a small correction of the commit message:
remote: *** ChangeLog format failed:
remote: *** ERR: line should start with a tab: "* g++.dg/gcov/gcov.exp: 
Respect triplet when looking for gcov."
remote: *** ERR: line should start with a tab: "* 
gcc.misc-tests/gcov.exp: Likewise."

as 34b9a03353d3fdc5c57f2708469d0df78c6d6508.

Cheers,
Martin

Re: [PATCH v2] gcov: Respect triplet when looking for gcov

[Torbjorn SVENSSON via Gcc-patches]

On 2022-09-12 10:40, Martin Liška wrote:

On 9/12/22 09:06, Torbjorn SVENSSON via Gcc-patches wrote:



On 2022-09-11 21:38, Mikael Morin wrote:

Le 11/09/2022 à 18:04, Torbjorn SVENSSON a écrit :

Can you fix it for me and submit it or do you want me to send a v3?


For trivial things like this, there is no need for a v3 (nor was there for a 
v2).
Do you miss a git write account and need someone to push for you?


Ok!

I do not have any write access, so yes, please push it for me!


Please attach a patch with git format-patch and I'm going to push it now.

Cheers,
Martin


Patch attached as requested.From 0400f4b34a62ad5a54e87c537b4a41bc630fd105 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Torbj=C3=B6rn=20SVENSSON?= 
Date: Fri, 9 Sep 2022 12:19:27 +0200
Subject: [PATCH] gcov: Respect triplet when looking for gcov
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

When testing a cross toolchain outside the build tree, the binary name
for gcov is prefixed with the triplet.

gcc/testsuite/ChangeLog:

* g++.dg/gcov/gcov.exp: Respect triplet when looking for gcov.
* gcc.misc-tests/gcov.exp: Likewise.

Signed-off-by: Torbjörn SVENSSON 
---
 gcc/testsuite/g++.dg/gcov/gcov.exp| 4 ++--
 gcc/testsuite/gcc.misc-tests/gcov.exp | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/gcc/testsuite/g++.dg/gcov/gcov.exp 
b/gcc/testsuite/g++.dg/gcov/gcov.exp
index 88acd95c361..04e7a016486 100644
--- a/gcc/testsuite/g++.dg/gcov/gcov.exp
+++ b/gcc/testsuite/g++.dg/gcov/gcov.exp
@@ -24,9 +24,9 @@ global GXX_UNDER_TEST
 
 # Find gcov in the same directory as $GXX_UNDER_TEST.
 if { ![is_remote host] && [string match "*/*" [lindex $GXX_UNDER_TEST 0]] } {
-set GCOV [file dirname [lindex $GXX_UNDER_TEST 0]]/gcov
+set GCOV [file dirname [lindex $GXX_UNDER_TEST 0]]/[transform gcov]
 } else {
-set GCOV gcov
+set GCOV [transform gcov]
 }
 
 # Initialize harness.
diff --git a/gcc/testsuite/gcc.misc-tests/gcov.exp 
b/gcc/testsuite/gcc.misc-tests/gcov.exp
index 82376d90ac2..b8e9661aa53 100644
--- a/gcc/testsuite/gcc.misc-tests/gcov.exp
+++ b/gcc/testsuite/gcc.misc-tests/gcov.exp
@@ -24,9 +24,9 @@ global GCC_UNDER_TEST
 
 # For now find gcov in the same directory as $GCC_UNDER_TEST.
 if { ![is_remote host] && [string match "*/*" [lindex $GCC_UNDER_TEST 0]] } {
-set GCOV [file dirname [lindex $GCC_UNDER_TEST 0]]/gcov
+set GCOV [file dirname [lindex $GCC_UNDER_TEST 0]]/[transform gcov]
 } else {
-set GCOV gcov
+set GCOV [transform gcov]
 }
 
 # Initialize harness.
-- 
2.25.1

Re: Patch ping^3 ([PATCH] libstdc++: Outline the overlapping case of string _M_replace into a separate function [PR105329])

[Jonathan Wakely via Gcc-patches]

On Mon, 12 Sept 2022 at 10:16, Jakub Jelinek  wrote:
>
> On Wed, Aug 31, 2022 at 11:38:58AM +0200, Jakub Jelinek via Gcc-patches wrote:
> > On Wed, Aug 10, 2022 at 01:27:51PM +0200, Jakub Jelinek via Gcc-patches 
> > wrote:
> > > On Wed, Jul 27, 2022 at 11:33:29AM +0200, Jakub Jelinek via Gcc-patches 
> > > wrote:
> > > > The following patch is partially a workaround for bogus warnings
> > > > when the compiler isn't able to fold _M_disjunct call into constant
> > > > false, but also an optimization attempt - assuming _M_disjunct (__s)
> > > > is rare, the patch should shrink code size for the common case and
> > > > use library or for non-standard instantiations an out of line
> > > > function to handle the rare case.
> > >
> > > I'd like to ping this patch.
> >
> > I'd like to ping this patch again.
> > https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598896.html
>
> Ping again.


OK for trunk, sorry for the slow review.

Patch ping^3 ([PATCH] libstdc++: Outline the overlapping case of string _M_replace into a separate function [PR105329])

[Jakub Jelinek via Gcc-patches]

On Wed, Aug 31, 2022 at 11:38:58AM +0200, Jakub Jelinek via Gcc-patches wrote:
> On Wed, Aug 10, 2022 at 01:27:51PM +0200, Jakub Jelinek via Gcc-patches wrote:
> > On Wed, Jul 27, 2022 at 11:33:29AM +0200, Jakub Jelinek via Gcc-patches 
> > wrote:
> > > The following patch is partially a workaround for bogus warnings
> > > when the compiler isn't able to fold _M_disjunct call into constant
> > > false, but also an optimization attempt - assuming _M_disjunct (__s)
> > > is rare, the patch should shrink code size for the common case and
> > > use library or for non-standard instantiations an out of line
> > > function to handle the rare case.
> > 
> > I'd like to ping this patch.
> 
> I'd like to ping this patch again.
> https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598896.html

Ping again.

Thanks.

Jakub

Re: [patch] libgomp.texi: Impl. status fix/addition

[Jakub Jelinek via Gcc-patches]

On Mon, Sep 12, 2022 at 11:04:08AM +0200, Tobias Burnus wrote:
> This patch is about the OpenMP 5.{1,2} implementation status.
> 
> For omp/ompx/omx, I think it was a bit misleading. omp/ompx (and omx)
> are reserved namespaces; for 'omp' nothing needs to be done (either
> already implemented or not), while for 'ompx'/'omx' (vendor extension),
> the note + footnote tries to describe what happens. – I hope the revised
> wording is clearer.
> 
> The other change is about two OpenMP 5.1 items; the first one seems to
> get used in some code – 'begin declare target' is essentially the same
> as 'declare target' ... 'end declare target' but additionally permits
> clauses.
> 
> And the second new item: I think it was regarded as bug fix, but I
> personally read it rather as change. The question is as what to read it
> and how to handle it? Initially I wrote and thought of it as deprecation
> of the previous syntax, i.e. warning but only once the OpenMP version
> has been bumped to 5.2's. I now think we could diagnose it earlier – IMO
> a warning would be sufficient, but it could also be read it such that an
> error is required. – Thoughts about this item + what to implement?

IMNSHO we should support it without any diagnostics until the big
deprecation day of 5.2 (when we are almost done with 5.2 and add all the
-Wdeprecated stuff there).
It is very similar to many other 5.2 changes, introduce a new syntax and
deprecate the old one.

> libgomp.texi: Impl. status fix/addition
> 
> libgomp/ChangeLog:
> 
>   * libgomp.texi (OpenMP 5.1 Impl. Status): Add two new minor items.
>   (OpenMP 5.2 Impl. Status): Improve omp/omx/ompx wording.
> 
> diff --git a/libgomp/libgomp.texi b/libgomp/libgomp.texi
> index 3dc467aade0..7db5fab580a 100644
> --- a/libgomp/libgomp.texi
> +++ b/libgomp/libgomp.texi
> @@ -348,6 +348,9 @@ The OpenMP 4.5 specification is fully supported.
>  @item Support @code{begin/end declare target} syntax in C/C++ @tab N @tab
>  @item Pointer predetermined firstprivate getting initialized
>  to address of matching mapped list item per 5.1, Sect. 2.21.7.2 @tab N @tab
> +@item @code{begin declare target} directive @tab N @tab
> +@item For Fortran, diagnose placing declarative before/between @code{USE},
> +  @code{IMPORT}, and @code{IMPLICIT} as invalid @tab N @tab
>  @end multitable
>  
>  
> @@ -362,12 +365,13 @@ to address of matching mapped list item per 5.1, Sect. 
> 2.21.7.2 @tab N @tab
>@tab N @tab
>  @item @code{omp}/@code{ompx}/@code{omx} sentinels and 
> @code{omp_}/@code{ompx_}
>namespaces @tab N/A
> -  @tab warning for @code{omp/ompx} sentinels@footnote{@code{omp/ompx}
> -  sentinels as C/C++ pragma and C++ attributes are warned for with
> +  @tab warning for @code{ompx/omx} sentinels@footnote{The @code{ompx}
> +  sentinel as C/C++ pragma and C++ attributes are warned for with
>@code{-Wunknown-pragmas} (implied by @code{-Wall}) and 
> @code{-Wattributes}
>(enabled by default), respectively; for Fortran free-source code, 
> there is
> -  a warning enabled by default and for fixed-source code with
> -  @code{-Wsurprising} (enabled by @code{-Wall})}
> +  a warning enabled by default and, for fixed-source code, the @code{omx}
> +  sentinel is warned for with with @code{-Wsurprising} (enabled by
> +  @code{-Wall}). Unknown clauses are always rejected with an error.}

Two spaces after ., not just one.
Otherwise LGTM.

Jakub

[patch] libgomp.texi: Impl. status fix/addition

[Tobias Burnus]

This patch is about the OpenMP 5.{1,2} implementation status.

For omp/ompx/omx, I think it was a bit misleading. omp/ompx (and omx)
are reserved namespaces; for 'omp' nothing needs to be done (either
already implemented or not), while for 'ompx'/'omx' (vendor extension),
the note + footnote tries to describe what happens. – I hope the revised
wording is clearer.

The other change is about two OpenMP 5.1 items; the first one seems to
get used in some code – 'begin declare target' is essentially the same
as 'declare target' ... 'end declare target' but additionally permits
clauses.

And the second new item: I think it was regarded as bug fix, but I
personally read it rather as change. The question is as what to read it
and how to handle it? Initially I wrote and thought of it as deprecation
of the previous syntax, i.e. warning but only once the OpenMP version
has been bumped to 5.2's. I now think we could diagnose it earlier – IMO
a warning would be sufficient, but it could also be read it such that an
error is required. – Thoughts about this item + what to implement?

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
libgomp.texi: Impl. status fix/addition

libgomp/ChangeLog:

	* libgomp.texi (OpenMP 5.1 Impl. Status): Add two new minor items.
	(OpenMP 5.2 Impl. Status): Improve omp/omx/ompx wording.

diff --git a/libgomp/libgomp.texi b/libgomp/libgomp.texi
index 3dc467aade0..7db5fab580a 100644
--- a/libgomp/libgomp.texi
+++ b/libgomp/libgomp.texi
@@ -348,6 +348,9 @@ The OpenMP 4.5 specification is fully supported.
 @item Support @code{begin/end declare target} syntax in C/C++ @tab N @tab
 @item Pointer predetermined firstprivate getting initialized
 to address of matching mapped list item per 5.1, Sect. 2.21.7.2 @tab N @tab
+@item @code{begin declare target} directive @tab N @tab
+@item For Fortran, diagnose placing declarative before/between @code{USE},
+  @code{IMPORT}, and @code{IMPLICIT} as invalid @tab N @tab
 @end multitable
 
 
@@ -362,12 +365,13 @@ to address of matching mapped list item per 5.1, Sect. 2.21.7.2 @tab N @tab
   @tab N @tab
 @item @code{omp}/@code{ompx}/@code{omx} sentinels and @code{omp_}/@code{ompx_}
   namespaces @tab N/A
-  @tab warning for @code{omp/ompx} sentinels@footnote{@code{omp/ompx}
-  sentinels as C/C++ pragma and C++ attributes are warned for with
+  @tab warning for @code{ompx/omx} sentinels@footnote{The @code{ompx}
+  sentinel as C/C++ pragma and C++ attributes are warned for with
   @code{-Wunknown-pragmas} (implied by @code{-Wall}) and @code{-Wattributes}
   (enabled by default), respectively; for Fortran free-source code, there is
-  a warning enabled by default and for fixed-source code with
-  @code{-Wsurprising} (enabled by @code{-Wall})}
+  a warning enabled by default and, for fixed-source code, the @code{omx}
+  sentinel is warned for with with @code{-Wsurprising} (enabled by
+  @code{-Wall}). Unknown clauses are always rejected with an error.}
 @item Clauses on @code{end} directive can be on directive @tab N @tab
 @item Deprecation of no-argument @code{destroy} clause on @code{depobj}
   @tab N @tab

[committed] libgomp: Fix up icv-6.c [PR106894]

[Jakub Jelinek via Gcc-patches]

Hi!

The thing is,
make check
or
make check RUNTESTFLAGS="c.exp='icv-6.c' c++.exp='icv-6.c'"
in libgomp obj dir work fine, but
make -j32 -k check RUNTESTFLAGS="c.exp='icv-6.c' c++.exp='icv-6.c'"
fails.
The thing is that the testcase as written relies on OMP_NUM_THREADS not being
set in environment (as it takes priority over OMP_NUM_THREADS_ALL for the
host).
So, if either a user has OMP_NUM_THREADS=42 in the environment by himself, or
when doing make check with -jN, we trigger:
  if test $$num_cpus -gt 8 && test -z "$$OMP_NUM_THREADS"; then \
OMP_NUM_THREADS=8; export OMP_NUM_THREADS; \
echo @@@ libgomp OMP_NUM_THREADS adjusted to 8 because of parallel
make check and too many CPUs; \
  fi; \
in libgomp/testsuite/Makefile.am and so the test fails.

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

2022-09-12  Jakub Jelinek  

PR libgomp/106894
* testsuite/libgomp.c-c++-common/icv-6.c: Include string.h.
(main): Avoid tests for which corresponding non-_ALL suffixed variable
is in the environment, or for OMP_NUM_TEAMS on the device
OMP_NUM_TEAMS_DEV_?.

--- libgomp/testsuite/libgomp.c-c++-common/icv-6.c.jj   2022-09-08 
20:22:07.903182970 +0200
+++ libgomp/testsuite/libgomp.c-c++-common/icv-6.c  2022-09-09 
17:00:36.409255776 +0200
@@ -17,6 +17,7 @@
 
 #include 
 #include 
+#include 
 
 int
 main ()
@@ -25,21 +26,28 @@ main ()
   int chunk_size;
   omp_get_schedule(, _size);
 
-  if (omp_get_max_teams () != 42
-  || !omp_get_dynamic ()
-  || kind != 3 || chunk_size != 4
-  || omp_get_teams_thread_limit () != 44
-  || omp_get_thread_limit () != 45
-  || omp_get_max_threads () != 46
-  || omp_get_proc_bind () != omp_proc_bind_spread
-  || omp_get_max_active_levels () != 47)
+  if ((!getenv ("OMP_NUM_TEAMS") && omp_get_max_teams () != 42)
+  || (!getenv ("OMP_DYNAMIC") && !omp_get_dynamic ())
+  || (!getenv ("OMP_SCHEDULE") && (kind != 3 || chunk_size != 4))
+  || (!getenv ("OMP_TEAMS_THREAD_LIMIT") && omp_get_teams_thread_limit () 
!= 44)
+  || (!getenv ("OMP_THREAD_LIMIT") && omp_get_thread_limit () != 45)
+  || (!getenv ("OMP_NUM_THREADS") && omp_get_max_threads () != 46)
+  || (!getenv ("OMP_PROC_BIND") && omp_get_proc_bind () != 
omp_proc_bind_spread)
+  || (!getenv ("OMP_MAX_ACTIVE_LEVELS") && omp_get_max_active_levels () != 
47))
 abort ();
 
   int num_devices = omp_get_num_devices () > 3 ? 3 : omp_get_num_devices ();
-  for (int i=0; i < num_devices; i++)
+  for (int i = 0; i < num_devices; i++)
+{
+  char name[sizeof ("OMP_NUM_TEAMS_DEV_1")];
+  strcpy (name, "OMP_NUM_TEAMS_DEV_1");
+  name[sizeof ("OMP_NUM_TEAMS_DEV_1") - 2] = '0' + i;
+  if (getenv (name))
+   continue;
 #pragma omp target device (i)
   if (omp_get_max_teams () != 43)
abort ();
+}
 
   return 0;
 }

Jakub

Re: [PATCH] Implement known/maybe fpclassify like API for frange.

[Jan-Benedict Glaw]

Hi Aldy!

On Thu, 2022-09-08 12:56:24 +0200, Aldy Hernandez via Gcc-patches 
 wrote:

> From 795baa0b044953e9f198f49e379374d633f43b47 Mon Sep 17 00:00:00 2001
> From: Aldy Hernandez 
> Date: Thu, 8 Sep 2022 08:11:43 +0200
> Subject: [PATCH] Implement known/maybe fpclassify like API for frange.
> 
> gcc/ChangeLog:
> 
>   * gimple-range-fold.cc
>   (fold_using_range::range_of_builtin_int_call): Use fpclassify like API.
>   * range-op-float.cc (finite_operand_p): Same.
>   (finite_operands_p): Same.
>   (foperator_lt::fold_range): Same.
>   (foperator_le::fold_range): Same.
>   (foperator_gt::fold_range): Same.
>   (foperator_ge::fold_range): Same.
>   (foperator_unordered::fold_range): Same.
>   (foperator_unordered::op1_range): Same.
>   (foperator_ordered::fold_range): Same.
>   * value-range.cc (frange::set_nan): Same.
>   (frange::set_signbit): Same.
>   (frange::union_): Same.
>   (frange::intersect): Same.
>   (frange::operator==): Same.
>   (frange::singleton_p): Same.
>   (frange::verify_range): Same.
>   (range_tests_nan): Same.
>   (range_tests_floats): Same.
>   * value-range.h(frange::known_finite): New.
>   (frange::maybe_inf): New.
>   (frange::known_inf): New.
>   (frange::maybe_nan): New.
>   (frange::known_nan): New.
>   (frange::known_signbit): New.
> ---
>  gcc/gimple-range-fold.cc |  19 +++---
>  gcc/range-op-float.cc|  26 
>  gcc/value-range.cc   | 126 +++
>  gcc/value-range.h|  78 +++-
>  4 files changed, 170 insertions(+), 79 deletions(-)

This triggers a selftest failure for pdp11:

.../gcc/configure --prefix=... --enable-werror-always --enable-languages=all 
--disable-gcov --disable-shared --disable-threads --target=pdp11-aout 
--without-headers
[...]
make V=1 all-gcc
[...]
/var/lib/laminar/run/gcc-pdp11-aout/13/toolchain-build/./gcc/xgcc 
-B/var/lib/laminar/run/gcc-pdp11-aout/13/toolchain-build/./gcc/  -xc -nostdinc 
/dev/null -S -o /dev/null -fself-test=../../gcc/gcc/testsuite/selftests
../../gcc/gcc/value-range.cc:3801: range_tests_signbit: FAIL: ASSERT_TRUE 
((r0.undefined_p ()))
In function 'test_fn':
cc1: internal compiler error: in fail, at selftest.cc:47
0x1757e97 selftest::fail(selftest::location const&, char const*)
  ../../gcc/gcc/selftest.cc:47
0x109ab62 range_tests_signbit
  ../../gcc/gcc/value-range.cc:3801
0x109ab62 range_tests_floats
  ../../gcc/gcc/value-range.cc:3810
0x10a9cf1 selftest::range_tests()
  ../../gcc/gcc/value-range.cc:3914
0x156e6d7 test_ranges
  ../../gcc/gcc/function-tests.cc:584
0x156e6d7 selftest::function_tests_cc_tests()
  ../../gcc/gcc/function-tests.cc:680
0x168d60b selftest::run_tests()
  ../../gcc/gcc/selftest-run-tests.cc:107
0xd968c9 toplev::run_self_tests()
  ../../gcc/gcc/toplev.cc:2184
Please submit a full bug report, with preprocessed source (by using 
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.
make[1]: *** [../../gcc/gcc/c/Make-lang.in:128: s-selftest-c] Error 1

Thanks,
  Jan-Benedict

-- 


signature.asc
Description: PGP signature

Re: [PATCH v2] gcov: Respect triplet when looking for gcov

[Martin Liška]

On 9/12/22 09:06, Torbjorn SVENSSON via Gcc-patches wrote:
> 
> 
> On 2022-09-11 21:38, Mikael Morin wrote:
>> Le 11/09/2022 à 18:04, Torbjorn SVENSSON a écrit :
>>> Can you fix it for me and submit it or do you want me to send a v3?
>>
>> For trivial things like this, there is no need for a v3 (nor was there for a 
>> v2).
>> Do you miss a git write account and need someone to push for you?
> 
> Ok!
> 
> I do not have any write access, so yes, please push it for me!

Please attach a patch with git format-patch and I'm going to push it now.

Cheers,
Martin

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

[Philipp Fent via Gcc-patches]

Hi Jonathan,

I've sent an updated patch addressing your comments here:
https://gcc.gnu.org/pipermail/libstdc++/2022-September/054587.html

Details below.

On 06.09.22 13:27, Jonathan Wakely wrote:

+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).


I factored this into a reusable access_streambuf_ptrs().


+# 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.


Good catch! I fixed that bug and added a test for this in the testsuite.




+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.


I didn't know one could redirect a stringstream, since its rdbuf() 
method hides the basic_ios rdbuf() methods. But of course, that's still 
possible via the base class...
The Patch v2 checks that case in the StdStringStreamPrinter constructor, 
and follows that redirect in to_string().





+
+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?


Indeed. The updated patch registers the pretty printer for all flavors.

[Ada] Special-case printing of SPARK_Mode in error messages

[Marc Poulhiès via Gcc-patches]

For error messages with inserted names that include acronyms like SPARK
or CPP, we want to preserve the casing. The list of special-cased named
is currently the same as in gnatpp.

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

gcc/ada/

* erroutc.adb (Set_Msg_Insertion_Name): Special-case printing with
acronyms.diff --git a/gcc/ada/erroutc.adb b/gcc/ada/erroutc.adb
--- a/gcc/ada/erroutc.adb
+++ b/gcc/ada/erroutc.adb
@@ -1317,8 +1317,8 @@ package body Erroutc is
 Name_Len := Name_Len - 1;
  end if;
 
- --  If operator name or character literal name, just print it as is
- --  Also print as is if it ends in a right paren (case of x'val(nnn))
+ --  If operator name or character literal name, just print it as is.
+ --  Also print as is if it ends in a right paren (case of x'val(nnn)).
 
  if Name_Buffer (1) = '"'
or else Name_Buffer (1) = '''
@@ -1534,6 +1534,32 @@ package body Erroutc is
   elsif Text = "_TYPE_INVARIANT" then
  Set_Msg_Str ("TYPE_INVARIANT'CLASS");
 
+  --  Preserve casing for names that include acronyms
+
+  elsif Text = "Cpp_Class" then
+ Set_Msg_Str ("CPP_Class");
+
+  elsif Text = "Cpp_Constructor" then
+ Set_Msg_Str ("CPP_Constructor");
+
+  elsif Text = "Cpp_Virtual" then
+ Set_Msg_Str ("CPP_Virtual");
+
+  elsif Text = "Cpp_Vtable" then
+ Set_Msg_Str ("CPP_Vtable");
+
+  elsif Text = "Persistent_Bss" then
+ Set_Msg_Str ("Persistent_BSS");
+
+  elsif Text = "Spark_Mode" then
+ Set_Msg_Str ("SPARK_Mode");
+
+  elsif Text = "Use_Vads_Size" then
+ Set_Msg_Str ("Use_VADS_Size");
+
+  elsif Text = "Vads_Size" then
+ Set_Msg_Str ("VADS_size");
+
   --  Normal case with no replacement
 
   else

[Ada] Accept explicit SPARK_Mode Auto as configuration pragma

[Marc Poulhiès via Gcc-patches]

An explicit value of Auto is now accepted for a configuration pragma
SPARK_Mode, as a way to exempt a unit from complete adherence to
SPARK rules when using a global configuration pragma file where
SPARK_Mode=>On is specified.

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

gcc/ada/

* sem_prag.adb (Analyze_Pragma): Accept SPARK_Mode=>Auto as
configuration pragma.
(Get_SPARK_Mode): Make the value for Auto explicit.
* snames.ads-tmpl (Name_Auto): Add name.diff --git a/gcc/ada/sem_prag.adb b/gcc/ada/sem_prag.adb
--- a/gcc/ada/sem_prag.adb
+++ b/gcc/ada/sem_prag.adb
@@ -23176,7 +23176,7 @@ package body Sem_Prag is
  -- SPARK_Mode --
  
 
- --  pragma SPARK_Mode [(On | Off)];
+ --  pragma SPARK_Mode [(Auto | On | Off)];
 
  when Pragma_SPARK_Mode => Do_SPARK_Mode : declare
 Mode_Id : SPARK_Mode_Type;
@@ -23662,7 +23662,7 @@ package body Sem_Prag is
 --  Check the legality of the mode (no argument = ON)
 
 if Arg_Count = 1 then
-   Check_Arg_Is_One_Of (Arg1, Name_On, Name_Off);
+   Check_Arg_Is_One_Of (Arg1, Name_Auto, Name_On, Name_Off);
Mode := Chars (Get_Pragma_Arg (Arg1));
 else
Mode := Name_On;
@@ -23713,6 +23713,15 @@ package body Sem_Prag is
 --  the pragma resides to find a potential construct.
 
 else
+   --  An explicit mode of Auto is only allowed as a configuration
+   --  pragma. Escape "pragma" to avoid replacement with "aspect".
+
+   if Mode_Id = None then
+  Error_Pragma_Arg
+("only configuration 'p'r'a'g'm'a% can have value &",
+ Arg1);
+   end if;
+
Stmt := Prev (N);
while Present (Stmt) loop
 
@@ -31169,7 +31178,9 @@ package body Sem_Prag is
 
function Get_SPARK_Mode_Type (N : Name_Id) return SPARK_Mode_Type is
begin
-  if N = Name_On then
+  if N = Name_Auto then
+ return None;
+  elsif N = Name_On then
  return On;
   elsif N = Name_Off then
  return Off;


diff --git a/gcc/ada/snames.ads-tmpl b/gcc/ada/snames.ads-tmpl
--- a/gcc/ada/snames.ads-tmpl
+++ b/gcc/ada/snames.ads-tmpl
@@ -782,6 +782,7 @@ package Snames is
Name_Assertion  : constant Name_Id := N + $;
Name_Assertions : constant Name_Id := N + $;
Name_Attribute_Name : constant Name_Id := N + $;
+   Name_Auto   : constant Name_Id := N + $;
Name_Body_File_Name : constant Name_Id := N + $;
Name_Boolean_Entry_Barriers : constant Name_Id := N + $;
Name_By_Any : constant Name_Id := N + $;

[Ada] Reject 'Valid_Scalars on Unchecked_Union regardless of privacy

[Marc Poulhiès via Gcc-patches]

Attribute Valid_Scalars applied to prefix with an unchecked union
component causes a legitimate crash in the backend. It was already
rejected in the frontend for prefixes of a public type; now it is
rejected in the frontend regardless of the type privacy.

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

gcc/ada/

* sem_attr.adb (Analyze_Attribute [Valid_Scalars]): Move check for
unchecked union before checks for private and public types.diff --git a/gcc/ada/sem_attr.adb b/gcc/ada/sem_attr.adb
--- a/gcc/ada/sem_attr.adb
+++ b/gcc/ada/sem_attr.adb
@@ -7399,10 +7399,19 @@ package body Sem_Attr is
  if Comes_From_Source (N) then
 Check_Object_Reference (P);
 
+--  Attribute 'Valid_Scalars is illegal on unchecked union types
+--  regardles of the privacy, because it is not always guaranteed
+--  that the components are retrievable based on whether the
+--  discriminants are inferable.
+
+if Has_Unchecked_Union (Validated_View (P_Type)) then
+   Error_Attr_P
+ ("attribute % not allowed for Unchecked_Union type");
+
 --  Do not emit any diagnostics related to private types to avoid
 --  disclosing the structure of the type.
 
-if Is_Private_Type (P_Type) then
+elsif Is_Private_Type (P_Type) then
 
--  Attribute 'Valid_Scalars is not supported on private tagged
--  types due to a code generation issue. Is_Visible_Component
@@ -7432,15 +7441,6 @@ package body Sem_Attr is
 ("??attribute % always True, no scalars to check", P);
   Set_Boolean_Result (N, True);
end if;
-
-   --  Attribute 'Valid_Scalars is illegal on unchecked union types
-   --  because it is not always guaranteed that the components are
-   --  retrievable based on whether the discriminants are inferable
-
-   if Has_Unchecked_Union (P_Type) then
-  Error_Attr_P
-("attribute % not allowed for Unchecked_Union type");
-   end if;
 end if;
  end if;
 

[Ada] Fix immediate assertion failure with -gnatd.1

[Marc Poulhiès via Gcc-patches]

The switch enables the front-end unnesting pass.

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

gcc/ada/

* gcc-interface/decl.cc (gnat_to_gnu_entity): Relax assertion when
front-end unnesting is enabled.diff --git a/gcc/ada/gcc-interface/decl.cc b/gcc/ada/gcc-interface/decl.cc
--- a/gcc/ada/gcc-interface/decl.cc
+++ b/gcc/ada/gcc-interface/decl.cc
@@ -436,7 +436,8 @@ gnat_to_gnu_entity (Entity_Id gnat_entity, tree gnu_expr, bool definition)
   /* If this is a numeric or enumeral type, or an access type, a nonzero Esize
  must be specified unless it was specified by the programmer.  Exceptions
  are for access-to-protected-subprogram types and all access subtypes, as
- another GNAT type is used to lay out the GCC type for them.  */
+ another GNAT type is used to lay out the GCC type for them, as well as
+ access-to-subprogram types if front-end unnesting is enabled.  */
   gcc_assert (!is_type
 	  || Known_Esize (gnat_entity)
 	  || Has_Size_Clause (gnat_entity)
@@ -445,6 +446,9 @@ gnat_to_gnu_entity (Entity_Id gnat_entity, tree gnu_expr, bool definition)
 		  && (!IN (kind, Access_Kind)
 		  || kind == E_Access_Protected_Subprogram_Type
 		  || kind == E_Anonymous_Access_Protected_Subprogram_Type
+		  || ((kind == E_Access_Subprogram_Type
+			   || kind == E_Anonymous_Access_Subprogram_Type)
+			  && Unnest_Subprogram_Mode)
 		  || kind == E_Access_Subtype
 		  || type_annotate_only)));
 

[Ada] Storage_Error raised analyzing type with call in its range constraint

[Marc Poulhiès via Gcc-patches]

This patch corrects a problem in the compiler whereby the determination of
scope levels during the generation of accessibility checks for function calls
within range constraints leads to a compiler crash due to the type not being
fully analyzed at the point in which its scope depth must be obtained.

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

gcc/ada/

* sem_util.adb
(Innermost_Master_Scope_Depth): Detect and handle case where scope
depth is not set on an enclosing scope.diff --git a/gcc/ada/sem_util.adb b/gcc/ada/sem_util.adb
--- a/gcc/ada/sem_util.adb
+++ b/gcc/ada/sem_util.adb
@@ -316,8 +316,20 @@ package body Sem_Util is
--  Ignore transient scopes made during expansion
 
if Comes_From_Source (Node_Par) then
-  return
-Scope_Depth (Encl_Scop) + Master_Lvl_Modifier;
+  --  Note that in some rare cases the scope depth may not be
+  --  set, for example, when we are in the middle of analyzing
+  --  a type and the enclosing scope is said type. So, instead,
+  --  continue to move up the parent chain since the scope
+  --  depth of the type's parent is the same as that of the
+  --  type.
+
+  if not Scope_Depth_Set (Encl_Scop) then
+ pragma Assert (Nkind (Parent (Encl_Scop))
+ = N_Full_Type_Declaration);
+  else
+ return
+   Scope_Depth (Encl_Scop) + Master_Lvl_Modifier;
+  end if;
end if;
 
 --  For a return statement within a function, return

[Ada] Improve CUDA host-side and device-side binder support

[Marc Poulhiès via Gcc-patches]

Use switches (one already existing, one newly added here) to indicate to
the binder that CUDA support code is to be generated for either the
host side or for the device side. Add an invocation of Adainit on the
device side from Adainit on the host side; similarly for Adafinal.

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

gcc/ada/

* bindgen.adb: When the binder is invoked for the host, it
declares imported subprograms corresponding to the Adainit and
Adafinal routines on the device. Declare string constants and
expression functions for the Ada source names and the link names
of these routines. Generate these subprogram declarations (and
accompanying Import pragmas) in Gen_CUDA_Defs. Generate
CUDA_Execute pragmas to call these subprograms from the host in
Gen_Adafinal and Gen_CUDA_Init. When the binder is invoked for the
device, include a CUDA_Global aspect declaration in the
declarations of Adainit and Adafinal and use the aforementioned
link names in the Export pragmas generated for those two routines.
* debug.adb: Update comments about "d_c" and "d_d" switches.
* opt.ads: Declare new Boolean variable,
Enable_CUDA_Device_Expansion. This complements the existing
Enable_CUDA_Expansion variable, which is used to enable host-side
CUDA expansion. The new variable enables device-side CUDA
expansion. It is currently never set during compilation; it is
only set via a binder switch.
* switch-b.adb
(scan_debug_switches): Add new use of the "-d_d" binder switch.
The new switch and the variable Opt.Enabled_CUDA_Device_Expansion
follow the existing pattern of the "-d_c" switch and the variable
Opt.Enabled_CUDA_Expansion. Flag error if both "-d_c" and "-d_d"
are specified.diff --git a/gcc/ada/bindgen.adb b/gcc/ada/bindgen.adb
--- a/gcc/ada/bindgen.adb
+++ b/gcc/ada/bindgen.adb
@@ -114,6 +114,29 @@ package body Bindgen is
--  For CodePeer, introduce a wrapper subprogram which calls the
--  user-defined main subprogram.
 
+   --  Names and link_names for CUDA device adainit/adafinal procs.
+
+   Device_Subp_Name_Prefix : constant String := "imported_device_";
+   Device_Link_Name_Prefix : constant String := "__device_";
+
+   function Device_Ada_Final_Link_Name return String is
+ (Device_Link_Name_Prefix & Ada_Final_Name.all);
+
+   function Device_Ada_Final_Subp_Name return String is
+ (Device_Subp_Name_Prefix & Ada_Final_Name.all);
+
+   function Device_Ada_Init_Link_Name return String is
+ (Device_Link_Name_Prefix & Ada_Init_Name.all);
+
+   function Device_Ada_Init_Subp_Name return String is
+ (Device_Subp_Name_Prefix & Ada_Init_Name.all);
+
+   --  Text for aspect specifications (if any) given as part of the
+   --  Adainit and Adafinal spec declarations.
+
+   function Aspect_Text return String is
+ (if Enable_CUDA_Device_Expansion then " with CUDA_Global" else "");
+
--
-- Interface_State Pragma Table --
--
@@ -501,6 +524,12 @@ package body Bindgen is
  WBI ("  System.Standard_Library.Adafinal;");
   end if;
 
+  --  perform device (as opposed to host) finalization
+  if Enable_CUDA_Expansion then
+ WBI ("  pragma CUDA_Execute (" &
+Device_Ada_Final_Subp_Name & ", 1, 1);");
+  end if;
+
   WBI ("   end " & Ada_Final_Name.all & ";");
   WBI ("");
end Gen_Adafinal;
@@ -512,7 +541,6 @@ package body Bindgen is
procedure Gen_Adainit (Elab_Order : Unit_Id_Array) is
   Main_Priority : Int renames ALIs.Table (ALIs.First).Main_Priority;
   Main_CPU  : Int renames ALIs.Table (ALIs.First).Main_CPU;
-
begin
   --  Declare the access-to-subprogram type used for initialization of
   --  of __gnat_finalize_library_objects. This is declared at library
@@ -1334,6 +1362,13 @@ package body Bindgen is
  end;
   end loop;
 
+  WBI ("   procedure " & Device_Ada_Init_Subp_Name & ";");
+  WBI ("   pragma Import (C, " & Device_Ada_Init_Subp_Name &
+ ", Link_Name => """ & Device_Ada_Init_Link_Name & """);");
+  WBI ("   procedure " & Device_Ada_Final_Subp_Name & ";");
+  WBI ("   pragma Import (C, " & Device_Ada_Final_Subp_Name &
+ ", Link_Name => """ & Device_Ada_Final_Link_Name & """);");
+
   WBI ("");
end Gen_CUDA_Defs;
 
@@ -1393,6 +1428,10 @@ package body Bindgen is
   end loop;
 
   WBI ("  CUDA_Register_Fat_Binary_End (Fat_Binary_Handle);");
+
+  --  perform device (as opposed to host) elaboration
+  WBI ("  pragma CUDA_Execute (" &
+ Device_Ada_Init_Subp_Name & ", 1, 1);");
end Gen_CUDA_Init;
 
--
@@ -2602,9 +2641,14 @@ package body Bindgen is
   end if;
 
   WBI ("");
-  WBI ("   procedure " & 

[Ada] Temporary tweak new expansion of contracts

[Marc Poulhiès via Gcc-patches]

In the case of a function, the new expansion of contracts makes use of an
extended return statement to store the result of the function in the return
object while the post-conditions are evaluated.

Unfortunately GNAT does not elide the copy of the return object for extended
return statements for the time being, so this scheme incurs an extra copy of
the return value on the primary or secondary stack, as well as an additional
pair of calls to Adjust/Finalize when the return type needs finalization.

This temporarily changes the expansion to use a block statement containing a
renaming, which does not incur the extra copy provided that it is manually
adjusted to be recognized by the existing "tail call" optimization present
in the Expand_Simple_Function_Return routine.

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

gcc/ada/

* contracts.adb (uild_Subprogram_Contract_Wrapper): Remove useless
local variable. In the case of a function, replace the extended
return statement by a block statement declaring a renaming of the
call to the local subprogram after removing side effects manually.
(Expand_Subprogram_Contract): Adjust description accordingly.
* exp_ch6.adb (Expand_Ctrl_Function_Call): Rewrite obsolete
comment and do not apply the transformation twice.
* sem_attr.adb (Analyze_Attribute_Old_Result): Now expect a block
statement instead of an extended return statement.diff --git a/gcc/ada/contracts.adb b/gcc/ada/contracts.adb
--- a/gcc/ada/contracts.adb
+++ b/gcc/ada/contracts.adb
@@ -1577,7 +1577,6 @@ package body Contracts is
   Decls   : List_Id;
   Result  : Entity_Id)
is
-  Actuals   : constant List_Id:= Empty_List;
   Body_Decl : constant Entity_Id  := Unit_Declaration_Node (Body_Id);
   Loc   : constant Source_Ptr := Sloc (Body_Decl);
   Spec_Id   : constant Entity_Id  := Corresponding_Spec (Body_Decl);
@@ -1606,11 +1605,11 @@ package body Contracts is
   Ret_Type := Etype (Subp_Id);
 
   --  Generate the contracts wrapper by moving the original declarations
-  --  and statements within a local subprogram and calling it within
-  --  an extended return to preserve the result for the purpose of
-  --  evaluating postconditions, contracts, type invariants, etc.
+  --  and statements within a local subprogram, calling it and possibly
+  --  preserving the result for the purpose of evaluating postconditions,
+  --  contracts, type invariants, etc.
 
-  --  Generate:
+  --  In the case of a function, generate:
   --
   --  function Original_Func (X : in out Integer) return Typ is
   -- 
@@ -1623,13 +1622,25 @@ package body Contracts is
   -- end;
   --
   --  begin
-  -- return
-  --Result_Obj : constant Typ := _Wrapped_Statements
-  -- do
+  -- declare
+  --type Axx is access all Typ;
+  --Rxx : constant Axx := _Wrapped_Statements'reference;
+  --Result_Obj : Typ renames Rxx.all;
+  --
+  -- begin
   --
-  -- end return;
+  --return Rxx.all;
+  -- end;
   --  end;
   --
+  --  This sequence is recognized by Expand_Simple_Function_Return as a
+  --  tail call, in other words equivalent to "return _Wrapped_Statements;"
+  --  and thus the copy to the anonymous return object is elided, including
+  --  a pair of calls to Adjust/Finalize for types requiring finalization.
+
+  --  Note that an extended return statement does not yield the same result
+  --  because the copy of the return object is not elided by GNAT for now.
+
   --  Or, in the case of a procedure:
   --
   --  procedure Original_Proc (X : in out Integer) is
@@ -1680,8 +1691,7 @@ package body Contracts is
   Set_Declarations (Body_Decl, Decls);
   Set_Handled_Statement_Sequence (Body_Decl,
 Make_Handled_Sequence_Of_Statements (Loc,
-  End_Label  => Make_Identifier (Loc, Chars (Wrapper_Id)),
-  Statements => New_List));
+  End_Label  => Make_Identifier (Loc, Chars (Wrapper_Id;
 
   --  Move certain flags which are relevant to the body
 
@@ -1697,7 +1707,7 @@ package body Contracts is
   Set_Has_Pragma_Inline_Always
 (Wrapper_Id, Has_Pragma_Inline_Always (Subp_Id));
 
-  --  Generate call to the wrapper
+  --  Prepend a call to the wrapper when the subprogram is a procedure
 
   if No (Ret_Type) or else Ret_Type = Standard_Void_Type then
  Prepend_To (Stmts,
@@ -1706,25 +1716,64 @@ package body Contracts is
  Set_Statements
(Handled_Statement_Sequence (Body_Decl), Stmts);
 
-  --  Generate the post-execution statements and the extended return
-  --  when the subprogram being wrapped is a function.
+  --  Declare a renaming of the result of the call to the wrapper and
+  --  append a 

[Ada] Fix validity checking on renamed Old attribute prefix

[Marc Poulhiès via Gcc-patches]

Prefix of attribute Old is captured either as an object renaming or as
an object declaration. This is now taken into account when applying
validity checks.

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

gcc/ada/

* exp_attr.adb (Expand_N_Attribute_Reference [Attribute_Old]):
Adapt to object declaration being rewritten into object renaming.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
@@ -5088,7 +5088,17 @@ package body Exp_Attr is
  --  to reflect the new placement of the prefix.
 
  if Validity_Checks_On and then Validity_Check_Operands then
-Ensure_Valid (Expression (Decl));
+
+--  Object declaration that captures the attribute prefix might
+--  be rewritten into object renaming declaration.
+
+if Nkind (Decl) = N_Object_Declaration then
+   Ensure_Valid (Expression (Decl));
+else
+   pragma Assert (Nkind (Decl) = N_Object_Renaming_Declaration
+  and then Is_Rewrite_Substitution (Decl));
+   Ensure_Valid (Name (Decl));
+end if;
  end if;
 
  Rewrite (N, New_Occurrence_Of (Temp, Loc));

[Ada] Improve CUDA host-side and device-side binder support

[Marc Poulhiès via Gcc-patches]

On the host-side, the binder now generates CUDA_Execute pragmas to
invoke initialization and finalization on the device-side. The
front end's expansion of these pragmas includes references to
entities declared in package CUDA.Internal. Generate a with-clause so
that unit will be available.

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

gcc/ada/

* bindgen.adb: When the binder is invoked for the host, generate a
"with CUDA.Internal;" with clause.diff --git a/gcc/ada/bindgen.adb b/gcc/ada/bindgen.adb
--- a/gcc/ada/bindgen.adb
+++ b/gcc/ada/bindgen.adb
@@ -2552,6 +2552,9 @@ package body Bindgen is
   if Enable_CUDA_Expansion then
  WBI ("with Interfaces.C;");
  WBI ("with Interfaces.C.Strings;");
+
+ --  with of CUDA.Internal needed for CUDA_Execute pragma expansion
+ WBI ("with CUDA.Internal;");
   end if;
 
   Resolve_Binder_Options (Elab_Order);

[Ada] Cleanup routine for handling SPARK_Mode kinds

[Marc Poulhiès via Gcc-patches]

Code cleanup; semantics is unaffected.

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

gcc/ada/

* sem_prag.adb (Get_SPARK_Mode_Type): Fix header box; replace
chained IF with a CASE statement.diff --git a/gcc/ada/sem_prag.adb b/gcc/ada/sem_prag.adb
--- a/gcc/ada/sem_prag.adb
+++ b/gcc/ada/sem_prag.adb
@@ -31172,25 +31172,26 @@ package body Sem_Prag is
   end if;
end Get_Base_Subprogram;
 
-   ---
+   -
-- Get_SPARK_Mode_Type --
-   ---
+   -
 
function Get_SPARK_Mode_Type (N : Name_Id) return SPARK_Mode_Type is
begin
-  if N = Name_Auto then
- return None;
-  elsif N = Name_On then
- return On;
-  elsif N = Name_Off then
- return Off;
+  case N is
+ when Name_Auto =>
+return None;
+ when Name_On =>
+return On;
+ when Name_Off =>
+return Off;
 
-  --  Any other argument is illegal. Assume that no SPARK mode applies to
-  --  avoid potential cascaded errors.
+ --  Any other argument is illegal. Assume that no SPARK mode applies
+ --  to avoid potential cascaded errors.
 
-  else
- return None;
-  end if;
+ when others =>
+return None;
+  end case;
end Get_SPARK_Mode_Type;
 

[Ada] Remove SPARK containers from GNAT documentation

[Marc Poulhiès via Gcc-patches]

This patch removes documentation on the SPARK containers,
now under the spark2014 repository.

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

gcc/ada/

* doc/gnat_rm/the_gnat_library.rst: Remove paragraphs about SPARK
containers.
* gnat_rm.texi, gnat_ugn.texi: Regenerate.

patch.diff.gz
Description: application/gzip

[Ada] Fix oversight in implementation of unnesting

[Marc Poulhiès via Gcc-patches]

The pass would traverse generic subprogram bodies, which are not expanded,
thus stumbling on unexpected nodes.

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

gcc/ada/

* exp_unst.adb (Unnest_Subprograms.Search_Subprograms): Skip the
subprogram bodies that are not to be unnested.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
@@ -2592,6 +2592,8 @@ package body Exp_Unst is
  and then Is_Library_Level_Entity (Spec_Id)
then
   Unnest_Subprogram (Spec_Id, N);
+   else
+  return Skip;
end if;
 end;
 

[Ada] Sync documentation of junk names with code

[Marc Poulhiès via Gcc-patches]

The list of junk entity names for which warnings are suppressed has been
recently modified, so update the documentation accordingly.

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

gcc/ada/

* doc/gnat_rm/implementation_defined_pragmas.rst
(Pragma Unreferenced): Sync description with
Sem_Warn.Has_Junk_Name routine.
* gnat_rm.texi: Regenerate.
* gnat_ugn.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
@@ -7125,7 +7125,7 @@ be.
 
 For the variable case, warnings are never given for unreferenced variables
 whose name contains one of the substrings
-``DISCARD, DUMMY, IGNORE, JUNK, UNUSED`` in any casing. Such names
+``DISCARD, DUMMY, IGNORE, JUNK, UNUSE, TMP, TEMP`` in any casing. Such names
 are typically to be used in cases where such warnings are expected.
 Thus it is never necessary to use ``pragma Unmodified`` for such
 variables, though it is harmless to do so.


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
@@ -8657,7 +8657,7 @@ be.
 
 For the variable case, warnings are never given for unreferenced variables
 whose name contains one of the substrings
-@code{DISCARD, DUMMY, IGNORE, JUNK, UNUSED} in any casing. Such names
+@code{DISCARD, DUMMY, IGNORE, JUNK, UNUSE, TMP, TEMP} in any casing. Such names
 are typically to be used in cases where such warnings are expected.
 Thus it is never necessary to use @code{pragma Unmodified} for such
 variables, though it is harmless to do so.


diff --git a/gcc/ada/gnat_ugn.texi b/gcc/ada/gnat_ugn.texi
--- a/gcc/ada/gnat_ugn.texi
+++ b/gcc/ada/gnat_ugn.texi
@@ -29317,8 +29317,8 @@ to permit their use in free software.
 
 @printindex ge
 
-@anchor{cf}@w{  }
 @anchor{gnat_ugn/gnat_utility_programs switches-related-to-project-files}@w{  }
+@anchor{cf}@w{  }
 
 @c %**end of body
 @bye

[Ada] Reject use in SPARK of Asm intrinsics for code insertions

[Marc Poulhiès via Gcc-patches]

SPARK does not allow code insertions. This applies also to
calls to Asm intrinsics defined in System.Machine_Code.

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

gcc/ada/

* libgnat/s-maccod.ads: Mark package as SPARK_Mode Off.diff --git a/gcc/ada/libgnat/s-maccod.ads b/gcc/ada/libgnat/s-maccod.ads
--- a/gcc/ada/libgnat/s-maccod.ads
+++ b/gcc/ada/libgnat/s-maccod.ads
@@ -33,7 +33,9 @@
 --  operations, and also for machine code statements. See GNAT documentation
 --  for full details.
 
-package System.Machine_Code is
+package System.Machine_Code
+  with SPARK_Mode => Off
+is
pragma No_Elaboration_Code_All;
pragma Pure;
 

[Ada] Internal error compiling formal instance of generic with Initial_Condition

[Marc Poulhiès via Gcc-patches]

Prevent the compiler from failing with an internal error in some cases involving
an instance of a generic which takes as a formal parameter an instance of a
second generic, where the second generic has an Initial_Condition aspect
specification.

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

gcc/ada/

* contracts.adb
(Analyze_Package_Contract): Do not analyze the contract of a
temporary package created just to check conformance of an actual
package.diff --git a/gcc/ada/contracts.adb b/gcc/ada/contracts.adb
--- a/gcc/ada/contracts.adb
+++ b/gcc/ada/contracts.adb
@@ -1319,6 +1319,18 @@ package body Contracts is
   if Present (Items) then
  if Analyzed (Items) then
 return;
+
+ --  Do not analyze the contract of the internal package
+ --  created to check conformance of an actual package.
+ --  Such an internal package is removed from the tree after
+ --  legality checks are completed, and it does not contain
+ --  the declarations of all local entities of the generic.
+
+ elsif Is_Internal (Pack_Id)
+   and then Is_Generic_Instance (Pack_Id)
+ then
+return;
+
  else
 Set_Analyzed (Items);
  end if;

[Ada] bugbox referencing INOX prefixed view of primitive op of modular type

[Marc Poulhiès via Gcc-patches]

The -gnatX switch enables naming a prefixed view of a subprogram with an
untagged prefix. Compiling such a reference where the prefix is of a modular
type could result in an internal compiler error.

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

gcc/ada/

* sem_ch4.adb
(Analyze_Selected_Component): Avoid initializing the local
variable Comp if the variable is not going to be subsequently
referenced. This is a correctness issue because the call to
First_Entity can fail.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
@@ -5187,7 +5187,16 @@ package body Sem_Ch4 is
   and then not Is_Derived_Type (Prefix_Type)
   and then Is_Entity_Name (Name);
 
-  Comp := First_Entity (Type_To_Use);
+  --  Avoid initializing Comp if that initialization is not needed
+  --  (and, more importantly, if the call to First_Entity could fail).
+
+  if Has_Discriminants (Type_To_Use)
+or else Is_Record_Type (Type_To_Use)
+or else Is_Private_Type (Type_To_Use)
+or else Is_Concurrent_Type (Type_To_Use)
+  then
+ Comp := First_Entity (Type_To_Use);
+  end if;
 
   --  If the selector has an original discriminant, the node appears in
   --  an instance. Replace the discriminant with the corresponding one

[Ada] Justify false alarm from CodePeer analysis of GNAT

[Marc Poulhiès via Gcc-patches]

Branch is determined as dead following a test always False by
CodePeer analysis, which is incorrect. Justify this false alarm
with an appropriate pragma Annotate.

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

gcc/ada/

* libgnat/s-imagei.adb (Image_Integer): Add justification.diff --git a/gcc/ada/libgnat/s-imagei.adb b/gcc/ada/libgnat/s-imagei.adb
--- a/gcc/ada/libgnat/s-imagei.adb
+++ b/gcc/ada/libgnat/s-imagei.adb
@@ -177,6 +177,8 @@ package body System.Image_I is
 
begin
   if V >= 0 then
+ pragma Annotate (CodePeer, False_Positive, "test always false",
+  "V can be positive");
  S (1) := ' ';
  P := 1;
  pragma Assert (P < S'Last);

[Ada] Do not mark user parameters of protected subprograms as artificial

[Marc Poulhiès via Gcc-patches]

This occurs because protected subprograms are not translated directly into
object code but first rewritten as a pair of subprograms by the front-end.

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

gcc/ada/

* exp_ch9.adb (Build_Protected_Spec): Tidy up and propagate the
Comes_From_Source flag onto the new formal parameters.
* sem_ch6.adb (Analyze_Subprogram_Body_Helper): Do not check
references for subprograms generated for protected subprograms.diff --git a/gcc/ada/exp_ch9.adb b/gcc/ada/exp_ch9.adb
--- a/gcc/ada/exp_ch9.adb
+++ b/gcc/ada/exp_ch9.adb
@@ -3868,32 +3868,35 @@ package body Exp_Ch9 is
   Ident   : Entity_Id;
   Unprotected : Boolean := False) return List_Id
is
-  Loc   : constant Source_Ptr := Sloc (N);
-  Decl  : Node_Id;
-  Formal: Entity_Id;
-  New_Plist : List_Id;
-  New_Param : Node_Id;
+  Loc : constant Source_Ptr := Sloc (N);
+
+  Decl   : Node_Id;
+  Formal : Entity_Id;
+  New_Formal : Entity_Id;
+  New_Plist  : List_Id;
 
begin
   New_Plist := New_List;
 
   Formal := First_Formal (Ident);
   while Present (Formal) loop
- New_Param :=
+ New_Formal :=
+   Make_Defining_Identifier (Sloc (Formal), Chars (Formal));
+ Set_Comes_From_Source (New_Formal, Comes_From_Source (Formal));
+
+ if Unprotected then
+Mutate_Ekind (New_Formal, Ekind (Formal));
+Set_Protected_Formal (Formal, New_Formal);
+ end if;
+
+ Append_To (New_Plist,
Make_Parameter_Specification (Loc,
- Defining_Identifier =>
-   Make_Defining_Identifier (Sloc (Formal), Chars (Formal)),
+ Defining_Identifier => New_Formal,
  Aliased_Present => Aliased_Present (Parent (Formal)),
  In_Present  => In_Present  (Parent (Formal)),
  Out_Present => Out_Present (Parent (Formal)),
- Parameter_Type  => New_Occurrence_Of (Etype (Formal), Loc));
-
- if Unprotected then
-Set_Protected_Formal (Formal, Defining_Identifier (New_Param));
-Mutate_Ekind (Defining_Identifier (New_Param), Ekind (Formal));
- end if;
+ Parameter_Type  => New_Occurrence_Of (Etype (Formal), Loc)));
 
- Append (New_Param, New_Plist);
  Next_Formal (Formal);
   end loop;
 


diff --git a/gcc/ada/sem_ch6.adb b/gcc/ada/sem_ch6.adb
--- a/gcc/ada/sem_ch6.adb
+++ b/gcc/ada/sem_ch6.adb
@@ -5511,12 +5511,22 @@ package body Sem_Ch6 is
 
  --  Check references of the subprogram spec when we are dealing with
  --  an expression function due to it having a generated body.
- --  Otherwise, we simply check the formals of the subprogram body.
 
  if Present (Spec_Id)
and then Is_Expression_Function (Spec_Id)
  then
 Check_References (Spec_Id);
+
+ --  Skip the check for subprograms generated for protected subprograms
+ --  because it is also done for the protected subprograms themselves.
+
+ elsif Present (Spec_Id)
+   and then Present (Protected_Subprogram (Spec_Id))
+ then
+null;
+
+ --  Otherwise, we simply check the formals of the subprogram body.
+
  else
 Check_References (Body_Id);
  end if;

[Ada] Syntax error in Ada 2022 array aggregate causes bug box

[Marc Poulhiès via Gcc-patches]

Check for the case where a user writes "in" instead of "of" in an
aggregate like "[for E in Some_Array when Some_Filter (E) => E]".

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

gcc/ada/

* sem_aggr.adb
(Resolve_Array_Aggregate): Generate an appropriate error message
in the case where an error in the source code leads to an
N_Iterated_Element_Association node in a bad context.diff --git a/gcc/ada/sem_aggr.adb b/gcc/ada/sem_aggr.adb
--- a/gcc/ada/sem_aggr.adb
+++ b/gcc/ada/sem_aggr.adb
@@ -1987,6 +1987,11 @@ package body Sem_Aggr is
  while Present (Assoc) loop
 if Nkind (Assoc) = N_Iterated_Component_Association then
Resolve_Iterated_Component_Association (Assoc, Index_Typ);
+
+elsif Nkind (Assoc) /= N_Component_Association then
+   Error_Msg_N
+ ("invalid component association for aggregate", Assoc);
+   return Failure;
 end if;
 
 Choice := First (Choice_List (Assoc));

[Ada] Lock_Free aspect takes precedence over Ceiling_Locking locking policy

[Marc Poulhiès via Gcc-patches]

Allow the Lock_Free aspect of a protected type to be True (but only by
explicit specification) if Ceiling_Locking locking policy has been specified.
Clarify that the Lock_Free aspect takes precedence over the Ceiling_Locking
policy in that case.

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

gcc/ada/

* sem_ch9.adb
(Satisfies_Lock_Free_Requirements): If Ceiling_Locking locking
policy has been specified, then either return False (if Lock_Free
was not explicitly specified) or generate a warning that ceiling
locking will not be implemented for this protected unit (if
Lock_Free was explicitly specified). Generate an error message (in
addition to returning False) if an explicit Lock_Free aspect
specification is rejected because atomic primitives are not
supported on the given target.
* doc/gnat_rm/implementation_defined_pragmas.rst: Clarify that the
Lock_Free aspect for a protected unit takes precedence over the
Ceiling_Locking locking policy in the case where both apply.
* 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
@@ -3752,7 +3752,12 @@ In addition, each protected subprogram body must satisfy:
 * May not dereferenced access values
 * Function calls and attribute references must be static
 
-
+If the Lock_Free aspect is specified to be True for a protected unit
+and the Ceiling_Locking locking policy is in effect, then the run-time
+actions associated with the Ceiling_Locking locking policy (described in
+Ada RM D.3) are not performed when a protected operation of the protected
+unit is executed.
+  
 Pragma Loop_Invariant
 =
 


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
@@ -19,7 +19,7 @@
 
 @copying
 @quotation
-GNAT Reference Manual , Aug 25, 2022
+GNAT Reference Manual , Sep 09, 2022
 
 AdaCore
 
@@ -5273,6 +5273,12 @@ May not dereferenced access values
 Function calls and attribute references must be static
 @end itemize
 
+If the Lock_Free aspect is specified to be True for a protected unit
+and the Ceiling_Locking locking policy is in effect, then the run-time
+actions associated with the Ceiling_Locking locking policy (described in
+Ada RM D.3) are not performed when a protected operation of the protected
+unit is executed.
+
 @node Pragma Loop_Invariant,Pragma Loop_Optimize,Pragma Lock_Free,Implementation Defined Pragmas
 @anchor{gnat_rm/implementation_defined_pragmas pragma-loop-invariant}@anchor{95}
 @section Pragma Loop_Invariant


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
@@ -651,9 +651,34 @@ package body Sem_Ch9 is
 
 begin
if not Support_Atomic_Primitives_On_Target then
+  if Lock_Free_Given then
+ Error_Msg_N
+   ("Lock_Free aspect requires target support for "
+  & "atomic primitives", N);
+  end if;
   return False;
end if;
 
+   --  Deal with case where Ceiling_Locking locking policy is
+   --  in effect.
+
+   if Locking_Policy = 'C' then
+  if Lock_Free_Given then
+ --  Explicit Lock_Free aspect spec overrides
+ --  Ceiling_Locking so we generate a warning.
+
+ Error_Msg_N
+   ("Lock_Free aspect specification overrides "
+  & "Ceiling_Locking locking policy??", N);
+  else
+ --  If Ceiling_Locking locking policy is in effect, then
+ --  Lock_Free can be explicitly specified but it is
+ --  never the default.
+
+ return False;
+  end if;
+   end if;
+
--  Get the number of errors detected by the compiler so far
 
if Lock_Free_Given then

[Ada] Tech debt: Expansion of contracts

[Marc Poulhiès via Gcc-patches]

This patch modifies the expansion of contracts such that the statements
and declarations of a subprogram with post-execution checks get moved to
a local internally generated subprogram which the original subprogram
calls directly followed by the required post-execution checks.

This differs from the current implementation which requires delicate
machinary which coordinates with the finalization process to emulate the
desired behavior within the "at end" procedure.

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

gcc/ada/

* contracts.adb, contracts.ads
(Analyze_Pragmas_In_Declarations): Added to aid in the new
expansion model so that pragmas relating to contracts can get
processed early before the rest of the subprogram containing them.
(Build_Subprogram_Contract_Wrapper): Created to do the majority of
expansion for postconditions. It builds a local wrapper with the
statements and declarations within a given subprogram.
(Is_Prologue_Renaming): Moved out from Process_Preconditions to be
used generally within the contracts package.
(Build_Entry_Contract_Wrapper): Moved from exp_ch7.
(Expand_Subprogram_Contract): Add new local variable Decls to
store expanded declarations needed for evaluation of contracts.
Call new wrapper building procedure and modify comments to match
new expansion model.
(Get_Postcond_Enabled): Deleted.
(Get_Result_Object_For_Postcond): Deleted.
(Get_Return_Success_For_Postcond): Deleted.
(Process_Contract_Cases): Add new parameter to store declarations.
(Process_Postconditions): Add new parameter to store declarations.
(Process_Preconditions): Add new parameter to store declarations.
Add code to move entry-call prologue renamings
* einfo.ads: Document new field Wrapped_Statements and modify
comment for Postconditions_Proc.
* exp_attr.adb
(Analyze_Attribute): Modify expansion of the 'Old attribute to
recognize new expansion model and use Wrapped_Statements instead
of Postconditions_Proc.
* exp_ch6.adb
(Add_Return): Remove special expansion for postconditions.
(Expand_Call): Modify condition checking for calls to access
subprogram wrappers to handle new expansion models.
(Expand_Call_Helper): Remove special expansion for postconditions.
(Expand_Non_Function_Return): Remove special expansion for
postconditions.
(Expand_Simple_Function_Return): Remove special expansion for
postconditions.
* exp_ch7.adb
(Build_Finalizer): Deleted, but replaced by code in
Build_Finalizer_Helper
(Build_Finalizer_Helper): Renamed to Build_Finalizer, and special
handling of 'Old objects removed.
* exp_ch9.adb
(Build_Contract_Wrapper): Renamed and moved to contracts package.
* exp_prag.adb
(Expand_Pragma_Contract_Cases): Delay analysis of contracts since
they now instead get analyzed as part of the wrapper generation
instead of after analysis of their corresponding subprogram's
body.
(Expand_Pragma_Check): Label expanded if-statements which come
from the expansion of assertion statements as
Comes_From_Check_Or_Contract.
* freeze.adb
(Freeze_Entity): Add special case to avoid freezing when a freeze
node gets generated as part of the expansion of a postcondition
check.
* gen_il-gen-gen_nodes.adb: Add new flag
Comes_From_Check_Or_Contract.
* gen_il-fields.ads: Add new field Wrapped_Statements. Add new
flag Comes_From_Check_Or_Contract.
* gen_il-gen-gen_entities.adb: Add new field Wrapped_Statements.
* ghost.adb
(Is_OK_Declaration): Replace Name_uPostconditions with
Name_uWrapped_Statements.
(Is_OK_Statement): Simplify condition due to the loss of
Original_Node as a result of the new expansion model of contracts
and use new flag Comes_From_Check_Or_Contract in its place.
* inline.adb
(Declare_Postconditions_Result): Replace Name_uPostconditions with
Name_uWrapped_Statements.
(Expand_Inlined_Call): Replace Name_uPostconditions with
Name_uWrapped_Statements.
* lib.adb, lib.ads
(ipu): Created to aid in debugging.
* lib-xref.adb
(Generate_References): Remove special handling for postcondition
procedures.
* sem_attr.adb
(Analyze_Attribute_Old_Result): Add new context in which 'Old can
appear due to the changes in expansion. Replace
Name_uPostconditions with Name_uWrapped_Statements.
(Result): Replace Name_uPostconditions with
Name_uWrapped_Statements.
* sem_ch11.adb
(Analyze_Handled_Statements): Remove check to exclude warnings on
useless assignments 

[Ada] Remove a no-longer-correct comment

[Marc Poulhiès via Gcc-patches]

Remove a comment about the former use of the -gnatd9 switch (that switch is
now unused).

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

gcc/ada/

* debug.adb: remove a comment.diff --git a/gcc/ada/debug.adb b/gcc/ada/debug.adb
--- a/gcc/ada/debug.adb
+++ b/gcc/ada/debug.adb
@@ -1089,9 +1089,6 @@ package body Debug is
--   opposite endianness from the actual correct value. Useful in
--   testing out code generation from the packed routines.
 
-   --  d9   This allows lock free implementation for protected objects
-   --   (see Exp_Ch9).
-
--  d.1  Sets Opt.Unnest_Subprogram_Mode to enable unnesting of subprograms.
--   This special pass does not actually unnest things, but it ensures
--   that a nested procedure does not contain any uplevel references.

[Ada] Fix issues with compiling ACATS test for user-defined literals

[Marc Poulhiès via Gcc-patches]

The draft ACATS test (which we developed) for the Ada 2022 feature of
user-defined literals has compile-time problems that are fixed with this
set of changes.  Two of these involve the resolution of named numbers
in the context where an implicit literal conversion can occur, and for
equality when a literal or named number is an operand. Furthermore,
the compiler can hang in some cases when a numeric literal is used
in a context where the expected type is a type derived two levels
down from a tagged type that specifies a literal aspect.

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

gcc/ada/

* sem_res.adb
(Resolve_Equality_Op): Add handling for equality ops with
user-defined literal operands.
* sem_util.ads
(Is_User_Defined_Literal): Update spec comment to indicate
inclusion of named number cases.
* sem_util.adb
(Corresponding_Primitive_Op): Rather than following the chain of
ancestor subprograms via Alias and Overridden_Operation links, we
check for matching profiles between primitive subprograms of the
descendant type and the ancestor subprogram (by calling a new
nested function Profile_Matches_Ancestor). This prevents the
compiler from hanging due to circular linkages via those fields
that can occur between inherited and overriding subprograms
(which might indicate a latent bug, but one that may be rather
delicate to resolve).
(Profile_Matches_Ancestor): New nested subprogram to compare the
profile of a primitive subprogram with the profile of a candidate
ancestor subprogram.
(Is_User_Defined_Literal): Also return True in cases where the
node N denotes a named number (E_Name_Integer and E_Named_Real).diff --git a/gcc/ada/sem_res.adb b/gcc/ada/sem_res.adb
--- a/gcc/ada/sem_res.adb
+++ b/gcc/ada/sem_res.adb
@@ -8876,6 +8876,20 @@ package body Sem_Res is
  end if;
 
   else
+
+ --  For Ada 2022, check for user-defined literals when the type has
+ --  the appropriate aspect.
+
+ if Has_Applicable_User_Defined_Literal (L, Etype (R)) then
+Resolve (L, Etype (R));
+Set_Etype (N, Standard_Boolean);
+ end if;
+
+ if Has_Applicable_User_Defined_Literal (R, Etype (L)) then
+Resolve (R, Etype (L));
+Set_Etype (N, Standard_Boolean);
+ end if;
+
  --  Deal with other error cases
 
  if T = Any_Stringor else


diff --git a/gcc/ada/sem_util.adb b/gcc/ada/sem_util.adb
--- a/gcc/ada/sem_util.adb
+++ b/gcc/ada/sem_util.adb
@@ -7182,7 +7182,51 @@ package body Sem_Util is
   Typ  : constant Entity_Id := Find_Dispatching_Type (Ancestor_Op);
   Elmt : Elmt_Id;
   Subp : Entity_Id;
-  Prim : Entity_Id;
+
+  function Profile_Matches_Ancestor (S : Entity_Id) return Boolean;
+  --  Returns True if subprogram S has the proper profile for an
+  --  overriding of Ancestor_Op (that is, corresponding formals either
+  --  have the same type, or are corresponding controlling formals,
+  --  and similarly for result types).
+
+  --
+  -- Profile_Matches_Ancestor --
+  --
+
+  function Profile_Matches_Ancestor (S : Entity_Id) return Boolean is
+ F1 : Entity_Id := First_Formal (Ancestor_Op);
+ F2 : Entity_Id := First_Formal (S);
+
+  begin
+ if Ekind (Ancestor_Op) /= Ekind (S) then
+return False;
+ end if;
+
+ --  ??? This should probably account for anonymous access formals,
+ --  but the parent function (Corresponding_Primitive_Op) is currently
+ --  only called for user-defined literal functions, which can't have
+ --  such formals. But if this is ever used in a more general context
+ --  it should be extended to handle such formals (and result types).
+
+ while Present (F1) and then Present (F2) loop
+if Etype (F1) = Etype (F2)
+  or else Is_Ancestor (Typ, Etype (F2))
+then
+   Next_Formal (F1);
+   Next_Formal (F2);
+else
+   return False;
+end if;
+ end loop;
+
+ return No (F1)
+   and then No (F2)
+   and then (Etype (Ancestor_Op) = Etype (S)
+  or else Is_Ancestor (Typ, Etype (S)));
+  end Profile_Matches_Ancestor;
+
+   --  Start of processing for Corresponding_Primitive_Op
+
begin
   pragma Assert (Is_Dispatching_Operation (Ancestor_Op));
   pragma Assert (Is_Ancestor (Typ, Descendant_Type)
@@ -7193,12 +7237,12 @@ package body Sem_Util is
   while Present (Elmt) loop
  Subp := Node (Elmt);
 
- --  For regular primitives we only need to traverse the chain of
- --  ancestors when the name matches the name of Ancestor_Op, but
- --  for 

[Ada] Disable Support_Atomic_Primitives on QNX and VxWorks targets

[Marc Poulhiès via Gcc-patches]

The current configuration of the QNX and VxWorks runtimes does not support
atomic primitives.

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

gcc/ada/

* libgnat/system-qnx-arm.ads: Set Support_Atomic_Primitives to
false.
* libgnat/system-vxworks7-aarch64.ads: Ditto.
* libgnat/system-vxworks7-aarch64-rtp-smp.ads: Ditto.
* libgnat/system-vxworks7-arm.ads: Ditto.
* libgnat/system-vxworks7-arm-rtp-smp.ads: Ditto.
* libgnat/system-vxworks7-x86-kernel.ads: Ditto.
* libgnat/system-vxworks7-x86-rtp-smp.ads: Ditto.diff --git a/gcc/ada/libgnat/system-qnx-arm.ads b/gcc/ada/libgnat/system-qnx-arm.ads
--- a/gcc/ada/libgnat/system-qnx-arm.ads
+++ b/gcc/ada/libgnat/system-qnx-arm.ads
@@ -142,7 +142,7 @@ private
Stack_Check_Probes: constant Boolean := True;
Stack_Check_Limits: constant Boolean := False;
Support_Aggregates: constant Boolean := True;
-   Support_Atomic_Primitives : constant Boolean := True;
+   Support_Atomic_Primitives : constant Boolean := False;
Support_Composite_Assign  : constant Boolean := True;
Support_Composite_Compare : constant Boolean := True;
Support_Long_Shifts   : constant Boolean := True;


diff --git a/gcc/ada/libgnat/system-vxworks7-aarch64-rtp-smp.ads b/gcc/ada/libgnat/system-vxworks7-aarch64-rtp-smp.ads
--- a/gcc/ada/libgnat/system-vxworks7-aarch64-rtp-smp.ads
+++ b/gcc/ada/libgnat/system-vxworks7-aarch64-rtp-smp.ads
@@ -151,7 +151,7 @@ private
Stack_Check_Probes: constant Boolean := True;
Stack_Check_Limits: constant Boolean := False;
Support_Aggregates: constant Boolean := True;
-   Support_Atomic_Primitives : constant Boolean := True;
+   Support_Atomic_Primitives : constant Boolean := False;
Support_Composite_Assign  : constant Boolean := True;
Support_Composite_Compare : constant Boolean := True;
Support_Long_Shifts   : constant Boolean := True;


diff --git a/gcc/ada/libgnat/system-vxworks7-aarch64.ads b/gcc/ada/libgnat/system-vxworks7-aarch64.ads
--- a/gcc/ada/libgnat/system-vxworks7-aarch64.ads
+++ b/gcc/ada/libgnat/system-vxworks7-aarch64.ads
@@ -148,7 +148,7 @@ private
Stack_Check_Probes: constant Boolean := True;
Stack_Check_Limits: constant Boolean := False;
Support_Aggregates: constant Boolean := True;
-   Support_Atomic_Primitives : constant Boolean := True;
+   Support_Atomic_Primitives : constant Boolean := False;
Support_Composite_Assign  : constant Boolean := True;
Support_Composite_Compare : constant Boolean := True;
Support_Long_Shifts   : constant Boolean := True;


diff --git a/gcc/ada/libgnat/system-vxworks7-arm-rtp-smp.ads b/gcc/ada/libgnat/system-vxworks7-arm-rtp-smp.ads
--- a/gcc/ada/libgnat/system-vxworks7-arm-rtp-smp.ads
+++ b/gcc/ada/libgnat/system-vxworks7-arm-rtp-smp.ads
@@ -148,7 +148,7 @@ private
Stack_Check_Probes: constant Boolean := True;
Stack_Check_Limits: constant Boolean := False;
Support_Aggregates: constant Boolean := True;
-   Support_Atomic_Primitives : constant Boolean := True;
+   Support_Atomic_Primitives : constant Boolean := False;
Support_Composite_Assign  : constant Boolean := True;
Support_Composite_Compare : constant Boolean := True;
Support_Long_Shifts   : constant Boolean := True;


diff --git a/gcc/ada/libgnat/system-vxworks7-arm.ads b/gcc/ada/libgnat/system-vxworks7-arm.ads
--- a/gcc/ada/libgnat/system-vxworks7-arm.ads
+++ b/gcc/ada/libgnat/system-vxworks7-arm.ads
@@ -146,7 +146,7 @@ private
Stack_Check_Probes: constant Boolean := True;
Stack_Check_Limits: constant Boolean := False;
Support_Aggregates: constant Boolean := True;
-   Support_Atomic_Primitives : constant Boolean := True;
+   Support_Atomic_Primitives : constant Boolean := False;
Support_Composite_Assign  : constant Boolean := True;
Support_Composite_Compare : constant Boolean := True;
Support_Long_Shifts   : constant Boolean := True;


diff --git a/gcc/ada/libgnat/system-vxworks7-x86-kernel.ads b/gcc/ada/libgnat/system-vxworks7-x86-kernel.ads
--- a/gcc/ada/libgnat/system-vxworks7-x86-kernel.ads
+++ b/gcc/ada/libgnat/system-vxworks7-x86-kernel.ads
@@ -146,7 +146,7 @@ private
Stack_Check_Probes: constant Boolean := True;
Stack_Check_Limits: constant Boolean := False;
Support_Aggregates: constant Boolean := True;
-   Support_Atomic_Primitives : constant Boolean := True;
+   Support_Atomic_Primitives : constant Boolean := False;
Support_Composite_Assign  : constant Boolean := True;
Support_Composite_Compare : constant Boolean := True;
Support_Long_Shifts   : constant Boolean := True;


diff --git a/gcc/ada/libgnat/system-vxworks7-x86-rtp-smp.ads b/gcc/ada/libgnat/system-vxworks7-x86-rtp-smp.ads
--- a/gcc/ada/libgnat/system-vxworks7-x86-rtp-smp.ads
+++ 

[Ada] Fix bugs in check-related warnings.

[Marc Poulhiès via Gcc-patches]

Make sure warnings about wrong-length aggregates don't get
suppressed. Such a warning (in a with-ed unit) can be the only
explanation for an error about No_Elaboration_Code violations.

Avoid passing a bogus "#" to Error_Msg. We really should never
construct message templates by concatenating strings that can
come from input data, but there are too many cases of that to
clean up. The message template parameters should really be
of a type other than String, to avoid these kinds of bugs,
but again, that's too much work to clean up now.

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

gcc/ada/

* checks.adb
(Selected_Length_Checks): In the message for an aggregate that has
too few or too many elements, add "!!" to make sure the warning
gets printed in with'ed units. Note that we have to put "!!"
before the "??", because Compile_Time_Constraint_Error detects
warnings by comparing the last character of the message with '?'
(which is bit dubious, but we're not changing that here).
(Length_Mismatch_Info_Message): Use Unat for some things that
can't be negative. Specify Decimal instead of Auto in calls to
UI_Image.
* sem_util.adb
(Compile_Time_Constraint_Error): Minor.
* uintp.adb
(Image_Uint): It's always better to initialize objects on their
declaration.diff --git a/gcc/ada/checks.adb b/gcc/ada/checks.adb
--- a/gcc/ada/checks.adb
+++ b/gcc/ada/checks.adb
@@ -9951,8 +9951,8 @@ package body Checks is
   --Typ'Length /= Exp'Length
 
   function Length_Mismatch_Info_Message
-(Left_Element_Count  : Uint;
- Right_Element_Count : Uint) return String;
+(Left_Element_Count  : Unat;
+ Right_Element_Count : Unat) return String;
   --  Returns a message indicating how many elements were expected
   --  (Left_Element_Count) and how many were found (Right_Element_Count).
 
@@ -10150,14 +10150,14 @@ package body Checks is
   --
 
   function Length_Mismatch_Info_Message
-(Left_Element_Count  : Uint;
- Right_Element_Count : Uint) return String
+(Left_Element_Count  : Unat;
+ Right_Element_Count : Unat) return String
   is
 
- function Plural_Vs_Singular_Ending (Count : Uint) return String;
+ function Plural_Vs_Singular_Ending (Count : Unat) return String;
  --  Returns an empty string if Count is 1; otherwise returns "s"
 
- function Plural_Vs_Singular_Ending (Count : Uint) return String is
+ function Plural_Vs_Singular_Ending (Count : Unat) return String is
  begin
 if Count = 1 then
return "";
@@ -10167,12 +10167,19 @@ package body Checks is
  end Plural_Vs_Singular_Ending;
 
   begin
- return "expected " & UI_Image (Left_Element_Count)
+ return "expected "
+  & UI_Image (Left_Element_Count, Format => Decimal)
   & " element"
   & Plural_Vs_Singular_Ending (Left_Element_Count)
-  & "; found " & UI_Image (Right_Element_Count)
+  & "; found "
+  & UI_Image (Right_Element_Count, Format => Decimal)
   & " element"
   & Plural_Vs_Singular_Ending (Right_Element_Count);
+ --  "Format => Decimal" above is needed because otherwise UI_Image
+ --  can sometimes return a hexadecimal number 16#...#, but "#" means
+ --  something special to Errout. A previous version used the default
+ --  Auto, which was essentially the same bug as documented here:
+ --  https://xkcd.com/327/ .
   end Length_Mismatch_Info_Message;
 
   -
@@ -10371,14 +10378,14 @@ package body Checks is
if L_Length > R_Length then
   Add_Check
 (Compile_Time_Constraint_Error
-  (Wnode, "too few elements for}??", T_Typ,
+  (Wnode, "too few elements for}!!??", T_Typ,
Extra_Msg => Length_Mismatch_Info_Message
   (L_Length, R_Length)));
 
elsif L_Length < R_Length then
   Add_Check
 (Compile_Time_Constraint_Error
-  (Wnode, "too many elements for}??", T_Typ,
+  (Wnode, "too many elements for}!!??", T_Typ,
Extra_Msg => Length_Mismatch_Info_Message
   (L_Length, R_Length)));
end if;


diff --git a/gcc/ada/sem_util.adb b/gcc/ada/sem_util.adb
--- a/gcc/ada/sem_util.adb
+++ b/gcc/ada/sem_util.adb
@@ -6691,8 +6691,6 @@ package body Sem_Util is
   Wmsg 

[Ada] Disable Support_Atomic_Primitives on x86_64 VxWorks

[Marc Poulhiès via Gcc-patches]

The current configuration of the x86-64 VxWorks runtimes does not support
atomic primitives. x86-64 VxWorks was missed from the previous patch.

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

gcc/ada/

* libgnat/system-vxworks7-x86_64-kernel.ads: Set
Support_Atomic_Primitives to false.
* libgnat/system-vxworks7-x86_64-rtp-smp.ads: Ditto.diff --git a/gcc/ada/libgnat/system-vxworks7-x86_64-kernel.ads b/gcc/ada/libgnat/system-vxworks7-x86_64-kernel.ads
--- a/gcc/ada/libgnat/system-vxworks7-x86_64-kernel.ads
+++ b/gcc/ada/libgnat/system-vxworks7-x86_64-kernel.ads
@@ -146,7 +146,7 @@ private
Stack_Check_Probes: constant Boolean := True;
Stack_Check_Limits: constant Boolean := False;
Support_Aggregates: constant Boolean := True;
-   Support_Atomic_Primitives : constant Boolean := True;
+   Support_Atomic_Primitives : constant Boolean := False;
Support_Composite_Assign  : constant Boolean := True;
Support_Composite_Compare : constant Boolean := True;
Support_Long_Shifts   : constant Boolean := True;


diff --git a/gcc/ada/libgnat/system-vxworks7-x86_64-rtp-smp.ads b/gcc/ada/libgnat/system-vxworks7-x86_64-rtp-smp.ads
--- a/gcc/ada/libgnat/system-vxworks7-x86_64-rtp-smp.ads
+++ b/gcc/ada/libgnat/system-vxworks7-x86_64-rtp-smp.ads
@@ -149,7 +149,7 @@ private
Stack_Check_Probes: constant Boolean := True;
Stack_Check_Limits: constant Boolean := False;
Support_Aggregates: constant Boolean := True;
-   Support_Atomic_Primitives : constant Boolean := True;
+   Support_Atomic_Primitives : constant Boolean := False;
Support_Composite_Assign  : constant Boolean := True;
Support_Composite_Compare : constant Boolean := True;
Support_Long_Shifts   : constant Boolean := True;

[Ada] Parser and lexer cleanup

[Marc Poulhiès via Gcc-patches]

This patch makes various minor cleanup changes to the parser.
No change in behavior.

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

gcc/ada/

* par-tchk.adb, par-util.adb, prep.adb, prepcomp.adb, scng.adb:
Use "in" instead of chains of "=" connected with "or else".
Likewise for "not in", "/=", "and then". Misc cleanup.
* par-ch10.adb, par-ch12.adb, par-ch13.adb, par-ch4.adb: Likewise.
* par-ch8.adb, par-ch9.adb, par-endh.adb, par-sync.adb: Likewise.
* par.adb
(Pf_Rec): Remove filler, which was added August 25, 1993 to get
around a compiler limitation that no longer exists. Minor cleanup.
Remove useless qualfications.
* par-ch3.adb: Remove redundant return statements.
(Component_Scan_Loop): Remove loop name; there are no nested
loops, so it's unnecessary and possibly misleading, and it causes
too-long lines.
* par-ch5.adb: DRY: Remove comments that repeat the comments in
par.adb.
(P_Sequence_Of_Statements): It is better to initialize things on
the declaration. And constants are better than variables.
(Test_Statement_Required): Remove unnecessary insertion of a null
statement.
* par-ch6.adb, par-ch7.adb: DRY: Remove comments that repeat the
comments in par.adb.

patch.diff.gz
Description: application/gzip

[Ada] Revert "Enforce matching of extra formals"

[Marc Poulhiès via Gcc-patches]

This reverts commit 51abc0cc8691daecd7cec8372e4988e9f3f1913c.

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



patch.diff.gz
Description: application/gzip

Re: [PATCH][GCC 12] arm: Fix constant immediates predicates and constraints for some MVE builtins

[Christophe Lyon via Gcc-patches]

Hi!

On 9/9/22 11:33, Christophe Lyon wrote:

This is a backport from trunk to gcc-12.

Several MVE builtins incorrectly use the same predicate/constraint
pair for several modes, which does not match the specification.
This patch uses the appropriate iterator instead.

2022-09-06  Christophe Lyon  

gcc/
* config/arm/mve.md (mve_vqshluq_n_s): Use
MVE_pred/MVE_constraint instead of mve_imm_7/Ra.
(mve_vqshluq_m_n_s): Likewise.
(mve_vqrshrnbq_n_): Use MVE_pred3/MVE_constraint3
instead of mve_imm_8/Rb.
(mve_vqrshrunbq_n_s): Likewise.
(mve_vqrshrntq_n_): Likewise.
(mve_vqrshruntq_n_s): Likewise.
(mve_vrshrnbq_n_): Likewise.
(mve_vrshrntq_n_): Likewise.
(mve_vqrshrnbq_m_n_): Likewise.
(mve_vqrshrntq_m_n_): Likewise.
(mve_vrshrnbq_m_n_): Likewise.
(mve_vrshrntq_m_n_): Likewise.
(mve_vqrshrunbq_m_n_s): Likewise.
(mve_vsriq_n_): Likewise.

(cheerry-picked from c3fb6658c7670e446f2fd00984404d971e416b3c)



Is this backport OK for gcc-12? (with the "cheerry" typo above fixed)

Thanks,

Christophe



---
  gcc/config/arm/mve.md | 30 +++---
  1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/gcc/config/arm/mve.md b/gcc/config/arm/mve.md
index f16991c0a34..469e7e7f8dc 100644
--- a/gcc/config/arm/mve.md
+++ b/gcc/config/arm/mve.md
@@ -1617,7 +1617,7 @@ (define_insn "mve_vqshluq_n_s"
[
 (set (match_operand:MVE_2 0 "s_register_operand" "=w")
(unspec:MVE_2 [(match_operand:MVE_2 1 "s_register_operand" "w")
-  (match_operand:SI 2 "mve_imm_7" "Ra")]
+  (match_operand:SI 2 "" "")]
 VQSHLUQ_N_S))
]
"TARGET_HAVE_MVE"
@@ -2608,7 +2608,7 @@ (define_insn "mve_vqrshrnbq_n_"
 (set (match_operand: 0 "s_register_operand" "=w")
(unspec: [(match_operand: 1 "s_register_operand" 
"0")
 (match_operand:MVE_5 2 "s_register_operand" 
"w")
-(match_operand:SI 3 "mve_imm_8" "Rb")]
+(match_operand:SI 3 "" 
"")]
 VQRSHRNBQ_N))
]
"TARGET_HAVE_MVE"
@@ -2623,7 +2623,7 @@ (define_insn "mve_vqrshrunbq_n_s"
 (set (match_operand: 0 "s_register_operand" "=w")
(unspec: [(match_operand: 1 "s_register_operand" 
"0")
 (match_operand:MVE_5 2 "s_register_operand" 
"w")
-(match_operand:SI 3 "mve_imm_8" "Rb")]
+(match_operand:SI 3 "" 
"")]
 VQRSHRUNBQ_N_S))
]
"TARGET_HAVE_MVE"
@@ -3563,7 +3563,7 @@ (define_insn "mve_vsriq_n_"
 (set (match_operand:MVE_2 0 "s_register_operand" "=w")
(unspec:MVE_2 [(match_operand:MVE_2 1 "s_register_operand" "0")
   (match_operand:MVE_2 2 "s_register_operand" "w")
-  (match_operand:SI 3 "mve_imm_selective_upto_8" "Rg")]
+  (match_operand:SI 3 "" "")]
 VSRIQ_N))
]
"TARGET_HAVE_MVE"
@@ -4466,7 +4466,7 @@ (define_insn "mve_vqrshrntq_n_"
 (set (match_operand: 0 "s_register_operand" "=w")
(unspec: [(match_operand: 1 "s_register_operand" 
"0")
   (match_operand:MVE_5 2 "s_register_operand" "w")
-  (match_operand:SI 3 "mve_imm_8" "Rb")]
+  (match_operand:SI 3 "" "")]
 VQRSHRNTQ_N))
]
"TARGET_HAVE_MVE"
@@ -4482,7 +4482,7 @@ (define_insn "mve_vqrshruntq_n_s"
 (set (match_operand: 0 "s_register_operand" "=w")
(unspec: [(match_operand: 1 "s_register_operand" 
"0")
   (match_operand:MVE_5 2 "s_register_operand" "w")
-  (match_operand:SI 3 "mve_imm_8" "Rb")]
+  (match_operand:SI 3 "" "")]
 VQRSHRUNTQ_N_S))
]
"TARGET_HAVE_MVE"
@@ -4770,7 +4770,7 @@ (define_insn "mve_vrshrnbq_n_"
 (set (match_operand: 0 "s_register_operand" "=w")
(unspec: [(match_operand: 1 "s_register_operand" 
"0")
   (match_operand:MVE_5 2 "s_register_operand" "w")
-  (match_operand:SI 3 "mve_imm_8" "Rb")]
+  (match_operand:SI 3 "" "")]
 VRSHRNBQ_N))
]
"TARGET_HAVE_MVE"
@@ -4786,7 +4786,7 @@ (define_insn "mve_vrshrntq_n_"
 (set (match_operand: 0 "s_register_operand" "=w")
(unspec: [(match_operand: 1 "s_register_operand" 
"0")
   (match_operand:MVE_5 2 "s_register_operand" "w")
-  (match_operand:SI 3 "mve_imm_8" "Rb")]
+  (match_operand:SI 3 "" "")]
 VRSHRNTQ_N))
]
"TARGET_HAVE_MVE"
@@ -4980,7 +4980,7 @@ (define_insn "mve_vqshluq_m_n_s"
 (set (match_operand:MVE_2 0 "s_register_operand" "=w")
(unspec:MVE_2 [(match_operand:MVE_2 1 "s_register_operand" "0")
   (match_operand:MVE_2 2 "s_register_operand" "w")
-  

[PATCH] c++: Implement P1467R9 - Extended floating-point types and standard names compiler part except for bfloat16 [PR106652]

[Jakub Jelinek via Gcc-patches]

Hi!

The following patch implements the compiler part of C++23
P1467R9 - Extended floating-point types and standard names compiler part
by introducing _Float{16,32,64,128} as keywords and builtin types
like they are implemented for C already since GCC 7.
It doesn't introduce _Float{32,64,128}x for C++, those remain C only
for now, mainly because 
https://itanium-cxx-abi.github.io/cxx-abi/abi.html#mangling
has mangling for:
::= DF  _ # ISO/IEC TS 18661 binary floating point type _FloatN (N bits)
but doesn't for _FloatNx.  And it doesn't add anything for bfloat16_t
support, see below.
Regarding mangling, I think mangling _FloatNx as DF  x _ would be
possible, but would need to be discussed and voted in.
As there is no _FloatNx support for C++, I think it is wrong to announce
it through __FLT{32,64,128}X_*__ predefined macros (so the patch disables
those for C++; unfortunately g++ 7 to 12 will predefine those and also
__FLT{32,64,128}_*__ even when _FloatN support isn't implemented).
The patch wants to keep backwards compatibility with how __float128 has
been handled in C++ before, both for mangling and behavior in binary
operations, overload resolution etc.  So, there are some backend changes
where for C __float128 and _Float128 are the same type (float128_type_node
and float128t_type_node are the same pointer), but for C++ they are distinct
types which mangle differently and _Float128 is treated as extended
floating-point type while __float128 is treated as non-standard floating
point type.  The various C++23 changes about how floating-point types
are changed are actually implemented as written in the spec only if at least
one of the types involved is _Float{16,32,64,128} and kept previous behavior
otherwise.  For float/double/long double the rules are actually written that
they behave the same as before.
There is some backwards incompatibility at least on x86 regarding _Float16,
because that type was already used by that name and with the DF16_ mangling
(but only since GCC 12 and I think it isn't that widely used in the wild
yet).  E.g. config/i386/avx512fp16intrin.h shows the issues, where
in C or in GCC 12 in C++ one could pass 0.0f to a builtin taking _Float16
argument, but with the changes that is not possible anymore, one needs
to either use 0.0f16 or (_Float16) 0.0f.
We have also a problem with glibc headers, where since glibc 2.27
math.h and complex.h aren't compilable with these changes.  One gets
errors like:
In file included from /usr/include/math.h:43,
 from abc.c:1:
/usr/include/bits/floatn.h:86:9: error: multiple types in one declaration
   86 | typedef __float128 _Float128;
  | ^~
/usr/include/bits/floatn.h:86:20: error: declaration does not declare anything 
[-fpermissive]
   86 | typedef __float128 _Float128;
  |^
In file included from /usr/include/bits/floatn.h:119:
/usr/include/bits/floatn-common.h:214:9: error: multiple types in one 
declaration
  214 | typedef float _Float32;
  | ^
/usr/include/bits/floatn-common.h:214:15: error: declaration does not declare 
anything [-fpermissive]
  214 | typedef float _Float32;
  |   ^~~~
/usr/include/bits/floatn-common.h:251:9: error: multiple types in one 
declaration
  251 | typedef double _Float64;
  | ^~
/usr/include/bits/floatn-common.h:251:16: error: declaration does not declare 
anything [-fpermissive]
  251 | typedef double _Float64;
  |^~~~
This is from snippets like:
/* The remaining of this file provides support for older compilers.  */
# if __HAVE_FLOAT128

/* The type _Float128 exists only since GCC 7.0.  */
#  if !__GNUC_PREREQ (7, 0) || defined __cplusplus
typedef __float128 _Float128;
#  endif
where it hardcodes that C++ doesn't have _Float{16,32,64,128} support nor
{f,F}{16,32,64,128} literal suffixes nor _Complex _Float{16,32,64,128}.
The patch fixincludes this for now and hopefully if this is committed, then
glibc can change those.  Right now the patch changes those
#  if !__GNUC_PREREQ (7, 0) || defined __cplusplus
conditions to
#  if !__GNUC_PREREQ (7, 0) || (defined __cplusplus && !__GNUC_PREREQ (13, 1) 
&& defined __FLT32X_MANT_DIG__)
where it relies on __FLT32X_*__ macros no longer being predefined for C++.
Now, I guess for the fixincludes it could also use
#  if !__GNUC_PREREQ (7, 0) || (defined __cplusplus && !__GNUC_PREREQ (13, 0))
where earlier GCC 13 snapshots would not be doing the fixincludes,
but the question is what to use for upstream glibc, because
there will be 13.0 snapshots where C++ doesn't support _Float{16,32,64,128}
and where it is essential to use what glibc has been doing previously
and using the #else would fail miserably, and then 13.0 snapshots where it
does support it and where using the if would fail miserably.
One option is to use
#  if !__GNUC_PREREQ (7, 0) || (defined __cplusplus && !__GNUC_PREREQ (13, 1))
in glibc and rely on fixincludes for 13.0 

Re: [PATCH v2] gcov: Respect triplet when looking for gcov

[Mikael Morin]

Le 12/09/2022 à 09:06, Torbjorn SVENSSON a écrit :



On 2022-09-11 21:38, Mikael Morin wrote:

Le 11/09/2022 à 18:04, Torbjorn SVENSSON a écrit :

Can you fix it for me and submit it or do you want me to send a v3?


For trivial things like this, there is no need for a v3 (nor was there 
for a v2).

Do you miss a git write account and need someone to push for you?


Ok!

I do not have any write access, so yes, please push it for me!


No problem, I will do it the next time I synchronize my work tree, but 
it will have to wait a few days until that time.

Re: [PATCH 1/2] Add new target hook: constant_ok_for_cprop_p

[Richard Biener via Gcc-patches]

On Sun, Sep 11, 2022 at 10:51 PM Takayuki 'January June' Suwa via
Gcc-patches  wrote:
>
> Hi,
>
> Many RISC machines, as we know, have some restrictions on placing 
> register-width constants in the source of load-immediate machine 
> instructions, so the target must provide a solution for that in the machine 
> description.
>
> A naive way would be to solve it early, ie. to replace with read constants 
> pooled in memory when expanding to RTL.
>
> Alternatively, a more fancy approach would be to forgo placement in the 
> constant pool until somewhere before the reload/LRA eg. the "split1" pass to 
> give the optimization passes that involve immediates a chance to work.
>
> If we choose the latter, we can expect better results with RTL if-conversion, 
> constant folding, etc., but it often propagates constants that are too large 
> in size to resolve to a simple load-immediate instruction.
>
> This is because constant propagation has no way of telling about it, so this 
> patch provides it.

What does prevent other passes like fwprop, CSE and PRE from doing the
same propagation?  Can that be the solution for
constant propagation as well?

Richard.

> ===
>
> This new target hook can be used to tell cprop whether or not to propagate
> a constant depending on its contents.
>
> For backwards compatibility, the default setting for this hook retains the
> old behavior.
>
> gcc/ChangeLog:
>
> * hooks.h (hook_bool_const_rtx_true): New prototype.
> * hooks.cc (hook_bool_const_rtx_true): New default hook.
> * target.def (constant_ok_for_cprop_p): New target hook.
> * cprop.cc (cprop_constant_p): Change to use the hook.
> * doc/tm.texi.in, (TARGET_CONSTANT_OK_FOR_CPROP_P): New @hook.
> * doc/tm.texi (TARGET_CONSTANT_OK_FOR_CPROP_P): New document.
> ---
>  gcc/cprop.cc   |  4 +++-
>  gcc/doc/tm.texi| 12 
>  gcc/doc/tm.texi.in |  2 ++
>  gcc/hooks.cc   |  7 +++
>  gcc/hooks.h|  1 +
>  gcc/target.def | 14 ++
>  6 files changed, 39 insertions(+), 1 deletion(-)
>
> diff --git a/gcc/cprop.cc b/gcc/cprop.cc
> index 580f811545d..dfb1e88e9b4 100644
> --- a/gcc/cprop.cc
> +++ b/gcc/cprop.cc
> @@ -40,6 +40,7 @@ along with GCC; see the file COPYING3.  If not see
>  #include "dbgcnt.h"
>  #include "cfgloop.h"
>  #include "gcse.h"
> +#include "target.h"
>
>
>  /* An obstack for our working variables.  */
> @@ -249,7 +250,8 @@ insert_set_in_table (rtx dest, rtx src, rtx_insn *insn,
>  static bool
>  cprop_constant_p (const_rtx x)
>  {
> -  return CONSTANT_P (x) && (GET_CODE (x) != CONST || shared_const_p (x));
> +  return CONSTANT_P (x) && targetm.constant_ok_for_cprop_p (x)
> +&& (GET_CODE (x) != CONST || shared_const_p (x));
>  }
>
>  /* Determine whether the rtx X should be treated as a register that can
> diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi
> index 858bfb80cec..83151626a71 100644
> --- a/gcc/doc/tm.texi
> +++ b/gcc/doc/tm.texi
> @@ -12187,6 +12187,18 @@ MIPS, where add-immediate takes a 16-bit signed 
> value,
>  is zero, which disables this optimization.
>  @end deftypevr
>
> +@deftypefn {Target Hook} bool TARGET_CONSTANT_OK_FOR_CPROP_P (const_rtx 
> @var{cst})
> +On some target machines, such as RISC ones, load-immediate instructions
> +often have a limited range (for example, within signed 12 bits or less).
> +Because they will be typically placed into the constant pool,
> +unconditionally propagating constants that exceed such limit can lead to
> +increased number of instruction and/or memory read access.
> +This target hook should return @code{false} if @var{cst}, a candidate for
> +constant propagation, is undesirable as a source for load-immediate
> +instructions.
> +The default version of this hook always returns @code{true}.
> +@end deftypefn
> +
>  @deftypefn {Target Hook} {unsigned HOST_WIDE_INT} TARGET_ASAN_SHADOW_OFFSET 
> (void)
>  Return the offset bitwise ored into shifted address to get corresponding
>  Address Sanitizer shadow memory address.  NULL if Address Sanitizer is not
> diff --git a/gcc/doc/tm.texi.in b/gcc/doc/tm.texi.in
> index 21b849ea32a..147331b0f53 100644
> --- a/gcc/doc/tm.texi.in
> +++ b/gcc/doc/tm.texi.in
> @@ -7887,6 +7887,8 @@ and the associated definitions of those functions.
>
>  @hook TARGET_CONST_ANCHOR
>
> +@hook TARGET_CONSTANT_OK_FOR_CPROP_P
> +
>  @hook TARGET_ASAN_SHADOW_OFFSET
>
>  @hook TARGET_MEMMODEL_CHECK
> diff --git a/gcc/hooks.cc b/gcc/hooks.cc
> index b29233f4f85..67bf3553d26 100644
> --- a/gcc/hooks.cc
> +++ b/gcc/hooks.cc
> @@ -82,6 +82,13 @@ hook_bool_mode_true (machine_mode)
>return true;
>  }
>
> +/* Generic hook that takes (const_rtx) and returns true.  */
> +bool
> +hook_bool_const_rtx_true (const_rtx)
> +{
> +  return true;
> +}
> +
>  /* Generic hook that takes (machine_mode, machine_mode) and returns true.  */
>  bool
>  hook_bool_mode_mode_true (machine_mode, machine_mode)
> diff --git a/gcc/hooks.h b/gcc/hooks.h
> index 

Re: stdatomic.h: Do not define ATOMIC_VAR_INIT for C2x

[Richard Biener via Gcc-patches]

On Fri, Sep 9, 2022 at 10:41 PM Joseph Myers  wrote:
>
> The  macro ATOMIC_VAR_INIT, previously declared obsolete,
> is removed completely in C2x; disable it for C2x in GCC's
> implementation.  (Although ATOMIC_* are reserved names for this
> header, disabling the macro for C2x still seems appropriate.)
>
> Bootstrapped with no regressions for x86_64-pc-linux-gnu.  OK to commit?

OK

> gcc/
> * ginclude/stdatomic.h [defined __STDC_VERSION__ &&
> __STDC_VERSION__ > 201710L] (ATOMIC_VAR_INIT): Do not define.
>
> gcc/testsuite/
> * gcc.dg/atomic/c2x-stdatomic-var-init-1.c: New test.
>
> diff --git a/gcc/ginclude/stdatomic.h b/gcc/ginclude/stdatomic.h
> index 9f2475b739d..a56ba5d9639 100644
> --- a/gcc/ginclude/stdatomic.h
> +++ b/gcc/ginclude/stdatomic.h
> @@ -79,7 +79,9 @@ typedef _Atomic __INTMAX_TYPE__ atomic_intmax_t;
>  typedef _Atomic __UINTMAX_TYPE__ atomic_uintmax_t;
>
>
> +#if !(defined __STDC_VERSION__ && __STDC_VERSION__ > 201710L)
>  #define ATOMIC_VAR_INIT(VALUE) (VALUE)
> +#endif
>
>  /* Initialize an atomic object pointed to by PTR with VAL.  */
>  #define atomic_init(PTR, VAL)   \
> diff --git a/gcc/testsuite/gcc.dg/atomic/c2x-stdatomic-var-init-1.c 
> b/gcc/testsuite/gcc.dg/atomic/c2x-stdatomic-var-init-1.c
> new file mode 100644
> index 000..1978a410350
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/atomic/c2x-stdatomic-var-init-1.c
> @@ -0,0 +1,9 @@
> +/* Test ATOMIC_VAR_INIT not in C2x.  */
> +/* { dg-do compile } */
> +/* { dg-options "-std=c2x -pedantic-errors" } */
> +
> +#include 
> +
> +#ifdef ATOMIC_VAR_INIT
> +#error "ATOMIC_VAR_INIT defined"
> +#endif
>
> --
> Joseph S. Myers
> jos...@codesourcery.com

[PATCH][pushed] analyzer: remove unused fields

[Martin Liška]

Fixes:
gcc/analyzer/region-model.cc:5918:8: warning: private field 'm_record_type' is 
not used [-Wunused-private-field]
gcc/analyzer/region-model.cc:6305:25: warning: private field 'm_mgr' is not 
used [-Wunused-private-field]

gcc/analyzer/ChangeLog:

* region-model.cc (region_model::maybe_complain_about_infoleak):
  Remove unused fields.
---
 gcc/analyzer/region-model.cc | 12 +++-
 1 file changed, 3 insertions(+), 9 deletions(-)

diff --git a/gcc/analyzer/region-model.cc b/gcc/analyzer/region-model.cc
index 13b8e3eaf1b..22c52872c3e 100644
--- a/gcc/analyzer/region-model.cc
+++ b/gcc/analyzer/region-model.cc
@@ -5838,7 +5838,6 @@ public:
   };
 
   record_layout (tree record_type)
-  : m_record_type (record_type)
   {
 gcc_assert (TREE_CODE (record_type) == RECORD_TYPE);
 
@@ -5918,7 +5917,6 @@ private:
   }
   }
 
-  tree m_record_type;
   auto_vec m_items;
 };
 
@@ -5932,12 +5930,10 @@ class exposure_through_uninit_copy
 public:
   exposure_through_uninit_copy (const region *src_region,
const region *dest_region,
-   const svalue *copied_sval,
-   region_model_manager *mgr)
+   const svalue *copied_sval)
   : m_src_region (src_region),
 m_dest_region (dest_region),
-m_copied_sval (copied_sval),
-m_mgr (mgr)
+m_copied_sval (copied_sval)
   {
 gcc_assert (m_copied_sval->get_kind () == SK_POISONED
|| m_copied_sval->get_kind () == SK_COMPOUND);
@@ -6305,7 +6301,6 @@ private:
   const region *m_src_region;
   const region *m_dest_region;
   const svalue *m_copied_sval;
-  region_model_manager *m_mgr;
 };
 
 /* Return true if any part of SVAL is uninitialized.  */
@@ -6351,8 +6346,7 @@ region_model::maybe_complain_about_infoleak (const region 
*dst_reg,
   if (contains_uninit_p (copied_sval))
 ctxt->warn (new exposure_through_uninit_copy (src_reg,
  dst_reg,
- copied_sval,
- m_mgr));
+ copied_sval));
 }
 
 /* class noop_region_model_context : public region_model_context.  */
-- 
2.37.3

Re: [PATCH v2] gcov: Respect triplet when looking for gcov

[Torbjorn SVENSSON via Gcc-patches]

On 2022-09-11 21:38, Mikael Morin wrote:

Le 11/09/2022 à 18:04, Torbjorn SVENSSON a écrit :

Can you fix it for me and submit it or do you want me to send a v3?


For trivial things like this, there is no need for a v3 (nor was there 
for a v2).

Do you miss a git write account and need someone to push for you?


Ok!

I do not have any write access, so yes, please push it for me!