Re: [RFC] light expander sra for parameters and returns
On Sat, 5 Aug 2023, Jiufu Guo wrote:
>
> Hi,
>
> Richard Biener writes:
>
> > On Thu, 3 Aug 2023, Jiufu Guo wrote:
> >
> >>
> >> Hi Richard,
> >>
> >> Richard Biener writes:
> >>
> >> > On Tue, 1 Aug 2023, Jiufu Guo wrote:
> >> >
> >> >>
> >> >> Hi,
> >> >>
> >> >> Richard Biener writes:
> >> >>
> >> >> > On Mon, 24 Jul 2023, Jiufu Guo wrote:
> >> >> >
> >> >> >>
> >> >> >> Hi Martin,
> >> >> >>
> >> >> >> Not sure about your current option about re-using the ipa-sra code
> >> >> >> in the light-expander-sra. And if anything I could input please
> >> >> >> let me know.
> >> >> >>
> >> >> >> And I'm thinking about the difference between the expander-sra,
> >> >> >> ipa-sra
> >> >> >> and tree-sra. 1. For stmts walking, expander-sra has special behavior
> >> >> >> for return-stmt, and also a little special on assign-stmt. And phi
> >> >> >> stmts are not checked by ipa-sra/tree-sra. 2. For the access
> >> >> >> structure,
> >> >> >> I'm also thinking if we need a tree structure; it would be useful
> >> >> >> when
> >> >> >> checking overlaps, it was not used now in the expander-sra.
> >> >> >>
> >> >> >> For ipa-sra and tree-sra, I notice that there is some similar code,
> >> >> >> but of cause there are differences. While it seems the difference
> >> >> >> is 'intended', for example: 1. when creating and accessing,
> >> >> >> 'size != max_size' is acceptable in tree-sra but not for ipa-sra.
> >> >> >> 2. 'AGGREGATE_TYPE_P' for ipa-sra is accepted for some cases, but
> >> >> >> not ok for tree-ipa.
> >> >> >> I'm wondering if those slight difference blocks re-use the code
> >> >> >> between ipa-sra and tree-sra.
> >> >> >>
> >> >> >> The expander-sra may be more light, for example, maybe we can use
> >> >> >> FOR_EACH_IMM_USE_STMT to check the usage of each parameter, and not
> >> >> >> need to walk all the stmts.
> >> >> >
> >> >> > What I was hoping for is shared stmt-level analysis and a shared
> >> >> > data structure for the "access"(es) a stmt performs. Because that
> >> >> > can come up handy in multiple places. The existing SRA data
> >> >> > structures could easily embed that subset for example if sharing
> >> >> > the whole data structure of [IPA] SRA seems too unwieldly.
> >> >>
> >> >> Understand.
> >> >> The stmt-level analysis and "access" data structure are similar
> >> >> between ipa-sra/tree-sra and the expander-sra.
> >> >>
> >> >> I just update the patch, this version does not change the behaviors of
> >> >> the previous version. It is just cleaning/merging some functions only.
> >> >> The patch is attached.
> >> >>
> >> >> This version (and tree-sra/ipa-sra) is still using the similar
> >> >> "stmt analyze" and "access struct"". This could be extracted as
> >> >> shared code.
> >> >> I'm thinking to update the code to use the same "base_access" and
> >> >> "walk function".
> >> >>
> >> >> >
> >> >> > With a stmt-leve API using FOR_EACH_IMM_USE_STMT would still be
> >> >> > possible (though RTL expansion pre-walks all stmts anyway).
> >> >>
> >> >> Yeap, I also notice that "FOR_EACH_IMM_USE_STMT" is not enough.
> >> >> For struct parameters, walking stmt is needed.
> >> >
> >> > I think I mentioned this before, RTL expansion already
> >> > pre-walks the whole function looking for variables it has to
> >> > expand to the stack in discover_nonconstant_array_refs (which is
> >> > now badly named), I'd appreciate if the "SRA" walk would piggy-back
> >> > on that existing walk.
> >>
> >> I may misunderstand your meaning about 'stmt-level analysis' and
> >> 'pre-walk'.
> >> I understand it as 'walk to analyze each stmt in each bb'.
> >> In 'discover_nonconstant_array_refs', there is a 'walk_gimple_op':
> >>
> >> FOR_EACH_BB_FN (bb, cfun)
> >> for (gsi = gsi_start_bb (bb); !gsi_end_p (gsi); gsi_next (&gsi))
> >>{
> >> gimple *stmt = gsi_stmt (gsi);
> >> if (!is_gimple_debug (stmt))
> >> {
> >> walk_gimple_op (stmt, discover_nonconstant_array_refs_r, &wi);
> >>
> >> Maybe, this 'walk_gimple_op' is what you mentioned as 'stmt-level
> >> analysis' and the 'pre-walk'. Is this right?
> >>
> >> Here, 'discover_nonconstant_array_refs_r' is the callback of
> >> 'walk_gimple_op'.
> >> This callback analyses if an array is accessed through a variant index,
> >> if so, the array must be put into the stack.
> >>
> >> While it seems 'walk_gimple_op' is not ok for SRA analysis,
> >> because, in the callback, it is hard to analyze an access is
> >> 'read' or 'write' to an struct object. But the 'read/write' info
> >> is needed for SRA.
> >>
> >> 'walk_stmt_load_store_addr_ops' is another 'walk on stmt ops'.
> >> This 'walk' is not used to analyze SRA access, the primary reason
> >> would be: the load/store/addr parameter of the callback is a
> >> DECL, the 'size' and 'offset' are stripped.
> >>
> >> Currently, in tree-sra/ipa-sra/expand-sra, when analyzing stmt
> >> for SRA access, stmt code is checked for 'return/assign/call/asm'.
> >> And sub-e
Re: [PATCH] MATCH: Extend min_value/max_value to pointer types
On Sat, Aug 5, 2023 at 10:44 PM Andrew Pinski via Gcc-patches
wrote:
>
> Since we already had the infrastructure to optimize
> `(x == 0) && (x > y)` to false for integer types,
> this extends the same to pointer types as indirectly
> requested by PR 96695.
>
> OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.
OK.
Thanks,
Richard.
> gcc/ChangeLog:
>
> PR tree-optimization/96695
> * match.pd (min_value, max_value): Extend to
> pointer types too.
>
> gcc/testsuite/ChangeLog:
>
> PR tree-optimization/96695
> * gcc.dg/pr96695-1.c: New test.
> * gcc.dg/pr96695-10.c: New test.
> * gcc.dg/pr96695-11.c: New test.
> * gcc.dg/pr96695-12.c: New test.
> * gcc.dg/pr96695-2.c: New test.
> * gcc.dg/pr96695-3.c: New test.
> * gcc.dg/pr96695-4.c: New test.
> * gcc.dg/pr96695-5.c: New test.
> * gcc.dg/pr96695-6.c: New test.
> * gcc.dg/pr96695-7.c: New test.
> * gcc.dg/pr96695-8.c: New test.
> * gcc.dg/pr96695-9.c: New test.
> ---
> gcc/match.pd | 6 --
> gcc/testsuite/gcc.dg/pr96695-1.c | 18 ++
> gcc/testsuite/gcc.dg/pr96695-10.c | 20
> gcc/testsuite/gcc.dg/pr96695-11.c | 18 ++
> gcc/testsuite/gcc.dg/pr96695-12.c | 18 ++
> gcc/testsuite/gcc.dg/pr96695-2.c | 18 ++
> gcc/testsuite/gcc.dg/pr96695-3.c | 20
> gcc/testsuite/gcc.dg/pr96695-4.c | 21 +
> gcc/testsuite/gcc.dg/pr96695-5.c | 19 +++
> gcc/testsuite/gcc.dg/pr96695-6.c | 20
> gcc/testsuite/gcc.dg/pr96695-7.c | 19 +++
> gcc/testsuite/gcc.dg/pr96695-8.c | 19 +++
> gcc/testsuite/gcc.dg/pr96695-9.c | 20
> 13 files changed, 234 insertions(+), 2 deletions(-)
> create mode 100644 gcc/testsuite/gcc.dg/pr96695-1.c
> create mode 100644 gcc/testsuite/gcc.dg/pr96695-10.c
> create mode 100644 gcc/testsuite/gcc.dg/pr96695-11.c
> create mode 100644 gcc/testsuite/gcc.dg/pr96695-12.c
> create mode 100644 gcc/testsuite/gcc.dg/pr96695-2.c
> create mode 100644 gcc/testsuite/gcc.dg/pr96695-3.c
> create mode 100644 gcc/testsuite/gcc.dg/pr96695-4.c
> create mode 100644 gcc/testsuite/gcc.dg/pr96695-5.c
> create mode 100644 gcc/testsuite/gcc.dg/pr96695-6.c
> create mode 100644 gcc/testsuite/gcc.dg/pr96695-7.c
> create mode 100644 gcc/testsuite/gcc.dg/pr96695-8.c
> create mode 100644 gcc/testsuite/gcc.dg/pr96695-9.c
>
> diff --git a/gcc/match.pd b/gcc/match.pd
> index 2278029d608..de54b17abba 100644
> --- a/gcc/match.pd
> +++ b/gcc/match.pd
> @@ -2733,12 +2733,14 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
>
> (match min_value
> INTEGER_CST
> - (if (INTEGRAL_TYPE_P (type)
> + (if ((INTEGRAL_TYPE_P (type)
> + || POINTER_TYPE_P(type))
>&& wi::eq_p (wi::to_wide (t), wi::min_value (type)
>
> (match max_value
> INTEGER_CST
> - (if (INTEGRAL_TYPE_P (type)
> + (if ((INTEGRAL_TYPE_P (type)
> + || POINTER_TYPE_P(type))
>&& wi::eq_p (wi::to_wide (t), wi::max_value (type)
>
> /* x > y && x != XXX_MIN --> x > y
> diff --git a/gcc/testsuite/gcc.dg/pr96695-1.c
> b/gcc/testsuite/gcc.dg/pr96695-1.c
> new file mode 100644
> index 000..d4287ab4c8c
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/pr96695-1.c
> @@ -0,0 +1,18 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -fdump-tree-ifcombine" } */
> +
> +#include
> +
> +_Bool and1(unsigned *x, unsigned *y)
> +{
> + /* x > y && x != 0 --> x > y */
> + return x > y && x != 0;
> +}
> +
> +_Bool and2(unsigned *x, unsigned *y)
> +{
> + /* x < y && x != -1 --> x < y */
> + return x < y && x != (unsigned*)-1;
> +}
> +
> +/* { dg-final { scan-tree-dump-not " != " "ifcombine" } } */
> diff --git a/gcc/testsuite/gcc.dg/pr96695-10.c
> b/gcc/testsuite/gcc.dg/pr96695-10.c
> new file mode 100644
> index 000..dfe752526f0
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/pr96695-10.c
> @@ -0,0 +1,20 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -fdump-tree-optimized" } */
> +
> +#include
> +
> +_Bool or1(unsigned *x, unsigned *y)
> +{
> + /* x <= y || x != 0 --> true */
> + return x <= y || x != 0;
> +}
> +
> +_Bool or2(unsigned *x, unsigned *y)
> +{
> + /* x >= y || x != -1 --> true */
> + return x >= y || x != (unsigned*)-1;
> +}
> +
> +/* { dg-final { scan-tree-dump-not " != " "optimized" } } */
> +/* { dg-final { scan-tree-dump-not " <= " "optimized" } } */
> +/* { dg-final { scan-tree-dump-not " >= " "optimized" } } */
> diff --git a/gcc/testsuite/gcc.dg/pr96695-11.c
> b/gcc/testsuite/gcc.dg/pr96695-11.c
> new file mode 100644
> index 000..d3c36168b98
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/pr96695-11.c
> @@ -0,0 +1,18 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -fdump-tree-ifcombine" } */
> +
> +#include
> +
> +_Bool or1(unsigned *x, unsigned *y)
> +{
> +
Re: [PATCH] Add -Wdisabled-optimization warning for not optimizing sibling calls
On Sat, Aug 5, 2023 at 11:54 PM David Malcolm via Gcc-patches
wrote:
>
> On Sun, 2023-08-06 at 02:28 +0530, Prathamesh Kulkarni via Gcc-patches
> wrote:
> > On Fri, 4 Aug 2023 at 23:28, Bradley Lucier via Gcc-patches
> > wrote:
>
> Hi Bradley and Prathamesh...
>
> > >
> > > The patch at the end adds a warning when a tail/sibling call cannot
> > > be
> > > optimized for various reasons.
> > >
> > > I built and tested GCC with and without the patch with
> > > configuration
> > >
> > > Configured with: ../../gcc-mainline/configure --enable-languages=c
> > > --disable-multilib --prefix=/pkgs/gcc-mainline --disable-werror
> > >
> > > There were some changes in the test results, but I can't say that
> > > they
> > > look substantive:
> > >
>
> [...]
>
> > >
> > > to test the new warning. The warnings are of the form, e.g.,
> > >
> > > ../../../gcc-mainline/gcc/tree-vect-stmts.cc:11990:44: warning:
> > > cannot
> > > apply sibling-call optimization: callee required more stack slots
> > > than
> > > the caller [-Wdisabled-optimization]
> > >
> > > These are the number of times this warning was triggered building
> > > stage1:
> > >
> > > grep warning: build.log | grep sibling | sed 's/^.*://' | sort |
> > > uniq -c
> > > 259 callee required more stack slots than the caller
> > > [-Wdisabled-optimization]
> > > 43 callee returns a structure [-Wdisabled-optimization]
> > >
> > > If this patch is OK, someone else will need to commit it for me.
> > >
> > > Brad
> > >
> > > gcc/Changelog
> > >
> > > * calls.cc (maybe_complain_about_tail_call) Add warning
> > > when
> > > tail or sibling call cannot be optimized.
> > Hi Bradley,
> > I don't have comments on the patch, but a new warning will also
> > require a corresponding entry in doc/invoke.texi.
>
> To nitpick, this isn't a new warning; the patch is extending an
> existing warning. Looking at the existing entry for that warning I
> see:
>
> @opindex Wdisabled-optimization
> @opindex Wno-disabled-optimization
> @item -Wdisabled-optimization
> Warn if a requested optimization pass is disabled. This warning does
> not generally indicate that there is anything wrong with your code; it
> merely indicates that GCC's optimizers are unable to handle the code
> effectively. Often, the problem is that your code is too big or too
> complex; GCC refuses to optimize programs when the optimization
> itself is likely to take inordinate amounts of time.
>
> ...which arguably fits the new functionality. Though I don't know how
> the optimizer maintainers feel about it. Also, as we add more stuff to
> this warning, would users need more fine-grained control over which
> things for the optimizer to complain about? I'm not sure.
I don't think this specific case qualifies for -Wdisabled-optimization.
The diagnostic is for cases the user can control and was invented
for limits we put up for compile-time and memory-usage issues
where there exist --param XYZ to adjust limits.
It would be more appropriate to change this to
dump_printf_loc (MSG_MISSED_OPTIMIZATION, ...)
where this was designe to diagnose cases the compiler failed to
optimize for other reasons than running into some --param.
So, NAK.
Thanks,
Richard.
> >
> > Thanks,
> > Prathamesh
> > >
> > > diff --git a/gcc/calls.cc b/gcc/calls.cc
> > > index 1f3a6d5c450..b95c876fda8 100644
> > > --- a/gcc/calls.cc
> > > +++ b/gcc/calls.cc
> > > @@ -1242,10 +1242,12 @@ void
> > > maybe_complain_about_tail_call (tree call_expr, const char
> > > *reason)
> > > {
> > > gcc_assert (TREE_CODE (call_expr) == CALL_EXPR);
> > > - if (!CALL_EXPR_MUST_TAIL_CALL (call_expr))
> > > -return;
> > > -
> > > - error_at (EXPR_LOCATION (call_expr), "cannot tail-call: %s",
> > > reason);
> > > + if (CALL_EXPR_MUST_TAIL_CALL (call_expr))
> > > +error_at (EXPR_LOCATION (call_expr), "cannot tail-call: %s",
> > > reason);
>
> The existing code use error_at, passing it the location of the
> call_expr...
>
> > > + else if (flag_optimize_sibling_calls)
> > > +warning (OPT_Wdisabled_optimization,
> > > + "cannot apply sibling-call optimization: %s",
> > > reason);
>
> ...but the warning branch uses "warning", which implicitly uses the
> input_location global variable. Is the warning reported at the correct
> place? It's better to use warning_at and pass it the location at which
> the warning should be emitted.
>
> The patch doesn't add any test cases, but I imagine any such cases
> would be very target-dependent (did I add any to my libgccjit version
> of this way back when?)
>
> Thanks for the patch; hope this is constructive
> Dave
>
>
>
> > > + return;
> > > }
> > >
> > > /* Fill in ARGS_SIZE and ARGS array based on the parameters found
> > > in
> > >
> > >
> >
>
Re: [PATCH 2/3] RISC-V: Part-2: Save/Restore vector registers which need to be preversed
Hi Kito, > > +machine_mode m1_mode = TARGET_VECTOR_ELEN_64 > > +? (TARGET_MIN_VLEN >= 128 ? VNx2DImode : VNx1DImode) > > +: VNx1SImode; > This should update since JuZhe has update the mode system :P Yes, thanks reminder. > > @@ -5907,7 +6057,7 @@ riscv_expand_epilogue (int style) > > Start off by assuming that no registers need to be restored.*/ > >struct riscv_frame_info *frame = &cfun->machine->frame; > >unsigned mask = frame->mask; > > -HOST_WIDE_INT step2 = 0; > > +poly_int64 step2 = 0; > I saw we check `step2.to_constant () > 0` later, does it mean step2 is > always a scalar rather than a poly number? > If so, I would suggest keeping HOST_WIDE_INT if possible. step2 will be reduced by `riscv_for_each_saved_v_reg (step2, riscv_restore_reg, false);` before `step2.to_constant () > 0`. After `riscv_for_each_saved_v_reg`, the step2 must be a constant. So step2 may be a poly number if there are any length agnostic vector registers that need to be saved. Best, Lehua
PR target/107671: Make more use of btl/btq on x86_64.
This patch is a partial solution to PR target/107671, updating Uros'
patch from comment #4, to catch both bit set (setc) and bit not set
(setnc) cases from the code in comment #2, when compiled on x86_64.
Unfortunately, this is a partial solution, as the pointer variants
in comment #1, aren't yet all optimized, and my attempts to check
whether the 32-bit versions are optimized with -m32 revealed they
also need further improvement. (Some of) These remaining issues
might best be fixed in the middle-end, in either match.pd or the
RTL optimizers, so I thought it reasonable to submit this independent
backend piece, and gain/bank the improvements on x86_64.
This patch has been tested on x86_64-pc-linux-gnu with make bootstrap
and make -k check, both with and without --target_board=unix{-m32}
with no new failures. Ok for mainline?
2023-08-07 Roger Sayle
Uros Bizjak
gcc/ChangeLog
PR target/107671
* config/i386/i386.md (*bt_setc_mask): Allow the
shift count to have a different mode (using SWI248) from either
the bit-test or the result.
(*bt_setnc_mask): New define_insn_and_split for the
setnc (bit not set) case of the above pattern.
(*btdi_setncsi_mask): New define_insn_and_split to handle the
SImode result from a DImode bit-test variant of the above patterns.
(*bt_setncqi_mask_2): New define_insn_and_split for the
setnc (bit not set) version of *bt_setcqi_mask_2.
gcc/testsuite/ChangeLog
PR target/107671
* gcc.target/i386/pr107671-1.c: New test case.
* gcc.target/i386/pr107671-2.c: Likewise.
Roger
--
diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index ba376f8..aa8946a 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -16405,19 +16405,19 @@
(ne:QI (reg:CCC FLAGS_REG) (const_int 0)))])
;; Help combine recognize bt followed by setc
-(define_insn_and_split "*bt_setc_mask"
+(define_insn_and_split "*bt_setc_mask"
[(set (match_operand:SWI48 0 "register_operand")
(zero_extract:SWI48
(match_operand:SWI48 1 "register_operand")
(const_int 1)
(subreg:QI
- (and:SWI48
- (match_operand:SWI48 2 "register_operand")
+ (and:SWI248
+ (match_operand:SWI248 2 "register_operand")
(match_operand 3 "const_int_operand")) 0)))
(clobber (reg:CC FLAGS_REG))]
"TARGET_USE_BT
- && (INTVAL (operands[3]) & (GET_MODE_BITSIZE (mode)-1))
- == GET_MODE_BITSIZE (mode)-1
+ && (INTVAL (operands[3]) & (GET_MODE_BITSIZE (mode)-1))
+ == GET_MODE_BITSIZE (mode)-1
&& ix86_pre_reload_split ()"
"#"
"&& 1"
@@ -16432,6 +16432,90 @@
operands[2] = gen_lowpart (QImode, operands[2]);
operands[3] = gen_reg_rtx (QImode);
})
+
+;; Help combine recognize bt followed by setnc
+(define_insn_and_split "*bt_setnc_mask"
+ [(set (match_operand:SWI48 0 "register_operand")
+ (and:SWI48
+ (not:SWI48
+ (lshiftrt:SWI48
+ (match_operand:SWI48 1 "register_operand")
+ (subreg:QI
+ (and:SWI248 (match_operand:SWI248 2 "register_operand")
+ (match_operand 3 "const_int_operand")) 0)))
+ (const_int 1)))
+ (clobber (reg:CC FLAGS_REG))]
+ "TARGET_USE_BT
+ && (INTVAL (operands[3]) & (GET_MODE_BITSIZE (mode)-1))
+ == GET_MODE_BITSIZE (mode)-1
+ && ix86_pre_reload_split ()"
+ "#"
+ "&& 1"
+ [(set (reg:CCC FLAGS_REG)
+(compare:CCC
+ (zero_extract:SWI48 (match_dup 1) (const_int 1) (match_dup 2))
+ (const_int 0)))
+ (set (match_dup 3)
+(ne:QI (reg:CCC FLAGS_REG) (const_int 0)))
+ (set (match_dup 0) (zero_extend:SWI48 (match_dup 3)))]
+{
+ operands[2] = gen_lowpart (QImode, operands[2]);
+ operands[3] = gen_reg_rtx (QImode);
+})
+
+;; Help combine recognize bt followed by setnc
+(define_insn_and_split "*btdi_setncsi_mask"
+ [(set (match_operand:SI 0 "register_operand")
+ (and:SI
+ (not:SI
+ (subreg:SI
+ (lshiftrt:DI (match_operand:DI 1 "register_operand")
+ (subreg:QI
+(and:SWI248
+ (match_operand:SWI248 2 "register_operand")
+ (const_int 63)) 0)) 0))
+ (const_int 1)))
+ (clobber (reg:CC FLAGS_REG))]
+ "TARGET_64BIT && TARGET_USE_BT && ix86_pre_reload_split ()"
+ "#"
+ "&& 1"
+ [(set (reg:CCC FLAGS_REG)
+(compare:CCC
+ (zero_extract:DI (match_dup 1) (const_int 1) (match_dup 2))
+ (const_int 0)))
+ (set (match_dup 3)
+(ne:QI (reg:CCC FLAGS_REG) (const_int 0)))
+ (set (match_dup 0) (zero_extend:SI (match_dup 3)))]
+{
+ operands[2] = gen_lowpart (QImode, operands[2]);
+ operands[3] = gen_reg_rtx (QImode);
+})
+
+;; Help combine recognize bt followed by setnc
+(define_insn_and_split "*bt_setncqi_mask_2"
+ [(set (match_operand:QI 0 "register_oper
Re: [PATCH][RFC] tree-optimization/92335 - Improve sinking heuristics for vectorization
On Mon, Aug 7, 2023 at 2:05 AM Prathamesh Kulkarni via Gcc-patches
wrote:
>
> On Thu, 3 Aug 2023 at 17:48, Richard Biener wrote:
> >
> > On Thu, 3 Aug 2023, Richard Biener wrote:
> >
> > > On Thu, 3 Aug 2023, Richard Biener wrote:
> > >
> > > > On Thu, 3 Aug 2023, Prathamesh Kulkarni wrote:
> > > >
> > > > > On Wed, 2 Aug 2023 at 14:17, Richard Biener via Gcc-patches
> > > > > wrote:
> > > > > >
> > > > > > On Mon, 31 Jul 2023, Jeff Law wrote:
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On 7/28/23 01:05, Richard Biener via Gcc-patches wrote:
> > > > > > > > The following delays sinking of loads within the same innermost
> > > > > > > > loop when it was unconditional before. That's a not uncommon
> > > > > > > > issue preventing vectorization when masked loads are not
> > > > > > > > available.
> > > > > > > >
> > > > > > > > Bootstrapped and tested on x86_64-unknown-linux-gnu.
> > > > > > > >
> > > > > > > > I have a followup patch improving sinking that without this
> > > > > > > > would
> > > > > > > > cause more of the problematic sinking - now that we have a
> > > > > > > > second
> > > > > > > > sink pass after loop opts this looks like a reasonable approach?
> > > > > > > >
> > > > > > > > OK?
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > > Richard.
> > > > > > > >
> > > > > > > > PR tree-optimization/92335
> > > > > > > > * tree-ssa-sink.cc (select_best_block): Before loop
> > > > > > > > optimizations avoid sinking unconditional loads/stores
> > > > > > > > in innermost loops to conditional executed places.
> > > > > > > >
> > > > > > > > * gcc.dg/tree-ssa/ssa-sink-10.c: Disable vectorizing.
> > > > > > > > * gcc.dg/tree-ssa/predcom-9.c: Clone from ssa-sink-10.c,
> > > > > > > > expect predictive commoning to happen instead of sinking.
> > > > > > > > * gcc.dg/vect/pr65947-3.c: Adjust.
> > > > > > > I think it's reasonable -- there's probably going to be cases
> > > > > > > where it's not
> > > > > > > great, but more often than not I think it's going to be a
> > > > > > > reasonable
> > > > > > > heuristic.
> > > > > > >
> > > > > > > If there is undesirable fallout, better to find it over the
> > > > > > > coming months than
> > > > > > > next spring. So I'd suggest we go forward now to give more time
> > > > > > > to find any
> > > > > > > pathological cases (if they exist).
> > > > > >
> > > > > > Agreed, I've pushed this now.
> > > > > Hi Richard,
> > > > > After this patch (committed in
> > > > > 399c8dd44ff44f4b496223c7cc980651c4d6f6a0),
> > > > > pr65947-7.c "failed" for aarch64-linux-gnu:
> > > > > FAIL: gcc.dg/vect/pr65947-7.c scan-tree-dump-not vect "LOOP
> > > > > VECTORIZED"
> > > > > FAIL: gcc.dg/vect/pr65947-7.c -flto -ffat-lto-objects
> > > > > scan-tree-dump-not vect "LOOP VECTORIZED"
> > > > >
> > > > > /* { dg-final { scan-tree-dump-not "LOOP VECTORIZED" "vect" { target {
> > > > > ! vect_fold_extract_last } } } } */
> > > > >
> > > > > With your commit, condition_reduction in pr65947-7.c gets vectorized
> > > > > regardless of vect_fold_extract_last,
> > > > > which gates the above test (which is an improvement, because the
> > > > > function didn't get vectorized before the commit).
> > > > >
> > > > > The attached patch thus removes the gating on vect_fold_extract_last,
> > > > > and the test passes again.
> > > > > OK to commit ?
> > > >
> > > > OK.
> > >
> > > Or wait - the loop doesn't vectorize on x86_64, so I guess one
> > > critical target condition is missing. Can you figure out which?
> >
> > I see
> >
> > /space/rguenther/src/gcc/gcc/testsuite/gcc.dg/vect/pr65947-7.c:18:21:
> > note: vect_is_simple_use: operand last_19 = PHI ,
> > type of def: reduction
> > /space/rguenther/src/gcc/gcc/testsuite/gcc.dg/vect/pr65947-7.c:18:21:
> > note: vect_is_simple_use: vectype vector(4) int
> > /space/rguenther/src/gcc/gcc/testsuite/gcc.dg/vect/pr65947-7.c:18:21:
> > missed: multiple types in double reduction or condition reduction or
> > fold-left reduction.
> > /space/rguenther/src/gcc/gcc/testsuite/gcc.dg/vect/pr65947-7.c:13:1:
> > missed: not vectorized: relevant phi not supported: last_19 = PHI
> >
> > /space/rguenther/src/gcc/gcc/testsuite/gcc.dg/vect/pr65947-7.c:18:21:
> > missed: bad operation or unsupported loop bound.
> Hi Richard,
> Looking at the aarch64 vect dump, it seems the loop in
> condition_reduction gets vectorized with V4HI mode
> while fails for other modes in vectorizable_condition:
>
> if ((double_reduc || reduction_type != TREE_CODE_REDUCTION)
> && ncopies > 1)
> {
> if (dump_enabled_p ())
> dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,
> "multiple types in double reduction or condition "
> "reduction or fold-left reduction.\n");
> return false;
> }
>
> From the dump:
> foo.c:9:21: note: === vect_analyze_loop_operations ===
> foo.c:9:21: note: examining phi: last_19 = PHI
> foo.c:9:21: note: vect_is_simpl
Re: [PATCH] MATCH: [PR109959] `(uns <= 1) & uns` could be optimized to `uns == 1`
On Mon, Aug 7, 2023 at 7:07 AM Andrew Pinski via Gcc-patches
wrote:
>
> I noticed while looking into some code generation of bitmap_single_bit_set_p,
> that sometimes:
> ```
> if (uns > 1)
> return 0;
> return uns == 1;
> ```
> Would not optimize down to just:
> ```
> return uns == 1;
> ```
>
> In this case, VRP likes to change `a == 1` into `(bool)a` if
> a has a range of [0,1] due to `a <= 1` side of the branch.
> We might end up with this similar code even without VRP,
> in the case of builtin-sprintf-warn-23.c (and Wrestrict.c), we had:
> ```
> if (s < 0 || 1 < s)
> s = 0;
> ```
> Which is the same as `s = ((unsigned)s) <= 1 ? s : 0`;
> So we should be able to catch that also.
>
> This adds 2 patterns to catch `(uns <= 1) & uns` and
> `(uns > 1) ? 0 : uns` and convert those into:
> `(convert) uns == 1`.
>
> OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.
OK.
Thanks,
Richard.
> PR tree-optimization/109959
>
> gcc/ChangeLog:
>
> * match.pd (`(a > 1) ? 0 : (cast)a`, `(a <= 1) & (cast)a`):
> New patterns.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.dg/tree-ssa/builtin-sprintf-warn-23.c: Remove xfail.
> * c-c++-common/Wrestrict.c: Update test and remove some xfail.
> * gcc.dg/tree-ssa/cmpeq-1.c: New test.
> * gcc.dg/tree-ssa/cmpeq-2.c: New test.
> * gcc.dg/tree-ssa/cmpeq-3.c: New test.
> ---
> gcc/match.pd | 20 +++
> gcc/testsuite/c-c++-common/Wrestrict.c| 11 +++---
> .../gcc.dg/tree-ssa/builtin-sprintf-warn-23.c | 2 +-
> gcc/testsuite/gcc.dg/tree-ssa/cmpeq-1.c | 36 +++
> gcc/testsuite/gcc.dg/tree-ssa/cmpeq-2.c | 32 +
> gcc/testsuite/gcc.dg/tree-ssa/cmpeq-3.c | 22
> 6 files changed, 117 insertions(+), 6 deletions(-)
> create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/cmpeq-1.c
> create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/cmpeq-2.c
> create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/cmpeq-3.c
>
> diff --git a/gcc/match.pd b/gcc/match.pd
> index de54b17abba..9b4819e5be7 100644
> --- a/gcc/match.pd
> +++ b/gcc/match.pd
> @@ -4902,6 +4902,26 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
> )
> )
>
> +/* (a > 1) ? 0 : (cast)a is the same as (cast)(a == 1)
> + for unsigned types. */
> +(simplify
> + (cond (gt @0 integer_onep@1) integer_zerop (convert? @2))
> + (if (TYPE_UNSIGNED (TREE_TYPE (@0))
> + && bitwise_equal_p (@0, @2))
> + (convert (eq @0 @1))
> + )
> +)
> +
> +/* (a <= 1) & (cast)a is the same as (cast)(a == 1)
> + for unsigned types. */
> +(simplify
> + (bit_and:c (convert1? (le @0 integer_onep@1)) (convert2? @2))
> + (if (TYPE_UNSIGNED (TREE_TYPE (@0))
> + && bitwise_equal_p (@0, @2))
> + (convert (eq @0 @1))
> + )
> +)
> +
> (simplify
> (cond @0 zero_one_valued_p@1 zero_one_valued_p@2)
> (switch
> diff --git a/gcc/testsuite/c-c++-common/Wrestrict.c
> b/gcc/testsuite/c-c++-common/Wrestrict.c
> index 9eb02bdbfcb..4d005a618b3 100644
> --- a/gcc/testsuite/c-c++-common/Wrestrict.c
> +++ b/gcc/testsuite/c-c++-common/Wrestrict.c
> @@ -681,7 +681,7 @@ void test_strcpy_range (void)
>ptrdiff_t r;
>
>r = SR (0, 1);
> - T (8, "0", a + r, a); /* { dg-warning "accessing between 1 and 2 bytes
> at offsets \\\[0, 1] and 0 overlaps up to 2 bytes at offset \\\[0, 1]"
> "strcpy" { xfail *-*-*} } */
> + T (8, "0", a + r, a); /* { dg-warning "accessing 2 bytes at offsets
> \\\[0, 1] and 0 overlaps between 1 and 2 bytes at offset \\\[0, 1]" "strcpy"
> } */
>
>r = SR (2, 5);
>T (8, "01", a + r, a);/* { dg-warning "accessing 3 bytes at
> offsets \\\[2, 5] and 0 may overlap 1 byte at offset 2" } */
> @@ -860,10 +860,11 @@ void test_strncpy_range (char *d, size_t n)
>
>i = SR (0, 1);
>T ("0123", a, a + i, 0);
> - T ("0123", a, a + i, 1);
> - /* Offset in the range [0, i] is represented as a PHI (&a, &a + i)
> - that the implementation isn't equipped to handle yet. */
> - T ("0123", a, a + i, 2); /* { dg-warning "accessing 2 bytes at offsets 0
> and \\\[0, 1] may overlap 1 byte at offset 1" "strncpy" { xfail *-*-* } } */
> + T ("0123", a, a + i, 1); /* { dg-warning "accessing 1 byte at offsets 0
> and \\\[0, 1] may overlap 1 byte at offset 0" } */
> + /* When i == 1 the following overlaps at least 1 byte: the nul at a[1]
> + (if a + 1 is the empty string). If a + 1 is not empty then it overlaps
> + it plus as many non-nul characters after it, up to the total of 2. */
> + T ("0123", a, a + i, 2); /* { dg-warning "accessing 2 bytes at offsets 0
> and \\\[0, 1] overlaps between 1 and 2 bytes at offset \\\[0, 1]" "strncpy" }
> */
>
>i = SR (1, 5);
>T ("0123", a, a + i, 0);
> diff --git a/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-23.c
> b/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-23.c
> index 112b08afc44..051c58892e6 100644
> --- a/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-23.c
> +++ b/
Re: [PATCH 1/3] RISC-V: Part-1: Select suitable vector registers for vector type args and returns
Thanks for the high quality patch, it's generally LGTM, only a few minor comments :) > + /* The number and alignment of vector registers need for this scalable > vector > + argument. When the mode size is less than a full vector, we use 1 vector > + register to pass. Just call TARGET_HARD_REGNO_NREGS for the number > + infomation. */ gmail told me here is a typo: information :P > + int nregs = riscv_hard_regno_nregs (V_ARG_FIRST, mode); > + int LMUL = riscv_v_ext_tuple_mode_p (mode) > + ? nregs / riscv_vector::get_nf (mode) > + : nregs; > + int arg_reg_start = V_ARG_FIRST - V_REG_FIRST; > + int arg_reg_end = V_ARG_LAST - V_REG_FIRST; > + int aligned_reg_start = (arg_reg_start + LMUL - 1) & -LMUL; Use` ROUND_UP (arg_reg_start, LMUL)`
[PATCH] Fix ICE in rtl check when bootstrap.
/var/tmp/portage/sys-devel/gcc-14.0.0_pre20230806/work/gcc-14-20230806/libgfortran/generated/matmul_i1.c:
In function ‘matmul_i1_avx512f’:
/var/tmp/portage/sys-devel/gcc-14.0.0_pre20230806/work/gcc-14-20230806/libgfortran/generated/matmul_i1.c:1781:1:
internal compiler error: RTL check: expected elt 0 type 'i' or 'n', have 'w'
(rtx const_int) in vpternlog_redundant_operand_mask, at
config/i386/i386.cc:19460
1781 | }
| ^
0x5559de26dc2d rtl_check_failed_type2(rtx_def const*, int, int, int, char
const*, int, char const*)
/var/tmp/portage/sys-devel/gcc-14.0.0_pre20230806/work/gcc-14-20230806/gcc/rtl.cc:761
0x5559de340bfe vpternlog_redundant_operand_mask(rtx_def**)
/var/tmp/portage/sys-devel/gcc-14.0.0_pre20230806/work/gcc-14-20230806/gcc/config/i386/i386.cc:19460
0x5559dfec67a6 split_44
/var/tmp/portage/sys-devel/gcc-14.0.0_pre20230806/work/gcc-14-20230806/gcc/config/i386/sse.md:12730
0x5559dfec67a6 split_63
/var/tmp/portage/sys-devel/gcc-14.0.0_pre20230806/work/gcc-14-20230806/gcc/config/i386/sse.md:28428
0x5559deb8a682 try_split(rtx_def*, rtx_insn*, int)
/var/tmp/portage/sys-devel/gcc-14.0.0_pre20230806/work/gcc-14-20230806/gcc/emit-rtl.cc:3800
0x5559deb8adf2 try_split(rtx_def*, rtx_insn*, int)
/var/tmp/portage/sys-devel/gcc-14.0.0_pre20230806/work/gcc-14-20230806/gcc/emit-rtl.cc:3972
0x5559def69194 split_insn
/var/tmp/portage/sys-devel/gcc-14.0.0_pre20230806/work/gcc-14-20230806/gcc/recog.cc:3385
0x5559def70c57 split_all_insns()
/var/tmp/portage/sys-devel/gcc-14.0.0_pre20230806/work/gcc-14-20230806/gcc/recog.cc:3489
0x5559def70d0c execute
/var/tmp/portage/sys-devel/gcc-14.0.0_pre20230806/work/gcc-14-20230806/gcc/recog.cc:4413
Use INTVAL (imm_op) instead of XINT (imm_op, 0).
Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
Ok for trunk?
gcc/ChangeLog:
* config/i386/i386-protos.h (vpternlog_redundant_operand_mask):
Adjust parameter type.
* config/i386/i386.cc (vpternlog_redundant_operand_mask): Use
INTVAL instead of XINT, also adjust parameter type from rtx* to
rtx since the function only needs operands[4] in vpternlog
pattern.
(substitute_vpternlog_operands): Pass operands[4] instead of
operands to vpternlog_redundant_operand_mask
* config/i386/sse.md: Ditto.
---
gcc/config/i386/i386-protos.h | 2 +-
gcc/config/i386/i386.cc | 6 +++---
gcc/config/i386/sse.md| 4 ++--
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/gcc/config/i386/i386-protos.h b/gcc/config/i386/i386-protos.h
index e547ee64587..fc2f1f13b78 100644
--- a/gcc/config/i386/i386-protos.h
+++ b/gcc/config/i386/i386-protos.h
@@ -70,7 +70,7 @@ extern machine_mode ix86_cc_mode (enum rtx_code, rtx, rtx);
extern int avx_vpermilp_parallel (rtx par, machine_mode mode);
extern int avx_vperm2f128_parallel (rtx par, machine_mode mode);
-extern int vpternlog_redundant_operand_mask (rtx[]);
+extern int vpternlog_redundant_operand_mask (rtx);
extern void substitute_vpternlog_operands (rtx[]);
extern bool ix86_expand_strlen (rtx, rtx, rtx, rtx);
diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc
index 8cd26eb54fa..50860050049 100644
--- a/gcc/config/i386/i386.cc
+++ b/gcc/config/i386/i386.cc
@@ -19454,10 +19454,10 @@ avx_vperm2f128_parallel (rtx par, machine_mode mode)
/* Return a mask of VPTERNLOG operands that do not affect output. */
int
-vpternlog_redundant_operand_mask (rtx *operands)
+vpternlog_redundant_operand_mask (rtx pternlog_imm)
{
int mask = 0;
- int imm8 = XINT (operands[4], 0);
+ int imm8 = INTVAL (pternlog_imm);
if (((imm8 >> 4) & 0x0F) == (imm8 & 0x0F))
mask |= 1;
@@ -19475,7 +19475,7 @@ vpternlog_redundant_operand_mask (rtx *operands)
void
substitute_vpternlog_operands (rtx *operands)
{
- int mask = vpternlog_redundant_operand_mask (operands);
+ int mask = vpternlog_redundant_operand_mask (operands[4]);
if (mask & 1) /* The first operand is redundant. */
operands[1] = operands[2];
diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
index 7e2aa3f995c..c53450fd965 100644
--- a/gcc/config/i386/sse.md
+++ b/gcc/config/i386/sse.md
@@ -12706,7 +12706,7 @@ (define_split
(match_operand:V 3 "memory_operand")
(match_operand:SI 4 "const_0_to_255_operand")]
UNSPEC_VTERNLOG))]
- "!reload_completed && vpternlog_redundant_operand_mask (operands) == 3"
+ "!reload_completed && vpternlog_redundant_operand_mask (operands[4]) == 3"
[(set (match_dup 0)
(match_dup 3))
(set (match_dup 0)
@@ -12727,7 +12727,7 @@ (define_split
(match_operand:V 3 "nonimmediate_operand")
(match_operand:SI 4 "const_0_to_255_operand")]
UNSPEC_VTERNLOG))]
- "!reload_completed && vpternlog_redundant_operand_mask (operands) != 0"
+ "!reload_completed && vpternlog_redundant_operand_mask (operands[4]) != 0"
[(set (match_dup 0)
[PATCH] i386: Clear upper bits of XMM register for V4HFmode/V2HFmode operations [PR110762]
Similar like r14-2786-gade30fad6669e5, the patch is for V4HF/V2HFmode.
Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
Ok for trunk?
gcc/ChangeLog:
PR target/110762
* config/i386/mmx.md (3): Changed from define_insn
to define_expand and break into ..
(v4hf3): .. this.
(divv4hf3): .. this.
(v2hf3): .. this.
(divv2hf3): .. this.
(movd_v2hf_to_sse): New define_expand.
(movq__to_sse): Extend to V4HFmode.
(mmxdoublevecmode): Ditto.
(V2FI_V4HF): New mode iterator.
* config/i386/sse.md (*vec_concatv4sf): Extend to hanlde V8HF
by using mode iterator V4SF_V8HF, renamed to ..
(*vec_concat): .. this.
(*vec_concatv4sf_0): Extend to handle V8HF by using mode
iterator V4SF_V8HF, renamed to ..
(*vec_concat_0): .. this.
(*vec_concatv8hf_movss): New define_insn.
(V4SF_V8HF): New mode iterator.
gcc/testsuite/ChangeLog:
* gcc.target/i386/pr110762-v4hf.c: New test.
---
gcc/config/i386/mmx.md| 109 +++---
gcc/config/i386/sse.md| 40 +--
gcc/testsuite/gcc.target/i386/pr110762-v4hf.c | 57 +
3 files changed, 177 insertions(+), 29 deletions(-)
create mode 100644 gcc/testsuite/gcc.target/i386/pr110762-v4hf.c
diff --git a/gcc/config/i386/mmx.md b/gcc/config/i386/mmx.md
index 896af76a33f..88bdf084f54 100644
--- a/gcc/config/i386/mmx.md
+++ b/gcc/config/i386/mmx.md
@@ -79,9 +79,7 @@ (define_mode_iterator V_16_32_64
;; V2S* modes
(define_mode_iterator V2FI [V2SF V2SI])
-;; 4-byte and 8-byte float16 vector modes
-(define_mode_iterator VHF_32_64 [V4HF V2HF])
-
+(define_mode_iterator V2FI_V4HF [V2SF V2SI V4HF])
;; Mapping from integer vector mode to mnemonic suffix
(define_mode_attr mmxvecsize
[(V8QI "b") (V4QI "b") (V2QI "b")
@@ -108,7 +106,7 @@ (define_mode_attr mmxintvecmodelower
;; Mapping of vector modes to a vector mode of double size
(define_mode_attr mmxdoublevecmode
- [(V2SF "V4SF") (V2SI "V4SI")])
+ [(V2SF "V4SF") (V2SI "V4SI") (V4HF "V8HF")])
;; Mapping of vector modes back to the scalar modes
(define_mode_attr mmxscalarmode
@@ -594,7 +592,7 @@ (define_insn "sse_movntq"
(define_expand "movq__to_sse"
[(set (match_operand: 0 "register_operand")
(vec_concat:
- (match_operand:V2FI 1 "nonimmediate_operand")
+ (match_operand:V2FI_V4HF 1 "nonimmediate_operand")
(match_dup 2)))]
"TARGET_SSE2"
"operands[2] = CONST0_RTX (mode);")
@@ -1927,21 +1925,94 @@ (define_expand "lroundv2sfv2si2"
;;
;
-(define_insn "3"
- [(set (match_operand:VHF_32_64 0 "register_operand" "=v")
- (plusminusmultdiv:VHF_32_64
- (match_operand:VHF_32_64 1 "register_operand" "v")
- (match_operand:VHF_32_64 2 "register_operand" "v")))]
+(define_expand "v4hf3"
+ [(set (match_operand:V4HF 0 "register_operand")
+ (plusminusmult:V4HF
+ (match_operand:V4HF 1 "nonimmediate_operand")
+ (match_operand:V4HF 2 "nonimmediate_operand")))]
"TARGET_AVX512FP16 && TARGET_AVX512VL"
- "vph\t{%2, %1, %0|%0, %1, %2}"
- [(set (attr "type")
- (cond [(match_test " == MULT")
- (const_string "ssemul")
-(match_test " == DIV")
- (const_string "ssediv")]
-(const_string "sseadd")))
- (set_attr "prefix" "evex")
- (set_attr "mode" "V8HF")])
+{
+ rtx op2 = gen_reg_rtx (V8HFmode);
+ rtx op1 = gen_reg_rtx (V8HFmode);
+ rtx op0 = gen_reg_rtx (V8HFmode);
+
+ emit_insn (gen_movq_v4hf_to_sse (op2, operands[2]));
+ emit_insn (gen_movq_v4hf_to_sse (op1, operands[1]));
+
+ emit_insn (gen_v8hf3 (op0, op1, op2));
+
+ emit_move_insn (operands[0], lowpart_subreg (V4HFmode, op0, V8HFmode));
+ DONE;
+})
+
+(define_expand "divv4hf3"
+ [(set (match_operand:V4HF 0 "register_operand")
+ (div:V4HF
+ (match_operand:V4HF 1 "nonimmediate_operand")
+ (match_operand:V4HF 2 "nonimmediate_operand")))]
+ "TARGET_AVX512FP16 && TARGET_AVX512VL"
+{
+ rtx op2 = gen_reg_rtx (V8HFmode);
+ rtx op1 = gen_reg_rtx (V8HFmode);
+ rtx op0 = gen_reg_rtx (V8HFmode);
+
+ emit_insn (gen_movq_v4hf_to_sse (op1, operands[1]));
+ rtx tmp = gen_rtx_VEC_CONCAT (V8HFmode, operands[2],
+ force_reg (V4HFmode, CONST1_RTX (V4HFmode)));
+ emit_insn (gen_rtx_SET (op2, tmp));
+ emit_insn (gen_divv8hf3 (op0, op1, op2));
+ emit_move_insn (operands[0], lowpart_subreg (V4HFmode, op0, V8HFmode));
+ DONE;
+})
+
+(define_expand "movd_v2hf_to_sse"
+ [(set (match_operand:V8HF 0 "register_operand")
+ (vec_merge:V8HF
+ (vec_duplicate:V8HF
+ (match_operand:V2HF 1 "nonimmediate_operand"))
+ (match_operand:V8HF 2 "reg_or_0_operand")
+ (const_int 3)))]
+ "TARGET_SSE")
+
+(define_expand "v2hf3"
+ [(set (match_operand:V2HF 0 "register_operand")
+ (plusminusmult:V2HF
+
[PATCH] libsanitizer: Fix SPARC stacktraces
As detailed in LLVM Issue #57624
(https://github.com/llvm/llvm-project/issues/57624), a patch to
sanitizer_internal_defs.h broke SPARC stacktraces in the sanitizers.
The issue has now been fixed upstream (https://reviews.llvm.org/D156504)
and I'd like to cherry-pick that patch.
Bootstrapped without regressions on sparc-sun-solaris2.11.
Ok for trunk and the gcc-13 branch?
Rainer
--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
2023-07-27 Rainer Orth
libsanitizer:
* sanitizer_common/sanitizer_stacktrace_sparc.cpp,
sanitizer_common/sanitizer_unwind_linux_libcdep.cpp: Cherry-pick
llvm-project revision 679c076ae446af81eba81ce9b94203a273d4b88a.
# HG changeset patch
# Parent cc61fd6b33c37b7a2a1415e0ed02f75dd8a21110
Fix SPARC stacktraces in sanitizers
diff --git a/libsanitizer/sanitizer_common/sanitizer_stacktrace_sparc.cpp b/libsanitizer/sanitizer_common/sanitizer_stacktrace_sparc.cpp
--- a/libsanitizer/sanitizer_common/sanitizer_stacktrace_sparc.cpp
+++ b/libsanitizer/sanitizer_common/sanitizer_stacktrace_sparc.cpp
@@ -30,13 +30,7 @@ void BufferedStackTrace::UnwindFast(uptr
// TODO(yln): add arg sanity check for stack_top/stack_bottom
CHECK_GE(max_depth, 2);
const uptr kPageSize = GetPageSizeCached();
-#if defined(__GNUC__)
- // __builtin_return_address returns the address of the call instruction
- // on the SPARC and not the return address, so we need to compensate.
- trace_buffer[0] = GetNextInstructionPc(pc);
-#else
trace_buffer[0] = pc;
-#endif
size = 1;
if (stack_top < 4096) return; // Sanity check for stack top.
// Flush register windows to memory
diff --git a/libsanitizer/sanitizer_common/sanitizer_unwind_linux_libcdep.cpp b/libsanitizer/sanitizer_common/sanitizer_unwind_linux_libcdep.cpp
--- a/libsanitizer/sanitizer_common/sanitizer_unwind_linux_libcdep.cpp
+++ b/libsanitizer/sanitizer_common/sanitizer_unwind_linux_libcdep.cpp
@@ -139,13 +139,7 @@ void BufferedStackTrace::UnwindSlow(uptr
if (to_pop == 0 && size > 1)
to_pop = 1;
PopStackFrames(to_pop);
-#if defined(__GNUC__) && defined(__sparc__)
- // __builtin_return_address returns the address of the call instruction
- // on the SPARC and not the return address, so we need to compensate.
- trace_buffer[0] = GetNextInstructionPc(pc);
-#else
trace_buffer[0] = pc;
-#endif
}
void BufferedStackTrace::UnwindSlow(uptr pc, void *context, u32 max_depth) {
Re: [PATCH v2] rs6000: Fix __builtin_altivec_vcmpne{b,h,w} implementation
Hi Carl,
Sorry for the late review.
on 2023/8/2 02:29, Carl Love wrote:
>
> GCC maintainers:
>
> Ver 2: Re-worked the test vec-cmpne.c to create a compile only test
> verify the instruction generation and a runnable test to verify the
> built-in functionality. Retested the patch on Power 8 LE/BE, Power 9LE/BE
> and Power 10 LE with no regressions.
>
> The following patch cleans up the definition for the
> __builtin_altivec_vcmpne{b,h,w}. The current implementation implies
> that the built-in is only supported on Power 9 since it is defined
> under the Power 9 stanza. However the built-in has no ISA restrictions
> as stated in the Power Vector Intrinsic Programming Reference document.
> The current built-in works because the built-in gets replaced during
> GIMPLE folding by a simple not-equal operator so it doesn't get
> expanded and checked for Power 9 code generation.
>
> This patch moves the definition to the Altivec stanza in the built-in
> definition file to make it clear the built-ins are valid for Power 8,
> Power 9 and beyond.
>
> The patch has been tested on Power 8 LE/BE, Power 9 LE/BE and Power 10
> LE with no regressions.
>
> Please let me know if the patch is acceptable for mainline. Thanks.
>
> Carl
>
>
> rs6000: Fix __builtin_altivec_vcmpne{b,h,w} implementation
>
> The current built-in definitions for vcmpneb, vcmpneh, vcmpnew are defined
> under the Power 9 section of r66000-builtins. This implies they are only
> supported on Power 9 and above when in fact they are defined and work with
> Altivec as well with the appropriate Altivec instruction generation.
>
> The vec_cmpne builtin should generate the vcmpequ{b,h,w} instruction with
> Altivec enabled and generate the vcmpne{b,h,w} on Power 9 and newer
> processors.
>
> This patch moves the definitions to the Altivec stanza to make it clear
> the built-ins are supported for all Altivec processors. The patch
> enables the vcmpequ{b,h,w} instruction to be generated on Altivec and
> the vcmpne{b,h,w} instruction to be generated on Power 9 and beyond.
But as you noted above, the current built-ins work as expected, that is
to generate with vcmpequ{b,h,w} on altivec but not Power9 while generate
with vcmpne{b,h,w} on Power9. So I think we shouldn't say it's enabled
by this patch. Instead it's to remove the confusion.
>
> There is existing test coverage for the vec_cmpne built-in for
> vector bool char, vector bool short, vector bool int,
> vector bool long long in builtins-3-p9.c and p8vector-builtin-2.c.
> Coverage for vector signed int, vector unsigned int is in
> p8vector-builtin-2.c.
>
> Test vec-cmpne.c is updated to check the generation of the vcmpequ{b,h,w}
> instructions for Altivec. A new test vec-cmpne-runnable.c is added to
> verify the built-ins work as expected.
>
> Patch has been tested on Power 8 LE/BE, Power 9 LE/BE and Power 10 LE
> with no regressions.
>
> gcc/ChangeLog:
>
> * config/rs6000/rs6000-builtins.def (vcmpneb, vcmpneh, vcmpnew):
> Move definitions to Altivec stanza.
> * config/rs6000/altivec.md (vcmpneb, vcmpneh, vcmpnew): New
> define_expand.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/powerpc/vec-cmpne-runnable.c: New execution test.
> * gcc.target/powerpc/vec-cmpne.c (define_test_functions,
> execute_test_functions) moved to vec-cmpne.h. Added
> scan-assembler-times for vcmpequb, vcmpequh, vcmpequw.
> * gcc.target/powerpc/vec-cmpne.h: New include file for vec-cmpne.c
> and vec-cmpne-runnable.c. Split define_test_functions definition
> into define_test_functions and define_init_verify_functions.
> ---
> gcc/config/rs6000/altivec.md | 12 ++
> gcc/config/rs6000/rs6000-builtins.def | 18 +--
> .../gcc.target/powerpc/vec-cmpne-runnable.c | 36 ++
> gcc/testsuite/gcc.target/powerpc/vec-cmpne.c | 110 ++
> gcc/testsuite/gcc.target/powerpc/vec-cmpne.h | 86 ++
> 5 files changed, 151 insertions(+), 111 deletions(-)
> create mode 100644 gcc/testsuite/gcc.target/powerpc/vec-cmpne-runnable.c
> create mode 100644 gcc/testsuite/gcc.target/powerpc/vec-cmpne.h
>
> diff --git a/gcc/config/rs6000/altivec.md b/gcc/config/rs6000/altivec.md
> index ad1224e0b57..31f65aa1b7a 100644
> --- a/gcc/config/rs6000/altivec.md
> +++ b/gcc/config/rs6000/altivec.md
> @@ -2631,6 +2631,18 @@ (define_insn "altivec_vcmpequt_p"
>"vcmpequq. %0,%1,%2"
>[(set_attr "type" "veccmpfx")])
>
> +;; Expand for builtin vcmpne{b,h,w}
> +(define_expand "altivec_vcmpne_"
> + [(set (match_operand:VSX_EXTRACT_I 3 "altivec_register_operand" "=v")
> + (eq:VSX_EXTRACT_I (match_operand:VSX_EXTRACT_I 1
> "altivec_register_operand" "v")
> + (match_operand:VSX_EXTRACT_I 2
> "altivec_register_operand" "v")))
> + (set (match_operand:VSX_EXTRACT_I 0 "altivec_register_operand" "=v")
> +(not:V
Re: [PATCH] i386: Clear upper bits of XMM register for V4HFmode/V2HFmode operations [PR110762]
On Mon, Aug 7, 2023 at 10:57 AM liuhongt wrote:
>
> Similar like r14-2786-gade30fad6669e5, the patch is for V4HF/V2HFmode.
>
> Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
> Ok for trunk?
>
> gcc/ChangeLog:
>
> PR target/110762
> * config/i386/mmx.md (3): Changed from define_insn
> to define_expand and break into ..
> (v4hf3): .. this.
> (divv4hf3): .. this.
> (v2hf3): .. this.
> (divv2hf3): .. this.
> (movd_v2hf_to_sse): New define_expand.
> (movq__to_sse): Extend to V4HFmode.
> (mmxdoublevecmode): Ditto.
> (V2FI_V4HF): New mode iterator.
> * config/i386/sse.md (*vec_concatv4sf): Extend to hanlde V8HF
> by using mode iterator V4SF_V8HF, renamed to ..
> (*vec_concat): .. this.
> (*vec_concatv4sf_0): Extend to handle V8HF by using mode
> iterator V4SF_V8HF, renamed to ..
> (*vec_concat_0): .. this.
> (*vec_concatv8hf_movss): New define_insn.
> (V4SF_V8HF): New mode iterator.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/i386/pr110762-v4hf.c: New test.
LGTM.
Please also note the RFC patch [1] that relaxes clears for V2SFmode
with -fno-trapping-math. The patched compiler will then emit the same
code as clang does for -O2. Which raises another question - should gcc
default to -fno-trapping-math?
[1] https://gcc.gnu.org/pipermail/gcc-patches/2023-July/625795.html
Thanks,
Uros.
> ---
> gcc/config/i386/mmx.md| 109 +++---
> gcc/config/i386/sse.md| 40 +--
> gcc/testsuite/gcc.target/i386/pr110762-v4hf.c | 57 +
> 3 files changed, 177 insertions(+), 29 deletions(-)
> create mode 100644 gcc/testsuite/gcc.target/i386/pr110762-v4hf.c
>
> diff --git a/gcc/config/i386/mmx.md b/gcc/config/i386/mmx.md
> index 896af76a33f..88bdf084f54 100644
> --- a/gcc/config/i386/mmx.md
> +++ b/gcc/config/i386/mmx.md
> @@ -79,9 +79,7 @@ (define_mode_iterator V_16_32_64
> ;; V2S* modes
> (define_mode_iterator V2FI [V2SF V2SI])
>
> -;; 4-byte and 8-byte float16 vector modes
> -(define_mode_iterator VHF_32_64 [V4HF V2HF])
> -
> +(define_mode_iterator V2FI_V4HF [V2SF V2SI V4HF])
> ;; Mapping from integer vector mode to mnemonic suffix
> (define_mode_attr mmxvecsize
>[(V8QI "b") (V4QI "b") (V2QI "b")
> @@ -108,7 +106,7 @@ (define_mode_attr mmxintvecmodelower
>
> ;; Mapping of vector modes to a vector mode of double size
> (define_mode_attr mmxdoublevecmode
> - [(V2SF "V4SF") (V2SI "V4SI")])
> + [(V2SF "V4SF") (V2SI "V4SI") (V4HF "V8HF")])
>
> ;; Mapping of vector modes back to the scalar modes
> (define_mode_attr mmxscalarmode
> @@ -594,7 +592,7 @@ (define_insn "sse_movntq"
> (define_expand "movq__to_sse"
>[(set (match_operand: 0 "register_operand")
> (vec_concat:
> - (match_operand:V2FI 1 "nonimmediate_operand")
> + (match_operand:V2FI_V4HF 1 "nonimmediate_operand")
> (match_dup 2)))]
>"TARGET_SSE2"
>"operands[2] = CONST0_RTX (mode);")
> @@ -1927,21 +1925,94 @@ (define_expand "lroundv2sfv2si2"
> ;;
> ;
>
> -(define_insn "3"
> - [(set (match_operand:VHF_32_64 0 "register_operand" "=v")
> - (plusminusmultdiv:VHF_32_64
> - (match_operand:VHF_32_64 1 "register_operand" "v")
> - (match_operand:VHF_32_64 2 "register_operand" "v")))]
> +(define_expand "v4hf3"
> + [(set (match_operand:V4HF 0 "register_operand")
> + (plusminusmult:V4HF
> + (match_operand:V4HF 1 "nonimmediate_operand")
> + (match_operand:V4HF 2 "nonimmediate_operand")))]
>"TARGET_AVX512FP16 && TARGET_AVX512VL"
> - "vph\t{%2, %1, %0|%0, %1, %2}"
> - [(set (attr "type")
> - (cond [(match_test " == MULT")
> - (const_string "ssemul")
> -(match_test " == DIV")
> - (const_string "ssediv")]
> -(const_string "sseadd")))
> - (set_attr "prefix" "evex")
> - (set_attr "mode" "V8HF")])
> +{
> + rtx op2 = gen_reg_rtx (V8HFmode);
> + rtx op1 = gen_reg_rtx (V8HFmode);
> + rtx op0 = gen_reg_rtx (V8HFmode);
> +
> + emit_insn (gen_movq_v4hf_to_sse (op2, operands[2]));
> + emit_insn (gen_movq_v4hf_to_sse (op1, operands[1]));
> +
> + emit_insn (gen_v8hf3 (op0, op1, op2));
> +
> + emit_move_insn (operands[0], lowpart_subreg (V4HFmode, op0, V8HFmode));
> + DONE;
> +})
> +
> +(define_expand "divv4hf3"
> + [(set (match_operand:V4HF 0 "register_operand")
> + (div:V4HF
> + (match_operand:V4HF 1 "nonimmediate_operand")
> + (match_operand:V4HF 2 "nonimmediate_operand")))]
> + "TARGET_AVX512FP16 && TARGET_AVX512VL"
> +{
> + rtx op2 = gen_reg_rtx (V8HFmode);
> + rtx op1 = gen_reg_rtx (V8HFmode);
> + rtx op0 = gen_reg_rtx (V8HFmode);
> +
> + emit_insn (gen_movq_v4hf_to_sse (op1, operands[1]));
> + rtx tmp = gen_rtx_VEC_CONCAT (V8HFmode, operands[2],
> + force_r
Re: [PATCH] libsanitizer: Fix SPARC stacktraces
On Mon, Aug 07, 2023 at 11:13:10AM +0200, Rainer Orth wrote: > As detailed in LLVM Issue #57624 > (https://github.com/llvm/llvm-project/issues/57624), a patch to > sanitizer_internal_defs.h broke SPARC stacktraces in the sanitizers. > The issue has now been fixed upstream (https://reviews.llvm.org/D156504) > and I'd like to cherry-pick that patch. > > Bootstrapped without regressions on sparc-sun-solaris2.11. > > Ok for trunk and the gcc-13 branch? Ok, thanks. > 2023-07-27 Rainer Orth > > libsanitizer: > * sanitizer_common/sanitizer_stacktrace_sparc.cpp, > sanitizer_common/sanitizer_unwind_linux_libcdep.cpp: Cherry-pick > llvm-project revision 679c076ae446af81eba81ce9b94203a273d4b88a. Jakub
Re: Re: PING^2 [PATCH] mklog: fix bugs of --append option
Hi, Jeff. Could you help with this patch? With this patch, we don't need to manually copy commit log. With ../contrib/mklog.py -a patch It will automatically copy to the commit log which is useful when sending patches. Thanks. juzhe.zh...@rivai.ai From: Lehua Ding Date: 2023-08-03 20:08 To: jeffreyalaw; gcc-patches CC: juzhe.zhong; Martin Jambor Subject: Re: PING^2 [PATCH] mklog: fix bugs of --append option Gentle PING^2, thanks!
[PATCH] RISC-V: Support VLS basic operation auto-vectorization
This patch support VLS modes auto-vectorization to enhance VLA
auto-vectorization
when niters is known.
Consider this following case:
#include
#define DEF_OP_VV(PREFIX, NUM, TYPE, OP) \
void __attribute__ ((noinline, noclone)) \
PREFIX##_##TYPE##NUM (TYPE *__restrict a, TYPE *__restrict b, TYPE
*__restrict c) \
{\
for (int i = 0; i < NUM; ++i) \
a[i] = b[i] OP c[i]; \
}
DEF_OP_VV (plus, 16, int8_t, +)
Before this patch:
plus_int8_t16(signed char*, signed char*, signed char*):
li a5,16
csrra4,vlenb
bleua5,a4,.L2
mv a5,a4
.L2:
vsetvli zero,a5,e8,m1,ta,ma
vle8.v v2,0(a1)
vle8.v v1,0(a2)
vsetvli a4,zero,e8,m1,ta,ma
vadd.vv v1,v1,v2
vsetvli zero,a5,e8,m1,ta,ma
vse8.v v1,0(a0)
ret
After this patch:
plus_int8_t16:
vsetivlizero,16,e8,m1,ta,ma
vle8.v v1,0(a2)
vle8.v v2,0(a1)
vadd.vv v1,v1,v2
vse8.v v1,0(a0)
ret
gcc/ChangeLog:
* config/riscv/autovec-vls.md (3): Add VLS modes.
* config/riscv/vector-iterators.md: Ditto.
* config/riscv/vector.md: Ditto.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/vls/def.h: Add basic operations.
* gcc.target/riscv/rvv/autovec/vls/and-1.c: New test.
* gcc.target/riscv/rvv/autovec/vls/and-2.c: New test.
* gcc.target/riscv/rvv/autovec/vls/and-3.c: New test.
* gcc.target/riscv/rvv/autovec/vls/div-1.c: New test.
* gcc.target/riscv/rvv/autovec/vls/ior-1.c: New test.
* gcc.target/riscv/rvv/autovec/vls/ior-2.c: New test.
* gcc.target/riscv/rvv/autovec/vls/ior-3.c: New test.
* gcc.target/riscv/rvv/autovec/vls/max-1.c: New test.
* gcc.target/riscv/rvv/autovec/vls/min-1.c: New test.
* gcc.target/riscv/rvv/autovec/vls/minus-1.c: New test.
* gcc.target/riscv/rvv/autovec/vls/minus-2.c: New test.
* gcc.target/riscv/rvv/autovec/vls/minus-3.c: New test.
* gcc.target/riscv/rvv/autovec/vls/mod-1.c: New test.
* gcc.target/riscv/rvv/autovec/vls/mult-1.c: New test.
* gcc.target/riscv/rvv/autovec/vls/plus-1.c: New test.
* gcc.target/riscv/rvv/autovec/vls/plus-2.c: New test.
* gcc.target/riscv/rvv/autovec/vls/plus-3.c: New test.
---
gcc/config/riscv/autovec-vls.md | 23 +++
gcc/config/riscv/vector-iterators.md | 93 ++
gcc/config/riscv/vector.md| 166 +-
.../gcc.target/riscv/rvv/autovec/vls/and-1.c | 57 ++
.../gcc.target/riscv/rvv/autovec/vls/and-2.c | 57 ++
.../gcc.target/riscv/rvv/autovec/vls/and-3.c | 57 ++
.../gcc.target/riscv/rvv/autovec/vls/def.h| 48 +
.../gcc.target/riscv/rvv/autovec/vls/div-1.c | 58 ++
.../gcc.target/riscv/rvv/autovec/vls/ior-1.c | 57 ++
.../gcc.target/riscv/rvv/autovec/vls/ior-2.c | 57 ++
.../gcc.target/riscv/rvv/autovec/vls/ior-3.c | 57 ++
.../gcc.target/riscv/rvv/autovec/vls/max-1.c | 57 ++
.../gcc.target/riscv/rvv/autovec/vls/min-1.c | 57 ++
.../riscv/rvv/autovec/vls/minus-1.c | 57 ++
.../riscv/rvv/autovec/vls/minus-2.c | 57 ++
.../riscv/rvv/autovec/vls/minus-3.c | 57 ++
.../gcc.target/riscv/rvv/autovec/vls/mod-1.c | 57 ++
.../gcc.target/riscv/rvv/autovec/vls/mult-1.c | 57 ++
.../gcc.target/riscv/rvv/autovec/vls/plus-1.c | 57 ++
.../gcc.target/riscv/rvv/autovec/vls/plus-2.c | 57 ++
.../gcc.target/riscv/rvv/autovec/vls/plus-3.c | 57 ++
21 files changed, 1217 insertions(+), 83 deletions(-)
create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/autovec/vls/and-1.c
create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/autovec/vls/and-2.c
create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/autovec/vls/and-3.c
create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/autovec/vls/div-1.c
create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/autovec/vls/ior-1.c
create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/autovec/vls/ior-2.c
create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/autovec/vls/ior-3.c
create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/autovec/vls/max-1.c
create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/autovec/vls/min-1.c
create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/autovec/vls/minus-1.c
create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/autovec/vls/minus-2.c
create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/autovec/vls/minus-3.c
create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/autovec/vls/mod-1.c
create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/autovec/vls/mult-1.c
create mode 1
Re: [PATCH V2] rs6000: Don't allow AltiVec address in movoo & movxo pattern [PR110411]
Hi Jeevitha,
on 2023/7/20 00:46, jeevitha wrote:
> Hi All,
>
> The following patch has been bootstrapped and regtested on powerpc64le-linux.
>
> There are no instructions that do traditional AltiVec addresses (i.e.
> with the low four bits of the address masked off) for OOmode and XOmode
> objects. The solution is to modify the constraints used in the movoo and
> movxo pattern to disallow these types of addresses, which assists LRA in
> resolving this issue. Furthermore, the mode size 16 check has been
> removed in vsx_quad_dform_memory_operand to allow OOmode and
Excepting for the nits Peter caught, one minor nit: "... to allow
OOmode and XOmode, and ..."
This patch looks quite reasonable that to make mov[ox]o to use the same
memory constraints as what the underlying vsx paired load/store insns use.
It's okay for trunk with those nits tweaked, also okay for all affected
release branches after burn-in time, thanks!
BR,
Kewen
> quad_address_p already handles less than size 16.
>
> 2023-07-19 Jeevitha Palanisamy
>
> gcc/
> PR target/110411
> * config/rs6000/mma.md (define_insn_and_split movoo): Disallow
> AltiVec address in movoo and movxo pattern.
> (define_insn_and_split movxo): Likewise.
> *config/rs6000/predicates.md (vsx_quad_dform_memory_operand):Remove
> redundant mode size check.
>
> gcc/testsuite/
> PR target/110411
> * gcc.target/powerpc/pr110411-1.c: New testcase.
> * gcc.target/powerpc/pr110411-2.c: New testcase.
>
> diff --git a/gcc/config/rs6000/mma.md b/gcc/config/rs6000/mma.md
> index d36dc13872b..575751d477e 100644
> --- a/gcc/config/rs6000/mma.md
> +++ b/gcc/config/rs6000/mma.md
> @@ -293,8 +293,8 @@
> })
>
> (define_insn_and_split "*movoo"
> - [(set (match_operand:OO 0 "nonimmediate_operand" "=wa,m,wa")
> - (match_operand:OO 1 "input_operand" "m,wa,wa"))]
> + [(set (match_operand:OO 0 "nonimmediate_operand" "=wa,ZwO,wa")
> + (match_operand:OO 1 "input_operand" "ZwO,wa,wa"))]
>"TARGET_MMA
> && (gpc_reg_operand (operands[0], OOmode)
> || gpc_reg_operand (operands[1], OOmode))"
> @@ -340,8 +340,8 @@
> })
>
> (define_insn_and_split "*movxo"
> - [(set (match_operand:XO 0 "nonimmediate_operand" "=d,m,d")
> - (match_operand:XO 1 "input_operand" "m,d,d"))]
> + [(set (match_operand:XO 0 "nonimmediate_operand" "=d,ZwO,d")
> + (match_operand:XO 1 "input_operand" "ZwO,d,d"))]
>"TARGET_MMA
> && (gpc_reg_operand (operands[0], XOmode)
> || gpc_reg_operand (operands[1], XOmode))"
> diff --git a/gcc/config/rs6000/predicates.md b/gcc/config/rs6000/predicates.md
> index 3552d908e9d..925f69cd3fc 100644
> --- a/gcc/config/rs6000/predicates.md
> +++ b/gcc/config/rs6000/predicates.md
> @@ -924,7 +924,7 @@
> (define_predicate "vsx_quad_dform_memory_operand"
>(match_code "mem")
> {
> - if (!TARGET_P9_VECTOR || GET_MODE_SIZE (mode) != 16)
> + if (!TARGET_P9_VECTOR)
> return false;
>
>return quad_address_p (XEXP (op, 0), mode, false);
> diff --git a/gcc/testsuite/gcc.target/powerpc/pr110411-1.c
> b/gcc/testsuite/gcc.target/powerpc/pr110411-1.c
> new file mode 100644
> index 000..f42e9388d65
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/powerpc/pr110411-1.c
> @@ -0,0 +1,22 @@
> +/* PR target/110411 */
> +/* { dg-require-effective-target power10_ok } */
> +/* { dg-options "-O2 -mdejagnu-cpu=power10 -mblock-ops-vector-pair" } */
> +
> +/* Verify we do not ICE on the following. */
> +
> +#include
> +
> +struct s {
> + long a;
> + long b;
> + long c;
> + long d: 1;
> +};
> +unsigned long ptr;
> +
> +void
> +bug (struct s *dst)
> +{
> + struct s *src = (struct s *)(ptr & ~0xFUL);
> + memcpy (dst, src, sizeof(struct s));
> +}
> diff --git a/gcc/testsuite/gcc.target/powerpc/pr110411-2.c
> b/gcc/testsuite/gcc.target/powerpc/pr110411-2.c
> new file mode 100644
> index 000..c2046fb9855
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/powerpc/pr110411-2.c
> @@ -0,0 +1,12 @@
> +/* PR target/110411 */
> +/* { dg-require-effective-target power10_ok } */
> +/* { dg-options "-O2 -mdejagnu-cpu=power10" } */
> +
> +/* Verify we do not ICE on the following. */
> +
> +void
> +bug (__vector_quad *dst)
> +{
> + dst = (__vector_quad *)((unsigned long)dst & ~0xFUL);
> + __builtin_mma_xxsetaccz (dst);
> +}
>
>
[PATCH V4] VECT: Support CALL vectorization for COND_LEN_*
From: Ju-Zhe Zhong
Hi, Richard and Richi.
Base on the suggestions from Richard:
https://gcc.gnu.org/pipermail/gcc-patches/2023-July/625396.html
This patch choose (1) approach that Richard provided, meaning:
RVV implements cond_* optabs as expanders. RVV therefore supports
both IFN_COND_ADD and IFN_COND_LEN_ADD. No dummy length arguments
are needed at the gimple level.
Such approach can make codes much cleaner and reasonable.
Consider this following case:
void foo (float * __restrict a, float * __restrict b, int * __restrict cond,
int n)
{
for (int i = 0; i < n; i++)
if (cond[i])
a[i] = b[i] + a[i];
}
Output of RISC-V (32-bits) gcc (trunk) (Compiler #3)
:5:21: missed: couldn't vectorize loop
:5:21: missed: not vectorized: control flow in loop.
ARM SVE:
...
mask__27.10_51 = vect__4.9_49 != { 0, ... };
...
vec_mask_and_55 = loop_mask_49 & mask__27.10_51;
...
vect__9.17_62 = .COND_ADD (vec_mask_and_55, vect__6.13_56, vect__8.16_60,
vect__6.13_56);
For RVV, we want IR as follows:
...
_68 = .SELECT_VL (ivtmp_66, POLY_INT_CST [4, 4]);
...
mask__27.10_51 = vect__4.9_49 != { 0, ... };
...
vect__9.17_60 = .COND_LEN_ADD (mask__27.10_51, vect__6.13_55, vect__8.16_59,
vect__6.13_55, _68, 0);
...
Both len and mask of COND_LEN_ADD are real not dummy.
This patch has been fully tested in RISC-V port with supporting both COND_* and
COND_LEN_*.
And also, Bootstrap and Regression on X86 passed.
OK for trunk?
gcc/ChangeLog:
* internal-fn.cc (get_len_internal_fn): New function.
(DEF_INTERNAL_COND_FN): Ditto.
(DEF_INTERNAL_SIGNED_COND_FN): Ditto.
* internal-fn.h (get_len_internal_fn): Ditto.
* tree-vect-stmts.cc (vectorizable_call): Add CALL auto-vectorization.
---
gcc/internal-fn.cc | 24 +
gcc/internal-fn.h | 1 +
gcc/tree-vect-stmts.cc | 58 ++
3 files changed, 78 insertions(+), 5 deletions(-)
diff --git a/gcc/internal-fn.cc b/gcc/internal-fn.cc
index 8e294286388..7f5ede00c02 100644
--- a/gcc/internal-fn.cc
+++ b/gcc/internal-fn.cc
@@ -4443,6 +4443,30 @@ get_conditional_internal_fn (internal_fn fn)
}
}
+/* If there exists an internal function like IFN that operates on vectors,
+ but with additional length and bias parameters, return the internal_fn
+ for that function, otherwise return IFN_LAST. */
+internal_fn
+get_len_internal_fn (internal_fn fn)
+{
+ switch (fn)
+{
+#undef DEF_INTERNAL_COND_FN
+#undef DEF_INTERNAL_SIGNED_COND_FN
+#define DEF_INTERNAL_COND_FN(NAME, ...)
\
+ case IFN_COND_##NAME:
\
+return IFN_COND_LEN_##NAME;
+#define DEF_INTERNAL_SIGNED_COND_FN(NAME, ...)
\
+ case IFN_COND_##NAME:
\
+return IFN_COND_LEN_##NAME;
+#include "internal-fn.def"
+#undef DEF_INTERNAL_COND_FN
+#undef DEF_INTERNAL_SIGNED_COND_FN
+default:
+ return IFN_LAST;
+}
+}
+
/* If IFN implements the conditional form of an unconditional internal
function, return that unconditional function, otherwise return IFN_LAST. */
diff --git a/gcc/internal-fn.h b/gcc/internal-fn.h
index a5c3f4765ff..410c1b623d6 100644
--- a/gcc/internal-fn.h
+++ b/gcc/internal-fn.h
@@ -224,6 +224,7 @@ extern bool set_edom_supported_p (void);
extern internal_fn get_conditional_internal_fn (tree_code);
extern internal_fn get_conditional_internal_fn (internal_fn);
+extern internal_fn get_len_internal_fn (internal_fn);
extern internal_fn get_conditional_len_internal_fn (tree_code);
extern tree_code conditional_internal_fn_code (internal_fn);
extern internal_fn get_unconditional_internal_fn (internal_fn);
diff --git a/gcc/tree-vect-stmts.cc b/gcc/tree-vect-stmts.cc
index 6a4e8fce126..76b1c83f41e 100644
--- a/gcc/tree-vect-stmts.cc
+++ b/gcc/tree-vect-stmts.cc
@@ -3540,7 +3540,10 @@ vectorizable_call (vec_info *vinfo,
int reduc_idx = STMT_VINFO_REDUC_IDX (stmt_info);
internal_fn cond_fn = get_conditional_internal_fn (ifn);
+ internal_fn cond_len_fn = get_len_internal_fn (ifn);
+ int len_opno = internal_fn_len_index (cond_len_fn);
vec_loop_masks *masks = (loop_vinfo ? &LOOP_VINFO_MASKS (loop_vinfo) : NULL);
+ vec_loop_lens *lens = (loop_vinfo ? &LOOP_VINFO_LENS (loop_vinfo) : NULL);
if (!vec_stmt) /* transformation not required. */
{
if (slp_node)
@@ -3569,6 +3572,9 @@ vectorizable_call (vec_info *vinfo,
if (reduc_idx >= 0
&& (cond_fn == IFN_LAST
|| !direct_internal_fn_supported_p (cond_fn, vectype_out,
+ OPTIMIZE_FOR_SPEED))
+ && (cond_len_fn == IFN_LAST
+ || !direct_internal_fn_supported_p (cond_len_fn, vectype_out,
OPTIMIZE_FOR_SPEED)))
{
if (dump_enabled_p ())
@@ -35
[PATCH] tree-optimization/110897 - Fix missed vectorization of shift on both RISC-V and aarch64
Consider this following case:
#include
#define TEST2_TYPE(TYPE)\
__attribute__((noipa))\
void vshiftr_##TYPE (TYPE *__restrict dst, TYPE *__restrict a, TYPE
*__restrict b, int n) \
{ \
for (int i = 0; i < n; i++) \
dst[i] = (a[i]) >> b[i]; \
}
#define TEST_ALL() \
TEST2_TYPE(uint8_t)\
TEST2_TYPE(uint16_t) \
TEST2_TYPE(uint32_t) \
TEST2_TYPE(uint64_t) \
TEST_ALL()
Both RISC-V and aarch64 of trunk GCC failed vectorize uint8_t/uint16_t with
following missed report:
:17:1: missed: couldn't vectorize loop
:17:1: missed: not vectorized: relevant stmt not supported: patt_46 =
MIN_EXPR <_6, 7>;
:17:1: missed: couldn't vectorize loop
:17:1: missed: not vectorized: relevant stmt not supported: patt_47 =
MIN_EXPR <_7, 15>;
Compiler returned: 0
Both GCC 13.1 can vectorize, see:
https://godbolt.org/z/6vaMK5M1o
Bootstrap and regression on X86 passed.
Ok for trunk ?
gcc/ChangeLog:
* tree-vect-patterns.cc (vect_recog_over_widening_pattern): Add op
vectype.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/binop/narrow-1.c: Adapt testcase.
---
gcc/testsuite/gcc.target/riscv/rvv/autovec/binop/narrow-1.c | 4 ++--
gcc/tree-vect-patterns.cc | 3 ++-
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/gcc/testsuite/gcc.target/riscv/rvv/autovec/binop/narrow-1.c
b/gcc/testsuite/gcc.target/riscv/rvv/autovec/binop/narrow-1.c
index 3de8d85b52d..b12cb6355c8 100644
--- a/gcc/testsuite/gcc.target/riscv/rvv/autovec/binop/narrow-1.c
+++ b/gcc/testsuite/gcc.target/riscv/rvv/autovec/binop/narrow-1.c
@@ -27,5 +27,5 @@
TEST_ALL ()
-/* { dg-final { scan-assembler-times {\tvnsra\.wv} 6 } } */
-/* { dg-final { scan-assembler-times {\tvnsrl\.wv} 5 } } */
+/* { dg-final { scan-assembler-times {\tvnsra\.wv} 4 } } */
+/* { dg-final { scan-assembler-times {\tvnsrl\.wv} 4 } } */
diff --git a/gcc/tree-vect-patterns.cc b/gcc/tree-vect-patterns.cc
index 2cedf238450..cda27fed95b 100644
--- a/gcc/tree-vect-patterns.cc
+++ b/gcc/tree-vect-patterns.cc
@@ -3133,7 +3133,8 @@ vect_recog_over_widening_pattern (vec_info *vinfo,
return NULL;
}
else
- append_pattern_def_seq (vinfo, last_stmt_info, pattern_stmt);
+ append_pattern_def_seq (vinfo, last_stmt_info, pattern_stmt,
+ op_vectype);
ops[1] = new_var;
}
}
--
2.36.1
Re: [PATCH V4] VECT: Support CALL vectorization for COND_LEN_*
Oh, I am so sorry resend this patch again.
I was trying to send patch which fixed missed shift vectorizaiton on RISCV and
ARM:
https://gcc.gnu.org/pipermail/gcc-patches/2023-August/626456.html
This V4 patch is no different from before.
I am sorry about that. Forget about this patch.
juzhe.zh...@rivai.ai
From: juzhe.zhong
Date: 2023-08-07 17:38
To: gcc-patches
CC: richard.sandiford; rguenther; Ju-Zhe Zhong
Subject: [PATCH V4] VECT: Support CALL vectorization for COND_LEN_*
From: Ju-Zhe Zhong
Hi, Richard and Richi.
Base on the suggestions from Richard:
https://gcc.gnu.org/pipermail/gcc-patches/2023-July/625396.html
This patch choose (1) approach that Richard provided, meaning:
RVV implements cond_* optabs as expanders. RVV therefore supports
both IFN_COND_ADD and IFN_COND_LEN_ADD. No dummy length arguments
are needed at the gimple level.
Such approach can make codes much cleaner and reasonable.
Consider this following case:
void foo (float * __restrict a, float * __restrict b, int * __restrict cond,
int n)
{
for (int i = 0; i < n; i++)
if (cond[i])
a[i] = b[i] + a[i];
}
Output of RISC-V (32-bits) gcc (trunk) (Compiler #3)
:5:21: missed: couldn't vectorize loop
:5:21: missed: not vectorized: control flow in loop.
ARM SVE:
...
mask__27.10_51 = vect__4.9_49 != { 0, ... };
...
vec_mask_and_55 = loop_mask_49 & mask__27.10_51;
...
vect__9.17_62 = .COND_ADD (vec_mask_and_55, vect__6.13_56, vect__8.16_60,
vect__6.13_56);
For RVV, we want IR as follows:
...
_68 = .SELECT_VL (ivtmp_66, POLY_INT_CST [4, 4]);
...
mask__27.10_51 = vect__4.9_49 != { 0, ... };
...
vect__9.17_60 = .COND_LEN_ADD (mask__27.10_51, vect__6.13_55, vect__8.16_59,
vect__6.13_55, _68, 0);
...
Both len and mask of COND_LEN_ADD are real not dummy.
This patch has been fully tested in RISC-V port with supporting both COND_* and
COND_LEN_*.
And also, Bootstrap and Regression on X86 passed.
OK for trunk?
gcc/ChangeLog:
* internal-fn.cc (get_len_internal_fn): New function.
(DEF_INTERNAL_COND_FN): Ditto.
(DEF_INTERNAL_SIGNED_COND_FN): Ditto.
* internal-fn.h (get_len_internal_fn): Ditto.
* tree-vect-stmts.cc (vectorizable_call): Add CALL auto-vectorization.
---
gcc/internal-fn.cc | 24 +
gcc/internal-fn.h | 1 +
gcc/tree-vect-stmts.cc | 58 ++
3 files changed, 78 insertions(+), 5 deletions(-)
diff --git a/gcc/internal-fn.cc b/gcc/internal-fn.cc
index 8e294286388..7f5ede00c02 100644
--- a/gcc/internal-fn.cc
+++ b/gcc/internal-fn.cc
@@ -4443,6 +4443,30 @@ get_conditional_internal_fn (internal_fn fn)
}
}
+/* If there exists an internal function like IFN that operates on vectors,
+ but with additional length and bias parameters, return the internal_fn
+ for that function, otherwise return IFN_LAST. */
+internal_fn
+get_len_internal_fn (internal_fn fn)
+{
+ switch (fn)
+{
+#undef DEF_INTERNAL_COND_FN
+#undef DEF_INTERNAL_SIGNED_COND_FN
+#define DEF_INTERNAL_COND_FN(NAME, ...)
\
+ case IFN_COND_##NAME:
\
+return IFN_COND_LEN_##NAME;
+#define DEF_INTERNAL_SIGNED_COND_FN(NAME, ...)
\
+ case IFN_COND_##NAME:
\
+return IFN_COND_LEN_##NAME;
+#include "internal-fn.def"
+#undef DEF_INTERNAL_COND_FN
+#undef DEF_INTERNAL_SIGNED_COND_FN
+default:
+ return IFN_LAST;
+}
+}
+
/* If IFN implements the conditional form of an unconditional internal
function, return that unconditional function, otherwise return IFN_LAST. */
diff --git a/gcc/internal-fn.h b/gcc/internal-fn.h
index a5c3f4765ff..410c1b623d6 100644
--- a/gcc/internal-fn.h
+++ b/gcc/internal-fn.h
@@ -224,6 +224,7 @@ extern bool set_edom_supported_p (void);
extern internal_fn get_conditional_internal_fn (tree_code);
extern internal_fn get_conditional_internal_fn (internal_fn);
+extern internal_fn get_len_internal_fn (internal_fn);
extern internal_fn get_conditional_len_internal_fn (tree_code);
extern tree_code conditional_internal_fn_code (internal_fn);
extern internal_fn get_unconditional_internal_fn (internal_fn);
diff --git a/gcc/tree-vect-stmts.cc b/gcc/tree-vect-stmts.cc
index 6a4e8fce126..76b1c83f41e 100644
--- a/gcc/tree-vect-stmts.cc
+++ b/gcc/tree-vect-stmts.cc
@@ -3540,7 +3540,10 @@ vectorizable_call (vec_info *vinfo,
int reduc_idx = STMT_VINFO_REDUC_IDX (stmt_info);
internal_fn cond_fn = get_conditional_internal_fn (ifn);
+ internal_fn cond_len_fn = get_len_internal_fn (ifn);
+ int len_opno = internal_fn_len_index (cond_len_fn);
vec_loop_masks *masks = (loop_vinfo ? &LOOP_VINFO_MASKS (loop_vinfo) : NULL);
+ vec_loop_lens *lens = (loop_vinfo ? &LOOP_VINFO_LENS (loop_vinfo) : NULL);
if (!vec_stmt) /* transformation not required. */
{
if (slp_node)
@@ -3569,6 +3572,9 @@ vectorizable_call (vec_info *vinfo,
if (reduc_idx >= 0
Re: PR target/107671: Make more use of btl/btq on x86_64.
On Mon, Aug 7, 2023 at 9:37 AM Roger Sayle wrote:
>
>
> This patch is a partial solution to PR target/107671, updating Uros'
> patch from comment #4, to catch both bit set (setc) and bit not set
> (setnc) cases from the code in comment #2, when compiled on x86_64.
> Unfortunately, this is a partial solution, as the pointer variants
> in comment #1, aren't yet all optimized, and my attempts to check
> whether the 32-bit versions are optimized with -m32 revealed they
> also need further improvement. (Some of) These remaining issues
> might best be fixed in the middle-end, in either match.pd or the
> RTL optimizers, so I thought it reasonable to submit this independent
> backend piece, and gain/bank the improvements on x86_64.
>
> This patch has been tested on x86_64-pc-linux-gnu with make bootstrap
> and make -k check, both with and without --target_board=unix{-m32}
> with no new failures. Ok for mainline?
>
>
> 2023-08-07 Roger Sayle
> Uros Bizjak
>
> gcc/ChangeLog
> PR target/107671
> * config/i386/i386.md (*bt_setc_mask): Allow the
> shift count to have a different mode (using SWI248) from either
> the bit-test or the result.
> (*bt_setnc_mask): New define_insn_and_split for the
> setnc (bit not set) case of the above pattern.
> (*btdi_setncsi_mask): New define_insn_and_split to handle the
> SImode result from a DImode bit-test variant of the above patterns.
> (*bt_setncqi_mask_2): New define_insn_and_split for the
> setnc (bit not set) version of *bt_setcqi_mask_2.
>
> gcc/testsuite/ChangeLog
> PR target/107671
> * gcc.target/i386/pr107671-1.c: New test case.
> * gcc.target/i386/pr107671-2.c: Likewise.
I am worried about the number of existing and new patterns that are
introduced to satisfy creativity of the combine pass. The following
can be handled via zero-extract RTXes:
return ((v & (1 << (bitnum & 31 != 0;
return ((v & (1L << (bitnum & 63 != 0;
return (v >> (bitnum & 31)) & 1;
return (v >> (bitnum & 63)) & 1;
but there is no canonicalization for negative forms of the above constructs.
For the above, the combine pass tries:
(set (reg:SI 95)
(zero_extract:SI (reg:SI 97)
(const_int 1 [0x1])
(and:SI (reg:SI 98)
(const_int 31 [0x1f]
that is necessary to handle the change of compare mode from CCZ to
CCC. However, negative forms try:
(set (reg:QI 96)
(eq:QI (zero_extract:SI (reg:SI 97)
(const_int 1 [0x1])
(and:SI (reg:SI 98)
(const_int 31 [0x1f])))
(const_int 0 [0])))
and:
(set (reg:SI 95)
(xor:SI (zero_extract:SI (reg:SI 97)
(const_int 1 [0x1])
(and:SI (reg:SI 98)
(const_int 31 [0x1f])))
(const_int 1 [0x1])))
and these are further different for SImode and DImode.
Ideally, we would simplify all forms to:
(set (reg:QI 96)
(eq:QI (zero_extract:SI (reg:SI 97)
(const_int 1 [0x1])
(and:SI (reg:SI 98)
(const_int 31 [0x1f])))
(const_int 0 [0])))
where inverted/non-inverted forms would emit ne/eq:QI ()
(const_int 0). The result would be zero-extended to DI or SImode,
depending on the target mode.
You can already see the problem with missing canonicalization in
i386.md with define_insn_and_split pattern with comments:
;; Help combine recognize bt followed by setc
;; Help combine recognize bt followed by setnc
where totally different patterns are needed to match what combine produces.
The above problem is specific to setcc patterns, where output value is
derived from the input operand. jcc and cmov look OK.
If the following pattern would be tried by combine, then we would
handle all the testcases in the PR (plus some more, where output is in
different mode than input):
(set (reg:QI 96)
({eq,ne}:QI (zero_extract:SI (reg:SI 97)
(const_int 1 [0x1])
(and:SI (reg:SI 98)
(const_int 31 [0x1f])))
(const_int 0 [0])))
where QIreg is later zero-extended to the target width. In this case,
one define_insn_and_split pattern would handle all testcases from
PR107671.
Please also note that we can implement this transformation via a
combine splitter. The benefit of the combine splitter is that its
results are immediately "recognized", and new RTXes can be propagated
into subsequent combinations.
I have made some measurements with my proposed patch (as posted in the
PR), and the transformation never triggered (neither for gcc build,
nor when building the linux kernel). So, I wonder if the added number
of patterns outweigh the benefits at all.
IMO, the correct way is to teach the combine pass some more about
bit-test functionality (to also pass negative forms via zero-extract
RTXes, see above). This would canonicalize the transformation and
prevent pattern explosion.
I consider bt to be quite an important instruction, wher
Re: [PATCH] tree-optimization/110897 - Fix missed vectorization of shift on both RISC-V and aarch64
On Mon, 7 Aug 2023, Juzhe-Zhong wrote:
> Consider this following case:
>
> #include
>
> #define TEST2_TYPE(TYPE) \
> __attribute__((noipa)) \
> void vshiftr_##TYPE (TYPE *__restrict dst, TYPE *__restrict a, TYPE
> *__restrict b, int n) \
> { \
> for (int i = 0; i < n; i++) \
> dst[i] = (a[i]) >> b[i];\
> }
>
> #define TEST_ALL()\
> TEST2_TYPE(uint8_t) \
> TEST2_TYPE(uint16_t) \
> TEST2_TYPE(uint32_t) \
> TEST2_TYPE(uint64_t) \
>
> TEST_ALL()
>
> Both RISC-V and aarch64 of trunk GCC failed vectorize uint8_t/uint16_t with
> following missed report:
>
> :17:1: missed: couldn't vectorize loop
> :17:1: missed: not vectorized: relevant stmt not supported: patt_46 =
> MIN_EXPR <_6, 7>;
> :17:1: missed: couldn't vectorize loop
> :17:1: missed: not vectorized: relevant stmt not supported: patt_47 =
> MIN_EXPR <_7, 15>;
> Compiler returned: 0
>
> Both GCC 13.1 can vectorize, see:
>
> https://godbolt.org/z/6vaMK5M1o
>
> Bootstrap and regression on X86 passed.
>
> Ok for trunk ?
OK.
> gcc/ChangeLog:
>
> * tree-vect-patterns.cc (vect_recog_over_widening_pattern): Add op
> vectype.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/riscv/rvv/autovec/binop/narrow-1.c: Adapt testcase.
>
> ---
> gcc/testsuite/gcc.target/riscv/rvv/autovec/binop/narrow-1.c | 4 ++--
> gcc/tree-vect-patterns.cc | 3 ++-
> 2 files changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/gcc/testsuite/gcc.target/riscv/rvv/autovec/binop/narrow-1.c
> b/gcc/testsuite/gcc.target/riscv/rvv/autovec/binop/narrow-1.c
> index 3de8d85b52d..b12cb6355c8 100644
> --- a/gcc/testsuite/gcc.target/riscv/rvv/autovec/binop/narrow-1.c
> +++ b/gcc/testsuite/gcc.target/riscv/rvv/autovec/binop/narrow-1.c
> @@ -27,5 +27,5 @@
>
> TEST_ALL ()
>
> -/* { dg-final { scan-assembler-times {\tvnsra\.wv} 6 } } */
> -/* { dg-final { scan-assembler-times {\tvnsrl\.wv} 5 } } */
> +/* { dg-final { scan-assembler-times {\tvnsra\.wv} 4 } } */
> +/* { dg-final { scan-assembler-times {\tvnsrl\.wv} 4 } } */
> diff --git a/gcc/tree-vect-patterns.cc b/gcc/tree-vect-patterns.cc
> index 2cedf238450..cda27fed95b 100644
> --- a/gcc/tree-vect-patterns.cc
> +++ b/gcc/tree-vect-patterns.cc
> @@ -3133,7 +3133,8 @@ vect_recog_over_widening_pattern (vec_info *vinfo,
> return NULL;
> }
> else
> - append_pattern_def_seq (vinfo, last_stmt_info, pattern_stmt);
> + append_pattern_def_seq (vinfo, last_stmt_info, pattern_stmt,
> + op_vectype);
> ops[1] = new_var;
> }
> }
>
--
Richard Biener
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
[PATCH 1/3 v4] Support get_or_insert in ordered_hash_map
Get_or_insert method is already supported by the unordered hash map.
Adding it to the ordered map enables us to replace the unordered map
with the ordered one in cases where ordering may be useful.
Signed-off-by: Andrzej Turko
gcc/ChangeLog:
* ordered-hash-map.h: Add get_or_insert.
* ordered-hash-map-tests.cc: Use get_or_insert in tests.
---
gcc/ordered-hash-map-tests.cc | 19 +++
gcc/ordered-hash-map.h| 26 ++
2 files changed, 41 insertions(+), 4 deletions(-)
diff --git a/gcc/ordered-hash-map-tests.cc b/gcc/ordered-hash-map-tests.cc
index 1c26bbfa979..55894c25fa0 100644
--- a/gcc/ordered-hash-map-tests.cc
+++ b/gcc/ordered-hash-map-tests.cc
@@ -58,6 +58,7 @@ static void
test_map_of_strings_to_int ()
{
ordered_hash_map m;
+ bool existed;
const char *ostrich = "ostrich";
const char *elephant = "elephant";
@@ -74,17 +75,23 @@ test_map_of_strings_to_int ()
ASSERT_EQ (false, m.put (ostrich, 2));
ASSERT_EQ (false, m.put (elephant, 4));
ASSERT_EQ (false, m.put (ant, 6));
- ASSERT_EQ (false, m.put (spider, 8));
+ existed = true;
+ int &value = m.get_or_insert (spider, &existed);
+ value = 8;
+ ASSERT_EQ (false, existed);
ASSERT_EQ (false, m.put (millipede, 750));
ASSERT_EQ (false, m.put (eric, 3));
+
/* Verify that we can recover the stored values. */
ASSERT_EQ (6, m.elements ());
ASSERT_EQ (2, *m.get (ostrich));
ASSERT_EQ (4, *m.get (elephant));
ASSERT_EQ (6, *m.get (ant));
ASSERT_EQ (8, *m.get (spider));
- ASSERT_EQ (750, *m.get (millipede));
+ existed = false;
+ ASSERT_EQ (750, m.get_or_insert (millipede, &existed));
+ ASSERT_EQ (true, existed);
ASSERT_EQ (3, *m.get (eric));
/* Verify that the order of insertion is preserved. */
@@ -113,6 +120,7 @@ test_map_of_int_to_strings ()
{
const int EMPTY = -1;
const int DELETED = -2;
+ bool existed;
typedef int_hash int_hash_t;
ordered_hash_map m;
@@ -131,7 +139,9 @@ test_map_of_int_to_strings ()
ASSERT_EQ (false, m.put (2, ostrich));
ASSERT_EQ (false, m.put (4, elephant));
ASSERT_EQ (false, m.put (6, ant));
- ASSERT_EQ (false, m.put (8, spider));
+ const char* &value = m.get_or_insert (8, &existed);
+ value = spider;
+ ASSERT_EQ (false, existed);
ASSERT_EQ (false, m.put (750, millipede));
ASSERT_EQ (false, m.put (3, eric));
@@ -141,7 +151,8 @@ test_map_of_int_to_strings ()
ASSERT_EQ (*m.get (4), elephant);
ASSERT_EQ (*m.get (6), ant);
ASSERT_EQ (*m.get (8), spider);
- ASSERT_EQ (*m.get (750), millipede);
+ ASSERT_EQ (m.get_or_insert (750, &existed), millipede);
+ ASSERT_EQ (existed, TRUE);
ASSERT_EQ (*m.get (3), eric);
/* Verify that the order of insertion is preserved. */
diff --git a/gcc/ordered-hash-map.h b/gcc/ordered-hash-map.h
index 6b68cc96305..9fc875182e1 100644
--- a/gcc/ordered-hash-map.h
+++ b/gcc/ordered-hash-map.h
@@ -76,6 +76,32 @@ public:
return m_map.get (k);
}
+ /* Return a reference to the value for the passed in key, creating the entry
+if it doesn't already exist. If existed is not NULL then it is set to
+false if the key was not previously in the map, and true otherwise. */
+
+ Value &get_or_insert (const Key &k, bool *existed = NULL)
+ {
+bool _existed;
+Value &ret = m_map.get_or_insert (k, &_existed);
+
+if (!_existed)
+ {
+ bool key_present;
+ int &slot = m_key_index.get_or_insert (k, &key_present);
+ if (!key_present)
+ {
+ slot = m_keys.length ();
+ m_keys.safe_push (k);
+ }
+ }
+
+if (existed)
+ *existed = _existed;
+
+return ret;
+ }
+
/* Removing a key removes it from the map, but retains the insertion
order. */
--
2.34.1
[PATCH 0/3 v4] genmatch: Speed up recompilation after changes to match.pd
The following reduces the number of object files that need to be rebuilt after match.pd has been modified. Right now a change to match.pd which adds/removes a line almost always forces recompilation of all files that genmatch generates from it. This is because of unnecessary changes to the generated .cc files: 1. Function names and ordering change as does the way the functions are distributed across multiple source files. 2. Code locations from match.pd are quoted directly (including line numbers) by logging fprintf calls. This patch addresses the those issues without changing the behaviour of the generated code. The first one is solved by making sure that minor changes to match.pd do not influence the order in which functions are generated. The second one by using a lookup table with line numbers. Now a change to a single function will trigger a rebuild of 4 object files (one with the function and the one with the lookup table both for gimple and generic) instead all of them (20 by default). For reference, this decreased the rebuild time with 48 threads from 3.5 minutes to 1.5 minutes on my machine. V2: * Placed the change in Makefile.in in the correct commit. * Used a separate logging function to reduce size of the executable. V3: * Fix a bug from 'genmatch: Log line numbers indirectly', which was introduced in V2. V4: * Remove duplicate line numbers in the lookup table. * Do not define dump_log functions if they are not called. Note for reviewers: I do not have write access. Andrzej Turko (3): Support get_or_insert in ordered_hash_map genmatch: Reduce variability of generated code genmatch: Log line numbers indirectly gcc/Makefile.in | 4 +- gcc/genmatch.cc | 98 +-- gcc/ordered-hash-map-tests.cc | 19 +-- gcc/ordered-hash-map.h| 26 ++ 4 files changed, 125 insertions(+), 22 deletions(-) -- 2.34.1
[PATCH 3/3 v4] genmatch: Log line numbers indirectly
Currently fprintf calls logging to a dump file take line numbers
in the match.pd file directly as arguments.
When match.pd is edited, referenced code changes line numbers,
which causes changes to many fprintf calls and, thus, to many
(usually all) .cc files generated by genmatch. This forces make
to (unnecessarily) rebuild many .o files.
This change replaces those logging fprintf calls with calls to
a dedicated logging function. Because it reads the line numbers
from the lookup table, it is enough to pass a corresponding index.
Thanks to this, when match.pd changes, it is enough to rebuild
the file containing the lookup table and, of course, those
actually affected by the change.
Signed-off-by: Andrzej Turko
gcc/ChangeLog:
* genmatch.cc: Log line numbers indirectly.
---
gcc/genmatch.cc | 95 +
1 file changed, 80 insertions(+), 15 deletions(-)
diff --git a/gcc/genmatch.cc b/gcc/genmatch.cc
index 1deca505603..f46d2e1520d 100644
--- a/gcc/genmatch.cc
+++ b/gcc/genmatch.cc
@@ -217,10 +217,56 @@ fp_decl_done (FILE *f, const char *trailer)
fprintf (header_file, "%s;", trailer);
}
+/* Line numbers for use by indirect line directives. */
+static vec dbg_line_numbers;
+
+static void
+write_header_declarations (bool gimple, FILE *f)
+{
+ fprintf (f, "\nextern void\n%s_dump_logs (const char *file1, int line1_id, "
+ "const char *file2, int line2, bool simplify);\n",
+ gimple ? "gimple" : "generic");
+}
+
+static void
+define_dump_logs (bool gimple, FILE *f)
+{
+ if (dbg_line_numbers.is_empty ())
+ return;
+
+ fprintf (f , "void\n%s_dump_logs (const char *file1, int line1_id, "
+ "const char *file2, int line2, bool simplify)\n{\n",
+ gimple ? "gimple" : "generic");
+
+ fprintf_indent (f, 2, "static int dbg_line_numbers[%d] = {",
+ dbg_line_numbers.length ());
+
+ for (unsigned i = 0; i < dbg_line_numbers.length () - 1; i++)
+{
+ if (i % 20 == 0)
+ fprintf (f, "\n\t");
+
+ fprintf (f, "%d, ", dbg_line_numbers[i]);
+}
+ fprintf (f, "%d\n };\n\n", dbg_line_numbers.last ());
+
+
+ fprintf_indent (f, 2, "fprintf (dump_file, \"%%s "
+ "%%s:%%d, %%s:%%d\\n\",\n");
+ fprintf_indent (f, 10, "simplify ? \"Applying pattern\" : "
+ "\"Matching expression\", file1, "
+ "dbg_line_numbers[line1_id], file2, line2);");
+
+ fprintf (f, "\n}\n\n");
+}
+
static void
output_line_directive (FILE *f, location_t location,
- bool dumpfile = false, bool fnargs = false)
+ bool dumpfile = false, bool fnargs = false,
+ bool indirect_line_numbers = false)
{
+ typedef pair_hash> location_hash;
+ static hash_map loc_id_map;
const line_map_ordinary *map;
linemap_resolve_location (line_table, location, LRK_SPELLING_LOCATION, &map);
expanded_location loc = linemap_expand_location (line_table, map, location);
@@ -239,7 +285,23 @@ output_line_directive (FILE *f, location_t location,
++file;
if (fnargs)
- fprintf (f, "\"%s\", %d", file, loc.line);
+ {
+ if (indirect_line_numbers)
+ {
+ bool existed;
+ int &loc_id = loc_id_map.get_or_insert (
+ std::make_pair (file, loc.line), &existed);
+ if (!existed)
+ {
+ loc_id = dbg_line_numbers.length ();
+ dbg_line_numbers.safe_push (loc.line);
+ }
+
+ fprintf (f, "\"%s\", %d", file, loc_id);
+ }
+ else
+ fprintf (f, "\"%s\", %d", file, loc.line);
+ }
else
fprintf (f, "%s:%d", file, loc.line);
}
@@ -3375,20 +3437,19 @@ dt_operand::gen (FILE *f, int indent, bool gimple, int
depth)
}
}
-/* Emit a fprintf to the debug file to the file F, with the INDENT from
+/* Emit a logging call to the debug file to the file F, with the INDENT from
either the RESULT location or the S's match location if RESULT is null. */
static void
-emit_debug_printf (FILE *f, int indent, class simplify *s, operand *result)
+emit_logging_call (FILE *f, int indent, class simplify *s, operand *result,
+ bool gimple)
{
fprintf_indent (f, indent, "if (UNLIKELY (debug_dump)) "
- "fprintf (dump_file, \"%s ",
- s->kind == simplify::SIMPLIFY
- ? "Applying pattern" : "Matching expression");
- fprintf (f, "%%s:%%d, %%s:%%d\\n\", ");
+ "%s_dump_logs (", gimple ? "gimple" : "generic");
output_line_directive (f,
-result ? result->location : s->match->location, true,
-true);
- fprintf (f, ", __FILE__, __LINE__);\n");
+ result ? result->location : s->match->location,
+ true, true, true);
+ fprintf (f, ", __FILE__, __LINE__, %s);\n",
+
[PATCH 2/3 v4] genmatch: Reduce variability of generated code
So far genmatch has been using an unordered map to store information about
functions to be generated. Since corresponding locations from match.pd were
used as keys in the map, even small changes to match.pd which caused
line number changes would change the order in which the functions are
generated. This would reshuffle the functions between the generated .cc files.
This way even a minimal modification to match.pd forces recompilation of all
object files originating from match.pd on rebuild.
This commit makes sure that functions are generated in the order of their
processing (in contrast to the random order based on hashes of their
locations in match.pd). This is done by replacing the unordered map with an
ordered one. This way small changes to match.pd does not cause function
renaming and reshuffling among generated source files.
Together with the subsequent change to logging fprintf calls, this
removes unnecessary changes to the files generated by genmatch allowing
for reuse of already built object files during rebuild. The aim is to
make editing of match.pd and subsequent testing easier.
Signed-off-by: Andrzej Turko
gcc/ChangeLog:
* genmatch.cc: Make sinfo map ordered.
* Makefile.in: Require the ordered map header for genmatch.o.
---
gcc/Makefile.in | 4 ++--
gcc/genmatch.cc | 3 ++-
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index e99628cec07..2429128cbf2 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -3004,8 +3004,8 @@ build/genhooks.o : genhooks.cc $(TARGET_DEF)
$(C_TARGET_DEF) \
$(COMMON_TARGET_DEF) $(D_TARGET_DEF) $(BCONFIG_H) $(SYSTEM_H) errors.h
build/genmddump.o : genmddump.cc $(RTL_BASE_H) $(BCONFIG_H) $(SYSTEM_H)
\
$(CORETYPES_H) $(GTM_H) errors.h $(READ_MD_H) $(GENSUPPORT_H)
-build/genmatch.o : genmatch.cc $(BCONFIG_H) $(SYSTEM_H) \
- $(CORETYPES_H) errors.h $(HASH_TABLE_H) hash-map.h $(GGC_H) is-a.h \
+build/genmatch.o : genmatch.cc $(BCONFIG_H) $(SYSTEM_H) $(CORETYPES_H) \
+ errors.h $(HASH_TABLE_H) hash-map.h $(GGC_H) is-a.h ordered-hash-map.h \
tree.def builtins.def internal-fn.def case-cfn-macros.h $(CPPLIB_H)
build/gencfn-macros.o : gencfn-macros.cc $(BCONFIG_H) $(SYSTEM_H) \
$(CORETYPES_H) errors.h $(HASH_TABLE_H) hash-set.h builtins.def \
diff --git a/gcc/genmatch.cc b/gcc/genmatch.cc
index 2302f2a7ff0..1deca505603 100644
--- a/gcc/genmatch.cc
+++ b/gcc/genmatch.cc
@@ -29,6 +29,7 @@ along with GCC; see the file COPYING3. If not see
#include "hash-table.h"
#include "hash-set.h"
#include "is-a.h"
+#include "ordered-hash-map.h"
/* Stubs for GGC referenced through instantiations triggered by hash-map. */
@@ -1684,7 +1685,7 @@ struct sinfo_hashmap_traits :
simple_hashmap_traits,
template static inline void remove (T &) {}
};
-typedef hash_map
+typedef ordered_hash_map
sinfo_map_t;
/* Current simplifier ID we are processing during insertion into the
--
2.34.1
PING^4 [PATCH 0/9] rs6000: Rework rs6000_emit_vector_compare
Hi, Gentle ping this series: https://gcc.gnu.org/pipermail/gcc-patches/2022-November/607146.html BR, Kewen >>> on 2022/11/24 17:15, Kewen Lin wrote: Hi, Following Segher's suggestion, this patch series is to rework function rs6000_emit_vector_compare for vector float and int in multiple steps, it's based on the previous attempts [1][2]. As mentioned in [1], the need to rework this for float is to make a centralized place for vector float comparison handlings instead of supporting with swapping ops and reversing code etc. dispersedly. It's also for a subsequent patch to handle comparison operators with or without trapping math (PR105480). With the handling on vector float reworked, we can further make the handling on vector int simplified as shown. For Segher's concern about whether this rework causes any assembly change, I constructed two testcases for vector float[3] and int[4] respectively before, it showed the most are fine excepting for the difference on LE and UNGT, it's demonstrated as improvement since it uses GE instead of GT ior EQ. The associated test case in patch 3/9 is a good example. Besides, w/ and w/o the whole patch series, I built the whole SPEC2017 at options -O3 and -Ofast separately, checked the differences on object assembly. The result showed that the most are unchanged, except for: * at -O3, 521.wrf_r has 9 object files and 526.blender_r has 9 object files with differences. * at -Ofast, 521.wrf_r has 12 object files, 526.blender_r has one and 527.cam4_r has 4 object files with differences. By looking into these differences, all significant differences are caused by the known improvement mentined above transforming GT ior EQ to GE, which can also affect unrolling decision due to insn count. Some other trivial differences are branch target offset difference, nop difference for alignment, vsx register number differences etc. I also evaluated the runtime performance for these changed benchmarks, the result is neutral. These patches are bootstrapped and regress-tested incrementally on powerpc64-linux-gnu P7 & P8, and powerpc64le-linux-gnu P9 & P10. Is it ok for trunk? BR, Kewen - [1] https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606375.html [2] https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606376.html [3] https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606504.html [4] https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606506.html Kewen Lin (9): rs6000: Rework vector float comparison in rs6000_emit_vector_compare - p1 rs6000: Rework vector float comparison in rs6000_emit_vector_compare - p2 rs6000: Rework vector float comparison in rs6000_emit_vector_compare - p3 rs6000: Rework vector float comparison in rs6000_emit_vector_compare - p4 rs6000: Rework vector integer comparison in rs6000_emit_vector_compare - p1 rs6000: Rework vector integer comparison in rs6000_emit_vector_compare - p2 rs6000: Rework vector integer comparison in rs6000_emit_vector_compare - p3 rs6000: Rework vector integer comparison in rs6000_emit_vector_compare - p4 rs6000: Rework vector integer comparison in rs6000_emit_vector_compare - p5 gcc/config/rs6000/rs6000.cc | 180 ++-- gcc/testsuite/gcc.target/powerpc/vcond-fp.c | 25 +++ 2 files changed, 74 insertions(+), 131 deletions(-) create mode 100644 gcc/testsuite/gcc.target/powerpc/vcond-fp.c
PING^3 [PATCH v2] sched: Change no_real_insns_p to no_real_nondebug_insns_p [PR108273]
Hi,
I'd like to gentle ping this patch:
https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614818.html
BR,
Kewen
>> on 2023/3/29 15:18, Kewen.Lin via Gcc-patches wrote:
>>> Hi,
>>>
>>> By addressing Alexander's comments, against v1 this
>>> patch v2 mainly:
>>>
>>> - Rename no_real_insns_p to no_real_nondebug_insns_p;
>>> - Introduce enum rgn_bb_deps_free_action for three
>>> kinds of actions to free deps;
>>> - Change function free_deps_for_bb_no_real_insns_p to
>>> resolve_forw_deps which only focuses on forward deps;
>>> - Extend the handlings to cover dbg-cnt sched_block,
>>> add one test case for it;
>>> - Move free_trg_info call in schedule_region to an
>>> appropriate place.
>>>
>>> One thing I'm not sure about is the change in function
>>> sched_rgn_local_finish, currently the invocation to
>>> sched_rgn_local_free is guarded with !sel_sched_p (),
>>> so I just follow it, but the initialization of those
>>> structures (in sched_rgn_local_init) isn't guarded
>>> with !sel_sched_p (), it looks odd.
>>>
>>>
>>>
>>> As PR108273 shows, when there is one block which only has
>>> NOTE_P and LABEL_P insns at non-debug mode while has some
>>> extra DEBUG_INSN_P insns at debug mode, after scheduling
>>> it, the DFA states would be different between debug mode
>>> and non-debug mode. Since at non-debug mode, the block
>>> meets no_real_insns_p, it gets skipped; while at debug
>>> mode, it gets scheduled, even it only has NOTE_P, LABEL_P
>>> and DEBUG_INSN_P, the call of function advance_one_cycle
>>> will change the DFA state. PR108519 also shows this issue
>>> issue can be exposed by some scheduler changes.
>>>
>>> This patch is to change function no_real_insns_p to
>>> function no_real_nondebug_insns_p by taking debug insn into
>>> account, which make us not try to schedule for the block
>>> having only NOTE_P, LABEL_P and DEBUG_INSN_P insns,
>>> resulting in consistent DFA states between non-debug and
>>> debug mode.
>>>
>>> Changing no_real_insns_p to no_real_nondebug_insns_p caused
>>> ICE when doing free_block_dependencies, the root cause is
>>> that we create dependencies for debug insns, those
>>> dependencies are expected to be resolved during scheduling
>>> insns, but which gets skipped after this change.
>>> By checking the code, it looks it's reasonable to skip to
>>> compute block dependences for no_real_nondebug_insns_p
>>> blocks. There is also another issue, which gets exposed
>>> in SPEC2017 bmks build at option -O2 -g, is that we could
>>> skip to schedule some block, which already gets dependency
>>> graph built so has dependencies computed and rgn_n_insns
>>> accumulated, then the later verification on if the graph
>>> becomes exhausted by scheduling would fail as follow:
>>>
>>> /* Sanity check: verify that all region insns were
>>> scheduled. */
>>> gcc_assert (sched_rgn_n_insns == rgn_n_insns);
>>>
>>> , and also some forward deps aren't resovled.
>>>
>>> As Alexander pointed out, the current debug count handling
>>> also suffers the similar issue, so this patch handles these
>>> two cases together: one is for some block gets skipped by
>>> !dbg_cnt (sched_block), the other is for some block which
>>> is not no_real_nondebug_insns_p initially but becomes
>>> no_real_nondebug_insns_p due to speculative scheduling.
>>>
>>> This patch can be bootstrapped and regress-tested on
>>> x86_64-redhat-linux, aarch64-linux-gnu and
>>> powerpc64{,le}-linux-gnu.
>>>
>>> I also verified this patch can pass SPEC2017 both intrate
>>> and fprate bmks building at -g -O2/-O3.
>>>
>>> Any thoughts?
>>>
>>> BR,
>>> Kewen
>>>
>>> PR rtl-optimization/108273
>>>
>>> gcc/ChangeLog:
>>>
>>> * haifa-sched.cc (no_real_insns_p): Rename to ...
>>> (no_real_nondebug_insns_p): ... this, and consider DEBUG_INSN_P insn.
>>> * sched-ebb.cc (schedule_ebb): Replace no_real_insns_p with
>>> no_real_nondebug_insns_p.
>>> * sched-int.h (no_real_insns_p): Rename to ...
>>> (no_real_nondebug_insns_p): ... this.
>>> * sched-rgn.cc (enum rgn_bb_deps_free_action): New enum.
>>> (bb_deps_free_actions): New static variable.
>>> (compute_block_dependences): Skip for no_real_nondebug_insns_p.
>>> (resolve_forw_deps): New function.
>>> (free_block_dependencies): Check bb_deps_free_actions and call
>>> function resolve_forw_deps for RGN_BB_DEPS_FREE_ARTICIAL.
>>> (compute_priorities): Replace no_real_insns_p with
>>> no_real_nondebug_insns_p.
>>> (schedule_region): Replace no_real_insns_p with
>>> no_real_nondebug_insns_p, set RGN_BB_DEPS_FREE_ARTICIAL if the block
>>> get dependencies computed before but skipped now, fix up count
>>> sched_rgn_n_insns for it too. Call free_trg_info when the block
>>> gets scheduled, and move sched_rgn_local_finish after the loop
>>> of free_block_dependencies loop.
>>> (sched_rgn_local_init): Allocate and compute bb_deps_free_actions.
>>> (sched_rgn_local_
PING^2 [PATCH v2] rs6000: Don't use optimize_function_for_speed_p too early [PR108184]
Hi,
Gentle ping this:
https://gcc.gnu.org/pipermail/gcc-patches/2023-January/609993.html
BR,
Kewen
> on 2023/1/16 17:08, Kewen.Lin via Gcc-patches wrote:
>> Hi,
>>
>> As Honza pointed out in [1], the current uses of function
>> optimize_function_for_speed_p in rs6000_option_override_internal
>> are too early, since the query results from the functions
>> optimize_function_for_{speed,size}_p could be changed later due
>> to profile feedback and some function attributes handlings etc.
>>
>> This patch is to move optimize_function_for_speed_p to all the
>> use places of the corresponding flags, which follows the existing
>> practices. Maybe we can cache it somewhere at an appropriate
>> timing, but that's another thing.
>>
>> Comparing with v1[2], this version added one test case for
>> SAVE_TOC_INDIRECT as Segher questioned and suggested, and it
>> also considered the possibility of explicit option (see test
>> cases pr108184-2.c and pr108184-4.c). I believe that excepting
>> for the intentional change on optimize_function_for_{speed,
>> size}_p, there is no other function change.
>>
>> [1] https://gcc.gnu.org/pipermail/gcc-patches/2022-November/607527.html
>> [2] https://gcc.gnu.org/pipermail/gcc-patches/2023-January/609379.html
>>
>> Bootstrapped and regtested on powerpc64-linux-gnu P8,
>> powerpc64le-linux-gnu P{9,10} and powerpc-ibm-aix.
>>
>> Is it ok for trunk?
>>
>> BR,
>> Kewen
>> -
>> gcc/ChangeLog:
>>
>> * config/rs6000/rs6000.cc (rs6000_option_override_internal): Remove
>> all optimize_function_for_speed_p uses.
>> (fusion_gpr_load_p): Call optimize_function_for_speed_p along
>> with TARGET_P8_FUSION_SIGN.
>> (expand_fusion_gpr_load): Likewise.
>> (rs6000_call_aix): Call optimize_function_for_speed_p along with
>> TARGET_SAVE_TOC_INDIRECT.
>> * config/rs6000/predicates.md (fusion_gpr_mem_load): Call
>> optimize_function_for_speed_p along with TARGET_P8_FUSION_SIGN.
>>
>> gcc/testsuite/ChangeLog:
>>
>> * gcc.target/powerpc/pr108184-1.c: New test.
>> * gcc.target/powerpc/pr108184-2.c: New test.
>> * gcc.target/powerpc/pr108184-3.c: New test.
>> * gcc.target/powerpc/pr108184-4.c: New test.
>> ---
>> gcc/config/rs6000/predicates.md | 5 +++-
>> gcc/config/rs6000/rs6000.cc | 19 +-
>> gcc/testsuite/gcc.target/powerpc/pr108184-1.c | 16
>> gcc/testsuite/gcc.target/powerpc/pr108184-2.c | 15 +++
>> gcc/testsuite/gcc.target/powerpc/pr108184-3.c | 25 +++
>> gcc/testsuite/gcc.target/powerpc/pr108184-4.c | 24 ++
>> 6 files changed, 97 insertions(+), 7 deletions(-)
>> create mode 100644 gcc/testsuite/gcc.target/powerpc/pr108184-1.c
>> create mode 100644 gcc/testsuite/gcc.target/powerpc/pr108184-2.c
>> create mode 100644 gcc/testsuite/gcc.target/powerpc/pr108184-3.c
>> create mode 100644 gcc/testsuite/gcc.target/powerpc/pr108184-4.c
>>
>> diff --git a/gcc/config/rs6000/predicates.md
>> b/gcc/config/rs6000/predicates.md
>> index a1764018545..9f84468db84 100644
>> --- a/gcc/config/rs6000/predicates.md
>> +++ b/gcc/config/rs6000/predicates.md
>> @@ -1878,7 +1878,10 @@ (define_predicate "fusion_gpr_mem_load"
>>
>>/* Handle sign/zero extend. */
>>if (GET_CODE (op) == ZERO_EXTEND
>> - || (TARGET_P8_FUSION_SIGN && GET_CODE (op) == SIGN_EXTEND))
>> + || (TARGET_P8_FUSION_SIGN
>> + && GET_CODE (op) == SIGN_EXTEND
>> + && (rs6000_isa_flags_explicit & OPTION_MASK_P8_FUSION_SIGN
>> + || optimize_function_for_speed_p (cfun
>> {
>>op = XEXP (op, 0);
>>mode = GET_MODE (op);
>> diff --git a/gcc/config/rs6000/rs6000.cc b/gcc/config/rs6000/rs6000.cc
>> index 6ac3adcec6b..f47d21980a9 100644
>> --- a/gcc/config/rs6000/rs6000.cc
>> +++ b/gcc/config/rs6000/rs6000.cc
>> @@ -3997,8 +3997,7 @@ rs6000_option_override_internal (bool global_init_p)
>>/* If we can shrink-wrap the TOC register save separately, then use
>> -msave-toc-indirect unless explicitly disabled. */
>>if ((rs6000_isa_flags_explicit & OPTION_MASK_SAVE_TOC_INDIRECT) == 0
>> - && flag_shrink_wrap_separate
>> - && optimize_function_for_speed_p (cfun))
>> + && flag_shrink_wrap_separate)
>> rs6000_isa_flags |= OPTION_MASK_SAVE_TOC_INDIRECT;
>>
>>/* Enable power8 fusion if we are tuning for power8, even if we aren't
>> @@ -4032,7 +4031,6 @@ rs6000_option_override_internal (bool global_init_p)
>> zero extending load, and an explicit sign extension. */
>>if (TARGET_P8_FUSION
>>&& !(rs6000_isa_flags_explicit & OPTION_MASK_P8_FUSION_SIGN)
>> - && optimize_function_for_speed_p (cfun)
>>&& optimize >= 3)
>> rs6000_isa_flags |= OPTION_MASK_P8_FUSION_SIGN;
>>
>> @@ -25690,7 +25688,10 @@ rs6000_call_aix (rtx value, rtx func_desc, rtx
>> tlsarg, rtx cookie)
>>
>>/* Can we optimize saving the TOC in the prologue or
>> do we need to do it at every call
Re: [PATCH 1/3] targhooks: Extend legitimate_address_p with code_helper [PR110248]
Hi Richi,
on 2023/6/30 17:13, Kewen.Lin via Gcc-patches wrote:
> Hi Richi,
>
> Thanks for your review!
>
> on 2023/6/30 16:56, Richard Biener wrote:
>> On Fri, Jun 30, 2023 at 7:38 AM Kewen.Lin wrote:
>>>
>>> Hi,
>>>
>>> As PR110248 shows, some middle-end passes like IVOPTs can
>>> query the target hook legitimate_address_p with some
>>> artificially constructed rtx to determine whether some
>>> addressing modes are supported by target for some gimple
>>> statement. But for now the existing legitimate_address_p
>>> only checks the given mode, it's unable to distinguish
>>> some special cases unfortunately, for example, for LEN_LOAD
>>> ifn on Power port, we would expand it with lxvl hardware
>>> insn, which only supports one register to hold the address
>>> (the other register is holding the length), that is we
>>> don't support base (reg) + index (reg) addressing mode for
>>> sure. But hook legitimate_address_p only considers the
>>> given mode which would be some vector mode for LEN_LOAD
>>> ifn, and we do support base + index addressing mode for
>>> normal vector load and store insns, so the hook will return
>>> true for the query unexpectedly.
>>>
>>> This patch is to introduce one extra argument of type
>>> code_helper for hook legitimate_address_p, it makes targets
>>> able to handle some special case like what's described
>>> above. The subsequent patches will show how to leverage
>>> the new code_helper argument.
>>>
>>> I didn't separate those target specific adjustments to
>>> their own patches, since those changes are no function
>>> changes. One typical change is to add one unnamed argument
>>> with default ERROR_MARK, some ports need to include tree.h
>>> in their {port}-protos.h since the hook is used in some
>>> machine description files. I've cross-built a corresponding
>>> cc1 successfully for at least one triple of each affected
>>> target so I believe they are safe. But feel free to correct
>>> me if separating is needed for the review of this patch.
>>>
>>> Besides, it's bootstrapped and regtested on
>>> x86_64-redhat-linux and powerpc64{,le}-linux-gnu.
>>>
>>> Is it ok for trunk?
>>
>> Is defaulting the arguments in the targets necessary for
>> the middle-end or only for direct uses in the targets?
>
> It's only for the direct uses in target codes, the call
> sites in generic code of these hooks would use the given
> code_helper type variable or an explicit ERROR_MARK, they
> don't require target codes to set that.
>
>>
>> It looks OK in general but please give others some time to
>> comment.
Some weeks passed and no further comments are received, I guess
this still looks good to you?
BR,
Kewen
>
> OK, thanks again!
>
> BR,
> Kewen
>
>>
>> Thanks,
>> Richard.
>>
>>> BR,
>>> Kewen
>>> --
>>> PR tree-optimization/110248
>>>
>>> gcc/ChangeLog:
>>>
>>> * coretypes.h (class code_helper): Add forward declaration.
>>> * doc/tm.texi: Regenerate.
>>> * lra-constraints.cc (valid_address_p): Call target hook
>>> targetm.addr_space.legitimate_address_p with an extra parameter
>>> ERROR_MARK as its prototype changes.
>>> * recog.cc (memory_address_addr_space_p): Likewise.
>>> * reload.cc (strict_memory_address_addr_space_p): Likewise.
>>> * target.def (legitimate_address_p,
>>> addr_space.legitimate_address_p):
>>> Extend with one more argument of type code_helper, update the
>>> documentation accordingly.
>>> * targhooks.cc (default_legitimate_address_p): Adjust for the
>>> new code_helper argument.
>>> (default_addr_space_legitimate_address_p): Likewise.
>>> * targhooks.h (default_legitimate_address_p): Likewise.
>>> (default_addr_space_legitimate_address_p): Likewise.
>>> * config/aarch64/aarch64.cc (aarch64_legitimate_address_hook_p):
>>> Adjust
>>> with extra unnamed code_helper argument with default ERROR_MARK.
>>> * config/alpha/alpha.cc (alpha_legitimate_address_p): Likewise.
>>> * config/arc/arc.cc (arc_legitimate_address_p): Likewise.
>>> * config/arm/arm-protos.h (arm_legitimate_address_p): Likewise.
>>> (tree.h): New include for tree_code ERROR_MARK.
>>> * config/arm/arm.cc (arm_legitimate_address_p): Adjust with extra
>>> unnamed code_helper argument with default ERROR_MARK.
>>> * config/avr/avr.cc (avr_addr_space_legitimate_address_p): Likewise.
>>> * config/bfin/bfin.cc (bfin_legitimate_address_p): Likewise.
>>> * config/bpf/bpf.cc (bpf_legitimate_address_p): Likewise.
>>> * config/c6x/c6x.cc (c6x_legitimate_address_p): Likewise.
>>> * config/cris/cris-protos.h (cris_legitimate_address_p): Likewise.
>>> (tree.h): New include for tree_code ERROR_MARK.
>>> * config/cris/cris.cc (cris_legitimate_address_p): Adjust with extra
>>> unnamed code_helper argument with default ERROR_MARK.
>>> * config/csky/csky
Re: [PATCH] tree-optimization/110897 - Fix missed vectorization of shift on both RISC-V and aarch64
Committed to trunk, thanks Richard and Juzhe.
[PATCH] fwprop: Allow UNARY_P and check register pressure.
Hi,
originally inspired by the wish to transform
vmv v3, a0 ; = vec_duplicate
vadd.vv v1, v2, v3
into
vadd.vx v1, v2, a0
via fwprop for riscv, this patch enables the forward propagation
of UNARY_P sources.
As this involves potentially replacing a vector register with
a scalar register the ira_hoist_pressure machinery is used to
calculate the change in register pressure. If the propagation
would increase the pressure beyond the number of hard regs, we
don't perform it.
The regpressure commit this patch depends on is not yet pushed
because I figured I'd post the code using it in case of further
comments.
The testsuite is unchanged on i386 and power10 but aarch64 has
some new FAILs but I'm not terribly familiar with aarch64, hence
some examples here:
The following cases shrn-combine-1/2/3 seem worse as we emit one
instruction more.
Before:
shrnv30.8b, v30.8h, 2
shrn2 v30.16b, v31.8h, 2
str q30, [x1, x3]
After:
ushrv30.8h, v30.8h, 2
ushrv31.8h, v31.8h, 2
uzp1v31.16b, v30.16b, v31.16b
str q31, [x1, x3]
Here, one optimization already happens in fwprop so combine
cannot do the same work it did before.
vec-init-22-speed.c changes from
sxthw0, w0
sxthw1, w1
fmovd31, x0
fmovd0, x1
to:
dup v31.4h, w0
dup v0.4h, w1
which I hope has the same semantics and is shorter.
Apart from that there are numerous check-asm testcases where
a new, earlier propagation prevents a later, supposedly better
propagation. One such example is from ld4_s8.c:
(insn 11 10 12 2 (set (reg:DI 100)
(neg:DI (reg:DI 102))) 385 {negdi2}
(expr_list:REG_EQUAL (const_poly_int:DI [-576, -576])
(nil)))
(insn 12 11 13 2 (set (reg/f:DI 99)
(plus:DI (reg/v/f:DI 97 [ x0 ])
(reg:DI 100))) 153 {*adddi3_aarch64}
(expr_list:REG_EQUAL (plus:DI (reg/v/f:DI 97 [ x0 ])
(const_poly_int:DI [-576, -576]))
(nil)))
(insn 13 12 14 2 (set (reg/v:VNx64QI 94 [ z0 ])
(unspec:VNx64QI [
(reg/v:VNx16BI 96 [ p0 ])
(mem:VNx64QI (reg/f:DI 99) [0 MEM [(signed char
*)_1]+0 S[64, 64] A8])
] UNSPEC_LDN)) 5885 {vec_mask_load_lanesvnx64qivnx16qi}
(nil))
where we now do:
propagating insn 11 into insn 12, replacing:
(set (reg/f:DI 99)
(plus:DI (reg/v/f:DI 97 [ x0 ])
(reg:DI 100)))
successfully matched this instruction to subdi3:
(set (reg/f:DI 99)
(minus:DI (reg/v/f:DI 97 [ x0 ])
(reg:DI 102)))
vs before:
cannot propagate from insn 11 into insn 12: would increase complexity of
pattern
propagating insn 12 into insn 13, replacing:
(set (reg/v:VNx64QI 94 [ z0 ])
(unspec:VNx64QI [
(reg/v:VNx16BI 96 [ p0 ])
(mem:VNx64QI (reg/f:DI 99) [0 MEM [(signed char
*)_1]+0 S[64, 64] A8])
] UNSPEC_LDN))
successfully matched this instruction to vec_mask_load_lanesvnx64qivnx16qi:
(set (reg/v:VNx64QI 94 [ z0 ])
(unspec:VNx64QI [
(reg/v:VNx16BI 96 [ p0 ])
(mem:VNx64QI (plus:DI (reg/v/f:DI 97 [ x0 ])
(reg:DI 100)) [0 MEM [(signed char *)_1]+0
S[64, 64] A8])
] UNSPEC_LDN))
All in all this seems like a general problem with earlier
optimizations preventing later ones and surely all of those
could be fixed individually. Still, the question remains if
the general approach is useful or desired or if we not rather
prevent more optimizations that we gain. Suggestions welcome.
I have some riscv tests for it but didn't attach them yet
in order to focus on the main part first.
Regards
Robin
gcc/ChangeLog:
* fwprop.cc (fwprop_propagation::profitable_p): Add unary
handling.
(fwprop_propagation::update_register_pressure): New function.
(fwprop_propagation::register_pressure_high_p): New function
(reg_single_def_for_src_p): Look through unary expressions.
(try_fwprop_subst_pattern): Check register pressure.
(forward_propagate_into): Call new function.
(fwprop_init): Init register pressure.
(fwprop_done): Clean up register pressure.
(fwprop_insn): Add comment.
---
gcc/fwprop.cc | 307 --
1 file changed, 300 insertions(+), 7 deletions(-)
diff --git a/gcc/fwprop.cc b/gcc/fwprop.cc
index 0707a234726..413fe4e7335 100644
--- a/gcc/fwprop.cc
+++ b/gcc/fwprop.cc
@@ -36,6 +36,10 @@ along with GCC; see the file COPYING3. If not see
#include "tree-pass.h"
#include "rtl-iter.h"
#include "target.h"
+#include "dominance.h"
+
+#include "ira.h"
+#include "regpressure.h"
/* This p
Re: [RFC] Combine zero_extract and sign_extend for TARGET_TRULY_NOOP_TRUNCATION
On Thu, 3 Aug 2023, YunQiang Su wrote: > PR #104914 Please don't cc me on MIPS matters, I have told you I have withdrawn my interest in this architecture on the GCC side. Thank you. Maciej
Re: [committed] Fix several preprocessor directives
On Sun, 30 Jul 2023 at 14:55, François Dumont via Libstdc++ < libstd...@gcc.gnu.org> wrote: > Committed as obvious. > > libstdc++: Fix several preprocessor directives > > A wrong usage of #define in place of a #error seems to have been > replicated > at different places in source files. > Oops, thanks! > > libstdc++-v3/ChangeLog: > > * src/c++11/compatibility-ldbl-facets-aliases.h: Replace > #define with > proper #error. > * src/c++11/locale-inst-monetary.h: Likewise. > * src/c++11/locale-inst-numeric.h: Likewise. > > François >
[COMMITTED] ada: Spurious error on class-wide preconditions
From: Javier Miranda The compiler reports an spurious error when a class-wide precondition expression has a class-wide type conversion. gcc/ada/ * sem_res.adb (Resolve_Type_Conversion): Do not warn on conversion to class-wide type on internally build helpers of class-wide preconditions. Tested on x86_64-pc-linux-gnu, committed on master. --- gcc/ada/sem_res.adb | 12 1 file changed, 12 insertions(+) diff --git a/gcc/ada/sem_res.adb b/gcc/ada/sem_res.adb index d3a0192fb09..ac0c60f5f22 100644 --- a/gcc/ada/sem_res.adb +++ b/gcc/ada/sem_res.adb @@ -12455,6 +12455,18 @@ package body Sem_Res is elsif Orig_T = Base_Type (Standard_Long_Long_Integer) then null; +-- Do not warn on conversion to class-wide type on helpers of +-- class-wide preconditions because in this context the warning +-- would be spurious (since the class-wide precondition has been +-- installed in the return statement of the helper, which has a +-- class-wide formal type instead of a regular tagged type). + +elsif Is_Class_Wide_Type (Orig_T) + and then Is_Subprogram_Or_Generic_Subprogram (Current_Scope) + and then Present (Class_Preconditions_Subprogram (Current_Scope)) +then + null; + -- Here we give the redundant conversion warning. If it is an -- entity, give the name of the entity in the message. If not, -- just mention the expression. -- 2.40.0
[COMMITTED] ada: Crash in GNATprove due to wrong detection of inlining
From: Yannick Moy
When a function is called in a predicate, it was not properly detected
as not always inlined in GNATprove mode, which led to crashes later during
analysis. Fixed now.
gcc/ada/
* sem_res.adb (Resolve_Call): Always call Cannot_Inline so that
subprogram called is marked as not always inlined.
Tested on x86_64-pc-linux-gnu, committed on master.
---
gcc/ada/sem_res.adb | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/gcc/ada/sem_res.adb b/gcc/ada/sem_res.adb
index ac0c60f5f22..9755e4d14a6 100644
--- a/gcc/ada/sem_res.adb
+++ b/gcc/ada/sem_res.adb
@@ -7330,30 +7330,32 @@ package body Sem_Res is
or else Is_Invariant_Procedure (Current_Subprogram)
or else Is_DIC_Procedure (Current_Subprogram))
then
- if Present (Body_Id)
-and then Present (Body_To_Inline (Nam_Decl))
- then
+ declare
+ Issue_Msg : constant Boolean :=
+ Present (Body_Id)
+ and then Present (Body_To_Inline (Nam_Decl));
+ begin
if Is_Predicate_Function (Current_Subprogram) then
Cannot_Inline
("cannot inline & (inside predicate)?",
- N, Nam_UA);
+ N, Nam_UA, Suppress_Info => not Issue_Msg);
elsif Is_Invariant_Procedure (Current_Subprogram) then
Cannot_Inline
("cannot inline & (inside invariant)?",
- N, Nam_UA);
+ N, Nam_UA, Suppress_Info => not Issue_Msg);
elsif Is_DIC_Procedure (Current_Subprogram) then
Cannot_Inline
("cannot inline & (inside Default_Initial_Condition)?",
- N, Nam_UA);
+ N, Nam_UA, Suppress_Info => not Issue_Msg);
else
Cannot_Inline
("cannot inline & (inside expression function)?",
- N, Nam_UA);
+ N, Nam_UA, Suppress_Info => not Issue_Msg);
end if;
- end if;
+ end;
-- Cannot inline a call inside the definition of a record type,
-- typically inside the constraints of the type. Calls in
--
2.40.0
[COMMITTED] ada: Extend precondition of Interfaces.C.String.Value with Length
From: Piotr Trojanek The existing precondition guarded against exception Dereference_Error, but not against Constraint_Error. The RM rule B.3.1(36/3) only mentions Constraint_Error for the Value function which returns char_array, but the one which returns String has the same restriction, because it is equivalent to calling the variant which returns char_array and then converted. gcc/ada/ * libgnat/i-cstrin.ads (Value): Extend preconditions; adapt comment for the package. Tested on x86_64-pc-linux-gnu, committed on master. --- gcc/ada/libgnat/i-cstrin.ads | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/gcc/ada/libgnat/i-cstrin.ads b/gcc/ada/libgnat/i-cstrin.ads index e486f03a585..9f1577f5e14 100644 --- a/gcc/ada/libgnat/i-cstrin.ads +++ b/gcc/ada/libgnat/i-cstrin.ads @@ -36,8 +36,8 @@ -- Preconditions in this unit are meant for analysis only, not for run-time -- checking, so that the expected exceptions are raised. This is enforced by -- setting the corresponding assertion policy to Ignore. These preconditions --- protect from Dereference_Error and Update_Error, but not from --- Storage_Error. +-- protect from Constraint_Error, Dereference_Error and Update_Error, but not +-- from Storage_Error. pragma Assertion_Policy (Pre => Ignore); @@ -95,7 +95,7 @@ is (Item : chars_ptr; Length : size_t) return char_array with - Pre=> Item /= Null_Ptr, + Pre=> Item /= Null_Ptr and then Length /= 0, Global => (Input => C_Memory); function Value (Item : chars_ptr) return String with @@ -106,7 +106,7 @@ is (Item : chars_ptr; Length : size_t) return String with - Pre=> Item /= Null_Ptr, + Pre=> Item /= Null_Ptr and then Length /= 0, Global => (Input => C_Memory); function Strlen (Item : chars_ptr) return size_t with -- 2.40.0
[COMMITTED] ada: Refactor multiple returns
From: Sheri Bernstein Replace multiple returns by a single return statement with a conditional expression. This is more readable and maintainable, and also conformant with a Highly Recommended design principle of ISO 26262-6. gcc/ada/ * libgnat/s-parame__qnx.adb: Refactor multiple returns. Tested on x86_64-pc-linux-gnu, committed on master. --- gcc/ada/libgnat/s-parame__qnx.adb | 30 +++--- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/gcc/ada/libgnat/s-parame__qnx.adb b/gcc/ada/libgnat/s-parame__qnx.adb index d9b46b6f795..8a7dfaf57d0 100644 --- a/gcc/ada/libgnat/s-parame__qnx.adb +++ b/gcc/ada/libgnat/s-parame__qnx.adb @@ -39,13 +39,11 @@ package body System.Parameters is function Adjust_Storage_Size (Size : Size_Type) return Size_Type is begin - if Size = Unspecified_Size then - return Default_Stack_Size; - elsif Size < Minimum_Stack_Size then - return Minimum_Stack_Size; - else - return Size; - end if; + return + (if Size = Unspecified_Size then Default_Stack_Size + elsif Size < Minimum_Stack_Size then Minimum_Stack_Size + else Size + ); end Adjust_Storage_Size; @@ -56,14 +54,16 @@ package body System.Parameters is Default_Stack_Size : constant Integer; pragma Import (C, Default_Stack_Size, "__gl_default_stack_size"); begin - if Default_Stack_Size = -1 then - -- 256K is the default stack size on aarch64 QNX - return 256 * 1024; - elsif Size_Type (Default_Stack_Size) < Minimum_Stack_Size then - return Minimum_Stack_Size; - else - return Size_Type (Default_Stack_Size); - end if; + return + (if Default_Stack_Size = -1 + then + (256 * 1024) -- 256K is the default stack size on aarch64 QNX + elsif Size_Type (Default_Stack_Size) < Minimum_Stack_Size + then + Minimum_Stack_Size + else + Size_Type (Default_Stack_Size) + ); end Default_Stack_Size; -- 2.40.0
[PATCH 00/24] Sync shared build infrastructure with binutils-gdb
Hello, This patch set, combined with a sibling patch set sent on the binutils and GDB MLs, bring up the shared infrastructure between the two projects in sync again. It largely consists of cherry-picks from various people which have been reviewed and accepted on the binutils-gdb side, as well as a couple of patches for differences that seemed to get lost during the pick-and-regenerate process, though I've had to reformat quite a few commits so that they match what the changelog verifier expects. Some of these commits were previously applied and then reverted, namely "Check if AR works with --plugin and rc", but the reversion reason[1] seems to be no longer valid as of requiring Binutils 2.35 for LTO anyway. In addition, I'm not entirely certain that the handling of the removed targets I re-added is correct, nor what their status in binutils and gdb is, so feedback is welcome there. During this process, it appears that I overlooked passing -x to cherry-pick, so the paper trail got lost. If needed, I can hack together some code to associate commits based on subjects with their pair in the other repository, and amend the commits with these references added. These patches ignore the intl/ directory, as I plan to follow up this patchset with one that can be cleanly applied to both trees which gets rid of the intl/ directory in favor of out-of-tree gettext (ISL, GMP, et al. style). Bootstrapped and reg-tested on x86_64-pc-linux-gnu. OK for master? Thanks in advance, have a lovely day. [1]: https://inbox.sourceware.org/gcc-patches/CAMe9rOqFSOSM5Sw5SBMiy20rdgRJkftUXdw=ykexhvdmuty...@mail.gmail.com/ Alan Modra (4): PR29961, plugin-api.h: "Could not detect architecture endianess" gcc-4.5 build fixes egrep in binutils PR27116, Spelling errors found by Debian style checker Alexander von Gluck IV (1): Add support for the haiku operating system Arsen Arsenović (3): toplevel: Substitute GDCFLAGS instead of using CFLAGS toplevel: Recover tilegx/tilepro targets configure: reinstate 32b PA-RISC HP-UX target in toplevel Christophe Lyon (1): configure: require libzstd >= 1.4.0 Fangrui Song (1): binutils, gdb: support zstd compressed debug sections H.J. Lu (4): Sync with binutils: GCC: Pass --plugin to AR and RANLIB GCC: Check if AR works with --plugin and rc PKG_CHECK_MODULES: Check if $pkg_cv_[]$1[]_LIBS works PKG_CHECK_MODULES: Properly check if $pkg_cv_[]$1[]_LIBS works Indu Bhagat (2): bfd: linker: merge .sframe sections toplevel: Makefile.def: add install-strip dependency on libsframe John Ericson (1): Deprecate a.out support for NetBSD targets. Luis Machado (1): Disable year 2038 support on 32-bit hosts by default Martin Liska (1): add --enable-default-compressed-debug-sections-algorithm configure option Nick Alcock (3): libtool.m4: fix nm BSD flag detection libtool.m4: fix the NM="/nm/over/here -B/option/with/path" case libtool.m4: augment symcode for Solaris 11 Simon Marchi (1): Pass PKG_CONFIG_PATH down from top-level Makefile Vladimir Mezentsev (1): gprofng: a new GNU profiler Makefile.def | 18 ++ Makefile.in| 517 - Makefile.tpl | 10 +- config/gcc-plugin.m4 | 40 +++ config/lib-ld.m4 | 8 +- config/override.m4 | 2 +- config/picflag.m4 | 4 +- config/pkg.m4 | 8 + config/zstd.m4 | 23 ++ configure | 224 +++- configure.ac | 74 +- fixincludes/configure | 3 +- gcc/configure | 140 ++ include/collectorAPI.h | 73 ++ include/libcollector.h | 89 +++ include/libfcollector.h| 42 +++ include/plugin-api.h | 49 ++-- include/xtensa-dynconfig.h | 2 - intl/configure | 4 +- libada/configure | 4 +- libatomic/configure| 130 ++ libbacktrace/configure | 130 ++ libcc1/configure | 132 ++ libcpp/configure | 4 +- libffi/configure | 132 ++ libgcc/configure | 6 +- libgfortran/configure | 132 ++ libgm2/configure | 132 ++ libgomp/configure | 132 ++ libiberty/Makefile.in | 5 +- libiberty/aclocal.m4 | 1 + libiberty/configure| 144 ++- libiberty/configure.ac | 12 + libitm/configure | 132 ++ libobjc/configure | 130 ++ libphobos/configure| 130 ++ libquadmath/configure | 130 ++ libsanitizer/configure | 132 ++ libssp/configure | 130 ++ libstdc++-v3/configure | 148 +++ libtool.m4 | 130 ++ libvtv/configure | 132 ++ lto-plugin/configure | 130 ++ zlib/configure | 130 ++ 44 files changed, 2924 insertions(+), 956 dele
[PATCH 01/24] toplevel: Substitute GDCFLAGS instead of using CFLAGS
r14-2875-g1ed21e23d6d4da ("Use substituted GDCFLAGS") already
implemented this change, but only on the generated file rather than in
the template it is generated from.
ChangeLog:
* Makefile.tpl: Substitute @GDCFLAGS@ instead of using
$(CFLAGS).
---
Makefile.tpl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Makefile.tpl b/Makefile.tpl
index d0fe7e2fb77..4fdca604eb0 100644
--- a/Makefile.tpl
+++ b/Makefile.tpl
@@ -447,7 +447,7 @@ LIBCFLAGS = $(CFLAGS)
CXXFLAGS = @CXXFLAGS@
LIBCXXFLAGS = $(CXXFLAGS) -fno-implicit-templates
GOCFLAGS = $(CFLAGS)
-GDCFLAGS = $(CFLAGS)
+GDCFLAGS = @GDCFLAGS@
GM2FLAGS = $(CFLAGS)
# Pass additional PGO and LTO compiler options to the PGO build.
--
2.41.0
[PATCH 09/24] add --enable-default-compressed-debug-sections-algorithm configure option
From: Martin Liska
ChangeLog:
* configure.ac: Add
--enable-default-compressed-debug-sections-algorithm.
* configure: Regenerate.
---
configure| 13 +
configure.ac | 6 ++
2 files changed, 19 insertions(+)
diff --git a/configure b/configure
index a5f6282bb0e..c5f6ae8e745 100755
--- a/configure
+++ b/configure
@@ -807,6 +807,7 @@ enable_offload_defaulted
enable_gold
enable_ld
enable_compressed_debug_sections
+enable_default_compressed_debug_sections_algorithm
enable_libquadmath
enable_libquadmath_support
enable_libada
@@ -1546,6 +1547,9 @@ Optional Features:
--enable-compressed-debug-sections={all,gas,gold,ld,none}
Enable compressed debug sections for gas, gold or ld
by default
+ --enable-default-compressed-debug-sections-algorithm={zlib,zstd}
+ Default compression algorithm for
+ --enable-compressed-debug-sections.
--disable-libquadmath do not build libquadmath directory
--disable-libquadmath-support
disable libquadmath support for Fortran
@@ -3142,6 +3146,15 @@ else
fi
+# Select default compression algorithm.
+# Check whether --enable-default_compressed_debug_sections_algorithm was given.
+if test "${enable_default_compressed_debug_sections_algorithm+set}" = set;
then :
+ enableval=$enable_default_compressed_debug_sections_algorithm;
+else
+ default_compressed_debug_sections_algorithm=
+fi
+
+
# Configure extra directories which are host specific
case "${host}" in
diff --git a/configure.ac b/configure.ac
index e820940c81e..ef30300af28 100644
--- a/configure.ac
+++ b/configure.ac
@@ -418,6 +418,12 @@ AC_ARG_ENABLE(compressed_debug_sections,
fi
], [enable_compressed_debug_sections=])
+# Select default compression algorithm.
+AC_ARG_ENABLE(default_compressed_debug_sections_algorithm,
+[AS_HELP_STRING([--enable-default-compressed-debug-sections-algorithm={zlib,zstd}],
+ [Default compression algorithm for
--enable-compressed-debug-sections.])],
+[], [default_compressed_debug_sections_algorithm=])
+
# Configure extra directories which are host specific
case "${host}" in
--
2.41.0
[PATCH 03/24] gcc-4.5 build fixes
From: Alan Modra Trying to build binutils with an older gcc currently fails. Working around these gcc bugs is not onerous so let's fix them. include/ChangeLog: * xtensa-dynconfig.h (xtensa_isa_internal): Delete unnecessary forward declaration. --- include/xtensa-dynconfig.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/include/xtensa-dynconfig.h b/include/xtensa-dynconfig.h index 48877ebb6b6..45d54dcd0e0 100644 --- a/include/xtensa-dynconfig.h +++ b/include/xtensa-dynconfig.h @@ -121,8 +121,6 @@ struct xtensa_config_v4 int xchal_unaligned_store_hw; }; -typedef struct xtensa_isa_internal_struct xtensa_isa_internal; - extern const void *xtensa_load_config (const char *name, const void *no_plugin_def, const void *no_name_def); -- 2.41.0
[PATCH 11/24] Disable year 2038 support on 32-bit hosts by default
From: Luis Machado
With a recent import of gnulib, code has been pulled that tests and enables
64-bit time_t by default on 32-bit hosts that support it.
Although gdb can use the gnulib support, bfd doesn't use gnulib and currently
doesn't do these checks.
As a consequence, if we have a 32-bit host that supports 64-bit time_t, we'll
have a mismatch between gdb's notion of time_t and bfd's notion of time_t.
This will lead to mismatches in the struct stat size, leading to memory
corruption and crashes.
This patch disables the year 2038 check for now, which makes things work
reliably again.
I'd consider this a temporary fix until we have proper bfd checks for the year
2038, if it makes sense. 64-bit hosts seems to be more common these days, so
I'm not sure how important it is to have this support enabled and how soon
we want to enable it.
Thoughts?
ChangeLog:
* configure.ac: Disable year2038 by default on 32-bit hosts.
* configure: Regenerate.
---
configure| 22 ++
configure.ac | 18 ++
2 files changed, 40 insertions(+)
diff --git a/configure b/configure
index 35c0c75ee12..faa1aedaa04 100755
--- a/configure
+++ b/configure
@@ -809,6 +809,7 @@ enable_ld
enable_gprofng
enable_compressed_debug_sections
enable_default_compressed_debug_sections_algorithm
+enable_year2038
enable_libquadmath
enable_libquadmath_support
enable_libada
@@ -1552,6 +1553,7 @@ Optional Features:
--enable-default-compressed-debug-sections-algorithm={zlib,zstd}
Default compression algorithm for
--enable-compressed-debug-sections.
+ --enable-year2038 enable support for timestamps past the year 2038
--disable-libquadmath do not build libquadmath directory
--disable-libquadmath-support
disable libquadmath support for Fortran
@@ -3194,6 +3196,20 @@ case "${host}" in
;;
esac
+# Default to --disable-year2038 until we can handle differences between
+# projects that use gnulib (which understands year 2038) and projects that
+# do not (like BFD).
+# Check whether --enable-year2038 was given.
+if test "${enable_year2038+set}" = set; then :
+ enableval=$enable_year2038; ENABLE_YEAR2038=$enableval
+else
+ ENABLE_YEAR2038=no
+fi
+
+enable_year2038=
+if test "${ENABLE_YEAR2038}" = "no" ; then
+ enable_year2038=no
+fi
# Check whether --enable-libquadmath was given.
if test "${enable_libquadmath+set}" = set; then :
@@ -10215,9 +10231,15 @@ if test "$silent" = yes; then
baseargs="$baseargs --silent"
tbaseargs="$tbaseargs --silent"
fi
+
baseargs="$baseargs --disable-option-checking"
tbaseargs="$tbaseargs --disable-option-checking"
+if test "$enable_year2038" = no; then
+ baseargs="$baseargs --disable-year2038"
+ tbaseargs="$tbaseargs --disable-year2038"
+fi
+
# Record and document user additions to sub configure arguments.
diff --git a/configure.ac b/configure.ac
index 71b923d316f..a0dff0ecac8 100644
--- a/configure.ac
+++ b/configure.ac
@@ -459,6 +459,18 @@ case "${host}" in
;;
esac
+# Default to --disable-year2038 until we can handle differences between
+# projects that use gnulib (which understands year 2038) and projects that
+# do not (like BFD).
+AC_ARG_ENABLE(year2038,
+AS_HELP_STRING([--enable-year2038],
+ [enable support for timestamps past the year 2038]),
+ENABLE_YEAR2038=$enableval,
+ENABLE_YEAR2038=no)
+enable_year2038=
+if test "${ENABLE_YEAR2038}" = "no" ; then
+ enable_year2038=no
+fi
AC_ARG_ENABLE(libquadmath,
AS_HELP_STRING([--disable-libquadmath],
@@ -3339,9 +3351,15 @@ if test "$silent" = yes; then
baseargs="$baseargs --silent"
tbaseargs="$tbaseargs --silent"
fi
+
baseargs="$baseargs --disable-option-checking"
tbaseargs="$tbaseargs --disable-option-checking"
+if test "$enable_year2038" = no; then
+ baseargs="$baseargs --disable-year2038"
+ tbaseargs="$tbaseargs --disable-year2038"
+fi
+
# Record and document user additions to sub configure arguments.
AC_ARG_VAR([build_configargs],
[additional configure arguments for build directories])
--
2.41.0
[PATCH 06/24] toplevel: Recover tilegx/tilepro targets
These are still supported in Binutils.
ChangeLog:
* configure: Regenerate.
* configure.ac: Recover tilegx/tilepro targets.
---
configure| 5 -
configure.ac | 5 -
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/configure b/configure
index 3fe4a1804cf..04369383079 100755
--- a/configure
+++ b/configure
@@ -3072,7 +3072,7 @@ case "${ENABLE_GOLD}" in
# Check for target supported by gold.
case "${target}" in
i?86-*-* | x86_64-*-* | sparc*-*-* | powerpc*-*-* | arm*-*-* \
-| aarch64*-*-* | mips*-*-* | s390*-*-* | loongarch*-*-*)
+| aarch64*-*-* | tilegx*-*-* | mips*-*-* | s390*-*-* | loongarch*-*-*)
configdirs="$configdirs gold"
if test x${ENABLE_GOLD} = xdefault; then
default_ld=gold
@@ -3977,6 +3977,9 @@ case "${target}" in
tic6x-*-*)
noconfigdirs="$noconfigdirs sim"
;;
+ tilepro*-*-* | tilegx*-*-*)
+noconfigdirs="$noconfigdirs sim"
+;;
v810-*-*)
noconfigdirs="$noconfigdirs bfd binutils gas gdb ld opcodes
target-libgloss"
;;
diff --git a/configure.ac b/configure.ac
index a11b1006427..3632216fd1c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -360,7 +360,7 @@ case "${ENABLE_GOLD}" in
# Check for target supported by gold.
case "${target}" in
i?86-*-* | x86_64-*-* | sparc*-*-* | powerpc*-*-* | arm*-*-* \
-| aarch64*-*-* | mips*-*-* | s390*-*-* | loongarch*-*-*)
+| aarch64*-*-* | tilegx*-*-* | mips*-*-* | s390*-*-* | loongarch*-*-*)
configdirs="$configdirs gold"
if test x${ENABLE_GOLD} = xdefault; then
default_ld=gold
@@ -1227,6 +1227,9 @@ case "${target}" in
tic6x-*-*)
noconfigdirs="$noconfigdirs sim"
;;
+ tilepro*-*-* | tilegx*-*-*)
+noconfigdirs="$noconfigdirs sim"
+;;
v810-*-*)
noconfigdirs="$noconfigdirs bfd binutils gas gdb ld opcodes
target-libgloss"
;;
--
2.41.0
[PATCH 02/24] PR29961, plugin-api.h: "Could not detect architecture endianess"
From: Alan Modra Found when attempting to build binutils on sparc sunos-5.8 where sys/byteorder.h defines _BIG_ENDIAN but not any of the BYTE_ORDER variants. This patch adds the extra tests to cope with the old machine, and tidies the header a little. include/ChangeLog: * plugin-api.h: When handling non-gcc or gcc < 4.6.0 include necessary header files before testing macros. Make more use of #elif. Test _LITTLE_ENDIAN and _BIG_ENDIAN in final tests. --- include/plugin-api.h | 49 ++-- 1 file changed, 25 insertions(+), 24 deletions(-) diff --git a/include/plugin-api.h b/include/plugin-api.h index 395d5bcc598..f3cf2d8101b 100644 --- a/include/plugin-api.h +++ b/include/plugin-api.h @@ -37,7 +37,7 @@ #error cannot find uint64_t type #endif -/* Detect endianess based on __BYTE_ORDER__ macro. */ +/* Detect endianess based on gcc's (>=4.6.0) __BYTE_ORDER__ macro. */ #if defined(__BYTE_ORDER__) && defined(__ORDER_BIG_ENDIAN__) && \ defined(__ORDER_LITTLE_ENDIAN__) && defined(__ORDER_PDP_ENDIAN__) #if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ @@ -47,46 +47,47 @@ #elif __BYTE_ORDER__ == __ORDER_PDP_ENDIAN__ #define PLUGIN_PDP_ENDIAN 1 #endif + #else -/* Older GCC releases (<4.6.0) can make detection from glibc macros. */ +/* Include header files to define endian macros. */ #if defined(__GLIBC__) || defined(__GNU_LIBRARY__) || defined(__ANDROID__) #include -#ifdef __BYTE_ORDER -#if __BYTE_ORDER == __LITTLE_ENDIAN -#define PLUGIN_LITTLE_ENDIAN 1 -#elif __BYTE_ORDER == __BIG_ENDIAN -#define PLUGIN_BIG_ENDIAN 1 -#endif -#endif -#endif -/* Include all necessary header files based on target. */ -#if defined(__SVR4) && defined(__sun) + +#elif defined(__SVR4) && defined(__sun) #include -#endif -#if defined(__FreeBSD__) || defined(__NetBSD__) || \ -defined(__DragonFly__) || defined(__minix) + +#elif defined(__FreeBSD__) || defined(__NetBSD__) || \ + defined(__DragonFly__) || defined(__minix) #include -#endif -#if defined(__OpenBSD__) + +#elif defined(__OpenBSD__) #include #endif + +/* Detect endianess based on __BYTE_ORDER. */ +#ifdef __BYTE_ORDER +#if __BYTE_ORDER == __LITTLE_ENDIAN +#define PLUGIN_LITTLE_ENDIAN 1 +#elif __BYTE_ORDER == __BIG_ENDIAN +#define PLUGIN_BIG_ENDIAN 1 +#endif + /* Detect endianess based on _BYTE_ORDER. */ -#ifdef _BYTE_ORDER +#elif defined _BYTE_ORDER #if _BYTE_ORDER == _LITTLE_ENDIAN #define PLUGIN_LITTLE_ENDIAN 1 #elif _BYTE_ORDER == _BIG_ENDIAN #define PLUGIN_BIG_ENDIAN 1 #endif -#endif + /* Detect based on _WIN32. */ -#if defined(_WIN32) +#elif defined _WIN32 #define PLUGIN_LITTLE_ENDIAN 1 -#endif + /* Detect based on __BIG_ENDIAN__ and __LITTLE_ENDIAN__ */ -#ifdef __LITTLE_ENDIAN__ +#elif defined __LITTLE_ENDIAN__ || defined _LITTLE_ENDIAN #define PLUGIN_LITTLE_ENDIAN 1 -#endif -#ifdef __BIG_ENDIAN__ +#elif defined __BIG_ENDIAN__ || defined _BIG_ENDIAN #define PLUGIN_BIG_ENDIAN 1 #endif #endif -- 2.41.0
[PATCH 08/24] configure: require libzstd >= 1.4.0
From: Christophe Lyon gas uses ZSTD_compressStream2 which is only available with libzstd >= 1.4.0, leading to build errors when an older version is installed. This patch updates the check libzstd presence to check its version is >= 1.4.0. However, since gas seems to be the only component requiring such a recent version this may imply that we disable ZSTD support for all components although some would still benefit from an older version. I ran 'autoreconf -f' in all directories containing a configure.ac file, using vanilla autoconf-2.69 and automake-1.15.1. I noticed several errors from autoheader in readline, as well as warnings in intl, but they are unrelated to this patch. This should fix some of the buildbots. OK for trunk? Thanks, Christophe config/ChangeLog: * zstd.m4: Add minimum version requirement of 1.4.0. --- config/zstd.m4 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/config/zstd.m4 b/config/zstd.m4 index 6da4db68c58..eb34c0f36d7 100644 --- a/config/zstd.m4 +++ b/config/zstd.m4 @@ -12,7 +12,7 @@ AC_ARG_WITH(zstd, [], [with_zstd=auto]) AS_IF([test "$with_zstd" != no], - [PKG_CHECK_MODULES(ZSTD, [libzstd], [ + [PKG_CHECK_MODULES(ZSTD, [libzstd >= 1.4.0], [ AC_DEFINE(HAVE_ZSTD, 1, [Define to 1 if zstd is enabled.]) ], [ if test "$with_zstd" = yes; then -- 2.41.0
[PATCH 07/24] binutils, gdb: support zstd compressed debug sections
From: Fangrui Song
PR29397 PR29563: Add new configure option --with-zstd which defaults to
auto. If pkgconfig/libzstd.pc is found, define HAVE_ZSTD and support
zstd compressed debug sections for most tools.
* bfd: for addr2line, objdump --dwarf, gdb, etc
* gas: support --compress-debug-sections=zstd
* ld: support ELFCOMPRESS_ZSTD input and --compress-debug-sections=zstd
* objcopy: support ELFCOMPRESS_ZSTD input for
--decompress-debug-sections and --compress-debug-sections=zstd
* gdb: support ELFCOMPRESS_ZSTD input. The bfd change references zstd
symbols, so gdb has to link against -lzstd in this patch.
If zstd is not supported, ELFCOMPRESS_ZSTD input triggers an error. We
can avoid HAVE_ZSTD if binutils-gdb imports zstd/ like zlib/, but this
is too heavyweight, so don't do it for now.
```
% ld/ld-new a.o
ld/ld-new: a.o: section .debug_abbrev is compressed with zstd, but BFD is not
built with zstd support
...
% ld/ld-new a.o --compress-debug-sections=zstd
ld/ld-new: --compress-debug-sections=zstd: ld is not built with zstd support
% binutils/objcopy --compress-debug-sections=zstd a.o b.o
binutils/objcopy: --compress-debug-sections=zstd: binutils is not built with
zstd support
% binutils/objcopy b.o --decompress-debug-sections
binutils/objcopy: zstd.o: section .debug_abbrev is compressed with zstd, but
BFD is not built with zstd support
...
```
config/ChangeLog:
* zstd.m4: New file.
ChangeLog:
* configure: Regenerate.
* configure.ac: Add --with-zstd.
---
config/zstd.m4 | 23 +++
configure | 10 ++
configure.ac | 3 +++
3 files changed, 36 insertions(+)
create mode 100644 config/zstd.m4
diff --git a/config/zstd.m4 b/config/zstd.m4
new file mode 100644
index 000..6da4db68c58
--- /dev/null
+++ b/config/zstd.m4
@@ -0,0 +1,23 @@
+dnl Copyright (C) 2022 Free Software Foundation, Inc.
+dnl This file is free software, distributed under the terms of the GNU
+dnl General Public License. As a special exception to the GNU General
+dnl Public License, this file may be distributed as part of a program
+dnl that contains a configuration script generated by Autoconf, under
+dnl the same distribution terms as the rest of that program.
+
+dnl Enable features using the zstd library.
+AC_DEFUN([AC_ZSTD], [
+AC_ARG_WITH(zstd,
+ [AS_HELP_STRING([--with-zstd], [support zstd compressed debug sections
(default=auto)])],
+ [], [with_zstd=auto])
+
+AS_IF([test "$with_zstd" != no],
+ [PKG_CHECK_MODULES(ZSTD, [libzstd], [
+AC_DEFINE(HAVE_ZSTD, 1, [Define to 1 if zstd is enabled.])
+ ], [
+if test "$with_zstd" = yes; then
+ AC_MSG_ERROR([--with-zstd was given, but pkgconfig/libzstd.pc is not
found])
+fi
+ ])
+ ])
+])
diff --git a/configure b/configure
index 04369383079..a5f6282bb0e 100755
--- a/configure
+++ b/configure
@@ -800,6 +800,7 @@ ac_user_opts='
enable_option_checking
with_build_libsubdir
with_system_zlib
+with_zstd
enable_as_accelerator_for
enable_offload_targets
enable_offload_defaulted
@@ -1589,6 +1590,8 @@ Optional Packages:
--without-PACKAGE do not use PACKAGE (same as --with-PACKAGE=no)
--with-build-libsubdir=DIR Directory where to find libraries for build
system
--with-system-zlib use installed libz
+ --with-zstd Support zstd compressed debug sections
+ (default=auto)
--with-mpc=PATH specify prefix directory for installed MPC package.
Equivalent to --with-mpc-include=PATH/include plus
--with-mpc-lib=PATH/lib
@@ -2962,6 +2965,13 @@ if test x$with_system_readline = xyes ; then
noconfigdirs="$noconfigdirs readline"
fi
+
+# Check whether --with-zstd was given.
+if test "${with_zstd+set}" = set; then :
+ withval=$with_zstd;
+fi
+
+
# some tools are so dependent upon X11 that if we're not building with X,
# it's not even worth trying to configure, much less build, that tool.
diff --git a/configure.ac b/configure.ac
index 3632216fd1c..e820940c81e 100644
--- a/configure.ac
+++ b/configure.ac
@@ -254,6 +254,9 @@ if test x$with_system_readline = xyes ; then
noconfigdirs="$noconfigdirs readline"
fi
+AC_ARG_WITH(zstd,
+[AS_HELP_STRING([--with-zstd], [Support zstd compressed debug sections
(default=auto)])])
+
# some tools are so dependent upon X11 that if we're not building with X,
# it's not even worth trying to configure, much less build, that tool.
--
2.41.0
[PATCH 05/24] GCC: Check if AR works with --plugin and rc
From: "H.J. Lu"
AR from older binutils doesn't work with --plugin and rc:
[hjl@gnu-cfl-2 bin]$ touch foo.c
[hjl@gnu-cfl-2 bin]$ ar --plugin
/usr/libexec/gcc/x86_64-redhat-linux/10/liblto_plugin.so rc libfoo.a foo.c
[hjl@gnu-cfl-2 bin]$ ./ar --plugin
/usr/libexec/gcc/x86_64-redhat-linux/10/liblto_plugin.so rc libfoo.a foo.c
./ar: no operation specified
[hjl@gnu-cfl-2 bin]$ ./ar --version
GNU ar (Linux/GNU Binutils) 2.29.51.0.1.20180112
Copyright (C) 2018 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) any later version.
This program has absolutely no warranty.
[hjl@gnu-cfl-2 bin]$
Check if AR works with --plugin and rc before passing --plugin to AR and
RANLIB.
ChangeLog:
* configure: Regenerated.
* libtool.m4 (_LT_CMD_OLD_ARCHIVE): Check if AR works with
--plugin and rc before enabling --plugin.
config/ChangeLog:
* gcc-plugin.m4 (GCC_PLUGIN_OPTION): Check if AR works with
--plugin and rc before enabling --plugin.
gcc/ChangeLog:
* configure: Regenerate.
libatomic/ChangeLog:
* configure: Regenerate.
libbacktrace/ChangeLog:
* configure: Regenerate.
libcc1/ChangeLog:
* configure: Regenerate.
libffi/ChangeLog:
* configure: Regenerate.
libgfortran/ChangeLog:
* configure: Regenerate.
libgm2/ChangeLog:
* configure: Regenerate.
libgomp/ChangeLog:
* configure: Regenerate.
libiberty/ChangeLog:
* configure: Regenerate.
libitm/ChangeLog:
* configure: Regenerate.
libobjc/ChangeLog:
* configure: Regenerate.
libphobos/ChangeLog:
* configure: Regenerate.
libquadmath/ChangeLog:
* configure: Regenerate.
libsanitizer/ChangeLog:
* configure: Regenerate.
libssp/ChangeLog:
* configure: Regenerate.
libstdc++-v3/ChangeLog:
* configure: Regenerate.
libvtv/ChangeLog:
* configure: Regenerate.
lto-plugin/ChangeLog:
* configure: Regenerate.
zlib/ChangeLog:
* configure: Regenerate.
---
config/gcc-plugin.m4 | 12 +
configure | 103 +
gcc/configure | 14 --
libatomic/configure| 14 --
libbacktrace/configure | 14 --
libcc1/configure | 14 --
libffi/configure | 14 --
libgfortran/configure | 14 --
libgm2/configure | 14 --
libgomp/configure | 14 --
libiberty/configure| 103 +
libitm/configure | 14 --
libobjc/configure | 14 --
libphobos/configure| 14 --
libquadmath/configure | 14 --
libsanitizer/configure | 14 --
libssp/configure | 14 --
libstdc++-v3/configure | 26 +++
libtool.m4 | 9 +++-
libvtv/configure | 14 --
lto-plugin/configure | 14 --
zlib/configure | 14 --
22 files changed, 430 insertions(+), 61 deletions(-)
diff --git a/config/gcc-plugin.m4 b/config/gcc-plugin.m4
index d782d52858e..c731a6fab38 100644
--- a/config/gcc-plugin.m4
+++ b/config/gcc-plugin.m4
@@ -150,6 +150,18 @@ for plugin in $plugin_names; do
break
fi
done
+dnl Check if ${AR} $plugin_option rc works.
+AC_CHECK_TOOL(AR, ar)
+if test "${AR}" = "" ; then
+ AC_MSG_ERROR([Required archive tool 'ar' not found on PATH.])
+fi
+touch conftest.c
+${AR} $plugin_option rc conftest.a conftest.c
+if test "$?" != 0; then
+ AC_MSG_WARN([Failed: $AR $plugin_option rc])
+ plugin_option=
+fi
+rm -f conftest.*
if test -n "$plugin_option"; then
$1="$plugin_option"
AC_MSG_RESULT($plugin_option)
diff --git a/configure b/configure
index 4aa1ca21a38..3fe4a1804cf 100755
--- a/configure
+++ b/configure
@@ -12966,6 +12966,109 @@ for plugin in $plugin_names; do
break
fi
done
+if test -n "$ac_tool_prefix"; then
+ # Extract the first word of "${ac_tool_prefix}ar", so it can be a program
name with args.
+set dummy ${ac_tool_prefix}ar; ac_word=$2
+{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
+$as_echo_n "checking for $ac_word... " >&6; }
+if ${ac_cv_prog_AR+:} false; then :
+ $as_echo_n "(cached) " >&6
+else
+ if test -n "$AR"; then
+ ac_cv_prog_AR="$AR" # Let the user override the test.
+else
+as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
+for as_dir in $PATH
+do
+ IFS=$as_save_IFS
+ test -z "$as_dir" && as_dir=.
+for ac_exec_ext in '' $ac_executable_extensions; do
+ if as_fn_executable_p "$as_dir/$ac_word$ac_exec_ext"; then
+ac_cv_prog_AR="${ac_tool_prefix}ar"
+$as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext"
>&5
+break 2
+ fi
+done
+ done
+IFS=$as_save_IFS
+
+fi
+fi
+AR=$ac_cv_prog_AR
+if test -n "$AR"; then
+ { $as_echo "$as_me:${as_lineno-$LINENO}: result: $AR" >&5
+$as_echo "$AR" >&6; }
+else
+ { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
+$
[PATCH 12/24] Pass PKG_CONFIG_PATH down from top-level Makefile
From: Simon Marchi
[Sending to binutils, gdb-patches and gcc-patches, since it touches the
top-level Makefile/configure]
I have my debuginfod library installed in a non-standard location
(/opt/debuginfod), which requires me to set
PKG_CONFIG_PATH=/opt/debuginfod/lib/pkg-config. If I just set it during
configure:
$ PKG_CONFIG_PATH=/opt/debuginfod/lib/pkg-config ./configure
--with-debuginfod
$ make
or
$ ./configure --with-debuginfod
PKG_CONFIG_PATH=/opt/debuginfod/lib/pkg-config
$ make
Then PKG_CONFIG_PATH is only present (and ignored) during the top-level
configure. When running make (which runs gdb's and binutils'
configure), PKG_CONFIG_PATH is not set, which results in their configure
script not finding the library:
checking for libdebuginfod >= 0.179... no
configure: error: "--with-debuginfod was given, but libdebuginfod is
missing or unusable."
Change the top-level configure/Makefile system to capture the value
passed when configuring the top-level and pass it down to
subdirectories (similar to CFLAGS, LDFLAGS, etc).
I don't know much about the top-level build system, so I really don't
know if I did this correctly. The changes are:
- Use AC_SUBST(PKG_CONFIG_PATH) in configure.ac, so that
@PKG_CONFIG_PATH@ gets replaced with the actual PKG_CONFIG_PATH value
in config files (i.e. Makefile)
- Add a PKG_CONFIG_PATH Makefile variable in Makefile.tpl, initialized
to @PKG_CONFIG_PATH@
- Add PKG_CONFIG_PATH to HOST_EXPORTS in Makefile.tpl, which are the
variables set when running the sub-configures
I initially added PKG_CONFIG_PATH to flags_to_pass, in Makefile.def, but
I don't think it's needed. AFAIU, this defines the flags to pass down
when calling "make" in subdirectories. We only need PKG_CONFIG_PATH to
be passed down during configure. After that, it's captured in
gdb/config.status, so even if a "make" causes a re-configure later
(because gdb/configure has changed, for example), the PKG_CONFIG_PATH
value will be remembered.
Change-Id: I91138dfca41c43b05e53e445f62e4b27882536bf
ChangeLog:
* configure.ac: Add AC_SUBST(PKG_CONFIG_PATH).
* configure: Re-generate.
* Makefile.tpl (HOST_EXPORTS): Pass PKG_CONFIG_PATH.
(PKG_CONFIG_PATH): New.
* Makefile.in: Re-generate.
---
Makefile.in | 3 +++
Makefile.tpl | 3 +++
configure| 2 ++
configure.ac | 1 +
4 files changed, 9 insertions(+)
diff --git a/Makefile.in b/Makefile.in
index f177ce176fb..214a2a15544 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -221,6 +221,7 @@ HOST_EXPORTS = \
OBJCOPY="$(OBJCOPY)"; export OBJCOPY; \
OBJDUMP="$(OBJDUMP)"; export OBJDUMP; \
OTOOL="$(OTOOL)"; export OTOOL; \
+ PKG_CONFIG_PATH="$(PKG_CONFIG_PATH)"; export PKG_CONFIG_PATH; \
READELF="$(READELF)"; export READELF; \
AR_FOR_TARGET="$(AR_FOR_TARGET)"; export AR_FOR_TARGET; \
AS_FOR_TARGET="$(AS_FOR_TARGET)"; export AS_FOR_TARGET; \
@@ -447,6 +448,8 @@ GOCFLAGS = $(CFLAGS)
GDCFLAGS = @GDCFLAGS@
GM2FLAGS = $(CFLAGS)
+PKG_CONFIG_PATH = @PKG_CONFIG_PATH@
+
# Pass additional PGO and LTO compiler options to the PGO build.
BUILD_CFLAGS = $(PGO_BUILD_CFLAGS) $(PGO_BUILD_LTO_CFLAGS)
override CFLAGS += $(BUILD_CFLAGS)
diff --git a/Makefile.tpl b/Makefile.tpl
index 6586e907964..36fa20950d4 100644
--- a/Makefile.tpl
+++ b/Makefile.tpl
@@ -224,6 +224,7 @@ HOST_EXPORTS = \
OBJCOPY="$(OBJCOPY)"; export OBJCOPY; \
OBJDUMP="$(OBJDUMP)"; export OBJDUMP; \
OTOOL="$(OTOOL)"; export OTOOL; \
+ PKG_CONFIG_PATH="$(PKG_CONFIG_PATH)"; export PKG_CONFIG_PATH; \
READELF="$(READELF)"; export READELF; \
AR_FOR_TARGET="$(AR_FOR_TARGET)"; export AR_FOR_TARGET; \
AS_FOR_TARGET="$(AS_FOR_TARGET)"; export AS_FOR_TARGET; \
@@ -450,6 +451,8 @@ GOCFLAGS = $(CFLAGS)
GDCFLAGS = @GDCFLAGS@
GM2FLAGS = $(CFLAGS)
+PKG_CONFIG_PATH = @PKG_CONFIG_PATH@
+
# Pass additional PGO and LTO compiler options to the PGO build.
BUILD_CFLAGS = $(PGO_BUILD_CFLAGS) $(PGO_BUILD_LTO_CFLAGS)
override CFLAGS += $(BUILD_CFLAGS)
diff --git a/configure b/configure
index faa1aedaa04..b6b7487f834 100755
--- a/configure
+++ b/configure
@@ -622,6 +622,7 @@ CXX_FOR_TARGET
CC_FOR_TARGET
RANLIB_PLUGIN_OPTION
AR_PLUGIN_OPTION
+PKG_CONFIG_PATH
GDCFLAGS
READELF
OTOOL
@@ -13017,6 +13018,7 @@ fi
GDCFLAGS=${GDCFLAGS-${CFLAGS}}
+
{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for -plugin option" >&5
$as_echo_n "checking for -plugin option... " >&6; }
diff --git a/configure.ac b/configure.ac
index a0dff0ecac8..39e5649f360 100644
--- a/configure.ac
+++ b/configure.ac
@@ -3708,6 +3708,7 @@ AC_SUBST(CXXFLAGS)
AC_SUBST(GDC)
AC_SUBST(GDCFLAGS)
GDCFLAGS=${GDCFLAGS-${CFLAGS}}
+AC_SUBST(PKG_CONFIG_PATH)
GCC_PLUGIN_OPTION(PLUGIN_OPTION)
AR_PLUGIN_OPTION=
--
2.41.0
[PATCH 18/24] PR27116, Spelling errors found by Debian style checker
From: Alan Modra config/ChangeLog: * override.m4: Correct comment grammar. --- config/override.m4 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/config/override.m4 b/config/override.m4 index d3e815bb1b4..5a1bffe6018 100644 --- a/config/override.m4 +++ b/config/override.m4 @@ -32,7 +32,7 @@ m4_ifndef([_GCC_AUTOCONF_VERSION], [m4_define([_GCC_AUTOCONF_VERSION], [2.69])]) dnl Test for the exact version when AC_INIT is expanded. -dnl This allows to update the tree in steps (for testing) +dnl This allows one to update the tree in steps (for testing) dnl by putting dnl m4_define([_GCC_AUTOCONF_VERSION], [X.Y]) dnl in configure.ac before AC_INIT, -- 2.41.0
[PATCH 04/24] Sync with binutils: GCC: Pass --plugin to AR and RANLIB
From: "H.J. Lu" Sync with binutils for building binutils with LTO: 50ad1254d50 GCC: Pass --plugin to AR and RANLIB Detect GCC LTO plugin. Pass --plugin to AR and RANLIB to support LTO build. ChangeLog: * Makefile.tpl (AR): Add @AR_PLUGIN_OPTION@ (RANLIB): Add @RANLIB_PLUGIN_OPTION@. * configure.ac: Include config/gcc-plugin.m4. AC_SUBST AR_PLUGIN_OPTION and RANLIB_PLUGIN_OPTION. * libtool.m4 (_LT_CMD_OLD_ARCHIVE): Pass --plugin to AR and RANLIB if possible. * Makefile.in: Regenerated. * configure: Likewise. config/ChangeLog: * gcc-plugin.m4 (GCC_PLUGIN_OPTION): New. libiberty/ChangeLog: * Makefile.in (AR): Add @AR_PLUGIN_OPTION@ (RANLIB): Add @RANLIB_PLUGIN_OPTION@. (configure_deps): Depend on ../config/gcc-plugin.m4. * configure.ac: AC_SUBST AR_PLUGIN_OPTION and RANLIB_PLUGIN_OPTION. * aclocal.m4: Regenerated. * configure: Likewise. zlib/ChangeLog: * configure: Regenerated. gcc/ChangeLog: * configure: Regenerate. libatomic/ChangeLog: * configure: Regenerate. libbacktrace/ChangeLog: * configure: Regenerate. libcc1/ChangeLog: * configure: Regenerate. libffi/ChangeLog: * configure: Regenerate. libgfortran/ChangeLog: * configure: Regenerate. libgm2/ChangeLog: * configure: Regenerate. libgomp/ChangeLog: * configure: Regenerate. libitm/ChangeLog: * configure: Regenerate. libobjc/ChangeLog: * configure: Regenerate. libphobos/ChangeLog: * configure: Regenerate. libquadmath/ChangeLog: * configure: Regenerate. libsanitizer/ChangeLog: * configure: Regenerate. libssp/ChangeLog: * configure: Regenerate. libstdc++-v3/ChangeLog: * configure: Regenerate. libvtv/ChangeLog: * configure: Regenerate. lto-plugin/ChangeLog: * configure: Regenerate. --- Makefile.in| 5 +++-- Makefile.tpl | 5 +++-- config/gcc-plugin.m4 | 28 configure | 39 +++ configure.ac | 15 +++ gcc/configure | 27 +-- libatomic/configure| 27 +-- libbacktrace/configure | 27 +-- libcc1/configure | 27 +-- libffi/configure | 27 +-- libgfortran/configure | 27 +-- libgm2/configure | 27 +-- libgomp/configure | 27 +-- libiberty/Makefile.in | 5 +++-- libiberty/aclocal.m4 | 1 + libiberty/configure| 37 + libiberty/configure.ac | 12 libitm/configure | 27 +-- libobjc/configure | 27 +-- libphobos/configure| 27 +-- libquadmath/configure | 27 +-- libsanitizer/configure | 27 +-- libssp/configure | 27 +-- libstdc++-v3/configure | 39 +++ libtool.m4 | 25 - libvtv/configure | 27 +-- lto-plugin/configure | 27 +-- zlib/configure | 27 +-- 28 files changed, 621 insertions(+), 49 deletions(-) diff --git a/Makefile.in b/Makefile.in index 144bccd2603..6539fb201dc 100644 --- a/Makefile.in +++ b/Makefile.in @@ -417,7 +417,7 @@ MAKEINFOFLAGS = --split-size=500 # - AS = @AS@ -AR = @AR@ +AR = @AR@ @AR_PLUGIN_OPTION@ AR_FLAGS = rc CC = @CC@ CXX = @CXX@ @@ -428,7 +428,7 @@ LIPO = @LIPO@ NM = @NM@ OBJDUMP = @OBJDUMP@ OTOOL = @OTOOL@ -RANLIB = @RANLIB@ +RANLIB = @RANLIB@ @RANLIB_PLUGIN_OPTION@ READELF = @READELF@ STRIP = @STRIP@ WINDRES = @WINDRES@ @@ -66748,6 +66748,7 @@ AUTOCONF = autoconf $(srcdir)/configure: @MAINT@ $(srcdir)/configure.ac $(srcdir)/config/acx.m4 \ $(srcdir)/config/override.m4 $(srcdir)/config/proginstall.m4 \ $(srcdir)/config/elf.m4 $(srcdir)/config/isl.m4 \ + $(srcdir)/config/gcc-plugin.m4 \ $(srcdir)/libtool.m4 $(srcdir)/ltoptions.m4 $(srcdir)/ltsugar.m4 \ $(srcdir)/ltversion.m4 $(srcdir)/lt~obsolete.m4 cd $(srcdir) && $(AUTOCONF) diff --git a/Makefile.tpl b/Makefile.tpl index 4fdca604eb0..6586e907964 100644 --- a/Makefile.tpl +++ b/Makefile.tpl @@ -420,7 +420,7 @@ MAKEINFOFLAGS = --split-size=500 # - AS = @AS@ -AR = @AR@ +AR = @AR@ @AR_PLUGIN_OPTION@ AR_FLAGS = rc CC = @CC@ CXX = @CXX@ @@ -431,7 +431,7 @@ LIPO = @LIPO@ NM = @NM@ OBJDUMP = @OBJDUMP@ OTOOL = @OTOOL@ -RANLIB = @RANLIB@ +RANLIB = @RANLIB@ @RANLIB_PLUGIN_OPTION@ READELF = @READELF@
[PATCH 21/24] PKG_CHECK_MODULES: Properly check if $pkg_cv_[]$1[]_LIBS works
From: "H.J. Lu" There is no need to check $pkg_cv_[]$1[]_LIBS works if package check failed. config/ChangeLog: * pkg.m4 (PKG_CHECK_MODULES): Use AC_TRY_LINK only if $pkg_failed = no. --- config/pkg.m4 | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/config/pkg.m4 b/config/pkg.m4 index 45587e97c8b..7ebf517cd6a 100644 --- a/config/pkg.m4 +++ b/config/pkg.m4 @@ -148,10 +148,12 @@ _PKG_CONFIG([$1][_CFLAGS], [cflags], [$2]) _PKG_CONFIG([$1][_LIBS], [libs], [$2]) dnl Check whether $pkg_cv_[]$1[]_LIBS works. -pkg_save_LDFLAGS="$LDFLAGS" -LDFLAGS="$LDFLAGS $pkg_cv_[]$1[]_LIBS" -AC_TRY_LINK([],[return 0;], [pkg_failed=no], [pkg_failed=yes]) -LDFLAGS=$pkg_save_LDFLAGS +if test $pkg_failed = no; then + pkg_save_LDFLAGS="$LDFLAGS" + LDFLAGS="$LDFLAGS $pkg_cv_[]$1[]_LIBS" + AC_TRY_LINK([],[], [], [pkg_failed=yes]) + LDFLAGS=$pkg_save_LDFLAGS +fi m4_define([_PKG_TEXT], [Alternatively, you may set the environment variables $1[]_CFLAGS and $1[]_LIBS to avoid the need to call pkg-config. -- 2.41.0
[PATCH 20/24] PKG_CHECK_MODULES: Check if $pkg_cv_[]$1[]_LIBS works
From: "H.J. Lu" It is quite normal to have headers without library on multilib OSes. Add AC_TRY_LINK to PKG_CHECK_MODULES to check if $pkg_cv_[]$1[]_LIBS works. config/ChangeLog: * pkg.m4 (PKG_CHECK_MODULES): Add AC_TRY_LINK to check if $pkg_cv_[]$1[]_LIBS works. --- config/pkg.m4 | 6 ++ 1 file changed, 6 insertions(+) diff --git a/config/pkg.m4 b/config/pkg.m4 index 13a88901786..45587e97c8b 100644 --- a/config/pkg.m4 +++ b/config/pkg.m4 @@ -147,6 +147,12 @@ AC_MSG_CHECKING([for $2]) _PKG_CONFIG([$1][_CFLAGS], [cflags], [$2]) _PKG_CONFIG([$1][_LIBS], [libs], [$2]) +dnl Check whether $pkg_cv_[]$1[]_LIBS works. +pkg_save_LDFLAGS="$LDFLAGS" +LDFLAGS="$LDFLAGS $pkg_cv_[]$1[]_LIBS" +AC_TRY_LINK([],[return 0;], [pkg_failed=no], [pkg_failed=yes]) +LDFLAGS=$pkg_save_LDFLAGS + m4_define([_PKG_TEXT], [Alternatively, you may set the environment variables $1[]_CFLAGS and $1[]_LIBS to avoid the need to call pkg-config. See the pkg-config man page for more details.]) -- 2.41.0
[PATCH 17/24] egrep in binutils
From: Alan Modra
Apparently some distros have a nagging egrep that helpfully tells you
egrep is deprecated and to use "grep -E". The nag message causes a ld
testsuite failure. What's more the advice isn't that good. The "-E"
flag may not be available with older versions of grep.
This patch fixes bare invocation of egrep within binutils, replacing
it with the autoconf $EGREP or with grep.
config/ChangeLog:
* lib-ld.m4 (AC_LIB_PROG_LD_GNU): Require AC_PROG_EGREP and
invoke $EGREP.
(AC_LIB_PROG_LD): Likewise.
gcc/ChangeLog:
* configure: Regenerate.
intl/ChangeLog:
* configure: Regenerate.
libcpp/ChangeLog:
* configure: Regenerate.
libgcc/ChangeLog:
* configure: Regenerate.
libstdc++-v3/ChangeLog:
* configure: Regenerate.
---
config/lib-ld.m4 | 8 +---
gcc/configure | 4 ++--
intl/configure | 4 ++--
libcpp/configure | 4 ++--
libgcc/configure | 2 +-
libstdc++-v3/configure | 4 ++--
6 files changed, 14 insertions(+), 12 deletions(-)
diff --git a/config/lib-ld.m4 b/config/lib-ld.m4
index 11d0ce77342..73cf9571b57 100644
--- a/config/lib-ld.m4
+++ b/config/lib-ld.m4
@@ -12,9 +12,10 @@ dnl with libtool.m4.
dnl From libtool-1.4. Sets the variable with_gnu_ld to yes or no.
AC_DEFUN([AC_LIB_PROG_LD_GNU],
-[AC_CACHE_CHECK([if the linker ($LD) is GNU ld], acl_cv_prog_gnu_ld,
+[AC_REQUIRE([AC_PROG_EGREP])dnl
+AC_CACHE_CHECK([if the linker ($LD) is GNU ld], acl_cv_prog_gnu_ld,
[# I'd rather use --version here, but apparently some GNU ld's only accept -v.
-if $LD -v 2>&1 &5; then
+if $LD -v 2>&1 &5; then
acl_cv_prog_gnu_ld=yes
else
acl_cv_prog_gnu_ld=no
@@ -29,6 +30,7 @@ AC_DEFUN([AC_LIB_PROG_LD],
test "$withval" = no || with_gnu_ld=yes, with_gnu_ld=no)
AC_REQUIRE([AC_PROG_CC])dnl
AC_REQUIRE([AC_CANONICAL_HOST])dnl
+AC_REQUIRE([AC_PROG_EGREP])dnl
# Prepare PATH_SEPARATOR.
# The user is always right.
if test "${PATH_SEPARATOR+set}" != set; then
@@ -88,7 +90,7 @@ AC_CACHE_VAL(acl_cv_path_LD,
# Check to see if the program is GNU ld. I'd rather use --version,
# but apparently some GNU ld's only accept -v.
# Break only if it was the GNU/non-GNU ld that we prefer.
- if "$acl_cv_path_LD" -v 2>&1 < /dev/null | egrep '(GNU|with BFD)' >
/dev/null; then
+ if "$acl_cv_path_LD" -v 2>&1 < /dev/null | $EGREP '(GNU|with BFD)' >
/dev/null; then
test "$with_gnu_ld" != no && break
else
test "$with_gnu_ld" != yes && break
diff --git a/gcc/configure b/gcc/configure
index e97433d8743..cd9919e858d 100755
--- a/gcc/configure
+++ b/gcc/configure
@@ -11299,7 +11299,7 @@ else
# Check to see if the program is GNU ld. I'd rather use --version,
# but apparently some GNU ld's only accept -v.
# Break only if it was the GNU/non-GNU ld that we prefer.
- if "$acl_cv_path_LD" -v 2>&1 < /dev/null | egrep '(GNU|with BFD)' >
/dev/null; then
+ if "$acl_cv_path_LD" -v 2>&1 < /dev/null | $EGREP '(GNU|with BFD)' >
/dev/null; then
test "$with_gnu_ld" != no && break
else
test "$with_gnu_ld" != yes && break
@@ -11327,7 +11327,7 @@ if ${acl_cv_prog_gnu_ld+:} false; then :
$as_echo_n "(cached) " >&6
else
# I'd rather use --version here, but apparently some GNU ld's only accept -v.
-if $LD -v 2>&1 &5; then
+if $LD -v 2>&1 &5; then
acl_cv_prog_gnu_ld=yes
else
acl_cv_prog_gnu_ld=no
diff --git a/intl/configure b/intl/configure
index 79bb5831a47..42b2a26b5bf 100755
--- a/intl/configure
+++ b/intl/configure
@@ -5094,7 +5094,7 @@ else
# Check to see if the program is GNU ld. I'd rather use --version,
# but apparently some GNU ld's only accept -v.
# Break only if it was the GNU/non-GNU ld that we prefer.
- if "$acl_cv_path_LD" -v 2>&1 < /dev/null | egrep '(GNU|with BFD)' >
/dev/null; then
+ if "$acl_cv_path_LD" -v 2>&1 < /dev/null | $EGREP '(GNU|with BFD)' >
/dev/null; then
test "$with_gnu_ld" != no && break
else
test "$with_gnu_ld" != yes && break
@@ -5122,7 +5122,7 @@ if ${acl_cv_prog_gnu_ld+:} false; then :
$as_echo_n "(cached) " >&6
else
# I'd rather use --version here, but apparently some GNU ld's only accept -v.
-if $LD -v 2>&1 &5; then
+if $LD -v 2>&1 &5; then
acl_cv_prog_gnu_ld=yes
else
acl_cv_prog_gnu_ld=no
diff --git a/libcpp/configure b/libcpp/configure
index 1389ddab544..ed98f40a1c1 100755
--- a/libcpp/configure
+++ b/libcpp/configure
@@ -6811,7 +6811,7 @@ else
# Check to see if the program is GNU ld. I'd rather use --version,
# but apparently some GNU ld's only accept -v.
# Break only if it was the GNU/non-GNU ld that we prefer.
- if "$acl_cv_path_LD" -v 2>&1 < /dev/null | egrep '(GNU|with BFD)' >
/dev/null; then
+ if "$acl_cv_path_LD" -v 2>&1 < /dev/null | $EGREP '(GNU|with BFD)' >
/dev/null; then
test "$with_gnu_ld" != no && break
else
test "$with_gnu_ld" != yes && break
[PATCH 10/24] gprofng: a new GNU profiler
From: Vladimir Mezentsev
ChangeLog:
* Makefile.def: Add gprofng module.
* configure.ac: Add --enable-gprofng option.
* Makefile.in: Regenerate.
* configure: Regenerate.
include/ChangeLog:
* collectorAPI.h: New file.
* libcollector.h: New file.
* libfcollector.h: New file.
---
Makefile.def| 11 +
Makefile.in | 497
configure | 18 ++
configure.ac| 14 ++
include/collectorAPI.h | 73 ++
include/libcollector.h | 89 +++
include/libfcollector.h | 42
7 files changed, 744 insertions(+)
create mode 100644 include/collectorAPI.h
create mode 100644 include/libcollector.h
create mode 100644 include/libfcollector.h
diff --git a/Makefile.def b/Makefile.def
index 9b4a8a2bf7a..86d25f43762 100644
--- a/Makefile.def
+++ b/Makefile.def
@@ -73,6 +73,7 @@ host_modules= { module= isl; lib_path=.libs; bootstrap=true;
no_install= true; };
host_modules= { module= gold; bootstrap=true; };
host_modules= { module= gprof; };
+host_modules= { module= gprofng; };
// intl acts on 'host_shared' directly, and does not support --with-pic.
host_modules= { module= intl; bootstrap=true; };
host_modules= { module= tcl;
@@ -511,6 +512,16 @@ dependencies = { module=all-gprof; on=all-bfd; };
dependencies = { module=all-gprof; on=all-opcodes; };
dependencies = { module=all-gprof; on=all-intl; };
dependencies = { module=all-gprof; on=all-gas; };
+
+dependencies = { module=configure-gprofng; on=configure-intl; };
+dependencies = { module=all-gprofng; on=all-libiberty; };
+dependencies = { module=all-gprofng; on=all-bfd; };
+dependencies = { module=all-gprofng; on=all-opcodes; };
+dependencies = { module=all-gprofng; on=all-intl; };
+dependencies = { module=all-gprofng; on=all-gas; };
+dependencies = { module=install-gprofng; on=install-opcodes; };
+dependencies = { module=install-gprofng; on=install-bfd; };
+
dependencies = { module=configure-ld; on=configure-intl; };
dependencies = { module=all-ld; on=all-libiberty; };
dependencies = { module=all-ld; on=all-bfd; };
diff --git a/Makefile.in b/Makefile.in
index 6539fb201dc..f177ce176fb 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -1089,6 +1089,7 @@ configure-host: \
maybe-configure-isl \
maybe-configure-gold \
maybe-configure-gprof \
+maybe-configure-gprofng \
maybe-configure-intl \
maybe-configure-tcl \
maybe-configure-itcl \
@@ -1242,6 +1243,7 @@ all-host: maybe-all-isl
all-host: maybe-all-gold
@endif gold-no-bootstrap
all-host: maybe-all-gprof
+all-host: maybe-all-gprofng
@if intl-no-bootstrap
all-host: maybe-all-intl
@endif intl-no-bootstrap
@@ -1381,6 +1383,7 @@ info-host: maybe-info-mpc
info-host: maybe-info-isl
info-host: maybe-info-gold
info-host: maybe-info-gprof
+info-host: maybe-info-gprofng
info-host: maybe-info-intl
info-host: maybe-info-tcl
info-host: maybe-info-itcl
@@ -1471,6 +1474,7 @@ dvi-host: maybe-dvi-mpc
dvi-host: maybe-dvi-isl
dvi-host: maybe-dvi-gold
dvi-host: maybe-dvi-gprof
+dvi-host: maybe-dvi-gprofng
dvi-host: maybe-dvi-intl
dvi-host: maybe-dvi-tcl
dvi-host: maybe-dvi-itcl
@@ -1561,6 +1565,7 @@ pdf-host: maybe-pdf-mpc
pdf-host: maybe-pdf-isl
pdf-host: maybe-pdf-gold
pdf-host: maybe-pdf-gprof
+pdf-host: maybe-pdf-gprofng
pdf-host: maybe-pdf-intl
pdf-host: maybe-pdf-tcl
pdf-host: maybe-pdf-itcl
@@ -1651,6 +1656,7 @@ html-host: maybe-html-mpc
html-host: maybe-html-isl
html-host: maybe-html-gold
html-host: maybe-html-gprof
+html-host: maybe-html-gprofng
html-host: maybe-html-intl
html-host: maybe-html-tcl
html-host: maybe-html-itcl
@@ -1741,6 +1747,7 @@ TAGS-host: maybe-TAGS-mpc
TAGS-host: maybe-TAGS-isl
TAGS-host: maybe-TAGS-gold
TAGS-host: maybe-TAGS-gprof
+TAGS-host: maybe-TAGS-gprofng
TAGS-host: maybe-TAGS-intl
TAGS-host: maybe-TAGS-tcl
TAGS-host: maybe-TAGS-itcl
@@ -1831,6 +1838,7 @@ install-info-host: maybe-install-info-mpc
install-info-host: maybe-install-info-isl
install-info-host: maybe-install-info-gold
install-info-host: maybe-install-info-gprof
+install-info-host: maybe-install-info-gprofng
install-info-host: maybe-install-info-intl
install-info-host: maybe-install-info-tcl
install-info-host: maybe-install-info-itcl
@@ -1921,6 +1929,7 @@ install-dvi-host: maybe-install-dvi-mpc
install-dvi-host: maybe-install-dvi-isl
install-dvi-host: maybe-install-dvi-gold
install-dvi-host: maybe-install-dvi-gprof
+install-dvi-host: maybe-install-dvi-gprofng
install-dvi-host: maybe-install-dvi-intl
install-dvi-host: maybe-install-dvi-tcl
install-dvi-host: maybe-install-dvi-itcl
@@ -2011,6 +2020,7 @@ install-pdf-host: maybe-install-pdf-mpc
install-pdf-host: maybe-install-pdf-isl
install-pdf-host: maybe-install-pdf-gold
install-pdf-host: maybe-install-pdf-gprof
+install-pdf-host: maybe-install-pdf-gprofng
install-pdf-host: maybe-install-pdf-intl
install-pdf-host: maybe-install-pdf-tcl
install
[PATCH 15/24] libtool.m4: fix the NM="/nm/over/here -B/option/with/path" case
From: Nick Alcock My previous nm patch handled all cases but one -- if the user set NM in the environment to a path which contained an option, libtool's nm detection tries to run nm against a copy of nm with the options in it: e.g. if NM was set to "nm --blargle", and nm was found in /usr/bin, the test would try to run "/usr/bin/nm --blargle /usr/bin/nm --blargle". This is unlikely to be desirable: in this case we should run "/usr/bin/nm --blargle /usr/bin/nm". Furthermore, as part of this nm has to detect when the passed-in $NM contains a path, and in that case avoid doing a path search itself. This too was thrown off if an option contained something that looked like a path, e.g. NM="nm -B../prev-gcc"; libtool then tries to run "nm -B../prev-gcc nm" which rarely works well (and indeed it looks to see whether that nm exists, finds it doesn't, and wrongly concludes that nm -p or whatever does not work). Fix all of these by clipping all options (defined as everything including and after the first " -") before deciding whether nm contains a path (but not using the clipped value for anything else), and then removing all options from the path-modified nm before looking to see whether that nm existed. NM=my-nm now does a path search and runs e.g. /usr/bin/my-nm -B /usr/bin/my-nm NM=/usr/bin/my-nm now avoids a path search and runs e.g. /usr/bin/my-nm -B /usr/bin/my-nm NM="my-nm -p../wombat" now does a path search and runs e.g. /usr/bin/my-nm -p../wombat -B /usr/bin/my-nm NM="../prev-binutils/new-nm -B../prev-gcc" now avoids a path search: ../prev-binutils/my-nm -B../prev-gcc -B ../prev-binutils/my-nm This seems to be all combinations, including those used by GCC bootstrap (which, before this commit, fails to bootstrap when configured --with-build-config=bootstrap-lto, because the lto plugin is now using --export-symbols-regex, which requires libtool to find a working nm, while also using -B../prev-gcc to point at the lto plugin associated with the GCC just built.) Regenerate all affected configure scripts. ChangeLog: * libtool.m4 (LT_PATH_NM): Handle user-specified NM with options, including options containing paths. gcc/ChangeLog: * configure: Regenerate. libatomic/ChangeLog: * configure: Regenerate. libbacktrace/ChangeLog: * configure: Regenerate. libcc1/ChangeLog: * configure: Regenerate. libffi/ChangeLog: * configure: Regenerate. libgfortran/ChangeLog: * configure: Regenerate. libgm2/ChangeLog: * configure: Regenerate. libgomp/ChangeLog: * configure: Regenerate. libitm/ChangeLog: * configure: Regenerate. libobjc/ChangeLog: * configure: Regenerate. libphobos/ChangeLog: * configure: Regenerate. libquadmath/ChangeLog: * configure: Regenerate. libsanitizer/ChangeLog: * configure: Regenerate. libssp/ChangeLog: * configure: Regenerate. libstdc++-v3/ChangeLog: * configure: Regenerate. libvtv/ChangeLog: * configure: Regenerate. lto-plugin/ChangeLog: * configure: Regenerate. zlib/ChangeLog: * configure: Regenerate. --- gcc/configure | 20 +--- libatomic/configure| 20 +--- libbacktrace/configure | 20 +--- libcc1/configure | 20 +--- libffi/configure | 20 +--- libgfortran/configure | 20 +--- libgm2/configure | 20 +--- libgomp/configure | 20 +--- libitm/configure | 20 +--- libobjc/configure | 20 +--- libphobos/configure| 20 +--- libquadmath/configure | 20 +--- libsanitizer/configure | 20 +--- libssp/configure | 20 +--- libstdc++-v3/configure | 32 +++- libtool.m4 | 16 +++- libvtv/configure | 20 +--- lto-plugin/configure | 20 +--- zlib/configure | 20 +--- 19 files changed, 251 insertions(+), 137 deletions(-) diff --git a/gcc/configure b/gcc/configure index 81b93c1b599..c58a99f5d40 100755 --- a/gcc/configure +++ b/gcc/configure @@ -14144,25 +14144,31 @@ else lt_nm_to_check="$lt_nm_to_check nm" fi fi - for lt_tmp_nm in $lt_nm_to_check; do + for lt_tmp_nm in "$lt_nm_to_check"; do lt_save_ifs="$IFS"; IFS=$PATH_SEPARATOR for ac_dir in $PATH /usr/ccs/bin/elf /usr/ccs/bin /usr/ucb /bin; do IFS="$lt_save_ifs" test -z "$ac_dir" && ac_dir=. - case "$lt_tmp_nm" in + # Strip out any user-provided options from the nm to test twice, + # the first time to test to see if nm (rather than its options) has + # an explicit path, the second time to yield a file which can be + # nm'ed itself. + tmp_nm_path="`$ECHO "$lt_tmp_nm" | sed 's, -.*$,,'`" + case "$tmp_nm_p
[PATCH 13/24] configure: reinstate 32b PA-RISC HP-UX target in toplevel
The Binutils still support this target.
ChangeLog:
* configure.ac: Reinstate 32b PA-RISC HP-UX targets
* configure: Regenerate.
---
configure| 10 ++
configure.ac | 10 ++
2 files changed, 20 insertions(+)
diff --git a/configure b/configure
index b6b7487f834..907ebe71777 100755
--- a/configure
+++ b/configure
@@ -3572,6 +3572,11 @@ case "${target}" in
hppa*64*-*-hpux*)
noconfigdirs="$noconfigdirs target-libffi"
;;
+ hppa*-hp-hpux11*)
+;;
+ hppa*-*-hpux*)
+noconfigdirs="$noconfigdirs target-libffi"
+;;
ia64*-*-*vms*)
noconfigdirs="$noconfigdirs target-libffi"
;;
@@ -3878,9 +3883,14 @@ case "${target}" in
h8500-*-*)
noconfigdirs="$noconfigdirs target-libgloss"
;;
+ hppa1.1-*-osf* | hppa1.1-*-bsd* )
+;;
hppa*64*-*-hpux*)
noconfigdirs="$noconfigdirs gdb"
;;
+ hppa*-*-hpux11*)
+noconfigdirs="$noconfigdirs gdb ld"
+;;
hppa*64*-*-linux*)
;;
hppa*-*-linux*)
diff --git a/configure.ac b/configure.ac
index 39e5649f360..6a2e585a39a 100644
--- a/configure.ac
+++ b/configure.ac
@@ -802,6 +802,11 @@ case "${target}" in
hppa*64*-*-hpux*)
noconfigdirs="$noconfigdirs target-libffi"
;;
+ hppa*-hp-hpux11*)
+;;
+ hppa*-*-hpux*)
+noconfigdirs="$noconfigdirs target-libffi"
+;;
ia64*-*-*vms*)
noconfigdirs="$noconfigdirs target-libffi"
;;
@@ -1105,9 +1110,14 @@ case "${target}" in
h8500-*-*)
noconfigdirs="$noconfigdirs target-libgloss"
;;
+ hppa1.1-*-osf* | hppa1.1-*-bsd* )
+;;
hppa*64*-*-hpux*)
noconfigdirs="$noconfigdirs gdb"
;;
+ hppa*-*-hpux11*)
+noconfigdirs="$noconfigdirs gdb ld"
+;;
hppa*64*-*-linux*)
;;
hppa*-*-linux*)
--
2.41.0
[PATCH 16/24] Add support for the haiku operating system
From: Alexander von Gluck IV
These are the os support patches we have been grooming and maintaining
for quite a few years over on git.haiku-os.org. All of these
architectures are working and most have been stable for quite some time.
ChangeLog:
* configure: Regenerate.
* configure.ac: Add Haiku to list of ELF OSes
* libtool.m4: Update sys_lib_dlsearch_path_spec on Haiku.
gcc/ChangeLog:
* configure: Regenerate.
libatomic/ChangeLog:
* configure: Regenerate.
libbacktrace/ChangeLog:
* configure: Regenerate.
libcc1/ChangeLog:
* configure: Regenerate.
libffi/ChangeLog:
* configure: Regenerate.
libgfortran/ChangeLog:
* configure: Regenerate.
libgm2/ChangeLog:
* configure: Regenerate.
libgomp/ChangeLog:
* configure: Regenerate.
libitm/ChangeLog:
* configure: Regenerate.
libobjc/ChangeLog:
* configure: Regenerate.
libphobos/ChangeLog:
* configure: Regenerate.
libquadmath/ChangeLog:
* configure: Regenerate.
libsanitizer/ChangeLog:
* configure: Regenerate.
libssp/ChangeLog:
* configure: Regenerate.
libstdc++-v3/ChangeLog:
* configure: Regenerate.
libvtv/ChangeLog:
* configure: Regenerate.
lto-plugin/ChangeLog:
* configure: Regenerate.
zlib/ChangeLog:
* configure: Regenerate.
---
configure | 2 +-
configure.ac | 2 +-
gcc/configure | 4 ++--
libatomic/configure| 2 +-
libbacktrace/configure | 2 +-
libcc1/configure | 4 ++--
libffi/configure | 4 ++--
libgfortran/configure | 4 ++--
libgm2/configure | 4 ++--
libgomp/configure | 4 ++--
libitm/configure | 4 ++--
libobjc/configure | 2 +-
libphobos/configure| 2 +-
libquadmath/configure | 2 +-
libsanitizer/configure | 4 ++--
libssp/configure | 2 +-
libstdc++-v3/configure | 4 ++--
libtool.m4 | 2 +-
libvtv/configure | 4 ++--
lto-plugin/configure | 2 +-
zlib/configure | 2 +-
21 files changed, 31 insertions(+), 31 deletions(-)
diff --git a/configure b/configure
index 907ebe71777..28f0913bdd4 100755
--- a/configure
+++ b/configure
@@ -3077,7 +3077,7 @@ case "${ENABLE_GOLD}" in
*-*-elf* | *-*-sysv4* | *-*-unixware* | *-*-eabi* | hppa*64*-*-hpux* \
| *-*-linux* | *-*-gnu* | frv-*-uclinux* | *-*-irix5* | *-*-irix6* \
| *-*-netbsd* | *-*-openbsd* | *-*-freebsd* | *-*-dragonfly* \
- | *-*-solaris2* | *-*-nto* | *-*-nacl*)
+ | *-*-solaris2* | *-*-nto* | *-*-nacl* | *-*-haiku*)
case "${target}" in
*-*-linux*aout* | *-*-linux*oldld*)
;;
diff --git a/configure.ac b/configure.ac
index 6a2e585a39a..5d25dc864c3 100644
--- a/configure.ac
+++ b/configure.ac
@@ -349,7 +349,7 @@ case "${ENABLE_GOLD}" in
*-*-elf* | *-*-sysv4* | *-*-unixware* | *-*-eabi* | hppa*64*-*-hpux* \
| *-*-linux* | *-*-gnu* | frv-*-uclinux* | *-*-irix5* | *-*-irix6* \
| *-*-netbsd* | *-*-openbsd* | *-*-freebsd* | *-*-dragonfly* \
- | *-*-solaris2* | *-*-nto* | *-*-nacl*)
+ | *-*-solaris2* | *-*-nto* | *-*-nacl* | *-*-haiku*)
case "${target}" in
*-*-linux*aout* | *-*-linux*oldld*)
;;
diff --git a/gcc/configure b/gcc/configure
index c58a99f5d40..e97433d8743 100755
--- a/gcc/configure
+++ b/gcc/configure
@@ -19068,7 +19068,7 @@ haiku*)
soname_spec='${libname}${release}${shared_ext}$major'
shlibpath_var=LIBRARY_PATH
shlibpath_overrides_runpath=yes
- sys_lib_dlsearch_path_spec='/boot/home/config/lib /boot/common/lib
/boot/beos/system/lib'
+ sys_lib_dlsearch_path_spec='/boot/home/config/lib /boot/common/lib
/boot/system/lib'
hardcode_into_libs=yes
;;
@@ -22743,7 +22743,7 @@ haiku*)
soname_spec='${libname}${release}${shared_ext}$major'
shlibpath_var=LIBRARY_PATH
shlibpath_overrides_runpath=yes
- sys_lib_dlsearch_path_spec='/boot/home/config/lib /boot/common/lib
/boot/beos/system/lib'
+ sys_lib_dlsearch_path_spec='/boot/home/config/lib /boot/common/lib
/boot/system/lib'
hardcode_into_libs=yes
;;
diff --git a/libatomic/configure b/libatomic/configure
index 648f0dd7e52..75096735c61 100755
--- a/libatomic/configure
+++ b/libatomic/configure
@@ -10582,7 +10582,7 @@ haiku*)
soname_spec='${libname}${release}${shared_ext}$major'
shlibpath_var=LIBRARY_PATH
shlibpath_overrides_runpath=yes
- sys_lib_dlsearch_path_spec='/boot/home/config/lib /boot/common/lib
/boot/beos/system/lib'
+ sys_lib_dlsearch_path_spec='/boot/home/config/lib /boot/common/lib
/boot/system/lib'
hardcode_into_libs=yes
;;
diff --git a/libbacktrace/configure b/libbacktrace/configure
index 73611a3b994..f3ef3fc3f23 100755
--- a/libbacktrace/configure
+++ b/libbacktrace/configure
@@ -10759,7 +10759,7 @@ haiku*)
soname_spec='${libname}${release}${shared_ext}$major'
shlibpath_var=LIBRARY_PATH
shlibpath_overrides_runpath=yes
- sys_lib_dlsearch_path_spe
[PATCH 23/24] bfd: linker: merge .sframe sections
From: Indu Bhagat
The linker merges all the input .sframe sections. When merging, the
linker verifies that all the input .sframe sections have the same
abi/arch.
The linker uses libsframe library to perform key actions on the
.sframe sections - decode, read, and create output data. This
implies buildsystem changes to make and install libsframe before
libbfd.
The linker places the output .sframe section in a new segment of its
own: PT_GNU_SFRAME. A new segment is not added, however, if the
generated .sframe section is empty.
When a section is discarded from the final link, the corresponding
entries in the .sframe section for those functions are also deleted.
The linker sorts the SFrame FDEs on start address by default and sets
the SFRAME_F_FDE_SORTED flag in the .sframe section.
This patch also adds support for generation of SFrame unwind
information for the .plt* sections on x86_64. SFrame unwind info is
generated for IBT enabled PLT, lazy/non-lazy PLT.
The existing linker option --no-ld-generated-unwind-info has been
adapted to include the control of whether .sframe unwind information
will be generated for the linker generated sections like PLT.
Changes to the linker script have been made as necessary.
ChangeLog:
* Makefile.def: Add install dependency on libsframe for libbfd.
* Makefile.in: Regenerated.
---
Makefile.def | 4
Makefile.in | 11 +++
2 files changed, 15 insertions(+)
diff --git a/Makefile.def b/Makefile.def
index 86d25f43762..0c6784b6da1 100644
--- a/Makefile.def
+++ b/Makefile.def
@@ -459,11 +459,14 @@ dependencies = { module=all-gdbsupport; on=all-gnulib; };
dependencies = { module=all-gdbsupport; on=all-intl; };
// Host modules specific to binutils.
+// build libsframe before bfd for encoder/decoder support for linking
+// SFrame sections
dependencies = { module=configure-bfd; on=configure-libiberty; hard=true; };
dependencies = { module=configure-bfd; on=configure-intl; };
dependencies = { module=all-bfd; on=all-libiberty; };
dependencies = { module=all-bfd; on=all-intl; };
dependencies = { module=all-bfd; on=all-zlib; };
+dependencies = { module=all-bfd; on=all-libsframe; };
dependencies = { module=configure-opcodes; on=configure-libiberty; hard=true;
};
dependencies = { module=all-opcodes; on=all-libiberty; };
@@ -489,6 +492,7 @@ dependencies = { module=install-binutils;
on=install-opcodes; };
dependencies = { module=install-strip-binutils; on=install-strip-opcodes; };
// Likewise for ld, libctf, and bfd.
+dependencies = { module=install-bfd; on=install-libsframe; };
dependencies = { module=install-libctf; on=install-bfd; };
dependencies = { module=install-ld; on=install-bfd; };
dependencies = { module=install-ld; on=install-libctf; };
diff --git a/Makefile.in b/Makefile.in
index 214a2a15544..35a5d8c575d 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -66354,6 +66354,16 @@ all-stagetrain-bfd: maybe-all-stagetrain-zlib
all-stagefeedback-bfd: maybe-all-stagefeedback-zlib
all-stageautoprofile-bfd: maybe-all-stageautoprofile-zlib
all-stageautofeedback-bfd: maybe-all-stageautofeedback-zlib
+all-bfd: maybe-all-libsframe
+all-stage1-bfd: maybe-all-stage1-libsframe
+all-stage2-bfd: maybe-all-stage2-libsframe
+all-stage3-bfd: maybe-all-stage3-libsframe
+all-stage4-bfd: maybe-all-stage4-libsframe
+all-stageprofile-bfd: maybe-all-stageprofile-libsframe
+all-stagetrain-bfd: maybe-all-stagetrain-libsframe
+all-stagefeedback-bfd: maybe-all-stagefeedback-libsframe
+all-stageautoprofile-bfd: maybe-all-stageautoprofile-libsframe
+all-stageautofeedback-bfd: maybe-all-stageautofeedback-libsframe
configure-opcodes: configure-libiberty
configure-stage1-opcodes: configure-stage1-libiberty
configure-stage2-opcodes: configure-stage2-libiberty
@@ -66486,6 +66496,7 @@ all-stageautoprofile-binutils:
maybe-all-stageautoprofile-libsframe
all-stageautofeedback-binutils: maybe-all-stageautofeedback-libsframe
install-binutils: maybe-install-opcodes
install-strip-binutils: maybe-install-strip-opcodes
+install-bfd: maybe-install-libsframe
install-libctf: maybe-install-bfd
install-ld: maybe-install-bfd
install-ld: maybe-install-libctf
--
2.41.0
[PATCH 24/24] toplevel: Makefile.def: add install-strip dependency on libsframe
From: Indu Bhagat
As noted in PR libsframe/30014 - FTBFS: install-strip fails because
bfdlib relinks and fails to find libsframe, the install time
dependencies of libbfd need to be updated.
ChangeLog:
* Makefile.def: Reflect that libsframe needs to installed before
libbfd. Reorder a bit to better track libsframe dependencies.
* Makefile.in: Regenerate.
---
Makefile.def | 5 -
Makefile.in | 3 ++-
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/Makefile.def b/Makefile.def
index 0c6784b6da1..870150183b9 100644
--- a/Makefile.def
+++ b/Makefile.def
@@ -492,7 +492,6 @@ dependencies = { module=install-binutils;
on=install-opcodes; };
dependencies = { module=install-strip-binutils; on=install-strip-opcodes; };
// Likewise for ld, libctf, and bfd.
-dependencies = { module=install-bfd; on=install-libsframe; };
dependencies = { module=install-libctf; on=install-bfd; };
dependencies = { module=install-ld; on=install-bfd; };
dependencies = { module=install-ld; on=install-libctf; };
@@ -500,6 +499,10 @@ dependencies = { module=install-strip-libctf;
on=install-strip-bfd; };
dependencies = { module=install-strip-ld; on=install-strip-bfd; };
dependencies = { module=install-strip-ld; on=install-strip-libctf; };
+// libbfd depends on libsframe
+dependencies = { module=install-bfd; on=install-libsframe; };
+dependencies = { module=install-strip-bfd; on=install-strip-libsframe; };
+
// libopcodes depends on libbfd
dependencies = { module=configure-opcodes; on=configure-bfd; hard=true; };
dependencies = { module=install-opcodes; on=install-bfd; };
diff --git a/Makefile.in b/Makefile.in
index 35a5d8c575d..c97130a2338 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -66496,13 +66496,14 @@ all-stageautoprofile-binutils:
maybe-all-stageautoprofile-libsframe
all-stageautofeedback-binutils: maybe-all-stageautofeedback-libsframe
install-binutils: maybe-install-opcodes
install-strip-binutils: maybe-install-strip-opcodes
-install-bfd: maybe-install-libsframe
install-libctf: maybe-install-bfd
install-ld: maybe-install-bfd
install-ld: maybe-install-libctf
install-strip-libctf: maybe-install-strip-bfd
install-strip-ld: maybe-install-strip-bfd
install-strip-ld: maybe-install-strip-libctf
+install-bfd: maybe-install-libsframe
+install-strip-bfd: maybe-install-strip-libsframe
configure-opcodes: configure-bfd
configure-stage1-opcodes: configure-stage1-bfd
configure-stage2-opcodes: configure-stage2-bfd
--
2.41.0
[PATCH 14/24] libtool.m4: fix nm BSD flag detection
From: Nick Alcock Libtool needs to get BSD-format (or MS-format) output out of the system nm, so that it can scan generated object files for symbol names for -export-symbols-regex support. Some nms need specific flags to turn on BSD-formatted output, so libtool checks for this in its AC_PATH_NM. Unfortunately the code to do this has a pair of interlocking flaws: - it runs the test by doing an nm of /dev/null. Some platforms reasonably refuse to do an nm on a device file, but before now this has only been worked around by assuming that the error message has a specific textual form emitted by Tru64 nm, and that getting this error means this is Tru64 nm and that nm -B would work to produce BSD-format output, even though the test never actually got anything but an error message out of nm -B. This is fixable by nm'ing *nm itself* (since we necessarily have a path to it). - the test is entirely skipped if NM is set in the environment, on the grounds that the user has overridden the test: but the user cannot reasonably be expected to know that libtool wants not only nm but also flags forcing BSD-format output. Worse yet, one such "user" is the top-level Cygnus configure script, which neither tests for nor specifies any BSD-format flags. So platforms needing BSD-format flags always fail to set them when run in a Cygnus tree, breaking -export-symbols-regex on such platforms. Libtool also needs to augment $LD on some platforms, but this is done unconditionally, augmenting whatever the user specified: the nm check should do the same. One wrinkle: if the user has overridden $NM, a path might have been provided: so we use the user-specified path if there was one, and otherwise do the path search as usual. (If the nm specified doesn't work, this might lead to a few extra pointless path searches -- but the test is going to fail anyway, so that's not a problem.) (Tested with NM unset, and set to nm, /usr/bin/nm, my-nm where my-nm is a symlink to /usr/bin/nm on the PATH, and /not-on-the-path/my-nm where *that* is a symlink to /usr/bin/nm.) ChangeLog: * libtool.m4 (LT_PATH_NM): Try BSDization flags with a user-provided NM, if there is one. Run nm on itself, not on /dev/null, to avoid errors from nms that refuse to work on non-regular files. Remove other workarounds for this problem. Strip out blank lines from the nm output. fixincludes/ChangeLog: * configure: Regenerate. gcc/ChangeLog: * configure: Regenerate. libatomic/ChangeLog: * configure: Regenerate. libbacktrace/ChangeLog: * configure: Regenerate. libcc1/ChangeLog: * configure: Regenerate. libffi/ChangeLog: * configure: Regenerate. libgfortran/ChangeLog: * configure: Regenerate. libgm2/ChangeLog: * configure: Regenerate. libgomp/ChangeLog: * configure: Regenerate. libitm/ChangeLog: * configure: Regenerate. libobjc/ChangeLog: * configure: Regenerate. libphobos/ChangeLog: * configure: Regenerate. libquadmath/ChangeLog: * configure: Regenerate. libsanitizer/ChangeLog: * configure: Regenerate. libssp/ChangeLog: * configure: Regenerate. libstdc++-v3/ChangeLog: * configure: Regenerate. libvtv/ChangeLog: * configure: Regenerate. lto-plugin/ChangeLog: * configure: Regenerate. zlib/ChangeLog: * configure: Regenerate. --- fixincludes/configure | 3 +- gcc/configure | 89 ++-- libatomic/configure| 89 ++-- libbacktrace/configure | 89 ++-- libcc1/configure | 89 ++-- libffi/configure | 89 ++-- libgfortran/configure | 89 ++-- libgm2/configure | 89 ++-- libgomp/configure | 89 ++-- libitm/configure | 89 ++-- libobjc/configure | 89 ++-- libphobos/configure| 89 ++-- libquadmath/configure | 89 ++-- libsanitizer/configure | 89 ++-- libssp/configure | 89 ++-- libstdc++-v3/configure | 101 + libtool.m4 | 88 +-- libvtv/configure | 89 ++-- lto-plugin/configure | 89 ++-- zlib/configure | 89 ++-- 20 files changed, 863 insertions(+), 842 deletions(-) diff --git a/fixincludes/configure b/fixincludes/configure index f1748ebef74..b9770489adc 100755 --- a/fixin
Re: [PATCH] i386: Clear upper bits of XMM register for V4HFmode/V2HFmode operations [PR110762]
On Mon, Aug 7, 2023 at 11:20 AM Uros Bizjak via Gcc-patches
wrote:
>
> On Mon, Aug 7, 2023 at 10:57 AM liuhongt wrote:
> >
> > Similar like r14-2786-gade30fad6669e5, the patch is for V4HF/V2HFmode.
> >
> > Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
> > Ok for trunk?
> >
> > gcc/ChangeLog:
> >
> > PR target/110762
> > * config/i386/mmx.md (3): Changed from define_insn
> > to define_expand and break into ..
> > (v4hf3): .. this.
> > (divv4hf3): .. this.
> > (v2hf3): .. this.
> > (divv2hf3): .. this.
> > (movd_v2hf_to_sse): New define_expand.
> > (movq__to_sse): Extend to V4HFmode.
> > (mmxdoublevecmode): Ditto.
> > (V2FI_V4HF): New mode iterator.
> > * config/i386/sse.md (*vec_concatv4sf): Extend to hanlde V8HF
> > by using mode iterator V4SF_V8HF, renamed to ..
> > (*vec_concat): .. this.
> > (*vec_concatv4sf_0): Extend to handle V8HF by using mode
> > iterator V4SF_V8HF, renamed to ..
> > (*vec_concat_0): .. this.
> > (*vec_concatv8hf_movss): New define_insn.
> > (V4SF_V8HF): New mode iterator.
> >
> > gcc/testsuite/ChangeLog:
> >
> > * gcc.target/i386/pr110762-v4hf.c: New test.
>
> LGTM.
>
> Please also note the RFC patch [1] that relaxes clears for V2SFmode
> with -fno-trapping-math. The patched compiler will then emit the same
> code as clang does for -O2. Which raises another question - should gcc
> default to -fno-trapping-math?
I think we discussed this before and yes, IMHO we should default to
-fno-trapping-math at least for C/C++ to be consistent with our other
handling of the FP environment (default to -fno-rounding-math) and
lack of proper FENV access barriers for inspecting the exceptions.
Note Fortran has the -ffpe-trap= option which would then need to make
sure to also enable -ftrapping-math. Ada might have similar constraints
(it also uses -fnon-call-exceptions, but unless it enables CPU traps for
FP exceptions that would be a no-op). Note this also shows we should
possibly separate maintaining the IEEE exception state and considering
changes in the IEEE exception states to cause CPU traps (that's also
a source of common confusion on the user side).
Richard.
> [1] https://gcc.gnu.org/pipermail/gcc-patches/2023-July/625795.html
>
> Thanks,
> Uros.
>
> > ---
> > gcc/config/i386/mmx.md| 109 +++---
> > gcc/config/i386/sse.md| 40 +--
> > gcc/testsuite/gcc.target/i386/pr110762-v4hf.c | 57 +
> > 3 files changed, 177 insertions(+), 29 deletions(-)
> > create mode 100644 gcc/testsuite/gcc.target/i386/pr110762-v4hf.c
> >
> > diff --git a/gcc/config/i386/mmx.md b/gcc/config/i386/mmx.md
> > index 896af76a33f..88bdf084f54 100644
> > --- a/gcc/config/i386/mmx.md
> > +++ b/gcc/config/i386/mmx.md
> > @@ -79,9 +79,7 @@ (define_mode_iterator V_16_32_64
> > ;; V2S* modes
> > (define_mode_iterator V2FI [V2SF V2SI])
> >
> > -;; 4-byte and 8-byte float16 vector modes
> > -(define_mode_iterator VHF_32_64 [V4HF V2HF])
> > -
> > +(define_mode_iterator V2FI_V4HF [V2SF V2SI V4HF])
> > ;; Mapping from integer vector mode to mnemonic suffix
> > (define_mode_attr mmxvecsize
> >[(V8QI "b") (V4QI "b") (V2QI "b")
> > @@ -108,7 +106,7 @@ (define_mode_attr mmxintvecmodelower
> >
> > ;; Mapping of vector modes to a vector mode of double size
> > (define_mode_attr mmxdoublevecmode
> > - [(V2SF "V4SF") (V2SI "V4SI")])
> > + [(V2SF "V4SF") (V2SI "V4SI") (V4HF "V8HF")])
> >
> > ;; Mapping of vector modes back to the scalar modes
> > (define_mode_attr mmxscalarmode
> > @@ -594,7 +592,7 @@ (define_insn "sse_movntq"
> > (define_expand "movq__to_sse"
> >[(set (match_operand: 0 "register_operand")
> > (vec_concat:
> > - (match_operand:V2FI 1 "nonimmediate_operand")
> > + (match_operand:V2FI_V4HF 1 "nonimmediate_operand")
> > (match_dup 2)))]
> >"TARGET_SSE2"
> >"operands[2] = CONST0_RTX (mode);")
> > @@ -1927,21 +1925,94 @@ (define_expand "lroundv2sfv2si2"
> > ;;
> > ;
> >
> > -(define_insn "3"
> > - [(set (match_operand:VHF_32_64 0 "register_operand" "=v")
> > - (plusminusmultdiv:VHF_32_64
> > - (match_operand:VHF_32_64 1 "register_operand" "v")
> > - (match_operand:VHF_32_64 2 "register_operand" "v")))]
> > +(define_expand "v4hf3"
> > + [(set (match_operand:V4HF 0 "register_operand")
> > + (plusminusmult:V4HF
> > + (match_operand:V4HF 1 "nonimmediate_operand")
> > + (match_operand:V4HF 2 "nonimmediate_operand")))]
> >"TARGET_AVX512FP16 && TARGET_AVX512VL"
> > - "vph\t{%2, %1, %0|%0, %1, %2}"
> > - [(set (attr "type")
> > - (cond [(match_test " == MULT")
> > - (const_string "ssemul")
> > -(match_test " == DIV")
> > - (const_string "ssediv")]
> > -
[PATCH 19/24] Deprecate a.out support for NetBSD targets.
From: John Ericson
As discussed previously, a.out support is now quite deprecated, and in
some cases removed, in both Binutils itself and NetBSD, so this legacy
default makes little sense. `netbsdelf*` and `netbsdaout*` still work
allowing the user to be explicit about there choice. Additionally, the
configure script warns about the change as Nick Clifton requested.
One possible concern was the status of NetBSD on NS32K, where only a.out
was supported. But per [1] NetBSD has removed support, and if it were to
come back, it would be with ELF. The binutils implementation is
therefore marked obsolete, per the instructions in the last message.
With that patch and this one applied, I have confirmed the following:
--target=i686-unknown-netbsd
--target=i686-unknown-netbsdelf
builds completely
--target=i686-unknown-netbsdaout
properly fails because target is deprecated.
--target=vax-unknown-netbsdaout builds completely except for gas, where
the target is deprecated.
[1]: https://mail-index.netbsd.org/tech-toolchain/2021/07/19/msg004025.html
config/ChangeLog:
* picflag.m4: Simplify SHmedia NetBSD match by presuming ELF.
gcc/ChangeLog:
* configure: Regenerate.
libada/ChangeLog:
* configure: Regenerate.
libgcc/ChangeLog:
* configure: Regenerate.
libiberty/ChangeLog:
* configure: Regenerate.
---
config/picflag.m4 | 4 +---
gcc/configure | 8 +++-
libada/configure| 4 +---
libgcc/configure| 4 +---
libiberty/configure | 4 +---
5 files changed, 7 insertions(+), 17 deletions(-)
diff --git a/config/picflag.m4 b/config/picflag.m4
index 0aefcf619bf..3f3ac744c96 100644
--- a/config/picflag.m4
+++ b/config/picflag.m4
@@ -63,9 +63,7 @@ case "${$2}" in
sh-*-linux* | sh[[2346lbe]]*-*-linux*)
$1=-fpic
;;
-# FIXME: Simplify to sh*-*-netbsd*?
-sh-*-netbsdelf* | shl*-*-netbsdelf* | sh5-*-netbsd* | sh5l*-*-netbsd* | \
- sh64-*-netbsd* | sh64l*-*-netbsd*)
+sh*-*-netbsd*)
$1=-fpic
;;
# Default to -fPIC unless specified otherwise.
diff --git a/gcc/configure b/gcc/configure
index cd9919e858d..e5e95e7c1c8 100755
--- a/gcc/configure
+++ b/gcc/configure
@@ -5480,9 +5480,7 @@ case "${target}" in
sh-*-linux* | sh[2346lbe]*-*-linux*)
PICFLAG_FOR_TARGET=-fpic
;;
-# FIXME: Simplify to sh*-*-netbsd*?
-sh-*-netbsdelf* | shl*-*-netbsdelf* | sh5-*-netbsd* | sh5l*-*-netbsd* | \
- sh64-*-netbsd* | sh64l*-*-netbsd*)
+sh*-*-netbsd*)
PICFLAG_FOR_TARGET=-fpic
;;
# Default to -fPIC unless specified otherwise.
@@ -19888,7 +19886,7 @@ else
lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
lt_status=$lt_dlunknown
cat > conftest.$ac_ext <<_LT_EOF
-#line 19891 "configure"
+#line 19889 "configure"
#include "confdefs.h"
#if HAVE_DLFCN_H
@@ -19994,7 +19992,7 @@ else
lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
lt_status=$lt_dlunknown
cat > conftest.$ac_ext <<_LT_EOF
-#line 19997 "configure"
+#line 19995 "configure"
#include "confdefs.h"
#if HAVE_DLFCN_H
diff --git a/libada/configure b/libada/configure
index 9c8b133d817..ac4dad3ad3b 100755
--- a/libada/configure
+++ b/libada/configure
@@ -3231,9 +3231,7 @@ case "${host}" in
sh-*-linux* | sh[2346lbe]*-*-linux*)
PICFLAG=-fpic
;;
-# FIXME: Simplify to sh*-*-netbsd*?
-sh-*-netbsdelf* | shl*-*-netbsdelf* | sh5-*-netbsd* | sh5l*-*-netbsd* | \
- sh64-*-netbsd* | sh64l*-*-netbsd*)
+sh*-*-netbsd*)
PICFLAG=-fpic
;;
# Default to -fPIC unless specified otherwise.
diff --git a/libgcc/configure b/libgcc/configure
index 1e727367ba3..cf149209652 100755
--- a/libgcc/configure
+++ b/libgcc/configure
@@ -2422,9 +2422,7 @@ case "${host}" in
sh-*-linux* | sh[2346lbe]*-*-linux*)
PICFLAG=-fpic
;;
-# FIXME: Simplify to sh*-*-netbsd*?
-sh-*-netbsdelf* | shl*-*-netbsdelf* | sh5-*-netbsd* | sh5l*-*-netbsd* | \
- sh64-*-netbsd* | sh64l*-*-netbsd*)
+sh*-*-netbsd*)
PICFLAG=-fpic
;;
# Default to -fPIC unless specified otherwise.
diff --git a/libiberty/configure b/libiberty/configure
index bdc860f1623..dd896270dc6 100755
--- a/libiberty/configure
+++ b/libiberty/configure
@@ -5368,9 +5368,7 @@ case "${host}" in
sh-*-linux* | sh[2346lbe]*-*-linux*)
PICFLAG=-fpic
;;
-# FIXME: Simplify to sh*-*-netbsd*?
-sh-*-netbsdelf* | shl*-*-netbsdelf* | sh5-*-netbsd* | sh5l*-*-netbsd* | \
- sh64-*-netbsd* | sh64l*-*-netbsd*)
+sh*-*-netbsd*)
PICFLAG=-fpic
;;
# Default to -fPIC unless specified otherwise.
--
2.41.0
[PATCH 22/24] libtool.m4: augment symcode for Solaris 11
From: Nick Alcock This reports common symbols like GNU nm, via a type code of 'C'. ChangeLog: * libtool.m4 (lt_cv_sys_global_symbol_pipe): Augment symcode for Solaris 11. gcc/ChangeLog: * configure: Regenerate. libatomic/ChangeLog: * configure: Regenerate. libbacktrace/ChangeLog: * configure: Regenerate. libcc1/ChangeLog: * configure: Regenerate. libffi/ChangeLog: * configure: Regenerate. libgfortran/ChangeLog: * configure: Regenerate. libgm2/ChangeLog: * configure: Regenerate. libgomp/ChangeLog: * configure: Regenerate. libitm/ChangeLog: * configure: Regenerate. libobjc/ChangeLog: * configure: Regenerate. libphobos/ChangeLog: * configure: Regenerate. libquadmath/ChangeLog: * configure: Regenerate. libsanitizer/ChangeLog: * configure: Regenerate. libssp/ChangeLog: * configure: Regenerate. libstdc++-v3/ChangeLog: * configure: Regenerate. libvtv/ChangeLog: * configure: Regenerate. lto-plugin/ChangeLog: * configure: Regenerate. zlib/ChangeLog: * configure: Regenerate. --- gcc/configure | 2 +- libatomic/configure| 2 +- libbacktrace/configure | 2 +- libcc1/configure | 2 +- libffi/configure | 2 +- libgfortran/configure | 2 +- libgm2/configure | 2 +- libgomp/configure | 2 +- libitm/configure | 2 +- libobjc/configure | 2 +- libphobos/configure| 2 +- libquadmath/configure | 2 +- libsanitizer/configure | 2 +- libssp/configure | 2 +- libstdc++-v3/configure | 2 +- libtool.m4 | 2 +- libvtv/configure | 2 +- lto-plugin/configure | 2 +- zlib/configure | 2 +- 19 files changed, 19 insertions(+), 19 deletions(-) diff --git a/gcc/configure b/gcc/configure index e5e95e7c1c8..ea1ad6606a6 100755 --- a/gcc/configure +++ b/gcc/configure @@ -15346,7 +15346,7 @@ osf*) symcode='[BCDEGQRST]' ;; solaris*) - symcode='[BDRT]' + symcode='[BCDRT]' ;; sco3.2v5*) symcode='[DT]' diff --git a/libatomic/configure b/libatomic/configure index 75096735c61..57f320753e1 100755 --- a/libatomic/configure +++ b/libatomic/configure @@ -6593,7 +6593,7 @@ osf*) symcode='[BCDEGQRST]' ;; solaris*) - symcode='[BDRT]' + symcode='[BCDRT]' ;; sco3.2v5*) symcode='[DT]' diff --git a/libbacktrace/configure b/libbacktrace/configure index f3ef3fc3f23..c3e7b884e36 100755 --- a/libbacktrace/configure +++ b/libbacktrace/configure @@ -7038,7 +7038,7 @@ osf*) symcode='[BCDEGQRST]' ;; solaris*) - symcode='[BDRT]' + symcode='[BCDRT]' ;; sco3.2v5*) symcode='[DT]' diff --git a/libcc1/configure b/libcc1/configure index edf03334f30..1a63a0e4e1a 100755 --- a/libcc1/configure +++ b/libcc1/configure @@ -6299,7 +6299,7 @@ osf*) symcode='[BCDEGQRST]' ;; solaris*) - symcode='[BDRT]' + symcode='[BCDRT]' ;; sco3.2v5*) symcode='[DT]' diff --git a/libffi/configure b/libffi/configure index a1ded4f617b..9eac9c907bf 100755 --- a/libffi/configure +++ b/libffi/configure @@ -6825,7 +6825,7 @@ osf*) symcode='[BCDEGQRST]' ;; solaris*) - symcode='[BDRT]' + symcode='[BCDRT]' ;; sco3.2v5*) symcode='[DT]' diff --git a/libgfortran/configure b/libgfortran/configure index 7b408515498..cd176b04a14 100755 --- a/libgfortran/configure +++ b/libgfortran/configure @@ -8227,7 +8227,7 @@ osf*) symcode='[BCDEGQRST]' ;; solaris*) - symcode='[BDRT]' + symcode='[BCDRT]' ;; sco3.2v5*) symcode='[DT]' diff --git a/libgm2/configure b/libgm2/configure index 2d54302129c..f576681098f 100755 --- a/libgm2/configure +++ b/libgm2/configure @@ -8129,7 +8129,7 @@ osf*) symcode='[BCDEGQRST]' ;; solaris*) - symcode='[BDRT]' + symcode='[BCDRT]' ;; sco3.2v5*) symcode='[DT]' diff --git a/libgomp/configure b/libgomp/configure index 6d4b6e3850e..a12b30f1b0f 100755 --- a/libgomp/configure +++ b/libgomp/configure @@ -6607,7 +6607,7 @@ osf*) symcode='[BCDEGQRST]' ;; solaris*) - symcode='[BDRT]' + symcode='[BCDRT]' ;; sco3.2v5*) symcode='[DT]' diff --git a/libitm/configure b/libitm/configure index 83ff24b73e8..02e8de7896b 100755 --- a/libitm/configure +++ b/libitm/configure @@ -7268,7 +7268,7 @@ osf*) symcode='[BCDEGQRST]' ;; solaris*) - symcode='[BDRT]' + symcode='[BCDRT]' ;; sco3.2v5*) symcode='[DT]' diff --git a/libobjc/configure b/libobjc/configure index fd590e628ab..752f6fdfebd 100755 --- a/libobjc/configure +++ b/libobjc/configure @@ -5995,7 +5995,7 @@ osf*) symcode='[BCDEGQRST]' ;; solaris*) - symcode='[BDRT]' + symcode='[BCDRT]' ;; sco3.2v5*) symcode='[DT]' diff --git a/libphobos/configure b/libphobos/configure index 814cacc1120..b7276d95010 100755 --- a/libphobos/configure +++ b/libphobos/configure @@ -7272,7 +7272,7 @@ osf*) symcode='[BCDEGQRST]' ;; solaris*) - symcode='[BDRT]' + symcode='[BCDRT]' ;; sco3.2v5*) symcode='[DT]' diff --git a/libquadmath/c
[PATCH] cprop_hardreg: Allow more propagation of the stack pointer.
The stack pointer propagation fix 736f8fd3 turned out to be more restrictive
than needed by rejecting propagation of the stack pointer when REG_POINTER
didn't match.
This commit removes this check:
When the stack pointer is propagated it is fine for this to result in
REG_POINTER becoming true from false, which is what the original code checked.
This simplification makes the previously introduced function
maybe_copy_reg_attrs obsolete and the logic can be inlined at the call sites,
as it was before 736f8fd3.
gcc/ChangeLog:
* regcprop.cc (maybe_copy_reg_attrs): Remove unnecessary function.
(find_oldest_value_reg): Inline stack_pointer_rtx check.
(copyprop_hardreg_forward_1): Inline stack_pointer_rtx check.
Signed-off-by: Manolis Tsamis
---
gcc/regcprop.cc | 56 -
1 file changed, 23 insertions(+), 33 deletions(-)
diff --git a/gcc/regcprop.cc b/gcc/regcprop.cc
index d28a4d5aca8..a75af2ba7e3 100644
--- a/gcc/regcprop.cc
+++ b/gcc/regcprop.cc
@@ -451,31 +451,6 @@ maybe_mode_change (machine_mode orig_mode, machine_mode
copy_mode,
return NULL_RTX;
}
-/* Helper function to copy attributes when replacing OLD_REG with NEW_REG.
- If the changes required for NEW_REG are invalid return NULL_RTX, otherwise
- return NEW_REG. This is intended to be used with maybe_mode_change. */
-
-static rtx
-maybe_copy_reg_attrs (rtx new_reg, rtx old_reg)
-{
- if (new_reg != stack_pointer_rtx)
-{
- /* NEW_REG is assumed to be a register copy resulting from
-maybe_mode_change. */
- ORIGINAL_REGNO (new_reg) = ORIGINAL_REGNO (old_reg);
- REG_ATTRS (new_reg) = REG_ATTRS (old_reg);
- REG_POINTER (new_reg) = REG_POINTER (old_reg);
-}
- else if (REG_POINTER (new_reg) != REG_POINTER (old_reg))
-{
- /* Only a single instance of STACK_POINTER_RTX must exist and we cannot
-modify it. Allow propagation if REG_POINTER for OLD_REG matches and
-don't touch ORIGINAL_REGNO and REG_ATTRS. */
- return NULL_RTX;
-}
- return new_reg;
-}
-
/* Find the oldest copy of the value contained in REGNO that is in
register class CL and has mode MODE. If found, return an rtx
of that oldest register, otherwise return NULL. */
@@ -511,7 +486,17 @@ find_oldest_value_reg (enum reg_class cl, rtx reg, struct
value_data *vd)
new_rtx = maybe_mode_change (oldmode, vd->e[regno].mode, mode, i, regno);
if (new_rtx)
- return maybe_copy_reg_attrs (new_rtx, reg);
+ {
+ /* NEW_RTX may be the global stack pointer rtx, in which case we
+must not modify it's attributes. */
+ if (new_rtx != stack_pointer_rtx)
+ {
+ ORIGINAL_REGNO (new_rtx) = ORIGINAL_REGNO (reg);
+ REG_ATTRS (new_rtx) = REG_ATTRS (reg);
+ REG_POINTER (new_rtx) = REG_POINTER (reg);
+ }
+ return new_rtx;
+ }
}
return NULL_RTX;
@@ -985,15 +970,20 @@ copyprop_hardreg_forward_1 (basic_block bb, struct
value_data *vd)
if (validate_change (insn, &SET_SRC (set), new_rtx, 0))
{
- if (maybe_copy_reg_attrs (new_rtx, src))
+ /* NEW_RTX may be the global stack pointer rtx, in which
+case we must not modify it's attributes. */
+ if (new_rtx != stack_pointer_rtx)
{
- if (dump_file)
- fprintf (dump_file,
-"insn %u: replaced reg %u with %u\n",
-INSN_UID (insn), regno, REGNO (new_rtx));
- changed = true;
- goto did_replacement;
+ ORIGINAL_REGNO (new_rtx) = ORIGINAL_REGNO (src);
+ REG_ATTRS (new_rtx) = REG_ATTRS (src);
+ REG_POINTER (new_rtx) = REG_POINTER (src);
}
+ if (dump_file)
+ fprintf (dump_file,
+"insn %u: replaced reg %u with %u\n",
+INSN_UID (insn), regno, REGNO (new_rtx));
+ changed = true;
+ goto did_replacement;
}
/* We need to re-extract as validate_change clobbers
recog_data. */
--
2.34.1
Re: [PATCH] i386: Clear upper bits of XMM register for V4HFmode/V2HFmode operations [PR110762]
On Mon, Aug 7, 2023 at 5:19 PM Uros Bizjak via Gcc-patches
wrote:
>
> On Mon, Aug 7, 2023 at 10:57 AM liuhongt wrote:
> >
> > Similar like r14-2786-gade30fad6669e5, the patch is for V4HF/V2HFmode.
> >
> > Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
> > Ok for trunk?
> >
> > gcc/ChangeLog:
> >
> > PR target/110762
> > * config/i386/mmx.md (3): Changed from define_insn
> > to define_expand and break into ..
> > (v4hf3): .. this.
> > (divv4hf3): .. this.
> > (v2hf3): .. this.
> > (divv2hf3): .. this.
> > (movd_v2hf_to_sse): New define_expand.
> > (movq__to_sse): Extend to V4HFmode.
> > (mmxdoublevecmode): Ditto.
> > (V2FI_V4HF): New mode iterator.
> > * config/i386/sse.md (*vec_concatv4sf): Extend to hanlde V8HF
> > by using mode iterator V4SF_V8HF, renamed to ..
> > (*vec_concat): .. this.
> > (*vec_concatv4sf_0): Extend to handle V8HF by using mode
> > iterator V4SF_V8HF, renamed to ..
> > (*vec_concat_0): .. this.
> > (*vec_concatv8hf_movss): New define_insn.
> > (V4SF_V8HF): New mode iterator.
> >
> > gcc/testsuite/ChangeLog:
> >
> > * gcc.target/i386/pr110762-v4hf.c: New test.
>
> LGTM.
>
> Please also note the RFC patch [1] that relaxes clears for V2SFmode
> with -fno-trapping-math. The patched compiler will then emit the same
> code as clang does for -O2. Which raises another question - should gcc
> default to -fno-trapping-math?
>
> [1] https://gcc.gnu.org/pipermail/gcc-patches/2023-July/625795.html
>
I can create another patch to handle my parts for -fno-trapping-math
optimization.
> Thanks,
> Uros.
>
> > ---
> > gcc/config/i386/mmx.md| 109 +++---
> > gcc/config/i386/sse.md| 40 +--
> > gcc/testsuite/gcc.target/i386/pr110762-v4hf.c | 57 +
> > 3 files changed, 177 insertions(+), 29 deletions(-)
> > create mode 100644 gcc/testsuite/gcc.target/i386/pr110762-v4hf.c
> >
> > diff --git a/gcc/config/i386/mmx.md b/gcc/config/i386/mmx.md
> > index 896af76a33f..88bdf084f54 100644
> > --- a/gcc/config/i386/mmx.md
> > +++ b/gcc/config/i386/mmx.md
> > @@ -79,9 +79,7 @@ (define_mode_iterator V_16_32_64
> > ;; V2S* modes
> > (define_mode_iterator V2FI [V2SF V2SI])
> >
> > -;; 4-byte and 8-byte float16 vector modes
> > -(define_mode_iterator VHF_32_64 [V4HF V2HF])
> > -
> > +(define_mode_iterator V2FI_V4HF [V2SF V2SI V4HF])
> > ;; Mapping from integer vector mode to mnemonic suffix
> > (define_mode_attr mmxvecsize
> >[(V8QI "b") (V4QI "b") (V2QI "b")
> > @@ -108,7 +106,7 @@ (define_mode_attr mmxintvecmodelower
> >
> > ;; Mapping of vector modes to a vector mode of double size
> > (define_mode_attr mmxdoublevecmode
> > - [(V2SF "V4SF") (V2SI "V4SI")])
> > + [(V2SF "V4SF") (V2SI "V4SI") (V4HF "V8HF")])
> >
> > ;; Mapping of vector modes back to the scalar modes
> > (define_mode_attr mmxscalarmode
> > @@ -594,7 +592,7 @@ (define_insn "sse_movntq"
> > (define_expand "movq__to_sse"
> >[(set (match_operand: 0 "register_operand")
> > (vec_concat:
> > - (match_operand:V2FI 1 "nonimmediate_operand")
> > + (match_operand:V2FI_V4HF 1 "nonimmediate_operand")
> > (match_dup 2)))]
> >"TARGET_SSE2"
> >"operands[2] = CONST0_RTX (mode);")
> > @@ -1927,21 +1925,94 @@ (define_expand "lroundv2sfv2si2"
> > ;;
> > ;
> >
> > -(define_insn "3"
> > - [(set (match_operand:VHF_32_64 0 "register_operand" "=v")
> > - (plusminusmultdiv:VHF_32_64
> > - (match_operand:VHF_32_64 1 "register_operand" "v")
> > - (match_operand:VHF_32_64 2 "register_operand" "v")))]
> > +(define_expand "v4hf3"
> > + [(set (match_operand:V4HF 0 "register_operand")
> > + (plusminusmult:V4HF
> > + (match_operand:V4HF 1 "nonimmediate_operand")
> > + (match_operand:V4HF 2 "nonimmediate_operand")))]
> >"TARGET_AVX512FP16 && TARGET_AVX512VL"
> > - "vph\t{%2, %1, %0|%0, %1, %2}"
> > - [(set (attr "type")
> > - (cond [(match_test " == MULT")
> > - (const_string "ssemul")
> > -(match_test " == DIV")
> > - (const_string "ssediv")]
> > -(const_string "sseadd")))
> > - (set_attr "prefix" "evex")
> > - (set_attr "mode" "V8HF")])
> > +{
> > + rtx op2 = gen_reg_rtx (V8HFmode);
> > + rtx op1 = gen_reg_rtx (V8HFmode);
> > + rtx op0 = gen_reg_rtx (V8HFmode);
> > +
> > + emit_insn (gen_movq_v4hf_to_sse (op2, operands[2]));
> > + emit_insn (gen_movq_v4hf_to_sse (op1, operands[1]));
> > +
> > + emit_insn (gen_v8hf3 (op0, op1, op2));
> > +
> > + emit_move_insn (operands[0], lowpart_subreg (V4HFmode, op0, V8HFmode));
> > + DONE;
> > +})
> > +
> > +(define_expand "divv4hf3"
> > + [(set (match_operand:V4HF 0 "register_operand")
> > + (div:V4HF
> > + (match_operand:V4HF 1 "nonimmedia
Re: [PATCH] Fix ICE in rtl check when bootstrap.
On Mon, Aug 7, 2023 at 4:54 PM liuhongt wrote:
>
> /var/tmp/portage/sys-devel/gcc-14.0.0_pre20230806/work/gcc-14-20230806/libgfortran/generated/matmul_i1.c:
> In function ‘matmul_i1_avx512f’:
> /var/tmp/portage/sys-devel/gcc-14.0.0_pre20230806/work/gcc-14-20230806/libgfortran/generated/matmul_i1.c:1781:1:
> internal compiler error: RTL check: expected elt 0 type 'i' or 'n', have 'w'
> (rtx const_int) in vpternlog_redundant_operand_mask, at
> config/i386/i386.cc:19460
> 1781 | }
> | ^
> 0x5559de26dc2d rtl_check_failed_type2(rtx_def const*, int, int, int, char
> const*, int, char const*)
>
> /var/tmp/portage/sys-devel/gcc-14.0.0_pre20230806/work/gcc-14-20230806/gcc/rtl.cc:761
> 0x5559de340bfe vpternlog_redundant_operand_mask(rtx_def**)
>
> /var/tmp/portage/sys-devel/gcc-14.0.0_pre20230806/work/gcc-14-20230806/gcc/config/i386/i386.cc:19460
> 0x5559dfec67a6 split_44
>
> /var/tmp/portage/sys-devel/gcc-14.0.0_pre20230806/work/gcc-14-20230806/gcc/config/i386/sse.md:12730
> 0x5559dfec67a6 split_63
>
> /var/tmp/portage/sys-devel/gcc-14.0.0_pre20230806/work/gcc-14-20230806/gcc/config/i386/sse.md:28428
> 0x5559deb8a682 try_split(rtx_def*, rtx_insn*, int)
>
> /var/tmp/portage/sys-devel/gcc-14.0.0_pre20230806/work/gcc-14-20230806/gcc/emit-rtl.cc:3800
> 0x5559deb8adf2 try_split(rtx_def*, rtx_insn*, int)
>
> /var/tmp/portage/sys-devel/gcc-14.0.0_pre20230806/work/gcc-14-20230806/gcc/emit-rtl.cc:3972
> 0x5559def69194 split_insn
>
> /var/tmp/portage/sys-devel/gcc-14.0.0_pre20230806/work/gcc-14-20230806/gcc/recog.cc:3385
> 0x5559def70c57 split_all_insns()
>
> /var/tmp/portage/sys-devel/gcc-14.0.0_pre20230806/work/gcc-14-20230806/gcc/recog.cc:3489
> 0x5559def70d0c execute
>
> /var/tmp/portage/sys-devel/gcc-14.0.0_pre20230806/work/gcc-14-20230806/gcc/recog.cc:4413
>
> Use INTVAL (imm_op) instead of XINT (imm_op, 0).
>
> Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
> Ok for trunk?
Pushed to trunk as an obvious fix.
>
> gcc/ChangeLog:
>
> * config/i386/i386-protos.h (vpternlog_redundant_operand_mask):
> Adjust parameter type.
> * config/i386/i386.cc (vpternlog_redundant_operand_mask): Use
> INTVAL instead of XINT, also adjust parameter type from rtx* to
> rtx since the function only needs operands[4] in vpternlog
> pattern.
> (substitute_vpternlog_operands): Pass operands[4] instead of
> operands to vpternlog_redundant_operand_mask
> * config/i386/sse.md: Ditto.
> ---
> gcc/config/i386/i386-protos.h | 2 +-
> gcc/config/i386/i386.cc | 6 +++---
> gcc/config/i386/sse.md| 4 ++--
> 3 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/gcc/config/i386/i386-protos.h b/gcc/config/i386/i386-protos.h
> index e547ee64587..fc2f1f13b78 100644
> --- a/gcc/config/i386/i386-protos.h
> +++ b/gcc/config/i386/i386-protos.h
> @@ -70,7 +70,7 @@ extern machine_mode ix86_cc_mode (enum rtx_code, rtx, rtx);
> extern int avx_vpermilp_parallel (rtx par, machine_mode mode);
> extern int avx_vperm2f128_parallel (rtx par, machine_mode mode);
>
> -extern int vpternlog_redundant_operand_mask (rtx[]);
> +extern int vpternlog_redundant_operand_mask (rtx);
> extern void substitute_vpternlog_operands (rtx[]);
>
> extern bool ix86_expand_strlen (rtx, rtx, rtx, rtx);
> diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc
> index 8cd26eb54fa..50860050049 100644
> --- a/gcc/config/i386/i386.cc
> +++ b/gcc/config/i386/i386.cc
> @@ -19454,10 +19454,10 @@ avx_vperm2f128_parallel (rtx par, machine_mode mode)
> /* Return a mask of VPTERNLOG operands that do not affect output. */
>
> int
> -vpternlog_redundant_operand_mask (rtx *operands)
> +vpternlog_redundant_operand_mask (rtx pternlog_imm)
> {
>int mask = 0;
> - int imm8 = XINT (operands[4], 0);
> + int imm8 = INTVAL (pternlog_imm);
>
>if (((imm8 >> 4) & 0x0F) == (imm8 & 0x0F))
> mask |= 1;
> @@ -19475,7 +19475,7 @@ vpternlog_redundant_operand_mask (rtx *operands)
> void
> substitute_vpternlog_operands (rtx *operands)
> {
> - int mask = vpternlog_redundant_operand_mask (operands);
> + int mask = vpternlog_redundant_operand_mask (operands[4]);
>
>if (mask & 1) /* The first operand is redundant. */
> operands[1] = operands[2];
> diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
> index 7e2aa3f995c..c53450fd965 100644
> --- a/gcc/config/i386/sse.md
> +++ b/gcc/config/i386/sse.md
> @@ -12706,7 +12706,7 @@ (define_split
>(match_operand:V 3 "memory_operand")
>(match_operand:SI 4 "const_0_to_255_operand")]
> UNSPEC_VTERNLOG))]
> - "!reload_completed && vpternlog_redundant_operand_mask (operands) == 3"
> + "!reload_completed && vpternlog_redundant_operand_mask (operands[4]) == 3"
>[(set (match_dup 0)
> (match_dup 3))
> (set (match_dup 0)
> @@ -12727,7 +12727,7 @@ (define_split
>(match_operand:
Re: [PATCH 1/3] targhooks: Extend legitimate_address_p with code_helper [PR110248]
On Mon, Aug 7, 2023 at 12:15 PM Kewen.Lin wrote:
>
> Hi Richi,
>
> on 2023/6/30 17:13, Kewen.Lin via Gcc-patches wrote:
> > Hi Richi,
> >
> > Thanks for your review!
> >
> > on 2023/6/30 16:56, Richard Biener wrote:
> >> On Fri, Jun 30, 2023 at 7:38 AM Kewen.Lin wrote:
> >>>
> >>> Hi,
> >>>
> >>> As PR110248 shows, some middle-end passes like IVOPTs can
> >>> query the target hook legitimate_address_p with some
> >>> artificially constructed rtx to determine whether some
> >>> addressing modes are supported by target for some gimple
> >>> statement. But for now the existing legitimate_address_p
> >>> only checks the given mode, it's unable to distinguish
> >>> some special cases unfortunately, for example, for LEN_LOAD
> >>> ifn on Power port, we would expand it with lxvl hardware
> >>> insn, which only supports one register to hold the address
> >>> (the other register is holding the length), that is we
> >>> don't support base (reg) + index (reg) addressing mode for
> >>> sure. But hook legitimate_address_p only considers the
> >>> given mode which would be some vector mode for LEN_LOAD
> >>> ifn, and we do support base + index addressing mode for
> >>> normal vector load and store insns, so the hook will return
> >>> true for the query unexpectedly.
> >>>
> >>> This patch is to introduce one extra argument of type
> >>> code_helper for hook legitimate_address_p, it makes targets
> >>> able to handle some special case like what's described
> >>> above. The subsequent patches will show how to leverage
> >>> the new code_helper argument.
> >>>
> >>> I didn't separate those target specific adjustments to
> >>> their own patches, since those changes are no function
> >>> changes. One typical change is to add one unnamed argument
> >>> with default ERROR_MARK, some ports need to include tree.h
> >>> in their {port}-protos.h since the hook is used in some
> >>> machine description files. I've cross-built a corresponding
> >>> cc1 successfully for at least one triple of each affected
> >>> target so I believe they are safe. But feel free to correct
> >>> me if separating is needed for the review of this patch.
> >>>
> >>> Besides, it's bootstrapped and regtested on
> >>> x86_64-redhat-linux and powerpc64{,le}-linux-gnu.
> >>>
> >>> Is it ok for trunk?
> >>
> >> Is defaulting the arguments in the targets necessary for
> >> the middle-end or only for direct uses in the targets?
> >
> > It's only for the direct uses in target codes, the call
> > sites in generic code of these hooks would use the given
> > code_helper type variable or an explicit ERROR_MARK, they
> > don't require target codes to set that.
> >
> >>
> >> It looks OK in general but please give others some time to
> >> comment.
>
> Some weeks passed and no further comments are received, I guess
> this still looks good to you?
Yes.
> BR,
> Kewen
>
> >
> > OK, thanks again!
> >
> > BR,
> > Kewen
> >
> >>
> >> Thanks,
> >> Richard.
> >>
> >>> BR,
> >>> Kewen
> >>> --
> >>> PR tree-optimization/110248
> >>>
> >>> gcc/ChangeLog:
> >>>
> >>> * coretypes.h (class code_helper): Add forward declaration.
> >>> * doc/tm.texi: Regenerate.
> >>> * lra-constraints.cc (valid_address_p): Call target hook
> >>> targetm.addr_space.legitimate_address_p with an extra parameter
> >>> ERROR_MARK as its prototype changes.
> >>> * recog.cc (memory_address_addr_space_p): Likewise.
> >>> * reload.cc (strict_memory_address_addr_space_p): Likewise.
> >>> * target.def (legitimate_address_p,
> >>> addr_space.legitimate_address_p):
> >>> Extend with one more argument of type code_helper, update the
> >>> documentation accordingly.
> >>> * targhooks.cc (default_legitimate_address_p): Adjust for the
> >>> new code_helper argument.
> >>> (default_addr_space_legitimate_address_p): Likewise.
> >>> * targhooks.h (default_legitimate_address_p): Likewise.
> >>> (default_addr_space_legitimate_address_p): Likewise.
> >>> * config/aarch64/aarch64.cc (aarch64_legitimate_address_hook_p):
> >>> Adjust
> >>> with extra unnamed code_helper argument with default ERROR_MARK.
> >>> * config/alpha/alpha.cc (alpha_legitimate_address_p): Likewise.
> >>> * config/arc/arc.cc (arc_legitimate_address_p): Likewise.
> >>> * config/arm/arm-protos.h (arm_legitimate_address_p): Likewise.
> >>> (tree.h): New include for tree_code ERROR_MARK.
> >>> * config/arm/arm.cc (arm_legitimate_address_p): Adjust with extra
> >>> unnamed code_helper argument with default ERROR_MARK.
> >>> * config/avr/avr.cc (avr_addr_space_legitimate_address_p):
> >>> Likewise.
> >>> * config/bfin/bfin.cc (bfin_legitimate_address_p): Likewise.
> >>> * config/bpf/bpf.cc (bpf_legitimate_address_p): Likewise.
> >>> * config/c6x/c6x.cc (c6x_legitimate_address_p): Likewise.
> >>> * config/cris/cris-pr
[PATCH v1] Mode-Switching: Fix SET_SRC ICE when only one operand
From: Pan Li
In same cases, like gcc/testsuite/gcc.dg/pr78148.c in RISC-V, there will
be only 1 operand when SET_SRC in create_pre_exit. For example as below.
(insn 13 9 14 2 (clobber (reg/i:TI 10 a0))
"gcc/testsuite/gcc.dg/pr78148.c":24:1 -1
(expr_list:REG_UNUSED (reg/i:TI 10 a0)
(nil)))
Unfortunately, SET_SRC requires at least 2 operands and then Segment
Fault here. This patch would like to fix this ICE by adding operand
length check before SET_SRC.
Signed-off-by: Pan Li
gcc/ChangeLog:
* mode-switching.cc (create_pre_exit): Add operand length check.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/mode-switch-ice-1.c: New test.
---
gcc/mode-switching.cc | 2 ++
.../gcc.target/riscv/mode-switch-ice-1.c | 22 +++
2 files changed, 24 insertions(+)
create mode 100644 gcc/testsuite/gcc.target/riscv/mode-switch-ice-1.c
diff --git a/gcc/mode-switching.cc b/gcc/mode-switching.cc
index 64ae2bc29c3..cbf03c02159 100644
--- a/gcc/mode-switching.cc
+++ b/gcc/mode-switching.cc
@@ -411,6 +411,8 @@ create_pre_exit (int n_entities, int *entity_map, const int
*num_modes)
conflict with address reloads. */
if (copy_start >= ret_start
&& copy_start + copy_num <= ret_end
+ && GET_RTX_LENGTH (GET_CODE (return_copy_pat)) >= 2
+ /* SET_SRC requires at least 2 operands. */
&& OBJECT_P (SET_SRC (return_copy_pat)))
forced_late_switch = true;
break;
diff --git a/gcc/testsuite/gcc.target/riscv/mode-switch-ice-1.c
b/gcc/testsuite/gcc.target/riscv/mode-switch-ice-1.c
new file mode 100644
index 000..1b34a471904
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/mode-switch-ice-1.c
@@ -0,0 +1,22 @@
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+
+struct A { char e, f; };
+
+struct B
+{
+ int g;
+ struct A h[4];
+};
+
+extern void bar (int, int);
+
+struct B foo (void)
+{
+ bar (2, 1);
+}
+
+void baz ()
+{
+ foo ();
+}
--
2.34.1
RE: RE: [PATCH v1] RISC-V: Refactor RVV frm_mode attr for rounding mode intrinsic
Got you point, thanks kito and will send patch v2 after test.
Pan
-Original Message-
From: Kito Cheng
Sent: Monday, August 7, 2023 2:35 PM
To: Li, Pan2
Cc: juzhe.zh...@rivai.ai; gcc-patches ; Wang, Yanzhang
Subject: Re: RE: [PATCH v1] RISC-V: Refactor RVV frm_mode attr for rounding
mode intrinsic
A build-able patch attached, again, it's based on your patch :)
On Mon, Aug 7, 2023 at 11:46 AM Li, Pan2 via Gcc-patches
wrote:
>
> I am not quite sure if I understand it correctly, but I bet below enums are
> required by RISC-V mode switching, like FRM_MODE_DYN in entry, or
> FRM_MODE_CALL/EXIT in emit.
>
> > ;; Defines rounding mode of an floating-point operation.
> > -(define_attr "frm_mode" "rne,rtz,rdn,rup,rmm,dyn,dyn_exit,dyn_call,none"
> > +(define_attr "frm_mode" ""
> > (cond [(eq_attr "type" "vfalu,vfwalu,vfmul,vfdiv,vfwmul,vfdiv,vfwmul")
> > -(const_string "dyn")]
> > +(const_string "FRM_DYN")]
> >(const_string "none")))
>
> Pan
>
> -Original Message-
> From: Kito Cheng
> Sent: Monday, August 7, 2023 11:27 AM
> To: Li, Pan2
> Cc: juzhe.zh...@rivai.ai; gcc-patches ; Wang,
> Yanzhang
> Subject: Re: RE: [PATCH v1] RISC-V: Refactor RVV frm_mode attr for rounding
> mode intrinsic
>
> What about using similar way as vlmul?
>
>
> # NOTE: diff is based on your patch.
> [kitoc@hsinchu02 riscv]$ git diff
> diff --git a/gcc/config/riscv/riscv-protos.h b/gcc/config/riscv/riscv-protos.h
> index 33f7cb1d670..3cb5c23cb09 100644
> --- a/gcc/config/riscv/riscv-protos.h
> +++ b/gcc/config/riscv/riscv-protos.h
> @@ -345,6 +345,7 @@ enum floating_point_rounding_mode
> FRM_DYN = 7, /* Aka 0b111. */
> FRM_STATIC_MIN = FRM_RNE,
> FRM_STATIC_MAX = FRM_RMM,
> + FRM_NONE = 8,
> };
>
> opt_machine_mode vectorize_related_mode (machine_mode, scalar_mode,
> diff --git a/gcc/config/riscv/riscv-v.cc b/gcc/config/riscv/riscv-v.cc
> index d5fb8611d6e..3d5dc0c11be 100644
> --- a/gcc/config/riscv/riscv-v.cc
> +++ b/gcc/config/riscv/riscv-v.cc
> @@ -112,6 +112,7 @@ public:
> {
> m_has_fp_rounding_mode_p = true;
> m_fp_rounding_mode = mode;
> +gcc_assert (mode != FRM_NONE);
> }
>
> void add_output_operand (rtx x, machine_mode mode)
> diff --git a/gcc/config/riscv/vector.md b/gcc/config/riscv/vector.md
> index f966f1ba769..c1a7650fe85 100644
> --- a/gcc/config/riscv/vector.md
> +++ b/gcc/config/riscv/vector.md
> @@ -865,9 +865,9 @@ (define_attr "vxrm_mode" "rnu,rne,rdn,rod,none"
> (const_string "none")))
>
> ;; Defines rounding mode of an floating-point operation.
> -(define_attr "frm_mode" "rne,rtz,rdn,rup,rmm,dyn,dyn_exit,dyn_call,none"
> +(define_attr "frm_mode" ""
> (cond [(eq_attr "type" "vfalu,vfwalu,vfmul,vfdiv,vfwmul,vfdiv,vfwmul")
> -(const_string "dyn")]
> +(const_string "FRM_DYN")]
>(const_string "none")))
>
> ;; -
Re: [PATCH v1] Mode-Switching: Fix SET_SRC ICE when only one operand
On Mon, Aug 7, 2023 at 2:30 PM Pan Li via Gcc-patches
wrote:
>
> From: Pan Li
>
> In same cases, like gcc/testsuite/gcc.dg/pr78148.c in RISC-V, there will
> be only 1 operand when SET_SRC in create_pre_exit. For example as below.
>
> (insn 13 9 14 2 (clobber (reg/i:TI 10 a0))
> "gcc/testsuite/gcc.dg/pr78148.c":24:1 -1
> (expr_list:REG_UNUSED (reg/i:TI 10 a0)
> (nil)))
>
> Unfortunately, SET_SRC requires at least 2 operands and then Segment
> Fault here. This patch would like to fix this ICE by adding operand
> length check before SET_SRC.
>
> Signed-off-by: Pan Li
>
> gcc/ChangeLog:
>
> * mode-switching.cc (create_pre_exit): Add operand length check.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/riscv/mode-switch-ice-1.c: New test.
> ---
> gcc/mode-switching.cc | 2 ++
> .../gcc.target/riscv/mode-switch-ice-1.c | 22 +++
> 2 files changed, 24 insertions(+)
> create mode 100644 gcc/testsuite/gcc.target/riscv/mode-switch-ice-1.c
>
> diff --git a/gcc/mode-switching.cc b/gcc/mode-switching.cc
> index 64ae2bc29c3..cbf03c02159 100644
> --- a/gcc/mode-switching.cc
> +++ b/gcc/mode-switching.cc
> @@ -411,6 +411,8 @@ create_pre_exit (int n_entities, int *entity_map, const
> int *num_modes)
>conflict with address reloads. */
> if (copy_start >= ret_start
> && copy_start + copy_num <= ret_end
> + && GET_RTX_LENGTH (GET_CODE (return_copy_pat)) >=
> 2
> + /* SET_SRC requires at least 2 operands. */
maybe check that return_copy_pat is a SET instead?
> && OBJECT_P (SET_SRC (return_copy_pat)))
> forced_late_switch = true;
> break;
> diff --git a/gcc/testsuite/gcc.target/riscv/mode-switch-ice-1.c
> b/gcc/testsuite/gcc.target/riscv/mode-switch-ice-1.c
> new file mode 100644
> index 000..1b34a471904
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/riscv/mode-switch-ice-1.c
> @@ -0,0 +1,22 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O2" } */
> +
> +struct A { char e, f; };
> +
> +struct B
> +{
> + int g;
> + struct A h[4];
> +};
> +
> +extern void bar (int, int);
> +
> +struct B foo (void)
> +{
> + bar (2, 1);
> +}
> +
> +void baz ()
> +{
> + foo ();
> +}
> --
> 2.34.1
>
[PATCH] Improve -fopt-info-vec for basic-block vectorization
We currently dump notes like flow_lam.f:65:72: optimized: basic block part vectorized using 32 byte vectors flow_lam.f:65:72: optimized: basic block part vectorized using 32 byte vectors flow_lam.f:65:72: optimized: basic block part vectorized using 32 byte vectors flow_lam.f:65:72: optimized: basic block part vectorized using 32 byte vectors .. repeating the same location for multiple instances because we clobber vect_location during BB vectorization. The following avoids this, improving things to flow_lam.f:15:72: optimized: basic block part vectorized using 32 byte vectors flow_lam.f:16:72: optimized: basic block part vectorized using 32 byte vectors flow_lam.f:17:72: optimized: basic block part vectorized using 32 byte vectors flow_lam.f:18:72: optimized: basic block part vectorized using 32 byte vectors ... Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed. * tree-vect-slp.cc (vect_slp_region): Save/restore vect_location around dumping code. --- gcc/tree-vect-slp.cc | 8 1 file changed, 8 insertions(+) diff --git a/gcc/tree-vect-slp.cc b/gcc/tree-vect-slp.cc index a1b153035e1..eab3dcd40ec 100644 --- a/gcc/tree-vect-slp.cc +++ b/gcc/tree-vect-slp.cc @@ -7496,6 +7496,7 @@ vect_slp_region (vec bbs, vec datarefs, if (instance->subgraph_entries.is_empty ()) continue; + dump_user_location_t saved_vect_location = vect_location; vect_location = instance->location (); if (!unlimited_cost_model (NULL) && !vect_bb_vectorization_profitable_p @@ -7505,9 +7506,11 @@ vect_slp_region (vec bbs, vec datarefs, dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location, "not vectorized: vectorization is not " "profitable.\n"); + vect_location = saved_vect_location; continue; } + vect_location = saved_vect_location; if (!dbg_cnt (vect_slp)) continue; @@ -7557,6 +7560,9 @@ vect_slp_region (vec bbs, vec datarefs, "using SLP\n"); vectorized = true; + dump_user_location_t saved_vect_location = vect_location; + vect_location = instance->location (); + vect_schedule_slp (bb_vinfo, instance->subgraph_entries); unsigned HOST_WIDE_INT bytes; @@ -7572,6 +7578,8 @@ vect_slp_region (vec bbs, vec datarefs, "basic block part vectorized using " "variable length vectors\n"); } + + vect_location = saved_vect_location; } } else -- 2.35.3
Re: [PATCH] rtl-optimization/110587 - speedup find_hard_regno_for_1
On Wed, 2 Aug 2023, Richard Biener wrote:
> On Mon, 31 Jul 2023, Jeff Law wrote:
>
> >
> >
> > On 7/31/23 04:54, Richard Biener via Gcc-patches wrote:
> > > On Tue, 25 Jul 2023, Richard Biener wrote:
> > >
> > >> The following applies a micro-optimization to find_hard_regno_for_1,
> > >> re-ordering the check so we can easily jump-thread by using an else.
> > >> This reduces the time spent in this function by 15% for the testcase
> > >> in the PR.
> > >>
> > >> Bootstrap & regtest running on x86_64-unknown-linux-gnu, OK if that
> > >> passes?
> > >
> > > Ping.
> > >
> > >> Thanks,
> > >> Richard.
> > >>
> > >> PR rtl-optimization/110587
> > >> * lra-assigns.cc (find_hard_regno_for_1): Re-order checks.
> > >> ---
> > >> gcc/lra-assigns.cc | 9 +
> > >> 1 file changed, 5 insertions(+), 4 deletions(-)
> > >>
> > >> diff --git a/gcc/lra-assigns.cc b/gcc/lra-assigns.cc
> > >> index b8582dcafff..d2ebcfd5056 100644
> > >> --- a/gcc/lra-assigns.cc
> > >> +++ b/gcc/lra-assigns.cc
> > >> @@ -522,14 +522,15 @@ find_hard_regno_for_1 (int regno, int *cost, int
> > >> @@ try_only_hard_regno,
> > >> r2 != NULL;
> > >> r2 = r2->start_next)
> > >> {
> > >> - if (r2->regno >= lra_constraint_new_regno_start
> > >> + if (live_pseudos_reg_renumber[r2->regno] < 0
> > >> + && r2->regno >= lra_constraint_new_regno_start
> > >> && lra_reg_info[r2->regno].preferred_hard_regno1 >= 0
> > >> - && live_pseudos_reg_renumber[r2->regno] < 0
> > >> && rclass_intersect_p[regno_allocno_class_array[r2->regno]])
> > >> sparseset_set_bit (conflict_reload_and_inheritance_pseudos,
> > >> r2->regno);
> > >> - if (live_pseudos_reg_renumber[r2->regno] >= 0
> > >> - &&
> > >> rclass_intersect_p[regno_allocno_class_array[r2->regno]])
> > >> + else if (live_pseudos_reg_renumber[r2->regno] >= 0
> > >> + && rclass_intersect_p
> > >> +[regno_allocno_class_array[r2->regno]])
> > >> sparseset_set_bit (live_range_hard_reg_pseudos, r2->regno);
> > My biggest concern here would be r2->regno < 0 in the new code which could
> > cause an OOB array reference in the first condition of the test.
> >
> > Isn't that the point if the original ordering? Test that r2->regno is
> > reasonable before using it as an array index?
>
> Note the original code is
>
> if (r2->regno >= lra_constraint_new_regno_start
> ...
> if (live_pseudos_reg_renumber[r2->regno] >= 0
> ...
>
> so we are going to access live_pseudos_reg_renumber[r2->regno]
> independent on the r2->regno >= lra_constraint_new_regno_start check,
> so I don't think that's the point of the original ordering. Note
> I preserved the ordering with respect to other array accesses,
> the speedup seen is because we now have the
>
>
>if (live_pseudos_reg_renumber[r2->regno] < 0
>...
>else if (live_pseudos_reg_renumber[r2->regno] >= 0
> ...
>
> structure directly exposed which helps the compiler.
>
> I think the check on r2->regno is to decide whether to alter
> conflict_reload_and_inheritance_pseudos or
> live_range_hard_reg_pseudos (so it's also somewhat natural to check
> that first).
So - OK?
Thanks,
Richard.
RE: [PATCH v1] Mode-Switching: Fix SET_SRC ICE when only one operand
> maybe check that return_copy_pat is a SET instead?
You mean something like this? I tried this but I am not sure single_set is good
enough here, because it should be "narrow" than GET_RTX_LENGTH.
+ && single_set (return_copy)
Pan
-Original Message-
From: Richard Biener
Sent: Monday, August 7, 2023 9:14 PM
To: Li, Pan2
Cc: gcc-patches@gcc.gnu.org; juzhe.zh...@rivai.ai; kito.ch...@sifive.com; Wang,
Yanzhang ; jeffreya...@gmail.com
Subject: Re: [PATCH v1] Mode-Switching: Fix SET_SRC ICE when only one operand
On Mon, Aug 7, 2023 at 2:30 PM Pan Li via Gcc-patches
wrote:
>
> From: Pan Li
>
> In same cases, like gcc/testsuite/gcc.dg/pr78148.c in RISC-V, there will
> be only 1 operand when SET_SRC in create_pre_exit. For example as below.
>
> (insn 13 9 14 2 (clobber (reg/i:TI 10 a0))
> "gcc/testsuite/gcc.dg/pr78148.c":24:1 -1
> (expr_list:REG_UNUSED (reg/i:TI 10 a0)
> (nil)))
>
> Unfortunately, SET_SRC requires at least 2 operands and then Segment
> Fault here. This patch would like to fix this ICE by adding operand
> length check before SET_SRC.
>
> Signed-off-by: Pan Li
>
> gcc/ChangeLog:
>
> * mode-switching.cc (create_pre_exit): Add operand length check.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/riscv/mode-switch-ice-1.c: New test.
> ---
> gcc/mode-switching.cc | 2 ++
> .../gcc.target/riscv/mode-switch-ice-1.c | 22 +++
> 2 files changed, 24 insertions(+)
> create mode 100644 gcc/testsuite/gcc.target/riscv/mode-switch-ice-1.c
>
> diff --git a/gcc/mode-switching.cc b/gcc/mode-switching.cc
> index 64ae2bc29c3..cbf03c02159 100644
> --- a/gcc/mode-switching.cc
> +++ b/gcc/mode-switching.cc
> @@ -411,6 +411,8 @@ create_pre_exit (int n_entities, int *entity_map, const
> int *num_modes)
>conflict with address reloads. */
> if (copy_start >= ret_start
> && copy_start + copy_num <= ret_end
> + && GET_RTX_LENGTH (GET_CODE (return_copy_pat)) >=
> 2
> + /* SET_SRC requires at least 2 operands. */
maybe check that return_copy_pat is a SET instead?
> && OBJECT_P (SET_SRC (return_copy_pat)))
> forced_late_switch = true;
> break;
> diff --git a/gcc/testsuite/gcc.target/riscv/mode-switch-ice-1.c
> b/gcc/testsuite/gcc.target/riscv/mode-switch-ice-1.c
> new file mode 100644
> index 000..1b34a471904
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/riscv/mode-switch-ice-1.c
> @@ -0,0 +1,22 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O2" } */
> +
> +struct A { char e, f; };
> +
> +struct B
> +{
> + int g;
> + struct A h[4];
> +};
> +
> +extern void bar (int, int);
> +
> +struct B foo (void)
> +{
> + bar (2, 1);
> +}
> +
> +void baz ()
> +{
> + foo ();
> +}
> --
> 2.34.1
>
[PATCH] Use RPO order for sinking
The following makes us use RPO order instead of walking post-dominators.
This ensures we visit a block before any predecessors. I've seen
some extra sinking because of this in a larger testcase but failed
to reduce a smaller one (processing of post-dominator sons is unordered
so I failed to have "luck").
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
* tree-ssa-sink.cc (pass_sink_code::execute): Do not
calculate post-dominators. Calculate RPO on the inverted
graph and process blocks in that order.
---
gcc/tree-ssa-sink.cc | 19 +--
1 file changed, 5 insertions(+), 14 deletions(-)
diff --git a/gcc/tree-ssa-sink.cc b/gcc/tree-ssa-sink.cc
index 5cf9e737e84..6ad9d21589e 100644
--- a/gcc/tree-ssa-sink.cc
+++ b/gcc/tree-ssa-sink.cc
@@ -824,26 +824,17 @@ pass_sink_code::execute (function *fun)
connect_infinite_loops_to_exit ();
memset (&sink_stats, 0, sizeof (sink_stats));
calculate_dominance_info (CDI_DOMINATORS);
- calculate_dominance_info (CDI_POST_DOMINATORS);
virtual_operand_live vop_live;
- auto_vec worklist;
- worklist.quick_push (EXIT_BLOCK_PTR_FOR_FN (fun));
- do
-{
- basic_block bb = worklist.pop ();
- todo |= sink_code_in_bb (bb, vop_live);
- for (basic_block son = first_dom_son (CDI_POST_DOMINATORS, bb);
- son;
- son = next_dom_son (CDI_POST_DOMINATORS, son))
- worklist.safe_push (son);
-}
- while (!worklist.is_empty ());
+ int *rpo = XNEWVEC (int, n_basic_blocks_for_fn (cfun));
+ int n = inverted_rev_post_order_compute (fun, rpo);
+ for (int i = 0; i < n; ++i)
+todo |= sink_code_in_bb (BASIC_BLOCK_FOR_FN (fun, rpo[i]), vop_live);
+ free (rpo);
statistics_counter_event (fun, "Sunk statements", sink_stats.sunk);
statistics_counter_event (fun, "Commoned stores", sink_stats.commoned);
- free_dominance_info (CDI_POST_DOMINATORS);
remove_fake_exit_edges ();
loop_optimizer_finalize ();
--
2.35.3
[PATCH] tree-optimization/49955 - BB reduction with odd number of lanes
The following enhances BB reduction vectorization to support
vectorizing only a subset of the lanes, keeping the rest as
scalar ops. For now we try to make the number of lanes even
by leaving alone the "last" lane. That's because SLP discovery
with all lanes will fail too soon to get us any hint on which
lane to strip and likewise we don't know what vector modes the
target supports so restricting ourselves to power-of-two or
other cases isn't easy.
This is enough to get at the vectorization opportunity for the
testcase in the PR - albeit with the chosen lanes not optimal
but at least vectorizable.
Boostrap and regtest running on x86_64-unknown-linux-gnu.
I failed to write a small testcase because of that "optimal"
lane selection and PR110935.
PR tree-optimization/49955
* tree-vectorizer.h (_slp_instance::remain_stmts): New.
(SLP_INSTANCE_REMAIN_STMTS): Likewise.
* tree-vect-slp.cc (vect_free_slp_instance): Release
SLP_INSTANCE_REMAIN_STMTS.
(vect_build_slp_instance): Make the number of lanes of
a BB reduction even.
(vectorize_slp_instance_root_stmt): Handle unvectorized
defs of a BB reduction.
* gfortran.dg/vect/pr49955.f: New testcase.
---
gcc/testsuite/gfortran.dg/vect/pr49955.f | 38
gcc/tree-vect-slp.cc | 30 ++-
gcc/tree-vectorizer.h| 5
3 files changed, 72 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/gfortran.dg/vect/pr49955.f
diff --git a/gcc/testsuite/gfortran.dg/vect/pr49955.f
b/gcc/testsuite/gfortran.dg/vect/pr49955.f
new file mode 100644
index 000..a73cd5ada03
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/vect/pr49955.f
@@ -0,0 +1,38 @@
+! { dg-do compile }
+! { dg-additional-options "-ffast-math -fdump-tree-slp1" }
+
+ subroutine shell(nx,ny,nz,q,dt,cfl,dx,dy,dz,cfll,gm,Pr,Re)
+ implicit none
+ integer nx,ny,nz,i,j,k
+ real*8 cfl,dx,dy,dz,dt
+ real*8 gm,Re,Pr,cfll,t1,t2,t3,t4,t5,t6,t7,t8,mu
+ real*8 q(5,nx,ny,nz)
+
+ if (cfll.ge.cfl) cfll=cfl
+ t8=0.0d0
+
+ do k=1,nz
+ do j=1,ny
+do i=1,nx
+ t1=q(1,i,j,k)
+ t2=q(2,i,j,k)/t1
+ t3=q(3,i,j,k)/t1
+ t4=q(4,i,j,k)/t1
+ t5=(gm-1.0d0)*(q(5,i,j,k)-0.5d0*t1*(t2*t2+t3*t3+t4*t4))
+ t6=dSQRT(gm*t5/t1)
+ mu=gm*Pr*(gm*t5/t1)**0.75d0*2.0d0/Re/t1
+ t7=((dabs(t2)+t6)/dx+mu/dx**2)**2 +
+ 1((dabs(t3)+t6)/dy+mu/dy**2)**2 +
+ 2((dabs(t4)+t6)/dz+mu/dz**2)**2
+ t7=DSQRT(t7)
+ t8=max(t8,t7)
+enddo
+ enddo
+ enddo
+ dt=cfll / t8
+
+ return
+ end
+
+! We don't have an effective target for reduc_plus_scal optab support
+! { dg-final { scan-tree-dump ".REDUC_PLUS" "slp1" { target x86_64-*-* } } }
diff --git a/gcc/tree-vect-slp.cc b/gcc/tree-vect-slp.cc
index eab3dcd40ec..070ab3ff7ae 100644
--- a/gcc/tree-vect-slp.cc
+++ b/gcc/tree-vect-slp.cc
@@ -209,6 +209,7 @@ vect_free_slp_instance (slp_instance instance)
vect_free_slp_tree (SLP_INSTANCE_TREE (instance));
SLP_INSTANCE_LOADS (instance).release ();
SLP_INSTANCE_ROOT_STMTS (instance).release ();
+ SLP_INSTANCE_REMAIN_STMTS (instance).release ();
instance->subgraph_entries.release ();
instance->cost_vec.release ();
free (instance);
@@ -3128,6 +3129,16 @@ vect_build_slp_instance (vec_info *vinfo,
" %G", scalar_stmts[i]->stmt);
}
+ /* When a BB reduction doesn't have an even number of lanes
+ strip it down, treating the remaining lane as scalar.
+ ??? Selecting the optimal set of lanes to vectorize would be nice
+ but SLP build for all lanes will fail quickly because we think
+ we're going to need unrolling. */
+ auto_vec remain;
+ if (kind == slp_inst_kind_bb_reduc
+ && (scalar_stmts.length () & 1))
+remain.safe_push (scalar_stmts.pop ());
+
/* Build the tree for the SLP instance. */
unsigned int group_size = scalar_stmts.length ();
bool *matches = XALLOCAVEC (bool, group_size);
@@ -3175,6 +3186,10 @@ vect_build_slp_instance (vec_info *vinfo,
SLP_INSTANCE_UNROLLING_FACTOR (new_instance) = unrolling_factor;
SLP_INSTANCE_LOADS (new_instance) = vNULL;
SLP_INSTANCE_ROOT_STMTS (new_instance) = root_stmt_infos;
+ if (!remain.is_empty ())
+ SLP_INSTANCE_REMAIN_STMTS (new_instance) = remain.copy ();
+ else
+ SLP_INSTANCE_REMAIN_STMTS (new_instance) = vNULL;
SLP_INSTANCE_KIND (new_instance) = kind;
new_instance->reduc_phis = NULL;
new_instance->cost_vec = vNULL;
@@ -9138,7 +9153,20 @@ vectorize_slp_instance_root_stmt (slp_tree node,
slp_instance instance)
gcc_unreachable ();
tree scalar_def = gimple_build (&epilogue, as_combined_fn (reduc_fn),
[PATCH] rtl-optimization/110869 Fix tests cmp-mem-const-*.c for sparc
This fixes the rather new tests cmp-mem-const-{1,2,3,4,5,6}.c for sparc.
For -1 and -2 we need at least optimization level 2 on sparc. For the
sake of homogeneity, change all test cases to -O2. For -3 and -4 we do
not end up with a comparison of memory and a constant, and finally for
-5 and -6 the constants are reduced by a prior optimization which means
there is nothing left to do. Thus excluding sparc from those tests.
Ok for mainline?
gcc/testsuite/ChangeLog:
PR rtl-optimization/110869
* gcc.dg/cmp-mem-const-1.c: Use optimization level 2.
* gcc.dg/cmp-mem-const-2.c: Dito.
* gcc.dg/cmp-mem-const-3.c: Exclude sparc from this test.
* gcc.dg/cmp-mem-const-4.c: Dito.
* gcc.dg/cmp-mem-const-5.c: Dito.
* gcc.dg/cmp-mem-const-6.c: Dito.
---
gcc/testsuite/gcc.dg/cmp-mem-const-1.c | 2 +-
gcc/testsuite/gcc.dg/cmp-mem-const-2.c | 2 +-
gcc/testsuite/gcc.dg/cmp-mem-const-3.c | 6 --
gcc/testsuite/gcc.dg/cmp-mem-const-4.c | 6 --
gcc/testsuite/gcc.dg/cmp-mem-const-5.c | 6 --
gcc/testsuite/gcc.dg/cmp-mem-const-6.c | 6 --
6 files changed, 18 insertions(+), 10 deletions(-)
diff --git a/gcc/testsuite/gcc.dg/cmp-mem-const-1.c
b/gcc/testsuite/gcc.dg/cmp-mem-const-1.c
index 4f21a1ade4a..0b0e7331354 100644
--- a/gcc/testsuite/gcc.dg/cmp-mem-const-1.c
+++ b/gcc/testsuite/gcc.dg/cmp-mem-const-1.c
@@ -1,5 +1,5 @@
/* { dg-do compile { target { lp64 } } } */
-/* { dg-options "-O1 -fdump-rtl-combine-details" } */
+/* { dg-options "-O2 -fdump-rtl-combine-details" } */
/* { dg-final { scan-rtl-dump "narrow comparison from mode .I to QI" "combine"
} } */
typedef __UINT64_TYPE__ uint64_t;
diff --git a/gcc/testsuite/gcc.dg/cmp-mem-const-2.c
b/gcc/testsuite/gcc.dg/cmp-mem-const-2.c
index 7b722951594..8022137a8ec 100644
--- a/gcc/testsuite/gcc.dg/cmp-mem-const-2.c
+++ b/gcc/testsuite/gcc.dg/cmp-mem-const-2.c
@@ -1,5 +1,5 @@
/* { dg-do compile { target { lp64 } } } */
-/* { dg-options "-O1 -fdump-rtl-combine-details" } */
+/* { dg-options "-O2 -fdump-rtl-combine-details" } */
/* { dg-final { scan-rtl-dump "narrow comparison from mode .I to QI" "combine"
} } */
typedef __UINT64_TYPE__ uint64_t;
diff --git a/gcc/testsuite/gcc.dg/cmp-mem-const-3.c
b/gcc/testsuite/gcc.dg/cmp-mem-const-3.c
index ed5059d3807..c60ecdb4026 100644
--- a/gcc/testsuite/gcc.dg/cmp-mem-const-3.c
+++ b/gcc/testsuite/gcc.dg/cmp-mem-const-3.c
@@ -1,5 +1,7 @@
-/* { dg-do compile { target { lp64 } } } */
-/* { dg-options "-O1 -fdump-rtl-combine-details" } */
+/* { dg-do compile { target { lp64 && { ! sparc*-*-* } } } } */
+/* Excluding sparc since there we do not end up with a comparison of memory and
+ a constant which means that the optimization is not applicable. */
+/* { dg-options "-O2 -fdump-rtl-combine-details" } */
/* { dg-final { scan-rtl-dump "narrow comparison from mode .I to HI" "combine"
} } */
typedef __UINT64_TYPE__ uint64_t;
diff --git a/gcc/testsuite/gcc.dg/cmp-mem-const-4.c
b/gcc/testsuite/gcc.dg/cmp-mem-const-4.c
index 23e83372bee..7aa403d76d9 100644
--- a/gcc/testsuite/gcc.dg/cmp-mem-const-4.c
+++ b/gcc/testsuite/gcc.dg/cmp-mem-const-4.c
@@ -1,5 +1,7 @@
-/* { dg-do compile { target { lp64 } } } */
-/* { dg-options "-O1 -fdump-rtl-combine-details" } */
+/* { dg-do compile { target { lp64 && { ! sparc*-*-* } } } } */
+/* Excluding sparc since there we do not end up with a comparison of memory and
+ a constant which means that the optimization is not applicable. */
+/* { dg-options "-O2 -fdump-rtl-combine-details" } */
/* { dg-final { scan-rtl-dump "narrow comparison from mode .I to HI" "combine"
} } */
typedef __UINT64_TYPE__ uint64_t;
diff --git a/gcc/testsuite/gcc.dg/cmp-mem-const-5.c
b/gcc/testsuite/gcc.dg/cmp-mem-const-5.c
index d266896a25e..4316dcb5605 100644
--- a/gcc/testsuite/gcc.dg/cmp-mem-const-5.c
+++ b/gcc/testsuite/gcc.dg/cmp-mem-const-5.c
@@ -1,5 +1,7 @@
-/* { dg-do compile { target { lp64 } && ! target { sparc*-*-* } } } */
-/* { dg-options "-O1 -fdump-rtl-combine-details" } */
+/* { dg-do compile { target { lp64 && { ! sparc*-*-* } } } } */
+/* Excluding sparc since there a prior optimization already reduced the
+ constant, i.e., nothing left for us. */
+/* { dg-options "-O2 -fdump-rtl-combine-details" } */
/* { dg-final { scan-rtl-dump "narrow comparison from mode .I to SI" "combine"
} } */
typedef __UINT64_TYPE__ uint64_t;
diff --git a/gcc/testsuite/gcc.dg/cmp-mem-const-6.c
b/gcc/testsuite/gcc.dg/cmp-mem-const-6.c
index 68d7a9d0265..d9046af79eb 100644
--- a/gcc/testsuite/gcc.dg/cmp-mem-const-6.c
+++ b/gcc/testsuite/gcc.dg/cmp-mem-const-6.c
@@ -1,5 +1,7 @@
-/* { dg-do compile { target { lp64 } && ! target { sparc*-*-* } } } */
-/* { dg-options "-O1 -fdump-rtl-combine-details" } */
+/* { dg-do compile { target { lp64 && { ! sparc*-*-* } } } } */
+/* Excluding sparc since there a prior optimization already reduced the
+ constant, i.e., nothing left for us. */
+/* { dg-options "-O2 -fdump-rtl-combine-details" } */
[PATCH, OpenACC 2.7, v2] readonly modifier support in front-ends
Hi Thomas, Tobias,
here's the updated v2 of the readonly modifier front-end patch.
On 2023/7/20 11:08 PM, Tobias Burnus wrote:
>>> +++ b/gcc/c/c-parser.cc
>>> @@ -14059,7 +14059,8 @@ c_parser_omp_variable_list (c_parser *parser,
>>>
>>> static tree
>>> c_parser_omp_var_list_parens (c_parser *parser, enum omp_clause_code kind,
>>> - tree list, bool allow_deref = false)
>>> + tree list, bool allow_deref = false,
>>> + bool *readonly = NULL)
>>> ...
>> Instead of doing this in 'c_parser_omp_var_list_parens', I think it's
>> clearer to have this special 'readonly :' parsing logic in the two places
>> where it's used.
> I concur. The same issue also occurred for OpenMP's
> c_parser_omp_clause_to, and c_parser_omp_clause_from and the 'present'
> modifier. For it, I created a combined function but the main reason for
> that is that OpenMP also permits more modifiers (like 'iterators'),
> which would cause more duplication of code ('iterator' is not yet
> supported).
>
> For something as simple to parse as this modifier, I would just do it at
> the two places – as Thomas suggested.
Okay, I've changed the C/C++ parser parts to have the parsing logic directly
added.
>>> +++ b/gcc/fortran/gfortran.h
>>> @@ -1360,7 +1360,11 @@ typedef struct gfc_omp_namelist
>>> {
>>> gfc_omp_reduction_op reduction_op;
>>> gfc_omp_depend_doacross_op depend_doacross_op;
>>> - gfc_omp_map_op map_op;
>>> + struct
>>> +{
>>> + ENUM_BITFIELD (gfc_omp_map_op) map_op:8;
>>> + bool readonly;
>>> +};
>>> gfc_expr *align;
>>> struct
>>>{
>> [...] Thus, the above looks good to me.
> I concur but I wonder whether it would be cleaner to name the struct;
> this makes it also more obvious what belongs together in the union.
>
> Namely, naming the struct 'map' and then changing the 45 users from
> 'u.map_op' to 'u.map.op' and the new 'u.readonly' to 'u.map.readonly'. –
> this seems to be cleaner.
I've adjusted 'u.map' to be a named struct now, and updated the references.
>> + if (gfc_match ("readonly :") == MATCH_YES)
>> I note this one does not have a space after ':' in 'gfc_match', but the
>> one above in 'gfc_match_omp_clauses' does. I don't know off-hand if that
>> makes a difference in parsing -- probably not, as all of
>> 'gcc/fortran/openmp.cc' generally doesn't seem to be very consistent
>> about these two variants?
> It *does* make a difference. And for obvious reasons. You don't want to
> permit:
>
>!$acc kernels asnyccopy(a)
>
> but require at least one space (or comma) between "async" and "copy"..
> (In fixed form Fortran, it would be fine - as would be "!$acc k e nelsasy nc
> co p y(a)".)
>
> A " " matches zero or more whitespaces, but with gfc_match_space you can find
> out
> whether there was whitespace or not.
Okay, made sure both are 'gfc_match ("readonly : ")'. Thanks for catching that,
didn't
realize that space was significant.
>>> +++ b/gcc/tree.h
>>> @@ -1813,6 +1813,14 @@ class auto_suppress_location_wrappers
>>> #define OMP_CLAUSE_MAP_DECL_MAKE_ADDRESSABLE(NODE) \
>>> (OMP_CLAUSE_SUBCODE_CHECK (NODE, OMP_CLAUSE_MAP)->base.addressable_flag)
>>>
>>> +/* Nonzero if OpenACC 'readonly' modifier set, used for 'copyin'. */
>>> +#define OMP_CLAUSE_MAP_READONLY(NODE) \
>>> + TREE_READONLY (OMP_CLAUSE_SUBCODE_CHECK (NODE, OMP_CLAUSE_MAP))
>>> +
>>> +/* Same as above, for use in OpenACC cache directives. */
>>> +#define OMP_CLAUSE__CACHE__READONLY(NODE) \
>>> + TREE_READONLY (OMP_CLAUSE_SUBCODE_CHECK (NODE, OMP_CLAUSE__CACHE_))
>> I'm not sure if these special accessor functions are actually useful, or
>> we should just directly use 'TREE_READONLY' instead? We're only using
>> them in contexts where it's clear that the 'OMP_CLAUSE_SUBCODE_CHECK' is
>> satisfied, for example.
> I find directly using TREE_READONLY confusing.
FWIW, I've changed to use TREE_NOTHROW instead, if it can give a better sense
of safety :P
I think there's a misunderstanding here anyways: we are not relying on a DECL
marked
TREE_READONLY here. We merely need the OMP_CLAUSE_MAP to be marked as
OMP_CLAUSE_MAP_READONLY == 1.
The other points-to patch then (also in front-ends) take the
OMP_CLAUSE_MAP_READONLY
to mark the clauses of "base-pointers of array-sections" as
OMP_CLAUSE_MAP_POINTS_TO_READONLY,
and later this gradually gets relayed to alias oracle routines in
tree-ssa-alias.cc
Re-tested this v2 patch on powerpc64le-linux/nvptx. Okay for trunk?
Thanks,
Chung-Lin
2023-08-07 Chung-Lin Tang
gcc/c/ChangeLog:
* c-parser.cc (c_parser_oacc_data_clause): Add parsing support for
'readonly' modifier, set OMP_CLAUSE_MAP_READONLY if readonly modifier
found, update comments.
(c_parser_oacc_cache): Add parsing support for 'readonly' modifier,
set OMP_CLAUSE__CACHE__READONLY if readonly modifier found, update
comments.
[V2][PATCH] gcc-14/changes.html: Deprecate a GCC C extension on flexible array members.
Hi, This is the 2nd version of the patch. Comparing to the 1st version, the only change is to address Richard's comment on refering a warning option for diagnosing deprecated behavior. Okay for committing? thanks. Qing == *htdocs/gcc-14/changes.html (Caveats): Add notice about deprecating a C extension about flexible array members. --- htdocs/gcc-14/changes.html | 13 - 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html index dad1ba53..eae25f1a 100644 --- a/htdocs/gcc-14/changes.html +++ b/htdocs/gcc-14/changes.html @@ -30,7 +30,18 @@ a work-in-progress. Caveats - ... + C: + Support for the GCC extension, a structure containing a C99 flexible array + member, or a union containing such a structure, is not the last field of + another structure, is deprecated. Refer to + https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html";> + Zero Length Arrays. + Any code relying on this extension should be modifed to ensure that + C99 flexible array members only end up at the ends of structures. + Please use the warning option + https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wflex-array-member-not-at-end";>-Wflex-array-member-not-at-end to + identify all such cases in the source code and modify them. + -- 2.31.1
[PATCH v4] Implement new RTL optimizations pass: fold-mem-offsets.
This is a new RTL pass that tries to optimize memory offset calculations
by moving them from add immediate instructions to the memory loads/stores.
For example it can transform this:
addi t4,sp,16
add t2,a6,t4
shl t3,t2,1
ld a2,0(t3)
addi a2,1
sd a2,8(t2)
into the following (one instruction less):
add t2,a6,sp
shl t3,t2,1
ld a2,32(t3)
addi a2,1
sd a2,24(t2)
Although there are places where this is done already, this pass is more
powerful and can handle the more difficult cases that are currently not
optimized. Also, it runs late enough and can optimize away unnecessary
stack pointer calculations.
gcc/ChangeLog:
* Makefile.in: Add fold-mem-offsets.o.
* passes.def: Schedule a new pass.
* tree-pass.h (make_pass_fold_mem_offsets): Declare.
* common.opt: New options.
* doc/invoke.texi: Document new option.
* fold-mem-offsets.cc: New file.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/fold-mem-offsets-1.c: New test.
* gcc.target/riscv/fold-mem-offsets-2.c: New test.
* gcc.target/riscv/fold-mem-offsets-3.c: New test.
Signed-off-by: Manolis Tsamis
---
Changes in v4:
- Add DF_EQ_NOTES flag to avoid incorrect state in notes.
- Remove fold_mem_offsets_driver and enum fold_mem_phase.
- Call recog when patching offsets in do_commit_offset.
- Restore INSN_CODE after modifying insn in do_check_validity.
Changes in v3:
- Added propagation for more codes:
sub, neg, mul.
- Added folding / elimination for sub and
const int moves.
- For the validity check of the generated addresses
also test memory_address_addr_space_p.
- Replaced GEN_INT with gen_int_mode.
- Replaced some bitmap_head with auto_bitmap.
- Refactor each phase into own function for readability.
- Add dump details.
- Replace rtx iteration with reg_mentioned_p.
- Return early for codes that we can't propagate through.
Changes in v2:
- Made the pass target-independant instead of RISCV specific.
- Fixed a number of bugs.
- Add code to handle more ADD patterns as found
in other targets (x86, aarch64).
- Improved naming and comments.
- Fixed bitmap memory leak.
gcc/Makefile.in | 1 +
gcc/common.opt| 4 +
gcc/doc/invoke.texi | 8 +
gcc/fold-mem-offsets.cc | 725 ++
gcc/passes.def| 1 +
.../gcc.target/riscv/fold-mem-offsets-1.c | 16 +
.../gcc.target/riscv/fold-mem-offsets-2.c | 24 +
.../gcc.target/riscv/fold-mem-offsets-3.c | 17 +
gcc/tree-pass.h | 1 +
9 files changed, 797 insertions(+)
create mode 100644 gcc/fold-mem-offsets.cc
create mode 100644 gcc/testsuite/gcc.target/riscv/fold-mem-offsets-1.c
create mode 100644 gcc/testsuite/gcc.target/riscv/fold-mem-offsets-2.c
create mode 100644 gcc/testsuite/gcc.target/riscv/fold-mem-offsets-3.c
diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index e99628cec07..d717e90bc44 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -1431,6 +1431,7 @@ OBJS = \
fixed-value.o \
fold-const.o \
fold-const-call.o \
+ fold-mem-offsets.o \
function.o \
function-abi.o \
function-tests.o \
diff --git a/gcc/common.opt b/gcc/common.opt
index 0888c15b88f..5f3d3e9706f 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -1248,6 +1248,10 @@ fcprop-registers
Common Var(flag_cprop_registers) Optimization
Perform a register copy-propagation optimization pass.
+ffold-mem-offsets
+Target Bool Var(flag_fold_mem_offsets) Init(1)
+Fold instructions calculating memory offsets to the memory access instruction
if possible.
+
fcrossjumping
Common Var(flag_crossjumping) Optimization
Perform cross-jumping optimization.
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 674f956f4b8..30974309e9b 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -540,6 +540,7 @@ Objective-C and Objective-C++ Dialects}.
-fauto-inc-dec -fbranch-probabilities
-fcaller-saves
-fcombine-stack-adjustments -fconserve-stack
+-ffold-mem-offsets
-fcompare-elim -fcprop-registers -fcrossjumping
-fcse-follow-jumps -fcse-skip-blocks -fcx-fortran-rules
-fcx-limited-range
@@ -14314,6 +14315,13 @@ the comparison operation before register allocation is
complete.
Enabled at levels @option{-O1}, @option{-O2}, @option{-O3}, @option{-Os}.
+@opindex ffold-mem-offsets
+@item -ffold-mem-offsets
+@itemx -fno-fold-mem-offsets
+Try to eliminate add instructions by folding them in memory loads/stores.
+
+Enabled at levels @option{-O2}, @option{-O3}.
+
@opindex fcprop-registers
@item -fcprop-registers
After register allocation and post-register allocation instruction splitting,
diff --git a/gcc/fo
Re: [PATCH v3] Implement new RTL optimizations pass: fold-mem-offsets.
I have sent out a new v4 of this
(https://gcc.gnu.org/pipermail/gcc-patches/2023-August/626502.html).
In the new version I both restore the INSN_CODE as mentioned here and
I also call recog when I commit the offset change (because there may
be a change from no offset to some offsets).
I have also removed the driver function as per Vineet's suggestion.
Last thing I have fixed a nasty bug with REG_EQUIV's that resulted in
failing bootstrap on AArch64.
The offending sequence looked like this (in 'simplified RTX'):
(set (reg/f:DI 3 x3)
(plus:DI (reg/f:DI 2 x2)
(const_int 8 [0x8])))
(set (reg/f:DI 19 x19)
(plus:DI (reg/f:DI 3 x3)
(reg:DI 19 x19)))
...
(set (reg:TI 2 x2)
(mem:TI (reg/f:DI 0 x0)))
(expr_list:REG_DEAD (reg/f:DI 0 x0)
(expr_list:REG_EQUIV (mem:TI (reg/f:DI 19 x19))
(nil)))
(set (mem:TI (reg/f:DI 19 x19))
(reg:TI 2 x2))
(expr_list:REG_DEAD (reg/f:DI 19 x19)
(expr_list:REG_DEAD (reg:TI 2 x2)
(nil)))
Were the first instruction (x3 = x2 + 8) was folded in the address
calculation of the last one, resulting in (mem:TI (plus:DI (reg/f:DI
19 x19) (const_int 8 [0x8])), but then the previous REG_EQUIV was
incorrect due to the modified runtime value of x19.
For now I opted to treat REG_EQ/EQUIV notes as uses that we cannot
handle, so if any of them are involved we don't fold offsets. Although
it would may be possible to improve this in the future, I think it's
fine for now and the reduction of folded insns is a small %.
I have tested v4 with a number of benchmarks and large projects on
x64, aarch64 and riscv64 without observing any issues. The x86
testsuite issue still exists as I don't have a satisfactory solution
to it yet.
Any feedback for the changes is appreciated!
Thanks,
Manolis
On Fri, Jul 21, 2023 at 12:59 AM Jeff Law wrote:
>
>
>
> On 7/20/23 00:18, Vineet Gupta wrote:
> >
> >
> > On 7/18/23 21:31, Jeff Law via Gcc-patches wrote:
> >>>
> >>> In a run with -fno-fold-mem-offsets, the same insn 93 is successfully
> >>> grok'ed by cprop_hardreg,
> >>>
> >>> | (insn 93 337 522 11 (set (mem/c:DF (plus:DI (reg/f:DI 2 sp)
> >>> |(const_int 8 [0x8])) [4 %sfp+-8 S8 A64])
> >>> |(const_double:DF 0.0 [0x0.0p+0])) "sff.i":23:11 190
> >>> {*movdf_hardfloat_rv64}
> >>> ^^^
> >>> | (expr_list:REG_EQUAL (const_double:DF 0.0 [0x0.0p+0])
> >>> |(nil)))
> >>>
> >>> P.S. I wonder if it is a good idea in general to call recog() post
> >>> reload since the insn could be changed sufficiently to no longer
> >>> match the md patterns. Of course I don't know the answer.
> >> If this ever causes a problem, it's a backend bug. It's that simple.
> >>
> >> Conceptually it should always be safe to set INSN_CODE to -1 for any
> >> insn.
> >
> > Sure the -1 should be handled, but are you implying that f-mo- will
> > always generate a valid combination and recog() failing is simply a bug
> > in backend and/or f-m-o. If not, the -1 setting can potentially trigger
> > an ICE in future.
> A recog failure after setting INSN_CODE to -1 would always be an
> indicator of a target bug at the point where f-m-o runs.
>
> In that would be generally true as well. There are some very obscure
> exceptions and those exceptions are for narrow periods of time.
>
>
>
> >
> >>
> >> Odds are for this specific case in the RV backend, we just need a
> >> constraint to store 0.0 into a memory location. That can actually be
> >> implemented as a store from x0 since 0.0 has the bit pattern 0x0. This
> >> is probably a good thing to expose anyway as an optimization and can
> >> move forward independently of the f-m-o patch.
> >
> > I call dibs on this :-) Seems like an interesting little side project.
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110748
> It's yours :-)
>
> jeff
[PATCH] VR-VALUES [PR28794]: optimize compare assignments also
This patch fixes the oldish (2006) bug where VRP was not
optimizing the comparison for assignments while handling
them for GIMPLE_COND only.
It just happens to also solves PR 103281 due to allowing
to optimize `c < 1` to `c == 0` and then we get
`(c == 0) == c` (which was handled by r14-2501-g285c9d04).
OK? Bootstrapped and tested on x86_64-linux-gnu with no
regressions.
PR tree-optmization/103281
PR tree-optimization/28794
gcc/ChangeLog:
* vr-values.cc (simplify_using_ranges::simplify_cond_using_ranges_1):
Split out
majority to ...
(simplify_using_ranges::simplify_compare_using_ranges_1): Here.
(simplify_using_ranges::simplify_casted_cond): Rename to ...
(simplify_using_ranges::simplify_casted_compare): This
and change arguments to take op0 and op1.
(simplify_using_ranges::simplify_compare_assign_using_ranges_1): New
method.
(simplify_using_ranges::simplify): For tcc_comparison assignments call
simplify_compare_assign_using_ranges_1.
* vr-values.h (simplify_using_ranges): Add
new methods, simplify_compare_using_ranges_1 and
simplify_compare_assign_using_ranges_1.
Rename simplify_casted_cond and simplify_casted_compare and
update argument types.
gcc/testsuite/ChangeLog:
* gcc.dg/tree-ssa/pr103281-1.c: New test.
* gcc.dg/tree-ssa/vrp-compare-1.c: New test.
---
gcc/testsuite/gcc.dg/tree-ssa/pr103281-1.c| 19 +++
gcc/testsuite/gcc.dg/tree-ssa/vrp-compare-1.c | 13 ++
gcc/vr-values.cc | 160 +++---
gcc/vr-values.h | 4 +-
4 files changed, 134 insertions(+), 62 deletions(-)
create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/pr103281-1.c
create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/vrp-compare-1.c
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr103281-1.c
b/gcc/testsuite/gcc.dg/tree-ssa/pr103281-1.c
new file mode 100644
index 000..09964d0b46b
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/pr103281-1.c
@@ -0,0 +1,19 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-optimized" } */
+/* PR tree-optmization/103281 */
+
+void foo(void);
+
+static unsigned b;
+
+int main() {
+ for (; b < 3; b++) {
+char c = b;
+char a = c ? c : c << 1;
+if (!(a < 1 ^ b))
+ foo();
+ }
+}
+
+/* the call to foo should be optimized away. */
+/* { dg-final { scan-tree-dump-not "foo " "optimized" } } */
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/vrp-compare-1.c
b/gcc/testsuite/gcc.dg/tree-ssa/vrp-compare-1.c
new file mode 100644
index 000..9889cf34706
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/vrp-compare-1.c
@@ -0,0 +1,13 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-evrp-details" } */
+/* PR tree-optimization/28794 */
+
+void g(int);
+void f1(int x)
+{
+ if (x < 0) return;
+ g(x>0);
+}
+
+/* `x > 0` should be optimized to just `x != 0` */
+/* { dg-final { scan-tree-dump-times "Simplified relational" 1 "evrp" } } */
diff --git a/gcc/vr-values.cc b/gcc/vr-values.cc
index ac4a83c6097..a4fddd62841 100644
--- a/gcc/vr-values.cc
+++ b/gcc/vr-values.cc
@@ -1139,6 +1139,87 @@ simplify_using_ranges::simplify_cond_using_ranges_1
(gcond *stmt)
if (fold_cond (stmt))
return true;
+ if (simplify_compare_using_ranges_1 (cond_code, op0, op1, stmt))
+{
+ if (dump_file)
+ {
+ fprintf (dump_file, "Simplified relational ");
+ print_gimple_stmt (dump_file, stmt, 0);
+ fprintf (dump_file, " into ");
+ }
+
+ gimple_cond_set_code (stmt, cond_code);
+ gimple_cond_set_lhs (stmt, op0);
+ gimple_cond_set_rhs (stmt, op1);
+
+ update_stmt (stmt);
+
+ if (dump_file)
+ {
+ print_gimple_stmt (dump_file, stmt, 0);
+ fprintf (dump_file, "\n");
+ }
+ return true;
+}
+ return false;
+}
+
+/* Like simplify_cond_using_ranges_1 but for assignments rather
+ than GIMPLE_COND. */
+
+bool
+simplify_using_ranges::simplify_compare_assign_using_ranges_1
+ (gimple_stmt_iterator *gsi,
+gimple *stmt)
+{
+ enum tree_code code = gimple_assign_rhs_code (stmt);
+ tree op0 = gimple_assign_rhs1 (stmt);
+ tree op1 = gimple_assign_rhs2 (stmt);
+ gcc_assert (TREE_CODE_CLASS (code) == tcc_comparison);
+ bool happened = false;
+
+ if (simplify_compare_using_ranges_1 (code, op0, op1, stmt))
+{
+ if (dump_file)
+ {
+ fprintf (dump_file, "Simplified relational ");
+ print_gimple_stmt (dump_file, stmt, 0);
+ fprintf (dump_file, " into ");
+ }
+
+ gimple_assign_set_rhs_code (stmt, code);
+ gimple_assign_set_rhs1 (stmt, op0);
+ gimple_assign_set_rhs2 (stmt, op1);
+
+ update_stmt (stmt);
+
+ if (dump_file)
+ {
+ print_gimple_stmt (dump_file, stmt, 0);
+ fprintf (dump_file, "\n");
+ }
+ happened = tru
[committed] [RISC-V] Handle more cases in riscv_expand_conditional_move
As I've mentioned in the main zicond thread, Ventana has had patches
that support more cases by first emitting a suitable scc instruction
essentially as a canonicalization step of the condition for zicond.
For example if we have
(set (target) (if_then_else (op (reg1) (reg2))
(true_value)
(false_value)))
The two register comparison isn't handled by zicond directly. But we
can generate something like this instead
(set (temp) (op (reg1) (reg2)))
(set (target) (if_then_else (op (temp) (const_int 0))
(true_value)
(false_value)
Then let the remaining code from Xiao handle the true_value/false_value
to make sure it's zicond compatible.
This is primarily Raphael's work. My involvement has been mostly to
move it from its original location (in the .md file) into the expander
function and fix minor problems with the FP case.
Committed to the trunk,
Jeff
commit 8ae83274d8cc60547e8c92a41a4f4716b045f57a
Author: Raphael Zinsly
Date: Mon Aug 7 10:26:24 2023 -0400
[committed] [RISC-V] Handle more cases in riscv_expand_conditional_move
As I've mentioned in the main zicond thread, Ventana has had patches
that support more cases by first emitting a suitable scc instruction
essentially as a canonicalization step of the condition for zicond.
For example if we have
(set (target) (if_then_else (op (reg1) (reg2))
(true_value)
(false_value)))
The two register comparison isn't handled by zicond directly. But we
can generate something like this instead
(set (temp) (op (reg1) (reg2)))
(set (target) (if_then_else (op (temp) (const_int 0))
(true_value)
(false_value)
Then let the remaining code from Xiao handle the true_value/false_value
to make sure it's zicond compatible.
This is primarily Raphael's work. My involvement has been mostly to
move it from its original location (in the .md file) into the expander
function and fix minor problems with the FP case.
gcc/
* config/riscv/riscv.cc (riscv_expand_int_scc): Add invert_ptr
as an argument and pass it to riscv_emit_int_order_test.
(riscv_expand_conditional_move): Handle cases where the condition
is not EQ/NE or the second argument to the conditional is not
(const_int 0).
* config/riscv/riscv-protos.h (riscv_expand_int_scc): Update
prototype.
Co-authored-by: Jeff Law
diff --git a/gcc/config/riscv/riscv-protos.h b/gcc/config/riscv/riscv-protos.h
index 324991e2619..53b87cb28d3 100644
--- a/gcc/config/riscv/riscv-protos.h
+++ b/gcc/config/riscv/riscv-protos.h
@@ -103,7 +103,7 @@ extern const char *riscv_output_move (rtx, rtx);
extern const char *riscv_output_return ();
#ifdef RTX_CODE
-extern void riscv_expand_int_scc (rtx, enum rtx_code, rtx, rtx);
+extern void riscv_expand_int_scc (rtx, enum rtx_code, rtx, rtx, bool
*invert_ptr = 0);
extern void riscv_expand_float_scc (rtx, enum rtx_code, rtx, rtx);
extern void riscv_expand_conditional_branch (rtx, enum rtx_code, rtx, rtx);
extern rtx riscv_emit_binary (enum rtx_code code, rtx dest, rtx x, rtx y);
diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index 7728cd34569..279304afc19 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -3499,7 +3499,7 @@ riscv_emit_float_compare (enum rtx_code *code, rtx *op0,
rtx *op1)
/* CODE-compare OP0 and OP1. Store the result in TARGET. */
void
-riscv_expand_int_scc (rtx target, enum rtx_code code, rtx op0, rtx op1)
+riscv_expand_int_scc (rtx target, enum rtx_code code, rtx op0, rtx op1, bool
*invert_ptr)
{
riscv_extend_comparands (code, &op0, &op1);
op0 = force_reg (word_mode, op0);
@@ -3510,7 +3510,7 @@ riscv_expand_int_scc (rtx target, enum rtx_code code, rtx
op0, rtx op1)
riscv_emit_binary (code, target, zie, const0_rtx);
}
else
-riscv_emit_int_order_test (code, 0, target, op0, op1);
+riscv_emit_int_order_test (code, invert_ptr, target, op0, op1);
}
/* Like riscv_expand_int_scc, but for floating-point comparisons. */
@@ -3576,7 +3576,6 @@ riscv_expand_conditional_move (rtx dest, rtx op, rtx
cons, rtx alt)
return true;
}
else if (TARGET_ZICOND
- && (code == EQ || code == NE)
&& GET_MODE_CLASS (mode) == MODE_INT)
{
/* The comparison must be comparing WORD_MODE objects. We must
@@ -3586,6 +3585,45 @@ riscv_expand_conditional_move (rtx dest, rtx op, rtx
cons, rtx alt)
if (GET_MODE (op0) != word_mode || GET_MODE (op1) != word_mode)
return false;
+ /* Canonicalize the comparison. It must be an equality comparison
+against 0. If it isn't, then emit an SCC instruction so that
+
Re: [RFC PATCH] i386: Do not sanitize upper part of V2SFmode reg with -fno-trapping-math [PR110832]
On Mon, Jul 31, 2023 at 11:40 AM Richard Biener wrote:
>
> On Sun, 30 Jul 2023, Uros Bizjak wrote:
>
> > Also introduce -m[no-]mmxfp-with-sse option to disable trapping V2SF
> > named patterns in order to avoid generation of partial vector V4SFmode
> > trapping instructions.
> >
> > The new option is enabled by default, because even with sanitization,
> > a small but consistent speed up of 2 to 3% with Polyhedron capacita
> > benchmark can be achieved vs. scalar code.
> >
> > Using -fno-trapping-math improves Polyhedron capacita runtime 8 to 9%
> > vs. scalar code. This is what clang does by default, as it defaults
> > to -fno-trapping-math.
>
> I like the new option, note you lack invoke.texi documentation where
> I'd also elaborate a bit on the interaction with -fno-trapping-math
> and the possible performance impact then NaNs or denormals leak
> into the upper halves and cross-reference -mdaz-ftz.
The attached doc patch is invoke.texi entry for -mmmxfp-with-sse
option. It is written in a way to also cover half-float vectors. WDYT?
Uros.
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index fa765d5a0dd..99093172abe 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -1417,6 +1417,7 @@ See RS/6000 and PowerPC Options.
-mcld -mcx16 -msahf -mmovbe -mcrc32 -mmwait
-mrecip -mrecip=@var{opt}
-mvzeroupper -mprefer-avx128 -mprefer-vector-width=@var{opt}
+-mmmxfp-with-sse
-mmove-max=@var{bits} -mstore-max=@var{bits}
-mmmx -msse -msse2 -msse3 -mssse3 -msse4.1 -msse4.2 -msse4 -mavx
-mavx2 -mavx512f -mavx512pf -mavx512er -mavx512cd -mavx512vl
@@ -33708,6 +33709,22 @@ This option instructs GCC to use 128-bit AVX
instructions instead of
This option instructs GCC to use @var{opt}-bit vector width in instructions
instead of default on the selected platform.
+@opindex -mmmxfp-with-sse
+@item -mmmxfp-with-sse
+This option enables GCC to generate trapping floating-point operations on
+partial vectors, where vector elements reside in the low part of the 128-bit
+SSE register. Unless @option{-fno-trapping-math} is specified, the compiler
+guarantees correct trapping behavior by sanitizing all input operands to
+have zeroes in the upper part of the vector register. Note that by using
+built-in functions or inline assembly with partial vector arguments, NaNs,
+denormal or invalid values can leak into the upper part of the vector,
+causing possible performance issues when @option{-fno-trapping-math} is in
+effect. These issues can be mitigated by manually sanitizing the upper part
+of the partial vector argument register or by using @option{-mdaz-ftz} to set
+denormals-are-zero (DAZ) flag in the MXCSR register.
+
+This option is enabled by default.
+
@opindex mmove-max
@item -mmove-max=@var{bits}
This option instructs GCC to set the maximum number of bits can be
Re: [V2][PATCH 0/3] New attribute "counted_by" to annotate bounds for C99 FAM(PR108896)
On Fri, Aug 04, 2023 at 07:44:28PM +, Qing Zhao wrote:
> This is the 2nd version of the patch, per our discussion based on the
> review comments for the 1st version, the major changes in this version
> are:
Thanks for the update!
>
> 1. change the name "element_count" to "counted_by";
> 2. change the parameter for the attribute from a STRING to an
> Identifier;
> 3. Add logic and testing cases to handle anonymous structure/unions;
> 4. Clarify documentation to permit the situation when the allocation
> size is larger than what's specified by "counted_by", at the same time,
> it's user's error if allocation size is smaller than what's specified by
> "counted_by";
> 5. Add a complete testing case for using counted_by attribute in
> __builtin_dynamic_object_size when there is mismatch between the
> allocation size and the value of "counted_by", the expecting behavior
> for each case and the explanation on why in the comments.
All the "normal" test cases I have are passing; this is wonderful! :)
I'm still seeing unexpected situations when I've intentionally set
counted_by to be smaller than alloc_size, but I assume it's due to not
yet having the patch you mention below.
> As discussed, I plan to add two more separate patch sets after this initial
> patch set is approved and committed.
>
> set 1. A new warning option and a new sanitizer option for the user error
>when the allocation size is smaller than the value of "counted_by".
> set 2. An improvement to __builtin_dynamic_object_size for the following
>case:
>
> struct A
> {
> size_t foo;
> int array[] __attribute__((counted_by (foo)));
> };
>
> extern struct fix * alloc_buf ();
>
> int main ()
> {
> struct fix *p = alloc_buf ();
> __builtin_object_size(p->array, 0) == sizeof(struct A) + p->foo * sizeof(int);
> /* with the current algorithm, it’s UNKNOWN */
> __builtin_object_size(p->array, 2) == sizeof(struct A) + p->foo * sizeof(int);
> /* with the current algorithm, it’s UNKNOWN */
> }
Should the above be bdos instead of bos?
> Bootstrapped and regression tested on both aarch64 and X86, no issue.
I've updated the Linux kernel's macros for the name change and done
build tests with my first pass at "easy" cases for adding counted_by:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/commit/?h=devel/counted_by&id=adc5b3cb48a049563dc673f348eab7b6beba8a9b
Everything is working as expected. :)
-Kees
--
Kees Cook
Re: [PATCH v1] Mode-Switching: Fix SET_SRC ICE when only one operand
On 8/7/23 07:13, Richard Biener wrote: On Mon, Aug 7, 2023 at 2:30 PM Pan Li via Gcc-patches wrote: From: Pan Li In same cases, like gcc/testsuite/gcc.dg/pr78148.c in RISC-V, there will be only 1 operand when SET_SRC in create_pre_exit. For example as below. (insn 13 9 14 2 (clobber (reg/i:TI 10 a0)) "gcc/testsuite/gcc.dg/pr78148.c":24:1 -1 (expr_list:REG_UNUSED (reg/i:TI 10 a0) (nil))) Unfortunately, SET_SRC requires at least 2 operands and then Segment Fault here. This patch would like to fix this ICE by adding operand length check before SET_SRC. Signed-off-by: Pan Li gcc/ChangeLog: * mode-switching.cc (create_pre_exit): Add operand length check. gcc/testsuite/ChangeLog: * gcc.target/riscv/mode-switch-ice-1.c: New test. --- gcc/mode-switching.cc | 2 ++ .../gcc.target/riscv/mode-switch-ice-1.c | 22 +++ 2 files changed, 24 insertions(+) create mode 100644 gcc/testsuite/gcc.target/riscv/mode-switch-ice-1.c diff --git a/gcc/mode-switching.cc b/gcc/mode-switching.cc index 64ae2bc29c3..cbf03c02159 100644 --- a/gcc/mode-switching.cc +++ b/gcc/mode-switching.cc @@ -411,6 +411,8 @@ create_pre_exit (int n_entities, int *entity_map, const int *num_modes) conflict with address reloads. */ if (copy_start >= ret_start && copy_start + copy_num <= ret_end + && GET_RTX_LENGTH (GET_CODE (return_copy_pat)) >= 2 + /* SET_SRC requires at least 2 operands. */ maybe check that return_copy_pat is a SET instead? Or just ignore the case of an insn that is a toplevel USE/CLOBBER? I bet we even have a function for that somewhere given how commonly we need to do that. jeff
Re: [V2][PATCH 0/3] New attribute "counted_by" to annotate bounds for C99 FAM(PR108896)
> On Aug 7, 2023, at 12:16 PM, Kees Cook wrote:
>
> On Fri, Aug 04, 2023 at 07:44:28PM +, Qing Zhao wrote:
>> This is the 2nd version of the patch, per our discussion based on the
>> review comments for the 1st version, the major changes in this version
>> are:
>
> Thanks for the update!
>
>>
>> 1. change the name "element_count" to "counted_by";
>> 2. change the parameter for the attribute from a STRING to an
>> Identifier;
>> 3. Add logic and testing cases to handle anonymous structure/unions;
>> 4. Clarify documentation to permit the situation when the allocation
>> size is larger than what's specified by "counted_by", at the same time,
>> it's user's error if allocation size is smaller than what's specified by
>> "counted_by";
>> 5. Add a complete testing case for using counted_by attribute in
>> __builtin_dynamic_object_size when there is mismatch between the
>> allocation size and the value of "counted_by", the expecting behavior
>> for each case and the explanation on why in the comments.
>
> All the "normal" test cases I have are passing; this is wonderful! :)
>
> I'm still seeing unexpected situations when I've intentionally set
> counted_by to be smaller than alloc_size, but I assume it's due to not
> yet having the patch you mention below.
What’s the testing case for the one that failed?
If it’s
__builtin_dynamic_object_size(p->array, 0/2) without the allocation information
in the routine,
then with the current algorithm, gcc cannot deduce the size for the whole
object.
If not such case, let me know.
>
>> As discussed, I plan to add two more separate patch sets after this initial
>> patch set is approved and committed.
>>
>> set 1. A new warning option and a new sanitizer option for the user error
>> when the allocation size is smaller than the value of "counted_by".
>> set 2. An improvement to __builtin_dynamic_object_size for the following
>> case:
>>
>> struct A
>> {
>> size_t foo;
>> int array[] __attribute__((counted_by (foo)));
>> };
>>
>> extern struct fix * alloc_buf ();
>>
>> int main ()
>> {
>> struct fix *p = alloc_buf ();
>> __builtin_object_size(p->array, 0) == sizeof(struct A) + p->foo *
>> sizeof(int);
>> /* with the current algorithm, it’s UNKNOWN */
>> __builtin_object_size(p->array, 2) == sizeof(struct A) + p->foo *
>> sizeof(int);
>> /* with the current algorithm, it’s UNKNOWN */
>> }
>
> Should the above be bdos instead of bos?
Yes, sorry for the typo. -:)
>
>> Bootstrapped and regression tested on both aarch64 and X86, no issue.
>
> I've updated the Linux kernel's macros for the name change and done
> build tests with my first pass at "easy" cases for adding counted_by:
> https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/commit/?h=devel/counted_by&id=adc5b3cb48a049563dc673f348eab7b6beba8a9b
>
> Everything is working as expected. :)
Thanks a lot for the testing!
Qing
>
> -Kees
>
> --
> Kees Cook
>
>
Re: [PATCH v3] Implement new RTL optimizations pass: fold-mem-offsets.
On 8/7/23 08:44, Manolis Tsamis wrote: I have sent out a new v4 of this (https://gcc.gnu.org/pipermail/gcc-patches/2023-August/626502.html). In the new version I both restore the INSN_CODE as mentioned here and I also call recog when I commit the offset change (because there may be a change from no offset to some offsets). I have also removed the driver function as per Vineet's suggestion. Last thing I have fixed a nasty bug with REG_EQUIV's that resulted in failing bootstrap on AArch64. The offending sequence looked like this (in 'simplified RTX'): (set (reg/f:DI 3 x3) (plus:DI (reg/f:DI 2 x2) (const_int 8 [0x8]))) (set (reg/f:DI 19 x19) (plus:DI (reg/f:DI 3 x3) (reg:DI 19 x19))) ... (set (reg:TI 2 x2) (mem:TI (reg/f:DI 0 x0))) (expr_list:REG_DEAD (reg/f:DI 0 x0) (expr_list:REG_EQUIV (mem:TI (reg/f:DI 19 x19)) (nil))) (set (mem:TI (reg/f:DI 19 x19)) (reg:TI 2 x2)) (expr_list:REG_DEAD (reg/f:DI 19 x19) (expr_list:REG_DEAD (reg:TI 2 x2) (nil))) Were the first instruction (x3 = x2 + 8) was folded in the address calculation of the last one, resulting in (mem:TI (plus:DI (reg/f:DI 19 x19) (const_int 8 [0x8])), but then the previous REG_EQUIV was incorrect due to the modified runtime value of x19. For now I opted to treat REG_EQ/EQUIV notes as uses that we cannot handle, so if any of them are involved we don't fold offsets. Although it would may be possible to improve this in the future, I think it's fine for now and the reduction of folded insns is a small %. I have tested v4 with a number of benchmarks and large projects on x64, aarch64 and riscv64 without observing any issues. The x86 testsuite issue still exists as I don't have a satisfactory solution to it yet. Any feedback for the changes is appreciated! Thanks for the explanation. You could just remove the REG_EQUIV note. It's not used much after allocation & reloading. Or just ignoring those insns as you've done seems reasonable as well. I doubt one approach is clear better than the other. jeff
Re: [PATCH] rtl-optimization/110869 Fix tests cmp-mem-const-*.c for sparc
On 8/7/23 07:32, Stefan Schulze Frielinghaus via Gcc-patches wrote:
This fixes the rather new tests cmp-mem-const-{1,2,3,4,5,6}.c for sparc.
For -1 and -2 we need at least optimization level 2 on sparc. For the
sake of homogeneity, change all test cases to -O2. For -3 and -4 we do
not end up with a comparison of memory and a constant, and finally for
-5 and -6 the constants are reduced by a prior optimization which means
there is nothing left to do. Thus excluding sparc from those tests.
Ok for mainline?
gcc/testsuite/ChangeLog:
PR rtl-optimization/110869
* gcc.dg/cmp-mem-const-1.c: Use optimization level 2.
* gcc.dg/cmp-mem-const-2.c: Dito.
* gcc.dg/cmp-mem-const-3.c: Exclude sparc from this test.
* gcc.dg/cmp-mem-const-4.c: Dito.
* gcc.dg/cmp-mem-const-5.c: Dito.
* gcc.dg/cmp-mem-const-6.c: Dito.
OK. Though I suspect the lack of memory comparison to a constant likely
shows up elsewhere. We're likely going to end up with a significant
number of excludes for -3 and -4.
Jeff
Re: [PATCH] cprop_hardreg: Allow more propagation of the stack pointer.
On 8/7/23 05:31, Manolis Tsamis wrote: The stack pointer propagation fix 736f8fd3 turned out to be more restrictive than needed by rejecting propagation of the stack pointer when REG_POINTER didn't match. This commit removes this check: When the stack pointer is propagated it is fine for this to result in REG_POINTER becoming true from false, which is what the original code checked. This simplification makes the previously introduced function maybe_copy_reg_attrs obsolete and the logic can be inlined at the call sites, as it was before 736f8fd3. gcc/ChangeLog: * regcprop.cc (maybe_copy_reg_attrs): Remove unnecessary function. (find_oldest_value_reg): Inline stack_pointer_rtx check. (copyprop_hardreg_forward_1): Inline stack_pointer_rtx check. OK jeff
[COMMITTED] MAINTAINERS: Add myself as a BPF port reviewer
ChangeLog: * MAINTAINERS: Add the BPF port to my reviewer listing. --- MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 6cac5ac6671..1e54844c905 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -273,7 +273,7 @@ arc portClaudiu Zissulescu callgraph Martin Jambor C front endMarek Polacek CTF, BTF Indu Bhagat -CTF, BTF David Faust +CTF, BTF, bpf port David Faust dataflow Paolo Bonzini dataflow Seongbae Park dataflow Kenneth Zadeck -- 2.40.1
[RFC] GCC Security policy
FOSS Best Practices recommends that projects have an official Security policy stated in a SECURITY.md or SECURITY.txt file at the root of the repository. GLIBC and Binutils have added such documents. Appended is a prototype for a Security policy file for GCC based on the Binutils document because GCC seems to have more affinity with Binutils as a tool. Do the runtime libraries distributed with GCC, especially libgcc, require additional security policies? [ ] Is it appropriate to use the Binutils SECURITY.txt as the starting point or should GCC use GLIBC SECURITY.md as the starting point for the GCC Security policy? [ ] Does GCC, or some components of GCC, require additional care because of runtime libraries like libgcc and libstdc++, and because of gcov and profile-directed feedback? Thoughts? Thanks, David GCC Security Process What is a GCC security bug? === A security bug is one that threatens the security of a system or network, or might compromise the security of data stored on it. In the context of GCC there are two ways in which such bugs might occur. In the first, the programs themselves might be tricked into a direct compromise of security. In the second, the tools might introduce a vulnerability in the generated output that was not already present in the files used as input. Other than that, all other bugs will be treated as non-security issues. This does not mean that they will be ignored, just that they will not be given the priority that is given to security bugs. This stance applies to the creation tools in the GCC (e.g., gcc, g++, gfortran, gccgo, gccrs, gnat, cpp, gcov, etc.) and the libraries that they use. Notes: == None of the programs in GCC need elevated privileges to operate and it is recommended that users do not use them from accounts where such privileges are automatically available. Reporting private security bugs *All bugs reported in the GCC Bugzilla are public.* In order to report a private security bug that is not immediately public, please contact one of the downstream distributions with security teams. The following teams have volunteered to handle such bugs: Debian: secur...@debian.org Red Hat: secal...@redhat.com SUSE:secur...@suse.de Please report the bug to just one of these teams. It will be shared with other teams as necessary. The team contacted will take care of details such as vulnerability rating and CVE assignment (http://cve.mitre.org/about/). It is likely that the team will ask to file a public bug because the issue is sufficiently minor and does not warrant an embargo. An embargo is not a requirement for being credited with the discovery of a security vulnerability. Reporting public security bugs == It is expected that critical security bugs will be rare, and that most security bugs can be reported in GCC, thus making them public immediately. The system can be found here: https://gcc.gnu.org/bugzilla/
Re: [PATCH 01/24] toplevel: Substitute GDCFLAGS instead of using CFLAGS
On 8/7/23 04:32, Arsen Arsenović via Gcc-patches wrote:
r14-2875-g1ed21e23d6d4da ("Use substituted GDCFLAGS") already
implemented this change, but only on the generated file rather than in
the template it is generated from.
ChangeLog:
* Makefile.tpl: Substitute @GDCFLAGS@ instead of using
$(CFLAGS).
OK.
jeff
Re: [PATCH 03/24] gcc-4.5 build fixes
On 8/7/23 04:32, Arsen Arsenović via Gcc-patches wrote: From: Alan Modra Trying to build binutils with an older gcc currently fails. Working around these gcc bugs is not onerous so let's fix them. include/ChangeLog: * xtensa-dynconfig.h (xtensa_isa_internal): Delete unnecessary forward declaration. OK. While gcc-4.8 is the minimum for GCC, as long as the pain is small I think we should allow earlier compilers if it helps gdb/binutils. jeff
Re: [PATCH] cprop_hardreg: Allow more propagation of the stack pointer.
Applied to master, thanks! --Philipp. On Mon, 7 Aug 2023 at 19:20, Jeff Law wrote: > > > > On 8/7/23 05:31, Manolis Tsamis wrote: > > The stack pointer propagation fix 736f8fd3 turned out to be more restrictive > > than needed by rejecting propagation of the stack pointer when REG_POINTER > > didn't match. > > > > This commit removes this check: > > When the stack pointer is propagated it is fine for this to result in > > REG_POINTER becoming true from false, which is what the original code > > checked. > > > > This simplification makes the previously introduced function > > maybe_copy_reg_attrs obsolete and the logic can be inlined at the call > > sites, > > as it was before 736f8fd3. > > > > gcc/ChangeLog: > > > > * regcprop.cc (maybe_copy_reg_attrs): Remove unnecessary function. > > (find_oldest_value_reg): Inline stack_pointer_rtx check. > > (copyprop_hardreg_forward_1): Inline stack_pointer_rtx check. > OK > jeff
Re: [PATCH 1/2] libstdc++: Implement more maintainable header
Jonathan Wakely writes: > [...snip...] > It looks like this will regenerate the bits/version.h file if it's older > than the definitions or the autogen template, right? > > Generally we don't want to touch anything in the source tree as part of a > normal build. It's OK to do that when configured with > --enable-maintainer-mode (which nobody working on libstdc++ actually uses, > because it causes problems IME) or via a dedicated target which is not > built by default (e.g. doc/Makefile.am has the doc-html-docbook-regenerate > target, which is isn't a prereq of any other targets so it's only run if > you explicitly request it). > > The problem with modifying the source tree as part of a normal build is > that it might be on read-only media, and so the build will fail if this > target can't be updated. We would also want to add the version.h header to > the contrib/gcc_update script that updates the timestamps of generated > files, so that they are always newer than their prereqs. > > Maybe the best option here is to assume that version.h is always up to > date, and add a custom target to regen it manually, which we can run after > editing the .def or .tpl files. What do you think? Ah, I wasn't aware of this concern. I'll make it a phony target, yeah. > My only other concern with this patch is that I don't speak lisp so the > Guile code in version.tpl is opaque and unmaintainable for me. That is > fixable though. The algorithm the code implements is quite simple, it just verifies that the three numeric fields associated with each FTM are in a non-ascending order (which ensures that the most broad option comes last in the #if/#elif chain). It's a sanity check that's caught a couple of transcription errors I made during the initial conversion. -- Arsen Arsenović signature.asc Description: PGP signature
Re: [PATCH 4/5] [RISC-V] Generate Zicond instruction for select pattern with condition eq or neq to non-zero
On 7/19/23 04:11, Xiao Zeng wrote: This patch completes the recognition of Zicond when the select pattern with condition eq or neq to non-zero (using equality as an example), namely: 1 rd = (rs2 == non-imm) ? 0 : rs1 2 rd = (rs2 == reg) ? 0 : rs1 At the same time, more Zicond non basic semantic test cases have been added. gcc/ChangeLog: * config/riscv/riscv.cc (riscv_expand_conditional_move): Recognize Zicond. I think this is handled by the changes from Raphael I just committed. But I do think we should take the testsuite work to verify the cases all work as expected. Given the testcases from 3/5 are also on hold pending fixing the costing issues, I'm thinking to roll all the testsuite changes into a distinct patch, with the failing tests xfailed until we fix the costing work. But I definitely don't want to lose the tests. jeff
Re: [PATCH v2] rs6000: Fix __builtin_altivec_vcmpne{b,h,w} implementation
On Mon, 2023-08-07 at 17:18 +0800, Kewen.Lin wrote:
> Hi Carl,
>
> Sorry for the late review.
>
> on 2023/8/2 02:29, Carl Love wrote:
> > GCC maintainers:
> >
> > Ver 2: Re-worked the test vec-cmpne.c to create a compile only
> > test
> > verify the instruction generation and a runnable test to verify the
> > built-in functionality. Retested the patch on Power 8 LE/BE, Power
> > 9LE/BE and Power 10 LE with no regressions.
> >
> > The following patch cleans up the definition for the
> > __builtin_altivec_vcmpne{b,h,w}. The current implementation
> > implies
> > that the built-in is only supported on Power 9 since it is defined
> > under the Power 9 stanza. However the built-in has no ISA
> > restrictions
> > as stated in the Power Vector Intrinsic Programming Reference
> > document.
> > The current built-in works because the built-in gets replaced
> > during
> > GIMPLE folding by a simple not-equal operator so it doesn't get
> > expanded and checked for Power 9 code generation.
> >
> > This patch moves the definition to the Altivec stanza in the built-
> > in
> > definition file to make it clear the built-ins are valid for Power
> > 8,
> > Power 9 and beyond.
> >
> > The patch has been tested on Power 8 LE/BE, Power 9 LE/BE and Power
> > 10
> > LE with no regressions.
> >
> > Please let me know if the patch is acceptable for
> > mainline. Thanks.
> >
> > Carl
> >
> >
> > rs6000: Fix __builtin_altivec_vcmpne{b,h,w} implementation
> >
> > The current built-in definitions for vcmpneb, vcmpneh, vcmpnew are
> > defined
> > under the Power 9 section of r66000-builtins. This implies they
> > are only
> > supported on Power 9 and above when in fact they are defined and
> > work with
> > Altivec as well with the appropriate Altivec instruction
> > generation.
> >
> > The vec_cmpne builtin should generate the vcmpequ{b,h,w}
> > instruction with
> > Altivec enabled and generate the vcmpne{b,h,w} on Power 9 and newer
> > processors.
> >
> > This patch moves the definitions to the Altivec stanza to make it
> > clear
> > the built-ins are supported for all Altivec processors. The patch
> > enables the vcmpequ{b,h,w} instruction to be generated on Altivec
> > and
> > the vcmpne{b,h,w} instruction to be generated on Power 9 and
> > beyond.
>
> But as you noted above, the current built-ins work as expected, that
> is
> to generate with vcmpequ{b,h,w} on altivec but not Power9 while
> generate
> with vcmpne{b,h,w} on Power9. So I think we shouldn't say it's
> enabled
> by this patch. Instead it's to remove the confusion.
OK, changed.
>
> > There is existing test coverage for the vec_cmpne built-in for
> > vector bool char, vector bool short, vector bool int,
> > vector bool long long in builtins-3-p9.c and p8vector-builtin-2.c.
> > Coverage for vector signed int, vector unsigned int is in
> > p8vector-builtin-2.c.
> >
> > Test vec-cmpne.c is updated to check the generation of the
> > vcmpequ{b,h,w}
> > instructions for Altivec. A new test vec-cmpne-runnable.c is added
> > to
> > verify the built-ins work as expected.
> >
> > Patch has been tested on Power 8 LE/BE, Power 9 LE/BE and Power 10
> > LE
> > with no regressions.
> >
> > gcc/ChangeLog:
> >
> > * config/rs6000/rs6000-builtins.def (vcmpneb, vcmpneh,
> > vcmpnew):
> > Move definitions to Altivec stanza.
> > * config/rs6000/altivec.md (vcmpneb, vcmpneh, vcmpnew): New
> > define_expand.
> >
> > gcc/testsuite/ChangeLog:
> >
> > * gcc.target/powerpc/vec-cmpne-runnable.c: New execution test.
> > * gcc.target/powerpc/vec-cmpne.c (define_test_functions,
> > execute_test_functions) moved to vec-cmpne.h. Added
> > scan-assembler-times for vcmpequb, vcmpequh, vcmpequw.
> > * gcc.target/powerpc/vec-cmpne.h: New include file for vec-
> > cmpne.c
> > and vec-cmpne-runnable.c. Split define_test_functions
> > definition
> > into define_test_functions and define_init_verify_functions.
> > ---
> > gcc/config/rs6000/altivec.md | 12 ++
> > gcc/config/rs6000/rs6000-builtins.def | 18 +--
> > .../gcc.target/powerpc/vec-cmpne-runnable.c | 36 ++
> > gcc/testsuite/gcc.target/powerpc/vec-cmpne.c | 110 ++--
> > --
> > gcc/testsuite/gcc.target/powerpc/vec-cmpne.h | 86 ++
> > 5 files changed, 151 insertions(+), 111 deletions(-)
> > create mode 100644 gcc/testsuite/gcc.target/powerpc/vec-cmpne-
> > runnable.c
> > create mode 100644 gcc/testsuite/gcc.target/powerpc/vec-cmpne.h
> >
> > diff --git a/gcc/config/rs6000/altivec.md
> > b/gcc/config/rs6000/altivec.md
> > index ad1224e0b57..31f65aa1b7a 100644
> > --- a/gcc/config/rs6000/altivec.md
> > +++ b/gcc/config/rs6000/altivec.md
> > @@ -2631,6 +2631,18 @@ (define_insn "altivec_vcmpequt_p"
> >"vcmpequq. %0,%1,%2"
> >[(set_attr "type" "veccmpfx")])
> >
> > +;; Expand for builtin vcmpne{b,h,w}
> > +(define_expand "altivec_vcmpn
Re: [PATCH 2/2] libstdc++: Replace all manual FTM definitions and use
Jonathan Wakely writes:
> On Sat, 29 Apr 2023 at 11:24, Arsen Arsenović via Libstdc++ <
> libstd...@gcc.gnu.org> wrote:
>
>> libstdc++-v3/ChangeLog:
>>
>> * libsupc++/typeinfo: Switch to bits/version.h for
>> __cpp_lib_constexpr_typeinfo.
>>
>>
> Does this change have an impact on compilation speed?
> With this change we'll be re-including bits/version.h multiple times in
> most compilations, and unlike other headers the preprocessor can't optimize
> away the second and subsequent times its' included, because the header
> isn't idempotent.
> It will only affect the preprocessing phase, which is a fraction of the
> time taken by template instantiation and middle end optimizations, but I'd
> like to know it's not *too* expensive before committing to this approach.
>
>> @@ -234,9 +234,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>>return __atomic_test_and_set (&_M_i, int(__m));
>> }
>>
>> -#if __cplusplus > 201703L
>> -#define __cpp_lib_atomic_flag_test 201907L
>> -
>> +#ifdef __cpp_lib_atomic_flag_test
>> _GLIBCXX_ALWAYS_INLINE bool
>> test(memory_order __m = memory_order_seq_cst) const noexcept
>> {
>>
>
> This is more "structured" and maintainable than the current ad-hoc way we
> deal with FTMs, but this seems like a readability/usability regression in
> terms of being able to open the header and see "ah this feature is only
> available for C++20 and up". Instead you can see it's available for the
> specified FTM, but now you have to go and find where that's defined, and
> that's not even defined in C++, it's in the version.def file. It's also
> defined in bits/version.h, but that's a generated file and so is very
> verbose and long.
>
>
> diff --git a/libstdc++-v3/include/bits/move_only_function.h
>> b/libstdc++-v3/include/bits/move_only_function.h
>> index 71d52074978..81d7d9f7c0a 100644
>> --- a/libstdc++-v3/include/bits/move_only_function.h
>> +++ b/libstdc++-v3/include/bits/move_only_function.h
>> @@ -32,7 +32,10 @@
>>
>> #pragma GCC system_header
>>
>> -#if __cplusplus > 202002L
>> +#define __glibcxx_want_move_only_function
>> +#include
>> +
>> +#ifdef __cpp_lib_move_only_function
>>
>
> Here's another case where I think the __cplusplus > 202002L is more
> discoverable.
>
> Although maybe I'm biased, because I look at that and immediately see
> "C++23 and up". Maybe the average user finds that less clear. Maybe the
> average user doesn't need to look at this anyway, but I know *I* do it
> fairly often.
>
> I wonder if it would help if we kept a comment there with a (possibly
> imprecise) hint about the conditions under which the feature is defined. So
> in this case:
>
> // Only defined for C++23
> #ifdef __cpp_lib_move_only_function
>
> That retains the info that's currently there, and is even more readable
> than the __cplusplus check.
>
> There's a risk that those comments would get out of step with reality,
> which is one of the things this patch set aims to solve. But I think in
> practice that's unlikely. std::move_only_function isn't suddenly going to
> become available in C++20, or stop being available in C++23 and move to
> C++26.
>
> What do you think?
I think that's reasonable. And, yes, I doubt these conditions change
much. I'll go over the conditions and insert a hint.
--
Arsen Arsenović
signature.asc
Description: PGP signature
Re: [PATCH 05/24] GCC: Check if AR works with --plugin and rc
On 8/7/23 04:32, Arsen Arsenović via Gcc-patches wrote: From: "H.J. Lu" AR from older binutils doesn't work with --plugin and rc: [hjl@gnu-cfl-2 bin]$ touch foo.c [hjl@gnu-cfl-2 bin]$ ar --plugin /usr/libexec/gcc/x86_64-redhat-linux/10/liblto_plugin.so rc libfoo.a foo.c [hjl@gnu-cfl-2 bin]$ ./ar --plugin /usr/libexec/gcc/x86_64-redhat-linux/10/liblto_plugin.so rc libfoo.a foo.c ./ar: no operation specified [hjl@gnu-cfl-2 bin]$ ./ar --version GNU ar (Linux/GNU Binutils) 2.29.51.0.1.20180112 Copyright (C) 2018 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or (at your option) any later version. This program has absolutely no warranty. [hjl@gnu-cfl-2 bin]$ Check if AR works with --plugin and rc before passing --plugin to AR and RANLIB. ChangeLog: * configure: Regenerated. * libtool.m4 (_LT_CMD_OLD_ARCHIVE): Check if AR works with --plugin and rc before enabling --plugin. config/ChangeLog: * gcc-plugin.m4 (GCC_PLUGIN_OPTION): Check if AR works with --plugin and rc before enabling --plugin. gcc/ChangeLog: * configure: Regenerate. libatomic/ChangeLog: * configure: Regenerate. libbacktrace/ChangeLog: * configure: Regenerate. libcc1/ChangeLog: * configure: Regenerate. libffi/ChangeLog: * configure: Regenerate. libgfortran/ChangeLog: * configure: Regenerate. libgm2/ChangeLog: * configure: Regenerate. libgomp/ChangeLog: * configure: Regenerate. libiberty/ChangeLog: * configure: Regenerate. libitm/ChangeLog: * configure: Regenerate. libobjc/ChangeLog: * configure: Regenerate. libphobos/ChangeLog: * configure: Regenerate. libquadmath/ChangeLog: * configure: Regenerate. libsanitizer/ChangeLog: * configure: Regenerate. libssp/ChangeLog: * configure: Regenerate. libstdc++-v3/ChangeLog: * configure: Regenerate. libvtv/ChangeLog: * configure: Regenerate. lto-plugin/ChangeLog: * configure: Regenerate. zlib/ChangeLog: * configure: Regenerate. OK jeff
