Re: [PATCH v2] swap: Fix incorrect lane extraction by vec_extract() [PR106770]

[Segher Boessenkool]

Hi!

Please say "rs6000/p8swap:" in the subject, not "swap:" :-)

On Sun, Sep 10, 2023 at 10:58:32PM +0530, Surya Kumari Jangala wrote:
> Another issue with always handling swappable instructions is that it is
> incorrect to do so in webs where loads/stores on quad word aligned
> addresses are changed to lvx/stvx.

Why?  Please say why in the commit message (the message you send with
your patch should be the exact eventual commit message!)

> gcc/
>   PR rtl-optimization/PR106770
>   * config/rs6000/rs6000-p8swap.cc (non_permuting_mem_insn): New
>   function.

Please don't break commit message / changelog lines early unnecessarily.
Lines are 80 chars, the leading tab counts as 8.

> +  /* Set if the swappable insns in the web represented by this entry
> + have to be fixed. Swappable insns have to be fixed in :

(no space before colon)

> +static bool
> +non_permuting_mem_insn (swap_web_entry *insn_entry, unsigned int i)
> +{
> +  return (insn_entry[i].special_handling == SH_NOSWAP_LD ||
> +   insn_entry[i].special_handling == SH_NOSWAP_ST);
> +}

"return" is not a function, you don't need parens here.

> +/* Convert a non-permuting load/store insn to a permuting one.  */
> +static void
> +handle_non_permuting_mem_insn (swap_web_entry *insn_entry, unsigned int i)

A better name would be good, "handle" is a weaselword :-)  It is a
static, so a shorter name is completely acceptable (say, one that
wouldn't be acceptable with bigger than file scope).

> +  rtx_insn *insn = insn_entry[i].insn;
> +  if (insn_entry[i].special_handling == SH_NOSWAP_LD)
> +permute_load (insn);
> +  else if (insn_entry[i].special_handling == SH_NOSWAP_ST)
> +permute_store (insn);

Lose the "else"?  The compiler can do micro-optimisations a million
times better than any user could.  Simpler, more readable (better
understandable!) code is much preferred.

> +  /* Perform special handling for swappable insns that require it.

That is a completely contentless sentence :-(

> + Note that special handling should be done only for those
> + swappable insns that are present in webs marked as requiring
> + special handling.  */

This one isn't much better.

> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/powerpc/pr106770.c
> @@ -0,0 +1,21 @@
> +/* { dg-do compile } */

This is the default, you do not need this.

> +/* { dg-require-effective-target powerpc_p8vector_ok } */
> +/* { dg-options "-mdejagnu-cpu=power8 -O2 " } */
> +/* The 2 xxpermdi instructions are generated by the two
> +   calls to vec_promote() */
> +/* { dg-final { scan-assembler-times "xxpermdi" 2 } } */

Please enclose in {}.  Use double quotes in Tcl only when tou want the
interpolation they cause.  Default to using {} instead.

So please fix those things, and write a better commit message.  Ideally
the commit messsage will tell everything needed to understand the patch
(so also to review the patch).  Maybe add examples where needed.  So
reviewing the code in the patch should be an easy thing to do, after
reading the commit message :-)


Segher

[COMMITTED] gcc: xtensa: fix salt/saltu version check

[Max Filippov]

gcc/
* config/xtensa/xtensa.h (TARGET_SALT): Change HW version from
26 (which corresponds to RF-2014.0) to 27 (which
corresponds to RG-2015.0, the release where salt/saltu opcodes
were introduced).
---
 gcc/config/xtensa/xtensa.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/config/xtensa/xtensa.h b/gcc/config/xtensa/xtensa.h
index 5987681e5496..49e6350001da 100644
--- a/gcc/config/xtensa/xtensa.h
+++ b/gcc/config/xtensa/xtensa.h
@@ -54,7 +54,7 @@ along with GCC; see the file COPYING3.  If not see
 #define TARGET_WINDOWED_ABIxtensa_windowed_abi
 #define TARGET_DEBUG   XCHAL_HAVE_DEBUG
 #define TARGET_L32RXCHAL_HAVE_L32R
-#define TARGET_SALT(XTENSA_MARCH_EARLIEST >= 26)
+#define TARGET_SALT(XTENSA_MARCH_EARLIEST >= 27)
 
 #define TARGET_DEFAULT (MASK_SERIALIZE_VOLATILE)
 
-- 
2.39.2

[PATCH] c++: fix noexcept checking for trivial operations [PR96090]

[Nathaniel Shead]

Bootstrapped and regtested on x86_64-pc-linux-gnu.

-- >8 --

This patch stops eager folding of trivial operations (construction and
assignment) from occurring when checking for noexceptness. This was
previously done in PR c++/53025, but only for copy/move construction,
and the __is_nothrow_xible builtins did not receive the same treatment
when they were added.

To handle `is_nothrow_default_constructible`, the patch also ensures
that when no parameters are passed we do value initialisation instead of
just building the constructor call: in particular, value-initialisation
doesn't necessarily actually invoke the constructor for trivial default
constructors, and so we need to handle this case as well.

PR c++/96090
PR c++/100470

gcc/cp/ChangeLog:

* call.cc (build_over_call): Prevent folding of trivial special
members when checking for noexcept.
* method.cc (constructible_expr): Perform value-initialisation
for empty parameter lists.
(is_nothrow_xible): Treat as noexcept operator.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/noexcept81.C: New test.
* g++.dg/ext/is_nothrow_constructible7.C: New test.
* g++.dg/ext/is_nothrow_constructible8.C: New test.

Signed-off-by: Nathaniel Shead 
---
 gcc/cp/call.cc| 17 ++---
 gcc/cp/method.cc  | 19 --
 gcc/testsuite/g++.dg/cpp0x/noexcept81.C   | 36 +++
 .../g++.dg/ext/is_nothrow_constructible7.C| 20 ++
 .../g++.dg/ext/is_nothrow_constructible8.C| 63 +++
 5 files changed, 141 insertions(+), 14 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/noexcept81.C
 create mode 100644 gcc/testsuite/g++.dg/ext/is_nothrow_constructible7.C
 create mode 100644 gcc/testsuite/g++.dg/ext/is_nothrow_constructible8.C

diff --git a/gcc/cp/call.cc b/gcc/cp/call.cc
index c1fb8807d3f..ac02b0633ed 100644
--- a/gcc/cp/call.cc
+++ b/gcc/cp/call.cc
@@ -10231,15 +10231,16 @@ build_over_call (struct z_candidate *cand, int flags, 
tsubst_flags_t complain)
   /* Avoid actually calling copy constructors and copy assignment operators,
  if possible.  */
 
-  if (! flag_elide_constructors && !force_elide)
+  if (!force_elide 
+  && (!flag_elide_constructors
+ /* It's unsafe to elide the operation when handling
+a noexcept-expression, it may evaluate to the wrong
+value (c++/53025, c++/96090).  */
+ || cp_noexcept_operand != 0))
 /* Do things the hard way.  */;
-  else if (cand->num_convs == 1 
-   && (DECL_COPY_CONSTRUCTOR_P (fn) 
-   || DECL_MOVE_CONSTRUCTOR_P (fn))
-  /* It's unsafe to elide the constructor when handling
- a noexcept-expression, it may evaluate to the wrong
- value (c++/53025).  */
-  && (force_elide || cp_noexcept_operand == 0))
+  else if (cand->num_convs == 1
+  && (DECL_COPY_CONSTRUCTOR_P (fn)
+  || DECL_MOVE_CONSTRUCTOR_P (fn)))
 {
   tree targ;
   tree arg = argarray[num_artificial_parms_for (fn)];
diff --git a/gcc/cp/method.cc b/gcc/cp/method.cc
index a70dd5d6adc..3c978e2369d 100644
--- a/gcc/cp/method.cc
+++ b/gcc/cp/method.cc
@@ -2091,6 +2091,7 @@ constructible_expr (tree to, tree from)
 {
   tree expr;
   cp_unevaluated cp_uneval_guard;
+  const int len = TREE_VEC_LENGTH (from);
   if (CLASS_TYPE_P (to))
 {
   tree ctype = to;
@@ -2098,11 +2099,16 @@ constructible_expr (tree to, tree from)
   if (!TYPE_REF_P (to))
to = cp_build_reference_type (to, /*rval*/false);
   tree ob = build_stub_object (to);
-  vec_alloc (args, TREE_VEC_LENGTH (from));
-  for (tree arg : tree_vec_range (from))
-   args->quick_push (build_stub_object (arg));
-  expr = build_special_member_call (ob, complete_ctor_identifier, ,
-   ctype, LOOKUP_NORMAL, tf_none);
+  if (len == 0)
+   expr = build_value_init (ctype, tf_none);
+  else
+   {
+ vec_alloc (args, TREE_VEC_LENGTH (from));
+ for (tree arg : tree_vec_range (from))
+   args->quick_push (build_stub_object (arg));
+ expr = build_special_member_call (ob, complete_ctor_identifier, ,
+   ctype, LOOKUP_NORMAL, tf_none);
+   }
   if (expr == error_mark_node)
return error_mark_node;
   /* The current state of the standard vis-a-vis LWG 2116 is that
@@ -2120,7 +2126,6 @@ constructible_expr (tree to, tree from)
 }
   else
 {
-  const int len = TREE_VEC_LENGTH (from);
   if (len == 0)
return build_value_init (strip_array_types (to), tf_none);
   if (len > 1)
@@ -2216,7 +2221,9 @@ is_trivially_xible (enum tree_code code, tree to, tree 
from)
 bool
 is_nothrow_xible (enum tree_code code, tree to, tree from)
 {
+  ++cp_noexcept_operand;
   tree expr = is_xible_helper (code, to, from, /*trivial*/false);
+  

RE: [PATCH v1] RISC-V: Fix one range-loop-construct warning of avlprop

[Li, Pan2]

Committed, thanks Jeff.

Pan

-Original Message-
From: Jeff Law  
Sent: Saturday, October 28, 2023 11:00 PM
To: Li, Pan2 ; gcc-patches@gcc.gnu.org
Cc: juzhe.zh...@rivai.ai; Wang, Yanzhang ; 
kito.ch...@gmail.com
Subject: Re: [PATCH v1] RISC-V: Fix one range-loop-construct warning of avlprop



On 10/28/23 08:51, pan2...@intel.com wrote:
> From: Pan Li 
> 
> This patch would like to fix one warning of avlprop as below.
> 
> ../../gcc/config/riscv/riscv-avlprop.cc: In member function 'virtual
> unsigned int pass_avlprop::execute(function*)':
> ../../gcc/config/riscv/riscv-avlprop.cc:346:23: error: loop variable
> 'candidate' creates a copy from type 'const std::pair rtl_ssa::insn_info*>' [-Werror=range-loop-construct]
>346 |   for (const auto candidate : m_candidates)
>|   ^
> ../../gcc/config/riscv/riscv-avlprop.cc:346:23: note: use reference type
> to prevent copying
>346 |   for (const auto candidate : m_candidates)
>|   ^
>|   &
> 
> gcc/ChangeLog:
> 
>   * config/riscv/riscv-avlprop.cc (pass_avlprop::execute): Use
>   reference type to prevent copying.
OK
jeff
> 

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

[waffl3x]

I woke up today and figured it out in about 30 minutes, I don't know if
this solution would be okay but I am running away from
cp_build_addr_expr_1 for now. I think this is another place I will have
the urge to refactor in the future, but if I keep looking at it right
now I am just going to waste all my energy before I finish everything
else.

This line
```
  else if (BASELINK_P (TREE_OPERAND (arg, 1)))
```
near the bottom of the function is almost certainly dead. The switch
case (near the top) for baselink reassigns arg.
```
case BASELINK:
  arg = BASELINK_FUNCTIONS (arg);
```
And I'm pretty sure a baselink's functions can't be a baselink, so that
case near the bottom is almost certainly dead. I've put it in my todo
so I will look at it in the future.

Anyway, here is my new solution, it seems to work, but as indicated in
the comment (for myself) I'm not sure this handles constexpr things
right as near the bottom of this function there is some constexpr
handling. I know I said it took me 30 minutes but I realized I had some
holes I needed to check as I was writing this email, so it was more
like 2 hours.
```
/* Forming a pointer-to-member is a use of non-pure-virtual fns.  */
if (TREE_CODE (t) == FUNCTION_DECL
&& !DECL_PURE_VIRTUAL_P (t)
&& !mark_used (t, complain) && !(complain & tf_error))
  return error_mark_node;

/* Exception for non-overloaded explicit object member function.  */
/* I am pretty sure this is still not perfect, I think we aren't
   handling some constexpr stuff, but I am leaving it for now. */
if (TREE_CODE (TREE_TYPE (t)) == FUNCTION_TYPE)
  return build_address (t);

type = build_ptrmem_type (context_for_name_lookup (t),
  TREE_TYPE (t));
t = make_ptrmem_cst (type, t);
return t;
  }
```
I'm sharing it because I am still uncertain on whether this is the
ideal solution, this function is kind of a mess in general (sorry) so
it's hard to tell.

There's still a few things in my previous email that I would like
looked at, primarily the differences I observed in returns from
grokdeclarator, but I am glad to finally be moving forward on to other
things. Hopefully I can put together the patches with this one fixed.
(Of course I still have to fix the other bug I found as well.)

I had thought I might try to get lambda support and by value xobj
params working in this patch, but I think that will still be something
I work on once I am finished the initial patch. I still want to get
both of those into GCC14 though so I probably need to speed things up.

Alex

> 
> 
> I've been under the weather so I took a few days break, I honestly was
> also very reluctant to pick it back up. The current problem is what I
> like to call "not friendly", but I am back at it now.
> 
> > > I don't understand what this means exactly, under what circumstances
> > > would  find the member function. Oh, I guess while in the body of
> > > it's class, I hadn't considered that. Is that what you're referring to?
> > 
> > Right:
> > 
> > struct A {
> > void g(this A&);
> > A() {
> > ::g; // ok
> >  // same error as for an implicit object member function
> > }
> > };
> 
> 
> I fully get this now, I threw together a test for it so this case
> doesn't get forgotten about. Unfortunately though, I am concerned that
> the approach I was going to take to fix the crash would have the
> incorrect behavior for this.
> 
> Here is what I added to cp_build_addr_expr_1 with context included.
> `case OFFSET_REF: offset_ref: /* Turn a reference to a non-static data member 
> into a pointer-to-member. */ { tree type; tree t; gcc_assert (PTRMEM_OK_P 
> (arg)); t = TREE_OPERAND (arg, 1); if (TYPE_REF_P (TREE_TYPE (t))) { if 
> (complain & tf_error) error_at (loc, "cannot create pointer to reference 
> member %qD", t); return error_mark_node; } /* -- Waffl3x additions start -- 
> */ /* Exception for non-overloaded explicit object member function. */ if 
> (TREE_CODE (TREE_TYPE (t)) == FUNCTION_TYPE) return build1 (ADDR_EXPR, 
> unknown_type_node, arg); /* -- Waffl3x additions end -- */ /* Forming a 
> pointer-to-member is a use of non-pure-virtual fns. */ if (TREE_CODE (t) == 
> FUNCTION_DECL && !DECL_PURE_VIRTUAL_P (t) && !mark_used (t, complain) && 
> !(complain & tf_error)) return error_mark_node;`
> 
> I had hoped this naive solution would work just fine, but unfortunately
> the following code fails to compile with an error.
> 
> `struct S { void f(this S&) {} }; int main() { void (*a)(S&) = ::f; }`
> normal_static.C: In function ‘int main()’:
> normal_static.C:13:25: error: cannot convert ‘S::f’ from type ‘void(S&)’ to 
> type ‘void (*)(S&)’
> 13 | void (*a)(S&) = ::f;
> | ^
> 
> So clearly it isn't going to be that easy. I went up and down looking
> at how the single static case is handled, and tried to read the code in
> build_ptrmem_type and build_ptrmemfunc_type but I had a hard time
> 

[Bug spam/8943] spam

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Priority|P3  |P5
 CC|gcc-bugs at gcc dot gnu.org,   |
   |paolo.carlini at oracle dot com|
Summary|Love Match! |spam
   Severity|normal  |trivial

[Bug target/111867] aarch64: Wrong code for bf16 literal load when the arch support +fp16

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #6 from Andrew Pinski  ---
Won't be able to get to this until assignment is figured out 

[Bug d/112270] ICE: in verify_gimple_in_seq on powerpc-darwin9

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

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

ibuclaw at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #4 from ibuclaw at gcc dot gnu.org ---
Fix committed, and backported to GCC 13 and GCC 12 release branches.

[committed] d: Fix ICE: in verify_gimple_in_seq on powerpc-darwin9 [PR112270]

[Iain Buclaw]

Hi,

This patch fixes an ICE seen during stage2 on powerpc-darwin9 only.
There were still some uses of GCC's boolean_type_node in the D
front-end, which caused a type mismatch to trigger as D bool size is
fixed to 1 byte on all targets.

So two new nodes have been introduced - d_bool_false_node and
d_bool_true_node - which have replaced all remaining uses of
boolean_false_node and boolean_true_node respectively.

Bootstrapped and regression tested on x86_64-linux-gnu/-m32, committed
to mainline, and backported to gcc-12 and gcc-13.

Regards,
Iain.

---
PR d/112270

gcc/d/ChangeLog:

* d-builtins.cc (d_build_d_type_nodes): Initialize d_bool_false_node,
d_bool_true_node.
* d-codegen.cc (build_array_struct_comparison): Use d_bool_false_node
instead of boolean_false_node.
* d-convert.cc (d_truthvalue_conversion): Use d_bool_false_node and
d_bool_true_node instead of boolean_false_node and boolean_true_node.
* d-tree.h (enum d_tree_index): Add DTI_BOOL_FALSE and DTI_BOOL_TRUE.
(d_bool_false_node): New macro.
(d_bool_true_node): New macro.
* modules.cc (build_dso_cdtor_fn): Use d_bool_false_node and
d_bool_true_node instead of boolean_false_node and boolean_true_node.
(register_moduleinfo): Use d_bool_type instead of boolean_type_node.

gcc/testsuite/ChangeLog:

* gdc.dg/pr112270.d: New test.
---
 gcc/d/d-builtins.cc |  3 +++
 gcc/d/d-codegen.cc  |  2 +-
 gcc/d/d-convert.cc  | 10 +-
 gcc/d/d-tree.h  |  6 ++
 gcc/d/modules.cc|  4 ++--
 gcc/testsuite/gdc.dg/pr112270.d |  7 +++
 6 files changed, 24 insertions(+), 8 deletions(-)
 create mode 100644 gcc/testsuite/gdc.dg/pr112270.d

diff --git a/gcc/d/d-builtins.cc b/gcc/d/d-builtins.cc
index cf998d22721..f6ea026bdcf 100644
--- a/gcc/d/d-builtins.cc
+++ b/gcc/d/d-builtins.cc
@@ -956,6 +956,9 @@ d_build_d_type_nodes (void)
   d_bool_type = make_unsigned_type (1);
   TREE_SET_CODE (d_bool_type, BOOLEAN_TYPE);
 
+  d_bool_false_node = TYPE_MIN_VALUE (d_bool_type);
+  d_bool_true_node = TYPE_MAX_VALUE (d_bool_type);
+
   char8_type_node = make_unsigned_type (8);
   TYPE_STRING_FLAG (char8_type_node) = 1;
 
diff --git a/gcc/d/d-codegen.cc b/gcc/d/d-codegen.cc
index 91ddb1b657e..270cb5e2be6 100644
--- a/gcc/d/d-codegen.cc
+++ b/gcc/d/d-codegen.cc
@@ -1115,7 +1115,7 @@ build_array_struct_comparison (tree_code code, 
StructDeclaration *sd,
if (length == 0 || result OP 0) break;  */
   t = build_boolop (EQ_EXPR, length, d_convert (lentype, integer_zero_node));
   t = build_boolop (TRUTH_ORIF_EXPR, t, build_boolop (code, result,
- boolean_false_node));
+ d_bool_false_node));
   t = build1 (EXIT_EXPR, void_type_node, t);
   add_stmt (t);
 
diff --git a/gcc/d/d-convert.cc b/gcc/d/d-convert.cc
index 2b9d8e78fb6..71d7a41374e 100644
--- a/gcc/d/d-convert.cc
+++ b/gcc/d/d-convert.cc
@@ -132,13 +132,13 @@ d_truthvalue_conversion (tree expr)
   return expr;
 
 case INTEGER_CST:
-  return integer_zerop (expr) ? boolean_false_node
- : boolean_true_node;
+  return integer_zerop (expr) ? d_bool_false_node
+ : d_bool_true_node;
 
 case REAL_CST:
   return real_compare (NE_EXPR, _REAL_CST (expr), )
-? boolean_true_node
-: boolean_false_node;
+? d_bool_true_node
+: d_bool_false_node;
 
 case ADDR_EXPR:
   /* If we are taking the address of a decl that can never be null,
@@ -148,7 +148,7 @@ d_truthvalue_conversion (tree expr)
  warning (OPT_Waddress,
   "the address of %qD will always evaluate as %",
   TREE_OPERAND (expr, 0));
- return boolean_true_node;
+ return d_bool_true_node;
}
   break;
 
diff --git a/gcc/d/d-tree.h b/gcc/d/d-tree.h
index ed26533feb4..7763695a106 100644
--- a/gcc/d/d-tree.h
+++ b/gcc/d/d-tree.h
@@ -444,6 +444,9 @@ enum d_tree_index
   DTI_NULL_ARRAY,
   DTI_BOTTOM_TYPE,
 
+  DTI_BOOL_FALSE,
+  DTI_BOOL_TRUE,
+
   DTI_MAX
 };
 
@@ -480,6 +483,9 @@ extern GTY(()) tree d_global_trees[DTI_MAX];
 #define null_array_noded_global_trees[DTI_NULL_ARRAY]
 /* The bottom type, referred to as `noreturn` in code.  */
 #define noreturn_type_node d_global_trees[DTI_BOTTOM_TYPE]
+/* D boolean values are always byte-sized, unlike boolean_type_node.  */
+#define d_bool_false_node  d_global_trees[DTI_BOOL_FALSE]
+#define d_bool_true_node   d_global_trees[DTI_BOOL_TRUE]
 
 /* A prefix for internal variables, which are not user-visible.  */
 #if !defined (NO_DOT_IN_LABEL)
diff --git a/gcc/d/modules.cc b/gcc/d/modules.cc
index 8d6c8f0f9ad..e3c1ef9f82e 100644
--- a/gcc/d/modules.cc
+++ b/gcc/d/modules.cc
@@ -330,7 +330,7 @@ 

[Bug d/112270] ICE: in verify_gimple_in_seq on powerpc-darwin9

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

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

--- Comment #3 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Iain Buclaw
:

https://gcc.gnu.org/g:8362293229626e608afeca8008ad23ea07cda1e7

commit r12-9949-g8362293229626e608afeca8008ad23ea07cda1e7
Author: Iain Buclaw 
Date:   Sun Oct 29 00:27:49 2023 +0200

d: Fix ICE: in verify_gimple_in_seq on powerpc-darwin9 [PR112270]

This ICE was seen during stage2 on powerpc-darwin9 only.  There were
still some uses of GCC's boolean_type_node in the D front-end, which
caused a type mismatch to trigger as D bool size is fixed to 1 byte on
all targets.

So two new nodes have been introduced - d_bool_false_node and
d_bool_true_node - which have replaced all remaining uses of
boolean_false_node and boolean_true_node respectively.

PR d/112270

gcc/d/ChangeLog:

* d-builtins.cc (d_build_d_type_nodes): Initialize
d_bool_false_node,
d_bool_true_node.
* d-codegen.cc (build_array_struct_comparison): Use
d_bool_false_node
instead of boolean_false_node.
* d-convert.cc (d_truthvalue_conversion): Use d_bool_false_node and
d_bool_true_node instead of boolean_false_node and
boolean_true_node.
* d-tree.h (enum d_tree_index): Add DTI_BOOL_FALSE and
DTI_BOOL_TRUE.
(d_bool_false_node): New macro.
(d_bool_true_node): New macro.
* modules.cc (build_dso_cdtor_fn): Use d_bool_false_node and
d_bool_true_node instead of boolean_false_node and
boolean_true_node.
(register_moduleinfo): Use d_bool_type instead of
boolean_type_node.

gcc/testsuite/ChangeLog:

* gdc.dg/pr112270.d: New test.

(cherry picked from commit 10f1489dcb3bd9adccc88898bc12f53398fa3583)

[Bug d/112270] ICE: in verify_gimple_in_seq on powerpc-darwin9

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

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

--- Comment #2 from CVS Commits  ---
The releases/gcc-13 branch has been updated by Iain Buclaw
:

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

commit r13-7990-gab5c18d76497d52ade3c04c412060bc2d718d7ab
Author: Iain Buclaw 
Date:   Sun Oct 29 00:27:49 2023 +0200

d: Fix ICE: in verify_gimple_in_seq on powerpc-darwin9 [PR112270]

This ICE was seen during stage2 on powerpc-darwin9 only.  There were
still some uses of GCC's boolean_type_node in the D front-end, which
caused a type mismatch to trigger as D bool size is fixed to 1 byte on
all targets.

So two new nodes have been introduced - d_bool_false_node and
d_bool_true_node - which have replaced all remaining uses of
boolean_false_node and boolean_true_node respectively.

PR d/112270

gcc/d/ChangeLog:

* d-builtins.cc (d_build_d_type_nodes): Initialize
d_bool_false_node,
d_bool_true_node.
* d-codegen.cc (build_array_struct_comparison): Use
d_bool_false_node
instead of boolean_false_node.
* d-convert.cc (d_truthvalue_conversion): Use d_bool_false_node and
d_bool_true_node instead of boolean_false_node and
boolean_true_node.
* d-tree.h (enum d_tree_index): Add DTI_BOOL_FALSE and
DTI_BOOL_TRUE.
(d_bool_false_node): New macro.
(d_bool_true_node): New macro.
* modules.cc (build_dso_cdtor_fn): Use d_bool_false_node and
d_bool_true_node instead of boolean_false_node and
boolean_true_node.
(register_moduleinfo): Use d_bool_type instead of
boolean_type_node.

gcc/testsuite/ChangeLog:

* gdc.dg/pr112270.d: New test.

(cherry picked from commit 10f1489dcb3bd9adccc88898bc12f53398fa3583)

gcc-13-20231028 is now available

[GCC Administrator via Gcc]

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

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

You'll find:

 gcc-13-20231028.tar.xz   Complete GCC

  SHA256=10ee2194ad4b2bf7c06ddd2dcb89907af58ef4a3ea888f0ad7b9f91103228b02
  SHA1=226021dc18781c663ef2f91938c9ff52032a76c0

Diffs from 13-20231021 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-13
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 d/112270] ICE: in verify_gimple_in_seq on powerpc-darwin9

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

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Iain Buclaw :

https://gcc.gnu.org/g:10f1489dcb3bd9adccc88898bc12f53398fa3583

commit r14-4989-g10f1489dcb3bd9adccc88898bc12f53398fa3583
Author: Iain Buclaw 
Date:   Sun Oct 29 00:27:49 2023 +0200

d: Fix ICE: in verify_gimple_in_seq on powerpc-darwin9 [PR112270]

This ICE was seen during stage2 on powerpc-darwin9 only.  There were
still some uses of GCC's boolean_type_node in the D front-end, which
caused a type mismatch to trigger as D bool size is fixed to 1 byte on
all targets.

So two new nodes have been introduced - d_bool_false_node and
d_bool_true_node - which have replaced all remaining uses of
boolean_false_node and boolean_true_node respectively.

PR d/112270

gcc/d/ChangeLog:

* d-builtins.cc (d_build_d_type_nodes): Initialize
d_bool_false_node,
d_bool_true_node.
* d-codegen.cc (build_array_struct_comparison): Use
d_bool_false_node
instead of boolean_false_node.
* d-convert.cc (d_truthvalue_conversion): Use d_bool_false_node and
d_bool_true_node instead of boolean_false_node and
boolean_true_node.
* d-tree.h (enum d_tree_index): Add DTI_BOOL_FALSE and
DTI_BOOL_TRUE.
(d_bool_false_node): New macro.
(d_bool_true_node): New macro.
* modules.cc (build_dso_cdtor_fn): Use d_bool_false_node and
d_bool_true_node instead of boolean_false_node and
boolean_true_node.
(register_moduleinfo): Use d_bool_type instead of
boolean_type_node.

gcc/testsuite/ChangeLog:

* gdc.dg/pr112270.d: New test.

[Bug libstdc++/107885] H8/300: libsupc++/hash_bytes.cc fix shift-count-overflow warning

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org
 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #3 from Jeffrey A. Law  ---
No plans to backport this.

[Bug tree-optimization/112113] [14 Regression] wrong code at -O3 on x86_64-linux-gnu

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

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

--- Comment #3 from Thomas Koenig  ---
(In reply to Thomas Koenig from comment #2)
> According to bisection, f5fb9ff2396fd41fdd2e6d35a412e936d2d42f75
> is the first bad commit.

Or, if anybody wants a link,
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=f5fb9ff2396fd41fdd2e6d35a412e936d2d42f75
.

[Bug tree-optimization/112113] [14 Regression] wrong code at -O3 on x86_64-linux-gnu

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

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

Thomas Koenig  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #2 from Thomas Koenig  ---
According to bisection, f5fb9ff2396fd41fdd2e6d35a412e936d2d42f75
is the first bad commit.

[Bug tree-optimization/112271] Some `(a == CST) ? a OP b : CST` is not done in match

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

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

--- Comment #2 from Andrew Pinski  ---
the others:
```
int f_lshift(int a, int b)
{
  int c = b>>a;
  int d;
  if (b == 0) d = c; else d = 0;
  return d;
}
int f_div(int a, int b)
{
  a = 2; // Just needs to be non-negative
  int c = b/a;
  int d;
  if (b == 0) d = c; else d = 0;
  return d;
}
```

[Bug tree-optimization/112271] Some `(a == CST) ? a OP b : CST` is not done in match

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

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

--- Comment #1 from Andrew Pinski  ---
Actually this is basically moving absorbing_element_p to match.

[Bug tree-optimization/112271] Some `(a == CST) ? a OP b : CST` is not done in match

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2023-10-28
 Status|UNCONFIRMED |ASSIGNED
   Severity|normal  |enhancement
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org

[Bug tree-optimization/112271] New: Some `(a == CST) ? a OP b : CST` is not done in match

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

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

Bug ID: 112271
   Summary: Some `(a == CST) ? a OP b : CST` is not done in match
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

Take:
```
/* 
a == -1 ? a | b : -1 -> -1
*/
int f_or(int a, int b)
{
  int c = b|a;
  int d;
  if (a == -1) d = c; else d = -1;
  return d;
}
/* 
a == 0 ? a * b : 0 -> 0
*/
int f_mult(int a, int b)
{
  int c = b*a;
  int d;
  if (a == 0) d = c; else d = 0;
  return d;
}
/* 
a == 0 ? a & b : 0 -> 0
*/
int f_and(int a, int b)
{
  int c = b
  int d;
  if (a == 0) d = c; else d = 0;
  return d;
}

```
These all should be done in match. They are currently handled by the ranger
code (either via dom2 or evrp). Matching it in match would allow it to be
caught earlier for -O1 and might allow for some other cases later on.

Recording this here for now so I don't forget to add them ...

[Bug c++/110075] Bogus -Wdangling-reference

[roystgnr at gmail dot com via Gcc-bugs]

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

Roy Stogner  changed:

   What|Removed |Added

 CC||roystgnr at gmail dot com

--- Comment #2 from Roy Stogner  ---
This case looks most similar to the one that my code triggered, which I
simplified to the following:

---

#include 

const double &
find_wrapper(const std::map & map,
 const int & key)
{
  auto it = map.find(key);
  return it->second;
}


int main(void)
{
  std::map testmap{{1,0.0}};
  const double & d = find_wrapper(testmap, 1);
  return int(d);
}

---

$ g++ -Wall -Wextra -Werror -o test.x test.C
test.C: In function ‘int main()’:
test.C:15:18: error: possibly dangling reference to a temporary
[-Werror=dangling-reference]
   15 |   const double & d = find_wrapper(testmap, 1);
  |  ^
test.C:15:34: note: the temporary was destroyed at the end of the full
expression ‘find_wrapper(testmap, 1)’
   15 |   const double & d = find_wrapper(testmap, 1);
  |  ^~~~
cc1plus: all warnings being treated as errors

---

If I change the parameter type to `const int key`, then the warning is not
triggered.  If I leave the parameter type as a reference but I pass in a
non-temporary variable "one" instead of "1", then the warning is not triggered.


Either or both of these cases might be a dup of bug 109642

[Bug target/93877] [11/12/13/14 Regression] [SH] webkit2gtk fails to build with "internal compiler error: in extract_constrain_insn, at recog.c:2211"

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #22 from John Paul Adrian Glaubitz  ---
(In reply to Andrew Pinski from comment #21)
> (In reply to John Paul Adrian Glaubitz from comment #20)
> > I don't think this is a duplicate. This one is supposed to be without -mlra.
> 
> All of the comments here talk about -mlra and even that one all of the
> comments talk about using -mlra .

I should probably recheck all the issues I reported whether they still affect
gcc-13 or trunk. Some of my reports are quite old.

[Bug target/93877] [11/12/13/14 Regression] [SH] webkit2gtk fails to build with "internal compiler error: in extract_constrain_insn, at recog.c:2211"

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

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

--- Comment #21 from Andrew Pinski  ---
(In reply to John Paul Adrian Glaubitz from comment #20)
> I don't think this is a duplicate. This one is supposed to be without -mlra.

All of the comments here talk about -mlra and even that one all of the comments
talk about using -mlra .

[Bug d/112270] New: ICE: in verify_gimple_in_seq on powerpc-darwin9

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

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

Bug ID: 112270
   Summary: ICE: in verify_gimple_in_seq on powerpc-darwin9
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: ibuclaw at gcc dot gnu.org
  Target Milestone: ---

Mismatching D and C boolean types causes ICE on powerpc-darwin.

---../../gcc/d/dmd/cppmangle.d: In function ‘isNamespaceEqual’:
../../gcc/d/dmd/cppmangle.d:2354:14: error: non-trivial conversion in
‘integer_cst’
 2354 | private bool isNamespaceEqual (CPPNamespaceDeclaration a,
CPPNamespaceDeclaration b) @safe
  |  ^
bool

iftmp.120 = 1;
../../gcc/d/dmd/cppmangle.d:2354:14: internal compiler error: ‘verify_gimple’
failed
0x118c5a5 verify_gimple_in_seq(gimple*, bool)
../../gcc/tree-cfg.cc:5297
0xe4192b gimplify_body(tree_node*, bool)
../../gcc/gimplify.cc:18046
0xe41a9f gimplify_function_tree(tree_node*)
../../gcc/gimplify.cc:18162
0xc571f7 cgraph_node::analyze()
../../gcc/cgraphunit.cc:684
0xc598d7 analyze_functions
../../gcc/cgraphunit.cc:1247
0xc5a621 symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.cc:2554
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.
../../gcc/d/dmd/cppmangle.d failed
---


Minimal reproducer:
---
class CPPNamespaceDeclaration { }
bool isNamespaceEqual (CPPNamespaceDeclaration a)
{
return a ? true : isNamespaceEqual(a);
}

[Bug d/103578] d21 doesn't link on Darwin/i386

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

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

ibuclaw at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
 CC||ibuclaw at gcc dot gnu.org

--- Comment #1 from ibuclaw at gcc dot gnu.org ---
This was fixed in r12-8302.

[Bug target/93877] [11/12/13/14 Regression] [SH] webkit2gtk fails to build with "internal compiler error: in extract_constrain_insn, at recog.c:2211"

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #20 from John Paul Adrian Glaubitz  ---
(In reply to Andrew Pinski from comment #19)
> Dup of bug 83464.
> 
> *** This bug has been marked as a duplicate of bug 83464 ***

I don't think this is a duplicate. This one is supposed to be without -mlra.

[Bug c++/112269] [14 Regression] x86_64 GNU/Linux '-m32' multilib 'libstdc++-v3/include/complex:1493: internal compiler error: in tsubst_expr, at cp/pt.cc:21534'

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

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

--- Comment #1 from Andrew Pinski  ---
I suspect this is excess-precision related.

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

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

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

--- Comment #1 from Jonathan Wakely  ---
I'm not sure if this is a libstdc++ problem or should be component=libbacktrace

[Bug c++/112269] [14 Regression] x86_64 GNU/Linux '-m32' multilib 'libstdc++-v3/include/complex:1493: internal compiler error: in tsubst_expr, at cp/pt.cc:21534'

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |14.0

[Bug libstdc++/112097] _PSTL_EARLYEXIT_PRESENT macro doesn't correctly identify intel compilers.

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

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

--- Comment #3 from Jonathan Wakely  ---
I hope the Intel devs got it right :)

[Bug c++/112269] New: [14 Regression] x86_64 GNU/Linux '-m32' multilib 'libstdc++-v3/include/complex:1493: internal compiler error: in tsubst_expr, at cp/pt.cc:21534'

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

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

Bug ID: 112269
   Summary: [14 Regression] x86_64 GNU/Linux '-m32' multilib
'libstdc++-v3/include/complex:1493: internal compiler
error: in tsubst_expr, at cp/pt.cc:21534'
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code, testsuite-fail
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
  Target Milestone: ---

(Assuming my tacking is to be believed) something in Git commit
r14-4720-gaf4bb221153359f5948da917d5ef2df738bb1e61..r14-4986-g4d3d2cdb574488223d023b590c3a34ddd93f4dae
ICE-regresses a few x86_64 GNU/Linux '-m32' multilib test cases:

[-PASS:-]{+FAIL:+} 24_iterators/reverse_iterator/100639.cc  -std=c++20
(test for excess errors)
[-PASS:-]{+FAIL:+} 24_iterators/reverse_iterator/100639.cc  -std=c++26
(test for excess errors)

In file included from
[...]/build-gcc/x86_64-pc-linux-gnu/32/libstdc++-v3/include/ccomplex:39,
 from
[...]/build-gcc/x86_64-pc-linux-gnu/32/libstdc++-v3/include/x86_64-pc-linux-gnu/bits/stdc++.h:127,
 from :
[...]/build-gcc/x86_64-pc-linux-gnu/32/libstdc++-v3/include/complex: In
member function 'constexpr std::complex&
std::complex::operator/=(const std::complex<_Tp>&)':
[...]/build-gcc/x86_64-pc-linux-gnu/32/libstdc++-v3/include/complex:1493:
internal compiler error: in tsubst_expr, at cp/pt.cc:21534
0x784e58 tsubst_expr(tree_node*, tree_node*, int, tree_node*)
[...]/source-gcc/gcc/cp/pt.cc:21534
0xf03edb fold_non_dependent_expr_template
[...]/source-gcc/gcc/cp/constexpr.cc:9030
0xfa17ed fold_for_warn(tree_node*)
[...]/source-gcc/gcc/cp/expr.cc:412
0x1144377 cp_build_binary_op(op_location_t const&, tree_code, tree_node*,
tree_node*, int)
[...]/source-gcc/gcc/cp/typeck.cc:5436
0x11525b3 cp_build_modify_expr(unsigned int, tree_node*, tree_code,
tree_node*, int)
[...]/source-gcc/gcc/cp/typeck.cc:9522
0xec5c4d build_new_op(op_location_t const&, tree_code, int, tree_node*,
tree_node*, tree_node*, tree_node*, tree_node**, int)
[...]/source-gcc/gcc/cp/call.cc:7312
0x11536a5 build_x_modify_expr(unsigned int, tree_node*, tree_code,
tree_node*, tree_node*, int)
[...]/source-gcc/gcc/cp/typeck.cc:9728
0x103f464 cp_parser_assignment_expression
[...]/source-gcc/gcc/cp/parser.cc:10611
0x103f6b4 cp_parser_expression
[...]/source-gcc/gcc/cp/parser.cc:10740
0x10441c7 cp_parser_expression_statement
[...]/source-gcc/gcc/cp/parser.cc:12939
0x10504ea cp_parser_statement
[...]/source-gcc/gcc/cp/parser.cc:12719
0x10517f7 cp_parser_statement_seq_opt
[...]/source-gcc/gcc/cp/parser.cc:13188
0x1051a27 cp_parser_compound_statement
[...]/source-gcc/gcc/cp/parser.cc:13042
0x1073d95 cp_parser_function_body
[...]/source-gcc/gcc/cp/parser.cc:25560
0x1073d95 cp_parser_ctor_initializer_opt_and_function_body
[...]/source-gcc/gcc/cp/parser.cc:25611
0x107a1ae cp_parser_function_definition_after_declarator
[...]/source-gcc/gcc/cp/parser.cc:32273
0x107a634 cp_parser_late_parsing_for_member
[...]/source-gcc/gcc/cp/parser.cc:33241
0x104c3e4 cp_parser_class_specifier
[...]/source-gcc/gcc/cp/parser.cc:26761
0x104c3e4 cp_parser_type_specifier
[...]/source-gcc/gcc/cp/parser.cc:19725
0x104cb6b cp_parser_decl_specifier_seq
[...]/source-gcc/gcc/cp/parser.cc:16283

Similarly:

[-PASS:-]{+FAIL:+} std/ranges/iota/93267.cc  -std=c++20 (test for excess
errors)
[-PASS:-]{+FAIL:+} std/ranges/iota/93267.cc  -std=c++26 (test for excess
errors)

[-PASS:-]{+FAIL:+} std/ranges/iota/96042.cc  -std=c++20 (test for excess
errors)
[-PASS:-]{+FAIL:+} std/ranges/iota/96042.cc  -std=c++26 (test for excess
errors)

[-PASS:-]{+FAIL:+} std/ranges/iota/size.cc  -std=c++20 (test for excess
errors)
[-PASS:-]{+FAIL:+} std/ranges/iota/size.cc  -std=c++26 (test for excess
errors)

[-PASS:-]{+FAIL:+} std/ranges/subrange/96042.cc  -std=c++20 (test for
excess errors)
[-PASS:-]{+FAIL:+} std/ranges/subrange/96042.cc  -std=c++26 (test for
excess errors)

Re: [PATCH] tree-optimization/109334: Improve computation for access attribute

[Martin Uecker]

Thanks, Sid!

(one comment below)

Am Donnerstag, dem 26.10.2023 um 07:51 -0400 schrieb Siddhesh Poyarekar:
> On 2023-10-26 04:37, Martin Uecker wrote:

> 
> > /* ... and either PARM is void * or has a type that is complete and 
> > has a
> >  constant size... */
> > && ((typesize && poly_int_tree_p (typesize))
> > @@ -1587,10 +1587,14 @@ parm_object_size (struct object_size_info *osi, 
> > tree var)
> > unsigned argpos = 0;
> >   
> > /* ... then walk through the parameters to pick the size parameter 
> > and
> > -safely scale it by the type size if needed.  */
> > +safely scale it by the type size if needed.
> > +
> > +TODO: we could also compute the size of VLAs where the size is
> > +given by a function parameter.  */
> 
> Isn't this testcase h() in builtin-dynamic-object-size-20.c?  If you're 
> referring to testcase i(), then maybe "where the size is given by a 
> non-trivial function of a function parameter, e.g.
> fn (size_t n, char buf[dummy(n)])."

h() is supported.  For i() we would need something as
__builtin_access__with_size to record the result of dummy().

But the comment refers to the simpler case:

fn (size_t n, char (*buf)[n])
[[gnu::access(read_write, 2, 1)]]

This doesn't work because buf[n] does not have constant
size, but it could be made to work more easily because
the size is directly given by a function argument.

Martin


> 
> > for (arg = fnargs; arg; arg = TREE_CHAIN (arg), ++argpos)
> > -   if (argpos == access->sizarg && INTEGRAL_TYPE_P (TREE_TYPE (arg)))
> > +   if (argpos == access->sizarg)
> >   {
> > +   gcc_assert (INTEGRAL_TYPE_P (TREE_TYPE (arg)));
> > sz = get_or_create_ssa_default_def (cfun, arg);
> > if (sz != NULL_TREE)
> >   {
> > 
> 
> We rely on the frontend to make sure that the arg at sizarg is an 
> integral type.  OK.
> 
> Overall the change looks OK with a few nits I pointed out above.
> 
> Thanks,
> Sid

[Bug rtl-optimization/112268] New: AVR-GCC generates suboptimal code for bit shifts

[anton at tchekov dot net via Gcc-bugs]

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

Bug ID: 112268
   Summary: AVR-GCC generates suboptimal code for bit shifts
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anton at tchekov dot net
  Target Milestone: ---

This function:

uint8_t extract1(uint32_t val)
{
return val >> 26;
}

generates the following assembly code, which shifts all four registers 26 times
in a loop.
It is exactly the same on optimization levels O2, O3 and Os. (The exact shift
amounts are not important)

extract1:
mov r27,r25
mov r26,r24
mov r25,r23
mov r24,r22
ldi r18,26
1:
lsr r27
ror r26
ror r25
ror r24
dec r18
brne 1b
ret

It is possible to do a lot better with this workaround which uses only 3
instructions:
(and is exactly equivalent)

uint8_t extract2(uint32_t val)
{
uint8_t tmp = val >> 24;
return tmp >> 2;
}

extract2:
mov r24,r25
lsr r24
lsr r24
ret

The "shift loop" only happens with 32-bit integers, but not with 16-bit, where
the optimization opportunity is recognized:

uint8_t extract3(uint16_t val)
{
return val >> 9;
}

extract3:
mov r24,r25
lsr r24
ret

[Bug c++/112267] New: "inline function constexpr used but never defined" warning in SFINAE context

[falemagn at gmail dot com via Gcc-bugs]

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

Bug ID: 112267
   Summary: "inline function constexpr used but never defined"
warning in SFINAE context
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: falemagn at gmail dot com
  Target Milestone: ---

I am expecting no warnings from the following code snippets, especially because
SFINAE is being correctly triggered, and indeed clang doesn't provide one for
the specific case at hand, alas g++ does.

I am left wondering whether this is a bug or a "overreaction". The warning
itself cannot be turned off with a pragma.

#if defined(__clang__)
_Pragma("GCC diagnostic ignored \"-Wundefined-inline\"");   
#endif

#define DEFINE_FUNC 0

constexpr bool func()
#if DEFINE_FUNC
{
return true;
}
#else
;
#endif

template 
constexpr bool is_defined(int) {
return true;
}


template 
constexpr bool is_defined(double) {
return false;
}

int a = is_defined(0);

See it working on Compiler Explorer: https://godbolt.org/z/dvTKdGfbv

[Bug target/112265] [14 Regression] GCN offloading 'libgomp.c-c++-common/for-5.c': 'internal compiler error: maximum number of generated reload insns per insn achieved (90)'

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |14.0

--- Comment #2 from Andrew Pinski  ---
(In reply to Thomas Schwinge from comment #1)
> The ICE goes away if I revert PR111000 commit
> r14-4786-gd118738e71cf4615f170fff8dabe66442206d008 "tree-optimization/111000
> - restrict invariant motion of shifts".  What that now tells us I have no
> clue.

That it was a latent bug; I wonder if there is a way to expose it before that
patch. Maybe a GIMPLE testcase ...

[Bug target/112265] [14 Regression] GCN offloading 'libgomp.c-c++-common/for-5.c': 'internal compiler error: maximum number of generated reload insns per insn achieved (90)'

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

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

Thomas Schwinge  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #1 from Thomas Schwinge  ---
The ICE goes away if I revert PR111000 commit
r14-4786-gd118738e71cf4615f170fff8dabe66442206d008 "tree-optimization/111000 -
restrict invariant motion of shifts".  What that now tells us I have no clue.

[PATCH,resend] hurd: Ad default-pie and static-pie support

[Samuel Thibault]

This fixes the Hurd spec in the default-pie case, and adds static-pie
support.

gcc/ChangeLog:

* gcc/config/i386/gnu.h: Use PIE_SPEC, add static-pie case.
* gcc/config/i386/gnu64.h: Use PIE_SPEC, add static-pie case.

diff --git a/gcc/config/i386/gnu.h b/gcc/config/i386/gnu.h
index 8dc6d9ee4e3..e776144f96c 100644
--- a/gcc/config/i386/gnu.h
+++ b/gcc/config/i386/gnu.h
@@ -27,12 +27,12 @@ along with GCC.  If not, see .
 #undef STARTFILE_SPEC
 #if defined HAVE_LD_PIE
 #define STARTFILE_SPEC \
-  "%{!shared: 
%{pg|p|profile:%{static:gcrt0.o%s;:gcrt1.o%s};pie:Scrt1.o%s;static:crt0.o%s;:crt1.o%s}}
 \
-   crti.o%s %{static:crtbeginT.o%s;shared|pie:crtbeginS.o%s;:crtbegin.o%s}"
+  "%{!shared: 
%{pg|p|profile:%{static-pie:grcrt0.o%s;static:gcrt0.o%s;:gcrt1.o%s};static-pie:rcrt0.o%s;static:crt0.o%s;"
 PIE_SPEC ":Scrt1.o%s;:crt1.o%s}} \
+   crti.o%s %{static:crtbeginT.o%s;shared|static-pie|" PIE_SPEC 
":crtbeginS.o%s;:crtbegin.o%s}"
 #else
 #define STARTFILE_SPEC \
   "%{!shared: 
%{pg|p|profile:%{static:gcrt0.o%s;:gcrt1.o%s};static:crt0.o%s;:crt1.o%s}} \
-   crti.o%s %{static:crtbeginT.o%s;shared|pie:crtbeginS.o%s;:crtbegin.o%s}"
+   crti.o%s %{static:crtbeginT.o%s;shared:crtbeginS.o%s;:crtbegin.o%s}"
 #endif
 
 #ifdef TARGET_LIBC_PROVIDES_SSP
diff --git a/gcc/config/i386/gnu64.h b/gcc/config/i386/gnu64.h
index a411f0e802a..332372fa067 100644
--- a/gcc/config/i386/gnu64.h
+++ b/gcc/config/i386/gnu64.h
@@ -31,10 +31,10 @@ along with GCC.  If not, see .
 #undef STARTFILE_SPEC
 #if defined HAVE_LD_PIE
 #define STARTFILE_SPEC \
-  "%{!shared: 
%{pg|p|profile:%{static:gcrt0.o%s;:gcrt1.o%s};pie:Scrt1.o%s;static:crt0.o%s;:crt1.o%s}}
 \
-   crti.o%s %{static:crtbeginT.o%s;shared|pie:crtbeginS.o%s;:crtbegin.o%s}"
+  "%{!shared: 
%{pg|p|profile:%{static-pie:grcrt0.o%s;static:gcrt0.o%s;:gcrt1.o%s};static-pie:rcrt0.o%s;static:crt0.o%s;"
 PIE_SPEC ":Scrt1.o%s;:crt1.o%s}} \
+   crti.o%s %{static:crtbeginT.o%s;shared|static-pie|" PIE_SPEC 
":crtbeginS.o%s;:crtbegin.o%s}"
 #else
 #define STARTFILE_SPEC \
   "%{!shared: 
%{pg|p|profile:%{static:gcrt0.o%s;:gcrt1.o%s};static:crt0.o%s;:crt1.o%s}} \
-   crti.o%s %{static:crtbeginT.o%s;shared|pie:crtbeginS.o%s;:crtbegin.o%s}"
+   crti.o%s %{static:crtbeginT.o%s;shared|static-pie|" PIE_SPEC 
":crtbeginS.o%s;:crtbegin.o%s}"
 #endif

[PATCH,resend] hurd: Add multilib paths for gnu-x86_64

[Samuel Thibault]

We need the multilib paths in gcc to find e.g. glibc crt files on
Debian.  This is essentially based on t-linux64 version.

gcc/ChangeLog:

* gcc/config/i386/t-gnu64: New file.
* gcc/config.gcc [x86_64-*-gnu*): Add i386/t-gnu64 to
tmake_file.

diff --git a/gcc/config.gcc b/gcc/config.gcc
index 671c7e3b018..6b1939b9f09 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -5828,6 +5828,9 @@ case ${target} in
visium-*-*)
target_cpu_default2="TARGET_CPU_$with_cpu"
;;
+   x86_64-*-gnu*)
+   tmake_file="$tmake_file i386/t-gnu64"
+   ;;
 esac
 
 t=
diff --git a/gcc/config/i386/t-gnu64 b/gcc/config/i386/t-gnu64
index e69de29bb2d..23ee6823d65 100644
--- a/gcc/config/i386/t-gnu64
+++ b/gcc/config/i386/t-gnu64
@@ -0,0 +1,38 @@
+# Copyright (C) 2002-2023 Free Software Foundation, Inc.
+#
+# This file is part of GCC.
+#
+# GCC is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3, or (at your option)
+# any later version.
+#
+# GCC is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with GCC; see the file COPYING3.  If not see
+# .
+
+# On Debian, Ubuntu and other derivative distributions, the 32bit libraries
+# are found in /lib32 and /usr/lib32, /lib64 and /usr/lib64 are symlinks to
+# /lib and /usr/lib, while other distributions install libraries into /lib64
+# and /usr/lib64.  The LSB does not enforce the use of /lib64 and /usr/lib64,
+# it doesn't tell anything about the 32bit libraries on those systems.  Set
+# MULTILIB_OSDIRNAMES according to what is found on the target.
+
+# To support i386, x86-64 and x32 libraries, the directory structrue
+# should be:
+#
+#  /lib has i386 libraries.
+#  /lib64 has x86-64 libraries.
+#  /libx32 has x32 libraries.
+#
+comma=,
+MULTILIB_OPTIONS= $(subst $(comma),/,$(TM_MULTILIB_CONFIG))
+MULTILIB_DIRNAMES   = $(patsubst m%, %, $(subst /, ,$(MULTILIB_OPTIONS)))
+MULTILIB_OSDIRNAMES = m64=../lib64$(call if_multiarch,:x86_64-gnu)
+MULTILIB_OSDIRNAMES+= m32=$(if $(wildcard $(shell echo 
$(SYSTEM_HEADER_DIR))/../../usr/lib32),../lib32,../lib)$(call 
if_multiarch,:i386-gnu)
+MULTILIB_OSDIRNAMES+= mx32=../libx32$(call if_multiarch,:x86_64-gnux32)

[RFC PATCH v1] c: Do not warn about external declaration following inline definition

[Barnabás Pőcze]

An external declaration following an inline definition is not redundant
because it forces the compiler to emit an external definition for the function.
That is,

  inline void f(void) { }
  [extern] void f(void);

should not trigger the

  redundant redeclaration of ...

warning.

gcc/c/ChangeLog:

* c-decl.cc (diagnose_mismatched_decls): Add new
case for Wredundant-decls suppression.
---
 gcc/c/c-decl.cc | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/gcc/c/c-decl.cc b/gcc/c/c-decl.cc
index 7a145bed281..e86f7950858 100644
--- a/gcc/c/c-decl.cc
+++ b/gcc/c/c-decl.cc
@@ -2592,7 +2592,12 @@ diagnose_mismatched_decls (tree newdecl, tree olddecl,
   && TREE_ASM_WRITTEN (olddecl) && !TREE_ASM_WRITTEN (newdecl))
   /* Don't warn about a variable definition following a declaration.  */
   && !(VAR_P (newdecl)
-  && DECL_INITIAL (newdecl) && !DECL_INITIAL (olddecl)))
+  && DECL_INITIAL (newdecl) && !DECL_INITIAL (olddecl))
+  /* Don't warn about external declaration following inline definition.  */
+  && !(TREE_CODE (newdecl) == FUNCTION_DECL
+  && !DECL_INITIAL (newdecl) && !DECL_DECLARED_INLINE_P (newdecl)
+  && DECL_EXTERNAL (newdecl) && DECL_INITIAL (olddecl)
+  && DECL_DECLARED_INLINE_P (olddecl) && DECL_EXTERNAL (olddecl)))
 {
   warned = warning (OPT_Wredundant_decls, "redundant redeclaration of 
%q+D",
newdecl);
-- 
2.42.0

[Bug tree-optimization/112266] New: `constcall(a)` and `constcall(>b[0])` is not being optimized to one call

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

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

Bug ID: 112266
   Summary: `constcall(a)` and `constcall(>b[0])` is not being
optimized to one call
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

Take:
```
struct a
{
int b[1];
};

[[gnu::const]]
int constcall(int *a);

int f(struct a *b)
{
  int *c = b->b;
  int *d = (int*)b;
  int t = constcall(c);
  int t1 = constcall(d);
  return t+t1;
}

```

There should only be one call to constcall since the argument is the exact same
value just represented slightly different in the IR.

[Bug target/93877] [11/12/13/14 Regression] [SH] webkit2gtk fails to build with "internal compiler error: in extract_constrain_insn, at recog.c:2211"

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #19 from Andrew Pinski  ---
Dup of bug 83464.

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

[Bug target/83464] [SH] ICE: in final_scan_insn, at final.c:3025 with -mlra

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

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

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

[Bug target/112115] SH4 ICE: in extract_constrain_insn, at recog.cc:2692 with -mlra (VMUBEEP)

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

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

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

[Bug target/112114] SH4 ICE: in extract_constrain_insn, at recog.cc:2692 with -mlra (2NDMIX)

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

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

[Bug tree-optimization/112123] Missed optimization of loop deletion because loop invariants are not identified

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug target/112115] SH4 ICE: in extract_constrain_insn, at recog.cc:2692 with -mlra (VMUBEEP)

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

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

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

[Bug target/112122] SH4 ICE: in extract_constrain_insn, at recog.cc:2692 with -mlra (TSUNAMI_FONT)

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Likewise.

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

[Bug target/112115] SH4 ICE: in extract_constrain_insn, at recog.cc:2692 with -mlra (VMUBEEP)

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

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

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

[Bug target/112115] SH4 ICE: in extract_constrain_insn, at recog.cc:2692 with -mlra (VMUBEEP)

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

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

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

[Bug target/112121] SH4 ICE: in extract_constrain_insn, at recog.cc:2692 with -mlra (FNT_TEST)

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

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

[Bug target/112120] SH4 ICE: in extract_constrain_insn, at recog.cc:2692 with -mlra (GLTEST)

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Likewise.

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

[Bug target/112115] SH4 ICE: in extract_constrain_insn, at recog.cc:2692 with -mlra (VMUBEEP)

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

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

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

[Bug target/112119] SH4 ICE: in extract_constrain_insn, at recog.cc:2692 with -mlra (RUMBLE)

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Likewise.

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

[Bug target/112115] SH4 ICE: in extract_constrain_insn, at recog.cc:2692 with -mlra (VMUBEEP)

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

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

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

[Bug target/112118] SH4 ICE: in extract_constrain_insn, at recog.cc:2692 with -mlra (GHETTOPLAY)

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Both issues are the same underlying issue.

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

[ARC PATCH] Convert (signed<<31)>>31 to -(signed&1) without barrel shifter.

[Roger Sayle]

This patch optimizes PR middle-end/101955 for the ARC backend.  On ARC
CPUs with a barrel shifter, using two shifts is (probably) optimal as:

asl_s   r0,r0,31
asr_s   r0,r0,31

but without a barrel shifter, GCC -O2 -mcpu=em currently generates:

and r2,r0,1
ror r2,r2
add.f   0,r2,r2
sbc r0,r0,r0

with this patch, we now generate the smaller, faster and non-flags
clobbering:

bmsk_s  r0,r0,0
neg_s   r0,r0

Tested with a cross-compiler to arc-linux hosted on x86_64,
with no new (compile-only) regressions from make -k check.
Ok for mainline if this passes Claudiu's nightly testing?


2023-10-28  Roger Sayle  

gcc/ChangeLog
PR middle-end/101955
* config/arc/arc.md (*extvsi_1_0): New define_insn_and_split
to convert sign extract of the least significant bit into an
AND $1 then a NEG when !TARGET_BARREL_SHIFTER.

gcc/testsuite/ChangeLog
PR middle-end/101955
* gcc.target/arc/pr101955.c: New test case.


Thanks again,
Roger
--

diff --git a/gcc/config/arc/arc.md b/gcc/config/arc/arc.md
index ee43887..6471344 100644
--- a/gcc/config/arc/arc.md
+++ b/gcc/config/arc/arc.md
@@ -5873,6 +5873,20 @@ archs4x, archs4xd"
   (zero_extract:SI (match_dup 1) (match_dup 5) (match_dup 
7)))])
(match_dup 1)])
 
+;; Split sign-extension of single least significant bit as and x,$1;neg x
+(define_insn_and_split "*extvsi_1_0"
+  [(set (match_operand:SI 0 "register_operand" "=r")
+   (sign_extract:SI (match_operand:SI 1 "register_operand" "0")
+(const_int 1)
+(const_int 0)))]
+  "!TARGET_BARREL_SHIFTER"
+  "#"
+  "&& 1"
+  [(set (match_dup 0) (and:SI (match_dup 1) (const_int 1)))
+   (set (match_dup 0) (neg:SI (match_dup 0)))]
+  ""
+  [(set_attr "length" "8")])
+
 (define_insn_and_split "rotlsi3_cnt1"
   [(set (match_operand:SI 0 "dest_reg_operand""=r")
(rotate:SI (match_operand:SI 1 "register_operand" "r")
diff --git a/gcc/testsuite/gcc.target/arc/pr101955.c 
b/gcc/testsuite/gcc.target/arc/pr101955.c
new file mode 100644
index 000..74bca3c
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arc/pr101955.c
@@ -0,0 +1,10 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -mcpu=em" } */
+
+int f(int a)
+{
+return (a << 31) >> 31;
+}
+
+/* { dg-final { scan-assembler "msk_s\\s+r0,r0,0" } } */
+/* { dg-final { scan-assembler "neg_s\\s+r0,r0" } } */

[Bug target/112265] New: [14 Regression] GCN offloading 'libgomp.c-c++-common/for-5.c': 'internal compiler error: maximum number of generated reload insns per insn achieved (90)'

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

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

Bug ID: 112265
   Summary: [14 Regression] GCN offloading
'libgomp.c-c++-common/for-5.c': 'internal compiler
error: maximum number of generated reload insns per
insn achieved (90)'
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code, openmp, testsuite-fail
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: ams at gcc dot gnu.org, jules at gcc dot gnu.org
  Target Milestone: ---
Target: GCN

(Assuming my tacking is to be believed) something in Git commit
r14-4720-gaf4bb221153359f5948da917d5ef2df738bb1e61..r14-4986-g4d3d2cdb574488223d023b590c3a34ddd93f4dae
regressed GCN offloading 'libgomp.c-c++-common/for-5.c' both C and C++
compilation:

[-PASS:-]{+FAIL: libgomp.c/../libgomp.c-c++-common/for-5.c (internal
compiler error: maximum number of generated reload insns per insn achieved
(90))+}
{+FAIL:+} libgomp.c/../libgomp.c-c++-common/for-5.c (test for excess
errors)
[-PASS:-]{+UNRESOLVED:+} libgomp.c/../libgomp.c-c++-common/for-5.c
[-execution test-]{+compilation failed to produce executable+}

[-PASS:-]{+FAIL: libgomp.c++/../libgomp.c-c++-common/for-5.c (internal
compiler error: maximum number of generated reload insns per insn achieved
(90))+}
{+FAIL:+} libgomp.c++/../libgomp.c-c++-common/for-5.c (test for excess
errors)
[-PASS:-]{+UNRESOLVED:+} libgomp.c++/../libgomp.c-c++-common/for-5.c
[-execution test-]{+compilation failed to produce executable+}

All of '-march=fiji', '-march=gfx900', '-march=gfx906', '-march=gfx908',
'-march=gfx90a' are affected.

[Bug libgomp/112264] New: Occasionally (but very rare): 'FAIL: libgomp.fortran/target-nowait-array-section.f90 -O execution test'

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

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

Bug ID: 112264
   Summary: Occasionally (but very rare): 'FAIL:
libgomp.fortran/target-nowait-array-section.f90   -O
execution test'
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: openmp, testsuite-fail
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: burnus at gcc dot gnu.org, jakub at gcc dot gnu.org
  Target Milestone: ---

As reported in

"OpenMP/Fortran: Use firstprivat not alloc for ptr attach for arrays" almost a
year ago:

| For non-offloading x86_64-pc-linux-gnu '-m32', I'm occasionally (but very
| rarely!) seeing ['libgomp.fortran/target-nowait-array-section.f90']
| FAIL its execution test.  Similar can also
| be seen on occasional reports via ,
| .

..., and Jakub's report in
 "libgomp: Fix comment
typo".

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

[vincenzo.innocente at cern dot ch via Gcc-bugs]

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

Bug ID: 112263
   Summary: [C++23] std::stacktrace does not identify symbols in
shared library
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vincenzo.innocente at cern dot ch
  Target Milestone: ---

using 
gcc version 14.0.0 20231028 (experimental) [master r14-4988-g5d2a360f0a5] (GCC)
that contains the fix for #111936

This simple example  [1]
when run as a single executable prints all symbols in the stacktrace
when the nested functions are in a shared library their names are missing
c++ -std=c++23 testStacktrace.cpp -lstdc++exp -g -DINMAIN -DINLIB ; ./a.out
   0# nested_func2(int) at
/afs/cern.ch/user/i/innocent/public/ctest/testStacktrace.cpp:13
   1# nested_func(int) at
/afs/cern.ch/user/i/innocent/public/ctest/testStacktrace.cpp:18
   2# func(int) at
/afs/cern.ch/user/i/innocent/public/ctest/testStacktrace.cpp:26
   3# main at /afs/cern.ch/user/i/innocent/public/ctest/testStacktrace.cpp:31
   4#  at :0
   5# _start at :0
   6#


c++ -std=c++23 testStacktrace.cpp -lstdc++exp -g -DINLIB -fpic -shared -o
liba.so ; c++ -std=c++23 testStacktrace.cpp -lstdc++exp -g -DINMAIN -L. -la
-Wl,-rpath=. ; ./a.out
   0#  at :0
   1#  at :0
   2# func(int) at
/afs/cern.ch/user/i/innocent/public/ctest/testStacktrace.cpp:26
   3# main at /afs/cern.ch/user/i/innocent/public/ctest/testStacktrace.cpp:31
   4#  at :0
   5# _start at :0
   6#



[1]
cat testStacktrace.cpp
//compile and run with either
// c++ -std=c++23 testStacktrace.cpp -lstdc++exp -g -DINMAIN -DINLIB; ./a.out
// or
// c++ -std=c++23 testStacktrace.cpp -lstdc++exp -g -DINLIB -fpic -shared -o
liba.so;c++ -std=c++23 testStacktrace.cpp -lstdc++exp -g -DINMAIN -L. -la
-Wl,-rpath=.; ./a.out
//
#include 
#include 


#ifdef INLIB
int nested_func2(int c)
{
std::cout << std::stacktrace::current() << '\n';
return c + 1;
}
int nested_func(int c)
{
return nested_func2(c + 1);
}
#else
int nested_func(int c);
#endif
#ifdef INMAIN
int func(int b)
{
return nested_func(b + 1);
}

int main()
{
std::cout << func(777);
   return 0;
}
#endif

[Bug c++/109781] [11/12/13/14 Regression] erroneous error "lambda-expression in template parameter type" for tparam lambda returning a lambda

[johelegp at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Johel Ernesto Guerrero Peña  ---
Add `+` to convert it to a pointer,
and it's still rejected ():

```C++
template 
struct C {};
```

```output
: In lambda function:
:1:32: error: lambda-expression in template parameter type
1 | template 
  |^
Compiler returned: 1
```

Re: [PATCH v1] RISC-V: Fix one range-loop-construct warning of avlprop

[Jeff Law]

On 10/28/23 08:51, pan2...@intel.com wrote:

From: Pan Li 

This patch would like to fix one warning of avlprop as below.

../../gcc/config/riscv/riscv-avlprop.cc: In member function 'virtual
unsigned int pass_avlprop::execute(function*)':
../../gcc/config/riscv/riscv-avlprop.cc:346:23: error: loop variable
'candidate' creates a copy from type 'const std::pair' [-Werror=range-loop-construct]
   346 |   for (const auto candidate : m_candidates)
   |   ^
../../gcc/config/riscv/riscv-avlprop.cc:346:23: note: use reference type
to prevent copying
   346 |   for (const auto candidate : m_candidates)
   |   ^
   |   &

gcc/ChangeLog:

* config/riscv/riscv-avlprop.cc (pass_avlprop::execute): Use
reference type to prevent copying.

OK
jeff

[Bug c++/109781] [11/12/13/14 Regression] erroneous error "lambda-expression in template parameter type" for tparam lambda returning a lambda

[johelegp at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Johel Ernesto Guerrero Peña  ---
This isn't valid since .

[PATCH v1] RISC-V: Fix one range-loop-construct warning of avlprop

[pan2 . li]

From: Pan Li 

This patch would like to fix one warning of avlprop as below.

../../gcc/config/riscv/riscv-avlprop.cc: In member function 'virtual
unsigned int pass_avlprop::execute(function*)':
../../gcc/config/riscv/riscv-avlprop.cc:346:23: error: loop variable
'candidate' creates a copy from type 'const std::pair' [-Werror=range-loop-construct]
  346 |   for (const auto candidate : m_candidates)
  |   ^
../../gcc/config/riscv/riscv-avlprop.cc:346:23: note: use reference type
to prevent copying
  346 |   for (const auto candidate : m_candidates)
  |   ^
  |   &

gcc/ChangeLog:

* config/riscv/riscv-avlprop.cc (pass_avlprop::execute): Use
reference type to prevent copying.

Signed-off-by: Pan Li 
---
 gcc/config/riscv/riscv-avlprop.cc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/config/riscv/riscv-avlprop.cc 
b/gcc/config/riscv/riscv-avlprop.cc
index 2c79ec81806..c59eb7f6fa3 100644
--- a/gcc/config/riscv/riscv-avlprop.cc
+++ b/gcc/config/riscv/riscv-avlprop.cc
@@ -343,7 +343,7 @@ pass_avlprop::execute (function *fn)
 {
   fprintf (dump_file, "\nNumber of potential AVL propagations: %d\n",
   m_candidates.length ());
-  for (const auto candidate : m_candidates)
+  for (const auto  : m_candidates)
{
  fprintf (dump_file, "\nAVL propagation type: %s\n",
   avlprop_type_to_str (candidate.first));
-- 
2.34.1

[Bug d/112262] New: aaaaaaaaaaaaaa12

[xzlink63 at gmail dot com via Gcc-bugs]

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

Bug ID: 112262
   Summary: aa12
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: xzlink63 at gmail dot com
  Target Milestone: ---

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


aa12

[Bug d/112261] New: aaaa

[xzlink63 at gmail dot com via Gcc-bugs]

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

Bug ID: 112261
   Summary: 
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: xzlink63 at gmail dot com
  Target Milestone: ---

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


https://gcc.gnu.org/bugzilla/enter_bug.cgi?product=gcc

[Bug d/112260] New: azz

[xzlink63 at gmail dot com via Gcc-bugs]

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

Bug ID: 112260
   Summary: azz
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: xzlink63 at gmail dot com
  Target Milestone: ---

Created attachment 56465
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56465=edit
aaa

[Bug d/112259] New: dsfsfssfsdds

[xzlink63 at gmail dot com via Gcc-bugs]

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

Bug ID: 112259
   Summary: dsfsfssfsdds
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: xzlink63 at gmail dot com
  Target Milestone: ---

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

[Bug debug/112258] New: dsfsfssfsdds

[xzlink63 at gmail dot com via Gcc-bugs]

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

Bug ID: 112258
   Summary: dsfsfssfsdds
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: xzlink63 at gmail dot com
  Target Milestone: ---

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


dsfsfssfsdds

[Bug d/112257] New: fg

[xzlink63 at gmail dot com via Gcc-bugs]

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

Bug ID: 112257
   Summary: fg
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: xzlink63 at gmail dot com
  Target Milestone: ---

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


dsfsfssfsdds

[Bug d/112256] New: dddd

[xzlink63 at gmail dot com via Gcc-bugs]

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

Bug ID: 112256
   Summary: 
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: xzlink63 at gmail dot com
  Target Milestone: ---

Created attachment 56461
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56461=edit
f

dsfsfssfsdds

[Bug d/112255] New: dsfsfssfsdds

[xzlink63 at gmail dot com via Gcc-bugs]

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

Bug ID: 112255
   Summary: dsfsfssfsdds
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: xzlink63 at gmail dot com
  Target Milestone: ---

Created attachment 56460
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56460=edit
gg

ff

[Bug debug/112254] New: ffff

[xzlink63 at gmail dot com via Gcc-bugs]

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

Bug ID: 112254
   Summary: 
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: xzlink63 at gmail dot com
  Target Milestone: ---

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


dsfsfssfsdds

[Bug d/112253] New: dsfsfssfsddsf

[xzlink63 at gmail dot com via Gcc-bugs]

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

Bug ID: 112253
   Summary: dsfsfssfsddsf
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: xzlink63 at gmail dot com
  Target Milestone: ---

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


dsfsfssfsdds

[Bug d/112252] New: dsfsfssfsdds

[xzlink63 at gmail dot com via Gcc-bugs]

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

Bug ID: 112252
   Summary: dsfsfssfsdds
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: xzlink63 at gmail dot com
  Target Milestone: ---

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


dsfsfssfsddsdsfsfssfsdds

[Bug d/112250] New: dsfsfssfsdds

[xzlink63 at gmail dot com via Gcc-bugs]

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

Bug ID: 112250
   Summary: dsfsfssfsdds
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: xzlink63 at gmail dot com
  Target Milestone: ---

Created attachment 56455
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56455=edit
uyu

dsfsfssfsdds

[Bug d/112251] New: dff

[xzlink63 at gmail dot com via Gcc-bugs]

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

Bug ID: 112251
   Summary: dff
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: xzlink63 at gmail dot com
  Target Milestone: ---

Created attachment 56456
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56456=edit
yyy

dsfsfssfsdds

[Bug d/112249] New: dsfsfssfsdds

[xzlink63 at gmail dot com via Gcc-bugs]

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

Bug ID: 112249
   Summary: dsfsfssfsdds
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: xzlink63 at gmail dot com
  Target Milestone: ---

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


dsfsfssfsdds

[Bug d/112248] New: f

[xzlink63 at gmail dot com via Gcc-bugs]

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

Bug ID: 112248
   Summary: f
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: xzlink63 at gmail dot com
  Target Milestone: ---

Created attachment 56453
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56453=edit
j

dsfsfssfsdds

[Bug d/112247] New: dsfsfssfsdds

[xzlink63 at gmail dot com via Gcc-bugs]

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

Bug ID: 112247
   Summary: dsfsfssfsdds
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: xzlink63 at gmail dot com
  Target Milestone: ---

Created attachment 56452
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56452=edit
u

dsfsfssfsdds

[Bug d/112246] New: dsfsfssfsdds

[xzlink63 at gmail dot com via Gcc-bugs]

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

Bug ID: 112246
   Summary: dsfsfssfsdds
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: xzlink63 at gmail dot com
  Target Milestone: ---

Created attachment 56451
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56451=edit
uyuu

dsfsfssfsdds

[Bug d/112245] New: dsfsfssfsdds

[xzlink63 at gmail dot com via Gcc-bugs]

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

Bug ID: 112245
   Summary: dsfsfssfsdds
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: xzlink63 at gmail dot com
  Target Milestone: ---

Created attachment 56450
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56450=edit
fff

dsfsfssfsdds

[Bug d/112244] New: dsfsfssfsdds

[xzlink63 at gmail dot com via Gcc-bugs]

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

Bug ID: 112244
   Summary: dsfsfssfsdds
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: xzlink63 at gmail dot com
  Target Milestone: ---

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


dsfsfssfsdds

[Bug d/112243] New: dsfsfssfsdds

[xzlink63 at gmail dot com via Gcc-bugs]

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

Bug ID: 112243
   Summary: dsfsfssfsdds
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: xzlink63 at gmail dot com
  Target Milestone: ---

Created attachment 56448
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56448=edit
aaa

dsfsfssfsdds

[Bug d/112242] New: dsfsfssfsdds

[xzlink63 at gmail dot com via Gcc-bugs]

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

Bug ID: 112242
   Summary: dsfsfssfsdds
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: xzlink63 at gmail dot com
  Target Milestone: ---

Created attachment 56447
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56447=edit
e

dsfsfssfsdds

[Bug d/112241] New: v1e1e1e1e1e1

[xzlink63 at gmail dot com via Gcc-bugs]

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

Bug ID: 112241
   Summary: v1e1e1e1e1e1
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: xzlink63 at gmail dot com
  Target Milestone: ---

Created attachment 56446
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56446=edit
ff

1e1e1e1e1e1

[Bug d/112240] New: 1e1e1e1e1e11e1e1e1e1e11e1e1e1e1e1

[xzlink63 at gmail dot com via Gcc-bugs]

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

Bug ID: 112240
   Summary: 1e1e1e1e1e11e1e1e1e1e11e1e1e1e1e1
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: xzlink63 at gmail dot com
  Target Milestone: ---

Created attachment 56445
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56445=edit
y

1e1e1e1e1e1

[Bug d/112239] New: 1e1e1e1e1e1

[xzlink63 at gmail dot com via Gcc-bugs]

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

Bug ID: 112239
   Summary: 1e1e1e1e1e1
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: xzlink63 at gmail dot com
  Target Milestone: ---

Created attachment 56444
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56444=edit
hhh

1e1e1e1e1e1

[Bug d/112238] New: 1e1e1e1e1e1

[xzlink63 at gmail dot com via Gcc-bugs]

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

Bug ID: 112238
   Summary: 1e1e1e1e1e1
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: xzlink63 at gmail dot com
  Target Milestone: ---

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

[Bug d/112237] New: 1e1e1e1e1e1

[xzlink63 at gmail dot com via Gcc-bugs]

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

Bug ID: 112237
   Summary: 1e1e1e1e1e1
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: xzlink63 at gmail dot com
  Target Milestone: ---

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


1e1e1e1e1e1

[Bug d/112236] New: 1e1e1e1e1e1

[xzlink63 at gmail dot com via Gcc-bugs]

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

Bug ID: 112236
   Summary: 1e1e1e1e1e1
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: xzlink63 at gmail dot com
  Target Milestone: ---

Created attachment 56441
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56441=edit
y

1e1e1e1e1e11e1e1e1e1e1

[Bug d/112235] New: 1e1e1e1e1e1

[xzlink63 at gmail dot com via Gcc-bugs]

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

Bug ID: 112235
   Summary: 1e1e1e1e1e1
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: xzlink63 at gmail dot com
  Target Milestone: ---

Created attachment 56440
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56440=edit
1e1e1e1e1e1

1e1e1e1e1e1

[Bug d/112234] New: 1e1e1e1e1e11e1e1e1e1e1

[xzlink63 at gmail dot com via Gcc-bugs]

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

Bug ID: 112234
   Summary: 1e1e1e1e1e11e1e1e1e1e1
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: xzlink63 at gmail dot com
  Target Milestone: ---

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


1e1e1e1e1e11e1e1e1e1e1

[Bug d/112233] New: 1e1e1e1e1e1

[xzlink63 at gmail dot com via Gcc-bugs]

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

Bug ID: 112233
   Summary: 1e1e1e1e1e1
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: xzlink63 at gmail dot com
  Target Milestone: ---

Created attachment 56438
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56438=edit
ttyyy

1e1e1e1e1e1

[Bug d/112232] New: 1e1e1e1e1e1

[xzlink63 at gmail dot com via Gcc-bugs]

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

Bug ID: 112232
   Summary: 1e1e1e1e1e1
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: xzlink63 at gmail dot com
  Target Milestone: ---

Created attachment 56437
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56437=edit
uyuuu

1e1e1e1e1e1

[Bug d/112231] New: 1e1e1e1e1e1

[xzlink63 at gmail dot com via Gcc-bugs]

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

Bug ID: 112231
   Summary: 1e1e1e1e1e1
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: xzlink63 at gmail dot com
  Target Milestone: ---

Created attachment 56436
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56436=edit
po

[Bug d/112230] New: 1e1e1e1e1e1

[xzlink63 at gmail dot com via Gcc-bugs]

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

Bug ID: 112230
   Summary: 1e1e1e1e1e1
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: xzlink63 at gmail dot com
  Target Milestone: ---

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


1e1e1e1e1e1

[Bug d/112229] New: 1e1e1e1e1e1

[xzlink63 at gmail dot com via Gcc-bugs]

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

Bug ID: 112229
   Summary: 1e1e1e1e1e1
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: xzlink63 at gmail dot com
  Target Milestone: ---

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


1e1e1e1e1e1

[Bug d/112228] New: 1e1e1e1e1e1

[xzlink63 at gmail dot com via Gcc-bugs]

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

Bug ID: 112228
   Summary: 1e1e1e1e1e1
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: xzlink63 at gmail dot com
  Target Milestone: ---

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


1e1e1e1e1e1

[Bug d/112224] New: 1e1e1e1e1e1

[xzlink63 at gmail dot com via Gcc-bugs]

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

Bug ID: 112224
   Summary: 1e1e1e1e1e1
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: xzlink63 at gmail dot com
  Target Milestone: ---

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


1e1e1e1e1e11e1e1e1e1e1

[Bug d/112227] New: 1e1e1e1e1e1

[xzlink63 at gmail dot com via Gcc-bugs]

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

Bug ID: 112227
   Summary: 1e1e1e1e1e1
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: xzlink63 at gmail dot com
  Target Milestone: ---

Created attachment 56432
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56432=edit
yyt

1e1e1e1e1e1