Re: Re: [PATCH] [PHIOPT] Add A ? B + CST : B match and simplify optimizations

[Richard Biener via Gcc-patches]

On Tue, Nov 8, 2022 at 4:51 PM 钟云德  wrote:

> At 2022-11-08 22:58:34, "Richard Biener" 
> wrote:
>
> >On Sat, Nov 5, 2022 at 10:03 AM Zhongyunde via Gcc-patches
> > wrote:
> >>
> >>
> >> > -Original Message-
> >> > From: Andrew Pinski [mailto:pins...@gcc.gnu.org]
> >> > Sent: Saturday, November 5, 2022 2:34 PM
> >> > To: Zhongyunde 
> >> > Cc: hongtao@intel.com; gcc-patches@gcc.gnu.org; Zhangwen(Esan)
> >> > ; Weiwei (weiwei, Compiler)
> >> > ; zhong_1985...@163.com
> >> > Subject: Re: [PATCH] [PHIOPT] Add A ? B + CST : B match and simplify
> >> > optimizations
> >> >
> >> > On Fri, Nov 4, 2022 at 11:17 PM Zhongyunde 
> >> > wrote:
> >> > >
> >> > > hi,
> >> > >   This patch is try to fix the issue
> >> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107190,
> >> > > would you like to give me some suggestion, thanks.
> >> >
> >> > This seems like a "simplified" version of
> >> > https://gcc.gnu.org/pipermail/gcc-patches/2021-November/584411.html
> >> > which just handles power of 2 constants where we know the cond will be
> >> > removed.
> >> > We could do even more "simplified" of 1 if needed really.
> >> > What is the IR before PHI-OPT? Is it just + 1?
> >>
> >> Thanks for your attention. It is + 4294967296 before PHI-OPT  (See detail 
> >> https://gcc.godbolt.org/z/6zEc6ja1z)
> >> So we should keep matching the power of 2 constants ?
> >>
> >> > Also your pattern can be simplified to use integer_pow2p in the match 
> >> > part
> >> > instead of INTEGER_CST.
> >> >
> >> Apply your comment, thanks
> >
> >How does the patch fix the mentioned bug?  match.pd patterns should make 
> >things
> >"simpler" but x + (a << C') isn't simpler than a ? x + C : x.  It
> >looks you are targeting
> >PHI-OPT here, so maybe instead extend value_replacement to handle this case,
> >it does look similar to the case with neutral/absorbing element there?
> >
> >Richard.
>
> Thanks. This patch try to fix the 1st issued mentioned in 107090 – [aarch64] 
> sequence logic should be combined with mul and umulh (gnu.org) 
> 
> Sure, I'll take a look at the function value_replacement.
> I have also noticed that the function of two_value_replacement is very close 
> to patch I want to achieve, and it may be easy to extend.
> It seems can be expressed equally in match.pd (called by 
> match_simplify_replacement), so how do we
> choose where to implement may be better?
>
>
I think that if we realize that we don't want a simplification to always
apply (like by checking
for canonicalize_math_p ()), then we should look for a pass which is a good
fit and since
you add the pattern to trigger a PHI-OPT optimization that looked like an
obvious choice ...

```
>
>   /* Do the replacement of conditional if it can be done.  */ 
> if (!early_p  
>   
> && !diamond_p 
>   && 
> two_value_replacement (bb, bb1, e2, phi, arg0, arg1)) 
>  cfgchanged = true;   
>  
> else if (!diamond_p   
>&& 
> match_simplify_replacement (bb, bb1, e1, e2, phi, 
>   arg0, 
> arg1, early_p)) 
> cfgchanged = true;
>
> ```
> >> > Thanks, >> > Andrew >> >>
>
>

RE: [PATCH 1/4]middle-end Support not decomposing specific divisions during vectorization.

[Richard Biener via Gcc-patches]

On Tue, 8 Nov 2022, Tamar Christina wrote:

> Ping.

Jeff approved this already.  I think it's OK if the rest of the series
is approved.

Richard.

> > -Original Message-
> > From: Tamar Christina
> > Sent: Monday, October 31, 2022 11:35 AM
> > To: Richard Biener 
> > Cc: gcc-patches@gcc.gnu.org; nd ; jeffreya...@gmail.com
> > Subject: RE: [PATCH 1/4]middle-end Support not decomposing specific
> > divisions during vectorization.
> > 
> > >
> > > The type of the expression should be available via the mode and the
> > > signedness, no?  So maybe to avoid having both RTX and TREE on the
> > > target hook pass it a wide_int instead for the divisor?
> > >
> > 
> > Done.
> > 
> > Bootstrapped Regtested on aarch64-none-linux-gnu, x86_64-pc-linux-gnu
> > and no issues.
> > 
> > Ok for master?
> > 
> > Thanks,
> > Tamar
> > 
> > gcc/ChangeLog:
> > 
> > * expmed.h (expand_divmod): Pass tree operands down in addition
> > to RTX.
> > * expmed.cc (expand_divmod): Likewise.
> > * explow.cc (round_push, align_dynamic_address): Likewise.
> > * expr.cc (force_operand, expand_expr_divmod): Likewise.
> > * optabs.cc (expand_doubleword_mod,
> > expand_doubleword_divmod):
> > Likewise.
> > * target.h: Include tree-core.
> > * target.def (can_special_div_by_const): New.
> > * targhooks.cc (default_can_special_div_by_const): New.
> > * targhooks.h (default_can_special_div_by_const): New.
> > * tree-vect-generic.cc (expand_vector_operation): Use it.
> > * doc/tm.texi.in: Document it.
> > * doc/tm.texi: Regenerate.
> > * tree-vect-patterns.cc (vect_recog_divmod_pattern): Check for
> > support.
> > * tree-vect-stmts.cc (vectorizable_operation): Likewise.
> > 
> > gcc/testsuite/ChangeLog:
> > 
> > * gcc.dg/vect/vect-div-bitmask-1.c: New test.
> > * gcc.dg/vect/vect-div-bitmask-2.c: New test.
> > * gcc.dg/vect/vect-div-bitmask-3.c: New test.
> > * gcc.dg/vect/vect-div-bitmask.h: New file.
> > 
> > --- inline copy of patch ---
> > 
> > diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi index
> > 92bda1a7e14a3c9ea63e151e4a49a818bf4d1bdb..a29f5c39be3f0927f8ef6e094
> > c7a712c0604fb77 100644
> > --- a/gcc/doc/tm.texi
> > +++ b/gcc/doc/tm.texi
> > @@ -6112,6 +6112,22 @@ instruction pattern.  There is no need for the hook
> > to handle these two  implementation approaches itself.
> >  @end deftypefn
> > 
> > +@deftypefn {Target Hook} bool
> > TARGET_VECTORIZE_CAN_SPECIAL_DIV_BY_CONST
> > +(enum @var{tree_code}, tree @var{vectype}, wide_int @var{constant}, rtx
> > +*@var{output}, rtx @var{in0}, rtx @var{in1}) This hook is used to test
> > +whether the target has a special method of division of vectors of type
> > +@var{vectype} using the value @var{constant}, and producing a vector of
> > type @var{vectype}.  The division will then not be decomposed by the and
> > kept as a div.
> > +
> > +When the hook is being used to test whether the target supports a
> > +special divide, @var{in0}, @var{in1}, and @var{output} are all null.
> > +When the hook is being used to emit a division, @var{in0} and @var{in1}
> > +are the source vectors of type @var{vecttype} and @var{output} is the
> > +destination vector of type @var{vectype}.
> > +
> > +Return true if the operation is possible, emitting instructions for it
> > +if rtxes are provided and updating @var{output}.
> > +@end deftypefn
> > +
> >  @deftypefn {Target Hook} tree
> > TARGET_VECTORIZE_BUILTIN_VECTORIZED_FUNCTION (unsigned
> > @var{code}, tree @var{vec_type_out}, tree @var{vec_type_in})  This hook
> > should return the decl of a function that implements the  vectorized variant
> > of the function with the @code{combined_fn} code diff --git
> > a/gcc/doc/tm.texi.in b/gcc/doc/tm.texi.in index
> > 112462310b134705d860153294287cfd7d4af81d..d5a745a02acdf051ea1da1b04
> > 076d058c24ce093 100644
> > --- a/gcc/doc/tm.texi.in
> > +++ b/gcc/doc/tm.texi.in
> > @@ -4164,6 +4164,8 @@ address;  but often a machine-dependent strategy
> > can generate better code.
> > 
> >  @hook TARGET_VECTORIZE_VEC_PERM_CONST
> > 
> > +@hook TARGET_VECTORIZE_CAN_SPECIAL_DIV_BY_CONST
> > +
> >  @hook TARGET_VECTORIZE_BUILTIN_VECTORIZED_FUNCTION
> > 
> >  @hook TARGET_VECTORIZE_BUILTIN_MD_VECTORIZED_FUNCTION
> > diff --git a/gcc/explow.cc b/gcc/explow.cc index
> > ddb4d6ae3600542f8d2bb5617cdd3933a9fae6c0..568e0eb1a158c696458ae678f
> > 5e346bf34ba0036 100644
> > --- a/gcc/explow.cc
> > +++ b/gcc/explow.cc
> > @@ -1037,7 +1037,7 @@ round_push (rtx size)
> >   TRUNC_DIV_EXPR.  */
> >size = expand_binop (Pmode, add_optab, size, alignm1_rtx,
> >NULL_RTX, 1, OPTAB_LIB_WIDEN);
> > -  size = expand_divmod (0, TRUNC_DIV_EXPR, Pmode, size, align_rtx,
> > +  size = expand_divmod (0, TRUNC_DIV_EXPR, Pmode, NULL, NULL, size,
> > + align_rtx,
> > NULL_RTX, 1);
> >size = expand_mult (Pmode, size, align_rtx, NULL_RTX, 1);
> > 
> > @@ -1203,7 +1203,7 @@ align_dynamic_address (rtx target, unsigned
> > required_a

Re: [PATCH 2/4] LoongArch: Add ftint{,rm,rp}.{w,l}.{s,d} instructions

[Xi Ruoyao via Gcc-patches]

On Wed, 2022-11-09 at 15:46 +0800, Lulu Cheng wrote:
> There is a paragraph in the explanation information for the compile 
> parameter '-fno-fp-int-builtin-inexact' in the gcc.pdf document:
> 
>  "Do not allow the built-in functions ceil, floor, round and
> trunc, 
> and their　float and long double variants,
> 
>  to generate code that raises the “inexact”　floating-point
> exception 
> for noninteger arguments.
> 
>  ISO C99 and C11 allow　these functions to raise the “inexact” 
> exception, but ISO/IEC TS 18661-1:2014,
> 
>  the C bindings to IEEE 754-2008, as integrated into ISO C2X, does
> not allow　these functions to do so."
> 
> So I think the implementation of these functions needs to be confirmed
> again.
> 
> Or am I misinterpreting this description?:-[

You are correct, I'm wrong :(.

This patch breaks:

long x(double d)
{
return __builtin_ceil(d);
}

The compiler then folds it into __builtin_lceil and produce
ftintrp.l.d $f0,$f0, even if -fno-fp-int-builtin-inexact is used.

I'll revise this patch to limit lceil and lfloor for -ffp-int-builtin-
inexact only.


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

Re: [PATCH 1/4]middle-end Support not decomposing specific divisions during vectorization.

[Tamar Christina via Gcc-patches]

Ah sorry, i missed that one.

Thanks,
Tamar


From: Richard Biener 
Sent: Wednesday, November 9, 2022 8:01 AM
To: Tamar Christina 
Cc: gcc-patches@gcc.gnu.org ; nd ; 
jeffreya...@gmail.com 
Subject: RE: [PATCH 1/4]middle-end Support not decomposing specific divisions 
during vectorization.

On Tue, 8 Nov 2022, Tamar Christina wrote:

> Ping.

Jeff approved this already.  I think it's OK if the rest of the series
is approved.

Richard.

> > -Original Message-
> > From: Tamar Christina
> > Sent: Monday, October 31, 2022 11:35 AM
> > To: Richard Biener 
> > Cc: gcc-patches@gcc.gnu.org; nd ; jeffreya...@gmail.com
> > Subject: RE: [PATCH 1/4]middle-end Support not decomposing specific
> > divisions during vectorization.
> >
> > >
> > > The type of the expression should be available via the mode and the
> > > signedness, no?  So maybe to avoid having both RTX and TREE on the
> > > target hook pass it a wide_int instead for the divisor?
> > >
> >
> > Done.
> >
> > Bootstrapped Regtested on aarch64-none-linux-gnu, x86_64-pc-linux-gnu
> > and no issues.
> >
> > Ok for master?
> >
> > Thanks,
> > Tamar
> >
> > gcc/ChangeLog:
> >
> >  * expmed.h (expand_divmod): Pass tree operands down in addition
> > to RTX.
> >  * expmed.cc (expand_divmod): Likewise.
> >  * explow.cc (round_push, align_dynamic_address): Likewise.
> >  * expr.cc (force_operand, expand_expr_divmod): Likewise.
> >  * optabs.cc (expand_doubleword_mod,
> > expand_doubleword_divmod):
> >  Likewise.
> >  * target.h: Include tree-core.
> >  * target.def (can_special_div_by_const): New.
> >  * targhooks.cc (default_can_special_div_by_const): New.
> >  * targhooks.h (default_can_special_div_by_const): New.
> >  * tree-vect-generic.cc (expand_vector_operation): Use it.
> >  * doc/tm.texi.in: Document it.
> >  * doc/tm.texi: Regenerate.
> >  * tree-vect-patterns.cc (vect_recog_divmod_pattern): Check for
> > support.
> >  * tree-vect-stmts.cc (vectorizable_operation): Likewise.
> >
> > gcc/testsuite/ChangeLog:
> >
> >  * gcc.dg/vect/vect-div-bitmask-1.c: New test.
> >  * gcc.dg/vect/vect-div-bitmask-2.c: New test.
> >  * gcc.dg/vect/vect-div-bitmask-3.c: New test.
> >  * gcc.dg/vect/vect-div-bitmask.h: New file.
> >
> > --- inline copy of patch ---
> >
> > diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi index
> > 92bda1a7e14a3c9ea63e151e4a49a818bf4d1bdb..a29f5c39be3f0927f8ef6e094
> > c7a712c0604fb77 100644
> > --- a/gcc/doc/tm.texi
> > +++ b/gcc/doc/tm.texi
> > @@ -6112,6 +6112,22 @@ instruction pattern.  There is no need for the hook
> > to handle these two  implementation approaches itself.
> >  @end deftypefn
> >
> > +@deftypefn {Target Hook} bool
> > TARGET_VECTORIZE_CAN_SPECIAL_DIV_BY_CONST
> > +(enum @var{tree_code}, tree @var{vectype}, wide_int @var{constant}, rtx
> > +*@var{output}, rtx @var{in0}, rtx @var{in1}) This hook is used to test
> > +whether the target has a special method of division of vectors of type
> > +@var{vectype} using the value @var{constant}, and producing a vector of
> > type @var{vectype}.  The division will then not be decomposed by the and
> > kept as a div.
> > +
> > +When the hook is being used to test whether the target supports a
> > +special divide, @var{in0}, @var{in1}, and @var{output} are all null.
> > +When the hook is being used to emit a division, @var{in0} and @var{in1}
> > +are the source vectors of type @var{vecttype} and @var{output} is the
> > +destination vector of type @var{vectype}.
> > +
> > +Return true if the operation is possible, emitting instructions for it
> > +if rtxes are provided and updating @var{output}.
> > +@end deftypefn
> > +
> >  @deftypefn {Target Hook} tree
> > TARGET_VECTORIZE_BUILTIN_VECTORIZED_FUNCTION (unsigned
> > @var{code}, tree @var{vec_type_out}, tree @var{vec_type_in})  This hook
> > should return the decl of a function that implements the  vectorized variant
> > of the function with the @code{combined_fn} code diff --git
> > a/gcc/doc/tm.texi.in b/gcc/doc/tm.texi.in index
> > 112462310b134705d860153294287cfd7d4af81d..d5a745a02acdf051ea1da1b04
> > 076d058c24ce093 100644
> > --- a/gcc/doc/tm.texi.in
> > +++ b/gcc/doc/tm.texi.in
> > @@ -4164,6 +4164,8 @@ address;  but often a machine-dependent strategy
> > can generate better code.
> >
> >  @hook TARGET_VECTORIZE_VEC_PERM_CONST
> >
> > +@hook TARGET_VECTORIZE_CAN_SPECIAL_DIV_BY_CONST
> > +
> >  @hook TARGET_VECTORIZE_BUILTIN_VECTORIZED_FUNCTION
> >
> >  @hook TARGET_VECTORIZE_BUILTIN_MD_VECTORIZED_FUNCTION
> > diff --git a/gcc/explow.cc b/gcc/explow.cc index
> > ddb4d6ae3600542f8d2bb5617cdd3933a9fae6c0..568e0eb1a158c696458ae678f
> > 5e346bf34ba0036 100644
> > --- a/gcc/explow.cc
> > +++ b/gcc/explow.cc
> > @@ -1037,7 +1037,7 @@ round_push (rtx size)
> >   TRUNC_DIV_EXPR.  */
> >size = expand_binop (Pmode, add_optab, size, alignm1_rtx,
> > NULL_RTX, 1, OPTAB_LIB_WIDEN);
> > -  size = expand_divm

RE: [PATCH 2/4]AArch64 Add implementation for pow2 bitmask division.

[Tamar Christina via Gcc-patches]

Ping

> -Original Message-
> From: Tamar Christina
> Sent: Monday, October 31, 2022 11:35 AM
> To: 'Tamar Christina' ; gcc-patches@gcc.gnu.org
> Cc: nd ; Richard Earnshaw ;
> Marcus Shawcroft ; Kyrylo Tkachov
> ; Richard Sandiford
> 
> Subject: RE: [PATCH 2/4]AArch64 Add implementation for pow2 bitmask
> division.
> 
> Hi All,
> 
> Ping, and updated patch based on mid-end changes.
> 
> Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
> 
> Ok for master?
> 
> Thanks,
> Tamar
> 
> gcc/ChangeLog:
> 
>   * config/aarch64/aarch64-simd.md
> (@aarch64_bitmask_udiv3): New.
>   * config/aarch64/aarch64.cc
> (aarch64_vectorize_can_special_div_by_constant): New.
> 
> gcc/testsuite/ChangeLog:
> 
>   * gcc.target/aarch64/div-by-bitmask.c: New test.
> 
> --- inline copy of patch ---
> 
> diff --git a/gcc/config/aarch64/aarch64-simd.md
> b/gcc/config/aarch64/aarch64-simd.md
> index
> 587a45d77721e1b39accbad7dbeca4d741eccb10..f4152160084d6b6f34bd69f0b
> a6386c1ab50f77e 100644
> --- a/gcc/config/aarch64/aarch64-simd.md
> +++ b/gcc/config/aarch64/aarch64-simd.md
> @@ -4831,6 +4831,65 @@ (define_expand
> "aarch64_hn2"
>}
>  )
> 
> +;; div optimizations using narrowings
> +;; we can do the division e.g. shorts by 255 faster by calculating it
> +as ;; (x + ((x + 257) >> 8)) >> 8 assuming the operation is done in ;;
> +double the precision of x.
> +;;
> +;; If we imagine a short as being composed of two blocks of bytes then
> +;; adding 257 or 0b_0001__0001 to the number is equivalen to ;;
> +adding 1 to each sub component:
> +;;
> +;;  short value of 16-bits
> +;; ┌──┬┐
> +;; │  ││
> +;; └──┴┘
> +;;   8-bit part1 ▲  8-bit part2   ▲
> +;;   ││
> +;;   ││
> +;;  +1   +1
> +;;
> +;; after the first addition, we have to shift right by 8, and narrow
> +the ;; results back to a byte.  Remember that the addition must be done
> +in ;; double the precision of the input.  Since 8 is half the size of a
> +short ;; we can use a narrowing halfing instruction in AArch64, addhn
> +which also ;; does the addition in a wider precision and narrows back
> +to a byte.  The ;; shift itself is implicit in the operation as it
> +writes back only the top ;; half of the result. i.e. bits 2*esize-1:esize.
> +;;
> +;; Since we have narrowed the result of the first part back to a byte,
> +for ;; the second addition we can use a widening addition, uaddw.
> +;;
> +;; For the finaly shift, since it's unsigned arithmatic we emit an ushr
> +by 8 ;; to shift and the vectorizer.
> +;;
> +;; The shift is later optimized by combine to a uzp2 with movi #0.
> +(define_expand "@aarch64_bitmask_udiv3"
> +  [(match_operand:VQN 0 "register_operand")
> +   (match_operand:VQN 1 "register_operand")
> +   (match_operand:VQN 2 "immediate_operand")]
> +  "TARGET_SIMD"
> +{
> +  unsigned HOST_WIDE_INT size
> += (1ULL << GET_MODE_UNIT_BITSIZE (mode)) - 1;
> +  if (!CONST_VECTOR_P (operands[2])
> +  || const_vector_encoded_nelts (operands[2]) != 1
> +  || size != UINTVAL (CONST_VECTOR_ELT (operands[2], 0)))
> +FAIL;
> +
> +  rtx addend = gen_reg_rtx (mode);
> +  rtx val = aarch64_simd_gen_const_vector_dup (mode, 1);
> +  emit_move_insn (addend, lowpart_subreg (mode, val,
> +mode));
> +  rtx tmp1 = gen_reg_rtx (mode);
> +  rtx tmp2 = gen_reg_rtx (mode);
> +  emit_insn (gen_aarch64_addhn (tmp1, operands[1], addend));
> +  unsigned bitsize = GET_MODE_UNIT_BITSIZE (mode);
> +  rtx shift_vector = aarch64_simd_gen_const_vector_dup (mode,
> +bitsize);
> +  emit_insn (gen_aarch64_uaddw (tmp2, operands[1], tmp1));
> +  emit_insn (gen_aarch64_simd_lshr (operands[0], tmp2,
> +shift_vector));
> +  DONE;
> +})
> +
>  ;; pmul.
> 
>  (define_insn "aarch64_pmul"
> diff --git a/gcc/config/aarch64/aarch64.cc b/gcc/config/aarch64/aarch64.cc
> index
> 4b486aeea90ea2afb9cdd96a4dbe15c5bb2abd7a..d3c3650d7d728f56adb65154
> 127dc7b72386c5a7 100644
> --- a/gcc/config/aarch64/aarch64.cc
> +++ b/gcc/config/aarch64/aarch64.cc
> @@ -24146,6 +24146,40 @@ aarch64_vectorize_vec_perm_const
> (machine_mode vmode, machine_mode op_mode,
>return ret;
>  }
> 
> +/* Implement TARGET_VECTORIZE_CAN_SPECIAL_DIV_BY_CONST.  */
> +
> +bool
> +aarch64_vectorize_can_special_div_by_constant (enum tree_code code,
> +tree vectype, wide_int cst,
> +rtx *output, rtx in0, rtx in1) {
> +  if (code != TRUNC_DIV_EXPR
> +  || !TYPE_UNSIGNED (vectype))
> +return false;
> +
> +  unsigned int flags = aarch64_classify_vector_mode (TYPE_MODE
> + (vectype));  if ((flags & VEC_ANY_SVE) && !TARGET_SVE2)
> +return false;
> +
> +  if (in0 == NULL_RTX && in1 == NULL_RTX)
> +{
> +  wide_int val = wi::add (cst, 1);
> +  int pow = wi::exact_log2 (val);
> +  return pow == (int)(element_precision (vectype)

RE: [PATCH 3/4]AArch64 Add SVE2 implementation for pow2 bitmask division

[Tamar Christina via Gcc-patches]

ping

> -Original Message-
> From: Tamar Christina
> Sent: Monday, October 31, 2022 11:35 AM
> To: Tamar Christina ; gcc-patches@gcc.gnu.org
> Cc: nd ; Richard Earnshaw ;
> Marcus Shawcroft ; Kyrylo Tkachov
> ; Richard Sandiford
> 
> Subject: RE: [PATCH 3/4]AArch64 Add SVE2 implementation for pow2
> bitmask division
> 
> Ping
> 
> > -Original Message-
> > From: Tamar Christina 
> > Sent: Friday, September 23, 2022 10:34 AM
> > To: gcc-patches@gcc.gnu.org
> > Cc: nd ; Richard Earnshaw ;
> > Marcus Shawcroft ; Kyrylo Tkachov
> > ; Richard Sandiford
> > 
> > Subject: [PATCH 3/4]AArch64 Add SVE2 implementation for pow2 bitmask
> > division
> >
> > Hi All,
> >
> > In plenty of image and video processing code it's common to modify
> > pixel values by a widening operation and then scale them back into
> > range by dividing by 255.
> >
> > This patch adds an named function to allow us to emit an optimized
> > sequence when doing an unsigned division that is equivalent to:
> >
> >x = y / (2 ^ (bitsize (y)/2)-1)
> >
> > For SVE2 this means we generate for:
> >
> > void draw_bitmap1(uint8_t* restrict pixel, uint8_t level, int n) {
> >   for (int i = 0; i < (n & -16); i+=1)
> > pixel[i] = (pixel[i] * level) / 0xff; }
> >
> > the following:
> >
> > mov z3.b, #1
> > .L3:
> > ld1bz0.h, p0/z, [x0, x3]
> > mul z0.h, p1/m, z0.h, z2.h
> > addhnb  z1.b, z0.h, z3.h
> > addhnb  z0.b, z0.h, z1.h
> > st1bz0.h, p0, [x0, x3]
> > inchx3
> > whilelo p0.h, w3, w2
> > b.any   .L3
> >
> > instead of:
> >
> > .L3:
> > ld1bz0.h, p1/z, [x0, x3]
> > mul z0.h, p0/m, z0.h, z1.h
> > umulh   z0.h, p0/m, z0.h, z2.h
> > lsr z0.h, z0.h, #7
> > st1bz0.h, p1, [x0, x3]
> > inchx3
> > whilelo p1.h, w3, w2
> > b.any   .L3
> >
> > Which results in significantly faster code.
> >
> > Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
> >
> > Ok for master?
> >
> > Thanks,
> > Tamar
> >
> > gcc/ChangeLog:
> >
> > * config/aarch64/aarch64-sve2.md
> > (@aarch64_bitmask_udiv3): New.
> >
> > gcc/testsuite/ChangeLog:
> >
> > * gcc.target/aarch64/sve2/div-by-bitmask_1.c: New test.
> >
> > --- inline copy of patch --
> > diff --git a/gcc/config/aarch64/aarch64-sve2.md
> > b/gcc/config/aarch64/aarch64-sve2.md
> > index
> >
> f138f4be4bcf74c1a4a6d5847ed831435246737f..4d097f7c405cc68a1d6cda5c234
> > a1023a6eba0d1 100644
> > --- a/gcc/config/aarch64/aarch64-sve2.md
> > +++ b/gcc/config/aarch64/aarch64-sve2.md
> > @@ -71,6 +71,7 @@
> >  ;;  [INT] Reciprocal approximation  ;;  [INT<-FP] Base-2
> > logarithm  ;;  [INT] Polynomial multiplication
> > +;;  [INT] Misc optab implementations
> >  ;;
> >  ;; == Permutation
> >  ;;  [INT,FP] General permutes
> > @@ -2312,6 +2313,47 @@ (define_insn "@aarch64_sve_"
> >"\t%0., %1., %2."
> >  )
> >
> > +;;
> > +-
> > +--
> > +-- ;;  [INT] Misc optab implementations ;;
> > +-
> > +--
> > +--
> > +;; Includes:
> > +;; - aarch64_bitmask_udiv
> > +;;
> > +-
> > +--
> > +--
> > +
> > +;; div optimizations using narrowings ;; we can do the division e.g.
> > +shorts by 255 faster by calculating it as ;; (x + ((x + 257) >> 8))
> > +>> 8 assuming the operation is done in ;; double the precision of x.
> > +;;
> > +;; See aarch64-simd.md for bigger explanation.
> > +(define_expand "@aarch64_bitmask_udiv3"
> > +  [(match_operand:SVE_FULL_HSDI 0 "register_operand")
> > +   (match_operand:SVE_FULL_HSDI 1 "register_operand")
> > +   (match_operand:SVE_FULL_HSDI 2 "immediate_operand")]
> > +  "TARGET_SVE2"
> > +{
> > +  unsigned HOST_WIDE_INT size
> > += (1ULL << GET_MODE_UNIT_BITSIZE (mode)) - 1;
> > +  if (!CONST_VECTOR_P (operands[2])
> > +  || const_vector_encoded_nelts (operands[2]) != 1
> > +  || size != UINTVAL (CONST_VECTOR_ELT (operands[2], 0)))
> > +FAIL;
> > +
> > +  rtx addend = gen_reg_rtx (mode);
> > +  rtx tmp1 = gen_reg_rtx (mode);
> > +  rtx tmp2 = gen_reg_rtx (mode);
> > +  rtx val = aarch64_simd_gen_const_vector_dup (mode, 1);
> > +  emit_move_insn (addend, lowpart_subreg (mode, val,
> > +mode));
> > +  emit_insn (gen_aarch64_sve (UNSPEC_ADDHNB, mode, tmp1,
> > operands[1],
> > + addend));
> > +  emit_insn (gen_aarch64_sve (UNSPEC_ADDHNB, mode, tmp2,
> > operands[1],
> > + lowpart_subreg (mode, tmp1,
> > + mode)));
> > +  emit_move_insn (operands[0],
> > + lowpart_subreg (mode, tmp2,
> > mode));
> > +  DONE;
> > +})
> > +
> >  ;;
> >
> ==
> > ===
> >  ;; == Permutation
> >  ;;
> >
> =

RE: [PATCH 4/4]AArch64 sve2: rewrite pack + NARROWB + NARROWB to NARROWB + NARROWT

[Tamar Christina via Gcc-patches]

ping

> -Original Message-
> From: Tamar Christina
> Sent: Monday, October 31, 2022 11:35 AM
> To: Tamar Christina ; gcc-patches@gcc.gnu.org
> Cc: Richard Earnshaw ; nd ;
> Richard Sandiford ; Marcus Shawcroft
> 
> Subject: RE: [PATCH 4/4]AArch64 sve2: rewrite pack + NARROWB +
> NARROWB to NARROWB + NARROWT
> 
> Ping
> 
> > -Original Message-
> > From: Gcc-patches  > bounces+tamar.christina=arm@gcc.gnu.org> On Behalf Of Tamar
> > Christina via Gcc-patches
> > Sent: Friday, September 23, 2022 10:34 AM
> > To: gcc-patches@gcc.gnu.org
> > Cc: Richard Earnshaw ; nd ;
> > Richard Sandiford ; Marcus Shawcroft
> > 
> > Subject: [PATCH 4/4]AArch64 sve2: rewrite pack + NARROWB + NARROWB
> to
> > NARROWB + NARROWT
> >
> > Hi All,
> >
> > This adds an RTL pattern for when two NARROWB instructions are being
> > combined with a PACK.  The second NARROWB is then transformed into a
> > NARROWT.
> >
> > For the example:
> >
> > void draw_bitmap1(uint8_t* restrict pixel, uint8_t level, int n) {
> >   for (int i = 0; i < (n & -16); i+=1)
> > pixel[i] += (pixel[i] * level) / 0xff; }
> >
> > we generate:
> >
> > addhnb  z6.b, z0.h, z4.h
> > addhnb  z5.b, z1.h, z4.h
> > addhnb  z0.b, z0.h, z6.h
> > addhnt  z0.b, z1.h, z5.h
> > add z0.b, z0.b, z2.b
> >
> > instead of:
> >
> > addhnb  z6.b, z1.h, z4.h
> > addhnb  z5.b, z0.h, z4.h
> > addhnb  z1.b, z1.h, z6.h
> > addhnb  z0.b, z0.h, z5.h
> > uzp1z0.b, z0.b, z1.b
> > add z0.b, z0.b, z2.b
> >
> > Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
> >
> > Ok for master?
> >
> > Thanks,
> > Tamar
> >
> > gcc/ChangeLog:
> >
> > * config/aarch64/aarch64-sve2.md
> > (*aarch64_sve_pack_):
> > New.
> > * config/aarch64/iterators.md (binary_top): New.
> >
> > gcc/testsuite/ChangeLog:
> >
> > * gcc.dg/vect/vect-div-bitmask-4.c: New test.
> > * gcc.target/aarch64/sve2/div-by-bitmask_2.c: New test.
> >
> > --- inline copy of patch --
> > diff --git a/gcc/config/aarch64/aarch64-sve2.md
> > b/gcc/config/aarch64/aarch64-sve2.md
> > index
> >
> ab5dcc369481311e5bd68a1581265e1ce99b4b0f..0ee46c8b0d43467da4a6b98a
> > d3c41e5d05d8cf38 100644
> > --- a/gcc/config/aarch64/aarch64-sve2.md
> > +++ b/gcc/config/aarch64/aarch64-sve2.md
> > @@ -1600,6 +1600,25 @@ (define_insn
> > "@aarch64_sve_"
> >"\t%0., %2., %3."
> >  )
> >
> > +(define_insn_and_split "*aarch64_sve_pack_"
> > +  [(set (match_operand: 0 "register_operand" "=w")
> > +   (unspec:
> > + [(match_operand:SVE_FULL_HSDI 1 "register_operand" "w")
> > +  (subreg:SVE_FULL_HSDI (unspec:
> > +[(match_operand:SVE_FULL_HSDI 2 "register_operand" "w")
> > + (match_operand:SVE_FULL_HSDI 3 "register_operand" "w")]
> > +SVE2_INT_BINARY_NARROWB) 0)]
> > + UNSPEC_PACK))]
> > +  "TARGET_SVE2"
> > +  "#"
> > +  "&& true"
> > +  [(const_int 0)]
> > +{
> > +  rtx tmp = lowpart_subreg (mode, operands[1],
> > mode);
> > +  emit_insn (gen_aarch64_sve
> > (, mode,
> > + operands[0], tmp, operands[2], operands[3]));
> > +})
> > +
> >  ;;
> > --
> > ---
> >  ;;  [INT] Narrowing right shifts
> >  ;;
> > --
> > --- diff --git a/gcc/config/aarch64/iterators.md
> > b/gcc/config/aarch64/iterators.md index
> >
> 0dd9dc66f7ccd78acacb759662d0cd561cd5b4ef..37d8161a33b1c399d80be82af
> > a67613a087389d4 100644
> > --- a/gcc/config/aarch64/iterators.md
> > +++ b/gcc/config/aarch64/iterators.md
> > @@ -3589,6 +3589,11 @@ (define_int_attr brk_op [(UNSPEC_BRKA "a")
> > (UNSPEC_BRKB "b")
> >
> >  (define_int_attr sve_pred_op [(UNSPEC_PFIRST "pfirst") (UNSPEC_PNEXT
> > "pnext")])
> >
> > +(define_int_attr binary_top [(UNSPEC_ADDHNB "UNSPEC_ADDHNT")
> > +(UNSPEC_RADDHNB "UNSPEC_RADDHNT")
> > +(UNSPEC_RSUBHNB "UNSPEC_RSUBHNT")
> > +(UNSPEC_SUBHNB "UNSPEC_SUBHNT")])
> > +
> >  (define_int_attr sve_int_op [(UNSPEC_ADCLB "adclb")
> >  (UNSPEC_ADCLT "adclt")
> >  (UNSPEC_ADDHNB "addhnb")
> > diff --git a/gcc/testsuite/gcc.dg/vect/vect-div-bitmask-4.c
> > b/gcc/testsuite/gcc.dg/vect/vect-div-bitmask-4.c
> > new file mode 100644
> > index
> >
> ..0df08bda6fd3e33280307ea15
> > c82dd9726897cfd
> > --- /dev/null
> > +++ b/gcc/testsuite/gcc.dg/vect/vect-div-bitmask-4.c
> > @@ -0,0 +1,26 @@
> > +/* { dg-require-effective-target vect_int } */
> > +/* { dg-additional-options "-fno-vect-cost-model" { target
> > +aarch64*-*-* } } */
> > +
> > +#include 
> > +#include "tree-vect.h"
> > +
> > +#define N 50
> > +#define TYPE uint32_t
> > +
> > +__attribute__((noipa, noinline, optimize("O1"))) void fun1(TYPE*
> > +restrict pixel, TYPE level, int n) {
> > +  for (int i = 0; i < n; i+=1)
> > +

Re: [RFC] propgation leap over memory copy for struct

[Richard Biener via Gcc-patches]

On Wed, 9 Nov 2022, Jiufu Guo wrote:

> Jiufu Guo via Gcc-patches  writes:
> 
> > Richard Biener  writes:
> >
> >> On Tue, 1 Nov 2022, Jiufu Guo wrote:
> >>
> >>> Segher Boessenkool  writes:
> >>> 
> >>> > On Mon, Oct 31, 2022 at 04:13:38PM -0600, Jeff Law wrote:
> >>> >> On 10/30/22 20:42, Jiufu Guo via Gcc-patches wrote:
> >>> >> >We know that for struct variable assignment, memory copy may be used.
> >>> >> >And for memcpy, we may load and store more bytes as possible at one 
> >>> >> >time.
> >>> >> >While it may be not best here:
> >>> >
> >>> >> So the first question in my mind is can we do better at the gimple 
> >>> >> phase?  For the second case in particular can't we just "return a" 
> >>> >> rather than copying a into  then returning ?  This 
> >>> >> feels 
> >>> >> a lot like the return value optimization from C++.  I'm not sure if it 
> >>> >> applies to the first case or not, it's been a long time since I looked 
> >>> >> at NRV optimizations, but it might be worth poking around in there a 
> >>> >> bit 
> >>> >> (tree-nrv.cc).
> >>> >
> >>> > If it is a bigger struct you end up with quite a lot of stuff in
> >>> > registers.  GCC will eventually put that all in memory so it will work
> >>> > out fine in the end, but you are likely to get inefficient code.
> >>> Yes.  We may need to use memory to save regiters for big struct.
> >>> Small struct may be practical to use registers.  We may leverage the
> >>> idea that: some type of small struct are passing to function through
> >>> registers. 
> >>> 
> >>> >
> >>> > OTOH, 8 bytes isn't as big as we would want these days, is it?  So it
> >>> > would be useful to put smaller temportaries, say 32 bytes and smaller,
> >>> > in registers instead of in memory.
> >>> I think you mean:  we should try to registers to avoid memory accesing,
> >>> and using registers would be ok for more bytes memcpy(32bytes).
> >>> Great sugguestion, thanks a lot!
> >>> 
> >>> Like below idea:
> >>> [r100:TI, r101:TI] = src;  //Or r100:OI/OO = src;
> >>> dest = [r100:TI, r101:TI];
> >>> 
> >>> Currently, for 8bytes structure, we are using TImode for it.
> >>> And subreg/fwprop/cse passes are able to optimize it as expected.
> >>> Two concerns here: larger int modes(OI/OO/..) may be not introduced yet;
> >>> I'm not sure if current infrastructure supports to use two more
> >>> registers for one structure.
> >>> 
> >>> >
> >>> >> But even so, these kinds of things are still bound to happen, so it's 
> >>> >> probably worth thinking about if we can do better in RTL as well.
> >>> >
> >>> > Always.  It is a mistake to think that having better high-level
> >>> > optimisations means that you don't need good low-level optimisations
> >>> > anymore: in fact deficiencies there become more glaringly apparent if
> >>> > the early pipeline opts become better :-)
> >>> Understant, thanks :)
> >>> 
> >>> >
> >>> >> The first thing that comes to my mind is to annotate memcpy calls that 
> >>> >> are structure assignments.  The idea here is that we may want to 
> >>> >> expand 
> >>> >> a memcpy differently in those cases.   Changing how we expand an 
> >>> >> opaque 
> >>> >> memcpy call is unlikely to be beneficial in most cases.  But changing 
> >>> >> how we expand a structure copy may be beneficial by exposing the 
> >>> >> underlying field values.   This would roughly correspond to your 
> >>> >> method 
> >>> >> #1.
> >>> >> 
> >>> >> Or instead of changing how we expand, teach the optimizers about these 
> >>> >> annotated memcpy calls -- they're just a a copy of each field.   
> >>> >> That's 
> >>> >> how CSE and the propagators could treat them. After some point we'd 
> >>> >> lower them in the usual ways, but at least early in the RTL pipeline 
> >>> >> we 
> >>> >> could keep them as annotated memcpy calls.  This roughly corresponds 
> >>> >> to 
> >>> >> your second suggestion.
> >>> >
> >>> > Ideally this won't ever make it as far as RTL, if the structures do not
> >>> > need to go via memory.  All high-level optimissations should have been
> >>> > done earlier, and hopefully it was not expand tiself that forced stuff
> >>> > into memory!  :-/
> >>> Currently, after early gimple optimization, the struct member accessing
> >>> may still need to be in memory (if the mode of the struct is BLK).
> >>> For example:
> >>> 
> >>> _Bool foo (const A a) { return a.a[0] > 1.0; }
> >>> 
> >>> The optimized gimple would be:
> >>>   _1 = a.a[0];
> >>>   _3 = _1 > 1.0e+0;
> >>>   return _3;
> >>> 
> >>> During expand to RTL, parm 'a' is store to memory from arg regs firstly,
> >>> and "a.a[0]" is also reading from memory.  It may be better to use
> >>> "f1" for "a.a[0]" here.
> >>> 
> >>> Maybe, method3 is similar with your idea: using "parallel:BLK {DF;DF;DF; 
> >>> DF}"
> >>> for the struct (BLK may be changed), and using 4 DF registers to access
> >>> the structure in expand pass.
> >>
> >> I think for cases like this it might be a good idea to perform
> >> SRA-like analysis at RTL 

[COMMITTED] Implement op[12]_range operators for PLUS_EXPR and MINUS_EXPR.

[Aldy Hernandez via Gcc-patches]

We can implement the op[12]_range entries for plus and minus in terms
of each other.  These are adapted from the integer versions.

gcc/ChangeLog:

* range-op-float.cc (foperator_plus::op1_range): New.
(foperator_plus::op2_range): New.
(foperator_minus::op1_range): New.
(foperator_minus::op2_range): New.
---
 gcc/range-op-float.cc | 45 +++
 1 file changed, 45 insertions(+)

diff --git a/gcc/range-op-float.cc b/gcc/range-op-float.cc
index d52e971f84e..44db81c1c1e 100644
--- a/gcc/range-op-float.cc
+++ b/gcc/range-op-float.cc
@@ -1862,6 +1862,29 @@ foperator_unordered_equal::op1_range (frange &r, tree 
type,
 
 class foperator_plus : public range_operator_float
 {
+  using range_operator_float::op1_range;
+  using range_operator_float::op2_range;
+public:
+  virtual bool op1_range (frange &r, tree type,
+ const frange &lhs,
+ const frange &op2,
+ relation_trio = TRIO_VARYING) const final override
+  {
+if (lhs.undefined_p ())
+  return false;
+range_op_handler minus (MINUS_EXPR, type);
+if (!minus)
+  return false;
+return minus.fold_range (r, type, lhs, op2);
+  }
+  virtual bool op2_range (frange &r, tree type,
+ const frange &lhs,
+ const frange &op1,
+ relation_trio = TRIO_VARYING) const final override
+  {
+return op1_range (r, type, lhs, op1);
+  }
+private:
   void rv_fold (REAL_VALUE_TYPE &lb, REAL_VALUE_TYPE &ub, bool &maybe_nan,
tree type,
const REAL_VALUE_TYPE &lh_lb,
@@ -1886,6 +1909,28 @@ class foperator_plus : public range_operator_float
 
 class foperator_minus : public range_operator_float
 {
+  using range_operator_float::op1_range;
+  using range_operator_float::op2_range;
+public:
+  virtual bool op1_range (frange &r, tree type,
+ const frange &lhs,
+ const frange &op2,
+ relation_trio = TRIO_VARYING) const final override
+  {
+if (lhs.undefined_p ())
+  return false;
+return fop_plus.fold_range (r, type, lhs, op2);
+  }
+  virtual bool op2_range (frange &r, tree type,
+ const frange &lhs,
+ const frange &op1,
+ relation_trio = TRIO_VARYING) const final override
+  {
+if (lhs.undefined_p ())
+  return false;
+return fold_range (r, type, op1, lhs);
+  }
+private:
   void rv_fold (REAL_VALUE_TYPE &lb, REAL_VALUE_TYPE &ub, bool &maybe_nan,
tree type,
const REAL_VALUE_TYPE &lh_lb,
-- 
2.38.1

[PATCH (pushed)] sphinx: fix building if sphinx-build is missing

[Martin Liška]

I noticed I modified Makefile.in files in the Sphinx series. While I was
supposed to modifiky Makefile.am and use automake. I'm going to fix that soon.

Martin

libgomp/ChangeLog:

* Makefile.in: Build info pages conditionally.

libitm/ChangeLog:

* Makefile.in: Build info pages conditionally.

libquadmath/ChangeLog:

* Makefile.in: Build info pages conditionally.
---
 libgomp/Makefile.in | 5 -
 libitm/Makefile.in  | 5 -
 libquadmath/Makefile.in | 4 +++-
 3 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/libgomp/Makefile.in b/libgomp/Makefile.in
index 9d1787d8458..0c016980c3d 100644
--- a/libgomp/Makefile.in
+++ b/libgomp/Makefile.in
@@ -1304,7 +1304,10 @@ stamp-geninsrc: doc/info/texinfo/libgomp.info
@touch $@
 
 doc/info/texinfo/libgomp.info: $(SPHINX_FILES)
-   + make -C $(srcdir)/../doc info SOURCEDIR=$(abs_srcdir)/doc 
BUILDDIR=$(abs_doc_builddir)/info SPHINXBUILD=$(SPHINX_BUILD)
+   + if [ x$(HAS_SPHINX_BUILD) = xhas-sphinx-build ]; then \
+ make -C $(srcdir)/../doc info SOURCEDIR=$(abs_srcdir)/doc 
BUILDDIR=$(abs_doc_builddir)/info SPHINXBUILD=$(SPHINX_BUILD); \
+   else true; fi
+
 
 # target overrides
 -include $(tmake_file)
diff --git a/libitm/Makefile.in b/libitm/Makefile.in
index 38a7e5bf731..f51858db8c7 100644
--- a/libitm/Makefile.in
+++ b/libitm/Makefile.in
@@ -1121,7 +1121,10 @@ stamp-geninsrc: doc/info/texinfo/libitm.info
@touch $@
 
 doc/info/texinfo/libitm.info: $(SPHINX_FILES)
-   + make -C $(srcdir)/../doc info SOURCEDIR=$(abs_srcdir)/doc 
BUILDDIR=$(abs_doc_builddir)/info SPHINXBUILD=$(SPHINX_BUILD)
+   + if [ x$(HAS_SPHINX_BUILD) = xhas-sphinx-build ]; then \
+ make -C $(srcdir)/../doc info SOURCEDIR=$(abs_srcdir)/doc 
BUILDDIR=$(abs_doc_builddir)/info SPHINXBUILD=$(SPHINX_BUILD); \
+   else true; fi
+
 
 # GNU Make needs to see an explicit $(MAKE) variable in the command it
 # runs to enable its job server during parallel builds.  Hence the
diff --git a/libquadmath/Makefile.in b/libquadmath/Makefile.in
index d551f56ce62..864ebc6048a 100644
--- a/libquadmath/Makefile.in
+++ b/libquadmath/Makefile.in
@@ -1374,7 +1374,9 @@ SPHINX_FILES:=$(RST_FILES) $(SPHINX_CONFIG_FILES)
 export BUGURL=$(REPORT_BUGS_TO)
 
 doc/info/texinfo/libquadmath.info: $(SPHINX_FILES)
-   + make -C $(srcdir)/../doc info SOURCEDIR=$(abs_srcdir)/doc 
BUILDDIR=$(abs_doc_builddir)/info SPHINXBUILD=$(SPHINX_BUILD)
+   + if [ x$(HAS_SPHINX_BUILD) = xhas-sphinx-build ]; then \
+ make -C $(srcdir)/../doc info SOURCEDIR=$(abs_srcdir)/doc 
BUILDDIR=$(abs_doc_builddir)/info SPHINXBUILD=$(SPHINX_BUILD); \
+   else true; fi
 
 # GNU Make needs to see an explicit $(MAKE) variable in the command it
 # runs to enable its job server during parallel builds.  Hence the
-- 
2.38.0

Re: [RFC] propgation leap over memory copy for struct

[Jiufu Guo via Gcc-patches]

Hi,

Richard Biener  writes:

> On Mon, Oct 31, 2022 at 11:14 PM Jeff Law via Gcc-patches
>  wrote:
>>
>>
>> On 10/30/22 20:42, Jiufu Guo via Gcc-patches wrote:
>> > Hi,
>> >
>> > We know that for struct variable assignment, memory copy may be used.
>> > And for memcpy, we may load and store more bytes as possible at one time.
>> > While it may be not best here:
>> > 1. Before/after stuct variable assignment, the vaiable may be operated.
>> > And it is hard for some optimizations to leap over memcpy.  Then some 
>> > struct
>> > operations may be sub-optimimal.  Like the issue in PR65421.
>> > 2. The size of struct is constant mostly, the memcpy would be expanded.  
>> > Using
>> > small size to load/store and executing in parallel may not slower than 
>> > using
>> > large size to loat/store. (sure, more registers may be used for smaller 
>> > bytes.)
>> >
>> >
>> > In PR65421, For source code as below:
>> > t.c
>> > #define FN 4
>> > typedef struct { double a[FN]; } A;
>> >
>> > A foo (const A *a) { return *a; }
>> > A bar (const A a) { return a; }
>>
>> So the first question in my mind is can we do better at the gimple
>> phase?  For the second case in particular can't we just "return a"
>> rather than copying a into  then returning ?  This feels
>> a lot like the return value optimization from C++.  I'm not sure if it
>> applies to the first case or not, it's been a long time since I looked
>> at NRV optimizations, but it might be worth poking around in there a bit
>> (tree-nrv.cc).
>>
>>
>> But even so, these kinds of things are still bound to happen, so it's
>> probably worth thinking about if we can do better in RTL as well.
>>
>>
>> The first thing that comes to my mind is to annotate memcpy calls that
>> are structure assignments.  The idea here is that we may want to expand
>> a memcpy differently in those cases.   Changing how we expand an opaque
>> memcpy call is unlikely to be beneficial in most cases.  But changing
>> how we expand a structure copy may be beneficial by exposing the
>> underlying field values.   This would roughly correspond to your method #1.
>>
>> Or instead of changing how we expand, teach the optimizers about these
>> annotated memcpy calls -- they're just a a copy of each field.   That's
>> how CSE and the propagators could treat them. After some point we'd
>> lower them in the usual ways, but at least early in the RTL pipeline we
>> could keep them as annotated memcpy calls.  This roughly corresponds to
>> your second suggestion.
>
> In the end it depends on the access patterns so some analysis like SRA
> performs would be nice.  The issue with expanding memcpy on GIMPLE
> is that we currently cannot express 'rep; movb;' or other target specific
> sequences from the cpymem like optabs on GIMPLE and recovering those
> from piecewise copies on RTL is going to be difficult.
Actually, it is a special memcpy. It is generated during expanding the
struct assignment(expand_assignment/store_expr/emit_block_move).
We may introduce a function block_move_for_record for struct type.  And
this function could be a target hook to generate specificed sequences.
For example:
r125:DF=[r112:DI+0x20]
r126:DF=[r112:DI+0x28]
[r112:DI]=r125:DF
[r112:DI+0x8]=r126:DF

After expanding, following passes(cse/prop/dse/..) could optimize the
insn sequences. e.g "[r112:DI+0x20]=f1;r125:DF=[r112:DI+0x20];
[r112:DI]=r125:DF;r129:DF=[r112:DI]" ==> "r129:DF=f1"

And if the small reading/writing insns are still occur in late passes
e.g. combine, we would recover the isnsn to better sequence:
r125:DF=[r112:DI+0x20];r126:DF=[r112:DI+0x28]
==>
r155:V2DI=[r112:DI+0x20];

Any comments? Thanks!

BR,
Jeff(Jiufu)


>
>>
>> jeff
>>
>>
>>

Re: [PATCH] RISC-V: costs: handle BSWAP

[Philipp Tomsich]

On Wed, 9 Nov 2022 at 05:43, Andrew Pinski  wrote:
>
> On Tue, Nov 8, 2022 at 7:16 PM Palmer Dabbelt  wrote:
> >
> > On Tue, 08 Nov 2022 18:57:26 PST (-0800), jeffreya...@gmail.com wrote:
> > >
> > > On 11/8/22 12:54, Philipp Tomsich wrote:
> > >> The BSWAP operation is not handled in rtx_costs. Add it.
> > >>
> > >> With Zbb, BSWAP for XLEN is a single instruction; for smaller modes,
> > >> it will expand into two.
> > >>
> > >> gcc/ChangeLog:
> > >>
> > >>  * config/riscv/riscv.c (rtx_costs): Add BSWAP.
> > >
> > > OK.
> >
> > It's riscv_rtx_costs.
> >
> > (I don't usually read ChangeLog entries that closely, just happened to
> > stumble on it when poking around.)
>
> Using contrib/git-commit-mklog.py can help here to make sure you
> always get the correct format for the changelog and it does a decent
> job of figuring out function names too.
> You can also use contrib/gcc-git-customization.sh to install it such
> that you can use it when doing git commits.
> After invoking that inside the GCC git; you can just do "git
> gcc-commit-mklog " Where  would be what you normally put for
> "git commit" (but as if in the toplevel directory).

We always pass them through contrib/mklog,py (or git-commit-mklog.py,
which invokes it) anyway, but (as the ".c" in the filename indicates)
this one hasn't been refreshed in over a year's time.
Don't worry, this will need to get adjusted again once I merge it (as
the commit hooks won't let it pass).

Philipp.

Re: [PATCH] RISC-V: costs: handle BSWAP

[Philipp Tomsich]

Applied to master, with the commit-message regenerated as:

gcc/ChangeLog:

* config/riscv/riscv.cc (riscv_rtx_costs): Add BSWAP.

Thanks,
Philipp.

On Wed, 9 Nov 2022 at 04:15, Palmer Dabbelt  wrote:
>
> On Tue, 08 Nov 2022 18:57:26 PST (-0800), jeffreya...@gmail.com wrote:
> >
> > On 11/8/22 12:54, Philipp Tomsich wrote:
> >> The BSWAP operation is not handled in rtx_costs. Add it.
> >>
> >> With Zbb, BSWAP for XLEN is a single instruction; for smaller modes,
> >> it will expand into two.
> >>
> >> gcc/ChangeLog:
> >>
> >>  * config/riscv/riscv.c (rtx_costs): Add BSWAP.
> >
> > OK.
>
> It's riscv_rtx_costs.
>
> (I don't usually read ChangeLog entries that closely, just happened to
> stumble on it when poking around.)
>
>
> >
> > Jeff

Re: [PATCH v2] RISC-V missing __builtin_lceil and __builtin_lfloor

[Xi Ruoyao via Gcc-patches]

On Mon, 2022-11-07 at 20:36 -0800, Kevin Lee wrote:
> The patch in 
> https://gcc.gnu.org/pipermail/gcc-patches/2022-August/599755.html was
> corrupted. I am resending the cleaner version as patch v2. Thank you! 

Hi Kevin,

I "shamelessly copied" your idea in
https://gcc.gnu.org/pipermail/gcc-patches/2022-November/605456.html. 
During the review we found an issue.

Consider

$ cat x.c
long x(double d)
{
return __builtin_ceil(d);
}

With the patch:

$ ./gcc/cc1 x.c -nostdinc -mabi=lp64d -march=rv64g -O 
-fno-fp-int-builtin-inexact
$ cat x.s
.file   "x.c"
.option nopic
.text
.align  2
.globl  x
.type   x, @function
x:
fcvt.l.d a0,fa0,rup
ret
.size   x, .-x
    .ident  "GCC: (GNU) 13.0.0 20221109 (experimental)"
.section.note.GNU-stack,"",@progbits

-fno-fp-int-builtin-inexact does not allow __builtin_ceil to raise
inexact exception.  But fcvt.l.d may raise one.

> gcc/ChangeLog:
> 
> Michael Collison 
> * config/riscv/iterators.md (RINT): Additional iterators.
> (rint_pattern): Additional attributes.
> (rint_rm): Ditto.
> * config/riscv/riscv.md: New attributes.
> 
> gcc/testsuite/ChangeLog:
> 
> Kevin Lee 
> * gcc.target/riscv/lfloor-lceil.c: New test.
> ---
>  gcc/config/riscv/iterators.md |  8 +-
>  gcc/config/riscv/riscv.md |  3 +
>  gcc/testsuite/gcc.target/riscv/lfloor-lceil.c | 79
> +++
>  3 files changed, 87 insertions(+), 3 deletions(-)
>  create mode 100644 gcc/testsuite/gcc.target/riscv/lfloor-lceil.c
> 
> diff --git a/gcc/config/riscv/iterators.md
> b/gcc/config/riscv/iterators.md
> index 50380ecfac9..3dd705eaf81 100644
> --- a/gcc/config/riscv/iterators.md
> +++ b/gcc/config/riscv/iterators.md
> @@ -233,9 +233,11 @@ (define_code_attr bitmanip_insn [(smin "min")
>  ;; --
> -
>  
>  ;; Iterator and attributes for floating-point rounding instructions.
> -(define_int_iterator RINT [UNSPEC_LRINT UNSPEC_LROUND])
> -(define_int_attr rint_pattern [(UNSPEC_LRINT "rint") (UNSPEC_LROUND
> "round")])
> -(define_int_attr rint_rm [(UNSPEC_LRINT "dyn") (UNSPEC_LROUND
> "rmm")])
> +(define_int_iterator RINT [UNSPEC_LRINT UNSPEC_LROUND UNSPEC_LCEIL
> UNSPEC_LFLOOR])
> +(define_int_attr rint_pattern [(UNSPEC_LRINT "rint") (UNSPEC_LROUND
> "round")
> + (UNSPEC_LCEIL "ceil") (UNSPEC_LFLOOR
> "floor")])
> +(define_int_attr rint_rm [(UNSPEC_LRINT "dyn") (UNSPEC_LROUND "rmm")
> +    (UNSPEC_LCEIL "rup") (UNSPEC_LFLOOR "rdn")])
>  
>  ;; Iterator and attributes for quiet comparisons.
>  (define_int_iterator QUIET_COMPARISON [UNSPEC_FLT_QUIET
> UNSPEC_FLE_QUIET])
> diff --git a/gcc/config/riscv/riscv.md b/gcc/config/riscv/riscv.md
> index 798f7370a08..07e72af8950 100644
> --- a/gcc/config/riscv/riscv.md
> +++ b/gcc/config/riscv/riscv.md
> @@ -60,6 +60,9 @@ (define_c_enum "unspec" [
>    UNSPEC_FMIN
>    UNSPEC_FMAX
>  
> +  UNSPEC_LCEIL
> +  UNSPEC_LFLOOR
> +
>    ;; Stack tie
>    UNSPEC_TIE
>  ])
> diff --git a/gcc/testsuite/gcc.target/riscv/lfloor-lceil.c
> b/gcc/testsuite/gcc.target/riscv/lfloor-lceil.c
> new file mode 100644
> index 000..4715de746fb
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/riscv/lfloor-lceil.c
> @@ -0,0 +1,79 @@
> +/* { dg-do compile } */
> +/* { dg-options "-march=rv64gc -mabi=lp64d" } */
> +/* { dg-skip-if "" { *-*-* } { "-O0" "-Og" } } */
> +
> +int
> +ceil1(float i)
> +{
> +  return __builtin_lceil(i);
> +}
> +
> +long
> +ceil2(float i)
> +{
> +  return __builtin_lceil(i);
> +}
> +
> +long long
> +ceil3(float i)
> +{
> +  return __builtin_lceil(i);
> +}
> +
> +int
> +ceil4(double i)
> +{
> +  return __builtin_lceil(i);
> +}
> +
> +long
> +ceil5(double i)
> +{
> +  return __builtin_lceil(i);
> +}
> +
> +long long
> +ceil6(double i)
> +{
> +  return __builtin_lceil(i);
> +}
> +
> +int
> +floor1(float i)
> +{
> +  return __builtin_lfloor(i);
> +}
> +
> +long
> +floor2(float i)
> +{
> +  return __builtin_lfloor(i);
> +}
> +
> +long long
> +floor3(float i)
> +{
> +  return __builtin_lfloor(i);
> +}
> +
> +int
> +floor4(double i)
> +{
> +  return __builtin_lfloor(i);
> +}
> +
> +long
> +floor5(double i)
> +{
> +  return __builtin_lfloor(i);
> +}
> +
> +long long
> +floor6(double i)
> +{
> +  return __builtin_lfloor(i);
> +}
> +
> +/* { dg-final { scan-assembler-times "fcvt.l.s" 6 } } */
> +/* { dg-final { scan-assembler-times "fcvt.l.d" 6 } } */
> +/* { dg-final { scan-assembler-not "call" } } */

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

Re: [PATCH] Restore RTL alias analysis for hard frame pointer

[Eric Botcazou via Gcc-patches]

> Oh, do you have a testcase suitable for the testsuite?

C guality testcase attached, it fails on x86/Linux with -m32 on the gcc-12 
branch (which does not have the fix):

FAIL: gcc.dg/guality/param-6.c   -O1  -DPREVENT_OPTIMIZATION  line 15 i == 5
FAIL: gcc.dg/guality/param-6.c   -O2  -DPREVENT_OPTIMIZATION  line 15 i == 5
FAIL: gcc.dg/guality/param-6.c   -O3 -g  -DPREVENT_OPTIMIZATION  line 15 i == 
5
FAIL: gcc.dg/guality/param-6.c   -Os  -DPREVENT_OPTIMIZATION  line 15 i == 5
FAIL: gcc.dg/guality/param-6.c   -O2 -flto -fno-use-linker-plugin -flto-
partition=none  -DPREVENT_OPTIMIZATION line 15 i == 5
FAIL: gcc.dg/guality/param-6.c   -O2 -flto -fuse-linker-plugin -fno-fat-lto-
objects  -DPREVENT_OPTIMIZATION line 15 i == 5

but passes on the mainline (which has the fix) and on the gcc-11 branch (which 
does not have the issue).  The fix also eliminates other regressions:

-FAIL: gcc.dg/guality/drap.c   -Os  -DPREVENT_OPTIMIZATION  line 21 a == 5
-FAIL: gcc.dg/guality/drap.c   -Os  -DPREVENT_OPTIMIZATION  line 22 b == 6
-FAIL: gcc.dg/guality/pr43051-1.c   -Os  -DPREVENT_OPTIMIZATION  line 35 v == 
1
-FAIL: gcc.dg/guality/pr43051-1.c   -Os  -DPREVENT_OPTIMIZATION  line 36 e == 
&a[1]
-FAIL: gcc.dg/guality/pr43051-1.c   -Os  -DPREVENT_OPTIMIZATION  line 40 v == 
1
-FAIL: gcc.dg/guality/pr43051-1.c   -Os  -DPREVENT_OPTIMIZATION  line 41 e == 
&a[1]
-FAIL: gcc.dg/guality/pr43177.c   -Os  -DPREVENT_OPTIMIZATION  line 15 x == 7
-FAIL: gcc.dg/guality/pr54519-3.c   -Os  -DPREVENT_OPTIMIZATION  line 20 y == 
25
-FAIL: gcc.dg/guality/pr54519-3.c   -Os  -DPREVENT_OPTIMIZATION  line 20 z == 
6
-FAIL: gcc.dg/guality/pr54519-3.c   -Os  -DPREVENT_OPTIMIZATION  line 23 y == 
117
-FAIL: gcc.dg/guality/pr54519-3.c   -Os  -DPREVENT_OPTIMIZATION  line 23 z == 
8
-FAIL: gcc.dg/guality/pr54519-4.c   -Os  -DPREVENT_OPTIMIZATION  line 17 y == 
25
-FAIL: gcc.dg/guality/pr54796.c   -O1  -DPREVENT_OPTIMIZATION  line 17 a == 5
-FAIL: gcc.dg/guality/pr54796.c   -O1  -DPREVENT_OPTIMIZATION  line 17 b == 6
-FAIL: gcc.dg/guality/pr54796.c   -O1  -DPREVENT_OPTIMIZATION  line 17 c == 5
-FAIL: gcc.dg/guality/pr54796.c   -O2  -DPREVENT_OPTIMIZATION  line 17 a == 5
-FAIL: gcc.dg/guality/pr54796.c   -O2  -DPREVENT_OPTIMIZATION  line 17 b == 6
-FAIL: gcc.dg/guality/pr54796.c   -O2  -DPREVENT_OPTIMIZATION  line 17 c == 5
-FAIL: gcc.dg/guality/pr54796.c   -O3 -g  -DPREVENT_OPTIMIZATION  line 17 a == 
5
-FAIL: gcc.dg/guality/pr54796.c   -O3 -g  -DPREVENT_OPTIMIZATION  line 17 b == 
6
-FAIL: gcc.dg/guality/pr54796.c   -O3 -g  -DPREVENT_OPTIMIZATION  line 17 c == 
5
-FAIL: gcc.dg/guality/pr54796.c   -Os  -DPREVENT_OPTIMIZATION  line 17 a == 5
-FAIL: gcc.dg/guality/pr54796.c   -Os  -DPREVENT_OPTIMIZATION  line 17 b == 6
-FAIL: gcc.dg/guality/pr54796.c   -Os  -DPREVENT_OPTIMIZATION  line 17 c == 5
-FAIL: gcc.dg/guality/pr54796.c   -O2 -flto -fno-use-linker-plugin -flto-
partition=none  -DPREVENT_OPTIMIZATION line 17 a == 5
-FAIL: gcc.dg/guality/pr54796.c   -O2 -flto -fno-use-linker-plugin -flto-
partition=none  -DPREVENT_OPTIMIZATION line 17 b == 6
-FAIL: gcc.dg/guality/pr54796.c   -O2 -flto -fno-use-linker-plugin -flto-
partition=none  -DPREVENT_OPTIMIZATION line 17 c == 5
-FAIL: gcc.dg/guality/sra-1.c   -Os  -DPREVENT_OPTIMIZATION  line 43 a.j == 14
-FAIL: gcc.dg/guality/vla-1.c   -O1  -DPREVENT_OPTIMIZATION  line 24 i == 5
-FAIL: gcc.dg/guality/vla-1.c   -O2  -DPREVENT_OPTIMIZATION  line 24 i == 5
-FAIL: gcc.dg/guality/vla-1.c   -O3 -g  -DPREVENT_OPTIMIZATION  line 24 i == 5
-FAIL: gcc.dg/guality/vla-1.c   -Os  -DPREVENT_OPTIMIZATION  line 24 i == 5
-FAIL: gcc.dg/guality/vla-1.c   -O2 -flto -fno-use-linker-plugin -flto-
partition=none  -DPREVENT_OPTIMIZATION line 24 i == 5

present on the gcc-12 branch wrt the gcc-11 branch (apparently nobody really 
cares about the guality testsuite on x86/Linux).


* gcc.dg/guality/param-6.c: New test.

-- 
Eric Botcazou/* { dg-do run { target i?86-*-* x86_64-*-* } } */
/* { dg-options "-g" } */

void __attribute__((noipa)) bar (void *p)
{}

void __attribute__((noipa)) foo (int i)
{
  void *p = __builtin_alloca (i);

  asm volatile ("" : : : "ebx");

  bar (p); /* { dg-final { gdb-test . "i" "5" } } */
}

int main (void)
{
  foo (5);
  return 0;
}

Re: [PATCH] invoke: RISC-V's -march doesn't take ISA strings

[Christoph Müllner]

On Wed, Nov 9, 2022 at 4:00 AM Palmer Dabbelt  wrote:

> On Tue, 08 Nov 2022 05:40:10 PST (-0800), christoph.muell...@vrull.eu
> wrote:
> > On Mon, Nov 7, 2022 at 8:01 PM Palmer Dabbelt 
> wrote:
> >
> >> The docs say we take ISA strings, but that's never really been the case:
> >> at a bare minimum we've required lower case strings, but there's
> >> generally been some subtle differences as well in things like version
> >> handling and such.  We talked about removing the lower case requirement
> >> in the last GNU toolchain meeting and we've always called other
> >> differences just bugs.  We don't have profile support yet, but based on
> >> the discussions on the RISC-V lists it looks like we're going to have
> >> some differences there as well.
> >
> >
> >> So let's just stop pretending these are ISA strings.  That's been a
> >> headache for years now, if we're meant to just be ISA-string-like here
> >> then we don't have to worry about all these long-tail ISA string parsing
> >> issues.
> >>
> >
> > You are right, we should first properly specify the -march string,
> > before we talk about the implementation details of the parser.
> >
> > I tried to collect all the recent change requests and undocumented
> > properties of the -march string and worked on a first draft
> specification.
> > As the -march flag should share a common behavior across different
> > compilers and tools, I've made a PR to the RISC-V toolchain-conventions
> > repo:
> >   https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/26
> >
> > Do you mind if we continue the discussion there?
>
> IMO trying to handle this with another RISC-V spec is a waste of time:
> we've spent many years trying to follow the specs here, it's pretty
> clear they're just not meant to be read in that level of detail.  This
> sort of problem is all over the place in RISC-V land, moving to a
> different spec doesn't fix the problem.
>

I created the documentation as a response of your comment in your patch
about
the flag being "woefully under-documented".
You can call my attempt to address this a "waste of time", but a more
constructive
approach would be appreciated.

The reason I created a PR over there in the riscv-toolchain-conventions
repo is,
that it is the agreed place to document the common behavior of RISC-V
compilers/tools (e.g. command line flags).
I.e. to ensure that LLVM developers can also contribute to a common
solution.

If I understand correctly, you want something between the documentation that
you wrote as part of this patch and the PR that I created.
If so, then please let me know the details you don't want to have documented
in my proposal.

Anyway, thanks for your feedback.
I'll quote/reference it in the PR so it won't get lost.


>
> >> Link: https://lists.riscv.org/g/sig-toolchains/message/486
> >>
> >> gcc/ChangeLog
> >>
> >> doc/invoke.texi (RISC-V): -march doesn't take ISA strings.
> >>
> >> ---
> >>
> >> This is now woefully under-documented, as we can't even fall back on the
> >> "it's just an ISA string" excuse any more.  I'm happy to go document
> >> that, but figured I'd just send this along now so we can have the
> >> discussion.
> >> ---
> >>  gcc/doc/invoke.texi | 8 
> >>  1 file changed, 4 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
> >> index 94a2e20cfc1..780b0364c52 100644
> >> --- a/gcc/doc/invoke.texi
> >> +++ b/gcc/doc/invoke.texi
> >> @@ -28617,11 +28617,11 @@ Produce code conforming to version 20191213.
> >>  The default is @option{-misa-spec=20191213} unless GCC has been
> configured
> >>  with @option{--with-isa-spec=} specifying a different default version.
> >>
> >> -@item -march=@var{ISA-string}
> >> +@item -march=@var{target-string}
> >>  @opindex march
> >> -Generate code for given RISC-V ISA (e.g.@: @samp{rv64im}).  ISA
> strings
> >> must be
> >> -lower-case.  Examples include @samp{rv64i}, @samp{rv32g}, @samp{rv32e},
> >> and
> >> -@samp{rv32imaf}.
> >> +Generate code for given target (e.g.@: @samp{rv64im}).  Target strings
> >> are
> >> +similar to ISA strings, but must be lower-case.  Examples include
> >> @samp{rv64i},
> >> +@samp{rv32g}, @samp{rv32e}, and @samp{rv32imaf}.
> >>
> >>  When @option{-march=} is not specified, use the setting from
> >> @option{-mcpu}.
> >>
> >> --
> >> 2.38.1
> >>
> >>
>

[PATCH (pushed)] avr: sphinx: port gen-avr-mmcu to RST

[Martin Liška]

This ports generation of avr-mcus to RST.

Pushed,
Martin

gcc/ChangeLog:

* Makefile.in: Add vpath default for .rst files.
* config/avr/avr-devices.cc: For port RST.
* config/avr/avr-mcus.def: Update path.
* config/avr/gen-avr-mmcu-texi.cc: Moved to...
* config/avr/gen-avr-mmcu-rst.cc: ...here.
* config/avr/t-avr: Update to rst.
* doc/gcc/gcc-command-options/machine-dependent-options/avr-mmcu.rst: 
Re-generate.
---
 gcc/Makefile.in   |  7 
 gcc/config/avr/avr-devices.cc | 42 +--
 gcc/config/avr/avr-mcus.def   |  2 +-
 ...n-avr-mmcu-texi.cc => gen-avr-mmcu-rst.cc} | 33 +++
 gcc/config/avr/t-avr  |  6 +--
 .../machine-dependent-options/avr-mmcu.rst|  3 +-
 6 files changed, 49 insertions(+), 44 deletions(-)
 rename gcc/config/avr/{gen-avr-mmcu-texi.cc => gen-avr-mmcu-rst.cc} (80%)

diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index 428078fbcf9..059606c37d5 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -113,6 +113,13 @@ target_objdir := $(toplevel_builddir)/$(target_subdir)
 # Directory where sources are, from where we are.
 VPATH = @srcdir@
 
+# We define a vpath for the sources of the .rst files here because they
+# are split between multiple directories and we would rather use one implicit
+# pattern rule for everything.
+# This vpath could be extended within the Make-lang fragments.
+
+vpath %.rst $(gcc_docdir)
+
 # 
 # UNSORTED
 # 
diff --git a/gcc/config/avr/avr-devices.cc b/gcc/config/avr/avr-devices.cc
index aa284217f50..611b35f7a27 100644
--- a/gcc/config/avr/avr-devices.cc
+++ b/gcc/config/avr/avr-devices.cc
@@ -64,54 +64,54 @@ avr_arch_types[] =
 };
 
 const avr_arch_info_t
-avr_texinfo[] =
+avr_rst[] =
 {
   { ARCH_AVR1,
 "This ISA is implemented by the minimal AVR core and supported "
 "for assembler only." },
   { ARCH_AVR2,
-"``Classic'' devices with up to 8@tie{}KiB of program memory." },
+"\"Classic\" devices with up to 8 |nbsp| KiB of program memory." },
   { ARCH_AVR25,
-"``Classic'' devices with up to 8@tie{}KiB of program memory and with "
-"the @code{MOVW} instruction." },
+"\"Classic\" devices with up to 8 |nbsp| KiB of program memory and with "
+"the ``MOVW`` instruction." },
   { ARCH_AVR3,
-"``Classic'' devices with 16@tie{}KiB up to 64@tie{}KiB of "
+"\"Classic\" devices with 16 |nbsp| KiB up to 64 |nbsp| KiB of "
 "program memory." },
   { ARCH_AVR31,
-"``Classic'' devices with 128@tie{}KiB of program memory." },
+"\"Classic\" devices with 128 |nbsp| KiB of program memory." },
   { ARCH_AVR35,
-"``Classic'' devices with 16@tie{}KiB up to 64@tie{}KiB of "
-"program memory and with the @code{MOVW} instruction." },
+"\"Classic\" devices with 16 |nbsp| KiB up to 64 |nbsp| KiB of "
+"program memory and with the ``MOVW`` instruction." },
   { ARCH_AVR4,
-"``Enhanced'' devices with up to 8@tie{}KiB of program memory." },
+"\"Enhanced\" devices with up to 8 |nbsp| KiB of program memory." },
   { ARCH_AVR5,
-"``Enhanced'' devices with 16@tie{}KiB up to 64@tie{}KiB of "
+"\"Enhanced\" devices with 16 |nbsp| KiB up to 64 |nbsp| KiB of "
 "program memory." },
   { ARCH_AVR51,
-"``Enhanced'' devices with 128@tie{}KiB of program memory." },
+"\"Enhanced\" devices with 128 |nbsp| KiB of program memory." },
   { ARCH_AVR6,
-"``Enhanced'' devices with 3-byte PC, i.e.@: with more than 128@tie{}KiB "
+"\"Enhanced\" devices with 3-byte PC, i.e.: with more than 128 |nbsp| KiB "
 "of program memory." },
   { ARCH_AVRTINY,
-"``TINY'' Tiny core devices with 512@tie{}B up to 4@tie{}KiB of "
+"\"TINY\" Tiny core devices with 512 |nbsp| B up to 4 |nbsp| KiB of "
 "program memory." },
   { ARCH_AVRXMEGA2,
-"``XMEGA'' devices with more than 8@tie{}KiB and up to 64@tie{}KiB "
+"\"XMEGA\" devices with more than 8 |nbsp| KiB and up to 64 |nbsp| KiB "
 "of program memory." },
   { ARCH_AVRXMEGA3,
-"``XMEGA'' devices with up to 64@tie{}KiB of combined program memory "
+"\"XMEGA\" devices with up to 64 |nbsp| KiB of combined program memory "
 "and RAM, and with program memory visible in the RAM address space." },
   { ARCH_AVRXMEGA4,
-"``XMEGA'' devices with more than 64@tie{}KiB and up to 128@tie{}KiB "
+"\"XMEGA\" devices with more than 64 |nbsp| KiB and up to 128 |nbsp| KiB "
 "of program memory." },
   { ARCH_AVRXMEGA5,
-"``XMEGA'' devices with more than 64@tie{}KiB and up to 128@tie{}KiB "
-"of program memory and more than 64@tie{}KiB of RAM." },
+"\"XMEGA\" devices with more than 64 |nbsp| KiB and up to 128 |nbsp| KiB "
+"of program memory and more than 64 |nbsp| KiB of RAM." },
   { ARCH_AVRXMEGA6,
-"``XMEGA'' devices with more than 128@tie{}KiB of program memory." },
+"\"XMEGA\" devices with more than 128 |nbsp| KiB of program memory

Re: Announcement: Porting the Docs to Sphinx - tomorrow

[Mark Wielaard]

Hi,

On Wed, Nov 09, 2022 at 08:49:22AM +0100, Richard Biener via Gcc wrote:
> On Wed, Nov 9, 2022 at 1:09 AM Sam James via Gcc-patches
>  wrote:
> > > On 9 Nov 2022, at 00:00, Joseph Myers  wrote:
> > > On Tue, 8 Nov 2022, Sam James via Gcc wrote:
> >
> > If that's your expectation, that's fine, but I'd regard it as pretty
> > serious if one didn't build, and I don't remember a time when it didn't.
> >
> > It's not like it's that much use if it fails to build on a bog-standard
> > amd64 platform anyway, as if nothing else, you'd get a deluge
> > of duplicate bug reports.
> 
> I'd say that doing a trunk snapshot build every day as CI would be nice, we
> can then publish one once a week, skipping days where the build failed.
> 
> For release branches having generated files in the snapshots would be
> even more useful and I very much hope the build there always succeeds.

The current buildbot CI jobs already run various builds which just do
a simple non-bootstrap build (plus some that do a full build and make
check) to see if things work:
https://builder.sourceware.org/buildbot/#/builders?tags=gcc&tags=gcc-full

If we make sure the relevant machine/containers contain the necessary
prerequirements then can add the configure flags to some builders to
make sure the docs are generated:
https://sourceware.org/git/?p=builder.git;a=blob;f=README

And make it sent warning emails (to gcc-testresults) when things break.

Cheers,

Mark

Re: [PATCH] invoke: RISC-V's -march doesn't take ISA strings

[Philipp Tomsich]

On Wed, 9 Nov 2022 at 04:00, Palmer Dabbelt  wrote:
>
> On Tue, 08 Nov 2022 05:40:10 PST (-0800), christoph.muell...@vrull.eu wrote:
> > On Mon, Nov 7, 2022 at 8:01 PM Palmer Dabbelt  wrote:
> >
> >> The docs say we take ISA strings, but that's never really been the case:
> >> at a bare minimum we've required lower case strings, but there's
> >> generally been some subtle differences as well in things like version
> >> handling and such.  We talked about removing the lower case requirement
> >> in the last GNU toolchain meeting and we've always called other
> >> differences just bugs.  We don't have profile support yet, but based on
> >> the discussions on the RISC-V lists it looks like we're going to have
> >> some differences there as well.
> >
> >
> >> So let's just stop pretending these are ISA strings.  That's been a
> >> headache for years now, if we're meant to just be ISA-string-like here
> >> then we don't have to worry about all these long-tail ISA string parsing
> >> issues.
> >>
> >
> > You are right, we should first properly specify the -march string,
> > before we talk about the implementation details of the parser.
> >
> > I tried to collect all the recent change requests and undocumented
> > properties of the -march string and worked on a first draft specification.
> > As the -march flag should share a common behavior across different
> > compilers and tools, I've made a PR to the RISC-V toolchain-conventions
> > repo:
> >   https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/26
> >
> > Do you mind if we continue the discussion there?
>
> IMO trying to handle this with another RISC-V spec is a waste of time:
> we've spent many years trying to follow the specs here, it's pretty
> clear they're just not meant to be read in that level of detail.  This
> sort of problem is all over the place in RISC-V land, moving to a
> different spec doesn't fix the problem.

Consider this repo as "hosted by RISC-V" and not as a RISC-V
specification (e.g., it doesn't go through the lifecycle and never
gets ratified/approved).  Maybe that's easier to digest.

Within RISC-V, some participants try hard to enforce a requirement for
end-to-end implementations before a spec lands.  This continually
leads to some friction between the software community within RISC-V
and those that "just need the specs done".  If you see something in a
spec going for public review (or even better: before it goes to public
review and is at the committee sign-off stage) that is underspecified,
let us know and we can request remedial action: the ABI effort in Zc
is a good example of this.

Anytime someone tries to skip these requirements, I point them to the
'bset' instruction (which—even though most people assume it—does not
implement 'a | (1 << b)'; instead it implements 'a | (1 << (b &
(XLEN-1)))').  Things like that get caught only if there are
end-to-end software implementations to allow experimentation and
review with various workloads and by a wide community.

Philipp.




> >> Link: https://lists.riscv.org/g/sig-toolchains/message/486
> >>
> >> gcc/ChangeLog
> >>
> >> doc/invoke.texi (RISC-V): -march doesn't take ISA strings.
> >>
> >> ---
> >>
> >> This is now woefully under-documented, as we can't even fall back on the
> >> "it's just an ISA string" excuse any more.  I'm happy to go document
> >> that, but figured I'd just send this along now so we can have the
> >> discussion.
> >> ---
> >>  gcc/doc/invoke.texi | 8 
> >>  1 file changed, 4 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
> >> index 94a2e20cfc1..780b0364c52 100644
> >> --- a/gcc/doc/invoke.texi
> >> +++ b/gcc/doc/invoke.texi
> >> @@ -28617,11 +28617,11 @@ Produce code conforming to version 20191213.
> >>  The default is @option{-misa-spec=20191213} unless GCC has been configured
> >>  with @option{--with-isa-spec=} specifying a different default version.
> >>
> >> -@item -march=@var{ISA-string}
> >> +@item -march=@var{target-string}
> >>  @opindex march
> >> -Generate code for given RISC-V ISA (e.g.@: @samp{rv64im}).  ISA strings
> >> must be
> >> -lower-case.  Examples include @samp{rv64i}, @samp{rv32g}, @samp{rv32e},
> >> and
> >> -@samp{rv32imaf}.
> >> +Generate code for given target (e.g.@: @samp{rv64im}).  Target strings
> >> are
> >> +similar to ISA strings, but must be lower-case.  Examples include
> >> @samp{rv64i},
> >> +@samp{rv32g}, @samp{rv32e}, and @samp{rv32imaf}.
> >>
> >>  When @option{-march=} is not specified, use the setting from
> >> @option{-mcpu}.
> >>
> >> --
> >> 2.38.1
> >>
> >>

RE: [PATCH 1/4]middle-end Support not decomposing specific divisions during vectorization.

[Kyrylo Tkachov via Gcc-patches]

Hi Tamar,

> -Original Message-
> From: Gcc-patches  bounces+kyrylo.tkachov=arm@gcc.gnu.org> On Behalf Of Tamar
> Christina via Gcc-patches
> Sent: Friday, September 23, 2022 10:33 AM
> To: gcc-patches@gcc.gnu.org
> Cc: nd ; rguent...@suse.de
> Subject: [PATCH 1/4]middle-end Support not decomposing specific divisions
> during vectorization.
> 
> Hi All,
> 
> In plenty of image and video processing code it's common to modify pixel
> values
> by a widening operation and then scale them back into range by dividing by
> 255.
> 
> e.g.:
> 
>x = y / (2 ^ (bitsize (y)/2)-1
> 
> This patch adds a new target hook can_special_div_by_const, similar to
> can_vec_perm which can be called to check if a target will handle a particular
> division in a special way in the back-end.
> 
> The vectorizer will then vectorize the division using the standard tree code
> and at expansion time the hook is called again to generate the code for the
> division.
> 
> Alot of the changes in the patch are to pass down the tree operands in all
> paths
> that can lead to the divmod expansion so that the target hook always has the
> type of the expression you're expanding since the types can change the
> expansion.
> 
> Bootstrapped Regtested on aarch64-none-linux-gnu, x86_64-pc-linux-gnu
> and no issues.
> 
> Ok for master?
> 
> Thanks,
> Tamar
> 
> gcc/ChangeLog:
> 
>   * expmed.h (expand_divmod): Pass tree operands down in addition
> to RTX.
>   * expmed.cc (expand_divmod): Likewise.
>   * explow.cc (round_push, align_dynamic_address): Likewise.
>   * expr.cc (force_operand, expand_expr_divmod): Likewise.
>   * optabs.cc (expand_doubleword_mod,
> expand_doubleword_divmod):
>   Likewise.
>   * target.h: Include tree-core.
>   * target.def (can_special_div_by_const): New.
>   * targhooks.cc (default_can_special_div_by_const): New.
>   * targhooks.h (default_can_special_div_by_const): New.
>   * tree-vect-generic.cc (expand_vector_operation): Use it.
>   * doc/tm.texi.in: Document it.
>   * doc/tm.texi: Regenerate.
>   * tree-vect-patterns.cc (vect_recog_divmod_pattern): Check for
> support.
>   * tree-vect-stmts.cc (vectorizable_operation): Likewise.
> 
> gcc/testsuite/ChangeLog:
> 
>   * gcc.dg/vect/vect-div-bitmask-1.c: New test.
>   * gcc.dg/vect/vect-div-bitmask-2.c: New test.
>   * gcc.dg/vect/vect-div-bitmask-3.c: New test.
>   * gcc.dg/vect/vect-div-bitmask.h: New file.
> 
> --- inline copy of patch --
> diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi
> index
> 92bda1a7e14a3c9ea63e151e4a49a818bf4d1bdb..adba9fe97a9b43729c5e86d
> 244a2a23e76cac097 100644
> --- a/gcc/doc/tm.texi
> +++ b/gcc/doc/tm.texi
> @@ -6112,6 +6112,22 @@ instruction pattern.  There is no need for the
> hook to handle these two
>  implementation approaches itself.
>  @end deftypefn
> 
> +@deftypefn {Target Hook} bool
> TARGET_VECTORIZE_CAN_SPECIAL_DIV_BY_CONST (enum @var{tree_code},
> tree @var{vectype}, tree @var{treeop0}, tree @var{treeop1}, rtx
> *@var{output}, rtx @var{in0}, rtx @var{in1})
> +This hook is used to test whether the target has a special method of
> +division of vectors of type @var{vectype} using the two operands
> @code{treeop0},
> +and @code{treeop1} and producing a vector of type @var{vectype}.  The
> division
> +will then not be decomposed by the and kept as a div.

I think the grammar here is wonky, can you reword this sentence please?
(I was just reading this patch to understand the optab semantics futher in the 
series)
Thanks,
Kyrill

> +
> +When the hook is being used to test whether the target supports a special
> +divide, @var{in0}, @var{in1}, and @var{output} are all null.  When the hook
> +is being used to emit a division, @var{in0} and @var{in1} are the source
> +vectors of type @var{vecttype} and @var{output} is the destination vector
> of
> +type @var{vectype}.
> +
> +Return true if the operation is possible, emitting instructions for it
> +if rtxes are provided and updating @var{output}.
> +@end deftypefn
> +
>  @deftypefn {Target Hook} tree
> TARGET_VECTORIZE_BUILTIN_VECTORIZED_FUNCTION (unsigned
> @var{code}, tree @var{vec_type_out}, tree @var{vec_type_in})
>  This hook should return the decl of a function that implements the
>  vectorized variant of the function with the @code{combined_fn} code
> diff --git a/gcc/doc/tm.texi.in b/gcc/doc/tm.texi.in
> index
> 112462310b134705d860153294287cfd7d4af81d..d5a745a02acdf051ea1da1b
> 04076d058c24ce093 100644
> --- a/gcc/doc/tm.texi.in
> +++ b/gcc/doc/tm.texi.in
> @@ -4164,6 +4164,8 @@ address;  but often a machine-dependent strategy
> can generate better code.
> 
>  @hook TARGET_VECTORIZE_VEC_PERM_CONST
> 
> +@hook TARGET_VECTORIZE_CAN_SPECIAL_DIV_BY_CONST
> +
>  @hook TARGET_VECTORIZE_BUILTIN_VECTORIZED_FUNCTION
> 
>  @hook TARGET_VECTORIZE_BUILTIN_MD_VECTORIZED_FUNCTION
> diff --git a/gcc/explow.cc b/gcc/explow.cc
> index
> ddb4d6ae3600542f8d2bb5617cdd3933a9fae6c0..568e0eb1a158c696458ae67
> 8f5

Re: [PATCH] Restore RTL alias analysis for hard frame pointer

[Richard Biener via Gcc-patches]

> Am 09.11.2022 um 10:49 schrieb Eric Botcazou :
> 
> 
>> 
>> Oh, do you have a testcase suitable for the testsuite?
> 
> C guality testcase attached, it fails on x86/Linux with -m32 on the gcc-12 
> branch (which does not have the fix):
> 
> FAIL: gcc.dg/guality/param-6.c   -O1  -DPREVENT_OPTIMIZATION  line 15 i == 5
> FAIL: gcc.dg/guality/param-6.c   -O2  -DPREVENT_OPTIMIZATION  line 15 i == 5
> FAIL: gcc.dg/guality/param-6.c   -O3 -g  -DPREVENT_OPTIMIZATION  line 15 i == 
> 5
> FAIL: gcc.dg/guality/param-6.c   -Os  -DPREVENT_OPTIMIZATION  line 15 i == 5
> FAIL: gcc.dg/guality/param-6.c   -O2 -flto -fno-use-linker-plugin -flto-
> partition=none  -DPREVENT_OPTIMIZATION line 15 i == 5
> FAIL: gcc.dg/guality/param-6.c   -O2 -flto -fuse-linker-plugin -fno-fat-lto-
> objects  -DPREVENT_OPTIMIZATION line 15 i == 5
> 
> but passes on the mainline (which has the fix) and on the gcc-11 branch 
> (which 
> does not have the issue).  The fix also eliminates other regressions:
> 
> -FAIL: gcc.dg/guality/drap.c   -Os  -DPREVENT_OPTIMIZATION  line 21 a == 5
> -FAIL: gcc.dg/guality/drap.c   -Os  -DPREVENT_OPTIMIZATION  line 22 b == 6
> -FAIL: gcc.dg/guality/pr43051-1.c   -Os  -DPREVENT_OPTIMIZATION  line 35 v == 
> 1
> -FAIL: gcc.dg/guality/pr43051-1.c   -Os  -DPREVENT_OPTIMIZATION  line 36 e == 
> &a[1]
> -FAIL: gcc.dg/guality/pr43051-1.c   -Os  -DPREVENT_OPTIMIZATION  line 40 v == 
> 1
> -FAIL: gcc.dg/guality/pr43051-1.c   -Os  -DPREVENT_OPTIMIZATION  line 41 e == 
> &a[1]
> -FAIL: gcc.dg/guality/pr43177.c   -Os  -DPREVENT_OPTIMIZATION  line 15 x == 7
> -FAIL: gcc.dg/guality/pr54519-3.c   -Os  -DPREVENT_OPTIMIZATION  line 20 y == 
> 25
> -FAIL: gcc.dg/guality/pr54519-3.c   -Os  -DPREVENT_OPTIMIZATION  line 20 z == 
> 6
> -FAIL: gcc.dg/guality/pr54519-3.c   -Os  -DPREVENT_OPTIMIZATION  line 23 y == 
> 117
> -FAIL: gcc.dg/guality/pr54519-3.c   -Os  -DPREVENT_OPTIMIZATION  line 23 z == 
> 8
> -FAIL: gcc.dg/guality/pr54519-4.c   -Os  -DPREVENT_OPTIMIZATION  line 17 y == 
> 25
> -FAIL: gcc.dg/guality/pr54796.c   -O1  -DPREVENT_OPTIMIZATION  line 17 a == 5
> -FAIL: gcc.dg/guality/pr54796.c   -O1  -DPREVENT_OPTIMIZATION  line 17 b == 6
> -FAIL: gcc.dg/guality/pr54796.c   -O1  -DPREVENT_OPTIMIZATION  line 17 c == 5
> -FAIL: gcc.dg/guality/pr54796.c   -O2  -DPREVENT_OPTIMIZATION  line 17 a == 5
> -FAIL: gcc.dg/guality/pr54796.c   -O2  -DPREVENT_OPTIMIZATION  line 17 b == 6
> -FAIL: gcc.dg/guality/pr54796.c   -O2  -DPREVENT_OPTIMIZATION  line 17 c == 5
> -FAIL: gcc.dg/guality/pr54796.c   -O3 -g  -DPREVENT_OPTIMIZATION  line 17 a 
> == 
> 5
> -FAIL: gcc.dg/guality/pr54796.c   -O3 -g  -DPREVENT_OPTIMIZATION  line 17 b 
> == 
> 6
> -FAIL: gcc.dg/guality/pr54796.c   -O3 -g  -DPREVENT_OPTIMIZATION  line 17 c 
> == 
> 5
> -FAIL: gcc.dg/guality/pr54796.c   -Os  -DPREVENT_OPTIMIZATION  line 17 a == 5
> -FAIL: gcc.dg/guality/pr54796.c   -Os  -DPREVENT_OPTIMIZATION  line 17 b == 6
> -FAIL: gcc.dg/guality/pr54796.c   -Os  -DPREVENT_OPTIMIZATION  line 17 c == 5
> -FAIL: gcc.dg/guality/pr54796.c   -O2 -flto -fno-use-linker-plugin -flto-
> partition=none  -DPREVENT_OPTIMIZATION line 17 a == 5
> -FAIL: gcc.dg/guality/pr54796.c   -O2 -flto -fno-use-linker-plugin -flto-
> partition=none  -DPREVENT_OPTIMIZATION line 17 b == 6
> -FAIL: gcc.dg/guality/pr54796.c   -O2 -flto -fno-use-linker-plugin -flto-
> partition=none  -DPREVENT_OPTIMIZATION line 17 c == 5
> -FAIL: gcc.dg/guality/sra-1.c   -Os  -DPREVENT_OPTIMIZATION  line 43 a.j == 14
> -FAIL: gcc.dg/guality/vla-1.c   -O1  -DPREVENT_OPTIMIZATION  line 24 i == 5
> -FAIL: gcc.dg/guality/vla-1.c   -O2  -DPREVENT_OPTIMIZATION  line 24 i == 5
> -FAIL: gcc.dg/guality/vla-1.c   -O3 -g  -DPREVENT_OPTIMIZATION  line 24 i == 5
> -FAIL: gcc.dg/guality/vla-1.c   -Os  -DPREVENT_OPTIMIZATION  line 24 i == 5
> -FAIL: gcc.dg/guality/vla-1.c   -O2 -flto -fno-use-linker-plugin -flto-
> partition=none  -DPREVENT_OPTIMIZATION line 24 i == 5
> 
> present on the gcc-12 branch wrt the gcc-11 branch (apparently nobody really 
> cares about the guality testsuite on x86/Linux).

Thanks a lot, OK.

Richard 

> 
> 
>* gcc.dg/guality/param-6.c: New test.
> 
> -- 
> Eric Botcazou
> 

[PATCH] Fix up foperator_abs::op1_range [PR107569]

[Jakub Jelinek via Gcc-patches]

Hi!

foperator_abs::op1_range works except for the NaN handling,
from:
[frange] double [-Inf, 
1.79769313486231570814527423731704356798070567525844996599e+308 
(0x0.f8p+1024)]
lhs it computes r
[frange] double 
[-1.79769313486231570814527423731704356798070567525844996599e+308 
(-0x0.f8p+1024), 
1.79769313486231570814527423731704356798070567525844996599e+308 
(0x0.f8p+1024)] +-NAN
which is correct except for the +-NAN part.
For r before the final step it makes sure to add -NAN if there is +NAN
in the lhs range, but the final r.union_ makes it unconditional +-NAN,
because the frange ctor sets +-NAN.
So, I think we need to clear it (or have some set variant which
says not to set NAN).

This patch fixes that, but isn't enough to fix the PR, something in
the assumptions handling is still broken (and the PR has other parts).

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

2022-11-09  Jakub Jelinek  

PR tree-optimization/107569
* range-op-float.cc (foperator_abs::op1_range): Clear NaNs
from the negatives frange before unioning it into r.

--- gcc/range-op-float.cc.jj2022-11-06 11:56:27.138137781 +0100
+++ gcc/range-op-float.cc   2022-11-08 18:13:18.026974667 +0100
@@ -1280,9 +1280,10 @@ foperator_abs::op1_range (frange &r, tre
 return true;
   // Then add the negative of each pair:
   // ABS(op1) = [5,20] would yield op1 => [-20,-5][5,20].
-  r.union_ (frange (type,
-   real_value_negate (&positives.upper_bound ()),
-   real_value_negate (&positives.lower_bound (;
+  frange negatives (type, real_value_negate (&positives.upper_bound ()),
+   real_value_negate (&positives.lower_bound ()));
+  negatives.clear_nan ();
+  r.union_ (negatives);
   return true;
 }
 

Jakub

[DOCS] sphinx: align documentation links with project names

[Martin Liška]

And add missing documentation.

Pushed.
---
 htdocs/onlinedocs/index.html | 160 +++
 1 file changed, 69 insertions(+), 91 deletions(-)

diff --git a/htdocs/onlinedocs/index.html b/htdocs/onlinedocs/index.html
index a64c9813..cfa8bf5a 100644
--- a/htdocs/onlinedocs/index.html
+++ b/htdocs/onlinedocs/index.html
@@ -1561,101 +1561,79 @@ existing release.
 
   User-Level Documentation
   
-https://gcc.gnu.org/install/";>GCC Installation 
Instructions
-https://gcc.gnu.org/onlinedocs/gcc/";>GCC Manual (https://gcc.gnu.org/onlinedocs/gcc.pdf";>also in
-   PDF or https://gcc.gnu.org/onlinedocs/gcc.ps.gz";>PostScript or https://gcc.gnu.org/onlinedocs/gcc-html.tar.gz";>an
-   HTML tarball)
-https://gcc.gnu.org/onlinedocs/gfortran/";>GNU Fortran
-   Manual (https://gcc.gnu.org/onlinedocs/gfortran.pdf";>also in
-   PDF or https://gcc.gnu.org/onlinedocs/gfortran.ps.gz";>PostScript 
or https://gcc.gnu.org/onlinedocs/gfortran-html.tar.gz";>an
-   HTML tarball)
-https://gcc.gnu.org/onlinedocs/cpp/";>CPP Manual (https://gcc.gnu.org/onlinedocs/cpp.pdf";>also in
-   PDF or https://gcc.gnu.org/onlinedocs/cpp.ps.gz";>PostScript or https://gcc.gnu.org/onlinedocs/cpp-html.tar.gz";>an
-   HTML tarball)
-https://gcc.gnu.org/onlinedocs/gnat_rm/";>GNAT Reference 
Manual (https://gcc.gnu.org/onlinedocs/gnat_rm.pdf";>also in
-   PDF or https://gcc.gnu.org/onlinedocs/gnat_rm.ps.gz";>PostScript 
or https://gcc.gnu.org/onlinedocs/gnat_rm-html.tar.gz";>an
-   HTML tarball)
-https://gcc.gnu.org/onlinedocs/gnat_ugn/";>GNAT User's Guide
-   for Native Platforms / Unix and Windows (https://gcc.gnu.org/onlinedocs/gnat_ugn.pdf";>also in
-   PDF or https://gcc.gnu.org/onlinedocs/gnat_ugn.ps.gz";>PostScript 
or https://gcc.gnu.org/onlinedocs/gnat_ugn-html.tar.gz";>an
-   HTML tarball)
-https://gcc.gnu.org/onlinedocs/gccgo/";>GCCGO Manual (https://gcc.gnu.org/onlinedocs/gccgo.pdf";>also in
-   PDF or https://gcc.gnu.org/onlinedocs/gccgo.ps.gz";>PostScript or 
https://gcc.gnu.org/onlinedocs/gccgo-html.tar.gz";>an
-   HTML tarball)
-https://gcc.gnu.org/onlinedocs/libgomp/";>GNU Offloading and
-   Multi Processing Runtime Library Manual (https://gcc.gnu.org/onlinedocs/libgomp.pdf";>also in
-   PDF or https://gcc.gnu.org/onlinedocs/libgomp.ps.gz";>PostScript 
or https://gcc.gnu.org/onlinedocs/libgomp-html.tar.gz";>an
-   HTML tarball)
-https://gcc.gnu.org/onlinedocs/libstdc++/";>libstdc++-v3 
Documentation
-https://gcc.gnu.org/onlinedocs/libquadmath/";>GCC 
Quad-Precision
-   Math Library Manual (https://gcc.gnu.org/onlinedocs/libquadmath.pdf";>also in
-   PDF or https://gcc.gnu.org/onlinedocs/libquadmath.ps.gz";>PostScript or https://gcc.gnu.org/onlinedocs/libquadmath-html.tar.gz";>an
-   HTML tarball)
-https://gcc.gnu.org/onlinedocs/jit/";>libgccjit 
documentation
-https://gcc.gnu.org/onlinedocs/docs-sources.tar.gz";>Texinfo
-   sources of all the manuals
+
+  https://gcc.gnu.org/onlinedocs/install/";>GCC Installation 
Instructions
+  (https://gcc.gnu.org/onlinedocs/install.pdf";>also in PDF)
+
+
+  https://gcc.gnu.org/onlinedocs/gcc/";>Using the GNU Compiler 
Collection
+  (https://gcc.gnu.org/onlinedocs/gcc.pdf";>also in PDF)
+
+
+  https://gcc.gnu.org/onlinedocs/gfortran/";>Using GNU Fortran
+  (https://gcc.gnu.org/onlinedocs/gfortran.pdf";>also in PDF)
+
+
+  https://gcc.gnu.org/onlinedocs/cpp/";>The C Preprocessor
+  (https://gcc.gnu.org/onlinedocs/cpp.pdf";>also in PDF)
+
+
+  https://gcc.gnu.org/onlinedocs/gnat_rm/";>GNAT Reference 
Manual
+  (https://gcc.gnu.org/onlinedocs/gnat_rm.pdf";>also in PDF)
+
+
+  https://gcc.gnu.org/onlinedocs/gnat_ugn/";>GNAT User's Guide for 
Native Platforms"
+  (https://gcc.gnu.org/onlinedocs/gnat_ugn.pdf";>also in PDF)
+
+
+  https://gcc.gnu.org/onlinedocs/gccgo/";>The GNU Go Compiler
+  (https://gcc.gnu.org/onlinedocs/gccgo.pdf";>also in PDF)
+
+
+  https://gcc.gnu.org/onlinedocs/gdc/";>The GNU D Compiler
+  (https://gcc.gnu.org/onlinedocs/gdc.pdf";>also in PDF)
+
+
+  https://gcc.gnu.org/onlinedocs/libgomp/";>GNU Offloading and 
Multi Processing Runtime Library
+  (https://gcc.gnu.org/onlinedocs/libgomp.pdf";>also in PDF)
+
+
+  https://gcc.gnu.org/onlinedocs/libquadmath/";>The GCC 
Quad-Precision Math Library
+  (https://gcc.gnu.org/onlinedocs/libquadmath.pdf";>also in 
PDF)
+
+
+  https://gcc.gnu.org/onlinedocs/libitm/";>The GNU Transactional 
Memory Library
+  (https://gcc.gnu.org/onlinedocs/libitm.pdf";>also in PDF)
+
+
+  https://gcc.gnu.org/onlinedocs/libgccjit/";>libgccjit
+  (https://gcc.gnu.org/onlinedocs/libgccjit.pdf";>also in PDF)
+
+https://gcc.gnu.org/onlined

[DOCS] sphinx: use new Sphinx links

[Martin Liška]

Pushed.

---
 htdocs/about.html  |  2 +-
 htdocs/bugs/index.html |  4 ++--
 htdocs/faq.html|  6 +++---
 htdocs/news.html   |  4 ++--
 htdocs/projects/beginner.html  |  8 
 htdocs/projects/documentation.html |  2 +-
 htdocs/projects/gomp/index.html| 12 ++--
 htdocs/releases.html   |  2 +-
 htdocs/simtest-howto.html  |  2 +-
 htdocs/style.mhtml |  8 
 htdocs/testing/index.html  |  6 +++---
 11 files changed, 28 insertions(+), 28 deletions(-)

diff --git a/htdocs/about.html b/htdocs/about.html
index 7278cae6..92e88ad0 100644
--- a/htdocs/about.html
+++ b/htdocs/about.html
@@ -17,7 +17,7 @@
 The web effort was originally led by Jeff Law.  For the last two
 decades or so Gerald Pfeifer has been leading the effort, but there are
 many
-https://gcc.gnu.org/onlinedocs/gcc/Contributors.html";>contributors
+https://gcc.gnu.org/onlinedocs/gcc/contributors-to-gcc.html";>contributors
 .
 
 The web pages are under git control.
diff --git a/htdocs/bugs/index.html b/htdocs/bugs/index.html
index aaef8915..9b53512b 100644
--- a/htdocs/bugs/index.html
+++ b/htdocs/bugs/index.html
@@ -673,7 +673,7 @@ errors or malfunctioning programs.
 It should not be necessary to recompile if you have changed
 to a bug-fix release of the same version of the compiler; bug-fix
 releases are careful to avoid ABI changes. See also the
-https://gcc.gnu.org/onlinedocs/gcc/Compatibility.html";>compatibility
+https://gcc.gnu.org/onlinedocs/gcc/binary-compatibility.html";>compatibility
 section of the GCC manual.
 
 Standard conformance
@@ -689,7 +689,7 @@ However, some non-conforming constructs are allowed when 
the command-line
 option -fpermissive is used.
 
 The manual contains a section on
-https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Misunderstandings.html";>
+https://gcc.gnu.org/onlinedocs/gcc/known-causes-of-trouble-with-gcc/common-misunderstandings-with-gnu-c.html";>
 Common Misunderstandings with GNU C++.
 
 
diff --git a/htdocs/faq.html b/htdocs/faq.html
index b09e3920..0556b737 100644
--- a/htdocs/faq.html
+++ b/htdocs/faq.html
@@ -97,7 +97,7 @@ disadvantages.
 The host/target specific installation notes for GCC include information
 about known problems with installing or using GCC on particular platforms.
 These are included in the sources for a release in INSTALL/specific.html,
-and the https://gcc.gnu.org/install/specific.html";>latest version
+and the https://gcc.gnu.org/onlinedocs/install//host-target-specific-installation-notes-for-gcc.html";>latest
 version
 is always available at the GCC web site.
 Reports of successful builds
 for several versions of GCC are also available at the web site.
@@ -210,7 +210,7 @@ may have to take one of the following actions to arrange 
that GCC uses
 the GNU versions of those programs.
 
 To ensure that GCC finds the GNU assembler (the GNU linker), which
-are required by https://gcc.gnu.org/install/specific.html";>some
+are required by https://gcc.gnu.org/onlinedocs/install/host-target-specific-installation-notes-for-gcc.html";>some
 configurations,
 you should configure these with the same --prefix option as you used
 for GCC.  Then build & install GNU as (GNU ld) and proceed with
@@ -427,7 +427,7 @@ those generated files are out of date and try to regenerate 
them.
 transparently without requiring installation of any additional tools.
 
 If you modified some sources or when building from SVN you may also
-need https://gcc.gnu.org/install/prerequisites.html#TOC1";>some
+need https://gcc.gnu.org/onlinedocs/install/install/prerequisites.html#tools-packages-necessary-for-modifying-gcc";>some
 additional tools.
 
 
diff --git a/htdocs/news.html b/htdocs/news.html
index e1384852..2b35dabc 100644
--- a/htdocs/news.html
+++ b/htdocs/news.html
@@ -1020,7 +1020,7 @@ code now, and other ports will follow.
 
 Ben Elliston of Wasabi Systems, Inc. has converted the existing ARM
 processor pipeline description to the new https://gcc.gnu.org/onlinedocs/gccint/Processor-pipeline-description.html";>DFA
+href="https://gcc.gnu.org/onlinedocs/3.4.0/gccint/Processor-pipeline-description.html";>DFA
 pipeline description model.
 It will be part of the GCC 3.4.0 release.
 
@@ -1075,7 +1075,7 @@ fix release only.
 
 Geoffrey Keating of Apple Computer, Inc., with support from Red Hat,
 Inc., has contributed a
-https://gcc.gnu.org/onlinedocs/gcc/Precompiled-Headers.html#Precompiled%20Headers";>
+https://gcc.gnu.org/onlinedocs/3.4.0/gcc/Precompiled-Headers.html#Precompiled%20Headers";>
 precompiled header implementation that can dramatically speed up
 compilation of some projects.
 
diff --git a/htdocs/projects/beginner.html b/htdocs/projects/beginner.html
index 0cefb562..0825b2c0 100644
--- a/htdocs/projects/beginner.html
+++ b/htdocs/projects/beginner.html
@@ -31,10 +31,10 @@ suite.  You should also familiarize yourself with the
 
 Many of these projects will require at least a readi

[PATCH 6/12 V2] arm: Add pointer authentication for stack-unwinding runtime

[Andrea Corallo via Gcc-patches]

Hi all,

please find attached the latest version of this patch now updating the
stack pointer value after the pop used to read the PAC value.

Best Regards

  Andrea

>From a78acf8804daa3d493b419b4998f4ac705869ff9 Mon Sep 17 00:00:00 2001
From: Andrea Corallo 
Date: Mon, 6 Dec 2021 11:42:11 +0100
Subject: [PATCH] [PATCH 6/15] arm: Add pointer authentication for
 stack-unwinding runtime

This patch adds authentication for when the stack is unwound when an
exception is taken.  All the changes here are done to the runtime code
in libgcc's unwinder code for Arm target. All the changes are guarded
under defined (__ARM_FEATURE_PAC_DEFAULT) and activated only if the
+pacbti feature is switched on for the architecture. This means that
switching on the target feature via -march or -mcpu is sufficient and
-mbranch-protection need not be enabled. This ensures that the
unwinder is authenticated only if the PACBTI instructions are
available in the non-NOP space as it uses AUTG.  Just generating
PAC/AUT instructions using -mbranch-protection will not enable
authentication on the unwinder.

Pre-approved with the requested changes here
.

gcc/ChangeLog:

* ginclude/unwind-arm-common.h (_Unwind_VRS_RegClass): Introduce
new pseudo register class _UVRSC_PAC.
* libgcc/config/arm/pr-support.c (__gnu_unwind_execute): Decode
exception opcode (0xb4) for saving RA_AUTH_CODE and authenticate
with AUTG if found.
* libgcc/config/arm/unwind-arm.c (struct pseudo_regs): New.
(phase1_vrs): Introduce new field to store pseudo-reg state.
(phase2_vrs): Likewise.
(_Unwind_VRS_Get): Load pseudo register state from virtual reg set.
(_Unwind_VRS_Set): Store pseudo register state to virtual reg set.
(_Unwind_VRS_Pop): Load pseudo register value from stack into VRS.

Co-Authored-By: Tejas Belagod  
Co-Authored-By: Srinath Parvathaneni 
---
 gcc/ginclude/unwind-arm-common.h |  3 ++-
 libgcc/config/arm/pr-support.c   | 32 
 libgcc/config/arm/unwind-arm.c   | 28 
 3 files changed, 62 insertions(+), 1 deletion(-)

diff --git a/gcc/ginclude/unwind-arm-common.h b/gcc/ginclude/unwind-arm-common.h
index d3831f6c60a..f26702e8c6c 100644
--- a/gcc/ginclude/unwind-arm-common.h
+++ b/gcc/ginclude/unwind-arm-common.h
@@ -127,7 +127,8 @@ extern "C" {
   _UVRSC_VFP = 1,   /* vfp */
   _UVRSC_FPA = 2,   /* fpa */
   _UVRSC_WMMXD = 3, /* Intel WMMX data register */
-  _UVRSC_WMMXC = 4  /* Intel WMMX control register */
+  _UVRSC_WMMXC = 4, /* Intel WMMX control register */
+  _UVRSC_PAC = 5/* Armv8.1-M Mainline PAC/AUTH pseudo-register */
 }
   _Unwind_VRS_RegClass;
 
diff --git a/libgcc/config/arm/pr-support.c b/libgcc/config/arm/pr-support.c
index 2de96c2a447..e48854587c6 100644
--- a/libgcc/config/arm/pr-support.c
+++ b/libgcc/config/arm/pr-support.c
@@ -106,6 +106,7 @@ __gnu_unwind_execute (_Unwind_Context * context, 
__gnu_unwind_state * uws)
 {
   _uw op;
   int set_pc;
+  int set_pac = 0;
   _uw reg;
 
   set_pc = 0;
@@ -114,6 +115,27 @@ __gnu_unwind_execute (_Unwind_Context * context, 
__gnu_unwind_state * uws)
   op = next_unwind_byte (uws);
   if (op == CODE_FINISH)
{
+ /* When we reach end, we have to authenticate R12 we just popped
+earlier.
+
+Note: while the check provides additional security against a
+corrupted unwind chain, it isn't essential for correct unwinding
+of an uncorrupted chain.  */
+#if defined(TARGET_HAVE_PACBTI)
+ if (set_pac)
+   {
+ _uw sp;
+ _uw lr;
+ _uw pac;
+ _Unwind_VRS_Get (context, _UVRSC_CORE, R_SP, _UVRSD_UINT32, &sp);
+ _Unwind_VRS_Get (context, _UVRSC_CORE, R_LR, _UVRSD_UINT32, &lr);
+ _Unwind_VRS_Get (context, _UVRSC_PAC, R_IP,
+  _UVRSD_UINT32, &pac);
+ __asm__ __volatile__
+   ("autg %0, %1, %2" : : "r"(pac), "r"(lr), "r"(sp) :);
+   }
+#endif
+
  /* If we haven't already set pc then copy it from lr.  */
  if (!set_pc)
{
@@ -227,6 +249,16 @@ __gnu_unwind_execute (_Unwind_Context * context, 
__gnu_unwind_state * uws)
return _URC_FAILURE;
  continue;
}
+ /* Pop PAC off the stack into VRS pseudo.pac.  */
+ if (op == 0xb4)
+   {
+ if (_Unwind_VRS_Pop (context, _UVRSC_PAC, 0, _UVRSD_UINT32)
+ != _UVRSR_OK)
+   return _URC_FAILURE;
+ set_pac = 1;
+ continue;
+   }
+
  if ((op & 0xfc) == 0xb4)  /* Obsolete FPA.  */
return _URC_FAILURE;
 
diff --git a/libgcc/config/arm/unwind-arm.c b/libgcc/config/arm/unwind-arm.c
index 386406564af..9acb3de6bc3 100644
--- a/libg

Re: [DOCS] sphinx: use new Sphinx links

[Martin Liška]

Gerald, can you please propagate changes I made to:
htdocs/style.mhtml file?

Thanks,
Martin

On 11/9/22 12:13, Martin Liška wrote:
> Pushed.
> 
> ---
>  htdocs/about.html  |  2 +-
>  htdocs/bugs/index.html |  4 ++--
>  htdocs/faq.html|  6 +++---
>  htdocs/news.html   |  4 ++--
>  htdocs/projects/beginner.html  |  8 
>  htdocs/projects/documentation.html |  2 +-
>  htdocs/projects/gomp/index.html| 12 ++--
>  htdocs/releases.html   |  2 +-
>  htdocs/simtest-howto.html  |  2 +-
>  htdocs/style.mhtml |  8 
>  htdocs/testing/index.html  |  6 +++---
>  11 files changed, 28 insertions(+), 28 deletions(-)
> 
> diff --git a/htdocs/about.html b/htdocs/about.html
> index 7278cae6..92e88ad0 100644
> --- a/htdocs/about.html
> +++ b/htdocs/about.html
> @@ -17,7 +17,7 @@
>  The web effort was originally led by Jeff Law.  For the last two
>  decades or so Gerald Pfeifer has been leading the effort, but there are
>  many
> -https://gcc.gnu.org/onlinedocs/gcc/Contributors.html";>contributors
> + href="https://gcc.gnu.org/onlinedocs/gcc/contributors-to-gcc.html";>contributors
>  .
>  
>  The web pages are under git control.
> diff --git a/htdocs/bugs/index.html b/htdocs/bugs/index.html
> index aaef8915..9b53512b 100644
> --- a/htdocs/bugs/index.html
> +++ b/htdocs/bugs/index.html
> @@ -673,7 +673,7 @@ errors or malfunctioning programs.
>  It should not be necessary to recompile if you have changed
>  to a bug-fix release of the same version of the compiler; bug-fix
>  releases are careful to avoid ABI changes. See also the
> -https://gcc.gnu.org/onlinedocs/gcc/Compatibility.html";>compatibility
> + href="https://gcc.gnu.org/onlinedocs/gcc/binary-compatibility.html";>compatibility
>  section of the GCC manual.
>  
>  Standard conformance
> @@ -689,7 +689,7 @@ However, some non-conforming constructs are allowed when 
> the command-line
>  option -fpermissive is used.
>  
>  The manual contains a section on
> - href="https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Misunderstandings.html";>
> + href="https://gcc.gnu.org/onlinedocs/gcc/known-causes-of-trouble-with-gcc/common-misunderstandings-with-gnu-c.html";>
>  Common Misunderstandings with GNU C++.
>  
>  
> diff --git a/htdocs/faq.html b/htdocs/faq.html
> index b09e3920..0556b737 100644
> --- a/htdocs/faq.html
> +++ b/htdocs/faq.html
> @@ -97,7 +97,7 @@ disadvantages.
>  The host/target specific installation notes for GCC include information
>  about known problems with installing or using GCC on particular platforms.
>  These are included in the sources for a release in INSTALL/specific.html,
> -and the https://gcc.gnu.org/install/specific.html";>latest 
> version
> +and the  href="https://gcc.gnu.org/onlinedocs/install//host-target-specific-installation-notes-for-gcc.html";>latest
>  version
>  is always available at the GCC web site.
>  Reports of successful builds
>  for several versions of GCC are also available at the web site.
> @@ -210,7 +210,7 @@ may have to take one of the following actions to arrange 
> that GCC uses
>  the GNU versions of those programs.
>  
>  To ensure that GCC finds the GNU assembler (the GNU linker), which
> -are required by https://gcc.gnu.org/install/specific.html";>some
> +are required by  href="https://gcc.gnu.org/onlinedocs/install/host-target-specific-installation-notes-for-gcc.html";>some
>  configurations,
>  you should configure these with the same --prefix option as you used
>  for GCC.  Then build & install GNU as (GNU ld) and proceed with
> @@ -427,7 +427,7 @@ those generated files are out of date and try to 
> regenerate them.
>  transparently without requiring installation of any additional tools.
>  
>  If you modified some sources or when building from SVN you may also
> -need https://gcc.gnu.org/install/prerequisites.html#TOC1";>some
> +need  href="https://gcc.gnu.org/onlinedocs/install/install/prerequisites.html#tools-packages-necessary-for-modifying-gcc";>some
>  additional tools.
>  
>  
> diff --git a/htdocs/news.html b/htdocs/news.html
> index e1384852..2b35dabc 100644
> --- a/htdocs/news.html
> +++ b/htdocs/news.html
> @@ -1020,7 +1020,7 @@ code now, and other ports will follow.
>  
>  Ben Elliston of Wasabi Systems, Inc. has converted the existing ARM
>  processor pipeline description to the new  -href="https://gcc.gnu.org/onlinedocs/gccint/Processor-pipeline-description.html";>DFA
> +href="https://gcc.gnu.org/onlinedocs/3.4.0/gccint/Processor-pipeline-description.html";>DFA
>  pipeline description model.
>  It will be part of the GCC 3.4.0 release.
>  
> @@ -1075,7 +1075,7 @@ fix release only.
>  
>  Geoffrey Keating of Apple Computer, Inc., with support from Red Hat,
>  Inc., has contributed a
> - href="https://gcc.gnu.org/onlinedocs/gcc/Precompiled-Headers.html#Precompiled%20Headers";>
> + href="https://gcc.gnu.org/onlinedocs/3.4.0/gcc/Precompiled-Headers.html#Precompiled%20Head

Re: [PATCH] Fix up foperator_abs::op1_range [PR107569]

[Aldy Hernandez via Gcc-patches]

On Wed, Nov 9, 2022 at 11:55 AM Jakub Jelinek  wrote:
>
> Hi!
>
> foperator_abs::op1_range works except for the NaN handling,
> from:
> [frange] double [-Inf, 
> 1.79769313486231570814527423731704356798070567525844996599e+308 
> (0x0.f8p+1024)]
> lhs it computes r
> [frange] double 
> [-1.79769313486231570814527423731704356798070567525844996599e+308 
> (-0x0.f8p+1024), 
> 1.79769313486231570814527423731704356798070567525844996599e+308 
> (0x0.f8p+1024)] +-NAN
> which is correct except for the +-NAN part.
> For r before the final step it makes sure to add -NAN if there is +NAN
> in the lhs range, but the final r.union_ makes it unconditional +-NAN,
> because the frange ctor sets +-NAN.
> So, I think we need to clear it (or have some set variant which
> says not to set NAN).
>
> This patch fixes that, but isn't enough to fix the PR, something in
> the assumptions handling is still broken (and the PR has other parts).

LGTM.

Sorry I haven't gotten to the PR yet.  I'll poke at it later today.

Thanks.
Aldy

>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> 2022-11-09  Jakub Jelinek  
>
> PR tree-optimization/107569
> * range-op-float.cc (foperator_abs::op1_range): Clear NaNs
> from the negatives frange before unioning it into r.
>
> --- gcc/range-op-float.cc.jj2022-11-06 11:56:27.138137781 +0100
> +++ gcc/range-op-float.cc   2022-11-08 18:13:18.026974667 +0100
> @@ -1280,9 +1280,10 @@ foperator_abs::op1_range (frange &r, tre
>  return true;
>// Then add the negative of each pair:
>// ABS(op1) = [5,20] would yield op1 => [-20,-5][5,20].
> -  r.union_ (frange (type,
> -   real_value_negate (&positives.upper_bound ()),
> -   real_value_negate (&positives.lower_bound (;
> +  frange negatives (type, real_value_negate (&positives.upper_bound ()),
> +   real_value_negate (&positives.lower_bound ()));
> +  negatives.clear_nan ();
> +  r.union_ (negatives);
>return true;
>  }
>
>
> Jakub
>

Re: [AArch64] Enable generation of FRINTNZ instructions

[Andre Vieira (lists) via Gcc-patches]

On 07/11/2022 14:56, Richard Biener wrote:

On Mon, 7 Nov 2022, Andre Vieira (lists) wrote:


On 07/11/2022 11:05, Richard Biener wrote:

On Fri, 4 Nov 2022, Andre Vieira (lists) wrote:


Sorry for the delay, just been reminded I still had this patch outstanding
from last stage 1. Hopefully since it has been mostly reviewed it could go
in
for this stage 1?

I addressed the comments and gave the slp-part of vectorizable_call some
TLC
to make it work.

I also changed vect_get_slp_defs as I noticed that the call from
vectorizable_call was creating an auto_vec with 'nargs' that might be less
than the number of children in the slp_node

how so?  Please fix that in the caller.  It looks like it probably
shoud use vect_nargs instead?

Well that was my first intuition, but when I looked at it further the variant
it's calling:
void vect_get_slp_defs (vec_info *, slp_tree slp_node, vec >
*vec_oprnds, unsigned n)

Is actually creating a vector of vectors of slp defs. So for each child of
slp_node it calls:
void vect_get_slp_defs (slp_tree slp_node, vec *vec_defs)

Which returns a vector of vectorized defs. So vect_nargs would be the right
size for the inner vec of vec_defs, but the outer should have the same
number of elements as the original slp_node has children.

No, the inner vector is the vector of vectors for each arg, the outer
vector should be the one for each argument.  Hm, that was a confusing
sentence.

That said, the number of SLP children of a call node should eventually
be the number of arguments of the call (plus masks, etc.).  So it
looks about correct besides the vec_nargs issue?
Yeah you are right, I misunderstood what the children were, so you have 
a child node for each argument of the call. Though, since you iterate 
over the 'scalar' arguments of the call I actually think 'nargs' was 
correct to begin with, which would explain why this never went wrong... 
So I think it is actually correct as is, I must have gotten confused by 
some earlier investigation into how to deal with the scalar arguments... 
Sorry for the noise, I'll undo these changes to the patch.

[PATCH (pushed)] sphinx: update crontab with new script

[Martin Liška]

maintainer-scripts/ChangeLog:

* crontab: Use new script for documentation of master branch.
---
 maintainer-scripts/crontab | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/maintainer-scripts/crontab b/maintainer-scripts/crontab
index a961ff1ed5b..09e33c0095f 100644
--- a/maintainer-scripts/crontab
+++ b/maintainer-scripts/crontab
@@ -1,5 +1,5 @@
 16  0 * * * sh /home/gccadmin/scripts/update_version_git
-50  0 * * * sh /home/gccadmin/scripts/update_web_docs_git
+50  0 * * * sh /home/gccadmin/venv/bin/python3 
/home/gccadmin/scripts/update_web_docs_git.py /www/gcc/htdocs/onlinedocs/ 
--sphinx-build=/home/gccadmin/venv/bin/sphinx-build
 55  0 * * * sh /home/gccadmin/scripts/update_web_docs_libstdcxx_git
 32 22 * * 4 sh /home/gccadmin/scripts/gcc_release -s 10:releases/gcc-10 -l -d 
/sourceware/snapshot-tmp/gcc all
 32 22 * * 5 sh /home/gccadmin/scripts/gcc_release -s 11:releases/gcc-11 -l -d 
/sourceware/snapshot-tmp/gcc all
-- 
2.38.0

[PATCH (pushed)] sphinx: update diagnostics URLs

[Martin Liška]

For the future, we'll use https://pypi.org/project/sphinx-redirect-by-id/
which will allow links like

https://gcc.gnu.org/onlinedocs/gcc/redirect.html?q=cmdoption-Wfoo

but for now, let's use the proper landing pages.

Martin

gcc/ChangeLog:

* opts.cc (get_option_html_page): Port to sphinx URLs.
(get_option_url): Likewise.
(test_get_option_html_page): Likewise.
---
 gcc/opts.cc | 26 ++
 1 file changed, 14 insertions(+), 12 deletions(-)

diff --git a/gcc/opts.cc b/gcc/opts.cc
index 3797784c865..c00887ae76e 100644
--- a/gcc/opts.cc
+++ b/gcc/opts.cc
@@ -3608,11 +3608,11 @@ get_option_html_page (int option_index)
 
   /* Analyzer options are on their own page.  */
   if (strstr (cl_opt->opt_text, "analyzer-"))
-return "gcc/Static-Analyzer-Options.html";
+return "gcc/gcc-command-options/options-that-control-static-analysis.html";
 
   /* Handle -flto= option.  */
   if (strstr (cl_opt->opt_text, "flto"))
-return "gcc/Optimize-Options.html";
+return "gcc/gcc-command-options/options-that-control-optimization.html";
 
 #ifdef CL_Fortran
   if ((cl_opt->flags & CL_Fortran) != 0
@@ -3623,10 +3623,11 @@ get_option_html_page (int option_index)
   && (cl_opt->flags & CL_CXX) == 0
 #endif
  )
-return "gfortran/Error-and-Warning-Options.html";
+return ("gfortran/gnu-fortran-command-options/"
+   "options-to-request-or-suppress-errors-and-warnings.html");
 #endif
 
-  return "gcc/Warning-Options.html";
+  return 
"gcc/gcc-command-options/options-to-request-or-suppress-warnings.html";
 }
 
 /* Return malloced memory for a URL describing the option OPTION_INDEX
@@ -3645,11 +3646,8 @@ get_option_url (diagnostic_context *, int option_index)
  "gcc/Warning-Options.html".  */
   get_option_html_page (option_index),
 
-  /* Expect an anchor of the form "index-Wfoo" e.g.
- , and thus an id within
- the URL of "#index-Wformat".  */
-  "#index", cl_options[option_index].opt_text,
-  NULL);
+  /* Expect an anchor of the form "cmdoption-Wfoo".  */
+  "#cmdoption", cl_options[option_index].opt_text, NULL);
   else
 return NULL;
 }
@@ -3786,12 +3784,16 @@ namespace selftest {
 static void
 test_get_option_html_page ()
 {
-  ASSERT_STREQ (get_option_html_page (OPT_Wcpp), "gcc/Warning-Options.html");
+  ASSERT_STREQ (get_option_html_page (OPT_Wcpp),
+   "gcc/gcc-command-options/"
+   "options-to-request-or-suppress-warnings.html");
   ASSERT_STREQ (get_option_html_page (OPT_Wanalyzer_double_free),
-"gcc/Static-Analyzer-Options.html");
+   "gcc/gcc-command-options/"
+   "options-that-control-static-analysis.html");
 #ifdef CL_Fortran
   ASSERT_STREQ (get_option_html_page (OPT_Wline_truncation),
-   "gfortran/Error-and-Warning-Options.html");
+   "gfortran/gnu-fortran-command-options/"
+   "options-to-request-or-suppress-errors-and-warnings.html");
 #endif
 }
 
-- 
2.38.0

Re: [RFC PATCH] c++: Minimal handling of carries_dependency attribute

[Jakub Jelinek via Gcc-patches]

On Tue, Nov 08, 2022 at 01:40:03PM -1000, Jason Merrill wrote:
> > A comment in D2552R1:
> > "The only questionable (but still conforming) case we found was
> > [[carries_dependency(some_argument)]] on GCC, where the emitted diagnostic 
> > said that the
> > carries_dependency attribute is not supported, but did not specifically 
> > call out the syntax error
> > in the argument clause."
> > made me try the following patch, where we'll error at least
> > for arguments to the attribute and for some uses of the attribute
> > appertaining to something not mentioned in the standard warn
> > with different diagnostics (or should that be an error?; clang++
> > does that, but I think we never do for any attribute, standard or not).
> > The diagnostics on toplevel attribute declaration is still an
> > attribute ignored warning and on empty statement different wording.
> > 
> > The paper additionally mentions
> > struct X { [[nodiscard]]; }; // no diagnostic on GCC
> > and 2 cases of missing diagnostics on [[fallthrough]] (guess I should
> > file a PR about those; one problem is that do { ... } while (0); there
> > is replaced during genericization just by ... and another that
> > [[fallthrough]] there is followed by a label, but not user/case/default
> > label, but an artificial one created from while loop genericization.
> > 
> > Thoughts on this?
> 
> LGTM.

Thanks, committed now.
Given CWG2538, I wonder whether we shouldn't at least pedwarn rather than
warning{,_at} for standard attributes that appertain to wrong entities
(and keep warning{,_at} for non-standard attributes including gnu variants
of standard attributes).
If yes, we'd need to differentiate between the standard attributes
and gnu variants thereof (I think the C FE does, but C++ FE has
  /* We used to treat C++11 noreturn attribute as equivalent to GNU's,
 but no longer: we have to be able to tell [[noreturn]] and
 __attribute__((noreturn)) apart.  */
  /* C++14 deprecated attribute is equivalent to GNU's.  */
  if (is_attribute_p ("deprecated", attr_id))
TREE_PURPOSE (TREE_PURPOSE (attribute)) = gnu_identifier;
  /* C++17 fallthrough attribute is equivalent to GNU's.  */
  else if (is_attribute_p ("fallthrough", attr_id))
TREE_PURPOSE (TREE_PURPOSE (attribute)) = gnu_identifier;
  /* C++23 assume attribute is equivalent to GNU's.  */
  else if (is_attribute_p ("assume", attr_id))
TREE_PURPOSE (TREE_PURPOSE (attribute)) = gnu_identifier;
so we'd need to remove that and make sure those standard attributes
are handled.

Jakub

[PATCH] AArch64: Add fma_reassoc_width [PR107413]

[Wilco Dijkstra via Gcc-patches]

Add a reassocation width for FMAs in per-CPU tuning structures. Keep the
existing setting for cores with 2 FMA pipes, and use 4 for cores with 4
FMA pipes.  This improves SPECFP2017 on Neoverse V1 by ~1.5%.

Passes regress/bootstrap, OK for commit?

gcc/
PR 107413
* config/aarch64/aarch64.cc (struct tune_params): Add
fma_reassoc_width to all CPU tuning structures.
* config/aarch64/aarch64-protos.h (struct tune_params): Add
fma_reassoc_width.

---

diff --git a/gcc/config/aarch64/aarch64-protos.h 
b/gcc/config/aarch64/aarch64-protos.h
index 
a73bfa20acb9b92ae0475794c3f11c67d22feb97..71365a446007c26b906b61ca8b2a68ee06c83037
 100644
--- a/gcc/config/aarch64/aarch64-protos.h
+++ b/gcc/config/aarch64/aarch64-protos.h
@@ -540,6 +540,7 @@ struct tune_params
   const char *loop_align;
   int int_reassoc_width;
   int fp_reassoc_width;
+  int fma_reassoc_width;
   int vec_reassoc_width;
   int min_div_recip_mul_sf;
   int min_div_recip_mul_df;
diff --git a/gcc/config/aarch64/aarch64.cc b/gcc/config/aarch64/aarch64.cc
index 
798363bcc449c414de5bbb4f26b8e1c64a0cf71a..643162cdecd6a8fe5587164cb2d0d62b709a491d
 100644
--- a/gcc/config/aarch64/aarch64.cc
+++ b/gcc/config/aarch64/aarch64.cc
@@ -1346,6 +1346,7 @@ static const struct tune_params generic_tunings =
   "8", /* loop_align.  */
   2,   /* int_reassoc_width.  */
   4,   /* fp_reassoc_width.  */
+  1,   /* fma_reassoc_width.  */
   1,   /* vec_reassoc_width.  */
   2,   /* min_div_recip_mul_sf.  */
   2,   /* min_div_recip_mul_df.  */
@@ -1382,6 +1383,7 @@ static const struct tune_params cortexa35_tunings =
   "8", /* loop_align.  */
   2,   /* int_reassoc_width.  */
   4,   /* fp_reassoc_width.  */
+  1,   /* fma_reassoc_width.  */
   1,   /* vec_reassoc_width.  */
   2,   /* min_div_recip_mul_sf.  */
   2,   /* min_div_recip_mul_df.  */
@@ -1415,6 +1417,7 @@ static const struct tune_params cortexa53_tunings =
   "8", /* loop_align.  */
   2,   /* int_reassoc_width.  */
   4,   /* fp_reassoc_width.  */
+  1,   /* fma_reassoc_width.  */
   1,   /* vec_reassoc_width.  */
   2,   /* min_div_recip_mul_sf.  */
   2,   /* min_div_recip_mul_df.  */
@@ -1448,6 +1451,7 @@ static const struct tune_params cortexa57_tunings =
   "8", /* loop_align.  */
   2,   /* int_reassoc_width.  */
   4,   /* fp_reassoc_width.  */
+  1,   /* fma_reassoc_width.  */
   1,   /* vec_reassoc_width.  */
   2,   /* min_div_recip_mul_sf.  */
   2,   /* min_div_recip_mul_df.  */
@@ -1481,6 +1485,7 @@ static const struct tune_params cortexa72_tunings =
   "8", /* loop_align.  */
   2,   /* int_reassoc_width.  */
   4,   /* fp_reassoc_width.  */
+  1,   /* fma_reassoc_width.  */
   1,   /* vec_reassoc_width.  */
   2,   /* min_div_recip_mul_sf.  */
   2,   /* min_div_recip_mul_df.  */
@@ -1514,6 +1519,7 @@ static const struct tune_params cortexa73_tunings =
   "8", /* loop_align.  */
   2,   /* int_reassoc_width.  */
   4,   /* fp_reassoc_width.  */
+  1,   /* fma_reassoc_width.  */
   1,   /* vec_reassoc_width.  */
   2,   /* min_div_recip_mul_sf.  */
   2,   /* min_div_recip_mul_df.  */
@@ -1548,6 +1554,7 @@ static const struct tune_params exynosm1_tunings =
   "4", /* loop_align.  */
   2,   /* int_reassoc_width.  */
   4,   /* fp_reassoc_width.  */
+  1,   /* fma_reassoc_width.  */
   1,   /* vec_reassoc_width.  */
   2,   /* min_div_recip_mul_sf.  */
   2,   /* min_div_recip_mul_df.  */
@@ -1580,6 +1587,7 @@ static const struct tune_params thunderxt88_tunings =
   "8", /* loop_align.  */
   2,   /* int_reassoc_width.  */
   4,   /* fp_reassoc_width.  */
+  1,   /* fma_reassoc_width.  */
   1,   /* vec_reassoc_width.  */
   2,   /* min_div_recip_mul_sf.  */
   2,   /* min_div_recip_mul_df.  */
@@ -1612,6 +1620,7 @@ static const struct tune_params thunderx_tunings =
   "8", /* loop_align.  */
   2,   /* int_reassoc_width.  */
   4,   /* fp_reassoc_width.  */
+  1,   /* fma_reassoc_width.  */
   1,   /* vec_reassoc_width.  */
   2,   /* min_div_recip_mul_sf.  */
   2,   /* min_div_recip_mul_df.  */
@@ -1646,6 +1655,7 @@ static const struct tune_params tsv110_tunings =
   "8",  /* loop_align.  */
   2,/* int_reassoc_width.  */
   4,/* fp_reassoc_width.  */
+  1,   /* fma_reassoc_width.  */
   1,/* vec_reassoc_width.  */
   2,/* min_div_recip_mul_sf.  */
   2,/* min_div_recip_mul_df.  */
@@ -1678,6 +1688,7 @@ static const struct tune_params xgene1_tunings =
   "16",/* loop_align.  */
   2,   /* int_reassoc_width.  */
   4,   /* fp_reassoc_width.  */
+  1,   /* fma_reassoc_width.  */
   1,   /* vec_reassoc_width.  */
   2,   /* min_div_recip_mul_sf.  */
   2,   /* min_div_recip_mul_df.  */
@@ -1710,6 +1721,7 @@ static const struct tune_params emag_tunings =
   "16",/* loop_align.  */
   2,   /* int_reassoc_width.  */
   4,   /* fp_reassoc_width.  */
+  1,   /* fma_reassoc_width.  */
   1,   /* vec_reassoc_width.  */
   2,   /* min_div_recip_mul_sf.  */
   2,   /* min_div_recip_mul_df.  */
@@ -1743,6 +1755,7 @@ static const s

[PATCH (pushed)] docs: fix: WARNING: Parsing of expression failed. Using fallback parser.

[Martin Liška]

For the future, we can use https://sphinx-fortran.readthedocs.io/ for
Fortran functions which can have optional arguments. However, it's an
additional dependency.

Simplify the function declration.

gcc/fortran/ChangeLog:

* doc/gfortran/intrinsic-procedures/aint.rst: Simplify function
  declaration.
* doc/gfortran/intrinsic-procedures/anint.rst: Likewise.
* doc/gfortran/intrinsic-procedures/char.rst: Likewise.
* doc/gfortran/intrinsic-procedures/real.rst: Likewise.
---
 gcc/fortran/doc/gfortran/intrinsic-procedures/aint.rst  | 4 ++--
 gcc/fortran/doc/gfortran/intrinsic-procedures/anint.rst | 4 ++--
 gcc/fortran/doc/gfortran/intrinsic-procedures/char.rst  | 4 ++--
 gcc/fortran/doc/gfortran/intrinsic-procedures/int.rst   | 4 ++--
 gcc/fortran/doc/gfortran/intrinsic-procedures/real.rst  | 4 ++--
 5 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/gcc/fortran/doc/gfortran/intrinsic-procedures/aint.rst 
b/gcc/fortran/doc/gfortran/intrinsic-procedures/aint.rst
index 2550442c246..f95a60121aa 100644
--- a/gcc/fortran/doc/gfortran/intrinsic-procedures/aint.rst
+++ b/gcc/fortran/doc/gfortran/intrinsic-procedures/aint.rst
@@ -16,7 +16,7 @@
 AINT --- Truncate to a whole number
 ***
 
-.. function:: AINT(A [, KIND])
+.. function:: AINT(A, KIND)
 
   ``AINT(A [, KIND])`` truncates its argument to a whole number.
 
@@ -75,4 +75,4 @@ AINT --- Truncate to a whole number
* - ``DINT(A)``
  - ``REAL(8) A``
  - ``REAL(8)``
- - Fortran 77 and later
\ No newline at end of file
+ - Fortran 77 and later
diff --git a/gcc/fortran/doc/gfortran/intrinsic-procedures/anint.rst 
b/gcc/fortran/doc/gfortran/intrinsic-procedures/anint.rst
index 889585c412f..7c1d324cfc7 100644
--- a/gcc/fortran/doc/gfortran/intrinsic-procedures/anint.rst
+++ b/gcc/fortran/doc/gfortran/intrinsic-procedures/anint.rst
@@ -16,7 +16,7 @@
 ANINT --- Nearest whole number
 **
 
-.. function:: ANINT(A [, KIND])
+.. function:: ANINT(A, KIND)
 
   ``ANINT(A [, KIND])`` rounds its argument to the nearest whole number.
 
@@ -73,4 +73,4 @@ ANINT --- Nearest whole number
* - ``DNINT(A)``
  - ``REAL(8) A``
  - ``REAL(8)``
- - Fortran 77 and later
\ No newline at end of file
+ - Fortran 77 and later
diff --git a/gcc/fortran/doc/gfortran/intrinsic-procedures/char.rst 
b/gcc/fortran/doc/gfortran/intrinsic-procedures/char.rst
index 221deca4882..a51b927d0b3 100644
--- a/gcc/fortran/doc/gfortran/intrinsic-procedures/char.rst
+++ b/gcc/fortran/doc/gfortran/intrinsic-procedures/char.rst
@@ -12,7 +12,7 @@
 CHAR --- Character conversion function
 **
 
-.. function:: CHAR(I [, KIND])
+.. function:: CHAR(I, KIND)
 
   ``CHAR(I [, KIND])`` returns the character represented by the integer 
:samp:`{I}`.
 
@@ -68,4 +68,4 @@ CHAR --- Character conversion function
   See also:
 :ref:`ACHAR`,
 :ref:`IACHAR`,
-:ref:`ICHAR`
\ No newline at end of file
+:ref:`ICHAR`
diff --git a/gcc/fortran/doc/gfortran/intrinsic-procedures/int.rst 
b/gcc/fortran/doc/gfortran/intrinsic-procedures/int.rst
index 43d2a56be38..83a35aef529 100644
--- a/gcc/fortran/doc/gfortran/intrinsic-procedures/int.rst
+++ b/gcc/fortran/doc/gfortran/intrinsic-procedures/int.rst
@@ -16,7 +16,7 @@
 INT --- Convert to integer type
 ***
 
-.. function:: INT(A , KIND))
+.. function:: INT(A, KIND)
 
   Convert to integer type
 
@@ -73,4 +73,4 @@ INT --- Convert to integer type
* - ``IDINT(A)``
  - ``REAL(8) A``
  - ``INTEGER``
- - Fortran 77 and later
\ No newline at end of file
+ - Fortran 77 and later
diff --git a/gcc/fortran/doc/gfortran/intrinsic-procedures/real.rst 
b/gcc/fortran/doc/gfortran/intrinsic-procedures/real.rst
index 0f15f5cb8cc..be19a01723d 100644
--- a/gcc/fortran/doc/gfortran/intrinsic-procedures/real.rst
+++ b/gcc/fortran/doc/gfortran/intrinsic-procedures/real.rst
@@ -28,7 +28,7 @@
 REAL --- Convert to real type
 **
 
-.. function:: REAL(A [, KIND])
+.. function:: REAL(A, KIND)
 
   ``REAL(A [, KIND])`` converts its argument :samp:`{A}` to a real type.  The
   ``REALPART`` function is provided for compatibility with :command:`g77`,
@@ -101,4 +101,4 @@ REAL --- Convert to real type
  - Fortran 77 and later
 
   See also:
-:ref:`DBLE`
\ No newline at end of file
+:ref:`DBLE`
-- 
2.38.0

Re: [COMMITTED] [range-op-float] Abstract out binary operator code out of PLUS_EXPR entry.

[Jakub Jelinek via Gcc-patches]

On Wed, Nov 09, 2022 at 08:07:57AM +0100, Aldy Hernandez wrote:
> The PLUS_EXPR was always meant to be a template for further
> development, since most of the binary operators will share a similar
> structure.  This patch abstracts out the common bits into the default
> definition for range_operator_float::fold_range() and provides an
> rv_fold() to be implemented by the individual entries wishing to use
> the generic folder.  This is akin to what we do with fold_range() and
> wi_fold() in the integer version of range-ops.

Shouldn't foperator_mult be very similar to this (except that until
division is done op[12]_range can't be implemented), with the exception
that the invalid case isn't -INF + INF or INF + -INF, but
0 * +/-INF or +/-INF * 0?

Jakub

Re: [RFC] propgation leap over memory copy for struct

[Richard Biener via Gcc-patches]

On Wed, 9 Nov 2022, Jiufu Guo wrote:

> Hi,
> 
> Richard Biener  writes:
> 
> > On Mon, Oct 31, 2022 at 11:14 PM Jeff Law via Gcc-patches
> >  wrote:
> >>
> >>
> >> On 10/30/22 20:42, Jiufu Guo via Gcc-patches wrote:
> >> > Hi,
> >> >
> >> > We know that for struct variable assignment, memory copy may be used.
> >> > And for memcpy, we may load and store more bytes as possible at one time.
> >> > While it may be not best here:
> >> > 1. Before/after stuct variable assignment, the vaiable may be operated.
> >> > And it is hard for some optimizations to leap over memcpy.  Then some 
> >> > struct
> >> > operations may be sub-optimimal.  Like the issue in PR65421.
> >> > 2. The size of struct is constant mostly, the memcpy would be expanded.  
> >> > Using
> >> > small size to load/store and executing in parallel may not slower than 
> >> > using
> >> > large size to loat/store. (sure, more registers may be used for smaller 
> >> > bytes.)
> >> >
> >> >
> >> > In PR65421, For source code as below:
> >> > t.c
> >> > #define FN 4
> >> > typedef struct { double a[FN]; } A;
> >> >
> >> > A foo (const A *a) { return *a; }
> >> > A bar (const A a) { return a; }
> >>
> >> So the first question in my mind is can we do better at the gimple
> >> phase?  For the second case in particular can't we just "return a"
> >> rather than copying a into  then returning ?  This feels
> >> a lot like the return value optimization from C++.  I'm not sure if it
> >> applies to the first case or not, it's been a long time since I looked
> >> at NRV optimizations, but it might be worth poking around in there a bit
> >> (tree-nrv.cc).
> >>
> >>
> >> But even so, these kinds of things are still bound to happen, so it's
> >> probably worth thinking about if we can do better in RTL as well.
> >>
> >>
> >> The first thing that comes to my mind is to annotate memcpy calls that
> >> are structure assignments.  The idea here is that we may want to expand
> >> a memcpy differently in those cases.   Changing how we expand an opaque
> >> memcpy call is unlikely to be beneficial in most cases.  But changing
> >> how we expand a structure copy may be beneficial by exposing the
> >> underlying field values.   This would roughly correspond to your method #1.
> >>
> >> Or instead of changing how we expand, teach the optimizers about these
> >> annotated memcpy calls -- they're just a a copy of each field.   That's
> >> how CSE and the propagators could treat them. After some point we'd
> >> lower them in the usual ways, but at least early in the RTL pipeline we
> >> could keep them as annotated memcpy calls.  This roughly corresponds to
> >> your second suggestion.
> >
> > In the end it depends on the access patterns so some analysis like SRA
> > performs would be nice.  The issue with expanding memcpy on GIMPLE
> > is that we currently cannot express 'rep; movb;' or other target specific
> > sequences from the cpymem like optabs on GIMPLE and recovering those
> > from piecewise copies on RTL is going to be difficult.
> Actually, it is a special memcpy. It is generated during expanding the
> struct assignment(expand_assignment/store_expr/emit_block_move).
> We may introduce a function block_move_for_record for struct type.  And
> this function could be a target hook to generate specificed sequences.
> For example:
> r125:DF=[r112:DI+0x20]
> r126:DF=[r112:DI+0x28]
> [r112:DI]=r125:DF
> [r112:DI+0x8]=r126:DF
> 
> After expanding, following passes(cse/prop/dse/..) could optimize the
> insn sequences. e.g "[r112:DI+0x20]=f1;r125:DF=[r112:DI+0x20];
> [r112:DI]=r125:DF;r129:DF=[r112:DI]" ==> "r129:DF=f1"
> 
> And if the small reading/writing insns are still occur in late passes
> e.g. combine, we would recover the isnsn to better sequence:
> r125:DF=[r112:DI+0x20];r126:DF=[r112:DI+0x28]
> ==>
> r155:V2DI=[r112:DI+0x20];
> 
> Any comments? Thanks!

As said the best copying decomposition depends on the followup uses
and the argument passing ABI which is why I suggested to perform
SRA like analysis which collects the access patterns and use that
to drive the heuristic expanding this special memcpy.

Richard.

Re: [PATCH (pushed)] sphinx: update diagnostics URLs

[Richard Biener via Gcc-patches]

On Wed, Nov 9, 2022 at 1:12 PM Martin Liška  wrote:
>
> For the future, we'll use https://pypi.org/project/sphinx-redirect-by-id/
> which will allow links like
>
> https://gcc.gnu.org/onlinedocs/gcc/redirect.html?q=cmdoption-Wfoo
>
> but for now, let's use the proper landing pages.

Do we need a redirect at the old location?

> Martin
>
> gcc/ChangeLog:
>
> * opts.cc (get_option_html_page): Port to sphinx URLs.
> (get_option_url): Likewise.
> (test_get_option_html_page): Likewise.
> ---
>  gcc/opts.cc | 26 ++
>  1 file changed, 14 insertions(+), 12 deletions(-)
>
> diff --git a/gcc/opts.cc b/gcc/opts.cc
> index 3797784c865..c00887ae76e 100644
> --- a/gcc/opts.cc
> +++ b/gcc/opts.cc
> @@ -3608,11 +3608,11 @@ get_option_html_page (int option_index)
>
>/* Analyzer options are on their own page.  */
>if (strstr (cl_opt->opt_text, "analyzer-"))
> -return "gcc/Static-Analyzer-Options.html";
> +return 
> "gcc/gcc-command-options/options-that-control-static-analysis.html";
>
>/* Handle -flto= option.  */
>if (strstr (cl_opt->opt_text, "flto"))
> -return "gcc/Optimize-Options.html";
> +return "gcc/gcc-command-options/options-that-control-optimization.html";
>
>  #ifdef CL_Fortran
>if ((cl_opt->flags & CL_Fortran) != 0
> @@ -3623,10 +3623,11 @@ get_option_html_page (int option_index)
>&& (cl_opt->flags & CL_CXX) == 0
>  #endif
>   )
> -return "gfortran/Error-and-Warning-Options.html";
> +return ("gfortran/gnu-fortran-command-options/"
> +   "options-to-request-or-suppress-errors-and-warnings.html");
>  #endif
>
> -  return "gcc/Warning-Options.html";
> +  return 
> "gcc/gcc-command-options/options-to-request-or-suppress-warnings.html";
>  }
>
>  /* Return malloced memory for a URL describing the option OPTION_INDEX
> @@ -3645,11 +3646,8 @@ get_option_url (diagnostic_context *, int option_index)
>   "gcc/Warning-Options.html".  */
>get_option_html_page (option_index),
>
> -  /* Expect an anchor of the form "index-Wfoo" e.g.
> - , and thus an id within
> - the URL of "#index-Wformat".  */
> -  "#index", cl_options[option_index].opt_text,
> -  NULL);
> +  /* Expect an anchor of the form "cmdoption-Wfoo".  */
> +  "#cmdoption", cl_options[option_index].opt_text, NULL);
>else
>  return NULL;
>  }
> @@ -3786,12 +3784,16 @@ namespace selftest {
>  static void
>  test_get_option_html_page ()
>  {
> -  ASSERT_STREQ (get_option_html_page (OPT_Wcpp), "gcc/Warning-Options.html");
> +  ASSERT_STREQ (get_option_html_page (OPT_Wcpp),
> +   "gcc/gcc-command-options/"
> +   "options-to-request-or-suppress-warnings.html");
>ASSERT_STREQ (get_option_html_page (OPT_Wanalyzer_double_free),
> -"gcc/Static-Analyzer-Options.html");
> +   "gcc/gcc-command-options/"
> +   "options-that-control-static-analysis.html");
>  #ifdef CL_Fortran
>ASSERT_STREQ (get_option_html_page (OPT_Wline_truncation),
> -   "gfortran/Error-and-Warning-Options.html");
> +   "gfortran/gnu-fortran-command-options/"
> +   "options-to-request-or-suppress-errors-and-warnings.html");
>  #endif
>  }
>
> --
> 2.38.0
>

RE: [PATCH] RISC-V: cost model for loading 64bit constant in rv32

[Sinan via Gcc-patches]

>> comparison with clang:
>> https://godbolt.org/z/v5nxTbKe9 
>
> IIUC the rules are generally no compiler explorer links (so we can
> preserve history) and no attachment patches (ie, inline them like
> git-send-email does). There's some documenation on sending patches at
> .
>
> Given those usually show up for first-time contributors there's also
> some copyright/DCO procedures to bo followed. I see some other
> linux.alibaba.com emails called out explicitly, but then also a generic
> "GCC Alibaba Group Holding Limited". I think that means we're OK for
> copyright assignment here? There's still the "you wrote the code" bits
> that are worth reading, though.
Thanks for your info. I will resend this patch according to your suggestion. As 
for the copyright, people and I with the linux.alibaba.com email have FSF 
copyright assignment and copyright won't be a problem.
> On Tue, 08 Nov 2022 19:26:01 PST (-0800), gcc-patches@gcc.gnu.org wrote:
>> loading constant 0x739290001LL in rv32 can be done with three instructions
>> output:
>> li a1, 7
>> lui a1, 234128
>> addi a1, a1, 1
>
> Probably more useful to load the constant into two different registers? 
> The point is the same, though, so just a commit message issue.
>
>> Similarly, loading 0x839290001LL in rv32 can be done within three 
>> instructions
>> expected output:
>> li a1, 8
>> lui a1, 234128
>> addi a1, a1, 1
> However, riscv_build_integer does not handle this case well and makes a wrong 
> prediction about the number of instructions > needed and then the constant is 
> forced to put in the memory via riscv_const_insns and emit_move_insn.
>> real output:
>> lui a4,%hi(.LC0)
>> lw a2,%lo(.LC0)(a4)
>> lw a3,%lo(.LC0+4)(a4)
>> .LC0:
>> .word958988289
>> .word8
>
> That's still 3 instructions, but having loads and a constant is worse so
> that's just another commit message issue.
>
>
> Looking at the attached patch:
>
>> + if ((value > INT32_MAX || value < INT32_MIN) && !TARGET_64BIT)
>> + {
>> + unsigned HOST_WIDE_INT loval = sext_hwi (value, 32);
>> + unsigned HOST_WIDE_INT hival = sext_hwi ((value - loval) >> 32, 32);
>> + struct riscv_integer_op alt_codes[RISCV_MAX_INTEGER_OPS],
>> + hicode[RISCV_MAX_INTEGER_OPS];
>> + int hi_cost, lo_cost;
>> +
>> + hi_cost = riscv_build_integer_1 (hicode, hival, mode);
>> + if (hi_cost < cost)
>> + {
>> + lo_cost = riscv_build_integer_1 (alt_codes, loval, mode);
>> + if (lo_cost + hi_cost < cost)
>> + {
>> + memcpy (codes, alt_codes,
>> + lo_cost * sizeof (struct riscv_integer_op));
>> + memcpy (codes + lo_cost, hicode,
>> + hi_cost * sizeof (struct riscv_integer_op));
>> + cost = lo_cost + hi_cost;
>> + }
>> + }
>> + }
>
> This kind of stuff always seems like it should be possible to handle
> with generic middle-end optimizations: it's essentially just splitting
> the 64-bit constant into two 32-bit constants, which is free because
> it's going into two registers anyway. That's not a RISC-V specific
> problem, it's just the case any time a constant is going to be split
> between two registers -- it'd even apply for 128-bit constants on rv64,
> though those are probably rare enough they don't matter all that much.
>
> I'm not opposed to doing this in the backend, but maybe it's a sign
> we've just screwed something else up and can avoid adding the code?
Sorry for not making it clear. The motivation of this patch is to correct the 
wrong estimation of the number of instructions needed for loading a 64bit 
constant in rv32 in the current cost model(riscv_interger_cost). According to 
the current implementation, if a constant requires more than 3 
instructions(riscv_const_insn and riscv_legitimate_constant_p), then the 
constant will be put into constant pool when expanding gimple to 
rtl(legitimate_constant_p hook and emit_move_insn). So at least the wrong 
estimation part in rv32 could be improved.
Strategies of loading a big constant vary from backend ot backend, and I think 
it makes sense that let the backend make the decision. As for RV64 and int128, 
I did not investigate it and it seems a bit different from rv32 case. For 
example, loading 64bit constant 0x839290001LL in rv64 actually requires one 
more instruction than rv32.
```
lui a1, 132
addiw a1,a1,-1751
slli a1,a1,16
addi a1,a1,1
```
>> +++ b/gcc/testsuite/gcc.target/riscv/rv32-load-64bit-constant.c
>> @@ -0,0 +1,35 @@
>> +/* { dg-do compile } */
>> +/* { dg-options "-march=rv32gc -mabi=ilp32 -Os" } */
>
> This has the same library/abi problems we've had before, but in this
> case I think it's fine to just leave the -march/-mabi out: the test
> cases won't be that exciting on rv64 (unless we add the 128-bit splits
> too?), but they should still stay away from the constant pool.
>
> IIUC this should work on more than Os, at least O2/above? Not that
> exciting for the test case, though.
>
>> +/* { dg-final { scan-assembler-not "\.LC\[0-9\]" } } */
>
> That's a bit fragile, maybe just ma

Re: [PATCH (pushed)] sphinx: update diagnostics URLs

[Martin Liška]

On 11/9/22 14:00, Richard Biener wrote:
> Do we need a redirect at the old location?

Well, what's not working are older gcc releases that still point to "master" 
branch
documentation:

gcc --version
gcc (SUSE Linux) 12.2.1 20221020 [revision 
0aaef83351473e8f4eb774f8f999bbe87a4866d7]
...
https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wunused-parameter

these should point ideally to:
https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Warning-Options.html#index-Wunused-parameter

anyway, we can provider redirect for these, I'll ask Gerald.

Martin

Re: [COMMITTED] [range-op-float] Abstract out binary operator code out of PLUS_EXPR entry.

[Aldy Hernandez via Gcc-patches]

On Wed, Nov 9, 2022 at 1:48 PM Jakub Jelinek  wrote:
>
> On Wed, Nov 09, 2022 at 08:07:57AM +0100, Aldy Hernandez wrote:
> > The PLUS_EXPR was always meant to be a template for further
> > development, since most of the binary operators will share a similar
> > structure.  This patch abstracts out the common bits into the default
> > definition for range_operator_float::fold_range() and provides an
> > rv_fold() to be implemented by the individual entries wishing to use
> > the generic folder.  This is akin to what we do with fold_range() and
> > wi_fold() in the integer version of range-ops.
>
> Shouldn't foperator_mult be very similar to this (except that until
> division is done op[12]_range can't be implemented), with the exception
> that the invalid case isn't -INF + INF or INF + -INF, but
> 0 * +/-INF or +/-INF * 0?

Multiplication and division are tricky because you have to keep track
of signs to order the resulting range.  It's the most annoying pattern
we have for integers:

// Multiplications, divisions and shifts are a bit tricky to handle,
// depending on the mix of signs we have in the two ranges, we need to
// operate on different values to get the minimum and maximum values
// for the new range.  One approach is to figure out all the
// variations of range combinations and do the operations.
//
// However, this involves several calls to compare_values and it is
// pretty convoluted.  It's simpler to do the 4 operations (MIN0 OP
// MIN1, MIN0 OP MAX1, MAX0 OP MIN1 and MAX0 OP MAX0 OP MAX1) and then
// figure the smallest and largest values to form the new range.

But if you have a simpler approach, have at it.  I may have to bail on
multiplication and division for this cycle, cause I'm running out of
cycles :-/.

Hmmm...even if we don't get to implement mult/div in this cycle,
perhaps we could at least figure out if we'll NAN as you've suggested
above.  So, set [-INF,+INF] but without a NAN when applicable.

Aldy

Re: [PATCH (pushed)] sphinx: update diagnostics URLs

[Richard Biener via Gcc-patches]

On Wed, Nov 9, 2022 at 2:07 PM Martin Liška  wrote:
>
> On 11/9/22 14:00, Richard Biener wrote:
> > Do we need a redirect at the old location?
>
> Well, what's not working are older gcc releases that still point to "master" 
> branch
> documentation:
>
> gcc --version
> gcc (SUSE Linux) 12.2.1 20221020 [revision 
> 0aaef83351473e8f4eb774f8f999bbe87a4866d7]
> ...
> https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wunused-parameter
>
> these should point ideally to:
> https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Warning-Options.html#index-Wunused-parameter

I suppose we might want to point to the "latest" 12 version, so have a
gcc-12/ link and use that?
And have a releasing.html entry saying to adjust those URLs in source
to point to the new
version instead of trunk?

> anyway, we can provider redirect for these, I'll ask Gerald.

Thanks

> Martin

Re: [COMMITTED] [range-op-float] Abstract out binary operator code out of PLUS_EXPR entry.

[Jakub Jelinek via Gcc-patches]

On Wed, Nov 09, 2022 at 02:14:19PM +0100, Aldy Hernandez wrote:
> On Wed, Nov 9, 2022 at 1:48 PM Jakub Jelinek  wrote:
> >
> > On Wed, Nov 09, 2022 at 08:07:57AM +0100, Aldy Hernandez wrote:
> > > The PLUS_EXPR was always meant to be a template for further
> > > development, since most of the binary operators will share a similar
> > > structure.  This patch abstracts out the common bits into the default
> > > definition for range_operator_float::fold_range() and provides an
> > > rv_fold() to be implemented by the individual entries wishing to use
> > > the generic folder.  This is akin to what we do with fold_range() and
> > > wi_fold() in the integer version of range-ops.
> >
> > Shouldn't foperator_mult be very similar to this (except that until
> > division is done op[12]_range can't be implemented), with the exception
> > that the invalid case isn't -INF + INF or INF + -INF, but
> > 0 * +/-INF or +/-INF * 0?
> 
> Multiplication and division are tricky because you have to keep track
> of signs to order the resulting range.  It's the most annoying pattern
> we have for integers:

Ah, you're right.
Reminds me of check_for_binary_op_overflow for multiplication.

Jakub

[PATCH] changelog: check for space after tab

[Martin Liška]

Will install if there are not comments.

Martin

contrib/ChangeLog:

* gcc-changelog/git_commit.py: Check for a space after leading
tab.
* gcc-changelog/test_email.py: Likewise.
* gcc-changelog/test_patches.txt: Likewise.
---
 contrib/gcc-changelog/git_commit.py|  8 ++
 contrib/gcc-changelog/test_email.py|  4 +++
 contrib/gcc-changelog/test_patches.txt | 39 ++
 3 files changed, 51 insertions(+)

diff --git a/contrib/gcc-changelog/git_commit.py 
b/contrib/gcc-changelog/git_commit.py
index 1f6e1920829..3bd671011f2 100755
--- a/contrib/gcc-changelog/git_commit.py
+++ b/contrib/gcc-changelog/git_commit.py
@@ -365,6 +365,7 @@ class GitCommit:
 self.check_for_broken_parentheses()
 self.deduce_changelog_locations()
 self.check_file_patterns()
+self.check_line_start()
 if not self.errors:
 self.check_mentioned_files()
 self.check_for_correct_changelog()
@@ -613,6 +614,13 @@ class GitCommit:
 msg = 'bad parentheses wrapping'
 self.errors.append(Error(msg, entry.parentheses_stack[-1]))
 
+def check_line_start(self):
+for entry in self.changelog_entries:
+for line in entry.lines:
+if line.startswith('\t '):
+msg = 'extra space after tab'
+self.errors.append(Error(msg, line))
+
 def get_file_changelog_location(self, changelog_file):
 for file in self.info.modified_files:
 if file[0] == changelog_file:
diff --git a/contrib/gcc-changelog/test_email.py 
b/contrib/gcc-changelog/test_email.py
index c56f6da513a..d0de88cf562 100755
--- a/contrib/gcc-changelog/test_email.py
+++ b/contrib/gcc-changelog/test_email.py
@@ -451,3 +451,7 @@ class TestGccChangelog(unittest.TestCase):
 email = self.from_patch_glob('toplev-new-file.patch')
 assert (email.errors[0].message ==
 'new file in the top-level folder not mentioned in a 
ChangeLog')
+
+def test_space_after_tab(self):
+email = 
self.from_patch_glob('0001-Use-Value_Range-when-applying-inferred-ranges.patch')
+assert (email.errors[0].message == 'extra space after tab')
diff --git a/contrib/gcc-changelog/test_patches.txt 
b/contrib/gcc-changelog/test_patches.txt
index 95ad961f2d3..b28de7d30b0 100644
--- a/contrib/gcc-changelog/test_patches.txt
+++ b/contrib/gcc-changelog/test_patches.txt
@@ -3571,3 +3571,42 @@ index 000..d6459e00543
 +xxx
 -- 
 2.34.1
+
+=== 0001-Use-Value_Range-when-applying-inferred-ranges.patch ===
+From 69a233610f6b27cd4283561569d8ce0f35044dc4 Mon Sep 17 00:00:00 2001
+From: Andrew MacLeod 
+Date: Wed, 19 Oct 2022 09:21:22 -0400
+Subject: [PATCH] Use Value_Range when applying inferred ranges.
+
+Applying an inferred range is using int_range_ma as the
+temporary rather than the general purpose Value_Range.  This causes it
+to trap if we have a non-integral inferred range.
+
+   * gimple-range-cache.cc (ranger_cache::range_from_dom): Use
+ Value_Range not int_range_max.
+---
+ gcc/gimple-range-cache.cc | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/gcc/gimple-range-cache.cc b/gcc/gimple-range-cache.cc
+index 0b9aa3639c5..f279371948a 100644
+--- a/gcc/gimple-range-cache.cc
 b/gcc/gimple-range-cache.cc
+@@ -1546,7 +1546,6 @@ ranger_cache::range_from_dom (vrange &r, tree name, 
basic_block start_bb,
+ void
+ ranger_cache::apply_inferred_ranges (gimple *s)
+ {
+-  int_range_max r;
+   bool update = true;
+ 
+   basic_block bb = gimple_bb (s);
+@@ -1572,6 +1571,7 @@ ranger_cache::apply_inferred_ranges (gimple *s)
+   m_exit.add_range (name, bb, infer.range (x));
+   if (update)
+   {
++Value_Range r (TREE_TYPE (name));
+ if (!m_on_entry.get_bb_range (r, name, bb))
+   exit_range (r, name, bb, RFD_READ_ONLY);
+ if (r.intersect (infer.range (x)))
+-- 
+2.38.0
-- 
2.38.0

Re: [DOCS] sphinx: use new Sphinx links

[Martin Liška]

On 11/9/22 12:22, Martin Liška wrote:
> Gerald, can you please propagate changes I made to:
> htdocs/style.mhtml file?

Gerald I would like to ask you for further server actions related
to the Sphinx documentation:

1) https://gcc.gnu.org/install/ - for the future we will use
https://gcc.gnu.org/onlinedocs/install/

That's a way we can cross reference an older GCC release (e.g. 
https://gcc.gnu.org/onlinedocs/gcc-12.2.0/nstall/)

So please remove content of /www/gcc/htdocs-preformatted/install

2) permanently redirect all '/install/', '/install/...*.html' to:
https://gcc.gnu.org/onlinedocs/install/

Thank you,
Martin

Re: [COMMITTED] [range-op-float] Implement MINUS_EXPR.

[Xi Ruoyao via Gcc-patches]

Hi Aldy,

This commit breaks the attached test case at -O2 on x86_64-linux-gnu and
loongarch64-linux-gnu :(.

The code is simplified from Glibc: the breakage causes two Glibc test
failures on loongarch64-linux-gnu.

Reverting the commit can fix the breakage.

On Wed, 2022-11-09 at 08:07 +0100, Aldy Hernandez via Gcc-patches wrote:
> Now that the generic parts of the binary operators have been
> abstracted, implementing MINUS_EXPR is a cinch.
> 
> The op[12]_range entries will be submitted as a follow-up.
> 
> gcc/ChangeLog:
> 
> * range-op-float.cc (class foperator_minus): New.
> (floating_op_table::floating_op_table): Add MINUS_EXPR entry.
> ---
>  gcc/range-op-float.cc | 24 
>  1 file changed, 24 insertions(+)
> 
> diff --git a/gcc/range-op-float.cc b/gcc/range-op-float.cc
> index 7075c25442a..d52e971f84e 100644
> --- a/gcc/range-op-float.cc
> +++ b/gcc/range-op-float.cc
> @@ -1884,6 +1884,29 @@ class foperator_plus : public
> range_operator_float
>  } fop_plus;
>  
>  
> +class foperator_minus : public range_operator_float
> +{
> +  void rv_fold (REAL_VALUE_TYPE &lb, REAL_VALUE_TYPE &ub, bool
> &maybe_nan,
> +   tree type,
> +   const REAL_VALUE_TYPE &lh_lb,
> +   const REAL_VALUE_TYPE &lh_ub,
> +   const REAL_VALUE_TYPE &rh_lb,
> +   const REAL_VALUE_TYPE &rh_ub) const final override
> +  {
> +    frange_arithmetic (MINUS_EXPR, type, lb, lh_lb, rh_ub,
> dconstninf);
> +    frange_arithmetic (MINUS_EXPR, type, ub, lh_ub, rh_lb,
> dconstinf);
> +
> +    // [+INF] - [+INF] = NAN
> +    if (real_isinf (&lh_ub, false) && real_isinf (&rh_ub, false))
> +  maybe_nan = true;
> +    // [-INF] - [-INF] = NAN
> +    else if (real_isinf (&lh_lb, true) && real_isinf (&rh_lb, true))
> +  maybe_nan = true;
> +    else
> +  maybe_nan = false;
> +  }
> +} fop_minus;
> +
>  // Instantiate a range_op_table for floating point operations.
>  static floating_op_table global_floating_table;
>  
> @@ -1917,6 +1940,7 @@ floating_op_table::floating_op_table ()
>    set (ABS_EXPR, fop_abs);
>    set (NEGATE_EXPR, fop_negate);
>    set (PLUS_EXPR, fop_plus);
> +  set (MINUS_EXPR, fop_minus);
>  }
>  
>  // Return a pointer to the range_operator_float instance, if there is

-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University
__attribute__((noipa,noinline))
int t(double a, double b)
{
	double c = a - b;
	if (!__builtin_isfinite(c)) {
		if (__builtin_isnan(c)) {
			if (!__builtin_isnan(a) && !__builtin_isnan(b))
return 1;
		} else if (__builtin_isfinite(a) && __builtin_isfinite(b))
			return 2;
	} else if (c == 0 && a != b)
		return 3;
	return 4;
}

int main()
{
	double a = __builtin_inf();
	if (t(a, a) != 1)
		__builtin_abort();
}

[PATCH] tree-optimization/84646 - remove premature thread path rejection

[Richard Biener via Gcc-patches]

This removes a premature rejection that's done later in a different
way.

Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.

PR tree-optimization/84646
* tree-ssa-threadbackward.cc (back_threader::maybe_register_path):
Remove premature cycle rejection.
---
 gcc/tree-ssa-threadbackward.cc | 23 +++
 1 file changed, 7 insertions(+), 16 deletions(-)

diff --git a/gcc/tree-ssa-threadbackward.cc b/gcc/tree-ssa-threadbackward.cc
index 2a8cfa3ee01..2290b95717d 100644
--- a/gcc/tree-ssa-threadbackward.cc
+++ b/gcc/tree-ssa-threadbackward.cc
@@ -249,25 +249,16 @@ back_threader::maybe_register_path 
(back_threader_profitability &profit)
 
   if (taken_edge && taken_edge != UNREACHABLE_EDGE)
 {
-  if (m_visited_bbs.contains (taken_edge->dest))
+  bool irreducible = false;
+  if (profit.profitable_path_p (m_path, taken_edge, &irreducible)
+ && debug_counter ()
+ && m_registry.register_path (m_path, taken_edge))
{
- // Avoid circular paths by indicating there is nothing to
- // see in this direction.
- taken_edge = UNREACHABLE_EDGE;
+ if (irreducible)
+   vect_free_loop_info_assumptions (m_path[0]->loop_father);
}
   else
-   {
- bool irreducible = false;
- if (profit.profitable_path_p (m_path, taken_edge, &irreducible)
- && debug_counter ()
- && m_registry.register_path (m_path, taken_edge))
-   {
- if (irreducible)
-   vect_free_loop_info_assumptions (m_path[0]->loop_father);
-   }
- else
-   taken_edge = NULL;
-   }
+   taken_edge = NULL;
 }
 
   if (dump_file && (dump_flags & TDF_DETAILS))
-- 
2.35.3

[PATCH v2 0/4] LoongArch: Add some floating-point operations

[Xi Ruoyao via Gcc-patches]

These patches allow to expand the following builtins to floating point
instructions for LoongArch:

- __builtin_rint{,f}
- __builtin_{l,ll}rint{,f}
- __builtin_{l,ll}floor{,f}
- __builtin_{l,ll}ceil{,f}
- __builtin_scalb{n,ln}{,f}
- __builtin_logb{,f}

Bootstrapped and regtested on loongarch64-linux-gnu.  And a modified
Glibc using the builtins for rint{,f}, {l,ll}rint{,f}, and logb{,f}
also survived Glibc test suite.

Please review ASAP because GCC 13 stage 1 will end on Nov. 13th.

v1 -> v2: Only use ftint{rm,rp} instructions if floor and ceil are
allowed to raise inexact exception.

Xi Ruoyao (4):
  LoongArch: Rename frint_ to rint2
  LoongArch: Add ftint{,rm,rp}.{w,l}.{s,d} instructions
  LoongArch: Add fscaleb.{s,d} instructions as ldexp{sf,df}3
  LoongArch: Add flogb.{s,d} instructions and expand logb{sf,df}2

 gcc/config/loongarch/loongarch.md | 95 ++-
 gcc/testsuite/gcc.target/loongarch/flogb.c| 18 
 gcc/testsuite/gcc.target/loongarch/frint.c| 16 
 gcc/testsuite/gcc.target/loongarch/fscaleb.c  | 48 ++
 .../gcc.target/loongarch/ftint-no-inexact.c   | 44 +
 gcc/testsuite/gcc.target/loongarch/ftint.c| 44 +
 6 files changed, 261 insertions(+), 4 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/loongarch/flogb.c
 create mode 100644 gcc/testsuite/gcc.target/loongarch/frint.c
 create mode 100644 gcc/testsuite/gcc.target/loongarch/fscaleb.c
 create mode 100644 gcc/testsuite/gcc.target/loongarch/ftint-no-inexact.c
 create mode 100644 gcc/testsuite/gcc.target/loongarch/ftint.c

-- 
2.38.1

[PATCH v2 1/4] LoongArch: Rename frint_ to rint2

[Xi Ruoyao via Gcc-patches]

Use standard name so __builtin_rint{,f} can be expanded to one
instruction.

gcc/ChangeLog:

* config/loongarch/loongarch.md (frint_): Rename to ..
(rint2): .. this.

gcc/testsuite/ChangeLog:

* gcc.target/loongarch/frint.c: New test.
---
 gcc/config/loongarch/loongarch.md  |  4 ++--
 gcc/testsuite/gcc.target/loongarch/frint.c | 16 
 2 files changed, 18 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/loongarch/frint.c

diff --git a/gcc/config/loongarch/loongarch.md 
b/gcc/config/loongarch/loongarch.md
index bda34d0f3db..a14ab14ac24 100644
--- a/gcc/config/loongarch/loongarch.md
+++ b/gcc/config/loongarch/loongarch.md
@@ -2012,8 +2012,8 @@ (define_insn "lui_h_hi12"
   [(set_attr "type" "move")]
 )
 
-;; Convert floating-point numbers to integers
-(define_insn "frint_"
+;; Round floating-point numbers to integers
+(define_insn "rint2"
   [(set (match_operand:ANYF 0 "register_operand" "=f")
(unspec:ANYF [(match_operand:ANYF 1 "register_operand" "f")]
  UNSPEC_FRINT))]
diff --git a/gcc/testsuite/gcc.target/loongarch/frint.c 
b/gcc/testsuite/gcc.target/loongarch/frint.c
new file mode 100644
index 000..3ee6a8f973a
--- /dev/null
+++ b/gcc/testsuite/gcc.target/loongarch/frint.c
@@ -0,0 +1,16 @@
+/* { dg-do compile } */
+/* { dg-options "-mdouble-float" } */
+/* { dg-final { scan-assembler "frint\\.s" } } */
+/* { dg-final { scan-assembler "frint\\.d" } } */
+
+double
+my_rint (double a)
+{
+  return __builtin_rint (a);
+}
+
+float
+my_rintf (float a)
+{
+  return __builtin_rintf (a);
+}
-- 
2.38.1

[PATCH v2 3/4] LoongArch: Add fscaleb.{s, d} instructions as ldexp{sf, df}3

[Xi Ruoyao via Gcc-patches]

This allows optimizing __builtin_ldexp{,f} and __builtin_scalbn{,f} with
-fno-math-errno.

IMODE is added because we can't hard code SI for operand 2: fscaleb.d
instruction always take the high half of both source registers into
account.  See my_ldexp_long in the test case.

gcc/ChangeLog:

* config/loongarch/loongarch.md (UNSPEC_FSCALEB): New unspec.
(type): Add fscaleb.
(IMODE): New mode attr.
(ldexp3): New instruction template.

gcc/testsuite/ChangeLog:

* gcc.target/loongarch/fscaleb.c: New test.
---
 gcc/config/loongarch/loongarch.md| 26 ++-
 gcc/testsuite/gcc.target/loongarch/fscaleb.c | 48 
 2 files changed, 72 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/loongarch/fscaleb.c

diff --git a/gcc/config/loongarch/loongarch.md 
b/gcc/config/loongarch/loongarch.md
index eb127c346a3..c141c9adde2 100644
--- a/gcc/config/loongarch/loongarch.md
+++ b/gcc/config/loongarch/loongarch.md
@@ -41,6 +41,7 @@ (define_c_enum "unspec" [
   UNSPEC_FTINT
   UNSPEC_FTINTRM
   UNSPEC_FTINTRP
+  UNSPEC_FSCALEB
 
   ;; Override return address for exception handling.
   UNSPEC_EH_RETURN
@@ -220,6 +221,7 @@ (define_attr "qword_mode" "no,yes"
 ;; fcmpfloating point compare
 ;; fcopysign   floating point copysign
 ;; fcvtfloating point convert
+;; fscaleb floating point scale
 ;; fsqrt   floating point square root
 ;; frsqrt   floating point reciprocal square root
 ;; multi   multiword sequence (or user asm statements)
@@ -231,8 +233,8 @@ (define_attr "type"
   "unknown,branch,jump,call,load,fpload,fpidxload,store,fpstore,fpidxstore,
prefetch,prefetchx,condmove,mgtf,mftg,const,arith,logical,
shift,slt,signext,clz,trap,imul,idiv,move,
-   fmove,fadd,fmul,fmadd,fdiv,frdiv,fabs,fneg,fcmp,fcopysign,fcvt,fsqrt,
-   frsqrt,accext,accmod,multi,atomic,syncloop,nop,ghost"
+   fmove,fadd,fmul,fmadd,fdiv,frdiv,fabs,fneg,fcmp,fcopysign,fcvt,fscaleb,
+   fsqrt,frsqrt,accext,accmod,multi,atomic,syncloop,nop,ghost"
   (cond [(eq_attr "jirl" "!unset") (const_string "call")
 (eq_attr "got" "load") (const_string "load")
 
@@ -418,6 +420,10 @@ (define_mode_attr UNITMODE [(SF "SF") (DF "DF")])
 ;; the controlling mode.
 (define_mode_attr HALFMODE [(DF "SI") (DI "SI") (TF "DI")])
 
+;; This attribute gives the integer mode that has the same size of a
+;; floating-point mode.
+(define_mode_attr IMODE [(SF "SI") (DF "DI")])
+
 ;; This code iterator allows signed and unsigned widening multiplications
 ;; to use the same template.
 (define_code_iterator any_extend [sign_extend zero_extend])
@@ -1014,7 +1020,23 @@ (define_insn "copysign3"
   "fcopysign.\t%0,%1,%2"
   [(set_attr "type" "fcopysign")
(set_attr "mode" "")])
+
+;;
+;;  
+;;
+;; FLOATING POINT SCALE
+;;
+;;  
 
+(define_insn "ldexp3"
+  [(set (match_operand:ANYF 0 "register_operand" "=f")
+   (unspec:ANYF [(match_operand:ANYF1 "register_operand" "f")
+ (match_operand: 2 "register_operand" "f")]
+UNSPEC_FSCALEB))]
+  "TARGET_HARD_FLOAT"
+  "fscaleb.\t%0,%1,%2"
+  [(set_attr "type" "fscaleb")
+   (set_attr "mode" "")])
 
 ;;
 ;;  ...
diff --git a/gcc/testsuite/gcc.target/loongarch/fscaleb.c 
b/gcc/testsuite/gcc.target/loongarch/fscaleb.c
new file mode 100644
index 000..f18470fbb8f
--- /dev/null
+++ b/gcc/testsuite/gcc.target/loongarch/fscaleb.c
@@ -0,0 +1,48 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -mabi=lp64d -mdouble-float -fno-math-errno" } */
+/* { dg-final { scan-assembler-times "fscaleb\\.s" 3 } } */
+/* { dg-final { scan-assembler-times "fscaleb\\.d" 4 } } */
+/* { dg-final { scan-assembler-times "slli\\.w" 1 } } */
+
+double
+my_scalbln (double a, long b)
+{
+  return __builtin_scalbln (a, b);
+}
+
+double
+my_scalbn (double a, int b)
+{
+  return __builtin_scalbn (a, b);
+}
+
+double
+my_ldexp (double a, int b)
+{
+  return __builtin_ldexp (a, b);
+}
+
+float
+my_scalblnf (float a, long b)
+{
+  return __builtin_scalblnf (a, b);
+}
+
+float
+my_scalbnf (float a, int b)
+{
+  return __builtin_scalbnf (a, b);
+}
+
+float
+my_ldexpf (float a, int b)
+{
+  return __builtin_ldexpf (a, b);
+}
+
+/* b must be sign-extended */
+double
+my_ldexp_long (double a, long b)
+{
+  return __builtin_ldexp (a, b);
+}
-- 
2.38.1

[PATCH v2 2/4] LoongArch: Add ftint{,rm,rp}.{w,l}.{s,d} instructions

[Xi Ruoyao via Gcc-patches]

This allows to optimize the following builtins if -fno-math-errno:

- __builtin_lrint{,f}
- __builtin_lfloor{,f}
- __builtin_lceil{,f}

Inspired by
https://gcc.gnu.org/pipermail/gcc-patches/2022-November/605287.html.

ANYFI is added so the compiler won't try ftint.l.s if -mfpu=32.  If we
simply used GPR here an ICE would be triggered with __builtin_lrintf
and -mfpu=32.

ftint{rm,rp} instructions may raise inexact exception, so they can't be
used if -fno-trapping-math -fno-fp-int-builtin-inexact.

Note that the .w.{s,d} variants are not tested because we don't support
ILP32 for now.

gcc/ChangeLog:

* config/loongarch/loongarch.md (UNSPEC_FTINT): New unspec.
(UNSPEC_FTINTRM): Likewise.
(UNSPEC_FTINTRP): Likewise.
(LRINT): New define_int_iterator.
(lrint_pattern): New define_int_attr.
(lrint_submenmonic): Likewise.
(lrint_allow_inexact): Likewise.
(ANYFI): New define_mode_iterator.
(lrint): New instruction template.

gcc/testsuite/ChangeLog:

* gcc.target/loongarch/ftint.c: New test.
* gcc.target/loongarch/ftint-no-inexact.c: New test.
---
 gcc/config/loongarch/loongarch.md | 34 ++
 .../gcc.target/loongarch/ftint-no-inexact.c   | 44 +++
 gcc/testsuite/gcc.target/loongarch/ftint.c| 44 +++
 3 files changed, 122 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/loongarch/ftint-no-inexact.c
 create mode 100644 gcc/testsuite/gcc.target/loongarch/ftint.c

diff --git a/gcc/config/loongarch/loongarch.md 
b/gcc/config/loongarch/loongarch.md
index a14ab14ac24..eb127c346a3 100644
--- a/gcc/config/loongarch/loongarch.md
+++ b/gcc/config/loongarch/loongarch.md
@@ -38,6 +38,9 @@ (define_c_enum "unspec" [
   UNSPEC_FMAX
   UNSPEC_FMIN
   UNSPEC_FCOPYSIGN
+  UNSPEC_FTINT
+  UNSPEC_FTINTRM
+  UNSPEC_FTINTRP
 
   ;; Override return address for exception handling.
   UNSPEC_EH_RETURN
@@ -374,6 +377,11 @@ (define_mode_iterator QHWD [QI HI SI (DI "TARGET_64BIT")])
 (define_mode_iterator ANYF [(SF "TARGET_HARD_FLOAT")
(DF "TARGET_DOUBLE_FLOAT")])
 
+;; Iterator for fixed-point modes which can be hold by a hardware
+;; floating-point register.
+(define_mode_iterator ANYFI [(SI "TARGET_HARD_FLOAT")
+(DI "TARGET_DOUBLE_FLOAT")])
+
 ;; A mode for which moves involving FPRs may need to be split.
 (define_mode_iterator SPLITF
   [(DF "!TARGET_64BIT && TARGET_DOUBLE_FLOAT")
@@ -515,6 +523,19 @@ (define_code_attr fcond [(unordered "cun")
 (define_code_attr sel [(eq "masknez") (ne "maskeqz")])
 (define_code_attr selinv [(eq "maskeqz") (ne "masknez")])
 
+;; Iterator and attributes for floating-point to fixed-point conversion
+;; instructions.
+(define_int_iterator LRINT [UNSPEC_FTINT UNSPEC_FTINTRM UNSPEC_FTINTRP])
+(define_int_attr lrint_pattern [(UNSPEC_FTINT "lrint")
+   (UNSPEC_FTINTRM "lfloor")
+   (UNSPEC_FTINTRP "lceil")])
+(define_int_attr lrint_submenmonic [(UNSPEC_FTINT "")
+   (UNSPEC_FTINTRM "rm")
+   (UNSPEC_FTINTRP "rp")])
+(define_int_attr lrint_allow_inexact [(UNSPEC_FTINT "1")
+ (UNSPEC_FTINTRM "0")
+ (UNSPEC_FTINTRP "0")])
+
 ;;
 ;;  
 ;;
@@ -2022,6 +2043,19 @@ (define_insn "rint2"
   [(set_attr "type" "fcvt")
(set_attr "mode" "")])
 
+;; Convert floating-point numbers to integers
+(define_insn "2"
+  [(set (match_operand:ANYFI 0 "register_operand" "=f")
+   (unspec:ANYFI [(match_operand:ANYF 1 "register_operand" "f")]
+ LRINT))]
+  "TARGET_HARD_FLOAT &&
+   (
+|| flag_fp_int_builtin_inexact
+|| !flag_trapping_math)"
+  "ftint.. %0,%1"
+  [(set_attr "type" "fcvt")
+   (set_attr "mode" "")])
+
 ;; Load the low word of operand 0 with operand 1.
 (define_insn "load_low"
   [(set (match_operand:SPLITF 0 "register_operand" "=f,f")
diff --git a/gcc/testsuite/gcc.target/loongarch/ftint-no-inexact.c 
b/gcc/testsuite/gcc.target/loongarch/ftint-no-inexact.c
new file mode 100644
index 000..88b83a9c056
--- /dev/null
+++ b/gcc/testsuite/gcc.target/loongarch/ftint-no-inexact.c
@@ -0,0 +1,44 @@
+/* { dg-do compile } */
+/* { dg-options "-mabi=lp64d -mdouble-float -fno-math-errno 
-fno-fp-int-builtin-inexact" } */
+/* { dg-final { scan-assembler "ftint\\.l\\.s" } } */
+/* { dg-final { scan-assembler "ftint\\.l\\.d" } } */
+/* { dg-final { scan-assembler-not "ftintrm\\.l\\.s" } } */
+/* { dg-final { scan-assembler-not "ftintrm\\.l\\.d" } } */
+/* { dg-final { scan-assembler-not "ftintrp\\.l\\.s" } } */
+/* { dg-final { scan-assembler-not "ftintrp\\.l\\.d" } } */
+
+long
+my_lrint (double a)
+{
+  return __builtin_lrint (a);
+}
+
+long
+my_lrintf (float a)
+{
+  return __builtin_lrintf (a);
+}
+
+long
+my_lfloor (double a)
+{
+  return __builtin_lfloor (a);
+}
+
+long
+my_lfloor

Re: [PATCH Rust front-end v3 38/46] gccrs: Add HIR to GCC GENERIC lowering entry point

[Richard Biener via Gcc-patches]

On Wed, Oct 26, 2022 at 10:37 AM  wrote:
>
> From: Philip Herron 
>
> This patch contains the entry point and utilities used for the lowering
> of HIR nodes to `tree`s. It also contains a constant evaluator, ported
> over from the C++ frontend.
>
> Co-authored-by: David Faust 
> Co-authored-by: Faisal Abbas <90.abbasfai...@gmail.com>
> ---
>  gcc/rust/backend/rust-compile-context.cc | 146 
>  gcc/rust/backend/rust-compile-context.h  | 343 ++
>  gcc/rust/backend/rust-compile.cc | 414 +
>  gcc/rust/backend/rust-compile.h  |  47 +++
>  gcc/rust/backend/rust-constexpr.cc   | 441 +++
>  gcc/rust/backend/rust-constexpr.h|  31 ++
>  6 files changed, 1422 insertions(+)
>  create mode 100644 gcc/rust/backend/rust-compile-context.cc
>  create mode 100644 gcc/rust/backend/rust-compile-context.h
>  create mode 100644 gcc/rust/backend/rust-compile.cc
>  create mode 100644 gcc/rust/backend/rust-compile.h
>  create mode 100644 gcc/rust/backend/rust-constexpr.cc
>  create mode 100644 gcc/rust/backend/rust-constexpr.h
>
> diff --git a/gcc/rust/backend/rust-compile-context.cc 
> b/gcc/rust/backend/rust-compile-context.cc
> new file mode 100644
> index 000..cb2addf6c21
> --- /dev/null
> +++ b/gcc/rust/backend/rust-compile-context.cc
> @@ -0,0 +1,146 @@
> +// Copyright (C) 2020-2022 Free Software Foundation, Inc.
> +
> +// This file is part of GCC.
> +
> +// GCC is free software; you can redistribute it and/or modify it under
> +// the terms of the GNU General Public License as published by the Free
> +// Software Foundation; either version 3, or (at your option) any later
> +// version.
> +
> +// GCC is distributed in the hope that it will be useful, but WITHOUT ANY
> +// WARRANTY; without even the implied warranty of MERCHANTABILITY or
> +// FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
> +// for more details.
> +
> +// You should have received a copy of the GNU General Public License
> +// along with GCC; see the file COPYING3.  If not see
> +// .
> +
> +#include "rust-compile-context.h"
> +#include "rust-compile-type.h"
> +
> +namespace Rust {
> +namespace Compile {
> +
> +Context::Context (::Backend *backend)
> +  : backend (backend), resolver (Resolver::Resolver::get ()),
> +tyctx (Resolver::TypeCheckContext::get ()),
> +mappings (Analysis::Mappings::get ()), mangler (Mangler ())
> +{
> +  setup_builtins ();
> +}
> +
> +void
> +Context::setup_builtins ()
> +{
> +  auto builtins = resolver->get_builtin_types ();
> +  for (auto it = builtins.begin (); it != builtins.end (); it++)
> +{
> +  HirId ref;
> +  bool ok = tyctx->lookup_type_by_node_id ((*it)->get_node_id (), &ref);
> +  rust_assert (ok);
> +
> +  TyTy::BaseType *lookup;
> +  ok = tyctx->lookup_type (ref, &lookup);
> +  rust_assert (ok);
> +
> +  TyTyResolveCompile::compile (this, lookup);
> +}
> +}
> +
> +hashval_t
> +Context::type_hasher (tree type)
> +{
> +  inchash::hash hstate;
> +
> +  hstate.add_int (TREE_CODE (type));
> +
> +  if (TYPE_NAME (type))
> +{
> +  hashval_t record_name_hash
> +   = IDENTIFIER_HASH_VALUE (DECL_NAME (TYPE_NAME (type)));
> +  hstate.add_object (record_name_hash);
> +}

The following does look a bit like type_hash_canon_hash.  I'll probably see what
we use tree type hashing for, just wondering here.

> +  for (tree t = TYPE_ATTRIBUTES (type); t; t = TREE_CHAIN (t))
> +/* Just the identifier is adequate to distinguish.  */
> +hstate.add_object (IDENTIFIER_HASH_VALUE (TREE_PURPOSE (t)));
> +
> +  switch (TREE_CODE (type))
> +{
> +case METHOD_TYPE:
> +  hstate.add_object (TYPE_HASH (TYPE_METHOD_BASETYPE (type)));
> +  /* FALLTHROUGH. */
> +case FUNCTION_TYPE:
> +  for (tree t = TYPE_ARG_TYPES (type); t; t = TREE_CHAIN (t))
> +   if (TREE_VALUE (t) != error_mark_node)
> + hstate.add_object (TYPE_HASH (TREE_VALUE (t)));
> +  break;
> +
> +case OFFSET_TYPE:
> +  hstate.add_object (TYPE_HASH (TYPE_OFFSET_BASETYPE (type)));
> +  break;
> +
> +  case ARRAY_TYPE: {

GCC coding conventions would say the { goes to the next line and indented.
The rust FE might intentionally diverge from that standard, if so a
pointer in some
README in rust/ would be helpful.

> +   if (TYPE_DOMAIN (type))
> + hstate.add_object (TYPE_HASH (TYPE_DOMAIN (type)));
> +   if (!AGGREGATE_TYPE_P (TREE_TYPE (type)))
> + {
> +   unsigned typeless = TYPE_TYPELESS_STORAGE (type);
> +   hstate.add_object (typeless);
> + }
> +  }
> +  break;
> +
> +  case INTEGER_TYPE: {
> +   tree t = TYPE_MAX_VALUE (type);
> +   if (!t)
> + t = TYPE_MIN_VALUE (type);
> +   for (int i = 0; i < TREE_INT_CST_NUNITS (t); i++)
> + hstate.add_object (TREE_INT_CST_ELT (t, i));
> +   break;
> +  }
> +
> +case REAL_TYPE:
> 

[PATCH v2 4/4] LoongArch: Add flogb.{s, d} instructions and expand logb{sf, df}2

[Xi Ruoyao via Gcc-patches]

On LoongArch, flogb instructions extract the exponent of a non-negative
floating point value, but produces NaN for negative values.  So we need
to add a fabs instruction when we expand logb.

gcc/ChangeLog:

* config/loongarch/loongarch.md (UNSPEC_FLOGB): New unspec.
(type): Add flogb.
(logb_non_negative2): New instruction template.
(logb2): New define_expand.

gcc/testsuite/ChangeLog:

* gcc.target/loongarch/flogb.c: New test.
---
 gcc/config/loongarch/loongarch.md  | 35 --
 gcc/testsuite/gcc.target/loongarch/flogb.c | 18 +++
 2 files changed, 51 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/loongarch/flogb.c

diff --git a/gcc/config/loongarch/loongarch.md 
b/gcc/config/loongarch/loongarch.md
index c141c9adde2..682ab961741 100644
--- a/gcc/config/loongarch/loongarch.md
+++ b/gcc/config/loongarch/loongarch.md
@@ -42,6 +42,7 @@ (define_c_enum "unspec" [
   UNSPEC_FTINTRM
   UNSPEC_FTINTRP
   UNSPEC_FSCALEB
+  UNSPEC_FLOGB
 
   ;; Override return address for exception handling.
   UNSPEC_EH_RETURN
@@ -217,6 +218,7 @@ (define_attr "qword_mode" "no,yes"
 ;; fdivfloating point divide
 ;; frdiv   floating point reciprocal divide
 ;; fabsfloating point absolute value
+;; flogb   floating point exponent extract
 ;; fnegfloating point negation
 ;; fcmpfloating point compare
 ;; fcopysign   floating point copysign
@@ -233,8 +235,8 @@ (define_attr "type"
   "unknown,branch,jump,call,load,fpload,fpidxload,store,fpstore,fpidxstore,
prefetch,prefetchx,condmove,mgtf,mftg,const,arith,logical,
shift,slt,signext,clz,trap,imul,idiv,move,
-   fmove,fadd,fmul,fmadd,fdiv,frdiv,fabs,fneg,fcmp,fcopysign,fcvt,fscaleb,
-   fsqrt,frsqrt,accext,accmod,multi,atomic,syncloop,nop,ghost"
+   fmove,fadd,fmul,fmadd,fdiv,frdiv,fabs,flogb,fneg,fcmp,fcopysign,fcvt,
+   fscaleb,fsqrt,frsqrt,accext,accmod,multi,atomic,syncloop,nop,ghost"
   (cond [(eq_attr "jirl" "!unset") (const_string "call")
 (eq_attr "got" "load") (const_string "load")
 
@@ -1039,6 +1041,35 @@ (define_insn "ldexp3"
(set_attr "mode" "")])
 
 ;;
+;;  
+;;
+;; FLOATING POINT EXPONENT EXTRACT
+;;
+;;  
+
+(define_insn "logb_non_negative2"
+  [(set (match_operand:ANYF 0 "register_operand" "=f")
+   (unspec:ANYF [(match_operand:ANYF 1 "register_operand" "f")]
+UNSPEC_FLOGB))]
+  "TARGET_HARD_FLOAT"
+  "flogb.\t%0,%1"
+  [(set_attr "type" "flogb")
+   (set_attr "mode" "")])
+
+(define_expand "logb2"
+  [(set (match_operand:ANYF 0 "register_operand")
+   (unspec:ANYF [(abs:ANYF (match_operand:ANYF 1 "register_operand"))]
+UNSPEC_FLOGB))]
+  "TARGET_HARD_FLOAT"
+{
+  rtx tmp = gen_reg_rtx (mode);
+
+  emit_insn (gen_abs2 (tmp, operands[1]));
+  emit_insn (gen_logb_non_negative2 (operands[0], tmp));
+  DONE;
+})
+
+;;
 ;;  ...
 ;;
 ;;  Count leading zeroes.
diff --git a/gcc/testsuite/gcc.target/loongarch/flogb.c 
b/gcc/testsuite/gcc.target/loongarch/flogb.c
new file mode 100644
index 000..1daefe54e13
--- /dev/null
+++ b/gcc/testsuite/gcc.target/loongarch/flogb.c
@@ -0,0 +1,18 @@
+/* { dg-do compile } */
+/* { dg-options "-mdouble-float -fno-math-errno" } */
+/* { dg-final { scan-assembler "fabs\\.s" } } */
+/* { dg-final { scan-assembler "fabs\\.d" } } */
+/* { dg-final { scan-assembler "flogb\\.s" } } */
+/* { dg-final { scan-assembler "flogb\\.d" } } */
+
+double
+my_logb (double a)
+{
+  return __builtin_logb (a);
+}
+
+float
+my_logbf (float a)
+{
+  return __builtin_logbf (a);
+}
-- 
2.38.1

[RFC] docs: remove documentation for unsupported releases

[Martin Liška]

Hi.

I think we should remove documentation for unsupported GCC releases
as it's indexed by Google engine. Second reason is that the page is long
one one can't easily jump to Current development documentation.

Thoughts?
Martin

---
 htdocs/onlinedocs/index.html | 1294 --
 1 file changed, 1294 deletions(-)

diff --git a/htdocs/onlinedocs/index.html b/htdocs/onlinedocs/index.html
index cfa8bf5a..138dde95 100644
--- a/htdocs/onlinedocs/index.html
+++ b/htdocs/onlinedocs/index.html
@@ -255,1300 +255,6 @@
 https://gcc.gnu.org/onlinedocs/gcc-10.4.0/docs-sources.tar.gz";>Texinfo
  sources of all the GCC 10.4 manuals
   
-
-  GCC 9.5 manuals:
-  
-https://gcc.gnu.org/onlinedocs/gcc-9.5.0/gcc/";>GCC
- 9.5 Manual (https://gcc.gnu.org/onlinedocs/gcc-9.5.0/gcc.pdf";>also
- in PDF or https://gcc.gnu.org/onlinedocs/gcc-9.5.0/gcc.ps.gz";>PostScript or https://gcc.gnu.org/onlinedocs/gcc-9.5.0/gcc-html.tar.gz";>an
- HTML tarball)
-https://gcc.gnu.org/onlinedocs/gcc-9.5.0/gfortran/";>GCC
- 9.5 GNU Fortran Manual (https://gcc.gnu.org/onlinedocs/gcc-9.5.0/gfortran.pdf";>also
- in PDF or https://gcc.gnu.org/onlinedocs/gcc-9.5.0/gfortran.ps.gz";>PostScript 
or https://gcc.gnu.org/onlinedocs/gcc-9.5.0/gfortran-html.tar.gz";>an
- HTML tarball)
-https://gcc.gnu.org/onlinedocs/gcc-9.5.0/cpp/";>GCC
- 9.5 CPP Manual (https://gcc.gnu.org/onlinedocs/gcc-9.5.0/cpp.pdf";>also
- in PDF or https://gcc.gnu.org/onlinedocs/gcc-9.5.0/cpp.ps.gz";>PostScript or https://gcc.gnu.org/onlinedocs/gcc-9.5.0/cpp-html.tar.gz";>an
- HTML tarball)
-https://gcc.gnu.org/onlinedocs/gcc-9.5.0/gnat_rm/";>GCC
- 9.5 GNAT Reference Manual (https://gcc.gnu.org/onlinedocs/gcc-9.5.0/gnat_rm.pdf";>also
- in PDF or https://gcc.gnu.org/onlinedocs/gcc-9.5.0/gnat_rm.ps.gz";>PostScript or 
https://gcc.gnu.org/onlinedocs/gcc-9.5.0/gnat_rm-html.tar.gz";>an
- HTML tarball)
-https://gcc.gnu.org/onlinedocs/gcc-9.5.0/gnat_ugn/";>GCC
- 9.5 GNAT User's Guide (https://gcc.gnu.org/onlinedocs/gcc-9.5.0/gnat_ugn.pdf";>also
- in PDF or https://gcc.gnu.org/onlinedocs/gcc-9.5.0/gnat_ugn.ps.gz";>PostScript 
or https://gcc.gnu.org/onlinedocs/gcc-9.5.0/gnat_ugn-html.tar.gz";>an
- HTML tarball)
-https://gcc.gnu.org/onlinedocs/gcc-9.5.0/libstdc++/manual/";>GCC
- 9.5 Standard C++ Library Manual  (https://gcc.gnu.org/onlinedocs/gcc-9.5.0/libstdc++-manual.pdf.gz";>also
- in PDF or https://gcc.gnu.org/onlinedocs/gcc-9.5.0/libstdc++-manual.xml.gz";>XML 
or https://gcc.gnu.org/onlinedocs/gcc-9.5.0/libstdc++-manual-html.tar.gz";>an
- HTML tarball)
-https://gcc.gnu.org/onlinedocs/gcc-9.5.0/libstdc++/api/";>GCC
- 9.5 Standard C++ Library Reference Manual  (https://gcc.gnu.org/onlinedocs/gcc-9.5.0/libstdc++-api.pdf.gz";>also
- in PDF or https://gcc.gnu.org/onlinedocs/gcc-9.5.0/libstdc++-api.xml.gz";>XML 
GPL or
- https://gcc.gnu.org/onlinedocs/gcc-9.5.0/libstdc++-api-gfdl.xml.gz";>XML 
GFDL or https://gcc.gnu.org/onlinedocs/gcc-9.5.0/libstdc++-api-html.tar.gz";>an
- HTML tarball)
-https://gcc.gnu.org/onlinedocs/gcc-9.5.0/gccgo/";>GCCGO 9.5 
Manual (https://gcc.gnu.org/onlinedocs/gcc-9.5.0/gccgo.pdf";>also in
-   PDF or https://gcc.gnu.org/onlinedocs/gcc-9.5.0/gccgo.ps.gz";>PostScript or https://gcc.gnu.org/onlinedocs/gcc-9.5.0/gccgo-html.tar.gz";>an
-   HTML tarball)
-https://gcc.gnu.org/onlinedocs/gcc-9.5.0/libgomp/";>GCC 9.5
- GNU Offloading and Multi Processing Runtime Library Manual (https://gcc.gnu.org/onlinedocs/gcc-9.5.0/libgomp.pdf";>also in
- PDF or https://gcc.gnu.org/onlinedocs/gcc-9.5.0/libgomp.ps.gz";>PostScript or 
https://gcc.gnu.org/onlinedocs/gcc-9.5.0/libgomp-html.tar.gz";>an
- HTML tarball)
-https://gcc.gnu.org/onlinedocs/gcc-9.5.0/libquadmath/";>GCC 9.5
- Quad-Precision Math Library Manual (https://gcc.gnu.org/onlinedocs/gcc-9.5.0/libquadmath.pdf";>also 
in
- PDF or https://gcc.gnu.org/onlinedocs/gcc-9.5.0/libquadmath.ps.gz";>PostScript
 or https://gcc.gnu.org/onlinedocs/gcc-9.5.0/libquadmath-html.tar.gz";>an
- HTML tarball)
-https://gcc.gnu.org/onlinedocs/gcc-9.5.0/jit/";>GCC 9.5 JIT
- Library
-https://gcc.gnu.org/onlinedocs/gcc-9.5.0/docs-sources.tar.gz";>Texinfo
- sources of all the GCC 9.5 manuals
-  
-
-  GCC 8.5 manuals:
-  
-https://gcc.gnu.org/onlinedocs/gcc-8.5.0/gcc/";>GCC
- 8.5 Manual (https://gcc.gnu.org/onlinedocs/gcc-8.5.0/gcc.pdf";>also
- in PDF or https://gcc.gnu.org/onlinedocs/gcc-8.5.0/gcc.ps.gz";>PostScript or https://gcc.gnu.org/onlinedocs/gcc-8.5.0/gcc-html.tar.gz";>an
- HTML tarball)
-https://gcc.gnu.org/onlinedocs/gcc-8.5.0/gfortran/";>GCC
- 8.5 GNU Fortran Manual (https://gcc.gnu.org/onlinedocs/gcc-8.5.0/gfortran.pdf";>also
- in PDF or https://gcc.gnu.org/onlinedocs/gcc-8.5.0/

Re: [COMMITTED] [range-op-float] Implement MINUS_EXPR.

[Xi Ruoyao via Gcc-patches]

On Wed, 2022-11-09 at 21:49 +0800, Xi Ruoyao wrote:
> Hi Aldy,
> 
> This commit breaks the attached test case at -O2 on x86_64-linux-gnu and
  ^^^

Ah, not this one.  I meant r13-3842 "Implement op[12]_range operators
for PLUS_EXPR and MINUS_EXPR."

> loongarch64-linux-gnu :(.
> 
> The code is simplified from Glibc: the breakage causes two Glibc test
> failures on loongarch64-linux-gnu.
> 
> Reverting the commit can fix the breakage.
^^ also r13-3842.

/* snip */

> > The op[12]_range entries will be submitted as a follow-up.

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

Re: [RFC] docs: remove documentation for unsupported releases

[Jakub Jelinek via Gcc-patches]

On Wed, Nov 09, 2022 at 02:54:48PM +0100, Martin Liška wrote:
> I think we should remove documentation for unsupported GCC releases
> as it's indexed by Google engine. Second reason is that the page is long
> one one can't easily jump to Current development documentation.
> 
> Thoughts?

I'd prefer to move it into a separate old.html or unsupported.html
and perhaps mark it so that search engines ignore it.
With a link from onlinedocs/index.html to that.
While we don't support those releases, they are actually used in the
wild, both through vendor support or just because people keep using them
unsupported.

In either case, branch-closing.html should be updated to include
the required manual step (either drop the old release from
onlinedocs/index.html, or move it to the other page).

Dropping the docs altogether would mean it wouldn't make much sense
to even generate documentation for the last release from a release branch,
because those by definition go immediately out of support.
We still release them...

> diff --git a/htdocs/onlinedocs/index.html b/htdocs/onlinedocs/index.html
> index cfa8bf5a..138dde95 100644
> --- a/htdocs/onlinedocs/index.html
> +++ b/htdocs/onlinedocs/index.html
> @@ -255,1300 +255,6 @@
>   href="https://gcc.gnu.org/onlinedocs/gcc-10.4.0/docs-sources.tar.gz";>Texinfo
>   sources of all the GCC 10.4 manuals
>
> -
> -  GCC 9.5 manuals:
> -  
> -https://gcc.gnu.org/onlinedocs/gcc-9.5.0/gcc/";>GCC
> - 9.5 Manual ( - href="https://gcc.gnu.org/onlinedocs/gcc-9.5.0/gcc.pdf";>also
> - in PDF or  - 
> href="https://gcc.gnu.org/onlinedocs/gcc-9.5.0/gcc.ps.gz";>PostScript or  - href="https://gcc.gnu.org/onlinedocs/gcc-9.5.0/gcc-html.tar.gz";>an
> - HTML tarball)
> -https://gcc.gnu.org/onlinedocs/gcc-9.5.0/gfortran/";>GCC
> - 9.5 GNU Fortran Manual ( - href="https://gcc.gnu.org/onlinedocs/gcc-9.5.0/gfortran.pdf";>also
> - in PDF or  - 
> href="https://gcc.gnu.org/onlinedocs/gcc-9.5.0/gfortran.ps.gz";>PostScript 
> or  - 
> href="https://gcc.gnu.org/onlinedocs/gcc-9.5.0/gfortran-html.tar.gz";>an
> - HTML tarball)
> -https://gcc.gnu.org/onlinedocs/gcc-9.5.0/cpp/";>GCC
> - 9.5 CPP Manual ( - href="https://gcc.gnu.org/onlinedocs/gcc-9.5.0/cpp.pdf";>also
> - in PDF or  - 
> href="https://gcc.gnu.org/onlinedocs/gcc-9.5.0/cpp.ps.gz";>PostScript or  - href="https://gcc.gnu.org/onlinedocs/gcc-9.5.0/cpp-html.tar.gz";>an
> - HTML tarball)
> -https://gcc.gnu.org/onlinedocs/gcc-9.5.0/gnat_rm/";>GCC
> - 9.5 GNAT Reference Manual ( - href="https://gcc.gnu.org/onlinedocs/gcc-9.5.0/gnat_rm.pdf";>also
> - in PDF or  - 
> href="https://gcc.gnu.org/onlinedocs/gcc-9.5.0/gnat_rm.ps.gz";>PostScript 
> or  - 
> href="https://gcc.gnu.org/onlinedocs/gcc-9.5.0/gnat_rm-html.tar.gz";>an
> - HTML tarball)
> -https://gcc.gnu.org/onlinedocs/gcc-9.5.0/gnat_ugn/";>GCC
> - 9.5 GNAT User's Guide ( - href="https://gcc.gnu.org/onlinedocs/gcc-9.5.0/gnat_ugn.pdf";>also
> - in PDF or  - 
> href="https://gcc.gnu.org/onlinedocs/gcc-9.5.0/gnat_ugn.ps.gz";>PostScript 
> or  - 
> href="https://gcc.gnu.org/onlinedocs/gcc-9.5.0/gnat_ugn-html.tar.gz";>an
> - HTML tarball)
> - href="https://gcc.gnu.org/onlinedocs/gcc-9.5.0/libstdc++/manual/";>GCC
> - 9.5 Standard C++ Library Manual  ( - 
> href="https://gcc.gnu.org/onlinedocs/gcc-9.5.0/libstdc++-manual.pdf.gz";>also
> - in PDF or  - 
> href="https://gcc.gnu.org/onlinedocs/gcc-9.5.0/libstdc++-manual.xml.gz";>XML
>  or  - 
> href="https://gcc.gnu.org/onlinedocs/gcc-9.5.0/libstdc++-manual-html.tar.gz";>an
> - HTML tarball)
> -https://gcc.gnu.org/onlinedocs/gcc-9.5.0/libstdc++/api/";>GCC
> - 9.5 Standard C++ Library Reference Manual  ( - 
> href="https://gcc.gnu.org/onlinedocs/gcc-9.5.0/libstdc++-api.pdf.gz";>also
> - in PDF or  - 
> href="https://gcc.gnu.org/onlinedocs/gcc-9.5.0/libstdc++-api.xml.gz";>XML 
> GPL or
> -  - 
> href="https://gcc.gnu.org/onlinedocs/gcc-9.5.0/libstdc++-api-gfdl.xml.gz";>XML 
> GFDL or  - 
> href="https://gcc.gnu.org/onlinedocs/gcc-9.5.0/libstdc++-api-html.tar.gz";>an
> - HTML tarball)
> -https://gcc.gnu.org/onlinedocs/gcc-9.5.0/gccgo/";>GCCGO 9.5 
> Manual ( -   href="https://gcc.gnu.org/onlinedocs/gcc-9.5.0/gccgo.pdf";>also in
> -   PDF or  -   
> href="https://gcc.gnu.org/onlinedocs/gcc-9.5.0/gccgo.ps.gz";>PostScript or 
>  -   
> href="https://gcc.gnu.org/onlinedocs/gcc-9.5.0/gccgo-html.tar.gz";>an
> -   HTML tarball)
> -https://gcc.gnu.org/onlinedocs/gcc-9.5.0/libgomp/";>GCC 9.5
> - GNU Offloading and Multi Processing Runtime Library Manual ( - href="https://gcc.gnu.org/onlinedocs/gcc-9.5.0/libgomp.pdf";>also in
> -  

Re: [RFC] docs: remove documentation for unsupported releases

[Michael Matz via Gcc-patches]

Hello,

On Wed, 9 Nov 2022, Martin Liška wrote:

> I think we should remove documentation for unsupported GCC releases
> as it's indexed by Google engine. Second reason is that the page is long
> one one can't easily jump to Current development documentation.
> 
> Thoughts?

I think everything that's on the web server (even the 2.95 docu) has to be 
reachable via a (reasonable) set of clicks from the main index.html.  It 
doesn't need to be _directly_ from the main index.html, though.

Also, you simply might want to move the "Current Development" section 
to the front if it's currently too cumbersome to reach.

(E.g. one could move the index of the obsolete versions to a different web 
page, make that one un-indexable by google, but leave a trace to that one 
from the main index.html).


Ciao,
Michael.


> Martin
> 
> ---
>  htdocs/onlinedocs/index.html | 1294 --
>  1 file changed, 1294 deletions(-)
> 
> diff --git a/htdocs/onlinedocs/index.html b/htdocs/onlinedocs/index.html
> index cfa8bf5a..138dde95 100644
> --- a/htdocs/onlinedocs/index.html
> +++ b/htdocs/onlinedocs/index.html
> @@ -255,1300 +255,6 @@
>   href="https://gcc.gnu.org/onlinedocs/gcc-10.4.0/docs-sources.tar.gz";>Texinfo
>   sources of all the GCC 10.4 manuals
>
> -
> -  GCC 9.5 manuals:
> -  
> -https://gcc.gnu.org/onlinedocs/gcc-9.5.0/gcc/";>GCC
> - 9.5 Manual ( - href="https://gcc.gnu.org/onlinedocs/gcc-9.5.0/gcc.pdf";>also
> - in PDF or  - 
> href="https://gcc.gnu.org/onlinedocs/gcc-9.5.0/gcc.ps.gz";>PostScript or  - href="https://gcc.gnu.org/onlinedocs/gcc-9.5.0/gcc-html.tar.gz";>an
> - HTML tarball)
> -https://gcc.gnu.org/onlinedocs/gcc-9.5.0/gfortran/";>GCC
> - 9.5 GNU Fortran Manual ( - href="https://gcc.gnu.org/onlinedocs/gcc-9.5.0/gfortran.pdf";>also
> - in PDF or  - 
> href="https://gcc.gnu.org/onlinedocs/gcc-9.5.0/gfortran.ps.gz";>PostScript 
> or  - 
> href="https://gcc.gnu.org/onlinedocs/gcc-9.5.0/gfortran-html.tar.gz";>an
> - HTML tarball)
> -https://gcc.gnu.org/onlinedocs/gcc-9.5.0/cpp/";>GCC
> - 9.5 CPP Manual ( - href="https://gcc.gnu.org/onlinedocs/gcc-9.5.0/cpp.pdf";>also
> - in PDF or  - 
> href="https://gcc.gnu.org/onlinedocs/gcc-9.5.0/cpp.ps.gz";>PostScript or  - href="https://gcc.gnu.org/onlinedocs/gcc-9.5.0/cpp-html.tar.gz";>an
> - HTML tarball)
> -https://gcc.gnu.org/onlinedocs/gcc-9.5.0/gnat_rm/";>GCC
> - 9.5 GNAT Reference Manual ( - href="https://gcc.gnu.org/onlinedocs/gcc-9.5.0/gnat_rm.pdf";>also
> - in PDF or  - 
> href="https://gcc.gnu.org/onlinedocs/gcc-9.5.0/gnat_rm.ps.gz";>PostScript 
> or  - 
> href="https://gcc.gnu.org/onlinedocs/gcc-9.5.0/gnat_rm-html.tar.gz";>an
> - HTML tarball)
> -https://gcc.gnu.org/onlinedocs/gcc-9.5.0/gnat_ugn/";>GCC
> - 9.5 GNAT User's Guide ( - href="https://gcc.gnu.org/onlinedocs/gcc-9.5.0/gnat_ugn.pdf";>also
> - in PDF or  - 
> href="https://gcc.gnu.org/onlinedocs/gcc-9.5.0/gnat_ugn.ps.gz";>PostScript 
> or  - 
> href="https://gcc.gnu.org/onlinedocs/gcc-9.5.0/gnat_ugn-html.tar.gz";>an
> - HTML tarball)
> - href="https://gcc.gnu.org/onlinedocs/gcc-9.5.0/libstdc++/manual/";>GCC
> - 9.5 Standard C++ Library Manual  ( - 
> href="https://gcc.gnu.org/onlinedocs/gcc-9.5.0/libstdc++-manual.pdf.gz";>also
> - in PDF or  - 
> href="https://gcc.gnu.org/onlinedocs/gcc-9.5.0/libstdc++-manual.xml.gz";>XML
>  or  - 
> href="https://gcc.gnu.org/onlinedocs/gcc-9.5.0/libstdc++-manual-html.tar.gz";>an
> - HTML tarball)
> -https://gcc.gnu.org/onlinedocs/gcc-9.5.0/libstdc++/api/";>GCC
> - 9.5 Standard C++ Library Reference Manual  ( - 
> href="https://gcc.gnu.org/onlinedocs/gcc-9.5.0/libstdc++-api.pdf.gz";>also
> - in PDF or  - 
> href="https://gcc.gnu.org/onlinedocs/gcc-9.5.0/libstdc++-api.xml.gz";>XML 
> GPL or
> -  - 
> href="https://gcc.gnu.org/onlinedocs/gcc-9.5.0/libstdc++-api-gfdl.xml.gz";>XML 
> GFDL or  - 
> href="https://gcc.gnu.org/onlinedocs/gcc-9.5.0/libstdc++-api-html.tar.gz";>an
> - HTML tarball)
> -https://gcc.gnu.org/onlinedocs/gcc-9.5.0/gccgo/";>GCCGO 9.5 
> Manual ( -   href="https://gcc.gnu.org/onlinedocs/gcc-9.5.0/gccgo.pdf";>also in
> -   PDF or  -   
> href="https://gcc.gnu.org/onlinedocs/gcc-9.5.0/gccgo.ps.gz";>PostScript or 
>  -   
> href="https://gcc.gnu.org/onlinedocs/gcc-9.5.0/gccgo-html.tar.gz";>an
> -   HTML tarball)
> -https://gcc.gnu.org/onlinedocs/gcc-9.5.0/libgomp/";>GCC 9.5
> - GNU Offloading and Multi Processing Runtime Library Manual ( - href="https://gcc.gnu.org/onlinedocs/gcc-9.5.0/libgomp.pdf";>also in
> - PDF or  - 
> href="https://gcc.gnu.org/onlinedocs/gcc-9.5.0/li

Re: [COMMITTED] [range-op-float] Abstract out binary operator code out of PLUS_EXPR entry.

[Jakub Jelinek via Gcc-patches]

On Wed, Nov 09, 2022 at 02:32:55PM +0100, Jakub Jelinek wrote:
> On Wed, Nov 09, 2022 at 02:14:19PM +0100, Aldy Hernandez wrote:
> > On Wed, Nov 9, 2022 at 1:48 PM Jakub Jelinek  wrote:
> > >
> > > On Wed, Nov 09, 2022 at 08:07:57AM +0100, Aldy Hernandez wrote:
> > > > The PLUS_EXPR was always meant to be a template for further
> > > > development, since most of the binary operators will share a similar
> > > > structure.  This patch abstracts out the common bits into the default
> > > > definition for range_operator_float::fold_range() and provides an
> > > > rv_fold() to be implemented by the individual entries wishing to use
> > > > the generic folder.  This is akin to what we do with fold_range() and
> > > > wi_fold() in the integer version of range-ops.
> > >
> > > Shouldn't foperator_mult be very similar to this (except that until
> > > division is done op[12]_range can't be implemented), with the exception
> > > that the invalid case isn't -INF + INF or INF + -INF, but
> > > 0 * +/-INF or +/-INF * 0?
> > 
> > Multiplication and division are tricky because you have to keep track
> > of signs to order the resulting range.  It's the most annoying pattern
> > we have for integers:
> 
> Ah, you're right.
> Reminds me of check_for_binary_op_overflow for multiplication.

On the other side, thinking more about it, it should be easier than
integral, because we don't need to deal with unsigned/wrap around and
overflows aren't undefined, but infinities (though I guess we still have
even for +/- the question how actually say PDP floats or ARM non-IEEE
mode __fp16 behave on overflows for floats that don't support infinities,
if it is saturating on HUGE_VAL*/-HUGE_VAL* or wraps around).
So just do the cross products, sort them to create the final range,
clear_nans on it and provide nans the normal way?

Jakub

[GCC][PATCH 13/15, v4] arm: Add support for dwarf debug directives and pseudo hard-register for PAC feature.

[Srinath Parvathaneni via Gcc-patches]

Hello,

This patch teaches the DWARF support in gcc about RA_AUTH_CODE pseudo 
hard-register and also 
updates the ".save", ".cfi_register", ".cfi_offset", ".cfi_restore" directives 
accordingly.
This patch also adds support to emit ".pacspval" directive when "pac ip, lr, 
sp" instruction
in generated in the assembly.

RA_AUTH_CODE register number is 107 and it's dwarf register number is 143.

Applying this patch on top of PACBTI series posted here
https://gcc.gnu.org/pipermail/gcc-patches/2022-August/599658.html and when 
compiling the following
test.c with "-march=armv8.1-m.main+mve+pacbti -mbranch-protection=pac-ret 
-mthumb -mfloat-abi=hard
fasynchronous-unwind-tables -g -O0 -S" command line options, the assembly 
output after this patch
looks like below:

$cat test.c

void fun1(int a);
void fun(int a,...)
{
  fun1(a);
}

int main()
{
  fun (10);
  return 0;
}

$ arm-none-eabi-gcc -march=armv8.1-m.main+mve+pacbti 
-mbranch-protection=pac-ret -mthumb -mfloat-abi=hard
-fasynchronous-unwind-tables -g -O0 -S test.s

Assembly output:
...
fun:
...
.pacspval
pac ip, lr, sp
.cfi_register 143, 12
push{r3, r7, ip, lr}
.save {r3, r7, ra_auth_code, lr}
...
.cfi_offset 143, -24
...
.cfi_restore 143
...
aut ip, lr, sp
bx  lr
...
main:
...
.pacspval
pac ip, lr, sp
.cfi_register 143, 12
push{r3, r7, ip, lr}
.save {r3, r7, ra_auth_code, lr}
...
.cfi_offset 143, -8
...
.cfi_restore 143
...
aut ip, lr, sp
bx  lr
...

Regression tested on arm-none-eabi target and found no regressions.

Ok for master?

Regards,
Srinath.

gcc/testsuite/ChangeLog:

2022-11-04  Srinath Parvathaneni  

* g++.target/arm/pac-1.C: New test.
* gcc.target/arm/pac-9.c: New test.


2022-11-04  Srinath Parvathaneni  

* config/arm/aout.h (ra_auth_code): Add entry in enum.
* config/arm/arm.cc (pac_emit): Declare new global boolean variable.
(emit_multi_reg_push): Add RA_AUTH_CODE register to
dwarf frame expression.
(arm_emit_multi_reg_pop): Restore RA_AUTH_CODE register.
(arm_expand_prologue): Update frame related infomration and reg notes
for pac/pacbit insn.
(arm_regno_class): Check for pac pseudo reigster.
(arm_dbx_register_number): Assign ra_auth_code register number in dwarf.
(arm_unwind_emit_sequence): Print .save directive with ra_auth_code
register.
(arm_unwind_emit_set): Add entry for IP_REGNUM in switch case.
(arm_unwind_emit): Update REG_CFA_REGISTER case._
(arm_conditional_register_usage): Mark ra_auth_code in fixed reigsters.
* config/arm/arm.h (FIRST_PSEUDO_REGISTER): Modify.
(IS_PAC_PSEUDO_REGNUM): Define.
(enum reg_class): Add PAC_REG entry.
* config/arm/arm.md (RA_AUTH_CODE): Define.

gcc/testsuite/ChangeLog:

2022-11-04  Srinath Parvathaneni  

* g++.target/arm/pac-1.C: New test.
* gcc.target/arm/pac-9.c: Likewise.


### Attachment also inlined for ease of reply###


diff --git a/gcc/config/arm/aout.h b/gcc/config/arm/aout.h
index 
b918ad3782fbee82320febb8b6e72ad615780261..ffeed45a678f17c63d5b42c21f020ca416cbf23f
 100644
--- a/gcc/config/arm/aout.h
+++ b/gcc/config/arm/aout.h
@@ -74,7 +74,8 @@
   "wr8",   "wr9",   "wr10",  "wr11",   \
   "wr12",  "wr13",  "wr14",  "wr15",   \
   "wcgr0", "wcgr1", "wcgr2", "wcgr3",  \
-  "cc", "vfpcc", "sfp", "afp", "apsrq", "apsrge", "p0" \
+  "cc", "vfpcc", "sfp", "afp", "apsrq", "apsrge", "p0",\
+  "ra_auth_code"   \
 }
 #endif
 
diff --git a/gcc/config/arm/arm.h b/gcc/config/arm/arm.h
index 
a2dc3fc145c52d8381c54634687376089a47e704..91c400f12568156ed29bf5d5e59460bf887fbefb
 100644
--- a/gcc/config/arm/arm.h
+++ b/gcc/config/arm/arm.h
@@ -820,7 +820,8 @@ extern const int arm_arch_cde_coproc_bits[];
s16-s31   S VFP variable (aka d8-d15).
vfpcc   Not a real register.  Represents the VFP condition
code flags.
-   vpr Used to represent MVE VPR predication.  */
+   vpr Used to represent MVE VPR predication.
+   ra_auth_codePseudo register to save PAC.  */
 
 /* The stack backtrace structure is as follows:
   fp points to here:  |  save code pointer  |  [fp]
@@ -861,7 +862,7 @@ extern const int arm_arch_cde_coproc_bits[];
   1,1,1,1,1,1,1,1, \
   1,1,1,1, \
   /* Specials.  */ \
-  1,1,1,1,1,1,1\
+  1,1,1,1,1,1,1,1  \
 }
 
 /* 1 for registers not available across function calls.
@@ -891,7 +892,7 @@ extern const int arm_arch_cde_coproc_bits[];
   1,1,1,1,1,1,1,1, \
   1,1,1,1, \
   /* Spe

[PATCH (pushed)] docs: fix links pointing to gcc.gnu.org/install

[Martin Liška]

Use https://gcc.gnu.org/onlinedocs/install/ instead.

ChangeLog:

* configure.ac: Use new install URL.
* configure: Regenerate.

gcc/ChangeLog:

* Makefile.in: Use new install URL.
* doc/gcc/gcc-command-options/machine-dependent-options/avr-options.rst:
Use intersphinx link.
* 
doc/gcc/gcc-command-options/options-to-control-diagnostic-messages-formatting.rst:
Use new URL.
* doc/gccint/source-tree-structure-and-build-system.rst: Use
intersphinx link.
* doc/install/host-target-specific-installation-notes-for-gcc.rst: 
Likewise.
* doc/install/installing-gcc.rst: Likewise.
---
 configure   | 2 +-
 configure.ac| 2 +-
 gcc/Makefile.in | 2 +-
 .../machine-dependent-options/avr-options.rst   | 3 +--
 .../options-to-control-diagnostic-messages-formatting.rst   | 2 +-
 gcc/doc/gccint/source-tree-structure-and-build-system.rst   | 2 +-
 .../host-target-specific-installation-notes-for-gcc.rst | 6 +++---
 gcc/doc/install/installing-gcc.rst  | 2 +-
 8 files changed, 10 insertions(+), 11 deletions(-)

diff --git a/configure b/configure
index 7b1238877f5..c13b24055b3 100755
--- a/configure
+++ b/configure
@@ -8239,7 +8239,7 @@ Try the --with-gmp, --with-mpfr and/or --with-mpc options 
to specify
 their locations.  Source code for these libraries can be found at
 their respective hosting sites as well as at
 https://gcc.gnu.org/pub/gcc/infrastructure/.  See also
-http://gcc.gnu.org/install/prerequisites.html for additional info.  If
+https://gcc.gnu.org/onlinedocs/install/prerequisites.html for additional info. 
 If
 you obtained GMP, MPFR and/or MPC from a vendor distribution package,
 make sure that you have installed both the libraries and the header
 files.  They may be located in separate packages." "$LINENO" 5
diff --git a/configure.ac b/configure.ac
index 60f408683ff..8f3a4f38e30 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1680,7 +1680,7 @@ Try the --with-gmp, --with-mpfr and/or --with-mpc options 
to specify
 their locations.  Source code for these libraries can be found at
 their respective hosting sites as well as at
 https://gcc.gnu.org/pub/gcc/infrastructure/.  See also
-http://gcc.gnu.org/install/prerequisites.html for additional info.  If
+https://gcc.gnu.org/onlinedocs/install/prerequisites.html for additional info. 
 If
 you obtained GMP, MPFR and/or MPC from a vendor distribution package,
 make sure that you have installed both the libraries and the header
 files.  They may be located in separate packages.])
diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index 059606c37d5..4982012f5b2 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -2035,7 +2035,7 @@ cstamp-h: config.in config.status
 # config.status does not exist before failing.
 config.status: $(srcdir)/configure $(srcdir)/config.gcc $(LANG_CONFIGUREFRAGS)
@if [ ! -f config.status ] ; then \
- echo You must configure gcc.  Look at http://gcc.gnu.org/install/ for 
details.; \
+ echo You must configure gcc.  Look at 
http://gcc.gnu.org/onlinedocs/install/ for details.; \
  false; \
else \
  LANGUAGES="$(CONFIG_LANGUAGES)" $(SHELL) config.status --recheck; \
diff --git 
a/gcc/doc/gcc/gcc-command-options/machine-dependent-options/avr-options.rst 
b/gcc/doc/gcc/gcc-command-options/machine-dependent-options/avr-options.rst
index b8157b2f58c..5b2dc4bf741 100644
--- a/gcc/doc/gcc/gcc-command-options/machine-dependent-options/avr-options.rst
+++ b/gcc/doc/gcc/gcc-command-options/machine-dependent-options/avr-options.rst
@@ -62,8 +62,7 @@ GCC supports the following AVR devices and ISAs:
   Set the size (in bits) of the ``double`` or ``long double`` type,
   respectively.  Possible values for :samp:`{bits}` are 32 and 64.
   Whether or not a specific value for :samp:`{bits}` is allowed depends on
-  the ``--with-double=`` and ``--with-long-double=``
-  `configure options `_,
+  the :option:`install:--with-double=`` and ``--with-long-double=``,
   and the same applies for the default values of the options.
 
 .. option:: -mgas-isr-prologues
diff --git 
a/gcc/doc/gcc/gcc-command-options/options-to-control-diagnostic-messages-formatting.rst
 
b/gcc/doc/gcc/gcc-command-options/options-to-control-diagnostic-messages-formatting.rst
index 6e40ab26e97..20a14a1808a 100644
--- 
a/gcc/doc/gcc/gcc-command-options/options-to-control-diagnostic-messages-formatting.rst
+++ 
b/gcc/doc/gcc/gcc-command-options/options-to-control-diagnostic-messages-formatting.rst
@@ -687,7 +687,7 @@ honor these options.
 ],
 "message": "this ‘if’ clause does not guard...",
 "option": "-Wmisleading-indentation",
-"option_url": 
"https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#

Re: Announcement: Porting the Docs to Sphinx - 9. November 2022

[Martin Liška]

On 10/20/22 18:43, Joseph Myers wrote:
> On Thu, 20 Oct 2022, Martin Liška wrote:
> 
>>> Also, but not strictly part of the release issue:
>>>
>>> (d) Builds with missing or old Sphinx should work regardless of whether 
>>> such files are in the source directory - but if they aren't in the source 
>>> directory, the effect of missing or old Sphinx (detected at configure 
>>> time) should be to disable building and installing documentation.
>>
>> All right Joseph, is it something you're willing to help me once we start
>> using Sphinx? Apparently, there will be many consequent steps after we 
>> switch.
> 
> Sure, but most of the conditionals are *already* present, just need 
> updating as part of the Sphinx transition.  E.g. gcc/Makefile.in has 
> BUILD_INFO and GENERATED_MANPAGES conditionals based on configure tests 
> for whether relevant tools are present and new enough; the rules for 
> $(DESTDIR)$(infodir)/%.info quietly allow the info files not to be 
> present, so installing also works without the info files or tools to build 
> them, and the rules for installing man pages similarly ignore errors; and 
> there are srcinfo and srcman rules, enabled based on @GENINSRC@, to copy 
> those built files to the source directory, which are what's used when 
> --enable-generated-files-in-srcdir is used as part of building a release 
> tarball.
> 
> The main thing I've suggested that I think may actually be new is an error 
> for trying to build a release tarball without new-enough Sphinx (I think 
> the current rules would quietly not copy info / man pages to the source 
> directory if build tools were missing - but having those tools missing 
> when building a release tarball is much less likely than not having 
> new-enough Sphinx).
> 

Hello Joseph.

So the transition is done and I would to ask you Joseph for help with the
following 2 items:

1) not synchronized content among lib*/Makefile.in and lib*/Makefile.am.
Apparently, I modified the generated Makefile.in file with the rules like:

doc/info/texinfo/libitm.info: $(SPHINX_FILES)
+ if [ x$(HAS_SPHINX_BUILD) = xhas-sphinx-build ]; then \
  make -C $(srcdir)/../doc info SOURCEDIR=$(abs_srcdir)/doc 
BUILDDIR=$(abs_doc_builddir)/info SPHINXBUILD=$(SPHINX_BUILD); \
else true; fi

Can you please modify Makefile.am in the corresponding manner and re-generate 
Makefile.in?

2) Adding proper support --enable-generated-files-in-srcdir in gcc_release:

As mentioned above in the quoted email.

Thanks in advance,
Martin

Re: [COMMITTED] Implement op[12]_range operators for PLUS_EXPR and MINUS_EXPR.

[Jakub Jelinek via Gcc-patches]

On Wed, Nov 09, 2022 at 10:02:46AM +0100, Aldy Hernandez wrote:
> We can implement the op[12]_range entries for plus and minus in terms
> of each other.  These are adapted from the integer versions.

I think for NANs the op[12]_range shouldn't act this way.
For the forward binary operations, we have the (maybe/known) NAN handling
of one or both NAN operands resulting in VARYING sign (maybe/known) NAN
result, that is the somehow the case for the reverse binary operations too,
if result is (maybe/known) NAN and the other op is not NAN, op is
VARYING sign (maybe/known) NAN, if other op is (maybe/known) NAN,
then op is VARYING sign maybe NAN (always maybe, never known).
But then for + we have the -INF + INF or vice versa into NAN, and that
is something that shouldn't be considered.  If result isn't NAN, then
neither operand can be NAN, regardless of whether result can be
+/- INF and the other op -/+ INF.

Jakub

[wwwdocs] Add httpd redirects for texinfo trunk docs and for each release series

[Jonathan Wakely via Gcc-patches]

I've tested that the redirects work on my own httpd server, and have
verified that no new sphinx-generated docs match these patterns, and no
old texinfo docs fail to match them (except for cases like index.html
where a new file exists with the same name anyway so we don't need a
redirect).

For example, on gcc.gnu.org:

cd htdocs/onlinedocs/gcc-12.2.0

# All "missing" URLs are matched by these patterns:

for i in {gcc,cpp}/*.html ; do test -f ../$i || echo $i ; done | grep -E -v 
'^(gcc|cpp)/([[:upper:]].*|_00(5f|40).*|aarch64-feature-modifiers|c99-like-fast-enumeration-syntax|compatibility_005f.*|dashMF|eBPF-Options|fdollars-in-identifiers|lto-dump-Intro|(m68k|msp430|picoChip|x86|zSeries).*|trigraphs).*\.html$'

for i in gccint/*.html ; do test -f ../$i || echo $i ; done | grep -E -v 
'^gccint/([[:upper:]].*|(arm|define|input|poly|stack|window)_005f.*|compat-Testing|(epi|pro)logue-instruction-pattern|gcc-Directory|gcov-Testing|loop-iv|profopt-Testing|real-RTL-SSA-insns|shift-patterns|wi-arith.*)\.html$'

for i in cppinternals/*.html ; do test -f ../$i || echo $i ; done | grep -E -v 
'^cppinternals/([[:upper:]].*)\.html$'


# No still-valid URLs are matched:

for i in {gcc,cpp}/*.html ; do test -f ../$i && echo $i ; done | grep -E 
'^(gcc|cpp)/([[:upper:]].*|_00(5f|40).*|aarch64-feature-modifiers|c99-like-fast-enumeration-syntax|compatibility_005f.*|dashMF|eBPF-Options|fdollars-in-identifiers|lto-dump-Intro|(m68k|msp430|picoChip|x86|zSeries).*|trigraphs).*\.html$'

for i in gccint/*.html ; do test -f ../$i && echo $i ; done | grep -E 
'^gccint/([[:upper:]].*|(arm|define|input|poly|stack|window)_005f.*|compat-Testing|(epi|pro)logue-instruction-pattern|gcc-Directory|gcov-Testing|loop-iv|profopt-Testing|real-RTL-SSA-insns|shift-patterns|wi-arith.*)\.html$'

for i in  cppinternals/*.html ; do test -f ../$i && echo $i ; done | grep -E 
'^cppinternals/([[:upper:]].*)\.html$'


I haven't added redirects for other sub-dirs such as gccgo, gfortran,
libgomp etc. so if somebody cares about those, they should deal with
them.

OK for wwwdocs?

-- >8 --

Add redirects from /onlinedocs/gcc-X to the latest gcc-X.Y.0 release
(which will need to be updated when a release is made).

Also add redirects from URLs for old trunk docs such as
https://gcc.gnu.org/onlinedocs/cpp/Variadic-Macros.html
to the gcc-12 equivalent of that page.
---
 htdocs/.htaccess | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/htdocs/.htaccess b/htdocs/.htaccess
index 18997d63..bf7124ea 100644
--- a/htdocs/.htaccess
+++ b/htdocs/.htaccess
@@ -79,3 +79,17 @@ Redirect   /onlinedocs/libc  
https://www.gnu.org/software/libc/manual/ht
 Redirect   /onlinedocs/standards   
https://www.gnu.org/prep/standards/html_node/
 
 Redirect   /onlinedocs/ref 
https://gcc.gnu.org/onlinedocs/gcc-4.3.2/
+
+Redirect   /onlinedocs/gcc-5/   
https://gcc.gnu.org/onlinedocs/gcc-5.5.0/
+Redirect   /onlinedocs/gcc-6/   
https://gcc.gnu.org/onlinedocs/gcc-6.5.0/
+Redirect   /onlinedocs/gcc-7/   
https://gcc.gnu.org/onlinedocs/gcc-7.5.0/
+Redirect   /onlinedocs/gcc-8/   
https://gcc.gnu.org/onlinedocs/gcc-8.5.0/
+Redirect   /onlinedocs/gcc-9/   
https://gcc.gnu.org/onlinedocs/gcc-9.5.0/
+Redirect   /onlinedocs/gcc-10/  
https://gcc.gnu.org/onlinedocs/gcc-10.4.0/
+Redirect   /onlinedocs/gcc-11/  
https://gcc.gnu.org/onlinedocs/gcc-11.3.0/
+Redirect   /onlinedocs/gcc-12/  
https://gcc.gnu.org/onlinedocs/gcc-12.2.0/
+
+# Redirect URLs for old texinfo trunk docs to gcc-12
+RedirectMatch permanent 
/onlinedocs/(gcc|cpp)/([[:upper:]].*|_00(5f|40).*|aarch64-feature-modifiers|c99-like-fast-enumeration-syntax|compatibility_005f.*|dashMF|eBPF-Options|fdollars-in-identifiers|lto-dump-Intro|(m68k|msp430|picoChip|x86|zSeries).*|trigraphs).*\.html$
 https://gcc.gnu.org/onlinedocs/gcc-12/$1/$2.html
+RedirectMatch permanent 
/onlinedocs/gccint/([[:upper:]].*|(arm|define|input|poly|stack|window)_005f.*|compat-Testing|(epi|pro)logue-instruction-pattern|gcc-Directory|gcov-Testing|loop-iv|profopt-Testing|real-RTL-SSA-insns|shift-patterns|wi-arith.*)\.html$
 https://gcc.gnu.org/onlinedocs/gcc-12/gccint/$1.html
+RedirectMatch permanent /onlinedocs/cppinternals/([[:upper:]].*)\.html$ 
https://gcc.gnu.org/onlinedocs/gcc-12/gccint/$1.html
-- 
2.38.1

Re: [COMMITTED] Implement op[12]_range operators for PLUS_EXPR and MINUS_EXPR.

[Aldy Hernandez via Gcc-patches]

On Wed, Nov 9, 2022 at 3:58 PM Jakub Jelinek  wrote:
>
> On Wed, Nov 09, 2022 at 10:02:46AM +0100, Aldy Hernandez wrote:
> > We can implement the op[12]_range entries for plus and minus in terms
> > of each other.  These are adapted from the integer versions.
>
> I think for NANs the op[12]_range shouldn't act this way.
> For the forward binary operations, we have the (maybe/known) NAN handling
> of one or both NAN operands resulting in VARYING sign (maybe/known) NAN
> result, that is the somehow the case for the reverse binary operations too,
> if result is (maybe/known) NAN and the other op is not NAN, op is
> VARYING sign (maybe/known) NAN, if other op is (maybe/known) NAN,
> then op is VARYING sign maybe NAN (always maybe, never known).
> But then for + we have the -INF + INF or vice versa into NAN, and that
> is something that shouldn't be considered.  If result isn't NAN, then
> neither operand can be NAN, regardless of whether result can be
> +/- INF and the other op -/+ INF.

Heh.  I just ran into this while debugging the problem reported by Xi.

We are solving NAN = op1 - VARYING, and trying to do it with op1 = NAN
+ VARYING, which returns op1 = NAN (incorrectly).

I suppose in the above case op1 should ideally be
[-INF,-INF][+INF,+INF]+-NAN, but since we can't represent that then
[-INF,+INF] +-NAN, which is actually VARYING.  Do you agree?

I'm reverting this patch as attached, while I sort this out.

Thanks.
Aldy
From f8ac2b15d1ce8cbb2f4a4ba89afbd87a8aa5c4e6 Mon Sep 17 00:00:00 2001
From: Aldy Hernandez 
Date: Wed, 9 Nov 2022 16:35:40 +0100
Subject: [PATCH] Revert op[12]_range operators for PLUS_EXPR and MINUS_EXPR.

Revert the patch below until issues are resolved:

	commit 4287e8168f89e90b3dff3a50f3ada40be53e0e01
	Author: Aldy Hernandez 
	Date:   Wed Nov 9 01:00:57 2022 +0100

	Implement op[12]_range operators for PLUS_EXPR and MINUS_EXPR.

	We can implement the op[12]_range entries for plus and minus in terms
	of each other.  These are adapted from the integer versions.

gcc/ChangeLog:

	* range-op-float.cc (class foperator_plus): Remove op[12]_range.
	(class foperator_minus): Same.
---
 gcc/range-op-float.cc | 45 ---
 1 file changed, 45 deletions(-)

diff --git a/gcc/range-op-float.cc b/gcc/range-op-float.cc
index cc806438a19..380142b4c14 100644
--- a/gcc/range-op-float.cc
+++ b/gcc/range-op-float.cc
@@ -1863,29 +1863,6 @@ foperator_unordered_equal::op1_range (frange &r, tree type,
 
 class foperator_plus : public range_operator_float
 {
-  using range_operator_float::op1_range;
-  using range_operator_float::op2_range;
-public:
-  virtual bool op1_range (frange &r, tree type,
-			  const frange &lhs,
-			  const frange &op2,
-			  relation_trio = TRIO_VARYING) const final override
-  {
-if (lhs.undefined_p ())
-  return false;
-range_op_handler minus (MINUS_EXPR, type);
-if (!minus)
-  return false;
-return minus.fold_range (r, type, lhs, op2);
-  }
-  virtual bool op2_range (frange &r, tree type,
-			  const frange &lhs,
-			  const frange &op1,
-			  relation_trio = TRIO_VARYING) const final override
-  {
-return op1_range (r, type, lhs, op1);
-  }
-private:
   void rv_fold (REAL_VALUE_TYPE &lb, REAL_VALUE_TYPE &ub, bool &maybe_nan,
 		tree type,
 		const REAL_VALUE_TYPE &lh_lb,
@@ -1910,28 +1887,6 @@ private:
 
 class foperator_minus : public range_operator_float
 {
-  using range_operator_float::op1_range;
-  using range_operator_float::op2_range;
-public:
-  virtual bool op1_range (frange &r, tree type,
-			  const frange &lhs,
-			  const frange &op2,
-			  relation_trio = TRIO_VARYING) const final override
-  {
-if (lhs.undefined_p ())
-  return false;
-return fop_plus.fold_range (r, type, lhs, op2);
-  }
-  virtual bool op2_range (frange &r, tree type,
-			  const frange &lhs,
-			  const frange &op1,
-			  relation_trio = TRIO_VARYING) const final override
-  {
-if (lhs.undefined_p ())
-  return false;
-return fold_range (r, type, op1, lhs);
-  }
-private:
   void rv_fold (REAL_VALUE_TYPE &lb, REAL_VALUE_TYPE &ub, bool &maybe_nan,
 		tree type,
 		const REAL_VALUE_TYPE &lh_lb,
-- 
2.38.1

Re: [COMMITTED] [range-op-float] Implement MINUS_EXPR.

[Aldy Hernandez via Gcc-patches]

I have reverted the patch while I sort this out.

Thanks for the report and especially for the distilled test.  It's very useful.

Aldy

On Wed, Nov 9, 2022 at 2:58 PM Xi Ruoyao  wrote:
>
> On Wed, 2022-11-09 at 21:49 +0800, Xi Ruoyao wrote:
> > Hi Aldy,
> >
> > This commit breaks the attached test case at -O2 on x86_64-linux-gnu and
>   ^^^
>
> Ah, not this one.  I meant r13-3842 "Implement op[12]_range operators
> for PLUS_EXPR and MINUS_EXPR."
>
> > loongarch64-linux-gnu :(.
> >
> > The code is simplified from Glibc: the breakage causes two Glibc test
> > failures on loongarch64-linux-gnu.
> >
> > Reverting the commit can fix the breakage.
> ^^ also r13-3842.
>
> /* snip */
>
> > > The op[12]_range entries will be submitted as a follow-up.
>
> --
> Xi Ruoyao 
> School of Aerospace Science and Technology, Xidian University
>

Re: [COMMITTED] Implement op[12]_range operators for PLUS_EXPR and MINUS_EXPR.

[Jakub Jelinek via Gcc-patches]

On Wed, Nov 09, 2022 at 04:43:56PM +0100, Aldy Hernandez wrote:
> Heh.  I just ran into this while debugging the problem reported by Xi.
> 
> We are solving NAN = op1 - VARYING, and trying to do it with op1 = NAN
> + VARYING, which returns op1 = NAN (incorrectly).
> 
> I suppose in the above case op1 should ideally be
> [-INF,-INF][+INF,+INF]+-NAN, but since we can't represent that then
> [-INF,+INF] +-NAN, which is actually VARYING.  Do you agree?

Yes.
For implementation, perhaps just on the result of the reverse ops
of whatever you do there currently (right before returning)
call some function common to all binary ops that will handle
the reverse op handling of NANs I've described.
If lhs can't be NAN, then clear_nan on the result, if
lhs is known to be NAN and other op can't be NAN,
have result be known NAN (with VARYING sign),
otherwise set maybe +-NAN on the result.

Jakub

RE: [PATCH 2/4]AArch64 Add implementation for pow2 bitmask division.

[Kyrylo Tkachov via Gcc-patches]

Hi Tamar,

> -Original Message-
> From: Tamar Christina 
> Sent: Monday, October 31, 2022 11:35 AM
> To: Tamar Christina ; gcc-patches@gcc.gnu.org
> Cc: nd ; Richard Earnshaw ;
> Marcus Shawcroft ; Kyrylo Tkachov
> ; Richard Sandiford
> 
> Subject: RE: [PATCH 2/4]AArch64 Add implementation for pow2 bitmask
> division.
> 
> Hi All,
> 
> Ping, and updated patch based on mid-end changes.
> 
> Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
> 
> Ok for master?
> 
> Thanks,
> Tamar
> 
> gcc/ChangeLog:
> 
>   * config/aarch64/aarch64-simd.md
> (@aarch64_bitmask_udiv3): New.
>   * config/aarch64/aarch64.cc
> (aarch64_vectorize_can_special_div_by_constant): New.
> 
> gcc/testsuite/ChangeLog:
> 
>   * gcc.target/aarch64/div-by-bitmask.c: New test.
> 
> --- inline copy of patch ---
> 
> diff --git a/gcc/config/aarch64/aarch64-simd.md
> b/gcc/config/aarch64/aarch64-simd.md
> index
> 587a45d77721e1b39accbad7dbeca4d741eccb10..f4152160084d6b6f34bd69f
> 0ba6386c1ab50f77e 100644
> --- a/gcc/config/aarch64/aarch64-simd.md
> +++ b/gcc/config/aarch64/aarch64-simd.md
> @@ -4831,6 +4831,65 @@ (define_expand
> "aarch64_hn2"
>}
>  )

Some editorial comments.

> 
> +;; div optimizations using narrowings
> +;; we can do the division e.g. shorts by 255 faster by calculating it as
> +;; (x + ((x + 257) >> 8)) >> 8 assuming the operation is done in
> +;; double the precision of x.
> +;;
> +;; If we imagine a short as being composed of two blocks of bytes then
> +;; adding 257 or 0b_0001__0001 to the number is equivalen to

Typo "equivalent"

> +;; adding 1 to each sub component:
> +;;
> +;;  short value of 16-bits
> +;; ┌──┬┐
> +;; │  ││
> +;; └──┴┘
> +;;   8-bit part1 ▲  8-bit part2   ▲
> +;;   ││
> +;;   ││
> +;;  +1   +1
> +;;
> +;; after the first addition, we have to shift right by 8, and narrow the
> +;; results back to a byte.  Remember that the addition must be done in
> +;; double the precision of the input.  Since 8 is half the size of a short
> +;; we can use a narrowing halfing instruction in AArch64, addhn which also
> +;; does the addition in a wider precision and narrows back to a byte.  The
> +;; shift itself is implicit in the operation as it writes back only the top
> +;; half of the result. i.e. bits 2*esize-1:esize.
> +;;
> +;; Since we have narrowed the result of the first part back to a byte, for
> +;; the second addition we can use a widening addition, uaddw.
> +;;
> +;; For the finaly shift, since it's unsigned arithmatic we emit an ushr by 8

"final shift", "unsigned arithmetic"

> +;; to shift and the vectorizer.

Incomplete sentence?

> +;;
> +;; The shift is later optimized by combine to a uzp2 with movi #0.
> +(define_expand "@aarch64_bitmask_udiv3"
> +  [(match_operand:VQN 0 "register_operand")
> +   (match_operand:VQN 1 "register_operand")
> +   (match_operand:VQN 2 "immediate_operand")]
> +  "TARGET_SIMD"
> +{
> +  unsigned HOST_WIDE_INT size
> += (1ULL << GET_MODE_UNIT_BITSIZE (mode)) - 1;
> +  if (!CONST_VECTOR_P (operands[2])
> +  || const_vector_encoded_nelts (operands[2]) != 1
> +  || size != UINTVAL (CONST_VECTOR_ELT (operands[2], 0)))
> +FAIL;
> +
> +  rtx addend = gen_reg_rtx (mode);
> +  rtx val = aarch64_simd_gen_const_vector_dup (mode, 1);
> +  emit_move_insn (addend, lowpart_subreg (mode, val,
> mode));
> +  rtx tmp1 = gen_reg_rtx (mode);
> +  rtx tmp2 = gen_reg_rtx (mode);
> +  emit_insn (gen_aarch64_addhn (tmp1, operands[1], addend));
> +  unsigned bitsize = GET_MODE_UNIT_BITSIZE (mode);
> +  rtx shift_vector = aarch64_simd_gen_const_vector_dup (mode,
> bitsize);
> +  emit_insn (gen_aarch64_uaddw (tmp2, operands[1], tmp1));
> +  emit_insn (gen_aarch64_simd_lshr (operands[0], tmp2,
> shift_vector));
> +  DONE;
> +})

Does all this work for big-endian too? I think it does, but wonder whether 
you've tested.

Ok if so, with the comments addressed.
Thanks,
Kyrill

> +
>  ;; pmul.
> 
>  (define_insn "aarch64_pmul"
> diff --git a/gcc/config/aarch64/aarch64.cc b/gcc/config/aarch64/aarch64.cc
> index
> 4b486aeea90ea2afb9cdd96a4dbe15c5bb2abd7a..d3c3650d7d728f56adb651
> 54127dc7b72386c5a7 100644
> --- a/gcc/config/aarch64/aarch64.cc
> +++ b/gcc/config/aarch64/aarch64.cc
> @@ -24146,6 +24146,40 @@ aarch64_vectorize_vec_perm_const
> (machine_mode vmode, machine_mode op_mode,
>return ret;
>  }
> 
> +/* Implement TARGET_VECTORIZE_CAN_SPECIAL_DIV_BY_CONST.  */
> +
> +bool
> +aarch64_vectorize_can_special_div_by_constant (enum tree_code code,
> +tree vectype, wide_int cst,
> +rtx *output, rtx in0, rtx in1)
> +{
> +  if (code != TRUNC_DIV_EXPR
> +  || !TYPE_UNSIGNED (vectype))
> +return false;
> +
> +  unsigned int flags = aarch64_classify_vector_mode (TYPE_MODE
> (vectype));
> +

Re: [PATCH 1/2] Change the name of array_at_struct_end_p to array_ref_flexible_size_p

[Qing Zhao via Gcc-patches]

Thanks.

Committed as:  https://gcc.gnu.org/pipermail/gcc-cvs/2022-November/373830.html

Qing
> On Nov 9, 2022, at 2:57 AM, Richard Biener  wrote:
> 
> On Tue, 8 Nov 2022, Qing Zhao wrote:
> 
>> The name of the utility routine "array_at_struct_end_p" is misleading
>> and should be changed to a new name that more accurately reflects its
>> real meaning.
>> 
>> The routine "array_at_struct_end_p" is used to check whether an array
>> reference is to an array whose actual size might be larger than its
>> upper bound implies, which includes 3 different cases:
>> 
>>   A. a ref to a flexible array member at the end of a structure;
>>   B. a ref to an array with a different type against the original decl;
>>   C. a ref to an array that was passed as a parameter;
>> 
>> The old name only reflects the above case A, therefore very confusing
>> when reading the corresponding gcc source code.
>> 
>> In this patch, A new name "array_ref_flexible_size_p" is used to replace
>> the old name.
>> 
>> All the references to the routine "array_at_struct_end_p" was replaced
>> with this new name, and the corresponding comments were updated to make
>> them clean and consistent.
> 
> Since you seem to feel strongly about this - OK.
> 
> Thanks,
> Richard.
> 
>> gcc/ChangeLog:
>> 
>>  * gimple-array-bounds.cc (trailing_array): Replace
>>  array_at_struct_end_p with new name and update comments.
>>  * gimple-fold.cc (get_range_strlen_tree): Likewise.
>>  * gimple-ssa-warn-restrict.cc (builtin_memref::builtin_memref):
>>  Likewise.
>>  * graphite-sese-to-poly.cc (bounds_are_valid): Likewise.
>>  * tree-if-conv.cc (idx_within_array_bound): Likewise.
>>  * tree-object-size.cc (addr_object_size): Likewise.
>>  * tree-ssa-alias.cc (component_ref_to_zero_sized_trailing_array_p):
>>  Likewise.
>>  (stmt_kills_ref_p): Likewise.
>>  * tree-ssa-loop-niter.cc (idx_infer_loop_bounds): Likewise.
>>  * tree-ssa-strlen.cc (maybe_set_strlen_range): Likewise.
>>  * tree.cc (array_at_struct_end_p): Rename to ...
>>  (array_ref_flexible_size_p): ... this.
>>  (component_ref_size): Replace array_at_struct_end_p with new name.
>>  * tree.h (array_at_struct_end_p): Rename to ...
>>  (array_ref_flexible_size_p): ... this.
>> ---
>> gcc/gimple-array-bounds.cc  |  4 ++--
>> gcc/gimple-fold.cc  |  6 ++
>> gcc/gimple-ssa-warn-restrict.cc |  5 +++--
>> gcc/graphite-sese-to-poly.cc|  4 ++--
>> gcc/tree-if-conv.cc |  7 +++
>> gcc/tree-object-size.cc |  2 +-
>> gcc/tree-ssa-alias.cc   |  8 
>> gcc/tree-ssa-loop-niter.cc  | 15 +++
>> gcc/tree-ssa-strlen.cc  |  2 +-
>> gcc/tree.cc | 11 ++-
>> gcc/tree.h  |  8 
>> 11 files changed, 35 insertions(+), 37 deletions(-)
>> 
>> diff --git a/gcc/gimple-array-bounds.cc b/gcc/gimple-array-bounds.cc
>> index e190b93aa85..fbf448e045d 100644
>> --- a/gcc/gimple-array-bounds.cc
>> +++ b/gcc/gimple-array-bounds.cc
>> @@ -129,7 +129,7 @@ get_ref_size (tree arg, tree *pref)
>> }
>> 
>> /* Return true if REF is (likely) an ARRAY_REF to a trailing array member
>> -   of a struct.  It refines array_at_struct_end_p by detecting a pointer
>> +   of a struct.  It refines array_ref_flexible_size_p by detecting a pointer
>>to an array and an array parameter declared using the [N] syntax (as
>>opposed to a pointer) and returning false.  Set *PREF to the decl or
>>expression REF refers to.  */
>> @@ -167,7 +167,7 @@ trailing_array (tree arg, tree *pref)
>>  return false;
>> }
>> 
>> -  return array_at_struct_end_p (arg);
>> +  return array_ref_flexible_size_p (arg);
>> }
>> 
>> /* Checks one ARRAY_REF in REF, located at LOCUS. Ignores flexible
>> diff --git a/gcc/gimple-fold.cc b/gcc/gimple-fold.cc
>> index 9055cd8982d..cafd331ca98 100644
>> --- a/gcc/gimple-fold.cc
>> +++ b/gcc/gimple-fold.cc
>> @@ -1690,13 +1690,11 @@ get_range_strlen_tree (tree arg, bitmap visited, 
>> strlen_range_kind rkind,
>>/* Handle a MEM_REF into a DECL accessing an array of integers,
>>   being conservative about references to extern structures with
>>   flexible array members that can be initialized to arbitrary
>> - numbers of elements as an extension (static structs are okay).
>> - FIXME: Make this less conservative -- see
>> - component_ref_size in tree.cc.  */
>> + numbers of elements as an extension (static structs are okay).  */
>>tree ref = TREE_OPERAND (TREE_OPERAND (arg, 0), 0);
>>if ((TREE_CODE (ref) == PARM_DECL || VAR_P (ref))
>>&& (decl_binds_to_current_def_p (ref)
>> -  || !array_at_struct_end_p (arg)))
>> +  || !array_ref_flexible_size_p (arg)))
>>  {
>>/* Fail if the offset is out of bounds.  Such accesses
>>   should be diagnosed at some point.  */
>> diff --git a/gcc/gimple-s

Re: Announcement: Porting the Docs to Sphinx - tomorrow

[Joseph Myers]

On Wed, 9 Nov 2022, Richard Biener via Gcc wrote:

> I'd say that doing a trunk snapshot build every day as CI would be nice, we
> can then publish one once a week, skipping days where the build failed.

Note that each snapshot should have diffs relative to the previous 
published snapshot.  Not relative to some other one that was not 
published, for example.

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

Re: Announcement: Porting the Docs to Sphinx - 9. November 2022

[Joseph Myers]

On Wed, 9 Nov 2022, Martin Liška wrote:

> 1) not synchronized content among lib*/Makefile.in and lib*/Makefile.am.
> Apparently, I modified the generated Makefile.in file with the rules like:
> 
> doc/info/texinfo/libitm.info: $(SPHINX_FILES)
>   + if [ x$(HAS_SPHINX_BUILD) = xhas-sphinx-build ]; then \
> make -C $(srcdir)/../doc info SOURCEDIR=$(abs_srcdir)/doc 
> BUILDDIR=$(abs_doc_builddir)/info SPHINXBUILD=$(SPHINX_BUILD); \
>   else true; fi
> 
> Can you please modify Makefile.am in the corresponding manner and re-generate 
> Makefile.in?

I think someone else had best look at this.

> 2) Adding proper support --enable-generated-files-in-srcdir in gcc_release:

It looks like all the GENINSRC rules / conditionals are still present.  
So maybe there are details where the paths are wrong, or where fixes are 
needed to ensure the files get installed from the source directory when 
available in the source directory but not available in the build directory 
because Sphinx isn't available, but much of the code for the feature is 
still there.

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

Re: Announcement: Porting the Docs to Sphinx - tomorrow

[Richard Biener via Gcc-patches]

On Wed, Nov 9, 2022 at 6:11 PM Joseph Myers  wrote:
>
> On Wed, 9 Nov 2022, Richard Biener via Gcc wrote:
>
> > I'd say that doing a trunk snapshot build every day as CI would be nice, we
> > can then publish one once a week, skipping days where the build failed.
>
> Note that each snapshot should have diffs relative to the previous
> published snapshot.  Not relative to some other one that was not
> published, for example.

Sure, but diffs can be created from the two snapshot tarballs at
publishing time.

Richard.

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

Re: [PATCH] riscv: implement TARGET_MODE_REP_EXTENDED

[Alexander Monakov via Gcc-patches]

On Wed, 9 Nov 2022, Philipp Tomsich wrote:

> > To give a specific example that will be problematic if you go far enough 
> > down
> > the road of matching MIPS64 behavior:
> >
> > long f(void)
> > {
> > int x;
> > asm("" : "=r"(x));
> > return x;
> > }
> >
> > here GCC (unlike LLVM) omits sign extension of 'x', assuming that asm output
> > must have been sign-extended to 64 bits by the programmer.
> 
> In fact, with the proposed patch (but also without it), GCC will sign-extend:
> f:
>   sext.w a0,a0
>   ret
>   .size f, .-f

I'm aware. I said "will be problematic if ...", meaning that GCC omits sign
extension when targeting MIPS64, and if you match MIPS64 behavior on RISC-V, 
you'll get in that situation as well.

> To make sure that this is not just an extension to promote the int to
> long for the function return, I next added another empty asm to
> consume 'x'.
> This clearly shows that the extension is performed to postprocess the
> output of the asm-statement:
> 
> f:
>   # ./asm2.c:4: asm("" : "=r"(x));
>   sext.w a0,a0 # x, x
>   # ./asm2.c:5: asm("" : : "r"(x));
>   # ./asm2.c:7: }
>   ret

No, you cannot distinguish post-processing the output of the first asm vs.
pre-processing the input of the second asm. Try

  asm("" : "+r"(x));

as the second asm instead, and you'll get

f:
# t.c:17: asm("" : "=r"(x));
# t.c:18: asm("" : "+r"(x));
# t.c:20: }
sext.w  a0,a0   #, x
ret

If it helps, here's a Compiler Explorer link comparing with MIPS64:
https://godbolt.org/z/7eobvdKdK

Alexander

[COMMITTED] Clear NAN when reading back a global range if necessary.

[Aldy Hernandez via Gcc-patches]

When reading back from the global store, we must clear the NAN bit if
necessary.  The reason it's not happening is because the constructor
sets a NAN by default (when HONOR_NANS).  We must be careful to clear
the NAN bit if the original range didn't have a NAN.

I have commented the reason we use the constructor instead of filling
out the fields by hand, because it wasn't clear at re-reading this
code.

PR 107569/tree-optimization

gcc/ChangeLog:

* value-range-storage.cc (frange_storage_slot::get_frange): Clear
NAN if appropriate.
* value-range.cc (range_tests_floats): New test.
---
 gcc/value-range-storage.cc | 9 -
 gcc/value-range.cc | 9 +
 2 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/gcc/value-range-storage.cc b/gcc/value-range-storage.cc
index 462447ba250..b57701f0ea1 100644
--- a/gcc/value-range-storage.cc
+++ b/gcc/value-range-storage.cc
@@ -276,13 +276,20 @@ frange_storage_slot::get_frange (frange &r, tree type) 
const
   return;
 }
 
-  // Use the constructor because it will canonicalize the range.
+  // We use the constructor to create the new range instead of writing
+  // out the bits into the frange directly, because the global range
+  // being read may be being inlined into a function with different
+  // restrictions as when it was originally written.  We want to make
+  // sure the resulting range is canonicalized correctly for the new
+  // consumer.
   r = frange (type, m_min, m_max, m_kind);
 
   // The constructor will set the NAN bits for HONOR_NANS, but we must
   // make sure to set the NAN sign if known.
   if (HONOR_NANS (type) && (m_pos_nan ^ m_neg_nan) == 1)
 r.update_nan (m_neg_nan);
+  else if (!m_pos_nan && !m_neg_nan)
+r.clear_nan ();
 }
 
 bool
diff --git a/gcc/value-range.cc b/gcc/value-range.cc
index 859c7fb4af9..852ac09f2c4 100644
--- a/gcc/value-range.cc
+++ b/gcc/value-range.cc
@@ -4051,6 +4051,15 @@ range_tests_floats ()
   ASSERT_TRUE (real_isinf (&r0.lower_bound (), true));
   ASSERT_TRUE (real_isinf (&r0.upper_bound (), true));
 }
+
+  // Test that reading back a global range yields the same result as
+  // what we wrote into it.
+  tree ssa = make_temp_ssa_name (float_type_node, NULL, "blah");
+  r0.set_varying (float_type_node);
+  r0.clear_nan ();
+  set_range_info (ssa, r0);
+  get_global_range_query ()->range_of_expr (r1, ssa);
+  ASSERT_EQ (r0, r1);
 }
 
 // Run floating range tests for various combinations of NAN and INF
-- 
2.38.1

Re: [PATCH V2] Enable small loop unrolling for O2

[David Edelsohn via Gcc-patches]

> This patch does not change rs6000/s390 since I don't have machines to
> test them, but I suppose the default behavior is the same since they
> enable flag_unroll_loops at O2.

There are Power (rs6000) systems in the Compile Farm.

Trial Linux on Z (s390x) VMs are available through the Linux Community
Cloud.
https://linuxone.cloud.marist.edu/#/register?flag=VM

Thanks, David

[PATCH (pushed)] docs: create sources tarball

[Martin Liška]

maintainer-scripts/ChangeLog:

* update_web_docs_git.py: Create sources tarball.
---
 maintainer-scripts/update_web_docs_git.py | 29 +++
 1 file changed, 29 insertions(+)

diff --git a/maintainer-scripts/update_web_docs_git.py 
b/maintainer-scripts/update_web_docs_git.py
index 18c8bbb8324..d9cf9b70968 100755
--- a/maintainer-scripts/update_web_docs_git.py
+++ b/maintainer-scripts/update_web_docs_git.py
@@ -37,6 +37,32 @@ def find_configs():
 yield (Path(root).resolve(), docname)
 
 
+def create_source_tarball(output, configs):
+pwd = Path('.').resolve()
+subfolders = {'doc'}
+explicit_files = {'gcc/BASE-VER', 'gcc/DEV-PHASE', 'gcc/DATESTAMP'}
+
+for location, _ in configs:
+location = location.relative_to(pwd)
+while not location.name == 'doc':
+location = location.parent
+subfolders.add(location)
+
+sources = Path('sources')
+sources.mkdir()
+
+# Copy all subfolders and files
+for subfolder in subfolders:
+shutil.copytree(subfolder, sources / subfolder)
+
+for filename in explicit_files:
+shutil.copy(filename, sources / filename)
+
+shutil.make_archive(Path(output, 'docs-sources'), 'gztar',
+sources)
+print('sources tarball has been created')
+
+
 with tempfile.TemporaryDirectory() as folder:
 print(f'Using {folder} as temporary directory')
 os.chdir(folder)
@@ -49,6 +75,9 @@ with tempfile.TemporaryDirectory() as folder:
 if not output.exists():
 output.mkdir()
 
+# Create source tarball
+create_source_tarball(output, configs)
+
 temp = Path('tmp').resolve()
 temp.mkdir()
 
-- 
2.38.0

[PATCH (pushed)] Include docs-sources in onlinedocs.

[Martin Liška]

---
 htdocs/onlinedocs/index.html | 1 +
 1 file changed, 1 insertion(+)

diff --git a/htdocs/onlinedocs/index.html b/htdocs/onlinedocs/index.html
index cfa8bf5a..3410f731 100644
--- a/htdocs/onlinedocs/index.html
+++ b/htdocs/onlinedocs/index.html
@@ -1610,6 +1610,7 @@ existing release.
   (https://gcc.gnu.org/onlinedocs/libgccjit.pdf";>also in PDF)
 
 https://gcc.gnu.org/onlinedocs/libstdc++/";>libstdc++-v3
+https://gcc.gnu.org/onlinedocs/docs-sources.tar.gz";>Sphinx 
sources of all the manuals
   
 
   Internals Documentation
-- 
2.38.0

Re: [Patch Arm] Fix PR 92999

[Alex Coplan via Gcc-patches]

Hi Ramana,

On 08/11/2022 18:20, Ramana Radhakrishnan via Gcc-patches wrote:
> PR92999 is a case where the VFP calling convention does not allocate
> enough FP registers for a homogenous aggregate containing FP16 values.
> I believe this is the complete fix but would appreciate another set of
> eyes on this.
> 
> Could I get a hand with a regression test run on an armhf environment
> while I fix my environment ?

I ran a bootstrap/regtest on arm-linux-gnueabihf, which ran OK (no
regressions, new test passes).

FWIW, I noticed some minor style issues with the patch, though:

$ contrib/check_GNU_style.py Arm-Fix-PR-92999.diff
=== ERROR type #1: there should be exactly one space between function name and 
parenthesis (2 error(s)) ===
gcc/config/arm/arm.cc:6746:18:  shift = (MAX(GET_MODE_SIZE(ag_mode), 
GET_MODE_SIZE(SFmode))
gcc/config/arm/arm.cc:6747:23: / GET_MODE_SIZE(SFmode));

Thanks,
Alex

> 
> gcc/ChangeLog:
> 
> PR target/92999
> *  config/arm/arm.c (aapcs_vfp_allocate_return_reg): Adjust to handle
> aggregates with elements smaller than SFmode.
> 
> gcc/testsuite/ChangeLog:
> 
> * gcc.target/arm/pr92999.c: New test.
> 
> 
> Thanks,
> Ramana
> 
> Signed-off-by: Ramana Radhakrishnan 

Re: [RFC] docs: remove documentation for unsupported releases

[Joseph Myers]

On Wed, 9 Nov 2022, Michael Matz via Gcc-patches wrote:

> I think everything that's on the web server (even the 2.95 docu) has to be 
> reachable via a (reasonable) set of clicks from the main index.html.  It 
> doesn't need to be _directly_ from the main index.html, though.
> 
> Also, you simply might want to move the "Current Development" section 
> to the front if it's currently too cumbersome to reach.
> 
> (E.g. one could move the index of the obsolete versions to a different web 
> page, make that one un-indexable by google, but leave a trace to that one 
> from the main index.html).

Although we could use robots.txt to prevent indexing of the old 
documentation, that's not quite right, in that there's no problem with 
robots accessing the old documentation for any purpose (indexing, 
archiving, downloading a local copy of all the docs for an old version, 
etc.), just with showing it in a search engine in preference to a more 
recent version.  The logically correct way of directing search engines to 
the preferred version to index is .

Suppose we could develop some reasonably reliable way of making automated 
substitutions in the HTML manuals for old versions.  (Make sure the 
original versions of the files, generated years ago, are backed up first!  
Indeed, when we want to revise such substitutions, we should go back to 
the original versions of the files to do so rather than piling one 
substitution on top of another - i.e. the original versions should be kept 
somewhere readily available for that purpose, just not directly in the web 
area.)  Then we could substitute such  to point to a 
more recent release (that has a matching documentation page).  And as I 
mentioned at the Cauldron, I think having human-visible notices on the 
pages for old versions, linking to the corresponding page for human 
readers - like there are in old versions of the Python documentation - 
would be a good idea as well.

Maybe it would be hard to find matching pages in an automated way across 
the Sphinx transition - so all EOL versions before GCC 12 would end up 
pointing to corresponding pages in GCC 12 documentation and a more general 
index for later versions, rather than a corresponding page for a later 
version - but whatever can be done automatically in terms of 
rel="canonical" for search engines and a prominent notice at the top of 
each page for human readers still seems like it would be a significant 
improvement (and something that could be improved further incrementally).

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

[PATCH 1/2] symtab: also change RTL decl name

[Bernhard Reutner-Fischer via Gcc-patches]

We were changing the ASSEMBLER_NAME of the function decl
but not the name in DECL_RTL which is used as the function name
fnname in rest_of_handle_final(). This led to using the old, wrong name
for the attribute target default function when using target_clones.

Bootstrapped and regtested cleanly on x86_64-unknown-linux
for c,c++,fortran,lto.
Ok for trunk?

gcc/ChangeLog:

* symtab.cc: Remove stray comment.
(symbol_table::change_decl_assembler_name): Also update the
name in DECL_RTL.

Cc: Jan Hubicka 
---
 gcc/symtab.cc | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/gcc/symtab.cc b/gcc/symtab.cc
index f2d96c0268b..2e20bf5fefc 100644
--- a/gcc/symtab.cc
+++ b/gcc/symtab.cc
@@ -154,8 +154,6 @@ symbol_table::decl_assembler_name_equal (tree decl, 
const_tree asmname)
 }
 
 
-/* Returns nonzero if P1 and P2 are equal.  */
-
 /* Insert NODE to assembler name hash.  */
 
 void
@@ -303,6 +301,10 @@ symbol_table::change_decl_assembler_name (tree decl, tree 
name)
warning (0, "%qD renamed after being referenced in assembly", decl);
 
   SET_DECL_ASSEMBLER_NAME (decl, name);
+  /* Set the new name in rtl.  */
+  if (DECL_RTL_SET_P (decl))
+   XSTR (XEXP (DECL_RTL (decl), 0), 0) = IDENTIFIER_POINTER (name);
+
   if (alias)
{
  IDENTIFIER_TRANSPARENT_ALIAS (name) = 1;
-- 
2.38.1

[PATCH 2/2] Fortran: add attribute target_clones

[Bernhard Reutner-Fischer via Gcc-patches]

Hi!

Add support for attribute target_clones:
!GCC$ ATTRIBUTES target_clones("arch1", "arch3","default") :: mysubroutine

Bootstrapped and regtested on x86_64-unknown-linux with
--target_board=unix'{-m32,-m64}'.
OK for trunk?

gcc/fortran/ChangeLog:

* decl.cc: Include fold-const.h for size_int.
(gfc_match_gcc_attribute_args): New internal helper function.
(gfc_match_gcc_attributes): Handle target_clones.
* f95-lang.cc (struct attribute_spec): Add target and
target_clones entries.
* gfortran.h (ext_attr_id_t): Add EXT_ATTR_TARGET_CLONES.
(struct symbol_attribute): Add field ext_attr_args.
* trans-decl.cc (add_attributes_to_decl): Also add ext_attr_args
to the decl's attributes.
* gfortran.texi: Document attribute target_clones.

gcc/testsuite/ChangeLog:

* gfortran.dg/attr_target_clones-1.F90: New test.

Cc: gfortran ML 
---
 gcc/fortran/decl.cc   | 104 ++
 gcc/fortran/f95-lang.cc   |   4 +
 gcc/fortran/gfortran.h|   2 +
 gcc/fortran/gfortran.texi |  31 ++
 gcc/fortran/trans-decl.cc |   3 +
 .../gfortran.dg/attr_target_clones-1.F90  |  30 +
 6 files changed, 174 insertions(+)
 create mode 100644 gcc/testsuite/gfortran.dg/attr_target_clones-1.F90

diff --git a/gcc/fortran/decl.cc b/gcc/fortran/decl.cc
index 0f9b2ced4c2..3a619dbdd34 100644
--- a/gcc/fortran/decl.cc
+++ b/gcc/fortran/decl.cc
@@ -23,6 +23,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "coretypes.h"
 #include "options.h"
 #include "tree.h"
+#include "fold-const.h"
 #include "gfortran.h"
 #include "stringpool.h"
 #include "match.h"
@@ -11709,6 +11710,96 @@ gfc_match_final_decl (void)
   return MATCH_YES;
 }
 
+/* Internal helper to parse attribute argument list.
+   If REQUIRE_STRING is true, then require a string.
+   If ALLOW_MULTIPLE is true, allow more than one arg.
+   If multiple arguments are passed, require braces around them.
+   Returns a tree_list of arguments or NULL_TREE.  */
+static tree
+gfc_match_gcc_attribute_args (bool require_string, bool allow_multiple)
+{
+  tree attr_args = NULL_TREE, attr_arg;
+  char name[GFC_MAX_SYMBOL_LEN + 1];
+  unsigned pos = 0;
+  gfc_char_t c;
+
+  /* When we get here, we already parsed
+ !GCC$ ATTRIBUTES ATTRIBUTE_NAME
+ Now parse the arguments. These could be one of
+   "single_string_literal"
+   ( "str_literal_1" , "str_literal_2" )
+   */
+
+  gfc_gobble_whitespace ();
+
+  if (allow_multiple && gfc_match_char ('(') != MATCH_YES)
+{
+  gfc_error ("expected '(' at %C");
+  return NULL_TREE;
+}
+
+  if (require_string)
+{
+  do {
+   if (pos)
+ {
+   if (!allow_multiple)
+ {
+   gfc_error ("surplus argument at %C");
+   return NULL_TREE;
+ }
+   gfc_next_ascii_char (); /* Consume the comma.  */
+ }
+   pos = 0;
+   gfc_gobble_whitespace ();
+   unsigned char num_quotes = 0;
+   do {
+ c = gfc_next_char_literal (NONSTRING);
+ if (c == '"')
+   {
+ num_quotes++;
+ continue; /* Skip the quote */
+   }
+ name[pos++] = c;
+ if (pos >= GFC_MAX_SYMBOL_LEN)
+   {
+ gfc_error ("attribute argument truncated at %C");
+ return NULL_TREE;
+   }
+   } while (num_quotes % 2 && gfc_match_eos () != MATCH_YES);
+   if (pos < 1)
+ {
+   gfc_error ("expected argument at %C");
+   return NULL_TREE;
+ }
+   if (num_quotes != 2)
+ {
+   gfc_error ("invalid string literal at %C");
+   return NULL_TREE;
+ }
+   name[pos] = '\0'; /* Redundant wrt build_string.  */
+   tree str = build_string (pos, name);
+   /* Compare with c-family/c-common.cc: fix_string_type.  */
+   tree i_type = build_index_type (size_int (pos));
+   tree a_type = build_array_type (char_type_node, i_type);
+   TREE_TYPE (str) = a_type;
+   TREE_READONLY (str) = 1;
+   TREE_STATIC (str) = 1;
+   attr_arg = build_tree_list (NULL_TREE, str);
+   attr_args = chainon (attr_args, attr_arg);
+
+   gfc_gobble_whitespace ();
+  } while (gfc_peek_ascii_char () == ',');
+}
+
+  if (allow_multiple && gfc_match_char (')') != MATCH_YES)
+{
+  gfc_error ("expected ')' at %C");
+  return NULL_TREE;
+}
+
+  return attr_args;
+}
 
 const ext_attr_t ext_attr_list[] = {
   { "dllimport",EXT_ATTR_DLLIMPORT,"dllimport" },
@@ -11718,6 +11809,7 @@ const ext_attr_t ext_attr_list[] = {
   { "fastcall", EXT_ATTR_FASTCALL, "fastcall"  },
   { "no_arg_check", EXT_ATTR_NO_ARG_CHECK, NULL},
   { "deprecated",   EXT_ATTR_DEPRECATED,   NULL   },
+  { "target_clones",EXT_ATTR_TARGET_CLONES,NULL   },
   { NULL

[PATCH 0/2] Fortran: add attribute target_clones

[Bernhard Reutner-Fischer via Gcc-patches]

Hi!

These two patches add support for attribute target_clones to the fortran
frontend.

1) The symtab hunk is identical to the one sent in
https://gcc.gnu.org/pipermail/gcc-patches/2022-November/605081.html
which had some additional information.
I only tested it on x86_64-unknown-linux and for
languages c,fortran,c++,lto so far, i.e. not for ada,go,d,modula2

2) fortran FE hunks
I'm aware that the documentation will have to be rewritten now for
Sphinx.
I'll will take care of that before pushing the change anyway, of course.

The fortran FE part works as intended.
Note that it is of course not possible to mix ISA features of different
target architectures, i.e. "sse","avx512f" is fine, "powerpc7" in the
same attribute is prohibited.

There is a gotcha that took me a while to (re-)notice when writing the
testcase though: We (the fortran FE, fortran/cpp.cc) do not define arch
defines. Consider:
$ echo -e "#ifndef __x86_64__\nbummer\n#endif\nend" > /tmp/ouch.F95
$ ./gfortran -B. -c -o /tmp/ouch.o /tmp/ouch.F95
/tmp/ouch.F95:2:1:

2 | bummer
  | 1
Error: Unclassifiable statement at (1)

$ echo -e "#ifndef __x86_64__\nbummer\n#endif" \
  | ./xgcc -B. -x f95-cpp-input -ffree-form -E -dD - | grep -i x86
$ # nothing
versus
$ echo -e "#ifndef __x86_64__\nbummer\n#endif" \
  | ./xgcc -B. -x assembler-with-cpp -E -dD - | grep -i x86
#define __x86_64 1
#define __x86_64__ 1

I'm sure we have existing PRs about those missing defines but i didn't
look yet.


Bernhard Reutner-Fischer (2):
  symtab: also change RTL decl name
  Fortran: add attribute target_clones

 gcc/fortran/decl.cc   | 104 ++
 gcc/fortran/f95-lang.cc   |   4 +
 gcc/fortran/gfortran.h|   2 +
 gcc/fortran/gfortran.texi |  31 ++
 gcc/fortran/trans-decl.cc |   3 +
 gcc/symtab.cc |   6 +-
 .../gfortran.dg/attr_target_clones-1.F90  |  30 +
 7 files changed, 178 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/gfortran.dg/attr_target_clones-1.F90

-- 
2.38.1

Re: [RFC] docs: remove documentation for unsupported releases

[Alexander Monakov via Gcc-patches]

On Wed, 9 Nov 2022, Martin Liška wrote:

> Hi.
> 
> I think we should remove documentation for unsupported GCC releases
> as it's indexed by Google engine.

I'd agree with previous responses that outright removing the links is
undesirable, and pointing Google to recent documentation should be done
by annotating links, e.g. via rel=canonical as indicated by Joseph.

I would add that adding rel=canonical links seems doable without modifying
old files, by configuring the web server to add HTTP Link: header.

> Second reason is that the page is long
> one one can't easily jump to Current development documentation.

For this I would suggest using the  tag to neatly fold links for
old releases. Please see the attached patch.

AlexanderFrom ab6ce8c24aa17dba8ed79f3c3f7a5e8038dd3205 Mon Sep 17 00:00:00 2001
From: Alexander Monakov 
Date: Wed, 9 Nov 2022 22:17:16 +0300
Subject: [PATCH] Fold doc links for old releases using  tag

---
 htdocs/onlinedocs/index.html | 151 ++-
 1 file changed, 96 insertions(+), 55 deletions(-)

diff --git a/htdocs/onlinedocs/index.html b/htdocs/onlinedocs/index.html
index 3410f731..03cbdbeb 100644
--- a/htdocs/onlinedocs/index.html
+++ b/htdocs/onlinedocs/index.html
@@ -18,8 +18,8 @@
  caring about internals should really be using the mainline
  versions.  -->
 
-
-  GCC 12.2 manuals:
+
+ GCC 12.2 manuals:
   
 https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/";>GCC
  12.2 Manual (
 https://gcc.gnu.org/onlinedocs/gcc-12.2.0/docs-sources.tar.gz";>Texinfo
  sources of all the GCC 12.2 manuals
-  
+  
+
 
-  GCC 11.3 manuals:
+
+  GCC 11.3 manuals:
   
 https://gcc.gnu.org/onlinedocs/gcc-11.3.0/gcc/";>GCC
  11.3 Manual (
 https://gcc.gnu.org/onlinedocs/gcc-11.3.0/docs-sources.tar.gz";>Texinfo
  sources of all the GCC 11.3 manuals
-  
+  
+
 
-  GCC 10.4 manuals:
+
+  GCC 10.4 manuals:
   
 https://gcc.gnu.org/onlinedocs/gcc-10.4.0/gcc/";>GCC
  10.4 Manual (
 https://gcc.gnu.org/onlinedocs/gcc-10.4.0/docs-sources.tar.gz";>Texinfo
  sources of all the GCC 10.4 manuals
-  
+  
+
 
-  GCC 9.5 manuals:
+
+  GCC 9.5 manuals:
   
 https://gcc.gnu.org/onlinedocs/gcc-9.5.0/gcc/";>GCC
  9.5 Manual (
 https://gcc.gnu.org/onlinedocs/gcc-9.5.0/docs-sources.tar.gz";>Texinfo
  sources of all the GCC 9.5 manuals
-  
+  
+
 
-  GCC 8.5 manuals:
+
+  GCC 8.5 manuals:
   
 https://gcc.gnu.org/onlinedocs/gcc-8.5.0/gcc/";>GCC
  8.5 Manual (
 https://gcc.gnu.org/onlinedocs/gcc-8.5.0/docs-sources.tar.gz";>Texinfo
  sources of all the GCC 8.5 manuals
-  
+  
+
 
-  GCC 7.5 manuals:
+
+  GCC 7.5 manuals:
   
 https://gcc.gnu.org/onlinedocs/gcc-7.5.0/gcc/";>GCC
  7.5 Manual (
 https://gcc.gnu.org/onlinedocs/gcc-7.5.0/docs-sources.tar.gz";>Texinfo
  sources of all the GCC 7.5 manuals
-  
+  
+
 
-  GCC 6.5 manuals:
+
+  GCC 6.5 manuals:
   
 https://gcc.gnu.org/onlinedocs/gcc-6.5.0/gcc/";>GCC
  6.5 Manual (
 https://gcc.gnu.org/onlinedocs/gcc-6.5.0/docs-sources.tar.gz";>Texinfo
  sources of all the GCC 6.5 manuals
-  
+  
+
 
-  GCC 5.5 manuals:
+
+  GCC 5.5 manuals:
   
 https://gcc.gnu.org/onlinedocs/gcc-5.5.0/gcc/";>GCC
  5.5 Manual (
 https://gcc.gnu.org/onlinedocs/gcc-5.5.0/docs-sources.tar.gz";>Texinfo
  sources of all the GCC 5.5 manuals
-  
+  
+
 
-  GCC 4.9.4 manuals:
+
+  GCC 4.9.4 manuals:
   
 https://gcc.gnu.org/onlinedocs/gcc-4.9.4/gcc/";>GCC
  4.9.4 Manual ()
 https://gcc.gnu.org/onlinedocs/gcc-4.9.4/docs-sources.tar.gz";>Texinfo
  sources of all the GCC 4.9.4 manuals
-  
+  
+
 
-  GCC 4.8.5 manuals:
+
+  GCC 4.8.5 manuals:
   
 https://gcc.gnu.org/onlinedocs/gcc-4.8.5/gcc/";>GCC
  4.8.5 Manual ()
 https://gcc.gnu.org/onlinedocs/gcc-4.8.5/docs-sources.tar.gz";>Texinfo
  sources of all the GCC 4.8.5 manuals
-  
-
+  
+
 
-  GCC 4.7.4 manuals:
+
+  GCC 4.7.4 manuals:
   
 https://gcc.gnu.org/onlinedocs/gcc-4.7.4/gcc/";>GCC
  4.7.4 Manual ()
 https://gcc.gnu.org/onlinedocs/gcc-4.7.4/docs-sources.tar.gz";>Texinfo
  sources of all the GCC 4.7.4 manuals
-  
-
+  
+
 
-  GCC 4.6.4 manuals:
+
+  GCC 4.6.4 manuals:
   
 https://gcc.gnu.org/onlinedocs/gcc-4.6.4/gcc/";>GCC
  4.6.4 Manual ()
 https://gcc.gnu.org/onlinedocs/gcc-4.6.4/docs-sources.tar.gz";>Texinfo
  sources of all the GCC 4.6.4 manuals
-  
-
+  
+
 
-  GCC 4.5.4 manuals:
+
+  GCC 4.5.4 manuals:
   
 https://gcc.gnu.org/onlinedocs/gcc-4.5.4/gcc/";>GCC
  4.5.4 Manual ()
 https://gcc.gnu.org/onlinedocs/gcc-4.5.4/docs-sources.tar.gz";>Texinfo
  sources of all the GCC 4.5.4 manuals
-  
-
+  
+
 
-  GCC 4.4.7 manuals:
+
+  GCC 4.4.7 manuals:
   
 https://gcc.gnu.org/onlinedocs/gcc-4.4.7/gcc/";>GCC
  4.4.7 Manual ()
 https://gcc.gnu.org/onlinedocs/gcc-4.4.7/docs-sources.tar.gz";>Texinfo

[PATCH (pushed)] sphinx: add missing HAS_SPHINX_BUILD

[Martin Liška]

libgomp/ChangeLog:

* Makefile.in: Add missing HAS_SPHINX_BUILD.

libitm/ChangeLog:

* Makefile.in: Add missing HAS_SPHINX_BUILD.

libquadmath/ChangeLog:

* Makefile.in: Add missing HAS_SPHINX_BUILD.
---
 libgomp/Makefile.in | 1 +
 libitm/Makefile.in  | 1 +
 libquadmath/Makefile.in | 1 +
 3 files changed, 3 insertions(+)

diff --git a/libgomp/Makefile.in b/libgomp/Makefile.in
index 0c016980c3d..814ccd13dc0 100644
--- a/libgomp/Makefile.in
+++ b/libgomp/Makefile.in
@@ -401,6 +401,7 @@ SED = @SED@
 SET_MAKE = @SET_MAKE@
 SHELL = @SHELL@
 SPHINX_BUILD = @SPHINX_BUILD@
+HAS_SPHINX_BUILD = @HAS_SPHINX_BUILD@
 STRIP = @STRIP@
 VERSION = @VERSION@
 XCFLAGS = @XCFLAGS@
diff --git a/libitm/Makefile.in b/libitm/Makefile.in
index f51858db8c7..a07b9ebc6d0 100644
--- a/libitm/Makefile.in
+++ b/libitm/Makefile.in
@@ -347,6 +347,7 @@ SED = @SED@
 SET_MAKE = @SET_MAKE@
 SHELL = @SHELL@
 SPHINX_BUILD = @SPHINX_BUILD@
+HAS_SPHINX_BUILD = @HAS_SPHINX_BUILD@
 STRIP = @STRIP@
 VERSION = @VERSION@
 XCFLAGS = @XCFLAGS@
diff --git a/libquadmath/Makefile.in b/libquadmath/Makefile.in
index 864ebc6048a..10e402ccd07 100644
--- a/libquadmath/Makefile.in
+++ b/libquadmath/Makefile.in
@@ -347,6 +347,7 @@ SED = @SED@
 SET_MAKE = @SET_MAKE@
 SHELL = @SHELL@
 SPHINX_BUILD = @SPHINX_BUILD@
+HAS_SPHINX_BUILD = @HAS_SPHINX_BUILD@
 STRIP = @STRIP@
 VERSION = @VERSION@
 XCFLAGS = @XCFLAGS@
-- 
2.38.0

Re: [RFC] docs: remove documentation for unsupported releases

[Martin Liška]

On 11/9/22 20:32, Alexander Monakov wrote:
> 
> On Wed, 9 Nov 2022, Martin Liška wrote:
> 
>> Hi.
>>
>> I think we should remove documentation for unsupported GCC releases
>> as it's indexed by Google engine.
> 
> I'd agree with previous responses that outright removing the links is
> undesirable, and pointing Google to recent documentation should be done
> by annotating links, e.g. via rel=canonical as indicated by Joseph.
> 
> I would add that adding rel=canonical links seems doable without modifying
> old files, by configuring the web server to add HTTP Link: header.
> 
>> Second reason is that the page is long
>> one one can't easily jump to Current development documentation.
> 
> For this I would suggest using the  tag to neatly fold links for
> old releases. Please see the attached patch.

I do support the patch. It should help with the Google indexing (maybe).

Martin

> 
> Alexander

[PATCH (pushed)] docs: Fix expected diagnostics URL [PR107599]

[Martin Liška]

PR c++/107599

gcc/testsuite/ChangeLog:

* c-c++-common/diagnostic-format-json-2.c: Fix expected URL.
* c-c++-common/diagnostic-format-json-3.c: Likewise.
* c-c++-common/diagnostic-format-json-4.c: Likewise.
* gfortran.dg/diagnostic-format-json-2.F90: Likewise.
* gfortran.dg/diagnostic-format-json-3.F90: Likewise.
---
 gcc/testsuite/c-c++-common/diagnostic-format-json-2.c  | 2 +-
 gcc/testsuite/c-c++-common/diagnostic-format-json-3.c  | 2 +-
 gcc/testsuite/c-c++-common/diagnostic-format-json-4.c  | 2 +-
 gcc/testsuite/gfortran.dg/diagnostic-format-json-2.F90 | 2 +-
 gcc/testsuite/gfortran.dg/diagnostic-format-json-3.F90 | 2 +-
 5 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/gcc/testsuite/c-c++-common/diagnostic-format-json-2.c 
b/gcc/testsuite/c-c++-common/diagnostic-format-json-2.c
index edb802efb8d..4e2351aa60a 100644
--- a/gcc/testsuite/c-c++-common/diagnostic-format-json-2.c
+++ b/gcc/testsuite/c-c++-common/diagnostic-format-json-2.c
@@ -12,7 +12,7 @@
 /* { dg-regexp "\"escape-source\": false" } */
 /* { dg-regexp "\"message\": \"#warning message\"" } */
 /* { dg-regexp "\"option\": \"-Wcpp\"" } */
-/* { dg-regexp "\"option_url\": \"https:\[^\n\r\"\]*#index-Wcpp\"" } */
+/* { dg-regexp "\"option_url\": \"https:\[^\n\r\"\]*#cmdoption-Wcpp\"" } */
 
 /* { dg-regexp "\"caret\": \{" } */
 /* { dg-regexp "\"file\": \"\[^\n\r\"\]*diagnostic-format-json-2.c\"" } */
diff --git a/gcc/testsuite/c-c++-common/diagnostic-format-json-3.c 
b/gcc/testsuite/c-c++-common/diagnostic-format-json-3.c
index bb7b8dc5d16..325b0bab63b 100644
--- a/gcc/testsuite/c-c++-common/diagnostic-format-json-3.c
+++ b/gcc/testsuite/c-c++-common/diagnostic-format-json-3.c
@@ -12,7 +12,7 @@
 /* { dg-regexp "\"escape-source\": false" } */
 /* { dg-regexp "\"message\": \"#warning message\"" } */
 /* { dg-regexp "\"option\": \"-Werror=cpp\"" } */
-/* { dg-regexp "\"option_url\": \"https:\[^\n\r\"\]*#index-Wcpp\"" } */
+/* { dg-regexp "\"option_url\": \"https:\[^\n\r\"\]*#cmdoption-Wcpp\"" } */
 
 /* { dg-regexp "\"caret\": \{" } */
 /* { dg-regexp "\"file\": \"\[^\n\r\"\]*diagnostic-format-json-3.c\"" } */
diff --git a/gcc/testsuite/c-c++-common/diagnostic-format-json-4.c 
b/gcc/testsuite/c-c++-common/diagnostic-format-json-4.c
index 8ac90723cbd..f6cd2aacb20 100644
--- a/gcc/testsuite/c-c++-common/diagnostic-format-json-4.c
+++ b/gcc/testsuite/c-c++-common/diagnostic-format-json-4.c
@@ -42,7 +42,7 @@ int test (void)
 /* { dg-regexp "\"message\": \"this 'if' clause does not guard...\"" } */
 /* { dg-regexp "\"escape-source\": false" } */
 /* { dg-regexp "\"option\": \"-Wmisleading-indentation\"" } */
-/* { dg-regexp "\"option_url\": 
\"https:\[^\n\r\"\]*#index-Wmisleading-indentation\"" } */
+/* { dg-regexp "\"option_url\": 
\"https:\[^\n\r\"\]*#cmdoption-Wmisleading-indentation\"" } */
 
 /* { dg-regexp "\"caret\": \{" } */
 /* { dg-regexp "\"file\": \"\[^\n\r\"\]*diagnostic-format-json-4.c\"" } */
diff --git a/gcc/testsuite/gfortran.dg/diagnostic-format-json-2.F90 
b/gcc/testsuite/gfortran.dg/diagnostic-format-json-2.F90
index 1681462fa08..3b6030f7c5f 100644
--- a/gcc/testsuite/gfortran.dg/diagnostic-format-json-2.F90
+++ b/gcc/testsuite/gfortran.dg/diagnostic-format-json-2.F90
@@ -12,7 +12,7 @@
 ! { dg-regexp "\"escape-source\": false" }
 ! { dg-regexp "\"message\": \"#warning message\"" }
 ! { dg-regexp "\"option\": \"-Wcpp\"" }
-! { dg-regexp "\"option_url\": \"\[^\n\r\"\]*#index-Wcpp\"" }
+! { dg-regexp "\"option_url\": \"\[^\n\r\"\]*#cmdoption-Wcpp\"" }
 
 ! { dg-regexp "\"caret\": \{" }
 ! { dg-regexp "\"file\": \"\[^\n\r\"\]*diagnostic-format-json-2.F90\"" }
diff --git a/gcc/testsuite/gfortran.dg/diagnostic-format-json-3.F90 
b/gcc/testsuite/gfortran.dg/diagnostic-format-json-3.F90
index f0a67de76b0..a2a1c14a991 100644
--- a/gcc/testsuite/gfortran.dg/diagnostic-format-json-3.F90
+++ b/gcc/testsuite/gfortran.dg/diagnostic-format-json-3.F90
@@ -12,7 +12,7 @@
 ! { dg-regexp "\"escape-source\": false" }
 ! { dg-regexp "\"message\": \"#warning message\"" }
 ! { dg-regexp "\"option\": \"-Werror=cpp\"" }
-! { dg-regexp "\"option_url\": \"\[^\n\r\"\]*#index-Wcpp\"" }
+! { dg-regexp "\"option_url\": \"\[^\n\r\"\]*#cmdoption-Wcpp\"" }
 
 ! { dg-regexp "\"caret\": \{" }
 ! { dg-regexp "\"file\": \"\[^\n\r\"\]*diagnostic-format-json-3.F90\"" }
-- 
2.38.0

[Ping 2][PATCH] Add condition coverage profiling

[Jørgen Kvalsvik via Gcc-patches]

On 02/11/2022 07:16, Jørgen Kvalsvik wrote:
> On 25/10/2022 08:33, Jørgen Kvalsvik wrote:
>> On 12/10/2022 12:16, Jørgen Kvalsvik wrote:
>>> This patch adds support in gcc+gcov for modified condition/decision
>>> coverage (MC/DC) with the -fprofile-conditions flag. MC/DC is a type of
>>> test/code coverage and it is particularly important in the avation and
>>> automotive industries for safety-critical applications. MC/DC it is
>>> required for or recommended by:
>>>
>>> * DO-178C for the most critical software (Level A) in avionics
>>> * IEC 61508 for SIL 4
>>> * ISO 26262-6 for ASIL D
>>>
>>> From the SQLite webpage:
>>>
>>> Two methods of measuring test coverage were described above:
>>> "statement" and "branch" coverage. There are many other test
>>> coverage metrics besides these two. Another popular metric is
>>> "Modified Condition/Decision Coverage" or MC/DC. Wikipedia defines
>>> MC/DC as follows:
>>>
>>> * Each decision tries every possible outcome.
>>> * Each condition in a decision takes on every possible outcome.
>>> * Each entry and exit point is invoked.
>>> * Each condition in a decision is shown to independently affect
>>>   the outcome of the decision.
>>>
>>> In the C programming language where && and || are "short-circuit"
>>> operators, MC/DC and branch coverage are very nearly the same thing.
>>> The primary difference is in boolean vector tests. One can test for
>>> any of several bits in bit-vector and still obtain 100% branch test
>>> coverage even though the second element of MC/DC - the requirement
>>> that each condition in a decision take on every possible outcome -
>>> might not be satisfied.
>>>
>>> https://sqlite.org/testing.html#mcdc
>>>
>>> Wahlen, Heimdahl, and De Silva "Efficient Test Coverage Measurement for
>>> MC/DC" describes an algorithm for adding instrumentation by carrying
>>> over information from the AST, but my algorithm analyses the the control
>>> flow graph to instrument for coverage. This has the benefit of being
>>> programming language independent and faithful to compiler decisions
>>> and transformations, although I have only tested it on constructs in C
>>> and C++, see testsuite/gcc.misc-tests and testsuite/g++.dg.
>>>
>>> Like Wahlen et al this implementation records coverage in fixed-size
>>> bitsets which gcov knows how to interpret. This is very fast, but
>>> introduces a limit on the number of terms in a single boolean
>>> expression, the number of bits in a gcov_unsigned_type (which is
>>> typedef'd to uint64_t), so for most practical purposes this would be
>>> acceptable. This limitation is in the implementation and not the
>>> algorithm, so support for more conditions can be added by also
>>> introducing arbitrary-sized bitsets.
>>>
>>> For space overhead, the instrumentation needs two accumulators
>>> (gcov_unsigned_type) per condition in the program which will be written
>>> to the gcov file. In addition, every function gets a pair of local
>>> accumulators, but these accmulators are reused between conditions in the
>>> same function.
>>>
>>> For time overhead, there is a zeroing of the local accumulators for
>>> every condition and one or two bitwise operation on every edge taken in
>>> the an expression.
>>>
>>> In action it looks pretty similar to the branch coverage. The -g short
>>> opt carries no significance, but was chosen because it was an available
>>> option with the upper-case free too.
>>>
>>> gcov --conditions:
>>>
>>> 3:   17:void fn (int a, int b, int c, int d) {
>>> 3:   18:if ((a && (b || c)) && d)
>>> condition outcomes covered 3/8
>>> condition  0 not covered (true false)
>>> condition  1 not covered (true)
>>> condition  2 not covered (true)
>>> condition  3 not covered (true)
>>> 1:   19:x = 1;
>>> -:   20:else
>>> 2:   21:x = 2;
>>> 3:   22:}
>>>
>>> gcov --conditions --json-format:
>>>
>>> "conditions": [
>>> {
>>> "not_covered_false": [
>>> 0
>>> ],
>>> "count": 8,
>>> "covered": 3,
>>> "not_covered_true": [
>>> 0,
>>> 1,
>>> 2,
>>> 3
>>> ]
>>> }
>>> ],
>>>
>>> Some expressions, mostly those without else-blocks, are effectively
>>> "rewritten" in the CFG construction making the algorithm unable to
>>> distinguish them:
>>>
>>> and.c:
>>>
>>> if (a && b && c)
>>> x = 1;
>>>
>>> ifs.c:
>>>
>>> if (a)
>>> if (b)
>>> if (c)
>>> x = 1;
>>>
>>> gcc will build the same graph for both these programs, and gcov will
>>> report boths as 3-term expressions. It is vital that it is not
>>> interpreted the other way around (which is consistent with the shape of
>>> the graph) because otherwise the masking would be wrong for the and.c
>

[PATCH, committed] Fortran: avoid NULL pointer dereference on bad EQUIVALENCEs [PR107559]

[Harald Anlauf via Gcc-patches]

Dear all,

I've committed an obvious patch for NULL pointer dereferences
that could occur when checking EQUIVALENCEs.  See also attached.

Testcase by Gerhard.

Regtested on x86_64-pc-linux-gnu.

Pushed: https://gcc.gnu.org/g:e505f7493bed1395d121d2f53137ec11706fa42e

Thanks,
Harald

From e505f7493bed1395d121d2f53137ec11706fa42e Mon Sep 17 00:00:00 2001
From: Harald Anlauf 
Date: Wed, 9 Nov 2022 21:05:28 +0100
Subject: [PATCH] Fortran: avoid NULL pointer dereference on bad EQUIVALENCEs
 [PR107559]

gcc/fortran/ChangeLog:

	PR fortran/107559
	* resolve.cc (resolve_equivalence): Avoid NULL pointer dereference
	while emitting diagnostics for bad EQUIVALENCEs.

gcc/testsuite/ChangeLog:

	PR fortran/107559
	* gfortran.dg/pr107559.f90: New test.
---
 gcc/fortran/resolve.cc |  2 ++
 gcc/testsuite/gfortran.dg/pr107559.f90 | 11 +++
 2 files changed, 13 insertions(+)
 create mode 100644 gcc/testsuite/gfortran.dg/pr107559.f90

diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index 9202e2f10ad..5ff1cd070ac 100644
--- a/gcc/fortran/resolve.cc
+++ b/gcc/fortran/resolve.cc
@@ -17218,6 +17218,7 @@ resolve_equivalence (gfc_equiv *eq)
 	"statement at %L with different type objects";
   if ((object ==2
 	   && last_eq_type == SEQ_MIXED
+	   && last_where
 	   && !gfc_notify_std (GFC_STD_GNU, msg, first_sym->name, last_where))
 	  || (eq_type == SEQ_MIXED
 	  && !gfc_notify_std (GFC_STD_GNU, msg, sym->name, &e->where)))
@@ -17227,6 +17228,7 @@ resolve_equivalence (gfc_equiv *eq)
 	"statement at %L with objects of different type";
   if ((object ==2
 	   && last_eq_type == SEQ_NONDEFAULT
+	   && last_where
 	   && !gfc_notify_std (GFC_STD_GNU, msg, first_sym->name, last_where))
 	  || (eq_type == SEQ_NONDEFAULT
 	  && !gfc_notify_std (GFC_STD_GNU, msg, sym->name, &e->where)))
diff --git a/gcc/testsuite/gfortran.dg/pr107559.f90 b/gcc/testsuite/gfortran.dg/pr107559.f90
new file mode 100644
index 000..714e236df50
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr107559.f90
@@ -0,0 +1,11 @@
+! { dg-do compile }
+! { dg-options "-std=f95" }
+! PR fortran/107559 - ICE in resolve_equivalence
+! Contributed by G.Steinmetz
+
+module m
+  implicit none
+  integer, protected :: a ! { dg-error "Fortran 2003: PROTECTED attribute" }
+  integer :: b
+  equivalence (a, b)  ! { dg-error "has no IMPLICIT type" }
+end
--
2.35.3

Proxy ping [PATCH] Fortran: diagnostics for actual arguments to pointer dummy arguments [PR94104]

[Harald Anlauf via Gcc-patches]

Dear all,

Jose posted a patch here that was never reviewed:

  https://gcc.gnu.org/pipermail/fortran/2021-June/056162.html

I think the diagnostics improvement is helpful, as it adjusts
to the changes from F2003 to F2008.

The patch suffered a little from bitrot, but was otherwise
straightforward to apply.  I slightly edited the commit
message, as I found the original one difficult to parse.

Regtested on x86_64-pc-linux-gnu.  OK for mainline?

Thanks,
Harald

From 46957184b74af8d5a3b41704f5ef48a12f37fe33 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jos=C3=A9=20Rui=20Faustino=20de=20Sousa?=
 
Date: Wed, 9 Nov 2022 21:30:25 +0100
Subject: [PATCH] Fortran: diagnostics for actual arguments to pointer dummy
 arguments [PR94104]

Error message improvement.  In Fortran 2008 actual procedure arguments
associated with a pointer, intent(in) attribute, dummy argument
can also have the target attribute, not just pointer.

gcc/fortran/ChangeLog:

	PR fortran/94104
	* interface.cc (gfc_compare_actual_formal): Improve error message
	dependent on Fortran standard level.

gcc/testsuite/ChangeLog:

	PR fortran/94104
	* gfortran.dg/parens_2.f90: Adjust to improved error message.
	* gfortran.dg/PR94104a.f90: New test.
	* gfortran.dg/PR94104b.f90: New test.
---
 gcc/fortran/interface.cc   | 48 +-
 gcc/testsuite/gfortran.dg/PR94104a.f90 | 29 
 gcc/testsuite/gfortran.dg/PR94104b.f90 | 29 
 gcc/testsuite/gfortran.dg/parens_2.f90 |  2 +-
 4 files changed, 90 insertions(+), 18 deletions(-)
 create mode 100644 gcc/testsuite/gfortran.dg/PR94104a.f90
 create mode 100644 gcc/testsuite/gfortran.dg/PR94104b.f90

diff --git a/gcc/fortran/interface.cc b/gcc/fortran/interface.cc
index d3e199535b3..49dbd1d886c 100644
--- a/gcc/fortran/interface.cc
+++ b/gcc/fortran/interface.cc
@@ -3477,25 +3477,39 @@ gfc_compare_actual_formal (gfc_actual_arglist **ap, gfc_formal_arglist *formal,
 	  goto match;
 	}

-  if (a->expr->expr_type != EXPR_NULL
-	  && compare_pointer (f->sym, a->expr) == 0)
+  if (a->expr->expr_type != EXPR_NULL)
 	{
-	  if (where)
-	gfc_error ("Actual argument for %qs must be a pointer at %L",
-		   f->sym->name, &a->expr->where);
-	  ok = false;
-	  goto match;
-	}
+	  int cmp = compare_pointer (f->sym, a->expr);
+	  bool pre2008 = ((gfc_option.allow_std & GFC_STD_F2008) == 0);

-  if (a->expr->expr_type != EXPR_NULL
-	  && (gfc_option.allow_std & GFC_STD_F2008) == 0
-	  && compare_pointer (f->sym, a->expr) == 2)
-	{
-	  if (where)
-	gfc_error ("Fortran 2008: Non-pointer actual argument at %L to "
-		   "pointer dummy %qs", &a->expr->where,f->sym->name);
-	  ok = false;
-	  goto match;
+	  if (pre2008 && cmp == 0)
+	{
+	  if (where)
+		gfc_error ("Actual argument for %qs at %L must be a pointer",
+			   f->sym->name, &a->expr->where);
+	  ok = false;
+	  goto match;
+	}
+
+	  if (pre2008 && cmp == 2)
+	{
+	  if (where)
+		gfc_error ("Fortran 2008: Non-pointer actual argument at %L to "
+			   "pointer dummy %qs", &a->expr->where, f->sym->name);
+	  ok = false;
+	  goto match;
+	}
+
+	  if (!pre2008 && cmp == 0)
+	{
+	  if (where)
+		gfc_error ("Actual argument for %qs at %L must be a pointer "
+			   "or a valid target for the dummy pointer in a "
+			   "pointer assignment statement",
+			   f->sym->name, &a->expr->where);
+	  ok = false;
+	  goto match;
+	}
 	}


diff --git a/gcc/testsuite/gfortran.dg/PR94104a.f90 b/gcc/testsuite/gfortran.dg/PR94104a.f90
new file mode 100644
index 000..a1e578ac9ba
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/PR94104a.f90
@@ -0,0 +1,29 @@
+! { dg-do compile }
+! { dg-options "-std=f2003" }
+!
+! PR fortran/94104
+!
+
+program diag_p
+  implicit none
+
+  integer, parameter :: n = 7
+
+  integer :: a(n)
+  integer, target :: b(n)
+
+  a = 1
+  print *, sumf(a) ! { dg-error "Actual argument for 'a' at .1. must be a pointer" }
+  print *, sumf(b) ! { dg-error "Fortran 2008: Non-pointer actual argument at .1. to pointer dummy 'a'" }
+
+contains
+
+  function sumf(a) result(s)
+integer, pointer, intent(in) :: a(:)
+
+integer :: s
+
+s = sum(a)
+  end function sumf
+
+end program diag_p
diff --git a/gcc/testsuite/gfortran.dg/PR94104b.f90 b/gcc/testsuite/gfortran.dg/PR94104b.f90
new file mode 100644
index 000..ee7d640b926
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/PR94104b.f90
@@ -0,0 +1,29 @@
+! { dg-do compile }
+! { dg-options "-std=f2008" }
+!
+! PR fortran/94104
+!
+
+program diag_p
+  implicit none
+
+  integer, parameter :: n = 7
+
+  integer :: a(n)
+  integer, target :: b(n)
+
+  a = 1
+  print *, sumf(a) ! { dg-error "Actual argument for 'a' at .1. must be a pointer or a valid target" }
+  print *, sumf(b)
+
+contains
+
+  function sumf(a) result(s)
+integer, pointer, intent(in) :: a(:)
+
+integer :: s
+
+s = sum(a)
+  end function sumf
+
+end program diag_p
diff --git a/gcc/testsu

[PATCH] c++: P2448 - Relaxing some constexpr restrictions [PR106649]

[Marek Polacek via Gcc-patches]

This patch implements C++23 P2448, which lifts more restrictions on the
constexpr keyword.  It's effectively going the way of being just a hint
(hello, inline!).

This gist is relatively simple: in C++23, a constexpr function's return
type/parameter type doesn't have to be a literal type; and you can have
a constexpr function for which no invocation satisfies the requirements
of a core constant expression.  For example,

  void f(int& i); // not constexpr

  constexpr void g(int& i) {
f(i); // unconditionally calls a non-constexpr function
  }

is now OK, even though there isn't an invocation of 'g' that would be
a constant expression.  Maybe 'f' will be made constexpr soon, or maybe
this depends on the version of C++ used, and similar.  The patch is
unfortunately not that trivial.  The important bit is to use the new
require_potential_rvalue_constant_expression_fncheck in
maybe_save_constexpr_fundef (and where appropriate).  It has a new flag
that says that we're checking the body of a constexpr function, and in
that case it's OK to find constructs that aren't a constant expression.

Since it's useful to be able to check for problematic constructs even
in C++23, this patch implements a new warning, -Winvalid-constexpr,
which is a pedwarn turned on by default in C++20 and earlier, and which
can be turned on in C++23 as well, in which case it's an ordinary warning.
This I implemented by using the new function constexpr_error, used in
p_c_e_1 and friends.  (In some cases I believe fundef_p will be always
false (= hard error), but it made sense to me to be consistent and use
constexpr_error throughout p_c_e_1.)

While working on this I think I found a bug, see constexpr-nonlit15.C
and .  This patch doesn't address that.

I also don't love that in C++23, if you don't use -Winvalid-constexpr,
and call a constexpr function that in fact isn't constexpr-ready yet,
sometimes all you get is an error saying "called in a constant expression"
like in constexpr-nonlit12.C.  This could be remedied by some tweaks to
explain_invalid_constexpr_fn, I reckon (it gives up on !DECL_DEFAULTED_FN).

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?

PR c++/106649

gcc/c-family/ChangeLog:

* c-cppbuiltin.cc (c_cpp_builtins): Update value of __cpp_constexpr for
C++23.
* c-opts.cc (c_common_post_options): Set warn_invalid_constexpr
depending on cxx_dialect.
* c.opt (Winvalid-constexpr): New option.

gcc/cp/ChangeLog:

* constexpr.cc (constexpr_error): New function.
(is_valid_constexpr_fn): Use constexpr_error.
(maybe_save_constexpr_fundef): Call
require_potential_rvalue_constant_expression_fncheck rather than
require_potential_rvalue_constant_expression.
(non_const_var_error): Add a bool parameter.  Use constexpr_error.
(inline_asm_in_constexpr_error): Likewise.
(cxx_eval_constant_expression): Adjust calls to non_const_var_error
and inline_asm_in_constexpr_error.
(potential_constant_expression_1): Add a bool parameter.  Use
constexpr_error.
(require_potential_rvalue_constant_expression_fncheck): New function.
* cp-tree.h (require_potential_rvalue_constant_expression_fncheck):
Declare.
* method.cc (struct comp_info): Call
require_potential_rvalue_constant_expression_fncheck rather than
require_potential_rvalue_constant_expression.

gcc/ChangeLog:

* doc/gcc/gcc-command-options/option-summary.rst: Add
-Winvalid-constexpr.
* doc/gcc/gcc-command-options/options-controlling-c++-dialect.rst:
Document -Winvalid-constexpr.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/constexpr-ctor2.C: Expect an error in c++20_down only.
* g++.dg/cpp0x/constexpr-default-ctor.C: Likewise.
* g++.dg/cpp0x/constexpr-diag3.C: Likewise.
* g++.dg/cpp0x/constexpr-ex1.C: Likewise.
* g++.dg/cpp0x/constexpr-friend.C: Likewise.
* g++.dg/cpp0x/constexpr-generated1.C: Likewise.
* g++.dg/cpp0x/constexpr-ice5.C: Likewise.
* g++.dg/cpp0x/constexpr-ice6.C: Likewise.
* g++.dg/cpp0x/constexpr-memfn1.C: Likewise.
* g++.dg/cpp0x/constexpr-neg2.C: Likewise.
* g++.dg/cpp0x/constexpr-non-const-arg.C: Likewise.
* g++.dg/cpp0x/constexpr-reinterpret1.C: Likewise.
* g++.dg/cpp0x/pr65327.C: Likewise.
* g++.dg/cpp1y/constexpr-105050.C: Likewise.
* g++.dg/cpp1y/constexpr-89285-2.C: Likewise.
* g++.dg/cpp1y/constexpr-89285.C: Likewise.
* g++.dg/cpp1y/constexpr-89785-2.C: Likewise.
* g++.dg/cpp1y/constexpr-local4.C: Likewise.
* g++.dg/cpp1y/constexpr-neg1.C: Likewise.
* g++.dg/cpp1y/constexpr-nsdmi7b.C: Likewise.
* g++.dg/cpp1y/constexpr-throw.C: Likewise.
* g++.dg/cpp23/constexpr-nonlit3.C: Remove dg-error.
* g++.dg/cpp23/constexpr-nonlit6.C: Expect an err

Re: [committed] wwwdocs: codingconventions: Properly link to flake8

[Martin Liška]

On 11/1/22 13:01, Gerald Pfeifer wrote:
> Nearly all hrefs= on our site are https:// or http://, and that's the case 
> pretty much across the web. Still the protocol needs to be provided for 
> links to work.

Makes sense, thanks!

Martin

> 
> Pushed.
> 
> Gerald
> 
> 
> Web links need to be prefixed by https:// or http://.
> ---
>  htdocs/codingconventions.html | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/htdocs/codingconventions.html b/htdocs/codingconventions.html
> index f5e22983..348f1e1d 100644
> --- a/htdocs/codingconventions.html
> +++ b/htdocs/codingconventions.html
> @@ -1487,7 +1487,7 @@ Definitions within the body of a namespace are not 
> indented.
>  Python Language Conventions
>  
>  Python scripts should follow  href="https://peps.python.org/pep-0008/";>PEP 8 ??? Style Guide for Python 
> Code
> -which can be verified by the flake8 tool.
> +which can be verified by the https://flake8.pycqa.org";>flake8 
> tool.
>  We recommend using the following flake8 plug-ins:
>  
>  

Re: [PATCH] Fix doc typo

[Martin Liška]

On 11/9/22 08:51, Richard Biener via Gcc-patches wrote:
> On Wed, Nov 9, 2022 at 4:29 AM Sinan via Gcc-patches
>  wrote:
>>
>> add a missing variable name.
> 
> OK.

I've just pushed the change.

Martin

Re: [PATCH] match.pd: rewrite select to branchless expression

[Michael Collison]

Richard,

Thanks for your feedback. I want to make sure I am following what you 
are recommending. Are you suggesting changing:


(for op (bit_xor bit_ior)
(simplify
(cond (eq (bit_and @0 integer_onep@1)
integer_zerop)
@2
(op:c @3 @2))
(if (INTEGRAL_TYPE_P (type)
&& (INTEGRAL_TYPE_P (TREE_TYPE (@0
(op (bit_and (negate (convert:type (bit_and @0 @1))) @3) @2


to

(for op (bit_xor bit_ior)
 (simplify
  (cond (eq zero_one_valued_p@0
    integer_zerop)
    @1
    (op:c @2 @1))
  (if (INTEGRAL_TYPE_P (type)
   && (INTEGRAL_TYPE_P (TREE_TYPE (@0
   (op (bit_and (negate (convert:type (bit_and @0 { build_one_cst 
(type); }))) @2) @1



On 11/9/22 02:41, Richard Biener wrote:

On Tue, Nov 8, 2022 at 9:02 PM Michael Collison  wrote:

This patches transforms (cond (and (x , 0x1) == 0), y, (z op y)) into
(-(and (x , 0x1)) & z ) op y, where op is a '^' or a '|'. It also
transforms (cond (and (x , 0x1) != 0), (z op y), y ) into (-(and (x ,
0x1)) & z ) op y.

Matching this patterns allows GCC to generate branchless code for one of
the functions in coremark.

Bootstrapped and tested on x86 and RISC-V. Okay?

Michael.

2022-11-08  Michael Collison  

  * match.pd ((cond (and (x , 0x1) == 0), y, (z op y) )
  -> (-(and (x , 0x1)) & z ) op y)

2022-11-08  Michael Collison  

  * gcc.dg/tree-ssa/branchless-cond.c: New test.

---
   gcc/match.pd  | 22 
   .../gcc.dg/tree-ssa/branchless-cond.c | 26 +++
   2 files changed, 48 insertions(+)
   create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/branchless-cond.c

diff --git a/gcc/match.pd b/gcc/match.pd
index 194ba8f5188..722f517ac6d 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -3486,6 +3486,28 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
 (cond (le @0 integer_zerop@1) (negate@2 @0) integer_zerop@1)
 (max @2 @1))

+/* (cond (and (x , 0x1) == 0), y, (z ^ y) ) -> (-(and (x , 0x1)) & z )
^ y */

Please write the match as a C expression in the comment, as present
it's a weird mix.  So x & 0x1 == 0 ? y : z  y -> (-(typeof(y))(x &
0x1) & z)  y


+(for op (bit_xor bit_ior)
+ (simplify
+  (cond (eq (bit_and @0 integer_onep@1)
+integer_zerop)
+@2
+(op:c @3 @2))
+  (if (INTEGRAL_TYPE_P (type)
+   && (INTEGRAL_TYPE_P (TREE_TYPE (@0
+   (op (bit_and (negate (convert:type (bit_and @0 @1))) @3) @2

Since you are literally keeping (bit_and @0 @1) and not matching @0 with
anything I suspect you could instead use

  (simplify (cond (eq zero_one_valued_p@0 integer_zerop) ...

eventually extending that to cover bit_and with one.  Do you need to guard
this against 'type' being a signed/unsigned 1-bit precision integer?


+
+/* (cond (and (x , 0x1) != 0), (z ^ y), y ) -> (-(and (x , 0x1)) & z )
^ y */
+(for op (bit_xor bit_ior)
+ (simplify
+  (cond (ne (bit_and @0 integer_onep@1)
+integer_zerop)
+(op:c @3 @2)
+@2)
+  (if (INTEGRAL_TYPE_P (type)
+   && (INTEGRAL_TYPE_P (TREE_TYPE (@0
+   (op (bit_and (negate (convert:type (bit_and @0 @1))) @3) @2
+
   /* Simplifications of shift and rotates.  */

   (for rotate (lrotate rrotate)
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/branchless-cond.c
b/gcc/testsuite/gcc.dg/tree-ssa/branchless-cond.c
new file mode 100644
index 000..68087ae6568
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/branchless-cond.c
@@ -0,0 +1,26 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-optimized" } */
+
+int f1(unsigned int x, unsigned int y, unsigned int z)
+{
+  return ((x & 1) == 0) ? y : z ^ y;
+}
+
+int f2(unsigned int x, unsigned int y, unsigned int z)
+{
+  return ((x & 1) != 0) ? z ^ y : y;
+}
+
+int f3(unsigned int x, unsigned int y, unsigned int z)
+{
+  return ((x & 1) == 0) ? y : z | y;
+}
+
+int f4(unsigned int x, unsigned int y, unsigned int z)
+{
+  return ((x & 1) != 0) ? z | y : y;
+}
+
+/* { dg-final { scan-tree-dump-times " -" 4 "optimized" } } */
+/* { dg-final { scan-tree-dump-times " & " 8 "optimized" } } */
+/* { dg-final { scan-tree-dump-not "if" "optimized" } } */
--
2.34.1

[PATCH] doc: Use a separate directory for new modules we add to PATH

[Arsen Arsenović via Gcc-patches]

ChangeLog:

* doc/baseconf.py: Inject dirname(__file__)/'modules' to path
instead of just ``.''.
* doc/gcc_sphinx.py: Moved to...
* doc/modules/gcc_sphinx.py: ...here.
---
Evening,

This patch addresses a path mixup and provides a nice compromise between
convenience for the user and namespace cleanliness.  Further modules
that Sphinx imports internally from the GCC tree should also go into
this directory.  I moved gcc_sphinx since I knew of that one, but there
could be others I'm missing.

Tested on x86_64-pc-linux-gnu with ``make html''.

Have a great night!

 doc/baseconf.py | 4 +++-
 doc/{ => modules}/gcc_sphinx.py | 0
 2 files changed, 3 insertions(+), 1 deletion(-)
 rename doc/{ => modules}/gcc_sphinx.py (100%)

diff --git a/doc/baseconf.py b/doc/baseconf.py
index 47e3a126416..d85659e4540 100644
--- a/doc/baseconf.py
+++ b/doc/baseconf.py
@@ -13,7 +13,6 @@
 import os
 import time
 import sys
-# sys.path.insert(0, os.path.abspath('.'))
 
 # gccint needs a deeper stack limit
 sys.setrecursionlimit(2000)
@@ -23,8 +22,11 @@ sys.setrecursionlimit(2000)
 # The full version, including alpha/beta/rc tags
 
 folder = os.path.dirname(os.path.realpath(__file__))
+doc_modules = os.path.join(folder, 'modules')
 gcc_srcdir = os.path.join(folder, '..', 'gcc')
 
+sys.path.insert(0, doc_modules)
+
 def read_file(name):
 path = os.path.join(gcc_srcdir, name)
 if os.path.exists(path):
diff --git a/doc/gcc_sphinx.py b/doc/modules/gcc_sphinx.py
similarity index 100%
rename from doc/gcc_sphinx.py
rename to doc/modules/gcc_sphinx.py
-- 
2.38.1

[PATCH v2] doc: Remove outdated reference to "core" and front-end downloads

[Jonathan Wakely via Gcc-patches]

Patch rebased on the new doc format. I haven't tested building the docs
this way, but this is just plain text here.

OK for trunk?

-- >8 --

gcc/ChangeLog:

* doc/install/testing.rst: Remove anachronism about separate
source tarballs.
---
 gcc/doc/install/testing.rst | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/gcc/doc/install/testing.rst b/gcc/doc/install/testing.rst
index 4ae17688440..58d93cc4378 100644
--- a/gcc/doc/install/testing.rst
+++ b/gcc/doc/install/testing.rst
@@ -22,9 +22,7 @@ but it can give you confidence in your new GCC installation 
or point out
 problems before you install and start using your new GCC.
 
 First, you must have :ref:`downloaded the testsuites `.
-These are part of the full distribution, but if you downloaded the
-'core' compiler plus any front ends, you must download the testsuites
-separately.
+These are included in the source tarball.
 
 Second, you must have the testing tools installed.  This includes
 `DejaGnu `_, Tcl, and Expect;
-- 
2.38.1

Re: [DOCS] sphinx: use new Sphinx links

[Gerald Pfeifer]

On Wed, 9 Nov 2022, Martin Liška wrote:
> Gerald, can you please propagate changes I made to:
> htdocs/style.mhtml file?

Done. All pages live on gcc.gnu.org should be udpated now.

(I'm at a conference and have been offline during daytime this week so 
far. If you want to run further changes, Friday and Monday should work 
fine.)

Gerald

Re: [PATCH] doc: Use a separate directory for new modules we add to PATH

[David Malcolm via Gcc-patches]

On Wed, 2022-11-09 at 22:31 +0100, Arsen Arsenović via Gcc-patches
wrote:
> ChangeLog:
> 
> * doc/baseconf.py: Inject dirname(__file__)/'modules' to path
> instead of just ``.''.
> * doc/gcc_sphinx.py: Moved to...
> * doc/modules/gcc_sphinx.py: ...here.
> ---
> Evening,
> 
> This patch addresses a path mixup 

FWIW this patch fixes the build of the docs for me; without it I run
into the "Could not import extension gcc_sphinx (exception: No module
named 'gcc_sphinx')" issue we were discussing on IRC.

Thanks!
Dave

> and provides a nice compromise between
> convenience for the user and namespace cleanliness.  Further modules
> that Sphinx imports internally from the GCC tree should also go into
> this directory.  I moved gcc_sphinx since I knew of that one, but
> there
> could be others I'm missing.
> 
> Tested on x86_64-pc-linux-gnu with ``make html''.
> 
> Have a great night!
> 
>  doc/baseconf.py | 4 +++-
>  doc/{ => modules}/gcc_sphinx.py | 0
>  2 files changed, 3 insertions(+), 1 deletion(-)
>  rename doc/{ => modules}/gcc_sphinx.py (100%)
> 
> diff --git a/doc/baseconf.py b/doc/baseconf.py
> index 47e3a126416..d85659e4540 100644
> --- a/doc/baseconf.py
> +++ b/doc/baseconf.py
> @@ -13,7 +13,6 @@
>  import os
>  import time
>  import sys
> -# sys.path.insert(0, os.path.abspath('.'))
>  
>  # gccint needs a deeper stack limit
>  sys.setrecursionlimit(2000)
> @@ -23,8 +22,11 @@ sys.setrecursionlimit(2000)
>  # The full version, including alpha/beta/rc tags
>  
>  folder = os.path.dirname(os.path.realpath(__file__))
> +doc_modules = os.path.join(folder, 'modules')
>  gcc_srcdir = os.path.join(folder, '..', 'gcc')
>  
> +sys.path.insert(0, doc_modules)
> +
>  def read_file(name):
>  path = os.path.join(gcc_srcdir, name)
>  if os.path.exists(path):
> diff --git a/doc/gcc_sphinx.py b/doc/modules/gcc_sphinx.py
> similarity index 100%
> rename from doc/gcc_sphinx.py
> rename to doc/modules/gcc_sphinx.py

[committed] analyzer: better logging of event creation

[David Malcolm via Gcc-patches]

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r13-3867-g965ce1ba392ca0.

gcc/analyzer/ChangeLog:
* checker-path.cc (checker_event::debug): New.
(checker_path::add_event): Move here from checker-path.h.  Add
logging.
* checker-path.h (checker_event::debug): New decl.
(checker_path::checker_path): Add logger param.
(checker_path::add_event): Move definition from here to
checker-path.cc.
(checker_path::m_logger): New field.
* diagnostic-manager.cc
(diagnostic_manager::emit_saved_diagnostic): Pass logger to
checker_path ctor.
(diagnostic_manager::add_events_for_eedge): Log scope when
processing a run of stmts.

Signed-off-by: David Malcolm 
---
 gcc/analyzer/checker-path.cc   | 29 +
 gcc/analyzer/checker-path.h| 10 +-
 gcc/analyzer/diagnostic-manager.cc |  3 ++-
 3 files changed, 36 insertions(+), 6 deletions(-)

diff --git a/gcc/analyzer/checker-path.cc b/gcc/analyzer/checker-path.cc
index 40f9ccfe08f..ffab91c26ff 100644
--- a/gcc/analyzer/checker-path.cc
+++ b/gcc/analyzer/checker-path.cc
@@ -204,6 +204,20 @@ checker_event::dump (pretty_printer *pp) const
 get_location ());
 }
 
+/* Dump this event to stderr (for debugging/logging purposes).  */
+
+DEBUG_FUNCTION void
+checker_event::debug () const
+{
+  pretty_printer pp;
+  pp_format_decoder (&pp) = default_tree_printer;
+  pp_show_color (&pp) = pp_show_color (global_dc->printer);
+  pp.buffer->stream = stderr;
+  dump (&pp);
+  pp_newline (&pp);
+  pp_flush (&pp);
+}
+
 /* Hook for being notified when this event has its final id EMISSION_ID
and is about to emitted for PD.
 
@@ -1228,6 +1242,21 @@ checker_path::maybe_log (logger *logger, const char 
*desc) const
 }
 }
 
+void
+checker_path::add_event (std::unique_ptr event)
+{
+  if (m_logger)
+{
+  m_logger->start_log_line ();
+  m_logger->log_partial ("added event[%i]: %s ",
+m_events.length (),
+event_kind_to_string (event.get ()->m_kind));
+  event.get ()->dump (m_logger->get_printer ());
+  m_logger->end_log_line ();
+}
+  m_events.safe_push (event.release ());
+}
+
 /* Print a multiline form of this path to STDERR.  */
 
 DEBUG_FUNCTION void
diff --git a/gcc/analyzer/checker-path.h b/gcc/analyzer/checker-path.h
index c8de5c9be2c..46f4875f541 100644
--- a/gcc/analyzer/checker-path.h
+++ b/gcc/analyzer/checker-path.h
@@ -118,6 +118,7 @@ public:
   }
 
   void dump (pretty_printer *pp) const;
+  void debug () const;
 
   void set_location (location_t loc) { m_loc = loc; }
 
@@ -607,7 +608,7 @@ private:
 class checker_path : public diagnostic_path
 {
 public:
-  checker_path () : diagnostic_path () {}
+  checker_path (logger *logger) : diagnostic_path (), m_logger (logger) {}
 
   /* Implementation of diagnostic_path vfuncs.  */
 
@@ -631,10 +632,7 @@ public:
 
   void maybe_log (logger *logger, const char *desc) const;
 
-  void add_event (std::unique_ptr event)
-  {
-m_events.safe_push (event.release ());
-  }
+  void add_event (std::unique_ptr event);
 
   void delete_event (int idx)
   {
@@ -711,6 +709,8 @@ private:
  exploded_node *, so that rewind events can refer to them in their
  descriptions.  */
   hash_map  m_setjmp_event_ids;
+
+  logger *m_logger;
 };
 
 } // namespace ana
diff --git a/gcc/analyzer/diagnostic-manager.cc 
b/gcc/analyzer/diagnostic-manager.cc
index e77547567c1..74cc7369d77 100644
--- a/gcc/analyzer/diagnostic-manager.cc
+++ b/gcc/analyzer/diagnostic-manager.cc
@@ -1356,7 +1356,7 @@ diagnostic_manager::emit_saved_diagnostic (const 
exploded_graph &eg,
 
   /* This is the diagnostic_path subclass that will be built for
  the diagnostic.  */
-  checker_path emission_path;
+  checker_path emission_path (get_logger ());
 
   /* Populate emission_path with a full description of EPATH.  */
   build_emission_path (pb, *epath, &emission_path);
@@ -1963,6 +1963,7 @@ diagnostic_manager::add_events_for_eedge (const 
path_builder &pb,
   events for them.  */
if (dst_state.m_region_model)
  {
+   log_scope s (get_logger (), "processing run of stmts");
program_state iter_state (dst_state);
program_point iter_point (dst_point);
while (1)
-- 
2.26.3

[PATCH] RISC-V: Optimise adding a (larger than simm12) constant

[Philipp Tomsich]

Handling the register-const_int addition has very quickly escalated to
creating a full sign-extended 32bit constant and performing a
register-register for RISC-V in GCC so far, resulting in sequences like
(for the case of "a + 2048"):
li  a5,4096
addia5,a5,-2048
add a0,a0,a5

By adding an expansion for add3, we can emit optimised RTL that
matches the capabilities of RISC-V better by adding support for the
following, previously unoptimised cases:
  - addi + addi
addia0,a0,2047
addia0,a0,1
  - li + sh[123]add (if Zba is enabled)
li  a5,960
sh3add  a0,a5,a0

With this commit, we also fix up riscv_adjust_libcall_cfi_prologue()
and riscv_adjust_libcall_cfi_epilogue() to not use gen_add3_insn, as
the expander will otherwise wrap the resulting set-expression in an
insn (causing an ICE at dwarf2-time) when invoked with -msave-restore.

This closes the gap to LLVM, which has already been emitting these
optimised sequences.

Note that this benefits is perlbench (in SPEC CPU 2017), which needs
to add the constant 3840.

gcc/ChangeLog:

* config/riscv/bitmanip.md (*shNadd): Rename.
(riscv_shNadd): Expose as gen_riscv_shNadd{di/si}.
* config/riscv/predicates.md (const_arith_shifted123_operand):
New predicate (for constants that are a simm12, shifted by
1, 2 or 3).
(const_arith_2simm12_operand): New predicate (that can be
expressed by adding 2 simm12 together).
(addi_operand): New predicate (an immedaite operand suitable
for the new add3 expansion).
* config/riscv/riscv.cc (riscv_adjust_libcall_cfi_prologue):
Don't use gen_add3_insn, where a RTX instead of an INSN is
required (otherwise this will break as soon as we have a
define_expand for add3).
(riscv_adjust_libcall_cfi_epilogue): Same.
* config/riscv/riscv.md (addsi3): Rename.
(riscv_addsi3): New name for addsi3.
(adddi3): Rename.
(riscv_adddi3): New name for adddi3.
(add3): New expander that handles the basic and fancy
(such as li+sh[123]add, addi+addi, ...) cases for adding
register-register and register-const_int.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/addi.c: New test.
* gcc.target/riscv/zba-shNadd-06.c: New test.

Signed-off-by: Philipp Tomsich 
---

 gcc/config/riscv/bitmanip.md  |  2 +-
 gcc/config/riscv/predicates.md| 28 +
 gcc/config/riscv/riscv.cc | 10 ++--
 gcc/config/riscv/riscv.md | 58 ++-
 gcc/testsuite/gcc.target/riscv/addi.c | 39 +
 .../gcc.target/riscv/zba-shNadd-06.c  | 11 
 6 files changed, 141 insertions(+), 7 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/riscv/addi.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/zba-shNadd-06.c

diff --git a/gcc/config/riscv/bitmanip.md b/gcc/config/riscv/bitmanip.md
index bb23ceb86d9..78fdf02c2ec 100644
--- a/gcc/config/riscv/bitmanip.md
+++ b/gcc/config/riscv/bitmanip.md
@@ -29,7 +29,7 @@
   [(set_attr "type" "bitmanip,load")
(set_attr "mode" "DI")])
 
-(define_insn "*shNadd"
+(define_insn "riscv_shNadd"
   [(set (match_operand:X 0 "register_operand" "=r")
(plus:X (ashift:X (match_operand:X 1 "register_operand" "r")
  (match_operand:QI 2 "imm123_operand" "Ds3"))
diff --git a/gcc/config/riscv/predicates.md b/gcc/config/riscv/predicates.md
index 6772228e5b6..c56bfa99339 100644
--- a/gcc/config/riscv/predicates.md
+++ b/gcc/config/riscv/predicates.md
@@ -308,3 +308,31 @@
 (match_test "INTVAL (op) > 0")))
(ior (match_test "SMALL_OPERAND (UINTVAL (op) & ~(HOST_WIDE_INT_1U << 
floor_log2 (UINTVAL (op")
(match_test "popcount_hwi (UINTVAL (op)) == 2"
+
+;; A CONST_INT that can be shifted down by 1, 2 or 3 bits (i.e., has
+;; these bits clear) and will then form a SMALL_OPERAND.
+(define_predicate "const_arith_shifted123_operand"
+  (and (match_code "const_int")
+   (not (match_test "SMALL_OPERAND (INTVAL (op))")))
+{
+  HOST_WIDE_INT val = INTVAL (op);
+  int trailing = ctz_hwi (val);
+
+  /* Clamp to 3, as we have sh[123]add instructions only. */
+  if (trailing > 3)
+ trailing = 3;
+
+  return trailing > 0 && SMALL_OPERAND (val >> trailing);
+})
+
+;; A CONST_INT that can formed by adding two SMALL_OPERANDs together
+(define_predicate "const_arith_2simm12_operand"
+  (and (match_code "const_int")
+   (ior (match_test "SMALL_OPERAND(INTVAL (op) - ~(HOST_WIDE_INT_M1U << 
(IMM_BITS - 1)))")
+   (match_test "SMALL_OPERAND(INTVAL (op) -  (HOST_WIDE_INT_M1U << 
(IMM_BITS - 1)))"
+
+(define_predicate "addi_operand"
+  (ior (match_operand 0 "arith_operand")
+   (match_operand 0 "const_arith_2simm12_operand")
+   (and (match_operand 0 "const_arith_shifted123_operand")
+   (match_test "TARGET_ZBA")))

[PATCH] RISC-V: Implement movmisalign to enable SLP

[Philipp Tomsich]

The default implementation of support_vector_misalignment() checks
whether movmisalign is present for the requested mode.  This
will be used by vect_supportable_dr_alignment() to determine whether a
misaligned access of vectorized data is permissible.

For RISC-V this is required to convert multiple integer data refs,
such as "c[1] << 8) | c[0]" into a larger (in the example before: a
halfword load) access.
We conditionalize on !riscv_slow_unaligned_access_p to allow the
misaligned refs, if they are not expected to be slow.

This benefits both xalancbmk and blender on SPEC CPU 2017.

gcc/ChangeLog:

* config/riscv/riscv.md (movmisalign): Implement.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/movmisalign-1.c: New test.
* gcc.target/riscv/movmisalign-2.c: New test.
* gcc.target/riscv/movmisalign-3.c: New test.

Signed-off-by: Philipp Tomsich 
---

 gcc/config/riscv/riscv.md  | 18 ++
 gcc/testsuite/gcc.target/riscv/movmisalign-1.c | 12 
 gcc/testsuite/gcc.target/riscv/movmisalign-2.c | 12 
 gcc/testsuite/gcc.target/riscv/movmisalign-3.c | 12 
 4 files changed, 54 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/riscv/movmisalign-1.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/movmisalign-2.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/movmisalign-3.c

diff --git a/gcc/config/riscv/riscv.md b/gcc/config/riscv/riscv.md
index 289ff7470c6..1b357a9c57f 100644
--- a/gcc/config/riscv/riscv.md
+++ b/gcc/config/riscv/riscv.md
@@ -1715,6 +1715,24 @@
  MAX_MACHINE_MODE, &operands[3], TRUE);
 })
 
+;; Misaligned (integer) moves: provide an implementation for
+;; movmisalign, so the default support_vector_misalignment() will
+;; return the right boolean depending on whether
+;; riscv_slow_unaligned_access_p is set or not.
+;;
+;; E.g., this is needed for SLP to convert "c[1] << 8) | c[0]" into a
+;; HImode load (a good test case will be blender and xalancbmk in SPEC
+;; CPU 2017).
+;;
+(define_expand "movmisalign"
+  [(set (match_operand:ANYI 0 "")
+   (match_operand:ANYI 1 ""))]
+  "!riscv_slow_unaligned_access_p"
+{
+  if (riscv_legitimize_move (mode, operands[0], operands[1]))
+DONE;
+})
+
 ;; 64-bit integer moves
 
 (define_expand "movdi"
diff --git a/gcc/testsuite/gcc.target/riscv/movmisalign-1.c 
b/gcc/testsuite/gcc.target/riscv/movmisalign-1.c
new file mode 100644
index 000..791a3d63335
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/movmisalign-1.c
@@ -0,0 +1,12 @@
+/* { dg-do compile } */
+/* { dg-options "-march=rv64gc -mabi=lp64 -mtune=size" } */
+/* { dg-skip-if "" { *-*-* } { "-O0" "-Og" "-O1" } } */
+
+void f(unsigned short *sink, unsigned char *arr)
+{
+  *sink = (arr[1] << 8) | arr[0];
+}
+
+/* { dg-final { scan-assembler-times "lhu\t" 1 } } */
+/* { dg-final { scan-assembler-not "lbu\t" } } */
+
diff --git a/gcc/testsuite/gcc.target/riscv/movmisalign-2.c 
b/gcc/testsuite/gcc.target/riscv/movmisalign-2.c
new file mode 100644
index 000..ef73dcb2d9d
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/movmisalign-2.c
@@ -0,0 +1,12 @@
+/* { dg-do compile } */
+/* { dg-options "-march=rv64gc -mabi=lp64 -mtune=size -mstrict-align" } */
+/* { dg-skip-if "" { *-*-* } { "-O0" "-Og" "-O1" } } */
+
+void f(unsigned short *sink, unsigned char *arr)
+{
+  *sink = (arr[1] << 8) | arr[0];
+}
+
+/* { dg-final { scan-assembler-times "lbu\t" 2 } } */
+/* { dg-final { scan-assembler-not "lhu\t" } } */
+
diff --git a/gcc/testsuite/gcc.target/riscv/movmisalign-3.c 
b/gcc/testsuite/gcc.target/riscv/movmisalign-3.c
new file mode 100644
index 000..963b11c27fd
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/movmisalign-3.c
@@ -0,0 +1,12 @@
+/* { dg-do compile } */
+/* { dg-options "-march=rv64gc -mabi=lp64 -mtune=rocket" } */
+/* { dg-skip-if "" { *-*-* } { "-O0" "-Og" "-O1" } } */
+
+void f(unsigned short *sink, unsigned char *arr)
+{
+  *sink = (arr[1] << 8) | arr[0];
+}
+
+/* { dg-final { scan-assembler-times "lbu\t" 2 } } */
+/* { dg-final { scan-assembler-not "lhu\t" } } */
+
-- 
2.34.1

[PATCH] ifcombine: recognize single bit test of sign-bit

[Philipp Tomsich]

Our ifcombine pass combines 2 single-bit tests into a single test of
the form "(a & T) == T".

However, detection of the bit-tests does not work for sign-bits (of
any mode) as the RTL presented to the pass uses a cast to a
signed-type and an order-operator.  E.g., the test for 'a & 0x80'
presents as:
_1 = *a_5(D);
_2 = (signed char) _1;
if (_2 < 0)
  goto ;
else
  goto ;

This adds detection logic to recognize_single_bit_test() for this case
and reports it as a single-bit test.

gcc/ChangeLog:

* tree-ssa-ifcombine.cc (recognize_single_bit_test): Add
  detection for tests against the sign-bit of the relevant
  type as a single-bit test.

gcc/testsuite/ChangeLog:

* gcc.dg/tree-ssa/ssa-ifcombine-14.c: New test.

Signed-off-by: Philipp Tomsich 
---

 .../gcc.dg/tree-ssa/ssa-ifcombine-14.c| 14 +
 gcc/tree-ssa-ifcombine.cc | 20 +++
 2 files changed, 34 insertions(+)
 create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/ssa-ifcombine-14.c

diff --git a/gcc/testsuite/gcc.dg/tree-ssa/ssa-ifcombine-14.c 
b/gcc/testsuite/gcc.dg/tree-ssa/ssa-ifcombine-14.c
new file mode 100644
index 000..f9b1115a34a
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/ssa-ifcombine-14.c
@@ -0,0 +1,14 @@
+/* { dg-do compile } */
+/* { dg-options "-O -fdump-tree-ifcombine-details-blocks" } */
+
+void sink();
+
+void same(unsigned char *a)
+{
+  if (*a & 0x80)
+if (*a & 0x40)
+  g();
+}
+
+/* { dg-final { scan-tree-dump "optimizing double bit test" } } */
+
diff --git a/gcc/tree-ssa-ifcombine.cc b/gcc/tree-ssa-ifcombine.cc
index 80c41c45489..cd6331f84db 100644
--- a/gcc/tree-ssa-ifcombine.cc
+++ b/gcc/tree-ssa-ifcombine.cc
@@ -225,6 +225,26 @@ recognize_single_bit_test (gcond *cond, tree *name, tree 
*bit, bool inv)
 {
   gimple *stmt;
 
+  /* Handle the test for a sign-bit:
+   unsigned charD.15 _1;
+   _2 = (signed char) _1;
+   if (_2 < 0) */
+  if (TREE_CODE (gimple_cond_lhs (cond)) == SSA_NAME
+  && !TYPE_UNSIGNED (TREE_TYPE (gimple_cond_lhs (cond)))
+  && gimple_cond_code (cond) == (inv ? GE_EXPR : LT_EXPR)
+  && integer_zerop (gimple_cond_rhs (cond)))
+{
+  tree type = TREE_TYPE (gimple_cond_lhs (cond));
+
+  stmt = SSA_NAME_DEF_STMT (gimple_cond_lhs (cond));
+  if (!is_gimple_assign (stmt))
+   return false;
+  *name = gimple_assign_rhs1 (stmt);
+  *bit = build_int_cst (integer_type_node, TYPE_PRECISION (type) - 1);
+
+  return true;
+}
+
   /* Get at the definition of the result of the bit test.  */
   if (gimple_cond_code (cond) != (inv ? EQ_EXPR : NE_EXPR)
   || TREE_CODE (gimple_cond_lhs (cond)) != SSA_NAME
-- 
2.34.1

[PATCH] ifcombine: fold two bit tests with different polarity

[Philipp Tomsich]

Our ifcombine pass combines 2 single-bit tests into a single test of
the form "(a & T) == T", requiring the same polarity (i.e., tests for
bit set/cleared) for both bit-tests.  However some applications test
against two bits expecting one set and the other cleared.

This adds support for the case "(a & T) == C" where T is a constant
with 2 bits set and C has only one of those bits set.

gcc/ChangeLog:

* tree-ssa-ifcombine.cc (ifcombine_ifandif): Add support for
  combining two bit-tests that test for bits of different
  polarity.

gcc/testsuite/ChangeLog:

* gcc.dg/tree-ssa/ssa-ifcombine-15.c: New test.

Signed-off-by: Philipp Tomsich 
---

 .../gcc.dg/tree-ssa/ssa-ifcombine-15.c| 14 +
 gcc/tree-ssa-ifcombine.cc | 56 +++
 2 files changed, 70 insertions(+)
 create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/ssa-ifcombine-15.c

diff --git a/gcc/testsuite/gcc.dg/tree-ssa/ssa-ifcombine-15.c 
b/gcc/testsuite/gcc.dg/tree-ssa/ssa-ifcombine-15.c
new file mode 100644
index 000..081faa39628
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/ssa-ifcombine-15.c
@@ -0,0 +1,14 @@
+/* { dg-do compile } */
+/* { dg-options "-O -fdump-tree-ifcombine-details-blocks" } */
+
+void sink();
+
+void reversed(unsigned char *a)
+{
+  if (*a & 0x60)
+if (!(*a & 0x02))
+  g();
+}
+
+/* { dg-final { scan-tree-dump "optimizing double bit test" } } */
+
diff --git a/gcc/tree-ssa-ifcombine.cc b/gcc/tree-ssa-ifcombine.cc
index cd6331f84db..ea49cc2bff1 100644
--- a/gcc/tree-ssa-ifcombine.cc
+++ b/gcc/tree-ssa-ifcombine.cc
@@ -498,6 +498,62 @@ ifcombine_ifandif (basic_block inner_cond_bb, bool 
inner_inv,
   return true;
 }
 
+  /* See if we test polarity-reversed single bits of the same name in
+ both tests.  In that case remove the outer test, merging both
+ else edges, and change the inner one to test for
+   name & (bit1 | bit2) == (bit2).  */
+  else if ((recognize_single_bit_test (inner_cond, &name1, &bit1, !inner_inv)
+   && recognize_single_bit_test (outer_cond, &name2, &bit2, outer_inv)
+   && name1 == name2)
+  || (recognize_single_bit_test (inner_cond, &name2, &bit2, inner_inv)
+  && recognize_single_bit_test (outer_cond, &name1, &bit1, 
!outer_inv)
+  && name1 == name2))
+{
+  tree t, t2, t3;
+
+  /* Do it.  */
+  gsi = gsi_for_stmt (inner_cond);
+  t = fold_build2 (LSHIFT_EXPR, TREE_TYPE (name1),
+  build_int_cst (TREE_TYPE (name1), 1), bit1);
+  t2 = fold_build2 (LSHIFT_EXPR, TREE_TYPE (name1),
+   build_int_cst (TREE_TYPE (name1), 1), bit2);
+  t = fold_build2 (BIT_IOR_EXPR, TREE_TYPE (name1), t, t2);
+  t = force_gimple_operand_gsi (&gsi, t, true, NULL_TREE,
+   true, GSI_SAME_STMT);
+  t3 = fold_build2 (BIT_AND_EXPR, TREE_TYPE (name1), name1, t);
+  t3 = force_gimple_operand_gsi (&gsi, t3, true, NULL_TREE,
+true, GSI_SAME_STMT);
+  t = fold_build2 (result_inv ? NE_EXPR : EQ_EXPR,
+  boolean_type_node, t2, t3);
+  t = canonicalize_cond_expr_cond (t);
+  if (!t)
+   return false;
+  gimple_cond_set_condition_from_tree (inner_cond, t);
+  update_stmt (inner_cond);
+
+  /* Leave CFG optimization to cfg_cleanup.  */
+  gimple_cond_set_condition_from_tree (outer_cond,
+   outer_inv ? boolean_false_node : boolean_true_node);
+  update_stmt (outer_cond);
+
+  update_profile_after_ifcombine (inner_cond_bb, outer_cond_bb);
+
+  if (dump_file)
+   {
+ fprintf (dump_file, "optimizing double bit test to ");
+ print_generic_expr (dump_file, name1);
+ fprintf (dump_file, " & T == C\nwith temporary T = (1 << ");
+ print_generic_expr (dump_file, bit1);
+ fprintf (dump_file, ") | (1 << ");
+ print_generic_expr (dump_file, bit2);
+ fprintf (dump_file, ")\nand temporary C = (1 << ");
+ print_generic_expr (dump_file, bit2);
+ fprintf (dump_file, ")\n");
+   }
+
+  return true;
+}
+
   /* See if we have two bit tests of the same name in both tests.
  In that case remove the outer test and change the inner one to
  test for name & (bits1 | bits2) != 0.  */
-- 
2.34.1

[PATCH v2] [WIP] RISC-V: Replace zero_extendsidi2_shifted with generalized split

[Philipp Tomsich]

The current method of treating shifts of extended values on RISC-V
frequently causes sequences of 3 shifts, despite the presence of the
'zero_extendsidi2_shifted' pattern.

Consider:
unsigned long f(unsigned int a, unsigned long b)
{
a = a << 1;
unsigned long c = (unsigned long) a;
c = b + (c<<4);
return c;
}
which will present at combine-time as:
Trying 7, 8 -> 9:
7: r78:SI=r81:DI#0<<0x1
  REG_DEAD r81:DI
8: r79:DI=zero_extend(r78:SI)
  REG_DEAD r78:SI
9: r72:DI=r79:DI<<0x4
  REG_DEAD r79:DI
Failed to match this instruction:
(set (reg:DI 72 [ _1 ])
(and:DI (ashift:DI (reg:DI 81)
(const_int 5 [0x5]))
(const_int 68719476704 [0xfffe0])))
and produce the following (optimized) assembly:
f:
slliw   a5,a0,1
sllia5,a5,32
srlia5,a5,28
add a0,a5,a1
ret

The current way of handling this (in 'zero_extendsidi2_shifted')
doesn't apply for two reasons:
- this is seen before reload, and
- (more importantly) the constant mask is not 0xul.

To address this, we introduce a generalized version of shifting
zero-extended values that supports any mask of consecutive ones as
long as the number of training zeros is the inner shift-amount.

With this new split, we generate the following assembly for the
aforementioned function:
f:
sllia0,a0,33
srlia0,a0,28
add a0,a0,a1
ret

Unfortunately, all of this causes some fallout (especially in how it
interacts with Zb* extensions and zero_extract expressions formed
during combine): this is addressed through additional instruction
splitting and handling of zero_extract.

gcc/ChangeLog:

* config/riscv/bitmanip.md (*zext.w): Match a zext.w expressed
as an and:DI.
(*andi_add.uw): New pattern.
(*slli_slli_uw): New pattern.
(*shift_then_shNadd.uw): New pattern.
(*slliuw): Rename to riscv_slli_uw.
(riscv_slli_uw): Renamed from *slliuw.
(*zeroextract2_highbits): New pattern.
(*zero_extract): New pattern, which will be split to
shift-left + shift-right.
* config/riscv/predicates.md (dimode_shift_operand):
* config/riscv/riscv.md (*zero_extract_lowbits):
(zero_extendsidi2_shifted): Rename.
(*zero_extendsidi2_shifted): Generalize.
(*shift_truthvalue): New pattern.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/shift-shift-6.c: New test.
* gcc.target/riscv/shift-shift-7.c: New test.
* gcc.target/riscv/shift-shift-8.c: New test.
* gcc.target/riscv/shift-shift-9.c: New test.
* gcc.target/riscv/snez.c: New test.

Commit notes:
- Depends on a predicate posted in "RISC-V: Optimize branches testing
  a bit-range or a shifted immediate".  Depending on the order of
  applying these, I'll take care to pull that part out of the other
  patch if needed.

Version-changes: 2
- refactor
- optimise for additional corner cases and deal with fallout

Signed-off-by: Philipp Tomsich 
---

(no changes since v1)

 gcc/config/riscv/bitmanip.md  | 142 ++
 gcc/config/riscv/predicates.md|   5 +
 gcc/config/riscv/riscv.md |  75 +++--
 .../gcc.target/riscv/shift-shift-6.c  |  14 ++
 .../gcc.target/riscv/shift-shift-7.c  |  16 ++
 .../gcc.target/riscv/shift-shift-8.c  |  20 +++
 .../gcc.target/riscv/shift-shift-9.c  |  15 ++
 gcc/testsuite/gcc.target/riscv/snez.c |  14 ++
 8 files changed, 261 insertions(+), 40 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/riscv/shift-shift-6.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/shift-shift-7.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/shift-shift-8.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/shift-shift-9.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/snez.c

diff --git a/gcc/config/riscv/bitmanip.md b/gcc/config/riscv/bitmanip.md
index 78fdf02c2ec..06126ac4819 100644
--- a/gcc/config/riscv/bitmanip.md
+++ b/gcc/config/riscv/bitmanip.md
@@ -29,7 +29,20 @@
   [(set_attr "type" "bitmanip,load")
(set_attr "mode" "DI")])
 
-(define_insn "riscv_shNadd"
+;; We may end up forming a slli.uw with an immediate of 0 (while
+;; splitting through "*slli_slli_uw", below).
+;; Match this back to a zext.w
+(define_insn "*zext.w"
+  [(set (match_operand:DI 0 "register_operand" "=r")
+   (and:DI (ashift:DI (match_operand:DI 1 "register_operand" "r")
+  (const_int 0))
+   (const_int 4294967295)))]
+  "TARGET_64BIT && TARGET_ZBA"
+  "zext.w\t%0,%1"
+  [(set_attr "type" "bitmanip")
+   (set_attr "mode" "DI")])
+
+(define_insn "*shNadd"
   [(set (match_operand:X 0 "register_operand" "=r")
(plus:X (ashift:X (match_operand:X 1 "register_operand" "r")
  (match_ope