[PATCH] ipa-prop: Fix another case of missing BUILT_IN_UNREACHABLE_TRAP handling [PR106258]

[Jakub Jelinek via Gcc-patches]

On Wed, Feb 22, 2023 at 07:46:46PM +0100, Richard Biener wrote:
> Ok for stage1

Thanks.  In that case, can we get at least following into GCC 13,
another spot that handles in IPA just BUILT_IN_UNREACHABLE and
not BUILT_IN_UNREACHABLE_TRAP?

Bootstrapped/regtested on x86_64-linux and i686-linux.

2023-02-23  Jakub Jelinek  

PR middle-end/106258
* ipa-prop.cc (try_make_edge_direct_virtual_call): Handle
BUILT_IN_UNREACHABLE_TRAP like BUILT_IN_UNREACHABLE.

--- gcc/ipa-prop.cc.jj  2023-02-22 20:50:27.422519757 +0100
+++ gcc/ipa-prop.cc 2023-02-22 20:52:04.904112685 +0100
@@ -3850,6 +3850,7 @@ try_make_edge_direct_virtual_call (struc
{
  if (!t
  || fndecl_built_in_p (t, BUILT_IN_UNREACHABLE)
+ || fndecl_built_in_p (t, BUILT_IN_UNREACHABLE_TRAP)
  || !possible_polymorphic_call_target_p
   (ie, cgraph_node::get (t)))
{


Jakub

Re: [PATCH] vect: Check that vector factor is a compile-time constant

[Michael Collison]

Hi Jeff,

We do not have two independent implementations: my work is 100% based on 
the vector intrinsic foundation in upstream GCC. In fact I have only 
added two core patterns, vector add and subtract, that are based on the 
existing vector intrinsics implementation:


(define_expand "add3"
  [(match_operand:VI 0 "register_operand")
   (match_operand:VI 1 "register_operand")
   (match_operand:VI 2 "vector_arith_operand")]
  "TARGET_VECTOR"
{
  using namespace riscv_vector;

  rtx merge = gen_rtx_UNSPEC (mode, gen_rtvec (1, const0_rtx), 
UNSPEC_VUNDEF);

  rtx vl = emit_vlmax_vsetvl (mode);
  rtx mask_policy = get_mask_policy_no_pred();
  rtx tail_policy = get_tail_policy_no_pred();
  rtx mask = CONSTM1_RTX(mode);
  rtx vlmax_avl_p = get_avl_type_rtx(NONVLMAX);

  emit_insn(gen_pred_add(operands[0], mask, merge, operands[1], 
operands[2],

            vl, tail_policy, mask_policy, vlmax_avl_p));

  DONE;
})

This pattern leverages the existing vector intrinsics framework. The 
bulk of the changes are the cost model, and target macros. The cost 
model is based on Juzhe's work.


The point I am making is the auto-vectorization work is no more 
experimental than the intrinsics work which is still being merged.


On 2/22/23 23:01, Jeff Law wrote:



On 2/22/23 10:54, Michael Collison wrote:

Juzhe,

I disagree with this comment. There are many stakeholders for 
autovectorization and waiting until GCC 14 is not a viable solution 
for us as well as other stakeholders ready to begin work on 
autovectorization.


As we discussed I have been moving forward with patches for 
autovectorization and am preparing to send them to gcc-patches. This 
assert is preventing code from compiling and needs to be addressed.


If you have a solution in either the RISCV backend or in this file 
can you please present it?
I don't necessarily think it means waiting for gcc-14, but it does 
mean waiting for gcc-13 to branch and gcc-14 development to open. I 
would object to anyone trying to push forward an autovec 
implementation into gcc-13.  We're well past that point IMHO, even if 
the changes only affected the RISC-V backend.


Given that it looks like we have two independent implementations we're 
almost certainly going to have to sit down with both, evaluate both 
from a quality of code viewpoint and benchmark them both and 
ultimately choose one implementation or the other, or maybe even some 
mixing and matching.


I would strongly suggest that both groups have implementations we can 
start evaluating from a design/implementation standpoint relatively 
soon.  Ideally both groups would actually have branches in the repo 
that are regularly updated with their current implementation.


While I have a great interest in seeing an autovec implementation move 
forward as soon as possible after gcc-14 development opens, I have no 
opinions at this point about either of the two existing implementations.


Jeff

Re: Re: [PATCH] vect: Check that vector factor is a compile-time constant

[juzhe.zh...@rivai.ai]

>> I would object to anyone trying to push forward an autovec implementation 
>> into
>> gcc-13.  We're well past that point IMHO, even if the changes only
>> affected the RISC-V backend.

Yes, I am agree with Jeff's opinion. I finished infrastructure (intrinsic and 
VSETVL PASS) of RVV now.
Now, I am pulling as many resources as possible to do the testing.
From now to April (until GCC 14 is open), I will only keep testing and fix bugs 
or some codes refine && simplification.
I won't push any more features especially autovec until GCC 14 is open.



juzhe.zh...@rivai.ai
 
From: Jeff Law
Date: 2023-02-23 12:01
To: Michael Collison; juzhe.zhong; gcc-patches
CC: kito.cheng; kito.cheng; richard.sandiford; richard.guenther
Subject: Re: [PATCH] vect: Check that vector factor is a compile-time constant
 
 
On 2/22/23 10:54, Michael Collison wrote:
> Juzhe,
> 
> I disagree with this comment. There are many stakeholders for 
> autovectorization and waiting until GCC 14 is not a viable solution for 
> us as well as other stakeholders ready to begin work on autovectorization.
> 
> As we discussed I have been moving forward with patches for 
> autovectorization and am preparing to send them to gcc-patches. This 
> assert is preventing code from compiling and needs to be addressed.
> 
> If you have a solution in either the RISCV backend or in this file can 
> you please present it?
I don't necessarily think it means waiting for gcc-14, but it does mean 
waiting for gcc-13 to branch and gcc-14 development to open.  I would 
object to anyone trying to push forward an autovec implementation into 
gcc-13.  We're well past that point IMHO, even if the changes only 
affected the RISC-V backend.
 
Given that it looks like we have two independent implementations we're 
almost certainly going to have to sit down with both, evaluate both from 
a quality of code viewpoint and benchmark them both and ultimately 
choose one implementation or the other, or maybe even some mixing and 
matching.
 
I would strongly suggest that both groups have implementations we can 
start evaluating from a design/implementation standpoint relatively 
soon.  Ideally both groups would actually have branches in the repo that 
are regularly updated with their current implementation.
 
While I have a great interest in seeing an autovec implementation move 
forward as soon as possible after gcc-14 development opens, I have no 
opinions at this point about either of the two existing implementations.
 
Jeff
 

Re: [PATCH] vect: Check that vector factor is a compile-time constant

[Jeff Law via Gcc-patches]

On 2/22/23 10:54, Michael Collison wrote:

Juzhe,

I disagree with this comment. There are many stakeholders for 
autovectorization and waiting until GCC 14 is not a viable solution for 
us as well as other stakeholders ready to begin work on autovectorization.


As we discussed I have been moving forward with patches for 
autovectorization and am preparing to send them to gcc-patches. This 
assert is preventing code from compiling and needs to be addressed.


If you have a solution in either the RISCV backend or in this file can 
you please present it?
I don't necessarily think it means waiting for gcc-14, but it does mean 
waiting for gcc-13 to branch and gcc-14 development to open.  I would 
object to anyone trying to push forward an autovec implementation into 
gcc-13.  We're well past that point IMHO, even if the changes only 
affected the RISC-V backend.


Given that it looks like we have two independent implementations we're 
almost certainly going to have to sit down with both, evaluate both from 
a quality of code viewpoint and benchmark them both and ultimately 
choose one implementation or the other, or maybe even some mixing and 
matching.


I would strongly suggest that both groups have implementations we can 
start evaluating from a design/implementation standpoint relatively 
soon.  Ideally both groups would actually have branches in the repo that 
are regularly updated with their current implementation.


While I have a great interest in seeing an autovec implementation move 
forward as soon as possible after gcc-14 development opens, I have no 
opinions at this point about either of the two existing implementations.


Jeff

[PATCH 2/2] xtensa: Fix missing mode warnings in machine description

[Takayuki 'January June' Suwa via Gcc-patches]

gcc/ChangeLog:

* config/xtensa/xtensa.md
(zero_cost_loop_start, zero_cost_loop_end, loop_end):
Add missing "SI:" to PLUS RTXes.
---
 gcc/config/xtensa/xtensa.md | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/gcc/config/xtensa/xtensa.md b/gcc/config/xtensa/xtensa.md
index d3996b26cb5..d6116d63ddf 100644
--- a/gcc/config/xtensa/xtensa.md
+++ b/gcc/config/xtensa/xtensa.md
@@ -2028,8 +2028,8 @@
  (label_ref (match_operand 1 "" ""))
  (pc)))
(set (match_operand:SI 0 "register_operand" "=a")
-   (plus (match_dup 0)
- (const_int -1)))
+   (plus:SI (match_dup 0)
+(const_int -1)))
(unspec [(const_int 0)] UNSPEC_LSETUP_START)]
   "TARGET_LOOPS && optimize"
   "loop\t%0, %l1_LEND"
@@ -2044,8 +2044,8 @@
  (label_ref (match_operand 1 "" ""))
  (pc)))
(set (match_operand:SI 0 "nonimmediate_operand" "=a,m")
-   (plus (match_dup 0)
- (const_int -1)))
+   (plus:SI (match_dup 0)
+(const_int -1)))
(unspec [(const_int 0)] UNSPEC_LSETUP_END)
(clobber (match_scratch:SI 3 "=X,"))]
   "TARGET_LOOPS && optimize"
@@ -2061,8 +2061,8 @@
  (label_ref (match_operand 1 "" ""))
  (pc)))
(set (match_operand:SI 0 "register_operand" "=a")
-   (plus (match_dup 0)
- (const_int -1)))
+   (plus:SI (match_dup 0)
+(const_int -1)))
(unspec [(const_int 0)] UNSPEC_LSETUP_END)]
   "TARGET_LOOPS && optimize"
 {
-- 
2.30.2

[PATCH 1/2] xtensa: Fix non-fatal regression introduced by b2ef02e8cbbaf95fee98be255f697f47193960ec

[Takayuki 'January June' Suwa via Gcc-patches]

In commit b2ef02e8cbbaf95fee98be255f697f47193960ec, the sibling call
insn included (use (reg:SI A0_REG)) to fix the problem, which added
a USE chain unconditionally to the data flow of register A0 during
the sibling call.

As a result, df_regs_ever_live_p (A0_REG) returns true, so even if
register A0 is not used outside of the sibling call insn, saves and
restores to stack slots are emitted in pro/epilogue, and finally
code size increases.
(This is why I never included (use A0) in sibling calls)

/* example */
extern int foo(int);
int test(int a) {
  return foo(a * 3 + 1);
}

;; before
test:
addisp, sp, -16 ;; unneeded stack frame allocation (induced)
s32i.n  a0, sp, 12  ;; unneeded saving of register A0
l32i.n  a0, sp, 12  ;; unneeded restoration of register A0
addx2   a2, a2, a2
addi.n  a2, a2, 1
addisp, sp, 16  ;; unneeded stack frame freeing (induced)
j.l foo, a9 ;; sibling call (truly needs register A0)

The essential cause is that we emit (use A0) *before* the insns that
does the stack pointer adjustment during epilogue expansion, so the
liveness of register A0 ends early, so register A0 is reused afterwards.

This patch fixes the problem and avoids such regression by doing the
emit of (use A0) in the sibling call epilogue expansion at the end.

;; after
test:
addx2   a2, a2, a2
addi.n  a2, a2, 1
j.l foo, a9

>From RTL-pass "315r.rnreg" by
"gfortran -O3 -funroll-loops -mabi=call0 -S -da 
gcc-gnu/gcc/testsuite/gfortran.dg/allocate_with_source_5.f90":

;; Function selector_init (__selectors_MOD_selector_init, funcdef_no=2, 
decl_uid=987, cgraph_uid=3, symbol_order=4)
...
(insn 3807 3806 3808 121 (set (reg:SI 15 a15)
(mem/c:SI (plus:SI (reg/f:SI 1 sp)
(const_int 268 [0x10c])) [31  S4 A32])) 
"gcc-gnu/gcc/testsuite/gfortran.dg/allocate_with_source_5.f90":35:30 53 
{movsi_internal}
 (nil))
(insn 3808 3807 3809 121 (set (reg:SI 7 a7)
(const_int 288 [0x120])) 
"gcc-gnu/gcc/testsuite/gfortran.dg/allocate_with_source_5.f90":35:30 53 
{movsi_internal}
 (nil))
(insn 3809 3808 3810 121 (set (reg/f:SI 1 sp)
(plus:SI (reg/f:SI 1 sp)
(reg:SI 7 a7))) 
"gcc-gnu/gcc/testsuite/gfortran.dg/allocate_with_source_5.f90":35:30 1 {addsi3}
 (expr_list:REG_DEAD (reg:SI 9 a9)
(nil)))
(insn 3810 3809 721 121 (use (reg:SI 0 a0)) 
"gcc-gnu/gcc/testsuite/gfortran.dg/allocate_with_source_5.f90":35:30 -1
 (expr_list:REG_DEAD (reg:SI 0 a0)
(nil)))
(call_insn/j 721 3810 722 121 (call (mem:SI (symbol_ref:SI ("free") [flags 
0x41]  ) [0 __builtin_free S4 A32])
(const_int 0 [0])) 
"gcc-gnu/gcc/testsuite/gfortran.dg/allocate_with_source_5.f90":35:30 discrim 1 
106 {sibcall_internal}
 (expr_list:REG_DEAD (reg:SI 2 a2)
(expr_list:REG_CALL_DECL (symbol_ref:SI ("free") [flags 0x41]  
)
(expr_list:REG_EH_REGION (const_int 0 [0])
(nil
(expr_list:SI (use (reg:SI 2 a2))
(nil)))

(IMHO the "rnreg" pass doesn't take REG_ALLOC_ORDER into account;
it just seems to allocate registers in fixed_regs index order,
which may have hurt register A0 that became allocatable in the recent
patch)

gcc/ChangeLog:

* config/xtensa/xtensa.cc (xtensa_expand_epilogue):
Emit (use (reg:SI A0_REG)) at the end in the sibling call
(i.e. the same place as (return) in the normal call).
* config/xtensa/xtensa.md
(sibcall, sibcall_internal, sibcall_value, sibcall_value_internal):
Revert changes by the previous patch.
---
 gcc/config/xtensa/xtensa.cc |  4 +++-
 gcc/config/xtensa/xtensa.md | 20 +++-
 2 files changed, 10 insertions(+), 14 deletions(-)

diff --git a/gcc/config/xtensa/xtensa.cc b/gcc/config/xtensa/xtensa.cc
index 5c1c713e122..b80eef5c19e 100644
--- a/gcc/config/xtensa/xtensa.cc
+++ b/gcc/config/xtensa/xtensa.cc
@@ -3573,7 +3573,9 @@ xtensa_expand_epilogue (bool sibcall_p)
  EH_RETURN_STACKADJ_RTX));
 }
   cfun->machine->epilogue_done = true;
-  if (!sibcall_p)
+  if (sibcall_p)
+emit_use (gen_rtx_REG (SImode, A0_REG));
+  else
 emit_jump_insn (gen_return ());
 }
 
diff --git a/gcc/config/xtensa/xtensa.md b/gcc/config/xtensa/xtensa.md
index b8a8aaf9764..d3996b26cb5 100644
--- a/gcc/config/xtensa/xtensa.md
+++ b/gcc/config/xtensa/xtensa.md
@@ -2369,10 +2369,8 @@
(set_attr "length"  "3")])
 
 (define_expand "sibcall"
-  [(parallel [
-(call (match_operand 0 "memory_operand" "")
- (match_operand 1 "" ""))
-(use (reg:SI A0_REG))])]
+  [(call (match_operand 0 "memory_operand" "")
+(match_operand 1 "" ""))]
   "!TARGET_WINDOWED_ABI"
 {
   xtensa_prepare_expand_call (0, operands);
@@ -2380,8 +2378,7 @@
 
 (define_insn "sibcall_internal"
   [(call (mem:SI 

Re: Ping^2: [PATCH+wwwdocs 0/8] A small Texinfo refinement

[Gerald Pfeifer]

On Tue, 21 Feb 2023, Arsen Arsenović wrote:
> Ping.  Like last time, I rebased the series.

Thank you!

> The first two times around, I did not notice there's dedicated
> maintainers for the documentation component, and so, I am adding Gerald,
> Joseph and Sandra to CC this time.  Apologies for the omission.

Much of this is over my head in terms of texinfo, which is why I had 
to defer when I originally saw it. Sorry for not being explicit about
that originally.

That said, I feel sufficiently confident taking care of 2/8 and 3/8 
(see my earlier replies).

I hope Sandra or Joseph will be able to help with others (especially
1, 5, and 6).

Gerald

Re: [PATCH+wwwdocs 0/8] A small Texinfo refinement

[Gerald Pfeifer]

On Fri, 27 Jan 2023, Arsen Arsenović via Gcc-patches wrote:
> Some patches from this patchset appear to have been dropped due to size
> limits.  I neglected to compress them last night.  Here they are again:

I pushed 2/8 after spot checking the huge patch.

Just 2 out of 970 hunks FAILED (for gcc/doc/invoke.texi). Do you want to 
re-run your script and see what new may have popped up or is missing?

Thanks,
Gerald

Re: [committed 034/103] gccrs: dump: Emit visibility when dumping items

[Gerald Pfeifer]

Just noticed this by chance: 

How does this patch constitute a functional change (that matches the 
ChangeLog)? It looks it only adds an empty line to the source code?

Gerald

On Tue, 21 Feb 2023, arthur.co...@embecosm.com wrote:
> From: Arthur Cohen 
> 
> gcc/rust/ChangeLog:
> 
>   * ast/rust-ast-dump.cc: Emit visibility when dumping items.
> ---
>  gcc/rust/ast/rust-ast-dump.cc | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/gcc/rust/ast/rust-ast-dump.cc b/gcc/rust/ast/rust-ast-dump.cc
> index fdcd97561bb..b7557bdee0c 100644
> --- a/gcc/rust/ast/rust-ast-dump.cc
> +++ b/gcc/rust/ast/rust-ast-dump.cc
> @@ -835,6 +835,7 @@ void
>  Dump::visit (Function )
>  {
>emit_visibility (function.get_visibility ());
> +
>stream << "fn " << function.get_function_name ();
>if (function.has_generics ())
>  emit_generic_params (function.get_generic_params ());

Re: [PATCH 3/7] **/*.texi: Reorder index entries

[Gerald Pfeifer]

Hi Arsen,

On Fri, 27 Jan 2023, Arsen Arsenović via Gcc-patches wrote:
> gcc/d/ChangeLog:
> 
>   * implement-d.texi: Reorder index entries around @items.
> 
> gcc/ChangeLog:
> 
>   * doc/cfg.texi: Reorder index entries around @items.
>   * doc/cpp.texi: Ditto.
>   * doc/cppenv.texi: Ditto.
>   * doc/cppopts.texi: Ditto.
>   * doc/generic.texi: Ditto.
>   * doc/install.texi: Ditto.
>   * doc/invoke.texi: Ditto.
>   * doc/md.texi: Ditto.
>   * doc/rtl.texi: Ditto.
>   * doc/tm.texi: Ditto.
>   * doc/trouble.texi: Ditto.
> 
> gcc/fortran/ChangeLog:
> 
>   * invoke.texi: Reorder index entries around @items.
> 
> gcc/go/ChangeLog:
> 
>   * gccgo.texi: Reorder index entries around @items.

I was going to push this, alas there are now rejects for
fortran/invoke.texi, gcc/doc/invoke.texi and gcc/doc/cppopts.texi.

If you can get me a rebased version I'll give it a try again. (Or
are there some earlier dependencies? I tried to push what I feel
comfortable at this point.)

Gerald

[PATCH] c++: variable template and targ deduction [PR108550]

[Marek Polacek via Gcc-patches]

In this test, we get a bogus error because we failed to deduce the auto in
constexpr auto is_pointer_v = is_pointer::value;
to bool.  Then ensure_literal_type_for_constexpr_object thinks the object
isn't literal and an error is reported.

This is another case of the interaction between tf_partial and 'auto',
where the auto was not reduced so the deduction failed.  In more detail:
we have

  Wrap1()

in the code and we need to perform OR -> fn_type_unification.  The targ
list is incomplete, so we do
  tsubst_flags_t ecomplain = complain | tf_partial | tf_fndecl_type;
  fntype = tsubst (TREE_TYPE (fn), explicit_targs, ecomplain, NULL_TREE);
where TREE_TYPE (fn) is struct integral_constant  (void).  Then
we substitute the return type, which results in tsubsting is_pointer_v.
is_pointer_v is a variable template with a placeholder type:

  template 
  constexpr auto is_pointer_v = is_pointer::value;

so we find ourselves in lookup_and_finish_template_variable.  tf_partial is
still set, so finish_template_variable -> instantiate_template -> tsubst
won't reduce the level of auto.  But then we do mark_used which eventually
calls do_auto_deduction which clears tf_partial, because we want to replace
the auto now.  But we hadn't reduced auto's level so this fails.  And
since we're not in an immediate context, we emit a hard error.

I suppose that when we reach lookup_and_finish_template_variable it's
probably time to clear tf_partial.  (I added an assert and our testsuite
doesn't have a test whereby we get to lookup_and_finish_template_variable
while tf_partial is still active.)

Does this make *any* sense to you?

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

PR c++/108550

gcc/cp/ChangeLog:

* pt.cc (lookup_and_finish_template_variable): Clear tf_partial.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1y/var-templ70.C: New test.
* g++.dg/cpp1y/var-templ71.C: New test.
---
 gcc/cp/pt.cc |  6 ++
 gcc/testsuite/g++.dg/cpp1y/var-templ70.C | 25 +++
 gcc/testsuite/g++.dg/cpp1y/var-templ71.C | 26 
 3 files changed, 57 insertions(+)
 create mode 100644 gcc/testsuite/g++.dg/cpp1y/var-templ70.C
 create mode 100644 gcc/testsuite/g++.dg/cpp1y/var-templ71.C

diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
index 1a071e95004..f636bac5413 100644
--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -10355,6 +10355,12 @@ lookup_and_finish_template_variable (tree templ, tree 
targs,
   if (TMPL_PARMS_DEPTH (DECL_TEMPLATE_PARMS (templ)) == 1
   && !any_dependent_template_arguments_p (targs))
 {
+  /* We may be called while doing a partial substitution, but the
+type of the variable template may be auto, in which case we
+will call do_auto_deduction in mark_used (which clears tf_partial)
+and the auto must be properly reduced at that time for the
+deduction to work.  */
+  complain &= ~tf_partial;
   var = finish_template_variable (var, complain);
   mark_used (var);
 }
diff --git a/gcc/testsuite/g++.dg/cpp1y/var-templ70.C 
b/gcc/testsuite/g++.dg/cpp1y/var-templ70.C
new file mode 100644
index 000..1d35c38c7cc
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1y/var-templ70.C
@@ -0,0 +1,25 @@
+// PR c++/108550
+// { dg-do compile { target c++14 } }
+
+template
+struct is_pointer
+{
+  static constexpr bool value = false;
+};
+
+template
+struct integral_constant
+{
+  static constexpr T value = T1;
+};
+
+
+template 
+constexpr auto is_pointer_v = is_pointer::value;
+
+template 
+integral_constant> Wrap1();
+
+int main() {
+  static_assert(!decltype(Wrap1())::value, "");
+}
diff --git a/gcc/testsuite/g++.dg/cpp1y/var-templ71.C 
b/gcc/testsuite/g++.dg/cpp1y/var-templ71.C
new file mode 100644
index 000..e0cf55230d9
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1y/var-templ71.C
@@ -0,0 +1,26 @@
+// PR c++/108550
+// { dg-do compile { target c++14 } }
+
+template
+struct integral_constant
+{
+  static constexpr T value = T1;
+};
+
+template 
+struct S {
+  template 
+  static constexpr void foo(V) { }
+
+  constexpr bool bar () const { foo(10); return false; }
+};
+
+template 
+constexpr auto is_pointer_v = S{}.bar();
+
+template 
+integral_constant> Wrap1();
+
+int main() {
+  static_assert(!decltype(Wrap1())::value, "");
+}

base-commit: 1370014f2ea02ec185cf1199027575916f79fe63
-- 
2.39.2

Re: Re: [PATCH] vect: Check that vector factor is a compile-time constant

[juzhe.zhong]

Besides, since GCC 13 currently is on stage 4. 
Unlike the infrastructure that I am building for intrinsic && auto-vec which is 
safe and will not affect the original RISC-V port functionality.
Auto-vectorization will potentially affect the orignal RISC-V port 
functionality which is not safe to support in current stage of GCC 13.



juzhe.zh...@rivai.ai
 
From: Michael Collison
Date: 2023-02-23 01:54
To: juzhe.zhong; gcc-patches
CC: kito.cheng; kito.cheng; richard.sandiford; richard.guenther
Subject: Re: [PATCH] vect: Check that vector factor is a compile-time constant
Juzhe,
I disagree with this comment. There are many stakeholders for autovectorization 
and waiting until GCC 14 is not a viable solution for us as well as other 
stakeholders ready to begin work on autovectorization.
As we discussed I have been moving forward with patches for autovectorization 
and am preparing to send them to gcc-patches. This assert is preventing code 
from compiling and needs to be addressed.
If you have a solution in either the RISCV backend or in this file can you 
please present it?
On 2/22/23 10:27, juzhe.zh...@rivai.ai wrote:
> gcc/
>
>  * tree-vect-loop-manip.cc (vect_do_peeling): Verify
>  that vectorization factor is a compile-time constant.
>
> ---
>   gcc/tree-vect-loop-manip.cc | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/gcc/tree-vect-loop-manip.cc b/gcc/tree-vect-loop-manip.cc
> index 6aa3d2ed0bf..1ad1961c788 100644
> --- a/gcc/tree-vect-loop-manip.cc
> +++ b/gcc/tree-vect-loop-manip.cc
> @@ -2930,7 +2930,7 @@ vect_do_peeling (loop_vec_info loop_vinfo, tree
> niters, tree nitersm1,
> niters = vect_build_loop_niters (loop_vinfo, _var_p);
> /* It's guaranteed that vector loop bound before vectorization is at
>least VF, so set range information for newly generated var. */
> -  if (new_var_p)
> +  if (new_var_p && vf.is_constant ())
>   {
> value_range vr (type,
> wi::to_wide (build_int_cst (type, vf)),

I don't think we need to apply this limit in case of RVV auto-vectorization.
I have talked with Kito and I have a full solution of supporting RVV solution.

We are going to support RVV auto-vectorization in 3 configuration according to 
RVV ISA spec:
1. -march=zve32* support QI and HI auto-vectorization by VNx4QImode and 
VNx2HImode
2. -march=zve64* support QI and HI and SI auto-vectorization by VNx8QImode and 
VNx4HImode and VNx2SImode
3. -march=v* support QI and HI and SI and DI auto-vectorization by VNx16QImode 
and VNx8HImode and VNx4SImode and VNx2DImode

I will support them in GCC 14. Current loop vectorizer works well for us no 
need to fix it. 
Thanks.


juzhe.zh...@rivai.ai

Re: Re: [PATCH] vect: Check that vector factor is a compile-time constant

[juzhe.zhong]

Currently, upstream GCC is not ready to support auto-vec.
I am building the basic infrastructure of RVV and need more testing.
I can't support auto-vec now since it depends on the infrastructure tha I am 
building.
I have open source "rvv-next" in RISC-V foundation repo which fully support 
intrinsic && auto-vec.
You can either wait for the upstream GCC or develop base rvv-next.



juzhe.zh...@rivai.ai
 
From: Michael Collison
Date: 2023-02-23 01:54
To: juzhe.zhong; gcc-patches
CC: kito.cheng; kito.cheng; richard.sandiford; richard.guenther
Subject: Re: [PATCH] vect: Check that vector factor is a compile-time constant
Juzhe,
I disagree with this comment. There are many stakeholders for autovectorization 
and waiting until GCC 14 is not a viable solution for us as well as other 
stakeholders ready to begin work on autovectorization.
As we discussed I have been moving forward with patches for autovectorization 
and am preparing to send them to gcc-patches. This assert is preventing code 
from compiling and needs to be addressed.
If you have a solution in either the RISCV backend or in this file can you 
please present it?
On 2/22/23 10:27, juzhe.zh...@rivai.ai wrote:
> gcc/
>
>  * tree-vect-loop-manip.cc (vect_do_peeling): Verify
>  that vectorization factor is a compile-time constant.
>
> ---
>   gcc/tree-vect-loop-manip.cc | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/gcc/tree-vect-loop-manip.cc b/gcc/tree-vect-loop-manip.cc
> index 6aa3d2ed0bf..1ad1961c788 100644
> --- a/gcc/tree-vect-loop-manip.cc
> +++ b/gcc/tree-vect-loop-manip.cc
> @@ -2930,7 +2930,7 @@ vect_do_peeling (loop_vec_info loop_vinfo, tree
> niters, tree nitersm1,
> niters = vect_build_loop_niters (loop_vinfo, _var_p);
> /* It's guaranteed that vector loop bound before vectorization is at
>least VF, so set range information for newly generated var. */
> -  if (new_var_p)
> +  if (new_var_p && vf.is_constant ())
>   {
> value_range vr (type,
> wi::to_wide (build_int_cst (type, vf)),

I don't think we need to apply this limit in case of RVV auto-vectorization.
I have talked with Kito and I have a full solution of supporting RVV solution.

We are going to support RVV auto-vectorization in 3 configuration according to 
RVV ISA spec:
1. -march=zve32* support QI and HI auto-vectorization by VNx4QImode and 
VNx2HImode
2. -march=zve64* support QI and HI and SI auto-vectorization by VNx8QImode and 
VNx4HImode and VNx2SImode
3. -march=v* support QI and HI and SI and DI auto-vectorization by VNx16QImode 
and VNx8HImode and VNx4SImode and VNx2DImode

I will support them in GCC 14. Current loop vectorizer works well for us no 
need to fix it. 
Thanks.


juzhe.zh...@rivai.ai

Re: [wwwdocs, patch] OpenMP update for gcc-13/changes.html + projects/gomp/

[Gerald Pfeifer]

On Wed, 22 Feb 2023, Tobias Burnus wrote:
> Comments? Suggestions?

OpenMP update for gcc-13/changes.html + projects/gomp/


--- a/htdocs/gcc-13/changes.html
+++ b/htdocs/gcc-13/changes.html
+  Reverse offload is now supported with nvptx and AMD GCN devices.

Would it make sense to sort AMD GCN and nvptx alphabetically (and in turn 
switch the order)?


>From a wwwdocs perspective the changes look fine.

Thanks,
Gerald

[pushed] wwwdocs: gcc-9: Various changes around -flive-patching

[Gerald Pfeifer]

This is on top of what Qing nicely added back in 2018 - backlog on my 
disk.

Pushed.

Gerald
---
 htdocs/gcc-9/changes.html | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/htdocs/gcc-9/changes.html b/htdocs/gcc-9/changes.html
index 7dfae89c..89c20985 100644
--- a/htdocs/gcc-9/changes.html
+++ b/htdocs/gcc-9/changes.html
@@ -101,10 +101,10 @@ You may also want to check out our
   Invoking GCC for more.
   
   
-A new option, https://gcc.gnu.org/onlinedocs/gcc-9.1.0/gcc/Optimize-Options.html#index-flive-patching;>-flive-patching=[inline-only-static|inline-clone]
 wwwdocs:, has been
-introduced to provide a safe compilation for live-patching. At the same
-time, provides multiple-level control on the enabled IPA optimizations.
-See the user guide for more details about the option.
+A new option https://gcc.gnu.org/onlinedocs/gcc-9.1.0/gcc/Optimize-Options.html#index-flive-patching;>-flive-patching=[inline-only-static|inline-clone]
 wwwdocs:
+generates code suitable for live patching. At the same
+time it provides multiple-level control over IPA optimizations.
+See the user guide for more details.
   
   
   A new option, --completion, has been added to provide more 
fine
-- 
2.39.1

Re: [PATCH] c-family: avoid compile-time-hog in c_genericize [PR108880]

[Jakub Jelinek via Gcc-patches]

On Wed, Feb 22, 2023 at 05:37:45PM -0500, Marek Polacek wrote:
> This fixes a compile-time hog with UBSan.  This only happened in cc1 but
> not cc1plus.  The problem is ultimately that c_genericize_control_stmt/
> STATEMENT_LIST -> walk_tree_1 doesn't use a hash_set to remember visited
> nodes, so it kept on recursing for a long time.  We should be able to
> use the pset that c_genericize created.  We just need to use walk_tree
> instead of walk_tree_w_d so that the pset is explicit.
> 
> Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> 
>   PR c/108880
> 
> gcc/c-family/ChangeLog:
> 
>   * c-gimplify.cc (c_genericize_control_stmt) : Pass
>   pset to walk_tree_1.
>   (c_genericize): Call walk_tree with an explicit pset.
> 
> gcc/testsuite/ChangeLog:
> 
>   * c-c++-common/ubsan/pr108880.c: New test.

Ok, thanks.

Jakub

[PATCH] c-family: avoid compile-time-hog in c_genericize [PR108880]

[Marek Polacek via Gcc-patches]

This fixes a compile-time hog with UBSan.  This only happened in cc1 but
not cc1plus.  The problem is ultimately that c_genericize_control_stmt/
STATEMENT_LIST -> walk_tree_1 doesn't use a hash_set to remember visited
nodes, so it kept on recursing for a long time.  We should be able to
use the pset that c_genericize created.  We just need to use walk_tree
instead of walk_tree_w_d so that the pset is explicit.

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

PR c/108880

gcc/c-family/ChangeLog:

* c-gimplify.cc (c_genericize_control_stmt) : Pass
pset to walk_tree_1.
(c_genericize): Call walk_tree with an explicit pset.

gcc/testsuite/ChangeLog:

* c-c++-common/ubsan/pr108880.c: New test.
---
 gcc/c-family/c-gimplify.cc  | 10 +++---
 gcc/testsuite/c-c++-common/ubsan/pr108880.c | 13 +
 2 files changed, 20 insertions(+), 3 deletions(-)
 create mode 100644 gcc/testsuite/c-c++-common/ubsan/pr108880.c

diff --git a/gcc/c-family/c-gimplify.cc b/gcc/c-family/c-gimplify.cc
index b57546ad7a0..74b276b2b26 100644
--- a/gcc/c-family/c-gimplify.cc
+++ b/gcc/c-family/c-gimplify.cc
@@ -511,12 +511,15 @@ c_genericize_control_stmt (tree *stmt_p, int 
*walk_subtrees, void *data,
 STATEMENT_LIST wouldn't be present at all the resulting
 expression wouldn't have TREE_SIDE_EFFECTS set, so make sure
 to clear it even on the STATEMENT_LIST in such cases.  */
+ hash_set *pset = (c_dialect_cxx ()
+ ? nullptr
+ : static_cast *>(data));
  for (i = tsi_start (stmt); !tsi_end_p (i); tsi_next ())
{
  tree t = tsi_stmt (i);
  if (TREE_CODE (t) != DEBUG_BEGIN_STMT && nondebug_stmts < 2)
nondebug_stmts++;
- walk_tree_1 (tsi_stmt_ptr (i), func, data, NULL, lh);
+ walk_tree_1 (tsi_stmt_ptr (i), func, data, pset, lh);
  if (TREE_CODE (t) != DEBUG_BEGIN_STMT
  && (nondebug_stmts > 1 || TREE_SIDE_EFFECTS (tsi_stmt (i
clear_side_effects = false;
@@ -572,8 +575,9 @@ c_genericize (tree fndecl)
   bc_state_t save_state;
   push_cfun (DECL_STRUCT_FUNCTION (fndecl));
   save_bc_state (_state);
-  walk_tree_without_duplicates (_SAVED_TREE (fndecl),
-   c_genericize_control_r, NULL);
+  hash_set pset;
+  walk_tree (_SAVED_TREE (fndecl), c_genericize_control_r, ,
+);
   restore_bc_state (_state);
   pop_cfun ();
 }
diff --git a/gcc/testsuite/c-c++-common/ubsan/pr108880.c 
b/gcc/testsuite/c-c++-common/ubsan/pr108880.c
new file mode 100644
index 000..7d589edcd12
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/ubsan/pr108880.c
@@ -0,0 +1,13 @@
+/* PR c/108880 */
+/* { dg-do compile } */
+/* { dg-options "-fsanitize=undefined" } */
+
+long a;
+short b, e;
+char c;
+int d, f, g;
+void h() {
+  int i;
+  f &= i ^= (((g &= 0 / d / d % 8 << 0 << 2) % a >> e) / c >> b) / 1 % 8 << 3;
+}
+int main() {}

base-commit: 31303c9b5bab200754cdb7ef8cd91ae4918f3018
-- 
2.39.2

Re: [PR100127] Test for coroutine header in clang-compatible tests

[Alexandre Oliva via Gcc-patches]

On Feb 17, 2023, Iain Sandoe  wrote:

> As a matter of interest, do you know of any other compiler claiming 
> “__clang__” (I have
> treated that as safe so far).

We've had (or found it more convenient, not sure) to do that to gcc on
some recent combinations of version and target of vxworks, for one.

>> Use a __has_include feature test instead.

> I think we need to do

> #if __has_include()
> …
> #elif __has_include()
> …

> because newer clang has the include in the standard place.

That would change what gets tested with clang, I suppose, but I hope
that's for the better.  I wondered what to do at the #else above, and
decided to spell it a little differently.  Retested on x86_64-linux-gnu
(trunk) and arm-vxworks7r2 (gcc-12), ok to install?


[PR100127] Test for coroutine header in clang-compatible tests

From: Alexandre Oliva 

The test is compatible with clang as well as gcc, but ISTM that
testing for the __clang__ macro is just as potentially error-prone as
macros that used to be GCC-specific are now defined in compilers that
aim for GCC compatibility.  Use a __has_include feature test instead.


for  gcc/testsuite/ChangeLog

PR c++/100127
* g++.dg/coroutines/pr100127.C: Test for header rather than
compiler macro.
---
 gcc/testsuite/g++.dg/coroutines/pr100127.C   |3 ++-
 gcc/testsuite/g++.dg/coroutines/pr100772-a.C |3 ++-
 gcc/testsuite/g++.dg/coroutines/pr100772-b.C |3 ++-
 3 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/gcc/testsuite/g++.dg/coroutines/pr100127.C 
b/gcc/testsuite/g++.dg/coroutines/pr100127.C
index 374cd710077af..5879fd0bcc595 100644
--- a/gcc/testsuite/g++.dg/coroutines/pr100127.C
+++ b/gcc/testsuite/g++.dg/coroutines/pr100127.C
@@ -1,4 +1,5 @@
-#ifdef __clang__
+#if !__has_include() \
+  && __has_include() // for __clang__
 #include 
 namespace std {
   using namespace std::experimental;
diff --git a/gcc/testsuite/g++.dg/coroutines/pr100772-a.C 
b/gcc/testsuite/g++.dg/coroutines/pr100772-a.C
index a325d384fc390..06e705b0c65a0 100644
--- a/gcc/testsuite/g++.dg/coroutines/pr100772-a.C
+++ b/gcc/testsuite/g++.dg/coroutines/pr100772-a.C
@@ -1,5 +1,6 @@
 //  { dg-additional-options "-fsyntax-only " }
-#ifdef __clang__
+#if !__has_include() \
+  && __has_include() // for __clang__
 #include 
 namespace std {
   using namespace std::experimental;
diff --git a/gcc/testsuite/g++.dg/coroutines/pr100772-b.C 
b/gcc/testsuite/g++.dg/coroutines/pr100772-b.C
index 6cdf8d1e529e5..4ef80a9959490 100644
--- a/gcc/testsuite/g++.dg/coroutines/pr100772-b.C
+++ b/gcc/testsuite/g++.dg/coroutines/pr100772-b.C
@@ -1,4 +1,5 @@
-#ifdef __clang__
+#if !__has_include() \
+  && __has_include() // for __clang__
 #include 
 namespace std {
   using namespace std::experimental;


-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

Re: C++ modules and AAPCS/ARM EABI clash on inline key methods

[Alexandre Oliva via Gcc-patches]

On Feb 21, 2023, Richard Earnshaw  wrote:

> Rather than scanning for the triplet, a better test would be

> { xfail { arm_eabi } }

Indeed, thanks.  Here's the updated patch, retested.  Ok to install?


[PR105224] C++ modules and AAPCS/ARM EABI clash on inline key methods

From: Alexandre Oliva 

g++.dg/modules/virt-2_a.C fails on arm-eabi and many other arm targets
that use the AAPCS variant.  ARM is the only target that overrides
TARGET_CXX_KEY_METHOD_MAY_BE_INLINE.  It's not clear to me which way
the clash between AAPCS and C++ Modules design should be resolved, but
currently it favors AAPCS and thus the test fails.

Skipping the test or conditionally dropping the inline keyword breaks
subsequent tests, so I'm XFAILing the expectation that vtable and rtti
symbols are output on arm_eabi targets.


for  gcc/testsuite/ChangeLog

PR c++/105224
* g++.dg/modules/virt-2_a.C: XFAIL syms on arm_eabi.
---
 gcc/testsuite/g++.dg/modules/virt-2_a.C |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/gcc/testsuite/g++.dg/modules/virt-2_a.C 
b/gcc/testsuite/g++.dg/modules/virt-2_a.C
index 580552be5a0d8..f5d68878f50fb 100644
--- a/gcc/testsuite/g++.dg/modules/virt-2_a.C
+++ b/gcc/testsuite/g++.dg/modules/virt-2_a.C
@@ -22,6 +22,6 @@ export int Visit (Visitor *v)
 }
 
 // Emit here
-// { dg-final { scan-assembler {_ZTVW3foo7Visitor:} } }
-// { dg-final { scan-assembler {_ZTIW3foo7Visitor:} } }
-// { dg-final { scan-assembler {_ZTSW3foo7Visitor:} } }
+// { dg-final { scan-assembler {_ZTVW3foo7Visitor:} { xfail { arm_eabi } } } }
+// { dg-final { scan-assembler {_ZTIW3foo7Visitor:} { xfail { arm_eabi } } } }
+// { dg-final { scan-assembler {_ZTSW3foo7Visitor:} { xfail { arm_eabi } } } }


-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

[PATCH] c++: unevaluated array new-expr size constantness [PR108219]

[Patrick Palka via Gcc-patches]

Here we're mishandling the unevaluated array new-expressions due to a
supposed non-constant array size ever since r12-5253-g4df7f8c79835d569,
made us no longer perform constant evaluation of non-manifestly-constant
expressions within unevaluated contexts.  This shouldn't make a
difference here since the array sizes are constant literals, except
they're actually NON_LVALUE_EXPR location wrappers wrapping INTEGER_CST,
wrappers which used to get stripped as part of constant evaluation and
now no longer do.  Moreover it means build_vec_init can't constant fold
the 'maxindex' passed from build_new_1 (since it uses maybe_constant_value
with mce_unknown).

This patch fixes the first issue by making maybe_constant_value and
fold_non_dependent_expr_template shortcut handling location wrappers
around constant nodes, and the second issue by using fold_build2_loc
instead of cp_build_binary_op when computing the maxindex to pass to
build_vec_init.

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk/12?

PR c++/108219
PR c++/108218

gcc/cp/ChangeLog:

* constexpr.cc (maybe_constant_value): Extend the constant node
shortcut to look through location wrappers too.
(fold_non_dependent_expr_template): Mirror the constant node
shortcut from maybe_constant_value.
* init.cc (build_new_1): Use fold_build2_loc instead
of cp_build_binary_op to build a MINUS_EXPR representing the
maximum index.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/new6.C: New test.
* g++.dg/cpp2a/concepts-new1.C: New test.
---
 gcc/cp/constexpr.cc|  8 ++--
 gcc/cp/init.cc | 18 --
 gcc/testsuite/g++.dg/cpp0x/new6.C  |  9 +
 gcc/testsuite/g++.dg/cpp2a/concepts-new1.C | 13 +
 4 files changed, 36 insertions(+), 12 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/new6.C
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-new1.C

diff --git a/gcc/cp/constexpr.cc b/gcc/cp/constexpr.cc
index aa2c14355f8..d38c4c80415 100644
--- a/gcc/cp/constexpr.cc
+++ b/gcc/cp/constexpr.cc
@@ -8538,9 +8538,9 @@ maybe_constant_value (tree t, tree decl /* = NULL_TREE */,
t = mark_non_constant (t);
   return t;
 }
-  else if (CONSTANT_CLASS_P (t))
+  else if (CONSTANT_CLASS_OR_WRAPPER_P (t))
 /* No caching or evaluation needed.  */
-return t;
+return tree_strip_any_location_wrapper (t);
 
   if (manifestly_const_eval != mce_unknown)
 return cxx_eval_outermost_constant_expr (t, true, true,
@@ -8631,6 +8631,10 @@ fold_non_dependent_expr_template (tree t, tsubst_flags_t 
complain,
  return t;
}
 
+  if (CONSTANT_CLASS_OR_WRAPPER_P (t))
+   /* No evaluation needed.  */
+   return tree_strip_any_location_wrapper (t);
+
   if (cp_unevaluated_operand && !manifestly_const_eval)
return t;
 
diff --git a/gcc/cp/init.cc b/gcc/cp/init.cc
index 705a5b3bdb6..574d2e2586c 100644
--- a/gcc/cp/init.cc
+++ b/gcc/cp/init.cc
@@ -3653,16 +3653,14 @@ build_new_1 (vec **placement, tree type, 
tree nelts,
 error ("parenthesized initializer in array new");
  return error_mark_node;
 }
- init_expr
-   = build_vec_init (data_addr,
- cp_build_binary_op (input_location,
- MINUS_EXPR, outer_nelts,
- integer_one_node,
- complain),
- vecinit,
- explicit_value_init_p,
- /*from_array=*/0,
-  complain);
+ tree maxindex = fold_build2_loc (input_location, MINUS_EXPR,
+  TREE_TYPE (outer_nelts),
+  outer_nelts,
+  build_one_cst (TREE_TYPE
+ (outer_nelts)));
+ init_expr = build_vec_init (data_addr, maxindex, vecinit,
+ explicit_value_init_p, /*from_array=*/0,
+ complain);
}
   else
{
diff --git a/gcc/testsuite/g++.dg/cpp0x/new6.C 
b/gcc/testsuite/g++.dg/cpp0x/new6.C
new file mode 100644
index 000..17a669b42d0
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/new6.C
@@ -0,0 +1,9 @@
+// PR c++/108218
+// { dg-do compile { target c++11 } }
+
+template
+void f() {
+  decltype(new int[-1]) p; // { dg-error "negative" }
+}
+
+decltype(new int[-1]) q; // { dg-error "negative" }
diff --git a/gcc/testsuite/g++.dg/cpp2a/concepts-new1.C 
b/gcc/testsuite/g++.dg/cpp2a/concepts-new1.C
new file mode 100644
index 000..62007205108
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/concepts-new1.C
@@ -0,0 +1,13 @@
+// PR 

Re: [PATCH] tree, v2: Add 3 argument fndecl_built_in_p

[Richard Biener via Gcc-patches]

> Am 22.02.2023 um 19:34 schrieb Jakub Jelinek :
> 
> On Wed, Feb 22, 2023 at 12:35:24PM +, Jonathan Wakely wrote:
>> Yes, I was right, it doesn't work in gcc 4.8. This does though (with
>> typos above fixed too, and actually tested on GCC 4.8.5):
> 
> I think we don't need the DECL_FUNCTION_CODE (node) in every recursive call,
> we can just pass DECL_FUNCTION_CODE (node) down instead.
> 
> The following patch does that, tested again also with gcc 4.8:

Ok for stage1

Thanks,
Richard 

> 2023-02-22  Jakub Jelinek  
>Jonathan Wakely  
> 
>* tree.h (built_in_function_equal_p): New helper function.
>(fndecl_built_in_p): Turn into variadic template to support
>1 or more built_in_function arguments.
>* builtins.cc (fold_builtin_expect): Use 3 argument fndecl_built_in_p.
>* gimplify.cc (goa_stabilize_expr): Likewise.
>* cgraphclones.cc (cgraph_node::create_clone): Likewise.
>* ipa-fnsummary.cc (compute_fn_summary): Likewise.
>* omp-low.cc (setjmp_or_longjmp_p): Likewise.
>* cgraph.cc (cgraph_edge::redirect_call_stmt_to_callee,
>cgraph_update_edges_for_call_stmt_node,
>cgraph_edge::verify_corresponds_to_fndecl,
>cgraph_node::verify_node): Likewise.
>* tree-stdarg.cc (optimize_va_list_gpr_fpr_size): Likewise.
>* gimple-ssa-warn-access.cc (matching_alloc_calls_p): Likewise.
>* ipa-prop.cc (try_make_edge_direct_virtual_call): Handle
>BUILT_IN_UNREACHABLE_TRAP like BUILT_IN_UNREACHABLE.
> 
> --- gcc/tree.h.jj2023-02-17 12:45:08.223636043 +0100
> +++ gcc/tree.h2023-02-22 17:10:57.410410020 +0100
> @@ -6575,6 +6575,24 @@ type_has_mode_precision_p (const_tree t)
>   return known_eq (TYPE_PRECISION (t), GET_MODE_PRECISION (TYPE_MODE (t)));
> }
> 
> +/* Helper functions for fndecl_built_in_p.  */
> +
> +inline bool
> +built_in_function_equal_p (built_in_function name0, built_in_function name1)
> +{
> + return name0 == name1;
> +}
> +
> +/* Recursive case for two or more names.  */
> +
> +template 
> +inline bool
> +built_in_function_equal_p (built_in_function name0, built_in_function name1,
> +   built_in_function name2, F... names)
> +{
> + return name0 == name1 || built_in_function_equal_p (name0, name2, names...);
> +}
> +
> /* Return true if a FUNCTION_DECL NODE is a GCC built-in function.
> 
>Note that it is different from the DECL_IS_UNDECLARED_BUILTIN
> @@ -6606,13 +6624,16 @@ fndecl_built_in_p (const_tree node, unsi
> }
> 
> /* Return true if a FUNCTION_DECL NODE is a GCC built-in function
> -   of BUILT_IN_NORMAL class with name equal to NAME.  */
> +   of BUILT_IN_NORMAL class with name equal to NAME1 (or other mentioned
> +   NAMES).  */
> 
> +template 
> inline bool
> -fndecl_built_in_p (const_tree node, built_in_function name)
> +fndecl_built_in_p (const_tree node, built_in_function name1, F... names)
> {
>   return (fndecl_built_in_p (node, BUILT_IN_NORMAL)
> -  && DECL_FUNCTION_CODE (node) == name);
> +  && built_in_function_equal_p (DECL_FUNCTION_CODE (node),
> +name1, names...));
> }
> 
> /* A struct for encapsulating location information about an operator
> --- gcc/builtins.cc.jj2023-02-14 12:09:57.163647987 +0100
> +++ gcc/builtins.cc2023-02-22 11:29:43.800179949 +0100
> @@ -8625,8 +8625,8 @@ fold_builtin_expect (location_t loc, tre
> 
>   if (TREE_CODE (inner) == CALL_EXPR
>   && (fndecl = get_callee_fndecl (inner))
> -  && (fndecl_built_in_p (fndecl, BUILT_IN_EXPECT)
> -  || fndecl_built_in_p (fndecl, BUILT_IN_EXPECT_WITH_PROBABILITY)))
> +  && fndecl_built_in_p (fndecl, BUILT_IN_EXPECT,
> +BUILT_IN_EXPECT_WITH_PROBABILITY))
> return arg0;
> 
>   inner = inner_arg0;
> --- gcc/gimplify.cc.jj2023-02-15 09:23:27.807390189 +0100
> +++ gcc/gimplify.cc2023-02-22 11:32:38.446655528 +0100
> @@ -15815,8 +15815,8 @@ goa_stabilize_expr (tree *expr_p, gimple
>   if (TREE_CODE (expr) == CALL_EXPR)
>{
>  if (tree fndecl = get_callee_fndecl (expr))
> -if (fndecl_built_in_p (fndecl, BUILT_IN_CLEAR_PADDING)
> -|| fndecl_built_in_p (fndecl, BUILT_IN_MEMCMP))
> +if (fndecl_built_in_p (fndecl, BUILT_IN_CLEAR_PADDING,
> +   BUILT_IN_MEMCMP))
>  {
>int nargs = call_expr_nargs (expr);
>for (int i = 0; i < nargs; i++)
> --- gcc/cgraphclones.cc.jj2023-02-22 11:21:56.467934980 +0100
> +++ gcc/cgraphclones.cc2023-02-22 11:28:30.272242754 +0100
> @@ -425,9 +425,8 @@ cgraph_node::create_clone (tree new_decl
> version.  The only exception is when the edge was proved to
> be unreachable during the cloning procedure.  */
>   if (!e->callee
> -  || !(fndecl_built_in_p (e->callee->decl, BUILT_IN_UNREACHABLE)
> -   || fndecl_built_in_p (e->callee->decl,
> - BUILT_IN_UNREACHABLE_TRAP)))
> +  || !fndecl_built_in_p (e->callee->decl, BUILT_IN_UNREACHABLE,
> +  BUILT_IN_UNREACHABLE_TRAP))
> 

Re: [PATCH 1/2]middle-end: Fix wrong overmatching of div-bitmask by using new optabs [PR108583]

[Andrew MacLeod via Gcc-patches]

On 2/22/23 13:03, Tamar Christina wrote:

-Original Message-
From: Andrew MacLeod 
Sent: Wednesday, February 22, 2023 4:42 PM
To: Tamar Christina ; Richard Biener
; Richard Sandiford 
Cc: Tamar Christina via Gcc-patches ; nd
; j...@ventanamicro.com
Subject: Re: [PATCH 1/2]middle-end: Fix wrong overmatching of div-bitmask
by using new optabs [PR108583]


On 2/15/23 13:42, Andrew MacLeod wrote:

On 2/15/23 12:50, Andrew MacLeod wrote:

On 2/15/23 12:13, Tamar Christina wrote:

On 2/15/23 07:51, Tamar Christina wrote:

void
operator_plus::wi_fold (irange , tree type,
     const wide_int _lb, const wide_int _ub,
     const wide_int _lb, const wide_int _ub)
const {
   wi::overflow_type ov_lb, ov_ub;
   signop s = TYPE_SIGN (type);

   // Do whatever wideint magic is required to do this adds in higher
precision
   wide_int new_lb = wi::add (lh_lb, rh_lb, s, _lb);
   wide_int new_ub = wi::add (lh_ub, rh_ub, s, _ub);

   r = int_range<2> (type, new_lb, new_ub); }


The operator needs to be registered, I've attached the skeleton for
it.  you should just have to finish implementing wi_fold().

in theory :-)


You also mentioned earlier that some were tree codes, some were
internal function calls?  We have some initial support for built in
functions, but I am not familiar with all the various forms they can
take.  We currently support CFN_ functions in

   gimple-range-op.cc, gimple_range_op_handler::maybe_builtin_call ()

Basically this is part of a "gimple_range_op_handler"  wrapper for
range-ops which can provide a range-ops class for stmts that don't map
to a binary or unary form.. such as built in functions.

If you get to the point where you need this for a builtin function, I
can help you through that too.  Although someone may have to also help
me through what differentiates the different kinds of internal
function :-)    I presume they are all similar in some way.

Andrew


Oh yeah, and in case you haven't figured it out on your own, you'll have
to remove WIDEN_MULT_EXPR from the range-ops init table.   This
non-standard mechanism only gets checked if there is no standard
range-op table entry for the tree code :-P


Hmm it looks like it'll work, but it keeps segfaulting in:

bool
range_op_handler::fold_range (vrange , tree type,
  const vrange ,
  const vrange ,
  relation_trio rel) const
{
   gcc_checking_assert (m_valid);
   if (m_int)
 return m_int->fold_range (as_a  (r), type,
   as_a  (lh),
   as_a  (rh), rel);

while trying to call fold_range.

But m_int is set to the right instance. Probably something I'm missing,
I'll double check it all.

Hmm.  whats your class operator_widen_mult* look like? what are you 
inheriting from?   Send me your patch and I'll have a look if you want.  
this is somewhat  new territory :-)


I cant imagine it being a linkage thing between the 2 files since the 
operator is defined in another file and the address taken in this one? 
that should work, but strange that cant make the call...


Andrew

[PATCH] tree, v2: Add 3 argument fndecl_built_in_p

[Jakub Jelinek via Gcc-patches]

On Wed, Feb 22, 2023 at 12:35:24PM +, Jonathan Wakely wrote:
> Yes, I was right, it doesn't work in gcc 4.8. This does though (with
> typos above fixed too, and actually tested on GCC 4.8.5):

I think we don't need the DECL_FUNCTION_CODE (node) in every recursive call,
we can just pass DECL_FUNCTION_CODE (node) down instead.

The following patch does that, tested again also with gcc 4.8:

2023-02-22  Jakub Jelinek  
Jonathan Wakely  

* tree.h (built_in_function_equal_p): New helper function.
(fndecl_built_in_p): Turn into variadic template to support
1 or more built_in_function arguments.
* builtins.cc (fold_builtin_expect): Use 3 argument fndecl_built_in_p.
* gimplify.cc (goa_stabilize_expr): Likewise.
* cgraphclones.cc (cgraph_node::create_clone): Likewise.
* ipa-fnsummary.cc (compute_fn_summary): Likewise.
* omp-low.cc (setjmp_or_longjmp_p): Likewise.
* cgraph.cc (cgraph_edge::redirect_call_stmt_to_callee,
cgraph_update_edges_for_call_stmt_node,
cgraph_edge::verify_corresponds_to_fndecl,
cgraph_node::verify_node): Likewise.
* tree-stdarg.cc (optimize_va_list_gpr_fpr_size): Likewise.
* gimple-ssa-warn-access.cc (matching_alloc_calls_p): Likewise.
* ipa-prop.cc (try_make_edge_direct_virtual_call): Handle
BUILT_IN_UNREACHABLE_TRAP like BUILT_IN_UNREACHABLE.

--- gcc/tree.h.jj   2023-02-17 12:45:08.223636043 +0100
+++ gcc/tree.h  2023-02-22 17:10:57.410410020 +0100
@@ -6575,6 +6575,24 @@ type_has_mode_precision_p (const_tree t)
   return known_eq (TYPE_PRECISION (t), GET_MODE_PRECISION (TYPE_MODE (t)));
 }
 
+/* Helper functions for fndecl_built_in_p.  */
+
+inline bool
+built_in_function_equal_p (built_in_function name0, built_in_function name1)
+{
+ return name0 == name1;
+}
+
+/* Recursive case for two or more names.  */
+
+template 
+inline bool
+built_in_function_equal_p (built_in_function name0, built_in_function name1,
+  built_in_function name2, F... names)
+{
+ return name0 == name1 || built_in_function_equal_p (name0, name2, names...);
+}
+
 /* Return true if a FUNCTION_DECL NODE is a GCC built-in function.
 
Note that it is different from the DECL_IS_UNDECLARED_BUILTIN
@@ -6606,13 +6624,16 @@ fndecl_built_in_p (const_tree node, unsi
 }
 
 /* Return true if a FUNCTION_DECL NODE is a GCC built-in function
-   of BUILT_IN_NORMAL class with name equal to NAME.  */
+   of BUILT_IN_NORMAL class with name equal to NAME1 (or other mentioned
+   NAMES).  */
 
+template 
 inline bool
-fndecl_built_in_p (const_tree node, built_in_function name)
+fndecl_built_in_p (const_tree node, built_in_function name1, F... names)
 {
   return (fndecl_built_in_p (node, BUILT_IN_NORMAL)
- && DECL_FUNCTION_CODE (node) == name);
+ && built_in_function_equal_p (DECL_FUNCTION_CODE (node),
+   name1, names...));
 }
 
 /* A struct for encapsulating location information about an operator
--- gcc/builtins.cc.jj  2023-02-14 12:09:57.163647987 +0100
+++ gcc/builtins.cc 2023-02-22 11:29:43.800179949 +0100
@@ -8625,8 +8625,8 @@ fold_builtin_expect (location_t loc, tre
 
   if (TREE_CODE (inner) == CALL_EXPR
   && (fndecl = get_callee_fndecl (inner))
-  && (fndecl_built_in_p (fndecl, BUILT_IN_EXPECT)
- || fndecl_built_in_p (fndecl, BUILT_IN_EXPECT_WITH_PROBABILITY)))
+  && fndecl_built_in_p (fndecl, BUILT_IN_EXPECT,
+   BUILT_IN_EXPECT_WITH_PROBABILITY))
 return arg0;
 
   inner = inner_arg0;
--- gcc/gimplify.cc.jj  2023-02-15 09:23:27.807390189 +0100
+++ gcc/gimplify.cc 2023-02-22 11:32:38.446655528 +0100
@@ -15815,8 +15815,8 @@ goa_stabilize_expr (tree *expr_p, gimple
   if (TREE_CODE (expr) == CALL_EXPR)
{
  if (tree fndecl = get_callee_fndecl (expr))
-   if (fndecl_built_in_p (fndecl, BUILT_IN_CLEAR_PADDING)
-   || fndecl_built_in_p (fndecl, BUILT_IN_MEMCMP))
+   if (fndecl_built_in_p (fndecl, BUILT_IN_CLEAR_PADDING,
+  BUILT_IN_MEMCMP))
  {
int nargs = call_expr_nargs (expr);
for (int i = 0; i < nargs; i++)
--- gcc/cgraphclones.cc.jj  2023-02-22 11:21:56.467934980 +0100
+++ gcc/cgraphclones.cc 2023-02-22 11:28:30.272242754 +0100
@@ -425,9 +425,8 @@ cgraph_node::create_clone (tree new_decl
 version.  The only exception is when the edge was proved to
 be unreachable during the cloning procedure.  */
   if (!e->callee
- || !(fndecl_built_in_p (e->callee->decl, BUILT_IN_UNREACHABLE)
-  || fndecl_built_in_p (e->callee->decl,
-BUILT_IN_UNREACHABLE_TRAP)))
+ || !fndecl_built_in_p (e->callee->decl, BUILT_IN_UNREACHABLE,
+ BUILT_IN_UNREACHABLE_TRAP))
 

Re: [PATCH 1/2] PR target/107299: Fix build issue when long double is IEEE 128-bit

[Michael Meissner via Gcc-patches]

On Wed, Feb 22, 2023 at 06:37:39PM +0800, Kewen.Lin wrote:
> Thanks for working on this!  If updating libgcc source to workaround this 
> issue
> is the best option we can have at this moment, it's fine.

Thanks.  Yes, I agree that it does not fix the root issue.

> Comparing to one
> previous proposal which removes the workaround in build_common_tree_nodes for
> rs6000 KFmode, a bit concern on this one is that users can still meet the ICE
> with a simple case like:
> 
> typedef float TFtype __attribute__((mode (TF)));
> 
> TFtype
> test (TFtype t)
> {
>   return __builtin_copysignf128 (1.0q, t);
> }
> 
> but I guess they would write this kind of code very rarely?

I tend to think that it is better to consistantly use __float128/_Float128
types with the 'f128' functions, and use long double with the 'l'.  It would be
nice to fix the root cause (of __float128 and _Float128 not being the same type
within the compiler).

It is complicated by the fact that until C++2x, you can't use the _Float128
type.  You can use the __float128 and __ibm128 extensions, but you can't use
those extensions with _Complex.  This means for C++, you have to use the
__attrbibute__((mode)) to get to the complex type.  And due to the way I
initially implemented it, whether you use T{C,F}, K{C,F}, and I{C,F} depends on
the switches.

But without fixing that (which is fairly complex), I really want the master
branch fixed so you can build GCC with long double defaulting to IEEE 128-bit.

-- 
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meiss...@linux.ibm.com

RE: [PATCH 1/2]middle-end: Fix wrong overmatching of div-bitmask by using new optabs [PR108583]

[Tamar Christina via Gcc-patches]

> -Original Message-
> From: Andrew MacLeod 
> Sent: Wednesday, February 22, 2023 4:42 PM
> To: Tamar Christina ; Richard Biener
> ; Richard Sandiford 
> Cc: Tamar Christina via Gcc-patches ; nd
> ; j...@ventanamicro.com
> Subject: Re: [PATCH 1/2]middle-end: Fix wrong overmatching of div-bitmask
> by using new optabs [PR108583]
> 
> 
> On 2/15/23 13:42, Andrew MacLeod wrote:
> >
> > On 2/15/23 12:50, Andrew MacLeod wrote:
> >>
> >> On 2/15/23 12:13, Tamar Christina wrote:
>  On 2/15/23 07:51, Tamar Christina wrote:
> >> void
> >> operator_plus::wi_fold (irange , tree type,
> >>     const wide_int _lb, const wide_int _ub,
> >>     const wide_int _lb, const wide_int _ub)
> >> const {
> >>   wi::overflow_type ov_lb, ov_ub;
> >>   signop s = TYPE_SIGN (type);
> >>
> >>   // Do whatever wideint magic is required to do this adds in higher
> >> precision
> >>   wide_int new_lb = wi::add (lh_lb, rh_lb, s, _lb);
> >>   wide_int new_ub = wi::add (lh_ub, rh_ub, s, _ub);
> >>
> >>   r = int_range<2> (type, new_lb, new_ub); }
> >>
> >>
> >> The operator needs to be registered, I've attached the skeleton for
> >> it.  you should just have to finish implementing wi_fold().
> >>
> >> in theory :-)
> >>
> > You also mentioned earlier that some were tree codes, some were
> > internal function calls?  We have some initial support for built in
> > functions, but I am not familiar with all the various forms they can
> > take.  We currently support CFN_ functions in
> >
> >   gimple-range-op.cc, gimple_range_op_handler::maybe_builtin_call ()
> >
> > Basically this is part of a "gimple_range_op_handler"  wrapper for
> > range-ops which can provide a range-ops class for stmts that don't map
> > to a binary or unary form.. such as built in functions.
> >
> > If you get to the point where you need this for a builtin function, I
> > can help you through that too.  Although someone may have to also help
> > me through what differentiates the different kinds of internal
> > function :-)    I presume they are all similar in some way.
> >
> > Andrew
> >
> Oh yeah, and in case you haven't figured it out on your own, you'll have
> to remove WIDEN_MULT_EXPR from the range-ops init table.   This
> non-standard mechanism only gets checked if there is no standard
> range-op table entry for the tree code :-P
> 

Hmm it looks like it'll work, but it keeps segfaulting in:

bool
range_op_handler::fold_range (vrange , tree type,
  const vrange ,
  const vrange ,
  relation_trio rel) const
{
  gcc_checking_assert (m_valid);
  if (m_int)
return m_int->fold_range (as_a  (r), type,
   as_a  (lh),
   as_a  (rh), rel);

while trying to call fold_range.

But m_int is set to the right instance. Probably something I'm missing,
I'll double check it all.

Cheers,
Tamar
> Andrew
> 
> Andrew

New Romanian PO file for 'cpplib' (version 13.1-b20230212)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'cpplib' has been submitted
by the Romanian team of translators.  The file is available at:

https://translationproject.org/latest/cpplib/ro.po

(This file, 'cpplib-13.1-b20230212.ro.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

https://translationproject.org/latest/cpplib/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

https://translationproject.org/domain/cpplib.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

Contents of PO file 'cpplib-13.1-b20230212.ro.po'

[Translation Project Robot]

cpplib-13.1-b20230212.ro.po.gz
Description: Binary data
The Translation Project robot, in the
name of your translation coordinator.

Re: [PATCH 2/2] Rework 128-bit complex multiply and divide.

[Michael Meissner via Gcc-patches]

On Wed, Feb 22, 2023 at 06:13:07PM +0800, Kewen.Lin wrote:
> These two above paragraphs look a bit out of date (two patches now). :)

Thanks.

> IIUC this patch actually fixes a latent issue, so it is independent of the one
> fixing the bootstrapping issue, right?  This updated version of patch looks
> good to me, but I'd leave the approval to Segher/David.  Thanks!

Yes, I've been waiting for Segher or David's approval for this for awhile.

The history is it is indeed a latent issue (not supporting __ibm128 complex
multiply and divide when long double is IEEE 128-bit).  However, at the time I
wrote it, the other changes had broken the complex multiply and divide, and I
wrote this patch as part of the series.  I separated the patch from the other 2
to make it simpler to go in.  But it seems to be in limbo.

-- 
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meiss...@linux.ibm.com

Re: [PATCH] vect: Check that vector factor is a compile-time constant

[Michael Collison]

Juzhe,

I disagree with this comment. There are many stakeholders for 
autovectorization and waiting until GCC 14 is not a viable solution for 
us as well as other stakeholders ready to begin work on autovectorization.


As we discussed I have been moving forward with patches for 
autovectorization and am preparing to send them to gcc-patches. This 
assert is preventing code from compiling and needs to be addressed.


If you have a solution in either the RISCV backend or in this file can 
you please present it?


On 2/22/23 10:27, juzhe.zh...@rivai.ai wrote:

>/gcc/ />//>/* tree-vect-loop-manip.cc (vect_do_peeling): Verify />/that vectorization factor is a compile-time constant. />//>/--- 
/>/gcc/tree-vect-loop-manip.cc | 2 +- />/1 file changed, 1 insertion(+), 1 deletion(-) />//>/diff --git a/gcc/tree-vect-loop-manip.cc 
b/gcc/tree-vect-loop-manip.cc />/index 6aa3d2ed0bf..1ad1961c788 100644 />/--- a/gcc/tree-vect-loop-manip.cc />/+++ b/gcc/tree-vect-loop-manip.cc 
/>/@@ -2930,7 +2930,7 @@ vect_do_peeling (loop_vec_info loop_vinfo, tree />/niters, tree nitersm1, />/niters = vect_build_loop_niters (loop_vinfo, 
_var_p); />//* It's guaranteed that vector loop bound before vectorization is at />/least VF, so set range information for newly generated var. */ 
/>/- if (new_var_p) />/+ if (new_var_p && vf.is_constant ()) />/{ />/value_range vr (type, />/wi::to_wide (build_int_cst (type, vf)),/

I don't think we need to apply this limit in case of RVV 
auto-vectorization.
I have talked with Kito and I have a full solution of supporting RVV 
solution.


We are going to support RVV auto-vectorization in 3 configuration 
according to RVV ISA spec:
1. -march=zve32* support QI and HI auto-vectorization by VNx4QImode 
and VNx2HImode
2. -march=zve64* support QI and HI and SI auto-vectorization by 
VNx8QImode and VNx4HImode and VNx2SImode
3.-march=v* support QI and HI and SI and DI auto-vectorization by 
VNx16QImode and VNx8HImode and VNx4SImode and VNx2DImode


I will support them in GCC 14. Current loop vectorizer works well for 
us no need to fix it.

Thanks.

juzhe.zh...@rivai.ai

Sort-of ping for [PATCH] testsuite: Handle "packed" targets in c-c++-common/auto-init-7.c and -8.c

[Hans-Peter Nilsson via Gcc-patches]

> From: Qing Zhao 
> Date: Wed, 15 Feb 2023 20:30:00 +0100

> Thank you for fixing this issue.

Thanks!  Although you're not holding an approver position
I'm tempted to take that as approval, as you're the author
of that test.  This being a patch of no particular
significance and having seen no other comments, I'll do
that, but delay another week.

brgds, H-P

> 
> Qing
> 
> > On Feb 15, 2023, at 2:19 PM, Hans-Peter Nilsson  wrote:
> > 
> > Tested for cris-elf.  Ok to commit?
> > 
> > -- >8 --
> > Looks like there's a failed assumption that
> > sizeof (union U { char u1[5]; int u2; float u3; }) == 8.
> > However, for "packed" targets like cris-elf, it's 5.
> > 
> > These two tests have always failed for cris-elf.  I see from
> > https://gcc.gnu.org/pipermail/gcc-testresults/2023-February/777912.html
> > that they fail on pru-elf too, but I don't know if the cause
> > (and/or remedy) is the same.
> > 
> > IMHO this is preferred over the alternative; splitting up
> > that last line into two lines, like:
> > /* { dg-final { scan-tree-dump "temp4 = \
> > .DEFERRED_INIT \\(8, 2, \&\"temp4\"" "gimple" { target { ! default_packed } 
> > } } } */
> > /* { dg-final { scan-tree-dump "temp4 = \
> > .DEFERRED_INIT \\(5, 2, \&\"temp4\"" "gimple" { target default_packed } } } 
> > */
> > 
> > gcc/testsuite:
> > * c-c++-common/auto-init-7.c, c-c++-common/auto-init-8.c: Also
> > match targets where sizeof (union U) == 5, like "packed" targets.
> > ---
> > gcc/testsuite/c-c++-common/auto-init-7.c | 2 +-
> > gcc/testsuite/c-c++-common/auto-init-8.c | 2 +-
> > 2 files changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/gcc/testsuite/c-c++-common/auto-init-7.c 
> > b/gcc/testsuite/c-c++-common/auto-init-7.c
> > index b44dd5e68ed1..dd48d691596f 100644
> > --- a/gcc/testsuite/c-c++-common/auto-init-7.c
> > +++ b/gcc/testsuite/c-c++-common/auto-init-7.c
> > @@ -32,4 +32,4 @@ double foo()
> > /* { dg-final { scan-tree-dump "temp1 = .DEFERRED_INIT \\(12, 2, 
> > \&\"temp1\"" "gimple" } } */
> > /* { dg-final { scan-tree-dump "temp2 = .DEFERRED_INIT \\(24, 2, 
> > \&\"temp2\"" "gimple" } } */
> > /* { dg-final { scan-tree-dump "temp3 = .DEFERRED_INIT \\(28, 2, 
> > \&\"temp3\"" "gimple" } } */
> > -/* { dg-final { scan-tree-dump "temp4 = .DEFERRED_INIT \\(8, 2, 
> > \&\"temp4\"" "gimple" } } */
> > +/* { dg-final { scan-tree-dump "temp4 = .DEFERRED_INIT \\((8|5), 2, 
> > \&\"temp4\"" "gimple" } } */
> > diff --git a/gcc/testsuite/c-c++-common/auto-init-8.c 
> > b/gcc/testsuite/c-c++-common/auto-init-8.c
> > index 739ac0289315..863f2ba87d7d 100644
> > --- a/gcc/testsuite/c-c++-common/auto-init-8.c
> > +++ b/gcc/testsuite/c-c++-common/auto-init-8.c
> > @@ -32,4 +32,4 @@ double foo()
> > /* { dg-final { scan-tree-dump "temp1 = .DEFERRED_INIT \\(12, 1, 
> > \&\"temp1\"" "gimple" } } */
> > /* { dg-final { scan-tree-dump "temp2 = .DEFERRED_INIT \\(24, 1, 
> > \&\"temp2\"" "gimple" } } */
> > /* { dg-final { scan-tree-dump "temp3 = .DEFERRED_INIT \\(28, 1, 
> > \&\"temp3\"" "gimple" } } */
> > -/* { dg-final { scan-tree-dump "temp4 = .DEFERRED_INIT \\(8, 1, 
> > \&\"temp4\"" "gimple" } } */
> > +/* { dg-final { scan-tree-dump "temp4 = .DEFERRED_INIT \\((8|5), 1, 
> > \&\"temp4\"" "gimple" } } */
> > -- 
> > 2.30.2
> > 
> 

New German PO file for 'cpplib' (version 13.1-b20230212)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'cpplib' has been submitted
by the German team of translators.  The file is available at:

https://translationproject.org/latest/cpplib/de.po

(This file, 'cpplib-13.1-b20230212.de.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

https://translationproject.org/latest/cpplib/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

https://translationproject.org/domain/cpplib.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

Contents of PO file 'cpplib-13.1-b20230212.de.po'

[Translation Project Robot]

cpplib-13.1-b20230212.de.po.gz
Description: Binary data
The Translation Project robot, in the
name of your translation coordinator.

Re: [PATCH] Skip module_cmi_p and related unsupported module test

[Alexandre Oliva via Gcc-patches]

On Feb 20, 2023, Jason Merrill  wrote:

> This seems like an ugly kludge around that problem, but I don't have
> any clever ideas of a better approach short of rewriting everything.
> So, OK with a comment explaining the rationale above your overridden
> "unsupported".

> Also, your commit subject line needs a subsystem tag, I guess
> "testsuite:" in this case.

*nod*, thanks, I'm checking in the adjusted patch below.


testsuite: Skip module_cmi_p and related unsupported module test

From: Alexandre Oliva 

When a multi-source module is found to be unsupported, we fail
module_cmi_p and subsequent sources.  Override proc unsupported to
mark the result in module_do, and test it to skip module_cmp_p and
subsequent related tests.


for  gcc/testsuite/ChangeLog

* g++.dg/modules/modules.exp: Override unsupported to update
module_do, and test it after dg-test.
---
 gcc/testsuite/g++.dg/modules/modules.exp |   17 +
 1 file changed, 17 insertions(+)

diff --git a/gcc/testsuite/g++.dg/modules/modules.exp 
b/gcc/testsuite/g++.dg/modules/modules.exp
index 61994b059457b..e66b2082f2055 100644
--- a/gcc/testsuite/g++.dg/modules/modules.exp
+++ b/gcc/testsuite/g++.dg/modules/modules.exp
@@ -315,6 +315,17 @@ proc module-check-requirements { tests } {
 # cleanup any detritus from previous run
 cleanup_module_files [find $DEFAULT_REPO *.gcm]
 
+# Override unsupported to set the second element of module_do to "N",
+# so that, after an unsupported result in dg-test, we can skip rather
+# than fail subsequent related tests.
+set module_do {"compile" "P"}
+rename unsupported saved-unsupported
+proc unsupported { args } {
+global module_do
+lset module_do 1 "N"
+return [saved-unsupported $args]
+}
+
 # not grouped tests, sadly tcl doesn't have negated glob
 foreach test [prune [lsort [find $srcdir/$subdir {*.[CH]}]] \
  "$srcdir/$subdir/*_?.\[CH\]"] {
@@ -327,6 +338,9 @@ foreach test [prune [lsort [find $srcdir/$subdir {*.[CH]}]] 
\
set module_cmis {}
verbose "Testing $nshort $std" 1
dg-test $test "$std" $DEFAULT_MODFLAGS
+   if { [lindex $module_do 1] == "N" } {
+   continue
+   }
set testcase [string range $test [string length "$srcdir/"] end]
cleanup_module_files [module_cmi_p $testcase $module_cmis]
}
@@ -372,6 +386,9 @@ foreach src [lsort [find $srcdir/$subdir {*_a.[CHX}]] {
}
}
dg-test -keep-output $test "$std" $DEFAULT_MODFLAGS
+   if { [lindex $module_do 1] == "N" } {
+   break
+   }
set testcase [string range $test [string length "$srcdir/"] 
end]
lappend mod_files [module_cmi_p $testcase $module_cmis]
}


-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

Re: [PATCH] [arm] disable aes-1742098 mitigation for a72 combine tests

[Alexandre Oliva via Gcc-patches]

Hello, Kyrylo,

On Feb 20, 2023, Kyrylo Tkachov  wrote:

> So rather than overriding this awkward part with
> -mno-fix-cortex-a57-aes-1742098 I'd rather just select a different
> CPU that enables that fusion and isn't afflicted by this workaround,
> such as -mcpu=cortex-a53.

Sounds good to me.

> Ok with changing the -mcpu option instead.

Thanks, here's what I've just retested and am now checking in.

[arm] avoid aes-1742098 mitigation in combine tests

The expected asm output for aes-fuse-[12].c does not correspond to
that which is generated when -mfix-cortex-a57-aes-1742098 is enabled.
The mitigation was introduced after the test, and enabled by default
for the selected processor, a72.  Select a53 instead, where the
migitation is not enabled by default, and all the expected fusions can
take place.


for  gcc/testsuite/ChangeLog

* gcc.target/arm/aes-fuse-1.c: Switch to -mcpu=cortex-a53.
* gcc.target/arm/aes-fuse-2.c: Likewise.
---
 gcc/testsuite/gcc.target/arm/aes-fuse-1.c |2 +-
 gcc/testsuite/gcc.target/arm/aes-fuse-2.c |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/testsuite/gcc.target/arm/aes-fuse-1.c 
b/gcc/testsuite/gcc.target/arm/aes-fuse-1.c
index 27b08aeef7ba7..a1bbe054e0a01 100644
--- a/gcc/testsuite/gcc.target/arm/aes-fuse-1.c
+++ b/gcc/testsuite/gcc.target/arm/aes-fuse-1.c
@@ -1,7 +1,7 @@
 /* { dg-do compile } */
 /* { dg-require-effective-target arm_crypto_ok } */
 /* { dg-add-options arm_crypto } */
-/* { dg-additional-options "-mcpu=cortex-a72 -O3 -dp" } */
+/* { dg-additional-options "-mcpu=cortex-a53 -O3 -dp" } */
 
 #include 
 
diff --git a/gcc/testsuite/gcc.target/arm/aes-fuse-2.c 
b/gcc/testsuite/gcc.target/arm/aes-fuse-2.c
index 1266a28753169..ede3237ce2692 100644
--- a/gcc/testsuite/gcc.target/arm/aes-fuse-2.c
+++ b/gcc/testsuite/gcc.target/arm/aes-fuse-2.c
@@ -1,7 +1,7 @@
 /* { dg-do compile } */
 /* { dg-require-effective-target arm_crypto_ok } */
 /* { dg-add-options arm_crypto } */
-/* { dg-additional-options "-mcpu=cortex-a72 -O3 -dp" } */
+/* { dg-additional-options "-mcpu=cortex-a53 -O3 -dp" } */
 
 #include 
 


-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

Re: [PATCH] vect: Check that vector factor is a compile-time constant

[Michael Collison]

Richard how would I check for a full masked main vector loop?

On 2/22/23 03:20, Richard Biener wrote:

On Wed, Feb 22, 2023 at 12:03 AM Michael Collison  wrote:

While working on autovectorizing for the RISCV port I encountered an
issue where vect_do_peeling assumes that the vectorization factor is a
compile-time constant. The vectorization is not a compile-time constant
on RISCV.

Tested on RISCV and x86_64-linux-gnu. Okay?

I wonder how you arrive at prologue peeling with a non-constant VF?
In any case it would probably be better to use constant_lower_bound (vf)
here?  Also it looks wrong to apply this limit in case we are using
a fully masked main vector loop.  But as said, the specific case of
non-constant VF and prologue peeling probably wasn't supposed to happen,
instead the prologue usually is applied via an offset to a fully masked loop?

Richard?

Thanks,
Richard.


Michael

gcc/

  * tree-vect-loop-manip.cc (vect_do_peeling): Verify
  that vectorization factor is a compile-time constant.

---
   gcc/tree-vect-loop-manip.cc | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/tree-vect-loop-manip.cc b/gcc/tree-vect-loop-manip.cc
index 6aa3d2ed0bf..1ad1961c788 100644
--- a/gcc/tree-vect-loop-manip.cc
+++ b/gcc/tree-vect-loop-manip.cc
@@ -2930,7 +2930,7 @@ vect_do_peeling (loop_vec_info loop_vinfo, tree
niters, tree nitersm1,
 niters = vect_build_loop_niters (loop_vinfo, _var_p);
 /* It's guaranteed that vector loop bound before vectorization is at
least VF, so set range information for newly generated var. */
-  if (new_var_p)
+  if (new_var_p && vf.is_constant ())
   {
 value_range vr (type,
 wi::to_wide (build_int_cst (type, vf)),
--
2.34.1

Re: [PATCH 1/2]middle-end: Fix wrong overmatching of div-bitmask by using new optabs [PR108583]

[Andrew MacLeod via Gcc-patches]

On 2/15/23 13:42, Andrew MacLeod wrote:


On 2/15/23 12:50, Andrew MacLeod wrote:


On 2/15/23 12:13, Tamar Christina wrote:

On 2/15/23 07:51, Tamar Christina wrote:

void
operator_plus::wi_fold (irange , tree type,
    const wide_int _lb, const wide_int _ub,
    const wide_int _lb, const wide_int _ub) 
const

{
  wi::overflow_type ov_lb, ov_ub;
  signop s = TYPE_SIGN (type);

  // Do whatever wideint magic is required to do this adds in higher 
precision

  wide_int new_lb = wi::add (lh_lb, rh_lb, s, _lb);
  wide_int new_ub = wi::add (lh_ub, rh_ub, s, _ub);

  r = int_range<2> (type, new_lb, new_ub);
}


The operator needs to be registered, I've attached the skeleton for 
it.  you should just have to finish implementing wi_fold().


in theory :-)

You also mentioned earlier that some were tree codes, some were 
internal function calls?  We have some initial support for built in 
functions, but I am not familiar with all the various forms they can 
take.  We currently support CFN_ functions in


  gimple-range-op.cc, gimple_range_op_handler::maybe_builtin_call ()

Basically this is part of a "gimple_range_op_handler"  wrapper for 
range-ops which can provide a range-ops class for stmts that don't map 
to a binary or unary form.. such as built in functions.


If you get to the point where you need this for a builtin function, I 
can help you through that too.  Although someone may have to also help 
me through what differentiates the different kinds of internal 
function :-)    I presume they are all similar in some way.


Andrew

Oh yeah, and in case you haven't figured it out on your own, you'll have 
to remove WIDEN_MULT_EXPR from the range-ops init table.   This 
non-standard mechanism only gets checked if there is no standard 
range-op table entry for the tree code :-P


Andrew

Andrew

Contents of PO file 'cpplib-13.1-b20230212.es.po'

[Translation Project Robot]

cpplib-13.1-b20230212.es.po.gz
Description: Binary data
The Translation Project robot, in the
name of your translation coordinator.

New Spanish PO file for 'cpplib' (version 13.1-b20230212)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'cpplib' has been submitted
by the Spanish team of translators.  The file is available at:

https://translationproject.org/latest/cpplib/es.po

(This file, 'cpplib-13.1-b20230212.es.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

https://translationproject.org/latest/cpplib/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

https://translationproject.org/domain/cpplib.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

Re: [PATCH] Share work directories

[Andrew Pinski via Gcc-patches]

On Wed, Feb 22, 2023 at 4:22 AM Yash Shinde  wrote:
>
> From: Khem Raj 
>
> Fix configure and Makefile files to read the defaults.hand t-oe from build 
> directory,
> so that the source can be shared between gcc-cross-initial, 
> gcc-cross-intermediate, gcc-cross, gcc-runtime,
> and also the sdk build which use a separate build directory compared to 
> source directory.

>
> While compiling gcc-crosssdk-initial-x86_64 on some host, there is
> occasionally failure that test the existance of default.h doesn't work,
> the reason is tm_include_list='** defaults.h' rather than tm_include_list='** 
> ./defaults.h'.
> So we add the test condition for this situation.

This patch does not make sense because $(srcdir)/defaults.h will always exist.
I build all the time with different object directories and I know of
many people who build with a read only source directory; explicitly so
they can test that way.
You are going to have to expand on why you need defaults.h from the
build directory and not the source directory?
As far as I Know there is no defaults.h in the build directory even.
Do you have another patch which changes that?


Thanks,
Andrew Pinski

>
> gcc/ChangeLog:
>
> * configure
> * configure.ac
> * mkconfig.sh
>
> Signed-off-by: Khem Raj 
> Signed-off-by: Hongxu Jia 
> ---
>  gcc/configure| 4 ++--
>  gcc/configure.ac | 4 ++--
>  gcc/mkconfig.sh  | 4 ++--
>  3 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/gcc/configure b/gcc/configure
> index 254f9b6c943..ff2a3e26049 100755
> --- a/gcc/configure
> +++ b/gcc/configure
> @@ -13471,8 +13471,8 @@ for f in $tm_file; do
> tm_include_list="${tm_include_list} $f"
> ;;
>  defaults.h )
> -   tm_file_list="${tm_file_list} \$(srcdir)/$f"
> -   tm_include_list="${tm_include_list} $f"
> +   tm_file_list="${tm_file_list} ./$f"
> +   tm_include_list="${tm_include_list} ./$f"
> ;;
>  * )
> tm_file_list="${tm_file_list} \$(srcdir)/config/$f"
> diff --git a/gcc/configure.ac b/gcc/configure.ac
> index 62bc908b991..d36830cf2fb 100644
> --- a/gcc/configure.ac
> +++ b/gcc/configure.ac
> @@ -2336,8 +2336,8 @@ for f in $tm_file; do
> tm_include_list="${tm_include_list} $f"
> ;;
>  defaults.h )
> -   tm_file_list="${tm_file_list} \$(srcdir)/$f"
> -   tm_include_list="${tm_include_list} $f"
> +   tm_file_list="${tm_file_list} ./$f"
> +   tm_include_list="${tm_include_list} ./$f"
> ;;
>  * )
> tm_file_list="${tm_file_list} \$(srcdir)/config/$f"
> diff --git a/gcc/mkconfig.sh b/gcc/mkconfig.sh
> index 054ede89647..3b2c2b9df37 100644
> --- a/gcc/mkconfig.sh
> +++ b/gcc/mkconfig.sh
> @@ -77,7 +77,7 @@ if [ -n "$HEADERS" ]; then
>  if [ $# -ge 1 ]; then
> echo '#ifdef IN_GCC' >> ${output}T
> for file in "$@"; do
> -   if test x"$file" = x"defaults.h"; then
> +   if test x"$file" = x"./defaults.h" -o x"$file" = x"defaults.h"; 
> then
> postpone_defaults_h="yes"
> else
> echo "# include \"$file\"" >> ${output}T
> @@ -106,7 +106,7 @@ esac
>
>  # If we postponed including defaults.h, add the #include now.
>  if test x"$postpone_defaults_h" = x"yes"; then
> -echo "# include \"defaults.h\"" >> ${output}T
> +echo "# include \"./defaults.h\"" >> ${output}T
>  fi
>
>  # Add multiple inclusion protection guard, part two.
> --
> 2.39.0
>

Re: [PATCH] Accept pmf-vbit-in-delta extra warning

[Alexandre Oliva via Gcc-patches]

On Feb 17, 2023, Jason Merrill  wrote:

> On 2/17/23 23:02, Alexandre Oliva wrote:
>> 
>> cp_build_binary_op, that issues -Waddress warnings, issues an extra
>> warning on arm targets, that g++.dg/warn/Waddress-5.C does not expect
>> when comparing a pointer-to-member-function literal with null.
>> 
>> The reason for the extra warning is that, on arm targets,
>> TARGET_PTRMEMFUNC_VBIT_LOCATION == ptrmemfunc_vbit_in_delta, which
>> causes a different path to be taken, that extracts the
>> pointer-to-function and the delta fields (minus the vbit) and compares
>> each one with zero.  It's when comparing this pointer-to-function with
>> zero, in a recursive cp_build_binary_op, that another warning is
>> issued.
>> 
>> I suppose there should be a way to skip the warning in this recursive
>> call, without disabling other warnings that might be issued there, but

> warning_sentinel ws (warn_address)

Oh, yeah, that will suppress the expected warning for pfn0, but isn't
there any risk whatsoever that it could suppress other -Waddress
warnings for tree operands of pfn0?

I see the cp_save_expr for side effects, but what if e.g. the pmfn we're
testing is an array element, and the index expression tests another pmfn
against NULL that should be warned about?  Or something else that
wouldn't have TREE_SIDE_EFFECTS, and would thus not go through
cp_save_expr.  Would we then warn for uses of both pfn0 and delta0?


Here's what I'm going to test for these concerns.  Ok to install if it
bootstraps successfully, and my concerns are unfounded?


[c++] suppress redundant null-addr warn in pfn from pmfn

From: Alexandre Oliva 

When TARGET_PTRMEMFUNC_VBIT_LOCATION == ptrmemfunc_vbit_in_delta, when
we warn about comparing a pointer-to-member-function with NULL, we
also warn about comparing the pointer-to-function extracted from it
with NULL, which is redundant.  Suppress the redundant warning.


for  gcc/cp/ChangeLog

* typeck.cc (cp_build_binary_op): Suppress redundant warning
for pfn null test in pmfn test with vbit-in-delta.
---
 gcc/cp/typeck.cc |   17 -
 1 file changed, 12 insertions(+), 5 deletions(-)

diff --git a/gcc/cp/typeck.cc b/gcc/cp/typeck.cc
index 4afb5e4f0d420..d5a3e501d8e91 100644
--- a/gcc/cp/typeck.cc
+++ b/gcc/cp/typeck.cc
@@ -5780,11 +5780,18 @@ cp_build_binary_op (const op_location_t ,
 
  pfn0 = pfn_from_ptrmemfunc (op0);
  delta0 = delta_from_ptrmemfunc (op0);
- e1 = cp_build_binary_op (location,
-  EQ_EXPR,
-  pfn0,
-  build_zero_cst (TREE_TYPE (pfn0)),
-  complain);
+ {
+   /* If we will warn below about a null-address compare
+  involving the orig_op0 ptrmemfunc, we'd likely also
+  warn about the pfn0's null-address compare, and
+  that would be redundant, so suppress it.  */
+   warning_sentinel ws (warn_address);
+   e1 = cp_build_binary_op (location,
+EQ_EXPR,
+pfn0,
+build_zero_cst (TREE_TYPE (pfn0)),
+complain);
+ }
  e2 = cp_build_binary_op (location,
   BIT_AND_EXPR,
   delta0,


-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

Re: [PATCH] Share work directories

[Thomas Schwinge]

Hi!

On 2023-02-22T04:19:04-0800, Yash Shinde  wrote:
> From: Khem Raj 
>
> Fix configure and Makefile files to read the defaults.h and t-oe from build 
> directory,
> so that the source can be shared between gcc-cross-initial, 
> gcc-cross-intermediate, gcc-cross, gcc-runtime,
> and also the sdk build which use a separate build directory compared to 
> source directory.
>
> While compiling gcc-crosssdk-initial-x86_64 on some host, there is
> occasionally failure that test the existance of default.h doesn't work,

This is about '[source-gcc]/gcc/defaults.h', right?  Why should that ever
fail to test that it exists?

> the reason is tm_include_list='** defaults.h' rather than tm_include_list='** 
> ./defaults.h'.
> So we add the test condition for this situation.

I'm sorry, I understand neither your failure mode, nor your proposed
changes.  Please provide more context?


Grüße
 Thomas


> gcc/ChangeLog:
>
>   * configure
>   * configure.ac
>   * mkconfig.sh
>
> Signed-off-by: Khem Raj 
> Signed-off-by: Hongxu Jia 
> ---
>  gcc/configure| 4 ++--
>  gcc/configure.ac | 4 ++--
>  gcc/mkconfig.sh  | 4 ++--
>  3 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/gcc/configure b/gcc/configure
> index 254f9b6c943..ff2a3e26049 100755
> --- a/gcc/configure
> +++ b/gcc/configure
> @@ -13471,8 +13471,8 @@ for f in $tm_file; do
> tm_include_list="${tm_include_list} $f"
> ;;
>  defaults.h )
> -   tm_file_list="${tm_file_list} \$(srcdir)/$f"
> -   tm_include_list="${tm_include_list} $f"
> +   tm_file_list="${tm_file_list} ./$f"
> +   tm_include_list="${tm_include_list} ./$f"
> ;;
>  * )
> tm_file_list="${tm_file_list} \$(srcdir)/config/$f"
> diff --git a/gcc/configure.ac b/gcc/configure.ac
> index 62bc908b991..d36830cf2fb 100644
> --- a/gcc/configure.ac
> +++ b/gcc/configure.ac
> @@ -2336,8 +2336,8 @@ for f in $tm_file; do
> tm_include_list="${tm_include_list} $f"
> ;;
>  defaults.h )
> -   tm_file_list="${tm_file_list} \$(srcdir)/$f"
> -   tm_include_list="${tm_include_list} $f"
> +   tm_file_list="${tm_file_list} ./$f"
> +   tm_include_list="${tm_include_list} ./$f"
> ;;
>  * )
> tm_file_list="${tm_file_list} \$(srcdir)/config/$f"
> diff --git a/gcc/mkconfig.sh b/gcc/mkconfig.sh
> index 054ede89647..3b2c2b9df37 100644
> --- a/gcc/mkconfig.sh
> +++ b/gcc/mkconfig.sh
> @@ -77,7 +77,7 @@ if [ -n "$HEADERS" ]; then
>  if [ $# -ge 1 ]; then
>   echo '#ifdef IN_GCC' >> ${output}T
>   for file in "$@"; do
> - if test x"$file" = x"defaults.h"; then
> + if test x"$file" = x"./defaults.h" -o x"$file" = x"defaults.h"; then
>   postpone_defaults_h="yes"
>   else
>   echo "# include \"$file\"" >> ${output}T
> @@ -106,7 +106,7 @@ esac
>
>  # If we postponed including defaults.h, add the #include now.
>  if test x"$postpone_defaults_h" = x"yes"; then
> -echo "# include \"defaults.h\"" >> ${output}T
> +echo "# include \"./defaults.h\"" >> ${output}T
>  fi
>
>  # Add multiple inclusion protection guard, part two.
> --
> 2.39.0
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955

[PATCH] vect: Check that vector factor is a compile-time constant

[juzhe.zhong]

> gcc/
>
>  * tree-vect-loop-manip.cc (vect_do_peeling): Verify
>  that vectorization factor is a compile-time constant.
>
> ---
>   gcc/tree-vect-loop-manip.cc | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/gcc/tree-vect-loop-manip.cc b/gcc/tree-vect-loop-manip.cc
> index 6aa3d2ed0bf..1ad1961c788 100644
> --- a/gcc/tree-vect-loop-manip.cc
> +++ b/gcc/tree-vect-loop-manip.cc
> @@ -2930,7 +2930,7 @@ vect_do_peeling (loop_vec_info loop_vinfo, tree
> niters, tree nitersm1,
> niters = vect_build_loop_niters (loop_vinfo, _var_p);
> /* It's guaranteed that vector loop bound before vectorization is at
>least VF, so set range information for newly generated var. */
> -  if (new_var_p)
> +  if (new_var_p && vf.is_constant ())
>   {
> value_range vr (type,
> wi::to_wide (build_int_cst (type, vf)),

I don't think we need to apply this limit in case of RVV auto-vectorization.
I have talked with Kito and I have a full solution of supporting RVV solution.

We are going to support RVV auto-vectorization in 3 configuration according to 
RVV ISA spec:
1. -march=zve32* support QI and HI auto-vectorization by VNx4QImode and 
VNx2HImode
2. -march=zve64* support QI and HI and SI auto-vectorization by VNx8QImode and 
VNx4HImode and VNx2SImode
3. -march=v* support QI and HI and SI and DI auto-vectorization by VNx16QImode 
and VNx8HImode and VNx4SImode and VNx2DImode

I will support them in GCC 14. Current loop vectorizer works well for us no 
need to fix it. 
Thanks.


juzhe.zh...@rivai.ai

Re: [PATCH] [vxworks] make wint_t and wchar_t the same distinct type

[Alexandre Oliva via Gcc-patches]

Hello, Jason,

On Feb 17, 2023, Jason Merrill  wrote:

> On 2/17/23 23:04, Alexandre Oliva wrote:
>> 
>> We used to define WINT_TYPE to WCHAR_TYPE, so that both wint_t and
>> wchar_t mapped to the same underlying type, but this caused a glitch
>> in Wstringop-overflow-6.C: on vxworks, wint_t is typedef'ed to
>> wchar_t

> And fixing that isn't an option?

Erhm, why do you say "fixing"?  That implies it's broken, but I don't
see anything in the C++ standards, or in the relevant bits that it
imports from the C standards, that rules out using wint_t = wchar_t in
C++.  wint_t is imported from the C standard as an integral type that
meets certain requirements, and AFAICT in C++ wchar_t is an integral
type that meets those requirements.  Am I missing something?


Now, could it be changed so that wint_t is wchar_t's underlying type
rather than wchar_t?  If the equivalence is a compliance error, we could
file a bug report with WRS and request them to fix it, but modifying
their system headers would require a copyright license they don't grant,
so we avoid doing that.  I imagine that breaking this equivalence would
have ABI implications, and even break legitimate (though unportable)
programs because of overload, specializations and whatnot, so there
would have to be very strong reasons to support a request for such a
change.

> Do the integer builtins work properly if we force them to use wchar_t
> instead of an integer type?

I haven't observed any regressions, I don't see any builtin functions
with wint in their signature that we even expand as builtins, and my
imagination is failing me on why an integral type such as wchar_t would
fail for wint_t, where other integral types, including wchar_t's
underlying type, would work.  Did you have any specific risks in mind
about what could go wrong?

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

Re: [PATCH 1/2]middle-end: Fix wrong overmatching of div-bitmask by using new optabs [PR108583]

[Andrew MacLeod via Gcc-patches]

On 2/22/23 08:06, Tamar Christina wrote:

Hi Andrew,


all the range-op integer code is in gcc/range-op.cc.  As this is a basic
binary operation, you should be able to get away with implementing a
single routine,  wi_fold () which adds 2 wide int bounds  together and
returns a result.  THis si the implelemntaion for operator_plus.

void
operator_plus::wi_fold (irange , tree type,
      const wide_int _lb, const wide_int _ub,
      const wide_int _lb, const wide_int _ub) const
{
    wi::overflow_type ov_lb, ov_ub;
    signop s = TYPE_SIGN (type);
    wide_int new_lb = wi::add (lh_lb, rh_lb, s, _lb);
    wide_int new_ub = wi::add (lh_ub, rh_ub, s, _ub);
    value_range_with_overflow (r, type, new_lb, new_ub, ov_lb, ov_ub);
}


you shouldn't have to do any of the overflow stuff at the end, just take
the 2 sets of wide int, double their precision to start, add them
together (it cant possible overflow right) and then return an
int_range<2> with those bounds...
ie

void
operator_plus::wi_fold (irange , tree type,
      const wide_int _lb, const wide_int _ub,
      const wide_int _lb, const wide_int _ub) const
{
    wi::overflow_type ov_lb, ov_ub;
    signop s = TYPE_SIGN (type);

    // Do whatever wideint magic is required to do this adds in higher
precision
    wide_int new_lb = wi::add (lh_lb, rh_lb, s, _lb);
    wide_int new_ub = wi::add (lh_ub, rh_ub, s, _ub);

    r = int_range<2> (type, new_lb, new_ub);
}


So I've been working on adding support for widening plus and widening 
multiplication,
and my examples all work now.. but during bootstrap I hit a problem.

Say you have a mixed sign widening multiplication, such as in:

int decMultiplyOp_zacc, decMultiplyOp_iacc;
int *decMultiplyOp_lp;
void decMultiplyOp() {
   decMultiplyOp_lp = _zacc;
   for (; decMultiplyOp_lp < _zacc + decMultiplyOp_iacc;
decMultiplyOp_lp++)
 *decMultiplyOp_lp = 0;
}

Eventually the pointer arithmetic will generate:

intD.7 decMultiplyOp_iacc.2_13;
long unsigned intD.11 _15;
_15 = decMultiplyOp_iacc.2_13 w* 4;
and it'll try to get the range from this.

My implementation is just:

void
operator_widen_mult::wi_fold (irange , tree type,
const wide_int _lb, const wide_int _ub,
const wide_int _lb, const wide_int _ub) const
{
   signop s = TYPE_SIGN (type);

   wide_int lh_wlb = wide_int::from (lh_lb, wi::get_precision (lh_lb) * 2, s);
   wide_int rh_wlb = wide_int::from (rh_lb, wi::get_precision (rh_lb) * 2, s);
   wide_int lh_wub = wide_int::from (lh_ub, wi::get_precision (lh_ub) * 2, s);
   wide_int rh_wub = wide_int::from (rh_ub, wi::get_precision (rh_ub) * 2, s);

   /* We don't expect a widening multiplication to be able to overflow but range
  calculations for multiplications are complicated.  After widening the
  operands lets call the base class.  */
   return operator_mult::wi_fold (r, type, lh_wlb, lh_wub, rh_wlb, rh_wub);
}

But in this case the operands are different types and the wi_fold only gets the
type of the operation. The issue is that when increasing the precision for lh_*
I need to sign extend the value and not zero extend, but I don't seem to have
enough context here to know that I do.  I'm missing the type of the operands.

For non-widening operations this doesn't matter as the precision stays the same.

Is there a way to get the information I need?



we haven't had this situation before, if I understand it correctly:

The LHS is a different type than both the operands, and your problem is 
you need to know the sign of at least operand1 in order to know whether 
to zero extend or to sign extend it?  huh. haven't run into that with 
any other bit of IL before :-P


Let me think about it.  I am loathe to change range-ops itself, but we 
may be able to leverage the builtin-function approach to dealing with 
something non-standard. At least for the moment to keep you going.


For the builtins, we provide a range-ops handler, *after* we look at the 
operands from within a gimple-context where we can still see the types, 
and  choose an appropriate handler.  so I'm thinking we provide 2 handlers,


operator_widen_mult_signed
operator_widen_mult_unsigned

chosen based on whether to sign extned or zero extend op1. look at the 
type of operand one, and return the appropriate handler. Let me give you 
a skeleton.  I *think* this should do it.


you can provide 2 versions of  operator_widen_mult in range-ops (so you 
can still inherit from operator_mult).  The should be exported I think, 
and the appropriate one should be called I think...


Give it a try and see if it works :-P.




diff --git a/gcc/gimple-range-op.cc b/gcc/gimple-range-op.cc
index d9dfdc56939..e4391f4a616 100644
--- a/gcc/gimple-range-op.cc
+++ b/gcc/gimple-range-op.cc
@@ -179,6 +179,8 @@ gimple_range_op_handler::gimple_range_op_handler (gimple *s)
   // statements.
   if (is_a  (m_stmt))
 

Re: [PATCH] [PR77760] [libstdc++] encode __time_get_state in tm

[Alexandre Oliva via Gcc-patches]

On Feb 17, 2023, Jakub Jelinek  wrote:

> My worry is that people often invoke the time_get APIs on uninitialized
> struct tm.

Yeah.  I thought you meant get(), but it looks like you meant do_get()
as well.  I seem to have overread the permissions to overwrite tm
members, to update its current contents, and to write unspecified values
in its members.

When I started down this path, I thought we might be able to hold the
state bits only in fields that were to be updated, but the century field
and allowing for 16-bit ints made that a bit challenging.


So, back to the drawing board, the other possibility that occurs to me
is to use a thread-local state-keeper chained stack, set up by get, and
that enabled state to be recovered and updated by do_get if relevant
incoming arguments match those recorded at the top of the stack (e.g.,
at least that we're looking at the same tm object).


Another approach is to encode state in tm in-place and progressively,
and compute derived fields when (i) we've just set one of the input
fields, and (ii) any other input fields are in range.  E.g., if we parse
%p, we make sure tm_hour will be in the 00..11 range for am or 12..23
for pm, using the value previously-held in tm_hour, modulo 12, only if
it was in the 00..23 range.  If it wasn't in range, we record 00 or 12.
When we parse %I, if we find that tm_hour is in the 12..23 range, we
take that as meaning a "pm" was parsed for %p before, and add 12 to the
parsed value.  For century, we'd encode it immediately in tm_year
(preserving the previous modulo-100 value), and when parsing %Y we'd use
the century data, both at the risk of using garbage in case of
uninitialized data.  That appears to be in line with the
standard-specified behavior.  Maybe this is what the specification
expects implementations to do?

> For the encoding in get, the questions are:
> 1) if it is ok if we clear some normally unused bits of certain tm_*
>fields even if they wouldn't be otherwise touched; perhaps nothing
>will care, but it is still a user visible change

Rereading the relevant passages in standards and drafts, ISTM that this
unconditional zeroing would be unexpected and not permitted by the
standard, indeed.

> 2) when those tm_* fields we want to encode the state into are unitialized,
>don't we effectively invoke UB by using the uninitialized member
>(admittedly we just overwrite some bits in it and leave others as is,
>but won't that e.g. cause -Wuninitialized warnings)?

ISTM that https://eel.is/c++draft/locale.time.get#virtuals-15 allows
do_get to read values of members, and even to expect them to have been
zero-initialized.  That, and the allowance for unspecified values to be
stored in tm in case of error, seem to me to hint at using out-of-range
values of struct tm.

However, at the end of do_get, we *should* have specified values in
place in the just-read member, and get rules out modifying other fields.
Could get() build a temporary, automatic tm object, zero-initialize it,
set a bit in each field that indicates it is not set, use it throughout
multiple do_get calls to hold parsed values and internal state, and then
copy to the user-supplied tm object only fields that are marked as set
(the bit is clear) and in range?

> More importantly, in the do_get the questions are:
> 3) while do_get is protected, are we guaranteed that it will never be called
>except from the public members of time_get?

That's IMHO the main element of risk in using bits from unrelated fields
to hold state.  Storing the expected values only implies encoding state
in tm where it would ultimately end up (i.e., am/pm in tm_hour / 12,
century in tm_year / 100 + 19), using a zero (or an equal-to-sign) bit
to flag "set", and leaving it for get() to compute derived fields (if
that's even standard-compliant; it's not clear that it is, desirable as
it seems)

> 4) I think we even shouldn't __state._M_finalize_state(__tm); in do_get
>if it is nested, then you wouldn't need to tweak 
> src/c++98/locale_facets.cc;
>generally state should be finalized once everything is parsed together,
>not many times in between (of course if user code will parse stuff
>separately that will not work, say get with "%I" in one call, then get
>with "%h" in another one etc., but that is user's decision).

Parsing "%h%p%I%p%h" should get into tm_hour the value that time_put
read to format with the same format string, so there's an argument for
"finalizing" tm_hour based on more than the state fields we hold atm,
perhaps even for progressive in-place encoding, as I have suggested
above.

> Just curious, why doesn't the pmf hack work on arm-vxworks7?

At first, I thought we were running into this just because we have to
define __clang__ because of some vxworks system headers aimed at clang.
But even as I tried to drop the #ifndef, the test still failed; I
suspected it had to do with ARM's encoding of ptrmemfunc_vbit_in_delta,
but I did not confirm that 

Re: Rust: In 'type_for_mode' langhook also consider all 'int_n' modes/types (was: Modula-2 / Rust: Many targets failing)

[Arthur Cohen]

Hi Thomas,

On 2/22/23 12:25, Thomas Schwinge wrote:

Hi!

Richard, you may remember your words from 
"ICE: SIGSEGV in optab_for_tree_code (optabs.c:407) with -O -fno-tree-scev-cprop 
-ftree-vectorize":


Ideally we'd never use lang_hooks.types.type_for_mode (or _for_size) in the
middle-end but had a pure middle-end based implementation.


Is there a canonical PR or other discussion thread for that?

Here's another instance of this issue:

On 2022-12-19T22:23:45+0100, Jan-Benedict Glaw  wrote:

With the recent merges for Modula-2 and Rust, I see a good number of
targets failing with --enable-languages=all, mostly due to issues with
the Modula-2 driver.


Thanks for reporting.


  Modula-2 related issues
[snipped]



  Rust related issues
=

  --target=msp430-elfbare
~
   /var/lib/laminar/run/gcc-msp430-elfbare/24/toolchain-build/./gcc/xgcc 
-B/var/lib/laminar/run/gcc-msp430-elfbare/24/toolchain-build/./gcc/  -xrust 
-frust-incomplete-and-experimental-compiler-do-not-use -nostdinc /dev/null -S 
-o /dev/null -fself-test=../../gcc/gcc/testsuite/selftests
   : internal compiler error: Segmentation fault
   0xf2efbf crash_signal
 ../../gcc/gcc/toplev.cc:314
   0x120c8c7 build_function_type(tree_node*, tree_node*, bool)
 ../../gcc/gcc/tree.cc:7360
   0x120cc20 build_function_type_list(tree_node*, ...)
 ../../gcc/gcc/tree.cc:7442
   0x120d16b build_common_builtin_nodes()
 ../../gcc/gcc/tree.cc:9883
   0x8449b4 grs_langhook_init
 ../../gcc/gcc/rust/rust-lang.cc:132
   0x8427b2 lang_dependent_init
 ../../gcc/gcc/toplev.cc:1815
   0x8427b2 do_compile
 ../../gcc/gcc/toplev.cc:2110
   Please submit a full bug report, with preprocessed source (by using 
-freport-bug).
   Please include the complete backtrace with any bug report.
   See  for instructions.
   make[1]: *** [../../gcc/gcc/rust/Make-lang.in:275: s-selftest-rust] 
Error 1


See also 
"Test failure on msp430-elfbare target".

I confirm with both upstream GCC master branch and GCC/Rust master
branch:

 $ ../source-gcc/configure --target=msp430-elfbare --enable-languages=rust 
[...]
 $ make all-gcc [...]
 [...]
 [...]/build-gcc/./gcc/xgcc -B[...]/build-gcc/./gcc/  -xc -nostdinc 
/dev/null -S -o /dev/null -fself-test=../../source-gcc/gcc/testsuite/selftests
 -fself-test: 57323 pass(es) in 0.42 seconds
 echo timestamp > s-selftest-c
 [...]/build-gcc/./gcc/xgcc -B[...]/build-gcc/./gcc/  -xrust 
-frust-incomplete-and-experimental-compiler-do-not-use -nostdinc /dev/null -S 
-o /dev/null -fself-test=../../source-gcc/gcc/testsuite/selftests
 : internal compiler error: Segmentation fault
 0xf51b9f crash_signal
 ../../source-gcc/gcc/toplev.cc:314
 0x12e6a3a build_function_type(tree_node*, tree_node*, bool)
 ../../source-gcc/gcc/tree.cc:7447
 0x12e6ee0 build_function_type_list(tree_node*, ...)
 ../../source-gcc/gcc/tree.cc:7529
 0x12e748e build_common_builtin_nodes()
 ../../source-gcc/gcc/tree.cc:9977
 0x7661c4 grs_langhook_init
 ../../source-gcc/gcc/rust/rust-lang.cc:128
 0x762ac9 lang_dependent_init
 ../../source-gcc/gcc/toplev.cc:1815
 0x762ac9 do_compile
 ../../source-gcc/gcc/toplev.cc:2110
 Please submit a full bug report, with preprocessed source (by using 
-freport-bug).
 Please include the complete backtrace with any bug report.
 See  for instructions.
 make[1]: *** [s-selftest-rust] Error 1
 [...]

OK to push the attached
"Rust: In 'type_for_mode' langhook also consider all 'int_n' modes/types"?|


OK :) patch was tested on x86_64 and builds, bootstraps and pass the 
testsuite.


Kindly,

Arthur




Grüße
  Thomas


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955


OpenPGP_0x1B3465B044AD9C65.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: [PATCH] [arm] adjust tests for quotes around +cdecp

[Christophe Lyon via Gcc-patches]

On 2/22/23 13:38, Alexandre Oliva wrote:

Hello, Christophe,

On Feb 20, 2023, Christophe Lyon  wrote:


On 2/17/23 08:17, Alexandre Oliva via Gcc-patches wrote:


Back when quotes were added around "+cdecp" in the "coproc must be
a constant immediate" error in arm-builtins.cc, tests for that message
lagged behind.  Fixed thusly.

Regstrapped on x86_64-linux-gnu.
Tested on arm-vxworks7 (gcc-12) and arm-eabi (trunk).  Ok to install?



It seems this changed with r12-6553-gc3782843badbf3, right?


Yup.


I see this commit added quotes in several others places: are the two
tests you fix the only ones impacted?


https://gcc.gnu.org/pipermail/gcc-patches/2023-February/612176.html in
asm-flag-4.c also fixed fallout from that patch, I realize now, but that
was all that came up in our testing.

I didn't start from that patch, I was just going through test results,
investigating the failures and fixing them or at least annotating the
failures as expected.

It is conceivable that other quoted strings appear in tests that are
skipped by all of the target variants that we test.  Indeed, I went
through some arm-*-eabi variants not long ago, and these didn't come up.
So, in case you're wondering whether to look for the other strings in
the tests or somesuch, please don't assume I've already done so.


OK thanks for the clarification.

(and for the other cleanup patches!)

Christophe

RE: [PATCH 1/2]middle-end: Fix wrong overmatching of div-bitmask by using new optabs [PR108583]

[Tamar Christina via Gcc-patches]

Hi Andrew,

> 
> all the range-op integer code is in gcc/range-op.cc.  As this is a basic
> binary operation, you should be able to get away with implementing a
> single routine,  wi_fold () which adds 2 wide int bounds  together and
> returns a result.  THis si the implelemntaion for operator_plus.
> 
> void
> operator_plus::wi_fold (irange , tree type,
>      const wide_int _lb, const wide_int _ub,
>      const wide_int _lb, const wide_int _ub) const
> {
>    wi::overflow_type ov_lb, ov_ub;
>    signop s = TYPE_SIGN (type);
>    wide_int new_lb = wi::add (lh_lb, rh_lb, s, _lb);
>    wide_int new_ub = wi::add (lh_ub, rh_ub, s, _ub);
>    value_range_with_overflow (r, type, new_lb, new_ub, ov_lb, ov_ub);
> }
> 
> 
> you shouldn't have to do any of the overflow stuff at the end, just take
> the 2 sets of wide int, double their precision to start, add them
> together (it cant possible overflow right) and then return an
> int_range<2> with those bounds...
> ie
> 
> void
> operator_plus::wi_fold (irange , tree type,
>      const wide_int _lb, const wide_int _ub,
>      const wide_int _lb, const wide_int _ub) const
> {
>    wi::overflow_type ov_lb, ov_ub;
>    signop s = TYPE_SIGN (type);
> 
>    // Do whatever wideint magic is required to do this adds in higher
> precision
>    wide_int new_lb = wi::add (lh_lb, rh_lb, s, _lb);
>    wide_int new_ub = wi::add (lh_ub, rh_ub, s, _ub);
> 
>    r = int_range<2> (type, new_lb, new_ub);
> }
> 

So I've been working on adding support for widening plus and widening 
multiplication,
and my examples all work now.. but during bootstrap I hit a problem.

Say you have a mixed sign widening multiplication, such as in:

int decMultiplyOp_zacc, decMultiplyOp_iacc;
int *decMultiplyOp_lp;
void decMultiplyOp() {
  decMultiplyOp_lp = _zacc;
  for (; decMultiplyOp_lp < _zacc + decMultiplyOp_iacc;
   decMultiplyOp_lp++)
*decMultiplyOp_lp = 0;
}

Eventually the pointer arithmetic will generate:

intD.7 decMultiplyOp_iacc.2_13;
long unsigned intD.11 _15;
_15 = decMultiplyOp_iacc.2_13 w* 4;
and it'll try to get the range from this.

My implementation is just:

void
operator_widen_mult::wi_fold (irange , tree type,
const wide_int _lb, const wide_int _ub,
const wide_int _lb, const wide_int _ub) const
{
  signop s = TYPE_SIGN (type);

  wide_int lh_wlb = wide_int::from (lh_lb, wi::get_precision (lh_lb) * 2, s);
  wide_int rh_wlb = wide_int::from (rh_lb, wi::get_precision (rh_lb) * 2, s);
  wide_int lh_wub = wide_int::from (lh_ub, wi::get_precision (lh_ub) * 2, s);
  wide_int rh_wub = wide_int::from (rh_ub, wi::get_precision (rh_ub) * 2, s);

  /* We don't expect a widening multiplication to be able to overflow but range
 calculations for multiplications are complicated.  After widening the
 operands lets call the base class.  */
  return operator_mult::wi_fold (r, type, lh_wlb, lh_wub, rh_wlb, rh_wub);
}

But in this case the operands are different types and the wi_fold only gets the
type of the operation. The issue is that when increasing the precision for lh_*
I need to sign extend the value and not zero extend, but I don't seem to have
enough context here to know that I do.  I'm missing the type of the operands.

For non-widening operations this doesn't matter as the precision stays the same.

Is there a way to get the information I need?

Thanks,
Tamar

> 
> The operator needs to be registered, I've attached the skeleton for it.
> you should just have to finish implementing wi_fold().
> 
> in theory :-)

Re: [PATCH] cygwin: Don't try to support multilibs [PR107998]

[Jonathan Yong via Gcc-patches]

On 2/22/23 09:25, Jakub Jelinek wrote:

Hi!

As discussed in the PR, t-cygwin-w64 file has been introduced in 2013
and has one important problem, two different multilib options -m64 and -m32,
but MULTILIB_DIRNAMES with just one word in it.
Before the genmultilib sanity checking was added, my understanding is that
this essentially resulted in effective --disable-multilib,
$ gcc -print-multi-lib
.;
;@m32
$ gcc -print-multi-directory
.
$ gcc -print-multi-directory -m64
.
$ gcc -print-multi-directory -m32

$ gcc -print-multi-os-directory
../lib
$ gcc -print-multi-os-directory -m64
../lib
$ gcc -print-multi-os-directory -m32
../lib32
and because of the way e.g. config-ml.in operates
multidirs=
for i in `${CC-gcc} --print-multi-lib 2>/dev/null`; do
   dir=`echo $i | sed -e 's/;.*$//'`
   if [ "${dir}" = "." ]; then
 true
   else
 if [ -z "${multidirs}" ]; then
   multidirs="${dir}"
 else
   multidirs="${multidirs} ${dir}"
 fi
   fi
done
dir was . first time (and so nothing was done) and empty
second time, multidirs empty too, so multidirs was set to empty
like it would be with --disable-multilib.

With the added sanity checking the build fails unless --disable-multilib
is used in configure (dunno whether people usually configure that way
on cygwin).


From what has been said in the PR, multilibs were not meant to be supported

and e.g. cygwin headers probably aren't ready for it.

So the following patch just removes the file with the (incorrect) multilib
stuff instead of fixing it (say by setting MULTILIB_DIRNAMES to 64 32).

I have no way to test this though, no Windows around, can anyone please
test this?  I just would like to get some progress on the P1s we have...

2023-02-22  Jakub Jelinek  

PR target/107998
* config.gcc (x86_64-*-cygwin*): Don't add i386/t-cygwin-w64 into
$tmake_file.
* config/i386/t-cygwin-w64: Remove.

--- gcc/config.gcc.jj   2023-02-18 12:38:30.803025062 +0100
+++ gcc/config.gcc  2023-02-21 17:07:12.143164563 +0100
@@ -2105,7 +2105,7 @@ x86_64-*-cygwin*)
need_64bit_isa=yes
tm_file="${tm_file} i386/unix.h i386/bsd.h i386/gas.h i386/cygming.h 
i386/cygwin.h i386/cygwin-w64.h i386/cygwin-stdint.h"
xm_file=i386/xm-cygwin.h
-   tmake_file="${tmake_file} i386/t-cygming t-slibgcc i386/t-cygwin-w64"
+   tmake_file="${tmake_file} i386/t-cygming t-slibgcc"
target_gtfiles="$target_gtfiles \$(srcdir)/config/i386/winnt.cc"
extra_options="${extra_options} i386/cygming.opt i386/cygwin.opt"
extra_objs="${extra_objs} winnt.o winnt-stubs.o"
--- gcc/config/i386/t-cygwin-w64.jj 2020-01-12 11:54:36.333414616 +0100
+++ gcc/config/i386/t-cygwin-w642023-02-21 17:06:44.121572616 +0100
@@ -1,3 +0,0 @@
-MULTILIB_OPTIONS = m64/m32
-MULTILIB_DIRNAMES = 64
-MULTILIB_OSDIRNAMES = ../lib ../lib32

Jakub



Achim, mind looking at this?
Resending due to mail client problems, hopefully not a duplicate.

Re: [PATCH] cygwin: Don't try to support multilibs [PR107998]

[Jonathan Yong via Gcc-patches]

On 2/22/23 09:25, Jakub Jelinek wrote:

Hi!

As discussed in the PR, t-cygwin-w64 file has been introduced in 2013
and has one important problem, two different multilib options -m64 and -m32,
but MULTILIB_DIRNAMES with just one word in it.
Before the genmultilib sanity checking was added, my understanding is that
this essentially resulted in effective --disable-multilib,
$ gcc -print-multi-lib
.;
;@m32
$ gcc -print-multi-directory
.
$ gcc -print-multi-directory -m64
.
$ gcc -print-multi-directory -m32

$ gcc -print-multi-os-directory
../lib
$ gcc -print-multi-os-directory -m64
../lib
$ gcc -print-multi-os-directory -m32
../lib32
and because of the way e.g. config-ml.in operates
multidirs=
for i in `${CC-gcc} --print-multi-lib 2>/dev/null`; do
   dir=`echo $i | sed -e 's/;.*$//'`
   if [ "${dir}" = "." ]; then
 true
   else
 if [ -z "${multidirs}" ]; then
   multidirs="${dir}"
 else
   multidirs="${multidirs} ${dir}"
 fi
   fi
done
dir was . first time (and so nothing was done) and empty
second time, multidirs empty too, so multidirs was set to empty
like it would be with --disable-multilib.

With the added sanity checking the build fails unless --disable-multilib
is used in configure (dunno whether people usually configure that way
on cygwin).


From what has been said in the PR, multilibs were not meant to be supported

and e.g. cygwin headers probably aren't ready for it.

So the following patch just removes the file with the (incorrect) multilib
stuff instead of fixing it (say by setting MULTILIB_DIRNAMES to 64 32).

I have no way to test this though, no Windows around, can anyone please
test this?  I just would like to get some progress on the P1s we have...

2023-02-22  Jakub Jelinek  

PR target/107998
* config.gcc (x86_64-*-cygwin*): Don't add i386/t-cygwin-w64 into
$tmake_file.
* config/i386/t-cygwin-w64: Remove.

--- gcc/config.gcc.jj   2023-02-18 12:38:30.803025062 +0100
+++ gcc/config.gcc  2023-02-21 17:07:12.143164563 +0100
@@ -2105,7 +2105,7 @@ x86_64-*-cygwin*)
need_64bit_isa=yes
tm_file="${tm_file} i386/unix.h i386/bsd.h i386/gas.h i386/cygming.h 
i386/cygwin.h i386/cygwin-w64.h i386/cygwin-stdint.h"
xm_file=i386/xm-cygwin.h
-   tmake_file="${tmake_file} i386/t-cygming t-slibgcc i386/t-cygwin-w64"
+   tmake_file="${tmake_file} i386/t-cygming t-slibgcc"
target_gtfiles="$target_gtfiles \$(srcdir)/config/i386/winnt.cc"
extra_options="${extra_options} i386/cygming.opt i386/cygwin.opt"
extra_objs="${extra_objs} winnt.o winnt-stubs.o"
--- gcc/config/i386/t-cygwin-w64.jj 2020-01-12 11:54:36.333414616 +0100
+++ gcc/config/i386/t-cygwin-w642023-02-21 17:06:44.121572616 +0100
@@ -1,3 +0,0 @@
-MULTILIB_OPTIONS = m64/m32
-MULTILIB_DIRNAMES = 64
-MULTILIB_OSDIRNAMES = ../lib ../lib32

Jakub



Achim,

Mind checking this out?

RE: [PATCH 1/2]middle-end: Fix wrong overmatching of div-bitmask by using new optabs [PR108583]

[Tamar Christina via Gcc-patches]

> -Original Message-
> From: Andrew MacLeod 
> Sent: Wednesday, February 15, 2023 6:43 PM
> To: Tamar Christina ; Richard Biener
> ; Richard Sandiford 
> Cc: Tamar Christina via Gcc-patches ; nd
> ; j...@ventanamicro.com
> Subject: Re: [PATCH 1/2]middle-end: Fix wrong overmatching of div-bitmask
> by using new optabs [PR108583]
> 
> 
> On 2/15/23 12:50, Andrew MacLeod wrote:
> >
> > On 2/15/23 12:13, Tamar Christina wrote:
> >>> On 2/15/23 07:51, Tamar Christina wrote:
> > void
> > operator_plus::wi_fold (irange , tree type,
> >     const wide_int _lb, const wide_int _ub,
> >     const wide_int _lb, const wide_int _ub)
> > const {
> >   wi::overflow_type ov_lb, ov_ub;
> >   signop s = TYPE_SIGN (type);
> >
> >   // Do whatever wideint magic is required to do this adds in higher
> > precision
> >   wide_int new_lb = wi::add (lh_lb, rh_lb, s, _lb);
> >   wide_int new_ub = wi::add (lh_ub, rh_ub, s, _ub);
> >
> >   r = int_range<2> (type, new_lb, new_ub); }
> >
> >
> > The operator needs to be registered, I've attached the skeleton for
> > it.  you should just have to finish implementing wi_fold().
> >
> > in theory :-)
> >
> You also mentioned earlier that some were tree codes, some were internal
> function calls?  We have some initial support for built in functions,
> but I am not familiar with all the various forms they can take.  We
> currently support CFN_ functions in

Ah then this should work, CFNs is are e helper class to combine compiler 
builtins
and internal functions in one structure.  So with support for CFN_ both should
be supported.  Probably just a matter of adding the new ops then.

> 
>    gimple-range-op.cc, gimple_range_op_handler::maybe_builtin_call ()
> 
> Basically this is part of a "gimple_range_op_handler"  wrapper for
> range-ops which can provide a range-ops class for stmts that don't map
> to a binary or unary form.. such as built in functions.
> 
> If you get to the point where you need this for a builtin function, I
> can help you through that too.  Although someone may have to also help
> me through what differentiates the different kinds of internal function
> :-)    I presume they are all similar in some way.

Will do! I'm hoping to range related vectorizer missed optimizations with this 
in
GCC 14 so I'll be back 

Cheers,
Tamar
> 
> Andrew
> 

Re: [PATCH] tree: Add 3 argument fndecl_built_in_p

[Richard Biener via Gcc-patches]

On Wed, Feb 22, 2023 at 1:17 PM Jonathan Wakely via Gcc-patches
 wrote:
>
> On Wed, 22 Feb 2023 at 11:49, Richard Biener  wrote:
> >
> > On Wed, 22 Feb 2023, Jakub Jelinek wrote:
> >
> > > On Wed, Feb 22, 2023 at 09:52:06AM +, Richard Biener wrote:
> > > > > The following testcase ICEs because we still have some spots that
> > > > > treat BUILT_IN_UNREACHABLE specially but not BUILT_IN_UNREACHABLE_TRAP
> > > > > the same.
> > >
> > > This patch uses (fndecl_built_in_p (node, BUILT_IN_UNREACHABLE)
> > >|| fndecl_built_in_p (node, BUILT_IN_UNREACHABLE_TRAP))
> > > a lot and from grepping around, we do something like that in lots of
> > > other places, or in some spots instead as
> > > (fndecl_built_in_p (node, BUILT_IN_NORMAL)
> > >  && (DECL_FUNCTION_CODE (node) == BUILT_IN_WHATEVER1
> > >  || DECL_FUNCTION_CODE (node) == BUILT_IN_WHATEVER2))
> > > The following patch adds an overload for this case, so we can write
> > > it in a shorter way.  It isn't worth for 3+, code in that case
> > > typically uses the fndecl_built_in_p (node, BUILT_IN_NORMAL)
> > > + switch in DECL_FUNCTION_CODE.
> > >
> > > If this isn't appropriate for GCC 13 (or not at all), I think we'll
> > > need to change at least ipa-prop.cc because it suffers from the same
> > > problem as the previous patch was fixing.
> >
> > Is it possible to use C++ (template) magic to expand the > 1 argument
> > case to
> >
> >   if (fndecl_built_in_p (BUILT_IN_NORMA)
> >   && (... || ... || ...
> >
> > lispy we'd expand to the head check and then recursively on the
> > first and the remaining args.
>
> In C++17 yes, there are fold expressions, so you'd write it as literally:
>
> if (fndecl_built_in_p (BUILT_IN_NORMA)
>   && (DECL_FUNCTION_CODE (node) == name || ...)
>
> Where "name" is a parameter pack, and the "..." is literally what the
> code would contain, not an abbreviation for the example :-)

Ah, that's nice.  But then I'd need to replace each arg with
DECL_FUNCTION_CODE (node) == arg, fold expressions seem to
only support literal replacement here?

> For C++11 you can write it recursively. Something like:

But sure, we're C++11 only ...

>
> // Single argument case terminates recursion.
> inline bool
> fndecl_built_in_matches_name_p (const_tree node, built_in_function name1)
> {
>   return DECL_FUNCTION_CODE (node) == name1;
> }
>
> // Recursive case. If names... is an empty pack then the overload above
> // is a better match.
> template
> inline bool
> fndecl_built_in_matches_name_p (const_tree node, built_in_function name1,
> Functions... names)
> {
>   return DECL_FUNCTION_CODE (node) == name1
>|| fndecl_built_in_matches_name_p (node, names...);
> }
>
> // Call with one or more names.
> template
> inline bool
> fndecl_built_in_p (const_tree node, built_in_function name1,
> Functions names...)
> {
>   return (fndecl_built_in_p (node, BUILT_IN_NORMAL)
>&& fndecl_built_in_matches_name_p (node, name1, names...);
> }
>
> I think the "is a better match" comment is the status of C++ after a
> DR, so might not actually be true in C++11 with GCC 4.8, I can check
> that (and if needed, rewrite the recursive case to avoid the problem).
>

Re: [PATCH] RISC-V: When the TARGET_COMPUTE_MULTILIB hook is implemented, check the version of each extension.

[Kito Cheng via Gcc-patches]

Hi Jin:

Curious, did you introduce version info into the multi-lib path in
your donwstream GCC? I suspect we need a more complete solution to
deal with the multiversion issue, so it would be great if you can
provide more experience with this part?

Thanks :)


On Wed, Feb 22, 2023 at 5:44 PM Jin Ma  wrote:
>
> When there is an extension with different versions, the result of the 
> TARGET_COMPUTE_MULTILIB hook
> is generally wrong, so the version needs to be considered.
>
> gcc/ChangeLog:
>
> * common/config/riscv/riscv-common.cc 
> (riscv_subset_list::match_score): Match the version
> of each extension.
> ---
>  gcc/common/config/riscv/riscv-common.cc | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/gcc/common/config/riscv/riscv-common.cc 
> b/gcc/common/config/riscv/riscv-common.cc
> index ebc1ed7d7e4..0a15ff705d1 100644
> --- a/gcc/common/config/riscv/riscv-common.cc
> +++ b/gcc/common/config/riscv/riscv-common.cc
> @@ -331,10 +331,9 @@ riscv_subset_list::match_score (riscv_subset_list *list) 
> const
>/* list must be subset of current this list, otherwise it not safe to
>   link.
>   TODO: We might give different weight for each extension, but the rule 
> could
> -  be complicated.
> - TODO: We might consider the version of each extension.  */
> +  be complicated.  */
>for (s = list->m_head; s != NULL; s = s->next)
> -if (this->lookup (s->name.c_str ()) != NULL)
> +if (this->lookup (s->name.c_str (), s->major_version, s->minor_version) 
> != NULL)
>score++;
>  else
>return 0;
> --
> 2.17.1
>

Re: [PATCH] [arm] adjust tests for quotes around +cdecp

[Alexandre Oliva via Gcc-patches]

Hello, Christophe,

On Feb 20, 2023, Christophe Lyon  wrote:

> On 2/17/23 08:17, Alexandre Oliva via Gcc-patches wrote:
>> 
>> Back when quotes were added around "+cdecp" in the "coproc must be
>> a constant immediate" error in arm-builtins.cc, tests for that message
>> lagged behind.  Fixed thusly.
>> 
>> Regstrapped on x86_64-linux-gnu.
>> Tested on arm-vxworks7 (gcc-12) and arm-eabi (trunk).  Ok to install?

> It seems this changed with r12-6553-gc3782843badbf3, right?

Yup.

> I see this commit added quotes in several others places: are the two
> tests you fix the only ones impacted?

https://gcc.gnu.org/pipermail/gcc-patches/2023-February/612176.html in
asm-flag-4.c also fixed fallout from that patch, I realize now, but that
was all that came up in our testing.

I didn't start from that patch, I was just going through test results,
investigating the failures and fixing them or at least annotating the
failures as expected.

It is conceivable that other quoted strings appear in tests that are
skipped by all of the target variants that we test.  Indeed, I went
through some arm-*-eabi variants not long ago, and these didn't come up.
So, in case you're wondering whether to look for the other strings in
the tests or somesuch, please don't assume I've already done so.

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

Re: [PATCH] tree: Add 3 argument fndecl_built_in_p

[Jonathan Wakely via Gcc-patches]

On Wed, 22 Feb 2023 at 12:16, Jonathan Wakely  wrote:
>
> On Wed, 22 Feb 2023 at 11:49, Richard Biener  wrote:
> >
> > On Wed, 22 Feb 2023, Jakub Jelinek wrote:
> >
> > > On Wed, Feb 22, 2023 at 09:52:06AM +, Richard Biener wrote:
> > > > > The following testcase ICEs because we still have some spots that
> > > > > treat BUILT_IN_UNREACHABLE specially but not BUILT_IN_UNREACHABLE_TRAP
> > > > > the same.
> > >
> > > This patch uses (fndecl_built_in_p (node, BUILT_IN_UNREACHABLE)
> > >|| fndecl_built_in_p (node, BUILT_IN_UNREACHABLE_TRAP))
> > > a lot and from grepping around, we do something like that in lots of
> > > other places, or in some spots instead as
> > > (fndecl_built_in_p (node, BUILT_IN_NORMAL)
> > >  && (DECL_FUNCTION_CODE (node) == BUILT_IN_WHATEVER1
> > >  || DECL_FUNCTION_CODE (node) == BUILT_IN_WHATEVER2))
> > > The following patch adds an overload for this case, so we can write
> > > it in a shorter way.  It isn't worth for 3+, code in that case
> > > typically uses the fndecl_built_in_p (node, BUILT_IN_NORMAL)
> > > + switch in DECL_FUNCTION_CODE.
> > >
> > > If this isn't appropriate for GCC 13 (or not at all), I think we'll
> > > need to change at least ipa-prop.cc because it suffers from the same
> > > problem as the previous patch was fixing.
> >
> > Is it possible to use C++ (template) magic to expand the > 1 argument
> > case to
> >
> >   if (fndecl_built_in_p (BUILT_IN_NORMA)
> >   && (... || ... || ...
> >
> > lispy we'd expand to the head check and then recursively on the
> > first and the remaining args.
>
> In C++17 yes, there are fold expressions, so you'd write it as literally:
>
> if (fndecl_built_in_p (BUILT_IN_NORMA)
>   && (DECL_FUNCTION_CODE (node) == name || ...)
>
> Where "name" is a parameter pack, and the "..." is literally what the
> code would contain, not an abbreviation for the example :-)
>
> For C++11 you can write it recursively. Something like:
>
>
> // Single argument case terminates recursion.
> inline bool
> fndecl_built_in_matches_name_p (const_tree node, built_in_function name1)
> {
>   return DECL_FUNCTION_CODE (node) == name1;
> }
>
> // Recursive case. If names... is an empty pack then the overload above
> // is a better match.
> template
> inline bool
> fndecl_built_in_matches_name_p (const_tree node, built_in_function name1,
> Functions... names)
> {
>   return DECL_FUNCTION_CODE (node) == name1
>|| fndecl_built_in_matches_name_p (node, names...);
> }
>
> // Call with one or more names.
> template
> inline bool
> fndecl_built_in_p (const_tree node, built_in_function name1,
> Functions names...)
> {
>   return (fndecl_built_in_p (node, BUILT_IN_NORMAL)
>&& fndecl_built_in_matches_name_p (node, name1, names...);
> }
>
> I think the "is a better match" comment is the status of C++ after a
> DR, so might not actually be true in C++11 with GCC 4.8, I can check
> that (and if needed, rewrite the recursive case to avoid the problem).

Yes, I was right, it doesn't work in gcc 4.8. This does though (with
typos above fixed too, and actually tested on GCC 4.8.5):

// Single argument case terminates recursion.
inline bool
fndecl_built_in_matches_name_p (const_tree node, built_in_function name1)
{
 return DECL_FUNCTION_CODE (node) == name1;
}

// Recursive case for two or more names.
template
inline bool
fndecl_built_in_matches_name_p (const_tree node, built_in_function name1,
   built_in_function name2,
   Functions... names)
{
 return DECL_FUNCTION_CODE (node) == name1
  || fndecl_built_in_matches_name_p (node, name2, names...);
}

// Call with one or more names.
template
inline bool
fndecl_built_in_p (const_tree node, built_in_function name1,
 Functions... names)
{
 return fndecl_built_in_p (node, BUILT_IN_NORMAL)
  && fndecl_built_in_matches_name_p (node, name1, names...);
}


The variadic template fndecl_builtin_p above can replace the existing
one in gcc/tree.h and will work for all the existing cases with a
single name argument, but also support multiple names.

[PATCH] Pass CXXFLAGS_FOR_BUILD to avoid build failure errors.

[Yash Shinde]

From: Richard Purdie 

If CXXFLAGS contains something unsupported by the build CXX, we see build 
failures (e.g. using -fmacro-prefix-map for the target).

ChangeLog:

* Makefile.in: Regenerate.
* Makefile.tpl: Add missing CXXFLAGS_FOR_BUILD overrides.

Signed-off-by: Richard Purdie 
Signed-off-by: Yash Shinde 
---
 Makefile.in  | 2 ++
 Makefile.tpl | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/Makefile.in b/Makefile.in
index 06a9398e172..4b0069b257c 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -178,6 +178,7 @@ BUILD_EXPORTS = \
 # built for the build system to override those in BASE_FLAGS_TO_PASS.
 EXTRA_BUILD_FLAGS = \
CFLAGS="$(CFLAGS_FOR_BUILD)" \
+   CXXFLAGS="$(CXXFLAGS_FOR_BUILD)" \
LDFLAGS="$(LDFLAGS_FOR_BUILD)"
 
 # This is the list of directories to built for the host system.
@@ -210,6 +211,7 @@ HOST_EXPORTS = \
CPP_FOR_BUILD="$(CPP_FOR_BUILD)"; export CPP_FOR_BUILD; \
CPPFLAGS_FOR_BUILD="$(CPPFLAGS_FOR_BUILD)"; export CPPFLAGS_FOR_BUILD; \
CXX_FOR_BUILD="$(CXX_FOR_BUILD)"; export CXX_FOR_BUILD; \
+   CXXFLAGS_FOR_BUILD="$(CXXFLAGS_FOR_BUILD)"; export CXXFLAGS_FOR_BUILD; \
DLLTOOL="$(DLLTOOL)"; export DLLTOOL; \
DSYMUTIL="$(DSYMUTIL)"; export DSYMUTIL; \
LD="$(LD)"; export LD; \
diff --git a/Makefile.tpl b/Makefile.tpl
index dfbd74b68f8..419b332953b 100644
--- a/Makefile.tpl
+++ b/Makefile.tpl
@@ -181,6 +181,7 @@ BUILD_EXPORTS = \
 # built for the build system to override those in BASE_FLAGS_TO_PASS.
 EXTRA_BUILD_FLAGS = \
CFLAGS="$(CFLAGS_FOR_BUILD)" \
+   CXXFLAGS="$(CXXFLAGS_FOR_BUILD)" \
LDFLAGS="$(LDFLAGS_FOR_BUILD)"
 
 # This is the list of directories to built for the host system.
@@ -213,6 +214,7 @@ HOST_EXPORTS = \
CPP_FOR_BUILD="$(CPP_FOR_BUILD)"; export CPP_FOR_BUILD; \
CPPFLAGS_FOR_BUILD="$(CPPFLAGS_FOR_BUILD)"; export CPPFLAGS_FOR_BUILD; \
CXX_FOR_BUILD="$(CXX_FOR_BUILD)"; export CXX_FOR_BUILD; \
+   CXXFLAGS_FOR_BUILD="$(CXXFLAGS_FOR_BUILD)"; export CXXFLAGS_FOR_BUILD; \
DLLTOOL="$(DLLTOOL)"; export DLLTOOL; \
DSYMUTIL="$(DSYMUTIL)"; export DSYMUTIL; \
LD="$(LD)"; export LD; \
-- 
2.39.0

[PATCH] libgcc_s: Use alias for __cpu_indicator_init instead of symver

[Yash Shinde]

From: Khem Raj 

Adapter from

https://gcc.gnu.org/ml/gcc-patches/2015-05/msg00899.html

This fix was debated but hasnt been applied gcc upstream since
they expect musl to support '@' in symbol versioning which is
a sun/gnu versioning extention. This patch however avoids the
need for the '@' symbols at all

libgcc/Changelog:

2015-05-11  Szabolcs Nagy  

* config/i386/cpuinfo.c (__cpu_indicator_init_local): Add.
(__cpu_indicator_init@GCC_4.8.0, __cpu_model@GCC_4.8.0): Remove.

* config/i386/t-linux (HOST_LIBGCC2_CFLAGS): Remove -DUSE_ELF_SYMVER.

gcc/Changelog:

2015-05-11  Szabolcs Nagy  

* config/i386/i386-expand.c (ix86_expand_builtin): Make 
__builtin_cpu_init
call __cpu_indicator_init_local instead of __cpu_indicator_init.

Signed-off-by: Khem Raj 
Signed-off-by: Yash Shinde 
---
 gcc/config/i386/i386-expand.cc | 4 ++--
 libgcc/config/i386/cpuinfo.c   | 6 +++---
 libgcc/config/i386/t-linux | 2 +-
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/gcc/config/i386/i386-expand.cc b/gcc/config/i386/i386-expand.cc
index 3eddbc94360..aee05e813cc 100644
--- a/gcc/config/i386/i386-expand.cc
+++ b/gcc/config/i386/i386-expand.cc
@@ -12647,10 +12647,10 @@ ix86_expand_builtin (tree exp, rtx target, rtx 
subtarget,
 {
 case IX86_BUILTIN_CPU_INIT:
   {
-   /* Make it call __cpu_indicator_init in libgcc.  */
+   /* Make it call __cpu_indicator_init_local in libgcc.a.  */
tree call_expr, fndecl, type;
type = build_function_type_list (integer_type_node, NULL_TREE);
-   fndecl = build_fn_decl ("__cpu_indicator_init", type);
+   fndecl = build_fn_decl ("__cpu_indicator_init_local", type);
call_expr = build_call_expr (fndecl, 0);
return expand_expr (call_expr, target, mode, EXPAND_NORMAL);
   }
diff --git a/libgcc/config/i386/cpuinfo.c b/libgcc/config/i386/cpuinfo.c
index dab1d98060f..cf824b4114a 100644
--- a/libgcc/config/i386/cpuinfo.c
+++ b/libgcc/config/i386/cpuinfo.c
@@ -63,7 +63,7 @@ __cpu_indicator_init (void)
 __cpu_features2);
 }
 
-#if defined SHARED && defined USE_ELF_SYMVER
-__asm__ (".symver __cpu_indicator_init, __cpu_indicator_init@GCC_4.8.0");
-__asm__ (".symver __cpu_model, __cpu_model@GCC_4.8.0");
+#ifndef SHARED
+int __cpu_indicator_init_local (void)
+  __attribute__ ((weak, alias ("__cpu_indicator_init")));
 #endif
diff --git a/libgcc/config/i386/t-linux b/libgcc/config/i386/t-linux
index 8506a635790..564296f788e 100644
--- a/libgcc/config/i386/t-linux
+++ b/libgcc/config/i386/t-linux
@@ -3,5 +3,5 @@
 # t-slibgcc-elf-ver and t-linux
 SHLIB_MAPFILES = libgcc-std.ver $(srcdir)/config/i386/libgcc-glibc.ver
 
-HOST_LIBGCC2_CFLAGS += -mlong-double-80 -DUSE_ELF_SYMVER $(CET_FLAGS)
+HOST_LIBGCC2_CFLAGS += -mlong-double-80 $(CET_FLAGS)
 CRTSTUFF_T_CFLAGS += $(CET_FLAGS)
-- 
2.39.0

[PATCH] Share work directories

[Yash Shinde]

From: Khem Raj 

Fix configure and Makefile files to read the defaults.hand t-oe from build 
directory,
so that the source can be shared between gcc-cross-initial, 
gcc-cross-intermediate, gcc-cross, gcc-runtime,
and also the sdk build which use a separate build directory compared to source 
directory.

While compiling gcc-crosssdk-initial-x86_64 on some host, there is
occasionally failure that test the existance of default.h doesn't work,
the reason is tm_include_list='** defaults.h' rather than tm_include_list='** 
./defaults.h'.
So we add the test condition for this situation.

gcc/ChangeLog:

* configure
* configure.ac
* mkconfig.sh

Signed-off-by: Khem Raj 
Signed-off-by: Hongxu Jia 
---
 gcc/configure| 4 ++--
 gcc/configure.ac | 4 ++--
 gcc/mkconfig.sh  | 4 ++--
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/gcc/configure b/gcc/configure
index 254f9b6c943..ff2a3e26049 100755
--- a/gcc/configure
+++ b/gcc/configure
@@ -13471,8 +13471,8 @@ for f in $tm_file; do
tm_include_list="${tm_include_list} $f"
;;
 defaults.h )
-   tm_file_list="${tm_file_list} \$(srcdir)/$f"
-   tm_include_list="${tm_include_list} $f"
+   tm_file_list="${tm_file_list} ./$f"
+   tm_include_list="${tm_include_list} ./$f"
;;
 * )
tm_file_list="${tm_file_list} \$(srcdir)/config/$f"
diff --git a/gcc/configure.ac b/gcc/configure.ac
index 62bc908b991..d36830cf2fb 100644
--- a/gcc/configure.ac
+++ b/gcc/configure.ac
@@ -2336,8 +2336,8 @@ for f in $tm_file; do
tm_include_list="${tm_include_list} $f"
;;
 defaults.h )
-   tm_file_list="${tm_file_list} \$(srcdir)/$f"
-   tm_include_list="${tm_include_list} $f"
+   tm_file_list="${tm_file_list} ./$f"
+   tm_include_list="${tm_include_list} ./$f"
;;
 * )
tm_file_list="${tm_file_list} \$(srcdir)/config/$f"
diff --git a/gcc/mkconfig.sh b/gcc/mkconfig.sh
index 054ede89647..3b2c2b9df37 100644
--- a/gcc/mkconfig.sh
+++ b/gcc/mkconfig.sh
@@ -77,7 +77,7 @@ if [ -n "$HEADERS" ]; then
 if [ $# -ge 1 ]; then
echo '#ifdef IN_GCC' >> ${output}T
for file in "$@"; do
-   if test x"$file" = x"defaults.h"; then
+   if test x"$file" = x"./defaults.h" -o x"$file" = x"defaults.h"; then
postpone_defaults_h="yes"
else
echo "# include \"$file\"" >> ${output}T
@@ -106,7 +106,7 @@ esac
 
 # If we postponed including defaults.h, add the #include now.
 if test x"$postpone_defaults_h" = x"yes"; then
-echo "# include \"defaults.h\"" >> ${output}T
+echo "# include \"./defaults.h\"" >> ${output}T
 fi
 
 # Add multiple inclusion protection guard, part two.
-- 
2.39.0

[committed] RISC-V: Make the test condition more strict for gcc.target/riscv/_Float16-zhinxmin-1.c

[Kito Cheng via Gcc-patches]

LTO might generate random string for the section name, which might contain `mv`,
then might cause random false alarm.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/_Float16-zhinxmin-1.c: Tweak test
condition.
---
 gcc/testsuite/gcc.target/riscv/_Float16-zhinxmin-1.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.target/riscv/_Float16-zhinxmin-1.c 
b/gcc/testsuite/gcc.target/riscv/_Float16-zhinxmin-1.c
index 0070ebf616c..fa049db5b93 100644
--- a/gcc/testsuite/gcc.target/riscv/_Float16-zhinxmin-1.c
+++ b/gcc/testsuite/gcc.target/riscv/_Float16-zhinxmin-1.c
@@ -5,6 +5,6 @@ _Float16 foo1 (_Float16 a, _Float16 b)
 {
 /* { dg-final { scan-assembler-not "fmv.h" } } */
 /* { dg-final { scan-assembler-not "fmv.s" } } */
-/* { dg-final { scan-assembler-times "mv" 1 } } */
+/* { dg-final { scan-assembler-times "mv\ta0" 1 } } */
 return b;
 }
-- 
2.37.2

Re: [PATCH] tree: Add 3 argument fndecl_built_in_p

[Jonathan Wakely via Gcc-patches]

On Wed, 22 Feb 2023 at 11:49, Richard Biener  wrote:
>
> On Wed, 22 Feb 2023, Jakub Jelinek wrote:
>
> > On Wed, Feb 22, 2023 at 09:52:06AM +, Richard Biener wrote:
> > > > The following testcase ICEs because we still have some spots that
> > > > treat BUILT_IN_UNREACHABLE specially but not BUILT_IN_UNREACHABLE_TRAP
> > > > the same.
> >
> > This patch uses (fndecl_built_in_p (node, BUILT_IN_UNREACHABLE)
> >|| fndecl_built_in_p (node, BUILT_IN_UNREACHABLE_TRAP))
> > a lot and from grepping around, we do something like that in lots of
> > other places, or in some spots instead as
> > (fndecl_built_in_p (node, BUILT_IN_NORMAL)
> >  && (DECL_FUNCTION_CODE (node) == BUILT_IN_WHATEVER1
> >  || DECL_FUNCTION_CODE (node) == BUILT_IN_WHATEVER2))
> > The following patch adds an overload for this case, so we can write
> > it in a shorter way.  It isn't worth for 3+, code in that case
> > typically uses the fndecl_built_in_p (node, BUILT_IN_NORMAL)
> > + switch in DECL_FUNCTION_CODE.
> >
> > If this isn't appropriate for GCC 13 (or not at all), I think we'll
> > need to change at least ipa-prop.cc because it suffers from the same
> > problem as the previous patch was fixing.
>
> Is it possible to use C++ (template) magic to expand the > 1 argument
> case to
>
>   if (fndecl_built_in_p (BUILT_IN_NORMA)
>   && (... || ... || ...
>
> lispy we'd expand to the head check and then recursively on the
> first and the remaining args.

In C++17 yes, there are fold expressions, so you'd write it as literally:

if (fndecl_built_in_p (BUILT_IN_NORMA)
  && (DECL_FUNCTION_CODE (node) == name || ...)

Where "name" is a parameter pack, and the "..." is literally what the
code would contain, not an abbreviation for the example :-)

For C++11 you can write it recursively. Something like:


// Single argument case terminates recursion.
inline bool
fndecl_built_in_matches_name_p (const_tree node, built_in_function name1)
{
  return DECL_FUNCTION_CODE (node) == name1;
}

// Recursive case. If names... is an empty pack then the overload above
// is a better match.
template
inline bool
fndecl_built_in_matches_name_p (const_tree node, built_in_function name1,
Functions... names)
{
  return DECL_FUNCTION_CODE (node) == name1
   || fndecl_built_in_matches_name_p (node, names...);
}

// Call with one or more names.
template
inline bool
fndecl_built_in_p (const_tree node, built_in_function name1,
Functions names...)
{
  return (fndecl_built_in_p (node, BUILT_IN_NORMAL)
   && fndecl_built_in_matches_name_p (node, name1, names...);
}

I think the "is a better match" comment is the status of C++ after a
DR, so might not actually be true in C++11 with GCC 4.8, I can check
that (and if needed, rewrite the recursive case to avoid the problem).

Re: [PATCH] RISC-V: Don't report an error until the link phase if suitable multilib isn't found.

[Kito Cheng via Gcc-patches]

This will break some scenario which is to build anything by themself,
which does not use any header or library from the builtin one.

So that's why the spec needs to guard so many conditions, no
-nostartfiles, -nodefaultlibs, -nolibc and -nostdlib appears.

 
"%{!nostartfiles:%{!nodefaultlibs:%{!nolibc:%{!nostdlib:%:riscv_multi_lib_check()
On Wed, Feb 22, 2023 at 6:26 PM Jin Ma  wrote:
>
> When suitable multilib isn't found, an error is not reported until the
> link period, which is inconsistent with the result of compiling option
> `-print-multi-directory`. For example, when suitable multilib isn't
> found, the return result of `-print-multi-directory` is the default
> value '.', while the actual execution result is an error during the
> link phase. This is not very reasonable.
>
> I think the error should be reported in advance, so that the compilation
> option `-print-multi-directory` will also report an error. The two
> should be consistent, either reporting errors or using default values.
>
> gcc/ChangeLog:
>
> * common/config/riscv/riscv-common.cc
> (riscv_compute_multilib): report an error if suitable multilib isn't 
> found.
> (struct riscv_multi_lib_info_t): Delet.
> (riscv_multi_lib_check): Likewise.
> * config/riscv/elf.h (LIB_SPEC): Likewise.
> * config/riscv/riscv.h (riscv_multi_lib_check): Likewise.
> (EXTRA_SPEC_FUNCTIONS): Likewise.
> ---
>  gcc/common/config/riscv/riscv-common.cc | 25 +
>  gcc/config/riscv/elf.h  |  3 +--
>  gcc/config/riscv/riscv.h|  4 +---
>  3 files changed, 7 insertions(+), 25 deletions(-)
>
> diff --git a/gcc/common/config/riscv/riscv-common.cc 
> b/gcc/common/config/riscv/riscv-common.cc
> index ebc1ed7d7e4..3f27ecf4b3c 100644
> --- a/gcc/common/config/riscv/riscv-common.cc
> +++ b/gcc/common/config/riscv/riscv-common.cc
> @@ -274,9 +274,6 @@ struct riscv_multi_lib_info_t {
>  const std::vector &);
>  };
>
> -/* Flag for checking if there is no suitable multi-lib found.  */
> -static bool riscv_no_matched_multi_lib;
> -
>  /* Used for record value of -march and -mabi.  */
>  static std::string riscv_current_arch_str;
>  static std::string riscv_current_abi_str;
> @@ -1396,21 +1393,6 @@ riscv_expand_arch_from_cpu (int argc ATTRIBUTE_UNUSED,
>return xasprintf ("-march=%s", arch.c_str());
>  }
>
> -/* Report error if not found suitable multilib.  */
> -const char *
> -riscv_multi_lib_check (int argc ATTRIBUTE_UNUSED,
> -  const char **argv ATTRIBUTE_UNUSED)
> -{
> -  if (riscv_no_matched_multi_lib)
> -fatal_error (
> -  input_location,
> -  "Cannot find suitable multilib set for %<-march=%s%>/%<-mabi=%s%>",
> -  riscv_current_arch_str.c_str (),
> -  riscv_current_abi_str.c_str ());
> -
> -  return "";
> -}
> -
>  /* We only override this in bare-metal toolchain.  */
>  #ifdef RISCV_USE_CUSTOMISED_MULTI_LIB
>
> @@ -1583,7 +1565,6 @@ riscv_compute_multilib (
>const char *this_path;
>size_t this_path_len;
>bool result;
> -  riscv_no_matched_multi_lib = false;
>riscv_subset_list *subset_list = NULL;
>
>std::vector multilib_infos;
> @@ -1709,7 +1690,11 @@ riscv_compute_multilib (
>
>if (best_match_multi_lib == -1)
>  {
> -  riscv_no_matched_multi_lib = true;
> +  fatal_error (
> +   input_location,
> +   "Cannot find suitable multilib set for %<-march=%s%>/%<-mabi=%s%>",
> +   riscv_current_arch_str.c_str (),
> +   riscv_current_abi_str.c_str ());
>return multilib_dir;
>  }
>else
> diff --git a/gcc/config/riscv/elf.h b/gcc/config/riscv/elf.h
> index a725c00b637..7b8dc29d4cb 100644
> --- a/gcc/config/riscv/elf.h
> +++ b/gcc/config/riscv/elf.h
> @@ -28,8 +28,7 @@ along with GCC; see the file COPYING3.  If not see
> Handle the circular dependence between libc and libgloss. */
>  #undef  LIB_SPEC
>  #define LIB_SPEC \
> -  "--start-group -lc %{!specs=nosys.specs:-lgloss} --end-group " \
> -  
> "%{!nostartfiles:%{!nodefaultlibs:%{!nolibc:%{!nostdlib:%:riscv_multi_lib_check()"
> +  "--start-group -lc %{!specs=nosys.specs:-lgloss} --end-group"
>
>  #undef  STARTFILE_SPEC
>  #define STARTFILE_SPEC "crt0%O%s crtbegin%O%s"
> diff --git a/gcc/config/riscv/riscv.h b/gcc/config/riscv/riscv.h
> index 5bc7f2f467d..b8fa5f022db 100644
> --- a/gcc/config/riscv/riscv.h
> +++ b/gcc/config/riscv/riscv.h
> @@ -46,13 +46,11 @@ along with GCC; see the file COPYING3.  If not see
>  extern const char *riscv_expand_arch (int argc, const char **argv);
>  extern const char *riscv_expand_arch_from_cpu (int argc, const char **argv);
>  extern const char *riscv_default_mtune (int argc, const char **argv);
> -extern const char *riscv_multi_lib_check (int argc, const char **argv);
>
>  # define EXTRA_SPEC_FUNCTIONS  \
>{ "riscv_expand_arch", riscv_expand_arch },  \
>{ 

Re: Rust: In 'type_for_mode' langhook also consider all 'int_n' modes/types (was: Modula-2 / Rust: Many targets failing)

[Richard Biener via Gcc-patches]

On Wed, 22 Feb 2023, Thomas Schwinge wrote:

> Hi!
> 
> Richard, you may remember your words from 
> "ICE: SIGSEGV in optab_for_tree_code (optabs.c:407) with -O 
> -fno-tree-scev-cprop -ftree-vectorize":
> 
> > Ideally we'd never use lang_hooks.types.type_for_mode (or _for_size) in the
> > middle-end but had a pure middle-end based implementation.
> 
> Is there a canonical PR or other discussion thread for that?

No, not that I'm aware of.

Richard.

> Here's another instance of this issue:
> 
> On 2022-12-19T22:23:45+0100, Jan-Benedict Glaw  wrote:
> > With the recent merges for Modula-2 and Rust, I see a good number of
> > targets failing with --enable-languages=all, mostly due to issues with
> > the Modula-2 driver.
> 
> Thanks for reporting.
> 
> >  Modula-2 related issues
> > [snipped]
> 
> >  Rust related issues
> > =
> >
> >  --target=msp430-elfbare
> > ~
> >   /var/lib/laminar/run/gcc-msp430-elfbare/24/toolchain-build/./gcc/xgcc 
> > -B/var/lib/laminar/run/gcc-msp430-elfbare/24/toolchain-build/./gcc/  -xrust 
> > -frust-incomplete-and-experimental-compiler-do-not-use -nostdinc /dev/null 
> > -S -o /dev/null -fself-test=../../gcc/gcc/testsuite/selftests
> >   : internal compiler error: Segmentation fault
> >   0xf2efbf crash_signal
> > ../../gcc/gcc/toplev.cc:314
> >   0x120c8c7 build_function_type(tree_node*, tree_node*, bool)
> > ../../gcc/gcc/tree.cc:7360
> >   0x120cc20 build_function_type_list(tree_node*, ...)
> > ../../gcc/gcc/tree.cc:7442
> >   0x120d16b build_common_builtin_nodes()
> > ../../gcc/gcc/tree.cc:9883
> >   0x8449b4 grs_langhook_init
> > ../../gcc/gcc/rust/rust-lang.cc:132
> >   0x8427b2 lang_dependent_init
> > ../../gcc/gcc/toplev.cc:1815
> >   0x8427b2 do_compile
> > ../../gcc/gcc/toplev.cc:2110
> >   Please submit a full bug report, with preprocessed source (by using 
> > -freport-bug).
> >   Please include the complete backtrace with any bug report.
> >   See  for instructions.
> >   make[1]: *** [../../gcc/gcc/rust/Make-lang.in:275: s-selftest-rust] 
> > Error 1
> 
> See also 
> "Test failure on msp430-elfbare target".
> 
> I confirm with both upstream GCC master branch and GCC/Rust master
> branch:
> 
> $ ../source-gcc/configure --target=msp430-elfbare --enable-languages=rust 
> [...]
> $ make all-gcc [...]
> [...]
> [...]/build-gcc/./gcc/xgcc -B[...]/build-gcc/./gcc/  -xc -nostdinc 
> /dev/null -S -o /dev/null -fself-test=../../source-gcc/gcc/testsuite/selftests
> -fself-test: 57323 pass(es) in 0.42 seconds
> echo timestamp > s-selftest-c
> [...]/build-gcc/./gcc/xgcc -B[...]/build-gcc/./gcc/  -xrust 
> -frust-incomplete-and-experimental-compiler-do-not-use -nostdinc /dev/null -S 
> -o /dev/null -fself-test=../../source-gcc/gcc/testsuite/selftests
> : internal compiler error: Segmentation fault
> 0xf51b9f crash_signal
> ../../source-gcc/gcc/toplev.cc:314
> 0x12e6a3a build_function_type(tree_node*, tree_node*, bool)
> ../../source-gcc/gcc/tree.cc:7447
> 0x12e6ee0 build_function_type_list(tree_node*, ...)
> ../../source-gcc/gcc/tree.cc:7529
> 0x12e748e build_common_builtin_nodes()
> ../../source-gcc/gcc/tree.cc:9977
> 0x7661c4 grs_langhook_init
> ../../source-gcc/gcc/rust/rust-lang.cc:128
> 0x762ac9 lang_dependent_init
> ../../source-gcc/gcc/toplev.cc:1815
> 0x762ac9 do_compile
> ../../source-gcc/gcc/toplev.cc:2110
> Please submit a full bug report, with preprocessed source (by using 
> -freport-bug).
> Please include the complete backtrace with any bug report.
> See  for instructions.
> make[1]: *** [s-selftest-rust] Error 1
> [...]
> 
> OK to push the attached
> "Rust: In 'type_for_mode' langhook also consider all 'int_n' modes/types"?
> 
> 
> Grüße
>  Thomas
> 
> 
> -
> Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
> München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
> Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
> München, HRB 106955
> 

-- 
Richard Biener 
SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg,
Germany; GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman;
HRB 36809 (AG Nuernberg)

Re: [PATCH] tree: Add 3 argument fndecl_built_in_p

[Richard Biener via Gcc-patches]

On Wed, 22 Feb 2023, Jakub Jelinek wrote:

> On Wed, Feb 22, 2023 at 09:52:06AM +, Richard Biener wrote:
> > > The following testcase ICEs because we still have some spots that
> > > treat BUILT_IN_UNREACHABLE specially but not BUILT_IN_UNREACHABLE_TRAP
> > > the same.
> 
> This patch uses (fndecl_built_in_p (node, BUILT_IN_UNREACHABLE)
>|| fndecl_built_in_p (node, BUILT_IN_UNREACHABLE_TRAP))
> a lot and from grepping around, we do something like that in lots of
> other places, or in some spots instead as
> (fndecl_built_in_p (node, BUILT_IN_NORMAL)
>  && (DECL_FUNCTION_CODE (node) == BUILT_IN_WHATEVER1
>  || DECL_FUNCTION_CODE (node) == BUILT_IN_WHATEVER2))
> The following patch adds an overload for this case, so we can write
> it in a shorter way.  It isn't worth for 3+, code in that case
> typically uses the fndecl_built_in_p (node, BUILT_IN_NORMAL)
> + switch in DECL_FUNCTION_CODE.
> 
> If this isn't appropriate for GCC 13 (or not at all), I think we'll
> need to change at least ipa-prop.cc because it suffers from the same
> problem as the previous patch was fixing.

Is it possible to use C++ (template) magic to expand the > 1 argument
case to

  if (fndecl_built_in_p (BUILT_IN_NORMA)
  && (... || ... || ...

lispy we'd expand to the head check and then recursively on the
first and the remaining args.

Richard.

> 2023-02-22  Jakub Jelinek  
> 
>   * tree.h (fndecl_built_in_p): New overload with 2 built_in_function
>   arguments.
>   * builtins.cc (fold_builtin_expect): Use it.
>   * gimplify.cc (goa_stabilize_expr): Likewise.
>   * cgraphclones.cc (cgraph_node::create_clone): Likewise.
>   * ipa-fnsummary.cc (compute_fn_summary): Likewise.
>   * omp-low.cc (setjmp_or_longjmp_p): Likewise.
>   * cgraph.cc (cgraph_edge::redirect_call_stmt_to_callee,
>   cgraph_update_edges_for_call_stmt_node,
>   cgraph_edge::verify_corresponds_to_fndecl,
>   cgraph_node::verify_node): Likewise.
>   * tree-stdarg.cc (optimize_va_list_gpr_fpr_size): Likewise.
>   * gimple-ssa-warn-access.cc (matching_alloc_calls_p): Likewise.
>   * ipa-prop.cc (try_make_edge_direct_virtual_call): Handle
>   BUILT_IN_UNREACHABLE_TRAP like BUILT_IN_UNREACHABLE.
> 
> --- gcc/tree.h.jj 2023-02-17 12:45:08.223636043 +0100
> +++ gcc/tree.h2023-02-22 11:25:31.608825229 +0100
> @@ -6615,6 +6615,18 @@ fndecl_built_in_p (const_tree node, buil
> && DECL_FUNCTION_CODE (node) == name);
>  }
>  
> +/* Faster variant of
> +   fndecl_built_in_p (NODE, NAME1) || fndecl_built_in_p (NODE, NAME2).  */
> +
> +inline bool
> +fndecl_built_in_p (const_tree node, built_in_function name1,
> +built_in_function name2)
> +{
> +  return (fndecl_built_in_p (node, BUILT_IN_NORMAL)
> +   && (DECL_FUNCTION_CODE (node) == name1
> +   || DECL_FUNCTION_CODE (node) == name2));
> +}
> +
>  /* A struct for encapsulating location information about an operator
> and the operation built from it.
>  
> --- gcc/builtins.cc.jj2023-02-14 12:09:57.163647987 +0100
> +++ gcc/builtins.cc   2023-02-22 11:29:43.800179949 +0100
> @@ -8625,8 +8625,8 @@ fold_builtin_expect (location_t loc, tre
>  
>if (TREE_CODE (inner) == CALL_EXPR
>&& (fndecl = get_callee_fndecl (inner))
> -  && (fndecl_built_in_p (fndecl, BUILT_IN_EXPECT)
> -   || fndecl_built_in_p (fndecl, BUILT_IN_EXPECT_WITH_PROBABILITY)))
> +  && fndecl_built_in_p (fndecl, BUILT_IN_EXPECT,
> + BUILT_IN_EXPECT_WITH_PROBABILITY))
>  return arg0;
>  
>inner = inner_arg0;
> --- gcc/gimplify.cc.jj2023-02-15 09:23:27.807390189 +0100
> +++ gcc/gimplify.cc   2023-02-22 11:32:38.446655528 +0100
> @@ -15815,8 +15815,8 @@ goa_stabilize_expr (tree *expr_p, gimple
>if (TREE_CODE (expr) == CALL_EXPR)
>   {
> if (tree fndecl = get_callee_fndecl (expr))
> - if (fndecl_built_in_p (fndecl, BUILT_IN_CLEAR_PADDING)
> - || fndecl_built_in_p (fndecl, BUILT_IN_MEMCMP))
> + if (fndecl_built_in_p (fndecl, BUILT_IN_CLEAR_PADDING,
> +BUILT_IN_MEMCMP))
> {
>   int nargs = call_expr_nargs (expr);
>   for (int i = 0; i < nargs; i++)
> --- gcc/cgraphclones.cc.jj2023-02-22 11:21:56.467934980 +0100
> +++ gcc/cgraphclones.cc   2023-02-22 11:28:30.272242754 +0100
> @@ -425,9 +425,8 @@ cgraph_node::create_clone (tree new_decl
>version.  The only exception is when the edge was proved to
>be unreachable during the cloning procedure.  */
>if (!e->callee
> -   || !(fndecl_built_in_p (e->callee->decl, BUILT_IN_UNREACHABLE)
> -|| fndecl_built_in_p (e->callee->decl,
> -  BUILT_IN_UNREACHABLE_TRAP)))
> +   || !fndecl_built_in_p (e->callee->decl, BUILT_IN_UNREACHABLE,
> +   BUILT_IN_UNREACHABLE_TRAP))
>  

Contents of PO file 'cpplib-13.1-b20230212.fr.po'

[Translation Project Robot]

cpplib-13.1-b20230212.fr.po.gz
Description: Binary data
The Translation Project robot, in the
name of your translation coordinator.

New French PO file for 'cpplib' (version 13.1-b20230212)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'cpplib' has been submitted
by the French team of translators.  The file is available at:

https://translationproject.org/latest/cpplib/fr.po

(This file, 'cpplib-13.1-b20230212.fr.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

https://translationproject.org/latest/cpplib/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

https://translationproject.org/domain/cpplib.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

Rust: In 'type_for_mode' langhook also consider all 'int_n' modes/types (was: Modula-2 / Rust: Many targets failing)

[Thomas Schwinge]

Hi!

Richard, you may remember your words from 
"ICE: SIGSEGV in optab_for_tree_code (optabs.c:407) with -O 
-fno-tree-scev-cprop -ftree-vectorize":

> Ideally we'd never use lang_hooks.types.type_for_mode (or _for_size) in the
> middle-end but had a pure middle-end based implementation.

Is there a canonical PR or other discussion thread for that?

Here's another instance of this issue:

On 2022-12-19T22:23:45+0100, Jan-Benedict Glaw  wrote:
> With the recent merges for Modula-2 and Rust, I see a good number of
> targets failing with --enable-languages=all, mostly due to issues with
> the Modula-2 driver.

Thanks for reporting.

>  Modula-2 related issues
> [snipped]

>  Rust related issues
> =
>
>  --target=msp430-elfbare
> ~
>   /var/lib/laminar/run/gcc-msp430-elfbare/24/toolchain-build/./gcc/xgcc 
> -B/var/lib/laminar/run/gcc-msp430-elfbare/24/toolchain-build/./gcc/  -xrust 
> -frust-incomplete-and-experimental-compiler-do-not-use -nostdinc /dev/null -S 
> -o /dev/null -fself-test=../../gcc/gcc/testsuite/selftests
>   : internal compiler error: Segmentation fault
>   0xf2efbf crash_signal
> ../../gcc/gcc/toplev.cc:314
>   0x120c8c7 build_function_type(tree_node*, tree_node*, bool)
> ../../gcc/gcc/tree.cc:7360
>   0x120cc20 build_function_type_list(tree_node*, ...)
> ../../gcc/gcc/tree.cc:7442
>   0x120d16b build_common_builtin_nodes()
> ../../gcc/gcc/tree.cc:9883
>   0x8449b4 grs_langhook_init
> ../../gcc/gcc/rust/rust-lang.cc:132
>   0x8427b2 lang_dependent_init
> ../../gcc/gcc/toplev.cc:1815
>   0x8427b2 do_compile
> ../../gcc/gcc/toplev.cc:2110
>   Please submit a full bug report, with preprocessed source (by using 
> -freport-bug).
>   Please include the complete backtrace with any bug report.
>   See  for instructions.
>   make[1]: *** [../../gcc/gcc/rust/Make-lang.in:275: s-selftest-rust] 
> Error 1

See also 
"Test failure on msp430-elfbare target".

I confirm with both upstream GCC master branch and GCC/Rust master
branch:

$ ../source-gcc/configure --target=msp430-elfbare --enable-languages=rust 
[...]
$ make all-gcc [...]
[...]
[...]/build-gcc/./gcc/xgcc -B[...]/build-gcc/./gcc/  -xc -nostdinc 
/dev/null -S -o /dev/null -fself-test=../../source-gcc/gcc/testsuite/selftests
-fself-test: 57323 pass(es) in 0.42 seconds
echo timestamp > s-selftest-c
[...]/build-gcc/./gcc/xgcc -B[...]/build-gcc/./gcc/  -xrust 
-frust-incomplete-and-experimental-compiler-do-not-use -nostdinc /dev/null -S 
-o /dev/null -fself-test=../../source-gcc/gcc/testsuite/selftests
: internal compiler error: Segmentation fault
0xf51b9f crash_signal
../../source-gcc/gcc/toplev.cc:314
0x12e6a3a build_function_type(tree_node*, tree_node*, bool)
../../source-gcc/gcc/tree.cc:7447
0x12e6ee0 build_function_type_list(tree_node*, ...)
../../source-gcc/gcc/tree.cc:7529
0x12e748e build_common_builtin_nodes()
../../source-gcc/gcc/tree.cc:9977
0x7661c4 grs_langhook_init
../../source-gcc/gcc/rust/rust-lang.cc:128
0x762ac9 lang_dependent_init
../../source-gcc/gcc/toplev.cc:1815
0x762ac9 do_compile
../../source-gcc/gcc/toplev.cc:2110
Please submit a full bug report, with preprocessed source (by using 
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.
make[1]: *** [s-selftest-rust] Error 1
[...]

OK to push the attached
"Rust: In 'type_for_mode' langhook also consider all 'int_n' modes/types"?


Grüße
 Thomas


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
>From cae898bef63db18cc40b94ee4d48f85aec258c02 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Wed, 22 Feb 2023 11:42:43 +0100
Subject: [PATCH] Rust: In 'type_for_mode' langhook also consider all 'int_n'
 modes/types

As reported in "Rust related issues" at the end of

"Modula-2 / Rust: Many targets failing",

"Test failure on msp430-elfbare target", for '--target=msp430-elfbar' we ICE:

: internal compiler error: Segmentation fault
0xf2efbf crash_signal
  ../../gcc/gcc/toplev.cc:314
0x120c8c7 build_function_type(tree_node*, tree_node*, bool)
  ../../gcc/gcc/tree.cc:7360
0x120cc20 build_function_type_list(tree_node*, ...)
  ../../gcc/gcc/tree.cc:7442
0x120d16b 

[PATCH] tree: Add 3 argument fndecl_built_in_p

[Jakub Jelinek via Gcc-patches]

On Wed, Feb 22, 2023 at 09:52:06AM +, Richard Biener wrote:
> > The following testcase ICEs because we still have some spots that
> > treat BUILT_IN_UNREACHABLE specially but not BUILT_IN_UNREACHABLE_TRAP
> > the same.

This patch uses (fndecl_built_in_p (node, BUILT_IN_UNREACHABLE)
 || fndecl_built_in_p (node, BUILT_IN_UNREACHABLE_TRAP))
a lot and from grepping around, we do something like that in lots of
other places, or in some spots instead as
(fndecl_built_in_p (node, BUILT_IN_NORMAL)
 && (DECL_FUNCTION_CODE (node) == BUILT_IN_WHATEVER1
 || DECL_FUNCTION_CODE (node) == BUILT_IN_WHATEVER2))
The following patch adds an overload for this case, so we can write
it in a shorter way.  It isn't worth for 3+, code in that case
typically uses the fndecl_built_in_p (node, BUILT_IN_NORMAL)
+ switch in DECL_FUNCTION_CODE.

If this isn't appropriate for GCC 13 (or not at all), I think we'll
need to change at least ipa-prop.cc because it suffers from the same
problem as the previous patch was fixing.

2023-02-22  Jakub Jelinek  

* tree.h (fndecl_built_in_p): New overload with 2 built_in_function
arguments.
* builtins.cc (fold_builtin_expect): Use it.
* gimplify.cc (goa_stabilize_expr): Likewise.
* cgraphclones.cc (cgraph_node::create_clone): Likewise.
* ipa-fnsummary.cc (compute_fn_summary): Likewise.
* omp-low.cc (setjmp_or_longjmp_p): Likewise.
* cgraph.cc (cgraph_edge::redirect_call_stmt_to_callee,
cgraph_update_edges_for_call_stmt_node,
cgraph_edge::verify_corresponds_to_fndecl,
cgraph_node::verify_node): Likewise.
* tree-stdarg.cc (optimize_va_list_gpr_fpr_size): Likewise.
* gimple-ssa-warn-access.cc (matching_alloc_calls_p): Likewise.
* ipa-prop.cc (try_make_edge_direct_virtual_call): Handle
BUILT_IN_UNREACHABLE_TRAP like BUILT_IN_UNREACHABLE.

--- gcc/tree.h.jj   2023-02-17 12:45:08.223636043 +0100
+++ gcc/tree.h  2023-02-22 11:25:31.608825229 +0100
@@ -6615,6 +6615,18 @@ fndecl_built_in_p (const_tree node, buil
  && DECL_FUNCTION_CODE (node) == name);
 }
 
+/* Faster variant of
+   fndecl_built_in_p (NODE, NAME1) || fndecl_built_in_p (NODE, NAME2).  */
+
+inline bool
+fndecl_built_in_p (const_tree node, built_in_function name1,
+  built_in_function name2)
+{
+  return (fndecl_built_in_p (node, BUILT_IN_NORMAL)
+ && (DECL_FUNCTION_CODE (node) == name1
+ || DECL_FUNCTION_CODE (node) == name2));
+}
+
 /* A struct for encapsulating location information about an operator
and the operation built from it.
 
--- gcc/builtins.cc.jj  2023-02-14 12:09:57.163647987 +0100
+++ gcc/builtins.cc 2023-02-22 11:29:43.800179949 +0100
@@ -8625,8 +8625,8 @@ fold_builtin_expect (location_t loc, tre
 
   if (TREE_CODE (inner) == CALL_EXPR
   && (fndecl = get_callee_fndecl (inner))
-  && (fndecl_built_in_p (fndecl, BUILT_IN_EXPECT)
- || fndecl_built_in_p (fndecl, BUILT_IN_EXPECT_WITH_PROBABILITY)))
+  && fndecl_built_in_p (fndecl, BUILT_IN_EXPECT,
+   BUILT_IN_EXPECT_WITH_PROBABILITY))
 return arg0;
 
   inner = inner_arg0;
--- gcc/gimplify.cc.jj  2023-02-15 09:23:27.807390189 +0100
+++ gcc/gimplify.cc 2023-02-22 11:32:38.446655528 +0100
@@ -15815,8 +15815,8 @@ goa_stabilize_expr (tree *expr_p, gimple
   if (TREE_CODE (expr) == CALL_EXPR)
{
  if (tree fndecl = get_callee_fndecl (expr))
-   if (fndecl_built_in_p (fndecl, BUILT_IN_CLEAR_PADDING)
-   || fndecl_built_in_p (fndecl, BUILT_IN_MEMCMP))
+   if (fndecl_built_in_p (fndecl, BUILT_IN_CLEAR_PADDING,
+  BUILT_IN_MEMCMP))
  {
int nargs = call_expr_nargs (expr);
for (int i = 0; i < nargs; i++)
--- gcc/cgraphclones.cc.jj  2023-02-22 11:21:56.467934980 +0100
+++ gcc/cgraphclones.cc 2023-02-22 11:28:30.272242754 +0100
@@ -425,9 +425,8 @@ cgraph_node::create_clone (tree new_decl
 version.  The only exception is when the edge was proved to
 be unreachable during the cloning procedure.  */
   if (!e->callee
- || !(fndecl_built_in_p (e->callee->decl, BUILT_IN_UNREACHABLE)
-  || fndecl_built_in_p (e->callee->decl,
-BUILT_IN_UNREACHABLE_TRAP)))
+ || !fndecl_built_in_p (e->callee->decl, BUILT_IN_UNREACHABLE,
+ BUILT_IN_UNREACHABLE_TRAP))
 e->redirect_callee_duplicating_thunks (new_node);
 }
   new_node->expand_all_artificial_thunks ();
--- gcc/ipa-fnsummary.cc.jj 2023-01-02 09:32:45.510951148 +0100
+++ gcc/ipa-fnsummary.cc2023-02-22 11:33:07.99473 +0100
@@ -3180,8 +3180,8 @@ compute_fn_summary (struct cgraph_node *
   for (e = node->callees; e; e = e->next_callee)
 {
   tree cdecl = e->callee->decl;
-  

[wwwdocs, patch] OpenMP update for gcc-13/changes.html + projects/gomp/

[Tobias Burnus]

Update the release notes and the impl.status for some newer
changes: Reverse offload for AMD GCN now works.

Additionally, I thinko for TR11 was fixed (propagating a libgomp.texi
change): the other clauses already support 'strict' as listed elsewhere
(earlier OpenMP version and alreaddy implemented in GCC).

Comments? Suggestions?

Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
OpenMP update for gcc-13/changes.html + projects/gomp/

diff --git a/htdocs/gcc-13/changes.html b/htdocs/gcc-13/changes.html
index 5dbcc229..03b51bef 100644
--- a/htdocs/gcc-13/changes.html
+++ b/htdocs/gcc-13/changes.html
@@ -60,19 +60,19 @@ a work-in-progress.
 General Improvements
 
 
   https://gcc.gnu.org/projects/gomp/;>OpenMP
   
 
-  Reverse offload is now supported with nvptx devices. Additionally, the
-  requires handling has been improved and all clauses are
-  now accepted. If a requirement cannot be fulfilled for an accessible
-  device, this device is excluded from the list of available devices. This
-  may imply that the only device left is the host (the initial device).
-  In particular, requires_offload is currently unsupported on
-  AMD GCN devices while unified_address and
+  Reverse offload is now supported with nvptx and AMD GCN devices.
+  Additionally, the requires handling has been improved and
+  all clauses are now accepted. If a requirement cannot be fulfilled for
+  an accessible device, this device is excluded from the list of
+  available devices. This may imply that the only device left is the host
+  (the initial device).
+  In particular, unified_address and
   unified_shared_memory are unsupported by all non-host
   devices.
 
 
   OpenMP 5.0: Fortran now supports some non-rectangular loop nests; for
   C/C++, the support was added in GCC 11.
diff --git a/htdocs/projects/gomp/index.html b/htdocs/projects/gomp/index.html
index b2b3b0c8..3ef4f502 100644
--- a/htdocs/projects/gomp/index.html
+++ b/htdocs/projects/gomp/index.html
@@ -312,14 +312,14 @@ than listed, depending on resolved corner cases and optimizations.
   GCC12
   GCC13
 
 
   (atomic_default_mem_order)
   (dynamic_allocators)
-  complete but no non-host devices provides unified_address,
-  unified_shared_memory or reverse_offload
+  complete but no non-host devices provides unified_address or
+  unified_shared_memory
 
   
   
 conditional modifier to lastprivate clause
 GCC10
 
@@ -429,13 +429,13 @@ than listed, depending on resolved corner cases and optimizations.
 
   GCC12
   GCC13
 
 
   Reverse offload unsupported
-  See comment for requires
+  Reverse offload supported
 
   
   
 Mapping C/C++ pointer variables and to assign the address of device memory mapped by an array section
 GCC12
 
@@ -1059,14 +1059,13 @@ error.
   
 omp_get_max_progress_width runtime routine
 No
 
   
   
-strict modifier keyword to num_threads, num_tasks
-  and grainsize
+strict modifier keyword to num_threads
 No
 
   
   
 memscope clause to atomic and flush
 No

Contents of PO file 'cpplib-13.1-b20230212.uk.po'

[Translation Project Robot]

cpplib-13.1-b20230212.uk.po.gz
Description: Binary data
The Translation Project robot, in the
name of your translation coordinator.

New Ukrainian PO file for 'cpplib' (version 13.1-b20230212)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'cpplib' has been submitted
by the Ukrainian team of translators.  The file is available at:

https://translationproject.org/latest/cpplib/uk.po

(This file, 'cpplib-13.1-b20230212.uk.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

https://translationproject.org/latest/cpplib/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

https://translationproject.org/domain/cpplib.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

Re: [PATCH, rs6000] Merge two vector shift when their sources are the same

[Kewen.Lin via Gcc-patches]

Hi Haochen,

on 2023/2/20 10:04, HAO CHEN GUI wrote:
> Hi,
>   This patch merges two "vsldoi" insns when their sources are the
> same. Particularly, it is simplified to be one move if the total
> shift is multiples of 16 bytes.
> 
>   Bootstrapped and tested on powerpc64-linux BE and LE with no
> regressions.
> 
> Thanks
> Gui Haochen
> 
> 
> ChangeLog
> 2023-02-20  Haochen Gui 
> 
> gcc/
>   * config/rs6000/altivec.md (*altivec_vsldoi_dup_): New
>   insn_and_split to merge two vsldoi.
> 
> gcc/testsuite/
>   * gcc.target/powerpc/vsldoi_merge.c: New.
> 
> 
> patch.diff
> diff --git a/gcc/config/rs6000/altivec.md b/gcc/config/rs6000/altivec.md
> index 84660073f32..22e9c4c1fc5 100644
> --- a/gcc/config/rs6000/altivec.md
> +++ b/gcc/config/rs6000/altivec.md
> @@ -2529,6 +2529,35 @@ (define_insn "altivec_vsldoi_"
>"vsldoi %0,%1,%2,%3"
>[(set_attr "type" "vecperm")])
> 
> +(define_insn_and_split "*altivec_vsldoi_dup_"
> +  [(set (match_operand:VM 0 "register_operand" "=v")
> + (unspec:VM [(unspec:VM [(match_operand:VM 1 "register_operand" "v")
> + (match_operand:VM 2 "register_operand" "v")
> + (match_operand:QI 3 "immediate_operand" "i")]
> +UNSPEC_VSLDOI)
> + (unspec:VM [(match_dup 1)
> + (match_dup 2)
> + (match_dup 3)]
> +UNSPEC_VSLDOI)
> + (match_operand:QI 4 "immediate_operand" "i")]
> +UNSPEC_VSLDOI))]
> +  "TARGET_ALTIVEC"
> +  "#"
> +  "&& 1"
> +  [(const_int 0)]
> +{
> +  unsigned int shift1 = UINTVAL (operands[3]);
> +  unsigned int shift2 = UINTVAL (operands[4]);
> +
> +  unsigned int shift = (shift1 + shift2) % 16;
> +  if (shift)
> +emit_insn (gen_altivec_vsldoi_ (operands[0], operands[1],
> +   operands[1], GEN_INT (shift)));
> +  else
> +emit_move_insn (operands[0], operands[1]);
> +  DONE;
> +})

This patch looks wrong, I think we need to ensure operand 1 and operand 2
are the same (dup 1 for 2)? one simple counter example for this proposed
fix is that two given vector a {A0, A1} and {B0, B1} (all A0/A1/B0/B1 are
doublewords) on BE:

a = vec_sld (a, b, 8);  // (1) res a = {A1, B0}
a = vec_sld (a, a, 8);  // (2) res a = {B0, A1}

it would get the unexpected result a {A0, A1} with this patch.

Since this patch got bootstrapped and regress-tested, I think we don't
have enough coverage on this part, it's a good thing to add one dg-do run
test case as well. :)

BR,
Kewen

Re: [PATCH 1/2] PR target/107299: Fix build issue when long double is IEEE 128-bit

[Kewen.Lin via Gcc-patches]

Hi Mike,

on 2023/2/3 13:49, Michael Meissner wrote:
> This patch is a repost of a patch:
> 
> | Date: Thu, 19 Jan 2023 11:37:27 -0500
> | Subject: [PATCH] PR target/107299: Fix build issue when long double is IEEE 
> 128-bit
> | Message-ID: 
> 
> This patch updates the IEEE 128-bit types used in libgcc.
> 
> At the moment, we cannot build GCC when the target uses IEEE 128-bit long
> doubles, such as building the compiler for a native Fedora 36 system.  The
> build dies when it is trying to build the _mulkc3.c and _divkc3 modules.
> 
> This patch changes libgcc to use long double for the IEEE 128-bit base type if
> long double is IEEE 128-bit, and it uses _Float128 otherwise.  The built-in
> functions are adjusted to be the correct version based on the IEEE 128-bit 
> base
> type used.
> 
> While it is desirable to ultimately have __float128 and _Float128 use the same
> internal type and mode within GCC, at present if you use the option
> -mabi=ieeelongdouble, the __float128 type will use the long double type and 
> not
> the _Float128 type.  We get an internal compiler error if we combine the
> signbitf128 built-in with a long double type.
> 
> I've gone through several iterations of trying to fix this within GCC, and
> there are various problems that have come up.  I developed this alternative
> patch that changes libgcc so that it does not tickle the issue.  I hope we can
> fix the compiler at some point, but right now, this is preventing people on
> Fedora 36 systems from building compilers where the default long double is 
> IEEE
> 128-bit.

Thanks for working on this!  If updating libgcc source to workaround this issue
is the best option we can have at this moment, it's fine.  Comparing to one
previous proposal which removes the workaround in build_common_tree_nodes for
rs6000 KFmode, a bit concern on this one is that users can still meet the ICE
with a simple case like:

typedef float TFtype __attribute__((mode (TF)));

TFtype
test (TFtype t)
{
  return __builtin_copysignf128 (1.0q, t);
}

but I guess they would write this kind of code very rarely?

BR,
Kewen

Re: [PATCH] rs6000: fmr gets used instead of faster xxlor [PR93571]

[Ajit Agarwal via Gcc-patches]

On 21/02/23 7:39 pm, Segher Boessenkool wrote:
> On Tue, Feb 21, 2023 at 06:00:52PM +0530, Ajit Agarwal wrote:
>> On 21/02/23 4:34 pm, Segher Boessenkool wrote:
>>> Please domn't use a switch, it isn't needed.  Instead use the "isa"
>>> attribute (with p7v here), and put the preferred alternative first.
>>
>> I am not sure how this is possible without switch and using only "isa".
> 
> You have the "p7v" "xxlor" alternative earlier than the "*" "fmr"
> alternative.  You can have an "xxlor" for contraints "d", but probably
> the best (and certainly the easiest) is to just move the existing
> xxlor to before fmr.
> 
> Oh, the existing xxlor alternative is implicitly isa p7v, the "wa"
> constraint causes that.  It may be nicer to mark it explicitly p7v as
> well, nicer for the reader.
> 

If I do the above, for power9 it selects xxlor instead of fmr.

> Btw, please update the other similar patterns at the same time?  There
> are eight patterns with fmr in rs6000.md (the four in dfp.md should
> probably not be touched); not all are similar so should be in separate
> patches, if changed at all, but a bunch are completely analogous so
> should not diverge.
> 
> (It is fine to first do this one pattern only, until we have worked out
> all kinks, but all should be committed at the same time).
> 
> Thanks,
> 
> 
> Segher

[PATCH] RISC-V: Don't report an error until the link phase if suitable multilib isn't found.

[Jin Ma via Gcc-patches]

When suitable multilib isn't found, an error is not reported until the
link period, which is inconsistent with the result of compiling option
`-print-multi-directory`. For example, when suitable multilib isn't
found, the return result of `-print-multi-directory` is the default
value '.', while the actual execution result is an error during the
link phase. This is not very reasonable.

I think the error should be reported in advance, so that the compilation
option `-print-multi-directory` will also report an error. The two
should be consistent, either reporting errors or using default values.

gcc/ChangeLog:

* common/config/riscv/riscv-common.cc
(riscv_compute_multilib): report an error if suitable multilib isn't 
found.
(struct riscv_multi_lib_info_t): Delet.
(riscv_multi_lib_check): Likewise.
* config/riscv/elf.h (LIB_SPEC): Likewise.
* config/riscv/riscv.h (riscv_multi_lib_check): Likewise.
(EXTRA_SPEC_FUNCTIONS): Likewise.
---
 gcc/common/config/riscv/riscv-common.cc | 25 +
 gcc/config/riscv/elf.h  |  3 +--
 gcc/config/riscv/riscv.h|  4 +---
 3 files changed, 7 insertions(+), 25 deletions(-)

diff --git a/gcc/common/config/riscv/riscv-common.cc 
b/gcc/common/config/riscv/riscv-common.cc
index ebc1ed7d7e4..3f27ecf4b3c 100644
--- a/gcc/common/config/riscv/riscv-common.cc
+++ b/gcc/common/config/riscv/riscv-common.cc
@@ -274,9 +274,6 @@ struct riscv_multi_lib_info_t {
 const std::vector &);
 };
 
-/* Flag for checking if there is no suitable multi-lib found.  */
-static bool riscv_no_matched_multi_lib;
-
 /* Used for record value of -march and -mabi.  */
 static std::string riscv_current_arch_str;
 static std::string riscv_current_abi_str;
@@ -1396,21 +1393,6 @@ riscv_expand_arch_from_cpu (int argc ATTRIBUTE_UNUSED,
   return xasprintf ("-march=%s", arch.c_str());
 }
 
-/* Report error if not found suitable multilib.  */
-const char *
-riscv_multi_lib_check (int argc ATTRIBUTE_UNUSED,
-  const char **argv ATTRIBUTE_UNUSED)
-{
-  if (riscv_no_matched_multi_lib)
-fatal_error (
-  input_location,
-  "Cannot find suitable multilib set for %<-march=%s%>/%<-mabi=%s%>",
-  riscv_current_arch_str.c_str (),
-  riscv_current_abi_str.c_str ());
-
-  return "";
-}
-
 /* We only override this in bare-metal toolchain.  */
 #ifdef RISCV_USE_CUSTOMISED_MULTI_LIB
 
@@ -1583,7 +1565,6 @@ riscv_compute_multilib (
   const char *this_path;
   size_t this_path_len;
   bool result;
-  riscv_no_matched_multi_lib = false;
   riscv_subset_list *subset_list = NULL;
 
   std::vector multilib_infos;
@@ -1709,7 +1690,11 @@ riscv_compute_multilib (
 
   if (best_match_multi_lib == -1)
 {
-  riscv_no_matched_multi_lib = true;
+  fatal_error (
+   input_location,
+   "Cannot find suitable multilib set for %<-march=%s%>/%<-mabi=%s%>",
+   riscv_current_arch_str.c_str (),
+   riscv_current_abi_str.c_str ());
   return multilib_dir;
 }
   else
diff --git a/gcc/config/riscv/elf.h b/gcc/config/riscv/elf.h
index a725c00b637..7b8dc29d4cb 100644
--- a/gcc/config/riscv/elf.h
+++ b/gcc/config/riscv/elf.h
@@ -28,8 +28,7 @@ along with GCC; see the file COPYING3.  If not see
Handle the circular dependence between libc and libgloss. */
 #undef  LIB_SPEC
 #define LIB_SPEC \
-  "--start-group -lc %{!specs=nosys.specs:-lgloss} --end-group " \
-  
"%{!nostartfiles:%{!nodefaultlibs:%{!nolibc:%{!nostdlib:%:riscv_multi_lib_check()"
+  "--start-group -lc %{!specs=nosys.specs:-lgloss} --end-group"
 
 #undef  STARTFILE_SPEC
 #define STARTFILE_SPEC "crt0%O%s crtbegin%O%s"
diff --git a/gcc/config/riscv/riscv.h b/gcc/config/riscv/riscv.h
index 5bc7f2f467d..b8fa5f022db 100644
--- a/gcc/config/riscv/riscv.h
+++ b/gcc/config/riscv/riscv.h
@@ -46,13 +46,11 @@ along with GCC; see the file COPYING3.  If not see
 extern const char *riscv_expand_arch (int argc, const char **argv);
 extern const char *riscv_expand_arch_from_cpu (int argc, const char **argv);
 extern const char *riscv_default_mtune (int argc, const char **argv);
-extern const char *riscv_multi_lib_check (int argc, const char **argv);
 
 # define EXTRA_SPEC_FUNCTIONS  \
   { "riscv_expand_arch", riscv_expand_arch },  \
   { "riscv_expand_arch_from_cpu", riscv_expand_arch_from_cpu },
\
-  { "riscv_default_mtune", riscv_default_mtune },  \
-  { "riscv_multi_lib_check", riscv_multi_lib_check },
+  { "riscv_default_mtune", riscv_default_mtune },
 
 /* Support for a compile-time default CPU, et cetera.  The rules are:
--with-arch is ignored if -march or -mcpu is specified.
-- 
2.17.1

New template for 'gcc' made available

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.  (If you have
any questions, send them to .)

A new POT file for textual domain 'gcc' has been made available
to the language teams for translation.  It is archived as:

https://translationproject.org/POT-files/gcc-13.1-b20230212.pot

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

Below is the URL which has been provided to the translators of your
package.  Please inform the translation coordinator, at the address
at the bottom, if this information is not current:

https://gcc.gnu.org/pub/gcc/snapshots/13-20230212/gcc-13-20230212.tar.xz

Translated PO files will later be automatically e-mailed to you.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

Rust: Move void_list_node init to common code (was: [PATCH] Move void_list_node init to common code)

[Thomas Schwinge]

Hi!

On 2022-09-14T16:06:55+0200, Richard Biener via Gcc-patches 
 wrote:
> All frontends replicate this, so move it.

At that time, the Rust front end was not yet in master branch; I've now
pushed to master branch commit 334f23d83261997ca89d8919b94b97aa22003a65
"Rust: Move void_list_node init to common code", see attached.


Grüße
 Thomas


> Bootstrap and regtest running for all languages on
> x86_64-unknown-linux-gnu.
>
> OK if that succeeds?
>
> Thanks,
> Richard.
>
> gcc/
>   * tree.cc (build_common_tree_nodes): Initialize void_list_node
>   here.
>
> gcc/ada/
>   * gcc-interface/trans.cc (gigi): Do not initialize void_list_node.
>
> gcc/c-family/
>   * c-common.h (build_void_list_node): Remove.
>   * c-common.cc (c_common_nodes_and_builtins): Do not initialize
>   void_list_node.
>
> gcc/c/
>   * c-decl.cc (build_void_list_node): Remove.
>
> gcc/cp/
>   * decl.cc (cxx_init_decl_processing): Inline last
>   build_void_list_node call.
>   (build_void_list_node): Remove.
>
> gcc/d/
>   * d-builtins.cc (d_build_c_type_nodes): Do not initialize
>   void_list_node.
>
> gcc/fortran/
>   * f95-lang.c (gfc_init_decl_processing): Do not initialize
>   void_list_node.
>
> gcc/go/
>   * go-lang.cc (go_langhook_init): Do not initialize
>   void_list_node.
>
> gcc/jit/
>   * dummy-frontend.cc (jit_langhook_init): Do not initialize
>   void_list_node.
>
> gcc/lto/
>   * lto-lang.cc (lto_build_c_type_nodes): Do not initialize
>   void_list_node.
> ---
>  gcc/ada/gcc-interface/trans.cc |  1 -
>  gcc/c-family/c-common.cc   |  2 --
>  gcc/c-family/c-common.h|  1 -
>  gcc/c/c-decl.cc|  8 
>  gcc/cp/decl.cc | 10 +-
>  gcc/d/d-builtins.cc|  1 -
>  gcc/fortran/f95-lang.cc|  2 --
>  gcc/go/go-lang.cc  |  3 ---
>  gcc/jit/dummy-frontend.cc  |  3 ---
>  gcc/lto/lto-lang.cc|  1 -
>  gcc/tree.cc|  2 ++
>  11 files changed, 3 insertions(+), 31 deletions(-)
>
> diff --git a/gcc/ada/gcc-interface/trans.cc b/gcc/ada/gcc-interface/trans.cc
> index f2e0cb2299b..2d93947cb26 100644
> --- a/gcc/ada/gcc-interface/trans.cc
> +++ b/gcc/ada/gcc-interface/trans.cc
> @@ -413,7 +413,6 @@ gigi (Node_Id gnat_root,
>save_gnu_tree (gnat_literal, t, false);
>
>/* Declare the building blocks of function nodes.  */
> -  void_list_node = build_tree_list (NULL_TREE, void_type_node);
>void_ftype = build_function_type_list (void_type_node, NULL_TREE);
>ptr_void_ftype = build_pointer_type (void_ftype);
>
> diff --git a/gcc/c-family/c-common.cc b/gcc/c-family/c-common.cc
> index 0a5b7e120c9..c0f15f4cab1 100644
> --- a/gcc/c-family/c-common.cc
> +++ b/gcc/c-family/c-common.cc
> @@ -4505,8 +4505,6 @@ c_common_nodes_and_builtins (void)
>  TYPE_NAME (void_type_node) = void_name;
>}
>
> -  void_list_node = build_void_list_node ();
> -
>/* Make a type to be the domain of a few array types
>   whose domains don't really matter.
>   200 is small enough that it always fits in size_t
> diff --git a/gcc/c-family/c-common.h b/gcc/c-family/c-common.h
> index ce971a29b5d..2f592f5cd58 100644
> --- a/gcc/c-family/c-common.h
> +++ b/gcc/c-family/c-common.h
> @@ -853,7 +853,6 @@ extern tree identifier_global_tag (tree);
>  extern bool names_builtin_p (const char *);
>  extern tree c_linkage_bindings (tree);
>  extern void record_builtin_type (enum rid, const char *, tree);
> -extern tree build_void_list_node (void);
>  extern void start_fname_decls (void);
>  extern void finish_fname_decls (void);
>  extern const char *fname_as_string (int);
> diff --git a/gcc/c/c-decl.cc b/gcc/c/c-decl.cc
> index 34f8feda897..b09c6393b91 100644
> --- a/gcc/c/c-decl.cc
> +++ b/gcc/c/c-decl.cc
> @@ -10676,14 +10676,6 @@ record_builtin_type (enum rid rid_index, const char 
> *name, tree type)
>  debug_hooks->type_decl (decl, false);
>  }
>
> -/* Build the void_list_node (void_type_node having been created).  */
> -tree
> -build_void_list_node (void)
> -{
> -  tree t = build_tree_list (NULL_TREE, void_type_node);
> -  return t;
> -}
> -
>  /* Return a c_parm structure with the given SPECS, ATTRS and DECLARATOR.  */
>
>  struct c_parm *
> diff --git a/gcc/cp/decl.cc b/gcc/cp/decl.cc
> index 006e9affcba..070f673c3a2 100644
> --- a/gcc/cp/decl.cc
> +++ b/gcc/cp/decl.cc
> @@ -4623,7 +4623,7 @@ cxx_init_decl_processing (void)
>record_unknown_type (init_list_type_node, "init list");
>
>/* Used when parsing to distinguish parameter-lists () and (void).  */
> -  explicit_void_list_node = build_void_list_node ();
> +  explicit_void_list_node = build_tree_list (NULL_TREE, void_type_node);
>
>{
>  /* Make sure we get a unique function type, so we can give
> @@ -18450,14 +18450,6 @@ cp_tree_node_structure (union lang_tree_node * t)
>  }
>  }
>
> -/* Build the void_list_node (void_type_node having been created).  */
> -tree
> 

GCC 13.0.1 Status Report (2023-02-22)

[Richard Biener via Gcc-patches]

Status
==

The GCC development branch which will become GCC 13 is in
regression and documentation fixing mode (Stage 4) until we
reach zero P1 regressions and branch for the release.

We are making slow progress towards this goal, new bugs are
coming in at a high pace.

Please help triaging UNCONFIRMED reported regressions and
at least provide some analysis for bugs attributed to you
or in the area of your expertise when they are classified
as target bugs.


Quality Data


Priority  #   Change from last report
---   ---
P1   32   -   5
P2  492   -   5
P3   77   -  11
P4  255   -   1
P5   24 
---   ---
Total P1-P3 601   -  21 
Total   880   -  22


Previous Report
===

https://gcc.gnu.org/pipermail/gcc/2023-January/240523.html

Re: [PATCH 2/2] Rework 128-bit complex multiply and divide.

[Kewen.Lin via Gcc-patches]

Hi Mike,

on 2023/2/3 13:53, Michael Meissner wrote:
> This patch reworks how the complex multiply and divide built-in functions are
> done.  Previously we created built-in declarations for doing long double 
> complex
> multiply and divide when long double is IEEE 128-bit.  The old code also did 
> not
> support __ibm128 complex multiply and divide if long double is IEEE 128-bit.
> 
> This patch was originally posted on December 13th, 2022:
> 
> | Date: Tue, 13 Dec 2022 01:21:06 -0500
> | Subject: [PATCH V2] Rework 128-bit complex multiply and divide, PR 
> target/107299
> | Message-ID: 
> 
> In terms of history, I wrote the original code just as I was starting to test
> GCC on systems where IEEE 128-bit long double was the default.  At the time, 
> we
> had not yet started mangling the built-in function names as a way to bridge
> going from a system with 128-bit IBM long double to 128-bin IEEE long double.
> 
> The original code depends on there only being two 128-bit types invovled.  
> With
> the next patch in this series, this assumption will no longer be true.  When
> long double is IEEE 128-bit, there will be 2 IEEE 128-bit types (one for the
> explicit __float128/_Float128 type and one for long double).
> 
> The problem is we cannot create two separate built-in functions that resolve 
> to
> the same name.  This is a requirement of add_builtin_function and the C front
> end.  That means for the 3 possible modes (IFmode, KFmode, and TFmode), you 
> can
> only use 2 of them.
> 
> This code does not create the built-in declaration with the changed name.
> Instead, it uses the TARGET_MANGLE_DECL_ASSEMBLER_NAME hook to change the name
> before it is written out to the assembler file like it now does for all of the
> other long double built-in functions.
> 
> When I wrote these patches, I discovered that __ibm128 complex multiply and
> divide had originally not been supported if long double is IEEE 128-bit as it
> would generate calls to __mulic3 and __divic3.  I added tests in the testsuite
> to verify that the correct name (i.e. __multc3 and __divtc3) is used in this
> case.
> 
> I had previously sent this patch out on November 1st.  Compared to that 
> version,
> this version no longer disables the special mapping when you are building
> libgcc, as it turns out we don't need it.
> 
> I tested all 3 patchs for PR target/107299 on:
> 
> 1)LE Power10 using --with-cpu=power10 
> --with-long-double-format=ieee
> 2)LE Power10 using --with-cpu=power10 
> --with-long-double-format=ibm
> 3)LE Power9  using --with-cpu=power9  
> --with-long-double-format=ibm
> 4)BE Power8  using --with-cpu=power8  
> --with-long-double-format=ibm
> 
> Once all 3 patches have been applied, we can once again build GCC when long
> double is IEEE 128-bit.  There were no other regressions with these patches.
> Can I check these patches into the trunk?

These two above paragraphs look a bit out of date (two patches now). :)

IIUC this patch actually fixes a latent issue, so it is independent of the one
fixing the bootstrapping issue, right?  This updated version of patch looks
good to me, but I'd leave the approval to Segher/David.  Thanks!

BR,
Kewen

New template for 'cpplib' made available

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.  (If you have
any questions, send them to .)

A new POT file for textual domain 'cpplib' has been made available
to the language teams for translation.  It is archived as:

https://translationproject.org/POT-files/cpplib-13.1-b20230212.pot

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

Below is the URL which has been provided to the translators of your
package.  Please inform the translation coordinator, at the address
at the bottom, if this information is not current:

https://gcc.gnu.org/pub/gcc/snapshots/13-20230212/gcc-13-20230212.tar.xz

Translated PO files will later be automatically e-mailed to you.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

Re: [PATCH] cgraph: Handle BUILT_IN_UNREACHABLE_TRAP like BUILT_IN_UNREACHABLE in more spots [PR106258]

[Richard Biener via Gcc-patches]

On Wed, 22 Feb 2023, Jakub Jelinek wrote:

> Hi!
> 
> The following testcase ICEs because we still have some spots that
> treat BUILT_IN_UNREACHABLE specially but not BUILT_IN_UNREACHABLE_TRAP
> the same.
> 
> The following patch fixes that, bootstrapped/regtested on x86_64-linux and
> i686-linux, ok for trunk?

OK.

> 2023-02-22  Jakub Jelinek  
> 
>   PR middle-end/106258
>   * cgraph.cc (cgraph_edge::redirect_call_stmt_to_callee,
>   cgraph_update_edges_for_call_stmt_node, cgraph_node::verify_node):
>   Handle BUILT_IN_UNREACHABLE_TRAP like BUILT_IN_UNREACHABLE.
>   * cgraphclones.cc (cgraph_node::create_clone): Likewise.
> 
>   * g++.dg/ipa/pr106258.C: New test.
> 
> --- gcc/cgraph.cc.jj  2023-02-07 10:33:46.027107080 +0100
> +++ gcc/cgraph.cc 2023-02-21 14:57:10.405454504 +0100
> @@ -1548,7 +1548,8 @@ cgraph_edge::redirect_call_stmt_to_calle
>else
>  {
>if (flag_checking
> -   && !fndecl_built_in_p (e->callee->decl, BUILT_IN_UNREACHABLE))
> +   && !fndecl_built_in_p (e->callee->decl, BUILT_IN_UNREACHABLE)
> +   && !fndecl_built_in_p (e->callee->decl, BUILT_IN_UNREACHABLE_TRAP))
>   ipa_verify_edge_has_no_modifications (e);
>new_stmt = e->call_stmt;
>gimple_call_set_fndecl (new_stmt, e->callee->decl);
> @@ -1634,7 +1635,9 @@ cgraph_update_edges_for_call_stmt_node (
>   {
> /* Keep calls marked as dead dead.  */
> if (new_stmt && is_gimple_call (new_stmt) && e->callee
> -   && fndecl_built_in_p (e->callee->decl, BUILT_IN_UNREACHABLE))
> +   && (fndecl_built_in_p (e->callee->decl, BUILT_IN_UNREACHABLE)
> +   || fndecl_built_in_p (e->callee->decl,
> + BUILT_IN_UNREACHABLE_TRAP)))
>   {
> cgraph_edge::set_call_stmt (node->get_edge (old_stmt),
> as_a  (new_stmt));
> @@ -3598,7 +3601,9 @@ cgraph_node::verify_node (void)
> /* Optimized out calls are redirected to __builtin_unreachable.  */
> && (e->count.nonzero_p ()
> || ! e->callee->decl
> -   || !fndecl_built_in_p (e->callee->decl, BUILT_IN_UNREACHABLE))
> +   || !(fndecl_built_in_p (e->callee->decl, BUILT_IN_UNREACHABLE)
> +|| fndecl_built_in_p (e->callee->decl,
> +  BUILT_IN_UNREACHABLE_TRAP)))
> && count
> == ENTRY_BLOCK_PTR_FOR_FN (DECL_STRUCT_FUNCTION (decl))->count
> && (!e->count.ipa_p ()
> --- gcc/cgraphclones.cc.jj2023-01-02 09:32:44.706962765 +0100
> +++ gcc/cgraphclones.cc   2023-02-21 14:58:11.619568895 +0100
> @@ -425,7 +425,9 @@ cgraph_node::create_clone (tree new_decl
>version.  The only exception is when the edge was proved to
>be unreachable during the cloning procedure.  */
>if (!e->callee
> -   || !fndecl_built_in_p (e->callee->decl, BUILT_IN_UNREACHABLE))
> +   || !(fndecl_built_in_p (e->callee->decl, BUILT_IN_UNREACHABLE)
> +|| fndecl_built_in_p (e->callee->decl,
> +  BUILT_IN_UNREACHABLE_TRAP)))
>  e->redirect_callee_duplicating_thunks (new_node);
>  }
>new_node->expand_all_artificial_thunks ();
> --- gcc/testsuite/g++.dg/ipa/pr106258.C.jj2023-02-21 15:02:17.251015237 
> +0100
> +++ gcc/testsuite/g++.dg/ipa/pr106258.C   2023-02-21 15:02:12.255087511 
> +0100
> @@ -0,0 +1,5 @@
> +// PR middle-end/106258
> +// { dg-do compile { target c++11 } }
> +// { dg-options "-O2 -funreachable-traps" }
> +
> +#include "ipa-sra-4.C"
> 
>   Jakub
> 
> 

-- 
Richard Biener 
SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg,
Germany; GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman;
HRB 36809 (AG Nuernberg)

Re: [PATCH] LoongArch: Change the value of macro TRY_EMPTY_VM_SPACE from 0x8000000000 to 0x1000000000.

[Lulu Cheng]

在 2023/2/22 下午5:35, WANG Xuerui 写道:

On 2023/2/22 17:30, Lulu Cheng wrote:


在 2023/2/21 下午9:56, WANG Xuerui 写道:

Hi,

On 2023/2/21 21:03, Lulu Cheng wrote:


在 2023/2/21 下午3:41, Xi Ruoyao 写道:

On Tue, 2023-02-21 at 15:20 +0800, Lulu Cheng wrote:

Like la264 only has 40 effective bits of virtual address space.
I'm OK with the change.  But the VA length is configurable 
building the

kernel.  Is there any specific reason LA264 has to use the 40-bit
configuration, or should we reword the commit message like "for
supporting the configuration with less page table level or smaller 
page

size"?


I consulted with my colleagues who are working on the kernel,

it looks like this:

The la264 chip desgn is physically 40-bit virtual address.

User mode and kernel mode each account for half:

User mode :    0x0-0x7f  

Kernel mode:  0x ff80   -0x   

The high bit is the sign extension of bit39.

Looking at the comments around the TRY_EMPTY_VM_SPACE definitions, 
they all indicate that the guessed range should be "likely free" -- 
that implies "usable". Given the common VM allocation behavior, we 
want TRY_EMPTY_VM_SPACE to point at a reasonably high place in the 
VA so it's "likely free".


So IMO the point is, will there be any LoongArch HW in the 
foreseeable future, with less than maybe 40 bits of VA? If the 
answer is "no" then a TRY_EMPTY_VM_SPACE near the 40-bit VA ceiling 
would be appropriate. Otherwise you may have to choose a value near 
or even below a 32-bit VA's upper limit: according to the ISA manual 
Volume 1, Section 2.1.5, "typical VALEN is in the range of [40, 
48]"; also see Section 5.2.3, RDVA can be as large as 8, so the 
actual VA space could theoretically be as narrow as 40-8=32 bits.



Yes, I agree with your point of view this is looking for a "likely 
free" virtual memory space.



But if I want to support chips with less than 40-bit virtual 
addresses, then the value of this macro needs to be set small.


I think setting this value small will increase the probability of 
virtual address mapping failure.


Not exactly; in case the TYPE_EMPTY_VM_SPACE address happen to be 
occupied, the mmap will still return something else that's nonzero 
(consult mmap's man page for details), and will not just blow the 
process up straight away.


But...



Chips with less than 40-bit virtual address space are small chips for 
embedded use.


The purpose of pch is to make compilation faster, but I think we 
rarely compile on embedded systems. So this situation may not be 
within our consideration.


Everything makes more sense with this context. Now put these 
justification into the commit message (after a little bit of rewording 
maybe) and I think we're good to go then ;-)

OK! Thanks!:-)

[PATCH] RISC-V: When the TARGET_COMPUTE_MULTILIB hook is implemented, check the version of each extension.

[Jin Ma via Gcc-patches]

When there is an extension with different versions, the result of the 
TARGET_COMPUTE_MULTILIB hook
is generally wrong, so the version needs to be considered.

gcc/ChangeLog:

* common/config/riscv/riscv-common.cc (riscv_subset_list::match_score): 
Match the version
of each extension.
---
 gcc/common/config/riscv/riscv-common.cc | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/gcc/common/config/riscv/riscv-common.cc 
b/gcc/common/config/riscv/riscv-common.cc
index ebc1ed7d7e4..0a15ff705d1 100644
--- a/gcc/common/config/riscv/riscv-common.cc
+++ b/gcc/common/config/riscv/riscv-common.cc
@@ -331,10 +331,9 @@ riscv_subset_list::match_score (riscv_subset_list *list) 
const
   /* list must be subset of current this list, otherwise it not safe to
  link.
  TODO: We might give different weight for each extension, but the rule 
could
-  be complicated.
- TODO: We might consider the version of each extension.  */
+  be complicated.  */
   for (s = list->m_head; s != NULL; s = s->next)
-if (this->lookup (s->name.c_str ()) != NULL)
+if (this->lookup (s->name.c_str (), s->major_version, s->minor_version) != 
NULL)
   score++;
 else
   return 0;
-- 
2.17.1

Re: [PATCH] LoongArch: Change the value of macro TRY_EMPTY_VM_SPACE from 0x8000000000 to 0x1000000000.

[WANG Xuerui]

On 2023/2/22 17:30, Lulu Cheng wrote:


在 2023/2/21 下午9:56, WANG Xuerui 写道:

Hi,

On 2023/2/21 21:03, Lulu Cheng wrote:


在 2023/2/21 下午3:41, Xi Ruoyao 写道:

On Tue, 2023-02-21 at 15:20 +0800, Lulu Cheng wrote:

Like la264 only has 40 effective bits of virtual address space.
I'm OK with the change.  But the VA length is configurable building 
the

kernel.  Is there any specific reason LA264 has to use the 40-bit
configuration, or should we reword the commit message like "for
supporting the configuration with less page table level or smaller 
page

size"?


I consulted with my colleagues who are working on the kernel,

it looks like this:

The la264 chip desgn is physically 40-bit virtual address.

User mode and kernel mode each account for half:

User mode :    0x0-0x7f  

Kernel mode:  0x ff80   -0x   

The high bit is the sign extension of bit39.

Looking at the comments around the TRY_EMPTY_VM_SPACE definitions, 
they all indicate that the guessed range should be "likely free" -- 
that implies "usable". Given the common VM allocation behavior, we 
want TRY_EMPTY_VM_SPACE to point at a reasonably high place in the VA 
so it's "likely free".


So IMO the point is, will there be any LoongArch HW in the 
foreseeable future, with less than maybe 40 bits of VA? If the answer 
is "no" then a TRY_EMPTY_VM_SPACE near the 40-bit VA ceiling would be 
appropriate. Otherwise you may have to choose a value near or even 
below a 32-bit VA's upper limit: according to the ISA manual Volume 
1, Section 2.1.5, "typical VALEN is in the range of [40, 48]"; also 
see Section 5.2.3, RDVA can be as large as 8, so the actual VA space 
could theoretically be as narrow as 40-8=32 bits.



Yes, I agree with your point of view this is looking for a "likely 
free" virtual memory space.



But if I want to support chips with less than 40-bit virtual 
addresses, then the value of this macro needs to be set small.


I think setting this value small will increase the probability of 
virtual address mapping failure.


Not exactly; in case the TYPE_EMPTY_VM_SPACE address happen to be 
occupied, the mmap will still return something else that's nonzero 
(consult mmap's man page for details), and will not just blow the 
process up straight away.


But...



Chips with less than 40-bit virtual address space are small chips for 
embedded use.


The purpose of pch is to make compilation faster, but I think we 
rarely compile on embedded systems. So this situation may not be 
within our consideration.


Everything makes more sense with this context. Now put these 
justification into the commit message (after a little bit of rewording 
maybe) and I think we're good to go then ;-)

Re: [PATCH] LoongArch: Change the value of macro TRY_EMPTY_VM_SPACE from 0x8000000000 to 0x1000000000.

[Lulu Cheng]

在 2023/2/21 下午9:56, WANG Xuerui 写道:

Hi,

On 2023/2/21 21:03, Lulu Cheng wrote:


在 2023/2/21 下午3:41, Xi Ruoyao 写道:

On Tue, 2023-02-21 at 15:20 +0800, Lulu Cheng wrote:

Like la264 only has 40 effective bits of virtual address space.

I'm OK with the change.  But the VA length is configurable building the
kernel.  Is there any specific reason LA264 has to use the 40-bit
configuration, or should we reword the commit message like "for
supporting the configuration with less page table level or smaller page
size"?


I consulted with my colleagues who are working on the kernel,

it looks like this:

The la264 chip desgn is physically 40-bit virtual address.

User mode and kernel mode each account for half:

User mode :    0x0-0x7f  

Kernel mode:  0x ff80   -0x   

The high bit is the sign extension of bit39.

Looking at the comments around the TRY_EMPTY_VM_SPACE definitions, 
they all indicate that the guessed range should be "likely free" -- 
that implies "usable". Given the common VM allocation behavior, we 
want TRY_EMPTY_VM_SPACE to point at a reasonably high place in the VA 
so it's "likely free".


So IMO the point is, will there be any LoongArch HW in the foreseeable 
future, with less than maybe 40 bits of VA? If the answer is "no" then 
a TRY_EMPTY_VM_SPACE near the 40-bit VA ceiling would be appropriate. 
Otherwise you may have to choose a value near or even below a 32-bit 
VA's upper limit: according to the ISA manual Volume 1, Section 2.1.5, 
"typical VALEN is in the range of [40, 48]"; also see Section 5.2.3, 
RDVA can be as large as 8, so the actual VA space could theoretically 
be as narrow as 40-8=32 bits.



Yes, I agree with your point of view this is looking for a "likely free" 
virtual memory space.



But if I want to support chips with less than 40-bit virtual addresses, 
then the value of this macro needs to be set small.


I think setting this value small will increase the probability of 
virtual address mapping failure.


Chips with less than 40-bit virtual address space are small chips for 
embedded use.


The purpose of pch is to make compilation faster, but I think we rarely 
compile on embedded systems. So this situation may not be within our 
consideration.

[PATCH] cygwin: Don't try to support multilibs [PR107998]

[Jakub Jelinek via Gcc-patches]

Hi!

As discussed in the PR, t-cygwin-w64 file has been introduced in 2013
and has one important problem, two different multilib options -m64 and -m32,
but MULTILIB_DIRNAMES with just one word in it.
Before the genmultilib sanity checking was added, my understanding is that
this essentially resulted in effective --disable-multilib,
$ gcc -print-multi-lib
.;
;@m32
$ gcc -print-multi-directory
.
$ gcc -print-multi-directory -m64
.
$ gcc -print-multi-directory -m32

$ gcc -print-multi-os-directory
../lib
$ gcc -print-multi-os-directory -m64
../lib
$ gcc -print-multi-os-directory -m32
../lib32
and because of the way e.g. config-ml.in operates
multidirs=
for i in `${CC-gcc} --print-multi-lib 2>/dev/null`; do
  dir=`echo $i | sed -e 's/;.*$//'`
  if [ "${dir}" = "." ]; then
true
  else
if [ -z "${multidirs}" ]; then
  multidirs="${dir}"
else
  multidirs="${multidirs} ${dir}"
fi
  fi
done
dir was . first time (and so nothing was done) and empty
second time, multidirs empty too, so multidirs was set to empty
like it would be with --disable-multilib.

With the added sanity checking the build fails unless --disable-multilib
is used in configure (dunno whether people usually configure that way
on cygwin).

>From what has been said in the PR, multilibs were not meant to be supported
and e.g. cygwin headers probably aren't ready for it.

So the following patch just removes the file with the (incorrect) multilib
stuff instead of fixing it (say by setting MULTILIB_DIRNAMES to 64 32).

I have no way to test this though, no Windows around, can anyone please
test this?  I just would like to get some progress on the P1s we have...

2023-02-22  Jakub Jelinek  

PR target/107998
* config.gcc (x86_64-*-cygwin*): Don't add i386/t-cygwin-w64 into
$tmake_file.
* config/i386/t-cygwin-w64: Remove.

--- gcc/config.gcc.jj   2023-02-18 12:38:30.803025062 +0100
+++ gcc/config.gcc  2023-02-21 17:07:12.143164563 +0100
@@ -2105,7 +2105,7 @@ x86_64-*-cygwin*)
need_64bit_isa=yes
tm_file="${tm_file} i386/unix.h i386/bsd.h i386/gas.h i386/cygming.h 
i386/cygwin.h i386/cygwin-w64.h i386/cygwin-stdint.h"
xm_file=i386/xm-cygwin.h
-   tmake_file="${tmake_file} i386/t-cygming t-slibgcc i386/t-cygwin-w64"
+   tmake_file="${tmake_file} i386/t-cygming t-slibgcc"
target_gtfiles="$target_gtfiles \$(srcdir)/config/i386/winnt.cc"
extra_options="${extra_options} i386/cygming.opt i386/cygwin.opt"
extra_objs="${extra_objs} winnt.o winnt-stubs.o"
--- gcc/config/i386/t-cygwin-w64.jj 2020-01-12 11:54:36.333414616 +0100
+++ gcc/config/i386/t-cygwin-w642023-02-21 17:06:44.121572616 +0100
@@ -1,3 +0,0 @@
-MULTILIB_OPTIONS = m64/m32
-MULTILIB_DIRNAMES = 64
-MULTILIB_OSDIRNAMES = ../lib ../lib32

Jakub

[PATCH] cgraph: Handle BUILT_IN_UNREACHABLE_TRAP like BUILT_IN_UNREACHABLE in more spots [PR106258]

[Jakub Jelinek via Gcc-patches]

Hi!

The following testcase ICEs because we still have some spots that
treat BUILT_IN_UNREACHABLE specially but not BUILT_IN_UNREACHABLE_TRAP
the same.

The following patch fixes that, bootstrapped/regtested on x86_64-linux and
i686-linux, ok for trunk?

2023-02-22  Jakub Jelinek  

PR middle-end/106258
* cgraph.cc (cgraph_edge::redirect_call_stmt_to_callee,
cgraph_update_edges_for_call_stmt_node, cgraph_node::verify_node):
Handle BUILT_IN_UNREACHABLE_TRAP like BUILT_IN_UNREACHABLE.
* cgraphclones.cc (cgraph_node::create_clone): Likewise.

* g++.dg/ipa/pr106258.C: New test.

--- gcc/cgraph.cc.jj2023-02-07 10:33:46.027107080 +0100
+++ gcc/cgraph.cc   2023-02-21 14:57:10.405454504 +0100
@@ -1548,7 +1548,8 @@ cgraph_edge::redirect_call_stmt_to_calle
   else
 {
   if (flag_checking
- && !fndecl_built_in_p (e->callee->decl, BUILT_IN_UNREACHABLE))
+ && !fndecl_built_in_p (e->callee->decl, BUILT_IN_UNREACHABLE)
+ && !fndecl_built_in_p (e->callee->decl, BUILT_IN_UNREACHABLE_TRAP))
ipa_verify_edge_has_no_modifications (e);
   new_stmt = e->call_stmt;
   gimple_call_set_fndecl (new_stmt, e->callee->decl);
@@ -1634,7 +1635,9 @@ cgraph_update_edges_for_call_stmt_node (
{
  /* Keep calls marked as dead dead.  */
  if (new_stmt && is_gimple_call (new_stmt) && e->callee
- && fndecl_built_in_p (e->callee->decl, BUILT_IN_UNREACHABLE))
+ && (fndecl_built_in_p (e->callee->decl, BUILT_IN_UNREACHABLE)
+ || fndecl_built_in_p (e->callee->decl,
+   BUILT_IN_UNREACHABLE_TRAP)))
{
  cgraph_edge::set_call_stmt (node->get_edge (old_stmt),
  as_a  (new_stmt));
@@ -3598,7 +3601,9 @@ cgraph_node::verify_node (void)
  /* Optimized out calls are redirected to __builtin_unreachable.  */
  && (e->count.nonzero_p ()
  || ! e->callee->decl
- || !fndecl_built_in_p (e->callee->decl, BUILT_IN_UNREACHABLE))
+ || !(fndecl_built_in_p (e->callee->decl, BUILT_IN_UNREACHABLE)
+  || fndecl_built_in_p (e->callee->decl,
+BUILT_IN_UNREACHABLE_TRAP)))
  && count
  == ENTRY_BLOCK_PTR_FOR_FN (DECL_STRUCT_FUNCTION (decl))->count
  && (!e->count.ipa_p ()
--- gcc/cgraphclones.cc.jj  2023-01-02 09:32:44.706962765 +0100
+++ gcc/cgraphclones.cc 2023-02-21 14:58:11.619568895 +0100
@@ -425,7 +425,9 @@ cgraph_node::create_clone (tree new_decl
 version.  The only exception is when the edge was proved to
 be unreachable during the cloning procedure.  */
   if (!e->callee
- || !fndecl_built_in_p (e->callee->decl, BUILT_IN_UNREACHABLE))
+ || !(fndecl_built_in_p (e->callee->decl, BUILT_IN_UNREACHABLE)
+  || fndecl_built_in_p (e->callee->decl,
+BUILT_IN_UNREACHABLE_TRAP)))
 e->redirect_callee_duplicating_thunks (new_node);
 }
   new_node->expand_all_artificial_thunks ();
--- gcc/testsuite/g++.dg/ipa/pr106258.C.jj  2023-02-21 15:02:17.251015237 
+0100
+++ gcc/testsuite/g++.dg/ipa/pr106258.C 2023-02-21 15:02:12.255087511 +0100
@@ -0,0 +1,5 @@
+// PR middle-end/106258
+// { dg-do compile { target c++11 } }
+// { dg-options "-O2 -funreachable-traps" }
+
+#include "ipa-sra-4.C"

Jakub

[PATCH] c++: Don't recurse on DECL_INITIAL for DECL_EXPR on non-VAR_DECLs [PR108606]

[Jakub Jelinek via Gcc-patches]

Hi!

The r13-2965-g73d9b0e5947e16 change changed the line touched in this patch
from
  return RECUR (tmp, want_rval);
to
  return RECUR (DECL_INITIAL (tmp), want_rval);
This is on DECL_EXPR handling code, where tmp can be lots of different
trees and DECL_INITIAL unfortunately also means different things on
different trees.
It is the initializer on VAR_DECL, DECL_ARG_TYPE on PARM_DECLs (though
those are unlikely to have DECL_EXPRs), for FUNCTION_DECLs the body,
..., USING_DECL_DECLS on USING_DECLs and DECL_FRIENDLIST on TYPE_DECLs.

The testcase below ICEs because we have a DECL_EXPR for TYPE_DECL
which has non-NULL DECL_FRIENDLIST and we certainly can't recurse on
the friend list.

The following patch is a conditional partial reversion of r13-2965,
it will recurse on DECL_INITIAL only for VAR_DECLs and for anything
else keep previous behavior.

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

2023-02-22  Jakub Jelinek  

PR c++/108606
* constexpr.cc (potential_constant_expression_1) :
Only recurse on DECL_INITIAL (tmp) if tmp is a VAR_DECL, otherwise
recurse on tmp.

* g++.dg/cpp1y/pr108606.C: New test.

--- gcc/cp/constexpr.cc.jj  2023-02-20 22:06:36.0 +0100
+++ gcc/cp/constexpr.cc 2023-02-21 14:40:39.366910531 +0100
@@ -9699,7 +9699,9 @@ potential_constant_expression_1 (tree t,
   (tmp, /*constexpr_context_p=*/true, flags))
return false;
}
-  return RECUR (DECL_INITIAL (tmp), want_rval);
+  if (VAR_P (tmp))
+   return RECUR (DECL_INITIAL (tmp), want_rval);
+  return RECUR (tmp, want_rval);
 
 case TRY_FINALLY_EXPR:
   return (RECUR (TREE_OPERAND (t, 0), want_rval)
--- gcc/testsuite/g++.dg/cpp1y/pr108606.C.jj2023-02-21 14:44:41.292380973 
+0100
+++ gcc/testsuite/g++.dg/cpp1y/pr108606.C   2023-02-21 14:44:15.622755459 
+0100
@@ -0,0 +1,11 @@
+// PR c++/108606
+// { dg-do compile { target c++14 } }
+
+template 
+void bar (T) {}
+
+void
+foo ()
+{
+  bar ([&] (auto x) { class C { friend void baz (); }; });
+}

Jakub

Re: [PATCH] vect: Check that vector factor is a compile-time constant

[Richard Biener via Gcc-patches]

On Wed, Feb 22, 2023 at 12:03 AM Michael Collison  wrote:
>
> While working on autovectorizing for the RISCV port I encountered an
> issue where vect_do_peeling assumes that the vectorization factor is a
> compile-time constant. The vectorization is not a compile-time constant
> on RISCV.
>
> Tested on RISCV and x86_64-linux-gnu. Okay?

I wonder how you arrive at prologue peeling with a non-constant VF?
In any case it would probably be better to use constant_lower_bound (vf)
here?  Also it looks wrong to apply this limit in case we are using
a fully masked main vector loop.  But as said, the specific case of
non-constant VF and prologue peeling probably wasn't supposed to happen,
instead the prologue usually is applied via an offset to a fully masked loop?

Richard?

Thanks,
Richard.

> Michael
>
> gcc/
>
>  * tree-vect-loop-manip.cc (vect_do_peeling): Verify
>  that vectorization factor is a compile-time constant.
>
> ---
>   gcc/tree-vect-loop-manip.cc | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/gcc/tree-vect-loop-manip.cc b/gcc/tree-vect-loop-manip.cc
> index 6aa3d2ed0bf..1ad1961c788 100644
> --- a/gcc/tree-vect-loop-manip.cc
> +++ b/gcc/tree-vect-loop-manip.cc
> @@ -2930,7 +2930,7 @@ vect_do_peeling (loop_vec_info loop_vinfo, tree
> niters, tree nitersm1,
> niters = vect_build_loop_niters (loop_vinfo, _var_p);
> /* It's guaranteed that vector loop bound before vectorization is at
>least VF, so set range information for newly generated var. */
> -  if (new_var_p)
> +  if (new_var_p && vf.is_constant ())
>   {
> value_range vr (type,
> wi::to_wide (build_int_cst (type, vf)),
> --
> 2.34.1
>