Re: [PATCH] rs6000: Rework option -mpowerpc64 handling [PR106680]

[Kewen.Lin via Gcc-patches]

Hi Iain,

Thanks very much for your time!!!

on 2022/9/29 03:09, Iain Sandoe wrote:
> Hi Kewen
> 
>> On 28 Sep 2022, at 17:18, Iain Sandoe  wrote:
>>
>> (reduced CC list, if folks want to be re-included .. please add them back).
>>
>>> On 28 Sep 2022, at 07:37, Iain Sandoe  wrote:
>>
 On 28 Sep 2022, at 06:30, Kewen.Lin via Gcc-patches 
  wrote:
>>>
 PR106680 shows that -m32 -mpowerpc64 is different from
 -mpowerpc64 -m32, this is determined by the way how we
 handle option powerpc64 in rs6000_handle_option.

 Segher pointed out this difference should be taken as
 a bug and we should ensure that option powerpc64 is
 independent of -m32/-m64.  So this patch removes the
 handlings in rs6000_handle_option and add some necessary
 supports in rs6000_option_override_internal instead.

 With this patch, if users specify -m{no-,}powerpc64, the
 specified value is honoured, otherwise, for 64bit it
 always enables OPTION_MASK_POWERPC64 while for 32bit
 it disables OPTION_MASK_POWERPC64 if OS_MISSING_POWERPC64.

 Bootstrapped and regress-tested on:
 - powerpc64-linux-gnu P7 and P8 {-m64,-m32}
 - powerpc64le-linux-gnu P9 and P10
 - powerpc-ibm-aix7.2.0.0 {-maix64,-maix32}

 Hi Iain, could you help to test this on darwin to ensure
 it won't break darwin's build and new tests are fine?
 Thanks in advance!
>>>
>>> Will do, it will take a day or so, thanks,
>>
>> Perhaps a small exposition on the target:
>>
>> powerpc-apple-darwin, is perhaps somewhat unusual in that it is nominally a 
>> 32b kernel, but the OS supports 64b processes on suitable hardware (and the 
>> OS does preserve the upper bits of 64b regs in the context).
>>
>> -
>>
>> I bootstrapped (all supported languages) and tested r13-2892 yesterday with 
>> “nominal” results.
>>
>> Then I added this patch .. and did a clean bootstrap (same configuration).
>>
>> the bootstrap fails on the stage3 libgomp (building the ppc64 multilib) with 
>> the error below
>> What is somewhat odd here is that libgomp is bootstrapped with the compiler 
>> and, apparently,
>> openacc-init.c built OK at stage2.
>>
>> ——
>>
>> Of course, powerpc-darwin is not a blocker for anything, it should not hold 
>> you up (but sometimes it
>> manages to find a glitch missed elsewhere).  I will try to take a look at 
>> this this evening see if I can throw
>> any more light on it.
>>
>> --
>>
>> /src-local/gcc-master/libgomp/oacc-init.c:876:1: internal compiler error: 
>> ‘global_options’ are modified in local context
>>  876 | {
>>  | ^
>> 0xe940d7 cl_optimization_compare(gcc_options*, gcc_options*)
>>/scratch/10-5-leo/gcc-master/gcc/options-save.cc:14082
> 
> This repeats on a cross from x86_64-darwin to powerpc-darwin .. (makes debug 
> a bit quicker)
> 
> this is the failing case - which does not (immediately) seem directly 
> connected .. does it ring
> any bells for you?
> 
>16649if (ptr1->x_rs6000_sched_restricted_insns_priority != 
> ptr2->x_rs6000_sched_restricted_insns_priority)
> -> 16650  internal_error ("% are modified in local 
> context”);
> 

I found this flag is mainly related to tune setting and spotted that we have 
some code
for tune setting when no explicit cpu is given. 

...

  else
{
  size_t i;
  enum processor_type tune_proc
= (TARGET_POWERPC64 ? PROCESSOR_DEFAULT64 : PROCESSOR_DEFAULT);

  tune_index = -1;
  for (i = 0; i < ARRAY_SIZE (processor_target_table); i++)
if (processor_target_table[i].processor == tune_proc)
  {
tune_index = i;
break;
  }
}

It checks TARGET_POWERPC64 directly here, my proposed patch will adjust 
TARGET_POWERPC64
after this hunk, so it seems to be problematic for some case.

I'm testing the attached diff which can be applied on top of the previous 
proposed patch
on ppc64 and ppc64le, could you help to test it can fix the issue?

BR,
Kewendiff --git a/gcc/config/rs6000/rs6000.cc b/gcc/config/rs6000/rs6000.cc
index 605d35893f9..3bfbb4eac21 100644
--- a/gcc/config/rs6000/rs6000.cc
+++ b/gcc/config/rs6000/rs6000.cc
@@ -3702,7 +3702,7 @@ rs6000_option_override_internal (bool global_init_p)
   else
{
  /* PowerPC 64-bit LE requires at least ISA 2.07.  */
- const char *default_cpu = (!TARGET_POWERPC64
+ const char *default_cpu = (!TARGET_POWERPC64 && TARGET_32BIT
 ? "powerpc"
 : (BYTES_BIG_ENDIAN
? "powerpc64"
@@ -3713,6 +3713,26 @@ rs6000_option_override_internal (bool global_init_p)
   rs6000_isa_flags |= (flags & ~rs6000_isa_flags_explicit);
 }
 
+  /* With option powerpc64 specified explicitly (either on or off), even if
+ being compiled for 64 bit we don't need to check if it's disabled here,
+ since subtargets will check and raise an error message if necessary

[PATCH] Check nonlinear iv in vect_can_advance_ivs_p.

[liuhongt via Gcc-patches]

vectorizable_nonlinear_induction doesn't always guard
vect_peel_nonlinear_iv_init when it's called by
vect_update_ivs_after_vectorizer which is supposed to be guarded
by vect_can_advance_ivs_p. The patch put part codes from
vectorizable_nonlinear_induction into a new function
vect_can_peel_nonlinear_iv_p, and make vect_can_advcance_ivs_p call it.

Also this patch fix a typo in my initial patch as bellow.
-  if (!LOOP_VINFO_NITERS_KNOWN_P (loop_vinfo)
-  && induction_type == vect_step_op_mul)
   if (!INTEGRAL_TYPE_P (TREE_TYPE (vectype)))

Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
Ok for trunk?

gcc/ChangeLog:

PR tree-optimization/107055
* tree-vect-loop-manip.cc (vect_can_advance_ivs_p): Check for
nonlinear induction variables.
* tree-vect-loop.cc (vect_can_peel_nonlinear_iv_p): New
functions.
(vectorizable_nonlinear_induction): Put part codes into
vect_can_peel_nonlinear_iv_p.
* tree-vectorizer.h (vect_can_peel_nonlinear_iv_p): Declare.

gcc/testsuite/ChangeLog:

* gcc.target/i386/pr107055.c: New test.
---
 gcc/testsuite/gcc.target/i386/pr107055.c |  4 ++
 gcc/tree-vect-loop-manip.cc  | 10 +++
 gcc/tree-vect-loop.cc| 82 ++--
 gcc/tree-vectorizer.h|  3 +
 4 files changed, 64 insertions(+), 35 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/i386/pr107055.c

diff --git a/gcc/testsuite/gcc.target/i386/pr107055.c 
b/gcc/testsuite/gcc.target/i386/pr107055.c
new file mode 100644
index 000..63bcb3d742e
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr107055.c
@@ -0,0 +1,4 @@
+/* { dg-do compile } */
+/* { dg-options "-O1 -fno-tree-dce -fno-vect-cost-model -ftree-vectorize 
-fprofile-arcs" } */
+
+#include "../../gcc.dg/torture/pr24257.c"
diff --git a/gcc/tree-vect-loop-manip.cc b/gcc/tree-vect-loop-manip.cc
index 74b221a973c..1d96130c985 100644
--- a/gcc/tree-vect-loop-manip.cc
+++ b/gcc/tree-vect-loop-manip.cc
@@ -1413,6 +1413,7 @@ vect_can_advance_ivs_p (loop_vec_info loop_vinfo)
   for (gsi = gsi_start_phis (bb); !gsi_end_p (gsi); gsi_next ())
 {
   tree evolution_part;
+  enum vect_induction_op_type induction_type;
 
   gphi *phi = gsi.phi ();
   stmt_vec_info phi_info = loop_vinfo->lookup_stmt (phi);
@@ -1432,6 +1433,15 @@ vect_can_advance_ivs_p (loop_vec_info loop_vinfo)
  continue;
}
 
+  induction_type = STMT_VINFO_LOOP_PHI_EVOLUTION_TYPE (phi_info);
+  if (induction_type != vect_step_op_add)
+   {
+ if (!vect_can_peel_nonlinear_iv_p (loop_vinfo, induction_type))
+   return false;
+
+ continue;
+   }
+
   /* Analyze the evolution function.  */
 
   evolution_part = STMT_VINFO_LOOP_PHI_EVOLUTION_PART (phi_info);
diff --git a/gcc/tree-vect-loop.cc b/gcc/tree-vect-loop.cc
index aabdc6f2d81..2536cc3cf49 100644
--- a/gcc/tree-vect-loop.cc
+++ b/gcc/tree-vect-loop.cc
@@ -8558,6 +8558,50 @@ vect_update_nonlinear_iv (gimple_seq* stmts, tree 
vectype,
   return vec_def;
 
 }
+
+/* Return true if vectorizer can peel for nonlinear iv.  */
+bool
+vect_can_peel_nonlinear_iv_p (loop_vec_info loop_vinfo,
+ enum vect_induction_op_type induction_type)
+{
+  tree niters_skip;
+  /* Init_expr will be update by vect_update_ivs_after_vectorizer,
+ if niters is unkown:
+ For shift, when shift mount >= precision, there would be UD.
+ For mult, don't known how to generate
+ init_expr * pow (step, niters) for variable niters.
+ For neg, it should be ok, since niters of vectorized main loop
+ will always be multiple of 2.  */
+  if (!LOOP_VINFO_NITERS_KNOWN_P (loop_vinfo)
+  && induction_type != vect_step_op_neg)
+{
+  if (dump_enabled_p ())
+   dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,
+"Peeling for epilogue is not supported"
+" for nonlinear induction except neg"
+" when iteration count is unknown.\n");
+  return false;
+}
+
+  /* Also doens't support peel for neg when niter is variable.
+ ??? generate something like niter_expr & 1 ? init_expr : -init_expr?  */
+  niters_skip = LOOP_VINFO_MASK_SKIP_NITERS (loop_vinfo);
+  if ((niters_skip != NULL_TREE
+   && TREE_CODE (niters_skip) != INTEGER_CST)
+  || (!vect_use_loop_mask_for_alignment_p (loop_vinfo)
+ && LOOP_VINFO_PEELING_FOR_ALIGNMENT (loop_vinfo) < 0))
+{
+  if (dump_enabled_p ())
+   dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,
+"Peeling for alignement is not supported"
+" for nonlinear induction when niters_skip"
+" is not constant.\n");
+  return false;
+}
+
+  return true;
+}
+
 /* Function vectorizable_induction
 
Check if STMT_INFO performs an nonlinear induction computation that can be
@@ -8628,42 +8672,9 @@ 

[committed] libstdc++: Disable volatile-qualified std::bind for C++20

[Jonathan Wakely via Gcc-patches]

Tested powerpc64le-linux. Pushed to trunk.

-- >8 --

LWG 2487 added a precondition to std::bind for C++17, making
volatile-qualified uses undefined. We still support it, but with a
deprecated warning.

P1065R2 made it explicitly ill-formed for C++20, so we should no longer
accept it as deprecated. This implements that change.

libstdc++-v3/ChangeLog:

* doc/xml/manual/evolution.xml: Document std::bind API
changes.
* doc/xml/manual/intro.xml: Document LWG 2487 status.
* doc/xml/manual/using.xml: Clarify default value of
_GLIBCXX_USE_DEPRECATED.
* doc/html/*: Regenerate.
* include/std/functional (_Bind::operator()(Args&&...) volatile)
(_Bind::operator()(Args&&...) const volatile)
(_Bind_result::operator()(Args&&...) volatile)
(_Bind_result::operator()(Args&&...) const volatile): Replace
with deleted overload for C++20 and later.
* testsuite/20_util/bind/cv_quals.cc: Check for deprecated
warnings in C++17.
* testsuite/20_util/bind/cv_quals_2.cc: Likewise, and check for
ill-formed in C++20.
---
 libstdc++-v3/doc/html/index.html  |  2 +-
 libstdc++-v3/doc/html/manual/api.html |  5 +++
 libstdc++-v3/doc/html/manual/appendix.html|  2 +-
 .../doc/html/manual/appendix_porting.html |  2 +-
 libstdc++-v3/doc/html/manual/bugs.html|  6 
 libstdc++-v3/doc/html/manual/index.html   |  2 +-
 .../doc/html/manual/using_macros.html |  5 +--
 libstdc++-v3/doc/xml/manual/evolution.xml | 13 
 libstdc++-v3/doc/xml/manual/intro.xml |  9 ++
 libstdc++-v3/doc/xml/manual/using.xml |  5 +--
 libstdc++-v3/include/std/functional   | 32 ++-
 .../testsuite/20_util/bind/cv_quals.cc| 25 ---
 .../testsuite/20_util/bind/cv_quals_2.cc  | 12 ---
 13 files changed, 87 insertions(+), 33 deletions(-)

diff --git a/libstdc++-v3/doc/xml/manual/evolution.xml 
b/libstdc++-v3/doc/xml/manual/evolution.xml
index 4923e8c4783..82936189179 100644
--- a/libstdc++-v3/doc/xml/manual/evolution.xml
+++ b/libstdc++-v3/doc/xml/manual/evolution.xml
@@ -817,6 +817,10 @@ now defaults to zero.
   has_trivial_copy_assign removed.
 
 
+
+Calling a std::bind result as volatile was deprecated for C++17.
+
+
  Profile Mode was deprecated. 
 
 7.2
@@ -1067,4 +1071,13 @@ the process.
 
 
 
+
+12.3
+
+Calling a std::bind result as volatile is ill-formed for C++20
+and later.
+
+
+
+
 
diff --git a/libstdc++-v3/doc/xml/manual/intro.xml 
b/libstdc++-v3/doc/xml/manual/intro.xml
index d341c3efe6d..e3a03cf9d59 100644
--- a/libstdc++-v3/doc/xml/manual/intro.xml
+++ b/libstdc++-v3/doc/xml/manual/intro.xml
@@ -1163,6 +1163,15 @@ requirements of the license of GCC.
 ill-formed.
 
 
+http://www.w3.org/1999/xlink; xlink:href="#2487">2487:
+   bind() should be const-overloaded
+  not cv-overloaded
+   
+
+Deprecate volatile-qualified operator()
+for C++17, make it ill-formed for C++20.
+
+
 http://www.w3.org/1999/xlink; xlink:href="#2499">2499:
operator>>(basic_istream, CharT*) makes it 
hard to avoid buffer overflows

diff --git a/libstdc++-v3/doc/xml/manual/using.xml 
b/libstdc++-v3/doc/xml/manual/using.xml
index 0acdba6b3bd..9c444dd2997 100644
--- a/libstdc++-v3/doc/xml/manual/using.xml
+++ b/libstdc++-v3/doc/xml/manual/using.xml
@@ -1062,7 +1062,7 @@ g++ -Winvalid-pch -I. -include stdc++.h -H -g -O2 
hello.cc -o test.exe
   #define/#undef).

 
-ABI means that changing from the default value may
+ABI-changing means that changing from the default 
value may
   mean changing the ABI of compiled code. In other words,
   these choices control code which has already been compiled (i.e., in a
   binary such as libstdc++.a/.so).  If you explicitly #define or
@@ -1077,7 +1077,8 @@ g++ -Winvalid-pch -I. -include stdc++.h -H -g -O2 
hello.cc -o test.exe
 _GLIBCXX_USE_DEPRECATED
 
   
-   Defined by default. Not configurable. ABI-changing. Turning this off
+   Defined to the value 1 by default.
+   Not configurable. ABI-changing. Turning this off
removes older ARM-style iostreams code, and other anachronisms
from the API.  This macro is dependent on the version of the
standard being tracked, and as a result may give different results for
diff --git a/libstdc++-v3/include/std/functional 
b/libstdc++-v3/include/std/functional
index c4f75880fd8..5235ef20332 100644
--- a/libstdc++-v3/include/std/functional
+++ b/libstdc++-v3/include/std/functional
@@ -465,6 +465,17 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
   /// @endcond
 
+#if __cplusplus == 201703L && _GLIBCXX_USE_DEPRECATED
+# define _GLIBCXX_VOLATILE_BIND
+// _GLIBCXX_RESOLVE_LIB_DEFECTS
+// 2487. bind() should be const-overloaded, not cv-overloaded
+# define _GLIBCXX_DEPR_BIND \
+  [[deprecated("std::bind does not support volatile in C++17")]]
+#elif __cplusplus < 

[committed] libstdc++: Make INVOKE refuse to create dangling references [PR70692]

[Jonathan Wakely via Gcc-patches]

Tested powerpc64le-linux. Pushed to trunk.

-- >8 --

This is the next part of the library changes from P2255R2. This makes
INVOKE ill-formed if converting the INVOKE expression to R would bind
a reference to a temporary object.

The is_invocable_r trait is now false if the invocation would create a
dangling reference. This is done by adding the dangling check to the
__is_invocable_impl partial specialization used for INVOKE
expressions. This change also slightly simplifies the nothrow checking
recently added to that partial specialization.

This change also removes the is_invocable_r checks from the pre-C++17
implementation of std::__invoke_r, because there is no need for it to be
SFINAE-friendly. None of our C++11 and C++14 uses of INVOKE require
those constraints. The std::function constructor needs to check
is_invocable_r, but that's already done explicitly, so we don't need to
recheck when calling __is_invoke_r in std::function::operator(). The
other uses of std::__is_invoke_r do not need to be constrained and can
just be ill-formed if the INVOKE expression is ill-formed.

libstdc++-v3/ChangeLog:

PR libstdc++/70692
* include/bits/invoke.h [__cplusplus < 201703] (__invoke_r):
Remove is_invocable and is_convertible constraints.
* include/std/type_traits (__is_invocable_impl::_S_conv): Use
non-deduced context for parameter.
(__is_invocable_impl::_S_test): Remove _Check_noex template
parameter and use deduced noexcept value in its place. Add bool
parameter to detect dangling references.
(__is_invocable_impl::type): Adjust call to _S_test to avoid
deducing unnecessary noexcept property..
(__is_invocable_impl::__nothrow_type): Rename to ...
(__is_invocable_impl::__nothrow_conv): ... this. Adjust call
to _S_test to deduce noexcept property.
* testsuite/20_util/bind/dangling_ref.cc: New test.
* testsuite/20_util/function/cons/70692.cc: New test.
* testsuite/20_util/function_objects/invoke/dangling_ref.cc:
New test.
* testsuite/20_util/is_invocable/dangling_ref.cc: New test.
* testsuite/30_threads/packaged_task/cons/dangling_ref.cc:
New test.
---
 libstdc++-v3/include/bits/invoke.h| 30 ---
 libstdc++-v3/include/std/type_traits  | 27 ++---
 .../testsuite/20_util/bind/dangling_ref.cc|  9 ++
 .../testsuite/20_util/function/cons/70692.cc  | 13 
 .../function_objects/invoke/dangling_ref.cc   | 12 
 .../20_util/is_invocable/dangling_ref.cc  |  6 
 .../packaged_task/cons/dangling_ref.cc| 11 +++
 7 files changed, 80 insertions(+), 28 deletions(-)
 create mode 100644 libstdc++-v3/testsuite/20_util/bind/dangling_ref.cc
 create mode 100644 libstdc++-v3/testsuite/20_util/function/cons/70692.cc
 create mode 100644 
libstdc++-v3/testsuite/20_util/function_objects/invoke/dangling_ref.cc
 create mode 100644 libstdc++-v3/testsuite/20_util/is_invocable/dangling_ref.cc
 create mode 100644 
libstdc++-v3/testsuite/30_threads/packaged_task/cons/dangling_ref.cc

diff --git a/libstdc++-v3/include/bits/invoke.h 
b/libstdc++-v3/include/bits/invoke.h
index cdecca0e2bf..8724a764f73 100644
--- a/libstdc++-v3/include/bits/invoke.h
+++ b/libstdc++-v3/include/bits/invoke.h
@@ -115,29 +115,23 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
  std::forward<_Callable>(__fn),
  std::forward<_Args>(__args)...);
 }
-#else // C++11
-  template
-using __can_invoke_as_void = __enable_if_t<
-  __and_, __is_invocable<_Callable, _Args...>>::value,
-  _Res
->;
-
-  template
-using __can_invoke_as_nonvoid = __enable_if_t<
-  __and_<__not_>,
-is_convertible::type,
-   _Res>
-  >::value,
-  _Res
->;
+#else // C++11 or C++14
+  // This is a non-SFINAE-friendly std::invoke_r(fn, args...) for C++11/14.
+  // It's used in std::function, std::bind, and std::packaged_task. Only
+  // std::function is constrained on is_invocable_r, but that is checked on
+  // construction so doesn't need to be checked again when calling __invoke_r.
+  // Consequently, these __invoke_r overloads do not check for invocable
+  // arguments, nor check that the invoke result is convertible to R.
 
   // INVOKE: Invoke a callable object and convert the result to R.
   template
-constexpr __can_invoke_as_nonvoid<_Res, _Callable, _Args...>
+constexpr __enable_if_t::value, _Res>
 __invoke_r(_Callable&& __fn, _Args&&... __args)
 {
   using __result = __invoke_result<_Callable, _Args...>;
   using __type = typename __result::type;
+  static_assert(!__reference_converts_from_temporary(_Res, __type),
+   "INVOKE must not create a dangling reference");
   using __tag = typename __result::__invoke_type;
   return std::__invoke_impl<__type>(__tag{}, 

Re: [PATCH][_GLIBCXX_DEBUG][_GLIBCXX_INLINE_VERSION] Add missing printers

[Jonathan Wakely via Gcc-patches]

On Thu, 22 Sept 2022 at 18:06, François Dumont via Libstdc++
 wrote:
>
> Hi
>
>  This patch fix failures when _GLIBCXX_INLINE_VERSION mode and running:
>
> make check-debug RUNTESTFLAGS=prettyprinters.exp
>
>  libstdc++: [_GLIBCXX_INLINE_VERSION] Add gdb pretty print for
> _GLIBCXX_DEBUG
>
>  In _GLIBCXX_DEBUG mode containers are in std::__debug namespace but
> not template
>  parameters. In _GLIBCXX_INLINE_VERSION mode most types are in
> std::__8 namespace but
>  not std::__debug containers. We need to register specific type
> printers for this
>  combination.
>
>  libstdc++-v3/ChangeLog:
>
>  * python/libstdcxx/v6/printers.py
> (add_one_template_type_printer): Register
>  printer for types in std::__debug namespace with template
> parameters in std::__8
>  namespace.
>
> Ok to commit ?

OK, thanks.

Re: [PATCH] rs6000: Rework option -mpowerpc64 handling [PR106680]

[Iain Sandoe]

> On 29 Sep 2022, at 00:04, Iain Sandoe  wrote:
> 

> adding —with-tune=G5 to the configure line .. the cross-build then succeeded
> (at "-O1 -g" as I was building to debug) - maybe that will provide a clue, 
> but I’m
> out of time for today.

perhaps we also need a check that the m32 CPU has support for 64b insns?

so perhaps —with-cpu-32=  (or the moral equivalent) should be
required?

Iain

Re: [PATCH] rs6000: Rework option -mpowerpc64 handling [PR106680]

[Iain Sandoe]

Hi Folks,

> On 28 Sep 2022, at 22:30, Segher Boessenkool  
> wrote:

> On Wed, Sep 28, 2022 at 05:18:47PM +0100, Iain Sandoe wrote:
>>> On 28 Sep 2022, at 07:37, Iain Sandoe  wrote:
 On 28 Sep 2022, at 06:30, Kewen.Lin via Gcc-patches 
  wrote:

>> powerpc-apple-darwin, is perhaps somewhat unusual in that it is nominally a 
>> 32b kernel, but the OS supports 64b processes on suitable hardware
> 
> Just like Linux was before there was powerpc64-linux.  I think it should
> still work even?
> 
>> (and the OS does preserve the upper bits of 64b regs in the context).
> 
> That works on Linux as well.  What still does not work is user-mode
> context switches in 32-bit processes (so setjmp and getcontext stuff).

AFAIU the Darwin impl. it is the same - the user context only contains 32b
register images.

Since one can only use the feature between function calls, I guess that the
setjmp/longjmp stuff is not so critical on Darwin***. However, even being able
to use 64b insns between calls could give a massive win in allowing, for
example, lock-free 64b atomics.

Sometime, I need to spend some time with this and make a set of ppc970
library slices (the dynamic loader should pick the right arch for the resident
cpu).

>> I will try to take a look at this this evening see if I can throw
>> any more light on it.
> 
> Thanks!

adding —with-tune=G5 to the configure line .. the cross-build then succeeded
(at "-O1 -g" as I was building to debug) - maybe that will provide a clue, but 
I’m
out of time for today.

Iain.

===
*** revisiting this topic, did make me wonder about non-call exceptions tho, not
sure if they were considered in the original recipes.

Re: [PATCH] rs6000: Rework option -mpowerpc64 handling [PR106680]

[Segher Boessenkool]

On Wed, Sep 28, 2022 at 01:30:46PM +0800, Kewen.Lin wrote:
> PR106680 shows that -m32 -mpowerpc64 is different from
> -mpowerpc64 -m32, this is determined by the way how we
> handle option powerpc64 in rs6000_handle_option.
> 
> Segher pointed out this difference should be taken as
> a bug and we should ensure that option powerpc64 is
> independent of -m32/-m64.  So this patch removes the
> handlings in rs6000_handle_option and add some necessary
> supports in rs6000_option_override_internal instead.

Thanks!

> With this patch, if users specify -m{no-,}powerpc64, the
> specified value is honoured, otherwise, for 64bit it
> always enables OPTION_MASK_POWERPC64 while for 32bit
> it disables OPTION_MASK_POWERPC64 if OS_MISSING_POWERPC64.

If the user says -m64 -mno-powerpc64 it should error, and perhaps -m32
-mpowerpc64 should warn if OS_MISSING_POWERPC64?

> -  /* Some OSs don't support saving the high part of 64-bit registers on 
> context
> - switch.  Other OSs don't support saving Altivec registers.  On those 
> OSs,
> - we don't touch the OPTION_MASK_POWERPC64 or OPTION_MASK_ALTIVEC 
> settings;
> - if the user wants either, the user must explicitly specify them and we
> - won't interfere with the user's specification.  */
> +  /* Some OSs don't support saving Altivec registers.  On those OSs, we don't
> + touch the OPTION_MASK_POWERPC64 or OPTION_MASK_ALTIVEC settings; if the
> + user wants either, the user must explicitly specify them and we won't
> + interfere with the user's specification.  */
> 
>set_masks = POWERPC_MASKS;
> -#ifdef OS_MISSING_POWERPC64
> -  if (OS_MISSING_POWERPC64)
> -set_masks &= ~OPTION_MASK_POWERPC64;
> -#endif

As I said elsewhere, it probably is helpful if we still warn here for
-m32 -mpowerpc64 with OS_MISSING_POWERPC64 (or without the -m32 even,
same thing).

> +  /* With option powerpc64 specified explicitly (either on or off), even if
> + being compiled for 64 bit we don't need to check if it's disabled here,
> + since subtargets will check and raise an error message if necessary
> + later.  But without option powerpc64 specified explicitly, we need to
> + ensure powerpc64 enabled for 64 bit and disabled on those OSes with
> + OS_MISSING_POWERPC64, since they don't support saving the high part of
> + 64-bit registers on context switch.  */
> +  if (!(rs6000_isa_flags_explicit & OPTION_MASK_POWERPC64))
> +{
> +  if (TARGET_64BIT)
> + /* Make sure we always enable it by default for 64 bit.  */
> + rs6000_isa_flags |= OPTION_MASK_POWERPC64;
> +#ifdef OS_MISSING_POWERPC64
> +  else if (OS_MISSING_POWERPC64)
> + /* It's unexpected to have OPTION_MASK_POWERPC64 on for OSes which
> +miss powerpc64 support, so disable it.  */
> + rs6000_isa_flags &= ~OPTION_MASK_POWERPC64;
> +#endif
> +}

Aha.  Please don't, just warn instead?  Silently disabling such stuff is
the worst option :-(

> +/* { dg-error "'-m64' requires a PowerPC64 cpu" "PR106680" { target 
> powerpc*-*-linux* powerpc-*-rtems* } 0 } */

Everything except AIX even?  So it will include Darwin as well (and the
BSDs, and powerpc*-elf, etc.)

> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/powerpc/pr106680-4.c
> @@ -0,0 +1,16 @@
> +/* Skip this on aix, otherwise it emits the error message like "64-bit
> +   computation with 32-bit addressing not yet supported" on aix.  */
> +/* { dg-skip-if "" { powerpc*-*-aix* } } */
> +/* { dg-require-effective-target ilp32 } */
> +/* { dg-options "-mpowerpc64 -m32 -O2" } */

If you have -m32 you don't need ilp32, and the other way around.

> +/* Verify option -m32 doesn't override option -mpowerpc64.
> +   If option -mpowerpc64 gets overridden, the assembly would
> +   end up with addc and adde.  */
> +/* { dg-final { scan-assembler-not "addc" } } */
> +/* { dg-final { scan-assembler-not "adde" } } */

Lol, nice :-)

"adde" is a frequent substring, use \m \M please?  You will always get
these exact insns anyway.  And you could add a -times {\madd\M} 1 ?

 - - -

The Darwin problem might be something in darwin*.h, but I don't see it.
Maybe it is a more generic problem?


Segher

Re: [PATCH] rs6000: Rework option -mpowerpc64 handling [PR106680]

[Segher Boessenkool]

Hi!

On Wed, Sep 28, 2022 at 05:18:47PM +0100, Iain Sandoe wrote:
> > On 28 Sep 2022, at 07:37, Iain Sandoe  wrote:
> >> On 28 Sep 2022, at 06:30, Kewen.Lin via Gcc-patches 
> >>  wrote:
> >> PR106680 shows that -m32 -mpowerpc64 is different from
> >> -mpowerpc64 -m32, this is determined by the way how we
> >> handle option powerpc64 in rs6000_handle_option.
> >> 
> >> Segher pointed out this difference should be taken as
> >> a bug and we should ensure that option powerpc64 is
> >> independent of -m32/-m64.  So this patch removes the
> >> handlings in rs6000_handle_option and add some necessary
> >> supports in rs6000_option_override_internal instead.
> >> 
> >> With this patch, if users specify -m{no-,}powerpc64, the
> >> specified value is honoured, otherwise, for 64bit it
> >> always enables OPTION_MASK_POWERPC64 while for 32bit
> >> it disables OPTION_MASK_POWERPC64 if OS_MISSING_POWERPC64.

It probably shouldn't have to disable it, it can only be on if it is
explicitly enabled by the user?  So warning would be much better than
implicitly disabling it.

> Perhaps a small exposition on the target:
> 
> powerpc-apple-darwin, is perhaps somewhat unusual in that it is nominally a 
> 32b kernel, but the OS supports 64b processes on suitable hardware

Just like Linux was before there was powerpc64-linux.  I think it should
still work even?

> (and the OS does preserve the upper bits of 64b regs in the context).

That works on Linux as well.  What still does not work is user-mode
context switches in 32-bit processes (so setjmp and getcontext stuff).

> Of course, powerpc-darwin is not a blocker for anything, it should not hold 
> you up (but sometimes it
> manages to find a glitch missed elsewhere).

It is stage 1, nothing blocks nothing :-)  But indeed this looks like a
bug not specific to Darwin.  It would be nice if it was fixed before
this goes in.

> I will try to take a look at this this evening see if I can throw
> any more light on it.

Thanks!


Segher

[PATCH] c++: Remove maybe-rvalue OR in implicit move

[Marek Polacek via Gcc-patches]

This patch removes the two-stage overload resolution when performing
implicit move, whereby the compiler does two separate overload resolutions:
one treating the operand as an rvalue, and then (if that resolution fails)
another one treating the operand as an lvalue.  In the standard this was
introduced via CWG 1579 and implemented in gcc in r251035.  In r11-2412,
we disabled the fallback OR in C++20 (but not in C++17).  Then C++23 P2266
removed the fallback overload resolution, and changed the implicit move rules
once again.  So we wound up with three different behaviors.

The two overload resolutions approach was complicated and quirky, so
users should transition to the newer model.  Removing the maybe-rvalue
OR also allows us to simplify our code, for instance, now we can get
rid of LOOKUP_PREFER_RVALUE altogether.

This change means that code that previously didn't compile in C++17 will
now compile, for example:

  struct S1 { S1(S1 &&); };
  struct S2 : S1 {};

  S1
  f (S2 s)
  {
return s; // OK, derived-to-base, use S1::S1(S1&&)
  }

And conversely, code that used to work in C++17 may not compile anymore:

  struct W {
W();
  };

  struct F {
F(W&);
F(W&&) = delete;
  };

  F fn ()
  {
W w;
return w; // use w as rvalue -> use of deleted function F::F(W&&)
  }

I plan to add a note to porting_to.html.

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

gcc/cp/ChangeLog:

* call.cc (standard_conversion): Remove LOOKUP_PREFER_RVALUE code.
(reference_binding): Honor clk_implicit_rval even pre-C++20.
(implicit_conversion_1): Remove LOOKUP_PREFER_RVALUE code.
(build_user_type_conversion_1): Likewise.
(convert_like_internal): Likewise.
(build_over_call): Likewise.
* cp-tree.h (LOOKUP_PREFER_RVALUE): Remove.
(LOOKUP_NO_NARROWING): Adjust definition.
* except.cc (build_throw): Don't perform two overload resolutions.
* typeck.cc (maybe_warn_pessimizing_move): Don't use
LOOKUP_PREFER_RVALUE.
(check_return_expr): Don't perform two overload resolutions.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/Wredundant-move10.C: Adjust dg-warning.
* g++.dg/cpp0x/Wredundant-move7.C: Likewise.
* g++.dg/cpp0x/move-return2.C: Remove dg-error.
* g++.dg/cpp0x/move-return4.C: Likewise.
* g++.dg/cpp0x/ref-qual20.C: Adjust expected return value.
* g++.dg/cpp0x/move-return5.C: New test.
---
 gcc/cp/call.cc| 41 ++-
 gcc/cp/cp-tree.h  |  6 +--
 gcc/cp/except.cc  | 23 ++-
 gcc/cp/typeck.cc  | 34 +++
 .../g++.dg/cpp0x/Wredundant-move10.C  |  2 +-
 gcc/testsuite/g++.dg/cpp0x/Wredundant-move7.C |  6 +--
 gcc/testsuite/g++.dg/cpp0x/move-return2.C |  2 +-
 gcc/testsuite/g++.dg/cpp0x/move-return4.C |  2 +-
 gcc/testsuite/g++.dg/cpp0x/move-return5.C | 20 +
 gcc/testsuite/g++.dg/cpp0x/ref-qual20.C   |  2 +-
 10 files changed, 41 insertions(+), 97 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/move-return5.C

diff --git a/gcc/cp/call.cc b/gcc/cp/call.cc
index 3506b0fcfbb..e100913ea29 100644
--- a/gcc/cp/call.cc
+++ b/gcc/cp/call.cc
@@ -1272,9 +1272,6 @@ standard_conversion (tree to, tree from, tree expr, bool 
c_cast_p,
}
}
   conv = build_conv (ck_rvalue, from, conv);
-  if (flags & LOOKUP_PREFER_RVALUE)
-   /* Tell convert_like to set LOOKUP_PREFER_RVALUE.  */
-   conv->rvaluedness_matches_p = true;
   /* If we're performing copy-initialization, remember to skip
 explicit constructors.  */
   if (flags & LOOKUP_ONLYCONVERTING)
@@ -1572,9 +1569,6 @@ standard_conversion (tree to, tree from, tree expr, bool 
c_cast_p,
 type.  A temporary object is created to hold the result of
 the conversion unless we're binding directly to a reference.  */
   conv->need_temporary_p = !(flags & LOOKUP_NO_TEMP_BIND);
-  if (flags & LOOKUP_PREFER_RVALUE)
-   /* Tell convert_like to set LOOKUP_PREFER_RVALUE.  */
-   conv->rvaluedness_matches_p = true;
   /* If we're performing copy-initialization, remember to skip
 explicit constructors.  */
   if (flags & LOOKUP_ONLYCONVERTING)
@@ -1883,7 +1877,7 @@ reference_binding (tree rto, tree rfrom, tree expr, bool 
c_cast_p, int flags,
  /* Unless it's really a C++20 lvalue being treated as an xvalue.
 But in C++23, such an expression is just an xvalue, not a special
 lvalue, so the binding is once again ill-formed.  */
- && !(cxx_dialect == cxx20
+ && !(cxx_dialect <= cxx20
   && (gl_kind & clk_implicit_rval))
  && (!CP_TYPE_CONST_NON_VOLATILE_P (to)
  || (flags & LOOKUP_NO_RVAL_BIND))
@@ -2044,9 +2038,8 @@ implicit_conversion_1 (tree to, tree from, tree expr, 
bool c_cast_p,
   

[PATCH v2] btf: Add support to BTF_KIND_ENUM64 type

[Guillermo E. Martinez via Gcc-patches]

Hello GCC team,

The following is patch v2 to update BTF/CTF backend supporting
BTF_KIND_ENUM64 type. Changes from v1:

  + Fix typo in commit message.
  + Fix changelog entries.

Comments will be welcomed and appreciated!,

Kind regards,
guillermo
--

BTF supports 64-bits enumerators with following encoding:

  struct btf_type:
name_off: 0 or offset to a valid C identifier
info.kind_flag: 0 for unsigned, 1 for signed
info.kind: BTF_KIND_ENUM64
info.vlen: number of enum values
size: 1/2/4/8

The btf_type is followed by info.vlen number of:

struct btf_enum64
{
  uint32_t name_off;   /* Offset in string section of enumerator name.  */
  uint32_t val_lo32;   /* lower 32-bit value for a 64-bit value Enumerator 
*/
  uint32_t val_hi32;   /* high 32-bit value for a 64-bit value Enumerator */
};

So, a new btf_enum64 structure was added to represent BTF_KIND_ENUM64
and a new field in ctf_dtdef to represent specific type's properties, in
the particular case for CTF enums it helps to distinguish when its
enumerators values are signed or unsigned, later that information is
used to encode the BTF enum type.

gcc/ChangeLog:

* btfout.cc (btf_calc_num_vbytes): Compute enumeration size depending of
enumerator type btf_enum{,64}.
(btf_asm_type): Update btf_kflag according to enumerators sign,
using correct BPF type in BTF_KIND_ENUMi{,64}.
(btf_asm_enum_const): New argument to represent the size of
the BTF enum type.
* ctfc.cc (ctf_add_enum): Use and initialization of flag field to
CTF_ENUM_F_NONE.
(ctf_add_enumerator): New argument to represent CTF flags,
updating the comment and flag vaue according to enumerators
sing.
* ctfc.h (ctf_dmdef): Update dmd_value to HOST_WIDE_INT to allow
use 32/64 bits enumerators.
(ctf_dtdef): Add flags to to describe specific type's properties.
* dwarf2ctf.cc (gen_ctf_enumeration_type): Update flags field
depending when a signed enumerator value is found.

include/
* btf.h (btf_enum64): Add new definition and new symbolic
constant to BTF_KIND_ENUM64 and BTF_KF_ENUM_{UN,}SIGNED.

gcc/testsuite/ChangeLog:

* gcc.dg/debug/btf/btf-enum-1.c: Update testcase, with correct
info.kflags encoding.
* gcc.dg/debug/btf/btf-enum64-1.c: New testcase.
---
 gcc/btfout.cc | 24 ---
 gcc/ctfc.cc   | 14 ---
 gcc/ctfc.h|  9 +++-
 gcc/dwarf2ctf.cc  |  9 +++-
 gcc/testsuite/gcc.dg/debug/btf/btf-enum-1.c   |  2 +-
 gcc/testsuite/gcc.dg/debug/btf/btf-enum64-1.c | 41 +++
 include/btf.h | 19 +++--
 7 files changed, 99 insertions(+), 19 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/debug/btf/btf-enum64-1.c

diff --git a/gcc/btfout.cc b/gcc/btfout.cc
index 997a33fa089..4b11c867c23 100644
--- a/gcc/btfout.cc
+++ b/gcc/btfout.cc
@@ -223,7 +223,9 @@ btf_calc_num_vbytes (ctf_dtdef_ref dtd)
   break;
 
 case BTF_KIND_ENUM:
-  vlen_bytes += vlen * sizeof (struct btf_enum);
+  vlen_bytes += (dtd->dtd_data.ctti_size == 0x8)
+   ? vlen * sizeof (struct btf_enum64)
+   : vlen * sizeof (struct btf_enum);
   break;
 
 case BTF_KIND_FUNC_PROTO:
@@ -622,6 +624,15 @@ btf_asm_type (ctf_container_ref ctfc, ctf_dtdef_ref dtd)
   btf_size_type = 0;
 }
 
+ if (btf_kind == BTF_KIND_ENUM)
+   {
+ btf_kflag = (dtd->flags & CTF_ENUM_F_ENUMERATORS_SIGNED)
+   ? BTF_KF_ENUM_SIGNED
+   : BTF_KF_ENUM_UNSIGNED;
+ if (dtd->dtd_data.ctti_size == 0x8)
+   btf_kind = BTF_KIND_ENUM64;
+   }
+
   dw2_asm_output_data (4, dtd->dtd_data.ctti_name, "btt_name");
   dw2_asm_output_data (4, BTF_TYPE_INFO (btf_kind, btf_kflag, btf_vlen),
   "btt_info: kind=%u, kflag=%u, vlen=%u",
@@ -634,6 +645,7 @@ btf_asm_type (ctf_container_ref ctfc, ctf_dtdef_ref dtd)
 case BTF_KIND_UNION:
 case BTF_KIND_ENUM:
 case BTF_KIND_DATASEC:
+case BTF_KIND_ENUM64:
   dw2_asm_output_data (4, dtd->dtd_data.ctti_size, "btt_size: %uB",
   dtd->dtd_data.ctti_size);
   return;
@@ -707,13 +719,13 @@ btf_asm_sou_member (ctf_container_ref ctfc, ctf_dmdef_t * 
dmd)
 }
 }
 
-/* Asm'out an enum constant following a BTF_KIND_ENUM.  */
+/* Asm'out an enum constant following a BTF_KIND_ENUM{,64}.  */
 
 static void
-btf_asm_enum_const (ctf_dmdef_t * dmd)
+btf_asm_enum_const (unsigned int size, ctf_dmdef_t * dmd)
 {
   dw2_asm_output_data (4, dmd->dmd_name_offset, "bte_name");
-  dw2_asm_output_data (4, dmd->dmd_value, "bte_value");
+  dw2_asm_output_data (size, dmd->dmd_value, "bte_value");
 }
 
 /* Asm'out a function parameter description following a BTF_KIND_FUNC_PROTO.  
*/
@@ -871,7 +883,7 @@ 

Re: [PATCH] btf: Add support to BTF_KIND_ENUM64 type

[Guillermo E. Martinez via Gcc-patches]

On 9/28/22 13:45, David Faust wrote:

Hi Guillermo,



Hi David,


Thanks for the patch. Just a couple of small nits on the changelog
entries below but otherwise very nice, LGTM.

But, please wait a couple of days before pushing to give Indu time
to raise any objections about the changes in ctfc/dwarf2ctf.



OK. Thanks for your comments!.
 

Thanks!
David

On 8/29/22 14:11, Guillermo E. Martinez via Gcc-patches wrote:

Hello GCC team,

The following patch update BTF/CTF backend to support
BTF_KIND_ENUM64 type.

Comments will be welcomed and appreciated!,

Kind regards,
guillermo
--

BTF supports 64-bits enumerators with following encoding:

   struct btf_type:
 name_off: 0 or offset to a valid C identifier
 info.kind_flag: 0 for unsigned, 1 for signed
 info.kind: BTF_KIND_ENUM64
 info.vlen: number of enum values
 size: 1/2/4/8

The btf_type is followed by info.vlen number of:

 struct btf_enum64
 {
   uint32_t name_off;   /* Offset in string section of enumerator name.  */
   uint32_t val_lo32;   /* lower 32-bit value for a 64-bit value Enumerator 
*/
   uint32_t val_hi32;   /* high 32-bit value for a 64-bit value Enumerator 
*/
 };

So, a new btf_enum64 structure was added to represent BTF_KIND_ENUM64
and a new field in ctf_dtdef to represent specific type's properties, in
the particular case for CTF enums it helps to distinguish when its
enumerators values are signed or unsigned, later that information is
used to encode the BTF enum type.

gcc/ChangeLog:

* btfout.cc (btf_calc_num_vbytes): Compute enumeration size depending of
enumerator type btf_enum{,64}.
(btf_asm_type): Update btf_kflag according to enumerators sign,
using correct BPF type in BTF_KIND_ENUMi{,64}.
(btf_asm_enum_const): New argument to represent the size of
the BTF enum type.
* ctfc.cc (ctf_add_enum): Use and initialization of flag field to
CTF_ENUM_F_NONE.
(ctf_add_enumerator): New argument to represent CTF flags,
updating the comment and flag vaue according to enumerators
sing.
* ctfc.h (ctf_dmdef): Update dmd_value to HOST_WIDE_INT to allow
use 32/64 bits enumerators.
(ctf_dtdef): Add flags to to describe specifyc type's properties.


typo: specific



Fixed in v2.


* dwarf2ctf.cc (gen_ctf_enumeration_type): Update flags field
depending when a signed enumerator value is found.
include/btf.h (btf_enum64): Add new definition and new symbolic
constant to BTF_KIND_ENUM64 and BTF_KF_ENUM_{UN,}SIGNED.


Missing an * here for include/btf.h



Fixed in v2.



gcc/testsuite/ChangeLog:

gcc.dg/debug/btf/btf-enum-1.c: Update testcase, with correct
info.kflags encoding.
gcc.dg/debug/btf/btf-enum64-1.c: New testcase.


Likewise for these ChangeLog entries.



Fixed in v2.


You can use contrib/gcc-changelog/git_check_commit.py to check the
formatting of the entries.



Oh. thanks for mention it, really useful.


---
  gcc/btfout.cc | 24 ---
  gcc/ctfc.cc   | 14 ---
  gcc/ctfc.h|  9 +++-
  gcc/dwarf2ctf.cc  |  9 +++-
  gcc/testsuite/gcc.dg/debug/btf/btf-enum-1.c   |  2 +-
  gcc/testsuite/gcc.dg/debug/btf/btf-enum64-1.c | 41 +++
  include/btf.h | 19 +++--
  7 files changed, 99 insertions(+), 19 deletions(-)
  create mode 100644 gcc/testsuite/gcc.dg/debug/btf/btf-enum64-1.c

diff --git a/gcc/btfout.cc b/gcc/btfout.cc
index 997a33fa089..4b11c867c23 100644
--- a/gcc/btfout.cc
[...]


Regards,
guillermo

Re: [PATCH] c++ modules: ICE with class NTTP argument [PR100616]

[Nathan Sidwell via Gcc-patches]

On 9/28/22 10:42, Patrick Palka wrote:

On Tue, 27 Sep 2022, Nathan Sidwell wrote:


On 9/26/22 15:05, Patrick Palka wrote:

On Mon, 26 Sep 2022, Patrick Palka wrote:


On Mon, 26 Sep 2022, Nathan Sidwell wrote:






   return decl;
@@ -29150,9 +29151,10 @@ finish_concept_definition (cp_expr id, tree init)
   static tree
   listify (tree arg)
   {
-  tree std_init_list = get_namespace_binding (std_node,
init_list_identifier);
+  tree std_init_list = lookup_qualified_name (std_node,
init_list_identifier);
   -  if (!std_init_list || !DECL_CLASS_TEMPLATE_P (std_init_list))
+  if (std_init_list == error_mark_node
+  || !DECL_CLASS_TEMPLATE_P (std_init_list))
   {
 gcc_rich_location richloc (input_location);
 maybe_add_include_fixit (, "", false);


What do you think about this independent change to use
lookup_qualified_name instead of get_namespace_binding in listify so
that the lookup for std::initializer_list is import-aware, which seems
to fix PR102576?


Yes, that looks right to me, thanks!  (I think it'll also fix a 
potential future problem if we ever have:


namespace std {
inline namespace v2 {
template  class initializer_list {...};
}}




diff --git a/gcc/testsuite/g++.dg/modules/pr100616_a.C
b/gcc/testsuite/g++.dg/modules/pr100616_a.C
new file mode 100644
index 000..788af2eb533
--- /dev/null
+++ b/gcc/testsuite/g++.dg/modules/pr100616_a.C
@@ -0,0 +1,8 @@
+// PR c++/100616
+// { dg-additional-options "-std=c++20 -fmodules-ts" }
+// { dg-module-cmi pr100616 }
+export module pr100616;
+
+template struct C { };
+struct A { };
+C c1;
diff --git a/gcc/testsuite/g++.dg/modules/pr100616_b.C
b/gcc/testsuite/g++.dg/modules/pr100616_b.C
new file mode 100644
index 000..fc89cd08ac5
--- /dev/null
+++ b/gcc/testsuite/g++.dg/modules/pr100616_b.C
@@ -0,0 +1,8 @@
+// PR c++/100616
+// { dg-additional-options "-std=c++20 -fmodules-ts" }
+module pr100616;
+
+C c2;
+
+using type = decltype(c1);
+using type = decltype(c2);
diff --git a/gcc/testsuite/g++.dg/modules/pr102576_a.H
b/gcc/testsuite/g++.dg/modules/pr102576_a.H
new file mode 100644
index 000..87ba9b52031
--- /dev/null
+++ b/gcc/testsuite/g++.dg/modules/pr102576_a.H
@@ -0,0 +1,5 @@
+// PR c++/102576
+// { dg-additional-options -fmodule-header }
+// { dg-module-cmi {} }
+
+#include 
diff --git a/gcc/testsuite/g++.dg/modules/pr102576_b.C
b/gcc/testsuite/g++.dg/modules/pr102576_b.C
new file mode 100644
index 000..10251ed5304
--- /dev/null
+++ b/gcc/testsuite/g++.dg/modules/pr102576_b.C
@@ -0,0 +1,9 @@
+// PR c++/102576
+// { dg-additional-options -fmodules-ts }
+
+import "pr102576_a.H";
+
+int main() {
+  for (int i : {1, 2, 3})
+;
+}


--
Nathan Sidwell



--
Nathan Sidwell

c++: Add DECL_NTTP_OBJECT_P lang flag

[Nathan Sidwell via Gcc-patches]

VAR_DECLs for NTTPs need to be handled specially by module streaming,
in the same manner to type info decls.  This reworks their handling to
allow that work to drop in.  We use DECL_LANG_FLAG_5 to indicate such
decls (I didn't notice template_parm_object_p, which looks at the
mangled name -- anyway a bit flag on the node is better, IMHO).  We
break apart the creation routine, so there's now an entry point the
module machinery can use directly.

nathan
--
Nathan SidwellFrom 50888e70c984da9cd9676d3986f68222581884b3 Mon Sep 17 00:00:00 2001
From: Nathan Sidwell 
Date: Wed, 28 Sep 2022 09:20:27 -0700
Subject: [PATCH] c++: Add DECL_NTTP_OBJECT_P lang flag

VAR_DECLs for NTTPs need to be handled specially by module streaming,
in the same manner to type info decls.  This reworks their handling to
allow that work to drop in.  We use DECL_LANG_FLAG_5 to indicate such
decls (I didn't notice template_parm_object_p, which looks at the
mangled name -- anyway a bit flag on the node is better, IMHO).  We
break apart the creation routine, so there's now an entry point the
module machinery can use directly.

	gcc/cp/
	* cp-tree.h (DECL_NTTP_OBJECT_P): New.
	(template_parm_object_p): Delete.
	(build_template_parm_object): Declare.
	* cxx-pretty-print.cc (pp_cx_template_argument_list): Use DECL_NTTP_OBJECT_P.
	* error.cc (dump_simple_decl): Likewise.
	* mangle.cc (write_template_arg): Likewise.
	* pt.cc (template_parm_object_p): Delete.
	(create_template_parm_object): Separated out checking from ...
	(get_template_parm_object): ... this, new external entry point.
---
 gcc/cp/cp-tree.h   |  7 ++-
 gcc/cp/cxx-pretty-print.cc |  2 +-
 gcc/cp/error.cc|  2 +-
 gcc/cp/mangle.cc   |  2 +-
 gcc/cp/pt.cc   | 35 +--
 5 files changed, 26 insertions(+), 22 deletions(-)

diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index 19bbfbc557f..d0f1b18b015 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -518,6 +518,7 @@ extern GTY(()) tree cp_global_trees[CPTI_MAX];
   CALL_EXPR_REVERSE_ARGS (in CALL_EXPR, AGGR_INIT_EXPR)
   CONSTRUCTOR_PLACEHOLDER_BOUNDARY (in CONSTRUCTOR)
   OVL_EXPORT_P (in OVERLOAD)
+  DECL_NTTP_OBJECT_P (in VAR_DECL)
6: TYPE_MARKED_P (in _TYPE)
   DECL_NONTRIVIALLY_INITIALIZED_P (in VAR_DECL)
   RANGE_FOR_IVDEP (in RANGE_FOR_STMT)
@@ -3548,6 +3549,10 @@ struct GTY(()) lang_decl {
 #define DECL_TINFO_P(NODE)			\
   TREE_LANG_FLAG_4 (TREE_CHECK2 (NODE,VAR_DECL,TYPE_DECL))
 
+/* true iff VAR_DECL node NODE is a NTTP object decl.  */
+#define DECL_NTTP_OBJECT_P(NODE)			\
+  TREE_LANG_FLAG_5 (TREE_CHECK (NODE,VAR_DECL))
+
 /* 1 iff VAR_DECL node NODE is virtual table or VTT.  We forward to
DECL_VIRTUAL_P from the common code, as that has the semantics we
need.  But we want a more descriptive name.  */
@@ -7414,7 +7419,7 @@ extern bool alias_type_or_template_p(tree);
 enum { nt_opaque = false, nt_transparent = true };
 extern tree alias_template_specialization_p (const_tree, bool);
 extern tree dependent_alias_template_spec_p (const_tree, bool);
-extern bool template_parm_object_p		(const_tree);
+extern tree get_template_parm_object		(tree expr, tree mangle);
 extern tree tparm_object_argument		(tree);
 extern bool explicit_class_specialization_p (tree);
 extern bool push_tinst_level(tree);
diff --git a/gcc/cp/cxx-pretty-print.cc b/gcc/cp/cxx-pretty-print.cc
index e18143e39a9..bbd51bb562a 100644
--- a/gcc/cp/cxx-pretty-print.cc
+++ b/gcc/cp/cxx-pretty-print.cc
@@ -1956,7 +1956,7 @@ pp_cxx_template_argument_list (cxx_pretty_printer *pp, tree t)
 	  if (TYPE_P (arg) || (TREE_CODE (arg) == TEMPLATE_DECL
 			   && TYPE_P (DECL_TEMPLATE_RESULT (arg
 	pp->type_id (arg);
-	  else if (template_parm_object_p (arg))
+	  else if (TREE_CODE (arg) == VAR_DECL && DECL_NTTP_OBJECT_P (arg))
 	pp->expression (DECL_INITIAL (arg));
 	  else
 	pp->expression (arg);
diff --git a/gcc/cp/error.cc b/gcc/cp/error.cc
index 0389f35d731..53904e3669d 100644
--- a/gcc/cp/error.cc
+++ b/gcc/cp/error.cc
@@ -1129,7 +1129,7 @@ dump_global_iord (cxx_pretty_printer *pp, tree t)
 static void
 dump_simple_decl (cxx_pretty_printer *pp, tree t, tree type, int flags)
 {
-  if (template_parm_object_p (t))
+  if (TREE_CODE (t) == VAR_DECL && DECL_NTTP_OBJECT_P (t))
 return dump_expr (pp, DECL_INITIAL (t), flags);
 
   if (flags & TFF_DECL_SPECIFIERS)
diff --git a/gcc/cp/mangle.cc b/gcc/cp/mangle.cc
index 00d283fff8c..1a455858827 100644
--- a/gcc/cp/mangle.cc
+++ b/gcc/cp/mangle.cc
@@ -3672,7 +3672,7 @@ write_template_arg (tree node)
 	}
 }
 
-  if (template_parm_object_p (node))
+  if (TREE_CODE (node) == VAR_DECL && DECL_NTTP_OBJECT_P (node))
 /* We want to mangle the argument, not the var we stored it in.  */
 node = tparm_object_argument (node);
 
diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
index 2d83dfd6954..c7adaef997d 100644
--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ 

[PATCH] Fix gdb printers for std::string

[François Dumont via Gcc-patches]

Sometimes substitution of basic_string by one of the std::string 
typeedef fails. Here is the fix.


    libstdc++: Fix gdb pretty printers when dealing with std::string

    Since revision 33b43b0d8cd2de722d177ef823930500948a7487 std::string 
and other
    similar typedef are ambiguous from a gdb point of view because it 
matches both
    std::basic_string and std::__cxx11::basic_string 
symbols. For those
    typedef add a workaround to accept the substitution as long as the 
same regardless

    of __cxx11 namespace.

    Also avoid to register printers for types in std::__cxx11::__8:: 
namespace, there is

    no such symbols.

    libstdc++-v3/ChangeLog:

    * libstdc++-v3/python/libstdcxx/v6/printers.py 
(Printer.add_version): Do not add

    version namespace for __cxx11 symbols.
    (add_one_template_type_printer): Likewise.
    (add_one_type_printer): Likewise.
    (FilteringTypePrinter._recognizer.recognize): Add a 
workaround for std::string & al
    ambiguous typedef matching both std:: and std::__cxx11:: 
symbols.
    (register_type_printers): Refine type registration to limit 
false positive in
    FilteringTypePrinter._recognize.recognize requiring to look 
for the type in gdb.
    * libstdc++-v3/testsuite/libstdc++-prettyprinters/cxx17.cc: 
Remove obsolete

    \#define _GLIBCXX_USE_CXX11_ABI 0.
    * 
libstdc++-v3/testsuite/libstdc++-prettyprinters/simple.cc: Likewise.
    * 
libstdc++-v3/testsuite/libstdc++-prettyprinters/simple11.cc: Likewise.
    * 
libstdc++-v3/testsuite/libstdc++-prettyprinters/whatis.cc: Likewise.
    * libstdc++-v3/testsuite/libstdc++-prettyprinters/80276.cc: 
Likewise and remove

    xfail for c++20 and debug mode.
    * 
libstdc++-v3/testsuite/libstdc++-prettyprinters/libfundts.cc: Likewise.


Tested under x86_64 linux w/o _GLIBCXX_INLINE_VERSION and w/o 
_GLIBCXX_DEBUG.


I also tested it with my patch to use cxx11 abi in 
_GLIBCXX_INLINE_VERSION mode.


Ok to commit ?

François
diff --git a/libstdc++-v3/python/libstdcxx/v6/printers.py b/libstdc++-v3/python/libstdcxx/v6/printers.py
index 245b6e3dbcd..b4878b93bb2 100644
--- a/libstdc++-v3/python/libstdcxx/v6/printers.py
+++ b/libstdc++-v3/python/libstdcxx/v6/printers.py
@@ -1857,7 +1857,7 @@ class Printer(object):
 # Add a name using _GLIBCXX_BEGIN_NAMESPACE_VERSION.
 def add_version(self, base, name, function):
 self.add(base + name, function)
-if _versioned_namespace:
+if _versioned_namespace and not '__cxx11' in base:
 vbase = re.sub('^(std|__gnu_cxx)::', r'\g<0>%s' % _versioned_namespace, base)
 self.add(vbase + name, function)
 
@@ -2026,7 +2026,7 @@ def add_one_template_type_printer(obj, name, defargs):
 printer = TemplateTypePrinter('std::__debug::'+name, defargs)
 gdb.types.register_type_printer(obj, printer)
 
-if _versioned_namespace:
+if _versioned_namespace and not '__cxx11' in name:
 # Add second type printer for same type in versioned namespace:
 ns = 'std::' + _versioned_namespace
 # PR 86112 Cannot use dict comprehension here:
@@ -2084,6 +2084,21 @@ class FilteringTypePrinter(object):
 pass
 if self.type_obj == type_obj:
 return strip_inline_namespaces(self.name)
+
+if self.type_obj is None:
+return None
+
+# Workaround ambiguous typedefs matching both std:: and std::__cxx11:: symbols.
+ambiguous = False
+for ch in ('', 'w', 'u8', 'u16', 'u32'):
+if self.name == 'std::' + ch + 'string':
+ambiguous = True
+break
+
+if ambiguous:
+if self.type_obj.tag.replace('__cxx11::', '') == type_obj.tag.replace('__cxx11::', ''):
+return strip_inline_namespaces(self.name)
+
 return None
 
 def instantiate(self):
@@ -2093,7 +2108,7 @@ class FilteringTypePrinter(object):
 def add_one_type_printer(obj, match, name):
 printer = FilteringTypePrinter('std::' + match, 'std::' + name)
 gdb.types.register_type_printer(obj, printer)
-if _versioned_namespace:
+if _versioned_namespace and not '__cxx11' in match:
 ns = 'std::' + _versioned_namespace
 printer = FilteringTypePrinter(ns + match, ns + name)
 gdb.types.register_type_printer(obj, printer)
@@ -2105,29 +2120,26 @@ def register_type_printers(obj):
 return
 
 # Add type printers for typedefs std::string, std::wstring etc.
-for ch in ('', 'w', 'u8', 'u16', 'u32'):
-add_one_type_printer(obj, 'basic_string', ch + 'string')
-add_one_type_printer(obj, '__cxx11::basic_string', ch + 'string')
-# Typedefs for __cxx11::basic_string used to be in namespace __cxx11:
-add_one_type_printer(obj, '__cxx11::basic_string',
-   

Re: [PATCH] support -gz=zstd for both linker and assembler

[Richard Biener via Gcc-patches]

On Tue, Sep 27, 2022 at 3:54 PM Martin Liška  wrote:
>
> PING^1

OK

Thanks,
Richard.

> On 9/22/22 14:51, Martin Liška wrote:
> > Hi.
> >
> > Tested with Fangrui's patch set sent to binutils ML and mold linker.
> >
> > $ gcc -g -gz=zstd a.c --save-temps --verbose 2>&1 | grep debug-sections
> >  /home/marxin/Programming/binutils/objdir/gas/as-new -v --gdwarf-5 
> > --compress-debug-sections=zstd --64 -o a.o a.s
> >  /home/marxin/bin/gcc/libexec/gcc/x86_64-pc-linux-gnu/13.0.0/collect2 
> > -plugin 
> > /home/marxin/bin/gcc/libexec/gcc/x86_64-pc-linux-gnu/13.0.0/liblto_plugin.so
> >  
> > -plugin-opt=/home/marxin/bin/gcc/libexec/gcc/x86_64-pc-linux-gnu/13.0.0/lto-wrapper
> >  -plugin-opt=-fresolution=a.res -plugin-opt=-pass-through=-lgcc 
> > -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc 
> > -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s 
> > --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 
> > --compress-debug-sections=zstd /lib/../lib64/crt1.o /lib/../lib64/crti.o 
> > /home/marxin/bin/gcc/lib64/gcc/x86_64-pc-linux-gnu/13.0.0/crtbegin.o 
> > -L/home/marxin/bin/gcc/lib64/gcc/x86_64-pc-linux-gnu/13.0.0 
> > -L/home/marxin/bin/gcc/lib64/gcc/x86_64-pc-linux-gnu/13.0.0/../../../../lib64
> >  -L/lib/../lib64 -L/usr/lib/../lib64 
> > -L/home/marxin/bin/gcc/lib64/gcc/x86_64-pc-linux-gnu/13.0.0/../../.. a.o 
> > -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s 
> > --no-as-needed 
> > /home/marxin/bin/gcc/lib64/gcc/x86_64-pc-linux-gnu/13.0.0/crtend.o 
> > /lib/../lib64/crtn.o
> >
> > $ gdb a.out
> > ...
> > BFD: /home/marxin/Programming/testcases/a.out: unable to initialize 
> > decompress status for section .debug_abbrev
> > BFD: /home/marxin/Programming/testcases/a.out: unable to initialize 
> > decompress status for section .debug_abbrev
> > "/home/marxin/Programming/testcases/a.out": not in executable format: file 
> > format not recognized
> >
> > So it's really compressed with zstd. I'm going to write ChangeLog entry for 
> > zlib-gnu once this gets merged as well.
> >
> > Ready to be installed?
> > Thanks,
> > Martin
> >
> >   PR driver/106897
> >
> > gcc/ChangeLog:
> >
> >   * common.opt: Add -gz=zstd value.
> >   * configure.ac: Detect --compress-debug-sections=zstd
> >   for both linker and assembler.
> >   * configure: Regenerate.
> >   * gcc.cc (LINK_COMPRESS_DEBUG_SPEC): Handle -gz=zstd.
> >   (ASM_COMPRESS_DEBUG_SPEC): Likewise.
> > ---
> >  gcc/common.opt   |  5 -
> >  gcc/configure| 11 +--
> >  gcc/configure.ac | 11 +--
> >  gcc/gcc.cc   | 15 +++
> >  4 files changed, 37 insertions(+), 5 deletions(-)
> >
> > diff --git a/gcc/common.opt b/gcc/common.opt
> > index 06ef768ab78..68370db816b 100644
> > --- a/gcc/common.opt
> > +++ b/gcc/common.opt
> > @@ -3419,7 +3419,10 @@ EnumValue
> >  Enum(compressed_debug_sections) String(zlib) Value(1)
> >
> >  EnumValue
> > -Enum(compressed_debug_sections) String(zlib-gnu) Value(2)
> > +Enum(compressed_debug_sections) String(zstd) Value(2)
> > +
> > +EnumValue
> > +Enum(compressed_debug_sections) String(zlib-gnu) Value(3)
> >
> >  gz
> >  Common Driver
> > diff --git a/gcc/configure b/gcc/configure
> > index 70a013e9a30..ce4e1859e1f 100755
> > --- a/gcc/configure
> > +++ b/gcc/configure
> > @@ -29727,13 +29727,16 @@ else
> > if $gcc_cv_as --compress-debug-sections -o conftest.o conftest.s 2>&1 | 
> > grep -i warning > /dev/null
> > then
> >   gcc_cv_as_compress_debug=0
> > -   # Since binutils 2.26, gas supports --compress-debug-sections=zlib,
> > -   # defaulting to the ELF gABI format.
> > elif $gcc_cv_as --compress-debug-sections=zlib -o conftest.o conftest.s 
> > > /dev/null 2>&1
> > then
> >   gcc_cv_as_compress_debug=1
> >   gcc_cv_as_compress_debug_option="--compress-debug-sections"
> >   gcc_cv_as_no_compress_debug_option="--nocompress-debug-sections"
> > + # Since binutils 2.40, gas supports --compress-debug-sections=zstd.
> > + if $gcc_cv_as --compress-debug-sections=zstd -o conftest.o conftest.s 
> > > /dev/null 2>&1
> > + then
> > +   gcc_cv_as_compress_debug=2
> > + fi
> > else
> >   gcc_cv_as_compress_debug=0
> > fi
> > @@ -30251,6 +30254,10 @@ $as_echo_n "checking linker for compressed debug 
> > sections... " >&6; }
> >  if $gcc_cv_ld --help 2>&1 | grep -- 
> > '--compress-debug-sections.*\' > /dev/null; then
> >  gcc_cv_ld_compress_debug=1
> >  gcc_cv_ld_compress_debug_option="--compress-debug-sections"
> > +# Detect zstd debug section compression support
> > +if $gcc_cv_ld --help 2>&1 | grep -- 
> > '--compress-debug-sections.*\' > /dev/null; then
> > +  gcc_cv_ld_compress_debug=2
> > +fi
> >  else
> >case "${target}" in
> >  *-*-solaris2*)
> > diff --git a/gcc/configure.ac b/gcc/configure.ac
> > index 96e10d7c194..b6bafa8b7d6 100644
> > --- a/gcc/configure.ac
> > +++ b/gcc/configure.ac
> > @@ 

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

[Qing Zhao via Gcc-patches]

Hi, Martin,

Thanks for the comments. And sorry for my late reply till now (I just came back 
home from LPC, GNU Cauldron and then a one-week vacation after that…)

> On Sep 12, 2022, at 12:42 PM, Martin Sebor  wrote:
> 
> 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.
Yes, I agree.

>  (I think qualifying the sentence
> by adding "for the purposes of accessing the elements of such arrays"
> might be one way to do it).

How about:

'-fstrict-flex-arrays’
 Treat the trailing array of a structure as a variable-length array
  in a stricter way.
?

> 
>> The positive form is equivalent to
>>  '-fstrict-flex-arrays=3', which is the strictest.  A trailing array
>>  is treated as a flexible array member only when it is declared as a
>>  flexible array member per C99 standard onwards.  The negative form
>>  is equivalent to '-fstrict-flex-arrays=0', which is the least
>>  strict.  All trailing arrays of structures are treated as flexible
>>  array members.
>> '-fstrict-flex-arrays=LEVEL'
>>  Treat the trailing array of a structure as a flexible array member
>>  in a stricter way.  The value of LEVEL controls the level of
>>  strictness.
>>  The possible values of LEVEL are the same as for the
>>  'strict_flex_arrays' attribute (*note Variable Attributes::).
>>  You can control this behavior for a specific trailing array field
>>  of a structure by using the variable attribute 'strict_flex_arrays'
>>  attribute (*note Variable Attributes::).
>> 'strict_flex_arrays (LEVEL)'
>>  The 'strict_flex_arrays' attribute should be attached to the
>>  trailing array field of a structure.  It specifies the level of
>>  strictness of treating the trailing array field of a structure as a
>>  flexible array member.  LEVEL must be an integer betwen 0 to 3.
> 
> 
> 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').

Will make the change as you suggested.

Thanks.

Qing
> 
> 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 

Re: [PATCH] rs6000: Rework option -mpowerpc64 handling [PR106680]

[Iain Sandoe]

Hi Kewen

> On 28 Sep 2022, at 17:18, Iain Sandoe  wrote:
> 
> (reduced CC list, if folks want to be re-included .. please add them back).
> 
>> On 28 Sep 2022, at 07:37, Iain Sandoe  wrote:
> 
>>> On 28 Sep 2022, at 06:30, Kewen.Lin via Gcc-patches 
>>>  wrote:
>> 
>>> PR106680 shows that -m32 -mpowerpc64 is different from
>>> -mpowerpc64 -m32, this is determined by the way how we
>>> handle option powerpc64 in rs6000_handle_option.
>>> 
>>> Segher pointed out this difference should be taken as
>>> a bug and we should ensure that option powerpc64 is
>>> independent of -m32/-m64.  So this patch removes the
>>> handlings in rs6000_handle_option and add some necessary
>>> supports in rs6000_option_override_internal instead.
>>> 
>>> With this patch, if users specify -m{no-,}powerpc64, the
>>> specified value is honoured, otherwise, for 64bit it
>>> always enables OPTION_MASK_POWERPC64 while for 32bit
>>> it disables OPTION_MASK_POWERPC64 if OS_MISSING_POWERPC64.
>>> 
>>> Bootstrapped and regress-tested on:
>>> - powerpc64-linux-gnu P7 and P8 {-m64,-m32}
>>> - powerpc64le-linux-gnu P9 and P10
>>> - powerpc-ibm-aix7.2.0.0 {-maix64,-maix32}
>>> 
>>> Hi Iain, could you help to test this on darwin to ensure
>>> it won't break darwin's build and new tests are fine?
>>> Thanks in advance!
>> 
>> Will do, it will take a day or so, thanks,
> 
> Perhaps a small exposition on the target:
> 
> powerpc-apple-darwin, is perhaps somewhat unusual in that it is nominally a 
> 32b kernel, but the OS supports 64b processes on suitable hardware (and the 
> OS does preserve the upper bits of 64b regs in the context).
> 
> -
> 
> I bootstrapped (all supported languages) and tested r13-2892 yesterday with 
> “nominal” results.
> 
> Then I added this patch .. and did a clean bootstrap (same configuration).
> 
> the bootstrap fails on the stage3 libgomp (building the ppc64 multilib) with 
> the error below
> What is somewhat odd here is that libgomp is bootstrapped with the compiler 
> and, apparently,
> openacc-init.c built OK at stage2.
> 
> ——
> 
> Of course, powerpc-darwin is not a blocker for anything, it should not hold 
> you up (but sometimes it
> manages to find a glitch missed elsewhere).  I will try to take a look at 
> this this evening see if I can throw
> any more light on it.
> 
> --
> 
> /src-local/gcc-master/libgomp/oacc-init.c:876:1: internal compiler error: 
> ‘global_options’ are modified in local context
>  876 | {
>  | ^
> 0xe940d7 cl_optimization_compare(gcc_options*, gcc_options*)
>/scratch/10-5-leo/gcc-master/gcc/options-save.cc:14082

This repeats on a cross from x86_64-darwin to powerpc-darwin .. (makes debug a 
bit quicker)

this is the failing case - which does not (immediately) seem directly connected 
.. does it ring
any bells for you?

   16649  if (ptr1->x_rs6000_sched_restricted_insns_priority != 
ptr2->x_rs6000_sched_restricted_insns_priority)
-> 16650internal_error ("% are modified in local 
context”);



> 0x15f8fb handle_optimize_attribute
>/src-local/gcc-master/gcc/c-family/c-attribs.cc:5619
> 0x8447 decl_attributes(tree_node**, tree_node*, int, tree_node*)
>/src-local/gcc-master/gcc/attribs.cc:875
> 0x307bb start_function(c_declspecs*, c_declarator*, tree_node*)
>/src-local/gcc-master/gcc/c/c-decl.cc:9537
> 0xb4f27 c_parser_declaration_or_fndef
>/src-local/gcc-master/gcc/c/c-parser.cc:2466
> 0xc164f c_parser_external_declaration
>/src-local/gcc-master/gcc/c/c-parser.cc:1800
> 0xc2323 c_parser_translation_unit
>/src-local/gcc-master/gcc/c/c-parser.cc:1666
> 0xc2323 c_parse_file()
>???:0
> 0x13a5db c_common_parse_file()
>/src-local/gcc-master/gcc/c-family/c-opts.cc:1255
> 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.
> 

Re: [PATCH 1/2] c++: introduce TRAIT_TYPE alongside TRAIT_EXPR

[Jason Merrill via Gcc-patches]

On 9/28/22 12:36, Patrick Palka wrote:

On Tue, 27 Sep 2022, Jason Merrill wrote:


On 9/27/22 15:50, Patrick Palka wrote:

We already have generic support for predicate-like traits that yield a
boolean via TRAIT_EXPR, but we lack the same support for transform-like
traits that yield a type.  Such support would be useful for implementing
efficient built-ins for std::decay and std::remove_cvref and other
conceptually simple type traits that are otherwise relatively expensive
to implement.

This patch implements a generic TRAIT_TYPE type and replaces the
existing hardcoded UNDERLYING_TYPE type to use TRAIT_TYPE instead.


Sounds good, perhaps we also want to convert BASES to e.g. TRAIT_TYPE_PACK at
some point...


*nod*




gcc/cp/ChangeLog:

* cp-objcp-common.cc (cp_common_init_ts): Replace
UNDERLYING_TYPE with TRAIT_TYPE.
* cp-tree.def (TRAIT_TYPE): Define.
(UNDERLYING_TYPE): Remove.
* cp-tree.h (TRAIT_TYPE_KIND_RAW): Define.
(TRAIT_TYPE_KIND): Define.
(TRAIT_TYPE_TYPE1): Define.
(TRAIT_TYPE_TYPE2): Define.
(WILDCARD_TYPE_P): Return true for TRAIT_TYPE.
(finish_trait_type): Declare.
* cxx-pretty-print.cc (cxx_pretty_printer::primary_expression):
Adjust after renaming pp_cxx_trait_expression.
(cxx_pretty_printer::type_id): Replace UNDERLYING_TYPE with
TRAIT_TYPE.
(pp_cxx_trait_expression): Rename to ...
(pp_cxx_trait): ... this.  Handle TRAIT_TYPE as well.  Correct
pretty printing of the trailing arguments.
* cxx-pretty-print.h (pp_cxx_trait_expression): Rename to ...
(pp_cxx_trait_type): ... this.
* error.cc (dump_type) : Remove.
: New.
(dump_type_prefix): Replace UNDERLYING_WITH with TRAIT_TYPE.
(dump_type_suffix): Likewise.
* mangle.cc (write_type) : Remove.
: New.
* module.cc (trees_out::type_node) :
Remove.
: New.
(trees_in::tree_node): Likewise.
* parser.cc (cp_parser_primary_expression): Adjust after
renaming cp_parser_trait_expr.
(cp_parser_trait_expr): Rename to ...
(cp_parser_trait): ... this.  Call finish_trait_type for traits
that yield a type.
(cp_parser_simple_type_specifier): Adjust after renaming
cp_parser_trait_expr.
* pt.cc (for_each_template_parm_r) :
Remove.
: New.
(tsubst): Likewise.
(unify): Replace UNDERLYING_TYPE with TRAIT_TYPE.
(dependent_type_p_r): Likewise.
* semantics.cc (finish_underlying_type): Don't return
UNDERLYING_TYPE anymore when processing_template_decl.
(finish_trait_type): Define.
* tree.cc (strip_typedefs) : Remove.
: New.
(cp_walk_subtrees): Likewise.
* typeck.cc (structural_comptypes): Likewise.

gcc/testsuite/ChangeLog:

* g++.dg/ext/underlying_type7.C: Adjust expected error message.
---
   gcc/cp/cp-objcp-common.cc   |  2 +-
   gcc/cp/cp-tree.def  |  9 ++--
   gcc/cp/cp-tree.h| 18 
   gcc/cp/cxx-pretty-print.cc  | 49 ++---
   gcc/cp/cxx-pretty-print.h   |  2 +-
   gcc/cp/error.cc | 14 +++---
   gcc/cp/mangle.cc|  5 ++-
   gcc/cp/module.cc| 24 +-
   gcc/cp/parser.cc| 24 +-
   gcc/cp/pt.cc| 26 +++
   gcc/cp/semantics.cc | 41 -
   gcc/cp/tree.cc  | 22 ++---
   gcc/cp/typeck.cc|  7 ++-
   gcc/testsuite/g++.dg/cpp0x/alias-decl-59.C  |  4 +-
   gcc/testsuite/g++.dg/ext/underlying_type7.C |  2 +-
   15 files changed, 171 insertions(+), 78 deletions(-)

diff --git a/gcc/cp/cp-objcp-common.cc b/gcc/cp/cp-objcp-common.cc
index 64975699351..380f288a7f1 100644
--- a/gcc/cp/cp-objcp-common.cc
+++ b/gcc/cp/cp-objcp-common.cc
@@ -518,7 +518,7 @@ cp_common_init_ts (void)
 MARK_TS_TYPE_NON_COMMON (DECLTYPE_TYPE);
 MARK_TS_TYPE_NON_COMMON (TYPENAME_TYPE);
 MARK_TS_TYPE_NON_COMMON (TYPEOF_TYPE);
-  MARK_TS_TYPE_NON_COMMON (UNDERLYING_TYPE);
+  MARK_TS_TYPE_NON_COMMON (TRAIT_TYPE);
 MARK_TS_TYPE_NON_COMMON (BOUND_TEMPLATE_TEMPLATE_PARM);
 MARK_TS_TYPE_NON_COMMON (TEMPLATE_TEMPLATE_PARM);
 MARK_TS_TYPE_NON_COMMON (TEMPLATE_TYPE_PARM);
diff --git a/gcc/cp/cp-tree.def b/gcc/cp/cp-tree.def
index f9cbd339f19..f83b4c54d43 100644
--- a/gcc/cp/cp-tree.def
+++ b/gcc/cp/cp-tree.def
@@ -444,9 +444,12 @@ DEFTREECODE (BIT_CAST_EXPR, "bit_cast_expr",
tcc_expression, 1)
 /** C++ extensions. */
   -/* Represents a trait expression during template expansion.  */
+/* Represents a templated trait that yields an expression.  */
   DEFTREECODE (TRAIT_EXPR, "trait_expr", tcc_exceptional, 0)
   +/* 

Re: [PATCH] btf: Add support to BTF_KIND_ENUM64 type

[David Faust via Gcc-patches]

Hi Guillermo,

Thanks for the patch. Just a couple of small nits on the changelog
entries below but otherwise very nice, LGTM.

But, please wait a couple of days before pushing to give Indu time
to raise any objections about the changes in ctfc/dwarf2ctf.

Thanks!
David

On 8/29/22 14:11, Guillermo E. Martinez via Gcc-patches wrote:
> Hello GCC team,
> 
> The following patch update BTF/CTF backend to support
> BTF_KIND_ENUM64 type.
> 
> Comments will be welcomed and appreciated!,
> 
> Kind regards,
> guillermo
> --
> 
> BTF supports 64-bits enumerators with following encoding:
> 
>   struct btf_type:
> name_off: 0 or offset to a valid C identifier
> info.kind_flag: 0 for unsigned, 1 for signed
> info.kind: BTF_KIND_ENUM64
> info.vlen: number of enum values
> size: 1/2/4/8
> 
> The btf_type is followed by info.vlen number of:
> 
> struct btf_enum64
> {
>   uint32_t name_off;   /* Offset in string section of enumerator name.  */
>   uint32_t val_lo32;   /* lower 32-bit value for a 64-bit value 
> Enumerator */
>   uint32_t val_hi32;   /* high 32-bit value for a 64-bit value Enumerator 
> */
> };
> 
> So, a new btf_enum64 structure was added to represent BTF_KIND_ENUM64
> and a new field in ctf_dtdef to represent specific type's properties, in
> the particular case for CTF enums it helps to distinguish when its
> enumerators values are signed or unsigned, later that information is
> used to encode the BTF enum type.
> 
> gcc/ChangeLog:
> 
>   * btfout.cc (btf_calc_num_vbytes): Compute enumeration size depending of
>   enumerator type btf_enum{,64}.
>   (btf_asm_type): Update btf_kflag according to enumerators sign,
>   using correct BPF type in BTF_KIND_ENUMi{,64}.
>   (btf_asm_enum_const): New argument to represent the size of
>   the BTF enum type.
>   * ctfc.cc (ctf_add_enum): Use and initialization of flag field to
>   CTF_ENUM_F_NONE.
>   (ctf_add_enumerator): New argument to represent CTF flags,
>   updating the comment and flag vaue according to enumerators
>   sing.
>   * ctfc.h (ctf_dmdef): Update dmd_value to HOST_WIDE_INT to allow
>   use 32/64 bits enumerators.
>   (ctf_dtdef): Add flags to to describe specifyc type's properties.

typo: specific

>   * dwarf2ctf.cc (gen_ctf_enumeration_type): Update flags field
>   depending when a signed enumerator value is found.
>   include/btf.h (btf_enum64): Add new definition and new symbolic
>   constant to BTF_KIND_ENUM64 and BTF_KF_ENUM_{UN,}SIGNED.

Missing an * here for include/btf.h

> 
> gcc/testsuite/ChangeLog:
> 
>   gcc.dg/debug/btf/btf-enum-1.c: Update testcase, with correct
>   info.kflags encoding.
>   gcc.dg/debug/btf/btf-enum64-1.c: New testcase.

Likewise for these ChangeLog entries.

You can use contrib/gcc-changelog/git_check_commit.py to check the
formatting of the entries.

> ---
>  gcc/btfout.cc | 24 ---
>  gcc/ctfc.cc   | 14 ---
>  gcc/ctfc.h|  9 +++-
>  gcc/dwarf2ctf.cc  |  9 +++-
>  gcc/testsuite/gcc.dg/debug/btf/btf-enum-1.c   |  2 +-
>  gcc/testsuite/gcc.dg/debug/btf/btf-enum64-1.c | 41 +++
>  include/btf.h | 19 +++--
>  7 files changed, 99 insertions(+), 19 deletions(-)
>  create mode 100644 gcc/testsuite/gcc.dg/debug/btf/btf-enum64-1.c
> 
> diff --git a/gcc/btfout.cc b/gcc/btfout.cc
> index 997a33fa089..4b11c867c23 100644
> --- a/gcc/btfout.cc
> +++ b/gcc/btfout.cc
> @@ -223,7 +223,9 @@ btf_calc_num_vbytes (ctf_dtdef_ref dtd)
>break;
>  
>  case BTF_KIND_ENUM:
> -  vlen_bytes += vlen * sizeof (struct btf_enum);
> +  vlen_bytes += (dtd->dtd_data.ctti_size == 0x8)
> + ? vlen * sizeof (struct btf_enum64)
> + : vlen * sizeof (struct btf_enum);
>break;
>  
>  case BTF_KIND_FUNC_PROTO:
> @@ -622,6 +624,15 @@ btf_asm_type (ctf_container_ref ctfc, ctf_dtdef_ref dtd)
>btf_size_type = 0;
>  }
>  
> + if (btf_kind == BTF_KIND_ENUM)
> +   {
> + btf_kflag = (dtd->flags & CTF_ENUM_F_ENUMERATORS_SIGNED)
> + ? BTF_KF_ENUM_SIGNED
> + : BTF_KF_ENUM_UNSIGNED;
> + if (dtd->dtd_data.ctti_size == 0x8)
> +   btf_kind = BTF_KIND_ENUM64;
> +   }
> +
>dw2_asm_output_data (4, dtd->dtd_data.ctti_name, "btt_name");
>dw2_asm_output_data (4, BTF_TYPE_INFO (btf_kind, btf_kflag, btf_vlen),
>  "btt_info: kind=%u, kflag=%u, vlen=%u",
> @@ -634,6 +645,7 @@ btf_asm_type (ctf_container_ref ctfc, ctf_dtdef_ref dtd)
>  case BTF_KIND_UNION:
>  case BTF_KIND_ENUM:
>  case BTF_KIND_DATASEC:
> +case BTF_KIND_ENUM64:
>dw2_asm_output_data (4, dtd->dtd_data.ctti_size, "btt_size: %uB",
>  dtd->dtd_data.ctti_size);
>return;
> @@ -707,13 +719,13 @@ 

[PATCH] fixincludes: Fix up powerpc floatn.h tweaks [PR107059]

[Jakub Jelinek via Gcc-patches]

Hi!

On Wed, Sep 28, 2022 at 12:23:31AM +, Joseph Myers wrote:
> In general the changes match those made by fixincludes, though I think
> the ones in sysdeps/powerpc/bits/floatn.h, where the header tests
> __LDBL_MANT_DIG__ == 113 or uses #elif, wouldn't match the existing
> fixincludes patterns.

You're right, missed that.
The header has:
/* Defined to a complex binary128 type if __HAVE_FLOAT128 is 1.  */
# if __HAVE_FLOAT128
#  if __LDBL_MANT_DIG__ == 113 && defined __cplusplus
typedef long double _Float128;
#   define __CFLOAT128 _Complex long double
#  elif !__GNUC_PREREQ (7, 0) || defined __cplusplus
/* The type _Float128 exist for powerpc only since GCC 7.0.  */
typedef __float128 _Float128;
/* Add a typedef for older GCC and C++ compilers which don't natively support
   _Complex _Float128.  */
typedef _Complex float __cfloat128 __attribute__ ((__mode__ (__KC__)));
#   define __CFLOAT128 __cfloat128
#  else
#   define __CFLOAT128 _Complex _Float128
#  endif
# endif
and my current rules don't do anything about that.

The following patch fixes that.

I've run additionally
MACRO_LIST=`pwd`/../gcc/macro_list TARGET_MACHINE=x86_64-pc-linux-gnu 
../fixincludes/fixinc.sh /tmp/include-fixed `echo /usr/src/libc | sed -e :a -e 
's,[^/]*/\.\.\/,,' -e ta`
in the builddir/fixincludes directory where /usr/src/libc is latest glibc
trunk checkout and seems the remaining defined __cplusplus cases in the floatn.h
and floatn-common.h headers are ok or acceptable.
The remaining cases are:
#if __GNUC_PREREQ (7, 0) && !defined __cplusplus
# define __HAVE_FLOATN_NOT_TYPEDEF 1
#else
# define __HAVE_FLOATN_NOT_TYPEDEF 0
#endif
which is IMHO ok because this is only used in tgmath.h or tgmath-like math.h
stuff which is C only, as C++ doesn't have _Generic.
Another case are the following 3 snippets:
#  if !__GNUC_PREREQ (7, 0) || defined __cplusplus
#   error "_Float128X supported but no constant suffix"
#  else
#   define __f128x(x) x##f128x
#  endif
...
#  if !__GNUC_PREREQ (7, 0) || defined __cplusplus
#   error "_Float128X supported but no complex type"
#  else
#   define __CFLOAT128X _Complex _Float128x
#  endif
...
#  if !__GNUC_PREREQ (7, 0) || defined __cplusplus
#   error "_Float128x supported but no type"
#  endif
but as no target has _Float128x right now and don't see it
coming soon, it isn't a big deal (on the glibc side it is of
course ok to adjust those).
OT, besides floatn.h and floatn-common.h headers, the only
one remaining in /tmp/include-fixed is sysdeps/arm/unwind.h, perhaps
-#if defined(linux) || defined(__NetBSD__)
+#if defined(__linux__) || defined(__NetBSD__)
should be done in that header (and libgcc/config/arm/unwind-arm.h
too).

Ok for trunk?

BTW, we have some multi-arch related issue with fixincludes too, apparently
fixincludes never worked properly on multi-arch (aka Debian/Ubuntu) :(.

2022-09-28  Jakub Jelinek  

PR bootstrap/107059
* inclhack.def (glibc_cxx_floatn_2): Handle #elif the same as #if.
(glibc_cxx_floatn_4): New.
* fixincl.x: Regenerated.
* tests/base/bits/floatn.h: Regenerated.

--- gcc/inclhack.def.jj 2022-09-27 12:29:21.309769836 +0200
+++ gcc/inclhack.def2022-09-28 19:56:07.222783768 +0200
@@ -2060,11 +2060,11 @@ fix = {
 fix = {
 hackname  = glibc_cxx_floatn_2;
 files = bits/floatn.h, bits/floatn-common.h, "*/bits/floatn.h", 
"*/bits/floatn-common.h";
-select= "^([ \t]*#[ \t]*if !__GNUC_PREREQ \\(7, 0\\) \\|\\| )defined 
__cplusplus\n"
+select= "^([ \t]*#[ \t]*(el)?if !__GNUC_PREREQ \\(7, 0\\) \\|\\| 
)defined __cplusplus\n"
"(([ \t]*/\\*[^\n]*\\*/\n)?"
"[ \t]*typedef[ \t]+[^\n]*[ \t]+_Float(16|32|64|128)x?([ 
\t]+__attribute__ \\(\\(__mode__ \\(__HF__\\)\\)\\))?;)";
 c_fix = format;
-c_fix_arg = "%1(defined __cplusplus && !__GNUC_PREREQ (13, 0))\n%2";
+c_fix_arg = "%1(defined __cplusplus && !__GNUC_PREREQ (13, 0))\n%3";
 test_text = <<-EOT
#  if !__GNUC_PREREQ (7, 0) || defined __cplusplus
typedef float _Float16 __attribute__ ((__mode__ (__HF__)));
@@ -2072,6 +2072,10 @@ fix = {
#  if !__GNUC_PREREQ (7, 0) || defined __cplusplus
typedef __float128 _Float128;
#  endif
+   #  if 0
+   #  elif !__GNUC_PREREQ (7, 0) || defined __cplusplus
+   typedef __float128 _Float128;
+   #  endif
EOT;
 };
 
@@ -2110,6 +2114,22 @@ fix = {
#  endif
EOT;
 };
+
+fix = {
+hackname  = glibc_cxx_floatn_4;
+files = bits/floatn.h, "*/bits/floatn.h";
+select= "^([ \t]*#[ \t]*if __LDBL_MANT_DIG__ == 113 && )defined 
__cplusplus\n"
+   "(([ \t]*/\\*[^\n]*\\*/\n)?"
+   "[ \t]*typedef[ \t]+[^\n]*[ \t]+_Float128;)";
+c_fix = format;
+c_fix_arg = "%1defined __cplusplus && !__GNUC_PREREQ (13, 0)\n%2";
+test_text = <<-EOT
+   #  if __LDBL_MANT_DIG__ == 113 && defined __cplusplus
+   typedef long double _Float128;
+   #   define 

Re: [PATCH] RISC-V: Add ABI-defined RVV types.

[Kito Cheng via Gcc-patches]

Committed with few minor style tweaks :)

On Tue, Sep 27, 2022 at 5:27 PM  wrote:
>
> From: Ju-Zhe Zhong 
>
> gcc/ChangeLog:
>
> * config.gcc: Add riscv-vector-builtins.o.
> * config/riscv/riscv-builtins.cc (riscv_init_builtins): Add RVV 
> builtin function.
> * config/riscv/riscv-protos.h (riscv_v_ext_enabled_vector_mode_p): 
> New function.
> * config/riscv/riscv.cc (ENTRY): New macro.
> (riscv_v_ext_enabled_vector_mode_p): New function.
> (riscv_mangle_type): Add RVV mangle.
> (riscv_vector_mode_supported_p): Adjust RVV machine mode.
> (riscv_verify_type_context): Add context check for RVV.
> (riscv_vector_alignment): Add RVV alignment target hook support.
> (TARGET_VECTOR_MODE_SUPPORTED_P): New target hook support.
> (TARGET_VERIFY_TYPE_CONTEXT): Ditto.
> (TARGET_VECTOR_ALIGNMENT): Ditto.
> * config/riscv/t-riscv: Add riscv-vector-builtins.o
> * config/riscv/riscv-vector-builtins.cc: New file.
> * config/riscv/riscv-vector-builtins.def: New file.
> * config/riscv/riscv-vector-builtins.h: New file.
> * config/riscv/riscv-vector-switch.def: New file.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/riscv/rvv/base/abi-1.c: New test.
> * gcc.target/riscv/rvv/base/abi-2.c: New test.
> * gcc.target/riscv/rvv/base/abi-3.c: New test.
> * gcc.target/riscv/rvv/base/abi-4.c: New test.
> * gcc.target/riscv/rvv/base/abi-5.c: New test.
> * gcc.target/riscv/rvv/base/abi-6.c: New test.
> * gcc.target/riscv/rvv/base/abi-7.c: New test.
> * gcc.target/riscv/rvv/rvv.exp: New test.
>
> ---
>  gcc/config.gcc|   1 +
>  gcc/config/riscv/riscv-builtins.cc|   2 +
>  gcc/config/riscv/riscv-protos.h   |   1 +
>  gcc/config/riscv/riscv-vector-builtins.cc | 281 ++
>  gcc/config/riscv/riscv-vector-builtins.def| 199 +
>  gcc/config/riscv/riscv-vector-builtins.h  |  79 +
>  gcc/config/riscv/riscv-vector-switch.def  | 164 ++
>  gcc/config/riscv/riscv.cc |  95 +-
>  gcc/config/riscv/t-riscv  |  10 +
>  .../gcc.target/riscv/rvv/base/abi-1.c |  63 
>  .../gcc.target/riscv/rvv/base/abi-2.c |  63 
>  .../gcc.target/riscv/rvv/base/abi-3.c |  63 
>  .../gcc.target/riscv/rvv/base/abi-4.c |  63 
>  .../gcc.target/riscv/rvv/base/abi-5.c |  63 
>  .../gcc.target/riscv/rvv/base/abi-6.c |  63 
>  .../gcc.target/riscv/rvv/base/abi-7.c |  63 
>  gcc/testsuite/gcc.target/riscv/rvv/rvv.exp|  47 +++
>  17 files changed, 1319 insertions(+), 1 deletion(-)
>  create mode 100644 gcc/config/riscv/riscv-vector-builtins.cc
>  create mode 100644 gcc/config/riscv/riscv-vector-builtins.def
>  create mode 100644 gcc/config/riscv/riscv-vector-builtins.h
>  create mode 100644 gcc/config/riscv/riscv-vector-switch.def
>  create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/abi-1.c
>  create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/abi-2.c
>  create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/abi-3.c
>  create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/abi-4.c
>  create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/abi-5.c
>  create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/abi-6.c
>  create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/abi-7.c
>  create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/rvv.exp
>
> diff --git a/gcc/config.gcc b/gcc/config.gcc
> index 27ffce3fb50..615a06f87dd 100644
> --- a/gcc/config.gcc
> +++ b/gcc/config.gcc
> @@ -516,6 +516,7 @@ pru-*-*)
>  riscv*)
> cpu_type=riscv
> extra_objs="riscv-builtins.o riscv-c.o riscv-sr.o 
> riscv-shorten-memrefs.o riscv-selftests.o"
> +   extra_objs="${extra_objs} riscv-vector-builtins.o"
> d_target_objs="riscv-d.o"
> ;;
>  rs6000*-*-*)
> diff --git a/gcc/config/riscv/riscv-builtins.cc 
> b/gcc/config/riscv/riscv-builtins.cc
> index 3009311604d..a51037a8f7a 100644
> --- a/gcc/config/riscv/riscv-builtins.cc
> +++ b/gcc/config/riscv/riscv-builtins.cc
> @@ -37,6 +37,7 @@ along with GCC; see the file COPYING3.  If not see
>  #include "stringpool.h"
>  #include "expr.h"
>  #include "langhooks.h"
> +#include "riscv-vector-builtins.h"
>
>  /* Macros to create an enumeration identifier for a function prototype.  */
>  #define RISCV_FTYPE_NAME0(A) RISCV_##A##_FTYPE
> @@ -213,6 +214,7 @@ void
>  riscv_init_builtins (void)
>  {
>riscv_init_builtin_types ();
> +  riscv_vector::init_builtins ();
>
>for (size_t i = 0; i < ARRAY_SIZE (riscv_builtins); i++)
>  {
> diff --git a/gcc/config/riscv/riscv-protos.h b/gcc/config/riscv/riscv-protos.h
> index f9a2baa46c7..101361a4b44 100644
> --- a/gcc/config/riscv/riscv-protos.h
> +++ b/gcc/config/riscv/riscv-protos.h
> @@ -75,6 +75,7 @@ extern 

Re: [PATCH] Teach vectorizer to deal with bitfield accesses (was: [RFC] Teach vectorizer to deal with bitfield reads)

[Andre Vieira (lists) via Gcc-patches]

Made the change and also created the ChangeLogs.

gcc/ChangeLog:

    * tree-if-conv.cc (if_convertible_loop_p_1): Move ordering of 
loop bb's from here...
    (tree_if_conversion): ... to here.  Also call bitfield lowering 
when appropriate.
    (version_loop_for_if_conversion): Adapt to enable loop 
versioning when we only need

    to lower bitfields.
    (ifcvt_split_critical_edges): Relax condition of expected loop 
form as this is checked earlier.

    (get_bitfield_rep): New function.
    (lower_bitfield): Likewise.
    (bitfields_to_lower_p): Likewise.
    (need_to_lower_bitfields): New global boolean.
    (need_to_ifcvt): Likewise.
    * tree-vect-data-refs.cc (vect_find_stmt_data_reference): 
Improve diagnostic message.
    * tree-vect-patterns.cc (vect_recog_temp_ssa_var): Add default 
value for last parameter.

    (vect_recog_bitfield_ref_pattern): New.
    (vect_recog_bit_insert_pattern): New.

gcc/testsuite/ChangeLog:

    * gcc.dg/vect/vect-bitfield-read-1.c: New test.
    * gcc.dg/vect/vect-bitfield-read-2.c: New test.
    * gcc.dg/vect/vect-bitfield-read-3.c: New test.
    * gcc.dg/vect/vect-bitfield-read-4.c: New test.
    * gcc.dg/vect/vect-bitfield-read-5.c: New test.
    * gcc.dg/vect/vect-bitfield-read-6.c: New test.
    * gcc.dg/vect/vect-bitfield-write-1.c: New test.
    * gcc.dg/vect/vect-bitfield-write-2.c: New test.
    * gcc.dg/vect/vect-bitfield-write-3.c: New test.
    * gcc.dg/vect/vect-bitfield-write-4.c: New test.
    * gcc.dg/vect/vect-bitfield-write-5.c: New test.

On 28/09/2022 10:43, Andre Vieira (lists) via Gcc-patches wrote:


On 27/09/2022 13:34, Richard Biener wrote:

On Mon, 26 Sep 2022, Andre Vieira (lists) wrote:


On 08/09/2022 12:51, Richard Biener wrote:

I'm curious, why the push to redundant_ssa_names?  That could use
a comment ...
So I purposefully left a #if 0 #else #endif in there so you can see 
the two
options. But the reason I used redundant_ssa_names is because ifcvt 
seems to
use that as a container for all pairs of (old, new) ssa names to 
replace
later. So I just piggy backed on that. I don't know if there's a 
specific
reason they do the replacement at the end? Maybe some ordering 
issue? Either
way both adding it to redundant_ssa_names or doing the replacement 
inline work

for the bitfield lowering (or work in my testing at least).

Possibly because we (in the past?) inserted/copied stuff based on
predicates generated at analysis time after we decide to elide something
so we need to watch for later appearing uses.  But who knows ... my mind
fails me here.

If it works to replace uses immediately please do so.  But now
I wonder why we need this - the value shouldn't change so you
should get away with re-using the existing SSA name for the final value?


Yeah... good point. A quick change and minor testing seems to agree. 
I'm sure I had a good reason to do it initially ;)


I'll run a full-regression on this change to make sure I didn't miss 
anything.
diff --git a/gcc/testsuite/gcc.dg/vect/vect-bitfield-read-1.c 
b/gcc/testsuite/gcc.dg/vect/vect-bitfield-read-1.c
new file mode 100644
index 
..01cf34fb44484ca926ca5de99eef76dd99b69e92
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/vect/vect-bitfield-read-1.c
@@ -0,0 +1,40 @@
+/* { dg-require-effective-target vect_int } */
+
+#include 
+#include "tree-vect.h"
+
+extern void abort(void);
+
+struct s { int i : 31; };
+
+#define ELT0 {0}
+#define ELT1 {1}
+#define ELT2 {2}
+#define ELT3 {3}
+#define N 32
+#define RES 48
+struct s A[N]
+  = { ELT0, ELT1, ELT2, ELT3, ELT0, ELT1, ELT2, ELT3,
+  ELT0, ELT1, ELT2, ELT3, ELT0, ELT1, ELT2, ELT3,
+  ELT0, ELT1, ELT2, ELT3, ELT0, ELT1, ELT2, ELT3,
+  ELT0, ELT1, ELT2, ELT3, ELT0, ELT1, ELT2, ELT3};
+
+int __attribute__ ((noipa))
+f(struct s *ptr, unsigned n) {
+int res = 0;
+for (int i = 0; i < n; ++i)
+  res += ptr[i].i;
+return res;
+}
+
+int main (void)
+{
+  check_vect ();
+
+  if (f([0], N) != RES)
+abort ();
+
+  return 0;
+}
+
+/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect" } } */
diff --git a/gcc/testsuite/gcc.dg/vect/vect-bitfield-read-2.c 
b/gcc/testsuite/gcc.dg/vect/vect-bitfield-read-2.c
new file mode 100644
index 
..1a4a1579c1478b9407ad21b19e8fbdca9f674b42
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/vect/vect-bitfield-read-2.c
@@ -0,0 +1,43 @@
+/* { dg-require-effective-target vect_int } */
+
+#include 
+#include "tree-vect.h"
+
+extern void abort(void);
+
+struct s {
+unsigned i : 31;
+char a : 4;
+};
+
+#define N 32
+#define ELT0 {0x7FFFUL, 0}
+#define ELT1 {0x7FFFUL, 1}
+#define ELT2 {0x7FFFUL, 2}
+#define ELT3 {0x7FFFUL, 3}
+#define RES 48
+struct s A[N]
+  = { ELT0, ELT1, ELT2, ELT3, ELT0, ELT1, ELT2, ELT3,
+  ELT0, ELT1, ELT2, ELT3, ELT0, ELT1, ELT2, ELT3,
+  ELT0, ELT1, ELT2, ELT3, ELT0, 

Re: [PATCH] Add OPTIONS_H_EXTRA to GTFILES

[Jeff Law via Gcc-patches]

On 9/28/22 00:35, Richard Sandiford via Gcc-patches wrote:

I have a patch that adds a typedef to aarch64's -opts.h.
The typedef is used for a TargetVariable in the .opt file,
which means that it is covered by PCH and so needs to be
visible to gengtype.

-opts.h is not included directly in tm.h, but indirectly
by target headers (in this case aarch64.h).  There was therefore
nothing that caused it to be added to GTFILES.

Tested on aarch64-linux-gnu and x86_64-linux-gnu.  OK to install?

Richard


gcc/
* Makefile.in (GTFILES): Add OPTIONS_H_EXTRA.


OK

jeff

Re: [PATCH 1/2]middle-end Fold BIT_FIELD_REF and Shifts into BIT_FIELD_REFs alone

[Jeff Law via Gcc-patches]

On 9/28/22 07:19, Tamar Christina wrote:

-Original Message-
From: Jeff Law 
Sent: Saturday, September 24, 2022 8:38 PM
To: Tamar Christina ; gcc-patches@gcc.gnu.org
Cc: nd ; rguent...@suse.de
Subject: Re: [PATCH 1/2]middle-end Fold BIT_FIELD_REF and Shifts into
BIT_FIELD_REFs alone


On 9/23/22 05:42, Tamar Christina wrote:

Hi All,

This adds a match.pd rule that can fold right shifts and
bit_field_refs of integers into just a bit_field_ref by adjusting the
offset and the size of the extract and adds an extend to the previous size.

Concretely turns:

#include 

unsigned int foor (uint32x4_t x)
{
  return x[1] >> 16;
}

which used to generate:

_1 = BIT_FIELD_REF ;
_3 = _1 >> 16;

into

_4 = BIT_FIELD_REF ;
_2 = (unsigned int) _4;

I currently limit the rewrite to only doing it if the resulting
extract is in a mode the target supports. i.e. it won't rewrite it to
extract say 13-bits because I worry that for targets that won't have a
bitfield extract instruction this may be a de-optimization.

Bootstrapped Regtested on aarch64-none-linux-gnu, x86_64-pc-linux-gnu
and no issues.

Testcase are added in patch 2/2.

Ok for master?

Thanks,
Tamar

gcc/ChangeLog:

* match.pd: Add bitfield and shift folding.

Were you planning to handle left shifts as well?  It looks like it since you've
got iterations for the shift opcode and corresponding adjustment to the field,
but they currently only handle rshift/plus.


Hmm do left shifts work here? Since a left shift would increase the size of the
resulting value by adding zeros to the end of the number, so you can't increase
the size of the bitfield to do the same.


Dunno, I hadn't really thought about it.  It just looked like you were 
prepared to handle more cases with those iterators.





I did however realize that truncating casts have the same effect as a right 
shift,
so I have added that now.


ACK.

jeff

Re: [PATCH 1/2]middle-end: RFC: On expansion of conditional branches, give hint if argument is a truth type to backend

[Jeff Law via Gcc-patches]

On 9/28/22 09:04, Richard Sandiford wrote:

Tamar Christina  writes:

Maybe the target could use (subreg:SI (reg:BI ...)) as argument. Heh.

But then I'd still need to change the expansion code. I suppose this could
prevent the issue with changes to code on other targets.


We have undocumented addcc, negcc, etc. patterns, should we have aandcc

pattern for this indicating support for andcc + jump as opposedto cmpcc + jump?

This could work yeah. I didn't know these existed.

Ah, so they are conditional add, not add setting CC, so andcc wouldn't
be appropriate.
So I'm not sure how we'd handle such situation - maybe looking at
REG_DECL and recognizing a _Bool PARM_DECL is OK?

I have a slight suspicion that Richard Sandiford would likely reject this
though..

Good guess :-P  We shouldn't rely on something like that for correctness.

Would it help if we promoted the test-and-branch instructions to optabs,
alongside cbranch?  The jump expanders could then target it directly.

IMO that'd be a reasonable thing to do if it does help.  It's a relatively
common operation, especially on CISCy targets.


But don't we represent these single bit tests using zero_extract as the 
condition of the branch?  I guess if we can generate them directly 
rather than waiting for combine to deduce that we're dealing with a 
single bit test and constructing the zero_extract form would be an 
improvement and might help aarch at the same time.



jeff

Re: [PATCH] C++ API database

[Ulrich Drepper via Gcc-patches]

Ping.  Anyone having problems with this?  And the governance of the file?

On Mon, Sep 12, 2022 at 1:51 PM Ulrich Drepper  wrote:

> After my prior inquiry into the use of python as a build tool for
> maintainers didn't produce any negative comments and several active and
> even enthusiastic support message I'm going forward with submitting the
> patch.
>
> To repeat the detail, for the generation of the upcoming C++ standard
> library module and the hints for missing definitions/declarations in the
> std:: namespace we need a list of standard C++ APIs.  The information
> needed for the two use cases is different but the actual APIs overlap
> almost completely and therefore it would be a bad idea to have the data
> separated.
>
> We could opt for a file format that is easy to read in awk and writing the
> appropriate scripts to transform the data into the appropriate output
> format but this looks ugly, is hard to understand, and a nightmare to
> maintain.  On the other hand, writing the code in Python is simple and
> clean.
>
>
> Therefore, Jonathan and I worked on a CSV file which contains the
> necessary information and a Python to create the gperf input file to
> generate std-name-hint.h and also, in future, the complete source of the
> export interface description for the standard library module.  This mode is
> not yet used because the module support isn't ready yet.  The output file
> corresponds to the hand-coded version of the export code Jonathan uses
> right now.
>
> Note that in both of these cases the generated files are static, they
> don't depend on the local configuration and therefore are checked into the
> source code repository.  The script only has to run if the generated files
> are explicitly removed or, in maintainer mode, if the CSV file has
> changed.  For normal compilation from a healthy source code tree the tool
> is not needed.
>
>
> One remaining issue is the responsibility for the CSV file.  The file
> needs to live in the directory of the frontend and therefore nominally
> changes need to be approved by the frontend maintainers.  The content
> entirely consists of information from the standard library, though.  Any
> change that doesn't break the build on one machine (i.e., the Python script
> doesn't fail) will not course any problem because the output format of the
> script is correct.  Therefore we have been wondering whether the CSV file
> should at least have shared ownership between the frontend maintainers and
> the libstdc++ maintainers.
>
> The CSV file contain more hint information than the old hand-coded .gperf
> file.  So, an additional effect of this patch is the extension of the hints
> that are provided but given that the lookup is now fast this shouldn't have
> any negative impact.  The file is not complete, though, this will come over
> time and definitely before the module support is done.
>
> I build my complete set of compilers with this patch without problems.
>
> Any comments?
>
> 2022-09-12  Jonathan Wakely  
> Ulrich Drepper  
>
> contrib/ChangeLog
> * gcc_update: Add rule to generate gcc/cp/std-name-hint.gperf.
>
> gcc/cp/ChangeLog
> * Make-lang.in: Add rule to generate gcc/cp/std-name-hint.gperf.
> Adjust rule to generate $(srcdir)/cp/std-name-hint.h.
> Add explicit rule to depend cp/name-lookup.o on
> $(srcdir)/cp/std-name-hint.h.
> * cxxapi-data.csv: New file.  Database of C++ APIs.
> * gen-cxxapi-file.py: New file.  Script to generate source code for
> C++ standard library exports and to generate C++ std:: namespace
> fix hints.
> * std-name-hint.gperf: Regenerated.
> * std-name-hint.h: Regenerated.
>

Re: [RFC] postreload cse'ing vector constants

[Robin Dapp via Gcc-patches]

> I opened:
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107061

The online docs for encodekey256 also say

XMM4 through XMM6 are reserved for future usages and software should not
rely upon them being zeroed.

I believe we also zero there.

> This sounds like an issue.

So with your patch for encodekey128 the regression is gone and we zero
(pxor) xmm0 in both versions.  The case I outlined before does not
actually happen since cprop_hardreg propagates the (newly) zeroed
register to the use sites rather than zeroing every time.

I guess this just leaves the situation where we implicitly know that a
reg is zero and by rather zeroing another one we miss the cprop_hardreg
opportunity.  Not sure how common this is and if it's a blocker for this
patch.  No regressions on x86, aarch64, power9 and s390 now.  Most
likely we don't check to that granularity in the test suite and even
here it was more of accidental hit.

Re: [PATCH 1/2] c++: introduce TRAIT_TYPE alongside TRAIT_EXPR

[Patrick Palka via Gcc-patches]

On Tue, 27 Sep 2022, Jason Merrill wrote:

> On 9/27/22 15:50, Patrick Palka wrote:
> > We already have generic support for predicate-like traits that yield a
> > boolean via TRAIT_EXPR, but we lack the same support for transform-like
> > traits that yield a type.  Such support would be useful for implementing
> > efficient built-ins for std::decay and std::remove_cvref and other
> > conceptually simple type traits that are otherwise relatively expensive
> > to implement.
> > 
> > This patch implements a generic TRAIT_TYPE type and replaces the
> > existing hardcoded UNDERLYING_TYPE type to use TRAIT_TYPE instead.
> 
> Sounds good, perhaps we also want to convert BASES to e.g. TRAIT_TYPE_PACK at
> some point...

*nod*

> 
> > gcc/cp/ChangeLog:
> > 
> > * cp-objcp-common.cc (cp_common_init_ts): Replace
> > UNDERLYING_TYPE with TRAIT_TYPE.
> > * cp-tree.def (TRAIT_TYPE): Define.
> > (UNDERLYING_TYPE): Remove.
> > * cp-tree.h (TRAIT_TYPE_KIND_RAW): Define.
> > (TRAIT_TYPE_KIND): Define.
> > (TRAIT_TYPE_TYPE1): Define.
> > (TRAIT_TYPE_TYPE2): Define.
> > (WILDCARD_TYPE_P): Return true for TRAIT_TYPE.
> > (finish_trait_type): Declare.
> > * cxx-pretty-print.cc (cxx_pretty_printer::primary_expression):
> > Adjust after renaming pp_cxx_trait_expression.
> > (cxx_pretty_printer::type_id): Replace UNDERLYING_TYPE with
> > TRAIT_TYPE.
> > (pp_cxx_trait_expression): Rename to ...
> > (pp_cxx_trait): ... this.  Handle TRAIT_TYPE as well.  Correct
> > pretty printing of the trailing arguments.
> > * cxx-pretty-print.h (pp_cxx_trait_expression): Rename to ...
> > (pp_cxx_trait_type): ... this.
> > * error.cc (dump_type) : Remove.
> > : New.
> > (dump_type_prefix): Replace UNDERLYING_WITH with TRAIT_TYPE.
> > (dump_type_suffix): Likewise.
> > * mangle.cc (write_type) : Remove.
> > : New.
> > * module.cc (trees_out::type_node) :
> > Remove.
> > : New.
> > (trees_in::tree_node): Likewise.
> > * parser.cc (cp_parser_primary_expression): Adjust after
> > renaming cp_parser_trait_expr.
> > (cp_parser_trait_expr): Rename to ...
> > (cp_parser_trait): ... this.  Call finish_trait_type for traits
> > that yield a type.
> > (cp_parser_simple_type_specifier): Adjust after renaming
> > cp_parser_trait_expr.
> > * pt.cc (for_each_template_parm_r) :
> > Remove.
> > : New.
> > (tsubst): Likewise.
> > (unify): Replace UNDERLYING_TYPE with TRAIT_TYPE.
> > (dependent_type_p_r): Likewise.
> > * semantics.cc (finish_underlying_type): Don't return
> > UNDERLYING_TYPE anymore when processing_template_decl.
> > (finish_trait_type): Define.
> > * tree.cc (strip_typedefs) : Remove.
> > : New.
> > (cp_walk_subtrees): Likewise.
> > * typeck.cc (structural_comptypes): Likewise.
> > 
> > gcc/testsuite/ChangeLog:
> > 
> > * g++.dg/ext/underlying_type7.C: Adjust expected error message.
> > ---
> >   gcc/cp/cp-objcp-common.cc   |  2 +-
> >   gcc/cp/cp-tree.def  |  9 ++--
> >   gcc/cp/cp-tree.h| 18 
> >   gcc/cp/cxx-pretty-print.cc  | 49 ++---
> >   gcc/cp/cxx-pretty-print.h   |  2 +-
> >   gcc/cp/error.cc | 14 +++---
> >   gcc/cp/mangle.cc|  5 ++-
> >   gcc/cp/module.cc| 24 +-
> >   gcc/cp/parser.cc| 24 +-
> >   gcc/cp/pt.cc| 26 +++
> >   gcc/cp/semantics.cc | 41 -
> >   gcc/cp/tree.cc  | 22 ++---
> >   gcc/cp/typeck.cc|  7 ++-
> >   gcc/testsuite/g++.dg/cpp0x/alias-decl-59.C  |  4 +-
> >   gcc/testsuite/g++.dg/ext/underlying_type7.C |  2 +-
> >   15 files changed, 171 insertions(+), 78 deletions(-)
> > 
> > diff --git a/gcc/cp/cp-objcp-common.cc b/gcc/cp/cp-objcp-common.cc
> > index 64975699351..380f288a7f1 100644
> > --- a/gcc/cp/cp-objcp-common.cc
> > +++ b/gcc/cp/cp-objcp-common.cc
> > @@ -518,7 +518,7 @@ cp_common_init_ts (void)
> > MARK_TS_TYPE_NON_COMMON (DECLTYPE_TYPE);
> > MARK_TS_TYPE_NON_COMMON (TYPENAME_TYPE);
> > MARK_TS_TYPE_NON_COMMON (TYPEOF_TYPE);
> > -  MARK_TS_TYPE_NON_COMMON (UNDERLYING_TYPE);
> > +  MARK_TS_TYPE_NON_COMMON (TRAIT_TYPE);
> > MARK_TS_TYPE_NON_COMMON (BOUND_TEMPLATE_TEMPLATE_PARM);
> > MARK_TS_TYPE_NON_COMMON (TEMPLATE_TEMPLATE_PARM);
> > MARK_TS_TYPE_NON_COMMON (TEMPLATE_TYPE_PARM);
> > diff --git a/gcc/cp/cp-tree.def b/gcc/cp/cp-tree.def
> > index f9cbd339f19..f83b4c54d43 100644
> > --- a/gcc/cp/cp-tree.def
> > +++ b/gcc/cp/cp-tree.def
> > @@ -444,9 +444,12 @@ DEFTREECODE (BIT_CAST_EXPR, "bit_cast_expr",
> > tcc_expression, 1)
> > /** C++ extensions. */
> >   -/* Represents a trait expression during 

Re: [PATCH] rs6000: Rework option -mpowerpc64 handling [PR106680]

[Iain Sandoe]

(reduced CC list, if folks want to be re-included .. please add them back).

> On 28 Sep 2022, at 07:37, Iain Sandoe  wrote:

>> On 28 Sep 2022, at 06:30, Kewen.Lin via Gcc-patches 
>>  wrote:
> 
>> PR106680 shows that -m32 -mpowerpc64 is different from
>> -mpowerpc64 -m32, this is determined by the way how we
>> handle option powerpc64 in rs6000_handle_option.
>> 
>> Segher pointed out this difference should be taken as
>> a bug and we should ensure that option powerpc64 is
>> independent of -m32/-m64.  So this patch removes the
>> handlings in rs6000_handle_option and add some necessary
>> supports in rs6000_option_override_internal instead.
>> 
>> With this patch, if users specify -m{no-,}powerpc64, the
>> specified value is honoured, otherwise, for 64bit it
>> always enables OPTION_MASK_POWERPC64 while for 32bit
>> it disables OPTION_MASK_POWERPC64 if OS_MISSING_POWERPC64.
>> 
>> Bootstrapped and regress-tested on:
>> - powerpc64-linux-gnu P7 and P8 {-m64,-m32}
>> - powerpc64le-linux-gnu P9 and P10
>> - powerpc-ibm-aix7.2.0.0 {-maix64,-maix32}
>> 
>> Hi Iain, could you help to test this on darwin to ensure
>> it won't break darwin's build and new tests are fine?
>> Thanks in advance!
> 
> Will do, it will take a day or so, thanks,

Perhaps a small exposition on the target:

powerpc-apple-darwin, is perhaps somewhat unusual in that it is nominally a 32b 
kernel, but the OS supports 64b processes on suitable hardware (and the OS does 
preserve the upper bits of 64b regs in the context).

-

I bootstrapped (all supported languages) and tested r13-2892 yesterday with 
“nominal” results.

Then I added this patch .. and did a clean bootstrap (same configuration).

the bootstrap fails on the stage3 libgomp (building the ppc64 multilib) with 
the error below
What is somewhat odd here is that libgomp is bootstrapped with the compiler 
and, apparently,
openacc-init.c built OK at stage2.

——

Of course, powerpc-darwin is not a blocker for anything, it should not hold you 
up (but sometimes it
manages to find a glitch missed elsewhere).  I will try to take a look at this 
this evening see if I can throw
any more light on it.

--

/src-local/gcc-master/libgomp/oacc-init.c:876:1: internal compiler error: 
‘global_options’ are modified in local context
  876 | {
  | ^
0xe940d7 cl_optimization_compare(gcc_options*, gcc_options*)
/scratch/10-5-leo/gcc-master/gcc/options-save.cc:14082
0x15f8fb handle_optimize_attribute
/src-local/gcc-master/gcc/c-family/c-attribs.cc:5619
0x8447 decl_attributes(tree_node**, tree_node*, int, tree_node*)
/src-local/gcc-master/gcc/attribs.cc:875
0x307bb start_function(c_declspecs*, c_declarator*, tree_node*)
/src-local/gcc-master/gcc/c/c-decl.cc:9537
0xb4f27 c_parser_declaration_or_fndef
/src-local/gcc-master/gcc/c/c-parser.cc:2466
0xc164f c_parser_external_declaration
/src-local/gcc-master/gcc/c/c-parser.cc:1800
0xc2323 c_parser_translation_unit
/src-local/gcc-master/gcc/c/c-parser.cc:1666
0xc2323 c_parse_file()
???:0
0x13a5db c_common_parse_file()
/src-local/gcc-master/gcc/c-family/c-opts.cc:1255
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.

[GCC 11] aarch64: Add support for -mcpu=neoverse-v2

[Kyrylo Tkachov via Gcc-patches]

Hi all,

This is a GCC 11 version of 
https://gcc.gnu.org/pipermail/gcc-patches/2022-September/602105.html
There are no tuning structures to rename so the patch is (even) smaller than 
the GCC 12 and trunk
versions.

Bootstrapped and tested on aarch64-none-linux-gnu.
Pushing to the branch.
Thanks,
Kyrill

gcc/ChangeLog:

* config/aarch64/aarch64-cores.def (neoverse-v2): New entry.
* config/aarch64/aarch64-tune.md: Regenerate.
* doc/invoke.texi (AArch64 Options): Document neoverse-v2.


v2-11.patch
Description: v2-11.patch

[GCC 10] aarch64: Add support for -mcpu=neoverse-v2

[Kyrylo Tkachov via Gcc-patches]

Hi all,

This is a GCC 10 version of 
https://gcc.gnu.org/pipermail/gcc-patches/2022-September/602105.html
There are no tuning structures to rename so the patch is (even) smaller than 
the GCC 12 and trunk
versions.

Bootstrapped and tested on aarch64-none-linux-gnu.
Pushing to trunk.
Thanks,
Kyrill

gcc/ChangeLog:

* config/aarch64/aarch64-cores.def (neoverse-v2): New entry.
* config/aarch64/aarch64-tune.md: Regenerate.
* doc/invoke.texi (AArch64 Options): Document neoverse-v2.


v2-10.patch
Description: v2-10.patch

Re: [PATCH v4] rs6000: Rework ELFv2 support for -fpatchable-function-entry* [PR99888]

[Segher Boessenkool]

Hi!

On Thu, Aug 25, 2022 at 01:50:28PM +0800, Kewen.Lin wrote:
> --- a/gcc/config/rs6000/rs6000-internal.h
> +++ b/gcc/config/rs6000/rs6000-internal.h
> @@ -183,10 +183,15 @@ extern tree rs6000_fold_builtin (tree fndecl 
> ATTRIBUTE_UNUSED,
>tree *args ATTRIBUTE_UNUSED,
>bool ignore ATTRIBUTE_UNUSED);
> 
> +extern void rs6000_print_patchable_function_entry (FILE *,
> +unsigned HOST_WIDE_INT,
> +bool);
> +
>  extern bool rs6000_passes_float;
>  extern bool rs6000_passes_long_double;
>  extern bool rs6000_passes_vector;
>  extern bool rs6000_returns_struct;
>  extern bool cpu_builtin_p;
> 
> +
>  #endif

No new random empty lines please.

> +  point would be 2, 6 and 14.  It's possible to support those
> +  other counts of nops by not making a local entry point, but
> +  we don't have clear user cases for them, so leave them

"use cases"

> --- a/gcc/doc/invoke.texi
> +++ b/gcc/doc/invoke.texi
> @@ -16717,9 +16717,13 @@ the area size or to remove it completely on a single 
> function.
>  If @code{N=0}, no pad location is recorded.
> 
>  The NOP instructions are inserted at---and maybe before, depending on
> -@var{M}---the function entry address, even before the prologue.
> +@var{M}---the function entry address, even before the prologue.  On
> +PowerPC with the ELFv2 ABI, for one function with dual entry points,
> +the local entry point is taken as the function entry for generation.

I think "the local entry point is this function entry address" is a bit
clearer.

> -The maximum value of @var{N} and @var{M} is 65535.
> +The maximum value of @var{N} and @var{M} is 65535.  On PowerPC with the
> +ELFv2 ABI, for one function with dual entry points, the supported values
> +for @var{M} are 0, 2, 6 and 14.

"for a function"

Okay for trunk with those trivial chnges.  Thanks!


Segher

Re: [PATCH] OpenACC: whole struct vs. component mappings (PR107028)

[Tobias Burnus]

On 28.09.22 15:20, Julian Brown wrote:

This patch fixes an ICE when both a complete struct variable and
components of that struct are mapped on the same directive for OpenACC,
using a modified version of the scheme used for OpenMP in the following
patch [...]
Tested with offloading to NVPTX. OK?

OpenACC comments:

I do note that there are now two "appears more than once in map clauses". The
newly added  error_at in oacc_resolve_clause_dependencies is triggered by
gcc/testsuite/gfortran.dg/goacc/{derived-types-3.f90,goacc/mapping-tests-{1,4}.f90}.

However, it looks as if no testcase triggers anymore the OpenACC-only error_at
in omp_accumulate_sibling_list. My impression is that the 
oacc_resolve_clause_dependencies
check + 'if (grp->deleted) continue;' in the sibling-list function makes this 
difficult to hit.

I don't see immediately whether some cases can still reach 
omp_accumulate_sibling_list –
if so, a testcase would be nice, or whether that error_at can now be removed.


However, I note that *without* the patch, the *following* *error* triggers – 
while
it compiles *silently* *with* the *patch* applied:

  15 |   !$acc enter data copyin(x%A, x%A%i(5), x%A%i(5))
 |  ^
Error: ‘x.a.i’ appears more than once in map clauses

  15 |   !$acc enter data copyin(x%A, x%A%i(5), x%A%i(4))
 |  ^
Error: ‘x.a.i’ appears more than once in map clauses

BTW: The two testcases differ by the array-element: '5'/'5' vs. '5'/'4'.
Testcase is a modified existing one:

--- a/gcc/testsuite/gfortran.dg/goacc/mapping-tests-4.f90
+++ b/gcc/testsuite/gfortran.dg/goacc/mapping-tests-4.f90
@@ -3 +3 @@ subroutine foo
-integer i, j
+integer i(5), j
@@ -15 +15 @@ subroutine foo
-  !$acc enter data copyin(x%A, x%A%i, x%A%i)
+  !$acc enter data copyin(x%A, x%A%i(5), x%A%i(4))

Otherwise, the patch looks sensible - as far as I understand it.
However, it surely would help if Thomas and/or Jakub could have a second look.

Tobias


2022-09-28  Julian Brown  


gcc/
   PR middle-end/107028
   * gimplify.cc (omp_group_base): Fix IF_PRESENT handling.
   (omp_check_mapping_compatibility, oacc_resolve_clause_dependencies):
   New functions.
   (build_struct_sibling_lists): Skip deleted groups.  Don't build sibling
   list for struct variables that are fully mapped on the same directive
   for OpenACC.
   (gimplify_scan_omp_clauses): Call oacc_resolve_clause_dependencies.

gcc/testsuite/
   PR middle-end/107028
   * c-c++-common/goacc/struct-component-kind-1.c: New test.
   * g++.dg/goacc/pr107028-1.C: New test.
   * g++.dg/goacc/pr107028-2.C: New test.

-
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

[PATCH] vect: while_ult for integer mask

[Andrew Stubbs]

This patch is a prerequisite for some amdgcn patches I'm working on to 
support shorter vector lengths (having fixed 64 lanes tends to miss 
optimizations, and masking is not supported everywhere yet).


The problem is that, unlike AArch64, I'm not using different mask modes 
for different sized vectors, so all loops end up using the while_ultsidi 
pattern, regardless of vector length.  In theory I could use SImode for 
V32, HImode for V16, etc., but there's no mode to fit V4 or V2 so 
something else is needed.  Moving to using vector masks in the backend 
is not a natural fit for GCN, and would be a huge task in any case.


This patch adds an additional length operand so that we can distinguish 
the different uses in the back end and don't end up with more lanes 
enabled than there ought to be.


I've made the extra operand conditional on the mode so that I don't have 
to modify the AArch64 backend; that uses while_ family of 
operators in a lot of places and uses iterators, so it would end up 
touching a lot of code just to add an inactive operand, plus I don't 
have a way to test it properly.  I've confirmed that AArch64 builds and 
expands while_ult correctly in a simple example.


OK for mainline?

Thanks

Andrewvect: while_ult for integer masks

Add a vector length parameter needed by amdgcn without breaking aarch64.

All amdgcn vector masks are DImode, regardless of vector length, so we can't
tell what length is implied simply from the operator mode.  (Even if we used
different integer modes there's no mode small enough to differenciate a 2 or
4 lane mask).  Without knowing the intended length we end up using a mask with
too many lanes enabled, which leads to undefined behaviour..

The extra operand is not added for vector mask types so AArch64 does not need
to be adjusted.

gcc/ChangeLog:

* config/gcn/gcn-valu.md (while_ultsidi): Limit mask length using
operand 3.
* doc/md.texi (while_ult): Document new operand 3 usage.
* internal-fn.cc (expand_while_optab_fn): Set operand 3 when lhs_type
maps to a non-vector mode.

diff --git a/gcc/config/gcn/gcn-valu.md b/gcc/config/gcn/gcn-valu.md
index 3bfdf8213fc..dec81e863f7 100644
--- a/gcc/config/gcn/gcn-valu.md
+++ b/gcc/config/gcn/gcn-valu.md
@@ -3052,7 +3052,8 @@ (define_expand "vcondu_exec"
 (define_expand "while_ultsidi"
   [(match_operand:DI 0 "register_operand")
(match_operand:SI 1 "")
-   (match_operand:SI 2 "")]
+   (match_operand:SI 2 "")
+   (match_operand:SI 3 "")]
   ""
   {
 if (GET_CODE (operands[1]) != CONST_INT
@@ -3077,6 +3078,11 @@ (define_expand "while_ultsidi"
  : ~((unsigned HOST_WIDE_INT)-1 << diff));
emit_move_insn (operands[0], gen_rtx_CONST_INT (VOIDmode, mask));
   }
+if (INTVAL (operands[3]) < 64)
+  emit_insn (gen_anddi3 (operands[0], operands[0],
+gen_rtx_CONST_INT (VOIDmode,
+   ~((unsigned HOST_WIDE_INT)-1
+ << INTVAL (operands[3]);
 DONE;
   })
 
diff --git a/gcc/doc/md.texi b/gcc/doc/md.texi
index d46963f468c..d8e2a5a83f4 100644
--- a/gcc/doc/md.texi
+++ b/gcc/doc/md.texi
@@ -4950,9 +4950,10 @@ This pattern is not allowed to @code{FAIL}.
 @cindex @code{while_ult@var{m}@var{n}} instruction pattern
 @item @code{while_ult@var{m}@var{n}}
 Set operand 0 to a mask that is true while incrementing operand 1
-gives a value that is less than operand 2.  Operand 0 has mode @var{n}
-and operands 1 and 2 are scalar integers of mode @var{m}.
-The operation is equivalent to:
+gives a value that is less than operand 2, for a vector length up to operand 3.
+Operand 0 has mode @var{n} and operands 1 to 3 are scalar integers of mode
+@var{m}.  Operand 3 should be omitted when @var{n} is a vector mode.  The
+operation for vector modes is equivalent to:
 
 @smallexample
 operand0[0] = operand1 < operand2;
@@ -4960,6 +4961,14 @@ for (i = 1; i < GET_MODE_NUNITS (@var{n}); i++)
   operand0[i] = operand0[i - 1] && (operand1 + i < operand2);
 @end smallexample
 
+And for non-vector modes the operation is equivalent to:
+
+@smallexample
+operand0[0] = operand1 < operand2;
+for (i = 1; i < operand3; i++)
+  operand0[i] = operand0[i - 1] && (operand1 + i < operand2);
+@end smallexample
+
 @cindex @code{check_raw_ptrs@var{m}} instruction pattern
 @item @samp{check_raw_ptrs@var{m}}
 Check whether, given two pointers @var{a} and @var{b} and a length @var{len},
diff --git a/gcc/internal-fn.cc b/gcc/internal-fn.cc
index 651d99eaeb9..c306240c2ac 100644
--- a/gcc/internal-fn.cc
+++ b/gcc/internal-fn.cc
@@ -3664,7 +3664,7 @@ expand_direct_optab_fn (internal_fn fn, gcall *stmt, 
direct_optab optab,
 static void
 expand_while_optab_fn (internal_fn, gcall *stmt, convert_optab optab)
 {
-  expand_operand ops[3];
+  expand_operand ops[4];
   tree rhs_type[2];
 
   tree lhs = gimple_call_lhs (stmt);
@@ -3680,10 +3680,24 @@ expand_while_optab_fn 

Re: [PATCH 1/2]middle-end: RFC: On expansion of conditional branches, give hint if argument is a truth type to backend

[Richard Sandiford via Gcc-patches]

Tamar Christina  writes:
>> Maybe the target could use (subreg:SI (reg:BI ...)) as argument. Heh.
>
> But then I'd still need to change the expansion code. I suppose this could
> prevent the issue with changes to code on other targets. 
>
>> > > We have undocumented addcc, negcc, etc. patterns, should we have aandcc
> pattern for this indicating support for andcc + jump as opposedto cmpcc + 
> jump?
>> >
>> > This could work yeah. I didn't know these existed.
>
>> Ah, so they are conditional add, not add setting CC, so andcc wouldn't
>> be appropriate.
>
>> So I'm not sure how we'd handle such situation - maybe looking at
>> REG_DECL and recognizing a _Bool PARM_DECL is OK?
>
> I have a slight suspicion that Richard Sandiford would likely reject this
> though..

Good guess :-P  We shouldn't rely on something like that for correctness.

Would it help if we promoted the test-and-branch instructions to optabs,
alongside cbranch?  The jump expanders could then target it directly.

IMO that'd be a reasonable thing to do if it does help.  It's a relatively
common operation, especially on CISCy targets.

Thanks,
Richard

> The additional AND seemed less hacky as it's just communicating range.
>
> I still need to also figure out which representation of bool is being used,
> because only the 0-1 variant works. Is there a way to check that?
>
> Thanks, 
> Tamar. 
>
> ---
> From: Richard Biener 
> Sent: Monday, September 26, 2022 12:32 PM
> To: Tamar Christina 
> Cc: gcc-patches@gcc.gnu.org ; nd ;
> jeffreya...@gmail.com ; Richard Sandiford
> 
> Subject: Re: [PATCH 1/2]middle-end: RFC: On expansion of conditional branches,
> give hint if argument is a truth type to backend
>  
> On Mon, 26 Sep 2022, Tamar Christina wrote:
>
>> > > This pattern occurs more than 120,000 times in SPECCPU 2017 and so is
> quite common.
>>
>> > How does this help a target?
>>
>> So the idea is to communicate that only the bottom bit of the value is
> relevant and not the entire value itself.
>>
>> > Why does RTL nonzerop bits not recover thisinformation and the desired
> optimization done later during combinefor example?
>>
>> I'm not sure it works here. We (AArch64) don't have QImode integer registers,
> so our apcs says that the top bits of the 32-bit registers it's passed in are
> undefined.
>>
>> We have to zero extend the value first if we really want it as an 8-bit
> value. So the problem is if you e.g. Pass a boolean as an argument of a
> function I don't think nonzero bits will return anything useful.
>>
>> > Why's a SImode compare not OK if there's no QImode compare?
>>
>> The mode then becomes irrelevant because we're telling the backend that only
> a single bit matters. And we have instructions to test and branch on the value
> of a single bit. See https://gcc.gnu.org/pipermail/gcc-patches/2022-September/
> 602090.html for the testcases
>
> Maybe the target could use (subreg:SI (reg:BI ...)) as argument.  Heh.
>
>> > We have undocumented addcc, negcc, etc. patterns, should we have aandcc
> pattern for this indicating support for andcc + jump as opposedto cmpcc + 
> jump?
>>
>> This could work yeah. I didn't know these existed.
>
> Ah, so they are conditional add, not add setting CC, so andcc wouldn't
> be appropriate.
>
> So I'm not sure how we'd handle such situation - maybe looking at
> REG_DECL and recognizing a _Bool PARM_DECL is OK?
>
> Richard.
>
>> > So - what's the target and what's a testcase?
>>
>> See https://gcc.gnu.org/pipermail/gcc-patches/2022-September/602090.html :)
>>
>> Thanks,
>> Tamar
>>
>> 
>> From: Richard Biener 
>> Sent: Monday, September 26, 2022 11:35 AM
>> To: Tamar Christina 
>> Cc: gcc-patches@gcc.gnu.org ; nd ;
> jeffreya...@gmail.com ; Richard Sandiford
> 
>> Subject: Re: [PATCH 1/2]middle-end: RFC: On expansion of conditional
> branches, give hint if argument is a truth type to backend
>>
>> On Fri, 23 Sep 2022, Tamar Christina wrote:
>>
>> > Hi All,
>> >
>> > This is an RFC to figure out how to deal with targets that don't have
> native
>> > comparisons against QImode values.
>> >
>> > Booleans, at least in C99 and higher are 0-1 valued.  This means that we
> only
>> > really need to test a single bit.  However in RTL we no longer have this
>> > information available and just have an SImode value (due to the promotion
> of
>> > QImode to SImode).
>> >
>> > This RFC fixes it by emitting an explicit & 1 during the expansion of the
>> > conditional branch.
>> >
>> > However it's unlikely that we want to do this unconditionally.  Most
> targets
>> > I've tested seem to have harmless code changes, like x86 changes from testb
> to
>> > andl, $1.
>> >
>> > So I have two questions:
>> >
>> > 1. Should I limit this behind a target macro? Or should I just leave it for
> all
>> >targets and deal with the fallout.
>> > 2. How can I tell whether the C99 0-1 values bools are being used or the
> 

Re: PING^1 [PATCH] rs6000/test: Adjust pr104992.c with vect_int_mod [PR106516]

[Segher Boessenkool]

On Wed, Sep 28, 2022 at 01:35:09PM +0800, Kewen.Lin wrote:
> I assumed the generic part introducing check_effective_target_vect_int_mod
> needs the approval from global maintainers.

Target-specific testsuite changes can be approved by target maintainers.
Currently this can be considered target-specific (since we are the only
one implementing it), so :-)  I know it is borderline.


Segher

Re: [PATCH] rs6000/test: Adjust pr104992.c with vect_int_mod [PR106516]

[Segher Boessenkool]

Hi!

On Wed, Aug 24, 2022 at 04:17:55PM +0800, Kewen.Lin wrote:
> As PR106516 shows, we can get unexpected gimple outputs for
> function thud on some target which supports modulus operation
> for vector int.  This patch introduces one effective target
> vect_int_mod for it, then adjusts the test case with it.

> +# Return 1 if the target supports vector int modulus, 0 otherwise.
> +
> +proc check_effective_target_vect_int_mod { } {
> +return [check_cached_effective_target_indexed vect_int_mod {
> +  expr { [istarget powerpc*-*-*]
> +  && [check_effective_target_power10_ok] }}]
> +}

power10_ok does not mean the vmod[su][wdq] instructions will be
generated.  You need to test if we have -mcpu=power10 or such, so,
check_effective_target_has_arch_pwr10 .

_ok tests if it is okay to enable .  _hw tests if the hardware
can do .  has_arch_ tests if the compiler is asked to generate
code for  (which is reflected in the _ARCH_* preprocessor symbols,
hence the name).

Okay for trunk with the correct check_effective_target_* .  Thanks!


Segher

Re: [PATCH] c++ modules: ICE with class NTTP argument [PR100616]

[Patrick Palka via Gcc-patches]

On Tue, 27 Sep 2022, Nathan Sidwell wrote:

> On 9/26/22 15:05, Patrick Palka wrote:
> > On Mon, 26 Sep 2022, Patrick Palka wrote:
> > 
> > > On Mon, 26 Sep 2022, Nathan Sidwell wrote:
> > > 
> > > > On 9/26/22 10:08, Nathan Sidwell wrote:
> > > > > On 9/23/22 09:32, Patrick Palka wrote:
> > > > > 
> > > > > > Judging by the two commits that introduced/modified this part of
> > > > > > maybe_register_incomplete_var, r196852 and r214333, ISTM the code
> > > > > > is really only concerned with constexpr static data members (whose
> > > > > > initializer may contain a pointer-to-member for a currently open
> > > > > > class).
> > > > > > So maybe we ought to restrict the branch like so, which effectively
> > > > > > disables this part of maybe_register_incomplete_var during
> > > > > > stream-in, and
> > > > > > guarantees that outermost_open_class doesn't return NULL if the
> > > > > > branch is
> > > > > > taken?
> > > > > 
> > > > > I think the problem is that we're streaming these VAR_DECLs as regular
> > > > > VAR_DECLS, when we should be handling them as a new kind of object
> > > > > fished
> > > > > out from the template they're instantiating. (I'm guessing that'll
> > > > > just be a
> > > > > new tag, a type and an initializer?)
> > > > > 
> > > > > Then on stream-in we can handle them in the same way as a non-modules
> > > > > compilation handles such redeclarations.  I.e. how does:
> > > > > 
> > > > > template struct C { };
> > > > > struct A { };
> > > > > C c1; // #1
> > > > > C c2; // #2
> > > > > 
> > > > > work.  Presumably at some point #2's A{} gets unified such that we
> > > > > find the
> > > > > instantation that occurred at #1?
> > > 
> > > This works because the lookup in get_template_parm_object for #2's A{}
> > > finds and reuses the VAR_DECL created for #1's A{}.
> > > 
> > > But IIUC this lookup (performed via get_global_binding) isn't
> > > import-aware, which I suppose explains why we don't find the VAR_DECL
> > > from another TU.
> > > 
> > > > > 
> > > > > I notice the template arg for C is a var decl mangled as
> > > > > _ZTAXtl1AEE,
> > > > > which is a 'template paramete object for A{}'.  I see that's a special
> > > > > mangler 'mangle_template_parm_object', called from
> > > > > get_template_parm_object.  Perhaps these VAR_DECLs need an additional
> > > > > in-tree flag that the streamer can check for?
> > > > 
> > > > I wonder if we're setting the module attachment for these variables
> > > > sanely?
> > > > They should be attached to the global module.  My guess is the
> > > > pushdecl_top_level_and_finish call in get_templatE_parm_object is not
> > > > doing
> > > > what is needed (as well as the other issues).
> > > 
> > > This is a bit of a shot in the dark, but the following seems to work:
> > > when pushing the VAR_DECL, we need to call set_originating_module to
> > > attach it to the global module, and when looking it up, we need to do so
> > > in an import-aware way.  Hopefully something like this is sufficient
> > > to properly handle these VAR_DECLs and we don't need to stream them
> > > specially?
> > 
> > Err, rather than changing the behavior of get_namespace_binding (which
> > has many unrelated callers), I guess we could just use the already
> > import-aware lookup_qualified_name instead where appropriate.  WDYT of
> > the following? (testing in progress)
> 
> I'm going to have to think further.  Morally these VAR_DECLs are like the
> typeinfo objects -- which we have to handle specially.  Reminding myself, I
> see rtti.cc does the pushdecl_top_level stuff creating them -- so they go into
> the slot for the current TU.  But the streaming code writes
> tt_tinfo_var/tt_tinfo_typedef records, and recreates the typeinfo on stream
> in, using the same above pushdec_top_level path. So even though the tinfo
> decls might seem attached to the current module, that doesn;t confuse the
> streaming, nor create collisions on read back.  Nor do we stream out tinfo
> decls that are not reachable through the streamed AST (if we treated then as
> normal decls, we'd stream them cos they're inthe current TU in the symbol
> table.  I have the same fear for these NTTPs.)
> 
> It looks like TREE_LANG_FLAG_5 can be used to note these VAR_DECLs are NTTPs,
> and then the streaming can deal with them.  Let me look further.

I see, thanks very much for the enlightening explanation.

> 
> > @@ -7307,6 +7307,7 @@ get_template_parm_object (tree expr, tsubst_flags_t
> > complain)
> > hash_map_safe_put (tparm_obj_values, decl, copy);
> >   }
> >   +  set_originating_module (decl);
> > pushdecl_top_level_and_finish (decl, expr);
> 
> this is wrong.  You're attaching the decl to the current module. which will
> mean conflicts when reading in such VAR_DECLs for the same NTTP from different
> modules.  Your test case might be hiding that as you have an interface and
> implementation unit from the same module (but you should be getting some kind
> of multiple definition error 

Re: PING^1 [PATCH] testsuite: 'b' instruction can't do long enough jumps

[Christophe Lyon via Gcc-patches]

On 9/28/22 15:39, Torbjorn SVENSSON wrote:

Hi Christophe!

On 2022-09-28 13:55, Christophe Lyon wrote:

Hi!


On 9/28/22 11:17, Torbjorn SVENSSON via Gcc-patches wrote:

Hi,

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


Kind regards,
Torbjörn

On 2022-09-19 18:30, Torbjörn SVENSSON wrote:

After moving the testglue in commit 9d503515cee, the jump to exit and
abort is too far for the 'b' instruction on Cortex-M0. As most of the
I am not sure I understand why that commit changed the distance 
between 'exit' and the branch instruction?


The change was that the gcc_tg.o (the DejaGNU testglue.c object file) is 
now put last on the command line. In the previous versions of GCC, it 
was put before the ldflags flag etc, so now the code is placed in a way 
that the distance might be too big.


This could also be related to that we in ST are using QEMU in system 
mode and not user mode and as a result, our test environment is slightly 
larger and might perhaps be placed in between the code for the test case 
and the testglue.




Thanks, that makes sense.


C code would generate a 'bl' instruction instead of a 'b'
instruction, lets do the same for the inline assembler.

The error seen without this patch:

/tmp/cccCRiCl.o: in function `main':
stack-protector-1.c:(.text+0x4e): relocation truncated to fit: 
R_ARM_THM_JUMP11 against symbol `__wrap_exit' defined in .text 
section in gcc_tg.o
stack-protector-1.c:(.text+0x50): relocation truncated to fit: 
R_ARM_THM_JUMP11 against symbol `__wrap_abort' defined in .text 
section in gcc_tg.o

collect2: error: ld returned 1 exit status

Anyway the change seems sensible to me, I suppose it's not worth 
adding support in the linker to insert long branch stubs for these 
relocations.


If a simple 'bl' instead of 'b' is enough, I think that this trivial 
change is the right one as the test case is supposed to test the stack 
protection, not branching, right?


Yeah, agreed, I just meant to say a linker patch in addition to this one 
is probably not worth the effort.


Christophe


Kind regards,
Torbjörn



Christophe


gcc/testsuite/ChangeLog:

 * gcc/testsuite/gcc.target/arm/stack-protector-1.c: Use 'bl'
instead of 'b' instruction.
* gcc/testsuite/gcc.target/arm/stack-protector-3.c: Likewise.

Co-Authored-By: Yvan ROUX  
Signed-off-by: Torbjörn SVENSSON  
---
  gcc/testsuite/gcc.target/arm/stack-protector-1.c | 4 ++--
  gcc/testsuite/gcc.target/arm/stack-protector-3.c | 2 +-
  2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/gcc/testsuite/gcc.target/arm/stack-protector-1.c 
b/gcc/testsuite/gcc.target/arm/stack-protector-1.c

index 8d28b0a847c..3f0ffc9c3f3 100644
--- a/gcc/testsuite/gcc.target/arm/stack-protector-1.c
+++ b/gcc/testsuite/gcc.target/arm/stack-protector-1.c
@@ -56,8 +56,8 @@ asm (
  "    ldr    r1, [sp, #4]\n"
  CHECK (r1)
  "    mov    r0, #0\n"
-"    b    exit\n"
+"    bl    exit\n"
  "1:\n"
-"    b    abort\n"
+"    bl    abort\n"
  "    .size    main, .-main"
  );
diff --git a/gcc/testsuite/gcc.target/arm/stack-protector-3.c 
b/gcc/testsuite/gcc.target/arm/stack-protector-3.c

index b8f77fa2309..2f710529b8f 100644
--- a/gcc/testsuite/gcc.target/arm/stack-protector-3.c
+++ b/gcc/testsuite/gcc.target/arm/stack-protector-3.c
@@ -26,7 +26,7 @@ asm (
  "    .type    __stack_chk_fail, %function\n"
  "__stack_chk_fail:\n"
  "    movs    r0, #0\n"
-"    b    exit\n"
+"    bl    exit\n"
  "    .size    __stack_chk_fail, .-__stack_chk_fail"
  );

Re: [OG12][PATCH] OpenMP: Fix ICE with OMP metadirectives

[Tobias Burnus]

Hi Paul-Antoine, hi all,

On 28.09.22 15:47, Paul-Antoine Arras wrote:

Here is a revised patch resulting from your comments.
The only issue that I could not easily fix is the following code
triggering an ICE: [...]
I filed a PR on Bugzilla:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107067
Is it OK for you?


Thanks for the update – LGTM.

(We may want to revise some general block handling, but that's something
for either upstreaming – or even after the upstreaming hen fixing the PR.)

Two minor remarks: (a) Don't forget to update the date in the
ChangeLog.omp. (b) On can shorten bug URL by using
https://gcc.gnu.org/PR107067 which is, well, shorter. (Similarly,
https://gcc.gnu.org/g: or https://gcc.gnu.org/r... for the svn
or 'git gcc-descr [--full]' revision number also works.)

Tobias

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

Re: PING^1 [PATCH] testsuite: Do not prefix linker script with "-Wl, "

[Christophe Lyon via Gcc-patches]

On 9/28/22 11:18, Torbjorn SVENSSON via Gcc-patches wrote:

Hi,

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

Kind regards,
Torbjörn

On 2022-09-19 18:57, Torbjörn SVENSSON wrote:

The linker script should not be prefixed with "-Wl," - it's not an
input file and does not interfere with the new dump output filename
strategy.

gcc/testsuite/ChangeLog:


I think you want to mention PR testsuite/95720 since it is related?


* lib/gcc-defs.exp: Do not prefix linker script with "-Wl,".

Signed-off-by: Torbjörn SVENSSON  
---
  gcc/testsuite/lib/gcc-defs.exp | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/lib/gcc-defs.exp 
b/gcc/testsuite/lib/gcc-defs.exp

index 42ef1d85432..2102ed6f7a3 100644
--- a/gcc/testsuite/lib/gcc-defs.exp
+++ b/gcc/testsuite/lib/gcc-defs.exp
@@ -332,7 +332,7 @@ proc gcc_adjust_linker_flags_list { args } {
  continue
  } elseif { $skip != "" } then {
  set skip ""
-    } elseif { $opt == "-Xlinker" } then {
+    } elseif { $opt == "-Xlinker" || $opt == "-T" } then {
  set skip $opt
  } elseif { ![string match "-*" $opt] \
 && [file isfile $opt] } {

Re: [OG12][PATCH] OpenMP: Fix ICE with OMP metadirectives

[Paul-Antoine Arras]

Hi Tobias,

Thanks for your review.

Here is a revised patch resulting from your comments.

The only issue that I could not easily fix is the following code 
triggering an ICE:


```
   !$OMP begin metadirective &
   !$OMP   when ( user = { condition ( UseDevice ) } &
   !$OMP : nothing ) &
   !$OMP   default ( parallel )
   block
  call foo()
   end block
   call bar()   <--- ICE
   !$omp end metadirective
```

I filed a PR on Bugzilla: 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107067


Is it OK for you?
--
PAFrom 03476214bda71c6581b7978cf9fd5b701896a052 Mon Sep 17 00:00:00 2001
From: Paul-Antoine Arras 
Date: Wed, 21 Sep 2022 15:52:56 +
Subject: [PATCH] OpenMP: Fix ICE with OMP metadirectives

Problem: ending an OpenMP metadirective block with an OMP end statement
results in an internal compiler error.
Solution: reject invalid end statements and issue a proper diagnostic.

This revision also fixes a couple of minor metadirective issues and adds
related test cases.

gcc/fortran/ChangeLog:

* parse.cc (gfc_ascii_statement): Missing $ in !$OMP END METADIRECTIVE.
(parse_omp_structured_block): Fix handling of OMP end metadirective.
(parse_omp_metadirective_body): Reject OMP end statements
at the end of an OMP metadirective.

gcc/testsuite/ChangeLog:

* gfortran.dg/gomp/metadirective-1.f90: Match !$OMP END METADIRECTIVE.
* gfortran.dg/gomp/metadirective-10.f90: New test.
* gfortran.dg/gomp/metadirective-11.f90: New xfail test.
* gfortran.dg/gomp/metadirective-9.f90: New test.
---
 gcc/fortran/ChangeLog.omp |  7 
 gcc/fortran/parse.cc  | 32 ++-
 gcc/testsuite/ChangeLog.omp   |  7 
 .../gfortran.dg/gomp/metadirective-1.f90  |  2 +-
 .../gfortran.dg/gomp/metadirective-10.f90 | 40 +++
 .../gfortran.dg/gomp/metadirective-11.f90 | 33 +++
 .../gfortran.dg/gomp/metadirective-9.f90  | 30 ++
 7 files changed, 141 insertions(+), 10 deletions(-)
 create mode 100644 gcc/testsuite/gfortran.dg/gomp/metadirective-10.f90
 create mode 100644 gcc/testsuite/gfortran.dg/gomp/metadirective-11.f90
 create mode 100644 gcc/testsuite/gfortran.dg/gomp/metadirective-9.f90

diff --git gcc/fortran/ChangeLog.omp gcc/fortran/ChangeLog.omp
index 8c89cd5bd43..14f897e8fec 100644
--- gcc/fortran/ChangeLog.omp
+++ gcc/fortran/ChangeLog.omp
@@ -1,3 +1,10 @@
+2022-09-21  Paul-Antoine Arras  
+
+   * parse.cc (gfc_ascii_statement): Missing $ in !$OMP END METADIRECTIVE.
+   (parse_omp_structured_block): Fix handling of OMP end metadirective.
+   (parse_omp_metadirective_body): Reject OMP end statements
+   at the end of an OMP metadirective.
+
 2022-09-09  Tobias Burnus  
 
Backport from mainline:
diff --git gcc/fortran/parse.cc gcc/fortran/parse.cc
index b35d76a4f6b..fc88111a7ad 100644
--- gcc/fortran/parse.cc
+++ gcc/fortran/parse.cc
@@ -2517,7 +2517,7 @@ gfc_ascii_statement (gfc_statement st)
   p = "!$OMP END MASTER TASKLOOP SIMD";
   break;
 case ST_OMP_END_METADIRECTIVE:
-  p = "!OMP END METADIRECTIVE";
+  p = "!$OMP END METADIRECTIVE";
   break;
 case ST_OMP_END_ORDERED:
   p = "!$OMP END ORDERED";
@@ -5643,9 +5643,15 @@ parse_omp_structured_block (gfc_statement omp_st, bool 
workshare_stmts_only)
   np->block = NULL;
 
   omp_end_st = gfc_omp_end_stmt (omp_st, false, true);
-  if (omp_st == ST_NONE)
+  if (omp_end_st == ST_NONE)
 gcc_unreachable ();
 
+  /* If handling a metadirective variant, treat 'omp end metadirective'
+ as the expected end statement for the current construct.  */
+  if (gfc_state_stack->previous != NULL
+  && gfc_state_stack->previous->state == COMP_OMP_BEGIN_METADIRECTIVE)
+omp_end_st = ST_OMP_END_METADIRECTIVE;
+
   bool block_construct = false;
   gfc_namespace *my_ns = NULL;
   gfc_namespace *my_parent = NULL;
@@ -5744,13 +5750,6 @@ parse_omp_structured_block (gfc_statement omp_st, bool 
workshare_stmts_only)
   else
st = parse_executable (st);
 
-  /* If handling a metadirective variant, treat 'omp end metadirective'
-as the expected end statement for the current construct.  */
-  if (st == ST_OMP_END_METADIRECTIVE
- && gfc_state_stack->previous != NULL
- && gfc_state_stack->previous->state == COMP_OMP_BEGIN_METADIRECTIVE)
-   st = omp_end_st;
-
   if (st == ST_NONE)
unexpected_eof ();
   else if (st == ST_OMP_SECTION
@@ -5863,6 +5862,21 @@ parse_omp_metadirective_body (gfc_statement omp_st)
  break;
}
 
+  if (gfc_state_stack->state == COMP_OMP_METADIRECTIVE
+ && startswith (gfc_ascii_statement (st), "!$OMP END "))
+   {
+ for (gfc_state_data *p = gfc_state_stack; p; p = p->previous)
+   if (p->state == COMP_OMP_STRUCTURED_BLOCK
+   || p->state == COMP_OMP_BEGIN_METADIRECTIVE)
+ goto finish;
+ 

Re: PING^1 [PATCH] testsuite: 'b' instruction can't do long enough jumps

[Torbjorn SVENSSON via Gcc-patches]

Hi Christophe!

On 2022-09-28 13:55, Christophe Lyon wrote:

Hi!


On 9/28/22 11:17, Torbjorn SVENSSON via Gcc-patches wrote:

Hi,

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


Kind regards,
Torbjörn

On 2022-09-19 18:30, Torbjörn SVENSSON wrote:

After moving the testglue in commit 9d503515cee, the jump to exit and
abort is too far for the 'b' instruction on Cortex-M0. As most of the
I am not sure I understand why that commit changed the distance between 
'exit' and the branch instruction?


The change was that the gcc_tg.o (the DejaGNU testglue.c object file) is 
now put last on the command line. In the previous versions of GCC, it 
was put before the ldflags flag etc, so now the code is placed in a way 
that the distance might be too big.


This could also be related to that we in ST are using QEMU in system 
mode and not user mode and as a result, our test environment is slightly 
larger and might perhaps be placed in between the code for the test case 
and the testglue.



C code would generate a 'bl' instruction instead of a 'b'
instruction, lets do the same for the inline assembler.

The error seen without this patch:

/tmp/cccCRiCl.o: in function `main':
stack-protector-1.c:(.text+0x4e): relocation truncated to fit: 
R_ARM_THM_JUMP11 against symbol `__wrap_exit' defined in .text 
section in gcc_tg.o
stack-protector-1.c:(.text+0x50): relocation truncated to fit: 
R_ARM_THM_JUMP11 against symbol `__wrap_abort' defined in .text 
section in gcc_tg.o

collect2: error: ld returned 1 exit status

Anyway the change seems sensible to me, I suppose it's not worth adding 
support in the linker to insert long branch stubs for these relocations.


If a simple 'bl' instead of 'b' is enough, I think that this trivial 
change is the right one as the test case is supposed to test the stack 
protection, not branching, right?


Kind regards,
Torbjörn



Christophe


gcc/testsuite/ChangeLog:

 * gcc/testsuite/gcc.target/arm/stack-protector-1.c: Use 'bl'
instead of 'b' instruction.
* gcc/testsuite/gcc.target/arm/stack-protector-3.c: Likewise.

Co-Authored-By: Yvan ROUX  
Signed-off-by: Torbjörn SVENSSON  
---
  gcc/testsuite/gcc.target/arm/stack-protector-1.c | 4 ++--
  gcc/testsuite/gcc.target/arm/stack-protector-3.c | 2 +-
  2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/gcc/testsuite/gcc.target/arm/stack-protector-1.c 
b/gcc/testsuite/gcc.target/arm/stack-protector-1.c

index 8d28b0a847c..3f0ffc9c3f3 100644
--- a/gcc/testsuite/gcc.target/arm/stack-protector-1.c
+++ b/gcc/testsuite/gcc.target/arm/stack-protector-1.c
@@ -56,8 +56,8 @@ asm (
  "    ldr    r1, [sp, #4]\n"
  CHECK (r1)
  "    mov    r0, #0\n"
-"    b    exit\n"
+"    bl    exit\n"
  "1:\n"
-"    b    abort\n"
+"    bl    abort\n"
  "    .size    main, .-main"
  );
diff --git a/gcc/testsuite/gcc.target/arm/stack-protector-3.c 
b/gcc/testsuite/gcc.target/arm/stack-protector-3.c

index b8f77fa2309..2f710529b8f 100644
--- a/gcc/testsuite/gcc.target/arm/stack-protector-3.c
+++ b/gcc/testsuite/gcc.target/arm/stack-protector-3.c
@@ -26,7 +26,7 @@ asm (
  "    .type    __stack_chk_fail, %function\n"
  "__stack_chk_fail:\n"
  "    movs    r0, #0\n"
-"    b    exit\n"
+"    bl    exit\n"
  "    .size    __stack_chk_fail, .-__stack_chk_fail"
  );

Re: [PATCH V2] place `const volatile' objects in read-only sections

[Koning, Paul via Gcc-patches]

> On Sep 27, 2022, at 8:51 PM, Jeff Law via Gcc-patches 
>  wrote:
> 
> 
> On 8/5/22 05:41, Jose E. Marchesi via Gcc-patches wrote:
>> [Changes from V1:
>> - Added a test.]
>> 
>> It is common for C BPF programs to use variables that are implicitly
>> set by the BPF loader and run-time.  It is also necessary for these
>> variables to be stored in read-only storage so the BPF verifier
>> recognizes them as such.  This leads to declarations using both
>> `const' and `volatile' qualifiers, like this:
>> 
>>   const volatile unsigned char is_allow_list = 0;
>> 
>> Where `volatile' is used to avoid the compiler to optimize out the
>> variable, or turn it into a constant, and `const' to make sure it is
>> placed in .rodata.
>> 
>> Now, it happens that:
>> 
>> - GCC places `const volatile' objects in the .data section, under the
>>   assumption that `volatile' somehow voids the `const'.
>> 
>> - LLVM places `const volatile' objects in .rodata, under the
>>   assumption that `volatile' is orthogonal to `const'.
>> ...
> 
> The best use I've heard for const volatile is stuff like hardware status 
> registers which are readonly from the standpoint of the compiler, but which 
> are changed by the hardware.   But for those, we're looking for the const to 
> trigger compiler diagnostics if we try to write the value.  The volatile (of 
> course) indicates the value changes behind our back.

I'd go a bit further and say that this is the only use of const volatile that 
makes any sense.

> What you're trying to do seems to parallel that case reasonably well for the 
> volatile aspect.  You want to force the compiler to read the data for every 
> access.
> 
> Your need for the const is a bit different.  Instead of looking to get a 
> diagnostic out of the compiler if its modified, you need the data to live in 
> .rodata so the BPF verifier knows the compiler/code won't change the value.  
> Presumably the BPF verifier can't read debug info to determine the const-ness.
> 
> I'm not keen on the behavior change, but nobody else is stepping in to review 
> and I don't have a strong case to reject.  So OK for the trunk.

A const volatile that sits in memory feels like a programmer error.  Instead of 
worrying about how it's handled, would it not make more sense to tag it with a 
warning?

paul

Re: [PATCH] arm: Define __ARM_FEATURE_AES and __ARM_FEATURE_SHA2 when march +crypto is selected

[Andrea Corallo via Gcc-patches]

Kyrylo Tkachov  writes:

> Hi Andrea,
>
>> -Original Message-
>> From: Andrea Corallo 
>> Sent: Wednesday, September 28, 2022 1:19 PM
>> To: gcc-patches@gcc.gnu.org
>> Cc: Kyrylo Tkachov ; Richard Earnshaw
>> ; Andrea Corallo 
>> Subject: [PATCH] arm: Define __ARM_FEATURE_AES and
>> __ARM_FEATURE_SHA2 when march +crypto is selected
>> 
>> Hi all,
>> 
>> this patch fixes the missing definition of __ARM_FEATURE_AES and
>> __ARM_FEATURE_SHA2 when AES SHA1 & SHA2 crypto instructions are
>> available [1] (read when march +crypto is selected).
>> 
>> Okay for master?
>
> Ok.
> Thanks,
> Kyrill

Into trunk as 5e9c4ed903c.

Thanks!

  Andrea

[PATCH] OpenACC: whole struct vs. component mappings (PR107028)

[Julian Brown]

This patch fixes an ICE when both a complete struct variable and
components of that struct are mapped on the same directive for OpenACC,
using a modified version of the scheme used for OpenMP in the following
patch:

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

A new function has been added to make sure that the mapping kinds of
the whole struct and the member access are compatible -- conservatively,
so as not to copy more to/from the device than the user expects.

Tested with offloading to NVPTX. OK?

Thanks,

Julian

2022-09-28  Julian Brown  

gcc/
PR middle-end/107028
* gimplify.cc (omp_group_base): Fix IF_PRESENT handling.
(omp_check_mapping_compatibility, oacc_resolve_clause_dependencies):
New functions.
(build_struct_sibling_lists): Skip deleted groups.  Don't build sibling
list for struct variables that are fully mapped on the same directive
for OpenACC.
(gimplify_scan_omp_clauses): Call oacc_resolve_clause_dependencies.

gcc/testsuite/
PR middle-end/107028
* c-c++-common/goacc/struct-component-kind-1.c: New test.
* g++.dg/goacc/pr107028-1.C: New test.
* g++.dg/goacc/pr107028-2.C: New test.
---
 gcc/gimplify.cc   | 129 +-
 .../goacc/struct-component-kind-1.c   |  72 ++
 gcc/testsuite/g++.dg/goacc/pr107028-1.C   |  14 ++
 gcc/testsuite/g++.dg/goacc/pr107028-2.C   |  27 
 4 files changed, 235 insertions(+), 7 deletions(-)
 create mode 100644 gcc/testsuite/c-c++-common/goacc/struct-component-kind-1.c
 create mode 100644 gcc/testsuite/g++.dg/goacc/pr107028-1.C
 create mode 100644 gcc/testsuite/g++.dg/goacc/pr107028-2.C

diff --git a/gcc/gimplify.cc b/gcc/gimplify.cc
index 4d032c6bf06..7fc1d38644a 100644
--- a/gcc/gimplify.cc
+++ b/gcc/gimplify.cc
@@ -9245,6 +9245,7 @@ omp_group_base (omp_mapping_group *grp, unsigned int 
*chained,
 case GOMP_MAP_RELEASE:
 case GOMP_MAP_DELETE:
 case GOMP_MAP_FORCE_ALLOC:
+case GOMP_MAP_IF_PRESENT:
   if (node == grp->grp_end)
return node;
 
@@ -9323,7 +9324,6 @@ omp_group_base (omp_mapping_group *grp, unsigned int 
*chained,
 case GOMP_MAP_FORCE_DEVICEPTR:
 case GOMP_MAP_DEVICE_RESIDENT:
 case GOMP_MAP_LINK:
-case GOMP_MAP_IF_PRESENT:
 case GOMP_MAP_FIRSTPRIVATE:
 case GOMP_MAP_FIRSTPRIVATE_INT:
 case GOMP_MAP_USE_DEVICE_PTR:
@@ -9861,6 +9861,115 @@ omp_lastprivate_for_combined_outer_constructs (struct 
gimplify_omp_ctx *octx,
 omp_notice_variable (octx, decl, true);
 }
 
+/* If we have mappings INNER and OUTER, where INNER is a component access and
+   OUTER is a mapping of the whole containing struct, check that the mappings
+   are compatible.  We'll be deleting the inner mapping, so we need to make
+   sure the outer mapping does (at least) the same transfers to/from the device
+   as the inner mapping.  */
+
+bool
+omp_check_mapping_compatibility (location_t loc,
+omp_mapping_group *outer,
+omp_mapping_group *inner)
+{
+  tree first_outer = *outer->grp_start, first_inner = *inner->grp_start;
+
+  gcc_assert (OMP_CLAUSE_CODE (first_outer) == OMP_CLAUSE_MAP);
+  gcc_assert (OMP_CLAUSE_CODE (first_inner) == OMP_CLAUSE_MAP);
+
+  enum gomp_map_kind outer_kind = OMP_CLAUSE_MAP_KIND (first_outer);
+  enum gomp_map_kind inner_kind = OMP_CLAUSE_MAP_KIND (first_inner);
+
+  if (outer_kind == inner_kind)
+return true;
+
+  switch (outer_kind)
+{
+case GOMP_MAP_ALWAYS_TO:
+  if (inner_kind == GOMP_MAP_FORCE_PRESENT
+ || inner_kind == GOMP_MAP_ALLOC
+ || inner_kind == GOMP_MAP_TO)
+   return true;
+  break;
+
+case GOMP_MAP_ALWAYS_FROM:
+  if (inner_kind == GOMP_MAP_FORCE_PRESENT
+ || inner_kind == GOMP_MAP_ALLOC
+ || inner_kind == GOMP_MAP_FROM)
+   return true;
+  break;
+
+case GOMP_MAP_TO:
+case GOMP_MAP_FROM:
+  if (inner_kind == GOMP_MAP_FORCE_PRESENT
+ || inner_kind == GOMP_MAP_ALLOC)
+   return true;
+  break;
+
+case GOMP_MAP_ALWAYS_TOFROM:
+case GOMP_MAP_TOFROM:
+  if (inner_kind == GOMP_MAP_FORCE_PRESENT
+ || inner_kind == GOMP_MAP_ALLOC
+ || inner_kind == GOMP_MAP_TO
+ || inner_kind == GOMP_MAP_FROM
+ || inner_kind == GOMP_MAP_TOFROM)
+   return true;
+  break;
+
+default:
+  ;
+}
+
+  error_at (loc, "data movement for component %qE is not compatible with "
+   "movement for struct %qE", OMP_CLAUSE_DECL (first_inner),
+   OMP_CLAUSE_DECL (first_outer));
+
+  return false;
+}
+
+/* Similar to the above function, but for OpenACC.  The only clause
+   dependencies we handle for now are struct element mappings and whole-struct
+   mappings on the same directive.  */
+
+void
+oacc_resolve_clause_dependencies (vec *groups,
+ hash_map *grpmap)
+{
+  

RE: [PATCH 1/2]middle-end Fold BIT_FIELD_REF and Shifts into BIT_FIELD_REFs alone

[Tamar Christina via Gcc-patches]

> -Original Message-
> From: Jeff Law 
> Sent: Saturday, September 24, 2022 8:38 PM
> To: Tamar Christina ; gcc-patches@gcc.gnu.org
> Cc: nd ; rguent...@suse.de
> Subject: Re: [PATCH 1/2]middle-end Fold BIT_FIELD_REF and Shifts into
> BIT_FIELD_REFs alone
> 
> 
> On 9/23/22 05:42, Tamar Christina wrote:
> > Hi All,
> >
> > This adds a match.pd rule that can fold right shifts and
> > bit_field_refs of integers into just a bit_field_ref by adjusting the
> > offset and the size of the extract and adds an extend to the previous size.
> >
> > Concretely turns:
> >
> > #include 
> >
> > unsigned int foor (uint32x4_t x)
> > {
> >  return x[1] >> 16;
> > }
> >
> > which used to generate:
> >
> >_1 = BIT_FIELD_REF ;
> >_3 = _1 >> 16;
> >
> > into
> >
> >_4 = BIT_FIELD_REF ;
> >_2 = (unsigned int) _4;
> >
> > I currently limit the rewrite to only doing it if the resulting
> > extract is in a mode the target supports. i.e. it won't rewrite it to
> > extract say 13-bits because I worry that for targets that won't have a
> > bitfield extract instruction this may be a de-optimization.
> >
> > Bootstrapped Regtested on aarch64-none-linux-gnu, x86_64-pc-linux-gnu
> > and no issues.
> >
> > Testcase are added in patch 2/2.
> >
> > Ok for master?
> >
> > Thanks,
> > Tamar
> >
> > gcc/ChangeLog:
> >
> > * match.pd: Add bitfield and shift folding.
> 
> Were you planning to handle left shifts as well?  It looks like it since 
> you've
> got iterations for the shift opcode and corresponding adjustment to the field,
> but they currently only handle rshift/plus.
> 

Hmm do left shifts work here? Since a left shift would increase the size of the
resulting value by adding zeros to the end of the number, so you can't increase
the size of the bitfield to do the same.

I did however realize that truncating casts have the same effect as a right 
shift,
so I have added that now.

Tamar

> 
> Jeff
> 

Re: [Patch] libgomp/nvptx: Prepare for reverse-offload callback handling

[Alexander Monakov via Gcc-patches]

On Tue, 27 Sep 2022, Tobias Burnus wrote:

> Ignoring (1), does the overall patch and this part otherwise look okay(ish)?
> 
> 
> Caveat: The .sys scope works well with >= sm_60 but not does not handle
> older versions. For those, the __atomic_{load/store}_n are used.  I do not
> see a good solution beyond documentation. In the way it is used (one
> thread only setting only on/off flag, no atomic increments etc.), I think
> it is unlikely to cause races without .sys scope, but as always is
> difficult to rule out some special unfortunate case where it does. At
> lease we do have now some documentation (in general) - which still needs
> to be expanded and improved.  For this feature, I did not add any wording
> in this patch: until the feature is actually enabled, it would be more
> confusing than helpful.

If the implication is that distros will ship a racy-by-default implementation,
unless they know about the problem and configure for sm_60, then no, that
doesn't look fine to me. A possible solution is not enabling a feature that
has a known correctness issue.

Alexander

RE: [PATCH] arm: Define __ARM_FEATURE_AES and __ARM_FEATURE_SHA2 when march +crypto is selected

[Kyrylo Tkachov via Gcc-patches]

Hi Andrea,

> -Original Message-
> From: Andrea Corallo 
> Sent: Wednesday, September 28, 2022 1:19 PM
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov ; Richard Earnshaw
> ; Andrea Corallo 
> Subject: [PATCH] arm: Define __ARM_FEATURE_AES and
> __ARM_FEATURE_SHA2 when march +crypto is selected
> 
> Hi all,
> 
> this patch fixes the missing definition of __ARM_FEATURE_AES and
> __ARM_FEATURE_SHA2 when AES SHA1 & SHA2 crypto instructions are
> available [1] (read when march +crypto is selected).
> 
> Okay for master?

Ok.
Thanks,
Kyrill

> 
> Thanks
> 
>   Andrea
> 
> [1]  software/acle/main/main/acle.md>
> 
> /gcc/ChangeLog
> 
> 2022-09-14  Andrea Corallo  
> 
>   * config/arm/arm-c.cc (arm_cpu_builtins): Define
>   __ARM_FEATURE_AES and __ARM_FEATURE_SHA2.
> 
> gcc/testsuite/ChangeLog
> 
> 2022-09-14  Andrea Corallo  
> 
>   * gcc.target/arm/attr-crypto.c: Update test.
> ---
>  gcc/config/arm/arm-c.cc| 2 ++
>  gcc/testsuite/gcc.target/arm/attr-crypto.c | 8 
>  2 files changed, 10 insertions(+)
> 
> diff --git a/gcc/config/arm/arm-c.cc b/gcc/config/arm/arm-c.cc
> index a8697b8c62f..86c56bf2680 100644
> --- a/gcc/config/arm/arm-c.cc
> +++ b/gcc/config/arm/arm-c.cc
> @@ -202,6 +202,8 @@ arm_cpu_builtins (struct cpp_reader* pfile)
>def_or_undef_macro (pfile, "__ARM_FEATURE_QBIT",
> TARGET_ARM_QBIT);
>def_or_undef_macro (pfile, "__ARM_FEATURE_SAT", TARGET_ARM_SAT);
>def_or_undef_macro (pfile, "__ARM_FEATURE_CRYPTO",
> TARGET_CRYPTO);
> +  def_or_undef_macro (pfile, "__ARM_FEATURE_AES", TARGET_CRYPTO);
> +  def_or_undef_macro (pfile, "__ARM_FEATURE_SHA2", TARGET_CRYPTO);
> 
>def_or_undef_macro (pfile, "__ARM_FEATURE_UNALIGNED",
> unaligned_access);
> 
> diff --git a/gcc/testsuite/gcc.target/arm/attr-crypto.c
> b/gcc/testsuite/gcc.target/arm/attr-crypto.c
> index cbd13a757d8..05e458f36b6 100644
> --- a/gcc/testsuite/gcc.target/arm/attr-crypto.c
> +++ b/gcc/testsuite/gcc.target/arm/attr-crypto.c
> @@ -16,6 +16,14 @@
>  #error __ARM_FEATURE_CRYPTO not defined.
>  #endif
> 
> +#ifndef __ARM_FEATURE_AES
> +#error __ARM_FEATURE_AES not defined.
> +#endif
> +
> +#ifndef __ARM_FEATURE_SHA2
> +#error __ARM_FEATURE_SHA2 not defined.
> +#endif
> +
>  #ifndef __ARM_NEON
>  #error __ARM_NEON not defined.
>  #endif
> --
> 2.25.1

[PATCH] arm: Define __ARM_FEATURE_AES and __ARM_FEATURE_SHA2 when march +crypto is selected

[Andrea Corallo via Gcc-patches]

Hi all,

this patch fixes the missing definition of __ARM_FEATURE_AES and
__ARM_FEATURE_SHA2 when AES SHA1 & SHA2 crypto instructions are
available [1] (read when march +crypto is selected).

Okay for master?

Thanks

  Andrea

[1] 

/gcc/ChangeLog

2022-09-14  Andrea Corallo  

* config/arm/arm-c.cc (arm_cpu_builtins): Define
__ARM_FEATURE_AES and __ARM_FEATURE_SHA2.

gcc/testsuite/ChangeLog

2022-09-14  Andrea Corallo  

* gcc.target/arm/attr-crypto.c: Update test.
---
 gcc/config/arm/arm-c.cc| 2 ++
 gcc/testsuite/gcc.target/arm/attr-crypto.c | 8 
 2 files changed, 10 insertions(+)

diff --git a/gcc/config/arm/arm-c.cc b/gcc/config/arm/arm-c.cc
index a8697b8c62f..86c56bf2680 100644
--- a/gcc/config/arm/arm-c.cc
+++ b/gcc/config/arm/arm-c.cc
@@ -202,6 +202,8 @@ arm_cpu_builtins (struct cpp_reader* pfile)
   def_or_undef_macro (pfile, "__ARM_FEATURE_QBIT", TARGET_ARM_QBIT);
   def_or_undef_macro (pfile, "__ARM_FEATURE_SAT", TARGET_ARM_SAT);
   def_or_undef_macro (pfile, "__ARM_FEATURE_CRYPTO", TARGET_CRYPTO);
+  def_or_undef_macro (pfile, "__ARM_FEATURE_AES", TARGET_CRYPTO);
+  def_or_undef_macro (pfile, "__ARM_FEATURE_SHA2", TARGET_CRYPTO);
 
   def_or_undef_macro (pfile, "__ARM_FEATURE_UNALIGNED", unaligned_access);
 
diff --git a/gcc/testsuite/gcc.target/arm/attr-crypto.c 
b/gcc/testsuite/gcc.target/arm/attr-crypto.c
index cbd13a757d8..05e458f36b6 100644
--- a/gcc/testsuite/gcc.target/arm/attr-crypto.c
+++ b/gcc/testsuite/gcc.target/arm/attr-crypto.c
@@ -16,6 +16,14 @@
 #error __ARM_FEATURE_CRYPTO not defined.
 #endif
 
+#ifndef __ARM_FEATURE_AES
+#error __ARM_FEATURE_AES not defined.
+#endif
+
+#ifndef __ARM_FEATURE_SHA2
+#error __ARM_FEATURE_SHA2 not defined.
+#endif
+
 #ifndef __ARM_NEON
 #error __ARM_NEON not defined.
 #endif
-- 
2.25.1

Re: PING^1 [PATCH] testsuite: 'b' instruction can't do long enough jumps

[Christophe Lyon via Gcc-patches]

Hi!


On 9/28/22 11:17, Torbjorn SVENSSON via Gcc-patches wrote:

Hi,

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

Kind regards,
Torbjörn

On 2022-09-19 18:30, Torbjörn SVENSSON wrote:

After moving the testglue in commit 9d503515cee, the jump to exit and
abort is too far for the 'b' instruction on Cortex-M0. As most of the
I am not sure I understand why that commit changed the distance between 
'exit' and the branch instruction?



C code would generate a 'bl' instruction instead of a 'b'
instruction, lets do the same for the inline assembler.

The error seen without this patch:

/tmp/cccCRiCl.o: in function `main':
stack-protector-1.c:(.text+0x4e): relocation truncated to fit: 
R_ARM_THM_JUMP11 against symbol `__wrap_exit' defined in .text section 
in gcc_tg.o
stack-protector-1.c:(.text+0x50): relocation truncated to fit: 
R_ARM_THM_JUMP11 against symbol `__wrap_abort' defined in .text 
section in gcc_tg.o

collect2: error: ld returned 1 exit status

Anyway the change seems sensible to me, I suppose it's not worth adding 
support in the linker to insert long branch stubs for these relocations.


Christophe


gcc/testsuite/ChangeLog:

 * gcc/testsuite/gcc.target/arm/stack-protector-1.c: Use 'bl'
instead of 'b' instruction.
* gcc/testsuite/gcc.target/arm/stack-protector-3.c: Likewise.

Co-Authored-By: Yvan ROUX  
Signed-off-by: Torbjörn SVENSSON  
---
  gcc/testsuite/gcc.target/arm/stack-protector-1.c | 4 ++--
  gcc/testsuite/gcc.target/arm/stack-protector-3.c | 2 +-
  2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/gcc/testsuite/gcc.target/arm/stack-protector-1.c 
b/gcc/testsuite/gcc.target/arm/stack-protector-1.c

index 8d28b0a847c..3f0ffc9c3f3 100644
--- a/gcc/testsuite/gcc.target/arm/stack-protector-1.c
+++ b/gcc/testsuite/gcc.target/arm/stack-protector-1.c
@@ -56,8 +56,8 @@ asm (
  "    ldr    r1, [sp, #4]\n"
  CHECK (r1)
  "    mov    r0, #0\n"
-"    b    exit\n"
+"    bl    exit\n"
  "1:\n"
-"    b    abort\n"
+"    bl    abort\n"
  "    .size    main, .-main"
  );
diff --git a/gcc/testsuite/gcc.target/arm/stack-protector-3.c 
b/gcc/testsuite/gcc.target/arm/stack-protector-3.c

index b8f77fa2309..2f710529b8f 100644
--- a/gcc/testsuite/gcc.target/arm/stack-protector-3.c
+++ b/gcc/testsuite/gcc.target/arm/stack-protector-3.c
@@ -26,7 +26,7 @@ asm (
  "    .type    __stack_chk_fail, %function\n"
  "__stack_chk_fail:\n"
  "    movs    r0, #0\n"
-"    b    exit\n"
+"    bl    exit\n"
  "    .size    __stack_chk_fail, .-__stack_chk_fail"
  );

RE: [PATCH][committed] aarch64: Add Arm Neoverse V2 support

[Kyrylo Tkachov via Gcc-patches]

> -Original Message-
> From: Gcc-patches  bounces+kyrylo.tkachov=arm@gcc.gnu.org> On Behalf Of Kyrylo
> Tkachov via Gcc-patches
> Sent: Friday, September 23, 2022 12:11 PM
> To: gcc-patches@gcc.gnu.org
> Subject: [PATCH][committed] aarch64: Add Arm Neoverse V2 support
> 
> Hi all,
> 
> This patch adds -mcpu/-mtune support for the Arm Neoverse V2 core.
> This updates the internal references to "demeter", but leaves "demeter" as
> an
> accepted value to -mcpu/-mtune as it appears in the released GCC 12 series.
> 
> Bootstrapped and tested on aarch64-none-linux-gnu.
> Pushing to trunk.

This applies, bootstraps and tests cleanly on GCC 12 so I've pushed it to that 
branch too.
Thanks,
Kyrill

> Thanks,
> Kyrill
> 
> gcc/ChangeLog:
> 
>   * config/aarch64/aarch64-cores.def (neoverse-v2): New entry.
>   (demeter): Update tunings to neoversev2.
>   * config/aarch64/aarch64-tune.md: Regenerate.
>   * config/aarch64/aarch64.cc (demeter_addrcost_table): Rename to
>   neoversev2_addrcost_table.
>   (demeter_regmove_cost): Rename to neoversev2_addrcost_table.
>   (demeter_advsimd_vector_cost): Rename to
> neoversev2_advsimd_vector_cost.
>   (demeter_sve_vector_cost): Rename to neoversev2_sve_vector_cost.
>   (demeter_scalar_issue_info): Rename to
> neoversev2_scalar_issue_info.
>   (demeter_advsimd_issue_info): Rename to
> neoversev2_advsimd_issue_info.
>   (demeter_sve_issue_info): Rename to neoversev2_sve_issue_info.
>   (demeter_vec_issue_info): Rename to neoversev2_vec_issue_info.
>   Update references to above.
>   (demeter_vector_cost): Rename to neoversev2_vector_cost.
>   (demeter_tunings): Rename to neoversev2_tunings.
>   (aarch64_vec_op_count::rename_cycles_per_iter): Use
>   neoversev2_sve_issue_info instead of demeter_sve_issue_info.
>   * doc/invoke.texi (AArch64 Options): Document neoverse-v2.

Re: [wwwdocs][patch] gcc-13/changes.html: Add nvptx's --with-arch

[Gerald Pfeifer]

Hi Tobias,

On Wed, 28 Sep 2022, Tobias Burnus wrote:
> The attached patch documents the new nvptx configure flag 
> --with-arch=sm_...
> 
> Comments? OK?

where it reads

+  https://gcc.gnu.org/install/specific.html#nvptx-x-none;>
+  --with-arch= flag; if not specified, GCC defaults to
+  sm_30. GCC's target libraries are build both with
+  sm_30 and the specified target architecture.

I suggest "configure option" instead of "flag" (if that's it, of course). 
 
And I'd start the following as a full sentence "If not specified", or in 
fact omit it, since "GCC defaults" already implies "If not specified"?

"are build" -> "are then built", and switch the last two sentences?

Okay with those changes (or telling me I'm wrong ;-).

Gerald

Re: [PATCH] Teach vectorizer to deal with bitfield accesses (was: [RFC] Teach vectorizer to deal with bitfield reads)

[Andre Vieira (lists) via Gcc-patches]

On 27/09/2022 13:34, Richard Biener wrote:

On Mon, 26 Sep 2022, Andre Vieira (lists) wrote:


On 08/09/2022 12:51, Richard Biener wrote:

I'm curious, why the push to redundant_ssa_names?  That could use
a comment ...

So I purposefully left a #if 0 #else #endif in there so you can see the two
options. But the reason I used redundant_ssa_names is because ifcvt seems to
use that as a container for all pairs of (old, new) ssa names to replace
later. So I just piggy backed on that. I don't know if there's a specific
reason they do the replacement at the end? Maybe some ordering issue? Either
way both adding it to redundant_ssa_names or doing the replacement inline work
for the bitfield lowering (or work in my testing at least).

Possibly because we (in the past?) inserted/copied stuff based on
predicates generated at analysis time after we decide to elide something
so we need to watch for later appearing uses.  But who knows ... my mind
fails me here.

If it works to replace uses immediately please do so.  But now
I wonder why we need this - the value shouldn't change so you
should get away with re-using the existing SSA name for the final value?


Yeah... good point. A quick change and minor testing seems to agree. I'm sure I 
had a good reason to do it initially ;)

I'll run a full-regression on this change to make sure I didn't miss anything.

Re: [Documentation] Correct RTL documentation: (use (mem ...)) is allowed.

[Uros Bizjak via Gcc-patches]

> > This patch is a one line correction/clarification to GCC's current
> > RTL documentation that explains a USE of a MEM is permissible.
> >
> > PR rtl-optimization/99930 is an interesting example on x86_64 where
> > the backend generates better code when a USE is a (const) MEM than
> > when it is a REG. In fact the backend relies on CSE to propagate the
> > MEM (a constant pool reference) into the USE, to enable combine to
> > merge/simplify instructions.
> >
> > This change has been tested with a make bootstrap, but as it might
> > provoke a discussion, I've decided to not consider it "obvious".
> > Ok for mainline (to document the actual current behavior)?
> >
> >
> > 2022-07-23  Roger Sayle   
> >
> > gcc/ChangeLog
> >  * doc/rtl.texi (use): Document that the operand may be a MEM.
>
> Given this is documenting existing behavior and it's not hard to
> envision the MEM being useful in this context.  OK.

I would like to point out at this occasion that there are some issues
with (use (mem)) when commutative operands are used. PR95218 has a
testcase where the postreload pass simply removed the instruction (see
comment #6). It was later found out in comment #17 that commutative
operands in (use (...)) statements somehow confuse postreload pass. I
have to remove commutative operands from (use (...)) to solve the
issue, so either this unfortunate fact should be mentioned in the
documentation or the limitation (bug?) should be fixed in the
postreload pass.

Uros.

PING^1 [PATCH] testsuite: Do not prefix linker script with "-Wl,"

[Torbjorn SVENSSON via Gcc-patches]

Hi,

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

Kind regards,
Torbjörn

On 2022-09-19 18:57, Torbjörn SVENSSON wrote:

The linker script should not be prefixed with "-Wl," - it's not an
input file and does not interfere with the new dump output filename
strategy.

gcc/testsuite/ChangeLog:

* lib/gcc-defs.exp: Do not prefix linker script with "-Wl,".

Signed-off-by: Torbjörn SVENSSON  
---
  gcc/testsuite/lib/gcc-defs.exp | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/lib/gcc-defs.exp b/gcc/testsuite/lib/gcc-defs.exp
index 42ef1d85432..2102ed6f7a3 100644
--- a/gcc/testsuite/lib/gcc-defs.exp
+++ b/gcc/testsuite/lib/gcc-defs.exp
@@ -332,7 +332,7 @@ proc gcc_adjust_linker_flags_list { args } {
continue
} elseif { $skip != "" } then {
set skip ""
-   } elseif { $opt == "-Xlinker" } then {
+   } elseif { $opt == "-Xlinker" || $opt == "-T" } then {
set skip $opt
} elseif { ![string match "-*" $opt] \
   && [file isfile $opt] } {

PING^1 [PATCH] testsuite: 'b' instruction can't do long enough jumps

[Torbjorn SVENSSON via Gcc-patches]

Hi,

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

Kind regards,
Torbjörn

On 2022-09-19 18:30, Torbjörn SVENSSON wrote:

After moving the testglue in commit 9d503515cee, the jump to exit and
abort is too far for the 'b' instruction on Cortex-M0. As most of the
C code would generate a 'bl' instruction instead of a 'b'
instruction, lets do the same for the inline assembler.

The error seen without this patch:

/tmp/cccCRiCl.o: in function `main':
stack-protector-1.c:(.text+0x4e): relocation truncated to fit: R_ARM_THM_JUMP11 
against symbol `__wrap_exit' defined in .text section in gcc_tg.o
stack-protector-1.c:(.text+0x50): relocation truncated to fit: R_ARM_THM_JUMP11 
against symbol `__wrap_abort' defined in .text section in gcc_tg.o
collect2: error: ld returned 1 exit status

gcc/testsuite/ChangeLog:

 * gcc/testsuite/gcc.target/arm/stack-protector-1.c: Use 'bl'
instead of 'b' instruction.
* gcc/testsuite/gcc.target/arm/stack-protector-3.c: Likewise.

Co-Authored-By: Yvan ROUX  
Signed-off-by: Torbjörn SVENSSON  
---
  gcc/testsuite/gcc.target/arm/stack-protector-1.c | 4 ++--
  gcc/testsuite/gcc.target/arm/stack-protector-3.c | 2 +-
  2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/gcc/testsuite/gcc.target/arm/stack-protector-1.c 
b/gcc/testsuite/gcc.target/arm/stack-protector-1.c
index 8d28b0a847c..3f0ffc9c3f3 100644
--- a/gcc/testsuite/gcc.target/arm/stack-protector-1.c
+++ b/gcc/testsuite/gcc.target/arm/stack-protector-1.c
@@ -56,8 +56,8 @@ asm (
  "ldr r1, [sp, #4]\n"
CHECK (r1)
  "mov r0, #0\n"
-" b   exit\n"
+" bl  exit\n"
  "1:\n"
-" b   abort\n"
+" bl  abort\n"
  ".size   main, .-main"
  );
diff --git a/gcc/testsuite/gcc.target/arm/stack-protector-3.c 
b/gcc/testsuite/gcc.target/arm/stack-protector-3.c
index b8f77fa2309..2f710529b8f 100644
--- a/gcc/testsuite/gcc.target/arm/stack-protector-3.c
+++ b/gcc/testsuite/gcc.target/arm/stack-protector-3.c
@@ -26,7 +26,7 @@ asm (
  ".type   __stack_chk_fail, %function\n"
  "__stack_chk_fail:\n"
  "movsr0, #0\n"
-" b   exit\n"
+" bl  exit\n"
  ".size   __stack_chk_fail, .-__stack_chk_fail"
  );
  

RE: [PATCH] testsuite: Skip intrinsics test if arm

[Kyrylo Tkachov via Gcc-patches]

> -Original Message-
> From: Torbjörn SVENSSON 
> Sent: Tuesday, September 27, 2022 3:40 PM
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov ; Richard Sandiford
> ; Torbjörn SVENSSON
> ; Yvan ROUX 
> Subject: [PATCH] testsuite: Skip intrinsics test if arm
> 
> In the test cases, it's clearly written that intrinsics are not
> implemented on arm*. A simple xfail does not help since there are
> link error and that would cause an UNRESOLVED testcase rather than
> XFAIL.
> By changing to dg-skip-if, the entire test case is omitted.
> 

Ok.
Thanks,
Kyrill

> gcc/testsuite/ChangeLog:
> 
>   * gcc.target/aarch64/advsimd-intrinsics/vld1x2.c: Rephrase
>   to unimplemented.
>   * gcc.target/aarch64/advsimd-intrinsics/vld1x3.c: Likewise.
>   * gcc.target/aarch64/advsimd-intrinsics/vld1x4.c: Likewise.
>   * gcc.target/aarch64/advsimd-intrinsics/vst1x2.c: Replace
>   dg-xfail-if with dg-skip-if.
>   * gcc.target/aarch64/advsimd-intrinsics/vst1x3.c: Likewise.
>   * gcc.target/aarch64/advsimd-intrinsics/vst1x4.c: Likewise.
> 
> Co-Authored-By: Yvan ROUX  
> Signed-off-by: Torbjörn SVENSSON  
> ---
>  gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vld1x2.c | 2 +-
>  gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vld1x3.c | 2 +-
>  gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vld1x4.c | 2 +-
>  gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vst1x2.c | 2 +-
>  gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vst1x3.c | 2 +-
>  gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vst1x4.c | 2 +-
>  6 files changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vld1x2.c
> b/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vld1x2.c
> index f933102be47..0c45a2b227b 100644
> --- a/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vld1x2.c
> +++ b/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vld1x2.c
> @@ -1,6 +1,6 @@
>  /* We haven't implemented these intrinsics for arm yet.  */
>  /* { dg-do run } */
> -/* { dg-skip-if "unsupported" { arm*-*-* } } */
> +/* { dg-skip-if "unimplemented" { arm*-*-* } } */
>  /* { dg-options "-O3" } */
> 
>  #include 
> diff --git a/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vld1x3.c
> b/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vld1x3.c
> index b20dec061b5..4174dcd064a 100644
> --- a/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vld1x3.c
> +++ b/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vld1x3.c
> @@ -1,6 +1,6 @@
>  /* We haven't implemented these intrinsics for arm yet.  */
>  /* { dg-do run } */
> -/* { dg-skip-if "unsupported" { arm*-*-* } } */
> +/* { dg-skip-if "unimplemented" { arm*-*-* } } */
>  /* { dg-options "-O3" } */
> 
>  #include 
> diff --git a/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vld1x4.c
> b/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vld1x4.c
> index e59f845880e..89b289bb21d 100644
> --- a/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vld1x4.c
> +++ b/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vld1x4.c
> @@ -1,6 +1,6 @@
>  /* We haven't implemented these intrinsics for arm yet.  */
>  /* { dg-do run } */
> -/* { dg-skip-if "unsupported" { arm*-*-* } } */
> +/* { dg-skip-if "unimplemented" { arm*-*-* } } */
>  /* { dg-options "-O3" } */
> 
>  #include 
> diff --git a/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vst1x2.c
> b/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vst1x2.c
> index cb13da0caed..6d20a46b8b6 100644
> --- a/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vst1x2.c
> +++ b/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vst1x2.c
> @@ -1,6 +1,6 @@
>  /* We haven't implemented these intrinsics for arm yet.  */
> -/* { dg-xfail-if "" { arm*-*-* } } */
>  /* { dg-do run } */
> +/* { dg-skip-if "unimplemented" { arm*-*-* } } */
>  /* { dg-options "-O3" } */
> 
>  #include 
> diff --git a/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vst1x3.c
> b/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vst1x3.c
> index 3ce272a5007..87eae4d2f35 100644
> --- a/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vst1x3.c
> +++ b/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vst1x3.c
> @@ -1,6 +1,6 @@
>  /* We haven't implemented these intrinsics for arm yet.  */
> -/* { dg-xfail-if "" { arm*-*-* } } */
>  /* { dg-do run } */
> +/* { dg-skip-if "unimplemented" { arm*-*-* } } */
>  /* { dg-options "-O3" } */
> 
>  #include 
> diff --git a/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vst1x4.c
> b/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vst1x4.c
> index 1f17b5342de..829a18ddac0 100644
> --- a/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vst1x4.c
> +++ b/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vst1x4.c
> @@ -1,6 +1,6 @@
>  /* We haven't implemented these intrinsics for arm yet.  */
> -/* { dg-xfail-if "" { arm*-*-* } } */
>  /* { dg-do run } */
> +/* { dg-skip-if "unimplemented" { arm*-*-* } } */
>  /* { 

Re: [PATCH] LoongArch: Add prefetch instruction

[Xi Ruoyao via Gcc-patches]

On Wed, 2022-09-28 at 16:31 +0800, Lulu Cheng wrote:
> Hi,
> 
> My colleague is testing the performance data of prefetch and
> prefetchx.
> 
> And will submit both supports together if there is no problem.

Ok, so mark this one as "superseded".

> 
> 在 2022/9/25 下午7:25, Xi Ruoyao 写道:
> > The test pr106397.c fails on LoongArch because we don't have defined
> > prefetch instruction.  We can silence the test for LoongArch, but
> > it's
> > not too difficult to add the prefetch instruction so add it now.
> > 
> > -- >8 --
> > 
> > gcc/ChangeLog:
> > 
> > * config/loongarch/constraints.md (ZD): New address
> > constraint.
> > * config/loongarch/loongarch.md (prefetch): New insn.
> > ---
> >   gcc/config/loongarch/constraints.md |  6 ++
> >   gcc/config/loongarch/loongarch.md   | 14 ++
> >   2 files changed, 20 insertions(+)
> > 
> > diff --git a/gcc/config/loongarch/constraints.md
> > b/gcc/config/loongarch/constraints.md
> > index 43cb7b5f0f5..93da5970958 100644
> > --- a/gcc/config/loongarch/constraints.md
> > +++ b/gcc/config/loongarch/constraints.md
> > @@ -190,3 +190,9 @@ (define_memory_constraint "ZB"
> >     The offset is zero"
> >     (and (match_code "mem")
> >  (match_test "REG_P (XEXP (op, 0))")))
> > +
> > +(define_address_constraint "ZD"
> > +  "An address operand whose address is formed by a base register
> > and offset
> > +   that is suitable for use in instructions with the same
> > addressing mode
> > +   as @code{preld}."
> > +   (match_test "loongarch_12bit_offset_address_p (op, mode)"))
> > diff --git a/gcc/config/loongarch/loongarch.md
> > b/gcc/config/loongarch/loongarch.md
> > index 214b14bddd3..84c1bd1c0d6 100644
> > --- a/gcc/config/loongarch/loongarch.md
> > +++ b/gcc/config/loongarch/loongarch.md
> > @@ -2137,6 +2137,20 @@ (define_insn "loongarch_dbar"
> >     ""
> >     "dbar\t%0")
> >   
> > +(define_insn "prefetch"
> > +  [(prefetch (match_operand 0 "address_operand" "ZD")
> > +    (match_operand 1 "const_uimm5_operand" "i")
> > +    (match_operand 2 "const_int_operand" "n"))]
> > +  ""
> > +{
> > +  switch (INTVAL (operands[1]))
> > +  {
> > +    case 0: return "preld\t0,%a0";
> > +    case 1: return "preld\t8,%a0";
> > +    default: gcc_unreachable ();
> > +  }
> > +})
> > +
> >   
> >   
> >   ;; Privileged state instruction
> 

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

Re: [PATCH] LoongArch: Add prefetch instruction

[Lulu Cheng]

Hi,

My colleague is testing the performance data of prefetch and prefetchx.

And will submit both supports together if there is no problem.


在 2022/9/25 下午7:25, Xi Ruoyao 写道:

The test pr106397.c fails on LoongArch because we don't have defined
prefetch instruction.  We can silence the test for LoongArch, but it's
not too difficult to add the prefetch instruction so add it now.

-- >8 --

gcc/ChangeLog:

* config/loongarch/constraints.md (ZD): New address constraint.
* config/loongarch/loongarch.md (prefetch): New insn.
---
  gcc/config/loongarch/constraints.md |  6 ++
  gcc/config/loongarch/loongarch.md   | 14 ++
  2 files changed, 20 insertions(+)

diff --git a/gcc/config/loongarch/constraints.md 
b/gcc/config/loongarch/constraints.md
index 43cb7b5f0f5..93da5970958 100644
--- a/gcc/config/loongarch/constraints.md
+++ b/gcc/config/loongarch/constraints.md
@@ -190,3 +190,9 @@ (define_memory_constraint "ZB"
The offset is zero"
(and (match_code "mem")
 (match_test "REG_P (XEXP (op, 0))")))
+
+(define_address_constraint "ZD"
+  "An address operand whose address is formed by a base register and offset
+   that is suitable for use in instructions with the same addressing mode
+   as @code{preld}."
+   (match_test "loongarch_12bit_offset_address_p (op, mode)"))
diff --git a/gcc/config/loongarch/loongarch.md 
b/gcc/config/loongarch/loongarch.md
index 214b14bddd3..84c1bd1c0d6 100644
--- a/gcc/config/loongarch/loongarch.md
+++ b/gcc/config/loongarch/loongarch.md
@@ -2137,6 +2137,20 @@ (define_insn "loongarch_dbar"
""
"dbar\t%0")
  
+(define_insn "prefetch"

+  [(prefetch (match_operand 0 "address_operand" "ZD")
+(match_operand 1 "const_uimm5_operand" "i")
+(match_operand 2 "const_int_operand" "n"))]
+  ""
+{
+  switch (INTVAL (operands[1]))
+  {
+case 0: return "preld\t0,%a0";
+case 1: return "preld\t8,%a0";
+default: gcc_unreachable ();
+  }
+})
+
  
  
  ;; Privileged state instruction

[committed] libgomp.texi: Status 'P' for 'assume', remove duplicated line

[Tobias Burnus]

The wording for 'begin declare target' was different, but the meaning the same.
thus I remove one. (See line just after the @@ in the diff for the kept item.)

Being there, I have also marked 'assume' as 'P (only C/C++)'.

Committed as https://gcc.gnu.org/r13-2911

Tobias


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

libgomp.texi: Status 'P' for 'assume', remove duplicated line

libgomp/
* libgomp.texi (OpenMP 5.1): Mark 'assume' as implemented
for C/C++. Remove duplicated 'begin declare target' entry.
---
 libgomp/libgomp.texi | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/libgomp/libgomp.texi b/libgomp/libgomp.texi
index 5aef987f00a..2b11f304409 100644
--- a/libgomp/libgomp.texi
+++ b/libgomp/libgomp.texi
@@ -287,7 +287,7 @@ The OpenMP 4.5 specification is fully supported.
   @code{append_args} @tab N @tab
 @item @code{dispatch} construct @tab N @tab
 @item device-specific ICV settings with environment variables @tab Y @tab
-@item @code{assume} directive @tab N @tab
+@item @code{assume} directive @tab P @tab Only C/C++
 @item @code{nothing} directive @tab Y @tab
 @item @code{error} directive @tab Y @tab
 @item @code{masked} construct @tab Y @tab
@@ -348,7 +348,6 @@ 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

Re: [PATCH] LoongArch: Use UNSPEC for fmin/fmax RTL pattern [PR105414]

[Lulu Cheng]

I have no problem.

Thanks.

在 2022/9/24 下午8:47, Xi Ruoyao 写道:

I made a mistake defining fmin/fmax RTL patterns in r13-2085: I used
smin and smax in the definition mistakenly.  This causes the optimizer
to perform constant folding as if fmin/fmax was "really" smin/smax
operations even with -fsignaling-nans.  Then pr105414.c fails.

We don't have fmin/fmax RTL codes for now (PR107013) so we can only use
an UNSPEC for fmin and fmax patterns.

gcc/ChangeLog:

PR tree-optimization/105414
* config/loongarch/loongarch.md (UNSPEC_FMAX): New unspec.
(UNSPEC_FMIN): Likewise.
(fmax3): Use UNSPEC_FMAX instead of smax.
(fmin3): Use UNSPEC_FMIN instead of smin.
---
  gcc/config/loongarch/loongarch.md | 12 
  1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/gcc/config/loongarch/loongarch.md 
b/gcc/config/loongarch/loongarch.md
index 3787fd8230f..214b14bddd3 100644
--- a/gcc/config/loongarch/loongarch.md
+++ b/gcc/config/loongarch/loongarch.md
@@ -35,6 +35,8 @@ (define_c_enum "unspec" [
;; Floating point unspecs.
UNSPEC_FRINT
UNSPEC_FCLASS
+  UNSPEC_FMAX
+  UNSPEC_FMIN
  
;; Override return address for exception handling.

UNSPEC_EH_RETURN
@@ -1032,8 +1034,9 @@ (define_insn "smin3"
  
  (define_insn "fmax3"

[(set (match_operand:ANYF 0 "register_operand" "=f")
-   (smax:ANYF (match_operand:ANYF 1 "register_operand" "f")
-  (match_operand:ANYF 2 "register_operand" "f")))]
+   (unspec:ANYF [(use (match_operand:ANYF 1 "register_operand" "f"))
+ (use (match_operand:ANYF 2 "register_operand" "f"))]
+UNSPEC_FMAX))]
""
"fmax.\t%0,%1,%2"
[(set_attr "type" "fmove")
@@ -1041,8 +1044,9 @@ (define_insn "fmax3"
  
  (define_insn "fmin3"

[(set (match_operand:ANYF 0 "register_operand" "=f")
-   (smin:ANYF (match_operand:ANYF 1 "register_operand" "f")
-  (match_operand:ANYF 2 "register_operand" "f")))]
+   (unspec:ANYF [(use (match_operand:ANYF 1 "register_operand" "f"))
+ (use (match_operand:ANYF 2 "register_operand" "f"))]
+UNSPEC_FMIN))]
""
"fmin.\t%0,%1,%2"
[(set_attr "type" "fmove")

[wwwdocs][patch] gcc-13/changes.html: Add nvptx's --with-arch

[Tobias Burnus]

The attached patch documents the new nvptx configure flag --with-arch=sm_...

Comments? OK?

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
gcc-13/changes.html: Add nvptx's --with-arch

diff --git a/htdocs/gcc-13/changes.html b/htdocs/gcc-13/changes.html
index 390193ca..f113e443 100644
--- a/htdocs/gcc-13/changes.html
+++ b/htdocs/gcc-13/changes.html
@@ -209,7 +209,18 @@ a work-in-progress.
 
 
 
-
+NVPTX
+
+  The default value for the https://gcc.gnu.org/onlinedocs/gcc/Nvidia-PTX-Options.html;>
+  -march option can be now changed when https://gcc.gnu.org/install/;>building GCC using the
+  https://gcc.gnu.org/install/specific.html#nvptx-x-none;>
+  --with-arch= flag; if not specified, GCC defaults to
+  sm_30. GCC's target libraries are build both with
+  sm_30 and the specified target architecture.
+  
+
 
 
 

Re: [PATCH v2] LoongArch: Libvtv add loongarch support.

[Lulu Cheng]

在 2022/9/27 下午7:44, Xi Ruoyao 写道:

On Tue, 2022-09-27 at 15:49 +0800, Lulu Cheng wrote:

  #if defined (__CYGWIN__) || defined (__MINGW32__)
    if (VTV_PAGE_SIZE != sysconf_SC_PAGE_SIZE())
+#elif defined (__loongarch_lp64)
+  /* I think that under the LoongArch 64-bit system, VTV_PAGE_SIZE is set
+ to the maximum value of 64K supported by the system, so there is no
+ need to judge here.  */
+  if (false)

I think "if (false)" can trigger some compiler warnings...

Still not sure if the maximum value is always correct (+ Caroline for a
confirmation).  If it's correct I'd suggest...


  #else
    if (VTV_PAGE_SIZE != sysconf (_SC_PAGE_SIZE))

if (VTV_PAGE_SIZE % sysconf (_SC_PAGE_SIZE) != 0)



If the setting to the maximum value is correct,

I also think it is better to achieve this.




  #endif

Re: [commited PATCH] LoongArch: Libitm add LoongArch support.

[Lulu Cheng]

在 2022/9/26 上午10:05, Lulu Cheng 写道:

Co-Authored-By: Yang Yujie 

libitm/ChangeLog:

* configure.tgt: Add loongarch support.
* config/loongarch/asm.h: New file.
* config/loongarch/sjlj.S: New file.
* config/loongarch/target.h: New file.


Pushed to r13-2910.

Re: [PATCH] rs6000: Rework option -mpowerpc64 handling [PR106680]

[Iain Sandoe]

Hi Kewen,

> On 28 Sep 2022, at 06:30, Kewen.Lin via Gcc-patches  
> wrote:

> PR106680 shows that -m32 -mpowerpc64 is different from
> -mpowerpc64 -m32, this is determined by the way how we
> handle option powerpc64 in rs6000_handle_option.
> 
> Segher pointed out this difference should be taken as
> a bug and we should ensure that option powerpc64 is
> independent of -m32/-m64.  So this patch removes the
> handlings in rs6000_handle_option and add some necessary
> supports in rs6000_option_override_internal instead.
> 
> With this patch, if users specify -m{no-,}powerpc64, the
> specified value is honoured, otherwise, for 64bit it
> always enables OPTION_MASK_POWERPC64 while for 32bit
> it disables OPTION_MASK_POWERPC64 if OS_MISSING_POWERPC64.
> 
> Bootstrapped and regress-tested on:
>  - powerpc64-linux-gnu P7 and P8 {-m64,-m32}
>  - powerpc64le-linux-gnu P9 and P10
>  - powerpc-ibm-aix7.2.0.0 {-maix64,-maix32}
> 
> Hi Iain, could you help to test this on darwin to ensure
> it won't break darwin's build and new tests are fine?
> Thanks in advance!

Will do, it will take a day or so, thanks,
Iain

[PATCH] Add OPTIONS_H_EXTRA to GTFILES

[Richard Sandiford via Gcc-patches]

I have a patch that adds a typedef to aarch64's -opts.h.
The typedef is used for a TargetVariable in the .opt file,
which means that it is covered by PCH and so needs to be
visible to gengtype.

-opts.h is not included directly in tm.h, but indirectly
by target headers (in this case aarch64.h).  There was therefore
nothing that caused it to be added to GTFILES.

Tested on aarch64-linux-gnu and x86_64-linux-gnu.  OK to install?

Richard


gcc/
* Makefile.in (GTFILES): Add OPTIONS_H_EXTRA.
---
 gcc/Makefile.in | 1 +
 1 file changed, 1 insertion(+)

diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index 59b67d99441..c1d04384399 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -2661,6 +2661,7 @@ s-match: build/genmatch$(build_exeext) $(srcdir)/match.pd 
cfn-operators.pd
 
 GTFILES = $(CPPLIB_H) $(srcdir)/input.h $(srcdir)/coretypes.h \
   $(host_xm_file_list) \
+  $(OPTIONS_H_EXTRA) \
   $(tm_file_list) $(HASHTAB_H) $(SPLAY_TREE_H) $(srcdir)/bitmap.h \
   $(srcdir)/wide-int.h $(srcdir)/alias.h \
   $(srcdir)/coverage.cc  $(srcdir)/rtl.h \
-- 
2.25.1