Re: [PATCH] Allocate general register(memory/immediate) for 16/32/64-bit vector bit_op patterns.

[Uros Bizjak via Gcc-patches]

On Tue, Jul 12, 2022 at 8:37 AM Hongtao Liu  wrote:
>
> On Mon, Jul 11, 2022 at 4:03 PM Uros Bizjak via Gcc-patches
>  wrote:
> >
> > On Mon, Jul 11, 2022 at 3:15 AM liuhongt  wrote:
> > >
> > > And split it to GPR-version instruction after reload.
> > >
> > > This will enable below optimization for 16/32/64-bit vector bit_op
> > >
> > > -   movd(%rdi), %xmm0
> > > -   movd(%rsi), %xmm1
> > > -   pand%xmm1, %xmm0
> > > -   movd%xmm0, (%rdi)
> > > +   movl(%rsi), %eax
> > > +   andl%eax, (%rdi)
> > >
> > > Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
> > > Ok for trunk?
> >
> > The patch will create many interunit moves (xmm <-> gpr) for anything
> > but the most simple logic sequences, because operations with
> > memory/immediate will be forced into GPR registers, while reg/reg
> > operations will remain in XMM registers.
> Agree not to deal with mem/immediate at first.
> >
> > I tried to introduce GPR registers to MMX logic insns in the past and
> > observed the above behavior, but perhaps RA evolved in the mean time
> > to handle different register sets better (especially under register
> > pressure). However, I would advise to be careful with this
> > functionality.
> >
> > Perhaps this problem should be attacked in stages. First, please
> > introduce GPR registers to MMX logic instructions (similar to how
> > VI_16_32 mode instructions are handled). After RA effects will be
> There's "?r" in VI_16_32 logic instructions which prevent RA allocate
> gpr for testcase in the patch.
> Is it ok to remove "?" for them(Also add alternative "r" instead of
> "?r" in mmx logic insns)?
> If there's other instructions that prefer "v to "r", then RA will
> allocate "v", but for logic instructions, "r" and “v" should be
> treated equally, just as in the 16/32/64-bit vector
> mov_internal.

?r was introduced under the assumption that we want vector values
mostly in vector registers. Currently there are no instructions with
memory or immediate operand, so that made sense at the time. Let's
keep ?r until logic instructions with mem/imm operands are introduced.
So, for the patch that adds 64-bit vector logic in GPR, I would advise
to first introduce only register operands. mem/imm operands should be
added in a follow-up patch when the "?r" constraint will also be
relaxed.

Uros.

Re: [PATCH 3/3] lto-plugin: implement LDPT_GET_API_VERSION

[Martin Liška]

On 7/12/22 08:28, Richard Biener wrote:
> On Mon, Jul 11, 2022 at 6:35 PM Alexander Monakov  wrote:
>>
>> On Mon, 11 Jul 2022, Martin Liška wrote:
>>
>>> I've clarified that linker should return a value that is in range
>>> [minimal_api_supported, maximal_api_supported] and added an abort
>>> if it's not the case.
>>
>> I noticed that we are placing a trap for C++ consumers such as mold
>> by passing min/max_api_supported as enum values. Unlike C, C++ disallows
>> out-of-range enum values, so when mold does
>>
>> enum PluginLinkerAPIVersion {
>>   LAPI_V0 = 0,   
>>   LAPI_V1,
>> };
>>
>> get_api_version(const char *plugin_identifier,
>> unsigned plugin_version,
>> PluginLinkerAPIVersion minimal_api_supported,
>> PluginLinkerAPIVersion maximal_api_supported,
>> const char **linker_identifier,
>> const char **linker_version) {
>>
>> checks such as 'min_api_supported > LAPI_V1' can be optimized out. Also,
>> if a future tool passes LAPI_V2, it will trigger Clang's UBSan (GCC
>> -fsanitize-undefined=enum instruments loads but not retrieval of function
>> arguments).
>>
>> I'd suggest to fix this on both sides by changing the arguments to plain
>> integer types.
> 
> That's a good point - the enum itself is then also somewhat redundant
> if it just specifies symbolic names for 0, 1, ... but we can keep it for
> documentation purposes.

All right, here we go with the integer types.

May I install the version now?

Thanks,
Martin

> 
>>
>> Alexander
From 8f7372bd2b3d76feeca84cdbb0d392d93569bd57 Mon Sep 17 00:00:00 2001
From: Martin Liska 
Date: Mon, 16 May 2022 14:01:52 +0200
Subject: [PATCH] lto-plugin: implement LDPT_GET_API_VERSION

include/ChangeLog:

	* plugin-api.h (enum linker_api_version): New enum.
	(ld_plugin_get_api_version): New.
	(enum ld_plugin_tag): Add LDPT_GET_API_VERSION.
	(struct ld_plugin_tv): Add tv_get_api_version.

lto-plugin/ChangeLog:

	* lto-plugin.c (negotiate_api_version): New.
	(onload): Negotiate API version.
	* Makefile.am: Add -DBASE_VERSION.
	* Makefile.in: Regenerate.
---
 include/plugin-api.h| 33 +
 lto-plugin/Makefile.am  |  2 +-
 lto-plugin/Makefile.in  |  2 +-
 lto-plugin/lto-plugin.c | 47 +
 4 files changed, 82 insertions(+), 2 deletions(-)

diff --git a/include/plugin-api.h b/include/plugin-api.h
index 8aebe2ff267..0b61cfc0443 100644
--- a/include/plugin-api.h
+++ b/include/plugin-api.h
@@ -483,6 +483,37 @@ enum ld_plugin_level
   LDPL_FATAL
 };
 
+/* Contract between a plug-in and a linker.  */
+
+enum linker_api_version
+{
+   /* The linker/plugin do not implement any of the API levels below, the API
+   is determined solely via the transfer vector.  */
+   LAPI_V0,
+
+   /* API level v1.  The linker provides get_symbols_v3, add_symbols_v2,
+  the plugin will use that and not any lower versions.
+  claim_file is thread-safe on the plugin side and
+  add_symbols on the linker side.  */
+   LAPI_V1
+};
+
+/* The linker's interface for API version negotiation.  A plug-in calls
+  the function (with its IDENTIFIER and VERSION), plus minimal and maximal
+  version of linker_api_version is provided.  Linker then returns selected
+  API version and provides its IDENTIFIER and VERSION.  The returned value
+  by linker must be in range [MINIMAL_API_SUPPORTED, MAXIMAL_API_SUPPORTED].
+  Identifier pointers remain valid as long as the plugin is loaded.  */
+
+typedef
+int
+(*ld_plugin_get_api_version) (const char *plugin_identifier,
+			  const char *plugin_version,
+			  int minimal_api_supported,
+			  int maximal_api_supported,
+			  const char **linker_identifier,
+			  const char **linker_version);
+
 /* Values for the tv_tag field of the transfer vector.  */
 
 enum ld_plugin_tag
@@ -521,6 +552,7 @@ enum ld_plugin_tag
   LDPT_REGISTER_NEW_INPUT_HOOK,
   LDPT_GET_WRAP_SYMBOLS,
   LDPT_ADD_SYMBOLS_V2,
+  LDPT_GET_API_VERSION,
 };
 
 /* The plugin transfer vector.  */
@@ -556,6 +588,7 @@ struct ld_plugin_tv
 ld_plugin_get_input_section_size tv_get_input_section_size;
 ld_plugin_register_new_input tv_register_new_input;
 ld_plugin_get_wrap_symbols tv_get_wrap_symbols;
+ld_plugin_get_api_version tv_get_api_version;
   } tv_u;
 };
 
diff --git a/lto-plugin/Makefile.am b/lto-plugin/Makefile.am
index 81362eafc36..482946e4dd5 100644
--- a/lto-plugin/Makefile.am
+++ b/lto-plugin/Makefile.am
@@ -8,7 +8,7 @@ target_noncanonical := @target_noncanonical@
 libexecsubdir := $(libexecdir)/gcc/$(real_target_noncanonical)/$(gcc_version)$(accel_dir_suffix)
 
 AM_CPPFLAGS = -I$(top_srcdir)/../include $(DEFS)
-AM_CFLAGS = @ac_lto_plugin_warn_cflags@ $(CET_HOST_FLAGS)
+AM_CFLAGS = @ac_lto_plugin_warn_cflags@ $(CET_HOST_FLAGS) -DBASE_VERSION='"$(gcc_version)"'
 # The plug-in depends on pthreads.
 AM_LDFLAGS = -pthread @ac_lto_plugin_ldflags@
 AM_LIBTOOLFLAGS = --tag=disable-static
diff --git a/l

Re: [PATCH 1/2] Add gcc/make-unique.h

[Jonathan Wakely via Gcc-patches]

On Tue, 12 Jul 2022 at 07:48, Jonathan Wakely wrote:
> You also need  for the enable_if and is_array traits. With 
> libstdc++ that gets included by  but that's guaranteed for other 
> library implementations.

Sorry, I was replying from my phone and missed a word. That's **not**
guaranteed for other library implementations.

(It's not formally guaranteed for libstdc++ either, but in practice
nearly every libstdc++ header includes  because nearly
every header needs part of it, and that's unlikely to change).

Re: [PATCH] libstdc++: Prefer const T to std::add_const_t

[Jonathan Wakely via Gcc-patches]

On Thu, 7 Jul 2022 at 17:55, Jonathan Wakely via Libstdc++
 wrote:
>
> Does anybody see a problem with this change? The point is to avoid
> unnecessary class template instantiations.
>
> Tested aarch64-linux.

Pushed to trunk now.

>
> -- >8 --
>
> For any typedef-name or template parameter, T, add_const_t is
> equivalent to T const, so we can avoid instantiating the std::add_const
> class template and just say T const (or const T).
>
> This isn't true for a non-typedef like int&, where int& const would be
> ill-formed, but we shouldn't be using add_const_t anyway, because
> we know what that type is.
>
> The only place we need to continue using std::add_const is in the
> std::bind implementation where it's used as a template template
> parameter to be applied as a metafunction elsewhere.
>
> libstdc++-v3/ChangeLog:
>
> * include/bits/stl_iterator.h (__iter_to_alloc_t): Replace
> add_const_t with const-qualifier.
> * include/bits/utility.h (tuple_element): Likewise for
> all cv-qualifiers.
> * include/std/type_traits (add_const, add_volatile): Replace
> typedef-declaration with using-declaration.
> (add_cv): Replace add_const and add_volatile with cv-qualifiers.
> * include/std/variant (variant_alternative): Replace
> add_const_t, add_volatile_t and add_cv_t etc. with cv-qualifiers.
> ---
>  libstdc++-v3/include/bits/stl_iterator.h | 11 +--
>  libstdc++-v3/include/bits/utility.h  |  6 +++---
>  libstdc++-v3/include/std/type_traits |  9 +++--
>  libstdc++-v3/include/std/variant |  6 +++---
>  4 files changed, 14 insertions(+), 18 deletions(-)
>
> diff --git a/libstdc++-v3/include/bits/stl_iterator.h 
> b/libstdc++-v3/include/bits/stl_iterator.h
> index 12a89ab229f..049cb02a4c4 100644
> --- a/libstdc++-v3/include/bits/stl_iterator.h
> +++ b/libstdc++-v3/include/bits/stl_iterator.h
> @@ -2536,19 +2536,18 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>// of associative containers.
>template
>  using __iter_key_t = remove_const_t<
> -typename iterator_traits<_InputIterator>::value_type::first_type>;
> +  typename iterator_traits<_InputIterator>::value_type::first_type>;
>
>template
> -using __iter_val_t =
> -typename iterator_traits<_InputIterator>::value_type::second_type;
> +using __iter_val_t
> +  = typename iterator_traits<_InputIterator>::value_type::second_type;
>
>template
>  struct pair;
>
>template
> -using __iter_to_alloc_t =
> -pair>,
> -__iter_val_t<_InputIterator>>;
> +using __iter_to_alloc_t
> +  = pair, 
> __iter_val_t<_InputIterator>>;
>  #endif // __cpp_deduction_guides
>
>  _GLIBCXX_END_NAMESPACE_VERSION
> diff --git a/libstdc++-v3/include/bits/utility.h 
> b/libstdc++-v3/include/bits/utility.h
> index e0e40309a6d..6a192e27836 100644
> --- a/libstdc++-v3/include/bits/utility.h
> +++ b/libstdc++-v3/include/bits/utility.h
> @@ -86,19 +86,19 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>template
>  struct tuple_element<__i, const _Tp>
>  {
> -  typedef typename add_const<__tuple_element_t<__i, _Tp>>::type type;
> +  using type = const __tuple_element_t<__i, _Tp>;
>  };
>
>template
>  struct tuple_element<__i, volatile _Tp>
>  {
> -  typedef typename add_volatile<__tuple_element_t<__i, _Tp>>::type type;
> +  using type = volatile __tuple_element_t<__i, _Tp>;
>  };
>
>template
>  struct tuple_element<__i, const volatile _Tp>
>  {
> -  typedef typename add_cv<__tuple_element_t<__i, _Tp>>::type type;
> +  using type = const volatile __tuple_element_t<__i, _Tp>;
>  };
>
>  #if __cplusplus >= 201402L
> diff --git a/libstdc++-v3/include/std/type_traits 
> b/libstdc++-v3/include/std/type_traits
> index 2572d8edd69..e5f58bc2e3f 100644
> --- a/libstdc++-v3/include/std/type_traits
> +++ b/libstdc++-v3/include/std/type_traits
> @@ -1577,20 +1577,17 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>/// add_const
>template
>  struct add_const
> -{ typedef _Tp const type; };
> +{ using type = _Tp const; };
>
>/// add_volatile
>template
>  struct add_volatile
> -{ typedef _Tp volatile type; };
> +{ using type = _Tp volatile; };
>
>/// add_cv
>template
>  struct add_cv
> -{
> -  typedef typename
> -  add_const::type>::type type;
> -};
> +{ using type = _Tp const volatile; };
>
>  #if __cplusplus > 201103L
>
> diff --git a/libstdc++-v3/include/std/variant 
> b/libstdc++-v3/include/std/variant
> index 5ff1e3edcdf..f8f15665433 100644
> --- a/libstdc++-v3/include/std/variant
> +++ b/libstdc++-v3/include/std/variant
> @@ -107,15 +107,15 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>
>template
>  struct variant_alternative<_Np, const _Variant>
> -{ using type = add_const_t>; };
> +{ using type = const variant_alternative_t<_Np, _Variant>; };
>
>template
>  struct variant_alternative<_Np, volatile _Variant>
> -

[PATCH 0/1 V4] RISC-V: Support Zmmul extension

[shihua]

From: LiaoShihua 

Zmmul extension is Multiply only extension for RISC-V.It implements the 
multiplication subset of the M extension. 
The encodings are identical to those of the corresponding M-extension 
instructions.
When You both use M extension add Zmmul extension, it will warning "-mdiv 
cannot use when the ZMMUL extension is present"

LiaoShihua (1):
  RISC-V: Support Zmmul extension

 gcc/common/config/riscv/riscv-common.cc  |  3 +++
 gcc/config/riscv/riscv-opts.h|  3 +++
 gcc/config/riscv/riscv.cc|  8 +--
 gcc/config/riscv/riscv.md| 28 
 gcc/config/riscv/riscv.opt   |  3 +++
 gcc/testsuite/gcc.target/riscv/zmmul-1.c | 20 +
 gcc/testsuite/gcc.target/riscv/zmmul-2.c | 20 +
 7 files changed, 69 insertions(+), 16 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/riscv/zmmul-1.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/zmmul-2.c

-- 
2.31.1.windows.1

[PATCH 1/1 V4] RISC-V: Support Zmmul extension

[shihua]

From: LiaoShihua 

gcc\ChangeLog:

* common/config/riscv/riscv-common.cc: Add zmmul.
* config/riscv/riscv-opts.h (MASK_ZMMUL): New.
(TARGET_ZMMUL): Ditto.
* config/riscv/riscv.cc (riscv_option_override): Prohibit division if 
Zmmul is present.
* config/riscv/riscv.md: Add zmmul
* config/riscv/riscv.opt: Ditto.

gcc\testsuite\ChangeLog:

* gcc.target/riscv/zmmul-1.c: New test.
* gcc.target/riscv/zmmul-2.c: New test.

---
 gcc/common/config/riscv/riscv-common.cc  |  3 +++
 gcc/config/riscv/riscv-opts.h|  3 +++
 gcc/config/riscv/riscv.cc|  8 +--
 gcc/config/riscv/riscv.md| 28 
 gcc/config/riscv/riscv.opt   |  3 +++
 gcc/testsuite/gcc.target/riscv/zmmul-1.c | 20 +
 gcc/testsuite/gcc.target/riscv/zmmul-2.c | 20 +
 7 files changed, 69 insertions(+), 16 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/riscv/zmmul-1.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/zmmul-2.c

diff --git a/gcc/common/config/riscv/riscv-common.cc 
b/gcc/common/config/riscv/riscv-common.cc
index 0e5be2ce105..20acc590b30 100644
--- a/gcc/common/config/riscv/riscv-common.cc
+++ b/gcc/common/config/riscv/riscv-common.cc
@@ -193,6 +193,8 @@ static const struct riscv_ext_version 
riscv_ext_version_table[] =
   {"zvl32768b", ISA_SPEC_CLASS_NONE, 1, 0},
   {"zvl65536b", ISA_SPEC_CLASS_NONE, 1, 0},
 
+  {"zmmul", ISA_SPEC_CLASS_NONE, 1, 0},
+
   /* Terminate the list.  */
   {NULL, ISA_SPEC_CLASS_NONE, 0, 0}
 };
@@ -1148,6 +1150,7 @@ static const riscv_ext_flag_table_t 
riscv_ext_flag_table[] =
   {"zvl32768b", &gcc_options::x_riscv_zvl_flags, MASK_ZVL32768B},
   {"zvl65536b", &gcc_options::x_riscv_zvl_flags, MASK_ZVL65536B},
 
+  {"zmmul", &gcc_options::x_riscv_zm_subext, MASK_ZMMUL},
 
   {NULL, NULL, 0}
 };
diff --git a/gcc/config/riscv/riscv-opts.h b/gcc/config/riscv/riscv-opts.h
index 1e153b3a6e7..9c7d69a6ea3 100644
--- a/gcc/config/riscv/riscv-opts.h
+++ b/gcc/config/riscv/riscv-opts.h
@@ -153,6 +153,9 @@ enum stack_protector_guard {
 #define TARGET_ZICBOM ((riscv_zicmo_subext & MASK_ZICBOM) != 0)
 #define TARGET_ZICBOP ((riscv_zicmo_subext & MASK_ZICBOP) != 0)
 
+#define MASK_ZMMUL  (1 << 0)
+#define TARGET_ZMMUL((riscv_zm_subext & MASK_ZMMUL) != 0)
+
 /* Bit of riscv_zvl_flags will set contintuly, N-1 bit will set if N-bit is
set, e.g. MASK_ZVL64B has set then MASK_ZVL32B is set, so we can use
popcount to caclulate the minimal VLEN.  */
diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index 2e83ca07394..9bf57980024 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -4999,10 +4999,14 @@ riscv_option_override (void)
   /* The presence of the M extension implies that division instructions
  are present, so include them unless explicitly disabled.  */
   if (TARGET_MUL && (target_flags_explicit & MASK_DIV) == 0)
-target_flags |= MASK_DIV;
+if(!TARGET_ZMMUL)
+  target_flags |= MASK_DIV;
   else if (!TARGET_MUL && TARGET_DIV)
 error ("%<-mdiv%> requires %<-march%> to subsume the % extension");
-
+  
+  if(TARGET_ZMMUL && TARGET_MUL)
+warning (0, "%<-mdiv%> cannot use when the % extension is 
present");
+  
   /* Likewise floating-point division and square root.  */
   if (TARGET_HARD_FLOAT && (target_flags_explicit & MASK_FDIV) == 0)
 target_flags |= MASK_FDIV;
diff --git a/gcc/config/riscv/riscv.md b/gcc/config/riscv/riscv.md
index 308b64dd30d..d4e171464ea 100644
--- a/gcc/config/riscv/riscv.md
+++ b/gcc/config/riscv/riscv.md
@@ -763,7 +763,7 @@
   [(set (match_operand:SI  0 "register_operand" "=r")
(mult:SI (match_operand:SI 1 "register_operand" " r")
 (match_operand:SI 2 "register_operand" " r")))]
-  "TARGET_MUL"
+  "TARGET_ZMMUL || TARGET_MUL"
   { return TARGET_64BIT ? "mulw\t%0,%1,%2" : "mul\t%0,%1,%2"; }
   [(set_attr "type" "imul")
(set_attr "mode" "SI")])
@@ -772,7 +772,7 @@
   [(set (match_operand:DI  0 "register_operand" "=r")
(mult:DI (match_operand:DI 1 "register_operand" " r")
 (match_operand:DI 2 "register_operand" " r")))]
-  "TARGET_MUL && TARGET_64BIT"
+  "TARGET_ZMMUL || TARGET_MUL && TARGET_64BIT"
   "mul\t%0,%1,%2"
   [(set_attr "type" "imul")
(set_attr "mode" "DI")])
@@ -782,7 +782,7 @@
(mult:GPR (match_operand:GPR 1 "register_operand" " r")
  (match_operand:GPR 2 "register_operand" " r")))
(label_ref (match_operand 3 "" ""))]
-  "TARGET_MUL"
+  "TARGET_ZMMUL || TARGET_MUL"
 {
   if (TARGET_64BIT && mode == SImode)
 {
@@ -827,7 +827,7 @@
(mult:GPR (match_operand:GPR 1 "register_operand" " r")
  (match_operand:GPR 2 "register_operand" " r")))
(label_ref (match_operand 3 "" ""))]
-  "TARGET_MUL"
+  "TARGET_ZMMUL || TARGET_MUL"
 {
   if (TARGET_64BIT && mode == SImode)
 {
@@ -873,7 +873,7 @@
(sign_extend:DI

[committed] libgomp: Add tailing \n to gomp_debug

[Tobias Burnus]

A recently added gomp_debug (for 'requires') missed a tailing '\n'. I
missed to add it, when changing gomp_warning (which always outputs an
'\n') to gomp_debug.

Committed as r13-1613-g220bef460153a0296e947f16492d35e67b1b5b22

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 220bef460153a0296e947f16492d35e67b1b5b22
Author: Tobias Burnus 
Date:   Tue Jul 12 11:10:50 2022 +0200

libgomp: Add tailing \n to gomp_debug

Contrary to gomp_{error,warning,fatal}, no tailing '\n' is added with
gomp_debug; only affected was a 'requires'-related output.

libgomp/ChangeLog:

* target.c (gomp_target_init): Added tailing '\n' to gomp_debug.
---
 libgomp/target.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libgomp/target.c b/libgomp/target.c
index 86f9d3050d9..135db1d88ab 100644
--- a/libgomp/target.c
+++ b/libgomp/target.c
@@ -4212,7 +4212,7 @@ gomp_target_init (void)
 		name[cur_len] = '\0';
 		gomp_debug (1,
 "%s devices present but 'omp requires %s' "
-			"cannot be fulfilled", name, buf);
+"cannot be fulfilled\n", name, buf);
 		free (name);
 		  }
 	  }

RE: [PATCH 2/2]middle-end: Support recognition of three-way max/min.

[Tamar Christina via Gcc-patches]

ping

> -Original Message-
> From: Tamar Christina
> Sent: Tuesday, July 5, 2022 4:26 PM
> To: Richard Biener 
> Cc: gcc-patches@gcc.gnu.org; nd ; ja...@redhat.com
> Subject: RE: [PATCH 2/2]middle-end: Support recognition of three-way
> max/min.
> 
> > >   }
> > > +  else if (EDGE_SUCC (bb1, 0)->dest == EDGE_SUCC (bb2, 0)->dest
> > > +&& single_succ_p (bb1)
> > > +&& single_succ_p (bb2)
> > > +&& single_pred_p (bb1)
> > > +&& single_pred_p (bb2)
> > > +&& single_succ_p (EDGE_SUCC (bb1, 0)->dest))
> >
> > please do the single_succ/pred checks below where appropriate, also
> > what's the last check about?
> 
> Done.
> 
> > why does the merge block need a single successor?
> 
> I was using it to fix an ICE, but I realize that's not the right fix. I'm now
> checking If the BB is empty instead, in which case it's just a fall through 
> edge
> so don't treat it as a diamond.
> 
> >
> > > + {
> > > +   gimple_stmt_iterator it1 = gsi_start_nondebug_after_labels_bb
> > (bb1);
> > > +   gimple_stmt_iterator it2 = gsi_start_nondebug_after_labels_bb
> > (bb2);
> > > +   if (gsi_one_before_end_p (it1) && gsi_one_before_end_p (it2))
> > > + {
> > > +   gimple *stmt1 = gsi_stmt (it1);
> > > +   gimple *stmt2 = gsi_stmt (it2);
> > > +   if (is_gimple_assign (stmt1) && is_gimple_assign (stmt2))
> > > + {
> > > +   enum tree_code code1 = gimple_assign_rhs_code (stmt1);
> > > +   enum tree_code code2 = gimple_assign_rhs_code (stmt2);
> > > +   diamond_minmax_p
> > > + = (code1 == MIN_EXPR || code1 == MAX_EXPR)
> > > +   && (code2 == MIN_EXPR || code2 == MAX_EXPR);
> > > + }
> > > + }
> > > + }
> >
> > I'd generalize this to general diamond detection, simply cutting off
> > *_replacement workers that do not handle diamonds and do appropriate
> > checks in minmax_replacement only.
> >
> 
> Done.
> 
> > >else
> > >   continue;
> > >
> > > @@ -316,6 +340,13 @@ tree_ssa_phiopt_worker (bool do_store_elim,
> > bool do_hoist_loads, bool early_p)
> > > if (!candorest)
> > >   continue;
> > >
> > > +   /* Check that we're looking for nested phis.  */
> > > +   if (phis == NULL && diamond_minmax_p)
> > > + {
> > > +   phis = phi_nodes (EDGE_SUCC (bb2, 0)->dest);
> > > +   e2 = EDGE_SUCC (bb2, 0);
> > > + }
> > > +
> >
> > instead
> >
> >   basic_block merge = diamond_p ? EDGE_SUCC (bb2, 0)->dest : bb2;
> >   gimple_seq phis = phi_nodes (merge);
> >
> 
> Done.
> 
> >
> > > phi = single_non_singleton_phi_for_edges (phis, e1, e2);
> > > if (!phi)
> > >   continue;
> > > @@ -329,6 +360,7 @@ tree_ssa_phiopt_worker (bool do_store_elim,
> bool
> > > do_hoist_loads, bool early_p)
> > >
> > > gphi *newphi;
> > > if (single_pred_p (bb1)
> > > +   && !diamond_minmax_p
> > > && (newphi = factor_out_conditional_conversion (e1, e2, phi,
> > > arg0, arg1,
> > > cond_stmt)))
> > > @@ -343,20 +375,25 @@ tree_ssa_phiopt_worker (bool do_store_elim,
> > bool do_hoist_loads, bool early_p)
> > >   }
> > >
> > > /* Do the replacement of conditional if it can be done.  */
> > > -   if (!early_p && two_value_replacement (bb, bb1, e2, phi, arg0,
> > arg1))
> > > +   if (!early_p
> > > +   && !diamond_minmax_p
> > > +   && two_value_replacement (bb, bb1, e2, phi, arg0, arg1))
> > >   cfgchanged = true;
> > > -   else if (match_simplify_replacement (bb, bb1, e1, e2, phi,
> > > -arg0, arg1,
> > > -early_p))
> > > +   else if (!diamond_minmax_p
> > > +&& match_simplify_replacement (bb, bb1, e1, e2, phi,
> > > +   arg0, arg1, early_p))
> > >   cfgchanged = true;
> > > else if (!early_p
> > > +&& !diamond_minmax_p
> > >  && single_pred_p (bb1)
> > >  && cond_removal_in_builtin_zero_pattern (bb, bb1, e1,
> > e2,
> > >   phi, arg0, arg1))
> > >   cfgchanged = true;
> > > -   else if (minmax_replacement (bb, bb1, e1, e2, phi, arg0, arg1))
> > > +   else if (minmax_replacement (bb, bb1, bb2, e1, e2, phi, arg0, arg1,
> > > +diamond_minmax_p))
> > >   cfgchanged = true;
> > > else if (single_pred_p (bb1)
> > > +&& !diamond_minmax_p
> > >  && spaceship_replacement (bb, bb1, e1, e2, phi, arg0,
> > arg1))
> > >   cfgchanged = true;
> > >   }
> > > @@ -385,7 +422,7 @@ tree_ssa_phiopt_worker (bool do_store_elim,
> bool
> > > do_hoist_loads, bool early_p)
> > >
> > >  static void
> > >  replace_phi_edge_with_variable (basic_block cond_block,
> > > - edge e, gphi *phi, tree new_tree)
> > > + edge 

Re: [PATCH 3/3] lto-plugin: implement LDPT_GET_API_VERSION

[Rui Ueyama via Gcc-patches]

I'm fine, though I don't think I have a right to sign off.

On Tue, Jul 12, 2022 at 3:36 PM Martin Liška  wrote:
>
> On 7/12/22 08:28, Richard Biener wrote:
> > On Mon, Jul 11, 2022 at 6:35 PM Alexander Monakov  
> > wrote:
> >>
> >> On Mon, 11 Jul 2022, Martin Liška wrote:
> >>
> >>> I've clarified that linker should return a value that is in range
> >>> [minimal_api_supported, maximal_api_supported] and added an abort
> >>> if it's not the case.
> >>
> >> I noticed that we are placing a trap for C++ consumers such as mold
> >> by passing min/max_api_supported as enum values. Unlike C, C++ disallows
> >> out-of-range enum values, so when mold does
> >>
> >> enum PluginLinkerAPIVersion {
> >>   LAPI_V0 = 0,
> >>   LAPI_V1,
> >> };
> >>
> >> get_api_version(const char *plugin_identifier,
> >> unsigned plugin_version,
> >> PluginLinkerAPIVersion minimal_api_supported,
> >> PluginLinkerAPIVersion maximal_api_supported,
> >> const char **linker_identifier,
> >> const char **linker_version) {
> >>
> >> checks such as 'min_api_supported > LAPI_V1' can be optimized out. Also,
> >> if a future tool passes LAPI_V2, it will trigger Clang's UBSan (GCC
> >> -fsanitize-undefined=enum instruments loads but not retrieval of function
> >> arguments).
> >>
> >> I'd suggest to fix this on both sides by changing the arguments to plain
> >> integer types.
> >
> > That's a good point - the enum itself is then also somewhat redundant
> > if it just specifies symbolic names for 0, 1, ... but we can keep it for
> > documentation purposes.
>
> All right, here we go with the integer types.
>
> May I install the version now?
>
> Thanks,
> Martin
>
> >
> >>
> >> Alexander

Re: XFAIL 'offloading_enabled' diagnostics issue in 'libgomp.oacc-c-c++-common/reduction-5.c' [PR101551] (was: Enhance '_Pragma' diagnostics verification in OMP C/C++ test cases)

[Lewis Hyatt via Gcc-patches]

On Tue, Jul 12, 2022 at 2:33 AM Thomas Schwinge  wrote:
>
> Hi!
>
> On 2022-07-11T11:27:12+0200, I wrote:
> > [...], I've just pushed to master branch
> > commit 06b2a2abe26554c6f9365676683d67368cbba206
> > "Enhance '_Pragma' diagnostics verification in OMP C/C++ test cases"
>
> > --- a/libgomp/testsuite/libgomp.oacc-c-c++-common/reduction-5.c
> > +++ b/libgomp/testsuite/libgomp.oacc-c-c++-common/reduction-5.c
> > @@ -17,7 +17,7 @@ const int n = 100;
> >  #define check_reduction(gwv_par, gwv_loop)   \
> >{  \
> >s1 = 2; s2 = 5;\
> > -DO_PRAGMA (acc parallel gwv_par copy (s1, s2))   \
> > +DO_PRAGMA (acc parallel gwv_par copy (s1, s2)) /* { dg-line DO_PRAGMA_loc 
> > } */ \
> >  DO_PRAGMA (acc loop gwv_loop reduction (+:s1, s2))   \
> >  for (i = 0; i < n; i++)  \
> >{  \
> > @@ -45,8 +45,10 @@ main (void)
> >
> >/* Nvptx targets require a vector_length or 32 in to allow spinlocks with
> >   gangs.  */
> > -  check_reduction (num_workers (nw) vector_length (vl), worker);
> > -  /* { dg-warning "region is vector partitioned but does not contain 
> > vector partitioned code" "test1" { target *-*-* } pragma_loc } */
> > +  check_reduction (num_workers (nw) vector_length (vl), worker); /* { 
> > dg-line check_reduction_loc }
> > +  /* { dg-warning "22:region is vector partitioned but does not contain 
> > vector partitioned code" "" { target *-*-* } pragma_loc }
> > + { dg-note "1:in expansion of macro 'DO_PRAGMA'" "" { target *-*-* } 
> > DO_PRAGMA_loc }
> > + { dg-note "3:in expansion of macro 'check_reduction'" "" { target 
> > *-*-* } check_reduction_loc } */
>
> Oh my, PR101551 "[offloading] Differences in diagnostics etc."
> strikes again...  The latter two 'note' diagnostics are currently
> only emitted in non-offloading configurations.  I've now pushed to
> master branch commit 3723aedaad20a129741c2f6f3c22b3dd1220a3fc
> "XFAIL 'offloading_enabled' diagnostics issue in
> 'libgomp.oacc-c-c++-common/reduction-5.c' [PR101551]", see attached.
>

Would you mind please confirming how I need to run configure in order
to get this configuration? Then I can look into why the difference in
location information there. Thanks

-Lewis

[PATCH] aarch64: Remove redundant builtins code

[Richard Sandiford via Gcc-patches]

aarch64_builtin_vectorized_function handles some built-in functions
that already have equivalent internal functions.  This seems to be
redundant now, since the target builtins that it chooses are mapped
to the same optab patterns as the internal functions.

Tested on aarch64-linux-gnu & pushed.

Richard


gcc/
* config/aarch64/aarch64-builtins.cc
(aarch64_builtin_vectorized_function): Remove handling of
floor, ceil, trunc, round, nearbyint, sqrt, clz and ctz.

gcc/testsuite/
* gcc.target/aarch64/vect_unary_1.c: New test.
---
 gcc/config/aarch64/aarch64-builtins.cc|  32 ---
 .../gcc.target/aarch64/vect_unary_1.c | 186 ++
 2 files changed, 186 insertions(+), 32 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/aarch64/vect_unary_1.c

diff --git a/gcc/config/aarch64/aarch64-builtins.cc 
b/gcc/config/aarch64/aarch64-builtins.cc
index e0a741ac663..a486321e10f 100644
--- a/gcc/config/aarch64/aarch64-builtins.cc
+++ b/gcc/config/aarch64/aarch64-builtins.cc
@@ -2581,38 +2581,6 @@ aarch64_builtin_vectorized_function (unsigned int fn, 
tree type_out,
   switch (fn)
 {
 #undef AARCH64_CHECK_BUILTIN_MODE
-#define AARCH64_CHECK_BUILTIN_MODE(C, N) \
-  (out_mode == V##C##N##Fmode && in_mode == V##C##N##Fmode)
-CASE_CFN_FLOOR:
-  return AARCH64_FIND_FRINT_VARIANT (floor);
-CASE_CFN_CEIL:
-  return AARCH64_FIND_FRINT_VARIANT (ceil);
-CASE_CFN_TRUNC:
-  return AARCH64_FIND_FRINT_VARIANT (btrunc);
-CASE_CFN_ROUND:
-  return AARCH64_FIND_FRINT_VARIANT (round);
-CASE_CFN_NEARBYINT:
-  return AARCH64_FIND_FRINT_VARIANT (nearbyint);
-CASE_CFN_SQRT:
-  return AARCH64_FIND_FRINT_VARIANT (sqrt);
-#undef AARCH64_CHECK_BUILTIN_MODE
-#define AARCH64_CHECK_BUILTIN_MODE(C, N) \
-  (out_mode == V##C##SImode && in_mode == V##C##N##Imode)
-CASE_CFN_CLZ:
-  {
-   if (AARCH64_CHECK_BUILTIN_MODE (4, S))
- return aarch64_builtin_decls[AARCH64_SIMD_BUILTIN_UNOP_clzv4si];
-   return NULL_TREE;
-  }
-CASE_CFN_CTZ:
-  {
-   if (AARCH64_CHECK_BUILTIN_MODE (2, S))
- return aarch64_builtin_decls[AARCH64_SIMD_BUILTIN_UNOP_ctzv2si];
-   else if (AARCH64_CHECK_BUILTIN_MODE (4, S))
- return aarch64_builtin_decls[AARCH64_SIMD_BUILTIN_UNOP_ctzv4si];
-   return NULL_TREE;
-  }
-#undef AARCH64_CHECK_BUILTIN_MODE
 #define AARCH64_CHECK_BUILTIN_MODE(C, N) \
   (out_mode == V##C##N##Imode && in_mode == V##C##N##Fmode)
 CASE_CFN_IFLOOR:
diff --git a/gcc/testsuite/gcc.target/aarch64/vect_unary_1.c 
b/gcc/testsuite/gcc.target/aarch64/vect_unary_1.c
new file mode 100644
index 000..8516808becf
--- /dev/null
+++ b/gcc/testsuite/gcc.target/aarch64/vect_unary_1.c
@@ -0,0 +1,186 @@
+/* { dg-options "-O3 --save-temps" } */
+/* { dg-final { check-function-bodies "**" "" "" } } */
+
+#include 
+
+#define TEST2(OUT, NAME, IN)   \
+OUT __attribute__((vector_size(sizeof(OUT) * 2)))  \
+test2_##OUT##_##NAME##_##IN (float dummy,  \
+IN __attribute__((vector_size(sizeof(IN) * 2))) y) 
\
+{  \
+  OUT __attribute__((vector_size(sizeof(OUT) * 2))) x; \
+  x[0] = __builtin_##NAME (y[0]);  \
+  x[1] = __builtin_##NAME (y[1]);  \
+  return x;\
+}  \
+
+#define TEST4(OUT, NAME, IN)   \
+OUT __attribute__((vector_size(16)))   \
+test4_##OUT##_##NAME##_##IN (float dummy,  \
+IN __attribute__((vector_size(16))) y) \
+{  \
+  OUT __attribute__((vector_size(16))) x;  \
+  x[0] = __builtin_##NAME (y[0]);  \
+  x[1] = __builtin_##NAME (y[1]);  \
+  x[2] = __builtin_##NAME (y[2]);  \
+  x[3] = __builtin_##NAME (y[3]);  \
+  return x;\
+}  \
+
+/*
+** test2_float_truncf_float:
+** frintz  v0.2s, v1.2s
+** ret
+*/
+TEST2 (float, truncf, float)
+
+/*
+** test2_double_trunc_double:
+** frintz  v0.2d, v1.2d
+** ret
+*/
+TEST2 (double, trunc, double)
+
+/*
+** test4_float_truncf_float:
+** frintz  v0.4s, v1.4s
+** ret
+*/
+TEST4 (float, truncf, float)
+
+/*
+** test2_float_roundf_float:
+** frinta  v0.2s, v1.2s
+** ret
+*/
+TEST2 (float, roundf, float)
+
+/*
+** test2_double_round_dou

[PATCH] Add internal functions for iround etc. [PR106253]

[Richard Sandiford via Gcc-patches]

The PR is about the aarch64 port using an ACLE built-in function
to vectorise a scalar function call, even though the ECF_* flags for
the ACLE function didn't match the ECF_* flags for the scalar call.

To some extent that kind of difference is inevitable, since the
ACLE intrinsics are supposed to follow the behaviour of the
underlying instruction as closely as possible.  Also, using
target-specific builtins has the drawback of limiting further
gimple optimisation, since the gimple optimisers won't know what
the function does.

We handle several other maths functions, including round, floor
and ceil, by defining directly-mapped internal functions that
are linked to the associated built-in functions.  This has two
main advantages:

- it means that, internally, we are not restricted to the set of
  scalar types that happen to have associated C/C++ functions

- the functions (and thus the underlying optabs) extend naturally
  to vectors

This patch takes the same approach for the remaining functions
handled by aarch64_builtin_vectorized_function.

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

Richard


gcc/
PR target/106253
* predict.h (insn_optimization_type): Declare.
* predict.cc (insn_optimization_type): New function.
* internal-fn.def (IFN_ICEIL, IFN_IFLOOR, IFN_IRINT, IFN_IROUND)
(IFN_LCEIL, IFN_LFLOOR, IFN_LRINT, IFN_LROUND, IFN_LLCEIL)
(IFN_LLFLOOR, IFN_LLRINT, IFN_LLROUND): New internal functions.
* internal-fn.cc (unary_convert_direct): New macro.
(expand_convert_optab_fn): New function.
(expand_unary_convert_optab_fn): New macro.
(direct_unary_convert_optab_supported_p): Likewise.
* optabs.cc (expand_sfix_optab): Pass insn_optimization_type to
convert_optab_handler.
* config/aarch64/aarch64-protos.h
(aarch64_builtin_vectorized_function): Delete.
* config/aarch64/aarch64-builtins.cc
(aarch64_builtin_vectorized_function): Delete.
* config/aarch64/aarch64.cc
(TARGET_VECTORIZE_BUILTIN_VECTORIZED_FUNCTION): Delete.
* config/i386/i386.cc (ix86_optab_supported_p): Handle lround_optab.
* config/i386/i386.md (lround2): Remove
optimize_insn_for_size_p test.

gcc/testsuite/
PR target/106253
* gcc.target/aarch64/vect_unary_1.c: Add tests for iroundf,
llround, iceilf, llceil, ifloorf, llfloor, irintf and llrint.
* gfortran.dg/vect/pr106253.f: New test.
---
 gcc/config/aarch64/aarch64-builtins.cc| 83 ---
 gcc/config/aarch64/aarch64-protos.h   |  1 -
 gcc/config/aarch64/aarch64.cc |  4 -
 gcc/config/i386/i386.cc   |  1 +
 gcc/config/i386/i386.md   |  3 -
 gcc/internal-fn.cc| 20 +
 gcc/internal-fn.def   | 23 +
 gcc/optabs.cc |  3 +-
 gcc/predict.cc| 11 +++
 gcc/predict.h |  1 +
 .../gcc.target/aarch64/vect_unary_1.c | 65 ++-
 gcc/testsuite/gfortran.dg/vect/pr106253.f | 35 
 12 files changed, 157 insertions(+), 93 deletions(-)
 create mode 100644 gcc/testsuite/gfortran.dg/vect/pr106253.f

diff --git a/gcc/config/aarch64/aarch64-builtins.cc 
b/gcc/config/aarch64/aarch64-builtins.cc
index a486321e10f..adfddb8b215 100644
--- a/gcc/config/aarch64/aarch64-builtins.cc
+++ b/gcc/config/aarch64/aarch64-builtins.cc
@@ -2555,89 +2555,6 @@ aarch64_general_expand_builtin (unsigned int fcode, tree 
exp, rtx target,
   gcc_unreachable ();
 }
 
-tree
-aarch64_builtin_vectorized_function (unsigned int fn, tree type_out,
-tree type_in)
-{
-  machine_mode in_mode, out_mode;
-
-  if (TREE_CODE (type_out) != VECTOR_TYPE
-  || TREE_CODE (type_in) != VECTOR_TYPE)
-return NULL_TREE;
-
-  out_mode = TYPE_MODE (type_out);
-  in_mode = TYPE_MODE (type_in);
-
-#undef AARCH64_CHECK_BUILTIN_MODE
-#define AARCH64_CHECK_BUILTIN_MODE(C, N) 1
-#define AARCH64_FIND_FRINT_VARIANT(N) \
-  (AARCH64_CHECK_BUILTIN_MODE (2, D) \
-? aarch64_builtin_decls[AARCH64_SIMD_BUILTIN_UNOP_##N##v2df] \
-: (AARCH64_CHECK_BUILTIN_MODE (4, S) \
-   ? aarch64_builtin_decls[AARCH64_SIMD_BUILTIN_UNOP_##N##v4sf] \
-   : (AARCH64_CHECK_BUILTIN_MODE (2, S) \
-  ? aarch64_builtin_decls[AARCH64_SIMD_BUILTIN_UNOP_##N##v2sf] \
-  : NULL_TREE)))
-  switch (fn)
-{
-#undef AARCH64_CHECK_BUILTIN_MODE
-#define AARCH64_CHECK_BUILTIN_MODE(C, N) \
-  (out_mode == V##C##N##Imode && in_mode == V##C##N##Fmode)
-CASE_CFN_IFLOOR:
-CASE_CFN_LFLOOR:
-CASE_CFN_LLFLOOR:
-  {
-   enum aarch64_builtins builtin;
-   if (AARCH64_CHECK_BUILTIN_MODE (2, D))
- builtin = AARCH64_SIMD_BUILTIN_UNOP_lfloorv2dfv2di;
-   else if (AARCH64_CHECK_BUILTIN_MODE (4, S))
- builtin = AARCH64_SIMD_BUILTIN_U

[Ada] Remove excessive guard in detection of access-to-variable objects

[Pierre-Marie de Rodat via Gcc-patches]

It is safe to call Is_Access_Variable without calling
Is_Access_Object_Type before. Compiler cleanup only; semantics is
unaffected.

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

gcc/ada/

* sem_util.adb (Is_Variable): Remove excessive guard.diff --git a/gcc/ada/sem_util.adb b/gcc/ada/sem_util.adb
--- a/gcc/ada/sem_util.adb
+++ b/gcc/ada/sem_util.adb
@@ -21896,7 +21896,6 @@ package body Sem_Util is
   or else (K = E_Component
 and then not In_Protected_Function (E))
   or else (Present (Etype (E))
-and then Is_Access_Object_Type (Etype (E))
 and then Is_Access_Variable (Etype (E))
 and then Is_Dereferenced (N))
   or else K = E_Out_Parameter

[Ada] Warn about unreachable code after calls with No_Return

[Pierre-Marie de Rodat via Gcc-patches]

GNAT was already warning about unreachable code after raise/goto/exit
statements, but not after calls to procedures with No_Return. Now this
warning is extended.

Also, previously the warning was suppressed for unreachable RETURN after
RAISE statements. Now this suppression is narrowed to functions, because
only in function such a RETURN statement might be indeed needed (where
it is the only RETURN statement of a function).

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

gcc/ada/

* sem_ch5.adb (Check_Unreachable_Code): Extend suppression to
calls with No_Return aspect, but narrow it to functions.
* sem_res.adb (Resolve_Call): Warn about unreachable code after
calls with No_Return.diff --git a/gcc/ada/sem_ch5.adb b/gcc/ada/sem_ch5.adb
--- a/gcc/ada/sem_ch5.adb
+++ b/gcc/ada/sem_ch5.adb
@@ -4418,12 +4418,20 @@ package body Sem_Ch5 is
  elsif Comes_From_Source (Nxt)
and then Is_Statement (Nxt)
  then
---  Special very annoying exception. If we have a return that
---  follows a raise, then we allow it without a warning, since
---  the Ada RM annoyingly requires a useless return here.
-
-if Nkind (Original_Node (N)) /= N_Raise_Statement
-  or else Nkind (Nxt) /= N_Simple_Return_Statement
+--  Special very annoying exception. Ada RM 6.5(5) annoyingly
+--  requires functions to have at least one return statement, so
+--  don't complain about a simple return that follows a raise or a
+--  call to procedure with No_Return.
+
+if not (Present (Current_Subprogram)
+and then Ekind (Current_Subprogram) = E_Function
+and then (Nkind (Original_Node (N)) = N_Raise_Statement
+or else
+  (Nkind (N) = N_Procedure_Call_Statement
+   and then Is_Entity_Name (Name (N))
+   and then Present (Entity (Name (N)))
+   and then No_Return (Entity (Name (N)
+and then Nkind (Nxt) = N_Simple_Return_Statement)
 then
--  The rather strange shenanigans with the warning message
--  here reflects the fact that Kill_Dead_Code is very good at


diff --git a/gcc/ada/sem_res.adb b/gcc/ada/sem_res.adb
--- a/gcc/ada/sem_res.adb
+++ b/gcc/ada/sem_res.adb
@@ -62,6 +62,7 @@ with Sem_Case;   use Sem_Case;
 with Sem_Cat;use Sem_Cat;
 with Sem_Ch3;use Sem_Ch3;
 with Sem_Ch4;use Sem_Ch4;
+with Sem_Ch5;use Sem_Ch5;
 with Sem_Ch6;use Sem_Ch6;
 with Sem_Ch8;use Sem_Ch8;
 with Sem_Ch13;   use Sem_Ch13;
@@ -7193,6 +7194,14 @@ package body Sem_Res is
 
   Analyze_Dimension_Call (N, Nam);
 
+  --  Check unreachable code after calls to procedures with No_Return
+
+  if Ekind (Nam) = E_Procedure
+and then No_Return (Nam)
+  then
+ Check_Unreachable_Code (N);
+  end if;
+
   --  All done, evaluate call and deal with elaboration issues
 
   Eval_Call (N);

[Ada] Clean up scanner

[Pierre-Marie de Rodat via Gcc-patches]

This patch removes some obsolete code in the scanner and related files,
and corrects some comments. Tok_Special is used only by the
preprocessor, and uses only the two characters '#' and '$'.

It might be simpler to have a single flag indicating we're scanning for
preprocessing, instead of the Special_Characters array and the
End_Of_Line_Is_Token flag, but that's for another day.

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

gcc/ada/

* scans.ads: Fix obsolete comments about Tok_Special, and give
Special_Character a predicate assuring it is one of the two
characters used in preprocessing.
* scng.ads: Clean up comments.
* scng.adb: Clean up handling of Tok_Special.  Remove comment
about '@' (target_name), which doesn't seem very helpful.
Set_Special_Character will now blow up if given anything other
than '#' and '$', because of the predicate on Special_Character;
it's not clear why it used to say "when others => null;".
Remove Comment_Is_Token, which is not used.
* scn.ads: Remove commented-out use clause.  Remove redundant
comment.
* ali-util.adb: Use "is null" for do-nothing procedures.
* gprep.adb (Post_Scan): Use "is null".diff --git a/gcc/ada/ali-util.adb b/gcc/ada/ali-util.adb
--- a/gcc/ada/ali-util.adb
+++ b/gcc/ada/ali-util.adb
@@ -42,15 +42,12 @@ package body ALI.Util is
--  empty, because we don't want to report any errors when computing
--  a source checksum.
 
-   procedure Post_Scan;
+   procedure Post_Scan is null;
 
-   procedure Error_Msg (Msg : String; Flag_Location : Source_Ptr);
-
-   procedure Error_Msg_S (Msg : String);
-
-   procedure Error_Msg_SC (Msg : String);
-
-   procedure Error_Msg_SP (Msg : String);
+   procedure Error_Msg (Msg : String; Flag_Location : Source_Ptr) is null;
+   procedure Error_Msg_S (Msg : String) is null;
+   procedure Error_Msg_SC (Msg : String) is null;
+   procedure Error_Msg_SP (Msg : String) is null;
 
--  Instantiation of Styleg, needed to instantiate Scng
 
@@ -85,47 +82,6 @@ package body ALI.Util is
   return Checksum1 = Checksum2 and then Checksum1 /= Checksum_Error;
end Checksums_Match;
 
-   ---
-   -- Error_Msg --
-   ---
-
-   procedure Error_Msg (Msg : String; Flag_Location : Source_Ptr) is
-  pragma Warnings (Off, Msg);
-  pragma Warnings (Off, Flag_Location);
-   begin
-  null;
-   end Error_Msg;
-
-   -
-   -- Error_Msg_S --
-   -
-
-   procedure Error_Msg_S (Msg : String) is
-  pragma Warnings (Off, Msg);
-   begin
-  null;
-   end Error_Msg_S;
-
-   --
-   -- Error_Msg_SC --
-   --
-
-   procedure Error_Msg_SC (Msg : String) is
-  pragma Warnings (Off, Msg);
-   begin
-  null;
-   end Error_Msg_SC;
-
-   --
-   -- Error_Msg_SP --
-   --
-
-   procedure Error_Msg_SP (Msg : String) is
-  pragma Warnings (Off, Msg);
-   begin
-  null;
-   end Error_Msg_SP;
-
---
-- Get_File_Checksum --
---
@@ -192,15 +148,6 @@ package body ALI.Util is
   Interfaces.Reset;
end Initialize_ALI_Source;
 
-   ---
-   -- Post_Scan --
-   ---
-
-   procedure Post_Scan is
-   begin
-  null;
-   end Post_Scan;
-
--
-- Read_Withed_ALIs --
--


diff --git a/gcc/ada/gprep.adb b/gcc/ada/gprep.adb
--- a/gcc/ada/gprep.adb
+++ b/gcc/ada/gprep.adb
@@ -93,8 +93,8 @@ package body GPrep is
procedure Display_Copyright;
--  Display the copyright notice
 
-   procedure Post_Scan;
-   --  Null procedure, needed by instantiation of Scng below
+   procedure Post_Scan is null;
+   --  Needed by instantiation of Scng below
 
package Scanner is new Scng
  (Post_Scan,
@@ -327,15 +327,6 @@ package body GPrep is
   New_Line (Outfile.all);
end New_EOL_To_Outfile;
 
-   ---
-   -- Post_Scan --
-   ---
-
-   procedure Post_Scan is
-   begin
-  null;
-   end Post_Scan;
-

-- Preprocess_Infile_Name --



diff --git a/gcc/ada/scans.ads b/gcc/ada/scans.ads
--- a/gcc/ada/scans.ads
+++ b/gcc/ada/scans.ads
@@ -210,15 +210,11 @@ package Scans is
 
   Tok_End_Of_Line,
   --  Represents an end of line. Not used during normal compilation scans
-  --  where end of line is ignored. Active for preprocessor scanning and
-  --  also when scanning project files (where it is needed because of ???)
+  --  where end of line is ignored. Active for preprocessor scanning.
 
   Tok_Special,
-  --  AI12-0125-03 : target name as abbreviation for LHS
-
-  --  Otherwise used only in preprocessor scanning (to represent one of
-  --  the characters '#', '$', '?', '@', '`', '\', '^', '~', or '_'. The
-  --  character value itself is stored in 

[Ada] Add new unbounded and indefinite formal doubly linked list

[Pierre-Marie de Rodat via Gcc-patches]

Before this patch, the only formal doubly linked lists were bounded and
definite. This means that it is necessary to provide their maximum
length or capacity at instantiation and that they can only be used with
definite element types.

The formal lists added by this patch are unbounded and indefinite.
Their length grows dynamically until Count_Type'Last. This makes them
easier to use but requires the use of dynamic allocation and controlled
types.

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

gcc/ada/

* libgnat/a-cfidll.adb, libgnat/a-cfidll.ads: Implementation
files of the formal unbounded indefinite list.
* Makefile.rtl, impunit.adb: Take into account the add of the
new files.

patch.diff.gz
Description: application/gzip

[Ada] Add one more leading underscore to couple of exported symbols

[Pierre-Marie de Rodat via Gcc-patches]

For the sake of consistency with other runtime units.

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

gcc/ada/

* libgnat/s-stchop.ads: Use a double underscore prefix for symbols.diff --git a/gcc/ada/libgnat/s-stchop.ads b/gcc/ada/libgnat/s-stchop.ads
--- a/gcc/ada/libgnat/s-stchop.ads
+++ b/gcc/ada/libgnat/s-stchop.ads
@@ -72,7 +72,7 @@ package System.Stack_Checking.Operations is
 private
Cache : aliased Stack_Access := Null_Stack;
 
-   pragma Export (C, Cache, "_gnat_stack_cache");
-   pragma Export (C, Stack_Check, "_gnat_stack_check");
+   pragma Export (C, Cache, "__gnat_stack_cache");
+   pragma Export (C, Stack_Check, "__gnat_stack_check");
 
 end System.Stack_Checking.Operations;

[Ada] Ignore exceptions in task termination handlers

[Pierre-Marie de Rodat via Gcc-patches]

This patch fixes a bug in which if the environment task has a specific
termination handler, and that handler raises an exception, the handler
is called recursively, causing infinite recursion. The RM requires such
exceptions to be ignored.

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

gcc/ada/

* libgnarl/s-solita.adb (Task_Termination_Handler_T): Ignore all
exceptions propagated by Specific_Handler.
* libgnarl/s-tassta.adb, libgnarl/s-taskin.ads: Minor.diff --git a/gcc/ada/libgnarl/s-solita.adb b/gcc/ada/libgnarl/s-solita.adb
--- a/gcc/ada/libgnarl/s-solita.adb
+++ b/gcc/ada/libgnarl/s-solita.adb
@@ -188,7 +188,14 @@ package body System.Soft_Links.Tasking is
   --  fall-back handler applies only to the dependent tasks of the task".
 
   if Self_Id.Common.Specific_Handler /= null then
- Self_Id.Common.Specific_Handler.all (Cause, Self_Id, EO);
+ begin
+Self_Id.Common.Specific_Handler.all (Cause, Self_Id, EO);
+ exception
+--  RM-C.7.3(16) requires all exceptions raised here to be ignored
+
+when others =>
+   null;
+ end;
   end if;
end Task_Termination_Handler_T;
 


diff --git a/gcc/ada/libgnarl/s-taskin.ads b/gcc/ada/libgnarl/s-taskin.ads
--- a/gcc/ada/libgnarl/s-taskin.ads
+++ b/gcc/ada/libgnarl/s-taskin.ads
@@ -1168,7 +1168,7 @@ package System.Tasking is
   --
   --  Protection: Self.L. Once a task has set Self.Stage to Completing, it
   --  has exclusive access to this field.
-   end record;
+   end record; -- Ada_Task_Control_Block
 

-- Initialization --


diff --git a/gcc/ada/libgnarl/s-tassta.adb b/gcc/ada/libgnarl/s-tassta.adb
--- a/gcc/ada/libgnarl/s-tassta.adb
+++ b/gcc/ada/libgnarl/s-tassta.adb
@@ -1307,10 +1307,8 @@ package body System.Tasking.Stages is
   if TH /= null then
  begin
 TH.all (Cause, Self_ID, EO);
-
  exception
-
---  RM-C.7.3 requires all exceptions raised here to be ignored
+--  RM-C.7.3(16) requires all exceptions raised here to be ignored
 
 when others =>
null;

[Ada] Fix missing Overflow and Range checks

[Pierre-Marie de Rodat via Gcc-patches]

While doing Preanalysis (as is the case during ghost code handling),
some range and/or overflow checks can be saved (see Saved_Checks in
checks.adb) and later one omitted as they would be redundant (see
Find_Check in checks.adb). In the case of ghost code, the node being
Preanalyzed is a temporary copy that is discarded, so its corresponding
check is not expanded later. The node that gets expanded later is not
having any checks expanded as it is wrongly assumed it has already been
done before.

As is already the case in Preanalyze_And_Resolve, this change suppresses
all checks during Preanalyze except for GNATprove mode.

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

gcc/ada/

* sem.adb (Preanalyze): Suppress checks when not in GNATprove
mode.
* sem_res.adb (Preanalyze_And_Resolve): Add cross reference in
comment to above procedure.
* sinfo.ads: Typo fix in comment.diff --git a/gcc/ada/sem.adb b/gcc/ada/sem.adb
--- a/gcc/ada/sem.adb
+++ b/gcc/ada/sem.adb
@@ -1338,7 +1338,15 @@ package body Sem is
   Full_Analysis := False;
   Expander_Mode_Save_And_Set (False);
 
-  Analyze (N);
+  --  See comment in sem_res.adb for Preanalyze_And_Resolve
+
+  if GNATprove_Mode
+or else Nkind (Parent (N)) = N_Simple_Return_Statement
+  then
+ Analyze (N);
+  else
+ Analyze (N, Suppress => All_Checks);
+  end if;
 
   Expander_Mode_Restore;
   Full_Analysis := Save_Full_Analysis;


diff --git a/gcc/ada/sem_res.adb b/gcc/ada/sem_res.adb
--- a/gcc/ada/sem_res.adb
+++ b/gcc/ada/sem_res.adb
@@ -2046,16 +2046,18 @@ package body Sem_Res is
   Full_Analysis := False;
   Expander_Mode_Save_And_Set (False);
 
+  --  See also Preanalyze_And_Resolve in sem.adb for similar handling
+
   --  Normally, we suppress all checks for this preanalysis. There is no
   --  point in processing them now, since they will be applied properly
   --  and in the proper location when the default expressions reanalyzed
   --  and reexpanded later on. We will also have more information at that
   --  point for possible suppression of individual checks.
 
-  --  However, in SPARK mode, most expansion is suppressed, and this
-  --  later reanalysis and reexpansion may not occur. SPARK mode does
+  --  However, in GNATprove mode, most expansion is suppressed, and this
+  --  later reanalysis and reexpansion may not occur. GNATprove mode does
   --  require the setting of checking flags for proof purposes, so we
-  --  do the SPARK preanalysis without suppressing checks.
+  --  do the GNATprove preanalysis without suppressing checks.
 
   --  This special handling for SPARK mode is required for example in the
   --  case of Ada 2012 constructs such as quantified expressions, which are


diff --git a/gcc/ada/sinfo.ads b/gcc/ada/sinfo.ads
--- a/gcc/ada/sinfo.ads
+++ b/gcc/ada/sinfo.ads
@@ -554,9 +554,9 @@ package Sinfo is
--  The tree after this light expansion should be fully analyzed
--  semantically, which sometimes requires the insertion of semantic
--  preanalysis, for example for subprogram contracts and pragma
-   --  check/assert. In particular, all expression must have their proper type,
-   --  and semantic links should be set between tree nodes (partial to full
-   --  view, etc.) Some kinds of nodes should be either absent, or can be
+   --  check/assert. In particular, all expressions must have their proper
+   --  type, and semantic links should be set between tree nodes (partial to
+   --  full view, etc.). Some kinds of nodes should be either absent, or can be
--  ignored by the formal verification backend:
 
--  N_Object_Renaming_Declaration: can be ignored safely

[Ada] Proper freezing for dispatching expression functions.

[Pierre-Marie de Rodat via Gcc-patches]

In the case of an expression function that is a primitive function of a
tagged type, freezing the tagged type needs to freeze the function (and
its return expression). A bug in this area could result in incorrect
behavior both at compile time and at run time. At compile time, freezing
rule violations could go undetected so that an illegal program could be
incorrectly accepted. At run time, a dispatching call to the primitive
function could end up dispatching through a not-yet-initialized slot in
the dispatch table, typically (although not always) resulting in a
segmentation fault.

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

gcc/ada/

* freeze.adb (Check_Expression_Function.Find_Constant): Add a
check that a type that is referenced as the prefix of an
attribute is fully declared.
(Freeze_And_Append): Do not freeze the profile when freezing an
expression function.
(Freeze_Entity): When a tagged type is frozen, also freeze any
primitive operations of the type that are expression functions.
* sem_ch6.adb (Analyze_Subprogram_Body_Helper): Do not prevent
freezing associated with an expression function body if the
function is a dispatching op.diff --git a/gcc/ada/freeze.adb b/gcc/ada/freeze.adb
--- a/gcc/ada/freeze.adb
+++ b/gcc/ada/freeze.adb
@@ -1470,6 +1470,10 @@ package body Freeze is
 if Is_Entity_Name (Prefix (Nod))
   and then Is_Type (Entity (Prefix (Nod)))
 then
+   if Expander_Active then
+  Check_Fully_Declared (Entity (Prefix (Nod)), N);
+   end if;
+
Freeze_Before (N, Entity (Prefix (Nod)));
 end if;
  end if;
@@ -2632,7 +2636,13 @@ package body Freeze is
   N  : Node_Id;
   Result : in out List_Id)
is
-  L : constant List_Id := Freeze_Entity (Ent, N);
+  --  Freezing an Expression_Function does not freeze its profile:
+  --  the formals will have been frozen otherwise before the E_F
+  --  can be called.
+
+  L : constant List_Id :=
+Freeze_Entity
+  (Ent, N, Do_Freeze_Profile => not Is_Expression_Function (Ent));
begin
   if Is_Non_Empty_List (L) then
  if Result = No_List then
@@ -7807,11 +7817,37 @@ package body Freeze is
  --  type itself is frozen, because the class-wide type refers to the
  --  tagged type which generates the class.
 
+ --  For a tagged type, freeze explicitly those primitive operations
+ --  that are expression functions, which otherwise have no clear
+ --  freeze point: these have to be frozen before the dispatch table
+ --  for the type is built, and before any explicit call to the
+ --  primitive, which would otherwise be the freeze point for it.
+
  if Is_Tagged_Type (E)
and then not Is_Class_Wide_Type (E)
and then Present (Class_Wide_Type (E))
  then
 Freeze_And_Append (Class_Wide_Type (E), N, Result);
+
+declare
+   Ops  : constant Elist_Id := Primitive_Operations (E);
+
+   Elmt : Elmt_Id;
+   Subp : Entity_Id;
+
+begin
+   if Ops /= No_Elist  then
+  Elmt := First_Elmt (Ops);
+  while Present (Elmt) loop
+ Subp := Node (Elmt);
+ if Is_Expression_Function (Subp) then
+Freeze_And_Append (Subp, N, Result);
+ end if;
+
+ Next_Elmt (Elmt);
+  end loop;
+   end if;
+end;
  end if;
   end if;
 


diff --git a/gcc/ada/sem_ch6.adb b/gcc/ada/sem_ch6.adb
--- a/gcc/ada/sem_ch6.adb
+++ b/gcc/ada/sem_ch6.adb
@@ -4508,7 +4508,16 @@ package body Sem_Ch6 is
 --  This also needs to be done in the case of an ignored Ghost
 --  expression function, where the expander isn't active.
 
-Set_Is_Frozen (Spec_Id);
+--  A further complication arises if the expression function is
+--  a primitive operation of a tagged type: in that case the
+--  function entity must be frozen before the dispatch table for
+--  the type is constructed, so it will be frozen like other local
+--  entities, at the end of the current scope.
+
+if not Is_Dispatching_Operation (Spec_Id) then
+   Set_Is_Frozen (Spec_Id);
+end if;
+
 Mask_Types := Mask_Unfrozen_Types (Spec_Id);
 
  elsif not Is_Frozen (Spec_Id)

[Ada] Fix spurious warning on unreferenced internal generic instance

[Pierre-Marie de Rodat via Gcc-patches]

This patch removes a spurious warning, saying that an internal entity of
a generic formal package is unreferenced. The immediate cause of this
warning is that the internal entity is explicitly flagged as coming from
source.

The explicit flagging was added decades ago to fix a missing
cross-reference in the ALI file. Apparently these days the
cross-references work fine without this flag.

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

gcc/ada/

* sem_ch12.adb (Analyze_Package_Instantiation): Remove dubious
call to Set_Comes_From_Source.diff --git a/gcc/ada/sem_ch12.adb b/gcc/ada/sem_ch12.adb
--- a/gcc/ada/sem_ch12.adb
+++ b/gcc/ada/sem_ch12.adb
@@ -4297,7 +4297,6 @@ package body Sem_Ch12 is
 
   if Nkind (N) = N_Package_Instantiation then
  Act_Decl_Id := New_Copy (Defining_Entity (N));
- Set_Comes_From_Source (Act_Decl_Id, True);
 
  if Nkind (Defining_Unit_Name (N)) = N_Defining_Program_Unit_Name then
 Act_Decl_Name :=

[Ada] Remove out-of-range warning in unreachable code

[Pierre-Marie de Rodat via Gcc-patches]

This patch removes a warning in examples like this:

if cond then
   return; -- or other jump
end if;
X := ...; -- where the value is out of range

where cond is known at compile time. It could, for example, be a generic
formal parameter that is known to be True in some instances.

As a side effect, this patch adds new warnings about unreachable code.

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

gcc/ada/

* gnatls.adb (Output_License_Information): Remove pragma
No_Return; call sites deal with Exit_Program.
* libgnat/g-socthi.adb (C_Connect): Suppress warning about
unreachable code.
* sem_ch5.adb (Check_Unreachable_Code): Special-case if
statements with static conditions.  If we remove unreachable
code (including the return statement) from a function, add
"raise Program_Error", so we won't warn about missing returns.
Remove Original_Node in test for N_Raise_Statement; it's not
needed.  Remove test for CodePeer_Mode; if Operating_Mode =
Generate_Code, then CodePeer_Mode can't be True.  Misc cleanup.
Do not reuse Nxt variable for unrelated purpose (the usage in
the Kill_Dead_Code loop is entirely local to the loop).
* sem_ch6.adb: Add check for Is_Transfer. Misc cleanup.
* sem_prag.adb: Minor.
* sem_res.adb: Minor.
* sem_util.adb: Minor cleanup.
(Is_Trivial_Boolean): Move to nonnested place, so it can be
called from elsewhere.
(Is_Static_Constant_Boolean): New function.
* sem_util.ads (Is_Trivial_Boolean): Export.
(Is_Static_Constant_Boolean): New function.diff --git a/gcc/ada/gnatls.adb b/gcc/ada/gnatls.adb
--- a/gcc/ada/gnatls.adb
+++ b/gcc/ada/gnatls.adb
@@ -189,7 +189,6 @@ procedure Gnatls is
--  Print usage message
 
procedure Output_License_Information;
-   pragma No_Return (Output_License_Information);
--  Output license statement, and if not found, output reference to COPYING
 
function Image (Restriction : Restriction_Id) return String;
@@ -894,8 +893,6 @@ procedure Gnatls is
  & " for license terms.");
 Write_Eol;
   end case;
-
-  Exit_Program (E_Success);
end Output_License_Information;
 
---


diff --git a/gcc/ada/libgnat/g-socthi.adb b/gcc/ada/libgnat/g-socthi.adb
--- a/gcc/ada/libgnat/g-socthi.adb
+++ b/gcc/ada/libgnat/g-socthi.adb
@@ -187,7 +187,9 @@ package body GNAT.Sockets.Thin is
  return Res;
   end if;
 
-  declare
+  pragma Warnings (Off, "unreachable code");
+  declare -- unreachable if Thread_Blocking_IO is statically True
+ pragma Warnings (On, "unreachable code");
  WSet : aliased Fd_Set;
  Now  : aliased Timeval;
 


diff --git a/gcc/ada/sem_ch5.adb b/gcc/ada/sem_ch5.adb
--- a/gcc/ada/sem_ch5.adb
+++ b/gcc/ada/sem_ch5.adb
@@ -4425,7 +4425,7 @@ package body Sem_Ch5 is
 
 if not (Present (Current_Subprogram)
 and then Ekind (Current_Subprogram) = E_Function
-and then (Nkind (Original_Node (N)) = N_Raise_Statement
+and then (Nkind (N) in N_Raise_Statement
 or else
   (Nkind (N) = N_Procedure_Call_Statement
and then Is_Entity_Name (Name (N))
@@ -,39 +,59 @@ package body Sem_Ch5 is
--  unreachable code, since it is useless and we don't want
--  to generate junk warnings.
 
-   --  We skip this step if we are not in code generation mode
-   --  or CodePeer mode.
+   --  We skip this step if we are not in code generation mode.
 
--  This is the one case where we remove dead code in the
--  semantics as opposed to the expander, and we do not want
--  to remove code if we are not in code generation mode, since
--  this messes up the tree or loses useful information for
-   --  CodePeer.
+   --  analysis tools such as CodePeer.
 
--  Note that one might react by moving the whole circuit to
--  exp_ch5, but then we lose the warning in -gnatc mode.
 
-   if Operating_Mode = Generate_Code
- and then not CodePeer_Mode
-   then
+   if Operating_Mode = Generate_Code then
   loop
- Nxt := Next (N);
-
- --  Quit deleting when we have nothing more to delete
- --  or if we hit a label (since someone could transfer
- --  control to a label, so we should not delete it).
+ declare
+Del : constant Node_Id := Next (N);
+--  Node to be possibly deleted
+ begin
+--  Quit deleting

[Ada] Avoid namespace pollution for Next and Previous

[Pierre-Marie de Rodat via Gcc-patches]

This patch renames Next and Previous in a-convec.ads and other
containers to be _Next and _Previous, to avoid namespace pollution.  The
compiler now uses the leading-underscore names to look them up.

The scanner is changed to allow this.

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

gcc/ada/

* exp_ch5.adb (Expand_Iterator_Loop_Over_Array): Use _Next and
_Previous in the optimized expansion of "for ... of".  No longer
need to check parameter profiles for these, because the
leading-underscore names are unique.
* libgnat/a-convec.ads (_Next, _Previous): Renamings of Next and
Previous, to avoid namespace pollution.
* libgnat/a-cbdlli.ads, libgnat/a-cbhama.ads,
libgnat/a-cbhase.ads, libgnat/a-cbmutr.ads,
libgnat/a-cborma.ads, libgnat/a-cborse.ads,
libgnat/a-cdlili.ads, libgnat/a-cidlli.ads,
libgnat/a-cihama.ads, libgnat/a-cihase.ads,
libgnat/a-cimutr.ads, libgnat/a-ciorma.ads,
libgnat/a-ciorse.ads, libgnat/a-cobove.ads,
libgnat/a-cohama.ads, libgnat/a-cohase.ads,
libgnat/a-coinve.ads, libgnat/a-comutr.ads,
libgnat/a-coorma.ads, libgnat/a-coorse.ads: Likewise.  Also,
remove duplicated comments -- refer to one comment about _Next,
_Previous, Pseudo_Reference in libgnat/a-convec.ads. DRY.
* scng.adb (Scan): Allow leading underscores in identifiers in
the run-time library.
* snames.ads-tmpl (Name_uNext, Name_uPrevious): New names with
leading underscores.diff --git a/gcc/ada/exp_ch5.adb b/gcc/ada/exp_ch5.adb
--- a/gcc/ada/exp_ch5.adb
+++ b/gcc/ada/exp_ch5.adb
@@ -4924,7 +4924,8 @@ package body Exp_Ch5 is
 
--  In the optimized case, we make use of these:
 
-   -- procedure Next (Position : in out Cursor); -- instead of Iter.Next
+   -- procedure _Next (Position : in out Cursor); -- instead of Iter.Next
+   --(or _Previous for reverse loops)
 
-- function Pseudo_Reference
--   (Container : aliased Vector'Class) return Reference_Control_Type;
@@ -4939,6 +4940,11 @@ package body Exp_Ch5 is
--  pollute the namespace for clients. The compiler has no trouble breaking
--  privacy to call things in the private part of an instance.)
 
+   --  Note that Next and Previous are renamed as _Next and _Previous with
+   --  leading underscores. Leading underscores are illegal in Ada, but we
+   --  allow them in the run-time library. This allows us to avoid polluting
+   --  the user-visible namespaces.
+
--  Source:
 
--  for X of My_Vector loop
@@ -4989,7 +4995,7 @@ package body Exp_Ch5 is
--  X.Count := X.Count + 1;
--  ...
--
-   --  Next (Cur); -- or Prev
+   --  _Next (Cur); -- or _Previous
--  --  This is instead of "Cur := Next (Iter, Cur);"
--  end;
--  --  No finalization here
@@ -5015,13 +5021,14 @@ package body Exp_Ch5 is
   Stats: List_Id := Statements (N);
   --  Maybe wrapped in a conditional if a filter is present
 
-  Cursor: Entity_Id;
-  Decl  : Node_Id;
-  Iter_Type : Entity_Id;
-  Iterator  : Entity_Id;
-  Name_Init : Name_Id;
-  Name_Step : Name_Id;
-  New_Loop  : Node_Id;
+  Cursor : Entity_Id;
+  Decl   : Node_Id;
+  Iter_Type  : Entity_Id;
+  Iterator   : Entity_Id;
+  Name_Init  : Name_Id;
+  Name_Step  : Name_Id;
+  Name_Fast_Step : Name_Id;
+  New_Loop   : Node_Id;
 
   Fast_Element_Access_Op : Entity_Id := Empty;
   Fast_Step_Op   : Entity_Id := Empty;
@@ -5049,9 +5056,11 @@ package body Exp_Ch5 is
   if Reverse_Present (I_Spec) then
  Name_Init := Name_Last;
  Name_Step := Name_Previous;
+ Name_Fast_Step := Name_uPrevious;
   else
  Name_Init := Name_First;
  Name_Step := Name_Next;
+ Name_Fast_Step := Name_uNext;
   end if;
 
   --  The type of the iterator is the return type of the Iterate function
@@ -5189,14 +5198,13 @@ package body Exp_Ch5 is
 
 Iter_Pack := Scope (Root_Type (Etype (Iter_Type)));
 
---  Find declarations needed for "for ... of" optimization
+--  Find declarations needed for "for ... of" optimization.
 --  These declarations come from GNAT sources or sources
 --  derived from them. User code may include additional
 --  overloadings with similar names, and we need to perforn
 --  some reasonable resolution to find the needed primitives.
---  It is unclear whether this mechanism is fragile if a user
---  makes arbitrary changes to the private part of a package
---  that supports iterators.
+--  Note that we use _Next or _Previous to avoid picking up
+--  some arbitrary user-defined Next or Previous.
 
  

[Ada] Fix buffer overrun for small string concatenation at -O0

[Pierre-Marie de Rodat via Gcc-patches]

The concatenation routines may read too much data on the source side when
the destination buffer is larger than the final result.  This change makes
sure that this does not happen any more and also removes obsolete stuff.

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

gcc/ada/

* rtsfind.ads (RE_Id): Remove RE_Str_Concat_Bounds_N values.
(RE_Unit_Table): Remove RE_Str_Concat_Bounds_N entries.
* libgnat/s-conca2.ads (Str_Concat_2): Adjust head comment.
(Str_Concat_Bounds_2): Delete.
* libgnat/s-conca2.adb (Str_Concat_2): Use the length of the last
input to size the last assignment.
(Str_Concat_Bounds_2): Delete.
* libgnat/s-conca3.ads (Str_Concat_3): Adjust head comment.
(Str_Concat_Bounds_3): Delete.
* libgnat/s-conca3.adb (Str_Concat_3): Use the length of the last
input to size the last assignment.
(Str_Concat_Bounds_3): Delete.
* libgnat/s-conca4.ads (Str_Concat_4): Adjust head comment.
(Str_Concat_Bounds_4): Delete.
* libgnat/s-conca4.adb (Str_Concat_4): Use the length of the last
input to size the last assignment.
(Str_Concat_Bounds_4): Delete.
* libgnat/s-conca5.ads (Str_Concat_5): Adjust head comment.
(Str_Concat_Bounds_5): Delete.
* libgnat/s-conca5.adb (Str_Concat_5): Use the length of the last
input to size the last assignment.
(Str_Concat_Bounds_5): Delete.
* libgnat/s-conca6.ads (Str_Concat_6): Adjust head comment.
(Str_Concat_Bounds_6): Delete.
* libgnat/s-conca6.adb (Str_Concat_6): Use the length of the last
input to size the last assignment.
(Str_Concat_Bounds_6): Delete.
* libgnat/s-conca7.ads (Str_Concat_7): Adjust head comment.
(Str_Concat_Bounds_7): Delete.
* libgnat/s-conca7.adb (Str_Concat_7): Use the length of the last
input to size the last assignment.
(Str_Concat_Bounds_7): Delete.
* libgnat/s-conca8.ads (Str_Concat_8): Adjust head comment.
(Str_Concat_Bounds_8): Delete.
* libgnat/s-conca8.adb (Str_Concat_8): Use the length of the last
input to size the last assignment.
(Str_Concat_Bounds_8): Delete.
* libgnat/s-conca9.ads (Str_Concat_9): Adjust head comment.
(Str_Concat_Bounds_9): Delete.
* libgnat/s-conca9.adb (Str_Concat_9): Use the length of the last
input to size the last assignment.
(Str_Concat_Bounds_9): Delete.diff --git a/gcc/ada/libgnat/s-conca2.adb b/gcc/ada/libgnat/s-conca2.adb
--- a/gcc/ada/libgnat/s-conca2.adb
+++ b/gcc/ada/libgnat/s-conca2.adb
@@ -46,26 +46,8 @@ package body System.Concat_2 is
   R (F .. L) := S1;
 
   F := L + 1;
-  L := R'Last;
+  L := F + S2'Length - 1;
   R (F .. L) := S2;
end Str_Concat_2;
 
-   -
-   -- Str_Concat_Bounds_2 --
-   -
-
-   procedure Str_Concat_Bounds_2
- (Lo, Hi : out Natural;
-  S1, S2 : String)
-   is
-   begin
-  if S1 = "" then
- Lo := S2'First;
- Hi := S2'Last;
-  else
- Lo := S1'First;
- Hi := S1'Last + S2'Length;
-  end if;
-   end Str_Concat_Bounds_2;
-
 end System.Concat_2;


diff --git a/gcc/ada/libgnat/s-conca2.ads b/gcc/ada/libgnat/s-conca2.ads
--- a/gcc/ada/libgnat/s-conca2.ads
+++ b/gcc/ada/libgnat/s-conca2.ads
@@ -36,15 +36,8 @@ package System.Concat_2 is
 
procedure Str_Concat_2 (R : out String; S1, S2 : String);
--  Performs the operation R := S1 & S2. The bounds of R are known to be
-   --  correct (usually set by a call to the Str_Concat_Bounds_2 procedure
-   --  below), so no bounds checks are required, and it is known that none of
+   --  sufficient so no bound checks are required, and it is known that none of
--  the input operands overlaps R. No assumptions can be made about the
--  lower bounds of any of the operands.
 
-   procedure Str_Concat_Bounds_2
- (Lo, Hi : out Natural;
-  S1, S2 : String);
-   --  Assigns to Lo..Hi the bounds of the result of concatenating the two
-   --  given strings, following the rules in the RM regarding null operands.
-
 end System.Concat_2;


diff --git a/gcc/ada/libgnat/s-conca3.adb b/gcc/ada/libgnat/s-conca3.adb
--- a/gcc/ada/libgnat/s-conca3.adb
+++ b/gcc/ada/libgnat/s-conca3.adb
@@ -29,8 +29,6 @@
 --  --
 --
 
-with System.Concat_2;
-
 package body System.Concat_3 is
 
pragma Suppress (All_Checks);
@@ -52,25 +50,8 @@ package body System.Concat_3 is
   R (F .. L) := S2;
 
   F := L + 1;
-  L := R'Last;
+  L := F + S3'Length - 1;
   R (F .. L) := S3;
end Str_Concat_3;
 
-   -
-   -- Str_Concat_Bounds_3 --
-   -
-
-   procedure Str_Concat_Bounds_3
- (Lo, Hi : out Nat

[Ada] Ignore switches for controlling frontend warnings in GNATprove mode

[Pierre-Marie de Rodat via Gcc-patches]

In the special mode for GNATprove, ignore switches controlling frontend
warnings, like already done for the control of style checks warnings.
Also remove special handling of warning mode in Errout to make up for
the previous division of control between -gnatw (GNAT) and --warnings
(GNATprove).

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

gcc/ada/

* errout.adb (Record_Compilation_Errors): Remove global
variable.
(Compilation_Errors): Simplify.
(Initialize): Inline Reset_Warnings.
(Reset_Warnings): Remove.
* errout.ads (Reset_Warnings): Remove.
(Compilation_Errors): Update comment.
* gnat1drv.adb (Adjust_Global_Switches): Ignore all frontend
warnings in GNATprove mode, except regarding elaboration and
suspicious contracts.diff --git a/gcc/ada/errout.adb b/gcc/ada/errout.adb
--- a/gcc/ada/errout.adb
+++ b/gcc/ada/errout.adb
@@ -64,13 +64,6 @@ package body Errout is
Finalize_Called : Boolean := False;
--  Set True if the Finalize routine has been called
 
-   Record_Compilation_Errors : Boolean := False;
-   --  Record that a compilation error was witnessed during a given phase of
-   --  analysis for gnat2why. This is needed as Warning_Mode is modified twice
-   --  in gnat2why, hence Erroutc.Compilation_Errors can only return a suitable
-   --  value for each phase of analysis separately. This is updated at each
-   --  call to Compilation_Errors.
-
Warn_On_Instance : Boolean;
--  Flag set true for warning message to be posted on instance
 
@@ -252,17 +245,8 @@ package body Errout is
begin
   if not Finalize_Called then
  raise Program_Error;
-
-  --  Record that a compilation error was witnessed during a given phase of
-  --  analysis for gnat2why. This is needed as Warning_Mode is modified
-  --  twice in gnat2why, hence Erroutc.Compilation_Errors can only return a
-  --  suitable value for each phase of analysis separately.
-
   else
- Record_Compilation_Errors :=
-   Record_Compilation_Errors or else Erroutc.Compilation_Errors;
-
- return Record_Compilation_Errors;
+ return Erroutc.Compilation_Errors;
   end if;
end Compilation_Errors;
 
@@ -1914,7 +1898,10 @@ package body Errout is
 
   --  Reset counts for warnings
 
-  Reset_Warnings;
+  Warnings_Treated_As_Errors := 0;
+  Warnings_Detected := 0;
+  Warning_Info_Messages := 0;
+  Warnings_As_Errors_Count := 0;
 
   --  Initialize warnings tables
 
@@ -3414,18 +3401,6 @@ package body Errout is
   end loop;
end Remove_Warning_Messages;
 
-   
-   -- Reset_Warnings --
-   
-
-   procedure Reset_Warnings is
-   begin
-  Warnings_Treated_As_Errors := 0;
-  Warnings_Detected := 0;
-  Warning_Info_Messages := 0;
-  Warnings_As_Errors_Count := 0;
-   end Reset_Warnings;
-
--
-- Adjust_Name_Case --
--


diff --git a/gcc/ada/errout.ads b/gcc/ada/errout.ads
--- a/gcc/ada/errout.ads
+++ b/gcc/ada/errout.ads
@@ -858,11 +858,6 @@ package Errout is
--  Remove warnings on all elements of a list (Calls Remove_Warning_Messages
--  on each element of the list, see above).
 
-   procedure Reset_Warnings;
-   --  Reset the counts related to warnings. This is used both to initialize
-   --  these counts and to reset them after each phase of analysis for a given
-   --  value of Opt.Warning_Mode in gnat2why.
-
procedure Set_Ignore_Errors (To : Boolean);
--  Following a call to this procedure with To=True, all error calls are
--  ignored. A call with To=False restores the default treatment in which
@@ -910,11 +905,10 @@ package Errout is
--  matching Warnings Off pragma preceding this one.
 
function Compilation_Errors return Boolean;
-   --  Returns True if errors have been detected, or warnings in -gnatwe (treat
-   --  warnings as errors) mode. Note that it is mandatory to call Finalize
-   --  before calling this routine. To account for changes to Warning_Mode in
-   --  gnat2why between phases, the past or current presence of an error is
-   --  recorded in a global variable at each call.
+   --  Returns True if errors have been detected, or warnings when they are
+   --  treated as errors, which corresponds to switch -gnatwe in the compiler,
+   --  and other switches in other tools. Note that it is mandatory to call
+   --  Finalize before calling this routine.
 
procedure Error_Msg_CRT (Feature : String; N : Node_Id);
--  Posts a non-fatal message on node N saying that the feature identified


diff --git a/gcc/ada/gnat1drv.adb b/gcc/ada/gnat1drv.adb
--- a/gcc/ada/gnat1drv.adb
+++ b/gcc/ada/gnat1drv.adb
@@ -557,10 +557,14 @@ procedure Gnat1drv is
  Validity_Checks_On := False;
  Check_Validity_Of_Parameters := False;
 
- --  Turn off style check options since we are not interested in any
-  

[Ada] Refine heuristics for unreachable-code warnings

[Pierre-Marie de Rodat via Gcc-patches]

This patch refines the heuristics for when we warn about unreachable
code, to avoid common false alarms.

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

gcc/ada/

* sem_ch5.adb (Check_Unreachable_Code): Refine heuristics.
* sem_util.ads, sem_util.adb (Is_Static_Constant_Name): Remove
this; instead we have a new function Is_Simple_Case in
Sem_Ch5.Check_Unreachable_Code.diff --git a/gcc/ada/sem_ch5.adb b/gcc/ada/sem_ch5.adb
--- a/gcc/ada/sem_ch5.adb
+++ b/gcc/ada/sem_ch5.adb
@@ -4393,6 +4393,31 @@ package body Sem_Ch5 is

 
procedure Check_Unreachable_Code (N : Node_Id) is
+
+  function Is_Simple_Case (N : Node_Id) return Boolean;
+  --  N is the condition of an if statement. True if N is simple enough
+  --  that we should not set Unblocked_Exit_Count in the special case
+  --  below.
+
+  
+  -- Is_Simple_Case --
+  
+
+  function Is_Simple_Case (N : Node_Id) return Boolean is
+  begin
+ return
+Is_Trivial_Boolean (N)
+   or else
+(Comes_From_Source (N)
+   and then Is_Static_Expression (N)
+   and then Nkind (N) in N_Identifier | N_Expanded_Name
+   and then Ekind (Entity (N)) = E_Constant)
+   or else
+(not In_Instance
+   and then Nkind (Original_Node (N)) = N_Op_Not
+   and then Is_Simple_Case (Right_Opnd (Original_Node (N;
+  end Is_Simple_Case;
+
   Error_Node : Node_Id;
   Nxt: Node_Id;
   P  : Node_Id;
@@ -4574,8 +4599,7 @@ package body Sem_Ch5 is
   and then No (Else_Statements (P))
   and then Is_OK_Static_Expression (Condition (P))
   and then Is_True (Expr_Value (Condition (P)))
-  and then not Is_Trivial_Boolean (Condition (P))
-  and then not Is_Static_Constant_Name (Condition (P))
+  and then not Is_Simple_Case (Condition (P))
 then
pragma Assert (Unblocked_Exit_Count = 2);
Unblocked_Exit_Count := 0;


diff --git a/gcc/ada/sem_util.adb b/gcc/ada/sem_util.adb
--- a/gcc/ada/sem_util.adb
+++ b/gcc/ada/sem_util.adb
@@ -21532,18 +21532,6 @@ package body Sem_Util is
 and then Entity (N) in Standard_True | Standard_False;
end Is_Trivial_Boolean;
 
-   -
-   -- Is_Static_Constant_Name --
-   -
-
-   function Is_Static_Constant_Name (N : Node_Id) return Boolean is
-   begin
-  return Comes_From_Source (N)
-and then Is_Static_Expression (N)
-and then Nkind (N) in N_Identifier | N_Expanded_Name
-and then Ekind (Entity (N)) = E_Constant;
-   end Is_Static_Constant_Name;
-
--
-- Is_Unchecked_Conversion_Instance --
--


diff --git a/gcc/ada/sem_util.ads b/gcc/ada/sem_util.ads
--- a/gcc/ada/sem_util.ads
+++ b/gcc/ada/sem_util.ads
@@ -2485,9 +2485,6 @@ package Sem_Util is
--  Determine whether source node N denotes "True" or "False". Note that
--  this is not true for expressions that got folded to True or False.
 
-   function Is_Static_Constant_Name (N : Node_Id) return Boolean;
-   --  True if N is a name that statically denotes a static constant.
-
function Is_Unchecked_Conversion_Instance (Id : Entity_Id) return Boolean;
--  Determine whether an arbitrary entity denotes an instance of function
--  Ada.Unchecked_Conversion.

[Ada] Vxworks7* - Makefile.rtl rtp vs rtp-smp cleanup - remove unused files

[Pierre-Marie de Rodat via Gcc-patches]

Only smp runtimes are built for vxworks7*, even though the -smp suffix
is removed during install. This change removes unused system packages
for rtp runtimes.

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

gcc/ada/

* libgnat/system-vxworks7-ppc-rtp.ads: Remove
* libgnat/system-vxworks7-x86-rtp.ads: Likewise.diff --git a/gcc/ada/libgnat/system-vxworks7-ppc-rtp.ads /dev/null
deleted file mode 100644
--- a/gcc/ada/libgnat/system-vxworks7-ppc-rtp.ads
+++ /dev/null
@@ -1,164 +0,0 @@
---
---  --
---GNAT RUN-TIME COMPONENTS  --
---  --
---   S Y S T E M--
---  --
--- S p e c  --
---  (VxWorks 7.x PPC RTP)   --
---  --
---  Copyright (C) 1992-2022, Free Software Foundation, Inc. --
---  --
--- This specification is derived from the Ada Reference Manual for use with --
--- GNAT. The copyright notice above, and the license provisions that follow --
--- apply solely to the  contents of the part following the private keyword. --
---  --
--- GNAT is free software;  you can  redistribute it  and/or modify it under --
--- terms of the  GNU General Public License as published  by the Free Soft- --
--- ware  Foundation;  either version 3,  or (at your option) any later ver- --
--- sion.  GNAT is distributed in the hope that it will be useful, but WITH- --
--- OUT ANY WARRANTY;  without even the  implied warranty of MERCHANTABILITY --
--- or FITNESS FOR A PARTICULAR PURPOSE. --
---  --
--- As a special exception under Section 7 of GPL version 3, you are granted --
--- additional permissions described in the GCC Runtime Library Exception,   --
--- version 3.1, as published by the Free Software Foundation.   --
---  --
--- You should have received a copy of the GNU General Public License and--
--- a copy of the GCC Runtime Library Exception along with this program; --
--- see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see--
--- .  --
---  --
--- GNAT was originally developed  by the GNAT team at  New York University. --
--- Extensive contributions were provided by Ada Core Technologies Inc.  --
---  --
---
-
---  This is the VxWorks version of this package for RTPs
-
-package System is
-   pragma Pure;
-   --  Note that we take advantage of the implementation permission to make
-   --  this unit Pure instead of Preelaborable; see RM 13.7.1(15). In Ada
-   --  2005, this is Pure in any case (AI-362).
-
-   pragma No_Elaboration_Code_All;
-   --  Allow the use of that restriction in units that WITH this unit
-
-   type Name is (SYSTEM_NAME_GNAT);
-   System_Name : constant Name := SYSTEM_NAME_GNAT;
-
-   --  System-Dependent Named Numbers
-
-   Min_Int : constant := -2 ** (Standard'Max_Integer_Size - 1);
-   Max_Int : constant :=  2 ** (Standard'Max_Integer_Size - 1) - 1;
-
-   Max_Binary_Modulus: constant := 2 ** Standard'Max_Integer_Size;
-   Max_Nonbinary_Modulus : constant := 2 ** Integer'Size - 1;
-
-   Max_Base_Digits   : constant := Long_Long_Float'Digits;
-   Max_Digits: constant := Long_Long_Float'Digits;
-
-   Max_Mantissa  : constant := Standard'Max_Integer_Size - 1;
-   Fine_Delta: constant := 2.0 ** (-Max_Mantissa);
-
-   Tick  : constant := 1.0 / 60.0;
-
-   --  Storage-related Declarations
-
-   type Address is private;
-   pragma Preelaborable_Initialization (Address);
-   Null_Address : constant Address;
-
-   Storage_Unit : constant := 8;
-   Word_Size: constant := Standard'Word_Size;
-   Memory_Size  : constant := 2 ** Word_Size;
-
-   --  Address comparison
-
-   function "<"  (Left, Right : Address) return Boolean;
-   function "<=" (Left, Right : Address) return Boolean;
-   function ">"  (Left, Right : Address) return Boolean;
-   function ">=" (Left, Right : Addre

[Ada] Accept aspect Yield on subprogram bodies acting as specs

[Pierre-Marie de Rodat via Gcc-patches]

A small fix for the aspect Yield defined in AI12-0279 for Ada 2022, to
accept aspect given for a subprogram body which acts as its own spec.

For example:

   procedure Switch with Yield => True is
   begin
  ...
   end Switch;

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

gcc/ada/

* sem_ch13.adb (Analyze_Aspect_Yield): Look at the entity kind,
not at the declaration kind.diff --git a/gcc/ada/sem_ch13.adb b/gcc/ada/sem_ch13.adb
--- a/gcc/ada/sem_ch13.adb
+++ b/gcc/ada/sem_ch13.adb
@@ -2724,13 +2724,11 @@ package body Sem_Ch13 is
Expr_Value : Boolean := False;
 
 begin
-   --  Check valid declarations for 'Yield
+   --  Check valid entity for 'Yield
 
-   if Nkind (N) in N_Abstract_Subprogram_Declaration
- | N_Entry_Declaration
- | N_Generic_Subprogram_Declaration
- | N_Subprogram_Declaration
- | N_Formal_Subprogram_Declaration
+   if (Is_Subprogram (E)
+ or else Is_Generic_Subprogram (E)
+ or else Is_Entry (E))
  and then not Within_Protected_Type (E)
then
   null;

[Ada] Make it clear that gnatmake passes the ball to gprbuild if -P is set

[Pierre-Marie de Rodat via Gcc-patches]

Also move -P switch description to the top of the switches list.

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

gcc/ada/

* makeusg.adb,
doc/gnat_ugn/building_executable_programs_with_gnat.rst: Move -P
to the top of switches list and make it clear that gnatmake
passes the ball to gprbuild if -P is set.
* gnat_ugn.texi: Regenerate.diff --git a/gcc/ada/doc/gnat_ugn/building_executable_programs_with_gnat.rst b/gcc/ada/doc/gnat_ugn/building_executable_programs_with_gnat.rst
--- a/gcc/ada/doc/gnat_ugn/building_executable_programs_with_gnat.rst
+++ b/gcc/ada/doc/gnat_ugn/building_executable_programs_with_gnat.rst
@@ -139,6 +139,17 @@ You may specify any of the following switches to ``gnatmake``:
   all other options.
 
 
+.. index:: -P  (gnatmake)
+
+:switch:`-P{project}`
+  Build GNAT project file ``project`` using GPRbuild. When this switch is
+  present, all other command-line switches are treated as GPRbuild switches
+  and not ``gnatmake`` switches.
+
+.. -- Comment:
+  :ref:`gnatmake_and_Project_Files`.
+
+
 .. index:: --GCC=compiler_name  (gnatmake)
 
 :switch:`--GCC={compiler_name}`
@@ -522,15 +533,6 @@ You may specify any of the following switches to ``gnatmake``:
 :switch:`-p`
   Same as :switch:`--create-missing-dirs`
 
-.. index:: -P  (gnatmake)
-
-:switch:`-P{project}`
-  Use project file ``project``. Only one such switch can be used.
-
-.. -- Comment:
-  :ref:`gnatmake_and_Project_Files`.
-
-
 .. index:: -q  (gnatmake)
 
 :switch:`-q`


diff --git a/gcc/ada/gnat_ugn.texi b/gcc/ada/gnat_ugn.texi
--- a/gcc/ada/gnat_ugn.texi
+++ b/gcc/ada/gnat_ugn.texi
@@ -21,7 +21,7 @@
 
 @copying
 @quotation
-GNAT User's Guide for Native Platforms , Jun 24, 2022
+GNAT User's Guide for Native Platforms , Jul 11, 2022
 
 AdaCore
 
@@ -7120,6 +7120,21 @@ If @code{--version} was not used, display usage, then exit disregarding
 all other options.
 @end table
 
+@geindex -P (gnatmake)
+
+
+@table @asis
+
+@item @code{-P@emph{project}}
+
+Build GNAT project file @code{project} using GPRbuild. When this switch is
+present, all other command-line switches are treated as GPRbuild switches
+and not @code{gnatmake} switches.
+@end table
+
+@c -- Comment:
+@c :ref:`gnatmake_and_Project_Files`.
+
 @geindex --GCC=compiler_name (gnatmake)
 
 
@@ -7620,19 +7635,6 @@ This switch cannot be used when invoking @code{gnatmake} with several
 Same as @code{--create-missing-dirs}
 @end table
 
-@geindex -P (gnatmake)
-
-
-@table @asis
-
-@item @code{-P@emph{project}}
-
-Use project file @code{project}. Only one such switch can be used.
-@end table
-
-@c -- Comment:
-@c :ref:`gnatmake_and_Project_Files`.
-
 @geindex -q (gnatmake)
 
 


diff --git a/gcc/ada/makeusg.adb b/gcc/ada/makeusg.adb
--- a/gcc/ada/makeusg.adb
+++ b/gcc/ada/makeusg.adb
@@ -54,6 +54,13 @@ begin
 
Display_Usage_Version_And_Help;
 
+   --  Line for -P
+
+   Write_Str ("  -Pproj   Build GNAT Project File proj using GPRbuild");
+   Write_Eol;
+   Write_Str ("   Treats all other switches as GPRbuild switches");
+   Write_Eol;
+
--  Line for -a
 
Write_Str ("  -a   Consider all files, even readonly ali files");
@@ -169,11 +176,6 @@ begin
Write_Str ("  -p   Create missing obj, lib and exec dirs");
Write_Eol;
 
-   --  Line for -P
-
-   Write_Str ("  -Pproj   Use GNAT Project File proj");
-   Write_Eol;
-
--  Line for -q
 
Write_Str ("  -q   Be quiet/terse");

[Ada] Warn on unset objects in packages with no bodies

[Pierre-Marie de Rodat via Gcc-patches]

Fix an inconsistency, where GNAT was warning about references to unset
objects inside generic packages with no bodies but not inside ordinary
packages with no bodies.

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

gcc/ada/

* sem_ch7.adb (Analyze_Package_Declaration): Check references to
unset objects.

gcc/testsuite/

* gnat.dg/specs/discr5.ads: Expect new warnings.
* gnat.dg/specs/empty_variants.ads: Likewise.
* gnat.dg/specs/pack13.ads: Likewise.diff --git a/gcc/ada/sem_ch7.adb b/gcc/ada/sem_ch7.adb
--- a/gcc/ada/sem_ch7.adb
+++ b/gcc/ada/sem_ch7.adb
@@ -1253,6 +1253,13 @@ package body Sem_Ch7 is
   (Context  => N,
Is_Main_Unit => Parent (N) = Cunit (Main_Unit));
  end if;
+
+ --  Warn about references to unset objects, which is straightforward
+ --  for packages with no bodies. For packages with bodies this is more
+ --  complicated, because some of the objects might be set between spec
+ --  and body elaboration, in nested or child packages, etc.
+
+ Check_References (Id);
   end if;
 
   --  Set Body_Required indication on the compilation unit node


diff --git a/gcc/testsuite/gnat.dg/specs/discr5.ads b/gcc/testsuite/gnat.dg/specs/discr5.ads
--- a/gcc/testsuite/gnat.dg/specs/discr5.ads
+++ b/gcc/testsuite/gnat.dg/specs/discr5.ads
@@ -22,7 +22,7 @@ package Discr5 is
subtype Rt is R(True);
subtype Rf is R(False);
 
-   type R1 (D1 : Boolean) is new R (X) with record
+   type R1 (D1 : Boolean) is new R (X) with record -- { dg-warning "\"X\" may be referenced before it has a value" }
   FF : Float;
   case D1 is
  when True =>
@@ -38,7 +38,7 @@ package Discr5 is
subtype R1t is R1 (True);
subtype R1f is R1 (False);
 
-   type R2 (D2 : Boolean) is new R1 (Y) with record
+   type R2 (D2 : Boolean) is new R1 (Y) with record -- { dg-warning "\"Y\" may be referenced before it has a value" }
   FFF: System.Address;
   case D2 is
  when True =>
@@ -55,3 +55,4 @@ package Discr5 is
subtype R2f is R2 (False);
 
 end Discr5;
+


diff --git a/gcc/testsuite/gnat.dg/specs/empty_variants.ads b/gcc/testsuite/gnat.dg/specs/empty_variants.ads
--- a/gcc/testsuite/gnat.dg/specs/empty_variants.ads
+++ b/gcc/testsuite/gnat.dg/specs/empty_variants.ads
@@ -1,5 +1,4 @@
 --  { dg-do compile }
---  { dg-options "-gnatdF" }
 
 package Empty_Variants is

@@ -23,10 +22,11 @@ package Empty_Variants is

R : Rec;

-   I : Integer := R.I;
+   I : Integer := R.I; -- { dg-warning "\"R\.I\" may be referenced before it has a value" }
J : Integer := R.J;
K : Integer := R.K;
L : Integer := R.L;
M : Integer := R.L;
 
 end Empty_Variants;
+


diff --git a/gcc/testsuite/gnat.dg/specs/pack13.ads b/gcc/testsuite/gnat.dg/specs/pack13.ads
--- a/gcc/testsuite/gnat.dg/specs/pack13.ads
+++ b/gcc/testsuite/gnat.dg/specs/pack13.ads
@@ -20,6 +20,6 @@ package Pack13 is
 
   A : Arr;
 
-  package My_G is new G (Boolean, A(True).B);
+  package My_G is new G (Boolean, A(True).B); -- { dg-warning "\"A\" may be referenced before it has a value" }
 
 end Pack13;

[Ada] Suppress warning in g-socthi__vxworks.adb

[Pierre-Marie de Rodat via Gcc-patches]

Follow-on to previous change, which missed the vxworks version of this
package.

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

gcc/ada/

* libgnat/g-socthi__vxworks.adb (C_Connect): Suppress new warning.diff --git a/gcc/ada/libgnat/g-socthi__vxworks.adb b/gcc/ada/libgnat/g-socthi__vxworks.adb
--- a/gcc/ada/libgnat/g-socthi__vxworks.adb
+++ b/gcc/ada/libgnat/g-socthi__vxworks.adb
@@ -190,7 +190,9 @@ package body GNAT.Sockets.Thin is
  return Res;
   end if;
 
-  declare
+  pragma Warnings (Off, "unreachable code");
+  declare -- unreachable if Thread_Blocking_IO is statically True
+ pragma Warnings (On, "unreachable code");
  WSet : aliased Fd_Set;
  Now  : aliased Timeval;
   begin

[Ada] Simplify rewriting of attributes into Boolean literals

[Pierre-Marie de Rodat via Gcc-patches]

Code cleanup; semantics is unaffected.

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

gcc/ada/

* sem_attr.adb (Set_Boolean_Result): Simplify using
Boolean_Literals.diff --git a/gcc/ada/sem_attr.adb b/gcc/ada/sem_attr.adb
--- a/gcc/ada/sem_attr.adb
+++ b/gcc/ada/sem_attr.adb
@@ -12778,13 +12778,8 @@ package body Sem_Attr is

 
procedure Set_Boolean_Result (N : Node_Id; B : Boolean) is
-  Loc : constant Source_Ptr := Sloc (N);
begin
-  if B then
- Rewrite (N, New_Occurrence_Of (Standard_True, Loc));
-  else
- Rewrite (N, New_Occurrence_Of (Standard_False, Loc));
-  end if;
+  Rewrite (N, New_Occurrence_Of (Boolean_Literals (B), Sloc (N)));
end Set_Boolean_Result;
 

[Ada] Fix confusing error expression on an unknown restriction

[Pierre-Marie de Rodat via Gcc-patches]

When pragma Restriction is used with an unknown restriction identifier,
it is better to not process the restriction expression, as it will
likely produce confusing error message.

In particular, an odd message appeared when there was a typo in the
restriction identifier whose expression requires special processing
(e.g.  No_Dependence_On instead of No_Dependence).

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

gcc/ada/

* sem_prag.adb (Process_Restrictions_Or_Restriction_Warnings):
Do not process expression of unknown restrictions.diff --git a/gcc/ada/sem_prag.adb b/gcc/ada/sem_prag.adb
--- a/gcc/ada/sem_prag.adb
+++ b/gcc/ada/sem_prag.adb
@@ -10792,13 +10792,15 @@ package body Sem_Prag is
 
 else
R_Id := Get_Restriction_Id (Process_Restriction_Synonyms (Arg));
-   Analyze_And_Resolve (Expr, Any_Integer);
 
if R_Id not in All_Parameter_Restrictions then
   Error_Pragma_Arg
 ("invalid restriction parameter identifier", Arg);
+   end if;
+
+   Analyze_And_Resolve (Expr, Any_Integer);
 
-   elsif not Is_OK_Static_Expression (Expr) then
+   if not Is_OK_Static_Expression (Expr) then
   Flag_Non_Static_Expr
 ("value must be static expression!", Expr);
   raise Pragma_Exit;

[Ada] Annotate libraries with returning annotation

[Pierre-Marie de Rodat via Gcc-patches]

This patch annotates SPARK-annotated libraries with returning
annotations (Always_Return, Might_Not_Return) to remove the warnings
raised by GNATprove about missing annotations.

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

gcc/ada/

* libgnarl/a-reatim.ads, libgnat/a-cfdlli.ads,
libgnat/a-cfhama.ads, libgnat/a-cfhase.ads,
libgnat/a-cfinse.ads, libgnat/a-cfinve.ads,
libgnat/a-cforma.ads, libgnat/a-cforse.ads,
libgnat/a-chahan.ads, libgnat/a-cofove.ads,
libgnat/a-cofuma.ads, libgnat/a-cofuse.ads,
libgnat/a-cofuve.ads, libgnat/a-nbnbin.ads,
libgnat/a-nbnbre.ads, libgnat/a-ngelfu.ads,
libgnat/a-nlelfu.ads, libgnat/a-nllefu.ads,
libgnat/a-nselfu.ads, libgnat/a-nuelfu.ads,
libgnat/a-strbou.ads, libgnat/a-strfix.ads,
libgnat/a-strmap.ads, libgnat/a-strunb.ads,
libgnat/a-strunb__shared.ads,  libgnat/a-strsea.ads,
libgnat/a-textio.ads, libgnat/a-tideio.ads,
libgnat/a-tienio.ads, libgnat/a-tifiio.ads,
libgnat/a-tiflio.ads, libgnat/a-tiinio.ads,
libgnat/a-timoio.ads, libgnat/i-c.ads, libgnat/interfac.ads,
libgnat/interfac__2020.ads, libgnat/s-atacco.ads,
libgnat/s-stoele.ads: Annotate packages and subprograms with
returning annotations.

patch.diff.gz
Description: application/gzip

[Ada] Ada 2020: Allow declarative items mixed with statements

[Pierre-Marie de Rodat via Gcc-patches]

This patch implements a syntactic language extension that allows
declarative items to appear in a sequence of statements.  For example:

for X in S'Range loop
Item : Character renames S (X);
Item := Transform (Item);
end loop;

Previously, declare/begin/end was required, which is just noise.

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

gcc/ada/

* par.adb (P_Declarative_Items): New function to parse a
sequence of declarative items.
(P_Sequence_Of_Statements): Add Handled flag, to indicate
whether to wrap the result in a block statement.
* par-ch3.adb (P_Declarative_Item): Rename P_Declarative_Items
to be P_Declarative_Item, because it really only parses a single
declarative item, and to avoid conflict with the new
P_Declarative_Items. Add In_Statements.  We keep the old
error-recovery mechanisms in place when In_Statements is False.
When True, we don't want to complain about statements, because
we are parsing a sequence of statements.
(P_Identifier_Declarations): If In_Statements, and we see what
looks like a statement, we no longer give an error. We return to
P_Sequence_Of_Statements with Done = True, so it can parse the
statement.
* par-ch5.adb (P_Sequence_Of_Statements): Call
P_Declarative_Items to parse declarative items that appear in
the statement list.  Remove error handling code that complained
about such items.  Check some errors conservatively.  Wrap the
result in a block statement when necessary.
* par-ch11.adb (P_Handled_Sequence_Of_Statements): Pass
Handled => True to P_Sequence_Of_Statements.
* types.ads (No, Present): New functions for querying
Source_Ptrs (equal, not equal No_Location).

patch.diff.gz
Description: application/gzip

[Ada] Don't check for misspelling of Not_A_Restriction_Id

[Pierre-Marie de Rodat via Gcc-patches]

When looking for a misspelling of a restriction identifier we should
ignore the Not_A_Restriction_Id literal, because it doesn't represent
any restriction.

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

gcc/ada/

* sem_prag.adb (Process_Restrictions_Or_Restriction_Warnings):
Fix range of iteration.diff --git a/gcc/ada/sem_prag.adb b/gcc/ada/sem_prag.adb
--- a/gcc/ada/sem_prag.adb
+++ b/gcc/ada/sem_prag.adb
@@ -10561,7 +10561,7 @@ package body Sem_Prag is
 
   --  Check for possible misspelling
 
-  for J in Restriction_Id loop
+  for J in All_Restrictions loop
  declare
 Rnm : constant String := Restriction_Id'Image (J);
 

[Ada] Fix inconsistent comment about expansion of exception declarations

[Pierre-Marie de Rodat via Gcc-patches]

Code cleanup.

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

gcc/ada/

* exp_ch11.adb (Expand_N_Exception_Declaration): Sync comment
with declaration in System.Standard_Library.diff --git a/gcc/ada/exp_ch11.adb b/gcc/ada/exp_ch11.adb
--- a/gcc/ada/exp_ch11.adb
+++ b/gcc/ada/exp_ch11.adb
@@ -1136,7 +1136,7 @@ package body Exp_Ch11 is
   Set_Is_Statically_Allocated (Ex_Id);
 
   --  Create the aggregate list for type Standard.Exception_Type:
-  --  Handled_By_Other component: False
+  --  Not_Handled_By_Others component: False
 
   L := Empty_List;
   Append_To (L, New_Occurrence_Of (Standard_False, Loc));

[Ada] Fix 0-sized secondary stack allocations

[Pierre-Marie de Rodat via Gcc-patches]

The Has_Enough_Free_Memory was not correctly reporting a completely full
chunk in the case of a 0-sized allocation.

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

gcc/ada/

* libgnat/s-secsta.adb (Has_Enough_Free_Memory): Check for full
chunk before computing the available size.diff --git a/gcc/ada/libgnat/s-secsta.adb b/gcc/ada/libgnat/s-secsta.adb
--- a/gcc/ada/libgnat/s-secsta.adb
+++ b/gcc/ada/libgnat/s-secsta.adb
@@ -506,12 +506,17 @@ package body System.Secondary_Stack is
   Mem_Size : Memory_Size) return Boolean
is
begin
+  --  First check if the chunk is full (Byte is > Memory'Last in that
+  --  case), then check there is enough free memory.
+
   --  Byte - 1 denotes the last occupied byte. Subtracting that byte from
   --  the memory capacity of the chunk yields the size of the free memory
   --  within the chunk. The chunk can fit the request as long as the free
   --  memory is as big as the request.
 
-  return Chunk.Size - (Byte - 1) >= Mem_Size;
+  return Chunk.Memory'Last >= Byte
+and then Chunk.Size - (Byte - 1) >= Mem_Size;
+
end Has_Enough_Free_Memory;
 
--

[Ada] Do not create large objects for indefinite protected types

[Pierre-Marie de Rodat via Gcc-patches]

This plugs a small loophole in the Needs_Secondary_Stack predicate for
some protected types and record types containing protected components.

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

gcc/ada/

* sem_util.adb (Caller_Known_Size_Record): Make entry assertion
more robust and add guard for null argument.  For protected
types, invoke Caller_Known_Size_Record on
Corresponding_Record_Type.
(Needs_Secondary_Stack): Likewise.diff --git a/gcc/ada/sem_util.adb b/gcc/ada/sem_util.adb
--- a/gcc/ada/sem_util.adb
+++ b/gcc/ada/sem_util.adb
@@ -23305,7 +23305,7 @@ package body Sem_Util is
   --
 
   function Caller_Known_Size_Record (Typ : Entity_Id) return Boolean is
- pragma Assert (Typ = Underlying_Type (Typ));
+ pragma Assert (if Present (Typ) then Typ = Underlying_Type (Typ));
 
  function Depends_On_Discriminant (Typ : Entity_Id) return Boolean;
  --  Called for untagged record and protected types. Return True if Typ
@@ -23342,6 +23342,14 @@ package body Sem_Util is
  end Depends_On_Discriminant;
 
   begin
+ --  This is a protected type without Corresponding_Record_Type set,
+ --  typically because expansion is disabled. The safe thing to do is
+ --  to return True, so Needs_Secondary_Stack returns False.
+
+ if No (Typ) then
+return True;
+ end if;
+
  --  First see if we have a variant part and return False if it depends
  --  on discriminants.
 
@@ -23367,14 +23375,18 @@ package body Sem_Util is
 Underlying_Type (Etype (Comp));
 
begin
-  if Is_Record_Type (Comp_Type)
-or else
- Is_Protected_Type (Comp_Type)
-  then
+  if Is_Record_Type (Comp_Type) then
  if not Caller_Known_Size_Record (Comp_Type) then
 return False;
  end if;
 
+  elsif Is_Protected_Type (Comp_Type) then
+ if not Caller_Known_Size_Record
+  (Corresponding_Record_Type (Comp_Type))
+ then
+return False;
+ end if;
+
   elsif Is_Array_Type (Comp_Type) then
  if Size_Depends_On_Discriminant (Comp_Type) then
 return False;
@@ -23478,7 +23490,7 @@ package body Sem_Util is
begin
   --  This is a private type which is not completed yet. This can only
   --  happen in a default expression (of a formal parameter or of a
-  --  record component). Do not expand transient scope in this case.
+  --  record component). The safe thing to do is to return False.
 
   if No (Typ) then
  return False;
@@ -23533,12 +23545,17 @@ package body Sem_Util is
   elsif Is_Definite_Subtype (Typ) or else Is_Task_Type (Typ) then
  return Large_Max_Size_Mutable (Typ);
 
-  --  Indefinite (discriminated) record or protected type
+  --  Indefinite (discriminated) record type
 
-  elsif Is_Record_Type (Typ) or else Is_Protected_Type (Typ) then
+  elsif Is_Record_Type (Typ) then
  return not Caller_Known_Size_Record (Typ);
 
-  --  Unconstrained array
+  --  Indefinite (discriminated) protected type
+
+  elsif Is_Protected_Type (Typ) then
+ return not Caller_Known_Size_Record (Corresponding_Record_Type (Typ));
+
+  --  Unconstrained array type
 
   else
  pragma Assert (Is_Array_Type (Typ) and not Is_Definite_Subtype (Typ));

[Ada] Extend No_Dependence restriction to code generation

[Pierre-Marie de Rodat via Gcc-patches]

This makes it possible to report violations of the No_Dependence restriction
during code generation, in other words outside of the Ada front-end proper.
These violations are supposed to be only for child units of System, so the
implementation is restricted to these cases.

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

gcc/ada/

* restrict.ads (type ND_Entry): Add System_Child component.
(Check_Restriction_No_Dependence_On_System): Declare.
* restrict.adb (Global_Restriction_No_Tasking): Move around.
(Violation_Of_No_Dependence): New procedure.
(Check_Restriction_No_Dependence): Call Violation_Of_No_Dependence
to report a violation.
(Check_Restriction_No_Dependence_On_System): New procedure.
(Set_Restriction_No_Dependenc): Set System_Child component if the
unit is a child of System.
* snames.ads-tmpl (Name_Arith_64): New package name.
(Name_Arith_128): Likewise.
(Name_Memory): Likewise.
(Name_Stack_Checking): Likewise.
* fe.h (Check_Restriction_No_Dependence_On_System): Declare.diff --git a/gcc/ada/fe.h b/gcc/ada/fe.h
--- a/gcc/ada/fe.h
+++ b/gcc/ada/fe.h
@@ -252,6 +252,8 @@ extern Boolean SJLJ_Exceptions		(void);
   restrict__check_no_implicit_protected_alloc
 #define Check_No_Implicit_Task_Alloc	\
   restrict__check_no_implicit_task_alloc
+#define Check_Restriction_No_Dependence_On_System \
+  restrict__check_restriction_no_dependence_on_system
 #define No_Exception_Handlers_Set	\
   restrict__no_exception_handlers_set
 #define No_Exception_Propagation_Active	\
@@ -262,6 +264,7 @@ extern void Check_Implicit_Dynamic_Code_Allowed	(Node_Id);
 extern void Check_No_Implicit_Heap_Alloc	(Node_Id);
 extern void Check_No_Implicit_Protected_Alloc	(Node_Id);
 extern void Check_No_Implicit_Task_Alloc	(Node_Id);
+extern void Check_Restriction_No_Dependence_On_System (Name_Id, Node_Id);
 extern Boolean No_Exception_Handlers_Set	(void);
 extern Boolean No_Exception_Propagation_Active	(void);
 


diff --git a/gcc/ada/restrict.adb b/gcc/ada/restrict.adb
--- a/gcc/ada/restrict.adb
+++ b/gcc/ada/restrict.adb
@@ -44,10 +44,6 @@ with Uname;  use Uname;
 
 package body Restrict is
 
-   Global_Restriction_No_Tasking : Boolean := False;
-   --  Set to True when No_Tasking is set in the run-time package System
-   --  or in a configuration pragmas file (for example, gnat.adc).
-

-- Package Local Declarations --

@@ -55,6 +51,10 @@ package body Restrict is
Config_Cunit_Boolean_Restrictions : Save_Cunit_Boolean_Restrictions;
--  Save compilation unit restrictions set by config pragma files
 
+   Global_Restriction_No_Tasking : Boolean := False;
+   --  Set to True when No_Tasking is set in the run-time package System
+   --  or in a configuration pragmas file (for example, gnat.adc).
+
Restricted_Profile_Result : Boolean := False;
--  This switch memoizes the result of Restricted_Profile function calls for
--  improved efficiency. Valid only if Restricted_Profile_Cached is True.
@@ -122,6 +122,11 @@ package body Restrict is
--  message is to be suppressed if this is an internal file and this file is
--  not the main unit. Returns True if message is to be suppressed.
 
+   procedure Violation_Of_No_Dependence (Unit : Int; N : Node_Id);
+   --  Called if a violation of restriction No_Dependence for Unit at node N
+   --  is found. This routine outputs the appropriate message, taking care of
+   --  warning vs real violation.
+
---
-- Abort_Allowed --
---
@@ -550,8 +555,6 @@ package body Restrict is
-
 
procedure Check_Restriction_No_Dependence (U : Node_Id; Err : Node_Id) is
-  DU : Node_Id;
-
begin
   --  Ignore call if node U is not in the main source unit. This avoids
   --  cascaded errors, e.g. when Ada.Containers units with other units.
@@ -567,26 +570,33 @@ package body Restrict is
   --  Loop through entries in No_Dependence table to check each one in turn
 
   for J in No_Dependences.First .. No_Dependences.Last loop
- DU := No_Dependences.Table (J).Unit;
+ if Same_Unit (No_Dependences.Table (J).Unit, U) then
+Violation_Of_No_Dependence (J, Err);
+return;
+ end if;
+  end loop;
+   end Check_Restriction_No_Dependence;
 
- if Same_Unit (U, DU) then
-Error_Msg_Sloc := Sloc (DU);
-Error_Msg_Node_1 := DU;
+   ---
+   -- Check_Restriction_No_Dependence_On_System --
+   ---
 
-if No_Dependences.Table (J).Warn then
-   Error_Msg
- ("?*?violation of restriction `No_Dependence '='> &`#",
-  Sloc (Err));
-else
-   Error_Msg
- ("|violat

Ping^2: [RFA configure parts] aarch64: Make cc1 &co handle --with options

[Richard Sandiford via Gcc-patches]

Ping^2 for the configure bits.

Richard Sandiford via Gcc-patches  writes:
> On aarch64, --with-arch, --with-cpu and --with-tune only have an
> effect on the driver, so “./xgcc -B./ -O3” can give significantly
> different results from “./cc1 -O3”.  --with-arch did have a limited
> effect on ./cc1 in previous releases, although it didn't work
> entirely correctly.
>
> Being of a lazy persuasion, I've got used to ./cc1 selecting SVE for
> --with-arch=armv8.2-a+sve without having to supply an explicit -march,
> so this patch makes ./cc1 emulate the relevant OPTION_DEFAULT_SPECS.
> It relies on Wilco's earlier clean-ups.
>
> The patch makes config.gcc define WITH_FOO_STRING macros for each
> supported --with-foo option.  This could be done only in aarch64-
> specific code, but I thought it could be useful on other targets
> too (and can be safely ignored otherwise).  There didn't seem to
> be any existing and potentially clashing uses of macros with this
> style of name.
>
> Tested on aarch64-linux-gnu & x86_64-linux-gnu.  OK for the configure
> bits?
>
> Richard
>
>
> gcc/
>   * config.gcc: Define WITH_FOO_STRING macros for each supported
>   --with-foo option.
>   * config/aarch64/aarch64.cc (aarch64_override_options): Emulate
>   OPTION_DEFAULT_SPECS.
>   * config/aarch64/aarch64.h (OPTION_DEFAULT_SPECS): Reference the above.
> ---
>  gcc/config.gcc| 14 ++
>  gcc/config/aarch64/aarch64.cc |  8 
>  gcc/config/aarch64/aarch64.h  |  5 -
>  3 files changed, 26 insertions(+), 1 deletion(-)
>
> diff --git a/gcc/config.gcc b/gcc/config.gcc
> index cdbefb5b4f5..e039230431c 100644
> --- a/gcc/config.gcc
> +++ b/gcc/config.gcc
> @@ -5865,6 +5865,20 @@ else
>   configure_default_options="{ ${t} }"
>  fi
>  
> +for option in $supported_defaults
> +do
> + lc_option=`echo $option | sed s/-/_/g`
> + uc_option=`echo $lc_option | tr a-z A-Z`
> + eval "val=\$with_$lc_option"
> + if test -n "$val"
> + then
> + val="\\\"$val\\\""
> + else
> + val=nullptr
> + fi
> + tm_defines="$tm_defines WITH_${uc_option}_STRING=$val"
> +done
> +
>  if test "$target_cpu_default2" != ""
>  then
>   if test "$target_cpu_default" != ""
> diff --git a/gcc/config/aarch64/aarch64.cc b/gcc/config/aarch64/aarch64.cc
> index d21e041eccb..0bc700b81ad 100644
> --- a/gcc/config/aarch64/aarch64.cc
> +++ b/gcc/config/aarch64/aarch64.cc
> @@ -18109,6 +18109,14 @@ aarch64_override_options (void)
>if (aarch64_branch_protection_string)
>  aarch64_validate_mbranch_protection (aarch64_branch_protection_string);
>  
> +  /* Emulate OPTION_DEFAULT_SPECS.  */
> +  if (!aarch64_arch_string && !aarch64_cpu_string)
> +aarch64_arch_string = WITH_ARCH_STRING;
> +  if (!aarch64_arch_string && !aarch64_cpu_string)
> +aarch64_cpu_string = WITH_CPU_STRING;
> +  if (!aarch64_cpu_string && !aarch64_tune_string)
> +aarch64_tune_string = WITH_TUNE_STRING;
> +
>/* -mcpu=CPU is shorthand for -march=ARCH_FOR_CPU, -mtune=CPU.
>   If either of -march or -mtune is given, they override their
>   respective component of -mcpu.  */
> diff --git a/gcc/config/aarch64/aarch64.h b/gcc/config/aarch64/aarch64.h
> index 80cfe4b7407..3122dbd7098 100644
> --- a/gcc/config/aarch64/aarch64.h
> +++ b/gcc/config/aarch64/aarch64.h
> @@ -1267,7 +1267,10 @@ extern enum aarch64_code_model aarch64_cmodel;
>  /* Support for configure-time --with-arch, --with-cpu and --with-tune.
> --with-arch and --with-cpu are ignored if either -mcpu or -march is used.
> --with-tune is ignored if either -mtune or -mcpu is used (but is not
> -   affected by -march).  */
> +   affected by -march).
> +
> +   There is corresponding code in aarch64_override_options that emulates
> +   this behavior when cc1 &co are invoked directly.  */
>  #define OPTION_DEFAULT_SPECS \
>{"arch", "%{!march=*:%{!mcpu=*:-march=%(VALUE)}}" },   \
>{"cpu",  "%{!march=*:%{!mcpu=*:-mcpu=%(VALUE)}}" },   \

[Ada] Spurious use_type clause warning

[Pierre-Marie de Rodat via Gcc-patches]

This patch corrects an error in the compiler whereby a spurious
redundant use_type_clause warning gets issued when the clause appears in
the context_clause of a package preceding a with_clause for a package
with an identical use_clause in its specification.

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

gcc/ada/

* einfo.ads: Modify documentation for In_Use flag to include
scope stack manipulation.
* sem_ch8.adb (Use_One_Type): Add condition to return when
attempting to detect redundant use_type_clauses in child units
in certain cases.diff --git a/gcc/ada/einfo.ads b/gcc/ada/einfo.ads
--- a/gcc/ada/einfo.ads
+++ b/gcc/ada/einfo.ads
@@ -2309,6 +2309,10 @@ package Einfo is
 --   the corresponding entity. Reset at end of corresponding declarative
 --   part. The flag on a type is also used to determine the visibility of
 --   the primitive operators of the type.
+--
+--   Note that manipulation of scopes on the scope stack will also cause
+--   the flag to be set/unset since the setting of scopes affects
+--   visibility.
 
 --Is_Abstract_Subprogram
 --   Defined in all subprograms and entries. Set for abstract subprograms.


diff --git a/gcc/ada/sem_ch8.adb b/gcc/ada/sem_ch8.adb
--- a/gcc/ada/sem_ch8.adb
+++ b/gcc/ada/sem_ch8.adb
@@ -10758,15 +10758,26 @@ package body Sem_Ch8 is
  return;
   end if;
 
-  --  There is a redundant use_type_clause in a child unit.
-  --  Determine which of the units is more deeply nested. If a
+  --  If there is a redundant use_type_clause in a child unit
+  --  determine which of the units is more deeply nested. If a
   --  unit is a package instance, retrieve the entity and its
   --  scope from the instance spec.
 
   Ent1 := Entity_Of_Unit (Unit1);
   Ent2 := Entity_Of_Unit (Unit2);
 
-  if Scope (Ent2) = Standard_Standard then
+  --  When the scope of both units' entities are
+  --  Standard_Standard then neither Unit1 or Unit2 are child
+  --  units - so return in that case.
+
+  if Scope (Ent1) = Standard_Standard
+and then Scope (Ent2) = Standard_Standard
+  then
+ return;
+
+  --  Otherwise, determine if one of the units is not a child
+
+  elsif Scope (Ent2) = Standard_Standard then
  Error_Msg_Sloc := Sloc (Clause2);
  Err_No := Clause1;
 

Re: Modula-2: merge followup (brief update on the progress of the new linking implementation)

[Gaius Mulley via Gcc-patches]

Rainer Orth  writes:

Hi Rainer,

many thanks for the patch and log of the failures.  I've committed the
patch and rebuilt all Makefile.in's which are affected by m2.

I think this just leaves:

> * While this lets the build finish on all of i386-pc-solaris2.11,
>   sparcv9-sun-solaris2.11, and x86_64-pc-linux-gnu, I get thousands of
>   testsuite failures, all of the same kind:
>
> Undefined   first referenced
>  symbol in file
> RTco_signal 
> /var/gcc/modula-2/11.4-gcc-modula-2/i386-pc-solaris2.11/./libgm2/libm2pim/.libs/libm2pim.so
> RTco_select 
> /var/gcc/modula-2/11.4-gcc-modula-2/i386-pc-solaris2.11/./libgm2/libm2pim/.libs/libm2pim.so
> RTco_initSemaphore  
> /var/gcc/modula-2/11.4-gcc-modula-2/i386-pc-solaris2.11/./libgm2/libm2pim/.libs/libm2pim.so
> RTco_wait   
> /var/gcc/modula-2/11.4-gcc-modula-2/i386-pc-solaris2.11/./libgm2/libm2pim/.libs/libm2pim.so
> ld: fatal: symbol referencing errors
> collect2: error: ld returned 1 exit status
> compiler exited with status 1
> FAIL: gm2/exceptions/run/pass/libexcept.mod compilation,  -g
>
>   I haven't yet tried to fix those.

which I'll try and reproduce,

regards,
Gaius

RE: [ping][vect-patterns] Refactor widen_plus/widen_minus as internal_fns

[Richard Biener via Gcc-patches]

On Thu, 30 Jun 2022, Joel Hutton wrote:

> > We can go with a private vect_gimple_build function until we sort out the 
> > API
> > issue to unblock Tamar (I'll reply to Richards reply with further thoughts 
> > on
> > this)
> > 
> 
> Done.
> 
> > > Similarly are you ok with the use of gimple_extract_op? I would lean
> > towards using it as it is cleaner, but I don't have strong feelings.
> > 
> > I don't like using gimple_extract_op here, I think I outlined a variant 
> > that is
> > even shorter.
> > 
> 
> Done.
> 
> Updated patches attached, bootstrapped and regression tested on aarch64.
> 
> Tomorrow is my last working day at Arm, so it will likely be Andre that 
> commits this/addresses any further comments.

First sorry for the (repeated) delays.

In the first patch I still see ECF_WIDEN, I don't like that, we
use things like associative_binary_fn_p so for widening internal
functions similar predicates should be used.

In the second patch you add vec_widen_{add,sub} optabs

+OPTAB_CD(vec_widen_add_optab, "add$a$b3")
+OPTAB_CD(vec_widen_sub_optab, "sub$a$b3")

but a) the names are that of regular adds which is at least confusing
(if not wrong), b) there's no documentation for them in md.texi which,
c) doesn't explain why they are necessary when we have 
vec_widen_[su]{add,sub}l_optab

+  internal_fn ifn = as_internal_fn (code.safe_as_fn_code ());

asks for safe_as_internal_fn () (just complete the API, also with
safe_as_builtin_fn)

+  internal_fn lo, hi;
+  lookup_multi_internal_fn (ifn, &lo, &hi);
+  *code1 = as_combined_fn (lo);
+  *code2 = as_combined_fn (hi);

in fact this probably shows that the guarding condition should
be if (code.is_internal_fn ()) instead of if (code.is_fn_code ()).

+  optab1 = lookup_multi_ifn_optab (lo, !TYPE_UNSIGNED (vectype));
+  optab2 = lookup_multi_ifn_optab (hi, !TYPE_UNSIGNED (vectype));

this shows the two lookup_ APIs are inconsistent in having two vs. one
output, please make them consistent.  I'd say give
lookup_multi_internal_fn a enum { LO, HI } argument, returning the
result.  Given VEC_WIDEN_MULT has HI, LO, EVEN and ODD variants
that sounds more future proof.

The internal_fn stuff could probably get a 2nd eye from Richard.

In the third patch I see unrelated and wrong changes like

  /* Check that the DR_INITs are compile-time constants.  */
- if (!tree_fits_shwi_p (DR_INIT (dra))
- || !tree_fits_shwi_p (DR_INIT (drb)))
+ if (TREE_CODE (DR_INIT (dra)) != INTEGER_CST
+ || TREE_CODE (DR_INIT (drb)) != INTEGER_CST)
break;

please strip the patch down to relevant changes.

-  tree op = gimple_op (assign, i + 1);
+  tree op;
+  if (is_gimple_assign (stmt))
+   op = gimple_op (stmt, i + 1);
+  else
+   op = gimple_call_arg (stmt, i);

somebody added gimple_arg which can be used here doing

   op = gimple_arg (stmt, i);

+  tree lhs = is_gimple_assign (stmt) ? gimple_assign_lhs (stmt):
+ gimple_call_lhs (stmt);

  tree lhs = gimple_get_lhs (stmt);

   /* Check for an integer operation with the right code.  */
-  gassign *assign = dyn_cast  (stmt_info->stmt);
-  if (!assign)
+  gimple* stmt = stmt_info->stmt;
+  if (!(is_gimple_assign (stmt) || is_gimple_call (stmt)))
 return 0;

-  tree_code rhs_code = gimple_assign_rhs_code (assign);
-  if (rhs_code != code && rhs_code != widened_code)
+  code_helper rhs_code;
+  if (is_gimple_assign (stmt))
+rhs_code = gimple_assign_rhs_code (stmt);
+  else
+rhs_code = gimple_call_combined_fn (stmt);
+
+  if (rhs_code.safe_as_tree_code () != code
+  && rhs_code.get_rep () != widened_code.get_rep ())
 return 0;

that's probably better refactored as

 if (is_gimple_assign (stmt))
   {
 if (code check)
   return 0;
   }
 else if (is_gimple_call (..))
  {
  ..
  }
 else
   return 0;

otherwise the last patch looks reasonable.

Richard.

[Ada] Use right implementation type for nonbinary-modulus ops

[Pierre-Marie de Rodat via Gcc-patches]

If the flag Opt.Expand_Nonbinary_Modular_Ops is set (which occurs if
-gnateg is specified) then we implement predefined operations for a
modular type whose modulus is not a power of two by converting the
operands to some other type (either a signed integer type or a modular
type with a power-of-two modulus), doing the operation in that
representation, and converting back.  If the bounds of the chosen type
are too narrow, then problems with intermediate overflow can result. But
there are performance advantages to choosing narrower bounds (and to
prefering an unsigned choice over a signed choice of the same size) when
multiple safe choices are available.

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

gcc/ada/

* exp_ch4.adb (Expand_Nonbinary_Modular_Op.Expand_Modular_Op):
Reimplement choice of which predefined type to use for the
implementation of a predefined operation of a modular type with
a non-power-of-two modulus.diff --git a/gcc/ada/exp_ch4.adb b/gcc/ada/exp_ch4.adb
--- a/gcc/ada/exp_ch4.adb
+++ b/gcc/ada/exp_ch4.adb
@@ -4177,43 +4177,82 @@ package body Exp_Ch4 is
   ---
 
   procedure Expand_Modular_Op is
+ --   We will convert to another type (not a nonbinary-modulus modular
+ --   type), evaluate the op in that representation, reduce the result,
+ --   and convert back to the original type. This means that the
+ --   backend does not have to deal with nonbinary-modulus ops.
+
  Op_Expr  : constant Node_Id := New_Op_Node (Nkind (N), Loc);
  Mod_Expr : constant Node_Id := New_Op_Node (N_Op_Mod, Loc);
 
- Target_Type   : Entity_Id;
-
+ Target_Type : Entity_Id;
   begin
- --  Convert nonbinary modular type operands into integer values. Thus
- --  we avoid never-ending loops expanding them, and we also ensure
- --  the back end never receives nonbinary modular type expressions.
-
- if Nkind (N) in N_Op_And | N_Op_Or | N_Op_Xor then
-Set_Left_Opnd (Op_Expr,
-  Unchecked_Convert_To (Standard_Unsigned,
-New_Copy_Tree (Left_Opnd (N;
-Set_Right_Opnd (Op_Expr,
-  Unchecked_Convert_To (Standard_Unsigned,
-New_Copy_Tree (Right_Opnd (N;
-Set_Left_Opnd (Mod_Expr,
-  Unchecked_Convert_To (Standard_Integer, Op_Expr));
-
- else
---  If the modulus of the type is larger than Integer'Last use a
---  larger type for the operands, to prevent spurious constraint
---  errors on large legal literals of the type.
+ --  Select a target type that is large enough to avoid spurious
+ --  intermediate overflow on pre-reduction computation (for
+ --  correctness) but is no larger than is needed (for performance).
 
-if Modulus (Etype (N)) > Int (Integer'Last) then
-   Target_Type := Standard_Long_Long_Integer;
+ declare
+Required_Size : Uint := RM_Size (Etype (N));
+Use_Unsigned  : Boolean := True;
+ begin
+case Nkind (N) is
+   when N_Op_Add =>
+  --  For example, if modulus is 255 then RM_Size will be 8
+  --  and the range of possible values (before reduction) will
+  --  be 0 .. 508; that range requires 9 bits.
+  Required_Size := Required_Size + 1;
+
+   when N_Op_Subtract =>
+  --  For example, if modulus is 255 then RM_Size will be 8
+  --  and the range of possible values (before reduction) will
+  --  be -254 .. 254; that range requires 9 bits, signed.
+  Use_Unsigned := False;
+  Required_Size := Required_Size + 1;
+
+   when N_Op_Multiply =>
+  --  For example, if modulus is 255 then RM_Size will be 8
+  --  and the range of possible values (before reduction) will
+  --  be 0 .. 64,516; that range requires 16 bits.
+  Required_Size := Required_Size * 2;
+
+   when others =>
+  null;
+end case;
+
+if Use_Unsigned then
+   if Required_Size <= Standard_Short_Short_Integer_Size then
+  Target_Type := Standard_Short_Short_Unsigned;
+   elsif Required_Size <= Standard_Short_Integer_Size then
+  Target_Type := Standard_Short_Unsigned;
+   elsif Required_Size <= Standard_Integer_Size then
+  Target_Type := Standard_Unsigned;
+   else
+  pragma Assert (Required_Size <= 64);
+  Target_Type := Standard_Unsigned_64;
+   end if;
+elsif Required_Size <= 8 then
+   Target_Type := Standard_Integer_8;
+elsif Required_Size <= 16 then
+   Target_Type

[PATCH] Remove create_lcssa_for_virtual_phi and uses

[Richard Biener via Gcc-patches]

The following expands the comment in vect_do_peeling as to why we
do not need create_lcssa_for_virtual_phi and removes that function.

That's the last bit I have queued for the vectorizer virtual LCSSA
cleanup.

Bootstrapped and tested on x86_64-unknown-linux-gnu and
aarch64-linux-gnu (sic), pushed.

* tree-vect-loop-manip.cc (create_lcssa_for_virtual_phi):
Remove.
(vect_do_peeling): Do not call it, adjust comment.
---
 gcc/tree-vect-loop-manip.cc | 95 +++--
 1 file changed, 7 insertions(+), 88 deletions(-)

diff --git a/gcc/tree-vect-loop-manip.cc b/gcc/tree-vect-loop-manip.cc
index 2c2b4f7bd53..86d2264054a 100644
--- a/gcc/tree-vect-loop-manip.cc
+++ b/gcc/tree-vect-loop-manip.cc
@@ -1332,56 +1332,6 @@ slpeel_can_duplicate_loop_p (const class loop *loop, 
const_edge e)
   return true;
 }
 
-/* If the loop has a virtual PHI, but exit bb doesn't, create a virtual PHI
-   in the exit bb and rename all the uses after the loop.  This simplifies
-   the *guard[12] routines, which assume loop closed SSA form for all PHIs
-   (but normally loop closed SSA form doesn't require virtual PHIs to be
-   in the same form).  Doing this early simplifies the checking what
-   uses should be renamed.
-
-   If we create a new phi after the loop, return the definition that
-   applies on entry to the loop, otherwise return null.  */
-
-static tree
-create_lcssa_for_virtual_phi (class loop *loop)
-{
-  gphi_iterator gsi;
-  edge exit_e = single_exit (loop);
-
-  for (gsi = gsi_start_phis (loop->header); !gsi_end_p (gsi); gsi_next (&gsi))
-if (virtual_operand_p (gimple_phi_result (gsi_stmt (gsi
-  {
-   gphi *phi = gsi.phi ();
-   for (gsi = gsi_start_phis (exit_e->dest);
-!gsi_end_p (gsi); gsi_next (&gsi))
- if (virtual_operand_p (gimple_phi_result (gsi_stmt (gsi
-   break;
-   if (gsi_end_p (gsi))
- {
-   tree new_vop = copy_ssa_name (PHI_RESULT (phi));
-   gphi *new_phi = create_phi_node (new_vop, exit_e->dest);
-   tree vop = PHI_ARG_DEF_FROM_EDGE (phi, EDGE_SUCC (loop->latch, 0));
-   imm_use_iterator imm_iter;
-   gimple *stmt;
-   use_operand_p use_p;
-
-   SSA_NAME_OCCURS_IN_ABNORMAL_PHI (new_vop)
- = SSA_NAME_OCCURS_IN_ABNORMAL_PHI (vop);
-   add_phi_arg (new_phi, vop, exit_e, UNKNOWN_LOCATION);
-   gimple_phi_set_result (new_phi, new_vop);
-   FOR_EACH_IMM_USE_STMT (stmt, imm_iter, vop)
- if (stmt != new_phi
- && !flow_bb_inside_loop_p (loop, gimple_bb (stmt)))
-   FOR_EACH_IMM_USE_ON_STMT (use_p, imm_iter)
- SET_USE (use_p, new_vop);
-
-   return PHI_ARG_DEF_FROM_EDGE (phi, loop_preheader_edge (loop));
- }
-   break;
-  }
-  return NULL_TREE;
-}
-
 /* Function vect_get_loop_location.
 
Extract the location of the loop in the source code.
@@ -2702,31 +2652,20 @@ vect_do_peeling (loop_vec_info loop_vinfo, tree niters, 
tree nitersm1,
  pending update needs.  */
   gcc_assert (!need_ssa_update_p (cfun));
 
-  create_lcssa_for_virtual_phi (loop);
-
-  /* If we're vectorizing an epilogue loop, the update_ssa above will
- have ensured that the virtual operand is in SSA form throughout the
- vectorized main loop.  Normally it is possible to trace the updated
+  /* If we're vectorizing an epilogue loop, we have ensured that the
+ virtual operand is in SSA form throughout the vectorized main loop.
+ Normally it is possible to trace the updated
  vector-stmt vdefs back to scalar-stmt vdefs and vector-stmt vuses
  back to scalar-stmt vuses, meaning that the effect of the SSA update
  remains local to the main loop.  However, there are rare cases in
- which the vectorized loop has vdefs even when the original scalar
+ which the vectorized loop should have vdefs even when the original scalar
  loop didn't.  For example, vectorizing a load with IFN_LOAD_LANES
  introduces clobbers of the temporary vector array, which in turn
  needs new vdefs.  If the scalar loop doesn't write to memory, these
  new vdefs will be the only ones in the vector loop.
-
- In that case, update_ssa will have added a new virtual phi to the
- main loop, which previously didn't need one.  Ensure that we (locally)
- maintain LCSSA form for the virtual operand, just as we would have
- done if the virtual phi had existed from the outset.  This makes it
- easier to duplicate the scalar epilogue loop below.  */
-  tree vop_to_rename = NULL_TREE;
-  if (loop_vec_info orig_loop_vinfo = LOOP_VINFO_ORIG_LOOP_INFO (loop_vinfo))
-{
-  class loop *orig_loop = LOOP_VINFO_LOOP (orig_loop_vinfo);
-  vop_to_rename = create_lcssa_for_virtual_phi (orig_loop);
-}
+ We are currently defering updating virtual SSA form and creating
+ of a virtual PHI for this case so we do not have to mak

Re: [PATCH 1/1 V4] RISC-V: Support Zmmul extension

[Kito Cheng via Gcc-patches]

> gcc\ChangeLog:

It's minor but that should be gcc/ChangeLog rather than gcc\ChangeLog:

>
> gcc\testsuite\ChangeLog:

Same here.

> --- a/gcc/config/riscv/riscv.cc
> +++ b/gcc/config/riscv/riscv.cc
> @@ -4999,10 +4999,14 @@ riscv_option_override (void)
>/* The presence of the M extension implies that division instructions
>   are present, so include them unless explicitly disabled.  */
>if (TARGET_MUL && (target_flags_explicit & MASK_DIV) == 0)
> -target_flags |= MASK_DIV;
> +if(!TARGET_ZMMUL)
> +  target_flags |= MASK_DIV;
>else if (!TARGET_MUL && TARGET_DIV)
>  error ("%<-mdiv%> requires %<-march%> to subsume the % extension");
> -
> +
> +  if(TARGET_ZMMUL && TARGET_MUL)

Should be +  if(TARGET_ZMMUL && !TARGET_MUL && TARGET_DIV)

Otherwise that treat rv32im_zmmul becomes an invalid arch string, but
actually that's a valid combination.

> +warning (0, "%<-mdiv%> cannot use when the % extension is 
> present");

Google suggest that : "%<-mdiv%> cannot be used when %
extension is present" :P


> +
>/* Likewise floating-point division and square root.  */
>if (TARGET_HARD_FLOAT && (target_flags_explicit & MASK_FDIV) == 0)
>  target_flags |= MASK_FDIV;
> diff --git a/gcc/config/riscv/riscv.md b/gcc/config/riscv/riscv.md
> index 308b64dd30d..d4e171464ea 100644
> --- a/gcc/config/riscv/riscv.md
> +++ b/gcc/config/riscv/riscv.md
> @@ -763,7 +763,7 @@
>[(set (match_operand:SI  0 "register_operand" "=r")
> (mult:SI (match_operand:SI 1 "register_operand" " r")
>  (match_operand:SI 2 "register_operand" " r")))]
> -  "TARGET_MUL"
> +  "TARGET_ZMMUL || TARGET_MUL"
>{ return TARGET_64BIT ? "mulw\t%0,%1,%2" : "mul\t%0,%1,%2"; }
>[(set_attr "type" "imul")
> (set_attr "mode" "SI")])
> @@ -772,7 +772,7 @@
>[(set (match_operand:DI  0 "register_operand" "=r")
> (mult:DI (match_operand:DI 1 "register_operand" " r")
>  (match_operand:DI 2 "register_operand" " r")))]
> -  "TARGET_MUL && TARGET_64BIT"
> +  "TARGET_ZMMUL || TARGET_MUL && TARGET_64BIT"
>"mul\t%0,%1,%2"
>[(set_attr "type" "imul")
> (set_attr "mode" "DI")])
> @@ -782,7 +782,7 @@
> (mult:GPR (match_operand:GPR 1 "register_operand" " r")
>   (match_operand:GPR 2 "register_operand" " r")))
> (label_ref (match_operand 3 "" ""))]
> -  "TARGET_MUL"
> +  "TARGET_ZMMUL || TARGET_MUL"
>  {
>if (TARGET_64BIT && mode == SImode)
>  {
> @@ -827,7 +827,7 @@
> (mult:GPR (match_operand:GPR 1 "register_operand" " r")
>   (match_operand:GPR 2 "register_operand" " r")))
> (label_ref (match_operand 3 "" ""))]
> -  "TARGET_MUL"
> +  "TARGET_ZMMUL || TARGET_MUL"
>  {
>if (TARGET_64BIT && mode == SImode)
>  {
> @@ -873,7 +873,7 @@
> (sign_extend:DI
> (mult:SI (match_operand:SI 1 "register_operand" " r")
>  (match_operand:SI 2 "register_operand" " r"]
> -  "TARGET_MUL && TARGET_64BIT"
> +  "(TARGET_ZMMUL || TARGET_MUL) && TARGET_64BIT"
>"mulw\t%0,%1,%2"
>[(set_attr "type" "imul")
> (set_attr "mode" "SI")])
> @@ -884,7 +884,7 @@
>   (match_operator:SI 3 "subreg_lowpart_operator"
> [(mult:DI (match_operand:DI 1 "register_operand" " r")
>   (match_operand:DI 2 "register_operand" " r"))])))]
> -  "TARGET_MUL && TARGET_64BIT"
> +  "(TARGET_ZMMUL || TARGET_MUL) && TARGET_64BIT"
>"mulw\t%0,%1,%2"
>[(set_attr "type" "imul")
> (set_attr "mode" "SI")])
> @@ -902,7 +902,7 @@
>[(set (match_operand:TI 0 "register_operand")
> (mult:TI (any_extend:TI (match_operand:DI 1 "register_operand"))
>  (any_extend:TI (match_operand:DI 2 "register_operand"]
> -  "TARGET_MUL && TARGET_64BIT"
> +  "(TARGET_ZMMUL || TARGET_MUL) && TARGET_64BIT"
>  {
>rtx low = gen_reg_rtx (DImode);
>emit_insn (gen_muldi3 (low, operands[1], operands[2]));
> @@ -924,7 +924,7 @@
>  (any_extend:TI
>(match_operand:DI 2 "register_operand" " r")))
> (const_int 64]
> -  "TARGET_MUL && TARGET_64BIT"
> +  "(TARGET_ZMMUL || TARGET_MUL) && TARGET_64BIT"
>"mulh\t%0,%1,%2"
>[(set_attr "type" "imul")
> (set_attr "mode" "DI")])
> @@ -933,7 +933,7 @@
>[(set (match_operand:TI  0 "register_operand")
> (mult:TI (zero_extend:TI (match_operand:DI 1 "register_operand"))
>  (sign_extend:TI (match_operand:DI 2 "register_operand"]
> -  "TARGET_MUL && TARGET_64BIT"
> +  "(TARGET_ZMMUL || TARGET_MUL) && TARGET_64BIT"
>  {
>rtx low = gen_reg_rtx (DImode);
>emit_insn (gen_muldi3 (low, operands[1], operands[2]));
> @@ -955,7 +955,7 @@
>  (sign_extend:TI
>(match_operand:DI 2 "register_operand" " r")))
> (const_int 64]
> -  "TARGET_MUL && TARGET_64BIT"
> +  "(TARGET_ZMMUL || TARGET_MUL) && 

Re: [PATCH] Add internal functions for iround etc. [PR106253]

[Richard Biener via Gcc-patches]

On Tue, Jul 12, 2022 at 2:07 PM Richard Sandiford via Gcc-patches
 wrote:
>
> The PR is about the aarch64 port using an ACLE built-in function
> to vectorise a scalar function call, even though the ECF_* flags for
> the ACLE function didn't match the ECF_* flags for the scalar call.
>
> To some extent that kind of difference is inevitable, since the
> ACLE intrinsics are supposed to follow the behaviour of the
> underlying instruction as closely as possible.  Also, using
> target-specific builtins has the drawback of limiting further
> gimple optimisation, since the gimple optimisers won't know what
> the function does.
>
> We handle several other maths functions, including round, floor
> and ceil, by defining directly-mapped internal functions that
> are linked to the associated built-in functions.  This has two
> main advantages:
>
> - it means that, internally, we are not restricted to the set of
>   scalar types that happen to have associated C/C++ functions
>
> - the functions (and thus the underlying optabs) extend naturally
>   to vectors
>
> This patch takes the same approach for the remaining functions
> handled by aarch64_builtin_vectorized_function.
>
> Tested on aarch64-linux-gnu and x86_64-linux-gnu.  OK to install?

OK.

Thanks,
Richard.

> Richard
>
>
> gcc/
> PR target/106253
> * predict.h (insn_optimization_type): Declare.
> * predict.cc (insn_optimization_type): New function.
> * internal-fn.def (IFN_ICEIL, IFN_IFLOOR, IFN_IRINT, IFN_IROUND)
> (IFN_LCEIL, IFN_LFLOOR, IFN_LRINT, IFN_LROUND, IFN_LLCEIL)
> (IFN_LLFLOOR, IFN_LLRINT, IFN_LLROUND): New internal functions.
> * internal-fn.cc (unary_convert_direct): New macro.
> (expand_convert_optab_fn): New function.
> (expand_unary_convert_optab_fn): New macro.
> (direct_unary_convert_optab_supported_p): Likewise.
> * optabs.cc (expand_sfix_optab): Pass insn_optimization_type to
> convert_optab_handler.
> * config/aarch64/aarch64-protos.h
> (aarch64_builtin_vectorized_function): Delete.
> * config/aarch64/aarch64-builtins.cc
> (aarch64_builtin_vectorized_function): Delete.
> * config/aarch64/aarch64.cc
> (TARGET_VECTORIZE_BUILTIN_VECTORIZED_FUNCTION): Delete.
> * config/i386/i386.cc (ix86_optab_supported_p): Handle lround_optab.
> * config/i386/i386.md (lround2): Remove
> optimize_insn_for_size_p test.
>
> gcc/testsuite/
> PR target/106253
> * gcc.target/aarch64/vect_unary_1.c: Add tests for iroundf,
> llround, iceilf, llceil, ifloorf, llfloor, irintf and llrint.
> * gfortran.dg/vect/pr106253.f: New test.
> ---
>  gcc/config/aarch64/aarch64-builtins.cc| 83 ---
>  gcc/config/aarch64/aarch64-protos.h   |  1 -
>  gcc/config/aarch64/aarch64.cc |  4 -
>  gcc/config/i386/i386.cc   |  1 +
>  gcc/config/i386/i386.md   |  3 -
>  gcc/internal-fn.cc| 20 +
>  gcc/internal-fn.def   | 23 +
>  gcc/optabs.cc |  3 +-
>  gcc/predict.cc| 11 +++
>  gcc/predict.h |  1 +
>  .../gcc.target/aarch64/vect_unary_1.c | 65 ++-
>  gcc/testsuite/gfortran.dg/vect/pr106253.f | 35 
>  12 files changed, 157 insertions(+), 93 deletions(-)
>  create mode 100644 gcc/testsuite/gfortran.dg/vect/pr106253.f
>
> diff --git a/gcc/config/aarch64/aarch64-builtins.cc 
> b/gcc/config/aarch64/aarch64-builtins.cc
> index a486321e10f..adfddb8b215 100644
> --- a/gcc/config/aarch64/aarch64-builtins.cc
> +++ b/gcc/config/aarch64/aarch64-builtins.cc
> @@ -2555,89 +2555,6 @@ aarch64_general_expand_builtin (unsigned int fcode, 
> tree exp, rtx target,
>gcc_unreachable ();
>  }
>
> -tree
> -aarch64_builtin_vectorized_function (unsigned int fn, tree type_out,
> -tree type_in)
> -{
> -  machine_mode in_mode, out_mode;
> -
> -  if (TREE_CODE (type_out) != VECTOR_TYPE
> -  || TREE_CODE (type_in) != VECTOR_TYPE)
> -return NULL_TREE;
> -
> -  out_mode = TYPE_MODE (type_out);
> -  in_mode = TYPE_MODE (type_in);
> -
> -#undef AARCH64_CHECK_BUILTIN_MODE
> -#define AARCH64_CHECK_BUILTIN_MODE(C, N) 1
> -#define AARCH64_FIND_FRINT_VARIANT(N) \
> -  (AARCH64_CHECK_BUILTIN_MODE (2, D) \
> -? aarch64_builtin_decls[AARCH64_SIMD_BUILTIN_UNOP_##N##v2df] \
> -: (AARCH64_CHECK_BUILTIN_MODE (4, S) \
> -   ? aarch64_builtin_decls[AARCH64_SIMD_BUILTIN_UNOP_##N##v4sf] \
> -   : (AARCH64_CHECK_BUILTIN_MODE (2, S) \
> -  ? aarch64_builtin_decls[AARCH64_SIMD_BUILTIN_UNOP_##N##v2sf] \
> -  : NULL_TREE)))
> -  switch (fn)
> -{
> -#undef AARCH64_CHECK_BUILTIN_MODE
> -#define AARCH64_CHECK_BUILTIN_MODE(C, N) \
> -  (out_mode == V##C##N##Imode && in_mode == V##C##N##Fmode)
> -CA

Re: XFAIL 'offloading_enabled' diagnostics issue in 'libgomp.oacc-c-c++-common/reduction-5.c' [PR101551] (was: Enhance '_Pragma' diagnostics verification in OMP C/C++ test cases)

[Tobias Burnus]

Hi,

On 12.07.22 13:50, Lewis Hyatt via Gcc-patches wrote:

On Tue, Jul 12, 2022 at 2:33 AM Thomas Schwinge  wrote:

On 2022-07-11T11:27:12+0200, I wrote:

Oh my, PR101551 "[offloading] Differences in diagnostics etc."
strikes again...  The latter two 'note' diagnostics are currently
only emitted in non-offloading configurations.  I've now pushed to
master branch commit 3723aedaad20a129741c2f6f3c22b3dd1220a3fc
"XFAIL 'offloading_enabled' diagnostics issue in
'libgomp.oacc-c-c++-common/reduction-5.c' [PR101551]", see attached.

Would you mind please confirming how I need to run configure in order
to get this configuration? Then I can look into why the difference in
location information there. Thanks.


I think the simplest to replicate it without much effort is to run:

cd ${GCC-SRC}/gcc
sed -e 's/ENABLE_OFFLOADING/true/' *.cc */*.cc

I think that covers all cases, which do not need the target lto1.
If they do do - then it becomes more difficult as you need an
offloading compiler. (But that is rather about: diagnostic or
no diagostic and not about having a different diagnostic.)

I think the different diagnostic has the reason stated in
commit r12-135-gbd7ebe9da745a62184052dd1b15f4dd10fbdc9f4

Namely:
cut---
It turned out that a compiler built without offloading support
and one with can produce slightly different diagnostic.

Offloading support implies ENABLE_OFFLOAD which implies that
g->have_offload is set when offloading is actually needed.
In cgraphunit.c, the latter causes flag_generate_offload = 1,
which in turn affects tree.c's free_lang_data.

The result is that the front-end specific diagnostic gets reset
('tree_diagnostics_defaults (global_dc)'), which affects in this
case 'Warning' vs. 'warning' via the Fortran frontend.

Result: 'Warning:' vs. 'warning:'.
Side note: Other FE also override the diagnostic, leading to
similar differences, e.g. the C++ FE outputs mangled function
names differently
cut--

If the message is from the offload-device's lto1 compiler, it
becomes more difficult to configure+build GCC. See
https://gcc.gnu.org/wiki/Offloading under
"How to build an offloading-enabled GCC"

I hope it helps.

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: [PATCH 2/2]middle-end: Support recognition of three-way max/min.

[Richard Biener via Gcc-patches]

On Tue, 5 Jul 2022, Tamar Christina wrote:

> > >   }
> > > +  else if (EDGE_SUCC (bb1, 0)->dest == EDGE_SUCC (bb2, 0)->dest
> > > +&& single_succ_p (bb1)
> > > +&& single_succ_p (bb2)
> > > +&& single_pred_p (bb1)
> > > +&& single_pred_p (bb2)
> > > +&& single_succ_p (EDGE_SUCC (bb1, 0)->dest))
> > 
> > please do the single_succ/pred checks below where appropriate, also what's
> > the last check about? 
> 
> Done.
> 
> > why does the merge block need a single successor?
> 
> I was using it to fix an ICE, but I realize that's not the right fix. I'm now 
> checking
> If the BB is empty instead, in which case it's just a fall through edge so 
> don't
> treat it as a diamond.
> 
> > 
> > > + {
> > > +   gimple_stmt_iterator it1 = gsi_start_nondebug_after_labels_bb
> > (bb1);
> > > +   gimple_stmt_iterator it2 = gsi_start_nondebug_after_labels_bb
> > (bb2);
> > > +   if (gsi_one_before_end_p (it1) && gsi_one_before_end_p (it2))
> > > + {
> > > +   gimple *stmt1 = gsi_stmt (it1);
> > > +   gimple *stmt2 = gsi_stmt (it2);
> > > +   if (is_gimple_assign (stmt1) && is_gimple_assign (stmt2))
> > > + {
> > > +   enum tree_code code1 = gimple_assign_rhs_code (stmt1);
> > > +   enum tree_code code2 = gimple_assign_rhs_code (stmt2);
> > > +   diamond_minmax_p
> > > + = (code1 == MIN_EXPR || code1 == MAX_EXPR)
> > > +   && (code2 == MIN_EXPR || code2 == MAX_EXPR);
> > > + }
> > > + }
> > > + }
> > 
> > I'd generalize this to general diamond detection, simply cutting off
> > *_replacement workers that do not handle diamonds and do appropriate
> > checks in minmax_replacement only.
> > 
> 
> Done.
> 
> > >else
> > >   continue;
> > >
> > > @@ -316,6 +340,13 @@ tree_ssa_phiopt_worker (bool do_store_elim,
> > bool do_hoist_loads, bool early_p)
> > > if (!candorest)
> > >   continue;
> > >
> > > +   /* Check that we're looking for nested phis.  */
> > > +   if (phis == NULL && diamond_minmax_p)
> > > + {
> > > +   phis = phi_nodes (EDGE_SUCC (bb2, 0)->dest);
> > > +   e2 = EDGE_SUCC (bb2, 0);
> > > + }
> > > +
> > 
> > instead
> > 
> >   basic_block merge = diamond_p ? EDGE_SUCC (bb2, 0)->dest : bb2;
> >   gimple_seq phis = phi_nodes (merge);
> > 
> 
> Done. 
> 
> > 
> > > phi = single_non_singleton_phi_for_edges (phis, e1, e2);
> > > if (!phi)
> > >   continue;
> > > @@ -329,6 +360,7 @@ tree_ssa_phiopt_worker (bool do_store_elim, bool
> > > do_hoist_loads, bool early_p)
> > >
> > > gphi *newphi;
> > > if (single_pred_p (bb1)
> > > +   && !diamond_minmax_p
> > > && (newphi = factor_out_conditional_conversion (e1, e2, phi,
> > > arg0, arg1,
> > > cond_stmt)))
> > > @@ -343,20 +375,25 @@ tree_ssa_phiopt_worker (bool do_store_elim,
> > bool do_hoist_loads, bool early_p)
> > >   }
> > >
> > > /* Do the replacement of conditional if it can be done.  */
> > > -   if (!early_p && two_value_replacement (bb, bb1, e2, phi, arg0,
> > arg1))
> > > +   if (!early_p
> > > +   && !diamond_minmax_p
> > > +   && two_value_replacement (bb, bb1, e2, phi, arg0, arg1))
> > >   cfgchanged = true;
> > > -   else if (match_simplify_replacement (bb, bb1, e1, e2, phi,
> > > -arg0, arg1,
> > > -early_p))
> > > +   else if (!diamond_minmax_p
> > > +&& match_simplify_replacement (bb, bb1, e1, e2, phi,
> > > +   arg0, arg1, early_p))
> > >   cfgchanged = true;
> > > else if (!early_p
> > > +&& !diamond_minmax_p
> > >  && single_pred_p (bb1)
> > >  && cond_removal_in_builtin_zero_pattern (bb, bb1, e1,
> > e2,
> > >   phi, arg0, arg1))
> > >   cfgchanged = true;
> > > -   else if (minmax_replacement (bb, bb1, e1, e2, phi, arg0, arg1))
> > > +   else if (minmax_replacement (bb, bb1, bb2, e1, e2, phi, arg0, arg1,
> > > +diamond_minmax_p))
> > >   cfgchanged = true;
> > > else if (single_pred_p (bb1)
> > > +&& !diamond_minmax_p
> > >  && spaceship_replacement (bb, bb1, e1, e2, phi, arg0,
> > arg1))
> > >   cfgchanged = true;
> > >   }
> > > @@ -385,7 +422,7 @@ tree_ssa_phiopt_worker (bool do_store_elim, bool
> > > do_hoist_loads, bool early_p)
> > >
> > >  static void
> > >  replace_phi_edge_with_variable (basic_block cond_block,
> > > - edge e, gphi *phi, tree new_tree)
> > > + edge e, gphi *phi, tree new_tree, bool
> > delete_bb = true)
> > >  {
> > >basic_block bb = gimple_bb (phi);
> > >gimple_stmt_iterator gsi;
> > > @@ -428,7 +465,7 @@ replace_phi_edge_with_variable (bas

Re: [PATCH 3/3] lto-plugin: implement LDPT_GET_API_VERSION

[Richard Biener via Gcc-patches]

On Tue, Jul 12, 2022 at 1:50 PM Rui Ueyama  wrote:
>
> I'm fine, though I don't think I have a right to sign off.
>
> On Tue, Jul 12, 2022 at 3:36 PM Martin Liška  wrote:
> >
> > On 7/12/22 08:28, Richard Biener wrote:
> > > On Mon, Jul 11, 2022 at 6:35 PM Alexander Monakov  
> > > wrote:
> > >>
> > >> On Mon, 11 Jul 2022, Martin Liška wrote:
> > >>
> > >>> I've clarified that linker should return a value that is in range
> > >>> [minimal_api_supported, maximal_api_supported] and added an abort
> > >>> if it's not the case.
> > >>
> > >> I noticed that we are placing a trap for C++ consumers such as mold
> > >> by passing min/max_api_supported as enum values. Unlike C, C++ disallows
> > >> out-of-range enum values, so when mold does
> > >>
> > >> enum PluginLinkerAPIVersion {
> > >>   LAPI_V0 = 0,
> > >>   LAPI_V1,
> > >> };
> > >>
> > >> get_api_version(const char *plugin_identifier,
> > >> unsigned plugin_version,
> > >> PluginLinkerAPIVersion minimal_api_supported,
> > >> PluginLinkerAPIVersion maximal_api_supported,
> > >> const char **linker_identifier,
> > >> const char **linker_version) {
> > >>
> > >> checks such as 'min_api_supported > LAPI_V1' can be optimized out. Also,
> > >> if a future tool passes LAPI_V2, it will trigger Clang's UBSan (GCC
> > >> -fsanitize-undefined=enum instruments loads but not retrieval of function
> > >> arguments).
> > >>
> > >> I'd suggest to fix this on both sides by changing the arguments to plain
> > >> integer types.
> > >
> > > That's a good point - the enum itself is then also somewhat redundant
> > > if it just specifies symbolic names for 0, 1, ... but we can keep it for
> > > documentation purposes.
> >
> > All right, here we go with the integer types.
> >
> > May I install the version now?

OK.

Thanks,
Richard.

> > Thanks,
> > Martin
> >
> > >
> > >>
> > >> Alexander

Re: [PATCH 1/2] Add gcc/make-unique.h

[Pedro Alves]

On 2022-07-12 1:25 a.m., David Malcolm via Gcc-patches wrote:

> I tried adding it to gcc/system.h, but anything that uses it needs to
> have std::unique_ptr declared, which meant forcibly including 
> from gcc/system.h

Did you consider making gcc/system.h include gcc/make-unique.h itself 
if INCLUDE_MEMORY is defined?  Something like:

 #ifdef INCLUDE_MEMORY
 # include 
+ #include "make-unique.h"
 #endif

This is because std::make_unique is defined in  in C++14.  This would
mean fewer changes once GCC requires C++14 (or later) and this new header is 
eliminated.

> (in the root namespace, rather than std::, which saves a bit more typing).

It's less typing now, but it will be more churn once GCC requires C++14 (or 
later), at
which point you'll naturally want to get rid of the custom make_unique.  More 
churn
since make_unique -> std::make_unique may require re-indentation of arguments, 
etc.
For that reason, I would suggest instead to put the function (and any other 
straight
standard library backport) in a 3-letter namespace already, like, 
gcc::make_unique
or gnu::make_unique.  That way, when the time comes that GCC requires C++14,
the patch to replace gcc::make_unique won't have to worry about reindenting 
code,
it'll just replace gcc -> std.

Re: [PATCH 3/3] lto-plugin: implement LDPT_GET_API_VERSION

[Martin Liška]

On 7/12/22 13:50, Rui Ueyama wrote:
> I'm fine, though I don't think I have a right to sign off.

I've just pushed that.

@Rui: Can you please merge the mold counter-part?

Thanks,
Martin

[PATCH] c++: coroutines - Overlap variables in frame [PR105989]

[Michal Jankovič via Gcc-patches]

Currently, coroutine frames store all variables of a coroutine separately,
even if their lifetime does not overlap (they are in distinct scopes). This
patch implements overlapping distinct variable scopes in the coroutine frame,
by storing the frame fields in nested unions of structs. This lowers the size
of the frame for larger coroutines significantly, and makes them more usable
on systems with limited memory.

Bootstrapped and regression tested on x86_64-pc-linux-gnu; new test fails
before the patch and succeeds after with no regressions.

PR c++/105989

gcc/cp/ChangeLog:

* coroutines.cc (struct local_var_info): Add field_access_path.
(build_local_var_frame_access_expr): New.
(transform_local_var_uses): Use build_local_var_frame_access_expr.
(coro_make_frame_entry_id): New.
(coro_make_frame_entry): Delegate to coro_make_frame_entry_id.
(struct local_vars_frame_data): Add orig, field_access_path.
(register_local_var_uses): Generate new frame layout. Create access
paths to vars.
(morph_fn_to_coro): Set new fields in local_vars_frame_data. 

gcc/testsuite/ChangeLog:

* g++.dg/coroutines/pr105989.C: New test.



pr105989.patch
Description: Binary data

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

[Tom de Vries via Gcc-patches]

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

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

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

Hi,

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

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

This is a regression since commit a08bdb159bb ("[gdb/build] Fix gdbserver
build with -fsanitize=thread").

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

effect that only one is handled.

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

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

OK for gcc trunk?



Ping.

Thanks,
- Tom


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

Thanks,
- Tom



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

ChangeLog:

2022-06-27  Tom de Vries  

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

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

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

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

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

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

Re: [PATCH 1/2] Add gcc/make-unique.h

[Jonathan Wakely via Gcc-patches]

On Tue, 12 Jul 2022 at 14:24, Pedro Alves wrote:
>
> On 2022-07-12 1:25 a.m., David Malcolm via Gcc-patches wrote:
>
> > I tried adding it to gcc/system.h, but anything that uses it needs to
> > have std::unique_ptr declared, which meant forcibly including 
> > from gcc/system.h
>
> Did you consider making gcc/system.h include gcc/make-unique.h itself
> if INCLUDE_MEMORY is defined?  Something like:
>
>  #ifdef INCLUDE_MEMORY
>  # include 
> + #include "make-unique.h"
>  #endif
>
> This is because std::make_unique is defined in  in C++14.  This would
> mean fewer changes once GCC requires C++14 (or later) and this new header is 
> eliminated.

That's a good idea.

> > (in the root namespace, rather than std::, which saves a bit more typing).
>
> It's less typing now, but it will be more churn once GCC requires C++14 (or 
> later), at
> which point you'll naturally want to get rid of the custom make_unique.  More 
> churn
> since make_unique -> std::make_unique may require re-indentation of 
> arguments, etc.
> For that reason, I would suggest instead to put the function (and any other 
> straight
> standard library backport) in a 3-letter namespace already, like, 
> gcc::make_unique
> or gnu::make_unique.  That way, when the time comes that GCC requires C++14,
> the patch to replace gcc::make_unique won't have to worry about reindenting 
> code,
> it'll just replace gcc -> std.

Or (when the time comes) don't change gcc->std and do:

namespace gcc {
  using std::make_unique;
}

or just leave it in the global namespace as in your current patch, and
at a later date add a using-declaration to the global namespace:

using std::make_unique;

RE: [PATCH 1/2]AArch64 Fix 128-bit sequential consistency atomic operations.

[Kyrylo Tkachov via Gcc-patches]

Hi Tamar,

Let me be the latest to offer my apologies for the slow review.

> -Original Message-
> From: Tamar Christina 
> Sent: Wednesday, June 8, 2022 3:49 PM
> To: gcc-patches@gcc.gnu.org
> Cc: nd ; Richard Earnshaw ;
> Marcus Shawcroft ; Kyrylo Tkachov
> ; Richard Sandiford
> 
> Subject: [PATCH 1/2]AArch64 Fix 128-bit sequential consistency atomic
> operations.
> 
> Hi All,
> 
> The AArch64 implementation of 128-bit atomics is broken.
> 
> For 128-bit atomics we rely on pthread barriers to correct guard the address
> in the pointer to get correct memory ordering.  However for 128-bit atomics
> the
> address under the lock is different from the original pointer.
> 
> This means that one of the values under the atomic operation is not
> protected
> properly and so we fail during when the user has requested sequential
> consistency as there's no barrier to enforce this requirement.
> 
> As such users have resorted to adding an
> 
> #ifdef GCC
> 
> #endif
> 
> around the use of these atomics.
> 
> This corrects the issue by issuing a barrier only when __ATOMIC_SEQ_CST
> was
> requested.  To remedy this performance hit I think we should revisit using a
> similar approach to out-line-atomics for the 128-bit atomics.
> 
> Note that I believe I need the empty file due to the include_next chain but
> I am not entirely sure.  I have hand verified that the barriers are inserted
> for atomic seq cst.
> 
> Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
> 
> Ok for master? and for backporting to GCC 12, 11 and 10?

I'll admit I'm not too familiar with the mechanics of libatomic but...

> 
> Thanks,
> Tamar
> 
> libatomic/ChangeLog:
> 
>   PR target/102218
>   * config/aarch64/aarch64-config.h: New file.
>   * config/aarch64/host-config.h: New file.
> 
> --- inline copy of patch --
> diff --git a/libatomic/config/aarch64/aarch64-config.h
> b/libatomic/config/aarch64/aarch64-config.h
> new file mode 100644
> index
> ..d3474fa8ff80cb0c3ddbf8c4
> 8acd931d2339d33d
> --- /dev/null
> +++ b/libatomic/config/aarch64/aarch64-config.h
> @@ -0,0 +1,23 @@
> +/* Copyright (C) 2022 Free Software Foundation, Inc.
> +
> +   This file is part of the GNU Atomic Library (libatomic).
> +
> +   Libatomic is free software; you can redistribute it and/or modify it
> +   under the terms of the GNU General Public License as published by
> +   the Free Software Foundation; either version 3 of the License, or
> +   (at your option) any later version.
> +
> +   Libatomic is distributed in the hope that it will be useful, but WITHOUT
> ANY
> +   WARRANTY; without even the implied warranty of MERCHANTABILITY or
> FITNESS
> +   FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> +   more details.
> +
> +   Under Section 7 of GPL version 3, you are granted additional
> +   permissions described in the GCC Runtime Library Exception, version
> +   3.1, as published by the Free Software Foundation.
> +
> +   You should have received a copy of the GNU General Public License and
> +   a copy of the GCC Runtime Library Exception along with this program;
> +   see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
> +   .  */
> +
> diff --git a/libatomic/config/aarch64/host-config.h
> b/libatomic/config/aarch64/host-config.h
> new file mode 100644
> index
> ..f445a47d25ef5cc51cd21670
> 69500245d07bf1bc
> --- /dev/null
> +++ b/libatomic/config/aarch64/host-config.h
> @@ -0,0 +1,46 @@
> +/* Copyright (C) 2022 Free Software Foundation, Inc.
> +
> +   This file is part of the GNU Atomic Library (libatomic).
> +
> +   Libatomic is free software; you can redistribute it and/or modify it
> +   under the terms of the GNU General Public License as published by
> +   the Free Software Foundation; either version 3 of the License, or
> +   (at your option) any later version.
> +
> +   Libatomic is distributed in the hope that it will be useful, but WITHOUT
> ANY
> +   WARRANTY; without even the implied warranty of MERCHANTABILITY or
> FITNESS
> +   FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> +   more details.
> +
> +   Under Section 7 of GPL version 3, you are granted additional
> +   permissions described in the GCC Runtime Library Exception, version
> +   3.1, as published by the Free Software Foundation.
> +
> +   You should have received a copy of the GNU General Public License and
> +   a copy of the GCC Runtime Library Exception along with this program;
> +   see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
> +   .  */
> +
> +/* Avoiding the DMB (or kernel helper) can be a good thing.  */
> +#define WANT_SPECIALCASE_RELAXED
> +
> +/* Glibc, at least, uses acq_rel in its pthread mutex
> +   implementation.  If the user is asking for seq_cst,
> +   this is insufficient.  */
> +
> +static inline void __attribute__(

Re: [PING][PATCH][gdb/build] Fix build breaker with --enabled-shared

[Iain Sandoe via Gcc-patches]

Hi Tom

> On 12 Jul 2022, at 14:42, Tom de Vries via Gcc-patches 
>  wrote:
> 
> [ dropped gdb-patches, since already applied there. ]
> 
> On 6/27/22 15:38, Tom de Vries wrote:
>> On 6/27/22 15:03, Tom de Vries wrote:
>>> Hi,
>>> 
>>> When building gdb with --enabled-shared, I run into:
>>> ...
>>> ld: build/zlib/libz.a(libz_a-inffast.o): relocation R_X86_64_32S against \
>>>`.rodata' can not be used when making a shared object; recompile with 
>>> -fPIC
>>> ld: build/zlib/libz.a(libz_a-inflate.o): warning: relocation against \
>>>`inflateResetKeep' in read-only section `.text'
>>> collect2: error: ld returned 1 exit status
>>> make[3]: *** [libbfd.la] Error 1
>>> ...
>>> 
>>> This is a regression since commit a08bdb159bb ("[gdb/build] Fix gdbserver
>>> build with -fsanitize=thread").
>>> 
>>> The problem is that a single case statement in configure is shared to handle
>>> special requirements for both the host libiberty and host zlib, which has 
>>> the
>>> effect that only one is handled.
>>> 
>>> Fix this by handling libiberty and zlib each in its own case statement.
>>> 
>>> Build on x86_64-linux, with and without --enable-shared.
>>> 
>>> OK for gcc trunk?
>>> 
> 
> Ping.

see also 
https://gcc.gnu.org/pipermail/gcc-patches/2022-June/597263.html
which is approved but i didn’t yet push it .. 

do you not see any issues with GMP et. al. (or are they not used)?
Iain

> 
> Thanks,
> - Tom
> 
>> To fix the buildbot breakage, I already pushed to the gdb repo.
>> Thanks,
>> - Tom
>>> 
>>> [gdb/build] Fix build breaker with --enabled-shared
>>> 
>>> ChangeLog:
>>> 
>>> 2022-06-27  Tom de Vries  
>>> 
>>> * configure.ac: Set extra_host_libiberty_configure_flags and
>>> extra_host_zlib_configure_flags in separate case statements.
>>> * configure: Regenerate.
>>> 
>>> ---
>>>   configure| 8 ++--
>>>   configure.ac | 8 ++--
>>>   2 files changed, 12 insertions(+), 4 deletions(-)
>>> 
>>> diff --git a/configure b/configure
>>> index aac80b88d70..be433ef6d5d 100755
>>> --- a/configure
>>> +++ b/configure
>>> @@ -6962,13 +6962,18 @@ fi
>>>   # Sometimes we have special requirements for the host libiberty.
>>>   extra_host_libiberty_configure_flags=
>>> -extra_host_zlib_configure_flags=
>>>   case " $configdirs " in
>>> *" lto-plugin "* | *" libcc1 "* | *" gdbserver "*)
>>>   # When these are to be built as shared libraries, the same applies to
>>>   # libiberty.
>>>   extra_host_libiberty_configure_flags=--enable-shared
>>>   ;;
>>> +esac
>>> +
>>> +
>>> +# Sometimes we have special requirements for the host zlib.
>>> +extra_host_zlib_configure_flags=
>>> +case " $configdirs " in
>>> *" bfd "*)
>>>   # When bfd is to be built as a shared library, the same applies to
>>>   # zlib.
>>> @@ -6979,7 +6984,6 @@ case " $configdirs " in
>>>   esac
>>> -
>>>   # Produce a warning message for the subdirs we can't configure.
>>>   # This isn't especially interesting in the Cygnus tree, but in the 
>>> individual
>>>   # FSF releases, it's important to let people know when their machine isn't
>>> diff --git a/configure.ac b/configure.ac
>>> index 29f74d10b5a..1651cbf3b02 100644
>>> --- a/configure.ac
>>> +++ b/configure.ac
>>> @@ -2342,13 +2342,18 @@ fi
>>>   # Sometimes we have special requirements for the host libiberty.
>>>   extra_host_libiberty_configure_flags=
>>> -extra_host_zlib_configure_flags=
>>>   case " $configdirs " in
>>> *" lto-plugin "* | *" libcc1 "* | *" gdbserver "*)
>>>   # When these are to be built as shared libraries, the same applies to
>>>   # libiberty.
>>>   extra_host_libiberty_configure_flags=--enable-shared
>>>   ;;
>>> +esac
>>> +AC_SUBST(extra_host_libiberty_configure_flags)
>>> +
>>> +# Sometimes we have special requirements for the host zlib.
>>> +extra_host_zlib_configure_flags=
>>> +case " $configdirs " in
>>> *" bfd "*)
>>>   # When bfd is to be built as a shared library, the same applies to
>>>   # zlib.
>>> @@ -2357,7 +2362,6 @@ case " $configdirs " in
>>>   fi
>>>   ;;
>>>   esac
>>> -AC_SUBST(extra_host_libiberty_configure_flags)
>>>   AC_SUBST(extra_host_zlib_configure_flags)
>>>   # Produce a warning message for the subdirs we can't configure.

Re: [PATCH] Add condition coverage profiling

[Sebastian Huber]

Hello Jørgen,

thanks for the updated patch. I used it for a test suite run and the 
results look quite good.


Could you please add this hunk to your patch set:

diff --git a/libgcc/libgcov-merge.c b/libgcc/libgcov-merge.c
index 89741f637e1..9e3e8ee5657 100644
--- a/libgcc/libgcov-merge.c
+++ b/libgcc/libgcov-merge.c
@@ -33,6 +33,11 @@ void __gcov_merge_add (gcov_type *counters 
__attribute__ ((unused)),

unsigned n_counters __attribute__ ((unused))) {}
 #endif

+#ifdef L_gcov_merge_ior
+void __gcov_merge_ior (gcov_type *counters  __attribute__ ((unused)),
+  unsigned n_counters __attribute__ ((unused))) {}
+#endif
+
 #ifdef L_gcov_merge_topn
 void __gcov_merge_topn (gcov_type *counters  __attribute__ ((unused)),
unsigned n_counters __attribute__ ((unused))) {}

It is necessary to use gcov in freestanding environments (inhibit_libc 
is defined).


The condition profiling found one spot for which we have insufficient 
condition coverage:


function _Leap_year called 227 returned 100% blocks executed 100%
  227:   54:static bool _Leap_year(
-:   55:  uint32_t year
-:   56:)
-:   57:{
  227:   58:  return (((year % 4) == 0) && ((year % 100) != 0)) || 
((year % 400) == 0);

branch  0 taken 19% (fallthrough)
branch  1 taken 81%
branch  2 taken 16% (fallthrough)
branch  3 taken 84%
branch  4 taken 4% (fallthrough)
branch  5 taken 96%
conditions covered 5/6
condition  1 not covered (false)
-:   59:}

This is because we don't test with the year 2100 for example. This value 
would result in:


year % 4 == 0: true
year % 100 != 0: false
year % 400 == 0: false

It was not immediately clear to me what the

"conditions covered 5/6
condition  1 not covered (false)"

is supposed to tell me. I guess a reasonable interpretation is: 
condition 1 (which is "(year % 100) != 0" should be false and determine 
the outcome of the decision.


What could be a bit confusing is that we have "conditions covered 5/6", 
however, there are only three conditions (0: (year % 4) == 0, 1: (year % 
100) != 0, 2: (year % 400) == 0). Maybe it would be more clear if the 
report says "condition variants covered 5/6" or something like this.


--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/

Re: [PATCH 1/2] Add gcc/make-unique.h

[Pedro Alves]

On 2022-07-12 2:45 p.m., Jonathan Wakely wrote:
> On Tue, 12 Jul 2022 at 14:24, Pedro Alves wrote:
>>
>> On 2022-07-12 1:25 a.m., David Malcolm via Gcc-patches wrote:
>>
>>> I tried adding it to gcc/system.h, but anything that uses it needs to
>>> have std::unique_ptr declared, which meant forcibly including 
>>> from gcc/system.h
>>
>> Did you consider making gcc/system.h include gcc/make-unique.h itself
>> if INCLUDE_MEMORY is defined?  Something like:
>>
>>  #ifdef INCLUDE_MEMORY
>>  # include 
>> + #include "make-unique.h"
>>  #endif
>>
>> This is because std::make_unique is defined in  in C++14.  This would
>> mean fewer changes once GCC requires C++14 (or later) and this new header is 
>> eliminated.
> 
> That's a good idea.
> 
>>> (in the root namespace, rather than std::, which saves a bit more typing).
>>
>> It's less typing now, but it will be more churn once GCC requires C++14 (or 
>> later), at
>> which point you'll naturally want to get rid of the custom make_unique.  
>> More churn
>> since make_unique -> std::make_unique may require re-indentation of 
>> arguments, etc.
>> For that reason, I would suggest instead to put the function (and any other 
>> straight
>> standard library backport) in a 3-letter namespace already, like, 
>> gcc::make_unique
>> or gnu::make_unique.  That way, when the time comes that GCC requires C++14,
>> the patch to replace gcc::make_unique won't have to worry about reindenting 
>> code,
>> it'll just replace gcc -> std.
> 
> Or (when the time comes) don't change gcc->std and do:
> 
> namespace gcc {
>   using std::make_unique;
> }

It will seem like a pointless indirection then, IMO.

> 
> or just leave it in the global namespace as in your current patch, and
> at a later date add a using-declaration to the global namespace:
> 
> using std::make_unique;
> 

That's not very idiomatic, though.  Let me turn this into a reverse question:

If GCC required C++14 today, would you be doing the above, either importing 
make_unique
to the global namespace, or into namespace gcc?   I think it's safe to say 
that, no,
nobody would be doing that.  So once GCC requires C++14, why would you want to 
preserve
once-backported symbols in a namespace other than std, when you no longer have 
a reason to?
It will just be another unnecessary thing that newcomers at that future time 
will have
to learn.

Re: [PATCH] c++: coroutines - Overlap variables in frame [PR105989]

[Iain Sandoe]

Hi Michal,

> On 12 Jul 2022, at 14:35, Michal Jankovič via Gcc-patches 
>  wrote:
> 
> Currently, coroutine frames store all variables of a coroutine separately,
> even if their lifetime does not overlap (they are in distinct scopes). This
> patch implements overlapping distinct variable scopes in the coroutine frame,
> by storing the frame fields in nested unions of structs. This lowers the size
> of the frame for larger coroutines significantly, and makes them more usable
> on systems with limited memory.

not a review (I will try to take a look at the weekend).

but … this is one of the two main optimisations on my TODO - so cool for doing 
it.

(the other related optimisation is to eliminate frame entries for scopes 
without any suspend
 points - which has the potential to save even more space for code with sparse 
use of co_)

Iain

> Bootstrapped and regression tested on x86_64-pc-linux-gnu; new test fails
> before the patch and succeeds after with no regressions.
> 
>   PR c++/105989
> 
> gcc/cp/ChangeLog:
> 
>   * coroutines.cc (struct local_var_info): Add field_access_path.
>   (build_local_var_frame_access_expr): New.
>   (transform_local_var_uses): Use build_local_var_frame_access_expr.
>   (coro_make_frame_entry_id): New.
>   (coro_make_frame_entry): Delegate to coro_make_frame_entry_id.
>   (struct local_vars_frame_data): Add orig, field_access_path.
>   (register_local_var_uses): Generate new frame layout. Create access
>   paths to vars.
>   (morph_fn_to_coro): Set new fields in local_vars_frame_data. 
> 
> gcc/testsuite/ChangeLog:
> 
>   * g++.dg/coroutines/pr105989.C: New test.
> 
> 

Re: [PING][PATCH][gdb/build] Fix build breaker with --enabled-shared

[Tom de Vries via Gcc-patches]

On 7/12/22 15:59, Iain Sandoe wrote:

Hi Tom


On 12 Jul 2022, at 14:42, Tom de Vries via Gcc-patches 
 wrote:

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

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

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

Hi,

When building gdb with --enabled-shared, I run into:
...
ld: build/zlib/libz.a(libz_a-inffast.o): relocation R_X86_64_32S against \
`.rodata' can not be used when making a shared object; recompile with -fPIC
ld: build/zlib/libz.a(libz_a-inflate.o): warning: relocation against \
`inflateResetKeep' in read-only section `.text'
collect2: error: ld returned 1 exit status
make[3]: *** [libbfd.la] Error 1
...

This is a regression since commit a08bdb159bb ("[gdb/build] Fix gdbserver
build with -fsanitize=thread").

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

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

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

OK for gcc trunk?



Ping.


see also
https://gcc.gnu.org/pipermail/gcc-patches/2022-June/597263.html
which is approved but i didn’t yet push it ..



Ack.


do you not see any issues with GMP et. al. (or are they not used)?


Well, it's used, but I'm not building it in-tree:
...
$ ldd ./gdb | grep gmp
libgmp.so.10 => /usr/lib64/libgmp.so.10 (0x7f7008706000)
...

Thanks,
- Tom


Iain



Thanks,
- Tom


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


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

ChangeLog:

2022-06-27  Tom de Vries  

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

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

diff --git a/configure b/configure
index aac80b88d70..be433ef6d5d 100755
--- a/configure
+++ b/configure
@@ -6962,13 +6962,18 @@ fi
   # Sometimes we have special requirements for the host libiberty.
   extra_host_libiberty_configure_flags=
-extra_host_zlib_configure_flags=
   case " $configdirs " in
 *" lto-plugin "* | *" libcc1 "* | *" gdbserver "*)
   # When these are to be built as shared libraries, the same applies to
   # libiberty.
   extra_host_libiberty_configure_flags=--enable-shared
   ;;
+esac
+
+
+# Sometimes we have special requirements for the host zlib.
+extra_host_zlib_configure_flags=
+case " $configdirs " in
 *" bfd "*)
   # When bfd is to be built as a shared library, the same applies to
   # zlib.
@@ -6979,7 +6984,6 @@ case " $configdirs " in
   esac
-
   # Produce a warning message for the subdirs we can't configure.
   # This isn't especially interesting in the Cygnus tree, but in the individual
   # FSF releases, it's important to let people know when their machine isn't
diff --git a/configure.ac b/configure.ac
index 29f74d10b5a..1651cbf3b02 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2342,13 +2342,18 @@ fi
   # Sometimes we have special requirements for the host libiberty.
   extra_host_libiberty_configure_flags=
-extra_host_zlib_configure_flags=
   case " $configdirs " in
 *" lto-plugin "* | *" libcc1 "* | *" gdbserver "*)
   # When these are to be built as shared libraries, the same applies to
   # libiberty.
   extra_host_libiberty_configure_flags=--enable-shared
   ;;
+esac
+AC_SUBST(extra_host_libiberty_configure_flags)
+
+# Sometimes we have special requirements for the host zlib.
+extra_host_zlib_configure_flags=
+case " $configdirs " in
 *" bfd "*)
   # When bfd is to be built as a shared library, the same applies to
   # zlib.
@@ -2357,7 +2362,6 @@ case " $configdirs " in
   fi
   ;;
   esac
-AC_SUBST(extra_host_libiberty_configure_flags)
   AC_SUBST(extra_host_zlib_configure_flags)
   # Produce a warning message for the subdirs we can't configure.

Re: [PATCH] [RFC]Support vectorization for Complex type.

[Richard Biener via Gcc-patches]

On Tue, Jul 12, 2022 at 6:11 AM Hongtao Liu  wrote:
>
> On Mon, Jul 11, 2022 at 7:47 PM Richard Biener via Gcc-patches
>  wrote:
> >
> > On Mon, Jul 11, 2022 at 5:44 AM liuhongt  wrote:
> > >
> > > The patch only handles load/store(including ctor/permutation, except
> > > gather/scatter) for complex type, other operations don't needs to be
> > > handled since they will be lowered by pass cplxlower.(MASK_LOAD is not
> > > supported for complex type, so no need to handle either).
> >
> > (*)
> >
> > > Instead of support vector(2) _Complex double, this patch takes vector(4)
> > > double as vector type of _Complex double. Since vectorizer originally
> > > takes TYPE_VECTOR_SUBPARTS as nunits which is not true for complex
> > > type, the patch handles nunits/ncopies/vf specially for complex type.
> >
> > For the limited set above(*) can you explain what's "special" about
> > vector(2) _Complex
> > vs. vector(4) double, thus why we need to have STMT_VINFO_COMPLEX_P at all?
> Supporting a vector(2) complex  is a straightforward idea, just like
> supporting other scalar type in vectorizer, but it requires more
> efforts(in the backend and frontend), considering that most of
> operations of complex type will be lowered into realpart and imagpart
> operations, supporting a vector(2) complex does not look that
> necessary. Then it comes up with supporting vector(4) double(with
> adjustment of vf/ctor/permutation), the vectorizer only needs to
> handle the vectorization of the move operation of the complex type(no
> need to worry about wrongly mapping vector(4) double multiplication to
> complex type multiplication since it's already lowered before
> vectorizer).
> stmt_info does not record the scalar type, in order to avoid duplicate
> operation like getting a lhs type from stmt to determine whether it is
> a complex type, STMT_VINFO_COMPLEX_P bit is added, this bit is mainly
> initialized in vect_analyze_data_refs and vect_get_vector_types_for_
> stmt.
> >
> > I wonder to what extent your handling can be extended to support 
> > re-vectorizing
> > (with a higher VF for example) already vectorized code?  The vectorizer 
> > giving
> > up on vector(2) double looks quite obviously similar to it giving up
> > on _Complex double ...
> Yes, it can be extended to vector(2) double/float/int/ with a bit
> adjustment(exacting element by using bit_field instead of
> imagpart_expr/realpart_expr).
> > It would be a shame to not use the same underlying mechanism for dealing 
> > with
> > both, where for the vector case obviously vector(4) would be supported as 
> > well.
> >
> > In principle _Complex double operations should be two SLP lanes but it 
> > seems you
> > are handling them with classical interleaving as well?
> I'm only handling move operations, for other operations it will be
> lowered to realpart and imagpart and thus two SLP lanes.

Yes, I understood that.

Doing it more general (and IMHO better) would involve enhancing
how we represent dataref groups, maintaining the number of scalars
covered by each of the vinfos.  On the SLP representation side it
probably requires to rely on the representative for access and not
on the scalar stmts (since those do not map properly to the lanes).

Ideally we'd be able to handle

struct { _Complex double c; double a; double b; } a[], b[];

void foo ()
{
   for (int i = 0; i < 100; ++i)
{
  a[i].c = b[i].c;
  a[i].a = b[i].a;
  a[i].b = b[i].b;
}
}

which I guess your patch doesn't handle with plain AVX vector
copies but instead uses interleaving for the _Complex and non-_Complex
parts?

Let me spend some time fleshing out what is necessary to make
this work "properly".  We can consider your special-casing of _Complex
memory ops if I can't manage to assess the complexity of the task.

Thanks,
Richard.

> >
> > Thanks,
> > Richard.
> >
> > > Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
> > > Also test the patch for SPEC2017 and find there's complex type 
> > > vectorization
> > > in 510/549(but no performance impact).
> > >
> > > Any comments?
> > >
> > > gcc/ChangeLog:
> > >
> > > PR tree-optimization/106010
> > > * tree-vect-data-refs.cc (vect_get_data_access_cost):
> > > Pass complex_p to vect_get_num_copies to avoid ICE.
> > > (vect_analyze_data_refs): Support vectorization for Complex
> > > type with vector scalar types.
> > > * tree-vect-loop.cc (vect_determine_vf_for_stmt_1): VF should
> > > be half of TYPE_VECTOR_SUBPARTS when complex_p.
> > > * tree-vect-slp.cc (vect_record_max_nunits): nunits should be
> > > half of TYPE_VECTOR_SUBPARTS when complex_p.
> > > (vect_optimize_slp): Support permutation for complex type.
> > > (vect_slp_analyze_node_operations_1): Double nunits in
> > > vect_get_num_vectors to get right SLP_TREE_NUMBER_OF_VEC_STMTS
> > > when complex_p.
> > > (vect_slp_analyze_node_operations): Ditto.
> > >   

Re: Modula-2: merge followup (brief update on the progress of the new linking implementation)

[Rainer Orth]

Hi Gaius,

> many thanks for the patch and log of the failures.  I've committed the
> patch and rebuilt all Makefile.in's which are affected by m2.

thanks.  I've noticed that libgm2/configure has been generated with a
patched autoconf which includes runstatedir, unlike the upstream
version.  It's just a nit, but confusing.

> I think this just leaves:
>
>> * While this lets the build finish on all of i386-pc-solaris2.11,
>>   sparcv9-sun-solaris2.11, and x86_64-pc-linux-gnu, I get thousands of
>>   testsuite failures, all of the same kind:
>>
>> Undefined   first referenced
>>  symbol in file
>> RTco_signal 
>> /var/gcc/modula-2/11.4-gcc-modula-2/i386-pc-solaris2.11/./libgm2/libm2pim/.libs/libm2pim.so
>> RTco_select 
>> /var/gcc/modula-2/11.4-gcc-modula-2/i386-pc-solaris2.11/./libgm2/libm2pim/.libs/libm2pim.so
>> RTco_initSemaphore  
>> /var/gcc/modula-2/11.4-gcc-modula-2/i386-pc-solaris2.11/./libgm2/libm2pim/.libs/libm2pim.so
>> RTco_wait   
>> /var/gcc/modula-2/11.4-gcc-modula-2/i386-pc-solaris2.11/./libgm2/libm2pim/.libs/libm2pim.so
>> ld: fatal: symbol referencing errors
>> collect2: error: ld returned 1 exit status
>> compiler exited with status 1
>> FAIL: gm2/exceptions/run/pass/libexcept.mod compilation,  -g
>>
>>   I haven't yet tried to fix those.
>
> which I'll try and reproduce,

Excellent.  I've also seen this one on Linux/x86_64, so this isn't a
Solaris-specific issue.

Rainer

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

[PATCH] openmp: fix max_vf setting for amdgcn offloading

[Andrew Stubbs]

This patch ensures that the maximum vectorization factor used to set the 
"safelen" attribute on "omp simd" constructs is suitable for all the 
configured offload devices.


Right now it makes the proper adjustment for NVPTX, but otherwise just 
uses a value suitable for the host system (always x86_64 in the case of 
amdgcn).  This typically ends up being 16 where 64 is the minimum for 
vectorization to work properly on GCN.


There is a potential problem that one "safelen" must be set for *all* 
offload devices, which means it can't be perfect for all devices. 
However I believe that too big is always OK (at least for powers of 
two?) whereas too small is not OK, so this code always selects the 
largest value of max_vf, regardless of where it comes from.


The existing target VF function, omp_max_simt_vf, is tangled up with the 
notion of whether SIMT is available or not, so I couldn't add amdgcn in 
there. It's tempting to have omp_max_vf do some kind of autodetect what 
VF to choose, but the current implementation in omp-general.cc doesn't 
have access to the context in a convenient way, and nor do all the 
callers, so I couldn't easily do that. Instead, I have opted to add a 
new function, omp_max_simd_vf, which can check for the presence of amdgcn.


While reviewing the callers of omp_max_vf I found one other case that 
looks like it ought to be tuned for the device, not just the host. In 
that case it's not clear how to achieve that and in fact, at least on 
x86_64, the way it is coded the actual value from omp_max_vf is always 
ignored in favour of a much larger "minimum", so I have added a comment 
for the next person to touch that spot and left it alone.


This change gives a 10x performance improvement on the BabelStream "dot" 
benchmark on amdgcn and is not harmful on nvptx.


OK for mainline?

I will commit a backport to OG12 shortly.

Andrewopenmp: fix max_vf setting for amdgcn offloading

Ensure that the "max_vf" figure used for the "safelen" attribute is large
enough for the largest configured offload device.

This change gives ~10x speed improvement on the Bablestream "dot" benchmark for
AMD GCN.

gcc/ChangeLog:

* gimple-loop-versioning.cc (loop_versioning::loop_versioning): Add
comment.
* omp-general.cc (omp_max_simd_vf): New function.
* omp-general.h (omp_max_simd_vf): New prototype.
* omp-low.cc (lower_rec_simd_input_clauses): Select largest from
  omp_max_vf, omp_max_simt_vf, and omp_max_simd_vf.

gcc/testsuite/ChangeLog:

* lib/target-supports.exp
(check_effective_target_amdgcn_offloading_enabled): New.
(check_effective_target_nvptx_offloading_enabled): New.
* gcc.dg/gomp/target-vf.c: New test.

diff --git a/gcc/gimple-loop-versioning.cc b/gcc/gimple-loop-versioning.cc
index 6bcf6eba691..e908c27fc44 100644
--- a/gcc/gimple-loop-versioning.cc
+++ b/gcc/gimple-loop-versioning.cc
@@ -555,7 +555,10 @@ loop_versioning::loop_versioning (function *fn)
  unvectorizable code, since it is the largest size that can be
  handled efficiently by scalar code.  omp_max_vf calculates the
  maximum number of bytes in a vector, when such a value is relevant
- to loop optimization.  */
+ to loop optimization.
+ FIXME: this probably needs to use omp_max_simd_vf when in a target
+ region, but how to tell? (And MAX_FIXED_MODE_SIZE is large enough that
+ it doesn't actually matter.)  */
   m_maximum_scale = estimated_poly_value (omp_max_vf ());
   m_maximum_scale = MAX (m_maximum_scale, MAX_FIXED_MODE_SIZE);
 }
diff --git a/gcc/omp-general.cc b/gcc/omp-general.cc
index a406c578f33..8c6fcebc4b3 100644
--- a/gcc/omp-general.cc
+++ b/gcc/omp-general.cc
@@ -994,6 +994,24 @@ omp_max_simt_vf (void)
   return 0;
 }
 
+/* Return maximum SIMD width if offloading may target SIMD hardware.  */
+
+int
+omp_max_simd_vf (void)
+{
+  if (!optimize)
+return 0;
+  if (ENABLE_OFFLOADING)
+for (const char *c = getenv ("OFFLOAD_TARGET_NAMES"); c;)
+  {
+   if (startswith (c, "amdgcn"))
+ return 64;
+   else if ((c = strchr (c, ':')))
+ c++;
+  }
+  return 0;
+}
+
 /* Store the construct selectors as tree codes from last to first,
return their number.  */
 
diff --git a/gcc/omp-general.h b/gcc/omp-general.h
index 74e90e1a71a..410343e45fa 100644
--- a/gcc/omp-general.h
+++ b/gcc/omp-general.h
@@ -104,6 +104,7 @@ extern gimple *omp_build_barrier (tree lhs);
 extern tree find_combined_omp_for (tree *, int *, void *);
 extern poly_uint64 omp_max_vf (void);
 extern int omp_max_simt_vf (void);
+extern int omp_max_simd_vf (void);
 extern int omp_constructor_traits_to_codes (tree, enum tree_code *);
 extern tree omp_check_context_selector (location_t loc, tree ctx);
 extern void omp_mark_declare_variant (location_t loc, tree variant,
diff --git a/gcc/omp-low.cc b/gcc/omp-low.cc
index d73c165f029..1a9a509adb9 100644
--- a/gcc/omp-low.cc
+++ b/gcc/omp-low.cc
@@ -4646,7 +4646,14 @@ lowe

[PATCH v2 1/2] aarch64: Don't return invalid GIMPLE assign statements

[Andrew Carlotti via Gcc-patches]

aarch64_general_gimple_fold_builtin doesn't check whether the LHS of a
function call is null before converting it to an assign statement. To avoid
returning an invalid GIMPLE statement in this case, we instead assign the
expression result to a new (unused) variable.

This change only affects code that:
1) Calls an intrinsic function that has no side effects;
2) Does not use or store the value returned by the intrinsic;
3) Uses parameters that prevent the front-end eliminating the call prior to
gimplification.

The ICE is unlikely to have occurred in the wild, as it relies on the presence
of a redundant intrinsic call.

gcc/ChangeLog:

 * config/aarch64/aarch64-builtins.cc
 (aarch64_general_gimple_fold_builtin): Add fixup for invalid GIMPLE.

gcc/testsuite/ChangeLog:

 * gcc.target/aarch64/advsimd-intrinsics/ignored_return_1.c: New test.

---

diff --git a/gcc/config/aarch64/aarch64-builtins.cc 
b/gcc/config/aarch64/aarch64-builtins.cc
index 
e0a741ac663188713e21f457affa57217d074783..5753988a9964967c27a03aca5fddb9025fd8ed6e
 100644
--- a/gcc/config/aarch64/aarch64-builtins.cc
+++ b/gcc/config/aarch64/aarch64-builtins.cc
@@ -3022,6 +3022,16 @@ aarch64_general_gimple_fold_builtin (unsigned int fcode, 
gcall *stmt,
 default:
   break;
 }
+
+  /* GIMPLE assign statements (unlike calls) require a non-null lhs. If we
+ created an assign statement with a null lhs, then fix this by assigning
+ to a new (and subsequently unused) variable. */
+  if (new_stmt && is_gimple_assign (new_stmt) && !gimple_assign_lhs (new_stmt))
+{
+  tree new_lhs = make_ssa_name (gimple_call_return_type (stmt));
+  gimple_assign_set_lhs (new_stmt, new_lhs);
+}
+
   return new_stmt;
 }
 
diff --git 
a/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/ignored_return_1.c 
b/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/ignored_return_1.c
new file mode 100644
index 
..345307456b175307f5cb22de5e59cfc6254f2737
--- /dev/null
+++ b/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/ignored_return_1.c
@@ -0,0 +1,9 @@
+/* { dg-do compile { target { aarch64*-*-* } } } */
+
+#include 
+
+int8_t *bar();
+
+void foo() {
+  __builtin_aarch64_ld1v16qi(bar());
+}

[COMMITTED] Set nonzero bits from bitwise and operator in range-ops.

[Aldy Hernandez via Gcc-patches]

Now that nonzero bits are first class citizens in the range, we can
keep better track of them in range-ops, especially the bitwise and
operator.

This patch sets the nonzero mask for the trivial case.  In doing so,
I've removed some old dead code that was an attempt to keep better
track of masks.

I'm sure there are tons of optimizations throughout range-ops that
could be implemented, especially the op1_range methods, but those
always make my head hurt.  I'll leave them to the smarter hackers
out there.

I've removed the restriction that nonzero bits can't be queried from
legacy.  This was causing special casing all over the place, and
it's not like we can generate incorrect code.  We just silently
drop nonzero bits to -1 in some of the legacy code.  The end result
is that VRP1, and other users of legacy, may not benefit from these
improvements.

Tested and benchmarked on x86-64 Linux.

gcc/ChangeLog:

* range-op.cc (unsigned_singleton_p): Remove.
(operator_bitwise_and::remove_impossible_ranges): Remove.
(operator_bitwise_and::fold_range): Set nonzero bits.  *
* value-range.cc (irange::get_nonzero_bits): Remove
legacy_mode_p assert.
(irange::dump_bitmasks): Remove legacy_mode_p check.
---
 gcc/range-op.cc| 70 ++
 gcc/value-range.cc |  6 +---
 2 files changed, 4 insertions(+), 72 deletions(-)

diff --git a/gcc/range-op.cc b/gcc/range-op.cc
index 5150c6021b8..0e16408027c 100644
--- a/gcc/range-op.cc
+++ b/gcc/range-op.cc
@@ -2604,72 +2604,8 @@ private:
   void simple_op1_range_solver (irange &r, tree type,
const irange &lhs,
const irange &op2) const;
-  void remove_impossible_ranges (irange &r, const irange &rh) const;
 } op_bitwise_and;
 
-static bool
-unsigned_singleton_p (const irange &op)
-{
-  tree mask;
-  if (op.singleton_p (&mask))
-{
-  wide_int x = wi::to_wide (mask);
-  return wi::ge_p (x, 0, TYPE_SIGN (op.type ()));
-}
-  return false;
-}
-
-// Remove any ranges from R that are known to be impossible when an
-// range is ANDed with MASK.
-
-void
-operator_bitwise_and::remove_impossible_ranges (irange &r,
-   const irange &rmask) const
-{
-  if (r.undefined_p () || !unsigned_singleton_p (rmask))
-return;
-
-  wide_int mask = rmask.lower_bound ();
-  tree type = r.type ();
-  int prec = TYPE_PRECISION (type);
-  int leading_zeros = wi::clz (mask);
-  int_range_max impossible_ranges;
-
-  /* We know that starting at the most significant bit, any 0 in the
- mask means the resulting range cannot contain a 1 in that same
- position.  This means the following ranges are impossible:
-
-   x & 0b1001 1010
- IMPOSSIBLE RANGES
- 01xx    [0100 , 0111 ]
- 001x    [0010 , 0011 ]
-  01xx   [ 0100,  0111]
-  0001   [ 0001,  0001]
-  */
-  wide_int one = wi::one (prec);
-  for (int i = 0; i < prec - leading_zeros - 1; ++i)
-if (wi::bit_and (mask, wi::lshift (one, wi::uhwi (i, prec))) == 0)
-  {
-   tree lb = fold_build2 (LSHIFT_EXPR, type,
-  build_one_cst (type),
-  build_int_cst (type, i));
-   tree ub_left = fold_build1 (BIT_NOT_EXPR, type,
-   fold_build2 (LSHIFT_EXPR, type,
-build_minus_one_cst (type),
-build_int_cst (type, i)));
-   tree ub_right = fold_build2 (LSHIFT_EXPR, type,
-build_one_cst (type),
-build_int_cst (type, i));
-   tree ub = fold_build2 (BIT_IOR_EXPR, type, ub_left, ub_right);
-   impossible_ranges.union_ (int_range<1> (lb, ub));
-  }
-  if (!impossible_ranges.undefined_p ())
-{
-  impossible_ranges.invert ();
-  r.intersect (impossible_ranges);
-}
-}
-
 bool
 operator_bitwise_and::fold_range (irange &r, tree type,
  const irange &lh,
@@ -2678,9 +2614,9 @@ operator_bitwise_and::fold_range (irange &r, tree type,
 {
   if (range_operator::fold_range (r, type, lh, rh))
 {
-  // FIXME: This is temporarily disabled because, though it
-  // generates better ranges, it's noticeably slower for evrp.
-  // remove_impossible_ranges (r, rh);
+  if (!lh.undefined_p () && !rh.undefined_p ())
+   r.set_nonzero_bits (wi::bit_and (lh.get_nonzero_bits (),
+rh.get_nonzero_bits ()));
   return true;
 }
   return false;
diff --git a/gcc/value-range.cc b/gcc/value-range.cc
index a02fab47fc4..2aa973b2af2 100644
--- a/gcc/value-range.cc
+++ b/gcc/value-range.cc
@@ -2388,10 +2388,6 @@ wide_int
 irange::get_nonzero_bits () const
 {
   gcc_checking_assert (!undefine

[PATCH v2 2/2] aarch64: Lower vcombine to GIMPLE

[Andrew Carlotti via Gcc-patches]

This lowers vcombine intrinsics to a GIMPLE vector constructor, which enables
better optimisation during GIMPLE passes.

gcc/

* config/aarch64/aarch64-builtins.c
(aarch64_general_gimple_fold_builtin): Add combine.

gcc/testsuite/

* gcc.target/aarch64/advsimd-intrinsics/combine.c:
New test.

diff --git a/gcc/config/aarch64/aarch64-builtins.cc 
b/gcc/config/aarch64/aarch64-builtins.cc
index 
5753988a9964967c27a03aca5fddb9025fd8ed6e..a25756cfed5fab3a98ebf3e2ee29a5e117cbd2aa
 100644
--- a/gcc/config/aarch64/aarch64-builtins.cc
+++ b/gcc/config/aarch64/aarch64-builtins.cc
@@ -2857,6 +2857,28 @@ aarch64_general_gimple_fold_builtin (unsigned int fcode, 
gcall *stmt,
gimple_call_set_lhs (new_stmt, gimple_call_lhs (stmt));
break;
 
+ BUILTIN_VDC (BINOP, combine, 0, AUTO_FP)
+ BUILTIN_VD_I (BINOPU, combine, 0, NONE)
+ BUILTIN_VDC_P (BINOPP, combine, 0, NONE)
+   {
+ tree first_part, second_part;
+ if (BYTES_BIG_ENDIAN)
+   {
+ second_part = args[0];
+ first_part = args[1];
+   }
+ else
+   {
+ first_part = args[0];
+ second_part = args[1];
+   }
+ tree ret_type = TREE_TYPE (gimple_call_lhs (stmt));
+ tree ctor = build_constructor_va (ret_type, 2, NULL_TREE, first_part,
+   NULL_TREE, second_part);
+ new_stmt = gimple_build_assign (gimple_call_lhs (stmt), ctor);
+   }
+   break;
+
  /*lower store and load neon builtins to gimple.  */
  BUILTIN_VALL_F16 (LOAD1, ld1, 0, LOAD)
  BUILTIN_VDQ_I (LOAD1_U, ld1, 0, LOAD)
diff --git a/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/combine.c 
b/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/combine.c
new file mode 100644
index 
..d08faf7a4a160a1e83428ed9b270731bbf7b8c8a
--- /dev/null
+++ b/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/combine.c
@@ -0,0 +1,18 @@
+/* { dg-do compile { target { aarch64*-*-* } } } */
+/* { dg-final { check-function-bodies "**" "" {-O[^0]} } } */
+/* { dg-skip-if "" { *-*-* } { "-fno-fat-lto-objects" } } */
+
+#include 
+
+/*
+** foo:
+** umovw0, v1\.s\[1\]
+** ret
+*/
+
+int32_t foo (int32x2_t a, int32x2_t b)
+{
+  int32x4_t c = vcombine_s32(a, b);
+  return vgetq_lane_s32(c, 3);
+}
+

Re: [PATCH] btf: emit linkage information in BTF_KIND_FUNC entries

[Jose E. Marchesi via Gcc-patches]

> On 7/8/22 11:30 AM, Jose E. Marchesi via Gcc-patches wrote:
>> 
>> The kernel bpftool expects BTF_KIND_FUNC entries in BTF to include an
>> annotation reflecting the linkage of functions (static, global).  For
>> whatever reason they (ab)use the `vlen' field of the BTF_KIND_FUNC entry
>> instead of adding a variable-part to the record like it is done with
>> other entry kinds.
>> 
>
> For BTF Variables, we have the linkage information in the output
> section as "btv_linkage".  To propagate that information from DWARF to
> BTF, we have the dvd_visibility in struct ctf_dvdef (in ctfc.h). Now
> that the linkage information is needed for the BTF_KIND_FUNC entries,
> what do you think about - adding something like dtd_visibility to
> ctf_dtdef.
>
> Updating the BTF format documentation will be useful
> https://www.kernel.org/doc/Documentation/bpf/btf.rst. Let's see what
> can be done for that...
>
> Also, adding some testcases with the current patch will be great.
>
> I have created PR debug/106263 "BTF_KIND_FUNC type does not encode
> linkage" to track this.

Sending V2 with the requested changes.

[PATCH V2] btf: emit linkage information in BTF_KIND_FUNC entries

[Jose E. Marchesi via Gcc-patches]

The kernel bpftool expects BTF_KIND_FUNC entries in BTF to include an
annotation reflecting the linkage of functions (static, global).  For
whatever reason they abuse the `vlen' field of the BTF_KIND_FUNC entry
instead of adding a variable-part to the record like it is done with
other entry kinds.

This patch makes GCC to include this linkage info in BTF_KIND_FUNC
entries.

Tested in bpf-unknown-none target.

gcc/ChangeLog:

PR debug/106263
* ctfc.h (struct ctf_dtdef): Add field linkage.
* ctfc.cc (ctf_add_function): Set ctti_linkage.
* dwarf2ctf.cc (gen_ctf_function_type): Pass a linkage for
function types and subprograms.
* btfout.cc (btf_asm_func_type): Emit linkage information for the
function.
(btf_dtd_emit_preprocess_cb): Propagate the linkage information
for functions.

gcc/testsuite/ChangeLog:

PR debug/106263
* gcc.dg/debug/btf/btf-function-4.c: New test.
* gcc.dg/debug/btf/btf-function-5.c: Likewise.
---
 gcc/btfout.cc   |  6 +-
 gcc/ctfc.cc |  3 ++-
 gcc/ctfc.h  |  3 ++-
 gcc/dwarf2ctf.cc|  4 +++-
 gcc/testsuite/gcc.dg/debug/btf/btf-function-4.c | 14 ++
 gcc/testsuite/gcc.dg/debug/btf/btf-function-5.c | 14 ++
 6 files changed, 40 insertions(+), 4 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/debug/btf/btf-function-4.c
 create mode 100644 gcc/testsuite/gcc.dg/debug/btf/btf-function-5.c

diff --git a/gcc/btfout.cc b/gcc/btfout.cc
index 31af50521da..594cba84910 100644
--- a/gcc/btfout.cc
+++ b/gcc/btfout.cc
@@ -463,6 +463,7 @@ btf_dtd_emit_preprocess_cb (ctf_container_ref ctfc, 
ctf_dtdef_ref dtd)
   ctf_dtdef_ref func_dtd = ggc_cleared_alloc ();
   func_dtd->dtd_data = dtd->dtd_data;
   func_dtd->dtd_data.ctti_type = dtd->dtd_type;
+  func_dtd->linkage = dtd->linkage;
 
   vec_safe_push (funcs, func_dtd);
   num_types_created++;
@@ -740,7 +741,10 @@ static void
 btf_asm_func_type (ctf_dtdef_ref dtd)
 {
   dw2_asm_output_data (4, dtd->dtd_data.ctti_name, "btt_name");
-  dw2_asm_output_data (4, BTF_TYPE_INFO (BTF_KIND_FUNC, 0, 0), "btt_info");
+  dw2_asm_output_data (4, BTF_TYPE_INFO (BTF_KIND_FUNC, 0,
+ dtd->linkage),
+   "btt_info: kind=%u, kflag=%u, linkage=%u",
+   BTF_KIND_FUNC, 0, dtd->linkage);
   dw2_asm_output_data (4, get_btf_id (dtd->dtd_data.ctti_type), "btt_type");
 }
 
diff --git a/gcc/ctfc.cc b/gcc/ctfc.cc
index f24e7bff948..9773358a475 100644
--- a/gcc/ctfc.cc
+++ b/gcc/ctfc.cc
@@ -777,7 +777,7 @@ ctf_add_function_arg (ctf_container_ref ctfc, dw_die_ref 
func,
 ctf_id_t
 ctf_add_function (ctf_container_ref ctfc, uint32_t flag, const char * name,
  const ctf_funcinfo_t * ctc, dw_die_ref die,
- bool from_global_func)
+ bool from_global_func, int linkage)
 {
   ctf_dtdef_ref dtd;
   ctf_id_t type;
@@ -791,6 +791,7 @@ ctf_add_function (ctf_container_ref ctfc, uint32_t flag, 
const char * name,
   type = ctf_add_generic (ctfc, flag, name, &dtd, die);
 
   dtd->from_global_func = from_global_func;
+  dtd->linkage = linkage;
   dtd->dtd_data.ctti_info = CTF_TYPE_INFO (CTF_K_FUNCTION, flag, vlen);
   /* Caller must make sure CTF types for ctc->ctc_return are already added.  */
   dtd->dtd_data.ctti_type = (uint32_t) ctc->ctc_return;
diff --git a/gcc/ctfc.h b/gcc/ctfc.h
index 001e544ef08..bcf3a43ae1b 100644
--- a/gcc/ctfc.h
+++ b/gcc/ctfc.h
@@ -161,6 +161,7 @@ struct GTY ((for_user)) ctf_dtdef
   ctf_itype_t dtd_data;  /* Type node.  */
   bool from_global_func; /* Whether this type was added from a global
function.  */
+  uint32_t linkage;   /* Used in function types.  0=local, 1=global.  
*/
   union GTY ((desc ("ctf_dtu_d_union_selector (&%1)")))
   {
 /* struct, union, or enum.  */
@@ -423,7 +424,7 @@ extern ctf_id_t ctf_add_forward (ctf_container_ref, 
uint32_t, const char *,
 extern ctf_id_t ctf_add_typedef (ctf_container_ref, uint32_t, const char *,
 ctf_id_t, dw_die_ref);
 extern ctf_id_t ctf_add_function (ctf_container_ref, uint32_t, const char *,
- const ctf_funcinfo_t *, dw_die_ref, bool);
+ const ctf_funcinfo_t *, dw_die_ref, bool, 
int);
 extern ctf_id_t ctf_add_sou (ctf_container_ref, uint32_t, const char *,
 uint32_t, size_t, dw_die_ref);
 
diff --git a/gcc/dwarf2ctf.cc b/gcc/dwarf2ctf.cc
index a6329ab6ee4..39714c2 100644
--- a/gcc/dwarf2ctf.cc
+++ b/gcc/dwarf2ctf.cc
@@ -644,6 +644,7 @@ gen_ctf_function_type (ctf_container_ref ctfc, dw_die_ref 
function,
 
   ctf_funcinfo_t func_info;
   uint32_t num_args = 0;
+  int linkage = get_AT_flag (function, DW_AT_external);
 
   ctf_id_t return_

Re: [PATCH 1/2] Add gcc/make-unique.h

[Jonathan Wakely via Gcc-patches]

On Tue, 12 Jul 2022 at 15:06, Pedro Alves  wrote:
>
> On 2022-07-12 2:45 p.m., Jonathan Wakely wrote:
> > On Tue, 12 Jul 2022 at 14:24, Pedro Alves wrote:
> >>
> >> On 2022-07-12 1:25 a.m., David Malcolm via Gcc-patches wrote:
> >>
> >>> I tried adding it to gcc/system.h, but anything that uses it needs to
> >>> have std::unique_ptr declared, which meant forcibly including 
> >>> from gcc/system.h
> >>
> >> Did you consider making gcc/system.h include gcc/make-unique.h itself
> >> if INCLUDE_MEMORY is defined?  Something like:
> >>
> >>  #ifdef INCLUDE_MEMORY
> >>  # include 
> >> + #include "make-unique.h"
> >>  #endif
> >>
> >> This is because std::make_unique is defined in  in C++14.  This 
> >> would
> >> mean fewer changes once GCC requires C++14 (or later) and this new header 
> >> is eliminated.
> >
> > That's a good idea.
> >
> >>> (in the root namespace, rather than std::, which saves a bit more typing).
> >>
> >> It's less typing now, but it will be more churn once GCC requires C++14 
> >> (or later), at
> >> which point you'll naturally want to get rid of the custom make_unique.  
> >> More churn
> >> since make_unique -> std::make_unique may require re-indentation of 
> >> arguments, etc.
> >> For that reason, I would suggest instead to put the function (and any 
> >> other straight
> >> standard library backport) in a 3-letter namespace already, like, 
> >> gcc::make_unique
> >> or gnu::make_unique.  That way, when the time comes that GCC requires 
> >> C++14,
> >> the patch to replace gcc::make_unique won't have to worry about 
> >> reindenting code,
> >> it'll just replace gcc -> std.
> >
> > Or (when the time comes) don't change gcc->std and do:
> >
> > namespace gcc {
> >   using std::make_unique;
> > }
>
> It will seem like a pointless indirection then, IMO.
>
> >
> > or just leave it in the global namespace as in your current patch, and
> > at a later date add a using-declaration to the global namespace:
> >
> > using std::make_unique;
> >
>
> That's not very idiomatic, though.  Let me turn this into a reverse question:
>
> If GCC required C++14 today, would you be doing the above, either importing 
> make_unique
> to the global namespace, or into namespace gcc?   I think it's safe to say 
> that, no,
> nobody would be doing that.

Erm, I might well do exactly that, for either case.

I don't see a problem with 'using std::make_unique;' into the global
namespace in GCC code. It's not a library header being included by
arbitrary code, it's a single application that isn't going to have
conflicts for some other ::make_unique defined in GCC (because the
::make_unique that is being proposed today would be removed once
C++14's std::make_unique can be used).


>  So once GCC requires C++14, why would you want to preserve
> once-backported symbols in a namespace other than std, when you no longer 
> have a reason to?
> It will just be another unnecessary thing that newcomers at that future time 
> will have
> to learn.

I also don't see a problem with importing std::make_unique into
namespace gcc for local use alongside other things in namespace gcc. I
do consider that idiomatic. It says "the make_unique for gcc code is
std::make_unique". It means you only need a 'using namespace gcc;' at
the top of a source file and you get access to everything in namespace
gcc, even if it is something like std::make_unique that was originally
defined in a different namespace.

Re: [PATCH] c++: coroutines - Overlap variables in frame [PR105989]

[Michal Jankovič via Gcc-patches]

Hi Iain,

Thanks for the reply, this is my first time contributing and I am
looking forward to your input.

One other related thing I would like to investigate is reducing the
number of compiler generated variables in the frame, particularly
_Coro_destroy_fn and _Coro_self_handle.  

As I understand it, _Coro_destroy_fn just sets a flag in
_Coro_resume_index and calls _Coro_resume_fn; it should be possible to
move this logic to __builtin_coro_destroy, so that only _Coro_resume_fn
is stored in the frame; this would however change the coroutine ABI - I
don't know if that's a problem.

The _Coro_self_handle should be constructible on-demand from the frame address.

Do you have any advice / opinions on this before I try to implement it?

Michal

On Jul 12 2022, at 4:08 pm, Iain Sandoe  wrote:

> Hi Michal,
>  
>> On 12 Jul 2022, at 14:35, Michal Jankovič via Gcc-patches
>>  wrote:
>>  
>> Currently, coroutine frames store all variables of a coroutine separately,
>> even if their lifetime does not overlap (they are in distinct
>> scopes). This
>> patch implements overlapping distinct variable scopes in the
>> coroutine frame,
>> by storing the frame fields in nested unions of structs. This lowers
>> the size
>> of the frame for larger coroutines significantly, and makes them more usable
>> on systems with limited memory.
>  
> not a review (I will try to take a look at the weekend).
>  
> but … this is one of the two main optimisations on my TODO - so cool
> for doing it.
>  
> (the other related optimisation is to eliminate frame entries for
> scopes without any suspend
> points - which has the potential to save even more space for code with
> sparse use of co_)
>  
> Iain
>  
>> Bootstrapped and regression tested on x86_64-pc-linux-gnu; new test fails
>> before the patch and succeeds after with no regressions.
>>  
>>  PR c++/105989
>>  
>> gcc/cp/ChangeLog:
>>  
>>  * coroutines.cc (struct local_var_info): Add field_access_path.
>>  (build_local_var_frame_access_expr): New.
>>  (transform_local_var_uses): Use build_local_var_frame_access_expr.
>>  (coro_make_frame_entry_id): New.
>>  (coro_make_frame_entry): Delegate to coro_make_frame_entry_id.
>>  (struct local_vars_frame_data): Add orig, field_access_path.
>>  (register_local_var_uses): Generate new frame layout. Create access
>>  paths to vars.
>>  (morph_fn_to_coro): Set new fields in local_vars_frame_data.  
>>  
>> gcc/testsuite/ChangeLog:
>>  
>>  * g++.dg/coroutines/pr105989.C: New test.
>>  
>> 
>  
>

[PATCH 5/12 V2] arm: Implement target feature macros for PACBTI

[Andrea Corallo via Gcc-patches]

Richard Earnshaw  writes:

> On 28/04/2022 10:42, Andrea Corallo via Gcc-patches wrote:
>> This patch implements target feature macros when PACBTI is enabled
>> through the -march option or -mbranch-protection.  The target feature
>> macros __ARM_FEATURE_PAC_DEFAULT and __ARM_FEATURE_BTI_DEFAULT are
>> specified in ARM ACLE
>> 
>> __ARM_FEATURE_PAUTH and __ARM_FEATURE_BTI are specified in the
>> pull-request .
>> Approved here
>> .
>> gcc/ChangeLog:
>>  * config/arm/arm-c.c (arm_cpu_builtins): Define
>>  __ARM_FEATURE_BTI_DEFAULT, __ARM_FEATURE_PAC_DEFAULT,
>>  __ARM_FEATURE_PAUTH and __ARM_FEATURE_BTI.
>
> This bit is OK.
>
>> gcc/testsuite/ChangeLog:
>>  * gcc.target/arm/acle/pacbti-m-predef-2.c: New test.
>>  * gcc.target/arm/acle/pacbti-m-predef-4.c: New test.
>>  * gcc.target/arm/acle/pacbti-m-predef-5.c: New test.
>> 
>
> These are all execution tests.  I think we also need some compile-only
> tests so that we get better coverage when the target does not directly
> support PACBTI.
>
> We also need some tests for the defines when targetting armv8-m.main
> and some tests for checking __ARM_FEATURE_BTI and __ARM_FEATURE_PAC
> (the tests here check only the '..._DEFAULT' macros.

Hi Richard & all,

please find attached the updated version of this patch.

Best Regards

  Andrea

gcc/ChangeLog:

* config/arm/arm-c.c (arm_cpu_builtins): Define
__ARM_FEATURE_BTI_DEFAULT, __ARM_FEATURE_PAC_DEFAULT,
__ARM_FEATURE_PAUTH and __ARM_FEATURE_BTI.

gcc/testsuite/ChangeLog:

* gcc.target/arm/acle/pacbti-m-predef-2.c: New test.
* gcc.target/arm/acle/pacbti-m-predef-4.c: Likewise.
* gcc.target/arm/acle/pacbti-m-predef-5.c: Likewise.
* gcc.target/arm/acle/pacbti-m-predef-8.c: Likewise.
* gcc.target/arm/acle/pacbti-m-predef-9.c: Likewise.
* gcc.target/arm/acle/pacbti-m-predef-10.c: Likewise.
* gcc.target/arm/acle/pacbti-m-predef-11.c: Likewise.
* gcc.target/arm/acle/pacbti-m-predef-12.c: Likewise.

>From d1897ca2db828d214a6591ab34f29cf42ebd2fb6 Mon Sep 17 00:00:00 2001
From: Andrea Corallo 
Date: Mon, 6 Dec 2021 11:39:59 +0100
Subject: [PATCH] [PATCH 5/12] arm: Implement target feature macros for PACBTI

This patch implements target feature macros when PACBTI is enabled
through the -march option or -mbranch-protection.  The target feature
macros __ARM_FEATURE_PAC_DEFAULT and __ARM_FEATURE_BTI_DEFAULT are
specified in ARM ACLE

__ARM_FEATURE_PAUTH and __ARM_FEATURE_BTI are specified in the
pull-request .

Approved here
.

gcc/ChangeLog:

* config/arm/arm-c.c (arm_cpu_builtins): Define
__ARM_FEATURE_BTI_DEFAULT, __ARM_FEATURE_PAC_DEFAULT,
__ARM_FEATURE_PAUTH and __ARM_FEATURE_BTI.

gcc/testsuite/ChangeLog:

* gcc.target/arm/acle/pacbti-m-predef-2.c: New test.
* gcc.target/arm/acle/pacbti-m-predef-4.c: Likewise.
* gcc.target/arm/acle/pacbti-m-predef-5.c: Likewise.
* gcc.target/arm/acle/pacbti-m-predef-8.c: Likewise.
* gcc.target/arm/acle/pacbti-m-predef-9.c: Likewise.
* gcc.target/arm/acle/pacbti-m-predef-10.c: Likewise.
* gcc.target/arm/acle/pacbti-m-predef-11.c: Likewise.
* gcc.target/arm/acle/pacbti-m-predef-12.c: Likewise.

Co-Authored-By: Tejas Belagod  
---
 gcc/config/arm/arm-c.cc   | 18 ++
 .../gcc.target/arm/acle/pacbti-m-predef-10.c  | 10 
 .../gcc.target/arm/acle/pacbti-m-predef-11.c  | 10 
 .../gcc.target/arm/acle/pacbti-m-predef-12.c  | 10 
 .../gcc.target/arm/acle/pacbti-m-predef-2.c   | 24 +++
 .../gcc.target/arm/acle/pacbti-m-predef-4.c   | 21 
 .../gcc.target/arm/acle/pacbti-m-predef-5.c   | 24 +++
 .../gcc.target/arm/acle/pacbti-m-predef-8.c   | 11 +
 .../gcc.target/arm/acle/pacbti-m-predef-9.c   | 10 
 9 files changed, 138 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/arm/acle/pacbti-m-predef-10.c
 create mode 100644 gcc/testsuite/gcc.target/arm/acle/pacbti-m-predef-11.c
 create mode 100644 gcc/testsuite/gcc.target/arm/acle/pacbti-m-predef-12.c
 create mode 100644 gcc/testsuite/gcc.target/arm/acle/pacbti-m-predef-2.c
 create mode 100644 gcc/testsuite/gcc.target/arm/acle/pacbti-m-predef-4.c
 create mode 100644 gcc/testsuite/gcc.target/arm/acle/pacbti-m-predef-5.c
 create mode 100644 gcc/testsuite/gcc.target/arm/acle/pacbti-m-predef-8.c
 create mode 100644 gcc/testsuite/gcc.target/arm/acle/pacbti-m-predef-9.c

diff --git a/gcc/config/arm/arm-c.cc b/gcc/config/arm/arm-c.cc
index a8697b8c62f.

Re: [PATCH] c++: non-dependent call to consteval operator [PR105912]

[Jason Merrill via Gcc-patches]

On 7/11/22 21:27, Patrick Palka wrote:

Here we were crashing when substituting a non-dependent call to a
consteval operator, whose CALL_EXPR_OPERATOR_SYNTAX flag we try to
propagate to the result, but the result isn't a CALL_EXPR since the
called function is consteval.  This patch fixes this by checking the
result of extract_call_expr accordingly.  (Note that we can't easily
check DECL_IMMEDIATE_FUNCTION_P here because we don't know which
function was selected by overload resolution from this call frame.)

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

PR c++/105912

gcc/cp/ChangeLog:

* pt.cc (tsubst_copy_and_build) : Guard against
NULL_TREE extract_call_expr result.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/consteval31.C: New test.
---
  gcc/cp/pt.cc | 10 +
  gcc/testsuite/g++.dg/cpp2a/consteval31.C | 26 
  2 files changed, 32 insertions(+), 4 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/cpp2a/consteval31.C

diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
index 232964c2831..8a6ae5c42fe 100644
--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -21207,10 +21207,12 @@ tsubst_copy_and_build (tree t,
bool rev = CALL_EXPR_REVERSE_ARGS (t);
if (op || ord || rev)
  {


I'd drop this pair of braces.  OK either way.


-   function = extract_call_expr (ret);
-   CALL_EXPR_OPERATOR_SYNTAX (function) = op;
-   CALL_EXPR_ORDERED_ARGS (function) = ord;
-   CALL_EXPR_REVERSE_ARGS (function) = rev;
+   if (tree call = extract_call_expr (ret))
+ {
+   CALL_EXPR_OPERATOR_SYNTAX (call) = op;
+   CALL_EXPR_ORDERED_ARGS (call) = ord;
+   CALL_EXPR_REVERSE_ARGS (call) = rev;
+ }
  }
  }
  
diff --git a/gcc/testsuite/g++.dg/cpp2a/consteval31.C b/gcc/testsuite/g++.dg/cpp2a/consteval31.C

new file mode 100644
index 000..85a4d1794e5
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/consteval31.C
@@ -0,0 +1,26 @@
+// PR c++/105912
+// { dg-do compile { target c++20 } }
+
+struct A {
+  consteval A operator+() {
+return {};
+  }
+};
+
+consteval A operator~(A) {
+  return {};
+}
+
+consteval A operator+(A, A) {
+  return {};
+}
+
+template
+void f() {
+  A a;
+  ~a;
+  a + a;
+  +a;
+}
+
+template void f();

Re: [PATCH] c++: dependence of constrained memfn from current inst [PR105842]

[Jason Merrill via Gcc-patches]

On 7/11/22 09:33, Patrick Palka wrote:

Here we incorrectly deem the calls to func1, func2 and tmpl2 as
ambiguous ahead of time ultimately because we mishandle dependence
of a constrained member function from the current instantiation.

In type_dependent_expression_p, we consider the dependence of a
TEMPLATE_DECL's constraints (via uses_outer_template_parms), but
neglect to do the same for a FUNCTION_DECL such as func1.

And in satisfy_declaration_constraints, we give up if _any_ template
argument is dependent, but for non-dependent member functions from
the current instantiation such as func2 and tmpl2, we can and must
check constraints as long as the innermost arguments aren't dependent.

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

PR c++/105842

gcc/cp/ChangeLog:

* constraint.cc (satisfy_declaration_constraints): Refine
early exit test for argument dependence.
* cp-tree.h (uses_outer_template_parms_in_constraints): Declare.
* pt.cc (template_class_depth): Handle TI_TEMPLATE being a
FIELD_DECL.
(usse_outer_template_parms): Factor out constraint dependence
check to ...
(uses_outer_template_parms_in_constraints): ... here.
(type_dependent_expression_p): Use it for FUNCTION_DECL.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/concepts-memtmpl6.C: New test.
---
  gcc/cp/constraint.cc  | 20 +++
  gcc/cp/cp-tree.h  |  1 +
  gcc/cp/pt.cc  | 34 ---
  .../g++.dg/cpp2a/concepts-memtmpl6.C  | 34 +++
  4 files changed, 79 insertions(+), 10 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-memtmpl6.C

diff --git a/gcc/cp/constraint.cc b/gcc/cp/constraint.cc
index 591155cee22..99b97d24eae 100644
--- a/gcc/cp/constraint.cc
+++ b/gcc/cp/constraint.cc
@@ -3176,9 +3176,13 @@ satisfy_declaration_constraints (tree t, sat_info info)
args = regen_args;
  }
  
-  /* If any arguments depend on template parameters, we can't

- check constraints. Pretend they're satisfied for now.  */
-  if (uses_template_parms (args))
+  /* If the innermost arguments are dependent, or if the outer arguments
+ are dependent and are needed by the constraints, we can't check
+ satisfaction yet so pretend they're satisfied for now.  */
+  if (uses_template_parms (args)
+  && (TMPL_ARGS_DEPTH (args) == 1
+ || uses_template_parms (INNERMOST_TEMPLATE_ARGS (args))
+ || uses_outer_template_parms_in_constraints (t)))
  return boolean_true_node;
  
/* Get the normalized constraints.  */

@@ -3240,9 +3244,13 @@ satisfy_declaration_constraints (tree t, tree args, 
sat_info info)
else
  args = add_outermost_template_args (t, args);
  
-  /* If any arguments depend on template parameters, we can't

- check constraints. Pretend they're satisfied for now.  */
-  if (uses_template_parms (args))
+  /* If the innermost arguments are dependent, or if the outer arguments
+ are dependent and are needed by the constraints, we can't check
+ satisfaction yet so pretend they're satisfied for now.  */
+  if (uses_template_parms (args)
+  && (TMPL_ARGS_DEPTH (args) == 1
+ || uses_template_parms (INNERMOST_TEMPLATE_ARGS (args))
+ || uses_outer_template_parms_in_constraints (t)))
  return boolean_true_node;
  
tree result = boolean_true_node;

diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index 2fde4f83b41..bec98aa2ac3 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -7297,6 +7297,7 @@ extern tree lookup_template_function  (tree, 
tree);
  extern tree lookup_template_variable  (tree, tree);
  extern bool uses_template_parms   (tree);
  extern bool uses_template_parms_level (tree, int);
+extern bool uses_outer_template_parms_in_constraints (tree);
  extern bool in_template_function  (void);
  extern bool need_generic_capture  (void);
  extern tree instantiate_class_template(tree);
diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
index 59ee50c152d..de5d3a5cd78 100644
--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -391,7 +391,9 @@ template_class_depth (tree type)
  {
tree tinfo = get_template_info (type);
  
-  if (tinfo && PRIMARY_TEMPLATE_P (TI_TEMPLATE (tinfo))

+  if (tinfo
+ && TREE_CODE (TI_TEMPLATE (tinfo)) == TEMPLATE_DECL
+ && PRIMARY_TEMPLATE_P (TI_TEMPLATE (tinfo))
  && uses_template_parms (INNERMOST_TEMPLATE_ARGS (TI_ARGS (tinfo
++depth;
  
@@ -11011,7 +11013,7 @@ uses_template_parms_level (tree t, int level)

  /* Returns true if the signature of DECL depends on any template parameter 
from
 its enclosing class.  */
  
-bool

+static bool
  uses_outer_template_parms (tree decl)
  {
int depth = template_class_depth (CP_DECL_CONTEXT (decl));
@@ -11042,11 +11044,27 @@ uses_

Re: [PATCH] i386 testsuite: cope with --enable-default-pie

[Alexandre Oliva via Gcc-patches]

On Jul 11, 2022, Mike Stump  wrote:

> Ok.

>> PS: There's at least one additional FAIL with --enable-default-pie in
>> the trunk, namely gcc.target/i386/mvc7.c

>> WDYT?

> Seems reasonable.

Thanks, here's what I installed.


i386 testsuite: cope with --enable-default-pie

Running the testsuite on a toolchain build with --enable-default-pie
had some unexpected fails.  Adjust the tests to tolerate the effects
of this configuration option on x86_64-linux-gnu and i686-linux-gnu.

The cet-sjlj* tests get offsets before the base symbol name with PIC
or PIE.  A single pattern covering both alternatives somehow triggered
two matches rather than the single expected match, thus my narrowing
the '.*' to not skip line breaks, but that was not enough.  Still
puzzled, I separated the patterns into nonpic and !nonpic, and we get
the expected matchcounts this way.

Tests for -mfentry require an mfentry effective target, which excludes
32-bit x86 with PIC or PIE enabled, that's why the patterns that
accept the PIC sym@RELOC annotations only cover x86_64.  mvc7 is
getting regexps extended to cover PIC reloc annotatios and all of the
named variants, and tightened to avoid unexpected '.' matches.

The pr24414 test stores in an unadorned named variable in an old-style
asm statement, to check that such asm statements get an implicit
memory clobber.  Rewriting the asm into a GCC extended asm with the
variable as an output would remove the regression it checks against.
Problem is, the literal reference to the variable is not PIC, so it's
rejected by the elf64 linker with an error, and flagged with a warning
by the elf32 one.  We could presumably make the variable references
PIC-friendly with #ifdefs, but I doubt that's worth the trouble.  I'm
just arranging for the test to be skipped if PIC or PIE are enabled by
default.


for  gcc/testsuite/ChangeLog

* gcc.target/i386/cet-sjlj-6a.c: Cope with --enable-default-pie.
* gcc.target/i386/cet-sjlj-6b.c: Likewise.
* gcc.target/i386/fentryname3.c: Likewise.
* gcc.target/i386/mvc7.c: Likewise.
* gcc.target/i386/pr24414.c: Likewise.
* gcc.target/i386/pr93492-3.c: Likewise.
* gcc.target/i386/pr93492-5.c: Likewise.
* gcc.target/i386/pr98482-1.c: Likewise.
---
 gcc/testsuite/gcc.target/i386/cet-sjlj-6a.c |6 --
 gcc/testsuite/gcc.target/i386/cet-sjlj-6b.c |6 --
 gcc/testsuite/gcc.target/i386/fentryname3.c |3 ++-
 gcc/testsuite/gcc.target/i386/mvc7.c|   12 ++--
 gcc/testsuite/gcc.target/i386/pr24414.c |1 +
 gcc/testsuite/gcc.target/i386/pr93492-3.c   |2 +-
 gcc/testsuite/gcc.target/i386/pr93492-5.c   |2 +-
 gcc/testsuite/gcc.target/i386/pr98482-1.c   |3 ++-
 8 files changed, 21 insertions(+), 14 deletions(-)

diff --git a/gcc/testsuite/gcc.target/i386/cet-sjlj-6a.c 
b/gcc/testsuite/gcc.target/i386/cet-sjlj-6a.c
index 040b297aeb023..c3d0eb929424d 100644
--- a/gcc/testsuite/gcc.target/i386/cet-sjlj-6a.c
+++ b/gcc/testsuite/gcc.target/i386/cet-sjlj-6a.c
@@ -2,8 +2,10 @@
 /* { dg-require-effective-target maybe_x32 } */
 /* { dg-options "-O -maddress-mode=short -fcf-protection -mx32" } */
 /* { dg-final { scan-assembler-times "endbr64" 2 } } */
-/* { dg-final { scan-assembler-times "movq\t.*buf\\+8" 1 } } */
-/* { dg-final { scan-assembler-times "subq\tbuf\\+8" 1 } } */
+/* { dg-final { scan-assembler-times "movq\t\[^\n\]*buf\\+8" 1 { target nonpic 
} } } */
+/* { dg-final { scan-assembler-times "movq\t\[^\n\]*8\\+buf" 1 { target { ! 
nonpic } } } } */
+/* { dg-final { scan-assembler-times "subq\tbuf\\+8" 1 { target nonpic } } } */
+/* { dg-final { scan-assembler-times "subq\t8\\+buf" 1 { target { ! nonpic } } 
} } */
 /* { dg-final { scan-assembler-times "shrl\t\\\$3," 1 } } */
 /* { dg-final { scan-assembler-times "rdsspq" 2 } } */
 /* { dg-final { scan-assembler-times "incsspq" 2 } } */
diff --git a/gcc/testsuite/gcc.target/i386/cet-sjlj-6b.c 
b/gcc/testsuite/gcc.target/i386/cet-sjlj-6b.c
index b2376e710df6a..4c52685d7d1e1 100644
--- a/gcc/testsuite/gcc.target/i386/cet-sjlj-6b.c
+++ b/gcc/testsuite/gcc.target/i386/cet-sjlj-6b.c
@@ -2,8 +2,10 @@
 /* { dg-require-effective-target maybe_x32 } */
 /* { dg-options "-O -maddress-mode=long -fcf-protection -mx32" } */
 /* { dg-final { scan-assembler-times "endbr64" 2 } } */
-/* { dg-final { scan-assembler-times "movq\t.*buf\\+16" 1 } } */
-/* { dg-final { scan-assembler-times "subq\tbuf\\+16" 1 } } */
+/* { dg-final { scan-assembler-times "movq\t\[^\n\]*buf\\+16" 1 { target 
nonpic } } } */
+/* { dg-final { scan-assembler-times "movq\t\[^\n\]*16\\+buf" 1 { target { ! 
nonpic } } } } */
+/* { dg-final { scan-assembler-times "subq\tbuf\\+16" 1 { target nonpic } } } 
*/
+/* { dg-final { scan-assembler-times "subq\t16\\+buf" 1 { target { ! nonpic } 
} } } */
 /* { dg-final { scan-assembler-times "shrl\t\\\$3," 1 } } */
 /* { dg-final { scan-assembler-times "rdsspq" 2 } } */
 /* { dg-final { scan-assembler-times "incsspq" 2 } } */
diff -

Re: [PATCH 1/2] Add gcc/make-unique.h

[Pedro Alves]

On 2022-07-12 4:14 p.m., Jonathan Wakely wrote:

>>  So once GCC requires C++14, why would you want to preserve
>> once-backported symbols in a namespace other than std, when you no longer 
>> have a reason to?
>> It will just be another unnecessary thing that newcomers at that future time 
>> will have
>> to learn.
> 
> I also don't see a problem with importing std::make_unique into
> namespace gcc for local use alongside other things in namespace gcc. I
> do consider that idiomatic. It says "the make_unique for gcc code is
> std::make_unique". It means you only need a 'using namespace gcc;' at
> the top of a source file and you get access to everything in namespace
> gcc, even if it is something like std::make_unique that was originally
> defined in a different namespace.
> 

If that's the approach, then GCC should import std::unique_ptr, std::move,
std::foo, std::bar into the gcc namespace too, no?  Are you really going
to propose that?

[PATCH] dwarf2.h (enum dwarf_source_language): Add new DWARF5 language codes.

[Meghan Denny]

Updated constants from 


diff --git a/include/dwarf2.h b/include/dwarf2.h
index 40aa5a54f01..87bf764a4fb 100644
--- a/include/dwarf2.h
+++ b/include/dwarf2.h
@@ -373,6 +373,16 @@ enum dwarf_source_language
DW_LANG_Fortran03 = 0x0022,
DW_LANG_Fortran08 = 0x0023,
DW_LANG_RenderScript = 0x0024,
+ DW_LANG_BLISS = 0x0025,
+ DW_LANG_Kotlin = 0x0026,
+ DW_LANG_Zig = 0x0027,
+ DW_LANG_Crystal = 0x0028,
+ DW_LANG_C_plus_plus_17 = 0x002a,
+ DW_LANG_C_plus_plus_20 = 0x002b,
+ DW_LANG_C17 = 0x002c,
+ DW_LANG_Fortran18 = 0x002d,
+ DW_LANG_Ada2005 = 0x002e,
+ DW_LANG_Ada2012 = 0x002f,

DW_LANG_lo_user = 0x8000, /* Implementation-defined range start. 
*/DW_LANG_hi_user = 0x, /* Implementation-defined range start. */

Re: Mips: Fix kernel_stat structure size

[Hans-Peter Nilsson]

On Tue, 12 Jul 2022, Dimitrije Milosevic wrote:
> Hi Hans-Peter,
> You're right, this is not ok for the O32 ABI. Your change however, broke the 
> functionality
> for the N32 ABI.

That's just not true.  There was no mips support for ASAN in
gcc, hence nothing to break for N32.  Maybe an anachronism?

Or maybe you mean plain backporting to LLVM?  Perhaps it needs
adjustments for their _FILE_OFFSET_BITS=64 builds?  On the other
hand, that struct_kernel_stat_sz shouldn't be affected by that -
unless that's a misnomer or they get the includes wrong - but
then again, the include part was fixed by the patch.  Unless
mis-merged, as in gcc currently.

> AFAIK, the changes like this should go through LLVM first
> (yours didn't),

As I recall, and judging from the mentioned commit, this would
have given them no benefit; no visible error to fix, as they're
always building the runtime with for 64-bit file size.  But yes,
it should have been submitted there eventually.

> so I will send out a review, covering both 32 ABIs, meaning that both O32 and 
> N32 ABIs
> will be working properly.

Very good.  Thank you in advance.

> As for this change, I'm not sure what should be done?
> Should this be committed now, while the LLVM change is cherry-picked once 
> it's committed.
> Best regards,
> Dimitrije Milosevic
>
>
> From: Hans-Peter Nilsson 
> Sent: Saturday, July 9, 2022 4:44 PM
> To: Xi Ruoyao 
> Cc: Dimitrije Milosevic ; Djordje Todorovic 
> ; gcc-patches@gcc.gnu.org 
> 
> Subject: Re: Mips: Fix kernel_stat structure size
> ?
> On Sat, 9 Jul 2022, Xi Ruoyao wrote:
>
> > On Fri, 2022-07-08 at 21:42 -0400, Hans-Peter Nilsson wrote:
> > > On Fri, 1 Jul 2022, Dimitrije Milosevic wrote:
> > >
> > > > Fix kernel_stat structure size for non-Android 32-bit Mips.
> > > > LLVM currently has this value for the kernel_stat structure size,
> > > > as per compiler-rt/lib/sanitizer-
> > > > common/sanitizer_platform_limits_posix.h.
> > > > This also resolves one of the build issues for non-Android 32-bit
> > > > Mips.
> > >
> > > I insist that PR105614 comment #7 is the way to go, i.e. fix
> > > the merge error, avoiding the faulty include that it
> > > reintroduced.? Was this tested on O32?
> >
> > I'm pretty sure it is *not* the way to go.
> >
> > Sanitizer does not really intercept system call.? It intercepts libc
> > stat() or lstat() etc. calls.? So you need to keep struct_kernel_stat_sz
> > same as the size of struct stat in libc, i. e. "the size of buffer which
> > *libc* stat()-like functions writing into".
> >
> > The "kernel_" in the name is just misleading.
>
> You make a sound argument, and I just refer to my old commit
> 9f943b2446f2d0a.? Either way, the proof is in the pussing: was
> this tested for O32 or not?
>
> > And, if you still think it should be the way to go, let's submit the
> > change to LLVM and get it reviewed properly.
>
> Sorry, I've no longer interest in mips besides I'd like to see
> un-broken what I helped getting in a working state (support ASAN
> in gcc for mips O32).
>
> brgds, H-P

Re: [PATCH v2] Simplify memchr with small constant strings

[H.J. Lu via Gcc-patches]

On Fri, Jul 8, 2022 at 5:54 AM Richard Biener
 wrote:
>
> On Thu, Jul 7, 2022 at 6:45 PM H.J. Lu  wrote:
> >
> > When memchr is applied on a constant string of no more than the bytes of
> > a word, simplify memchr by checking each byte in the constant string.
> >
> > int f (int a)
> > {
> >return  __builtin_memchr ("AE", a, 2) != 0;
> > }
> >
> > is simplified to
> >
> > int f (int a)
> > {
> >   return ((char) a == 'A' || (char) a == 'E') != 0;
> > }
> >
> > gcc/
> >
> > PR tree-optimization/103798
> > * tree-ssa-forwprop.cc: Include "tree-ssa-strlen.h".
> > (simplify_builtin_call): Inline memchr with constant strings of
> > no more than the bytes of a word.
> > * tree-ssa-strlen.cc (use_in_zero_equality): Make it global.
> > * tree-ssa-strlen.h (use_in_zero_equality): New.
> >
> > gcc/testsuite/
> >
> > PR tree-optimization/103798
> > * c-c++-common/pr103798-1.c: New test.
> > * c-c++-common/pr103798-2.c: Likewise.
> > * c-c++-common/pr103798-3.c: Likewise.
> > * c-c++-common/pr103798-4.c: Likewise.
> > * c-c++-common/pr103798-5.c: Likewise.
> > * c-c++-common/pr103798-6.c: Likewise.
> > * c-c++-common/pr103798-7.c: Likewise.
> > * c-c++-common/pr103798-8.c: Likewise.
> > ---
> >  gcc/testsuite/c-c++-common/pr103798-1.c | 28 +++
> >  gcc/testsuite/c-c++-common/pr103798-2.c | 30 
> >  gcc/testsuite/c-c++-common/pr103798-3.c | 28 +++
> >  gcc/testsuite/c-c++-common/pr103798-4.c | 28 +++
> >  gcc/testsuite/c-c++-common/pr103798-5.c | 26 ++
> >  gcc/testsuite/c-c++-common/pr103798-6.c | 27 +++
> >  gcc/testsuite/c-c++-common/pr103798-7.c | 27 +++
> >  gcc/testsuite/c-c++-common/pr103798-8.c | 27 +++
> >  gcc/tree-ssa-forwprop.cc| 64 +
> >  gcc/tree-ssa-strlen.cc  |  4 +-
> >  gcc/tree-ssa-strlen.h   |  2 +
> >  11 files changed, 289 insertions(+), 2 deletions(-)
> >  create mode 100644 gcc/testsuite/c-c++-common/pr103798-1.c
> >  create mode 100644 gcc/testsuite/c-c++-common/pr103798-2.c
> >  create mode 100644 gcc/testsuite/c-c++-common/pr103798-3.c
> >  create mode 100644 gcc/testsuite/c-c++-common/pr103798-4.c
> >  create mode 100644 gcc/testsuite/c-c++-common/pr103798-5.c
> >  create mode 100644 gcc/testsuite/c-c++-common/pr103798-6.c
> >  create mode 100644 gcc/testsuite/c-c++-common/pr103798-7.c
> >  create mode 100644 gcc/testsuite/c-c++-common/pr103798-8.c
> >
> > diff --git a/gcc/testsuite/c-c++-common/pr103798-1.c 
> > b/gcc/testsuite/c-c++-common/pr103798-1.c
> > new file mode 100644
> > index 000..cd3edf569fc
> > --- /dev/null
> > +++ b/gcc/testsuite/c-c++-common/pr103798-1.c
> > @@ -0,0 +1,28 @@
> > +/* { dg-do run } */
> > +/* { dg-options "-O2 -fdump-tree-optimized -save-temps" } */
> > +
> > +__attribute__ ((weak))
> > +int
> > +f (char a)
> > +{
> > +   return  __builtin_memchr ("a", a, 1) == 0;
> > +}
> > +
> > +__attribute__ ((weak))
> > +int
> > +g (char a)
> > +{
> > +  return a != 'a';
> > +}
> > +
> > +int
> > +main ()
> > +{
> > + for (int i = 0; i < 255; i++)
> > +   if (f (i) != g (i))
> > + __builtin_abort ();
> > +
> > + return 0;
> > +}
> > +
> > +/* { dg-final { scan-assembler-not "memchr" } } */
> > diff --git a/gcc/testsuite/c-c++-common/pr103798-2.c 
> > b/gcc/testsuite/c-c++-common/pr103798-2.c
> > new file mode 100644
> > index 000..e7e99c3679e
> > --- /dev/null
> > +++ b/gcc/testsuite/c-c++-common/pr103798-2.c
> > @@ -0,0 +1,30 @@
> > +/* { dg-do run } */
> > +/* { dg-options "-O2 -fdump-tree-optimized -save-temps" } */
> > +
> > +#include 
> > +
> > +__attribute__ ((weak))
> > +int
> > +f (int a)
> > +{
> > +   return memchr ("aE", a, 2) != NULL;
> > +}
> > +
> > +__attribute__ ((weak))
> > +int
> > +g (char a)
> > +{
> > +  return a == 'a' || a == 'E';
> > +}
> > +
> > +int
> > +main ()
> > +{
> > + for (int i = 0; i < 255; i++)
> > +   if (f (i + 256) != g (i + 256))
> > + __builtin_abort ();
> > +
> > + return 0;
> > +}
> > +
> > +/* { dg-final { scan-assembler-not "memchr" } } */
> > diff --git a/gcc/testsuite/c-c++-common/pr103798-3.c 
> > b/gcc/testsuite/c-c++-common/pr103798-3.c
> > new file mode 100644
> > index 000..ddcedc7e238
> > --- /dev/null
> > +++ b/gcc/testsuite/c-c++-common/pr103798-3.c
> > @@ -0,0 +1,28 @@
> > +/* { dg-do run } */
> > +/* { dg-options "-O2 -fdump-tree-optimized -save-temps" } */
> > +
> > +__attribute__ ((weak))
> > +int
> > +f (char a)
> > +{
> > +   return  __builtin_memchr ("aEgZ", a, 3) == 0;
> > +}
> > +
> > +__attribute__ ((weak))
> > +int
> > +g (char a)
> > +{
> > +  return a != 'a' && a != 'E' && a != 'g';
> > +}
> > +
> > +int
> > +main ()
> > +{
> > + for (int i = 0; i < 255; i++)
> > +   if (f (i) != g (i))
> > + __builtin_abort ();
> > +
> > + return 0;
> > +}
> > +
> > +/* { dg-final { scan-assembler-not "memchr" } } */
> > diff 

Re: [PATCH] c++: coroutines - Overlap variables in frame [PR105989]

[Iain Sandoe]

Hi Michal,

> On 12 Jul 2022, at 16:14, Michal Jankovič  wrote:

> One other related thing I would like to investigate is reducing the
> number of compiler generated variables in the frame, particularly
> _Coro_destroy_fn and _Coro_self_handle.  
> 
> As I understand it, _Coro_destroy_fn just sets a flag in
> _Coro_resume_index and calls _Coro_resume_fn; it should be possible to
> move this logic to __builtin_coro_destroy, so that only _Coro_resume_fn
> is stored in the frame;

That is a particular point about GCC’s implementation … (it is not neccesarily, 
or even
likely to be the same for other implementations) - see below.

I was intending to do experiment with making the ramp/resume/destroy value a 
parameter
to the actor function so that we would have something like -

ramp calls  actor(frame, 0)
resume calls  actor(frame, 1)
destroy calls  actor(frame, 2) 
- the token values are illustrative, not intended to be a final version.

I think that should allow for more inlining opportunites and possibly a way 
forward to
frame elision (a.k.a halo).

> this would however change the coroutine ABI - I don't know if that's a 
> problem.

The external ABI for the coroutine is the 
 resume,
 destroy pointers 
 and the promise 
 and that one can find each of these from the frame pointer.

This was agreed between the interested “vendors” so that one compiler could 
invoke
coroutines built by another.  So I do not think this is so much a useful area 
to explore.

Also the intent is that an indirect call through the frame pointer is the most 
frequent
operation so should be the most efficient.  
  resume() might be called many times, 
  destroy() just once thus it is a cold code path 
  - space can be important too - but interoperability was the goal here.

> The _Coro_self_handle should be constructible on-demand from the frame 
> address.

Yes, and in the header the relevant items are all constexpr - so that should 
happen in the
user’s code.  I elected to have that value in the frame to avoid recreating it 
each time - I
suppose that is a trade-off of one oiptimisation c.f. another … 
> 
> Do you have any advice / opinions on this before I try to implement it?

Hopefully, the notes above help.

I will rebase my latest code changes as soon as I have a chance and put them 
somewhere
for you to look at - basically, these are to try and address the correctness 
issues we face,

Iain


> 
> Michal
> 
> On Jul 12 2022, at 4:08 pm, Iain Sandoe  wrote:
> 
>> Hi Michal,
>> 
>>> On 12 Jul 2022, at 14:35, Michal Jankovič via Gcc-patches
>>>  wrote:
>>> 
>>> Currently, coroutine frames store all variables of a coroutine separately,
>>> even if their lifetime does not overlap (they are in distinct
>>> scopes). This
>>> patch implements overlapping distinct variable scopes in the
>>> coroutine frame,
>>> by storing the frame fields in nested unions of structs. This lowers
>>> the size
>>> of the frame for larger coroutines significantly, and makes them more usable
>>> on systems with limited memory.
>> 
>> not a review (I will try to take a look at the weekend).
>> 
>> but … this is one of the two main optimisations on my TODO - so cool
>> for doing it.
>> 
>> (the other related optimisation is to eliminate frame entries for
>> scopes without any suspend
>> points - which has the potential to save even more space for code with
>> sparse use of co_)
>> 
>> Iain
>> 
>>> Bootstrapped and regression tested on x86_64-pc-linux-gnu; new test fails
>>> before the patch and succeeds after with no regressions.
>>> 
>>> PR c++/105989
>>> 
>>> gcc/cp/ChangeLog:
>>> 
>>> * coroutines.cc (struct local_var_info): Add field_access_path.
>>> (build_local_var_frame_access_expr): New.
>>> (transform_local_var_uses): Use build_local_var_frame_access_expr.
>>> (coro_make_frame_entry_id): New.
>>> (coro_make_frame_entry): Delegate to coro_make_frame_entry_id.
>>> (struct local_vars_frame_data): Add orig, field_access_path.
>>> (register_local_var_uses): Generate new frame layout. Create access
>>> paths to vars.
>>> (morph_fn_to_coro): Set new fields in local_vars_frame_data.  
>>> 
>>> gcc/testsuite/ChangeLog:
>>> 
>>> * g++.dg/coroutines/pr105989.C: New test.
>>> 
>>> 
>> 
>> 

[PATCH v2] c++: Add __reference_con{struc,ver}ts_from_temporary [PR104477]

[Marek Polacek via Gcc-patches]

On Mon, Jul 11, 2022 at 11:19:19AM +0100, Jonathan Wakely wrote:
> On Fri, 8 Jul 2022 at 18:41, Marek Polacek wrote:
> > The patch also adds the relevant class and variable templates to 
> > .
> 
> 
> +  template
> +struct reference_constructs_from_temp
> orary
> +: public __bool_constant<__reference_constructs_from_temporary(_Tp, _Up)>
> 
> This can use bool_constant, as that was added in C++17.
> __bool_constant is the internal equivalent for pre-C++17.

Ah, I see, I didn't know std::bool_constant was a C++17 thing!
 
> The library parts are fine with that change, thanks for implementing this!

Thanks, updated patch below.

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

-- >8 --
This patch implements C++23 P2255R2, which adds two new type traits to
detect reference binding to a temporary.  They can be used to detect code
like

  std::tuple t("meow");

which is incorrect because it always creates a dangling reference, because
the std::string temporary is created inside the selected constructor of
std::tuple, and not outside it.

There are two new compiler builtins, __reference_constructs_from_temporary
and __reference_converts_from_temporary.  The former is used to simulate
direct- and the latter copy-initialization context.  But I had a hard time
finding a test where there's actually a difference.  Under DR 2267, both
of these are invalid:

  struct A { } a;
  struct B { explicit B(const A&); };
  const B &b1{a};
  const B &b2(a);

so I had to peruse [over.match.ref], and eventually realized that the
difference can be seen here:

  struct G {
operator int(); // #1
explicit operator int&&(); // #2
  };

int&& r1(G{}); // use #2 (no temporary)
int&& r2 = G{}; // use #1 (a temporary is created to be bound to int&&)

The implementation itself was rather straightforward because we already
have conv_binds_ref_to_prvalue.  The main function here is
reference_from_temporary.  The renaming to ref_conv_binds_to_temporary_p
is because previously the function didn't distinguish between an invalid
conversion and one that binds to a prvalue.

The patch also adds the relevant class and variable templates to .

PR c++/104477

gcc/c-family/ChangeLog:

* c-common.cc (c_common_reswords): Add
__reference_constructs_from_temporary and
__reference_converts_from_temporary.
* c-common.h (enum rid): Add RID_REF_CONSTRUCTS_FROM_TEMPORARY and
RID_REF_CONVERTS_FROM_TEMPORARY.

gcc/cp/ChangeLog:

* call.cc (ref_conv_binds_directly_p): Rename to ...
(ref_conv_binds_to_temporary_p): ... this.  Add a new bool
parameter.  Return true only if the conversion is valid and
conv_binds_ref_to_prvalue returns true.
* constraint.cc (diagnose_trait_expr): Handle
CPTK_REF_CONSTRUCTS_FROM_TEMPORARY and CPTK_REF_CONVERTS_FROM_TEMPORARY.
* cp-tree.h (enum cp_trait_kind): Add CPTK_REF_CONSTRUCTS_FROM_TEMPORARY
and CPTK_REF_CONVERTS_FROM_TEMPORARY.
(ref_conv_binds_directly_p): Rename to ...
(ref_conv_binds_to_temporary_p): ... this.
(reference_from_temporary): Declare.
* cxx-pretty-print.cc (pp_cxx_trait_expression): Handle
CPTK_REF_CONSTRUCTS_FROM_TEMPORARY and CPTK_REF_CONVERTS_FROM_TEMPORARY.
* method.cc (reference_from_temporary): New.
* parser.cc (cp_parser_primary_expression): Handle
RID_REF_CONSTRUCTS_FROM_TEMPORARY and RID_REF_CONVERTS_FROM_TEMPORARY.
(cp_parser_trait_expr): Likewise.
(warn_for_range_copy): Adjust to call ref_conv_binds_to_temporary_p.
* semantics.cc (trait_expr_value): Handle
CPTK_REF_CONSTRUCTS_FROM_TEMPORARY and CPTK_REF_CONVERTS_FROM_TEMPORARY.
(finish_trait_expr): Likewise.

libstdc++-v3/ChangeLog:

* include/std/type_traits (reference_constructs_from_temporary,
reference_converts_from_temporary): New class templates.
(reference_constructs_from_temporary_v,
reference_converts_from_temporary_v): New variable templates.
(__cpp_lib_reference_from_temporary): Define for C++23.
* include/std/version (__cpp_lib_reference_from_temporary): Define for
C++23.
* testsuite/20_util/variable_templates_for_traits.cc: Test
reference_constructs_from_temporary_v and
reference_converts_from_temporary_v.
* testsuite/20_util/reference_from_temporary/value.cc: New test.
* testsuite/20_util/reference_from_temporary/value2.cc: New test.
* testsuite/20_util/reference_from_temporary/version.cc: New test.

gcc/testsuite/ChangeLog:

* g++.dg/ext/reference_constructs_from_temporary1.C: New test.
* g++.dg/ext/reference_converts_from_temporary1.C: New test.
---
 gcc/c-family/c-common.cc  |   4 +
 gcc/c-family/c-common.h   |   2 +
 gcc/cp/call.cc|  14 +-
 gcc/cp/constraint.cc  |   8 +
 gcc/cp/cp-tre

Re: [PATCH v3, rs6000] Disable TImode from Bool expanders [PR100694, PR93123]

[Segher Boessenkool]

Hi!

On Mon, Jul 04, 2022 at 02:27:42PM +0800, HAO CHEN GUI wrote:
>   This patch fails TImode for all 128-bit logical operation expanders. So
> TImode splits to two DI registers during expand. Potential optimizations can
> be taken after expand pass. Originally, the TImode logical operations are
> split after reload pass. It's too late. The test case illustrates it.

Out of interest, did you see any performance win?  There is a lot of
opportunity for this to cause performance *loss*, on newer systems :-(

> ChangeLog
> 2022-07-04 Haochen Gui 

Two spaces both before and after your name, in changelogs.

> --- a/gcc/config/rs6000/rs6000.md
> +++ b/gcc/config/rs6000/rs6000.md
> @@ -7078,27 +7078,38 @@ (define_expand "subti3"
>  })
>  
>  ;; 128-bit logical operations expanders
> +;; Fail TImode in all 128-bit logical operations expanders and split it into
> +;; two DI registers.
> 
>  (define_expand "and3"
>[(set (match_operand:BOOL_128 0 "vlogical_operand")
>   (and:BOOL_128 (match_operand:BOOL_128 1 "vlogical_operand")
> (match_operand:BOOL_128 2 "vlogical_operand")))]
>""
> -  "")
> +{
> +  if (mode == TImode)
> +FAIL;
> +})

It is better to not FAIL it, but simply not have a pattern for the
TImode version at all.

Does nothing depend on the :TI version to exist?

What about the :PTI version?  Getting rid of that as well will allow
some nice optimisations.

Of course we *do* have instructions to do such TImode ops, on newer
CPUs, but in vector registers only.  It isn't obvious what is faster.

> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/powerpc/pr100694.c
> @@ -0,0 +1,16 @@
> +/* { dg-do compile } */
> +/* { dg-require-effective-target int128 } */
> +/* { dg-options "-O2" } */
> +/* { dg-final { scan-assembler-times {\mstd\M} 2 } } */
> +/* { dg-final { scan-assembler-not {\mli\M} } } */
> +/* { dg-final { scan-assembler-not {\mor\M} } } */
> +
> +/* It just needs two std.  */
> +void foo (unsigned __int128* res, unsigned long long hi, unsigned long long 
> lo)
> +{
> +   unsigned __int128 i = hi;
> +   i <<= 64;
> +   i |= lo;
> +   *res = i;
> +}

You can also just count the number of generated insns:
/* { dg-final { scan-assembler-times {(?n)^\s+[a-z]} 3 } } */
(three, not two, because of the blr insn at the end).

If possible, we should simply not do :TI ops on older systems at all,
and only on the newer systems that have instructions for it (and that
does not fix PR100694 btw, the problems there have to be solved, not
side-stepped :-( )


Segher

Re: [PATCH 1/2] Add gcc/make-unique.h

[Jonathan Wakely via Gcc-patches]

On Tue, 12 Jul 2022, 17:40 Pedro Alves,  wrote:

> On 2022-07-12 4:14 p.m., Jonathan Wakely wrote:
>
> >>  So once GCC requires C++14, why would you want to preserve
> >> once-backported symbols in a namespace other than std, when you no
> longer have a reason to?
> >> It will just be another unnecessary thing that newcomers at that future
> time will have
> >> to learn.
> >
> > I also don't see a problem with importing std::make_unique into
> > namespace gcc for local use alongside other things in namespace gcc. I
> > do consider that idiomatic. It says "the make_unique for gcc code is
> > std::make_unique". It means you only need a 'using namespace gcc;' at
> > the top of a source file and you get access to everything in namespace
> > gcc, even if it is something like std::make_unique that was originally
> > defined in a different namespace.
> >
>
> If that's the approach, then GCC should import std::unique_ptr, std::move,
> std::foo, std::bar into the gcc namespace too, no?  Are you really going
> to propose that?
>

No, I don't follow the logic of "if you do it for one thing you must do it
for everything". That's a straw man. But I don't really mind how this gets
done. Your suggestion is fine.

>

Re: [PATCH] Fortran: error recovery simplifying PACK with invalid arguments [PR106049]

[Harald Anlauf via Gcc-patches]

As there were no comments, committed as r13-1650.

Am 05.07.22 um 22:31 schrieb Harald Anlauf via Fortran:

Dear all,

poor error recovery while trying to simplify intrinsics with given
invalid arguments seems to be a recurrent theme in testcases submitted
by Gerhard.  In the present case, simplification of PACK() chokes on
the array argument being a bad decl.

The most general approach that came to my mind is to modify function
is_constant_array_expr: when the declared shape of the array indicates
a size greater than zero, but the constructor is missing or empty,
then something bad may have happened, and the array cannot be
considered constant.  We thus punt on simplification of something
that cannot be simplified.  With some luck, this might prevent issues
in similar cases elsewhere...

Regtested on x86_64-pc-linux-gnu.  OK for mainline?

Thanks,
Harald

Re: [PATCH 1/2] Add gcc/make-unique.h

[Pedro Alves]

On 2022-07-12 7:22 p.m., Jonathan Wakely wrote:
> 
> 
> On Tue, 12 Jul 2022, 17:40 Pedro Alves,  > wrote:
> 
> On 2022-07-12 4:14 p.m., Jonathan Wakely wrote:
> 
> >>  So once GCC requires C++14, why would you want to preserve
> >> once-backported symbols in a namespace other than std, when you no 
> longer have a reason to?
> >> It will just be another unnecessary thing that newcomers at that 
> future time will have
> >> to learn.
> >
> > I also don't see a problem with importing std::make_unique into
> > namespace gcc for local use alongside other things in namespace gcc. I
> > do consider that idiomatic. It says "the make_unique for gcc code is
> > std::make_unique". It means you only need a 'using namespace gcc;' at
> > the top of a source file and you get access to everything in namespace
> > gcc, even if it is something like std::make_unique that was originally
> > defined in a different namespace.
> >
> 
> If that's the approach, then GCC should import std::unique_ptr, std::move,
> std::foo, std::bar into the gcc namespace too, no?  Are you really going
> to propose that?
> 
> 
> No, I don't follow the logic of "if you do it for one thing you must do it 
> for everything". That's a straw man. But I don't really mind how this gets 
> done. Your suggestion is fine.
> 

It isn't a strawman, Jon.  Maybe there's some miscommunication.  The conversion 
started (and part of it is
still quoted above), by thinking about what we'd do once we get to C++14, and 
my suggestion to optimize
for that.  When we get to the point when we require C++14, make_unique is no 
longer different from any other
symbol in the std namespace, and there will be no reason to treat it 
differently anymore.  Like, if someone at
that point proposes to remove the global make_unique or gcc::make_unique, and 
replace all references with
std::make_unique, there will be no real ground to object to that, why wouldn't 
you want it?  This is very
much like when you removed "gnu::unique_ptr" (not going to miss it) a few 
months back -- you replaced
it by "std::unique_ptr"; gnu::unique_ptr wasn't kept just because of history.

Cheers,
Pedro Alves

Re: [PATCH 1/2] Add gcc/make-unique.h

[David Malcolm via Gcc-patches]

On Tue, 2022-07-12 at 17:40 +0100, Pedro Alves wrote:
> On 2022-07-12 4:14 p.m., Jonathan Wakely wrote:
> 
> > >  So once GCC requires C++14, why would you want to preserve

I look forward to the happy day when we can use C++14 in GCC's
implementation, but I don't see it happening anytime soon.

GCC's needs may differ from those of GDB's.  I'm not very familiar with
GDB's insides, but, for example, GCC has its own garbage-collector
which complicates everything to do with memory managements.

Right now I have comments expressing ownership of some pointers, and
e.g. "takes ownership of ...".  It would be wonderful to take some baby
steps into using C++11 to express the ownership directly in code.

> > > once-backported symbols in a namespace other than std, when you
> > > no longer have a reason to?
> > > It will just be another unnecessary thing that newcomers at that
> > > future time will have
> > > to learn.
> > 
> > I also don't see a problem with importing std::make_unique into
> > namespace gcc for local use alongside other things in namespace
> > gcc. I
> > do consider that idiomatic. It says "the make_unique for gcc code
> > is
> > std::make_unique". It means you only need a 'using namespace gcc;'
> > at
> > the top of a source file and you get access to everything in
> > namespace
> > gcc, even if it is something like std::make_unique that was
> > originally
> > defined in a different namespace.

Jonathan's idea sounds good to me.

> > 
> 
> If that's the approach, then GCC should import std::unique_ptr,
> std::move,
> std::foo, std::bar into the gcc namespace too, no?  Are you really
> going
> to propose that?

Pedro, it feels to me like you're constructing a strawman here. 
Neither me nor Jonathan are proposing that.

I just want to be able to comfortably use std::unique_ptr in GCC in the
places for which it makes sense, and being able to use "make_unique" is
a part of that.

Hope this is constructive
Dave

Re: [PATCH 1/2] Add gcc/make-unique.h

[Pedro Alves]

On 2022-07-12 7:36 p.m., Pedro Alves wrote:
> On 2022-07-12 7:22 p.m., Jonathan Wakely wrote:
>>
>>
>> On Tue, 12 Jul 2022, 17:40 Pedro Alves, > > wrote:
>>
>> On 2022-07-12 4:14 p.m., Jonathan Wakely wrote:
>>
>> >>  So once GCC requires C++14, why would you want to preserve
>> >> once-backported symbols in a namespace other than std, when you no 
>> longer have a reason to?
>> >> It will just be another unnecessary thing that newcomers at that 
>> future time will have
>> >> to learn.
>> >
>> > I also don't see a problem with importing std::make_unique into
>> > namespace gcc for local use alongside other things in namespace gcc. I
>> > do consider that idiomatic. It says "the make_unique for gcc code is
>> > std::make_unique". It means you only need a 'using namespace gcc;' at
>> > the top of a source file and you get access to everything in namespace
>> > gcc, even if it is something like std::make_unique that was originally
>> > defined in a different namespace.
>> >
>>
>> If that's the approach, then GCC should import std::unique_ptr, 
>> std::move,
>> std::foo, std::bar into the gcc namespace too, no?  Are you really going
>> to propose that?
>>
>>
>> No, I don't follow the logic of "if you do it for one thing you must do it 
>> for everything". That's a straw man. But I don't really mind how this gets 
>> done. Your suggestion is fine.
>>
> 
> It isn't a strawman, Jon.  Maybe there's some miscommunication.  The 
> conversion started (and part of it is
> still quoted above), by thinking about what we'd do once we get to C++14, and 
> my suggestion to optimize
> for that.  When we get to the point when we require C++14, make_unique is no 
> longer different from any other
> symbol in the std namespace, and there will be no reason to treat it 
> differently anymore.  Like, if someone at
> that point proposes to remove the global make_unique or gcc::make_unique, and 
> replace all references with
> std::make_unique, there will be no real ground to object to that, why 
> wouldn't you want it?  This is very
> much like when you removed "gnu::unique_ptr" (not going to miss it) a few 
> months back -- you replaced
> it by "std::unique_ptr"; gnu::unique_ptr wasn't kept just because of history.

Sorry to reply to myself -- but I'm not sure it is clear what I meant above in 
the last sentence, so let
me try again: 'the "gnu::unique_ptr" wasn't rewritten as an import of 
std::unique_ptr into the gnu namespace
just because of history.'

Re: [PATCH 1/2] Add gcc/make-unique.h

[Pedro Alves]

On 2022-07-12 7:36 p.m., David Malcolm wrote:
> On Tue, 2022-07-12 at 17:40 +0100, Pedro Alves wrote:

>>>
>>
>> If that's the approach, then GCC should import std::unique_ptr,
>> std::move,
>> std::foo, std::bar into the gcc namespace too, no?  Are you really
>> going
>> to propose that?
> 
> Pedro, it feels to me like you're constructing a strawman here. 
> Neither me nor Jonathan are proposing that.
> 

See my other reply.

I am actually appalled at how the conversion seems to have derailed.

> I just want to be able to comfortably use std::unique_ptr in GCC in the
> places for which it makes sense, and being able to use "make_unique" is
> a part of that.

My suggestion was simple:

wrap your make_unique in namespace gcc, so that later on when we get to
C++14, yanking it out causes as little churn as possible, with just a 3 letters
for 3 letters replacement.  I never thought this would be objectionable.

If you don't want to do that, that's fine, the churn will happen in the future,
but it's no big deal.  You'll get to live with shorter make_unique for a few 
years
(my bet is not forever).

> 
> Hope this is constructive
> Dave
> 
> 

Re: [PATCH 1/2] Add gcc/make-unique.h

[Jonathan Wakely via Gcc-patches]

On Tue, 12 Jul 2022, 19:36 Pedro Alves,  wrote:

> On 2022-07-12 7:22 p.m., Jonathan Wakely wrote:
> >
> >
> > On Tue, 12 Jul 2022, 17:40 Pedro Alves,  pe...@palves.net>> wrote:
> >
> > On 2022-07-12 4:14 p.m., Jonathan Wakely wrote:
> >
> > >>  So once GCC requires C++14, why would you want to preserve
> > >> once-backported symbols in a namespace other than std, when you
> no longer have a reason to?
> > >> It will just be another unnecessary thing that newcomers at that
> future time will have
> > >> to learn.
> > >
> > > I also don't see a problem with importing std::make_unique into
> > > namespace gcc for local use alongside other things in namespace
> gcc. I
> > > do consider that idiomatic. It says "the make_unique for gcc code
> is
> > > std::make_unique". It means you only need a 'using namespace gcc;'
> at
> > > the top of a source file and you get access to everything in
> namespace
> > > gcc, even if it is something like std::make_unique that was
> originally
> > > defined in a different namespace.
> > >
> >
> > If that's the approach, then GCC should import std::unique_ptr,
> std::move,
> > std::foo, std::bar into the gcc namespace too, no?  Are you really
> going
> > to propose that?
> >
> >
> > No, I don't follow the logic of "if you do it for one thing you must do
> it for everything". That's a straw man. But I don't really mind how this
> gets done. Your suggestion is fine.
> >
>
> It isn't a strawman, Jon.  Maybe there's some miscommunication.  The
> conversion started (and part of it is
> still quoted above), by thinking about what we'd do once we get to C++14,
> and my suggestion to optimize
> for that.



Yeah, and I don't think optimizing for indentation is the right trade off.
Putting something in a namespace with a three-letter name just so you don't
have to re-indent some statements in a few years seems odd.

I see no technical difficulty replacing a custom make_unique (in any
namespace) with std::make_unique at a later date.

If a namespace made sense to avoid name clashes, or to enable finding
functions by ADL, or other technical reasons, I'd be all for it. But no
such rationale was given, and using a namespace for indentation just seems
odd to me.

But I really don't care. Putting it in the global namespace or a 'gcc'
namespace or anything else appropriate to GCC is fine. I'll leave this
thread now. I don't think this is very constructive and I'm sorry for
objecting to the suggestion.


  When we get to the point when we require C++14, make_unique is no longer
> different from any other
> symbol in the std namespace, and there will be no reason to treat it
> differently anymore.  Like, if someone at
> that point proposes to remove the global make_unique or gcc::make_unique,
> and replace all references with
> std::make_unique, there will be no real ground to object to that, why
> wouldn't you want it?  This is very
> much like when you removed "gnu::unique_ptr" (not going to miss it) a few
> months back -- you replaced
> it by "std::unique_ptr"; gnu::unique_ptr wasn't kept just because of
> history.
>
> Cheers,
> Pedro Alves
>

Re: [PATCH 1/2] Add gcc/make-unique.h

[Pedro Alves]

On 2022-07-12 7:50 p.m., Jonathan Wakely wrote:

> Yeah, and I don't think optimizing for indentation is the right trade off. 
> Putting something in a namespace with a three-letter name just so you don't 
> have to re-indent some statements in a few years seems odd.
> 
> I see no technical difficulty replacing a custom make_unique (in any 
> namespace) with std::make_unique at a later date.
> 
> If a namespace made sense to avoid name clashes, or to enable finding 
> functions by ADL, or other technical reasons, I'd be all for it. But no such 
> rationale was given, and using a namespace for indentation just seems odd to 
> me.
> 
> But I really don't care. Putting it in the global namespace or a 'gcc' 
> namespace or anything else appropriate to GCC is fine. I'll leave this thread 
> now. I don't think this is very constructive and I'm sorry for objecting to 
> the suggestion.

That's fair.  Cheers!  Hope we'll be able to laugh about it in Prague!

Re: [PATCH 1/2] Add gcc/make-unique.h

[Jonathan Wakely via Gcc-patches]

On Tue, 12 Jul 2022 at 19:41, Pedro Alves  wrote:
>
> On 2022-07-12 7:36 p.m., Pedro Alves wrote:
> > On 2022-07-12 7:22 p.m., Jonathan Wakely wrote:
> >>
> >>
> >> On Tue, 12 Jul 2022, 17:40 Pedro Alves,  >> > wrote:
> >>
> >> On 2022-07-12 4:14 p.m., Jonathan Wakely wrote:
> >>
> >> >>  So once GCC requires C++14, why would you want to preserve
> >> >> once-backported symbols in a namespace other than std, when you no 
> >> longer have a reason to?
> >> >> It will just be another unnecessary thing that newcomers at that 
> >> future time will have
> >> >> to learn.
> >> >
> >> > I also don't see a problem with importing std::make_unique into
> >> > namespace gcc for local use alongside other things in namespace gcc. 
> >> I
> >> > do consider that idiomatic. It says "the make_unique for gcc code is
> >> > std::make_unique". It means you only need a 'using namespace gcc;' at
> >> > the top of a source file and you get access to everything in 
> >> namespace
> >> > gcc, even if it is something like std::make_unique that was 
> >> originally
> >> > defined in a different namespace.
> >> >
> >>
> >> If that's the approach, then GCC should import std::unique_ptr, 
> >> std::move,
> >> std::foo, std::bar into the gcc namespace too, no?  Are you really 
> >> going
> >> to propose that?
> >>
> >>
> >> No, I don't follow the logic of "if you do it for one thing you must do it 
> >> for everything". That's a straw man. But I don't really mind how this gets 
> >> done. Your suggestion is fine.
> >>
> >
> > It isn't a strawman, Jon.  Maybe there's some miscommunication.  The 
> > conversion started (and part of it is
> > still quoted above), by thinking about what we'd do once we get to C++14, 
> > and my suggestion to optimize
> > for that.  When we get to the point when we require C++14, make_unique is 
> > no longer different from any other
> > symbol in the std namespace, and there will be no reason to treat it 
> > differently anymore.  Like, if someone at
> > that point proposes to remove the global make_unique or gcc::make_unique, 
> > and replace all references with
> > std::make_unique, there will be no real ground to object to that, why 
> > wouldn't you want it?  This is very
> > much like when you removed "gnu::unique_ptr" (not going to miss it) a few 
> > months back -- you replaced
> > it by "std::unique_ptr"; gnu::unique_ptr wasn't kept just because of 
> > history.
>
> Sorry to reply to myself -- but I'm not sure it is clear what I meant above 
> in the last sentence, so let
> me try again: 'the "gnu::unique_ptr" wasn't rewritten as an import of 
> std::unique_ptr into the gnu namespace
> just because of history.'

[OFFLIST]

I considered doing exactly that. But because namespace gnu wasn't used
anywhere else in GCC it didn't make sense. If it had been put in
namespace gcc, which is still used elsewhere in the GCC codebase, I
might have decided differently. But keeping namespace 'gnu' with no
content except 'using std::unique_ptr;' would have been pointless. It
wouldn't have made it easier for other things in namespace gnu to
refer to it, because there were no other things. It wouldn't have
allowed 'using namespace gnu;' to make various useful utilities
available with a single using-directive, because that would only make
one thing available, and 'using std::unique_ptr;' does that just as
effectively.

Re: [PATCH 1/2] Add gcc/make-unique.h

[Jonathan Wakely via Gcc-patches]

On Tue, 12 Jul 2022 at 19:58, Jonathan Wakely  wrote:
> [OFFLIST]

Oops, sorry, reply-all fail. I meant to spare everybody any further
musing on this topic.

Really leaving the thread now!

ICE after folding svld1rq to vec_perm_expr duing forwprop

[Prathamesh Kulkarni via Gcc-patches]

Hi Richard,
For the following test:

svint32_t f2(int a, int b, int c, int d)
{
  int32x4_t v = (int32x4_t) {a, b, c, d};
  return svld1rq_s32 (svptrue_b8 (), &v[0]);
}

The compiler emits following ICE with -O3 -mcpu=generic+sve:
foo.c: In function ‘f2’:
foo.c:4:11: error: non-trivial conversion in ‘view_convert_expr’
4 | svint32_t f2(int a, int b, int c, int d)
  |   ^~
svint32_t
__Int32x4_t
_7 = VIEW_CONVERT_EXPR<__Int32x4_t>(_8);
during GIMPLE pass: forwprop
dump file: foo.c.109t.forwprop2
foo.c:4:11: internal compiler error: verify_gimple failed
0xfda04a verify_gimple_in_cfg(function*, bool)
../../gcc/gcc/tree-cfg.cc:5568
0xe9371f execute_function_todo
../../gcc/gcc/passes.cc:2091
0xe93ccb execute_todo
../../gcc/gcc/passes.cc:2145

This happens because, after folding svld1rq_s32 to vec_perm_expr, we have:
  int32x4_t v;
  __Int32x4_t _1;
  svint32_t _9;
  vector(4) int _11;

   :
  _1 = {a_3(D), b_4(D), c_5(D), d_6(D)};
  v_12 = _1;
  _11 = v_12;
  _9 = VEC_PERM_EXPR <_11, _11, { 0, 1, 2, 3, ... }>;
  return _9;

During forwprop, simplify_permutation simplifies vec_perm_expr to
view_convert_expr,
and the end result becomes:
  svint32_t _7;
  __Int32x4_t _8;

;;   basic block 2, loop depth 0
;;pred:   ENTRY
  _8 = {a_2(D), b_3(D), c_4(D), d_5(D)};
  _7 = VIEW_CONVERT_EXPR<__Int32x4_t>(_8);
  return _7;
;;succ:   EXIT

which causes the error duing verify_gimple since VIEW_CONVERT_EXPR
has incompatible types (svint32_t, int32x4_t).

The attached patch disables simplification of VEC_PERM_EXPR
in simplify_permutation, if lhs and rhs have non compatible types,
which resolves ICE, but am not sure if it's the correct approach ?

Alternatively, should we allow assignments from fixed-width to SVE
vector, so the above
VIEW_CONVERT_EXPR would result in dup ?

Thanks,
Prathamesh
diff --git a/gcc/tree-ssa-forwprop.cc b/gcc/tree-ssa-forwprop.cc
index 69567ab3275..be888f1c48e 100644
--- a/gcc/tree-ssa-forwprop.cc
+++ b/gcc/tree-ssa-forwprop.cc
@@ -2414,6 +2414,9 @@ simplify_permutation (gimple_stmt_iterator *gsi)
   if (TREE_CODE (op2) != VECTOR_CST)
 return 0;
 
+  if (!types_compatible_p (TREE_TYPE (gimple_get_lhs (stmt)), TREE_TYPE (op0)))
+return 0;
+
   if (TREE_CODE (op0) == VECTOR_CST)
 {
   code = VECTOR_CST;

Re: [PATCH 2/3] tree-cfg: do not duplicate returns_twice calls

[Alexander Monakov via Gcc-patches]

Apologies for the prolonged silence Richard, it is a bit of an obscure topic,
and I was unsure I'd be able to handle any complications in a timely manner.
I'm ready to revisit it now, please see below.

On Mon, 17 Jan 2022, Richard Biener wrote:

> On Fri, Jan 14, 2022 at 7:21 PM Alexander Monakov  wrote:
> >
> > A returns_twice call may have associated abnormal edges that correspond
> > to the "second return" from the call. If the call is duplicated, the
> > copies of those edges also need to be abnormal, but e.g. tracer does not
> > enforce that. Just prohibit the (unlikely to be useful) duplication.
> 
> The general CFG copying routines properly duplicate those edges, no?

No (in fact you say so in the next paragraph). In general I think they cannot,
abnormal edges are a special case, so it should be the responsibility of the
caller.

> Tracer uses duplicate_block so it should also get copies of all successor
> edges of that block.  It also only traces along normal edges.  What it might
> miss is abnormal incoming edges - is that what you are referring to?

Yes (I think its entire point is to build a "trace" of duplicated blocks that
does not have incoming edges in the middle, abnormal or not).

> That would be a thing we don't handle in duplicate_block on its own but
> that callers are expected to do (though I don't see copy_bbs doing that
> either).  I wonder if we can trigger this issue for some testcase?

Oh yes (in fact my desire to find a testcase delayed this quite a bit).
When compiling the following testcase with -O2 -ftracer:

__attribute__((returns_twice))
int rtwice_a(int), rtwice_b(int);

int f(int *x)
{
volatile unsigned k, i = (*x);

for (k = 1; (i = rtwice_a(i)) * k; k = 2);

for (; (i = rtwice_b(i)) * k; k = 4);

return k;
}

tracer manages to eliminate the ABNORMAL_DISPATCHER block completely, so
the possibility of transferring control back to rtwice_a from rtwice_b
is no longer modeled in the IR. I could spend some time "upgrading" this
to an end-to-end miscompilation, but I hope you agree this is quite broken
already.

> The thing to check would be incoming abnormal edges in
> can_duplicate_block_p, not (only) returns twice functions?

Unfortunately not, abnormal edges are also used for computed gotos, which are
less magic than returns_twice edges and should not block tracer I think.

This implies patch 1/3 [1] unnecessary blocks sinking to computed goto targets.
[1] https://gcc.gnu.org/pipermail/gcc-patches/2022-January/588498.html

How would you like to proceed here? Is my initial patch ok?

Alexander

> 
> Richard.
> 
> > gcc/ChangeLog:
> >
> > * tree-cfg.c (gimple_can_duplicate_bb_p): Reject blocks with
> > calls that may return twice.
> > ---
> >  gcc/tree-cfg.c | 7 +--
> >  1 file changed, 5 insertions(+), 2 deletions(-)
> >
> > diff --git a/gcc/tree-cfg.c b/gcc/tree-cfg.c
> > index b7fe313b7..a99f1acb4 100644
> > --- a/gcc/tree-cfg.c
> > +++ b/gcc/tree-cfg.c
> > @@ -6304,12 +6304,15 @@ gimple_can_duplicate_bb_p (const_basic_block bb)
> >  {
> >gimple *g = gsi_stmt (gsi);
> >
> > -  /* An IFN_GOMP_SIMT_ENTER_ALLOC/IFN_GOMP_SIMT_EXIT call must be
> > +  /* Prohibit duplication of returns_twice calls, otherwise associated
> > +abnormal edges also need to be duplicated properly.
> > +An IFN_GOMP_SIMT_ENTER_ALLOC/IFN_GOMP_SIMT_EXIT call must be
> >  duplicated as part of its group, or not at all.
> >  The IFN_GOMP_SIMT_VOTE_ANY and IFN_GOMP_SIMT_XCHG_* are part of 
> > such a
> >  group, so the same holds there.  */
> >if (is_gimple_call (g)
> > - && (gimple_call_internal_p (g, IFN_GOMP_SIMT_ENTER_ALLOC)
> > + && (gimple_call_flags (g) & ECF_RETURNS_TWICE
> > + || gimple_call_internal_p (g, IFN_GOMP_SIMT_ENTER_ALLOC)
> >   || gimple_call_internal_p (g, IFN_GOMP_SIMT_EXIT)
> >   || gimple_call_internal_p (g, IFN_GOMP_SIMT_VOTE_ANY)
> >   || gimple_call_internal_p (g, IFN_GOMP_SIMT_XCHG_BFLY)
> > --
> > 2.33.1
> >
> 

Re: [PATCH] c++: Add __reference_con{struc,ver}ts_from_temporary [PR104477]

[Jason Merrill via Gcc-patches]

On 7/8/22 13:41, Marek Polacek wrote:

This patch implements C++23 P2255R2, which adds two new type traits to
detect reference binding to a temporary.  They can be used to detect code
like

   std::tuple t("meow");

which is incorrect because it always creates a dangling reference, because
the std::string temporary is created inside the selected constructor of
std::tuple, and not outside it.

There are two new compiler builtins, __reference_constructs_from_temporary
and __reference_converts_from_temporary.  The former is used to simulate
direct- and the latter copy-initialization context.  But I had a hard time
finding a test where there's actually a difference.  Under DR 2267, both
of these are invalid:

   struct A { } a;
   struct B { explicit B(const A&); };
   const B &b1{a};
   const B &b2(a);

so I had to peruse [over.match.ref], and eventually realized that the
difference can be seen here:

   struct G {
 operator int(); // #1
 explicit operator int&&(); // #2
   };

int&& r1(G{}); // use #2 (no temporary)
int&& r2 = G{}; // use #1 (a temporary is created to be bound to int&&)

The implementation itself was rather straightforward because we already
have conv_binds_ref_to_prvalue.  The main function here is
reference_from_temporary.  The renaming to ref_conv_binds_to_temporary_p
is because previously the function didn't distinguish between an invalid
conversion and one that binds to a prvalue.

The patch also adds the relevant class and variable templates to .

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

PR c++/104477

gcc/c-family/ChangeLog:

* c-common.cc (c_common_reswords): Add
__reference_constructs_from_temporary and
__reference_converts_from_temporary.
* c-common.h (enum rid): Add RID_REF_CONSTRUCTS_FROM_TEMPORARY and
RID_REF_CONVERTS_FROM_TEMPORARY.

gcc/cp/ChangeLog:

* call.cc (ref_conv_binds_directly_p): Rename to ...
(ref_conv_binds_to_temporary_p): ... this.  Add a new bool
parameter.  Return true only if the conversion is valid and
conv_binds_ref_to_prvalue returns true.
* constraint.cc (diagnose_trait_expr): Handle
CPTK_REF_CONSTRUCTS_FROM_TEMPORARY and CPTK_REF_CONVERTS_FROM_TEMPORARY.
* cp-tree.h (enum cp_trait_kind): Add CPTK_REF_CONSTRUCTS_FROM_TEMPORARY
and CPTK_REF_CONVERTS_FROM_TEMPORARY.
(ref_conv_binds_directly_p): Rename to ...
(ref_conv_binds_to_temporary_p): ... this.
(reference_from_temporary): Declare.
* cxx-pretty-print.cc (pp_cxx_trait_expression): Handle
CPTK_REF_CONSTRUCTS_FROM_TEMPORARY and CPTK_REF_CONVERTS_FROM_TEMPORARY.
* method.cc (reference_from_temporary): New.
* parser.cc (cp_parser_primary_expression): Handle
RID_REF_CONSTRUCTS_FROM_TEMPORARY and RID_REF_CONVERTS_FROM_TEMPORARY.
(cp_parser_trait_expr): Likewise.
(warn_for_range_copy): Adjust to call ref_conv_binds_to_temporary_p.
* semantics.cc (trait_expr_value): Handle
CPTK_REF_CONSTRUCTS_FROM_TEMPORARY and CPTK_REF_CONVERTS_FROM_TEMPORARY.
(finish_trait_expr): Likewise.

libstdc++-v3/ChangeLog:

* include/std/type_traits (reference_constructs_from_temporary,
reference_converts_from_temporary): New class templates.
(reference_constructs_from_temporary_v,
reference_converts_from_temporary_v): New variable templates.
(__cpp_lib_reference_from_temporary): Define for C++23.
* include/std/version (__cpp_lib_reference_from_temporary): Define for
C++23.
* testsuite/20_util/variable_templates_for_traits.cc: Test
reference_constructs_from_temporary_v and
reference_converts_from_temporary_v.
* testsuite/20_util/reference_from_temporary/value.cc: New test.
* testsuite/20_util/reference_from_temporary/value2.cc: New test.
* testsuite/20_util/reference_from_temporary/version.cc: New test.

gcc/testsuite/ChangeLog:

* g++.dg/ext/reference_constructs_from_temporary1.C: New test.
* g++.dg/ext/reference_converts_from_temporary1.C: New test.
---
  gcc/c-family/c-common.cc  |   4 +
  gcc/c-family/c-common.h   |   2 +
  gcc/cp/call.cc|  14 +-
  gcc/cp/constraint.cc  |   8 +
  gcc/cp/cp-tree.h  |   7 +-
  gcc/cp/cxx-pretty-print.cc|   6 +
  gcc/cp/method.cc  |  28 +++
  gcc/cp/parser.cc  |  14 +-
  gcc/cp/semantics.cc   |   8 +
  .../reference_constructs_from_temporary1.C| 214 ++
  .../ext/reference_converts_from_temporary1.C  | 214 ++
  libstdc++-v3/include/std/type_traits  |  39 
  libstdc++-v3/include/std/version  |   5 +-
  .../20_util/reference_from_temporary/value.cc | 110 +
  

Re: [PATCH] c++: Add __reference_con{struc,ver}ts_from_temporary [PR104477]

[Jason Merrill via Gcc-patches]

On 7/12/22 16:10, Jason Merrill wrote:

On 7/8/22 13:41, Marek Polacek wrote:

This patch implements C++23 P2255R2, which adds two new type traits to
detect reference binding to a temporary.  They can be used to detect code
like

   std::tuple t("meow");

which is incorrect because it always creates a dangling reference, 
because

the std::string temporary is created inside the selected constructor of
std::tuple, and not outside it.

There are two new compiler builtins, 
__reference_constructs_from_temporary

and __reference_converts_from_temporary.  The former is used to simulate
direct- and the latter copy-initialization context.  But I had a hard 
time

finding a test where there's actually a difference.  Under DR 2267, both
of these are invalid:

   struct A { } a;
   struct B { explicit B(const A&); };
   const B &b1{a};
   const B &b2(a);

so I had to peruse [over.match.ref], and eventually realized that the
difference can be seen here:

   struct G {
 operator int(); // #1
 explicit operator int&&(); // #2
   };

int&& r1(G{}); // use #2 (no temporary)
int&& r2 = G{}; // use #1 (a temporary is created to be bound to int&&)

The implementation itself was rather straightforward because we already
have conv_binds_ref_to_prvalue.  The main function here is
reference_from_temporary.  The renaming to ref_conv_binds_to_temporary_p
is because previously the function didn't distinguish between an invalid
conversion and one that binds to a prvalue.

The patch also adds the relevant class and variable templates to 
.


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

PR c++/104477

gcc/c-family/ChangeLog:

* c-common.cc (c_common_reswords): Add
__reference_constructs_from_temporary and
__reference_converts_from_temporary.
* c-common.h (enum rid): Add RID_REF_CONSTRUCTS_FROM_TEMPORARY and
RID_REF_CONVERTS_FROM_TEMPORARY.

gcc/cp/ChangeLog:

* call.cc (ref_conv_binds_directly_p): Rename to ...
(ref_conv_binds_to_temporary_p): ... this.  Add a new bool
parameter.  Return true only if the conversion is valid and
conv_binds_ref_to_prvalue returns true.
* constraint.cc (diagnose_trait_expr): Handle
CPTK_REF_CONSTRUCTS_FROM_TEMPORARY and 
CPTK_REF_CONVERTS_FROM_TEMPORARY.
* cp-tree.h (enum cp_trait_kind): Add 
CPTK_REF_CONSTRUCTS_FROM_TEMPORARY

and CPTK_REF_CONVERTS_FROM_TEMPORARY.
(ref_conv_binds_directly_p): Rename to ...
(ref_conv_binds_to_temporary_p): ... this.
(reference_from_temporary): Declare.
* cxx-pretty-print.cc (pp_cxx_trait_expression): Handle
CPTK_REF_CONSTRUCTS_FROM_TEMPORARY and 
CPTK_REF_CONVERTS_FROM_TEMPORARY.

* method.cc (reference_from_temporary): New.
* parser.cc (cp_parser_primary_expression): Handle
RID_REF_CONSTRUCTS_FROM_TEMPORARY and 
RID_REF_CONVERTS_FROM_TEMPORARY.

(cp_parser_trait_expr): Likewise.
(warn_for_range_copy): Adjust to call ref_conv_binds_to_temporary_p.
* semantics.cc (trait_expr_value): Handle
CPTK_REF_CONSTRUCTS_FROM_TEMPORARY and 
CPTK_REF_CONVERTS_FROM_TEMPORARY.

(finish_trait_expr): Likewise.

libstdc++-v3/ChangeLog:

* include/std/type_traits (reference_constructs_from_temporary,
reference_converts_from_temporary): New class templates.
(reference_constructs_from_temporary_v,
reference_converts_from_temporary_v): New variable templates.
(__cpp_lib_reference_from_temporary): Define for C++23.
* include/std/version (__cpp_lib_reference_from_temporary): Define 
for

C++23.
* testsuite/20_util/variable_templates_for_traits.cc: Test
reference_constructs_from_temporary_v and
reference_converts_from_temporary_v.
* testsuite/20_util/reference_from_temporary/value.cc: New test.
* testsuite/20_util/reference_from_temporary/value2.cc: New test.
* testsuite/20_util/reference_from_temporary/version.cc: New test.

gcc/testsuite/ChangeLog:

* g++.dg/ext/reference_constructs_from_temporary1.C: New test.
* g++.dg/ext/reference_converts_from_temporary1.C: New test.
---
  gcc/c-family/c-common.cc  |   4 +
  gcc/c-family/c-common.h   |   2 +
  gcc/cp/call.cc    |  14 +-
  gcc/cp/constraint.cc  |   8 +
  gcc/cp/cp-tree.h  |   7 +-
  gcc/cp/cxx-pretty-print.cc    |   6 +
  gcc/cp/method.cc  |  28 +++
  gcc/cp/parser.cc  |  14 +-
  gcc/cp/semantics.cc   |   8 +
  .../reference_constructs_from_temporary1.C    | 214 ++
  .../ext/reference_converts_from_temporary1.C  | 214 ++
  libstdc++-v3/include/std/type_traits  |  39 
  libstdc++-v3/include/std/version  |   5 +-
  .../20_util/reference_from_temporary/value.cc | 110 +
  .../reference_from_temporary/value2.cc    |  28 +++
  .../reference_from_temporary/version.cc   |  27

[committed] libstdc++: Check for EOF if extraction avoids buffer overflow [PR106248]

[Jonathan Wakely via Gcc-patches]

Tested x86_64-linux, pushed to trunk. Backports to gcc-12 and gcc-11 to
follow.

-- >8 --

In r11-2581-g17abcc77341584 (for LWG 2499) I added overflow checks to
the pre-C++20 operator>>(istream&, char*) overload.  Those checks can
cause extraction to stop after filling the buffer, where previously it
would have tried to extract another character and stopped at EOF. When
that happens we no longer set eofbit in the stream state, which is
consistent with the behaviour of the new C++20 overload, but is an
observable and unexpected change in the C++17 behaviour. What makes it
worse is that the behaviour change is dependent on optimization, because
__builtin_object_size is used to detect the buffer size and that only
works when optimizing.

To avoid the unexpected and optimization-dependent change in behaviour,
set eofbit manually if we stopped extracting because of the buffer size
check, but had reached EOF anyway. If the stream's rdstate() != goodbit
or width() is non-zero and smaller than the buffer, there's nothing to
do. Otherwise, we filled the buffer and need to check for EOF, and maybe
set eofbit.

The new check is guarded by #ifdef __OPTIMIZE__ because otherwise
__builtin_object_size is useless. There's no point compiling and
emitting dead code that can't be eliminated because we're not
optimizing.

We could add extra checks that the next character in the buffer is not
whitespace, to detect the case where we stopped early and prevented a
buffer overflow that would have happened otherwise. That would allow us
to assert or set badbit in the stream state when undefined behaviour was
prevented. However, those extra checks would increase the size of the
function, potentially reducing the likelihood of it being inlined, and
so making the buffer size detection less reliable. It seems preferable
to prevent UB and silently truncate, rather than miss the UB and allow
the overflow to happen.

libstdc++-v3/ChangeLog:

PR libstdc++/106248
* include/std/istream [C++17] (operator>>(istream&, char*)):
Set eofbit if we stopped extracting at EOF.
* testsuite/27_io/basic_istream/extractors_character/char/pr106248.cc:
New test.
* 
testsuite/27_io/basic_istream/extractors_character/wchar_t/pr106248.cc:
New test.
---
 libstdc++-v3/include/std/istream  | 33 ---
 .../extractors_character/char/pr106248.cc | 40 +++
 .../extractors_character/wchar_t/pr106248.cc  | 40 +++
 3 files changed, 107 insertions(+), 6 deletions(-)
 create mode 100644 
libstdc++-v3/testsuite/27_io/basic_istream/extractors_character/char/pr106248.cc
 create mode 100644 
libstdc++-v3/testsuite/27_io/basic_istream/extractors_character/wchar_t/pr106248.cc

diff --git a/libstdc++-v3/include/std/istream b/libstdc++-v3/include/std/istream
index b506c4f7504..416ef556fa1 100644
--- a/libstdc++-v3/include/std/istream
+++ b/libstdc++-v3/include/std/istream
@@ -784,7 +784,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
*  - if `width()` is greater than zero, `n` is `min(width(), n)`
*  - otherwise `n` is the number of elements of the array
*  - (before C++20 the pointer is assumed to point to an array of
-   *  - the largest possible size for an array of `char_type`).
+   *the largest possible size for an array of `char_type`).
*
*  Characters are extracted and stored until one of the following happens:
*  - `n - 1` characters are stored
@@ -802,19 +802,40 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 inline basic_istream<_CharT, _Traits>&
 operator>>(basic_istream<_CharT, _Traits>& __in, _CharT* __s)
 {
+#ifdef __OPTIMIZE__
+  // Function inlining might make the buffer size known, allowing us to
+  // prevent overflow.
   size_t __n = __builtin_object_size(__s, 0);
-  if (__builtin_expect(__n < sizeof(_CharT), false))
+  if (__n < sizeof(_CharT))
{
  // There is not even space for the required null terminator.
  __glibcxx_assert(__n >= sizeof(_CharT));
+ // No point calling __istream_extract, but still need to reset width.
  __in.width(0);
  __in.setstate(ios_base::failbit);
}
-  else
+  else if (__n != (size_t)-1)
{
- if (__n == (size_t)-1)
-   __n = __gnu_cxx::__numeric_traits::__max;
- std::__istream_extract(__in, __s, __n / sizeof(_CharT));
+ __n /= sizeof(_CharT);
+ streamsize __w = __in.width();
+ std::__istream_extract(__in, __s, __n);
+ if (__in.good() && (__w <= 0 || __n < __w))
+   {
+ // Stopped extracting early to avoid overflowing the buffer,
+ // but might have stopped anyway (and set eofbit) if at EOF.
+ const typename _Traits::int_type __c = __in.rdbuf()->sgetc();
+ const bool __eof = _Traits::eq_int_type(__c, _Traits::eof());
+ if (__builtin_expect(__eof, true)) // Assume EOF, not overflow.
+

Re: [PATCH V2] btf: emit linkage information in BTF_KIND_FUNC entries

[Indu Bhagat via Gcc-patches]

On 7/12/22 8:13 AM, Jose E. Marchesi via Gcc-patches wrote:


The kernel bpftool expects BTF_KIND_FUNC entries in BTF to include an
annotation reflecting the linkage of functions (static, global).  For
whatever reason they abuse the `vlen' field of the BTF_KIND_FUNC entry
instead of adding a variable-part to the record like it is done with
other entry kinds.

This patch makes GCC to include this linkage info in BTF_KIND_FUNC
entries.

Tested in bpf-unknown-none target.



I am not the maintainer of this functionality, but this version looks OK 
to me.


Thanks


gcc/ChangeLog:

PR debug/106263
* ctfc.h (struct ctf_dtdef): Add field linkage.
* ctfc.cc (ctf_add_function): Set ctti_linkage.
* dwarf2ctf.cc (gen_ctf_function_type): Pass a linkage for
function types and subprograms.
* btfout.cc (btf_asm_func_type): Emit linkage information for the
function.
(btf_dtd_emit_preprocess_cb): Propagate the linkage information
for functions.

gcc/testsuite/ChangeLog:

PR debug/106263
* gcc.dg/debug/btf/btf-function-4.c: New test.
* gcc.dg/debug/btf/btf-function-5.c: Likewise.
---
  gcc/btfout.cc   |  6 +-
  gcc/ctfc.cc |  3 ++-
  gcc/ctfc.h  |  3 ++-
  gcc/dwarf2ctf.cc|  4 +++-
  gcc/testsuite/gcc.dg/debug/btf/btf-function-4.c | 14 ++
  gcc/testsuite/gcc.dg/debug/btf/btf-function-5.c | 14 ++
  6 files changed, 40 insertions(+), 4 deletions(-)
  create mode 100644 gcc/testsuite/gcc.dg/debug/btf/btf-function-4.c
  create mode 100644 gcc/testsuite/gcc.dg/debug/btf/btf-function-5.c

diff --git a/gcc/btfout.cc b/gcc/btfout.cc
index 31af50521da..594cba84910 100644
--- a/gcc/btfout.cc
+++ b/gcc/btfout.cc
@@ -463,6 +463,7 @@ btf_dtd_emit_preprocess_cb (ctf_container_ref ctfc, 
ctf_dtdef_ref dtd)
ctf_dtdef_ref func_dtd = ggc_cleared_alloc ();
func_dtd->dtd_data = dtd->dtd_data;
func_dtd->dtd_data.ctti_type = dtd->dtd_type;
+  func_dtd->linkage = dtd->linkage;
  
vec_safe_push (funcs, func_dtd);

num_types_created++;
@@ -740,7 +741,10 @@ static void
  btf_asm_func_type (ctf_dtdef_ref dtd)
  {
dw2_asm_output_data (4, dtd->dtd_data.ctti_name, "btt_name");
-  dw2_asm_output_data (4, BTF_TYPE_INFO (BTF_KIND_FUNC, 0, 0), "btt_info");
+  dw2_asm_output_data (4, BTF_TYPE_INFO (BTF_KIND_FUNC, 0,
+ dtd->linkage),
+   "btt_info: kind=%u, kflag=%u, linkage=%u",
+   BTF_KIND_FUNC, 0, dtd->linkage);
dw2_asm_output_data (4, get_btf_id (dtd->dtd_data.ctti_type), "btt_type");
  }
  
diff --git a/gcc/ctfc.cc b/gcc/ctfc.cc

index f24e7bff948..9773358a475 100644
--- a/gcc/ctfc.cc
+++ b/gcc/ctfc.cc
@@ -777,7 +777,7 @@ ctf_add_function_arg (ctf_container_ref ctfc, dw_die_ref 
func,
  ctf_id_t
  ctf_add_function (ctf_container_ref ctfc, uint32_t flag, const char * name,
  const ctf_funcinfo_t * ctc, dw_die_ref die,
- bool from_global_func)
+ bool from_global_func, int linkage)
  {
ctf_dtdef_ref dtd;
ctf_id_t type;
@@ -791,6 +791,7 @@ ctf_add_function (ctf_container_ref ctfc, uint32_t flag, 
const char * name,
type = ctf_add_generic (ctfc, flag, name, &dtd, die);
  
dtd->from_global_func = from_global_func;

+  dtd->linkage = linkage;
dtd->dtd_data.ctti_info = CTF_TYPE_INFO (CTF_K_FUNCTION, flag, vlen);
/* Caller must make sure CTF types for ctc->ctc_return are already added.  
*/
dtd->dtd_data.ctti_type = (uint32_t) ctc->ctc_return;
diff --git a/gcc/ctfc.h b/gcc/ctfc.h
index 001e544ef08..bcf3a43ae1b 100644
--- a/gcc/ctfc.h
+++ b/gcc/ctfc.h
@@ -161,6 +161,7 @@ struct GTY ((for_user)) ctf_dtdef
ctf_itype_t dtd_data; /* Type node.  */
bool from_global_func; /* Whether this type was added from a global
function.  */
+  uint32_t linkage;   /* Used in function types.  0=local, 1=global.  
*/
union GTY ((desc ("ctf_dtu_d_union_selector (&%1)")))
{
  /* struct, union, or enum.  */
@@ -423,7 +424,7 @@ extern ctf_id_t ctf_add_forward (ctf_container_ref, 
uint32_t, const char *,
  extern ctf_id_t ctf_add_typedef (ctf_container_ref, uint32_t, const char *,
 ctf_id_t, dw_die_ref);
  extern ctf_id_t ctf_add_function (ctf_container_ref, uint32_t, const char *,
- const ctf_funcinfo_t *, dw_die_ref, bool);
+ const ctf_funcinfo_t *, dw_die_ref, bool, 
int);
  extern ctf_id_t ctf_add_sou (ctf_container_ref, uint32_t, const char *,
 uint32_t, size_t, dw_die_ref);
  
diff --git a/gcc/dwarf2ctf.cc b/gcc/dwarf2ctf.cc

index a6329ab6ee4..39714c2 100644
--- a/gcc/dwarf2ctf.cc
+++ b/gcc/dwarf2ctf.cc
@@ -644,6 +644,7 @@ gen_

Re: Mips: Fix kernel_stat structure size

[Xi Ruoyao via Gcc-patches]

On Tue, 2022-07-12 at 06:42 +, Dimitrije Milosevic wrote:
> Hi Hans-Peter,
> You're right, this is not ok for the O32 ABI. Your change however, broke the 
> functionality
> for the N32 ABI. AFAIK, the changes like this should go through LLVM first 
> (yours didn't),
> so I will send out a review, covering both 32 ABIs, meaning that both O32 and 
> N32 ABIs 
> will be working properly. As for this change, I'm not sure what should be 
> done? 
> Should this be committed now, while the LLVM change is cherry-picked once 
> it's committed.

I think just get it into LLVM first, then we sync with LLVM.

It seems on o32 sizeof(struct stat) is 144, n32 -> 160, n64 -> 216
(tested on gcc23.fsffrance.org).  "Luckily" we don't support other
strange things like "o64".