Re: [PATCH] PR106342 - IBM zSystems: Provide vsel for all vector modes

[Andreas Krebbel via Gcc-patches]

On 8/10/22 13:42, Ilya Leoshkevich wrote:
> On Wed, 2022-08-03 at 12:20 +0200, Ilya Leoshkevich wrote:
>> Bootstrapped and regtested on s390x-redhat-linux.  Ok for master?
>>
>>
>>
>> dg.exp=pr104612.c fails with an ICE on s390x, because copysignv2sf3
>> produces an insn that vsel is supposed to recognize, but can't,
>> because it's not defined for V2SF.  Fix by defining it for all vector
>> modes supported by copysign3.
>>
>> gcc/ChangeLog:
>>
>> * config/s390/vector.md (V_HW_FT): New iterator.
>> * config/s390/vx-builtins.md (vsel): Use V instead of
>> V_HW.
>> ---
>>  gcc/config/s390/vector.md  |  6 ++
>>  gcc/config/s390/vx-builtins.md | 12 ++--
>>  2 files changed, 12 insertions(+), 6 deletions(-)
> 
> Jakub pointed out that this is broken in gcc-12 as well.
> The patch applies cleanly, and I started a bootstrap/regtest.
> Ok for gcc-12?

Yes. Thanks!

Andreas

Re: [PATCH] RISC-V: Avoid redundant sign-extension for SImode SGE, SGEU, SLE, SLEU

[Kito Cheng via Gcc-patches]

LGTM, but with a nit, I don't get set.w but get an andi like below, so
maybe we should also scan-assembler-not andi? feel free to commit that
directly with that fix

```asm
sleu:
   sgtua0,a0,a1# 9 [c=4 l=4]  *sgtu_disi
   xoria0,a0,1 # 10[c=4 l=4]  *xorsi3_internal/1
   andia0,a0,1 # 16[c=4 l=4]  anddi3/1
   ret # 25[c=0 l=4]  simple_return
```

On Wed, Aug 3, 2022 at 5:54 PM Maciej W. Rozycki  wrote:
>
> We produce inefficient code for some synthesized SImode conditional set
> operations (i.e. ones that are not directly implemented in hardware) on
> RV64.  For example a piece of C code like this:
>
> int
> sleu (unsigned int x, unsigned int y)
> {
>   return x <= y;
> }
>
> gets compiled (at `-O2') to this:
>
> sleu:
> sgtua0,a0,a1# 9 [c=4 l=4]  *sgtu_disi
> xoria0,a0,1 # 10[c=4 l=4]  *xorsi3_internal/1
> sext.w  a0,a0   # 16[c=4 l=4]  extendsidi2/0
> ret # 25[c=0 l=4]  simple_return
>
> This is because the middle end expands a SLEU operation missing from
> RISC-V hardware into a sequence of a SImode SGTU operation followed by
> an explicit SImode XORI operation with immediate 1.  And while the SGTU
> machine instruction (alias SLTU with the input operands swapped) gives a
> properly sign-extended 32-bit result which is valid both as a SImode or
> a DImode operand the middle end does not see that through a SImode XORI
> operation, because we tell the middle end that the RISC-V target (unlike
> MIPS) may hold values in DImode integer registers that are valid for
> SImode operations even if not properly sign-extended.
>
> However the RISC-V psABI requires that 32-bit function arguments and
> results passed in 64-bit integer registers be properly sign-extended, so
> this is explicitly done at the conclusion of the function.
>
> Fix this by making the backend use a sequence of a DImode SGTU operation
> followed by a SImode SEQZ operation instead.  The latter operation is
> known by the middle end to produce a properly sign-extended 32-bit
> result and therefore combine gets rid of the sign-extension operation
> that follows and actually folds it into the very same XORI machine
> operation resulting in:
>
> sleu:
> sgtua0,a0,a1# 9 [c=4 l=4]  *sgtu_didi
> xoria0,a0,1 # 16[c=4 l=4]  xordi3/1
> ret # 25[c=0 l=4]  simple_return
>
> instead (although the SEQZ alias SLTIU against immediate 1 machine
> instruction would equally do and is actually retained at `-O0').  This
> is handled analogously for the remaining synthesized operations of this
> kind, i.e. `SLE', `SGEU', and `SGE'.
>
> gcc/
> * config/riscv/riscv.cc (riscv_emit_int_order_test): Use EQ 0
> rather that XOR 1 for LE and LEU operations.
>
> gcc/testsuite/
> * gcc.target/riscv/sge.c: New test.
> * gcc.target/riscv/sgeu.c: New test.
> * gcc.target/riscv/sle.c: New test.
> * gcc.target/riscv/sleu.c: New test.
> ---
> Hi,
>
>  Regression-tested with the `riscv64-linux-gnu' target.  OK to apply?
>
>   Maciej
> ---
>  gcc/config/riscv/riscv.cc |4 ++--
>  gcc/testsuite/gcc.target/riscv/sge.c  |   11 +++
>  gcc/testsuite/gcc.target/riscv/sgeu.c |   11 +++
>  gcc/testsuite/gcc.target/riscv/sle.c  |   11 +++
>  gcc/testsuite/gcc.target/riscv/sleu.c |   11 +++
>  5 files changed, 46 insertions(+), 2 deletions(-)
>
> gcc-riscv-int-order-inv-seqz.diff
> Index: gcc/gcc/config/riscv/riscv.cc
> ===
> --- gcc.orig/gcc/config/riscv/riscv.cc
> +++ gcc/gcc/config/riscv/riscv.cc
> @@ -2500,9 +2500,9 @@ riscv_emit_int_order_test (enum rtx_code
> }
>else if (invert_ptr == 0)
> {
> - rtx inv_target = riscv_force_binary (GET_MODE (target),
> + rtx inv_target = riscv_force_binary (word_mode,
>inv_code, cmp0, cmp1);
> - riscv_emit_binary (XOR, target, inv_target, const1_rtx);
> + riscv_emit_binary (EQ, target, inv_target, const0_rtx);
> }
>else
> {
> Index: gcc/gcc/testsuite/gcc.target/riscv/sge.c
> ===
> --- /dev/null
> +++ gcc/gcc/testsuite/gcc.target/riscv/sge.c
> @@ -0,0 +1,11 @@
> +/* { dg-do compile } */
> +/* { dg-require-effective-target rv64 } */
> +/* { dg-skip-if "" { *-*-* } { "-O0" } } */
> +
> +int
> +sge (int x, int y)
> +{
> +  return x >= y;
> +}
> +
> +/* { dg-final { scan-assembler-not "sext\\.w" } } */
> Index: gcc/gcc/testsuite/gcc.target/riscv/sgeu.c
> ===
> --- /dev/null
> +++ gcc/gcc/testsuite/gcc.target/riscv/sgeu.c
> @@ -0,0 +1,11 @@
> +/* { dg-do compile } */
> +/* { 

Re: [PATCH] RISC-V/testsuite: Restrict remaining `fmin'/`fmax' tests to hard float

[Kito Cheng via Gcc-patches]

LGTM, thanks :)

On Fri, Jul 29, 2022 at 3:52 AM Maciej W. Rozycki  wrote:
>
> Complement commit 7915f6551343 ("RISC-V/testsuite: constraint some of
> tests to hard_float") and also restrict the remaining `fmin'/`fmax'
> tests to hard-float test configurations.
>
> gcc/testsuite/
> * gcc.target/riscv/fmax-snan.c: Add `dg-require-effective-target
> hard_float'.
> * gcc.target/riscv/fmaxf-snan.c: Likewise.
> * gcc.target/riscv/fmin-snan.c: Likewise.
> * gcc.target/riscv/fminf-snan.c: Likewise.
> ---
>  gcc/testsuite/gcc.target/riscv/fmax-snan.c  |1 +
>  gcc/testsuite/gcc.target/riscv/fmaxf-snan.c |1 +
>  gcc/testsuite/gcc.target/riscv/fmin-snan.c  |1 +
>  gcc/testsuite/gcc.target/riscv/fminf-snan.c |1 +
>  4 files changed, 4 insertions(+)
>
> gcc-riscv-fmin-fmax-test-hard-float.diff
> Index: gcc/gcc/testsuite/gcc.target/riscv/fmax-snan.c
> ===
> --- gcc.orig/gcc/testsuite/gcc.target/riscv/fmax-snan.c
> +++ gcc/gcc/testsuite/gcc.target/riscv/fmax-snan.c
> @@ -1,4 +1,5 @@
>  /* { dg-do compile } */
> +/* { dg-require-effective-target hard_float } */
>  /* { dg-options "-fno-finite-math-only -fsigned-zeros -fsignaling-nans -dp" 
> } */
>
>  double
> Index: gcc/gcc/testsuite/gcc.target/riscv/fmaxf-snan.c
> ===
> --- gcc.orig/gcc/testsuite/gcc.target/riscv/fmaxf-snan.c
> +++ gcc/gcc/testsuite/gcc.target/riscv/fmaxf-snan.c
> @@ -1,4 +1,5 @@
>  /* { dg-do compile } */
> +/* { dg-require-effective-target hard_float } */
>  /* { dg-options "-fno-finite-math-only -fsigned-zeros -fsignaling-nans -dp" 
> } */
>
>  float
> Index: gcc/gcc/testsuite/gcc.target/riscv/fmin-snan.c
> ===
> --- gcc.orig/gcc/testsuite/gcc.target/riscv/fmin-snan.c
> +++ gcc/gcc/testsuite/gcc.target/riscv/fmin-snan.c
> @@ -1,4 +1,5 @@
>  /* { dg-do compile } */
> +/* { dg-require-effective-target hard_float } */
>  /* { dg-options "-fno-finite-math-only -fsigned-zeros -fsignaling-nans -dp" 
> } */
>
>  double
> Index: gcc/gcc/testsuite/gcc.target/riscv/fminf-snan.c
> ===
> --- gcc.orig/gcc/testsuite/gcc.target/riscv/fminf-snan.c
> +++ gcc/gcc/testsuite/gcc.target/riscv/fminf-snan.c
> @@ -1,4 +1,5 @@
>  /* { dg-do compile } */
> +/* { dg-require-effective-target hard_float } */
>  /* { dg-options "-fno-finite-math-only -fsigned-zeros -fsignaling-nans -dp" 
> } */
>
>  float

Re: [PATCH v3] Modify combine pattern by a pseudo AND with its nonzero bits [PR93453]

[HAO CHEN GUI via Gcc-patches]

Hi Segher,
  Really appreciate your review comments.

On 11/8/2022 上午 1:38, Segher Boessenkool wrote:
> Hi!
> 
> Sorry for the tardiness.
> 
> On Fri, Jul 22, 2022 at 03:07:55PM +0800, HAO CHEN GUI wrote:
>>   This patch creates a new function - change_pseudo_and_mask. If recog fails,
>> the function converts a single pseudo to the pseudo AND with a mask if the
>> outer operator is IOR/XOR/PLUS and inner operator is ASHIFT or AND. The
>> conversion helps pattern to match rotate and mask insn on some targets.
> 
> The name isn't so clear.  It isn't changing a mask, to start with.
How about setting function name to change_pseudo? It converts a pseudo to
the pseudo AND with a mask in a particular situation.

> 
>> +/* When the outer code of set_src is IOR/XOR/PLUS and the inner code is
>> +   ASHIFT/AND,
> 
> "When the outercode of the SET_SRC of PAT is ..."
Yeah, I will change it.

> 
>> convert a pseudo to pseudo AND with a mask if its nonzero_bits
>> +   is less than its mode mask.  The nonzero_bits in later passes is not a
>> +   superset of what is known in combine pass.  So an insn with nonzero_bits
>> +   can't be recoged later.  */
> 
> Can this not be done with a splitter in the machine description?
> 
Sorry, I don't quite understand it. Do you mean if the conversion can be done in
split pass?

If a pseudo has DImode and stem from a char, we get nonzero_bits as 0xff in 
combine
pass. But in split pass, it's nonzero_bits is 0x. So the 
conversion
can only be done in combine pass.

Thanks
Gui Haochen

Re: [PATCH v2] c-family: Honor -Wno-init-self for cv-qual vars [PR102633]

[Jason Merrill via Gcc-patches]

On 8/8/22 12:06, Marek Polacek wrote:

On Sat, Aug 06, 2022 at 03:29:05PM -0700, Jason Merrill wrote:

On 7/26/22 14:31, Marek Polacek wrote:

On Tue, Jul 26, 2022 at 04:24:18PM -0400, Jason Merrill wrote:

On 7/26/22 15:03, Marek Polacek wrote:

Since r11-5188-g32934a4f45a721, we drop qualifiers during l-to-r
conversion by creating a NOP_EXPR.  For e.g.

 const int i = i;

that means that the DECL_INITIAL is '(int) i' and not 'i' anymore.
Consequently, we don't suppress_warning here:

711 case DECL_EXPR:
715   if (VAR_P (DECL_EXPR_DECL (*expr_p))
716   && !DECL_EXTERNAL (DECL_EXPR_DECL (*expr_p))
717   && !TREE_STATIC (DECL_EXPR_DECL (*expr_p))
718   && (DECL_INITIAL (DECL_EXPR_DECL (*expr_p)) == DECL_EXPR_DECL 
(*expr_p))
719   && !warn_init_self)
720 suppress_warning (DECL_EXPR_DECL (*expr_p), OPT_Winit_self);

because of the check on line 718 -- (int) i is not i.  So -Wno-init-self
doesn't disable the warning as it's supposed to.

The following patch fixes it...except it doesn't, for volatile variables
in C++.  The problem is that for

 volatile int k = k;

we see that the initializer has TREE_SIDE_EFFECTS, so we perform dynamic
initialization.  So there's no DECL_INITIAL and the suppress_warning
call above is never done.  I suppose we could amend get_no_uninit_warning
to return true for volatile-qualified expressions.  I mean, can we ever
say for a fact that a volatile variable is uninitialized?

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

PR middle-end/102633

gcc/c-family/ChangeLog:

* c-gimplify.cc (c_gimplify_expr): Strip NOPs of DECL_INITIAL.


I wonder if we want to handle this i = i case earlier, like in finish_decl.


I could, something like

@@ -5381,7 +5381,14 @@ finish_decl (tree decl, location_t init_loc, tree init,
   init = NULL_TREE;

 if (init)
-store_init_value (init_loc, decl, init, origtype);
+{
+  /* In the self-init case, undo the artificial NOP_EXPR we may have
+added in convert_lvalue_to_rvalue so that c_gimplify_expr/DECL_EXPR
+can perform suppress_warning.  */
+  if (TREE_CODE (init) == NOP_EXPR && TREE_OPERAND (init, 0) == decl)
+   init = TREE_OPERAND (init, 0);
+  store_init_value (init_loc, decl, init, origtype);
+}

but then I'd have to do the same thing in cp_finish_decl because
decay_conversion also adds a NOP_EXPR for cv-qualified non-class prvalues.
Is that what we want?  To me that seems less clean than having c_gimplify_expr
see through NOP_EXPRs.


I was thinking of checking the form of the initializer before
decay_conversion or anything else messes with it, and calling
suppress_warning at that point instead of in c_gimplify_expr.


Aaah, okay.  Here's a patch that does it.  In the C FE it has to
happen really early.  Now both front ends behave the same wrt volatiles!

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


LGTM.


-- >8 --
Since r11-5188-g32934a4f45a721, we drop qualifiers during l-to-r
conversion by creating a NOP_EXPR.  For e.g.

   const int i = i;

that means that the DECL_INITIAL is '(int) i' and not 'i' anymore.
Consequently, we don't suppress_warning here:

711 case DECL_EXPR:
715   if (VAR_P (DECL_EXPR_DECL (*expr_p))
716   && !DECL_EXTERNAL (DECL_EXPR_DECL (*expr_p))
717   && !TREE_STATIC (DECL_EXPR_DECL (*expr_p))
718   && (DECL_INITIAL (DECL_EXPR_DECL (*expr_p)) == DECL_EXPR_DECL 
(*expr_p))
719   && !warn_init_self)
720 suppress_warning (DECL_EXPR_DECL (*expr_p), OPT_Winit_self);

because of the check on line 718 -- (int) i is not i.  So -Wno-init-self
doesn't disable the warning as it's supposed to.

The following patch fixes it by moving the suppress_warning call from
c_gimplify_expr to the front ends, at points where we haven't created
the NOP_EXPR yet.

PR middle-end/102633

gcc/c-family/ChangeLog:

* c-gimplify.cc (c_gimplify_expr) : Don't call
suppress_warning here.

gcc/c/ChangeLog:

* c-parser.cc (c_parser_initializer): Add new tree parameter.  Use it.
Call suppress_warning.
(c_parser_declaration_or_fndef): Pass d down to c_parser_initializer.
(c_parser_omp_declare_reduction): Pass omp_priv down to
c_parser_initializer.

gcc/cp/ChangeLog:

* decl.cc (cp_finish_decl): Call suppress_warning.

gcc/testsuite/ChangeLog:

* c-c++-common/Winit-self1.c: New test.
* c-c++-common/Winit-self2.c: New test.
---
  gcc/c-family/c-gimplify.cc   | 12 -
  gcc/c/c-parser.cc| 19 ---
  gcc/cp/decl.cc   |  8 ++
  gcc/testsuite/c-c++-common/Winit-self1.c | 31 
  gcc/testsuite/c-c++-common/Winit-self2.c | 31 
  5 files changed, 85 insertions(+), 16 deletions(-)
  create mode 100644 gcc/testsuite/c-c++-common/Winit-self1.c
  create mode 100644 

Re: Possible C++ method signature warning feature?

[Andrew Pinski via Gcc]

On Wed, Aug 10, 2022 at 6:20 PM Paul Koning via Gcc  wrote:
>
> There's a C++ problem I keep running into, in a very large body of software 
> with lots of subclassing.
>
> There's a base class that defines a set of interface methods, not all pure 
> virtual (some define the default behavior).  A number of subclasses override 
> some but not all of these.
>
> Now I find myself changing the argument list of some of these methods, so I 
> have to change the base class definitions and also track down all the 
> subclass redefinitions.  If I miss one of the latter, that subclass method is 
> no longer called (it now just looks like an unrelated method with a different 
> argument list that isn't used anywhere).  Finding these things can be hard 
> and time consuming.
>
> It would be helpful to have some way to mark a method as "this is supposed to 
> be an override of a base class method", in other words "warn me if this 
> method doesn't override some method in a base class".

C++11's overload keyword sounds exactly what you want.
https://en.cppreference.com/w/cpp/language/override

Thanks,
Andrew Pinski

>
> Does that sound like a possible thing to do, perhaps with some __attribute__ 
> magic?  Would it be interesting?
>
> paul
>

Possible C++ method signature warning feature?

[Paul Koning via Gcc]

There's a C++ problem I keep running into, in a very large body of software 
with lots of subclassing.

There's a base class that defines a set of interface methods, not all pure 
virtual (some define the default behavior).  A number of subclasses override 
some but not all of these.

Now I find myself changing the argument list of some of these methods, so I 
have to change the base class definitions and also track down all the subclass 
redefinitions.  If I miss one of the latter, that subclass method is no longer 
called (it now just looks like an unrelated method with a different argument 
list that isn't used anywhere).  Finding these things can be hard and time 
consuming.

It would be helpful to have some way to mark a method as "this is supposed to 
be an override of a base class method", in other words "warn me if this method 
doesn't override some method in a base class".

Does that sound like a possible thing to do, perhaps with some __attribute__ 
magic?  Would it be interesting?

paul

[Bug tree-optimization/106322] [12/13 Regression] tree-vectorize: Wrong code at O2 level (-fno-tree-vectorize is working) since r12-2404-ga1d27560770818c5

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

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

--- Comment #44 from Kewen Lin  ---
(In reply to Richard Biener from comment #43)
> (In reply to Richard Biener from comment #42)
> > I think this goes wrong in vectorizable_operation which does
> > 
> >   if (using_emulated_vectors_p
> >   && !vect_can_vectorize_without_simd_p (code))
> > 
> > to guard this but I'm not sure how this slips through?
> 
> Ah, it's an internal function.  I think we should simply return false
> during analysis for any vect_emulated_vector_p type in vectorizable_call.
> 
> Alternatively pattern recognition could also be made to fail but the above
> is definitely more future proof.

Thanks for the pointer!  I think you meant:

diff --git a/gcc/tree-vect-stmts.cc b/gcc/tree-vect-stmts.cc
index c9534ef9b1e..ee10fa3e0fb 100644
--- a/gcc/tree-vect-stmts.cc
+++ b/gcc/tree-vect-stmts.cc
@@ -3388,6 +3388,14 @@ vectorizable_call (vec_info *vinfo,
   return false;
 }

+  if (vect_emulated_vector_p (vectype_in) || vect_emulated_vector_p
(vectype_out))
+  {
+  if (dump_enabled_p ())
+   dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,
+"use emulated vector type for call\n");
+  return false;
+  }
+
   /* FORNOW */
   nunits_in = TYPE_VECTOR_SUBPARTS (vectype_in);
   nunits_out = TYPE_VECTOR_SUBPARTS (vectype_out);

Will kick off some testings on x64/aarch64/ppc64{,le} and post it later.

Re: gccgo emits GIMPLE with temporaries for boolean expressions unlike gcc, gdc

[Ian Lance Taylor via Gcc]

On Wed, Aug 3, 2022 at 6:26 AM j  wrote:
>
> I've proposed a patch [1] for condition coverage profiling in gcc,
> implemented in the middle-end alongside the branch coverage. I've
> written most of the tests for C and a few for C++ and finally got around
> to try it with a toy example for D and go and noticed something odd
> about Go's CFG construction.
>
> abc.c:
>  int fn (int a, int b, int c) {
>  if (a && (b || c))
>  return a;
>  else
>  return b * c;
>  }
>
> abc.d:
>  int fn (int a, int b, int c) {
>  if (a && (b || c))
>  return a;
>  else
>  return b * c;
>  }
>
> abc.go:
>  func fn (a int, b int, c int) int {
>  a_ := a != 0;
>  b_ := b != 0;
>  c_ := c != 0;
>
>  if a_ && (b_ || c_) {
>  return 1;
>  } else {
>  return 0;
>  }
>  }
>
> All were built with gcc --coverage -fprofile-conditions (my patch, but
> it does not affect this) and no optimization. The C and D programs
> behaved as expected:
>
> gcov --conditions abc.d:
>
>  3:3:int fn (int a, int b, int c) {
> 3*:4:if (a && (b || c))
> conditions outcomes covered 3/6
> condition  1 not covered (false)
> condition  2 not covered (true)
> condition  2 not covered (false)
>  1:5:return a;
>  -:6:else
>  2:7:return b * c;
>
>
> gcov --conditions abc.go:
>  3:5:func fn (a int, b int, c int) int {
>  3:6:a_ := a != 0;
>  3:7:b_ := b != 0;
>  3:8:c_ := c != 0;
>  -:9:
> 3*:   10:if a_ && (b_ || c_) {
> condition outcomes covered 2/2
> condition outcomes covered 1/2
> condition  0 not covered (true)
> condition outcomes covered 2/2
>  1:   11:return 1;
>  -:   12:} else {
>  2:   13:return 0;
>  -:   14:}
>  -:   15:}
>
> So I dumped the gimple gcc -fdump-tree-gimple abc.go:
>
> int main.fn (int a, int b, int c)
> {
>int D.2725;
>int $ret0;
>
>$ret0 = 0;
>{
>  bool a_;
>  bool b_;
>  bool c_;
>
>  a_ = a != 0;
>  b_ = b != 0;
>  c_ = c != 0;
>  {
>{
>  GOTMP.0 = a_;
>  if (GOTMP.0 != 0) goto ; else goto ;
>  :
>  {
>{
>  GOTMP.1 = b_;
>  _1 = ~GOTMP.1;
>  if (_1 != 0) goto ; else goto ;
>  :
>  {
>GOTMP.1 = c_;
>  }
>  :
>}
>GOTMP.2 = GOTMP.1;
>GOTMP.0 = GOTMP.2;
>  }
>  :
>}
>if (GOTMP.0 != 0) goto ; else goto ;
>:
>
>
>
>{
>  {
>$ret0 = 1;
>D.2725 = $ret0;
>// predicted unlikely by early return (on trees) predictor.
>return D.2725;
>  }
>}
>:
>{
>  {
>$ret0 = 0;
>D.2725 = $ret0;
>// predicted unlikely by early return (on trees) predictor.
>return D.2725;
>  }
>}
>  }
>}
> }
>
> Where as D (and C) is more-or-less as you would expect:
>
> int fn (int a, int b, int c)
>
>
>
> {
>int D.7895;
>
>if (a != 0) goto ; else goto ;
>:
>if (b != 0) goto ; else goto ;
>:
>if (c != 0) goto ; else goto ;
>:
>D.7895 = a;
>// predicted unlikely by early return (on trees) predictor.
>return D.7895;
>:
>D.7895 = b * c;
>// predicted unlikely by early return (on trees) predictor.
>return D.7895;
> }
>
> Clearly the decision inference algorithm is unable to properly
> instrument to Go program for condition coverage because of the use of
> temporaries in the emitted GIMPLE. The question is: is this intentional
> and/or required from Go's semantics or could it be considered a defect?
> Is emitting the GIMPLE without the use of temporaries feasible at all?

The Go frontend converts && and || expressions into code that uses
explicit if statements.  This is done largely as an internal
simplification.  Go has rules about the order in which function calls
and certain other kinds of expressions must be evaluated.  Separating
out the order of evaluation imposed by && and || simplifies the
implementation of the other order of evaluation rules.

Ian

[Bug target/106574] gcc 12 with O3 leads to failures in glibc's y1f128 tests

[michael.hudson at canonical dot com via Gcc-bugs]

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

--- Comment #10 from Michael Hudson-Doyle  
---
FWIW, I see a similar error on ppc64el with what looks like a similar cause. (I
also see other errors that do not go away with s/O3/O2/ so that might be
something slightly different).

O3:

(kinetic-ppc64el)root@bobonevm3:/build/glibc-9T9BfE/glibc-2.36/build-tree/ppc64el-libc#
./elf/ld64.so.2 --library-path .:./elf:./math  ./math/test-ibm128-y1
testing long double (without inline functions)
Failure: Test: y1_downward (0x2p+0)
Result:
 is: -1.07032431540937546888370772277496e-01 
-0x1.b667a3914664758b0c44371e580p-4
 should be:  -1.07032431540937546888370772277477e-01 
-0x1.b667a3914664758b0c44371e520p-4
 difference:  1.84889274661174641893373882488153e-32  
0x1.800p-106
 ulp   :  12.
 max.ulp   :  11.
Maximal error of `y1_downward'
 is  : 12 ulp
 accepted: 11 ulp
Failure: Test: y1_upward (0x1.c1bc2ep+0)
Result:
 is: -2.49838507061808223791568937534715e-01 
-0x1.ffab54c8e53c466a84209c10030p-3
 should be:  -2.49838507061808223791568937534759e-01 
-0x1.ffab54c8e53c466a84209c100a0p-3
 difference:  4.31408307542740831084539059139024e-32  
0x1.c00p-105
 ulp   :  14.
 max.ulp   :  9.
Failure: Test: y1_upward (0x2p+0)
Result:
 is: -1.07032431540937546888370772277458e-01 
-0x1.b667a3914664758b0c44371e4c0p-4
 should be:  -1.07032431540937546888370772277475e-01 
-0x1.b667a3914664758b0c44371e518p-4
 difference:  1.69481835106076755068926058947474e-32  
0x1.600p-106
 ulp   :  11.
 max.ulp   :  9.
Maximal error of `y1_upward'
 is  : 14 ulp
 accepted: 9 ulp

Test suite completed:
  175 test cases plus 171 tests for exception flags and
171 tests for errno executed.

O2:

(kinetic-ppc64el)root@bobonevm3:/build/glibc-9T9BfE/glibc-2.36/build-tree/ppc64el-libc#
./elf/ld64.so.2 --library-path .:./elf:./math  ./math/test-ibm128-y1
testing long double (without inline functions)
Failure: Test: y1_upward (0x1.c1bc2ep+0)
Result:
 is: -2.49838507061808223791568937534728e-01 
-0x1.ffab54c8e53c466a84209c10050p-3
 should be:  -2.49838507061808223791568937534759e-01 
-0x1.ffab54c8e53c466a84209c100a0p-3
 difference:  3.08148791101957736488956470813589e-32  
0x1.400p-105
 ulp   :  10.
 max.ulp   :  9.
Failure: Test: y1_upward (0x2p+0)
Result:
 is: -1.07032431540937546888370772277458e-01 
-0x1.b667a3914664758b0c44371e4c0p-4
 should be:  -1.07032431540937546888370772277475e-01 
-0x1.b667a3914664758b0c44371e518p-4
 difference:  1.69481835106076755068926058947474e-32  
0x1.600p-106
 ulp   :  11.
 max.ulp   :  9.
Maximal error of `y1_upward'
 is  : 11 ulp
 accepted: 9 ulp

Test suite completed:
  175 test cases plus 171 tests for exception flags and
171 tests for errno executed.
  3 errors occurred.

(I also see llround errors on ppc64el, no idea what's going on there...)

Re: [PATCH v2 2/2] RISC-V: Support zfh and zfhmin extension

[钟居哲]

LGTM. 



juzhe.zh...@rivai.ai
 
From: Kito Cheng
Date: 2022-08-10 23:44
To: gcc-patches; kito.cheng; jim.wilson.gcc; palmer; andrew; juzhe.zhong; joseph
CC: Kito Cheng
Subject: [PATCH v2 2/2] RISC-V: Support zfh and zfhmin extension
Zfh and Zfhmin are extensions for IEEE half precision, both are ratified
in Jan. 2022[1]:
 
- Zfh has full set of operation like F or D for single or double precision.
- Zfhmin has only provide minimal support for half precision operation,
  like conversion, load, store and move instructions.
 
[1] 
https://github.com/riscv/riscv-isa-manual/commit/b35a54079e0da11740ce5b1e6db999d1d5172768
 
gcc/ChangeLog:
 
* common/config/riscv/riscv-common.cc (riscv_implied_info): Add
zfh and zfhmin.
(riscv_ext_version_table): Ditto.
(riscv_ext_flag_table): Ditto.
* config/riscv/riscv-opts.h (MASK_ZFHMIN): New.
(MASK_ZFH): Ditto.
(TARGET_ZFHMIN): Ditto.
(TARGET_ZFH): Ditto.
* config/riscv/riscv.cc (riscv_output_move): Handle HFmode move
for zfh and zfhmin.
(riscv_emit_float_compare): Handle HFmode.
* config/riscv/riscv.md (ANYF): Add HF.
(SOFTF): Add HF.
(load): Ditto.
(store): Ditto.
(truncsfhf2): New.
(truncdfhf2): Ditto.
(extendhfsf2): Ditto.
(extendhfdf2): Ditto.
(*movhf_hardfloat): Ditto.
(*movhf_softfloat): Make sure not ZFHMIN.
* config/riscv/riscv.opt (riscv_zf_subext): New.
 
gcc/testsuite/ChangeLog:
 
* gcc.target/riscv/_Float16-zfh-1.c: New.
* gcc.target/riscv/_Float16-zfh-2.c: Ditto.
* gcc.target/riscv/_Float16-zfh-3.c: Ditto.
* gcc.target/riscv/_Float16-zfhmin-1.c: Ditto.
* gcc.target/riscv/_Float16-zfhmin-2.c: Ditto.
* gcc.target/riscv/_Float16-zfhmin-3.c: Ditto.
* gcc.target/riscv/arch-16.c: Ditto.
* gcc.target/riscv/arch-17.c: Ditto.
* gcc.target/riscv/predef-21.c: Ditto.
* gcc.target/riscv/predef-22.c: Ditto.
---
gcc/common/config/riscv/riscv-common.cc   |  8 +++
gcc/config/riscv/riscv-opts.h |  6 ++
gcc/config/riscv/riscv.cc | 33 ++-
gcc/config/riscv/riscv.md | 59 +--
gcc/config/riscv/riscv.opt|  3 +
.../gcc.target/riscv/_Float16-zfh-1.c |  8 +++
.../gcc.target/riscv/_Float16-zfh-2.c |  8 +++
.../gcc.target/riscv/_Float16-zfh-3.c |  8 +++
.../gcc.target/riscv/_Float16-zfhmin-1.c  |  9 +++
.../gcc.target/riscv/_Float16-zfhmin-2.c  |  9 +++
.../gcc.target/riscv/_Float16-zfhmin-3.c  |  9 +++
gcc/testsuite/gcc.target/riscv/arch-16.c  |  5 ++
gcc/testsuite/gcc.target/riscv/arch-17.c  |  5 ++
gcc/testsuite/gcc.target/riscv/predef-21.c| 59 +++
gcc/testsuite/gcc.target/riscv/predef-22.c| 59 +++
15 files changed, 279 insertions(+), 9 deletions(-)
create mode 100644 gcc/testsuite/gcc.target/riscv/_Float16-zfh-1.c
create mode 100644 gcc/testsuite/gcc.target/riscv/_Float16-zfh-2.c
create mode 100644 gcc/testsuite/gcc.target/riscv/_Float16-zfh-3.c
create mode 100644 gcc/testsuite/gcc.target/riscv/_Float16-zfhmin-1.c
create mode 100644 gcc/testsuite/gcc.target/riscv/_Float16-zfhmin-2.c
create mode 100644 gcc/testsuite/gcc.target/riscv/_Float16-zfhmin-3.c
create mode 100644 gcc/testsuite/gcc.target/riscv/arch-16.c
create mode 100644 gcc/testsuite/gcc.target/riscv/arch-17.c
create mode 100644 gcc/testsuite/gcc.target/riscv/predef-21.c
create mode 100644 gcc/testsuite/gcc.target/riscv/predef-22.c
 
diff --git a/gcc/common/config/riscv/riscv-common.cc 
b/gcc/common/config/riscv/riscv-common.cc
index 0e5be2ce105..4ee1b3198c5 100644
--- a/gcc/common/config/riscv/riscv-common.cc
+++ b/gcc/common/config/riscv/riscv-common.cc
@@ -96,6 +96,9 @@ static const riscv_implied_info_t riscv_implied_info[] =
   {"zvl32768b", "zvl16384b"},
   {"zvl65536b", "zvl32768b"},
+  {"zfh", "zfhmin"},
+  {"zfhmin", "f"},
+
   {NULL, NULL}
};
@@ -193,6 +196,9 @@ static const struct riscv_ext_version 
riscv_ext_version_table[] =
   {"zvl32768b", ISA_SPEC_CLASS_NONE, 1, 0},
   {"zvl65536b", ISA_SPEC_CLASS_NONE, 1, 0},
+  {"zfh",   ISA_SPEC_CLASS_NONE, 1, 0},
+  {"zfhmin",ISA_SPEC_CLASS_NONE, 1, 0},
+
   /* Terminate the list.  */
   {NULL, ISA_SPEC_CLASS_NONE, 0, 0}
};
@@ -1148,6 +1154,8 @@ static const riscv_ext_flag_table_t 
riscv_ext_flag_table[] =
   {"zvl32768b", _options::x_riscv_zvl_flags, MASK_ZVL32768B},
   {"zvl65536b", _options::x_riscv_zvl_flags, MASK_ZVL65536B},
+  {"zfhmin",_options::x_riscv_zf_subext, MASK_ZFHMIN},
+  {"zfh",   _options::x_riscv_zf_subext, MASK_ZFH},
   {NULL, NULL, 0}
};
diff --git a/gcc/config/riscv/riscv-opts.h b/gcc/config/riscv/riscv-opts.h
index 1e153b3a6e7..85e869e62e3 100644
--- a/gcc/config/riscv/riscv-opts.h
+++ b/gcc/config/riscv/riscv-opts.h
@@ -153,6 +153,12 @@ enum stack_protector_guard {
#define TARGET_ZICBOM ((riscv_zicmo_subext & MASK_ZICBOM) != 0)
#define TARGET_ZICBOP ((riscv_zicmo_subext & MASK_ZICBOP) != 0)
+#define MASK_ZFHMIN   (1 << 0)
+#define MASK_ZFH  (1 << 1)
+
+#define TARGET_ZFHMIN ((riscv_zf_subext & MASK_ZFHMIN) != 0)
+#define TARGET_ZFH

[Bug target/106574] gcc 12 with O3 leads to failures in glibc's y1f128 tests

[michael.hudson at canonical dot com via Gcc-bugs]

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

--- Comment #9 from Michael Hudson-Doyle  
---
I uploaded the object file with the bad code to
https://people.canonical.com/~mwh/e_j1f128.os.

[Bug target/106581] [Aarch64] libstdc++ segfault at end of execution

[lancethepants at gmail dot com via Gcc-bugs]

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

--- Comment #12 from Lance Fredrickson  ---
I will send an email to their mailing list and inform them of this thread as
well. I've queried on buildroot mailing list and irc if anyone uses aarch64 +
uclibc-ng.

thanks for your attention and troubleshooting!

[Bug target/106574] gcc 12 with O3 leads to failures in glibc's y1f128 tests

[michael.hudson at canonical dot com via Gcc-bugs]

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

--- Comment #8 from Michael Hudson-Doyle  
---
I just changed

  z = xx * xx;

to

  z = math_opt_barrier(xx * xx);

which perhaps isn't sufficient.

But my reading of the assembly is that the issue is that some of the math code
is being moved _after_ the restore of the fpu state implied by
SET_RESTORE_ROUNDL (FE_TONEAREST).

I included some snippets in https://paste.ubuntu.com/p/RMdWK6yr2F/.

This seems bad?

[Bug target/106545] peephole.md seems like it should not exist

[vineetg at rivosinc dot com via Gcc-bugs]

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

Vineet Gupta  changed:

   What|Removed |Added

 CC||vineetg at rivosinc dot com

--- Comment #1 from Vineet Gupta  ---
How do I assign this to myself, can this only be done by maintainers ?

[Bug fortran/106579] ieee_signaling_nan problem in fortran on powerpc64

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

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

Segher Boessenkool  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org

--- Comment #2 from Segher Boessenkool  ---
Let me say again that IEEE QP and double-double should not be the same kind.
This very obviously cannot work at all.

[Bug target/106581] [Aarch64] libstdc++ segfault at end of execution

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||wrong-code
  Component|libstdc++   |target

--- Comment #11 from Andrew Pinski  ---
(In reply to Lance Fredrickson from comment #10)
> (gdb) disassemble 0x7fb7eae3b8
> Dump of assembler code for function (anonymous namespace)::get_global():
>0x007fb7eae3b8 <+0>: stp x29, x30, [sp, #-16]!
>0x007fb7eae3bc <+4>: mov x29, sp
>0x007fb7eae3c0 <+8>: adrpx0, 0x7fb7fe3000
> <_znst15basic_stringbuficst11char_traitsicesaicee15_m_update_egpt...@got.plt>
>0x007fb7eae3c4 <+12>:ldr x1, [x0, #3248]
>0x007fb7eae3c8 <+16>:add x0, x0, #0xcb0
>0x007fb7eae3cc <+20>:blr x1
>0x007fb7eae3d0 <+24>:mrs x1, tpidr_el0
>0x007fb7eae3d4 <+28>:add x0, x1, x0
>0x007fb7eae3d8 <+32>:ldp x29, x30, [sp], #16
>0x007fb7eae3dc <+36>:ret
> End of assembler dump.

That looks correct.
It is basically:

adrpx0, :tlsdesc:a
ldr x1, [x0, #:tlsdesc_lo12:a]
add x0, x0, :tlsdesc_lo12:a
.tlsdesccalla
blr x1
mrs x1, tpidr_el0
add x0, x1, x0


So now this is looking more and more like an uclibc issue rather a
GCC/libstdc++ one.
Have you reported it to them yet?

[Bug libstdc++/106581] [Aarch64] libstdc++ segfault at end of execution

[lancethepants at gmail dot com via Gcc-bugs]

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

--- Comment #10 from Lance Fredrickson  ---
(gdb) disassemble 0x7fb7eae3b8
Dump of assembler code for function (anonymous namespace)::get_global():
   0x007fb7eae3b8 <+0>: stp x29, x30, [sp, #-16]!
   0x007fb7eae3bc <+4>: mov x29, sp
   0x007fb7eae3c0 <+8>: adrpx0, 0x7fb7fe3000
<_znst15basic_stringbuficst11char_traitsicesaicee15_m_update_egpt...@got.plt>
   0x007fb7eae3c4 <+12>:ldr x1, [x0, #3248]
   0x007fb7eae3c8 <+16>:add x0, x0, #0xcb0
   0x007fb7eae3cc <+20>:blr x1
   0x007fb7eae3d0 <+24>:mrs x1, tpidr_el0
   0x007fb7eae3d4 <+28>:add x0, x1, x0
   0x007fb7eae3d8 <+32>:ldp x29, x30, [sp], #16
   0x007fb7eae3dc <+36>:ret
End of assembler dump.

[Bug libstdc++/106581] [Aarch64] libstdc++ segfault at end of execution

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

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

--- Comment #9 from Andrew Pinski  ---
disassemble 0x7fb7eae3b8
Which was:
   0x007fb7eae3fc <+8>: bl  0x7fb7eae3b8 <(anonymous
namespace)::get_global()>

I am still trying to figure out how the TLS address was formed here.

[Bug libstdc++/106581] [Aarch64] libstdc++ segfault at end of execution

[lancethepants at gmail dot com via Gcc-bugs]

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

--- Comment #8 from Lance Fredrickson  ---
Here is 'info proc mappings'

(gdb) info proc mappings
process 16896
Mapped address spaces:

  Start Addr   End Addr   Size Offset objfile
0x555000   0x556000 0x10000x0
/mmc/src/hello.src/hello
0x565000   0x566000 0x10000x0
/mmc/src/hello.src/hello
0x566000   0x567000 0x1000 0x1000
/mmc/src/hello.src/hello
0x567000   0x5790000x120000x0 [heap]
0x7fb7c9f000   0x7fb7db   0x1110000x0
/mmc/lib/libuClibc-1.0.41.so
0x7fb7db   0x7fb7dc0x10x0
0x7fb7dc   0x7fb7dc1000 0x1000   0x111000
/mmc/lib/libuClibc-1.0.41.so
0x7fb7dc1000   0x7fb7dc2000 0x1000   0x112000
/mmc/lib/libuClibc-1.0.41.so
0x7fb7dc2000   0x7fb7ddc0000x1a0000x0
0x7fb7ddc000   0x7fb7df0x140000x0
/mmc/lib/libgcc_s.so.1
0x7fb7df   0x7fb7e00x10x0
0x7fb7e0   0x7fb7e01000 0x10000x14000
/mmc/lib/libgcc_s.so.1
0x7fb7e01000   0x7fb7e02000 0x10000x15000
/mmc/lib/libgcc_s.so.1
0x7fb7e02000   0x7fb7fc6000   0x1c40000x0
/mmc/usr/lib/libstdc++.so.6.0.30
0x7fb7fc6000   0x7fb7fd60000x10x0
0x7fb7fd6000   0x7fb7fe1000 0xb000   0x1c4000
/mmc/usr/lib/libstdc++.so.6.0.30
0x7fb7fe1000   0x7fb7fe4000 0x3000   0x1cf000
/mmc/usr/lib/libstdc++.so.6.0.30
0x7fb7fe4000   0x7fb7fe8000 0x40000x0
0x7fb7fe8000   0x7fb7ff 0x80000x0
/mmc/lib/ld-uClibc-1.0.41.so
0x7fb7ffa000   0x7fb7ffd000 0x30000x0
0x7fb7ffd000   0x7fb7ffe000 0x10000x0 [vvar]
0x7fb7ffe000   0x7fb7fff000 0x10000x0 [vdso]
0x7fb7fff000   0x7fb800 0x1000 0x7000
/mmc/lib/ld-uClibc-1.0.41.so
0x7fb800   0x7fb8001000 0x1000 0x8000
/mmc/lib/ld-uClibc-1.0.41.so
0x7df000   0x800x210000x0 [stack]

[Bug target/106574] gcc 12 with O3 leads to failures in glibc's y1f128 tests

[joseph at codesourcery dot com via Gcc-bugs]

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

--- Comment #7 from joseph at codesourcery dot com  ---
I'd suggest looking at the generated assembly.  I don't know exactly what 
you mean by "putting a math_opt_barrier on this line"; it would need to be 
used in a way that ensures a dependency for all the code after 
SET_RESTORE_ROUNDL (for example, "xx = math_opt_barrier (xx);").

[Bug libstdc++/106581] [Aarch64] libstdc++ segfault at end of execution

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

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

--- Comment #7 from Andrew Pinski  ---
(In reply to Lance Fredrickson from comment #6)
> info mem gives
> 
> (gdb) info mem
> Using memory regions provided by the target.
> There are no memory regions defined.

Sorry, I mean "info proc mappings"

Re: Checking for built-in functions from build systems

[Luca Bacci via Gcc]

Thank you very much, Jonathan. That's very helpful!

This test program:

int main()
{
  void *a = alloca(10);
  return 0;
}

Compiles fine with:
 gcc -o test test.c
But then fails with:
 gcc -o test test.c -fno-builtin

That's on an Arch Linux system (based on glibc)

The issue is that what happens when built-ins are not inlined is not well
defined. The libc may not implement the routine, or it's not clear which
dependency should provide it.

Thanks,
Luca Bacci

Il giorno mer 10 ago 2022 alle ore 23:27 Jonathan Wakely <
jwakely@gmail.com> ha scritto:

>
>
> On Wed, 10 Aug 2022, 23:12 Luca Bacci via Gcc,  wrote:
>
>>
>> 1. Is inlining of built-ins dependant only on the target architecture and
>> command-line arguments?
>>
>
> No, I think it can depend on the arguments to the built-in as well.
>
>
> 2. If the answer to 1 is yes, could a __is_builtin_inlined (func) macro be
>> added to GCC? It should tell whether func is going to be substituted
>> inline
>> for the given compiler invocation
>
>
> I don't think that can work for some built-ins, e.g. in a single
> translation unit memcmp can be inlined for constant arguments of small
> size, and not inlined for other calls.
>
>
>
>

[Bug libstdc++/106581] [Aarch64] libstdc++ segfault at end of execution

[lancethepants at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Lance Fredrickson  ---
info mem gives

(gdb) info mem
Using memory regions provided by the target.
There are no memory regions defined.

[Bug libstdc++/106581] [Aarch64] libstdc++ segfault at end of execution

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

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

--- Comment #5 from Andrew Pinski  ---
uclibc must have some ordering issue when it comes to atexit and shared
libraries and TLS.

Can you also do:
"info mem"

[Bug libstdc++/106581] [Aarch64] libstdc++ segfault at end of execution

[lancethepants at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Lance Fredrickson  ---
Here you go.

(gdb) info registers
x0 0xff6fea06f01097094268656
x1 0x7fb7ffa6c0548547831488
x2 0x0 0
x3 0x0 0
x4 0x555a9f366503877279
x5 0x7fb7dc2d5f548545506655
x6 0x57202c6f6c6c6548  6278066737626506568
x7 0x6f726620646c726f  8030593374864831087
x8 0x4064
x9 0x7fb7ffccb0548547841200
x100x7fb7e13090548545835152
x110x1 1
x120x1824
x130x7fb7ffccc0548547841216
x140x7fb7ffc2d0548547838672
x150x1 1
x160x7fb7eae3f4548546470900
x170x7fb7fe26a8548547733160
x180x0 0
x190x7fb7fe4f50548547743568
x200x7ff330549755810608
x210x555890366503876752
x220x0 0
x230x0 0
x240x0 0
x250x0 0
x260x0 0
x270x0 0
x280x0 0
x290x7ff2e0549755810528
x300x7fb7eae2b4548546470580
sp 0x7ff2e00x7ff2e0
pc 0x7fb7eae2b40x7fb7eae2b4 
cpsr   0x8000  [ EL=0 N ]
fpsr   0x0 [ ]
fpcr   0x0 [ RMode=0 ]


(gdb) disassemble __cxa_get_globals
Dump of assembler code for function __cxxabiv1::__cxa_get_globals():
   0x007fb7eae3f4 <+0>: stp x29, x30, [sp, #-16]!
   0x007fb7eae3f8 <+4>: mov x29, sp
   0x007fb7eae3fc <+8>: bl  0x7fb7eae3b8 <(anonymous
namespace)::get_global()>
   0x007fb7eae400 <+12>:ldp x29, x30, [sp], #16
   0x007fb7eae404 <+16>:ret
End of assembler dump.

[Bug libstdc++/106581] [Aarch64] libstdc++ segfault at end of execution

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

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Lance Fredrickson from comment #2)
> Here is the disassemble
> 
> (gdb) disassemble
> Dump of assembler code for function _ZSt18uncaught_exceptionv:
>0x007fb7eae2a8 <+0>: stp x29, x30, [sp, #-16]!
>0x007fb7eae2ac <+4>: mov x29, sp
>0x007fb7eae2b0 <+8>: bl  0x7fb7ea8dd0 <__cxa_get_globals@plt>
> => 0x007fb7eae2b4 <+12>:ldr w0, [x0, #8]
>0x007fb7eae2b8 <+16>:cmp w0, #0x0
>0x007fb7eae2bc <+20>:csetw0, ne  // ne = any
>0x007fb7eae2c0 <+24>:ldp x29, x30, [sp], #16
>0x007fb7eae2c4 <+28>:ret
> End of assembler dump.

"info registers"

What is the value of x0 at this point?

Can you also do "disassemble __cxa_get_globals"?

[Bug libstdc++/106581] [Aarch64] libstdc++ segfault at end of execution

[lancethepants at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Lance Fredrickson  ---
Here is the disassemble

(gdb) disassemble
Dump of assembler code for function _ZSt18uncaught_exceptionv:
   0x007fb7eae2a8 <+0>: stp x29, x30, [sp, #-16]!
   0x007fb7eae2ac <+4>: mov x29, sp
   0x007fb7eae2b0 <+8>: bl  0x7fb7ea8dd0 <__cxa_get_globals@plt>
=> 0x007fb7eae2b4 <+12>:ldr w0, [x0, #8]
   0x007fb7eae2b8 <+16>:cmp w0, #0x0
   0x007fb7eae2bc <+20>:csetw0, ne  // ne = any
   0x007fb7eae2c0 <+24>:ldp x29, x30, [sp], #16
   0x007fb7eae2c4 <+28>:ret
End of assembler dump.

[Bug libstdc++/106581] [Aarch64] libstdc++ segfault at end of execution

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2022-08-10
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
This could be a bug in uclibc and TLS.

The crash is related to TLS of:
  abi::__cxa_eh_globals*
  get_global() _GLIBCXX_NOTHROW
  {
static __thread abi::__cxa_eh_globals global;
return 
  }

Can you provide the disassemble std::uncaught_exception of where the crash is
located?
just do "disassemble" in gdb.

[GCC13][Patch][PR106457]improve array_at_struct_end_p for array objects (PR106457)

[Qing Zhao via Gcc-patches]

Hi,

As mentioned in the bug report, I reopened this bug since the previous patch:

commit r13-1875-gff26f0ba68fe6e870f315d0601b596f889b89680
Author: Richard Biener 
Date:   Thu Jul 28 10:07:32 2022 +0200

middle-end/106457 - improve array_at_struct_end_p for array objects
Array references to array objects are never at struct end.


Didn’t resolve this bug.

This is a new patch, and my current work on -fstrict-flex-array depends on this 
patch.

Please take a look at the patch and let me know whether it’s good for 
committing.

Thanks.

Qing.


==

[PATCH] middle-end/106457 - improve array_at_struct_end_p for array
 objects (PR106457)

Array references are not handled correctly by current array_at_struct_end_p,
for the following array references:

Example 1: (from gcc/testsuite/gcc.dg/torture/pr50067-[1|2].c):

short a[32] = { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16,
 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31 };
 ... = (*((char(*)[32])[0]))[i+8];  // this array reference

Example 2: (from gcc/testsuite/gcc.target/aarch64/vadd_reduc-2.c):

int test (uint8_t *p, uint32_t t[1][1], int n) {
  for (int i = 0; i < 4; i++, p++)
t[i][0] = ...;  // this array reference
...
}

Example 3: (from gcc/testsuite/g++.dg/debug/debug5.C):

  int a = 1;
  int b = 1;
  int e[a][b];
  e[0][0] = 0;  // this array reference

All the above array references are identified as TRUE by the current
array_at_struct_end_p, therefore treated as flexible array members.
Obviously, they are just simple array references, not an array refs
to the last field of a struture. The current array_at_struct_end_p handles
such array references incorrectly.

In order to handle array references correctly, we could recursively check
its first operand if it's a MEM_REF or COMPONENT_REF and stop as FALSE
when otherwise. This resolved all the issues for ARRAY_REF.

bootstrapped and regression tested on both X86 and Aarch64.
Multiple testing cases behave differently due to array_at_struct_end_p now
behave correctly (return FALSE now, then they are not flexible array member
anymore). Adjust these testing cases.

There is one regression for gcc/target/aarch64/vadd_reduc-2.c is left
unresolved since the loop transformation is changed due to the changed behavior
of array_at_struct_end_p, simple adjustment of the testing case doesnt work.
I will file a bug to record this regression.

gcc/ChangeLog:

PR middle-end/106457
* tree.cc (array_at_struct_end_p): Handle array objects recursively
through its first operand.

gcc/testsuite/ChangeLog:

PR middle-end/106457
* gcc.dg/torture/pr50067-1.c: Add -Wno-aggressive-loop-optimizations
to suppress warnings.
* gcc.dg/torture/pr50067-2.c: Likewise.
* gcc.target/aarch64/vadd_reduc-2.c: Likewise.
* gcc.target/i386/pr104059.c: Likewise.


The complete patch is at:




0001-middle-end-106457-improve-array_at_struct_end_p-for-.patch
Description: 0001-middle-end-106457-improve-array_at_struct_end_p-for-.patch

Re: Resend: Potential upcoming changes in mangling to PowerPC GCC

[Tulio Magno Quites Machado Filho via Gcc]

Segher Boessenkool  writes:

> You can write
>   double convert (__ibm128  x) { return x; }
>   double convert (__ieee128 x) { return x; }
> as well.  "__ieee128" and "long double" are the same type then (and the
> same as _Float128 and __float128 as well).

Oh! I see.  Thanks!

Going back to Mike's original question:

>> But in changing the mangling, we have the potential to create compatibility
>> issues, of code compiled with previous GCC's that use explicit __ibm128 and
>> __float128 keywords.  I don't how the users of these keywords (i.e. typically
>> libstdc++ and glibc developers, but potentially others as well).

In glibc, we use __ibm128 only once in a place that always has to be
double-double regardless of the long double type.
Everywhere else, when a double-double type is expected, long double is used.
This is also how glibc users are expected to use double-double functions from
glibc.

Meanwhile, _Float128/_float128 is used everywhere along with long double,
regardless if long double is double-double or __float128.

With that said, glibc code was designed with this in mind (thanks Joseph!), but
AFAIK nobody ever tested building glibc for ppc64le with the proposal you have
here.

If this proposal is adopted, we'd need a way to distinguish between the previous
and the new behavior, i.e. a macro.

Anyway, I believe that a newer GCC will have trouble compiling on a
system with an older glibc.
An older glibc will also have trouble building with a newer GCC, but that might
be less important.

Likewise for libdfp.

-- 
Tulio Magno

Re: Checking for built-in functions from build systems

[Jonathan Wakely via Gcc]

On Wed, 10 Aug 2022, 23:12 Luca Bacci via Gcc,  wrote:

>
> 1. Is inlining of built-ins dependant only on the target architecture and
> command-line arguments?
>

No, I think it can depend on the arguments to the built-in as well.


2. If the answer to 1 is yes, could a __is_builtin_inlined (func) macro be
> added to GCC? It should tell whether func is going to be substituted inline
> for the given compiler invocation


I don't think that can work for some built-ins, e.g. in a single
translation unit memcmp can be inlined for constant arguments of small
size, and not inlined for other calls.

[Bug target/106574] gcc 12 with O3 leads to failures in glibc's y1f128 tests

[michael.hudson at canonical dot com via Gcc-bugs]

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

--- Comment #6 from Michael Hudson-Doyle  
---
Are there any tips as to how to diagnose this further? I tried putting a
math_opt_barrier on this line:
https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/ieee754/ldbl-128/e_j1l.c;h=54c457681aecef079cb64d406ca89e05d2ce4fc5;hb=HEAD#l872
and it didn't help, although the failing test is hitting the case the
SET_RESTORE_ROUNDL is in.

[Bug libstdc++/106581] New: [Aarch64] libstdc++ segfault at end of execution

[lancethepants at gmail dot com via Gcc-bugs]

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

Bug ID: 106581
   Summary: [Aarch64] libstdc++ segfault at end of execution
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lancethepants at gmail dot com
  Target Milestone: ---

aarch64
linux 4.1.51
GCC 12.1
uclibc-ng 1.0.41

All dynamically linked c++ executables will segfault.  Some executables will
run then segfault, some just segfault.  I think there are couple segfaulting
issues, but this is the first one to address I think. GCC 10 & 11 don't
segfault at the end of execution if they don't segfault for some other reason. 
Static linked binaries don't segfault at the end of execution using either
'-static' for fully static binary or '-static-libstdc++' to static link just
libstdc++.

Here is a backtrace of segfaulting 'hello world' c++ binary

admin@RT-AX88U-6860:~/src/hello.src# /opt/bin/gdb ./hello
GNU gdb (GDB) 11.2
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "aarch64-openwrt-linux".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./hello...
(gdb) run
Starting program: /mmc/src/hello.src/hello
warning: Unable to determine the number of hardware watchpoints available.
warning: Unable to determine the number of hardware breakpoints available.
warning: File "/mmc/lib/libthread_db-1.0.41.so" auto-loading has been declined
by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load".
To enable execution of this file add
add-auto-load-safe-path /mmc/lib/libthread_db-1.0.41.so
line to your configuration file "/mmc/.config/gdb/gdbinit".
To completely disable this security protection add
set auto-load safe-path /
line to your configuration file "/mmc/.config/gdb/gdbinit".
For more information about this security protection see the
"Auto-loading safe path" section in the GDB manual.  E.g., run from the shell:
info "(gdb)Auto-loading safe path"
warning: Unable to find libthread_db matching inferior's thread library, thread
debugging will not be available.
Hello, World from C++!

Program received signal SIGSEGV, Segmentation fault.
std::uncaught_exception () at
../../../../libstdc++-v3/libsupc++/eh_catch.cc:141
141 ../../../../libstdc++-v3/libsupc++/eh_catch.cc: No such file or
directory.
(gdb) backtrace
#0  std::uncaught_exception () at
../../../../libstdc++-v3/libsupc++/eh_catch.cc:141
#1  0x007fb7f0bd30 in std::ostream::sentry::~sentry (this=0x7ff340,
__in_chrg=)
at
/home/lance/tomatoware/toolchain/buildroot-git/output/build/host-gcc-final-12.1.0/build/aarch64-tomatoware-linux-uclibc/libstdc++-v3/include/ostream:466
#2  0x007fb7f0bde4 in std::ostream::flush (this=0x7fb7fe4f48 )
at
/home/lance/tomatoware/toolchain/buildroot-git/output/build/host-gcc-final-12.1.0/build/aarch64-tomatoware-linux-uclibc/libstdc++-v3/include/bits/ostream.tcc:245
#3  0x007fb7ebbc40 in std::ios_base::Init::~Init (this=,
__in_chrg=) at
../../../../../libstdc++-v3/src/c++98/ios_init.cc:135
#4  0x007fb7d401b8 in __exit_handler (status=0) at
libc/stdlib/_atexit.c:263
#5  0x007fb7d402b8 in __GI_exit (rv=0) at libc/stdlib/_atexit.c:301
#6  0x007fb7d46134 in __uClibc_main (main=0x5559d4 , argc=1,
argv=0x7ff598, app_init=0x5557d8 <_init>, app_fini=0x555a78
<_fini>, rtld_fini=0x7fb7fe94f0 <_dl_fini>, stack_end=0x7ff590)
at libc/misc/internals/__uClibc_main.c:552
#7  0x005558c4 in _start () at libc/sysdeps/linux/aarch64/crt1.S:92
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Checking for built-in functions from build systems

[Luca Bacci via Gcc]

Hello dear GCC developers,

I am working on an issue in Meson wrt GCC built-in functions, see
https://github.com/mesonbuild/meson/issues/10641.

As you already know, some built-ins are always inlined, while others are
inlined only at times (e.g. depending on the target architecture) and
resolve to a regular function call otherwise. The issue is about the
latter's, i.e. those that may emit regular function calls.

In fact, even though __has_builtin(func) evaluates to 1, func may not be
present in libraries (libgcc, libc, libm), causing linking errors if not
inlined.

Because some of the GCC built-in functions are not part of the C standard
(e.g. sincos), it's not worthwhile to require having implementations in
libc. In addition, should generic implementations be added to libgcc, those
would likely have sub-par performance or accuracy issues (being generic).

As such, I think that a build system should check if an implementation of a
conditionally-inlined built-in function is provided in the target libc.

I have a few questions:

1. Is inlining of built-ins dependant only on the target architecture and
command-line arguments?
2. If the answer to 1 is yes, could a __is_builtin_inlined (func) macro be
added to GCC? It should tell whether func is going to be substituted inline
for the given compiler invocation
3. Is it true that conditionally-inlined built-ins are exactly those that
come in the two variants of '__builtin_func' and 'func'?

Thanks,
Luca Bacci

[Bug target/96786] rs6000: We output the wrong .machine for -mcpu=7450

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

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #3 from Segher Boessenkool  ---
Yes, I fuxed it in g:77eccbf39ed.  That needed the g:80fcc4b6afee fixup, and
will need more work in the future. but this PR is fixed indeed :-)

[Bug tree-optimization/106458] [12/13 Regression] glibc's malloc/tst-scratch_buffer.c test is miscompiled with gcc-12

[dave.anglin at bell dot net via Gcc-bugs]

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

--- Comment #15 from dave.anglin at bell dot net ---
On 2022-08-10 9:30 a.m., rguenth at gcc dot gnu.org wrote:
> hen I try with a cc1 cross I see
>
>> ./cc1 -quiet t.i -fpreprocessed -O2 -g -std=gnu11 -fgnu89-inline 
>> -fmerge-all-constants -frounding-math -fno-stack-protector -fno-common 
>> -fmath-errno-fno-pie -fopt-info-vec
> and nothing actually vectorized.  Besides the PRE there seems to be a missed
> DSE at the end (when vectorization is enabled as after the change):
>
> # DEBUG BEGIN_STMT
> memset (__space.__c, 64, 1024);
> # DEBUG BEGIN_STMT
> +  sizes[0] = 16;
> sizes[1] = 1024;
> sizes[2] = 1040;
>
> otherwise I see nothing suspicious in differences in .optimized when
> comparing -fdump-tree-optimized with/without -fno-tree-vectorize.
>
I'm not sure what's going on with the sizes[0] statement but the main
difference in .optimize with and without pre
seems to be in the handling of the old_length variable in do_test:

  Removing basic block 86
  int do_test ()
  {
-  unsigned int ivtmp.23;
-  size_t old_length;
+  unsigned int ivtmp.28;
    void * r;
    void * c;
    size_t l;

Re: [PATCH V2] arm: add -static-pie support

[Ramana Radhakrishnan via Gcc-patches]

Hi Lance,

Thanks for your contribution - looks like your first one to GCC ?

The patch looks good to me, though it should probably go through a
full test suite run on arm-linux-gnueabihf and get a ChangeLog - see
here for more https://gcc.gnu.org/contribute.html#patches.

This is probably small enough to go under the 10 line rule but since
you've used Signed-off-by in your patch, is that indicating you are
contributing under DCO rules -
https://gcc.gnu.org/contribute.html#legal ?

regards
Ramana


On Thu, Aug 4, 2022 at 5:48 PM Lance Fredrickson via Gcc-patches
 wrote:
>
> Just a follow up trying to get some eyes on my static-pie patch
> submission for arm.
> Feedback welcome.
> https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598610.html
>
> thanks,
> Lance Fredrickson

[Bug target/96786] rs6000: We output the wrong .machine for -mcpu=7450

[erhard_f at mailbox dot org via Gcc-bugs]

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

Erhard F.  changed:

   What|Removed |Added

 CC||erhard_f at mailbox dot org

--- Comment #2 from Erhard F.  ---
This seems to have been fixed meanwhile. My Gentoo ppc/ppc64 box says:

 # gcc-9.5.0 -S -m32 -mcpu=7450 -frecord-gcc-switches -xc -o - - < /dev/null |
grep -E 'mcpu|machine'
.ascii  "-mcpu=7450"

 # gcc-10.4.0 -S -m32 -mcpu=7450 -frecord-gcc-switches -xc -o - - < /dev/null |
grep -E 'mcpu|machine'
.machine "7450"
.ascii  "-mcpu=7450"

 # gcc-11.3.0 -S -m32 -mcpu=7450 -frecord-gcc-switches -xc -o - - < /dev/null |
grep -E 'mcpu|machine'
.machine power7
.string "GNU C17 11.3.0 -msecure-plt -m32 -mcpu=7450"

 # gcc-12.1.1 -S -m32 -mcpu=7450 -frecord-gcc-switches -xc -o - - < /dev/null |
grep -E 'mcpu|machine'
.machine "7450"
.string "GNU C17 12.1.1 20220625 -msecure-plt -m32 -mcpu=7450"

This would be on the 32bit chroot of my Talos II.

Re: Resend: Potential upcoming changes in mangling to PowerPC GCC

[Segher Boessenkool]

On Wed, Aug 10, 2022 at 04:55:42PM -0300, Tulio Magno Quites Machado Filho 
wrote:
> Michael Meissner via Gcc  writes:
> > Because long double mangles the same as either __float128 or __ibm128, you
> > cannot write programs like:
> >
> > double convert (__ibm128x) { return x; }
> > double convert (__float128  x) { return x; }
> > double convert (long double x) { return x; }
> >
> > You would have to write on a system with long double being IBM 128-bit:
> >
> > double convert (__float128  x) { return x; }
> > double convert (long double x) { return x; }
> >
> > or on a system with long double being IEEE 128-bit:
> >
> > double convert (__ibm128x) { return x; }
> > double convert (long double x) { return x; }
> 
> Does that mean, when long double is IEEE 128-bit, the compiler won't support
> _Float128/__float128 ?

You can write
double convert (__ibm128  x) { return x; }
double convert (__ieee128 x) { return x; }
as well.  "__ieee128" and "long double" are the same type then (and the
same as _Float128 and __float128 as well).


Segher

Re: Resend: Potential upcoming changes in mangling to PowerPC GCC

[Tulio Magno Quites Machado Filho via Gcc]

Michael Meissner via Gcc  writes:

> Because long double mangles the same as either __float128 or __ibm128, you
> cannot write programs like:
>
>   double convert (__ibm128x) { return x; }
>   double convert (__float128  x) { return x; }
>   double convert (long double x) { return x; }
>
> You would have to write on a system with long double being IBM 128-bit:
>
>   double convert (__float128  x) { return x; }
>   double convert (long double x) { return x; }
>
> or on a system with long double being IEEE 128-bit:
>
>   double convert (__ibm128x) { return x; }
>   double convert (long double x) { return x; }

Does that mean, when long double is IEEE 128-bit, the compiler won't support
_Float128/__float128 ?

-- 
Tulio Magno

[Bug ipa/106061] [13 Regression] during GIMPLE pass: einline ICE: verify_cgraph_node failed (edge points to wrong declaration) with -Og since r13-1204-gd68d366425369649

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||muecker at gwdg dot de

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

[Bug sanitizer/106580] ICE with UBSan and -fsanitize-undefined-trap-on-error

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Dup of bug 106061

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

[Bug middle-end/106492] [OpenMP] ICE in #pragma omp for simd and bitfields

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

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Tobias Burnus
:

https://gcc.gnu.org/g:68b8c55c7e7de8438ea97f600cdccac826b8e67d

commit r12-8678-g68b8c55c7e7de8438ea97f600cdccac826b8e67d
Author: Tobias Burnus 
Date:   Tue Aug 9 07:57:40 2022 +0200

OpenMP: Fix folding with simd's linear clause [PR106492]

gcc/ChangeLog:

PR middle-end/106492
* omp-low.cc (lower_rec_input_clauses): Add missing folding
to data type of linear-clause list item.

gcc/testsuite/ChangeLog:

PR middle-end/106492
* g++.dg/gomp/pr106492.C: New test.

(cherry picked from commit 8a16b9f983824b6b9a25275cd23b6bba8c98b800)

[Bug sanitizer/106580] New: ICE with UBSan and -fsanitize-undefined-trap-on-error

[muecker at gwdg dot de via Gcc-bugs]

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

Bug ID: 106580
   Summary: ICE with UBSan and -fsanitize-undefined-trap-on-error
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: muecker at gwdg dot de
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

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

The following reduced test case produces an ICE on turnk with:

-O1 -fsanitize=undefined -fsanitize-undefined-trap-on-error


extern void f(void);
static void g(int typ)
{
switch (typ) {

case 1:
f();
}
}

extern void e(void)
{
return g(0);
}

extern void h(void)
{
return g(1);
}

https://godbolt.org/z/YdKTEfovY

Re: Rust frontend patches v1

[David Malcolm via Gcc-patches]

On Wed, 2022-08-10 at 19:56 +0100, Philip Herron wrote:
> Hi everyone
> 
> For my v2 of the patches, I've been spending a lot of time ensuring
> each patch is buildable. It would end up being simpler if it was
> possible if each patch did not have to be like this so I could split
> up the front-end in more patches. Does this make sense?

Yes.  I've often split up patches into chunks when posting them for
review, and I see other people here do that.

It makes it easier for the reviewer also, since it's usually easier to
deal with e.g. 10 small patches than one enormous one (e.g. if many of
them are uncontroversial, having them split up makes it easier to focus
attention on just the controversial areas).

>  In theory,
> when everything goes well, does this still mean that we can merge in
> one commit, 

Split up the patches for review, but make a note in the cover letter
than they would all be merged into one when committing.

(especially if doing the split is taking up a lot of time; we don't
want to be mandating busy-work)

Dave


> or should it follow a series of buildable patches? I've
> received feedback that it might be possible to ignore making each
> patch an independent chunk and just focus on splitting it up as small
> as possible even if they don't build.
> 
> I hope this makes sense.
> 
> Thanks
> 
> --Phil
> 
> On Thu, 28 Jul 2022 at 10:39, Philip Herron < 
> philip.her...@embecosm.com> wrote:
> > 
> > Thanks, for confirming David. I think it was too big in the end. I
> > was
> > trying to figure out how to actually split that up but it seems
> > reasonable that I can split up the front-end patches into patches
> > for
> > each separate pass in the compiler seems like a reasonable approach
> > for now.
> > 
> > --Phil
> > 
> > On Wed, 27 Jul 2022 at 17:45, David Malcolm 
> > wrote:
> > > 
> > > On Wed, 2022-07-27 at 14:40 +0100, herron.philip--- via Gcc-
> > > patches
> > > wrote:
> > > > This is the initial version 1 patch set for the Rust front-end.
> > > > There
> > > > are more changes that need to be extracted out for all the
> > > > target
> > > > hooks we have implemented. The goal is to see if we are
> > > > implementing
> > > > the target hooks information for x86 and arm. We have more
> > > > patches
> > > > for the other targets I can add in here but they all follow the
> > > > pattern established here.
> > > > 
> > > > Each patch is buildable on its own and rebased ontop of
> > > > 718cf8d0bd32689192200d2156722167fd21a647. As for ensuring we
> > > > keep
> > > > attribution for all the patches we have received in the front-
> > > > end
> > > > should we create a CONTRIBUTOR's file inside the front-end
> > > > folder?
> > > > 
> > > > Note thanks to Thomas Schwinge and Mark Wielaard, we are
> > > > keeping a
> > > > branch up to date with our code on:
> > > >  
> > > > https://gcc.gnu.org/git/?p=gcc.git;a=shortlog;h=refs/heads/devel/rust/master
> > > >  but this is not rebased ontop of gcc head.
> > > > 
> > > > Let me know if I have sent these patches correctly or not, this
> > > > is a
> > > > learning experience with git send-email.
> > > > 
> > > > [PATCH Rust front-end v1 1/4] Add skeleton Rust front-end
> > > > folder
> > > > [PATCH Rust front-end v1 2/4] Add Rust lang TargetHooks for
> > > > i386 and
> > > > [PATCH Rust front-end v1 3/4] Add Rust target hooks to ARM
> > > > [PATCH Rust front-end v1 4/4] Add Rust front-end and associated
> > > 
> > > FWIW it looks like patch 4 of the kit didn't make it (I didn't
> > > get a
> > > copy and I don't see it in the archives).
> > > 
> > > Maybe it exceeded a size limit?  If so, maybe try splitting it up
> > > into
> > > more patches.
> > > 
> > > Dave
> > > 
> 

Re: Rust frontend patches v1

[Philip Herron]

Hi everyone

For my v2 of the patches, I've been spending a lot of time ensuring
each patch is buildable. It would end up being simpler if it was
possible if each patch did not have to be like this so I could split
up the front-end in more patches. Does this make sense? In theory,
when everything goes well, does this still mean that we can merge in
one commit, or should it follow a series of buildable patches? I've
received feedback that it might be possible to ignore making each
patch an independent chunk and just focus on splitting it up as small
as possible even if they don't build.

I hope this makes sense.

Thanks

--Phil

On Thu, 28 Jul 2022 at 10:39, Philip Herron  wrote:
>
> Thanks, for confirming David. I think it was too big in the end. I was
> trying to figure out how to actually split that up but it seems
> reasonable that I can split up the front-end patches into patches for
> each separate pass in the compiler seems like a reasonable approach
> for now.
>
> --Phil
>
> On Wed, 27 Jul 2022 at 17:45, David Malcolm  wrote:
> >
> > On Wed, 2022-07-27 at 14:40 +0100, herron.philip--- via Gcc-patches
> > wrote:
> > > This is the initial version 1 patch set for the Rust front-end. There
> > > are more changes that need to be extracted out for all the target
> > > hooks we have implemented. The goal is to see if we are implementing
> > > the target hooks information for x86 and arm. We have more patches
> > > for the other targets I can add in here but they all follow the
> > > pattern established here.
> > >
> > > Each patch is buildable on its own and rebased ontop of
> > > 718cf8d0bd32689192200d2156722167fd21a647. As for ensuring we keep
> > > attribution for all the patches we have received in the front-end
> > > should we create a CONTRIBUTOR's file inside the front-end folder?
> > >
> > > Note thanks to Thomas Schwinge and Mark Wielaard, we are keeping a
> > > branch up to date with our code on:
> > > https://gcc.gnu.org/git/?p=gcc.git;a=shortlog;h=refs/heads/devel/rust/master
> > >  but this is not rebased ontop of gcc head.
> > >
> > > Let me know if I have sent these patches correctly or not, this is a
> > > learning experience with git send-email.
> > >
> > > [PATCH Rust front-end v1 1/4] Add skeleton Rust front-end folder
> > > [PATCH Rust front-end v1 2/4] Add Rust lang TargetHooks for i386 and
> > > [PATCH Rust front-end v1 3/4] Add Rust target hooks to ARM
> > > [PATCH Rust front-end v1 4/4] Add Rust front-end and associated
> >
> > FWIW it looks like patch 4 of the kit didn't make it (I didn't get a
> > copy and I don't see it in the archives).
> >
> > Maybe it exceeded a size limit?  If so, maybe try splitting it up into
> > more patches.
> >
> > Dave
> >

Re: [PATCH] analyzer: fix ICE casued by dup2 in sm-fd.cc[PR106551]

[David Malcolm via Gcc-patches]

On Wed, 2022-08-10 at 22:51 +0530, Mir Immad wrote:
>  > Can you please rebase and see if your patch
> > does fix it?
> 
> No, the patch that I sent did not attempt to fix this. Now that I
> have made
> the correction, XFAIL in fd-uninit-1.c has changed to XPASS.

Great - that means that, with your fix, we no longer bogusly emit that
false positive.

> 
> Should i remove the dg-bogus warning from fd-uninit-1.c test_1?

Yes please.

Thanks
Dave

> 
> Thanks.
> Immad.
> 
> 
> On Wed, Aug 10, 2022 at 10:26 PM David Malcolm 
> wrote:
> 
> > On Wed, 2022-08-10 at 20:34 +0530, Mir Immad wrote:
> > >  > if you convert the "int m;" locals into an extern global, like
> > > in
> > > > comment #0 of bug 106551, does that still trigger the crash on
> > > > the
> > > > unpatched sm-fd.cc?
> > > 
> > > Yes, it does, since m would be in "m_start" state. I'm sending an
> > > updated
> > > patch.
> > 
> > Great!
> > 
> > Note that I recently committed a fix for bug 106573, which has an
> > xfail
> > on a dg-bogus to mark a false positive which your patch hopefully
> > also
> > fixes (in fd-uninit-1.c).  Can you please rebase and see if your
> > patch
> > does fix it?
> > 
> > Thanks
> > Dave
> > 
> > 
> > > 
> > > Thanks
> > > Immad.
> > > 
> > > On Wed, Aug 10, 2022 at 1:32 AM David Malcolm <
> > > dmalc...@redhat.com>
> > > wrote:
> > > 
> > > > On Tue, 2022-08-09 at 21:42 +0530, Immad Mir wrote:
> > > > > This patch fixes the ICE caused by valid_to_unchecked_state,
> > > > > at analyzer/sm-fd.cc by handling the m_start state in
> > > > > check_for_dup.
> > > > > 
> > > > > Tested lightly on x86_64.
> > > > > 
> > > > > gcc/analyzer/ChangeLog:
> > > > >     PR analyzer/106551
> > > > >     * sm-fd.cc (check_for_dup): handle the m_start
> > > > >     state when transitioning the state of LHS
> > > > >     of dup, dup2 and dup3 call.
> > > > > 
> > > > > gcc/testsuite/ChangeLog:
> > > > >     * gcc.dg/analyzer/fd-dup-1.c: New testcases.
> > > > > 
> > > > > Signed-off-by: Immad Mir 
> > > > > ---
> > > > >  gcc/analyzer/sm-fd.cc    |  4 ++--
> > > > >  gcc/testsuite/gcc.dg/analyzer/fd-dup-1.c | 28
> > > > > +++-
> > > > >  2 files changed, 29 insertions(+), 3 deletions(-)
> > > > > 
> > > > > diff --git a/gcc/analyzer/sm-fd.cc b/gcc/analyzer/sm-fd.cc
> > > > > index 8bb76d72b05..c8b9930a7b6 100644
> > > > > --- a/gcc/analyzer/sm-fd.cc
> > > > > +++ b/gcc/analyzer/sm-fd.cc
> > > > > @@ -983,7 +983,7 @@ fd_state_machine::check_for_dup
> > > > > (sm_context
> > > > > *sm_ctxt, const supernode *node,
> > > > >  case DUP_1:
> > > > >    if (lhs)
> > > > >     {
> > > > > - if (is_constant_fd_p (state_arg_1))
> > > > > + if (is_constant_fd_p (state_arg_1) || state_arg_1
> > > > > ==
> > > > > m_start)
> > > > >     sm_ctxt->set_next_state (stmt, lhs,
> > > > > m_unchecked_read_write);
> > > > >   else
> > > > >     sm_ctxt->set_next_state (stmt, lhs,
> > > > > @@ -1011,7 +1011,7 @@ fd_state_machine::check_for_dup
> > > > > (sm_context
> > > > > *sm_ctxt, const supernode *node,
> > > > >    file descriptor i.e the first argument.  */
> > > > >    if (lhs)
> > > > >     {
> > > > > - if (is_constant_fd_p (state_arg_1))
> > > > > + if (is_constant_fd_p (state_arg_1) || state_arg_1
> > > > > ==
> > > > > m_start)
> > > > >     sm_ctxt->set_next_state (stmt, lhs,
> > > > > m_unchecked_read_write);
> > > > >   else
> > > > >     sm_ctxt->set_next_state (stmt, lhs,
> > > > > diff --git a/gcc/testsuite/gcc.dg/analyzer/fd-dup-1.c
> > > > > b/gcc/testsuite/gcc.dg/analyzer/fd-dup-1.c
> > > > > index eba2570568f..ed4d6de57db 100644
> > > > > --- a/gcc/testsuite/gcc.dg/analyzer/fd-dup-1.c
> > > > > +++ b/gcc/testsuite/gcc.dg/analyzer/fd-dup-1.c
> > > > > @@ -220,4 +220,30 @@ test_19 (const char *path, void *buf)
> > > > >  close (fd);
> > > > >  }
> > > > > 
> > > > > -}
> > > > > \ No newline at end of file
> > > > > +}
> > > > > +
> > > > > +void
> > > > > +test_20 ()
> > > > > +{
> > > > > +    int m;
> > > > > +    int fd = dup (m); /* { dg-warning "'dup' on possibly
> > > > > invalid
> > > > > file descriptor 'm'" } */
> > > > > +    close (fd);
> > > > > +}
> > > > > +
> > > > > +void
> > > > > +test_21 ()
> > > > > +{
> > > > > +    int m;
> > > > > +    int fd = dup2 (m, 1); /* { dg-warning "'dup2' on
> > > > > possibly
> > > > > invalid file descriptor 'm'" } */
> > > > > +    close (fd);
> > > > > +}
> > > > > +
> > > > > +void
> > > > > +test_22 (int flags)
> > > > > +{
> > > > > +    int m;
> > > > > +    int fd = dup3 (m, 1, flags); /* { dg-warning "'dup3' on
> > > > > possibly
> > > > > invalid file descriptor 'm'" } */
> > > > > +    close (fd);
> > > > > +}
> > > > 
> > > > Thanks for the updated patch.
> > > > 
> > > > The test cases looked suspicious to me - I was wondering why
> > > > the
> > > > analyzer doesn't complain about the uninitialized values 

[PATCH] Complete __gnu_test::basic_string<>::compare support

[François Dumont via Gcc-patches]

Here is another patch to complete __gnu_debug::basic_string<> Standard 
conformity. This one is adding the missing compare overloads.


I also would like to propose to change how __gnu_debug::basic_string<> 
is tested. I considered activating  checks when 
_GLIBCXX_ASSERTIONS is defined but it turns out that to do so this 
light-debug mode should then also consider _GLIBCXX_DEBUG_PEDANTIC. I 
prefer to avoid this.


So I restored previous behavior. I'm now checking for the 
_GLIBCXX_TEST_DEBUG_STRING macro to force usage of . This 
way I am testing it using:


make check-debug CXXFLAGS=-D_GLIBCXX_TEST_DEBUG_STRING

    libstdc++: Add __gnu_debug::basic_string<>::compare overloads

    Rather than adding those implementations we are ading a:
    using _Base::compare;

    so that any compare method not implemented at __gnu_debug::basic_string
    level are injected from the base class.

    Also review how __gnu_debug::basic_string is tested. Now require to 
define

    _GLIBCXX_TEST_DEBUG_STRING when running 'make check-debug'.

    libstdc++-v3/ChangeLog

    * include/debug/string: Add using _Base::compare.
    (__gnu_debug::basic_string<>::compare(const 
basic_string<>&)): Remove.
    (__gnu_debug::basic_string<>::compare(size_type, size_type, 
const basic_string<>&)):

    Remove.
    (__gnu_debug::basic_string<>::compare(size_type, size_type, 
const basic_string<>&,

    size_type, size_type)): Remove.
    * testsuite/util/testsuite_string.h 
[_GLIBCXX_TEST_DEBUG_STRING]: Include .
    * 
testsuite/21_strings/basic_string/operations/compare/char/1.cc: Include 
testsuite_string.h

    and use __gnu_test::string.
    * 
testsuite/21_strings/basic_string/operations/compare/char/13650.cc: 
Likewise.
    * 
testsuite/21_strings/basic_string/operations/compare/char/2.cc: Likewise.
    * 
testsuite/21_strings/basic_string/operations/rfind/char/1.cc: Likewise.
    * 
testsuite/21_strings/basic_string/operations/rfind/char/2.cc: Likewise.
    * 
testsuite/21_strings/basic_string/operations/rfind/char/3.cc: Likewise.
    * 
testsuite/21_strings/basic_string/operations/compare/wchar_t/1.cc: 
Include testsuite_string.h

    and use __gnu_test::wstring.
    * 
testsuite/21_strings/basic_string/operations/compare/wchar_t/13650.cc: 
Likewise.
    * 
testsuite/21_strings/basic_string/operations/compare/wchar_t/2.cc: Likewise.


Tested under Linux x86_64.

Ok to commit ?

François
diff --git a/libstdc++-v3/include/debug/string b/libstdc++-v3/include/debug/string
index a4482db4af5..c32eb41eacd 100644
--- a/libstdc++-v3/include/debug/string
+++ b/libstdc++-v3/include/debug/string
@@ -1002,22 +1002,11 @@ namespace __gnu_debug
   substr(size_type __pos = 0, size_type __n = _Base::npos) const
   { return basic_string(_Base::substr(__pos, __n)); }
 
-  int
-  compare(const basic_string& __str) const
-  { return _Base::compare(__str); }
-
-  int
-  compare(size_type __pos1, size_type __n1,
-	  const basic_string& __str) const
-  { return _Base::compare(__pos1, __n1, __str); }
-
-  int
-  compare(size_type __pos1, size_type __n1, const basic_string& __str,
-	  size_type __pos2, size_type __n2) const
-  { return _Base::compare(__pos1, __n1, __str, __pos2, __n2); }
+  using _Base::compare;
 
+  _GLIBCXX20_CONSTEXPR
   int
-  compare(const _CharT* __s) const
+  compare(const _CharT* __s) const _GLIBCXX_NOEXCEPT
   {
 	__glibcxx_check_string(__s);
 	return _Base::compare(__s);
@@ -1025,6 +1014,7 @@ namespace __gnu_debug
 
   //  _GLIBCXX_RESOLVE_LIB_DEFECTS
   //  5. string::compare specification questionable
+  _GLIBCXX20_CONSTEXPR
   int
   compare(size_type __pos1, size_type __n1, const _CharT* __s) const
   {
@@ -1034,6 +1024,7 @@ namespace __gnu_debug
 
   //  _GLIBCXX_RESOLVE_LIB_DEFECTS
   //  5. string::compare specification questionable
+  _GLIBCXX20_CONSTEXPR
   int
   compare(size_type __pos1, size_type __n1,const _CharT* __s,
 	  size_type __n2) const
diff --git a/libstdc++-v3/testsuite/21_strings/basic_string/operations/compare/char/1.cc b/libstdc++-v3/testsuite/21_strings/basic_string/operations/compare/char/1.cc
index 0bef0d2dd3d..c04b83c4896 100644
--- a/libstdc++-v3/testsuite/21_strings/basic_string/operations/compare/char/1.cc
+++ b/libstdc++-v3/testsuite/21_strings/basic_string/operations/compare/char/1.cc
@@ -29,7 +29,7 @@
 // NB compare should be thought of as a lexographical compare, ie how
 // things would be sorted in a dictionary.
 
-#include 
+#include 
 #include 
 #include 
 
@@ -67,7 +67,7 @@ test_value(int result, want_value expected)
 int 
 test01()
 {
-  using namespace std;
+  using namespace __gnu_test;
 
   string 	str_0("costa rica");
   string 	str_1("costa marbella");
diff --git 

[Bug tree-optimization/106458] [12/13 Regression] glibc's malloc/tst-scratch_buffer.c test is miscompiled with gcc-12

[dave.anglin at bell dot net via Gcc-bugs]

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

--- Comment #14 from dave.anglin at bell dot net ---
On 2022-08-10 1:38 p.m., dave.anglin at bell dot net wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106458
>
> --- Comment #13 from dave.anglin at bell dot net ---
> On 2022-08-10 9:30 a.m., rguenth at gcc dot gnu.org wrote:
>> You could try if -fno-tree-pre reproduces it also before the change.
> It doesn't.
But the test does not fail after the change with -fno-tree-pre.

[Bug fortran/106579] ieee_signaling_nan problem in fortran on powerpc64

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||fxcoudert at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Ouch, indeed.
Looking at ieee/ieee_exceptions.F90, I think that one is ok, while
__ieee_exceptions_MOD_ieee_support_flag_16
is exported from the library, all of
__ieee_exceptions_MOD_ieee_support_flag_{4,8,16} return the same result and I
think it is the same for both IEEE quad and IBM double double formats too,
so using __ieee_exceptions_MOD_ieee_support_flag_16 for it is fine.
On the other side, ieee/ieee_arithmetic.F90 is problematic.
I must say I don't understand at all stuff like IEEE_IS_FINITE, because it
refers
to stuff like _gfortran_ieee_is_finite_16 which I don't see anywhere in
libgfortran.{so.5,a}.
Looking purely on what is exported from libgfortran.so.5 from the
ieee_arithmetic module symbols, I see:
readelf -Wa ../powerpc64le-unknown-linux-gnu/libgfortran/.libs/libgfortran.so.5
| grep ieee_arith | grep _16@@
   483: 001ca77020 FUNCGLOBAL DEFAULT   11
__ieee_arithmetic_MOD_ieee_support_io_16@@GFORTRAN_8
   555: 001ca67020 FUNCGLOBAL DEFAULT   11
__ieee_arithmetic_MOD_ieee_support_sqrt_16@@GFORTRAN_8
   753: 001cac1072 FUNCGLOBAL DEFAULT   11
__ieee_arithmetic_MOD_ieee_support_rounding_16@@GFORTRAN_8   [: 8]
   771: 001caef056 FUNCGLOBAL DEFAULT   11
__ieee_arithmetic_MOD_ieee_class_16@@GFORTRAN_8  [: 8]
   795: 001ca8f020 FUNCGLOBAL DEFAULT   11
__ieee_arithmetic_MOD_ieee_support_subnormal_16@@GFORTRAN_9
   823: 001ca97020 FUNCGLOBAL DEFAULT   11
__ieee_arithmetic_MOD_ieee_support_denormal_16@@GFORTRAN_8
   961: 001ca6f020 FUNCGLOBAL DEFAULT   11
__ieee_arithmetic_MOD_ieee_support_nan_16@@GFORTRAN_8
  1220: 001cae3060 FUNCGLOBAL DEFAULT   11
__ieee_arithmetic_MOD_ieee_value_16@@GFORTRAN_8  [: 8]
  1265: 001ca7f020 FUNCGLOBAL DEFAULT   11
__ieee_arithmetic_MOD_ieee_support_inf_16@@GFORTRAN_8
  1502: 001caad072 FUNCGLOBAL DEFAULT   11
__ieee_arithmetic_MOD_ieee_support_underflow_control_16@@GFORTRAN_8 
[: 8]
  1532: 001ca5f020 FUNCGLOBAL DEFAULT   11
__ieee_arithmetic_MOD_ieee_support_standard_16@@GFORTRAN_8
  1596: 001ca87020 FUNCGLOBAL DEFAULT   11
__ieee_arithmetic_MOD_ieee_support_divide_16@@GFORTRAN_8
  1703: 001ca9f020 FUNCGLOBAL DEFAULT   11
__ieee_arithmetic_MOD_ieee_support_datatype_16@@GFORTRAN_8

Now, most of the above are probably fine too, they just return true and again
that answer seems to be fine for both when
real(kind=16) is IBM double double or IEEE quad.
The problematic cases from those are:
__ieee_arithmetic_MOD_ieee_class_16
__ieee_arithmetic_MOD_ieee_value_16
The above 2 clearly need different behavior when real(kind=16) is IEEE quad vs.
IBM double double, the
implementation right now implements those for IBM double double.
So, either we need to arrange for those to be expanded inline by the frontend
(and it can be done either
by hardcoding the enumerators or say transforming the calls from working with
IEEE quad to working with
IBM double double or vice versa), or we need to add
__ieee_arithmetic_MOD_ieee_class_17
__ieee_arithmetic_MOD_ieee_value_17
entrypoints to the library and arrange for the _16 to be remapped to _17 for
these 2.
Other possibly problematic functions are
__ieee_arithmetic_MOD_ieee_support_rounding_16
__ieee_arithmetic_MOD_ieee_support_underflow_control_16
The former seems to do the exact same call in each case, so is probably fine
like the true cases,
the latter actually calls support_underflow_control_helper with kind value, but
it is ignored everywhere but alpha,
so is fine too.

For the transformation above, I mean something like handling ieee_class by
doing __builtin_fpclassify + issignalling
and __builtin_signbit and depending on the result call
__ieee_arithmetic_MOD_ieee_class_16 on sample IBM double double
values with the same properties.
Similarly, ieee_value by calling __ieee_arithmetic_MOD_ieee_value_16 first,
analyzing the result with
__builtin_fpclassify and in most cases just converting the IBM double double to
IEEE quad.
Guess NaNs (especially signalling NaN) and denormals need to be an exception.

Another question is if one needs to implement these as actual out of line
functions (even hidden), whether it is
permissible to say call some function/subroutine with ieee_value or ieee_class
as procedure argument.
Given that they are overloaded, I'd hope it is not possible.

Re: [PATCH v3] Modify combine pattern by a pseudo AND with its nonzero bits [PR93453]

[Segher Boessenkool]

Hi!

Sorry for the tardiness.

On Fri, Jul 22, 2022 at 03:07:55PM +0800, HAO CHEN GUI wrote:
>   This patch creates a new function - change_pseudo_and_mask. If recog fails,
> the function converts a single pseudo to the pseudo AND with a mask if the
> outer operator is IOR/XOR/PLUS and inner operator is ASHIFT or AND. The
> conversion helps pattern to match rotate and mask insn on some targets.

The name isn't so clear.  It isn't changing a mask, to start with.

> +/* When the outer code of set_src is IOR/XOR/PLUS and the inner code is
> +   ASHIFT/AND,

"When the outercode of the SET_SRC of PAT is ..."

> convert a pseudo to pseudo AND with a mask if its nonzero_bits
> +   is less than its mode mask.  The nonzero_bits in later passes is not a
> +   superset of what is known in combine pass.  So an insn with nonzero_bits
> +   can't be recoged later.  */

Can this not be done with a splitter in the machine description?


Segher

[Bug tree-optimization/106458] [12/13 Regression] glibc's malloc/tst-scratch_buffer.c test is miscompiled with gcc-12

[dave.anglin at bell dot net via Gcc-bugs]

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

--- Comment #13 from dave.anglin at bell dot net ---
On 2022-08-10 9:30 a.m., rguenth at gcc dot gnu.org wrote:
> You could try if -fno-tree-pre reproduces it also before the change.
It doesn't.

Re: [PATCH] analyzer: fix ICE casued by dup2 in sm-fd.cc[PR106551]

[Mir Immad via Gcc-patches]

 > Can you please rebase and see if your patch
> does fix it?

No, the patch that I sent did not attempt to fix this. Now that I have made
the correction, XFAIL in fd-uninit-1.c has changed to XPASS.

Should i remove the dg-bogus warning from fd-uninit-1.c test_1?

Thanks.
Immad.


On Wed, Aug 10, 2022 at 10:26 PM David Malcolm  wrote:

> On Wed, 2022-08-10 at 20:34 +0530, Mir Immad wrote:
> >  > if you convert the "int m;" locals into an extern global, like in
> > > comment #0 of bug 106551, does that still trigger the crash on the
> > > unpatched sm-fd.cc?
> >
> > Yes, it does, since m would be in "m_start" state. I'm sending an
> > updated
> > patch.
>
> Great!
>
> Note that I recently committed a fix for bug 106573, which has an xfail
> on a dg-bogus to mark a false positive which your patch hopefully also
> fixes (in fd-uninit-1.c).  Can you please rebase and see if your patch
> does fix it?
>
> Thanks
> Dave
>
>
> >
> > Thanks
> > Immad.
> >
> > On Wed, Aug 10, 2022 at 1:32 AM David Malcolm 
> > wrote:
> >
> > > On Tue, 2022-08-09 at 21:42 +0530, Immad Mir wrote:
> > > > This patch fixes the ICE caused by valid_to_unchecked_state,
> > > > at analyzer/sm-fd.cc by handling the m_start state in
> > > > check_for_dup.
> > > >
> > > > Tested lightly on x86_64.
> > > >
> > > > gcc/analyzer/ChangeLog:
> > > > PR analyzer/106551
> > > > * sm-fd.cc (check_for_dup): handle the m_start
> > > > state when transitioning the state of LHS
> > > > of dup, dup2 and dup3 call.
> > > >
> > > > gcc/testsuite/ChangeLog:
> > > > * gcc.dg/analyzer/fd-dup-1.c: New testcases.
> > > >
> > > > Signed-off-by: Immad Mir 
> > > > ---
> > > >  gcc/analyzer/sm-fd.cc|  4 ++--
> > > >  gcc/testsuite/gcc.dg/analyzer/fd-dup-1.c | 28
> > > > +++-
> > > >  2 files changed, 29 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/gcc/analyzer/sm-fd.cc b/gcc/analyzer/sm-fd.cc
> > > > index 8bb76d72b05..c8b9930a7b6 100644
> > > > --- a/gcc/analyzer/sm-fd.cc
> > > > +++ b/gcc/analyzer/sm-fd.cc
> > > > @@ -983,7 +983,7 @@ fd_state_machine::check_for_dup (sm_context
> > > > *sm_ctxt, const supernode *node,
> > > >  case DUP_1:
> > > >if (lhs)
> > > > {
> > > > - if (is_constant_fd_p (state_arg_1))
> > > > + if (is_constant_fd_p (state_arg_1) || state_arg_1 ==
> > > > m_start)
> > > > sm_ctxt->set_next_state (stmt, lhs,
> > > > m_unchecked_read_write);
> > > >   else
> > > > sm_ctxt->set_next_state (stmt, lhs,
> > > > @@ -1011,7 +1011,7 @@ fd_state_machine::check_for_dup (sm_context
> > > > *sm_ctxt, const supernode *node,
> > > >file descriptor i.e the first argument.  */
> > > >if (lhs)
> > > > {
> > > > - if (is_constant_fd_p (state_arg_1))
> > > > + if (is_constant_fd_p (state_arg_1) || state_arg_1 ==
> > > > m_start)
> > > > sm_ctxt->set_next_state (stmt, lhs,
> > > > m_unchecked_read_write);
> > > >   else
> > > > sm_ctxt->set_next_state (stmt, lhs,
> > > > diff --git a/gcc/testsuite/gcc.dg/analyzer/fd-dup-1.c
> > > > b/gcc/testsuite/gcc.dg/analyzer/fd-dup-1.c
> > > > index eba2570568f..ed4d6de57db 100644
> > > > --- a/gcc/testsuite/gcc.dg/analyzer/fd-dup-1.c
> > > > +++ b/gcc/testsuite/gcc.dg/analyzer/fd-dup-1.c
> > > > @@ -220,4 +220,30 @@ test_19 (const char *path, void *buf)
> > > >  close (fd);
> > > >  }
> > > >
> > > > -}
> > > > \ No newline at end of file
> > > > +}
> > > > +
> > > > +void
> > > > +test_20 ()
> > > > +{
> > > > +int m;
> > > > +int fd = dup (m); /* { dg-warning "'dup' on possibly invalid
> > > > file descriptor 'm'" } */
> > > > +close (fd);
> > > > +}
> > > > +
> > > > +void
> > > > +test_21 ()
> > > > +{
> > > > +int m;
> > > > +int fd = dup2 (m, 1); /* { dg-warning "'dup2' on possibly
> > > > invalid file descriptor 'm'" } */
> > > > +close (fd);
> > > > +}
> > > > +
> > > > +void
> > > > +test_22 (int flags)
> > > > +{
> > > > +int m;
> > > > +int fd = dup3 (m, 1, flags); /* { dg-warning "'dup3' on
> > > > possibly
> > > > invalid file descriptor 'm'" } */
> > > > +close (fd);
> > > > +}
> > >
> > > Thanks for the updated patch.
> > >
> > > The test cases looked suspicious to me - I was wondering why the
> > > analyzer doesn't complain about the uninitialized values being
> > > passed
> > > to the various dup functions as parameters.  So your test cases
> > > seem to
> > > have uncovered a hidden pre-existing bug in the analyzer's
> > > uninitialized value detection, which I've filed for myself to deal
> > > with
> > > as PR analyzer/106573.
> > >
> > > If you convert the "int m;" locals into an extern global, like in
> > > comment #0 of bug 106551, does that still trigger the crash on the
> > > unpatched sm-fd.cc?  If so, then that's greatly preferable as a
> > > regression test, since otherwise I'll have to modify that test case
> > > 

Re: Resend: Potential upcoming changes in mangling to PowerPC GCC

[Segher Boessenkool]

On Mon, Aug 08, 2022 at 05:44:36PM -0400, Michael Meissner wrote:
> On Thu, Aug 04, 2022 at 03:53:55PM -0500, Segher Boessenkool wrote:
> > On Thu, Aug 04, 2022 at 01:48:51PM -0400, Michael Meissner wrote:
> > It would be a lot simpler and less roundabout and inside out if we could
> > do this the other way around: start with the QP float and double-double
> > types and modes, and point the long double type and TFmode at that.  But
> > alas.
> 
> Yes if we could go back 5 years it would have been simpler to do that way.

It does not require time machines: we can change the current code *now*.

> > > These 3 tests use the
> > > 'nanqs' built-in function, which is mapped to 'nanf128s' and it delivers a
> > > _Float128 signaling NaN.  But since __float128 uses a different type, the
> > > signaling NaN is converted and it loses the signaling property.
> > 
> > So you are saying __float128 and _Float128 should *not* be separate
> > types?  Or, the testcases are buggy, make unwarranted assumptions?
> 
> I am saying right now, they are separate types when -mabi=ieeelongdouble is
> used.  They are the same type when -mabi=ibmlongdouble is used.  I think they
> should be the same type, no matter which way long double is defined.

Ah, good.

> But there are a bunch of assumptions within the compiler that need to be
> changed due to these assumptions.

> > > In addition, it would be nice if we could refine the setting of bits in 
> > > the ELF
> > > header so that if you pass an explicit __float128 or __ibm128 object, it
> > > doesn't set the bits that you used long double of the appropriate type.  
> > > But
> > > the code that sets these bits is done in the RTL stages, and it only 
> > > looks at
> > > modes, not at types.
> > 
> > So fix that?  It is a clear bug.
> 
> It isn't so simple,

Yes it is.  It *is* a clear bug.

Solving it might be some work, but it has to be done, it can not be
avoided.

> > It cannot always use IFmode?  Generic code uses TFmode for long double
> > (which can be double-double).
> 
> My point is __ibm128 can potentionally be separate and always use IFmode.
> Hence my question.

It cannot be.  Generic code (on double-double configs) uses TFmode.

It is a good idea for us to use IFmode in the backend code, certainly.


Segher

[PATCH] match.pd: Add abs with bitwise and pattern [PR106243]

[Sam Feifer via Gcc-patches]

This patch adds a simplification to match.pd that was discussed on the
thread for pr106243. It simplifies the pattern, abs(x) & 1, to x & 1.

There are also tests for the simplification in this patch. I couldn't
figure out how to get abs to work with vectors. If a test for that is
necessary, could I get some guidance on using abs with vector types?

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

PR tree-optimization/106243

gcc/ChangeLog:

* match.pd (abs(x) & 1): New simplification.

gcc/testsuite/ChangeLog:

* gcc.dg/pr106243-2.c: New test.
* gcc.dg/pr106243-3.c: New test.
---
 gcc/match.pd  |  5 +
 gcc/testsuite/gcc.dg/pr106243-2.c | 31 +++
 gcc/testsuite/gcc.dg/pr106243-3.c | 18 ++
 3 files changed, 54 insertions(+)
 create mode 100644 gcc/testsuite/gcc.dg/pr106243-2.c
 create mode 100644 gcc/testsuite/gcc.dg/pr106243-3.c

diff --git a/gcc/match.pd b/gcc/match.pd
index f82f94ad1fe..c04e70f34c1 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -8071,3 +8071,8 @@ and,
 (simplify 
   (bit_and (negate @0) integer_onep@1)
   (bit_and @0 @1))
+
+/* abs(x) & 1 -> x & 1.  */
+(simplify
+  (bit_and (abs @0) integer_onep@1)
+  (bit_and @0 @1))
diff --git a/gcc/testsuite/gcc.dg/pr106243-2.c 
b/gcc/testsuite/gcc.dg/pr106243-2.c
new file mode 100644
index 000..27e66f59160
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr106243-2.c
@@ -0,0 +1,31 @@
+/* PR tree-optimization/106243 */
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-optimized" } */
+
+#include 
+
+__attribute__((noipa)) int foo (int x) {
+return abs(x) & 1; 
+}
+
+__attribute__((noipa)) int bar (int x) {
+return (0 - abs(x)) & 1;
+}
+
+/* Commutative property.  */
+__attribute__((noipa)) int baz (int x) {
+return 1 & abs(x);
+}
+
+/* Forward propogation.  */
+__attribute__((noipa)) int qux (int x) {
+int y = abs(x);
+return y & 1;
+}
+
+/* Should not simplify.  */
+__attribute__((noipa)) int thud (int x) {
+return abs(x) & -1;
+}
+
+/* { dg-final {scan-tree-dump-times " ABS_EXPR " 1 "optimized" } } */
diff --git a/gcc/testsuite/gcc.dg/pr106243-3.c 
b/gcc/testsuite/gcc.dg/pr106243-3.c
new file mode 100644
index 000..68800868751
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr106243-3.c
@@ -0,0 +1,18 @@
+/* PR tree-optimization/106243 */
+/* { dg-do run } */
+/* { dg-options "-O2" } */
+
+#include "pr106243-2.c"
+
+int main () {
+
+if (foo(6) != 0
+|| bar(-3) != 1
+|| baz(32) != 0
+|| qux(-128) != 0
+|| foo (127) != 1) {
+__builtin_abort();
+}
+
+return 0;
+}

base-commit: be58bf98e98bb431ed26ca8be84586075fe8be82
-- 
2.31.1

Re: [PATCH v2] rs6000: Fix incorrect RTL for Power LE when removing the UNSPECS [PR106069]

[Segher Boessenkool]

On Wed, Aug 10, 2022 at 02:39:02PM +0800, Xionghu Luo wrote:
> On 2022/8/9 11:01, Kewen.Lin wrote:
> >I have some concern on those changed "altivec_*_direct", IMHO the suffix
> >"_direct" is normally to indicate the define_insn is mapped to the
> >corresponding hw insn directly.  With this change, for example,
> >altivec_vmrghb_direct can be mapped into vmrghb or vmrglb, this looks
> >misleading.  Maybe we can add the corresponding _direct_le and _direct_be
> >versions, both are mapped into the same insn but have different RTL
> >patterns.  Looking forward to Segher's and David's suggestions.
> 
> Thanks!  Do you mean same RTL patterns with different hw insn?

A pattern called altivec_vmrghb_direct_le should always emit a vmrghb
instruction, never a vmrglb instead.  Misleading names are an expensive
problem.


Segher

Re: [PATCH 0/5] IEEE 128-bit built-in overload support.

[Segher Boessenkool]

On Wed, Aug 10, 2022 at 02:23:27AM -0400, Michael Meissner wrote:
> On Fri, Aug 05, 2022 at 01:19:05PM -0500, Segher Boessenkool wrote:
> > On Thu, Jul 28, 2022 at 12:43:49AM -0400, Michael Meissner wrote:
> > > These patches lay the foundation for a set of follow-on patches that will
> > > change the internal handling of 128-bit floating point types in GCC.  In 
> > > the
> > > future patches, I hope to change the compiler to always use KFmode for the
> > > explicit _Float128/__float128 types, to always use TFmode for the long 
> > > double
> > > type, no matter which 128-bit floating point type is used, and IFmode for 
> > > the
> > > explicit __ibm128 type.
> > 
> > Making TFmode different from KFmode and IFmode is not an improvement.
> > NAK.
> 
> First of all, it already IS different from KFmode and IFmode, as we've talked
> about.

It always is the same as either IFmode or KFmode in the end.  It is a
separate mode, yes, because generic code always wants to use TFmode.

> I'm trying to clean this mess up.  Having explicit __float128's being
> converted to TFmode if -mabi=ieeelongdouble is just as bad, and it means that
> _Float128 and __float128 are not the same type.

What do types have to do with this at all?

If TFmode means IEEE QP float, TFmode and KFmode can be used
interchangeably.  When TFmode means double-double, TFmode and IFmode can
be used interchangeably.  We should never depend on TFmode being
different from both underlying modes, that way madness lies.

If you remember, in 2016 or such I experimented with making TFmode a
macro-like thingie, so that we always get KFmode and IFmode in the
instruction stream.  This did not work because of the fundamental
problem that KFmode and IFmode cannot be ordered: for both modes there
are numbers it can represent that cannot be represented in the other
mode; converting from IFmode to KFmode is lossty for some numbers, and
the same is true for converting from KFmode to IFmode.  But, some
internals of GCC require all pairs of floating point modes (that can be
converted between at least) to be comparable (in the mathmatical sense).

Until that problem is solved, we CANNOT move forward.  Your 126/127/128
precision hack gave us some time, but nothing has been improved since
then, and things have started to fall apart at the seams again


Segher

Re: [PATCH] analyzer: fix ICE casued by dup2 in sm-fd.cc[PR106551]

[David Malcolm via Gcc-patches]

On Wed, 2022-08-10 at 20:34 +0530, Mir Immad wrote:
>  > if you convert the "int m;" locals into an extern global, like in
> > comment #0 of bug 106551, does that still trigger the crash on the
> > unpatched sm-fd.cc?
> 
> Yes, it does, since m would be in "m_start" state. I'm sending an
> updated
> patch.

Great!  

Note that I recently committed a fix for bug 106573, which has an xfail
on a dg-bogus to mark a false positive which your patch hopefully also
fixes (in fd-uninit-1.c).  Can you please rebase and see if your patch
does fix it?

Thanks
Dave


> 
> Thanks
> Immad.
> 
> On Wed, Aug 10, 2022 at 1:32 AM David Malcolm 
> wrote:
> 
> > On Tue, 2022-08-09 at 21:42 +0530, Immad Mir wrote:
> > > This patch fixes the ICE caused by valid_to_unchecked_state,
> > > at analyzer/sm-fd.cc by handling the m_start state in
> > > check_for_dup.
> > > 
> > > Tested lightly on x86_64.
> > > 
> > > gcc/analyzer/ChangeLog:
> > >     PR analyzer/106551
> > >     * sm-fd.cc (check_for_dup): handle the m_start
> > >     state when transitioning the state of LHS
> > >     of dup, dup2 and dup3 call.
> > > 
> > > gcc/testsuite/ChangeLog:
> > >     * gcc.dg/analyzer/fd-dup-1.c: New testcases.
> > > 
> > > Signed-off-by: Immad Mir 
> > > ---
> > >  gcc/analyzer/sm-fd.cc    |  4 ++--
> > >  gcc/testsuite/gcc.dg/analyzer/fd-dup-1.c | 28
> > > +++-
> > >  2 files changed, 29 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/gcc/analyzer/sm-fd.cc b/gcc/analyzer/sm-fd.cc
> > > index 8bb76d72b05..c8b9930a7b6 100644
> > > --- a/gcc/analyzer/sm-fd.cc
> > > +++ b/gcc/analyzer/sm-fd.cc
> > > @@ -983,7 +983,7 @@ fd_state_machine::check_for_dup (sm_context
> > > *sm_ctxt, const supernode *node,
> > >  case DUP_1:
> > >    if (lhs)
> > >     {
> > > - if (is_constant_fd_p (state_arg_1))
> > > + if (is_constant_fd_p (state_arg_1) || state_arg_1 ==
> > > m_start)
> > >     sm_ctxt->set_next_state (stmt, lhs,
> > > m_unchecked_read_write);
> > >   else
> > >     sm_ctxt->set_next_state (stmt, lhs,
> > > @@ -1011,7 +1011,7 @@ fd_state_machine::check_for_dup (sm_context
> > > *sm_ctxt, const supernode *node,
> > >    file descriptor i.e the first argument.  */
> > >    if (lhs)
> > >     {
> > > - if (is_constant_fd_p (state_arg_1))
> > > + if (is_constant_fd_p (state_arg_1) || state_arg_1 ==
> > > m_start)
> > >     sm_ctxt->set_next_state (stmt, lhs,
> > > m_unchecked_read_write);
> > >   else
> > >     sm_ctxt->set_next_state (stmt, lhs,
> > > diff --git a/gcc/testsuite/gcc.dg/analyzer/fd-dup-1.c
> > > b/gcc/testsuite/gcc.dg/analyzer/fd-dup-1.c
> > > index eba2570568f..ed4d6de57db 100644
> > > --- a/gcc/testsuite/gcc.dg/analyzer/fd-dup-1.c
> > > +++ b/gcc/testsuite/gcc.dg/analyzer/fd-dup-1.c
> > > @@ -220,4 +220,30 @@ test_19 (const char *path, void *buf)
> > >  close (fd);
> > >  }
> > > 
> > > -}
> > > \ No newline at end of file
> > > +}
> > > +
> > > +void
> > > +test_20 ()
> > > +{
> > > +    int m;
> > > +    int fd = dup (m); /* { dg-warning "'dup' on possibly invalid
> > > file descriptor 'm'" } */
> > > +    close (fd);
> > > +}
> > > +
> > > +void
> > > +test_21 ()
> > > +{
> > > +    int m;
> > > +    int fd = dup2 (m, 1); /* { dg-warning "'dup2' on possibly
> > > invalid file descriptor 'm'" } */
> > > +    close (fd);
> > > +}
> > > +
> > > +void
> > > +test_22 (int flags)
> > > +{
> > > +    int m;
> > > +    int fd = dup3 (m, 1, flags); /* { dg-warning "'dup3' on
> > > possibly
> > > invalid file descriptor 'm'" } */
> > > +    close (fd);
> > > +}
> > 
> > Thanks for the updated patch.
> > 
> > The test cases looked suspicious to me - I was wondering why the
> > analyzer doesn't complain about the uninitialized values being
> > passed
> > to the various dup functions as parameters.  So your test cases
> > seem to
> > have uncovered a hidden pre-existing bug in the analyzer's
> > uninitialized value detection, which I've filed for myself to deal
> > with
> > as PR analyzer/106573.
> > 
> > If you convert the "int m;" locals into an extern global, like in
> > comment #0 of bug 106551, does that still trigger the crash on the
> > unpatched sm-fd.cc?  If so, then that's greatly preferable as a
> > regression test, since otherwise I'll have to modify that test case
> > when I fix bug 106573.
> > 
> > Dave
> > 
> > 
> > 
> > 

[Bug fortran/106576] Finalization of temporaries from functions not occuring

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

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

--- Comment #1 from Thomas Koenig  ---
There currently is a c.l.f. thread on this, with this test case.
Although what nagfor and xlf are doing makes sense, it does
not (to me) follow from the language of the standard.

https://groups.google.com/g/comp.lang.fortran/c/7bB13FEa10w is
the link to the thread.

Re: [PATCH] rs6000: Enable generate const through pli+pli+rldimi

[Segher Boessenkool]

Hi!

On Wed, Aug 10, 2022 at 03:11:23PM +0800, Jiufu Guo wrote:
> As mentioned in PR106550, since pli could support 34bits immediate, we could
> use less instructions(3insn would be ok) to build 64bits constant with pli.
> 
> For example, for constant 0x020805006106003, we could generate it with:
> asm code1:
> pli 9,101736451 (0x6106003)
> sldi 9,9,32
> paddi 9,9, 213 (0x0208050)
> 
> or asm code2:
> pli 10, 213
> pli 9, 101736451
> rldimi 9, 10, 32, 0
> 
> If there is only one register can be used, then the asm code1 is ok. Otherwise
> asm code2 may be better.

It is significantly better yes.  That code with sldi is perhaps what we
have to do after reload, but all those three insns are sequential,
expensive.

> This patch re-enable the constant building(splitter) before RA by updating the
> constrains from int_reg_operand_not_pseudo to gpc_reg_operand.  And then, we
> could use two different pseduo for two pli(s), and asm code2 can be generated.

> This patch also could generate asm code1 if hard register is allocated for the
> constant.

> +  else if (TARGET_PREFIXED)
> +{
> +  /* pli 9,high32 + pli 10,low32 + rldimi 9,10,32,0.  */
> +  if (can_create_pseudo_p ())
> + {
> +   temp = gen_reg_rtx (DImode);
> +   rtx temp1 = gen_reg_rtx (DImode);
> +   emit_move_insn (copy_rtx (temp), GEN_INT ((ud4 << 16) | ud3));
> +   emit_move_insn (copy_rtx (temp1), GEN_INT ((ud2 << 16) | ud1));
> +
> +   rtx one = gen_rtx_AND (DImode, temp1, GEN_INT (0x));

Why do you meed to mask the value here?  That is a nop, no?

> +   rtx two = gen_rtx_ASHIFT (DImode, temp, GEN_INT (32));
> +   emit_move_insn (dest, gen_rtx_IOR (DImode, one, two));

But you can call gen_rotldi3_insert_3 explicitly, a better idea if this
code can run late (so we cannot rely on other optimisations to clean
things up).

> --- a/gcc/config/rs6000/rs6000.md
> +++ b/gcc/config/rs6000/rs6000.md
> @@ -9659,7 +9659,7 @@ (define_split
>  ;; When non-easy constants can go in the TOC, this should use
>  ;; easy_fp_constant predicate.
>  (define_split
> -  [(set (match_operand:DI 0 "int_reg_operand_not_pseudo")
> +  [(set (match_operand:DI 0 "gpc_reg_operand")
>   (match_operand:DI 1 "const_int_operand"))]
>"TARGET_POWERPC64 && num_insns_constant (operands[1], DImode) > 1"
>[(set (match_dup 0) (match_dup 2))

This is a huge change.  Do you have some indication that it helps /
hurts / is neutral?  Some reasoning why it is a good idea?

I am not against it, but some more rationale would be good :-)

Btw, this splitter uses operands[2] and [3] in the replacement, and
neither of those exists.  The replacement never is used of course.
Instead, rs6000_emit_set_const is called always.  It would be less
misleading if the replacement text was just "(pc)" or such.


Segher

[Bug c/90885] GCC should warn about 2^16 and 2^32 and 2^64 [-Wxor-used-as-pow]

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

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

David Malcolm  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||dmalcolm at gcc dot gnu.org
  Component|c++ |c
   Assignee|unassigned at gcc dot gnu.org  |dmalcolm at gcc dot 
gnu.org

--- Comment #24 from David Malcolm  ---
I'm working on an implementation of this.

Re: [PATCH] Fix path query compute_imports for external path

[Aldy Hernandez via Gcc-patches]

Oh, and if it wasn't clear from an earlier message.  I'm OK (and
thankful) for everything you're doing in this space, especially if you
stay on top of the threading counts from patch to patch, and you get
your gori questions answered by Andrew ;-).  No sense in you getting
blocked, since you seem to be making good progress.

Aldy

On Wed, Aug 10, 2022 at 6:10 PM Aldy Hernandez  wrote:
>
> Looks good to me.
>
> Thanks.
> Aldy
>
> On Wed, Aug 10, 2022 at 3:01 PM Richard Biener  wrote:
> >
> > The following fixes the use of compute_imports from the backwards
> > threader which ends up accessing stale m_path from a previous
> > threading attempt.  The fix is to pass in the path explicitely
> > (and not the exit), and initializing it with the exit around this
> > call from the backwards threader.  That unfortunately exposed that
> > we rely on this broken behavior as the new testcase shows.  The
> > missed threading can be restored by registering all relations
> > from conditions on the path during solving, for the testcase the
> > particular important case is for relations provided by the path
> > entry conditional.
> >
> > I've verified that the GORI query for imported ranges on edges
> > is not restricted this way.
> >
> > This regresses the new ssa-thread-19.c testcase which is exactly
> > a case for the other patch re-doing how we compute imports since
> > this misses imports for defs that are not on the dominating path
> > from the exit.
> >
> > That's one of the cases this regresses (it also progresses a few
> > due to more or the correct relations added).  Overall it
> > reduces the number of threads from 98649 to 98620 on my set of
> > cc1files.  I think it's a reasonable intermediate step to find
> > a stable, less random ground to compare stats to.
> >
> > Bootstrapped and tested on x86_64-unknown-linux-gnu.
> >
> > OK?
> >
> > Thanks,
> > Richard.
> >
> > * gimple-range-path.h (path_range_query::compute_imports):
> > Take path as argument, not the exit block.
> > * gimple-range-path.cc (path_range_query::compute_imports):
> > Likewise, and adjust, avoiding possibly stale m_path.
> > (path_range_query::compute_outgoing_relations): Register
> > relations for all conditionals.
> > * tree-ssa-threadbackward.cc (back_threader::find_paths):
> > Adjust.
> >
> > * gcc.dg/tree-ssa/ssa-thread-18.c: New testcase.
> > * gcc.dg/tree-ssa/ssa-thread-19.c: Likewise, but XFAILed.
> > ---
> >  gcc/gimple-range-path.cc  | 21 +---
> >  gcc/gimple-range-path.h   |  2 +-
> >  gcc/testsuite/gcc.dg/tree-ssa/ssa-thread-18.c | 20 +++
> >  gcc/testsuite/gcc.dg/tree-ssa/ssa-thread-19.c | 33 +++
> >  gcc/tree-ssa-threadbackward.cc|  4 ++-
> >  5 files changed, 65 insertions(+), 15 deletions(-)
> >  create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/ssa-thread-18.c
> >  create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/ssa-thread-19.c
> >
> > diff --git a/gcc/gimple-range-path.cc b/gcc/gimple-range-path.cc
> > index 43e7526b6fc..389faec260c 100644
> > --- a/gcc/gimple-range-path.cc
> > +++ b/gcc/gimple-range-path.cc
> > @@ -549,7 +549,7 @@ path_range_query::add_to_imports (tree name, bitmap 
> > imports)
> >return false;
> >  }
> >
> > -// Compute the imports to the path ending in EXIT.  These are
> > +// Compute the imports to PATH.  These are
> >  // essentially the SSA names used to calculate the final conditional
> >  // along the path.
> >  //
> > @@ -559,9 +559,10 @@ path_range_query::add_to_imports (tree name, bitmap 
> > imports)
> >  // we can solve.
> >
> >  void
> > -path_range_query::compute_imports (bitmap imports, basic_block exit)
> > +path_range_query::compute_imports (bitmap imports, const vec 
> > )
> >  {
> >// Start with the imports from the exit block...
> > +  basic_block exit = path[0];
> >gori_compute  = m_ranger->gori ();
> >bitmap r_imports = gori.imports (exit);
> >bitmap_copy (imports, r_imports);
> > @@ -599,7 +600,7 @@ path_range_query::compute_imports (bitmap imports, 
> > basic_block exit)
> >   tree arg = gimple_phi_arg (phi, i)->def;
> >
> >   if (TREE_CODE (arg) == SSA_NAME
> > - && m_path.contains (e->src)
> > + && path.contains (e->src)
> >   && bitmap_set_bit (imports, SSA_NAME_VERSION (arg)))
> > worklist.safe_push (arg);
> > }
> > @@ -607,9 +608,9 @@ path_range_query::compute_imports (bitmap imports, 
> > basic_block exit)
> >  }
> >// Exported booleans along the path, may help conditionals.
> >if (m_resolve)
> > -for (i = 0; i < m_path.length (); ++i)
> > +for (i = 0; i < path.length (); ++i)
> >{
> > -   basic_block bb = m_path[i];
> > +   basic_block bb = path[i];
> > tree name;
> > FOR_EACH_GORI_EXPORT_NAME (gori, bb, name)
> >   if (TREE_CODE 

Re: [PATCH] Fix path query compute_imports for external path

[Aldy Hernandez via Gcc-patches]

Looks good to me.

Thanks.
Aldy

On Wed, Aug 10, 2022 at 3:01 PM Richard Biener  wrote:
>
> The following fixes the use of compute_imports from the backwards
> threader which ends up accessing stale m_path from a previous
> threading attempt.  The fix is to pass in the path explicitely
> (and not the exit), and initializing it with the exit around this
> call from the backwards threader.  That unfortunately exposed that
> we rely on this broken behavior as the new testcase shows.  The
> missed threading can be restored by registering all relations
> from conditions on the path during solving, for the testcase the
> particular important case is for relations provided by the path
> entry conditional.
>
> I've verified that the GORI query for imported ranges on edges
> is not restricted this way.
>
> This regresses the new ssa-thread-19.c testcase which is exactly
> a case for the other patch re-doing how we compute imports since
> this misses imports for defs that are not on the dominating path
> from the exit.
>
> That's one of the cases this regresses (it also progresses a few
> due to more or the correct relations added).  Overall it
> reduces the number of threads from 98649 to 98620 on my set of
> cc1files.  I think it's a reasonable intermediate step to find
> a stable, less random ground to compare stats to.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu.
>
> OK?
>
> Thanks,
> Richard.
>
> * gimple-range-path.h (path_range_query::compute_imports):
> Take path as argument, not the exit block.
> * gimple-range-path.cc (path_range_query::compute_imports):
> Likewise, and adjust, avoiding possibly stale m_path.
> (path_range_query::compute_outgoing_relations): Register
> relations for all conditionals.
> * tree-ssa-threadbackward.cc (back_threader::find_paths):
> Adjust.
>
> * gcc.dg/tree-ssa/ssa-thread-18.c: New testcase.
> * gcc.dg/tree-ssa/ssa-thread-19.c: Likewise, but XFAILed.
> ---
>  gcc/gimple-range-path.cc  | 21 +---
>  gcc/gimple-range-path.h   |  2 +-
>  gcc/testsuite/gcc.dg/tree-ssa/ssa-thread-18.c | 20 +++
>  gcc/testsuite/gcc.dg/tree-ssa/ssa-thread-19.c | 33 +++
>  gcc/tree-ssa-threadbackward.cc|  4 ++-
>  5 files changed, 65 insertions(+), 15 deletions(-)
>  create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/ssa-thread-18.c
>  create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/ssa-thread-19.c
>
> diff --git a/gcc/gimple-range-path.cc b/gcc/gimple-range-path.cc
> index 43e7526b6fc..389faec260c 100644
> --- a/gcc/gimple-range-path.cc
> +++ b/gcc/gimple-range-path.cc
> @@ -549,7 +549,7 @@ path_range_query::add_to_imports (tree name, bitmap 
> imports)
>return false;
>  }
>
> -// Compute the imports to the path ending in EXIT.  These are
> +// Compute the imports to PATH.  These are
>  // essentially the SSA names used to calculate the final conditional
>  // along the path.
>  //
> @@ -559,9 +559,10 @@ path_range_query::add_to_imports (tree name, bitmap 
> imports)
>  // we can solve.
>
>  void
> -path_range_query::compute_imports (bitmap imports, basic_block exit)
> +path_range_query::compute_imports (bitmap imports, const vec 
> )
>  {
>// Start with the imports from the exit block...
> +  basic_block exit = path[0];
>gori_compute  = m_ranger->gori ();
>bitmap r_imports = gori.imports (exit);
>bitmap_copy (imports, r_imports);
> @@ -599,7 +600,7 @@ path_range_query::compute_imports (bitmap imports, 
> basic_block exit)
>   tree arg = gimple_phi_arg (phi, i)->def;
>
>   if (TREE_CODE (arg) == SSA_NAME
> - && m_path.contains (e->src)
> + && path.contains (e->src)
>   && bitmap_set_bit (imports, SSA_NAME_VERSION (arg)))
> worklist.safe_push (arg);
> }
> @@ -607,9 +608,9 @@ path_range_query::compute_imports (bitmap imports, 
> basic_block exit)
>  }
>// Exported booleans along the path, may help conditionals.
>if (m_resolve)
> -for (i = 0; i < m_path.length (); ++i)
> +for (i = 0; i < path.length (); ++i)
>{
> -   basic_block bb = m_path[i];
> +   basic_block bb = path[i];
> tree name;
> FOR_EACH_GORI_EXPORT_NAME (gori, bb, name)
>   if (TREE_CODE (TREE_TYPE (name)) == BOOLEAN_TYPE)
> @@ -636,7 +637,7 @@ path_range_query::compute_ranges (const vec 
> ,
>if (imports)
>  bitmap_copy (m_imports, imports);
>else
> -compute_imports (m_imports, exit_bb ());
> +compute_imports (m_imports, m_path);
>
>if (m_resolve)
>  get_path_oracle ()->reset_path ();
> @@ -845,15 +846,9 @@ path_range_query::compute_phi_relations (basic_block bb, 
> basic_block prev)
>  void
>  path_range_query::compute_outgoing_relations (basic_block bb, basic_block 
> next)
>  {
> -  gimple *stmt = last_stmt (bb);
> -
> -  if (stmt
> -  && gimple_code 

Re: [PATCH] tree-optimization/106514 - revisit m_import compute in backward threading

[Aldy Hernandez via Gcc-patches]

On Wed, Aug 10, 2022 at 12:46 PM Richard Biener  wrote:
>
> On Wed, 10 Aug 2022, Richard Biener wrote:
>
> > On Tue, 9 Aug 2022, Andrew MacLeod wrote:
> >
> > >
> > > On 8/9/22 09:01, Richard Biener wrote:
> > > > This revisits how we compute imports later used for the ranger path
> > > > query during backwards threading.  The compute_imports function
> > > > of the path solver ends up pulling the SSA def chain of regular
> > > > stmts without limit and since it starts with just the gori imports
> > > > of the path exit it misses some interesting names to translate
> > > > during path discovery.  In fact with a still empty path this
> > > > compute_imports function looks like not the correct tool.
> > >
> > > I don't really know how this works in practice.  Aldys off this week, so 
> > > he
> > > can comment when he returns.
> > >
> > > The original premise was along the line of recognizing that only changes 
> > > to a
> > > GORI import name to a block can affect the branch at the end of the block.
> > > ie, if the path doesn't change any import to block A, then the branch at 
> > > the
> > > end of block A will not change either.Likewise, if it does change an
> > > import, then we look at whether the branch can be threaded.Beyond that
> > > basic premise, I dont know what all it does.
> >
> > Yep, I also think that's the idea.
>
> [...]
>
> > Anyway, the important result of the change is that the imports
> > set is vastly smaller since it is now constrained to the
> > actual path.  Plus it now contains the local defs in blocks
> > of the path that do not dominate the exit block which means
> > it might get more threading opportunities.  Which reminds me
> > to re-do the cc1files experiment for this change.
>
> Results are a bit unconclusive.  We have
> ethread 14044 -> 14058, first threadfull 36986 -> 37174,
> first thread 8060 -> 8049, dom 21723 -> 21822, second thread
> (after loop opts) 6242 -> 5582, second dom 8522 -> 8765,
> second threadfull 3072 -> 2998 which makes an overall drop
> in the number of threads from 98649 to 98448.

The threading dance between all passes is a bit fickle as you can see.
Particularly, DOM is a red herring.  If it starts firing up, as it
looks like from your numbers, it's usually because we regressed in the
backward threaders and DOM is picking up the slack.  Though a slightly
increase in DOM threading can be because we opened up more
opportunities for DOM because of better threading in the backward
threaders.  Sometimes it helps to run without DOM (or disable DOM
threading) to compare apples with apples...being careful of course,
that you're not dropping a bunch of threads in thread2 for instance,
and picking them up in threadfull2 or whatever.

Ughhh...I really hate that we have 20 million threading passes.

>
> I've isolated one testcase we threaded before but no longer after
> this change and that is
>
> void foo (int nest, int print_nest)
> {
>   _Bool t0 = nest != 0;
>   _Bool t1 = nest == print_nest;
>   _Bool t2 = t0 & t1;
>   if (t2)
> __builtin_puts ("x");
>   nest++;
>   if (nest > 2)
> __builtin_abort ();
>   if (print_nest == nest)
> __builtin_puts ("y");
> }
>
> where we are able to thread from if (t2) to if (print_nest == nest)
> resolving that to false when t2 is true using the nest == print_nest
> relation.  Now, the reason is because of the imports added by
>
>   // Exported booleans along the path, may help conditionals.
>   if (m_resolve)
> for (i = 0; i < m_path.length (); ++i)
>   {
> basic_block bb = m_path[i];
> tree name;
> FOR_EACH_GORI_EXPORT_NAME (gori, bb, name)
>   if (TREE_CODE (TREE_TYPE (name)) == BOOLEAN_TYPE)
> bitmap_set_bit (imports, SSA_NAME_VERSION (name));
>   }
>
> _BUT_ - it turns out that the m_path local to the solver is still
> the one from the last back_threader::find_taken_edge_switch
> calling m_solver->compute_ranges (path, m_imports), so for a possibly
> completely unrelated path.  Truncating the path also on the solver
> side before calling compute_imports makes the testcase fail to thread.
> I'll note the PHI handling also looks at the stale m_path.

Not good.  Thanks for noticing.

>
> I see the solver itself adds relations from edges on the path so
> the cruical item here seems to be to add imports for the path
> entry conditional, but those would likely be GORI imports for that
> block?  Unfortunately that fails to add t[012], the GORI exports
> seem to cover all that's needed but then exports might be too much
> here?  At least that's what the code in compute_imports effectively
> does (also for the entry block).  But I do wonder why compute_ranges
> does not add relations computed by the entry conditional ...
> That's probably because of
>
> void
> path_range_query::compute_outgoing_relations (basic_block bb, basic_block
> next)
> {
>   gimple *stmt = last_stmt (bb);
>
>   if (stmt
>   && gimple_code (stmt) == GIMPLE_COND
>   && 

[Bug middle-end/106578] spurious -Wuse-after-free=2 after conditional free() when not optimizing

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

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

--- Comment #3 from Gökçe Aydos  ---
> using 'tmp' instead makes it properly fire.

Dear Richard, maybe I misunderstood what you meant with *fire*. If `tmp` is
used then gcc does not *fire* any warning and works correctly, right?

Re: [09/23] Add a cut-down version of std::span (array_slice)

[Martin Jambor]

Hello,

I have one more question/comment about array_slice.  Ever since I
started to use it...

On Fri, Nov 13 2020, Richard Sandiford via Gcc-patches wrote:
> A later patch wants to be able to pass around subarray views of an
> existing array.  The standard class to do that is std::span, but it's
> a C++20 thing.  This patch just adds a cut-down version of it.
>
> The intention is just to provide what's currently needed.
>
> gcc/
>   * vec.h (array_slice): New class.
> ---
>  gcc/vec.h | 120 ++
>  1 file changed, 120 insertions(+)
>
> diff --git a/gcc/vec.h b/gcc/vec.h
> index f02beddc975..7768de9f518 100644
> --- a/gcc/vec.h
> +++ b/gcc/vec.h
> @@ -2128,6 +2128,126 @@ release_vec_vec (vec > )
>vec.release ();
>  }
>  
> +// Provide a subset of the std::span functionality.  (We can't use std::span
> +// itself because it's a C++20 feature.)
> +//
> +// In addition, provide an invalid value that is distinct from all valid
> +// sequences (including the empty sequence).  This can be used to return
> +// failure without having to use std::optional.
> +//
> +// There is no operator bool because it would be ambiguous whether it is
> +// testing for a valid value or an empty sequence.
> +template
> +class array_slice
> +{
> +  template friend class array_slice;
> +
> +public:
> +  using value_type = T;
> +  using iterator = T *;
> +  using const_iterator = const T *;
> +
> +  array_slice () : m_base (nullptr), m_size (0) {}
> +
> +  template
> +  array_slice (array_slice other)
> +: m_base (other.m_base), m_size (other.m_size) {}
> +
> +  array_slice (iterator base, unsigned int size)
> +: m_base (base), m_size (size) {}
> +
> +  template
> +  array_slice (T ()[N]) : m_base (array), m_size (N) {}
> +
> +  template
> +  array_slice (const vec )
> +: m_base (v.address ()), m_size (v.length ()) {}
> +
> +  iterator begin () { return m_base; }
> +  iterator end () { return m_base + m_size; }
> +
> +  const_iterator begin () const { return m_base; }
> +  const_iterator end () const { return m_base + m_size; }
> +
> +  value_type  ();
> +  value_type  ();
> +  value_type [] (unsigned int i);
> +
> +  const value_type  () const;
> +  const value_type  () const;
> +  const value_type [] (unsigned int i) const;
> +
> +  size_t size () const { return m_size; }

...this has been a constant source of compile errors, because vectors
have length () and this is size ().

I understand that the motivation was consistency with std::span, but do
we really want to add another inconsistency with ourselves?

Given that array_slice is not that much used yet, I believe we can still
change to be consistent with vectors.  I personally think we should but
at the very least, if we keep it as it is, I'd like us to do so
deliberately.

Thanks,

Martin

Re: [PATCH] RISC-V: Fix the sge ..., x0, ... pattern

[Kito Cheng via Gcc-patches]

LGTM, that's apparently some kind of copy & paste error (from *slt
pattern) when we add this pattern.

On Sun, Aug 7, 2022 at 3:42 AM Palmer Dabbelt  wrote:
>
> There's no operand 2 here, so referencing it doesn't make sense.  I
> couldn't find a way to trigger bad assembly output so I don't have a
> test.
>
> gcc/ChangeLog
>
> PR target/106543
> * config/riscv/riscv.md (sge_): Remove
> reference to non-existent operand.
> ---
> No new failures on the Linux multilibs on trunk.
> ---
>  gcc/config/riscv/riscv.md | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/gcc/config/riscv/riscv.md b/gcc/config/riscv/riscv.md
> index 0796f91dd30..ed1c7f241e6 100644
> --- a/gcc/config/riscv/riscv.md
> +++ b/gcc/config/riscv/riscv.md
> @@ -2386,7 +2386,7 @@
> (any_ge:GPR (match_operand:X 1 "register_operand" " r")
> (const_int 1)))]
>""
> -  "slt%i2\t%0,zero,%1"
> +  "slt\t%0,zero,%1"
>[(set_attr "type" "slt")
> (set_attr "mode" "")])
>
> --
> 2.34.1
>

Re: [PATCH] RISC-V: Use the X iterator for eh_set_lr_{si,di}

[Kito Cheng via Gcc-patches]

LGTM, thanks!

On Sun, Aug 7, 2022 at 3:42 AM Palmer Dabbelt  wrote:
>
> These two patterns were independent, but exactly match the semantics of
> X.  Replace them with a single paramaterized pattern.  Thanks to Andrew
> for pointing this one out over IRC.
>
> gcc/ChangeLog
>
> * config/riscv/riscv.md (eh_set_lr_): New pattern.
> (eh_set_lr_si): Remove.
> (eh_set_lr_di): Likewise.
> ---
> No new failures on the Linux multilibs on trunk.
> ---
>  gcc/config/riscv/riscv.md | 14 --
>  1 file changed, 4 insertions(+), 10 deletions(-)
>
> diff --git a/gcc/config/riscv/riscv.md b/gcc/config/riscv/riscv.md
> index 0796f91dd30..11a59f98a9f 100644
> --- a/gcc/config/riscv/riscv.md
> +++ b/gcc/config/riscv/riscv.md
> @@ -2562,16 +2562,10 @@
>  ;; Clobber the return address on the stack.  We can't expand this
>  ;; until we know where it will be put in the stack frame.
>
> -(define_insn "eh_set_lr_si"
> -  [(unspec [(match_operand:SI 0 "register_operand" "r")] UNSPEC_EH_RETURN)
> -   (clobber (match_scratch:SI 1 "="))]
> -  "! TARGET_64BIT"
> -  "#")
> -
> -(define_insn "eh_set_lr_di"
> -  [(unspec [(match_operand:DI 0 "register_operand" "r")] UNSPEC_EH_RETURN)
> -   (clobber (match_scratch:DI 1 "="))]
> -  "TARGET_64BIT"
> +(define_insn "eh_set_lr_"
> +  [(unspec [(match_operand:X 0 "register_operand" "r")] UNSPEC_EH_RETURN)
> +   (clobber (match_scratch:X 1 "="))]
> +  ""
>"#")
>
>  (define_split
> --
> 2.34.1
>

[PATCH v2 2/2] RISC-V: Support zfh and zfhmin extension

[Kito Cheng]

Zfh and Zfhmin are extensions for IEEE half precision, both are ratified
in Jan. 2022[1]:

- Zfh has full set of operation like F or D for single or double precision.
- Zfhmin has only provide minimal support for half precision operation,
  like conversion, load, store and move instructions.

[1] 
https://github.com/riscv/riscv-isa-manual/commit/b35a54079e0da11740ce5b1e6db999d1d5172768

gcc/ChangeLog:

* common/config/riscv/riscv-common.cc (riscv_implied_info): Add
zfh and zfhmin.
(riscv_ext_version_table): Ditto.
(riscv_ext_flag_table): Ditto.
* config/riscv/riscv-opts.h (MASK_ZFHMIN): New.
(MASK_ZFH): Ditto.
(TARGET_ZFHMIN): Ditto.
(TARGET_ZFH): Ditto.
* config/riscv/riscv.cc (riscv_output_move): Handle HFmode move
for zfh and zfhmin.
(riscv_emit_float_compare): Handle HFmode.
* config/riscv/riscv.md (ANYF): Add HF.
(SOFTF): Add HF.
(load): Ditto.
(store): Ditto.
(truncsfhf2): New.
(truncdfhf2): Ditto.
(extendhfsf2): Ditto.
(extendhfdf2): Ditto.
(*movhf_hardfloat): Ditto.
(*movhf_softfloat): Make sure not ZFHMIN.
* config/riscv/riscv.opt (riscv_zf_subext): New.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/_Float16-zfh-1.c: New.
* gcc.target/riscv/_Float16-zfh-2.c: Ditto.
* gcc.target/riscv/_Float16-zfh-3.c: Ditto.
* gcc.target/riscv/_Float16-zfhmin-1.c: Ditto.
* gcc.target/riscv/_Float16-zfhmin-2.c: Ditto.
* gcc.target/riscv/_Float16-zfhmin-3.c: Ditto.
* gcc.target/riscv/arch-16.c: Ditto.
* gcc.target/riscv/arch-17.c: Ditto.
* gcc.target/riscv/predef-21.c: Ditto.
* gcc.target/riscv/predef-22.c: Ditto.
---
 gcc/common/config/riscv/riscv-common.cc   |  8 +++
 gcc/config/riscv/riscv-opts.h |  6 ++
 gcc/config/riscv/riscv.cc | 33 ++-
 gcc/config/riscv/riscv.md | 59 +--
 gcc/config/riscv/riscv.opt|  3 +
 .../gcc.target/riscv/_Float16-zfh-1.c |  8 +++
 .../gcc.target/riscv/_Float16-zfh-2.c |  8 +++
 .../gcc.target/riscv/_Float16-zfh-3.c |  8 +++
 .../gcc.target/riscv/_Float16-zfhmin-1.c  |  9 +++
 .../gcc.target/riscv/_Float16-zfhmin-2.c  |  9 +++
 .../gcc.target/riscv/_Float16-zfhmin-3.c  |  9 +++
 gcc/testsuite/gcc.target/riscv/arch-16.c  |  5 ++
 gcc/testsuite/gcc.target/riscv/arch-17.c  |  5 ++
 gcc/testsuite/gcc.target/riscv/predef-21.c| 59 +++
 gcc/testsuite/gcc.target/riscv/predef-22.c| 59 +++
 15 files changed, 279 insertions(+), 9 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/riscv/_Float16-zfh-1.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/_Float16-zfh-2.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/_Float16-zfh-3.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/_Float16-zfhmin-1.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/_Float16-zfhmin-2.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/_Float16-zfhmin-3.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/arch-16.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/arch-17.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/predef-21.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/predef-22.c

diff --git a/gcc/common/config/riscv/riscv-common.cc 
b/gcc/common/config/riscv/riscv-common.cc
index 0e5be2ce105..4ee1b3198c5 100644
--- a/gcc/common/config/riscv/riscv-common.cc
+++ b/gcc/common/config/riscv/riscv-common.cc
@@ -96,6 +96,9 @@ static const riscv_implied_info_t riscv_implied_info[] =
   {"zvl32768b", "zvl16384b"},
   {"zvl65536b", "zvl32768b"},
 
+  {"zfh", "zfhmin"},
+  {"zfhmin", "f"},
+
   {NULL, NULL}
 };
 
@@ -193,6 +196,9 @@ static const struct riscv_ext_version 
riscv_ext_version_table[] =
   {"zvl32768b", ISA_SPEC_CLASS_NONE, 1, 0},
   {"zvl65536b", ISA_SPEC_CLASS_NONE, 1, 0},
 
+  {"zfh",   ISA_SPEC_CLASS_NONE, 1, 0},
+  {"zfhmin",ISA_SPEC_CLASS_NONE, 1, 0},
+
   /* Terminate the list.  */
   {NULL, ISA_SPEC_CLASS_NONE, 0, 0}
 };
@@ -1148,6 +1154,8 @@ static const riscv_ext_flag_table_t 
riscv_ext_flag_table[] =
   {"zvl32768b", _options::x_riscv_zvl_flags, MASK_ZVL32768B},
   {"zvl65536b", _options::x_riscv_zvl_flags, MASK_ZVL65536B},
 
+  {"zfhmin",_options::x_riscv_zf_subext, MASK_ZFHMIN},
+  {"zfh",   _options::x_riscv_zf_subext, MASK_ZFH},
 
   {NULL, NULL, 0}
 };
diff --git a/gcc/config/riscv/riscv-opts.h b/gcc/config/riscv/riscv-opts.h
index 1e153b3a6e7..85e869e62e3 100644
--- a/gcc/config/riscv/riscv-opts.h
+++ b/gcc/config/riscv/riscv-opts.h
@@ -153,6 +153,12 @@ enum stack_protector_guard {
 #define TARGET_ZICBOM ((riscv_zicmo_subext & MASK_ZICBOM) != 0)
 #define TARGET_ZICBOP ((riscv_zicmo_subext & MASK_ZICBOP) != 0)
 
+#define MASK_ZFHMIN   (1 << 0)
+#define MASK_ZFH  (1 << 1)
+
+#define TARGET_ZFHMIN 

[PATCH v2 1/2] RISC-V: Support _Float16 type.

[Kito Cheng]

RISC-V decide use _Float16 as primary IEEE half precision type, and this
already become part of psABI, this patch has added folloing support for
_Float16:

- Soft-float support for _Float16.
- Make sure _Float16 available on C++ mode.
- Name mangling for _Float16 on C++ mode.

gcc/ChangeLog

* config/riscv/riscv-builtins.cc: include stringpool.h
(riscv_float16_type_node): New.
(riscv_init_builtin_types): Ditto.
(riscv_init_builtins): Call riscv_init_builtin_types.
* config/riscv/riscv-modes.def (HF): New.
* gcc/config/riscv/riscv.cc (riscv_output_move): Handle HFmode.
(riscv_mangle_type): New.
(riscv_scalar_mode_supported_p): Ditto.
(riscv_libgcc_floating_mode_supported_p): Ditto.
(riscv_excess_precision): Ditto.
(riscv_floatn_mode): Ditto.
(riscv_init_libfuncs): Ditto.
(TARGET_MANGLE_TYPE): Ditto.
(TARGET_SCALAR_MODE_SUPPORTED_P): Ditto.
(TARGET_LIBGCC_FLOATING_MODE_SUPPORTED_P): Ditto.
(TARGET_INIT_LIBFUNCS): Ditto.
(TARGET_C_EXCESS_PRECISION): Ditto.
(TARGET_FLOATN_MODE): Ditto.
* gcc/config/riscv/riscv.md (mode): Add HF.
(softload): Add HF.
(softstore): Ditto.
(fmt): Ditto.
(UNITMODE): Ditto.
(movhf): New.
(*movhf_softfloat): New.

libgcc/ChangeLog:

* config/riscv/sfp-machine.h (_FP_NANFRAC_H): New.
(_FP_NANFRAC_H): Ditto.
(_FP_NANSIGN_H): Ditto.
* config/riscv/t-softfp32 (softfp_extensions): Add HF related
routines.
(softfp_truncations): Ditto.
(softfp_extras): Ditto.
* config/riscv/t-softfp64 (softfp_extras): Add HF related routines.

gcc/testsuite/ChangeLog:

* gcc/testsuite/g++.target/riscv/_Float16.C: New.
* gcc/testsuite/gcc.target/riscv/_Float16-soft-1.c: Ditto.
* gcc/testsuite/gcc.target/riscv/_Float16-soft-2.c: Ditto.
* gcc/testsuite/gcc.target/riscv/_Float16-soft-3.c: Ditto.
* gcc/testsuite/gcc.target/riscv/_Float16-soft-4.c: Ditto.
* gcc/testsuite/gcc.target/riscv/_Float16.c: Ditto.
---
 gcc/config/riscv/riscv-builtins.cc|  24 +++
 gcc/config/riscv/riscv-modes.def  |   1 +
 gcc/config/riscv/riscv.cc | 171 --
 gcc/config/riscv/riscv.md |  30 ++-
 gcc/testsuite/g++.target/riscv/_Float16.C |  18 ++
 .../gcc.target/riscv/_Float16-soft-1.c|   9 +
 .../gcc.target/riscv/_Float16-soft-2.c|  13 ++
 .../gcc.target/riscv/_Float16-soft-3.c|  12 ++
 .../gcc.target/riscv/_Float16-soft-4.c|  12 ++
 gcc/testsuite/gcc.target/riscv/_Float16.c |  19 ++
 libgcc/config/riscv/sfp-machine.h |   3 +
 libgcc/config/riscv/t-softfp32|   5 +
 libgcc/config/riscv/t-softfp64|   1 +
 13 files changed, 300 insertions(+), 18 deletions(-)
 create mode 100644 gcc/testsuite/g++.target/riscv/_Float16.C
 create mode 100644 gcc/testsuite/gcc.target/riscv/_Float16-soft-1.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/_Float16-soft-2.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/_Float16-soft-3.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/_Float16-soft-4.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/_Float16.c

diff --git a/gcc/config/riscv/riscv-builtins.cc 
b/gcc/config/riscv/riscv-builtins.cc
index 1218fdfc67d..3009311604d 100644
--- a/gcc/config/riscv/riscv-builtins.cc
+++ b/gcc/config/riscv/riscv-builtins.cc
@@ -34,6 +34,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "recog.h"
 #include "diagnostic-core.h"
 #include "stor-layout.h"
+#include "stringpool.h"
 #include "expr.h"
 #include "langhooks.h"
 
@@ -160,6 +161,8 @@ static GTY(()) int riscv_builtin_decl_index[NUM_INSN_CODES];
 #define GET_BUILTIN_DECL(CODE) \
   riscv_builtin_decls[riscv_builtin_decl_index[(CODE)]]
 
+tree riscv_float16_type_node = NULL_TREE;
+
 /* Return the function type associated with function prototype TYPE.  */
 
 static tree
@@ -185,11 +188,32 @@ riscv_build_function_type (enum riscv_function_type type)
   return types[(int) type];
 }
 
+static void
+riscv_init_builtin_types (void)
+{
+  /* Provide the _Float16 type and float16_type_node if needed.  */
+  if (!float16_type_node)
+{
+  riscv_float16_type_node = make_node (REAL_TYPE);
+  TYPE_PRECISION (riscv_float16_type_node) = 16;
+  SET_TYPE_MODE (riscv_float16_type_node, HFmode);
+  layout_type (riscv_float16_type_node);
+}
+  else
+riscv_float16_type_node = float16_type_node;
+
+  if (!maybe_get_identifier ("_Float16"))
+lang_hooks.types.register_builtin_type (riscv_float16_type_node,
+   "_Float16");
+}
+
 /* Implement TARGET_INIT_BUILTINS.  */
 
 void
 riscv_init_builtins (void)
 {
+  riscv_init_builtin_types ();
+
   for (size_t i = 0; i < ARRAY_SIZE (riscv_builtins); i++)
 {
   const struct 

[PATCH 0/2] RISC-V: Support _Float16 type and implement zfh and zfhmin extension

[Kito Cheng]

This patch set implements Zfh and Zfhmin, adds soft-float for _Float16, and 
enables _Float16 type in C++ mode.

Zfh and Zfhmin are extensions for IEEE half precision, both are ratified in 
Jan. 2022[1]

v2 Changes:
Fix mangling for C++ mode to fit the RISC-V psABI spec.


[1] 
https://github.com/riscv/riscv-isa-manual/commit/b35a54079e0da11740ce5b1e6db999d1d5172768

Re: [PATCH] tree-optimization/106514 - revisit m_import compute in backward threading

[Aldy Hernandez via Gcc-patches]

I'm still on vacation, but I figured I'd mention a few things to
either unblock you, or move the conversation along.

On Wed, Aug 10, 2022 at 8:45 AM Richard Biener  wrote:
>
> On Tue, 9 Aug 2022, Andrew MacLeod wrote:
>
> >
> > On 8/9/22 09:01, Richard Biener wrote:
> > > This revisits how we compute imports later used for the ranger path
> > > query during backwards threading.  The compute_imports function
> > > of the path solver ends up pulling the SSA def chain of regular
> > > stmts without limit and since it starts with just the gori imports
> > > of the path exit it misses some interesting names to translate
> > > during path discovery.  In fact with a still empty path this
> > > compute_imports function looks like not the correct tool.
> >
> > I don't really know how this works in practice.  Aldys off this week, so he
> > can comment when he returns.
> >
> > The original premise was along the line of recognizing that only changes to 
> > a
> > GORI import name to a block can affect the branch at the end of the block.
> > ie, if the path doesn't change any import to block A, then the branch at the
> > end of block A will not change either.Likewise, if it does change an
> > import, then we look at whether the branch can be threaded.Beyond that
> > basic premise, I dont know what all it does.
>
> Yep, I also think that's the idea.

Yes.

>
> > I presume the unbounded def chain is for local defs within a block that in
> > turn feeds the import to another block.   Im not sure why we need to do much
> > with those..  again, its only the import to the defchain that can affect the
> > outcome t the end of the chain.. and if it changes, then you need to
> > recalculate the entire chain.. but that would be part of the normal path
> > walk.  I suspect ther eis also some pruning that can be done there, as GORi
> > reflects "can affect the range" not "will affect the range".
> >
> > Perhaps whats going on is that all those local elements are being added up
> > front to the list of interesting names?  That would certainly blow up the
> > bitmaps and loops and such.
>
> What it does is, if we have
>
> bb:
>   _3 = _5 + 1;
>   _1 = _3 + _4;
>   if (_1 > _2)
>
> it puts _3 and _4 and _5 into the set of interesting names.  That's
> OK and desired I think?  The actual problem is that compute_imports
> will follow the def of _5 and _4 into dominating blocks recursively,
> adding things to the imports even if the definition blocks are not
> on the path (the path is empty at the point we call compute_imports).

That sounds like a bug.  We shouldn't recurse unbounded outside of the
path.  For that matter, for anything outside the path, we should be
querying the ranger, which can cache things appropriately.  The intent
was that for anything queried outside of the path, we should be using
the ranger through range_on_path_entry.

> For the testcase at hand this pulls in some 1000s of names into the
> initial set of imports.  Now, the current path discovery code
> only adds to imports by means of PHI translating from a PHI
> def to a PHI use on the path edge - it doesn't add any further
> local names used to define such PHI edge use from blocks not
> dominating the path exit (but on the about to be threaded path).
>
> I'll also note that compute_imports does
>
>   // Exported booleans along the path, may help conditionals.
>   if (m_resolve)
> for (i = 0; i < m_path.length (); ++i)
>   {
> basic_block bb = m_path[i];
> tree name;
> FOR_EACH_GORI_EXPORT_NAME (gori, bb, name)
>   if (TREE_CODE (TREE_TYPE (name)) == BOOLEAN_TYPE)
> bitmap_set_bit (imports, SSA_NAME_VERSION (name));
>   }
>
> but at least for the backwards threader this isn't effective
> since the path is empty at the point we call this.  And no
> other code in the backwards threader does sth like this.

IIRC, this came about to help with statements leading up to the
condition.  See fur_source::register_outgoing_edges:

  // Now look for other relations in the exports.  This will find stmts
  // leading to the condition such as:
  // c_2 = a_4 < b_7
  // if (c_2)
  FOR_EACH_GORI_EXPORT_NAME (*(gori ()), bb, name)
{
  if (TREE_CODE (TREE_TYPE (name)) != BOOLEAN_TYPE)
continue;

At least back when I wrote it, it made a difference in the number of
threads we got.

> I would also say for the exit block it doesn't make
> much sense to look at gori exports.  Plus I don't understand
> what this tries to capture - it presumably catches stmts
> like _1 = _2 == _3 that have uses in downstream blocks but
> might be not directly part of the conditional op def chain.
>
> In the end all the threader does is, once the path is complete,
> compute ranges for the path and the imports and then fold the
> path exit stmt.
>
> I'm not sure which names we need in the import set for this
> but as I guess the set of imports constrain the names we
> compute ranges for so for the BB above, if we want to have
> a 

Re: [RISC-V] [tech-toolchain] Fw: [RISCV] RISC-V GNU Toolchain Biweekly Sync-up call (Aug 11, 2022)

[jiawei]

BEGIN:VCALENDAR
PRODID:-//zoom.us//iCalendar Event//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:PUBLISH
CLASS:PUBLIC
BEGIN:VTIMEZONE
TZID:Asia/Singapore
LAST-MODIFIED:20220317T223602Z
TZURL:http://tzurl.org/zoneinfo-outlook/Asia/Singapore
X-LIC-LOCATION:Asia/Singapore
BEGIN:STANDARD
TZNAME:+08
TZOFFSETFROM:+0800
TZOFFSETTO:+0800
DTSTART:19700101T00
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
DTSTAMP:20220713T134316Z
DTSTART;TZID=Asia/Singapore:20220714T23
DTEND;TZID=Asia/Singapore:20220715T00
SUMMARY:RISC-V GNU Toolchain Biweekly Sync-up
RRULE:FREQ=WEEKLY;WKST=SU;UNTIL=20230323T16;INTERVAL=2;BYDAY=TH
UID:ZOOM89393600951
TZID:Asia/Singapore
DESCRIPTION:Wei Wu - PLCT Lab is inviting you to a scheduled Zoom meeting
 .\n\nJoin Zoom Meeting\nhttps://us02web.zoom.us/j/89393600951?pwd=ZFpWMk
 Z6Tm1TbUFXT1hZZjZZMHhRQT09\n\nMeeting ID: 893 9360 0951\nPasscode: 89966
 2\nOne tap mobile\n+6531651065\,\,89393600951#\,\,\,\,*899662# Singapore
 \n+6531587288\,\,89393600951#\,\,\,\,*899662# Singapore\n\nDial by your 
 location\n+65 3165 1065 Singapore\n+65 3158 7288 Singapo
 re\n+1 669 900 9128 US (San Jose)\n+1 669 444 9171 US\n 
+1 346 248 7799 US (Houston)\n+1 253 215 8782 US (Tacoma)
 \n+1 312 626 6799 US (Chicago)\n+1 646 558 8656 US (New 
 York)\n+1 646 931 3860 US\n+1 301 715 8592 US (Washingto
 n DC)\nMeeting ID: 893 9360 0951\nPasscode: 899662\nFind your local numb
 er: https://us02web.zoom.us/u/kk9cyIPNJ\n\n
LOCATION:https://us02web.zoom.us/j/89393600951?pwd=ZFpWMkZ6Tm1TbUFXT1hZZj
 ZZMHhRQT09
BEGIN:VALARM
TRIGGER:-PT10M
ACTION:DISPLAY
DESCRIPTION:Reminder
END:VALARM
END:VEVENT
END:VCALENDAR

[Bug fortran/106579] New: ieee_signaling_nan problem in fortran on powerpc64

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

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

Bug ID: 106579
   Summary: ieee_signaling_nan problem in fortran on powerpc64
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

There is an issue with ieee_signaling_nan as used in fortran on powerpc64 when
--with-long-double-format=ieee is used.

Extracted from gfortran.dg/ieee/signaling_3.f90:

program test
  use, intrinsic :: iso_c_binding
  use, intrinsic :: ieee_arithmetic
  implicit none

  real(kind=c_long_double) :: z

  if (ieee_support_nan(z)) then
z = ieee_value(z, ieee_signaling_nan)
if (ieee_class(z) /= ieee_signaling_nan) stop 100
  end if

end program test

seurer@fowler:~/gcc/git/build/gcc-12-test$
/home/seurer/gcc/git/build/gcc-12-test/gcc/testsuite/gfortran/../../gfortran
-B/home/seurer/gcc/git/build/gcc-12-test/gcc/testsuite/gfortran/../../
-B/home/seurer/gcc/git/build/gcc-12-test/powerpc64le-unknown-linux-gnu/./libgfortran/
signaling_3a.f90 -fdiagnostics-plain-output -fdiagnostics-plain-output -O0
-pedantic-errors -fintrinsic-modules-path
/home/seurer/gcc/git/build/gcc-12-test/powerpc64le-unknown-linux-gnu/./libgfortran/
-fno-unsafe-math-optimizations -frounding-math -fsignaling-nans
-B/home/seurer/gcc/git/build/gcc-12-test/powerpc64le-unknown-linux-gnu/./libgfortran/.libs
-L/home/seurer/gcc/git/build/gcc-12-test/powerpc64le-unknown-linux-gnu/./libgfortran/.libs
-L/home/seurer/gcc/git/build/gcc-12-test/powerpc64le-unknown-linux-gnu/./libgfortran/.libs
-L/home/seurer/gcc/git/build/gcc-12-test/powerpc64le-unknown-linux-gnu/./libatomic/.libs
-B/home/seurer/gcc/git/build/gcc-12-test/powerpc64le-unknown-linux-gnu/./libquadmath/.libs
-L/home/seurer/gcc/git/build/gcc-12-test/powerpc64le-unknown-linux-gnu/./libquadmath/.libs
-L/home/seurer/gcc/git/build/gcc-12-test/powerpc64le-unknown-linux-gnu/./libquadmath/.libs
-lm -o ./signaling_3a.exe

seurer@fowler:~/gcc/git/build/gcc-12-test$ ./signaling_3a.exe 
STOP 100


This happens for both gcc 12 and 13 (trunk).

It occurs on powerpc64 LE with the compiler being tested configured with
--with-long-double-format=ieee on Fedora 36 which is the first powerpc64 distro
built with --with-long-double-format=ieee.  The distro compiler is gcc version
12.1.1 20220507 (Red Hat 12.1.1-1) (GCC).


Note the specific test case, signaling_3.f90, was added here but another test
case signaling_2.f90 fails the same way.

commit e89d0befe3ec3238fca6de2cb078eb403b8c7e99 (HEAD)
Author: Francois-Xavier Coudert 
Date:   Mon Jan 17 12:46:48 2022 +0100

Fortran: provide a fallback implementation of issignaling

[Bug c/106571] Implement -Wsection diag

[bp at alien8 dot de via Gcc-bugs]

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

--- Comment #5 from Boris  ---
(In reply to Michael Matz from comment #4)
> Boris: what does DECLARE_PER_CPU() expand into?  Are there other attributes
> that could be usefully checked for mismatch between decl and def?

Unfortunately,

DECLARE_PER_CPU(u64, x86_spec_ctrl_current);

expands only to:

extern __attribute__((section(".data..percpu" ""))) __typeof__(u64)
x86_spec_ctrl_current;

[PATCH] analyzer: fix ICE casued by dup2 in sm-fd.cc[PR106551]

[Immad Mir via Gcc-patches]

This patch fixes the ICE caused by valid_to_unchecked_state,
at analyzer/sm-fd.cc by handling the m_start state in
check_for_dup.

Tested lightly on x86_64.

gcc/analyzer/ChangeLog:
PR analyzer/106551
* sm-fd.cc (check_for_dup): handle the m_start
state when transitioning the state of LHS
of dup, dup2 and dup3 call.

gcc/testsuite/ChangeLog:
* gcc.dg/analyzer/fd-dup-1.c: New testcases.

Signed-off-by: Immad Mir 
---
 gcc/analyzer/sm-fd.cc|  4 ++--
 gcc/testsuite/gcc.dg/analyzer/fd-dup-1.c | 27 +++-
 2 files changed, 28 insertions(+), 3 deletions(-)

diff --git a/gcc/analyzer/sm-fd.cc b/gcc/analyzer/sm-fd.cc
index 8bb76d72b05..c8b9930a7b6 100644
--- a/gcc/analyzer/sm-fd.cc
+++ b/gcc/analyzer/sm-fd.cc
@@ -983,7 +983,7 @@ fd_state_machine::check_for_dup (sm_context *sm_ctxt, const 
supernode *node,
 case DUP_1:
   if (lhs)
{
- if (is_constant_fd_p (state_arg_1))
+ if (is_constant_fd_p (state_arg_1) || state_arg_1 == m_start)
sm_ctxt->set_next_state (stmt, lhs, m_unchecked_read_write);
  else
sm_ctxt->set_next_state (stmt, lhs,
@@ -1011,7 +1011,7 @@ fd_state_machine::check_for_dup (sm_context *sm_ctxt, 
const supernode *node,
   file descriptor i.e the first argument.  */
   if (lhs)
{
- if (is_constant_fd_p (state_arg_1))
+ if (is_constant_fd_p (state_arg_1) || state_arg_1 == m_start)
sm_ctxt->set_next_state (stmt, lhs, m_unchecked_read_write);
  else
sm_ctxt->set_next_state (stmt, lhs,
diff --git a/gcc/testsuite/gcc.dg/analyzer/fd-dup-1.c 
b/gcc/testsuite/gcc.dg/analyzer/fd-dup-1.c
index eba2570568f..bc823d1ce4e 100644
--- a/gcc/testsuite/gcc.dg/analyzer/fd-dup-1.c
+++ b/gcc/testsuite/gcc.dg/analyzer/fd-dup-1.c
@@ -220,4 +220,29 @@ test_19 (const char *path, void *buf)
 close (fd);
 }
 
-}
\ No newline at end of file
+}
+
+extern int m;
+
+void
+test_20 ()
+{
+int fd = dup (m); /* { dg-warning "'dup' on possibly invalid file 
descriptor 'm'" } */
+close (fd);
+}
+
+void
+test_21 ()
+{
+int fd = dup2 (m, 1); /* { dg-warning "'dup2' on possibly invalid file 
descriptor 'm'" } */
+close (fd);
+}
+
+void
+test_22 (int flags)
+{
+int fd = dup3 (m, 1, flags); /* { dg-warning "'dup3' on possibly invalid 
file descriptor 'm'" } */
+close (fd);
+}
+
+
-- 
2.25.1

Re: [PATCH] analyzer: fix ICE casued by dup2 in sm-fd.cc[PR106551]

[Mir Immad via Gcc-patches]

 > if you convert the "int m;" locals into an extern global, like in
> comment #0 of bug 106551, does that still trigger the crash on the
> unpatched sm-fd.cc?

Yes, it does, since m would be in "m_start" state. I'm sending an updated
patch.

Thanks
Immad.

On Wed, Aug 10, 2022 at 1:32 AM David Malcolm  wrote:

> On Tue, 2022-08-09 at 21:42 +0530, Immad Mir wrote:
> > This patch fixes the ICE caused by valid_to_unchecked_state,
> > at analyzer/sm-fd.cc by handling the m_start state in
> > check_for_dup.
> >
> > Tested lightly on x86_64.
> >
> > gcc/analyzer/ChangeLog:
> > PR analyzer/106551
> > * sm-fd.cc (check_for_dup): handle the m_start
> > state when transitioning the state of LHS
> > of dup, dup2 and dup3 call.
> >
> > gcc/testsuite/ChangeLog:
> > * gcc.dg/analyzer/fd-dup-1.c: New testcases.
> >
> > Signed-off-by: Immad Mir 
> > ---
> >  gcc/analyzer/sm-fd.cc|  4 ++--
> >  gcc/testsuite/gcc.dg/analyzer/fd-dup-1.c | 28
> > +++-
> >  2 files changed, 29 insertions(+), 3 deletions(-)
> >
> > diff --git a/gcc/analyzer/sm-fd.cc b/gcc/analyzer/sm-fd.cc
> > index 8bb76d72b05..c8b9930a7b6 100644
> > --- a/gcc/analyzer/sm-fd.cc
> > +++ b/gcc/analyzer/sm-fd.cc
> > @@ -983,7 +983,7 @@ fd_state_machine::check_for_dup (sm_context
> > *sm_ctxt, const supernode *node,
> >  case DUP_1:
> >if (lhs)
> > {
> > - if (is_constant_fd_p (state_arg_1))
> > + if (is_constant_fd_p (state_arg_1) || state_arg_1 ==
> > m_start)
> > sm_ctxt->set_next_state (stmt, lhs,
> > m_unchecked_read_write);
> >   else
> > sm_ctxt->set_next_state (stmt, lhs,
> > @@ -1011,7 +1011,7 @@ fd_state_machine::check_for_dup (sm_context
> > *sm_ctxt, const supernode *node,
> >file descriptor i.e the first argument.  */
> >if (lhs)
> > {
> > - if (is_constant_fd_p (state_arg_1))
> > + if (is_constant_fd_p (state_arg_1) || state_arg_1 ==
> > m_start)
> > sm_ctxt->set_next_state (stmt, lhs,
> > m_unchecked_read_write);
> >   else
> > sm_ctxt->set_next_state (stmt, lhs,
> > diff --git a/gcc/testsuite/gcc.dg/analyzer/fd-dup-1.c
> > b/gcc/testsuite/gcc.dg/analyzer/fd-dup-1.c
> > index eba2570568f..ed4d6de57db 100644
> > --- a/gcc/testsuite/gcc.dg/analyzer/fd-dup-1.c
> > +++ b/gcc/testsuite/gcc.dg/analyzer/fd-dup-1.c
> > @@ -220,4 +220,30 @@ test_19 (const char *path, void *buf)
> >  close (fd);
> >  }
> >
> > -}
> > \ No newline at end of file
> > +}
> > +
> > +void
> > +test_20 ()
> > +{
> > +int m;
> > +int fd = dup (m); /* { dg-warning "'dup' on possibly invalid
> > file descriptor 'm'" } */
> > +close (fd);
> > +}
> > +
> > +void
> > +test_21 ()
> > +{
> > +int m;
> > +int fd = dup2 (m, 1); /* { dg-warning "'dup2' on possibly
> > invalid file descriptor 'm'" } */
> > +close (fd);
> > +}
> > +
> > +void
> > +test_22 (int flags)
> > +{
> > +int m;
> > +int fd = dup3 (m, 1, flags); /* { dg-warning "'dup3' on possibly
> > invalid file descriptor 'm'" } */
> > +close (fd);
> > +}
>
> Thanks for the updated patch.
>
> The test cases looked suspicious to me - I was wondering why the
> analyzer doesn't complain about the uninitialized values being passed
> to the various dup functions as parameters.  So your test cases seem to
> have uncovered a hidden pre-existing bug in the analyzer's
> uninitialized value detection, which I've filed for myself to deal with
> as PR analyzer/106573.
>
> If you convert the "int m;" locals into an extern global, like in
> comment #0 of bug 106551, does that still trigger the crash on the
> unpatched sm-fd.cc?  If so, then that's greatly preferable as a
> regression test, since otherwise I'll have to modify that test case
> when I fix bug 106573.
>
> Dave
>
>
>
>

[Bug target/106574] gcc 12 with O3 leads to failures in glibc's y1f128 tests

[joseph at codesourcery dot com via Gcc-bugs]

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

--- Comment #5 from joseph at codesourcery dot com  ---
It's possible code is being moved across SET_RESTORE_ROUNDL, in which case 
maybe math_opt_barrier needs to be used in glibc code to prevent that 
movement.

[Bug tree-optimization/106506] [13 Regression] g++.dg/opt/pr94589-2.C FAILS after enabling floats in VRP

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Last reconfirmed||2022-08-10
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Created attachment 53431
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53431=edit
gcc13-pr106506.patch

Those 2 checks were just trying to be careful, the (phires & 1) == phires and
variants it is folded to of course make only sense for the -1/0/1/2 result
spaceship, for -1/0/1 one can just use comparisons of phires.  We only floating
point spaceship if nans aren't honored, so the 2 case is ignored, and if it is,
with Aldy's changes we can simplify the 2 case away from the phi but the
(phires & 1) == phires stayed.  It is safe to treat the phires comparison as
phires >= 0 even then.

[Bug tree-optimization/106458] [12/13 Regression] glibc's malloc/tst-scratch_buffer.c test is miscompiled with gcc-12

[dave.anglin at bell dot net via Gcc-bugs]

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

--- Comment #12 from dave.anglin at bell dot net ---
On 2022-08-10 9:30 a.m., rguenth at gcc dot gnu.org wrote:
> When I try with a cc1 cross I see
>
>> ./cc1 -quiet t.i -fpreprocessed -O2 -g -std=gnu11 -fgnu89-inline 
>> -fmerge-all-constants -frounding-math -fno-stack-protector -fno-common 
>> -fmath-errno-fno-pie -fopt-info-vec
> and nothing actually vectorized.  Besides the PRE there seems to be a missed
> DSE at the end (when vectorization is enabled as after the change):
>
> # DEBUG BEGIN_STMT
> memset (__space.__c, 64, 1024);
> # DEBUG BEGIN_STMT
> +  sizes[0] = 16;
> sizes[1] = 1024;
> sizes[2] = 1040;
>
> otherwise I see nothing suspicious in differences in .optimized when
> comparing -fdump-tree-optimized with/without -fno-tree-vectorize.
I had tried -fno-tree-vectorize and it made no difference to the test.  So, it
seems GCC is miscompiled
with the -ftree-vectorize change.  I thought of building GCC with
-fno-tree-vectorize as a test.

>
> You could try if -fno-tree-pre reproduces it also before the change.
>
Will try.

[Bug middle-end/106578] spurious -Wuse-after-free=2 after conditional free()

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

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2022-08-10
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
The pattern matching of the if (result == NULL) doesn't work reliably without
optimization because it goes through memory:

   :
  tmp_5 = buf;
  _1 = realloc (tmp_5, 10);
  buf = _1;
  buf.0_2 = buf;
  if (buf.0_2 == 0B)
goto ; [INV]
  else
goto ; [INV]

   :
  free (tmp_5);

   :
  _9 = 0;

   :
:
  return _9;

using 'tmp' instead makes it properly fire.  Could be fixed with extra
compile-time cycles doing virtual VN like we do for early uninit
analysis (note this is the late waccess pass).

[Bug tree-optimization/106513] [10/11/12/13 Regression] bswap pass misses that >>56 for signed types can be replicate the sign bit

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

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Richard Biener
:

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

commit r12-8677-gab2ca2dbd528f0564b80fa0e6eda96e0237742bc
Author: Richard Biener 
Date:   Wed Aug 10 15:45:22 2022 +0200

tree-optimization/106513 - fix mistake in bswap symbolic number shifts

This fixes a mistake in typing a local variable in the symbolic
shift routine.

PR tree-optimization/106513
* gimple-ssa-store-merging.cc (do_shift_rotate): Use uint64_t
for head_marker.

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

(cherry picked from commit f675afa4eeac9910a2c085a95aa04d6d9f2fd8d6)

[Bug tree-optimization/106513] [10/11/12/13 Regression] bswap pass misses that >>56 for signed types can be replicate the sign bit

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

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Richard Biener :

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

commit r13-2013-gf675afa4eeac9910a2c085a95aa04d6d9f2fd8d6
Author: Richard Biener 
Date:   Wed Aug 10 15:45:22 2022 +0200

tree-optimization/106513 - fix mistake in bswap symbolic number shifts

This fixes a mistake in typing a local variable in the symbolic
shift routine.

PR tree-optimization/106513
* gimple-ssa-store-merging.cc (do_shift_rotate): Use uint64_t
for head_marker.

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

[Bug lto/106334] [13 Regression] lto -g ICE in dwarf2out_register_external_die at dwarf2out.cc:6072

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

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

--- Comment #10 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Richard Biener
:

https://gcc.gnu.org/g:4769ac6c5dfde2810a0266fe388211edc644e623

commit r12-8676-g4769ac6c5dfde2810a0266fe388211edc644e623
Author: Richard Biener 
Date:   Mon Aug 8 09:07:23 2022 +0200

lto/106540 - fix LTO tree input wrt dwarf2out_register_external_die

I've revisited the earlier two workarounds for
dwarf2out_register_external_die
getting duplicate entries.  It turns out that r11-525-g03d90a20a1afcb
added dref_queue pruning to lto_input_tree but decl reading uses that
to stream in DECL_INITIAL even when in the middle of SCC streaming.
When that SCC then gets thrown away we can end up with debug nodes
registered which isn't supposed to happen.  The following adjusts
the DECL_INITIAL streaming to go the in-SCC way, using lto_input_tree_1,
since no SCCs are expected at this point, just refs.

PR lto/106540
PR lto/106334
* lto-streamer-in.cc (lto_read_tree_1): Use lto_input_tree_1
to input DECL_INITIAL, avoiding to commit drefs.

(cherry picked from commit 2a1448f2763a72c83e2ec496f78243a975b0d44e)

[Bug lto/106540] [10/11/12 Regression] lto -g ICE in dwarf2out_register_external_die at dwarf2out.cc:6076

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

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Richard Biener
:

https://gcc.gnu.org/g:4769ac6c5dfde2810a0266fe388211edc644e623

commit r12-8676-g4769ac6c5dfde2810a0266fe388211edc644e623
Author: Richard Biener 
Date:   Mon Aug 8 09:07:23 2022 +0200

lto/106540 - fix LTO tree input wrt dwarf2out_register_external_die

I've revisited the earlier two workarounds for
dwarf2out_register_external_die
getting duplicate entries.  It turns out that r11-525-g03d90a20a1afcb
added dref_queue pruning to lto_input_tree but decl reading uses that
to stream in DECL_INITIAL even when in the middle of SCC streaming.
When that SCC then gets thrown away we can end up with debug nodes
registered which isn't supposed to happen.  The following adjusts
the DECL_INITIAL streaming to go the in-SCC way, using lto_input_tree_1,
since no SCCs are expected at this point, just refs.

PR lto/106540
PR lto/106334
* lto-streamer-in.cc (lto_read_tree_1): Use lto_input_tree_1
to input DECL_INITIAL, avoiding to commit drefs.

(cherry picked from commit 2a1448f2763a72c83e2ec496f78243a975b0d44e)

[PATCH] soft-fp: Update soft-fp from glibc

[Kito Cheng]

This patch is updating all soft-fp from glibc, most changes are
copyright years update, removing "Contributed by" lines and update URL for
license, and changes other than those update are adding conversion
function between IEEE half and 32-bit/64-bit integer, those functions are
required by RISC-V _Float16 support.

libgcc/ChangeLog:

* soft-fp/fixhfdi.c: New.
* soft-fp/fixhfsi.c: Likewise.
* soft-fp/fixunshfdi.c: Likewise.
* soft-fp/fixunshfsi.c: Likewise.
* soft-fp/floatdihf.c: Likewise.
* soft-fp/floatsihf.c: Likewise.
* soft-fp/floatundihf.c: Likewise.
* soft-fp/floatunsihf.c: Likewise.
* soft-fp/adddf3.c: Updating copyright years, removing "Contributed by"
lines and update URL for license.
* soft-fp/addsf3.c: Likewise.
* soft-fp/addtf3.c: Likewise.
* soft-fp/divdf3.c: Likewise.
* soft-fp/divsf3.c: Likewise.
* soft-fp/divtf3.c: Likewise.
* soft-fp/double.h: Likewise.
* soft-fp/eqdf2.c: Likewise.
* soft-fp/eqhf2.c: Likewise.
* soft-fp/eqsf2.c: Likewise.
* soft-fp/eqtf2.c: Likewise.
* soft-fp/extenddftf2.c: Likewise.
* soft-fp/extended.h: Likewise.
* soft-fp/extendhfdf2.c: Likewise.
* soft-fp/extendhfsf2.c: Likewise.
* soft-fp/extendhftf2.c: Likewise.
* soft-fp/extendhfxf2.c: Likewise.
* soft-fp/extendsfdf2.c: Likewise.
* soft-fp/extendsftf2.c: Likewise.
* soft-fp/extendxftf2.c: Likewise.
* soft-fp/fixdfdi.c: Likewise.
* soft-fp/fixdfsi.c: Likewise.
* soft-fp/fixdfti.c: Likewise.
* soft-fp/fixhfti.c: Likewise.
* soft-fp/fixsfdi.c: Likewise.
* soft-fp/fixsfsi.c: Likewise.
* soft-fp/fixsfti.c: Likewise.
* soft-fp/fixtfdi.c: Likewise.
* soft-fp/fixtfsi.c: Likewise.
* soft-fp/fixtfti.c: Likewise.
* soft-fp/fixunsdfdi.c: Likewise.
* soft-fp/fixunsdfsi.c: Likewise.
* soft-fp/fixunsdfti.c: Likewise.
* soft-fp/fixunshfti.c: Likewise.
* soft-fp/fixunssfdi.c: Likewise.
* soft-fp/fixunssfsi.c: Likewise.
* soft-fp/fixunssfti.c: Likewise.
* soft-fp/fixunstfdi.c: Likewise.
* soft-fp/fixunstfsi.c: Likewise.
* soft-fp/fixunstfti.c: Likewise.
* soft-fp/floatdidf.c: Likewise.
* soft-fp/floatdisf.c: Likewise.
* soft-fp/floatditf.c: Likewise.
* soft-fp/floatsidf.c: Likewise.
* soft-fp/floatsisf.c: Likewise.
* soft-fp/floatsitf.c: Likewise.
* soft-fp/floattidf.c: Likewise.
* soft-fp/floattihf.c: Likewise.
* soft-fp/floattisf.c: Likewise.
* soft-fp/floattitf.c: Likewise.
* soft-fp/floatundidf.c: Likewise.
* soft-fp/floatundisf.c: Likewise.
* soft-fp/floatunditf.c: Likewise.
* soft-fp/floatunsidf.c: Likewise.
* soft-fp/floatunsisf.c: Likewise.
* soft-fp/floatunsitf.c: Likewise.
* soft-fp/floatuntidf.c: Likewise.
* soft-fp/floatuntihf.c: Likewise.
* soft-fp/floatuntisf.c: Likewise.
* soft-fp/floatuntitf.c: Likewise.
* soft-fp/gedf2.c: Likewise.
* soft-fp/gesf2.c: Likewise.
* soft-fp/getf2.c: Likewise.
* soft-fp/half.h: Likewise.
* soft-fp/ledf2.c: Likewise.
* soft-fp/lesf2.c: Likewise.
* soft-fp/letf2.c: Likewise.
* soft-fp/muldf3.c: Likewise.
* soft-fp/mulsf3.c: Likewise.
* soft-fp/multf3.c: Likewise.
* soft-fp/negdf2.c: Likewise.
* soft-fp/negsf2.c: Likewise.
* soft-fp/negtf2.c: Likewise.
* soft-fp/op-1.h: Likewise.
* soft-fp/op-2.h: Likewise.
* soft-fp/op-4.h: Likewise.
* soft-fp/op-8.h: Likewise.
* soft-fp/op-common.h: Likewise.
* soft-fp/quad.h: Likewise.
* soft-fp/single.h: Likewise.
* soft-fp/soft-fp.h: Likewise.
* soft-fp/subdf3.c: Likewise.
* soft-fp/subsf3.c: Likewise.
* soft-fp/subtf3.c: Likewise.
* soft-fp/truncdfhf2.c: Likewise.
* soft-fp/truncdfsf2.c: Likewise.
* soft-fp/truncsfhf2.c: Likewise.
* soft-fp/trunctfdf2.c: Likewise.
* soft-fp/trunctfhf2.c: Likewise.
* soft-fp/trunctfsf2.c: Likewise.
* soft-fp/trunctfxf2.c: Likewise.
* soft-fp/truncxfhf2.c: Likewise.
* soft-fp/unorddf2.c: Likewise.
* soft-fp/unordsf2.c: Likewise.
---
 libgcc/soft-fp/adddf3.c  |  6 ++---
 libgcc/soft-fp/addsf3.c  |  6 ++---
 libgcc/soft-fp/addtf3.c  |  6 ++---
 libgcc/soft-fp/divdf3.c  |  6 ++---
 libgcc/soft-fp/divsf3.c  |  6 ++---
 libgcc/soft-fp/divtf3.c  |  6 ++---
 libgcc/soft-fp/double.h  |  8 ++-
 libgcc/soft-fp/eqdf2.c   |  6 ++---
 libgcc/soft-fp/eqhf2.c   |  2 +-
 libgcc/soft-fp/eqsf2.c   |  6 ++---
 libgcc/soft-fp/eqtf2.c   |  6 ++---
 libgcc/soft-fp/extenddftf2.c |  6 

[Bug middle-end/106578] spurious -Wuse-after-free=2 after conditional free()

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

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

--- Comment #1 from Gökçe Aydos  ---
FYI: [`realloc` behavior in the C11
standard](http://port70.net/~nsz/c/c11/n1570.html#7.22.3.5)

[Bug middle-end/106578] New: spurious -Wuse-after-free=2 after conditional free()

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

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

Bug ID: 106578
   Summary: spurious -Wuse-after-free=2 after conditional free()
   Product: gcc
   Version: 12.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc.gnu.org at aydos dot de
  Target Milestone: ---

I am new to GCC's components, so feel free to rename the headers if I
classified the bug wrong.

The following code throws the `use-after-free` error:

```
#include 

void *buf = NULL;
size_t buf_size = 0;

int main() {
void *tmp = buf;

buf = realloc(tmp, 10);

// Realloc returns a pointer to the new object, or a null pointer if the
// new object could not be allocated. Free the original pointer
// to avoid memory leak in latter case.
if (!buf)
free(tmp);
}
```
```
$ gcc -Wall -Wuse-after-free=2 main.c
main.c: In function ‘main’:
main.c:15:17: warning: pointer ‘tmp’ may be used after ‘realloc’
[-Wuse-after-free]
   15 | free(tmp);
  | ^
main.c:9:15: note: call to ‘realloc’ here
9 | buf = realloc(tmp, 10);
  |   ^~~~
```

A workaround is to `realloc` directly `buf` and use `tmp` for the return value
of `realloc`:

```
#include 

void *buf = NULL;
size_t buf_size = 0;

int main() {
void *tmp = buf;

tmp = realloc(buf, 10);

if (!tmp)
free(buf);
}
```

>From what I saw in other bugs this one may also be related to the meta-bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104075.

Can someone confirm this case?

Re: [PATCH] tree-optimization/106513 - fix mistake in bswap symbolic number shifts

[Jakub Jelinek via Gcc-patches]

On Wed, Aug 10, 2022 at 03:47:10PM +0200, Richard Biener via Gcc-patches wrote:
> This fixes a mistake in typing a local variable in the symbolic
> shift routine.
> 
> Bootstrap & regtest pending on x86_64-unknown-linux-gnu.
> 
>   PR tree-optimization/106513
>   * gimple-ssa-store-merging.cc (do_shift_rotate): Use uint64_t
>   for head_marker.

Ok.

> 
>   * gcc.dg/torture/pr106513.c: New testcase.

> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/torture/pr106513.c
> @@ -0,0 +1,26 @@
> +/* { dg-do run } */
> +
> +typedef __INT64_TYPE__ int64_t;
> +
> +__attribute__((noinline)) int64_t
> +swap64 (int64_t n)
> +{
> +  return (((n & (((int64_t) 0xff) )) << 56) |
> +  ((n & (((int64_t) 0xff) << 8)) << 40) |
> +  ((n & (((int64_t) 0xff) << 16)) << 24) |
> +  ((n & (((int64_t) 0xff) << 24)) << 8) |
> +  ((n & (((int64_t) 0xff) << 32)) >> 8) |
> +  ((n & (((int64_t) 0xff) << 40)) >> 24) |
> +  ((n & (((int64_t) 0xff) << 48)) >> 40) |
> +  ((n & ((int64_t)(0xffull << 56))) >> 56));
> +}
> +
> +int main (void)
> +{
> +  volatile int64_t n = 0x8000l;
> +
> +  if (swap64(n) != 0xff80l)
> +__builtin_abort ();

Please use ll instead of l in both cases above.
Perhaps -0x80ll would be simpler...

Jakub

[Bug tree-optimization/106570] [12/13 Regression] DCE sometimes fails with depending if statements since r12-2305-g398572c1544d8b75

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
   Priority|P3  |P2

[Bug target/106524] [12/13 Regression] ICE in extract_insn, at recog.cc:2791 (error: unrecognizable insn) since r12-4349-ge36206c9940d22.

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug tree-optimization/106514] [12/13 Regression] ranger slowness in path query

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

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2022-08-10
 Ever confirmed|0   |1
   Priority|P3  |P2
 Status|UNCONFIRMED |NEW

[Bug tree-optimization/106513] [10/11/12/13 Regression] bswap pass misses that >>56 for signed types can be replicate the sign bit

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

[Bug analyzer/106147] RFE: -fanalyzer could complain about some cases of infinite loops and infinite recursion

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

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

--- Comment #3 from David Malcolm  ---
See also https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106203#c1 (w.r.t possible
revamp of how source locations are tracked in the analyzer, given that an
infinite loop might not contain any statements)

[PATCH] tree-optimization/106513 - fix mistake in bswap symbolic number shifts

[Richard Biener via Gcc-patches]

This fixes a mistake in typing a local variable in the symbolic
shift routine.

Bootstrap & regtest pending on x86_64-unknown-linux-gnu.

PR tree-optimization/106513
* gimple-ssa-store-merging.cc (do_shift_rotate): Use uint64_t
for head_marker.

* gcc.dg/torture/pr106513.c: New testcase.
---
 gcc/gimple-ssa-store-merging.cc |  2 +-
 gcc/testsuite/gcc.dg/torture/pr106513.c | 26 +
 2 files changed, 27 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.dg/torture/pr106513.c

diff --git a/gcc/gimple-ssa-store-merging.cc b/gcc/gimple-ssa-store-merging.cc
index 0640168bcc4..b80b8eac444 100644
--- a/gcc/gimple-ssa-store-merging.cc
+++ b/gcc/gimple-ssa-store-merging.cc
@@ -263,7 +263,7 @@ do_shift_rotate (enum tree_code code,
 int count)
 {
   int i, size = TYPE_PRECISION (n->type) / BITS_PER_UNIT;
-  unsigned head_marker;
+  uint64_t head_marker;
 
   if (count < 0
   || count >= TYPE_PRECISION (n->type)
diff --git a/gcc/testsuite/gcc.dg/torture/pr106513.c 
b/gcc/testsuite/gcc.dg/torture/pr106513.c
new file mode 100644
index 000..92c02ffb37b
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/torture/pr106513.c
@@ -0,0 +1,26 @@
+/* { dg-do run } */
+
+typedef __INT64_TYPE__ int64_t;
+
+__attribute__((noinline)) int64_t
+swap64 (int64_t n)
+{
+  return (((n & (((int64_t) 0xff) )) << 56) |
+  ((n & (((int64_t) 0xff) << 8)) << 40) |
+  ((n & (((int64_t) 0xff) << 16)) << 24) |
+  ((n & (((int64_t) 0xff) << 24)) << 8) |
+  ((n & (((int64_t) 0xff) << 32)) >> 8) |
+  ((n & (((int64_t) 0xff) << 40)) >> 24) |
+  ((n & (((int64_t) 0xff) << 48)) >> 40) |
+  ((n & ((int64_t)(0xffull << 56))) >> 56));
+}
+
+int main (void)
+{
+  volatile int64_t n = 0x8000l;
+
+  if (swap64(n) != 0xff80l)
+__builtin_abort ();
+
+  return 0;
+}
-- 
2.35.3

[Bug analyzer/106203] Allow to emit diagnostics at return edges for the exit point as well as the call site

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

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

--- Comment #1 from David Malcolm  ---
I've been prototyping an implementation of PR 106147 (infinite loop detection),
and in some cases there aren't any statements at all for my warnings, just
location_t values (if that).  So as part of that I've been looking at a big
revamp of how source locations are tracked in the analyzer; I may be able to
fix this as part of that.

[Bug ipa/101839] [10/11/12/13 Regression] Hang in C++ code with -fdevirtualize

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

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

--- Comment #10 from Jan Hubicka  ---
Created attachment 53430
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53430=edit
Patch I am testing

[Bug tree-optimization/106513] [10/11/12/13 Regression] bswap pass misses that >>56 for signed types can be replicate the sign bit

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #4 from Richard Biener  ---
Mine.

diff --git a/gcc/gimple-ssa-store-merging.cc b/gcc/gimple-ssa-store-merging.cc
index 0640168bcc4..b80b8eac444 100644
--- a/gcc/gimple-ssa-store-merging.cc
+++ b/gcc/gimple-ssa-store-merging.cc
@@ -263,7 +263,7 @@ do_shift_rotate (enum tree_code code,
 int count)
 {
   int i, size = TYPE_PRECISION (n->type) / BITS_PER_UNIT;
-  unsigned head_marker;
+  uint64_t head_marker;

   if (count < 0
   || count >= TYPE_PRECISION (n->type)

[Bug tree-optimization/106458] [12/13 Regression] glibc's malloc/tst-scratch_buffer.c test is miscompiled with gcc-12

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

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

--- Comment #11 from Richard Biener  ---
The dump difference is easily explained by taming PRE when -ftree-vectorize is
on, it's not a "real" difference.

When I try with a cc1 cross I see

> ./cc1 -quiet t.i -fpreprocessed -O2 -g -std=gnu11 -fgnu89-inline 
> -fmerge-all-constants -frounding-math -fno-stack-protector -fno-common 
> -fmath-errno-fno-pie -fopt-info-vec

and nothing actually vectorized.  Besides the PRE there seems to be a missed
DSE at the end (when vectorization is enabled as after the change):

   # DEBUG BEGIN_STMT
   memset (__space.__c, 64, 1024);
   # DEBUG BEGIN_STMT
+  sizes[0] = 16;
   sizes[1] = 1024;
   sizes[2] = 1040;

otherwise I see nothing suspicious in differences in .optimized when
comparing -fdump-tree-optimized with/without -fno-tree-vectorize.

You could try if -fno-tree-pre reproduces it also before the change.