Re: arm: Make arm_noce_conversion_profitable_p call default hook [PR 116444]

2024-10-06 Thread Ramana Radhakrishnan
On Fri, Oct 4, 2024 at 9:25 PM Andre Vieira (lists)
 wrote:
>
> Hi,
>
> The patch for 'arm: Fix missed CE optimization for armv8.1-m.main [PR
> 116444]' introduced regressions with arm targets that used 'noce' before.
> This is because it would approve all noce optimisations without using
> the default cost check. Not sure why this didn't show up in my original
> testing, I suspect you need to test this for a set of specific targets
> like Torbjorn did, thank you for pointing these issues out to me.
>
> Could I ask you to rerun them with this patch? I'll try to do that
> locally too.
>
> Happy to receive reviews, but I'm waiting for Torbjorn and my own
> testing to complete before committing.
>
> When not dealing with the special armv8.1-m.main conditional
> instructions case
> make sure it uses the default_noce_conversion_profitable_p call to determine
> whether the sequence is cost effective.
>

Ok if no regressions.

Ramana

> gcc/ChangeLog:
>
>
> PR target/116444
> * config/arm/arm.cc (arm_noce_conversion_profitable_p): Call
> default_noce_conversion_profitable_p when not dealing with the
> armv8.1-m.main conditional instructions special cases.


Re: [PING] [PATCH] i386: Implement Thread Local Storage on Windows

2024-10-06 Thread Julian Waters
Hi Eric,

Thanks for getting back to me, I wasn't actually asking if it was ok (The
ping was poorly worded, sorry), more trying to draw attention to the patch.
The linker bug blocking this patch has actually already been fixed, see
https://github.com/bminor/binutils-gdb/commit/72cd2c70977943054ff784b7278cef5262288f32
for
the patch that fixed it (Thanks for the help Jan!). I'll add your
suggestions to the patch before pushing out a new version for review,
thanks (Well, there is one suggestion of yours I cannot add: Making the
secrel32 relocation Pmode, since the emitted assembly is broken when I do
that)

best regards,
Julian


On Mon, Oct 7, 2024 at 1:53 PM Eric Botcazou  wrote:

> > Pinging
> https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662860.html
> > as it has been buried under several other patches. Is the patch ok for
> > master?
>
> No, you should modify it along the way I suggested privately, and a
> blocker is
> the missing support in the linker AFAICS.
>
> --
> Eric Botcazou
>
>
>


[PING] [PATCH] i386: Implement Thread Local Storage on Windows

2024-10-06 Thread Julian Waters
Hi all,

Pinging https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662860.html
as it has been buried under several other patches. Is the patch ok for
master?

best regards,
Julian


Re: [PING] [PATCH] i386: Implement Thread Local Storage on Windows

2024-10-06 Thread Eric Botcazou
> Pinging https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662860.html
> as it has been buried under several other patches. Is the patch ok for
> master?

No, you should modify it along the way I suggested privately, and a blocker is 
the missing support in the linker AFAICS.

-- 
Eric Botcazou




Re: [PATCH 3/3] phiprop: VOP phi confuses phiprop [PR116824]

2024-10-06 Thread Andrew Pinski
On Wed, Sep 25, 2024 at 1:38 AM Richard Biener
 wrote:
>
> On Tue, Sep 24, 2024 at 6:14 PM Andrew Pinski  
> wrote:
> >
> > Another small phiprop improvement, in some cases
> > we could have a vop defining statement be a phi which might
> > be the same bb as the load happens. This is ok since the phi
> > here is not a store so we can just accept it.
> >
> > Bootstrapped and tested on x86_64-linux-gnu.
>
> OK.

Just a quick note here, I have not applied this nor the other phiprop
patch because they can expose more wrong code due to a latent bug in
phiprop (see PR 116835). I am working on fixing that bug and after
that issue is resolved I will push both of these.

Thanks,
Andrew Pinski

>
> > PR tree-optimization/116824
> >
> > gcc/ChangeLog:
> >
> > * tree-ssa-phiprop.cc (propagate_with_phi): Don't
> > reject if the bb of the def_stmt is the same as load
> > and if the def_stmt was a phi.
> >
> > gcc/testsuite/ChangeLog:
> >
> > * gcc.dg/tree-ssa/phiprop-3.c: New test.
> >
> > Signed-off-by: Andrew Pinski 
> > ---
> >  gcc/testsuite/gcc.dg/tree-ssa/phiprop-3.c | 30 +++
> >  gcc/tree-ssa-phiprop.cc   |  3 ++-
> >  2 files changed, 32 insertions(+), 1 deletion(-)
> >  create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/phiprop-3.c
> >
> > diff --git a/gcc/testsuite/gcc.dg/tree-ssa/phiprop-3.c 
> > b/gcc/testsuite/gcc.dg/tree-ssa/phiprop-3.c
> > new file mode 100644
> > index 000..a0d5891dc60
> > --- /dev/null
> > +++ b/gcc/testsuite/gcc.dg/tree-ssa/phiprop-3.c
> > @@ -0,0 +1,30 @@
> > +/* { dg-do compile } */
> > +/* { dg-options "-O1 -fdump-tree-phiprop1-details 
> > -fdump-tree-cselim-details -fdump-tree-phiopt2" } */
> > +
> > +/* PR tree-optimization/116824 */
> > +/* phiprop should be able to handle the case where the vops defining
> > +   statement was a phi in the same bb as the deference. */
> > +
> > +int g(int i, int *tt)
> > +{
> > +  const int t = 10;
> > +  const int *a;
> > +  {
> > +if (t < i)
> > +{
> > +  *tt = 1;
> > +  a = &t;
> > +}
> > +else
> > +{
> > +  *tt = 1;
> > +  a = &i;
> > +}
> > +  }
> > +  return *a;
> > +}
> > +
> > +/* { dg-final { scan-tree-dump-times "Inserting PHI for result of load" 1 
> > "phiprop1"} } */
> > +/* { dg-final { scan-tree-dump-times "factoring out stores" 1 "cselim"} } 
> > */
> > +/* { dg-final { scan-tree-dump-times "MIN_EXPR" 1 "phiopt2"} } */
> > +
> > diff --git a/gcc/tree-ssa-phiprop.cc b/gcc/tree-ssa-phiprop.cc
> > index f04990e8cb4..4d1df7d351e 100644
> > --- a/gcc/tree-ssa-phiprop.cc
> > +++ b/gcc/tree-ssa-phiprop.cc
> > @@ -401,7 +401,8 @@ propagate_with_phi (basic_block bb, gphi *phi, struct 
> > phiprop_d *phivn,
> >   def_stmt = SSA_NAME_DEF_STMT (vuse);
> > }
> >if (!SSA_NAME_IS_DEFAULT_DEF (vuse)
> > - && (gimple_bb (def_stmt) == bb
> > + && ((gimple_bb (def_stmt) == bb
> > +  && !is_a(def_stmt))
> >   || (gimple_bb (def_stmt)
> >   && !dominated_by_p (CDI_DOMINATORS,
> >   bb, gimple_bb (def_stmt)
> > --
> > 2.43.0
> >


Re: [PATCH 3/3] gimple: Add gimple_with_undefined_signed_overflow and use it [PR111276]

2024-10-06 Thread Andrew Pinski
On Fri, Oct 4, 2024 at 12:08 AM Richard Biener
 wrote:
>
> On Thu, Oct 3, 2024 at 6:09 PM Andrew Pinski  wrote:
> >
> > While looking into the ifcombine, I noticed that rewrite_to_defined_overflow
> > was rewriting already defined code. In the previous attempt at fixing this,
> > the review mentioned we should not be calling rewrite_to_defined_overflow
> > in those cases. The places which called rewrite_to_defined_overflow didn't
> > always check the lhs of the assignment. This fixes the problem by
> > introducing a helper function which is to be used before calling
> > rewrite_to_defined_overflow.
> >
> > Bootstrapped and tested on x86_64-linux-gnu.
>
> OK.

Just a quick note, this depends on the rewrite of `scope conflicts
better` issue; otherwise we get a regression. I am working on the new
patch for that and will resubmit this with that patch.

Thanks,
Andrew

>
> Thanks,
> Richard.
>
> > gcc/ChangeLog:
> >
> > PR tree-optimization/111276
> > * gimple-fold.cc (arith_code_with_undefined_signed_overflow): Make 
> > static.
> > (gimple_with_undefined_signed_overflow): New function.
> > * gimple-fold.h (arith_code_with_undefined_signed_overflow): Remove.
> > (gimple_with_undefined_signed_overflow): Add declaration.
> > * tree-if-conv.cc (if_convertible_gimple_assign_stmt_p): Use
> > gimple_with_undefined_signed_overflow instead of manually
> > checking lhs and the code of the stmt.
> > (predicate_statements): Likewise.
> > * tree-ssa-ifcombine.cc (pass_tree_ifcombine::execute): Likewise.
> > * tree-ssa-loop-im.cc (move_computations_worker): Likewise.
> > * tree-ssa-reassoc.cc (update_range_test): Likewise. Reformat.
> > * tree-scalar-evolution.cc (final_value_replacement_loop): Use
> > gimple_with_undefined_signed_overflow instead of
> > arith_code_with_undefined_signed_overflow.
> > * tree-ssa-loop-split.cc (split_loop): Likewise.
> >
> > Signed-off-by: Andrew Pinski 
> > ---
> >  gcc/gimple-fold.cc   | 26 ++-
> >  gcc/gimple-fold.h|  2 +-
> >  gcc/tree-if-conv.cc  | 16 +++
> >  gcc/tree-scalar-evolution.cc |  5 +
> >  gcc/tree-ssa-ifcombine.cc| 10 ++---
> >  gcc/tree-ssa-loop-im.cc  |  6 +-
> >  gcc/tree-ssa-loop-split.cc   |  5 +
> >  gcc/tree-ssa-reassoc.cc  | 40 +++-
> >  8 files changed, 50 insertions(+), 60 deletions(-)
> >
> > diff --git a/gcc/gimple-fold.cc b/gcc/gimple-fold.cc
> > index 942de7720fd..0b49d6754e2 100644
> > --- a/gcc/gimple-fold.cc
> > +++ b/gcc/gimple-fold.cc
> > @@ -8991,7 +8991,7 @@ gimple_fold_indirect_ref (tree t)
> > integer types involves undefined behavior on overflow and the
> > operation can be expressed with unsigned arithmetic.  */
> >
> > -bool
> > +static bool
> >  arith_code_with_undefined_signed_overflow (tree_code code)
> >  {
> >switch (code)
> > @@ -9008,6 +9008,30 @@ arith_code_with_undefined_signed_overflow (tree_code 
> > code)
> >  }
> >  }
> >
> > +/* Return true if STMT has an operation that operates on a signed
> > +   integer types involves undefined behavior on overflow and the
> > +   operation can be expressed with unsigned arithmetic.  */
> > +
> > +bool
> > +gimple_with_undefined_signed_overflow (gimple *stmt)
> > +{
> > +  if (!is_gimple_assign (stmt))
> > +return false;
> > +  tree lhs = gimple_assign_lhs (stmt);
> > +  if (!lhs)
> > +return false;
> > +  tree lhs_type = TREE_TYPE (lhs);
> > +  if (!INTEGRAL_TYPE_P (lhs_type)
> > +  && !POINTER_TYPE_P (lhs_type))
> > +return false;
> > +  if (!TYPE_OVERFLOW_UNDEFINED (lhs_type))
> > +return false;
> > +  if (!arith_code_with_undefined_signed_overflow
> > +   (gimple_assign_rhs_code (stmt)))
> > +return false;
> > +  return true;
> > +}
> > +
> >  /* Rewrite STMT, an assignment with a signed integer or pointer arithmetic
> > operation that can be transformed to unsigned arithmetic by converting
> > its operand, carrying out the operation in the corresponding unsigned
> > diff --git a/gcc/gimple-fold.h b/gcc/gimple-fold.h
> > index dc709d515a9..165325392c9 100644
> > --- a/gcc/gimple-fold.h
> > +++ b/gcc/gimple-fold.h
> > @@ -59,7 +59,7 @@ extern tree gimple_get_virt_method_for_vtable 
> > (HOST_WIDE_INT, tree,
> >  extern tree gimple_fold_indirect_ref (tree);
> >  extern bool gimple_fold_builtin_sprintf (gimple_stmt_iterator *);
> >  extern bool gimple_fold_builtin_snprintf (gimple_stmt_iterator *);
> > -extern bool arith_code_with_undefined_signed_overflow (tree_code);
> > +extern bool gimple_with_undefined_signed_overflow (gimple *);
> >  extern void rewrite_to_defined_overflow (gimple_stmt_iterator *);
> >  extern gimple_seq rewrite_to_defined_overflow (gimple *);
> >  extern void replace_call_with_value (gimple_stmt_iterator *, tree);
> > diff --git a/gcc/tree-if-conv.cc b/gcc/tree-if-conv.cc
> > inde

[to-be-committed][V2][RISC-V] Add splitters to restore condops generation after recent phiopt changes

2024-10-06 Thread Jeff Law


V2:
  Fix typo in ChangeLog.
  Remove now extraneous comment in cset-sext.c.
  Throttle back branch cost to 1 in various tests

--

Andrew P's recent improvements to phiopt regressed on the riscv testsuite.

Essentially the new code presented to the RTL optimizers is straightline 
code rather than branchy for the CE pass to analyze and optimize.  In 
the absence of conditional move support or sfb, the new code would be 
better.


Unfortunately the presented form isn't a great fit for xventanacondops, 
zicond or xtheadcondmov.  The net is the resulting code is actually 
slightly worse than before.  Essentially sne+czero turned into sne+sne+and.


Thankfully, combine is presented with

(and (ne (op1) (const_int 0))
 (ne (op2) (const_int 0)))

As the RHS of a set.  We can use a 3->2 splitter to guide combine on how 
to profitably rewrite the sequence in a form suitable for condops.  Just 
splitting that would be enough to fix the regression, but I'm fairly 
confident that other cases need to be handled and would have regressed 
had the testsuite been more thorough.



One arm of the AND is going to turn into an sCC instruction.  We have a 
variety of those that we support.  The codes vary as do the allowed 
operands of the sCC.  That produces a set of new splitters to handle 
those cases.


The other arm is going to turn into a czero (or similar) instruction. 
That one can be generalized to eq/ne.  So another set for that 
generalization.


We can remove a couple of XFAILs in the rv32 space as it's behaving much 
more like rv64 at this point.


For SFB targets it's unclear if the new code is better or worse.  In 
both cases it's a 3 instruction sequence.   So I just adjusted the test. 
 If the new code is worse for SFB, someone with an understanding of the 
tradeoffs for an SFB target will need to make adjustments.


Tested in my tester on rv64gcv and rv32gc.  Will wait for the pre-commit 
testers to render their verdict before moving forward.
   * config/riscv/iterators.md (scc_0): New code iterator.
   * config/riscv/zicond.md: New splitters to improve code generated for
   cases like (and (scc) (scc)) for zicond, xventanacondops, xtheadcondmov.

   * gcc.target/riscv/cset-sext-sfb.c: Turn off ssa-phiopt.
   * gcc.target/riscv/cset-sext-thead.c: Do not check CE output anymore.
   * gcc.target/riscv/cset-sext-ventana.c: Similarly.  Adjust branch cost.
   * gcc.target/riscv/cset-sext-zicond.c: Similarly.
   * gcc.target/riscv/cset-sext.c: Similarly.  No longer allow
   "neg" in asm output.

diff --git a/gcc/config/riscv/iterators.md b/gcc/config/riscv/iterators.md
index 2844cb02ff0..872c542e906 100644
--- a/gcc/config/riscv/iterators.md
+++ b/gcc/config/riscv/iterators.md
@@ -233,6 +233,8 @@ (define_code_iterator any_gt [gt gtu])
 (define_code_iterator any_ge [ge geu])
 (define_code_iterator any_lt [lt ltu])
 (define_code_iterator any_le [le leu])
+;; Iterators for conditions we can emit a sCC against 0 or a reg directly
+(define_code_iterator scc_0  [eq ne gt gtu])
 
 ; atomics code iterator
 (define_code_iterator any_atomic [plus ior xor and])
diff --git a/gcc/config/riscv/zicond.md b/gcc/config/riscv/zicond.md
index 3876be7f9d2..ab1a5337ee5 100644
--- a/gcc/config/riscv/zicond.md
+++ b/gcc/config/riscv/zicond.md
@@ -124,3 +124,115 @@ (define_split
 {
   operands[2] = GEN_INT (1 << UINTVAL(operands[2]));
 })
+
+;; In some cases gimple can give us a sequence with a logical and
+;; of two sCC insns.  This can be implemented an sCC feeding a
+;; conditional zero.
+(define_split
+  [(set (match_operand:X 0 "register_operand")
+	(and:X (ne:X (match_operand:X 1 "register_operand") (const_int 0))
+	   (scc_0:X (match_operand:X 2 "register_operand")
+			(match_operand:X 3 "reg_or_0_operand"
+   (clobber (match_operand:X 4 "register_operand"))]
+  "TARGET_ZICOND_LIKE || TARGET_XTHEADCONDMOV"
+  [(set (match_dup 4) (scc_0:X (match_dup 2) (match_dup 3)))
+   (set (match_dup 0) (if_then_else:X (eq:X (match_dup 1) (const_int 0))
+  (const_int 0)
+  (match_dup 4)))])
+
+;; Similarly but GE/GEU which requires (const_int 1) as an operand.
+(define_split
+  [(set (match_operand:X 0 "register_operand")
+	(and:X (ne:X (match_operand:X 1 "register_operand") (const_int 0))
+	   (any_ge:X (match_operand:X 2 "register_operand")
+			 (const_int 1
+   (clobber (match_operand:X 3 "register_operand"))]
+  "TARGET_ZICOND_LIKE || TARGET_XTHEADCONDMOV"
+  [(set (match_dup 3) (any_ge:X (match_dup 2) (const_int 1)))
+   (set (match_dup 0) (if_then_else:X (eq:X (match_dup 1) (const_int 0))
+  (const_int 0)
+  (match_dup 3)))])
+
+;; Similarly but LU/LTU which allows an arith_operand
+(define_split
+  [(set (match_operand:X 0 "register_operand")
+	(and:X (ne:X (match_operand:X 1 "register_operand") (const_int 0))
+	   (any_lt:X (match_operand:X 2 "register_operand")
+			 (match_operand:X 3 "arith_operand"
+   (clobber (match_operand:X 4 "regist

[committed] hppa: Use stack slot SP-40 to copy between integer and floating-point registers

2024-10-06 Thread John David Anglin
Tested on hppa64-hp-hpux11.11 and hppa-unknown-linux-gnu.  Committed
to trunk.

Dave
---

hppa: Use stack slot SP-40 to copy between integer and floating-point registers

2024-10-06  John David Anglin  

gcc/ChangeLog:

* config/pa/pa-64.h (PA_SECONDARY_MEMORY_NEEDED): Define
to false.  Update comment.
* config/pa/pa.md: Modify 64-bit move patterns to support
copying between integer and floating-point registers using
stack slot SP-40.

diff --git a/gcc/config/pa/pa-64.h b/gcc/config/pa/pa-64.h
index b676468d2ce..3fae3f851e5 100644
--- a/gcc/config/pa/pa-64.h
+++ b/gcc/config/pa/pa-64.h
@@ -91,9 +91,9 @@ along with GCC; see the file COPYING3.  If not see
the RTL to avoid scheduling related problems.  For example, the
store and load could be separated by a call to a pure or const
function which has no frame and this function might also use SP-16.
-   We have 14-bit immediates on the 64-bit port, so we use secondary
-   memory for the copies.  */
-#define PA_SECONDARY_MEMORY_NEEDED(MODE, CLASS1, CLASS2) \
-  (MAYBE_FP_REG_CLASS_P (CLASS1) != FP_REG_CLASS_P (CLASS2)\
-   || MAYBE_FP_REG_CLASS_P (CLASS2) != FP_REG_CLASS_P (CLASS1))
-
+   
+   On the 64-bit port, I couldn't get SECONDARY_MEMORY_NEEDED to work
+   with LRA, so I modified the move patterns to use SP-40.  The HP
+   compiler also uses this slot in the frame marker for moving data
+   between the general and floating-point registers.  */
+#define PA_SECONDARY_MEMORY_NEEDED(MODE, CLASS1, CLASS2) false
diff --git a/gcc/config/pa/pa.md b/gcc/config/pa/pa.md
index f0520bb2c35..bf59b7f601e 100644
--- a/gcc/config/pa/pa.md
+++ b/gcc/config/pa/pa.md
@@ -,9 +,9 @@
 
 (define_insn ""
   [(set (match_operand:SI 0 "move_dest_operand"
- "=r,r,r,r,r,r,Q,!*q,!r,!*f,*f,T")
+ "=r,r,r,r,r,r,Q,!*q,!r,!*f,*f,T,?r,?*f")
(match_operand:SI 1 "move_src_operand"
- "A,r,J,N,K,RQ,rM,!rM,!*q,!*fM,RT,*f"))]
+ "A,r,J,N,K,RQ,rM,!rM,!*q,!*fM,RT,*f,*f,r"))]
   "(register_operand (operands[0], SImode)
 || reg_or_0_operand (operands[1], SImode))
&& !TARGET_SOFT_FLOAT
@@ -2241,10 +2241,12 @@
{mfctl|mfctl,w} %%sar,%0
fcpy,sgl %f1,%0
fldw%F1 %1,%0
-   fstw%F0 %1,%0"
-  [(set_attr "type" 
"load,move,move,move,shift,load,store,move,move,fpalu,fpload,fpstore")
+   fstw%F0 %1,%0
+   fstw %1,-40(%%sp)\n\tldw -40(%%sp),%0
+   stw %1,-40(%%sp)\n\tfldw -40(%%sp),%0"
+  [(set_attr "type" 
"load,move,move,move,shift,load,store,move,move,fpalu,fpload,fpstore,fpstore_load,store_fpload")
(set_attr "pa_combine_type" "addmove")
-   (set_attr "length" "4,4,4,4,4,4,4,4,4,4,4,4")])
+   (set_attr "length" "4,4,4,4,4,4,4,4,4,4,4,4,8,8")])
 
 (define_insn ""
   [(set (match_operand:SI 0 "move_dest_operand"
@@ -4107,9 +4109,9 @@
 
 (define_insn ""
   [(set (match_operand:DF 0 "move_dest_operand"
- "=!*r,*r,*r,*r,*r,Q,f,f,T")
+ "=!*r,*r,*r,*r,*r,Q,f,f,T,?*r,?f")
(match_operand:DF 1 "move_src_operand"
- "!*rG,J,N,K,RQ,*rG,fG,RT,f"))]
+ "!*rG,J,N,K,RQ,*rG,fG,RT,f,f,*r"))]
   "(register_operand (operands[0], DFmode)
 || reg_or_0_operand (operands[1], DFmode))
&& !TARGET_SOFT_FLOAT && TARGET_64BIT"
@@ -4122,10 +4124,12 @@
std%M0 %r1,%0
fcpy,dbl %f1,%0
fldd%F1 %1,%0
-   fstd%F0 %1,%0"
-  [(set_attr "type" "move,move,move,shift,load,store,fpalu,fpload,fpstore")
+   fstd%F0 %1,%0
+   fstd %1,-40(%%sp)\n\tldd -40(%%sp),%0
+   std %1,-40(%%sp)\n\tfldd -40(%%sp),%0"
+  [(set_attr "type" 
"move,move,move,shift,load,store,fpalu,fpload,fpstore,fpstore_load,store_fpload")
(set_attr "pa_combine_type" "addmove")
-   (set_attr "length" "4,4,4,4,4,4,4,4,4")])
+   (set_attr "length" "4,4,4,4,4,4,4,4,4,8,8")])
 
 (define_insn ""
   [(set (match_operand:DF 0 "move_dest_operand"
@@ -4281,9 +4285,9 @@
 
 (define_insn ""
   [(set (match_operand:DI 0 "move_dest_operand"
- "=r,r,r,r,r,r,Q,!*q,!r,!*f,*f,T")
+ "=r,r,r,r,r,r,Q,!*q,!r,!*f,*f,T,?r,?*f")
(match_operand:DI 1 "move_src_operand"
- "A,r,J,N,K,RQ,rM,!rM,!*q,!*fM,RT,*f"))]
+ "A,r,J,N,K,RQ,rM,!rM,!*q,!*fM,RT,*f,*f,r"))]
   "(register_operand (operands[0], DImode)
 || reg_or_0_operand (operands[1], DImode))
&& !TARGET_SOFT_FLOAT && TARGET_64BIT"
@@ -4299,10 +4303,12 @@
{mfctl|mfctl,w} %%sar,%0
fcpy,dbl %f1,%0
fldd%F1 %1,%0
-   fstd%F0 %1,%0"
-  [(set_attr "type" 
"load,move,move,move,shift,load,store,move,move,fpalu,fpload,fpstore")
+   fstd%F0 %1,%0
+   fstd %1,-40(%%sp)\n\tldd -40(%%sp),%0
+   std %1,-40(%%sp)\n\tfldd -40(%%sp),%0"
+  [(set_attr "type" 
"load,move,move,move,shift,load,store,move,move,fpalu,fpload,fpstore,fpstore_load,store_fpload")
(set_attr "pa_combine_type" "addmove")
-   (set_attr "length" "4,4,4,4,4,4,4,4,4,4,4

Re: [PATCH v2] Add new warning Wmissing-designated-initializers [PR39589]

2024-10-06 Thread Peter Frost

Ping https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662590.html


testsuite: Require lto in three tests

2024-10-06 Thread John David Anglin
Committed as obvious.

Dave
---

testsuite: Require lto in three tests

2024-10-06  John David Anglin  

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/noexcept87.C: Require lto.
* g++.dg/ext/pragma-unroll-lambda-lto.C: Likewise.
* gcc.dg/enum-alias-3.c: Likewise.

diff --git a/gcc/testsuite/g++.dg/cpp0x/noexcept87.C 
b/gcc/testsuite/g++.dg/cpp0x/noexcept87.C
index 339569d15ae..bb7bb605532 100644
--- a/gcc/testsuite/g++.dg/cpp0x/noexcept87.C
+++ b/gcc/testsuite/g++.dg/cpp0x/noexcept87.C
@@ -1,5 +1,6 @@
 // PR c++/115223
 // { dg-do compile { target c++11 } }
+// { dg-require-effective-target lto }
 // { dg-additional-options -flto }
 
 template
diff --git a/gcc/testsuite/g++.dg/ext/pragma-unroll-lambda-lto.C 
b/gcc/testsuite/g++.dg/ext/pragma-unroll-lambda-lto.C
index 64cdf90f34d..ddf11730e33 100644
--- a/gcc/testsuite/g++.dg/ext/pragma-unroll-lambda-lto.C
+++ b/gcc/testsuite/g++.dg/ext/pragma-unroll-lambda-lto.C
@@ -1,4 +1,5 @@
 // { dg-do link { target c++11 } }
+// { dg-require-effective-target lto }
 // { dg-options "-O2 -flto -fdump-rtl-loop2_unroll" }
 // { dg-skip-if "requires hosted libstdc++ for cstdlib rand" { ! hostedlib } }
 
diff --git a/gcc/testsuite/gcc.dg/enum-alias-3.c 
b/gcc/testsuite/gcc.dg/enum-alias-3.c
index 36a4f02a455..322c8d82952 100644
--- a/gcc/testsuite/gcc.dg/enum-alias-3.c
+++ b/gcc/testsuite/gcc.dg/enum-alias-3.c
@@ -1,4 +1,5 @@
 /* { dg-do run } */
+/* { dg-require-effective-target lto } */
 /* { dg-options "-O2 -flto" } */
 
 typedef int *A;


signature.asc
Description: PGP signature