date:20240425

On Thu, Apr 25, 2024 at 11:30:48AM -0400, Jason Merrill wrote:
> Hmm, maybe maybe_clone_body shouldn't clear DECL_SAVED_TREE for aliases, but
> rather set it to some stub like void_node?

I'll try that in stage1.

> Though with all these changes, it's probably better to go with your first
> patch for GCC 14 and delay this approach to 15.  Your v1 patch is OK for 14.

Just to record, following patch passed bootstrap/regtest on x86_64-linux and
i686-linux.  But I've committed the v1 version instead with the addition of
comdat2.C and comdat5.C testcases from this patch now and in stage1 will
post an incremental diff.

Thanks.

2024-04-25  Jakub Jelinek  
Jason Merrill  

PR lto/113208
* decl2.cc (tentative_decl_linkage): Call maybe_make_one_only
for implicit instantiations of maybe in charge ctors/dtors
declared inline.
(c_parse_final_cleanups): Don't skip used same body aliases which
have non-NULL DECL_SAVED_TREE on the alias target.  Formatting fixes.
* optimize.cc (can_alias_cdtor): Adjust condition, for
HAVE_COMDAT_GROUP && DECL_ONE_ONLY && DECL_WEAK return true even
if not DECL_INTERFACE_KNOWN.
* decl.cc (cxx_comdat_group): For DECL_CLONED_FUNCTION_P
functions if SUPPORTS_ONE_ONLY return DECL_COMDAT_GROUP if already
set.

* g++.dg/abi/comdat2.C: New test.
* g++.dg/abi/comdat3.C: New test.
* g++.dg/abi/comdat4.C: New test.
* g++.dg/abi/comdat5.C: New test.
* g++.dg/lto/pr113208_0.C: New test.
* g++.dg/lto/pr113208_1.C: New file.
* g++.dg/lto/pr113208.h: New file.

--- gcc/cp/decl2.cc.jj  2024-04-24 18:28:22.299513620 +0200
+++ gcc/cp/decl2.cc 2024-04-25 16:19:17.385547357 +0200
@@ -3312,16 +3312,23 @@ tentative_decl_linkage (tree decl)
 linkage of all functions, and as that causes writes to
 the data mapped in from the PCH file, it's advantageous
 to mark the functions at this point.  */
- if (DECL_DECLARED_INLINE_P (decl)
- && (!DECL_IMPLICIT_INSTANTIATION (decl)
- || DECL_DEFAULTED_FN (decl)))
+ if (DECL_DECLARED_INLINE_P (decl))
{
- /* This function must have external linkage, as
-otherwise DECL_INTERFACE_KNOWN would have been
-set.  */
- gcc_assert (TREE_PUBLIC (decl));
- comdat_linkage (decl);
- DECL_INTERFACE_KNOWN (decl) = 1;
+ if (!DECL_IMPLICIT_INSTANTIATION (decl)
+ || DECL_DEFAULTED_FN (decl))
+   {
+ /* This function must have external linkage, as
+otherwise DECL_INTERFACE_KNOWN would have been
+set.  */
+ gcc_assert (TREE_PUBLIC (decl));
+ comdat_linkage (decl);
+ DECL_INTERFACE_KNOWN (decl) = 1;
+   }
+ else if (DECL_MAYBE_IN_CHARGE_CDTOR_P (decl))
+   /* For implicit instantiations of cdtors try to make
+  it comdat, so that maybe_clone_body can use aliases.
+  See PR113208.  */
+   maybe_make_one_only (decl);
}
}
   else if (VAR_P (decl))
@@ -5264,7 +5271,19 @@ c_parse_final_cleanups (void)
generate_tls_wrapper (decl);
 
  if (!DECL_SAVED_TREE (decl))
-   continue;
+   {
+ cgraph_node *node;
+ tree tgt;
+ /* Even when maybe_clone_body created same body alias
+has no DECL_SAVED_TREE, if its alias target does,
+don't skip it.  */
+ if (!DECL_CLONED_FUNCTION (decl)
+ || !(node = cgraph_node::get (decl))
+ || !node->cpp_implicit_alias
+ || !(tgt = node->get_alias_target_tree ())
+ || !DECL_SAVED_TREE (tgt))
+   continue;
+   }
 
  cgraph_node *node = cgraph_node::get_create (decl);
 
@@ -5292,7 +5311,7 @@ c_parse_final_cleanups (void)
node = node->get_alias_target ();
 
  node->call_for_symbol_thunks_and_aliases (clear_decl_external,
- NULL, true);
+   NULL, true);
  /* If we mark !DECL_EXTERNAL one of the symbols in some comdat
 group, we need to mark all symbols in the same comdat group
 that way.  */
@@ -5302,7 +5321,7 @@ c_parse_final_cleanups (void)
 next != node;
 next = dyn_cast (next->same_comdat_group))
  next->call_for_symbol_thunks_and_aliases (clear_decl_external,
- NULL, true);
+   NULL, true);
}
 
  /* If we're going to need to write this

Re: [PATCH] c++, v2: Fix constexpr evaluation of parameters passed by invisible reference [PR111284]

2024-04-25 Thread Jason Merrill


On 4/23/24 08:52, Jakub Jelinek wrote:

On Mon, Apr 15, 2024 at 02:19:36PM +0200, Jakub Jelinek wrote:

They weren't the same, one was trying to evaluate the convert_from_reference
with vc_glvalue, the other evaluates it without that and with vc_prvalue.
Now, I guess the
+ /* Undo convert_for_arg_passing work here.  */
+ if (TYPE_REF_P (TREE_TYPE (x))
+ && !same_type_p (type, TREE_TYPE (TREE_TYPE (x
+   x = cp_fold_convert (build_reference_type (type), x);
part could be thrown away, given the other !same_type_p check (that one is
needed because adjust_temp_type can't deal with that), at least
when I remove that
GXX_TESTSUITE_STDS=98,11,14,17,20,23,26 make check-g++ 
RUNTESTFLAGS="dg.exp='constexpr-dtor* pr114426.C constexpr-111284.C 
constexpr-lifetime7.C'"
still passes.


I've now tested that version and it passed bootstrap/regtest on x86_64-linux
and i686-linux.  But as I said earlier, trying to tweak the patch further
doesn't work on the constexpr-dtor{5,6}.C tests.


OK.


2024-04-23  Jakub Jelinek  

PR c++/111284
* constexpr.cc (cxx_bind_parameters_in_call): For PARM_DECLs with
TREE_ADDRESSABLE types use vc_glvalue rather than vc_prvalue for
cxx_eval_constant_expression and if it doesn't have the same
type as it should, cast the reference type to reference to type
before convert_from_reference and instead of adjust_temp_type
take address of the arg, cast to reference to type and then
convert_from_reference.
(cxx_eval_constant_expression) : For lval case
on parameters with TREE_ADDRESSABLE types lookup result in
ctx->globals if possible.  Otherwise if lookup in ctx->globals
was successful for parameter with TREE_ADDRESSABLE type,
recurse with vc_prvalue on the returned value.

* g++.dg/cpp1z/constexpr-111284.C: New test.
* g++.dg/cpp1y/constexpr-lifetime7.C: Expect one error on a different
line.

--- gcc/cp/constexpr.cc.jj  2024-02-13 10:29:57.979155641 +0100
+++ gcc/cp/constexpr.cc 2024-03-07 19:35:01.032412221 +0100
@@ -1877,13 +1877,18 @@ cxx_bind_parameters_in_call (const const
  x = build_address (x);
}
if (TREE_ADDRESSABLE (type))
-   /* Undo convert_for_arg_passing work here.  */
-   x = convert_from_reference (x);
-  /* Normally we would strip a TARGET_EXPR in an initialization context
-such as this, but here we do the elision differently: we keep the
-TARGET_EXPR, and use its CONSTRUCTOR as the value of the parm.  */
-  arg = cxx_eval_constant_expression (ctx, x, vc_prvalue,
- non_constant_p, overflow_p);
+   {
+ /* Undo convert_for_arg_passing work here.  */
+ x = convert_from_reference (x);
+ arg = cxx_eval_constant_expression (ctx, x, vc_glvalue,
+ non_constant_p, overflow_p);
+   }
+  else
+   /* Normally we would strip a TARGET_EXPR in an initialization context
+  such as this, but here we do the elision differently: we keep the
+  TARGET_EXPR, and use its CONSTRUCTOR as the value of the parm.  */
+   arg = cxx_eval_constant_expression (ctx, x, vc_prvalue,
+   non_constant_p, overflow_p);
/* Check we aren't dereferencing a null pointer when calling a 
non-static
 member function, which is undefined behaviour.  */
if (i == 0 && DECL_OBJECT_MEMBER_FUNCTION_P (fun)
@@ -1909,7 +1914,16 @@ cxx_bind_parameters_in_call (const const
{
  /* Make sure the binding has the same type as the parm.  But
 only for constant args.  */
- if (!TYPE_REF_P (type))
+ if (TREE_ADDRESSABLE (type))
+   {
+ if (!same_type_p (type, TREE_TYPE (arg)))
+   {
+ arg = build_fold_addr_expr (arg);
+ arg = cp_fold_convert (build_reference_type (type), arg);
+ arg = convert_from_reference (arg);
+   }
+   }
+ else if (!TYPE_REF_P (type))
arg = adjust_temp_type (type, arg);
  if (!TREE_CONSTANT (arg))
*non_constant_args = true;
@@ -7499,9 +7513,19 @@ cxx_eval_constant_expression (const cons
  
  case PARM_DECL:

if (lval && !TYPE_REF_P (TREE_TYPE (t)))
-   /* glvalue use.  */;
+   {
+ /* glvalue use.  */
+ if (TREE_ADDRESSABLE (TREE_TYPE (t)))
+   if (tree v = ctx->global->get_value (t))
+ r = v;
+   }
else if (tree v = ctx->global->get_value (t))
-   r = v;
+   {
+ r = v;
+ if (TREE_ADDRESSABLE (TREE_TYPE (t)))
+   r = cxx_eval_constant_expression (ctx, r, vc_prvalue,
+ non_constant_p, overflow_p);
+   }
else if (lval)
/* Defer in case this is only used for its type.

[PATCH] amdgcn: Add gfx90c target

2024-04-25 Thread Frederik Harwath


Hi Andrew,
this patch adds support for gfx90c GCN5 APU integrated graphics devices.
The LLVM AMDGPU documentation (https://llvm.org/docs/AMDGPUUsage.html)
lists those devices as unsupported by rocm-amdhsa.
As we have discussed elsewhere, I have tested the patch on an AMD Ryzen
5 5500U (also with different xnack settings) that I have and it passes
most libgomp offloading tests.
Although those APUs are very constrainted compared to dGPUs, I think
they might be interesting for learning, experimentation, and testing.


Can I commit the patch to the master branch?

Best regards,
Frederik
From 809e2a0248e6fad1e8336b4a883a729017cc62e5 Mon Sep 17 00:00:00 2001
From: Frederik Harwath 
Date: Wed, 24 Apr 2024 20:29:14 +0200
Subject: [PATCH] amdgcn: Add gfx90c target

Add support for gfx90c GCN5 APU integrated graphics devices.
The LLVM AMDGPU documentation does not list those devices as supported
by rocm-amdhsa, but it passes most libgomp offloading tests.
Although they are constrainted compared to dGPUs, they might be
interesting for learning, experimentation, and testing.

gcc/ChangeLog:

	* config.gcc: Add gfx90c.
	* config/gcn/gcn-hsa.h (NO_SRAM_ECC): Likewise.
	* config/gcn/gcn-opts.h (enum processor_type): Likewise.
	(TARGET_GFX90c): New macro.
	* config/gcn/gcn.cc (gcn_option_override): Handle gfx90c.
	(gcn_omp_device_kind_arch_isa): Likewise.
	(output_file_start): Likewise.
	* config/gcn/gcn.h: Add gfx90c.
	* config/gcn/gcn.opt: Likewise.
	* config/gcn/mkoffload.cc (EF_AMDGPU_MACH_AMDGCN_GFX90c): New macro.
	(get_arch): Handle gfx90c.
	(main): Handle EF_AMDGPU_MACH_AMDGCN_GFX90c
	* config/gcn/t-omp-device: Add gfx90c.
	* doc/install.texi: Likewise.
	* doc/invoke.texi: Likewise.

libgomp/ChangeLog:

	* plugin/plugin-gcn.c (isa_hsa_name): Handle EF_AMDGPU_MACH_AMDGCN_GFX90c.
	(isa_code): Handle gfx90c.
	(max_isa_vgprs): Handle EF_AMDGPU_MACH_AMDGCN_GFX90c.

Signed-off-by: Frederik Harwath 
---
 gcc/config.gcc  | 4 ++--
 gcc/config/gcn/gcn-hsa.h| 2 +-
 gcc/config/gcn/gcn-opts.h   | 2 ++
 gcc/config/gcn/gcn.cc   | 8 
 gcc/config/gcn/gcn.h| 2 ++
 gcc/config/gcn/gcn.opt  | 3 +++
 gcc/config/gcn/mkoffload.cc | 9 +
 gcc/config/gcn/t-omp-device | 2 +-
 gcc/doc/install.texi| 4 ++--
 gcc/doc/invoke.texi | 3 +++
 libgomp/plugin/plugin-gcn.c | 9 +
 11 files changed, 42 insertions(+), 6 deletions(-)

diff --git a/gcc/config.gcc b/gcc/config.gcc
index 5df3c52f8e9..1bf07b6eece 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -4569,7 +4569,7 @@ case "${target}" in
 		for which in arch tune; do
 			eval "val=\$with_$which"
 			case ${val} in
-			"" | fiji | gfx900 | gfx906 | gfx908 | gfx90a | gfx1030 | gfx1036 | gfx1100 | gfx1103)
+			"" | fiji | gfx900 | gfx906 | gfx908 | gfx90a | gfx90c | gfx1030 | gfx1036 | gfx1100 | gfx1103)
 # OK
 ;;
 			*)
@@ -4585,7 +4585,7 @@ case "${target}" in
 			TM_MULTILIB_CONFIG=
 			;;
 		xdefault | xyes)
-			TM_MULTILIB_CONFIG=`echo "gfx900,gfx906,gfx908,gfx90a,gfx1030,gfx1036,gfx1100,gfx1103" | sed "s/${with_arch},\?//;s/,$//"`
+			TM_MULTILIB_CONFIG=`echo "gfx900,gfx906,gfx908,gfx90a,gfx90c,gfx1030,gfx1036,gfx1100,gfx1103" | sed "s/${with_arch},\?//;s/,$//"`
 			;;
 		*)
 			TM_MULTILIB_CONFIG="${with_multilib_list}"
diff --git a/gcc/config/gcn/gcn-hsa.h b/gcc/config/gcn/gcn-hsa.h
index 7d6e3141cea..4611bc55392 100644
--- a/gcc/config/gcn/gcn-hsa.h
+++ b/gcc/config/gcn/gcn-hsa.h
@@ -93,7 +93,7 @@ extern unsigned int gcn_local_sym_hash (const char *name);
 #define NO_XNACK "march=fiji:;march=gfx1030:;march=gfx1036:;march=gfx1100:;march=gfx1103:;" \
 /* These match the defaults set in gcn.cc.  */ \
 "!mxnack*|mxnack=default:%{march=gfx900|march=gfx906|march=gfx908:-mattr=-xnack};"
-#define NO_SRAM_ECC "!march=*:;march=fiji:;march=gfx900:;march=gfx906:;"
+#define NO_SRAM_ECC "!march=*:;march=fiji:;march=gfx900:;march=gfx906:;march=gfx90c:;"
 
 /* In HSACOv4 no attribute setting means the binary supports "any" hardware
configuration.  The name of the attribute also changed.  */
diff --git a/gcc/config/gcn/gcn-opts.h b/gcc/config/gcn/gcn-opts.h
index 49099bad7e7..1091035a69a 100644
--- a/gcc/config/gcn/gcn-opts.h
+++ b/gcc/config/gcn/gcn-opts.h
@@ -25,6 +25,7 @@ enum processor_type
   PROCESSOR_VEGA20,  // gfx906
   PROCESSOR_GFX908,
   PROCESSOR_GFX90a,
+  PROCESSOR_GFX90c,
   PROCESSOR_GFX1030,
   PROCESSOR_GFX1036,
   PROCESSOR_GFX1100,
@@ -36,6 +37,7 @@ enum processor_type
 #define TARGET_VEGA20 (gcn_arch == PROCESSOR_VEGA20)
 #define TARGET_GFX908 (gcn_arch == PROCESSOR_GFX908)
 #define TARGET_GFX90a (gcn_arch == PROCESSOR_GFX90a)
+#define TARGET_GFX90c (gcn_arch == PROCESSOR_GFX90c)
 #define TARGET_GFX1030 (gcn_arch == PROCESSOR_GFX1030)
 #define TARGET_GFX1036 (gcn_arch == PROCESSOR_GFX1036)
 #define TARGET_GFX1100 (gcn_arch == PROCESSOR_GFX1100)
diff --git a/gcc/config/gcn/gcn.cc b/gcc/config/gcn/gcn.cc
index 9f91d4f9ebd..d6531f55190 100644
--- a/gcc/config/gcn/gcn.cc
+++

Re: [PATCH] libgcc: Don't use weakrefs for glibc 2.34

2024-04-25 Thread Richard Biener




> Am 25.04.2024 um 20:24 schrieb Jakub Jelinek :
> 
> Hi!
> 
> glibc 2.34 and later doesn't have separate libpthread (libpthread.so.0 is a
> dummy shared library with just some symbol versions for compatibility, but
> all the pthread_* APIs are in libc.so.6).
> So, we don't need to do the .weakref dances to check whether a program
> has been linked with -lpthread or not, in dynamically linked apps those
> will be always true anyway.
> In -static linking, this fixes various issues people had when only linking
> some parts of libpthread.a and getting weird crashes.  A hack for that was
> what e.g. some Fedora glibcs used, where libpthread.a was a library
> containing just one giant *.o file which had all the normal libpthread.a
> *.o files linked with -r together.
> 
> libstdc++-v3 actually does something like this already since r10-10928,
> the following patch is meant to fix it even for libgfortran, libobjc and
> whatever else uses gthr.h.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux (with glibc 2.35), ok
> for trunk?

Ok

Richard 

> 2024-04-25  Jakub Jelinek  
> 
>* gthr.h (GTHREAD_USE_WEAK): Redefine to 0 for GLIBC 2.34 or later.
> 
> --- libgcc/gthr.h.jj2024-01-03 12:07:28.623363560 +0100
> +++ libgcc/gthr.h2024-04-25 12:09:39.708622613 +0200
> @@ -141,6 +141,15 @@ see the files COPYING3 and COPYING.RUNTI
> #define GTHREAD_USE_WEAK 0
> #endif
> 
> +#ifdef __GLIBC_PREREQ
> +#if __GLIBC_PREREQ(2, 34)
> +/* glibc 2.34 and later has all pthread_* APIs inside of libc,
> +   no need to link separately with -lpthread.  */
> +#undef GTHREAD_USE_WEAK
> +#define GTHREAD_USE_WEAK 0
> +#endif
> +#endif
> +
> #ifndef GTHREAD_USE_WEAK
> #define GTHREAD_USE_WEAK 1
> #endif
> 
>Jakub
>

Re: [PATCH] wwwdocs: contribute.html: Update consensus on patch content.

2024-04-25 Thread Richard Biener




> Am 25.04.2024 um 17:44 schrieb Carlos O'Donell :
> 
> Discussion is here:
> https://inbox.sourceware.org/gcc/CAPS5khZeWkAD=v8ka9g5eecdnk3bdhfnzjumpvc+hedmkvj...@mail.gmail.com/
> 
> Rough consensus from Jakub Jelinek, Richard Biener and others is
> that maintainers are for the change.

Ok

Richard 


> This changes the contribution notes to allow it.
> ---
> htdocs/contribute.html | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/htdocs/contribute.html b/htdocs/contribute.html
> index 7c1ae323..e8137edc 100644
> --- a/htdocs/contribute.html
> +++ b/htdocs/contribute.html
> @@ -195,8 +195,9 @@ of your testing.
> 
> The patch itself
> 
> -Do not include generated files as part of the patch, just mention
> -them in the ChangeLog (e.g., "* configure: Regenerate.").
> +The patch should include everything you are changing (including
> +regenerated files which should be noted in the ChangeLog e.g.
> +"* configure: Regenerate.").
> 
> 
> 
> --
> 2.44.0
>

[PATCH] libgcc: Don't use weakrefs for glibc 2.34

Hi!

glibc 2.34 and later doesn't have separate libpthread (libpthread.so.0 is a
dummy shared library with just some symbol versions for compatibility, but
all the pthread_* APIs are in libc.so.6).
So, we don't need to do the .weakref dances to check whether a program
has been linked with -lpthread or not, in dynamically linked apps those
will be always true anyway.
In -static linking, this fixes various issues people had when only linking
some parts of libpthread.a and getting weird crashes.  A hack for that was
what e.g. some Fedora glibcs used, where libpthread.a was a library
containing just one giant *.o file which had all the normal libpthread.a
*.o files linked with -r together.

libstdc++-v3 actually does something like this already since r10-10928,
the following patch is meant to fix it even for libgfortran, libobjc and
whatever else uses gthr.h.

Bootstrapped/regtested on x86_64-linux and i686-linux (with glibc 2.35), ok
for trunk?

2024-04-25  Jakub Jelinek  

* gthr.h (GTHREAD_USE_WEAK): Redefine to 0 for GLIBC 2.34 or later.

--- libgcc/gthr.h.jj2024-01-03 12:07:28.623363560 +0100
+++ libgcc/gthr.h   2024-04-25 12:09:39.708622613 +0200
@@ -141,6 +141,15 @@ see the files COPYING3 and COPYING.RUNTI
 #define GTHREAD_USE_WEAK 0
 #endif
 
+#ifdef __GLIBC_PREREQ
+#if __GLIBC_PREREQ(2, 34)
+/* glibc 2.34 and later has all pthread_* APIs inside of libc,
+   no need to link separately with -lpthread.  */
+#undef GTHREAD_USE_WEAK
+#define GTHREAD_USE_WEAK 0
+#endif
+#endif
+
 #ifndef GTHREAD_USE_WEAK
 #define GTHREAD_USE_WEAK 1
 #endif

Jakub

[committed] openmp: Copy DECL_LANG_SPECIFIC and DECL_LANG_FLAG_? to tree-nested decl copy [PR114825]

Hi!

tree-nested.cc creates in 2 spots artificial VAR_DECLs, one of them is used
both for debug info and OpenMP/OpenACC lowering purposes, the other solely for
OpenMP/OpenACC lowering purposes.
When the decls are used in OpenMP/OpenACC lowering, the OMP langhooks (mostly
Fortran, C just a little and C++ doesn't have nested functions) then inspect
the flags on the vars and based on that decide how to lower the corresponding
clauses.

Unfortunately we weren't copying DECL_LANG_SPECIFIC and DECL_LANG_FLAG_?, so
the langhooks made decisions on the default flags on those instead.
As the original decl isn't necessarily a VAR_DECL, could be e.g. PARM_DECL,
using copy_node wouldn't work properly, so this patch just copies those
flags in addition to other flags it was copying already.  And I've removed
code duplication by introducing a helper function which does copying common
to both uses.

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

2024-04-25  Jakub Jelinek  

PR fortran/114825
* tree-nested.cc (get_debug_decl): New function.
(get_nonlocal_debug_decl): Use it.
(get_local_debug_decl): Likewise.

* gfortran.dg/gomp/pr114825.f90: New test.

--- gcc/tree-nested.cc.jj   2024-01-29 09:41:19.804391621 +0100
+++ gcc/tree-nested.cc  2024-04-24 18:02:55.103841888 +0200
@@ -1047,6 +1047,37 @@ get_frame_field (struct nesting_info *in
 
 static void note_nonlocal_vla_type (struct nesting_info *info, tree type);
 
+/* Helper for get_nonlocal_debug_decl and get_local_debug_decl.  */
+
+static tree
+get_debug_decl (tree decl)
+{
+  tree new_decl
+= build_decl (DECL_SOURCE_LOCATION (decl),
+ VAR_DECL, DECL_NAME (decl), TREE_TYPE (decl));
+  DECL_ARTIFICIAL (new_decl) = DECL_ARTIFICIAL (decl);
+  DECL_IGNORED_P (new_decl) = DECL_IGNORED_P (decl);
+  TREE_THIS_VOLATILE (new_decl) = TREE_THIS_VOLATILE (decl);
+  TREE_SIDE_EFFECTS (new_decl) = TREE_SIDE_EFFECTS (decl);
+  TREE_READONLY (new_decl) = TREE_READONLY (decl);
+  TREE_ADDRESSABLE (new_decl) = TREE_ADDRESSABLE (decl);
+  DECL_SEEN_IN_BIND_EXPR_P (new_decl) = 1;
+  if ((TREE_CODE (decl) == PARM_DECL
+   || TREE_CODE (decl) == RESULT_DECL
+   || VAR_P (decl))
+  && DECL_BY_REFERENCE (decl))
+DECL_BY_REFERENCE (new_decl) = 1;
+  /* Copy DECL_LANG_SPECIFIC and DECL_LANG_FLAG_* for OpenMP langhook
+ purposes.  */
+  DECL_LANG_SPECIFIC (new_decl) = DECL_LANG_SPECIFIC (decl);
+#define COPY_DLF(n) DECL_LANG_FLAG_##n (new_decl) = DECL_LANG_FLAG_##n (decl)
+  COPY_DLF (0); COPY_DLF (1); COPY_DLF (2); COPY_DLF (3);
+  COPY_DLF (4); COPY_DLF (5); COPY_DLF (6); COPY_DLF (7);
+  COPY_DLF (8);
+#undef COPY_DLF
+  return new_decl;
+}
+
 /* A subroutine of convert_nonlocal_reference_op.  Create a local variable
in the nested function with DECL_VALUE_EXPR set to reference the true
variable in the parent function.  This is used both for debug info
@@ -1094,21 +1125,8 @@ get_nonlocal_debug_decl (struct nesting_
 x = build_simple_mem_ref_notrap (x);
 
   /* ??? We should be remapping types as well, surely.  */
-  new_decl = build_decl (DECL_SOURCE_LOCATION (decl),
-VAR_DECL, DECL_NAME (decl), TREE_TYPE (decl));
+  new_decl = get_debug_decl (decl);
   DECL_CONTEXT (new_decl) = info->context;
-  DECL_ARTIFICIAL (new_decl) = DECL_ARTIFICIAL (decl);
-  DECL_IGNORED_P (new_decl) = DECL_IGNORED_P (decl);
-  TREE_THIS_VOLATILE (new_decl) = TREE_THIS_VOLATILE (decl);
-  TREE_SIDE_EFFECTS (new_decl) = TREE_SIDE_EFFECTS (decl);
-  TREE_READONLY (new_decl) = TREE_READONLY (decl);
-  TREE_ADDRESSABLE (new_decl) = TREE_ADDRESSABLE (decl);
-  DECL_SEEN_IN_BIND_EXPR_P (new_decl) = 1;
-  if ((TREE_CODE (decl) == PARM_DECL
-   || TREE_CODE (decl) == RESULT_DECL
-   || VAR_P (decl))
-  && DECL_BY_REFERENCE (decl))
-DECL_BY_REFERENCE (new_decl) = 1;
 
   SET_DECL_VALUE_EXPR (new_decl, x);
   DECL_HAS_VALUE_EXPR_P (new_decl) = 1;
@@ -1892,21 +1910,8 @@ get_local_debug_decl (struct nesting_inf
   x = info->frame_decl;
   x = build3 (COMPONENT_REF, TREE_TYPE (field), x, field, NULL_TREE);
 
-  new_decl = build_decl (DECL_SOURCE_LOCATION (decl),
-VAR_DECL, DECL_NAME (decl), TREE_TYPE (decl));
+  new_decl = get_debug_decl (decl);
   DECL_CONTEXT (new_decl) = info->context;
-  DECL_ARTIFICIAL (new_decl) = DECL_ARTIFICIAL (decl);
-  DECL_IGNORED_P (new_decl) = DECL_IGNORED_P (decl);
-  TREE_THIS_VOLATILE (new_decl) = TREE_THIS_VOLATILE (decl);
-  TREE_SIDE_EFFECTS (new_decl) = TREE_SIDE_EFFECTS (decl);
-  TREE_READONLY (new_decl) = TREE_READONLY (decl);
-  TREE_ADDRESSABLE (new_decl) = TREE_ADDRESSABLE (decl);
-  DECL_SEEN_IN_BIND_EXPR_P (new_decl) = 1;
-  if ((TREE_CODE (decl) == PARM_DECL
-   || TREE_CODE (decl) == RESULT_DECL
-   || VAR_P (decl))
-  && DECL_BY_REFERENCE (decl))
-DECL_BY_REFERENCE (new_decl) = 1;
 
   SET_DECL_VALUE_EXPR (new_decl, x);
   DECL_HAS_VALUE_EXPR_P (new_decl) = 1;
---

[gcc-13 PATCH 2/2 v3] libstdc++: Add libstdc++_libbacktrace.a to libstdc++exp

On Thu, 18 Apr 2024 at 21:34, Jonathan Wakely wrote:
>
> On Thu, 18 Apr 2024 at 20:51, Jonathan Wakely wrote:
> >
> > This completes the fixes to put all experimental symbols into
> > libstdc++exp.a.
> >
> > On trunk the libstdc++_libbacktrace.a was removed completely and its
> > contents aded to libstdc++exp.a instead. We don't want to do that on the
> > gcc-13 branch because it will break makefiles using it. We can add the
> > contents to libstdc++exp.a and then install a symlink so that
> > -lstdc++_libbacktrace still works, but links to libstdc++exp.a instead.
>
> It looks like simply duplicating all the libstdc___libbacktrace_FOO
> variables in libbacktrace/Makefile.am does work (see attached patch),
> so that we get an installed libstdc++_libbacktrace.a and a
> not-installed libstdc++_libbacktraceconvenience.a which gets included
> into the installed libstdc++exp.a
>
> So if that's preferable to making the installed
> libstdc++_libbacktrace.a a symlink, we can do that.
>
> I still kinda like the symlink approach, because it reduces the size
> on disk, and the same approach could be used to get rid of
> libstdc++fs.a without breaking makefiles using -lstdc++fs

I committed the symlink approach, but with a slightly different patch
(attached).

This one installs libstdc++_libbacktrace.a as a symlink, but also
removes the .la libtool file for that archive, because I don't think
it's any use. I also added an uninstall-local target so the symlink
gets removed.
commit f3cff718df0cf7590ccf9bc1d8cd17e4e08f1e6d
Author: Jonathan Wakely 
Date:   Thu Apr 18 17:26:55 2024

libstdc++: Add libstdc++_libbacktrace.a to libstdc++exp

This completes the fixes to put all experimental symbols into
libstdc++exp.a.

On trunk the libstdc++_libbacktrace.a was removed completely and its
contents aded to libstdc++exp.a instead. We don't want to remove it on
the gcc-13 branch because that would break makefiles using it. We can
add the contents to libstdc++exp.a and then install a symlink so that
using -lstdc++_libbacktrace still works, but links to libstdc++exp.a
instead.

The libstdc++_libbacktrace.la libtool control file is removed by this
change, because I'm pretty sure it's not actually useful, and I don't
know whether it should be a symlink to libstdc++exp.la or a regular file
that refers to libstdc++_libbacktrace.a.

libstdc++-v3/ChangeLog:

* src/experimental/Makefile.am (install-exec-local): New target.
(uninstall-local): New target.
* src/experimental/Makefile.in: Regenerate.
* src/libbacktrace/Makefile.am: Build libstdc++_libbacktrace as
noinst_LTLIBRARIES so it's only a convenience library.
* src/libbacktrace/Makefile.in: Regenerate.

diff --git a/libstdc++-v3/src/experimental/Makefile.am 
b/libstdc++-v3/src/experimental/Makefile.am
index c5a38d882c2..6536e759abd 100644
--- a/libstdc++-v3/src/experimental/Makefile.am
+++ b/libstdc++-v3/src/experimental/Makefile.am
@@ -66,6 +66,15 @@ AM_CXXFLAGS = \
 AM_MAKEFLAGS = \
"gxx_include_dir=$(gxx_include_dir)"
 
+if ENABLE_BACKTRACE
+install-exec-local:
+   -cd '$(DESTDIR)$(toolexeclibdir)' && \
+   $(LN_S) libstdc++exp.a libstdc++_libbacktrace.a
+uninstall-local:
+   -cd '$(DESTDIR)$(toolexeclibdir)' && \
+   rm -f libstdc++_libbacktrace.a
+endif
+
 # Libtool notes
 
 # 1) In general, libtool expects an argument such as `--tag=CXX' when
diff --git a/libstdc++-v3/src/experimental/Makefile.in 
b/libstdc++-v3/src/experimental/Makefile.in
index c16083a7fc8..238c96d9f9a 100644
--- a/libstdc++-v3/src/experimental/Makefile.in
+++ b/libstdc++-v3/src/experimental/Makefile.in
@@ -712,6 +712,8 @@ distclean-generic:
 maintainer-clean-generic:
@echo "This command is intended for maintainers to use"
@echo "it deletes files that may require special tools to rebuild."
+@ENABLE_BACKTRACE_FALSE@install-exec-local:
+@ENABLE_BACKTRACE_FALSE@uninstall-local:
 clean: clean-am
 
 clean-am: clean-generic clean-libtool clean-toolexeclibLTLIBRARIES \
@@ -740,7 +742,7 @@ install-dvi: install-dvi-am
 
 install-dvi-am:
 
-install-exec-am: install-toolexeclibLTLIBRARIES
+install-exec-am: install-exec-local install-toolexeclibLTLIBRARIES
 
 install-html: install-html-am
 
@@ -779,7 +781,7 @@ ps: ps-am
 
 ps-am:
 
-uninstall-am: uninstall-toolexeclibLTLIBRARIES
+uninstall-am: uninstall-local uninstall-toolexeclibLTLIBRARIES
 
 .MAKE: install-am install-strip
 
@@ -789,18 +791,25 @@ uninstall-am: uninstall-toolexeclibLTLIBRARIES
distclean-libtool distclean-tags dvi dvi-am html html-am info \
info-am install install-am install-data install-data-am \
install-dvi install-dvi-am install-exec install-exec-am \
-   install-html install-html-am install-info install-info-am \
-   install-man install-pdf install-pdf-am install-ps \
-   install-ps-am install-strip install-toolexeclibLTLIBRARIES \

Re: [PATCH] bpf: avoid issues with CO-RE and -gtoggle

2024-04-25 Thread Jose E. Marchesi



Hi Faust.
OK.  Thanks for the patch.

> Compiling a BPF program with CO-RE relocations (and BTF) while also
> passing -gtoggle led to an inconsistent state where CO-RE support was
> enabled but BTF would not be generated, and this was not caught by the
> existing option parsing.  This led to an ICE when generating the CO-RE
> relocation info, since BTF is required for CO-RE.
>
> Update bpf_option_override to avoid this case, and add a few tests for
> the interactions of these options.
>
> Tested on x86_64-linux-gnu host for bpf-unknown-none target.
>
> gcc/
>   * config/bpf/bpf.cc (bpf_option_override): Improve handling of CO-RE
>   options to avoid issues with -gtoggle.
>
> gcc/testsuite/
>   * gcc.target/bpf/core-options-1.c: New test.
>   * gcc.target/bpf/core-options-2.c: Likewise.
>   * gcc.target/bpf/core-options-3.c: Likewise.
> ---
>  gcc/config/bpf/bpf.cc |  7 +--
>  gcc/testsuite/gcc.target/bpf/core-options-1.c | 15 +++
>  gcc/testsuite/gcc.target/bpf/core-options-2.c | 14 ++
>  gcc/testsuite/gcc.target/bpf/core-options-3.c |  5 +
>  4 files changed, 39 insertions(+), 2 deletions(-)
>  create mode 100644 gcc/testsuite/gcc.target/bpf/core-options-1.c
>  create mode 100644 gcc/testsuite/gcc.target/bpf/core-options-2.c
>  create mode 100644 gcc/testsuite/gcc.target/bpf/core-options-3.c
>
> diff --git a/gcc/config/bpf/bpf.cc b/gcc/config/bpf/bpf.cc
> index 98fb755bb8b..e6ea211a2c6 100644
> --- a/gcc/config/bpf/bpf.cc
> +++ b/gcc/config/bpf/bpf.cc
> @@ -192,7 +192,8 @@ bpf_option_override (void)
>init_machine_status = bpf_init_machine_status;
>  
>/* BPF CO-RE support requires BTF debug info generation.  */
> -  if (TARGET_BPF_CORE && !btf_debuginfo_p ())
> +  if (TARGET_BPF_CORE
> +  && (!btf_debuginfo_p () || (debug_info_level < DINFO_LEVEL_NORMAL)))
>  error ("BPF CO-RE requires BTF debugging information, use %<-gbtf%>");
>  
>/* BPF applications always generate .BTF.ext.  */
> @@ -215,7 +216,9 @@ bpf_option_override (void)
>  
>/* -gbtf implies -mcore when using the BPF backend, unless -mno-co-re
>   is specified.  */
> -  if (btf_debuginfo_p () && !(target_flags_explicit & MASK_BPF_CORE))
> +  if (btf_debuginfo_p ()
> +  && (debug_info_level >= DINFO_LEVEL_NORMAL)
> +  && !(target_flags_explicit & MASK_BPF_CORE))
>  target_flags |= MASK_BPF_CORE;
>  
>/* Determine available features from ISA setting (-mcpu=).  */
> diff --git a/gcc/testsuite/gcc.target/bpf/core-options-1.c 
> b/gcc/testsuite/gcc.target/bpf/core-options-1.c
> new file mode 100644
> index 000..7d8c677f239
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/bpf/core-options-1.c
> @@ -0,0 +1,15 @@
> +/* -gbtf for the BPF target should enable CO-RE support automatically.  */
> +/* { dg-do compile } */
> +/* { dg-options "-gbtf" } */
> +
> +struct A {
> +  int x;
> +  int y;
> +  char c;
> +};
> +
> +int
> +foo (struct A *a) {
> +  int y = __builtin_preserve_access_index (a->y);
> +  return y;
> +}
> diff --git a/gcc/testsuite/gcc.target/bpf/core-options-2.c 
> b/gcc/testsuite/gcc.target/bpf/core-options-2.c
> new file mode 100644
> index 000..8f466258e29
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/bpf/core-options-2.c
> @@ -0,0 +1,14 @@
> +/* { dg-do compile } */
> +/* { dg-options "-gbtf -gtoggle" } */
> +
> +struct A {
> +  int x;
> +  int y;
> +  char c;
> +};
> +
> +int
> +foo (struct A *a) {
> +  int y = __builtin_preserve_access_index (a->y); /* { dg-error "BPF CO-RE 
> is required" } */
> +  return y;
> +}
> diff --git a/gcc/testsuite/gcc.target/bpf/core-options-3.c 
> b/gcc/testsuite/gcc.target/bpf/core-options-3.c
> new file mode 100644
> index 000..ca32a7c4012
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/bpf/core-options-3.c
> @@ -0,0 +1,5 @@
> +/* This combination of options tries to enable CO-RE without BTF, and should
> +   produce an error.  */
> +/* { dg-do compile } */
> +/* { dg-options "-gbtf -gtoggle -mco-re" } */
> +/* { dg-excess-errors "BPF CO-RE requires BTF debugging information" } */

[committed] libstdc++: Rename man pages to use '::' instead of '_'

Tested x86_64-linux, and docs regenerated. Pushed to trunk.

-- >8 --

The Doxygen-generated man pages for some new types need to be renamed to
use '::' instead of '_' in the filenames.

libstdc++-v3/ChangeLog:

* scripts/run_doxygen: Rename man pages for nested types.
---
 libstdc++-v3/scripts/run_doxygen | 13 +
 1 file changed, 13 insertions(+)

diff --git a/libstdc++-v3/scripts/run_doxygen b/libstdc++-v3/scripts/run_doxygen
index ea9bcb56553..11f24b058af 100644
--- a/libstdc++-v3/scripts/run_doxygen
+++ b/libstdc++-v3/scripts/run_doxygen
@@ -415,8 +415,21 @@ for f in __cxxabiv1_*; do
 mv $f $newname
 done
 
+mv std::__unspecified___exception_ptr.3 std::exception_ptr.3
+
 # Then piecemeal nested classes
 
+for f in std*distribution_param_type.3; do
+newname=`echo $f | sed 
's/distribution_param_type/distribution::param_type/'`
+mv $f $newname
+done
+
+for f in std*filesystem::path_iterator.3; do
+newname=`echo $f | sed 's/path_iterator/path::iterator/'`
+mv $f $newname
+done
+
+mv std::chrono::tzdb_list_const_iterator.3 
std::chrono::tzdb_list::const_iterator.3
 
 # Generic removal bits, where there are things in the generated man
 # pages that need to be killed.
-- 
2.44.0

[committed] libstdc++: Fix run_doxygen for Doxygen 1.10 man page format

Tested x86_64-linux, and docs regenerated. Pushed to trunk.

-- >8 --

Doxygen switched from \fC to \fR in its man page output:
https://github.com/doxygen/doxygen/pull/10497

This breaks our script that expects \fC so change the regaulr expression
to work with either style.

libstdc++-v3/ChangeLog:

* scripts/run_doxygen: Adjust sed pattern to match '\fR' for
new man output that Doxygen 1.10 generates.
---
 libstdc++-v3/scripts/run_doxygen | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/libstdc++-v3/scripts/run_doxygen b/libstdc++-v3/scripts/run_doxygen
index fbd601b11cc..ea9bcb56553 100644
--- a/libstdc++-v3/scripts/run_doxygen
+++ b/libstdc++-v3/scripts/run_doxygen
@@ -294,7 +294,11 @@ $gxx $cppflags $cxxflags 
${srcdir}/doc/doxygen/stdheader.cc -o ./stdheader || ex
 problematic=`grep -E -l '#include <.*h>' [a-z]*.3`
 for f in $problematic; do
 # this is also slow, but safe and easy to debug
-oldh=`sed -n '/fC#include .*/\1/p' $f`
+oldh=`sed -n '/f[CR]#include .*/\1/p' $f`
+if [ "$oldh" == "" ]; then
+  echo "ERROR: Doxygen man page formatting changed" 2>&1
+  continue
+fi
 newh=`echo $oldh | sed 's/&\\././g' | ./stdheader`
 sed "s=${oldh/\\/.}=${newh}=" $f > TEMP && mv TEMP $f
 done
-- 
2.44.0

[committed] libstdc++: Fix typo in Doxygen comment

Tested x86_64-linux, and docs regenerated. Pushed to trunk.

-- >8 --

libstdc++-v3/ChangeLog:

* include/std/chrono (tzdb_list): Fix typo in Doxygen comment.
---
 libstdc++-v3/include/std/chrono | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libstdc++-v3/include/std/chrono b/libstdc++-v3/include/std/chrono
index 3a9751781d2..b0aadf83b03 100644
--- a/libstdc++-v3/include/std/chrono
+++ b/libstdc++-v3/include/std/chrono
@@ -2780,7 +2780,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
   /** Remove the tzdb object _after_ the one the iterator refers to.
*
-   * Calling this function concurently with any of `front()`, `begin()`,
+   * Calling this function concurrently with any of `front()`, `begin()`,
* or `end()` does not cause a data race, but in general this function
* is not thread-safe. The behaviour may be undefined if erasing an
* element from the list while another thread is calling the same
-- 
2.44.0

[committed] libstdc++: Update Doxygen config for new headers

Tested x86_64-linux, and docs regenerated. Pushed to trunk.

-- >8 --

libstdc++-v3/ChangeLog:

* doc/doxygen/stdheader.cc (init_map): Add missing headers.
* doc/doxygen/user.cfg.in (EXCLUDE): Exclude generated files for
std::format and std::text_encoding.
---
 libstdc++-v3/doc/doxygen/stdheader.cc | 42 ---
 libstdc++-v3/doc/doxygen/user.cfg.in  |  6 
 2 files changed, 37 insertions(+), 11 deletions(-)

diff --git a/libstdc++-v3/doc/doxygen/stdheader.cc 
b/libstdc++-v3/doc/doxygen/stdheader.cc
index 67f54eef02b..3ee825feb66 100644
--- a/libstdc++-v3/doc/doxygen/stdheader.cc
+++ b/libstdc++-v3/doc/doxygen/stdheader.cc
@@ -40,19 +40,25 @@ void init_map()
 headers["ranges_algo.h"]= "algorithm";
 headers["ranges_algobase.h"]= "algorithm";
 headers["heap.h"]   = "algorithm";
+headers["chrono_io.h"]  = "chrono";
+headers["parse_numbers.h"]  = "chrono";
 headers["exception_ptr.h"]  = "exception";
 headers["nested_exception.h"]   = "exception";
 headers["fs_dir.h"] = "filesystem";
 headers["fs_fwd.h"] = "filesystem";
 headers["fs_ops.h"] = "filesystem";
 headers["fs_path.h"]= "filesystem";
+headers["unicode.h"]= "format";
+headers["unicode-data.h"]   = "format";
 headers["binders.h"]= "functional";
 headers["function.h"]   = "functional";
 headers["functional_hash.h"]= "functional";
 headers["mofunc_impl.h"]= "functional";
 headers["move_only_function.h"] = "functional";
 headers["invoke.h"] = "functional";
+headers["ranges_cmp.h"] = "functional";
 headers["refwrap.h"]= "functional";
+headers["elements_of.h"]= "generator";
 headers["quoted_string.h"]  = "iomanip";
 headers["ios_base.h"]   = "ios";
 headers["basic_ios.h"]  = "ios";
@@ -64,6 +70,7 @@ void init_map()
 headers["stream_iterator.h"]= "iterator";
 headers["streambuf_iterator.h"] = "iterator";
 headers["iterator_concepts.h"]  = "iterator";
+headers["max_size_type.h"]  = "iterator";
 headers["range_access.h"]   = "iterator";
 headers["codecvt.h"]= "locale";
 headers["c++locale.h"]  = "locale";
@@ -80,9 +87,11 @@ void init_map()
 headers["memoryfwd.h"]  = "memory";
 headers["align.h"]  = "memory";
 headers["alloc_traits.h"]   = "memory";
+headers["allocated_ptr.h"]  = "memory";
 headers["auto_ptr.h"]  = "memory";
 headers["construct.h"]  = "memory";
 headers["allocator.h"]  = "memory";
+headers["new_allocator.h"]  = "memory";
 headers["raw_storage_iter.h"]   = "memory";
 headers["tempbuf.h"]= "memory";
 headers["uninitialized.h"]  = "memory";
@@ -94,11 +103,15 @@ void init_map()
 headers["ptr_traits.h"] = "memory";
 headers["uses_allocator.h"] = "memory";
 headers["uses_allocator_args.h"]= "memory";
+headers["out_ptr.h"]= "memory";
+headers["memory_resource.h"]= "memory_resource";
 headers["unique_lock.h"]= "mutex";
+headers["sat_arith.h"]  = "numeric";
+headers["ostream_insert.h"] = "ostream";
 headers["uniform_int_dist.h"]   = "random";
 headers["ranges_base.h"]= "ranges";
+headers["ranges_to.h"]  = "ranges";
 headers["ranges_util.h"]= "ranges";
-headers["ranges_cmp.h"] = "functional";
 headers["regex_automaton.h"]= "regex";
 headers["regex_automaton.tcc"]  = "regex";
 headers["regex_compiler.h"] = "regex";
@@ -122,6 +135,9 @@ void init_map()
 headers["string_view.tcc"]  = "string_view";
 headers["this_thread_sleep.h"]  = "thread";
 headers["tree.h"]   = "map";
+headers["hashtable.h"]  = "unordered_map";
+headers["hashtable_policy.h"]   = "unordered_map";
+headers["move.h"]   = "utility";
 headers["pair.h"]   = "utility";
 headers["relops.h"] = "utility";
 headers["gslice.h"] = "valarray";
@@ -142,30 +158,34 @@ void init_map()
 headers["abs.h"]= "cstdlib";
 headers["specfun.h"]= "cmath";
 
-// This list is complete as of the October 2021 working draft.
+// This list is complete as of the April 2024 working draft.
 std_headers = {
"algorithm", "any", "array", "atomic",
"barrier", "bit", "bitset",
"charconv", "chrono", "codecvt", "compare",

[committed] libstdc++: Add comment to #include in

Tested x86_64-linux. Pushed to trunk.

-- >8 --

It's not obvious why  needs  so add a
comment to it.

libstdc++-v3/ChangeLog:

* include/std/variant: Add comment to #include.
---
 libstdc++-v3/include/std/variant | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libstdc++-v3/include/std/variant b/libstdc++-v3/include/std/variant
index f79d95db7a8..748e9bae1cb 100644
--- a/libstdc++-v3/include/std/variant
+++ b/libstdc++-v3/include/std/variant
@@ -42,7 +42,7 @@
 #include 
 #include 
 #include 
-#include 
+#include  // _Select_int
 #include 
 #include 
 #include  // in_place_index_t
-- 
2.44.0

Re: [SPARC] Fix PR target/114416

2024-04-25 Thread Eric Botcazou

> For the 20th anniversary of https://gcc.gnu.org/gcc-3.4/sparc-abi.html, a
> new calling convention incompatibility with the vendor compiler (and the
> ABI) has been discovered in 64-bit mode, affecting small structures
> containing arrays of floating-point components.  The decision has been made
> to fix it on Solaris only at this point.

Documented by the attached patch, validated with W3C's Validator and applied.

-- 
Eric Botcazoudiff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
index f0f0efe0..83b1016c 100644
--- a/htdocs/gcc-14/changes.html
+++ b/htdocs/gcc-14/changes.html
@@ -136,7 +136,7 @@ a work-in-progress.
 	int foo (int n)
 	{
 	  int res = 0;
-	  for (int i = 0; i < n; i++)
+	  for (int i = 0; i  n; i++)
 		{
 		   y[i] = x[i] * 2;
 		   res += x[i] + y[i];
@@ -1212,7 +1212,17 @@ __asm (".global __flmap_lock"  "\n\t"
 
 
 
-
+SPARC
+
+
+  
+The implementation of calling conventions for small structures containing
+arrays of floating-point components has been changed in 64-bit mode for
+the Solaris port to match the implementation of the vendor compiler (and
+the ABI). As a result, the code generated will not be binary compatible
+with earlier releases in these cases.
+  
+

[PATCH] bpf: set PREFERRED_DEBUGGING_TYPE to BTF_DEBUG

2024-04-25 Thread David Faust

BTF is the standard debug info used with BPF programs, so it makes sense
to default to BTF rather than DWARF.

Tested on x86_64-linux-gnu host for bpf-unknown-none target.

gcc/
* config/bpf/bpf.h (PREFERRED_DEBUGGING_TYPE): Set to BTF_DEBUG.

gcc/testsuite/
* gcc.target/bpf/bpf-debug-options-1.c: New test.
* gcc.target/bpf/bpf-debug-options-2.c: Likewise.
* gcc.target/bpf/bpf-debug-options-3.c: Likewise.
* gcc.target/bpf/core-options-4.c: Likewise.
---
 gcc/config/bpf/bpf.h   |  5 +
 .../gcc.target/bpf/bpf-debug-options-1.c   | 17 +
 .../gcc.target/bpf/bpf-debug-options-2.c   | 18 ++
 .../gcc.target/bpf/bpf-debug-options-3.c   | 14 ++
 gcc/testsuite/gcc.target/bpf/core-options-4.c  |  4 
 5 files changed, 58 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/bpf/bpf-debug-options-1.c
 create mode 100644 gcc/testsuite/gcc.target/bpf/bpf-debug-options-2.c
 create mode 100644 gcc/testsuite/gcc.target/bpf/bpf-debug-options-3.c
 create mode 100644 gcc/testsuite/gcc.target/bpf/core-options-4.c

diff --git a/gcc/config/bpf/bpf.h b/gcc/config/bpf/bpf.h
index c67e17526bf..e163fbf688d 100644
--- a/gcc/config/bpf/bpf.h
+++ b/gcc/config/bpf/bpf.h
@@ -245,6 +245,11 @@ enum reg_class
 
 / Debugging Info /
 
+/* Use BTF debug info by default.  */
+
+#undef  PREFERRED_DEBUGGING_TYPE
+#define PREFERRED_DEBUGGING_TYPE BTF_DEBUG
+
 /* In eBPF it is not possible to unwind frames. Disable CFA.  */
 
 #define DWARF2_FRAME_INFO 0
diff --git a/gcc/testsuite/gcc.target/bpf/bpf-debug-options-1.c 
b/gcc/testsuite/gcc.target/bpf/bpf-debug-options-1.c
new file mode 100644
index 000..409466c4ead
--- /dev/null
+++ b/gcc/testsuite/gcc.target/bpf/bpf-debug-options-1.c
@@ -0,0 +1,17 @@
+/* Default to BTF debug info.  */
+/* { dg-do compile } */
+/* { dg-options "-g -dA" }*/
+
+struct A {
+  int x;
+  int y;
+};
+
+int
+foo (struct A *a)
+{
+  return a->x;
+}
+
+/* { dg-final { scan-assembler-not "DWARF version" } } */
+/* { dg-final { scan-assembler "btf_version" } } */
diff --git a/gcc/testsuite/gcc.target/bpf/bpf-debug-options-2.c 
b/gcc/testsuite/gcc.target/bpf/bpf-debug-options-2.c
new file mode 100644
index 000..03bde12315b
--- /dev/null
+++ b/gcc/testsuite/gcc.target/bpf/bpf-debug-options-2.c
@@ -0,0 +1,18 @@
+/* -g defaults to BTF, which in turn implies -mco-re.  */
+/* { dg-do compile } */
+/* { dg-options "-g -dA" }*/
+
+struct A {
+  int x;
+  int y;
+};
+
+int
+foo (struct A *a)
+{
+  return __builtin_preserve_access_index (a->x);
+}
+
+/* { dg-final { scan-assembler-not "DWARF version" } } */
+/* { dg-final { scan-assembler "btf_version" } } */
+/* { dg-final { scan-assembler "btfext_version" } } */
diff --git a/gcc/testsuite/gcc.target/bpf/bpf-debug-options-3.c 
b/gcc/testsuite/gcc.target/bpf/bpf-debug-options-3.c
new file mode 100644
index 000..d41790e0928
--- /dev/null
+++ b/gcc/testsuite/gcc.target/bpf/bpf-debug-options-3.c
@@ -0,0 +1,14 @@
+/* Using -g does not incorrectly force CO-RE enabled.  */
+/* { dg-do compile } */
+/* { dg-options "-g -dA -mno-co-re" }*/
+
+struct A {
+  int x;
+  int y;
+};
+
+int
+foo (struct A *a)
+{
+  return __builtin_preserve_access_index (a->x); /* { dg-error "BPF CO-RE is 
required" } */
+}
diff --git a/gcc/testsuite/gcc.target/bpf/core-options-4.c 
b/gcc/testsuite/gcc.target/bpf/core-options-4.c
new file mode 100644
index 000..fde4195da42
--- /dev/null
+++ b/gcc/testsuite/gcc.target/bpf/core-options-4.c
@@ -0,0 +1,4 @@
+/* -g implies BTF, -gtoggle turns it off.  CO-RE should not work.  */
+/* { dg-do compile } */
+/* { dg-options "-g -mco-re -gtoggle" } */
+/* { dg-excess-errors "BPF CO-RE requires BTF debugging information" } */
-- 
2.43.0

[PATCH] bpf: avoid issues with CO-RE and -gtoggle

2024-04-25 Thread David Faust

Compiling a BPF program with CO-RE relocations (and BTF) while also
passing -gtoggle led to an inconsistent state where CO-RE support was
enabled but BTF would not be generated, and this was not caught by the
existing option parsing.  This led to an ICE when generating the CO-RE
relocation info, since BTF is required for CO-RE.

Update bpf_option_override to avoid this case, and add a few tests for
the interactions of these options.

Tested on x86_64-linux-gnu host for bpf-unknown-none target.

gcc/
* config/bpf/bpf.cc (bpf_option_override): Improve handling of CO-RE
options to avoid issues with -gtoggle.

gcc/testsuite/
* gcc.target/bpf/core-options-1.c: New test.
* gcc.target/bpf/core-options-2.c: Likewise.
* gcc.target/bpf/core-options-3.c: Likewise.
---
 gcc/config/bpf/bpf.cc |  7 +--
 gcc/testsuite/gcc.target/bpf/core-options-1.c | 15 +++
 gcc/testsuite/gcc.target/bpf/core-options-2.c | 14 ++
 gcc/testsuite/gcc.target/bpf/core-options-3.c |  5 +
 4 files changed, 39 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/bpf/core-options-1.c
 create mode 100644 gcc/testsuite/gcc.target/bpf/core-options-2.c
 create mode 100644 gcc/testsuite/gcc.target/bpf/core-options-3.c

diff --git a/gcc/config/bpf/bpf.cc b/gcc/config/bpf/bpf.cc
index 98fb755bb8b..e6ea211a2c6 100644
--- a/gcc/config/bpf/bpf.cc
+++ b/gcc/config/bpf/bpf.cc
@@ -192,7 +192,8 @@ bpf_option_override (void)
   init_machine_status = bpf_init_machine_status;
 
   /* BPF CO-RE support requires BTF debug info generation.  */
-  if (TARGET_BPF_CORE && !btf_debuginfo_p ())
+  if (TARGET_BPF_CORE
+  && (!btf_debuginfo_p () || (debug_info_level < DINFO_LEVEL_NORMAL)))
 error ("BPF CO-RE requires BTF debugging information, use %<-gbtf%>");
 
   /* BPF applications always generate .BTF.ext.  */
@@ -215,7 +216,9 @@ bpf_option_override (void)
 
   /* -gbtf implies -mcore when using the BPF backend, unless -mno-co-re
  is specified.  */
-  if (btf_debuginfo_p () && !(target_flags_explicit & MASK_BPF_CORE))
+  if (btf_debuginfo_p ()
+  && (debug_info_level >= DINFO_LEVEL_NORMAL)
+  && !(target_flags_explicit & MASK_BPF_CORE))
 target_flags |= MASK_BPF_CORE;
 
   /* Determine available features from ISA setting (-mcpu=).  */
diff --git a/gcc/testsuite/gcc.target/bpf/core-options-1.c 
b/gcc/testsuite/gcc.target/bpf/core-options-1.c
new file mode 100644
index 000..7d8c677f239
--- /dev/null
+++ b/gcc/testsuite/gcc.target/bpf/core-options-1.c
@@ -0,0 +1,15 @@
+/* -gbtf for the BPF target should enable CO-RE support automatically.  */
+/* { dg-do compile } */
+/* { dg-options "-gbtf" } */
+
+struct A {
+  int x;
+  int y;
+  char c;
+};
+
+int
+foo (struct A *a) {
+  int y = __builtin_preserve_access_index (a->y);
+  return y;
+}
diff --git a/gcc/testsuite/gcc.target/bpf/core-options-2.c 
b/gcc/testsuite/gcc.target/bpf/core-options-2.c
new file mode 100644
index 000..8f466258e29
--- /dev/null
+++ b/gcc/testsuite/gcc.target/bpf/core-options-2.c
@@ -0,0 +1,14 @@
+/* { dg-do compile } */
+/* { dg-options "-gbtf -gtoggle" } */
+
+struct A {
+  int x;
+  int y;
+  char c;
+};
+
+int
+foo (struct A *a) {
+  int y = __builtin_preserve_access_index (a->y); /* { dg-error "BPF CO-RE is 
required" } */
+  return y;
+}
diff --git a/gcc/testsuite/gcc.target/bpf/core-options-3.c 
b/gcc/testsuite/gcc.target/bpf/core-options-3.c
new file mode 100644
index 000..ca32a7c4012
--- /dev/null
+++ b/gcc/testsuite/gcc.target/bpf/core-options-3.c
@@ -0,0 +1,5 @@
+/* This combination of options tries to enable CO-RE without BTF, and should
+   produce an error.  */
+/* { dg-do compile } */
+/* { dg-options "-gbtf -gtoggle -mco-re" } */
+/* { dg-excess-errors "BPF CO-RE requires BTF debugging information" } */
-- 
2.43.0

Re: [gcc-13 PATCH 1/2] libstdc++: Fix libstdc++exp.a so it really does contain Filesystem TS symbols

Pushed to gcc-13

On Thu, 18 Apr 2024 at 20:51, Jonathan Wakely  wrote:
>
> In r14-3812-gb96b554592c5cb I claimed that libstdc++exp.a now contains
> all the symbols from libstdc++fs.a as well as libstdc++_libbacktrace.a,
> but that wasn't true. Only the symbols from the latter were added to
> libstdc++exp.a, the Filesystem TS ones weren't. This seems to be because
> libtool won't combine static libs that are going to be installed
> separately. Because libstdc++fs.a is still installed, libtool decides it
> shouldn't be included in libstdc++exp.a.
>
> The solution is similar to what we already do for libsupc++.a: build two
> static libs, libstdc++fs.a and libstdc++fsconvenience.a, where the
> former is installed and the latter isn't. If we then tell libtool to
> include the latter in libstdc++exp.a it will do as it's told.
>
> libstdc++-v3/ChangeLog:
>
> * src/experimental/Makefile.am: Use libstdc++fsconvenience.a
> instead of libstdc++fs.a.
> * src/experimental/Makefile.in: Regenerate.
> * src/filesystem/Makefile.am: Build libstdc++fsconvenience.a as
> well.
> * src/filesystem/Makefile.in: Regenerate.
>
> (cherry picked from commit abf40d2953639534af3428424f467adf3cb52177)
> ---
>  libstdc++-v3/src/experimental/Makefile.am |  2 +-
>  libstdc++-v3/src/experimental/Makefile.in |  4 +--
>  libstdc++-v3/src/filesystem/Makefile.am   |  4 +++
>  libstdc++-v3/src/filesystem/Makefile.in   | 37 +++
>  4 files changed, 38 insertions(+), 9 deletions(-)
>
> diff --git a/libstdc++-v3/src/experimental/Makefile.am 
> b/libstdc++-v3/src/experimental/Makefile.am
> index 1c7cea7e846..c5a38d882c2 100644
> --- a/libstdc++-v3/src/experimental/Makefile.am
> +++ b/libstdc++-v3/src/experimental/Makefile.am
> @@ -25,7 +25,7 @@ include $(top_srcdir)/fragment.am
>  toolexeclib_LTLIBRARIES = libstdc++exp.la
>
>  if ENABLE_FILESYSTEM_TS
> -filesystem_lib = $(top_builddir)/src/filesystem/libstdc++fs.la
> +filesystem_lib = $(top_builddir)/src/filesystem/libstdc++fsconvenience.la
>  else
>  filesystem_lib =
>  endif
> diff --git a/libstdc++-v3/src/experimental/Makefile.in 
> b/libstdc++-v3/src/experimental/Makefile.in
> index 6f6b742c1cf..c16083a7fc8 100644
> --- a/libstdc++-v3/src/experimental/Makefile.in
> +++ b/libstdc++-v3/src/experimental/Makefile.in
> @@ -148,7 +148,7 @@ am__uninstall_files_from_dir = { \
>}
>  am__installdirs = "$(DESTDIR)$(toolexeclibdir)"
>  LTLIBRARIES = $(toolexeclib_LTLIBRARIES)
> -@ENABLE_FILESYSTEM_TS_TRUE@am__DEPENDENCIES_1 = 
> $(top_builddir)/src/filesystem/libstdc++fs.la
> +@ENABLE_FILESYSTEM_TS_TRUE@am__DEPENDENCIES_1 = 
> $(top_builddir)/src/filesystem/libstdc++fsconvenience.la
>  @ENABLE_BACKTRACE_TRUE@am__DEPENDENCIES_2 = 
> $(top_builddir)/src/libbacktrace/libstdc++_libbacktrace.la
>  am__objects_1 = contract.lo
>  am_libstdc__exp_la_OBJECTS = $(am__objects_1)
> @@ -450,7 +450,7 @@ WARN_CXXFLAGS = \
>  AM_CPPFLAGS = $(GLIBCXX_INCLUDES) $(CPPFLAGS)
>  toolexeclib_LTLIBRARIES = libstdc++exp.la
>  @ENABLE_FILESYSTEM_TS_FALSE@filesystem_lib =
> -@ENABLE_FILESYSTEM_TS_TRUE@filesystem_lib = 
> $(top_builddir)/src/filesystem/libstdc++fs.la
> +@ENABLE_FILESYSTEM_TS_TRUE@filesystem_lib = 
> $(top_builddir)/src/filesystem/libstdc++fsconvenience.la
>  @ENABLE_BACKTRACE_FALSE@backtrace_lib =
>  @ENABLE_BACKTRACE_TRUE@backtrace_lib = 
> $(top_builddir)/src/libbacktrace/libstdc++_libbacktrace.la
>  headers =
> diff --git a/libstdc++-v3/src/filesystem/Makefile.am 
> b/libstdc++-v3/src/filesystem/Makefile.am
> index d2e1fde3f13..55f309b5c15 100644
> --- a/libstdc++-v3/src/filesystem/Makefile.am
> +++ b/libstdc++-v3/src/filesystem/Makefile.am
> @@ -22,7 +22,10 @@
>
>  include $(top_srcdir)/fragment.am
>
> +# Separate libstdc++fs.a to be installed.
>  toolexeclib_LTLIBRARIES = libstdc++fs.la
> +# Duplicate lib that is to be part of libstdc++exp.a
> +noinst_LTLIBRARIES = libstdc++fsconvenience.la
>
>  headers =
>
> @@ -44,6 +47,7 @@ sources = \
>  # vpath % $(top_srcdir)/src/filesystem
>
>  libstdc__fs_la_SOURCES = $(sources)
> +libstdc__fsconvenience_la_SOURCES = $(sources)
>
>  # AM_CXXFLAGS needs to be in each subdirectory so that it can be
>  # modified in a per-library or per-sub-library way.  Need to manually
> diff --git a/libstdc++-v3/src/filesystem/Makefile.in 
> b/libstdc++-v3/src/filesystem/Makefile.in
> index 852390ec1a9..76ba905087b 100644
> --- a/libstdc++-v3/src/filesystem/Makefile.in
> +++ b/libstdc++-v3/src/filesystem/Makefile.in
> @@ -147,7 +147,7 @@ am__uninstall_files_from_dir = { \
>   $(am__cd) "$$dir" && rm -f $$files; }; \
>}
>  am__installdirs = "$(DESTDIR)$(toolexeclibdir)"
> -LTLIBRARIES = $(toolexeclib_LTLIBRARIES)
> +LTLIBRARIES = $(noinst_LTLIBRARIES) $(toolexeclib_LTLIBRARIES)
>  libstdc__fs_la_LIBADD =
>  @ENABLE_DUAL_ABI_TRUE@am__objects_1 = cow-dir.lo cow-ops.lo \
>  @ENABLE_DUAL_ABI_TRUE@ cow-path.lo
> @@ -158,6 +158,10 @@ AM_V_lt = $(am__v_lt_@AM_V@)
>  am__v_lt_ = $(am__v_lt_@AM_DEFAULT_V@)
>

[PATCH] wwwdocs: contribute.html: Update consensus on patch content.

2024-04-25 Thread Carlos O'Donell

Discussion is here:
https://inbox.sourceware.org/gcc/CAPS5khZeWkAD=v8ka9g5eecdnk3bdhfnzjumpvc+hedmkvj...@mail.gmail.com/

Rough consensus from Jakub Jelinek, Richard Biener and others is
that maintainers are for the change.

This changes the contribution notes to allow it.
---
 htdocs/contribute.html | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/htdocs/contribute.html b/htdocs/contribute.html
index 7c1ae323..e8137edc 100644
--- a/htdocs/contribute.html
+++ b/htdocs/contribute.html
@@ -195,8 +195,9 @@ of your testing.
 
 The patch itself
 
-Do not include generated files as part of the patch, just mention
-them in the ChangeLog (e.g., "* configure: Regenerate."). 
+The patch should include everything you are changing (including
+regenerated files which should be noted in the ChangeLog e.g.
+"* configure: Regenerate.").
 
 
 
-- 
2.44.0

[COMMITTED BPF] bpf: default to using pseudo-C assembly syntax by default

2024-04-25 Thread Jose E. Marchesi

At this point the kernel headers that almost all BPF programs use
contain pseudo-C inline assembly and having the GNU toolchain using
the conventional assembly syntax by default would force users to
specify the command-line option explicitly almost all of the time,
which is very inconvenient.

This patch changes GCC in order to recognize and generate the pseudo-C
assembly syntax of BPF by default.  The ASM_SPEC is adapted
accordingly, and in a way that the current release of the BPF
assembler (which still expects conventional assembler syntax by
default) does the right thing.

Tested in bpf-unknown-none-bpf target and x86_64-linux-gnu host.
No regressions.

gcc/ChangeLog

* config/bpf/bpf.opt: Use ASM_PSEUDOC for the default value of
-masm.
* config/bpf/bpf.h (ASM_SPEC): Adapt accordingly.
* doc/invoke.texi (eBPF Options): Update.

gcc/testsuite/ChangeLog

* gcc.target/bpf/alu-1.c: Specify conventional asm dialect.
* gcc.target/bpf/xbpf-indirect-call-1.c: Likewise.
* gcc.target/bpf/sync-fetch-and-add.c: Likewise.
* gcc.target/bpf/smov-2.c: Likewise.
* gcc.target/bpf/smov-1.c: Likewise.
* gcc.target/bpf/smod-1.c: Likewise.
* gcc.target/bpf/sload-1.c: Likewise.
* gcc.target/bpf/sdiv-1.c: Likewise.
* gcc.target/bpf/nop-1.c: Likewise.
* gcc.target/bpf/neg-1.c: Likewise.
* gcc.target/bpf/ldxdw.c: Likewise.
* gcc.target/bpf/jmp-1.c: Likewise.
* gcc.target/bpf/inline-memops-threshold-1.c: Likewise.
* gcc.target/bpf/float-1.c: Likewise.
* gcc.target/bpf/double-2.c: Likewise.
* gcc.target/bpf/double-1.c: Likewise.
* gcc.target/bpf/core-builtin-type-id.c: Likewise.
* gcc.target/bpf/core-builtin-type-based.c: Likewise.
* gcc.target/bpf/core-builtin-fieldinfo-size-1.c: Likewise.
* gcc.target/bpf/core-builtin-fieldinfo-sign-2.c: Likewise.
* gcc.target/bpf/core-builtin-fieldinfo-sign-1.c: Likewise.
* gcc.target/bpf/core-builtin-fieldinfo-rshift-2.c: Likewise.
* gcc.target/bpf/core-builtin-fieldinfo-rshift-1.c: Likewise.
* gcc.target/bpf/core-builtin-fieldinfo-offset-1.c: Likewise.
* gcc.target/bpf/core-builtin-fieldinfo-lshift-2.c: Likewise.
* gcc.target/bpf/core-builtin-fieldinfo-lshift-1-le.c: Likewise.
* gcc.target/bpf/core-builtin-fieldinfo-lshift-1-be.c: Likewise.
* gcc.target/bpf/core-builtin-fieldinfo-existence-1.c: Likewise.
* gcc.target/bpf/core-builtin-fieldinfo-errors-2.c: Likewise.
* gcc.target/bpf/core-builtin-fieldinfo-errors-1.c: Likewise.
* gcc.target/bpf/core-builtin-fieldinfo-const-elimination.c:
Likewise.
* gcc.target/bpf/core-builtin-exprlist-4.c: Likewise.
* gcc.target/bpf/core-builtin-exprlist-3.c: Likewise.
* gcc.target/bpf/core-builtin-exprlist-2.c: Likewise.
* gcc.target/bpf/core-builtin-exprlist-1.c: Likewise.
* gcc.target/bpf/core-builtin-enumvalue-opt.c: Likewise.
* gcc.target/bpf/core-builtin-enumvalue-errors.c: Likewise.
* gcc.target/bpf/core-builtin-enumvalue.c: Likewise.
* gcc.target/bpf/core-builtin-3.c: Likewise.
* gcc.target/bpf/core-builtin-2.c: Likewise.
* gcc.target/bpf/core-builtin-1.c: Likewise.
* gcc.target/bpf/core-attr-struct-as-array.c: Likewise.
* gcc.target/bpf/core-attr-6.c: Likewise.
* gcc.target/bpf/core-attr-5.c: Likewise.
* gcc.target/bpf/core-attr-4.c: Likewise.
* gcc.target/bpf/core-attr-3.c: Likewise.
* gcc.target/bpf/core-attr-2.c: Likewise.
* gcc.target/bpf/core-attr-1.c: Likewise.
* gcc.target/bpf/builtin-load.c: Likewise.
* gcc.target/bpf/btfext-funcinfo-nocore.c: Likewise.
* gcc.target/bpf/btfext-funcinfo.c: Likewise.
* gcc.target/bpf/bswap-1.c: Likewise.
* gcc.target/bpf/bswap-2.c: Likewise.
* gcc.target/bpf/attr-kernel-helper.c: Likewise.
* gcc.target/bpf/atomic-xchg-2.c: Likewise.
* gcc.target/bpf/atomic-xchg-1.c: Likewise.
* gcc.target/bpf/atomic-op-3.c: Likewise.
* gcc.target/bpf/atomic-op-2.c: Likewise.
* gcc.target/bpf/atomic-op-1.c: Likewise.
* gcc.target/bpf/atomic-fetch-op-3.c: Likewise.
* gcc.target/bpf/atomic-fetch-op-2.c: Likewise.
* gcc.target/bpf/atomic-fetch-op-1.c: Likewise.
* gcc.target/bpf/atomic-cmpxchg-2.c: Likewise.
* gcc.target/bpf/atomic-cmpxchg-1.c: Likewise.
* gcc.target/bpf/alu-2.c: Likewise.
---
 gcc/config/bpf/bpf.h  | 4 +++-
 gcc/config/bpf/bpf.opt| 2 +-
 gcc/doc/invoke.texi   | 2 +-
 gcc/testsuite/gcc.target/bpf/alu-1.c  | 2 +-
 gcc/testsuite/gcc.target/bpf/alu-2.c  | 2 +-

Re: [PATCH] c++, v4: Retry the aliasing of base/complete cdtor optimization at import_export_decl time [PR113208]

2024-04-25 Thread Jason Merrill


On 4/25/24 07:22, Jakub Jelinek wrote:

On Thu, Apr 25, 2024 at 02:02:32PM +0200, Jakub Jelinek wrote:

I've tried the following patch, but unfortunately that lead to large
number of regressions:
+FAIL: g++.dg/cpp0x/initlist25.C  -std=c++17 (test for excess errors)


So the reduced testcase for this is
template  struct A {
   T a1;
   U a2;
   template 
   constexpr A(V &, W &) : a1(x), a2(y) {}
};
template  struct B;
namespace std {
template  struct initializer_list {
   int *_M_array;
   decltype (sizeof 0) _M_len;
};
}
template  struct C {
   void foo (std::initializer_list>);
};
template  struct D;
template , typename = B>
struct E { E (const char *); ~E (); };
int
main ()
{
   C, E> m;
   m.foo ({{"t", "t"}, {"y", "y"}});
}
Without the patch I've just posted or even with the earlier version
of the patch the
_ZN1AIK1EIc1DIcE1BIcEES5_EC[12]IRA2_KcSB_Lb1EEEOT_OT0_
ctors were emitted, but with this patch they are unresolved externals.

The reason is that the code actually uses (calls) the
_ZN1AIK1EIc1DIcE1BIcEES5_EC1IRA2_KcSB_Lb1EEEOT_OT0_
__ct_comp constructor, that one has TREE_USED, while the
_ZN1AIK1EIc1DIcE1BIcEES5_EC2IRA2_KcSB_Lb1EEEOT_OT0_
__ct_base constructor is not TREE_USED.

But the c_parse_final_cleanups loop over
FOR_EACH_VEC_SAFE_ELT (deferred_fns, i, decl)
will ignore the TREE_USED __ct_comp because it is an alias
and so has !DECL_SAVED_TREE:
5273  if (!DECL_SAVED_TREE (decl))
5274continue;


Hmm, maybe maybe_clone_body shouldn't clear DECL_SAVED_TREE for aliases, 
but rather set it to some stub like void_node?


Though with all these changes, it's probably better to go with your 
first patch for GCC 14 and delay this approach to 15.  Your v1 patch is 
OK for 14.


Jason

Re: [patch] [gcn][nvptx] Add warning to mkoffload for 32bit host code

2024-04-25 Thread Andrew Stubbs


On 25/04/2024 11:51, Tobias Burnus wrote:

Motivated by a surprise of a colleague that with -m32,
no offload dumps were created; that's because mkoffload
does not process host binaries when the are 32bit (i.e. ilp32).

Internally, that done as follows: The host compiler passes to
'mkoffload' the used host ABI, i.e. -foffload-abi=ilp32 or -foffload-abi=lp64

That's done via TARGET_OFFLOAD_OPTIONS, which is supported by aarch64, i386, 
and rs6000.

While it is sensible (albeit not strictly required) that GCC requires that
the host and device side agree and that only 64bit is implemented for the
device side, it can be confusing that silently no offloading code is generated.


Hence, I propose to print a warning in that case - as implemented in the 
attached patch:

$ gcc -fopenmp -m32 test.c
nvptx mkoffload: warning: offload code generation skipped: offloading with 
32-bit host code is currently not supported
gcn mkoffload: warning: offload code generation skipped: offloading with 32-bit 
host code is currently not supported

* * *

This shouldn't have any effect on offload builds using -m64
and non-offload builds – while several testcases already have
issues with '-m32' when offloading is enabled or an offloading
device is available.

To make it not worse, this patch adds some pruning and for
a subset of the failing testcases, I added code to avoids FAILS.
There are some more fails, but those aren't new.

Comments, remarks, suggestions?
Is the mkoffload.cc part is okay?


The mkoffload part looks reasonable to me. I'm not sure if there are 
other ABIs we might want to warn about, but this is definitely an 
improvement.


Andrew

Re: [PATCH][GCC] aarch64: Fix SCHEDULER_IDENT for Cortex-A510

2024-04-25 Thread Richard Ball

Hi Richard,

I committed this combined patch (with Cortex-A520) for trunk 
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=cab53aae43cf94171b01320c08302e47a5daa391

Am I ok to commit just the Cortex-A510 half into gcc-12 and gcc-13.

Thanks,
Richard Ball

From: Richard Ball
Sent: 12 March 2024 14:08
To: gcc-patches@gcc.gnu.org ; Richard Earnshaw 
; Richard Sandiford ; 
Marcus Shawcroft 
Subject: [PATCH][GCC] aarch64: Fix SCHEDULER_IDENT for Cortex-A510

The SCHEDULER_IDENT for this CPU was incorrectly
set to cortexa55, which is incorrect. This can cause
sub-optimal asm to be generated.

Ok for trunk?

Can I also backport this to gcc-12 and gcc-13?

gcc/ChangeLog:
PR target/114272
* config/aarch64/aarch64-cores.def (AARCH64_CORE):
Change SCHEDULER_IDENT from cortexa55 to cortexa53
for Cortex-A510.

Re: [PATCH] arm: Zero/Sign extends for CMSE security

2024-04-25 Thread Richard Ball

Hi Torbjorn,

Thanks very much for the comments.
I think given that the code that handles this, is within a 
FOREACH_FUNCTION_ARGS loop.
It seems a fairly safe assumption that if the code works for one that it will 
work for all.
To go back and add extra tests to me seems a little overkill.

Kind Regards,
Richard Ball

From: Torbjorn SVENSSON 
Sent: 25 April 2024 12:47
To: Richard Ball ; gcc-patches@gcc.gnu.org 
; Richard Earnshaw ; Richard 
Sandiford ; Marcus Shawcroft 
; Kyrylo Tkachov 
Subject: Re: [PATCH] arm: Zero/Sign extends for CMSE security

Hi,

On 2024-04-24 17:55, Richard Ball wrote:
> This patch makes the following changes:
>
> 1) When calling a secure function from non-secure code then any arguments
> smaller than 32-bits that are passed in registers are zero- or 
> sign-extended.
> 2) After a non-secure function returns into secure code then any return value
> smaller than 32-bits that is passed in a register is  zero- or 
> sign-extended.
>
> This patch addresses the following CVE-2024-0151.
>
> gcc/ChangeLog:
>  PR target/114837
>  * config/arm/arm.cc (cmse_nonsecure_call_inline_register_clear):
>Add zero/sign extend.
>  (arm_expand_prologue): Add zero/sign extend.
>
> gcc/testsuite/ChangeLog:
>
>  * gcc.target/arm/cmse/extend-param.c: New test.
>  * gcc.target/arm/cmse/extend-return.c: New test.

I think it would make sense that there is at least one test case that
takes 2 or more arguments to ensure that not only the first argument is
extended. WDYT?


Kind regards,
Torbjörn

Re: [PATCH] c++, v4: Retry the aliasing of base/complete cdtor optimization at import_export_decl time [PR113208]

On Thu, Apr 25, 2024 at 02:02:32PM +0200, Jakub Jelinek wrote:
> I've tried the following patch, but unfortunately that lead to large
> number of regressions:
> +FAIL: g++.dg/cpp0x/initlist25.C  -std=c++17 (test for excess errors)

So the reduced testcase for this is
template  struct A {
  T a1;
  U a2;
  template 
  constexpr A(V &, W &) : a1(x), a2(y) {}
};
template  struct B;
namespace std {
template  struct initializer_list {
  int *_M_array;
  decltype (sizeof 0) _M_len;
};
}
template  struct C {
  void foo (std::initializer_list>);
};
template  struct D;
template , typename = B>
struct E { E (const char *); ~E (); };
int
main ()
{
  C, E> m;
  m.foo ({{"t", "t"}, {"y", "y"}});
}
Without the patch I've just posted or even with the earlier version
of the patch the
_ZN1AIK1EIc1DIcE1BIcEES5_EC[12]IRA2_KcSB_Lb1EEEOT_OT0_
ctors were emitted, but with this patch they are unresolved externals.

The reason is that the code actually uses (calls) the
_ZN1AIK1EIc1DIcE1BIcEES5_EC1IRA2_KcSB_Lb1EEEOT_OT0_
__ct_comp constructor, that one has TREE_USED, while the
_ZN1AIK1EIc1DIcE1BIcEES5_EC2IRA2_KcSB_Lb1EEEOT_OT0_
__ct_base constructor is not TREE_USED.

But the c_parse_final_cleanups loop over
FOR_EACH_VEC_SAFE_ELT (deferred_fns, i, decl)
will ignore the TREE_USED __ct_comp because it is an alias
and so has !DECL_SAVED_TREE:
5273  if (!DECL_SAVED_TREE (decl))
5274continue;

With the following incremental patch the tests in make check-g++
(haven't tried the coroutine one) which failed with the earlier patch
now pass.

--- gcc/cp/decl2.cc.jj  2024-04-25 10:52:21.057535959 +0200
+++ gcc/cp/decl2.cc 2024-04-25 16:19:17.385547357 +0200
@@ -5271,7 +5271,19 @@ c_parse_final_cleanups (void)
generate_tls_wrapper (decl);
 
  if (!DECL_SAVED_TREE (decl))
-   continue;
+   {
+ cgraph_node *node;
+ tree tgt;
+ /* Even when maybe_clone_body created same body alias
+has no DECL_SAVED_TREE, if its alias target does,
+don't skip it.  */
+ if (!DECL_CLONED_FUNCTION (decl)
+ || !(node = cgraph_node::get (decl))
+ || !node->cpp_implicit_alias
+ || !(tgt = node->get_alias_target_tree ())
+ || !DECL_SAVED_TREE (tgt))
+   continue;
+   }
 
  cgraph_node *node = cgraph_node::get_create (decl);
 
@@ -5299,7 +5311,7 @@ c_parse_final_cleanups (void)
node = node->get_alias_target ();
 
  node->call_for_symbol_thunks_and_aliases (clear_decl_external,
- NULL, true);
+   NULL, true);
  /* If we mark !DECL_EXTERNAL one of the symbols in some comdat
 group, we need to mark all symbols in the same comdat group
 that way.  */
@@ -5309,7 +5321,7 @@ c_parse_final_cleanups (void)
 next != node;
 next = dyn_cast (next->same_comdat_group))
  next->call_for_symbol_thunks_and_aliases (clear_decl_external,
- NULL, true);
+   NULL, true);
}
 
  /* If we're going to need to write this function out, and


Jakub

Re: [PATCH v2 3/3] Add testing cases for flexible array members in unions and alone in structures.




> On Apr 25, 2024, at 10:13, Siddhesh Poyarekar  wrote:
> 
> On 2024-04-25 10:06, Qing Zhao wrote:
>> gcc/testsuite/ChangeLog:
>>  * c-c++-common/fam-in-union-alone-in-struct-1.c: New testcase.
>>  * c-c++-common/fam-in-union-alone-in-struct-2.c: New testcase.
>>  * c-c++-common/fam-in-union-alone-in-struct-3.c: New testcase.
>> ---
> 
> Sorry I should have commented sooner; could you please also add tests for 
> __bos/__bdos for such unions and structs?

Yes, nice suggestion! Will do.

Thanks a lot.

Qing
> 
> Thanks,
> Sid
> 
>>  .../fam-in-union-alone-in-struct-1.c  | 52 +++
>>  .../fam-in-union-alone-in-struct-2.c  | 51 ++
>>  .../fam-in-union-alone-in-struct-3.c  | 36 +
>>  3 files changed, 139 insertions(+)
>>  create mode 100644 
>> gcc/testsuite/c-c++-common/fam-in-union-alone-in-struct-1.c
>>  create mode 100644 
>> gcc/testsuite/c-c++-common/fam-in-union-alone-in-struct-2.c
>>  create mode 100644 
>> gcc/testsuite/c-c++-common/fam-in-union-alone-in-struct-3.c
>> diff --git a/gcc/testsuite/c-c++-common/fam-in-union-alone-in-struct-1.c 
>> b/gcc/testsuite/c-c++-common/fam-in-union-alone-in-struct-1.c
>> new file mode 100644
>> index ..7d4721aa95ac
>> --- /dev/null
>> +++ b/gcc/testsuite/c-c++-common/fam-in-union-alone-in-struct-1.c
>> @@ -0,0 +1,52 @@
>> +/* testing the correct usage of flexible array members in unions
>> +   and alone in structures.  */
>> +/* { dg-do run} */
>> +/* { dg-options "-Wpedantic" } */
>> +
>> +union with_fam_1 {
>> +  int a;
>> +  int b[];  /* { dg-warning "flexible array member in union is a GCC 
>> extension" } */
>> +};
>> +
>> +union with_fam_2 {
>> +  char a;
>> +  int b[];  /* { dg-warning "flexible array member in union is a GCC 
>> extension" } */
>> +};
>> +
>> +union with_fam_3 {
>> +  char a[];  /* { dg-warning "flexible array member in union is a GCC 
>> extension" } */
>> +  /* { dg-warning "in an otherwise empty" "" { target c++ } .-1 } */
>> +  int b[];  /* { dg-warning "flexible array member in union is a GCC 
>> extension" } */
>> +};
>> +
>> +struct only_fam {
>> +  int b[];
>> +  /* { dg-warning "in a struct with no named members" "" { target c } .-1 } 
>> */
>> +  /* { dg-warning "in an otherwise empty" "" { target c++ } .-2 } */
>> +  /* { dg-warning "forbids flexible array member" "" { target c++ } .-3 } */
>> +};
>> +
>> +struct only_fam_2 {
>> +  unsigned int : 2;
>> +  unsigned int : 3;
>> +  int b[];
>> +  /* { dg-warning "in a struct with no named members" "" { target c } .-1 } 
>> */
>> +  /* { dg-warning "in an otherwise empty" "" { target c++ } .-2 } */
>> +  /* { dg-warning "forbids flexible array member" "" { target c++ } .-3 } */
>> +};
>> +
>> +int main ()
>> +{
>> +  if (sizeof (union with_fam_1) != sizeof (int))
>> +__builtin_abort ();
>> +  if (sizeof (union with_fam_2) != __alignof__ (int))
>> +__builtin_abort ();
>> +  if (sizeof (union with_fam_3) != 0)
>> +__builtin_abort ();
>> +  if (sizeof (struct only_fam) != 0)
>> +__builtin_abort ();
>> +  if (sizeof (struct only_fam_2) != sizeof (int))
>> +__builtin_abort ();
>> +  return 0;
>> +}
>> +
>> diff --git a/gcc/testsuite/c-c++-common/fam-in-union-alone-in-struct-2.c 
>> b/gcc/testsuite/c-c++-common/fam-in-union-alone-in-struct-2.c
>> new file mode 100644
>> index ..3743f9e7dac5
>> --- /dev/null
>> +++ b/gcc/testsuite/c-c++-common/fam-in-union-alone-in-struct-2.c
>> @@ -0,0 +1,51 @@
>> +/* testing the correct usage of flexible array members in unions
>> +   and alone in structures: initialization  */
>> +/* { dg-do run} */
>> +/* { dg-options "-O2" } */
>> +
>> +union with_fam_1 {
>> +  int a;
>> +  int b[];
>> +} with_fam_1_v = {.b = {1, 2, 3, 4}};
>> +
>> +union with_fam_2 {
>> +  int a;
>> +  char b[];
>> +} with_fam_2_v = {.a = 0x1f2f3f4f};
>> +
>> +union with_fam_3 {
>> +  char a[];
>> +  int b[];
>> +} with_fam_3_v = {.b = {0x1f2f3f4f, 0x5f6f7f7f}};
>> +
>> +struct only_fam {
>> +  int b[];
>> +} only_fam_v = {{7, 11}};
>> +
>> +struct only_fam_2 {
>> +  unsigned int : 2;
>> +  unsigned int : 3;
>> +  int b[];
>> +} only_fam_2_v = {{7, 11}};
>> +
>> +int main ()
>> +{
>> +  if (with_fam_1_v.b[3] != 4
>> +  || with_fam_1_v.b[0] != 1)
>> +__builtin_abort ();
>> +  if (with_fam_2_v.b[3] != 0x1f
>> +  || with_fam_2_v.b[0] != 0x4f)
>> +__builtin_abort ();
>> +  if (with_fam_3_v.a[0] != 0x4f
>> +  || with_fam_3_v.a[7] != 0x5f)
>> +__builtin_abort ();
>> +  if (only_fam_v.b[0] != 7
>> +  || only_fam_v.b[1] != 11)
>> +__builtin_abort ();
>> +  if (only_fam_2_v.b[0] != 7
>> +  || only_fam_2_v.b[1] != 11)
>> +__builtin_abort ();
>> +
>> +  return 0;
>> +}
>> +
>> diff --git a/gcc/testsuite/c-c++-common/fam-in-union-alone-in-struct-3.c 
>> b/gcc/testsuite/c-c++-common/fam-in-union-alone-in-struct-3.c
>> new file mode 100644
>> index ..dd36fa01306d
>> --- /dev/null
>> +++

Re: [PATCH v1] RISC-V: Revert RVV wv instructions overlap and xfail tests

2024-04-25 Thread Jeff Law

On 4/22/24 4:07 PM, 钟居哲 wrote:

Apologize that we didn't post our (me, kito and Li Pan) disscussions.

This is the story:
We found that my previous patches which support highpart register
overlap with register filter for instructions like (vwadd.wv)

cause ICE reported by:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114714 gcc.gnu.org/bugzilla/show_bug.cgi?id=114714>

and this is obviously a regression (No ICE on GCC 13.2, but ICE on GCC 14)
Just a note for the future, this wouldn't really be considered a
regression since GCC-13 didn't have any vector support. I'm happy to
help with this kind of judgment call, as are many other GCC developers
such as Jakub, Richi, etc. We've been making these kinds of judgment
calls for decades.

We have tried several fixes to work around this ICE, however, we failed.
And also I found my previous patches are quite wrong which is not the
perfect solution to support register group overlap

for vwadd.wv.
So, finally we decide to revert those patches.
It would have been useful to bring others into the discussion. Both
Robin and I would have likely wanted to understand why disabling the
alternative wasn't sufficient.

Looking at this more generally, we need to keep in mind that the closer
we get to a release, the more careful we need to be. We can take the
time to bring more engineers into the technical discussion. We can take
the time to evaluate the pros/cons of different approaches and balance
them against the needs of the upcoming release and other factors that
may come into play.

So let's learn, adjust & move on.

Thanks,
jeff

Re: [PATCH v2 3/3] Add testing cases for flexible array members in unions and alone in structures.

2024-04-25 Thread Siddhesh Poyarekar


On 2024-04-25 10:06, Qing Zhao wrote:

gcc/testsuite/ChangeLog:

* c-c++-common/fam-in-union-alone-in-struct-1.c: New testcase.
* c-c++-common/fam-in-union-alone-in-struct-2.c: New testcase.
* c-c++-common/fam-in-union-alone-in-struct-3.c: New testcase.
---


Sorry I should have commented sooner; could you please also add tests 
for __bos/__bdos for such unions and structs?


Thanks,
Sid


  .../fam-in-union-alone-in-struct-1.c  | 52 +++
  .../fam-in-union-alone-in-struct-2.c  | 51 ++
  .../fam-in-union-alone-in-struct-3.c  | 36 +
  3 files changed, 139 insertions(+)
  create mode 100644 gcc/testsuite/c-c++-common/fam-in-union-alone-in-struct-1.c
  create mode 100644 gcc/testsuite/c-c++-common/fam-in-union-alone-in-struct-2.c
  create mode 100644 gcc/testsuite/c-c++-common/fam-in-union-alone-in-struct-3.c

diff --git a/gcc/testsuite/c-c++-common/fam-in-union-alone-in-struct-1.c 
b/gcc/testsuite/c-c++-common/fam-in-union-alone-in-struct-1.c
new file mode 100644
index ..7d4721aa95ac
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/fam-in-union-alone-in-struct-1.c
@@ -0,0 +1,52 @@
+/* testing the correct usage of flexible array members in unions
+   and alone in structures.  */
+/* { dg-do run} */
+/* { dg-options "-Wpedantic" } */
+
+union with_fam_1 {
+  int a;
+  int b[];  /* { dg-warning "flexible array member in union is a GCC 
extension" } */
+};
+
+union with_fam_2 {
+  char a;
+  int b[];  /* { dg-warning "flexible array member in union is a GCC 
extension" } */
+};
+
+union with_fam_3 {
+  char a[];  /* { dg-warning "flexible array member in union is a GCC 
extension" } */
+  /* { dg-warning "in an otherwise empty" "" { target c++ } .-1 } */
+  int b[];  /* { dg-warning "flexible array member in union is a GCC 
extension" } */
+};
+
+struct only_fam {
+  int b[];
+  /* { dg-warning "in a struct with no named members" "" { target c } .-1 } */
+  /* { dg-warning "in an otherwise empty" "" { target c++ } .-2 } */
+  /* { dg-warning "forbids flexible array member" "" { target c++ } .-3 } */
+};
+
+struct only_fam_2 {
+  unsigned int : 2;
+  unsigned int : 3;
+  int b[];
+  /* { dg-warning "in a struct with no named members" "" { target c } .-1 } */
+  /* { dg-warning "in an otherwise empty" "" { target c++ } .-2 } */
+  /* { dg-warning "forbids flexible array member" "" { target c++ } .-3 } */
+};
+
+int main ()
+{
+  if (sizeof (union with_fam_1) != sizeof (int))
+__builtin_abort ();
+  if (sizeof (union with_fam_2) != __alignof__ (int))
+__builtin_abort ();
+  if (sizeof (union with_fam_3) != 0)
+__builtin_abort ();
+  if (sizeof (struct only_fam) != 0)
+__builtin_abort ();
+  if (sizeof (struct only_fam_2) != sizeof (int))
+__builtin_abort ();
+  return 0;
+}
+
diff --git a/gcc/testsuite/c-c++-common/fam-in-union-alone-in-struct-2.c 
b/gcc/testsuite/c-c++-common/fam-in-union-alone-in-struct-2.c
new file mode 100644
index ..3743f9e7dac5
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/fam-in-union-alone-in-struct-2.c
@@ -0,0 +1,51 @@
+/* testing the correct usage of flexible array members in unions
+   and alone in structures: initialization  */
+/* { dg-do run} */
+/* { dg-options "-O2" } */
+
+union with_fam_1 {
+  int a;
+  int b[];
+} with_fam_1_v = {.b = {1, 2, 3, 4}};
+
+union with_fam_2 {
+  int a;
+  char b[];
+} with_fam_2_v = {.a = 0x1f2f3f4f};
+
+union with_fam_3 {
+  char a[];
+  int b[];
+} with_fam_3_v = {.b = {0x1f2f3f4f, 0x5f6f7f7f}};
+
+struct only_fam {
+  int b[];
+} only_fam_v = {{7, 11}};
+
+struct only_fam_2 {
+  unsigned int : 2;
+  unsigned int : 3;
+  int b[];
+} only_fam_2_v = {{7, 11}};
+
+int main ()
+{
+  if (with_fam_1_v.b[3] != 4
+  || with_fam_1_v.b[0] != 1)
+__builtin_abort ();
+  if (with_fam_2_v.b[3] != 0x1f
+  || with_fam_2_v.b[0] != 0x4f)
+__builtin_abort ();
+  if (with_fam_3_v.a[0] != 0x4f
+  || with_fam_3_v.a[7] != 0x5f)
+__builtin_abort ();
+  if (only_fam_v.b[0] != 7
+  || only_fam_v.b[1] != 11)
+__builtin_abort ();
+  if (only_fam_2_v.b[0] != 7
+  || only_fam_2_v.b[1] != 11)
+__builtin_abort ();
+
+  return 0;
+}
+
diff --git a/gcc/testsuite/c-c++-common/fam-in-union-alone-in-struct-3.c 
b/gcc/testsuite/c-c++-common/fam-in-union-alone-in-struct-3.c
new file mode 100644
index ..dd36fa01306d
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/fam-in-union-alone-in-struct-3.c
@@ -0,0 +1,36 @@
+/* testing the correct usage of flexible array members in unions
+   and alone in structures.  */
+/* { dg-do compile } */
+/* { dg-options "-pedantic-errors" } */
+
+union with_fam_1 {
+  int a;
+  int b[];  /* { dg-error "flexible array member in union is a GCC extension" 
} */
+};
+
+union with_fam_2 {
+  char a;
+  int b[];  /* { dg-error "flexible array member in union is a GCC extension" 
} */
+};
+
+union with_fam_3 {
+  char a[];  /* { dg-error "flexible array member in union is a GCC

[PATCH v2 3/3] Add testing cases for flexible array members in unions and alone in structures.

gcc/testsuite/ChangeLog:

* c-c++-common/fam-in-union-alone-in-struct-1.c: New testcase.
* c-c++-common/fam-in-union-alone-in-struct-2.c: New testcase.
* c-c++-common/fam-in-union-alone-in-struct-3.c: New testcase.
---
 .../fam-in-union-alone-in-struct-1.c  | 52 +++
 .../fam-in-union-alone-in-struct-2.c  | 51 ++
 .../fam-in-union-alone-in-struct-3.c  | 36 +
 3 files changed, 139 insertions(+)
 create mode 100644 gcc/testsuite/c-c++-common/fam-in-union-alone-in-struct-1.c
 create mode 100644 gcc/testsuite/c-c++-common/fam-in-union-alone-in-struct-2.c
 create mode 100644 gcc/testsuite/c-c++-common/fam-in-union-alone-in-struct-3.c

diff --git a/gcc/testsuite/c-c++-common/fam-in-union-alone-in-struct-1.c 
b/gcc/testsuite/c-c++-common/fam-in-union-alone-in-struct-1.c
new file mode 100644
index ..7d4721aa95ac
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/fam-in-union-alone-in-struct-1.c
@@ -0,0 +1,52 @@
+/* testing the correct usage of flexible array members in unions 
+   and alone in structures.  */
+/* { dg-do run} */
+/* { dg-options "-Wpedantic" } */
+
+union with_fam_1 {
+  int a;
+  int b[];  /* { dg-warning "flexible array member in union is a GCC 
extension" } */
+};
+
+union with_fam_2 {
+  char a;
+  int b[];  /* { dg-warning "flexible array member in union is a GCC 
extension" } */
+};
+
+union with_fam_3 {
+  char a[];  /* { dg-warning "flexible array member in union is a GCC 
extension" } */
+  /* { dg-warning "in an otherwise empty" "" { target c++ } .-1 } */
+  int b[];  /* { dg-warning "flexible array member in union is a GCC 
extension" } */
+};
+
+struct only_fam {
+  int b[];
+  /* { dg-warning "in a struct with no named members" "" { target c } .-1 } */
+  /* { dg-warning "in an otherwise empty" "" { target c++ } .-2 } */
+  /* { dg-warning "forbids flexible array member" "" { target c++ } .-3 } */
+};
+
+struct only_fam_2 {
+  unsigned int : 2;
+  unsigned int : 3;
+  int b[];
+  /* { dg-warning "in a struct with no named members" "" { target c } .-1 } */
+  /* { dg-warning "in an otherwise empty" "" { target c++ } .-2 } */
+  /* { dg-warning "forbids flexible array member" "" { target c++ } .-3 } */
+};
+
+int main ()
+{
+  if (sizeof (union with_fam_1) != sizeof (int))
+__builtin_abort ();
+  if (sizeof (union with_fam_2) != __alignof__ (int))
+__builtin_abort ();
+  if (sizeof (union with_fam_3) != 0)
+__builtin_abort ();
+  if (sizeof (struct only_fam) != 0)
+__builtin_abort ();
+  if (sizeof (struct only_fam_2) != sizeof (int))
+__builtin_abort ();
+  return 0;
+}
+
diff --git a/gcc/testsuite/c-c++-common/fam-in-union-alone-in-struct-2.c 
b/gcc/testsuite/c-c++-common/fam-in-union-alone-in-struct-2.c
new file mode 100644
index ..3743f9e7dac5
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/fam-in-union-alone-in-struct-2.c
@@ -0,0 +1,51 @@
+/* testing the correct usage of flexible array members in unions 
+   and alone in structures: initialization  */
+/* { dg-do run} */
+/* { dg-options "-O2" } */
+
+union with_fam_1 {
+  int a;
+  int b[]; 
+} with_fam_1_v = {.b = {1, 2, 3, 4}};
+
+union with_fam_2 {
+  int a;
+  char b[];  
+} with_fam_2_v = {.a = 0x1f2f3f4f};
+
+union with_fam_3 {
+  char a[];  
+  int b[];  
+} with_fam_3_v = {.b = {0x1f2f3f4f, 0x5f6f7f7f}};
+
+struct only_fam {
+  int b[]; 
+} only_fam_v = {{7, 11}};
+
+struct only_fam_2 {
+  unsigned int : 2;
+  unsigned int : 3;
+  int b[]; 
+} only_fam_2_v = {{7, 11}};
+
+int main ()
+{
+  if (with_fam_1_v.b[3] != 4
+  || with_fam_1_v.b[0] != 1)
+__builtin_abort ();
+  if (with_fam_2_v.b[3] != 0x1f
+  || with_fam_2_v.b[0] != 0x4f)
+__builtin_abort ();
+  if (with_fam_3_v.a[0] != 0x4f
+  || with_fam_3_v.a[7] != 0x5f)
+__builtin_abort ();
+  if (only_fam_v.b[0] != 7
+  || only_fam_v.b[1] != 11)
+__builtin_abort ();
+  if (only_fam_2_v.b[0] != 7
+  || only_fam_2_v.b[1] != 11)
+__builtin_abort ();
+
+  return 0;
+}
+
diff --git a/gcc/testsuite/c-c++-common/fam-in-union-alone-in-struct-3.c 
b/gcc/testsuite/c-c++-common/fam-in-union-alone-in-struct-3.c
new file mode 100644
index ..dd36fa01306d
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/fam-in-union-alone-in-struct-3.c
@@ -0,0 +1,36 @@
+/* testing the correct usage of flexible array members in unions 
+   and alone in structures.  */
+/* { dg-do compile } */
+/* { dg-options "-pedantic-errors" } */
+
+union with_fam_1 {
+  int a;
+  int b[];  /* { dg-error "flexible array member in union is a GCC extension" 
} */
+};
+
+union with_fam_2 {
+  char a;
+  int b[];  /* { dg-error "flexible array member in union is a GCC extension" 
} */
+};
+
+union with_fam_3 {
+  char a[];  /* { dg-error "flexible array member in union is a GCC extension" 
} */
+  /* { dg-error "in an otherwise empty" "" { target c++ } .-1 } */
+  int b[];  /* { dg-error "flexible array member in union is a GCC extension" 
} */
+};

[PATCH v2 0/3] Allow flexible array members in unions and alone in structures [PR53548]

Hi,

This is the 2nd version for 
Allow flexible array members in unions and alone in structures [PR53548]

(for your reference, the 1st version is at:
https://gcc.gnu.org/pipermail/gcc-patches/2024-April/649737.html)

compared to the 1st version, the major difference are:

A. C FE updates based on Joseph's comments:

   documentation changes;

   testing case changes; 
   * added testing cases for -pedantic-errors;
   * renamed the testing cases to accurately reflect the covered tests;
   * added unnamed bit-fields along with FAM;
   * move the testing cases to c-c++-common;

B. Merge the 4th patch (old testing adjustment) to the 2nd patch in order to 
   avoid testing regressions if individual patch is tested separately. 

Approval status:

   C FE and documentation changes have been approved for GCC15 with the above 
update A. 
   (Patch 1 and Patch 3 have been approved, the C FE part of Patch 2
has been approved). 

Review needed:

   C++ FE changes (in Patch 2);
   Middle-end changes (in Patch 2);

The patch set includes:
 1. Documentation change.
Allow flexible array members in unions and alone in structures
[PR53548]
 2. C and C++ FE changes to support flexible array members in unions and
   alone in structures.
Adjust testcases for flexible array member in union and alone in
   structure extension.
 3. Add testing cases for flexible array members in unions and alone in
   structures.

bootstrapped and regression tested on both x86 and aarch64, no issue.

Okay for GCC15?

thanks.

Qing

[PATCH v2 2/3] C and C++ FE changes

 to support flexible array members in unions and alone in structures.
 Adjust testcases for flexible array member
 in union and alone in structure extension.

gcc/c/ChangeLog:

* c-decl.cc (finish_struct): Change errors to pedwarns for the cases
flexible array members in union or alone in structures.

gcc/cp/ChangeLog:

* class.cc (diagnose_flexarrays): Change error to pdewarn for the case
flexible array members alone in structures.
* decl.cc (grokdeclarator): Change error to pdewarn for the case
flexible array members in unions.

gcc/ChangeLog:

* stor-layout.cc (place_union_field): Use zero sizes for flexible array
member fields.

gcc/testsuite/ChangeLog:

* c-c++-common/builtin-clear-padding-3.c: Adjust testcase.
* g++.dg/ext/flexary12.C: Likewise.
* g++.dg/ext/flexary19.C: Likewise.
* g++.dg/ext/flexary2.C: Likewise.
* g++.dg/ext/flexary3.C: Likewise.
* g++.dg/ext/flexary36.C: Likewise.
* g++.dg/ext/flexary4.C: Likewise.
* g++.dg/ext/flexary5.C: Likewise.
* g++.dg/ext/flexary8.C: Likewise.
* g++.dg/torture/pr64280.C: Likewise.
* gcc.dg/20050620-1.c: Likewise.
* gcc.dg/940510-1.c: Likewise.
---
 gcc/c/c-decl.cc   | 16 ++
 gcc/cp/class.cc   | 11 ++--
 gcc/cp/decl.cc|  7 ++-
 gcc/stor-layout.cc|  9 +++-
 .../c-c++-common/builtin-clear-padding-3.c| 10 ++--
 gcc/testsuite/g++.dg/ext/flexary12.C  |  6 +--
 gcc/testsuite/g++.dg/ext/flexary19.C  | 42 +++
 gcc/testsuite/g++.dg/ext/flexary2.C   |  2 +-
 gcc/testsuite/g++.dg/ext/flexary3.C   |  2 +-
 gcc/testsuite/g++.dg/ext/flexary36.C  |  2 +-
 gcc/testsuite/g++.dg/ext/flexary4.C   | 54 +--
 gcc/testsuite/g++.dg/ext/flexary5.C   |  4 +-
 gcc/testsuite/g++.dg/ext/flexary8.C   |  8 +--
 gcc/testsuite/g++.dg/torture/pr64280.C|  2 +-
 gcc/testsuite/gcc.dg/20050620-1.c |  2 +-
 gcc/testsuite/gcc.dg/940510-1.c   |  4 +-
 16 files changed, 91 insertions(+), 90 deletions(-)

diff --git a/gcc/c/c-decl.cc b/gcc/c/c-decl.cc
index 345090dae38b..947f3cd589eb 100644
--- a/gcc/c/c-decl.cc
+++ b/gcc/c/c-decl.cc
@@ -9471,11 +9471,8 @@ finish_struct (location_t loc, tree t, tree fieldlist, 
tree attributes,
   if (flexible_array_member_type_p (TREE_TYPE (x)))
{
  if (TREE_CODE (t) == UNION_TYPE)
-   {
- error_at (DECL_SOURCE_LOCATION (x),
-   "flexible array member in union");
- TREE_TYPE (x) = error_mark_node;
-   }
+   pedwarn (DECL_SOURCE_LOCATION (x), OPT_Wpedantic,
+"flexible array member in union is a GCC extension");
  else if (!is_last_field)
{
  error_at (DECL_SOURCE_LOCATION (x),
@@ -9483,12 +9480,9 @@ finish_struct (location_t loc, tree t, tree fieldlist, 
tree attributes,
  TREE_TYPE (x) = error_mark_node;
}
  else if (!saw_named_field)
-   {
- error_at (DECL_SOURCE_LOCATION (x),
-   "flexible array member in a struct with no named "
-   "members");
- TREE_TYPE (x) = error_mark_node;
-   }
+   pedwarn (DECL_SOURCE_LOCATION (x), OPT_Wpedantic,
+"flexible array member in a struct with no named "
+"members is a GCC extension");
}
 
   if (pedantic && TREE_CODE (t) == RECORD_TYPE
diff --git a/gcc/cp/class.cc b/gcc/cp/class.cc
index 5f258729940b..0c8afb72550f 100644
--- a/gcc/cp/class.cc
+++ b/gcc/cp/class.cc
@@ -7624,6 +7624,7 @@ diagnose_flexarrays (tree t, const flexmems_t *fmem)
   bool diagd = false;
 
   const char *msg = 0;
+  const char *msg_fam = 0;
 
   if (TYPE_DOMAIN (TREE_TYPE (fmem->array)))
 {
@@ -7649,15 +7650,19 @@ diagnose_flexarrays (tree t, const flexmems_t *fmem)
   if (fmem->after[0])
msg = G_("flexible array member %qD not at end of %q#T");
   else if (!fmem->first)
-   msg = G_("flexible array member %qD in an otherwise empty %q#T");
+   msg_fam = G_("flexible array member %qD in an otherwise"
+" empty %q#T is a GCC extension");
 
-  if (msg)
+  if (msg || msg_fam)
{
  location_t loc = DECL_SOURCE_LOCATION (fmem->array);
  diagd = true;
 
  auto_diagnostic_group d;
- error_at (loc, msg, fmem->array, t);
+ if (msg)
+   error_at (loc, msg, fmem->array, t);
+ else
+   pedwarn (loc, OPT_Wpedantic, msg_fam, fmem->array, t);
 
  /* In the unlikely event that the member following the flexible
 array member is declared in a different class, or the member
diff --git a/gcc/cp/decl.cc b/gcc/cp/decl.cc
index

[PATCH v2 1/3] Allow flexible array members in unions and alone in structures [PR53548]

The request for GCC to accept that the C99 flexible array member can be
in a union or alone in a structure has been made a long time ago around 2012
for supporting several practical cases including glibc.

A GCC PR has been opened for such request at that time:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53548

However, this PR was closed as WONTFIX around 2015 due to the following reason:

"there is an existing extension that makes the requested functionality possible"
i.e GCC fully supported that the zero-length array can be in a union or alone
in a structure for a long time. (though I didn't see any official documentation
on such extension)

It's reasonable to close PR53548 at that time since zero-length array extension
can be used for such purpose.

However, since GCC13, in order to improve the C/C++ security, we introduced
-fstrict-flex-arrays=n to gradually eliminate the "fake flexible array"
usages from C/C++ source code. As a result, zero-length arrays eventually
will be replaced by C99 flexiable array member completely.

Therefore, GCC needs to explicitly allow such extensions directly for C99
flexible arrays, since flexable array member in unions or alone in structs
are common code patterns in active use by the Linux kernel (and other projects).

For example, these do not error by default with GCC:

union one {
  int a;
  int b[0];
};

union two {
  int a;
  struct {
struct { } __empty;
int b[];
  };
};

But these do:

union three {
  int a;
  int b[];
};

struct four {
  int b[];
}

Clang has supported such extensions since March, 2024
https://github.com/llvm/llvm-project/pull/84428

GCC should also support such extensions. This will allow for
a seamless transition for code bases away from zero-length arrays without
losing existing code patterns.

gcc/ChangeLog:

* doc/extend.texi: Add documentation for Flexible Array Members in
Unions and Flexible Array Members alone in Structures.
---
 gcc/doc/extend.texi | 34 ++
 1 file changed, 34 insertions(+)

diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 7b54a241a7bf..cba98c8aadd7 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -42,6 +42,8 @@ extensions, accepted by GCC in C90 mode and in C++.
 * Named Address Spaces::Named address spaces.
 * Zero Length:: Zero-length arrays.
 * Empty Structures::Structures with no members.
+* Flexible Array Members in Unions::  Unions with Flexible Array Members.
+* Flexible Array Members alone in Structures::  Structures with only Flexible 
Array Members.
 * Variable Length:: Arrays whose length is computed at run time.
 * Variadic Macros:: Macros with a variable number of arguments.
 * Escaped Newlines::Slightly looser rules for escaped newlines.
@@ -1873,6 +1875,38 @@ The structure has size zero.  In C++, empty structures 
are part
 of the language.  G++ treats empty structures as if they had a single
 member of type @code{char}.
 
+@node Flexible Array Members in Unions
+@section Unions with Flexible Array Members
+@cindex unions with flexible array members
+@cindex unions with FAMs
+
+GCC permits a C99 flexible array member (FAM) to be in a union:
+
+@smallexample
+union with_fam @{
+  int a;
+  int b[];
+@};
+@end smallexample
+
+If all the members of a union are flexible array member, the size of
+such union is zero.
+
+@node Flexible Array Members alone in Structures
+@section Structures with only Flexible Array Members
+@cindex structures with only flexible array members
+@cindex structures with only FAMs
+
+GCC permits a C99 flexible array member (FAM) to be alone in a structure:
+
+@smallexample
+struct only_fam @{
+  int b[];
+@};
+@end smallexample
+
+The size of such structure gives the size zero.
+
 @node Variable Length
 @section Arrays of Variable Length
 @cindex variable-length arrays
-- 
2.31.1

[PATCH] tree-optimization/114792 - order loops to unloops in CH

2024-04-25 Thread Richard Biener


When we use unloop_loops we have to make sure to have loops ordered
inner to outer as otherwise we can wreck inner loop structure where
unlooping relies on that being intact.  The following re-sorts the
vector of to unloop loops after copy-header as that adds to the
vector in two places and the wrong order.

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

PR tree-optimization/114792
* tree-ssa-loop-ch.cc (ch_order_loops): New function.
(ch_base::copy_headers): Sort loops to unloop inner-to-outer.

* gcc.dg/torture/pr114792.c: New testcase.
---
 gcc/testsuite/gcc.dg/torture/pr114792.c | 16 
 gcc/tree-ssa-loop-ch.cc | 25 +
 2 files changed, 41 insertions(+)
 create mode 100644 gcc/testsuite/gcc.dg/torture/pr114792.c

diff --git a/gcc/testsuite/gcc.dg/torture/pr114792.c 
b/gcc/testsuite/gcc.dg/torture/pr114792.c
new file mode 100644
index 000..4990e76eb2a
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/torture/pr114792.c
@@ -0,0 +1,16 @@
+/* { dg-do compile } */
+/* { dg-additional-options "-fno-tree-ccp -fno-tree-copy-prop" } */
+
+int a;
+int main() {
+  int b = -1, c;
+  for (; b >= 0; b++) {
+for (c = 0; c; c++) {
+L:
+  while (a)
+if (a)
+  goto L;
+}
+  }
+  return 0;
+}
diff --git a/gcc/tree-ssa-loop-ch.cc b/gcc/tree-ssa-loop-ch.cc
index b7ef485c4cc..d7dd3e5459d 100644
--- a/gcc/tree-ssa-loop-ch.cc
+++ b/gcc/tree-ssa-loop-ch.cc
@@ -759,6 +759,21 @@ protected:
   bool process_loop_p (class loop *loop) final override;
 }; // class pass_ch_vect

+/* Sort comparator to order loops after the specified order.  */
+
+static int
+ch_order_loops (const void *a_, const void *b_, void *order_)
+{
+  int *order = (int *)order_;
+  const class loop *a = *(const class loop * const *)a_;
+  const class loop *b = *(const class loop * const *)b_;
+  if (a->num == b->num)
+return 0;
+  if (order[a->num] < order[b->num])
+return -1;
+  return 1;
+}
+
 /* For all loops, copy the condition at the end of the loop body in front
of the loop.  This is beneficial since it increases efficiency of
code motion optimizations.  It also saves one jump on entry to the loop.  */
@@ -1152,6 +1167,16 @@ ch_base::copy_headers (function *fun)
 }
   if (!loops_to_unloop.is_empty ())
 {
+  /* Make sure loops are ordered inner to outer for unlooping.  */
+  if (loops_to_unloop.length () != 1)
+   {
+ auto_vec order;
+ order.safe_grow (number_of_loops (cfun), true);
+ int i = 0;
+ for (auto loop : loops_list (cfun, LI_FROM_INNERMOST))
+   order[loop->num] = i++;
+ loops_to_unloop.sort (ch_order_loops, order.address ());
+   }
   bool irred_invalidated;
   auto_bitmap lc_invalidated;
   auto_vec edges_to_remove;
--
2.25.1

Re: [wwwdocs] Porting-to-14: Mention new pragma GCC Target behavior

On Thu, Apr 25, 2024 at 02:34:22PM +0200, Martin Jambor wrote:
> when looking at a package build issue with GCC 14, Michal Jireš noted a
> different behavior of pragma GCC Target.  This snippet tries to describe
> the gist of the problem.  I have left it in the C section even though it
> is not really C specific, but could not think of a good name for a new
> section for it.  Ideas (and any other suggestions for improvements)
> welcome, of course.

The change was more subtle.
We used to define/undefine the ISA macros in C in GCC 13 and older as well,
but only when using integrated preprocessor during compilation,
so it didn't work that way with -save-temps or separate -E and -S/-c
steps.
While in C++ it behaved as if the define/undefines aren't done at all
(they were done, but after preprocessing/lexing everything, so didn't
affect anything).
In GCC 14, it behaves in C++ the same as in C in older versions, and
additionally they are defined/undefined also when using separate
preprocessing, in both C and C++.

Jakub

[wwwdocs] Porting-to-14: Mention new pragma GCC Target behavior

2024-04-25 Thread Martin Jambor

Hello,

when looking at a package build issue with GCC 14, Michal Jireš noted a
different behavior of pragma GCC Target.  This snippet tries to describe
the gist of the problem.  I have left it in the C section even though it
is not really C specific, but could not think of a good name for a new
section for it.  Ideas (and any other suggestions for improvements)
welcome, of course.

Otherwise, would this be good to go to the wwwdocs?

Thanks,

Martin

diff --git a/htdocs/gcc-14/porting_to.html b/htdocs/gcc-14/porting_to.html
index c825a68e..ae9a3cde 100644
--- a/htdocs/gcc-14/porting_to.html
+++ b/htdocs/gcc-14/porting_to.html
@@ -490,6 +490,43 @@ in C23.
 GCC will probably continue to support old-style function definitions
 even once C23 is used as the default language dialect.
 
+Pragma GCC Target now affects preprocessor 
symbols
+
+
+The behavior of pragma GCC Target has changed in GCC 14.  For example,
+GCC 13 and below defines __AVX2__ only when the target
+is specified on the command line.  This has been considered https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87299;>a
+bug and since it was fixed in GCC 14, __AVX2__ is now also
+defined with #pragma GCC target("avx2").
+
+
+Therefore, if macros expand to something like the snippet below,
+functions will be (silently) compiled for an incorrect instruction
+set.
+
+
+  #if ! __AVX2__
+  #pragma GCC push_options
+  #pragma GCC target("avx2")
+  #endif
+
+  /* Code to be compiled for AVX2. */
+
+  /* With GCC 14, __AVX2__ here will always be defined and pop_options
+  never called. */
+  #if ! __AVX2__
+  #pragma GCC pop_options
+  #endif
+
+  /* With GCC 14, all following functions will be compiled for AVX2
+  which was not intended. */
+
+
+
+The fix in this case would be to remember
+whether pop_options needs to be performed in a new
+user-defined macro.
+
 C++ language issues
 
 Header dependency changes

Re: [PATCH] RISC-V: Add testcase for PR114749.

2024-04-25 Thread juzhe.zh...@rivai.ai

LGTM



juzhe.zh...@rivai.ai
 
From: Robin Dapp
Date: 2024-04-25 19:23
To: gcc-patches
CC: rdapp.gcc; palmer; Kito Cheng; juzhe.zh...@rivai.ai; jeffreyalaw; Patrick 
O'Neill
Subject: [PATCH] RISC-V: Add testcase for PR114749.
Hi,
 
this adds a test case for PR114749.
Going to commit as obvious unless somebody complains.
 
Regards
Robin
 
gcc/testsuite/ChangeLog:
 
PR tree-optimization/114749
 
* gcc.target/riscv/rvv/autovec/pr114749.c: New test.
---
.../gcc.target/riscv/rvv/autovec/pr114749.c   | 15 +++
1 file changed, 15 insertions(+)
create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/autovec/pr114749.c
 
diff --git a/gcc/testsuite/gcc.target/riscv/rvv/autovec/pr114749.c 
b/gcc/testsuite/gcc.target/riscv/rvv/autovec/pr114749.c
new file mode 100644
index 000..6733b0481a6
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/rvv/autovec/pr114749.c
@@ -0,0 +1,15 @@
+/* { dg-do compile } */
+/* { dg-options "-march=rv64gcv_zvl128b -mabi=lp64d -fwhole-program -O3 
-mrvv-vector-bits=zvl" } */
+
+extern int a[];
+extern char b[];
+int c = 24;
+_Bool d[24][24][24];
+_Bool (*e)[24][24] = d;
+int main() {
+  for (short f = 0; f < 24; f += 3)
+for (unsigned g = 0; g < (char)c; g += 2) {
+  a[f] = 0;
+  b[g] |= ({ e[f][f][f]; });
+}
+}
-- 
2.44.0

[PATCH] c++, v4: Retry the aliasing of base/complete cdtor optimization at import_export_decl time [PR113208]

On Wed, Apr 24, 2024 at 08:43:46PM -0400, Jason Merrill wrote:
> > Then can_alias_cdtor would return false, because it ends with:
> >/* Don't use aliases for weak/linkonce definitions unless we can put both
> >   symbols in the same COMDAT group.  */
> >return (DECL_INTERFACE_KNOWN (fn)
> >&& (SUPPORTS_ONE_ONLY || !DECL_WEAK (fn))
> >&& (!DECL_ONE_ONLY (fn)
> >|| (HAVE_COMDAT_GROUP && DECL_WEAK (fn;
> > Should we change that DECL_INTERFACE_KNOWN (fn) in there to
> > (DECL_INTERFACE_KNOWN (fn) || something) then and what that
> > something should be?  HAVE_COMDAT_GROUP && DECL_ONE_ONLY (fn)?
> 
> Yes, I think reorganize to
> 
> ((DECL_INTERFACE_KNOWN (fn) && !DECL_WEAK (fn) && !DECL_ONE_ONLY (fn))
>  || (HAVE_COMDAT_GROUP && DECL_ONE_ONLY (fn))

I've tried the following patch, but unfortunately that lead to large
number of regressions:
+FAIL: g++.dg/coroutines/torture/co-yield-04-complex-local-state.C (test for 
excess errors)
+FAIL: g++.dg/coroutines/torture/func-params-08.C (test for excess errors)
+FAIL: g++.dg/coroutines/torture/func-params-09-awaitable-parms.C (test for 
excess errors)
+FAIL: g++.dg/cpp0x/constexpr-initlist.C  -std=c++11 (test for excess errors)
+FAIL: g++.dg/cpp0x/constexpr-initlist.C  -std=c++14 (test for excess errors)
+FAIL: g++.dg/cpp0x/constexpr-initlist.C  -std=c++17 (test for excess errors)
+FAIL: g++.dg/cpp0x/constexpr-initlist.C  -std=c++20 (test for excess errors)
+FAIL: g++.dg/cpp0x/constexpr-initlist.C  -std=c++23 (test for excess errors)
+FAIL: g++.dg/cpp0x/constexpr-initlist.C  -std=c++26 (test for excess errors)
+FAIL: g++.dg/cpp0x/initlist25.C  -std=c++11 (test for excess errors)
+FAIL: g++.dg/cpp0x/initlist25.C  -std=c++14 (test for excess errors)
+FAIL: g++.dg/cpp0x/initlist25.C  -std=c++17 (test for excess errors)
+FAIL: g++.dg/cpp0x/initlist25.C  -std=c++20 (test for excess errors)
+FAIL: g++.dg/cpp0x/initlist25.C  -std=c++23 (test for excess errors)
+FAIL: g++.dg/cpp0x/initlist25.C  -std=c++26 (test for excess errors)
+FAIL: g++.dg/cpp1y/pr95226.C  -std=c++20 (test for excess errors)
+FAIL: g++.dg/cpp1y/pr95226.C  -std=c++23 (test for excess errors)
+FAIL: g++.dg/cpp1y/pr95226.C  -std=c++26 (test for excess errors)
+FAIL: g++.dg/cpp1z/decomp12.C  -std=c++23 (test for excess errors)
+FAIL: g++.dg/cpp1z/decomp12.C  -std=c++26 (test for excess errors)
+FAIL: g++.dg/cpp1z/eval-order2.C  -std=c++20 (test for excess errors)
+FAIL: g++.dg/cpp1z/eval-order2.C  -std=c++23 (test for excess errors)
+FAIL: g++.dg/cpp1z/eval-order2.C  -std=c++26 (test for excess errors)
+FAIL: g++.dg/cpp2a/srcloc17.C  -std=c++20 (test for excess errors)
+FAIL: g++.dg/cpp2a/srcloc17.C  -std=c++23 (test for excess errors)
+FAIL: g++.dg/cpp2a/srcloc17.C  -std=c++26 (test for excess errors)
+FAIL: g++.old-deja/g++.jason/template31.C  -std=c++20 (test for excess errors)
+FAIL: g++.old-deja/g++.jason/template31.C  -std=c++23 (test for excess errors)
+FAIL: g++.old-deja/g++.jason/template31.C  -std=c++26 (test for excess errors)
+FAIL: 20_util/unique_ptr/creation/for_overwrite.cc  -std=gnu++26 (test for 
excess errors)
+FAIL: 23_containers/span/cons_1_assert_neg.cc  -std=gnu++20 (test for excess 
errors)
+FAIL: 23_containers/span/cons_1_assert_neg.cc  -std=gnu++26 (test for excess 
errors)
+FAIL: 23_containers/span/cons_2_assert_neg.cc  -std=gnu++20 (test for excess 
errors)
+FAIL: 23_containers/span/cons_2_assert_neg.cc  -std=gnu++26 (test for excess 
errors)
+FAIL: std/ranges/repeat/1.cc  -std=gnu++23 (test for excess errors)
+FAIL: std/ranges/repeat/1.cc  -std=gnu++26 (test for excess errors)

Errors are like:
func-params-08.C:(.text._ZNSt12_Vector_baseIiSaIiEEC2Ev[_ZNSt12_Vector_baseIiSaIiEEC5Ev]+0x14):
 undefined reference to 
`_ZNSt12_Vector_baseIiSaIiEE12_Vector_implC1EvQ26is_default_constructible_vIN9__gnu_cxx14__alloc_traitsIT0_NS5_10value_typeEE6rebindIT_E5otherEE'
Though, libstdc++.so.6 abilist is the same.
Trying to debug it now.

2024-04-24  Jakub Jelinek  
Jason Merrill  

PR lto/113208
* decl2.cc (tentative_decl_linkage): Call maybe_make_one_only
for implicit instantiations of maybe in charge ctors/dtors
declared inline.
* optimize.cc (can_alias_cdtor): Adjust condition, for
HAVE_COMDAT_GROUP && DECL_ONE_ONLY && DECL_WEAK return true even
if not DECL_INTERFACE_KNOWN.
* decl.cc (cxx_comdat_group): For DECL_CLONED_FUNCTION_P
functions if SUPPORTS_ONE_ONLY return DECL_COMDAT_GROUP if already
set.

* g++.dg/abi/comdat2.C: New test.
* g++.dg/abi/comdat3.C: New test.
* g++.dg/abi/comdat4.C: New test.
* g++.dg/abi/comdat5.C: New test.
* g++.dg/lto/pr113208_0.C: New test.
* g++.dg/lto/pr113208_1.C: New file.
* g++.dg/lto/pr113208.h: New file.

--- gcc/cp/decl2.cc.jj  2024-04-24 18:28:22.299513620 +0200
+++ gcc/cp/decl2.cc 2024-04-25 10:04:18.049476567 +0200
@@ -3312,16 +3312,23 @@

Re: [PATCH] arm: Zero/Sign extends for CMSE security

2024-04-25 Thread Torbjorn SVENSSON


Hi,

On 2024-04-24 17:55, Richard Ball wrote:

This patch makes the following changes:

1) When calling a secure function from non-secure code then any arguments
smaller than 32-bits that are passed in registers are zero- or 
sign-extended.
2) After a non-secure function returns into secure code then any return value
smaller than 32-bits that is passed in a register is  zero- or 
sign-extended.

This patch addresses the following CVE-2024-0151.

gcc/ChangeLog:
 PR target/114837
 * config/arm/arm.cc (cmse_nonsecure_call_inline_register_clear):
   Add zero/sign extend.
 (arm_expand_prologue): Add zero/sign extend.

gcc/testsuite/ChangeLog:

 * gcc.target/arm/cmse/extend-param.c: New test.
 * gcc.target/arm/cmse/extend-return.c: New test.


I think it would make sense that there is at least one test case that 
takes 2 or more arguments to ensure that not only the first argument is 
extended. WDYT?



Kind regards,
Torbjörn

[PATCH] libcpp: Adjust __STDC_VERSION__ for C23