[PATCH] Remove m_nloops field from loop_versioning

[Andrew Pinski]

This is a small cleanup of loop_versioning where m_nloops
is only used in the constructor so we can remove the whole
field.

Bootstrapped and tested on x86_64-linux-gnu.

gcc/ChangeLog:

* gimple-loop-versioning.cc (loop_versioning): Remove m_nloops field.
(loop_versioning::loop_versioning): Remove initialization of
m_nloops field and move it to be a local variable.
(loop_versioning::analyze_blocks): Fix formating.
---
 gcc/gimple-loop-versioning.cc | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/gcc/gimple-loop-versioning.cc b/gcc/gimple-loop-versioning.cc
index 17877f06921..adea207659b 100644
--- a/gcc/gimple-loop-versioning.cc
+++ b/gcc/gimple-loop-versioning.cc
@@ -322,9 +322,6 @@ private:
   /* An obstack to use for general allocation.  */
   obstack m_obstack;
 
-  /* The number of loops in the function.  */
-  unsigned int m_nloops;
-
   /* The total number of loop version conditions we've found.  */
   unsigned int m_num_conditions;
 
@@ -525,10 +522,10 @@ loop_versioning::name_prop::value_of_expr (tree val, 
gimple *)
 
 loop_versioning::loop_versioning (function *fn)
   : m_fn (fn),
-m_nloops (number_of_loops (fn)),
 m_num_conditions (0),
 m_address_table (31)
 {
+  unsigned m_nloops = number_of_loops (fn);
   bitmap_obstack_initialize (&m_bitmap_obstack);
   gcc_obstack_init (&m_obstack);
 
@@ -1437,7 +1434,7 @@ loop_versioning::analyze_blocks ()
  {
linfo.rejected_p = true;
break;
-   }
+ }
 
  if (!linfo.rejected_p)
{
-- 
2.43.0

Pushed: [PATCH] LoongArch: Add constraints for bit string operation define_insn_and_split's [PR114861]

[Xi Ruoyao]

On Sat, 2024-04-27 at 11:04 +0800, Lulu Cheng wrote:
> LGTM!
> 
> Thanks.

Pushed r15-11 and r14-10142.

> 在 2024/4/26 下午9:52, Xi Ruoyao 写道:
> > Without the constrants, the compiler attempts to use a stack slot as the
> > target, causing an ICE building the kernel with -Os:
> > 
> >  drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c:3144:1:
> >  error: could not split insn
> >  (insn:TI 1764 67 1745
> >    (set (mem/c:DI (reg/f:DI 3 $r3) [707 %sfp+-80 S8 A64])
> >     (and:DI (reg/v:DI 28 $r28 [orig:422 raster_config ] [422])
> >     (const_int -50331649 [0xfcff])))
> >    "drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c":1386:21 111
> >    {*bstrins_di_for_mask}
> >    (nil))
> > 
> > Add these constrants to fix the issue.
> > 
> > gcc/ChangeLog:
> > 
> > PR target/114861
> > * config/loongarch/loongarch.md (bstrins__for_mask): Add
> > constraints for operands.
> > (bstrins__for_ior_mask): Likewise.
> > 
> > gcc/testsuite/ChangeLog:
> > 
> > PR target/114861
> > * gcc.target/loongarch/pr114861.c: New test.
> > ---
> >   gcc/config/loongarch/loongarch.md | 16 
> >   gcc/testsuite/gcc.target/loongarch/pr114861.c | 39 +++
> >   2 files changed, 47 insertions(+), 8 deletions(-)
> >   create mode 100644 gcc/testsuite/gcc.target/loongarch/pr114861.c
> > 
> > diff --git a/gcc/config/loongarch/loongarch.md 
> > b/gcc/config/loongarch/loongarch.md
> > index a316c8fb820..5c80c169cbf 100644
> > --- a/gcc/config/loongarch/loongarch.md
> > +++ b/gcc/config/loongarch/loongarch.md
> > @@ -1543,9 +1543,9 @@ (define_insn "and3_extended"
> >  (set_attr "mode" "")])
> >   
> >   (define_insn_and_split "*bstrins__for_mask"
> > -  [(set (match_operand:GPR 0 "register_operand")
> > -   (and:GPR (match_operand:GPR 1 "register_operand")
> > -(match_operand:GPR 2 "ins_zero_bitmask_operand")))]
> > +  [(set (match_operand:GPR 0 "register_operand" "=r")
> > +   (and:GPR (match_operand:GPR 1 "register_operand" "r")
> > +(match_operand:GPR 2 "ins_zero_bitmask_operand" "i")))]
> >     ""
> >     "#"
> >     ""
> > @@ -1563,11 +1563,11 @@ (define_insn_and_split "*bstrins__for_mask"
> >     })
> >   
> >   (define_insn_and_split "*bstrins__for_ior_mask"
> > -  [(set (match_operand:GPR 0 "register_operand")
> > -   (ior:GPR (and:GPR (match_operand:GPR 1 "register_operand")
> > -  (match_operand:GPR 2 "const_int_operand"))
> > -(and:GPR (match_operand:GPR 3 "register_operand")
> > -     (match_operand:GPR 4 "const_int_operand"]
> > +  [(set (match_operand:GPR 0 "register_operand" "=r")
> > +   (ior:GPR (and:GPR (match_operand:GPR 1 "register_operand" "r")
> > +     (match_operand:GPR 2 "const_int_operand" "i"))
> > +(and:GPR (match_operand:GPR 3 "register_operand" "r")
> > +     (match_operand:GPR 4 "const_int_operand" "i"]
> >     "loongarch_pre_reload_split ()
> >  && loongarch_use_bstrins_for_ior_with_mask (mode, operands)"
> >     "#"
> > diff --git a/gcc/testsuite/gcc.target/loongarch/pr114861.c 
> > b/gcc/testsuite/gcc.target/loongarch/pr114861.c
> > new file mode 100644
> > index 000..e6507c406b9
> > --- /dev/null
> > +++ b/gcc/testsuite/gcc.target/loongarch/pr114861.c
> > @@ -0,0 +1,39 @@
> > +/* PR114861: ICE building the kernel with -Os
> > +   Reduced from linux/fs/ntfs3/attrib.c at revision c942a0cd3603.  */
> > +/* { dg-do compile } */
> > +/* { dg-options "-Os -march=loongarch64 -msoft-float -mabi=lp64s" } */
> > +
> > +long evcn, attr_collapse_range_vbo, attr_collapse_range_bytes;
> > +unsigned short flags;
> > +int attr_collapse_range_ni_0_0;
> > +int *attr_collapse_range_mi;
> > +unsigned attr_collapse_range_svcn, attr_collapse_range_vcn1;
> > +void ni_insert_nonresident (unsigned, unsigned short, int **);
> > +int mi_pack_runs (int);
> > +int
> > +attr_collapse_range (void)
> > +{
> > +  _Bool __trans_tmp_1;
> > +  int run = attr_collapse_range_ni_0_0;
> > +  unsigned evcn1, vcn, end;
> > +  short a_flags = flags;
> > +  __trans_tmp_1 = flags & (32768 | 1);
> > +  if (__trans_tmp_1)
> > +    return 2;
> > +  vcn = attr_collapse_range_vbo;
> > +  end = attr_collapse_range_bytes;
> > +  evcn1 = evcn;
> > +  for (;;)
> > +    if (attr_collapse_range_svcn >= end)
> > +  {
> > +    unsigned eat, next_svcn = mi_pack_runs (42);
> > +    attr_collapse_range_vcn1 = (vcn ? vcn : attr_collapse_range_svcn);
> > +    eat = (0 < end) - attr_collapse_range_vcn1;
> > +    mi_pack_runs (run - eat);
> > +    if (next_svcn + eat)
> > +  ni_insert_nonresident (evcn1 - eat - next_svcn, a_flags,
> > + &attr_collapse_range_mi);
> > +  }
> > +    else
> > +  return 42;
> > +}
> 

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

Re: [PATCH] LoongArch: Add constraints for bit string operation define_insn_and_split's [PR114861]

[Lulu Cheng]

LGTM!

Thanks.

在 2024/4/26 下午9:52, Xi Ruoyao 写道:

Without the constrants, the compiler attempts to use a stack slot as the
target, causing an ICE building the kernel with -Os:

 drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c:3144:1:
 error: could not split insn
 (insn:TI 1764 67 1745
   (set (mem/c:DI (reg/f:DI 3 $r3) [707 %sfp+-80 S8 A64])
(and:DI (reg/v:DI 28 $r28 [orig:422 raster_config ] [422])
(const_int -50331649 [0xfcff])))
   "drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c":1386:21 111
   {*bstrins_di_for_mask}
   (nil))

Add these constrants to fix the issue.

gcc/ChangeLog:

PR target/114861
* config/loongarch/loongarch.md (bstrins__for_mask): Add
constraints for operands.
(bstrins__for_ior_mask): Likewise.

gcc/testsuite/ChangeLog:

PR target/114861
* gcc.target/loongarch/pr114861.c: New test.
---
  gcc/config/loongarch/loongarch.md | 16 
  gcc/testsuite/gcc.target/loongarch/pr114861.c | 39 +++
  2 files changed, 47 insertions(+), 8 deletions(-)
  create mode 100644 gcc/testsuite/gcc.target/loongarch/pr114861.c

diff --git a/gcc/config/loongarch/loongarch.md 
b/gcc/config/loongarch/loongarch.md
index a316c8fb820..5c80c169cbf 100644
--- a/gcc/config/loongarch/loongarch.md
+++ b/gcc/config/loongarch/loongarch.md
@@ -1543,9 +1543,9 @@ (define_insn "and3_extended"
 (set_attr "mode" "")])
  
  (define_insn_and_split "*bstrins__for_mask"

-  [(set (match_operand:GPR 0 "register_operand")
-   (and:GPR (match_operand:GPR 1 "register_operand")
-(match_operand:GPR 2 "ins_zero_bitmask_operand")))]
+  [(set (match_operand:GPR 0 "register_operand" "=r")
+   (and:GPR (match_operand:GPR 1 "register_operand" "r")
+(match_operand:GPR 2 "ins_zero_bitmask_operand" "i")))]
""
"#"
""
@@ -1563,11 +1563,11 @@ (define_insn_and_split "*bstrins__for_mask"
})
  
  (define_insn_and_split "*bstrins__for_ior_mask"

-  [(set (match_operand:GPR 0 "register_operand")
-   (ior:GPR (and:GPR (match_operand:GPR 1 "register_operand")
-  (match_operand:GPR 2 "const_int_operand"))
-(and:GPR (match_operand:GPR 3 "register_operand")
- (match_operand:GPR 4 "const_int_operand"]
+  [(set (match_operand:GPR 0 "register_operand" "=r")
+   (ior:GPR (and:GPR (match_operand:GPR 1 "register_operand" "r")
+ (match_operand:GPR 2 "const_int_operand" "i"))
+(and:GPR (match_operand:GPR 3 "register_operand" "r")
+ (match_operand:GPR 4 "const_int_operand" "i"]
"loongarch_pre_reload_split ()
 && loongarch_use_bstrins_for_ior_with_mask (mode, operands)"
"#"
diff --git a/gcc/testsuite/gcc.target/loongarch/pr114861.c 
b/gcc/testsuite/gcc.target/loongarch/pr114861.c
new file mode 100644
index 000..e6507c406b9
--- /dev/null
+++ b/gcc/testsuite/gcc.target/loongarch/pr114861.c
@@ -0,0 +1,39 @@
+/* PR114861: ICE building the kernel with -Os
+   Reduced from linux/fs/ntfs3/attrib.c at revision c942a0cd3603.  */
+/* { dg-do compile } */
+/* { dg-options "-Os -march=loongarch64 -msoft-float -mabi=lp64s" } */
+
+long evcn, attr_collapse_range_vbo, attr_collapse_range_bytes;
+unsigned short flags;
+int attr_collapse_range_ni_0_0;
+int *attr_collapse_range_mi;
+unsigned attr_collapse_range_svcn, attr_collapse_range_vcn1;
+void ni_insert_nonresident (unsigned, unsigned short, int **);
+int mi_pack_runs (int);
+int
+attr_collapse_range (void)
+{
+  _Bool __trans_tmp_1;
+  int run = attr_collapse_range_ni_0_0;
+  unsigned evcn1, vcn, end;
+  short a_flags = flags;
+  __trans_tmp_1 = flags & (32768 | 1);
+  if (__trans_tmp_1)
+return 2;
+  vcn = attr_collapse_range_vbo;
+  end = attr_collapse_range_bytes;
+  evcn1 = evcn;
+  for (;;)
+if (attr_collapse_range_svcn >= end)
+  {
+unsigned eat, next_svcn = mi_pack_runs (42);
+attr_collapse_range_vcn1 = (vcn ? vcn : attr_collapse_range_svcn);
+eat = (0 < end) - attr_collapse_range_vcn1;
+mi_pack_runs (run - eat);
+if (next_svcn + eat)
+  ni_insert_nonresident (evcn1 - eat - next_svcn, a_flags,
+ &attr_collapse_range_mi);
+  }
+else
+  return 42;
+}

Re: [PATCH v3 2/2] c++: Fix instantiation of imported temploid friends [PR114275]

[Jason Merrill]

On 4/19/24 09:29, Nathaniel Shead wrote:

On Fri, Apr 19, 2024 at 12:14:06PM +1000, Nathaniel Shead wrote:

On Wed, Apr 17, 2024 at 02:02:21PM -0400, Patrick Palka wrote:

On Mon, 15 Apr 2024, Nathaniel Shead wrote:


I'm not a huge fan of always streaming 'imported_temploid_friends' for
all decls, but I don't think it adds much performance cost over adding a
new flag to categorise decls that might be marked as such.


IIUC this value is going to be almost always null which is encoded as a
single 0 byte, which should be fast to stream.  But I wonder how much
larger  gets?  Can we get away with streaming this value
only for TEMPLATE_DECLs?


Yes, it should either just be a 0 byte or an additional backref
somewhere, which will likely also be small. On my system it increases
the size by 0.26%, from 31186800 bytes to 31268672.

But I've just found that this patch has a bug anyway, in that it doesn't
correctly dedup if the friend types are instantiated in two separate
modules that are then both imported.  I'll see what I need to do to fix
this which may influence what we need to stream here.



Here's an updated version of the patch that fixes this. Also changed to
only stream when 'inner' is either TYPE_DECL or FUNCTION_DECL, which
cuts the size of  down a bit to 31246992 (0.19% growth).

Another alternative would be to add another boolean flag at the top of
'decl_value' and branch on that; that would make use of the bitpacking
logic and probably cut down on the size further.  (I haven't measured
this yet though.)

Bootstrapped and regtested (so far just dg.exp and modules.exp) on
x86_64-pc-linux-gnu, OK for trunk if full regtest succeeds?

-- >8 --

This patch fixes a number of issues with the handling of temploid friend
declarations.

The primary issue is that instantiations of friend declarations should
attach the declaration to the same module as the befriending class, by
[module.unit] p7.1 and [temp.friend] p2; this could be a different
module from the current TU, and so needs special handling.


This is only an issue for DECL_UNINSTANTIATED_TEMPLATE_FRIEND_P, right?

Hmm, CWG2588 should probably touch [module.unit]/7.1 as well as 
[basic.link].



The other main issue here is that we can't assume that just because name
lookup didn't find a definition for a hidden template class, it doesn't
mean that it doesn't exist: it could be a non-exported entity that we've
nevertheless streamed in from an imported module.  We need to ensure
that when instantiating friend classes that we return the same TYPE_DECL
that we got from our imports, otherwise we will get later issues with
'duplicate_decls' (rightfully) complaining that they're different.


Tricksy.


This doesn't appear necessary for functions due to the existing name
lookup handling already finding these hidden declarations.

PR c++/105320
PR c++/114275

gcc/cp/ChangeLog:

* cp-tree.h (propagate_defining_module): Declare.
(lookup_imported_hidden_friend): Declare.
* decl.cc (duplicate_decls): Also check if hidden declarations
can be redeclared in this module.
* module.cc (imported_temploid_friends): New map.
(init_modules): Initialize it.
(trees_out::decl_value): Write it; don't consider imported
temploid friends as attached to this module.
(trees_in::decl_value): Read it.
(depset::hash::add_specializations): Don't treat instantiations
of a friend type as a specialisation.
(get_originating_module_decl): Follow the owning decl for an
imported temploid friend.
(propagate_defining_module): New function.
* name-lookup.cc (lookup_imported_hidden_friend): New function.
* pt.cc (tsubst_friend_function): Propagate defining module for
new friend functions.
(tsubst_friend_class): Lookup imported hidden friends. Check
for valid redeclaration. Propagate defining module for new
friend classes.

diff --git a/gcc/cp/decl.cc b/gcc/cp/decl.cc
index aa66da4829d..56752cf6872 100644
--- a/gcc/cp/decl.cc
+++ b/gcc/cp/decl.cc
@@ -2276,30 +2276,34 @@ duplicate_decls (tree newdecl, tree olddecl, bool 
hiding, bool was_hidden)
  
if (modules_p ()

&& TREE_CODE (CP_DECL_CONTEXT (olddecl)) == NAMESPACE_DECL
-  && TREE_CODE (olddecl) != NAMESPACE_DECL
-  && !hiding)
+  && TREE_CODE (olddecl) != NAMESPACE_DECL)
  {
if (!module_may_redeclare (olddecl, newdecl))
return error_mark_node;
  
-  tree not_tmpl = STRIP_TEMPLATE (olddecl);

-  if (DECL_LANG_SPECIFIC (not_tmpl)
- && DECL_MODULE_ATTACH_P (not_tmpl)
- /* Typedefs are not entities and so are OK to be redeclared
-as exported: see [module.interface]/p6.  */
- && TREE_CODE (olddecl) != TYPE_DECL)
+  if (!hiding)
{
- if (DECL_MODULE_EXPORT_P (STRIP_TEMPLATE (newdecl))
- && !DECL_MODULE_EXPORT_P (not_tmpl))
+ /* Hidden friend declaration

Re: [PATCH] RISC-V: Add -X to link spec

[Kito Cheng]

LGTM :)

Fangrui Song  於 2024年4月23日 週二 12:27 寫道：

> From: Fangrui Song 
>
> --discard-locals (-X) instructs the linker to remove local .L* symbols,
> which occur a lot due to label differences for linker relaxation. The
> arm port has a similar need and passes -X to ld.
>
> In contrast, the RISC-V port does not pass -X to ld and rely on the
> default --discard-locals in GNU ld's riscv port. The arm way is more
> conventional (compiler driver instead of the linker customizes the
> default behavior) and works with lld.
> ---
>  gcc/config/riscv/elf.h | 1 +
>  gcc/config/riscv/freebsd.h | 1 +
>  gcc/config/riscv/linux.h   | 1 +
>  3 files changed, 3 insertions(+)
>
> diff --git a/gcc/config/riscv/elf.h b/gcc/config/riscv/elf.h
> index f533764d9f8..c97f13c0cca 100644
> --- a/gcc/config/riscv/elf.h
> +++ b/gcc/config/riscv/elf.h
> @@ -20,6 +20,7 @@ along with GCC; see the file COPYING3.  If not see
>  #define LINK_SPEC "\
>  -melf" XLEN_SPEC DEFAULT_ENDIAN_SPEC "riscv \
>  %{mno-relax:--no-relax} \
> +-X \
>  %{mbig-endian:-EB} \
>  %{mlittle-endian:-EL} \
>  %{shared}"
> diff --git a/gcc/config/riscv/freebsd.h b/gcc/config/riscv/freebsd.h
> index bd08a985285..5dd4d51c42b 100644
> --- a/gcc/config/riscv/freebsd.h
> +++ b/gcc/config/riscv/freebsd.h
> @@ -44,6 +44,7 @@ along with GCC; see the file COPYING3.  If not see
>%{p:%nconsider using `-pg' instead of `-p' with gprof (1)}   \
>%{v:-V}  \
>%{assert*} %{R*} %{rpath*} %{defsym*}\
> +  -X   \
>%{mbig-endian:-EB}   \
>%{mlittle-endian:-EL}\
>%{shared:-Bshareable %{h*} %{soname*}}   \
> diff --git a/gcc/config/riscv/linux.h b/gcc/config/riscv/linux.h
> index 15851f653bc..3c356227134 100644
> --- a/gcc/config/riscv/linux.h
> +++ b/gcc/config/riscv/linux.h
> @@ -50,6 +50,7 @@ along with GCC; see the file COPYING3.  If not see
>  #define LINK_SPEC "\
>  -melf" XLEN_SPEC DEFAULT_ENDIAN_SPEC "riscv" LD_EMUL_SUFFIX " \
>  %{mno-relax:--no-relax} \
> +-X \
>  %{mbig-endian:-EB} \
>  %{mlittle-endian:-EL} \
>  %{shared} \
> --
> 2.44.0.769.g3c40516874-goog
>
>

[PATCH] arm: [MVE intrinsics] Fix support for predicate constants [PR target/114801]

[Christophe Lyon]

In this PR, we have to handle a case where MVE predicates are supplied
as a const_int, where individual predicates have illegal boolean
values (such as 0xc for a 4-bit boolean predicate).  To avoid the ICE,
we canonicalize them, replacing a non-null value with -1.

2024-04-26  Christophe Lyon  
Jakub Jelinek  

PR target/114801
gcc/
* config/arm/arm-mve-builtins.cc
(function_expander::add_input_operand): Handle CONST_INT
predicates.

gcc/testsuite/
* gcc.target/arm/mve/pr114801.c: New test.
---
 gcc/config/arm/arm-mve-builtins.cc  | 21 +++-
 gcc/testsuite/gcc.target/arm/mve/pr114801.c | 36 +
 2 files changed, 56 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.target/arm/mve/pr114801.c

diff --git a/gcc/config/arm/arm-mve-builtins.cc 
b/gcc/config/arm/arm-mve-builtins.cc
index 6a5775c67e5..f338ab36434 100644
--- a/gcc/config/arm/arm-mve-builtins.cc
+++ b/gcc/config/arm/arm-mve-builtins.cc
@@ -43,6 +43,7 @@
 #include "stringpool.h"
 #include "attribs.h"
 #include "diagnostic.h"
+#include "rtx-vector-builder.h"
 #include "arm-protos.h"
 #include "arm-builtins.h"
 #include "arm-mve-builtins.h"
@@ -2205,7 +2206,25 @@ function_expander::add_input_operand (insn_code icode, 
rtx x)
   mode = GET_MODE (x);
 }
   else if (VALID_MVE_PRED_MODE (mode))
-x = gen_lowpart (mode, x);
+{
+  if (CONST_INT_P (x) && (mode == V8BImode || mode == V4BImode))
+   {
+ /* In V8BI or V4BI each element has 2 or 4 bits, if those
+bits aren't all the same, it is UB and gen_lowpart might
+ICE.  Canonicalize all the 2 or 4 bits to all ones if any
+of them is non-zero.  */
+ unsigned HOST_WIDE_INT xi = UINTVAL (x);
+ xi |= ((xi & 0x) << 1) | ((xi & 0x) >> 1);
+ if (mode == V4BImode)
+   xi |= ((xi & 0x) << 2) | ((xi & 0x) >> 2);
+ x = gen_int_mode (xi, HImode);
+   }
+  else if (SUBREG_P (x))
+   /* gen_lowpart on a SUBREG can ICE.  */
+   x = force_reg (GET_MODE (x), x);
+
+  x = gen_lowpart (mode, x);
+}
 
   m_ops.safe_grow (m_ops.length () + 1, true);
   create_input_operand (&m_ops.last (), x, mode);
diff --git a/gcc/testsuite/gcc.target/arm/mve/pr114801.c 
b/gcc/testsuite/gcc.target/arm/mve/pr114801.c
new file mode 100644
index 000..676b109f9b8
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/mve/pr114801.c
@@ -0,0 +1,36 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target arm_v8_1m_mve_ok } */
+/* { dg-add-options arm_v8_1m_mve } */
+/* { dg-final { check-function-bodies "**" "" "" } } */
+
+#include 
+
+/*
+** test_32:
+**...
+** mov r[0-9]+, #65535 @ movhi
+**...
+*/
+uint32x4_t test_32() {
+  return vdupq_m_n_u32(vdupq_n_u32(0), 0, 0x);
+}
+
+/*
+** test_16:
+**...
+** mov r[0-9]+, #52428 @ movhi
+**...
+*/
+uint16x8_t test_16() {
+  return vdupq_m_n_u16(vdupq_n_u16(0), 0, 0x);
+}
+
+/*
+** test_8:
+**...
+** mov r[0-9]+, #52428 @ movhi
+**...
+*/
+uint8x16_t test_8() {
+  return vdupq_m_n_u8(vdupq_n_u8(0), 0, 0x);
+}
-- 
2.34.1

[PATCH 1/2] Add verification of gimple_assign_nontemporal_move_p [PR112976]

[Andrew Pinski]

Currently the middle-end only knows how to support temporal stores
(the undocumented storent optab) so let's verify that the only time
we set nontemporal_move on an assign is if the the lhs is not a
gimple reg.

Bootstrapped and tested on x86_64-linux-gnu no regressions.

gcc/ChangeLog:

PR middle-end/112976
* tree-cfg.cc (verify_gimple_assign): Verify that
nontmporal moves are stores.
* gimple.h (struct gimple): Note that only
nontemporal stores are supported.

Signed-off-by: Andrew Pinski 
---
 gcc/gimple.h|  3 ++-
 gcc/tree-cfg.cc | 11 +++
 2 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/gcc/gimple.h b/gcc/gimple.h
index 8a8ca109bbf..bd315ffc2dd 100644
--- a/gcc/gimple.h
+++ b/gcc/gimple.h
@@ -236,7 +236,8 @@ struct GTY((desc ("gimple_statement_structure (&%h)"), tag 
("GSS_BASE"),
  for clearing this bit before using it.  */
   unsigned int visited : 1;
 
-  /* Nonzero if this tuple represents a non-temporal move.  */
+  /* Nonzero if this tuple represents a non-temporal move; currently
+ only stores are supported.  */
   unsigned int nontemporal_move: 1;
 
   /* Pass local flags.  These flags are free for any pass to use as
diff --git a/gcc/tree-cfg.cc b/gcc/tree-cfg.cc
index b1ba33018fd..06a96f96be7 100644
--- a/gcc/tree-cfg.cc
+++ b/gcc/tree-cfg.cc
@@ -4837,6 +4837,17 @@ verify_gimple_assign_single (gassign *stmt)
 static bool
 verify_gimple_assign (gassign *stmt)
 {
+  if (gimple_assign_nontemporal_move_p (stmt))
+{
+  tree lhs = gimple_assign_lhs (stmt);
+  if (is_gimple_reg (lhs))
+   {
+ error ("nontemporal store lhs cannot a gimple register");
+ debug_generic_stmt (lhs);
+ return true;
+   }
+}
+
   switch (gimple_assign_rhs_class (stmt))
 {
 case GIMPLE_SINGLE_RHS:
-- 
2.43.0

[PATCH 2/2] Remove support for nontemporal stores with ssa_names on lhs [PR112976]

[Andrew Pinski]

When cfgexpand was changed to support expanding from tuple gimple
(r0-95521-g28ed065ef9f345), the code was added to support
doing nontemporal stores with LHS of a SSA_NAME but that will
never be a nontemporal store.
This patch removes that and asserts that expanding with a LHS
of a SSA_NAME is not a nontemporal store.

Bootstrapped and tested on x86_64-linux-gnu.

gcc/ChangeLog:

PR middle-end/112976
* cfgexpand.cc (expand_gimple_stmt_1): Remove
support for expanding nontemporal "moves" with
ssa names on the LHS.

Signed-off-by: Andrew Pinski 
---
 gcc/cfgexpand.cc | 11 ---
 1 file changed, 4 insertions(+), 7 deletions(-)

diff --git a/gcc/cfgexpand.cc b/gcc/cfgexpand.cc
index eef565eddb5..cfc5291aa0c 100644
--- a/gcc/cfgexpand.cc
+++ b/gcc/cfgexpand.cc
@@ -4002,17 +4002,16 @@ expand_gimple_stmt_1 (gimple *stmt)
else
  {
rtx target, temp;
-   bool nontemporal = gimple_assign_nontemporal_move_p (assign_stmt);
+   gcc_assert (!gimple_assign_nontemporal_move_p (assign_stmt));
bool promoted = false;
 
target = expand_expr (lhs, NULL_RTX, VOIDmode, EXPAND_WRITE);
if (GET_CODE (target) == SUBREG && SUBREG_PROMOTED_VAR_P (target))
  promoted = true;
 
-  /* If we want to use a nontemporal store, force the value to
- register first.  If we store into a promoted register,
- don't directly expand to target.  */
-   temp = nontemporal || promoted ? NULL_RTX : target;
+  /* If we store into a promoted register, don't directly
+ expand to target.  */
+   temp = promoted ? NULL_RTX : target;
temp = expand_expr_real_gassign (assign_stmt, temp,
 GET_MODE (target), EXPAND_NORMAL);
 
@@ -4034,8 +4033,6 @@ expand_gimple_stmt_1 (gimple *stmt)
 
convert_move (SUBREG_REG (target), temp, unsignedp);
  }
-   else if (nontemporal && emit_storent_insn (target, temp))
- ;
else
  {
temp = force_operand (temp, target);
-- 
2.43.0

Re: [PATCH] vax: resolve long-standing documentation bugs re floating-point codegen [PR79646]

[Mike Stump]

On Apr 26, 2024, at 11:17 AM, Abe Skolnik  wrote:

You never need to do any work in .po files, omit that part and repost.

[PATCH] vax: resolve long-standing documentation bugs re floating-point codegen [PR79646]

[Abe Skolnik]

Howdy, y`all.

After many years away from contributing to GCC, I am rejoining as a "gardener": 
my intent/plan is to clean up the bug backlog, weeding out old bugs that are 
relatively-easy to fix yet have languished for a long time.  First for today`s 
gardening: a documentation-only bug or two related to how floating-point code 
is generated for VAX-compatible CPUs.  Yes, _VAX_.

I made sure to update the translation files, using an on-line translator for 
languages which I can`t really read/write on my own.  In at least one case 
where the translation was empty before, I left it empty.  In at least one case 
where the translation was empty before, I filled it in.

Copyright assignment to the FSF, yadda yadda yadda...  all the usual.

Sincerely,

Abe
From ec5f259d0e7dd7dcd1194f775bf00d3decb786f3 Mon Sep 17 00:00:00 2001
From: Abe 
Date: Wed, 24 Apr 2024 21:06:50 -0400
Subject: [PATCH] PR79646: corrected VAX-specific message strings related to
 double-precision codegen, updated+improved translations of those messages.

PR target/79646 - Typos in vax.opt

	PR target/79646

gcc/ChangeLog:

	* config/vax/vax.opt:

gcc/po/ChangeLog:

	* be.po:
	* da.po:
	* de.po:
	* el.po:
	* es.po:
	* fi.po:
	* fr.po:
	* hr.po:
	* id.po:
	* ja.po:
	* nl.po:
	* ru.po:
	* sr.po:
	* sv.po:
	* tr.po:
	* uk.po:
	* vi.po:
	* zh_CN.po:
	* zh_TW.po:

---
 gcc/config/vax/vax.opt |  8 
 gcc/po/be.po   |  8 
 gcc/po/da.po   | 10 --
 gcc/po/de.po   |  8 
 gcc/po/el.po   |  8 
 gcc/po/es.po   |  8 
 gcc/po/fi.po   |  8 
 gcc/po/fr.po   |  8 
 gcc/po/hr.po   |  4 ++--
 gcc/po/id.po   |  8 
 gcc/po/ja.po   |  8 
 gcc/po/nl.po   |  4 ++--
 gcc/po/ru.po   |  8 
 gcc/po/sr.po   | 10 --
 gcc/po/sv.po   |  6 +++---
 gcc/po/tr.po   | 10 --
 gcc/po/uk.po   |  4 ++--
 gcc/po/vi.po   |  8 
 gcc/po/zh_CN.po| 10 --
 gcc/po/zh_TW.po| 10 --
 20 files changed, 73 insertions(+), 83 deletions(-)

diff --git a/gcc/config/vax/vax.opt b/gcc/config/vax/vax.opt
index 2cc66e543fe..fa2be78e9fa 100644
--- a/gcc/config/vax/vax.opt
+++ b/gcc/config/vax/vax.opt
@@ -20,19 +20,19 @@
 
 md
 Target RejectNegative InverseMask(G_FLOAT)
-Target DFLOAT double precision code.
+Generate DFLOAT double-precision code.
 
 md-float
 Target RejectNegative InverseMask(G_FLOAT)
-Target DFLOAT double precision code.
+Generate DFLOAT double-precision code.
 
 mg
 Target RejectNegative Mask(G_FLOAT)
-Generate GFLOAT double precision code.
+Generate GFLOAT double-precision code.
 
 mg-float
 Target RejectNegative Mask(G_FLOAT)
-Generate GFLOAT double precision code.
+Generate GFLOAT double-precision code.
 
 mgnu
 Target RejectNegative InverseMask(UNIX_ASM)
diff --git a/gcc/po/be.po b/gcc/po/be.po
index ae92f9b7b96..db102673665 100644
--- a/gcc/po/be.po
+++ b/gcc/po/be.po
@@ -11502,13 +11502,13 @@ msgstr ""
 
 #: config/vax/vax.opt:23 config/vax/vax.opt:27
 #, no-c-format
-msgid "Target DFLOAT double precision code."
-msgstr ""
+msgid "Generate DFLOAT double-precision code."
+msgstr "Генерыраваць код double-precision для DFLOAT."
 
 #: config/vax/vax.opt:31 config/vax/vax.opt:35
 #, no-c-format
-msgid "Generate GFLOAT double precision code."
-msgstr ""
+msgid "Generate GFLOAT double-precision code."
+msgstr "Генерыраваць код double-precision для GFLOAT."
 
 #: config/vax/vax.opt:39
 #, fuzzy, no-c-format
diff --git a/gcc/po/da.po b/gcc/po/da.po
index 9871ec5b82b..7d82a108897 100644
--- a/gcc/po/da.po
+++ b/gcc/po/da.po
@@ -12372,15 +12372,13 @@ msgstr ""
 
 #: config/vax/vax.opt:23 config/vax/vax.opt:27
 #, fuzzy, no-c-format
-#| msgid "Generate GFLOAT double precision code"
-msgid "Target DFLOAT double precision code."
-msgstr "Opret GFLOAT dobbeltpræcision kode"
+msgid "Generate DFLOAT double-precision code."
+msgstr "Opret GFLOAT dobbeltpræcision kode."
 
 #: config/vax/vax.opt:31 config/vax/vax.opt:35
 #, fuzzy, no-c-format
-#| msgid "Generate GFLOAT double precision code"
-msgid "Generate GFLOAT double precision code."
-msgstr "Opret GFLOAT dobbeltpræcision kode"
+msgid "Generate GFLOAT double-precision code."
+msgstr "Opret GFLOAT dobbeltpræcision kode."
 
 #: config/vax/vax.opt:39
 #, fuzzy, no-c-format
diff --git a/gcc/po/de.po b/gcc/po/de.po
index db42d7191ff..1303b189a4b 100644
--- a/gcc/po/de.po
+++ b/gcc/po/de.po
@@ -11333,13 +11333,13 @@ msgstr "Daten werden ausgehend vom Start des Programmcodes statt der GOT adressi
 
 #: config/vax/vax.opt:23 config/vax/vax.opt:27
 #, no-c-format
-msgid "Target DFLOAT double precision code."
-msgstr "DFLOAT-Code mit doppelter Genauigkeit generieren."
+msgid "Generate DFLOAT double-precision code."
+msgstr "Für doppelter Genauigkeit, DFLOAT-Code generieren."
 
 #: config/vax/vax.opt:31 config/vax/vax.opt:35
 #, no-c-format
-

[PATCH] aarch64: Use cinc for small constants instead of just add [PR112304]

[Andrew Pinski]

On many cores, the mov instruction is "free" so the sequence:
cmp w0, #0
csetw0, ne
add w0, w0, 42
is more expensive than just:
cmp w0, #0
mov w1, #42
cincw0, w1, ne

The reason why we get the add case is that the pattern csinc2_insn
only accepts registers for the predicate and we so we don't get an cinc
without that. The small change to the predicate of using general_operand
instead allows the combine to match and then the mov is generated with
the register allocator checks the constraints.

Built and tested on aarch64-linux-gnu with no regressions.

PR target/112304

gcc/ChangeLog:

* config/aarch64/aarch64.md (*csinc2_insn): Change the
predicate of the 1st operand to general_operand.

gcc/testsuite/ChangeLog:

* gcc.target/aarch64/cinc-2.c: New test.

Signed-off-by: Andrew Pinski 
---
 gcc/config/aarch64/aarch64.md |  2 +-
 gcc/testsuite/gcc.target/aarch64/cinc-2.c | 11 +++
 2 files changed, 12 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.target/aarch64/cinc-2.c

diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
index a6051ebfc5a..046a249475d 100644
--- a/gcc/config/aarch64/aarch64.md
+++ b/gcc/config/aarch64/aarch64.md
@@ -4549,7 +4549,7 @@ (define_insn "aarch64_"
 (define_insn "*csinc2_insn"
   [(set (match_operand:GPI 0 "register_operand" "=r")
 (plus:GPI (match_operand 2 "aarch64_comparison_operation" "")
-  (match_operand:GPI 1 "register_operand" "r")))]
+  (match_operand:GPI 1 "general_operand" "r")))]
   ""
   "cinc\\t%0, %1, %m2"
   [(set_attr "type" "csel")]
diff --git a/gcc/testsuite/gcc.target/aarch64/cinc-2.c 
b/gcc/testsuite/gcc.target/aarch64/cinc-2.c
new file mode 100644
index 000..dc68dfed40f
--- /dev/null
+++ b/gcc/testsuite/gcc.target/aarch64/cinc-2.c
@@ -0,0 +1,11 @@
+/* { dg-options "-O2" } */
+/* PR target/112304 */
+
+int f(int a)
+{
+return (a!=0)+42;
+}
+
+/* This function should produce a cinc with a mov instead of a cset with an 
add. */
+/* { dg-final { scan-assembler-not "cset\t" } } */
+/* { dg-final { scan-assembler "cinc\t" } } */
-- 
2.43.0

[PATCH] aarch64: Fix normal returns inside functions which use eh_returns [PR114843]

[Andrew Pinski]

The problem here is that on a normal return path, we still restore the
eh data return when we should not.
Instead of one return path in the case of eh_return, this changes over
to use multiple returns pathes just like a normal function.
On the normal path (non-eh return), we need to skip restoring of the eh
return data registers.

This fixes the code generation of _Unwind_RaiseException where the return value
was currupted.

Note this adds some testcases which might fail on some targets.
I know of the following targets will fail also:
arm is recorded as PR 114847.
powerpc is recorded as PR 114846.

Build and tested for aarch64-linux-gnu with no regressions.

PR target/114843

gcc/ChangeLog:

* config/aarch64/aarch64-protos.h (aarch64_expand_epilogue): New
prototype.
* config/aarch64/aarch64.cc (aarch64_pop_regs): Skip over the
eh return data if not eh return. Generate an add if both registers
was skipped and return true. Return false if we generated a pop.
(aarch64_restore_callee_saves): Skip over the eh return data regs
if not eh return.
(aarch64_expand_epilogue): New function, pass false.
(aarch64_expand_epilogue): Add was_eh_return argument.
Update calls to aarch64_restore_callee_saves and aarch64_pop_regs.
If aarch64_pop_regs return true, make sure we add the CFA note.
For eh_returns, update the sp and do an indirect jump.
Don't check EH_RETURN_TAKEN_RTX any more.
* config/aarch64/aarch64.h (EH_RETURN_TAKEN_RTX): Delete.
* config/aarch64/aarch64.md (eh_return): New define_expand.
(eh_return_internal): New pattern for eh_returns.

gcc/testsuite/ChangeLog:

* gcc.target/aarch64/eh_return-3.c: Update testcase.
* gcc.c-torture/execute/eh_return-1.c: New test.
* gcc.c-torture/execute/eh_return-2.c: New test.
* gcc.c-torture/execute/eh_return-3.c: New test.
* gcc.c-torture/execute/eh_return-4.c: New test.
* gcc.target/aarch64/eh_return-4.c: New test.

Signed-off-by: Andrew Pinski 
---
 gcc/config/aarch64/aarch64-protos.h   |  1 +
 gcc/config/aarch64/aarch64.cc | 69 ---
 gcc/config/aarch64/aarch64.h  |  4 +-
 gcc/config/aarch64/aarch64.md | 24 +++
 .../gcc.c-torture/execute/eh_return-1.c   | 20 ++
 .../gcc.c-torture/execute/eh_return-2.c   | 23 +++
 .../gcc.c-torture/execute/eh_return-3.c   | 25 +++
 .../gcc.c-torture/execute/eh_return-4.c   | 25 +++
 .../gcc.target/aarch64/eh_return-3.c  | 11 ++-
 .../gcc.target/aarch64/eh_return-4.c  | 30 
 10 files changed, 198 insertions(+), 34 deletions(-)
 create mode 100644 gcc/testsuite/gcc.c-torture/execute/eh_return-1.c
 create mode 100644 gcc/testsuite/gcc.c-torture/execute/eh_return-2.c
 create mode 100644 gcc/testsuite/gcc.c-torture/execute/eh_return-3.c
 create mode 100644 gcc/testsuite/gcc.c-torture/execute/eh_return-4.c
 create mode 100644 gcc/testsuite/gcc.target/aarch64/eh_return-4.c

diff --git a/gcc/config/aarch64/aarch64-protos.h 
b/gcc/config/aarch64/aarch64-protos.h
index 42639e9efcf..efe86d52873 100644
--- a/gcc/config/aarch64/aarch64-protos.h
+++ b/gcc/config/aarch64/aarch64-protos.h
@@ -904,6 +904,7 @@ const char * aarch64_gen_far_branch (rtx *, int, const char 
*, const char *);
 const char * aarch64_output_probe_stack_range (rtx, rtx);
 const char * aarch64_output_probe_sve_stack_clash (rtx, rtx, rtx, rtx);
 void aarch64_err_no_fpadvsimd (machine_mode);
+void aarch64_expand_epilogue (rtx_call_insn *, bool);
 void aarch64_expand_epilogue (rtx_call_insn *);
 rtx aarch64_ptrue_all (unsigned int);
 opt_machine_mode aarch64_ptrue_all_mode (rtx);
diff --git a/gcc/config/aarch64/aarch64.cc b/gcc/config/aarch64/aarch64.cc
index 1beec94629d..99dc6f7f1c0 100644
--- a/gcc/config/aarch64/aarch64.cc
+++ b/gcc/config/aarch64/aarch64.cc
@@ -8270,10 +8270,28 @@ aarch64_gen_loadwb_pair (machine_mode mode, rtx base, 
rtx reg, rtx reg2,
afterwards by ADJUSTMENT and writing the appropriate REG_CFA_RESTORE notes
into CFI_OPS.  */
 
-static void
+static bool
 aarch64_pop_regs (unsigned regno1, unsigned regno2, HOST_WIDE_INT adjustment,
- rtx *cfi_ops)
+ rtx *cfi_ops, bool was_eh_return)
 {
+  /* Skip over eh return data if not eh_return. */
+  if (!was_eh_return
+  && EH_RETURN_DATA_REGNO (regno1) != INVALID_REGNUM
+  && (!df_regs_ever_live_p (regno1)
+ || crtl->abi->clobbers_full_reg_p (regno1)))
+{
+  if (regno2 == INVALID_REGNUM
+ || (EH_RETURN_DATA_REGNO (regno2) != INVALID_REGNUM
+ && (!df_regs_ever_live_p (regno2)
+ || crtl->abi->clobbers_full_reg_p (regno2
+   {
+ rtx mem = plus_constant (Pmode, stack_pointer_rtx, adjustment);
+ emit_move_insn (stack_pointer_rtx, mem);
+ return true;
+   }
+  regno1 = regno2;
+ 

RE: [PATCH] i386: Fix array index overflow in pr105354-2.c

[Jiang, Haochen]

> -Original Message-
> From: Uros Bizjak 
> Sent: Friday, April 26, 2024 5:13 PM
> To: Jiang, Haochen 
> Cc: gcc-patches@gcc.gnu.org; Liu, Hongtao 
> Subject: Re: [PATCH] i386: Fix array index overflow in pr105354-2.c
> 
> On Fri, Apr 26, 2024 at 11:03 AM Haochen Jiang 
> wrote:
> >
> > Hi all,
> >
> > The array index should not be over 8 for v8hi, or it will fail
> > under -O0 or using -fstack-protector.
> >
> > This patch aims to fix that, which is mentioned in PR110621.
> >
> > Commit as obvious and backport to GCC13.
> >
> > Thx,
> > Haochen
> >
> > gcc/testsuite/ChangeLog:
> >
> > PR target/110621
> > * gcc.target/i386/pr105354-2.c: As mentioned.
> 
> Please note that the ChangeLog entry gets copied into the relevant
> ChangeLog file independently of the commit message. So, the above
> entry will be copied to gcc/testsuite/ChangeLog without any reference
> to what was mentioned.
>

I see. Forget to pay attention to that ChangeLog entry. My Bad.

Thx,
Haochen
 
> Uros.
> 

[committed] libstdc++: Do not apply localized formatting to NaN and inf [PR114863]

[Jonathan Wakely]

Tested x86_64-linux. Pushed to trunk.

I'm going to push this to gcc-13 and gcc-14 too (approved by Jakub on
IRC).

-- >8 --

We don't want to add grouping to strings like "-inf", and there is no
radix character to replace either.

libstdc++-v3/ChangeLog:

PR libstdc++/114863
* include/std/format (__formatter_fp::format): Only use
_M_localized for finite values.
* testsuite/std/format/functions/format.cc: Check localized
formatting of NaN and initiny.
---
 libstdc++-v3/include/std/format   | 2 +-
 libstdc++-v3/testsuite/std/format/functions/format.cc | 8 
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/libstdc++-v3/include/std/format b/libstdc++-v3/include/std/format
index 22dcb5f24bd..48deba2bcb2 100644
--- a/libstdc++-v3/include/std/format
+++ b/libstdc++-v3/include/std/format
@@ -1734,7 +1734,7 @@ namespace __format
}
 #endif
 
- if (_M_spec._M_localized)
+ if (_M_spec._M_localized && __builtin_isfinite(__v))
{
  __wstr = _M_localize(__str, __expc, __fc.locale());
  if (!__wstr.empty())
diff --git a/libstdc++-v3/testsuite/std/format/functions/format.cc 
b/libstdc++-v3/testsuite/std/format/functions/format.cc
index 4499397aaf9..78cc1ab482a 100644
--- a/libstdc++-v3/testsuite/std/format/functions/format.cc
+++ b/libstdc++-v3/testsuite/std/format/functions/format.cc
@@ -248,6 +248,14 @@ test_locale()
   s = std::format(cloc, "{:05L}", -1.0); // PR libstdc++/110968
   VERIFY( s == "-0001" );
 
+  // PR libstdc++/114863 grouping applied to nan and inf
+  double inf = std::numeric_limits::infinity();
+  s = std::format(eloc, "{0:Le} {0:Lf} {0:Lg}", -inf);
+  VERIFY( s == "-inf -inf -inf" );
+  double nan = std::numeric_limits::quiet_NaN();
+  s = std::format(eloc, "{0:Le} {0:Lf} {0:Lg}", -nan);
+  VERIFY( s == "-nan -nan -nan" );
+
   // Restore
   std::locale::global(cloc);
 }
-- 
2.44.0

[PATCH] LoongArch: Add constraints for bit string operation define_insn_and_split's [PR114861]

[Xi Ruoyao]

Without the constrants, the compiler attempts to use a stack slot as the
target, causing an ICE building the kernel with -Os:

drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c:3144:1:
error: could not split insn
(insn:TI 1764 67 1745
  (set (mem/c:DI (reg/f:DI 3 $r3) [707 %sfp+-80 S8 A64])
   (and:DI (reg/v:DI 28 $r28 [orig:422 raster_config ] [422])
   (const_int -50331649 [0xfcff])))
  "drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c":1386:21 111
  {*bstrins_di_for_mask}
  (nil))

Add these constrants to fix the issue.

gcc/ChangeLog:

PR target/114861
* config/loongarch/loongarch.md (bstrins__for_mask): Add
constraints for operands.
(bstrins__for_ior_mask): Likewise.

gcc/testsuite/ChangeLog:

PR target/114861
* gcc.target/loongarch/pr114861.c: New test.
---
 gcc/config/loongarch/loongarch.md | 16 
 gcc/testsuite/gcc.target/loongarch/pr114861.c | 39 +++
 2 files changed, 47 insertions(+), 8 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/loongarch/pr114861.c

diff --git a/gcc/config/loongarch/loongarch.md 
b/gcc/config/loongarch/loongarch.md
index a316c8fb820..5c80c169cbf 100644
--- a/gcc/config/loongarch/loongarch.md
+++ b/gcc/config/loongarch/loongarch.md
@@ -1543,9 +1543,9 @@ (define_insn "and3_extended"
(set_attr "mode" "")])
 
 (define_insn_and_split "*bstrins__for_mask"
-  [(set (match_operand:GPR 0 "register_operand")
-   (and:GPR (match_operand:GPR 1 "register_operand")
-(match_operand:GPR 2 "ins_zero_bitmask_operand")))]
+  [(set (match_operand:GPR 0 "register_operand" "=r")
+   (and:GPR (match_operand:GPR 1 "register_operand" "r")
+(match_operand:GPR 2 "ins_zero_bitmask_operand" "i")))]
   ""
   "#"
   ""
@@ -1563,11 +1563,11 @@ (define_insn_and_split "*bstrins__for_mask"
   })
 
 (define_insn_and_split "*bstrins__for_ior_mask"
-  [(set (match_operand:GPR 0 "register_operand")
-   (ior:GPR (and:GPR (match_operand:GPR 1 "register_operand")
-  (match_operand:GPR 2 "const_int_operand"))
-(and:GPR (match_operand:GPR 3 "register_operand")
- (match_operand:GPR 4 "const_int_operand"]
+  [(set (match_operand:GPR 0 "register_operand" "=r")
+   (ior:GPR (and:GPR (match_operand:GPR 1 "register_operand" "r")
+ (match_operand:GPR 2 "const_int_operand" "i"))
+(and:GPR (match_operand:GPR 3 "register_operand" "r")
+ (match_operand:GPR 4 "const_int_operand" "i"]
   "loongarch_pre_reload_split ()
&& loongarch_use_bstrins_for_ior_with_mask (mode, operands)"
   "#"
diff --git a/gcc/testsuite/gcc.target/loongarch/pr114861.c 
b/gcc/testsuite/gcc.target/loongarch/pr114861.c
new file mode 100644
index 000..e6507c406b9
--- /dev/null
+++ b/gcc/testsuite/gcc.target/loongarch/pr114861.c
@@ -0,0 +1,39 @@
+/* PR114861: ICE building the kernel with -Os
+   Reduced from linux/fs/ntfs3/attrib.c at revision c942a0cd3603.  */
+/* { dg-do compile } */
+/* { dg-options "-Os -march=loongarch64 -msoft-float -mabi=lp64s" } */
+
+long evcn, attr_collapse_range_vbo, attr_collapse_range_bytes;
+unsigned short flags;
+int attr_collapse_range_ni_0_0;
+int *attr_collapse_range_mi;
+unsigned attr_collapse_range_svcn, attr_collapse_range_vcn1;
+void ni_insert_nonresident (unsigned, unsigned short, int **);
+int mi_pack_runs (int);
+int
+attr_collapse_range (void)
+{
+  _Bool __trans_tmp_1;
+  int run = attr_collapse_range_ni_0_0;
+  unsigned evcn1, vcn, end;
+  short a_flags = flags;
+  __trans_tmp_1 = flags & (32768 | 1);
+  if (__trans_tmp_1)
+return 2;
+  vcn = attr_collapse_range_vbo;
+  end = attr_collapse_range_bytes;
+  evcn1 = evcn;
+  for (;;)
+if (attr_collapse_range_svcn >= end)
+  {
+unsigned eat, next_svcn = mi_pack_runs (42);
+attr_collapse_range_vcn1 = (vcn ? vcn : attr_collapse_range_svcn);
+eat = (0 < end) - attr_collapse_range_vcn1;
+mi_pack_runs (run - eat);
+if (next_svcn + eat)
+  ni_insert_nonresident (evcn1 - eat - next_svcn, a_flags,
+ &attr_collapse_range_mi);
+  }
+else
+  return 42;
+}
-- 
2.44.0

Re: Frontend access to target features (was Re: [PATCH] libgccjit: Add ability to get CPU features)

[Antoni Boucher]

Now that we have a more general way to check if target-dependent types 
are supported (see this commit: 
https://github.com/rust-lang/gcc/commit/1c9a9b2f1fd914cad911467ec1d29f158643c2ce#diff-018089519ab2b14a34313ded0ae1a2f9fcab5f7bcb2fa31f147e1dc757bbdd7aR4016), 
perhaps we should remove gcc_jit_target_info_supports_128bit_int from 
this patch, or change it to include the more general way.


David, what are your thoughts on this?

Le 2024-04-19 à 08 h 34, Antoni Boucher a écrit :

David: Ping.

Le 2024-04-09 à 09 h 21, Antoni Boucher a écrit :

David: Ping.

Le 2024-04-01 à 08 h 20, Antoni Boucher a écrit :

David: Ping.

Le 2024-03-19 à 07 h 03, Arthur Cohen a écrit :

Hi,

On 3/5/24 16:09, David Malcolm wrote:

On Thu, 2023-11-09 at 19:33 -0500, Antoni Boucher wrote:

Hi.
See answers below.

On Thu, 2023-11-09 at 18:04 -0500, David Malcolm wrote:

On Thu, 2023-11-09 at 17:27 -0500, Antoni Boucher wrote:

Hi.
This patch adds support for getting the CPU features in libgccjit
(bug
112466)

There's a TODO in the test:
I'm not sure how to test that gcc_jit_target_info_arch returns
the
correct value since it is dependant on the CPU.
Any idea on how to improve this?

Also, I created a CStringHash to be able to have a
std::unordered_set. Is there any built-in way of
doing
this?


Thanks for the patch.

Some high-level questions:

Is this specifically about detecting capabilities of the host that
libgccjit is currently running on? or how the target was configured
when libgccjit was built?


I'm less sure about this part. I'll need to do more tests.



One of the benefits of libgccjit is that, in theory, we support all
of
the targets that GCC already supports.  Does this patch change
that,
or
is this more about giving client code the ability to determine
capabilities of the specific host being compiled for?


This should not change that. If it does, this is a bug.



I'm nervous about having per-target jit code.  Presumably there's a
reason that we can't reuse existing target logic here - can you
please
describe what the problem is.  I see that the ChangeLog has:


 * config/i386/i386-jit.cc: New file.


where i386-jit.cc has almost 200 lines of nontrivial code.  Where
did
this come from?  Did you base it on existing code in our source
tree,
making modifications to fit the new internal API, or did you write
it
from scratch?  In either case, how onerous would this be for other
targets?


This was mostly copied from the same code done for the Rust and D
frontends.
See this commit and the following:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=b1c06fd9723453dd2b2ec306684cb806dc2b4fbb
The equivalent to i386-jit.cc is there:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=22e3557e2d52f129f2bbfdc98688b945dba28dc9


[CCing Iain and Arthur re those patches; for reference, the patch 
being

discussed is attached to :
https://gcc.gnu.org/pipermail/jit/2024q1/001792.html ]

One of my concerns about this patch is that we seem to be gaining code
that's per-(frontend x config) which seems to be copied and pasted 
with

a search and replace, which could lead to an M*N explosion.


I think this is definitely already the case, and it would be worth 
investigating if C/C++/Rust/jit can reuse a similar set of target 
files, or how to factor them together. I imagine that all of these 
components share similar needs for the targets they support.




Is there any real difference between the per-config code for the
different frontends, or should there be a general "enumerate all
features of the target" hook that's independent of the frontend? (but
perhaps calls into it).

Am I right in thinking that (rustc with default LLVM backend) has some
set of feature strings that both (rustc with rustc_codegen_gcc) and
gccrs are trying to emulate?  If so, is it presumably a goal that
libgccjit gives identical results to gccrs?  If so, would it be crazy
for libgccjit to consume e.g. config/i386/i386-rust.cc ?


I think this would definitely make sense, and it could probably be 
extended to other frontends. For the time being I think it makes 
sense to try it out for gccrs and jit. But finding a fitting name 
will be hard :)


Best,

Arthur



Dave





I'm not at expert at target hooks (or at the i386 backend), so if
we
do
go with this approach I'd want someone else to review those parts
of
the patch.

Have you verified that GCC builds with this patch with jit *not*
enabled in the enabled languages?


I will do.



[...snip...]

A nitpick:


+.. function:: const char * \
+  gcc_jit_target_info_arch (gcc_jit_target_info
*info)
+
+   Get the architecture of the currently running CPU.


What does this string look like?
How long does the pointer remain valid?


It's the march string, like "znver2", for instance.
It remains valid until we free the gcc_jit_target_info object.



Thanks again; hope the above makes sense
Dave

[PATCH] middle-end/114734 - wrong code with expand_call_mem_ref

[Richard Biener]

When expand_call_mem_ref looks at the definition of the address
argument to eventually expand a &TARGET_MEM_REF argument together
with a masked load it fails to honor constraints imposed by SSA
coalescing decisions.  The following fixes this.

Boostrap and regtest running on x86_64-unknown-linux-gnu.

PR middle-end/114734
* internal-fn.cc (expand_call_mem_ref): Use
get_gimple_for_ssa_name to get at the def stmt of the address
argument to honor SSA coalescing constraints.
---
 gcc/internal-fn.cc | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/gcc/internal-fn.cc b/gcc/internal-fn.cc
index 2c764441cde..0a7053c2286 100644
--- a/gcc/internal-fn.cc
+++ b/gcc/internal-fn.cc
@@ -53,6 +53,8 @@ along with GCC; see the file COPYING3.  If not see
 #include "rtl-iter.h"
 #include "gimple-range.h"
 #include "fold-const-call.h"
+#include "tree-ssa-live.h"
+#include "tree-outof-ssa.h"

 /* For lang_hooks.types.type_for_mode.  */
 #include "langhooks.h"
@@ -2964,8 +2966,8 @@ expand_call_mem_ref (tree type, gcall *stmt, int index)
   tree tmp = addr;
   if (TREE_CODE (tmp) == SSA_NAME)
 {
-  gimple *def = SSA_NAME_DEF_STMT (tmp);
-  if (gimple_assign_single_p (def))
+  gimple *def = get_gimple_for_ssa_name (tmp);
+  if (def && gimple_assign_single_p (def))
tmp = gimple_assign_rhs1 (def);
 }

--
2.25.1

Re: [PATCH] wwwdocs: Add note to changes.html for __has_{feature,extension}

[Alex Coplan]

On 26/04/2024 09:14, Marek Polacek wrote:
> On Fri, Apr 26, 2024 at 11:12:54AM +0100, Alex Coplan wrote:
> > On 17/04/2024 11:41, Marek Polacek wrote:
> > > On Mon, Apr 15, 2024 at 11:13:27AM +0100, Alex Coplan wrote:
> > > > On 04/04/2024 11:00, Alex Coplan wrote:
> > > > > Hi,
> > > > > 
> > > > > This adds a note to the GCC 14 release notes mentioning support for
> > > > > __has_{feature,extension} (PR60512).
> > > > > 
> > > > > OK to commit?
> > > > 
> > > > Ping.  Is this changes.html patch OK?  I guess it needs a review from 
> > > > C++
> > > > maintainers since it adds to the C++ section.
> > > > 
> > > > > 
> > > > > Thanks,
> > > > > Alex
> > > > 
> > > > > diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
> > > > > index 9fd224c1..facead8d 100644
> > > > > --- a/htdocs/gcc-14/changes.html
> > > > > +++ b/htdocs/gcc-14/changes.html
> > > > > @@ -242,6 +242,12 @@ a work-in-progress.
> > > > >constinit and optimized dynamic 
> > > > > initialization
> > > > >  
> > > > >
> > > > > +  The Clang language extensions __has_feature and
> > > > > +__has_extension have been implemented in GCC.  These
> > > > > +are available from C, C++, and Objective-C(++).
> > > 
> > > Since the extension is for the whole c-family, not just C++, I think it
> > > belongs to a "C family" section.  See e.g. 
> > > .
> > 
> > Thanks, I agree that makes more sense.  How about this version instead then:
> 
> Thanks, I think you can go ahead with this.

Great, I've pushed that to wwwdocs.

>  
> > diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
> > index fce0fb44..42353955 100644
> > --- a/htdocs/gcc-14/changes.html
> > +++ b/htdocs/gcc-14/changes.html
> > @@ -303,7 +303,15 @@ a work-in-progress.
> >Further clean up and improvements to the GNAT code.
> >  
> >  
> > -
> > +C family
> > +
> > +  The Clang language extensions __has_feature and
> > +__has_extension have been implemented in GCC.  These
> > +are available from C, C++, and Objective-C(++).
> > +This is primarily intended to aid the portability of code written
> > +against Clang.
> > +  
> > +
> >  
> >  C
> 
> Marek
> 

Re: [COMMITTED] gcc-14: Add Ada changes

[Marc Poulhiès]

Marek Polacek  writes:

Hello,

>> +  Experimental features:
>> +> href="https://gcc.gnu.org/onlinedocs/gnat_rm/Pragma-Storage_005fModel.html";>Storage
>> +Model: this feature proposes to redesign the concepts of Storage 
>> Pools
>> +into a more efficient model allowing higher performances and easier
>> +integration with low footprint embedded run-times.
>> +> href="https://gcc.gnu.org/onlinedocs/gnat_rm/String-interpolation.html";>String
>> +Interpolation: allows for easier string formatting.
>> +  
>> +  Further clean up and improvements to the GNAT code.
>> +
>
> Some of this doesn't pass https://validator.w3.org/.  Please take a look
> when you get a chance.  Thanks,

Sorry about that. I've pushed the simple fix and checked the validator
is happy again. Thanks for the notice.

Marc

Re: [COMMITTED] gcc-14: Add Ada changes

[Marek Polacek]

On Fri, Apr 26, 2024 at 10:55:35AM +0200, Marc Poulhiès wrote:
> Co-authored-by: Fernando Oleo Blanco 
> Co-authored-by: Piotr Trojanek 
> Signed-off-by: Marc Poulhiès 
> ---
>  htdocs/gcc-14/changes.html | 67 +-
>  1 file changed, 66 insertions(+), 1 deletion(-)
> 
> diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
> index 83b1016c..87e04cb8 100644
> --- a/htdocs/gcc-14/changes.html
> +++ b/htdocs/gcc-14/changes.html
> @@ -239,7 +239,72 @@ a work-in-progress.
>
>  
>  
> -
> +Ada
> +
> +
> +  New implementation-defined aspects and pragmas:
> +
> +   href="https://gcc.gnu.org/onlinedocs/gnat_rm/Aspect-Local_005fRestrictions.html";>Local_Restrictions,
> +  which specifies that a particular subprogram does not violate one or 
> more
> +  local restrictions, nor can it call a subprogram that is not subject to
> +  the same requirements.
> +   href="https://gcc.gnu.org/onlinedocs/gnat_rm/Pragma-User_005fAspect_005fDefinition.html";>User_Aspect_Definition
> +  and  href="https://gcc.gnu.org/onlinedocs/gnat_rm/Aspect-User_005fAspect.html";>User_Aspect,
> +  which provide a mechanism for avoiding textual duplication if some set 
> of
> +  aspect specifications is needed in multiple places.
> +
> +  
> +  New implementation-defined aspects and pragmas for verification of the
> +  SPARK 2014 subset of Ada:
> +
> +   href="https://gcc.gnu.org/onlinedocs/gnat_rm/Aspect-Always_005fTerminates.html";>Always_Terminates,
> +  which provides a condition for a subprogram to necessarily complete
> +  (either return normally or raise an exception).
> +   href="https://gcc.gnu.org/onlinedocs/gnat_rm/Aspect-Ghost_005fPredicate.html";>Ghost_Predicate,
> +  which introduces a subtype predicate that can reference Ghost entities.
> +  
> +   href="https://gcc.gnu.org/onlinedocs/gnat_rm/Aspect-Exceptional_005fCases.html";>Exceptional_Cases,
> +  which lists exceptions that might be propagated by the subprogram with
> +  side effects in the context of its precondition and associates them 
> with a
> +  specific postcondition.
> +  
> +   href="https://gcc.gnu.org/onlinedocs/gnat_rm/Aspect-Side_005fEffects.html";>Side_Effects,
> +  which indicates that a function should be handled like a procedure with
> +  respect to parameter modes, Global contract, exceptional contract and
> +  termination: it may have output parameters, write global variables, 
> raise
> +  exceptions and not terminate.
> +
> +  
> +  The new attributes and contracts have been applied to the relevant 
> parts
> +  of the Ada runtime library, which has been subsequently proven to be 
> correct
> +  with SPARK 2014.
> +  Initial support for the
> +   href="https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/";>CHERI
> +  architecture.
> +  Support for the LoongArch architecture.
> +  Support for vxWorks 7 Cert RTP has been removed.
> +  Additional hardening improvements. For more information reltated to
> +hardening options, refer to
> +the  href="https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html#index-fharden-compares";>GCC
> +Instrumentation Options and
> +the  href="https://gcc.gnu.org/onlinedocs/gnat_rm/Security-Hardening-Features.html";>GNAT
> +Reference Manual, Security and Hardening Features.
> +  
> +  Improve style checking for redundant parentheses
> +  with  href="https://gcc.gnu.org/onlinedocs/gnat_ugn/Style-Checking.html#index--gnatyz-_0028gcc_0029";>-gnatyz
> +  New
> +  switch  href="https://gcc.gnu.org/onlinedocs/gnat_ugn/Alphabetical-List-of-All-Switches.html#index--gnateH-_0028gcc_0029";>-gnateH
> +  to force reverse Bit_Order threshold to 64.
> +  Experimental features:
> + href="https://gcc.gnu.org/onlinedocs/gnat_rm/Pragma-Storage_005fModel.html";>Storage
> +Model: this feature proposes to redesign the concepts of Storage 
> Pools
> +into a more efficient model allowing higher performances and easier
> +integration with low footprint embedded run-times.
> + href="https://gcc.gnu.org/onlinedocs/gnat_rm/String-interpolation.html";>String
> +Interpolation: allows for easier string formatting.
> +  
> +  Further clean up and improvements to the GNAT code.
> +

Some of this doesn't pass https://validator.w3.org/.  Please take a look
when you get a chance.  Thanks,

Marek

Re: [PATCH] wwwdocs: Add note to changes.html for __has_{feature,extension}

[Marek Polacek]

On Fri, Apr 26, 2024 at 11:12:54AM +0100, Alex Coplan wrote:
> On 17/04/2024 11:41, Marek Polacek wrote:
> > On Mon, Apr 15, 2024 at 11:13:27AM +0100, Alex Coplan wrote:
> > > On 04/04/2024 11:00, Alex Coplan wrote:
> > > > Hi,
> > > > 
> > > > This adds a note to the GCC 14 release notes mentioning support for
> > > > __has_{feature,extension} (PR60512).
> > > > 
> > > > OK to commit?
> > > 
> > > Ping.  Is this changes.html patch OK?  I guess it needs a review from C++
> > > maintainers since it adds to the C++ section.
> > > 
> > > > 
> > > > Thanks,
> > > > Alex
> > > 
> > > > diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
> > > > index 9fd224c1..facead8d 100644
> > > > --- a/htdocs/gcc-14/changes.html
> > > > +++ b/htdocs/gcc-14/changes.html
> > > > @@ -242,6 +242,12 @@ a work-in-progress.
> > > >constinit and optimized dynamic initialization
> > > >  
> > > >
> > > > +  The Clang language extensions __has_feature and
> > > > +__has_extension have been implemented in GCC.  These
> > > > +are available from C, C++, and Objective-C(++).
> > 
> > Since the extension is for the whole c-family, not just C++, I think it
> > belongs to a "C family" section.  See e.g. 
> > .
> 
> Thanks, I agree that makes more sense.  How about this version instead then:

Thanks, I think you can go ahead with this.
 
> diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
> index fce0fb44..42353955 100644
> --- a/htdocs/gcc-14/changes.html
> +++ b/htdocs/gcc-14/changes.html
> @@ -303,7 +303,15 @@ a work-in-progress.
>Further clean up and improvements to the GNAT code.
>  
>  
> -
> +C family
> +
> +  The Clang language extensions __has_feature and
> +__has_extension have been implemented in GCC.  These
> +are available from C, C++, and Objective-C(++).
> +This is primarily intended to aid the portability of code written
> +against Clang.
> +  
> +
>  
>  C

Marek

Re: [PATCH] c++: fix source printing for "required from here" message

[Patrick Palka]

On Thu, 25 Apr 2024, David Malcolm wrote:

> On Wed, 2024-04-24 at 17:05 -0400, Patrick Palka wrote:
> > On Wed, 24 Apr 2024, Jason Merrill wrote:
> > 
> > > On 4/24/24 13:22, Patrick Palka wrote:
> > > > Tested on x86_64-pc-linux-gnu, full bootstrap+regtest in
> > > > progress,
> > > > does this look OK if successful?
> > > > 
> > > > -- >8 --
> > > > 
> > > > It seems the diagnostic machinery's source line printing respects
> > > > the pretty printer prefix, but this is undesirable for the call
> > > > to
> > > > diagnostic_show_locus in print_instantiation_partial_context_line
> > > > added in r14-4388-g1c45319b66edc9 since the prefix may have been
> > > > set when issuing an earlier, unrelated diagnostic and we just
> > > > want
> > > > to print an unprefixed source line.
> > > > 
> > > > This patch naively fixes this by clearing the prefix before
> > > > calling
> > > > diagnostic_show_locus.
> > > > 
> > > > Before this patch, for error60a.C below we'd print
> > > > 
> > > > gcc/testsuite/g++.dg/template/error60a.C: In function ‘void
> > > > usage()’:
> > > > gcc/testsuite/g++.dg/template/error60a.C:24:3: error:
> > > > ‘unrelated_error’ was
> > > > not declared in this scope
> > > >     24 |   unrelated_error; // { dg-error "not declared" }
> > > >    |   ^~~
> > > > gcc/testsuite/g++.dg/template/error60a.C: In instantiation of
> > > > ‘void
> > > > test(Foo) [with Foo = int]’:
> > > > gcc/testsuite/g++.dg/template/error60a.C:25:13:   required from
> > > > here
> > > > gcc/testsuite/g++.dg/template/error60a.C:24:3: error:    25 |  
> > > > test
> > > > (42); // { dg-message " required from here" }
> > > > gcc/testsuite/g++.dg/template/error60a.C:24:3: error:   |
> > > > ~~^~~~
> > > > gcc/testsuite/g++.dg/template/error60a.C:19:24: error: invalid
> > > > conversion
> > > > from ‘int’ to ‘int*’ [-fpermissive]
> > > >     19 |   my_pointer ptr (val); // { dg-error "invalid
> > > > conversion from
> > > > 'int' to 'int\\*'" }
> > > >    |    ^~~
> > > >    |    |
> > > >    |    int
> > > > gcc/testsuite/g++.dg/template/error60a.C:9:20: note:  
> > > > initializing argument
> > > > 1 of ‘my_pointer::my_pointer(Foo*) [with Foo = int]’
> > > >  9 |   my_pointer (Foo *ptr) // { dg-message " initializing
> > > > argument 1"
> > > > }
> > > >    |   ~^~~
> > > > 
> > > > and afterward we print
> > > > 
> > > > gcc/testsuite/g++.dg/template/error60a.C: In function ‘void
> > > > usage()’:
> > > > gcc/testsuite/g++.dg/template/error60a.C:24:3: error:
> > > > ‘unrelated_error’ was
> > > > not declared in this scope
> > > >     24 |   unrelated_error; // { dg-error "not declared" }
> > > >    |   ^~~
> > > > gcc/testsuite/g++.dg/template/error60a.C: In instantiation of
> > > > ‘void
> > > > test(Foo) [with Foo = int]’:
> > > > gcc/testsuite/g++.dg/template/error60a.C:25:13:   required from
> > > > here
> > > >     25 |   test (42); // { dg-message " required from here"
> > > > }
> > > >    |   ~~^~~~
> > > > gcc/testsuite/g++.dg/template/error60a.C:19:24: error: invalid
> > > > conversion
> > > > from ‘int’ to ‘int*’ [-fpermissive]
> > > >     19 |   my_pointer ptr (val); // { dg-error "invalid
> > > > conversion from
> > > > 'int' to 'int\\*'" }
> > > >    |    ^~~
> > > >    |    |
> > > >    |    int
> > > > gcc/testsuite/g++.dg/template/error60a.C:9:20: note:  
> > > > initializing argument
> > > > 1 of ‘my_pointer::my_pointer(Foo*) [with Foo = int]’
> > > >  9 |   my_pointer (Foo *ptr) // { dg-message " initializing
> > > > argument 1"
> > > > }
> > > >    |   ~^~~
> > > > 
> > > > gcc/cp/ChangeLog:
> > > > 
> > > > * error.cc (print_instantiation_partial_context_line):
> > > > Clear
> > > > context->printer->prefix around the call to
> > > > diagnostic_show_locus.
> > > > 
> > > > gcc/testsuite/ChangeLog:
> > > > 
> > > > * g++.dg/concepts/diagnostic2.C: Expect source line
> > > > printed
> > > > for the required from here message.
> > > > * g++.dg/template/error60a.C: New test.
> > > > ---
> > > >   gcc/cp/error.cc |  2 +
> > > >   gcc/testsuite/g++.dg/concepts/diagnostic2.C |  6 ++-
> > > >   gcc/testsuite/g++.dg/template/error60a.C    | 46
> > > > +
> > > >   3 files changed, 53 insertions(+), 1 deletion(-)
> > > >   create mode 100644 gcc/testsuite/g++.dg/template/error60a.C
> > > > 
> > > > diff --git a/gcc/cp/error.cc b/gcc/cp/error.cc
> > > > index 7074845154e..a7067d4d2ed 100644
> > > > --- a/gcc/cp/error.cc
> > > > +++ b/gcc/cp/error.cc
> > > > @@ -3793,7 +3793,9 @@ print_instantiation_partial_context_line
> > > > (diagnostic_context *context,
> > > >    : _("required from here\n"));
> > > >   }
> > > >     gcc_rich_location rich_loc (loc);
> > > >

[committed, gcc-14] libstdc++: Update status tables to refer to GCC 14 not mainline

[Jonathan Wakely]

Pushed to gcc-14.

-- >8 --

libstdc++-v3/ChangeLog:

* doc/html/manual/status.html: Regenerate.
* doc/xml/manual/status_cxx1998.xml: Replace references to
mainline GCC.
* doc/xml/manual/status_cxx2011.xml: Likewise.
* doc/xml/manual/status_cxx2014.xml: Likewise.
* doc/xml/manual/status_cxx2017.xml: Likewise.
* doc/xml/manual/status_cxx2020.xml: Likewise.
* doc/xml/manual/status_cxx2023.xml: Likewise.
* doc/xml/manual/status_cxxtr1.xml: Likewise.
* doc/xml/manual/status_cxxtr24733.xml: Likewise.
---
 libstdc++-v3/doc/html/manual/status.html  | 32 +--
 .../doc/xml/manual/status_cxx1998.xml |  4 +--
 .../doc/xml/manual/status_cxx2011.xml |  4 +--
 .../doc/xml/manual/status_cxx2014.xml |  4 +--
 .../doc/xml/manual/status_cxx2017.xml |  4 +--
 .../doc/xml/manual/status_cxx2020.xml |  4 +--
 .../doc/xml/manual/status_cxx2023.xml |  4 +--
 libstdc++-v3/doc/xml/manual/status_cxxtr1.xml |  4 +--
 .../doc/xml/manual/status_cxxtr24733.xml  |  4 +--
 9 files changed, 32 insertions(+), 32 deletions(-)

diff --git a/libstdc++-v3/doc/html/manual/status.html 
b/libstdc++-v3/doc/html/manual/status.html
index 2e293d32f81..c13ec20feaa 100644
--- a/libstdc++-v3/doc/html/manual/status.html
+++ b/libstdc++-v3/doc/html/manual/status.html
@@ -5,8 +5,8 @@
  NextChapter 1. StatusTable of ContentsImplementation 
StatusC++ 
1998/2003Implementation 
StatusImplementation Specific 
BehaviorC++ 2011Implementation Specific 
BehaviorC++ 2014Implementation Specific 
BehaviorFilesystem 
TSC++ 2017Implementation Specific 
BehaviorParallelism 2 
TSC++ 2020C++ 
2023C++ TR1Implementation Specific 
BehaviorC++ TR 24733C++ IS 
29124Implementation Specific 
BehaviorLicenseThe Code: 
GPLThe Documentation: GPL, 
FDLBugsImplementation 
BugsStandard 
BugsImplementation 
StatusC++ 
1998/2003Implementation Status
 This status table is based on the table of contents of ISO/IEC 14882:2003.
 
-This section describes the C++ support in mainline GCC, not in any
-particular release.
+This section describes the C++ support in
+the GCC 14 release series, not in any particular release.
 Table 1.1. C++ 1998/2003 Implementation 
StatusSectionDescriptionStatusComments
18
   
@@ -160,8 +160,8 @@ since that release.
 
 This status table is based on the table of contents of ISO/IEC 14882:2011.
 
-This section describes the C++11 support in mainline GCC, not in any
-particular release.
+This section describes the C++11 support in
+the GCC 14 release series, not in any particular release.
 Table 1.2. C++ 2011 Implementation 
StatusSectionDescriptionStatusComments
18
   
@@ -433,8 +433,8 @@ This status table is based on the table of contents of 
ISO/IEC 14882:2014.
 Some subclauses are not shown in the table where the content is unchanged
 since C++11 and the implementation is complete.
 
-This section describes the C++14 and library TS support in mainline GCC,
-not in any particular release.
+This section describes the C++14 and library TS support in
+the GCC 14 release series, not in any particular release.
 Table 1.3. C++ 2014 Implementation 
StatusSectionDescriptionStatusComments
18
   
@@ -578,8 +578,8 @@ GCC 9.1 was the first release with non-experimental C++17 
support,
 so the API and ABI of features added in C++17 is only stable
 since that release.
 
-This section describes the C++17 and library TS support in mainline GCC,
-not in any particular release.
+This section describes the C++17 and library TS support in
+the GCC 14 release series, not in any particular release.
 
 The following table lists new library features that are included in
 the C++17 standard. The "Proposal" column provides a link to the
@@ -1254,8 +1254,8 @@ options. The pre-defined symbol
 __cplusplus is used to check for the
 presence of the required flag.
 
-This section describes the C++20 and library TS support in mainline GCC,
-not in any particular release.
+This section describes the C++20 and library TS support in
+the GCC 14 release series, not in any particular release.
 
 The following table lists new library features that are included in
 the C++20 standard. The "Proposal" column provides a link to the
@@ -1724,8 +1724,8 @@ options. The pre-defined symbol
 __cplusplus is used to check for the
 presence of the required flag.
 
-This section describes the C++23 and library TS support in mainline GCC,
-not in any particular release.
+This section describes the C++23 and library TS support in
+the GCC 14 release series, not in any particular release.
 
 The following table lists new library features that have been accepted into
 the C++23 working draft. The "Proposal" column provides a link to the
@@ -2212,8 +2212,8 @@ In this implementation the header names are prefixed by
 tr1/, for instance ,
 , and so on.
 
-This page describes the TR1 support in mainline GCC

[committed, gcc-13] libstdc++: Update status tables to refer to GCC 13 not mainline

[Jonathan Wakely]

Pushed to gcc-13.

-- >8 --

This should have been done before the 13.1.0 release.

libstdc++-v3/ChangeLog:

* doc/html/manual/status.html: Regenerate.
* doc/xml/manual/status_cxx1998.xml: Replace references to
mainline GCC.
* doc/xml/manual/status_cxx2011.xml: Likewise.
* doc/xml/manual/status_cxx2014.xml: Likewise.
* doc/xml/manual/status_cxx2017.xml: Likewise.
* doc/xml/manual/status_cxx2020.xml: Likewise.
* doc/xml/manual/status_cxx2023.xml: Likewise.
* doc/xml/manual/status_cxxtr1.xml: Likewise.
* doc/xml/manual/status_cxxtr24733.xml: Likewise.
---
 libstdc++-v3/doc/html/manual/status.html  | 32 +--
 .../doc/xml/manual/status_cxx1998.xml |  4 +--
 .../doc/xml/manual/status_cxx2011.xml |  4 +--
 .../doc/xml/manual/status_cxx2014.xml |  4 +--
 .../doc/xml/manual/status_cxx2017.xml |  4 +--
 .../doc/xml/manual/status_cxx2020.xml |  4 +--
 .../doc/xml/manual/status_cxx2023.xml |  4 +--
 libstdc++-v3/doc/xml/manual/status_cxxtr1.xml |  4 +--
 .../doc/xml/manual/status_cxxtr24733.xml  |  4 +--
 9 files changed, 32 insertions(+), 32 deletions(-)

diff --git a/libstdc++-v3/doc/html/manual/status.html 
b/libstdc++-v3/doc/html/manual/status.html
index af94ead2b82..53957bd2e0d 100644
--- a/libstdc++-v3/doc/html/manual/status.html
+++ b/libstdc++-v3/doc/html/manual/status.html
@@ -5,8 +5,8 @@
  NextChapter 1. StatusTable of ContentsImplementation 
StatusC++ 
1998/2003Implementation 
StatusImplementation Specific 
BehaviorC++ 2011Implementation Specific 
BehaviorC++ 2014Implementation Specific 
BehaviorFilesystem 
TSC++ 2017Implementation Specific 
BehaviorParallelism 2 
TSC++ 2020C++ 
2023C++ TR1Implementation Specific 
BehaviorC++ TR 24733C++ IS 
29124Implementation Specific 
BehaviorLicenseThe Code: 
GPLThe Documentation: GPL, 
FDLBugsImplementation 
BugsStandard 
BugsImplementation 
StatusC++ 
1998/2003Implementation Status
 This status table is based on the table of contents of ISO/IEC 14882:2003.
 
-This section describes the C++ support in mainline GCC, not in any
-particular release.
+This section describes the C++ support in
+the GCC 13 release series, not in any particular release.
 Table 1.1. C++ 1998/2003 Implementation 
StatusSectionDescriptionStatusComments
18
   
@@ -160,8 +160,8 @@ since that release.
 
 This status table is based on the table of contents of ISO/IEC 14882:2011.
 
-This section describes the C++11 support in mainline GCC, not in any
-particular release.
+This section describes the C++11 support in
+the GCC 13 release series, not in any particular release.
 Table 1.2. C++ 2011 Implementation 
StatusSectionDescriptionStatusComments
18
   
@@ -433,8 +433,8 @@ This status table is based on the table of contents of 
ISO/IEC 14882:2014.
 Some subclauses are not shown in the table where the content is unchanged
 since C++11 and the implementation is complete.
 
-This section describes the C++14 and library TS support in mainline GCC,
-not in any particular release.
+This section describes the C++14 and library TS support in
+the GCC 13 release series, not in any particular release.
 Table 1.3. C++ 2014 Implementation 
StatusSectionDescriptionStatusComments
18
   
@@ -578,8 +578,8 @@ GCC 9.1 was the first release with non-experimental C++17 
support,
 so the API and ABI of features added in C++17 is only stable
 since that release.
 
-This section describes the C++17 and library TS support in mainline GCC,
-not in any particular release.
+This section describes the C++17 and library TS support in
+the GCC 13 release series, not in any particular release.
 
 The following table lists new library features that are included in
 the C++17 standard. The "Proposal" column provides a link to the
@@ -1254,8 +1254,8 @@ options. The pre-defined symbol
 __cplusplus is used to check for the
 presence of the required flag.
 
-This section describes the C++20 and library TS support in mainline GCC,
-not in any particular release.
+This section describes the C++20 and library TS support in
+the GCC 13 release series, not in any particular release.
 
 The following table lists new library features that are included in
 the C++20 standard. The "Proposal" column provides a link to the
@@ -1724,8 +1724,8 @@ options. The pre-defined symbol
 __cplusplus is used to check for the
 presence of the required flag.
 
-This section describes the C++23 and library TS support in mainline GCC,
-not in any particular release.
+This section describes the C++23 and library TS support in
+the GCC 13 release series, not in any particular release.
 
 The following table lists new library features that have been accepted into
 the C++23 working draft. The "Proposal" column provides a link to the
@@ -2122,8 +2122,8 @@ In this implementation the header names are prefixed by
 tr1/, for instance ,
 , and so on.

[committed] libstdc++: Adjust whitespace in status tables in manual

[Jonathan Wakely]

Pushed to trunk. I'll also be following this with the non-whitespace
equivalents for the gcc-14 and gcc-13 branches.

-- >8 --

This simplifies the changes needed after branching for a new release, so
that new line breaks don't need to be introduced every time we branch.

libstdc++-v3/ChangeLog:

* doc/html/manual/status.html: Regenerate.
* doc/xml/manual/status_cxx1998.xml: Adjust whitespace.
* doc/xml/manual/status_cxx2011.xml: Likewise.
* doc/xml/manual/status_cxx2014.xml: Likewise.
* doc/xml/manual/status_cxx2017.xml: Likewise.
* doc/xml/manual/status_cxx2020.xml: Likewise.
* doc/xml/manual/status_cxx2023.xml: Likewise.
* doc/xml/manual/status_cxxtr1.xml: Likewise.
* doc/xml/manual/status_cxxtr24733.xml: Likewise.
---
 libstdc++-v3/doc/html/manual/status.html  | 32 +--
 .../doc/xml/manual/status_cxx1998.xml |  4 +--
 .../doc/xml/manual/status_cxx2011.xml |  4 +--
 .../doc/xml/manual/status_cxx2014.xml |  4 +--
 .../doc/xml/manual/status_cxx2017.xml |  4 +--
 .../doc/xml/manual/status_cxx2020.xml |  4 +--
 .../doc/xml/manual/status_cxx2023.xml |  4 +--
 libstdc++-v3/doc/xml/manual/status_cxxtr1.xml |  4 +--
 .../doc/xml/manual/status_cxxtr24733.xml  |  4 +--
 9 files changed, 32 insertions(+), 32 deletions(-)

diff --git a/libstdc++-v3/doc/html/manual/status.html 
b/libstdc++-v3/doc/html/manual/status.html
index 2e293d32f81..3d55e265272 100644
--- a/libstdc++-v3/doc/html/manual/status.html
+++ b/libstdc++-v3/doc/html/manual/status.html
@@ -5,8 +5,8 @@
  NextChapter 1. StatusTable of ContentsImplementation 
StatusC++ 
1998/2003Implementation 
StatusImplementation Specific 
BehaviorC++ 2011Implementation Specific 
BehaviorC++ 2014Implementation Specific 
BehaviorFilesystem 
TSC++ 2017Implementation Specific 
BehaviorParallelism 2 
TSC++ 2020C++ 
2023C++ TR1Implementation Specific 
BehaviorC++ TR 24733C++ IS 
29124Implementation Specific 
BehaviorLicenseThe Code: 
GPLThe Documentation: GPL, 
FDLBugsImplementation 
BugsStandard 
BugsImplementation 
StatusC++ 
1998/2003Implementation Status
 This status table is based on the table of contents of ISO/IEC 14882:2003.
 
-This section describes the C++ support in mainline GCC, not in any
-particular release.
+This section describes the C++ support in
+mainline GCC, not in any particular release.
 Table 1.1. C++ 1998/2003 Implementation 
StatusSectionDescriptionStatusComments
18
   
@@ -160,8 +160,8 @@ since that release.
 
 This status table is based on the table of contents of ISO/IEC 14882:2011.
 
-This section describes the C++11 support in mainline GCC, not in any
-particular release.
+This section describes the C++11 support in
+mainline GCC, not in any particular release.
 Table 1.2. C++ 2011 Implementation 
StatusSectionDescriptionStatusComments
18
   
@@ -433,8 +433,8 @@ This status table is based on the table of contents of 
ISO/IEC 14882:2014.
 Some subclauses are not shown in the table where the content is unchanged
 since C++11 and the implementation is complete.
 
-This section describes the C++14 and library TS support in mainline GCC,
-not in any particular release.
+This section describes the C++14 and library TS support in
+mainline GCC, not in any particular release.
 Table 1.3. C++ 2014 Implementation 
StatusSectionDescriptionStatusComments
18
   
@@ -578,8 +578,8 @@ GCC 9.1 was the first release with non-experimental C++17 
support,
 so the API and ABI of features added in C++17 is only stable
 since that release.
 
-This section describes the C++17 and library TS support in mainline GCC,
-not in any particular release.
+This section describes the C++17 and library TS support in
+mainline GCC, not in any particular release.
 
 The following table lists new library features that are included in
 the C++17 standard. The "Proposal" column provides a link to the
@@ -1254,8 +1254,8 @@ options. The pre-defined symbol
 __cplusplus is used to check for the
 presence of the required flag.
 
-This section describes the C++20 and library TS support in mainline GCC,
-not in any particular release.
+This section describes the C++20 and library TS support in
+mainline GCC, not in any particular release.
 
 The following table lists new library features that are included in
 the C++20 standard. The "Proposal" column provides a link to the
@@ -1724,8 +1724,8 @@ options. The pre-defined symbol
 __cplusplus is used to check for the
 presence of the required flag.
 
-This section describes the C++23 and library TS support in mainline GCC,
-not in any particular release.
+This section describes the C++23 and library TS support in
+mainline GCC, not in any particular release.
 
 The following table lists new library features that have been accepted into
 the C++23 working draft. The "Proposal" column provides a link to the
@@ -2212,8 +2212,8 @@ In this implementation the header

[wwwdocs] gcc-14/changes.html (AMD GCN): Mention gfx90c support

[Andrew Stubbs]

I will push this shortly. I think the gfx90c patch just made the cut for
the GCC-14 branch!

Andrew

---
 htdocs/gcc-14/changes.html | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
index fce0fb44..47fef32d 100644
--- a/htdocs/gcc-14/changes.html
+++ b/htdocs/gcc-14/changes.html
@@ -726,10 +726,10 @@ a work-in-progress.
 AMD Radeon (GCN)
 
 
-  Initial support for the AMD Radeon gfx1030,
-gfx1036 (RDNA2), gfx1100 and
-gfx1103 (RDNA3) devices has been
-added. LLVM 15+ (assembler and linker) is Initial support for the AMD Radeon gfx90c (GCN5),
+gfx1030, gfx1036 (RDNA2), gfx1100
+and gfx1103 (RDNA3) devices has been added. LLVM 15+
+(assembler and linker) is https://gcc.gnu.org/install/specific.html#amdgcn-x-amdhsa";>required
 to support GFX11.
   Improved register usage and performance on CDNA Instinct MI100
-- 
2.41.0

[wwwdocs] gcc-14/changes.html (AMD GCN): Mention gfx90c support

[Andrew Stubbs]

I will push this shortly. I think the gfx90c patch just made the cut for
the GCC-14 branch!

Andrew

---
 htdocs/gcc-14/changes.html | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
index fce0fb44..47fef32d 100644
--- a/htdocs/gcc-14/changes.html
+++ b/htdocs/gcc-14/changes.html
@@ -726,10 +726,10 @@ a work-in-progress.
 AMD Radeon (GCN)
 
 
-  Initial support for the AMD Radeon gfx1030,
-gfx1036 (RDNA2), gfx1100 and
-gfx1103 (RDNA3) devices has been
-added. LLVM 15+ (assembler and linker) is Initial support for the AMD Radeon gfx90c (GCN5),
+gfx1030, gfx1036 (RDNA2), gfx1100
+and gfx1103 (RDNA3) devices has been added. LLVM 15+
+(assembler and linker) is https://gcc.gnu.org/install/specific.html#amdgcn-x-amdhsa";>required
 to support GFX11.
   Improved register usage and performance on CDNA Instinct MI100
-- 
2.41.0

Re: [PATCH] wwwdocs: Add note to changes.html for __has_{feature,extension}

[Alex Coplan]

On 17/04/2024 11:41, Marek Polacek wrote:
> On Mon, Apr 15, 2024 at 11:13:27AM +0100, Alex Coplan wrote:
> > On 04/04/2024 11:00, Alex Coplan wrote:
> > > Hi,
> > > 
> > > This adds a note to the GCC 14 release notes mentioning support for
> > > __has_{feature,extension} (PR60512).
> > > 
> > > OK to commit?
> > 
> > Ping.  Is this changes.html patch OK?  I guess it needs a review from C++
> > maintainers since it adds to the C++ section.
> > 
> > > 
> > > Thanks,
> > > Alex
> > 
> > > diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
> > > index 9fd224c1..facead8d 100644
> > > --- a/htdocs/gcc-14/changes.html
> > > +++ b/htdocs/gcc-14/changes.html
> > > @@ -242,6 +242,12 @@ a work-in-progress.
> > >constinit and optimized dynamic initialization
> > >  
> > >
> > > +  The Clang language extensions __has_feature and
> > > +__has_extension have been implemented in GCC.  These
> > > +are available from C, C++, and Objective-C(++).
> 
> Since the extension is for the whole c-family, not just C++, I think it
> belongs to a "C family" section.  See e.g. 
> .

Thanks, I agree that makes more sense.  How about this version instead then:

diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
index fce0fb44..42353955 100644
--- a/htdocs/gcc-14/changes.html
+++ b/htdocs/gcc-14/changes.html
@@ -303,7 +303,15 @@ a work-in-progress.
   Further clean up and improvements to the GNAT code.
 
 
-
+C family
+
+  The Clang language extensions __has_feature and
+__has_extension have been implemented in GCC.  These
+are available from C, C++, and Objective-C(++).
+This is primarily intended to aid the portability of code written
+against Clang.
+  
+
 
 C
 
Alex

> 
> Marek
> 

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

[Christophe Lyon]

On Fri, 26 Apr 2024 at 10:25, Christophe Lyon
 wrote:
>
> On Thu, 25 Apr 2024 at 17:44, Carlos O'Donell  wrote:
> >
> > 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.
>
> Thank you Carlos for the patch and helping with the discussions!
>
> Christophe
>

And BTW sorry I wasn't able to attend the meeting yesterday, thanks
Thiago for raising the question.

I have a follow-up one: I think the same applies to binutils, but I
don't think any maintainer / contributor expressed an opinion, and
IIUC patch policy for binutils is (lightly) documented at
https://sourceware.org/binutils/wiki/HowToContribute
Maybe Nick can update it? (I don't have such rights)

Thanks,

Christophe

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

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

[Richard Earnshaw (lists)]

On 25/04/2024 15:59, Richard Ball wrote:
> 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.

Yes, if that's the correct thing to do there.

R.

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

[Richard Earnshaw (lists)]

On 26/04/2024 09:39, Torbjorn SVENSSON wrote:
> Hi,
> 
> On 2024-04-25 16:25, Richard Ball wrote:
>> 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.
> 
> For verifying that the implementation does the right thing now, no, but for 
> verifying against future regressions, then yes.
> 
> So, from a regression point of view, I think it makes sense to have the check 
> that more than the first argument is managed properly.
> 
> Kind regards,
> Torbjörn

Feel free to post some additional tests, Torbjorn.

R.

Re: [PATCH] i386: Fix array index overflow in pr105354-2.c

[Uros Bizjak]

On Fri, Apr 26, 2024 at 11:03 AM Haochen Jiang  wrote:
>
> Hi all,
>
> The array index should not be over 8 for v8hi, or it will fail
> under -O0 or using -fstack-protector.
>
> This patch aims to fix that, which is mentioned in PR110621.
>
> Commit as obvious and backport to GCC13.
>
> Thx,
> Haochen
>
> gcc/testsuite/ChangeLog:
>
> PR target/110621
> * gcc.target/i386/pr105354-2.c: As mentioned.

Please note that the ChangeLog entry gets copied into the relevant
ChangeLog file independently of the commit message. So, the above
entry will be copied to gcc/testsuite/ChangeLog without any reference
to what was mentioned.

Uros.

> ---
>  gcc/testsuite/gcc.target/i386/pr105354-2.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/gcc/testsuite/gcc.target/i386/pr105354-2.c 
> b/gcc/testsuite/gcc.target/i386/pr105354-2.c
> index b78b62e1e7e..1c592e84860 100644
> --- a/gcc/testsuite/gcc.target/i386/pr105354-2.c
> +++ b/gcc/testsuite/gcc.target/i386/pr105354-2.c
> @@ -17,7 +17,7 @@ sse2_test (void)
>b.a[i] = i + 16;
>res_ab.a[i] = 0;
>exp_ab.a[i] = -1;
> -  if (i <= 8)
> +  if (i < 8)
> {
>   c.a[i] = i;
>   d.a[i] = i + 8;
> --
> 2.31.1
>

[PATCH] i386: Fix array index overflow in pr105354-2.c

[Haochen Jiang]

Hi all,

The array index should not be over 8 for v8hi, or it will fail
under -O0 or using -fstack-protector.

This patch aims to fix that, which is mentioned in PR110621.

Commit as obvious and backport to GCC13.

Thx,
Haochen

gcc/testsuite/ChangeLog:

PR target/110621
* gcc.target/i386/pr105354-2.c: As mentioned.
---
 gcc/testsuite/gcc.target/i386/pr105354-2.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.target/i386/pr105354-2.c 
b/gcc/testsuite/gcc.target/i386/pr105354-2.c
index b78b62e1e7e..1c592e84860 100644
--- a/gcc/testsuite/gcc.target/i386/pr105354-2.c
+++ b/gcc/testsuite/gcc.target/i386/pr105354-2.c
@@ -17,7 +17,7 @@ sse2_test (void)
   b.a[i] = i + 16;
   res_ab.a[i] = 0;
   exp_ab.a[i] = -1;
-  if (i <= 8)
+  if (i < 8)
{
  c.a[i] = i;
  d.a[i] = i + 8;
-- 
2.31.1

Re: [PATCH] amdgcn: Add gfx90c target

[Andrew Stubbs]

On 25/04/2024 19:37, Frederik Harwath wrote:

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?


OK, please go ahead.

Thanks for expanding our device support even further! :)

Andrew

[COMMITTED] gcc-14: Add Ada changes

[Marc Poulhiès]

Co-authored-by: Fernando Oleo Blanco 
Co-authored-by: Piotr Trojanek 
Signed-off-by: Marc Poulhiès 
---
 htdocs/gcc-14/changes.html | 67 +-
 1 file changed, 66 insertions(+), 1 deletion(-)

diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
index 83b1016c..87e04cb8 100644
--- a/htdocs/gcc-14/changes.html
+++ b/htdocs/gcc-14/changes.html
@@ -239,7 +239,72 @@ a work-in-progress.
   
 
 
-
+Ada
+
+
+  New implementation-defined aspects and pragmas:
+
+  https://gcc.gnu.org/onlinedocs/gnat_rm/Aspect-Local_005fRestrictions.html";>Local_Restrictions,
+  which specifies that a particular subprogram does not violate one or more
+  local restrictions, nor can it call a subprogram that is not subject to
+  the same requirements.
+  https://gcc.gnu.org/onlinedocs/gnat_rm/Pragma-User_005fAspect_005fDefinition.html";>User_Aspect_Definition
+  and https://gcc.gnu.org/onlinedocs/gnat_rm/Aspect-User_005fAspect.html";>User_Aspect,
+  which provide a mechanism for avoiding textual duplication if some set of
+  aspect specifications is needed in multiple places.
+
+  
+  New implementation-defined aspects and pragmas for verification of the
+  SPARK 2014 subset of Ada:
+
+  https://gcc.gnu.org/onlinedocs/gnat_rm/Aspect-Always_005fTerminates.html";>Always_Terminates,
+  which provides a condition for a subprogram to necessarily complete
+  (either return normally or raise an exception).
+  https://gcc.gnu.org/onlinedocs/gnat_rm/Aspect-Ghost_005fPredicate.html";>Ghost_Predicate,
+  which introduces a subtype predicate that can reference Ghost entities.
+  
+  https://gcc.gnu.org/onlinedocs/gnat_rm/Aspect-Exceptional_005fCases.html";>Exceptional_Cases,
+  which lists exceptions that might be propagated by the subprogram with
+  side effects in the context of its precondition and associates them with 
a
+  specific postcondition.
+  
+  https://gcc.gnu.org/onlinedocs/gnat_rm/Aspect-Side_005fEffects.html";>Side_Effects,
+  which indicates that a function should be handled like a procedure with
+  respect to parameter modes, Global contract, exceptional contract and
+  termination: it may have output parameters, write global variables, raise
+  exceptions and not terminate.
+
+  
+  The new attributes and contracts have been applied to the relevant parts
+  of the Ada runtime library, which has been subsequently proven to be correct
+  with SPARK 2014.
+  Initial support for the
+  https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/";>CHERI
+  architecture.
+  Support for the LoongArch architecture.
+  Support for vxWorks 7 Cert RTP has been removed.
+  Additional hardening improvements. For more information reltated to
+hardening options, refer to
+the https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html#index-fharden-compares";>GCC
+Instrumentation Options and
+the https://gcc.gnu.org/onlinedocs/gnat_rm/Security-Hardening-Features.html";>GNAT
+Reference Manual, Security and Hardening Features.
+  
+  Improve style checking for redundant parentheses
+  with https://gcc.gnu.org/onlinedocs/gnat_ugn/Style-Checking.html#index--gnatyz-_0028gcc_0029";>-gnatyz
+  New
+  switch https://gcc.gnu.org/onlinedocs/gnat_ugn/Alphabetical-List-of-All-Switches.html#index--gnateH-_0028gcc_0029";>-gnateH
+  to force reverse Bit_Order threshold to 64.
+  Experimental features:
+https://gcc.gnu.org/onlinedocs/gnat_rm/Pragma-Storage_005fModel.html";>Storage
+Model: this feature proposes to redesign the concepts of Storage Pools
+into a more efficient model allowing higher performances and easier
+integration with low footprint embedded run-times.
+https://gcc.gnu.org/onlinedocs/gnat_rm/String-interpolation.html";>String
+Interpolation: allows for easier string formatting.
+  
+  Further clean up and improvements to the GNAT code.
+
 
 
 
-- 
2.43.2

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

[Torbjorn SVENSSON]

Hi,

On 2024-04-25 16:25, Richard Ball wrote:

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.


For verifying that the implementation does the right thing now, no, but 
for verifying against future regressions, then yes.


So, from a regression point of view, I think it makes sense to have the 
check that more than the first argument is managed properly.


Kind regards,
Torbjörn

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

[Christophe Lyon]

On Thu, 25 Apr 2024 at 17:44, Carlos O'Donell  wrote:
>
> 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.

Thank you Carlos for the patch and helping with the discussions!

Christophe

> ---
>  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] PR middle-end/111701: signbit(x*x) vs -fsignaling-nans

[Roger Sayle]

This patch addresses PR middle-end/111701 where optimization of signbit(x*x)
using tree_nonnegative_p incorrectly eliminates a floating point
multiplication when the operands may potentially be signaling NaNs.

The above bug fix also provides a solution or work-around to the tricky
issue in PR middle-end/111701, that the results of IEEE operations on NaNs
are specified to return a NaN result, but fail to (precisely) specify
the exact NaN representation of this result.  Hence for the operation
"-NaN*-NaN" different hardware implementations (targets) return different
results.  Ultimately knowing what the resulting NaN "payload" of an
operation is can only be known by executing that operation at run-time,
and I'd suggest that GCC's -fsignaling-nans provides a mechanism for
handling code that uses NaN representations for communication/signaling
(which is a different but related concept to IEEE's sNaN).

One nice thing about this patch, which may or may not be a P2 regression
fix, is that it only affects (improves) code compiled with -fsignaling-nans
so should be extremely safe even for this point in stage 3.

This patch has been tested on x86_64-pc-linux-gnu with make bootstrap
and make -k check, both with and without --target_board=unix{-m32}
with no new failures.  Ok for mainline?


2024-04-26  Roger Sayle  

gcc/ChangeLog
PR middle-end/111701
* fold-const.cc (tree_binary_nonnegative_warnv_p) :
Split handling of floating point and integer types.  For equal
floating point operands, avoid optimization if the operand may be
a signaling NaN.

gcc/testsuite/ChangeLog
PR middle-end/111701
* gcc.dg/pr111701-1.c: New test case.
* gcc.dg/pr111701-2.c: Likewise.


Thanks in advance,
Roger
--

diff --git a/gcc/fold-const.cc b/gcc/fold-const.cc
index 7b26896..f7f174d 100644
--- a/gcc/fold-const.cc
+++ b/gcc/fold-const.cc
@@ -15076,16 +15076,27 @@ tree_binary_nonnegative_warnv_p (enum tree_code code, 
tree type, tree op0,
   break;
 
 case MULT_EXPR:
-  if (FLOAT_TYPE_P (type) || TYPE_OVERFLOW_UNDEFINED (type))
+  if (FLOAT_TYPE_P (type))
{
- /* x * x is always non-negative for floating point x
-or without overflow.  */
+ /* x * x is non-negative for floating point x except
+that -NaN*-NaN may return -NaN.  PR middle-end/111701.  */
+ if (operand_equal_p (op0, op1, 0))
+   {
+ if (!tree_expr_maybe_signaling_nan_p (op0) || RECURSE (op0))
+   return true;
+   }
+ else if (RECURSE (op0) && RECURSE (op1))
+   return true;
+   }
+
+  if (ANY_INTEGRAL_TYPE_P (type)
+ && TYPE_OVERFLOW_UNDEFINED (type))
+   {
+ /* x * x is always non-negative without overflow.  */
  if (operand_equal_p (op0, op1, 0)
  || (RECURSE (op0) && RECURSE (op1)))
{
- if (ANY_INTEGRAL_TYPE_P (type)
- && TYPE_OVERFLOW_UNDEFINED (type))
-   *strict_overflow_p = true;
+ *strict_overflow_p = true;
  return true;
}
}
diff --git a/gcc/testsuite/gcc.dg/pr111701-1.c 
b/gcc/testsuite/gcc.dg/pr111701-1.c
new file mode 100644
index 000..5cbfac2
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr111701-1.c
@@ -0,0 +1,14 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fsignaling-nans -fdump-tree-optimized" } */
+
+int foo(double x)
+{
+return __builtin_signbit(x*x);
+}
+
+int bar(float x)
+{
+return __builtin_signbit(x*x);
+}
+
+/* { dg-final { scan-tree-dump-times " \\* " 2 "optimized" } } */
diff --git a/gcc/testsuite/gcc.dg/pr111701-2.c 
b/gcc/testsuite/gcc.dg/pr111701-2.c
new file mode 100644
index 000..f79c7ba
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr111701-2.c
@@ -0,0 +1,14 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-optimized" } */
+
+int foo(double x)
+{
+return __builtin_signbit(x*x);
+}
+
+int bar(float x)
+{
+return __builtin_signbit(x*x);
+}
+
+/* { dg-final { scan-tree-dump-not " \\* " "optimized" } } */