RE: [COMMITTED V3 1/4] RISC-V: Add non-vector types to dfa pipelines

2024-02-02 Thread Li, Pan2
Hi Edwin

> I believe the only problematic failures are the 5 vls calling convention 
> ones where only 24 ld\\s+a[0-1],\\s*[0-9]+\\(sp\\) are found.

Does this "only 24" comes from calling-convention-1.c? 

> This is what I'm getting locally (first instance of wrong match):
> v32qi_RET1_ARG8:
> .LFB109:

V32qi will pass the args by reference instead of GPR(s), thus It is expected. I 
think we need to diff the asm code before and after the patch for the whole 
test-file.
The RE "ld\\s+a[0-1],\\s*[0-9]+\\(sp\\)" would like to check vls mode values 
are returned by a[0-1].

Pan

-Original Message-
From: Edwin Lu  
Sent: Saturday, February 3, 2024 8:29 AM
To: Li, Pan2 ; juzhe.zh...@rivai.ai; gcc-patches 

Cc: Robin Dapp ; kito.cheng ; 
jeffreyalaw ; palmer ; vineetg 
; Patrick O'Neill 
Subject: Re: [COMMITTED V3 1/4] RISC-V: Add non-vector types to dfa pipelines

On 2/1/2024 8:28 PM, Li, Pan2 wrote:
> Hi Edwin,
> 
> Just rerun the newlib and there is no ICE but still 160 dump failures as 
> below.
> 
> Pan
> 

Hi Pan,

Thanks for confirming! Having dump failures is expected. There are 
around 7 more unique failures than I expected 
(https://github.com/patrick-rivos/gcc-postcommit-ci/issues/473 <-- 
postcommit found 46 while I expected 39 
https://inbox.sourceware.org/gcc-patches/12d205cd-3177-48ea-a54e-c2052fdde...@gmail.com/
 
https://github.com/ewlu/gcc-precommit-ci/issues/1178#issuecomment-1889782987) 


I included the 7 failed tests below and what was found instead.

I believe the only problematic failures are the 5 vls calling convention 
ones where only 24 ld\\s+a[0-1],\\s*[0-9]+\\(sp\\) are found.

FAIL: gcc.target/riscv/rvv/autovec/vls/calling-convention-1.c -O3 
-ftree-vectorize --param riscv-autovec-preference=scalable 
scan-assembler-times ld\\s+a[0-1],\\s*[0-9]+\\(sp\\) 35
FAIL: gcc.target/riscv/rvv/autovec/vls/calling-convention-2.c -O3 
-ftree-vectorize --param riscv-autovec-preference=scalable 
scan-assembler-times ld\\s+a[0-1],\\s*[0-9]+\\(sp\\) 33
FAIL: gcc.target/riscv/rvv/autovec/vls/calling-convention-3.c -O3 
-ftree-vectorize --param riscv-autovec-preference=scalable 
scan-assembler-times ld\\s+a[0-1],\\s*[0-9]+\\(sp\\) 31
FAIL: gcc.target/riscv/rvv/autovec/vls/calling-convention-4.c -O3 
-ftree-vectorize --param riscv-autovec-preference=scalable 
scan-assembler-times ld\\s+a[0-1],\\s*[0-9]+\\(sp\\) 29
FAIL: gcc.target/riscv/rvv/autovec/vls/calling-convention-7.c -O3 
-ftree-vectorize --param riscv-autovec-preference=scalable 
scan-assembler-times ld\\s+a[0-1],\\s*[0-9]+\\(sp\\) 29

This is what I'm getting locally (first instance of wrong match):
v32qi_RET1_ARG8:
.LFB109:
 .cfi_startproc
 li  t1,32
 vsetvli zero,t1,e8,mf8,ta,ma
 vle8.v  v1,0(a1)
 vle8.v  v4,0(a2)
 vle8.v  v3,0(a3)
 vle8.v  v2,0(a4)
 vadd.vv v1,v1,v4
 vadd.vv v1,v1,v3
 vle8.v  v3,0(a5)
 ld  a5,0(sp)  <-- used a5 instead of a1
 vadd.vv v1,v1,v2
 vle8.v  v2,0(a6)
 vadd.vv v1,v1,v3
 vle8.v  v3,0(a7)
 vadd.vv v1,v1,v2
 vle8.v  v2,0(a5)
 vadd.vv v1,v1,v3
 vadd.vv v1,v1,v2
 vse8.v  v1,0(a0)
 ret
 .cfi_endproc

If I understand correctly, this is wrong since we aren't returning 
anything (nothing gets stored in a[0-1])?

Edwin



Re: [patch, libgfortran] PR111022 ES0.0E0 format gave ES0.dE0 output with d too high.

2024-02-02 Thread Steve Kargl
Jerry,

The patch looks good to me, but please give Harald a chance
to comment.

-- 
steve

On Fri, Feb 02, 2024 at 07:17:55PM -0800, Jerry D wrote:
> On 1/30/24 12:36 PM, Harald Anlauf wrote:
> > Hi Jerry,
> > 
> > Am 30.01.24 um 19:15 schrieb Jerry D:
> > > The attached patch attempts to fix the handling of the EN0.0E0 and
> > > ES0.0E0 formatting by correctly calculating the number of digits needed
> > > for the exponents and building those exponents into the float string.
> > 
> > while your patch addresses ENw.dE0 and ESw.dE0 formatting,
> > it does not fix Ew.dE0, which can be seen with the following test:
> > 
> >    write(buffer,"(E0.3E0)") .6660_4
> >    print *, buffer
> >    write(buffer,"(E0.3)") .6660_4
> >    print *, buffer
> > 
> > I get even with your patch:
> > 
> >   0.666
> >   0.666
> > 
> > but would have expected:
> > 
> >   0.666E+0   ! F2018 & F2023, table 13.1
> >   0.666E+0   ! F2023, table 13.1
> > 
> 
> Tha attached file shows the complete revised patch and git log generated by
> using the 'git show' command. I only just discovered that one. (eye roll).
> 
> Regressions tested on x86-64.  OK for trunk?
> 
> Regards,
> 
> Jerry

> commit 95c878a97944f952aef226ff0224b2198abfbe0f
> Author: Jerry DeLisle 
> Date:   Fri Feb 2 18:12:33 2024 -0800
> 
> libgfortran: EN0.0E0 and ES0.0E0 format editing.
> 
> PR libgfortran/111022
> 
> F2018 and F2023 standards added zero width exponents. This required
> additional special handing in the process of building formatted
> floating point strings.
> 
> G formatting uses either F or E formatting as documented in
> write_float.def comments. This logic changes the format token from FMT_G
> to FMT_F or FMT_E. The new formatting requirements interfere with this
> process when a FMT_G float string is being built.  To avoid this, a new
> component called 'pushed' is added to the fnode structure to save this
> condition.  The 'pushed' condition is then used to bypass portions of
> the new ES,E,EN, and D formatting, falling through to the existing
> default formatting which is retained.
> 
> libgfortran/ChangeLog:
> 
> * io/format.c (get_fnode): Update initialization of fnode.
> (parse_format_list): Initialization.
> * io/format.h (struct fnode): Added the new 'pushed' component.
> * io/write.c (select_buffer): Whitespace.
> (write_real): Whitespace.
> (write_real_w0): Adjust logic for the d == 0 condition.
> * io/write_float.def (determine_precision): Whitespace.
> (build_float_string): Calculate width of ..E0 exponents and
> adjust logic accordingly.
> (build_infnan_string): Whitespace.
> (CALCULATE_EXP): Whitespace.
> (quadmath_snprintf): Whitespace.
> (determine_en_precision): Whitespace.
> 
> gcc/testsuite/ChangeLog:
> 
> * gfortran.dg/fmt_error_10.f: Show D+0 exponent.
> * gfortran.dg/pr96436_4.f90: Show E+0 exponent.
> * gfortran.dg/pr96436_5.f90: Show E+0 exponent.
> * gfortran.dg/pr111022.f90: New test.
> 
> diff --git a/gcc/testsuite/gfortran.dg/fmt_error_10.f 
> b/gcc/testsuite/gfortran.dg/fmt_error_10.f
> index 6e1a5f60bea..fc6620a60a6 100644
> --- a/gcc/testsuite/gfortran.dg/fmt_error_10.f
> +++ b/gcc/testsuite/gfortran.dg/fmt_error_10.f
> @@ -18,7 +18,7 @@
>  
>str = '(1pd0.15)'
>write (line,str,iostat=istat, iomsg=msg) 1.0d0
> -  if (line.ne."1.000") STOP 5
> +  if (line.ne."1.000D+0") STOP 5
>read (*,str,iostat=istat, iomsg=msg) x
>if (istat.ne.5006 .or. msg(1:10).ne."Zero width") STOP 6
>if (x.ne.555.25) STOP 7
> diff --git a/gcc/testsuite/gfortran.dg/pr111022.f90 
> b/gcc/testsuite/gfortran.dg/pr111022.f90
> new file mode 100644
> index 000..eef55ff5ce0
> --- /dev/null
> +++ b/gcc/testsuite/gfortran.dg/pr111022.f90
> @@ -0,0 +1,72 @@
> +! { dg-do run }
> +program pr111022
> +  character(20) :: buffer
> +  write(buffer,"(EN0.3E0)") .6660_4
> +  if (buffer.ne."666.000E-3") stop 1
> +  write(buffer,"(EN0.3E0)") 6.660_4
> +  if (buffer.ne."6.660E+0") stop 2
> +  write(buffer,"(EN0.3E0)") 66.60_4
> +  if (buffer.ne."66.600E+0") stop 3
> +  write(buffer,"(EN0.3E0)") 666.0_4
> +  if (buffer.ne."666.000E+0") stop 4
> +  write(buffer,"(EN0.3E0)") 6660.0_4
> +  if (buffer.ne."6.660E+3") stop 5
> +  write(buffer,"(EN0.3E0)") 66600.0_4
> +  if (buffer.ne."66.600E+3") stop 6
> +  
> +  write(buffer,"(EN0.0E0)") 666.0_4
> +  if (buffer.ne."666.E+0") stop 7
> +  write(buffer,"(EN0.0E1)") 666.0_4
> +  if (buffer.ne."666.E+0") stop 8
> +  write(buffer,"(EN0.0E2)") 666.0_4
> +  if (buffer.ne."666.E+00") stop 9
> +  write(buffer,"(EN0.0E3)") 666.0_4
> +  if (buffer.ne."666.E+000") stop 10
> +  write(buffer,"(EN0.0E4)") 666.0_4
> +  if (buffer.ne."666.E+") stop 11
> +  write(bu

Re: [patch, libgfortran] PR111022 ES0.0E0 format gave ES0.dE0 output with d too high.

2024-02-02 Thread Jerry D

On 1/30/24 12:36 PM, Harald Anlauf wrote:

Hi Jerry,

Am 30.01.24 um 19:15 schrieb Jerry D:

The attached patch attempts to fix the handling of the EN0.0E0 and
ES0.0E0 formatting by correctly calculating the number of digits needed
for the exponents and building those exponents into the float string.


while your patch addresses ENw.dE0 and ESw.dE0 formatting,
it does not fix Ew.dE0, which can be seen with the following test:

   write(buffer,"(E0.3E0)") .6660_4
   print *, buffer
   write(buffer,"(E0.3)") .6660_4
   print *, buffer

I get even with your patch:

  0.666
  0.666

but would have expected:

  0.666E+0   ! F2018 & F2023, table 13.1
  0.666E+0   ! F2023, table 13.1



Tha attached file shows the complete revised patch and git log generated 
by using the 'git show' command. I only just discovered that one. (eye 
roll).


Regressions tested on x86-64.  OK for trunk?

Regards,

Jerry
commit 95c878a97944f952aef226ff0224b2198abfbe0f
Author: Jerry DeLisle 
Date:   Fri Feb 2 18:12:33 2024 -0800

libgfortran: EN0.0E0 and ES0.0E0 format editing.

PR libgfortran/111022

F2018 and F2023 standards added zero width exponents. This required
additional special handing in the process of building formatted
floating point strings.

G formatting uses either F or E formatting as documented in
write_float.def comments. This logic changes the format token from FMT_G
to FMT_F or FMT_E. The new formatting requirements interfere with this
process when a FMT_G float string is being built.  To avoid this, a new
component called 'pushed' is added to the fnode structure to save this
condition.  The 'pushed' condition is then used to bypass portions of
the new ES,E,EN, and D formatting, falling through to the existing
default formatting which is retained.

libgfortran/ChangeLog:

* io/format.c (get_fnode): Update initialization of fnode.
(parse_format_list): Initialization.
* io/format.h (struct fnode): Added the new 'pushed' component.
* io/write.c (select_buffer): Whitespace.
(write_real): Whitespace.
(write_real_w0): Adjust logic for the d == 0 condition.
* io/write_float.def (determine_precision): Whitespace.
(build_float_string): Calculate width of ..E0 exponents and
adjust logic accordingly.
(build_infnan_string): Whitespace.
(CALCULATE_EXP): Whitespace.
(quadmath_snprintf): Whitespace.
(determine_en_precision): Whitespace.

gcc/testsuite/ChangeLog:

* gfortran.dg/fmt_error_10.f: Show D+0 exponent.
* gfortran.dg/pr96436_4.f90: Show E+0 exponent.
* gfortran.dg/pr96436_5.f90: Show E+0 exponent.
* gfortran.dg/pr111022.f90: New test.

diff --git a/gcc/testsuite/gfortran.dg/fmt_error_10.f b/gcc/testsuite/gfortran.dg/fmt_error_10.f
index 6e1a5f60bea..fc6620a60a6 100644
--- a/gcc/testsuite/gfortran.dg/fmt_error_10.f
+++ b/gcc/testsuite/gfortran.dg/fmt_error_10.f
@@ -18,7 +18,7 @@
 
   str = '(1pd0.15)'
   write (line,str,iostat=istat, iomsg=msg) 1.0d0
-  if (line.ne."1.000") STOP 5
+  if (line.ne."1.000D+0") STOP 5
   read (*,str,iostat=istat, iomsg=msg) x
   if (istat.ne.5006 .or. msg(1:10).ne."Zero width") STOP 6
   if (x.ne.555.25) STOP 7
diff --git a/gcc/testsuite/gfortran.dg/pr111022.f90 b/gcc/testsuite/gfortran.dg/pr111022.f90
new file mode 100644
index 000..eef55ff5ce0
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr111022.f90
@@ -0,0 +1,72 @@
+! { dg-do run }
+program pr111022
+  character(20) :: buffer
+  write(buffer,"(EN0.3E0)") .6660_4
+  if (buffer.ne."666.000E-3") stop 1
+  write(buffer,"(EN0.3E0)") 6.660_4
+  if (buffer.ne."6.660E+0") stop 2
+  write(buffer,"(EN0.3E0)") 66.60_4
+  if (buffer.ne."66.600E+0") stop 3
+  write(buffer,"(EN0.3E0)") 666.0_4
+  if (buffer.ne."666.000E+0") stop 4
+  write(buffer,"(EN0.3E0)") 6660.0_4
+  if (buffer.ne."6.660E+3") stop 5
+  write(buffer,"(EN0.3E0)") 66600.0_4
+  if (buffer.ne."66.600E+3") stop 6
+  
+  write(buffer,"(EN0.0E0)") 666.0_4
+  if (buffer.ne."666.E+0") stop 7
+  write(buffer,"(EN0.0E1)") 666.0_4
+  if (buffer.ne."666.E+0") stop 8
+  write(buffer,"(EN0.0E2)") 666.0_4
+  if (buffer.ne."666.E+00") stop 9
+  write(buffer,"(EN0.0E3)") 666.0_4
+  if (buffer.ne."666.E+000") stop 10
+  write(buffer,"(EN0.0E4)") 666.0_4
+  if (buffer.ne."666.E+") stop 11
+  write(buffer,"(EN0.0E5)") 666.0_4
+  if (buffer.ne."666.E+0") stop 12
+  write(buffer,"(EN0.0E6)") 666.0_4
+  if (buffer.ne."666.E+00") stop 13
+  
+  write(buffer,"(ES0.3E0)") .6660_4
+  if (buffer.ne."6.660E-1") stop 14
+  write(buffer,"(ES0.3E0)") 6.660_4
+  if (buffer.ne."6.660E+0") stop 15
+  write(buffer,"(ES0.3E0)") 66.60_4
+  if (buffer.ne."6.660E+1") stop 16
+  write(buffer,"(ES0.3E0)") 666.0_4
+  if (buffer.ne."6.660E+2") stop 17
+  write(b

Re: [COMMITTED V3 1/4] RISC-V: Add non-vector types to dfa pipelines

2024-02-02 Thread Edwin Lu

On 2/1/2024 8:28 PM, Li, Pan2 wrote:

Hi Edwin,

Just rerun the newlib and there is no ICE but still 160 dump failures as below.

Pan



Hi Pan,

Thanks for confirming! Having dump failures is expected. There are 
around 7 more unique failures than I expected 
(https://github.com/patrick-rivos/gcc-postcommit-ci/issues/473 <-- 
postcommit found 46 while I expected 39 
https://inbox.sourceware.org/gcc-patches/12d205cd-3177-48ea-a54e-c2052fdde...@gmail.com/ 
https://github.com/ewlu/gcc-precommit-ci/issues/1178#issuecomment-1889782987) 



I included the 7 failed tests below and what was found instead.

I believe the only problematic failures are the 5 vls calling convention 
ones where only 24 ld\\s+a[0-1],\\s*[0-9]+\\(sp\\) are found.


FAIL: gcc.target/riscv/rvv/autovec/vls/calling-convention-1.c -O3 
-ftree-vectorize --param riscv-autovec-preference=scalable 
scan-assembler-times ld\\s+a[0-1],\\s*[0-9]+\\(sp\\) 35
FAIL: gcc.target/riscv/rvv/autovec/vls/calling-convention-2.c -O3 
-ftree-vectorize --param riscv-autovec-preference=scalable 
scan-assembler-times ld\\s+a[0-1],\\s*[0-9]+\\(sp\\) 33
FAIL: gcc.target/riscv/rvv/autovec/vls/calling-convention-3.c -O3 
-ftree-vectorize --param riscv-autovec-preference=scalable 
scan-assembler-times ld\\s+a[0-1],\\s*[0-9]+\\(sp\\) 31
FAIL: gcc.target/riscv/rvv/autovec/vls/calling-convention-4.c -O3 
-ftree-vectorize --param riscv-autovec-preference=scalable 
scan-assembler-times ld\\s+a[0-1],\\s*[0-9]+\\(sp\\) 29
FAIL: gcc.target/riscv/rvv/autovec/vls/calling-convention-7.c -O3 
-ftree-vectorize --param riscv-autovec-preference=scalable 
scan-assembler-times ld\\s+a[0-1],\\s*[0-9]+\\(sp\\) 29


This is what I'm getting locally (first instance of wrong match):
v32qi_RET1_ARG8:
.LFB109:
.cfi_startproc
li  t1,32
vsetvli zero,t1,e8,mf8,ta,ma
vle8.v  v1,0(a1)
vle8.v  v4,0(a2)
vle8.v  v3,0(a3)
vle8.v  v2,0(a4)
vadd.vv v1,v1,v4
vadd.vv v1,v1,v3
vle8.v  v3,0(a5)
ld  a5,0(sp)  <-- used a5 instead of a1
vadd.vv v1,v1,v2
vle8.v  v2,0(a6)
vadd.vv v1,v1,v3
vle8.v  v3,0(a7)
vadd.vv v1,v1,v2
vle8.v  v2,0(a5)
vadd.vv v1,v1,v3
vadd.vv v1,v1,v2
vse8.v  v1,0(a0)
ret
.cfi_endproc

If I understand correctly, this is wrong since we aren't returning 
anything (nothing gets stored in a[0-1])?


Edwin



Re: [PATCH] Change gcc/ira-conflicts.cc build_conflict_bit_table to use size_t/%zu

2024-02-02 Thread Jakub Jelinek
On Fri, Feb 02, 2024 at 11:43:21PM +, Jonathan Yong wrote:
> On 2/1/24 15:33, Jonathan Yong wrote:
> > On 2/1/24 15:25, Jakub Jelinek wrote:
> > > On Thu, Feb 01, 2024 at 03:55:51PM +0100, Jakub Jelinek wrote:
> > > > No, besides the formatting being incorrect both in ChangeLog and in the
> > > > patch, this pessimizes ILP32 hosts unnecessarily.
> > > 
> > > So like this instead?
> > > 
> > > 2024-02-01  Jakub Jelinek  
> > > 
> > > * hwint.h (GCC_PRISZ, fmt_size_t, HOST_SIZE_T_PRINT_DEC,
> > > HOST_SIZE_T_PRINT_UNSIGNED, HOST_SIZE_T_PRINT_HEX,
> > > HOST_SIZE_T_PRINT_HEX_PURE): Define.
> > > * ira-conflicts.cc (build_conflict_bit_table): Use it.  Formatting
> > > fixes.
> > > 
> > 
> > Looks good for ILP32/LLP64.
> 
> Are you planning to push yet?

It needs to be reviewed first.

Passed successfully bootstrap/regtest on x86_64-linux and i686-linux.

Note, I think incrementally we should search for similar issues,
grep -C3 '%l[duxXi]' *.cc */*.cc | grep 'long)' | grep -v long.long | wc -l
101
is an upper bound on what should be looked at, I see at least a few dozens
from those (e.g. when the argument uses sizeof, or is say hash table
size () or elements () etc.).

Also, wonder if the pretty-printer.cc should get 'z' and 't' modifiers
added, for those we clearly can use 'z' or 't' when we implement it
ourselves.  But at least that part is stage1 material I'd say.
In translated messages we certainly can't use macros like
HOST_SIZE_T_PRINT_*, because it is then untranslatable.

Jakub



[PATCH] coreutils-sum-pr108666.c: fix spurious LLP64 warnings

2024-02-02 Thread Jonathan Yong

Attached patch OK? Fixes the following warnings:
coreutils-sum-pr108666.c:17:1: warning: conflicting types for built-in function 
‘memcpy’; expected ‘void *(void *, const void *, long long unsigned int)’ 
[-Wbuiltin-declaration-mismatch]
   17 | memcpy(void* __restrict __dest, const void* __restrict __src, size_t 
__n)
  | ^~

coreutils-sum-pr108666.c:25:1: warning: conflicting types for built-in function 
‘malloc’; expected ‘void *(long long unsigned int)’ 
[-Wbuiltin-declaration-mismatch]
   25 | malloc(size_t __size) __attribute__((__nothrow__, __leaf__))
  | ^~

Copied for review convenience:
diff --git a/gcc/testsuite/c-c++-common/analyzer/coreutils-sum-pr108666.c 
b/gcc/testsuite/c-c++-common/analyzer/coreutils-sum-pr108666.c
index 5684d1b02d4..dadd27eaf41 100644
--- a/gcc/testsuite/c-c++-common/analyzer/coreutils-sum-pr108666.c
+++ b/gcc/testsuite/c-c++-common/analyzer/coreutils-sum-pr108666.c
@@ -1,6 +1,6 @@
 /* Reduced from coreutils's sum.c: bsd_sum_stream */
 
-typedef long unsigned int size_t;

+typedef __SIZE_TYPE__ size_t;
 typedef unsigned char __uint8_t;
 typedef unsigned long int __uintmax_t;
 typedef struct _IO_FILE FILE;From 54731e86e4bdce03ef4a722860ea8cee931ec127 Mon Sep 17 00:00:00 2001
From: Jonathan Yong <10wa...@gmail.com>
Date: Fri, 2 Feb 2024 23:47:47 +
Subject: [PATCH] coreutils-sum-pr108666.c: fix spurious LLP64 warnings
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Fixes the following warnings on x86_64-w64-mingw32:
coreutils-sum-pr108666.c:17:1: warning: conflicting types for built-in function ‘memcpy’; expected ‘void *(void *, const void *, long long unsigned int)’ [-Wbuiltin-declaration-mismatch]
   17 | memcpy(void* __restrict __dest, const void* __restrict __src, size_t __n)
  | ^~

coreutils-sum-pr108666.c:25:1: warning: conflicting types for built-in function ‘malloc’; expected ‘void *(long long unsigned int)’ [-Wbuiltin-declaration-mismatch]
   25 | malloc(size_t __size) __attribute__((__nothrow__, __leaf__))
  | ^~

gcc/testsuite:

	* coreutils-sum-pr108666.c: Use __SIZE_TYPE__ instead of
	long unsigned int for size_t definition.

Signed-off-by: Jonathan Yong <10wa...@gmail.com>
---
 gcc/testsuite/c-c++-common/analyzer/coreutils-sum-pr108666.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/c-c++-common/analyzer/coreutils-sum-pr108666.c b/gcc/testsuite/c-c++-common/analyzer/coreutils-sum-pr108666.c
index 5684d1b02d4..dadd27eaf41 100644
--- a/gcc/testsuite/c-c++-common/analyzer/coreutils-sum-pr108666.c
+++ b/gcc/testsuite/c-c++-common/analyzer/coreutils-sum-pr108666.c
@@ -1,6 +1,6 @@
 /* Reduced from coreutils's sum.c: bsd_sum_stream */
 
-typedef long unsigned int size_t;
+typedef __SIZE_TYPE__ size_t;
 typedef unsigned char __uint8_t;
 typedef unsigned long int __uintmax_t;
 typedef struct _IO_FILE FILE;
-- 
2.43.0



Re: [PATCH] Change gcc/ira-conflicts.cc build_conflict_bit_table to use size_t/%zu

2024-02-02 Thread Jonathan Yong

On 2/1/24 15:33, Jonathan Yong wrote:

On 2/1/24 15:25, Jakub Jelinek wrote:

On Thu, Feb 01, 2024 at 03:55:51PM +0100, Jakub Jelinek wrote:

No, besides the formatting being incorrect both in ChangeLog and in the
patch, this pessimizes ILP32 hosts unnecessarily.


So like this instead?

2024-02-01  Jakub Jelinek  

* hwint.h (GCC_PRISZ, fmt_size_t, HOST_SIZE_T_PRINT_DEC,
HOST_SIZE_T_PRINT_UNSIGNED, HOST_SIZE_T_PRINT_HEX,
HOST_SIZE_T_PRINT_HEX_PURE): Define.
* ira-conflicts.cc (build_conflict_bit_table): Use it.  Formatting
fixes.



Looks good for ILP32/LLP64.



Are you planning to push yet?


libgo patch committed: Better error messages for unsupported target

2024-02-02 Thread Ian Lance Taylor
This libgo patch generates better error messages then the Go GOARCH
and GOOS values can't be determined from the target.  This indicates
that the target is not supported.  This is for GCC PR 113530.
Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.  Committed
to mainline.

Ian
cfc6d9ae8143cf0e903384bc63e8d659ca1c9fe7
diff --git a/gcc/go/gofrontend/MERGE b/gcc/go/gofrontend/MERGE
index 18281c6cd1e..429904a2b8f 100644
--- a/gcc/go/gofrontend/MERGE
+++ b/gcc/go/gofrontend/MERGE
@@ -1,4 +1,4 @@
-7ab229670f7dad1d79f33929f9a4f8e6e4a71526
+8c056e335cecec67d1d223a329b7ba4dac778a65
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
diff --git a/libgo/Makefile.am b/libgo/Makefile.am
index c95dc2106cd..3eccadbac67 100644
--- a/libgo/Makefile.am
+++ b/libgo/Makefile.am
@@ -497,6 +497,10 @@ s-version: Makefile
 zgoarch.go: s-zgoarch; @true
 s-zgoarch: Makefile goarch.sh
rm -f zgoarch.go.tmp
+   if ! $(SHELL) $(srcdir)/goarch.sh $(GOARCH) family >/dev/null 
2>/dev/null;  then \
+ $(SHELL) $(srcdir)/goarch.sh $(GOARCH) family; \
+ exit 1; \
+   fi
echo "package goarch" > zgoarch.go.tmp
echo >> zgoarch.go.tmp
echo 'const GOARCH = "'$(GOARCH)'"' >> zgoarch.go.tmp
diff --git a/libgo/configure.ac b/libgo/configure.ac
index e8d66f8415d..22158ac7f5d 100644
--- a/libgo/configure.ac
+++ b/libgo/configure.ac
@@ -209,6 +209,10 @@ AM_CONDITIONAL(LIBGO_IS_BSD, test $is_darwin = yes -o 
$is_dragonfly = yes -o $is
 AC_SUBST(GOOS)
 AC_SUBST(ALLGOOS)
 
+if test "${GOOS}" = "unknown"; then
+   AC_MSG_ERROR("could not determine GOOS from ${host}")
+fi
+
 dnl Test whether we need to use DejaGNU or whether we can use the
 dnl simpler gotest approach.  We can only use gotest for a native
 dnl build.
@@ -376,6 +380,10 @@ AC_SUBST(GOARCH)
 AC_SUBST(ALLGOARCH)
 AC_SUBST(ALLGOARCHFAMILY)
 
+if test "${GOARCH}" = "unknown"; then
+   AC_MSG_ERROR("could not determine GOARCH from ${host}")
+fi
+
 AM_CONDITIONAL(LIBGO_IS_X86, test "$GOARCH" = "386" -o "$GOARCH" = "amd64" -o 
"$GOARCH" = "amd64p32")
 
 FUNCTION_DESCRIPTORS=false


Go patch committed: Export the type "any" as a builtin

2024-02-02 Thread Ian Lance Taylor
This patch to the Go frontend exports the type "any" as a builtin.
Otherwise we can't tell the difference between builtin type "any" and
a locally defined type "any".

This will require updates to the gccgo export data parsers in the main
Go repo and the x/tools repo.  These updates are https://go.dev/cl/537195
and https://go.dev/cl/537215.

Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.  Committed
to mainline.

Ian
e52d31804a910642c9817bdd400c290a593c98ef
diff --git a/gcc/go/gofrontend/MERGE b/gcc/go/gofrontend/MERGE
index c2a6032ae80..18281c6cd1e 100644
--- a/gcc/go/gofrontend/MERGE
+++ b/gcc/go/gofrontend/MERGE
@@ -1,4 +1,4 @@
-ddf3758e4a45ca2816fb68f3e4224501a3c4c438
+7ab229670f7dad1d79f33929f9a4f8e6e4a71526
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
diff --git a/gcc/go/gofrontend/export.cc b/gcc/go/gofrontend/export.cc
index 7373deee310..40f6d5d4b2f 100644
--- a/gcc/go/gofrontend/export.cc
+++ b/gcc/go/gofrontend/export.cc
@@ -1661,6 +1661,7 @@ Export::register_builtin_types(Gogo* gogo)
   this->register_builtin_type(gogo, "error", BUILTIN_ERROR);
   this->register_builtin_type(gogo, "byte", BUILTIN_BYTE);
   this->register_builtin_type(gogo, "rune", BUILTIN_RUNE);
+  this->register_builtin_type(gogo, "any", BUILTIN_ANY);
 }
 
 // Register one builtin type in the export table.
diff --git a/gcc/go/gofrontend/export.h b/gcc/go/gofrontend/export.h
index 1f613434cab..be117ece2ce 100644
--- a/gcc/go/gofrontend/export.h
+++ b/gcc/go/gofrontend/export.h
@@ -51,8 +51,9 @@ enum Builtin_code
   BUILTIN_ERROR = -19,
   BUILTIN_BYTE = -20,
   BUILTIN_RUNE = -21,
+  BUILTIN_ANY = -22,
 
-  SMALLEST_BUILTIN_CODE = -21
+  SMALLEST_BUILTIN_CODE = -22
 };
 
 // Export data version number. New export data is written with the
diff --git a/gcc/go/gofrontend/import.cc b/gcc/go/gofrontend/import.cc
index 21691fa5ff4..3cc8a720ee4 100644
--- a/gcc/go/gofrontend/import.cc
+++ b/gcc/go/gofrontend/import.cc
@@ -1408,6 +1408,7 @@ Import::register_builtin_types(Gogo* gogo)
   this->register_builtin_type(gogo, "error", BUILTIN_ERROR);
   this->register_builtin_type(gogo, "byte", BUILTIN_BYTE);
   this->register_builtin_type(gogo, "rune", BUILTIN_RUNE);
+  this->register_builtin_type(gogo, "any", BUILTIN_ANY);
 }
 
 // Register a single builtin type.
diff --git a/libgo/go/go/internal/gccgoimporter/parser.go 
b/libgo/go/go/internal/gccgoimporter/parser.go
index 48335fa6d8f..2161df7f368 100644
--- a/libgo/go/go/internal/gccgoimporter/parser.go
+++ b/libgo/go/go/internal/gccgoimporter/parser.go
@@ -187,7 +187,6 @@ func (p *parser) parseQualifiedNameStr(unquotedName string) 
(pkgpath, name strin
 // getPkg returns the package for a given path. If the package is
 // not found but we have a package name, create the package and
 // add it to the p.imports map.
-//
 func (p *parser) getPkg(pkgpath, name string) *types.Package {
// package unsafe is not in the imports map - handle explicitly
if pkgpath == "unsafe" {
@@ -904,6 +903,7 @@ const (
gccgoBuiltinERROR  = 19
gccgoBuiltinBYTE   = 20
gccgoBuiltinRUNE   = 21
+   gccgoBuiltinANY= 22
 )
 
 func lookupBuiltinType(typ int) types.Type {
@@ -928,13 +928,13 @@ func lookupBuiltinType(typ int) types.Type {
gccgoBuiltinERROR:  types.Universe.Lookup("error").Type(),
gccgoBuiltinBYTE:   types.Universe.Lookup("byte").Type(),
gccgoBuiltinRUNE:   types.Universe.Lookup("rune").Type(),
+   gccgoBuiltinANY:types.Universe.Lookup("any").Type(),
}[typ]
 }
 
 // Type = "<" "type" ( "-" int | int [ TypeSpec ] ) ">" .
 //
 // parseType updates the type map to t for all type numbers n.
-//
 func (p *parser) parseType(pkg *types.Package, n ...any) types.Type {
p.expect('<')
t, _ := p.parseTypeAfterAngle(pkg, n...)
@@ -1117,9 +1117,10 @@ func (p *parser) maybeCreatePackage() {
 }
 
 // InitDataDirective = ( "v1" | "v2" | "v3" ) ";" |
-// "priority" int ";" |
-// "init" { PackageInit } ";" |
-// "checksum" unquotedString ";" .
+//
+// "priority" int ";" |
+// "init" { PackageInit } ";" |
+// "checksum" unquotedString ";" .
 func (p *parser) parseInitDataDirective() {
if p.tok != scanner.Ident {
// unexpected token kind; panic
@@ -1170,15 +1171,16 @@ func (p *parser) parseInitDataDirective() {
 }
 
 // Directive = InitDataDirective |
-// "package" unquotedString [ unquotedString ] [ unquotedString ] 
";" |
-// "pkgpath" unquotedString ";" |
-// "prefix" unquotedString ";" |
-// "import" unquotedString unquotedString string ";" |
-// "indirectimport" unquotedString unquotedstring ";" |
-// "func" Func ";" |
-// "type" Type ";" |
-// "var" Var ";" |
-// "const" Const

Re: [PATCH] combine: Don't optimize SIGN_EXTEND of MEM on WORD_REGISTER_OPERATIONS targets [PR113010]

2024-02-02 Thread Greg McGary

On 2/1/24 10:24 PM, Jeff Law wrote:


On 2/1/24 18:24, Greg McGary wrote:

However, for a machine where (WORD_REGISTER_OPERATIONS && 
load_extend_op (inner_mode) == SIGN_EXTEND), the high part of a PSoM 
is  only known at runtime as 0s or 1s. That's the downstream bug. The 
fix for such machines is either (A) forbid static evaluation of the 
high part of a PSoM, or (B) forbid transforming (SIGN_EXTEND (MEM 
...) ) into a PSoM. My patch does B. Perhaps you prefer A? The 
trouble with A is that in the zero-extend case, it is valid to 
statically evaluate as 0. It is only the sign-extend case that isn't 
known until runtime. By the time we have a PSoM, its upstream 
ancestor as sign- or zero-extend is already lost.


Does that give you the understanding you desire, or are there deeper 
mysteries to probe?
It's a good start and I can see what you're trying to do -- and it may 
in fact be correct -- the quick discussion with Palmer Tuesday and 
your follow-up have helped a lot).


But just to be sure, what's the incoming rtl at function entry? just 
"debug_rtx (x)" should be sufficient.


input: (sign_extend:DI (mem/c:SI (symbol_ref:DI ("minus_1") [flags 0x86] 
) [1 minus_1+0 S4 A32]))


result: (subreg:DI (mem/c:SI (symbol_ref:DI ("minus_1") [flags 0x86] 
) [1 minus_1+0 S4 A32]) 0)


Later, the high part of the PSoM statically evaluates to 0, the code to 
load and test is elided, and the incorrect alternative is emitted 
unconditionally.


G



[PATCH v5] x86-64: Find a scratch register for large model profiling

2024-02-02 Thread H.J. Lu
Changes in v5:

1. Add pr113689-3.c.
2. Use %r10 if ix86_profile_before_prologue () return true.
3. Try a callee-saved register which has been saved on stack in the
prologue.

Changes in v4:

1. Remove pr113689-3.c.
2. Use df_get_live_out.

Changes in v3:

1. Remove r10_ok.

Changes in v2:

1. Add int_parameter_registers to machine_function to track integer
registers used for parameter passing.
2. Update x86_64_select_profile_regnum to try %r10 first and use an
caller-saved register, which isn't used for parameter passing.

---
2 scratch registers, %r10 and %r11, are available at function entry for
large model profiling.  But %r10 may be used by stack realignment and we
can't use %r10 in this case.  Add x86_64_select_profile_regnum to find
a caller-saved register which isn't live or a callee-saved register
which has been saved on stack in the prologue at entry for large model
profiling and sorry if we can't find one.

gcc/

PR target/113689
* config/i386/i386.cc (set_saved_int_registers_bit): New.
(test_saved_int_registers_bit): Likewise.
(ix86_emit_save_regs): Call set_saved_int_registers_bit on
saved register.
(ix86_emit_save_regs_using_mov): Likewise.
(x86_64_select_profile_regnum): New.
(x86_function_profiler): Call x86_64_select_profile_regnum to
get a scratch register for large model profiling.
* config/i386/i386.h (machine_function): Add
saved_int_registers.

gcc/testsuite/

PR target/113689
* gcc.target/i386/pr113689-1.c: New file.
* gcc.target/i386/pr113689-2.c: Likewise.
* gcc.target/i386/pr113689-3.c: Likewise.
---
 gcc/config/i386/i386.cc| 119 ++---
 gcc/config/i386/i386.h |   5 +
 gcc/testsuite/gcc.target/i386/pr113689-1.c |  49 +
 gcc/testsuite/gcc.target/i386/pr113689-2.c |  41 +++
 gcc/testsuite/gcc.target/i386/pr113689-3.c |  48 +
 5 files changed, 247 insertions(+), 15 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/i386/pr113689-1.c
 create mode 100644 gcc/testsuite/gcc.target/i386/pr113689-2.c
 create mode 100644 gcc/testsuite/gcc.target/i386/pr113689-3.c

diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc
index b3e7c74846e..1c7aaa4535e 100644
--- a/gcc/config/i386/i386.cc
+++ b/gcc/config/i386/i386.cc
@@ -7387,6 +7387,32 @@ choose_baseaddr (HOST_WIDE_INT cfa_offset, unsigned int 
*align,
   return plus_constant (Pmode, base_reg, base_offset);
 }
 
+/* Set the integer register REGNO bit in saved_int_registers.  */
+
+static void
+set_saved_int_registers_bit (int regno)
+{
+  if (LEGACY_INT_REGNO_P (regno))
+cfun->machine->saved_int_registers |= 1 << regno;
+  else
+cfun->machine->saved_int_registers
+  |= 1 << (regno - FIRST_REX_INT_REG + 8);
+}
+
+/* Return true if the integer register REGNO bit in saved_int_registers
+   is set.  */
+
+static bool
+test_saved_int_registers_bit (int regno)
+{
+  if (LEGACY_INT_REGNO_P (regno))
+return (cfun->machine->saved_int_registers
+   & (1 << regno)) != 0;
+  else
+return (cfun->machine->saved_int_registers
+   & (1 << (regno - FIRST_REX_INT_REG + 8))) != 0;
+}
+
 /* Emit code to save registers in the prologue.  */
 
 static void
@@ -7403,6 +7429,7 @@ ix86_emit_save_regs (void)
insn = emit_insn (gen_push (gen_rtx_REG (word_mode, regno),
TARGET_APX_PPX));
RTX_FRAME_RELATED_P (insn) = 1;
+   set_saved_int_registers_bit (regno);
  }
 }
   else
@@ -7415,6 +7442,7 @@ ix86_emit_save_regs (void)
   for (regno = FIRST_PSEUDO_REGISTER - 1; regno >= 0; regno--)
if (GENERAL_REGNO_P (regno) && ix86_save_reg (regno, true, true))
  {
+   set_saved_int_registers_bit (regno);
if (aligned)
  {
regno_list[loaded_regnum++] = regno;
@@ -7567,6 +7595,7 @@ ix86_emit_save_regs_using_mov (HOST_WIDE_INT cfa_offset)
   {
 ix86_emit_save_reg_using_mov (word_mode, regno, cfa_offset);
cfa_offset -= UNITS_PER_WORD;
+   set_saved_int_registers_bit (regno);
   }
 }
 
@@ -22749,6 +22778,48 @@ current_fentry_section (const char **name)
   return true;
 }
 
+/* Return a caller-saved register which isn't live or a callee-saved
+   register which has been saved on stack in the prologue at entry for
+   profile.  */
+
+static int
+x86_64_select_profile_regnum (bool r11_ok ATTRIBUTE_UNUSED)
+{
+  /* Use %r10 if the profiler is emitted before the prologue or it isn't
+ used by DRAP.  */
+  if (ix86_profile_before_prologue ()
+  || !crtl->drap_reg
+  || REGNO (crtl->drap_reg) != R10_REG)
+return R10_REG;
+
+  /* The profiler is emitted after the prologue.  If there is a
+ caller-saved register which isn't live or a callee-saved
+ register saved on stack in the prologue, use it.  */
+
+  bitmap reg_live = df_get_live_out (ENTRY_BLOCK_PTR_

[PATCH] aarch64: Fix undefined code in vect_ctz_1.c

2024-02-02 Thread Andrew Pinski
The testcase gcc.target/aarch64/vect_ctz_1.c fails execution when running
with -march=armv9-a due to the testcase calls __builtin_ctz with a value of 0.
The testcase should not depend on undefined behavior of __builtin_ctz. So this
changes it to use the g form with the 2nd argument of 32. Now the execution part
of the testcase work. It still has a scan-assembler failure which should be 
fixed
seperately.

OK? Tested on aarch64-linux-gnu.

gcc/testsuite/ChangeLog:

* gcc.target/aarch64/vect_ctz_1.c (TEST): Use g form of the builtin and 
pass 32
as the value expected at 0.

Signed-off-by: Andrew Pinski 
---
 gcc/testsuite/gcc.target/aarch64/vect_ctz_1.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.target/aarch64/vect_ctz_1.c 
b/gcc/testsuite/gcc.target/aarch64/vect_ctz_1.c
index c4eaf5b3a91..5fcf1e31ab2 100644
--- a/gcc/testsuite/gcc.target/aarch64/vect_ctz_1.c
+++ b/gcc/testsuite/gcc.target/aarch64/vect_ctz_1.c
@@ -9,7 +9,7 @@ count_tz_##name (unsigned *__restrict a, int *__restrict b) \
 { \
   int i; \
   for (i = 0; i < count; i++) \
-b[i] = __builtin_##subname (a[i]); \
+b[i] = __builtin_##subname##g (a[i], 32); \
 }
 
 #define CHECK(name, count, input, output) \
-- 
2.43.0



Re: [PATCH 1/2] c++: requires-exprs and partial constraint subst [PR112769]

2024-02-02 Thread Jason Merrill

On 2/2/24 15:57, Patrick Palka wrote:

On Fri, 2 Feb 2024, Patrick Palka wrote:


On Fri, 2 Feb 2024, Jason Merrill wrote:


On 2/2/24 14:41, Patrick Palka wrote:

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

-- >8 --

In r11-3261-gb28b621ac67bee we made tsubst_requires_expr never partially
substitute into a requires-expression so as to avoid checking its
requirements out of order during e.g. generic lambda regeneration.

Unfortunately we still do need to partially substitute into a
requires-expression in rare cases, in particular when it's used in
associated constraints that we are directly substituting for sake of
declaration matching or dguide constraint rewriting.  We can identify
this situation by checking processing_constraint_expression_p, so this
patch uses this predicate to control whether we defer substitution or
partially substitute.  The entering_scope=true change in tsubst_baselink
is needed to avoid ICEing from tsubst_baselink during name lookup when
rewriting std::ranges::ref_view's dguide constraints.


Actually, I don't think we want to enter the scope when rewriting constraints.
Would tsubst_scope work instead?


Oops yes, because of the maybe_dependent_member_ref stuff, the handling
for which doesn't trigger here for some reason.  Ah, I think it's
because the tf_dguide flag gets dropped during tsubst_requires_expr
since it uses tf_none rather than complain & ~tf_warning_or_error
which would preserve special tsubst flags such as tf_dguide.  I'll fix...


Like so?  Lightly tested so far, bootstrap+regtest in progress.


OK, thanks.


-- >8 --

Subject: [PATCH v2] c++: requires-exprs and partial constraint subst [PR112769]

In r11-3261-gb28b621ac67bee we made tsubst_requires_expr never partially
substitute into a requires-expression so as to avoid checking its
requirements out of order during e.g. generic lambda regeneration.

Unfortunately we still do need to partially substitute into a
requires-expression in rare cases, in particular when it's used in
associated constraints that we are directly substituting for sake of
declaration matching or dguide constraint rewriting.  We can identify
this situation by checking processing_constraint_expression_p, so this
patch uses this predicate to control whether we defer substitution or
partially substitute.

In turn, tsubst_requires_expr now needs to propagate semantic tsubst flags
rather than just using tf_none, in particular for dguide constraint rewriting
which sets tf_dguide.

PR c++/112769
PR c++/110006

gcc/cp/ChangeLog:

* constraint.cc (subst_info::quiet): Accomodate non-diagnostic
tsubst flags.
(tsubst_valid_expression_requirement): Likewise.
(tsubst_simple_requirement): Likewise.  Return a substituted _REQ
node when processing_template_decl.
(tsubst_type_requirement_1): Accomodate non-diagnostic tsubst
flags.
(tsubst_type_requirement): Return a substituted _REQ node when
processing_template_decl.
(tsubst_compound_requirement): Likewise.  Accomodate non-diagnostic
tsubst flags.
(tsubst_nested_requirement): Likewise.
(tsubst_requires_expr): Don't defer partial substitution when
processing_constraint_expression_p is true, in which case return
a substituted REQUIRES_EXPR.
* pt.cc (tsubst_expr) : Accomodate
non-diagnostic tsubst flags.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/class-deduction-alias18.C: New test.
* g++.dg/cpp2a/concepts-friend16.C: New test.
---
  gcc/cp/constraint.cc  | 56 +++
  gcc/cp/pt.cc  |  3 +-
  .../g++.dg/cpp2a/class-deduction-alias18.C| 13 +
  .../g++.dg/cpp2a/concepts-friend16.C  | 25 +
  4 files changed, 84 insertions(+), 13 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/cpp2a/class-deduction-alias18.C
  create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-friend16.C

diff --git a/gcc/cp/constraint.cc b/gcc/cp/constraint.cc
index fef68cf7ab2..d9569013bd3 100644
--- a/gcc/cp/constraint.cc
+++ b/gcc/cp/constraint.cc
@@ -85,7 +85,7 @@ struct subst_info
/* True if we should not diagnose errors.  */
bool quiet() const
{
-return complain == tf_none;
+return !(complain & tf_warning_or_error);
}
  
/* True if we should diagnose errors.  */

@@ -1991,8 +1991,9 @@ hash_placeholder_constraint (tree c)
  static tree
  tsubst_valid_expression_requirement (tree t, tree args, sat_info info)
  {
-  tree r = tsubst_expr (t, args, tf_none, info.in_decl);
-  if (convert_to_void (r, ICV_STATEMENT, tf_none) != error_mark_node)
+  tsubst_flags_t quiet = info.complain & ~tf_warning_or_error;
+  tree r = tsubst_expr (t, args, quiet, info.in_decl);
+  if (convert_to_void (r, ICV_STATEMENT, quiet) != error_mark_node)
  return r;
  
if (info.diagnose_unsatisfaction_p ())

@@ -2028,6 +2029,8 @@ tsubst_

Re: [PATCH 1/2] c++: requires-exprs and partial constraint subst [PR112769]

2024-02-02 Thread Patrick Palka
On Fri, 2 Feb 2024, Patrick Palka wrote:

> On Fri, 2 Feb 2024, Jason Merrill wrote:
> 
> > On 2/2/24 14:41, Patrick Palka wrote:
> > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this
> > > look OK for trunk?
> > > 
> > > -- >8 --
> > > 
> > > In r11-3261-gb28b621ac67bee we made tsubst_requires_expr never partially
> > > substitute into a requires-expression so as to avoid checking its
> > > requirements out of order during e.g. generic lambda regeneration.
> > > 
> > > Unfortunately we still do need to partially substitute into a
> > > requires-expression in rare cases, in particular when it's used in
> > > associated constraints that we are directly substituting for sake of
> > > declaration matching or dguide constraint rewriting.  We can identify
> > > this situation by checking processing_constraint_expression_p, so this
> > > patch uses this predicate to control whether we defer substitution or
> > > partially substitute.  The entering_scope=true change in tsubst_baselink
> > > is needed to avoid ICEing from tsubst_baselink during name lookup when
> > > rewriting std::ranges::ref_view's dguide constraints.
> > 
> > Actually, I don't think we want to enter the scope when rewriting 
> > constraints.
> > Would tsubst_scope work instead?
> 
> Oops yes, because of the maybe_dependent_member_ref stuff, the handling
> for which doesn't trigger here for some reason.  Ah, I think it's
> because the tf_dguide flag gets dropped during tsubst_requires_expr
> since it uses tf_none rather than complain & ~tf_warning_or_error
> which would preserve special tsubst flags such as tf_dguide.  I'll fix...

Like so?  Lightly tested so far, bootstrap+regtest in progress.

-- >8 --

Subject: [PATCH v2] c++: requires-exprs and partial constraint subst [PR112769]

In r11-3261-gb28b621ac67bee we made tsubst_requires_expr never partially
substitute into a requires-expression so as to avoid checking its
requirements out of order during e.g. generic lambda regeneration.

Unfortunately we still do need to partially substitute into a
requires-expression in rare cases, in particular when it's used in
associated constraints that we are directly substituting for sake of
declaration matching or dguide constraint rewriting.  We can identify
this situation by checking processing_constraint_expression_p, so this
patch uses this predicate to control whether we defer substitution or
partially substitute.

In turn, tsubst_requires_expr now needs to propagate semantic tsubst flags
rather than just using tf_none, in particular for dguide constraint rewriting
which sets tf_dguide.

PR c++/112769
PR c++/110006

gcc/cp/ChangeLog:

* constraint.cc (subst_info::quiet): Accomodate non-diagnostic
tsubst flags.
(tsubst_valid_expression_requirement): Likewise.
(tsubst_simple_requirement): Likewise.  Return a substituted _REQ
node when processing_template_decl.
(tsubst_type_requirement_1): Accomodate non-diagnostic tsubst
flags.
(tsubst_type_requirement): Return a substituted _REQ node when
processing_template_decl.
(tsubst_compound_requirement): Likewise.  Accomodate non-diagnostic
tsubst flags.
(tsubst_nested_requirement): Likewise.
(tsubst_requires_expr): Don't defer partial substitution when
processing_constraint_expression_p is true, in which case return
a substituted REQUIRES_EXPR.
* pt.cc (tsubst_expr) : Accomodate
non-diagnostic tsubst flags.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/class-deduction-alias18.C: New test.
* g++.dg/cpp2a/concepts-friend16.C: New test.
---
 gcc/cp/constraint.cc  | 56 +++
 gcc/cp/pt.cc  |  3 +-
 .../g++.dg/cpp2a/class-deduction-alias18.C| 13 +
 .../g++.dg/cpp2a/concepts-friend16.C  | 25 +
 4 files changed, 84 insertions(+), 13 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/class-deduction-alias18.C
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-friend16.C

diff --git a/gcc/cp/constraint.cc b/gcc/cp/constraint.cc
index fef68cf7ab2..d9569013bd3 100644
--- a/gcc/cp/constraint.cc
+++ b/gcc/cp/constraint.cc
@@ -85,7 +85,7 @@ struct subst_info
   /* True if we should not diagnose errors.  */
   bool quiet() const
   {
-return complain == tf_none;
+return !(complain & tf_warning_or_error);
   }
 
   /* True if we should diagnose errors.  */
@@ -1991,8 +1991,9 @@ hash_placeholder_constraint (tree c)
 static tree
 tsubst_valid_expression_requirement (tree t, tree args, sat_info info)
 {
-  tree r = tsubst_expr (t, args, tf_none, info.in_decl);
-  if (convert_to_void (r, ICV_STATEMENT, tf_none) != error_mark_node)
+  tsubst_flags_t quiet = info.complain & ~tf_warning_or_error;
+  tree r = tsubst_expr (t, args, quiet, info.in_decl);
+  if (convert_to_void (r, ICV_STATEMENT, quiet) != error_mark_node)
 return r;
 
   if (i

Re: [PATCH 1/2] c++: requires-exprs and partial constraint subst [PR112769]

2024-02-02 Thread Patrick Palka
On Fri, 2 Feb 2024, Jason Merrill wrote:

> On 2/2/24 14:41, Patrick Palka wrote:
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this
> > look OK for trunk?
> > 
> > -- >8 --
> > 
> > In r11-3261-gb28b621ac67bee we made tsubst_requires_expr never partially
> > substitute into a requires-expression so as to avoid checking its
> > requirements out of order during e.g. generic lambda regeneration.
> > 
> > Unfortunately we still do need to partially substitute into a
> > requires-expression in rare cases, in particular when it's used in
> > associated constraints that we are directly substituting for sake of
> > declaration matching or dguide constraint rewriting.  We can identify
> > this situation by checking processing_constraint_expression_p, so this
> > patch uses this predicate to control whether we defer substitution or
> > partially substitute.  The entering_scope=true change in tsubst_baselink
> > is needed to avoid ICEing from tsubst_baselink during name lookup when
> > rewriting std::ranges::ref_view's dguide constraints.
> 
> Actually, I don't think we want to enter the scope when rewriting constraints.
> Would tsubst_scope work instead?

Oops yes, because of the maybe_dependent_member_ref stuff, the handling
for which doesn't trigger here for some reason.  Ah, I think it's
because the tf_dguide flag gets dropped during tsubst_requires_expr
since it uses tf_none rather than complain & ~tf_warning_or_error
which would preserve special tsubst flags such as tf_dguide.  I'll fix...

> 
> Jason
> 
> 



Re: [PATCH 1/2] c++: requires-exprs and partial constraint subst [PR112769]

2024-02-02 Thread Jason Merrill

On 2/2/24 14:41, Patrick Palka wrote:

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

-- >8 --

In r11-3261-gb28b621ac67bee we made tsubst_requires_expr never partially
substitute into a requires-expression so as to avoid checking its
requirements out of order during e.g. generic lambda regeneration.

Unfortunately we still do need to partially substitute into a
requires-expression in rare cases, in particular when it's used in
associated constraints that we are directly substituting for sake of
declaration matching or dguide constraint rewriting.  We can identify
this situation by checking processing_constraint_expression_p, so this
patch uses this predicate to control whether we defer substitution or
partially substitute.  The entering_scope=true change in tsubst_baselink
is needed to avoid ICEing from tsubst_baselink during name lookup when
rewriting std::ranges::ref_view's dguide constraints.


Actually, I don't think we want to enter the scope when rewriting 
constraints.  Would tsubst_scope work instead?


Jason



Re: [PATCH 1/2] c++: requires-exprs and partial constraint subst [PR112769]

2024-02-02 Thread Jason Merrill

On 2/2/24 14:41, Patrick Palka wrote:

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


OK.


-- >8 --

In r11-3261-gb28b621ac67bee we made tsubst_requires_expr never partially
substitute into a requires-expression so as to avoid checking its
requirements out of order during e.g. generic lambda regeneration.

Unfortunately we still do need to partially substitute into a
requires-expression in rare cases, in particular when it's used in
associated constraints that we are directly substituting for sake of
declaration matching or dguide constraint rewriting.  We can identify
this situation by checking processing_constraint_expression_p, so this
patch uses this predicate to control whether we defer substitution or
partially substitute.  The entering_scope=true change in tsubst_baselink
is needed to avoid ICEing from tsubst_baselink during name lookup when
rewriting std::ranges::ref_view's dguide constraints.

PR c++/112769
PR c++/110006

gcc/cp/ChangeLog:

* constraint.cc (tsubst_simple_requirement): Return a
substituted _REQ node when processing_template_decl.
(tsubst_type_requirement): Likewise.
(tsubst_compound_requirement): Likewise.
(tsubst_nested_requirement): Likewise.
(tsubst_requires_expr): Don't defer partial substitution
when processing_constraint_expression_p is true, in which
case return a substituted REQUIRES_EXPR.
* pt.cc (tsubst_baselink): Use tsubst_aggr_type with
entring_scope=true instead of tsubst to substitute
qualifying_scope.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/class-deduction-alias18.C: New test.
* g++.dg/cpp2a/concepts-friend16.C: New test.
---
  gcc/cp/constraint.cc  | 38 +--
  gcc/cp/pt.cc  |  3 +-
  .../g++.dg/cpp2a/class-deduction-alias18.C| 13 +++
  .../g++.dg/cpp2a/concepts-friend16.C  | 25 
  4 files changed, 74 insertions(+), 5 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/cpp2a/class-deduction-alias18.C
  create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-friend16.C

diff --git a/gcc/cp/constraint.cc b/gcc/cp/constraint.cc
index fef68cf7ab2..450ae548f9a 100644
--- a/gcc/cp/constraint.cc
+++ b/gcc/cp/constraint.cc
@@ -2028,6 +2028,8 @@ tsubst_simple_requirement (tree t, tree args, sat_info 
info)
tree expr = tsubst_valid_expression_requirement (t0, args, info);
if (expr == error_mark_node)
  return error_mark_node;
+  if (processing_template_decl)
+return finish_simple_requirement (EXPR_LOCATION (t), expr);
return boolean_true_node;
  }
  
@@ -2068,6 +2070,8 @@ tsubst_type_requirement (tree t, tree args, sat_info info)

tree type = tsubst_type_requirement_1 (t0, args, info, EXPR_LOCATION (t));
if (type == error_mark_node)
  return error_mark_node;
+  if (processing_template_decl)
+return finish_type_requirement (EXPR_LOCATION (t), type);
return boolean_true_node;
  }
  
@@ -2182,6 +2186,9 @@ tsubst_compound_requirement (tree t, tree args, sat_info info)

}
  }
  
+  if (processing_template_decl)

+return finish_compound_requirement (EXPR_LOCATION (t),
+   expr, type, noexcept_p);
return boolean_true_node;
  }
  
@@ -2190,6 +2197,15 @@ tsubst_compound_requirement (tree t, tree args, sat_info info)

  static tree
  tsubst_nested_requirement (tree t, tree args, sat_info info)
  {
+  if (processing_template_decl)
+{
+  tree req = TREE_OPERAND (t, 0);
+  req = tsubst_constraint (req, args, info.complain, info.in_decl);
+  if (req == error_mark_node)
+   return error_mark_node;
+  return finish_nested_requirement (EXPR_LOCATION (t), req);
+}
+
sat_info quiet (tf_none, info.in_decl);
tree result = constraint_satisfaction_value (t, args, quiet);
if (result == boolean_true_node)
@@ -2330,18 +2346,25 @@ tsubst_requires_expr (tree t, tree args, sat_info info)
  
args = add_extra_args (REQUIRES_EXPR_EXTRA_ARGS (t), args,

 info.complain, info.in_decl);
-  if (processing_template_decl)
+  if (processing_template_decl
+  && !processing_constraint_expression_p ())
  {
/* We're partially instantiating a generic lambda.  Substituting into
 this requires-expression now may cause its requirements to get
 checked out of order, so instead just remember the template
-arguments and wait until we can substitute them all at once.  */
+arguments and wait until we can substitute them all at once.
+
+Except if this requires-expr is part of associated constraints
+that we're substituting into directly (for e.g. declaration
+matching or dguide constraint rewriting), in which case we need
+to partially substitute.  */
t = copy_node (t);
REQUIRES_EXPR_EXTRA_ARGS (t) = build_extra_args (

[PATCH 2/2] c++: remove lookup_template_class's entering_scope flag

2024-02-02 Thread Patrick Palka
Bootstrapped and regtested on x86_64-pc-linux, does this look like
an improvement?  This is not a bugfix and barely related to the previous
patch, but the previous patch's new use of entering_scope=true motivated
me to submit this patch since it seems like a nice simplification.

-- >8 --

lookup_template_class's entering_scope flag controls whether to prefer
returning the primary template type A instead of the corresponding
implicit instantiation A.  When we want to set this flag as part of
substitution, we need to use tsubst_aggr_type which also takes the flag,
but this separate entry point to substitution turned out to be subtly
problematic because it doesn't reuse typedefs like tsubst does, which
r13-4729-gbe124477b38a71 fixed in a way that respects the flag after the
fact, by adjusting the entering_scope=false result of
lookup_template_class as if entering_scope=true was passed.

But if that's possible then it means lookup_template_class's the
entering_scope flag is not necessary after all -- we can just do the
after-the-fact adjustment everywhere that we currently pass
entering_scope=true to it and tsubst_aggr_type.

To that end, this patch replaces this flag with an adjustment function
adjust_type_for_entering_scope, to be used whereever we currently need
the entering_scope=true behavior.  This means we can also get rid of
tsubst_aggr_type, since the only reason we needed this entry point
was to be able to pass entering_scope=true to lookup_template_class.

gcc/cp/ChangeLog:

* coroutines.cc (instantiate_coro_traits): Adjust call to
lookup_template_class.
(instantiate_coro_handle_for_promise_type): Likewise.
* cp-tree.h (adjust_type_for_entering_scope): Declare.
(lookup_template_class): Adjust declaration.
* decl.cc (make_typename_type): Adjust call to
lookup_template_class. Likewise.
(get_tuple_size): Likewise.
(get_tuple_element_type): Likewise.
* pt.cc (adjust_type_for_entering_scope): Define.
(lookup_template_class): Remove entering_scope parameter.
Replace tsubst_aggr_type call with tsubst followed by
adjust_type_for_entering_scope.
(tsubst_aggr_type): Remove.
(tsubst_aggr_type_1): Inline into tsubst.
(tsubst_function_decl): Replace tsubst_aggr_type call
with tsubst followed by adjust_type_for_entering_scope.
(tsubst_template_decl): Likewise.
(tsubst_decl): Likewise.
(tsubst) :
Inlined from tsubst_aggr_type_1.
: Adjust calls to
lookup_template_class.
: Replace tsubst_aggr_type call with
tsubst tsubst_scope followed by adjust_type_for_entering_scope.
: Replace tsubst_aggr_type
call with tsubst followed by adjust_type_for_entering_scope.
Increment processing_template_decl when substituting the
context.
(tsubst_baselink): Replace tsubst_aggr_type call with tsubst
followed by adjust_type_for_entering_scope.
(tsubst_expr) : Replace tsubst_aggr_type
call with tsubst followed by adjust_type_for_entering_scope.
: Likewise.
(instantiate_template): Likewise.
(resolve_typename_type): Adjust lookup_template_class call
and call adjust_type_for_entering_scope afterward.
(listify): Adjust lookup_template_class call.
(alias_ctad_tweaks): Likewise.
* semantics.cc (finish_template_type): Adjust lookup_template_class
call and maybe call adjust_type_for_entering_scope afterward.
---
 gcc/cp/coroutines.cc |   4 +-
 gcc/cp/cp-tree.h |   3 +-
 gcc/cp/decl.cc   |   4 +-
 gcc/cp/pt.cc | 212 +--
 gcc/cp/semantics.cc  |   4 +-
 5 files changed, 91 insertions(+), 136 deletions(-)

diff --git a/gcc/cp/coroutines.cc b/gcc/cp/coroutines.cc
index 3194c911e8c..8dab173d5cb 100644
--- a/gcc/cp/coroutines.cc
+++ b/gcc/cp/coroutines.cc
@@ -353,7 +353,7 @@ instantiate_coro_traits (tree fndecl, location_t kw)
   tree traits_class
 = lookup_template_class (coro_traits_templ, targ,
 /*in_decl=*/NULL_TREE, /*context=*/NULL_TREE,
-/*entering scope=*/false, tf_warning_or_error);
+tf_warning_or_error);
 
   if (traits_class == error_mark_node)
 {
@@ -400,7 +400,7 @@ instantiate_coro_handle_for_promise_type (location_t kw, 
tree promise_type)
 = lookup_template_class (coro_handle_identifier, targ,
 /* in_decl=*/NULL_TREE,
 /* context=*/std_node,
-/* entering scope=*/false, tf_warning_or_error);
+tf_warning_or_error);
 
   if (handle_type == error_mark_node)
 {
diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index 969c7239c97..4f73a7c84b6 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -7506,8 +7506,9 @@ extern tree push_template_decl 

[PATCH 1/2] c++: requires-exprs and partial constraint subst [PR112769]

2024-02-02 Thread Patrick Palka
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this
look OK for trunk?

-- >8 --

In r11-3261-gb28b621ac67bee we made tsubst_requires_expr never partially
substitute into a requires-expression so as to avoid checking its
requirements out of order during e.g. generic lambda regeneration.

Unfortunately we still do need to partially substitute into a
requires-expression in rare cases, in particular when it's used in
associated constraints that we are directly substituting for sake of
declaration matching or dguide constraint rewriting.  We can identify
this situation by checking processing_constraint_expression_p, so this
patch uses this predicate to control whether we defer substitution or
partially substitute.  The entering_scope=true change in tsubst_baselink
is needed to avoid ICEing from tsubst_baselink during name lookup when
rewriting std::ranges::ref_view's dguide constraints.

PR c++/112769
PR c++/110006

gcc/cp/ChangeLog:

* constraint.cc (tsubst_simple_requirement): Return a
substituted _REQ node when processing_template_decl.
(tsubst_type_requirement): Likewise.
(tsubst_compound_requirement): Likewise.
(tsubst_nested_requirement): Likewise.
(tsubst_requires_expr): Don't defer partial substitution
when processing_constraint_expression_p is true, in which
case return a substituted REQUIRES_EXPR.
* pt.cc (tsubst_baselink): Use tsubst_aggr_type with
entring_scope=true instead of tsubst to substitute
qualifying_scope.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/class-deduction-alias18.C: New test.
* g++.dg/cpp2a/concepts-friend16.C: New test.
---
 gcc/cp/constraint.cc  | 38 +--
 gcc/cp/pt.cc  |  3 +-
 .../g++.dg/cpp2a/class-deduction-alias18.C| 13 +++
 .../g++.dg/cpp2a/concepts-friend16.C  | 25 
 4 files changed, 74 insertions(+), 5 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/class-deduction-alias18.C
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-friend16.C

diff --git a/gcc/cp/constraint.cc b/gcc/cp/constraint.cc
index fef68cf7ab2..450ae548f9a 100644
--- a/gcc/cp/constraint.cc
+++ b/gcc/cp/constraint.cc
@@ -2028,6 +2028,8 @@ tsubst_simple_requirement (tree t, tree args, sat_info 
info)
   tree expr = tsubst_valid_expression_requirement (t0, args, info);
   if (expr == error_mark_node)
 return error_mark_node;
+  if (processing_template_decl)
+return finish_simple_requirement (EXPR_LOCATION (t), expr);
   return boolean_true_node;
 }
 
@@ -2068,6 +2070,8 @@ tsubst_type_requirement (tree t, tree args, sat_info info)
   tree type = tsubst_type_requirement_1 (t0, args, info, EXPR_LOCATION (t));
   if (type == error_mark_node)
 return error_mark_node;
+  if (processing_template_decl)
+return finish_type_requirement (EXPR_LOCATION (t), type);
   return boolean_true_node;
 }
 
@@ -2182,6 +2186,9 @@ tsubst_compound_requirement (tree t, tree args, sat_info 
info)
}
 }
 
+  if (processing_template_decl)
+return finish_compound_requirement (EXPR_LOCATION (t),
+   expr, type, noexcept_p);
   return boolean_true_node;
 }
 
@@ -2190,6 +2197,15 @@ tsubst_compound_requirement (tree t, tree args, sat_info 
info)
 static tree
 tsubst_nested_requirement (tree t, tree args, sat_info info)
 {
+  if (processing_template_decl)
+{
+  tree req = TREE_OPERAND (t, 0);
+  req = tsubst_constraint (req, args, info.complain, info.in_decl);
+  if (req == error_mark_node)
+   return error_mark_node;
+  return finish_nested_requirement (EXPR_LOCATION (t), req);
+}
+
   sat_info quiet (tf_none, info.in_decl);
   tree result = constraint_satisfaction_value (t, args, quiet);
   if (result == boolean_true_node)
@@ -2330,18 +2346,25 @@ tsubst_requires_expr (tree t, tree args, sat_info info)
 
   args = add_extra_args (REQUIRES_EXPR_EXTRA_ARGS (t), args,
 info.complain, info.in_decl);
-  if (processing_template_decl)
+  if (processing_template_decl
+  && !processing_constraint_expression_p ())
 {
   /* We're partially instantiating a generic lambda.  Substituting into
 this requires-expression now may cause its requirements to get
 checked out of order, so instead just remember the template
-arguments and wait until we can substitute them all at once.  */
+arguments and wait until we can substitute them all at once.
+
+Except if this requires-expr is part of associated constraints
+that we're substituting into directly (for e.g. declaration
+matching or dguide constraint rewriting), in which case we need
+to partially substitute.  */
   t = copy_node (t);
   REQUIRES_EXPR_EXTRA_ARGS (t) = build_extra_args (t, args, info.complain);
   return t;
 }
 
-  if (tree parms = REQUIRES_EXPR_P

Re: [PATCH v4] x86-64: Find a scratch register for large model profiling

2024-02-02 Thread H.J. Lu
On Fri, Feb 02, 2024 at 05:10:05PM +0100, Jakub Jelinek wrote:
> On Fri, Feb 02, 2024 at 07:42:00AM -0800, H.J. Lu wrote:
> > --- a/gcc/config/i386/i386.cc
> > +++ b/gcc/config/i386/i386.cc
> > @@ -22749,6 +22749,39 @@ current_fentry_section (const char **name)
> >return true;
> >  }
> >  
> > +/* Return an caller-saved register, which isn't live, at entry for
> > +   profile.  */
> > +
> > +static int
> > +x86_64_select_profile_regnum (bool r11_ok ATTRIBUTE_UNUSED)
> > +{
> > +  /* Use %r10 if it isn't used by DRAP.  */
> > +  if (!crtl->drap_reg || REGNO (crtl->drap_reg) != R10_REG)
> 
> I'd really like to see flag_fentry != 0 || here, if the profiler is
> emitted before the prologue (so before initializing the drap register),
> %r10 is a fine choice.

Fixed in v5.

> > +return R10_REG;
> > +
> > +  bitmap reg_live = df_get_live_out (ENTRY_BLOCK_PTR_FOR_FN (cfun));
> 
> I meant at pro_and_epilogue time, but perhaps doing it here
> can discover arguments of the function which are used somewhere in
> the body too.

My patch works when an argument is unused in the function body.  The
the unused argument register will be used for profiler.  I will add
a testcase in v5 to verify it.

> 
> > +  int i;
> > +  for (i = 0; i < FIRST_PSEUDO_REGISTER; i++)
> > +if (GENERAL_REGNO_P (i)
> > +   && i != R10_REG
> > +#ifdef NO_PROFILE_COUNTERS
> > +   && (r11_ok || i != R11_REG)
> > +#else
> > +   && i != R11_REG
> > +#endif
> > +   && (!REX2_INT_REGNO_P (i) || TARGET_APX_EGPR)
> > +   && !fixed_regs[i]
> > +   && call_used_regs[i]
> 
> I wonder if this shouldn't be && (call_used_regs[i] || X)
> where X would cover registers known to be saved in the prologue
> which aren't live from the prologue to the body (stuff like hard frame
> pointer if used).
> Because if the prologue say saves %r12 or %rbx to stack but doesn't
> yet set it to something, why couldn't the profiler use it?
> I'd expect cfun->machine contains something what has been saved there.

Added

 /* Bit mask for integer registers saved on stack in prologue.  The
 lower 8 bits are for legacy registers and the upper 8 bits are
 for r8-r15.  */
  unsigned int saved_int_registers : 16;

to track them.

> 
> > +   && !REGNO_REG_SET_P (reg_live, i))
> > +  return i;
> > +
> > +  sorry ("no register available for profiling %<-mcmodel=large%s%>",
> > +ix86_cmodel == CM_LARGE_PIC ? " -fPIC" : "");
> > +
> > +  return INVALID_REGNUM;
> > +}
> > +
> >  /* Output assembler code to FILE to increment profiler label # LABELNO
> > for profiling a function entry.  */
> >  void
> > @@ -22783,42 +22816,60 @@ x86_function_profiler (FILE *file, int labelno 
> > ATTRIBUTE_UNUSED)
> > fprintf (file, "\tleaq\t%sP%d(%%rip), %%r11\n", LPREFIX, labelno);
> >  #endif
> >  
> > +  int scratch;
> > +  const char *reg_prefix;
> > +  const char *reg;
> > +
> >if (!TARGET_PECOFF)
> > {
> >   switch (ix86_cmodel)
> > {
> > case CM_LARGE:
> > - /* NB: R10 is caller-saved.  Although it can be used as a
> > -static chain register, it is preserved when calling
> > -mcount for nested functions.  */
> > + scratch = x86_64_select_profile_regnum (true);
> > + reg = hi_reg_name[scratch];
> > + reg_prefix = LEGACY_INT_REGNO_P (scratch) ? "r" : "";
> >   if (ASSEMBLER_DIALECT == ASM_INTEL)
> > -   fprintf (file, "1:\tmovabs\tr10, OFFSET FLAT:%s\n"
> > -  "\tcall\tr10\n", mcount_name);
> > +   fprintf (file,
> > +"1:\tmovabs\t%s%s, OFFSET FLAT:%s\n"
> > +"\tcall\t%s%s\n",
> > +reg_prefix, reg, mcount_name, reg_prefix, reg);
> >   else
> > -   fprintf (file, "1:\tmovabsq\t$%s, %%r10\n\tcall\t*%%r10\n",
> > -mcount_name);
> > +   fprintf (file,
> > +"1:\tmovabsq\t$%s, %%%s%s\n\tcall\t*%%%s%s\n",
> > +mcount_name, reg_prefix, reg, reg_prefix, reg);
> >   break;
> > case CM_LARGE_PIC:
> >  #ifdef NO_PROFILE_COUNTERS
> > + scratch = x86_64_select_profile_regnum (false);
> > + reg = hi_reg_name[scratch];
> > + reg_prefix = LEGACY_INT_REGNO_P (scratch) ? "r" : "";
> >   if (ASSEMBLER_DIALECT == ASM_INTEL)
> > {
> >   fprintf (file, "1:movabs\tr11, "
> >  "OFFSET FLAT:_GLOBAL_OFFSET_TABLE_-1b\n");
> > - fprintf (file, "\tlea\tr10, 1b[rip]\n");
> > - fprintf (file, "\tadd\tr10, r11\n");
> > + fprintf (file, "\tlea\t%s%s, 1b[rip]\n",
> > +  reg_prefix, reg);
> > + fprintf (file, "\tadd\t%s%s, r11\n",
> > +  reg_prefix, reg);
> >   fprintf (file, "\tmovabs\tr11, OFFSET FLAT:%s@PLTOFF\n",
> >mcount_name);
> > - fprintf (file, "\tadd\tr10, r11\n");
> > -

Re: [PATCH] Notes on the warnings-as-errors change in GCC 14

2024-02-02 Thread Jonathan Wakely

On 02/02/24 17:59 +0100, Florian Weimer wrote:

---
htdocs/gcc-14/porting_to.html | 465 ++
1 file changed, 465 insertions(+)


base-commit: 15056edbb60e24a6410d9b75f7386de28ea60bc1

diff --git a/htdocs/gcc-14/porting_to.html b/htdocs/gcc-14/porting_to.html
index 3e4cedc3..4c8f9c8f 100644
--- a/htdocs/gcc-14/porting_to.html
+++ b/htdocs/gcc-14/porting_to.html
@@ -24,6 +24,471 @@ porting to GCC 14. This document is an effort to identify 
common issues
and provide solutions. Let us know if you have suggestions for improvements!


+C language issues
+
+Certain warnings are now errors
+
+https://archive.org/details/PC-Mag-1988-09-13/page/n115/mode/2up";>
+  Function prototyping was added, first to help enforce type checking
+  on both the types of the arguments passed to the function, and also
+  to check the assignment compatibility of the function return type.
+  
+Standard C: The ANSI Draft Grows Up.
+  PC Magazine, September 13, 1988, page 117.
+  
+
+
+The initial ISO C standard and its 1999 revision removed support for
+many C language features that were widely known as sources of
+application bugs due to accidental misuse.  For backwards
+compatibility, GCC 13 and earlier compiler versions diagnosed use of
+these features as warnings only.  Although these warnings have been
+enabled by default for many releases, experience shows that these
+warnings are easily ignored, resulting in difficult-to-diagnose bugs.
+In GCC 14, these issues are now reported as errors, and no output file
+is created, providing clearer feedback to programmers that something
+is wrong.
+
+
+Most components of the GNU project have already been fixed for
+compatibility, but not all of them have had releases since fixes were
+applied.  Programs that bundle parts
+of https://www.gnu.org/software/gnulib/";>gnulib or
+https://www.gnu.org/software/autoconf-archive/";>autoconf-archive
+may need to update these sources files from their upstream versions.
+
+
+Several GNU/Linux distributions have shared patches from their porting
+efforts on relevant upstream mailing lists and bug trackers, but of
+course there is a strong overlap between programs that have these
+historic C compatibility issues and are dormant today.
+
+Implicit int types 
(-Werror=implicit-int)
+
+In most cases, simply adding the missing int keyword
+addresses the error.  For example, a flag like
+
+
+  static initialized;
+
+
+might turn into:
+
+
+  static int initialized;
+
+
+If the return type of a function is omitted, the correct type to
+add could be int or void, depending on
+whether the function returns a value or not.
+
+In some cases, the previously implied int type
+was not correct.  This mostly happens in function definitions
+that are not prototypes, when argument types are not
+declared outside the parameter list.  Using the correct
+type maybe required to avoid int-conversion errors (see below).
+In the example below, the type of s should be
+const char *, not int:
+
+
+  write_string (fd, s)
+  {
+write (1, s, strlen (s));
+  }
+
+
+The corrected standard C source code might look like this (still
+disregarding error handling and short writes):
+
+
+  void
+  write_string (int fd, const char *s)
+  {
+write (1, s, strlen (s));
+  }
+
+
+Implicit function declarations 
(-Werror=implicit-function-declaration)
+
+It is no longer possible to call a function that has not been
+declared.  In general, the solution is to include a header file with
+an appropriate function prototype.  Note that GCC will perform further
+type checks based on the function prototype, which can reveal further
+type errors that require additional changes.
+
+
+For well-known functions declared in standard headers, GCC provides
+fix-it hints with the appropriate #include directives:
+
+
+error: implicit declaration of function ‘strlen’ 
[-Wimplicit-function-declaration]
+5 |   return strlen (s);
+  |  ^~
+note: include ‘’ or provide a declaration of ‘strlen’
+  +++ |+#include 
+1 |
+
+
+
+On GNU systems, headers described in standards (such as the C
+standard, or POSIX) may require the definition of certain
+macros at the start of the compilation before all required
+function declarations are made available.
+See https://sourceware.org/glibc/manual/html_node/Feature-Test-Macros.html";>Feature 
Test Macros
+in the GNU C Library manual for details.
+
+
+Some programs are built with -std=c11 or
+similar -std options that do not contain the
+string gnu, but these programs still use POSIX or other
+extensions in standard C headers such as .
+The GNU C library automatically suppresses these extensions in
+standard C mode, which can result in implicit function declarations.
+To address this, the -std=c11 option can be
+dropped, -std=gnu11 can be used instead,
+or -std=c11 -D_DEFAULT_SOURCE can be used re-enable
+common extensions.
+
+
+If undeclared functions from the same project are c

[pushed] c++: op== defaulted outside class [PR110084]

2024-02-02 Thread Jason Merrill
Tested x86_64-pc-linux-gnu, applying to trunk.

-- 8< --

defaulted_late_check is for checks that need to happen after the class is
complete; we shouldn't call it sooner.

PR c++/110084

gcc/cp/ChangeLog:

* pt.cc (tsubst_function_decl): Only check a function defaulted
outside the class if the class is complete.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/spaceship-synth-neg3.C: Check error message.
* g++.dg/cpp2a/spaceship-eq16.C: New test.
---
 gcc/cp/pt.cc  |  1 +
 gcc/testsuite/g++.dg/cpp2a/spaceship-eq16.C   | 11 +++
 gcc/testsuite/g++.dg/cpp2a/spaceship-synth-neg3.C |  2 +-
 3 files changed, 13 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/spaceship-eq16.C

diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
index 9d30a271713..355e9609bd3 100644
--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -14812,6 +14812,7 @@ tsubst_function_decl (tree t, tree args, tsubst_flags_t 
complain,
   if (DECL_SECTION_NAME (t))
 set_decl_section_name (r, t);
   if (DECL_DEFAULTED_OUTSIDE_CLASS_P (r)
+  && COMPLETE_TYPE_P (DECL_CONTEXT (r))
   && !processing_template_decl)
 defaulted_late_check (r);
 
diff --git a/gcc/testsuite/g++.dg/cpp2a/spaceship-eq16.C 
b/gcc/testsuite/g++.dg/cpp2a/spaceship-eq16.C
new file mode 100644
index 000..e5538ea9890
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/spaceship-eq16.C
@@ -0,0 +1,11 @@
+// PR c++/110084
+// { dg-do compile { target c++20 } }
+
+template 
+class BadTuple {
+  constexpr bool operator==(const BadTuple&) const;
+};
+template
+constexpr bool BadTuple::operator==(const BadTuple&) const = default;
+
+BadTuple a;
diff --git a/gcc/testsuite/g++.dg/cpp2a/spaceship-synth-neg3.C 
b/gcc/testsuite/g++.dg/cpp2a/spaceship-synth-neg3.C
index a4d8b32922f..aaa0264e7b3 100644
--- a/gcc/testsuite/g++.dg/cpp2a/spaceship-synth-neg3.C
+++ b/gcc/testsuite/g++.dg/cpp2a/spaceship-synth-neg3.C
@@ -5,7 +5,7 @@ template
 struct A {};
 
 struct B {
-constexpr auto operator<=>(const B&) const = default; // { dg-error "" }
+constexpr auto operator<=>(const B&) const = default; // { dg-error 
"strong_ordering" }
 int value;
 };
 

base-commit: 1c3cfb5a95dcc7f797ec2815690a6291878580c4
-- 
2.39.3



Re: [PATCH 1/2] libdecnumber: fixed undefined behavior in `decFloatFMA`

2024-02-02 Thread Ian McCormack
I've confirmed that these changes fix the error in MIRI, too. I'll post
an updated patch once I confirm that there aren't any regressions.

On Fri, Feb 2, 2024 at 10:38 AM Jakub Jelinek  wrote:

> On Fri, Feb 02, 2024 at 04:32:09PM +0100, Jakub Jelinek wrote:
> > Anyway, I think all of
> > decBasic.c: for (; UBTOUI(umsd)==0 && umsd+3 > decBasic.c: for (; *umsd==0 && umsd > decBasic.c:  for (; UBTOUI(hi->msd)==0 && hi->msd+3lsd;) hi->msd+=4;
> > decBasic.c:  for (; *hi->msd==0 && hi->msdlsd;) hi->msd++;
> > decBasic.c:  for (; UBTOUI(lo->msd)==0 && lo->msd+3lsd;) lo->msd+=4;
> > decBasic.c:  for (; *lo->msd==0 && lo->msdlsd;) lo->msd++;
> > decBasic.c:  for (; UBTOUI(lo->msd)==0 && lo->msd+3lsd;)
> lo->msd+=4;
> > decBasic.c:  for (; *lo->msd==0 && lo->msdlsd;) lo->msd++;
> > decCommon.c:  for (; *umsd==0 && umsd
> even more than that:
> decBasic.c:  for (; *msua==0 && msua>=lsua;) msua--;
> decBasic.c:if (*msua==0 && msua==lsua) break;
> decCommon.c:  if (*ulsd==0 && ulsd==umsd) { /* have zero */
> decNumber.c:for (; *msu1==0 && msu1>var1; msu1--) var1units--;
> too just from simple grep.
>
> Jakub
>
>


[committed] hppa: Implement TARGET_ATOMIC_ASSIGN_EXPAND_FENV

2024-02-02 Thread John David Anglin
Tested on hppa-unknown-linux-gnu and hppa64-hp-hpux11.11.

This is the first step in fixing PR target/59778.  libatomic/fenv.c
needs fixing for hppa so exceptions are correctly raised.

Committed to trunk.

Dave
---

hppa: Implement TARGET_ATOMIC_ASSIGN_EXPAND_FENV

This change implements __builtin_get_fpsr() and __builtin_set_fpsr(x)
to get and set the floating-point status register.  They are used to
implement pa_atomic_assign_expand_fenv().

2024-02-02  John David Anglin  

gcc/ChangeLog:

PR target/59778
* config/pa/pa.cc (enum pa_builtins): Add PA_BUILTIN_GET_FPSR
and PA_BUILTIN_SET_FPSR builtins.
* (pa_builtins_icode): Declare.
* (def_builtin, pa_fpu_init_builtins): New.
* (pa_init_builtins): Initialize FPU builtins.
* (pa_builtin_decl, pa_expand_builtin_1): New.
* (pa_expand_builtin): Handle PA_BUILTIN_GET_FPSR and
PA_BUILTIN_SET_FPSR builtins.
* (pa_atomic_assign_expand_fenv): New.
* config/pa/pa.md (UNSPECV_GET_FPSR, UNSPECV_SET_FPSR): New
UNSPECV constants.
(get_fpsr, put_fpsr): New expanders.
(get_fpsr_32, get_fpsr_64, set_fpsr_32, set_fpsr_64): New
insn patterns.

diff --git a/gcc/config/pa/pa.cc b/gcc/config/pa/pa.cc
index c58b0a0d75e..694123e37c9 100644
--- a/gcc/config/pa/pa.cc
+++ b/gcc/config/pa/pa.cc
@@ -28,6 +28,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "target.h"
 #include "rtl.h"
 #include "tree.h"
+#include "gimple.h"
 #include "df.h"
 #include "tm_p.h"
 #include "stringpool.h"
@@ -142,6 +143,7 @@ static void pa_asm_out_destructor (rtx, int);
 #endif
 static void pa_init_builtins (void);
 static rtx pa_expand_builtin (tree, rtx, rtx, machine_mode mode, int);
+static tree pa_builtin_decl (unsigned, bool);
 static rtx hppa_builtin_saveregs (void);
 static void hppa_va_start (tree, rtx);
 static tree hppa_gimplify_va_arg_expr (tree, tree, gimple_seq *, gimple_seq *);
@@ -205,6 +207,7 @@ static bool pa_modes_tieable_p (machine_mode, machine_mode);
 static bool pa_can_change_mode_class (machine_mode, machine_mode, reg_class_t);
 static HOST_WIDE_INT pa_starting_frame_offset (void);
 static section* pa_elf_select_rtx_section(machine_mode, rtx, unsigned 
HOST_WIDE_INT) ATTRIBUTE_UNUSED;
+static void pa_atomic_assign_expand_fenv (tree *, tree *, tree *);
 
 /* The following extra sections are only used for SOM.  */
 static GTY(()) section *som_readonly_data_section;
@@ -314,9 +317,10 @@ static size_t n_deferred_plabels = 0;
 
 #undef TARGET_INIT_BUILTINS
 #define TARGET_INIT_BUILTINS pa_init_builtins
-
 #undef TARGET_EXPAND_BUILTIN
 #define TARGET_EXPAND_BUILTIN pa_expand_builtin
+#undef  TARGET_BUILTIN_DECL
+#define TARGET_BUILTIN_DECL  pa_builtin_decl
 
 #undef TARGET_REGISTER_MOVE_COST
 #define TARGET_REGISTER_MOVE_COST hppa_register_move_cost
@@ -426,6 +430,9 @@ static size_t n_deferred_plabels = 0;
 #undef TARGET_HAVE_SPECULATION_SAFE_VALUE
 #define TARGET_HAVE_SPECULATION_SAFE_VALUE speculation_safe_value_not_needed
 
+#undef TARGET_ATOMIC_ASSIGN_EXPAND_FENV
+#define TARGET_ATOMIC_ASSIGN_EXPAND_FENV pa_atomic_assign_expand_fenv
+
 struct gcc_target targetm = TARGET_INITIALIZER;
 
 /* Parse the -mfixed-range= option string.  */
@@ -592,6 +599,10 @@ pa_option_override (void)
 
 enum pa_builtins
 {
+  /* FPU builtins.  */
+  PA_BUILTIN_GET_FPSR,
+  PA_BUILTIN_SET_FPSR,
+
   PA_BUILTIN_COPYSIGNQ,
   PA_BUILTIN_FABSQ,
   PA_BUILTIN_INFQ,
@@ -600,10 +611,48 @@ enum pa_builtins
 };
 
 static GTY(()) tree pa_builtins[(int) PA_BUILTIN_max];
+static GTY(()) enum insn_code pa_builtins_icode[(int) PA_BUILTIN_max];
+
+/* Add a PA  builtin function with NAME, ICODE, CODE and TYPE.  Return the
+   function decl or NULL_TREE if the builtin was not added.  */
+
+static tree
+def_builtin (const char *name, enum insn_code icode, enum pa_builtins code,
+tree type)
+{
+  tree t
+= add_builtin_function (name, type, code, BUILT_IN_MD, NULL, NULL_TREE);
+
+  if (t)
+{
+  pa_builtins[code] = t;
+  pa_builtins_icode[code] = icode;
+}
+
+  return t;
+}
+
+/* Create builtin functions for FPU instructions.  */
+
+static void
+pa_fpu_init_builtins (void)
+{
+  tree ftype;
+
+  ftype = build_function_type_list (unsigned_type_node, 0);
+  def_builtin ("__builtin_get_fpsr", CODE_FOR_get_fpsr,
+  PA_BUILTIN_GET_FPSR, ftype);
+  ftype = build_function_type_list (void_type_node, unsigned_type_node, 0);
+  def_builtin ("__builtin_set_fpsr", CODE_FOR_set_fpsr,
+  PA_BUILTIN_SET_FPSR, ftype);
+}
 
 static void
 pa_init_builtins (void)
 {
+  if (!TARGET_SOFT_FLOAT)
+pa_fpu_init_builtins ();
+
 #ifdef DONT_HAVE_FPUTC_UNLOCKED
   {
 tree decl = builtin_decl_explicit (BUILT_IN_PUTC_UNLOCKED);
@@ -663,6 +712,92 @@ pa_init_builtins (void)
 }
 }
 
+/* Implement TARGET_BUILTIN_DECL.  */
+
+static tree
+pa_builtin_decl (unsigned int code, bool initialize_p ATTRIBUTE_UNUSED)
+{
+  if (code >= PA_BUILTIN_max)
+return error

Re: [PATCH] Notes on the warnings-as-errors change in GCC 14

2024-02-02 Thread Jonathan Wakely

On 02/02/24 17:59 +0100, Florian Weimer wrote:

---
htdocs/gcc-14/porting_to.html | 465 ++
1 file changed, 465 insertions(+)


base-commit: 15056edbb60e24a6410d9b75f7386de28ea60bc1

diff --git a/htdocs/gcc-14/porting_to.html b/htdocs/gcc-14/porting_to.html
index 3e4cedc3..4c8f9c8f 100644
--- a/htdocs/gcc-14/porting_to.html
+++ b/htdocs/gcc-14/porting_to.html
@@ -24,6 +24,471 @@ porting to GCC 14. This document is an effort to identify 
common issues
and provide solutions. Let us know if you have suggestions for improvements!


+C language issues
+
+Certain warnings are now errors
+
+https://archive.org/details/PC-Mag-1988-09-13/page/n115/mode/2up";>
+  Function prototyping was added, first to help enforce type checking
+  on both the types of the arguments passed to the function, and also
+  to check the assignment compatibility of the function return type.
+  
+Standard C: The ANSI Draft Grows Up.
+  PC Magazine, September 13, 1988, page 117.
+  
+
+
+The initial ISO C standard and its 1999 revision removed support for
+many C language features that were widely known as sources of
+application bugs due to accidental misuse.  For backwards
+compatibility, GCC 13 and earlier compiler versions diagnosed use of
+these features as warnings only.  Although these warnings have been
+enabled by default for many releases, experience shows that these
+warnings are easily ignored, resulting in difficult-to-diagnose bugs.
+In GCC 14, these issues are now reported as errors, and no output file
+is created, providing clearer feedback to programmers that something
+is wrong.
+
+
+Most components of the GNU project have already been fixed for
+compatibility, but not all of them have had releases since fixes were
+applied.  Programs that bundle parts
+of https://www.gnu.org/software/gnulib/";>gnulib or
+https://www.gnu.org/software/autoconf-archive/";>autoconf-archive
+may need to update these sources files from their upstream versions.
+
+
+Several GNU/Linux distributions have shared patches from their porting
+efforts on relevant upstream mailing lists and bug trackers, but of
+course there is a strong overlap between programs that have these
+historic C compatibility issues and are dormant today.
+
+Implicit int types 
(-Werror=implicit-int)
+
+In most cases, simply adding the missing int keyword
+addresses the error.  For example, a flag like
+
+
+  static initialized;
+
+
+might turn into:
+
+
+  static int initialized;
+
+
+If the return type of a function is omitted, the correct type to
+add could be int or void, depending on
+whether the function returns a value or not.
+
+In some cases, the previously implied int type
+was not correct.  This mostly happens in function definitions
+that are not prototypes, when argument types are not
+declared outside the parameter list.  Using the correct
+type maybe required to avoid int-conversion errors (see below).


s/maybe/may be/


+In the example below, the type of s should be
+const char *, not int:
+
+
+  write_string (fd, s)
+  {
+write (1, s, strlen (s));
+  }
+
+
+The corrected standard C source code might look like this (still
+disregarding error handling and short writes):
+
+
+  void
+  write_string (int fd, const char *s)
+  {
+write (1, s, strlen (s));
+  }
+
+
+Implicit function declarations 
(-Werror=implicit-function-declaration)
+
+It is no longer possible to call a function that has not been
+declared.  In general, the solution is to include a header file with
+an appropriate function prototype.  Note that GCC will perform further
+type checks based on the function prototype, which can reveal further
+type errors that require additional changes.
+
+
+For well-known functions declared in standard headers, GCC provides
+fix-it hints with the appropriate #include directives:
+
+
+error: implicit declaration of function ‘strlen’ 
[-Wimplicit-function-declaration]
+5 |   return strlen (s);
+  |  ^~
+note: include ‘’ or provide a declaration of ‘strlen’
+  +++ |+#include 
+1 |
+
+
+
+On GNU systems, headers described in standards (such as the C
+standard, or POSIX) may require the definition of certain
+macros at the start of the compilation before all required
+function declarations are made available.
+See https://sourceware.org/glibc/manual/html_node/Feature-Test-Macros.html";>Feature 
Test Macros
+in the GNU C Library manual for details.
+
+
+Some programs are built with -std=c11 or
+similar -std options that do not contain the
+string gnu, but these programs still use POSIX or other
+extensions in standard C headers such as .
+The GNU C library automatically suppresses these extensions in
+standard C mode, which can result in implicit function declarations.
+To address this, the -std=c11 option can be
+dropped, -std=gnu11 can be used instead,
+or -std=c11 -D_DEFAULT_SOURCE can be used re-enable
+common extensions.
+
+
+If undeclared functions from th

Re: [PATCH] libgcc, v2: Fix up _BitInt division [PR113604]

2024-02-02 Thread Joseph Myers
On Wed, 31 Jan 2024, Jakub Jelinek wrote:

> Hi!
> 
> On Sat, Jan 27, 2024 at 08:53:42AM +0100, Jakub Jelinek wrote:
> > The following testcase ends up with SIGFPE in __divmodbitint4.
> > The problem is a thinko in my attempt to implement Knuth's algorithm.
> 
> Here is an updated version of the patch, the libgcc part is the same,
> but I've added a new testcase which tests the behavior of all the changed
> cases, so it has a case where uv1:uv0 / vv1 is 1:1, where it is
> 1:0 and rhat + vv1 overflows and where it is 1:0 and rhat + vv1 does not
> overflow, and includes tests also from Zdenek's other failing tests.
> 
> Previously successfully bootstrapped/regtested on x86_64-linux and
> i686-linux, the new version has been retested with
> make check-gcc GCC_TEST_RUN_EXPENSIVE=1 
> RUNTESTFLAGS="GCC_TEST_RUN_EXPENSIVE=1 dg-torture.exp='bitint-53.c 
> bitint-55.c'"
> Ok for trunk?

OK.

-- 
Joseph S. Myers
josmy...@redhat.com



[PATCH] Notes on the warnings-as-errors change in GCC 14

2024-02-02 Thread Florian Weimer
---
 htdocs/gcc-14/porting_to.html | 465 ++
 1 file changed, 465 insertions(+)

diff --git a/htdocs/gcc-14/porting_to.html b/htdocs/gcc-14/porting_to.html
index 3e4cedc3..4c8f9c8f 100644
--- a/htdocs/gcc-14/porting_to.html
+++ b/htdocs/gcc-14/porting_to.html
@@ -24,6 +24,471 @@ porting to GCC 14. This document is an effort to identify 
common issues
 and provide solutions. Let us know if you have suggestions for improvements!
 
 
+C language issues
+
+Certain warnings are now errors
+
+https://archive.org/details/PC-Mag-1988-09-13/page/n115/mode/2up";>
+  Function prototyping was added, first to help enforce type checking
+  on both the types of the arguments passed to the function, and also
+  to check the assignment compatibility of the function return type.
+  
+Standard C: The ANSI Draft Grows Up.
+  PC Magazine, September 13, 1988, page 117.
+  
+
+
+The initial ISO C standard and its 1999 revision removed support for
+many C language features that were widely known as sources of
+application bugs due to accidental misuse.  For backwards
+compatibility, GCC 13 and earlier compiler versions diagnosed use of
+these features as warnings only.  Although these warnings have been
+enabled by default for many releases, experience shows that these
+warnings are easily ignored, resulting in difficult-to-diagnose bugs.
+In GCC 14, these issues are now reported as errors, and no output file
+is created, providing clearer feedback to programmers that something
+is wrong.
+
+
+Most components of the GNU project have already been fixed for
+compatibility, but not all of them have had releases since fixes were
+applied.  Programs that bundle parts
+of https://www.gnu.org/software/gnulib/";>gnulib or
+https://www.gnu.org/software/autoconf-archive/";>autoconf-archive
+may need to update these sources files from their upstream versions.
+
+
+Several GNU/Linux distributions have shared patches from their porting
+efforts on relevant upstream mailing lists and bug trackers, but of
+course there is a strong overlap between programs that have these
+historic C compatibility issues and are dormant today.
+
+Implicit int types 
(-Werror=implicit-int)
+
+In most cases, simply adding the missing int keyword
+addresses the error.  For example, a flag like
+
+
+  static initialized;
+
+
+might turn into:
+
+
+  static int initialized;
+
+
+If the return type of a function is omitted, the correct type to
+add could be int or void, depending on
+whether the function returns a value or not.
+
+In some cases, the previously implied int type
+was not correct.  This mostly happens in function definitions
+that are not prototypes, when argument types are not
+declared outside the parameter list.  Using the correct
+type maybe required to avoid int-conversion errors (see below).
+In the example below, the type of s should be
+const char *, not int:
+
+
+  write_string (fd, s)
+  {
+write (1, s, strlen (s));
+  }
+
+
+The corrected standard C source code might look like this (still
+disregarding error handling and short writes):
+
+
+  void
+  write_string (int fd, const char *s)
+  {
+write (1, s, strlen (s));
+  }
+
+
+Implicit function declarations 
(-Werror=implicit-function-declaration)
+
+It is no longer possible to call a function that has not been
+declared.  In general, the solution is to include a header file with
+an appropriate function prototype.  Note that GCC will perform further
+type checks based on the function prototype, which can reveal further
+type errors that require additional changes.
+
+
+For well-known functions declared in standard headers, GCC provides
+fix-it hints with the appropriate #include directives:
+
+
+error: implicit declaration of function ‘strlen’ 
[-Wimplicit-function-declaration]
+5 |   return strlen (s);
+  |  ^~
+note: include ‘’ or provide a declaration of ‘strlen’
+  +++ |+#include 
+1 |
+
+
+
+On GNU systems, headers described in standards (such as the C
+standard, or POSIX) may require the definition of certain
+macros at the start of the compilation before all required
+function declarations are made available.
+See https://sourceware.org/glibc/manual/html_node/Feature-Test-Macros.html";>Feature
 Test Macros
+in the GNU C Library manual for details.
+
+
+Some programs are built with -std=c11 or
+similar -std options that do not contain the
+string gnu, but these programs still use POSIX or other
+extensions in standard C headers such as .
+The GNU C library automatically suppresses these extensions in
+standard C mode, which can result in implicit function declarations.
+To address this, the -std=c11 option can be
+dropped, -std=gnu11 can be used instead,
+or -std=c11 -D_DEFAULT_SOURCE can be used re-enable
+common extensions.
+
+
+If undeclared functions from the same project are called and there is
+yet no suitable shared header file, you should add a declaration to a
+header fi

Re: [PATCH] libstdc++: atomic: Add missing clear_padding in __atomic_float constructor

2024-02-02 Thread xndcn
Thank you for your careful review!

> But we don't need a new one if it's going to be used in exactly one test and 
> if the new option does the same thing for all targets that run the test.
Got it, thanks. Now add option "-latomic" directly, but it still rely
on the trick "[atomic_link_flags [get_multilibs]]"

> No, because the patch is supposed to prevent the infinite loop, and so 
> there's no need to stop it looping after 10s. It won't loop at all.
Thanks, deleted.

> We only need to clear padding for long double, not float and double, right?
Yes, actually there is a check "if constexpr
(__atomic_impl::__maybe_has_padding<_Fp>())".
But "__atomic_impl::__clear_padding(_M_fp); " is indeed simply, so fixed here.

> Why can't we run this on all targets?
Got it, now target option deleted.

> There's no reason to use __builtin_memset here, just include  and 
> use std::memcpy.
Thanks, fixed.

> It definitely does have padding, just say "long double has padding bits on 
> x86"
Thanks, fixed.

So here comes the latest patch:
---
libstdc++-v3/ChangeLog:

 * include/bits/atomic_base.h: add __builtin_clear_padding in
__atomic_float constructor.
 * testsuite/29_atomics/atomic_float/compare_exchange_padding.cc: New test.

Signed-off-by: xndcn 
---
 libstdc++-v3/include/bits/atomic_base.h   |  2 +-
 .../atomic_float/compare_exchange_padding.cc  | 53 +++
 2 files changed, 54 insertions(+), 1 deletion(-)
 create mode 100644
libstdc++-v3/testsuite/29_atomics/atomic_float/compare_exchange_padding.cc

diff --git a/libstdc++-v3/include/bits/atomic_base.h
b/libstdc++-v3/include/bits/atomic_base.h
index f4ce0fa53..cdd6f07da 100644
--- a/libstdc++-v3/include/bits/atomic_base.h
+++ b/libstdc++-v3/include/bits/atomic_base.h
@@ -1283,7 +1283,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION

   constexpr
   __atomic_float(_Fp __t) : _M_fp(__t)
-  { }
+  { __atomic_impl::__clear_padding(_M_fp); }

   __atomic_float(const __atomic_float&) = delete;
   __atomic_float& operator=(const __atomic_float&) = delete;
diff --git 
a/libstdc++-v3/testsuite/29_atomics/atomic_float/compare_exchange_padding.cc
b/libstdc++-v3/testsuite/29_atomics/atomic_float/compare_exchange_padding.cc
new file mode 100644
index 0..eeace251c
--- /dev/null
+++ b/libstdc++-v3/testsuite/29_atomics/atomic_float/compare_exchange_padding.cc
@@ -0,0 +1,53 @@
+// { dg-do run { target c++20 } }
+// { dg-options "-O0" }
+// { dg-additional-options "[atomic_link_flags [get_multilibs]] -latomic" }
+
+#include 
+#include 
+#include 
+#include 
+
+template
+void __attribute__((noinline,noipa))
+fill_padding(T& f)
+{
+  T mask;
+  std::memset(&mask, 0xff, sizeof(T));
+  __builtin_clear_padding(&mask);
+  unsigned char* ptr_f = (unsigned char*)&f;
+  unsigned char* ptr_mask = (unsigned char*)&mask;
+  for (int i = 0; i < sizeof(T); i++)
+  {
+if (ptr_mask[i] == 0x00)
+{
+  ptr_f[i] = 0xff;
+}
+  }
+}
+
+void
+test01()
+{
+  // test for long double with padding (float80)
+  if constexpr (std::numeric_limits::digits == 64)
+  {
+long double f = 0.5f; // long double has padding bits on x86
+fill_padding(f);
+std::atomic as{ f }; // padding cleared on constructor
+long double t = 1.5;
+
+as.fetch_add(t);
+long double s = f + t;
+t = as.load();
+VERIFY(s == t); // padding ignored on float comparing
+fill_padding(s);
+VERIFY(as.compare_exchange_weak(s, f)); // padding cleared on cmpexchg
+fill_padding(f);
+VERIFY(as.compare_exchange_strong(f, t)); // padding cleared on cmpexchg
+  }
+}
+
+int main()
+{
+  test01();
+}
-- 
2.25.1


Re: [PATCH] c++: Don't advertise cxx_constexpr_string_builtins [PR113658]

2024-02-02 Thread Marek Polacek
On Fri, Feb 02, 2024 at 05:32:31PM +0100, Jakub Jelinek wrote:
> On Fri, Feb 02, 2024 at 11:27:09AM -0500, Marek Polacek wrote:
> > > With -pedantic-errors we would have __has_extension behaving like
> > > __has_feature, and I wanted to check in the test that this doesn't get
> > > reported as a feature or extension.
> >  
> > Oh I see.  A comment to that effect might be helpful.
> 
> Don't we have over 1200 other tests with dg-options "" which
> don't have comments why they are doing that?

Yes, but the __has_extension / __has_feature thing doesn't seem
obvious at all, and the test passed for me with and without
dg-options "".

But I'm fine with the patch either way.

Marek



Re: [PATCH] c++: Don't advertise cxx_constexpr_string_builtins [PR113658]

2024-02-02 Thread Jakub Jelinek
On Fri, Feb 02, 2024 at 11:27:09AM -0500, Marek Polacek wrote:
> > With -pedantic-errors we would have __has_extension behaving like
> > __has_feature, and I wanted to check in the test that this doesn't get
> > reported as a feature or extension.
>  
> Oh I see.  A comment to that effect might be helpful.

Don't we have over 1200 other tests with dg-options "" which
don't have comments why they are doing that?

Jakub



Re: [PATCH] c++: Don't advertise cxx_constexpr_string_builtins [PR113658]

2024-02-02 Thread Marek Polacek
On Fri, Feb 02, 2024 at 03:45:48PM +, Alex Coplan wrote:
> On 02/02/2024 09:34, Marek Polacek wrote:
> > On Fri, Feb 02, 2024 at 10:27:23AM +, Alex Coplan wrote:
> > > Bootstrapped/regtested on x86_64-apple-darwin, OK for trunk?
> > > 
> > > Thanks,
> > > Alex
> > > 
> > > -- >8 --
> > > 
> > > When __has_feature was introduced for GCC 14, I included the feature
> > > cxx_constexpr_string_builtins, since of the relevant string builtins
> > > that GCC implements, it seems to support constexpr evaluation of those
> > > builtins.
> > > 
> > > However, as the PR shows, GCC doesn't implement the full list of
> > > builtins in the clang documentation.  After enumerating the builtins,
> > > the clang docs [1] say:
> > > 
> > > > Support for constant expression evaluation for the above builtins can
> > > > be detected with __has_feature(cxx_constexpr_string_builtins).
> > > 
> > > and a strict reading of this would suggest we can't really support
> > > constexpr evaluation of a builtin if we don't implement the builtin in
> > > the first place.
> > > 
> > > So the conservatively correct thing to do seems to be to stop
> > > advertising the feature altogether to avoid failing to build code which
> > > assumes the presence of this feature implies the presence of all the
> > > builtins listed in the clang documentation.
> > > 
> > > [1] : https://clang.llvm.org/docs/LanguageExtensions.html#string-builtins
> > > 
> > > gcc/cp/ChangeLog:
> > > 
> > >   PR c++/113658
> > >   * cp-objcp-common.cc (cp_feature_table): Remove entry for
> > >   cxx_constexpr_string_builtins.
> > > 
> > > gcc/testsuite/ChangeLog:
> > > 
> > >   PR c++/113658
> > >   * g++.dg/ext/pr113658.C: New test.
> > 
> > > diff --git a/gcc/cp/cp-objcp-common.cc b/gcc/cp/cp-objcp-common.cc
> > > index f06edf04ef0..85dde0459fa 100644
> > > --- a/gcc/cp/cp-objcp-common.cc
> > > +++ b/gcc/cp/cp-objcp-common.cc
> > > @@ -110,7 +110,6 @@ static constexpr cp_feature_info cp_feature_table[] =
> > >{ "cxx_alignof", cxx11 },
> > >{ "cxx_attributes", cxx11 },
> > >{ "cxx_constexpr", cxx11 },
> > > -  { "cxx_constexpr_string_builtins", cxx11 },
> > >{ "cxx_decltype", cxx11 },
> > >{ "cxx_decltype_incomplete_return_types", cxx11 },
> > >{ "cxx_default_function_template_args", cxx11 },
> > > diff --git a/gcc/testsuite/g++.dg/ext/pr113658.C 
> > > b/gcc/testsuite/g++.dg/ext/pr113658.C
> > > new file mode 100644
> > > index 000..f4a34888f28
> > > --- /dev/null
> > > +++ b/gcc/testsuite/g++.dg/ext/pr113658.C
> > 
> > Might be better to name this has-feature2.C
> > 
> > > @@ -0,0 +1,13 @@
> > 
> > Please include
> > // PR c++/113658
> 
> Can do.
> 
> > 
> > > +// { dg-do compile }
> > > +// { dg-options "" }
> > 
> > Why dg-options ""?  It doesn't seem to have any purpose here.
> 
> That is to disable -pedantic-errors which IIRC is added by default in
> the testsuite options.

Right.

> With -pedantic-errors we would have __has_extension behaving like
> __has_feature, and I wanted to check in the test that this doesn't get
> reported as a feature or extension.
 
Oh I see.  A comment to that effect might be helpful.

Otherwise LGTM, thanks.

Marek



Re: [PATCH v4] x86-64: Find a scratch register for large model profiling

2024-02-02 Thread Jakub Jelinek
On Fri, Feb 02, 2024 at 07:42:00AM -0800, H.J. Lu wrote:
> --- a/gcc/config/i386/i386.cc
> +++ b/gcc/config/i386/i386.cc
> @@ -22749,6 +22749,39 @@ current_fentry_section (const char **name)
>return true;
>  }
>  
> +/* Return an caller-saved register, which isn't live, at entry for
> +   profile.  */
> +
> +static int
> +x86_64_select_profile_regnum (bool r11_ok ATTRIBUTE_UNUSED)
> +{
> +  /* Use %r10 if it isn't used by DRAP.  */
> +  if (!crtl->drap_reg || REGNO (crtl->drap_reg) != R10_REG)

I'd really like to see flag_fentry != 0 || here, if the profiler is
emitted before the prologue (so before initializing the drap register),
%r10 is a fine choice.

> +return R10_REG;
> +
> +  bitmap reg_live = df_get_live_out (ENTRY_BLOCK_PTR_FOR_FN (cfun));

I meant at pro_and_epilogue time, but perhaps doing it here
can discover arguments of the function which are used somewhere in
the body too.

> +  int i;
> +  for (i = 0; i < FIRST_PSEUDO_REGISTER; i++)
> +if (GENERAL_REGNO_P (i)
> + && i != R10_REG
> +#ifdef NO_PROFILE_COUNTERS
> + && (r11_ok || i != R11_REG)
> +#else
> + && i != R11_REG
> +#endif
> + && (!REX2_INT_REGNO_P (i) || TARGET_APX_EGPR)
> + && !fixed_regs[i]
> + && call_used_regs[i]

I wonder if this shouldn't be && (call_used_regs[i] || X)
where X would cover registers known to be saved in the prologue
which aren't live from the prologue to the body (stuff like hard frame
pointer if used).
Because if the prologue say saves %r12 or %rbx to stack but doesn't
yet set it to something, why couldn't the profiler use it?
I'd expect cfun->machine contains something what has been saved there.

> + && !REGNO_REG_SET_P (reg_live, i))
> +  return i;
> +
> +  sorry ("no register available for profiling %<-mcmodel=large%s%>",
> +  ix86_cmodel == CM_LARGE_PIC ? " -fPIC" : "");
> +
> +  return INVALID_REGNUM;
> +}
> +
>  /* Output assembler code to FILE to increment profiler label # LABELNO
> for profiling a function entry.  */
>  void
> @@ -22783,42 +22816,60 @@ x86_function_profiler (FILE *file, int labelno 
> ATTRIBUTE_UNUSED)
>   fprintf (file, "\tleaq\t%sP%d(%%rip), %%r11\n", LPREFIX, labelno);
>  #endif
>  
> +  int scratch;
> +  const char *reg_prefix;
> +  const char *reg;
> +
>if (!TARGET_PECOFF)
>   {
> switch (ix86_cmodel)
>   {
>   case CM_LARGE:
> -   /* NB: R10 is caller-saved.  Although it can be used as a
> -  static chain register, it is preserved when calling
> -  mcount for nested functions.  */
> +   scratch = x86_64_select_profile_regnum (true);
> +   reg = hi_reg_name[scratch];
> +   reg_prefix = LEGACY_INT_REGNO_P (scratch) ? "r" : "";
> if (ASSEMBLER_DIALECT == ASM_INTEL)
> - fprintf (file, "1:\tmovabs\tr10, OFFSET FLAT:%s\n"
> -"\tcall\tr10\n", mcount_name);
> + fprintf (file,
> +  "1:\tmovabs\t%s%s, OFFSET FLAT:%s\n"
> +  "\tcall\t%s%s\n",
> +  reg_prefix, reg, mcount_name, reg_prefix, reg);
> else
> - fprintf (file, "1:\tmovabsq\t$%s, %%r10\n\tcall\t*%%r10\n",
> -  mcount_name);
> + fprintf (file,
> +  "1:\tmovabsq\t$%s, %%%s%s\n\tcall\t*%%%s%s\n",
> +  mcount_name, reg_prefix, reg, reg_prefix, reg);
> break;
>   case CM_LARGE_PIC:
>  #ifdef NO_PROFILE_COUNTERS
> +   scratch = x86_64_select_profile_regnum (false);
> +   reg = hi_reg_name[scratch];
> +   reg_prefix = LEGACY_INT_REGNO_P (scratch) ? "r" : "";
> if (ASSEMBLER_DIALECT == ASM_INTEL)
>   {
> fprintf (file, "1:movabs\tr11, "
>"OFFSET FLAT:_GLOBAL_OFFSET_TABLE_-1b\n");
> -   fprintf (file, "\tlea\tr10, 1b[rip]\n");
> -   fprintf (file, "\tadd\tr10, r11\n");
> +   fprintf (file, "\tlea\t%s%s, 1b[rip]\n",
> +reg_prefix, reg);
> +   fprintf (file, "\tadd\t%s%s, r11\n",
> +reg_prefix, reg);
> fprintf (file, "\tmovabs\tr11, OFFSET FLAT:%s@PLTOFF\n",
>  mcount_name);
> -   fprintf (file, "\tadd\tr10, r11\n");
> -   fprintf (file, "\tcall\tr10\n");
> +   fprintf (file, "\tadd\t%s%s, r11\n",
> +reg_prefix, reg);
> +   fprintf (file, "\tcall\t%s%s\n",
> +reg_prefix, reg);
> break;
>   }
> fprintf (file,
>  "1:\tmovabsq\t$_GLOBAL_OFFSET_TABLE_-1b, %%r11\n");
> -   fprintf (file, "\tleaq\t1b(%%rip), %%r10\n");
> -   fprintf (file, "\taddq\t%%r11, %%r10\n");
> +   fprintf (file, "\tleaq\t1b(%%rip), %%%s%s\n",
> +reg_prefix, re

[PATCH] gcc: configure: Fix the optimization flags cleanup

2024-02-02 Thread Slava Barinov
Currently sed command in flag cleanup removes all the -O[0-9] flags, ignoring
the context. This leads to issues when the optimization flags is passed to
linker:

CFLAGS="-Os -Wl,-O1 -Wl,--hash-style=gnu"
is converted into
CFLAGS="-Os -Wl,-Wl,--hash-style=gnu"

Which leads to configure failure with ld: unrecognized option '-Wl,-Wl'.

gcc/
* configure.ac: Only remove -O[0-9] if not preceded with comma
* configure: Regenerated
---
 gcc/configure| 4 ++--
 gcc/configure.ac | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/gcc/configure b/gcc/configure
index c83e09beea9..fd72034cbc1 100755
--- a/gcc/configure
+++ b/gcc/configure
@@ -5472,8 +5472,8 @@ ac_compiler_gnu=$ac_cv_cxx_compiler_gnu
 # optimizations to be activated explicitly by the toplevel.
 case "$CC" in
   */prev-gcc/xgcc*) ;;
-  *) CFLAGS=`echo "$CFLAGS " | sed -e "s/-Ofast[   ]//" -e "s/-O[gs][  
]//" -e "s/-O[0-9]*[]//" `
- CXXFLAGS=`echo "$CXXFLAGS " | sed -e "s/-Ofast[   ]//" -e "s/-O[gs][  
]//" -e "s/-O[0-9]*[]//" ` ;;
+  *) CFLAGS=`echo "$CFLAGS " | sed -e "s/-Ofast[   ]//" -e "s/-O[gs][  
]//" -e "s/[^,]-O[0-9]*[]//" `
+ CXXFLAGS=`echo "$CXXFLAGS " | sed -e "s/-Ofast[   ]//" -e "s/-O[gs][  
]//" -e "s/[^,]-O[0-9]*[]//" ` ;;
 esac
 
 
diff --git a/gcc/configure.ac b/gcc/configure.ac
index 239856a4e20..d62d630d9b7 100644
--- a/gcc/configure.ac
+++ b/gcc/configure.ac
@@ -467,8 +467,8 @@ AC_LANG(C++)
 # optimizations to be activated explicitly by the toplevel.
 case "$CC" in
   */prev-gcc/xgcc*) ;;
-  *) CFLAGS=`echo "$CFLAGS " | sed -e "s/-Ofast[[  ]]//" -e "s/-O[[gs]][[  
]]//" -e "s/-O[[0-9]]*[[]]//" `
- CXXFLAGS=`echo "$CXXFLAGS " | sed -e "s/-Ofast[[  ]]//" -e "s/-O[[gs]][[  
]]//" -e "s/-O[[0-9]]*[[]]//" ` ;;
+  *) CFLAGS=`echo "$CFLAGS " | sed -e "s/-Ofast[[  ]]//" -e "s/-O[[gs]][[  
]]//" -e "s/[[^,]]-O[[0-9]]*[[  ]]//" `
+ CXXFLAGS=`echo "$CXXFLAGS " | sed -e "s/-Ofast[[  ]]//" -e "s/-O[[gs]][[  
]]//" -e "s/[[^,]]-O[[0-9]]*[[  ]]//" ` ;;
 esac
 AC_SUBST(CFLAGS)
 AC_SUBST(CXXFLAGS)
-- 
2.43.0



[pushed] testsuite, Darwin: Allow for undefined symbols in shared test.

2024-02-02 Thread Iain Sandoe
tested on i686, x86_64 Darwin, x86_64, aarch64 linux, pushed to trunk,
thanks,
Iain

--- 8< ---

Darwin's linker defaults to error on undefined (which makes it look as
if we do not support shared, leading to tests being marked incorrectly
as unsupported).

This fixes the issue by allowing the symbols used in the target
supports test to be undefined.

gcc/testsuite/ChangeLog:

* lib/target-supports.exp (check_effective_target_shared):
Allow the external symbols referenced in the test to be undefined.
---
 gcc/testsuite/lib/target-supports.exp | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/gcc/testsuite/lib/target-supports.exp 
b/gcc/testsuite/lib/target-supports.exp
index 8aefb320d8c..f66dcaac7b8 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -1385,6 +1385,13 @@ proc check_effective_target_aarch64_tlsle32 { } {
 # emitted, 0 otherwise.
 
 proc check_effective_target_shared { } {
+# Darwin's linker defaults to error on undefined (which makes it look as
+# if we do not support shared) but we can tell it to allow the symbols used
+# here to be undefined.
+set extra_flags ""
+if { [istarget *-*-darwin\[912\]*] } {
+  set extra_flags "-Wl,-U,_foo,-U,_bar"
+}
 # Note that M68K has a multilib that supports -fpic but not
 # -fPIC, so we need to check both.  We test with a program that
 # requires GOT references, and with a libc symbol that would
@@ -1397,7 +1404,7 @@ proc check_effective_target_shared { } {
char *baz (void) {
return foo () + (char*) malloc (bar);
}
-} "-shared -fpic"]
+} "-shared -fpic $extra_flags"]
 }
 
 # Return 1 if -pie, -fpie and -fPIE are supported, 0 otherwise.
-- 
2.39.2 (Apple Git-143)



Re: [PATCH] c++: Don't advertise cxx_constexpr_string_builtins [PR113658]

2024-02-02 Thread Alex Coplan
On 02/02/2024 09:34, Marek Polacek wrote:
> On Fri, Feb 02, 2024 at 10:27:23AM +, Alex Coplan wrote:
> > Bootstrapped/regtested on x86_64-apple-darwin, OK for trunk?
> > 
> > Thanks,
> > Alex
> > 
> > -- >8 --
> > 
> > When __has_feature was introduced for GCC 14, I included the feature
> > cxx_constexpr_string_builtins, since of the relevant string builtins
> > that GCC implements, it seems to support constexpr evaluation of those
> > builtins.
> > 
> > However, as the PR shows, GCC doesn't implement the full list of
> > builtins in the clang documentation.  After enumerating the builtins,
> > the clang docs [1] say:
> > 
> > > Support for constant expression evaluation for the above builtins can
> > > be detected with __has_feature(cxx_constexpr_string_builtins).
> > 
> > and a strict reading of this would suggest we can't really support
> > constexpr evaluation of a builtin if we don't implement the builtin in
> > the first place.
> > 
> > So the conservatively correct thing to do seems to be to stop
> > advertising the feature altogether to avoid failing to build code which
> > assumes the presence of this feature implies the presence of all the
> > builtins listed in the clang documentation.
> > 
> > [1] : https://clang.llvm.org/docs/LanguageExtensions.html#string-builtins
> > 
> > gcc/cp/ChangeLog:
> > 
> > PR c++/113658
> > * cp-objcp-common.cc (cp_feature_table): Remove entry for
> > cxx_constexpr_string_builtins.
> > 
> > gcc/testsuite/ChangeLog:
> > 
> > PR c++/113658
> > * g++.dg/ext/pr113658.C: New test.
> 
> > diff --git a/gcc/cp/cp-objcp-common.cc b/gcc/cp/cp-objcp-common.cc
> > index f06edf04ef0..85dde0459fa 100644
> > --- a/gcc/cp/cp-objcp-common.cc
> > +++ b/gcc/cp/cp-objcp-common.cc
> > @@ -110,7 +110,6 @@ static constexpr cp_feature_info cp_feature_table[] =
> >{ "cxx_alignof", cxx11 },
> >{ "cxx_attributes", cxx11 },
> >{ "cxx_constexpr", cxx11 },
> > -  { "cxx_constexpr_string_builtins", cxx11 },
> >{ "cxx_decltype", cxx11 },
> >{ "cxx_decltype_incomplete_return_types", cxx11 },
> >{ "cxx_default_function_template_args", cxx11 },
> > diff --git a/gcc/testsuite/g++.dg/ext/pr113658.C 
> > b/gcc/testsuite/g++.dg/ext/pr113658.C
> > new file mode 100644
> > index 000..f4a34888f28
> > --- /dev/null
> > +++ b/gcc/testsuite/g++.dg/ext/pr113658.C
> 
> Might be better to name this has-feature2.C
> 
> > @@ -0,0 +1,13 @@
> 
> Please include
> // PR c++/113658

Can do.

> 
> > +// { dg-do compile }
> > +// { dg-options "" }
> 
> Why dg-options ""?  It doesn't seem to have any purpose here.

That is to disable -pedantic-errors which IIRC is added by default in
the testsuite options.

With -pedantic-errors we would have __has_extension behaving like
__has_feature, and I wanted to check in the test that this doesn't get
reported as a feature or extension.

Incidentally it also means we don't have to provide a dummy declaration,
with -pedantic-errors we would get a warning about an empty TU which
would make the test fail.

Thanks,
Alex

> 
> > +// PR113658: we shouldn't declare support for 
> > cxx_constexpr_string_builtins as
> > +// GCC is missing some of the builtins that clang implements.
> > +
> > +#if __has_feature (cxx_constexpr_string_builtins)
> > +#error
> > +#endif
> > +
> > +#if __has_extension (cxx_constexpr_string_builtins)
> > +#error
> > +#endif
> 
> 
> Marek
> 


Re: [PATCH v2] x86-64: Find a scratch register for large model profiling

2024-02-02 Thread H.J. Lu
On Fri, Feb 2, 2024 at 4:22 AM Jakub Jelinek  wrote:
>
> On Thu, Feb 01, 2024 at 03:02:47PM -0800, H.J. Lu wrote:
> > @@ -2763,6 +2789,8 @@ construct_container (machine_mode mode, machine_mode 
> > orig_mode,
> >{
> >case X86_64_INTEGER_CLASS:
> >case X86_64_INTEGERSI_CLASS:
> > + if (!in_return)
> > +   set_int_parameter_registers_bit (intreg[0]);
> >   return gen_rtx_REG (mode, intreg[0]);
> >case X86_64_SSE_CLASS:
> >case X86_64_SSEHF_CLASS:
> > @@ -2821,6 +2849,11 @@ construct_container (machine_mode mode, machine_mode 
> > orig_mode,
> >if (mode == BLKmode)
> >   {
> > /* Use TImode for BLKmode values in 2 integer registers.  */
> > +   if (!in_return)
> > + {
> > +   set_int_parameter_registers_bit (intreg[0]);
> > +   set_int_parameter_registers_bit (intreg[1]);
> > + }
> > exp[0] = gen_rtx_EXPR_LIST (VOIDmode,
> > gen_rtx_REG (TImode, intreg[0]),
> > GEN_INT (0));
>
> Isn't the above (computed from just whether a function has such an argument)
> already available from cum->nregs or similar plus the sequence of argument
> registers?  Or df which certainly also needs to know what registers contain
> arguments?

Fixed in v4 to use df_get_live_out instead.

> Though, the above means a function argument register which isn't used in a
> function will be impossible to use for mcount.
> We certainly can use it (although var-tracking will not know it got
> clobbered).
> So, wouldn't it be better to ask at the start of prologue generation df what
> registers are live at the start of the function (i.e. at the point of the
> NOTE_INSN_PROLOG_END because rest of prologue is emitted before that) and
> remember a suitable register for the profiling there?
> > @@ -22749,6 +22789,38 @@ current_fentry_section (const char **name)
> >return true;
> >  }
> >
> > +/* Return an caller-saved register, which isn't used for parameter
> > +   passing, at entry for profile.  */
> > +
> > +static int
> > +x86_64_select_profile_regnum (bool r11_ok ATTRIBUTE_UNUSED)
> > +{
> > +  /* Use %r10 if it isn't used by DRAP.  */
> > +  bool r10_ok = !crtl->drap_reg || REGNO (crtl->drap_reg) != R10_REG;
> > +  if (r10_ok)
> > +return R10_REG;
> > +
> > +  int i;
> > +  for (i = 0; i < FIRST_PSEUDO_REGISTER; i++)
> > +if (GENERAL_REGNO_P (i)
> > + && (r10_ok || i != R10_REG)
>
> r10_ok is false here, so just
>   if (flag_fentry != 0 || !crtl->drap_reg || REGNO (crtl->drap_reg) != 
> R10_REG)
> return R10_REG;
> at the start and don't declare r10_ok.
>
> > +#ifdef NO_PROFILE_COUNTERS
> > + && (r11_ok || i != R11_REG)
> > +#else
> > + && i != R11_REG
> > +#endif
> > + && (!REX2_INT_REGNO_P (i) || TARGET_APX_EGPR)
> > + && !fixed_regs[i]
> > + && call_used_regs[i]
> > + && !test_int_parameter_registers_bit (i))
> > +  return i;
> > +
> > +  sorry ("no register available for profiling %<-mcmodel=large%s%>",
> > +  ix86_cmodel == CM_LARGE_PIC ? " -fPIC" : "");
> > +
> > +  return INVALID_REGNUM;
> > +}
> > +
> >  /* Output assembler code to FILE to increment profiler label # LABELNO
> > for profiling a function entry.  */
> >  void
> > @@ -22783,42 +22855,60 @@ x86_function_profiler (FILE *file, int labelno 
> > ATTRIBUTE_UNUSED)
> >   fprintf (file, "\tleaq\t%sP%d(%%rip), %%r11\n", LPREFIX, labelno);
> >  #endif
> >
> > +  int scratch;
> > +  const char *reg_prefix;
> > +  const char *reg;
> > +
> >if (!TARGET_PECOFF)
> >   {
> > switch (ix86_cmodel)
> >   {
> >   case CM_LARGE:
> > -   /* NB: R10 is caller-saved.  Although it can be used as a
> > -  static chain register, it is preserved when calling
> > -  mcount for nested functions.  */
> > +   scratch = x86_64_select_profile_regnum (true);
> > +   reg = hi_reg_name[scratch];
> > +   reg_prefix = LEGACY_INT_REGNO_P (scratch) ? "r" : "";
> > if (ASSEMBLER_DIALECT == ASM_INTEL)
> > - fprintf (file, "1:\tmovabs\tr10, OFFSET FLAT:%s\n"
> > -"\tcall\tr10\n", mcount_name);
> > + fprintf (file,
> > +  "1:\tmovabs\t%s%s, OFFSET FLAT:%s\n"
> > +  "\tcall\t%s%s\n",
> > +  reg_prefix, reg, mcount_name, reg_prefix, reg);
> > else
> > - fprintf (file, "1:\tmovabsq\t$%s, %%r10\n\tcall\t*%%r10\n",
> > -  mcount_name);
> > + fprintf (file,
> > +  "1:\tmovabsq\t$%s, %%%s%s\n\tcall\t*%%%s%s\n",
> > +  mcount_name, reg_prefix, reg, reg_prefix, reg);
> > break;
> >   case CM_LARGE_PIC:
> >  #ifdef NO_PROFILE_COUNTERS
> > +   scratch = x86_64_select_profile_regnum (false);
> > +   reg = hi_reg_name[scratch];
> > 

[PATCH v4] x86-64: Find a scratch register for large model profiling

2024-02-02 Thread H.J. Lu
Changes in v4:

1. Remove pr113689-2.c.
2. Use df_get_live_out.

Changes in v3:

1. Remove r10_ok.

Changes in v2:

1. Add int_parameter_registers to machine_function to track integer
registers used for parameter passing.
2. Update x86_64_select_profile_regnum to try %r10 first and use an
caller-saved register, which isn't used for parameter passing.

---
2 scratch registers, %r10 and %r11, are available at function entry for
large model profiling.  But %r10 may be used by stack realignment and we
can't use %r10 in this case.  Add x86_64_select_profile_regnum to find
an caller-saved register, which isn't live, at entry for large model
profiling and sorry if we can't find one.

gcc/

PR target/113689
* config/i386/i386.cc (x86_64_select_profile_regnum): New.
(x86_function_profiler): Call x86_64_select_profile_regnum to
get a scratch register for large model profiling.
* config/i386/i386.h (machine_function): Add
int_parameter_registers.

gcc/testsuite/

PR target/113689
* gcc.target/i386/pr113689-1.c: New file.
* gcc.target/i386/pr113689-2.c: Likewise.
---
 gcc/config/i386/i386.cc| 81 ++
 gcc/testsuite/gcc.target/i386/pr113689-1.c | 49 +
 gcc/testsuite/gcc.target/i386/pr113689-2.c | 41 +++
 3 files changed, 156 insertions(+), 15 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/i386/pr113689-1.c
 create mode 100644 gcc/testsuite/gcc.target/i386/pr113689-2.c

diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc
index b3e7c74846e..b27445b8371 100644
--- a/gcc/config/i386/i386.cc
+++ b/gcc/config/i386/i386.cc
@@ -22749,6 +22749,39 @@ current_fentry_section (const char **name)
   return true;
 }
 
+/* Return an caller-saved register, which isn't live, at entry for
+   profile.  */
+
+static int
+x86_64_select_profile_regnum (bool r11_ok ATTRIBUTE_UNUSED)
+{
+  /* Use %r10 if it isn't used by DRAP.  */
+  if (!crtl->drap_reg || REGNO (crtl->drap_reg) != R10_REG)
+return R10_REG;
+
+  bitmap reg_live = df_get_live_out (ENTRY_BLOCK_PTR_FOR_FN (cfun));
+
+  int i;
+  for (i = 0; i < FIRST_PSEUDO_REGISTER; i++)
+if (GENERAL_REGNO_P (i)
+   && i != R10_REG
+#ifdef NO_PROFILE_COUNTERS
+   && (r11_ok || i != R11_REG)
+#else
+   && i != R11_REG
+#endif
+   && (!REX2_INT_REGNO_P (i) || TARGET_APX_EGPR)
+   && !fixed_regs[i]
+   && call_used_regs[i]
+   && !REGNO_REG_SET_P (reg_live, i))
+  return i;
+
+  sorry ("no register available for profiling %<-mcmodel=large%s%>",
+ix86_cmodel == CM_LARGE_PIC ? " -fPIC" : "");
+
+  return INVALID_REGNUM;
+}
+
 /* Output assembler code to FILE to increment profiler label # LABELNO
for profiling a function entry.  */
 void
@@ -22783,42 +22816,60 @@ x86_function_profiler (FILE *file, int labelno 
ATTRIBUTE_UNUSED)
fprintf (file, "\tleaq\t%sP%d(%%rip), %%r11\n", LPREFIX, labelno);
 #endif
 
+  int scratch;
+  const char *reg_prefix;
+  const char *reg;
+
   if (!TARGET_PECOFF)
{
  switch (ix86_cmodel)
{
case CM_LARGE:
- /* NB: R10 is caller-saved.  Although it can be used as a
-static chain register, it is preserved when calling
-mcount for nested functions.  */
+ scratch = x86_64_select_profile_regnum (true);
+ reg = hi_reg_name[scratch];
+ reg_prefix = LEGACY_INT_REGNO_P (scratch) ? "r" : "";
  if (ASSEMBLER_DIALECT == ASM_INTEL)
-   fprintf (file, "1:\tmovabs\tr10, OFFSET FLAT:%s\n"
-  "\tcall\tr10\n", mcount_name);
+   fprintf (file,
+"1:\tmovabs\t%s%s, OFFSET FLAT:%s\n"
+"\tcall\t%s%s\n",
+reg_prefix, reg, mcount_name, reg_prefix, reg);
  else
-   fprintf (file, "1:\tmovabsq\t$%s, %%r10\n\tcall\t*%%r10\n",
-mcount_name);
+   fprintf (file,
+"1:\tmovabsq\t$%s, %%%s%s\n\tcall\t*%%%s%s\n",
+mcount_name, reg_prefix, reg, reg_prefix, reg);
  break;
case CM_LARGE_PIC:
 #ifdef NO_PROFILE_COUNTERS
+ scratch = x86_64_select_profile_regnum (false);
+ reg = hi_reg_name[scratch];
+ reg_prefix = LEGACY_INT_REGNO_P (scratch) ? "r" : "";
  if (ASSEMBLER_DIALECT == ASM_INTEL)
{
  fprintf (file, "1:movabs\tr11, "
 "OFFSET FLAT:_GLOBAL_OFFSET_TABLE_-1b\n");
- fprintf (file, "\tlea\tr10, 1b[rip]\n");
- fprintf (file, "\tadd\tr10, r11\n");
+ fprintf (file, "\tlea\t%s%s, 1b[rip]\n",
+  reg_prefix, reg);
+ fprintf (file, "\tadd\t%s%s, r11\n",
+  reg_prefix, reg);
 

Re: [PATCH 1/2] libdecnumber: fixed undefined behavior in `decFloatFMA`

2024-02-02 Thread Jakub Jelinek
On Fri, Feb 02, 2024 at 04:32:09PM +0100, Jakub Jelinek wrote:
> Anyway, I think all of
> decBasic.c: for (; UBTOUI(umsd)==0 && umsd+3 decBasic.c: for (; *umsd==0 && umsd decBasic.c:  for (; UBTOUI(hi->msd)==0 && hi->msd+3lsd;) hi->msd+=4;
> decBasic.c:  for (; *hi->msd==0 && hi->msdlsd;) hi->msd++;
> decBasic.c:  for (; UBTOUI(lo->msd)==0 && lo->msd+3lsd;) lo->msd+=4;
> decBasic.c:  for (; *lo->msd==0 && lo->msdlsd;) lo->msd++;
> decBasic.c:  for (; UBTOUI(lo->msd)==0 && lo->msd+3lsd;) lo->msd+=4;
> decBasic.c:  for (; *lo->msd==0 && lo->msdlsd;) lo->msd++;
> decCommon.c:  for (; *umsd==0 && umsd=lsua;) msua--;
decBasic.c:if (*msua==0 && msua==lsua) break;
decCommon.c:  if (*ulsd==0 && ulsd==umsd) { /* have zero */
decNumber.c:for (; *msu1==0 && msu1>var1; msu1--) var1units--;
too just from simple grep.

Jakub



Re: [PATCH 1/2] libdecnumber: fixed undefined behavior in `decFloatFMA`

2024-02-02 Thread Jakub Jelinek
On Fri, Feb 02, 2024 at 10:09:05AM -0500, Ian McCormack wrote:
> This patch fixes a minor instance of undefined behavior in libdecnumber. It 
> was discovered in the Rust bindings for libdecnumber (`dec`) using a custom 
> version of MIRI that can execute foreign functions.
> 
> Within the function `decFloatFMA`, the pointer `lo->msd` is initialized to 
> point to a byte array of size 56. 
> 
> ```
> uByte  acc[FMALEN];  /* for multiplied coefficient in BCD */
> ...
> ub=acc+FMALEN-1; /* where lsd of result will go */
> ...
> lo->msd=ub+1;
> lo->lsd=acc+FMALEN-1;
> ```
> However, `lo->msd` is then offset in increments of 4, which leads to a read 
> of two bytes beyond the size of `acc`. This patch switches to reading in 
> increments of 2 instead of 4.
> 
> Bootstrapped on x86_64-pc-linux-gnu with no regressions.
> 
> libdecnumber/ChangeLog
>* decBasic.c: Increment `lo->msd` by 2 instead of 4 in `decFloatFMA` 
> to avoid undefined behavior.

Isn't 56 divisible by 4?
Anyway, I think all of
decBasic.c:   for (; UBTOUI(umsd)==0 && umsd+3msd)==0 && hi->msd+3lsd;) hi->msd+=4;
decBasic.c:  for (; *hi->msd==0 && hi->msdlsd;) hi->msd++;
decBasic.c:  for (; UBTOUI(lo->msd)==0 && lo->msd+3lsd;) lo->msd+=4;
decBasic.c:  for (; *lo->msd==0 && lo->msdlsd;) lo->msd++;
decBasic.c:  for (; UBTOUI(lo->msd)==0 && lo->msd+3lsd;) lo->msd+=4;
decBasic.c:  for (; *lo->msd==0 && lo->msdlsd;) lo->msd++;
decCommon.c:  for (; *umsd==0 && umsd

[PATCH] testsuite: Fix c-c++-common/pr103798-2.c on Solaris [PR113706]

2024-02-02 Thread Rainer Orth
c-c++-common/pr103798-2.c FAILs on Solaris when compiled as C++:

FAIL: c-c++-common/pr103798-2.c  -std=gnu++14  scan-assembler-not memchr
FAIL: c-c++-common/pr103798-2.c  -std=gnu++17  scan-assembler-not memchr
FAIL: c-c++-common/pr103798-2.c  -std=gnu++20  scan-assembler-not memchr
FAIL: c-c++-common/pr103798-2.c  -std=gnu++98  scan-assembler-not memchr

As H.J. analyzed in the PR, Solaris  declares std::memchr, not
memchr, which isn't treated as __builtin_memchr.

To avoid this, this patch declares memchr directly instead of including
.

Tested on i386-pc-solaris2.11, sparc-sun-solaris2.11, and
i686-pc-linux-gnu.

Ok for trunk?

Rainer

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


2024-02-01  Rainer Orth  

gcc/testsuite:
PR tree-optimization/113706
* c-c++-common/pr103798-2.c (NULL): Define.
(size_t, memchr): Declare instead of including .

# HG changeset patch
# Parent  943813561aef290adb442042f9c4fecd82ee
testsuite: Fix c-c++-common/pr103798-2.c on Solaris [PR113706]

diff --git a/gcc/testsuite/c-c++-common/pr103798-2.c b/gcc/testsuite/c-c++-common/pr103798-2.c
--- a/gcc/testsuite/c-c++-common/pr103798-2.c
+++ b/gcc/testsuite/c-c++-common/pr103798-2.c
@@ -1,7 +1,16 @@
 /* { dg-do run } */
 /* { dg-options "-O2 -fdump-tree-optimized -save-temps" } */
 
-#include 
+#define NULL ((void *) 0)
+
+typedef __SIZE_TYPE__ size_t;
+#ifdef __cplusplus
+extern "C" {
+#endif
+extern void *memchr (const void *, int, size_t);
+#ifdef __cplusplus
+}
+#endif
 
 __attribute__ ((weak))
 int


Re: [PATCH 1/2] bitint: Use TARGET_ARRAY_MODE for large bitints where target supports it

2024-02-02 Thread Jakub Jelinek
On Thu, Jan 25, 2024 at 05:45:00PM +, Andre Vieira wrote:
> 
> This patch ensures we use TARGET_ARRAY_MODE to determine the storage mode of
> large bitints that are represented as arrays in memory.  This is required to
> support such bitints for aarch64 and potential other targets with similar
> bitint specifications.  Existing tests like gcc.dg/torture/bitint-25.c are
> affected by this for aarch64 targets.
> 
> gcc/ChangeLog:
>   stor-layout.cc (layout_type): Use TARGET_ARRAY_MODE for large bitints
>   for targets that implement it.

I thought this has been resolved by the r14-8275 change.
Do you really need it for something?
I've tried
make check-gcc -j32 -k GCC_TEST_RUN_EXPENSIVE=1 
RUNTESTFLAGS="GCC_TEST_RUN_EXPENSIVE=1 dg.exp='*bitint* pr112673.c 
builtin-stdc-bit-*.c pr112566-2.c pr112511.c' dg-torture.exp=*bitint* 
dfp.exp=*bitint*"
in a x86_64 -> aarch64-linux cross with your other patch but not this one
and didn't see any ICEs (note, as I didn't have any aarch64 libc around,
all tests fail during linking).

I think BITINT_TYPE mode really should be that of a struct containing that
many limb elements rather than of an array and this patch doesn't match
that.

> diff --git a/gcc/stor-layout.cc b/gcc/stor-layout.cc
> index 4cf249133e9..31da2c123ab 100644
> --- a/gcc/stor-layout.cc
> +++ b/gcc/stor-layout.cc
> @@ -2427,8 +2427,16 @@ layout_type (tree type)
> }
>   else
> {
> - SET_TYPE_MODE (type, BLKmode);
>   cnt = CEIL (TYPE_PRECISION (type), GET_MODE_PRECISION (limb_mode));
> + machine_mode mode;
> + /* Some targets use TARGET_ARRAY_MODE to select the mode they use
> +for arrays with a specific element mode and a specific element
> +count and we should use this mode for large bitints that are
> +stored as such arrays.  */
> + if (!targetm.array_mode (limb_mode, cnt).exists (&mode)
> + || !targetm.array_mode_supported_p (limb_mode, cnt))
> +   mode = BLKmode;
> + SET_TYPE_MODE (type, mode);
>   gcc_assert (info.abi_limb_mode == info.limb_mode
>   || !info.big_endian == !WORDS_BIG_ENDIAN);
> }


Jakub



[PATCH 2/2] libdecnumber: fixed undefined behavior in decNumberGetBCD.

2024-02-02 Thread Ian McCormack
This patch fixes a minor instance of undefined behavior in libdecnumber. It was 
discovered in the Rust bindings for libdecnumber (`dec`) using a custom version 
of MIRI that can execute foreign functions.

On the last iteration of the `while` loop in `decNumberGetBCD`, the pointer 
`up` will be incremented beyond the end of the allocation `dn->lsu` before the 
assignment `u=*up`. This value does not affect the termination of the loop and 
is never read again, so this isn't really an issue, but this patch prevent an 
access out-of-bounds by only incrementing `up` if it is safe to do so.

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

libdecnumber/ChangeLog
   * decNumber.c: In `decNumberGetBCD`, only read from `dn->lsu` while the 
pointer `up` is still within bounds.

---
 libdecnumber/decNumber.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libdecnumber/decNumber.c b/libdecnumber/decNumber.c
index 0b6eb160fe3..094bc51c14a 100644
--- a/libdecnumber/decNumber.c
+++ b/libdecnumber/decNumber.c
@@ -3463,7 +3463,8 @@ uByte * decNumberGetBCD(const decNumber *dn, uByte *bcd) {
   cut--;
   if (cut>0) continue;/* more in this unit */
   up++;
-  u=*up;
+  if (ub > bcd)
+u=*up;
   cut=DECDPUN;
   }
   #endif
-- 
2.39.3 (Apple Git-145)



[PATCH 1/2] libdecnumber: fixed undefined behavior in `decFloatFMA`

2024-02-02 Thread Ian McCormack
This patch fixes a minor instance of undefined behavior in libdecnumber. It was 
discovered in the Rust bindings for libdecnumber (`dec`) using a custom version 
of MIRI that can execute foreign functions.

Within the function `decFloatFMA`, the pointer `lo->msd` is initialized to 
point to a byte array of size 56. 

```
uByte  acc[FMALEN];/* for multiplied coefficient in BCD */
...
ub=acc+FMALEN-1;   /* where lsd of result will go */
...
lo->msd=ub+1;
lo->lsd=acc+FMALEN-1;
```
However, `lo->msd` is then offset in increments of 4, which leads to a read of 
two bytes beyond the size of `acc`. This patch switches to reading in 
increments of 2 instead of 4.

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

libdecnumber/ChangeLog
   * decBasic.c: Increment `lo->msd` by 2 instead of 4 in `decFloatFMA` to 
avoid undefined behavior.

---
 libdecnumber/decBasic.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libdecnumber/decBasic.c b/libdecnumber/decBasic.c
index 6319f66b25d..3c8d71a2949 100644
--- a/libdecnumber/decBasic.c
+++ b/libdecnumber/decBasic.c
@@ -2023,6 +2023,7 @@ decFloat * decFloatFMA(decFloat *result, const decFloat 
*dfl,
   uInt  carry;/* +1 for ten's complement and during add */
   uByte  *ub, *uh, *ul;   /* work */
   uInt  uiwork;   /* for macros */
+  uShort uswork;
 
   /* handle all the special values [any special operand leads to a */
   /* special result] */
@@ -2252,7 +2253,7 @@ decFloat * decFloatFMA(decFloat *result, const decFloat 
*dfl,
   /* all done except for the special IEEE 754 exact-zero-result */
   /* rule (see above); while testing for zero, strip leading */
   /* zeros (which will save decFinalize doing it) */
-  for (; UBTOUI(lo->msd)==0 && lo->msd+3lsd;) lo->msd+=4;
+  for (; UBTOUS(lo->msd)==0 && lo->msd+1lsd;) lo->msd+=2;
   for (; *lo->msd==0 && lo->msdlsd;) lo->msd++;
   if (*lo->msd==0) {  /* must be true zero (and diffsign) */
lo->sign=0;/* assume + */
-- 
2.39.3 (Apple Git-145)



Re: [PATCH v4 4/5] Add tests for C/C++ musttail attributes

2024-02-02 Thread Andi Kleen
> Sorry, I wasn't clear about this in previous patch -- noipa will
> subsume other ipa attributes,
> so there's no need to have noinline, noclone along with noipa.
> int __attribute__((noipa)) callee(int i) should be sufficient for
> disabling IPA optimizations involving callee.

I thought you were worried about extra IPA optimizations. I prefer to
clearly say what I mean (besides it was just copied from existing
tests), so the verbose form is better. So if e.g. gcc ever re-adds the old
RTL inliner it wouldn't break. 

-Andi



Re: Updated musttail patches

2024-02-02 Thread Andi Kleen
On Fri, Feb 02, 2024 at 01:18:06PM +, Joseph Myers wrote:
> On Fri, 2 Feb 2024, Andi Kleen wrote:
> 
> > This patchkit implements a [[musttail]] attribute for C/C++.
> > 
> > v4:
> > Addressed all feedback except clang::musttail is still supported
> > (I don't want to force an #ifdef to most users) and I'm also still
> 
> I'm fine with supporting [[clang::musttail]].  What shouldn't be supported 
> is plain unnamespaced [[musttail]], at least for C, and I don't see any 

It's unsupported since v4 ("" -> "gnu" for the lookups) 

> tests that that's not supported (there are tests of [[musttail]] on things 
> that aren't returns, but that's mixing two different issues - 
> [[gnu::musttail]] shouldn't be accepted on non-returns, while [[musttail]] 
> shouldn't be accepted anywhere, including on returns, because it's not a 
> standard attribute).

I added some extra tests for this  (passing)

diff --git a/gcc/testsuite/c-c++-common/musttail5.c 
b/gcc/testsuite/c-c++-common/musttail5.c
index 71f4de40fc6d..7938e7ff80e4 100644
--- a/gcc/testsuite/c-c++-common/musttail5.c
+++ b/gcc/testsuite/c-c++-common/musttail5.c
@@ -19,7 +19,10 @@ int foo2(int p)
 
 int i;
 
-void foo3(void)
+int foo3(void)
 {
   [[musttail]] i++; /* { dg-warning "attribute" } */
+  [[musttail]] if (i > 10) /* { dg-warning "attribute" } */
+[[musttail]] return foo2(i); /* { dg-warning "attribute" } */
+  return 0;
 }




Re: [PATCH 2/2] aarch64: Add support for _BitInt

2024-02-02 Thread Jakub Jelinek
On Thu, Jan 25, 2024 at 05:45:01PM +, Andre Vieira wrote:
> This patch adds support for C23's _BitInt for the AArch64 port when compiling
> for little endianness.  Big Endianness requires further target-agnostic
> support and we therefor disable it for now.
> 
> gcc/ChangeLog:
> 
>   * config/aarch64/aarch64.cc (TARGET_C_BITINT_TYPE_INFO): Declare MACRO.
>   (aarch64_bitint_type_info): New function.
>   (aarch64_return_in_memory_1): Return large _BitInt's in memory.
>   (aarch64_function_arg_alignment): Adapt to correctly return the ABI
>   mandated alignment of _BitInt(N) where N > 128 as the alignment of
>   TImode.
>   (aarch64_composite_type_p): Return true for _BitInt(N), where N > 128.
> 
> libgcc/ChangeLog:
> 
>   * config/aarch64/t-softfp: Add fixtfbitint, floatbitinttf and
>   floatbitinthf to the softfp_extras variable to ensure the
>   runtime support is available for _BitInt.

I think this lacks some config/aarch64/t-whatever.ver
additions.
See PR113700 for some more details.
We want the support routines for binary floating point <-> _BitInt
conversions in both libgcc.a and libgcc_s.so.1 and exported from the latter
too at GCC_14.0.0 symver, while decimal floating point <-> _BitInt solely in
libgcc.a (as with all the huge dfp/bid stuff).

Jakub



Re: [PATCH] libgcc: Include stdlib.h for abort() on mingw32

2024-02-02 Thread Jeff Law




On 1/30/24 10:04, Khem Raj wrote:

libgcc/
 * config/i386/enable-execute-stack-mingw32.c: Include
 stdlib.h for abort() definition.

Thanks.  Pushed to the trunk.
jeff


[committed] libstdc++: Make std::function deduction guide support explicit object functions [PR113335]

2024-02-02 Thread Jonathan Wakely
Teted x86_64-linux. Pushed to trunk.

-- >8 --

This makes the deduction guides for std::function and std::packaged_task
work for explicit object member functions, i.e. "deducing this", as per
LWG 3617.

libstdc++-v3/ChangeLog:

PR libstdc++/113335
* include/bits/std_function.h (__function_guide_helper): Add
partial specialization for explicit object member functions, as
per LWG 3617.
* testsuite/20_util/function/cons/deduction_c++23.cc: Check
explicit object member functions.
* testsuite/30_threads/packaged_task/cons/deduction_c++23.cc:
Likewise.
---
 libstdc++-v3/include/bits/std_function.h  |  6 
 .../20_util/function/cons/deduction_c++23.cc  | 35 +++
 .../packaged_task/cons/deduction_c++23.cc | 35 +++
 3 files changed, 76 insertions(+)

diff --git a/libstdc++-v3/include/bits/std_function.h 
b/libstdc++-v3/include/bits/std_function.h
index 9130f9d28e3..79b59466fe9 100644
--- a/libstdc++-v3/include/bits/std_function.h
+++ b/libstdc++-v3/include/bits/std_function.h
@@ -697,6 +697,12 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 >
 { using type = _Res(_Args...); };
 
+#if __cpp_explicit_this_parameter >= 202110L
+  template
+struct __function_guide_helper<_Res (*) (_Tp, _Args...) noexcept(_Nx)>
+{ using type = _Res(_Args...); };
+#endif
+
 #if __cpp_static_call_operator >= 202207L && __cpp_concepts >= 202002L
   template
 struct __function_guide_static_helper
diff --git a/libstdc++-v3/testsuite/20_util/function/cons/deduction_c++23.cc 
b/libstdc++-v3/testsuite/20_util/function/cons/deduction_c++23.cc
index 132bfb8fbfe..8c70c102929 100644
--- a/libstdc++-v3/testsuite/20_util/function/cons/deduction_c++23.cc
+++ b/libstdc++-v3/testsuite/20_util/function/cons/deduction_c++23.cc
@@ -21,3 +21,38 @@ test_static_call_operator()
   std::function func2 = F2{};
   check_type>(func2);
 }
+
+void
+test_explicit_object_call_operator()
+{
+  // LWG 3617 - function/packaged_task deduction guides and deducing this
+  struct F {
+int operator()(this const F&) { return 42; }
+  };
+
+  std::function g = F{};
+  check_type>(g);
+
+  struct F2 {
+short operator()(this F2&, float&) { return 0; }
+  };
+
+  std::function g2 = F2{};
+  check_type>(g2);
+
+  struct F3 {
+void operator()(this const F3, char*, long) { }
+  };
+
+  std::function g3 = F3{};
+  check_type>(g3);
+
+  struct F4 {
+int i;
+operator const int&() const { return i; }
+const long& operator()(this int, const long& l) { return l; }
+  };
+
+  std::function g4 = F4{};
+  check_type>(g4);
+}
diff --git 
a/libstdc++-v3/testsuite/30_threads/packaged_task/cons/deduction_c++23.cc 
b/libstdc++-v3/testsuite/30_threads/packaged_task/cons/deduction_c++23.cc
index 6a43cf945d8..307522a73f5 100644
--- a/libstdc++-v3/testsuite/30_threads/packaged_task/cons/deduction_c++23.cc
+++ b/libstdc++-v3/testsuite/30_threads/packaged_task/cons/deduction_c++23.cc
@@ -20,3 +20,38 @@ test_static_call_operator()
   std::packaged_task task2{ F2{} };
   check_type>(task2);
 }
+
+void
+test_explicit_object_call_operator()
+{
+  // LWG 3617 - function/packaged_task deduction guides and deducing this
+  struct F {
+int operator()(this const F&) { return 42; }
+  };
+
+  std::packaged_task g{ F{} };
+  check_type>(g);
+
+  struct F2 {
+short operator()(this F2&, float&) { return 0; }
+  };
+
+  std::packaged_task g2{ F2{} };
+  check_type>(g2);
+
+  struct F3 {
+void operator()(this const F3, char*, long) { }
+  };
+
+  std::packaged_task g3{ F3{} };
+  check_type>(g3);
+
+  struct F4 {
+int i;
+operator const int&() const { return i; }
+const long& operator()(this int, const long& l) { return l; }
+  };
+
+  std::packaged_task g4{ F4{} };
+  check_type>(g4);
+}
-- 
2.43.0



Re: [PATCH 2/2] rtl-optimization/113255 - avoid re-associating REG_POINTER MINUS

2024-02-02 Thread Jeff Law




On 2/1/24 07:20, Richard Biener wrote:

The following avoids re-associating

  (minus:DI (reg/f:DI 119)
 (minus:DI (reg/f:DI 120)
 (reg/f:DI 114)))

into

  (minus:DI (plus:DI (reg/f:DI 114)
 (reg/f:DI 119))
 (reg/f:DI 120))

as that possibly confuses the REG_POINTER heuristics of RTL
alias analysis.  This happens to miscompile the PRs testcase
during DSE which expands addresses via CSELIB which eventually
simplifies what it substituted to.  The original code does
the innocent ptr - (ptr2 - ptr2'), bias a pointer by the
difference of two other pointers.

--

This is what I propose for the PR for branches, I have not made much
progress with fixing the fallout on the RTL alias analysis change
on trunk, so this is the alternative if we decide to revert that.

Bootstrapped and tested on x86_64-unknown-linux-gnu on the gcc-13
branch, bootstrapped after reverting of the previous fix on
x86_64-unknown-linux-gnu on trunk, testing is still ongoing there.

OK?  Any preference for trunk?

Thanks,
Richard.

PR rtl-optimization/113255
* simplify-rtx.cc (simplify_context::simplify_binary_operation_1):
Do not re-associate a MINUS with a REG_POINTER op0.
Nasty little set of problems.  I don't think we ever pondered that we 
could have multiple REGNO_POINTER_FLAG objects in the same expression, 
but clearly that can happen once you introduce a 3rd term in the expression.


I don't mind avoiding the reassociation, but it feels like we're 
papering over problems in alias.cc.  Conceptually it seems like if we 
have two objects with REG_POINTER set, then we can't know which one is 
the real base.  So your patch in the PR wasn't that bad.


Alternately, just stop using REG_POINTER for alias analysis?   It looks 
fundamentally flawed to me in that context.  In fact, one might argue 
that the only legitimate use would be to indicate to the target that we 
know a pointer points into an object.  Some targets (the PA) need this 
because x + y is not the same as y + x when used as a memory address.


If we wanted to be a bit more surgical, drop REG_POINTER from just the 
MINUS handling in alias.cc?


Jeff


Re: [PATCH] c++: Don't advertise cxx_constexpr_string_builtins [PR113658]

2024-02-02 Thread Marek Polacek
On Fri, Feb 02, 2024 at 10:27:23AM +, Alex Coplan wrote:
> Bootstrapped/regtested on x86_64-apple-darwin, OK for trunk?
> 
> Thanks,
> Alex
> 
> -- >8 --
> 
> When __has_feature was introduced for GCC 14, I included the feature
> cxx_constexpr_string_builtins, since of the relevant string builtins
> that GCC implements, it seems to support constexpr evaluation of those
> builtins.
> 
> However, as the PR shows, GCC doesn't implement the full list of
> builtins in the clang documentation.  After enumerating the builtins,
> the clang docs [1] say:
> 
> > Support for constant expression evaluation for the above builtins can
> > be detected with __has_feature(cxx_constexpr_string_builtins).
> 
> and a strict reading of this would suggest we can't really support
> constexpr evaluation of a builtin if we don't implement the builtin in
> the first place.
> 
> So the conservatively correct thing to do seems to be to stop
> advertising the feature altogether to avoid failing to build code which
> assumes the presence of this feature implies the presence of all the
> builtins listed in the clang documentation.
> 
> [1] : https://clang.llvm.org/docs/LanguageExtensions.html#string-builtins
> 
> gcc/cp/ChangeLog:
> 
>   PR c++/113658
>   * cp-objcp-common.cc (cp_feature_table): Remove entry for
>   cxx_constexpr_string_builtins.
> 
> gcc/testsuite/ChangeLog:
> 
>   PR c++/113658
>   * g++.dg/ext/pr113658.C: New test.

> diff --git a/gcc/cp/cp-objcp-common.cc b/gcc/cp/cp-objcp-common.cc
> index f06edf04ef0..85dde0459fa 100644
> --- a/gcc/cp/cp-objcp-common.cc
> +++ b/gcc/cp/cp-objcp-common.cc
> @@ -110,7 +110,6 @@ static constexpr cp_feature_info cp_feature_table[] =
>{ "cxx_alignof", cxx11 },
>{ "cxx_attributes", cxx11 },
>{ "cxx_constexpr", cxx11 },
> -  { "cxx_constexpr_string_builtins", cxx11 },
>{ "cxx_decltype", cxx11 },
>{ "cxx_decltype_incomplete_return_types", cxx11 },
>{ "cxx_default_function_template_args", cxx11 },
> diff --git a/gcc/testsuite/g++.dg/ext/pr113658.C 
> b/gcc/testsuite/g++.dg/ext/pr113658.C
> new file mode 100644
> index 000..f4a34888f28
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/ext/pr113658.C

Might be better to name this has-feature2.C

> @@ -0,0 +1,13 @@

Please include
// PR c++/113658

> +// { dg-do compile }
> +// { dg-options "" }

Why dg-options ""?  It doesn't seem to have any purpose here.

> +// PR113658: we shouldn't declare support for cxx_constexpr_string_builtins 
> as
> +// GCC is missing some of the builtins that clang implements.
> +
> +#if __has_feature (cxx_constexpr_string_builtins)
> +#error
> +#endif
> +
> +#if __has_extension (cxx_constexpr_string_builtins)
> +#error
> +#endif


Marek



Re: [PATCH] Fix some of vect-avg-*.c testcases

2024-02-02 Thread Jeff Law




On 1/29/24 22:19, Andrew Pinski wrote:

The vect-avg-*.c testcases are trying to make sure
the AVG internal function are used and not
doing promotion to `vector unsigned short`
but when V4QI is implemented, `vector(2) unsigned short`
shows up in the detail dump file and causes the failure.
To fix this checking the optimized dump instead of the vect dump
for `vector unsigned short` to make sure the vectorizer does not
do the promotion.

Built and tested for aarch64-linux-gnu.

gcc/testsuite/ChangeLog:

* gcc.dg/vect/vect-avg-1.c: Check optimized dump
for `vector *signed short` instead of the `vect` dump.
* gcc.dg/vect/vect-avg-11.c: Likewise.
* gcc.dg/vect/vect-avg-12.c: Likewise.
* gcc.dg/vect/vect-avg-13.c: Likewise.
* gcc.dg/vect/vect-avg-14.c: Likewise.
* gcc.dg/vect/vect-avg-2.c: Likewise.
* gcc.dg/vect/vect-avg-3.c: Likewise.
* gcc.dg/vect/vect-avg-4.c: Likewise.
* gcc.dg/vect/vect-avg-5.c: Likewise.
* gcc.dg/vect/vect-avg-6.c: Likewise.
* gcc.dg/vect/vect-avg-7.c: Likewise.
* gcc.dg/vect/vect-avg-8.c: Likewise.
Presumably any dump after vectorization is done, perhaps without details 
would work and be (marginally) better than waiting until .optimized 
since passes between vect and the end of the gimple pipeline could be 
making other changes spoiling the verification you're trying to do.  I 
don't see that as likely though.  So I'm OK with this on the trunk.


jeff


Re: [PATCH] testsuite, ubsan: Add libstdc++ deps where required.

2024-02-02 Thread Jeff Law




On 1/30/24 03:31, Iain Sandoe wrote:

tested on i686, x86_64 (and aarch64) Darwin, x86_64, aarch64 Linux,
OK for trunk?
thanks
Iain

--- 8< ---

We use the ubsan tests from both C, C++, D and Fortran.
the sanitizer libraries link to libstdc++.

When we are using the C/gdc/gfortran driver, and the target might
require a path to the libstdc++ (e.g. for handing -static- or
for embedded runpaths), we need to add a suitable option (or we get
fails at execution time because of the missing paths).

Conversely, we do not want to add multiple instances of these
paths (since that leads to failures on tools that report warnings
for duplicate runpaths).

This patch modifies the _init function to allow a sigle parameter
that determines whether the *asan_init should add a path for
libstdc++ (yes for C driver, no for C++ driver).
gcc/testsuite/ChangeLog:

* g++.dg/ubsan/ubsan.exp:Add a parameter to init to say that
we expect the C++ driver to provide paths for libstdc++.
* gcc.dg/ubsan/ubsan.exp: Add a parameter to init to say that
we need a path added for libstdc++.
* gdc.dg/ubsan/ubsan.exp: Likewise.
* gfortran.dg/ubsan/ubsan.exp: Likewise.
* lib/ubsan-dg.exp: Handle a single parameter to init that
requests addition of a path to libstdc++ to link flags.

Also OK.
jeff


Re: [PATCH] testsuite, asan, hwsan: Add libstdc++ deps where required.

2024-02-02 Thread Jeff Law




On 1/30/24 03:30, Iain Sandoe wrote:

tested on i686, x86_64 (and aarch64) Darwin, x86_64, aarch64 Linux,
OK for trunk?
thanks
Iain

--- 8< ---

We use the shared asan/hwasan from both C,C++,D and Fortran.
The sanitizer libraries link to libstdc++.

When we are using the C/gdc/gfortran driver, and the target might
require a path to the libstdc++ (e.g. for handing -static- or
for embedded runpaths), we need to add a suitable option (or we get
fails at execution time because of the missing paths).

Conversely, we do not want to add multiple instances of these
paths (since that leads to failures on tools that report warnings
for duplicate runpaths).

This patch modifies the _init function to allow a single parameter
that determines whether the *asan_init should add a path for
libstdc++ (yes for C driver, no for C++ driver).

gcc/testsuite/ChangeLog:

* g++.dg/asan/asan.exp: Add a parameter to init to say that
we expect the C++ driver to provide paths for libstdc++.
* g++.dg/hwasan/hwasan.exp: Likewise
* gcc.dg/asan/asan.exp: Add a parameter to init to say that
we need a path added for libstdc++.
* gcc.dg/hwasan/hwasan.exp: Likewise.
* gdc.dg/asan/asan.exp: Likewise.
* gfortran.dg/asan/asan.exp: Likewise.
* lib/asan-dg.exp: Handle a single parameter to init that
requests addition of a path to libstdc++ to link flags.
* lib/hwasan-dg.exp: Likewise.
OK.  I don't think we really need to wait for the sanitizer folks to 
chime in.  This is just getting the link bits right, not twiddling the 
sanitizer itself.


jeff


[committed] libstdc++: Fix experimental/names.cc failure on AIX

2024-02-02 Thread Jonathan Wakely
Tested x86_64-linux and powerpc-ibm-aix7.3.1.0. Pushed to trunk.

-- >8 --

This fails due to "u" being used in a system header.

FAIL: experimental/names.cc  -std=gnu++17 (test for excess errors)
Excess errors:
/usr/include/sys/poll.h:77: error: expected unqualified-id before ';' token
/usr/include/sys/poll.h:77: error: expected ')' before ';' token

FAIL: experimental/names.cc  -std=gnu++17 (test for excess errors)
Excess errors:
/usr/include/sys/poll.h:102: error: expected unqualified-id before ';' token
/usr/include/sys/poll.h:102: error: expected ')' before ';' token

libstdc++-v3/ChangeLog:

* testsuite/17_intro/names.cc [_AIX]: Undefine "u".
---
 libstdc++-v3/testsuite/17_intro/names.cc | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/libstdc++-v3/testsuite/17_intro/names.cc 
b/libstdc++-v3/testsuite/17_intro/names.cc
index 53c5aff219d..784da9a7352 100644
--- a/libstdc++-v3/testsuite/17_intro/names.cc
+++ b/libstdc++-v3/testsuite/17_intro/names.cc
@@ -240,6 +240,8 @@
 #undef r
 #undef x
 #undef y
+//  defines pollfd_ext::u on AIX 7.3
+#undef u
 //  defines vario::v
 #undef v
 //  defines trb::func and cputime_tmr::func
-- 
2.43.0



[PATCH] libstdc++: Add copyright and license text to new generated headers

2024-02-02 Thread Jonathan Wakely
These new headers should probably have the usual boilerplate at the top,
so make the Python scripts output it.

-- >8 --

contrib/ChangeLog:

* unicode/gen_libstdcxx_unicode_data.py: Add copyright and
license text to the output.

libstdc++-v3/ChangeLog:

* include/bits/text_encoding-data.h: Regenerate.
* include/bits/unicode-data.h: Regenerate.
* scripts/gen_text_encoding_data.py: Add copyright and license
text to the output.
---
 contrib/unicode/gen_libstdcxx_unicode_data.py | 30 ++-
 .../include/bits/text_encoding-data.h | 27 +
 libstdc++-v3/include/bits/unicode-data.h  | 27 +
 .../scripts/gen_text_encoding_data.py | 30 ++-
 4 files changed, 112 insertions(+), 2 deletions(-)

diff --git a/contrib/unicode/gen_libstdcxx_unicode_data.py 
b/contrib/unicode/gen_libstdcxx_unicode_data.py
index f2f2f8a8ec2..2341a442f6a 100755
--- a/contrib/unicode/gen_libstdcxx_unicode_data.py
+++ b/contrib/unicode/gen_libstdcxx_unicode_data.py
@@ -30,7 +30,35 @@ import sys
 import re
 import math
 
-print("// Generated by contrib/unicode/gen_std_format_width.py, do not 
edit.\n")
+print("""// Generated by contrib/unicode/gen_std_format_width.py, do not edit.
+
+// Copyright The GNU Toolchain Authors.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+
+// Under Section 7 of GPL version 3, you are granted additional
+// permissions described in the GCC Runtime Library Exception, version
+// 3.1, as published by the Free Software Foundation.
+
+// You should have received a copy of the GNU General Public License and
+// a copy of the GCC Runtime Library Exception along with this program;
+// see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
+// .
+
+/** @file bits/unicode-data.h
+ *  This is an internal header file, included by other library headers.
+ *  Do not attempt to use it directly. @headername{format}
+ */
+""")
 print("#ifndef _GLIBCXX_GET_UNICODE_DATA")
 print('# error "This is not a public header, do not include it directly"')
 print("#elif _GLIBCXX_GET_UNICODE_DATA != 150100")
diff --git a/libstdc++-v3/include/bits/text_encoding-data.h 
b/libstdc++-v3/include/bits/text_encoding-data.h
index 5041e738d21..81bd94e6c3a 100644
--- a/libstdc++-v3/include/bits/text_encoding-data.h
+++ b/libstdc++-v3/include/bits/text_encoding-data.h
@@ -1,5 +1,32 @@
 // Generated by gen_text_encoding_data.py, do not edit.
 
+// Copyright The GNU Toolchain Authors.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+
+// Under Section 7 of GPL version 3, you are granted additional
+// permissions described in the GCC Runtime Library Exception, version
+// 3.1, as published by the Free Software Foundation.
+
+// You should have received a copy of the GNU General Public License and
+// a copy of the GCC Runtime Library Exception along with this program;
+// see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
+// .
+
+/** @file bits/text_encoding-data.h
+ *  This is an internal header file, included by other library headers.
+ *  Do not attempt to use it directly. @headername{text_encoding}
+ */
+
 #ifndef _GLIBCXX_GET_ENCODING_DATA
 # error "This is not a public header, do not include it directly"
 #endif
diff --git a/libstdc++-v3/include/bits/unicode-data.h 
b/libstdc++-v3/include/bits/unicode-data.h
index 83968096499..69b8f2926c3 100644
--- a/libstdc++-v3/include/bits/unicode-data.h
+++ b/libstdc++-v3/include/bits/unicode-data.h
@@ -1,5 +1,32 @@
 // Generated by contrib/unicode/gen_std_format_width.py, do not edit.
 
+// Copyright The GNU Toolchain Authors.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later v

Re: Updated musttail patches

2024-02-02 Thread Joseph Myers
On Fri, 2 Feb 2024, Andi Kleen wrote:

> This patchkit implements a [[musttail]] attribute for C/C++.
> 
> v4:
> Addressed all feedback except clang::musttail is still supported
> (I don't want to force an #ifdef to most users) and I'm also still

I'm fine with supporting [[clang::musttail]].  What shouldn't be supported 
is plain unnamespaced [[musttail]], at least for C, and I don't see any 
tests that that's not supported (there are tests of [[musttail]] on things 
that aren't returns, but that's mixing two different issues - 
[[gnu::musttail]] shouldn't be accepted on non-returns, while [[musttail]] 
shouldn't be accepted anywhere, including on returns, because it's not a 
standard attribute).

-- 
Joseph S. Myers
josmy...@redhat.com



Re: [PATCH][gcc-13] libstdc++: Add Filesystem TS and std::stacktrace symbols to libstdc++exp.a

2024-02-02 Thread Jonathan Wakely
On Tue, 9 Jan 2024 at 12:44, Jonathan Wakely  wrote:
>
> I was talking to Matthias Klose about enabling libstdc++_libbacktrace.a
> for Ubuntu's gcc package and I realised that it would be preferable if
> the gcc-13 branch had those libbacktrace symbols in libstdc++exp.a. I
> already did that for trunk with r14-3812-gb96b554592c5cb and trunk no
> longer installs libstdc++_libbacktrace.a at all.
>
> Removing libstdc++_libbacktrace.a for GCC 13.3 would be inappropriate
> for a stable release branch, so this partial backport duplicates the
> libstdc++_libbacktrace.a symbols in libstdc++exp.a but still installs
> libstdc++_libbacktrace.a as well.  This gives users a smoother
> transition from GCC 13 to GCC 14. They can continue using
> -lstdc++_libbacktrace with GCC 13, or they can switch to
> -lstdc++exp now and be ready for GCC 14.

This didn't actually work though, see
https://gcc.gnu.org/pipermail/gcc-patches/2024-February/644822.html
for the explanation and fix, which I'll backport to gcc-13.

>
> Any objections?
>
> Tested x86_64-linux.
>
> If I push this I'll also add a 13.3 section to the bottom of
> https://gcc.gnu.org/gcc-13/changes.html#13.2 documenting it.
>
> -- >8 --
>
> This consolidates the three static archives for extensions into one, so
> that -lstdc++exp can be used to provide the definitions of all unstable
> library features.
>
> For this gcc-13 backport libstdc++_libbacktrace.a is still installed,
> but its contents are duplicated in libstdc++exp.a. This means that users
> can start using -lstdc++exp with GCC 13.3 if they want, but existing
> Makefiles can continue to use -lstdc++_libbacktrace for any GCC 13.x
> release.
>
> The libstdc++fs.a archive is still installed, but its contents are
> duplicated in libstdc++exp.a now. This means -lstdc++exp can be used
> instead of -lstdc++fs. For targets using the GNU linker we should
> consider replacing libstdc++fs.a with a linker script that does
> INPUT(libstdc++exp.a).
>
> The tests for  could be changed to use
> -lstdc++exp instead of -lstdc++fs, which would allow removing
> src/filesystem/.libs from the LDFLAGS in scripts/testsuite_flags.in,
> but that can be done at a later date.
>
> libstdc++-v3/ChangeLog:
>
> * doc/html/manual/*: Regenerate.
> * doc/xml/manual/using.xml: Update documentation on linking.
> * scripts/testsuite_flags.in: Adjust LDFLAGS to find
> libstdc++exp instead of libstdc++_libbacktrace.
> * src/c++20/Makefile.am: Fix comment.
> * src/c++20/Makefile.in: Regenerate.
> * src/experimental/Makefile.am: Use LIBADD to include other
> libraries.
> * src/experimental/Makefile.in: Regenerate.
> * testsuite/19_diagnostics/stacktrace/current.cc: Adjust
> dg-options to use -lstdc++exp.
> * testsuite/19_diagnostics/stacktrace/entry.cc: Likewise.
> * testsuite/19_diagnostics/stacktrace/stacktrace.cc: Likewise.
> * testsuite/23_containers/vector/debug/assign4_backtrace_neg.cc:
> Likewise.
>
> (cherry picked from commit b96b554592c5cbb6a2c1797ffcb5706fd295f4fd)
> ---
>  libstdc++-v3/doc/html/manual/using.html   | 26 +++--
>  .../html/manual/using_dynamic_or_shared.html  |  4 ++
>  libstdc++-v3/doc/xml/manual/using.xml | 37 ++-
>  libstdc++-v3/scripts/testsuite_flags.in   |  8 ++--
>  libstdc++-v3/src/c++20/Makefile.am|  2 +-
>  libstdc++-v3/src/c++20/Makefile.in|  2 +-
>  libstdc++-v3/src/experimental/Makefile.am | 18 +
>  libstdc++-v3/src/experimental/Makefile.in | 13 ++-
>  .../19_diagnostics/stacktrace/current.cc  |  2 +-
>  .../19_diagnostics/stacktrace/entry.cc|  2 +-
>  .../19_diagnostics/stacktrace/stacktrace.cc   |  2 +-
>  .../vector/debug/assign4_backtrace_neg.cc |  2 +-
>  12 files changed, 77 insertions(+), 41 deletions(-)
>
> diff --git a/libstdc++-v3/doc/xml/manual/using.xml 
> b/libstdc++-v3/doc/xml/manual/using.xml
> index 3a507fc1671..7276cad0feb 100644
> --- a/libstdc++-v3/doc/xml/manual/using.xml
> +++ b/libstdc++-v3/doc/xml/manual/using.xml
> @@ -100,30 +100,27 @@
>
>  
>
> -
> -  -lstdc++fs
> -  Linking to libstdc++fs
> -is required for use of the Filesystem library extensions in
> - class="headerfile">.
> -  
> -
> -
>  
>-lstdc++exp
> -  Linking to libstdc++exp
> -is required for use of the C++ Contracts extensions enabled by
> --fcontracts.
> +  Linking to  class="libraryfile">libstdc++exp.a
> +is required for use of experimental C++ library features.
> +This currently provides support for the C++23 types defined in the
> + header,
> +the Filesystem library extensions defined in the
> + class="headerfile">
> +header,
> +and the Contracts extensions enabled by 
> -fcontracts.
>
>  
>
>

Re: [Patch, stage-1, RFC]: i386: attribute regparm/stdcall and vaargs

2024-02-02 Thread Joseph Myers
On Fri, 2 Feb 2024, Bernhard Reutner-Fischer via Gcc wrote:

> Hi Joseph!
> 
> On Tue, 30 Jan 2024 14:54:49 + (UTC)
> Joseph Myers  wrote:
> 
> > On Tue, 30 Jan 2024, Bernhard Reutner-Fischer via Gcc wrote:
> > 
> > >   * builtin-attrs.def (ATTR_TM_NOTHROW_RT_LIST): Use ATTR_NOTHROW_LIST
> > >   instead of ATTR_TM_NOTHROW_LIST, thus removing ATTR_TM_REGPARM.  
> > 
> > That doesn't make sense.  ATTR_TM_NOTHROW_RT_LIST is specifically a 
> > transactional memory attribute list, but you're removing all transactional 
> > memory attributes from it.  A list without the "*tm regparm" internal 
> > attribute would have a different name.
> > 
> 
> AFAICS there is no pre-existing attr list with just returns_twice and
> nothrow. Would ATTR_NOTHROW_RT_LIST be more appropriate as name, and
> should i move this up to before the format attribute lists, before
> DEF_FORMAT_ATTRIBUTE?

Yes, both of those seem appropriate for such an attribute list.

I do not know what attributes are appropriate for _ITM_beginTransaction.

-- 
Joseph S. Myers
josmy...@redhat.com



Re: [PATCH] libstdc++: Fix libstdc++exp.a so it really does contain Filesystem TS symbols

2024-02-02 Thread Jonathan Wakely

On 02/02/24 12:14 +, Jonathan Wakely wrote:

This should fix the problem that libstdc++exp.a doesn't actually contain
the symbols from libstdc++fs.a, despite me claiming it did.

This increases the size of libstdc++exp.a considerably, because now it
really does contain what I intended it to contain. We might be able to
avoid that increased on-disk footprint by replacing the installed
version of libstdc++fs.a with a linker script that does
INPUT(-lstdc++exp.a) but for now duplicating things seems OK. Vendors


Oops, that should be INPUT(-lstdc++exp) obviously, without the .a
extension.


can replace libstdc++fs.a with a linker script if they want to.




[PATCH] libstdc++: Fix libstdc++exp.a so it really does contain Filesystem TS symbols

2024-02-02 Thread Jonathan Wakely
This should fix the problem that libstdc++exp.a doesn't actually contain
the symbols from libstdc++fs.a, despite me claiming it did.

This increases the size of libstdc++exp.a considerably, because now it
really does contain what I intended it to contain. We might be able to
avoid that increased on-disk footprint by replacing the installed
version of libstdc++fs.a with a linker script that does
INPUT(-lstdc++exp.a) but for now duplicating things seems OK. Vendors
can replace libstdc++fs.a with a linker script if they want to.

This needs to be backported too, because on the gcc-13 branch both
libstdc++fs.a _and_ libstdc++_libbacktrace.a are installed, so libtool
ignores them both and libstdc++exp.a only contains the contract
violation handler. That makes r13-8207-g17acf9fbeb10d7 completely
useless until this fix gets backported.

-- >8 --

In r14-3812-gb96b554592c5cb I claimed that libstdc++exp.a now contains
all the symbols from libstdc++fs.a as well as libstdc++_libbacktrace.a,
but that wasn't true. Only the symbols from the latter were added to
libstdc++exp.a, the Filesystem TS ones weren't. This seems to be because
libtool won't combine static libs that are going to be installed
separately. Because libstdc++fs.a is still installed, libtool decides it
shouldn't be included in libstdc++exp.a.

The solution is similar to what we already do for libsupc++.a: build two
static libs, libstdc++fs.a and libstdc++fsconvenience.a, where the
former is installed and the latter isn't. If we then tell libtool to
include the latter in libstdc++exp.a it will do as it's told.

libstdc++-v3/ChangeLog:

* src/experimental/Makefile.am: Use libstdc++fsconvenience.a
instead of libstdc++fs.a.
* src/experimental/Makefile.in: Regenerate.
* src/filesystem/Makefile.am: Build libstdc++fsconvenience.a as
well.
* src/filesystem/Makefile.in: Regenerate.
---
 libstdc++-v3/src/experimental/Makefile.am |  2 +-
 libstdc++-v3/src/experimental/Makefile.in |  4 +--
 libstdc++-v3/src/filesystem/Makefile.am   |  4 +++
 libstdc++-v3/src/filesystem/Makefile.in   | 37 +++
 4 files changed, 38 insertions(+), 9 deletions(-)

diff --git a/libstdc++-v3/src/experimental/Makefile.am 
b/libstdc++-v3/src/experimental/Makefile.am
index 6241430988e..386e7442de4 100644
--- a/libstdc++-v3/src/experimental/Makefile.am
+++ b/libstdc++-v3/src/experimental/Makefile.am
@@ -25,7 +25,7 @@ include $(top_srcdir)/fragment.am
 toolexeclib_LTLIBRARIES = libstdc++exp.la
 
 if ENABLE_FILESYSTEM_TS
-filesystem_lib = $(top_builddir)/src/filesystem/libstdc++fs.la
+filesystem_lib = $(top_builddir)/src/filesystem/libstdc++fsconvenience.la
 else
 filesystem_lib =
 endif
diff --git a/libstdc++-v3/src/filesystem/Makefile.am 
b/libstdc++-v3/src/filesystem/Makefile.am
index 4bdbab38660..37cbfe1d00e 100644
--- a/libstdc++-v3/src/filesystem/Makefile.am
+++ b/libstdc++-v3/src/filesystem/Makefile.am
@@ -22,7 +22,10 @@
 
 include $(top_srcdir)/fragment.am
 
+# Separate libstdc++fs.a to be installed.
 toolexeclib_LTLIBRARIES = libstdc++fs.la
+# Duplicate lib that is to be part of libstdc++exp.a
+noinst_LTLIBRARIES = libstdc++fsconvenience.la
 
 headers =
 
@@ -44,6 +47,7 @@ sources = \
 # vpath % $(top_srcdir)/src/filesystem
 
 libstdc__fs_la_SOURCES = $(sources)
+libstdc__fsconvenience_la_SOURCES = $(sources)
 
 # AM_CXXFLAGS needs to be in each subdirectory so that it can be
 # modified in a per-library or per-sub-library way.  Need to manually



Re: [PATCH v2] x86-64: Find a scratch register for large model profiling

2024-02-02 Thread Jakub Jelinek
On Thu, Feb 01, 2024 at 03:02:47PM -0800, H.J. Lu wrote:
> @@ -2763,6 +2789,8 @@ construct_container (machine_mode mode, machine_mode 
> orig_mode,
>{
>case X86_64_INTEGER_CLASS:
>case X86_64_INTEGERSI_CLASS:
> + if (!in_return)
> +   set_int_parameter_registers_bit (intreg[0]);
>   return gen_rtx_REG (mode, intreg[0]);
>case X86_64_SSE_CLASS:
>case X86_64_SSEHF_CLASS:
> @@ -2821,6 +2849,11 @@ construct_container (machine_mode mode, machine_mode 
> orig_mode,
>if (mode == BLKmode)
>   {
> /* Use TImode for BLKmode values in 2 integer registers.  */
> +   if (!in_return)
> + {
> +   set_int_parameter_registers_bit (intreg[0]);
> +   set_int_parameter_registers_bit (intreg[1]);
> + }
> exp[0] = gen_rtx_EXPR_LIST (VOIDmode,
> gen_rtx_REG (TImode, intreg[0]),
> GEN_INT (0));

Isn't the above (computed from just whether a function has such an argument)
already available from cum->nregs or similar plus the sequence of argument
registers?  Or df which certainly also needs to know what registers contain
arguments?
Though, the above means a function argument register which isn't used in a
function will be impossible to use for mcount.
We certainly can use it (although var-tracking will not know it got
clobbered).
So, wouldn't it be better to ask at the start of prologue generation df what
registers are live at the start of the function (i.e. at the point of the
NOTE_INSN_PROLOG_END because rest of prologue is emitted before that) and
remember a suitable register for the profiling there?
> @@ -22749,6 +22789,38 @@ current_fentry_section (const char **name)
>return true;
>  }
>  
> +/* Return an caller-saved register, which isn't used for parameter
> +   passing, at entry for profile.  */
> +
> +static int
> +x86_64_select_profile_regnum (bool r11_ok ATTRIBUTE_UNUSED)
> +{
> +  /* Use %r10 if it isn't used by DRAP.  */
> +  bool r10_ok = !crtl->drap_reg || REGNO (crtl->drap_reg) != R10_REG;
> +  if (r10_ok)
> +return R10_REG;
> +
> +  int i;
> +  for (i = 0; i < FIRST_PSEUDO_REGISTER; i++)
> +if (GENERAL_REGNO_P (i)
> + && (r10_ok || i != R10_REG)

r10_ok is false here, so just
  if (flag_fentry != 0 || !crtl->drap_reg || REGNO (crtl->drap_reg) != R10_REG)
return R10_REG;
at the start and don't declare r10_ok.

> +#ifdef NO_PROFILE_COUNTERS
> + && (r11_ok || i != R11_REG)
> +#else
> + && i != R11_REG
> +#endif
> + && (!REX2_INT_REGNO_P (i) || TARGET_APX_EGPR)
> + && !fixed_regs[i]
> + && call_used_regs[i]
> + && !test_int_parameter_registers_bit (i))
> +  return i;
> +
> +  sorry ("no register available for profiling %<-mcmodel=large%s%>",
> +  ix86_cmodel == CM_LARGE_PIC ? " -fPIC" : "");
> +
> +  return INVALID_REGNUM;
> +}
> +
>  /* Output assembler code to FILE to increment profiler label # LABELNO
> for profiling a function entry.  */
>  void
> @@ -22783,42 +22855,60 @@ x86_function_profiler (FILE *file, int labelno 
> ATTRIBUTE_UNUSED)
>   fprintf (file, "\tleaq\t%sP%d(%%rip), %%r11\n", LPREFIX, labelno);
>  #endif
>  
> +  int scratch;
> +  const char *reg_prefix;
> +  const char *reg;
> +
>if (!TARGET_PECOFF)
>   {
> switch (ix86_cmodel)
>   {
>   case CM_LARGE:
> -   /* NB: R10 is caller-saved.  Although it can be used as a
> -  static chain register, it is preserved when calling
> -  mcount for nested functions.  */
> +   scratch = x86_64_select_profile_regnum (true);
> +   reg = hi_reg_name[scratch];
> +   reg_prefix = LEGACY_INT_REGNO_P (scratch) ? "r" : "";
> if (ASSEMBLER_DIALECT == ASM_INTEL)
> - fprintf (file, "1:\tmovabs\tr10, OFFSET FLAT:%s\n"
> -"\tcall\tr10\n", mcount_name);
> + fprintf (file,
> +  "1:\tmovabs\t%s%s, OFFSET FLAT:%s\n"
> +  "\tcall\t%s%s\n",
> +  reg_prefix, reg, mcount_name, reg_prefix, reg);
> else
> - fprintf (file, "1:\tmovabsq\t$%s, %%r10\n\tcall\t*%%r10\n",
> -  mcount_name);
> + fprintf (file,
> +  "1:\tmovabsq\t$%s, %%%s%s\n\tcall\t*%%%s%s\n",
> +  mcount_name, reg_prefix, reg, reg_prefix, reg);
> break;
>   case CM_LARGE_PIC:
>  #ifdef NO_PROFILE_COUNTERS
> +   scratch = x86_64_select_profile_regnum (false);
> +   reg = hi_reg_name[scratch];
> +   reg_prefix = LEGACY_INT_REGNO_P (scratch) ? "r" : "";
> if (ASSEMBLER_DIALECT == ASM_INTEL)
>   {
> fprintf (file, "1:movabs\tr11, "
>"OFFSET FLAT:_GLOBAL_OFFSET_TABLE_-1b\n");
> -   fprintf (file, "\tlea\tr10, 1b[rip]\n");
> -   f

Re: [PATCH] x86-64: Find a scratch register for large model profiling

2024-02-02 Thread H.J. Lu
On Fri, Feb 2, 2024 at 4:07 AM  wrote:
>
> On 2 February 2024 00:02:54 CET, "H.J. Lu"  wrote:
> >On Thu, Feb 1, 2024 at 10:32 AM Jakub Jelinek  wrote:
> >>
> >> On Thu, Feb 01, 2024 at 10:15:30AM -0800, H.J. Lu wrote:
> >> > --- a/gcc/config/i386/i386.cc
> >> > +++ b/gcc/config/i386/i386.cc
> >> > @@ -22749,6 +22749,31 @@ current_fentry_section (const char **name)
> >> >return true;
> >> >  }
> >> >
> >> > +/* Return an unused caller-saved register at entry for profile.  */
> >> > +
> >> > +static int
> >> > +x86_64_select_profile_regnum (bool r11_ok ATTRIBUTE_UNUSED)
> >> > +{
> >> > +  int i;
> >>
> >> Why not just return R10_REG here if flag_entry != 0 (i.e. keep existing
> >> behavior unless emitting profiler after prologue)?
> >
> >Fixed in v2.
>
> Nit: r10_ok is now superfluous, but lets wait for Jakub.
> thanks

Fixed in v3.

Thanks.

-- 
H.J.


[PATCH v3] x86-64: Find a scratch register for large model profiling

2024-02-02 Thread H.J. Lu
Changes in v3:

1. Remove r10_ok.

Changes in v2:

1. Add int_parameter_registers to machine_function to track integer
registers used for parameter passing.
2. Update x86_64_select_profile_regnum to try %r10 first and use an
caller-saved register, which isn't used for parameter passing.

---
2 scratch registers, %r10 and %r11, are available at function entry for
large model profiling.  But %r10 may be used by stack realignment and we
can't use %r10 in this case.  Add x86_64_select_profile_regnum to find
an caller-saved register, which isn't used for parameter passing, for
large model profiling and sorry if we can't find one.

gcc/

PR target/113689
* config/i386/i386.cc (set_int_parameter_registers_bit): New.
(test_int_parameter_registers_bit): Likewise.
(x86_64_select_profile_regnum): New.
(construct_container): Call set_int_parameter_registers_bit for
integer register parameter passing.
(function_arg_32): Likewise.
(x86_function_profiler): Call x86_64_select_profile_regnum to
get a scratch register for large model profiling.
* config/i386/i386.h (machine_function): Add
int_parameter_registers.

gcc/testsuite/

PR target/113689
* gcc.target/i386/pr113689-1.c: New file.
* gcc.target/i386/pr113689-2.c: Likewise.
* gcc.target/i386/pr113689-3.c: Likewise.
---
 gcc/config/i386/i386.cc| 121 ++---
 gcc/config/i386/i386.h |   5 +
 gcc/testsuite/gcc.target/i386/pr113689-1.c |  49 +
 gcc/testsuite/gcc.target/i386/pr113689-2.c |  41 +++
 gcc/testsuite/gcc.target/i386/pr113689-3.c |  24 
 5 files changed, 224 insertions(+), 16 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/i386/pr113689-1.c
 create mode 100644 gcc/testsuite/gcc.target/i386/pr113689-2.c
 create mode 100644 gcc/testsuite/gcc.target/i386/pr113689-3.c

diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc
index b3e7c74846e..483d74a0811 100644
--- a/gcc/config/i386/i386.cc
+++ b/gcc/config/i386/i386.cc
@@ -2628,6 +2628,32 @@ classify_argument (machine_mode mode, const_tree type,
   return n;
 }
 
+/* Set the integer register REGNO bit in int_parameter_registers.  */
+
+static void
+set_int_parameter_registers_bit (int regno)
+{
+  if (LEGACY_INT_REGNO_P (regno))
+cfun->machine->int_parameter_registers |= 1 << regno;
+  else
+cfun->machine->int_parameter_registers
+  |= 1 << (regno - FIRST_REX_INT_REG + 8);
+}
+
+/* Return true if the integer register REGNO bit in
+   int_parameter_registers is set.  */
+
+static bool
+test_int_parameter_registers_bit (int regno)
+{
+  if (LEGACY_INT_REGNO_P (regno))
+return (cfun->machine->int_parameter_registers
+   & (1 << regno)) != 0;
+  else
+return (cfun->machine->int_parameter_registers
+   & (1 << (regno - FIRST_REX_INT_REG + 8))) != 0;
+}
+
 /* Examine the argument and return set number of register required in each
class.  Return true iff parameter should be passed in memory.  */
 
@@ -2763,6 +2789,8 @@ construct_container (machine_mode mode, machine_mode 
orig_mode,
   {
   case X86_64_INTEGER_CLASS:
   case X86_64_INTEGERSI_CLASS:
+   if (!in_return)
+ set_int_parameter_registers_bit (intreg[0]);
return gen_rtx_REG (mode, intreg[0]);
   case X86_64_SSE_CLASS:
   case X86_64_SSEHF_CLASS:
@@ -2821,6 +2849,11 @@ construct_container (machine_mode mode, machine_mode 
orig_mode,
   if (mode == BLKmode)
{
  /* Use TImode for BLKmode values in 2 integer registers.  */
+ if (!in_return)
+   {
+ set_int_parameter_registers_bit (intreg[0]);
+ set_int_parameter_registers_bit (intreg[1]);
+   }
  exp[0] = gen_rtx_EXPR_LIST (VOIDmode,
  gen_rtx_REG (TImode, intreg[0]),
  GEN_INT (0));
@@ -2829,7 +2862,11 @@ construct_container (machine_mode mode, machine_mode 
orig_mode,
  return ret;
}
   else
-   return gen_rtx_REG (mode, intreg[0]);
+   {
+ if (!in_return)
+   set_int_parameter_registers_bit (intreg[0]);
+ return gen_rtx_REG (mode, intreg[0]);
+   }
 }
 
   /* Otherwise figure out the entries of the PARALLEL.  */
@@ -2860,6 +2897,8 @@ construct_container (machine_mode mode, machine_mode 
orig_mode,
  = gen_rtx_EXPR_LIST (VOIDmode,
   gen_rtx_REG (tmpmode, *intreg),
   GEN_INT (i*8));
+   if (!in_return)
+ set_int_parameter_registers_bit (*intreg);
intreg++;
break;
  case X86_64_SSEHF_CLASS:
@@ -3241,6 +3280,7 @@ pass_in_reg:
  if (regno == AX_REG)
regno = CX_REG;
}
+ set_int_parameter_registers_bit (regno);
  return gen_rtx_REG (mode, regno);

Re: [PATCH] x86-64: Find a scratch register for large model profiling

2024-02-02 Thread rep . dot . nop
On 2 February 2024 00:02:54 CET, "H.J. Lu"  wrote:
>On Thu, Feb 1, 2024 at 10:32 AM Jakub Jelinek  wrote:
>>
>> On Thu, Feb 01, 2024 at 10:15:30AM -0800, H.J. Lu wrote:
>> > --- a/gcc/config/i386/i386.cc
>> > +++ b/gcc/config/i386/i386.cc
>> > @@ -22749,6 +22749,31 @@ current_fentry_section (const char **name)
>> >return true;
>> >  }
>> >
>> > +/* Return an unused caller-saved register at entry for profile.  */
>> > +
>> > +static int
>> > +x86_64_select_profile_regnum (bool r11_ok ATTRIBUTE_UNUSED)
>> > +{
>> > +  int i;
>>
>> Why not just return R10_REG here if flag_entry != 0 (i.e. keep existing
>> behavior unless emitting profiler after prologue)?
>
>Fixed in v2.

Nit: r10_ok is now superfluous, but lets wait for Jakub.
thanks


Re: [PATCH v2] arm: Fix missing bti instruction for virtual thunks

2024-02-02 Thread Richard Earnshaw (lists)
On 26/01/2024 15:31, Richard Ball wrote:
> v2: Formatting and test options fix.
> 
> Adds missing bti instruction at the beginning of a virtual
> thunk, when bti is enabled.
> 
> gcc/ChangeLog:
> 
>   * config/arm/arm.cc (arm_output_mi_thunk): Emit
>   insn for bti_c when bti is enabled.
> 
> gcc/testsuite/ChangeLog:
> 
> * lib/target-supports.exp: Add v8_1_m_main_pacbti.
> * g++.target/arm/bti_thunk.C: New test.

OK, thanks.

R.


Re: [PATCH v4 4/5] Add tests for C/C++ musttail attributes

2024-02-02 Thread Prathamesh Kulkarni
On Fri, 2 Feb 2024 at 14:44, Andi Kleen  wrote:
>
> Mostly adopted from the existing C musttail plugin tests.
>
> gcc/testsuite/ChangeLog:
>
> * c-c++-common/musttail1.c: New test.
> * c-c++-common/musttail2.c: New test.
> * c-c++-common/musttail3.c: New test.
> * c-c++-common/musttail4.c: New test.
> * c-c++-common/musttail5.c: New test.
> ---
>  gcc/testsuite/c-c++-common/musttail1.c | 15 
>  gcc/testsuite/c-c++-common/musttail2.c | 34 ++
>  gcc/testsuite/c-c++-common/musttail3.c | 29 ++
>  gcc/testsuite/c-c++-common/musttail4.c | 17 +
>  gcc/testsuite/c-c++-common/musttail5.c | 25 +++
>  5 files changed, 120 insertions(+)
>  create mode 100644 gcc/testsuite/c-c++-common/musttail1.c
>  create mode 100644 gcc/testsuite/c-c++-common/musttail2.c
>  create mode 100644 gcc/testsuite/c-c++-common/musttail3.c
>  create mode 100644 gcc/testsuite/c-c++-common/musttail4.c
>  create mode 100644 gcc/testsuite/c-c++-common/musttail5.c
>
> diff --git a/gcc/testsuite/c-c++-common/musttail1.c 
> b/gcc/testsuite/c-c++-common/musttail1.c
> new file mode 100644
> index ..ac92f9f74616
> --- /dev/null
> +++ b/gcc/testsuite/c-c++-common/musttail1.c
> @@ -0,0 +1,15 @@
> +/* { dg-do compile { target { tail_call && { c || c++11 } } } } */
> +/* { dg-options "-O2" } */
> +/* { dg-additional-options "-fdelayed-branch" { target sparc*-*-* } } */
> +
> +int __attribute__((noinline,noclone,noipa))
> +callee (int i)
Hi Andy,
Sorry, I wasn't clear about this in previous patch -- noipa will
subsume other ipa attributes,
so there's no need to have noinline, noclone along with noipa.
int __attribute__((noipa)) callee(int i) should be sufficient for
disabling IPA optimizations involving callee.

Thanks,
Prathamesh

> +{
> +  return i * i;
> +}
> +
> +int __attribute__((noinline,noclone,noipa))
> +caller (int i)
> +{
> +  [[gnu::musttail]] return callee (i + 1);
> +}
> diff --git a/gcc/testsuite/c-c++-common/musttail2.c 
> b/gcc/testsuite/c-c++-common/musttail2.c
> new file mode 100644
> index ..058329b69cc2
> --- /dev/null
> +++ b/gcc/testsuite/c-c++-common/musttail2.c
> @@ -0,0 +1,34 @@
> +/* { dg-do compile { target { tail_call && { c || c++11 } } } } */
> +
> +struct box { char field[256]; int i; };
> +
> +int __attribute__((noinline,noclone,noipa))
> +test_2_callee (int i, struct box b)
> +{
> +  if (b.field[0])
> +return 5;
> +  return i * i;
> +}
> +
> +int __attribute__((noinline,noclone,noipa))
> +test_2_caller (int i)
> +{
> +  struct box b;
> +  [[gnu::musttail]] return test_2_callee (i + 1, b); /* { dg-error "cannot 
> tail-call: " } */
> +}
> +
> +extern void setjmp (void);
> +void
> +test_3 (void)
> +{
> +  [[gnu::musttail]] return setjmp (); /* { dg-error "cannot tail-call: " } */
> +}
> +
> +typedef void (fn_ptr_t) (void);
> +volatile fn_ptr_t fn_ptr;
> +
> +void
> +test_5 (void)
> +{
> +  [[gnu::musttail]] return fn_ptr (); /* { dg-error "cannot tail-call: " } */
> +}
> diff --git a/gcc/testsuite/c-c++-common/musttail3.c 
> b/gcc/testsuite/c-c++-common/musttail3.c
> new file mode 100644
> index ..ea9589c59ef2
> --- /dev/null
> +++ b/gcc/testsuite/c-c++-common/musttail3.c
> @@ -0,0 +1,29 @@
> +/* { dg-do compile { target { tail_call && { c || c++11 } } } } */
> +
> +extern int foo2 (int x, ...);
> +
> +struct str
> +{
> +  int a, b;
> +};
> +
> +struct str
> +cstruct (int x)
> +{
> +  if (x < 10)
> +[[clang::musttail]] return cstruct (x + 1);
> +  return ((struct str){ x, 0 });
> +}
> +
> +int
> +foo (int x)
> +{
> +  if (x < 10)
> +[[clang::musttail]] return foo2 (x, 29);
> +  if (x < 100)
> +{
> +  int k = foo (x + 1);
> +  [[clang::musttail]] return k;/* { dg-error "cannot tail-call: " } 
> */
> +}
> +  return x;
> +}
> diff --git a/gcc/testsuite/c-c++-common/musttail4.c 
> b/gcc/testsuite/c-c++-common/musttail4.c
> new file mode 100644
> index ..23f4b5e1cd68
> --- /dev/null
> +++ b/gcc/testsuite/c-c++-common/musttail4.c
> @@ -0,0 +1,17 @@
> +/* { dg-do compile { target { tail_call && { c || c++11 } } } } */
> +
> +struct box { char field[64]; int i; };
> +
> +struct box __attribute__((noinline,noclone,noipa))
> +returns_struct (int i)
> +{
> +  struct box b;
> +  b.i = i * i;
> +  return b;
> +}
> +
> +int __attribute__((noinline,noclone))
> +test_1 (int i)
> +{
> +  [[gnu::musttail]] return returns_struct (i * 5).i; /* { dg-error "cannot 
> tail-call: " } */
> +}
> diff --git a/gcc/testsuite/c-c++-common/musttail5.c 
> b/gcc/testsuite/c-c++-common/musttail5.c
> new file mode 100644
> index ..71f4de40fc6d
> --- /dev/null
> +++ b/gcc/testsuite/c-c++-common/musttail5.c
> @@ -0,0 +1,25 @@
> +/* { dg-do compile } */
> +/* { dg-options "-std=c23" { target c } } */
> +/* { dg-options "-std=gnu++11" { target c++ } } */
> +
> +[[musttail]] int j; /* { dg-warning "attribute" } */
> +__attribute__((musttail)) int k; /*

Re: [Patch, stage-1, RFC]: i386: attribute regparm/stdcall and vaargs

2024-02-02 Thread Bernhard Reutner-Fischer
Hi Joseph!

On Tue, 30 Jan 2024 14:54:49 + (UTC)
Joseph Myers  wrote:

> On Tue, 30 Jan 2024, Bernhard Reutner-Fischer via Gcc wrote:
> 
> > * builtin-attrs.def (ATTR_TM_NOTHROW_RT_LIST): Use ATTR_NOTHROW_LIST
> > instead of ATTR_TM_NOTHROW_LIST, thus removing ATTR_TM_REGPARM.  
> 
> That doesn't make sense.  ATTR_TM_NOTHROW_RT_LIST is specifically a 
> transactional memory attribute list, but you're removing all transactional 
> memory attributes from it.  A list without the "*tm regparm" internal 
> attribute would have a different name.
> 

AFAICS there is no pre-existing attr list with just returns_twice and
nothrow. Would ATTR_NOTHROW_RT_LIST be more appropriate as name, and
should i move this up to before the format attribute lists, before
DEF_FORMAT_ATTRIBUTE?

Alternatively, there is an existing ATTR_RT_NOTHROW_LEAF_LIST
used by setjmp. But that would add leaf to _ITM_beginTransaction where
it was not marked leaf before. Would it be appropriate to use this for
_ITM_beginTransaction too, which behaves setjmp()ish AFAICS?

thanks


[committed] libgcc: Export XF, TF, HF and BFmode specific _BitInt symbols from libgcc_s.so.1 [PR113700]

2024-02-02 Thread Jakub Jelinek
Hi!

Rainer pointed out that __PFX__ and __FIXPTPFX__ prefix replacement is done
solely for libgcc-std.ver.in and not for the *.ver files in config.
I've used the __PFX__ prefix even in config/i386/libgcc-glibc.ver because it
was used for similar symbols in libgcc-std.ver.in, and that results in those
symbols being STB_LOCAL in libgcc_s.so.1.  Tests still work because gcc by
default uses -static-libgcc when linking (unlike g++ etc.), but would
have failed when using -shared-libgcc (but I see nothing in the testsuite
actually testing with -shared-libgcc, so am not adding tests).

With the patch, libgcc_s.so.1 now exports
__fixtfbitint@@GCC_14.0.0 FUNC GLOBAL DEFAULT
__fixxfbitint@@GCC_14.0.0 FUNC GLOBAL DEFAULT
__floatbitintbf@@GCC_14.0.0 FUNC GLOBAL DEFAULT
__floatbitinthf@@GCC_14.0.0 FUNC GLOBAL DEFAULT
__floatbitinttf@@GCC_14.0.0 FUNC GLOBAL DEFAULT
__floatbitintxf@@GCC_14.0.0 FUNC GLOBAL DEFAULT
on x86_64-linux which it wasn't before.

Tested on x86_64-linux, committed to trunk as obvious.

2024-02-02  Jakub Jelinek  

PR target/113700
* config/i386/libgcc-glibc.ver (GCC_14.0.0): Remove __PFX prefixes
from symbol names.

--- libgcc/config/i386/libgcc-glibc.ver.jj  2024-01-03 22:33:38.380691216 
+0100
+++ libgcc/config/i386/libgcc-glibc.ver 2024-02-02 11:39:59.374523748 +0100
@@ -229,10 +229,10 @@ GCC_13.0.0 {
 
 %inherit GCC_14.0.0 GCC_13.0.0
 GCC_14.0.0 {
-  __PFX__fixxfbitint
-  __PFX__fixtfbitint
-  __PFX__floatbitintbf
-  __PFX__floatbitinthf
-  __PFX__floatbitintxf
-  __PFX__floatbitinttf
+  __fixxfbitint
+  __fixtfbitint
+  __floatbitintbf
+  __floatbitinthf
+  __floatbitintxf
+  __floatbitinttf
 }

Jakub



Re: [PATCH] gcc/configure: Re-introduce INSTALL_INFO

2024-02-02 Thread Christophe Lyon
On Fri, 2 Feb 2024 at 11:10,  wrote:
>
> On 1 February 2024 18:15:34 CET, Christophe Lyon  
> wrote:
> >BUILD_INFO is currently a byproduct of checking makeinfo
> >presence/version.  INSTALL_INFO used to be defined similarly, but was
> >removed in 2000 (!) by commit 17db658241d18cf6db59d31bc2d6eac96e9257df
> >(svn r38141).
> >
> >In order to save build time, our CI overrides BUILD_INFO="", which
> >works when invoking 'make all' but not for 'make install' in case some
> >info files need an update.
>
> Instead of resurrecting INSTALL_INFO maybe you could something along the 
> lines of
>
> https://gcc.gnu.org/bugzilla/attachment.cgi?id=15038&action=edit

Ha indeed something along these lines would work too.
Thanks for the archaeology :-)

>
> not sure which approach would be considered cleaner..
Not sure either.

What do maintainers prefer?

>
> HTH


[committed, gcc-12] libstdc++: Force-inline shared_ptr::operator bool() for C++20 [PR108636]

2024-02-02 Thread Jonathan Wakely
Tested x86_64-linux. Pushed to releases/gcc-12 branch.

-- >8 --

This avoids a linker error with -fkeep-inline-functions when including
. We can't backport the fix from trunk because it adds an
export to the shared library. By marking the "missing" symbol
always_inline for C++20 mode we don't need a definition in the library.

libstdc++-v3/ChangeLog:

PR libstdc++/108636
* include/bits/shared_ptr_base.h (__shared_ptr::operator bool):
Add always_inline attribute for C++20 and later.
---
 libstdc++-v3/include/bits/shared_ptr_base.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/libstdc++-v3/include/bits/shared_ptr_base.h 
b/libstdc++-v3/include/bits/shared_ptr_base.h
index c22b397a194..23c3b17d46f 100644
--- a/libstdc++-v3/include/bits/shared_ptr_base.h
+++ b/libstdc++-v3/include/bits/shared_ptr_base.h
@@ -1666,6 +1666,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   { return _M_ptr; }
 
   /// Return true if the stored pointer is not null.
+#if __cplusplus >= 202002L
+  [[__gnu__::__always_inline__]]
+#endif
   explicit operator bool() const noexcept
   { return _M_ptr != nullptr; }
 
-- 
2.43.0



[committed] libstdc++: Implement some missing functions for net::ip::network_v6

2024-02-02 Thread Jonathan Wakely
Tested x86_64-linux. Pushed to trunk.

-- >8 --

libstdc++-v3/ChangeLog:

* include/experimental/internet (network_v6::network): Define.
(network_v6::hosts): Finish implementing.
(network_v6::to_string): Do not concatenate std::string to
arbitrary std::basic_string specialization.
* testsuite/experimental/net/internet/network/v6/cons.cc: New
test.
---
 libstdc++-v3/include/experimental/internet| 26 ++-
 .../net/internet/network/v6/cons.cc   | 74 +++
 2 files changed, 96 insertions(+), 4 deletions(-)
 create mode 100644 
libstdc++-v3/testsuite/experimental/net/internet/network/v6/cons.cc

diff --git a/libstdc++-v3/include/experimental/internet 
b/libstdc++-v3/include/experimental/internet
index 82043c87aca..3f5090cfa70 100644
--- a/libstdc++-v3/include/experimental/internet
+++ b/libstdc++-v3/include/experimental/internet
@@ -1347,17 +1347,35 @@ namespace ip
 constexpr address_v6 address() const noexcept { return _M_addr; }
 constexpr int prefix_length() const noexcept { return _M_prefix_len; }
 
-constexpr address_v6 network() const noexcept; // TODO
+_GLIBCXX17_CONSTEXPR address_v6
+network() const noexcept
+{
+  address_v6::bytes_type __bytes = _M_addr.to_bytes();
+  int __nbytes = (_M_prefix_len + 7) / 8;
+  for (int __n = __nbytes; __n < 16; ++__n)
+   __bytes[__n] = 0;
+  if (int __zbits = (__nbytes * 8) - _M_prefix_len)
+   __bytes[__nbytes - 1] &= 0xFF << __zbits;
+  return address_v6(__bytes, _M_addr.scope_id());
+}
 
 address_v6_range
 hosts() const noexcept
 {
   if (is_host())
return { address(), *++address_v6_iterator(address()) };
-  return {}; // { network(), XXX broadcast() XXX }; // TODO
+
+  address_v6::bytes_type __bytes = _M_addr.to_bytes();
+  int __nbytes = (_M_prefix_len + 7) / 8;
+  for (int __n = __nbytes; __n < 16; ++__n)
+   __bytes[__n] = 0xFF;
+  if (int __bits = (__nbytes * 8) - _M_prefix_len)
+   __bytes[__nbytes - 1] |= (1 << __bits) - 1;
+  address_v6 __last(__bytes, _M_addr.scope_id());
+  return { network(), *++address_v6_iterator(__last) };
 }
 
-constexpr network_v6
+_GLIBCXX17_CONSTEXPR network_v6
 canonical() const noexcept
 { return network_v6{network(), prefix_length()}; }
 
@@ -1379,7 +1397,7 @@ namespace ip
   to_string(const _Allocator& __a = _Allocator()) const
   {
return address().to_string(__a) + '/'
- + std::to_string(prefix_length());
++ std::to_string(prefix_length()).c_str();
   }
 
   private:
diff --git 
a/libstdc++-v3/testsuite/experimental/net/internet/network/v6/cons.cc 
b/libstdc++-v3/testsuite/experimental/net/internet/network/v6/cons.cc
new file mode 100644
index 000..9b4b791bd02
--- /dev/null
+++ b/libstdc++-v3/testsuite/experimental/net/internet/network/v6/cons.cc
@@ -0,0 +1,74 @@
+// { dg-do run { target c++14 } }
+// { dg-require-effective-target net_ts_ip }
+// { dg-add-options net_ts }
+
+#include 
+#include 
+#include 
+
+using std::experimental::net::ip::network_v6;
+using std::experimental::net::ip::address_v6;
+
+constexpr void
+test01()
+{
+  network_v6 n0;
+  VERIFY( n0.address().is_unspecified() );
+  VERIFY( n0.prefix_length() == 0 );
+}
+
+constexpr void
+test02()
+{
+  address_v6 a0;
+  network_v6 n0{ a0, 0 };
+  VERIFY( n0.address() == a0 );
+  VERIFY( n0.prefix_length() == 0 );
+
+  address_v6 a1{ address_v6::bytes_type{ 1, 2, 4, 8, 16, 32, 64, 128,
+3, 7, 47, 71, 83, 165, 199, 255 } };
+  network_v6 n1{ a1, 99};
+  VERIFY( n1.address() == a1 );
+  VERIFY( n1.prefix_length() == 99 );
+}
+
+void
+test02_errors()
+{
+  address_v6 a0;
+  try
+  {
+network_v6{a0, -1};
+VERIFY(false);
+  }
+  catch(const std::out_of_range&)
+  {
+  }
+
+  try
+  {
+network_v6{a0, 129};
+VERIFY(false);
+  }
+  catch(const std::out_of_range&)
+  {
+  }
+}
+
+constexpr bool
+test_constexpr()
+{
+  test01();
+  test02();
+  return true;
+}
+
+int
+main()
+{
+  test01();
+  test02();
+  test02_errors();
+
+  static_assert( test_constexpr(), "valid in constant expressions" );
+}
-- 
2.43.0



[committed 2/2] libstdc++: Fix invalid order in PSTL inplace_merge test [PR90276]

2024-02-02 Thread Jonathan Wakely
Tested x86_64-linux. Pushed to trunk.

-- >8 --

This looks like a typo in the upstream test that causes a failure in
debug mode. It has been reported upstream.

libstdc++-v3/ChangeLog:

PR libstdc++/90276
* testsuite/25_algorithms/pstl/alg_merge/inplace_merge.cc: Fix
comparison function to use less-than instead of equality.
---
 .../testsuite/25_algorithms/pstl/alg_merge/inplace_merge.cc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/libstdc++-v3/testsuite/25_algorithms/pstl/alg_merge/inplace_merge.cc 
b/libstdc++-v3/testsuite/25_algorithms/pstl/alg_merge/inplace_merge.cc
index 576f22423b8..a9205553574 100644
--- a/libstdc++-v3/testsuite/25_algorithms/pstl/alg_merge/inplace_merge.cc
+++ b/libstdc++-v3/testsuite/25_algorithms/pstl/alg_merge/inplace_merge.cc
@@ -160,7 +160,7 @@ main()
 test_by_type(
 [](std::size_t idx){ return MemoryChecker{std::int32_t(idx * 2)}; },
 [](std::size_t idx){ return MemoryChecker{std::int32_t(idx * 2 + 1)}; 
},
-[](const MemoryChecker& val1, const MemoryChecker& val2){ return 
val1.value() == val2.value(); });
+[](const MemoryChecker& val1, const MemoryChecker& val2){ return 
val1.value() < val2.value(); });
 EXPECT_FALSE(MemoryChecker::alive_objects() < 0, "wrong effect from 
inplace_merge: number of ctors calls < num of dtors calls");
 EXPECT_FALSE(MemoryChecker::alive_objects() > 0, "wrong effect from 
inplace_merge: number of ctors calls > num of dtors calls");
 
-- 
2.43.0



[committed 1/2] libstdc++: Avoid reusing moved-from iterators in PSTL tests [PR90276]

2024-02-02 Thread Jonathan Wakely
Tested x86_64-linux. Pushed to trunk.

-- >8 --

The reverse_invoker utility for PSTL tests uses forwarding references for
all parameters, but some of those parameters get forwarded to move
constructors which then leave the objects in a moved-from state. When
the parameters are forwarded a second time that results in making new
copies of moved-from iterators.  For libstdc++ debug mode iterators, the
moved-from state is singular, which means copying them will abort at
runtime.

The fix is to make copies of iterator arguments instead of forwarding
them.

The callers of reverse_invoker::operator() also forward the iterators
multiple times, but that's OK because reverse_invoker accepts them by
forwarding reference but then breaks the chain of forwarding and copies
them as lvalues.

libstdc++-v3/ChangeLog:

PR libstdc++/90276
* testsuite/util/pstl/test_utils.h (reverse_invoker): Do not use
perfect forwarding for iterator arguments.
---
 libstdc++-v3/testsuite/util/pstl/test_utils.h | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/libstdc++-v3/testsuite/util/pstl/test_utils.h 
b/libstdc++-v3/testsuite/util/pstl/test_utils.h
index ed6d48b9471..e35084eabb2 100644
--- a/libstdc++-v3/testsuite/util/pstl/test_utils.h
+++ b/libstdc++-v3/testsuite/util/pstl/test_utils.h
@@ -1083,18 +1083,18 @@ struct iterator_invoker
 template 
 struct reverse_invoker
 {
-template 
+template 
 void
-operator()(Rest&&... rest)
+operator()(Policy&& exec, Op op, Rest&&... rest)
 {
 // Random-access iterator
-iterator_invoker()(std::forward(rest)...);
+iterator_invoker()(std::forward(exec), op, rest...);
 
 // Forward iterator
-iterator_invoker()(std::forward(rest)...);
+iterator_invoker()(std::forward(exec), op, rest...);
 
 // Bidirectional iterator
-iterator_invoker()(std::forward(rest)...);
+iterator_invoker()(std::forward(exec), op, rest...);
 }
 };
 
-- 
2.43.0



[PATCH] c++: Don't advertise cxx_constexpr_string_builtins [PR113658]

2024-02-02 Thread Alex Coplan
Bootstrapped/regtested on x86_64-apple-darwin, OK for trunk?

Thanks,
Alex

-- >8 --

When __has_feature was introduced for GCC 14, I included the feature
cxx_constexpr_string_builtins, since of the relevant string builtins
that GCC implements, it seems to support constexpr evaluation of those
builtins.

However, as the PR shows, GCC doesn't implement the full list of
builtins in the clang documentation.  After enumerating the builtins,
the clang docs [1] say:

> Support for constant expression evaluation for the above builtins can
> be detected with __has_feature(cxx_constexpr_string_builtins).

and a strict reading of this would suggest we can't really support
constexpr evaluation of a builtin if we don't implement the builtin in
the first place.

So the conservatively correct thing to do seems to be to stop
advertising the feature altogether to avoid failing to build code which
assumes the presence of this feature implies the presence of all the
builtins listed in the clang documentation.

[1] : https://clang.llvm.org/docs/LanguageExtensions.html#string-builtins

gcc/cp/ChangeLog:

PR c++/113658
* cp-objcp-common.cc (cp_feature_table): Remove entry for
cxx_constexpr_string_builtins.

gcc/testsuite/ChangeLog:

PR c++/113658
* g++.dg/ext/pr113658.C: New test.
diff --git a/gcc/cp/cp-objcp-common.cc b/gcc/cp/cp-objcp-common.cc
index f06edf04ef0..85dde0459fa 100644
--- a/gcc/cp/cp-objcp-common.cc
+++ b/gcc/cp/cp-objcp-common.cc
@@ -110,7 +110,6 @@ static constexpr cp_feature_info cp_feature_table[] =
   { "cxx_alignof", cxx11 },
   { "cxx_attributes", cxx11 },
   { "cxx_constexpr", cxx11 },
-  { "cxx_constexpr_string_builtins", cxx11 },
   { "cxx_decltype", cxx11 },
   { "cxx_decltype_incomplete_return_types", cxx11 },
   { "cxx_default_function_template_args", cxx11 },
diff --git a/gcc/testsuite/g++.dg/ext/pr113658.C 
b/gcc/testsuite/g++.dg/ext/pr113658.C
new file mode 100644
index 000..f4a34888f28
--- /dev/null
+++ b/gcc/testsuite/g++.dg/ext/pr113658.C
@@ -0,0 +1,13 @@
+// { dg-do compile }
+// { dg-options "" }
+
+// PR113658: we shouldn't declare support for cxx_constexpr_string_builtins as
+// GCC is missing some of the builtins that clang implements.
+
+#if __has_feature (cxx_constexpr_string_builtins)
+#error
+#endif
+
+#if __has_extension (cxx_constexpr_string_builtins)
+#error
+#endif


[committed] libstdc++: Allow explicit conversion of string views with different traits

2024-02-02 Thread Jonathan Wakely
Tested aarch64-linux. Pushed to trunk.

-- >8 --

This was changed by LWG 3857.

libstdc++-v3/ChangeLog:

* include/std/string_view (basic_string_view(R&&)): Remove
constraint that traits_type must be the same, as per LWG 3857.
* testsuite/21_strings/basic_string_view/cons/char/range_c++20.cc:
Explicit conversion between different specializations should be
allowed.
* testsuite/21_strings/basic_string_view/cons/wchar_t/range_c++20.cc:
Likewise.
---
 libstdc++-v3/include/std/string_view  |  2 --
 .../cons/char/range_c++20.cc  | 21 ---
 .../cons/wchar_t/range_c++20.cc   | 21 ---
 3 files changed, 8 insertions(+), 36 deletions(-)

diff --git a/libstdc++-v3/include/std/string_view 
b/libstdc++-v3/include/std/string_view
index b444b5b9a39..e30a9c1768e 100644
--- a/libstdc++-v3/include/std/string_view
+++ b/libstdc++-v3/include/std/string_view
@@ -167,8 +167,6 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
  && (!requires (_DRange& __d) {
__d.operator ::std::basic_string_view<_CharT, _Traits>();
  })
- && (!requires { typename _DRange::traits_type; }
- || is_same_v)
constexpr explicit
basic_string_view(_Range&& __r)
noexcept(noexcept(ranges::size(__r)) && noexcept(ranges::data(__r)))
diff --git 
a/libstdc++-v3/testsuite/21_strings/basic_string_view/cons/char/range_c++20.cc 
b/libstdc++-v3/testsuite/21_strings/basic_string_view/cons/char/range_c++20.cc
index 5d0396563fd..bae8da1d264 100644
--- 
a/libstdc++-v3/testsuite/21_strings/basic_string_view/cons/char/range_c++20.cc
+++ 
b/libstdc++-v3/testsuite/21_strings/basic_string_view/cons/char/range_c++20.cc
@@ -115,23 +115,10 @@ test02()
   static_assert( ! std::is_constructible_v );
 
   using V2 = std::basic_string_view>;
-  // V2::traits_type is not the right type
-  static_assert( ! std::is_constructible_v );
-
-  struct V3 : V2
-  {
-  private:
-using V2::traits_type;
-  };
-  // V3::traits_type is not a valid (accessible) type
-  static_assert( std::is_constructible_v );
-
-  struct V4 : V2
-  {
-using traits_type = std::string_view::traits_type;
-  };
-  // V4::traits_type is the right type
-  static_assert( std::is_constructible_v );
+  // LWG 3857
+  // basic_string_view should allow explicit conversion when only traits vary
+  static_assert( std::is_constructible_v );
+  static_assert( ! std::is_convertible_v );
 }
 
 void
diff --git 
a/libstdc++-v3/testsuite/21_strings/basic_string_view/cons/wchar_t/range_c++20.cc
 
b/libstdc++-v3/testsuite/21_strings/basic_string_view/cons/wchar_t/range_c++20.cc
index d6996a1dd6f..3cf154d8602 100644
--- 
a/libstdc++-v3/testsuite/21_strings/basic_string_view/cons/wchar_t/range_c++20.cc
+++ 
b/libstdc++-v3/testsuite/21_strings/basic_string_view/cons/wchar_t/range_c++20.cc
@@ -115,23 +115,10 @@ test02()
   static_assert( ! std::is_constructible_v );
 
   using V2 = std::basic_string_view>;
-  // V2::traits_type is not the right type
-  static_assert( ! std::is_constructible_v );
-
-  struct V3 : V2
-  {
-  private:
-using V2::traits_type;
-  };
-  // V3::traits_type is not a valid (accessible) type
-  static_assert( std::is_constructible_v );
-
-  struct V4 : V2
-  {
-using traits_type = std::wstring_view::traits_type;
-  };
-  // V4::traits_type is the right type
-  static_assert( std::is_constructible_v );
+  // LWG 3857
+  // basic_string_view should allow explicit conversion when only traits vary
+  static_assert( std::is_constructible_v );
+  static_assert( ! std::is_convertible_v );
 }
 
 void
-- 
2.43.0



[committed] libstdc++: Remove noexcept from std::osyncstream::operator=

2024-02-02 Thread Jonathan Wakely
Tested aarch64-linux. Pushed to trunk.

-- >8 --

This should not be noexcept because its _M_syncbuf member has a
potentially-throwing move assignment operator. The noexcept was removed
by LWG 3867.

libstdc++-v3/ChangeLog:

* include/std/syncstream (basic_osyncstream::operator=): Remove
noexcept, as per LWG 3867.
---
 libstdc++-v3/include/std/syncstream | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libstdc++-v3/include/std/syncstream 
b/libstdc++-v3/include/std/syncstream
index a84c93a61ee..08a901b62fd 100644
--- a/libstdc++-v3/include/std/syncstream
+++ b/libstdc++-v3/include/std/syncstream
@@ -285,7 +285,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
   ~basic_osyncstream() = default;
 
-  basic_osyncstream& operator=(basic_osyncstream&&) noexcept = default;
+  basic_osyncstream& operator=(basic_osyncstream&&) = default;
 
   syncbuf_type* rdbuf() const noexcept
   { return const_cast(&_M_syncbuf); }
-- 
2.43.0



[committed] libstdc++: Remove noexcept from std::generator::promise_type::yield_value

2024-02-02 Thread Jonathan Wakely
Tested aarch64-linux. Pushed to trunk.

-- >8 --

This overload of std::generator::promise_type::yield_value calls things
which might throw, so should not be noexcept. The noexcept was remove by
LWG 3894.

libstdc++-v3/ChangeLog:

* include/std/generator (promise_type::yield_value): Remove
noexcept from fourth overload, as per LWG 3894.
---
 libstdc++-v3/include/std/generator | 1 -
 1 file changed, 1 deletion(-)

diff --git a/libstdc++-v3/include/std/generator 
b/libstdc++-v3/include/std/generator
index e7ef5ddfdd3..87983ee5e7c 100644
--- a/libstdc++-v3/include/std/generator
+++ b/libstdc++-v3/include/std/generator
@@ -155,7 +155,6 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
requires convertible_to, _Yielded>
auto
yield_value(ranges::elements_of<_R, _Alloc> __r)
- noexcept
{
  auto __n = [] (allocator_arg_t, _Alloc,
 ranges::iterator_t<_R> __i,
-- 
2.43.0



Re: [PATCH] testsuite: i386: Fix gcc.target/i386/pr71321.c on Solaris/x86

2024-02-02 Thread Uros Bizjak
On Fri, Feb 2, 2024 at 9:59 AM Rainer Orth  
wrote:
>
> gcc.target/i386/pr71321.c FAILs on 64-bit Solaris/x86 with the native
> assembler:
>
> FAIL: gcc.target/i386/pr71321.c scan-assembler-not lea.*0
>
> The problem is that /bin/as doesn't fully support cfi directives, so the
> .eh_frame section is specified explicitly, which includes ".long 0".
> The regular expression above includes ".*", which does multiline
> matches.  AFAICS those aren't needed here.
>
> This patch changes the RE not to use multiline patches.
>
> Tested on i386-pc-solaris2.11 (as and gas) and i686-pc-linux-gnu.
>
> Ok for trunk?

OK.

Thanks,
Uros.

>
> Rainer
>
> --
> -
> Rainer Orth, Center for Biotechnology, Bielefeld University
>
>
> 2024-02-01  Rainer Orth  
>
> gcc/testsuite:
> * gcc.target/i386/pr71321.c (scan-assembler-not): Avoid multiline
> matches.
>


Re: [PATCH]middle-end: check memory accesses in the destination block [PR113588].

2024-02-02 Thread Richard Biener



> Am 01.02.2024 um 22:34 schrieb Tamar Christina :
> 
> 
>> 
>>> 
>>> If the above is correct then I think I understand what you're saying and
>>> will update the patch and do some Checks.
>> 
>> Yes, I think that's what I wanted to say.
>> 
> 
> As discussed:
> 
> Bootstrapped Regtested on aarch64-none-linux-gnu and x86_64-pc-linux-gnu no 
> issues.
> Also checked both with --enable-lto --with-build-config='bootstrap-O3 
> bootstrap-lto' --enable-multilib
> and --enable-lto --with-build-config=bootstrap-O3 
> --enable-checking=release,yes,rtl,extra;
> and checked the libcrypt testsuite as reported on PR113467.
> 
> Ok for master?

Ok

Richard 

> Thanks,
> Tamar
> 
> gcc/ChangeLog:
> 
>PR tree-optimization/113588
>PR tree-optimization/113467
>(vect_analyze_data_ref_dependence):  Choose correct dest and fix checks.
>(vect_analyze_early_break_dependences): Update comments.
> 
> gcc/testsuite/ChangeLog:
> 
>PR tree-optimization/113588
>PR tree-optimization/113467
>* gcc.dg/vect/vect-early-break_108-pr113588.c: New test.
>* gcc.dg/vect/vect-early-break_109-pr113588.c: New test.
> 
> --- inline copy of patch ---
> 
> diff --git a/gcc/testsuite/gcc.dg/vect/vect-early-break_108-pr113588.c 
> b/gcc/testsuite/gcc.dg/vect/vect-early-break_108-pr113588.c
> new file mode 100644
> index 
> ..e488619c9aac41fafbcf479818392a6bb7c6924f
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/vect/vect-early-break_108-pr113588.c
> @@ -0,0 +1,15 @@
> +/* { dg-do compile } */
> +/* { dg-add-options vect_early_break } */
> +/* { dg-require-effective-target vect_early_break } */
> +/* { dg-require-effective-target vect_int } */
> +
> +/* { dg-final { scan-tree-dump-not "LOOP VECTORIZED" "vect" } } */
> +
> +int foo (const char *s, unsigned long n)
> +{
> + unsigned long len = 0;
> + while (*s++ && n--)
> +   ++len;
> + return len;
> +}
> +
> diff --git a/gcc/testsuite/gcc.dg/vect/vect-early-break_109-pr113588.c 
> b/gcc/testsuite/gcc.dg/vect/vect-early-break_109-pr113588.c
> new file mode 100644
> index 
> ..488c19d3ede809631d1a7ede0e7f7bcdc7a1ae43
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/vect/vect-early-break_109-pr113588.c
> @@ -0,0 +1,44 @@
> +/* { dg-add-options vect_early_break } */
> +/* { dg-require-effective-target vect_early_break } */
> +/* { dg-require-effective-target vect_int } */
> +/* { dg-require-effective-target mmap } */
> +
> +/* { dg-final { scan-tree-dump-not "LOOP VECTORIZED" "vect" } } */
> +
> +#include 
> +#include 
> +
> +#include "tree-vect.h"
> +
> +__attribute__((noipa))
> +int foo (const char *s, unsigned long n)
> +{
> + unsigned long len = 0;
> + while (*s++ && n--)
> +   ++len;
> + return len;
> +}
> +
> +int main()
> +{
> +
> +  check_vect ();
> +
> +  long pgsz = sysconf (_SC_PAGESIZE);
> +  void *p = mmap (NULL, pgsz * 3, PROT_READ|PROT_WRITE,
> + MAP_ANONYMOUS|MAP_PRIVATE, 0, 0);
> +  if (p == MAP_FAILED)
> +return 0;
> +  mprotect (p, pgsz, PROT_NONE);
> +  mprotect (p+2*pgsz, pgsz, PROT_NONE);
> +  char *p1 = p + pgsz;
> +  p1[0] = 1;
> +  p1[1] = 0;
> +  foo (p1, 1000);
> +  p1 = p + 2*pgsz - 2;
> +  p1[0] = 1;
> +  p1[1] = 0;
> +  foo (p1, 1000);
> +  return 0;
> +}
> +
> diff --git a/gcc/tree-vect-data-refs.cc b/gcc/tree-vect-data-refs.cc
> index 
> f592aeb8028afd4fd70e2175104efab2a2c0d82e..53fdfc25d7dc2deb7788176252697d2e45fc
>  100644
> --- a/gcc/tree-vect-data-refs.cc
> +++ b/gcc/tree-vect-data-refs.cc
> @@ -619,10 +619,10 @@ vect_analyze_data_ref_dependence (struct 
> data_dependence_relation *ddr,
>   return opt_result::success ();
> }
> 
> -/* Funcion vect_analyze_early_break_dependences.
> +/* Function vect_analyze_early_break_dependences.
> 
> -   Examime all the data references in the loop and make sure that if we have
> -   mulitple exits that we are able to safely move stores such that they 
> become
> +   Examine all the data references in the loop and make sure that if we have
> +   multiple exits that we are able to safely move stores such that they 
> become
>safe for vectorization.  The function also calculates the place where to 
> move
>the instructions to and computes what the new vUSE chain should be.
> 
> @@ -639,7 +639,7 @@ vect_analyze_data_ref_dependence (struct 
> data_dependence_relation *ddr,
>  - Multiple loads are allowed as long as they don't alias.
> 
>NOTE:
> - This implemementation is very conservative. Any overlappig loads/stores
> + This implementation is very conservative. Any overlapping loads/stores
>  that take place before the early break statement gets rejected aside from
>  WAR dependencies.
> 
> @@ -668,7 +668,6 @@ vect_analyze_early_break_dependences (loop_vec_info 
> loop_vinfo)
>   auto_vec bases;
>   basic_block dest_bb = NULL;
> 
> -  hash_set  visited;
>   class loop *loop = LOOP_VINFO_LOOP (loop_vinfo);
>   class loop *loop_nest = loop_outer (loop);
> 
> @@ -677,19 +676,33 @@ vect_analyz

Re: [PATCH] lower-bitint: Handle uninitialized large/huge SSA_NAMEs as inline asm inputs [PR113699]

2024-02-02 Thread Richard Biener



> Am 02.02.2024 um 10:41 schrieb Jakub Jelinek :
> 
> Hi!
> 
> Similar problem to calls with uninitialized large/huge _BitInt SSA_NAME
> arguments, var_to_partition will not work for those, but unlike calls
> where we just create a new uninitialized SSA_NAME here we need to change
> the inline asm input to be an uninitialized VAR_DECL.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

Ok

Richard 

> 2024-02-02  Jakub Jelinek  
> 
>PR middle-end/113699
>* gimple-lower-bitint.cc (bitint_large_huge::lower_asm): Handle
>uninitialized large/huge _BitInt SSA_NAME inputs.
> 
>* gcc.dg/bitint-81.c: New test.
> 
> --- gcc/gimple-lower-bitint.cc.jj2024-01-31 10:55:42.677095630 +0100
> +++ gcc/gimple-lower-bitint.cc2024-02-01 10:36:08.408867602 +0100
> @@ -5200,9 +5200,18 @@ bitint_large_huge::lower_asm (gimple *st
>  && TREE_CODE (TREE_TYPE (s)) == BITINT_TYPE
>  && bitint_precision_kind (TREE_TYPE (s)) >= bitint_prec_large)
>{
> -  int part = var_to_partition (m_map, s);
> -  gcc_assert (m_vars[part] != NULL_TREE);
> -  TREE_VALUE (t) = m_vars[part];
> +  if (SSA_NAME_IS_DEFAULT_DEF (s)
> +  && (!SSA_NAME_VAR (s) || VAR_P (SSA_NAME_VAR (s
> +{
> +  TREE_VALUE (t) = create_tmp_var (TREE_TYPE (s), "bitint");
> +  mark_addressable (TREE_VALUE (t));
> +}
> +  else
> +{
> +  int part = var_to_partition (m_map, s);
> +  gcc_assert (m_vars[part] != NULL_TREE);
> +  TREE_VALUE (t) = m_vars[part];
> +}
>}
> }
>   update_stmt (stmt);
> --- gcc/testsuite/gcc.dg/bitint-81.c.jj2024-02-01 10:38:26.132937531 +0100
> +++ gcc/testsuite/gcc.dg/bitint-81.c2024-02-01 10:38:01.628280939 +0100
> @@ -0,0 +1,12 @@
> +/* PR middle-end/113699 */
> +/* { dg-do compile { target bitint } } */
> +/* { dg-options "-O2 -std=c23" } */
> +
> +void
> +foo (void)
> +{
> +#if __BITINT_MAXWIDTH__ >= 129
> +  _BitInt(129) i;
> +  __asm__ ("" : : "rm" (i));
> +#endif
> +}
> 
>Jakub
> 


Re: [PATCH] lower-bitint: Handle casts from large/huge _BitInt to pointer/reference types [PR113692]

2024-02-02 Thread Richard Biener



> Am 02.02.2024 um 10:53 schrieb Jakub Jelinek :
> 
> Hi!
> 
> I thought one needs to cast first to pointer-sized integer before casting to
> pointer, but apparently that is not the case.
> So the following patch arranges for the large/huge _BitInt to
> pointer/reference conversions to use the same code as for conversions
> of them to small integral types.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

Ok

Richard 

> 2024-02-02  Jakub Jelinek  
> 
>PR tree-optimization/113692
>* gimple-lower-bitint.cc (bitint_large_huge::lower_stmt): Handle casts
>from large/huge BITINT_TYPEs to POINTER_TYPE/REFERENCE_TYPE as
>final_cast_p.
> 
>* gcc.dg/bitint-82.c: New test.
> 
> --- gcc/gimple-lower-bitint.cc.jj2024-02-01 10:36:08.408867602 +0100
> +++ gcc/gimple-lower-bitint.cc2024-02-01 11:47:21.233840956 +0100
> @@ -5264,7 +5264,8 @@ bitint_large_huge::lower_stmt (gimple *s
>mergeable_cast_p = true;
>   else if (TREE_CODE (TREE_TYPE (rhs1)) == BITINT_TYPE
>   && bitint_precision_kind (TREE_TYPE (rhs1)) >= bitint_prec_large
> -   && INTEGRAL_TYPE_P (TREE_TYPE (lhs)))
> +   && (INTEGRAL_TYPE_P (TREE_TYPE (lhs))
> +   || POINTER_TYPE_P (TREE_TYPE (lhs
>{
>  final_cast_p = true;
>  if (TREE_CODE (rhs1) == SSA_NAME
> @@ -5393,8 +5394,9 @@ bitint_large_huge::lower_stmt (gimple *s
> be needed.  */
>   gcc_assert (TYPE_PRECISION (lhs_type) <= 2 * limb_prec);
>   gimple *g;
> -  if (TREE_CODE (lhs_type) == BITINT_TYPE
> -  && bitint_precision_kind (lhs_type) == bitint_prec_middle)
> +  if ((TREE_CODE (lhs_type) == BITINT_TYPE
> +   && bitint_precision_kind (lhs_type) == bitint_prec_middle)
> +  || POINTER_TYPE_P (lhs_type))
>lhs_type = build_nonstandard_integer_type (TYPE_PRECISION (lhs_type),
>   TYPE_UNSIGNED (lhs_type));
>   m_data_cnt = 0;
> --- gcc/testsuite/gcc.dg/bitint-82.c.jj2024-02-01 11:55:37.995866642 +0100
> +++ gcc/testsuite/gcc.dg/bitint-82.c2024-02-01 11:54:16.998003815 +0100
> @@ -0,0 +1,18 @@
> +/* PR tree-optimization/113692 */
> +/* { dg-do compile { target bitint } } */
> +/* { dg-options "-O2 -std=c23" } */
> +
> +#if __BITINT_MAXWIDTH__ >= 135
> +_BitInt(135) i;
> +#else
> +_BitInt(63) i;
> +#endif
> +
> +void *
> +foo (void)
> +{
> +  void *ret = 0;
> +  if (i & 1)
> +ret = (void *) 1;
> +  return ret;
> +}
> 
>Jakub
> 


Re: [PATCH] tree-ssa-math-opts: Fix is_widening_mult_rhs_p - unbreak bootstrap [PR113705]

2024-02-02 Thread Richard Biener



> Am 01.02.2024 um 23:46 schrieb Jakub Jelinek :
> 
> On Tue, Jan 30, 2024 at 07:33:10AM -, Roger Sayle wrote:
> + wide_int bits = wide_int::from (tree_nonzero_bits (rhs),
>   
>   
> + prec,   
>   
>   
> + TYPE_SIGN (TREE_TYPE (rhs)));   
>   
>   
> ...
>> +  if (gimple_assign_rhs_code (stmt) == BIT_AND_EXPR
>> +  && TREE_CODE (gimple_assign_rhs2 (stmt)) == INTEGER_CST
>> +  && wi::to_wide (gimple_assign_rhs2 (stmt))
>> + == wi::mask (hprec, false, prec))
> 
> This change broke bootstrap on aarch64-linux.
> The problem can be seen even on the reduced testcase.
> 
> The IL on the unreduced testcase before widening_mul has:
>  # val_583 = PHI 
> ...
>  pretmp_266 = MEM[(const struct wide_int_storage *)&D.160657].len;
>  _264 = pretmp_266 & 65535;
> ...
>  _176 = (sizetype) val_583;
>  _439 = (sizetype) _264;
>  _284 = _439 * 8;
>  _115 = _176 + _284;
> where 583/266/264 have unsigned int type and 176/439/284/115 have sizetype.
> widening_mul first turns that into:
>  # val_583 = PHI 
> ...
>  pretmp_266 = MEM[(const struct wide_int_storage *)&D.160657].len;
>  _264 = pretmp_266 & 65535;
> ...
>  _176 = (sizetype) val_583;
>  _439 = (sizetype) _264;
>  _284 = _264 w* 8;
>  _115 = _176 + _284;
> and then is_widening_mult_rhs_p is called, with type sizetype (64-bit),
> rhs _264, hprec 32 and prec 64.  Now tree_nonzero_bits (rhs) is
> 65535, so bits is 64-bit wide_int 65535, stmt is BIT_AND_EXPR,
> but we ICE on the
> wi::to_wide (gimple_assign_rhs2 (stmt)) == wi::mask (hprec, false, prec)
> comparison because wi::to_wide on gimple_assign_rhs2 (stmt) - unsigned int
> 65535 gives 32-bit wide_int 65535, while wi::mask (hprec, false, prec)
> gives 64-bit wide_int 0x and comparison between different precision
> wide_ints is forbidden.
> 
> The following patch fixes it the same way how bits is computed earlier,
> by calling wide_int::from on the wi::to_wide (gimple_assign_rhs2 (stmt)),
> so we compare 64-bit 65535 with 64-bit 0x.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux plus tested on the
> testcase using cross to aarch64-linux, ok for trunk?

Ok

Richard 
> 2024-02-01  Jakub Jelinek  
> 
>PR middle-end/113705
>* tree-ssa-math-opts.cc (is_widening_mult_rhs_p): Use wide_int_from
>around wi::to_wide in order to compare value in prec precision.
> 
>* g++.dg/opt/pr113705.C: New test.
> 
> --- gcc/tree-ssa-math-opts.cc.jj2024-02-01 09:14:16.623549514 +0100
> +++ gcc/tree-ssa-math-opts.cc2024-02-01 17:48:59.151771177 +0100
> @@ -2572,7 +2572,8 @@ is_widening_mult_rhs_p (tree type, tree
>  if (is_gimple_assign (stmt)
>  && gimple_assign_rhs_code (stmt) == BIT_AND_EXPR
>  && TREE_CODE (gimple_assign_rhs2 (stmt)) == INTEGER_CST
> -  && wi::to_wide (gimple_assign_rhs2 (stmt))
> +  && wide_int::from (wi::to_wide (gimple_assign_rhs2 (stmt)),
> + prec, TYPE_SIGN (TREE_TYPE (rhs)))
> == wi::mask (hprec, false, prec))
>*new_rhs_out = gimple_assign_rhs1 (stmt);
>  else
> --- gcc/testsuite/g++.dg/opt/pr113705.C.jj2024-02-01 19:02:29.181388575 
> +0100
> +++ gcc/testsuite/g++.dg/opt/pr113705.C2024-02-01 19:03:03.211918152 +0100
> @@ -0,0 +1,68 @@
> +// PR middle-end/113705
> +// { dg-do compile { target c++17 } }
> +// { dg-options "-O2 -w" }
> +
> +void foo ();
> +template  struct A : T { long bar () const; };
> +int a;
> +
> +template 
> +long
> +A::bar () const
> +{
> +  return this->baz ()[a];
> +}
> +
> +struct B {
> +  struct { long b[1]; long c; } u;
> +  unsigned d;
> +  int e;
> +  B (const B &);
> +  ~B ();
> +  const long *baz () const;
> +  unsigned qux () const;
> +};
> +
> +B::B (const B &)
> +{
> +  if (__builtin_expect (e, 0))
> +u.c = 0;
> +}
> +
> +B::~B ()
> +{
> +  if (__builtin_expect (e, 0))
> +foo ();
> +}
> +
> +const long *
> +B::baz () const
> +{
> +  return u.b;
> +}
> +
> +unsigned
> +B::qux () const
> +{
> +  return d;
> +}
> +
> +struct C { A corge () const; A *f; };
> +
> +A
> +C::corge () const
> +{
> +  return f[1];
> +}
> +
> +void
> +test (C r, long *h, unsigned short *d)
> +{
> +  for (int j = 0; j < 8; ++j)
> +{
> +  A g = r.corge ();
> +  *d = g.qux ();
> +  for (unsigned i = 0; i < *d; ++i)
> +*h++ = g.bar ();
> +}
> +}
> 
> 
>Jakub
> 


Re: [PATCH] gcc/configure: Re-introduce INSTALL_INFO

2024-02-02 Thread rep . dot . nop
On 1 February 2024 18:15:34 CET, Christophe Lyon  
wrote:
>BUILD_INFO is currently a byproduct of checking makeinfo
>presence/version.  INSTALL_INFO used to be defined similarly, but was
>removed in 2000 (!) by commit 17db658241d18cf6db59d31bc2d6eac96e9257df
>(svn r38141).
>
>In order to save build time, our CI overrides BUILD_INFO="", which
>works when invoking 'make all' but not for 'make install' in case some
>info files need an update.

Instead of resurrecting INSTALL_INFO maybe you could something along the lines 
of

https://gcc.gnu.org/bugzilla/attachment.cgi?id=15038&action=edit

not sure which approach would be considered cleaner..

HTH


Re: [PATCH] LoongArch: libsanitizer: Enable build lsan and tsan for loongarch64.

2024-02-02 Thread Jakub Jelinek
On Tue, Jan 30, 2024 at 10:09:51AM +0800, Lulu Cheng wrote:
> From: chenguoqi 
> 
> libsanitizer/ChangeLog:
> 
>   * configure.tgt: Enable tsan and lsan for loongarch64.
>   * tsan/Makefile.am: Add tsan_rtl_loongarch64.S to 
> EXTRA_libtsan_la_SOURCES.

This line is too long and should read
* tsan/Makefile.am (EXTRA_libtsan_la_SOURCES): Add
tsan_rtl_loongarch64.S.

>   * tsan/Makefile.in: Regenerate.

Otherwise LGTM.

Jakub



[PATCH] LoongArch: Avoid out-of-bounds access in loongarch_symbol_insns

2024-02-02 Thread Xi Ruoyao
We call loongarch_symbol_insns with mode = MAX_MACHINE_MODE sometimes.
But in loongarch_symbol_insns:

if (LSX_SUPPORTED_MODE_P (mode) || LASX_SUPPORTED_MODE_P (mode))
  return 0;

And LSX_SUPPORTED_MODE_P is defined as:

#define LSX_SUPPORTED_MODE_P(MODE) \
  (ISA_HAS_LSX \
   && GET_MODE_SIZE (MODE) == UNITS_PER_LSX_REG ... ...

GET_MODE_SIZE is expanded to a call to mode_to_bytes, which is defined:

ALWAYS_INLINE poly_uint16
mode_to_bytes (machine_mode mode)
{
#if GCC_VERSION >= 4001
  return (__builtin_constant_p (mode)
  ? mode_size_inline (mode) : mode_size[mode]);
#else
  return mode_size[mode];
#endif
}

There is an assertion in mode_size_inline:

gcc_assert (mode >= 0 && mode < NUM_MACHINE_MODES);

Note that NUM_MACHINE_MODES = MAX_MACHINE_MODE (emitted by genmodes.cc),
thus if __builtin_constant_p (mode) is evaluated true (it happens when
GCC is bootstrapped with LTO+PGO), the assertion will be triggered and
cause an ICE.  OTOH if __builtin_constant_p (mode) is evaluated false,
mode_size[mode] is still an out-of-bound array access (the length or the
mode_size array is NUM_MACHINE_MODES).

So we shouldn't call LSX_SUPPORTED_MODE_P or LASX_SUPPORTED_MODE_P with
MAX_MACHINE_MODE in loongarch_symbol_insns.  This is very similar to a
MIPS bug PR98491 fixed by me about 3 years ago.

gcc/ChangeLog:

* config/loongarch/loongarch.cc (loongarch_symbol_insns): Do not
use LSX_SUPPORTED_MODE_P or LASX_SUPPORTED_MODE_P if mode is
MAX_MACHINE_MODE.
---

Bootstrapped and regtested on loongarch64-linux-gnu.  Ok for trunk?

 gcc/config/loongarch/loongarch.cc | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/gcc/config/loongarch/loongarch.cc 
b/gcc/config/loongarch/loongarch.cc
index 963e86d61af..6badef45d62 100644
--- a/gcc/config/loongarch/loongarch.cc
+++ b/gcc/config/loongarch/loongarch.cc
@@ -2007,7 +2007,8 @@ loongarch_symbol_insns (enum loongarch_symbol_type type, 
machine_mode mode)
 {
   /* LSX LD.* and ST.* cannot support loading symbols via an immediate
  operand.  */
-  if (LSX_SUPPORTED_MODE_P (mode) || LASX_SUPPORTED_MODE_P (mode))
+  if (mode != MAX_MACHINE_MODE
+  && (LSX_SUPPORTED_MODE_P (mode) || LASX_SUPPORTED_MODE_P (mode)))
 return 0;
 
   switch (type)
-- 
2.43.0



[PATCH] testsuite: Add another bitint testcase [PR113691]

2024-02-02 Thread Jakub Jelinek
Hi!

This is fixed by the PR113692 patch.

Will commit as obvious if that patch makes it in.

2024-02-02  Jakub Jelinek  

PR tree-optimization/113691
* gcc.dg/bitint-83.c: New test.

--- gcc/testsuite/gcc.dg/bitint-83.c.jj 2024-02-01 12:32:39.555709390 +0100
+++ gcc/testsuite/gcc.dg/bitint-83.c2024-02-01 12:32:31.178826835 +0100
@@ -0,0 +1,23 @@
+/* PR tree-optimization/113691 */
+/* { dg-do compile { target bitint } } */
+/* { dg-options "-O2 -std=gnu11 -w" } */
+
+#if __BITINT_MAXWIDTH__ >= 944
+_BitInt (944) i;
+#else
+_BitInt (63) i;
+#endif
+
+void foo ();
+
+void
+bar ()
+{
+  foo (i);
+}
+
+void
+foo (int *p)
+{
+  *p = 0;
+}

Jakub



[PATCH] lower-bitint: Handle casts from large/huge _BitInt to pointer/reference types [PR113692]

2024-02-02 Thread Jakub Jelinek
Hi!

I thought one needs to cast first to pointer-sized integer before casting to
pointer, but apparently that is not the case.
So the following patch arranges for the large/huge _BitInt to
pointer/reference conversions to use the same code as for conversions
of them to small integral types.

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

2024-02-02  Jakub Jelinek  

PR tree-optimization/113692
* gimple-lower-bitint.cc (bitint_large_huge::lower_stmt): Handle casts
from large/huge BITINT_TYPEs to POINTER_TYPE/REFERENCE_TYPE as
final_cast_p.

* gcc.dg/bitint-82.c: New test.

--- gcc/gimple-lower-bitint.cc.jj   2024-02-01 10:36:08.408867602 +0100
+++ gcc/gimple-lower-bitint.cc  2024-02-01 11:47:21.233840956 +0100
@@ -5264,7 +5264,8 @@ bitint_large_huge::lower_stmt (gimple *s
mergeable_cast_p = true;
   else if (TREE_CODE (TREE_TYPE (rhs1)) == BITINT_TYPE
   && bitint_precision_kind (TREE_TYPE (rhs1)) >= bitint_prec_large
-  && INTEGRAL_TYPE_P (TREE_TYPE (lhs)))
+  && (INTEGRAL_TYPE_P (TREE_TYPE (lhs))
+  || POINTER_TYPE_P (TREE_TYPE (lhs
{
  final_cast_p = true;
  if (TREE_CODE (rhs1) == SSA_NAME
@@ -5393,8 +5394,9 @@ bitint_large_huge::lower_stmt (gimple *s
 be needed.  */
   gcc_assert (TYPE_PRECISION (lhs_type) <= 2 * limb_prec);
   gimple *g;
-  if (TREE_CODE (lhs_type) == BITINT_TYPE
- && bitint_precision_kind (lhs_type) == bitint_prec_middle)
+  if ((TREE_CODE (lhs_type) == BITINT_TYPE
+  && bitint_precision_kind (lhs_type) == bitint_prec_middle)
+ || POINTER_TYPE_P (lhs_type))
lhs_type = build_nonstandard_integer_type (TYPE_PRECISION (lhs_type),
   TYPE_UNSIGNED (lhs_type));
   m_data_cnt = 0;
--- gcc/testsuite/gcc.dg/bitint-82.c.jj 2024-02-01 11:55:37.995866642 +0100
+++ gcc/testsuite/gcc.dg/bitint-82.c2024-02-01 11:54:16.998003815 +0100
@@ -0,0 +1,18 @@
+/* PR tree-optimization/113692 */
+/* { dg-do compile { target bitint } } */
+/* { dg-options "-O2 -std=c23" } */
+
+#if __BITINT_MAXWIDTH__ >= 135
+_BitInt(135) i;
+#else
+_BitInt(63) i;
+#endif
+
+void *
+foo (void)
+{
+  void *ret = 0;
+  if (i & 1)
+ret = (void *) 1;
+  return ret;
+}

Jakub



Re: [PATCH] RISC-V: Expand VLMAX scalar move in reduction

2024-02-02 Thread Kito Cheng
LGTM :)

On Fri, Feb 2, 2024 at 9:58 AM Juzhe-Zhong  wrote:
>
> This patch fixes the following:
>
> vsetvli a5,a1,e32,m1,tu,ma
> sllia4,a5,2
> sub a1,a1,a5
> vle32.v v2,0(a0)
> add a0,a0,a4
> vadd.vv v1,v2,v1
> bne a1,zero,.L3
> vsetivlizero,1,e32,m1,ta,ma
> vmv.s.x v2,zero
> vsetvli a5,zero,e32,m1,ta,ma  ---> Redundant vsetvl.
> vredsum.vs  v1,v1,v2
> vmv.x.s a0,v1
> ret
>
> VSETVL PASS is able to fuse avl = 1 of scalar move and VLMAX avl of reduction.
>
> However, this following RTL blocks the fusion in dependence analysis in 
> VSETVL PASS:
>
> (insn 49 24 50 5 (set (reg:RVVM1SI 98 v2 [148])
> (if_then_else:RVVM1SI (unspec:RVVMF32BI [
> (const_vector:RVVMF32BI [
> (const_int 1 [0x1])
> repeat [
> (const_int 0 [0])
> ]
> ])
> (const_int 1 [0x1])
> (const_int 2 [0x2]) repeated x2
> (const_int 0 [0])
> (reg:SI 66 vl)
> (reg:SI 67 vtype)
> ] UNSPEC_VPREDICATE)
> (const_vector:RVVM1SI repeat [
> (const_int 0 [0])
> ])
> (unspec:RVVM1SI [
> (reg:DI 0 zero)
> ] UNSPEC_VUNDEF))) 3813 {*pred_broadcastrvvm1si_zero}
>  (nil))
> (insn 50 49 51 5 (set (reg:DI 15 a5 [151])  >  It 
> set a5, blocks the following VLMAX into the scalar move above.
> (unspec:DI [
> (const_int 32 [0x20])
> ] UNSPEC_VLMAX)) 2566 {vlmax_avldi}
>  (expr_list:REG_EQUIV (unspec:DI [
> (const_int 32 [0x20])
> ] UNSPEC_VLMAX)
> (nil)))
> (insn 51 50 52 5 (set (reg:RVVM1SI 97 v1 [150])
> (unspec:RVVM1SI [
> (unspec:RVVMF32BI [
> (const_vector:RVVMF32BI repeat [
> (const_int 1 [0x1])
> ])
> (reg:DI 15 a5 [151])
> (const_int 2 [0x2])
> (const_int 1 [0x1])
> (reg:SI 66 vl)
> (reg:SI 67 vtype)
> ] UNSPEC_VPREDICATE)
> (unspec:RVVM1SI [
> (reg:RVVM1SI 97 v1 [orig:134 vect_result_14.6 ] [134])
> (reg:RVVM1SI 98 v2 [148])
> ] UNSPEC_REDUC_SUM)
> (unspec:RVVM1SI [
> (reg:DI 0 zero)
> ] UNSPEC_VUNDEF)
> ] UNSPEC_REDUC)) 17541 {pred_redsumrvvm1si}
>  (expr_list:REG_DEAD (reg:RVVM1SI 98 v2 [148])
> (expr_list:REG_DEAD (reg:SI 66 vl)
> (expr_list:REG_DEAD (reg:DI 15 a5 [151])
> (expr_list:REG_DEAD (reg:DI 0 zero)
> (nil))
>
> Such situation can only happen on auto-vectorization, never happen on 
> intrinsic codes.
> Since the reduction is passed VLMAX AVL, it should be more natural to pass 
> VLMAX to the scalar move which initial the value of the reduction.
>
> After this patch:
>
> vsetvli a5,a1,e32,m1,tu,ma
> sllia4,a5,2
> sub a1,a1,a5
> vle32.v v2,0(a0)
> add a0,a0,a4
> vadd.vv v1,v2,v1
> bne a1,zero,.L3
> vsetvli a5,zero,e32,m1,ta,ma
> vmv.s.x v2,zero
> vredsum.vs  v1,v1,v2
> vmv.x.s a0,v1
> ret
>
> Tested on both RV32/RV64 no regression.
>
> PR target/113697
>
> gcc/ChangeLog:
>
> * config/riscv/riscv-v.cc (expand_reduction): Pass VLMAX avl to 
> scalar move.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/riscv/rvv/autovec/pr113697.c: New test.
>
> ---
>  gcc/config/riscv/riscv-v.cc| 12 +++-
>  .../gcc.target/riscv/rvv/autovec/pr113697.c| 14 ++
>  2 files changed, 21 insertions(+), 5 deletions(-)
>  create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/autovec/pr113697.c
>
> diff --git a/gcc/config/riscv/riscv-v.cc b/gcc/config/riscv/riscv-v.cc
> index 4bacb7fea45..0cfbd21ce6f 100644
> --- a/gcc/config/riscv/riscv-v.cc
> +++ b/gcc/config/riscv/riscv-v.cc
> @@ -4151,13 +4151,15 @@ expand_reduction (unsigned unspec, unsigned 
> insn_flags, rtx *ops, rtx init)
>
>rtx m1_tmp = gen_reg_rtx (m1_mode);
>rtx scalar_move_ops[] = {m1_tmp, init};
> -  emit_nonvlmax_insn (code_for_pred_broadcast (m1_mode), SCALAR_MOVE_OP,
> - scalar_move_ops,
> - need_mask_operand_p (insn_flags) ? ops[3]
> -  : CONST1_RTX (Pmode));
> +  insn_code icode = code_for_pred_broadcast (m1_mode);
> +  if (need_mask_operand_p

[PATCH] lower-bitint: Handle uninitialized large/huge SSA_NAMEs as inline asm inputs [PR113699]

2024-02-02 Thread Jakub Jelinek
Hi!

Similar problem to calls with uninitialized large/huge _BitInt SSA_NAME
arguments, var_to_partition will not work for those, but unlike calls
where we just create a new uninitialized SSA_NAME here we need to change
the inline asm input to be an uninitialized VAR_DECL.

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

2024-02-02  Jakub Jelinek  

PR middle-end/113699
* gimple-lower-bitint.cc (bitint_large_huge::lower_asm): Handle
uninitialized large/huge _BitInt SSA_NAME inputs.

* gcc.dg/bitint-81.c: New test.

--- gcc/gimple-lower-bitint.cc.jj   2024-01-31 10:55:42.677095630 +0100
+++ gcc/gimple-lower-bitint.cc  2024-02-01 10:36:08.408867602 +0100
@@ -5200,9 +5200,18 @@ bitint_large_huge::lower_asm (gimple *st
  && TREE_CODE (TREE_TYPE (s)) == BITINT_TYPE
  && bitint_precision_kind (TREE_TYPE (s)) >= bitint_prec_large)
{
- int part = var_to_partition (m_map, s);
- gcc_assert (m_vars[part] != NULL_TREE);
- TREE_VALUE (t) = m_vars[part];
+ if (SSA_NAME_IS_DEFAULT_DEF (s)
+ && (!SSA_NAME_VAR (s) || VAR_P (SSA_NAME_VAR (s
+   {
+ TREE_VALUE (t) = create_tmp_var (TREE_TYPE (s), "bitint");
+ mark_addressable (TREE_VALUE (t));
+   }
+ else
+   {
+ int part = var_to_partition (m_map, s);
+ gcc_assert (m_vars[part] != NULL_TREE);
+ TREE_VALUE (t) = m_vars[part];
+   }
}
 }
   update_stmt (stmt);
--- gcc/testsuite/gcc.dg/bitint-81.c.jj 2024-02-01 10:38:26.132937531 +0100
+++ gcc/testsuite/gcc.dg/bitint-81.c2024-02-01 10:38:01.628280939 +0100
@@ -0,0 +1,12 @@
+/* PR middle-end/113699 */
+/* { dg-do compile { target bitint } } */
+/* { dg-options "-O2 -std=c23" } */
+
+void
+foo (void)
+{
+#if __BITINT_MAXWIDTH__ >= 129
+  _BitInt(129) i;
+  __asm__ ("" : : "rm" (i));
+#endif
+}

Jakub



Re: [PATCH]middle-end: check memory accesses in the destination block [PR113588].

2024-02-02 Thread Toon Moene

On 2/1/24 22:33, Tamar Christina wrote:


Bootstrapped Regtested on aarch64-none-linux-gnu and x86_64-pc-linux-gnu no 
issues.
Also checked both with --enable-lto --with-build-config='bootstrap-O3 
bootstrap-lto' --enable-multilib
and --enable-lto --with-build-config=bootstrap-O3 
--enable-checking=release,yes,rtl,extra;
and checked the libcrypt testsuite as reported on PR113467.


Note that I still run into problems if bootstrapping 
--with-build-config=bootstrap-O3 
(https://gcc.gnu.org/pipermail/gcc-testresults/2024-February/806840.html), 
but it is not visible.


That is because it happens in the test suite of gmp, which I build 
locally as part of the build.


It *is* visible in the full log of the bootstrap:

toon@moene:~/compilers$ grep ^FAIL log-thunderx-r14-8681
FAIL: libphobos.exceptions/rt_trap_exceptions.d output pattern test
FAIL: tacos
FAIL: tacosh
FAIL: tadd_si
FAIL: tadd_ui
FAIL: targ
FAIL: tasin
FAIL: tasinh
FAIL: tatan
FAIL: tatanh
FAIL: tcos
FAIL: tcosh


Quite a few of these "t" routines I had to kill by hand because they hang.

With a standard bootstrap I do not have that problem.

Kind regards,

--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands



[PATCH v4 2/5] C++: Support clang compatible [[musttail]] (PR83324)

2024-02-02 Thread Andi Kleen
This patch implements a clang compatible [[musttail]] attribute for
returns.

musttail is useful as an alternative to computed goto for interpreters.
With computed goto the interpreter function usually ends up very big
which causes problems with register allocation and other per function
optimizations not scaling. With musttail the interpreter can be instead
written as a sequence of smaller functions that call each other. To
avoid unbounded stack growth this requires forcing a sibling call, which
this attribute does. It guarantees an error if the call cannot be tail
called which allows the programmer to fix it instead of risking a stack
overflow. Unlike computed goto it is also type-safe.

It turns out that David Malcolm had already implemented middle/backend
support for a musttail attribute back in 2016, but it wasn't exposed
to any frontend other than a special plugin.

This patch adds a [[gnu::musttail]] attribute for C++ that can be added
to return statements. The return statement must be a direct call
(it does not follow dependencies), which is similar to what clang
implements. It then uses the existing must tail infrastructure.

For compatibility it also detects clang::musttail

One problem is that tree-tailcall usually fails when optimization
is disabled, which implies the attribute only really works with
optimization on. But that seems to be a reasonable limitation.

Passes bootstrap and full test

PR83324

gcc/cp/ChangeLog:

* cp-tree.h (finish_return_stmt): Add musttail_p.
(check_return_expr): Dito.
* parser.cc (cp_parser_statement): Handle [[musttail]].
(cp_parser_std_attribute): Dito.
(cp_parser_init_statement): Dito.
(cp_parser_jump_statement): Dito.
* semantics.cc (finish_return_stmt): Dito.
* typeck.cc (check_return_expr): Handle musttail_p flag.
---
 gcc/cp/cp-tree.h|  4 ++--
 gcc/cp/parser.cc| 30 --
 gcc/cp/semantics.cc |  6 +++---
 gcc/cp/typeck.cc| 20 ++--
 4 files changed, 47 insertions(+), 13 deletions(-)

diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index f46b448ce0d2..efc542c3ec26 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -7763,7 +7763,7 @@ extern void finish_while_stmt (tree);
 extern tree begin_do_stmt  (void);
 extern void finish_do_body (tree);
 extern void finish_do_stmt (tree, tree, bool, tree, bool);
-extern tree finish_return_stmt (tree);
+extern tree finish_return_stmt (tree, bool = false);
 extern tree begin_for_scope(tree *);
 extern tree begin_for_stmt (tree, tree);
 extern void finish_init_stmt   (tree);
@@ -8275,7 +8275,7 @@ extern tree composite_pointer_type(const 
op_location_t &,
 tsubst_flags_t);
 extern tree merge_types(tree, tree);
 extern tree strip_array_domain (tree);
-extern tree check_return_expr  (tree, bool *, bool *);
+extern tree check_return_expr  (tree, bool *, bool *, bool);
 extern tree spaceship_type (tree, tsubst_flags_t = 
tf_warning_or_error);
 extern tree genericize_spaceship   (location_t, tree, tree, tree);
 extern tree cp_build_binary_op  (const op_location_t &,
diff --git a/gcc/cp/parser.cc b/gcc/cp/parser.cc
index 3748ccd49ff3..f56500df3725 100644
--- a/gcc/cp/parser.cc
+++ b/gcc/cp/parser.cc
@@ -2462,7 +2462,7 @@ static tree cp_parser_perform_range_for_lookup
 static tree cp_parser_range_for_member_function
   (tree, tree);
 static tree cp_parser_jump_statement
-  (cp_parser *);
+  (cp_parser *, bool = false);
 static void cp_parser_declaration_statement
   (cp_parser *);
 
@@ -12719,9 +12719,27 @@ cp_parser_statement (cp_parser* parser, tree 
in_statement_expr,
 NULL_TREE, false);
  break;
 
+   case RID_RETURN:
+ {
+   bool musttail_p = false;
+   std_attrs = process_stmt_hotness_attribute (std_attrs, attrs_loc);
+   if (lookup_attribute ("gnu", "musttail", std_attrs))
+ {
+   musttail_p = true;
+   std_attrs = remove_attribute ("gnu", "musttail", std_attrs);
+ }
+   // support this for compatibility
+   if (lookup_attribute ("clang", "musttail", std_attrs))
+ {
+   musttail_p = true;
+   std_attrs = remove_attribute ("clang", "musttail", std_attrs);
+ }
+   statement = cp_parser_jump_statement (parser, musttail_p);
+ }
+ break;
+
case RID_BREAK:
case RID_CONTINUE:
-   case RID_RETURN:
case RID_CO_RETURN:
case RID_GOTO:
  std_attrs = process_stmt_hotness_attribute (std_attrs, att

[PATCH v4 3/5] C: Implement musttail attribute for returns

2024-02-02 Thread Andi Kleen
Implement a C23 clang compatible musttail attribute similar to the earlier
C++ implementation in the C parser.

PR83324

gcc/c/ChangeLog:

* c-parser.cc (struct attr_state): Define with musttail_p.
(c_parser_statement_after_labels): Handle [[musttail]]
(c_parser_std_attribute): Dito.
(c_parser_handle_musttail): Dito.
(c_parser_compound_statement_nostart): Dito.
(c_parser_all_labels): Dito.
(c_parser_statement): Dito.
* c-tree.h (c_finish_return): Add musttail_p flag.
* c-typeck.cc (c_finish_return): Handle musttail_p flag.
---
 gcc/c/c-parser.cc | 61 +--
 gcc/c/c-tree.h|  2 +-
 gcc/c/c-typeck.cc | 15 ++--
 3 files changed, 63 insertions(+), 15 deletions(-)

diff --git a/gcc/c/c-parser.cc b/gcc/c/c-parser.cc
index c31349dae2ff..76931931e270 100644
--- a/gcc/c/c-parser.cc
+++ b/gcc/c/c-parser.cc
@@ -1616,6 +1616,11 @@ struct omp_for_parse_data {
   bool fail : 1;
 };
 
+struct attr_state
+{
+  bool musttail_p; // parsed a musttail for return
+};
+
 static bool c_parser_nth_token_starts_std_attributes (c_parser *,
  unsigned int);
 static tree c_parser_std_attribute_specifier_sequence (c_parser *);
@@ -1660,7 +1665,7 @@ static location_t c_parser_compound_statement_nostart 
(c_parser *);
 static void c_parser_label (c_parser *, tree);
 static void c_parser_statement (c_parser *, bool *, location_t * = NULL);
 static void c_parser_statement_after_labels (c_parser *, bool *,
-vec * = NULL);
+vec * = NULL, attr_state = 
{});
 static tree c_parser_c99_block_statement (c_parser *, bool *,
  location_t * = NULL);
 static void c_parser_if_statement (c_parser *, bool *, vec *);
@@ -5757,6 +5762,8 @@ c_parser_std_attribute (c_parser *parser, bool for_tm,
}
   goto out;
 }
+  else if (is_attribute_p ("musttail", name))
+error ("% attribute has arguments");
   {
 location_t open_loc = c_parser_peek_token (parser)->location;
 matching_parens parens;
@@ -6943,6 +6950,28 @@ c_parser_handle_directive_omp_attributes (tree &attrs,
 }
 }
 
+/* Check if STD_ATTR contains a musttail attribute and handle it
+   PARSER is the parser and A is the output attr_state.  */
+
+static tree
+c_parser_handle_musttail (c_parser *parser, tree std_attrs, attr_state &a)
+{
+  if (c_parser_next_token_is_keyword (parser, RID_RETURN))
+{
+  if (lookup_attribute ("gnu", "musttail", std_attrs))
+   {
+ std_attrs = remove_attribute ("gnu", "musttail", std_attrs);
+ a.musttail_p = true;
+   }
+  if (lookup_attribute ("clang", "musttail", std_attrs))
+   {
+ std_attrs = remove_attribute ("clang", "musttail", std_attrs);
+ a.musttail_p = true;
+   }
+}
+  return std_attrs;
+}
+
 /* Parse a compound statement except for the opening brace.  This is
used for parsing both compound statements and statement expressions
(which follow different paths to handling the opening).  */
@@ -6959,6 +6988,7 @@ c_parser_compound_statement_nostart (c_parser *parser)
   bool in_omp_loop_block
 = omp_for_parse_state ? omp_for_parse_state->want_nested_loop : false;
   tree sl = NULL_TREE;
+  attr_state a = {};
 
   if (c_parser_next_token_is (parser, CPP_CLOSE_BRACE))
 {
@@ -7097,7 +7127,10 @@ c_parser_compound_statement_nostart (c_parser *parser)
= c_parser_nth_token_starts_std_attributes (parser, 1);
   tree std_attrs = NULL_TREE;
   if (have_std_attrs)
-   std_attrs = c_parser_std_attribute_specifier_sequence (parser);
+   {
+ std_attrs = c_parser_std_attribute_specifier_sequence (parser);
+ std_attrs = c_parser_handle_musttail (parser, std_attrs, a);
+   }
   if (c_parser_next_token_is_keyword (parser, RID_CASE)
  || c_parser_next_token_is_keyword (parser, RID_DEFAULT)
  || (c_parser_next_token_is (parser, CPP_NAME)
@@ -7245,7 +7278,7 @@ c_parser_compound_statement_nostart (c_parser *parser)
  last_stmt = true;
  mark_valid_location_for_stdc_pragma (false);
  if (!omp_for_parse_state)
-   c_parser_statement_after_labels (parser, NULL);
+   c_parser_statement_after_labels (parser, NULL, NULL, a);
  else
{
  /* In canonical loop nest form, nested loops can only appear
@@ -7287,15 +7320,18 @@ c_parser_compound_statement_nostart (c_parser *parser)
 /* Parse all consecutive labels, possibly preceded by standard
attributes.  In this context, a statement is required, not a
declaration, so attributes must be followed by a statement that is
-   not just a semicolon.  */
+   not just a semicolon.  Returns an attr_state.  */
 
-static void
+static attr_state
 c_parser_all_labels (c_parser *parser)
 {
+  attr_state a = {

[PATCH v4 5/5] Add documentation for musttail attribute

2024-02-02 Thread Andi Kleen
gcc/ChangeLog:

* doc/extend.texi: Document [[musttail]]
---
 gcc/doc/extend.texi | 16 
 1 file changed, 16 insertions(+)

diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 142e41ab8fbf..866f6c4a9fed 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -9875,6 +9875,22 @@ foo (int x, int y)
 @code{y} is not actually incremented and the compiler can but does not
 have to optimize it to just @code{return 42 + 42;}.
 
+@cindex @code{musttail} statement attribute
+@item musttail
+
+The @code{gnu::musttail} or @code{clang::musttail} attribute
+can be applied to a return statement that returns the value
+of a call to indicate that the call must be a tail call
+that does not allocate extra stack space.
+
+@smallexample
+[[gnu::musttail]] return foo();
+@end smallexample
+
+If the compiler cannot generate a tail call it will generate
+an error. Tail calls generally require enabling optimization.
+On some targets they may not be supported.
+
 @end table
 
 @node Attribute Syntax
-- 
2.43.0



Updated musttail patches

2024-02-02 Thread Andi Kleen
This patchkit implements a [[musttail]] attribute for C/C++.

v4:
Addressed all feedback except clang::musttail is still supported
(I don't want to force an #ifdef to most users) and I'm also still
using the lookup/remove_attributes (not clear if anything else
is worth it and it would certainly be more complicated)

Now added Changelogs.
Unified the tests for C/C++
C++ now checks for bogus arguments to gnu::musttail
Don't limit C++ tests to C++23
Added noipa to test cases (probably won't make any difference)
Other minor changes




[PATCH v4 4/5] Add tests for C/C++ musttail attributes

2024-02-02 Thread Andi Kleen
Mostly adopted from the existing C musttail plugin tests.

gcc/testsuite/ChangeLog:

* c-c++-common/musttail1.c: New test.
* c-c++-common/musttail2.c: New test.
* c-c++-common/musttail3.c: New test.
* c-c++-common/musttail4.c: New test.
* c-c++-common/musttail5.c: New test.
---
 gcc/testsuite/c-c++-common/musttail1.c | 15 
 gcc/testsuite/c-c++-common/musttail2.c | 34 ++
 gcc/testsuite/c-c++-common/musttail3.c | 29 ++
 gcc/testsuite/c-c++-common/musttail4.c | 17 +
 gcc/testsuite/c-c++-common/musttail5.c | 25 +++
 5 files changed, 120 insertions(+)
 create mode 100644 gcc/testsuite/c-c++-common/musttail1.c
 create mode 100644 gcc/testsuite/c-c++-common/musttail2.c
 create mode 100644 gcc/testsuite/c-c++-common/musttail3.c
 create mode 100644 gcc/testsuite/c-c++-common/musttail4.c
 create mode 100644 gcc/testsuite/c-c++-common/musttail5.c

diff --git a/gcc/testsuite/c-c++-common/musttail1.c 
b/gcc/testsuite/c-c++-common/musttail1.c
new file mode 100644
index ..ac92f9f74616
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/musttail1.c
@@ -0,0 +1,15 @@
+/* { dg-do compile { target { tail_call && { c || c++11 } } } } */
+/* { dg-options "-O2" } */
+/* { dg-additional-options "-fdelayed-branch" { target sparc*-*-* } } */
+
+int __attribute__((noinline,noclone,noipa))
+callee (int i)
+{
+  return i * i;
+}
+
+int __attribute__((noinline,noclone,noipa))
+caller (int i)
+{
+  [[gnu::musttail]] return callee (i + 1);
+}
diff --git a/gcc/testsuite/c-c++-common/musttail2.c 
b/gcc/testsuite/c-c++-common/musttail2.c
new file mode 100644
index ..058329b69cc2
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/musttail2.c
@@ -0,0 +1,34 @@
+/* { dg-do compile { target { tail_call && { c || c++11 } } } } */
+
+struct box { char field[256]; int i; };
+
+int __attribute__((noinline,noclone,noipa))
+test_2_callee (int i, struct box b)
+{
+  if (b.field[0])
+return 5;
+  return i * i;
+}
+
+int __attribute__((noinline,noclone,noipa))
+test_2_caller (int i)
+{
+  struct box b;
+  [[gnu::musttail]] return test_2_callee (i + 1, b); /* { dg-error "cannot 
tail-call: " } */
+}
+
+extern void setjmp (void);
+void
+test_3 (void)
+{
+  [[gnu::musttail]] return setjmp (); /* { dg-error "cannot tail-call: " } */
+}
+
+typedef void (fn_ptr_t) (void);
+volatile fn_ptr_t fn_ptr;
+
+void
+test_5 (void)
+{
+  [[gnu::musttail]] return fn_ptr (); /* { dg-error "cannot tail-call: " } */
+}
diff --git a/gcc/testsuite/c-c++-common/musttail3.c 
b/gcc/testsuite/c-c++-common/musttail3.c
new file mode 100644
index ..ea9589c59ef2
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/musttail3.c
@@ -0,0 +1,29 @@
+/* { dg-do compile { target { tail_call && { c || c++11 } } } } */
+
+extern int foo2 (int x, ...);
+
+struct str
+{
+  int a, b;
+};
+
+struct str
+cstruct (int x)
+{
+  if (x < 10)
+[[clang::musttail]] return cstruct (x + 1);
+  return ((struct str){ x, 0 });
+}
+
+int
+foo (int x)
+{
+  if (x < 10)
+[[clang::musttail]] return foo2 (x, 29);
+  if (x < 100)
+{
+  int k = foo (x + 1);
+  [[clang::musttail]] return k;/* { dg-error "cannot tail-call: " } */
+}
+  return x;
+}
diff --git a/gcc/testsuite/c-c++-common/musttail4.c 
b/gcc/testsuite/c-c++-common/musttail4.c
new file mode 100644
index ..23f4b5e1cd68
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/musttail4.c
@@ -0,0 +1,17 @@
+/* { dg-do compile { target { tail_call && { c || c++11 } } } } */
+
+struct box { char field[64]; int i; };
+
+struct box __attribute__((noinline,noclone,noipa))
+returns_struct (int i)
+{
+  struct box b;
+  b.i = i * i;
+  return b;
+}
+
+int __attribute__((noinline,noclone))
+test_1 (int i)
+{
+  [[gnu::musttail]] return returns_struct (i * 5).i; /* { dg-error "cannot 
tail-call: " } */
+}
diff --git a/gcc/testsuite/c-c++-common/musttail5.c 
b/gcc/testsuite/c-c++-common/musttail5.c
new file mode 100644
index ..71f4de40fc6d
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/musttail5.c
@@ -0,0 +1,25 @@
+/* { dg-do compile } */
+/* { dg-options "-std=c23" { target c } } */
+/* { dg-options "-std=gnu++11" { target c++ } } */
+
+[[musttail]] int j; /* { dg-warning "attribute" } */
+__attribute__((musttail)) int k; /* { dg-warning "attribute" } */
+
+void foo(void)
+{
+  [[gnu::musttail]] j++; /* { dg-warning "attribute" } */
+  [[gnu::musttail]] if (k > 0) /* { dg-warning "attribute" } */
+[[gnu::musttail]] k++; /* { dg-warning "attribute" } */
+}
+
+int foo2(int p)
+{
+  [[gnu::musttail(1)]] return foo2(p + 1); /* { dg-error "attribute" } */
+}
+
+int i;
+
+void foo3(void)
+{
+  [[musttail]] i++; /* { dg-warning "attribute" } */
+}
-- 
2.43.0



[PATCH v4 1/5] Improve must tail in RTL backend

2024-02-02 Thread Andi Kleen
- Give error messages for all causes of non sibling call generation
- Don't override choices of other non sibling call checks with
must tail. This causes ICEs. The must tail attribute now only
overrides flag_optimize_sibling_calls locally.
- Error out when tree-tailcall failed to mark a must-tail call
sibcall. In this case it doesn't know the true reason and only gives
a vague message (this could be improved, but it's already useful without
that) tree-tailcall usually fails without optimization, so must
adjust the existing must-tail plugin test to specify -O2.

PR83324

gcc/ChangeLog:

* calls.cc (expand_call): Fix mustcall implementation.

gcc/testsuite/ChangeLog:

* gcc.dg/plugin/must-tail-call-1.c: Adjust.
---
 gcc/calls.cc  | 30 ---
 .../gcc.dg/plugin/must-tail-call-1.c  |  1 +
 2 files changed, 21 insertions(+), 10 deletions(-)

diff --git a/gcc/calls.cc b/gcc/calls.cc
index 01f447347437..60a43f5d36a8 100644
--- a/gcc/calls.cc
+++ b/gcc/calls.cc
@@ -2650,7 +2650,9 @@ expand_call (tree exp, rtx target, int ignore)
   /* The type of the function being called.  */
   tree fntype;
   bool try_tail_call = CALL_EXPR_TAILCALL (exp);
-  bool must_tail_call = CALL_EXPR_MUST_TAIL_CALL (exp);
+  /* tree-tailcall decided not to do tail calls. Error for the musttail case.  
*/
+  if (!try_tail_call)
+  maybe_complain_about_tail_call (exp, "other reasons");
   int pass;
 
   /* Register in which non-BLKmode value will be returned,
@@ -3021,10 +3023,22 @@ expand_call (tree exp, rtx target, int ignore)
  pushed these optimizations into -O2.  Don't try if we're already
  expanding a call, as that means we're an argument.  Don't try if
  there's cleanups, as we know there's code to follow the call.  */
-  if (currently_expanding_call++ != 0
-  || (!flag_optimize_sibling_calls && !CALL_FROM_THUNK_P (exp))
-  || args_size.var
-  || dbg_cnt (tail_call) == false)
+  if (currently_expanding_call++ != 0)
+{
+  maybe_complain_about_tail_call (exp, "inside another call");
+  try_tail_call = 0;
+}
+  if (!flag_optimize_sibling_calls
+   && !CALL_FROM_THUNK_P (exp)
+   && !CALL_EXPR_MUST_TAIL_CALL (exp))
+try_tail_call = 0;
+  if (args_size.var)
+{
+  /* ??? correct message?  */
+  maybe_complain_about_tail_call (exp, "stack space needed");
+  try_tail_call = 0;
+}
+  if (dbg_cnt (tail_call) == false)
 try_tail_call = 0;
 
   /* Workaround buggy C/C++ wrappers around Fortran routines with
@@ -3045,15 +3059,11 @@ expand_call (tree exp, rtx target, int ignore)
if (MEM_P (*iter))
  {
try_tail_call = 0;
+   maybe_complain_about_tail_call (exp, "hidden string length 
argument");
break;
  }
}
 
-  /* If the user has marked the function as requiring tail-call
- optimization, attempt it.  */
-  if (must_tail_call)
-try_tail_call = 1;
-
   /*  Rest of purposes for tail call optimizations to fail.  */
   if (try_tail_call)
 try_tail_call = can_implement_as_sibling_call_p (exp,
diff --git a/gcc/testsuite/gcc.dg/plugin/must-tail-call-1.c 
b/gcc/testsuite/gcc.dg/plugin/must-tail-call-1.c
index 3a6d4cceaba7..44af361e2925 100644
--- a/gcc/testsuite/gcc.dg/plugin/must-tail-call-1.c
+++ b/gcc/testsuite/gcc.dg/plugin/must-tail-call-1.c
@@ -1,4 +1,5 @@
 /* { dg-do compile { target tail_call } } */
+/* { dg-options "-O2" } */
 /* { dg-options "-fdelayed-branch" { target sparc*-*-* } } */
 
 extern void abort (void);
-- 
2.43.0



[COMMITTED] testsuite: i386: Fix gcc.target/i386/sse2-stv-1.c on Solaris/x86

2024-02-02 Thread Rainer Orth
gcc.target/i386/sse2-stv-1.c FAILs on 32-bit Solaris/x86:

FAIL: gcc.target/i386/sse2-stv-1.c scan-assembler-not %[er]sp
FAIL: gcc.target/i386/sse2-stv-1.c scan-assembler-not shldl

The test assumes the Linux/x86 default of -mno-stackrealign, while
32-bit Solaris/x86 default to -mstackrealign.

Fixed by explicitly specifying -mno-stackrealign.

Tested on i386-pc-solaris2.11 and i686-pc-linux-gnu.

Committed to trunk.

Rainer

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


2024-02-01  Rainer Orth  

gcc/testsuite:
* gcc.target/i386/sse2-stv-1.c (dg-options): Add -mno-stackrealign.

# HG changeset patch
# Parent  1b69d161152aa71acfac15a0d29081f891eb8598
testsuite: i386: Fix gcc.target/i386/sse2-stv-1.c on Solaris/x86

diff --git a/gcc/testsuite/gcc.target/i386/sse2-stv-1.c b/gcc/testsuite/gcc.target/i386/sse2-stv-1.c
--- a/gcc/testsuite/gcc.target/i386/sse2-stv-1.c
+++ b/gcc/testsuite/gcc.target/i386/sse2-stv-1.c
@@ -1,5 +1,5 @@
 /* { dg-do compile { target ia32 } } */
-/* { dg-options "-O2 -msse2" } */
+/* { dg-options "-O2 -msse2 -mno-stackrealign" } */
 
 unsigned long long a,b,c,d;
 


[COMMITTED] testsuite: i386: Restrict gcc.target/i386/pr80569.c to gas

2024-02-02 Thread Rainer Orth
gcc.target/i386/pr80569.c FAILs on Solaris/x86 with the native
assembler:

FAIL: gcc.target/i386/pr80569.c (test for excess errors)

Excess errors:
Assembler: pr80569.c 
"/var/tmp//ccm4_iqb.s", line 2 : Illegal mnemonic
Near line: ".code16gcc"
"/var/tmp//ccm4_iqb.s", line 2 : Syntax error
Near line: ".code16gcc"

.code16gcc is a gas extension, so restrict the test to gas.

Tested on i386-pc-solaris2.11 (as and gas) and i686-pc-linux-gnu.

Committed to trunk.

Rainer

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


2024-02-01  Rainer Orth  

gcc/testsuite:
* gcc.target/i386/pr80569.c: Require gas.

# HG changeset patch
# Parent  1d2125161d5c03f6695de16e4e8608ed7a0d8163
testsuite: i386: Restrict gcc.target/i386/pr80569.c to gas

diff --git a/gcc/testsuite/gcc.target/i386/pr80569.c b/gcc/testsuite/gcc.target/i386/pr80569.c
--- a/gcc/testsuite/gcc.target/i386/pr80569.c
+++ b/gcc/testsuite/gcc.target/i386/pr80569.c
@@ -1,6 +1,8 @@
 /* PR target/80569 */
 /* { dg-do assemble } */
 /* { dg-options "-O2 -m16 -march=haswell" } */
+/* Non-gas assemblers choke on .code16gcc.  */
+/* { dg-require-effective-target gas } */
 
 void load_kernel(void *setup_addr)
 {


[PATCH] testsuite: i386: Fix gcc.target/i386/pr71321.c on Solaris/x86

2024-02-02 Thread Rainer Orth
gcc.target/i386/pr71321.c FAILs on 64-bit Solaris/x86 with the native
assembler:

FAIL: gcc.target/i386/pr71321.c scan-assembler-not lea.*0

The problem is that /bin/as doesn't fully support cfi directives, so the
.eh_frame section is specified explicitly, which includes ".long 0".
The regular expression above includes ".*", which does multiline
matches.  AFAICS those aren't needed here.

This patch changes the RE not to use multiline patches.

Tested on i386-pc-solaris2.11 (as and gas) and i686-pc-linux-gnu.

Ok for trunk?

Rainer

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


2024-02-01  Rainer Orth  

gcc/testsuite:
* gcc.target/i386/pr71321.c (scan-assembler-not): Avoid multiline
matches.

# HG changeset patch
# Parent  f2342e77e566f9b5bdb221afd339753dcb4d1723
testsuite: i386: Fix gcc.target/i386/pr71321.c on Solaris/x86

diff --git a/gcc/testsuite/gcc.target/i386/pr71321.c b/gcc/testsuite/gcc.target/i386/pr71321.c
--- a/gcc/testsuite/gcc.target/i386/pr71321.c
+++ b/gcc/testsuite/gcc.target/i386/pr71321.c
@@ -12,4 +12,4 @@ unsigned cvt_to_2digit_ascii(uint8_t i)
 {
   return cvt_to_2digit(i, 10) + 0x0a3030;
 }
-/* { dg-final { scan-assembler-not "lea.*0" } } */
+/* { dg-final { scan-assembler-not "lea\[^\n\r]*0" } } */


Re: [PATCH] RISC-V: Allow LICM hoist POLY_INT configuration code sequence

2024-02-02 Thread Kito Cheng
LGTM :)

On Thu, Feb 1, 2024 at 11:46 PM Juzhe-Zhong  wrote:
>
> Realize in recent benchmark evaluation (coremark-pro zip-test):
>
> vid.v   v2
> vmv.v.i v5,0
> .L9:
> vle16.v v3,0(a4)
> vrsub.vxv4,v2,a6   ---> LICM failed to hoist it outside the 
> loop.
>
> The root cause is:
>
> (insn 56 47 57 4 (set (subreg:DI (reg:HI 220) 0)
> (reg:DI 223)) "rvv.c":11:9 208 {*movdi_64bit}  -> Its result used by 
> the following vrsub.vx then supress the hoist of the vrsub.vx
>  (nil))
>
> (insn 57 56 59 4 (set (reg:RVVMF2HI 216)
> (if_then_else:RVVMF2HI (unspec:RVVMF32BI [
> (const_vector:RVVMF32BI repeat [
> (const_int 1 [0x1])
> ])
> (reg:DI 350)
> (const_int 2 [0x2]) repeated x2
> (const_int 1 [0x1])
> (reg:SI 66 vl)
> (reg:SI 67 vtype)
> ] UNSPEC_VPREDICATE)
> (minus:RVVMF2HI (vec_duplicate:RVVMF2HI (reg:HI 220))
> (reg:RVVMF2HI 217))
> (unspec:RVVMF2HI [
> (reg:DI 0 zero)
> ] UNSPEC_VUNDEF))) "rvv.c":11:9 6938 
> {pred_subrvvmf2hi_reverse_scalar}
>  (expr_list:REG_DEAD (reg:HI 220)
> (nil)))
>
> This patch fixes it generate (set (reg:HI) (subreg:HI (reg:DI))) instead of 
> (set (subreg:DI (reg:DI)) (reg:DI)).
>
> After this patch:
>
> vid.v   v2
> vrsub.vxv2,v2,a7
> vmv.v.i v4,0
> .L3:
> vle16.v v3,0(a4)
>
> Tested on both RV32 and RV64 no regression.
>
> gcc/ChangeLog:
>
> * config/riscv/riscv.cc (riscv_legitimize_move): Fix poly_int dest 
> generation.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/riscv/rvv/autovec/poly_licm-1.c: New test.
> * gcc.target/riscv/rvv/autovec/poly_licm-2.c: New test.
>
> ---
>  gcc/config/riscv/riscv.cc |  9 ---
>  .../riscv/rvv/autovec/poly_licm-1.c   | 18 +
>  .../riscv/rvv/autovec/poly_licm-2.c   | 27 +++
>  3 files changed, 50 insertions(+), 4 deletions(-)
>  create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/autovec/poly_licm-1.c
>  create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/autovec/poly_licm-2.c
>
> diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
> index 529ef5e84b7..6e22b43e618 100644
> --- a/gcc/config/riscv/riscv.cc
> +++ b/gcc/config/riscv/riscv.cc
> @@ -2711,16 +2711,17 @@ riscv_legitimize_move (machine_mode mode, rtx dest, 
> rtx src)
> (const_poly_int:HI [m, n])
> (const_poly_int:SI [m, n]).  */
>   rtx tmp = gen_reg_rtx (Pmode);
> - riscv_legitimize_poly_move (Pmode, gen_lowpart (Pmode, dest), tmp,
> - src);
> + rtx tmp2 = gen_reg_rtx (Pmode);
> + riscv_legitimize_poly_move (Pmode, tmp2, tmp, src);
> + emit_move_insn (dest, gen_lowpart (mode, tmp2));
> }
>else
> {
>   /* In RV32 system, handle (const_poly_int:SI [m, n])
> (const_poly_int:DI [m, n]).
>  In RV64 system, handle (const_poly_int:DI [m, n]).
> -   FIXME: Maybe we could gen SImode in RV32 and then sign-extend to 
> DImode,
> -   the offset should not exceed 4GiB in general.  */
> +FIXME: Maybe we could gen SImode in RV32 and then sign-extend to
> +DImode, the offset should not exceed 4GiB in general.  */
>   rtx tmp = gen_reg_rtx (mode);
>   riscv_legitimize_poly_move (mode, dest, tmp, src);
> }
> diff --git a/gcc/testsuite/gcc.target/riscv/rvv/autovec/poly_licm-1.c 
> b/gcc/testsuite/gcc.target/riscv/rvv/autovec/poly_licm-1.c
> new file mode 100644
> index 000..b7da65f0996
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/riscv/rvv/autovec/poly_licm-1.c
> @@ -0,0 +1,18 @@
> +/* { dg-do compile } */
> +/* { dg-options "-march=rv64gcv -mabi=lp64d -O3 -fno-schedule-insns 
> -fno-schedule-insns2" } */
> +
> +extern int wsize;
> +
> +typedef unsigned short Posf;
> +#define NIL 0
> +
> +void foo (Posf *p)
> +{
> +  register unsigned n, m;
> +  do {
> +  m = *--p;
> +  *p = (Posf)(m >= wsize ? m-wsize : NIL);
> +  } while (--n);
> +}
> +
> +/* { dg-final { scan-assembler-times 
> {vid\.v\s+v[0-9]+\s+addi\s+\s*[a-x0-9]+,\s*[a-x0-9]+,\s*-1\s+vrsub\.vx\s+} 1 
> } } */
> diff --git a/gcc/testsuite/gcc.target/riscv/rvv/autovec/poly_licm-2.c 
> b/gcc/testsuite/gcc.target/riscv/rvv/autovec/poly_licm-2.c
> new file mode 100644
> index 000..ffb3c63149f
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/riscv/rvv/autovec/poly_licm-2.c
> @@ -0,0 +1,27 @@
> +/* { dg-do compile } */
> +/* { dg-options "-march=rv64gcv -mabi=lp64d -O3 -fno-schedule-insns 
> -fno-schedule-insns2" } */
> +
> +typedef unsigned short uint16_t;
> +
> +void AAA

  1   2   >