[PATCH 2/2] c++: maybe_dependent_member_ref and typenames [PR118626]

[Patrick Palka]

Here during maybe_dependent_member_ref for accepted_type<_Up>, we
correctly don't strip the typedef because it's a complex one (its
defaulted template parameter isn't used in its definition) and so
we recurse to consider its corresponding TYPE_DECL.

We then incorrectly decide to not rewrite this use because of the
TYPENAME_TYPE shortcut.  But I don't think this shortcut should apply to
a typedef TYPE_DECL.

PR c++/118626

gcc/cp/ChangeLog:

* pt.cc (maybe_dependent_member_ref): Restrict TYPENAME_TYPE
shortcut to non-typedef TYPE_DECL.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/class-deduction-alias25a.C: New test.
---
 gcc/cp/pt.cc  |  3 ++-
 .../g++.dg/cpp2a/class-deduction-alias25a.C   | 19 +++
 2 files changed, 21 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/class-deduction-alias25a.C

diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
index 6509089efdc..a1b0df428dc 100644
--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -17786,7 +17786,8 @@ maybe_dependent_member_ref (tree t, tree args, 
tsubst_flags_t complain,
 
   if (TREE_CODE (t) == TYPE_DECL)
 {
-  if (TREE_CODE (TREE_TYPE (t)) == TYPENAME_TYPE
+  if (!DECL_ORIGINAL_TYPE (t)
+ && TREE_CODE (TREE_TYPE (t)) == TYPENAME_TYPE
  && TYPE_NAME (TREE_TYPE (t)) == t)
/* The TYPE_DECL for a typename has DECL_CONTEXT of the typename
   scope, but it doesn't need to be rewritten again.  */
diff --git a/gcc/testsuite/g++.dg/cpp2a/class-deduction-alias25a.C 
b/gcc/testsuite/g++.dg/cpp2a/class-deduction-alias25a.C
new file mode 100644
index 000..74ef1e4d890
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/class-deduction-alias25a.C
@@ -0,0 +1,19 @@
+// PR c++/118626
+// { dg-do compile { target c++20 } }
+
+template struct _Nth_type { using type = _Nth_type; };
+
+template
+struct variant {
+  template static constexpr long __accepted_index = 0;
+  template using __to_type = typename _Nth_type<_Np>::type;
+  template using __accepted_type = 
__to_type<__accepted_index<_Tp>>;
+  template> variant(_Up);
+};
+
+template
+struct Node { Node(_Tp); };
+
+template using Tree = variant>;
+using type = decltype(Tree{Node{42}});
+using type = Tree;
-- 
2.49.0.111.g5b97a56fa0

Re: [PATCH] [testsuite] [riscv] xfail update-threading on riscv [PR110628]

[Alexandre Oliva]

On Mar 31, 2025, Jeff Law  wrote:

>> PR tree-optimization/110628
>> * gcc.dg/tree-ssa/update-threading.c: XFAIL on riscv.
> ?!? This is passing on my tester:

Indeed, despite the lack of any activity in the PR that could suggest
it's fixed in the trunk, it no longer fails in the trunk, only gcc-14.

Patch withdrawn.

H-P, perhaps it's time to drop the XFAIL on cris in the trunk?

-- 
Alexandre Oliva, happy hackerhttps://blog.lx.oliva.nom.br/
Free Software Activist FSFLA co-founder GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity.
Excluding neuro-others for not behaving ""normal"" is *not* inclusive!

RE: [PATCH v3] RISC-V: Fix wrong LMUL when only implict zve32f.

[Li, Pan2]

> Yeah...and I also don't like the magic "ceil(AVL / 2) ≤ vl ≤ VLMAX if
> AVL < (2 * VLMAX)" rule...

+1, spec has some description about this but I am not sure if I really get the 
point.

From Spec:

"For  example,  this  permits  an  implementation  to  set  vl  =  ceil(AVL  /  
2)  for  VLMAX  <  AVL  <  2*VLMAX  in  order  to  evenly
distribute work over the last two iterations of a stripmine loop. Requirement 2 
ensures that the  rst stripmine iteration of reduction
loops uses the largest vector length of all iterations, even in the case of AVL 
< 2*VLMAX. This allows software to avoid needing to
explicitly  calculate  a  running  maximum  of  vector  lengths  observed  
during  a  stripmined  loop.  Requirement  2  also  allows  an
implementation to set vl to VLMAX for VLMAX < AVL < 2*VLMAX"

Pan

-Original Message-
From: Kito Cheng  
Sent: Tuesday, April 1, 2025 9:53 AM
To: Robin Dapp 
Cc: Kito Cheng ; gcc-patches@gcc.gnu.org; 
pal...@dabbelt.com; jeffreya...@gmail.com; rd...@ventanamicro.com; 
juzhe.zh...@rivai.ai; Li, Pan2 ; vine...@rivosinc.com; 
patr...@rivosinc.com; monk.chi...@sifive.com
Subject: Re: [PATCH v3] RISC-V: Fix wrong LMUL when only implict zve32f.

Hi Robin:

Pushed to trunk, thanks,

On Mon, Mar 31, 2025 at 11:23 PM Robin Dapp  wrote:
>
> LGTM (even though I still don't like the spec :D).

Yeah...and I also don't like the magic "ceil(AVL / 2) ≤ vl ≤ VLMAX if
AVL < (2 * VLMAX)" rule...


> We still have an implicit assumption in riscv-vsetvl.cc that might modify 
> LMUL:

Thanks for reminding me, will take a look to see if that will cause problems :)

>
> In prev_ratio_valid_for_next_sew_p and next_ratio_valid_for_prev_sew_p we 
> check
> whether the ratio of two LMULs is <= 8.  ISTR that with recent changes we only
> re-use an existing ratio and don't compute a new one but it might be worth a
> second look.  A while ago we certainly did change LMUL even to values that
> weren't initially enabled.
>
> --
> Regards
>  Robin
>

Re: [PATCH] [testsuite] [riscv] xfail some [PR113281] tests

[Robin Dapp]

Some of the tests regressed with a fix for the vectorization of
shifts.  The riscv cost models need to be adjusted to avoid the
unprofitable optimization.  The failure of these tests has been known
since 2024-03-13, without a forthcoming fix, so I suggest we consider
it expected by now.  Adjust the tests to reflect that expectation.



So in the beginning those were added when we could avoid vectorization by 
higher register move costs but that's not true any more and hasn't been in a 
while.  We still shouldn't vectorize those and, IIRC, the "burden of
proof" lies more in the middle end than in the back end (because we don't 
vectorize with a fixed vector length).  Even back when the tests started 
regressing we could _somehow_ prevent vectorization by adjusting costs but it 
never seemed right.


But can't we just keep them FAILing for now?  Just because time has passed our 
expectation hasn't changed.  To me that's more obvious than xfail.


--
Regards
Robin

Re: [PATCH 1/8] aarch64: Use PAUTH instead of V8_3A in some places

[Alfie Richards]

Hi Richard,

Is this backport okay for GCC 14 as well?
(It applies cleanly for 14 but patch for 12 and 13 required a minor edit)

Alfie

On 20/03/2025 14:05, Alfie Richards wrote:

Hi all,

This commit applies cleanly to GCC 14 and fixes PR119372.

Bootstrapped and regtested on aarch64-linux-gnu.

Okay for gcc 14 backport?

Alfie Richards

On 08/10/2024 16:46, Richard Sandiford wrote:

Andrew Carlotti  writes:

gcc/ChangeLog:

* config/aarch64/aarch64.cc
(aarch64_expand_epilogue): Use TARGET_PAUTH.
* config/aarch64/aarch64.md: Update comment.


diff --git a/gcc/config/aarch64/aarch64.cc b/gcc/config/aarch64/ 
aarch64.cc
index 
e7bb3278a27eca44c46afd26069d608218198a54..cf1107127fd5d9e12ad42441528666bf6b733f73 100644

--- a/gcc/config/aarch64/aarch64.cc
+++ b/gcc/config/aarch64/aarch64.cc
@@ -10042,12 +10042,12 @@ aarch64_expand_epilogue (rtx_call_insn 
*sibcall)
  1) Sibcalls don't return in a normal way, so if we're about to 
call one

 we must authenticate.
-    2) The RETAA instruction is not available before ARMv8.3-A, so 
if we are

-   generating code for !TARGET_ARMV8_3 we can't use it and must
+    2) The RETAA instruction is not available without FEAT_PAuth, so 
if we

+   are generating code for !TARGET_PAUTH we can't use it and must
 explicitly authenticate.
  */
    if (aarch64_return_address_signing_enabled ()
-  && (sibcall || !TARGET_ARMV8_3))
+  && (sibcall || !TARGET_PAUTH))
  {
    switch (aarch64_ra_sign_key)
  {
diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/ 
aarch64.md
index 
c54b29cd64b9e0dc6c6d12735049386ccedc5408..0940a84f9295ee2bc07282b150095fdb5af11a4d 100644

--- a/gcc/config/aarch64/aarch64.md
+++ b/gcc/config/aarch64/aarch64.md
@@ -7672,10 +7672,10 @@
  )
  ;; Pointer authentication patterns are always provided.  In 
architecture
-;; revisions prior to ARMv8.3-A these HINT instructions operate as 
NOPs.
+;; revisions prior to FEAT_PAuth these HINT instructions operate as 
NOPs.


I suppose this should be something like "On targets that don't implement
FEAT_PAuth".  OK with that change, thanks.

Richard

  ;; This lets the user write portable software which authenticates 
pointers

-;; when run on something which implements ARMv8.3-A, and which runs
-;; correctly, but does not authenticate pointers, where ARMv8.3-A is 
not

+;; when run on something which implements FEAT_PAuth, and which runs
+;; correctly, but does not authenticate pointers, where FEAT_PAuth 
is not

  ;; implemented.
  ;; Signing/Authenticating R30 using SP as the salt.

[COMMITTED 03/35] gccrs: Remove now passing test from exclusion list

[arthur . cohen]

From: Pierre-Emmanuel Patry 

Those tests were malformed and failed with the new name resolution
because of it.

gcc/testsuite/ChangeLog:

* rust/compile/nr2/exclude: Remove test from exclusion list.

Signed-off-by: Pierre-Emmanuel Patry 
---
 gcc/testsuite/rust/compile/nr2/exclude | 5 -
 1 file changed, 5 deletions(-)

diff --git a/gcc/testsuite/rust/compile/nr2/exclude 
b/gcc/testsuite/rust/compile/nr2/exclude
index 1582d5a2d96..45e90a4df93 100644
--- a/gcc/testsuite/rust/compile/nr2/exclude
+++ b/gcc/testsuite/rust/compile/nr2/exclude
@@ -2,8 +2,6 @@ canonical_paths1.rs
 cfg1.rs
 const_generics_3.rs
 generics9.rs
-issue-1901.rs
-issue-1981.rs
 issue-2043.rs
 issue-2330.rs
 issue-2812.rs
@@ -21,7 +19,6 @@ privacy8.rs
 pub_restricted_1.rs
 pub_restricted_2.rs
 pub_restricted_3.rs
-sizeof-stray-infer-var-bug.rs
 undeclared_label.rs
 use_1.rs
 while_break_expr.rs
@@ -37,9 +34,7 @@ issue-3403.rs
 derive-eq-invalid.rs
 derive-hash1.rs
 torture/alt_patterns1.rs
-torture/builtin_abort.rs
 torture/loop4.rs
 torture/loop8.rs
 torture/name_resolve1.rs
-torture/uninit-intrinsic-1.rs
 # please don't delete the trailing newline
-- 
2.49.0

[COMMITTED 12/35] gccrs: testsuite: Add more testcases for cfg() in core

[arthur . cohen]

From: Arthur Cohen 

gcc/testsuite/ChangeLog:

* rust/compile/cfg-core1.rs: New test.
* rust/compile/cfg-core2.rs: New test.
---
 gcc/testsuite/rust/compile/cfg-core1.rs | 12 
 gcc/testsuite/rust/compile/cfg-core2.rs | 12 
 2 files changed, 24 insertions(+)
 create mode 100644 gcc/testsuite/rust/compile/cfg-core1.rs
 create mode 100644 gcc/testsuite/rust/compile/cfg-core2.rs

diff --git a/gcc/testsuite/rust/compile/cfg-core1.rs 
b/gcc/testsuite/rust/compile/cfg-core1.rs
new file mode 100644
index 000..7780cc9587a
--- /dev/null
+++ b/gcc/testsuite/rust/compile/cfg-core1.rs
@@ -0,0 +1,12 @@
+// { dg-additional-options "-frust-cfg=A -frust-cfg=B" }
+
+#[cfg_attr(A, cfg(B))]
+struct Foo0;
+
+#[cfg_attr(A, cfg(C))]
+struct Bar0;
+
+fn main() {
+let a = Foo0;
+let a = Bar0; // { dg-error "cannot find value" }
+}
diff --git a/gcc/testsuite/rust/compile/cfg-core2.rs 
b/gcc/testsuite/rust/compile/cfg-core2.rs
new file mode 100644
index 000..e346eddd1a6
--- /dev/null
+++ b/gcc/testsuite/rust/compile/cfg-core2.rs
@@ -0,0 +1,12 @@
+// { dg-additional-options "-frust-cfg=B" }
+
+#[cfg(not(any(A, B)))]
+struct Foo0;
+
+#[cfg(not(any(A, C)))]
+struct Bar0;
+
+fn main() {
+let a = Foo0; // { dg-error "cannot find value" }
+let a = Bar0;
+}
-- 
2.49.0

Re: [PATCH v3] RISC-V: Fix wrong LMUL when only implict zve32f.

[Kito Cheng]

Hi Robin:

Pushed to trunk, thanks,

On Mon, Mar 31, 2025 at 11:23 PM Robin Dapp  wrote:
>
> LGTM (even though I still don't like the spec :D).

Yeah...and I also don't like the magic "ceil(AVL / 2) ≤ vl ≤ VLMAX if
AVL < (2 * VLMAX)" rule...


> We still have an implicit assumption in riscv-vsetvl.cc that might modify 
> LMUL:

Thanks for reminding me, will take a look to see if that will cause problems :)

>
> In prev_ratio_valid_for_next_sew_p and next_ratio_valid_for_prev_sew_p we 
> check
> whether the ratio of two LMULs is <= 8.  ISTR that with recent changes we only
> re-use an existing ratio and don't compute a new one but it might be worth a
> second look.  A while ago we certainly did change LMUL even to values that
> weren't initially enabled.
>
> --
> Regards
>  Robin
>

[PATCH] RISC-V: Fixbug for slli + addw + zext.w into sh[123]add + zext.w

[Jin Ma]

Assuming we have the following variables:

unsigned long long a0, a1;
unsigned int a2;

For the expression:

a0 = (a0 << 50) >> 49;  // slli a0, a0, 50 + srli a0, a0, 49
a2 = a1 + a0;   // addw a2, a1, a0 + slli a2, a2, 32 + srli a2, a2, 32

In the optimization process of ZBA (combine pass), it would be optimized to:

a2 = a0 << 1 + a1;  // sh1add a2, a0, a1 + zext.w a2, a2

This is clearly incorrect, as it overlooks the fact that a0=a0&0x7ffe, meaning
that the bits a0[32:14] are set to zero.

gcc/ChangeLog:

* config/riscv/bitmanip.md: The optimization can only be applied if
the high bit of operands[3] is set to 1.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/zba-shNadd-09.c: New test.
* gcc.target/riscv/zba-shNadd-10.c: New test.
---
 gcc/config/riscv/bitmanip.md  |  3 ++-
 .../gcc.target/riscv/zba-shNadd-09.c  | 12 +++
 .../gcc.target/riscv/zba-shNadd-10.c  | 20 +++
 3 files changed, 34 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.target/riscv/zba-shNadd-09.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/zba-shNadd-10.c

diff --git a/gcc/config/riscv/bitmanip.md b/gcc/config/riscv/bitmanip.md
index b29c127bcb8..9091c48b106 100644
--- a/gcc/config/riscv/bitmanip.md
+++ b/gcc/config/riscv/bitmanip.md
@@ -80,7 +80,8 @@ (define_split
(match_operand:DI 3 
"consecutive_bits_operand")) 0)
 (subreg:SI (match_operand:DI 4 
"register_operand") 0]
   "TARGET_64BIT && TARGET_ZBA
-   && riscv_shamt_matches_mask_p (INTVAL (operands[2]), INTVAL (operands[3]))"
+   && riscv_shamt_matches_mask_p (INTVAL (operands[2]), INTVAL (operands[3]))
+   && ((INTVAL (operands[3]) & (1 << 31)) != 0)"
   [(set (match_dup 0) (plus:DI (ashift:DI (match_dup 1) (match_dup 2)) 
(match_dup 4)))
(set (match_dup 0) (zero_extend:DI (subreg:SI (match_dup 0) 0)))])
 
diff --git a/gcc/testsuite/gcc.target/riscv/zba-shNadd-09.c 
b/gcc/testsuite/gcc.target/riscv/zba-shNadd-09.c
new file mode 100644
index 000..303f3cbb863
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/zba-shNadd-09.c
@@ -0,0 +1,12 @@
+/* { dg-do compile } */
+/* { dg-options "-march=rv64gc_zba -mabi=lp64" } */
+/* { dg-skip-if "" { *-*-* } { "-O0" "-Og" } } */
+
+long long sub (unsigned long long a, unsigned long long b)
+{
+  b = (b << 50) >> 49;
+  unsigned int x = a + b;
+  return x;
+}
+
+/* { dg-final { scan-assembler-not {\msh1add} } } */
diff --git a/gcc/testsuite/gcc.target/riscv/zba-shNadd-10.c 
b/gcc/testsuite/gcc.target/riscv/zba-shNadd-10.c
new file mode 100644
index 000..bec0260d625
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/zba-shNadd-10.c
@@ -0,0 +1,20 @@
+/* { dg-do run { target { rv64 } } } */
+/* { dg-options "-march=rv64gc_zba -mabi=lp64d -O2" } */
+
+#include 
+struct {
+  unsigned a : 14;
+  unsigned b : 3;
+} c;
+unsigned long long d;
+void e(unsigned long long *f, long p2) { *f = p2; }
+signed g;
+long i;
+int main() {
+  c.b = 4;
+  i = -(-c.a - (3023282U + c.a + g));
+  e(&d, i);
+  printf("%llu\n", d);
+}
+
+/* { dg-output "3023282\r\n" } */
-- 
2.25.1

Re: [PATCH v2] RISC-V: vsetvl: skip abnormal edge on vsetvl insertion [PR119533]

[Jeff Law]

On 3/31/25 1:33 PM, Vineet Gupta wrote:

On 3/29/25 17:58, Jeff Law wrote:

On 3/29/25 6:49 PM, Vineet Gupta wrote:

changes since v2
   - dump log sanfu

---
vsetvl phase4 uses LCM guided info to insert VSETVL insns.
It has an additional loop to insert missing vsetvls on certain edges.
Currently it asserts/aborts on encountering EDGE_ABNORMAL.
When enabling go frontend with V enabled, libgo build hits the assert.

It seems to be safe to just skip the abnormal edge.

Verified that a go toolchain build with the fix completes successfully
and runs the testsuite.
   
rv64imafdcv_zicbom_zicboz_zicntr_zicond_zicsr_zifencei_zihintntl_zihintpause_zihpm_zfa_zfhmin_zba_zbb_zbs_zkt_zvbb_zvkt/
  lp64d/ medlow |  738 /   146 |7 / 3 |   72 /12 |

Also to make sure nothing regressed on rvv and go side, did additional 2
sets of runs.

1. RVV build, go disabled, w/ and w/o fix
   rv64imafdcv_zvl256b_zba_zbb_zbs_zicond/  lp64d/ medlow |  244 /96 |7 
/ 3 |   67 /12 |
   rv64imafdcv_zvl256b_zba_zbb_zbs_zicond/  lp64d/ medlow |  244 /96 |7 
/ 3 |   67 /12 |

2. go enabled, RVV disabled, w/ and w/o fix
   rv64imafdc_zba_zbb_zbs_zicond_zfa/  lp64d/ medlow |  155 /47 |0 /
 0 |0 / 0 |
   rv64imafdc_zba_zbb_zbs_zicond_zfa/  lp64d/ medlow |  155 /47 |0 /
 0 |0 / 0 |

PR target/119533

gcc/ChangeLog:

* config/riscv/riscv-vsetvl.cc (pre_vsetvl::emit_vsetvl): skip
EDGE_ABNORMAL.

gcc/testsuite/ChangeLog:

* go.dg/pr119533-riscv.go: New test.

So presumably it wants to insert on the EH edge for a reason.  Just
skipping the edge is probably wrong.

The way these scenarios are handled in the more generic LCM passes is to
kill all values on the EH edge.  With all values killed on the EH edge,
no redundancy exists which should require insertion on the edge.


Lets do some dump diving - pun intended.

Failure happens at the following abnormal edge:

 Insert missed vsetvl info at edge(bb 42 -> bb 64):VALID (insn 663, bb 64)


Where bb 64 corresponds to unwinder call so clearly EH related.

 (code_label/s 474 591 476 64 37 (nil) [1 uses])
 (note 476 474 438 64 [bb 64] NOTE_INSN_BASIC_BLOCK)
 (call_insn 438 476 439 64 (parallel [
     (call (mem:SI (symbol_ref:DI ("_Unwind_Resume") [flags 0x41]
 ) [0
 __builtin_unwind_resume S4 A32])
     (const_int 0 [0]))
     (use (unspec:SI [
     (const_int 0 [0])
     ] UNSPEC_CALLEE_CC))
     (clobber (reg:SI 1 ra))
     ]) 456 {call_internal}
  (expr_list:REG_DEAD (reg:DI 10 a0)
     (expr_list:REG_CALL_DECL (symbol_ref:DI ("_Unwind_Resume") [flags
 0x41]  )
     (expr_list:REG_NORETURN (const_int 0 [0])
     (nil
     (expr_list:DI (use (reg:DI 10 a0))
     (nil)))
 (barrier 439 438 617)


The edge 42 -> 64 already exists at the entry of vsetvl, so its not something
that the vsetvl/LCM creates.

 Entering Lazy VSETVL PASS
 ...
 ...
 ;; 27 succs { 64 28 }
 ;; 28 succs { 64 29 } <---
 ;; 29 succs { 30 43 }
 ;; 30 succs { 64 31 }
 ;; 31 succs { 32 43 }
 ;; 32 succs { 64 33 }
 ;; 33 succs { 64 34 }
 ;; 34 succs { 64 35 }
 ;; 35 succs { 36 39 }
 ;; 36 succs { 64 37 }
 ;; 37 succs { 64 38 }
 ;; 38 succs { 39 }
 ;; 39 succs { 64 40 }
 ;; 40 succs { 64 41 }
 ;; 41 succs { 64 42 }
 ;; 42 succs { 64 43 }   <
 ...
 ...

In the working case, --param=vsetvl-strategy=simple, in cprop (just before
vsetvl), I don't see any jumps to the code label of bb 64 (with Unwinder call)
either.

I don't think vsetvl LCM is supposed to prune this edge out. In fact in the
routine to prepare LCM bitmaps I skip bb 42 (by checking for EDGE_CRITICAL in
invalid_opt_bb_p ()
The problem now happens in bb 28, which also happens to have edge to 64.

So it seems to me that it should be safe to just skip the abnormal edge.
But what state is in play that caused it to want to insert something? 
That's what needs to be understood here.  I don't see anything in bb64 
that requires vsetvl to be in any particular state.  So why did vsetvl 
insertion think that it needed to insert anything on the edge to bb64?


jeff

Re: [PATCH v3] RISC-V: Fix wrong LMUL when only implict zve32f.

[Robin Dapp]

Yeah...and I also don't like the magic "ceil(AVL / 2) ≤ vl ≤ VLMAX if
AVL < (2 * VLMAX)" rule...


+1, spec has some description about this but I am not sure if I really get the 
point.

From Spec:

"For  example,  this  permits  an  implementation  to  set  vl  =  ceil(AVL  
/  2)  for  VLMAX  <  AVL  <  2*VLMAX  in  order  to  evenly
distribute work over the last two iterations of a stripmine loop. Requirement 
2 ensures that the  rst stripmine iteration of reduction
loops uses the largest vector length of all iterations, even in the case of 
AVL < 2*VLMAX. This allows software to avoid needing to
explicitly  calculate  a  running  maximum  of  vector  lengths  observed  
during  a  stripmined  loop.  Requirement  2  also  allows  an

implementation to set vl to VLMAX for VLMAX < AVL < 2*VLMAX"


Yeah, that's very unfortunate.

The rule is something like
 
 if AVL >= 2 * VLMAX

   vl = vsetvl = min (AVL, VLMAX)

 if VLMAX > AVL < 2 * VLMAX
   vl = vsetvl = "whatever" ;)

 if AVL <= VLMAX
   vl = vsetvl = min (AVL, VLMAX)

The idea of load balancing is alright I guess but it really complicates matters 
in the compiler.


FWIW my plan for GCC 16 is to define a SELECT_VL_SANE (or any better name I can 
come up with) that doesn't have this behavior and always only performs a 
minimum instead.  This will allow us to perform scalar evolution on vsetvl 
rather than giving up as we do right now.  Microarchitectures where vsetvl 
always behaves like a minimum would then enable the corresponding expander/insn 
and others would fall back to the current behavior.


--
Regards
Robin

[PATCH]

[Alexandre Oliva]

[testsuite] [riscv] limit vwaddsub-1.c to rv64

The desired vw{add,sub}.wx instructions don't come up on rv32 for the
first two functions, we get v{add,sub}.vx instead.

I suppose this is an oversight, and something about the test is meant
for rv64 only, but the fact that the instruction is spelled out in the
intrinsic name and a different instruction is generated suggests
something may be wrong after all.


I could use a pointer to specs for these intrinsics and instructions to
tell for sure, but a closer look from someone more familiar with them
would definitely be welcome.

Tested on x86_64-linux-gnu native, and gcc-14 target riscv{64,32}-elf.
Ok to install?


for  gcc/testsuite/ChangeLog

* gcc.target/riscv/rvv/base/vwaddsub-1.c: Require rv64.
---
 .../gcc.target/riscv/rvv/base/vwaddsub-1.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.target/riscv/rvv/base/vwaddsub-1.c 
b/gcc/testsuite/gcc.target/riscv/rvv/base/vwaddsub-1.c
index 6e027a555f377..84d3c4cb4c717 100644
--- a/gcc/testsuite/gcc.target/riscv/rvv/base/vwaddsub-1.c
+++ b/gcc/testsuite/gcc.target/riscv/rvv/base/vwaddsub-1.c
@@ -1,4 +1,4 @@
-/* { dg-do compile { target { ! riscv_abi_e } } } */
+/* { dg-do compile { target { { ! riscv_abi_e } && rv64 } } } */
 /* { dg-add-options riscv_v } */
 /* { dg-additional-options "-std=gnu99 -O3 -fno-schedule-insns 
-fno-schedule-insns2" } */
 


-- 
Alexandre Oliva, happy hackerhttps://blog.lx.oliva.nom.br/
Free Software Activist FSFLA co-founder GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity.
Excluding neuro-others for not behaving ""normal"" is *not* inclusive!

[COMMITTED 05/35] gccrs: parser: Parse let-else statements

[arthur . cohen]

From: Arthur Cohen 

gcc/rust/ChangeLog:

* parse/rust-parse-impl.h (Parser::parse_let_stmt): Add new parsing in 
case of `else` token.
---
 gcc/rust/parse/rust-parse-impl.h | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/gcc/rust/parse/rust-parse-impl.h b/gcc/rust/parse/rust-parse-impl.h
index dd6086896f8..71d72504cfc 100644
--- a/gcc/rust/parse/rust-parse-impl.h
+++ b/gcc/rust/parse/rust-parse-impl.h
@@ -6163,6 +6163,10 @@ Parser::parse_let_stmt (AST::AttrVec 
outer_attrs,
}
 }
 
+  tl::optional> else_expr = tl::nullopt;
+  if (maybe_skip_token (ELSE))
+else_expr = parse_block_expr ();
+
   if (restrictions.consume_semi)
 {
   // `stmt` macro variables are parsed without a semicolon, but should be
@@ -6177,7 +6181,7 @@ Parser::parse_let_stmt (AST::AttrVec 
outer_attrs,
 
   return std::unique_ptr (
 new AST::LetStmt (std::move (pattern), std::move (expr), std::move (type),
- std::move (outer_attrs), locus));
+ std::move (else_expr), std::move (outer_attrs), locus));
 }
 
 // Parses a type path.
-- 
2.49.0

[COMMITTED 19/35] gccrs: Fix ICE when using super mid way though path

[arthur . cohen]

From: Philip Herron 

Fixes Rust-GCC#3568

gcc/rust/ChangeLog:

* resolve/rust-ast-resolve-path.cc (ResolvePath::resolve_path): check 
for super mid path

gcc/testsuite/ChangeLog:

* rust/compile/nr2/exclude: nr2 puts out a different error multiple 
times
* rust/compile/issue-3568.rs: New test.

Signed-off-by: Philip Herron 
---
 gcc/rust/resolve/rust-ast-resolve-path.cc | 6 ++
 gcc/testsuite/rust/compile/issue-3568.rs  | 7 +++
 gcc/testsuite/rust/compile/nr2/exclude| 1 +
 3 files changed, 14 insertions(+)
 create mode 100644 gcc/testsuite/rust/compile/issue-3568.rs

diff --git a/gcc/rust/resolve/rust-ast-resolve-path.cc 
b/gcc/rust/resolve/rust-ast-resolve-path.cc
index b2b10719e19..530926d5d97 100644
--- a/gcc/rust/resolve/rust-ast-resolve-path.cc
+++ b/gcc/rust/resolve/rust-ast-resolve-path.cc
@@ -370,6 +370,12 @@ ResolvePath::resolve_path (AST::SimplePath &expr)
}
   else if (segment.is_super_path_seg ())
{
+ if (!is_first_segment)
+   {
+ rust_error_at (segment.get_locus (),
+"% can only be used in start position");
+ return UNKNOWN_NODEID;
+   }
  if (module_scope_id == crate_scope_id)
{
  rust_error_at (segment.get_locus (),
diff --git a/gcc/testsuite/rust/compile/issue-3568.rs 
b/gcc/testsuite/rust/compile/issue-3568.rs
new file mode 100644
index 000..222a174ef38
--- /dev/null
+++ b/gcc/testsuite/rust/compile/issue-3568.rs
@@ -0,0 +1,7 @@
+pub type T = ();
+mod foo {
+pub use super::T;
+}
+
+pub use foo::super::foo::S as T;
+// { dg-error ".super. can only be used in start position" "" { target *-*-* } 
.-1 }
diff --git a/gcc/testsuite/rust/compile/nr2/exclude 
b/gcc/testsuite/rust/compile/nr2/exclude
index 71c2b682bf0..9273bd1489e 100644
--- a/gcc/testsuite/rust/compile/nr2/exclude
+++ b/gcc/testsuite/rust/compile/nr2/exclude
@@ -36,4 +36,5 @@ torture/alt_patterns1.rs
 torture/loop4.rs
 torture/loop8.rs
 torture/name_resolve1.rs
+issue-3568.rs
 # please don't delete the trailing newline
-- 
2.49.0

[COMMITTED 13/35] gccrs: Fix validation of constant items

[arthur . cohen]

From: Owen Avery 

gcc/rust/ChangeLog:

* checks/errors/rust-ast-validation.cc
(ASTValidation::visit): Allow constant items lacking expressions
if and only if they're associated with a trait definition, not a
trait implementation.

gcc/testsuite/ChangeLog:

* rust/compile/issue-3541-1.rs: New test.
* rust/compile/issue-3541-2.rs: Likewise.

Signed-off-by: Owen Avery 
---
 gcc/rust/checks/errors/rust-ast-validation.cc | 2 +-
 gcc/testsuite/rust/compile/issue-3541-1.rs| 5 +
 gcc/testsuite/rust/compile/issue-3541-2.rs| 3 +++
 3 files changed, 9 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/rust/compile/issue-3541-1.rs
 create mode 100644 gcc/testsuite/rust/compile/issue-3541-2.rs

diff --git a/gcc/rust/checks/errors/rust-ast-validation.cc 
b/gcc/rust/checks/errors/rust-ast-validation.cc
index 59b28057bab..0f4bdeb6935 100644
--- a/gcc/rust/checks/errors/rust-ast-validation.cc
+++ b/gcc/rust/checks/errors/rust-ast-validation.cc
@@ -56,7 +56,7 @@ ASTValidation::visit (AST::LoopLabel &label)
 void
 ASTValidation::visit (AST::ConstantItem &const_item)
 {
-  if (!const_item.has_expr () && ctx.peek () != Kind::TRAIT_IMPL)
+  if (!const_item.has_expr () && ctx.peek () != Kind::TRAIT)
 {
   rust_error_at (const_item.get_locus (),
 "associated constant in % without body");
diff --git a/gcc/testsuite/rust/compile/issue-3541-1.rs 
b/gcc/testsuite/rust/compile/issue-3541-1.rs
new file mode 100644
index 000..6b47b7e11a5
--- /dev/null
+++ b/gcc/testsuite/rust/compile/issue-3541-1.rs
@@ -0,0 +1,5 @@
+impl B for u32 {
+const BAR: i32; // { dg-error "associated constant in .impl." }
+}
+
+trait B {}
diff --git a/gcc/testsuite/rust/compile/issue-3541-2.rs 
b/gcc/testsuite/rust/compile/issue-3541-2.rs
new file mode 100644
index 000..9f17eedab54
--- /dev/null
+++ b/gcc/testsuite/rust/compile/issue-3541-2.rs
@@ -0,0 +1,3 @@
+trait B {
+const BAR: i32;
+}
-- 
2.49.0

[COMMITTED 07/35] gccrs: name-resolution: Handle let-else properly

[arthur . cohen]

From: Arthur Cohen 

gcc/rust/ChangeLog:

* resolve/rust-ast-resolve-stmt.h: Add handling for diverging else.
* resolve/rust-late-name-resolver-2.0.cc (Late::visit): Likewise.
---
 gcc/rust/resolve/rust-ast-resolve-stmt.h| 7 ---
 gcc/rust/resolve/rust-late-name-resolver-2.0.cc | 3 +++
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/gcc/rust/resolve/rust-ast-resolve-stmt.h 
b/gcc/rust/resolve/rust-ast-resolve-stmt.h
index d3ff14f755e..6c99d6a6f6c 100644
--- a/gcc/rust/resolve/rust-ast-resolve-stmt.h
+++ b/gcc/rust/resolve/rust-ast-resolve-stmt.h
@@ -73,9 +73,10 @@ public:
   void visit (AST::LetStmt &stmt) override
   {
 if (stmt.has_init_expr ())
-  {
-   ResolveExpr::go (stmt.get_init_expr (), prefix, canonical_prefix);
-  }
+  ResolveExpr::go (stmt.get_init_expr (), prefix, canonical_prefix);
+
+if (stmt.has_else_expr ())
+  ResolveExpr::go (stmt.get_else_expr (), prefix, canonical_prefix);
 
 PatternDeclaration::go (stmt.get_pattern (), Rib::ItemType::Var);
 if (stmt.has_type ())
diff --git a/gcc/rust/resolve/rust-late-name-resolver-2.0.cc 
b/gcc/rust/resolve/rust-late-name-resolver-2.0.cc
index cf7b7dcd03f..95df7272c75 100644
--- a/gcc/rust/resolve/rust-late-name-resolver-2.0.cc
+++ b/gcc/rust/resolve/rust-late-name-resolver-2.0.cc
@@ -140,6 +140,9 @@ Late::visit (AST::LetStmt &let)
 visit (let.get_init_expr ());
   visit (let.get_pattern ());
 
+  if (let.has_else_expr ())
+visit (let.get_init_expr ());
+
   // how do we deal with the fact that `let a = blipbloup` should look for a
   // label and cannot go through function ribs, but `let a = blipbloup()` can?
 
-- 
2.49.0

[COMMITTED 35/35] gccrs: Fix SEGV when type path resolver fails outright

[arthur . cohen]

From: Philip Herron 

When we resolve paths we resolve to Types first we walk each segment to
the last module which has no type but then in the event that the child
of a module is not found we have a null root_tyty which needs to be caught
and turned into an ErrorType node.

Fixes Rust-GCC#3613

gcc/rust/ChangeLog:

* typecheck/rust-hir-type-check-type.cc 
(TypeCheckType::resolve_root_path):
catch nullptr root_tyty

gcc/testsuite/ChangeLog:

* rust/compile/issue-3613.rs: New test.

Signed-off-by: Philip Herron 
---
 gcc/rust/typecheck/rust-hir-type-check-type.cc |  7 +++
 gcc/testsuite/rust/compile/issue-3613.rs   | 18 ++
 2 files changed, 25 insertions(+)
 create mode 100644 gcc/testsuite/rust/compile/issue-3613.rs

diff --git a/gcc/rust/typecheck/rust-hir-type-check-type.cc 
b/gcc/rust/typecheck/rust-hir-type-check-type.cc
index e56fa397e2a..54f50ec41f1 100644
--- a/gcc/rust/typecheck/rust-hir-type-check-type.cc
+++ b/gcc/rust/typecheck/rust-hir-type-check-type.cc
@@ -360,6 +360,13 @@ TypeCheckType::resolve_root_path (HIR::TypePath &path, 
size_t *offset,
 seg->as_string ().c_str ());
  return new TyTy::ErrorType (path.get_mappings ().get_hirid ());
}
+ else if (root_tyty == nullptr)
+   {
+ rust_error_at (seg->get_locus (),
+"unknown reference for resolved name: %qs",
+seg->as_string ().c_str ());
+ return new TyTy::ErrorType (path.get_mappings ().get_hirid ());
+   }
  return root_tyty;
}
 
diff --git a/gcc/testsuite/rust/compile/issue-3613.rs 
b/gcc/testsuite/rust/compile/issue-3613.rs
new file mode 100644
index 000..f2e10921f67
--- /dev/null
+++ b/gcc/testsuite/rust/compile/issue-3613.rs
@@ -0,0 +1,18 @@
+mod m1 {
+pub enum Baz4 {
+foo1,
+foo2,
+}
+}
+
+fn bar(x: m1::foo) {
+// { dg-error "unknown reference for resolved name: .foo." "" { target 
*-*-* } .-1 }
+match x {
+m1::foo::foo1 => {}
+// { dg-error "failed to type resolve root segment" "" { target *-*-* 
} .-1 }
+m1::NodePosition::foo2 => {}
+// { dg-error "failed to type resolve root segment" "" { target *-*-* 
} .-1 }
+}
+}
+
+pub fn main() {}
-- 
2.49.0

[COMMITTED 23/35] gccrs: Update exclusion list

[arthur . cohen]

From: Pierre-Emmanuel Patry 

gcc/testsuite/ChangeLog:

* rust/compile/nr2/exclude: Remove now passing tests from exclusion
list.

Signed-off-by: Pierre-Emmanuel Patry 
---
 gcc/testsuite/rust/compile/nr2/exclude | 6 --
 1 file changed, 6 deletions(-)

diff --git a/gcc/testsuite/rust/compile/nr2/exclude 
b/gcc/testsuite/rust/compile/nr2/exclude
index 9273bd1489e..75a0ae0ea0e 100644
--- a/gcc/testsuite/rust/compile/nr2/exclude
+++ b/gcc/testsuite/rust/compile/nr2/exclude
@@ -2,12 +2,8 @@ canonical_paths1.rs
 cfg1.rs
 generics9.rs
 issue-2043.rs
-issue-2330.rs
 issue-2812.rs
-issue-850.rs
-issue-855.rs
 issue-3315-2.rs
-iterators1.rs
 lookup_err1.rs
 macros/mbe/macro43.rs
 macros/mbe/macro6.rs
@@ -27,8 +23,6 @@ derive_clone_enum3.rs
 derive-debug1.rs
 derive-default1.rs
 issue-3402-1.rs
-for-loop1.rs
-for-loop2.rs
 issue-3403.rs
 derive-eq-invalid.rs
 derive-hash1.rs
-- 
2.49.0

[COMMITTED 28/35] gccrs: nr2.0: Rename prelude to lang_prelude

[arthur . cohen]

From: Owen Avery 

gcc/rust/ChangeLog:

* resolve/rust-forever-stack.h
(ForeverStack::get_prelude): Rename to...
(ForeverStack::get_lang_prelude): ...here.
(ForeverStack::prelude): Rename to...
(ForeverStack::lang_prelude): ...here.
(ForeverStack::ForeverStack): Handle renames.
* resolve/rust-forever-stack.hxx
(ForeverStack::push_inner): Likewise.
(ForeverStack::resolve_segments): Likewise.
(ForeverStack::resolve_path): Likewise.
(ForeverStack::get_prelude): Rename to...
(ForeverStack::get_lang_prelude): ...here and handle renames.
* resolve/rust-late-name-resolver-2.0.cc
(Late::visit): Handle renames.

Signed-off-by: Owen Avery 
---
 gcc/rust/resolve/rust-forever-stack.h   |  8 
 gcc/rust/resolve/rust-forever-stack.hxx | 17 +
 gcc/rust/resolve/rust-late-name-resolver-2.0.cc |  2 +-
 3 files changed, 14 insertions(+), 13 deletions(-)

diff --git a/gcc/rust/resolve/rust-forever-stack.h 
b/gcc/rust/resolve/rust-forever-stack.h
index d86212073b8..f390e3889df 100644
--- a/gcc/rust/resolve/rust-forever-stack.h
+++ b/gcc/rust/resolve/rust-forever-stack.h
@@ -548,7 +548,7 @@ template  class ForeverStack
 public:
   ForeverStack ()
 : root (Node (Rib (Rib::Kind::Normal), UNKNOWN_NODEID)),
-  prelude (Node (Rib (Rib::Kind::Prelude), UNKNOWN_NODEID, root)),
+  lang_prelude (Node (Rib (Rib::Kind::Prelude), UNKNOWN_NODEID, root)),
   cursor_reference (root)
   {
 rust_assert (root.is_root ());
@@ -658,8 +658,8 @@ public:
* the current map, an empty one otherwise.
*/
   tl::optional get (const Identifier &name);
-  tl::optional get_prelude (const Identifier &name);
-  tl::optional get_prelude (const std::string &name);
+  tl::optional get_lang_prelude (const Identifier &name);
+  tl::optional get_lang_prelude (const std::string &name);
 
   /**
* Resolve a path to its definition in the current `ForeverStack`
@@ -767,7 +767,7 @@ private:
* It has the root node as a parent, and acts as a "special case" for name
* resolution
*/
-  Node prelude;
+  Node lang_prelude;
 
   std::reference_wrapper cursor_reference;
 
diff --git a/gcc/rust/resolve/rust-forever-stack.hxx 
b/gcc/rust/resolve/rust-forever-stack.hxx
index fbe537d3b41..885f2820684 100644
--- a/gcc/rust/resolve/rust-forever-stack.hxx
+++ b/gcc/rust/resolve/rust-forever-stack.hxx
@@ -77,7 +77,7 @@ ForeverStack::push_inner (Rib rib, Link link)
   rust_assert (&cursor_reference.get () == &root);
   // Prelude doesn't have an access path
   rust_assert (!link.path);
-  update_cursor (this->prelude);
+  update_cursor (this->lang_prelude);
   return;
 }
   // If the link does not exist, we create it and emplace a new `Node` with the
@@ -319,16 +319,16 @@ ForeverStack::get (const Identifier &name)
 
 template 
 tl::optional
-ForeverStack::get_prelude (const Identifier &name)
+ForeverStack::get_lang_prelude (const Identifier &name)
 {
-  return prelude.rib.get (name.as_string ());
+  return lang_prelude.rib.get (name.as_string ());
 }
 
 template 
 tl::optional
-ForeverStack::get_prelude (const std::string &name)
+ForeverStack::get_lang_prelude (const std::string &name)
 {
-  return prelude.rib.get (name);
+  return lang_prelude.rib.get (name);
 }
 
 template <>
@@ -571,7 +571,7 @@ ForeverStack::resolve_segments (
  if (current_node->is_root () && !searched_prelude)
{
  searched_prelude = true;
- current_node = &prelude;
+ current_node = &lang_prelude;
  continue;
}
 
@@ -641,7 +641,8 @@ ForeverStack::resolve_path (
= get (unwrap_type_segment (segments.back ()).as_string ());
 
   if (!res)
-   res = get_prelude (unwrap_type_segment (segments.back ()).as_string ());
+   res = get_lang_prelude (
+ unwrap_type_segment (segments.back ()).as_string ());
 
   if (res && !res->is_ambiguous ())
insert_segment_resolution (segments.back (), res->get_node_id ());
@@ -672,7 +673,7 @@ ForeverStack::resolve_path (
 seg.is_lower_self_seg ());
   // Ok we didn't find it in the rib, Lets try the prelude...
   if (!res)
-   res = get_prelude (seg_name);
+   res = get_lang_prelude (seg_name);
 
   if (res && !res->is_ambiguous ())
insert_segment_resolution (segments.back (), res->get_node_id ());
diff --git a/gcc/rust/resolve/rust-late-name-resolver-2.0.cc 
b/gcc/rust/resolve/rust-late-name-resolver-2.0.cc
index 95df7272c75..7d323745edb 100644
--- a/gcc/rust/resolve/rust-late-name-resolver-2.0.cc
+++ b/gcc/rust/resolve/rust-late-name-resolver-2.0.cc
@@ -235,7 +235,7 @@ Late::visit (AST::IdentifierExpr &expr)
 }
   else
 {
-  if (auto type = ctx.types.get_prelude (expr.get_ident ()))
+  if (auto type = ctx.types.get_lang_prelude (expr.get_ident ()))
{
  resolved = 

[COMMITTED 34/35] gccrs: fix crash in parse repr options and missing delete call

[arthur . cohen]

From: Philip Herron 

Fixes Rust-GCC#3606

gcc/rust/ChangeLog:

* typecheck/rust-hir-type-check-base.cc 
(TypeCheckBase::parse_repr_options):
check for null and empty and add missing delete call

gcc/testsuite/ChangeLog:

* rust/compile/issue-3606.rs: New test.

Signed-off-by: Philip Herron 
---
 .../typecheck/rust-hir-type-check-base.cc | 20 +--
 gcc/testsuite/rust/compile/issue-3606.rs  |  6 ++
 2 files changed, 24 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/rust/compile/issue-3606.rs

diff --git a/gcc/rust/typecheck/rust-hir-type-check-base.cc 
b/gcc/rust/typecheck/rust-hir-type-check-base.cc
index 7fc6467e8ae..34a726cc665 100644
--- a/gcc/rust/typecheck/rust-hir-type-check-base.cc
+++ b/gcc/rust/typecheck/rust-hir-type-check-base.cc
@@ -321,8 +321,22 @@ TypeCheckBase::parse_repr_options (const AST::AttrVec 
&attrs, location_t locus)
  AST::AttrInputMetaItemContainer *meta_items
= option.parse_to_meta_item ();
 
- const std::string inline_option
-   = meta_items->get_items ().at (0)->as_string ();
+ if (meta_items == nullptr)
+   {
+ rust_error_at (attr.get_locus (), "malformed %qs attribute",
+"repr");
+ continue;
+   }
+
+ auto &items = meta_items->get_items ();
+ if (items.size () == 0)
+   {
+ // nothing to do with this its empty
+ delete meta_items;
+ continue;
+   }
+
+ const std::string inline_option = items.at (0)->as_string ();
 
  // TODO: it would probably be better to make the MetaItems more aware
  // of constructs with nesting like #[repr(packed(2))] rather than
@@ -359,6 +373,8 @@ TypeCheckBase::parse_repr_options (const AST::AttrVec 
&attrs, location_t locus)
  else if (is_align)
repr.align = value;
 
+ delete meta_items;
+
  // Multiple repr options must be specified with e.g. #[repr(C,
  // packed(2))].
  break;
diff --git a/gcc/testsuite/rust/compile/issue-3606.rs 
b/gcc/testsuite/rust/compile/issue-3606.rs
new file mode 100644
index 000..73b0bd6743b
--- /dev/null
+++ b/gcc/testsuite/rust/compile/issue-3606.rs
@@ -0,0 +1,6 @@
+// { dg-options "-w" }
+#[repr()]
+pub struct Coord {
+x: u32,
+y: u32,
+}
-- 
2.49.0

[PATCH] Libstdc++: Fix bootstrap failure for cross without tm.tm_zone [PR119550]

[Jonathan Wakely]

In r15-8491-g778c28c70f8573 I added a use of the Autoconf macro
AC_STRUCT_TIMEZONE, but that requires a link-test for the global tzname
object if tm.tm_zone isn't supported. That link-test isn't allowed for
cross-compilation, so bootstrap fails if tm.tm_zone isn't supported.

Since libstdc++ only cares about tm.tm_zone and won't use tzname anyway,
we don't need the link-test. Replace AC_STRUCT_TIMEZONE with a custom
macro that only checks for tm.tm_zone. We can improve on the Autoconf
macro by checking it's a suitable type, which isn't actually checked by
AC_STRUCT_TIMEZONE.

libstdc++-v3/ChangeLog:

PR libstdc++/119550
* acinclude.m4 (GLIBCXX_STRUCT_TM_TM_ZONE): New macro.
* config.h.in: Regenerate.
* configure: Regenerate.
* configure.ac: Use GLIBCXX_STRUCT_TM_TM_ZONE.
* include/bits/chrono_io.h (__formatter_chrono::_M_c): Check
_GLIBCXX_USE_STRUCT_TM_TM_ZONE instead of
_GLIBCXX_HAVE_STRUCT_TM_TM_ZONE.
---

Testing x86_64-linux and sparc-solaris2.11, looks fine so far.

 libstdc++-v3/acinclude.m4 |  35 
 libstdc++-v3/config.h.in  |  21 +--
 libstdc++-v3/configure| 238 --
 libstdc++-v3/configure.ac |   5 +-
 libstdc++-v3/include/bits/chrono_io.h |   2 +-
 5 files changed, 109 insertions(+), 192 deletions(-)

diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4
index e668d2dba27..02fd349e11d 100644
--- a/libstdc++-v3/acinclude.m4
+++ b/libstdc++-v3/acinclude.m4
@@ -5744,6 +5744,41 @@ AC_DEFUN([GLIBCXX_ZONEINFO_DIR], [
   fi
 ])
 
+dnl
+dnl Check for a tm_zone member in struct tm.
+dnl
+dnl This member is defined as const char* in Glibc, newlib, POSIX.1-2024,
+dnl and as char* in BSD (including macOS).
+dnl
+dnl Defines:
+dnl  _GLIBCXX_USE_STRUCT_TM_TM_ZONE if struct tm has a tm_zone member.
+dnl
+AC_DEFUN([GLIBCXX_STRUCT_TM_TM_ZONE], [
+
+  AC_LANG_SAVE
+  AC_LANG_CPLUSPLUS
+  ac_save_CXXFLAGS="$CXXFLAGS"
+  CXXFLAGS="$CXXFLAGS -std=c++20"
+
+  AC_CACHE_CHECK([for tm_zone member of struct tm], glibcxx_cv_tm_zone, [
+AC_COMPILE_IFELSE([AC_LANG_PROGRAM([#include 
+   ],
+   [struct tm t{}; t.tm_zone = (char*)0;]
+   )],
+   [glibcxx_cv_tm_zone=yes],
+   [glibcxx_cv_tm_zone=no]
+  )
+])
+
+  if test $glibcxx_cv_tm_zone = yes; then
+AC_DEFINE(_GLIBCXX_USE_STRUCT_TM_TM_ZONE, 1,
+ [Define if struct tm has a tm_zone member.])
+  fi
+
+  CXXFLAGS="$ac_save_CXXFLAGS"
+  AC_LANG_RESTORE
+])
+
 dnl
 dnl Check whether lock tables can be aligned to avoid false sharing.
 dnl
diff --git a/libstdc++-v3/config.h.in b/libstdc++-v3/config.h.in
index be151f43dd6..77bbaf1beaa 100644
--- a/libstdc++-v3/config.h.in
+++ b/libstdc++-v3/config.h.in
@@ -74,10 +74,6 @@
don't. */
 #undef HAVE_DECL_STRNLEN
 
-/* Define to 1 if you have the declaration of `tzname', and to 0 if you don't.
-   */
-#undef HAVE_DECL_TZNAME
-
 /* Define to 1 if you have the  header file. */
 #undef HAVE_DIRENT_H
 
@@ -412,9 +408,6 @@
 /* Define to 1 if `d_type' is a member of `struct dirent'. */
 #undef HAVE_STRUCT_DIRENT_D_TYPE
 
-/* Define to 1 if `tm_zone' is a member of `struct tm'. */
-#undef HAVE_STRUCT_TM_TM_ZONE
-
 /* Define if strxfrm_l is available in . */
 #undef HAVE_STRXFRM_L
 
@@ -506,17 +499,9 @@
 /* Define to 1 if the target supports thread-local storage. */
 #undef HAVE_TLS
 
-/* Define to 1 if your `struct tm' has `tm_zone'. Deprecated, use
-   `HAVE_STRUCT_TM_TM_ZONE' instead. */
-#undef HAVE_TM_ZONE
-
 /* Define if truncate is available in . */
 #undef HAVE_TRUNCATE
 
-/* Define to 1 if you don't have `tm_zone' but do have the external array
-   `tzname'. */
-#undef HAVE_TZNAME
-
 /* Define to 1 if you have the  header file. */
 #undef HAVE_UCHAR_H
 
@@ -605,9 +590,6 @@
 /* Define to 1 if you have the ANSI C header files. */
 #undef STDC_HEADERS
 
-/* Define to 1 if your  declares `struct tm'. */
-#undef TM_IN_SYS_TIME
-
 /* Version number of package */
 #undef VERSION
 
@@ -906,6 +888,9 @@
 /* Define to restrict std::__basic_file<> to stdio APIs. */
 #undef _GLIBCXX_USE_STDIO_PURE
 
+/* Define if struct tm has a tm_zone member. */
+#undef _GLIBCXX_USE_STRUCT_TM_TM_ZONE
+
 /* Define if struct stat has timespec members. */
 #undef _GLIBCXX_USE_ST_MTIM
 
diff --git a/libstdc++-v3/configure b/libstdc++-v3/configure
index 67d2b8c7b72..56d0bcb297e 100755
--- a/libstdc++-v3/configure
+++ b/libstdc++-v3/configure
@@ -2731,63 +2731,6 @@ $as_echo "$ac_res" >&6; }
   eval $as_lineno_stack; ${as_lineno_stack:+:} unset as_lineno
 
 } # ac_fn_c_check_decl
-
-# ac_fn_c_check_member LINENO AGGR MEMBER VAR INCLUDES
-# 
-# Tries to find if the field MEMBER exists in type AGGR, after including
-# INCLUDES, setting cache variable VAR accordingly.
-ac_fn_c_check_member ()
-{
-  as_lineno=${as_lineno-"$1"} as_lineno_stack=as_lineno_stack=$as_lineno_stack
-  { $as_echo "$as_me:${as_lineno-$LINENO}: chec

[COMMITTED 15/35] gccrs: Fix core library test with proper canonical path

[arthur . cohen]

From: Pierre-Emmanuel Patry 

Import from core library was wrong, it misses several crate directives
since we're no longer dealing with multiple files.

gcc/testsuite/ChangeLog:

* rust/compile/issue-2905-2.rs: Import from core library into a single
file misses the crate directives.

Signed-off-by: Pierre-Emmanuel Patry 
---
 gcc/testsuite/rust/compile/issue-2905-2.rs | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/gcc/testsuite/rust/compile/issue-2905-2.rs 
b/gcc/testsuite/rust/compile/issue-2905-2.rs
index 83c54ed92e5..1c9516df946 100644
--- a/gcc/testsuite/rust/compile/issue-2905-2.rs
+++ b/gcc/testsuite/rust/compile/issue-2905-2.rs
@@ -17,10 +17,10 @@ pub mod core {
 }
 
 pub mod slice {
-use core::marker::PhantomData;
-use core::option::Option;
+use crate::core::marker::PhantomData;
+use crate::core::option::Option;
 
-impl core::iter::IntoIterator for &[T] {
+impl crate::core::iter::IntoIterator for &[T] {
 type Item = &T;
 type IntoIter = Weird;
 
@@ -108,7 +108,7 @@ pub mod core {
 }
 
 pub mod iter {
-use option::Option;
+use crate::core::option::Option;
 
 pub trait IntoIterator {
 type Item;
-- 
2.49.0

[COMMITTED 04/35] gccrs: ast: Add optional diverging else to AST::LetStmt

[arthur . cohen]

From: Arthur Cohen 

gcc/rust/ChangeLog:

* ast/rust-stmt.h (class LetStmt): Add optional expression for 
diverging else.
* ast/rust-ast-builder.cc (Builder::let): Use new API.
---
 gcc/rust/ast/rust-ast-builder.cc |  3 ++-
 gcc/rust/ast/rust-stmt.h | 29 -
 2 files changed, 30 insertions(+), 2 deletions(-)

diff --git a/gcc/rust/ast/rust-ast-builder.cc b/gcc/rust/ast/rust-ast-builder.cc
index 86290e199c6..cdc6eec254b 100644
--- a/gcc/rust/ast/rust-ast-builder.cc
+++ b/gcc/rust/ast/rust-ast-builder.cc
@@ -17,6 +17,7 @@
 // .
 
 #include "rust-ast-builder.h"
+#include "optional.h"
 #include "rust-ast-builder-type.h"
 #include "rust-ast.h"
 #include "rust-common.h"
@@ -352,7 +353,7 @@ Builder::let (std::unique_ptr &&pattern, 
std::unique_ptr &&type,
 {
   return std::unique_ptr (new LetStmt (std::move (pattern),
 std::move (init), std::move (type),
-{}, loc));
+tl::nullopt, {}, loc));
 }
 
 std::unique_ptr
diff --git a/gcc/rust/ast/rust-stmt.h b/gcc/rust/ast/rust-stmt.h
index 6cbecaffd03..f843a79b3f9 100644
--- a/gcc/rust/ast/rust-stmt.h
+++ b/gcc/rust/ast/rust-stmt.h
@@ -19,6 +19,7 @@
 #ifndef RUST_AST_STATEMENT_H
 #define RUST_AST_STATEMENT_H
 
+#include "optional.h"
 #include "rust-ast.h"
 #include "rust-path.h"
 #include "rust-expr.h"
@@ -72,6 +73,8 @@ class LetStmt : public Stmt
   // bool has_init_expr;
   std::unique_ptr init_expr;
 
+  tl::optional> else_expr;
+
   location_t locus;
 
 public:
@@ -85,15 +88,18 @@ public:
 
   // Returns whether let statement has an initialisation expression.
   bool has_init_expr () const { return init_expr != nullptr; }
+  bool has_else_expr () const { return else_expr.has_value (); }
 
   std::string as_string () const override;
 
   LetStmt (std::unique_ptr variables_pattern,
   std::unique_ptr init_expr, std::unique_ptr type,
+  tl::optional> else_expr,
   std::vector outer_attrs, location_t locus)
 : outer_attrs (std::move (outer_attrs)),
   variables_pattern (std::move (variables_pattern)),
-  type (std::move (type)), init_expr (std::move (init_expr)), locus (locus)
+  type (std::move (type)), init_expr (std::move (init_expr)),
+  else_expr (std::move (else_expr)), locus (locus)
   {}
 
   // Copy constructor with clone
@@ -107,6 +113,9 @@ public:
 // guard to prevent null dereference (always required)
 if (other.init_expr != nullptr)
   init_expr = other.init_expr->clone_expr ();
+if (other.else_expr.has_value ())
+  else_expr = other.else_expr.value ()->clone_expr ();
+
 if (other.type != nullptr)
   type = other.type->clone_type ();
   }
@@ -128,6 +137,12 @@ public:
   init_expr = other.init_expr->clone_expr ();
 else
   init_expr = nullptr;
+
+if (other.else_expr != nullptr)
+  else_expr = other.else_expr.value ()->clone_expr ();
+else
+  else_expr = tl::nullopt;
+
 if (other.type != nullptr)
   type = other.type->clone_type ();
 else
@@ -162,12 +177,24 @@ public:
 return *init_expr;
   }
 
+  Expr &get_else_expr ()
+  {
+rust_assert (has_else_expr ());
+return *else_expr.value ();
+  }
+
   std::unique_ptr &get_init_expr_ptr ()
   {
 rust_assert (has_init_expr ());
 return init_expr;
   }
 
+  std::unique_ptr &get_else_expr_ptr ()
+  {
+rust_assert (has_else_expr ());
+return else_expr.value ();
+  }
+
   Pattern &get_pattern ()
   {
 rust_assert (variables_pattern != nullptr);
-- 
2.49.0

[COMMITTED 20/35] gccrs: Fix ICE when doing method resolution on trait predicates

[arthur . cohen]

From: Philip Herron 

We need to ensure we are adding methods to the possible candidates.

Fixes Rust-GCC#3554

gcc/rust/ChangeLog:

* typecheck/rust-hir-dot-operator.cc:

gcc/testsuite/ChangeLog:

* rust/compile/issue-3554-1.rs: New test.
* rust/compile/issue-3554-2.rs: New test.

Signed-off-by: Philip Herron 
---
 gcc/rust/typecheck/rust-hir-dot-operator.cc |  7 +--
 gcc/testsuite/rust/compile/issue-3554-1.rs  |  8 
 gcc/testsuite/rust/compile/issue-3554-2.rs  | 18 ++
 3 files changed, 31 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/rust/compile/issue-3554-1.rs
 create mode 100644 gcc/testsuite/rust/compile/issue-3554-2.rs

diff --git a/gcc/rust/typecheck/rust-hir-dot-operator.cc 
b/gcc/rust/typecheck/rust-hir-dot-operator.cc
index 38bd5b75fb7..c1165e9e5b1 100644
--- a/gcc/rust/typecheck/rust-hir-dot-operator.cc
+++ b/gcc/rust/typecheck/rust-hir-dot-operator.cc
@@ -472,8 +472,11 @@ MethodResolver::get_predicate_items (
   if (ty->get_kind () == TyTy::TypeKind::FNDEF)
{
  TyTy::FnType *fnty = static_cast (ty);
- predicate_candidate candidate{lookup, fnty};
- predicate_items.push_back (candidate);
+ if (fnty->is_method ())
+   {
+ predicate_candidate candidate{lookup, fnty};
+ predicate_items.push_back (candidate);
+   }
}
 }
 
diff --git a/gcc/testsuite/rust/compile/issue-3554-1.rs 
b/gcc/testsuite/rust/compile/issue-3554-1.rs
new file mode 100644
index 000..a66be35d363
--- /dev/null
+++ b/gcc/testsuite/rust/compile/issue-3554-1.rs
@@ -0,0 +1,8 @@
+trait Tr {
+fn foo();
+
+fn bar(&self) {
+self.foo()
+// { dg-error "no method named .foo. found in the current scope 
.E0599." "" { target *-*-* } .-1 }
+}
+}
diff --git a/gcc/testsuite/rust/compile/issue-3554-2.rs 
b/gcc/testsuite/rust/compile/issue-3554-2.rs
new file mode 100644
index 000..e455a8b2cec
--- /dev/null
+++ b/gcc/testsuite/rust/compile/issue-3554-2.rs
@@ -0,0 +1,18 @@
+#[lang = "sized"]
+pub trait Sized {}
+
+#[lang = "fn_once"]
+pub trait FnOnce {
+#[lang = "fn_once_output"]
+type Output;
+
+extern "rust-call" fn call_once(self, args: Args) -> Self::Output;
+}
+trait Tr {
+fn foo();
+
+fn bar(&self) {
+(|| self.foo())()
+// { dg-error "no method named .foo. found in the current scope 
.E0599." "" { target *-*-* } .-1 }
+}
+}
-- 
2.49.0

[COMMITTED 17/35] gccrs: Add check for super traits being implemented by Self

[arthur . cohen]

From: Philip Herron 

We need to recursively check the super traits of the predicate the Self
type is trying to implement. Otherwise its cannot implement it.

Fixes Rust-GCC#3553

gcc/rust/ChangeLog:

* typecheck/rust-hir-type-check-item.cc 
(TypeCheckItem::resolve_impl_block_substitutions):
Track the polarity
* typecheck/rust-tyty-bounds.cc 
(TypeBoundPredicate::validate_type_implements_this):
new validator
* typecheck/rust-tyty.h: new prototypes

gcc/testsuite/ChangeLog:

* rust/compile/issue-3553.rs: New test.

Signed-off-by: Philip Herron 
---
 .../typecheck/rust-hir-type-check-item.cc | 13 +++-
 gcc/rust/typecheck/rust-tyty-bounds.cc| 59 +++
 gcc/rust/typecheck/rust-tyty.h|  8 +++
 gcc/testsuite/rust/compile/issue-3553.rs  | 18 ++
 4 files changed, 95 insertions(+), 3 deletions(-)
 create mode 100644 gcc/testsuite/rust/compile/issue-3553.rs

diff --git a/gcc/rust/typecheck/rust-hir-type-check-item.cc 
b/gcc/rust/typecheck/rust-hir-type-check-item.cc
index a003848cce0..97749214351 100644
--- a/gcc/rust/typecheck/rust-hir-type-check-item.cc
+++ b/gcc/rust/typecheck/rust-hir-type-check-item.cc
@@ -725,11 +725,11 @@ TypeCheckItem::resolve_impl_block_substitutions 
(HIR::ImplBlock &impl_block,
 
   // we don't error out here see: gcc/testsuite/rust/compile/traits2.rs
   // for example
-  specified_bound = get_predicate_from_bound (ref, impl_block.get_type ());
+  specified_bound = get_predicate_from_bound (ref, impl_block.get_type (),
+ impl_block.get_polarity ());
 }
 
   TyTy::BaseType *self = TypeCheckType::Resolve (impl_block.get_type ());
-
   if (self->is ())
 {
   // we cannot check for unconstrained type arguments when the Self type is
@@ -771,7 +771,14 @@ TypeCheckItem::validate_trait_impl_block (
 
   // we don't error out here see: gcc/testsuite/rust/compile/traits2.rs
   // for example
-  specified_bound = get_predicate_from_bound (ref, impl_block.get_type ());
+  specified_bound = get_predicate_from_bound (ref, impl_block.get_type (),
+ impl_block.get_polarity ());
+
+  // need to check that if this specified bound has super traits does this
+  // Self
+  // implement them?
+  specified_bound.validate_type_implements_super_traits (
+   *self, impl_block.get_type (), impl_block.get_trait_ref ());
 }
 
   bool is_trait_impl_block = !trait_reference->is_error ();
diff --git a/gcc/rust/typecheck/rust-tyty-bounds.cc 
b/gcc/rust/typecheck/rust-tyty-bounds.cc
index 65f24c0aa2a..e028a0af80b 100644
--- a/gcc/rust/typecheck/rust-tyty-bounds.cc
+++ b/gcc/rust/typecheck/rust-tyty-bounds.cc
@@ -828,6 +828,65 @@ TypeBoundPredicate::is_equal (const TypeBoundPredicate 
&other) const
   return true;
 }
 
+bool
+TypeBoundPredicate::validate_type_implements_super_traits (
+  TyTy::BaseType &self, HIR::Type &impl_type, HIR::Type &trait) const
+{
+  if (get_polarity () != BoundPolarity::RegularBound)
+return true;
+
+  auto &ptref = *get ();
+  for (auto &super : super_traits)
+{
+  if (super.get_polarity () != BoundPolarity::RegularBound)
+   continue;
+
+  if (!super.validate_type_implements_this (self, impl_type, trait))
+   {
+ auto &sptref = *super.get ();
+
+ // emit error
+ std::string fixit1
+   = "required by this bound in: " + ptref.get_name ();
+ std::string fixit2 = "the trait " + sptref.get_name ()
+  + " is not implemented for "
+  + impl_type.as_string ();
+
+ rich_location r (line_table, trait.get_locus ());
+ r.add_fixit_insert_after (super.get_locus (), fixit1.c_str ());
+ r.add_fixit_insert_after (trait.get_locus (), fixit2.c_str ());
+ rust_error_at (r, ErrorCode::E0277,
+"the trait bound %<%s: %s%> is not satisfied",
+impl_type.as_string ().c_str (),
+sptref.get_name ().c_str ());
+
+ return false;
+   }
+
+  if (!super.validate_type_implements_super_traits (self, impl_type, 
trait))
+   return false;
+}
+
+  return true;
+}
+
+bool
+TypeBoundPredicate::validate_type_implements_this (TyTy::BaseType &self,
+  HIR::Type &impl_type,
+  HIR::Type &trait) const
+{
+  const auto &ptref = *get ();
+  auto probed_bounds = Resolver::TypeBoundsProbe::Probe (&self);
+  for (auto &elem : probed_bounds)
+{
+  auto &tref = *(elem.first);
+  if (ptref.is_equal (tref))
+   return true;
+}
+
+  return false;
+}
+
 // trait item reference
 
 const Resolver::TraitItemReference *
diff --git a/gcc/rust/typecheck/rust-tyty.h b/gcc/rust/typecheck/rust-tyty.h
index 0bfd29d98bb..e814f07f445 100644
--- 

[COMMITTED 14/35] gccrs: fix unconstrained infer vars on generic associated type

[arthur . cohen]

From: Philip Herron 

The trick here is that when Bar::test is resolved it resolves to the
trait method:

  fn , T> (placeholder) -> placeholder

Which is fine so we need to setup the associated types for Bar which
means looking up the associated impl block then setting up the projection
of A = T so it becomes:

  fn , T> (placeholder: projection:T)
-> placeholder: projection:T

But previously it was auto injecting inference variables so it became:

  fn , T> (placeholder: projection:?T)
-> placeholder: projection:?T

The issue is that the binding of the generics was still T so this caused
inference variables to be injected again but unlinked. A possible tweak
would be that we are substituting again with new infer vars to actually
just unify them enplace so they are all part of the chain. This still
might be needed but lets hold off for now.

So basically when we are Path probing we dont allow GAT's to generate new
inference vars because they wont be bound to this current segment which
just causes confusion.

Fixes Rust-GCC#3242

gcc/rust/ChangeLog:

* typecheck/rust-hir-trait-reference.h: add default infer arg
* typecheck/rust-hir-trait-resolve.cc: dont add new infer vars
* typecheck/rust-hir-type-check-path.cc 
(TypeCheckExpr::resolve_segments): dont infer

gcc/testsuite/ChangeLog:

* rust/compile/issue-3242.rs: no longer skip the test

Signed-off-by: Philip Herron 
---
 gcc/rust/typecheck/rust-hir-trait-reference.h  | 7 +++
 gcc/rust/typecheck/rust-hir-trait-resolve.cc   | 8 
 gcc/rust/typecheck/rust-hir-type-check-path.cc | 4 ++--
 gcc/testsuite/rust/compile/issue-3242.rs   | 1 -
 4 files changed, 9 insertions(+), 11 deletions(-)

diff --git a/gcc/rust/typecheck/rust-hir-trait-reference.h 
b/gcc/rust/typecheck/rust-hir-trait-reference.h
index 6a570ed0fdb..8b1ac7daf7f 100644
--- a/gcc/rust/typecheck/rust-hir-trait-reference.h
+++ b/gcc/rust/typecheck/rust-hir-trait-reference.h
@@ -254,10 +254,9 @@ public:
 
   void setup_raw_associated_types ();
 
-  TyTy::BaseType *
-  setup_associated_types (const TyTy::BaseType *self,
- const TyTy::TypeBoundPredicate &bound,
- TyTy::SubstitutionArgumentMappings *args = nullptr);
+  TyTy::BaseType *setup_associated_types (
+const TyTy::BaseType *self, const TyTy::TypeBoundPredicate &bound,
+TyTy::SubstitutionArgumentMappings *args = nullptr, bool infer = true);
 
   void reset_associated_types ();
 
diff --git a/gcc/rust/typecheck/rust-hir-trait-resolve.cc 
b/gcc/rust/typecheck/rust-hir-trait-resolve.cc
index c07425d48b7..e4a61bdb062 100644
--- a/gcc/rust/typecheck/rust-hir-trait-resolve.cc
+++ b/gcc/rust/typecheck/rust-hir-trait-resolve.cc
@@ -485,7 +485,7 @@ AssociatedImplTrait::setup_raw_associated_types ()
 TyTy::BaseType *
 AssociatedImplTrait::setup_associated_types (
   const TyTy::BaseType *self, const TyTy::TypeBoundPredicate &bound,
-  TyTy::SubstitutionArgumentMappings *args)
+  TyTy::SubstitutionArgumentMappings *args, bool infer)
 {
   // compute the constrained impl block generic arguments based on self and the
   // higher ranked trait bound
@@ -545,7 +545,7 @@ AssociatedImplTrait::setup_associated_types (
   std::vector subst_args;
   for (auto &p : substitutions)
 {
-  if (p.needs_substitution ())
+  if (p.needs_substitution () && infer)
{
  TyTy::TyVar infer_var = TyTy::TyVar::get_implicit_infer_var (locus);
  subst_args.push_back (
@@ -619,7 +619,7 @@ AssociatedImplTrait::setup_associated_types (
= unify_site_and (a->get_ref (), TyTy::TyWithLocation (a),
  TyTy::TyWithLocation (b), impl_predicate.get_locus (),
  true /*emit-errors*/, true /*commit-if-ok*/,
- false /*infer*/, true /*cleanup-on-fail*/);
+ true /*infer*/, true /*cleanup-on-fail*/);
   rust_assert (result->get_kind () != TyTy::TypeKind::ERROR);
 }
 
@@ -632,7 +632,7 @@ AssociatedImplTrait::setup_associated_types (
TyTy::TyWithLocation (impl_self_infer),
impl_predicate.get_locus (),
true /*emit-errors*/, true /*commit-if-ok*/,
-   false /*infer*/, true /*cleanup-on-fail*/);
+   true /*infer*/, true /*cleanup-on-fail*/);
   rust_assert (result->get_kind () != TyTy::TypeKind::ERROR);
   TyTy::BaseType *self_result = result;
 
diff --git a/gcc/rust/typecheck/rust-hir-type-check-path.cc 
b/gcc/rust/typecheck/rust-hir-type-check-path.cc
index 33570ffa1c7..1fe39aaeb64 100644
--- a/gcc/rust/typecheck/rust-hir-type-check-path.cc
+++ b/gcc/rust/typecheck/rust-hir-type-check-path.cc
@@ -535,8 +535,8 @@ TypeCheckExpr::resolve_segments (NodeId 
root_resolved_node_id,
= impl_block_ty->lookup_predicate (trait_ref.get_defid ());
  if (!predicate.is_error ())

[COMMITTED 22/35] gccrs: Resolve module final self segment in use decls

[arthur . cohen]

From: Pierre-Emmanuel Patry 

Lowercase self suffix with path was not resolved properly, this should
point to the module right before.

gcc/rust/ChangeLog:

* resolve/rust-forever-stack.hxx: Add a new specialized function
to retrieve the last "real" segment depending on the namespace.
* resolve/rust-forever-stack.h: Add new function prototype.
* resolve/rust-early-name-resolver-2.0.cc 
(Early::finalize_rebind_import):
Set declared name according to the selected segment, if there is a self
suffix in the use declaration then select the previous segment.

Signed-off-by: Pierre-Emmanuel Patry 
---
 .../resolve/rust-early-name-resolver-2.0.cc   | 17 ---
 gcc/rust/resolve/rust-forever-stack.h |  4 +++
 gcc/rust/resolve/rust-forever-stack.hxx   | 29 ---
 3 files changed, 42 insertions(+), 8 deletions(-)

diff --git a/gcc/rust/resolve/rust-early-name-resolver-2.0.cc 
b/gcc/rust/resolve/rust-early-name-resolver-2.0.cc
index 492a665f43e..afaca1f71f0 100644
--- a/gcc/rust/resolve/rust-early-name-resolver-2.0.cc
+++ b/gcc/rust/resolve/rust-early-name-resolver-2.0.cc
@@ -417,10 +417,19 @@ Early::finalize_rebind_import (const Early::ImportPair 
&mapping)
   declared_name = rebind.get_identifier ().as_string ();
   locus = rebind.get_identifier ().get_locus ();
   break;
-case AST::UseTreeRebind::NewBindType::NONE:
-  declared_name = path.get_final_segment ().as_string ();
-  locus = path.get_final_segment ().get_locus ();
-  break;
+  case AST::UseTreeRebind::NewBindType::NONE: {
+   const auto &segments = path.get_segments ();
+   // We don't want to insert `self` with `use module::self`
+   if (path.get_final_segment ().is_lower_self_seg ())
+ {
+   rust_assert (segments.size () > 1);
+   declared_name = segments[segments.size () - 2].as_string ();
+ }
+   else
+ declared_name = path.get_final_segment ().as_string ();
+   locus = path.get_final_segment ().get_locus ();
+   break;
+  }
 case AST::UseTreeRebind::NewBindType::WILDCARD:
   rust_unreachable ();
   break;
diff --git a/gcc/rust/resolve/rust-forever-stack.h 
b/gcc/rust/resolve/rust-forever-stack.h
index 2a4c7348728..d86212073b8 100644
--- a/gcc/rust/resolve/rust-forever-stack.h
+++ b/gcc/rust/resolve/rust-forever-stack.h
@@ -795,6 +795,10 @@ private:
 SegIterator iterator,
 std::function insert_segment_resolution);
 
+  tl::optional resolve_final_segment (Node &final_node,
+  std::string &seg_name,
+  bool is_lower_self);
+
   /* Helper functions for forward resolution (to_canonical_path, to_rib...) */
   struct DfsResult
   {
diff --git a/gcc/rust/resolve/rust-forever-stack.hxx 
b/gcc/rust/resolve/rust-forever-stack.hxx
index a6e0b30a57b..fbe537d3b41 100644
--- a/gcc/rust/resolve/rust-forever-stack.hxx
+++ b/gcc/rust/resolve/rust-forever-stack.hxx
@@ -594,6 +594,26 @@ ForeverStack::resolve_segments (
   return *current_node;
 }
 
+template <>
+inline tl::optional
+ForeverStack::resolve_final_segment (Node &final_node,
+  std::string &seg_name,
+  bool is_lower_self)
+{
+  if (is_lower_self)
+return Rib::Definition::NonShadowable (final_node.id);
+  else
+return final_node.rib.get (seg_name);
+}
+
+template 
+tl::optional
+ForeverStack::resolve_final_segment (Node &final_node, std::string 
&seg_name,
+   bool is_lower_self)
+{
+  return final_node.rib.get (seg_name);
+}
+
 template 
 template 
 tl::optional
@@ -643,12 +663,13 @@ ForeverStack::resolve_path (
   if (final_node.rib.kind == Rib::Kind::TraitOrImpl)
return tl::nullopt;
 
-  std::string seg_name
-   = unwrap_type_segment (segments.back ()).as_string ();
+  auto &seg = unwrap_type_segment (segments.back ());
+  std::string seg_name = seg.as_string ();
 
   // assuming this can't be a lang item segment
-  tl::optional res = final_node.rib.get (seg_name);
-
+  tl::optional res
+   = resolve_final_segment (final_node, seg_name,
+seg.is_lower_self_seg ());
   // Ok we didn't find it in the rib, Lets try the prelude...
   if (!res)
res = get_prelude (seg_name);
-- 
2.49.0

[COMMITTED 02/35] gccrs: Fix testcase module path

[arthur . cohen]

From: Pierre-Emmanuel Patry 

Those tests are coming from libcore and module inlining was wrong, in
libcore there was a use declaration to import those modules which was
missing here.

gcc/testsuite/ChangeLog:

* rust/compile/issue-2330.rs: Use complete path from crate root.
* rust/compile/issue-1901.rs: Likewise.
* rust/compile/issue-1981.rs: Likewise.
* rust/compile/iterators1.rs: Likewise.
* rust/compile/sizeof-stray-infer-var-bug.rs: Likewise.
* rust/compile/for-loop1.rs: Likewise.
* rust/compile/for-loop2.rs: Likewise.
* rust/compile/torture/builtin_abort.rs: Likewise.
* rust/compile/torture/uninit-intrinsic-1.rs: Likewise.

Signed-off-by: Pierre-Emmanuel Patry 
---
 gcc/testsuite/rust/compile/for-loop1.rs   | 60 -
 gcc/testsuite/rust/compile/for-loop2.rs   | 66 ++-
 gcc/testsuite/rust/compile/issue-1901.rs  |  4 +-
 gcc/testsuite/rust/compile/issue-1981.rs  | 40 +--
 gcc/testsuite/rust/compile/issue-2330.rs  | 38 +--
 gcc/testsuite/rust/compile/iterators1.rs  | 58 
 .../compile/sizeof-stray-infer-var-bug.rs |  2 +-
 .../rust/compile/torture/builtin_abort.rs |  4 +-
 .../compile/torture/uninit-intrinsic-1.rs |  4 +-
 9 files changed, 139 insertions(+), 137 deletions(-)

diff --git a/gcc/testsuite/rust/compile/for-loop1.rs 
b/gcc/testsuite/rust/compile/for-loop1.rs
index 1023ecde1c3..21e0399161b 100644
--- a/gcc/testsuite/rust/compile/for-loop1.rs
+++ b/gcc/testsuite/rust/compile/for-loop1.rs
@@ -102,30 +102,30 @@ mod ptr {
 #[lang = "const_ptr"]
 impl *const T {
 pub unsafe fn offset(self, count: isize) -> *const T {
-intrinsics::offset(self, count)
+crate::intrinsics::offset(self, count)
 }
 }
 
 #[lang = "mut_ptr"]
 impl *mut T {
 pub unsafe fn offset(self, count: isize) -> *mut T {
-intrinsics::offset(self, count) as *mut T
+crate::intrinsics::offset(self, count) as *mut T
 }
 }
 
 pub unsafe fn swap_nonoverlapping(x: *mut T, y: *mut T, count: usize) {
 let x = x as *mut u8;
 let y = y as *mut u8;
-let len = mem::size_of::() * count;
+let len = crate::mem::size_of::() * count;
 swap_nonoverlapping_bytes(x, y, len)
 }
 
 pub unsafe fn swap_nonoverlapping_one(x: *mut T, y: *mut T) {
 // For types smaller than the block optimization below,
 // just swap directly to avoid pessimizing codegen.
-if mem::size_of::() < 32 {
+if crate::mem::size_of::() < 32 {
 let z = read(x);
-intrinsics::copy_nonoverlapping(y, x, 1);
+crate::intrinsics::copy_nonoverlapping(y, x, 1);
 write(y, z);
 } else {
 swap_nonoverlapping(x, y, 1);
@@ -133,12 +133,12 @@ mod ptr {
 }
 
 pub unsafe fn write(dst: *mut T, src: T) {
-intrinsics::move_val_init(&mut *dst, src)
+crate::intrinsics::move_val_init(&mut *dst, src)
 }
 
 pub unsafe fn read(src: *const T) -> T {
-let mut tmp: T = mem::uninitialized();
-intrinsics::copy_nonoverlapping(src, &mut tmp, 1);
+let mut tmp: T = crate::mem::uninitialized();
+crate::intrinsics::copy_nonoverlapping(src, &mut tmp, 1);
 tmp
 }
 
@@ -146,7 +146,7 @@ mod ptr {
 struct Block(u64, u64, u64, u64);
 struct UnalignedBlock(u64, u64, u64, u64);
 
-let block_size = mem::size_of::();
+let block_size = crate::mem::size_of::();
 
 // Loop through x & y, copying them `Block` at a time
 // The optimizer should unroll the loop fully for most types
@@ -155,31 +155,31 @@ mod ptr {
 while i + block_size <= len {
 // Create some uninitialized memory as scratch space
 // Declaring `t` here avoids aligning the stack when this loop is 
unused
-let mut t: Block = mem::uninitialized();
+let mut t: Block = crate::mem::uninitialized();
 let t = &mut t as *mut _ as *mut u8;
 let x = x.offset(i as isize);
 let y = y.offset(i as isize);
 
 // Swap a block of bytes of x & y, using t as a temporary buffer
 // This should be optimized into efficient SIMD operations where 
available
-intrinsics::copy_nonoverlapping(x, t, block_size);
-intrinsics::copy_nonoverlapping(y, x, block_size);
-intrinsics::copy_nonoverlapping(t, y, block_size);
+crate::intrinsics::copy_nonoverlapping(x, t, block_size);
+crate::intrinsics::copy_nonoverlapping(y, x, block_size);
+crate::intrinsics::copy_nonoverlapping(t, y, block_size);
 i += block_size;
 }
 
 if i < len {
 // Swap any remaining bytes
-let mut t: UnalignedBlock = mem::uninitialized();
+let mut t: Un

[COMMITTED 30/35] gccrs: Fix ICE in array ref constexpr

[arthur . cohen]

From: Philip Herron 

Since 898d55ad7e2 was fixed to remove the VIEW_CONVERT_EXPR from
array expressions we can now turn on the array element access
const expr.

Fixes Rust-GCC#3563

gcc/rust/ChangeLog:

* backend/rust-constexpr.cc (eval_store_expression): turn this back on

gcc/testsuite/ChangeLog:

* rust/compile/issue-3563.rs: New test.

Signed-off-by: Philip Herron 
---
 gcc/rust/backend/rust-constexpr.cc   |  6 ++
 gcc/testsuite/rust/compile/issue-3563.rs | 17 +
 2 files changed, 19 insertions(+), 4 deletions(-)
 create mode 100644 gcc/testsuite/rust/compile/issue-3563.rs

diff --git a/gcc/rust/backend/rust-constexpr.cc 
b/gcc/rust/backend/rust-constexpr.cc
index 2f2bbbd921d..dc2d6b1066b 100644
--- a/gcc/rust/backend/rust-constexpr.cc
+++ b/gcc/rust/backend/rust-constexpr.cc
@@ -2697,10 +2697,8 @@ eval_store_expression (const constexpr_ctx *ctx, tree t, 
bool lval,
  }
if (TREE_CODE (probe) == ARRAY_REF)
  {
-   // TODO
-   rust_unreachable ();
-   // elt = eval_and_check_array_index (ctx, probe, false,
-   //non_constant_p, overflow_p);
+   elt = eval_and_check_array_index (ctx, probe, false,
+ non_constant_p, overflow_p);
if (*non_constant_p)
  return t;
  }
diff --git a/gcc/testsuite/rust/compile/issue-3563.rs 
b/gcc/testsuite/rust/compile/issue-3563.rs
new file mode 100644
index 000..46e762464b8
--- /dev/null
+++ b/gcc/testsuite/rust/compile/issue-3563.rs
@@ -0,0 +1,17 @@
+pub struct AA {
+pub data: [u8; 10],
+}
+
+impl AA {
+pub const fn new() -> Self {
+let mut res: AA = AA { data: [0; 10] };
+res.data[0] = 5;
+res
+}
+}
+
+static mut BB: AA = AA::new();
+
+fn main() {
+let _ptr = unsafe { &mut BB };
+}
-- 
2.49.0

Re: [PATCH]

[Jeff Law]

On 3/31/25 1:05 PM, Alexandre Oliva wrote:


[testsuite] [riscv] limit vwaddsub-1.c to rv64

The desired vw{add,sub}.wx instructions don't come up on rv32 for the
first two functions, we get v{add,sub}.vx instead.

I suppose this is an oversight, and something about the test is meant
for rv64 only, but the fact that the instruction is spelled out in the
intrinsic name and a different instruction is generated suggests
something may be wrong after all.


I could use a pointer to specs for these intrinsics and instructions to
tell for sure, but a closer look from someone more familiar with them
would definitely be welcome.

Tested on x86_64-linux-gnu native, and gcc-14 target riscv{64,32}-elf.
Ok to install?


for  gcc/testsuite/ChangeLog

* gcc.target/riscv/rvv/base/vwaddsub-1.c: Require rv64.
I don't immediately see anything in this test or its history to indicate 
it's only supposed to work for rv64.  So it'd be better dig a bit 
further into this one.


jeff

Re: [PATCH] [testsuite] [riscv] limit mcpu-xiangshan-nanhu.c to rv64

[Jeff Law]

On 3/31/25 1:02 PM, Alexandre Oliva wrote:


The testcase makes the -march option conditional on rv64, and #errors
out if the desired CPU properties are not active.  This makes the test
fail on rv32.  Arrange to skip the test on rv32 instead, moving the
rv64 conditional.

Tested on x86_64-linux-gnu native, and gcc-14 target riscv{64,32}-elf.
Ok to install?


for  gcc/testsuite/ChangeLog

* gcc.target/riscv/mcpu-xiangshan-nanhu.c: Skip on non-rv64.

OK
jeff

Re: [PATCH] [testsuite] [riscv] limit vwaddsub-1.c to rv64

[Alexandre Oliva]

On Mar 31, 2025, Jeff Law  wrote:

> On 3/31/25 1:05 PM, Alexandre Oliva wrote:

>> The desired vw{add,sub}.wx instructions don't come up on rv32 for
>> the
>> first two functions, we get v{add,sub}.vx instead.

>> I suppose this is an oversight, and something about the test is
>> meant
>> for rv64 only, but the fact that the instruction is spelled out in the
>> intrinsic name and a different instruction is generated suggests
>> something may be wrong after all.

>> for  gcc/testsuite/ChangeLog
>> * gcc.target/riscv/rvv/base/vwaddsub-1.c: Require rv64.

> I don't immediately see anything in this test or its history to
> indicate it's only supposed to work for rv64.

It's the 64-bit integral argument rs1.

On rv64, it's in a single 64-bit register, that needs to be narrowed to
32 bits and then sign extended to 64 bits to fit the semantics of
vwadd.vx.

On rv32, the 64-bit argument is passed in two separate registers, the
narrowing amounts to picking the first of the pair, and at that point it
becomes vadd.vx.

Likewise vwsub.vx->vsub.vx.

So the test is indeed meant for rv64, but only because there's another,
presumably better way to perform the requested operation on rv32.

-- 
Alexandre Oliva, happy hackerhttps://blog.lx.oliva.nom.br/
Free Software Activist FSFLA co-founder GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity.
Excluding neuro-others for not behaving ""normal"" is *not* inclusive!

Re: [PATCH v2] RISC-V: vsetvl: skip abnormal edge on vsetvl insertion [PR119533]

[Jeff Law]

On 3/31/25 3:43 PM, Vineet Gupta wrote:


But what state is in play that caused it to want to insert something?
That's what needs to be understood here.  I don't see anything in bb64
that requires vsetvl to be in any particular state.  So why did vsetvl
insertion think that it needed to insert anything on the edge to bb64?


emit vsetvl (phase 4), sweeps thru all BBs and if they have any vsetvl info
(local or global) it visits all edges (including abnormal) and inserts the
vsetvl on edge.
So if there is a block local need, then it gets inserted on the incoming 
edge(s).



It seems local would be when a BB needs vsetvl functionally (due to presence of
a V insn) vs. a global case being said BB part part of control flow eventually
leading to a BB with local vsetvl need.
And if that's the case then you can't simply skip an abnormal edge.  You 
have to do something sensible.


That "something sensible" has traditionally been to ensure there is 
never a need propagated to an edge since you can't insert on an abnormal 
critical edge.




So there is no real criteria for insertion here, its insert on every edge.
If there is a need in the block, then every path to the block must have 
the right value.  That's precisely my point.  You can't simply skip an 
edge in this case.


What needs to happen is you need to find a way to ensure there is no 
need at the start of the block that has incoming abnormal/EH edges. 
This is a classic problem in LCM algorithms.


See "prune_expressions" in gcse.cc.  I think the moral equivalent for 
vsetvl generation is to conceptually kill every vsetvl at the entry 
point to any block that as an incoming abnormal edge.  That should push 
the insertion point into the block instead of to the incoming edges.


Jeff

Re: [PATCH] [testsuite] [riscv] limit vwaddsub-1.c to rv64

[Jeff Law]

On 3/31/25 7:03 PM, Alexandre Oliva wrote:

On Mar 31, 2025, Jeff Law  wrote:

I don't immediately see anything in this test or its history to
indicate it's only supposed to work for rv64.


It's the 64-bit integral argument rs1.
Right, but ISTM we ought to be able to handle a vector of 64bit integral 
types, especially from the intrinsics interface.


Probably the thing to do is see what the intrinsics docs say.   Or maybe 
Kito knows offhand.





On rv64, it's in a single 64-bit register, that needs to be narrowed to
32 bits and then sign extended to 64 bits to fit the semantics of
vwadd.vx.
Ah.  A vx form.  That's the key here.  Indeed I don't think we can have 
a 64bit argument for the scalar argument in a .vx form insn.


So objection cleared.  OK for the trunk.
jeff

Re: [PATCH] [testsuite] [riscv] xfail some [PR113281] tests

[Jeff Law]

On 3/31/25 1:01 PM, Alexandre Oliva wrote:


Some of the tests regressed with a fix for the vectorization of
shifts.  The riscv cost models need to be adjusted to avoid the
unprofitable optimization.  The failure of these tests has been known
since 2024-03-13, without a forthcoming fix, so I suggest we consider
it expected by now.  Adjust the tests to reflect that expectation.

Tested on x86_64-linux-gnu native, and gcc-14 target riscv{64,32}-elf.
Ok to install?


for  gcc/testsuite/ChangeLog

PR tree-optimization/113281
* gcc.dg/vect/costmodel/riscv/rvv/pr113281-1.c: XFAIL.
* gcc.dg/vect/costmodel/riscv/rvv/pr113281-2.c: Likewise.
* gcc.dg/vect/costmodel/riscv/rvv/pr113281-5.c: Likewise.
So weirdly, these aren't running in my tester.  I don't see any evidence 
they've ever been tested.  But that's my problem, not yours :-)


If you verify they're failing on the trunk on riscv64-elf and/or 
riscv32-elf, then this is fine.


Also note that if you use "RISC-V" rather than "riscv" your patches will 
be automatically picked up by the pre-commit tester.


jeff

[COMMITTED 29/35] gccrs: Add ending newline to rust-macro-builtins-log-debug.cc

[arthur . cohen]

From: Owen Avery 

gcc/rust/ChangeLog:

* expand/rust-macro-builtins-log-debug.cc:
Add newline to end of file.

Signed-off-by: Owen Avery 
---
 gcc/rust/expand/rust-macro-builtins-log-debug.cc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/rust/expand/rust-macro-builtins-log-debug.cc 
b/gcc/rust/expand/rust-macro-builtins-log-debug.cc
index 49670d2b986..3d7b54f7b0c 100644
--- a/gcc/rust/expand/rust-macro-builtins-log-debug.cc
+++ b/gcc/rust/expand/rust-macro-builtins-log-debug.cc
@@ -30,4 +30,4 @@ MacroBuiltin::assert_handler (location_t invoc_locus,
 
   return AST::Fragment::create_error ();
 }
-} // namespace Rust
\ No newline at end of file
+} // namespace Rust
-- 
2.49.0

Re: [PATCH] [testsuite] [riscv] xfail update-threading on riscv [PR110628]

[Jeff Law]

On 3/31/25 1:00 PM, Alexandre Oliva wrote:


The failure to adjust estimated profiling frequencies in reassoc noted
in PR110628 affects riscv as well.  Add it to the XFAIL set.

Tested on x86_64-linux-gnu native, and gcc-14 target riscv{64,32}-elf.
Ok to install?


for  gcc/testsuite/ChangeLog

PR tree-optimization/110628
* gcc.dg/tree-ssa/update-threading.c: XFAIL on riscv.

?!? This is passing on my tester:


PASS: gcc.dg/tree-ssa/update-threading.c (test for excess errors)
PASS: gcc.dg/tree-ssa/update-threading.c (test for excess errors)
PASS: gcc.dg/tree-ssa/update-threading.c scan-tree-dump-times optimized "Invalid 
sum" 0
PASS: gcc.dg/tree-ssa/update-threading.c scan-tree-dump-times optimized "Invalid 
sum" 0



JEff

Re: [PATCH v2] RISC-V: vsetvl: skip abnormal edge on vsetvl insertion [PR119533]

[Vineet Gupta]

On 3/31/25 12:39, Jeff Law wrote:
* config/riscv/riscv-vsetvl.cc (pre_vsetvl::emit_vsetvl): skip
EDGE_ABNORMAL.

 gcc/testsuite/ChangeLog:

* go.dg/pr119533-riscv.go: New test.
>>> So presumably it wants to insert on the EH edge for a reason.  Just
>>> skipping the edge is probably wrong.
>>>
>>> The way these scenarios are handled in the more generic LCM passes is to
>>> kill all values on the EH edge.  With all values killed on the EH edge,
>>> no redundancy exists which should require insertion on the edge.
>> Lets do some dump diving - pun intended.
>>
>> Failure happens at the following abnormal edge:
>>
>>  Insert missed vsetvl info at edge(bb 42 -> bb 64):VALID (insn 663, bb 
>> 64)
>>
>>
>> Where bb 64 corresponds to unwinder call so clearly EH related.
>>
>>  (code_label/s 474 591 476 64 37 (nil) [1 uses])
>>  (note 476 474 438 64 [bb 64] NOTE_INSN_BASIC_BLOCK)
>>  (call_insn 438 476 439 64 (parallel [
>>      (call (mem:SI (symbol_ref:DI ("_Unwind_Resume") [flags 0x41]
>>  ) [0
>>  __builtin_unwind_resume S4 A32])
>>      (const_int 0 [0]))
>>      (use (unspec:SI [
>>      (const_int 0 [0])
>>      ] UNSPEC_CALLEE_CC))
>>      (clobber (reg:SI 1 ra))
>>      ]) 456 {call_internal}
>>   (expr_list:REG_DEAD (reg:DI 10 a0)
>>      (expr_list:REG_CALL_DECL (symbol_ref:DI ("_Unwind_Resume") 
>> [flags
>>  0x41]  )
>>      (expr_list:REG_NORETURN (const_int 0 [0])
>>      (nil
>>      (expr_list:DI (use (reg:DI 10 a0))
>>      (nil)))
>>  (barrier 439 438 617)
>>
>>
>> The edge 42 -> 64 already exists at the entry of vsetvl, so its not something
>> that the vsetvl/LCM creates.
>>
>>  Entering Lazy VSETVL PASS
>>  ...
>>  ...
>>  ;; 27 succs { 64 28 }
>>  ;; 28 succs { 64 29 } <---
>>  ;; 29 succs { 30 43 }
>>  ;; 30 succs { 64 31 }
>>  ;; 31 succs { 32 43 }
>>  ;; 32 succs { 64 33 }
>>  ;; 33 succs { 64 34 }
>>  ;; 34 succs { 64 35 }
>>  ;; 35 succs { 36 39 }
>>  ;; 36 succs { 64 37 }
>>  ;; 37 succs { 64 38 }
>>  ;; 38 succs { 39 }
>>  ;; 39 succs { 64 40 }
>>  ;; 40 succs { 64 41 }
>>  ;; 41 succs { 64 42 }
>>  ;; 42 succs { 64 43 }   <
>>  ...
>>  ...
>>
>> In the working case, --param=vsetvl-strategy=simple, in cprop (just before
>> vsetvl), I don't see any jumps to the code label of bb 64 (with Unwinder 
>> call)
>> either.
>>
>> I don't think vsetvl LCM is supposed to prune this edge out. In fact in the
>> routine to prepare LCM bitmaps I skip bb 42 (by checking for EDGE_CRITICAL in
>> invalid_opt_bb_p ()
>> The problem now happens in bb 28, which also happens to have edge to 64.
>>
>> So it seems to me that it should be safe to just skip the abnormal edge.
> But what state is in play that caused it to want to insert something? 
> That's what needs to be understood here.  I don't see anything in bb64 
> that requires vsetvl to be in any particular state.  So why did vsetvl 
> insertion think that it needed to insert anything on the edge to bb64?

emit vsetvl (phase 4), sweeps thru all BBs and if they have any vsetvl info
(local or global) it visits all edges (including abnormal) and inserts the
vsetvl on edge.
It seems local would be when a BB needs vsetvl functionally (due to presence of
a V insn) vs. a global case being said BB part part of control flow eventually
leading to a BB with local vsetvl need.
So there is no real criteria for insertion here, its insert on every edge. Seems
like we need to skip some edges, somehow. Whether that needs to be unconditional
or say only if vsetvl info is non-local or excluding some bbs from LCM - I don't
know. Someone like Juzhe more familiar with the design would know better.

Thx,
-Vineet

[COMMITTED 10/35] rust: Lower minimum supported Rust version to 1.49

[arthur . cohen]

From: Arthur Cohen 

gcc/rust/ChangeLog:

* checks/errors/borrowck/ffi-polonius/Cargo.lock: Regenerate.
* checks/errors/borrowck/ffi-polonius/Cargo.toml: Update to use source 
patching instead of
vendoring, lower edition to 2018.
* checks/errors/borrowck/ffi-polonius/vendor/log/Cargo.toml: Change 
edition to 2018.
* checks/errors/borrowck/ffi-polonius/vendor/log/src/lib.rs: Remove 
uses of unstable
feature.
* checks/errors/borrowck/ffi-polonius/.cargo/config.toml: Removed.

libgrust/ChangeLog:

* libformat_parser/Makefile.am: Avoid using --config as it is 
unsupported by cargo 1.49.
* libformat_parser/Makefile.in: Regenerate.
* libformat_parser/generic_format_parser/src/lib.rs: Use extension 
trait for missing
features.
* libformat_parser/src/lib.rs: Likewise.
* libformat_parser/.cargo/config: Moved to...
* libformat_parser/.cargo/config.toml: ...here.
---
 .../errors/borrowck/ffi-polonius/Cargo.lock   |  10 --
 .../errors/borrowck/ffi-polonius/Cargo.toml   |  10 +-
 .../ffi-polonius/vendor/log/Cargo.toml|   2 +-
 .../ffi-polonius/vendor/log/src/lib.rs| 138 --
 libgrust/libformat_parser/.cargo/config   |   5 -
 .../libformat_parser}/.cargo/config.toml  |   0
 libgrust/libformat_parser/Makefile.am |  11 +-
 libgrust/libformat_parser/Makefile.in |  10 +-
 .../generic_format_parser/src/lib.rs  |  14 ++
 libgrust/libformat_parser/src/lib.rs  |  11 ++
 10 files changed, 41 insertions(+), 170 deletions(-)
 delete mode 100644 libgrust/libformat_parser/.cargo/config
 rename {gcc/rust/checks/errors/borrowck/ffi-polonius => 
libgrust/libformat_parser}/.cargo/config.toml (100%)

diff --git a/gcc/rust/checks/errors/borrowck/ffi-polonius/Cargo.lock 
b/gcc/rust/checks/errors/borrowck/ffi-polonius/Cargo.lock
index f7cbd414caf..1b223b65556 100644
--- a/gcc/rust/checks/errors/borrowck/ffi-polonius/Cargo.lock
+++ b/gcc/rust/checks/errors/borrowck/ffi-polonius/Cargo.lock
@@ -1,12 +1,8 @@
 # This file is automatically @generated by Cargo.
 # It is not intended for manual editing.
-version = 3
-
 [[package]]
 name = "datafrog"
 version = "2.0.1"
-source = "registry+https://github.com/rust-lang/crates.io-index";
-checksum = "a0afaad2b26fa326569eb264b1363e8ae3357618c43982b3f285f0774ce76b69"
 
 [[package]]
 name = "ffi-polonius"
@@ -18,14 +14,10 @@ dependencies = [
 [[package]]
 name = "log"
 version = "0.4.22"
-source = "registry+https://github.com/rust-lang/crates.io-index";
-checksum = "a7a70ba024b9dc04c27ea2f0c0548feb474ec5c54bba33a7f72f873a39d07b24"
 
 [[package]]
 name = "polonius-engine"
 version = "0.13.0"
-source = "registry+https://github.com/rust-lang/crates.io-index";
-checksum = "c4e8e505342045d397d0b6674dcb82d6faf5cf40484d30eeb88fc82ef14e903f"
 dependencies = [
  "datafrog",
  "log",
@@ -35,5 +27,3 @@ dependencies = [
 [[package]]
 name = "rustc-hash"
 version = "1.1.0"
-source = "registry+https://github.com/rust-lang/crates.io-index";
-checksum = "08d43f7aa6b08d49f382cde6a7982047c3426db949b1424bc4b7ec9ae12c6ce2"
diff --git a/gcc/rust/checks/errors/borrowck/ffi-polonius/Cargo.toml 
b/gcc/rust/checks/errors/borrowck/ffi-polonius/Cargo.toml
index 71315c3b635..3bc8e3f873e 100644
--- a/gcc/rust/checks/errors/borrowck/ffi-polonius/Cargo.toml
+++ b/gcc/rust/checks/errors/borrowck/ffi-polonius/Cargo.toml
@@ -1,11 +1,17 @@
 [package]
 name = "ffi-polonius"
 version = "0.1.0"
-edition = "2021"
+edition = "2018"
 license = "GPL-3"
 
 [lib]
 crate-type = ["staticlib"]
 
 [dependencies]
-polonius-engine = "0.13.0"
\ No newline at end of file
+polonius-engine = "0.13.0"
+
+[patch.crates-io]
+log = { path = "vendor/log" }
+datafrog = { path = "vendor/datafrog" }
+polonius-engine = { path = "vendor/polonius-engine" }
+rustc-hash = { path = "vendor/rustc-hash" }
diff --git a/gcc/rust/checks/errors/borrowck/ffi-polonius/vendor/log/Cargo.toml 
b/gcc/rust/checks/errors/borrowck/ffi-polonius/vendor/log/Cargo.toml
index 313a0051ae5..a199e317010 100644
--- a/gcc/rust/checks/errors/borrowck/ffi-polonius/vendor/log/Cargo.toml
+++ b/gcc/rust/checks/errors/borrowck/ffi-polonius/vendor/log/Cargo.toml
@@ -10,7 +10,7 @@
 # See Cargo.toml.orig for the original contents.
 
 [package]
-edition = "2021"
+edition = "2018"
 rust-version = "1.60.0"
 name = "log"
 version = "0.4.22"
diff --git a/gcc/rust/checks/errors/borrowck/ffi-polonius/vendor/log/src/lib.rs 
b/gcc/rust/checks/errors/borrowck/ffi-polonius/vendor/log/src/lib.rs
index 6b43a9ae16d..603bbacb18c 100644
--- a/gcc/rust/checks/errors/borrowck/ffi-polonius/vendor/log/src/lib.rs
+++ b/gcc/rust/checks/errors/borrowck/ffi-polonius/vendor/log/src/lib.rs
@@ -397,20 +397,13 @@ mod serde;
 #[cfg(feature = "kv")]
 pub mod kv;
 
-#[cfg(target_has_atomic = "ptr")]
-use std::sync::atomic::{AtomicUsize, Ordering};
-
-#[cfg(not(target_has_atomic = "ptr"))]
 use std::cell::Cell;
-#[cfg(not(target_has_atomic = "ptr"))]
 use s

Re: [PATCH] libstdc++: Fix up string _M_constructor exports [PR103827]

[Jonathan Wakely]

On Mon, 31 Mar 2025 at 16:11, Rainer Orth  wrote:
>
> Jonathan Wakely  writes:
>
> > On Sun, 30 Mar 2025, 23:15 Jakub Jelinek,  wrote:
> >
> >> On Thu, Mar 27, 2025 at 02:04:24PM +0100, Jan Hubicka wrote:
> >> > > > Newline between functions please.
> >> > > >
> >> > > > OK with those two changes.
> >> > >
> >> > > Looking back through my inbox, this one doesn't seem to have been
> >> > > pushed. Was it superseded by something else, or is it just waiting for
> >> > > stage 1 now?
> >> >
> >> > Seems I missed the approval, sorry.  I will push it - I think it would
> >> > be useful to have it in.
> >> > (I have more libstdc++ work for next stage1, but solving this is IMO
> >> > useful)
> >>
> >> Unfortunately the exports in this patch only work on targets where size_t
> >> is
> >> unsigned long, not e.g. on ia32 where it is unsigned int, or targets where
> >> it is unsigned long long.
> >>
> >> Fixed thusly, tested on x86_64-linux and i686-linux, ok for trunk?
> >>
> >
> > OK, thanks
>
> with those two patches in, Solaris bootstrap with the native ld is
> broken linking libstdc++.so:
>
> ld: fatal: libstdc++-symbols.ver-sun: 7449: symbol 
> '_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_M_constructILb0EEEvPKcj':
>  symbol version conflict
> ld: fatal: libstdc++-symbols.ver-sun: 7450: symbol 
> '_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_M_constructILb1EEEvPKcj':
>  symbol version conflict
> ld: fatal: libstdc++-symbols.ver-sun: 7451: symbol 
> '_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_M_constructILb0EEEvPKwj':
>  symbol version conflict
> ld: fatal: libstdc++-symbols.ver-sun: 7452: symbol 
> '_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_M_constructILb1EEEvPKwj':
>  symbol version conflict
> collect2: error: ld returned 1 exit status
>
> E.g. 
> _ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_M_constructILb0EEEvPKcj
> is matched by both
>
> _ZNSt7__cxx1112basic_stringI[cw]St11char_traitsI[cw]ESaI[cw]EE12_M*
>
> in GLIBCXX_3.4.21 and
>
> _ZNSt7__cxx1112basic_stringI[cw]St11char_traitsI[cw]ESaI[cw]EE12_M_constructILb[01]EEEvPK[cw][jmy]
>
> in GLIBCXX_3.4.34.

This should fix it:

--- a/libstdc++-v3/config/abi/pre/gnu.ver
+++ b/libstdc++-v3/config/abi/pre/gnu.ver
@@ -1767,7 +1767,8 @@ GLIBCXX_3.4.21 {

_ZNSt7__cxx1112basic_stringI[cw]St11char_traitsI[cw]ESaI[cw]EE10_S_compareE[jmy][jmy];

_ZNSt7__cxx1112basic_stringI[cw]St11char_traitsI[cw]ESaI[cw]EE11_M_capacityE[jmy];

_ZNSt7__cxx1112basic_stringI[cw]St11char_traitsI[cw]ESaI[cw]EE12_Alloc_hiderC[12]EP[cw]RKS3_;
-_ZNSt7__cxx1112basic_stringI[cw]St11char_traitsI[cw]ESaI[cw]EE12_M*;
+
_ZNSt7__cxx1112basic_stringI[cw]St11char_traitsI[cw]ESaI[cw]EE12_M_constructE[jmy][cw];
+
_ZNSt7__cxx1112basic_stringI[cw]St11char_traitsI[cw]ESaI[cw]EE12_M_constructI[NP]*;
_ZNSt7__cxx1112basic_stringI[cw]St11char_traitsI[cw]ESaI[cw]EE13*;

_ZNSt7__cxx1112basic_stringI[cw]St11char_traitsI[cw]ESaI[cw]EE14_M_replace_aux*;
_ZNSt7__cxx1112basic_stringI[cw]St11char_traitsI[cw]ESaI[cw]EE1[68-9]*;

Re: [PATCH] RISC-V: testsuite: Fix broken testsuite error of zicbop

[Kito Cheng]

Thanks, pushed to trunk :)

On Mon, Mar 31, 2025 at 4:54 PM Liao Shihua  wrote:
>
> Fix broken testsuite like
> "ERROR: gcc.target/riscv/cmo-zicbop-2.c   -Os : 1: too many arguments for " 
> dg-do 1 compile target { { rv32-*-*}} "
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/riscv/cmo-zicbop-1.c: Fix missing { before target .
> * gcc.target/riscv/cmo-zicbop-2.c: Likewise.
> * gcc.target/riscv/prefetch-zicbop.c:Likewise.
> * gcc.target/riscv/prefetch-zihintntl.c:Likewise.
>
> ---
>  gcc/testsuite/gcc.target/riscv/cmo-zicbop-1.c   | 2 +-
>  gcc/testsuite/gcc.target/riscv/cmo-zicbop-2.c   | 2 +-
>  gcc/testsuite/gcc.target/riscv/prefetch-zicbop.c| 2 +-
>  gcc/testsuite/gcc.target/riscv/prefetch-zihintntl.c | 2 +-
>  4 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/gcc/testsuite/gcc.target/riscv/cmo-zicbop-1.c 
> b/gcc/testsuite/gcc.target/riscv/cmo-zicbop-1.c
> index e40874fc3df..581b5dbbfbf 100644
> --- a/gcc/testsuite/gcc.target/riscv/cmo-zicbop-1.c
> +++ b/gcc/testsuite/gcc.target/riscv/cmo-zicbop-1.c
> @@ -1,4 +1,4 @@
> -/* { dg-do compile target { { rv64-*-*}} } */
> +/* { dg-do compile { target rv64-*-* } } */
>  /* { dg-options "-march=rv64gc_zicbop -mabi=lp64" } */
>
>  void foo (char *p)
> diff --git a/gcc/testsuite/gcc.target/riscv/cmo-zicbop-2.c 
> b/gcc/testsuite/gcc.target/riscv/cmo-zicbop-2.c
> index dd6e1eafd44..3f7c1a455ad 100644
> --- a/gcc/testsuite/gcc.target/riscv/cmo-zicbop-2.c
> +++ b/gcc/testsuite/gcc.target/riscv/cmo-zicbop-2.c
> @@ -1,4 +1,4 @@
> -/* { dg-do compile target { { rv32-*-*}} } */
> +/* { dg-do compile { target rv64-*-* } } */
>  /* { dg-options "-march=rv32gc_zicbop -mabi=ilp32" } */
>
>  void foo (char *p)
> diff --git a/gcc/testsuite/gcc.target/riscv/prefetch-zicbop.c 
> b/gcc/testsuite/gcc.target/riscv/prefetch-zicbop.c
> index 250f9ec6b0a..44da4b2e578 100644
> --- a/gcc/testsuite/gcc.target/riscv/prefetch-zicbop.c
> +++ b/gcc/testsuite/gcc.target/riscv/prefetch-zicbop.c
> @@ -1,4 +1,4 @@
> -/* { dg-do compile target { { rv64-*-*}} } */
> +/* { dg-do compile { target rv64-*-* } } */
>  /* { dg-options "-march=rv64gc_zicbop -mabi=lp64" } */
>
>  void foo (char *p)
> diff --git a/gcc/testsuite/gcc.target/riscv/prefetch-zihintntl.c 
> b/gcc/testsuite/gcc.target/riscv/prefetch-zihintntl.c
> index 54e809f4353..43439d7aee6 100644
> --- a/gcc/testsuite/gcc.target/riscv/prefetch-zihintntl.c
> +++ b/gcc/testsuite/gcc.target/riscv/prefetch-zihintntl.c
> @@ -1,4 +1,4 @@
> -/* { dg-do compile target { { rv64-*-*}} } */
> +/* { dg-do compile { target rv64-*-* } } */
>  /* { dg-options "-march=rv64gc_zicbop_zihintntl -mabi=lp64" } */
>
>  void foo (char *p)
> --
> 2.43.0
>

[PATCH] RISC-V: Tweak testcase for PIE

[Kito Cheng]

Linux toolchain may configured with --enable-default-pie, and that will
cause lots of regression test failures because the function name will
append with @plt suffix (e.g. `call foo` become `call foo@plt`).

We may consider just drop @plt suffix to prevent that at all, because
it's not difference between w/ and w/o @plt suffix, the linker will pick
the right one to do, however it's late stage of GCC development, so just
tweak the testcase should be the best way to do now.

gcc/testsuite/ChangeLog:

* g++.target/riscv/mv-symbols1.C: Tweak testcase.
* g++.target/riscv/mv-symbols3.C: Likewise.
* g++.target/riscv/mv-symbols4.C: Likewise.
* g++.target/riscv/mv-symbols5.C: Likewise.
* g++.target/riscv/mvc-symbols1.C: Likewise.
* g++.target/riscv/mvc-symbols3.C: Likewise.
* gcc.target/riscv/cm_mv_rv32.c: Likewise.
* gcc.target/riscv/cpymem-64.c: Likewise.
* gcc.target/riscv/fmax-snan.c: Likewise.
* gcc.target/riscv/fmaxf-snan.c: Likewise.
* gcc.target/riscv/fmin-snan.c: Likewise.
* gcc.target/riscv/fminf-snan.c: Likewise.
* gcc.target/riscv/large-model.c: Likewise.
* gcc.target/riscv/predef-1.c: Likewise.
* gcc.target/riscv/predef-4.c: Likewise.
* gcc.target/riscv/predef-7.c: Likewise.
* gcc.target/riscv/predef-9.c: Likewise.
* gcc.target/riscv/rv32e_zcmp.c: Likewise.
* gcc.target/riscv/rv32i_zcmp.c: Likewise.
* gcc.target/riscv/zcmp_stack_alignment.c: Likewise.
---
 gcc/testsuite/g++.target/riscv/mv-symbols1.C  | 4 ++--
 gcc/testsuite/g++.target/riscv/mv-symbols3.C  | 4 ++--
 gcc/testsuite/g++.target/riscv/mv-symbols4.C  | 4 ++--
 gcc/testsuite/g++.target/riscv/mv-symbols5.C  | 4 ++--
 gcc/testsuite/g++.target/riscv/mvc-symbols1.C | 4 ++--
 gcc/testsuite/g++.target/riscv/mvc-symbols3.C | 4 ++--
 gcc/testsuite/gcc.target/riscv/cm_mv_rv32.c   | 4 ++--
 gcc/testsuite/gcc.target/riscv/cpymem-64.c| 4 ++--
 gcc/testsuite/gcc.target/riscv/fmax-snan.c| 2 +-
 gcc/testsuite/gcc.target/riscv/fmaxf-snan.c   | 2 +-
 gcc/testsuite/gcc.target/riscv/fmin-snan.c| 2 +-
 gcc/testsuite/gcc.target/riscv/fminf-snan.c   | 2 +-
 gcc/testsuite/gcc.target/riscv/large-model.c  | 2 +-
 gcc/testsuite/gcc.target/riscv/predef-1.c | 2 +-
 gcc/testsuite/gcc.target/riscv/predef-4.c | 2 +-
 gcc/testsuite/gcc.target/riscv/predef-7.c | 2 +-
 gcc/testsuite/gcc.target/riscv/predef-9.c | 2 +-
 gcc/testsuite/gcc.target/riscv/rv32e_zcmp.c   | 6 +++---
 gcc/testsuite/gcc.target/riscv/rv32i_zcmp.c   | 6 +++---
 gcc/testsuite/gcc.target/riscv/zcmp_stack_alignment.c | 2 +-
 20 files changed, 32 insertions(+), 32 deletions(-)

diff --git a/gcc/testsuite/g++.target/riscv/mv-symbols1.C 
b/gcc/testsuite/g++.target/riscv/mv-symbols1.C
index ea1a536fd00..a0e3f1e8f6d 100644
--- a/gcc/testsuite/g++.target/riscv/mv-symbols1.C
+++ b/gcc/testsuite/g++.target/riscv/mv-symbols1.C
@@ -57,7 +57,7 @@ int bar(int x)
 /* { dg-final { scan-assembler-times "\n_Z3foov\.arch__v:\n" 1 } } */
 /* { dg-final { scan-assembler-times "\n_Z3foov\.arch__zba__zbb:\n" 1 } } */
 /* { dg-final { scan-assembler-times "\n_Z3foov\.resolver:\n" 1 } } */
-/* { dg-final { scan-assembler-times "\n\t\call\t_Z3foov\n" 1 } } */
+/* { dg-final { scan-assembler-times "\n\t\call\t_Z3foov(?:@plt)\n" 1 } } */
 /* { dg-final { scan-assembler-times "\n\t\.type\t_Z3foov, 
@gnu_indirect_function\n" 1 } } */
 /* { dg-final { scan-assembler-times "\n\t\.set\t_Z3foov,_Z3foov\.resolver\n" 
1 } } */
 
@@ -65,6 +65,6 @@ int bar(int x)
 /* { dg-final { scan-assembler-times "\n_Z3fooi\.arch__v:\n" 1 } } */
 /* { dg-final { scan-assembler-times "\n_Z3fooi\.arch__zba__zbb:\n" 1 } } */
 /* { dg-final { scan-assembler-times "\n_Z3fooi\.resolver:\n" 1 } } */
-/* { dg-final { scan-assembler-times "\n\t\call\t_Z3fooi\n" 1 } } */
+/* { dg-final { scan-assembler-times "\n\t\call\t_Z3fooi(?:@plt)\n" 1 } } */
 /* { dg-final { scan-assembler-times "\n\t\.type\t_Z3fooi, 
@gnu_indirect_function\n" 1 } } */
 /* { dg-final { scan-assembler-times "\n\t\.set\t_Z3fooi,_Z3fooi\.resolver\n" 
1 } } */
diff --git a/gcc/testsuite/g++.target/riscv/mv-symbols3.C 
b/gcc/testsuite/g++.target/riscv/mv-symbols3.C
index 4dc81cf7395..ca85b545210 100644
--- a/gcc/testsuite/g++.target/riscv/mv-symbols3.C
+++ b/gcc/testsuite/g++.target/riscv/mv-symbols3.C
@@ -37,7 +37,7 @@ int bar()
 /* { dg-final { scan-assembler-times "\n_Z3foov\.arch__v:\n" 0 } } */
 /* { dg-final { scan-assembler-times "\n_Z3foov\.arch__zba__zbb:\n" 0 } } */
 /* { dg-final { scan-assembler-times "\n_Z3foov\.resolver:\n" 1 } } */
-/* { dg-final { scan-assembler-times "\n\tcall\t_Z3foov\n" 1 } } */
+/* { dg-final { scan-assembler-times "\n\tcall\t_Z3foov(?:@plt)\n" 1 } } */
 /* { dg-final { scan-assembler-times "\n\t\.type\t_Z3foov, 
@gnu_indirect_f

[PATCH 4/7] ipa-cp: Use the stored and streamed pass-through types in ipa-vr (PR118785)

[Martin Jambor]

This patch revisits the fix for PR 118785 and intead of deducing the
necessary operation type it just uses the value collected and streamed
by an earlier patch.

gcc/ChangeLog:

Bootstrapped and tested and LTO bootstrapped on x86_64-linux. OK for
master?

Thanks,

Martin


2025-03-20  Martin Jambor  

PR ipa/118785
* ipa-cp.cc (ipa_vr_intersect_with_arith_jfunc): Use the stored
and streamed type of arithmetic pass-through functions.
---
 gcc/ipa-cp.cc | 28 ++--
 1 file changed, 2 insertions(+), 26 deletions(-)

diff --git a/gcc/ipa-cp.cc b/gcc/ipa-cp.cc
index d81cda9b9ba..e39a9e144ad 100644
--- a/gcc/ipa-cp.cc
+++ b/gcc/ipa-cp.cc
@@ -1735,24 +1735,7 @@ ipa_vr_intersect_with_arith_jfunc (vrange &vr,
   const value_range *inter_vr;
   if (operation != NOP_EXPR)
{
- /* Since we construct arithmetic jump functions even when there is a
- type conversion in between the operation encoded in the jump
- function and when it is passed in a call argument, the IPA
- propagation phase must also perform the operation and conversion
- in two separate steps.
-
-TODO: In order to remove the use of expr_type_first_operand_type_p
-predicate we would need to stream the operation type, ideally
-encoding the whole jump function as a series of expr_eval_op
-structures.  */
-
- tree operation_type;
- if (expr_type_first_operand_type_p (operation))
-   operation_type = src_type;
- else if (operation == ABSU_EXPR)
-   operation_type = unsigned_type_for (src_type);
- else
-   return;
+ tree operation_type = ipa_get_jf_pass_through_op_type (jfunc);
  op_res.set_varying (operation_type);
  if (!ipa_vr_operation_and_type_effects (op_res, src_vr, operation,
  operation_type, src_type))
@@ -1782,14 +1765,7 @@ ipa_vr_intersect_with_arith_jfunc (vrange &vr,
   value_range op_vr (TREE_TYPE (operand));
   ipa_get_range_from_ip_invariant (op_vr, operand, context_node);
 
-  tree operation_type;
-  if (TREE_CODE_CLASS (operation) == tcc_comparison)
-operation_type = boolean_type_node;
-  else if (expr_type_first_operand_type_p (operation))
-operation_type = src_type;
-  else
-return;
-
+  tree operation_type = ipa_get_jf_pass_through_op_type (jfunc);
   value_range op_res (operation_type);
   if (!ipa_vr_supported_type_p (operation_type)
   || !handler.operand_check_p (operation_type, src_type, op_vr.type ())
-- 
2.48.1

[RFC PATCH 6/7] ipa: Remove type checks in arithmetic pass-through jfunc construction

[Martin Jambor]

After reviewing the code involving arithmetic pass-through jump
functions I found out that we actually do check that the type of the
LHS is compatible with the type of the first operand on the RHS.  Now
that we stream the types of the LHS of these operations, this is no
longer necessary - and we happen not to do it for unary operations,
something I have missed when reviewing their addition.  This patch
therefore removes these checks.

Bootstrapped and tested and LTO bootstrapped on x86_64-linux but my
plan is to propose this only in the next stage 1.

Thanks,

Martin

gcc/ChangeLog:

2025-03-21  Martin Jambor  

* ipa-prop.cc (compute_complex_assign_jump_func): Remove test for
comparison operation or type compatibility of LHS and RHS1.
(analyze_agg_content_value): Likewise.
---
 gcc/ipa-prop.cc | 11 +--
 1 file changed, 1 insertion(+), 10 deletions(-)

diff --git a/gcc/ipa-prop.cc b/gcc/ipa-prop.cc
index d882b997bf4..59ef00db823 100644
--- a/gcc/ipa-prop.cc
+++ b/gcc/ipa-prop.cc
@@ -1530,11 +1530,7 @@ compute_complex_assign_jump_func (struct 
ipa_func_body_info *fbi,
case GIMPLE_BINARY_RHS:
  {
tree op2 = gimple_assign_rhs2 (stmt);
-   if (!is_gimple_ip_invariant (op2)
-   || ((TREE_CODE_CLASS (gimple_assign_rhs_code (stmt))
-!= tcc_comparison)
-   && !useless_type_conversion_p (TREE_TYPE (name),
-  TREE_TYPE (op1
+   if (!is_gimple_ip_invariant (op2))
  return;
 
ipa_set_jf_arith_pass_through (jfunc, index, op2,
@@ -2032,11 +2028,6 @@ analyze_agg_content_value (struct ipa_func_body_info 
*fbi,
  }
else
  return;
-
-   if (TREE_CODE_CLASS (code) != tcc_comparison
-   && !useless_type_conversion_p (TREE_TYPE (lhs),
-  TREE_TYPE (rhs1)))
- return;
  }
  break;
 
-- 
2.48.1

[RFC PATCH 7/7] ipa: Allow a type conversion in construction of aggregate jump functions

[Martin Jambor]

When computing arithmetic pass-through jump functions for parameters
themselves (aka scalars), we allow a data preserving type conversion
in between the call and the gimple calculation that is represented by
the jump function.  When doing the same for values passed in
aggregates or passed by reference, we skip a chain of simple
assignments but so far do not allow a type conversion between the
corresponding store to memory and the gimple calculations even though
now we do stream both types and so can represent the conversion.  This
patch simply allows a type conversion to occur also in this case.

Bootstrapped and tested and LTO bootstrapped on x86_64-linux but my
plan is to propose this only in the next stage 1.

Thanks,

Martin


gcc/ChangeLog:

2025-03-24  Martin Jambor  

* ipa-prop.cc (is_a_safe_conversion_stmt_p): New function.
(skip_a_safe_conversion_op): Moved up in the file.  Moved most of the
functionality to is_a_safe_conversion_stmt_p.
(analyze_agg_content_value): Allow skipping a data preserving
conversion.
---
 gcc/ipa-prop.cc | 102 ++--
 1 file changed, 64 insertions(+), 38 deletions(-)

diff --git a/gcc/ipa-prop.cc b/gcc/ipa-prop.cc
index 59ef00db823..edf644ec52e 100644
--- a/gcc/ipa-prop.cc
+++ b/gcc/ipa-prop.cc
@@ -1865,6 +1865,59 @@ build_agg_jump_func_from_list (struct 
ipa_known_agg_contents_list *list,
 }
 }
 
+/* Return true if DEF is a statement that performs a simple type conversion
+   from an integer type to another integer type which is known to be able to
+   represent the values the operand of the conversion can hold.  */
+
+static bool
+is_a_safe_conversion_stmt_p (gimple *def)
+{
+  if (!is_gimple_assign (def))
+return false;
+
+  tree lhs = gimple_assign_lhs (def);
+  if (!CONVERT_EXPR_CODE_P (gimple_assign_rhs_code (def))
+  || !INTEGRAL_TYPE_P (TREE_TYPE (lhs))
+  || !INTEGRAL_TYPE_P (TREE_TYPE (gimple_assign_rhs1 (def
+return false;
+
+  tree rhs1 = gimple_assign_rhs1 (def);
+  if (TYPE_PRECISION (TREE_TYPE (lhs))
+  >= TYPE_PRECISION (TREE_TYPE (rhs1)))
+return true;
+
+  value_range vr (TREE_TYPE (rhs1));
+  if (!get_range_query (cfun)->range_of_expr (vr, rhs1, def)
+  || vr.undefined_p ())
+return false;
+
+  irange &ir = as_a  (vr);
+  if (range_fits_type_p (&ir, TYPE_PRECISION (TREE_TYPE (lhs)),
+TYPE_SIGN (TREE_TYPE (lhs
+return true;
+
+  return false;
+}
+
+/* If T is an SSA_NAME that is the result of a simple type conversion statement
+   from an integer type to another integer type which is known to be able to
+   represent the values the operand of the conversion can hold, return the
+   operand of that conversion, otherwise return T.  */
+
+static tree
+skip_a_safe_conversion_op (tree t)
+{
+  if (TREE_CODE (t) != SSA_NAME
+  || SSA_NAME_IS_DEFAULT_DEF (t))
+return t;
+
+  gimple *def = SSA_NAME_DEF_STMT (t);
+  if (is_a_safe_conversion_stmt_p (def))
+return gimple_assign_rhs1 (def);
+  else
+return t;
+}
+
 /* Given an assignment statement STMT, try to collect information into
AGG_VALUE that will be used to construct jump function for RHS of the
assignment, from which content value of an aggregate part comes.
@@ -1913,8 +1966,18 @@ analyze_agg_content_value (struct ipa_func_body_info 
*fbi,
 return;
 
   /* Skip SSA copies.  */
-  while (gimple_assign_rhs_class (stmt) == GIMPLE_SINGLE_RHS)
+  bool skipped_conversion = false;
+  while (true)
 {
+  if (gimple_assign_rhs_class (stmt) != GIMPLE_SINGLE_RHS)
+   {
+ if (!skipped_conversion
+ && is_a_safe_conversion_stmt_p (stmt))
+   skipped_conversion = true;
+ else
+   break;
+   }
+
   if (TREE_CODE (rhs1) != SSA_NAME || SSA_NAME_IS_DEFAULT_DEF (rhs1))
break;
 
@@ -2360,43 +2423,6 @@ ipa_get_range_from_ip_invariant (vrange &r, tree val, 
cgraph_node *context_node)
 r.set (val, val);
 }
 
-/* If T is an SSA_NAME that is the result of a simple type conversion statement
-   from an integer type to another integer type which is known to be able to
-   represent the values the operand of the conversion can hold, return the
-   operand of that conversion, otherwise return T.  */
-
-static tree
-skip_a_safe_conversion_op (tree t)
-{
-  if (TREE_CODE (t) != SSA_NAME
-  || SSA_NAME_IS_DEFAULT_DEF (t))
-return t;
-
-  gimple *def = SSA_NAME_DEF_STMT (t);
-  if (!is_gimple_assign (def)
-  || !CONVERT_EXPR_CODE_P (gimple_assign_rhs_code (def))
-  || !INTEGRAL_TYPE_P (TREE_TYPE (t))
-  || !INTEGRAL_TYPE_P (TREE_TYPE (gimple_assign_rhs1 (def
-return t;
-
-  tree rhs1 = gimple_assign_rhs1 (def);
-  if (TYPE_PRECISION (TREE_TYPE (t))
-  >= TYPE_PRECISION (TREE_TYPE (rhs1)))
-return gimple_assign_rhs1 (def);
-
-  value_range vr (TREE_TYPE (rhs1));
-  if (!get_range_query (cfun)->range_of_expr (vr, rhs1, def)
-  || vr.undefined_p ())
-

[COMMITTED 06/35] gccrs: dump: Handle let-else properly

[arthur . cohen]

From: Arthur Cohen 

gcc/rust/ChangeLog:

* ast/rust-ast-collector.cc (TokenCollector::visit): Add handling for 
diverging else
expression.
---
 gcc/rust/ast/rust-ast-collector.cc | 8 
 1 file changed, 8 insertions(+)

diff --git a/gcc/rust/ast/rust-ast-collector.cc 
b/gcc/rust/ast/rust-ast-collector.cc
index 073fa728dcf..3297407e6e8 100644
--- a/gcc/rust/ast/rust-ast-collector.cc
+++ b/gcc/rust/ast/rust-ast-collector.cc
@@ -22,6 +22,7 @@
 #include "rust-expr.h"
 #include "rust-item.h"
 #include "rust-keyword-values.h"
+#include "rust-location.h"
 #include "rust-path.h"
 #include "rust-system.h"
 #include "rust-token.h"
@@ -2587,6 +2588,13 @@ TokenCollector::visit (LetStmt &stmt)
   push (Rust::Token::make (EQUAL, UNDEF_LOCATION));
   visit (stmt.get_init_expr ());
 }
+
+  if (stmt.has_else_expr ())
+{
+  push (Rust::Token::make (ELSE, UNDEF_LOCATION));
+  visit (stmt.get_else_expr ());
+}
+
   push (Rust::Token::make (SEMICOLON, UNDEF_LOCATION));
 }
 
-- 
2.49.0

[PATCH 5/7] ipa-cp: Use the collected pass-through types to propagate constants (PR118097)

[Martin Jambor]

This patch revisits the fix for PR 118097 and instead of deducing the
necessary operation type it just uses the value collected and streamed
by an earlier patch.

It is bigger than the ones for propagating value ranges and known bits
because we track constants both in parameters themselves and also in
memory they point to or within aggregates, we clone functions for them
and we do fancy things for some types of recursive calls.

In the case of constants in aggregates or passed by reference, the
situation should not change because the code creating jump functions
for them does not allow type-casts, unlike for the plain ones.
However, this patch changes how we handle them for the sake of
consistency and also so that we can try and eliminate this limitation
in the next stage 1.

Bootstrapped and tested and LTO bootstrapped on x86_64-linux. OK for
master?

Thanks,

Martin


gcc/ChangeLog:

2025-03-20  Martin Jambor  

PR ipa/118097
* ipa-cp.cc (ipa_get_jf_arith_result): Require res_operand for
anything except NOP_EXPR or ADDR_EXPR, document it and remove the code
trying to deduce it.
(ipa_value_from_jfunc): Use the stored and streamed type of arithmetic
pass-through functions.
(ipa_agg_value_from_jfunc): Use the stored and streamed type of
arithmetic pass-through functions, convert to the type used to store
the value if necessary.
(get_val_across_arith_op): New parameter op_type, pass it to
ipa_get_jf_arith_result.
(propagate_vals_across_arith_jfunc): New parameter op_type, pass it to
get_val_across_arith_op.
(propagate_vals_across_pass_through): Use the stored and streamed type
of arithmetic pass-through functions.
(propagate_aggregate_lattice): Likewise.
(push_agg_values_for_index_from_edge): Use the stored and streamed
type of arithmetic pass-through functions, convert to the type used to
store the value if necessary.
---
 gcc/ipa-cp.cc | 94 ---
 1 file changed, 52 insertions(+), 42 deletions(-)

diff --git a/gcc/ipa-cp.cc b/gcc/ipa-cp.cc
index e39a9e144ad..7aa17d083d3 100644
--- a/gcc/ipa-cp.cc
+++ b/gcc/ipa-cp.cc
@@ -1478,10 +1478,12 @@ ipacp_value_safe_for_type (tree param_type, tree value)
 return NULL_TREE;
 }
 
-/* Return the result of a (possibly arithmetic) operation on the constant value
-   INPUT.  OPERAND is 2nd operand for binary operation.  RES_TYPE is the type
-   in which any operation is to be performed.  Return NULL_TREE if that cannot
-   be determined or be considered an interprocedural invariant.  */
+/* Return the result of a (possibly arithmetic) operation determined by OPCODE
+   on the constant value INPUT.  OPERAND is 2nd operand for binary operation
+   and is required for binary operations.  RES_TYPE, required when opcode is
+   not NOP_EXPR, is the type in which any operation is to be performed.  Return
+   NULL_TREE if that cannot be determined or be considered an interprocedural
+   invariant.  */
 
 static tree
 ipa_get_jf_arith_result (enum tree_code opcode, tree input, tree operand,
@@ -1502,16 +1504,6 @@ ipa_get_jf_arith_result (enum tree_code opcode, tree 
input, tree operand,
return NULL_TREE;
 }
 
-  if (!res_type)
-{
-  if (TREE_CODE_CLASS (opcode) == tcc_comparison)
-   res_type = boolean_type_node;
-  else if (expr_type_first_operand_type_p (opcode))
-   res_type = TREE_TYPE (input);
-  else
-   return NULL_TREE;
-}
-
   if (TREE_CODE_CLASS (opcode) == tcc_unary)
 res = fold_unary (opcode, res_type, input);
   else
@@ -1595,7 +1587,10 @@ ipa_value_from_jfunc (class ipa_node_params *info, 
struct ipa_jump_func *jfunc,
return NULL_TREE;
  enum tree_code opcode = ipa_get_jf_pass_through_operation (jfunc);
  tree op2 = ipa_get_jf_pass_through_operand (jfunc);
- tree cstval = ipa_get_jf_arith_result (opcode, input, op2, NULL_TREE);
+ tree op_type
+   = (opcode == NOP_EXPR) ? NULL_TREE
+   : ipa_get_jf_pass_through_op_type (jfunc);
+ tree cstval = ipa_get_jf_arith_result (opcode, input, op2, op_type);
  return ipacp_value_safe_for_type (parm_type, cstval);
}
   else
@@ -1905,10 +1900,11 @@ ipa_agg_value_from_jfunc (ipa_node_params *info, 
cgraph_node *node,
return NULL_TREE;
 }
 
-  return ipa_get_jf_arith_result (item->value.pass_through.operation,
- value,
- item->value.pass_through.operand,
- item->type);
+  tree cstval = ipa_get_jf_arith_result (item->value.pass_through.operation,
+value,
+item->value.pass_through.operand,
+item->value.pass_through.op_type);
+  return ipacp_value_safe_for_type (item->type, cstval

[PATCH 3/7] ipa-cp: Make dumping of widest_ints even more sane

[Martin Jambor]

This patch just introduces a form of dumping of widest ints that only
have zeros in the lowest 128 bits so that instead of printing
thousands of f's the output looks like:

   Bits: value = 0x, mask = all ones folled by 
0x

and then makes sure we use the function not only to print bits but
also to print masks where values like these can also occur.

Bootstrapped and tested and LTO bootstrapped on x86_64-linux. OK for
master?

Thanks,

Martin


gcc/ChangeLog:

2025-03-21  Martin Jambor  

* ipa-cp.cc (ipcp_print_widest_int): Also add a truncated form of
dumping of widest ints which only have zeros in the lowest 128 bits.
Update the comment.
(ipcp_bits_lattice::print): Also dump the mask using
ipcp_print_widest_int.
(ipcp_store_vr_results): Likewise.
---
 gcc/ipa-cp.cc | 15 +++
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/gcc/ipa-cp.cc b/gcc/ipa-cp.cc
index cdedbaaf859..d81cda9b9ba 100644
--- a/gcc/ipa-cp.cc
+++ b/gcc/ipa-cp.cc
@@ -307,14 +307,21 @@ ipcp_lattice::print (FILE * f, bool 
dump_sources, bool dump_benefits)
 fprintf (f, "\n");
 }
 
-/* If VALUE has all bits set to one, print "-1" to F, otherwise simply print it
-   hexadecimally to F. */
+/* Print VALUE to F in a form which in usual cases does not take thousands of
+   characters. */
 
 static void
 ipcp_print_widest_int (FILE *f, const widest_int &value)
 {
   if (wi::eq_p (wi::bit_not (value), 0))
 fprintf (f, "-1");
+  else if (wi::eq_p (wi::bit_not (wi::bit_or (value,
+ wi::sub (wi::lshift (1, 128),
+  1))), 0))
+{
+  fprintf (f, "all ones folled by ");
+  print_hex (wi::bit_and (value, wi::sub (wi::lshift (1, 128), 1)), f);
+}
   else
 print_hex (value, f);
 }
@@ -331,7 +338,7 @@ ipcp_bits_lattice::print (FILE *f)
   fprintf (f, " Bits: value = ");
   ipcp_print_widest_int (f, get_value ());
   fprintf (f, ", mask = ");
-  print_hex (get_mask (), f);
+  ipcp_print_widest_int (f, get_mask ());
   fprintf (f, "\n");
 }
 }
@@ -6448,7 +6455,7 @@ ipcp_store_vr_results (void)
  fprintf (dump_file, " param %i: value = ", i);
  ipcp_print_widest_int (dump_file, bits->get_value ());
  fprintf (dump_file, ", mask = ");
- print_hex (bits->get_mask (), dump_file);
+ ipcp_print_widest_int (dump_file, bits->get_mask ());
  fprintf (dump_file, "\n");
}
 }
-- 
2.48.1

[PATCH 0/7] Fix PRs 118097, 118785 and 119318 by storing and streaming operation type

[Martin Jambor]

Hi,

when looking at PR 119318 I have first written a simple fix along the
lines of the fix for PR 118097 and PR 118785, i.e. without storing the
type in which we perform the operation encoded in an arithmetic jump
function but relying on expr_type_first_operand_type_p instead.  It
however became clear that in order to avoid regressions, I had to add
POINTER_PLUS_EXPR into that predicate which is missing there.  This
patch is available as an attachment to bugzilla in comment #5 and is a
simple, slightly unclean but viable way to deal with he bug.

However, the need to fiddle with the predicate led me to re-evaluate
how I approached these bugs and this is what this patch series does.
The first patch collects, stores and streams the type of the operation
encoded in the jump function.  The following ones then fix PR 119318
using it and change fixes to PRs 118097 118785 using this known type
rather than relying on expr_type_first_operand_type_p.

The last two patches in the series are only meant as an RFC and I'd
like to commit them only in the next stage 1 as they then take the
approach one step further and allow for more propagation.

Martin


Martin Jambor (7):
  ipa: Record and stream result types of arithemetic jump functions
  ipa-cp: Make propagation of bits in IPA-CP aware of type conversions
(PR119318)
  ipa-cp: Make dumping of widest_ints even more sane
  ipa-cp: Use the stored and streamed pass-through types in ipa-vr
(PR118785)
  ipa-cp: Use the collected pass-through types to propgate constants
(PR118097)
  ipa: Remove  type checks in arithmetic pass-through jfunc construction
  ipa: Allow a type conversion in construction of aggregate jump
functions

 gcc/ipa-cp.cc   | 169 ++
 gcc/ipa-prop.cc | 176 ++--
 gcc/ipa-prop.h  |  15 +++
 gcc/testsuite/gcc.dg/ipa/pr119318.c |  38 ++
 4 files changed, 262 insertions(+), 136 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/ipa/pr119318.c

-- 
2.48.1

[PATCH 2/7] ipa-cp: Make propagation of bits in IPA-CP aware of type conversions (PR119318)

[Martin Jambor]

After the propagation of constants and value ranges, it turns out
that the propagation of known bits also needs to be made aware of any
intermediate types in which any arithmetic operations are made and
must limit its precision there.  This implements just that, using the
newly collected and streamed types of the operations involved.

Bootstrapped and tested and LTO bootstrapped on x86_64-linux. OK for
master?

Thanks,

Martin


gcc/ChangeLog:

2025-03-20  Martin Jambor  

PR ipa/119318
* ipa-cp.cc (ipcp_bits_lattice::meet_with_1): Set all mask bits
not covered by precision to one.
(ipcp_bits_lattice::meet_with): Likewise.
(propagate_bits_across_jump_function): Use the first operand type
rather than the final parameter one to perform meet with other
lattices.  Check the operation conforms with
expr_type_first_operand_type_p.
* tree.cc (expr_type_first_operand_type_p): Add POINTER_PLUS_EXPR.

gcc/testsuite/ChangeLog:

2025-03-18  Martin Jambor  

PR ipa/119318
* gcc.dg/ipa/pr119318.c: New test.
---
 gcc/ipa-cp.cc   | 32 
 gcc/testsuite/gcc.dg/ipa/pr119318.c | 38 +
 2 files changed, 65 insertions(+), 5 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/ipa/pr119318.c

diff --git a/gcc/ipa-cp.cc b/gcc/ipa-cp.cc
index 264568989a9..cdedbaaf859 100644
--- a/gcc/ipa-cp.cc
+++ b/gcc/ipa-cp.cc
@@ -918,6 +918,8 @@ ipcp_bits_lattice::meet_with_1 (widest_int value, 
widest_int mask,
 m_mask |= m_value;
   m_value &= ~m_mask;
 
+  widest_int cap_mask = wi::bit_not (wi::sub (wi::lshift (1, precision), 1));
+  m_mask |= cap_mask;
   if (wi::sext (m_mask, precision) == -1)
 return set_to_bottom ();
 
@@ -996,6 +998,8 @@ ipcp_bits_lattice::meet_with (ipcp_bits_lattice& other, 
unsigned precision,
  adjusted_mask |= adjusted_value;
  adjusted_value &= ~adjusted_mask;
}
+  widest_int cap_mask = wi::bit_not (wi::sub (wi::lshift (1, precision), 
1));
+  adjusted_mask |= cap_mask;
   if (wi::sext (adjusted_mask, precision) == -1)
return set_to_bottom ();
   return set_to_constant (adjusted_value, adjusted_mask);
@@ -2507,14 +2511,12 @@ propagate_bits_across_jump_function (cgraph_edge *cs, 
int idx,
   return dest_lattice->set_to_bottom ();
 }
 
-  unsigned precision = TYPE_PRECISION (parm_type);
-  signop sgn = TYPE_SIGN (parm_type);
-
   if (jfunc->type == IPA_JF_PASS_THROUGH
   || jfunc->type == IPA_JF_ANCESTOR)
 {
   ipa_node_params *caller_info = ipa_node_params_sum->get (cs->caller);
   tree operand = NULL_TREE;
+  tree op_type = NULL_TREE;
   enum tree_code code;
   unsigned src_idx;
   bool keep_null = false;
@@ -2524,7 +2526,10 @@ propagate_bits_across_jump_function (cgraph_edge *cs, 
int idx,
  code = ipa_get_jf_pass_through_operation (jfunc);
  src_idx = ipa_get_jf_pass_through_formal_id (jfunc);
  if (code != NOP_EXPR)
-   operand = ipa_get_jf_pass_through_operand (jfunc);
+   {
+ operand = ipa_get_jf_pass_through_operand (jfunc);
+ op_type = ipa_get_jf_pass_through_op_type (jfunc);
+   }
}
   else
{
@@ -2551,6 +2556,22 @@ propagate_bits_across_jump_function (cgraph_edge *cs, 
int idx,
 
   if (!src_lats->bits_lattice.bottom_p ())
{
+ if (!op_type)
+   {
+ op_type = ipa_get_type (caller_info, src_idx);
+ if (!op_type)
+   {
+ if (dump_file && (dump_flags & TDF_DETAILS))
+   fprintf (dump_file, "Setting dest_lattice to bottom, "
+"because the operation involved in computing "
+"param %i of %s is in an unknown type.\n",
+idx, cs->callee->dump_name ());
+ return dest_lattice->set_to_bottom ();
+   }
+   }
+
+ unsigned precision = TYPE_PRECISION (op_type);
+ signop sgn = TYPE_SIGN (op_type);
  bool drop_all_ones
= keep_null && !src_lats->bits_lattice.known_nonzero_p ();
 
@@ -2570,7 +2591,8 @@ propagate_bits_across_jump_function (cgraph_edge *cs, int 
idx,
= widest_int::from (bm.mask (), TYPE_SIGN (parm_type));
  widest_int value
= widest_int::from (bm.value (), TYPE_SIGN (parm_type));
- return dest_lattice->meet_with (value, mask, precision);
+ return dest_lattice->meet_with (value, mask,
+ TYPE_PRECISION (parm_type));
}
 }
   return dest_lattice->set_to_bottom ();
diff --git a/gcc/testsuite/gcc.dg/ipa/pr119318.c 
b/gcc/testsuite/gcc.dg/ipa/pr119318.c
new file mode 100644
index 000..8e62ec5e350
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/ipa/pr119318.c
@@ -0,0 +1,38 @@
+/* { dg-do run } */
+/* { dg-require-effective-target in

[PATCH 1/7] ipa: Record and stream result types of arithemetic jump functions

[Martin Jambor]

In order to replace the use of somewhat unweildy
expr_type_first_operand_type_p we need to record and stream the types
of results of operations recorded in arithmetic jump functions.  This
is necessary so that we can then simulate them at the IPA stage with
the corresponding precision and signedness.  This patch does the
recorsing and streaming, the following one adds the use of the date.

Bootstrapped and tested and LTO bootstrapped on x86_64-linux. OK for
master?

Thanks,

Martin


gcc/ChangeLog:

2025-03-20  Martin Jambor  

PR ipa/118097
PR ipa/118785
PR ipa/119318
* ipa-prop.h (ipa_pass_through_data): New field op_type.
(ipa_get_jf_pass_through_op_type): New function.
* ipa-prop.cc (ipa_dump_jump_function): Dump also pass-through
operation types, if any.  Dump pass-through operands only if not NULL.
(ipa_set_jf_simple_pass_through): Set op_type accordingly.
(compute_complex_assign_jump_func): Set op_type of arithmetic
pass-through jump_functions.
(analyze_agg_content_value): Update lhs when walking assighment
copies.  Set op_type of aggregate arithmetic pass-through
jump_functions.
(update_jump_functions_after_inlining): Also transfer the operation
type from the source arithmentic pass-through jump function to the
destination jump function.
(ipa_write_jump_function): Stream also the op_type when necessary.
(ipa_read_jump_function): Likewise.
(ipa_agg_pass_through_jf_equivalent_p): Also compare operation types.
---
 gcc/ipa-prop.cc | 63 -
 gcc/ipa-prop.h  | 15 
 2 files changed, 67 insertions(+), 11 deletions(-)

diff --git a/gcc/ipa-prop.cc b/gcc/ipa-prop.cc
index a120f942dc2..d882b997bf4 100644
--- a/gcc/ipa-prop.cc
+++ b/gcc/ipa-prop.cc
@@ -454,7 +454,11 @@ ipa_dump_jump_function (FILE *f, ipa_jump_func *jump_func,
   if (jump_func->value.pass_through.operation != NOP_EXPR)
{
  fprintf (f, " ");
- print_generic_expr (f, jump_func->value.pass_through.operand);
+ if (jump_func->value.pass_through.operand)
+   print_generic_expr (f, jump_func->value.pass_through.operand);
+ fprintf (f, " (in type ");
+ print_generic_expr (f, jump_func->value.pass_through.op_type);
+ fprintf (f, ")");
}
   if (jump_func->value.pass_through.agg_preserved)
fprintf (f, ", agg_preserved");
@@ -510,7 +514,11 @@ ipa_dump_jump_function (FILE *f, ipa_jump_func *jump_func,
  if (item->value.pass_through.operation != NOP_EXPR)
{
  fprintf (f, " ");
- print_generic_expr (f, item->value.pass_through.operand);
+ if (item->value.pass_through.operand)
+   print_generic_expr (f, item->value.pass_through.operand);
+ fprintf (f, " (in type ");
+ print_generic_expr (f, jump_func->value.pass_through.op_type);
+ fprintf (f, ")");
}
}
  else if (item->jftype == IPA_JF_CONST)
@@ -682,6 +690,7 @@ ipa_set_jf_simple_pass_through (struct ipa_jump_func 
*jfunc, int formal_id,
 {
   jfunc->type = IPA_JF_PASS_THROUGH;
   jfunc->value.pass_through.operand = NULL_TREE;
+  jfunc->value.pass_through.op_type = NULL_TREE;
   jfunc->value.pass_through.formal_id = formal_id;
   jfunc->value.pass_through.operation = NOP_EXPR;
   jfunc->value.pass_through.agg_preserved = agg_preserved;
@@ -692,10 +701,11 @@ ipa_set_jf_simple_pass_through (struct ipa_jump_func 
*jfunc, int formal_id,
 
 static void
 ipa_set_jf_unary_pass_through (struct ipa_jump_func *jfunc, int formal_id,
-  enum tree_code operation)
+  enum tree_code operation, tree op_type)
 {
   jfunc->type = IPA_JF_PASS_THROUGH;
   jfunc->value.pass_through.operand = NULL_TREE;
+  jfunc->value.pass_through.op_type = op_type;
   jfunc->value.pass_through.formal_id = formal_id;
   jfunc->value.pass_through.operation = operation;
   jfunc->value.pass_through.agg_preserved = false;
@@ -705,10 +715,12 @@ ipa_set_jf_unary_pass_through (struct ipa_jump_func 
*jfunc, int formal_id,
 
 static void
 ipa_set_jf_arith_pass_through (struct ipa_jump_func *jfunc, int formal_id,
-  tree operand, enum tree_code operation)
+  tree operand, enum tree_code operation,
+  tree op_type)
 {
   jfunc->type = IPA_JF_PASS_THROUGH;
   jfunc->value.pass_through.operand = unshare_expr_without_location (operand);
+  jfunc->value.pass_through.op_type = op_type;
   jfunc->value.pass_through.formal_id = formal_id;
   jfunc->value.pass_through.operation = operation;
   jfunc->value.pass_through.agg_preserved = false;
@@ -1526,7 +1538,8 @@ compute_complex_assign_jump_func (struct 
ipa_func_body_info *fbi,
  return;
 
   

[PATCH] LoongArch: doc: Put the '-mtls-dialect=opt' option description in the correct position.

[Lulu Cheng]

gcc/ChangeLog:

* doc/invoke.texi: Corrected the position of '-mtls-dialect=opt'
option.

---
 gcc/doc/invoke.texi | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index df461090824..ecc5f61f29c 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -28009,6 +28009,14 @@ build with @option{-march=la664}, it is enabled by 
default.  The default is
 This option controls which tls dialect may be used for general dynamic and
 local dynamic TLS models.
 
+@table @samp
+@item trad
+Use traditional TLS. This is the default.
+
+@item desc
+Use TLS descriptors.
+@end table
+
 @opindex mannotate-tablejump
 @opindex mno-annotate-tablejump
 @item -mannotate-tablejump
@@ -28020,14 +28028,6 @@ tools, for example @file{objtool} of the Linux kernel 
building system,
 need the annotation to analysis the control flow.  The default is
 @option{-mno-annotate-tablejump}.
 
-@table @samp
-@item trad
-Use traditional TLS. This is the default.
-
-@item desc
-Use TLS descriptors.
-@end table
-
 @item --param loongarch-vect-unroll-limit=@var{n}
 The vectorizer will use available tuning information to determine whether it
 would be beneficial to unroll the main vectorized loop and by how much.  This
-- 
2.34.1

[PATCH] target/119549 - fixup handling of -mno-sse4

[Richard Biener]

The following fixes ix86_handle_option to properly handle -mno-sse4
which is always handled as -msse4 with value unset.  I've verified
no other OPT_mno_* is left around.

Bootstrap and regtest running on x86_64-unknown-linux-gnu.

This error goes back quite some time, I'm not sure how prevalent
the use of -mno-sse4 is.  In fact I have no idea why we have
OPT_mno_sse4 at all...

Hmm:

msse4
Target RejectNegative Mask(ISA_SSE4_2) Var(ix86_isa_flags) Save
Support MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1 and SSE4.2 built-in functions 
and code generation.

mno-sse4
Target RejectNegative InverseMask(ISA_SSE4_1) Var(ix86_isa_flags) Save
Do not support SSE4.1 and SSE4.2 built-in functions and code generation.

but we end up building

$3 = {opt_index = 2231, warn_message = 0x0, arg = 0x0, 
  orig_option_with_args_text = 0x440d108 "-msse4", canonical_option = {
0x440d108 "-msse4", 0x0, 0x0, 0x0}, canonical_option_num_elements = 1, 
  value = 0, mask = 0, errors = 0}

from -mno-sse4 in target("") via ix86_valid_target_attribute_inner_p.

OK?  Any clarification on what the above is about?

Richard.

PR target/119549
* common/config/i386/i386-common.cc (ix86_handle_option):
Handle OPT_mno_sse4 via OPT_msse4 and looking at value.

* gcc.target/i386/pr119549.c: New testcase.
---
 gcc/common/config/i386/i386-common.cc| 21 -
 gcc/testsuite/gcc.target/i386/pr119549.c | 15 +++
 2 files changed, 27 insertions(+), 9 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/i386/pr119549.c

diff --git a/gcc/common/config/i386/i386-common.cc 
b/gcc/common/config/i386/i386-common.cc
index 80aec3244bc..296df3b3230 100644
--- a/gcc/common/config/i386/i386-common.cc
+++ b/gcc/common/config/i386/i386-common.cc
@@ -1519,15 +1519,18 @@ ix86_handle_option (struct gcc_options *opts,
   return true;
 
 case OPT_msse4:
-  opts->x_ix86_isa_flags |= OPTION_MASK_ISA_SSE4_SET;
-  opts->x_ix86_isa_flags_explicit |= OPTION_MASK_ISA_SSE4_SET;
-  return true;
-
-case OPT_mno_sse4:
-  opts->x_ix86_isa_flags &= ~OPTION_MASK_ISA_SSE4_UNSET;
-  opts->x_ix86_isa_flags_explicit |= OPTION_MASK_ISA_SSE4_UNSET;
-  opts->x_ix86_isa_flags2 &= ~OPTION_MASK_ISA2_SSE4_UNSET;
-  opts->x_ix86_isa_flags2_explicit |= OPTION_MASK_ISA2_SSE4_UNSET;
+  if (value)
+   {
+ opts->x_ix86_isa_flags |= OPTION_MASK_ISA_SSE4_SET;
+ opts->x_ix86_isa_flags_explicit |= OPTION_MASK_ISA_SSE4_SET;
+   }
+  else
+   {
+ opts->x_ix86_isa_flags &= ~OPTION_MASK_ISA_SSE4_UNSET;
+ opts->x_ix86_isa_flags_explicit |= OPTION_MASK_ISA_SSE4_UNSET;
+ opts->x_ix86_isa_flags2 &= ~OPTION_MASK_ISA2_SSE4_UNSET;
+ opts->x_ix86_isa_flags2_explicit |= OPTION_MASK_ISA2_SSE4_UNSET;
+   }
   return true;
 
 case OPT_msse4a:
diff --git a/gcc/testsuite/gcc.target/i386/pr119549.c 
b/gcc/testsuite/gcc.target/i386/pr119549.c
new file mode 100644
index 000..a465bec3cf0
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr119549.c
@@ -0,0 +1,15 @@
+/* { dg-do compile } */
+/* { dg-options "-msse4" } */
+
+typedef long long v2di __attribute__((vector_size(16)));
+
+static inline __attribute__((always_inline))
+int rte_trace_feature_is_enabled() { return 1; } /* { dg-error "inlining 
failed" } */
+
+void __attribute__((target ("no-sse3"))) __attribute__((target ("no-sse4")))
+rte_eal_trace_generic_void_init(void)
+{
+  if (!rte_trace_feature_is_enabled()) return;
+  __asm__ volatile ("" : : : "memory");
+}
+
-- 
2.43.0

[PATCH] sra: Clear grp_same_access_path of acesses created by total scalarization (PR118924)

[Martin Jambor]

Hi,

during analysis of PR 118924 it was discussed that total scalarization
invents access paths (strings of COMPONENT_REFs and possibly even
ARRAY_REFs) which did not exist in the program before which can have
unintended effects on subsequent AA queries.  Although not doing that
does not mean that SRA cannot create such situations (see the bug for
more info), it has been agreed that not doing this is generally better.
This patch therfore makes SRA fall back on creating simple MEM_REFs when
accessing components of an aggregate corresponding to what a SRA
variable now represents.

Bootstrapped on x86_64-linux and Aarch64-linux.  OK for master and then
for all active release branches?

Thanks,

Martin


gcc/ChangeLog:

2025-03-26  Martin Jambor  

PR tree-optimization/118924
* tree-sra.cc (create_total_scalarization_access): Set
grp_same_access_path flag to zero.
---
 gcc/tree-sra.cc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/tree-sra.cc b/gcc/tree-sra.cc
index 22d5d1ce999..8014bf1e6b4 100644
--- a/gcc/tree-sra.cc
+++ b/gcc/tree-sra.cc
@@ -3463,7 +3463,7 @@ create_total_scalarization_access (struct access *parent, 
HOST_WIDE_INT pos,
   access->grp_write = parent->grp_write;
   access->grp_total_scalarization = 1;
   access->grp_hint = 1;
-  access->grp_same_access_path = path_comparable_for_same_access (expr);
+  access->grp_same_access_path = 0;
   access->reverse = reverse_storage_order_for_component_p (expr);
 
   access->next_sibling = next_sibling;
-- 
2.48.1

Re: [PATCH] target/119549 - fixup handling of -mno-sse4

[Jakub Jelinek]

On Mon, Mar 31, 2025 at 03:33:34PM +0200, Richard Biener wrote:
> On Mon, 31 Mar 2025, Jakub Jelinek wrote:
> 
> > On Mon, Mar 31, 2025 at 03:12:56PM +0200, Richard Biener wrote:
> > > The following fixes ix86_handle_option to properly handle -mno-sse4
> > > which is always handled as -msse4 with value unset.  I've verified
> > > no other OPT_mno_* is left around.
> > > 
> > > Bootstrap and regtest running on x86_64-unknown-linux-gnu.
> > > 
> > > This error goes back quite some time, I'm not sure how prevalent
> > > the use of -mno-sse4 is.  In fact I have no idea why we have
> > > OPT_mno_sse4 at all...
> > 
> > That is because SSE4 is SSE4.1 + SSE4.2.
> > So for -msse4 we want it to act as -msse4.2 and for -mno-sse4
> > to act as -mno-sse4.1
> 
> Yes, but it seems ix86_handle_option handles this via
> OPTION_MASK_ISA_SSE4_SET vs. ~OPTION_MASK_ISA_SSE4_UNSET.  So the
> question is what the -mno-sse4 options entry does.  I'll note

But
i386-common.cc:#define OPTION_MASK_ISA_SSE4_SET OPTION_MASK_ISA_SSE4_2_SET
i386-common.cc:#define OPTION_MASK_ISA_SSE4_UNSET OPTION_MASK_ISA_SSE4_1_UNSET
i386-common.cc:#define OPTION_MASK_ISA2_SSE4_UNSET OPTION_MASK_ISA2_SSE4_1_UNSET
which is exactly what it wants.

> that ix86_handle_option also unsets flags in ix86_isa_flags2
> with -mno-sse4 but the mno-sse4 options entry does not indicate
> that.

It does, that is the
  opts->x_ix86_isa_flags2 &= ~OPTION_MASK_ISA2_SSE4_UNSET;
  opts->x_ix86_isa_flags2_explicit |= OPTION_MASK_ISA2_SSE4_UNSET;
There is no OPTION_MASK_ISA2_SSE4_SET (like there is no
OPTION_MASK_ISA2_SSE{,[234],4_{1,2}}_SET, that isn't needed because
all the requirements of SSE4 still fit into ix86_isa_flags.

Jakub

Re: [PATCH] target/119549 - fixup handling of -mno-sse4

[Richard Biener]

On Mon, 31 Mar 2025, Jakub Jelinek wrote:

> On Mon, Mar 31, 2025 at 03:33:34PM +0200, Richard Biener wrote:
> > On Mon, 31 Mar 2025, Jakub Jelinek wrote:
> > 
> > > On Mon, Mar 31, 2025 at 03:12:56PM +0200, Richard Biener wrote:
> > > > The following fixes ix86_handle_option to properly handle -mno-sse4
> > > > which is always handled as -msse4 with value unset.  I've verified
> > > > no other OPT_mno_* is left around.
> > > > 
> > > > Bootstrap and regtest running on x86_64-unknown-linux-gnu.
> > > > 
> > > > This error goes back quite some time, I'm not sure how prevalent
> > > > the use of -mno-sse4 is.  In fact I have no idea why we have
> > > > OPT_mno_sse4 at all...
> > > 
> > > That is because SSE4 is SSE4.1 + SSE4.2.
> > > So for -msse4 we want it to act as -msse4.2 and for -mno-sse4
> > > to act as -mno-sse4.1
> > 
> > Yes, but it seems ix86_handle_option handles this via
> > OPTION_MASK_ISA_SSE4_SET vs. ~OPTION_MASK_ISA_SSE4_UNSET.  So the
> > question is what the -mno-sse4 options entry does.  I'll note
> 
> But
> i386-common.cc:#define OPTION_MASK_ISA_SSE4_SET OPTION_MASK_ISA_SSE4_2_SET
> i386-common.cc:#define OPTION_MASK_ISA_SSE4_UNSET OPTION_MASK_ISA_SSE4_1_UNSET
> i386-common.cc:#define OPTION_MASK_ISA2_SSE4_UNSET 
> OPTION_MASK_ISA2_SSE4_1_UNSET
> which is exactly what it wants.
> 
> > that ix86_handle_option also unsets flags in ix86_isa_flags2
> > with -mno-sse4 but the mno-sse4 options entry does not indicate
> > that.
> 
> It does, that is the
>   opts->x_ix86_isa_flags2 &= ~OPTION_MASK_ISA2_SSE4_UNSET;
>   opts->x_ix86_isa_flags2_explicit |= OPTION_MASK_ISA2_SSE4_UNSET;
> There is no OPTION_MASK_ISA2_SSE4_SET (like there is no
> OPTION_MASK_ISA2_SSE{,[234],4_{1,2}}_SET, that isn't needed because
> all the requirements of SSE4 still fit into ix86_isa_flags.

Yes, all I say is that ix86_handle_option looks OK, I'm not sure
why we need the

mno-sse4
Target RejectNegative InverseMask(ISA_SSE4_1) Var(ix86_isa_flags) Save
Do not support SSE4.1 and SSE4.2 built-in functions and code generation.

options entry.  Or whether that means ix86_valid_target_attribute_inner_p
should have created OPT_mno_sse4 from -mno-sse4.  At least, having
both i386.opt entries looks like unnecessary complication to me.

And maybe I broke -mno-sse4 on the command-line with my change.  Indeed

> ./xgcc -B. t.c -mno-sse4

hits the code with OPT_mno_sse4.  I'll update the patch to leave
the old OPT_mno_sse4 handling in place.  The other option is
to fixup ix86_valid_target_attribute_inner_p to when finding
-mno-sse4 to exactly special case that and use OPT_mno_sse4?

Again, I don't really understand why it was done in this complicated
way.  At least there seems to be some test coverage.

Richard.

[committed] arm: testsuite: fix vect-fmaxmin.c test

[Richard Earnshaw]

This is another case of a test that was both an executable test
requiring specific hardware and an assembler scan test.  The
requirement for the hardware was masking some useful testing that
could be done (by scanning the assembly output) on almost all test
runs.  Fixed in a similar manner to fmaxmin{,-2}.c by splitting the
test into two, one that scans the assembler output and one that
executes the compiled code if suitable hardware is available.

The masked issue was that this test was expecting vectorization to
occur that was incorrect given the options passed.  For correct
vectorization we need -funsafe-math-optimizations as the vector
version of the single-precision operation will apply a truncation of
denormal values.

gcc/testsuite/ChangeLog:

* gcc.target/arm/vect-fmaxmin-2.c: New compile test.  Split from ...
* gcc.target/arm/vect-fmaxmin.c: ... here.  Remove scan-assembler
subtests.  For both, add -funsafe-math-optimizations.
---
 gcc/testsuite/gcc.target/arm/vect-fmaxmin-2.c | 14 ++
 gcc/testsuite/gcc.target/arm/vect-fmaxmin.c   | 10 +-
 2 files changed, 15 insertions(+), 9 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/arm/vect-fmaxmin-2.c

diff --git a/gcc/testsuite/gcc.target/arm/vect-fmaxmin-2.c 
b/gcc/testsuite/gcc.target/arm/vect-fmaxmin-2.c
new file mode 100644
index 000..57b0a3ad801
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/vect-fmaxmin-2.c
@@ -0,0 +1,14 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target arm_arch_v8a_hard_ok } */
+/* { dg-options "-O2 -ftree-vectorize -funsafe-math-optimizations -fno-inline 
-save-temps" } */
+/* { dg-add-options arm_arch_v8a_hard } */
+
+#include "fmaxmin.x"
+
+/* { dg-final { scan-assembler-times "vmaxnm.f32\tq\[0-9\]+, q\[0-9\]+, 
q\[0-9\]+" 1 } } */
+/* { dg-final { scan-assembler-times "vminnm.f32\tq\[0-9\]+, q\[0-9\]+, 
q\[0-9\]+" 1 } } */
+
+/* NOTE: There are no double precision vector versions of vmaxnm/vminnm.  */
+/* { dg-final { scan-assembler-times "vmaxnm.f64\td\[0-9\]+, d\[0-9\]+, 
d\[0-9\]+" 1 } } */
+/* { dg-final { scan-assembler-times "vminnm.f64\td\[0-9\]+, d\[0-9\]+, 
d\[0-9\]+" 1 } } */
+
diff --git a/gcc/testsuite/gcc.target/arm/vect-fmaxmin.c 
b/gcc/testsuite/gcc.target/arm/vect-fmaxmin.c
index ba45c4d379e..89dc14bd594 100644
--- a/gcc/testsuite/gcc.target/arm/vect-fmaxmin.c
+++ b/gcc/testsuite/gcc.target/arm/vect-fmaxmin.c
@@ -1,14 +1,6 @@
 /* { dg-do run } */
 /* { dg-require-effective-target arm_v8_neon_hw } */
-/* { dg-options "-O2 -ftree-vectorize -fno-inline -march=armv8-a -save-temps" 
} */
+/* { dg-options "-O2 -ftree-vectorize -fno-inline -funsafe-math-optimizations" 
} */
 /* { dg-add-options arm_v8_neon } */
 
 #include "fmaxmin.x"
-
-/* { dg-final { scan-assembler-times "vmaxnm.f32\tq\[0-9\]+, q\[0-9\]+, 
q\[0-9\]+" 1 } } */
-/* { dg-final { scan-assembler-times "vminnm.f32\tq\[0-9\]+, q\[0-9\]+, 
q\[0-9\]+" 1 } } */
-
-/* NOTE: There are no double precision vector versions of vmaxnm/vminnm.  */
-/* { dg-final { scan-assembler-times "vmaxnm.f64\td\[0-9\]+, d\[0-9\]+, 
d\[0-9\]+" 1 } } */
-/* { dg-final { scan-assembler-times "vminnm.f64\td\[0-9\]+, d\[0-9\]+, 
d\[0-9\]+" 1 } } */
-
-- 
2.34.1

Re: [PATCH] libstdc++: Make operator== for std::tuple convert to bool [PR119545]

[Tomasz Kaminski]

On Mon, Mar 31, 2025 at 3:03 PM Jonathan Wakely  wrote:

> The boolean-testable requirements don't require the type to be copyable,
> so we need to convert to bool before it might need to be copied.
>
> libstdc++-v3/ChangeLog:
>
> PR libstdc++/119545
> * include/std/tuple (operator==): Convert comparison results to
> bool.
> * testsuite/20_util/tuple/comparison_operators/119545.cc: New
> test.
> ---
>
> Tested x86_64-linux.
>
LGTM.

>
> For the recent r15-7897-ge6e7b477bbdbfb change to fix a similar problem
> I used an explicit return type on the lambda, because that was what the
> LWG issue said to do. In this case an explicit return type would also
> work, but I used an explicit conversion to bool on each element of the
> pack expansion instead.

boolean-testable requirements allows you to do that: a && b on
boolean-testable a, bis
required to have the same behavior bool(a) && bool(b), so all good.


> That matches what is done elsewhere in 
> for the tuple-like equality comparison, so I preferred to be locally
> consistent.
>
We also are no longer triggering lookup for opeartor&& on boolean-testable,
which is required to find nothing, but still will be performed. So I think
converting
to bool before applying &&/|| on boolean-testable is good idea.

>
>  libstdc++-v3/include/std/tuple|  2 +-
>  .../tuple/comparison_operators/119545.cc  | 24 +++
>  2 files changed, 25 insertions(+), 1 deletion(-)
>  create mode 100644
> libstdc++-v3/testsuite/20_util/tuple/comparison_operators/119545.cc
>
> diff --git a/libstdc++-v3/include/std/tuple
> b/libstdc++-v3/include/std/tuple
> index d3deb7bc124..2e69af13a98 100644
> --- a/libstdc++-v3/include/std/tuple
> +++ b/libstdc++-v3/include/std/tuple
> @@ -2534,7 +2534,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>  {
>return [&](index_sequence<_Inds...>) {
> // Fold == over the tuples until non-equal elements are found.
> -   return ((std::get<_Inds>(__t) == std::get<_Inds>(__u)) && ...);
> +   return (bool(std::get<_Inds>(__t) == std::get<_Inds>(__u)) && ...);
>}(index_sequence_for<_Tps...>{});
>  }
>
> diff --git
> a/libstdc++-v3/testsuite/20_util/tuple/comparison_operators/119545.cc
> b/libstdc++-v3/testsuite/20_util/tuple/comparison_operators/119545.cc
> new file mode 100644
> index 000..3a65ef53b01
> --- /dev/null
> +++ b/libstdc++-v3/testsuite/20_util/tuple/comparison_operators/119545.cc
> @@ -0,0 +1,24 @@
> +// { dg-do compile { target c++11 } }
> +// Bug libstdc++/119545
> +// tuple::operator==()'s help lambda does not specify return type as bool
> +
> +#include 
> +
> +void
> +test_pr119545()
> +{
> +  struct Bool {
> +Bool() = default;
> +Bool(const Bool&) = delete;
> +operator bool() const { return true; }
> +  };
> +
> +  static Bool b;
> +
> +  struct Object {
> +const Bool& operator==(const Object&) const { return b; }
> +  };
> +
> +  std::tuple t;
> +  (void) (t == t);
> +}
> --
> 2.49.0
>
>

Re: [PATCH] PR middle-end/119442: expr.cc: Fix vec_duplicate into vector boolean modes

[Richard Biener]

On Mon, Mar 31, 2025 at 9:41 AM Richard Biener
 wrote:
>
> On Mon, Mar 31, 2025 at 9:36 AM Kyrylo Tkachov  wrote:
> >
> > Ping.
>
> Can you reference the patch please?  I'll note your mails have the tendency to
> end up in my spam folder (which is auto-purged after some time).  Probably
> a setup issue at nvidias side.

Found it.  Your mails fail both DKIM and DMARC so gmail thinks you are
phishing me.

Richard.

>
> Richard.
>
> > Thanks,
> > Kyrill
> >
> > > On 24 Mar 2025, at 14:28, Kyrylo Tkachov  wrote:
> > >
> > > Hi all,
> > >
> > > In this testcase GCC tries to expand a VNx4BI vector:
> > > vector(4)  _40;
> > > _39 = () _24;
> > > _40 = {_39, _39, _39, _39};
> > >
> > > This ends up in a scalarised sequence of bitfield insert operations.
> > > This is despite the fact that AArch64 provides a vec_duplicate pattern
> > > specifically for vec_duplicate into VNx4BI.
> > >
> > > The store_constructor code is overly conservative when trying 
> > > vec_duplicate
> > > as it sees a requested VNx4BImode and an element mode of QImode, which I 
> > > guess
> > > is the storage mode of BImode objects.
> > >
> > > The vec_duplicate expander in aarch64-sve.md explicitly allows QImode 
> > > element
> > > modes so it should be safe to use it. This patch extends that mode check
> > > to allow such expanders.
> > >
> > > The testcase is heavily auto-reduced from a real application but in 
> > > itself is
> > > nonsensical, but it does demonstrate the current problematic codegen.
> > >
> > > This the testcase goes from:
> > > pfalse p15.b
> > > str p15, [sp, #6, mul vl]
> > > mov w0, 0
> > > ldr w2, [sp, 12]
> > > bfi w2, w0, 0, 4
> > > uxtw x2, w2
> > > bfi w2, w0, 4, 4
> > > uxtw x2, w2
> > > bfi w2, w0, 8, 4
> > > uxtw x2, w2
> > > bfi w2, w0, 12, 4
> > > str w2, [sp, 12]
> > > ldr p15, [sp, #6, mul vl]
> > >
> > > into:
> > > whilelo p15.s, wzr, wzr
> > >
> > > The whilelo could be optimised away into a pfalse of course, but the 
> > > important
> > > part is that the bfis are gone.
> > >
> > > Bootstrapped and tested on aarch64-none-linux-gnu.
> > >
> > > Given this a regression from GCC 13 is this ok for trunk now?
> > > Thanks,
> > > Kyrill
> > >
> > > Signed-off-by: Kyrylo Tkachov 
> > >
> > > gcc/
> > >
> > > PR middle-end/119442
> > > * expr.cc (store_constructor): Also allow element modes explicitly
> > > accepted by target vec_duplicate pattern.
> > >
> > > gcc/testsuite/
> > >
> > > PR middle-end/119442
> > > * gcc.target/aarch64/vls_sve_vec_dup_1.c: New test.
> > >
> > > <0001-PR-middle-end-119442-expr.cc-Fix-vec_duplicate-into-.patch>
> >

Re: [PATCH] gcc_release: Generate srcdir extras/infos/man pages from all FEs [PR119510]

[Andreas Schwab]

On Mär 31 2025, Richard Biener wrote:

> Do we even install libffi.info?

We shouldn't.  It would conflict with the standalone libffi library, and
we don't install anything from the target libffi library anyway (it's
only used internally).

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: [PATCH] libstdc++: Constrain formatters for chrono types [PR119517]

[Tomasz Kaminski]

I checked, and it seems that we have thread::id and stacktrace related
formatters already use basic_format_parse_context and basic_format_context
as parameters.
So no changes needed there.

On Sat, Mar 29, 2025 at 9:41 PM Jonathan Wakely 
wrote:

> On Sat, 29 Mar 2025 at 18:16, Tomasz Kaminski  wrote:
> >
> >
> >
> > On Fri, Mar 28, 2025 at 9:33 PM Jonathan Wakely 
> wrote:
> >>
> >> On 28/03/25 16:31 +0100, Tomasz Kamiński wrote:
> >> >The formatters for chrono types defined the parse/format methods
> >> >as accepting unconstrained types, this in combination with lack
> >> >of constrain on _CharT lead to them falsy statisfying formattable
> >> >requirements for any type used as character.
> >> >
> >> >This patch adjust the fromatter::parse signature to:
> >> > constexpr typename basic_format_parse_context<_CharT>::iterator
> >> > parse(basic_format_parse_context<_CharT>& __pc);
> >> >And formatter::format to:
> >> > template
> >> >   typename basic_format_context<_Out, _CharT>::iterator
> >> >   format(const T& __t,
> >> >  basic_format_context<_Out, _CharT>& __fc) const;
> >> >
> >> >Furthermore we _CharT with __format::__char (char or wchar_t),
> >> >
> >> >   PR libstdc++/119517
> >> >
> >> >libstdc++-v3/ChangeLog:
> >> >
> >> >   * include/bits/chrono_io.h (formatter):
> >> >   Add __format::__char for _CharT and adjust parse and format
> >> >   method signatures.
> >> >   * testsuite/std/time/format/pr119517.cc: New test.
> >> >---
> >> >Testing on x86_64-linux, std/time/format tests passed.
> >> >OK for trunk?
> >> >
> >> > libstdc++-v3/include/bits/chrono_io.h | 448 +-
> >> > .../testsuite/std/time/format/pr119517.cc |  44 ++
> >> > 2 files changed, 262 insertions(+), 230 deletions(-)
> >> > create mode 100644 libstdc++-v3/testsuite/std/time/format/pr119517.cc
> >> >
> >> >diff --git a/libstdc++-v3/include/bits/chrono_io.h
> b/libstdc++-v3/include/bits/chrono_io.h
> >> >index c55b651d049..3a5bc5695fb 100644
> >> >--- a/libstdc++-v3/include/bits/chrono_io.h
> >> >+++ b/libstdc++-v3/include/bits/chrono_io.h
> >> >@@ -1785,277 +1785,272 @@ namespace __format
> >> >   __format::__formatter_chrono<_CharT> _M_f;
> >> > };
> >> >
> >> >-  template
> >> >+  template<__format::__char _CharT>
> >> > struct formatter
> >> > {
> >> >-  template
> >> >-  constexpr typename _ParseContext::iterator
> >> >-  parse(_ParseContext& __pc)
> >> >-  { return _M_f._M_parse(__pc, __format::_Day); }
> >> >+  constexpr typename basic_format_parse_context<_CharT>::iterator
> >> >+  parse(basic_format_parse_context<_CharT>& __pc)
> >> >+  { return _M_f._M_parse(__pc, __format::_Day); }
> >> >
> >> >-  template
> >> >-  typename _FormatContext::iterator
> >> >-  format(const chrono::day& __t, _FormatContext& __fc) const
> >> >+  template
> >> >+  typename basic_format_context<_Out, _CharT>::iterator
> >> >+  format(const chrono::day& __t,
> >> >+ basic_format_context<_Out, _CharT>& __fc) const
> >> >   { return _M_f._M_format(__t, __fc); }
> >> >
> >> > private:
> >> >   __format::__formatter_chrono<_CharT> _M_f;
> >> > };
> >> >
> >> >-  template
> >> >+  template<__format::__char _CharT>
> >> > struct formatter
> >> > {
> >> >-  template
> >> >-  constexpr typename _ParseContext::iterator
> >> >-  parse(_ParseContext& __pc)
> >> >-  { return _M_f._M_parse(__pc, __format::_Month); }
> >> >+  constexpr typename basic_format_parse_context<_CharT>::iterator
> >> >+  parse(basic_format_parse_context<_CharT>& __pc)
> >> >+  { return _M_f._M_parse(__pc, __format::_Month); }
> >> >
> >> >-  template
> >> >-  typename _FormatContext::iterator
> >> >-  format(const chrono::month& __t, _FormatContext& __fc) const
> >> >+  template
> >> >+  typename basic_format_context<_Out, _CharT>::iterator
> >> >+  format(const chrono::month& __t,
> >> >+ basic_format_context<_Out, _CharT>& __fc) const
> >> >   { return _M_f._M_format(__t, __fc); }
> >> >
> >> > private:
> >> >   __format::__formatter_chrono<_CharT> _M_f;
> >> > };
> >> >
> >> >-  template
> >> >+  template<__format::__char _CharT>
> >> > struct formatter
> >> > {
> >> >-  template
> >> >-  constexpr typename _ParseContext::iterator
> >> >-  parse(_ParseContext& __pc)
> >> >-  { return _M_f._M_parse(__pc, __format::_Year); }
> >> >+  constexpr typename basic_format_parse_context<_CharT>::iterator
> >> >+  parse(basic_format_parse_context<_CharT>& __pc)
> >> >+  { return _M_f._M_parse(__pc, __format::_Year); }
> >> >
> >> >-  template
> >> >-  typename _FormatContext::iterator
> >> >-  format(const chrono::year& __t, _FormatContext& __fc) const
> >> >+  template
> >> >+  typename basic_format_context<_Out, _CharT>::iterator
> >> >+  format(const chrono::year& __t,
> >> >+ basic

Re: [PATCH] gcc_release: Generate srcdir extras/infos/man pages from all FEs [PR119510]

[Jakub Jelinek]

On Mon, Mar 31, 2025 at 10:38:58AM +0200, Andreas Schwab wrote:
> On Mär 31 2025, Richard Biener wrote:
> 
> > Do we even install libffi.info?
> 
> We shouldn't.  It would conflict with the standalone libffi library, and
> we don't install anything from the target libffi library anyway (it's
> only used internally).

We don't install that.
But still during the build if libffi is enabled we try to build libffi.info.
So I think at least it doesn't hurt to have that generated in the release
tarballs.

Jakub

Re: [PATCH] PR middle-end/119442: expr.cc: Fix vec_duplicate into vector boolean modes

[Kyrylo Tkachov]

Ping.

Thanks,
Kyrill

> On 24 Mar 2025, at 14:28, Kyrylo Tkachov  wrote:
> 
> Hi all,
> 
> In this testcase GCC tries to expand a VNx4BI vector:
> vector(4)  _40;
> _39 = () _24;
> _40 = {_39, _39, _39, _39};
> 
> This ends up in a scalarised sequence of bitfield insert operations.
> This is despite the fact that AArch64 provides a vec_duplicate pattern
> specifically for vec_duplicate into VNx4BI.
> 
> The store_constructor code is overly conservative when trying vec_duplicate
> as it sees a requested VNx4BImode and an element mode of QImode, which I guess
> is the storage mode of BImode objects.
> 
> The vec_duplicate expander in aarch64-sve.md explicitly allows QImode element
> modes so it should be safe to use it. This patch extends that mode check
> to allow such expanders.
> 
> The testcase is heavily auto-reduced from a real application but in itself is
> nonsensical, but it does demonstrate the current problematic codegen.
> 
> This the testcase goes from:
> pfalse p15.b
> str p15, [sp, #6, mul vl]
> mov w0, 0
> ldr w2, [sp, 12]
> bfi w2, w0, 0, 4
> uxtw x2, w2
> bfi w2, w0, 4, 4
> uxtw x2, w2
> bfi w2, w0, 8, 4
> uxtw x2, w2
> bfi w2, w0, 12, 4
> str w2, [sp, 12]
> ldr p15, [sp, #6, mul vl]
> 
> into:
> whilelo p15.s, wzr, wzr
> 
> The whilelo could be optimised away into a pfalse of course, but the important
> part is that the bfis are gone.
> 
> Bootstrapped and tested on aarch64-none-linux-gnu.
> 
> Given this a regression from GCC 13 is this ok for trunk now?
> Thanks,
> Kyrill
> 
> Signed-off-by: Kyrylo Tkachov 
> 
> gcc/
> 
> PR middle-end/119442
> * expr.cc (store_constructor): Also allow element modes explicitly
> accepted by target vec_duplicate pattern.
> 
> gcc/testsuite/
> 
> PR middle-end/119442
> * gcc.target/aarch64/vls_sve_vec_dup_1.c: New test.
> 
> <0001-PR-middle-end-119442-expr.cc-Fix-vec_duplicate-into-.patch>

[PATCH] RISC-V: testsuite: Fix broken testsuite error of zicbop

[Liao Shihua]

Fix broken testsuite like 
"ERROR: gcc.target/riscv/cmo-zicbop-2.c   -Os : 1: too many arguments for " 
dg-do 1 compile target { { rv32-*-*}} "

gcc/testsuite/ChangeLog:

* gcc.target/riscv/cmo-zicbop-1.c: Fix missing { before target .
* gcc.target/riscv/cmo-zicbop-2.c: Likewise.
* gcc.target/riscv/prefetch-zicbop.c:Likewise.
* gcc.target/riscv/prefetch-zihintntl.c:Likewise.

---
 gcc/testsuite/gcc.target/riscv/cmo-zicbop-1.c   | 2 +-
 gcc/testsuite/gcc.target/riscv/cmo-zicbop-2.c   | 2 +-
 gcc/testsuite/gcc.target/riscv/prefetch-zicbop.c| 2 +-
 gcc/testsuite/gcc.target/riscv/prefetch-zihintntl.c | 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/gcc/testsuite/gcc.target/riscv/cmo-zicbop-1.c 
b/gcc/testsuite/gcc.target/riscv/cmo-zicbop-1.c
index e40874fc3df..581b5dbbfbf 100644
--- a/gcc/testsuite/gcc.target/riscv/cmo-zicbop-1.c
+++ b/gcc/testsuite/gcc.target/riscv/cmo-zicbop-1.c
@@ -1,4 +1,4 @@
-/* { dg-do compile target { { rv64-*-*}} } */
+/* { dg-do compile { target rv64-*-* } } */
 /* { dg-options "-march=rv64gc_zicbop -mabi=lp64" } */
 
 void foo (char *p)
diff --git a/gcc/testsuite/gcc.target/riscv/cmo-zicbop-2.c 
b/gcc/testsuite/gcc.target/riscv/cmo-zicbop-2.c
index dd6e1eafd44..3f7c1a455ad 100644
--- a/gcc/testsuite/gcc.target/riscv/cmo-zicbop-2.c
+++ b/gcc/testsuite/gcc.target/riscv/cmo-zicbop-2.c
@@ -1,4 +1,4 @@
-/* { dg-do compile target { { rv32-*-*}} } */
+/* { dg-do compile { target rv64-*-* } } */
 /* { dg-options "-march=rv32gc_zicbop -mabi=ilp32" } */
 
 void foo (char *p)
diff --git a/gcc/testsuite/gcc.target/riscv/prefetch-zicbop.c 
b/gcc/testsuite/gcc.target/riscv/prefetch-zicbop.c
index 250f9ec6b0a..44da4b2e578 100644
--- a/gcc/testsuite/gcc.target/riscv/prefetch-zicbop.c
+++ b/gcc/testsuite/gcc.target/riscv/prefetch-zicbop.c
@@ -1,4 +1,4 @@
-/* { dg-do compile target { { rv64-*-*}} } */
+/* { dg-do compile { target rv64-*-* } } */
 /* { dg-options "-march=rv64gc_zicbop -mabi=lp64" } */
 
 void foo (char *p)
diff --git a/gcc/testsuite/gcc.target/riscv/prefetch-zihintntl.c 
b/gcc/testsuite/gcc.target/riscv/prefetch-zihintntl.c
index 54e809f4353..43439d7aee6 100644
--- a/gcc/testsuite/gcc.target/riscv/prefetch-zihintntl.c
+++ b/gcc/testsuite/gcc.target/riscv/prefetch-zihintntl.c
@@ -1,4 +1,4 @@
-/* { dg-do compile target { { rv64-*-*}} } */
+/* { dg-do compile { target rv64-*-* } } */
 /* { dg-options "-march=rv64gc_zicbop_zihintntl -mabi=lp64" } */
 
 void foo (char *p)
-- 
2.43.0

Re: [PATCH] tree-optimization/119532 - ICE with fixed-point tail recursion

[Jakub Jelinek]

On Mon, Mar 31, 2025 at 11:12:45AM +0200, Richard Biener wrote:
> The following disables tail recursion optimization when fixed-point
> types are involved as we cannot generate -1 for all fixed-point
> types.
> 
> Bootstrapped and tested on x86_64-unknown-linux-gnu.  OK?
> 
> Thanks,
> Richard.
> 
>   PR tree-optimization/119532
>   * tree-tailcall.cc (process_assignment): FAIL for fixed-point
>   typed functions.
> 
>   * gcc.dg/torture/pr119532.c: New testcase.

So shouldn't we punt in that case just for the problematic operations
(i.e. NEGATE_EXPR and MINUS_EXPR)?
Aren't the others ok as is?

> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/torture/pr119532.c
> @@ -0,0 +1,14 @@
> +/* { dg-do compile } */
> +/* { dg-require-effective-target fixed_point } */
> +
> +extern _Fract sinuhk_deg (unsigned short _Accum);
> +
> +_Fract cosuhk_deg (unsigned short _Accum deg)
> +{
> +  unsigned short _Accum _90_deg = 90uhk;
> +  __asm ("" : "+r" (_90_deg));
> +
> +  return deg <= _90_deg
> +? sinuhk_deg (_90_deg - deg)
> +: -sinuhk_deg (deg - _90_deg);
> +}
> diff --git a/gcc/tree-tailcall.cc b/gcc/tree-tailcall.cc
> index 8ba67522191..8ea1c8b5f99 100644
> --- a/gcc/tree-tailcall.cc
> +++ b/gcc/tree-tailcall.cc
> @@ -361,6 +361,10 @@ process_assignment (gassign *stmt,
>  if (FLOAT_TYPE_P (TREE_TYPE (DECL_RESULT (current_function_decl
>return FAIL;
>  
> +  /* We at least cannot build -1 for all fixed point types.  */
> +  if (FIXED_POINT_TYPE_P (TREE_TYPE (DECL_RESULT (current_function_decl
> +return FAIL;
> +
>if (rhs_class == GIMPLE_UNARY_RHS
>&& op0 == *ass_var)
>  ;
> -- 
> 2.43.0

Jakub

Re: [pushed] c++/modules: unexported friend template

[Nathaniel Shead]

On Sat, Mar 29, 2025 at 11:14:46AM -0400, Jason Merrill wrote:
> Tested x86_64-pc-linux-gnu, applying to trunk.  Do you agree with my choice of
> how to adjust duplicate_decls?

Yes, that looks reasonable to me.  The point of this block is just to
ensure that we export any entities declared in the module, but an
injected friend isn't really a declaration in the same way.  I also
can't think of any other cases this might come up.

(Similarly, the fact that the early check for 'DECL_LANG_SPECIFIC'
breaks propagation of "not imported" for non-lang-specific decls doesn't
actually affect anything I can think of, because the only time this
would be relevant is if the new declaration was in module purview in
which case it would have a lang-specific.)

> 
> -- 8< --
> 
> Here we were failing to match the injected friend declaration to the
> definition because the latter isn't exported.  But the friend is attached to
> the module, so we need to look for any reachable declaration in that module,
> not just the exports.
> 
> The duplicate_decls change is to avoid clobbering DECL_MODULE_IMPORT_P on
> the imported definition; matching an injected friend doesn't change that
> it's imported.  I considered checking get_originating_module == 0 or
> !decl_defined_p instead of DECL_UNIQUE_FRIEND_P there, but I think this
> situation is specific to friends.
> 
> I removed an assert because we have a test for the same condition a few
> lines above.
> 
> gcc/cp/ChangeLog:
> 
>   * decl.cc (duplicate_decls): Don't clobber DECL_MODULE_IMPORT_P with
>   an injected friend.
>   * name-lookup.cc (check_module_override): Look at all reachable
>   decls in decl's originating module.
> 
> gcc/testsuite/ChangeLog:
> 
>   * g++.dg/modules/friend-9_a.C: New test.
>   * g++.dg/modules/friend-9_b.C: New test.
> ---
>  gcc/cp/decl.cc|  6 --
>  gcc/cp/name-lookup.cc | 19 ++-
>  gcc/testsuite/g++.dg/modules/friend-9_a.C | 13 +
>  gcc/testsuite/g++.dg/modules/friend-9_b.C | 13 +
>  4 files changed, 40 insertions(+), 11 deletions(-)
>  create mode 100644 gcc/testsuite/g++.dg/modules/friend-9_a.C
>  create mode 100644 gcc/testsuite/g++.dg/modules/friend-9_b.C
> 
> diff --git a/gcc/cp/decl.cc b/gcc/cp/decl.cc
> index a785d5e79cb..7d10b228ec6 100644
> --- a/gcc/cp/decl.cc
> +++ b/gcc/cp/decl.cc
> @@ -2539,8 +2539,10 @@ duplicate_decls (tree newdecl, tree olddecl, bool 
> hiding, bool was_hidden)
>   }
>  
>/* Propagate purviewness and importingness as with
> -  set_instantiating_module.  */
> -  if (modules_p () && DECL_LANG_SPECIFIC (new_result))
> +  set_instantiating_module, unless newdecl is a friend injection.  */
> +  if (modules_p () && DECL_LANG_SPECIFIC (new_result)
> +   && !(TREE_CODE (new_result) == FUNCTION_DECL
> +&& DECL_UNIQUE_FRIEND_P (new_result)))
>   {
> if (DECL_MODULE_PURVIEW_P (new_result))
>   DECL_MODULE_PURVIEW_P (old_result) = true;
> diff --git a/gcc/cp/name-lookup.cc b/gcc/cp/name-lookup.cc
> index df033edafc7..7fadbccfe39 100644
> --- a/gcc/cp/name-lookup.cc
> +++ b/gcc/cp/name-lookup.cc
> @@ -3777,6 +3777,10 @@ check_module_override (tree decl, tree mvec, bool 
> hiding,
>   any reachable declaration, so we should check for overriding here too.  
> */
>bool any_reachable = deduction_guide_p (decl);
>  
> +  /* DECL might have an originating module if it's an instantiation of a
> + friend; we want to look at all reachable decls in that module.  */
> +  unsigned decl_mod = get_originating_module (decl);
> +
>if (BINDING_VECTOR_SLOTS_PER_CLUSTER == BINDING_SLOTS_FIXED)
>  {
>cluster++;
> @@ -3789,18 +3793,15 @@ check_module_override (tree decl, tree mvec, bool 
> hiding,
>   /* Are we importing this module?  */
>   if (cluster->indices[jx].span != 1)
> continue;
> - if (!cluster->indices[jx].base)
> + unsigned cluster_mod = cluster->indices[jx].base;
> + if (!cluster_mod)
> continue;
> - if (!any_reachable
> - && !bitmap_bit_p (imports, cluster->indices[jx].base))
> + bool c_any_reachable = (any_reachable || cluster_mod == decl_mod);
> + if (!c_any_reachable && !bitmap_bit_p (imports, cluster_mod))
> continue;
>   /* Is it loaded? */
>   if (cluster->slots[jx].is_lazy ())
> -   {
> - gcc_assert (cluster->indices[jx].span == 1);
> - lazy_load_binding (cluster->indices[jx].base,
> -scope, name, &cluster->slots[jx]);
> -   }
> +   lazy_load_binding (cluster_mod, scope, name, &cluster->slots[jx]);
>   tree bind = cluster->slots[jx];
>   if (!bind)
> /* Errors could cause there to be nothing.  */
> @@ -3812,7 +3813,7 @@ check_module_override (tree decl, tree mvec, bool 
> hiding,
>   /* If there was a matching STAT_TYPE here then xref_tag
>  should have found i

Re: [PATCH] tree-optimization/119532 - ICE with fixed-point tail recursion

[Jakub Jelinek]

On Mon, Mar 31, 2025 at 11:25:27AM +0200, Richard Biener wrote:
> > >   PR tree-optimization/119532
> > >   * tree-tailcall.cc (process_assignment): FAIL for fixed-point
> > >   typed functions.
> > > 
> > >   * gcc.dg/torture/pr119532.c: New testcase.
> > 
> > So shouldn't we punt in that case just for the problematic operations
> > (i.e. NEGATE_EXPR and MINUS_EXPR)?
> > Aren't the others ok as is?
> 
> We are associating the expression which at least breaks with
> saturating fixed-point.  We are also rejecting FP types
> without -fassociative-math, not trying to special cases some
> maybe working cases.
> 
> So, I'm not sure the code behaves correctly even when not
> running into the build_minus_one_cst case for _Fract types.
> We'd at least need to disable TYPE_SATURATING.
> 
> I can change to just disable TYPE_SATURATING and
> !ALL_SCALAR_ACCUM_MODE_P (TYPE_MODE (type)) (there's no TYPE-based
> test for _Fract it seems?).  Would you prefer that?
> Association could still affect rounding, and I don't think we
> document behavior of -fassociative-math on fixed-point?

I guess I don't know enough about fixed point types, so
let's go with your original patch, if anyone actually interested
in those types comes with something better, they can.

Jakub

Re: [PATCH] PR middle-end/119442: expr.cc: Fix vec_duplicate into vector boolean modes

[Richard Biener]

On Mon, Mar 31, 2025 at 9:36 AM Kyrylo Tkachov  wrote:
>
> Ping.

Can you reference the patch please?  I'll note your mails have the tendency to
end up in my spam folder (which is auto-purged after some time).  Probably
a setup issue at nvidias side.

Richard.

> Thanks,
> Kyrill
>
> > On 24 Mar 2025, at 14:28, Kyrylo Tkachov  wrote:
> >
> > Hi all,
> >
> > In this testcase GCC tries to expand a VNx4BI vector:
> > vector(4)  _40;
> > _39 = () _24;
> > _40 = {_39, _39, _39, _39};
> >
> > This ends up in a scalarised sequence of bitfield insert operations.
> > This is despite the fact that AArch64 provides a vec_duplicate pattern
> > specifically for vec_duplicate into VNx4BI.
> >
> > The store_constructor code is overly conservative when trying vec_duplicate
> > as it sees a requested VNx4BImode and an element mode of QImode, which I 
> > guess
> > is the storage mode of BImode objects.
> >
> > The vec_duplicate expander in aarch64-sve.md explicitly allows QImode 
> > element
> > modes so it should be safe to use it. This patch extends that mode check
> > to allow such expanders.
> >
> > The testcase is heavily auto-reduced from a real application but in itself 
> > is
> > nonsensical, but it does demonstrate the current problematic codegen.
> >
> > This the testcase goes from:
> > pfalse p15.b
> > str p15, [sp, #6, mul vl]
> > mov w0, 0
> > ldr w2, [sp, 12]
> > bfi w2, w0, 0, 4
> > uxtw x2, w2
> > bfi w2, w0, 4, 4
> > uxtw x2, w2
> > bfi w2, w0, 8, 4
> > uxtw x2, w2
> > bfi w2, w0, 12, 4
> > str w2, [sp, 12]
> > ldr p15, [sp, #6, mul vl]
> >
> > into:
> > whilelo p15.s, wzr, wzr
> >
> > The whilelo could be optimised away into a pfalse of course, but the 
> > important
> > part is that the bfis are gone.
> >
> > Bootstrapped and tested on aarch64-none-linux-gnu.
> >
> > Given this a regression from GCC 13 is this ok for trunk now?
> > Thanks,
> > Kyrill
> >
> > Signed-off-by: Kyrylo Tkachov 
> >
> > gcc/
> >
> > PR middle-end/119442
> > * expr.cc (store_constructor): Also allow element modes explicitly
> > accepted by target vec_duplicate pattern.
> >
> > gcc/testsuite/
> >
> > PR middle-end/119442
> > * gcc.target/aarch64/vls_sve_vec_dup_1.c: New test.
> >
> > <0001-PR-middle-end-119442-expr.cc-Fix-vec_duplicate-into-.patch>
>

Re: [PATCH] aarch64: remove SVE2 requirement from SME and diagnose it as unsupported

[Richard Sandiford]

"Andre Vieira (lists)"  writes:
> Here is the latest version of the patch, I wasn't sure whether Richard's 
> 'LGTM with...' was meant as a conditional OK and together with the 
> changes suggested by Andrew I thought I'd ask again, OK for trunk?
>
>
> As per the AArch64 ISA FEAT_SME does not require FEAT_SVE2. However, we 
> don't support SME without SVE2 and bail out with a 'sorry' if this 
> configuration is encountered.  We may choose to support this in the future.
>
> gcc/ChangeLog:
>
>   * config/aarch64/aarch64-arches.def (SME): Remove SVE2 as prerequisite
>   and add in FCMA and F16FML.
>   * config/aarch64/aarch64.cc (aarch64_override_options_internal):
>   Diagnose use of SME without SVE2 and implicitly enable SVE2 when
>   enabling SME after streaming mode diagnosis.
>   * doc/invoke.texi (sme): Document that this can only be used with the
>   sve2 extension.
>
> gcc/testsuite/ChangeLog:
>
>   * gcc.target/aarch64/no-sve-with-sme-1.c: New.
>   * gcc.target/aarch64/no-sve-with-sme-2.c: New.
>   * gcc.target/aarch64/no-sve-with-sme-3.c: New.
>   * gcc.target/aarch64/no-sve-with-sme-4.c: New.
>   * gcc.target/aarch64/pragma_cpp_predefs_4.c: Pass +sve2 to existing
>   +sme pragma.
>   * gcc.target/aarch64/sve/acle/general-c/binary_int_opt_single_n_2.c:
>   Likewise.
>   * gcc.target/aarch64/sve/acle/general-c/binary_opt_single_n_2.c:
>   Likewise.
>   * gcc.target/aarch64/sve/acle/general-c/binary_single_1.c: Likewise.
>   * 
> gcc.target/aarch64/sve/acle/general-c/binary_za_slice_int_opt_single_1.c:
>   * gcc.target/aarch64/sve/acle/general-c/binary_za_slice_lane_1.c:
>   Likewise.
>   * gcc.target/aarch64/sve/acle/general-c/binary_za_slice_lane_2.c:
>   Likewise.
>   * gcc.target/aarch64/sve/acle/general-c/binary_za_slice_lane_3.c:
>   Likewise.
>   * gcc.target/aarch64/sve/acle/general-c/binary_za_slice_lane_4.c:
>   Likewise.
>   * gcc.target/aarch64/sve/acle/general-c/binary_za_slice_opt_single_1.c:
>   Likewise.
>   * gcc.target/aarch64/sve/acle/general-c/binary_za_slice_opt_single_2.c:
>   Likewise.
>   * gcc.target/aarch64/sve/acle/general-c/binary_za_slice_opt_single_3.c:
>   Likewise.
>   * 
> gcc.target/aarch64/sve/acle/general-c/binary_za_slice_uint_opt_single_1.c:
>   Likewise.
>   * gcc.target/aarch64/sve/acle/general-c/binaryxn_2.c: Likewise.
>   * gcc.target/aarch64/sve/acle/general-c/clamp_1.c: Likewise.
>   * gcc.target/aarch64/sve/acle/general-c/compare_scalar_count_1.c:
>   Likewise.
>   * gcc.target/aarch64/sve/acle/general-c/dot_za_slice_int_lane_1.c:
>   Likewise.
>   * gcc.target/aarch64/sve/acle/general-c/dot_za_slice_lane_1.c:
>   Likewise.
>   * gcc.target/aarch64/sve/acle/general-c/dot_za_slice_lane_2.c:
>   Likewise.
>   * gcc.target/aarch64/sve/acle/general-c/dot_za_slice_uint_lane_1.c:
>   Likewise.
>   * gcc.target/aarch64/sve/acle/general-c/shift_right_imm_narrowxn_1.c:
>   Likewise.
>   * gcc.target/aarch64/sve/acle/general-c/storexn_1.c: Likewise.
>   * gcc.target/aarch64/sve/acle/general-c/ternary_mfloat8_lane_1.c:
>   Likewise.
>   * 
> gcc.target/aarch64/sve/acle/general-c/ternary_mfloat8_lane_group_selection_1.c:
>   Likewise.
>   * gcc.target/aarch64/sve/acle/general-c/ternary_qq_or_011_lane_1.c:
>   Likewise.
>   * gcc.target/aarch64/sve/acle/general-c/unary_convertxn_1.c: Likewise.
>   * gcc.target/aarch64/sve/acle/general-c/unary_convertxn_narrow_1.c:
>   Likewise.
>   * gcc.target/aarch64/sve/acle/general-c/unaryxn_1.c: Likewise.
>   * gcc.target/aarch64/sve/acle/general-c/write_za_1.c: Likewise.
>   * gcc.target/aarch64/sve/acle/general-c/write_za_slice_1.c: Likewise.

OK, thanks.

Richard

> diff --git a/gcc/config/aarch64/aarch64-option-extensions.def 
> b/gcc/config/aarch64/aarch64-option-extensions.def
> index 
> aa8d315c240fbd25b49008b131cc09f04001eb80..4649d8e977a67c37c5cbf2dbb1616aeb12592317
>  100644
> --- a/gcc/config/aarch64/aarch64-option-extensions.def
> +++ b/gcc/config/aarch64/aarch64-option-extensions.def
> @@ -207,7 +207,7 @@ AARCH64_FMV_FEATURE("sve2-sm4", SVE_SM4, (SVE2_SM4))
>  
>  AARCH64_OPT_EXTENSION("sve2p1", SVE2p1, (SVE2), (), (), "sve2p1")
>  
> -AARCH64_OPT_FMV_EXTENSION("sme", SME, (BF16, SVE2), (), (), "sme")
> +AARCH64_OPT_FMV_EXTENSION("sme", SME, (BF16, FCMA, F16, F16FML), (), (), 
> "sme")
>  
>  AARCH64_OPT_EXTENSION("memtag", MEMTAG, (), (), (), "")
>  
> diff --git a/gcc/config/aarch64/aarch64.cc b/gcc/config/aarch64/aarch64.cc
> index 
> 36b65df50c57267d9c18e430665c411f1bf3cc24..5b1c44e33069e5db33e8201d03cf687c6d92fdc7
>  100644
> --- a/gcc/config/aarch64/aarch64.cc
> +++ b/gcc/config/aarch64/aarch64.cc
> @@ -18759,7 +18759,10 @@ aarch64_override_options_internal (struct 
> gcc_options *opts)
> " option %<-march%>, or by using the %"
> " attribute or p

[PATCH 1/2] GCN, libstdc++: '#define _GLIBCXX_USE_WEAK_REF 0' [PR119369]

[Thomas Schwinge]

This fixes a few hundreds of compilation/linking FAILs (similar to PR69506),
where the GCN/LLVM 'ld' reported:

ld: error: relocation R_AMDGPU_REL32_LO cannot be used against symbol 
'_ZGTtnam'; recompile with -fPIC
>>> defined in 
[...]/amdgcn-amdhsa/./libstdc++-v3/src/.libs/libstdc++.a(cow-stdexcept.o)
>>> referenced by cow-stdexcept.cc:259 
([...]/libstdc++-v3/src/c++11/cow-stdexcept.cc:259)
>>>   
cow-stdexcept.o:(_txnal_cow_string_C1_for_exceptions(void*, char const*, 
void*)) in archive [...]/amdgcn-amdhsa/./libstdc++-v3/src/.libs/libstdc++.a

ld: error: relocation R_AMDGPU_REL32_HI cannot be used against symbol 
'_ZGTtnam'; recompile with -fPIC
>>> defined in 
[...]/amdgcn-amdhsa/./libstdc++-v3/src/.libs/libstdc++.a(cow-stdexcept.o)
>>> referenced by cow-stdexcept.cc:259 
([...]/source-gcc/libstdc++-v3/src/c++11/cow-stdexcept.cc:259)
>>>   
cow-stdexcept.o:(_txnal_cow_string_C1_for_exceptions(void*, char const*, 
void*)) in archive [...]/amdgcn-amdhsa/./libstdc++-v3/src/.libs/libstdc++.a

[...]

..., which is:

$ c++filt _ZGTtnam
transaction clone for operator new[](unsigned long)

..., and similarly for other libitm symbols.

However, the affected test cases, if applicable, then run into execution test
FAILs, due to PR119369
"GCN: weak undefined symbols -> execution test FAIL, 
'HSA_STATUS_ERROR_VARIABLE_UNDEFINED'".

PR target/119369
libstdc++-v3/
* config/cpu/gcn/cpu_defines.h: New.
* configure.host [GCN] (cpu_defines_dir): Point to it.
---
 libstdc++-v3/config/cpu/gcn/cpu_defines.h | 55 +++
 libstdc++-v3/configure.host   |  3 ++
 2 files changed, 58 insertions(+)
 create mode 100644 libstdc++-v3/config/cpu/gcn/cpu_defines.h

diff --git a/libstdc++-v3/config/cpu/gcn/cpu_defines.h 
b/libstdc++-v3/config/cpu/gcn/cpu_defines.h
new file mode 100644
index ..028bfb0ccff1
--- /dev/null
+++ b/libstdc++-v3/config/cpu/gcn/cpu_defines.h
@@ -0,0 +1,55 @@
+// Specific definitions for GCN platforms  -*- C++ -*-
+
+// Copyright (C) 2025 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+
+// Under Section 7 of GPL version 3, you are granted additional
+// permissions described in the GCC Runtime Library Exception, version
+// 3.1, as published by the Free Software Foundation.
+
+// You should have received a copy of the GNU General Public License and
+// a copy of the GCC Runtime Library Exception along with this program;
+// see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
+// .
+
+/** @file bits/cpu_defines.h
+ *  This is an internal header file, included by other library headers.
+ *  Do not attempt to use it directly. @headername{iosfwd}
+ */
+
+#ifndef _GLIBCXX_CPU_DEFINES
+#define _GLIBCXX_CPU_DEFINES 1
+
+/* GCN appears to run into issues similar to PR69506:
+
+   ld: error: relocation R_AMDGPU_REL32_LO cannot be used against symbol 
'_ZGTtnam'; recompile with -fPIC
+   >>> defined in 
[...]/amdgcn-amdhsa/./libstdc++-v3/src/.libs/libstdc++.a(cow-stdexcept.o)
+   >>> referenced by cow-stdexcept.cc:259 
([...]/libstdc++-v3/src/c++11/cow-stdexcept.cc:259)
+   >>>   
cow-stdexcept.o:(_txnal_cow_string_C1_for_exceptions(void*, char const*, 
void*)) in archive [...]/amdgcn-amdhsa/./libstdc++-v3/src/.libs/libstdc++.a
+   
+   ld: error: relocation R_AMDGPU_REL32_HI cannot be used against symbol 
'_ZGTtnam'; recompile with -fPIC
+   >>> defined in 
[...]/amdgcn-amdhsa/./libstdc++-v3/src/.libs/libstdc++.a(cow-stdexcept.o)
+   >>> referenced by cow-stdexcept.cc:259 
([...]/source-gcc/libstdc++-v3/src/c++11/cow-stdexcept.cc:259)
+   >>>   
cow-stdexcept.o:(_txnal_cow_string_C1_for_exceptions(void*, char const*, 
void*)) in archive [...]/amdgcn-amdhsa/./libstdc++-v3/src/.libs/libstdc++.a
+   
+   [...]
+
+   ..., which is:
+
+   $ c++filt _ZGTtnam
+   transaction clone for operator new[](unsigned long)
+
+   ..., and similarly for other libitm symbols.  See PR119369.  */
+#define _GLIBCXX_USE_WEAK_REF 0
+
+#endif
diff --git a/libstdc++-v3/configure.host b/libstdc++-v3/configure.host
index cb4c28a62bf3..0bed9dfff957 100644
--- a/libstdc++-v3/configure.host
+++ b/libstdc++-v3/configure.host
@@ -147,6 +147,9 @@ cpu_include_dir=cpu/${try_cpu}
 # Set specific CPU overrides for cpu_defines_dir. Most can just use generic.
 # THIS TABLE IS

[committed] OpenMP: modify_call_for_omp_dispatch - fix invalid memory access after 'error' [PR119541]

[Tobias Burnus]

This fixes an out-of-array-bounds access in the case that
   nappend < ninterop

Namely, the number of interop clauses to 'dispatch' exceeds
the number of interop args accepted by the function/specified
in the append_args clause to 'declare variant'.

OpenMP does not allow this - hence, GCC diagnoses this error,
but the append code was still executed, leading to the issue.

Committed asr15-9063-gf3899e0fd3f9aa Thanks to Filip for testing with an 
ASAN-instrumentedGCC and reporting this issue! Tobias
commit f3899e0fd3f9aa6b579a21e87b50c61ea5c448df
Author: Tobias Burnus 
Date:   Mon Mar 31 11:44:26 2025 +0200

OpenMP: modify_call_for_omp_dispatch - fix invalid memory access after 'error' [PR119541]

OpenMP requires that the number of dispatch 'interop' clauses (ninterop)
is less or equal to the number of declare variant 'append_args' interop
objects (nappend).

While 'nappend < ninterop' was diagnosed as error, the processing continues,
which lead to an invalid out-of-bounds memory access. Solution: only
process the first nappend 'interop' clauses.

gcc/ChangeLog:

PR middle-end/119541
* gimplify.cc (modify_call_for_omp_dispatch): Limit interop claues
processing by the number of append_args arguments.
---
 gcc/gimplify.cc | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/gcc/gimplify.cc b/gcc/gimplify.cc
index 422ad1265a6..a8399dc8363 100644
--- a/gcc/gimplify.cc
+++ b/gcc/gimplify.cc
@@ -3940,47 +3940,48 @@ modify_call_for_omp_dispatch (tree expr, tree dispatch_clauses,
   if (nappend < ninterop)
 	{
 	  error_at (OMP_CLAUSE_LOCATION (dispatch_interop),
 		"number of list items in % clause (%d) "
 		"exceeds the number of % items (%d) for "
 		"% candidate %qD",
 		ninterop, nappend, fndecl);
 	  inform (dispatch_append_args
 		  ? EXPR_LOCATION (TREE_PURPOSE (dispatch_append_args))
 		  : DECL_SOURCE_LOCATION (fndecl),
 		  "% candidate %qD declared here",
 		  fndecl);
+	  ninterop = nappend;
 	}
 }
   if (dispatch_interop && !dispatch_device_num)
 {
   gcc_checking_assert (ninterop > 1);
   error_at (OMP_CLAUSE_LOCATION (dispatch_interop),
 		"the % clause must be present if the % "
 		"clause has more than one list item");
 }
   else if (dispatch_append_args)
 {
   tree *buffer = XALLOCAVEC (tree, nargs + nappend);
   tree arg = TYPE_ARG_TYPES (TREE_TYPE (fndecl));
   /* Copy the first arguments; insert then the interop objects,
 	 and then copy the rest (nargs - nfirst_args) args.  */
   int i;
   for (i = 0; i < nfirst_args; i++)
 	{
 	  arg = TREE_CHAIN (arg);
 	  buffer[i] = CALL_EXPR_ARG (expr, i);
 	}
   int j = ninterop;
-  for (tree t = dispatch_interop; t; t = TREE_CHAIN (t))
+  for (tree t = dispatch_interop; t && j > 0; t = TREE_CHAIN (t))
 	if (OMP_CLAUSE_CODE (t) == OMP_CLAUSE_INTEROP)
 	  buffer[i + --j] = OMP_CLAUSE_DECL (t);
   gcc_checking_assert (j == 0);
 
   /* Do we need to create additional interop objects?  */
   if (ninterop < nappend)
 	{
 	  if (dispatch_device_num == NULL_TREE)
 	/* Not remapping device number.  */
 	dispatch_device_num = build_int_cst (integer_type_node,
 		 GOMP_DEVICE_DEFAULT_OMP_61);
 	  int nnew = nappend - ninterop;

Re: [PATCH v3] RISC-V: Fix wrong LMUL when only implict zve32f.

[Robin Dapp]

LGTM (even though I still don't like the spec :D).

We still have an implicit assumption in riscv-vsetvl.cc that might modify LMUL:

In prev_ratio_valid_for_next_sew_p and next_ratio_valid_for_prev_sew_p we check 
whether the ratio of two LMULs is <= 8.  ISTR that with recent changes we only 
re-use an existing ratio and don't compute a new one but it might be worth a 
second look.  A while ago we certainly did change LMUL even to values that 
weren't initially enabled.


--
Regards
Robin

[PATCH v3] RISC-V: Fix wrong LMUL when only implict zve32f.

[Kito Cheng]

From: Monk Chiang 

According to Section 3.4.2, Vector Register Grouping, in the RISC-V
Vector Specification, the rule for LMUL is LMUL >= SEW/ELEN

Changes since V2:
- Add check on vector-iterators.md
- Add one more testcase to check the VLS use correct mode.

gcc/ChangeLog:
* config/riscv/riscv-v.cc: Add restrict for insert LMUL.
config/riscv/riscv-vector-builtins-types.def:
Use RVV_REQUIRE_ELEN_64 to check LMUL number.
config/riscv/riscv-vector-switch.def: Likewise.
* config/riscv/vector-iterators.md: Check TARGET_VECTOR_ELEN_64
rather than "TARGET_MIN_VLEN > 32" for all iterator.

gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/pr111391-2.c: Update test.
gcc.target/riscv/rvv/base/abi-14.c: Update test.
gcc.target/riscv/rvv/base/abi-16.c: Update test.
gcc.target/riscv/rvv/base/abi-18.c: Update test.
gcc.target/riscv/rvv/base/vsetvl_zve32-1.c: New test.
gcc.target/riscv/rvv/base/vsetvl_zve32-2.c: New test.

Co-authored-by: Kito Cheng 
---
 gcc/config/riscv/riscv-v.cc   |   8 +-
 .../riscv/riscv-vector-builtins-types.def | 322 +-
 gcc/config/riscv/riscv-vector-switch.def  |  84 ++---
 gcc/config/riscv/vector-iterators.md  | 256 +++---
 .../gcc.target/riscv/rvv/autovec/pr111391-2.c |   2 +-
 .../gcc.target/riscv/rvv/base/abi-14.c|  84 ++---
 .../gcc.target/riscv/rvv/base/abi-16.c|  98 +++---
 .../gcc.target/riscv/rvv/base/abi-18.c| 112 +++---
 .../riscv/rvv/base/vsetvl_zve32-1.c   |  73 
 .../riscv/rvv/base/vsetvl_zve32-2.c   |  25 ++
 10 files changed, 582 insertions(+), 482 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vsetvl_zve32-1.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vsetvl_zve32-2.c

diff --git a/gcc/config/riscv/riscv-v.cc b/gcc/config/riscv/riscv-v.cc
index 287eb3e54cf..aae2d274336 100644
--- a/gcc/config/riscv/riscv-v.cc
+++ b/gcc/config/riscv/riscv-v.cc
@@ -1782,13 +1782,15 @@ get_vlmul (machine_mode mode)
   int inner_size = GET_MODE_BITSIZE (GET_MODE_INNER (mode));
   if (size < TARGET_MIN_VLEN)
{
+ /* Follow rule LMUL >= SEW / ELEN.  */
+ int elen = TARGET_VECTOR_ELEN_64 ? 1 : 2;
  int factor = TARGET_MIN_VLEN / size;
  if (inner_size == 8)
-   factor = MIN (factor, 8);
+   factor = MIN (factor, 8 / elen);
  else if (inner_size == 16)
-   factor = MIN (factor, 4);
+   factor = MIN (factor, 4 / elen);
  else if (inner_size == 32)
-   factor = MIN (factor, 2);
+   factor = MIN (factor, 2 / elen);
  else if (inner_size == 64)
factor = MIN (factor, 1);
  else
diff --git a/gcc/config/riscv/riscv-vector-builtins-types.def 
b/gcc/config/riscv/riscv-vector-builtins-types.def
index 6b98b93dfb6..857b63758a0 100644
--- a/gcc/config/riscv/riscv-vector-builtins-types.def
+++ b/gcc/config/riscv/riscv-vector-builtins-types.def
@@ -369,20 +369,20 @@ along with GCC; see the file COPYING3. If not see
 #define DEF_RVV_XFQF_OPS(TYPE, REQUIRE)
 #endif
 
-DEF_RVV_I_OPS (vint8mf8_t, RVV_REQUIRE_MIN_VLEN_64)
+DEF_RVV_I_OPS (vint8mf8_t, RVV_REQUIRE_ELEN_64)
 DEF_RVV_I_OPS (vint8mf4_t, 0)
 DEF_RVV_I_OPS (vint8mf2_t, 0)
 DEF_RVV_I_OPS (vint8m1_t, 0)
 DEF_RVV_I_OPS (vint8m2_t, 0)
 DEF_RVV_I_OPS (vint8m4_t, 0)
 DEF_RVV_I_OPS (vint8m8_t, 0)
-DEF_RVV_I_OPS (vint16mf4_t, RVV_REQUIRE_MIN_VLEN_64)
+DEF_RVV_I_OPS (vint16mf4_t, RVV_REQUIRE_ELEN_64)
 DEF_RVV_I_OPS (vint16mf2_t, 0)
 DEF_RVV_I_OPS (vint16m1_t, 0)
 DEF_RVV_I_OPS (vint16m2_t, 0)
 DEF_RVV_I_OPS (vint16m4_t, 0)
 DEF_RVV_I_OPS (vint16m8_t, 0)
-DEF_RVV_I_OPS (vint32mf2_t, RVV_REQUIRE_MIN_VLEN_64)
+DEF_RVV_I_OPS (vint32mf2_t, RVV_REQUIRE_ELEN_64)
 DEF_RVV_I_OPS (vint32m1_t, 0)
 DEF_RVV_I_OPS (vint32m2_t, 0)
 DEF_RVV_I_OPS (vint32m4_t, 0)
@@ -392,20 +392,20 @@ DEF_RVV_I_OPS (vint64m2_t, RVV_REQUIRE_ELEN_64)
 DEF_RVV_I_OPS (vint64m4_t, RVV_REQUIRE_ELEN_64)
 DEF_RVV_I_OPS (vint64m8_t, RVV_REQUIRE_ELEN_64)
 
-DEF_RVV_U_OPS (vuint8mf8_t, RVV_REQUIRE_MIN_VLEN_64)
+DEF_RVV_U_OPS (vuint8mf8_t, RVV_REQUIRE_ELEN_64)
 DEF_RVV_U_OPS (vuint8mf4_t, 0)
 DEF_RVV_U_OPS (vuint8mf2_t, 0)
 DEF_RVV_U_OPS (vuint8m1_t, 0)
 DEF_RVV_U_OPS (vuint8m2_t, 0)
 DEF_RVV_U_OPS (vuint8m4_t, 0)
 DEF_RVV_U_OPS (vuint8m8_t, 0)
-DEF_RVV_U_OPS (vuint16mf4_t, RVV_REQUIRE_MIN_VLEN_64)
+DEF_RVV_U_OPS (vuint16mf4_t, RVV_REQUIRE_ELEN_64)
 DEF_RVV_U_OPS (vuint16mf2_t, 0)
 DEF_RVV_U_OPS (vuint16m1_t, 0)
 DEF_RVV_U_OPS (vuint16m2_t, 0)
 DEF_RVV_U_OPS (vuint16m4_t, 0)
 DEF_RVV_U_OPS (vuint16m8_t, 0)
-DEF_RVV_U_OPS (vuint32mf2_t, RVV_REQUIRE_MIN_VLEN_64)
+DEF_RVV_U_OPS (vuint32mf2_t, RVV_REQUIRE_ELEN_64)
 DEF_RVV_U_OPS (vuint32m1_t, 0)
 DEF_RVV_U_OPS (vuint32m2_t, 0)
 DEF_RVV_U_OPS (vuint32m4_t, 0)
@@ -415,21 +415,21 @@ DEF_RVV_U_OPS (vuint64m2_t, RVV_REQUIRE_ELEN_64)
 DEF_RVV_U_OPS (vuint64m4_t, RVV_REQUIRE_ELEN_64)
 DEF_RVV_U_OPS

Re: [PATCH] target/119549 - fixup handling of -mno-sse4

[Richard Biener]

On Mon, 31 Mar 2025, Jakub Jelinek wrote:

> On Mon, Mar 31, 2025 at 03:12:56PM +0200, Richard Biener wrote:
> > The following fixes ix86_handle_option to properly handle -mno-sse4
> > which is always handled as -msse4 with value unset.  I've verified
> > no other OPT_mno_* is left around.
> > 
> > Bootstrap and regtest running on x86_64-unknown-linux-gnu.
> > 
> > This error goes back quite some time, I'm not sure how prevalent
> > the use of -mno-sse4 is.  In fact I have no idea why we have
> > OPT_mno_sse4 at all...
> 
> That is because SSE4 is SSE4.1 + SSE4.2.
> So for -msse4 we want it to act as -msse4.2 and for -mno-sse4
> to act as -mno-sse4.1

Yes, but it seems ix86_handle_option handles this via
OPTION_MASK_ISA_SSE4_SET vs. ~OPTION_MASK_ISA_SSE4_UNSET.  So the
question is what the -mno-sse4 options entry does.  I'll note
that ix86_handle_option also unsets flags in ix86_isa_flags2
with -mno-sse4 but the mno-sse4 options entry does not indicate
that.

Richard.

> > msse4
> > Target RejectNegative Mask(ISA_SSE4_2) Var(ix86_isa_flags) Save
> > Support MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1 and SSE4.2 built-in functions 
> > and code generation.
> > 
> > mno-sse4
> > Target RejectNegative InverseMask(ISA_SSE4_1) Var(ix86_isa_flags) Save
> > Do not support SSE4.1 and SSE4.2 built-in functions and code generation.
> > 
> > but we end up building
> > 
> > $3 = {opt_index = 2231, warn_message = 0x0, arg = 0x0, 
> >   orig_option_with_args_text = 0x440d108 "-msse4", canonical_option = {
> > 0x440d108 "-msse4", 0x0, 0x0, 0x0}, canonical_option_num_elements = 1, 
> >   value = 0, mask = 0, errors = 0}
> > 
> > from -mno-sse4 in target("") via ix86_valid_target_attribute_inner_p.
> > 
> > OK?  Any clarification on what the above is about?
> > 
> > Richard.
> > 
> > PR target/119549
> > * common/config/i386/i386-common.cc (ix86_handle_option):
> > Handle OPT_mno_sse4 via OPT_msse4 and looking at value.
> > 
> > * gcc.target/i386/pr119549.c: New testcase.
> > ---
> >  gcc/common/config/i386/i386-common.cc| 21 -
> >  gcc/testsuite/gcc.target/i386/pr119549.c | 15 +++
> >  2 files changed, 27 insertions(+), 9 deletions(-)
> >  create mode 100644 gcc/testsuite/gcc.target/i386/pr119549.c
> > 
> > diff --git a/gcc/common/config/i386/i386-common.cc 
> > b/gcc/common/config/i386/i386-common.cc
> > index 80aec3244bc..296df3b3230 100644
> > --- a/gcc/common/config/i386/i386-common.cc
> > +++ b/gcc/common/config/i386/i386-common.cc
> > @@ -1519,15 +1519,18 @@ ix86_handle_option (struct gcc_options *opts,
> >return true;
> >  
> >  case OPT_msse4:
> > -  opts->x_ix86_isa_flags |= OPTION_MASK_ISA_SSE4_SET;
> > -  opts->x_ix86_isa_flags_explicit |= OPTION_MASK_ISA_SSE4_SET;
> > -  return true;
> > -
> > -case OPT_mno_sse4:
> > -  opts->x_ix86_isa_flags &= ~OPTION_MASK_ISA_SSE4_UNSET;
> > -  opts->x_ix86_isa_flags_explicit |= OPTION_MASK_ISA_SSE4_UNSET;
> > -  opts->x_ix86_isa_flags2 &= ~OPTION_MASK_ISA2_SSE4_UNSET;
> > -  opts->x_ix86_isa_flags2_explicit |= OPTION_MASK_ISA2_SSE4_UNSET;
> > +  if (value)
> > +   {
> > + opts->x_ix86_isa_flags |= OPTION_MASK_ISA_SSE4_SET;
> > + opts->x_ix86_isa_flags_explicit |= OPTION_MASK_ISA_SSE4_SET;
> > +   }
> > +  else
> > +   {
> > + opts->x_ix86_isa_flags &= ~OPTION_MASK_ISA_SSE4_UNSET;
> > + opts->x_ix86_isa_flags_explicit |= OPTION_MASK_ISA_SSE4_UNSET;
> > + opts->x_ix86_isa_flags2 &= ~OPTION_MASK_ISA2_SSE4_UNSET;
> > + opts->x_ix86_isa_flags2_explicit |= OPTION_MASK_ISA2_SSE4_UNSET;
> > +   }
> >return true;
> >  
> >  case OPT_msse4a:
> 
> For OPT_msse4 that looks reasonable, but I wonder if the old code shouldn't
> be kept for OPT_mno_sse4.  When I just try to compile something with
> -O2 -mavx2 -mno-sse4
> previously this would make it like -O2 -mssse3, now it will act as -O2 -mavx2.
> E.g. compile
> #if __SSSE3__
> int i;
> #endif
> #if __AVX2__
> int j;
> #endif
> 
> I wonder what OPT_mno_sse4 with !value would actually mean though (if it
> ever happens).
> 
>   Jakub
> 
> 

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

[committed] d: Fix error with -Warray-bounds and -O2 [PR117002]

[Iain Buclaw]

Hi,

This patch fixes an error raised by the middle-end when compiling with
the options `-Warray-bounds -O2'.

The record layout of class types in D don't get any tail padding, so it
is possible for the `classInstanceSize' to not be a multiple of the
`classInstanceAlignment'.

Rather than setting the instance alignment on the underlying
RECORD_TYPE, instead give the type an alignment of 1, which will mark it
as TYPE_PACKED.  The value of `classInstanceAlignment' is instead
applied to the DECL_ALIGN of both the static `init' symbol, and the
stack allocated variable used when generating `new' for a `scope' class.

Bootstrapped and regression tested on x86_64-linux-gnu/-m32, committed
to mainline and backported to releases/gcc-14 and releases/gcc-13.

Regards,
Iain.

---
PR d/117002

gcc/d/ChangeLog:

* decl.cc (aggregate_initializer_decl): Set explicit decl alignment of
class instance.
* expr.cc (ExprVisitor::visit (NewExp *)): Likewise.
* types.cc (TypeVisitor::visit (TypeClass *)): Mark the record type of
classes as packed.

gcc/testsuite/ChangeLog:

* gdc.dg/torture/pr117002.d: New test.
---
 gcc/d/decl.cc   |  6 ++
 gcc/d/expr.cc   |  2 ++
 gcc/d/types.cc  |  3 ++-
 gcc/testsuite/gdc.dg/torture/pr117002.d | 28 +
 4 files changed, 38 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gdc.dg/torture/pr117002.d

diff --git a/gcc/d/decl.cc b/gcc/d/decl.cc
index 9fcfc5681f8..250d148e56f 100644
--- a/gcc/d/decl.cc
+++ b/gcc/d/decl.cc
@@ -2393,6 +2393,12 @@ aggregate_initializer_decl (AggregateDeclaration *decl)
   SET_DECL_ALIGN (sinit, sd->alignment.get () * BITS_PER_UNIT);
   DECL_USER_ALIGN (sinit) = true;
 }
+  else if (sd == NULL)
+{
+  /* Alignment of class is determined its biggest field alignment.  */
+  SET_DECL_ALIGN (sinit, decl->alignsize * BITS_PER_UNIT);
+  DECL_USER_ALIGN (sinit) = true;
+}
 
   decl->sinit = sinit;
   return sinit;
diff --git a/gcc/d/expr.cc b/gcc/d/expr.cc
index 0415763b60d..46e65145791 100644
--- a/gcc/d/expr.cc
+++ b/gcc/d/expr.cc
@@ -2243,6 +2243,8 @@ public:
   storage class, then the instance is allocated on the stack
   rather than the heap or using the class specific allocator.  */
tree var = build_local_temp (TREE_TYPE (type));
+   SET_DECL_ALIGN (var, cd->alignsize * BITS_PER_UNIT);
+   DECL_USER_ALIGN (var) = 1;
new_call = build_nop (type, build_address (var));
setup_exp = modify_expr (var, aggregate_initializer_decl (cd));
  }
diff --git a/gcc/d/types.cc b/gcc/d/types.cc
index 98074f1fb68..ea62bc9d05e 100644
--- a/gcc/d/types.cc
+++ b/gcc/d/types.cc
@@ -1278,7 +1278,8 @@ public:
 build_type_decl (basetype, t->sym);
 set_visibility_for_decl (basetype, t->sym);
 apply_user_attributes (t->sym, basetype);
-finish_aggregate_type (t->sym->structsize, t->sym->alignsize, basetype);
+/* The underlying record type of classes are packed.  */
+finish_aggregate_type (t->sym->structsize, 1, basetype);
 
 /* Classes only live in memory, so always set the TREE_ADDRESSABLE bit.  */
 for (tree tv = basetype; tv != NULL_TREE; tv = TYPE_NEXT_VARIANT (tv))
diff --git a/gcc/testsuite/gdc.dg/torture/pr117002.d 
b/gcc/testsuite/gdc.dg/torture/pr117002.d
new file mode 100644
index 000..5b8c19e5b12
--- /dev/null
+++ b/gcc/testsuite/gdc.dg/torture/pr117002.d
@@ -0,0 +1,28 @@
+// { dg-do compile }
+// { dg-additional-options "-Warray-bounds" }
+extern(C++) class C117002
+{
+ubyte[4] not_multiple_of_8;
+}
+
+int pr117002a(void *p)
+{
+auto init = __traits(initSymbol, C117002);
+if (init.ptr + init.length <= p)
+return 1;
+return 0;
+}
+
+void pr117002b(void *p)
+{
+auto init = __traits(initSymbol, C117002);
+p[0 .. init.length] = init[];
+}
+
+void pr117002c()
+{
+scope var = new C117002;
+void *p = cast(void*)var;
+auto init = __traits(initSymbol, C117002);
+p[0 .. __traits(classInstanceSize, C117002)] = init[];
+}
-- 
2.43.0

Re: [PATCH] libstdc++: Make operator== for std::tuple convert to bool [PR119545]

[Jonathan Wakely]

On Mon, 31 Mar 2025 at 15:53, Tomasz Kaminski  wrote:
>
>
>
> On Mon, Mar 31, 2025 at 3:03 PM Jonathan Wakely  wrote:
>>
>> The boolean-testable requirements don't require the type to be copyable,
>> so we need to convert to bool before it might need to be copied.
>>
>> libstdc++-v3/ChangeLog:
>>
>> PR libstdc++/119545
>> * include/std/tuple (operator==): Convert comparison results to
>> bool.
>> * testsuite/20_util/tuple/comparison_operators/119545.cc: New
>> test.
>> ---
>>
>> Tested x86_64-linux.
>
> LGTM.
>>
>>
>> For the recent r15-7897-ge6e7b477bbdbfb change to fix a similar problem
>> I used an explicit return type on the lambda, because that was what the
>> LWG issue said to do. In this case an explicit return type would also
>> work, but I used an explicit conversion to bool on each element of the
>> pack expansion instead.
>
> boolean-testable requirements allows you to do that: a && b on 
> boolean-testable a, bis
> required to have the same behavior bool(a) && bool(b), so all good.
>
>>
>> That matches what is done elsewhere in 
>> for the tuple-like equality comparison, so I preferred to be locally
>> consistent.
>
> We also are no longer triggering lookup for opeartor&& on boolean-testable,
> which is required to find nothing, but still will be performed. So I think 
> converting
> to bool before applying &&/|| on boolean-testable is good idea.

Yes, that did occur to me. But I decided that all sane comparisons
return bool anyway so the benefit was mostly theoretical :-)

Thanks for the review.

Re: [PATCH v2 0/1] Cherry pick of patch for gcc-13 fixing PR119372

[Richard Sandiford]

Alfie Richards  writes:
> Minor update to add the PR label from Alex's feedback (thank you!).
>
> Regtested and bookstrapped for gcc-12 and gcc-13 (after applying
> r13-100-g3771486daa1e904ceae6f3e135b28e58af33849 to gcc-12).
>
> Alfie
>
> Andrew Carlotti (1):
>   aarch64: Use PAUTH instead of V8_3A in some places
>
>  gcc/config/aarch64/aarch64.cc | 6 +++---
>  gcc/config/aarch64/aarch64.md | 8 
>  2 files changed, 7 insertions(+), 7 deletions(-)

OK for both, thanks.

Richard

Re: [PATCH] ranger: Improve nonnull_if_nonzero attribute [PR117023]

[Andrew MacLeod]

On 3/29/25 20:54, Jeff Law wrote:



On 3/4/25 2:10 AM, Jakub Jelinek wrote:

Hi!

On Fri, Nov 22, 2024 at 07:25:23PM -0500, Andrew MacLeod wrote:
  I will shortly be submitting , and presumable committing, this 
patch as

part of a series to improve VRP time for 117467..

So it may be in place by the time you need it



On 11/18/24 09:31, Andrew MacLeod wrote:

Attached is a pre-approved patch which adds a range_query to the
inferred range mechanism.

The only change you will need to make is to replace "get_range_query
(cfun)->"  with "q->" which is passed in.

This regstraps on x86 without your patch, and I got as far as a
bootstrap with your patches..


Sorry for the delay.  Only recently the remaining patches have been
committed, so I'm getting back to this.

The current state of the trunk is that it handles constant arg2 (if 
it is

zero or non-zero) and punts on everything else.

I've changed get_range_query (cfun)-> to q-> but unfortunately the test
FAILs with it, while it improves the if (n >= 42) case where there is a
SSA_NAME for n - 10, it doesn't improve the if (n) case, so it feels 
like

it is querying just the global range rather than the local one from the
statement, because on the foo (b, n); statement which is guarded by 
if (n)

n should be provably [1, SIZE_MAX].

The patch still bootstraps/regtests on x86_64-linux and i686-linux
and improves at least something, so I guess I could just comment out 
part
of the testcase.  Any thoughts why this happens though?  And is that 
something

that can be improved for GCC 15 or should wait for GCC 16?

2025-03-04  Jakub Jelinek  
    Andrew MacLeod  

PR c/117023
* gimple-range-infer.cc (gimple_infer_range::gimple_infer_range):
For nonnull_if_nonzero attribute check also arg2 range if it doesn't
include zero and in that case call add_nonzero too.

* gcc.dg/tree-ssa/pr78154-2.c: New test.
Feels like it should defer to gcc-16.  But I'll defer (haha) to 
Jakub's judgment on whether or not fixing this up for gcc-15 is critical.


jeff



OK, I took a look.  Yes, VRP folding was still only using global ranges.

When VRP folds a statement it also adds any inferred ranges to the 
oracle, via a call to register_inferred_ranges:


  bool fold_stmt (gimple_stmt_iterator *gsi) override
  {
    bool ret = m_simplifier.simplify (gsi);
    if (!ret)
  ret = m_ranger->fold_stmt (gsi, follow_single_use_edges);
    m_ranger->register_inferred_ranges (gsi_stmt
   (*gsi));  Here.
    return ret;
  }

That is passed on by ranger to ranger's cache.  Ranger is a range-query 
object, but the cache is also implemented  as a *read-only* 
range-query.. it simply populates the cache as needed looking up 
values.  So when ranger passes it on:


   void
   gimple_ranger::register_inferred_ranges (gimple *s)
   {
  // First, export the LHS if it is a new global range.
  tree lhs = gimple_get_lhs (s);
  if (lhs)
    {
  value_range tmp (TREE_TYPE (lhs));
  if (range_of_stmt (tmp, s, lhs) && !tmp.varying_p ())
    set_range_info (lhs, tmp);
    }
  m_cache.apply_inferred_ranges (s); -   Passed on here.
   }

The cache looks at the statement, and actually registers any inferred 
ranges with the inferred range oracle.


void
ranger_cache::apply_inferred_ranges (gimple *s)
{
  bool update = true;

  basic_block bb = gimple_bb (s);
  gimple_infer_range infer(s); <-  DOH!   No range query provided.
  if (infer.num () == 0)
    return;
  // Register ranges with the infer oracle.
<...>

so. When VRP does the folding, we aren't picking up any context.   The 
fix is for the cache to pass itself in.. This will result in a read-only 
lookup which avoids any potential cycles, and as we are doing a DOM 
walk, should resolve the issues.  Patch is attached.  It fixes your 
testcase.



I am running it through a bootstrap/regression cycle (hasnt finished 
yet).   In theory it should be safe.  It is only your condition which 
actually uses the range query at the moment.  The op1_range and 
op2_range calls at the bottom of the function invoke it on constants 
only I think,  so they shouldn't be impacted.


If this works for you, I would suggest simply adding it to your patch as 
that is the only thing really needing it at the moment.


Andrew
From 7116177599a3bb907d21fe642a4bdcb401e1263b Mon Sep 17 00:00:00 2001
From: Andrew MacLeod 
Date: Mon, 31 Mar 2025 11:18:22 -0400
Subject: [PATCH 2/2] Use the current cache when creating inferred ranges.

Infer range processing was adjusted to allow a query to be specified,
but during VRP folding, ranger w3as not providing a query.  This results
in contextual ranges being missed.   Pass the cache in as the query
which provide a read-only query of the current state.

	* gimple-range-cache.cc (ranger_cache::apply_inferred_ranges): Pass
	'this' as the range-query to the inferred range constructor.
---

Re: [PATCH v3 14/19] Add reject_target_clone hook and filter target_clone versions.

[Alfie Richards]

Ah you're right, command line error on my part.

Thank you!

Alfie

On 29/03/2025 17:05, Yangyu Chen wrote:

Hi Alfie,

It appears that you've duplicated patch 14/19. The only difference
between them is the title, which replaces "and" with "in order to".
I think the latter version is what you intended.

Thanks,
Yangyu Chen

Re: [PATCH 1/2] libstdc++: Fix -Wstringop-overread warning in std::vector [PR114758]

[Tomasz Kaminski]

On Fri, Mar 28, 2025 at 9:53 PM Jonathan Wakely  wrote:

> As in r13-4393-gcca06f0d6d76b0 and a few other commits, we can avoid
> bogus warnings in std::vector by hoisting some loads to before the
> allocation that calls operator new. This means that the compiler has
> enough info to remove the dead branches that trigger bogus warnings.
>
> On trunk this is only needed with -fno-assume-sane-operators-new-delete
> but it will help on the branches where that option doesn't exist.
>
> libstdc++-v3/ChangeLog:
>
> PR libstdc++/114758
> * include/bits/vector.tcc (vector::_M_fill_insert):
> Hoist loads of begin() and end() before allocation.
> * testsuite/23_containers/vector/bool/capacity/114758.cc: New
> test.
> ---
>
> Tested x86_64-linux.
>
LGTM

>
>  libstdc++-v3/include/bits/vector.tcc   |  5 +++--
>  .../23_containers/vector/bool/capacity/114758.cc   | 10 ++
>  2 files changed, 13 insertions(+), 2 deletions(-)
>  create mode 100644
> libstdc++-v3/testsuite/23_containers/vector/bool/capacity/114758.cc
>
> diff --git a/libstdc++-v3/include/bits/vector.tcc
> b/libstdc++-v3/include/bits/vector.tcc
> index f197278d52e..29aa63e4742 100644
> --- a/libstdc++-v3/include/bits/vector.tcc
> +++ b/libstdc++-v3/include/bits/vector.tcc
> @@ -1134,11 +1134,12 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
> {
>   const size_type __len =
> _M_check_len(__n, "vector::_M_fill_insert");
> + iterator __begin = begin(), __end = end();
>   _Bit_pointer __q = this->_M_allocate(__len);
>   iterator __start(std::__addressof(*__q), 0);
> - iterator __i = _M_copy_aligned(begin(), __position, __start);
> + iterator __i = _M_copy_aligned(__begin, __position, __start);
>   std::fill(__i, __i + difference_type(__n), __x);
> - iterator __finish = std::copy(__position, end(),
> + iterator __finish = std::copy(__position, __end,
> __i + difference_type(__n));
>   this->_M_deallocate();
>   this->_M_impl._M_end_of_storage = __q + _S_nword(__len);
> diff --git
> a/libstdc++-v3/testsuite/23_containers/vector/bool/capacity/114758.cc
> b/libstdc++-v3/testsuite/23_containers/vector/bool/capacity/114758.cc
> new file mode 100644
> index 000..d069db86bc6
> --- /dev/null
> +++ b/libstdc++-v3/testsuite/23_containers/vector/bool/capacity/114758.cc
> @@ -0,0 +1,10 @@
> +// { dg-options "-O3 -Werror=stringop-overread
> -fno-assume-sane-operators-new-delete" }
> +// { dg-do compile }
> +
> +#include 
> +
> +void pr114758(std::vector& v)
> +{
> +  v.resize(3);
> +  v = std::vector(3, false);
> +}
> --
> 2.49.0
>
>

Re: Warning/error typo bug: "couldn't deduce template parameter"

[Jakub Jelinek]

Jakub
--- Begin Message ---
On Mon, Mar 31, 2025 at 02:04:14PM +0300, Roman Kovalev wrote:
> Thanks for your reply. But I get warning: could»t deduce template parameter
> «muted»

In which locale?
That would be a translation error.
The translations can translate the quote characters ( ` and ' ).
If they don't, GCC uses ' and ' for non-UTF-8 locales and ‘ and ’
for UTF-8 locales.
And %' uses the closing quote character, whatever that is.
As documented, %' should be only used in untranslated messages,
translations should use their quotes or whatever that is appropriate.

So, either you use a language which translates the quotes to « and »
(da, de, ru, uk) or puts some space around those as well (fr) and that
language incorrectly uses %' in the translated strings, or it failed
to translate that message.
The first should be fixed by never using %' in msgstr (at least for
languages which do translate the quotes), the second by translating
the message.

Jakub
--- End Message ---

Re: [PATCH v3 05/19] Update is_function_default_version to work with target_version.

[Alfie Richards]

Hello,

The function is only used in i386 and rs6000 target specific code (which 
don't support the `target_version` attribute) so would have no effect on 
its own.


Additionally, when it became clear this ACLE compliance series wouldn't 
make GCC 15 we have added a warning for Aarch64 in gcc 14 and 15 to 
inform users that FMV behaviour is in beta and will change (commit 
e5798872281).


Alfie

On 29/03/2025 17:05, Yangyu Chen wrote:




On 27 Mar 2025, at 16:45, Alfie Richards  wrote:


Notably this respects target_version semantics where an unannotated
function can be the default version.

gcc/ChangeLog:

* attribs.cc (is_function_default_version): Add target_version logic.
---
gcc/attribs.cc | 27 ---
1 file changed, 20 insertions(+), 7 deletions(-)




Should we have this for GCC 15?

Re: [PATCH 1/2] GCN, libstdc++: '#define _GLIBCXX_USE_WEAK_REF 0' [PR119369]

[Jonathan Wakely]

On Mon, 31 Mar 2025 at 10:50, Thomas Schwinge  wrote:
>
> This fixes a few hundreds of compilation/linking FAILs (similar to PR69506),
> where the GCN/LLVM 'ld' reported:
>
> ld: error: relocation R_AMDGPU_REL32_LO cannot be used against symbol 
> '_ZGTtnam'; recompile with -fPIC
> >>> defined in 
> [...]/amdgcn-amdhsa/./libstdc++-v3/src/.libs/libstdc++.a(cow-stdexcept.o)
> >>> referenced by cow-stdexcept.cc:259 
> ([...]/libstdc++-v3/src/c++11/cow-stdexcept.cc:259)
> >>>   
> cow-stdexcept.o:(_txnal_cow_string_C1_for_exceptions(void*, char const*, 
> void*)) in archive [...]/amdgcn-amdhsa/./libstdc++-v3/src/.libs/libstdc++.a
>
> ld: error: relocation R_AMDGPU_REL32_HI cannot be used against symbol 
> '_ZGTtnam'; recompile with -fPIC
> >>> defined in 
> [...]/amdgcn-amdhsa/./libstdc++-v3/src/.libs/libstdc++.a(cow-stdexcept.o)
> >>> referenced by cow-stdexcept.cc:259 
> ([...]/source-gcc/libstdc++-v3/src/c++11/cow-stdexcept.cc:259)
> >>>   
> cow-stdexcept.o:(_txnal_cow_string_C1_for_exceptions(void*, char const*, 
> void*)) in archive [...]/amdgcn-amdhsa/./libstdc++-v3/src/.libs/libstdc++.a
>
> [...]
>
> ..., which is:
>
> $ c++filt _ZGTtnam
> transaction clone for operator new[](unsigned long)
>
> ..., and similarly for other libitm symbols.
>
> However, the affected test cases, if applicable, then run into execution test
> FAILs, due to PR119369
> "GCN: weak undefined symbols -> execution test FAIL, 
> 'HSA_STATUS_ERROR_VARIABLE_UNDEFINED'".
>
> PR target/119369
> libstdc++-v3/
> * config/cpu/gcn/cpu_defines.h: New.
> * configure.host [GCN] (cpu_defines_dir): Point to it.


OK for trunk, thanks.

> ---
>  libstdc++-v3/config/cpu/gcn/cpu_defines.h | 55 +++
>  libstdc++-v3/configure.host   |  3 ++
>  2 files changed, 58 insertions(+)
>  create mode 100644 libstdc++-v3/config/cpu/gcn/cpu_defines.h
>
> diff --git a/libstdc++-v3/config/cpu/gcn/cpu_defines.h 
> b/libstdc++-v3/config/cpu/gcn/cpu_defines.h
> new file mode 100644
> index ..028bfb0ccff1
> --- /dev/null
> +++ b/libstdc++-v3/config/cpu/gcn/cpu_defines.h
> @@ -0,0 +1,55 @@
> +// Specific definitions for GCN platforms  -*- C++ -*-
> +
> +// Copyright (C) 2025 Free Software Foundation, Inc.
> +//
> +// This file is part of the GNU ISO C++ Library.  This library is free
> +// software; you can redistribute it and/or modify it under the
> +// terms of the GNU General Public License as published by the
> +// Free Software Foundation; either version 3, or (at your option)
> +// any later version.
> +
> +// This library is distributed in the hope that it will be useful,
> +// but WITHOUT ANY WARRANTY; without even the implied warranty of
> +// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> +// GNU General Public License for more details.
> +
> +// Under Section 7 of GPL version 3, you are granted additional
> +// permissions described in the GCC Runtime Library Exception, version
> +// 3.1, as published by the Free Software Foundation.
> +
> +// You should have received a copy of the GNU General Public License and
> +// a copy of the GCC Runtime Library Exception along with this program;
> +// see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
> +// .
> +
> +/** @file bits/cpu_defines.h
> + *  This is an internal header file, included by other library headers.
> + *  Do not attempt to use it directly. @headername{iosfwd}
> + */
> +
> +#ifndef _GLIBCXX_CPU_DEFINES
> +#define _GLIBCXX_CPU_DEFINES 1
> +
> +/* GCN appears to run into issues similar to PR69506:
> +
> +   ld: error: relocation R_AMDGPU_REL32_LO cannot be used against symbol 
> '_ZGTtnam'; recompile with -fPIC
> +   >>> defined in 
> [...]/amdgcn-amdhsa/./libstdc++-v3/src/.libs/libstdc++.a(cow-stdexcept.o)
> +   >>> referenced by cow-stdexcept.cc:259 
> ([...]/libstdc++-v3/src/c++11/cow-stdexcept.cc:259)
> +   >>>   
> cow-stdexcept.o:(_txnal_cow_string_C1_for_exceptions(void*, char const*, 
> void*)) in archive [...]/amdgcn-amdhsa/./libstdc++-v3/src/.libs/libstdc++.a
> +
> +   ld: error: relocation R_AMDGPU_REL32_HI cannot be used against symbol 
> '_ZGTtnam'; recompile with -fPIC
> +   >>> defined in 
> [...]/amdgcn-amdhsa/./libstdc++-v3/src/.libs/libstdc++.a(cow-stdexcept.o)
> +   >>> referenced by cow-stdexcept.cc:259 
> ([...]/source-gcc/libstdc++-v3/src/c++11/cow-stdexcept.cc:259)
> +   >>>   
> cow-stdexcept.o:(_txnal_cow_string_C1_for_exceptions(void*, char const*, 
> void*)) in archive [...]/amdgcn-amdhsa/./libstdc++-v3/src/.libs/libstdc++.a
> +
> +   [...]
> +
> +   ..., which is:
> +
> +   $ c++filt _ZGTtnam
> +   transaction clone for operator new[](unsigned long)
> +
> +   ..., and similarly for other libitm symbols.  See PR119369.  */
> +#define _GLIBCXX_USE_WEAK_REF 0
> +
> +#endif
> diff --git a/libstdc++-v3/

Re: [PATCH] gcc_release: Generate srcdir extras/infos/man pages from all FEs [PR119510]

[Richard Biener]

On Sat, 29 Mar 2025, Jakub Jelinek wrote:

> Hi!
> 
> Enabling cobol explicitly (at least unconditionally) in gcc_release has the
> disadvantage that the script no longer works for GCC <= 14, I think it would
> be better to keep it working for all still supported release branches.
> 
> And as mentioned in the PR, we still don't generate the
> --enable-generated-files-in-srcdir extras/infos/man pages for languages
> not actually enabled.
> Using --enable-languages=all would mean gcc_release takes far longer and
> more importantly, various FEs have extra dependencies, Ada requires a
> working Ada compiler (furthermore not newer than the gcc release, so if
> I run this on a system with say GCC 15 installed, even when I have Ada
> installed, I won't be able to gcc_release GCC 14 or 13 etc.), D working D
> compiler, Go takes a long time to build libgo.
> 
> So, the following patch instead takes similar approach to what
> make regenerate-opt-urls
> takes, it generates stuff even for non-enabled languages.
> For most languages it works just fine and is a matter of say for cobol
> make cobol.srcextra cobol.srcinfo cobol.srcman
> The only problem is Modula 2, which has some messed up dependencies and
> when the FE is not enabled, this will try to build the whole FE as well and
> fail.  I think it would be useful to fix that but at least before that is
> fixed on the trunk and all release branches, the following patch just
> conditionally (so that it works even for GCC 12 which doesn't have Modula 2)
> enables also m2.
> 
> And lastly, libffi seems to be only enabled for Go (and maybe D), I'd prefer
> not to enable those languages for the reasons stated above, so if we really
> need libffi.info in release tarballs (despite libffi being used only as
> implementation detail and not installed), the patch just generates it by
> hand.

Do we even install libffi.info?  I can't find any handling of it in my
spec files building GCC with go enabled.

> Tested on x86_64-linux, ok for trunk?

OK.

Richard.

> 2025-03-29  Jakub Jelinek  
> 
>   PR other/119510
>   * gcc_release: Use --enable-languages=c,c++,lto and if m2 is available,
>   with,m2 appended to that.  Check for all possible languages and run
>   make $lang.srcextra $lang.srcinfo $lang.srcman for those.  Add
>   libffi/doc/libffi.info.
> 
> --- maintainer-scripts/gcc_release.jj 2025-03-28 15:44:23.714526549 +0100
> +++ maintainer-scripts/gcc_release2025-03-28 19:37:33.955981486 +0100
> @@ -266,10 +266,28 @@ EOF
>   '' | 0* | *[!0-9]*) num_cpus=1;;
>esac
>  fi
> +enable_langs=c,c++,lto
> +if [ -f ${SOURCE_DIRECTORY}/gcc/m2/Make-lang.in ]; then
> +  enable_langs=$enable_langs,m2
> +fi
>  contrib/gcc_build -d ${SOURCE_DIRECTORY} -o ${OBJECT_DIRECTORY} \
> -  -c "--enable-languages=default,cobol 
> --enable-generated-files-in-srcdir --disable-multilib" \
> +  -c "--enable-languages=$enable_langs 
> --enable-generated-files-in-srcdir --disable-multilib" \
>-m "-j$num_cpus" build || \
>error "Could not rebuild GCC"
> +cd ${OBJECT_DIRECTORY}/gcc
> +all_languages=`sed -n -e '/"all_languages"/s/^.*=//p' config.status \
> +| sed -e 's/"//g'`
> +for lang in $all_languages; do
> +  make $lang.srcextra $lang.srcinfo $lang.srcman || \
> + error "Could not build GCC $lang source extras"
> +done
> +if [ -d ${SOURCE_DIRECTORY}/libffi/doc ]; then
> +  makeinfo --split-size=500  -I ${SOURCE_DIRECTORY}/gcc/doc/include \
> + -I ${SOURCE_DIRECTORY}/libffi/doc/ -o 
> ${SOURCE_DIRECTORY}/libffi/doc/libffi.info \
> + ${SOURCE_DIRECTORY}/libffi/doc/libffi.texi || \
> + error "Could not build libffi.info"
> +fi
> +cd ${SOURCE_DIRECTORY}
>fi
>  
># Move message catalogs to source directory.
> 
>   Jakub
> 
> 

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

C++ patch ping (Re: [PATCH] c++, libcpp: Allow some left shifts in the preprocessor [PR119391])

[Jakub Jelinek]

Hi!

I'd like to ping the
https://gcc.gnu.org/pipermail/gcc-patches/2025-March/678863.html
patch.

Thanks.

On Sat, Mar 22, 2025 at 01:33:51AM +0100, Jakub Jelinek wrote:
> The libcpp left shift handling implements (partially) the C99-C23
> wording where shifts are UB if shift count is negative, or too large,
> or shifting left a negative value or shifting left non-negative value
> results in something not representable in the result type (in the
> preprocessor case that is intmax_t).
> libcpp actually implements left shift by negative count as right shifts
> by negation of the count and similarly right shifts by negative count
> as left shifts by negation (not ok), sets overflow for too large shift
> count (ok), doesn't check for negative values on left shift (not ok)
> and checks correctly for the non-representable ones otherwise (ok).
> 
> Now, C++11 to C++17 has different behavior, whereas in C99-C23 1 << 63
> in preprocessor is invalid, in C++11-17 it is valid, but 3 << 63 is
> not.  The wording is that left shift of negative value is UB (like in C)
> and signed non-negative left shift is UB if the result isn't representable
> in corresponding unsigned type (so uintmax_t for libcpp).
> 
> And then C++20 and newer says all left shifts are well defined with the
> exception of bad shift counts.
> 
> In -fsanitize=undefined we handle these by
>   /* For signed x << y, in C99 and later, the following:
>  (unsigned) x >> (uprecm1 - y)
>  if non-zero, is undefined.  */
> and
>   /* For signed x << y, in C++11 to C++17, the following:
>  x < 0 || ((unsigned) x >> (uprecm1 - y))
>  if > 1, is undefined.  */
> 
> Now, we are late in GCC 15 development, so I think making the preprocessor
> more strict than it is now is undesirable, so will defer setting overflow
> flag for the shifts by negative count, or shifts by negative value left.
> 
> The following patch just makes some previously incorrectly rejected or
> warned cases valid for C++11-17 and even more for C++20 and later.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> 
> 2025-03-22  Jakub Jelinek  
> 
>   PR preprocessor/119391
>   * expr.cc (num_lshift): Add pfile argument.  Don't set num.overflow
>   for !num.unsignedp in C++20 or later unless n >= precision.  For
>   C++11 to C++17 set it if orig >> (precision - 1 - n) as logical
>   shift results in value > 1.
>   (num_binary_op): Pass pfile to num_lshift.
>   (num_div_op): Likewise.
> 
>   * g++.dg/cpp/pr119391.C: New test.

Jakub

Re: [PATCH v2] aarch64, Darwin: Initial implementation of Apple cores [PR113257].

[Kyrylo Tkachov]

Hi Iain,

> On 22 Mar 2025, at 15:31, Iain Sandoe  wrote:
> 
> 0. Sorry this has taken some time to close off; partly because of waiting
>   for input, but mostly that I've been stretched with other work.
> 1. As per the commit message, the apparent non-conformance with 8.5/6
>   because FEAT_SPECRES returns 0, is a result of the query operating
>   at user priv.  The cores are confirmed to support this for priv.
>   code.
> 2. I added entries for the apple-m1,2,3 cores in invoke.texi.
> 3. Following Andrew's suggestion and with some measurements by Tamar
>   and me, figured out the LITTLE.big chip ids (at least for a sub-
>   set).
> 
> This has been in use for a while on aarch64-darwin branches and I've
> checked manually that it gives the right .arch lines on cfarm185.
> 
> OK for trunk? (if so, when?)
> thanks
> Iain
> 
> --- 8< ---
> 
> After discussion with the open source support team at Apple, we have
> established that the cores conform to the 8.5 and 8.6 requirements.
> One of the mandatory features (FEAT_SPECRES) is not exposed (or
> available) in user-space code but is supported for privileged code.
> 
> The values for chip IDs and the LITTLE.big variants have been taken
> from lists in the XNU and LLVM sources.
> 
> PR target/113257
> 
> gcc/ChangeLog:
> 
> * config/aarch64/aarch64-cores.def (AARCH64_CORE): Add Apple-a12,
> Apple-M1, Apple-M2, Apple-M3 with expanded names to allow for the
> LITTLE.big versions.
> * config/aarch64/aarch64-tune.md: Regenerate.
> * doc/invoke.texi: Add apple-m1,2 and 3 cores to the ones listed
> for arch and tune selections.
> 
> Signed-off-by: Iain Sandoe 
> ---
> gcc/config/aarch64/aarch64-cores.def | 16 
> gcc/config/aarch64/aarch64-tune.md   |  2 +-
> gcc/doc/invoke.texi  |  5 +++--
> 3 files changed, 20 insertions(+), 3 deletions(-)
> 
> diff --git a/gcc/config/aarch64/aarch64-cores.def 
> b/gcc/config/aarch64/aarch64-cores.def
> index 0e22d72976e..7f204fd0ac9 100644
> --- a/gcc/config/aarch64/aarch64-cores.def
> +++ b/gcc/config/aarch64/aarch64-cores.def
> @@ -173,6 +173,22 @@ AARCH64_CORE("cortex-a76.cortex-a55",  
> cortexa76cortexa55, cortexa53, V8_2A,  (F
> AARCH64_CORE("cortex-r82", cortexr82, cortexa53, V8R, (), cortexa53, 0x41, 
> 0xd15, -1)
> AARCH64_CORE("cortex-r82ae", cortexr82ae, cortexa53, V8R, (), cortexa53, 
> 0x41, 0xd14, -1)
> 
> +/* Apple (A12 and M) cores.
> +   Known part numbers as listed in other public sources.
> +   Placeholders for schedulers, generic_armv8_a for costs.
> +   A12 seems mostly 8.3, M1 is 8.5 without BTI, M2 and M3 are 8.6
> +   From measurements made so far the odd-number core IDs are performance.  */
> +AARCH64_CORE("apple-a12", applea12, cortexa53, V8_3A,  (), generic_armv8_a, 
> 0x61, 0x12, -1)
> +AARCH64_CORE("apple-m1", applem1_0, cortexa57, V8_5A,  (), generic_armv8_a, 
> 0x61, AARCH64_BIG_LITTLE (0x21, 0x20), -1)
> +AARCH64_CORE("apple-m1", applem1_1, cortexa57, V8_5A,  (), generic_armv8_a, 
> 0x61, AARCH64_BIG_LITTLE (0x23, 0x22), -1)
> +AARCH64_CORE("apple-m1", applem1_2, cortexa57, V8_5A,  (), generic_armv8_a, 
> 0x61, AARCH64_BIG_LITTLE (0x25, 0x24), -1)
> +AARCH64_CORE("apple-m1", applem1_3, cortexa57, V8_5A,  (), generic_armv8_a, 
> 0x61, AARCH64_BIG_LITTLE (0x29, 0x28), -1)
> +AARCH64_CORE("apple-m2", applem2_0, cortexa57, V8_6A,  (), generic_armv8_a, 
> 0x61, AARCH64_BIG_LITTLE (0x31, 0x30), -1)
> +AARCH64_CORE("apple-m2", applem2_1, cortexa57, V8_6A,  (), generic_armv8_a, 
> 0x61, AARCH64_BIG_LITTLE (0x33, 0x32), -1)
> +AARCH64_CORE("apple-m2", applem2_2, cortexa57, V8_6A,  (), generic_armv8_a, 
> 0x61, AARCH64_BIG_LITTLE (0x35, 0x34), -1)
> +AARCH64_CORE("apple-m2", applem2_3, cortexa57, V8_6A,  (), generic_armv8_a, 
> 0x61, AARCH64_BIG_LITTLE (0x39, 0x38), -1)
> +AARCH64_CORE("apple-m3", applem3_0, cortexa57, V8_6A,  (), generic_armv8_a, 
> 0x61, AARCH64_BIG_LITTLE (0x49, 0x48), -1)

I don’t think we have precedent of different MIDR part numbers resolving to the 
same -mcpu string, but I think it should all work as expected.
As long as you and Tamar are happy with the feature set here no objections from 
me.
Looks ok to me for GCC 15 with a documentation comment below…

> +
> /* Armv9.0-A Architecture Processors.  */
> 
> /* Arm ('A') cores. */
> diff --git a/gcc/config/aarch64/aarch64-tune.md 
> b/gcc/config/aarch64/aarch64-tune.md
> index 56a914f12b9..982074c2c21 100644
> --- a/gcc/config/aarch64/aarch64-tune.md
> +++ b/gcc/config/aarch64/aarch64-tune.md
> @@ -1,5 +1,5 @@
> ;; -*- buffer-read-only: t -*-
> ;; Generated automatically by gentune.sh from aarch64-cores.def
> (define_attr "tune"
> - 
> "cortexa34,cortexa35,cortexa53,cortexa57,cortexa72,cortexa73,thunderx,thunderxt88,thunderxt88p1,octeontx,octeontxt81,octeontxt83,thunderxt81,thunderxt83,ampere1,ampere1a,ampere1b,emag,xgene1,falkor,qdf24xx,exynosm1,phecda,thunderx2t99p1,vulcan,thunderx2t99,cortexa55,cortexa75,cortexa76,cortexa76ae,cortexa77,cortexa78,cortexa78ae,cortexa78c,cortexa65,cortexa65ae,cortexx1,co

Re: Warning/error typo bug: "couldn't deduce template parameter"

[Jakub Jelinek]

On Mon, Mar 31, 2025 at 01:35:40PM +0300, Roman Kovalev wrote:
> Hello! I found a typo in the error/warning output line. Sorry if I messed
> up the order of submitting edits.

Thius is incorrect.
%' is supported escape code for apostrophes:
   %': apostrophe (should only be used in untranslated messages;
   translations should use appropriate punctuation directly).
It can either print ' or ’ (U+2019) depending on capabilities of the
terminal.

Furthermore, even if it was a bug (which it is not, we never patch *.po
files like that, just regenerate (eventually) gcc.pot and let the
translation project update their files.

Jakub

[ping][PATCH v2] aarch64, Darwin: Initial implementation of Apple cores [PR113257].

[Iain Sandoe]

I realise this is probably not #1 priority - but it would be nice to have in 
gcc-15.
thanks
iain

> On 22 Mar 2025, at 14:31, Iain Sandoe  wrote:
> 
> 0. Sorry this has taken some time to close off; partly because of waiting
>   for input, but mostly that I've been stretched with other work.
> 1. As per the commit message, the apparent non-conformance with 8.5/6
>   because FEAT_SPECRES returns 0, is a result of the query operating
>   at user priv.  The cores are confirmed to support this for priv.
>   code.
> 2. I added entries for the apple-m1,2,3 cores in invoke.texi.
> 3. Following Andrew's suggestion and with some measurements by Tamar
>   and me, figured out the LITTLE.big chip ids (at least for a sub-
>   set).
> 
> This has been in use for a while on aarch64-darwin branches and I've
> checked manually that it gives the right .arch lines on cfarm185.
> 
> OK for trunk? (if so, when?)
> thanks
> Iain
> 
> --- 8< ---
> 
> After discussion with the open source support team at Apple, we have
> established that the cores conform to the 8.5 and 8.6 requirements.
> One of the mandatory features (FEAT_SPECRES) is not exposed (or
> available) in user-space code but is supported for privileged code.
> 
> The values for chip IDs and the LITTLE.big variants have been taken
> from lists in the XNU and LLVM sources.
> 
>   PR target/113257
> 
> gcc/ChangeLog:
> 
>   * config/aarch64/aarch64-cores.def (AARCH64_CORE): Add Apple-a12,
>   Apple-M1, Apple-M2, Apple-M3 with expanded names to allow for the
>   LITTLE.big versions.
>   * config/aarch64/aarch64-tune.md: Regenerate.
>   * doc/invoke.texi: Add apple-m1,2 and 3 cores to the ones listed
>   for arch and tune selections.
> 
> Signed-off-by: Iain Sandoe 
> ---
> gcc/config/aarch64/aarch64-cores.def | 16 
> gcc/config/aarch64/aarch64-tune.md   |  2 +-
> gcc/doc/invoke.texi  |  5 +++--
> 3 files changed, 20 insertions(+), 3 deletions(-)
> 
> diff --git a/gcc/config/aarch64/aarch64-cores.def 
> b/gcc/config/aarch64/aarch64-cores.def
> index 0e22d72976e..7f204fd0ac9 100644
> --- a/gcc/config/aarch64/aarch64-cores.def
> +++ b/gcc/config/aarch64/aarch64-cores.def
> @@ -173,6 +173,22 @@ AARCH64_CORE("cortex-a76.cortex-a55",  
> cortexa76cortexa55, cortexa53, V8_2A,  (F
> AARCH64_CORE("cortex-r82", cortexr82, cortexa53, V8R, (), cortexa53, 0x41, 
> 0xd15, -1)
> AARCH64_CORE("cortex-r82ae", cortexr82ae, cortexa53, V8R, (), cortexa53, 
> 0x41, 0xd14, -1)
> 
> +/* Apple (A12 and M) cores.
> +   Known part numbers as listed in other public sources.
> +   Placeholders for schedulers, generic_armv8_a for costs.
> +   A12 seems mostly 8.3, M1 is 8.5 without BTI, M2 and M3 are 8.6
> +   From measurements made so far the odd-number core IDs are performance.  */
> +AARCH64_CORE("apple-a12", applea12, cortexa53, V8_3A,  (), generic_armv8_a, 
> 0x61, 0x12, -1)
> +AARCH64_CORE("apple-m1", applem1_0, cortexa57, V8_5A,  (), generic_armv8_a, 
> 0x61, AARCH64_BIG_LITTLE (0x21, 0x20), -1)
> +AARCH64_CORE("apple-m1", applem1_1, cortexa57, V8_5A,  (), generic_armv8_a, 
> 0x61, AARCH64_BIG_LITTLE (0x23, 0x22), -1)
> +AARCH64_CORE("apple-m1", applem1_2, cortexa57, V8_5A,  (), generic_armv8_a, 
> 0x61, AARCH64_BIG_LITTLE (0x25, 0x24), -1)
> +AARCH64_CORE("apple-m1", applem1_3, cortexa57, V8_5A,  (), generic_armv8_a, 
> 0x61, AARCH64_BIG_LITTLE (0x29, 0x28), -1)
> +AARCH64_CORE("apple-m2", applem2_0, cortexa57, V8_6A,  (), generic_armv8_a, 
> 0x61, AARCH64_BIG_LITTLE (0x31, 0x30), -1)
> +AARCH64_CORE("apple-m2", applem2_1, cortexa57, V8_6A,  (), generic_armv8_a, 
> 0x61, AARCH64_BIG_LITTLE (0x33, 0x32), -1)
> +AARCH64_CORE("apple-m2", applem2_2, cortexa57, V8_6A,  (), generic_armv8_a, 
> 0x61, AARCH64_BIG_LITTLE (0x35, 0x34), -1)
> +AARCH64_CORE("apple-m2", applem2_3, cortexa57, V8_6A,  (), generic_armv8_a, 
> 0x61, AARCH64_BIG_LITTLE (0x39, 0x38), -1)
> +AARCH64_CORE("apple-m3", applem3_0, cortexa57, V8_6A,  (), generic_armv8_a, 
> 0x61, AARCH64_BIG_LITTLE (0x49, 0x48), -1)
> +
> /* Armv9.0-A Architecture Processors.  */
> 
> /* Arm ('A') cores. */
> diff --git a/gcc/config/aarch64/aarch64-tune.md 
> b/gcc/config/aarch64/aarch64-tune.md
> index 56a914f12b9..982074c2c21 100644
> --- a/gcc/config/aarch64/aarch64-tune.md
> +++ b/gcc/config/aarch64/aarch64-tune.md
> @@ -1,5 +1,5 @@
> ;; -*- buffer-read-only: t -*-
> ;; Generated automatically by gentune.sh from aarch64-cores.def
> (define_attr "tune"
> - 
> "cortexa34,cortexa35,cortexa53,cortexa57,cortexa72,cortexa73,thunderx,thunderxt88,thunderxt88p1,octeontx,octeontxt81,octeontxt83,thunderxt81,thunderxt83,ampere1,ampere1a,ampere1b,emag,xgene1,falkor,qdf24xx,exynosm1,phecda,thunderx2t99p1,vulcan,thunderx2t99,cortexa55,cortexa75,cortexa76,cortexa76ae,cortexa77,cortexa78,cortexa78ae,cortexa78c,cortexa65,cortexa65ae,cortexx1,cortexx1c,neoversen1,ares,neoversee1,octeontx2,octeontx2t98,octeontx2t96,octeontx2t93,octeontx2f95,octeontx2f95n,octeontx2f95mm,a64fx,fujitsu_monaka,tsv110,thun

Re: [PATCH] PR middle-end/119442: expr.cc: Fix vec_duplicate into vector boolean modes

[Mark Wielaard]

On Mon, 2025-03-31 at 09:12 +, Kyrylo Tkachov wrote:
> 
> > On 31 Mar 2025, at 09:43, Richard Biener  wrote:
> > 
> > On Mon, Mar 31, 2025 at 9:41 AM Richard Biener
> >  wrote:
> > > 
> > > On Mon, Mar 31, 2025 at 9:36 AM Kyrylo Tkachov  
> > > wrote:
> > > > 
> > > > Ping.
> > > 
> > > Can you reference the patch please?  I'll note your mails have the 
> > > tendency to
> > > end up in my spam folder (which is auto-purged after some time).  Probably
> > > a setup issue at nvidias side.
> > 
> > Found it.  Your mails fail both DKIM and DMARC so gmail thinks you are
> > phishing me.
> 
> Thanks for the review. Sorry about that, I think Mark had raised a BZ issue 
> somewhere tracking this, Mark do you recall something like that?
> I’m afraid I don’t know much about email workings to address this, but if 
> there’s more of a writeup on the issue I can forward it to someone
> internally who can help…

I also thought I had a specific bug about that. But all I can find is
https://sourceware.org/bugzilla/show_bug.cgi?id=31905 which just
suggests turning on From rewriting again, which I assume is not what we
really want.

Note that you can find how the message was received in
inbox.sourceware.org I believe your message was:
https://inbox.sourceware.org/gcc-patches/da6f5115-a6c3-4c3c-8299-4660d723c...@nvidia.com/raw
Which does show it passed dmarc at least when it came in.
If we have someone with the message as received we can compare if it
still passed dmarc or if something about the message was changed that
made it fail.

Cheers,

Mark

[ping] [PATCH] libgcobol: C++-ify the configuration steps.

[Iain Sandoe]

Hi folks

> On 24 Mar 2025, at 17:15, Iain Sandoe  wrote:
> 
>> On 24 Mar 2025, at 16:41, Iain Sandoe  wrote:
>>> On 24 Mar 2025, at 16:38, Robert Dubner  wrote:
>>> 
>>> How about you create the new patch and just edit out the regenerated
>>> configure before sending the e-mail?  Typing "autoreconf" isn't hard.
>> 
>> OK. I can do that (historically that is what we always have done, but now we
>> have CI infrastructure and that does not (yet) know how to deal with partial
>> patches).  In this case I don’t think the 700k of generated output is 
>> helpful…
>> 
>> Will do soon - I’m just rebasing on the updates fomr approved patches and
>> the rust set…
> 
> .. that’s done, based onto r15-8868-g57fdc97dac1453
> * edited out the regenerated file diffs
> * retesting for good measure
> * pushed “master-wip-cobol-s” to GH in case the hand-editting messes up the
>  patch,
> 
> OK for trunk, (assuming that the re-tests pass)
> my testing is bootstrap on x86_64 & aarch64 linux + existing testcases.
> (plus x86_64 darwin with additional patches needed to get it to build)
> 
> thanks
> Iain
> 
> <0001-libgcobol-C-ify-the-configuration-steps.patch>

There is a rebased (onto today’s trunk) version of this in 
https://github.com/iains/gcc-git/tree/master-wip-cobol-posted
in case that helps
thanks
Iain

RE: [gcc-wwwdocs PATCH] gcc-14/15: Mention recent change for Intel x86_64

[Jiang, Haochen]

> From: Gerald Pfeifer 
> Sent: Sunday, March 30, 2025 5:23 AM
> 
> On Mon, 24 Mar 2025, Haochen Jiang wrote:
> > Mention AVX10.1 option changes, revise AVX10.2 option and mention
> > APX_F new feature in GCC 15.
> > ---
> 
> >New ISA extension support for Intel AVX10.1 was added.
> > -  AVX10.1 intrinsics are available via the -mavx10.1 or
> > -  -mavx10.1-256 compiler switch with 256-bit vector size
> > -  support. 512-bit vector size support for AVX10.1 intrinsics are
> > -  available via the -mavx10.1-512 compiler switch.
> > +  AVX10.1 intrinsics are available via the -mavx10.1-256
> > +  compiler switch with 256-bit vector size support. 512-bit vector size
> > +  support for AVX10.1 intrinsics are available via the
> > +  -mavx10.1-512 compiler switch. -
> mavx10.1
> > +  enables AVX10.1 intrinsics with 256-bit vector size support in
> > + GCC 14.1
> 
> I suggest to just use "256-bit vector support", dropping the word "size", and
> similar for the 512-bit case.
> 
> > +  and GCC 14.2. Since GCC 14.3, it enables AVX10.1 intrinsics with 
> > 512-bit
> > +  vector size support. Since GCC 14.3, using -mavx10.1 
> > will
> > +  emit a warning due to this behavior change.
> 
> How about streamlining this to
> 
>   "Since GCC 14.3, it enables AVX10.1 intrinsics with 512-bit vector
>   support (and emits a warning due to this behavior change)."
> 
> ?
> 
> > +  compiler switch. MOVRS vector intrinsics are available via
> > +  the -mmovrs -mavx10.2 compiler switch.
> 
> Technically this is not one switch, so "switches"?
> 
> > +AMX-FP8, AMX-MOVRS, AMX-TF32, AMX-TRANSPOSE, APX_F, AVX10.2,
> AVX-IFMA,
> > +AVX-NE-CONVERT, AVX-VNNI-INT16, AVX-VNNI-INT8, CMPccXADD,
> MOVRS, SHA512,
> > +SM3, SM4 and USER_MSR ISA extensions.
> 
> We usually go for an Oxford comma, so "...SM4, and USER_MSR...".
> 
> > +  -mavx10.1-256, -mavx10.1-512 and
> > +  -mevex512 are marked as deprecated. Meanwhile,
> 
> How about just "... are deprecated"?
> 
> 
> > +  -mavx10.1 enables AVX10.1 intrinsics with 512-bit
> > +  vector size support, while in GCC 14.1 and GCC 14.2, it only enables
> > +  256-bit vector size support. GCC will emit a warning when using these
> > +  compiler switches. -mavx10.1-256, -mavx10.1-
> 512
> > +  and -mevex512 will be removed in GCC 16, while the
> warning
> > +  for the behavior change on -mavx10.1 will also be
> removed.
> 
> How about "..in GCC 16 together with he warning..." or "in GCC 16, as will the
> warning..."?
> 
> 
> This is fine with these (or similar) changes.

Thanks for the review!

I will do those changes after my vacation ends (approximately Apr. 8th)

Thx,
Haochen

Re: [PATCH] libstdc++: Fix up string _M_constructor exports [PR103827]

[Jonathan Wakely]

On Mon, 31 Mar 2025 at 17:07, Jonathan Wakely  wrote:
>
> On Mon, 31 Mar 2025 at 16:11, Rainer Orth  
> wrote:
> >
> > Jonathan Wakely  writes:
> >
> > > On Sun, 30 Mar 2025, 23:15 Jakub Jelinek,  wrote:
> > >
> > >> On Thu, Mar 27, 2025 at 02:04:24PM +0100, Jan Hubicka wrote:
> > >> > > > Newline between functions please.
> > >> > > >
> > >> > > > OK with those two changes.
> > >> > >
> > >> > > Looking back through my inbox, this one doesn't seem to have been
> > >> > > pushed. Was it superseded by something else, or is it just waiting 
> > >> > > for
> > >> > > stage 1 now?
> > >> >
> > >> > Seems I missed the approval, sorry.  I will push it - I think it would
> > >> > be useful to have it in.
> > >> > (I have more libstdc++ work for next stage1, but solving this is IMO
> > >> > useful)
> > >>
> > >> Unfortunately the exports in this patch only work on targets where size_t
> > >> is
> > >> unsigned long, not e.g. on ia32 where it is unsigned int, or targets 
> > >> where
> > >> it is unsigned long long.
> > >>
> > >> Fixed thusly, tested on x86_64-linux and i686-linux, ok for trunk?
> > >>
> > >
> > > OK, thanks
> >
> > with those two patches in, Solaris bootstrap with the native ld is
> > broken linking libstdc++.so:
> >
> > ld: fatal: libstdc++-symbols.ver-sun: 7449: symbol 
> > '_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_M_constructILb0EEEvPKcj':
> >  symbol version conflict
> > ld: fatal: libstdc++-symbols.ver-sun: 7450: symbol 
> > '_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_M_constructILb1EEEvPKcj':
> >  symbol version conflict
> > ld: fatal: libstdc++-symbols.ver-sun: 7451: symbol 
> > '_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_M_constructILb0EEEvPKwj':
> >  symbol version conflict
> > ld: fatal: libstdc++-symbols.ver-sun: 7452: symbol 
> > '_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_M_constructILb1EEEvPKwj':
> >  symbol version conflict
> > collect2: error: ld returned 1 exit status
> >
> > E.g. 
> > _ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_M_constructILb0EEEvPKcj
> > is matched by both
> >
> > _ZNSt7__cxx1112basic_stringI[cw]St11char_traitsI[cw]ESaI[cw]EE12_M*
> >
> > in GLIBCXX_3.4.21 and
> >
> > _ZNSt7__cxx1112basic_stringI[cw]St11char_traitsI[cw]ESaI[cw]EE12_M_constructILb[01]EEEvPK[cw][jmy]
> >
> > in GLIBCXX_3.4.34.
>
> This should fix it:
>
> --- a/libstdc++-v3/config/abi/pre/gnu.ver
> +++ b/libstdc++-v3/config/abi/pre/gnu.ver
> @@ -1767,7 +1767,8 @@ GLIBCXX_3.4.21 {
> 
> _ZNSt7__cxx1112basic_stringI[cw]St11char_traitsI[cw]ESaI[cw]EE10_S_compareE[jmy][jmy];
> 
> _ZNSt7__cxx1112basic_stringI[cw]St11char_traitsI[cw]ESaI[cw]EE11_M_capacityE[jmy];
> 
> _ZNSt7__cxx1112basic_stringI[cw]St11char_traitsI[cw]ESaI[cw]EE12_Alloc_hiderC[12]EP[cw]RKS3_;
> -_ZNSt7__cxx1112basic_stringI[cw]St11char_traitsI[cw]ESaI[cw]EE12_M*;
> +
> _ZNSt7__cxx1112basic_stringI[cw]St11char_traitsI[cw]ESaI[cw]EE12_M_constructE[jmy][cw];
> +
> _ZNSt7__cxx1112basic_stringI[cw]St11char_traitsI[cw]ESaI[cw]EE12_M_constructI[NP]*;
> _ZNSt7__cxx1112basic_stringI[cw]St11char_traitsI[cw]ESaI[cw]EE13*;
> 
> _ZNSt7__cxx1112basic_stringI[cw]St11char_traitsI[cw]ESaI[cw]EE14_M_replace_aux*;
> _ZNSt7__cxx1112basic_stringI[cw]St11char_traitsI[cw]ESaI[cw]EE1[68-9]*;

Indeed, I can build on Solaris 11 with this patch and it passes 'make
check-abi' on sparc-solaris and x86_64-linux. I'll push it.

[PATCH] libstdc++: Fix -Warray-bounds warning in std::vector::resize [PR114945]

[Jonathan Wakely]

This is yet another false positive warning fix. This time the compiler
can't prove that when the vector has sufficient excess capacity to
append new elements, the pointer to the existing storage is not null.

libstdc++-v3/ChangeLog:

PR libstdc++/114945
* include/bits/vector.tcc (vector::_M_default_append): Add
unreachable condition so the compiler knows that _M_finish is
not null.
* testsuite/23_containers/vector/capacity/114945.cc: New test.
---

Tested x86_64-linux.

 libstdc++-v3/include/bits/vector.tcc  |  3 ++
 .../23_containers/vector/capacity/114945.cc   | 36 +++
 2 files changed, 39 insertions(+)
 create mode 100644 
libstdc++-v3/testsuite/23_containers/vector/capacity/114945.cc

diff --git a/libstdc++-v3/include/bits/vector.tcc 
b/libstdc++-v3/include/bits/vector.tcc
index 7a92f34ec64..66d73b4cfd7 100644
--- a/libstdc++-v3/include/bits/vector.tcc
+++ b/libstdc++-v3/include/bits/vector.tcc
@@ -768,6 +768,9 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
 
  if (__navail >= __n)
{
+ if (!this->_M_impl._M_finish)
+   __builtin_unreachable();
+
  _GLIBCXX_ASAN_ANNOTATE_GROW(__n);
  this->_M_impl._M_finish =
std::__uninitialized_default_n_a(this->_M_impl._M_finish,
diff --git a/libstdc++-v3/testsuite/23_containers/vector/capacity/114945.cc 
b/libstdc++-v3/testsuite/23_containers/vector/capacity/114945.cc
new file mode 100644
index 000..daafc59d5a9
--- /dev/null
+++ b/libstdc++-v3/testsuite/23_containers/vector/capacity/114945.cc
@@ -0,0 +1,36 @@
+// { dg-options "-O2 -Werror=stringop-overflow -Werror=array-bounds" }
+// { dg-do compile { target c++11 } }
+
+// Bug libstdc++/114945
+// Sporadic std::vector::resize() -Wstringop-overflow or -Warray-bounds warning
+
+#include 
+#include 
+template  struct b {
+  void resize(std::size_t c) { d.resize(c); }
+  template  void f(a, e);
+  std::vector d;
+};
+#include 
+std::regex g;
+uint64_t h;
+uint32_t i;
+struct s {
+  enum class j : size_t;
+  void k();
+  using l = b;
+  std::vector m;
+};
+enum class s::j : size_t { n };
+void o() { g = ""; }
+void s::k() {
+  l p;
+  auto q = uint32_t(), r = uint32_t();
+  if (h)
+r = i;
+  b t;
+  if (q || r)
+p.f(j::n, 5);
+  t.resize(4);
+  m.push_back(p);
+}
-- 
2.49.0

Re: [PATCH] libstdc++: Fix up string _M_constructor exports [PR103827]

[Jonathan Wakely]

On Mon, 31 Mar 2025 at 17:28, Jonathan Wakely  wrote:
>
> On Mon, 31 Mar 2025 at 17:07, Jonathan Wakely  wrote:
> >
> > On Mon, 31 Mar 2025 at 16:11, Rainer Orth  
> > wrote:
> > >
> > > Jonathan Wakely  writes:
> > >
> > > > On Sun, 30 Mar 2025, 23:15 Jakub Jelinek,  wrote:
> > > >
> > > >> On Thu, Mar 27, 2025 at 02:04:24PM +0100, Jan Hubicka wrote:
> > > >> > > > Newline between functions please.
> > > >> > > >
> > > >> > > > OK with those two changes.
> > > >> > >
> > > >> > > Looking back through my inbox, this one doesn't seem to have been
> > > >> > > pushed. Was it superseded by something else, or is it just waiting 
> > > >> > > for
> > > >> > > stage 1 now?
> > > >> >
> > > >> > Seems I missed the approval, sorry.  I will push it - I think it 
> > > >> > would
> > > >> > be useful to have it in.
> > > >> > (I have more libstdc++ work for next stage1, but solving this is IMO
> > > >> > useful)
> > > >>
> > > >> Unfortunately the exports in this patch only work on targets where 
> > > >> size_t
> > > >> is
> > > >> unsigned long, not e.g. on ia32 where it is unsigned int, or targets 
> > > >> where
> > > >> it is unsigned long long.
> > > >>
> > > >> Fixed thusly, tested on x86_64-linux and i686-linux, ok for trunk?
> > > >>
> > > >
> > > > OK, thanks
> > >
> > > with those two patches in, Solaris bootstrap with the native ld is
> > > broken linking libstdc++.so:
> > >
> > > ld: fatal: libstdc++-symbols.ver-sun: 7449: symbol 
> > > '_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_M_constructILb0EEEvPKcj':
> > >  symbol version conflict
> > > ld: fatal: libstdc++-symbols.ver-sun: 7450: symbol 
> > > '_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_M_constructILb1EEEvPKcj':
> > >  symbol version conflict
> > > ld: fatal: libstdc++-symbols.ver-sun: 7451: symbol 
> > > '_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_M_constructILb0EEEvPKwj':
> > >  symbol version conflict
> > > ld: fatal: libstdc++-symbols.ver-sun: 7452: symbol 
> > > '_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_M_constructILb1EEEvPKwj':
> > >  symbol version conflict
> > > collect2: error: ld returned 1 exit status
> > >
> > > E.g. 
> > > _ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_M_constructILb0EEEvPKcj
> > > is matched by both
> > >
> > > _ZNSt7__cxx1112basic_stringI[cw]St11char_traitsI[cw]ESaI[cw]EE12_M*
> > >
> > > in GLIBCXX_3.4.21 and
> > >
> > > _ZNSt7__cxx1112basic_stringI[cw]St11char_traitsI[cw]ESaI[cw]EE12_M_constructILb[01]EEEvPK[cw][jmy]
> > >
> > > in GLIBCXX_3.4.34.
> >
> > This should fix it:
> >
> > --- a/libstdc++-v3/config/abi/pre/gnu.ver
> > +++ b/libstdc++-v3/config/abi/pre/gnu.ver
> > @@ -1767,7 +1767,8 @@ GLIBCXX_3.4.21 {
> > 
> > _ZNSt7__cxx1112basic_stringI[cw]St11char_traitsI[cw]ESaI[cw]EE10_S_compareE[jmy][jmy];
> > 
> > _ZNSt7__cxx1112basic_stringI[cw]St11char_traitsI[cw]ESaI[cw]EE11_M_capacityE[jmy];
> > 
> > _ZNSt7__cxx1112basic_stringI[cw]St11char_traitsI[cw]ESaI[cw]EE12_Alloc_hiderC[12]EP[cw]RKS3_;
> > -_ZNSt7__cxx1112basic_stringI[cw]St11char_traitsI[cw]ESaI[cw]EE12_M*;
> > +
> > _ZNSt7__cxx1112basic_stringI[cw]St11char_traitsI[cw]ESaI[cw]EE12_M_constructE[jmy][cw];
> > +
> > _ZNSt7__cxx1112basic_stringI[cw]St11char_traitsI[cw]ESaI[cw]EE12_M_constructI[NP]*;
> > _ZNSt7__cxx1112basic_stringI[cw]St11char_traitsI[cw]ESaI[cw]EE13*;
> > 
> > _ZNSt7__cxx1112basic_stringI[cw]St11char_traitsI[cw]ESaI[cw]EE14_M_replace_aux*;
> > _ZNSt7__cxx1112basic_stringI[cw]St11char_traitsI[cw]ESaI[cw]EE1[68-9]*;
>
> Indeed, I can build on Solaris 11 with this patch and it passes 'make
> check-abi' on sparc-solaris and x86_64-linux. I'll push it.

Pushed as r15-9071-g44289d258a970e

[pushed] Only write gcov when file output is on [PR119553]

[Jørgen Kvalsvik]

gcov_write_* functions must be guarded so they only are called when
output_to_file is true, like for -fcondition-coverage, otherwise it
triggers an invalid read as detected by valgrind. The gcno file is
mostly written to from profile.cc, so it doesn't make too much sense
to hide it in path-coverage.cc. The find_paths name was a bit
imprecise, and is renamed to instrument_prime_paths.

PR gcov-profile/119553

gcc/ChangeLog:

* path-coverage.cc (find_paths): Return path count, don't
write to gcno, and rename to ...
(instrument_prime_paths): ... this.
* profile.cc (branch_prob): Write path counts to gcno.
---
 gcc/path-coverage.cc | 15 ++-
 gcc/profile.cc   | 12 ++--
 2 files changed, 16 insertions(+), 11 deletions(-)

diff --git a/gcc/path-coverage.cc b/gcc/path-coverage.cc
index 55b39298603..55058fd04ff 100644
--- a/gcc/path-coverage.cc
+++ b/gcc/path-coverage.cc
@@ -504,8 +504,8 @@ flush_on_gsi (gimple_stmt_iterator *gsi, size_t bucket, 
tree local, tree mask,
bit N%64 in bucket N/64.  For large functions, an individual basic block
will only be part of a small subset of paths, and by extension buckets and
local counters.  Only the necessary counters are read and written.  */
-void
-find_paths (struct function *fn)
+unsigned
+instrument_prime_paths (struct function *fn)
 {
   mark_dfs_back_edges (fn);
   vec> paths = find_prime_paths (fn);
@@ -515,7 +515,7 @@ find_paths (struct function *fn)
   warning_at (fn->function_start_locus, OPT_Wcoverage_too_many_paths,
  "paths exceeding limit, giving up path coverage");
   release_vec_vec (paths);
-  return;
+  return 0;
 }
 
   tree gcov_type_node = get_gcov_type ();
@@ -526,14 +526,9 @@ find_paths (struct function *fn)
   if (!coverage_counter_alloc (GCOV_COUNTER_PATHS, nbuckets))
 {
   release_vec_vec (paths);
-  return;
+  return 0;
 }
 
-  gcov_position_t offset {};
-  offset = gcov_write_tag (GCOV_TAG_PATHS);
-  gcov_write_unsigned (paths.length ());
-  gcov_write_length (offset);
-
   hash_map  ands;
   hash_map  iors;
   hash_map  flushes;
@@ -771,6 +766,8 @@ find_paths (struct function *fn)
}
 }
 
+  const unsigned npaths = paths.length ();
   blocks.release ();
   release_vec_vec (paths);
+  return npaths;
 }
diff --git a/gcc/profile.cc b/gcc/profile.cc
index 0b222cf3864..c0f5097726b 100644
--- a/gcc/profile.cc
+++ b/gcc/profile.cc
@@ -1611,9 +1611,17 @@ branch_prob (bool thunk)
instrument_values (values);
 }
 
-  void find_paths (struct function*);
+  unsigned instrument_prime_paths (struct function*);
   if (path_coverage_flag)
-find_paths (cfun);
+{
+  const unsigned npaths = instrument_prime_paths (cfun);
+  if (output_to_file)
+   {
+ gcov_position_t offset = gcov_write_tag (GCOV_TAG_PATHS);
+ gcov_write_unsigned (npaths);
+ gcov_write_length (offset);
+   }
+}
 
   free_aux_for_edges ();
 
-- 
2.39.5

[PATCH] [testsuite] [riscv] xfail ssa-dom-cse-2 on riscv64

[Alexandre Oliva]

For the same reasons that affect alpha and other targets,
gcc.dg/tree-ssa/ssa-dom-cse-2.c fails to be optimized to the expected
return statement: the array initializer is vectorized into pairs, and
DOM cannot see through that.

Add riscv*-*-* to the list of affected lp64 platforms.  riscv32 is
not affected.

Tested on x86_64-linux-gnu native, and gcc-14 target riscv{64,32}-elf.
Ok to install?


for  gcc/testsuite/ChangeLog

* gcc.dg/tree-ssa/ssa-dom-cse-2.c: XFAIL on riscv lp64.
---
 gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-cse-2.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-cse-2.c 
b/gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-cse-2.c
index 5c89e3f869808..a879d3059714a 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-cse-2.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-cse-2.c
@@ -27,4 +27,4 @@ foo ()
but the loop reads only one element at a time, and DOM cannot resolve these.
The same happens on powerpc depending on the SIMD support available.  */
 
-/* { dg-final { scan-tree-dump "return 28;" "optimized" { xfail { { alpha*-*-* 
hppa*64*-*-* nvptx*-*-* mmix-knuth-mmixware } || { { { lp64 && { powerpc*-*-* 
sparc*-*-* } } || aarch64_sve } || { arm*-*-* && { ! arm_neon } } } } } } } */
+/* { dg-final { scan-tree-dump "return 28;" "optimized" { xfail { { alpha*-*-* 
hppa*64*-*-* nvptx*-*-* mmix-knuth-mmixware } || { { { lp64 && { powerpc*-*-* 
sparc*-*-* riscv*-*-* } } || aarch64_sve } || { arm*-*-* && { ! arm_neon } } } 
} } } } */

-- 
Alexandre Oliva, happy hackerhttps://blog.lx.oliva.nom.br/
Free Software Activist FSFLA co-founder GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity.
Excluding neuro-others for not behaving ""normal"" is *not* inclusive!

Re: [PATCH] libstdc++: Fix up string _M_constructor exports [PR103827]

[Rainer Orth]

Jonathan Wakely  writes:

> On Sun, 30 Mar 2025, 23:15 Jakub Jelinek,  wrote:
>
>> On Thu, Mar 27, 2025 at 02:04:24PM +0100, Jan Hubicka wrote:
>> > > > Newline between functions please.
>> > > >
>> > > > OK with those two changes.
>> > >
>> > > Looking back through my inbox, this one doesn't seem to have been
>> > > pushed. Was it superseded by something else, or is it just waiting for
>> > > stage 1 now?
>> >
>> > Seems I missed the approval, sorry.  I will push it - I think it would
>> > be useful to have it in.
>> > (I have more libstdc++ work for next stage1, but solving this is IMO
>> > useful)
>>
>> Unfortunately the exports in this patch only work on targets where size_t
>> is
>> unsigned long, not e.g. on ia32 where it is unsigned int, or targets where
>> it is unsigned long long.
>>
>> Fixed thusly, tested on x86_64-linux and i686-linux, ok for trunk?
>>
>
> OK, thanks

with those two patches in, Solaris bootstrap with the native ld is
broken linking libstdc++.so:

ld: fatal: libstdc++-symbols.ver-sun: 7449: symbol 
'_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_M_constructILb0EEEvPKcj':
 symbol version conflict
ld: fatal: libstdc++-symbols.ver-sun: 7450: symbol 
'_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_M_constructILb1EEEvPKcj':
 symbol version conflict
ld: fatal: libstdc++-symbols.ver-sun: 7451: symbol 
'_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_M_constructILb0EEEvPKwj':
 symbol version conflict
ld: fatal: libstdc++-symbols.ver-sun: 7452: symbol 
'_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_M_constructILb1EEEvPKwj':
 symbol version conflict
collect2: error: ld returned 1 exit status

E.g. 
_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_M_constructILb0EEEvPKcj
is matched by both

_ZNSt7__cxx1112basic_stringI[cw]St11char_traitsI[cw]ESaI[cw]EE12_M*

in GLIBCXX_3.4.21 and

_ZNSt7__cxx1112basic_stringI[cw]St11char_traitsI[cw]ESaI[cw]EE12_M_constructILb[01]EEEvPK[cw][jmy]

in GLIBCXX_3.4.34.

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

[PATCH] [testsuite] [riscv] xfail update-threading on riscv [PR110628]

[Alexandre Oliva]

The failure to adjust estimated profiling frequencies in reassoc noted
in PR110628 affects riscv as well.  Add it to the XFAIL set.

Tested on x86_64-linux-gnu native, and gcc-14 target riscv{64,32}-elf.
Ok to install?


for  gcc/testsuite/ChangeLog

PR tree-optimization/110628
* gcc.dg/tree-ssa/update-threading.c: XFAIL on riscv.
---
 gcc/testsuite/gcc.dg/tree-ssa/update-threading.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.dg/tree-ssa/update-threading.c 
b/gcc/testsuite/gcc.dg/tree-ssa/update-threading.c
index 9500099cddff3..024f098fc79ca 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/update-threading.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/update-threading.c
@@ -20,4 +20,4 @@ main (int argc, char **argv)
 foo (((A) { ((!(i >> 4) ? 8 : 64 + (i >> 4)) << 8) + (i << 4) } ).a);
   exit (0);
 }
-/* { dg-final { scan-tree-dump-times "Invalid sum" 0 "optimized" { xfail 
cris-*-* } } } Xfail: PR110628 */
+/* { dg-final { scan-tree-dump-times "Invalid sum" 0 "optimized" { xfail 
cris-*-* riscv*-*-* } } } Xfail: PR110628 */

-- 
Alexandre Oliva, happy hackerhttps://blog.lx.oliva.nom.br/
Free Software Activist FSFLA co-founder GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity.
Excluding neuro-others for not behaving ""normal"" is *not* inclusive!

[PATCH] [testsuite] [riscv] limit mcpu-xiangshan-nanhu.c to rv64

[Alexandre Oliva]

The testcase makes the -march option conditional on rv64, and #errors
out if the desired CPU properties are not active.  This makes the test
fail on rv32.  Arrange to skip the test on rv32 instead, moving the
rv64 conditional.

Tested on x86_64-linux-gnu native, and gcc-14 target riscv{64,32}-elf.
Ok to install?


for  gcc/testsuite/ChangeLog

* gcc.target/riscv/mcpu-xiangshan-nanhu.c: Skip on non-rv64.
---
 .../gcc.target/riscv/mcpu-xiangshan-nanhu.c|4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/testsuite/gcc.target/riscv/mcpu-xiangshan-nanhu.c 
b/gcc/testsuite/gcc.target/riscv/mcpu-xiangshan-nanhu.c
index 2903c88d91c86..c2a374f54fc86 100644
--- a/gcc/testsuite/gcc.target/riscv/mcpu-xiangshan-nanhu.c
+++ b/gcc/testsuite/gcc.target/riscv/mcpu-xiangshan-nanhu.c
@@ -1,6 +1,6 @@
-/* { dg-do compile } */
+/* { dg-do compile { target { rv64 } } } */
 /* { dg-skip-if "-march given" { *-*-* } { "-march=*" } } */
-/* { dg-options "-mcpu=xiangshan-nanhu" { target { rv64 } } } */
+/* { dg-options "-mcpu=xiangshan-nanhu" } */
 /* XiangShan Nanhu => rv64imafdc_zba_zbb_zbc_zbs_zbkb_zbkc_zbkx_zknd
   _zkne_zknh_zksed_zksh_svinval_zicbom_zicboz */
 

-- 
Alexandre Oliva, happy hackerhttps://blog.lx.oliva.nom.br/
Free Software Activist FSFLA co-founder GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity.
Excluding neuro-others for not behaving ""normal"" is *not* inclusive!

Re: [PATCH] testsuite: arm: Fix dg-final in short-vfp-1.c [PR119556]

[Sam James]

Christophe Lyon  writes:

> Recent syntactic fixes enabled the test, but the result was failing.
>
> It turns out it was missing a space between the register arguments in
> the scan-assembler-times directives.

Great find, thanks.

>
> gcc/testsuite/ChangeLog:
>
>   PR target/119556
>   * gcc.target/arm/short-vfp-1.c: Add missing spaces.
> ---
>  gcc/testsuite/gcc.target/arm/short-vfp-1.c | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/gcc/testsuite/gcc.target/arm/short-vfp-1.c 
> b/gcc/testsuite/gcc.target/arm/short-vfp-1.c
> index 18d38a58037..f6866c4f601 100644
> --- a/gcc/testsuite/gcc.target/arm/short-vfp-1.c
> +++ b/gcc/testsuite/gcc.target/arm/short-vfp-1.c
> @@ -1,5 +1,5 @@
>  /* { dg-do compile } */
> -/* { dg-require-effective-target arm_vfp_ok }
> +/* { dg-require-effective-target arm_vfp_ok } */
>  /* { dg-add-options arm_vfp } */
>  
>  int
> @@ -38,8 +38,8 @@ test_sihi (short x)
>return (int)x;
>  }
>  
> -/* { dg-final { scan-assembler-times {vcvt\.s32\.f32\ts[0-9]+,s[0-9]+} 2 } } 
> */
> -/* { dg-final { scan-assembler-times {vcvt\.f32\.s32\ts[0-9]+,s[0-9]+} 2 } } 
> */
> -/* { dg-final { scan-assembler-times {vmov\tr[0-9]+,s[0-9]+} 2 } } */
> -/* { dg-final { scan-assembler-times {vmov\ts[0-9]+,r[0-9]+} 2 } } */
> -/* { dg-final { scan-assembler-times {sxth\tr[0-9]+,r[0-9]+} 2 } } */
> +/* { dg-final { scan-assembler-times {vcvt\.s32\.f32\ts[0-9]+, s[0-9]+} 2 } 
> } */
> +/* { dg-final { scan-assembler-times {vcvt\.f32\.s32\ts[0-9]+, s[0-9]+} 2 } 
> } */
> +/* { dg-final { scan-assembler-times {vmov\tr[0-9]+, s[0-9]+} 2 } } */
> +/* { dg-final { scan-assembler-times {vmov\ts[0-9]+, r[0-9]+} 2 } } */
> +/* { dg-final { scan-assembler-times {sxth\tr[0-9]+, r[0-9]+} 2 } } */