date:20230516

[PATCH] RISC-V: Introduce rounding mode operand into fixed-point intrinsics

2023-05-16 Thread juzhe . zhong

From: Juzhe-Zhong 

According to new comming fixed-point API:
https://github.com/riscv-non-isa/rvv-intrinsic-doc/pull/222

Introduce vxrm argument:
- vint32m1_t __riscv_vsadd_vv_i32m1 (vint32m1_t op1, vint32m1_t op2, size_t vl);
+ vint32m1_t __riscv_vsadd_vv_i32m1 (vint32m1_t op1, vint32m1_t op2, size_t 
vxrm, size_t vl);

This patch doesn't insert vxrm csrw configuration instruction yet.
Will support automatically insert csrw vxrm instruction in the next patch.

This patch does this following:
1. Only extend the vxrm argument.
2. Check vxrm argument is invalid immediate and report error message if it is 
invalid.

gcc/ChangeLog:

* config/riscv/riscv-vector-builtins-bases.cc: Introduce rounding mode.
* config/riscv/riscv-vector-builtins-shapes.cc (struct alu_def): Ditto.
(struct narrow_alu_def): Ditto.
* config/riscv/riscv-vector-builtins.cc 
(function_builder::apply_predication): Ditto.
(function_expander::use_exact_insn): Ditto.
* config/riscv/riscv-vector-builtins.h (function_checker::arg_num): New 
function.
(function_base::has_rounding_mode_operand_p): New function.

gcc/testsuite/ChangeLog:

* g++.target/riscv/rvv/base/bug-11.C: Adapt testcase.
* g++.target/riscv/rvv/base/bug-12.C: Ditto.
* g++.target/riscv/rvv/base/bug-14.C: Ditto.
* g++.target/riscv/rvv/base/bug-15.C: Ditto.
* g++.target/riscv/rvv/base/bug-16.C: Ditto.
* g++.target/riscv/rvv/base/bug-17.C: Ditto.
* g++.target/riscv/rvv/base/bug-18.C: Ditto.
* g++.target/riscv/rvv/base/bug-19.C: Ditto.
* g++.target/riscv/rvv/base/bug-20.C: Ditto.
* g++.target/riscv/rvv/base/bug-21.C: Ditto.
* g++.target/riscv/rvv/base/bug-22.C: Ditto.
* g++.target/riscv/rvv/base/bug-23.C: Ditto.
* g++.target/riscv/rvv/base/bug-3.C: Ditto.
* g++.target/riscv/rvv/base/bug-5.C: Ditto.
* g++.target/riscv/rvv/base/bug-6.C: Ditto.
* g++.target/riscv/rvv/base/bug-8.C: Ditto.
* gcc.target/riscv/rvv/base/binop_vx_constraint-100.c: Ditto.
* gcc.target/riscv/rvv/base/binop_vx_constraint-101.c: Ditto.
* gcc.target/riscv/rvv/base/binop_vx_constraint-102.c: Ditto.
* gcc.target/riscv/rvv/base/binop_vx_constraint-103.c: Ditto.
* gcc.target/riscv/rvv/base/binop_vx_constraint-104.c: Ditto.
* gcc.target/riscv/rvv/base/binop_vx_constraint-105.c: Ditto.
* gcc.target/riscv/rvv/base/binop_vx_constraint-106.c: Ditto.
* gcc.target/riscv/rvv/base/binop_vx_constraint-107.c: Ditto.
* gcc.target/riscv/rvv/base/binop_vx_constraint-108.c: Ditto.
* gcc.target/riscv/rvv/base/binop_vx_constraint-109.c: Ditto.
* gcc.target/riscv/rvv/base/binop_vx_constraint-110.c: Ditto.
* gcc.target/riscv/rvv/base/binop_vx_constraint-111.c: Ditto.
* gcc.target/riscv/rvv/base/binop_vx_constraint-112.c: Ditto.
* gcc.target/riscv/rvv/base/binop_vx_constraint-113.c: Ditto.
* gcc.target/riscv/rvv/base/binop_vx_constraint-114.c: Ditto.
* gcc.target/riscv/rvv/base/binop_vx_constraint-115.c: Ditto.
* gcc.target/riscv/rvv/base/binop_vx_constraint-116.c: Ditto.
* gcc.target/riscv/rvv/base/binop_vx_constraint-117.c: Ditto.
* gcc.target/riscv/rvv/base/binop_vx_constraint-118.c: Ditto.
* gcc.target/riscv/rvv/base/binop_vx_constraint-119.c: Ditto.
* gcc.target/riscv/rvv/base/binop_vx_constraint-122.c: Ditto.
* gcc.target/riscv/rvv/base/binop_vx_constraint-97.c: Ditto.
* gcc.target/riscv/rvv/base/binop_vx_constraint-98.c: Ditto.
* gcc.target/riscv/rvv/base/merge_constraint-1.c: Ditto.
* gcc.target/riscv/rvv/base/narrow_constraint-6.c: Ditto.
* gcc.target/riscv/rvv/base/narrow_constraint-7.c: Ditto.
* gcc.target/riscv/rvv/base/narrow_constraint-8.c: Ditto.
* gcc.target/riscv/rvv/base/narrow_constraint-9.c: Ditto.
* gcc.target/riscv/rvv/base/vxrm-2.c: New test.
* gcc.target/riscv/rvv/base/vxrm-3.c: New test.
* gcc.target/riscv/rvv/base/vxrm-4.c: New test.
* gcc.target/riscv/rvv/base/vxrm-5.c: New test.

---
 .../riscv/riscv-vector-builtins-bases.cc  |  10 ++
 .../riscv/riscv-vector-builtins-shapes.cc |  26 +++
 gcc/config/riscv/riscv-vector-builtins.cc |  19 +-
 gcc/config/riscv/riscv-vector-builtins.h  |  18 ++
 .../g++.target/riscv/rvv/base/bug-11.C|   2 +-
 .../g++.target/riscv/rvv/base/bug-12.C|   8 +-
 .../g++.target/riscv/rvv/base/bug-14.C|   4 +-
 .../g++.target/riscv/rvv/base/bug-15.C|   2 +-
 .../g++.target/riscv/rvv/base/bug-16.C|   8 +-
 .../g++.target/riscv/rvv/base/bug-17.C|   2 +-
 .../g++.target/riscv/rvv/base/bug-18.C|   2 +-
 .../g++.target/riscv/rvv/base/bug-19.C|   2 +-
 .../g++.target/riscv/rvv/base/bug-20.C|   2 +-
 .../g++.target/riscv/rvv/base/bug-21.C|   2 +-

[Bug rtl-optimization/109858] [14 Regression] r14-172 caused some SPEC2017 bmk to degrade on Power

2023-05-16 Thread linkw at gcc dot gnu.org via Gcc-bugs

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

--- Comment #9 from Kewen Lin  ---
(In reply to Kewen Lin from comment #6)
> (In reply to Hongtao.liu from comment #5)
> > (In reply to Kewen Lin from comment #3)
> > > (In reply to Hongtao.liu from comment #2)
> > > > Does https://gcc.gnu.org/pipermail/gcc-patches/2023-May/617431.html 
> > > > help?
> > > 
> > > Sorry, I just measured those degraded bmks with this fix, the results 
> > > showed
> > > it didn't help.
> > 
> > Sorry for the inconvience, could you try again with attached patch.
> > The patch will still use GENERAL_REGS when hard_regno_mode_ok for mode and
> > GENERAL_REGS(which is the case in PR109610), hope it can also fix this
> > regression.
> 
> Thanks for the prompt fix, I'll do the perf evaluation once the perf boxes
> get released (they are used by others now) and get back to you.

I re-evaluated all SPEC2017 bmks on Power9 and Power10 with this patch (r14-171
vs. r14-172 + this fix), and confirmed it does fix all three degradation found
before and it doesn't cause any new degradation (btw, all the >1% improvements
are gone as well, all the results are neutral).

Re: RISC-V: Remove masking third operand of rotate instructions

2023-05-16 Thread Jeff Law via Gcc-patches

On 5/10/23 09:50, Jivan Hakobyan via Gcc-patches wrote:

Subject:
RISC-V: Remove masking third operand of rotate instructions
From:
Jivan Hakobyan via Gcc-patches 
Date:
5/10/23, 09:50

To:
gcc-patches@gcc.gnu.org

Rotate instructions do not need to mask the third operand.
For example  RV64 the following code:

unsigned long foo1(unsigned long rs1, unsigned long rs2)
{
 long shamt = rs2 & (64 - 1);
 return (rs1 << shamt) | (rs1 >> ((64 - shamt) & (64 - 1)));
}

Compiles to:
foo1:
 andia1,a1,63
 rol a0,a0,a1
 ret

This patch removes unnecessary masking.
Besides, I have merged masking insns for shifts that were written before.

gcc/ChangeLog:
 * config/riscv/riscv.md: Merged
 * config/riscv/bitmanip.md: New insns
 * config/riscv/iterators.md: New iterator and optab items
 * config/riscv/predicates.md: New predicates
Usually we try to mention the patterns that got changed.  So something 
like this

* config/riscv/riscv.md (*3_mask):  New pattern,
combined from
(*si3_mask, *di3_mask): Here.

Similarly for the other patterns in riscv.md that you combined.

For the bitmanip ChangeLog it might look like

* config/riscv/bitmanip.md (*3_mask): New
pattern.
(*si3_sext_mask): Likewise.

* config/riscv/iterators.md (shiftm1): Generalize to handle more
masking constants.
(bitmanip_rotate): New iterator.
(bitmanip_optab): Add rotates.

* config/riscv/predicates.md (const_si_mask_operand): Renamed
from const31_operand.  Generalize to handle more mask constants.
(const_di_mask_operand): Similarly.

-- With the best regards Jivan Hakobyan

rotate_mask.patch

diff --git a/gcc/config/riscv/bitmanip.md b/gcc/config/riscv/bitmanip.md
index a27fc3e34a1..0fd0cbdeb04 100644
--- a/gcc/config/riscv/bitmanip.md
+++ b/gcc/config/riscv/bitmanip.md
@@ -351,6 +351,42 @@
"rolw\t%0,%1,%2"
[(set_attr "type" "bitmanip")])

+(define_insn_and_split "*3_mask"

+  [(set (match_operand:X 0 "register_operand" "= r")
+(bitmanip_rotate:X
+(match_operand:X 1 "register_operand" "  r")
+(match_operator 4 "subreg_lowpart_operator"
+ [(and:X
+   (match_operand:X 2 "register_operand"  "r")
+   (match_operand 3 "" ""))])))]
+  "TARGET_ZBB || TARGET_ZBKB"
+  "#"
+  "&& 1"
+  [(set (match_dup 0)
+(bitmanip_rotate:X (match_dup 1)
+   (match_dup 2)))]
+  "operands[2] = gen_lowpart (QImode, operands[2]);"
+  [(set_attr "type" "bitmanip")
+   (set_attr "mode" "")])
It's worth noting that by using a subreg_lowpart_operator in this manner 
we can match any narrowing subreg lowpart rather than being restricted 
to QImode.  Clever use of iterators for the predicate and constraints on 
operand 3 as well.

diff --git a/gcc/config/riscv/riscv.md b/gcc/config/riscv/riscv.md
index c508ee3ad89..777d9468efa 100644
--- a/gcc/config/riscv/riscv.md
+++ b/gcc/config/riscv/riscv.md
@@ -2010,44 +2010,23 @@
[(set_attr "type" "shift")
 (set_attr "mode" "SI")])

-(define_insn_and_split "*si3_mask"

-  [(set (match_operand:SI 0 "register_operand" "= r")
-   (any_shift:SI
-   (match_operand:SI 1 "register_operand" "  r")
+(define_insn_and_split "*3_mask"
+  [(set (match_operand:X 0 "register_operand" "= r")
+   (any_shift:X
+   (match_operand:X 1 "register_operand" "  r")
(match_operator 4 "subreg_lowpart_operator"
 [(and:SI
   (match_operand:SI 2 "register_operand"  "r")
-  (match_operand 3 "const_int_operand"))])))]

Shouldn't the mode of operand 2 change to "X" as well?

-(define_insn_and_split "*di3_mask_1"
-  [(set (match_operand:DI 0 "register_operand" "= r")
-   (any_shift:DI
-   (match_operand:DI 1 "register_operand" "  r")
+(define_insn_and_split "*3_mask_1"
+  [(set (match_operand:GPR 0 "register_operand" "= r")
+   (any_shift:GPR
+   (match_operand:GPR 1 "register_operand" "  r")
(match_operator 4 "subreg_lowpart_operator"
 [(and:DI
   (match_operand:DI 2 "register_operand"  "r")
-  (match_operand 3 "const_int_operand"))])))]
Presumably we use GPR here because for TARGET_64BIT we can match both 
the 32bit and 64bit opcodes?  I was wondering if we should do the same 
for the rotate patterns -- use the GPR iterator rather than the X 
iterator to match rol[w] and ror[w].

Overall it looks really good.  Both in terms of improving code 
generation for the rotates and cleaning up the shift patterns a bit too. 
 Just a couple questions/cleanups and an improved ChangeLog and this 
should be good to go.

jeff

[Bug middle-end/90663] [10/11/12/13/14 Regression] strcmp ([i], a + i) not folded for arrays and constant index

2023-05-16 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

--- Comment #10 from Andrew Pinski  ---
Created attachment 55097
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55097=edit
Patch which I am testing

[Bug tree-optimization/106900] Regression after memchr optimization

2023-05-16 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||patch
URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2023-May/618
   ||762.html

--- Comment #5 from Andrew Pinski  ---
Patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2023-May/618762.html

Re: RISC-V Test Errors and Failures

2023-05-16 Thread Jeff Law via Gcc-patches





On 5/16/23 20:39, Palmer Dabbelt wrote:



By "chroot environment" you mean something like a 
debootstrap-into-chroot with qemu-user/binfmt-misc?  I don't have that 
setup right now, but it wouldn't be a big lift.
Essentially, yes.  I actually have a home built ones for the various 
targets.  There was a time when they needed to be <100M so they could be 
stored on github.  Going forward I just want them to be a docker 
container for Fedora or Ubuntu.  With binfmt you can run non-native 
containers trivially.


jeff

Re: RISC-V Test Errors and Failures

2023-05-16 Thread Jeff Law via Gcc-patches





On 5/16/23 21:33, Kito Cheng via Gcc-patches wrote:

diff --git a/scripts/wrapper/qemu/riscv64-unknown-linux-gnu-run 
b/scripts/wrapper/qemu/riscv64-unknown-linux-gnu-run
index 94d6ec5..efc3a80 100755
--- a/scripts/wrapper/qemu/riscv64-unknown-linux-gnu-run
+++ b/scripts/wrapper/qemu/riscv64-unknown-linux-gnu-run
@@ -12,4 +12,4 @@ done

  xlen="$(readelf -h $1 | grep 'Class' | cut -d: -f 2 | xargs echo | sed 
's/^ELF//')"

-qemu-riscv$xlen -r 5.10 "${qemu_args[@]}" -L ${RISC_V_SYSROOT} -cpu 
rv$xlen,zba=on,zbb=on,zbc=on,zbs=on "$@"
+qemu-riscv$xlen -r 5.10 "${qemu_args[@]}" -L ${RISC_V_SYSROOT} -cpu 
rv$xlen,zba=on,zbb=on,zbc=on,zbs=on,v=on "$@"


This not work when you testing some combination e.g. Z*inx and zve*,
but anyway I guess those configurations are not matter for you guys :P
What you could do is install a suitable binfmt handler, then you don't 
need the wrappers at all.  That's how we're handling this stuff in 
Ventana.  It also means you don't need magic dejagnu baseboard files or 
anything like that.  In fact from dejagnu's standpoint it looks native.


jeff

Re: Re: [PATCH V5] RISC-V: Using merge approach to optimize repeating sequence in vec_init

2023-05-16 Thread Kito Cheng via Gcc-patches

On Wed, May 17, 2023 at 11:36 AM juzhe.zh...@rivai.ai
 wrote:
>
> >> Does it means we assume inner_int_mode is DImode? (because sizeof 
> >> (uint64_t))
> >> or it should be something like `for (unsigned int i = 0; i <
> >> (GET_MODE_SIZE(inner_int_mode ()) * 8 / npatterns ()); i++)` ?
> No, sizeof (uint64_t) means uint64_t mask = 0;

+  return gen_int_mode (mask, inner_int_mode ());
And we expect the uint64_t mask can always be put into inner_int_mode ()?
If not, why do we fill up all 64 bits?

>
> >> Do you mind give more comment about this? what it checked and what it did?
> The reason we use known_gt (GET_MODE_SIZE (dup_mode), BYTES_PER_RISCV_VECTOR)
> since we want are using vector integer mode to generate the mask for example
> we generate 0b01010101010101 mask, we should use a scalar register 
> holding value = 0b010101010...
> Then vmv.v.x into a vector,then this vector will be used as a mask.
>
> >> Why this only hide in else? I guess I have this question is because I
> >> don't fully understand the logic of the if condition?
>
> Since we can't vector floting-point instruction to generate a mask.

I don't get why it's not something like below?

if (known_gt (GET_MODE_SIZE (dup_mode), BYTES_PER_RISCV_VECTOR))
{
...
}
if (FLOAT_MODE_P (dup_mode))
{
...
}



>
> >> nit: builder.inner_mode () rather than GET_MODE_INNER (dup_mode)?
>
> They are the same. I can change it using GET_MODE_INNER
>
> >> And I would like have more commnet to explain why we need force_reg here.
> Since it will creat ICE.

But why? And why can it be resolved by force_reg? you need few more
comment in the code

Re: Re: [PATCH V5] RISC-V: Using merge approach to optimize repeating sequence in vec_init

2023-05-16 Thread juzhe.zh...@rivai.ai

>> Does it means we assume inner_int_mode is DImode? (because sizeof (uint64_t))
>> or it should be something like `for (unsigned int i = 0; i <
>> (GET_MODE_SIZE(inner_int_mode ()) * 8 / npatterns ()); i++)` ?
No, sizeof (uint64_t) means uint64_t mask = 0;

>> Do you mind give more comment about this? what it checked and what it did?
The reason we use known_gt (GET_MODE_SIZE (dup_mode), BYTES_PER_RISCV_VECTOR)
since we want are using vector integer mode to generate the mask for example
we generate 0b01010101010101 mask, we should use a scalar register holding 
value = 0b010101010...
Then vmv.v.x into a vector,then this vector will be used as a mask.

>> Why this only hide in else? I guess I have this question is because I
>> don't fully understand the logic of the if condition?

Since we can't vector floting-point instruction to generate a mask.

>> nit: builder.inner_mode () rather than GET_MODE_INNER (dup_mode)?

They are the same. I can change it using GET_MODE_INNER

>> And I would like have more commnet to explain why we need force_reg here.
Since it will creat ICE.




juzhe.zh...@rivai.ai
 
From: Kito Cheng
Date: 2023-05-17 11:21
To: juzhe.zhong
CC: gcc-patches; palmer; jeffreyalaw
Subject: Re: [PATCH V5] RISC-V: Using merge approach to optimize repeating 
sequence in vec_init
> +
> +/* Get the mask for merge approach.
> +
> + Consider such following case:
> +   {a, b, a, b, a, b, a, b, a, b, a, b, a, b, a, b}
> + To merge "a", the mask should be 1010
> + To merge "b", the mask should be 0101
> +*/
> +rtx
> +rvv_builder::get_merge_mask_bitfield (unsigned int index) const
> +{
> +  uint64_t base_mask = (1ULL << index);
> +  uint64_t mask = 0;
> +  for (unsigned int i = 0; i < (sizeof (uint64_t) * 8 / npatterns ()); i++)
> +mask |= base_mask << (i * npatterns ());
> +  return gen_int_mode (mask, inner_int_mode ());
 
Does it means we assume inner_int_mode is DImode? (because sizeof (uint64_t))
or it should be something like `for (unsigned int i = 0; i <
(GET_MODE_SIZE(inner_int_mode ()) * 8 / npatterns ()); i++)` ?
 
> +}
> +
>  /* Subroutine of riscv_vector_expand_vector_init.
> Works as follows:
> (a) Initialize TARGET by broadcasting element NELTS_REQD - 1 of BUILDER.
> @@ -1226,6 +1307,107 @@ expand_vector_init_insert_elems (rtx target, const 
> rvv_builder ,
>  }
>  }
>
> +/* Emit vmv.s.x instruction.  */
> +
> +static void
> +emit_scalar_move_op (rtx dest, rtx src, machine_mode mask_mode)
> +{
> +  insn_expander<8> e;
> +  machine_mode mode = GET_MODE (dest);
> +  rtx scalar_move_mask = gen_scalar_move_mask (mask_mode);
> +  e.set_dest_and_mask (scalar_move_mask, dest, mask_mode);
> +  e.add_input_operand (src, GET_MODE_INNER (mode));
> +  e.set_len_and_policy (const1_rtx, false);
> +  e.expand (code_for_pred_broadcast (mode), false);
> +}
> +
> +/* Emit merge instruction.  */
> +
> +static void
> +emit_merge_op (rtx dest, rtx src1, rtx src2, rtx mask)
> +{
> +  insn_expander<8> e;
> +  machine_mode mode = GET_MODE (dest);
> +  e.set_dest_merge (dest);
> +  e.add_input_operand (src1, mode);
> +  if (VECTOR_MODE_P (GET_MODE (src2)))
> +e.add_input_operand (src2, mode);
> +  else
> +e.add_input_operand (src2, GET_MODE_INNER (mode));
> +
> +  e.add_input_operand (mask, GET_MODE (mask));
> +  e.set_len_and_policy (NULL_RTX, true, true, false);
> +  if (VECTOR_MODE_P (GET_MODE (src2)))
> +e.expand (code_for_pred_merge (mode), false);
> +  else
> +e.expand (code_for_pred_merge_scalar (mode), false);
> +}
> +
> +/* Use merge approach to initialize the vector with repeating sequence.
> + v = {a, b, a, b, a, b, a, b}.
> +
> + v = broadcast (a).
> + mask = 0b01010101
> + v = merge (v, b, mask)
> +*/
> +static void
> +expand_vector_init_merge_repeating_sequence (rtx target,
> +const rvv_builder )
> +{
> +  machine_mode mask_mode = get_mask_mode (builder.mode ()).require ();
> +  machine_mode dup_mode = builder.mode ();
> +  if (known_gt (GET_MODE_SIZE (dup_mode), BYTES_PER_RISCV_VECTOR))
> +{
> +  poly_uint64 nunits
> +   = exact_div (BYTES_PER_RISCV_VECTOR, builder.inner_units ());
> +  dup_mode = get_vector_mode (builder.inner_int_mode (), nunits).require 
> ();
> +}
 
Do you mind give more comment about this? what it checked and what it did?
 
> +  else
> +{
> +  if (FLOAT_MODE_P (dup_mode))
> +   {
> + poly_uint64 nunits = GET_MODE_NUNITS (dup_mode);
> + dup_mode
> +   = get_vector_mode (builder.inner_int_mode (), nunits).require ();
> +   }
 
Why this only hide in else? I guess I have this question is because I
don't fully understand the logic of the if condition?
 
> +}
> +
> +  machine_mode dup_mask_mode = get_mask_mode (dup_mode).require ();
> +
> +  /* Step 1: Broadcast the 1st-pattern.  */
> +  emit_len_op (code_for_pred_broadcast (builder.mode ()), target,
> +  force_reg (builder.inner_mode (),

Re: RISC-V Test Errors and Failures

2023-05-16 Thread Kito Cheng via Gcc-patches

> diff --git a/scripts/wrapper/qemu/riscv64-unknown-linux-gnu-run 
> b/scripts/wrapper/qemu/riscv64-unknown-linux-gnu-run
> index 94d6ec5..efc3a80 100755
> --- a/scripts/wrapper/qemu/riscv64-unknown-linux-gnu-run
> +++ b/scripts/wrapper/qemu/riscv64-unknown-linux-gnu-run
> @@ -12,4 +12,4 @@ done
>
>  xlen="$(readelf -h $1 | grep 'Class' | cut -d: -f 2 | xargs echo | sed 
> 's/^ELF//')"
>
> -qemu-riscv$xlen -r 5.10 "${qemu_args[@]}" -L ${RISC_V_SYSROOT} -cpu 
> rv$xlen,zba=on,zbb=on,zbc=on,zbs=on "$@"
> +qemu-riscv$xlen -r 5.10 "${qemu_args[@]}" -L ${RISC_V_SYSROOT} -cpu 
> rv$xlen,zba=on,zbb=on,zbc=on,zbs=on,v=on "$@"

This not work when you testing some combination e.g. Z*inx and zve*,
but anyway I guess those configurations are not matter for you guys :P

>
> for now.  I'm going to throw together hwprobe for qemu-user, from looking at
> the AVX stuff it should be pretty easy to plumb that into DG and then get the
> detection going.

Re: [PATCH V5] RISC-V: Using merge approach to optimize repeating sequence in vec_init

2023-05-16 Thread Kito Cheng via Gcc-patches

> +
> +/* Get the mask for merge approach.
> +
> + Consider such following case:
> +   {a, b, a, b, a, b, a, b, a, b, a, b, a, b, a, b}
> + To merge "a", the mask should be 1010
> + To merge "b", the mask should be 0101
> +*/
> +rtx
> +rvv_builder::get_merge_mask_bitfield (unsigned int index) const
> +{
> +  uint64_t base_mask = (1ULL << index);
> +  uint64_t mask = 0;
> +  for (unsigned int i = 0; i < (sizeof (uint64_t) * 8 / npatterns ()); i++)
> +mask |= base_mask << (i * npatterns ());
> +  return gen_int_mode (mask, inner_int_mode ());

Does it means we assume inner_int_mode is DImode? (because sizeof (uint64_t))
or it should be something like `for (unsigned int i = 0; i <
(GET_MODE_SIZE(inner_int_mode ()) * 8 / npatterns ()); i++)` ?

> +}
> +
>  /* Subroutine of riscv_vector_expand_vector_init.
> Works as follows:
> (a) Initialize TARGET by broadcasting element NELTS_REQD - 1 of BUILDER.
> @@ -1226,6 +1307,107 @@ expand_vector_init_insert_elems (rtx target, const 
> rvv_builder ,
>  }
>  }
>
> +/* Emit vmv.s.x instruction.  */
> +
> +static void
> +emit_scalar_move_op (rtx dest, rtx src, machine_mode mask_mode)
> +{
> +  insn_expander<8> e;
> +  machine_mode mode = GET_MODE (dest);
> +  rtx scalar_move_mask = gen_scalar_move_mask (mask_mode);
> +  e.set_dest_and_mask (scalar_move_mask, dest, mask_mode);
> +  e.add_input_operand (src, GET_MODE_INNER (mode));
> +  e.set_len_and_policy (const1_rtx, false);
> +  e.expand (code_for_pred_broadcast (mode), false);
> +}
> +
> +/* Emit merge instruction.  */
> +
> +static void
> +emit_merge_op (rtx dest, rtx src1, rtx src2, rtx mask)
> +{
> +  insn_expander<8> e;
> +  machine_mode mode = GET_MODE (dest);
> +  e.set_dest_merge (dest);
> +  e.add_input_operand (src1, mode);
> +  if (VECTOR_MODE_P (GET_MODE (src2)))
> +e.add_input_operand (src2, mode);
> +  else
> +e.add_input_operand (src2, GET_MODE_INNER (mode));
> +
> +  e.add_input_operand (mask, GET_MODE (mask));
> +  e.set_len_and_policy (NULL_RTX, true, true, false);
> +  if (VECTOR_MODE_P (GET_MODE (src2)))
> +e.expand (code_for_pred_merge (mode), false);
> +  else
> +e.expand (code_for_pred_merge_scalar (mode), false);
> +}
> +
> +/* Use merge approach to initialize the vector with repeating sequence.
> + v = {a, b, a, b, a, b, a, b}.
> +
> + v = broadcast (a).
> + mask = 0b01010101
> + v = merge (v, b, mask)
> +*/
> +static void
> +expand_vector_init_merge_repeating_sequence (rtx target,
> +const rvv_builder )
> +{
> +  machine_mode mask_mode = get_mask_mode (builder.mode ()).require ();
> +  machine_mode dup_mode = builder.mode ();
> +  if (known_gt (GET_MODE_SIZE (dup_mode), BYTES_PER_RISCV_VECTOR))
> +{
> +  poly_uint64 nunits
> +   = exact_div (BYTES_PER_RISCV_VECTOR, builder.inner_units ());
> +  dup_mode = get_vector_mode (builder.inner_int_mode (), nunits).require 
> ();
> +}

Do you mind give more comment about this? what it checked and what it did?

> +  else
> +{
> +  if (FLOAT_MODE_P (dup_mode))
> +   {
> + poly_uint64 nunits = GET_MODE_NUNITS (dup_mode);
> + dup_mode
> +   = get_vector_mode (builder.inner_int_mode (), nunits).require ();
> +   }

Why this only hide in else? I guess I have this question is because I
don't fully understand the logic of the if condition?

> +}
> +
> +  machine_mode dup_mask_mode = get_mask_mode (dup_mode).require ();
> +
> +  /* Step 1: Broadcast the 1st-pattern.  */
> +  emit_len_op (code_for_pred_broadcast (builder.mode ()), target,
> +  force_reg (builder.inner_mode (), builder.elt (0)), NULL_RTX,
> +  mask_mode);
> +
> +  /* Step 2: Merge each non 1st pattern.  */
> +  for (unsigned int i = 1; i < builder.npatterns (); i++)
> +{
> +  /* Step 2-1: Generate mask register v0 for each merge.  */
> +  rtx mask_bitfield = builder.get_merge_mask_bitfield (i);
> +  rtx mask = gen_reg_rtx (mask_mode);
> +  rtx dup = gen_reg_rtx (dup_mode);
> +  if (builder.inner_size () >= builder.full_nelts ().to_constant ())
> +   {
> + /* Use vmv.s.x.  */
> + emit_scalar_move_op (dup, mask_bitfield, dup_mask_mode);
> +   }
> +  else
> +   {
> + /* Use vmv.v.x.  */
> + unsigned int mask_num = CEIL (builder.full_nelts ().to_constant (),
> +   builder.inner_size ());
> + rtx vl = gen_int_mode (mask_num, Pmode);
> + emit_len_op (code_for_pred_broadcast (dup_mode), dup,
> +  force_reg (GET_MODE_INNER (dup_mode), mask_bitfield), 
> vl,

nit: builder.inner_mode () rather than GET_MODE_INNER (dup_mode)?

And I would like have more commnet to explain why we need force_reg here.

I guess it's corresponding to FLOAT_MODE_P, but it's not easy to
understand at frist moment without comment.

Re: RISC-V Test Errors and Failures

2023-05-16 Thread Palmer Dabbelt


On Tue, 16 May 2023 20:08:26 PDT (-0700), Vineet Gupta wrote:


On 5/16/23 19:53, Palmer Dabbelt wrote:


Probably, I'll go try and bump stuff and see if it works...


Word of caution: Best to not disturb your existing setup, a try a fresh
checkout first


Even easier, I think I can get away with just

diff --git a/scripts/wrapper/qemu/riscv64-unknown-linux-gnu-run 
b/scripts/wrapper/qemu/riscv64-unknown-linux-gnu-run
index 94d6ec5..efc3a80 100755
--- a/scripts/wrapper/qemu/riscv64-unknown-linux-gnu-run
+++ b/scripts/wrapper/qemu/riscv64-unknown-linux-gnu-run
@@ -12,4 +12,4 @@ done

xlen="$(readelf -h $1 | grep 'Class' | cut -d: -f 2 | xargs echo | sed 
's/^ELF//')"

-qemu-riscv$xlen -r 5.10 "${qemu_args[@]}" -L ${RISC_V_SYSROOT} -cpu 
rv$xlen,zba=on,zbb=on,zbc=on,zbs=on "$@"
+qemu-riscv$xlen -r 5.10 "${qemu_args[@]}" -L ${RISC_V_SYSROOT} -cpu 
rv$xlen,zba=on,zbb=on,zbc=on,zbs=on,v=on "$@"

for now.  I'm going to throw together hwprobe for qemu-user, from looking at
the AVX stuff it should be pretty easy to plumb that into DG and then get the
detection going.

Re: RISC-V Test Errors and Failures

2023-05-16 Thread Vineet Gupta




On 5/16/23 19:53, Palmer Dabbelt wrote:


Probably, I'll go try and bump stuff and see if it works... 


Word of caution: Best to not disturb your existing setup, a try a fresh 
checkout first

[Bug fortran/109865] different results when routine moved inside the contains statement

2023-05-16 Thread jvdelisle at gcc dot gnu.org via Gcc-bugs

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #15 from Jerry DeLisle  ---
(In reply to gary.wh...@colostate.edu from comment #11)
> I've never used valgrind -- what would it do?
> 
 valgrind tracks and checks memory allocations during execution and can spot
where things, such as pointers that go astray.  This sometimes happens with
optimization bugs.

>From the man page. It has many tools and is very useful.

   Valgrind is a flexible program for debugging and profiling Linux
   executables. It consists of a core, which provides a synthetic CPU in
   software, and a series of debugging and profiling tools. The
   architecture is modular, so that new tools can be created easily and
   without disturbing the existing structure.

Re: [PATCH] RISC-V: Add rounding mode enum for fixed-point intrinsics

2023-05-16 Thread Kito Cheng via Gcc-patches

I would like to defer this until the PR has updated.

On Wed, May 17, 2023 at 9:52 AM  wrote:
>
> From: Juzhe-Zhong 
>
> Hi, since fixed-point with modeling rounding mode intrinsics are coming:
> https://github.com/riscv-non-isa/rvv-intrinsic-doc/pull/222
>
> I am adding vxrm rounding mode enum to user first before the API intrinsic.
>
> This patch is simple && obvious.
>
> Ok for trunk ?
>
> gcc/ChangeLog:
>
> * config/riscv/riscv-vector-builtins.cc (register_vxrm): New function.
> (DEF_RVV_VXRM_ENUM): New macro.
> (handle_pragma_vector): Add vxrm enum register.
> * config/riscv/riscv-vector-builtins.def (DEF_RVV_VXRM_ENUM): New 
> macro.
> (RNU): Ditto.
> (RNE): Ditto.
> (RDN): Ditto.
> (ROD): Ditto.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/riscv/rvv/base/vxrm-1.c: New test.
>
> ---
>  gcc/config/riscv/riscv-vector-builtins.cc | 16 ++
>  gcc/config/riscv/riscv-vector-builtins.def| 11 +++
>  .../gcc.target/riscv/rvv/base/vxrm-1.c| 29 +++
>  3 files changed, 56 insertions(+)
>  create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vxrm-1.c
>
> diff --git a/gcc/config/riscv/riscv-vector-builtins.cc 
> b/gcc/config/riscv/riscv-vector-builtins.cc
> index b7458aaace6..bcabf1ea1a6 100644
> --- a/gcc/config/riscv/riscv-vector-builtins.cc
> +++ b/gcc/config/riscv/riscv-vector-builtins.cc
> @@ -3740,6 +3740,19 @@ verify_type_context (location_t loc, type_context_kind 
> context, const_tree type,
>gcc_unreachable ();
>  }
>
> +/* Register the vxrm enum.  */
> +static void
> +register_vxrm ()
> +{
> +  auto_vec values;
> +#define DEF_RVV_VXRM_ENUM(NAME, VALUE)   
>\
> +  values.quick_push (string_int_pair ("VXRM_" #NAME, VALUE));
> +#include "riscv-vector-builtins.def"
> +#undef DEF_RVV_VXRM_ENUM
> +
> +  lang_hooks.types.simulate_enum_decl (input_location, "RVV_VXRM", );
> +}
> +
>  /* Implement #pragma riscv intrinsic vector.  */
>  void
>  handle_pragma_vector ()
> @@ -3755,6 +3768,9 @@ handle_pragma_vector ()
>for (unsigned int type_i = 0; type_i < NUM_VECTOR_TYPES; ++type_i)
>  register_vector_type ((enum vector_type_index) type_i);
>
> +  /* Define the enums.  */
> +  register_vxrm ();
> +
>/* Define the functions.  */
>function_table = new hash_table (1023);
>function_builder builder;
> diff --git a/gcc/config/riscv/riscv-vector-builtins.def 
> b/gcc/config/riscv/riscv-vector-builtins.def
> index 0a387fd1617..2a1a9dbc903 100644
> --- a/gcc/config/riscv/riscv-vector-builtins.def
> +++ b/gcc/config/riscv/riscv-vector-builtins.def
> @@ -83,6 +83,11 @@ along with GCC; see the file COPYING3.  If not see
>X64_VLMUL_EXT, TUPLE_SUBPART)
>  #endif
>
> +/* Define RVV_VXRM rounding mode enum for fixed-point intrinsics.  */
> +#ifndef DEF_RVV_VXRM_ENUM
> +#define DEF_RVV_VXRM_ENUM(NAME, VALUE)
> +#endif
> +
>  /* SEW/LMUL = 64:
> Only enable when TARGET_MIN_VLEN > 32.
> Machine mode = VNx1BImode when TARGET_MIN_VLEN < 128.
> @@ -643,6 +648,11 @@ DEF_RVV_BASE_TYPE (vlmul_ext_x64, get_vector_type 
> (type_idx))
>  DEF_RVV_BASE_TYPE (size_ptr, build_pointer_type (size_type_node))
>  DEF_RVV_BASE_TYPE (tuple_subpart, get_tuple_subpart_type (type_idx))
>
> +DEF_RVV_VXRM_ENUM (RNU, VXRM_RNU)
> +DEF_RVV_VXRM_ENUM (RNE, VXRM_RNE)
> +DEF_RVV_VXRM_ENUM (RDN, VXRM_RDN)
> +DEF_RVV_VXRM_ENUM (ROD, VXRM_ROD)
> +
>  #include "riscv-vector-type-indexer.gen.def"
>
>  #undef DEF_RVV_PRED_TYPE
> @@ -651,3 +661,4 @@ DEF_RVV_BASE_TYPE (tuple_subpart, get_tuple_subpart_type 
> (type_idx))
>  #undef DEF_RVV_TUPLE_TYPE
>  #undef DEF_RVV_BASE_TYPE
>  #undef DEF_RVV_TYPE_INDEX
> +#undef DEF_RVV_VXRM_ENUM
> diff --git a/gcc/testsuite/gcc.target/riscv/rvv/base/vxrm-1.c 
> b/gcc/testsuite/gcc.target/riscv/rvv/base/vxrm-1.c
> new file mode 100644
> index 000..0d364787ad0
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/riscv/rvv/base/vxrm-1.c
> @@ -0,0 +1,29 @@
> +/* { dg-do compile } */
> +/* { dg-options "-march=rv64gcv -mabi=lp64d -O3" } */
> +
> +#include "riscv_vector.h"
> +
> +size_t f0 ()
> +{
> +  return VXRM_RNU;
> +}
> +
> +size_t f1 ()
> +{
> +  return VXRM_RNE;
> +}
> +
> +size_t f2 ()
> +{
> +  return VXRM_RDN;
> +}
> +
> +size_t f3 ()
> +{
> +  return VXRM_ROD;
> +}
> +
> +/* { dg-final { scan-assembler-times {li\s+[a-x0-9]+,\s*0} 1} } */
> +/* { dg-final { scan-assembler-times {li\s+[a-x0-9]+,\s*1} 1} } */
> +/* { dg-final { scan-assembler-times {li\s+[a-x0-9]+,\s*2} 1} } */
> +/* { dg-final { scan-assembler-times {li\s+[a-x0-9]+,\s*3} 1} } */
> --
> 2.36.3
>

Re: RISC-V Test Errors and Failures

2023-05-16 Thread Palmer Dabbelt


On Tue, 16 May 2023 19:51:48 PDT (-0700), Patrick O'Neill wrote:


On 5/16/23 19:47, Palmer Dabbelt wrote:

On Tue, 16 May 2023 19:46:28 PDT (-0700), Vineet Gupta wrote:

On 5/16/23 19:21, Kito Cheng wrote:

Palmer:

For short-term, this should help your internal test:
https://github.com/riscv-collab/riscv-gnu-toolchain/pull/1233


That only helps if using bleeding edge toolchain scripts (which I
regularly do and so did Patrick).

Palmer has a fork of toolchain scripts and I'm assuming he hasn't caught
up to that point ;-)


I'm fine dropping the fork if the bugs have been fixed.  IIRC last
week we were still waiting for them to merge something?

The testsuite was broken last week, but was fixed by
https://github.com/riscv-collab/riscv-gnu-toolchain/pull/1247 which was
merged last Friday.

That might be the thing you were thinking about?


Probably, I'll go try and bump stuff and see if it works...

Thanks!

Re: RISC-V Test Errors and Failures

2023-05-16 Thread Patrick O'Neill




On 5/16/23 19:47, Palmer Dabbelt wrote:

On Tue, 16 May 2023 19:46:28 PDT (-0700), Vineet Gupta wrote:

On 5/16/23 19:21, Kito Cheng wrote:

Palmer:

For short-term, this should help your internal test:
https://github.com/riscv-collab/riscv-gnu-toolchain/pull/1233


That only helps if using bleeding edge toolchain scripts (which I
regularly do and so did Patrick).

Palmer has a fork of toolchain scripts and I'm assuming he hasn't caught
up to that point ;-)


I'm fine dropping the fork if the bugs have been fixed.  IIRC last 
week we were still waiting for them to merge something?
The testsuite was broken last week, but was fixed by 
https://github.com/riscv-collab/riscv-gnu-toolchain/pull/1247 which was 
merged last Friday.


That might be the thing you were thinking about?

Re: RISC-V Test Errors and Failures

2023-05-16 Thread Palmer Dabbelt


On Tue, 16 May 2023 19:46:28 PDT (-0700), Vineet Gupta wrote:

On 5/16/23 19:21, Kito Cheng wrote:

Palmer:

For short-term, this should help your internal test:
https://github.com/riscv-collab/riscv-gnu-toolchain/pull/1233


That only helps if using bleeding edge toolchain scripts (which I
regularly do and so did Patrick).

Palmer has a fork of toolchain scripts and I'm assuming he hasn't caught
up to that point ;-)


I'm fine dropping the fork if the bugs have been fixed.  IIRC last week 
we were still waiting for them to merge something?



-Vineet

Re: RISC-V Test Errors and Failures

2023-05-16 Thread Vineet Gupta


On 5/16/23 19:21, Kito Cheng wrote:

Palmer:

For short-term, this should help your internal test:
https://github.com/riscv-collab/riscv-gnu-toolchain/pull/1233


That only helps if using bleeding edge toolchain scripts (which I 
regularly do and so did Patrick).


Palmer has a fork of toolchain scripts and I'm assuming he hasn't caught 
up to that point ;-)


-Vineet

Re: RISC-V Test Errors and Failures

2023-05-16 Thread Palmer Dabbelt


On Tue, 16 May 2023 19:32:21 PDT (-0700), jeffreya...@gmail.com wrote:



On 5/16/23 20:05, Palmer Dabbelt wrote:

On Tue, 16 May 2023 19:00:12 PDT (-0700), Jeff Law wrote:



On 5/16/23 19:29, Palmer Dabbelt wrote:




I think the most pressing need is bleeding edge gcc regression
tracking.
  @Jeff is anything setup on sourceware and/or usable ? I thought they
do have existing bots for some arches to spin up build / run - perhaps
runs are native and not qemu.


IIRC Jeff said his builders were hanging right now.

Correct.  More precisely, the riscv64 builds hang.  Not sure if it's
stage2 or stage3 of the bootstrap.  Been happening for the last couple
weeks.  I suspect some codegen bug in the riscv port.  I'll have to
bisect it which will be quite painful.


Can anyone else do it?  If the only blocker for having an upstream
regression CI thing is just sorting out why it broke over the last few
weeks then I'm happy to try and trick someone around here into doing
some work...

Probably easiest for me unless someone else has a chroot environment
handy.  It's not hard to do the bisection, it just involves a lot of
waiting.


By "chroot environment" you mean something like a 
debootstrap-into-chroot with qemu-user/binfmt-misc?  I don't have that 
setup right now, but it wouldn't be a big lift.



I've just about got the my problem from earlier today under control,
then I can probably start bisection.


That's fine with me, I have plenty of other stuff to do ;)

Re: RISC-V Test Errors and Failures

2023-05-16 Thread Jeff Law via Gcc-patches





On 5/16/23 20:05, Palmer Dabbelt wrote:

On Tue, 16 May 2023 19:00:12 PDT (-0700), Jeff Law wrote:



On 5/16/23 19:29, Palmer Dabbelt wrote:



I think the most pressing need is bleeding edge gcc regression 
tracking.

  @Jeff is anything setup on sourceware and/or usable ? I thought they
do have existing bots for some arches to spin up build / run - perhaps
runs are native and not qemu.


IIRC Jeff said his builders were hanging right now.

Correct.  More precisely, the riscv64 builds hang.  Not sure if it's
stage2 or stage3 of the bootstrap.  Been happening for the last couple
weeks.  I suspect some codegen bug in the riscv port.  I'll have to
bisect it which will be quite painful.


Can anyone else do it?  If the only blocker for having an upstream 
regression CI thing is just sorting out why it broke over the last few 
weeks then I'm happy to try and trick someone around here into doing 
some work...
Probably easiest for me unless someone else has a chroot environment 
handy.  It's not hard to do the bisection, it just involves a lot of 
waiting.


I've just about got the my problem from earlier today under control, 
then I can probably start bisection.


Jeff

Re: Re: RISC-V Test Errors and Failures

2023-05-16 Thread Kito Cheng via Gcc-patches

Palmer:

For short-term, this should help your internal test:
https://github.com/riscv-collab/riscv-gnu-toolchain/pull/1233

On Wed, May 17, 2023 at 10:20 AM Kito Cheng  wrote:
>
> Currently we are highly rely on simulator can setup correctly by ELF
> attribute or -march setting, but seems not true for everyone, for
> longer term we need something like
> check_effective_target_aarch64_sve_hw, but as Palmer point out, we
> might need...bunch of that for different extensions
>
> On Wed, May 17, 2023 at 10:13 AM Palmer Dabbelt  wrote:
> >
> > On Tue, 16 May 2023 19:07:01 PDT (-0700), juzhe.zh...@rivai.ai wrote:
> > > Oh, I see. Kito has add /* { dg-do run { target { riscv_vector } } } */
> > > But not all RVV tests has use this and I not sure whether it can work.
> > > I think Kito can answer it.
> > > If yes, I think we should add all of them.
> >
> > Unless I'm missing something, it looks like that only checks if GCC is
> > compiling for V.  Nothing appears to be checking if the system the tests
> > are running on supports V.
> >
> > # Return 1 if the target has RISC-V vector extension, 0 otherwise.
> > # Cache the result.
> >
> > proc check_effective_target_riscv_vector { } {
> > # Check that we are compiling for v by checking the __riscv_v marco.
> > return [check_no_compiler_messages riscv_vector assembly {
> >#if !defined(__riscv_v)
> >#error "__riscv_v not defined!"
> >#endif
> > }]
> > }
> >
> > Those are really just two different things.
> >
> > It seems pretty reasonably to me to just avoid running the tests when
> > the DUT lacks V, but I'm never great with DG.  We should probably add
> > similar checks for the other ISA extensions, there's going to be a bunch
> > of this.
> >
> > >
> > > Thanks.
> > >
> > >
> > > juzhe.zh...@rivai.ai
> > >
> > > From: Andrew Pinski
> > > Date: 2023-05-17 10:02
> > > To: juzhe.zh...@rivai.ai
> > > CC: gcc-patches; palmer; Kito.cheng
> > > Subject: Re: RISC-V Test Errors and Failures
> > > On Tue, May 16, 2023 at 6:58 PM juzhe.zh...@rivai.ai
> > >  wrote:
> > >>
> > >> Hi, Palmer.
> > >> I saw your patch showed there are a lot of run time fail (execution 
> > >> fail) of C++.
> > >> bug-*.C
> > >>
> > >> These tests are RVV api intrinsics tests coming from Kito's that I have 
> > >> already fixed all of them.
> > >> I just double checked again they all passed.
> > >> I think it may be your regression environment does not set up simulator 
> > >> (QEMU or SPIKE or GEM5) correctly.
> > >> For example, did not enable vector extension in simulator, I don't you 
> > >> may try.
> > >
> > > So on x86_64, we test to see if you have the right vector unit before
> > > running those tests? The same thing was true on powerpc (and I think
> > > aarch64 does the same for SVE now too). The reason why I am asking is
> > > that I would need to run the testsuite using the simulator as setup
> > > for the RISCV ISA I am using rather than the one with everything on.
> > > So does the RVV runtime testsuite tests to see if you can run RVV
> > > before running them (or running them and return they passed)?
> > >
> > > Thanks,
> > > Andrew Pinski
> > >
> > >>
> > >> Thanks.
> > >>
> > >>
> > >> juzhe.zh...@rivai.ai
> > >

Re: Re: RISC-V Test Errors and Failures

2023-05-16 Thread Kito Cheng via Gcc-patches

Currently we are highly rely on simulator can setup correctly by ELF
attribute or -march setting, but seems not true for everyone, for
longer term we need something like
check_effective_target_aarch64_sve_hw, but as Palmer point out, we
might need...bunch of that for different extensions

On Wed, May 17, 2023 at 10:13 AM Palmer Dabbelt  wrote:
>
> On Tue, 16 May 2023 19:07:01 PDT (-0700), juzhe.zh...@rivai.ai wrote:
> > Oh, I see. Kito has add /* { dg-do run { target { riscv_vector } } } */
> > But not all RVV tests has use this and I not sure whether it can work.
> > I think Kito can answer it.
> > If yes, I think we should add all of them.
>
> Unless I'm missing something, it looks like that only checks if GCC is
> compiling for V.  Nothing appears to be checking if the system the tests
> are running on supports V.
>
> # Return 1 if the target has RISC-V vector extension, 0 otherwise.
> # Cache the result.
>
> proc check_effective_target_riscv_vector { } {
> # Check that we are compiling for v by checking the __riscv_v marco.
> return [check_no_compiler_messages riscv_vector assembly {
>#if !defined(__riscv_v)
>#error "__riscv_v not defined!"
>#endif
> }]
> }
>
> Those are really just two different things.
>
> It seems pretty reasonably to me to just avoid running the tests when
> the DUT lacks V, but I'm never great with DG.  We should probably add
> similar checks for the other ISA extensions, there's going to be a bunch
> of this.
>
> >
> > Thanks.
> >
> >
> > juzhe.zh...@rivai.ai
> >
> > From: Andrew Pinski
> > Date: 2023-05-17 10:02
> > To: juzhe.zh...@rivai.ai
> > CC: gcc-patches; palmer; Kito.cheng
> > Subject: Re: RISC-V Test Errors and Failures
> > On Tue, May 16, 2023 at 6:58 PM juzhe.zh...@rivai.ai
> >  wrote:
> >>
> >> Hi, Palmer.
> >> I saw your patch showed there are a lot of run time fail (execution fail) 
> >> of C++.
> >> bug-*.C
> >>
> >> These tests are RVV api intrinsics tests coming from Kito's that I have 
> >> already fixed all of them.
> >> I just double checked again they all passed.
> >> I think it may be your regression environment does not set up simulator 
> >> (QEMU or SPIKE or GEM5) correctly.
> >> For example, did not enable vector extension in simulator, I don't you may 
> >> try.
> >
> > So on x86_64, we test to see if you have the right vector unit before
> > running those tests? The same thing was true on powerpc (and I think
> > aarch64 does the same for SVE now too). The reason why I am asking is
> > that I would need to run the testsuite using the simulator as setup
> > for the RISCV ISA I am using rather than the one with everything on.
> > So does the RVV runtime testsuite tests to see if you can run RVV
> > before running them (or running them and return they passed)?
> >
> > Thanks,
> > Andrew Pinski
> >
> >>
> >> Thanks.
> >>
> >>
> >> juzhe.zh...@rivai.ai
> >

Re: [PATCH V4 2/2] rs6000: use li;x?oris to build constant

2023-05-16 Thread guojiufu via Gcc-patches


Hi,

On 2023-05-15 14:53, Kewen.Lin wrote:

Hi Jeff,

on 2022/12/12 09:38, Jiufu Guo wrote:

Hi,

For constant C:
If '(c & 0xULL) == 0x' or say:
32(1) || 1(0) || 15(x) || 16(0), we could use "lis; xoris" to build.

Here N(M) means N continuous bit M, x for M means it is ok for either
1 or 0; '||' means concatenation.

This patch update rs6000_emit_set_long_const to support those 
constants.


Compare with previous version:
https://gcc.gnu.org/pipermail/gcc-patches/2022-December/607618.htm
This patch fix conflicts with trunk.

Bootstrap and regtest pass on ppc64{,le}.

Is this ok for trunk?


OK for trunk, thanks for improving this.

btw, the test case needs to be updated a bit as the function names in 
the
context changed upstream, please ensure it's tested well before 
committing,

thanks!


Yeap! Retested and verified.
Thanks so much for your always insight review and helpful comments!

Committed via r14-923-g5eb7d560626e42.

BR,
Jeff (Jiufu)





BR,
Jeff (Jiufu)


PR target/106708

gcc/ChangeLog:

* config/rs6000/rs6000.cc (rs6000_emit_set_long_const): Add to build
constants through "lis; xoris".


Maybe s/Add to build/Support building/

Yes :)



BR,
Kewen



gcc/testsuite/ChangeLog:

* gcc.target/powerpc/pr106708.c: Add test function.

---
 gcc/config/rs6000/rs6000.cc |  7 +++
 gcc/testsuite/gcc.target/powerpc/pr106708.c | 10 +-
 2 files changed, 16 insertions(+), 1 deletion(-)

diff --git a/gcc/config/rs6000/rs6000.cc b/gcc/config/rs6000/rs6000.cc
index 8c1192a10c8..1138d5e8cd4 100644
--- a/gcc/config/rs6000/rs6000.cc
+++ b/gcc/config/rs6000/rs6000.cc
@@ -10251,6 +10251,13 @@ rs6000_emit_set_long_const (rtx dest, 
HOST_WIDE_INT c)

   if (ud1 != 0)
emit_move_insn (dest, gen_rtx_IOR (DImode, temp, GEN_INT (ud1)));
 }
+  else if (ud4 == 0x && ud3 == 0x && !(ud2 & 0x8000) && ud1 
== 0)

+{
+  /* lis; xoris */
+  temp = !can_create_pseudo_p () ? dest : gen_reg_rtx (DImode);
+  emit_move_insn (temp, GEN_INT (sext_hwi ((ud2 | 0x8000) << 16, 
32)));
+  emit_move_insn (dest, gen_rtx_XOR (DImode, temp, GEN_INT 
(0x8000)));

+}
   else if (ud4 == 0x && ud3 == 0x && (ud1 & 0x8000))
 {
   /* li; xoris */
diff --git a/gcc/testsuite/gcc.target/powerpc/pr106708.c 
b/gcc/testsuite/gcc.target/powerpc/pr106708.c

index dc9ceda8367..a015c71e630 100644
--- a/gcc/testsuite/gcc.target/powerpc/pr106708.c
+++ b/gcc/testsuite/gcc.target/powerpc/pr106708.c
@@ -4,7 +4,7 @@
 /* { dg-require-effective-target has_arch_ppc64 } */

 long long arr[]
-  = {0x7cdeab55LL, 0x98765432LL, 0xabcdLL};
+= {0x7cdeab55LL, 0x98765432LL, 0xabcdLL, 
0x6543LL};


 void __attribute__ ((__noipa__)) lixoris (long long *arg)
 {
@@ -27,6 +27,13 @@ void __attribute__ ((__noipa__)) lisrldicl (long 
long *arg)

 /* { dg-final { scan-assembler-times {\mlis .*,0xabcd\M} 1 } } */
 /* { dg-final { scan-assembler-times {\mrldicl .*,0,32\M} 1 } } */

+void __attribute__ ((__noipa__)) lisxoris (long long *arg)
+{
+  *arg = 0x6543LL;
+}
+/* { dg-final { scan-assembler-times {\mlis .*,0xe543\M} 1 } } */
+/* { dg-final { scan-assembler-times {\mxoris .*0x8000\M} 1 } } */
+
 int
 main ()
 {
@@ -35,6 +42,7 @@ main ()
   lixoris (a);
   lioris (a + 1);
   lisrldicl (a + 2);
+  lisxoris (a + 3);
   if (__builtin_memcmp (a, arr, sizeof (arr)) != 0)
 __builtin_abort ();
   return 0;

Re: Re: RISC-V Test Errors and Failures

2023-05-16 Thread Palmer Dabbelt


On Tue, 16 May 2023 19:07:01 PDT (-0700), juzhe.zh...@rivai.ai wrote:

Oh, I see. Kito has add /* { dg-do run { target { riscv_vector } } } */
But not all RVV tests has use this and I not sure whether it can work.
I think Kito can answer it.
If yes, I think we should add all of them.


Unless I'm missing something, it looks like that only checks if GCC is 
compiling for V.  Nothing appears to be checking if the system the tests 
are running on supports V.


   # Return 1 if the target has RISC-V vector extension, 0 otherwise.
   # Cache the result.
   
   proc check_effective_target_riscv_vector { } {

   # Check that we are compiling for v by checking the __riscv_v marco.
   return [check_no_compiler_messages riscv_vector assembly {
  #if !defined(__riscv_v)
  #error "__riscv_v not defined!"
  #endif
   }]
   }

Those are really just two different things.

It seems pretty reasonably to me to just avoid running the tests when 
the DUT lacks V, but I'm never great with DG.  We should probably add 
similar checks for the other ISA extensions, there's going to be a bunch 
of this.




Thanks.


juzhe.zh...@rivai.ai
 
From: Andrew Pinski

Date: 2023-05-17 10:02
To: juzhe.zh...@rivai.ai
CC: gcc-patches; palmer; Kito.cheng
Subject: Re: RISC-V Test Errors and Failures
On Tue, May 16, 2023 at 6:58 PM juzhe.zh...@rivai.ai
 wrote:


Hi, Palmer.
I saw your patch showed there are a lot of run time fail (execution fail) of 
C++.
bug-*.C

These tests are RVV api intrinsics tests coming from Kito's that I have already 
fixed all of them.
I just double checked again they all passed.
I think it may be your regression environment does not set up simulator (QEMU 
or SPIKE or GEM5) correctly.
For example, did not enable vector extension in simulator, I don't you may try.
 
So on x86_64, we test to see if you have the right vector unit before

running those tests? The same thing was true on powerpc (and I think
aarch64 does the same for SVE now too). The reason why I am asking is
that I would need to run the testsuite using the simulator as setup
for the RISCV ISA I am using rather than the one with everything on.
So does the RVV runtime testsuite tests to see if you can run RVV
before running them (or running them and return they passed)?
 
Thanks,

Andrew Pinski
 


Thanks.


juzhe.zh...@rivai.ai

[Bug target/106708] [rs6000] 64bit constant generation with oris xoris

2023-05-16 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Jiu Fu Guo :

https://gcc.gnu.org/g:5eb7d560626e427673c53723ed430c4bb5721f33

commit r14-923-g5eb7d560626e427673c53723ed430c4bb5721f33
Author: Jiufu Guo 
Date:   Sat Dec 10 21:18:51 2022 +0800

rs6000: use lis;xoris to build constant

For constant C:
If '(c & 0xULL) == 0x' or say:
32(1) || 1(0) || 15(x) || 16(0), we could use "lis; xoris" to build.

Here N(M) means N continuous bit M, x for M means it is ok for either
1 or 0; '||' means concatenation.

This patch update rs6000_emit_set_long_const to support those constants.

Compare with previous version:
https://gcc.gnu.org/pipermail/gcc-patches/2022-December/608292.html
This patch updates test function names only.

Bootstrap and regtest pass on ppc64{,le}.

PR target/106708

gcc/ChangeLog:

* config/rs6000/rs6000.cc (rs6000_emit_set_long_const): Support
building
constants through "lis; xoris".

gcc/testsuite/ChangeLog:

* gcc.target/powerpc/pr106708.c: Add test function.

Re: RISC-V Test Errors and Failures

2023-05-16 Thread Jeff Law





On 5/16/23 20:08, Vineet Gupta wrote:




I think the most pressing need is bleeding edge gcc regression tracking.
  @Jeff is anything setup on sourceware and/or usable ? I thought they
do have existing bots for some arches to spin up build / run - perhaps
runs are native and not qemu.


IIRC Jeff said his builders were hanging right now.


Jeff it seems has his own test infra. I was ask
Mine is the closest we've got for project-wide testing.  Various orgs 
have their own servers/bots.


jeff

Re: RISC-V Test Errors and Failures

2023-05-16 Thread Vineet Gupta





On 5/16/23 18:29, Palmer Dabbelt wrote:

On Tue, 16 May 2023 18:04:37 PDT (-0700), Vineet Gupta wrote:

+ Christoph, Jiawei

On 5/16/23 17:20, Palmer Dabbelt wrote:

We really need to add some CI around RV toolchains to trip on these
sooner !


Sounds like you're volunteering to set one up?


Patrick's github CI patch seems to be a great start. Lets wait for it to
get merged, that will at least catch rv toolchain snafus: although the
granularity of testing is not ideal (tc changes are not so frequent)


You mean riscv-gnu-toolchain changes?  That's not super useful for GCC 
development, they're on a fork.


Well they are still useful to catch various snafus in toolchain plumbing 
itself - I've run into 2 of those and Patcrick 2 himself, when trying to 
use latest upstream toolchain scripts. But sure they are not testing 
bleeding edge gcc.






I think the most pressing need is bleeding edge gcc regression tracking.
  @Jeff is anything setup on sourceware and/or usable ? I thought they
do have existing bots for some arches to spin up build / run - perhaps
runs are native and not qemu.


IIRC Jeff said his builders were hanging right now.


Jeff it seems has his own test infra. I was asking if sourceware (or 
whatever the custodian of gcc project has).
I'd be really surprised if primary arches such as x86/aarch64 don't have 
any test bots there ?





FWIW rivos gitlab CI (not public) has capability to track upstream gcc
(Kevin almost has it working), but there is no easy way to publish it
for rest of the world and I'd rather that be done in a public infra.


+Kevin

At least having the failure lists public would be a must-have, and I 
think that's tricky to do with gitlab.


Yep.

Bjorn and Conor have something glued to the kernel patchwork that 
uploads test results to github as snippits, but IIRC we're trying to 
replace it with something more directly visible.



Didn't ISCAS/PLCT have such infra - sorry Kito asked the same question
this morning, but I was not fully awoke so don't remember what Jiawei
replied.


I didn't even remember he asked ;)

Re: Re: RISC-V Test Errors and Failures

2023-05-16 Thread juzhe.zh...@rivai.ai

Oh, I see. Kito has add /* { dg-do run { target { riscv_vector } } } */
But not all RVV tests has use this and I not sure whether it can work.
I think Kito can answer it.
If yes, I think we should add all of them.

Thanks.

juzhe.zh...@rivai.ai

From: Andrew Pinski
Date: 2023-05-17 10:02
To: juzhe.zh...@rivai.ai
CC: gcc-patches; palmer; Kito.cheng
Subject: Re: RISC-V Test Errors and Failures
On Tue, May 16, 2023 at 6:58 PM juzhe.zh...@rivai.ai
 wrote:
>
> Hi, Palmer.
> I saw your patch showed there are a lot of run time fail (execution fail) of 
> C++.
> bug-*.C
>
> These tests are RVV api intrinsics tests coming from Kito's that I have 
> already fixed all of them.
> I just double checked again they all passed.
> I think it may be your regression environment does not set up simulator (QEMU 
> or SPIKE or GEM5) correctly.
> For example, did not enable vector extension in simulator, I don't you may 
> try.

So on x86_64, we test to see if you have the right vector unit before
running those tests? The same thing was true on powerpc (and I think
aarch64 does the same for SVE now too). The reason why I am asking is
that I would need to run the testsuite using the simulator as setup
for the RISCV ISA I am using rather than the one with everything on.
So does the RVV runtime testsuite tests to see if you can run RVV
before running them (or running them and return they passed)?

Thanks,
Andrew Pinski

>
> Thanks.
>
>
> juzhe.zh...@rivai.ai

Re: RISC-V Test Errors and Failures

2023-05-16 Thread Palmer Dabbelt


On Tue, 16 May 2023 19:00:12 PDT (-0700), Jeff Law wrote:



On 5/16/23 19:29, Palmer Dabbelt wrote:




I think the most pressing need is bleeding edge gcc regression tracking.
  @Jeff is anything setup on sourceware and/or usable ? I thought they
do have existing bots for some arches to spin up build / run - perhaps
runs are native and not qemu.


IIRC Jeff said his builders were hanging right now.

Correct.  More precisely, the riscv64 builds hang.  Not sure if it's
stage2 or stage3 of the bootstrap.  Been happening for the last couple
weeks.  I suspect some codegen bug in the riscv port.  I'll have to
bisect it which will be quite painful.


Can anyone else do it?  If the only blocker for having an upstream 
regression CI thing is just sorting out why it broke over the last few 
weeks then I'm happy to try and trick someone around here into doing 
some work...

Re: RISC-V Test Errors and Failures

2023-05-16 Thread Andrew Pinski via Gcc-patches

On Tue, May 16, 2023 at 6:58 PM juzhe.zh...@rivai.ai
 wrote:
>
> Hi, Palmer.
> I saw your patch showed there are a lot of run time fail (execution fail) of 
> C++.
> bug-*.C
>
> These tests are RVV api intrinsics tests coming from Kito's that I have 
> already fixed all of them.
> I just double checked again they all passed.
> I think it may be your regression environment does not set up simulator (QEMU 
> or SPIKE or GEM5) correctly.
> For example, did not enable vector extension in simulator, I don't you may 
> try.

So on x86_64, we test to see if you have the right vector unit before
running those tests? The same thing was true on powerpc (and I think
aarch64 does the same for SVE now too). The reason why I am asking is
that I would need to run the testsuite using the simulator as setup
for the RISCV ISA I am using rather than the one with everything on.
So does the RVV runtime testsuite tests to see if you can run RVV
before running them (or running them and return they passed)?

Thanks,
Andrew Pinski

>
> Thanks.
>
>
> juzhe.zh...@rivai.ai

Re: RISC-V Test Errors and Failures

2023-05-16 Thread Jeff Law





On 5/16/23 19:29, Palmer Dabbelt wrote:




I think the most pressing need is bleeding edge gcc regression tracking.
  @Jeff is anything setup on sourceware and/or usable ? I thought they
do have existing bots for some arches to spin up build / run - perhaps
runs are native and not qemu.


IIRC Jeff said his builders were hanging right now.
Correct.  More precisely, the riscv64 builds hang.  Not sure if it's 
stage2 or stage3 of the bootstrap.  Been happening for the last couple 
weeks.  I suspect some codegen bug in the riscv port.  I'll have to 
bisect it which will be quite painful.


jeff

RISC-V Test Errors and Failures

2023-05-16 Thread juzhe.zh...@rivai.ai

Hi, Palmer.
I saw your patch showed there are a lot of run time fail (execution fail) of 
C++.
bug-*.C

These tests are RVV api intrinsics tests coming from Kito's that I have already 
fixed all of them.
I just double checked again they all passed.
I think it may be your regression environment does not set up simulator (QEMU 
or SPIKE or GEM5) correctly.
For example, did not enable vector extension in simulator, I don't you may try.

Thanks.


juzhe.zh...@rivai.ai

[PATCH] RISC-V: Add rounding mode enum for fixed-point intrinsics

2023-05-16 Thread juzhe . zhong

From: Juzhe-Zhong 

Hi, since fixed-point with modeling rounding mode intrinsics are coming:
https://github.com/riscv-non-isa/rvv-intrinsic-doc/pull/222

I am adding vxrm rounding mode enum to user first before the API intrinsic.

This patch is simple && obvious.

Ok for trunk ?

gcc/ChangeLog:

* config/riscv/riscv-vector-builtins.cc (register_vxrm): New function.
(DEF_RVV_VXRM_ENUM): New macro.
(handle_pragma_vector): Add vxrm enum register.
* config/riscv/riscv-vector-builtins.def (DEF_RVV_VXRM_ENUM): New macro.
(RNU): Ditto.
(RNE): Ditto.
(RDN): Ditto.
(ROD): Ditto.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/base/vxrm-1.c: New test.

---
 gcc/config/riscv/riscv-vector-builtins.cc | 16 ++
 gcc/config/riscv/riscv-vector-builtins.def| 11 +++
 .../gcc.target/riscv/rvv/base/vxrm-1.c| 29 +++
 3 files changed, 56 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vxrm-1.c

diff --git a/gcc/config/riscv/riscv-vector-builtins.cc 
b/gcc/config/riscv/riscv-vector-builtins.cc
index b7458aaace6..bcabf1ea1a6 100644
--- a/gcc/config/riscv/riscv-vector-builtins.cc
+++ b/gcc/config/riscv/riscv-vector-builtins.cc
@@ -3740,6 +3740,19 @@ verify_type_context (location_t loc, type_context_kind 
context, const_tree type,
   gcc_unreachable ();
 }
 
+/* Register the vxrm enum.  */
+static void
+register_vxrm ()
+{
+  auto_vec values;
+#define DEF_RVV_VXRM_ENUM(NAME, VALUE) 
 \
+  values.quick_push (string_int_pair ("VXRM_" #NAME, VALUE));
+#include "riscv-vector-builtins.def"
+#undef DEF_RVV_VXRM_ENUM
+
+  lang_hooks.types.simulate_enum_decl (input_location, "RVV_VXRM", );
+}
+
 /* Implement #pragma riscv intrinsic vector.  */
 void
 handle_pragma_vector ()
@@ -3755,6 +3768,9 @@ handle_pragma_vector ()
   for (unsigned int type_i = 0; type_i < NUM_VECTOR_TYPES; ++type_i)
 register_vector_type ((enum vector_type_index) type_i);
 
+  /* Define the enums.  */
+  register_vxrm ();
+
   /* Define the functions.  */
   function_table = new hash_table (1023);
   function_builder builder;
diff --git a/gcc/config/riscv/riscv-vector-builtins.def 
b/gcc/config/riscv/riscv-vector-builtins.def
index 0a387fd1617..2a1a9dbc903 100644
--- a/gcc/config/riscv/riscv-vector-builtins.def
+++ b/gcc/config/riscv/riscv-vector-builtins.def
@@ -83,6 +83,11 @@ along with GCC; see the file COPYING3.  If not see
   X64_VLMUL_EXT, TUPLE_SUBPART)
 #endif
 
+/* Define RVV_VXRM rounding mode enum for fixed-point intrinsics.  */
+#ifndef DEF_RVV_VXRM_ENUM
+#define DEF_RVV_VXRM_ENUM(NAME, VALUE)
+#endif
+
 /* SEW/LMUL = 64:
Only enable when TARGET_MIN_VLEN > 32.
Machine mode = VNx1BImode when TARGET_MIN_VLEN < 128.
@@ -643,6 +648,11 @@ DEF_RVV_BASE_TYPE (vlmul_ext_x64, get_vector_type 
(type_idx))
 DEF_RVV_BASE_TYPE (size_ptr, build_pointer_type (size_type_node))
 DEF_RVV_BASE_TYPE (tuple_subpart, get_tuple_subpart_type (type_idx))
 
+DEF_RVV_VXRM_ENUM (RNU, VXRM_RNU)
+DEF_RVV_VXRM_ENUM (RNE, VXRM_RNE)
+DEF_RVV_VXRM_ENUM (RDN, VXRM_RDN)
+DEF_RVV_VXRM_ENUM (ROD, VXRM_ROD)
+
 #include "riscv-vector-type-indexer.gen.def"
 
 #undef DEF_RVV_PRED_TYPE
@@ -651,3 +661,4 @@ DEF_RVV_BASE_TYPE (tuple_subpart, get_tuple_subpart_type 
(type_idx))
 #undef DEF_RVV_TUPLE_TYPE
 #undef DEF_RVV_BASE_TYPE
 #undef DEF_RVV_TYPE_INDEX
+#undef DEF_RVV_VXRM_ENUM
diff --git a/gcc/testsuite/gcc.target/riscv/rvv/base/vxrm-1.c 
b/gcc/testsuite/gcc.target/riscv/rvv/base/vxrm-1.c
new file mode 100644
index 000..0d364787ad0
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/rvv/base/vxrm-1.c
@@ -0,0 +1,29 @@
+/* { dg-do compile } */
+/* { dg-options "-march=rv64gcv -mabi=lp64d -O3" } */
+
+#include "riscv_vector.h"
+
+size_t f0 ()
+{
+  return VXRM_RNU;
+}
+
+size_t f1 ()
+{
+  return VXRM_RNE;
+}
+
+size_t f2 ()
+{
+  return VXRM_RDN;
+}
+
+size_t f3 ()
+{
+  return VXRM_ROD;
+}
+
+/* { dg-final { scan-assembler-times {li\s+[a-x0-9]+,\s*0} 1} } */
+/* { dg-final { scan-assembler-times {li\s+[a-x0-9]+,\s*1} 1} } */
+/* { dg-final { scan-assembler-times {li\s+[a-x0-9]+,\s*2} 1} } */
+/* { dg-final { scan-assembler-times {li\s+[a-x0-9]+,\s*3} 1} } */
-- 
2.36.3

Re: RISC-V Test Errors and Failures

2023-05-16 Thread Palmer Dabbelt


On Tue, 16 May 2023 18:04:37 PDT (-0700), Vineet Gupta wrote:

+ Christoph, Jiawei

On 5/16/23 17:20, Palmer Dabbelt wrote:

We really need to add some CI around RV toolchains to trip on these
sooner !


Sounds like you're volunteering to set one up?


Patrick's github CI patch seems to be a great start. Lets wait for it to
get merged, that will at least catch rv toolchain snafus: although the
granularity of testing is not ideal (tc changes are not so frequent)


You mean riscv-gnu-toolchain changes?  That's not super useful for GCC 
development, they're on a fork.



I think the most pressing need is bleeding edge gcc regression tracking.
  @Jeff is anything setup on sourceware and/or usable ? I thought they
do have existing bots for some arches to spin up build / run - perhaps
runs are native and not qemu.


IIRC Jeff said his builders were hanging right now.


FWIW rivos gitlab CI (not public) has capability to track upstream gcc
(Kevin almost has it working), but there is no easy way to publish it
for rest of the world and I'd rather that be done in a public infra.


+Kevin

At least having the failure lists public would be a must-have, and I 
think that's tricky to do with gitlab.  Bjorn and Conor have something 
glued to the kernel patchwork that uploads test results to github as 
snippits, but IIRC we're trying to replace it with something more 
directly visible.



Didn't ISCAS/PLCT have such infra - sorry Kito asked the same question
this morning, but I was not fully awoke so don't remember what Jiawei
replied.


I didn't even remember he asked ;)

[Bug rtl-optimization/109858] [14 Regression] r14-172 caused some SPEC2017 bmk to degrade on Power

2023-05-16 Thread crazylht at gmail dot com via Gcc-bugs

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

--- Comment #8 from Hongtao.liu  ---
(In reply to Segher Boessenkool from comment #7)
> > The patch will still use GENERAL_REGS when hard_regno_mode_ok for mode and
> > GENERAL_REGS(which is the case in PR109610), hope it can also fix this
> > regression.
> 
> That sounds more reasonable.  But, why use any heuristics like this?  Can't
> you
> just look at the actual costs of using mem and regs?

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109610#c2

[Bug testsuite/109880] [14 regression] gcc.target/powerpc/fold-vec-extract-int.p8.c fails after r14-916-g9417b30499ce09

2023-05-16 Thread bergner at gcc dot gnu.org via Gcc-bugs

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

Peter Bergner  changed:

   What|Removed |Added

   Target Milestone|--- |14.0
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |aagarwa at gcc dot 
gnu.org
   Last reconfirmed||2023-05-17
 Status|UNCONFIRMED |ASSIGNED

--- Comment #1 from Peter Bergner  ---
Confirmed.  The difference I see is:

gcc.target/powerpc/fold-vec-extract-int.p8.c: \\mrldicl\\M found 5 times
FAIL: gcc.target/powerpc/fold-vec-extract-int.p8.c scan-assembler-times
\\mrldicl\\M 7

...which makes sense, since the rldicl is used as a zero extend, so it does
look like just an instruction count update is needed.

Ajit, can you please confirm the 2 missing rldicl were removed because of zero
extends?  Bill's build seems pretty normal, so did you not see this failure
during your testing?

[Bug fortran/109865] different results when routine moved inside the contains statement

2023-05-16 Thread Gary.White at ColoState dot edu via Gcc-bugs

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

--- Comment #14 from GARY.WHITE at ColoState dot edu  ---
Clarification on the last post.  I'm compiling everything with -O3, except
va09ad.f90.  If va09ad.f90 is compiled with -O3, you get the bug.  If
va09ad.f90 is compiled with -O0, the code produces correct answers. 

Since LAPACK is a common library, you should be able to duplicate the bug with
little difficulty by changing the makefile.

Re: RISC-V Test Errors and Failures

2023-05-16 Thread Vineet Gupta


+ Christoph, Jiawei

On 5/16/23 17:20, Palmer Dabbelt wrote:
We really need to add some CI around RV toolchains to trip on these 
sooner !


Sounds like you're volunteering to set one up? 


Patrick's github CI patch seems to be a great start. Lets wait for it to 
get merged, that will at least catch rv toolchain snafus: although the 
granularity of testing is not ideal (tc changes are not so frequent)


I think the most pressing need is bleeding edge gcc regression tracking.
 @Jeff is anything setup on sourceware and/or usable ? I thought they 
do have existing bots for some arches to spin up build / run - perhaps 
runs are native and not qemu.


FWIW rivos gitlab CI (not public) has capability to track upstream gcc 
(Kevin almost has it working), but there is no easy way to publish it 
for rest of the world and I'd rather that be done in a public infra.


Didn't ISCAS/PLCT have such infra - sorry Kito asked the same question 
this morning, but I was not fully awoke so don't remember what Jiawei 
replied.


Thx,
-Vineet

[Bug fortran/109865] different results when routine moved inside the contains statement

2023-05-16 Thread Gary.White at ColoState dot edu via Gcc-bugs

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

--- Comment #12 from GARY.WHITE at ColoState dot edu  ---
I just checked, and the bug occurs with the LAPACK routines instead of LinPack.
 So "make type=markLAPACK" will generate markLAPACK that will fail with -O3,
but work with -O0.

--- Comment #13 from GARY.WHITE at ColoState dot edu  ---
I just checked, and the bug occurs with the LAPACK routines instead of LinPack.
 So "make type=markLAPACK" will generate markLAPACK that will fail with -O3,
but work with -O0.

[Bug fortran/109865] different results when routine moved inside the contains statement

2023-05-16 Thread Gary.White at ColoState dot edu via Gcc-bugs

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

--- Comment #12 from GARY.WHITE at ColoState dot edu  ---
I just checked, and the bug occurs with the LAPACK routines instead of LinPack.
 So "make type=markLAPACK" will generate markLAPACK that will fail with -O3,
but work with -O0.

--- Comment #13 from GARY.WHITE at ColoState dot edu  ---
I just checked, and the bug occurs with the LAPACK routines instead of LinPack.
 So "make type=markLAPACK" will generate markLAPACK that will fail with -O3,
but work with -O0.

[PATCH] Fix PR 106900: array-bounds warning inside simplify_builtin_call

2023-05-16 Thread Andrew Pinski via Gcc-patches

The problem here is that VRP cannot figure out isize could not be 0
due to using integer_zerop. This patch removes the use of integer_zerop
and instead checks for 0 directly after converting the tree to
an unsigned HOST_WIDE_INT. This allows VRP to figure out isize is not 0
and `isize - 1` will always be >= 0.

This patch is just to avoid the warning that GCC could produce sometimes
and does not change any code generation or even VRP.

OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.

gcc/ChangeLog:

* tree-ssa-forwprop.cc (simplify_builtin_call): Check
against 0 instead of calling integer_zerop.
---
 gcc/tree-ssa-forwprop.cc | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/tree-ssa-forwprop.cc b/gcc/tree-ssa-forwprop.cc
index 06f19868ade..0326e6733e8 100644
--- a/gcc/tree-ssa-forwprop.cc
+++ b/gcc/tree-ssa-forwprop.cc
@@ -1231,14 +1231,14 @@ simplify_builtin_call (gimple_stmt_iterator *gsi_p, 
tree callee2)
  tree size = gimple_call_arg (stmt2, 2);
  /* Size must be a constant which is <= UNITS_PER_WORD and
 <= the string length.  */
- if (TREE_CODE (size) != INTEGER_CST || integer_zerop (size))
+ if (TREE_CODE (size) != INTEGER_CST)
break;
 
  if (!tree_fits_uhwi_p (size))
break;
 
  unsigned HOST_WIDE_INT sz = tree_to_uhwi (size);
- if (sz > UNITS_PER_WORD || sz >= slen)
+ if (sz == 0 || sz > UNITS_PER_WORD || sz >= slen)
break;
 
  tree ch = gimple_call_arg (stmt2, 1);
-- 
2.31.1

Re: RISC-V Test Errors and Failures

2023-05-16 Thread Palmer Dabbelt


On Tue, 16 May 2023 17:16:11 PDT (-0700), Vineet Gupta wrote:

On 5/16/23 16:06, Palmer Dabbelt wrote:

A few of us were talking about test-related issues in the patchwork
meeting
this morning.  I bumped to trunk and did a full rebuild, I'm getting the
following (it's in riscv-systems-ci/riscv-gnu-toolchain).  This is
about what I
remember seeing last time I ran the tests, which was a week or so ago.  I
figured it'd be best to just blast the lists, as Jeff said his test
running had
been hanging so there might be some issue preventing folks from seeing
the
failures.

I guess I didn't get time to look last time and I doubt things are
looking any
better right now.  I'll try and take a look at some point, but any
help would
of course be appreciated.


Yes I was seeing similar tcl errors and such - and in my case an even
higher count.
Also for posterity, what was your configure cmdline ? multilibs or no


If only I'd saved those in the build somewhere... :)

It's all in github.com/palmer-dabbelt/riscv-systems-ci, which points to 
riscv-gnu-toolchain.  I've always got uncommitted diff in my various 
local checkous, but I think this would only be


   toolchain: toolchain/install.stamp
   
   toolchain/install.stamp: toolchain/Makefile

   $(MAKE) -C $(dir $<)
   date > $@
   
   toolchain/Makefile: riscv-gnu-toolchain/configure

   mkdir -p $(dir $@)
   env -C $(dir $@) $(abspath $<) --prefix="$(abspath $(dir 
$@)/install)" --enable-linux --enable-multilib --enable-gcc-checking=yes
   
   toolchain/check.log: toolchain/install.stamp

   $(MAKE) -C $(dir $<) check \
   
GLIBC_TARGET_BOARDS_EXTRA="riscv-sim/-march=rv64gczba_zbb_zbc_zbs/-mabi=lp64d 
riscv-sim/-march=rv64imafdcv/-mabi=lp64d riscv-sim/-march=rv32imafdcv/-mabi=ilp32d" 
|& tee $@
   touch -c $@
   
   toolchain/report: toolchain/check.log

   $(MAKE) -C $(dir $<) report \
   
GLIBC_TARGET_BOARDS_EXTRA="riscv-sim/-march=rv64gczba_zbb_zbc_zbs/-mabi=lp64d 
riscv-sim/-march=rv64imafdcv/-mabi=lp64d riscv-sim/-march=rv32imafdcv/-mabi=ilp32d" 
|& tee $@
   touch -c $@


We really need to add some CI around RV toolchains to trip on these sooner !


Sounds like you're volunteering to set one up?


$ cat toolchain/report
make[1]: Entering directory '/scratch/merges/rgt-gcc-trunk/toolchain'
/scratch/merges/rgt-gcc-trunk/riscv-gnu-toolchain/scripts/testsuite-filter
gcc glibc
/scratch/merges/rgt-gcc-trunk/riscv-gnu-toolchain/test/allowlist `find
build-gcc-linux-stage2/gcc/testsuite/ -name *.sum |paste -sd "," -`
    === g++: Unexpected fails for rv64imac lp64 medlow ===
FAIL: g++.dg/contracts/contracts-tmpl-spec2.C   output pattern test
    === g++: Unexpected fails for rv32imac ilp32 medlow ===
FAIL: g++.dg/contracts/contracts-tmpl-spec2.C   output pattern test
FAIL: g++.dg/modules/xtreme-header-5_c.C -std=c++2a (test for excess
errors)
FAIL: g++.dg/modules/xtreme-header-5_c.C -std=c++2b (test for excess
errors)
    === g++: Unexpected fails for rv64imafdc lp64d medlow ===
FAIL: g++.dg/contracts/contracts-tmpl-spec2.C   output pattern test
    === g++: Unexpected fails for rv32imafdc ilp32d medlow ===
FAIL: g++.dg/contracts/contracts-tmpl-spec2.C   output pattern test
FAIL: g++.dg/modules/xtreme-header-5_c.C -std=c++2a (test for excess
errors)
FAIL: g++.dg/modules/xtreme-header-5_c.C -std=c++2b (test for excess
errors)
    === g++: Unexpected fails for rv64imafdcv lp64d  ===
FAIL: g++.dg/contracts/contracts-tmpl-spec2.C   output pattern test
FAIL: g++.target/riscv/rvv/base/bug-10.C execution test
FAIL: g++.target/riscv/rvv/base/bug-11.C execution test
FAIL: g++.target/riscv/rvv/base/bug-12.C execution test
FAIL: g++.target/riscv/rvv/base/bug-13.C execution test
FAIL: g++.target/riscv/rvv/base/bug-14.C execution test
FAIL: g++.target/riscv/rvv/base/bug-15.C execution test
FAIL: g++.target/riscv/rvv/base/bug-16.C execution test
FAIL: g++.target/riscv/rvv/base/bug-17.C execution test
FAIL: g++.target/riscv/rvv/base/bug-2.C execution test
FAIL: g++.target/riscv/rvv/base/bug-23.C execution test
FAIL: g++.target/riscv/rvv/base/bug-3.C execution test
FAIL: g++.target/riscv/rvv/base/bug-4.C execution test
FAIL: g++.target/riscv/rvv/base/bug-5.C execution test
FAIL: g++.target/riscv/rvv/base/bug-6.C execution test
FAIL: g++.target/riscv/rvv/base/bug-7.C execution test
FAIL: g++.target/riscv/rvv/base/bug-8.C execution test
FAIL: g++.target/riscv/rvv/base/bug-9.C execution test
    === g++: Unexpected fails for rv32imafdcv ilp32d  ===
FAIL: g++.dg/contracts/contracts-tmpl-spec2.C   output pattern test
FAIL: g++.dg/modules/xtreme-header-5_c.C -std=c++2a (test for excess
errors)
FAIL: g++.dg/modules/xtreme-header-5_c.C -std=c++2b (test for excess
errors)
FAIL: g++.target/riscv/rvv/base/bug-10.C execution test
FAIL: g++.target/riscv/rvv/base/bug-11.C execution test
FAIL: g++.target/riscv/rvv/base/bug-12.C execution test
FAIL:

Re: RISC-V Test Errors and Failures

2023-05-16 Thread Vineet Gupta


On 5/16/23 16:06, Palmer Dabbelt wrote:
A few of us were talking about test-related issues in the patchwork 
meeting

this morning.  I bumped to trunk and did a full rebuild, I'm getting the
following (it's in riscv-systems-ci/riscv-gnu-toolchain).  This is 
about what I

remember seeing last time I ran the tests, which was a week or so ago.  I
figured it'd be best to just blast the lists, as Jeff said his test 
running had
been hanging so there might be some issue preventing folks from seeing 
the

failures.

I guess I didn't get time to look last time and I doubt things are 
looking any
better right now.  I'll try and take a look at some point, but any 
help would

of course be appreciated.


Yes I was seeing similar tcl errors and such - and in my case an even 
higher count.

Also for posterity, what was your configure cmdline ? multilibs or no
We really need to add some CI around RV toolchains to trip on these sooner !



$ cat toolchain/report
make[1]: Entering directory '/scratch/merges/rgt-gcc-trunk/toolchain'
/scratch/merges/rgt-gcc-trunk/riscv-gnu-toolchain/scripts/testsuite-filter 
gcc glibc 
/scratch/merges/rgt-gcc-trunk/riscv-gnu-toolchain/test/allowlist `find 
build-gcc-linux-stage2/gcc/testsuite/ -name *.sum |paste -sd "," -`

    === g++: Unexpected fails for rv64imac lp64 medlow ===
FAIL: g++.dg/contracts/contracts-tmpl-spec2.C   output pattern test
    === g++: Unexpected fails for rv32imac ilp32 medlow ===
FAIL: g++.dg/contracts/contracts-tmpl-spec2.C   output pattern test
FAIL: g++.dg/modules/xtreme-header-5_c.C -std=c++2a (test for excess 
errors)
FAIL: g++.dg/modules/xtreme-header-5_c.C -std=c++2b (test for excess 
errors)

    === g++: Unexpected fails for rv64imafdc lp64d medlow ===
FAIL: g++.dg/contracts/contracts-tmpl-spec2.C   output pattern test
    === g++: Unexpected fails for rv32imafdc ilp32d medlow ===
FAIL: g++.dg/contracts/contracts-tmpl-spec2.C   output pattern test
FAIL: g++.dg/modules/xtreme-header-5_c.C -std=c++2a (test for excess 
errors)
FAIL: g++.dg/modules/xtreme-header-5_c.C -std=c++2b (test for excess 
errors)

    === g++: Unexpected fails for rv64imafdcv lp64d  ===
FAIL: g++.dg/contracts/contracts-tmpl-spec2.C   output pattern test
FAIL: g++.target/riscv/rvv/base/bug-10.C execution test
FAIL: g++.target/riscv/rvv/base/bug-11.C execution test
FAIL: g++.target/riscv/rvv/base/bug-12.C execution test
FAIL: g++.target/riscv/rvv/base/bug-13.C execution test
FAIL: g++.target/riscv/rvv/base/bug-14.C execution test
FAIL: g++.target/riscv/rvv/base/bug-15.C execution test
FAIL: g++.target/riscv/rvv/base/bug-16.C execution test
FAIL: g++.target/riscv/rvv/base/bug-17.C execution test
FAIL: g++.target/riscv/rvv/base/bug-2.C execution test
FAIL: g++.target/riscv/rvv/base/bug-23.C execution test
FAIL: g++.target/riscv/rvv/base/bug-3.C execution test
FAIL: g++.target/riscv/rvv/base/bug-4.C execution test
FAIL: g++.target/riscv/rvv/base/bug-5.C execution test
FAIL: g++.target/riscv/rvv/base/bug-6.C execution test
FAIL: g++.target/riscv/rvv/base/bug-7.C execution test
FAIL: g++.target/riscv/rvv/base/bug-8.C execution test
FAIL: g++.target/riscv/rvv/base/bug-9.C execution test
    === g++: Unexpected fails for rv32imafdcv ilp32d  ===
FAIL: g++.dg/contracts/contracts-tmpl-spec2.C   output pattern test
FAIL: g++.dg/modules/xtreme-header-5_c.C -std=c++2a (test for excess 
errors)
FAIL: g++.dg/modules/xtreme-header-5_c.C -std=c++2b (test for excess 
errors)

FAIL: g++.target/riscv/rvv/base/bug-10.C execution test
FAIL: g++.target/riscv/rvv/base/bug-11.C execution test
FAIL: g++.target/riscv/rvv/base/bug-12.C execution test
FAIL: g++.target/riscv/rvv/base/bug-13.C execution test
FAIL: g++.target/riscv/rvv/base/bug-14.C (test for excess errors)
FAIL: g++.target/riscv/rvv/base/bug-15.C execution test
FAIL: g++.target/riscv/rvv/base/bug-16.C execution test
FAIL: g++.target/riscv/rvv/base/bug-17.C execution test
FAIL: g++.target/riscv/rvv/base/bug-18.C (test for excess errors)
FAIL: g++.target/riscv/rvv/base/bug-19.C (test for excess errors)
FAIL: g++.target/riscv/rvv/base/bug-2.C execution test
FAIL: g++.target/riscv/rvv/base/bug-20.C (test for excess errors)
FAIL: g++.target/riscv/rvv/base/bug-21.C (test for excess errors)
FAIL: g++.target/riscv/rvv/base/bug-22.C (test for excess errors)
FAIL: g++.target/riscv/rvv/base/bug-23.C execution test
FAIL: g++.target/riscv/rvv/base/bug-3.C execution test
FAIL: g++.target/riscv/rvv/base/bug-4.C execution test
FAIL: g++.target/riscv/rvv/base/bug-5.C execution test
FAIL: g++.target/riscv/rvv/base/bug-6.C execution test
FAIL: g++.target/riscv/rvv/base/bug-7.C execution test
FAIL: g++.target/riscv/rvv/base/bug-8.C execution test
FAIL: g++.target/riscv/rvv/base/bug-9.C (test for excess errors)
    === g++: Unexpected fails for rv64gczba_zbb_zbc_zbs lp64d ===
FAIL: g++.dg/contracts/contracts-tmpl-spec2.C   output pattern test
    === gcc: Unexpected fails for rv64imac lp64 medlow ===
ERROR: tcl error sourcing

[Bug target/109812] GraphicsMagick resize is a lot slower in GCC 13.1 vs Clang 16

2023-05-16 Thread sjames at gcc dot gnu.org via Gcc-bugs

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

Sam James  changed:

   What|Removed |Added

 CC||sjames at gcc dot gnu.org

--- Comment #5 from Sam James  ---
All of the benchmarks in that report are from
https://github.com/phoronix-test-suite/phoronix-test-suite.

For GraphicsMagick, the relevant benchmark seems to be:
https://github.com/phoronix-test-suite/phoronix-test-suite/blob/dea5e68ba7bc0eaa3646713a8e07100ffab929b5/ob-cache/test-profiles/pts/graphics-magick-1.6.1/test-definition.xml
(it might be a different version of the test, but note that '1.6.1' does NOT
equal the graphicsmagick version)

with a script at
https://github.com/phoronix-test-suite/phoronix-test-suite/blob/dea5e68ba7bc0eaa3646713a8e07100ffab929b5/ob-cache/test-profiles/pts/graphics-magick-1.6.1/install.sh#L25.

I think it runs individual commands like this (OMP_NUM_THREADS="$NUM_CPU_CORES"
./gm benchmark -duration 60 convert DSC_6782.png $@ null), so:
* OMP_NUM_THREADS="$NUM_CPU_CORES" ./gm benchmark -duration 60 convert
DSC_6782.png -colorspace HWB null
* OMP_NUM_THREADS="$NUM_CPU_CORES" ./gm benchmark -duration 60 convert
DSC_6782.png -blur 0x1.0 null
* OMP_NUM_THREADS="$NUM_CPU_CORES" ./gm benchmark -duration 60 convert
DSC_6782.png -lat 10x10-5% null
* OMP_NUM_THREADS="$NUM_CPU_CORES" ./gm benchmark -duration 60 convert
DSC_6782.png -resize 50% HWB null
* OMP_NUM_THREADS="$NUM_CPU_CORES" ./gm benchmark -duration 60 convert
DSC_6782.png -sharpen 0x1.0 HWB null

with GraphicsMagick (gm) built as with -fopenmp -O3 -march=native -flto -ltiff
-lfreetype -ljpeg -lXext -lSM -lICE -lX11 -lbz2 -lz -lzstd -lpthread. But I
can't actually find the test image DSC_6782.png, so...

I think we really need more information here before it's actionable. Perhaps
the reporter could reach out to Michael Larabel and ask him to comment here.

[committed] c: Remove restrictions on declarations in 'for' loops for C2X

2023-05-16 Thread Joseph Myers

C2X removes a restriction that the only declarations in the
declaration part of a 'for' loop are declarations of objects with
storage class auto or register.  Implement this change, making the
diagnostics into pedwarn_c11 calls instead of errors (as usual for
features added in a new standard version that were invalid code in a
previous version), so now pedwarn-if-pedantic for older standards and
diagnosed also with -Wc11-c2x-compat.

Bootstrapped with no regressions for x86_64-pc-linux-gnu.

gcc/c/
* c-decl.cc (check_for_loop_decls): Use pedwarn_c11 for
diagnostics.

gcc/testsuite/
* gcc.dg/c11-fordecl-1.c, gcc.dg/c11-fordecl-2.c,
gcc.dg/c11-fordecl-3.c, gcc.dg/c11-fordecl-4.c,
gcc.dg/c2x-fordecl-1.c, gcc.dg/c2x-fordecl-2.c,
gcc.dg/c2x-fordecl-3.c, gcc.dg/c2x-fordecl-4.c: New tests.
* gcc.dg/c99-fordecl-2.c: Test diagnostic for typedef declaration
in for loop here.
* gcc.dg/pr67784-2.c, gcc.dg/pr68320.c, objc.dg/foreach-7.m: Do
not expect errors for typedef declaration in for loop.

diff --git a/gcc/c/c-decl.cc b/gcc/c/c-decl.cc
index 90d7cd27cd5..f8ede362bfd 100644
--- a/gcc/c/c-decl.cc
+++ b/gcc/c/c-decl.cc
@@ -11032,7 +11032,9 @@ check_for_loop_decls (location_t loc, bool 
turn_off_iso_c99_error)
  only applies to those that are.  (A question on this in comp.std.c
  in November 2000 received no answer.)  We implement the strictest
  interpretation, to avoid creating an extension which later causes
- problems.  */
+ problems.
+
+ This constraint was removed in C2X.  */
 
   for (b = current_scope->bindings; b; b = b->prev)
 {
@@ -11048,33 +11050,35 @@ check_for_loop_decls (location_t loc, bool 
turn_off_iso_c99_error)
  {
location_t decl_loc = DECL_SOURCE_LOCATION (decl);
if (TREE_STATIC (decl))
- error_at (decl_loc,
-   "declaration of static variable %qD in % loop "
-   "initial declaration", decl);
+ pedwarn_c11 (decl_loc, OPT_Wpedantic,
+  "declaration of static variable %qD in % "
+  "loop initial declaration", decl);
else if (DECL_EXTERNAL (decl))
- error_at (decl_loc,
-   "declaration of % variable %qD in % loop 
"
-   "initial declaration", decl);
+ pedwarn_c11 (decl_loc, OPT_Wpedantic,
+  "declaration of % variable %qD in % "
+  "loop initial declaration", decl);
  }
  break;
 
case RECORD_TYPE:
- error_at (loc,
-   "% declared in % loop initial "
-   "declaration", id);
+ pedwarn_c11 (loc, OPT_Wpedantic,
+  "% declared in % loop initial "
+  "declaration", id);
  break;
case UNION_TYPE:
- error_at (loc,
-   "% declared in % loop initial declaration",
-   id);
+ pedwarn_c11 (loc, OPT_Wpedantic,
+  "% declared in % loop initial "
+  "declaration",
+  id);
  break;
case ENUMERAL_TYPE:
- error_at (loc, "% declared in % loop "
-   "initial declaration", id);
+ pedwarn_c11 (loc, OPT_Wpedantic,
+  "% declared in % loop "
+  "initial declaration", id);
  break;
default:
- error_at (loc, "declaration of non-variable "
-   "%qD in % loop initial declaration", decl);
+ pedwarn_c11 (loc, OPT_Wpedantic, "declaration of non-variable "
+  "%qD in % loop initial declaration", decl);
}
 
   n_decls++;
diff --git a/gcc/testsuite/gcc.dg/c11-fordecl-1.c 
b/gcc/testsuite/gcc.dg/c11-fordecl-1.c
new file mode 100644
index 000..4aceb335e18
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/c11-fordecl-1.c
@@ -0,0 +1,27 @@
+/* Test for C99 declarations in for loops.  Test constraints are diagnosed for
+   C11.  Based on c99-fordecl-2.c.  */
+/* { dg-do compile } */
+/* { dg-options "-std=c11 -pedantic-errors" } */
+
+void
+foo (void)
+{
+  int j = 0;
+  for (int i = 1, bar (void); i <= 10; i++) /* { dg-error "bar" } */
+j += i;
+
+  for (static int i = 1; i <= 10; i++) /* /* { dg-error "static" } */
+j += i;
+
+  for (extern int i; j <= 500; j++) /* { dg-error "extern" } */
+j += 5;
+
+  for (enum { FOO } i = FOO; i < 10; i++) /* { dg-error "FOO" } */
+j += i;
+
+  for (enum BAR { FOO } i = FOO; i < 10; i++) /* { dg-error "FOO" } */
+/* { dg-error "BAR" "enum tag in for loop" { target *-*-* } .-1 } */
+j += i;
+  for (typedef int T;;) /* { dg-error "non-variable" } */
+;
+}
diff --git a/gcc/testsuite/gcc.dg/c11-fordecl-2.c 
b/gcc/testsuite/gcc.dg/c11-fordecl-2.c
new file mode 100644
index 000..0be1a0d13fa
--- /dev/null

[Bug rtl-optimization/4079] unnecessary register move on simple code

2023-05-16 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to work||8.1.0
   Target Milestone|--- |8.0
 Status|SUSPENDED   |RESOLVED
  Known to fail||4.8.5
 Resolution|--- |FIXED

--- Comment #10 from Andrew Pinski  ---
This has been fixed for a while. At least in GCC 8. Maybe even before.

[Bug sanitizer/109882] -fsanitize=thread #include transitively includes sanitizer/common_interface_defs.h

2023-05-16 Thread redi at gcc dot gnu.org via Gcc-bugs

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-05-16
 Ever confirmed|0   |1

--- Comment #4 from Jonathan Wakely  ---
The header is included since r13-2677-g0abc63a5ea4550 (and
r12-9342-g0cec4e9cd44e25 on the branch), and not including it would mean not
being able to annotate atomic>.

I agree with Andrew, this is a bug in libsanitizer. The correct way to use
__has_feature in a public header is to test with #ifdef __has_feature not to
define the fallback definition.

[Bug ada/109881] GNAT BUG DETECTED during RTL pass, raised TYPES.UNRECOVERABLE_ERROR

2023-05-16 Thread gnugcc at marino dot st via Gcc-bugs

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

--- Comment #2 from John Marino  ---
I found the problematic line.

I changed this line:
data_in := read_compressed_data (input_stream, planned, bytes_read);

to:
bytes_read := read_compressed_data (input_stream  => input_stream,
bytes_planned => planned,
data_in   => data_in);

and the read_compressed_data function was changed from:
   function read_compressed_data
 (input_stream  : not null SIO.Stream_Access;
  bytes_planned : Natural;
  bytes_read: out Natural) return data_in_type;

to:
   function read_compressed_data
 (input_stream  : not null SIO.Stream_Access;
  bytes_planned : Natural;
  data_in   : out data_in_type) return Natural;

The rearrangement of the function avoided the GNAT bug.

[Bug rtl-optimization/43616] Extra register move

2023-05-16 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |5.0
 Status|NEW |RESOLVED
 Resolution|--- |FIXED
  Known to work||5.1.0, 9.1.0

--- Comment #3 from Andrew Pinski  ---
The arm code generation was fixed in GCC 5 for the testcase in comment #0.
The x86_64 code generation was fixed in GCC 9 for the testcase in comment #2.

So fixed a long time ago for both.

[Bug sanitizer/109882] -fsanitize=thread #include transitively includes sanitizer/common_interface_defs.h

2023-05-16 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

--- Comment #3 from Andrew Pinski  ---
Then you should file this bug upstream with the sanitizer for the way
__has_feature is handled incorrectly.

[Bug sanitizer/109882] -fsanitize=thread #include transitively includes sanitizer/common_interface_defs.h

2023-05-16 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|libstdc++   |sanitizer
 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

--- Comment #2 from Andrew Pinski  ---
Anyways I am going to declare this a bug in the sanitizer headers rather than
libstdc++ headers.

[Bug libstdc++/109882] -fsanitize=thread #include transitively includes sanitizer/common_interface_defs.h

2023-05-16 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

--- Comment #1 from Andrew Pinski  ---
__has_feature is being added

[Bug modula2/109879] ReadCard and ReadInt from WholeIO have problems with leading space

2023-05-16 Thread gaius at gcc dot gnu.org via Gcc-bugs

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

Gaius Mulley  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #4 from Gaius Mulley  ---
Closing now that the patch has been applied.

[Bug tree-optimization/68086] Expression explicitly defined outside the loop is moved inside the loop by the optimizer

2023-05-16 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|rtl-optimization|tree-optimization

--- Comment #3 from Andrew Pinski  ---
So we start with:
   :
  _1 = (long unsigned int) i_13;
  _2 = _1 * 4;
  _3 = -_2;
  rebased_15 = data_14(D) + _3;
  goto ; [INV]

   :
  _4 = (long unsigned int) i_10;
  _5 = _4 * 4;
  _6 = rebased_15 + _5;
  _7 = *_6;

And then forwprop turns it into:
  _4 = (long unsigned intD.16) i_10;
  _5 = _4 * 4;
  _11 = _4 - _1;
  _21 = _11 * 4;
  _6 = data_14(D) + _21;
  # VUSE <.MEM_16(D)>
  _7 = *_6;

Except then IVOPT does not know how to handle this correctly.

[Bug modula2/109879] ReadCard and ReadInt from WholeIO have problems with leading space

2023-05-16 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Gaius Mulley :

https://gcc.gnu.org/g:509eef9314b24eff20a5dbdd92f6ab52e2c0c786

commit r14-920-g509eef9314b24eff20a5dbdd92f6ab52e2c0c786
Author: Gaius Mulley 
Date:   Wed May 17 00:18:56 2023 +0100

PR modula2/109879 WholeIO.ReadCard and ReadInt should consume leading space

The Read{TYPE} procedures in LongIO, LongWholeIO, RealIO, ShortWholeIO and
WholeIO all require skip space functionality.  A new module TextUtil
is supplied with this functionality and the previous modules have been
changed to call SkipSpaces.

gcc/m2/ChangeLog:

PR modula2/109879
* gm2-libs-iso/LongIO.mod (ReadReal): Call SkipSpaces.
* gm2-libs-iso/LongWholeIO.mod (ReadInt): Call SkipSpaces.
(ReadCard): Call SkipSpaces.
* gm2-libs-iso/RealIO.mod (ReadReal): Call SkipSpaces.
* gm2-libs-iso/ShortWholeIO.mod: (ReadInt): Call SkipSpaces.
(ReadCard): Call SkipSpaces.
* gm2-libs-iso/TextIO.mod: Import SkipSpaces.
* gm2-libs-iso/WholeIO.mod (ReadInt): Call SkipSpaces.
(ReadCard): Call SkipSpaces.
* gm2-libs-iso/TextUtil.def: New file.
* gm2-libs-iso/TextUtil.mod: New file.

libgm2/ChangeLog:

PR modula2/109879
* Makefile.in: Regenerate.
* aclocal.m4: Regenerate.
* libm2cor/Makefile.in: Regenerate.
* libm2iso/Makefile.am (M2DEFS): Add TextUtil.def.
(M2MODS): Add TextUtil.mod.
* libm2iso/Makefile.in: Regenerate.
* libm2log/Makefile.in: Regenerate.
* libm2min/Makefile.in: Regenerate.
* libm2pim/Makefile.in: Regenerate.

gcc/testsuite/ChangeLog:

PR modula2/109879
* gm2/isolib/run/pass/testreadint.mod: New test.

Signed-off-by: Gaius Mulley

[Bug libstdc++/109882] New: -fsanitize=thread #include transitively includes sanitizer/common_interface_defs.h

2023-05-16 Thread ed at catmur dot uk via Gcc-bugs

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

Bug ID: 109882
   Summary: -fsanitize=thread #include  transitively
includes sanitizer/common_interface_defs.h
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ed at catmur dot uk
  Target Milestone: ---

Since 12.3.0, when compiled under tsan (-fsanitize=thread), #include 
transitively includes sanitizer/common_interface_defs.h:

#include 
#if defined SANITIZER_COMMON_INTERFACE_DEFS_H
#error :(
#endif

This is problematic for us because sanitizer/common_interface_defs.h has
#define __has_feature(x) 0
https://github.com/gcc-mirror/gcc/blame/5d85b5d649fff675ff00adcc99371bccf4ef5944/libsanitizer/include/sanitizer/common_interface_defs.h#L20

which makes our sanitizer detector incorrectly believe that __has_feature is
available and that tsan is not in fact present since
__has_feature(thread_sanitizer) evaluates to 0.

We will fix the order of checks to put `#ifdef __SANITIZE_THREAD__` first but
thought we should probably report this to help other users.

RISC-V Test Errors and Failures

2023-05-16 Thread Palmer Dabbelt


A few of us were talking about test-related issues in the patchwork meeting
this morning.  I bumped to trunk and did a full rebuild, I'm getting the
following (it's in riscv-systems-ci/riscv-gnu-toolchain).  This is about what I
remember seeing last time I ran the tests, which was a week or so ago.  I
figured it'd be best to just blast the lists, as Jeff said his test running had
been hanging so there might be some issue preventing folks from seeing the
failures.

I guess I didn't get time to look last time and I doubt things are looking any
better right now.  I'll try and take a look at some point, but any help would
of course be appreciated.

$ cat toolchain/report
make[1]: Entering directory '/scratch/merges/rgt-gcc-trunk/toolchain'
/scratch/merges/rgt-gcc-trunk/riscv-gnu-toolchain/scripts/testsuite-filter gcc glibc 
/scratch/merges/rgt-gcc-trunk/riscv-gnu-toolchain/test/allowlist `find 
build-gcc-linux-stage2/gcc/testsuite/ -name *.sum |paste -sd "," -`
=== g++: Unexpected fails for rv64imac lp64 medlow ===
FAIL: g++.dg/contracts/contracts-tmpl-spec2.C   output pattern test
=== g++: Unexpected fails for rv32imac ilp32 medlow ===
FAIL: g++.dg/contracts/contracts-tmpl-spec2.C   output pattern test
FAIL: g++.dg/modules/xtreme-header-5_c.C -std=c++2a (test for excess errors)
FAIL: g++.dg/modules/xtreme-header-5_c.C -std=c++2b (test for excess errors)
=== g++: Unexpected fails for rv64imafdc lp64d medlow ===
FAIL: g++.dg/contracts/contracts-tmpl-spec2.C   output pattern test
=== g++: Unexpected fails for rv32imafdc ilp32d medlow ===
FAIL: g++.dg/contracts/contracts-tmpl-spec2.C   output pattern test
FAIL: g++.dg/modules/xtreme-header-5_c.C -std=c++2a (test for excess errors)
FAIL: g++.dg/modules/xtreme-header-5_c.C -std=c++2b (test for excess errors)
=== g++: Unexpected fails for rv64imafdcv lp64d  ===
FAIL: g++.dg/contracts/contracts-tmpl-spec2.C   output pattern test
FAIL: g++.target/riscv/rvv/base/bug-10.C execution test
FAIL: g++.target/riscv/rvv/base/bug-11.C execution test
FAIL: g++.target/riscv/rvv/base/bug-12.C execution test
FAIL: g++.target/riscv/rvv/base/bug-13.C execution test
FAIL: g++.target/riscv/rvv/base/bug-14.C execution test
FAIL: g++.target/riscv/rvv/base/bug-15.C execution test
FAIL: g++.target/riscv/rvv/base/bug-16.C execution test
FAIL: g++.target/riscv/rvv/base/bug-17.C execution test
FAIL: g++.target/riscv/rvv/base/bug-2.C execution test
FAIL: g++.target/riscv/rvv/base/bug-23.C execution test
FAIL: g++.target/riscv/rvv/base/bug-3.C execution test
FAIL: g++.target/riscv/rvv/base/bug-4.C execution test
FAIL: g++.target/riscv/rvv/base/bug-5.C execution test
FAIL: g++.target/riscv/rvv/base/bug-6.C execution test
FAIL: g++.target/riscv/rvv/base/bug-7.C execution test
FAIL: g++.target/riscv/rvv/base/bug-8.C execution test
FAIL: g++.target/riscv/rvv/base/bug-9.C execution test
=== g++: Unexpected fails for rv32imafdcv ilp32d  ===
FAIL: g++.dg/contracts/contracts-tmpl-spec2.C   output pattern test
FAIL: g++.dg/modules/xtreme-header-5_c.C -std=c++2a (test for excess errors)
FAIL: g++.dg/modules/xtreme-header-5_c.C -std=c++2b (test for excess errors)
FAIL: g++.target/riscv/rvv/base/bug-10.C execution test
FAIL: g++.target/riscv/rvv/base/bug-11.C execution test
FAIL: g++.target/riscv/rvv/base/bug-12.C execution test
FAIL: g++.target/riscv/rvv/base/bug-13.C execution test
FAIL: g++.target/riscv/rvv/base/bug-14.C (test for excess errors)
FAIL: g++.target/riscv/rvv/base/bug-15.C execution test
FAIL: g++.target/riscv/rvv/base/bug-16.C execution test
FAIL: g++.target/riscv/rvv/base/bug-17.C execution test
FAIL: g++.target/riscv/rvv/base/bug-18.C (test for excess errors)
FAIL: g++.target/riscv/rvv/base/bug-19.C (test for excess errors)
FAIL: g++.target/riscv/rvv/base/bug-2.C execution test
FAIL: g++.target/riscv/rvv/base/bug-20.C (test for excess errors)
FAIL: g++.target/riscv/rvv/base/bug-21.C (test for excess errors)
FAIL: g++.target/riscv/rvv/base/bug-22.C (test for excess errors)
FAIL: g++.target/riscv/rvv/base/bug-23.C execution test
FAIL: g++.target/riscv/rvv/base/bug-3.C execution test
FAIL: g++.target/riscv/rvv/base/bug-4.C execution test
FAIL: g++.target/riscv/rvv/base/bug-5.C execution test
FAIL: g++.target/riscv/rvv/base/bug-6.C execution test
FAIL: g++.target/riscv/rvv/base/bug-7.C execution test
FAIL: g++.target/riscv/rvv/base/bug-8.C execution test
FAIL: g++.target/riscv/rvv/base/bug-9.C (test for excess errors)
=== g++: Unexpected fails for rv64gczba_zbb_zbc_zbs lp64d  ===
FAIL: g++.dg/contracts/contracts-tmpl-spec2.C   output pattern test
=== gcc: Unexpected fails for rv64imac lp64 medlow ===
ERROR: tcl error sourcing 
/scratch/merges/rgt-gcc-trunk/riscv-gnu-toolchain/gcc/gcc/testsuite/gcc.c-torture/execute/builtins/builtins.exp.
ERROR: torture-init: torture_without_loops is not empty as expected
ERROR: tcl error sourcing

[Bug rtl-optimization/79148] stack addresses are spilled to stack slots on x86-64 at -Os instead of rematerializing the addresses

2023-05-16 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2023-05-16
 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1

--- Comment #2 from Andrew Pinski  ---
The testcase at https://people.mozilla.org/~nfroyd/Unified_cpp_widget0.ii.gz is
no longer downloadable.

Do anyone know where a testcase for this can be get from?

[Bug target/109812] GraphicsMagick resize is a lot slower in GCC 13.1 vs Clang 16

2023-05-16 Thread juzhe.zhong at rivai dot ai via Gcc-bugs

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

JuzheZhong  changed:

   What|Removed |Added

 CC||juzhe.zhong at rivai dot ai

--- Comment #4 from JuzheZhong  ---
Thanks for reporting this. Unfortunately, a single report can not help us.
Would you mind file a bug with simple piece of code that we can reproduce
such issue and this issue matters for the benchmark.

Besides, I have read this report. I think this may be the X86 backend issue.
We (downstream) RISC-V GCC have tested various workloads, turns out GCC is
better
than Clang in traditional CPU benchmark. Also, Clang is much better than GCC in
AI program benchmark (For example mlperf).

Start with the benchmark you mentioned (GraphicsMagick), Could you post the
most important piece of code belongging to this benchmark ?


Thanks.

[Bug fortran/109865] different results when routine moved inside the contains statement

2023-05-16 Thread Gary.White at ColoState dot edu via Gcc-bugs

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

--- Comment #11 from GARY.WHITE at ColoState dot edu  ---
I've never used valgrind -- what would it do?

The problem isn't that the code is wrong -- otherwise -O0 would not generate
correct results.  The compiler is optimizing something incorrectly with -O1
that causes the numerical optimizer, i.e., va09ad code, to not work correctly. 
I included 2 files in the zip file that show incorrect and correct results --
basically va09ad just doesn't go anywhere, not finding an optimum after running
to the maximum number of function calls.  It's not blowing up or aborting --
just producing wrong answers.

I am willing to walk you through where the critical code is located, but need
to know more of what system you're working on and how I can help.

[Bug ada/109881] GNAT BUG DETECTED during RTL pass, raised TYPES.UNRECOVERABLE_ERROR

2023-05-16 Thread gnugcc at marino dot st via Gcc-bugs

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

--- Comment #1 from John Marino  ---
I commented out the "file_to_file_decompression" function and the GNAT BUG
disappeared.

[Bug rtl-optimization/66890] function splitting only works with profile feedback

2023-05-16 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

--- Comment #6 from Andrew Pinski  ---
Really for this loop, I would have assume to be split into 3 different loops
like:
volatile int count;

int main()
{
int i;
for (i = 0; i < 999; i++) {
if (i == 999)
count *= 2;
count++;
}
for (; i < 999+1; i++) {
if (i == 999)
count *= 2;
count++;
}
for (; i < 10; i++) {
if (i == 999)
count *= 2;
count++;
}
}

And then it would not have an extra branch inside the loop itself either.

[Bug ada/109881] New: GNAT BUG DETECTED during RTL pass, raised TYPES.UNRECOVERABLE_ERROR

2023-05-16 Thread gnugcc at marino dot st via Gcc-bugs

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

Bug ID: 109881
   Summary: GNAT BUG DETECTED during RTL pass, raised
TYPES.UNRECOVERABLE_ERROR
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gnugcc at marino dot st
CC: dkm at gcc dot gnu.org
  Target Milestone: ---

Created attachment 55096
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55096=edit
The three ada source files requested in the GNAT BUG message

During development, I hit this error on GCC 11.2.0 and also got a very similar
one on Community 2020 (Windows).  It just happened so if a future change
resolves it, I'll reattach those source files.  


during RTL pass: expand
+===GNAT BUG DETECTED==+
| 11.2.0 (x86_64-raven-dragonfly6.2) GCC error:|
| in operand_subword_force, at emit-rtl.c:1806 |
| Error detected around
/home/marino/rvn-format/src/zstandard/zstandard-streaming_decompression.adb:249:8|
| Please submit a bug report; see https://gcc.gnu.org/bugs/ .  |
| Use a subject line meaningful to you and us to track the bug.|
| Include the entire contents of this bug box in the report.   |
| Include the exact command that you entered.  |
| Also include sources listed below.   |
+==+

Please include these source files with error report
Note that list may not be accurate in some cases,
so please double check that the problem can still
be reproduced with the set of files listed.
Consider also -gnatd.n switch (see debug.adb).

/home/marino/rvn-format/src/zstandard/zstandard-streaming_decompression.adb
zstandard/zstandard-streaming_decompression.ads
zstandard/zstandard.ads

raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:407

commands that built it:
gcc -c unix/stat_opsc.c -o stat_opsc.o

PROG=/raven/share/raven/toolchain/ravensys-gcc/bin/gnatmake
${PROG} unrvn.adb -Izstandard -Iblake3 -Iunix -lzstd -largs -L/raven/lib
-lzstd_pic -lblake3_pic stat_opsc.o

[Bug debug/109805] LTO affecting -fdebug-prefix-map

2023-05-16 Thread sergiodj at sergiodj dot net via Gcc-bugs

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

--- Comment #12 from Sergio Durigan Junior  ---
Sorry, I have been busy with other things, but I'm paying attention to the
developments here.

I still have to test the workaround I suggested (passing -fdebug-prefix-map to
LDFLAGS) more broadly, because I think I may have found at least one scenario
where it doesn't work.  Something else that's puzzling me is the fact that I
don't see this behaviour everywhere; some packages do have the expected
DW_AT_comp_dir even after being compiled with LTO enabled.

[Bug testsuite/109880] New: [14 regression] gcc.target/powerpc/fold-vec-extract-int.p8.c fails after r14-916-g9417b30499ce09

2023-05-16 Thread seurer at gcc dot gnu.org via Gcc-bugs

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

Bug ID: 109880
   Summary: [14 regression]
gcc.target/powerpc/fold-vec-extract-int.p8.c fails
after r14-916-g9417b30499ce09
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:9417b30499ce09996b4f1b4e2ce75a2853865ed4, r14-916-g9417b30499ce09
make  -k check-gcc
RUNTESTFLAGS="powerpc.exp=gcc.target/powerpc/fold-vec-extract-int.p8.c"
FAIL: gcc.target/powerpc/fold-vec-extract-int.p8.c scan-assembler-times
\\mrldicl\\M 7
# of expected passes11
# of unexpected failures1


The test case may just need updating.  The ones that count assembler
instructions can be fragile.


commit 9417b30499ce09996b4f1b4e2ce75a2853865ed4 (HEAD, refs/bisect/bad)
Author: <80><9C>Ajit Kumar Agarwal<80><9D> 
Date:   Tue May 16 10:47:15 2023 -0500

rs6000: Enable REE pass by default

[Bug fortran/109865] different results when routine moved inside the contains statement

2023-05-16 Thread sgk at troutmask dot apl.washington.edu via Gcc-bugs

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

--- Comment #10 from Steve Kargl  ---
On Tue, May 16, 2023 at 03:55:51PM +, Gary.White at ColoState dot edu
wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109865
> 
> --- Comment #9 from GARY.WHITE at ColoState dot edu  dot edu> ---
> Another clue.  I'm seeing the same bug in gfortran-13, except that I have to
> use  -O0 for both cases of mc11ad.f90 in or out of the contains statement.
> 
> Similarly, if I put the set of va09ad.f90 routines in a module, I have to use
> -O0 to get correct answers.  -O3 causes a bug with va09ad.f90 in a module as
> well.
> 

Can you use valgrind?  I got the zip file, but reducing
that will be a pain. First, the included lapack, blas,
and linpack archives are useless to me.  Second, there
is just way too much code with a complete lack of
familiarity to try to reduce this.

I suspect you may have to go old school with
'print *' debugging in the problematic subroutine.

[Bug modula2/109879] ReadCard and ReadInt from WholeIO have problems with leading space

2023-05-16 Thread gaius at gcc dot gnu.org via Gcc-bugs

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

Gaius Mulley  changed:

   What|Removed |Added

   Last reconfirmed||2023-05-16
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1

--- Comment #2 from Gaius Mulley  ---
Confirmed as a bug.

[Bug modula2/109879] ReadCard and ReadInt from WholeIO have problems with leading space

2023-05-16 Thread gaius at gcc dot gnu.org via Gcc-bugs

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

Gaius Mulley  changed:

   What|Removed |Added

 CC||gaius at gcc dot gnu.org

--- Comment #1 from Gaius Mulley  ---
Created attachment 55095
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55095=edit
Proposed fix

Here is a proposed patch and testcase.

[Bug modula2/109879] New: ReadCard and ReadInt from WholeIO have problems with leading space

2023-05-16 Thread gaius at gcc dot gnu.org via Gcc-bugs

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

Bug ID: 109879
   Summary: ReadCard and ReadInt from WholeIO have problems with
leading space
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: modula2
  Assignee: gaius at gcc dot gnu.org
  Reporter: gaius at gcc dot gnu.org
  Target Milestone: ---

As reported on the gn2 mailing list, leading spaces are not skipped when
performing ReadInt or ReadCard.


module port_test10a_gm2;

from ChanConsts IMPORT
  OpenResults, old, read, write;
from IOChan IMPORT
  ChanId;
from StdChans IMPORT
  StdOutChan;
import StreamFile;
from TextIO IMPORT
  SkipLine, WriteLn, WriteString;
from WholeIO IMPORT
  ReadCard, ReadInt, WriteCard, WriteInt;


procedure ReadNumbersTest();
  const
arr_len=128;

  type
arr_type=   ARRAY[0..arr_len-1] of char;

  var
cid_file:   ChanId;
cid_out:ChanId;
file_name:  arr_type;
res:OpenResults;
c1: cardinal;
ival:   integer;
cval:   cardinal;

  begin (* procedure ReadNumbersTest *)
cid_out:=StdOutChan();

file_name:='test_data';

(* create file and write (integer) numbers to it *)
WriteString(cid_out, 'write (integer) numbers to file...');
WriteLn(cid_out);
StreamFile.Open(cid_file, file_name, write+old, res);
if res=opened THEN
  WriteString(cid_file, ' 123');
  WriteLn(cid_file);
  WriteString(cid_file, '234');
  WriteLn(cid_file);
  StreamFile.Close(cid_file);
end;(* if res=opened *)

(* (re-)open file and read numbers with ReadCard *)
WriteString(cid_out, 'read numbers with ReadCard...');
WriteLn(cid_out);
StreamFile.Open(cid_file, file_name, read, res);
if res=opened THEN
  for c1:=1 TO 2 DO
ReadCard(cid_file, cval);
WriteCard(cid_out, cval, 1);
WriteLn(cid_out);
SkipLine(cid_file);
  end;  (* for c1 *)
  StreamFile.Close(cid_file);
end;(* if res=opened *)
WriteLn(cid_out);

(* (re-)open file and read numbers with ReadInt *)
WriteString(cid_out, 'read numbers with ReadInt...');
WriteLn(cid_out);
StreamFile.Open(cid_file, file_name, read, res);
if res=opened THEN
  for c1:=1 TO 2 DO
ReadInt(cid_file, ival);
WriteInt(cid_out, ival, 1);
WriteLn(cid_out);
SkipLine(cid_file);
  end;  (* for c1 *)
  StreamFile.Close(cid_file);
end;(* if res=opened *)
WriteLn(cid_out);

  end ReadNumbersTest;


begin   (* module port_test10a_gm2 *)
  ReadNumbersTest();
end port_test10a_gm2.

[Bug tree-optimization/106900] Regression after memchr optimization

2023-05-16 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2023-05-16

--- Comment #4 from Andrew Pinski  ---
I am just going to test:
diff --git a/gcc/tree-ssa-forwprop.cc b/gcc/tree-ssa-forwprop.cc
index 06f19868ade..0326e6733e8 100644
--- a/gcc/tree-ssa-forwprop.cc
+++ b/gcc/tree-ssa-forwprop.cc
@@ -1231,14 +1231,14 @@ simplify_builtin_call (gimple_stmt_iterator *gsi_p,
tree callee2)
  tree size = gimple_call_arg (stmt2, 2);
  /* Size must be a constant which is <= UNITS_PER_WORD and
 <= the string length.  */
- if (TREE_CODE (size) != INTEGER_CST || integer_zerop (size))
+ if (TREE_CODE (size) != INTEGER_CST)
break;

  if (!tree_fits_uhwi_p (size))
break;

  unsigned HOST_WIDE_INT sz = tree_to_uhwi (size);
- if (sz > UNITS_PER_WORD || sz >= slen)
+ if (sz == 0 || sz > UNITS_PER_WORD || sz >= slen)
break;

  tree ch = gimple_call_arg (stmt2, 1);


This does not change the behavior of the code at all, just makes it obvious sz
cannot be 0 and therefore isize won't be 0 either.

[Bug libstdc++/40094] FAIL: ext/throw_allocator/deallocate_global.cc execution test

2023-05-16 Thread redi at gcc dot gnu.org via Gcc-bugs

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

--- Comment #26 from Jonathan Wakely  ---
Thanks!

[Bug libstdc++/40094] FAIL: ext/throw_allocator/deallocate_global.cc execution test

2023-05-16 Thread danglin at gcc dot gnu.org via Gcc-bugs

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

John David Anglin  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #25 from John David Anglin  ---
No.

[Bug libstdc++/109814] [13/14 Regression] freestanding using cmath does not compile anymore

2023-05-16 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |13.2

[Bug libstdc++/40094] FAIL: ext/throw_allocator/deallocate_global.cc execution test

2023-05-16 Thread redi at gcc dot gnu.org via Gcc-bugs

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #24 from Jonathan Wakely  ---
Dave, is this still an issue on the currently supported hp-ux targets?

[Bug analyzer/109570] detect fclose on unopened or NULL files

2023-05-16 Thread clyon at gcc dot gnu.org via Gcc-bugs

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

Christophe Lyon  changed:

   What|Removed |Added

 CC||clyon at gcc dot gnu.org

--- Comment #4 from Christophe Lyon  ---
The glibc change is now causing failures in the GCC testsuite:
FAIL: gcc.dg/analyzer/torture/conftest-1.c   -O0  (test for excess errors)
Excess errors:
/gcc/testsuite/gcc.dg/analyzer/torture/conftest-1.c:6:24: warning: use of
possibly-NULL 'f' where non-null expected [CWE-690]
[-Wanalyzer-possible-null-argument]


FAIL: gcc.dg/analyzer/data-model-4.c (test for excess errors)
Excess errors:
/gcc/testsuite/gcc.dg/analyzer/data-model-4.c:11:24: warning: use of
possibly-NULL 'f' where non-null expected [CWE-690]
[-Wanalyzer-possible-null-argument]

[Bug c++/109877] Support for clang-style attributes is needed to parse Darwin SDK headers properly

2023-05-16 Thread jakub at gcc dot gnu.org via Gcc-bugs

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

--- Comment #6 from Jakub Jelinek  ---
That is generally the case for the standard C/C++ attributes (arguments just
need to be a balanced token sequence), but not for GNU attributes.  Although,
all standard C/C++ attributes we support right now other than OpenMP ones
follow the GNU attribute rules as well.

[Bug libstdc++/33578] __gnu_parallel::yield means what?

2023-05-16 Thread redi at gcc dot gnu.org via Gcc-bugs

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

--- Comment #10 from Jonathan Wakely  ---
For std::this_thread::yield() we do:

inline void
yield() noexcept
{
#if defined _GLIBCXX_HAS_GTHREADS && defined _GLIBCXX_USE_SCHED_YIELD
  __gthread_yield();
#endif
}

And gthr-win32.h has:

__GTHREAD_WIN32_INLINE int
__gthread_yield (void)
{
  Sleep (0);
  return 0;
}

For atomics we also support using the x86 pause instruction

inline void
__thread_yield() noexcept
{
#if defined _GLIBCXX_HAS_GTHREADS && defined _GLIBCXX_USE_SCHED_YIELD
 __gthread_yield();
#endif
}

inline void
__thread_relax() noexcept
{
#if defined __i386__ || defined __x86_64__
  __builtin_ia32_pause();
#else
  __thread_yield();
#endif
}



For Parallel Mode maybe we should just use __gthread_yield() everywhere?
gthr-win32.h already takes care of hiding the Win32 API. Since Parallel Mode is
likely to get removed at some point (now that we have the parallel STL algos
from C++17) I don't see any point in revisiting its implementation w.r.t using
of yield at all (comment 1).

tl;dr let's not reinvent the wheel when we already have portable code for
yielding, and don't want to redesign the parallel mode.

Re: [PATCH] aarch64: Add SVE instruction types

2023-05-16 Thread Evandro Menezes via Gcc-patches

Hi, Kyrill.

It makes sense.  I could add the classification to a different attribute as you 
did and keep it in aarch64 as well.

I took the same approach, gleaning over several optimization guides for Arm 
processors supporting SVE and figuring out the smallest number of types that 
could cover most variations of resources used.  Methinks that the 
classification in this patch is close to that goal, but feedback is appreciated.

I did observe a meaningful gain in performance.  Of course, wide machines like 
the V1 can handle most instruction sequences thrown at it, but there’s still 
some efficiency left on the table without a tailored scheduling, especially 
when recovering from cache or branch misses, when it’s important to quickly 
fill up the pipeline back to regime, albeit umpteen transistors are dedicated 
to make sure that misses do not happen often.

Thank you,

-- 
Evandro Menezes



> Em 16 de mai. de 2023, à(s) 03:36, Kyrylo Tkachov  
> escreveu:
> 
> Hi Evandro,
>  
> I created a new attribute so I didn’t have to extend the “type” attribute 
> that lives in config/arm/types.md. As that attribute and file lives in the 
> arm backend but SVE is AArch64-only I didn’t want to add logic to the arm 
> backend as it’s not truly shared.
> The granularity has been somewhat subjective. I had looked at the Software 
> Optimisation guides for various SVE and SVE2-capable cores from Arm on 
> developer.arm.com  and tried to glean 
> commonalities between different instruction groups.
> I did try writing a model for Neoverse V1 using that classification but I 
> couldn’t spend much time on it and the resulting model didn’t give me much 
> improvements and gave some regressions instead.
> I think that was more down to my rushed model rather than anything else 
> though.
>  
> Thanks,
> Kyrill
>  
> From: Evandro Menezes  
> Sent: Monday, May 15, 2023 9:13 PM
> To: Kyrylo Tkachov 
> Cc: Richard Sandiford ; Evandro Menezes via 
> Gcc-patches ; evandro+...@gcc.gnu.org; Tamar 
> Christina 
> Subject: Re: [PATCH] aarch64: Add SVE instruction types
>  
> Hi, Kyrill.
>  
> I wasn’t aware of your previous patch.  Could you clarify why you considered 
> creating an SVE specific type attribute instead of reusing the common one?  I 
> really liked the iterators that you created; I’d like to use them.
>  
> Do you have specific examples which you might want to mention with regards to 
> granularity?
>  
> Yes, my intent for this patch is to enable modeling the SVE instructions on 
> N1.  The patch that implements it brings up some performance improvements, 
> but it’s mostly flat, as expected.
>  
> Thank you,
> 
> -- 
> Evandro Menezes
>  
>  
> 
> 
> Em 15 de mai. de 2023, à(s) 04:49, Kyrylo Tkachov  > escreveu:
>  
> 
> 
> 
> -Original Message-
> From: Richard Sandiford  >
> Sent: Monday, May 15, 2023 10:01 AM
> To: Evandro Menezes via Gcc-patches  >
> Cc: evandro+...@gcc.gnu.org ; Evandro Menezes 
> mailto:ebah...@icloud.com>>;
> Kyrylo Tkachov mailto:kyrylo.tkac...@arm.com>>; 
> Tamar Christina
> mailto:tamar.christ...@arm.com>>
> Subject: Re: [PATCH] aarch64: Add SVE instruction types
> 
> Evandro Menezes via Gcc-patches  > writes:
> 
> This patch adds the attribute `type` to most SVE1 instructions, as in the
> other
> 
> instructions.
> 
> Thanks for doing this.
> 
> Could you say what criteria you used for picking the granularity?  Other
> maintainers might disagree, but personally I'd prefer to distinguish two
> instructions only if:
> 
> (a) a scheduling description really needs to distinguish them or
> (b) grouping them together would be very artificial (because they're
>logically unrelated)
> 
> It's always possible to split types later if new scheduling descriptions
> require it.  Because of that, I don't think we should try to predict ahead
> of time what future scheduling descriptions will need.
> 
> Of course, this depends on having results that show that scheduling
> makes a significant difference on an SVE core.  I think one of the
> problems here is that, when a different scheduling model changes the
> performance of a particular test, it's difficult to tell whether
> the gain/loss is caused by the model being more/less accurate than
> the previous one, or if it's due to important "secondary" effects
> on register live ranges.  Instinctively, I'd have expected these
> secondary effects to dominate on OoO cores.
> 
> I agree with Richard on these points. The key here is getting the granularity 
> right without having too maintain too many types that aren't useful in the 
> models.
> FWIW I had posted 
> https://gcc.gnu.org/pipermail/gcc-patches/2022-November/607101.html in 
> November. It adds annotations to SVE2 patterns as well as for base SVE.
> Feel free to reuse it if you'd like.
> I see you had

Re: [PATCH] configure: Implement --enable-host-pie

2023-05-16 Thread Iain Sandoe

Hi Marek,

> On 16 May 2023, at 16:29, Marek Polacek via Gcc-patches 
>  wrote:
> 
> Ping.

I’m trying this on Darwin (since I have a local patch to do this for modern 
[darwin20+]
versions, which do not allow non-PIE)

I think you are missing a hunk to deal with Ada.

thanks for the patch
Iain

> 
> On Tue, May 09, 2023 at 03:41:58PM -0400, Marek Polacek via Gcc-patches wrote:
>> [ This is my third attempt to add this configure option.  The first
>> version was approved but it came too late in the development cycle.
>> The second version was also approved, but I had to revert it:
>> .
>> I've fixed the problem (by moving $(PICFLAG) from INTERNAL_CFLAGS to
>> ALL_COMPILERFLAGS).  Another change is that since r13-4536 I no longer
>> need to touch Makefile.def, so this patch is simplified. ]
>> 
>> This patch implements the --enable-host-pie configure option which
>> makes the compiler executables PIE.  This can be used to enhance
>> protection against ROP attacks, and can be viewed as part of a wider
>> trend to harden binaries.
>> 
>> It is similar to the option --enable-host-shared, except that --e-h-s
>> won't add -shared to the linker flags whereas --e-h-p will add -pie.
>> It is different from --enable-default-pie because that option just
>> adds an implicit -fPIE/-pie when the compiler is invoked, but the
>> compiler itself isn't PIE.
>> 
>> Since r12-5768-gfe7c3ecf, PCH works well with PIE, so there are no PCH
>> regressions.
>> 
>> When building the compiler, the build process may use various in-tree
>> libraries; these need to be built with -fPIE so that it's possible to
>> use them when building a PIE.  For instance, when --with-included-gettext
>> is in effect, intl object files must be compiled with -fPIE.  Similarly,
>> when building in-tree gmp, isl, mpfr and mpc, they must be compiled with
>> -fPIE.
>> 
>> With this patch and --enable-host-pie used to configure gcc:
>> 
>> $ file gcc/cc1{,plus,obj} gcc/f951 gcc/lto1 gcc/cpp
>> gcc/cc1: ELF 64-bit LSB pie executable, x86-64, version 1 (GNU/Linux), 
>> dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 
>> 3.2.0, with debug_info, not stripped
>> gcc/cc1plus: ELF 64-bit LSB pie executable, x86-64, version 1 (GNU/Linux), 
>> dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 
>> 3.2.0, with debug_info, not stripped
>> gcc/f951:ELF 64-bit LSB pie executable, x86-64, version 1 (GNU/Linux), 
>> dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 
>> 3.2.0, with debug_info, not stripped
>> gcc/cc1obj:  ELF 64-bit LSB pie executable, x86-64, version 1 (GNU/Linux), 
>> dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 
>> 3.2.0, with debug_info, not stripped
>> gcc/lto1:ELF 64-bit LSB pie executable, x86-64, version 1 (GNU/Linux), 
>> dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 
>> 3.2.0, with debug_info, not stripped
>> gcc/cpp: ELF 64-bit LSB pie executable, x86-64, version 1 (GNU/Linux), 
>> dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 
>> 3.2.0, with debug_info, not stripped
>> 
>> I plan to add an option to link with -Wl,-z,now.
>> 
>> Bootstrapped on x86_64-pc-linux-gnu with --with-included-gettext
>> --enable-host-pie as well as without --enable-host-pie.  Also tested
>> on a Debian system where the system gcc was configured with
>> --enable-default-pie.
>> 
>> ChangeLog:
>> 
>>  * configure.ac (--enable-host-pie): New check.  Set PICFLAG after this
>>  check.
>>  * configure: Regenerate.
>> 
>> c++tools/ChangeLog:
>> 
>>  * Makefile.in: Rename PIEFLAG to PICFLAG.  Set LD_PICFLAG.  Use it.
>>  Use pic/libiberty.a if PICFLAG is set.
>>  * configure.ac (--enable-default-pie): Set PICFLAG instead of PIEFLAG.
>>  (--enable-host-pie): New check.
>>  * configure: Regenerate.
>> 
>> fixincludes/ChangeLog:
>> 
>>  * Makefile.in: Set and use PICFLAG and LD_PICFLAG.  Use the "pic"
>>  build of libiberty if PICFLAG is set.
>>  * configure.ac:
>>  * configure: Regenerate.
>> 
>> gcc/ChangeLog:
>> 
>>  * Makefile.in: Set LD_PICFLAG.  Use it.  Set enable_host_pie.
>>  Remove NO_PIE_CFLAGS and NO_PIE_FLAG.  Pass LD_PICFLAG to
>>  ALL_LINKERFLAGS.  Use the "pic" build of libiberty if --enable-host-pie.
>>  * configure.ac (--enable-host-shared): Don't set PICFLAG here.
>>  (--enable-host-pie): New check.  Set PICFLAG and LD_PICFLAG after this
>>  check.
>>  * configure: Regenerate.
>>  * doc/install.texi: Document --enable-host-pie.
>> 
>> gcc/d/ChangeLog:
>> 
>>  * Make-lang.in: Remove NO_PIE_CFLAGS.
>> 
>> intl/ChangeLog:
>> 
>>  * Makefile.in: Use @PICFLAG@ in COMPILE as well.
>>  * configure.ac (--enable-host-shared): Don't set PICFLAG here.
>>  (--enable-host-pie): New check.  Set PICFLAG after this check.
>>  *

[Bug c++/109877] Support for clang-style attributes is needed to parse Darwin SDK headers properly

2023-05-16 Thread iains at gcc dot gnu.org via Gcc-bugs

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

--- Comment #5 from Iain Sandoe  ---
(In reply to Jakub Jelinek from comment #4)
> (In reply to Andrew Pinski from comment #2)
> > This style of attributes is bad. Because the GNU style attribute is just
> > token(expression,expression,expression) it seems odd that they added these
> > kind of attributes without thinking maybe it would be rejected somewhere
> > else.
> 
> To be precise, some attributes have the first argument an identifier rather
> than expression (e.g. mode/format/cleanup/access attribute).
> So, the macOS as first argument is acceptable, but not the second one.

As far as I can tell (and what my current implementation does) is to say that
everything in the inner parentheses cam be lexed/parsed in a manner specific to
the attribute ID.

so in:
 availability() the  is parsed specifically to "availability"
and presumably:
 another_attr() could have a different set of rules.

As noted, we [at least, all I have spoken to] agree that this is bad (in
respect of deviating from GNU style without any other mechanism to
differentiate).  However, once stuff is in the wild

Re: [PATCH] s390: Implement TARGET_ATOMIC_ALIGN_FOR_MODE

2023-05-16 Thread Andreas Krebbel via Gcc-patches

On 5/16/23 08:43, Stefan Schulze Frielinghaus wrote:
> So far atomic objects are aligned according to their default alignment.
> For 128 bit scalar types like int128 or long double this results in an
> 8 byte alignment which is wrong and must be 16 byte.
> 
> libstdc++ already computes a correct alignment, though, still adding a
> test case in order to make sure that both implementations are
> compatible.
> 
> Bootstrapped and regtested.  Ok for mainline?  Since this is an ABI
> break, is a backport to GCC 13 reasonable?

Ok for mainline.

I would also like to have it in GCC 13. It is an ABI breakage but on the other 
hand it also fixes an
ABI inconsistency between C and C++ which we should fix asap I think.

Andreas


> 
> gcc/ChangeLog:
> 
>   * config/s390/s390.cc (TARGET_ATOMIC_ALIGN_FOR_MODE):
>   New.
>   (s390_atomic_align_for_mode): New.
> 
> gcc/testsuite/ChangeLog:
> 
>   * g++.target/s390/atomic-align-1.C: New test.
>   * gcc.target/s390/atomic-align-1.c: New test.
>   * gcc.target/s390/atomic-align-2.c: New test.
> ---
>  gcc/config/s390/s390.cc   |  8 ++
>  .../g++.target/s390/atomic-align-1.C  | 25 +++
>  .../gcc.target/s390/atomic-align-1.c  | 23 +
>  .../gcc.target/s390/atomic-align-2.c  | 18 +
>  4 files changed, 74 insertions(+)
>  create mode 100644 gcc/testsuite/g++.target/s390/atomic-align-1.C
>  create mode 100644 gcc/testsuite/gcc.target/s390/atomic-align-1.c
>  create mode 100644 gcc/testsuite/gcc.target/s390/atomic-align-2.c
> 
> diff --git a/gcc/config/s390/s390.cc b/gcc/config/s390/s390.cc
> index 505de995da8..4813bf91dc4 100644
> --- a/gcc/config/s390/s390.cc
> +++ b/gcc/config/s390/s390.cc
> @@ -450,6 +450,14 @@ s390_preserve_fpr_arg_p (int regno)
> && regno >= FPR0_REGNUM);
>  }
>  
> +#undef TARGET_ATOMIC_ALIGN_FOR_MODE
> +#define TARGET_ATOMIC_ALIGN_FOR_MODE s390_atomic_align_for_mode
> +static unsigned int
> +s390_atomic_align_for_mode (machine_mode mode)
> +{
> +  return GET_MODE_BITSIZE (mode);
> +}
> +
>  /* A couple of shortcuts.  */
>  #define CONST_OK_FOR_J(x) \
>   CONST_OK_FOR_CONSTRAINT_P((x), 'J', "J")
> diff --git a/gcc/testsuite/g++.target/s390/atomic-align-1.C 
> b/gcc/testsuite/g++.target/s390/atomic-align-1.C
> new file mode 100644
> index 000..43aa0bc39ed
> --- /dev/null
> +++ b/gcc/testsuite/g++.target/s390/atomic-align-1.C
> @@ -0,0 +1,25 @@
> +/* { dg-do compile { target int128 } } */
> +/* { dg-options "-std=c++11" } */
> +/* { dg-final { scan-assembler-times {\.align\t2} 2 } } */
> +/* { dg-final { scan-assembler-times {\.align\t4} 2 } } */
> +/* { dg-final { scan-assembler-times {\.align\t8} 3 } } */
> +/* { dg-final { scan-assembler-times {\.align\t16} 2 } } */
> +
> +#include 
> +
> +// 2
> +std::atomic var_char;
> +std::atomic var_short;
> +// 4
> +std::atomic var_int;
> +// 8
> +std::atomic var_long;
> +std::atomic var_long_long;
> +// 16
> +std::atomic<__int128> var_int128;
> +// 4
> +std::atomic var_float;
> +// 8
> +std::atomic var_double;
> +// 16
> +std::atomic var_long_double;
> diff --git a/gcc/testsuite/gcc.target/s390/atomic-align-1.c 
> b/gcc/testsuite/gcc.target/s390/atomic-align-1.c
> new file mode 100644
> index 000..b2e1233e3ee
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/s390/atomic-align-1.c
> @@ -0,0 +1,23 @@
> +/* { dg-do compile { target int128 } } */
> +/* { dg-options "-std=c11" } */
> +/* { dg-final { scan-assembler-times {\.align\t2} 2 } } */
> +/* { dg-final { scan-assembler-times {\.align\t4} 2 } } */
> +/* { dg-final { scan-assembler-times {\.align\t8} 3 } } */
> +/* { dg-final { scan-assembler-times {\.align\t16} 2 } } */
> +
> +// 2
> +_Atomic char var_char;
> +_Atomic short var_short;
> +// 4
> +_Atomic int var_int;
> +// 8
> +_Atomic long var_long;
> +_Atomic long long var_long_long;
> +// 16
> +_Atomic __int128 var_int128;
> +// 4
> +_Atomic float var_float;
> +// 8
> +_Atomic double var_double;
> +// 16
> +_Atomic long double var_long_double;
> diff --git a/gcc/testsuite/gcc.target/s390/atomic-align-2.c 
> b/gcc/testsuite/gcc.target/s390/atomic-align-2.c
> new file mode 100644
> index 000..0bf17341bf8
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/s390/atomic-align-2.c
> @@ -0,0 +1,18 @@
> +/* { dg-do compile { target int128 } } */
> +/* { dg-options "-O -std=c11" } */
> +/* { dg-final { scan-assembler-not {abort} } } */
> +
> +/* The stack is 8 byte aligned which means GCC has to manually align a 16 
> byte
> +   aligned object.  This is done by allocating not 16 but rather 24 bytes for
> +   variable X and then manually aligning a pointer inside the memory block.
> +   Validate this by ensuring that the if-statement is optimized out.  */
> +
> +void bar (_Atomic unsigned __int128 *ptr);
> +
> +void foo (void) {
> +  _Atomic unsigned __int128 x;
> +  unsigned long n = (unsigned long)
> +  if (n % 16 != 0)
> +__builtin_abort ();
> +  bar ();
> +}

[Bug target/77579] Missed multiple add (int) for CSEd case

2023-05-16 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
Thinking about this some more, doing the multiply multiple times is actually
slower on most cores.
So this is not something you want to do normally but with a constant multiply
you do for small power of 2 constant.

E.g.:
```
void f(int x, int y, int z, int *s)
{
   int t = y * 2;
   s[0] = t + x;
   s[1] = x - t;
}
```
You should get:

add w2, w0, w1 lsl 1
sub w0, w0, w1 lsl 1
stp w2, w0, [x3]

And no seperate lsl instruction as the cost to do the lsl is free in this case.

Anyways I am not working on this any more.

[Bug target/104338] RISC-V: Subword atomics result in library calls

2023-05-16 Thread palmer at gcc dot gnu.org via Gcc-bugs

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

--- Comment #20 from palmer at gcc dot gnu.org ---
(In reply to rvalue from comment #19)
> (In reply to Aurelien Jarno from comment #18)
> > I wonder if the following patch should also be backported, as it
> > doesn't make sense to link with -latomic anymore with inline subword atomic
> > operations
> 
> Agreed. It's now meaningless to keep this workaround for RISC-V as the
> problem has been resolved.

Yep.  Can someone send the backport?

[Bug c++/109877] Support for clang-style attributes is needed to parse Darwin SDK headers properly

2023-05-16 Thread jakub at gcc dot gnu.org via Gcc-bugs

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
(In reply to Andrew Pinski from comment #2)
> This style of attributes is bad. Because the GNU style attribute is just
> token(expression,expression,expression) it seems odd that they added these
> kind of attributes without thinking maybe it would be rejected somewhere
> else.

To be precise, some attributes have the first argument an identifier rather
than expression (e.g. mode/format/cleanup/access attribute).
So, the macOS as first argument is acceptable, but not the second one.

[Bug tree-optimization/109878] New: missed simplifications of MAX and MIN

2023-05-16 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Bug ID: 109878
   Summary: missed simplifications of MAX and
MIN
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

Take:
```
int max_and(int a, int b)
{
b = a & 3;
a = a & 1;
if (b > a)
  return b;
else
  return a;
}
int min_and(int a, int b)
{
b = a & 3;
a = a & 1;
if (b < a)
  return b;
else
  return a;
}
```
max_and should just be optimized to `a&3` while min_and should be just
optimized to `a&1` The general rule is:
MAX -> a & CST0 IFF CST0  == CST1, that is CST1 is a
true subset of CST0.

I found this on accident while thinking about some generated code in
insn-automata.cc on x86_64.
MIN -> a & CST0 IFF CST0 == CST0, that is CST0 is a true
subset of CST1.

[Bug c++/109774] template function causes Spurious dangling reference warning while non-template does not

2023-05-16 Thread mpolacek at gcc dot gnu.org via Gcc-bugs

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

Marek Polacek  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #5 from Marek Polacek  ---
Fixed.

[Bug c++/109774] template function causes Spurious dangling reference warning while non-template does not

2023-05-16 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-13 branch has been updated by Marek Polacek
:

https://gcc.gnu.org/g:22741a09a8cbf8a360e99e530b016233dd705ce4

commit r13-7337-g22741a09a8cbf8a360e99e530b016233dd705ce4
Author: Marek Polacek 
Date:   Tue May 16 14:12:06 2023 -0400

c++: -Wdangling-reference not suppressed in template [PR109774]

In check_return_expr, we suppress the -Wdangling-reference warning when
we're sure it would be a false positive.  It wasn't working in a
template, though, because the suppress_warning call was never reached.

PR c++/109774

gcc/cp/ChangeLog:

* typeck.cc (check_return_expr): In a template, return only after
suppressing -Wdangling-reference.

gcc/testsuite/ChangeLog:

* g++.dg/warn/Wdangling-reference13.C: New test.

(cherry picked from commit f25d2de17663a0132f9fe090dee39d3b1132067b)

[Bug c++/109877] Support for clang-style attributes is needed to parse Darwin SDK headers properly

2023-05-16 Thread iains at gcc dot gnu.org via Gcc-bugs

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

--- Comment #3 from Iain Sandoe  ---
(In reply to Andrew Pinski from comment #2)
> This style of attributes is bad. Because the GNU style attribute is just
> token(expression,expression,expression) it seems odd that they added these
> kind of attributes without thinking maybe it would be rejected somewhere
> else.

Actually, the folks from clang I've spoken to agree it is bad; however, it's
also in the wild and so unfixable - at least for the key attributes such as
availability.  I hope that future additions will not take advantage of the
extra flexibility.

>From the PoV of the platform I'm kinda stuck [and it seems those attributes are
also used by, at least, android, z/OS and hlsl from the list in the clang
sources].

[Bug c++/98202] C++ cannot parse F128 suffix for float128 literals

2023-05-16 Thread jakub at gcc dot gnu.org via Gcc-bugs

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
Other option would be just hardcode those 4 constants by hand:
#define __FLT128_MAX__ 1.18973149535723176508575932662800702e+4932F128
#define __FLT128_NORM_MAX__ 1.18973149535723176508575932662800702e+4932F128
#define __FLT128_MIN__ 3.36210314311209350626267781732175260e-4932F128
#define __FLT128_EPSILON__ 1.92592994438723585305597794258492732e-34F128
#define __FLT128_DENORM_MIN__ 6.47517511943802511092443895822764655e-4966F128
with __extension__ before it and Q suffix instead of F128.  For __float128
I think those constants aren't going to change.
Advantage of doing that would be that even various versions of clang++ support
that,
while F128 suffix isn't supported.
So, use:
(__extension__ 0x1.p+16383Q)
(__extension__ 0x1.p+16383Q)
(__extension__ 0x1.p-16382Q)
(__extension__ 0x1.p-112Q)
(__extension__ 0x0.0001p-16382Q)
instead of those 4 constants.

[Bug libstdc++/43622] Incomplete C++ library support for __float128

2023-05-16 Thread redi at gcc dot gnu.org via Gcc-bugs

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

--- Comment #32 from Jonathan Wakely  ---
Hmm, yes. Well I think we can at least make std::is_integral<__int128> true,
which will remove once source of surprises for users.

[Bug target/104338] RISC-V: Subword atomics result in library calls

2023-05-16 Thread i at rvalue dot moe via Gcc-bugs

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

--- Comment #19 from rvalue  ---
(In reply to Aurelien Jarno from comment #18)
> I wonder if the following patch should also be backported, as it
> doesn't make sense to link with -latomic anymore with inline subword atomic
> operations

Agreed. It's now meaningless to keep this workaround for RISC-V as the problem
has been resolved.

[Bug libstdc++/44015] template parameters not documented

2023-05-16 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #8 from Andrew Pinski  ---
Unassigning since Benjamin since not been active in GCC development for over 8
years now.

[Bug libstdc++/40094] FAIL: ext/throw_allocator/deallocate_global.cc execution test

2023-05-16 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #23 from Andrew Pinski  ---
Unassigning since Benjamin since not been active in GCC development for over 8
years now.

[Bug libstdc++/40380] class documentation should mention include file to use

2023-05-16 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #11 from Andrew Pinski  ---
Unassigning since Benjamin since not been active in GCC development for over 8
years now.

[Bug libstdc++/21772] exception safety testing

2023-05-16 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #24 from Andrew Pinski  ---
Unassigning since Benjamin since not been active in GCC development for over 8
years now.

[Bug libstdc++/9780] issues with time_get, time_put not being tied to correct _punct facet.

2023-05-16 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

   Assignee|bkoz at gcc dot gnu.org|unassigned at gcc dot 
gnu.org

--- Comment #6 from Andrew Pinski  ---
Reassining since Benjamin has not been active in GCC development for a few
years now.

[Bug libstdc++/18571] document wstring/wfilebuf code conversions

2023-05-16 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
Unassigning since Benjamin since not been active in GCC development for over 8
years now.

[Bug libstdc++/5499] True name and named locales

2023-05-16 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
Unassigning since Benjamin since not been active in GCC development for over 8
years now.

[Bug libstdc++/16006] Conversions of numbers in fi_FI.UTF-8 produces incorrect UTF-8

2023-05-16 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #8 from Andrew Pinski  ---
Unassigning since Benjamin since not been active in GCC development for over 8
years now.

1 2 3 4 >

1 - 100 of 301 matches

Mail list logo