Re: [11 PATCH] libiberty, Darwin: Fix a build warning. [PR112823]

[Sam James]

Iain Sandoe  writes:

> HI Sam,

Hi Iain,

>
> I think this qualifies as obvious (it’s on my list, but I did not get to it 
> yet,
> so go ahead).

Thanks. I can't push it myself - could you do that for me?

thanks again,
sam

>
> Iain
>
>> On 2 Dec 2023, at 05:30, Sam James  wrote:
>> 
>> From: Iain Sandoe 
>> 
>> r12-3005-g220c410162ebece4f missed a cast for the set_32 call.
>> Fixed thus.
>> 
>> Signed-off-by: Iain Sandoe 
>> Signed-off-by: Sam James 
>> 
>> libiberty/ChangeLog:
>>  PR other/112823
>>  * simple-object-mach-o.c (simple_object_mach_o_write_segment):
>>  Cast the first argument to set_32 as needed.
>> 
>> (cherry picked from commit 38757aa88735ab2e511bc428e2407a5a5e9fa0be)
>> ---
>> libiberty/simple-object-mach-o.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/libiberty/simple-object-mach-o.c 
>> b/libiberty/simple-object-mach-o.c
>> index 72b69d19c216..a8869e7c6395 100644
>> --- a/libiberty/simple-object-mach-o.c
>> +++ b/libiberty/simple-object-mach-o.c
>> @@ -1228,7 +1228,7 @@ simple_object_mach_o_write_segment 
>> (simple_object_write *sobj, int descriptor,
>>   /* Swap the indices, if required.  */
>> 
>>   for (i = 0; i < (nsects_in * 4); ++i)
>> -set_32 ([i], index[i]);
>> +set_32 ((unsigned char *) [i], index[i]);
>> 
>>   sechdr_offset += sechdrsize;
>> 
>> -- 
>> 2.43.0
>> 

Re: [11 PATCH] libiberty, Darwin: Fix a build warning. [PR112823]

[Iain Sandoe]

HI Sam,

I think this qualifies as obvious (it’s on my list, but I did not get to it yet,
so go ahead).

Iain

> On 2 Dec 2023, at 05:30, Sam James  wrote:
> 
> From: Iain Sandoe 
> 
> r12-3005-g220c410162ebece4f missed a cast for the set_32 call.
> Fixed thus.
> 
> Signed-off-by: Iain Sandoe 
> Signed-off-by: Sam James 
> 
> libiberty/ChangeLog:
>   PR other/112823
>   * simple-object-mach-o.c (simple_object_mach_o_write_segment):
>   Cast the first argument to set_32 as needed.
> 
> (cherry picked from commit 38757aa88735ab2e511bc428e2407a5a5e9fa0be)
> ---
> libiberty/simple-object-mach-o.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libiberty/simple-object-mach-o.c 
> b/libiberty/simple-object-mach-o.c
> index 72b69d19c216..a8869e7c6395 100644
> --- a/libiberty/simple-object-mach-o.c
> +++ b/libiberty/simple-object-mach-o.c
> @@ -1228,7 +1228,7 @@ simple_object_mach_o_write_segment (simple_object_write 
> *sobj, int descriptor,
>   /* Swap the indices, if required.  */
> 
>   for (i = 0; i < (nsects_in * 4); ++i)
> - set_32 ([i], index[i]);
> + set_32 ((unsigned char *) [i], index[i]);
> 
>   sechdr_offset += sechdrsize;
> 
> -- 
> 2.43.0
> 

[Bug tree-optimization/111972] [14 regression] missed vectorzation for bool a = j != 1; j = (long int)a;

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

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

--- Comment #15 from Andrew Pinski  ---
Patch set finally posted:
https://gcc.gnu.org/pipermail/gcc-patches/2023-December/639019.html

[PATCH 3/3] MATCH: (convert)(zero_one !=/== 0/1) for outer type and zero_one type are the same

[Andrew Pinski]

When I moved two_value to match.pd, I removed the check for the {0,+-1}
as I had placed it after the {0,+-1} case for cond in match.pd.
In the case of {0,+-1} and non boolean, before we would optmize those
case to just `(convert)a` but after we would get `(convert)(a != 0)`
which was not handled anyways to just `(convert)a`.
So this adds a pattern to match `(convert)(zeroone != 0)` and simplify
to `(convert)zeroone`.

Also this optimizes (convert)(zeroone == 0) into (zeroone^1) if the
type match. This can only be done on the gimple level as if zeroone
was defined by (a&1), fold will convert (a&1)^1 back into
`(convert)(zeroone == 0)` and an infinite loop will happen.

Note the testcase pr69270.c needed a slight update due to not matching
exactly a scan pattern, this update makes it more robust and will match
before and afterwards and if there are other changes in this area too.

Note the testcase gcc.target/i386/pr110790-2.c needs a slight update
for better code generation in LP64 bit mode.

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

gcc/ChangeLog:

PR tree-optimization/111972
PR tree-optimization/110637
* match.pd (`(convert)(zeroone !=/== CST)`): Match
and simplify to ((convert)zeroone){,^1}.

gcc/testsuite/ChangeLog:

* gcc.dg/tree-ssa/pr110637-1.c: New test.
* gcc.dg/tree-ssa/pr110637-2.c: New test.
* gcc.dg/tree-ssa/pr110637-3.c: New test.
* gcc.dg/tree-ssa/pr111972-1.c: New test.
* gcc.dg/tree-ssa/pr69270.c: Update testcase.
* gcc.target/i386/pr110790-2.c: Update testcase.

Signed-off-by: Andrew Pinski 
---
 gcc/match.pd   | 21 +
 gcc/testsuite/gcc.dg/tree-ssa/pr110637-1.c | 10 +++
 gcc/testsuite/gcc.dg/tree-ssa/pr110637-2.c | 13 +
 gcc/testsuite/gcc.dg/tree-ssa/pr110637-3.c | 14 +
 gcc/testsuite/gcc.dg/tree-ssa/pr111972-1.c | 34 ++
 gcc/testsuite/gcc.dg/tree-ssa/pr69270.c|  4 +--
 gcc/testsuite/gcc.target/i386/pr110790-2.c | 16 --
 7 files changed, 108 insertions(+), 4 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/pr110637-1.c
 create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/pr110637-2.c
 create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/pr110637-3.c
 create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/pr111972-1.c

diff --git a/gcc/match.pd b/gcc/match.pd
index 4d554ba4721..656b2c9edda 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -3332,6 +3332,27 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
   (if (INTEGRAL_TYPE_P (TREE_TYPE (@0)) || POINTER_TYPE_P (TREE_TYPE (@0)))
 (rcmp @0 @1
 
+/* (type)([0,1]@a != 0) -> (type)a
+   (type)([0,1]@a == 1) -> (type)a
+   (type)([0,1]@a == 0) -> a ^ 1
+   (type)([0,1]@a != 1) -> a ^ 1.  */
+(for eqne (eq ne)
+ (simplify
+  (convert (eqne zero_one_valued_p@0 INTEGER_CST@1))
+  (if ((integer_zerop (@1) || integer_onep (@1)))
+   (if ((eqne == EQ_EXPR) ^ integer_zerop (@1))
+(convert @0)
+   /* a^1 can only be produced for gimple as
+  fold has the exact opposite transformation
+  for `(X & 1) ^ 1`.
+  See `Fold ~X & 1 as (X & 1) == 0.`
+  and `Fold (X ^ 1) & 1 as (X & 1) == 0.` in fold-const.cc.
+  Only do this if the types match as (type)(a == 0) is
+  canonical form normally, while `a ^ 1` is canonical when
+  there is no type change. */
+   (if (GIMPLE && types_match (type, TREE_TYPE (@0)))
+(bit_xor @0 { build_one_cst (type); } ))
+
 /* We can't reassociate at all for saturating types.  */
 (if (!TYPE_SATURATING (type))
 
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr110637-1.c 
b/gcc/testsuite/gcc.dg/tree-ssa/pr110637-1.c
new file mode 100644
index 000..3d03b0992a4
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/pr110637-1.c
@@ -0,0 +1,10 @@
+/* { dg-do compile } */
+/* { dg-options "-O1 -fdump-tree-optimized" } */
+int f(int a)
+{
+int b = (a & 1)!=0;
+return b;
+}
+
+/* This should be optimized to just return (a & 1); */
+/* { dg-final { scan-tree-dump-not " == " "optimized"} } */
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr110637-2.c 
b/gcc/testsuite/gcc.dg/tree-ssa/pr110637-2.c
new file mode 100644
index 000..f1c5b90353a
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/pr110637-2.c
@@ -0,0 +1,13 @@
+/* { dg-do compile } */
+/* { dg-options "-O1 -fdump-tree-optimized" } */
+int f(int a)
+{
+int b = a & 1;
+int c = b == 0;
+return c;
+}
+
+/* This should be optimized to just return `(a&1) ^ 1` or `(~a) & 1`. */
+/* { dg-final { scan-tree-dump-not " == " "optimized"} } */
+/* { dg-final { scan-tree-dump-times "~a" 1 "optimized"} } */
+/* { dg-final { scan-tree-dump-times " & 1" 1 "optimized"} } */
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr110637-3.c 
b/gcc/testsuite/gcc.dg/tree-ssa/pr110637-3.c
new file mode 100644
index 000..ce80146d9df
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/pr110637-3.c
@@ 

[PATCH 0/3] Fix PR 111972

[Andrew Pinski]

This patch set fixes PR 111972 and the fallout from it.

The first patch is a fix to zero_one_valued_p's convert pattern
which I hit while running the testsuite with the last patch.

The second patch is a fix for -fanalyzer which I had implemented with
a different version of the 3rd patch while I was working at Marvell.

And the 3rd patch fixes the issue by having the following as
canonical forms:
* `a ^ 1` is the canonical form of `(convert_back)(zero_one == 0)` (and 
`(convert_back)(zero_one != 1)`).
* `(convert)a` is the canonical form of `(convert)(zero_one != 0)` (and 
`(convert)(zero_one == 1)`).

Signed-off-by: Andrew Pinski 


Andrew Pinski (3):
  MATCH: Fix zero_one_valued_p's convert pattern
  Remove check of unsigned_char in
maybe_undo_optimize_bit_field_compare.
  MATCH: (convert)(zero_one !=/== 0/1) for outer type and zero_one type
are the same

 gcc/analyzer/region-model-manager.cc   |  3 --
 gcc/match.pd   | 24 +++
 gcc/testsuite/gcc.dg/tree-ssa/pr110637-1.c | 10 +++
 gcc/testsuite/gcc.dg/tree-ssa/pr110637-2.c | 13 +
 gcc/testsuite/gcc.dg/tree-ssa/pr110637-3.c | 14 +
 gcc/testsuite/gcc.dg/tree-ssa/pr111972-1.c | 34 ++
 gcc/testsuite/gcc.dg/tree-ssa/pr69270.c|  4 +--
 gcc/testsuite/gcc.target/i386/pr110790-2.c | 16 --
 8 files changed, 111 insertions(+), 7 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/pr110637-1.c
 create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/pr110637-2.c
 create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/pr110637-3.c
 create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/pr111972-1.c

-- 
2.34.1

[PATCH 2/3] Remove check of unsigned_char in maybe_undo_optimize_bit_field_compare.

[Andrew Pinski]

From: Andrew Pinski 

The check for the type seems unnecessary and gets in the way sometimes.
Also with a patch I am working on for match.pd, it causes a failure to happen.
Before my patch the IR was:
  _1 = BIT_FIELD_REF ;
  _2 = _1 & 1;
  _3 = _2 != 0;
  _4 = (int) _3;
  __analyzer_eval (_4);

Where _2 was an unsigned char type.
And After my patch we have:
  _1 = BIT_FIELD_REF ;
  _2 = (int) _1;
  _3 = _2 & 1;
  __analyzer_eval (_3);

But in this case, the BIT_AND_EXPR is in an int type.

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

gcc/analyzer/ChangeLog:

* region-model-manager.cc (maybe_undo_optimize_bit_field_compare): 
Remove
the check for type being unsigned_char_type_node.
---
 gcc/analyzer/region-model-manager.cc | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/gcc/analyzer/region-model-manager.cc 
b/gcc/analyzer/region-model-manager.cc
index 921edc55868..9a17b9d2878 100644
--- a/gcc/analyzer/region-model-manager.cc
+++ b/gcc/analyzer/region-model-manager.cc
@@ -586,9 +586,6 @@ maybe_undo_optimize_bit_field_compare (tree type,
   tree cst,
   const svalue *arg1)
 {
-  if (type != unsigned_char_type_node)
-return NULL;
-
   const binding_map  = compound_sval->get_map ();
   unsigned HOST_WIDE_INT mask = TREE_INT_CST_LOW (cst);
   /* If "mask" is a contiguous range of set bits, see if the
-- 
2.39.3

[PATCH 1/3] MATCH: Fix zero_one_valued_p's convert pattern

[Andrew Pinski]

While working on PR 111972, I was getting a regression
due to zero_one_valued_p matching a signed 1 bit integer
when it came to convert. This patch fixes that by checking
the outer type too.

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

gcc/ChangeLog:

* match.pd (zero_one_valued_p): For convert
make sure type is not a signed 1-bit integer.

Signed-off-by: Andrew Pinski 
---
 gcc/match.pd | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/gcc/match.pd b/gcc/match.pd
index 26383e55767..4d554ba4721 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -2247,6 +2247,9 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
  (if (INTEGRAL_TYPE_P (TREE_TYPE (@1))
   && (TYPE_UNSIGNED (TREE_TYPE (@1))
  || TYPE_PRECISION (TREE_TYPE (@1)) > 1)
+  && INTEGRAL_TYPE_P (type)
+  && (TYPE_UNSIGNED (type)
+ || TYPE_PRECISION (type) > 1)
   && wi::leu_p (tree_nonzero_bits (@1), 1
 
 /* Transform { 0 or 1 } * { 0 or 1 } into { 0 or 1 } & { 0 or 1 }.  */
-- 
2.39.3

Re: [PATCH 2/6] c: Turn int-conversion warnings into permerrors

[Sam James]

Jeff Law  writes:

> On 12/1/23 18:13, Sam James wrote:
>> 钟居哲  writes:
>> 
>>> Hi, This patch cause error on building newlib/glibc/musl on RISC-V port:
>>>
>>> /work/home/jzzhong/work/toolchain/riscv/build/dev-rv64gcv_zvfh_zfh-lp64d-medany-newlib-spike-debug/../../newlib/libgloss/riscv/sys_access.c:8:40:
>>> error: passing argument 3 of 'syscall_errno' makes integer from pointer 
>>> without a cast [-Wint-conversion]
>>>  8 |   return syscall_errno (SYS_access, 2, file, mode, 0, 0, 0, 0);
>>>|^~~~
>>>||
>>>|const char *
>> This looks like an issue in newlib. We expect broken code to be
>> broken
>> by the recent changes. Can you investigate it on the newlib side?
> A ton of stuff in newlib/libgloss is broken due to the compiler
> changes.   But that's not a big surprise -- much of the
> newlib/libgloss code is c89 and clearly wrong for c99 and newer.

Yeah, it's probably a reasonable candidate for -fpermissive to start
with until it's cleaned up.

(Also, sorry, I didn't mean my comment to appear glib. I just meant to
say "yes, this looks expected".)

>
> Jeff

thanks,
sam

[11 PATCH] libiberty, Darwin: Fix a build warning. [PR112823]

[Sam James]

From: Iain Sandoe 

r12-3005-g220c410162ebece4f missed a cast for the set_32 call.
Fixed thus.

Signed-off-by: Iain Sandoe 
Signed-off-by: Sam James 

libiberty/ChangeLog:
PR other/112823
* simple-object-mach-o.c (simple_object_mach_o_write_segment):
Cast the first argument to set_32 as needed.

(cherry picked from commit 38757aa88735ab2e511bc428e2407a5a5e9fa0be)
---
 libiberty/simple-object-mach-o.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libiberty/simple-object-mach-o.c b/libiberty/simple-object-mach-o.c
index 72b69d19c216..a8869e7c6395 100644
--- a/libiberty/simple-object-mach-o.c
+++ b/libiberty/simple-object-mach-o.c
@@ -1228,7 +1228,7 @@ simple_object_mach_o_write_segment (simple_object_write 
*sobj, int descriptor,
   /* Swap the indices, if required.  */
 
   for (i = 0; i < (nsects_in * 4); ++i)
-   set_32 ([i], index[i]);
+   set_32 ((unsigned char *) [i], index[i]);
 
   sechdr_offset += sechdrsize;
 
-- 
2.43.0

[Bug other/112823] [11 only] -Wincompatible-pointer-types errors in libiberty/simple-object-mach-o.c (missing backport for gcc-11)

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||build
   Target Milestone|--- |11.5
Summary|-Wincompatible-pointer-type |[11 only]
   |s errors in |-Wincompatible-pointer-type
   |libiberty/simple-object-mac |s errors in
   |h-o.c (missing backport for |libiberty/simple-object-mac
   |gcc-11) |h-o.c (missing backport for
   ||gcc-11)

[Bug other/112823] -Wincompatible-pointer-types errors in libiberty/simple-object-mach-o.c (missing backport for gcc-11)

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

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

--- Comment #1 from Sam James  ---
At some point, I think we should consider using formal Fixes: git trailers or
something to help find missed backports, but that's another story.

[Bug other/112823] New: -Wincompatible-pointer-types errors in libiberty/simple-object-mach-o.c (missing backport for gcc-11)

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

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

Bug ID: 112823
   Summary: -Wincompatible-pointer-types errors in
libiberty/simple-object-mach-o.c (missing backport for
gcc-11)
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
CC: fw at gcc dot gnu.org, iains at gcc dot gnu.org
  Target Milestone: ---

```
make[3]: Leaving directory
'/var/tmp/portage/sys-devel/gcc-11.4.1_p20231123/work/build/build-x86_64-pc-linux-gnu/libiberty'
make[3]: Entering directory
'/var/tmp/portage/sys-devel/gcc-11.4.1_p20231123/work/build/build-x86_64-pc-linux-gnu/libiberty'
x86_64-pc-linux-gnu-gcc -c -DHAVE_CONFIG_H -march=native -pipe -Wa,-O2
-Wa,-mtune=znver2 -fcf-protection=none -fdiagnostics-color=always
-fdiagnostics-urls=never -ggdb3 -g -O3  -I.
-I/var/tmp/portage/sys-devel/gcc-11.4.1_p20231123/work/gcc-11-20231123/libiberty/../include
 -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -Wshadow=local
-pedantic  -D_GNU_SOURCE -fcf-protection
/var/tmp/portage/sys-devel/gcc-11.4.1_p20231123/work/gcc-11-20231123/libiberty/simple-object-mach-o.c
-o simple-object-mach-o.o
/var/tmp/portage/sys-devel/gcc-11.4.1_p20231123/work/gcc-11-20231123/libiberty/simple-object-mach-o.c:
In function ‘simple_object_mach_o_write_segment’:
/var/tmp/portage/sys-devel/gcc-11.4.1_p20231123/work/gcc-11-20231123/libiberty/simple-object-mach-o.c:1231:17:
error: passing argument 1 of ‘set_32’ from incompatible pointer type
[-Wincompatible-pointer-types]
 1231 | set_32 ([i], index[i]);
  | ^
  | |
  | unsigned int *
/var/tmp/portage/sys-devel/gcc-11.4.1_p20231123/work/gcc-11-20231123/libiberty/simple-object-mach-o.c:1231:17:
note: expected ‘unsigned char *’ but argument is of type ‘unsigned int *’
make[3]: *** [Makefile:1309: simple-object-mach-o.o] Error 1
make[3]: Leaving directory
'/var/tmp/portage/sys-devel/gcc-11.4.1_p20231123/work/build/build-x86_64-pc-linux-gnu/libiberty'
make[3]: *** Waiting for unfinished jobs
make[3]: Entering directory
'/var/tmp/portage/sys-devel/gcc-11.4.1_p20231123/work/build/build-x86_64-pc-linux-gnu/libiberty'
```

r12-3005-g220c410162ebec was backported to releases/gcc-11 but the fixup commit
r12-3092-g38757aa88735ab wasn't yet backported, so we just need to pull that
in.

Re: [PATCH 2/6] c: Turn int-conversion warnings into permerrors

[Jeff Law]

On 12/1/23 18:13, Sam James wrote:


钟居哲  writes:


Hi, This patch cause error on building newlib/glibc/musl on RISC-V port:

/work/home/jzzhong/work/toolchain/riscv/build/dev-rv64gcv_zvfh_zfh-lp64d-medany-newlib-spike-debug/../../newlib/libgloss/riscv/sys_access.c:8:40:
error: passing argument 3 of 'syscall_errno' makes integer from pointer without 
a cast [-Wint-conversion]
 8 |   return syscall_errno (SYS_access, 2, file, mode, 0, 0, 0, 0);
   |^~~~
   ||
   |const char *


This looks like an issue in newlib. We expect broken code to be broken
by the recent changes. Can you investigate it on the newlib side?
A ton of stuff in newlib/libgloss is broken due to the compiler changes. 
 But that's not a big surprise -- much of the newlib/libgloss code is 
c89 and clearly wrong for c99 and newer.


Jeff

[Bug target/112801] [14] RISC-V vector: failure to mask top bits during type conversion

[juzhe.zhong at rivai dot ai via Gcc-bugs]

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

--- Comment #5 from JuzheZhong  ---
Should be fixed on the trunk. Plz verify it and close it.

[Bug target/112801] [14] RISC-V vector: failure to mask top bits during type conversion

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

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

--- Comment #4 from GCC Commits  ---
The master branch has been updated by Pan Li :

https://gcc.gnu.org/g:1461b431da51f80c90c3bea03d587d76e3e50843

commit r14-6069-g1461b431da51f80c90c3bea03d587d76e3e50843
Author: Juzhe-Zhong 
Date:   Fri Dec 1 20:31:50 2023 +0800

RISC-V: Fix incorrect combine of extended scalar pattern

Background:
RVV ISA vx instructions for example vadd.vx,
When EEW = 64 and RV32. We can't directly use vadd.vx.
Instead, we need to use:

sw
sw
vlse
vadd.vv

However, we have some special situation that we still can directly use
vadd.vx directly for EEW=64 && RV32.

that is, when scalar is a known CONST_INT value that doesn't overflow
32-bit value.
So, we have a dedicated pattern for such situation:

...
(sign_extend: (match_operand: 3 "register_operand"  "
r,  r,  r,  r")).
...

We first force_reg such CONST_INT (within 32bit value) into a SImode reg.
Then use such special patterns.
Those pattern with this operand match should only value on! TARGET_64BIT.

The PR112801 combine into such patterns on RV64 incorrectly (Those patterns
should be only value on RV32).

This is the bug:

andia2,a2,2
vsetivlizero,2,e64,m1,ta,ma
sext.w  a3,a4
vmv.v.x v1,a2
vslide1down.vx  v1,v1,a4-> it should be a3 instead of a4.

Such incorrect codegen is caused by
...
(sign_extend:DI (subreg:SI (reg:DI 135 [ f.0_3 ]) 0))
] UNSPEC_VSLIDE1DOWN)) 16935 {*pred_slide1downv2di_extended}
...

Incorretly combine into the patterns should not be valid on RV64 system.

So add !TARGET_64BIT to all same type patterns which can fix such issue as
well as robostify the vector.md.

PR target/112801

gcc/ChangeLog:

* config/riscv/vector.md: Add !TARGET_64BIT.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/autovec/pr112801.c: New test.

[Bug c/88088] -Wtrampolines should be enabled by -Wall (or -Wextra)

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

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

Eric Gallager  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #27 from Eric Gallager  ---
Marek Polacek has had a new idea to have it be enabled by the new -fhardened
flag instead:
https://gcc.gnu.org/pipermail/gcc-patches/2023-December/638987.html

[Bug c++/70819] constexpr error location wrong

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||needs-bisection

--- Comment #1 from Andrew Pinski  ---
GCC 7-13 does:
```
:17:24:   in constexpr expansion of 'fn7(0, 0)'
:17:43: error: dereferencing a null pointer
 constexpr int n3 = fn7 ((const int *) 0, 0);
   ^
:18:24:   in constexpr expansion of 'fn7(0, 8)'
:18:43: error: dereferencing a null pointer
 constexpr int n4 = fn7 ((const int *) 0, 8);
   ^
```

While the trunk gives:
```
:17:24:   in 'constexpr' expansion of 'fn7(0, 0)'
:14:14: error: dereferencing a null pointer
   14 |   return fn6 (*a, b);
  |  ^~~
:18:24:   in 'constexpr' expansion of 'fn7(0, 8)'
:14:14: error: dereferencing a null pointer
```

Which seems like the correct location now.

Re: [PATCH 2/6] c: Turn int-conversion warnings into permerrors

[Patrick O'Neill]

That failure is is due to newlib files:
/work/home/jzzhong/work/toolchain/riscv/build/dev-rv64gcv_zvfh_zfh-lp64d-medany-linux-spike-debug/../../*newlib*/newlib/libm/complex/ccoshl.c: 
In function 'ccoshl':


To build gcc w/ glibc with riscv-gnu-toolchain, run make linux.

A temporary fix for newlib is here:
https://github.com/patrick-rivos/riscv-gnu-toolchain/tree/35d8e8c486bd2f6e3e2e673db8d2b979309a6de4/fixups/newlib

On 12/1/23 17:53, 钟居哲 wrote:

No. GLIBC 2.37 also failed:

make[4]: Leaving directory 
'/work/home/jzzhong/work/toolchain/riscv/build/dev-rv64gcv_zvfh_zfh-lp64d-medany-linux-spike-debug/build-newlib/riscv64-unknown-elf/newlib'

  CC       libm/complex/libm_a-casinhl.o
make[3]: *** [Makefile:5283: all] Error 2
make[3]: Leaving directory 
'/work/home/jzzhong/work/toolchain/riscv/build/dev-rv64gcv_zvfh_zfh-lp64d-medany-linux-spike-debug/build-newlib/riscv64-unknown-elf/newlib'

make[2]: *** [Makefile:8492: all-target-newlib] Error 2
make[2]: Leaving directory 
'/work/home/jzzhong/work/toolchain/riscv/build/dev-rv64gcv_zvfh_zfh-lp64d-medany-linux-spike-debug/build-newlib'

make[1]: *** [Makefile:879: all] Error 2
make[1]: Leaving directory 
'/work/home/jzzhong/work/toolchain/riscv/build/dev-rv64gcv_zvfh_zfh-lp64d-medany-linux-spike-debug/build-newlib'

make: *** [Makefile:624: stamps/build-newlib] Error 2
make: *** Waiting for unfinished jobs
  CC       libm/complex/libm_a-csinhl.o
/work/home/jzzhong/work/toolchain/riscv/build/dev-rv64gcv_zvfh_zfh-lp64d-medany-linux-spike-debug/../../newlib/newlib/libm/complex/ccoshl.c: 
In function 'ccoshl':
/work/home/jzzhong/work/toolchain/riscv/build/dev-rv64gcv_zvfh_zfh-lp64d-medany-linux-spike-debug/../../newlib/newlib/libm/complex/ccoshl.c:43:13: 
error: implicit declaration of function 'coshl'; did you mean 'coshf'? 
[-Wimplicit-function-declaration]

   43 |         w = coshl(x) * cosl(y) + (sinhl(x) * sinl(y)) * I;
      |             ^
      |             coshf
/work/home/jzzhong/work/toolchain/riscv/build/dev-rv64gcv_zvfh_zfh-lp64d-medany-linux-spike-debug/../../newlib/newlib/libm/complex/ccoshl.c:43:24: 
error: implicit declaration of function 'cosl'; did you mean 'cosf'? 
[-Wimplicit-function-declaration]

   43 |         w = coshl(x) * cosl(y) + (sinhl(x) * sinl(y)) * I;
      |                        ^~~~
      |                        cosf
/work/home/jzzhong/work/toolchain/riscv/build/dev-rv64gcv_zvfh_zfh-lp64d-medany-linux-spike-debug/../../newlib/newlib/libm/complex/clogl.c: 
In function 'clogl':
/work/home/jzzhong/work/toolchain/riscv/build/dev-rv64gcv_zvfh_zfh-lp64d-medany-linux-spike-debug/../../newlib/newlib/libm/complex/ccoshl.c:43:35: 
error: implicit declaration of function 'sinhl'; did you mean 'sinhf'? 
[-Wimplicit-function-declaration]

   43 |         w = coshl(x) * cosl(y) + (sinhl(x) * sinl(y)) * I;
      |                                   ^
      |                                   sinhf
/work/home/jzzhong/work/toolchain/riscv/build/dev-rv64gcv_zvfh_zfh-lp64d-medany-linux-spike-debug/../../newlib/newlib/libm/complex/clogl.c:42:13: 
error: implicit declaration of function 'logl'; did you mean 'logf'? 
[-Wimplicit-function-declaration]

   42 |         p = logl(rr);
      |             ^~~~
      |             logf
/work/home/jzzhong/work/toolchain/riscv/build/dev-rv64gcv_zvfh_zfh-lp64d-medany-linux-spike-debug/../../newlib/newlib/libm/complex/ccoshl.c:43:46: 
error: implicit declaration of function 'sinl'; did you mean 'sinf'? 
[-Wimplicit-function-declaration]

   43 |         w = coshl(x) * cosl(y) + (sinhl(x) * sinl(y)) * I;
      |                                              ^~~~
      |                                              sinf
/work/home/jzzhong/work/toolchain/riscv/build/dev-rv64gcv_zvfh_zfh-lp64d-medany-linux-spike-debug/../../newlib/newlib/libm/complex/clogl.c:43:14: 
error: implicit declaration of function 'atan2l'; did you mean 
'atan2f'? [-Wimplicit-function-declaration]

   43 |         rr = atan2l(cimagl(z), creall(z));
      |              ^~
      |              atan2f
  CC       libm/complex/libm_a-csinl.o
/work/home/jzzhong/work/toolchain/riscv/build/dev-rv64gcv_zvfh_zfh-lp64d-medany-linux-spike-debug/../../newlib/newlib/libm/complex/cexpl.c: 
In function 'cexpl':
/work/home/jzzhong/work/toolchain/riscv/build/dev-rv64gcv_zvfh_zfh-lp64d-medany-linux-spike-debug/../../newlib/newlib/libm/complex/cexpl.c:43:13: 
error: implicit declaration of function 'expl'; did you mean 'expf'? 
[-Wimplicit-function-declaration]

   43 |         r = expl(x);
      |             ^~~~
      |             expf
/work/home/jzzhong/work/toolchain/riscv/build/dev-rv64gcv_zvfh_zfh-lp64d-medany-linux-spike-debug/../../newlib/newlib/libm/complex/cexpl.c:44:17: 
error: implicit declaration of function 'cosl'; did you mean 'cosf'? 
[-Wimplicit-function-declaration]

   44 |         w = r * cosl(y) + r * sinl(y) * I;
      |                 ^~~~
      |                 cosf

RE: [PATCH v4] RISC-V: Bugfix for legitimize move when get vec mode in zve32f

[Li, Pan2]

Committed, thanks Juzhe.

Pan

From: 钟居哲 
Sent: Saturday, December 2, 2023 9:10 AM
To: Li, Pan2 ; gcc-patches 
Cc: Li, Pan2 ; Wang, Yanzhang ; 
kito.cheng 
Subject: Re: [PATCH v4] RISC-V: Bugfix for legitimize move when get vec mode in 
zve32f

LGTM


juzhe.zh...@rivai.ai

From: pan2.li
Date: 2023-12-02 08:59
To: gcc-patches
CC: juzhe.zhong; 
pan2.li; 
yanzhang.wang; 
kito.cheng
Subject: [PATCH v4] RISC-V: Bugfix for legitimize move when get vec mode in 
zve32f
From: Pan Li mailto:pan2...@intel.com>>

If we want to extract 64bit value but ELEN < 64, we use RVV
vector mode with EEW = 32 to extract the highpart and lowpart.
However, this approach doesn't honor DFmode when movdf pattern
when ZVE32f and of course results in ICE when zve32f.

This patch would like to reuse the approach with some additional
handing, consider lowpart bits is meaningless for FP mode, we need
one int reg as bridge here. For example:

rtx tmp = gen_rtx_reg (DImode)
reg:DI = reg:DF (fmv.d.x) // Move DF reg to DI
...
perform the extract for high and low parts
...
reg:DF = reg:DI (fmv.x.d) // Move DI reg back to DF after all done

PR target/112743

gcc/ChangeLog:

* config/riscv/riscv.cc (riscv_legitimize_move): Take the
exist (U *mode) and handle DFmode like DImode when EEW is
32bits for ZVE32F.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/base/pr112743-2.c: New test.

Signed-off-by: Pan Li mailto:pan2...@intel.com>>
---
gcc/config/riscv/riscv.cc | 63 +--
.../gcc.target/riscv/rvv/base/pr112743-2.c| 52 +++
2 files changed, 95 insertions(+), 20 deletions(-)
create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/pr112743-2.c

diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index a4fc858fb50..84512dcdc68 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -2605,41 +2605,64 @@ riscv_legitimize_move (machine_mode mode, rtx dest, rtx 
src)
   unsigned int nunits = vmode_size > mode_size ? vmode_size / mode_size : 
1;
   scalar_mode smode = as_a (mode);
   unsigned int index = SUBREG_BYTE (src).to_constant () / mode_size;
-  unsigned int num = smode == DImode && !TARGET_VECTOR_ELEN_64 ? 2 : 1;
+  unsigned int num = known_eq (GET_MODE_SIZE (smode), 8)
+ && !TARGET_VECTOR_ELEN_64 ? 2 : 1;
+  bool need_int_reg_p = false;
   if (num == 2)
{
  /* If we want to extract 64bit value but ELEN < 64,
 we use RVV vector mode with EEW = 32 to extract
 the highpart and lowpart.  */
+   need_int_reg_p = smode == DFmode;
  smode = SImode;
  nunits = nunits * 2;
}
-  vmode = riscv_vector::get_vector_mode (smode, nunits).require ();
-  rtx v = gen_lowpart (vmode, SUBREG_REG (src));
-  for (unsigned int i = 0; i < num; i++)
+  if (riscv_vector::get_vector_mode (smode, nunits).exists ())
{
-   rtx result;
-   if (num == 1)
- result = dest;
-   else if (i == 0)
- result = gen_lowpart (smode, dest);
-   else
- result = gen_reg_rtx (smode);
-   riscv_vector::emit_vec_extract (result, v, index + i);
+   rtx v = gen_lowpart (vmode, SUBREG_REG (src));
+   rtx int_reg = dest;
-   if (i == 1)
+   if (need_int_reg_p)
{
-   rtx tmp
- = expand_binop (Pmode, ashl_optab, gen_lowpart (Pmode, result),
- gen_int_mode (32, Pmode), NULL_RTX, 0,
- OPTAB_DIRECT);
-   rtx tmp2 = expand_binop (Pmode, ior_optab, tmp, dest, NULL_RTX, 0,
-OPTAB_DIRECT);
-   emit_move_insn (dest, tmp2);
+   int_reg = gen_reg_rtx (DImode);
+   emit_move_insn (int_reg, gen_lowpart (GET_MODE (int_reg), dest));
}
+
+   for (unsigned int i = 0; i < num; i++)
+ {
+   rtx result;
+   if (num == 1)
+ result = int_reg;
+   else if (i == 0)
+ result = gen_lowpart (smode, int_reg);
+   else
+ result = gen_reg_rtx (smode);
+
+   riscv_vector::emit_vec_extract (result, v, index + i);
+
+   if (i == 1)
+ {
+   rtx tmp = expand_binop (Pmode, ashl_optab,
+   gen_lowpart (Pmode, result),
+   gen_int_mode (32, Pmode), NULL_RTX, 0,
+   OPTAB_DIRECT);
+   rtx tmp2 = expand_binop (Pmode, ior_optab, tmp, int_reg,
+NULL_RTX, 0,
+OPTAB_DIRECT);
+   emit_move_insn (int_reg, tmp2);
+ }
+ }
+
+   if (need_int_reg_p)
+ emit_move_insn (dest, gen_lowpart (GET_MODE (dest), int_reg));
+   else
+ emit_move_insn (dest, int_reg);
}
+  else
+ gcc_unreachable ();
+
   return true;
 }
   /* Expand
diff --git a/gcc/testsuite/gcc.target/riscv/rvv/base/pr112743-2.c 
b/gcc/testsuite/gcc.target/riscv/rvv/base/pr112743-2.c
new file mode 100644
index 000..fdb35fd70f2
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/rvv/base/pr112743-2.c
@@ -0,0 +1,52 @@
+/* Test that we do not have ice when compile */
+/* { dg-do compile } */
+/* { dg-options 

[Bug target/112743] RISC-V: building FAIL with -march=rv64(or rv32)gc_zve32f_zvfh_zfh

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

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

--- Comment #5 from GCC Commits  ---
The master branch has been updated by Pan Li :

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

commit r14-6068-ge5bbeedcf7020dfa3870d11cf2b85bc048655698
Author: Pan Li 
Date:   Thu Nov 30 15:08:50 2023 +0800

RISC-V: Bugfix for legitimize move when get vec mode in zve32f

If we want to extract 64bit value but ELEN < 64, we use RVV
vector mode with EEW = 32 to extract the highpart and lowpart.
However, this approach doesn't honor DFmode when movdf pattern
when ZVE32f and of course results in ICE when zve32f.

This patch would like to reuse the approach with some additional
handing, consider lowpart bits is meaningless for FP mode, we need
one int reg as bridge here. For example:

rtx tmp = gen_rtx_reg (DImode)
reg:DI = reg:DF (fmv.d.x) // Move DF reg to DI
...
perform the extract for high and low parts
...
reg:DF = reg:DI (fmv.x.d) // Move DI reg back to DF after all done

PR target/112743

gcc/ChangeLog:

* config/riscv/riscv.cc (riscv_legitimize_move): Take the
exist (U *mode) and handle DFmode like DImode when EEW is
32bits for ZVE32F.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/base/pr112743-2.c: New test.

Signed-off-by: Pan Li 

[Bug middle-end/112822] [14 regression] ICE: invalid RHS for gimple memory store after r14-5831-gaae723d360ca26

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |14.0

[Bug middle-end/112822] [14 regression] ICE: invalid RHS for gimple memory store after r14-5831-gaae723d360ca26

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

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

--- Comment #1 from Andrew Pinski  ---
>This is a huge C++ program that I have not cut down yet.

I think it didn't attach because it was too big, maybe compress and attach
that.

[Bug middle-end/112822] New: [14 regression] ICE: invalid RHS for gimple memory store after r14-5831-gaae723d360ca26

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

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

Bug ID: 112822
   Summary: [14 regression] ICE: invalid RHS for gimple memory
store after r14-5831-gaae723d360ca26
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:aae723d360ca26cd9fd0b039fb0a616bd0eae363, r14-5831-gaae723d360ca26

commit aae723d360ca26cd9fd0b039fb0a616bd0eae363 (HEAD)
Author: Martin Jambor 
Date:   Fri Nov 24 17:32:35 2023 +0100

sra: SRA of non-escaped aggregates passed by reference to calls


This is a huge C++ program that I have not cut down yet.  I will look at that
on Monday if need be.


seurer@ltcden2-lp1:~/tst$ ~/gcc/git/install/gcc-test/bin/g++ -w -O3 -c small.i

small.i: In function 'std::enable_if_t<(!Rows == 1) && (Depth != 1)) &&
(OA == Eigen::ColMajor)) || (((Depth == 1) && (Rows != 1)) && (OA ==
Eigen::RowMajor))) || (((Cols == 1) && (Depth != 1)) && (OB ==
Eigen::RowMajor))) || (((Depth == 1) && (Cols != 1)) && (OB ==
Eigen::ColMajor))) || (((Rows == 1) && (Cols != 1)) && (OC ==
Eigen::ColMajor))) || (((Cols == 1) && (Rows != 1)) && (OC ==
Eigen::RowMajor, void> test_lazy_single(int, int, int) [with T =
std::complex; int Rows = 1; int Cols = 4; int Depth = 6; int OC = 1;
int OA = 1; int OB = 1]':
small.i:133795:1: error: invalid RHS for gimple memory store:
'view_convert_expr'
133795 | test_lazy_single(int rows, int cols, int depth)
   | ^~~~
D$_M_value

VIEW_CONVERT_EXPR<_ComplexT>(C_1302);

# .MEM_1318 = VDEF <.MEM_1313>
D$_M_value = VIEW_CONVERT_EXPR<_ComplexT>(C_1302);
small.i:133795:1: error: invalid RHS for gimple memory store:
'view_convert_expr'
D$16$_M_value

VIEW_CONVERT_EXPR<_ComplexT>(C$16_1303);

# .MEM_1319 = VDEF <.MEM_1318>
D$16$_M_value = VIEW_CONVERT_EXPR<_ComplexT>(C$16_1303);
small.i:133795:1: error: invalid RHS for gimple memory store:
'view_convert_expr'
D$32$_M_value

VIEW_CONVERT_EXPR<_ComplexT>(C$32_1304);

# .MEM_1320 = VDEF <.MEM_1319>
D$32$_M_value = VIEW_CONVERT_EXPR<_ComplexT>(C$32_1304);
small.i:133795:1: error: invalid RHS for gimple memory store:
'view_convert_expr'
D$48$_M_value

VIEW_CONVERT_EXPR<_ComplexT>(C$48_1309);

# .MEM_1323 = VDEF <.MEM_1320>
D$48$_M_value = VIEW_CONVERT_EXPR<_ComplexT>(C$48_1309);
during GIMPLE pass: sra
small.i:133795:1: internal compiler error: verify_gimple failed
0x11136103 verify_gimple_in_cfg(function*, bool, bool)
/home/seurer/gcc/git/gcc-test/gcc/tree-cfg.cc:5662
0x10f27edf execute_function_todo
/home/seurer/gcc/git/gcc-test/gcc/passes.cc:2088
0x10f28eab do_per_function
/home/seurer/gcc/git/gcc-test/gcc/passes.cc:1687
0x10f290cb execute_todo
/home/seurer/gcc/git/gcc-test/gcc/passes.cc:2142

Re: Re: [PATCH 2/6] c: Turn int-conversion warnings into permerrors

[钟居哲]

No. GLIBC 2.37 also failed:

make[4]: Leaving directory 
'/work/home/jzzhong/work/toolchain/riscv/build/dev-rv64gcv_zvfh_zfh-lp64d-medany-linux-spike-debug/build-newlib/riscv64-unknown-elf/newlib'
  CC   libm/complex/libm_a-casinhl.o
make[3]: *** [Makefile:5283: all] Error 2
make[3]: Leaving directory 
'/work/home/jzzhong/work/toolchain/riscv/build/dev-rv64gcv_zvfh_zfh-lp64d-medany-linux-spike-debug/build-newlib/riscv64-unknown-elf/newlib'
make[2]: *** [Makefile:8492: all-target-newlib] Error 2
make[2]: Leaving directory 
'/work/home/jzzhong/work/toolchain/riscv/build/dev-rv64gcv_zvfh_zfh-lp64d-medany-linux-spike-debug/build-newlib'
make[1]: *** [Makefile:879: all] Error 2
make[1]: Leaving directory 
'/work/home/jzzhong/work/toolchain/riscv/build/dev-rv64gcv_zvfh_zfh-lp64d-medany-linux-spike-debug/build-newlib'
make: *** [Makefile:624: stamps/build-newlib] Error 2
make: *** Waiting for unfinished jobs
  CC   libm/complex/libm_a-csinhl.o
/work/home/jzzhong/work/toolchain/riscv/build/dev-rv64gcv_zvfh_zfh-lp64d-medany-linux-spike-debug/../../newlib/newlib/libm/complex/ccoshl.c:
 In function 'ccoshl':
/work/home/jzzhong/work/toolchain/riscv/build/dev-rv64gcv_zvfh_zfh-lp64d-medany-linux-spike-debug/../../newlib/newlib/libm/complex/ccoshl.c:43:13:
 error: implicit declaration of function 'coshl'; did you mean 'coshf'? 
[-Wimplicit-function-declaration]
   43 | w = coshl(x) * cosl(y) + (sinhl(x) * sinl(y)) * I;
  | ^
  | coshf
/work/home/jzzhong/work/toolchain/riscv/build/dev-rv64gcv_zvfh_zfh-lp64d-medany-linux-spike-debug/../../newlib/newlib/libm/complex/ccoshl.c:43:24:
 error: implicit declaration of function 'cosl'; did you mean 'cosf'? 
[-Wimplicit-function-declaration]
   43 | w = coshl(x) * cosl(y) + (sinhl(x) * sinl(y)) * I;
  |^~~~
  |cosf
/work/home/jzzhong/work/toolchain/riscv/build/dev-rv64gcv_zvfh_zfh-lp64d-medany-linux-spike-debug/../../newlib/newlib/libm/complex/clogl.c:
 In function 'clogl':
/work/home/jzzhong/work/toolchain/riscv/build/dev-rv64gcv_zvfh_zfh-lp64d-medany-linux-spike-debug/../../newlib/newlib/libm/complex/ccoshl.c:43:35:
 error: implicit declaration of function 'sinhl'; did you mean 'sinhf'? 
[-Wimplicit-function-declaration]
   43 | w = coshl(x) * cosl(y) + (sinhl(x) * sinl(y)) * I;
  |   ^
  |   sinhf
/work/home/jzzhong/work/toolchain/riscv/build/dev-rv64gcv_zvfh_zfh-lp64d-medany-linux-spike-debug/../../newlib/newlib/libm/complex/clogl.c:42:13:
 error: implicit declaration of function 'logl'; did you mean 'logf'? 
[-Wimplicit-function-declaration]
   42 | p = logl(rr);
  | ^~~~
  | logf
/work/home/jzzhong/work/toolchain/riscv/build/dev-rv64gcv_zvfh_zfh-lp64d-medany-linux-spike-debug/../../newlib/newlib/libm/complex/ccoshl.c:43:46:
 error: implicit declaration of function 'sinl'; did you mean 'sinf'? 
[-Wimplicit-function-declaration]
   43 | w = coshl(x) * cosl(y) + (sinhl(x) * sinl(y)) * I;
  |  ^~~~
  |  sinf
/work/home/jzzhong/work/toolchain/riscv/build/dev-rv64gcv_zvfh_zfh-lp64d-medany-linux-spike-debug/../../newlib/newlib/libm/complex/clogl.c:43:14:
 error: implicit declaration of function 'atan2l'; did you mean 'atan2f'? 
[-Wimplicit-function-declaration]
   43 | rr = atan2l(cimagl(z), creall(z));
  |  ^~
  |  atan2f
  CC   libm/complex/libm_a-csinl.o
/work/home/jzzhong/work/toolchain/riscv/build/dev-rv64gcv_zvfh_zfh-lp64d-medany-linux-spike-debug/../../newlib/newlib/libm/complex/cexpl.c:
 In function 'cexpl':
/work/home/jzzhong/work/toolchain/riscv/build/dev-rv64gcv_zvfh_zfh-lp64d-medany-linux-spike-debug/../../newlib/newlib/libm/complex/cexpl.c:43:13:
 error: implicit declaration of function 'expl'; did you mean 'expf'? 
[-Wimplicit-function-declaration]
   43 | r = expl(x);
  | ^~~~
  | expf
/work/home/jzzhong/work/toolchain/riscv/build/dev-rv64gcv_zvfh_zfh-lp64d-medany-linux-spike-debug/../../newlib/newlib/libm/complex/cexpl.c:44:17:
 error: implicit declaration of function 'cosl'; did you mean 'cosf'? 
[-Wimplicit-function-declaration]
   44 | w = r * cosl(y) + r * sinl(y) * I;
  | ^~~~
  | cosf
/work/home/jzzhong/work/toolchain/riscv/build/dev-rv64gcv_zvfh_zfh-lp64d-medany-linux-spike-debug/../../newlib/newlib/libm/complex/cexpl.c:44:31:
 error: implicit declaration of function 'sinl'; did you mean 'sinf'? 
[-Wimplicit-function-declaration]
   44 | w = r * cosl(y) + r * sinl(y) * I;
  |   ^~~~
  |   sinf

[Bug ada/112821] New: GNAT issues bug box on mismatched []

[prosfilaes at gmail dot com via Gcc-bugs]

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

Bug ID: 112821
   Summary: GNAT issues bug box on mismatched []
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: prosfilaes at gmail dot com
CC: dkm at gcc dot gnu.org
  Target Milestone: ---

x86_64-linux-gnu-gcc-13 -c -gnat2022 lexer.ads
+===GNAT BUG DETECTED==+
| 13.2.0 (x86_64-linux-gnu) Program_Error par-ch4.adb:365 explicit raise   |
| Error detected at lexer.ads:5:18 |
| Compiling lexer.ads  |
| Please submit a bug report; see https://gcc.gnu.org/bugs/ .  |
| Use a subject line meaningful to you and us to track the bug.|
| Include the entire contents of this bug box in the report.   |
| Include the exact command that you entered.  |
| Also include sources listed below.   |
+==+

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

lexer.ads

compilation abandoned
gnatmake: "lexer.ads" compilation error

package Lexer is

keyword_list : constant array (Natural range <>) of St :=
[
+"xor"
[;


end Lexer;

The code is erroneous, but GNAT should give an appropriate message instead of
erroring out.

[Bug c++/112820] New: vtable not emitted correctly from module when compiling with -g

[michael.kenzel at gmail dot com via Gcc-bugs]

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

Bug ID: 112820
   Summary: vtable not emitted correctly from module when
compiling with -g
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: michael.kenzel at gmail dot com
  Target Milestone: ---

When compiling a class with virtual member functions declared in a module
interface unit and defined in a module implementation unit with -g, the vtable
seems to not get emitted correctly, resulting in linker errors.

example:

// io.ixx
export module io;

export struct error
{
virtual const char* what() const noexcept;
};

// io-impl.cpp
module io;

const char* error::what() const noexcept
{
return "bla";
}

// main.cpp
import io;

int main()
{
error{};
}

compile with
g++ -std=c++23 -fmodules-ts -g -c -x c++ io.ixx
g++ -std=c++23 -fmodules-ts -g -c -x c++ io-impl.cpp
g++ -std=c++23 -fmodules-ts -g -c -x c++ main.cpp
g++ main.o io.o io-impl.o

produces
main.o: in function `error@io::error()':
main.cpp:3:(.text._ZNW2io5errorC2Ev[_ZNW2io5errorC5Ev]+0x8): undefined
reference to `vtable for error@io'
main.cpp:3:(.text._ZNW2io5errorC2Ev[_ZNW2io5errorC5Ev]+0xc): undefined
reference to `vtable for error@io'

Removing the -g from the first two commands resolves the problem, so this seems
to be tied to debugging information somehow. While the vtable will only be
emitted into io-impl.o, interestingly, it is apparently necessary to remove -g
from both the io-impo.o and the io.o commands for the vtable to be emitted.

Re: [PATCH v6 1/1] c++: Initial support for P0847R7 (Deducing This) [PR102609]

[waffl3x]

On Friday, December 1st, 2023 at 9:52 AM, Jason Merrill  
wrote:


> 
> 
> On 12/1/23 01:02, waffl3x wrote:
> 
> > I ran into another issue while devising tests for redeclarations of
> > xobj member functions as static member functions and vice versa. I am
> > pretty sure by the literal wording of the standard, this is well formed.
> > 
> > template
> > concept Constrain = true;
> > 
> > struct S {
> > void f(this auto, Constrain auto) {};
> > static void f(Constrain auto) {};
> > 
> > void g(this auto const&, Constrain auto) {};
> > static void g(Constrain auto) {};
> > 
> > void h(this auto&&, Constrain auto) {};
> > static void h(Constrain auto) {};
> > };
> > 
> > And also,
> > 
> > struct S{
> > void f(this auto) {};
> > static void f() {};
> > 
> > void g(this auto const&) {};
> > static void g() {};
> > 
> > void h(this auto&&) {};
> > static void h() {};
> > };
> > 
> > I wrote these tests expecting them to be ill-formed, and found what I
> > thought was a bug when they were not diagnosed as redecelarations.
> > However, given how the code for resolving overloads and determining
> > redeclarations looks, I believe this is actually well formed on a
> > technicality. I can't find the passages in the standard that specify
> > this so I can't be sure.
> 
> 
> I think the relevant section is
> https://eel.is/c++draft/basic.scope.scope
> 
> > Anyway, the template parameter list differs because of the deduced
> > object parameter. Now here is the question, you are required to ignore
> > the object parameter when determining if these are redeclarations or
> > not, but what about the template parameters associated with the object
> > parameter? Am I just missing the passage that specifies this or is this
> > an actual defect in the standard?
> 
> 
> I think that since they differ in template parameters, they don't
> correspond under https://eel.is/c++draft/basic.scope.scope#4.5 so they
> can be overloaded.
> 
> This is specified in terms of the template-head grammar non-terminal,
> but elsewhere we say that abbreviated templates are equivalent to
> writing out the template parameters explicitly.
> 
> > The annoying thing is, even if this was brought up, I think the only
> > solution is to ratify these examples as well formed.
> 
> 
> Yes.
> 
> Jason

I can't get over that I feel like this goes against the spirit of the
specification. Just because an object argument is deduced should not
suddenly mean we take it into account. Too bad there's no good solution.

I especially don't like that that the following case is ambiguous. I
understand why, but I don't like it.

template
concept Constrain = true;

struct S {
  int f(this auto, Constrain auto) {};
  static f(auto) {};
};
main() {
  S{}.f(0);
}

I would like to see this changed honestly. When an ambiguity is
encountered, the more constrained function should be taken into account
even if they normally can't be considered. Is there some pitfall with
this line of thinking that kept it out of the standard? Is it just a
case of "too hard to specify" or is there some reason it's impossible
to do in all but the simplest of cases?

Anyway while I do think this behavior is bad (not wrong according to
the standard, but bad imo), I recognize I don't have time to think
about it right now so I'll go back to working on the patch for the time
being.

Alex

Re: [PATCH 2/6] c: Turn int-conversion warnings into permerrors

[Sam James]

钟居哲  writes:

> Hi, This patch cause error on building newlib/glibc/musl on RISC-V port:
>
> /work/home/jzzhong/work/toolchain/riscv/build/dev-rv64gcv_zvfh_zfh-lp64d-medany-newlib-spike-debug/../../newlib/libgloss/riscv/sys_access.c:8:40:
> error: passing argument 3 of 'syscall_errno' makes integer from pointer 
> without a cast [-Wint-conversion]
> 8 |   return syscall_errno (SYS_access, 2, file, mode, 0, 0, 0, 0);
>   |^~~~
>   ||
>   |const char *

This looks like an issue in newlib. We expect broken code to be broken
by the recent changes. Can you investigate it on the newlib side?

Thanks.

Re: [PATCH 2/6] c: Turn int-conversion warnings into permerrors

[Patrick O'Neill]

Hi Juzhe,

I can confirm the failure on Newlib.
I'm not seeing any issues on glibc 2.37.
I haven't tried to build musl.

Since this patch promotes warnings to errors breakages were probably 
expected.

The fix may require changes to newlib to remove the errors.
I've hacked together a series of patches on top of newlib 4.3.0 that 
resolves these issues (but I think they'd need more work to be 
upstream-able):

https://github.com/patrick-rivos/riscv-gnu-toolchain/tree/35d8e8c486bd2f6e3e2e673db8d2b979309a6de4/fixups/newlib

@Thomas @Florian am I right in assuming that breakages were expected/the 
fix should come from fixing the warnings?


Thanks,
Patrick

On 12/1/23 16:33, 钟居哲 wrote:

Hi, This patch cause error on building newlib/glibc/musl on RISC-V port:

/work/home/jzzhong/work/toolchain/riscv/build/dev-rv64gcv_zvfh_zfh-lp64d-medany-newlib-spike-debug/../../newlib/libgloss/riscv/sys_access.c:8:40: 
error: passing argument 3 of 'syscall_errno' makes integer from 
pointer without a cast [-Wint-conversion]

    8 |   return syscall_errno (SYS_access, 2, file, mode, 0, 0, 0, 0);
      |                                        ^~~~
      |                                        |
      |                                        const char *
In file included from 
/work/home/jzzhong/work/toolchain/riscv/build/dev-rv64gcv_zvfh_zfh-lp64d-medany-newlib-spike-debug/../../newlib/libgloss/riscv/sys_access.c:2:
/work/home/jzzhong/work/toolchain/riscv/build/dev-rv64gcv_zvfh_zfh-lp64d-medany-newlib-spike-debug/../../newlib/libgloss/riscv/internal_syscall.h:66:38: 
note: expected 'long int' but argument is of type 'const char *'
   66 | syscall_errno(long n, int argc, long _a0, long _a1, long _a2, 
long _a3, long _a4, long _a5)

      |                                 ~^~~
/work/home/jzzhong/work/toolchain/riscv/build/dev-rv64gcv_zvfh_zfh-lp64d-medany-newlib-spike-debug/../../newlib/libgloss/riscv/sys_utime.c:5:39: 
warning: 'struct utimbuf' declared inside parameter list will not be 
visible outside of this definition or declaration

    5 | _utime(const char *path, const struct utimbuf *times)
      |                                       ^~~
/work/home/jzzhong/work/toolchain/riscv/build/dev-rv64gcv_zvfh_zfh-lp64d-medany-newlib-spike-debug/../../newlib/libgloss/riscv/sys_faccessat.c: 
In function '_faccessat':
/work/home/jzzhong/work/toolchain/riscv/build/dev-rv64gcv_zvfh_zfh-lp64d-medany-newlib-spike-debug/../../newlib/libgloss/riscv/sys_faccessat.c:7:50: 
error: passing argument 4 of 'syscall_errno' makes integer from 
pointer without a cast [-Wint-conversion]
    7 |   return syscall_errno (SYS_faccessat, 4, dirfd, file, mode, 
flags, 0, 0);

      | ^~~~
      |                                                  |
      | const char *
In file included from 
/work/home/jzzhong/work/toolchain/riscv/build/dev-rv64gcv_zvfh_zfh-lp64d-medany-newlib-spike-debug/../../newlib/libgloss/riscv/sys_faccessat.c:2:
/work/home/jzzhong/work/toolchain/riscv/build/dev-rv64gcv_zvfh_zfh-lp64d-medany-newlib-spike-debug/../../newlib/libgloss/riscv/internal_syscall.h:66:48: 
note: expected 'long int' but argument is of type 'const char *'
   66 | syscall_errno(long n, int argc, long _a0, long _a1, long _a2, 
long _a3, long _a4, long _a5)

      |                                           ~^~~
make[5]: *** [Makefile:3315: riscv/riscv_libgloss_a-sys_access.o] Error 1
make[5]: *** Waiting for unfinished jobs
/work/home/jzzhong/work/toolchain/riscv/build/dev-rv64gcv_zvfh_zfh-lp64d-medany-newlib-spike-debug/../../newlib/libgloss/riscv/sys_open.c: 
In function '_open':
/work/home/jzzhong/work/toolchain/riscv/build/dev-rv64gcv_zvfh_zfh-lp64d-medany-newlib-spike-debug/../../newlib/libgloss/riscv/sys_open.c:8:38: 
error: passing argument 3 of 'syscall_errno' makes integer from 
pointer without a cast [-Wint-conversion]

    8 |   return syscall_errno (SYS_open, 3, name, flags, mode, 0, 0, 0);
      |                                      ^~~~
      |                                      |
      |                                      const char *
In file included from 
/work/home/jzzhong/work/toolchain/riscv/build/dev-rv64gcv_zvfh_zfh-lp64d-medany-newlib-spike-debug/../../newlib/libgloss/riscv/sys_open.c:2:
/work/home/jzzhong/work/toolchain/riscv/build/dev-rv64gcv_zvfh_zfh-lp64d-medany-newlib-spike-debug/../../newlib/libgloss/riscv/internal_syscall.h:66:38: 
note: expected 'long int' but argument is of type 'const char *'
   66 | syscall_errno(long n, int argc, long _a0, long _a1, long _a2, 
long _a3, long _a4, long _a5)

      |                                 ~^~~
/work/home/jzzhong/work/toolchain/riscv/build/dev-rv64gcv_zvfh_zfh-lp64d-medany-newlib-spike-debug/../../newlib/libgloss/riscv/sys_openat.c: 
In function '_openat':
/work/home/jzzhong/work/toolchain/riscv/build/dev-rv64gcv_zvfh_zfh-lp64d-medany-newlib-spike-debug/../../newlib/libgloss/riscv/sys_openat.c:7:47: 
error: passing argument 4 of 'syscall_errno' makes integer 

[Bug tree-optimization/112819] New: rearrange branches to improve code generation

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

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

Bug ID: 112819
   Summary: rearrange branches to improve code generation
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

Take:
```
bool src(char *a, int l) {
if(l < 1) {
return false;
}
if(*a != 'a') {
return false;
}
if(l < 2) {
return false;
}
return true;
}

bool tgt(char *a, int l) {
if(l < 1) {
return false;
}
if(l < 2) {
return false;
}
if(*a != 'a') {
return false;
}
return true;
}
```
You would expect these 2 to produce both the same code but only tgt produces
decent code. That is because we can merge `l < 1` with `l < 2` into just `l <
2` (or `l <= 1`).

This might be an reassociation problem or something else.

Re: [PATCH v4] RISC-V: Bugfix for legitimize move when get vec mode in zve32f

[钟居哲]

LGTM



juzhe.zh...@rivai.ai
 
From: pan2.li
Date: 2023-12-02 08:59
To: gcc-patches
CC: juzhe.zhong; pan2.li; yanzhang.wang; kito.cheng
Subject: [PATCH v4] RISC-V: Bugfix for legitimize move when get vec mode in 
zve32f
From: Pan Li 
 
If we want to extract 64bit value but ELEN < 64, we use RVV
vector mode with EEW = 32 to extract the highpart and lowpart.
However, this approach doesn't honor DFmode when movdf pattern
when ZVE32f and of course results in ICE when zve32f.
 
This patch would like to reuse the approach with some additional
handing, consider lowpart bits is meaningless for FP mode, we need
one int reg as bridge here. For example:
 
rtx tmp = gen_rtx_reg (DImode)
reg:DI = reg:DF (fmv.d.x) // Move DF reg to DI
...
perform the extract for high and low parts
...
reg:DF = reg:DI (fmv.x.d) // Move DI reg back to DF after all done
 
PR target/112743
 
gcc/ChangeLog:
 
* config/riscv/riscv.cc (riscv_legitimize_move): Take the
exist (U *mode) and handle DFmode like DImode when EEW is
32bits for ZVE32F.
 
gcc/testsuite/ChangeLog:
 
* gcc.target/riscv/rvv/base/pr112743-2.c: New test.
 
Signed-off-by: Pan Li 
---
gcc/config/riscv/riscv.cc | 63 +--
.../gcc.target/riscv/rvv/base/pr112743-2.c| 52 +++
2 files changed, 95 insertions(+), 20 deletions(-)
create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/pr112743-2.c
 
diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index a4fc858fb50..84512dcdc68 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -2605,41 +2605,64 @@ riscv_legitimize_move (machine_mode mode, rtx dest, rtx 
src)
   unsigned int nunits = vmode_size > mode_size ? vmode_size / mode_size : 
1;
   scalar_mode smode = as_a (mode);
   unsigned int index = SUBREG_BYTE (src).to_constant () / mode_size;
-  unsigned int num = smode == DImode && !TARGET_VECTOR_ELEN_64 ? 2 : 1;
+  unsigned int num = known_eq (GET_MODE_SIZE (smode), 8)
+ && !TARGET_VECTOR_ELEN_64 ? 2 : 1;
+  bool need_int_reg_p = false;
   if (num == 2)
{
  /* If we want to extract 64bit value but ELEN < 64,
 we use RVV vector mode with EEW = 32 to extract
 the highpart and lowpart.  */
+   need_int_reg_p = smode == DFmode;
  smode = SImode;
  nunits = nunits * 2;
}
-  vmode = riscv_vector::get_vector_mode (smode, nunits).require ();
-  rtx v = gen_lowpart (vmode, SUBREG_REG (src));
-  for (unsigned int i = 0; i < num; i++)
+  if (riscv_vector::get_vector_mode (smode, nunits).exists ())
{
-   rtx result;
-   if (num == 1)
- result = dest;
-   else if (i == 0)
- result = gen_lowpart (smode, dest);
-   else
- result = gen_reg_rtx (smode);
-   riscv_vector::emit_vec_extract (result, v, index + i);
+   rtx v = gen_lowpart (vmode, SUBREG_REG (src));
+   rtx int_reg = dest;
-   if (i == 1)
+   if (need_int_reg_p)
{
-   rtx tmp
- = expand_binop (Pmode, ashl_optab, gen_lowpart (Pmode, result),
- gen_int_mode (32, Pmode), NULL_RTX, 0,
- OPTAB_DIRECT);
-   rtx tmp2 = expand_binop (Pmode, ior_optab, tmp, dest, NULL_RTX, 0,
-OPTAB_DIRECT);
-   emit_move_insn (dest, tmp2);
+   int_reg = gen_reg_rtx (DImode);
+   emit_move_insn (int_reg, gen_lowpart (GET_MODE (int_reg), dest));
}
+
+   for (unsigned int i = 0; i < num; i++)
+ {
+   rtx result;
+   if (num == 1)
+ result = int_reg;
+   else if (i == 0)
+ result = gen_lowpart (smode, int_reg);
+   else
+ result = gen_reg_rtx (smode);
+
+   riscv_vector::emit_vec_extract (result, v, index + i);
+
+   if (i == 1)
+ {
+   rtx tmp = expand_binop (Pmode, ashl_optab,
+   gen_lowpart (Pmode, result),
+   gen_int_mode (32, Pmode), NULL_RTX, 0,
+   OPTAB_DIRECT);
+   rtx tmp2 = expand_binop (Pmode, ior_optab, tmp, int_reg,
+NULL_RTX, 0,
+OPTAB_DIRECT);
+   emit_move_insn (int_reg, tmp2);
+ }
+ }
+
+   if (need_int_reg_p)
+ emit_move_insn (dest, gen_lowpart (GET_MODE (dest), int_reg));
+   else
+ emit_move_insn (dest, int_reg);
}
+  else
+ gcc_unreachable ();
+
   return true;
 }
   /* Expand
diff --git a/gcc/testsuite/gcc.target/riscv/rvv/base/pr112743-2.c 
b/gcc/testsuite/gcc.target/riscv/rvv/base/pr112743-2.c
new file mode 100644
index 000..fdb35fd70f2
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/rvv/base/pr112743-2.c
@@ -0,0 +1,52 @@
+/* Test that we do not have ice when compile */
+/* { dg-do compile } */
+/* { dg-options "-march=rv64gc_zve32f_zvfh_zfh -mabi=lp64 -O2" } */
+
+#include 
+
+union double_union
+{
+  double d;
+  __uint32_t i[2];
+};
+
+#define word0(x)  (x.i[1])
+#define word1(x)  (x.i[0])
+
+#define P 53
+#define Exp_shift 20
+#define Exp_msk1  ((__uint32_t)0x10L)
+#define Exp_mask  ((__uint32_t)0x7ff0L)
+
+double ulp (double _x)
+{
+  union double_union x, a;
+  register int L;
+
+  x.d = _x;
+  L = (word0 (x) & Exp_mask) - (P - 1) * Exp_msk1;
+
+  if (L > 0)
+{
+  L |= Exp_msk1 >> 4;
+  word0 (a) = 

[Bug tree-optimization/112818] [14 regression] ICE when building accel-ppp (error: conversion of register to a different size in ‘view_convert_expr’, verify_gimple failed)

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

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

--- Comment #3 from Sam James  ---
Created attachment 56766
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56766=edit
reduced.i

cvise just finished here with this, not massaged it by hand though

[PATCH v4] RISC-V: Bugfix for legitimize move when get vec mode in zve32f

[pan2 . li]

From: Pan Li 

If we want to extract 64bit value but ELEN < 64, we use RVV
vector mode with EEW = 32 to extract the highpart and lowpart.
However, this approach doesn't honor DFmode when movdf pattern
when ZVE32f and of course results in ICE when zve32f.

This patch would like to reuse the approach with some additional
handing, consider lowpart bits is meaningless for FP mode, we need
one int reg as bridge here. For example:

rtx tmp = gen_rtx_reg (DImode)
reg:DI = reg:DF (fmv.d.x) // Move DF reg to DI
...
perform the extract for high and low parts
...
reg:DF = reg:DI (fmv.x.d) // Move DI reg back to DF after all done

PR target/112743

gcc/ChangeLog:

* config/riscv/riscv.cc (riscv_legitimize_move): Take the
exist (U *mode) and handle DFmode like DImode when EEW is
32bits for ZVE32F.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/base/pr112743-2.c: New test.

Signed-off-by: Pan Li 
---
 gcc/config/riscv/riscv.cc | 63 +--
 .../gcc.target/riscv/rvv/base/pr112743-2.c| 52 +++
 2 files changed, 95 insertions(+), 20 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/pr112743-2.c

diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index a4fc858fb50..84512dcdc68 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -2605,41 +2605,64 @@ riscv_legitimize_move (machine_mode mode, rtx dest, rtx 
src)
   unsigned int nunits = vmode_size > mode_size ? vmode_size / mode_size : 
1;
   scalar_mode smode = as_a (mode);
   unsigned int index = SUBREG_BYTE (src).to_constant () / mode_size;
-  unsigned int num = smode == DImode && !TARGET_VECTOR_ELEN_64 ? 2 : 1;
+  unsigned int num = known_eq (GET_MODE_SIZE (smode), 8)
+   && !TARGET_VECTOR_ELEN_64 ? 2 : 1;
+  bool need_int_reg_p = false;
 
   if (num == 2)
{
  /* If we want to extract 64bit value but ELEN < 64,
 we use RVV vector mode with EEW = 32 to extract
 the highpart and lowpart.  */
+ need_int_reg_p = smode == DFmode;
  smode = SImode;
  nunits = nunits * 2;
}
-  vmode = riscv_vector::get_vector_mode (smode, nunits).require ();
-  rtx v = gen_lowpart (vmode, SUBREG_REG (src));
 
-  for (unsigned int i = 0; i < num; i++)
+  if (riscv_vector::get_vector_mode (smode, nunits).exists ())
{
- rtx result;
- if (num == 1)
-   result = dest;
- else if (i == 0)
-   result = gen_lowpart (smode, dest);
- else
-   result = gen_reg_rtx (smode);
- riscv_vector::emit_vec_extract (result, v, index + i);
+ rtx v = gen_lowpart (vmode, SUBREG_REG (src));
+ rtx int_reg = dest;
 
- if (i == 1)
+ if (need_int_reg_p)
{
- rtx tmp
-   = expand_binop (Pmode, ashl_optab, gen_lowpart (Pmode, result),
-   gen_int_mode (32, Pmode), NULL_RTX, 0,
-   OPTAB_DIRECT);
- rtx tmp2 = expand_binop (Pmode, ior_optab, tmp, dest, NULL_RTX, 0,
-  OPTAB_DIRECT);
- emit_move_insn (dest, tmp2);
+ int_reg = gen_reg_rtx (DImode);
+ emit_move_insn (int_reg, gen_lowpart (GET_MODE (int_reg), dest));
}
+
+ for (unsigned int i = 0; i < num; i++)
+   {
+ rtx result;
+ if (num == 1)
+   result = int_reg;
+ else if (i == 0)
+   result = gen_lowpart (smode, int_reg);
+ else
+   result = gen_reg_rtx (smode);
+
+ riscv_vector::emit_vec_extract (result, v, index + i);
+
+ if (i == 1)
+   {
+ rtx tmp = expand_binop (Pmode, ashl_optab,
+ gen_lowpart (Pmode, result),
+ gen_int_mode (32, Pmode), NULL_RTX, 0,
+ OPTAB_DIRECT);
+ rtx tmp2 = expand_binop (Pmode, ior_optab, tmp, int_reg,
+  NULL_RTX, 0,
+  OPTAB_DIRECT);
+ emit_move_insn (int_reg, tmp2);
+   }
+   }
+
+ if (need_int_reg_p)
+   emit_move_insn (dest, gen_lowpart (GET_MODE (dest), int_reg));
+ else
+   emit_move_insn (dest, int_reg);
}
+  else
+   gcc_unreachable ();
+
   return true;
 }
   /* Expand
diff --git a/gcc/testsuite/gcc.target/riscv/rvv/base/pr112743-2.c 
b/gcc/testsuite/gcc.target/riscv/rvv/base/pr112743-2.c
new file mode 100644
index 000..fdb35fd70f2
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/rvv/base/pr112743-2.c
@@ -0,0 +1,52 @@
+/* Test that we do not have ice when compile */
+/* { dg-do compile } */
+/* { dg-options 

Re: [PATCH v6] c++: implement P2564, consteval needs to propagate up [PR107687]

[Jason Merrill]

On 12/1/23 18:37, Marek Polacek wrote:

On Thu, Nov 30, 2023 at 06:34:01PM -0500, Jason Merrill wrote:

On 11/23/23 11:46, Marek Polacek wrote:

v5 greatly simplifies the code.


Indeed, it's much cleaner now.


I still need a new ff_ flag to signal that we can return immediately
after seeing an i-e expr.


That's still not clear to me:


+  /* In turn, maybe promote the function we find ourselves in...  */
+  if ((data->flags & ff_find_escalating_expr)
+ && DECL_IMMEDIATE_FUNCTION_P (decl)
+ /* ...but not if the call to DECL was constant; that is the
+"an immediate invocation that is not a constant expression"
+case.  */
+ && (e = cxx_constant_value (stmt, tf_none), e == error_mark_node))
+   {
+ /* Since we had to set DECL_ESCALATION_CHECKED_P before the walk,
+we call promote_function_to_consteval directly which doesn't
+check unchecked_immediate_escalating_function_p.  */
+ if (current_function_decl)
+   promote_function_to_consteval (current_function_decl);
+ *walk_subtrees = 0;
+ return stmt;
+   }


This is the one use of ff_find_escalating_expr, and it seems redundant with
the code immediately below, where we use complain (derived from
ff_mce_false) to decide whether to return immediately.  Can we remove this
hunk and the flag, and merge find_escalating_expr with cp_fold_immediate?


Ah, that works!  Hopefully done now.
  

I think you want to walk the function body for three-ish reasons:
1) at EOF, to check for escalation
2) at EOF, to check for errors
3) at error time, to explain escalation

It's not clear to me that we need a flag to distinguish between them. When
we encounter an immediate-escalating expression E:

A) if we're in an immediate-escalating function, escalate and return E (#1,
#3).
B) otherwise, if we're diagnosing, error and continue (#2).
C) otherwise, return E (individual expression mce_unknown walk from
constexpr.cc).


@@ -1178,11 +1388,19 @@ cp_fold_r (tree *stmt_p, int *walk_subtrees, void *data_
)
   *walk_subtrees = 0;
   /* Don't return yet, still need the cp_fold below.  */
 }
-  cp_fold_immediate_r (stmt_p, walk_subtrees, data);
+  else
+   cp_fold_immediate_r (stmt_p, walk_subtrees, data);
  }
*stmt_p = stmt = cp_fold (*stmt_p, data->flags);
+  /* For certain trees, like +foo(), the cp_fold below will remove the +,


s/below/above/?


Fixed.
  

+/* We've stashed immediate-escalating functions.  Now see if they indeed
+   ought to be promoted to consteval.  */
+
+void
+process_pending_immediate_escalating_fns ()
+{
+  /* This will be null for -fno-immediate-escalation.  */
+  if (!deferred_escalating_exprs)
+return;
+
+  for (auto e : *deferred_escalating_exprs)
+if (TREE_CODE (e) == FUNCTION_DECL && !DECL_ESCALATION_CHECKED_P (e))
+  cp_fold_immediate (_SAVED_TREE (e), mce_false, e);
+}
+
+/* We've escalated every function that could have been promoted to
+   consteval.  Check that we are not taking the address of a consteval
+   function.  */
+
+void
+check_immediate_escalating_refs ()
+{
+  /* This will be null for -fno-immediate-escalation.  */
+  if (!deferred_escalating_exprs)
+return;
+
+  for (auto ref : *deferred_escalating_exprs)
+{
+  if (TREE_CODE (ref) == FUNCTION_DECL)
+   continue;
+  tree decl = (TREE_CODE (ref) == PTRMEM_CST
+  ? PTRMEM_CST_MEMBER (ref)
+  : TREE_OPERAND (ref, 0));
+  if (DECL_IMMEDIATE_FUNCTION_P (decl))
+   taking_address_of_imm_fn_error (ref, decl);
+}
+
+  deferred_escalating_exprs = nullptr;
  }


Could these be merged, so you do a single loop of cp_fold_immediate over
function bodies or non-function expressions?  I'd expect that to work.


We seem to walk the hash table in a random order so I can't use one loop,
otherwise we could hit  before escalating f.


Is that a problem, since we recurse if we see a function that is still 
unchecked?



@@ -1045,90 +1191,138 @@ cp_fold_immediate_r (tree *stmt_p, int *walk_subtrees, 
void *data_)
   /* The purpose of this is not to emit errors for mce_unknown.  */
   const tsubst_flags_t complain = (data->flags & ff_mce_false
   ? tf_error : tf_none);
+  const tree_code code = TREE_CODE (stmt);
 
   /* No need to look into types or unevaluated operands.

  NB: This affects cp_fold_r as well.  */
-  if (TYPE_P (stmt) || unevaluated_p (TREE_CODE (stmt)))
+  if (TYPE_P (stmt) || unevaluated_p (code) || cp_unevaluated_operand)


Maybe check in_immediate_context here instead?


+  /* [expr.const]p16 "An expression or conversion is immediate-escalating if
+ it is not initially in an immediate function context and it is either
+ -- an immediate invocation that is not a constant expression and is not
+ a subexpression of an immediate invocation."
 
+ If we are in an immediate-escalating function, the 

[PATCH 2/6] c: Turn int-conversion warnings into permerrors

[钟居哲]

Hi, This patch cause error on building newlib/glibc/musl on RISC-V port:

/work/home/jzzhong/work/toolchain/riscv/build/dev-rv64gcv_zvfh_zfh-lp64d-medany-newlib-spike-debug/../../newlib/libgloss/riscv/sys_access.c:8:40:
 error: passing argument 3 of 'syscall_errno' makes integer from pointer 
without a cast [-Wint-conversion]
8 |   return syscall_errno (SYS_access, 2, file, mode, 0, 0, 0, 0);
  |^~~~
  ||
  |const char *
In file included from 
/work/home/jzzhong/work/toolchain/riscv/build/dev-rv64gcv_zvfh_zfh-lp64d-medany-newlib-spike-debug/../../newlib/libgloss/riscv/sys_access.c:2:
/work/home/jzzhong/work/toolchain/riscv/build/dev-rv64gcv_zvfh_zfh-lp64d-medany-newlib-spike-debug/../../newlib/libgloss/riscv/internal_syscall.h:66:38:
 note: expected 'long int' but argument is of type 'const char *'
   66 | syscall_errno(long n, int argc, long _a0, long _a1, long _a2, long _a3, 
long _a4, long _a5)
  | ~^~~
/work/home/jzzhong/work/toolchain/riscv/build/dev-rv64gcv_zvfh_zfh-lp64d-medany-newlib-spike-debug/../../newlib/libgloss/riscv/sys_utime.c:5:39:
 warning: 'struct utimbuf' declared inside parameter list will not be visible 
outside of this definition or declaration
5 | _utime(const char *path, const struct utimbuf *times)
  |   ^~~
/work/home/jzzhong/work/toolchain/riscv/build/dev-rv64gcv_zvfh_zfh-lp64d-medany-newlib-spike-debug/../../newlib/libgloss/riscv/sys_faccessat.c:
 In function '_faccessat':
/work/home/jzzhong/work/toolchain/riscv/build/dev-rv64gcv_zvfh_zfh-lp64d-medany-newlib-spike-debug/../../newlib/libgloss/riscv/sys_faccessat.c:7:50:
 error: passing argument 4 of 'syscall_errno' makes integer from pointer 
without a cast [-Wint-conversion]
7 |   return syscall_errno (SYS_faccessat, 4, dirfd, file, mode, flags, 0, 
0);
  |  ^~~~
  |  |
  |  const char *
In file included from 
/work/home/jzzhong/work/toolchain/riscv/build/dev-rv64gcv_zvfh_zfh-lp64d-medany-newlib-spike-debug/../../newlib/libgloss/riscv/sys_faccessat.c:2:
/work/home/jzzhong/work/toolchain/riscv/build/dev-rv64gcv_zvfh_zfh-lp64d-medany-newlib-spike-debug/../../newlib/libgloss/riscv/internal_syscall.h:66:48:
 note: expected 'long int' but argument is of type 'const char *'
   66 | syscall_errno(long n, int argc, long _a0, long _a1, long _a2, long _a3, 
long _a4, long _a5)
  |   ~^~~
make[5]: *** [Makefile:3315: riscv/riscv_libgloss_a-sys_access.o] Error 1
make[5]: *** Waiting for unfinished jobs
/work/home/jzzhong/work/toolchain/riscv/build/dev-rv64gcv_zvfh_zfh-lp64d-medany-newlib-spike-debug/../../newlib/libgloss/riscv/sys_open.c:
 In function '_open':
/work/home/jzzhong/work/toolchain/riscv/build/dev-rv64gcv_zvfh_zfh-lp64d-medany-newlib-spike-debug/../../newlib/libgloss/riscv/sys_open.c:8:38:
 error: passing argument 3 of 'syscall_errno' makes integer from pointer 
without a cast [-Wint-conversion]
8 |   return syscall_errno (SYS_open, 3, name, flags, mode, 0, 0, 0);
  |  ^~~~
  |  |
  |  const char *
In file included from 
/work/home/jzzhong/work/toolchain/riscv/build/dev-rv64gcv_zvfh_zfh-lp64d-medany-newlib-spike-debug/../../newlib/libgloss/riscv/sys_open.c:2:
/work/home/jzzhong/work/toolchain/riscv/build/dev-rv64gcv_zvfh_zfh-lp64d-medany-newlib-spike-debug/../../newlib/libgloss/riscv/internal_syscall.h:66:38:
 note: expected 'long int' but argument is of type 'const char *'
   66 | syscall_errno(long n, int argc, long _a0, long _a1, long _a2, long _a3, 
long _a4, long _a5)
  | ~^~~
/work/home/jzzhong/work/toolchain/riscv/build/dev-rv64gcv_zvfh_zfh-lp64d-medany-newlib-spike-debug/../../newlib/libgloss/riscv/sys_openat.c:
 In function '_openat':
/work/home/jzzhong/work/toolchain/riscv/build/dev-rv64gcv_zvfh_zfh-lp64d-medany-newlib-spike-debug/../../newlib/libgloss/riscv/sys_openat.c:7:47:
 error: passing argument 4 of 'syscall_errno' makes integer from pointer 
without a cast [-Wint-conversion]
7 |   return syscall_errno (SYS_openat, 4, dirfd, name, flags, mode, 0, 0);
  |   ^~~~
  |   |
  |   const char *
In file included from 
/work/home/jzzhong/work/toolchain/riscv/build/dev-rv64gcv_zvfh_zfh-lp64d-medany-newlib-spike-debug/../../newlib/libgloss/riscv/sys_openat.c:2:

[Bug libstdc++/28278] formatted I/O and calling width(0)

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

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

--- Comment #5 from Jonathan Wakely  ---
Created attachment 56765
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56765=edit
Martin's test code

Attaching the test code here, in case the link stops working.

[Bug c++/112775] Class template partial specialization with decltype(n) is wrongly rejected

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

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

--- Comment #2 from Andrew Pinski  ---
Note the workaround is to do just this:
```
template 
class A {};
```

[Bug c++/112775] Class template partial specialization with decltype(n) is wrongly rejected

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2023-12-02
 Status|UNCONFIRMED |NEW
   Keywords||diagnostic

--- Comment #1 from Andrew Pinski  ---
Confirmed. What is interesting is if we don't use -pedantic-errors, the
following is accepted:
```
template 
class A;
template 
class A {};
A b;
```

And even more if we have 2 different values for the 2/3rd arguments, it is
rejected as an incomplete class.

[Bug testsuite/112786] [14 Regression] gcc.dg/tree-ssa/scev-3.c scev-4.c and scev-5.c XPASSing on most ilp32 targets

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

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

--- Comment #3 from Hans-Peter Nilsson  ---
(In reply to Richard Biener from comment #2)
> Note they XPASS on the 13 branch as well IIRC.

XPASS without Alex patch?  Is that XPASS a typo for FAIL or PASS?

Either way, they FAIL, for ia32 say these results from gcc-testresults@:

i386-pc-solaris2.11
https://gcc.gnu.org/pipermail/gcc-testresults/2023-November/800123.html

x86_64-pc-linux-gnu -m32 (but not -mx32 nor default)
https://gcc.gnu.org/pipermail/gcc-testresults/2023-November/800107.html

i686-pc-linux-gnu
https://gcc.gnu.org/pipermail/gcc-testresults/2023-November/800113.html

And PASS for these:
sparc-sun-solaris2.11
https://gcc.gnu.org/pipermail/gcc-testresults/2023-November/800134.html

avr-unknown-none
https://gcc.gnu.org/pipermail/gcc-testresults/2023-November/800623.html

pru-unknown-elf
https://gcc.gnu.org/pipermail/gcc-testresults/2023-November/800630.html

[Bug bootstrap/112782] [14 Regression] stage2/3 differs when compiled with -mfix-r5900 on mips

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

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

--- Comment #6 from Andrew Pinski  ---
My bet is the code for -mfix-r5900 is not expecting the extra labels that is
produced for debuging ...

Anyways as I mentioned if -mfix-r5900 is the issue then it is a gas issue.

[Bug bootstrap/112782] [14 Regression] stage2/3 differs when compiled with -mfix-r5900 on mips

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://sourceware.org/bugz
   ||illa/show_bug.cgi?id=13509

--- Comment #5 from Andrew Pinski  ---
I can't remember exactly but I did file
https://sourceware.org/bugzilla/show_bug.cgi?id=13509 when I noticed a
bootstrap comparison failure a long time ago but I am not 100% sure if this is
the same issue or just a related one. But again I highly doubt this is not a
GCC issue, especially when -mfix-r5900 does almost nothing on the GCC side and
is only handled in gas.

[Bug bootstrap/112782] [14 Regression] stage2/3 differs when compiled with -mfix-r5900 on mips

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
   Keywords||compare-debug-failure
 Resolution|--- |MOVED

--- Comment #4 from Andrew Pinski  ---
-mfix-r5900 is all handled in gas rather than in GCC 

[Bug bootstrap/112782] [14 Regression] stage2/3 differs when compiled with -mfix-r5900 on mips

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

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

--- Comment #3 from Andrew Pinski  ---
I thought this was reported beforehand  ...

Reset your password

[Password Request via Gcc-bugs]

<<< image/gif: EXCLUDED >>>

[Bug ipa/112783] core dump on libxo when function is inlined

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #3 from Andrew Pinski  ---
The problem is not in GCC but rather a bad assumption on the code part.

Basically we have:

memcpy(nbuf, name, nlen);
...


if (!name)
...


But the check after a memcpy can be removed as passing a null pointer to memcpy
is undefined even if nlen is 0 here.


This patch to the sources fixes the issue for me:
```
diff --git a/libxo/libxo.c b/libxo/libxo.c
index 916a111..ea71723 100644
--- a/libxo/libxo.c
+++ b/libxo/libxo.c
@@ -4300,7 +4300,8 @@ xo_format_value (xo_handle_t *xop, const char *name,
ssize_t nlen,
if ((xsp->xs_flags & (XSF_EMIT | XSF_EMIT_KEY))
|| !(xsp->xs_flags & XSF_EMIT_LEAF_LIST)) {
char nbuf[nlen + 1];
-   memcpy(nbuf, name, nlen);
+if (name)
+ memcpy(nbuf, name, nlen);
nbuf[nlen] = '\0';

ssize_t rc = xo_transition(xop, 0, nbuf, XSS_EMIT_LEAF_LIST);
@@ -4324,7 +4325,8 @@ xo_format_value (xo_handle_t *xop, const char *name,
ssize_t nlen,

} else if (!(xsp->xs_flags & XSF_EMIT_KEY)) {
char nbuf[nlen + 1];
-   memcpy(nbuf, name, nlen);
+if (name)
+ memcpy(nbuf, name, nlen);
nbuf[nlen] = '\0';

ssize_t rc = xo_transition(xop, 0, nbuf, XSS_EMIT);
@@ -4342,7 +4344,8 @@ xo_format_value (xo_handle_t *xop, const char *name,
ssize_t nlen,
if ((xsp->xs_flags & XSF_EMIT_LEAF_LIST)
|| !(xsp->xs_flags & XSF_EMIT)) {
char nbuf[nlen + 1];
-   memcpy(nbuf, name, nlen);
+if (name)
+ memcpy(nbuf, name, nlen);
nbuf[nlen] = '\0';

ssize_t rc = xo_transition(xop, 0, nbuf, XSS_EMIT);

```

[PATCH v6] c++: implement P2564, consteval needs to propagate up [PR107687]

[Marek Polacek]

On Thu, Nov 30, 2023 at 06:34:01PM -0500, Jason Merrill wrote:
> On 11/23/23 11:46, Marek Polacek wrote:
> > v5 greatly simplifies the code.
> 
> Indeed, it's much cleaner now.
> 
> > I still need a new ff_ flag to signal that we can return immediately
> > after seeing an i-e expr.
> 
> That's still not clear to me:
> 
> > +  /* In turn, maybe promote the function we find ourselves in...  */
> > +  if ((data->flags & ff_find_escalating_expr)
> > + && DECL_IMMEDIATE_FUNCTION_P (decl)
> > + /* ...but not if the call to DECL was constant; that is the
> > +"an immediate invocation that is not a constant expression"
> > +case.  */
> > + && (e = cxx_constant_value (stmt, tf_none), e == error_mark_node))
> > +   {
> > + /* Since we had to set DECL_ESCALATION_CHECKED_P before the walk,
> > +we call promote_function_to_consteval directly which doesn't
> > +check unchecked_immediate_escalating_function_p.  */
> > + if (current_function_decl)
> > +   promote_function_to_consteval (current_function_decl);
> > + *walk_subtrees = 0;
> > + return stmt;
> > +   }
> 
> This is the one use of ff_find_escalating_expr, and it seems redundant with
> the code immediately below, where we use complain (derived from
> ff_mce_false) to decide whether to return immediately.  Can we remove this
> hunk and the flag, and merge find_escalating_expr with cp_fold_immediate?

Ah, that works!  Hopefully done now.
 
> I think you want to walk the function body for three-ish reasons:
> 1) at EOF, to check for escalation
> 2) at EOF, to check for errors
> 3) at error time, to explain escalation
> 
> It's not clear to me that we need a flag to distinguish between them. When
> we encounter an immediate-escalating expression E:
> 
> A) if we're in an immediate-escalating function, escalate and return E (#1,
> #3).
> B) otherwise, if we're diagnosing, error and continue (#2).
> C) otherwise, return E (individual expression mce_unknown walk from
> constexpr.cc).
> 
> > @@ -1178,11 +1388,19 @@ cp_fold_r (tree *stmt_p, int *walk_subtrees, void 
> > *data_
> > )
> >   *walk_subtrees = 0;
> >   /* Don't return yet, still need the cp_fold below.  */
> > }
> > -  cp_fold_immediate_r (stmt_p, walk_subtrees, data);
> > +  else
> > +   cp_fold_immediate_r (stmt_p, walk_subtrees, data);
> >  }
> >*stmt_p = stmt = cp_fold (*stmt_p, data->flags);
> > +  /* For certain trees, like +foo(), the cp_fold below will remove the +,
> 
> s/below/above/?

Fixed.
 
> > +/* We've stashed immediate-escalating functions.  Now see if they indeed
> > +   ought to be promoted to consteval.  */
> > +
> > +void
> > +process_pending_immediate_escalating_fns ()
> > +{
> > +  /* This will be null for -fno-immediate-escalation.  */
> > +  if (!deferred_escalating_exprs)
> > +return;
> > +
> > +  for (auto e : *deferred_escalating_exprs)
> > +if (TREE_CODE (e) == FUNCTION_DECL && !DECL_ESCALATION_CHECKED_P (e))
> > +  cp_fold_immediate (_SAVED_TREE (e), mce_false, e);
> > +}
> > +
> > +/* We've escalated every function that could have been promoted to
> > +   consteval.  Check that we are not taking the address of a consteval
> > +   function.  */
> > +
> > +void
> > +check_immediate_escalating_refs ()
> > +{
> > +  /* This will be null for -fno-immediate-escalation.  */
> > +  if (!deferred_escalating_exprs)
> > +return;
> > +
> > +  for (auto ref : *deferred_escalating_exprs)
> > +{
> > +  if (TREE_CODE (ref) == FUNCTION_DECL)
> > +   continue;
> > +  tree decl = (TREE_CODE (ref) == PTRMEM_CST
> > +  ? PTRMEM_CST_MEMBER (ref)
> > +  : TREE_OPERAND (ref, 0));
> > +  if (DECL_IMMEDIATE_FUNCTION_P (decl))
> > +   taking_address_of_imm_fn_error (ref, decl);
> > +}
> > +
> > +  deferred_escalating_exprs = nullptr;
> >  }
> 
> Could these be merged, so you do a single loop of cp_fold_immediate over
> function bodies or non-function expressions?  I'd expect that to work.

We seem to walk the hash table in a random order so I can't use one loop,
otherwise we could hit  before escalating f.  But there's not need for
two functions, so I've merged them into
process_and_check_pending_immediate_escalating_fns.

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

-- >8 --
This patch implements P2564, described at , whereby
certain functions are promoted to consteval.  For example:

  consteval int id(int i) { return i; }

  template 
  constexpr int f(T t)
  {
return t + id(t); // id causes f to be promoted to consteval
  }

  void g(int i)
  {
f (3);
  }

now compiles.  Previously the code was ill-formed: we would complain
that 't' in 'f' is not a constant expression.  Since 'f' is now
consteval, it means that the call to id(t) is in an immediate context,
so doesn't have to produce a constant -- this is how we allow consteval

[Bug ipa/112783] core dump on libxo when function is inlined

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

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

--- Comment #2 from Andrew Pinski  ---
   0x0040d178 <+152>:   call   0x401280 <__ctype_b_loc@plt>
=> 0x0040d17d <+157>:   movsbq (%r15),%rcx

r150x0 0


Seeing if I can reduce it ...

[Bug target/112817] RISC-V: RVV: provide a preprocessor macro for VLS codegen

[juzhe.zhong at rivai dot ai via Gcc-bugs]

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

--- Comment #7 from JuzheZhong  ---
(In reply to Vineet Gupta from comment #6)
> (In reply to JuzheZhong from comment #5)
> 
> > Support VLS codegen with -mrvv-vector-bits and attribute is reasonable to be
> > landed on GCC-14.
> 
> I don't think that is the reqmt for this issue. Just defining the
> preprocessor flag with existing gcc toggle for VLS codegen should be enough
> - as long as it generates same macro as llvm.

So, what do you mean ? I don't understand.
If you doesn't need attribute, how to fix the issue.

[Bug target/112817] RISC-V: RVV: provide a preprocessor macro for VLS codegen

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

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

--- Comment #6 from Vineet Gupta  ---
(In reply to JuzheZhong from comment #5)

> Support VLS codegen with -mrvv-vector-bits and attribute is reasonable to be
> landed on GCC-14.

I don't think that is the reqmt for this issue. Just defining the preprocessor
flag with existing gcc toggle for VLS codegen should be enough - as long as it
generates same macro as llvm.

Re: [PATCH] testsuite: scev: expect fail on ilp32

[Hans-Peter Nilsson]

> Date: Fri, 1 Dec 2023 08:07:14 +0100 (CET)
> From: Richard Biener 

> On Fri, 1 Dec 2023, Hans-Peter Nilsson wrote:
> 
> > > From: Hans-Peter Nilsson 
> > > Date: Thu, 30 Nov 2023 18:09:10 +0100
> > 
> > Richard B.:
> > > > > In the end we might need to move/duplicate the test to some
> > > > > gcc.target/* dir and restrict it to a specific tuning.
> > > 
> > > I intend to post two alternative patches to get this
> > > resolved:
> > > 1: Move the tests to gcc.target/i386/scev-[3-5].c
> > 
> > Subject: [PATCH 1/2] testsuite: Fix XPASS for gcc.dg/tree-ssa/scev-3.c, 
> > -4.c and -5.c [PR112786]
> > 
> > This is the first alternative, perhaps the more appropriate one.
> > 
> > Tested cris-elf, arm-eabi (default), x86_64-linux, ditto -m32,
> > h8300-elf and shle-linux; xpassing, skipped and passing as
> > applicable and intended.
> > 
> > Ok to commit?
> 
> Digging in history reveals the testcases were added by
> Jiangning Liu , not for any
> particular bugreport but "The problem is originally from a real benchmark,
> and the test case only tries to detect the GIMPLE level changes."
> 
> I'm not sure we can infer the testcase should be moved to
> gcc.target/arm/ because of that, but it does seem plausible.

It's been so long and so many changes since these tests were
regression guards, that the original target has lost
importance.  Heck, it was even xfail lp64 at one time!
According to my git dig, it's been adjusted for pass
changes, including reordering and dump output changes.  But
you know that; you've been instrumental in many of those
changes. :)

I'd say gcc.target/arm/ is the one target that's *not*
plausible, as according to Alex result differs between
subtargets.

> I read from your messages that the testcases pass on arm*-*-*?

Yes: they pass (currently XPASS) on arm-eabi and
arm-unknown-linux-gnueabi, default configurations.  But,
scev-3 and -5 fail with for example -mcpu=cortex-r5

brgds, H-P
PS. I'm open to just reverting the patch.  The s/ia32/ilp32/ is proven wrong.

[Bug tree-optimization/112818] [14 regression] ICE when building accel-ppp (error: conversion of register to a different size in ‘view_convert_expr’, verify_gimple failed)

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2023-12-01
 Status|UNCONFIRMED |NEW

[Bug tree-optimization/112818] [14 regression] ICE when building accel-ppp (error: conversion of register to a different size in ‘view_convert_expr’, verify_gimple failed)

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

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

--- Comment #2 from Andrew Pinski  ---
Created attachment 56764
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56764=edit
A little more

Re: [PATCH] RISC-V: Add vectorized strcmp.

[钟居哲]

lgtm



juzhe.zh...@rivai.ai
 
From: Robin Dapp
Date: 2023-12-01 23:23
To: gcc-patches; palmer; Kito Cheng; jeffreyalaw; juzhe.zh...@rivai.ai
CC: rdapp.gcc
Subject: [PATCH] RISC-V: Add vectorized strcmp.
Hi,
 
this patch adds a vectorized strcmp implementation and tests.  Similar
to strlen, expansion is still guarded by -minline-strcmp.  I just
realized I forgot to make it a series but this one is actually
dependent on the NFC patch and the rawmemchr fix before.
 
Regards
Robin
 
gcc/ChangeLog:
 
* config/riscv/riscv-protos.h (expand_strcmp): Declare.
* config/riscv/riscv-string.cc (riscv_expand_strcmp): Add
strategy handling and delegation to scalar and vector expanders.
(expand_strcmp): Vectorized implementation.
* config/riscv/riscv.md: Add TARGET_VECTOR to strcmp expander.
 
gcc/testsuite/ChangeLog:
 
* gcc.target/riscv/rvv/autovec/builtin/strcmp-run.c: New test.
* gcc.target/riscv/rvv/autovec/builtin/strcmp.c: New test.
---
gcc/config/riscv/riscv-protos.h   |   1 +
gcc/config/riscv/riscv-string.cc  | 161 +-
gcc/config/riscv/riscv.md |   3 +-
.../riscv/rvv/autovec/builtin/strcmp-run.c|  32 
.../riscv/rvv/autovec/builtin/strcmp.c|  13 ++
5 files changed, 206 insertions(+), 4 deletions(-)
create mode 100644 
gcc/testsuite/gcc.target/riscv/rvv/autovec/builtin/strcmp-run.c
create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/autovec/builtin/strcmp.c
 
diff --git a/gcc/config/riscv/riscv-protos.h b/gcc/config/riscv/riscv-protos.h
index c94c82a9973..5878a674413 100644
--- a/gcc/config/riscv/riscv-protos.h
+++ b/gcc/config/riscv/riscv-protos.h
@@ -558,6 +558,7 @@ void expand_cond_binop (unsigned, rtx *);
void expand_cond_ternop (unsigned, rtx *);
void expand_popcount (rtx *);
void expand_rawmemchr (machine_mode, rtx, rtx, rtx, bool = false);
+bool expand_strcmp (rtx, rtx, rtx, rtx, unsigned HOST_WIDE_INT, bool);
void emit_vec_extract (rtx, rtx, poly_int64);
/* Rounding mode bitfield for fixed point VXRM.  */
diff --git a/gcc/config/riscv/riscv-string.cc b/gcc/config/riscv/riscv-string.cc
index 6cde1bf89a0..11c1f74d0b3 100644
--- a/gcc/config/riscv/riscv-string.cc
+++ b/gcc/config/riscv/riscv-string.cc
@@ -511,12 +511,19 @@ riscv_expand_strcmp (rtx result, rtx src1, rtx src2,
 return false;
   alignment = UINTVAL (align_rtx);
-  if (TARGET_ZBB || TARGET_XTHEADBB)
+  if (TARGET_VECTOR && stringop_strategy & STRATEGY_VECTOR)
 {
-  return riscv_expand_strcmp_scalar (result, src1, src2, nbytes, alignment,
- ncompare);
+  bool ok = riscv_vector::expand_strcmp (result, src1, src2,
+  bytes_rtx, alignment,
+  ncompare);
+  if (ok)
+ return true;
 }
+  if ((TARGET_ZBB || TARGET_XTHEADBB) && stringop_strategy & STRATEGY_SCALAR)
+return riscv_expand_strcmp_scalar (result, src1, src2, nbytes, alignment,
+ncompare);
+
   return false;
}
@@ -1092,4 +1099,152 @@ expand_rawmemchr (machine_mode mode, rtx dst, rtx 
haystack, rtx needle,
 }
}
+/* Implement cmpstr using vector instructions.  The ALIGNMENT and
+   NCOMPARE parameters are unused for now.  */
+
+bool
+expand_strcmp (rtx result, rtx src1, rtx src2, rtx nbytes,
+unsigned HOST_WIDE_INT, bool)
+{
+  gcc_assert (TARGET_VECTOR);
+
+  /* We don't support big endian.  */
+  if (BYTES_BIG_ENDIAN)
+return false;
+
+  bool with_length = nbytes != NULL_RTX;
+
+  if (with_length
+  && (!REG_P (nbytes) && !SUBREG_P (nbytes) && !CONST_INT_P (nbytes)))
+return false;
+
+  if (with_length && CONST_INT_P (nbytes))
+nbytes = force_reg (Pmode, nbytes);
+
+  machine_mode mode = E_QImode;
+  unsigned int isize = GET_MODE_SIZE (mode).to_constant ();
+  int lmul = TARGET_MAX_LMUL;
+  poly_int64 nunits = exact_div (BYTES_PER_RISCV_VECTOR * lmul, isize);
+
+  machine_mode vmode;
+  if (!riscv_vector::get_vector_mode (GET_MODE_INNER (mode), nunits)
+ .exists ())
+gcc_unreachable ();
+
+  machine_mode mask_mode = riscv_vector::get_mask_mode (vmode);
+
+  /* Prepare addresses.  */
+  rtx src_addr1 = copy_addr_to_reg (XEXP (src1, 0));
+  rtx vsrc1 = change_address (src1, vmode, src_addr1);
+
+  rtx src_addr2 = copy_addr_to_reg (XEXP (src2, 0));
+  rtx vsrc2 = change_address (src2, vmode, src_addr2);
+
+  /* Set initial pointer bump to 0.  */
+  rtx cnt = gen_reg_rtx (Pmode);
+  emit_move_insn (cnt, CONST0_RTX (Pmode));
+
+  rtx sub = gen_reg_rtx (Pmode);
+  emit_move_insn (sub, CONST0_RTX (Pmode));
+
+  /* Create source vectors.  */
+  rtx vec1 = gen_reg_rtx (vmode);
+  rtx vec2 = gen_reg_rtx (vmode);
+
+  rtx done = gen_label_rtx ();
+  rtx loop = gen_label_rtx ();
+  emit_label (loop);
+
+  /* Bump the pointers.  */
+  emit_insn (gen_rtx_SET (src_addr1, gen_rtx_PLUS (Pmode, src_addr1, cnt)));
+  emit_insn (gen_rtx_SET (src_addr2, gen_rtx_PLUS (Pmode, src_addr2, cnt)));
+
+  rtx vlops1[] = {vec1, vsrc1};
+  rtx vlops2[] = {vec2, vsrc2};
+
+  if (!with_length)
+{
+  emit_vlmax_insn (code_for_pred_fault_load (vmode),
+

Re: [PATCH] RISC-V: Add vectorized strlen.

[钟居哲]

LGTM.



juzhe.zh...@rivai.ai
 
From: Robin Dapp
Date: 2023-12-01 23:21
To: gcc-patches; palmer; Kito Cheng; jeffreyalaw; juzhe.zh...@rivai.ai
CC: rdapp.gcc
Subject: [PATCH] RISC-V: Add vectorized strlen.
Hi,
 
this patch implements a vectorized strlen by re-using and slightly
adjusting the rawmemchr implementation.  Rawmemchr returns the address
of the needle while strlen returns the difference between needle address
and start address.
 
As before, strlen expansion is guarded by -minline-strlen.
 
While testing with -minline-strlen I encountered a vsetvl problem in
memcpy-chk.c where we didn't insert a vsetvl at the proper spot (after
a setjmp).  This needs to be fixed separately and I figured I'd post
this patch as-is.
 
Regards
Robin
 
gcc/ChangeLog:
 
* config/riscv/riscv-protos.h (expand_rawmemchr): Add strlen
parameter.
* config/riscv/riscv-string.cc (riscv_expand_strlen): Call
rawmemchr.
(expand_rawmemchr): Add strlen handling.
* config/riscv/riscv.md: Add TARGET_VECTOR to strlen expander.
 
gcc/testsuite/ChangeLog:
 
* gcc.target/riscv/rvv/autovec/builtin/strlen-run.c: New test.
* gcc.target/riscv/rvv/autovec/builtin/strlen.c: New test.
---
gcc/config/riscv/riscv-protos.h   |  2 +-
gcc/config/riscv/riscv-string.cc  | 41 ++-
gcc/config/riscv/riscv.md |  8 +---
.../riscv/rvv/autovec/builtin/strlen-run.c| 37 +
.../riscv/rvv/autovec/builtin/strlen.c| 12 ++
5 files changed, 83 insertions(+), 17 deletions(-)
create mode 100644 
gcc/testsuite/gcc.target/riscv/rvv/autovec/builtin/strlen-run.c
create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/autovec/builtin/strlen.c
 
diff --git a/gcc/config/riscv/riscv-protos.h b/gcc/config/riscv/riscv-protos.h
index 695ee24ad6f..c94c82a9973 100644
--- a/gcc/config/riscv/riscv-protos.h
+++ b/gcc/config/riscv/riscv-protos.h
@@ -557,7 +557,7 @@ void expand_cond_unop (unsigned, rtx *);
void expand_cond_binop (unsigned, rtx *);
void expand_cond_ternop (unsigned, rtx *);
void expand_popcount (rtx *);
-void expand_rawmemchr (machine_mode, rtx, rtx, rtx);
+void expand_rawmemchr (machine_mode, rtx, rtx, rtx, bool = false);
void emit_vec_extract (rtx, rtx, poly_int64);
/* Rounding mode bitfield for fixed point VXRM.  */
diff --git a/gcc/config/riscv/riscv-string.cc b/gcc/config/riscv/riscv-string.cc
index 594ff49fc5a..6cde1bf89a0 100644
--- a/gcc/config/riscv/riscv-string.cc
+++ b/gcc/config/riscv/riscv-string.cc
@@ -588,9 +588,16 @@ riscv_expand_strlen_scalar (rtx result, rtx src, rtx align)
bool
riscv_expand_strlen (rtx result, rtx src, rtx search_char, rtx align)
{
+  if (TARGET_VECTOR && stringop_strategy & STRATEGY_VECTOR)
+{
+  riscv_vector::expand_rawmemchr (E_QImode, result, src, search_char,
+   /* strlen */ true);
+  return true;
+}
+
   gcc_assert (search_char == const0_rtx);
-  if (TARGET_ZBB || TARGET_XTHEADBB)
+  if ((TARGET_ZBB || TARGET_XTHEADBB) && stringop_strategy & STRATEGY_SCALAR)
 return riscv_expand_strlen_scalar (result, src, align);
   return false;
@@ -979,12 +986,13 @@ expand_block_move (rtx dst_in, rtx src_in, rtx length_in)
}
-/* Implement rawmemchr using vector instructions.
+/* Implement rawmemchr and strlen using vector instructions.
It can be assumed that the needle is in the haystack, otherwise the
behavior is undefined.  */
void
-expand_rawmemchr (machine_mode mode, rtx dst, rtx src, rtx pat)
+expand_rawmemchr (machine_mode mode, rtx dst, rtx haystack, rtx needle,
+   bool strlen)
{
   /*
 rawmemchr:
@@ -1005,6 +1013,9 @@ expand_rawmemchr (machine_mode mode, rtx dst, rtx src, 
rtx pat)
   */
   gcc_assert (TARGET_VECTOR);
+  if (strlen)
+gcc_assert (mode == E_QImode);
+
   unsigned int isize = GET_MODE_SIZE (mode).to_constant ();
   int lmul = TARGET_MAX_LMUL;
   poly_int64 nunits = exact_div (BYTES_PER_RISCV_VECTOR * lmul, isize);
@@ -1028,12 +1039,13 @@ expand_rawmemchr (machine_mode mode, rtx dst, rtx src, 
rtx pat)
  return a pointer to the matching byte.  */
   unsigned int shift = exact_log2 (GET_MODE_SIZE (mode).to_constant ());
-  rtx src_addr = copy_addr_to_reg (XEXP (src, 0));
+  rtx src_addr = copy_addr_to_reg (XEXP (haystack, 0));
+  rtx start_addr = copy_addr_to_reg (XEXP (haystack, 0));
   rtx loop = gen_label_rtx ();
   emit_label (loop);
-  rtx vsrc = change_address (src, vmode, src_addr);
+  rtx vsrc = change_address (haystack, vmode, src_addr);
   /* Bump the pointer.  */
   rtx step = gen_reg_rtx (Pmode);
@@ -1052,8 +1064,8 @@ expand_rawmemchr (machine_mode mode, rtx dst, rtx src, 
rtx pat)
 emit_insn (gen_read_vldi_zero_extend (cnt));
   /* Compare needle with haystack and store in a mask.  */
-  rtx eq = gen_rtx_EQ (mask_mode, gen_const_vec_duplicate (vmode, pat), vec);
-  rtx vmsops[] = {mask, eq, vec, pat};
+  rtx eq = gen_rtx_EQ (mask_mode, gen_const_vec_duplicate (vmode, needle), 
vec);
+  rtx vmsops[] = {mask, eq, vec, needle};
   emit_nonvlmax_insn (code_for_pred_eqne_scalar 

Re: [PATCH] RISC-V: Rename and unify stringop strategy handling [NFC].

[钟居哲]

LGTM



juzhe.zh...@rivai.ai
 
From: Robin Dapp
Date: 2023-12-01 23:21
To: gcc-patches; palmer; Kito Cheng; jeffreyalaw; juzhe.zh...@rivai.ai
CC: rdapp.gcc
Subject: [PATCH] RISC-V: Rename and unify stringop strategy handling [NFC].
Hi,
 
now split into multiple patches.
 
In preparation for the vectorized strlen and strcmp support this NFC
patch unifies the stringop strategy handling a bit.  The "auto"
strategy now is a combination of scalar and vector and an expander
should try the strategies in their preferred order.
 
For the block_move expander this patch does just that.
 
Regards
Robin
 
gcc/ChangeLog:
 
* config/riscv/riscv-opts.h (enum riscv_stringop_strategy_enum):
Rename...
(enum stringop_strategy_enum): ... to this.
* config/riscv/riscv-string.cc (riscv_expand_block_move): New
wrapper expander handling the strategies and delegation.
(riscv_expand_block_move_scalar): Rename function and make
static.
(expand_block_move): Remove strategy handling.
* config/riscv/riscv.md: Call expander wrapper.
* config/riscv/riscv.opt: Rename.
---
gcc/config/riscv/riscv-opts.h | 18 ++--
gcc/config/riscv/riscv-string.cc  | 92 +++
gcc/config/riscv/riscv.md |  4 +-
gcc/config/riscv/riscv.opt| 18 ++--
.../riscv/rvv/base/cpymem-strategy-1.c|  2 +-
.../riscv/rvv/base/cpymem-strategy-2.c|  2 +-
.../riscv/rvv/base/cpymem-strategy-3.c|  2 +-
.../riscv/rvv/base/cpymem-strategy-4.c|  2 +-
.../riscv/rvv/base/cpymem-strategy-5.c|  2 +-
9 files changed, 78 insertions(+), 64 deletions(-)
 
diff --git a/gcc/config/riscv/riscv-opts.h b/gcc/config/riscv/riscv-opts.h
index e6e55ad7071..30efebbf07b 100644
--- a/gcc/config/riscv/riscv-opts.h
+++ b/gcc/config/riscv/riscv-opts.h
@@ -104,15 +104,15 @@ enum riscv_entity
};
/* RISC-V stringop strategy. */
-enum riscv_stringop_strategy_enum {
-  /* Use scalar or vector instructions. */
-  USE_AUTO,
-  /* Always use a library call. */
-  USE_LIBCALL,
-  /* Only use scalar instructions. */
-  USE_SCALAR,
-  /* Only use vector instructions. */
-  USE_VECTOR
+enum stringop_strategy_enum {
+  /* No expansion. */
+  STRATEGY_LIBCALL = 1,
+  /* Use scalar expansion if possible. */
+  STRATEGY_SCALAR = 2,
+  /* Only vector expansion if possible. */
+  STRATEGY_VECTOR = 4,
+  /* Use any. */
+  STRATEGY_AUTO = STRATEGY_SCALAR | STRATEGY_VECTOR
};
#define TARGET_ZICOND_LIKE (TARGET_ZICOND || (TARGET_XVENTANACONDOPS && 
TARGET_64BIT))
diff --git a/gcc/config/riscv/riscv-string.cc b/gcc/config/riscv/riscv-string.cc
index 80e3b5981af..f3a4d3ddd47 100644
--- a/gcc/config/riscv/riscv-string.cc
+++ b/gcc/config/riscv/riscv-string.cc
@@ -707,51 +707,68 @@ riscv_block_move_loop (rtx dest, rtx src, unsigned 
HOST_WIDE_INT length,
/* Expand a cpymemsi instruction, which copies LENGTH bytes from
memory reference SRC to memory reference DEST.  */
-bool
-riscv_expand_block_move (rtx dest, rtx src, rtx length)
+static bool
+riscv_expand_block_move_scalar (rtx dest, rtx src, rtx length)
{
-  if (riscv_memcpy_strategy == USE_LIBCALL
-  || riscv_memcpy_strategy == USE_VECTOR)
+  if (!CONST_INT_P (length))
 return false;
-  if (CONST_INT_P (length))
-{
-  unsigned HOST_WIDE_INT hwi_length = UINTVAL (length);
-  unsigned HOST_WIDE_INT factor, align;
+  unsigned HOST_WIDE_INT hwi_length = UINTVAL (length);
+  unsigned HOST_WIDE_INT factor, align;
-  align = MIN (MIN (MEM_ALIGN (src), MEM_ALIGN (dest)), BITS_PER_WORD);
-  factor = BITS_PER_WORD / align;
+  align = MIN (MIN (MEM_ALIGN (src), MEM_ALIGN (dest)), BITS_PER_WORD);
+  factor = BITS_PER_WORD / align;
-  if (optimize_function_for_size_p (cfun)
-   && hwi_length * factor * UNITS_PER_WORD > MOVE_RATIO (false))
- return false;
+  if (optimize_function_for_size_p (cfun)
+  && hwi_length * factor * UNITS_PER_WORD > MOVE_RATIO (false))
+return false;
-  if (hwi_length <= (RISCV_MAX_MOVE_BYTES_STRAIGHT / factor))
+  if (hwi_length <= (RISCV_MAX_MOVE_BYTES_STRAIGHT / factor))
+{
+  riscv_block_move_straight (dest, src, INTVAL (length));
+  return true;
+}
+  else if (optimize && align >= BITS_PER_WORD)
+{
+  unsigned min_iter_words
+ = RISCV_MAX_MOVE_BYTES_PER_LOOP_ITER / UNITS_PER_WORD;
+  unsigned iter_words = min_iter_words;
+  unsigned HOST_WIDE_INT bytes = hwi_length;
+  unsigned HOST_WIDE_INT words = bytes / UNITS_PER_WORD;
+
+  /* Lengthen the loop body if it shortens the tail.  */
+  for (unsigned i = min_iter_words; i < min_iter_words * 2 - 1; i++)
{
-   riscv_block_move_straight (dest, src, INTVAL (length));
-   return true;
+   unsigned cur_cost = iter_words + words % iter_words;
+   unsigned new_cost = i + words % i;
+   if (new_cost <= cur_cost)
+ iter_words = i;
}
-  else if (optimize && align >= BITS_PER_WORD)
- {
-   unsigned min_iter_words
- = RISCV_MAX_MOVE_BYTES_PER_LOOP_ITER / UNITS_PER_WORD;
-   unsigned iter_words = 

Re: [PATCH] RISC-V: Fix rawmemchr implementation.

[钟居哲]

LGTM。



juzhe.zh...@rivai.ai
 
From: Robin Dapp
Date: 2023-12-01 23:20
To: gcc-patches; palmer; Kito Cheng; jeffreyalaw; juzhe.zh...@rivai.ai
CC: rdapp.gcc
Subject: [PATCH] RISC-V: Fix rawmemchr implementation.
Hi,
 
this fixes a bug in the rawmemchr implementation by incrementing the
source address by vl * element_size instead of just vl.
 
This is normally harmless as we will just scan the same region more than
once but, in combination with an older qemu version, would lead to
an execution failure in SPEC2017.
 
Regards
Robin
 
 
gcc/ChangeLog:
 
* config/riscv/riscv-string.cc (expand_rawmemchr): Increment
source address by vl * element_size.
---
gcc/config/riscv/riscv-string.cc | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
 
diff --git a/gcc/config/riscv/riscv-string.cc b/gcc/config/riscv/riscv-string.cc
index f3a4d3ddd47..594ff49fc5a 100644
--- a/gcc/config/riscv/riscv-string.cc
+++ b/gcc/config/riscv/riscv-string.cc
@@ -1017,6 +1017,8 @@ expand_rawmemchr (machine_mode mode, rtx dst, rtx src, 
rtx pat)
   machine_mode mask_mode = riscv_vector::get_mask_mode (vmode);
   rtx cnt = gen_reg_rtx (Pmode);
+  emit_move_insn (cnt, CONST0_RTX (Pmode));
+
   rtx end = gen_reg_rtx (Pmode);
   rtx vec = gen_reg_rtx (vmode);
   rtx mask = gen_reg_rtx (mask_mode);
@@ -1033,6 +1035,11 @@ expand_rawmemchr (machine_mode mode, rtx dst, rtx src, 
rtx pat)
   rtx vsrc = change_address (src, vmode, src_addr);
+  /* Bump the pointer.  */
+  rtx step = gen_reg_rtx (Pmode);
+  emit_insn (gen_rtx_SET (step, gen_rtx_ASHIFT (Pmode, cnt, GEN_INT (shift;
+  emit_insn (gen_rtx_SET (src_addr, gen_rtx_PLUS (Pmode, src_addr, step)));
+
   /* Emit a first-fault load.  */
   rtx vlops[] = {vec, vsrc};
   emit_vlmax_insn (code_for_pred_fault_load (vmode),
@@ -1055,16 +1062,10 @@ expand_rawmemchr (machine_mode mode, rtx dst, rtx src, 
rtx pat)
   emit_nonvlmax_insn (code_for_pred_ffs (mask_mode, Pmode),
  riscv_vector::CPOP_OP, vfops, cnt);
-  /* Bump the pointer.  */
-  emit_insn (gen_rtx_SET (src_addr, gen_rtx_PLUS (Pmode, src_addr, cnt)));
-
   /* Emit the loop condition.  */
   rtx test = gen_rtx_LT (VOIDmode, end, const0_rtx);
   emit_jump_insn (gen_cbranch4 (Pmode, test, end, const0_rtx, loop));
-  /*  We overran by CNT, subtract it.  */
-  emit_insn (gen_rtx_SET (src_addr, gen_rtx_MINUS (Pmode, src_addr, cnt)));
-
   /*  We found something at SRC + END * [1,2,4,8].  */
   emit_insn (gen_rtx_SET (end, gen_rtx_ASHIFT (Pmode, end, GEN_INT (shift;
   emit_insn (gen_rtx_SET (dst, gen_rtx_PLUS (Pmode, src_addr, end)));
-- 
2.43.0
 
 

[Bug tree-optimization/112818] [14 regression] ICE when building accel-ppp (error: conversion of register to a different size in ‘view_convert_expr’, verify_gimple failed)

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

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

--- Comment #1 from Andrew Pinski  ---
Created attachment 56763
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56763=edit
start of reduction

Re: [PATCH] c++: decltype of (non-captured variable) [PR83167]

[Patrick Palka]

On Fri, 1 Dec 2023, Jason Merrill wrote:

> On 12/1/23 12:32, Patrick Palka wrote:
> > On Tue, 14 Nov 2023, Jason Merrill wrote:
> > 
> > > On 11/14/23 11:10, Patrick Palka wrote:
> > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
> > > > trunk?
> > > > 
> > > > -- >8 --
> > > > 
> > > > For decltype((x)) within a lambda where x is not captured, we dubiously
> > > > require that the lambda has a capture default, unlike for decltype(x).
> > > > This patch fixes this inconsistency; I couldn't find a justification for
> > > > it in the standard.
> > > 
> > > The relevant passage seems to be
> > > 
> > > https://eel.is/c++draft/expr.prim#id.unqual-3
> > > 
> > > "If naming the entity from outside of an unevaluated operand within S
> > > would
> > > refer to an entity captured by copy in some intervening lambda-expression,
> > > then let E be the innermost such lambda-expression.
> > > 
> > > If there is such a lambda-expression and if P is in E's function parameter
> > > scope but not its parameter-declaration-clause, then the type of the
> > > expression is the type of a class member access expression ([expr.ref])
> > > naming
> > > the non-static data member that would be declared for such a capture in
> > > the
> > > object parameter ([dcl.fct]) of the function call operator of E."
> > > 
> > > In this case I guess there is no such lambda-expression because naming x
> > > won't
> > > refer to a capture by copy if the lambda doesn't capture anything, so we
> > > ignore the lambda.
> > > 
> > > Maybe refer to that in a comment?  OK with that change.
> > > 
> > > I'm surprised that it refers specifically to capture by copy, but I guess
> > > a
> > > capture by reference should have the same decltype as the captured
> > > variable?
> > 
> > Ah, seems like it.  So maybe we should get rid of the redundant
> > by-reference capture-default handling, to more closely mirror the
> > standard?
> > 
> > Also now that r14-6026-g73e2bdbf9bed48 made capture_decltype return
> > NULL_TREE to mean the capture is dependent, it seems we should just
> > inline capture_decltype into finish_decltype_type rather than
> > introducing another special return value to mean "fall back to ordinary
> > handling".
> > 
> > How does the following look?  Bootstrapped and regtested on
> > x86_64-pc-linux-gnu.
> > 
> > -- >8 --
> > 
> > PR c++/83167
> > 
> > gcc/cp/ChangeLog:
> > 
> > * semantics.cc (capture_decltype): Inline into its only caller ...
> > (finish_decltype_type): ... here.  Update nearby comment to refer
> > to recent standard.  Restrict uncaptured variable handling to just
> > lambdas with a by-copy capture-default.
> > 
> > gcc/testsuite/ChangeLog:
> > 
> > * g++.dg/cpp0x/lambda/lambda-decltype4.C: New test.
> > ---
> >   gcc/cp/semantics.cc   | 107 +++---
> >   .../g++.dg/cpp0x/lambda/lambda-decltype4.C|  15 +++
> >   2 files changed, 55 insertions(+), 67 deletions(-)
> >   create mode 100644 gcc/testsuite/g++.dg/cpp0x/lambda/lambda-decltype4.C
> > 
> > diff --git a/gcc/cp/semantics.cc b/gcc/cp/semantics.cc
> > index fbbc18336a0..fb4c3992e34 100644
> > --- a/gcc/cp/semantics.cc
> > +++ b/gcc/cp/semantics.cc
> > @@ -53,7 +53,6 @@ along with GCC; see the file COPYING3.  If not see
> > static tree maybe_convert_cond (tree);
> >   static tree finalize_nrv_r (tree *, int *, void *);
> > -static tree capture_decltype (tree);
> > /* Used for OpenMP non-static data member privatization.  */
> >   @@ -11856,21 +11855,48 @@ finish_decltype_type (tree expr, bool
> > id_expression_or_member_access_p,
> >   }
> > else
> >   {
> > -  /* Within a lambda-expression:
> > -
> > -Every occurrence of decltype((x)) where x is a possibly
> > -parenthesized id-expression that names an entity of
> > -automatic storage duration is treated as if x were
> > -transformed into an access to a corresponding data member
> > -of the closure type that would have been declared if x
> > -were a use of the denoted entity.  */
> > if (outer_automatic_var_p (STRIP_REFERENCE_REF (expr))
> >   && current_function_decl
> >   && LAMBDA_FUNCTION_P (current_function_decl))
> > {
> > - type = capture_decltype (STRIP_REFERENCE_REF (expr));
> > - if (!type)
> > -   goto dependent;
> > + /* [expr.prim.id.unqual]/3: If naming the entity from outside of an
> > +unevaluated operand within S would refer to an entity captured by
> > +copy in some intervening lambda-expression, then let E be the
> > +innermost such lambda-expression.
> > +
> > +If there is such a lambda-expression and if P is in E's function
> > +parameter scope but not its parameter-declaration-clause, then
> > the
> > +type of the expression is the type of a class member access
> > +expression naming the non-static data member that would be
> > declared
> > +for such a 

[Bug tree-optimization/112818] [14 regression] ICE when building accel-ppp (error: conversion of register to a different size in ‘view_convert_expr’, verify_gimple failed)

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu.org
   Keywords||ice-on-valid-code
   Target Milestone|--- |14.0

gcc-12-20231201 is now available

[GCC Administrator via Gcc]

Snapshot gcc-12-20231201 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/12-20231201/
and on various mirrors, see https://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 12 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch 
releases/gcc-12 revision 17cbec6e8ea8817b6240837bb1f1bf74f1b9bdcd

You'll find:

 gcc-12-20231201.tar.xz   Complete GCC

  SHA256=04e4098a1a74575a5ee508e17a7b63965fa2f8507d8620fec9a234466865c6ac
  SHA1=abdb4127f32851e4a51f919537b75d287263f1ba

Diffs from 12-20231124 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-12
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

[Bug tree-optimization/112818] New: [14 regression] ICE when building accel-ppp (error: conversion of register to a different size in ‘view_convert_expr’, verify_gimple failed)

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

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

Bug ID: 112818
   Summary: [14 regression] ICE when building accel-ppp (error:
conversion of register to a different size in
‘view_convert_expr’, verify_gimple failed)
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
  Target Milestone: ---

Created attachment 56762
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56762=edit
pppoe.c.i

Initially reported downstream in Gentoo by Toralf Förster at
https://bugs.gentoo.org/918991.

```
[...]
/var/tmp/portage/net-dialup/accel-ppp-1.12.0_p20230609/work/accel-pppd/ctrl/pppoe/pppoe.c:
In function ‘add_tag.constprop.isra’:
/var/tmp/portage/net-dialup/accel-ppp-1.12.0_p20230609/work/accel-pppd/ctrl/pppoe/pppoe.c:736:12:
error: conversion of register to a different size in ‘view_convert_expr’
  736 | static int add_tag(uint8_t *pack, size_t pack_size, int type, const
void *data, int len)
  |^~~
VIEW_CONVERT_EXPR(_10);

_48 = VIEW_CONVERT_EXPR(_10);
during GIMPLE pass: slp
/var/tmp/portage/net-dialup/accel-ppp-1.12.0_p20230609/work/accel-pppd/ctrl/pppoe/pppoe.c:736:12:
internal compiler error: verify_gimple failed
0x55e876bf0bf1 verify_gimple_in_cfg(function*, bool, bool)
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/tree-cfg.cc:5662
0x55e87813950c execute_function_todo
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/passes.cc:2088
0x55e87813950c do_per_function
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/passes.cc:1687
0x55e87813950c execute_todo
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/passes.cc:2142
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.
```

I can reproduce with 'gcc -c pppoe.c.i -O2 -march=znver2'.

[Bug target/112817] RISC-V: RVV: provide a preprocessor macro for VLS codegen

[juzhe.zhong at rivai dot ai via Gcc-bugs]

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

--- Comment #5 from JuzheZhong  ---
Support VLS codegen with -mrvv-vector-bits and attribute is reasonable to be
landed on GCC-14.

But currently we are busy with fixing bugs (me, Robin, Lixu@eswin, Li
Pan@intel).
You can see gcc-patch list...


Could you first implement -mrvv-vector-bits feature ?

I have support it in rvv-next, but I don't have time to migrate that into trunk
GCC.

[Bug c++/112810] bogus ambiguous overload resolution when taking address of static/xobj member function template introduced by using declaration where candidates have a mismatched deduced return type

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-12-01
  Known to fail||4.9.0
 Ever confirmed|0   |1

--- Comment #2 from Andrew Pinski  ---
Confirmed, failed since at least GCC 4.9 when C++14 was added.

[Bug c++/112810] bogus ambiguous overload resolution when taking address of static/xobj member function template introduced by using declaration where candidates have a mismatched deduced return type

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

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

--- Comment #1 from Andrew Pinski  ---
Created attachment 56761
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56761=edit
C++14 testcase (removes the auto argument and changes into an explict template)

[Bug target/112651] RISC-V Vector new option -mvect-lmul required to force LMUL values (rather than --param=riscv-autovec-lmul to hint at values)

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

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

--- Comment #4 from Vineet Gupta  ---
(In reply to JuzheZhong from comment #3)
> The reason we use --param=riscv-autovec-lmul instead of -mvect-lmul which is
> not documented because we don't have ratifed compile option.
> 
> I have mentioned whether we should have -mrvv-vector-lmul but LLVM people
> object
> it.
> 
> https://github.com/riscv-non-isa/riscv-toolchain-conventions/issues/33

It seems the discussions back in March stalled due to things being tooearly.

But llvm and gcc seem to have diverged anyways for other toggles in the area. 
e.g. fixed length vec size is specified differently
(gcc:--param=riscv-autovec-preference=fixed-vlmax vs.
llvm:-mrvv-vector-bits=zvl) so we might as well switch gcc to -m way. This can
obviously only be done now, before this goes out in the wild in gcc-14 release.
I'd say even now it would be disruptive but ...

[Bug target/112817] RISC-V: RVV: provide a preprocessor macro for VLS codegen

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

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Vineet Gupta from comment #3)
> I agree, but what xsimd does is not under our control. Whoever wants to use
> xsimd for whatever reasons, we can allow gcc to be used similarly to llvm
> and certainly not for lack of a trivial define.

What I am trying to say is almost all of these "SIMD" libraries were done to
wrap x86_64 SIMD and is almost done in a bad form in general. I noticed that
when working on AARCH64 (even before SVE). they push the idea of a low level
wrapper just because "it is easier" rather than higher level concepts. xsimd,
even the whole C++ SIMD library seems to push low level wrappers rather than
high level concepts that could be optimized.

[Bug target/112817] RISC-V: RVV: provide a preprocessor macro for VLS codegen

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

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

Vineet Gupta  changed:

   What|Removed |Added

 CC||vineetg at gcc dot gnu.org

--- Comment #3 from Vineet Gupta  ---
I agree, but what xsimd does is not under our control. Whoever wants to use
xsimd for whatever reasons, we can allow gcc to be used similarly to llvm and
certainly not for lack of a trivial define.

[Bug target/112817] RISC-V: RVV: provide a preprocessor macro for VLS codegen

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

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

--- Comment #2 from Andrew Pinski  ---
Note the reality is xsimd was not thought out for SIMD but rather just fixed
length extensions. It seems more like a major shift that needs to happen to
these libraries and stop just thinking fixed length registers.

[Bug target/112817] RISC-V: RVV: provide a preprocessor macro for VLS codegen

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

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

--- Comment #1 from Andrew Pinski  ---
>gcc doesn't, which is a bit of pain for downstream projects such as xsimd.

Does it even make sense to define this? Projects like xsimd seems to be good
for fixed length SIMD but it seems to have a broken idea for non-fixed length
SIMD like SVE and RVV. Would it better to have xsimd provide better interfaces
instead for non-fixed length vectors and not provide a fixed length API at all?

[PATCH, v3] Fortran: deferred-length character optional dummy arguments [PR93762,PR100651]

[Harald Anlauf]

Dear all,

this patch extends the previous version by adding further code testing
the presence of an optional deferred-length character argument also
in the function initialization code.  This allows to re-enable a
commented-out test in v2.

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

Thanks,
Harald


On 11/28/23 20:56, Harald Anlauf wrote:

Hi FX,

On 11/28/23 18:07, FX Coudert wrote:

Hi Harald,

The patch looks OK to me. Probably wait a bit for another opinion,
since I’m not that active and I may have missed something.

Thanks,
FX


thanks for having a look.

In the meantime I got an automated mail from the Linaro testers.
According to it there is a runtime failure of the testcase on
aarch64.  I couldn't see any useful traceback or else.

I tried the testcase on x86 with different options and found
an unexpected result only with -fsanitize=undefined and only
for the case of a rank-1 dummy when there is no actual argument
and the passed to another subroutine.  (valgrind is happy.)

Reduced reproducer:

! this fails with -fsanitize=undefined
program main
   call test_rank1 ()
contains
   subroutine test_rank1 (msg1)
     character(:), optional, allocatable :: msg1(:)
     if (present (msg1)) stop 77
     call assert_rank1 ()    ! <- no problem here
     call assert_rank1 (msg1)    ! <- problematic code path
   end

   subroutine assert_rank1 (msg2)
     character(:), optional, allocatable :: msg2(:)
     if (present (msg2)) stop 99 ! <- no problem if commented
   end
end


As far as I can tell, this could be a pre-existing (latent)
issue.  By looking at the tree-dump, the only thing that
appears fishy has been there before.  But then I am only
guessing that this is the problem observed on aarch64.

I have disabled the related call in the testcase of the
attached revised version.  As I do not see anything else,
I wonder if one could proceed with the current version
but open a PR for the reduced case above, unless someone
can pinpoint the place that is responsible for the above
failure.  (Is it the caller, or rather the function entry
code in the callee?)

Cheers,
Harald

From b0a169bd70c9cd175c25b4a9543b24058596bf5e Mon Sep 17 00:00:00 2001
From: Harald Anlauf 
Date: Fri, 1 Dec 2023 22:44:30 +0100
Subject: [PATCH] Fortran: deferred-length character optional dummy arguments
 [PR93762,PR100651]

gcc/fortran/ChangeLog:

	PR fortran/93762
	PR fortran/100651
	* trans-array.cc (gfc_trans_deferred_array): Add presence check
	for optional deferred-length character dummy arguments.
	* trans-expr.cc (gfc_conv_missing_dummy): The character length for
	deferred-length dummy arguments is passed by reference, so that
	its value can be returned.  Adjust handling for optional dummies.

gcc/testsuite/ChangeLog:

	PR fortran/93762
	PR fortran/100651
	* gfortran.dg/optional_deferred_char_1.f90: New test.
---
 gcc/fortran/trans-array.cc|   9 ++
 gcc/fortran/trans-expr.cc |  22 +++-
 .../gfortran.dg/optional_deferred_char_1.f90  | 100 ++
 3 files changed, 127 insertions(+), 4 deletions(-)
 create mode 100644 gcc/testsuite/gfortran.dg/optional_deferred_char_1.f90

diff --git a/gcc/fortran/trans-array.cc b/gcc/fortran/trans-array.cc
index bbb81f40aa9..82f60a656f3 100644
--- a/gcc/fortran/trans-array.cc
+++ b/gcc/fortran/trans-array.cc
@@ -11430,6 +11430,15 @@ gfc_trans_deferred_array (gfc_symbol * sym, gfc_wrapped_block * block)
 {
   gfc_conv_string_length (sym->ts.u.cl, NULL, );
   gfc_trans_vla_type_sizes (sym, );
+
+  /* Presence check of optional deferred-length character dummy.  */
+  if (sym->ts.deferred && sym->attr.dummy && sym->attr.optional)
+	{
+	  tmp = gfc_finish_block ();
+	  tmp = build3_v (COND_EXPR, gfc_conv_expr_present (sym),
+			  tmp, build_empty_stmt (input_location));
+	  gfc_add_expr_to_block (, tmp);
+	}
 }
 
   /* Dummy, use associated and result variables don't need anything special.  */
diff --git a/gcc/fortran/trans-expr.cc b/gcc/fortran/trans-expr.cc
index 6a47af39c57..ea087294249 100644
--- a/gcc/fortran/trans-expr.cc
+++ b/gcc/fortran/trans-expr.cc
@@ -2125,10 +2125,24 @@ gfc_conv_missing_dummy (gfc_se * se, gfc_expr * arg, gfc_typespec ts, int kind)
 
   if (ts.type == BT_CHARACTER)
 {
-  tmp = build_int_cst (gfc_charlen_type_node, 0);
-  tmp = fold_build3_loc (input_location, COND_EXPR, gfc_charlen_type_node,
-			 present, se->string_length, tmp);
-  tmp = gfc_evaluate_now (tmp, >pre);
+  /* Handle deferred-length dummies that pass the character length by
+	 reference so that the value can be returned.  */
+  if (ts.deferred && INDIRECT_REF_P (se->string_length))
+	{
+	  tmp = gfc_build_addr_expr (NULL_TREE, se->string_length);
+	  tmp = fold_build3_loc (input_location, COND_EXPR, TREE_TYPE (tmp),
+ present, tmp, null_pointer_node);
+	  tmp = gfc_evaluate_now (tmp, >pre);
+	  tmp = build_fold_indirect_ref_loc (input_location, tmp);
+	}
+  else
+	{
+	  tmp = 

[Bug target/112817] RISC-V: RVV: provide a preprocessor macro for VLS codegen

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug target/112817] New: RISC-V: RVV: provide a preprocessor macro for VLS codegen

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

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

Bug ID: 112817
   Summary: RISC-V: RVV: provide a preprocessor macro for VLS
codegen
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vineetg at gcc dot gnu.org
CC: ewlu at rivosinc dot com, juzhe.zhong at rivai dot ai,
rdapp at gcc dot gnu.org
  Target Milestone: ---

LLVM toggle for setting up fixed vector length using -mrvv-vector-bits=zvl
(which in turn derives VL from -march=...-vl256) also generates a preprocessor
define __riscv_v_fixed_vlen.

gcc doesn't, which is a bit of pain for downstream projects such as xsimd.

Granted the C-API document [1] doesn't specify this, generation by llvm and
more importantly usage in downstream projects seems good enough of a
requirement to have it in gcc as well.

[1] https://github.com/riscv-non-isa/riscv-c-api-doc/blob/master/riscv-c-api.md

[Bug fortran/112772] Some issues with OPTIONAL, ALLOCATABLE dummy arguments

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

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

--- Comment #4 from GCC Commits  ---
The master branch has been updated by Harald Anlauf :

https://gcc.gnu.org/g:7317275497e10c4a0fb3fbaa6ca87f3463ac124d

commit r14-6066-g7317275497e10c4a0fb3fbaa6ca87f3463ac124d
Author: Harald Anlauf 
Date:   Thu Nov 30 21:53:21 2023 +0100

Fortran: copy-out for possibly missing OPTIONAL CLASS arguments [PR112772]

gcc/fortran/ChangeLog:

PR fortran/112772
* trans-expr.cc (gfc_conv_class_to_class): Make copy-out
conditional
on the presence of an OPTIONAL CLASS argument passed to an OPTIONAL
CLASS dummy.

gcc/testsuite/ChangeLog:

PR fortran/112772
* gfortran.dg/missing_optional_dummy_7.f90: New test.

[Bug target/112816] [11/12/13/14 Regression] ICE unrecognizable_insn with __builtin_signbit and returning struct with int[4]

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-12-01
Summary|[11/12/13/14 Regression]|[11/12/13/14 Regression]
   |internal compiler error: in |ICE unrecognizable_insn
   |extract_insn, at|with __builtin_signbit and
   |recog.cc:2804,  |returning struct with
   |unrecognizable_insn for |int[4]
   |__builtin_signbit   |
 Ever confirmed|0   |1

--- Comment #2 from Andrew Pinski  ---
Confirmed.

[Bug target/112816] [11/12/13/14 Regression] internal compiler error: in extract_insn, at recog.cc:2804, unrecognizable_insn for __builtin_signbit

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

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

--- Comment #1 from Andrew Pinski  ---
Created attachment 56760
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56760=edit
C testcase

[Bug target/112816] [11/12/13/14 Regression] internal compiler error: in extract_insn, at recog.cc:2804, unrecognizable_insn for __builtin_signbit

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|internal compiler error: in |[11/12/13/14 Regression]
   |extract_insn, at|internal compiler error: in
   |recog.cc:2804,  |extract_insn, at
   |unrecognizable_insn for |recog.cc:2804,
   |__builtin_signbit   |unrecognizable_insn for
   ||__builtin_signbit
   Target Milestone|--- |11.5

[Bug target/112773] [14 Regression] RISC-V ICE: in force_align_down_and_div, at poly-int.h:1828 on rv32gcv_zvl256b

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

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

--- Comment #13 from Robin Dapp  ---
Mostly an issue because our expander is definitely not prepared to handle that
:)

It looks like aarch64's is, though, and ours can/should be changed then.
aarch64 doesn't need to implement a qi/bi extract from a mask because the
bit_field_ref fallback code works for sve masks.

There is (at least) three things that prevent us from creating a vec_extract
here.  First, my old friend MODE_BITSIZE vs MODE_PRECISION, second we expect a
mask -> BI extract here (while we do mask -> QI extraction on the other path)
but I haven't yet defined a vec_extract...bi either.
Once those two are our of the way I still hit QI vs BI inconsistencies but I
think they can be sorted out.  Then we emit a VLA vec_extract.

I hope to have a patch ready by Monday.

Re: [PATCH] Fortran: copy-out for possibly missing OPTIONAL CLASS arguments [PR112772]

[Harald Anlauf]

Hi Mikael,

On 12/1/23 21:24, Mikael Morin wrote:

Hello,

Le 30/11/2023 à 22:06, Harald Anlauf a écrit :

the attached rather obvious patch fixes the first testcase of pr112772:
we unconditionally generated copy-out code for optional class arguments,
while the copy-in properly checked the presence of arguments.

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


Looks good.
Thanks.


ok, will commit.


(The second testcase is a different issue.)


Maybe use a separate PR?

Mikael



I just found a fix that is regtesting, and which will allow to
re-enable the test failing with ASAN in the patch for PR100651.
Will merge that fix into the previous patch and submit a v3 later.

Thanks,
Harald

Re: [PATCH] gcc: Disallow trampolines when -fhardened

[Jakub Jelinek]

On Fri, Dec 01, 2023 at 03:53:14PM -0500, Marek Polacek wrote:
> On Fri, Dec 01, 2023 at 11:44:28AM -0800, Andrew Pinski wrote:
> > On Fri, Dec 1, 2023, 11:36 Marek Polacek  wrote:
> > 
> > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> > >
> > > -- >8 --
> > > It came up that a good hardening strategy is to disable trampolines
> > > which may require executable stack.  Therefore the following patch
> > > adds -Werror=trampolines to -fhardened.
> > >
> > 
> > It might make sense to add a fortran testcase too. Especially when that and
> > Ada are 2 biggest users of trampolines.
> 
> I don't know either of these languages to write a test, and I don't see
> anything that mentions the word trampoline in gfortran.dg/.  Ada has

program nesting
  integer :: i
  procedure(), pointer :: p
  p => foo
  i = 5
  call p
  if (i.ne.6) stop 1
contains
  subroutine foo
i = i + 1
  end subroutine
end program

(obviously at -O0 only)?

Jakub

[Bug middle-end/112816] New: internal compiler error: in extract_insn, at recog.cc:2804, unrecognizable_insn for __builtin_signbit

[a.elovikov at gmail dot com via Gcc-bugs]

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

Bug ID: 112816
   Summary: internal compiler error: in extract_insn, at
recog.cc:2804, unrecognizable_insn for
__builtin_signbit
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: a.elovikov at gmail dot com
  Target Milestone: ---

https://godbolt.org/z/3vzejjWcq

constexpr int N = 4;

template 
struct S {
T x[N];
T& operator[](int idx) { return x[idx]; }
};
auto foo(S x) {
  S res;
  for (int i = 0; i < 4; ++i)
res[i] = __builtin_signbit(x[i]) ? -1 : 0;
  return res;
}

Copy-pasting "x86-64 gcc (trunk)" output from the godbolt link above (-O3
-std=c++17 options used):
: In function 'auto foo(S)':
:13:1: error: unrecognizable insn:
   13 | }
  | ^
(insn 20 19 21 2 (set (reg:V4SI 99 [ vect__2.11 ])
(lshiftrt:V4SI (subreg:V4SI (subreg:V4SF (reg/v:TI 105 [ x ]) 0) 0)
(const_int 31 [0x1f]))) "":11:31 discrim 1 -1
 (nil))
during RTL pass: vregs
:13:1: internal compiler error: in extract_insn, at recog.cc:2804
0x26c14fe internal_error(char const*, ...)
???:0
0xb125b9 fancy_abort(char const*, int, char const*)
???:0
0x925e6a _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
???:0
0x925e8c _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.
Compiler returned: 1

Also reproducible with (the version I discovered it with)

$ g++ --version
g++ (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[Bug c++/112815] New: ICE: in vague_linkage_p, at cp/decl2.cc:2329 with -flto -fno-weak

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 112815
   Summary: ICE: in vague_linkage_p, at cp/decl2.cc:2329 with
-flto -fno-weak
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

Created attachment 56759
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56759=edit
reduced testcase

This crashes at the same place as PR107990, but with a different backtrace. It
has common -fno-weak flag.

The original testcase didn't output the warning: 'T::T()::U::U()' used but
never defined

Compiler output:
$ x86_64-pc-linux-gnu-gcc -flto -fno-weak testcase.C
testcase.C:7:7: warning: 'T::T()::U::U()' used but never defined
7 |   U ();
  |   ^
during IPA pass: *free_lang_data
testcase.C:5:12: internal compiler error: in vague_linkage_p, at
cp/decl2.cc:2329
5 | struct U
  |^
0x74d356 vague_linkage_p(tree_node*)
/repo/gcc-trunk/gcc/cp/decl2.cc:2329
0x11394bf no_linkage_check(tree_node*, bool)
/repo/gcc-trunk/gcc/cp/tree.cc:3022
0xfd1cf3 mangle_decl(tree_node*)
/repo/gcc-trunk/gcc/cp/mangle.cc:4146
0x1ad0a8d decl_assembler_name(tree_node*)
/repo/gcc-trunk/gcc/tree.cc:719
0x1af7747 assign_assembler_name_if_needed(tree_node*)
/repo/gcc-trunk/gcc/tree.cc:834
0x2916760 free_lang_data_in_cgraph
/repo/gcc-trunk/gcc/ipa-free-lang-data.cc:1064
0x2916760 free_lang_data
/repo/gcc-trunk/gcc/ipa-free-lang-data.cc:1109
0x2916760 execute
/repo/gcc-trunk/gcc/ipa-free-lang-data.cc:1176
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-6051-20231201105652-gb1fe98dee21-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--disable-bootstrap --with-cloog --with-ppl --with-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r14-6051-20231201105652-gb1fe98dee21-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20231201 (experimental) (GCC)

[Bug fortran/112772] Some issues with OPTIONAL, ALLOCATABLE dummy arguments

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

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

--- Comment #3 from anlauf at gcc dot gnu.org ---
Created attachment 56758
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56758=edit
Patch for testcase 2

This patch makes the initialization code seen in testcase 2
dependent on the presence of the optional argument.

Needs testing.

Re: [PATCH] gcc: Disallow trampolines when -fhardened

[Marek Polacek]

On Fri, Dec 01, 2023 at 11:44:28AM -0800, Andrew Pinski wrote:
> On Fri, Dec 1, 2023, 11:36 Marek Polacek  wrote:
> 
> > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> >
> > -- >8 --
> > It came up that a good hardening strategy is to disable trampolines
> > which may require executable stack.  Therefore the following patch
> > adds -Werror=trampolines to -fhardened.
> >
> 
> It might make sense to add a fortran testcase too. Especially when that and
> Ada are 2 biggest users of trampolines.

I don't know either of these languages to write a test, and I don't see
anything that mentions the word trampoline in gfortran.dg/.  Ada has
gnat.dg/trampoline3.adb but:

$ gcc -c -Wtrampolines trampoline3.adb
trampoline3.adb:6:03: warning: variable "A" is read but never assigned [-gnatwv]

so there is no warning.

Marek

[Bug tree-optimization/112814] `Plus , PHI>` is not optimized to just PLUS

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug tree-optimization/112814] `Plus , PHI>` is not optimized to just PLUS

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://github.com/llvm/llv
   ||m-project/issues/73904

--- Comment #1 from Andrew Pinski  ---
Similarly:
```
int f(int a, int b, int c)
{
int d, e;
return (c ? a : b) + (c ? b : a);
}
```


Note the above could be done using a match pattern. catching it before
gimplification.

Re: [PATCH] libsupc++: try cxa_thread_atexit_impl at runtime

[Jason Merrill]

On 12/1/23 15:40, Alexandre Oliva wrote:

On Nov  9, 2023, Jonathan Wakely  wrote:


On Thu, 9 Nov 2023 at 01:56, Alexandre Oliva  wrote:



g++.dg/tls/thread_local-order2.C fails when the toolchain is built for
a platform that lacks __cxa_thread_atexit_impl, even if the program is
built and run using that toolchain on a (later) platform that offers
__cxa_thread_atexit_impl.

This patch adds runtime testing for __cxa_thread_atexit_impl on
platforms that support weak symbols.

Regstrapped on x86_64-linux-gnu, also tested with gcc-13 on i686- and
x86_64-, and with ac_cv_func___cxa_thread_atexit_impl=no, that, on a
distro that lacks __cxa_thread_atexit in libc, forces the newly-added
code to be exercised, and that enabled thread_local-order2.C to pass
where the runtime libc has __cxa_thread_atexit_impl.  Ok to install?



Seems fine to me. Any objections, Jason?


Jason, ping?
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/635750.html


OK by me.

Jason

Re: [PATCH] libsupc++: try cxa_thread_atexit_impl at runtime

[Alexandre Oliva]

On Nov  9, 2023, Jonathan Wakely  wrote:

> On Thu, 9 Nov 2023 at 01:56, Alexandre Oliva  wrote:

>> g++.dg/tls/thread_local-order2.C fails when the toolchain is built for
>> a platform that lacks __cxa_thread_atexit_impl, even if the program is
>> built and run using that toolchain on a (later) platform that offers
>> __cxa_thread_atexit_impl.
>> 
>> This patch adds runtime testing for __cxa_thread_atexit_impl on
>> platforms that support weak symbols.
>> 
>> Regstrapped on x86_64-linux-gnu, also tested with gcc-13 on i686- and
>> x86_64-, and with ac_cv_func___cxa_thread_atexit_impl=no, that, on a
>> distro that lacks __cxa_thread_atexit in libc, forces the newly-added
>> code to be exercised, and that enabled thread_local-order2.C to pass
>> where the runtime libc has __cxa_thread_atexit_impl.  Ok to install?

> Seems fine to me. Any objections, Jason?

Jason, ping?
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/635750.html

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive

[Bug tree-optimization/112814] New: `Plus , PHI>` is not optimized to just PLUS

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

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

Bug ID: 112814
   Summary: `Plus , PHI>` is not optimized to just
PLUS
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

Take:
```
int f(int a, int b, int c)
{
int d, e;
if (c) d = a, e = b;
else   d = b, e = a;
return d+e;
}
```
This should just be optimized to `return a+b` but it is currently not.

Re: [PATCH] c++: decltype of (non-captured variable) [PR83167]

[Jason Merrill]

On 12/1/23 12:32, Patrick Palka wrote:

On Tue, 14 Nov 2023, Jason Merrill wrote:


On 11/14/23 11:10, Patrick Palka wrote:

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

-- >8 --

For decltype((x)) within a lambda where x is not captured, we dubiously
require that the lambda has a capture default, unlike for decltype(x).
This patch fixes this inconsistency; I couldn't find a justification for
it in the standard.


The relevant passage seems to be

https://eel.is/c++draft/expr.prim#id.unqual-3

"If naming the entity from outside of an unevaluated operand within S would
refer to an entity captured by copy in some intervening lambda-expression,
then let E be the innermost such lambda-expression.

If there is such a lambda-expression and if P is in E's function parameter
scope but not its parameter-declaration-clause, then the type of the
expression is the type of a class member access expression ([expr.ref]) naming
the non-static data member that would be declared for such a capture in the
object parameter ([dcl.fct]) of the function call operator of E."

In this case I guess there is no such lambda-expression because naming x won't
refer to a capture by copy if the lambda doesn't capture anything, so we
ignore the lambda.

Maybe refer to that in a comment?  OK with that change.

I'm surprised that it refers specifically to capture by copy, but I guess a
capture by reference should have the same decltype as the captured variable?


Ah, seems like it.  So maybe we should get rid of the redundant
by-reference capture-default handling, to more closely mirror the
standard?

Also now that r14-6026-g73e2bdbf9bed48 made capture_decltype return
NULL_TREE to mean the capture is dependent, it seems we should just
inline capture_decltype into finish_decltype_type rather than
introducing another special return value to mean "fall back to ordinary
handling".

How does the following look?  Bootstrapped and regtested on
x86_64-pc-linux-gnu.

-- >8 --

PR c++/83167

gcc/cp/ChangeLog:

* semantics.cc (capture_decltype): Inline into its only caller ...
(finish_decltype_type): ... here.  Update nearby comment to refer
to recent standard.  Restrict uncaptured variable handling to just
lambdas with a by-copy capture-default.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/lambda/lambda-decltype4.C: New test.
---
  gcc/cp/semantics.cc   | 107 +++---
  .../g++.dg/cpp0x/lambda/lambda-decltype4.C|  15 +++
  2 files changed, 55 insertions(+), 67 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/cpp0x/lambda/lambda-decltype4.C

diff --git a/gcc/cp/semantics.cc b/gcc/cp/semantics.cc
index fbbc18336a0..fb4c3992e34 100644
--- a/gcc/cp/semantics.cc
+++ b/gcc/cp/semantics.cc
@@ -53,7 +53,6 @@ along with GCC; see the file COPYING3.  If not see
  
  static tree maybe_convert_cond (tree);

  static tree finalize_nrv_r (tree *, int *, void *);
-static tree capture_decltype (tree);
  
  /* Used for OpenMP non-static data member privatization.  */
  
@@ -11856,21 +11855,48 @@ finish_decltype_type (tree expr, bool id_expression_or_member_access_p,

  }
else
  {
-  /* Within a lambda-expression:
-
-Every occurrence of decltype((x)) where x is a possibly
-parenthesized id-expression that names an entity of
-automatic storage duration is treated as if x were
-transformed into an access to a corresponding data member
-of the closure type that would have been declared if x
-were a use of the denoted entity.  */
if (outer_automatic_var_p (STRIP_REFERENCE_REF (expr))
  && current_function_decl
  && LAMBDA_FUNCTION_P (current_function_decl))
{
- type = capture_decltype (STRIP_REFERENCE_REF (expr));
- if (!type)
-   goto dependent;
+ /* [expr.prim.id.unqual]/3: If naming the entity from outside of an
+unevaluated operand within S would refer to an entity captured by
+copy in some intervening lambda-expression, then let E be the
+innermost such lambda-expression.
+
+If there is such a lambda-expression and if P is in E's function
+parameter scope but not its parameter-declaration-clause, then the
+type of the expression is the type of a class member access
+expression naming the non-static data member that would be declared
+for such a capture in the object parameter of the function call
+operator of E."  */


Hmm, looks like this code is only checking the innermost lambda, it 
needs to check all containing lambdas for one that would capture it by copy.



+ tree decl = STRIP_REFERENCE_REF (expr);
+ tree lam = CLASSTYPE_LAMBDA_EXPR (DECL_CONTEXT 
(current_function_decl));
+ tree cap = lookup_name (DECL_NAME (decl), LOOK_where::BLOCK,
+ 

Re: [PATCH] Fortran: copy-out for possibly missing OPTIONAL CLASS arguments [PR112772]

[Mikael Morin]

Hello,

Le 30/11/2023 à 22:06, Harald Anlauf a écrit :

the attached rather obvious patch fixes the first testcase of pr112772:
we unconditionally generated copy-out code for optional class arguments,
while the copy-in properly checked the presence of arguments.

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


Looks good.
Thanks.


(The second testcase is a different issue.)


Maybe use a separate PR?

Mikael

[Bug target/112813] New: [14 Regression] RISCV ICE: vsetvl pass: in merge at config/riscv/riscv-vsetvl.cc:1968 on rv32gcv_zvl256b

[patrick at rivosinc dot com via Gcc-bugs]

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

Bug ID: 112813
   Summary: [14 Regression] RISCV ICE: vsetvl pass: in merge at
config/riscv/riscv-vsetvl.cc:1968 on rv32gcv_zvl256b
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: patrick at rivosinc dot com
  Target Milestone: ---

Created attachment 56757
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56757=edit
-freport-bug output

> /scratch/tc-testing/tc-nov-30-trunk/build-rv64gcv/bin/riscv64-unknown-linux-gnu-gcc
>  -march=rv32gcv_zvl256b -mabi=ilp32d -O3 red.c -S -freport-bug
during RTL pass: vsetvl
red.c: In function 'k':
red.c:21:1: internal compiler error: in merge, at
config/riscv/riscv-vsetvl.cc:1968
   21 | }
  | ^
0xac3d86 demand_system::merge(vsetvl_info&, vsetvl_info const&)
../../../gcc/gcc/config/riscv/riscv-vsetvl.cc:1968
0xac3d86 pre_vsetvl::earliest_fuse_vsetvl_info()
../../../gcc/gcc/config/riscv/riscv-vsetvl.cc:2992
0x1733d79 pass_vsetvl::lazy_vsetvl()
../../../gcc/gcc/config/riscv/riscv-vsetvl.cc:3472
0x17340df pass_vsetvl::execute(function*)
../../../gcc/gcc/config/riscv/riscv-vsetvl.cc:3519
0x17340df pass_vsetvl::execute(function*)
../../../gcc/gcc/config/riscv/riscv-vsetvl.cc:3502
Please submit a full bug report, with preprocessed source.
Please include the complete backtrace with any bug report.
See  for instructions.
Preprocessed source stored into /scratch/tmp/ccoSwl1N.out file, please attach
this to your bugreport.

creduced testcase:
int a, c, d, f, j;
int b[7];
long e;
char *g;
int *h;
long long *i;
void k() {
  int l[][1] = {{}, {1}, {1}};
  int *m = , *n = [0][0];
  for (; e;) {
f = 3;
for (; f >= 0; f--) {
  *m &= b[f] >= 0;
  j = a >= 2 ? 0 : 1 >> a;
  *i |= j;
}
for (; c;)
  *g = 0;
  }
  h = n;
}

I've attached the -freport-bug output.

Compiler explorer: https://godbolt.org/z/G49a3P8Ef

Re: [PATCH] gcc: Disallow trampolines when -fhardened

[Andrew Pinski]

On Fri, Dec 1, 2023, 11:36 Marek Polacek  wrote:

> Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
>
> -- >8 --
> It came up that a good hardening strategy is to disable trampolines
> which may require executable stack.  Therefore the following patch
> adds -Werror=trampolines to -fhardened.
>

It might make sense to add a fortran testcase too. Especially when that and
Ada are 2 biggest users of trampolines.

Thanks,
Andrew




> gcc/ChangeLog:
>
> * common.opt (Wtrampolines): Enable by -fhardened.
> * doc/invoke.texi: Reflect that -fhardened enables
> -Werror=trampolines.
> * opts.cc (print_help_hardened): Add -Werror=trampolines.
> * toplev.cc (process_options): Enable -Werror=trampolines for
> -fhardened.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.dg/fhardened-1.c: New test.
> * gcc.dg/fhardened-2.c: New test.
> * gcc.dg/fhardened-3.c: New test.
> * gcc.dg/fhardened-4.c: New test.
> * gcc.dg/fhardened-5.c: New test.
> ---
>  gcc/common.opt |  2 +-
>  gcc/doc/invoke.texi|  1 +
>  gcc/opts.cc|  1 +
>  gcc/testsuite/gcc.dg/fhardened-1.c | 27 +++
>  gcc/testsuite/gcc.dg/fhardened-2.c | 25 +
>  gcc/testsuite/gcc.dg/fhardened-3.c | 25 +
>  gcc/testsuite/gcc.dg/fhardened-4.c | 25 +
>  gcc/testsuite/gcc.dg/fhardened-5.c | 27 +++
>  gcc/toplev.cc  |  8 +++-
>  9 files changed, 139 insertions(+), 2 deletions(-)
>  create mode 100644 gcc/testsuite/gcc.dg/fhardened-1.c
>  create mode 100644 gcc/testsuite/gcc.dg/fhardened-2.c
>  create mode 100644 gcc/testsuite/gcc.dg/fhardened-3.c
>  create mode 100644 gcc/testsuite/gcc.dg/fhardened-4.c
>  create mode 100644 gcc/testsuite/gcc.dg/fhardened-5.c
>
> diff --git a/gcc/common.opt b/gcc/common.opt
> index 161a035d736..9b09c7cb3df 100644
> --- a/gcc/common.opt
> +++ b/gcc/common.opt
> @@ -807,7 +807,7 @@ Common Var(warn_system_headers) Warning
>  Do not suppress warnings from system headers.
>
>  Wtrampolines
> -Common Var(warn_trampolines) Warning
> +Common Var(warn_trampolines) Warning EnabledBy(fhardened)
>  Warn whenever a trampoline is generated.
>
>  Wtrivial-auto-var-init
> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
> index 2fab4c5d71f..c1664a1a0f1 100644
> --- a/gcc/doc/invoke.texi
> +++ b/gcc/doc/invoke.texi
> @@ -17745,6 +17745,7 @@ may change between major releases of GCC, but are
> currently:
>  -fstack-protector-strong
>  -fstack-clash-protection
>  -fcf-protection=full @r{(x86 GNU/Linux only)}
> +-Werror=trampolines
>  }
>
>  The list of options enabled by @option{-fhardened} can be generated using
> diff --git a/gcc/opts.cc b/gcc/opts.cc
> index 5d5efaf1b9e..aa062b87cef 100644
> --- a/gcc/opts.cc
> +++ b/gcc/opts.cc
> @@ -2517,6 +2517,7 @@ print_help_hardened ()
>printf ("  %s\n", "-fstack-protector-strong");
>printf ("  %s\n", "-fstack-clash-protection");
>printf ("  %s\n", "-fcf-protection=full");
> +  printf ("  %s\n", "-Werror=trampolines");
>putchar ('\n');
>  }
>
> diff --git a/gcc/testsuite/gcc.dg/fhardened-1.c
> b/gcc/testsuite/gcc.dg/fhardened-1.c
> new file mode 100644
> index 000..8710959b6f1
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/fhardened-1.c
> @@ -0,0 +1,27 @@
> +/* { dg-do compile { target *-*-linux* *-*-gnu* } } */
> +/* { dg-require-effective-target trampolines } */
> +/* { dg-options "-fhardened -O" } */
> +
> +static void
> +baz (int (*bar) (void))
> +{
> +  bar ();
> +}
> +
> +int
> +main (void)
> +{
> +  int a = 6;
> +
> +  int
> +  bar (void)   // { dg-error "trampoline" }
> +  {
> +return a;
> +  }
> +
> +  baz (bar);
> +
> +  return 0;
> +}
> +
> +/* { dg-prune-output "some warnings being treated as errors" } */
> diff --git a/gcc/testsuite/gcc.dg/fhardened-2.c
> b/gcc/testsuite/gcc.dg/fhardened-2.c
> new file mode 100644
> index 000..d47512aa47f
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/fhardened-2.c
> @@ -0,0 +1,25 @@
> +/* { dg-do compile { target *-*-linux* *-*-gnu* } } */
> +/* { dg-require-effective-target trampolines } */
> +/* { dg-options "-fhardened -O -Wno-trampolines" } */
> +
> +static void
> +baz (int (*bar) (void))
> +{
> +  bar ();
> +}
> +
> +int
> +main (void)
> +{
> +  int a = 6;
> +
> +  int
> +  bar (void)   // { dg-bogus "trampoline" }
> +  {
> +return a;
> +  }
> +
> +  baz (bar);
> +
> +  return 0;
> +}
> diff --git a/gcc/testsuite/gcc.dg/fhardened-3.c
> b/gcc/testsuite/gcc.dg/fhardened-3.c
> new file mode 100644
> index 000..cebae13d8be
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/fhardened-3.c
> @@ -0,0 +1,25 @@
> +/* { dg-do compile { target *-*-linux* *-*-gnu* } } */
> +/* { dg-require-effective-target trampolines } */
> +/* { dg-options "-fhardened -O -Wno-error" } */
> +
> +static void
> +baz (int (*bar) (void))
> +{
> +  bar ();
> +}
> +
> +int
> 

[PATCH] gcc: Disallow trampolines when -fhardened

[Marek Polacek]

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

-- >8 --
It came up that a good hardening strategy is to disable trampolines
which may require executable stack.  Therefore the following patch
adds -Werror=trampolines to -fhardened.

gcc/ChangeLog:

* common.opt (Wtrampolines): Enable by -fhardened.
* doc/invoke.texi: Reflect that -fhardened enables -Werror=trampolines.
* opts.cc (print_help_hardened): Add -Werror=trampolines.
* toplev.cc (process_options): Enable -Werror=trampolines for
-fhardened.

gcc/testsuite/ChangeLog:

* gcc.dg/fhardened-1.c: New test.
* gcc.dg/fhardened-2.c: New test.
* gcc.dg/fhardened-3.c: New test.
* gcc.dg/fhardened-4.c: New test.
* gcc.dg/fhardened-5.c: New test.
---
 gcc/common.opt |  2 +-
 gcc/doc/invoke.texi|  1 +
 gcc/opts.cc|  1 +
 gcc/testsuite/gcc.dg/fhardened-1.c | 27 +++
 gcc/testsuite/gcc.dg/fhardened-2.c | 25 +
 gcc/testsuite/gcc.dg/fhardened-3.c | 25 +
 gcc/testsuite/gcc.dg/fhardened-4.c | 25 +
 gcc/testsuite/gcc.dg/fhardened-5.c | 27 +++
 gcc/toplev.cc  |  8 +++-
 9 files changed, 139 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/fhardened-1.c
 create mode 100644 gcc/testsuite/gcc.dg/fhardened-2.c
 create mode 100644 gcc/testsuite/gcc.dg/fhardened-3.c
 create mode 100644 gcc/testsuite/gcc.dg/fhardened-4.c
 create mode 100644 gcc/testsuite/gcc.dg/fhardened-5.c

diff --git a/gcc/common.opt b/gcc/common.opt
index 161a035d736..9b09c7cb3df 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -807,7 +807,7 @@ Common Var(warn_system_headers) Warning
 Do not suppress warnings from system headers.
 
 Wtrampolines
-Common Var(warn_trampolines) Warning
+Common Var(warn_trampolines) Warning EnabledBy(fhardened)
 Warn whenever a trampoline is generated.
 
 Wtrivial-auto-var-init
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 2fab4c5d71f..c1664a1a0f1 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -17745,6 +17745,7 @@ may change between major releases of GCC, but are 
currently:
 -fstack-protector-strong
 -fstack-clash-protection
 -fcf-protection=full @r{(x86 GNU/Linux only)}
+-Werror=trampolines
 }
 
 The list of options enabled by @option{-fhardened} can be generated using
diff --git a/gcc/opts.cc b/gcc/opts.cc
index 5d5efaf1b9e..aa062b87cef 100644
--- a/gcc/opts.cc
+++ b/gcc/opts.cc
@@ -2517,6 +2517,7 @@ print_help_hardened ()
   printf ("  %s\n", "-fstack-protector-strong");
   printf ("  %s\n", "-fstack-clash-protection");
   printf ("  %s\n", "-fcf-protection=full");
+  printf ("  %s\n", "-Werror=trampolines");
   putchar ('\n');
 }
 
diff --git a/gcc/testsuite/gcc.dg/fhardened-1.c 
b/gcc/testsuite/gcc.dg/fhardened-1.c
new file mode 100644
index 000..8710959b6f1
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/fhardened-1.c
@@ -0,0 +1,27 @@
+/* { dg-do compile { target *-*-linux* *-*-gnu* } } */
+/* { dg-require-effective-target trampolines } */
+/* { dg-options "-fhardened -O" } */
+
+static void
+baz (int (*bar) (void))
+{
+  bar ();
+}
+
+int
+main (void)
+{
+  int a = 6;
+
+  int
+  bar (void)   // { dg-error "trampoline" }
+  {
+return a;
+  }
+
+  baz (bar);
+
+  return 0;
+}
+
+/* { dg-prune-output "some warnings being treated as errors" } */
diff --git a/gcc/testsuite/gcc.dg/fhardened-2.c 
b/gcc/testsuite/gcc.dg/fhardened-2.c
new file mode 100644
index 000..d47512aa47f
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/fhardened-2.c
@@ -0,0 +1,25 @@
+/* { dg-do compile { target *-*-linux* *-*-gnu* } } */
+/* { dg-require-effective-target trampolines } */
+/* { dg-options "-fhardened -O -Wno-trampolines" } */
+
+static void
+baz (int (*bar) (void))
+{
+  bar ();
+}
+
+int
+main (void)
+{
+  int a = 6;
+
+  int
+  bar (void)   // { dg-bogus "trampoline" }
+  {
+return a;
+  }
+
+  baz (bar);
+
+  return 0;
+}
diff --git a/gcc/testsuite/gcc.dg/fhardened-3.c 
b/gcc/testsuite/gcc.dg/fhardened-3.c
new file mode 100644
index 000..cebae13d8be
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/fhardened-3.c
@@ -0,0 +1,25 @@
+/* { dg-do compile { target *-*-linux* *-*-gnu* } } */
+/* { dg-require-effective-target trampolines } */
+/* { dg-options "-fhardened -O -Wno-error" } */
+
+static void
+baz (int (*bar) (void))
+{
+  bar ();
+}
+
+int
+main (void)
+{
+  int a = 6;
+
+  int
+  bar (void)   // { dg-warning "trampoline" }
+  {
+return a;
+  }
+
+  baz (bar);
+
+  return 0;
+}
diff --git a/gcc/testsuite/gcc.dg/fhardened-4.c 
b/gcc/testsuite/gcc.dg/fhardened-4.c
new file mode 100644
index 000..7e62ed3385d
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/fhardened-4.c
@@ -0,0 +1,25 @@
+/* { dg-do compile { target *-*-linux* *-*-gnu* } } */
+/* { dg-require-effective-target trampolines } */
+/* { dg-options "-fhardened -O 

[Bug tree-optimization/112788] [14 regression] ICEs in fold_range, at range-op.cc:206 after r14-5972-gea19de921b01a6

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #2 from Andrew Macleod  ---
(In reply to Kewen Lin from comment #1)

> 
> ranger makes use of type precision directly instead of something like
> types_compatible_p. I wonder if we can introduce a target hook (or hookpod)
> to make ranger unrestrict this check a bit, the justification is that for
> float type its precision information is encoded in its underlying
> real_format, if two float types underlying modes are the same, the precision
> are actually the same. 
> 
> btw, the operand_check_ps seems able to call range_compatible_p?

It could, but just a precision check seemed enough at the time.
The patch also went thru many iterations and it was only the final version that
operand_check_p() ended up with types as the parameter rather than ranges.

You bring up a good point tho. I just switched those routines to call
range_compatible_p() and checked it in.  Now it is all centralized in the one
routine going forward. 

It does seem wrong that the float precision don't match, and weird that its
hard to fix :-)   It should now be possible to have range_compatible_p check
the underlying mode for floats rather than the precision...  If there's a good
argument for it, and you want to give that a shot...

[COMMITTED] Use range_compatible_p in check_operands_p.

[Andrew MacLeod]

Comments in PR 112788 correctly brought up that the new 
check_operands_p() routine is directly checking precision rather than 
calling range_compatible_p().


Most earlier iterations of the original patch had ranges as arguments, 
and it wasn't primarily a CHECKING_P only call then...   Regardless, it 
makes total sense to call range_compatible_p so this patch does exactly 
that.  It required moving range_compatible_p() into value-range.h and 
then adjusting each check_operands_p() routine.


Now range type compatibility is centralized again :-P

Bootstraps on x86_64-pc-linux-gnu with no new regressions.

Andrew

From c6bb413eeb9d13412e8101e3029099d7fd746708 Mon Sep 17 00:00:00 2001
From: Andrew MacLeod 
Date: Fri, 1 Dec 2023 11:15:33 -0500
Subject: [PATCH] Use range_compatible_p in check_operands_p.

Instead of directly checking type precision, check_operands_p should
invoke range_compatible_p to keep the range checking centralized.

	* gimple-range-fold.h (range_compatible_p): Relocate.
	* value-range.h (range_compatible_p): Here.
	* range-op-mixed.h (operand_equal::operand_check_p): Call
	range_compatible_p rather than comparing precision.
	(operand_not_equal::operand_check_p): Ditto.
	(operand_not_lt::operand_check_p): Ditto.
	(operand_not_le::operand_check_p): Ditto.
	(operand_not_gt::operand_check_p): Ditto.
	(operand_not_ge::operand_check_p): Ditto.
	(operand_plus::operand_check_p): Ditto.
	(operand_abs::operand_check_p): Ditto.
	(operand_minus::operand_check_p): Ditto.
	(operand_negate::operand_check_p): Ditto.
	(operand_mult::operand_check_p): Ditto.
	(operand_bitwise_not::operand_check_p): Ditto.
	(operand_bitwise_xor::operand_check_p): Ditto.
	(operand_bitwise_and::operand_check_p): Ditto.
	(operand_bitwise_or::operand_check_p): Ditto.
	(operand_min::operand_check_p): Ditto.
	(operand_max::operand_check_p): Ditto.
	* range-op.cc (operand_lshift::operand_check_p): Ditto.
	(operand_rshift::operand_check_p): Ditto.
	(operand_logical_and::operand_check_p): Ditto.
	(operand_logical_or::operand_check_p): Ditto.
	(operand_logical_not::operand_check_p): Ditto.
---
 gcc/gimple-range-fold.h | 12 
 gcc/range-op-mixed.h| 43 -
 gcc/range-op.cc | 12 +---
 gcc/value-range.h   | 11 +++
 4 files changed, 33 insertions(+), 45 deletions(-)

diff --git a/gcc/gimple-range-fold.h b/gcc/gimple-range-fold.h
index fcbe1626790..0094b4e3f35 100644
--- a/gcc/gimple-range-fold.h
+++ b/gcc/gimple-range-fold.h
@@ -89,18 +89,6 @@ gimple_range_ssa_p (tree exp)
   return NULL_TREE;
 }
 
-// Return true if TYPE1 and TYPE2 are compatible range types.
-
-inline bool
-range_compatible_p (tree type1, tree type2)
-{
-  // types_compatible_p requires conversion in both directions to be useless.
-  // GIMPLE only requires a cast one way in order to be compatible.
-  // Ranges really only need the sign and precision to be the same.
-  return (TYPE_PRECISION (type1) == TYPE_PRECISION (type2)
-	  && TYPE_SIGN (type1) == TYPE_SIGN (type2));
-}
-
 // Source of all operands for fold_using_range and gori_compute.
 // It abstracts out the source of an operand so it can come from a stmt or
 // and edge or anywhere a derived class of fur_source wants.
diff --git a/gcc/range-op-mixed.h b/gcc/range-op-mixed.h
index 4386a68e946..7e3ee17ccbd 100644
--- a/gcc/range-op-mixed.h
+++ b/gcc/range-op-mixed.h
@@ -140,7 +140,7 @@ public:
 		   const irange ) const final override;
   // Check op1 and op2 for compatibility.
   bool operand_check_p (tree, tree t1, tree t2) const final override
-{ return TYPE_PRECISION (t1) == TYPE_PRECISION (t2); }
+{ return range_compatible_p (t1, t2); }
 };
 
 class operator_not_equal : public range_operator
@@ -179,7 +179,7 @@ public:
 		   const irange ) const final override;
   // Check op1 and op2 for compatibility.
   bool operand_check_p (tree, tree t1, tree t2) const final override
-{ return TYPE_PRECISION (t1) == TYPE_PRECISION (t2); }
+{ return range_compatible_p (t1, t2); }
 };
 
 class operator_lt :  public range_operator
@@ -215,7 +215,7 @@ public:
 		   const irange ) const final override;
   // Check op1 and op2 for compatibility.
   bool operand_check_p (tree, tree t1, tree t2) const final override
-{ return TYPE_PRECISION (t1) == TYPE_PRECISION (t2); }
+{ return range_compatible_p (t1, t2); }
 };
 
 class operator_le :  public range_operator
@@ -254,7 +254,7 @@ public:
 		   const irange ) const final override;
   // Check op1 and op2 for compatibility.
   bool operand_check_p (tree, tree t1, tree t2) const final override
-{ return TYPE_PRECISION (t1) == TYPE_PRECISION (t2); }
+{ return range_compatible_p (t1, t2); }
 };
 
 class operator_gt :  public range_operator
@@ -292,7 +292,7 @@ public:
 		   const irange ) const final override;
   // Check op1 and op2 for compatibility.
   bool operand_check_p (tree, tree t1, tree t2) const final override
-{ return TYPE_PRECISION 

Re: [pushed] c++: remove LAMBDA_EXPR_MUTABLE_P

[Patrick Palka]

On Thu, 30 Nov 2023, Jason Merrill wrote:

> Tested x86_64-pc-linux-gnu, applying to trunk.
> 
> -- 8< --
> 
> In review of the deducing 'this' patch it came up that LAMBDA_EXPR_MUTABLE_P
> doesn't make sense for a lambda with an explicit object parameter.  And it
> was never necessary, so let's remove it.
> 
> gcc/cp/ChangeLog:
> 
>   * cp-tree.h (LAMBDA_EXPR_MUTABLE_P): Remove.
>   * cp-tree.def: Remove documentation.
>   * lambda.cc (build_lambda_expr): Remove reference.
>   * parser.cc (cp_parser_lambda_declarator_opt): Likewise.
>   * pt.cc (tsubst_lambda_expr): Likewise.
>   * ptree.cc (cxx_print_lambda_node): Likewise.
>   * semantics.cc (capture_decltype): Get the object quals
>   from the object instead.
> ---
>  gcc/cp/cp-tree.h| 5 -
>  gcc/cp/lambda.cc| 1 -
>  gcc/cp/parser.cc| 1 -
>  gcc/cp/pt.cc| 1 -
>  gcc/cp/ptree.cc | 2 --
>  gcc/cp/semantics.cc | 9 ++---
>  gcc/cp/cp-tree.def  | 3 +--
>  7 files changed, 7 insertions(+), 15 deletions(-)
> 
> diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
> index 5614b71eed4..964af1ddd85 100644
> --- a/gcc/cp/cp-tree.h
> +++ b/gcc/cp/cp-tree.h
> @@ -461,7 +461,6 @@ extern GTY(()) tree cp_global_trees[CPTI_MAX];
>TYPENAME_IS_CLASS_P (in TYPENAME_TYPE)
>STMT_IS_FULL_EXPR_P (in _STMT)
>TARGET_EXPR_LIST_INIT_P (in TARGET_EXPR)
> -  LAMBDA_EXPR_MUTABLE_P (in LAMBDA_EXPR)
>DECL_FINAL_P (in FUNCTION_DECL)
>QUALIFIED_NAME_IS_TEMPLATE (in SCOPE_REF)
>CONSTRUCTOR_IS_DEPENDENT (in CONSTRUCTOR)
> @@ -1478,10 +1477,6 @@ enum cp_lambda_default_capture_mode_type {
>  #define LAMBDA_EXPR_CAPTURES_THIS_P(NODE) \
>LAMBDA_EXPR_THIS_CAPTURE(NODE)
>  
> -/* Predicate tracking whether the lambda was declared 'mutable'.  */
> -#define LAMBDA_EXPR_MUTABLE_P(NODE) \
> -  TREE_LANG_FLAG_1 (LAMBDA_EXPR_CHECK (NODE))
> -
>  /* True iff uses of a const variable capture were optimized away.  */
>  #define LAMBDA_EXPR_CAPTURE_OPTIMIZED(NODE) \
>TREE_LANG_FLAG_2 (LAMBDA_EXPR_CHECK (NODE))
> diff --git a/gcc/cp/lambda.cc b/gcc/cp/lambda.cc
> index 34d0190a89b..be8d240944d 100644
> --- a/gcc/cp/lambda.cc
> +++ b/gcc/cp/lambda.cc
> @@ -44,7 +44,6 @@ build_lambda_expr (void)
>LAMBDA_EXPR_THIS_CAPTURE (lambda) = NULL_TREE;
>LAMBDA_EXPR_REGEN_INFO   (lambda) = NULL_TREE;
>LAMBDA_EXPR_PENDING_PROXIES  (lambda) = NULL;
> -  LAMBDA_EXPR_MUTABLE_P(lambda) = false;
>return lambda;
>  }
>  
> diff --git a/gcc/cp/parser.cc b/gcc/cp/parser.cc
> index 2464d1a0783..1826b6175f5 100644
> --- a/gcc/cp/parser.cc
> +++ b/gcc/cp/parser.cc
> @@ -11770,7 +11770,6 @@ cp_parser_lambda_declarator_opt (cp_parser* parser, 
> tree lambda_expr)
>  
>if (lambda_specs.storage_class == sc_mutable)
>  {
> -  LAMBDA_EXPR_MUTABLE_P (lambda_expr) = 1;
>quals = TYPE_UNQUALIFIED;
>  }
>else if (lambda_specs.storage_class == sc_static)
> diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
> index c18718b319d..00a808bf323 100644
> --- a/gcc/cp/pt.cc
> +++ b/gcc/cp/pt.cc
> @@ -19341,7 +19341,6 @@ tsubst_lambda_expr (tree t, tree args, tsubst_flags_t 
> complain, tree in_decl)
>  = LAMBDA_EXPR_LOCATION (t);
>LAMBDA_EXPR_DEFAULT_CAPTURE_MODE (r)
>  = LAMBDA_EXPR_DEFAULT_CAPTURE_MODE (t);
> -  LAMBDA_EXPR_MUTABLE_P (r) = LAMBDA_EXPR_MUTABLE_P (t);
>if (tree ti = LAMBDA_EXPR_REGEN_INFO (t))
>  LAMBDA_EXPR_REGEN_INFO (r)
>= build_template_info (t, add_to_template_args (TI_ARGS (ti),
> diff --git a/gcc/cp/ptree.cc b/gcc/cp/ptree.cc
> index 32c5b5280dc..d1f58921fab 100644
> --- a/gcc/cp/ptree.cc
> +++ b/gcc/cp/ptree.cc
> @@ -265,8 +265,6 @@ cxx_print_identifier (FILE *file, tree node, int indent)
>  void
>  cxx_print_lambda_node (FILE *file, tree node, int indent)
>  {
> -  if (LAMBDA_EXPR_MUTABLE_P (node))
> -fprintf (file, " /mutable");
>fprintf (file, " default_capture_mode=[");
>switch (LAMBDA_EXPR_DEFAULT_CAPTURE_MODE (node))
>  {
> diff --git a/gcc/cp/semantics.cc b/gcc/cp/semantics.cc
> index 04b0540599a..36b57ac9524 100644
> --- a/gcc/cp/semantics.cc
> +++ b/gcc/cp/semantics.cc
> @@ -12792,9 +12792,12 @@ capture_decltype (tree decl)
>  
>if (!TYPE_REF_P (type))
>  {
> -  if (!LAMBDA_EXPR_MUTABLE_P (lam))
> - type = cp_build_qualified_type (type, (cp_type_quals (type)
> -|TYPE_QUAL_CONST));
> +  int quals = cp_type_quals (type);
> +  tree obtype = TREE_TYPE (DECL_ARGUMENTS (current_function_decl));
> +  gcc_checking_assert (!WILDCARD_TYPE_P (non_reference (obtype)));
> +  if (INDIRECT_TYPE_P (obtype))
> + quals |= cp_type_quals (TREE_TYPE (obtype));

Shouldn't we propagate cv-quals of a by-value object parameter as well?

> +  type = cp_build_qualified_type (type, quals);
>type = build_reference_type (type);
>  }
>return type;
> diff --git a/gcc/cp/cp-tree.def b/gcc/cp/cp-tree.def
> index 

[Bug fortran/111880] [11/12/13/14] False positive warning of obsolescent COMMON block with Fortran submodule

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #11 from anlauf at gcc dot gnu.org ---
Fixed on all open branches.  Closing.

[Bug fortran/111880] [11/12/13/14] False positive warning of obsolescent COMMON block with Fortran submodule

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

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

--- Comment #10 from GCC Commits  ---
The releases/gcc-11 branch has been updated by Harald Anlauf
:

https://gcc.gnu.org/g:246760b37f1239b3b97c20fb4a914f21154389a3

commit r11-9-g246760b37f1239b3b97c20fb4a914f21154389a3
Author: Harald Anlauf 
Date:   Thu Nov 23 22:48:38 2023 +0100

Fortran: avoid obsolescence warning for COMMON with submodule [PR111880]

gcc/fortran/ChangeLog:

PR fortran/111880
* resolve.c (resolve_common_vars): Do not call gfc_add_in_common
for symbols that are USE associated or used in a submodule.

gcc/testsuite/ChangeLog:

PR fortran/111880
* gfortran.dg/pr111880.f90: New test.

(cherry picked from commit c9d029ba2ceb435e31492c1f3f0fd3edf0e386be)

[pushed][PR112445][LRA]: Fix "unable to find a register to spill" error

[Vladimir Makarov]

The following patch fixes

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

The patch was successfully bootstrapped and tested on x86-64, aarch64, 
ppc64le.
commit 1390bf52c17a71834a1766c0222e4f8a74efb162
Author: Vladimir N. Makarov 
Date:   Fri Dec 1 11:46:37 2023 -0500

[PR112445][LRA]: Fix "unable to find a register to spill" error

PR112445 is a very complicated bug occurring from interaction of
constraint subpass, inheritance, and hard reg live range splitting.
It is hard to debug this PR only from LRA standard logs.  Therefore I
added dumping all func insns at the end of complicated sub-passes
(constraint, inheritance, undoing inheritance, hard reg live range
splitting, and rematerialization).  As such output can be quite big,
it is switched only one level 7 of -fira-verbose value.  The reason
for the bug is a skip of live-range splitting of hard reg (dx) on the
1st live range splitting subpass.  Splitting is done for reload
pseudos around an original insn and its reload insns but the subpass
did not recognize such insn pattern because previous inheritance and
undoing inheritance subpasses extended a bit reload pseudo live range.
Although we undid inheritance in question, the result code was a bit
different from a code before the corresponding inheritance pass.  The
following fixes the bug by restoring exact code before the
inheritance.

gcc/ChangeLog:

PR target/112445
* lra.h (lra): Add one more arg.
* lra-int.h (lra_verbose, lra_dump_insns): New externals.
(lra_dump_insns_if_possible): Ditto.
* lra.cc (lra_dump_insns): Dump all insns.
(lra_dump_insns_if_possible):  Dump all insns for lra_verbose >= 7.
(lra_verbose): New global.
(lra): Add new arg.  Setup lra_verbose from its value.
* lra-assigns.cc (lra_split_hard_reg_for): Dump insns if rtl
was changed.
* lra-remat.cc (lra_remat): Dump insns if rtl was changed.
* lra-constraints.cc (lra_inheritance): Dump insns.
(lra_constraints, lra_undo_inheritance): Dump insns if rtl
was changed.
(remove_inheritance_pseudos): Use restore reg if it is set up.
* ira.cc: (lra): Pass internal_flag_ira_verbose.

gcc/testsuite/ChangeLog:

PR target/112445
* gcc.target/i386/pr112445.c: New test.

diff --git a/gcc/ira.cc b/gcc/ira.cc
index d7530f01380..b5c4c0e4af7 100644
--- a/gcc/ira.cc
+++ b/gcc/ira.cc
@@ -5970,7 +5970,7 @@ do_reload (void)
 
   ira_destroy ();
 
-  lra (ira_dump_file);
+  lra (ira_dump_file, internal_flag_ira_verbose);
   /* ???!!! Move it before lra () when we use ira_reg_equiv in
 	 LRA.  */
   vec_free (reg_equivs);
diff --git a/gcc/lra-assigns.cc b/gcc/lra-assigns.cc
index d2ebcfd5056..7aa210e986f 100644
--- a/gcc/lra-assigns.cc
+++ b/gcc/lra-assigns.cc
@@ -1835,6 +1835,7 @@ lra_split_hard_reg_for (void)
   if (spill_p)
 {
   bitmap_clear (_reload_pseudos);
+  lra_dump_insns_if_possible ("changed func after splitting hard regs");
   return true;
 }
   bitmap_clear (_reload_pseudos);
diff --git a/gcc/lra-constraints.cc b/gcc/lra-constraints.cc
index 9b6a2af5b75..177c765ca13 100644
--- a/gcc/lra-constraints.cc
+++ b/gcc/lra-constraints.cc
@@ -5537,6 +5537,8 @@ lra_constraints (bool first_p)
 	  lra_assert (df_regs_ever_live_p (hard_regno + j));
 	  }
 }
+  if (changed_p)
+lra_dump_insns_if_possible ("changed func after local");
   return changed_p;
 }
 
@@ -7277,7 +7279,7 @@ lra_inheritance (void)
   bitmap_release (_invariant_regs);
   bitmap_release (_only_regs);
   free (usage_insns);
-
+  lra_dump_insns_if_possible ("func after inheritance");
   timevar_pop (TV_LRA_INHERITANCE);
 }
 
@@ -7477,13 +7479,16 @@ remove_inheritance_pseudos (bitmap remove_pseudos)
 			   == get_regno (lra_reg_info[prev_sregno].restore_rtx
 		  && ! bitmap_bit_p (remove_pseudos, prev_sregno))
 		{
+		  int restore_regno = get_regno (lra_reg_info[sregno].restore_rtx);
+		  if (restore_regno < 0)
+			restore_regno = prev_sregno;
 		  lra_assert (GET_MODE (SET_SRC (prev_set))
-  == GET_MODE (regno_reg_rtx[sregno]));
+  == GET_MODE (regno_reg_rtx[restore_regno]));
 		  /* Although we have a single set, the insn can
 			 contain more one sregno register occurrence
 			 as a source.  Change all occurrences.  */
 		  lra_substitute_pseudo_within_insn (curr_insn, sregno,
-			 SET_SRC (prev_set),
+			 regno_reg_rtx[restore_regno],
 			 false);
 		  /* As we are finishing with processing the insn
 			 here, check the destination too as it might
@@ -7745,5 +7750,7 @@ lra_undo_inheritance (void)
   EXECUTE_IF_SET_IN_BITMAP (_split_regs, 0, regno, bi)
 lra_reg_info[regno].restore_rtx = NULL_RTX;
   change_p = undo_optional_reloads () || change_p;
+  if 

ping: [PATCH v5] libstdc++: Remove UB from month and weekday additions and subtractions.

[Cassio Neri]

ping.

On Sat, 25 Nov 2023 at 13:52, Cassio Neri  wrote:

> The following invoke signed integer overflow (UB) [1]:
>
>   month   + months{MAX} // where MAX is the maximum value of months::rep
>   month   + months{MIN} // where MIN is the maximum value of months::rep
>   month   - months{MIN} // where MIN is the minimum value of months::rep
>   weekday + days  {MAX} // where MAX is the maximum value of days::rep
>   weekday - days  {MIN} // where MIN is the minimum value of days::rep
>
> For the additions to MAX, the crux of the problem is that, in libstdc++,
> months::rep and days::rep are int64_t. Other implementations use int32_t,
> cast
> operands to int64_t and perform arithmetic operations without risk of
> overflowing.
>
> For month + months{MIN}, the implementation follows the Standard's "returns
> clause" and evaluates:
>
>modulo(static_cast(unsigned{__x}) + (__y.count() - 1), 12);
>
> Overflow occurs when MIN - 1 is evaluated. Casting to a larger type could
> help
> but, unfortunately again, this is not possible for libstdc++.
>
> For the subtraction of MIN, the problem is that -MIN is not representable.
>
> It's fair to say that the intention is for these additions/subtractions to
> be performed in modulus (12 or 7) arithmetic so that no overflow is
> expected.
>
> To fix these UB, this patch implements:
>
>   template 
>   unsigned __add_modulo(unsigned __x, _T __y);
>
>   template 
>   unsigned __sub_modulo(unsigned __x, _T __y);
>
> which respectively, returns the remainder of Euclidean division of, __x +
> __y
> and __x - __y by __d without overflowing. These functions replace
>
>   constexpr unsigned __modulo(long long __n, unsigned __d);
>
> which also calculates the reminder of __n, where __n is the result of the
> addition or subtraction. Hence, these operations might invoke UB before
> __modulo
> is called and thus, __modulo can't do anything to remediate the issue.
>
> In addition to solve the UB issues, __add_modulo and __sub_modulo allow
> better
> codegen (shorter and branchless) on x86-64 and ARM [2].
>
> [1] https://godbolt.org/z/a9YfWdn57
> [2] https://godbolt.org/z/Gh36cr7E4
>
> libstdc++-v3/ChangeLog:
>
> * include/std/chrono: Fix + and - for months and weekdays.
> * testsuite/std/time/month/1.cc: Add constexpr tests against
> overflow.
> * testsuite/std/time/month/2.cc: New test for extreme values.
> * testsuite/std/time/weekday/1.cc: Add constexpr tests against
> overflow.
> * testsuite/std/time/weekday/2.cc: New test for extreme values.
> ---
> Good for trunk?
>
> Changes with respect to previous versions:
>   v5: Fix typos in commit message.
>   v4: Remove UB also from operator-.
>   v3: Fix screwed up email send with v2.
>   v2: Replace _T with _Tp and _U with _Up. Remove copyright+license from
> test.
>
>  libstdc++-v3/include/std/chrono  | 79 +---
>  libstdc++-v3/testsuite/std/time/month/1.cc   | 19 +
>  libstdc++-v3/testsuite/std/time/month/2.cc   | 32 
>  libstdc++-v3/testsuite/std/time/weekday/1.cc | 16 +++-
>  libstdc++-v3/testsuite/std/time/weekday/2.cc | 32 
>  5 files changed, 151 insertions(+), 27 deletions(-)
>  create mode 100644 libstdc++-v3/testsuite/std/time/month/2.cc
>  create mode 100644 libstdc++-v3/testsuite/std/time/weekday/2.cc
>
> diff --git a/libstdc++-v3/include/std/chrono
> b/libstdc++-v3/include/std/chrono
> index e4ba6eafceb..1b7cdb96e1c 100644
> --- a/libstdc++-v3/include/std/chrono
> +++ b/libstdc++-v3/include/std/chrono
> @@ -501,18 +501,47 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>
>  namespace __detail
>  {
> -  // Compute the remainder of the Euclidean division of __n divided
> by __d.
> -  // Euclidean division truncates toward negative infinity and always
> -  // produces a remainder in the range of [0,__d-1] (whereas standard
> -  // division truncates toward zero and yields a nonpositive remainder
> -  // for negative __n).
> +  // Helper to __add_modulo and __sub_modulo.
> +  template 
> +  constexpr auto
> +  __modulo_offset()
> +  {
> +   using _Up = make_unsigned_t<_Tp>;
> +   auto constexpr __a = _Up(-1) - _Up(255 + __d - 2);
> +   auto constexpr __b = _Up(__d * (__a / __d) - 1);
> +   // Notice: b <= a - 1 <= _Up(-1) - (255 + d - 1) and b % d = d - 1.
> +   return _Up(-1) - __b; // >= 255 + d - 1
> +  }
> +
> +  // Compute the remainder of the Euclidean division of __x + __y
> divided by
> +  // __d without overflowing.  Typically, __x <= 255 + d - 1 is sum of
> +  // weekday/month with a shift in [0, d - 1] and __y is a duration
> count.
> +  template 
> +  constexpr unsigned
> +  __add_modulo(unsigned __x, _Tp __y)
> +  {
> +   using _Up = make_unsigned_t<_Tp>;
> +   // For __y >= 0, _Up(__y) has the same mathematical value as __y
> and
> +   // this function simply returns (__x + _Up(__y)) % d.  Typically,
> this
> +   //