Re: [PATCH v3 1/2] c++: Initial support for P0847R7 (Deducing This) [PR102609]

[waffl3x]

> > That leaves 2, 4, and 5.
> > 
> > 2. I am pretty sure xobj functions should have the struct they are a
> > part of recorded as the method basetype member. I have already checked
> > that function_type and method_type are the same node type under the
> > hood and it does appear to be, so it should be trivial to set it.
> > However I do have to wonder why static member functions don't set it,
> > it seems to be that it would be convenient to use the same field. Can
> > you provide any insight into that?
> 
> 
> method basetype is only for METHOD_TYPE; if you want the containing type
> of the function, that's DECL_CONTEXT.

-- gcc/tree.h:530
#define FUNC_OR_METHOD_CHECK(T) TREE_CHECK2 (T, FUNCTION_TYPE, METHOD_TYPE)
-- gcc/tree.h:2518
#define TYPE_METHOD_BASETYPE(NODE)  \
  (FUNC_OR_METHOD_CHECK (NODE)->type_non_common.maxval)

The code doesn't seem to reflect that, perhaps since the underlying
node type is the same (as far as I can tell, they both inherit from
tree_type_non_common) it wasn't believed to be necessary.

Upon looking at DECL_CONTEXT though I see it seems you were thinking of
FUNCTION_DECL. I haven't observed DECL_CONTEXT being set for
FUNCTION_DECL nodes though, perhaps it should be? Although it's more
likely that it is being set and I just haven't noticed, but if that's
the case I'll have to make a note to make sure it is being set for xobj
member functions.

I was going to say that this seems like a redundancy, but I realized
that the type of a member function pointer is tied to the struct, so it
actually ends up relevant for METHOD_TYPE nodes. I would hazard a guess
that when forming member function pointers the FUNCTION_DECL node was
not as easily accessed. If I remember correctly that is not the case
right now so it might be worthwhile to refactor away from
TYPE_METHOD_BASETYPE and replace uses of it with DECL_CONTEXT.

I'm getting ahead of myself though, I'll stop here and avoid going on
too much of a refactoring tangent. I do want this patch to make it into
GCC14 after all.

> > 4. I have no comment here, but it does concern me since I don't
> > understand it at all.
> 
> 
> In the list near the top of cp-tree.h, DECL_LANG_FLAG_6 for a
> FUNCTION_DECL is documented to be DECL_THIS_STATIC, which should only be
> set on the static member.

Right, I'll try to remember to check this area in the future, but yeah
that tracks because I did remove that flag. Removing that flag just so
happened to be the start of this saga of bug fixes but alas, it had to
be done.

> > 5. I am pretty sure this is fine for now, but if xobj member functions
> > ever were to support virtual/override capabilities, then it would be a
> > problem. Is my understanding correct, or is there some other reason
> > that iobj member functions have a different value here?
> 
> 
> It is surprising that an iobj memfn would have a different DECL_ALIGN,
> but it shouldn't be a problem; the vtables only rely on alignment being
> at least 2.

I'll put a note for myself to look into it in the future, it's an
oddity at minimum and oddities interest me :^).

> > There are also some differences in the arg param in
> > cp_build_addr_expr_1 that concerns me, but most of them are reflected
> > in the differences I have already noted. I had wanted to include these
> > differences as well but I have been spending too much time staring at
> > it, it's no longer productive. In short, the indirect_ref node for xobj
> > member functions has reference_to_this set, while iobj member functions
> > do not.
> 
> 
> That's a result of difference 3.

Okay, makes sense, I'm mildly concerned about any possible side effects
this might have since we have a function_type node suddenly going
through execution paths that only method_type went through before. The
whole "reference_to_this" "pointer_to_this" thing is a little confusing
because I'm pretty sure that doesn't refer to the actual `this` object
argument or parameter since I've seen it all over the place. Hopefully
it's benign.

> > The baselink binfo field has the private flag set for xobj
> > member functions, iobj member functions does not.
> 
> 
> TREE_PRIVATE on a binfo is part of BINFO_ACCESS, which isn't a fixed
> value, but gets updated during member search. Perhaps the differences
> in consideration of conversion to a base led to it being set or cleared
> differently? I wouldn't worry too much about it unless you see
> differences in access control.

Unfortunately I don't have any tests for private/public access yet,
it's one of the area's I've neglected. Unfortunately I probably won't
put too much effort into writing TOO many more right now as it takes up
a lot of my time. I still have to clean up the ones I currently have
and I have a few I wanted to write that are not yet written.

> > I've spent too much time on this write up, so I am calling it here, it
> > wasn't all a waste of time because half of what I was doing here are
> > things I was going to need to do 

Re: [PATCH] recog/reload: Remove old UNARY_P operand support

[Hans-Peter Nilsson]

> From: Richard Sandiford 
> Date: Tue, 24 Oct 2023 11:14:20 +0100

> reload and constrain_operands had some old code to look through unary
> operators.  E.g. an operand could be (sign_extend (reg X)), and the
> constraints would match the reg rather than the sign_extend.
> 
> This was previously used by the MIPS port.  But relying on it was a
> recurring source of problems, so Eric and I removed it in the MIPS
> rewrite from ~20 years back.  I don't know of any other port that used it.

The SH did.  I remember this being one of the ugliest warts
of reload.  IIRC, there was a bit of a discourse involving
me and Joern way-back (also IIRC some 20 years ago, at least
before IRA and LRA).  The conclusion was that removing this
misfeature would be ok, as already at that time, there was
no de-facto beneficial effect for sh, likely due to code
rot.  However, no action was taken; no code changed.

Thanks for removing the last(?) bits!

brgds, H-P

Re: [PATCH v2] RISC-V: Refactor prefix [I/L/LL] rounding API autovec iterator

[juzhe.zh...@rivai.ai]

LGTM.



juzhe.zh...@rivai.ai
 
From: pan2.li
Date: 2023-11-03 11:26
To: gcc-patches
CC: juzhe.zhong; pan2.li; yanzhang.wang; kito.cheng
Subject: [PATCH v2] RISC-V: Refactor prefix [I/L/LL] rounding API autovec 
iterator
From: Pan Li 
 
Update in v2:
 
* Add mode size equal check to disable different mode size when expand,
  because the underlying codegen is not implemented yet.
 
Original log:
 
The previous rounding API start with i/l/ll only works on the same
mode types. For example as below, and we arrange the iterator similar
to fcvt.
 
* SF => SI
* DF => DI
 
After we refined this limination from middle-end, these API can also
vectorized with different type sizes, aka:
 
* HF => SI, HF => DI
* SF => DI, SF => SI
* DF => SI, DF => DI
 
Then the iterator cannot take care of this simply and this patch
would like to re-arrange the iterator in two items.
 
* V_VLS_F_CONVERT_SI: handle (HF, SF, DF) => SI
* V_VLS_F_CONVERT_DI: handle (HF, SF, DF) => DI
 
As well as related mode_attr to reconcile the new iterator.
 
gcc/ChangeLog:
 
* config/riscv/autovec.md (lrint2): Remove.
(lround2): Ditto.
(lceil2): Ditto.
(lfloor2): Ditto.
(lrint2): New pattern for cvt from
FP to SI.
(lround2): Ditto.
(lceil2): Ditto.
(lfloor2): Ditto.
(lrint2): New pattern for cvt from
FP to DI.
(lround2): Ditto.
(lceil2): Ditto.
(lfloor2): Ditto.
* config/riscv/vector-iterators.md: Renew iterators for both
the SI and DI.
 
Signed-off-by: Pan Li 
---
gcc/config/riscv/autovec.md  |  90 +---
gcc/config/riscv/vector-iterators.md | 199 ---
2 files changed, 251 insertions(+), 38 deletions(-)
 
diff --git a/gcc/config/riscv/autovec.md b/gcc/config/riscv/autovec.md
index f5e3e347ace..cc4c9596bbf 100644
--- a/gcc/config/riscv/autovec.md
+++ b/gcc/config/riscv/autovec.md
@@ -2395,42 +2395,92 @@ (define_expand "roundeven2"
   }
)
-(define_expand "lrint2"
-  [(match_operand:0 "register_operand")
-   (match_operand:V_VLS_FCONVERT_I_L_LL 1 "register_operand")]
-  "TARGET_VECTOR && !flag_trapping_math && !flag_rounding_math"
+;; Add mode_size equal check as we opened the modes for different sizes.
+;; The check will be removed soon after related codegen implemented
+(define_expand "lrint2"
+  [(match_operand:   0 "register_operand")
+   (match_operand:V_VLS_F_CONVERT_SI 1 "register_operand")]
+  "TARGET_VECTOR && !flag_trapping_math && !flag_rounding_math
+&& known_eq (GET_MODE_SIZE (mode), GET_MODE_SIZE 
(mode))"
   {
-riscv_vector::expand_vec_lrint (operands[0], operands[1], mode, 
mode);
+riscv_vector::expand_vec_lrint (operands[0], operands[1], mode, 
mode);
 DONE;
   }
)
-(define_expand "lround2"
-  [(match_operand:0 "register_operand")
-   (match_operand:V_VLS_FCONVERT_I_L_LL 1 "register_operand")]
-  "TARGET_VECTOR && !flag_trapping_math && !flag_rounding_math"
+(define_expand "lrint2"
+  [(match_operand:   0 "register_operand")
+   (match_operand:V_VLS_F_CONVERT_DI 1 "register_operand")]
+  "TARGET_VECTOR && !flag_trapping_math && !flag_rounding_math
+&& known_eq (GET_MODE_SIZE (mode), GET_MODE_SIZE 
(mode))"
   {
-riscv_vector::expand_vec_lround (operands[0], operands[1], mode, 
mode);
+riscv_vector::expand_vec_lrint (operands[0], operands[1], mode, 
mode);
 DONE;
   }
)
-(define_expand "lceil2"
-  [(match_operand:0 "register_operand")
-   (match_operand:V_VLS_FCONVERT_I_L_LL 1 "register_operand")]
-  "TARGET_VECTOR && !flag_trapping_math && !flag_rounding_math"
+(define_expand "lround2"
+  [(match_operand:   0 "register_operand")
+   (match_operand:V_VLS_F_CONVERT_SI 1 "register_operand")]
+  "TARGET_VECTOR && !flag_trapping_math && !flag_rounding_math
+&& known_eq (GET_MODE_SIZE (mode), GET_MODE_SIZE 
(mode))"
   {
-riscv_vector::expand_vec_lceil (operands[0], operands[1], mode, 
mode);
+riscv_vector::expand_vec_lround (operands[0], operands[1], mode, 
mode);
 DONE;
   }
)
-(define_expand "lfloor2"
-  [(match_operand:0 "register_operand")
-   (match_operand:V_VLS_FCONVERT_I_L_LL 1 "register_operand")]
-  "TARGET_VECTOR && !flag_trapping_math && !flag_rounding_math"
+(define_expand "lround2"
+  [(match_operand:   0 "register_operand")
+   (match_operand:V_VLS_F_CONVERT_DI 1 "register_operand")]
+  "TARGET_VECTOR && !flag_trapping_math && !flag_rounding_math
+&& known_eq (GET_MODE_SIZE (mode), GET_MODE_SIZE 
(mode))"
+  {
+riscv_vector::expand_vec_lround (operands[0], operands[1], mode, 
mode);
+DONE;
+  }
+)
+
+(define_expand "lceil2"
+  [(match_operand:   0 "register_operand")
+   (match_operand:V_VLS_F_CONVERT_SI 1 "register_operand")]
+  "TARGET_VECTOR && !flag_trapping_math && !flag_rounding_math
+&& known_eq (GET_MODE_SIZE (mode), GET_MODE_SIZE 
(mode))"
+  {
+riscv_vector::expand_vec_lceil (operands[0], operands[1], mode, 
mode);
+DONE;
+  }
+)
+
+(define_expand "lceil2"
+  [(match_operand:   0 "register_operand")
+   (match_operand:V_VLS_F_CONVERT_DI 1 "register_operand")]
+  "TARGET_VECTOR && 

[PATCH v2] RISC-V: Refactor prefix [I/L/LL] rounding API autovec iterator

[pan2 . li]

From: Pan Li 

Update in v2:

* Add mode size equal check to disable different mode size when expand,
  because the underlying codegen is not implemented yet.

Original log:

The previous rounding API start with i/l/ll only works on the same
mode types. For example as below, and we arrange the iterator similar
to fcvt.

* SF => SI
* DF => DI

After we refined this limination from middle-end, these API can also
vectorized with different type sizes, aka:

* HF => SI, HF => DI
* SF => DI, SF => SI
* DF => SI, DF => DI

Then the iterator cannot take care of this simply and this patch
would like to re-arrange the iterator in two items.

* V_VLS_F_CONVERT_SI: handle (HF, SF, DF) => SI
* V_VLS_F_CONVERT_DI: handle (HF, SF, DF) => DI

As well as related mode_attr to reconcile the new iterator.

gcc/ChangeLog:

* config/riscv/autovec.md (lrint2): Remove.
(lround2): Ditto.
(lceil2): Ditto.
(lfloor2): Ditto.
(lrint2): New pattern for cvt from
FP to SI.
(lround2): Ditto.
(lceil2): Ditto.
(lfloor2): Ditto.
(lrint2): New pattern for cvt from
FP to DI.
(lround2): Ditto.
(lceil2): Ditto.
(lfloor2): Ditto.
* config/riscv/vector-iterators.md: Renew iterators for both
the SI and DI.

Signed-off-by: Pan Li 
---
 gcc/config/riscv/autovec.md  |  90 +---
 gcc/config/riscv/vector-iterators.md | 199 ---
 2 files changed, 251 insertions(+), 38 deletions(-)

diff --git a/gcc/config/riscv/autovec.md b/gcc/config/riscv/autovec.md
index f5e3e347ace..cc4c9596bbf 100644
--- a/gcc/config/riscv/autovec.md
+++ b/gcc/config/riscv/autovec.md
@@ -2395,42 +2395,92 @@ (define_expand "roundeven2"
   }
 )
 
-(define_expand "lrint2"
-  [(match_operand:0 "register_operand")
-   (match_operand:V_VLS_FCONVERT_I_L_LL 1 "register_operand")]
-  "TARGET_VECTOR && !flag_trapping_math && !flag_rounding_math"
+;; Add mode_size equal check as we opened the modes for different sizes.
+;; The check will be removed soon after related codegen implemented
+(define_expand "lrint2"
+  [(match_operand:   0 "register_operand")
+   (match_operand:V_VLS_F_CONVERT_SI 1 "register_operand")]
+  "TARGET_VECTOR && !flag_trapping_math && !flag_rounding_math
+&& known_eq (GET_MODE_SIZE (mode), GET_MODE_SIZE 
(mode))"
   {
-riscv_vector::expand_vec_lrint (operands[0], operands[1], mode, 
mode);
+riscv_vector::expand_vec_lrint (operands[0], operands[1], mode, 
mode);
 DONE;
   }
 )
 
-(define_expand "lround2"
-  [(match_operand:0 "register_operand")
-   (match_operand:V_VLS_FCONVERT_I_L_LL 1 "register_operand")]
-  "TARGET_VECTOR && !flag_trapping_math && !flag_rounding_math"
+(define_expand "lrint2"
+  [(match_operand:   0 "register_operand")
+   (match_operand:V_VLS_F_CONVERT_DI 1 "register_operand")]
+  "TARGET_VECTOR && !flag_trapping_math && !flag_rounding_math
+&& known_eq (GET_MODE_SIZE (mode), GET_MODE_SIZE 
(mode))"
   {
-riscv_vector::expand_vec_lround (operands[0], operands[1], mode, 
mode);
+riscv_vector::expand_vec_lrint (operands[0], operands[1], mode, 
mode);
 DONE;
   }
 )
 
-(define_expand "lceil2"
-  [(match_operand:0 "register_operand")
-   (match_operand:V_VLS_FCONVERT_I_L_LL 1 "register_operand")]
-  "TARGET_VECTOR && !flag_trapping_math && !flag_rounding_math"
+(define_expand "lround2"
+  [(match_operand:   0 "register_operand")
+   (match_operand:V_VLS_F_CONVERT_SI 1 "register_operand")]
+  "TARGET_VECTOR && !flag_trapping_math && !flag_rounding_math
+&& known_eq (GET_MODE_SIZE (mode), GET_MODE_SIZE 
(mode))"
   {
-riscv_vector::expand_vec_lceil (operands[0], operands[1], mode, 
mode);
+riscv_vector::expand_vec_lround (operands[0], operands[1], mode, 
mode);
 DONE;
   }
 )
 
-(define_expand "lfloor2"
-  [(match_operand:0 "register_operand")
-   (match_operand:V_VLS_FCONVERT_I_L_LL 1 "register_operand")]
-  "TARGET_VECTOR && !flag_trapping_math && !flag_rounding_math"
+(define_expand "lround2"
+  [(match_operand:   0 "register_operand")
+   (match_operand:V_VLS_F_CONVERT_DI 1 "register_operand")]
+  "TARGET_VECTOR && !flag_trapping_math && !flag_rounding_math
+&& known_eq (GET_MODE_SIZE (mode), GET_MODE_SIZE 
(mode))"
+  {
+riscv_vector::expand_vec_lround (operands[0], operands[1], mode, 
mode);
+DONE;
+  }
+)
+
+(define_expand "lceil2"
+  [(match_operand:   0 "register_operand")
+   (match_operand:V_VLS_F_CONVERT_SI 1 "register_operand")]
+  "TARGET_VECTOR && !flag_trapping_math && !flag_rounding_math
+&& known_eq (GET_MODE_SIZE (mode), GET_MODE_SIZE 
(mode))"
+  {
+riscv_vector::expand_vec_lceil (operands[0], operands[1], mode, 
mode);
+DONE;
+  }
+)
+
+(define_expand "lceil2"
+  [(match_operand:   0 "register_operand")
+   (match_operand:V_VLS_F_CONVERT_DI 1 "register_operand")]
+  "TARGET_VECTOR && !flag_trapping_math && !flag_rounding_math
+&& known_eq (GET_MODE_SIZE (mode), GET_MODE_SIZE 

[Bug libbacktrace/112263] [C++23] std::stacktrace does not identify symbols in shared library

[ian at airs dot com via Gcc-bugs]

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

--- Comment #7 from Ian Lance Taylor  ---
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/635073.html

Re: [PATCH v3 1/2] c++: Initial support for P0847R7 (Deducing This) [PR102609]

[Jason Merrill]

On 10/28/23 00:07, waffl3x wrote:

I wanted to change DECL_NONSTATIC_MEMBER_FUNCTION_P to include explicit
object member functions, but it had some problems when I made the
modification. I also noticed that it's used in cp-objcp-common.cc so
would making changes to it be a bad idea?

-- cp-tree.h
```
/* Nonzero for FUNCTION_DECL means that this decl is a non-static
member function.  */
#define DECL_NONSTATIC_MEMBER_FUNCTION_P(NODE) \
   (TREE_CODE (TREE_TYPE (NODE)) == METHOD_TYPE)
```
I didn't want to investigate the problems as I was knee deep in
investigating the addressof bug. So I instead modified
DECL_FUNCTION_MEMBER_P to include explicit object member functions and
moved on.

-- cp-tree.h
```
/* Nonzero for FUNCTION_DECL means that this decl is a member function
(static or non-static).  */
#define DECL_FUNCTION_MEMBER_P(NODE) \
   (DECL_NONSTATIC_MEMBER_FUNCTION_P (NODE) || DECL_STATIC_FUNCTION_P (NODE) \
   || DECL_IS_XOBJ_MEMBER_FUNC (NODE))
```
I am mostly just mentioning this here in case it becomes more relevant
later. Looking at how much DECL_NONSTATIC_MEMBER_FUNCTION_P is used
throughout the code I now suspect that adding explicit object member
functions to it might cause xobj member functions to be treated as
regular member functions when they should not be.

If this change were to stick it would cause a discrepancy in the
behavior of DECL_NONSTATIC_MEMBER_FUNCTION_P and it's name. If we were
to do this, I think it's important we document the discrepancy and why
it exists, and in the future, it should possibly be refactored. One
option would be to simply rename it to DECL_IOBJ_MEMBER_FUNCTION_P.
After all, I suspect that it's unlikely that the current macro
(DECL_NONSTATIC_MEMBER_FUNCTION_P) is being used in places that concern
explicit object member functions. So just adding explicit object member
functions to it will most likely just result in headaches.

It seems to me that would be the best solution, so when and if it comes
up again, I think that route should be considered.


Agreed, it sounds good to rename the current macro and then add a new 
macro that includes both implicit and explicit, assuming that's a useful 
category.



Secondly, there are some differences in the nodes describing an
explicit object member function from those describing static member
functions and implicit object member functions that I am not sure
should be present.

I did my best to summarize the differences, if you want the logs of
tree_debug that I derived them from I can provide them. Most of my
understanding of the layout of the nodes is from reading print-tree.cc
and looking at debug_tree outputs, so it's possible I made a mistake.

I am opting to use the names of members as they are output by
debug_tree, I recognize this is not always the actual name of the
member in the actual tree_node structures.

Additionally, some of the differences listed are to be expected and are
most likely the correct values for each node. However, I wanted to be
exhaustive when listing them just in case I am mistaken in my opinion
on whether the differences should or should not occur.

The following declarations were used as input to the compiler.
iobj decl:
struct S { void f() {} };
xobj decl:
struct S { void f(this S&) {} };
static decl:
struct S { static void f(S&) {} };

These differences can be observed in the return values of
grokdeclarator for each declaration.

1. function_decl::type::tree_code
iobj: method_type
xobj: function_type
stat: function_type
2. function_decl::type::method basetype
iobj: 
xobj: NULL/no output
stat: NULL/no output
3. function_decl::type::arg-types::tree_list[0]::value
iobj: 
xobj: 
stat: 
4. function_decl::decl_6
iobj: false/no output
xobj: false/no output
stat: true
5. function_decl::align
iobj: 16
xobj: 8
stat: 8
6. function_decl::result::uid
iobj: D.2513
xobj: D.2513
stat: D.2512
7. function_decl::full-name
iobj: "void S::f()"
xobj: "void S::f(this S&)"

Differences 1, 3, and 7 seem obviously correct to me for all 3
declarations, 6 is a little bizarre to me, but since it's just a UID
it's merely an oddity, I doubt it is concerning.


Agreed.


That leaves 2, 4, and 5.

2. I am pretty sure xobj functions should have the struct they are a
part of recorded as the method basetype member. I have already checked
that function_type and method_type are the same node type under the
hood and it does appear to be, so it should be trivial to set it.
However I do have to wonder why static member functions don't set it,
it seems to be that it would be convenient to use the same field. Can
you provide any insight into that?


method basetype is only for METHOD_TYPE; if you want the containing type 
of the function, that's DECL_CONTEXT.



4. I have no comment here, but it does concern me since I don't
understand it at all.


In the list near the top of cp-tree.h, DECL_LANG_FLAG_6 for a 
FUNCTION_DECL is documented to be DECL_THIS_STATIC, which should only be 
set on the static member.



5. I am 

libstdc++ patch RFA: Fix dl_iterate_phdr configury for libbacktrace

[Ian Lance Taylor]

The libbacktrace sources, as used by libstdc++-v3, fail to correctly
determine whether the system supports dl_iterate_phdr.  The issue is
that the libbacktrace configure assumes that _GNU_SOURCE is defined
during compilation, but the libstdc++-v3 configure does not do that.
This configury failure is the cause of PR 112263.

This patch fixes the problem.  OK for mainline?

Ian

PR libbacktrace/112263
* acinclude.m4: Set -D_GNU_SOURCE in BACKTRACE_CPPFLAGS and when
grepping link.h for dl_iterate_phdr.
* configure: Regenerate.
diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4
index d8f0ba1c3e2..41446c2c3d6 100644
--- a/libstdc++-v3/acinclude.m4
+++ b/libstdc++-v3/acinclude.m4
@@ -5443,7 +5443,7 @@ AC_DEFUN([GLIBCXX_ENABLE_BACKTRACE], [
 
   # Most of this is adapted from libsanitizer/configure.ac
 
-  BACKTRACE_CPPFLAGS=
+  BACKTRACE_CPPFLAGS="-D_GNU_SOURCE"
 
   # libbacktrace only needs atomics for int, which we've already tested
   if test "$glibcxx_cv_atomic_int" = "yes"; then
@@ -5471,8 +5471,11 @@ AC_DEFUN([GLIBCXX_ENABLE_BACKTRACE], [
 have_dl_iterate_phdr=no
   else
 # When built as a GCC target library, we can't do a link test.
+ac_save_CPPFLAGS="$CPPFLAGS"
+CPPFLAGS="$CPPFLAGS -D_GNU_SOURCE"
 AC_EGREP_HEADER([dl_iterate_phdr], [link.h], [have_dl_iterate_phdr=yes],
[have_dl_iterate_phdr=no])
+CPPFLAGS="$ac_save_CPPFLAGS"
   fi
   if test "$have_dl_iterate_phdr" = "yes"; then
 BACKTRACE_CPPFLAGS="$BACKTRACE_CPPFLAGS -DHAVE_DL_ITERATE_PHDR=1"
diff --git a/libstdc++-v3/configure b/libstdc++-v3/configure
index 9f12c5baa3f..693564d3c7e 100755
--- a/libstdc++-v3/configure
+++ b/libstdc++-v3/configure
@@ -73299,7 +73299,7 @@ fi
 
   # Most of this is adapted from libsanitizer/configure.ac
 
-  BACKTRACE_CPPFLAGS=
+  BACKTRACE_CPPFLAGS="-D_GNU_SOURCE"
 
   # libbacktrace only needs atomics for int, which we've already tested
   if test "$glibcxx_cv_atomic_int" = "yes"; then
@@ -73382,6 +73382,8 @@ done
 have_dl_iterate_phdr=no
   else
 # When built as a GCC target library, we can't do a link test.
+ac_save_CPPFLAGS="$CPPFLAGS"
+CPPFLAGS="$CPPFLAGS -D_GNU_SOURCE"
 cat confdefs.h - <<_ACEOF >conftest.$ac_ext
 /* end confdefs.h.  */
 #include 
@@ -73395,6 +73397,7 @@ else
 fi
 rm -f conftest*
 
+CPPFLAGS="$ac_save_CPPFLAGS"
   fi
   if test "$have_dl_iterate_phdr" = "yes"; then
 BACKTRACE_CPPFLAGS="$BACKTRACE_CPPFLAGS -DHAVE_DL_ITERATE_PHDR=1"

[Bug target/111311] RISC-V regression testsuite errors with --param=riscv-autovec-preference=scalable

[law at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #14 from Jeffrey A. Law  ---
As Andrew said, if there's a test that depends on behavior of -INT_MIN, then
the test needs to be fixed.  That's undefined behavior.

Re: [PATCH] c++: Implement C++26 P1854R4 - Making non-encodable string literals ill-formed [PR110341]

[Jason Merrill]

On 11/2/23 03:53, Jakub Jelinek wrote:

On Fri, Oct 27, 2023 at 07:05:34PM -0400, Jason Merrill wrote:

--- gcc/testsuite/g++.dg/cpp26/literals1.C.jj   2023-08-25 17:23:06.662878355 
+0200
+++ gcc/testsuite/g++.dg/cpp26/literals1.C  2023-08-25 17:37:03.085132304 
+0200
@@ -0,0 +1,65 @@
+// C++26 P1854R4 - Making non-encodable string literals ill-formed
+// { dg-do compile { target c++11 } }
+// { dg-require-effective-target int32 }
+// { dg-options "-pedantic-errors -finput-charset=UTF-8 -fexec-charset=UTF-8" }
+
+int d = '';   // { dg-error "character too 
large for character literal type" }

...

+char16_t m = u''; // { dg-error "character 
constant too long for its type" }


Why are these different diagnostics?  Why doesn't the first line already hit
the existing diagnostic that the second gets?

Both could be clearer that the problem is that the single source character
can't be encoded as a single execution character.


The first diagnostics is the newly added in the patch which takes precedence
over the existing diagnostics (and wouldn't actually trigger without the
patch).  Sure, I could make that new diagnostics more specific, but all
I generally know is that (str2.len / nbwc) c-chars are encodable in str.len
execution character set code units.
So, would you like 2 different messages, one for str2.len / nbwb == 1
"single character not encodable in a single execution character code unit"


Sounds good, but let's drop "single".


and otherwise
"%d characters need %d execution character code units"
or
"at least one character not encodable in a single execution character code unit"
or something different?


The latter sounds good.  Maybe adding "in multicharacter literal"?


Everything else (i.e. u8 case in narrow_str_to_charconst and L, u and U
cases in wide_str_to_charconst) is already covered by existing diagnostics
which has the "character constant too long for its type"
wording and covers for both C and C++ both the cases where there are more
than one c-chars in the literal (allowed in the L case for < C++23) and
when one c-char encodes in more than one code units (but this time
it isn't execution character set, but UTF-8 character set for u8,
wide execution character set for L, UTF-16 character set for u and
UTF-32 for U).
Plus the same "character constant too long for its type" diagnostics
is emitted if normal narrow literal has several c-chars encodable all as
single execution character code units, but more than can fit into int.

So, do you want to change just the new diagnostics (and what is your
preferred wording), or use the old diagnostics wording also for the
new one, or do you want to change the preexisting diagnostics as well
and e.g. differentiate there between the single c-char cases which need
more than one code unit and different wording for more than one c-char?
Note, if we differentiate between those, we'd need to count how many
c-chars we have even for the u8, L, u and U cases if we see more than
one code unit, similarly how the patch does that (and also the follow-up
patch tweaks).


Under the existing diagnostic I'd like to distinguish the different 
cases more, e.g.


"multicharacter literal with %d characters exceeds 'int' size of %d bytes"
"multicharacter literal cannot have an encoding prefix"

Jason

Re: [PATCH] c++: End lifetime of objects in constexpr after destructor call [PR71093]

[Nathaniel Shead]

Oh, this also fixes PR102284 and its other linked PRs (apart from
fields); I forgot to note that in the commit.

On Fri, Nov 03, 2023 at 12:18:29PM +1100, Nathaniel Shead wrote:
> Bootstrapped and regtested on x86-64_pc_linux_gnu.
> 
> I'm not entirely sure if the change I made to have destructors clobber with
> CLOBBER_EOL instead of CLOBBER_UNDEF is appropriate, but nothing seemed to 
> have
> broken by doing this and I wasn't able to find anything else that really
> depended on this distinction other than a warning pass. Otherwise I could
> experiment with a new clobber kind for destructor calls.
> 
> -- >8 --
> 
> This patch adds checks for using objects after they've been manually
> destroyed via explicit destructor call. Currently this is only
> implemented for 'top-level' objects; FIELD_DECLs and individual elements
> of arrays will need a lot more work to track correctly and are left for
> a future patch.
> 
> The other limitation is that destruction of parameter objects is checked
> too 'early', happening at the end of the function call rather than the
> end of the owning full-expression as they should be for consistency;
> see cpp2a/constexpr-lifetime2.C. This is because I wasn't able to find a
> good way to link the constructed parameter declarations with the
> variable declarations that are actually destroyed later on to propagate
> their lifetime status, so I'm leaving this for a later patch.
> 
>   PR c++/71093
> 
> gcc/cp/ChangeLog:
> 
>   * call.cc (build_trivial_dtor_call): Mark pseudo-destructors as
>   ending lifetime.
>   * constexpr.cc (constexpr_global_ctx::get_value_ptr): Don't
>   return NULL_TREE for objects we're initializing.
>   (constexpr_global_ctx::destroy_value): Rename from remove_value.
>   Only mark real variables as outside lifetime.
>   (constexpr_global_ctx::clear_value): New function.
>   (destroy_value_checked): New function.
>   (cxx_eval_call_expression): Defer complaining about non-constant
>   arg0 for operator delete. Use remove_value_safe.
>   (cxx_fold_indirect_ref_1): Handle conversion to 'as base' type.
>   (outside_lifetime_error): Include name of object we're
>   accessing.
>   (cxx_eval_store_expression): Handle clobbers. Improve error
>   messages.
>   (cxx_eval_constant_expression): Use remove_value_safe. Clear
> bind variables before entering body.
>   * decl.cc (build_clobber_this): Mark destructors as ending
>   lifetime.
>   (start_preparsed_function): Pass false to build_clobber_this.
>   (begin_destructor_body): Pass true to build_clobber_this.
> 
> gcc/testsuite/ChangeLog:
> 
>   * g++.dg/cpp1y/constexpr-lifetime1.C: Improve error message.
>   * g++.dg/cpp1y/constexpr-lifetime2.C: Likewise.
>   * g++.dg/cpp1y/constexpr-lifetime3.C: Likewise.
>   * g++.dg/cpp1y/constexpr-lifetime4.C: Likewise.
>   * g++.dg/cpp2a/bitfield2.C: Likewise.
>   * g++.dg/cpp2a/constexpr-new3.C: Likewise. New check.
>   * g++.dg/cpp1y/constexpr-lifetime7.C: New test.
>   * g++.dg/cpp2a/constexpr-lifetime1.C: New test.
>   * g++.dg/cpp2a/constexpr-lifetime2.C: New test.
> 
> Signed-off-by: Nathaniel Shead 
> ---
>  gcc/cp/call.cc|   2 +-
>  gcc/cp/constexpr.cc   | 149 +++---
>  gcc/cp/decl.cc|  10 +-
>  .../g++.dg/cpp1y/constexpr-lifetime1.C|   2 +-
>  .../g++.dg/cpp1y/constexpr-lifetime2.C|   2 +-
>  .../g++.dg/cpp1y/constexpr-lifetime3.C|   2 +-
>  .../g++.dg/cpp1y/constexpr-lifetime4.C|   2 +-
>  .../g++.dg/cpp1y/constexpr-lifetime7.C|  93 +++
>  gcc/testsuite/g++.dg/cpp2a/bitfield2.C|   2 +-
>  .../g++.dg/cpp2a/constexpr-lifetime1.C|  21 +++
>  .../g++.dg/cpp2a/constexpr-lifetime2.C|  23 +++
>  gcc/testsuite/g++.dg/cpp2a/constexpr-new3.C   |  17 +-
>  12 files changed, 292 insertions(+), 33 deletions(-)
>  create mode 100644 gcc/testsuite/g++.dg/cpp1y/constexpr-lifetime7.C
>  create mode 100644 gcc/testsuite/g++.dg/cpp2a/constexpr-lifetime1.C
>  create mode 100644 gcc/testsuite/g++.dg/cpp2a/constexpr-lifetime2.C
> 
> diff --git a/gcc/cp/call.cc b/gcc/cp/call.cc
> index 2eb54b5b6ed..e5e9c6c44f8 100644
> --- a/gcc/cp/call.cc
> +++ b/gcc/cp/call.cc
> @@ -9682,7 +9682,7 @@ build_trivial_dtor_call (tree instance, bool 
> no_ptr_deref)
>  }
>  
>/* A trivial destructor should still clobber the object.  */
> -  tree clobber = build_clobber (TREE_TYPE (instance));
> +  tree clobber = build_clobber (TREE_TYPE (instance), CLOBBER_EOL);
>return build2 (MODIFY_EXPR, void_type_node,
>instance, clobber);
>  }
> diff --git a/gcc/cp/constexpr.cc b/gcc/cp/constexpr.cc
> index c05760e6789..4f0f590c38a 100644
> --- a/gcc/cp/constexpr.cc
> +++ b/gcc/cp/constexpr.cc
> @@ -1193,13 +1193,20 @@ public:
>   return *p;
>  return NULL_TREE;
>}
> -  tree 

[PATCH] c++: End lifetime of objects in constexpr after destructor call [PR71093]

[Nathaniel Shead]

Bootstrapped and regtested on x86-64_pc_linux_gnu.

I'm not entirely sure if the change I made to have destructors clobber with
CLOBBER_EOL instead of CLOBBER_UNDEF is appropriate, but nothing seemed to have
broken by doing this and I wasn't able to find anything else that really
depended on this distinction other than a warning pass. Otherwise I could
experiment with a new clobber kind for destructor calls.

-- >8 --

This patch adds checks for using objects after they've been manually
destroyed via explicit destructor call. Currently this is only
implemented for 'top-level' objects; FIELD_DECLs and individual elements
of arrays will need a lot more work to track correctly and are left for
a future patch.

The other limitation is that destruction of parameter objects is checked
too 'early', happening at the end of the function call rather than the
end of the owning full-expression as they should be for consistency;
see cpp2a/constexpr-lifetime2.C. This is because I wasn't able to find a
good way to link the constructed parameter declarations with the
variable declarations that are actually destroyed later on to propagate
their lifetime status, so I'm leaving this for a later patch.

PR c++/71093

gcc/cp/ChangeLog:

* call.cc (build_trivial_dtor_call): Mark pseudo-destructors as
ending lifetime.
* constexpr.cc (constexpr_global_ctx::get_value_ptr): Don't
return NULL_TREE for objects we're initializing.
(constexpr_global_ctx::destroy_value): Rename from remove_value.
Only mark real variables as outside lifetime.
(constexpr_global_ctx::clear_value): New function.
(destroy_value_checked): New function.
(cxx_eval_call_expression): Defer complaining about non-constant
arg0 for operator delete. Use remove_value_safe.
(cxx_fold_indirect_ref_1): Handle conversion to 'as base' type.
(outside_lifetime_error): Include name of object we're
accessing.
(cxx_eval_store_expression): Handle clobbers. Improve error
messages.
(cxx_eval_constant_expression): Use remove_value_safe. Clear
bind variables before entering body.
* decl.cc (build_clobber_this): Mark destructors as ending
lifetime.
(start_preparsed_function): Pass false to build_clobber_this.
(begin_destructor_body): Pass true to build_clobber_this.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1y/constexpr-lifetime1.C: Improve error message.
* g++.dg/cpp1y/constexpr-lifetime2.C: Likewise.
* g++.dg/cpp1y/constexpr-lifetime3.C: Likewise.
* g++.dg/cpp1y/constexpr-lifetime4.C: Likewise.
* g++.dg/cpp2a/bitfield2.C: Likewise.
* g++.dg/cpp2a/constexpr-new3.C: Likewise. New check.
* g++.dg/cpp1y/constexpr-lifetime7.C: New test.
* g++.dg/cpp2a/constexpr-lifetime1.C: New test.
* g++.dg/cpp2a/constexpr-lifetime2.C: New test.

Signed-off-by: Nathaniel Shead 
---
 gcc/cp/call.cc|   2 +-
 gcc/cp/constexpr.cc   | 149 +++---
 gcc/cp/decl.cc|  10 +-
 .../g++.dg/cpp1y/constexpr-lifetime1.C|   2 +-
 .../g++.dg/cpp1y/constexpr-lifetime2.C|   2 +-
 .../g++.dg/cpp1y/constexpr-lifetime3.C|   2 +-
 .../g++.dg/cpp1y/constexpr-lifetime4.C|   2 +-
 .../g++.dg/cpp1y/constexpr-lifetime7.C|  93 +++
 gcc/testsuite/g++.dg/cpp2a/bitfield2.C|   2 +-
 .../g++.dg/cpp2a/constexpr-lifetime1.C|  21 +++
 .../g++.dg/cpp2a/constexpr-lifetime2.C|  23 +++
 gcc/testsuite/g++.dg/cpp2a/constexpr-new3.C   |  17 +-
 12 files changed, 292 insertions(+), 33 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp1y/constexpr-lifetime7.C
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/constexpr-lifetime1.C
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/constexpr-lifetime2.C

diff --git a/gcc/cp/call.cc b/gcc/cp/call.cc
index 2eb54b5b6ed..e5e9c6c44f8 100644
--- a/gcc/cp/call.cc
+++ b/gcc/cp/call.cc
@@ -9682,7 +9682,7 @@ build_trivial_dtor_call (tree instance, bool no_ptr_deref)
 }
 
   /* A trivial destructor should still clobber the object.  */
-  tree clobber = build_clobber (TREE_TYPE (instance));
+  tree clobber = build_clobber (TREE_TYPE (instance), CLOBBER_EOL);
   return build2 (MODIFY_EXPR, void_type_node,
 instance, clobber);
 }
diff --git a/gcc/cp/constexpr.cc b/gcc/cp/constexpr.cc
index c05760e6789..4f0f590c38a 100644
--- a/gcc/cp/constexpr.cc
+++ b/gcc/cp/constexpr.cc
@@ -1193,13 +1193,20 @@ public:
return *p;
 return NULL_TREE;
   }
-  tree *get_value_ptr (tree t)
+  tree *get_value_ptr (tree t, bool initializing)
   {
 if (modifiable && !modifiable->contains (t))
   return nullptr;
 if (tree *p = values.get (t))
-  if (*p != void_node)
-   return p;
+  {
+   if (*p != void_node)
+ return p;
+   else if (initializing)
+ 

[Bug target/112326] Redundant vsetvl in fixed-vlmax autovectorization codes

[juzhe.zhong at rivai dot ai via Gcc-bugs]

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

JuzheZhong  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from JuzheZhong  ---
Fixed

[Bug target/112326] Redundant vsetvl in fixed-vlmax autovectorization codes

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Pan Li :

https://gcc.gnu.org/g:5ea3c039b784b0676323243940fd9916b1f6d540

commit r14-5092-g5ea3c039b784b0676323243940fd9916b1f6d540
Author: Juzhe-Zhong 
Date:   Fri Nov 3 08:36:03 2023 +0800

RISC-V: Fix redundant vsetvl in fixed-vlmax vectorized codes[PR112326]

With compile option --param=riscv-autovec-preference=fixed-vlmax, we have
redundant AVL/VL toggling:

vsetvli a5,a3,e8,mf4,ta,ma -> should be changed into e32m1
vle32.v v1,0(a1)
vle32.v v2,0(a0)
vsetivlizero,4,e32,m1,ta,ma -> redundant
sllia2,a5,2
vadd.vv v1,v1,v2
sub a3,a3,a5
vsetvli zero,a5,e32,m1,ta,ma -> redundant
vse32.v v1,0(a4)
add a0,a0,a2
add a1,a1,a2
add a4,a4,a2
bne a3,zero,.L3

The root cause is because we simplify AVL into immediate AVL too early
in FIXED-VLMAX situation. The later avlprop PASS failed to propagate AVL
generated by (SELECT_VL/vsetvl VL, AVL) into the normal RVV instruction.

So we need to remove immedate AVL simplification in 'expand' stage.

After this patch:

vsetvli a5,a3,e32,m1,ta,ma
sllia2,a5,2
vle32.v v1,0(a1)
vle32.v v2,0(a0)
sub a3,a3,a5
vadd.vv v1,v1,v2
vse32.v v1,0(a4)
add a0,a0,a2
add a1,a1,a2
add a4,a4,a2
bne a3,zero,.L3

After the removed simplification, the following situation should be fixed:
typedef int8_t vnx2qi __attribute__ ((vector_size (2)));

__attribute__ ((noipa)) void
f_vnx2qi (int8_t a, int8_t b, int8_t *out)
{
  vnx2qi v = {a, b};
  *(vnx2qi *) out = v;
}

We should use vsetvili zero, 2 instead of vsetvl a5,zero.
Such simplification is done in avlprop PASS which is also included in this
patch
to fix regression of these situation.

PR target/112326

gcc/ChangeLog:

* config/riscv/riscv-avlprop.cc (get_insn_vtype_mode): New
function.
(simplify_replace_vlmax_avl): Ditto.
(pass_avlprop::execute): Add immediate AVL simplification.
* config/riscv/riscv-protos.h (imm_avl_p): Rename.
* config/riscv/riscv-v.cc (const_vlmax_p): Ditto.
(imm_avl_p): Ditto.
(emit_vlmax_insn): Adapt for new interface name.
* config/riscv/vector.md (mode_idx): New attribute.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/autovec/pr112326.c: New test.

[Committed V3] RISC-V: Fix redundant vsetvl in fixed-vlmax vectorized codes[PR112326]

[Juzhe-Zhong]

With compile option --param=riscv-autovec-preference=fixed-vlmax, we have
redundant AVL/VL toggling:

vsetvli a5,a3,e8,mf4,ta,ma -> should be changed into e32m1
vle32.v v1,0(a1)
vle32.v v2,0(a0)
vsetivlizero,4,e32,m1,ta,ma -> redundant
sllia2,a5,2
vadd.vv v1,v1,v2
sub a3,a3,a5
vsetvli zero,a5,e32,m1,ta,ma -> redundant
vse32.v v1,0(a4)
add a0,a0,a2
add a1,a1,a2
add a4,a4,a2
bne a3,zero,.L3

The root cause is because we simplify AVL into immediate AVL too early
in FIXED-VLMAX situation. The later avlprop PASS failed to propagate AVL
generated by (SELECT_VL/vsetvl VL, AVL) into the normal RVV instruction.

So we need to remove immedate AVL simplification in 'expand' stage.

After this patch:

vsetvli a5,a3,e32,m1,ta,ma
sllia2,a5,2
vle32.v v1,0(a1)
vle32.v v2,0(a0)
sub a3,a3,a5
vadd.vv v1,v1,v2
vse32.v v1,0(a4)
add a0,a0,a2
add a1,a1,a2
add a4,a4,a2
bne a3,zero,.L3

After the removed simplification, the following situation should be fixed:
typedef int8_t vnx2qi __attribute__ ((vector_size (2)));

__attribute__ ((noipa)) void
f_vnx2qi (int8_t a, int8_t b, int8_t *out)
{
  vnx2qi v = {a, b};
  *(vnx2qi *) out = v;
}

We should use vsetvili zero, 2 instead of vsetvl a5,zero.
Such simplification is done in avlprop PASS which is also included in this patch
to fix regression of these situation.

PR target/112326

gcc/ChangeLog:

* config/riscv/riscv-avlprop.cc (get_insn_vtype_mode): New function.
(simplify_replace_vlmax_avl): Ditto.
(pass_avlprop::execute): Add immediate AVL simplification.
* config/riscv/riscv-protos.h (imm_avl_p): Rename.
* config/riscv/riscv-v.cc (const_vlmax_p): Ditto.
(imm_avl_p): Ditto.
(emit_vlmax_insn): Adapt for new interface name.
* config/riscv/vector.md (mode_idx): New attribute.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/autovec/pr112326.c: New test.

---
 gcc/config/riscv/riscv-avlprop.cc | 95 ++-
 gcc/config/riscv/riscv-protos.h   |  1 +
 gcc/config/riscv/riscv-v.cc   | 28 ++
 gcc/config/riscv/vector.md| 29 +-
 .../gcc.target/riscv/rvv/autovec/pr112326.c   | 16 
 5 files changed, 124 insertions(+), 45 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/autovec/pr112326.c

diff --git a/gcc/config/riscv/riscv-avlprop.cc 
b/gcc/config/riscv/riscv-avlprop.cc
index bcd77a3047a..1dfaa8742da 100644
--- a/gcc/config/riscv/riscv-avlprop.cc
+++ b/gcc/config/riscv/riscv-avlprop.cc
@@ -109,6 +109,48 @@ vlmax_ta_p (rtx_insn *rinsn)
   return vlmax_avl_type_p (rinsn) && tail_agnostic_p (rinsn);
 }
 
+static machine_mode
+get_insn_vtype_mode (rtx_insn *rinsn)
+{
+  extract_insn_cached (rinsn);
+  int mode_idx = get_attr_mode_idx (rinsn);
+  gcc_assert (mode_idx != INVALID_ATTRIBUTE);
+  return GET_MODE (recog_data.operand[mode_idx]);
+}
+
+static void
+simplify_replace_vlmax_avl (rtx_insn *rinsn, rtx new_avl)
+{
+  if (dump_file && (dump_flags & TDF_DETAILS))
+{
+  fprintf (dump_file, "\nPropagating AVL: ");
+  print_rtl_single (dump_file, new_avl);
+  fprintf (dump_file, "into: ");
+  print_rtl_single (dump_file, rinsn);
+}
+  /* Replace AVL operand.  */
+  extract_insn_cached (rinsn);
+  rtx avl = recog_data.operand[get_attr_vl_op_idx (rinsn)];
+  int count = count_regno_occurrences (rinsn, REGNO (avl));
+  gcc_assert (count == 1);
+  rtx new_pat = simplify_replace_rtx (PATTERN (rinsn), avl, new_avl);
+  validate_change_or_fail (rinsn,  (rinsn), new_pat, false);
+
+  /* Change AVL TYPE into NONVLMAX if it is VLMAX.  */
+  if (vlmax_avl_type_p (rinsn))
+{
+  int index = get_attr_avl_type_idx (rinsn);
+  gcc_assert (index != INVALID_ATTRIBUTE);
+  validate_change_or_fail (rinsn, recog_data.operand_loc[index],
+  get_avl_type_rtx (avl_type::NONVLMAX), false);
+}
+  if (dump_file && (dump_flags & TDF_DETAILS))
+{
+  fprintf (dump_file, "Successfully to match this instruction: ");
+  print_rtl_single (dump_file, rinsn);
+}
+}
+
 const pass_data pass_data_avlprop = {
   RTL_PASS, /* type */
   "avlprop",/* name */
@@ -384,34 +426,35 @@ pass_avlprop::execute (function *fn)
   for (const auto prop : *m_avl_propagations)
 {
   rtx_insn *rinsn = prop.first->rtl ();
+  simplify_replace_vlmax_avl (rinsn, prop.second);
+}
+
+  if (riscv_autovec_preference == RVV_FIXED_VLMAX)
+{
+  /* Simplify VLMAX AVL into immediate AVL.
+E.g. Simplify this following case:
+
+ vsetvl a5, zero, e32, m1
+ vadd.vv
+
+   into:
+
+ vsetvl zero, 4, e32, m1
+ vadd.vv
+if GET_MODE_NUNITS (RVVM1SImode) == 4.  */
   

RE: [PATCH v1] RISC-V: Refactor prefix [I/L/LL] rounding API autovec iterator

[Li, Pan2]

Thanks Patrick.

It caused by the underlying codegen is not implemented but expand modes opened. 
Revert it first to unblock others and will fix it ASAP.

Pan

From: Patrick O'Neill 
Sent: Friday, November 3, 2023 6:57 AM
To: Li, Pan2 ; juzhe.zhong 
Cc: gcc-patches@gcc.gnu.org; Wang, Yanzhang ; 
kito.ch...@gmail.com; gnu-toolchain 
Subject: Re: [PATCH v1] RISC-V: Refactor prefix [I/L/LL] rounding API autovec 
iterator


Hi Pan,

This patch is causing new failures (ICEs) on trunk:
https://github.com/patrick-rivos/gcc-postcommit-ci/issues/110

Pre-commit CI run:
https://github.com/ewlu/gcc-precommit-ci/issues/553#issuecomment-1790688172

New rv32gcv failures:

FAIL: gcc.dg/vect/fast-math-bb-slp-call-2.c (internal compiler error: in 
expand_vec_lrint, at config/riscv/riscv-v.cc:4134)

FAIL: gcc.dg/vect/fast-math-bb-slp-call-2.c (test for excess errors)

FAIL: gcc.dg/vect/fast-math-vect-call-2.c (internal compiler error: in 
expand_vec_lrint, at config/riscv/riscv-v.cc:4134)

FAIL: gcc.dg/vect/fast-math-vect-call-2.c (test for excess errors)

FAIL: gfortran.dg/pr32533.f90   -O0  (internal compiler error: in 
expand_vec_lround, at config/riscv/riscv-v.cc:4144)

FAIL: gfortran.dg/pr32533.f90   -O0  (test for excess errors)

FAIL: gfortran.dg/pr32533.f90   -O1  (internal compiler error: in 
expand_vec_lround, at config/riscv/riscv-v.cc:4144)

FAIL: gfortran.dg/pr32533.f90   -O1  (test for excess errors)

FAIL: gfortran.dg/pr32533.f90   -O2  (internal compiler error: in 
expand_vec_lround, at config/riscv/riscv-v.cc:4144)

FAIL: gfortran.dg/pr32533.f90   -O2  (test for excess errors)

FAIL: gfortran.dg/pr32533.f90   -O3 -fomit-frame-pointer -funroll-loops 
-fpeel-loops -ftracer -finline-functions  (internal compiler error: in 
expand_vec_lround, at config/riscv/riscv-v.cc:4144)

FAIL: gfortran.dg/pr32533.f90   -O3 -fomit-frame-pointer -funroll-loops 
-fpeel-loops -ftracer -finline-functions  (test for excess errors)

FAIL: gfortran.dg/pr32533.f90   -O3 -g  (internal compiler error: in 
expand_vec_lround, at config/riscv/riscv-v.cc:4144)

FAIL: gfortran.dg/pr32533.f90   -O3 -g  (test for excess errors)

FAIL: gfortran.dg/pr32533.f90   -Os  (internal compiler error: in 
expand_vec_lround, at config/riscv/riscv-v.cc:4144)

FAIL: gfortran.dg/pr32533.f90   -Os  (test for excess errors)

New rv64gcv failures:

FAIL: gfortran.dg/pr32533.f90   -O0  (internal compiler error: in 
expand_vec_lround, at config/riscv/riscv-v.cc:4144)

FAIL: gfortran.dg/pr32533.f90   -O0  (test for excess errors)

FAIL: gfortran.dg/pr32533.f90   -O1  (internal compiler error: in 
expand_vec_lround, at config/riscv/riscv-v.cc:4144)

FAIL: gfortran.dg/pr32533.f90   -O1  (test for excess errors)

FAIL: gfortran.dg/pr32533.f90   -O2  (internal compiler error: in 
expand_vec_lround, at config/riscv/riscv-v.cc:4144)

FAIL: gfortran.dg/pr32533.f90   -O2  (test for excess errors)

FAIL: gfortran.dg/pr32533.f90   -O3 -fomit-frame-pointer -funroll-loops 
-fpeel-loops -ftracer -finline-functions  (internal compiler error: in 
expand_vec_lround, at config/riscv/riscv-v.cc:4144)

FAIL: gfortran.dg/pr32533.f90   -O3 -fomit-frame-pointer -funroll-loops 
-fpeel-loops -ftracer -finline-functions  (test for excess errors)

FAIL: gfortran.dg/pr32533.f90   -O3 -g  (internal compiler error: in 
expand_vec_lround, at config/riscv/riscv-v.cc:4144)

FAIL: gfortran.dg/pr32533.f90   -O3 -g  (test for excess errors)

FAIL: gfortran.dg/pr32533.f90   -Os  (internal compiler error: in 
expand_vec_lround, at config/riscv/riscv-v.cc:4144)

FAIL: gfortran.dg/pr32533.f90   -Os  (test for excess errors)

Please let me know if you need any additional information.

Thanks,
Patrick
On 11/2/23 05:13, Li, Pan2 wrote:
Committed, thanks Juzhe.

Pan

From: juzhe.zhong 
Sent: Thursday, November 2, 2023 8:04 PM
To: Li, Pan2 
Cc: gcc-patches@gcc.gnu.org; Li, Pan2 
; Wang, Yanzhang 
; 
kito.ch...@gmail.com
Subject: Re: [PATCH v1] RISC-V: Refactor prefix [I/L/LL] rounding API autovec 
iterator

lgtm
 Replied Message 
From
pan2...@intel.com
Date
11/02/2023 19:48
To
gcc-patches@gcc.gnu.org
Cc
juzhe.zh...@rivai.ai,
pan2...@intel.com,
yanzhang.w...@intel.com,
kito.ch...@gmail.com
Subject
[PATCH v1] RISC-V: Refactor prefix [I/L/LL] rounding API autovec iterator

Re: RFC: the proposal to resolve the missing dependency issue for counted_by attribute

[Bill Wendling]

On Thu, Nov 2, 2023 at 1:36 PM Qing Zhao  wrote:
>
> Thanks a lot for raising these issues.
>
> If I understand correctly,  the major question we need to answer is:
>
> For the following example: (Jakub mentioned this  in an early message)
>
>   1 struct S { int a; char b __attribute__((counted_by (a))) []; };
>   2 struct S s;
>   3 s.a = 5;
>   4 char *p = [2];
>   5 int i1 = __builtin_dynamic_object_size (p, 0);
>   6 s.a = 3;
>   7 int i2 = __builtin_dynamic_object_size (p, 0);
>
> Should the 2nd __bdos call (line 7) get
> A. the latest value of s.a (line 6) for it’s size?
> Or  B. the value when the s.b was referenced (line 3, line 4)?
>
I personally think it should be (A). The user is specifically
indicating that the size has somehow changed, and the compiler should
behave accordingly.

> A should be more convenient for the user to use the dynamic array feature.
> With B, the user has to modify the source code (to add code to “re-obtain”
> the pointer after the size was adjusted at line 6) as mentioned by Richard.
>
> This depends on how we design the new internal function .ACCESS_WITH_SIZE
>
> 1. Size is passed by value to .ACCESS_WITH_SIZE as we currently designed.
>
> PTR = .ACCESS_WITH_SIZE (PTR, SIZE, ACCESS_MODE)
>
> 2. Size is passed by reference to .ACCESS_WITH_SIZE as Jakub suggested.
>
> PTR = .ACCESS_WITH_SIZE(PTR, , TYPEOFSIZE, ACCESS_MODE)
>
> With 1, We can only provide B, the user needs to modify the source code to 
> get the full feature of dynamic array;
> With 2, We can provide  A, the user will get full support to the dynamic 
> array without restrictions in the source code.
>
My understanding of ACCESS_WITH_SIZE is that it's there to add an
explicit reference to SIZE so that the optimizers won't reorder the
code incorrectly. If that's the case, then it should act as if
ACCESS_WITH_SIZE wasn't even there (i.e. it's just a pointer
dereference into the FAM). We get that with (2) it appears. It would
be a major headache to make the user go throughout their code base to
ensure that SIZE was either unmodified, or if it was that extra code
must be added to ensure the expected behavior.

> However, We have to pay additional cost for supporting A by using 2, which 
> includes:
>
> 1. .ACCESS_WITH_SIZE will become an escape point, which will further impact 
> the IPA optimizations, more runtime overhead.
> Then .ACCESS_WTH_SIZE will not be CONST, right? But it will still be PURE?
>
> 2. __builtin_dynamic_object_size will NOT be LEAF anymore.  This will also 
> impact some IPA optimizations, more runtime overhead.
>
> I think the following are the factors that make the decision:
>
> 1. How big the performance impact?
> 2. How important the dynamic array feature? Is adding some user restrictions 
> as Richard mentioned feasible to support this feature?
>
> Maybe we can implement 1 first, if the full support to the dynamic array is 
> needed, we can add 2 then?
> Or, we can implement both, and compare the performance difference, then 
> decide?
>
> Qing
>

Re: RFC: the proposal to resolve the missing dependency issue for counted_by attribute

[Bill Wendling]

On Thu, Nov 2, 2023 at 1:00 AM Richard Biener
 wrote:
>
> On Wed, Nov 1, 2023 at 3:47 PM Qing Zhao  wrote:
> >
> >
> >
> > > On Oct 31, 2023, at 6:14 PM, Joseph Myers  wrote:
> > >
> > > On Tue, 31 Oct 2023, Qing Zhao wrote:
> > >
> > >> 2.3 A new semantic requirement in the user documentation of "counted_by"
> > >>
> > >> For the following structure including a FAM with a counted_by attribute:
> > >>
> > >>  struct A
> > >>  {
> > >>   size_t size;
> > >>   char buf[] __attribute__((counted_by(size)));
> > >>  };
> > >>
> > >> for any object with such type:
> > >>
> > >>  struct A *obj = __builtin_malloc (sizeof(struct A) + sz * sizeof(char));
> > >>
> > >> The setting to the size field should be done before the first reference
> > >> to the FAM field.
> > >>
> > >> Such requirement to the user will guarantee that the first reference to
> > >> the FAM knows the size of the FAM.
> > >>
> > >> We need to add this additional requirement to the user document.
> > >
> > > Make sure the manual is very specific about exactly when size is
> > > considered to be an accurate representation of the space available for buf
> > > (given that, after malloc or realloc, it's going to be temporarily
> > > inaccurate).  If the intent is that inaccurate size at such a time means
> > > undefined behavior, say so explicitly.
> >
> > Yes, good point. We need to define this clearly in the beginning.
> > We need to explicit say that
> >
> > the size of the FAM is defined by the latest “counted_by” value. And it’s 
> > an undefined behavior when the size field is not defined when the FAM is 
> > referenced.
> >
> > Is the above good enough?
> >
> >
> > >
> > >> 2.4 Replace FAM field accesses with the new function ACCESS_WITH_SIZE
> > >>
> > >> In C FE:
> > >>
> > >> for every reference to a FAM, for example, "obj->buf" in the small 
> > >> example,
> > >>  check whether the corresponding FIELD_DECL has a "counted_by" attribute?
> > >>  if YES, replace the reference to "obj->buf" with a call to
> > >>  .ACCESS_WITH_SIZE (obj->buf, obj->size, -1);
> > >
> > > This seems plausible - but you should also consider the case of static
> > > initializers - remember the GNU extension for statically allocated objects
> > > with flexible array members (unless you're not allowing it with
> > > counted_by).
> > >
> > > static struct A x = { sizeof "hello", "hello" };
> > > static char *y = 
> > >
> > > I'd expect that to be valid - and unless you say such a usage is invalid,
> >
> > At this moment, I think that this should be valid.
> >
> > I,e, the following:
> >
> > struct A
> > {
> >  size_t size;
> >  char buf[] __attribute__((counted_by(size)));
> > };
> >
> > static struct A x = {sizeof "hello", "hello”};
> >
> > Should be valid, and x.size represents the number of elements of x.buf.
> > Both x.size and x.buf are initialized statically.
> >
> > > you should avoid the replacement in such a static initializer context when
> > > the FAM reference is to an object with a constant address (if
> > > .ACCESS_WITH_SIZE would not act as an lvalue whose address is a constant
> > > expression; if it works fine as a constant-address lvalue, then the
> > > replacement would be OK).
> >
> > Then if such usage for the “counted_by” is valid, we need to replace the FAM
> > reference by a call to  .ACCESS_WITH_SIZE as well.
> > Otherwise the “counted_by” relationship will be lost to the Middle end.
> >
> > With the current definition of .ACCESS_WITH_SIZE
> >
> > PTR = .ACCESS_WITH_SIZE (PTR, SIZE, ACCESS_MODE)
> >
> > Isn’t the PTR (return value of the call) a LVALUE?
>
> You probably want to specify that when a pointer to the array is taken the
> pointer has to be to the first array element (or do we want to mangle the
> 'size' accordingly for the instrumentation?).  You also want to specify that
> the 'size' associated with such pointer is assumed to be unchanging and
> after changing the size such pointer has to be re-obtained.  Plus that
> changes to the allocated object/size have to be performed through an
> lvalue where the containing type and thus the 'counted_by' attribute is
> visible.  That is,
>
> size_t *s = 
> *s = 1;
>
> is invoking undefined behavior, likewise modifying 'buf' (makes it a bit
> awkward since for example that wouldn't support using posix_memalign
> for allocation, though aligned_alloc would be fine).
>
I believe Qing's original documentation for counted_by makes the
relationship between 'size' and the FAM very clear and that without
agreement it'll result in undefined behavior. Though it might be best
to state that in a strong way.

-bw

Re: [PATCH] internal-fn: Add VCOND_MASK_LEN.

[Richard Sandiford]

Robin Dapp  writes:
>> Looks reasonable overall.  The new match patterns are 1:1 the
>> same as the COND_ ones.  That's a bit awkward, but I don't see
>> a good way to "macroize" stuff further there.  Can you at least
>> interleave the COND_LEN_* ones with the other ones instead of
>> putting them all at the end?
>
> Yes, no problem.  It's supposed to be only temporary anyway (FWIW)
> as I didn't manage with the "stripping _LEN" way on the first few tries.
> Still on the todo list but unlikely to be done before stage 1 closes.
>
> I believe Richard "kind of" LGTM'ed the rest minus the spurious
> pattern (which is gone now) but there is still the direct optab change
> that he didn't comment on so I think we should wait for his remarks
> still.

Could you explain why a special expansion is needed?  (Sorry if you already
have and I missed it, bit overloaded ATM.)  What does it do that is
different from what expand_fn_using_insn would do?

Thanks,
Richard

[PATCH] g++: Rely on dg-do-what-default to avoid running pr102788.cc on non-vector targets

[Patrick O'Neill]

Testcases in g++.dg/vect rely on check_vect_support_and_set_flags
to set dg-do-what-default and avoid running vector tests on non-vector
targets. The three testcases in this patch overwrite the default with
dg-do run.

Removing the dg-do run directive resolves this issue for non-vector
targets (while still running the tests on vector targets).

gcc/testsuite/ChangeLog:

* g++.dg/vect/pr102788.cc: Remove dg-do run directive.

Signed-off-by: Patrick O'Neill 
---
Tested using rv64gc & rv64gcv to make sure the testcases compile/run
as expected.

Similar to 
https://inbox.sourceware.org/gcc-patches/20231102190911.66763-1-patr...@rivosinc.com/T/#u
---
 gcc/testsuite/g++.dg/vect/pr102788.cc | 1 -
 1 file changed, 1 deletion(-)

diff --git a/gcc/testsuite/g++.dg/vect/pr102788.cc 
b/gcc/testsuite/g++.dg/vect/pr102788.cc
index fa9c366fe56..032fa29fc72 100644
--- a/gcc/testsuite/g++.dg/vect/pr102788.cc
+++ b/gcc/testsuite/g++.dg/vect/pr102788.cc
@@ -1,4 +1,3 @@
-// { dg-do run }
 // { dg-additional-options "-O3" }

 unsigned long long int var_4 = 235;
--
2.34.1

Re: [PATCH] ifcvt/vect: Emit COND_ADD for conditional scalar reduction.

[Andrew Pinski]

On Wed, Sep 20, 2023 at 6:52 AM Robin Dapp  wrote:
>
> Hi,
>
> as described in PR111401 we currently emit a COND and a PLUS expression
> for conditional reductions.  This makes it difficult to combine both
> into a masked reduction statement later.
> This patch improves that by directly emitting a COND_ADD during ifcvt and
> adjusting some vectorizer code to handle it.
>
> It also makes neutral_op_for_reduction return -0 if HONOR_SIGNED_ZEROS
> is true.
>
> Related question/change: We only allow PLUS_EXPR in fold_left_reduction_fn
> but have code to handle MINUS_EXPR in vectorize_fold_left_reduction.  I
> suppose that's intentional but it "just works" on riscv and the testsuite
> doesn't change when allowing MINUS_EXPR so I went ahead and did that.
>
> Bootstrapped and regtested on x86 and aarch64.

This caused gcc.target/i386/avx512f-reduce-op-1.c testcase to start to
fail when testing on a x86_64 that has avx512f (In my case I am using
`Intel(R) Xeon(R) D-2166NT CPU @ 2.00GHz`).  I reverted the commit to
double check it too.

The difference in optimized I see is:
  if (_40 != 3.5e+1) // working
vs
  if (_40 != 6.4e+1) // not working

It is test_epi32_ps which is failing with TEST_PS macro and the plus
operand that uses TESTOP:
TESTOP (add, +, float, ps, 0.0f);   \

I have not reduced the testcase any further though.

Thanks,
Andrew Pinski


>
> Regards
>  Robin
>
> gcc/ChangeLog:
>
> PR middle-end/111401
> * internal-fn.cc (cond_fn_p): New function.
> * internal-fn.h (cond_fn_p): Define.
> * tree-if-conv.cc (convert_scalar_cond_reduction): Emit COND_ADD
> if supported.
> (predicate_scalar_phi): Add whitespace.
> * tree-vect-loop.cc (fold_left_reduction_fn): Add IFN_COND_ADD.
> (neutral_op_for_reduction): Return -0 for PLUS.
> (vect_is_simple_reduction): Don't count else operand in
> COND_ADD.
> (vectorize_fold_left_reduction): Add COND_ADD handling.
> (vectorizable_reduction): Don't count else operand in COND_ADD.
> (vect_transform_reduction): Add COND_ADD handling.
> * tree-vectorizer.h (neutral_op_for_reduction): Add default
> parameter.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.dg/vect/vect-cond-reduc-in-order-2-signed-zero.c: New test.
> * gcc.target/riscv/rvv/autovec/cond/pr111401.c: New test.
> ---
>  gcc/internal-fn.cc|  38 +
>  gcc/internal-fn.h |   1 +
>  .../vect-cond-reduc-in-order-2-signed-zero.c  | 141 ++
>  .../riscv/rvv/autovec/cond/pr111401.c |  61 
>  gcc/tree-if-conv.cc   |  63 ++--
>  gcc/tree-vect-loop.cc | 130 
>  gcc/tree-vectorizer.h |   2 +-
>  7 files changed, 394 insertions(+), 42 deletions(-)
>  create mode 100644 
> gcc/testsuite/gcc.dg/vect/vect-cond-reduc-in-order-2-signed-zero.c
>  create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/autovec/cond/pr111401.c
>
> diff --git a/gcc/internal-fn.cc b/gcc/internal-fn.cc
> index 0fd34359247..77939890f5a 100644
> --- a/gcc/internal-fn.cc
> +++ b/gcc/internal-fn.cc
> @@ -4241,6 +4241,44 @@ first_commutative_argument (internal_fn fn)
>  }
>  }
>
> +/* Return true if this CODE describes a conditional (masked) internal_fn.  */
> +
> +bool
> +cond_fn_p (code_helper code)
> +{
> +  if (!code.is_fn_code ())
> +return false;
> +
> +  if (!internal_fn_p ((combined_fn) code))
> +return false;
> +
> +  internal_fn fn = as_internal_fn ((combined_fn) code);
> +  switch (fn)
> +{
> +#undef DEF_INTERNAL_COND_FN
> +#define DEF_INTERNAL_COND_FN(NAME, F, O, T)  \
> +case IFN_COND_##NAME:\
> +case IFN_COND_LEN_##NAME:\
> +  return true;
> +#include "internal-fn.def"
> +#undef DEF_INTERNAL_COND_FN
> +
> +#undef DEF_INTERNAL_SIGNED_COND_FN
> +#define DEF_INTERNAL_SIGNED_COND_FN(NAME, F, S, SO, UO, T)   \
> +case IFN_COND_##NAME:\
> +case IFN_COND_LEN_##NAME:\
> +  return true;
> +#include "internal-fn.def"
> +#undef DEF_INTERNAL_SIGNED_COND_FN
> +
> +default:
> +  return false;
> +}
> +
> +  return false;
> +}
> +
> +
>  /* Return true if this CODE describes an internal_fn that returns a vector 
> with
> elements twice as wide as the element size of the input vectors.  */
>
> diff --git a/gcc/internal-fn.h b/gcc/internal-fn.h
> index 99de13a0199..f1cc9db29c0 100644
> --- a/gcc/internal-fn.h
> +++ b/gcc/internal-fn.h
> @@ -219,6 +219,7 @@ extern bool commutative_ternary_fn_p (internal_fn);
>  extern int first_commutative_argument (internal_fn);
>  extern bool associative_binary_fn_p (internal_fn);
>  extern bool widening_fn_p (code_helper);
> 

[Bug tree-optimization/112358] New: [14 Regression] glibc -Wstringop-overflow= build failure

[jsm28 at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 112358
   Summary: [14 Regression] glibc -Wstringop-overflow= build
failure
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jsm28 at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
  Target Milestone: ---
Target: hppa-linux-gnu

Created attachment 56497
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56497=edit
preprocessed source

Building glibc for hppa-linux-gnu has been failing since 18 September:

In file included from ../include/atomic.h:49,
 from dl-find_object.c:20:
In function '_dlfo_update_init_seg',
inlined from '_dl_find_object_update_1' at dl-find_object.c:689:30,
inlined from '_dl_find_object_update' at dl-find_object.c:805:13:
../sysdeps/unix/sysv/linux/hppa/atomic-machine.h:44:4: error:
'__atomic_store_4' writing 4 bytes into a region of size 0 overflows the
destination [-Werror=stringop-overflow=]
   44 |__atomic_store_n ((mem), (val), __ATOMIC_RELAXED);  
 \
  |^
dl-find_object.c:644:3: note: in expansion of macro 'atomic_store_relaxed'
  644 |   atomic_store_relaxed (>size, new_seg_size);
  |   ^~~~
In function '_dl_find_object_update':
cc1: note: destination object is likely at address zero

Compile the attached test with -O2 -Wall:

In function '_dlfo_update_init_seg',
inlined from '_dl_find_object_update_1' at dl-find_object.c:689:30,
inlined from '_dl_find_object_update' at dl-find_object.c:805:12:
dl-find_object.c:644:132: warning: '__atomic_store_4' writing 4 bytes into a
region of size 0 overflows the destination [-Wstringop-overflow=]
In function '_dl_find_object_update':
cc1: note: destination object is likely at address zero

I don't know why the compiler thinks "destination object is likely at address
zero", so maybe there is actually an issue in the glibc sources, but I didn't
see an obvious reason for the warning/error.

Introduced by the commit:

commit d45ddc2c04e471d0dcee016b6edacc00b8341b16
Author: Richard Biener 
AuthorDate: Thu Sep 14 13:06:51 2023 +0200
Commit: Richard Biener 
CommitDate: Mon Sep 18 10:56:18 2023 +0200

tree-optimization/111294 - backwards threader PHI costing

Re: [Committed] RISC-V: Add check for types without insn reservations

[Edwin Lu]

On 11/1/2023 11:53 AM, Jeff Law wrote:



On 11/1/23 12:17, Edwin Lu wrote:

Now that all insns are guaranteed to have a type, ensure every insn
is associated with a cpu unit/insn reservation.

gcc/ChangeLog:

* config/riscv/riscv.cc (riscv_sched_variable_issue): add disabled 
assert
OK.  Really interested to see how often this trips in practice.  I 
suspect often right now ;-)


Committed! On a local test with just rv64gc, actually not that many 
types were tripped. I think there were around 13 that weren't part of 
any reservation


Edwin

jeff

Re: [PATCH v1] RISC-V: Refactor prefix [I/L/LL] rounding API autovec iterator

[Patrick O'Neill]

Hi Pan,

This patch is causing new failures (ICEs) on trunk:
https://github.com/patrick-rivos/gcc-postcommit-ci/issues/110

Pre-commit CI run:
https://github.com/ewlu/gcc-precommit-ci/issues/553#issuecomment-1790688172

New rv32gcv failures:

|FAIL: gcc.dg/vect/fast-math-bb-slp-call-2.c (internal compiler error: 
in expand_vec_lrint, at config/riscv/riscv-v.cc:4134) FAIL: 
gcc.dg/vect/fast-math-bb-slp-call-2.c (test for excess errors) FAIL: 
gcc.dg/vect/fast-math-vect-call-2.c (internal compiler error: in 
expand_vec_lrint, at config/riscv/riscv-v.cc:4134) FAIL: 
gcc.dg/vect/fast-math-vect-call-2.c (test for excess errors) FAIL: 
gfortran.dg/pr32533.f90 -O0 (internal compiler error: in 
expand_vec_lround, at config/riscv/riscv-v.cc:4144) FAIL: 
gfortran.dg/pr32533.f90 -O0 (test for excess errors) FAIL: 
gfortran.dg/pr32533.f90 -O1 (internal compiler error: in 
expand_vec_lround, at config/riscv/riscv-v.cc:4144) FAIL: 
gfortran.dg/pr32533.f90 -O1 (test for excess errors) FAIL: 
gfortran.dg/pr32533.f90 -O2 (internal compiler error: in 
expand_vec_lround, at config/riscv/riscv-v.cc:4144) FAIL: 
gfortran.dg/pr32533.f90 -O2 (test for excess errors) FAIL: 
gfortran.dg/pr32533.f90 -O3 -fomit-frame-pointer -funroll-loops 
-fpeel-loops -ftracer -finline-functions (internal compiler error: in 
expand_vec_lround, at config/riscv/riscv-v.cc:4144) FAIL: 
gfortran.dg/pr32533.f90 -O3 -fomit-frame-pointer -funroll-loops 
-fpeel-loops -ftracer -finline-functions (test for excess errors) FAIL: 
gfortran.dg/pr32533.f90 -O3 -g (internal compiler error: in 
expand_vec_lround, at config/riscv/riscv-v.cc:4144) FAIL: 
gfortran.dg/pr32533.f90 -O3 -g (test for excess errors) FAIL: 
gfortran.dg/pr32533.f90 -Os (internal compiler error: in 
expand_vec_lround, at config/riscv/riscv-v.cc:4144) FAIL: 
gfortran.dg/pr32533.f90 -Os (test for excess errors) |


New rv64gcv failures:

|FAIL: gfortran.dg/pr32533.f90 -O0 (internal compiler error: in 
expand_vec_lround, at config/riscv/riscv-v.cc:4144) FAIL: 
gfortran.dg/pr32533.f90 -O0 (test for excess errors) FAIL: 
gfortran.dg/pr32533.f90 -O1 (internal compiler error: in 
expand_vec_lround, at config/riscv/riscv-v.cc:4144) FAIL: 
gfortran.dg/pr32533.f90 -O1 (test for excess errors) FAIL: 
gfortran.dg/pr32533.f90 -O2 (internal compiler error: in 
expand_vec_lround, at config/riscv/riscv-v.cc:4144) FAIL: 
gfortran.dg/pr32533.f90 -O2 (test for excess errors) FAIL: 
gfortran.dg/pr32533.f90 -O3 -fomit-frame-pointer -funroll-loops 
-fpeel-loops -ftracer -finline-functions (internal compiler error: in 
expand_vec_lround, at config/riscv/riscv-v.cc:4144) FAIL: 
gfortran.dg/pr32533.f90 -O3 -fomit-frame-pointer -funroll-loops 
-fpeel-loops -ftracer -finline-functions (test for excess errors) FAIL: 
gfortran.dg/pr32533.f90 -O3 -g (internal compiler error: in 
expand_vec_lround, at config/riscv/riscv-v.cc:4144) FAIL: 
gfortran.dg/pr32533.f90 -O3 -g (test for excess errors) FAIL: 
gfortran.dg/pr32533.f90 -Os (internal compiler error: in 
expand_vec_lround, at config/riscv/riscv-v.cc:4144) FAIL: 
gfortran.dg/pr32533.f90 -Os (test for excess errors)|


Please let me know if you need any additional information.

Thanks,
Patrick

On 11/2/23 05:13, Li, Pan2 wrote:


Committed, thanks Juzhe.

Pan

*From:*juzhe.zhong 
*Sent:* Thursday, November 2, 2023 8:04 PM
*To:* Li, Pan2 
*Cc:* gcc-patches@gcc.gnu.org; Li, Pan2 ; Wang, 
Yanzhang ; kito.ch...@gmail.com
*Subject:* Re: [PATCH v1] RISC-V: Refactor prefix [I/L/LL] rounding 
API autovec iterator


lgtm

 Replied Message 

From



pan2...@intel.com 

Date



11/02/2023 19:48

To



gcc-patches@gcc.gnu.org 



Cc



juzhe.zh...@rivai.ai ,
pan2...@intel.com ,
yanzhang.w...@intel.com 
,

kito.ch...@gmail.com 

Subject



[PATCH v1] RISC-V: Refactor prefix [I/L/LL] rounding API autovec iterator

Re: Re: [PATCH V2] RISC-V: Fix redundant vsetvl in fixed-vlmax vectorized codes[PR112326]

[钟居哲]

Thanks Robin.

Committed with change nuints into nunits

and change mode_idx into 0 for vnshift and vnclip.



juzhe.zh...@rivai.ai
 
From: Robin Dapp
Date: 2023-11-02 23:18
To: Juzhe-Zhong; gcc-patches
CC: rdapp.gcc; kito.cheng; kito.cheng; jeffreyalaw
Subject: Re: [PATCH V2] RISC-V: Fix redundant vsetvl in fixed-vlmax vectorized 
codes[PR112326]
Hi Juzhe,
 
in principle this LGTM.  It could use some function comments, though ;)
> +imm_avl_p (machine_mode mode)
>  {
>poly_uint64 nuints = GET_MODE_NUNITS (mode);
>  
>return nuints.is_constant ()
> -/* The vsetivli can only hold register 0~31.  */
> -? (IN_RANGE (nuints.to_constant (), 0, 31))
> -/* Only allowed in VLS-VLMAX mode.  */
> -: false;
> +/* The vsetivli can only hold register 0~31.  */
> +? (IN_RANGE (nuints.to_constant (), 0, 31))
> +/* Only allowed in VLS-VLMAX mode.  */
> +: false;
>  }
 
Please replace nuints (or untis) with nunits here everywhere.
 
> +;; The index of operand[] represents the machine mode of the instruction.
> +(define_attr "mode_idx" ""
> + (cond [(eq_attr "type" 
> "vlde,vste,vldm,vstm,vlds,vsts,vldux,vldox,vldff,vldr,vstr,\
> + vlsegde,vlsegds,vlsegdux,vlsegdox,vlsegdff,vialu,vext,vicalu,\
> + vshift,vicmp,viminmax,vimul,vidiv,vimuladd,vimerge,vimov,\
> + vsalu,vaalu,vsmul,vsshift,vfalu,vfmul,vfdiv,vfmuladd,vfsqrt,vfrecp,\
> + vfcmp,vfminmax,vfsgnj,vfclass,vfmerge,vfmov,\
> + vfcvtitof,vfncvtitof,vfncvtftoi,vfncvtftof,vmalu,vmiota,vmidx,\
> + 
> vimovxv,vfmovfv,vslideup,vslidedown,vislide1up,vislide1down,vfslide1up,vfslide1down,\
> + vgather,vcompress,vmov")
> +(const_int 0)
> +
> +(eq_attr "type" "vimovvx,vfmovvf")
> +(const_int 1)
> +
> +(eq_attr "type" "vssegte,vnshift,vmpop,vmffs")
> +(const_int 2)   
 
I'm not that fond of the growing number of necessary indices even though I
realize that it's the most painless way for now.  Why is vnshift "2" and
not "0", though?
 
"4" for vnclip also looks dubious.  I didn't go through all of them.
 
Regards
Robin
 
 

[Bug target/111931] RISC-V: Trivial optimization of VSETVL PASS

[juzhe.zhong at rivai dot ai via Gcc-bugs]

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

JuzheZhong  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from JuzheZhong  ---
-g0 will fix this issue.
Close it.

[Bug target/111311] RISC-V regression testsuite errors with --param=riscv-autovec-preference=scalable

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #13 from Andrew Pinski  ---
(In reply to JuzheZhong from comment #12)
> signbit execution issue should be ignored. It's ISA issue not compiler issue.
> 
> I knew this issue long time ago and confirm Clang has the sam issue:
> 
> https://github.com/riscv-collab/riscv-gnu-toolchain/issues/1075

INT_MIN well negativing INT_MIN is undefined ...

If there is a testcase that depends on that, we should fix the testcase (now
with -fwrapv it should be well defined).

[Bug middle-end/111401] Middle-end: Missed optimization of MASK_LEN_FOLD_LEFT_PLUS

[juzhe.zhong at rivai dot ai via Gcc-bugs]

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

JuzheZhong  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #9 from JuzheZhong  ---
Fixed

[Bug target/87281] qsort checking ICE in ia64_reorg building libgo

[jsm28 at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #15 from Joseph S. Myers  ---
Created attachment 56496
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56496=edit
Test that started failing on 20 July 2023

Another instance of this ICE appeared in my glibc bot on 20 July; compile
ibm1008_420.i with -O2. This failure was introduced by

commit ef28aadad6e5cff3d7494f3c97d435a6579a2e2d
Author: Jan Hubicka 
Date:   Thu Jul 20 15:41:39 2023 +0200

loop-ch improvements, part 3

although I fully expect it's really the same bug as for the other testcases
discussed here and it was just some perturbation to the processing of this test
that resulted in the appearance for that test with that commit.

[Bug target/87281] [14 Regression] qsort checking ICE in ia64_reorg building libgo

[jsm28 at gcc dot gnu.org via Gcc-bugs]

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

Joseph S. Myers  changed:

   What|Removed |Added

   Last reconfirmed|2019-06-14 00:00:00 |2023-11-2
   Target Milestone|--- |14.0
Summary|qsort checking ICE in   |[14 Regression] qsort
   |ia64_reorg building libgo   |checking ICE in ia64_reorg
   ||building libgo

gcc-11-20231102 is now available

[GCC Administrator via Gcc]

Snapshot gcc-11-20231102 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/11-20231102/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 11 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch 
releases/gcc-11 revision 0836caff6ad2fe56cf92c11db1c53a37c2ed3429

You'll find:

 gcc-11-20231102.tar.xz   Complete GCC

  SHA256=28f3e4bdc5a0ff0a6041c1a02d41ba80b9a5544db4ea7626598a771caf08f7a5
  SHA1=0ff7e1dbb39ce53bc4685a2b768705ee71de80c7

Diffs from 11-20231026 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-11
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

[Bug target/111311] RISC-V regression testsuite errors with --param=riscv-autovec-preference=scalable

[juzhe.zhong at rivai dot ai via Gcc-bugs]

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

--- Comment #12 from JuzheZhong  ---
signbit execution issue should be ignored. It's ISA issue not compiler issue.

I knew this issue long time ago and confirm Clang has the sam issue:

https://github.com/riscv-collab/riscv-gnu-toolchain/issues/1075

[Bug fortran/112316] [13 Regression] Fix for PR87477 rejects valid code with a bogus error about pointer assignment and causes an ICE since r13-7761-gd6997a5aab7aaa325946a6283bfee8ac2bd9f540

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Paul Thomas :

https://gcc.gnu.org/g:7c1d011bc1f8b26dba4ebcbd4a429628dfb2698d

commit r14-5088-g7c1d011bc1f8b26dba4ebcbd4a429628dfb2698d
Author: Paul Thomas 
Date:   Thu Nov 2 22:23:05 2023 +

Fortran: Fix for regression in ASSOCIATE [PR112316]

2023-11-02  Paul Thomas  

gcc/fortran
PR fortran/112316
* parse.cc (parse_associate): Remove condition that caused this
regression.

gcc/testsuite/
PR fortran/112316
* gfortran.dg/pr112316.f90: New test.

Re: [PATCH 2/4] maintainer-scripts/gcc_release: create index between snapshots <-> commits

[rep . dot . nop]

On 2 November 2023 11:25:47 CET, Jonathan Wakely  wrote:
>On Thu, 2 Nov 2023 at 10:23, Andreas Schwab wrote:
>>
>> On Nov 02 2023, Jonathan Wakely wrote:
>>
>> > Git tags are cheap, but I can imagine a concern about hundreds of new
>> > tags "littering" the output of 'git tag -l'. I don't _think_ you can
>> > put tags under an alternative ref that isn't fetched by default (as we
>> > do with refs/users and refs/vendor). I think tags have to go under
>> > refs/tags. But grep -v could be used to filter out snapshot tags
>> > easily.
>>
>> There is no inherent limitation on publishing tags outside of refs/tags,
>> to make them invisible by git tag.  There are already existing examples
>> of tags residing under various refs/users and refs/vendors namespaces.
>
>
>Ah, good to know, thanks.
>
>So then there's no reason that snapshots would have to clutter up the
>list of default tags for anybody who isn't interested in them.
>

Thanks Andreas. Exactly. So, just to emphasise the obvious:
Let's please use refs/snapshot ?

[Bug tree-optimization/112357] New: Documentation for vect-max-peeling-for-alignment references -1 but -1 does not work

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 112357
   Summary: Documentation for vect-max-peeling-for-alignment
references -1 but -1 does not work
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: documentation
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

Using `-O2 --param vect-max-peeling-for-alignment=-1` provides the following
error message:
```
g++: error: argument to '--param=vect-max-peeling-for-alignment=' should be a
non-negative integer
```

But https://gcc.gnu.org/onlinedocs//gcc/Optimize-Options.html documents -1:
```
vect-max-peeling-for-alignment
The maximum number of loop peels to enhance access alignment for vectorizer.
Value -1 means no limit.
```

[Bug fortran/97245] ASSOCIATED intrinsic does not recognize a pointer variable the second time it is used

[anlauf at gcc dot gnu.org via Gcc-bugs]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

Summary|ASSOCIATE intrinsic does|ASSOCIATED intrinsic does
   |not recognize a ponter  |not recognize a pointer
   |variable the second time it |variable the second time it
   |is used |is used
   Keywords||rejects-valid
 CC||anlauf at gcc dot gnu.org

--- Comment #2 from anlauf at gcc dot gnu.org ---
Interesting bug.

The code is accepted if the declaration

  PROCEDURE(proc_void), POINTER:: pADJSensib

is moved into the subroutine.  In the original form, -fdump-fortran-original
shows the following:

code:
IF _gfortran_associated[[((formulaciones:padjsensib) ((arg not-present)))]]
  CALL padjsensib ()
ENDIF
IF associated[((calculo:padjsensib))]
  CALL padjsensib ()
ENDIF

This is weird.

[Bug target/111311] RISC-V regression testsuite errors with --param=riscv-autovec-preference=scalable

[vineetg at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #11 from Vineet Gupta  ---
(In reply to Robin Dapp from comment #10)
> As a general remark:  Some of those are present on other backends as well,
> some have been introduced by recent common-code changes and some are bogus
> test prerequisites or checks.

Is is possible to this identification (so we can at least mark them xfail or
some such). A lot of folks working on middle-end know this for certain, but for
the mere mortals every test failure seems just the same and equally important
:-)

[Bug tree-optimization/112356] `x == MIN & x > y` is not optimized to 0 if x was casted to signed from unsigned

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from Andrew Pinski  ---
The problem is we can't use `(match min_value` here but rather we need to
change it from:
```
(for eqne (eq ne)
 (simplify
  (bit_and:c (gt:c@2 @0 @1) (eqne @0 min_value))
```
to:
```
(for eqne (eq ne)
 (simplify
  (bit_and:c (gt:c@2 @0 @1) (eqne @3 uniform_integer_cst_p@2))
 (if (bitwise_equal_p (@0, @3)
  && min_value_p (TREE_TYPE (@0), uniform_integer_cst_p (@2))
```

Etc.

We could have min_value_p use uniform_integer_cst_p inside it instead of doing
it before hand.

[Bug tree-optimization/112356] `x == MIN & x > y` is not optimized to 0 if x was casted to signed from unsigned

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Last reconfirmed||2023-11-02

[Bug tree-optimization/112356] New: `x == MIN & x > y` is not optimized to 0 if x was casted to signed from unsigned

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 112356
   Summary: `x == MIN & x > y` is not optimized to 0 if x was
casted to signed from unsigned
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: pinskia at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

Take:
```
#include 

signed f2_1( unsigned x,  signed y)
{
   signed xs = x;
   signed t = x == INT_MIN;
   signed t1 = xs > y;
  return t & t1;
}
```

This is not optimized to 0.

Re: [PATCH] libstdc++: avoid uninitialized read in basic_string constructor

[Jonathan Wakely]

On Thu, 2 Nov 2023 at 19:58, Ben Sherman  wrote:
>
> Tested on x86_64-pc-linux-gnu, please let me know if there's anything
> else needed. I haven't contributed before and don't have write access, so
> apologies if I've missed anything.

This was https://gcc.gnu.org/PR109703 (and several duplicates) and
should already be fixed in all affected branches. Where are you seeing
this?

> The basic_string input iterator constructor incrementally reads data and
> allocates the internal buffer as-needed. When _M_dispose() is called, there
> is a check for whether the local buffer is being used - if it is, there is
> an additional check guarding __builtin_unreachable() for the value of
> _M_string_length. The constructor does not initialize _M_string_length
> until all data has been read, so the first re-allocation out of the local
> buffer will have an uninitialized read.
>
> This updates the basic_string input iterator constructor to properly set
> _M_string_length as data is being read.  It additionally introduces a new
> _M_assign_terminator() function to assign the null-terminator based on the
> currently-stored _M_string_length.

Adding new member functions to std::string requires exporting them
from the shared library, which requires bumping the shared library
version, which is an ABI change that isn't suitable for backporting to
release branches. But it doesn't matter if we don't need to make this
change (and I don't think we do need to).


> libstdc++-v3/ChangeLog:
>
> * include/bits/basic_string.h (_M_assign_terminator()): New
>   function.
>   (_M_set_length()): Use _M_assign_terminator().
> * include/bits/basic_string.tcc (_M_construct(InIter, InIter,
>   input_iterator_tag)): Set length incrementally, use
>   _M_assign_terminator().
>
> diff --git a/libstdc++-v3/include/bits/basic_string.h 
> b/libstdc++-v3/include/bits/basic_string.h
> index 0fa32afeb..ba02d8f0f 100644
> --- a/libstdc++-v3/include/bits/basic_string.h
> +++ b/libstdc++-v3/include/bits/basic_string.h
> @@ -258,12 +258,17 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
>_M_capacity(size_type __capacity)
>{ _M_allocated_capacity = __capacity; }
>
> +  _GLIBCXX20_CONSTEXPR
> +  void
> +  _M_assign_terminator()
> +  { traits_type::assign(_M_data()[_M_string_length], _CharT()); }
> +
>_GLIBCXX20_CONSTEXPR
>void
>_M_set_length(size_type __n)
>{
> _M_length(__n);
> -   traits_type::assign(_M_data()[__n], _CharT());
> +   _M_assign_terminator();
>}
>
>_GLIBCXX20_CONSTEXPR
> diff --git a/libstdc++-v3/include/bits/basic_string.tcc 
> b/libstdc++-v3/include/bits/basic_string.tcc
> index f0a44e5e8..84366a44a 100644
> --- a/libstdc++-v3/include/bits/basic_string.tcc
> +++ b/libstdc++-v3/include/bits/basic_string.tcc
> @@ -182,6 +182,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
> ++__beg;
>   }
>
> +   _M_length(__len);
> +
> struct _Guard
> {
>   _GLIBCXX20_CONSTEXPR
> @@ -206,12 +208,13 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
> _M_capacity(__capacity);
>   }
> traits_type::assign(_M_data()[__len++], *__beg);
> +   _M_length(__len);
> ++__beg;
>   }
>
> __guard._M_guarded = 0;
>
> -   _M_set_length(__len);
> +   _M_assign_terminator();
>}
>
>template
> --
> 2.21.0
>
>
>
>
>
>
>
> This electronic mail message and any attached files contain information 
> intended for the exclusive use of the individual or entity to whom it is 
> addressed and may contain information that is proprietary, confidential 
> and/or exempt from disclosure under applicable law. If you are not the 
> intended recipient, you are hereby notified that any viewing, copying, 
> disclosure or distribution of this information may be subject to legal 
> restriction or sanction. Please notify the sender, by electronic mail or 
> telephone, of any unintended recipients and delete the original message 
> without making any copies.
>

[Bug c++/109740] -Woverloaded-virtual is too aggressive

[emerg.reanimator at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Alexander Goomenuk  ---
Created attachment 56495
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56495=edit
Overloaded virtual testcase

Another relevant issue with gcc (GCC) 13.2.1 20231011 (Red Hat 13.2.1-4) and
-Woverloaded-virtual.

Overloading method f() in Derived class affects the warning that is caused by
assignment operator! 

Woverloaded-virtual-test.cpp:6:28: warning: ‘virtual const Parent&
Parent::operator=(int&)’ was hidden [-Woverloaded-virtual=]
6 | virtual const Parent & operator=(int )
  |^~~~
Woverloaded-virtual-test.cpp:15:8: note:   by ‘constexpr Derived&
Derived::operator=(const Derived&)’
   15 | struct Derived : public Parent
  |^~~

[PATCH] tree-optimization: Add register pressure heuristics

[Ajit Agarwal]

Hello All:

Currently code sinking heuristics are based on profile data like
basic block count and sink frequency threshold. We have removed
such heuristics and added register pressure heuristics based on
live-in and live-out of early blocks and immediate dominator of
use blocks of the same loop nesting depth.

Such heuristics reduces register pressure when code sinking is 
done with same loop nesting depth.

High register pressure region is the region where there are live-in of
early blocks that has been modified by the early block. If there are
modification of the variables in best block that are live-in in early
block that are live-out of best block.

Bootstrapped and regtested on powerpc64-linux-gnu.

Thanks & Regards
Ajit

tree-optimization: Add register pressure heuristics

Currently code sinking heuristics are based on profile data like
basic block count and sink frequency threshold. We have removed
such heuristics to add register pressure heuristics based on
live-in and live-out of early blocks and immediate dominator of
use blocks.

High register pressure region is the region where there are live-in of
early blocks that has been modified by the early block. If there are
modification of the variables in best block that are live-in in early
block that are live-out of best block.

2023-11-03  Ajit Kumar Agarwal  

gcc/ChangeLog:

* tree-ssa-sink.cc (statement_sink_location): Add tree_live_info_p
as paramters.
(sink_code_in_bb): Ditto.
(select_best_block): Add register pressure heuristics to select
the best blocks in the immediate dominator for same loop nest depth.
(execute): Add live range analysis.
(additional_var_map): New function.
* tree-ssa-live.cc (set_var_live_on_entry): Add virtual operand
tests on ssa_names.
(verify_live_on_entry): Ditto.

gcc/testsuite/ChangeLog:

* gcc.dg/tree-ssa/ssa-sink-21.c: New test.
* gcc.dg/tree-ssa/ssa-sink-22.c: New test.
---
 gcc/testsuite/gcc.dg/tree-ssa/ssa-sink-21.c | 15 
 gcc/testsuite/gcc.dg/tree-ssa/ssa-sink-22.c | 19 +
 gcc/tree-ssa-live.cc| 11 ++-
 gcc/tree-ssa-sink.cc| 93 ++---
 4 files changed, 104 insertions(+), 34 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/ssa-sink-21.c
 create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/ssa-sink-22.c

diff --git a/gcc/testsuite/gcc.dg/tree-ssa/ssa-sink-21.c 
b/gcc/testsuite/gcc.dg/tree-ssa/ssa-sink-21.c
new file mode 100644
index 000..d3b79ca5803
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/ssa-sink-21.c
@@ -0,0 +1,15 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-sink-stats" } */
+void bar();
+int j;
+void foo(int a, int b, int c, int d, int e, int f)
+{
+  int l;
+  l = a + b + c + d +e + f;
+  if (a != 5)
+{
+  bar();
+  j = l;
+}
+}
+/* { dg-final { scan-tree-dump 
{l_12\s+=\s+_4\s+\+\s+f_11\(D\);\n\s+bar\s+\(\)} sink1 } } */
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/ssa-sink-22.c 
b/gcc/testsuite/gcc.dg/tree-ssa/ssa-sink-22.c
new file mode 100644
index 000..84e7938c54f
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/ssa-sink-22.c
@@ -0,0 +1,19 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-sink-stats" } */
+void bar();
+int j, x;
+void foo(int a, int b, int c, int d, int e, int f)
+{
+  int l;
+  l = a + b + c + d +e + f;
+  if (a != 5)
+{
+  bar();
+  if (b != 3)
+x = 3;
+  else
+x = 5;
+  j = l;
+}
+}
+/* { dg-final { scan-tree-dump 
{l_13\s+=\s+_4\s+\+\s+f_12\(D\);\n\s+bar\s+\(\)} sink1 } } */
diff --git a/gcc/tree-ssa-live.cc b/gcc/tree-ssa-live.cc
index f06daf23035..998fe588278 100644
--- a/gcc/tree-ssa-live.cc
+++ b/gcc/tree-ssa-live.cc
@@ -1141,7 +1141,8 @@ set_var_live_on_entry (tree ssa_name, tree_live_info_p 
live)
 def_bb = ENTRY_BLOCK_PTR_FOR_FN (cfun);
 
   /* An undefined local variable does not need to be very alive.  */
-  if (ssa_undefined_value_p (ssa_name, false))
+  if (virtual_operand_p (ssa_name)
+  || ssa_undefined_value_p (ssa_name, false))
 return;
 
   /* Visit each use of SSA_NAME and if it isn't in the same block as the def,
@@ -1540,7 +1541,6 @@ debug (tree_live_info_d *ptr)
 
 
 /* Verify that the info in LIVE matches the current cfg.  */
-
 static void
 verify_live_on_entry (tree_live_info_p live)
 {
@@ -1569,11 +1569,13 @@ verify_live_on_entry (tree_live_info_p live)
  tree d = NULL_TREE;
  bitmap loe;
  var = partition_to_var (map, i);
+ if (var == NULL_TREE)
+   continue;
  stmt = SSA_NAME_DEF_STMT (var);
  tmp = gimple_bb (stmt);
+
  if (SSA_NAME_VAR (var))
d = ssa_default_def (cfun, SSA_NAME_VAR (var));
-
  loe = live_on_entry (live, e->dest);
  if (loe && bitmap_bit_p (loe, i))
{
@@ -1614,7 +1616,8 @@ verify_live_on_entry (tree_live_info_p live)
  {
 

Re: RFC: the proposal to resolve the missing dependency issue for counted_by attribute

[Qing Zhao]

> On Nov 2, 2023, at 8:09 AM, Jakub Jelinek  wrote:
> 
> On Thu, Nov 02, 2023 at 12:52:50PM +0100, Richard Biener wrote:
>>> What I meant is to emit
>>> tmp_4 = .ACCESS_WITH_SIZE ([0], , (typeof ()) 0);
>>> p_5 = _4[2];
>>> i.e. don't associate the pointer with a value of the size, but with
>>> an address where to find the size (plus how large it is), basically escape
>>> pointer to the size at that point.  And __builtin_dynamic_object_size is 
>>> pure,
>>> so supposedly it can depend on what the escaped pointer points to.
>> 
>> Well, yeah - that would work but depend on .ACCESS_WITH_SIZE being an
>> escape point (quite bad IMHO)
> 
> That is why I've said we need to decide what cost we want to suffer because
> of that.
> 
>> and __builtin_dynamic_object_size being
>> non-const (that's probably not too bad).
> 
> It is already pure,leaf,nothrow (unlike __builtin_object_size which is 
> obviously
> const,leaf,nothrow).  Because under the hood, it can read memory when
> expanded.
> 
>>> We'd see that a particular pointer is size associated with  address
>>> and would use that address cast to the type of the third argument (to
>>> preserve the exact pointer type on INTEGER_CST, though not sure, wouldn't
>>> VN CSE it anyway if one has say
>>> union U { struct S { int a; char b __attribute__((counted_by (a))) []; } s;
>>>  struct T { char c, d, e, f; char g __attribute__((counted_by (c))) 
>>> []; } t; };
>>> and
>>> .ACCESS_WITH_SIZE ([0], , (int *) 0);
>>> ...
>>> .ACCESS_WITH_SIZE ([0], , (int *) 0);
>>> ?
>> 
>> We'd probably CSE that - the usual issue of address-with-same-value.
>> 
>>> It would mean though that counted_by wouldn't be allowed to be a
>>> bit-field...
>> 
>> Yup.  We could also pass a pointer to the container though, that's good 
>> enough
>> for the escape, and pass the size by value in addition to that.
> 
> I was wondering about stuff like _BitInt.  But sure, counted_by is just an
> extension, we can just refuse counting by _BitInt in addition to counting by
> floating point, pointers, aggregates, bit-fields, or we could somehow encode
> all the needed type's properties numerically into an integral constant.
> Similarly for alias set (unless it uses 0 for reads).

counted_by currently is limited to INTEGER type. This should resolve this 
issue, right?

Qing
> 
>   Jakub
> 

Re: RFC: the proposal to resolve the missing dependency issue for counted_by attribute

[Qing Zhao]

> On Nov 2, 2023, at 7:52 AM, Richard Biener  wrote:
> 
> On Thu, Nov 2, 2023 at 11:40 AM Jakub Jelinek  wrote:
>> 
>> On Thu, Nov 02, 2023 at 11:18:09AM +0100, Richard Biener wrote:
 Or, if we want to pay further price, .ACCESS_WITH_SIZE could take as one of
 the arguments not the size value, but its address.  Then at __bdos time
 we would dereference that pointer to get the size.
 So,
 struct S { int a; char b __attribute__((counted_by (a))) []; };
 struct S s;
 s.a = 5;
 char *p = [2];
 int i1 = __builtin_dynamic_object_size (p, 0);
 s.a = 3;
 int i2 = __builtin_dynamic_object_size (p, 0);
 would then yield 3 and 1 rather than 3 and 3.
>>> 
>>> I fail to see how we can get the __builtin_dynamic_object_size call
>>> data dependent on s.a, thus avoid re-ordering or even DSE of the
>>> store.
>> 
>> If [2] is lowered as
>> sz_1 = s.a;
>> tmp_2 = .ACCESS_WITH_SIZE ([0], sz_1);
>> p_3 = _2[2];
>> then sure, there is no way, you get the size from that point.
>> tree-object-size.cc tracking then determines that in a particular
>> case the pointer is size associated with sz_1 and use that value
>> as the size (with the usual adjustments for pointer arithmetics and the
>> like).
>> 
>> What I meant is to emit
>> tmp_4 = .ACCESS_WITH_SIZE ([0], , (typeof ()) 0);
>> p_5 = _4[2];
>> i.e. don't associate the pointer with a value of the size, but with
>> an address where to find the size (plus how large it is), basically escape
>> pointer to the size at that point.  And __builtin_dynamic_object_size is 
>> pure,
>> so supposedly it can depend on what the escaped pointer points to.
> 
> Well, yeah - that would work but depend on .ACCESS_WITH_SIZE being an
> escape point (quite bad IMHO) and __builtin_dynamic_object_size being
> non-const (that's probably not too bad).
> 
>> We'd see that a particular pointer is size associated with  address
>> and would use that address cast to the type of the third argument (to
>> preserve the exact pointer type on INTEGER_CST, though not sure, wouldn't
>> VN CSE it anyway if one has say
>> union U { struct S { int a; char b __attribute__((counted_by (a))) []; } s;
>>  struct T { char c, d, e, f; char g __attribute__((counted_by (c))) 
>> []; } t; };
>> and
>> .ACCESS_WITH_SIZE ([0], , (int *) 0);
>> ...
>> .ACCESS_WITH_SIZE ([0], , (int *) 0);
>> ?
> 
> We'd probably CSE that - the usual issue of address-with-same-value.
> 
>> It would mean though that counted_by wouldn't be allowed to be a
>> bit-field...
> 
> Yup.  We could also pass a pointer to the container though, that's good enough
> for the escape, and pass the size by value in addition to that.
Could you explain a little bit more here? Then the .ACCESS_WITH_SIZE will become

PTR = .ACCESS_WITH_SIZE (PTR, ’s Container, SIZE, ACCESS_MODE)

??

> 
>>Jakub
>> 

Re: RFC: the proposal to resolve the missing dependency issue for counted_by attribute

[Qing Zhao]

Thanks a lot for raising these issues. 

If I understand correctly,  the major question we need to answer is:

For the following example: (Jakub mentioned this  in an early message)

  1 struct S { int a; char b __attribute__((counted_by (a))) []; };
  2 struct S s;
  3 s.a = 5;
  4 char *p = [2];
  5 int i1 = __builtin_dynamic_object_size (p, 0);
  6 s.a = 3;
  7 int i2 = __builtin_dynamic_object_size (p, 0);

Should the 2nd __bdos call (line 7) get
A. the latest value of s.a (line 6) for it’s size? 
Or  B. the value when the s.b was referenced (line 3, line 4)?

A should be more convenient for the user to use the dynamic array feature.
With B, the user has to modify the source code (to add code to “re-obtain” 
the pointer after the size was adjusted at line 6) as mentioned by Richard. 

This depends on how we design the new internal function .ACCESS_WITH_SIZE

1. Size is passed by value to .ACCESS_WITH_SIZE as we currently designed. 

PTR = .ACCESS_WITH_SIZE (PTR, SIZE, ACCESS_MODE)

2. Size is passed by reference to .ACCESS_WITH_SIZE as Jakub suggested.

PTR = .ACCESS_WITH_SIZE(PTR, , TYPEOFSIZE, ACCESS_MODE)

With 1, We can only provide B, the user needs to modify the source code to get 
the full feature of dynamic array;
With 2, We can provide  A, the user will get full support to the dynamic array 
without restrictions in the source code. 

However, We have to pay additional cost for supporting A by using 2, which 
includes:

1. .ACCESS_WITH_SIZE will become an escape point, which will further impact the 
IPA optimizations, more runtime overhead. 
Then .ACCESS_WTH_SIZE will not be CONST, right? But it will still be PURE?

2. __builtin_dynamic_object_size will NOT be LEAF anymore.  This will also 
impact some IPA optimizations, more runtime overhead. 

I think the following are the factors that make the decision:

1. How big the performance impact?
2. How important the dynamic array feature? Is adding some user restrictions as 
Richard mentioned feasible to support this feature?

Maybe we can implement 1 first, if the full support to the dynamic array is 
needed, we can add 2 then? 
Or, we can implement both, and compare the performance difference, then decide?

Qing




> On Nov 2, 2023, at 8:09 AM, Jakub Jelinek  wrote:
> 
> On Thu, Nov 02, 2023 at 12:52:50PM +0100, Richard Biener wrote:
>>> What I meant is to emit
>>> tmp_4 = .ACCESS_WITH_SIZE ([0], , (typeof ()) 0);
>>> p_5 = _4[2];
>>> i.e. don't associate the pointer with a value of the size, but with
>>> an address where to find the size (plus how large it is), basically escape
>>> pointer to the size at that point.  And __builtin_dynamic_object_size is 
>>> pure,
>>> so supposedly it can depend on what the escaped pointer points to.
>> 
>> Well, yeah - that would work but depend on .ACCESS_WITH_SIZE being an
>> escape point (quite bad IMHO)
> 
> That is why I've said we need to decide what cost we want to suffer because
> of that.
> 
>> and __builtin_dynamic_object_size being
>> non-const (that's probably not too bad).
> 
> It is already pure,leaf,nothrow (unlike __builtin_object_size which is 
> obviously
> const,leaf,nothrow).  Because under the hood, it can read memory when
> expanded.
> 
>>> We'd see that a particular pointer is size associated with  address
>>> and would use that address cast to the type of the third argument (to
>>> preserve the exact pointer type on INTEGER_CST, though not sure, wouldn't
>>> VN CSE it anyway if one has say
>>> union U { struct S { int a; char b __attribute__((counted_by (a))) []; } s;
>>>  struct T { char c, d, e, f; char g __attribute__((counted_by (c))) 
>>> []; } t; };
>>> and
>>> .ACCESS_WITH_SIZE ([0], , (int *) 0);
>>> ...
>>> .ACCESS_WITH_SIZE ([0], , (int *) 0);
>>> ?
>> 
>> We'd probably CSE that - the usual issue of address-with-same-value.
>> 
>>> It would mean though that counted_by wouldn't be allowed to be a
>>> bit-field...
>> 
>> Yup.  We could also pass a pointer to the container though, that's good 
>> enough
>> for the escape, and pass the size by value in addition to that.
> 
> I was wondering about stuff like _BitInt.  But sure, counted_by is just an
> extension, we can just refuse counting by _BitInt in addition to counting by
> floating point, pointers, aggregates, bit-fields, or we could somehow encode
> all the needed type's properties numerically into an integral constant.
> Similarly for alias set (unless it uses 0 for reads).
> 
>   Jakub
> 

Re: [Patch, fortran] PR98498 - Interp request: defined operators and unlimited polymorphic

[Harald Anlauf]

Hi Paul,

Am 02.11.23 um 19:18 schrieb Paul Richard Thomas:

Hi Harald,

I was overthinking the problem. The rejected cases led me to a fix that can
only be described as a considerable simplification compared with the first
patch!


this patch is *much* simpler, makes more sense, and works here. :-)


The testcase now reflects the requirements of the standard and
regtests without failures.

OK for mainline?


Yes, OK for mainline.

Thanks,
Harald


Thanks

Paul

Fortran: Defined operators with unlimited polymorphic args [PR98498]

2023-11-02  Paul Thomas  

gcc/fortran
PR fortran/98498
* interface.cc (upoly_ok): Defined operators using unlimited
polymorphic formal arguments must not override the intrinsic
operator use.

gcc/testsuite/
PR fortran/98498
* gfortran.dg/interface_50.f90: New test.


On Wed, 1 Nov 2023 at 20:12, Harald Anlauf  wrote:


Hi Paul,

Am 01.11.23 um 19:02 schrieb Paul Richard Thomas:

The interpretation request came in a long time ago but I only just got
around to implementing it.

The updated text from the standard is in the comment. Now I am writing
this, I think that I should perhaps use switch(op)/case rather than using
if/else if and depending on the order of the gfc_intrinsic_op enum being
maintained. Thoughts?


the logic is likely harder to parse with if/else than with
switch(op)/case.  However, I do not think that the order of
the enum will ever be changed, as the module format relies
on that very order.


The testcase runs fine with both mainline and nagfor. I think that
compile-only with counts of star-eq and star_not should suffice.


I found other cases that are rejected even with your patch,
but which are accepted by nagfor.  Example:

 print *, ('a' == c)

Nagfor prints F at runtime as expected, as it correctly resolves
this to star_eq.  Further examples can be easily constructed.

Can you have a look?

Thanks,
Harald


Regtests with no regressions. OK for mainline?

Paul

Fortran: Defined operators with unlimited polymorphic args [PR98498]

2023-11-01  Paul Thomas  

gcc/fortran
PR fortran/98498
* interface.cc (upoly_ok): New function.
(gfc_extend_expr): Use new function to ensure that defined
operators using unlimited polymorphic formal arguments do not
override their intrinsic uses.

gcc/testsuite/
PR fortran/98498
* gfortran.dg/interface_50.f90: New test.

[Bug c++/112301] [12/13/14 regression] Double destruction of returned object when exiting the scope causes an exception which gets rethrown since r12-6333-gb10e031458d541

[jason at gcc dot gnu.org via Gcc-bugs]

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

Jason Merrill  changed:

   What|Removed |Added

  Known to work||14.0

--- Comment #3 from Jason Merrill  ---
Fixed for 14 so far.

[Bug c++/33799] Return value's destructor not executed when a local variable's destructor throws

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #23 from CVS Commits  ---
The trunk branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:ae07265381d934ee97fb1ce8915731158c91babc

commit r14-5086-gae07265381d934ee97fb1ce8915731158c91babc
Author: Jason Merrill 
Date:   Mon Oct 30 17:44:54 2023 -0400

c++: retval dtor on rethrow [PR112301]

In r12-6333 for PR33799, I fixed the example in [except.ctor]/2.  In that
testcase, the exception is caught and the function returns again,
successfully.

In this testcase, however, the exception is rethrown, and hits two separate
cleanups: one in the try block and the other in the function body.  So we
destroy twice an object that was only constructed once.

Fortunately, the fix for the normal case is easy: we just need to clear the
"return value constructed by return" flag when we do it the first time.

This gets more complicated with the named return value optimization, since
we don't want to destroy the return value while the NRV variable is still
in
scope.

PR c++/112301
PR c++/102191
PR c++/33799

gcc/cp/ChangeLog:

* except.cc (maybe_splice_retval_cleanup): Clear
current_retval_sentinel when destroying retval.
* semantics.cc (nrv_data): Add in_nrv_cleanup.
(finalize_nrv): Set it.
(finalize_nrv_r): Fix handling of throwing cleanups.

gcc/testsuite/ChangeLog:

* g++.dg/eh/return1.C: Add more cases.

[Bug c++/102191] [C++20] Can't return prvalue with potentially-throwing destructor during constant evaluation

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from CVS Commits  ---
The trunk branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:ae07265381d934ee97fb1ce8915731158c91babc

commit r14-5086-gae07265381d934ee97fb1ce8915731158c91babc
Author: Jason Merrill 
Date:   Mon Oct 30 17:44:54 2023 -0400

c++: retval dtor on rethrow [PR112301]

In r12-6333 for PR33799, I fixed the example in [except.ctor]/2.  In that
testcase, the exception is caught and the function returns again,
successfully.

In this testcase, however, the exception is rethrown, and hits two separate
cleanups: one in the try block and the other in the function body.  So we
destroy twice an object that was only constructed once.

Fortunately, the fix for the normal case is easy: we just need to clear the
"return value constructed by return" flag when we do it the first time.

This gets more complicated with the named return value optimization, since
we don't want to destroy the return value while the NRV variable is still
in
scope.

PR c++/112301
PR c++/102191
PR c++/33799

gcc/cp/ChangeLog:

* except.cc (maybe_splice_retval_cleanup): Clear
current_retval_sentinel when destroying retval.
* semantics.cc (nrv_data): Add in_nrv_cleanup.
(finalize_nrv): Set it.
(finalize_nrv_r): Fix handling of throwing cleanups.

gcc/testsuite/ChangeLog:

* g++.dg/eh/return1.C: Add more cases.

[Bug c++/112301] [12/13/14 regression] Double destruction of returned object when exiting the scope causes an exception which gets rethrown since r12-6333-gb10e031458d541

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from CVS Commits  ---
The trunk branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:ae07265381d934ee97fb1ce8915731158c91babc

commit r14-5086-gae07265381d934ee97fb1ce8915731158c91babc
Author: Jason Merrill 
Date:   Mon Oct 30 17:44:54 2023 -0400

c++: retval dtor on rethrow [PR112301]

In r12-6333 for PR33799, I fixed the example in [except.ctor]/2.  In that
testcase, the exception is caught and the function returns again,
successfully.

In this testcase, however, the exception is rethrown, and hits two separate
cleanups: one in the try block and the other in the function body.  So we
destroy twice an object that was only constructed once.

Fortunately, the fix for the normal case is easy: we just need to clear the
"return value constructed by return" flag when we do it the first time.

This gets more complicated with the named return value optimization, since
we don't want to destroy the return value while the NRV variable is still
in
scope.

PR c++/112301
PR c++/102191
PR c++/33799

gcc/cp/ChangeLog:

* except.cc (maybe_splice_retval_cleanup): Clear
current_retval_sentinel when destroying retval.
* semantics.cc (nrv_data): Add in_nrv_cleanup.
(finalize_nrv): Set it.
(finalize_nrv_r): Fix handling of throwing cleanups.

gcc/testsuite/ChangeLog:

* g++.dg/eh/return1.C: Add more cases.

[pushed] c++: use hash_set in nrv_data

[Jason Merrill]

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

-- 8< --

I noticed we were using a hash_table directly here instead of the simpler
hash_set interface.  Also, let's check for the variable itself and repeats
earlier, since they should happen more often than any of the other cases.

gcc/cp/ChangeLog:

* semantics.cc (nrv_data): Change visited to hash_set.
(finalize_nrv_r): Reorganize.
---
 gcc/cp/semantics.cc | 26 --
 1 file changed, 12 insertions(+), 14 deletions(-)

diff --git a/gcc/cp/semantics.cc b/gcc/cp/semantics.cc
index a0f2edcf117..37bffca8e55 100644
--- a/gcc/cp/semantics.cc
+++ b/gcc/cp/semantics.cc
@@ -4980,7 +4980,7 @@ public:
 
   tree var;
   tree result;
-  hash_table > visited;
+  hash_set visited;
   bool simple;
   bool in_nrv_cleanup;
 };
@@ -4991,12 +4991,22 @@ static tree
 finalize_nrv_r (tree* tp, int* walk_subtrees, void* data)
 {
   class nrv_data *dp = (class nrv_data *)data;
-  tree_node **slot;
 
   /* No need to walk into types.  There wouldn't be any need to walk into
  non-statements, except that we have to consider STMT_EXPRs.  */
   if (TYPE_P (*tp))
 *walk_subtrees = 0;
+
+  /* Replace all uses of the NRV with the RESULT_DECL.  */
+  else if (*tp == dp->var)
+*tp = dp->result;
+
+  /* Avoid walking into the same tree more than once.  Unfortunately, we
+ can't just use walk_tree_without duplicates because it would only call
+ us for the first occurrence of dp->var in the function body.  */
+  else if (dp->visited.add (*tp))
+*walk_subtrees = 0;
+
   /* If there's a label, we might need to destroy the NRV on goto (92407).  */
   else if (TREE_CODE (*tp) == LABEL_EXPR && !dp->in_nrv_cleanup)
 dp->simple = false;
@@ -5086,18 +5096,6 @@ finalize_nrv_r (tree* tp, int* walk_subtrees, void* data)
   SET_EXPR_LOCATION (init, EXPR_LOCATION (*tp));
   *tp = init;
 }
-  /* And replace all uses of the NRV with the RESULT_DECL.  */
-  else if (*tp == dp->var)
-*tp = dp->result;
-
-  /* Avoid walking into the same tree more than once.  Unfortunately, we
- can't just use walk_tree_without duplicates because it would only call
- us for the first occurrence of dp->var in the function body.  */
-  slot = dp->visited.find_slot (*tp, INSERT);
-  if (*slot)
-*walk_subtrees = 0;
-  else
-*slot = *tp;
 
   /* Keep iterating.  */
   return NULL_TREE;

base-commit: 36a26298ec7dfca615d4ba411a3508d1287d6ce5
-- 
2.39.3

[pushed] c++: retval dtor on rethrow [PR112301]

[Jason Merrill]

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

-- 8< --

In r12-6333 for PR33799, I fixed the example in [except.ctor]/2.  In that
testcase, the exception is caught and the function returns again,
successfully.

In this testcase, however, the exception is rethrown, and hits two separate
cleanups: one in the try block and the other in the function body.  So we
destroy twice an object that was only constructed once.

Fortunately, the fix for the normal case is easy: we just need to clear the
"return value constructed by return" flag when we do it the first time.

This gets more complicated with the named return value optimization, since
we don't want to destroy the return value while the NRV variable is still in
scope.

PR c++/112301
PR c++/102191
PR c++/33799

gcc/cp/ChangeLog:

* except.cc (maybe_splice_retval_cleanup): Clear
current_retval_sentinel when destroying retval.
* semantics.cc (nrv_data): Add in_nrv_cleanup.
(finalize_nrv): Set it.
(finalize_nrv_r): Fix handling of throwing cleanups.

gcc/testsuite/ChangeLog:

* g++.dg/eh/return1.C: Add more cases.
---
 gcc/cp/except.cc  | 18 ++-
 gcc/cp/semantics.cc   | 47 +-
 gcc/testsuite/g++.dg/eh/return1.C | 81 ++-
 3 files changed, 142 insertions(+), 4 deletions(-)

diff --git a/gcc/cp/except.cc b/gcc/cp/except.cc
index e32efb30457..d966725db9b 100644
--- a/gcc/cp/except.cc
+++ b/gcc/cp/except.cc
@@ -1284,7 +1284,15 @@ build_noexcept_spec (tree expr, tsubst_flags_t complain)
current_retval_sentinel so that we know that the return value needs to be
destroyed on throw.  Do the same if the current function might use the
named return value optimization, so we don't destroy it on return.
-   Otherwise, returns NULL_TREE.  */
+   Otherwise, returns NULL_TREE.
+
+   The sentinel is set to indicate that we're in the process of returning, and
+   therefore should destroy a normal return value on throw, and shouldn't
+   destroy a named return value variable on normal scope exit.  It is set on
+   return, and cleared either by maybe_splice_retval_cleanup, or when an
+   exception reaches the NRV scope (finalize_nrv_r).  Note that once return
+   passes the NRV scope, it's effectively a normal return value, so cleanup
+   past that point is handled by maybe_splice_retval_cleanup. */
 
 tree
 maybe_set_retval_sentinel ()
@@ -1361,6 +1369,14 @@ maybe_splice_retval_cleanup (tree compound_stmt, bool 
is_try)
  tsi_delink ();
}
   tree dtor = build_cleanup (retval);
+  if (!function_body)
+   {
+ /* Clear the sentinel so we don't try to destroy the retval again on
+rethrow (c++/112301).  */
+ tree clear = build2 (MODIFY_EXPR, boolean_type_node,
+  current_retval_sentinel, boolean_false_node);
+ dtor = build2 (COMPOUND_EXPR, void_type_node, clear, dtor);
+   }
   tree cond = build3 (COND_EXPR, void_type_node, current_retval_sentinel,
  dtor, void_node);
   tree cleanup = build_stmt (loc, CLEANUP_STMT,
diff --git a/gcc/cp/semantics.cc b/gcc/cp/semantics.cc
index 52044be7af8..a0f2edcf117 100644
--- a/gcc/cp/semantics.cc
+++ b/gcc/cp/semantics.cc
@@ -4982,6 +4982,7 @@ public:
   tree result;
   hash_table > visited;
   bool simple;
+  bool in_nrv_cleanup;
 };
 
 /* Helper function for walk_tree, used by finalize_nrv below.  */
@@ -4997,7 +4998,7 @@ finalize_nrv_r (tree* tp, int* walk_subtrees, void* data)
   if (TYPE_P (*tp))
 *walk_subtrees = 0;
   /* If there's a label, we might need to destroy the NRV on goto (92407).  */
-  else if (TREE_CODE (*tp) == LABEL_EXPR)
+  else if (TREE_CODE (*tp) == LABEL_EXPR && !dp->in_nrv_cleanup)
 dp->simple = false;
   /* Change NRV returns to just refer to the RESULT_DECL; this is a nop,
  but differs from using NULL_TREE in that it indicates that we care
@@ -5016,16 +5017,59 @@ finalize_nrv_r (tree* tp, int* walk_subtrees, void* 
data)
   else if (TREE_CODE (*tp) == CLEANUP_STMT
   && CLEANUP_DECL (*tp) == dp->var)
 {
+  dp->in_nrv_cleanup = true;
+  cp_walk_tree (_BODY (*tp), finalize_nrv_r, data, 0);
+  dp->in_nrv_cleanup = false;
+  cp_walk_tree (_EXPR (*tp), finalize_nrv_r, data, 0);
+  *walk_subtrees = 0;
+
   if (dp->simple)
+   /* For a simple NRV, just run it on the EH path.  */
CLEANUP_EH_ONLY (*tp) = true;
   else
{
+ /* Not simple, we need to check current_retval_sentinel to decide
+whether to run it.  If it's set, we're returning normally and
+don't want to destroy the NRV.  If the sentinel is not set, we're
+leaving scope some other way, either by flowing off the end of its
+scope or throwing an exception.  */
  tree cond = build3 (COND_EXPR, void_type_node,
  

[PATCH] libstdc++: avoid uninitialized read in basic_string constructor

[Ben Sherman]

Tested on x86_64-pc-linux-gnu, please let me know if there's anything
else needed. I haven't contributed before and don't have write access, so
apologies if I've missed anything.

-- >8 --

The basic_string input iterator constructor incrementally reads data and
allocates the internal buffer as-needed. When _M_dispose() is called, there
is a check for whether the local buffer is being used - if it is, there is
an additional check guarding __builtin_unreachable() for the value of
_M_string_length. The constructor does not initialize _M_string_length
until all data has been read, so the first re-allocation out of the local
buffer will have an uninitialized read.

This updates the basic_string input iterator constructor to properly set
_M_string_length as data is being read.  It additionally introduces a new
_M_assign_terminator() function to assign the null-terminator based on the
currently-stored _M_string_length.

libstdc++-v3/ChangeLog:

* include/bits/basic_string.h (_M_assign_terminator()): New
  function.
  (_M_set_length()): Use _M_assign_terminator().
* include/bits/basic_string.tcc (_M_construct(InIter, InIter,
  input_iterator_tag)): Set length incrementally, use
  _M_assign_terminator().

diff --git a/libstdc++-v3/include/bits/basic_string.h 
b/libstdc++-v3/include/bits/basic_string.h
index 0fa32afeb..ba02d8f0f 100644
--- a/libstdc++-v3/include/bits/basic_string.h
+++ b/libstdc++-v3/include/bits/basic_string.h
@@ -258,12 +258,17 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
   _M_capacity(size_type __capacity)
   { _M_allocated_capacity = __capacity; }

+  _GLIBCXX20_CONSTEXPR
+  void
+  _M_assign_terminator()
+  { traits_type::assign(_M_data()[_M_string_length], _CharT()); }
+
   _GLIBCXX20_CONSTEXPR
   void
   _M_set_length(size_type __n)
   {
_M_length(__n);
-   traits_type::assign(_M_data()[__n], _CharT());
+   _M_assign_terminator();
   }

   _GLIBCXX20_CONSTEXPR
diff --git a/libstdc++-v3/include/bits/basic_string.tcc 
b/libstdc++-v3/include/bits/basic_string.tcc
index f0a44e5e8..84366a44a 100644
--- a/libstdc++-v3/include/bits/basic_string.tcc
+++ b/libstdc++-v3/include/bits/basic_string.tcc
@@ -182,6 +182,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
++__beg;
  }

+   _M_length(__len);
+
struct _Guard
{
  _GLIBCXX20_CONSTEXPR
@@ -206,12 +208,13 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
_M_capacity(__capacity);
  }
traits_type::assign(_M_data()[__len++], *__beg);
+   _M_length(__len);
++__beg;
  }

__guard._M_guarded = 0;

-   _M_set_length(__len);
+   _M_assign_terminator();
   }

   template
--
2.21.0







This electronic mail message and any attached files contain information 
intended for the exclusive use of the individual or entity to whom it is 
addressed and may contain information that is proprietary, confidential and/or 
exempt from disclosure under applicable law. If you are not the intended 
recipient, you are hereby notified that any viewing, copying, disclosure or 
distribution of this information may be subject to legal restriction or 
sanction. Please notify the sender, by electronic mail or telephone, of any 
unintended recipients and delete the original message without making any copies.

[Bug rtl-optimization/109035] meaningless memory store on RISC-V and LoongArch

[law at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #8 from Jeffrey A. Law  ---
No spills on rv64 either.

[Bug rtl-optimization/109035] meaningless memory store on RISC-V and LoongArch

[vmakarov at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #7 from Vladimir Makarov  ---
For last 2 weeks I pushed several patches for better dealing with equivalences
in RA.

It seems the patches solves the current PR.  I checked the test code generation
for loongarch and aarch64 and did not find spilled pseudos which are reported
here.

I think the PR should closed as fixed.

[Bug c++/112350] New: gcc is not triggering a dangling reference indicating stack use after return

[mohamed.selim at dxc dot com via Gcc-bugs]

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

Bug ID: 112350
   Summary: gcc is not triggering a dangling reference indicating
stack use after return
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mohamed.selim at dxc dot com
  Target Milestone: ---

Scenario A:
gcc is not triggering a dangling reference indicating stack use after return,
the address-sanitizer does trigger though.

"==1==ERROR: AddressSanitizer: stack-use-after-return on"

Scenario B:
gcc triggers a warning "-Wreturn-local-addr"

The sanitizers intervenes in both scenarios as expected, while gcc warnings in
not triggered in scenario A. Looks like the reference_wrapper has something to
do with it.


compiler options used:
-std=c++14 -Wframe-address -Wreturn-local-addr -Wall -Wextra -Wpedantic
-fsanitize=address


#include 
#include 


// scenario A
const int& foo()
{
int x = 234;
std::reference_wrapper s{x};

return s.get();
}

// scenario B
const int& foo()
{
int s = 234;   
return s;
}

int main()
{
const auto& f_res = foo();
std::cout << "result: " << f_res << "\n";

return 0;
}

[Bug libstdc++/112314] Missing index assertions in basic_string_view

[redi at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from Jonathan Wakely  ---
(In reply to Jose Dapena Paz from comment #2)
> In any case, the failing test is actually passing -1, my understanding is
> that that one should always assert no matter what we are passing as const
> char*.

Yes but I'm not going to add a check for -1 just to make some unit test pass.
In real code (size_t)-2 or (size_t)(-some other value) is at least as likely.

__glibcxx_assert(not in chromium tests) doesn't seem useful.

[PATCH] gfortran: Rely on dg-do-what-default to avoid running pr85853.f90, pr107254.f90 and vect-alias-check-1.F90 on non-vector targets

[Patrick O'Neill]

Testcases in gfortran.dg/vect/vect.exp rely on
check_vect_support_and_set_flags to set dg-do-what-default and avoid
running vector tests on non-vector targets. The three testcases in this
patch overwrite the default with dg-do run which causes issues
for non-vector targets.

Removing the dg-do run directive resolves this issue for non-vector
targets (while still running the tests on vector targets).

gcc/testsuite/ChangeLog:

* gfortran.dg/vect/pr107254.f90: Remove dg-do run directive.
* gfortran.dg/vect/pr85853.f90: Ditto.
* gfortran.dg/vect/vect-alias-check-1.F90: Ditto.

Signed-off-by: Patrick O'Neill 
---
Tested using rv64gc & rv64gcv to make sure the testcases compile/run
as expected.

These files haven't been changed in a long time so I'm not sure why (or
if) this hasn't been run into by other people before.
---
 gcc/testsuite/gfortran.dg/vect/pr107254.f90   | 2 --
 gcc/testsuite/gfortran.dg/vect/pr85853.f90| 1 -
 gcc/testsuite/gfortran.dg/vect/vect-alias-check-1.F90 | 1 -
 3 files changed, 4 deletions(-)

diff --git a/gcc/testsuite/gfortran.dg/vect/pr107254.f90 
b/gcc/testsuite/gfortran.dg/vect/pr107254.f90
index 85bcb5f3fa2..adce6bedc30 100644
--- a/gcc/testsuite/gfortran.dg/vect/pr107254.f90
+++ b/gcc/testsuite/gfortran.dg/vect/pr107254.f90
@@ -1,5 +1,3 @@
-! { dg-do run }
-
 subroutine dlartg( f, g, s, r )
   implicit none
   double precision :: f, g, r, s
diff --git a/gcc/testsuite/gfortran.dg/vect/pr85853.f90 
b/gcc/testsuite/gfortran.dg/vect/pr85853.f90
index 68f4a004324..4c0e3b81a09 100644
--- a/gcc/testsuite/gfortran.dg/vect/pr85853.f90
+++ b/gcc/testsuite/gfortran.dg/vect/pr85853.f90
@@ -1,5 +1,4 @@
 ! Taken from execute/where_2.f90, but with special flags.
-! { dg-do run }
 ! { dg-additional-options "-fno-tree-loop-vectorize" }
 
 ! Program to test the WHERE constructs
diff --git a/gcc/testsuite/gfortran.dg/vect/vect-alias-check-1.F90 
b/gcc/testsuite/gfortran.dg/vect/vect-alias-check-1.F90
index 3014ff9f3b6..85ae9b151e3 100644
--- a/gcc/testsuite/gfortran.dg/vect/vect-alias-check-1.F90
+++ b/gcc/testsuite/gfortran.dg/vect/vect-alias-check-1.F90
@@ -1,4 +1,3 @@
-! { dg-do run }
 ! { dg-additional-options "-fno-inline" }
 
 #define N 200
-- 
2.34.1

[Bug c++/106849] internal compiler error: tree check: expected none of template_decl, have template_decl in do_nonmember_using_decl, at cp/name-lookup.cc:4841

[davidfromonline at gmail dot com via Gcc-bugs]

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

--- Comment #3 from David Stone  ---
Oh, as per https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112355#c3 it's just
that the 13.2 build isn't checked, so it's not a new bug.

[Bug c++/106849] internal compiler error: tree check: expected none of template_decl, have template_decl in do_nonmember_using_decl, at cp/name-lookup.cc:4841

[davidfromonline at gmail dot com via Gcc-bugs]

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

--- Comment #2 from David Stone  ---
Looks like it works in 13.2 but fails in trunk.

13.2: https://godbolt.org/z/d54ToW7zW
trunk: https://godbolt.org/z/eej9d7ccM

[Bug c++/112355] Internal compiler error when exporting using declaration of function template

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from Andrew Pinski  ---
(In reply to David Stone from comment #1)
> Looks like this is a new bug in trunk. Works in 13.2

It is not, just extra checking is enabled by default when compiling the trunk
(unless you use the configure option --enable-checking=release).

[Bug c++/103524] [meta-bug] modules issue

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524
Bug 103524 depends on bug 112355, which changed state.

Bug 112355 Summary: Internal compiler error when exporting using declaration of 
function template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112355

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

[Bug c++/112355] Internal compiler error when exporting using declaration of function template

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Andrew Pinski  ---
Almost an exact dup of bug 106849.

*** This bug has been marked as a duplicate of bug 106849 ***

[Bug c++/106849] internal compiler error: tree check: expected none of template_decl, have template_decl in do_nonmember_using_decl, at cp/name-lookup.cc:4841

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||davidfromonline at gmail dot 
com

--- Comment #1 from Andrew Pinski  ---
*** Bug 112355 has been marked as a duplicate of this bug. ***

[Bug c++/112355] Internal compiler error when exporting using declaration of function template

[davidfromonline at gmail dot com via Gcc-bugs]

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

David Stone  changed:

   What|Removed |Added

 CC||davidfromonline at gmail dot 
com

--- Comment #1 from David Stone  ---
Looks like this is a new bug in trunk. Works in 13.2

[Bug c++/112355] New: Internal compiler error when exporting using declaration of function template

[davidfromonline at gmail dot com via Gcc-bugs]

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

Bug ID: 112355
   Summary: Internal compiler error when exporting using
declaration of function template
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: davidfromonline at gmail dot com
  Target Milestone: ---

The following mostly valid code:

```cxx
module;

namespace n {

template
void f() {
}

}

export module m;

export using n::f;
```

causes gcc to crash with

```console
:3:1: error: global module fragment contents must be from preprocessor
inclusion
3 | namespace n {
  | ^
:13:17: internal compiler error: tree check: expected none of
template_decl, have template_decl in do_nonmember_using_decl, at
cp/name-lookup.cc:4853
   13 | export using n::f;
  | ^
0x8fbb6e tree_not_check_failed(tree_node const*, char const*, int, char const*,
...)
gcc/source/gcc/tree.cc:8986
0x76f1d4 tree_not_check(tree_node*, char const*, int, char const*, tree_code)
gcc/source/gcc/tree.h:3607
0x76f1d4 do_nonmember_using_decl
gcc/source/gcc/cp/name-lookup.cc:4853
0xb63549 finish_nonmember_using_decl(tree_node*, tree_node*)
gcc/source/gcc/cp/name-lookup.cc:6297
0xb6d974 finish_using_decl
gcc/source/gcc/cp/parser.cc:21908
0xbb482f cp_parser_using_declaration
gcc/source/gcc/cp/parser.cc:22072
0xbc8653 cp_parser_declaration
gcc/source/gcc/cp/parser.cc:15335
0xbc85d4 cp_parser_module_export
gcc/source/gcc/cp/parser.cc:15080
0xbc85d4 cp_parser_declaration
gcc/source/gcc/cp/parser.cc:15276
0xbc908a cp_parser_toplevel_declaration
gcc/source/gcc/cp/parser.cc:15356
0xbc908a cp_parser_translation_unit
gcc/source/gcc/cp/parser.cc:5218
0xbc908a c_parse_file()
gcc/source/gcc/cp/parser.cc:50627
0xd0f8e1 c_common_parse_file()
gcc/source/gcc/c-family/c-opts.cc:1278
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.
Compiler returned: 1
```

See it live: http://desktop:10240/z/nj5q1b

(the crash still exists if the global module fragment comes from an #include, I
just made it this way to have a single-file reproduction)

[Bug tree-optimization/102138] t = a==0 and a = PHI<0, t> should be done earlier than PRE

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from Andrew Pinski  ---
This is the generic solution to what was done to fix PR 104639.

Re: [PATCH 4/4] maintainer-scripts/gcc_release: cleanup whitespace

[Joseph Myers]

On Thu, 2 Nov 2023, Sam James wrote:

> maintainer-scripts/
>   * gcc_release: Cleanup whitespace.

OK.

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

Re: [PATCH 3/4] maintainer-scripts/gcc_release: use HTTPS for links

[Joseph Myers]

On Thu, 2 Nov 2023, Sam James wrote:

> maintainer-scripts/
>   * gcc_release: Use HTTPS for links.

OK.

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

[Bug c/112347] [14 regression] ICE on jemalloc-5.3.0: Segmentation fault around convert_for_assignment()

[muecker at gwdg dot de via Gcc-bugs]

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

--- Comment #11 from Martin Uecker  ---

In this case this is by design because the size of an element should be second
argument to calloc. ("The calloc function allocates space for an array of nmemb
objects, each of whose size is size.")

[Bug tree-optimization/102138] t = a==0 and a = PHI<0, t> should be done earlier than PRE

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org
 Status|NEW |ASSIGNED

--- Comment #3 from Andrew Pinski  ---
mine.

[Bug c/112347] [14 regression] ICE on jemalloc-5.3.0: Segmentation fault around convert_for_assignment()

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #10 from David Binderman  ---
When this patch was tested, did that include a build of libgfortran ?

I am getting some strange new warnings:

../../../trunk.year/libgfortran/io/async.c:265:24: warning: allocation of
insufficient size ‘1’ for type ‘transfer_queue’ with size ‘80’ [-Walloc-size]
../../../trunk.year/libgfortran/io/async.c:287:24: warning: allocation of
insufficient size ‘1’ for type ‘transfer_queue’ with size ‘80’ [-Walloc-size]
../../../trunk.year/libgfortran/io/async.c:311:24: warning: allocation of
insufficient size ‘1’ for type ‘transfer_queue’ with size ‘80’ [-Walloc-size]
../../../trunk.year/libgfortran/io/async.c:331:24: warning: allocation of
insufficient size ‘1’ for type ‘transfer_queue’ with size ‘80’ [-Walloc-size]

The code looks legal to me. Here is the first one:

  transfer_queue *tq = calloc (sizeof (transfer_queue), 1);

[Bug c++/112335] missed optimization on reset and assign unique_ptr

[redi at gcc dot gnu.org via Gcc-bugs]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|UNCONFIRMED |RESOLVED

--- Comment #6 from Jonathan Wakely  ---
(In reply to Federico Kircheis from comment #5)
> I do not think that the case you have in mind is supported by the standard,

It is. The standard is very clear about exactly which operations happen, and in
which order. Code can rely on that behaviour, because it's guaranteed by the
standard. Implementations are not allowed to deviate from that.

In your 'bar1' function when the ~s destructor runs it is guaranteed that it
will observe ps1.get() == nullptr, because that's the first thing that
ps1.reset() does.

In your 'bar2' function when the ~s destructor runs it's guaranteed that it
will observe ps1.get() == the original value of ps2, because that value gets
set before invoking the deleter.

Demo: https://godbolt.org/z/PWd96j4fz

That is clearly an observable difference, which is required by the standard,
and so your bar1 and bar2 are clearly not equivalent.

But a much simpler example where the difference is observable is when the two
arguments to bar1 and bar2 are the same object:
https://godbolt.org/z/z8fsTan8K
For bar1 you destroy any pointed-to object, then move-assign an empty pointer
to itself, which does nothing. So bar1(p, p,) is equivalent to p.reset();
For bar2 you release the pointer, then reset it back again. So bar2(p, p) is a
no-op.

The functions are not clearly equivalent.

> but the postcondition does not hold with some deleters, so not sure if that
> could be relevant here

I'm not sure what you mean here. The postcondition holds unless the deleter
*also* destroys the unique_ptr itself.

[Bug target/111311] RISC-V regression testsuite errors with --param=riscv-autovec-preference=scalable

[rdapp at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #10 from Robin Dapp  ---
As a general remark:  Some of those are present on other backends as well, some
have been introduced by recent common-code changes and some are bogus test
prerequisites or checks.  I'm not saying we are in perfect shape but we have
several months to deal with most of those - if there is a high-severity bug we
can of course still do common code changes if necessary, although the bar will
be higher.

FYI 5ish of the mentioned bugs will be gone with the slp-reduc-7.c fix but it
will introduce another backend missed optimization - at first this might appear
worse (just by numbers) but it actually isn't.  Once stage 1 is over I'm going
to focus on the Fortran tests as well as the signbit execution tests (in case
they are still there at that time).

[Bug target/112337] arm: ICE in arm_effective_regno when compiling for MVE

[stammark at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from Stam Markianos-Wright  ---
Bisected to f55cdce3f8dd8503e080e35be59c5f5390f6d95e

Attached preprocessed source and a creduced-reproducer of it

Re: [PATCH] Format gotools.sum closer to what DejaGnu does

[rep . dot . nop]

On 2 November 2023 18:06:54 CET, Maxim Kuvyrkov  
wrote:
>> On Nov 2, 2023, at 21:02, rep.dot@gmail.com wrote:
>> 
>> Hi Maxim!
>> 
>> Many thanks for the patch! Quick question below..
>> 
>> On 2 November 2023 13:48:55 CET, Maxim Kuvyrkov  
>> wrote:
>>> ... to restore compatability with validate_failures.py .
>>> The testsuite script validate_failures.py expects
>>> "Running  ..." to extract  values,
>>> and gotools.sum provided "Running ".
>>> 
>>> Note that libgo.sum, which also uses Makefile logic to generate
>>> DejaGnu-like output, already has "..." suffix.
>>> 
>>> gotools/ChangeLog:
>>> 
>>> * Makefile.am: Update "Running  ..." output
>>> * Makefile.in: Regenerate.
>>> ---
>>> gotools/Makefile.am | 4 ++--
>>> gotools/Makefile.in | 5 +++--
>>> 2 files changed, 5 insertions(+), 4 deletions(-)
>>> 
>>> diff --git a/gotools/Makefile.am b/gotools/Makefile.am
>>> index 7b5302990f8..d2376b9c25b 100644
>>> --- a/gotools/Makefile.am
>>> +++ b/gotools/Makefile.am
>>> @@ -332,8 +332,8 @@ check: check-head check-go-tool check-runtime 
>>> check-cgo-test check-carchive-test
>>> @cp gotools.sum gotools.log
>>> @for file in cmd_go-testlog runtime-testlog cgo-testlog carchive-testlog 
>>> cmd_vet-testlog embed-testlog; do \
>>>   testname=`echo $${file} | sed -e 's/-testlog//' -e 's|_|/|'`; \
>>> -   echo "Running $${testname}" >> gotools.sum; \
>>> -   echo "Running $${testname}" >> gotools.log; \
>>> +   echo "Running $${testname} ..." >> gotools.sum; \
>>> +   echo "Running $${testname} ..." >> gotools.log; \
>>>   sed -e 's/^--- \(.*\) ([^)]*)$$/\1/' < $${file} >> gotools.log; \
>>>   grep '^--- ' $${file} | sed -e 's/^--- \(.*\) ([^)]*)$$/\1/' -e 
>>> 's/SKIP/UNTESTED/' | sort -k 2 >> gotools.sum; \
>>> done
>>> diff --git a/gotools/Makefile.in b/gotools/Makefile.in
>>> index 2783b91ef4b..9cc238e748d 100644
>>> --- a/gotools/Makefile.in
>>> +++ b/gotools/Makefile.in
>>> @@ -317,6 +317,7 @@ pdfdir = @pdfdir@
>>> prefix = @prefix@
>>> program_transform_name = @program_transform_name@
>>> psdir = @psdir@
>>> +runstatedir = @runstatedir@
>> 
>> Are you sure you used the correct version of automake?
>
>I used automake 1.15.1 (from Ubuntu 20.04 automake-1.15 package), and I 
>double-checked after getting the runstatedir update.

I think that runstatedir is a Debian (and derivatives) addition, would probably 
suffice to just drop that line manually..

The patch itself looks like it would be ok, probably even obvious, but I can 
not approve it.

I'm a bit surprised that you don't need to have "exp" != None for 
validate-failures to work after your exp addition, but I take it you checked 
that aspect :-)

thanks, again!

>
>I would appreciate someone checking on their side to make sure I don't have 
>something weird going on in my setup.
>
>--
>Maxim Kuvyrkov
>https://www.linaro.org
>

[Bug tree-optimization/112096] `(a || b) ? a : b` should be simplified to a

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from Andrew Pinski  ---
Another testcase:
```
int f(int a, int b, int d)
{
bool t = a == 0;
bool t1 = d == 0;
int c = a + b;
if (t & t1) return b;
return c;
}

int f1(int a, int b, int d)
{
bool t = a == 0;
bool t1 = d == 43;
int c = a + b;
if (t & t1) return b;
return c;
}
```

I have a patch which handles this one. I have to check on the != cases next.

[Bug libstdc++/112314] Missing index assertions in basic_string_view

[redi at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #7 from Jonathan Wakely  ---
(In reply to Jose Dapena Paz from comment #5)
> - The length is less than the possible pointer difference (checked with
> numeric_limits).

That seems too lenient to me, because for wchar_t, char16_t and char32_t the
maximum length that can actually exist in the program will be less than
PTRDIFF_MAX.

Our std::vector::max_size() uses this:

// std::distance(begin(), end()) cannot be greater than PTRDIFF_MAX,
// and realistically we can't store more than PTRDIFF_MAX/sizeof(T)
// (even if std::allocator_traits::max_size says we can).
const size_t __diffmax
  = __gnu_cxx::__numeric_traits::__max / sizeof(_Tp);

[Bug sanitizer/112353] New: asan-enabled, aarch64-gcc cross-compiled elf executables fail ro run in qemu-user on x86

[robert at bedrocksystems dot com via Gcc-bugs]

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

Bug ID: 112353
   Summary: asan-enabled, aarch64-gcc cross-compiled elf
executables fail ro run in qemu-user on x86
   Product: gcc
   Version: 12.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: robert at bedrocksystems dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

On Ubuntu 23.04 x86_64, an aarch64 cross-compiled elf executable with Address
Sanitizer (asan) enabled, fails with the run-time error:
```
AddressSanitizer: CHECK failed: asan_poisoning.cpp:38 "((AddrIsInMem(addr))) !=
(0)" (0x0, 0x0) (tid=1909)

```

This might be related to qemu and not gcc, but it reproduced also with gcc
13.2.0, but not with gcc 11.4.0.

Versions used:

```
$ aarch64-linux-gnu-g++ --version
aarch64-linux-gnu-g++ (Ubuntu 12.3.0-1ubuntu1~23.04) 12.3.0

$ qemu-aarch64-static -version
qemu-aarch64 version 7.2.0 (Debian 1:7.2+dfsg-5ubuntu2.3)
```

Steps to reproduce:
```
$ echo "int main() {return 1;}" > /tmp/poc.cpp
$ aarch64-linux-gnu-g++ -fsanitize=address /tmp/poc.cpp -o /tmp/poc 
$ qemu-aarch64-static /tmp/poc ## this takes a while
AddressSanitizer: CHECK failed: asan_poisoning.cpp:38 "((AddrIsInMem(addr))) !=
(0)" (0x0, 0x0) (tid=2220)

```

[Bug c++/112354] mismatched types 'B' and 'B&' for generic lambda noexcept-specifier referencing enclosing function parameter

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-11-02
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
Confirmed.

[Bug tree-optimization/110116] [12/13 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: verify_gimple failed

[tkoenig at gcc dot gnu.org via Gcc-bugs]

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

Thomas Koenig  changed:

   What|Removed |Added

Summary|[12/13/14 Regression] ICE   |[12/13 Regression] ICE on
   |on valid code at -O3 on |valid code at -O3 on
   |x86_64-linux-gnu:   |x86_64-linux-gnu:
   |verify_gimple failed|verify_gimple failed
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=111614
  Known to work||14.0

--- Comment #3 from Thomas Koenig  ---
r14-4303-g88d79b9b03eccf fixed it:

88d79b9b03eccf39921d13c2cbd1acc50aeda126 is the first fixed commit
commit 88d79b9b03eccf39921d13c2cbd1acc50aeda126
Author: Richard Biener 
Date:   Thu Sep 28 09:41:30 2023 +0200

tree-optimization/111614 - missing convert in
undistribute_bitref_for_vector

The following adjusts a flawed guard for converting the first vector
of the sum we create in undistribute_bitref_for_vector.

PR tree-optimization/111614
* tree-ssa-reassoc.cc (undistribute_bitref_for_vector): Properly
convert the first vector when required.

* gcc.dg/torture/pr111614.c: New testcase.

 gcc/testsuite/gcc.dg/torture/pr111614.c | 23 +++
 gcc/tree-ssa-reassoc.cc | 27 +++
 2 files changed, 38 insertions(+), 12 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/torture/pr111614.c

Maybe a candidate for backporting?  Unlike PR111614, this does not appear
to be latent.

[Bug target/111311] RISC-V regression testsuite errors with --param=riscv-autovec-preference=scalable

[patrick at rivosinc dot com via Gcc-bugs]

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

--- Comment #8 from Patrick O'Neill  ---
Updated regression list using r14-5070-g4ea36076d66 on rv64gcv:

=== gcc: Unexpected fails for rv64gcv lp64d medlow ===
FAIL: gcc.c-torture/execute/memset-3.c   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
FAIL: gcc.c-torture/execute/memset-3.c   -O3 -g  execution test
FAIL: c-c++-common/spec-barrier-1.c  -Wc++-compat  (test for excess errors)
FAIL: c-c++-common/vector-subscript-4.c  -Wc++-compat scan-tree-dump-not
optimized "vector"
XPASS: gcc.dg/attr-alloc_size-11.c missing range info for short (test for
warnings, line 51)
XPASS: gcc.dg/attr-alloc_size-11.c missing range info for signed char (test for
warnings, line 50)
FAIL: gcc.dg/signbit-2.c scan-tree-dump optimized "\\s+>\\s+{ 0(, 0)+ }"
FAIL: gcc.dg/signbit-2.c scan-tree-dump-not optimized "\\s+>>\\s+31"
FAIL: gcc.dg/signbit-5.c execution test
XPASS: gcc.dg/uninit-pred-9_b.c bogus warning (test for bogus messages, line
20)
FAIL: gcc.dg/unroll-8.c scan-rtl-dump loop2_unroll "Not unrolling loop, doesn't
roll"
FAIL: gcc.dg/unroll-8.c scan-rtl-dump loop2_unroll "likely upper bound: 6"
FAIL: gcc.dg/unroll-8.c scan-rtl-dump loop2_unroll "realistic bound: -1"
FAIL: gcc.dg/var-expand1.c scan-rtl-dump loop2_unroll "Expanding Accumulator"
FAIL: gcc.dg/tree-prof/val-prof-1.c scan-tree-dump optimized "if \\(n_[0-9]* !=
257\\)"
FAIL: gcc.dg/tree-prof/val-prof-3.c scan-tree-dump optimized "if \\(_[0-9]* \\<
n_[0-9]*"
FAIL: gcc.dg/tree-prof/val-prof-4.c scan-tree-dump optimized "if \\(n_[0-9]*
\\>"
FAIL: gcc.dg/tree-ssa/copy-headers-8.c scan-tree-dump-times ch2 "Conditional
combines static and invariant" 1
FAIL: gcc.dg/tree-ssa/copy-headers-8.c scan-tree-dump-times ch2 "Will duplicate
bb" 2
FAIL: gcc.dg/tree-ssa/cunroll-16.c scan-tree-dump cunroll "optimized: loop with
[0-9]+ iterations completely unrolled"
FAIL: gcc.dg/tree-ssa/cunroll-16.c scan-tree-dump-not optimized "foo"
FAIL: gcc.dg/tree-ssa/gen-vect-11b.c scan-tree-dump-times vect "vectorized 0
loops" 1
FAIL: gcc.dg/tree-ssa/gen-vect-11c.c scan-tree-dump-times vect "vectorized 0
loops" 1
FAIL: gcc.dg/tree-ssa/gen-vect-26.c scan-tree-dump-times vect "Alignment of
access forced using peeling" 1
FAIL: gcc.dg/tree-ssa/gen-vect-28.c scan-tree-dump-times vect "Alignment of
access forced using peeling" 1
FAIL: gcc.dg/tree-ssa/gen-vect-34.c scan-tree-dump-times vect "vectorized 1
loops" 1
FAIL: gcc.dg/tree-ssa/loop-bound-1.c scan-tree-dump ivopts "bounded by 254"
FAIL: gcc.dg/tree-ssa/loop-bound-2.c scan-tree-dump ivopts "bounded by 254"
XPASS: gcc.dg/tree-ssa/pr84512.c scan-tree-dump optimized "return 285;"
FAIL: gcc.dg/tree-ssa/predcom-4.c scan-tree-dump-times pcom "Combination" 1
FAIL: gcc.dg/tree-ssa/predcom-4.c scan-tree-dump-times pcom "Unrolling 3
times." 1
FAIL: gcc.dg/tree-ssa/predcom-5.c scan-tree-dump-times pcom "Combination" 2
FAIL: gcc.dg/tree-ssa/predcom-5.c scan-tree-dump-times pcom "Unrolling 3
times." 1
FAIL: gcc.dg/tree-ssa/predcom-9.c scan-tree-dump pcom "Executing predictive
commoning without unrolling"
FAIL: gcc.dg/tree-ssa/reassoc-46.c scan-tree-dump-times optimized
"(?:vect_)?sum_[\\d._]+ = (?:(?:vect_)?_[\\d._]+ \\+
(?:vect_)?sum_[\\d._]+|(?:vect_)?sum_[\\d._]+ \\+ (?:vect_)?_[\\d._]+)" 1
FAIL: gcc.dg/tree-ssa/scev-10.c scan-tree-dump-times ivopts " Type:\\tREFERENCE
ADDRESS\n" 1
FAIL: gcc.dg/tree-ssa/scev-11.c scan-tree-dump-times ivopts " Type:\\tREFERENCE
ADDRESS\n" 2
FAIL: gcc.dg/tree-ssa/scev-14.c scan-tree-dump ivopts "Overflowness wrto loop
niter:\tNo-overflow"
FAIL: gcc.dg/tree-ssa/scev-9.c scan-tree-dump-times ivopts " Type:\\tREFERENCE
ADDRESS\n" 1
FAIL: gcc.dg/tree-ssa/split-path-11.c scan-tree-dump-times split-paths "join
point for if-convertable half-diamond" 1
XPASS: gcc.dg/tree-ssa/ssa-fre-3.c scan-tree-dump fre1 "Replaced \\(int\\)
aa_.*with a_"
FAIL: gcc.dg/tree-ssa/update-threading.c scan-tree-dump-times optimized
"Invalid sum" 0
FAIL: gcc.dg/vect/bb-slp-33.c -flto -ffat-lto-objects scan-tree-dump-times slp2
"vectorizing stmts using SLP" 2
FAIL: gcc.dg/vect/bb-slp-33.c scan-tree-dump-times slp2 "vectorizing stmts
using SLP" 2
FAIL: gcc.dg/vect/bb-slp-39.c -flto -ffat-lto-objects scan-tree-dump-times slp2
"vectorizing stmts using SLP" 3
FAIL: gcc.dg/vect/bb-slp-39.c scan-tree-dump-times slp2 "vectorizing stmts
using SLP" 3
XPASS: gcc.dg/vect/bb-slp-43.c -flto -ffat-lto-objects scan-tree-dump-not slp2
"vector operands from scalars"
XPASS: gcc.dg/vect/bb-slp-43.c scan-tree-dump-not slp2 "vector operands from
scalars"
FAIL: gcc.dg/vect/bb-slp-cond-1.c -flto -ffat-lto-objects scan-tree-dump-times
vect "loop vectorized" 1
FAIL: gcc.dg/vect/bb-slp-cond-1.c scan-tree-dump-times vect "loop vectorized" 1
FAIL: gcc.dg/vect/bb-slp-over-widen-1.c -flto -ffat-lto-objects
scan-tree-dump-times slp2 "optimized: basic block" 2
FAIL: gcc.dg/vect/bb-slp-over-widen-1.c scan-tree-dump-times slp2 "optimized:
basic block" 2
FAIL: 

[Bug sanitizer/112353] asan-enabled, aarch64-gcc cross-compiled elf executables fail ro run in qemu-user on x86

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from Andrew Pinski  ---
https://github.com/google/sanitizers/issues/1470

[Bug c++/112354] New: mismatched types 'B' and 'B&' for generic lambda noexcept-specifier referencing enclosing function parameter

[ed at catmur dot uk via Gcc-bugs]

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

Bug ID: 112354
   Summary: mismatched types 'B' and 'B&' for generic
lambda noexcept-specifier referencing enclosing
function parameter
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ed at catmur dot uk
  Target Milestone: ---

Since 4.9.0,

template
struct B {
B();
B(B const&);
};
template void g(B, int);
auto f(B x) {
return [](auto y) noexcept(noexcept(g(x, y))) {
return 1;
};
}
int i = f({})(0);

fails with:

: In instantiation of 'f(B):: [with auto:1 =
int]':
:12:14:   required from here
   12 | int i = f({})(0);
  | ~^~~
:8:42: error: no matching function for call to 'g(B&&, int&)'
8 | return [](auto y) noexcept(noexcept(g(x, y))) {
  | ~^~
:6:24: note: candidate: 'template void g(B, int)'
6 | template void g(B, int);
  |^
:6:24: note:   template argument deduction/substitution failed:
:8:42: note:   mismatched types 'B' and 'B&'
8 | return [](auto y) noexcept(noexcept(g(x, y))) {
  | ~^~

[Bug libstdc++/112349] ranges::max makes unnecessary copies

[redi at gcc dot gnu.org via Gcc-bugs]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2023-11-02
 Status|UNCONFIRMED |NEW

--- Comment #1 from Jonathan Wakely  ---
(In reply to Ted Lyngmo from comment #0)
> auto& __tmp = *__first;

That won't compile for a move_iterator or a proxy reference. I think auto&&
would be OK.

But we'd need to restore the value category:

auto __result = *__first;
while (++__first != __last)
  {
auto&& __tmp = *__first;
if (std::__invoke(__comp,
  std::__invoke(__proj, __result),
  std::__invoke(__proj, __tmp)))
  __result = std::forward(__tmp);
  }
return __result;

> ...or just supplying `*__first` to `std::__invoke` it doesn't do copies in
> OP's example but it may have other consequences. Worth looking in to anyway.

I think that would be OK too.

auto __result = *__first;
while (++__first != __last)
  {
if (std::__invoke(__comp,
  std::__invoke(__proj, __result),
  std::__invoke(__proj, *__first)))
  __result = *__first;
  }
return __result;

[Bug c++/112350] gcc is not triggering a dangling reference indicating stack use after return

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from Andrew Pinski  ---
With optimization enabled and without -fsanitize=address  we get:

: In function 'const int& foo1()':
:12:18: warning: using a dangling pointer to 'x' [-Wdangling-pointer=]
   12 | return s.get();
  |  ^
:9:9: note: 'x' declared here
9 | int x = 234;
  | ^

Re: [Patch, fortran] PR98498 - Interp request: defined operators and unlimited polymorphic

[Paul Richard Thomas]

Hi Harald,

I was overthinking the problem. The rejected cases led me to a fix that can
only be described as a considerable simplification compared with the first
patch!

The testcase now reflects the requirements of the standard and
regtests without failures.

OK for mainline?

Thanks

Paul

Fortran: Defined operators with unlimited polymorphic args [PR98498]

2023-11-02  Paul Thomas  

gcc/fortran
PR fortran/98498
* interface.cc (upoly_ok): Defined operators using unlimited
polymorphic formal arguments must not override the intrinsic
operator use.

gcc/testsuite/
PR fortran/98498
* gfortran.dg/interface_50.f90: New test.


On Wed, 1 Nov 2023 at 20:12, Harald Anlauf  wrote:

> Hi Paul,
>
> Am 01.11.23 um 19:02 schrieb Paul Richard Thomas:
> > The interpretation request came in a long time ago but I only just got
> > around to implementing it.
> >
> > The updated text from the standard is in the comment. Now I am writing
> > this, I think that I should perhaps use switch(op)/case rather than using
> > if/else if and depending on the order of the gfc_intrinsic_op enum being
> > maintained. Thoughts?
>
> the logic is likely harder to parse with if/else than with
> switch(op)/case.  However, I do not think that the order of
> the enum will ever be changed, as the module format relies
> on that very order.
>
> > The testcase runs fine with both mainline and nagfor. I think that
> > compile-only with counts of star-eq and star_not should suffice.
>
> I found other cases that are rejected even with your patch,
> but which are accepted by nagfor.  Example:
>
> print *, ('a' == c)
>
> Nagfor prints F at runtime as expected, as it correctly resolves
> this to star_eq.  Further examples can be easily constructed.
>
> Can you have a look?
>
> Thanks,
> Harald
>
> > Regtests with no regressions. OK for mainline?
> >
> > Paul
> >
> > Fortran: Defined operators with unlimited polymorphic args [PR98498]
> >
> > 2023-11-01  Paul Thomas  
> >
> > gcc/fortran
> > PR fortran/98498
> > * interface.cc (upoly_ok): New function.
> > (gfc_extend_expr): Use new function to ensure that defined
> > operators using unlimited polymorphic formal arguments do not
> > override their intrinsic uses.
> >
> > gcc/testsuite/
> > PR fortran/98498
> > * gfortran.dg/interface_50.f90: New test.
> >
>
>
diff --git a/gcc/fortran/interface.cc b/gcc/fortran/interface.cc
index 8c4571e0aa6..fc4fe662eab 100644
--- a/gcc/fortran/interface.cc
+++ b/gcc/fortran/interface.cc
@@ -4737,6 +4737,17 @@ gfc_extend_expr (gfc_expr *e)
 	  if (sym != NULL)
 	break;
 	}
+
+  /* F2018(15.4.3.4.2) requires that the use of unlimited polymorphic
+	 formal arguments does not override the intrinsic uses.  */
+  gfc_push_suppress_errors ();
+  if (sym
+	  && (UNLIMITED_POLY (sym->formal->sym)
+	  || (sym->formal->next
+		  && UNLIMITED_POLY (sym->formal->next->sym)))
+	  && !gfc_check_operator_interface (sym, e->value.op.op, e->where))
+	sym = NULL;
+  gfc_pop_suppress_errors ();
 }
 
   /* TODO: Do an ambiguity-check and error if multiple matching interfaces are
! { dg-do compile }
! { dg-options "-fdump-tree-original" }
!
! Tests the fix for PR98498, which was subject to an interpretation request
! as to whether or not the interface operator overrode the intrinsic use.
! (See PR for correspondence)
!
! Contributed by Paul Thomas  
!
MODULE mytypes
  IMPLICIT none

  TYPE pvar
 character(len=20) :: name
 integer   :: level
  end TYPE pvar

  interface operator (==)
 module procedure star_eq
  end interface

  interface operator (.not.)
 module procedure star_not
  end interface

contains
  function star_eq(a, b)
implicit none
class(*), intent(in) :: a, b
logical :: star_eq
select type (a)
  type is (pvar)
  select type (b)
type is (pvar)
  if((a%level .eq. b%level) .and. (a%name .eq. b%name)) then
star_eq = .true.
  else
star_eq = .false.
  end if
type is (integer)
  star_eq = (a%level == b)
  end select
  class default
star_eq = .false.
end select
  end function star_eq

  function star_not (a)
implicit none
class(*), intent(in) :: a
type(pvar) :: star_not
select type (a)
  type is (pvar)
star_not = a
star_not%level = -star_not%level
  type is (real)
star_not = pvar ("real", -int(a))
  class default
star_not = pvar ("noname", 0)
end select
  end function

end MODULE mytypes

program test_eq
   use mytypes
   implicit none

   type(pvar) x, y
   integer :: i = 4
   real :: r = 2.0
   character(len = 4, kind =4) :: c = "abcd"
! Check that intrinsic use of .not. and == is not overridden.
   if (.not.(i == 2*int (r))) stop 1
   if (r == 1.0) stop 2

! Test defined operator ==
   x = pvar('test 1', 100)
   y = pvar('test 1', 100)
   if (.not.(x == y)) stop 3
   y = pvar('test 2', 100)
   if (x == y) stop 4
   if (x == r) stop 5! 

[Bug libstdc++/112314] Missing index assertions in basic_string_view

[redi at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #6 from Jonathan Wakely  ---
Created attachment 56494
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56494=edit
Check [ptr,end) and [ptr,ptr+n) ranges with _GLIBCXX_ASSERTIONS

With this change we could add:

__glibcxx_requires_string_len(__str, __len);

to the string_view constructor.

We could include checks for __len == 0 || __str != nullptr and PTRDIFF_MAX too.

Re: [PATCH] Format gotools.sum closer to what DejaGnu does

[Rainer Orth]

rep.dot@gmail.com writes:

> On 2 November 2023 18:06:54 CET, Maxim Kuvyrkov 
> wrote:
>>> On Nov 2, 2023, at 21:02, rep.dot@gmail.com wrote:
>>> 
>>> Hi Maxim!
>>> 
>>> Many thanks for the patch! Quick question below..
>>> 
>>> On 2 November 2023 13:48:55 CET, Maxim Kuvyrkov
>>>  wrote:
[...]
>>> Are you sure you used the correct version of automake?
>>
>>I used automake 1.15.1 (from Ubuntu 20.04 automake-1.15 package), and I
>> double-checked after getting the runstatedir update.
>
> I think that runstatedir is a Debian (and derivatives) addition, would
> probably suffice to just drop that line manually..

One needs to use the exact version of the autotools as documented on
https://gcc.gnu.org/install/prerequisites.html.  Since distros often
apply local patches, it's best to use a self-built version to guard
against those.  Manually dropping parts of the regenerated files is
heavily fraught with error, especially since you usually don't know what
to drop.

Rainer

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

[Bug fortran/112316] [13 Regression] Fix for PR87477 rejects valid code with a bogus error about pointer assignment and causes an ICE since r13-7761-gd6997a5aab7aaa325946a6283bfee8ac2bd9f540

[pault at gcc dot gnu.org via Gcc-bugs]

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

Paul Thomas  changed:

   What|Removed |Added

   Last reconfirmed||2023-11-02
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from Paul Thomas  ---
I can confirm this bug, of course. Thanks for the report.

I temporary work around is to invert the order of the contained procedures.

The problem is caused by a stupid (on my part :-( ) oversight:
diff --git a/gcc/fortran/parse.cc b/gcc/fortran/parse.cc
index e103ebee557..f88f9be3be8 100644
--- a/gcc/fortran/parse.cc
+++ b/gcc/fortran/parse.cc
@@ -5196,7 +5196,7 @@ parse_associate (void)
}
}

-  if (target->rank)
+  if (1)
{
  int rank = 0;
  rank = target->rank;

fixes the problem and regtests OK.

The simplification that I effected with the offending patch has been completely
spoiled by forgetting that one of the cases that was supposed to be fixed in
the block following the condition above is that of target->rank = 0 and the
associate variable having an array_spec.

I will commit a cleaned up version as obvious first thing tomorrow morning.

Sorry for the inconvenience.

Paul

[Bug libstdc++/112314] Missing index assertions in basic_string_view

[jdapena at igalia dot com via Gcc-bugs]

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

--- Comment #5 from Jose Dapena Paz  ---
(In reply to Jonathan Wakely from comment #4)
> (In reply to Jose Dapena Paz from comment #2)
> > In any case, the failing test is actually passing -1, my understanding is
> > that that one should always assert no matter what we are passing as const
> > char*.
> 
> Yes but I'm not going to add a check for -1 just to make some unit test
> pass. In real code (size_t)-2 or (size_t)(-some other value) is at least as
> likely.
> 
> __glibcxx_assert(not in chromium tests) doesn't seem useful.

Oh, I just checked the LLVM implementation and it is... interesting:
https://github.com/llvm/llvm-project/blob/main/libcxx/include/string_view#L311C1-L318C1

It checks two conditions:
- Length should be 0 OR pointer should not be null.
- The length is less than the possible pointer difference (checked with
numeric_limits).

[Bug target/111311] RISC-V regression testsuite errors with --param=riscv-autovec-preference=scalable

[vineetg at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #9 from Vineet Gupta  ---
(In reply to Patrick O'Neill from comment #8)
> Updated regression list using r14-5070-g4ea36076d66 on rv64gcv:
> 
> Failure list from:
> https://github.com/patrick-rivos/gcc-postcommit-ci/issues/109

And just for completeness, we have this as starting point of investigation.

linux: rv64gc lp64d medlow  34/17   13/430/5
linux: rv64gcv lp64d medlow multilib83/52   13/430/11

[PATCH V3 5/6] aarch64: Add front-end argument type checking for target builtins

[Victor Do Nascimento]

In implementing the ACLE read/write system register builtins it was
observed that leaving argument type checking to be done at expand-time
meant that poorly-formed function calls were being "fixed" by certain
optimization passes, meaning bad code wasn't being properly picked up
in checking.

Example:

  const char *regname = "amcgcr_el0";
  long long a = __builtin_aarch64_rsr64 (regname);

is reduced by the ccp1 pass to

  long long a = __builtin_aarch64_rsr64 ("amcgcr_el0");

As these functions require an argument of STRING_CST type, there needs
to be a check carried out by the front-end capable of picking this up.

The introduced `check_general_builtin_call' function will be called by
the TARGET_CHECK_BUILTIN_CALL hook whenever a call to a builtin
belonging to the AARCH64_BUILTIN_GENERAL category is encountered,
carrying out any appropriate checks associated with a particular
builtin function code.

gcc/ChangeLog:

* config/aarch64/aarch64-builtins.cc (check_general_builtin_call):
New.
* config/aarch64/aarch64-c.cc (aarch64_check_builtin_call):
Add check_general_builtin_call call.
* config/aarch64/aarch64-protos.h (check_general_builtin_call):
New.

gcc/testsuite/ChangeLog:

* gcc.target/aarch64/acle/rwsr-3.c: New.
---
 gcc/config/aarch64/aarch64-builtins.cc| 31 +++
 gcc/config/aarch64/aarch64-c.cc   |  4 +--
 gcc/config/aarch64/aarch64-protos.h   |  4 +++
 .../gcc.target/aarch64/acle/rwsr-3.c  | 18 +++
 4 files changed, 55 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/aarch64/acle/rwsr-3.c

diff --git a/gcc/config/aarch64/aarch64-builtins.cc 
b/gcc/config/aarch64/aarch64-builtins.cc
index dd76cca611b..c5f20f68bca 100644
--- a/gcc/config/aarch64/aarch64-builtins.cc
+++ b/gcc/config/aarch64/aarch64-builtins.cc
@@ -2127,6 +2127,37 @@ aarch64_general_builtin_decl (unsigned code, bool)
   return aarch64_builtin_decls[code];
 }
 
+bool
+aarch64_check_general_builtin_call (location_t location, vec,
+   unsigned int code, tree fndecl,
+   unsigned int nargs ATTRIBUTE_UNUSED, tree *args)
+{
+  switch (code)
+{
+case AARCH64_RSR:
+case AARCH64_RSRP:
+case AARCH64_RSR64:
+case AARCH64_RSRF:
+case AARCH64_RSRF64:
+case AARCH64_WSR:
+case AARCH64_WSRP:
+case AARCH64_WSR64:
+case AARCH64_WSRF:
+case AARCH64_WSRF64:
+  if (TREE_CODE (args[0]) != NOP_EXPR
+ || TREE_CODE (TREE_TYPE (args[0])) != POINTER_TYPE
+ || (TREE_CODE (TREE_OPERAND (TREE_OPERAND (args[0], 0) , 0))
+ != STRING_CST))
+   {
+ error_at (location, "first argument to %qD must be a string literal",
+   fndecl);
+ return false;
+   }
+}
+  /* Default behavior.  */
+  return true;
+}
+
 typedef enum
 {
   SIMD_ARG_COPY_TO_REG,
diff --git a/gcc/config/aarch64/aarch64-c.cc b/gcc/config/aarch64/aarch64-c.cc
index ab8844f6049..be8b7236cf9 100644
--- a/gcc/config/aarch64/aarch64-c.cc
+++ b/gcc/config/aarch64/aarch64-c.cc
@@ -339,8 +339,8 @@ aarch64_check_builtin_call (location_t loc, vec 
arg_loc,
   switch (code & AARCH64_BUILTIN_CLASS)
 {
 case AARCH64_BUILTIN_GENERAL:
-  return true;
-
+  return aarch64_check_general_builtin_call (loc, arg_loc, subcode,
+orig_fndecl, nargs, args);
 case AARCH64_BUILTIN_SVE:
   return aarch64_sve::check_builtin_call (loc, arg_loc, subcode,
  orig_fndecl, nargs, args);
diff --git a/gcc/config/aarch64/aarch64-protos.h 
b/gcc/config/aarch64/aarch64-protos.h
index 5d6a1e75700..dbd486cfea4 100644
--- a/gcc/config/aarch64/aarch64-protos.h
+++ b/gcc/config/aarch64/aarch64-protos.h
@@ -990,6 +990,10 @@ tree aarch64_general_builtin_rsqrt (unsigned int);
 void handle_arm_acle_h (void);
 void handle_arm_neon_h (void);
 
+bool aarch64_check_general_builtin_call (location_t, vec,
+unsigned int, tree, unsigned int,
+tree *);
+
 namespace aarch64_sve {
   void init_builtins ();
   void handle_arm_sve_h ();
diff --git a/gcc/testsuite/gcc.target/aarch64/acle/rwsr-3.c 
b/gcc/testsuite/gcc.target/aarch64/acle/rwsr-3.c
new file mode 100644
index 000..17038fefbf6
--- /dev/null
+++ b/gcc/testsuite/gcc.target/aarch64/acle/rwsr-3.c
@@ -0,0 +1,18 @@
+/* Test the __arm_[r,w]sr ACLE intrinsics family.  */
+/* Ensure that illegal behavior is rejected by the compiler.  */
+
+/* { dg-do compile } */
+/* { dg-options "-std=c2x -O3 -march=armv8.4-a" } */
+
+#include 
+
+void
+test_non_const_sysreg_name ()
+{
+  const char *regname = "trcseqstr";
+  long long a = __arm_rsr64 (regname); /* { dg-error "first argument to 
'__builtin_aarch64_rsr64' must be a string literal" } */
+  __arm_wsr64 (regname, a); /* { dg-error "first argument to 

Re: [PATCH] Format gotools.sum closer to what DejaGnu does

[Maxim Kuvyrkov]

> On Nov 2, 2023, at 21:02, rep.dot@gmail.com wrote:
> 
> Hi Maxim!
> 
> Many thanks for the patch! Quick question below..
> 
> On 2 November 2023 13:48:55 CET, Maxim Kuvyrkov  
> wrote:
>> ... to restore compatability with validate_failures.py .
>> The testsuite script validate_failures.py expects
>> "Running  ..." to extract  values,
>> and gotools.sum provided "Running ".
>> 
>> Note that libgo.sum, which also uses Makefile logic to generate
>> DejaGnu-like output, already has "..." suffix.
>> 
>> gotools/ChangeLog:
>> 
>> * Makefile.am: Update "Running  ..." output
>> * Makefile.in: Regenerate.
>> ---
>> gotools/Makefile.am | 4 ++--
>> gotools/Makefile.in | 5 +++--
>> 2 files changed, 5 insertions(+), 4 deletions(-)
>> 
>> diff --git a/gotools/Makefile.am b/gotools/Makefile.am
>> index 7b5302990f8..d2376b9c25b 100644
>> --- a/gotools/Makefile.am
>> +++ b/gotools/Makefile.am
>> @@ -332,8 +332,8 @@ check: check-head check-go-tool check-runtime 
>> check-cgo-test check-carchive-test
>> @cp gotools.sum gotools.log
>> @for file in cmd_go-testlog runtime-testlog cgo-testlog carchive-testlog 
>> cmd_vet-testlog embed-testlog; do \
>>   testname=`echo $${file} | sed -e 's/-testlog//' -e 's|_|/|'`; \
>> -   echo "Running $${testname}" >> gotools.sum; \
>> -   echo "Running $${testname}" >> gotools.log; \
>> +   echo "Running $${testname} ..." >> gotools.sum; \
>> +   echo "Running $${testname} ..." >> gotools.log; \
>>   sed -e 's/^--- \(.*\) ([^)]*)$$/\1/' < $${file} >> gotools.log; \
>>   grep '^--- ' $${file} | sed -e 's/^--- \(.*\) ([^)]*)$$/\1/' -e 
>> 's/SKIP/UNTESTED/' | sort -k 2 >> gotools.sum; \
>> done
>> diff --git a/gotools/Makefile.in b/gotools/Makefile.in
>> index 2783b91ef4b..9cc238e748d 100644
>> --- a/gotools/Makefile.in
>> +++ b/gotools/Makefile.in
>> @@ -317,6 +317,7 @@ pdfdir = @pdfdir@
>> prefix = @prefix@
>> program_transform_name = @program_transform_name@
>> psdir = @psdir@
>> +runstatedir = @runstatedir@
> 
> Are you sure you used the correct version of automake?

I used automake 1.15.1 (from Ubuntu 20.04 automake-1.15 package), and I 
double-checked after getting the runstatedir update.

I would appreciate someone checking on their side to make sure I don't have 
something weird going on in my setup.

--
Maxim Kuvyrkov
https://www.linaro.org

Re: Suspecting a wrong behavior in the value range propagation analysis for __builtin_clz

[Joseph Myers]

On Thu, 2 Nov 2023, Richard Biener via Gcc wrote:

> Note the semantic of __builtin_clz is _not_ altered by
> CLZ_DEFINED_VALUE_AT_ZERO, the behavior
> of __builtin_clz (x) is that is has undefined result for x == 0.

Note also the discussion in bug 111309 of possible future type-generic 
versions of operations such as clz (under a different name because 
__builtin_clz is already taken), in order to support _BitInt, where 
there's a plausible argument for defining the result for all argument 
values rather than leaving it undefined at 0.

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

Re: [PATCH] Format gotools.sum closer to what DejaGnu does

[rep . dot . nop]

Hi Maxim!

Many thanks for the patch! Quick question below..

On 2 November 2023 13:48:55 CET, Maxim Kuvyrkov  
wrote:
>... to restore compatability with validate_failures.py .
>The testsuite script validate_failures.py expects
>"Running  ..." to extract  values,
>and gotools.sum provided "Running ".
>
>Note that libgo.sum, which also uses Makefile logic to generate
>DejaGnu-like output, already has "..." suffix.
>
>gotools/ChangeLog:
>
>   * Makefile.am: Update "Running  ..." output
>   * Makefile.in: Regenerate.
>---
> gotools/Makefile.am | 4 ++--
> gotools/Makefile.in | 5 +++--
> 2 files changed, 5 insertions(+), 4 deletions(-)
>
>diff --git a/gotools/Makefile.am b/gotools/Makefile.am
>index 7b5302990f8..d2376b9c25b 100644
>--- a/gotools/Makefile.am
>+++ b/gotools/Makefile.am
>@@ -332,8 +332,8 @@ check: check-head check-go-tool check-runtime 
>check-cgo-test check-carchive-test
>   @cp gotools.sum gotools.log
>   @for file in cmd_go-testlog runtime-testlog cgo-testlog 
> carchive-testlog cmd_vet-testlog embed-testlog; do \
> testname=`echo $${file} | sed -e 's/-testlog//' -e 's|_|/|'`; \
>-echo "Running $${testname}" >> gotools.sum; \
>-echo "Running $${testname}" >> gotools.log; \
>+echo "Running $${testname} ..." >> gotools.sum; \
>+echo "Running $${testname} ..." >> gotools.log; \
> sed -e 's/^--- \(.*\) ([^)]*)$$/\1/' < $${file} >> gotools.log; \
> grep '^--- ' $${file} | sed -e 's/^--- \(.*\) ([^)]*)$$/\1/' -e 
> 's/SKIP/UNTESTED/' | sort -k 2 >> gotools.sum; \
>   done
>diff --git a/gotools/Makefile.in b/gotools/Makefile.in
>index 2783b91ef4b..9cc238e748d 100644
>--- a/gotools/Makefile.in
>+++ b/gotools/Makefile.in
>@@ -317,6 +317,7 @@ pdfdir = @pdfdir@
> prefix = @prefix@
> program_transform_name = @program_transform_name@
> psdir = @psdir@
>+runstatedir = @runstatedir@

Are you sure you used the correct version of automake?

thanks

> sbindir = @sbindir@
> sharedstatedir = @sharedstatedir@
> srcdir = @srcdir@
>@@ -1003,8 +1004,8 @@ mostlyclean-local:
> @NATIVE_TRUE@ @cp gotools.sum gotools.log
> @NATIVE_TRUE@ @for file in cmd_go-testlog runtime-testlog cgo-testlog 
> carchive-testlog cmd_vet-testlog embed-testlog; do \
> @NATIVE_TRUE@   testname=`echo $${file} | sed -e 's/-testlog//' -e 's|_|/|'`; 
> \
>-@NATIVE_TRUE@   echo "Running $${testname}" >> gotools.sum; \
>-@NATIVE_TRUE@   echo "Running $${testname}" >> gotools.log; \
>+@NATIVE_TRUE@   echo "Running $${testname} ..." >> gotools.sum; \
>+@NATIVE_TRUE@   echo "Running $${testname} ..." >> gotools.log; \
> @NATIVE_TRUE@   sed -e 's/^--- \(.*\) ([^)]*)$$/\1/' < $${file} >> 
> gotools.log; \
> @NATIVE_TRUE@   grep '^--- ' $${file} | sed -e 's/^--- \(.*\) ([^)]*)$$/\1/' 
> -e 's/SKIP/UNTESTED/' | sort -k 2 >> gotools.sum; \
> @NATIVE_TRUE@ done

Re: Suspecting a wrong behavior in the value range propagation analysis for __builtin_clz

[Jakub Jelinek via Gcc]

On Thu, Nov 02, 2023 at 04:44:30PM +, Joseph Myers wrote:
> On Thu, 2 Nov 2023, Richard Biener via Gcc wrote:
> 
> > Note the semantic of __builtin_clz is _not_ altered by
> > CLZ_DEFINED_VALUE_AT_ZERO, the behavior
> > of __builtin_clz (x) is that is has undefined result for x == 0.
> 
> Note also the discussion in bug 111309 of possible future type-generic 
> versions of operations such as clz (under a different name because 
> __builtin_clz is already taken), in order to support _BitInt, where 
> there's a plausible argument for defining the result for all argument 
> values rather than leaving it undefined at 0.

I plan to work on that soon.
The current plan is to let the users choose what they want, by having
the type-generic variants of the builtin support either one or two
arguments (just for clz/ctz obviously), if only one is provided,
it is undefined at 0, if two are provided, then the second argument is
the value to be returned for 0.

So, __builtin_clzg (0uwb) or __builtin_clzg (0ULL) would be UB,
while __builtin_clzg (0uwb, 42) would return 42.
We'd need something like __builtin_widthof as well because _Bitwithof
or something similar hasn't been standardized yet, so people can use
the type-generic function in macro and ask for the number of bits
to be returned for 0 (or something based on that).

Jakub

[PATCH V3 4/6] aarch64: Implement system register r/w arm ACLE intrinsic functions

[Victor Do Nascimento]

Implement the aarch64 intrinsics for reading and writing system
registers with the following signatures:

uint32_t __arm_rsr(const char *special_register);
uint64_t __arm_rsr64(const char *special_register);
void* __arm_rsrp(const char *special_register);
float __arm_rsrf(const char *special_register);
double __arm_rsrf64(const char *special_register);
void __arm_wsr(const char *special_register, uint32_t value);
void __arm_wsr64(const char *special_register, uint64_t value);
void __arm_wsrp(const char *special_register, const void *value);
void __arm_wsrf(const char *special_register, float value);
void __arm_wsrf64(const char *special_register, double value);

gcc/ChangeLog:

* config/aarch64/aarch64-builtins.cc (enum aarch64_builtins):
Add enums for new builtins.
(aarch64_init_rwsr_builtins): New.
(aarch64_general_init_builtins): Call aarch64_init_rwsr_builtins.
(aarch64_expand_rwsr_builtin):  New.
(aarch64_general_expand_builtin): Call aarch64_general_expand_builtin.
* config/aarch64/aarch64.md (read_sysregdi): New insn_and_split.
(write_sysregdi): Likewise.
* config/aarch64/arm_acle.h (__arm_rsr): New.
(__arm_rsrp): Likewise.
(__arm_rsr64): Likewise.
(__arm_rsrf): Likewise.
(__arm_rsrf64): Likewise.
(__arm_wsr): Likewise.
(__arm_wsrp): Likewise.
(__arm_wsr64): Likewise.
(__arm_wsrf): Likewise.
(__arm_wsrf64): Likewise.

gcc/testsuite/ChangeLog:

* gcc.target/aarch64/acle/rwsr.c: New.
* gcc.target/aarch64/acle/rwsr-1.c: Likewise.
* gcc.target/aarch64/acle/rwsr-2.c: Likewise.
* gcc.dg/pch/rwsr-pch.c: Likewise.
* gcc.dg/pch/rwsr-pch.hs: Likewise.
---
 gcc/config/aarch64/aarch64-builtins.cc| 191 ++
 gcc/config/aarch64/aarch64.md |  18 ++
 gcc/config/aarch64/arm_acle.h |  30 +++
 gcc/testsuite/gcc.dg/pch/rwsr-pch.c   |   7 +
 gcc/testsuite/gcc.dg/pch/rwsr-pch.hs  |  10 +
 .../gcc.target/aarch64/acle/rwsr-1.c  |  29 +++
 .../gcc.target/aarch64/acle/rwsr-2.c  |  25 +++
 gcc/testsuite/gcc.target/aarch64/acle/rwsr.c  | 144 +
 8 files changed, 454 insertions(+)
 create mode 100644 gcc/testsuite/gcc.dg/pch/rwsr-pch.c
 create mode 100644 gcc/testsuite/gcc.dg/pch/rwsr-pch.hs
 create mode 100644 gcc/testsuite/gcc.target/aarch64/acle/rwsr-1.c
 create mode 100644 gcc/testsuite/gcc.target/aarch64/acle/rwsr-2.c
 create mode 100644 gcc/testsuite/gcc.target/aarch64/acle/rwsr.c

diff --git a/gcc/config/aarch64/aarch64-builtins.cc 
b/gcc/config/aarch64/aarch64-builtins.cc
index 04f59fd9a54..dd76cca611b 100644
--- a/gcc/config/aarch64/aarch64-builtins.cc
+++ b/gcc/config/aarch64/aarch64-builtins.cc
@@ -47,6 +47,7 @@
 #include "stringpool.h"
 #include "attribs.h"
 #include "gimple-fold.h"
+#include "builtins.h"
 
 #define v8qi_UP  E_V8QImode
 #define v8di_UP  E_V8DImode
@@ -808,6 +809,17 @@ enum aarch64_builtins
   AARCH64_RBIT,
   AARCH64_RBITL,
   AARCH64_RBITLL,
+  /* System register builtins.  */
+  AARCH64_RSR,
+  AARCH64_RSRP,
+  AARCH64_RSR64,
+  AARCH64_RSRF,
+  AARCH64_RSRF64,
+  AARCH64_WSR,
+  AARCH64_WSRP,
+  AARCH64_WSR64,
+  AARCH64_WSRF,
+  AARCH64_WSRF64,
   AARCH64_BUILTIN_MAX
 };
 
@@ -1798,6 +1810,65 @@ aarch64_init_rng_builtins (void)
   AARCH64_BUILTIN_RNG_RNDRRS);
 }
 
+/* Add builtins for reading system register.  */
+static void
+aarch64_init_rwsr_builtins (void)
+{
+  tree fntype = NULL;
+  tree const_char_ptr_type
+= build_pointer_type (build_type_variant (char_type_node, true, false));
+
+#define AARCH64_INIT_RWSR_BUILTINS_DECL(F, N, T) \
+  aarch64_builtin_decls[AARCH64_##F] \
+= aarch64_general_add_builtin ("__builtin_aarch64_"#N, T, AARCH64_##F);
+
+  fntype
+= build_function_type_list (uint32_type_node, const_char_ptr_type, NULL);
+  AARCH64_INIT_RWSR_BUILTINS_DECL (RSR, rsr, fntype);
+
+  fntype
+= build_function_type_list (ptr_type_node, const_char_ptr_type, NULL);
+  AARCH64_INIT_RWSR_BUILTINS_DECL (RSRP, rsrp, fntype);
+
+  fntype
+= build_function_type_list (uint64_type_node, const_char_ptr_type, NULL);
+  AARCH64_INIT_RWSR_BUILTINS_DECL (RSR64, rsr64, fntype);
+
+  fntype
+= build_function_type_list (float_type_node, const_char_ptr_type, NULL);
+  AARCH64_INIT_RWSR_BUILTINS_DECL (RSRF, rsrf, fntype);
+
+  fntype
+= build_function_type_list (double_type_node, const_char_ptr_type, NULL);
+  AARCH64_INIT_RWSR_BUILTINS_DECL (RSRF64, rsrf64, fntype);
+
+  fntype
+= build_function_type_list (void_type_node, const_char_ptr_type,
+   uint32_type_node, NULL);
+
+  AARCH64_INIT_RWSR_BUILTINS_DECL (WSR, wsr, fntype);
+
+  fntype
+= build_function_type_list (void_type_node, const_char_ptr_type,
+   const_ptr_type_node, 

[PATCH V3 6/6] aarch64: Add system register duplication check selftest

[Victor Do Nascimento]

Add a build-time test to check whether system register data, as
imported from `aarch64-sys-reg.def' has any duplicate entries.

Duplicate entries are defined as any two SYSREG entries in the .def
file which share the same encoding values (as specified by its `CPENC'
field) and where the relationship amongst the two does not fit into
one of the following categories:

* Simple aliasing: In some cases, it is observed that one
register name serves as an alias to another.  One example of
this is where TRCEXTINSELR aliases TRCEXTINSELR0.
* Expressing intent: It is possible that when a given register
serves two distinct functions depending on how it is used, it
is given two distinct names whose use should match the context
under which it is being used.  Example:  Debug Data Transfer
Register. When used to receive data, it should be accessed as
DBGDTRRX_EL0 while when transmitting data it should be
accessed via DBGDTRTX_EL0.
* Register depreciation: Some register names have been
deprecated and should no longer be used, but backwards-
compatibility requires that such names continue to be
recognized, as is the case for the SPSR_EL1 register, whose
access via the SPSR_SVC name is now deprecated.
* Same encoding different target: Some encodings are given
different meaning depending on the target architecture and, as
such, are given different names in each of theses contexts.
We see an example of this for CPENC(3,4,2,0,0), which
corresponds to TTBR0_EL2 for Armv8-A targets and VSCTLR_EL2
in Armv8-R targets.

A consequence of these observations is that `CPENC' duplication is
acceptable iff at least one of the `properties' or `arch_reqs' fields
of the `sysreg_t' structs associated with the two registers in
question differ and it's this condition that is checked by the new
`aarch64_test_sysreg_encoding_clashes' function.

gcc/ChangeLog:

* config/aarch64/aarch64.cc
(aarch64_test_sysreg_encoding_clashes): New.
(aarch64_run_selftests): add call to
aarch64_test_sysreg_encoding_clashes selftest.
---
 gcc/config/aarch64/aarch64.cc | 44 +++
 1 file changed, 44 insertions(+)

diff --git a/gcc/config/aarch64/aarch64.cc b/gcc/config/aarch64/aarch64.cc
index eaeab0be436..c0d75f167be 100644
--- a/gcc/config/aarch64/aarch64.cc
+++ b/gcc/config/aarch64/aarch64.cc
@@ -22,6 +22,7 @@
 
 #define INCLUDE_STRING
 #define INCLUDE_ALGORITHM
+#define INCLUDE_VECTOR
 #include "config.h"
 #include "system.h"
 #include "coretypes.h"
@@ -28390,6 +28391,48 @@ aarch64_test_fractional_cost ()
   ASSERT_EQ (cf (1, 2).as_double (), 0.5);
 }
 
+/* Calculate whether our system register data, as imported from
+   `aarch64-sys-reg.def' has any duplicate entries.  */
+static void
+aarch64_test_sysreg_encoding_clashes (void)
+{
+  using dup_instances_t = hash_map>;
+
+  dup_instances_t duplicate_instances;
+
+  /* Every time an encoding is established to come up more than once
+ we add it to a "clash-analysis queue", which is then used to extract
+ necessary information from our hash map when establishing whether
+ repeated encodings are valid.  */
+
+  /* 1) Collect recurrence information.  */
+  for (unsigned i = 0; i < nsysreg; i++)
+{
+  const sysreg_t *reg = sysreg_structs + i;
+
+  std::vector *tmp
+   = _instances.get_or_insert (reg->encoding);
+
+  tmp->push_back (reg);
+}
+
+  /* 2) Carry out analysis on collected data.  */
+  for (auto instance : duplicate_instances)
+{
+  unsigned nrep = instance.second.size ();
+  if (nrep > 1)
+   for (unsigned i = 0; i < nrep; i++)
+ for (unsigned j = i + 1; j < nrep; j++)
+   {
+ const sysreg_t *a = instance.second[i];
+ const sysreg_t *b = instance.second[j];
+ ASSERT_TRUE ((a->properties != b->properties)
+  || (a->arch_reqs != b->arch_reqs));
+   }
+}
+}
+
 /* Run all target-specific selftests.  */
 
 static void
@@ -28397,6 +28440,7 @@ aarch64_run_selftests (void)
 {
   aarch64_test_loading_full_dump ();
   aarch64_test_fractional_cost ();
+  aarch64_test_sysreg_encoding_clashes ();
 }
 
 } // namespace selftest
-- 
2.41.0

[PATCH V3 0/6] aarch64: Add support for __arm_rsr and __arm_wsr ACLE function family

[Victor Do Nascimento]

Implement changes resulting from upstream discussion about the
implementation as presented in V2 of this patch:

https://gcc.gnu.org/pipermail/gcc-patches/2023-October/633458.html

Note that patch 4/7 of the previous iteration of this series (Add
basic target_print_operand support for CONST_STRING) was resubmitted
and upstreamed separately due to its use in other work which had since
been submitted.

---

This patch series adds support for reading and writing to and from
system registers via the relevant ACLE-defined builtins [1].

The patch series makes a series of additions to the aarch64-specific
areas of the compiler to make this possible.

Firstly, a mechanism for defining system registers is established via a
new .def file and the new SYSREG macro.  This macro is the same as is
used in Binutils and system register entries are compatible with
either code-base.

Given the information contained in this system register definition
file, a compile-time validation mechanism is implemented, such that any
system register name passed as a string literal argument to these
builtins can be checked against known system registers and its use
for a given target architecture validated.

Finally, patterns for each of these builtins are added to the back-end
such that, if all validation criteria are met, the correct assembly is
emitted.

Thus, the following example of system register access is now valid for
GCC:

long long old = __arm_rsr("trcseqstr");
__arm_wsr("trcseqstr", new);

Testing:
 - Bootstrap/regtest on aarch64-linux-gnu done.

[1] https://arm-software.github.io/acle/main/acle.html

Victor Do Nascimento (6):
  aarch64: Sync system register information with Binutils
  aarch64: Add support for aarch64-sys-regs.def
  aarch64: Implement system register validation tools
  aarch64: Implement system register r/w arm ACLE intrinsic functions
  aarch64: Add front-end argument type checking for target builtins
  aarch64: Add system register duplication check selftest

 gcc/config/aarch64/aarch64-builtins.cc|  222 
 gcc/config/aarch64/aarch64-c.cc   |4 +-
 gcc/config/aarch64/aarch64-protos.h   |6 +
 gcc/config/aarch64/aarch64-sys-regs.def   | 1064 +
 gcc/config/aarch64/aarch64.cc |  244 
 gcc/config/aarch64/aarch64.h  |   22 +
 gcc/config/aarch64/aarch64.md |   18 +
 gcc/config/aarch64/arm_acle.h |   30 +
 gcc/config/aarch64/predicates.md  |4 +
 gcc/testsuite/gcc.dg/pch/rwsr-pch.c   |7 +
 gcc/testsuite/gcc.dg/pch/rwsr-pch.hs  |   10 +
 .../gcc.target/aarch64/acle/rwsr-1.c  |   29 +
 .../gcc.target/aarch64/acle/rwsr-2.c  |   25 +
 .../gcc.target/aarch64/acle/rwsr-3.c  |   18 +
 gcc/testsuite/gcc.target/aarch64/acle/rwsr.c  |  144 +++
 15 files changed, 1845 insertions(+), 2 deletions(-)
 create mode 100644 gcc/config/aarch64/aarch64-sys-regs.def
 create mode 100644 gcc/testsuite/gcc.dg/pch/rwsr-pch.c
 create mode 100644 gcc/testsuite/gcc.dg/pch/rwsr-pch.hs
 create mode 100644 gcc/testsuite/gcc.target/aarch64/acle/rwsr-1.c
 create mode 100644 gcc/testsuite/gcc.target/aarch64/acle/rwsr-2.c
 create mode 100644 gcc/testsuite/gcc.target/aarch64/acle/rwsr-3.c
 create mode 100644 gcc/testsuite/gcc.target/aarch64/acle/rwsr.c

-- 
2.41.0