date:20220831

gcc/ChangeLog:

* config.gcc: Remove cr16.
---
 gcc/config.gcc | 8 +---
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/gcc/config.gcc b/gcc/config.gcc
index 8e8e1d0513f..11045084888 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -248,8 +248,7 @@ md_file=
 
 # Obsolete configurations.
 case ${target} in
- cr16-*-*  \
- | hppa[12]*-*-hpux10* \
+ hppa[12]*-*-hpux10*   \
  | hppa[12]*-*-hpux11* \
  )
 if test "x$enable_obsolete" != xyes; then
@@ -1551,11 +1550,6 @@ bpf-*-*)
 extra_objs="coreout.o"
 target_gtfiles="$target_gtfiles \$(srcdir)/config/bpf/coreout.cc"
 ;;
-cr16-*-elf)
-tm_file="elfos.h ${tm_file} newlib-stdint.h"
-tmake_file="${tmake_file} cr16/t-cr16 "
-use_collect2=no
-;;
 cris-*-elf | cris-*-none)
tm_file="elfos.h newlib-stdint.h ${tm_file}"
tmake_file="cris/t-cris cris/t-elfmulti"
-- 
2.37.2

Re: [PATCH 1/3] omp-simd-clone: Allow fixed-lane vectors

On 8/30/22 18:54, Rainer Orth wrote:
> Hi Andrew,
> 
>> On 26/08/2022 12:04, Jakub Jelinek wrote:
 gcc/ChangeLog:

* doc/tm.texi: Regenerate.
* omp-simd-clone.cc (simd_clone_adjust_return_type): Allow zero
vecsize.
(simd_clone_adjust_argument_types): Likewise.
* target.def (compute_vecsize_and_simdlen): Document the new
vecsize_int and vecsize_float semantics.
>>> LGTM, except for a formatting nit.
>> diff --git a/gcc/omp-simd-clone.cc b/gcc/omp-simd-clone.cc
>> index 58bd68b129b..68ee4c2c3b0 100644
>> --- a/gcc/omp-simd-clone.cc
>> +++ b/gcc/omp-simd-clone.cc
>> @@ -504,7 +504,10 @@ simd_clone_adjust_return_type (struct cgraph_node *node)
>>  veclen = node->simdclone->vecsize_int;
>>else
>>  veclen = node->simdclone->vecsize_float;
>> -  veclen = exact_div (veclen, GET_MODE_BITSIZE (SCALAR_TYPE_MODE (t)));
>> +  if (known_eq (veclen, 0))
>> +veclen = node->simdclone->simdlen;
>> +  else
>> +veclen = exact_div (veclen, GET_MODE_BITSIZE (SCALAR_TYPE_MODE (t)));
>>if (multiple_p (veclen, node->simdclone->simdlen))
>>  veclen = node->simdclone->simdlen;
>>if (POINTER_TYPE_P (t))
> 
> this broke bootstrap on (at least) i386-pc-solaris2.11 and
> sparc-sun-solaris2.11:
> 
> In file included from /vol/gcc/src/hg/master/local/gcc/coretypes.h:475,
>  from /vol/gcc/src/hg/master/local/gcc/omp-simd-clone.cc:23:
> /vol/gcc/src/hg/master/local/gcc/poly-int.h: In instantiation of 'typename 
> if_nonpoly::type maybe_ne(const poly_int_pod&, const Cb&) 
> [with unsigned int N = 1; Ca = long long unsigned int; Cb = int; typename 
> if_nonpoly::type = bool]':
> /vol/gcc/src/hg/master/local/gcc/omp-simd-clone.cc:507:7:   required from here
> /vol/gcc/src/hg/master/local/gcc/poly-int.h:1295:22: error: comparison of 
> integer expressions of different signedness: 'const long long unsigned int' 
> and 'const int' [-Werror=sign-compare]
>  1295 |   return a.coeffs[0] != b;
>   |  ^~~~

I noticed the very same warning on x86_64-linux-gnu as well.

Cheers,
Martin

> 
> Changing the three instances of 0 to 0U seems to fix this.
> 
>   Rainer
>

RE: [PATCH] middle-end: Add MULT_EXPR recognition for cond scalar reduction

2022-08-31 Thread Kong, Lingling via Gcc-patches

Hi  Richard,  could you help to have a look for the patch ?

Ok for master ?

> Hi,
> 
> The conditional mult reduction cannot be recognized with current GCC. The
> following loop cannot be vectorized.
> Now add MULT_EXPR recognition for conditional scalar reduction.
> 
> float summa(int n, float *arg1, float *arg2)
> {
> int i;
> float res1 = 1.0;
> for(i = 0; i < n; i++) {
>   if(arg2[i])
> res1 *= arg1[i];
> }
> return res1;
> }
> 
> gcc/ChangeLog:
> 
>   * tree-if-conv.cc (is_cond_scalar_reduction): Add MULT_EXPR
>   recognition.
> 
> gcc/testsuite/ChangeLog:
> 
>   * gcc.dg/tree-ssa/gen-vect-34.c: New test.
>   * gcc.dg/vect/vect-ifcvt-18.c: New test.
> ---
>  gcc/testsuite/gcc.dg/tree-ssa/gen-vect-34.c | 16 +
>  gcc/testsuite/gcc.dg/vect/vect-ifcvt-18.c   | 38 +
>  gcc/tree-if-conv.cc |  1 +
>  3 files changed, 55 insertions(+)
>  create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/gen-vect-34.c
>  create mode 100644 gcc/testsuite/gcc.dg/vect/vect-ifcvt-18.c
> 
> diff --git a/gcc/testsuite/gcc.dg/tree-ssa/gen-vect-34.c
> b/gcc/testsuite/gcc.dg/tree-ssa/gen-vect-34.c
> new file mode 100644
> index 000..8d2d36401fe
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/tree-ssa/gen-vect-34.c
> @@ -0,0 +1,16 @@
> +/* { dg-do compile } */
> +/* { dg-options "-Ofast -fdump-tree-vect-details" } */
> +/* { dg-additional-options "-mavx2" { target { x86_64-*-* i?86-*-* } }
> +} */
> +
> +float summul(int n, float *arg1, float *arg2)
> +{
> +int i;
> +float res1 = 1.0;
> +for(i = 0; i < n; i++) {
> +  if(arg2[i])
> +res1 *= arg1[i];
> +}
> +return res1;
> +}
> +
> +/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect" {
> +target { ! { avr-*-* pru-*-* } } } } } */
> diff --git a/gcc/testsuite/gcc.dg/vect/vect-ifcvt-18.c
> b/gcc/testsuite/gcc.dg/vect/vect-ifcvt-18.c
> new file mode 100644
> index 000..c1d3c27d819
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/vect/vect-ifcvt-18.c
> @@ -0,0 +1,38 @@
> +/* { dg-require-effective-target vect_condition } */
> +/* { dg-require-effective-target vect_float } */
> +/* { dg-additional-options "-Ofast -mavx" { target avx_runtime } } */
> +
> +
> +int A0[4] = {36,39,42,45};
> +int B0[4] = {42,42,0,42};
> +float A1[8] = {36,39,42,45,43,32,21,12}; float B1[8] =
> +{42,42,0,42,42,42,0,42}; double A2[16] =
> +{36,39,42,45,43,32,21,12,23,34,45,56,42,78,89,11};
> +double B2[16] = {42,42,0,42,42,42,42,42,42,42,42,42,0,42,42,42};
> +
> +int main ()
> +{
> +  int i, j;
> +  int res0 = 1;
> +  float res1 = 1.0;
> +  double res2 = 1.0;
> +
> +  for (i = 0; i < 4; i++)
> +if (B0[i])
> +  res0 *= A0[i];
> +
> +  for (i = 0; i < 8; i++)
> +if (B1[i])
> +  res1 *= A1[i];
> +
> +  for (i = 0; i < 16; i++)
> +if (B2[i])
> +  res2 *= A2[i];
> +  /* check results:  */
> +  if (res0 != 63180 || res1 != 1043228160.00
> +  ||res2 != 3296728515318523101184.00)
> +  __builtin_abort ();
> +  return 0;
> +}
> +
> +/* { dg-final { scan-tree-dump "vectorized 3 loops" "vect" { target
> +i?86-*-* x86_64-*-* } } } */
> diff --git a/gcc/tree-if-conv.cc b/gcc/tree-if-conv.cc index
> 1c8e1a45234..bac29fb5574 100644
> --- a/gcc/tree-if-conv.cc
> +++ b/gcc/tree-if-conv.cc
> @@ -1739,6 +1739,7 @@ is_cond_scalar_reduction (gimple *phi, gimple
> **reduc, tree arg_0, tree arg_1,
> 
>if (reduction_op != PLUS_EXPR
>&& reduction_op != MINUS_EXPR
> +  && reduction_op != MULT_EXPR
>&& reduction_op != BIT_IOR_EXPR
>&& reduction_op != BIT_XOR_EXPR
>&& reduction_op != BIT_AND_EXPR)
> --
> 2.18.2

[PATCH][V3] 32-bit PA-RISC with HP-UX: remove deprecated ports

Sending v3 of the patch that includes John's comments.

Ready to be installed?
Thanks,
Martin

ChangeLog:

* configure: Regenerate.
* configure.ac: Delete hpux9 and hpux10.

config/ChangeLog:

* mh-pa-hpux10: Removed.

contrib/ChangeLog:

* config-list.mk: Remove deprecated ports.

contrib/header-tools/ChangeLog:

* README: Remove deprecated ports.
* reduce-headers: Likewise.

gcc/ChangeLog:

* config.build: Remove deprecated ports.
* config.gcc: Likewise.
* config.host: Likewise.
* configure.ac: Likewise.
* configure: Regenerate.
* config/pa/pa-hpux10.h: Removed.
* config/pa/pa-hpux10.opt: Removed.
* config/pa/t-dce-thr: Removed.

gnattools/ChangeLog:

* configure.ac: Remove deprecated ports.
* configure: Regenerate.

libstdc++-v3/ChangeLog:

* configure: Regenerate.
* crossconfig.m4: Remove deprecated ports.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/lambda/lambda-conv.C: Remove useless test.
* gcc.c-torture/execute/ieee/hugeval.x: Likewise.
* gcc.dg/torture/pr47917.c: Likewise.
* lib/target-supports.exp: Likewise.

libgcc/ChangeLog:

* config.host: Remove hppa.

libitm/ChangeLog:

* configure: Regenerate.

fixincludes/ChangeLog:

* configure: Regenerate.
---
 config/mh-pa-hpux10   |   4 -
 configure |  14 --
 configure.ac  |  14 --
 contrib/config-list.mk|   3 +-
 contrib/header-tools/README   |   2 +-
 contrib/header-tools/reduce-headers   |   1 -
 fixincludes/configure |   2 +-
 gcc/config.build  |   5 +-
 gcc/config.gcc|  85 +-
 gcc/config.host   |   5 -
 gcc/config/pa/pa-hpux10.h | 157 --
 gcc/config/pa/pa-hpux10.opt   |  22 ---
 gcc/config/pa/t-dce-thr   |   2 -
 gcc/configure |  21 +--
 gcc/configure.ac  |  13 --
 .../g++.dg/cpp0x/lambda/lambda-conv.C |   2 +-
 .../gcc.c-torture/execute/ieee/hugeval.x  |   3 -
 gcc/testsuite/gcc.dg/torture/pr47917.c|   1 -
 gcc/testsuite/lib/target-supports.exp |  13 +-
 gnattools/configure   |   2 -
 gnattools/configure.ac|   2 -
 libgcc/config.host|  22 ---
 libitm/configure  |   2 +-
 libstdc++-v3/configure|  14 --
 libstdc++-v3/crossconfig.m4   |   9 -
 25 files changed, 13 insertions(+), 407 deletions(-)
 delete mode 100644 config/mh-pa-hpux10
 delete mode 100644 gcc/config/pa/pa-hpux10.h
 delete mode 100644 gcc/config/pa/pa-hpux10.opt
 delete mode 100644 gcc/config/pa/t-dce-thr

diff --git a/config/mh-pa-hpux10 b/config/mh-pa-hpux10
deleted file mode 100644
index 99a2278f281..000
--- a/config/mh-pa-hpux10
+++ /dev/null
@@ -1,4 +0,0 @@
-# The ada virtual array implementation requires that indexing be disabled on
-# hosts such as hpux that use a segmented memory architecture.  Both the c
-# and ada files need to be compiled with this option for correct operation.
-ADA_CFLAGS = -mdisable-indexing -D_X_HPUX10
diff --git a/configure b/configure
index 81c034b553f..e90b8df217d 100755
--- a/configure
+++ b/configure
@@ -3544,11 +3544,6 @@ case "${target}" in
   hppa*64*-*-hpux*)
 noconfigdirs="$noconfigdirs target-libffi"
 ;;
-  hppa*-hp-hpux11*)
-;;
-  hppa*-*-hpux*)
-noconfigdirs="$noconfigdirs target-libffi"
-;;
   ia64*-*-*vms*)
 noconfigdirs="$noconfigdirs target-libffi"
 ;;
@@ -3855,14 +3850,9 @@ case "${target}" in
   h8500-*-*)
 noconfigdirs="$noconfigdirs target-libgloss"
 ;;
-  hppa1.1-*-osf* | hppa1.1-*-bsd* )
-;;
   hppa*64*-*-hpux*)
 noconfigdirs="$noconfigdirs gdb"
 ;;
-  hppa*-*-hpux11*)
-noconfigdirs="$noconfigdirs gdb ld"
-;;
   hppa*64*-*-linux*)
 ;;
   hppa*-*-linux*)
@@ -4076,9 +4066,6 @@ fi
   alpha*-linux*)
 host_makefile_frag="config/mh-alpha-linux"
 ;;
-  hppa*-hp-hpux10*)
-host_makefile_frag="config/mh-pa-hpux10"
-;;
   hppa*-hp-hpux*)
 host_makefile_frag="config/mh-pa"
 ;;
@@ -18324,7 +18311,6 @@ fi
 compare_exclusions="gcc/cc*-checksum\$(objext) | gcc/ada/*tools/*"
 case "$target" in
   hppa*64*-*-hpux*) ;;
-  hppa*-*-hpux*) compare_exclusions="$compare_exclusions | */libgcc/lib2funcs* 
| gcc/function-tests.o" ;;
   powerpc*-ibm-aix*) compare_exclusions="$compare_exclusions | 
*libgomp*\$(objext)" ;;
 esac
 
diff --git a/configure.ac b/configure.ac
index 13f8c5f2a9f..3ecb532138d 100644
--- a/configure.ac
+++ b/configure.ac
@@ -804,11 +804,6 @@ case "${target}" in
   hppa*64*-*-hpux*)
 noconfigdirs

Re: [PATCH] s390: Recognize reverse/element swap permute patterns.

2022-08-31 Thread Robin Dapp via Gcc-patches

Hi,

adding -save-temps as well as a '\t' in order for the tests to do what
they are supposed to do.

Going to push this as obvious in some days.

Regards
 Robin

--
gcc/testsuite/ChangeLog:

* gcc.target/s390/vector/vperm-rev-z14.c: Add -save-temps.
* gcc.target/s390/vector/vperm-rev-z15.c: Likewise.

---

diff --git a/gcc/testsuite/gcc.target/s390/vector/vperm-rev-z14.c
b/gcc/testsuite/gcc.target/s390/vector/vperm-rev-z14.c
index 5c64fac4646c..eefacad45808 100644
--- a/gcc/testsuite/gcc.target/s390/vector/vperm-rev-z14.c
+++ b/gcc/testsuite/gcc.target/s390/vector/vperm-rev-z14.c
@@ -1,7 +1,7 @@
 /* Make sure that the reverse permute patterns are optimized
correctly.  */
 /* { dg-do run { target { s390*-*-* } } } */
-/* { dg-options "-O2 -march=z14 -mzarch -fno-unroll-loops" } */
+/* { dg-options "-O2 -march=z14 -mzarch -fno-unroll-loops -save-temps" } */

 /* { dg-final { scan-assembler-times "vpdi\t" 4 } } */
 /* { dg-final { scan-assembler-times "verllg\t" 2 } } */
diff --git a/gcc/testsuite/gcc.target/s390/vector/vperm-rev-z15.c
b/gcc/testsuite/gcc.target/s390/vector/vperm-rev-z15.c
index bff52406fa9b..079460b37e46 100644
--- a/gcc/testsuite/gcc.target/s390/vector/vperm-rev-z15.c
+++ b/gcc/testsuite/gcc.target/s390/vector/vperm-rev-z15.c
@@ -1,12 +1,12 @@
 /* Make sure that the reverse permute patterns are optimized
correctly.  */
 /* { dg-do run { target { s390*-*-* } } } */
-/* { dg-options "-O2 -march=z15 -mzarch -fno-unroll-loops" } */
+/* { dg-options "-O2 -march=z15 -mzarch -fno-unroll-loops -save-temps" } */

 /* { dg-final { scan-assembler-times "vsterg\t" 2 } } */
-/* { dg-final { scan-assembler-times "vsterf" 2 } } */
+/* { dg-final { scan-assembler-times "vsterf\t" 2 } } */
 /* { dg-final { scan-assembler-times "vstbrq\t" 1 } } */
-/* { dg-final { scan-assembler-times "vperm" 0 } } */
+/* { dg-final { scan-assembler-times "vperm\t" 0 } } */

 #include

[pushed] vect: Fix stray argument in call to dump_printf_loc

2022-08-31 Thread Richard Sandiford via Gcc-patches

One call to dump_printf_loc had a stray left-over argument
from an earlier version of the patch.  This went unnoticed
on aarch64-linux-gnu and x86_64-linux-gnu since the parameters
that actually mattered were passed in FPRs rather than GPRs,
but I assume this is the reason for the i686-linux-gnu failures
that Jakub hit.

Tested on x86_64-linux-gnu & pushed as obvious.  Sorry for the breakage.

Richard


gcc/
* tree-vect-slp.cc (vect_optimize_slp_pass::dump): Remove bogus
argument.
---
 gcc/tree-vect-slp.cc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/tree-vect-slp.cc b/gcc/tree-vect-slp.cc
index ab4c6fa6776..226550635cc 100644
--- a/gcc/tree-vect-slp.cc
+++ b/gcc/tree-vect-slp.cc
@@ -5461,7 +5461,7 @@ vect_optimize_slp_pass::dump ()
  combined_cost.add_serial_cost (layout_costs.out_cost);
 #define TEMPLATE "{depth: %f, total: %f}"
  dump_printf_loc (MSG_NOTE, vect_location,
-  "" TEMPLATE "\n", layout_i,
+  "" TEMPLATE "\n",
   layout_costs.in_cost.depth.to_double (),
   layout_costs.in_cost.total.to_double ());
  dump_printf_loc (MSG_NOTE, vect_location,
-- 
2.25.1

Re: [PATCH 1/3] omp-simd-clone: Allow fixed-lane vectors

On Tue, Aug 30, 2022 at 06:54:49PM +0200, Rainer Orth wrote:
> > --- a/gcc/omp-simd-clone.cc
> > +++ b/gcc/omp-simd-clone.cc
> > @@ -504,7 +504,10 @@ simd_clone_adjust_return_type (struct cgraph_node 
> > *node)
> >  veclen = node->simdclone->vecsize_int;
> >else
> >  veclen = node->simdclone->vecsize_float;
> > -  veclen = exact_div (veclen, GET_MODE_BITSIZE (SCALAR_TYPE_MODE (t)));
> > +  if (known_eq (veclen, 0))
> > +veclen = node->simdclone->simdlen;
> > +  else
> > +veclen = exact_div (veclen, GET_MODE_BITSIZE (SCALAR_TYPE_MODE (t)));
> >if (multiple_p (veclen, node->simdclone->simdlen))
> >  veclen = node->simdclone->simdlen;
> >if (POINTER_TYPE_P (t))
> 
> this broke bootstrap on (at least) i386-pc-solaris2.11 and
> sparc-sun-solaris2.11:
> 
> In file included from /vol/gcc/src/hg/master/local/gcc/coretypes.h:475,
>  from /vol/gcc/src/hg/master/local/gcc/omp-simd-clone.cc:23:
> /vol/gcc/src/hg/master/local/gcc/poly-int.h: In instantiation of 'typename 
> if_nonpoly::type maybe_ne(const poly_int_pod&, const Cb&) 
> [with unsigned int N = 1; Ca = long long unsigned int; Cb = int; typename 
> if_nonpoly::type = bool]':
> /vol/gcc/src/hg/master/local/gcc/omp-simd-clone.cc:507:7:   required from here
> /vol/gcc/src/hg/master/local/gcc/poly-int.h:1295:22: error: comparison of 
> integer expressions of different signedness: 'const long long unsigned int' 
> and 'const int' [-Werror=sign-compare]
>  1295 |   return a.coeffs[0] != b;
>   |  ^~~~
> 
> Changing the three instances of 0 to 0U seems to fix this.

It broke bootstrap for me on x86_64-linux and i686-linux too.

I've bootstrapped/regtested the following patch on both overnight
and committed to unbreak bootstrap for others.

2022-08-31  Rainer Orth  
Jakub Jelinek  

* omp-simd-clone.cc (simd_clone_adjust_return_type,
simd_clone_adjust_argument_types): Use known_eq (veclen, 0U)
instead of known_eq (veclen, 0) to avoid -Wsign-compare warnings.

--- gcc/omp-simd-clone.cc.jj2022-08-30 23:10:02.054456930 +0200
+++ gcc/omp-simd-clone.cc   2022-08-30 23:51:03.601664615 +0200
@@ -504,7 +504,7 @@ simd_clone_adjust_return_type (struct cg
 veclen = node->simdclone->vecsize_int;
   else
 veclen = node->simdclone->vecsize_float;
-  if (known_eq (veclen, 0))
+  if (known_eq (veclen, 0U))
 veclen = node->simdclone->simdlen;
   else
 veclen = exact_div (veclen, GET_MODE_BITSIZE (SCALAR_TYPE_MODE (t)));
@@ -621,7 +621,7 @@ simd_clone_adjust_argument_types (struct
veclen = sc->vecsize_int;
  else
veclen = sc->vecsize_float;
- if (known_eq (veclen, 0))
+ if (known_eq (veclen, 0U))
veclen = sc->simdlen;
  else
veclen
@@ -676,7 +676,7 @@ simd_clone_adjust_argument_types (struct
veclen = sc->vecsize_int;
   else
veclen = sc->vecsize_float;
-  if (known_eq (veclen, 0))
+  if (known_eq (veclen, 0U))
veclen = sc->simdlen;
   else
veclen = exact_div (veclen,


Jakub

Re: [PATCH 1/3] omp-simd-clone: Allow fixed-lane vectors

2022-08-31 Thread Andrew Stubbs


On 31/08/2022 09:29, Jakub Jelinek wrote:

On Tue, Aug 30, 2022 at 06:54:49PM +0200, Rainer Orth wrote:

--- a/gcc/omp-simd-clone.cc
+++ b/gcc/omp-simd-clone.cc
@@ -504,7 +504,10 @@ simd_clone_adjust_return_type (struct cgraph_node *node)
  veclen = node->simdclone->vecsize_int;
else
  veclen = node->simdclone->vecsize_float;
-  veclen = exact_div (veclen, GET_MODE_BITSIZE (SCALAR_TYPE_MODE (t)));
+  if (known_eq (veclen, 0))
+veclen = node->simdclone->simdlen;
+  else
+veclen = exact_div (veclen, GET_MODE_BITSIZE (SCALAR_TYPE_MODE (t)));
if (multiple_p (veclen, node->simdclone->simdlen))
  veclen = node->simdclone->simdlen;
if (POINTER_TYPE_P (t))


this broke bootstrap on (at least) i386-pc-solaris2.11 and
sparc-sun-solaris2.11:

In file included from /vol/gcc/src/hg/master/local/gcc/coretypes.h:475,
  from /vol/gcc/src/hg/master/local/gcc/omp-simd-clone.cc:23:
/vol/gcc/src/hg/master/local/gcc/poly-int.h: In instantiation of 'typename if_nonpoly::type maybe_ne(const poly_int_pod&, const Cb&) [with unsigned int N = 1; Ca 
= long long unsigned int; Cb = int; typename if_nonpoly::type = bool]':
/vol/gcc/src/hg/master/local/gcc/omp-simd-clone.cc:507:7:   required from here
/vol/gcc/src/hg/master/local/gcc/poly-int.h:1295:22: error: comparison of 
integer expressions of different signedness: 'const long long unsigned int' and 
'const int' [-Werror=sign-compare]
  1295 |   return a.coeffs[0] != b;
   |  ^~~~

Changing the three instances of 0 to 0U seems to fix this.


It broke bootstrap for me on x86_64-linux and i686-linux too.

I've bootstrapped/regtested the following patch on both overnight
and committed to unbreak bootstrap for others.


Apologies everyone. :-(

I did a full build and test on x86_64, but not a bootstrap, and 
apparently it was fine with my not-so-new compiler.


Andrew

[committed] libcpp: Make static checkers happy about makeuname2c [PR106778]

Hi!

The assertion ensures that we point within the image and at a byte
we haven't touched yet (or at least that it isn't the first byte
of an already stored tree), some static checker was unhappy about
first checking that it is zero and only afterwards checking that it
is within bounds.

Obviously nothing changes on the generated uname2c.h and while I've
bootstrapped/regtested it on x86_64-linux and i686-linux, the generator
is only used when built and run by hand (note, when updating to a newer
Unicode it won't be just a matter of rerunning it against newer files,
but one needs to update the generated_ranges according to Table 4-8
in the sources too).

Committed to trunk as obvious.

2022-08-31  Jakub Jelinek  

PR preprocessor/106778
* makeuname2c.cc (write_nodes): Reverse order of && operands in
assert.

--- libcpp/makeuname2c.cc.jj2022-08-26 09:24:12.122615517 +0200
+++ libcpp/makeuname2c.cc   2022-08-30 17:28:20.171052344 +0200
@@ -451,7 +451,7 @@ write_nodes (struct node *n, size_t off)
 {
   for (; n; n = n->sibling)
 {
-  assert (tree[off] == 0 && off < tree_size);
+  assert (off < tree_size && tree[off] == 0);
   if (n->key_len > 1)
{
  assert (n->key_len < 64);

Jakub

[PATCH] uninit testcase for PR65244

The PR65244 has an issue with code in init_from_control_deps
for which there's no direct testcase.  The following adds one.

Pushed.

PR tree-optimization/65244
* gcc.dg/uninit-pr65244-1.c: New testcase.
---
 gcc/testsuite/gcc.dg/uninit-pr65244-1.c | 20 
 1 file changed, 20 insertions(+)
 create mode 100644 gcc/testsuite/gcc.dg/uninit-pr65244-1.c

diff --git a/gcc/testsuite/gcc.dg/uninit-pr65244-1.c 
b/gcc/testsuite/gcc.dg/uninit-pr65244-1.c
new file mode 100644
index 000..7c1d910d546
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/uninit-pr65244-1.c
@@ -0,0 +1,20 @@
+/* { dg-do compile } */
+/* { dg-options "-O -Wuninitialized" } */
+
+extern void __attribute__((noreturn)) abort (void);
+
+int foo (int flag, int val)
+{
+  int tem;
+  if (flag)
+{
+  if (val == 0)
+abort ();
+  tem = val;
+}
+  /* large - prevent jump threading */
+  __asm__ volatile ("\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n");
+  if (flag)
+return tem; /* { dg-bogus "uninitialized" } */
+  return 0;
+}
-- 
2.35.3

Re: [PATCH] rs6000: Don't ICE when we disassemble an MMA variable [PR101322]

2022-08-31 Thread Kewen.Lin via Gcc-patches

Hi Peter,

Thanks for the patch!  Some comments are inline as below.

on 2022/8/27 11:50, Peter Bergner via Gcc-patches wrote:
> When we expand an MMA disassemble built-in with C++ using a pointer that
> is casted to a valid MMA type, the type isn't passed down to the expand
> machinery and we end up using the base type of the pointer which leads to
> an ICE.  This patch enforces we always use the correct MMA type regardless
> of the pointer type being used.
> 
> This passed bootstrap and regtesting on powerpc64le-linux with no regressions.
> Ok for trunk and backports after some burn-in time?
> 
> Peter
> 
> gcc/
>   PR target/101322
>   * config/rs6000/rs6000-builtin.cc (rs6000_gimple_fold_mma_builtin):
>   Enforce the use of a valid MMA pointer type.
> 
> gcc/testsuite/
>   PR target/101322
>   * g++.target/powerpc/pr101322.C: New test.
> 
> diff --git a/gcc/config/rs6000/rs6000-builtin.cc 
> b/gcc/config/rs6000/rs6000-builtin.cc
> index 12afa86854c..e796e74f072 100644
> --- a/gcc/config/rs6000/rs6000-builtin.cc
> +++ b/gcc/config/rs6000/rs6000-builtin.cc
> @@ -1085,7 +1085,12 @@ rs6000_gimple_fold_mma_builtin (gimple_stmt_iterator 
> *gsi,
>unsigned nvec = (fncode == RS6000_BIF_DISASSEMBLE_ACC) ? 4 : 2;
>tree dst_ptr = gimple_call_arg (stmt, 0);
>tree src_ptr = gimple_call_arg (stmt, 1);
> -  tree src_type = TREE_TYPE (src_ptr);
> +  tree src_type = (fncode == RS6000_BIF_DISASSEMBLE_ACC)
> +   ? build_pointer_type (vector_quad_type_node)
> +   : build_pointer_type (vector_pair_type_node);

Nit: it seems we can use existing ptr_vector_quad_type_node and 
ptr_vector_pair_type_node?
I assume the const qualifier is fine since it's for disassembling.

> +  if (TREE_TYPE (TREE_TYPE (src_ptr)) != src_type)

This line looks unexpected, the former is type char while the latter is type 
__vector_pair *.

I guess you meant to compare the type of pointer type like: 
   
   TREE_TYPE (TREE_TYPE (src_ptr)) != TREE_TYPE (src_type)

or even with mode like:

   TYPE_MODE (TREE_TYPE (TREE_TYPE (src_ptr))) != TYPE_MODE (TREE_TYPE 
(src_type))

> + src_ptr = build1 (VIEW_CONVERT_EXPR, src_type, src_ptr);

Nit: NOP_EXPR seems to be better suited here for pointer conversion.

BR,
Kewen

> +
>tree src = create_tmp_reg_or_ssa_name (TREE_TYPE (src_type));
>gimplify_assign (src, build_simple_mem_ref (src_ptr), &new_seq);
>  
> diff --git a/gcc/testsuite/g++.target/powerpc/pr101322.C 
> b/gcc/testsuite/g++.target/powerpc/pr101322.C
> new file mode 100644
> index 000..59e71e8eb89
> --- /dev/null
> +++ b/gcc/testsuite/g++.target/powerpc/pr101322.C
> @@ -0,0 +1,17 @@
> +/* PR target/101322 */
> +/* { dg-options "-O2 -mdejagnu-cpu=power10" } */
> +/* { dg-require-effective-target power10_ok } */
> +
> +/* Verify we don't ICE on the following test cases.  */
> +
> +void
> +foo (char *resp, char *vpp)
> +{
> +  __builtin_vsx_disassemble_pair (resp, (__vector_pair *) vpp);
> +}
> +
> +void
> +bar (char *resp, char *vpp)
> +{
> +  __builtin_mma_disassemble_acc (resp, (__vector_quad *)vpp);
> +}

Re: [PATCH][_GLIBCXX_DEBUG] Review null string assertions (was: Add basic_string::starts_with/ends_with checks)

On Wed, 31 Aug 2022 at 05:38, François Dumont  wrote:
>
> If I got your point correctly here is this patch again with just the
> change on '0' becoming 'nullptr' in assertions.
>
>  libstdc++: [_GLIBCXX_DEBUG] Review nullptr assertion diagnostics
>
>  Review null string checks to show:
>  _String != nullptr
>
>  rather than:
>  _String != 0
>
>  libstdc++-v3/ChangeLog:
>
>  * include/debug/debug.h: Use nullptr rather than '0' in
> checks in post-C++11.
>  * include/debug/string: Likewise.
>  *
> testsuite/21_strings/basic_string/operations/ends_with/char.cc: Use
> __gnu_test::string.
>  *
> testsuite/21_strings/basic_string/operations/ends_with/nonnull.cc: Likewise.
>  *
> testsuite/21_strings/basic_string/operations/ends_with/wchar_t.cc: Likewise.
>  *
> testsuite/21_strings/basic_string/operations/starts_with/wchar_t.cc:
> Likewise.
>  *
> testsuite/21_strings/basic_string/operations/starts_with/nonnull.cc:
> Likewise.
>  *
> testsuite/21_strings/basic_string/operations/starts_with/char.cc: Likewise..
>
> Ok to commit ?

The testsuite changes seem unrelated to the actual code change, so I'd
have done a separate patch. But OK for trunk.

[PATCH] rs6000/test: Fix typo in pr86731-fwrapv-longlong.c [PR106682]

2022-08-31 Thread Kewen.Lin via Gcc-patches

Hi,

Commit r12-2266 updated the scanned assembly content from

  "{\mlvx\M|\mlxv\M|\mlxvd2x\M}"

to

  "{\mp?lxv\M|\mlxv\M|\mlxvd2x\M}"

for the test case pr86731-fwrapv-longlong.c unexpectedly.

It's meant to update "lxv" to "p?lxv" and should leave the
"lvx" unchanged.  So this is to fix the typo accordingly.

Tested on powerpc64-linux-gnu P7 and P8,
and powerpc64le-linux-gnu P9 and P10.

I'll push this soon if no objections.

BR,
Kewen
-
PR testsuite/106682

gcc/testsuite/ChangeLog:

* gcc.target/powerpc/pr86731-fwrapv-longlong.c: Fix typo.
---
 gcc/testsuite/gcc.target/powerpc/pr86731-fwrapv-longlong.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.target/powerpc/pr86731-fwrapv-longlong.c 
b/gcc/testsuite/gcc.target/powerpc/pr86731-fwrapv-longlong.c
index dcb30e1d886..018e1cf9749 100644
--- a/gcc/testsuite/gcc.target/powerpc/pr86731-fwrapv-longlong.c
+++ b/gcc/testsuite/gcc.target/powerpc/pr86731-fwrapv-longlong.c
@@ -31,5 +31,5 @@ vector signed long long splats4(void)

 /* { dg-final { scan-assembler-times {\mvspltis[bhw]\M} 0 } } */
 /* { dg-final { scan-assembler-times {\mvsl[bhwd]\M} 0 } } */
-/* { dg-final { scan-assembler-times 
{\mp?lxv\M|\mlxv\M|\mlxvd2x\M|\mxxspltidp\M} 2 } } */
+/* { dg-final { scan-assembler-times 
{\mp?lxv\M|\mlvx\M|\mlxvd2x\M|\mxxspltidp\M} 2 } } */

--
2.25.1

[PATCH] rs6000/test: Fix bswap64-4.c with has_arch_ppc64 [PR106680]

2022-08-31 Thread Kewen.Lin via Gcc-patches

Hi,

Test case bswap64-4.c suffers the issue as its comments:

/* On some versions of dejagnu this test will fail when
   biarch testing with RUNTESTFLAGS="--target_board=unix
   '{-m64,-m32}'" due to -m32 being added on the command
   line after the dg-options -mpowerpc64.
   common/config/rs6000/rs6000-common.c:
   rs6000_handle_option disables -mpowerpc64 for -m32.  */

As tested, on test machine with dejaGnu 1.6.2, the compilation
option order looks like: -m32 ... -mpowerpc64, option
-mpowerpc64 still takes effect;  While on test machine with
dejaGnu 1.5.1, the option order looks like: -mpowerpc64 ... -m32,
option -mpowerpc64 is disabled by -m32, then the case fails.

This fix leverages the new effective target has_arch_ppc64 and
places dg-options before dg-require-effective-target (it makes
dg-options to be used for has_arch_ppc64 checking), on machine
with dejaGnu 1.6.2, the checking succeeds and the case passes;
while on machine with dejaGnu 1.5.1, the checking fails then
the case is marked as unsupported.

Tested on powerpc64-linux-gnu P7 and P8,
and powerpc64le-linux-gnu P9 and P10.

I'll push this soon if no objections.

BR,
Kewen
-
PR testsuite/106680

gcc/testsuite/ChangeLog:

* gcc.target/powerpc/bswap64-4.c: Adjust with has_arch_ppc64.
---
 gcc/testsuite/gcc.target/powerpc/bswap64-4.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.target/powerpc/bswap64-4.c 
b/gcc/testsuite/gcc.target/powerpc/bswap64-4.c
index 5acbb91ee38..85a7bbbd367 100644
--- a/gcc/testsuite/gcc.target/powerpc/bswap64-4.c
+++ b/gcc/testsuite/gcc.target/powerpc/bswap64-4.c
@@ -1,7 +1,8 @@
 /* { dg-do compile { target { powerpc*-*-* } } } */
 /* { dg-skip-if "" { powerpc*-*-aix* } } */
-/* { dg-options "-O2 -mpowerpc64" } */
 /* { dg-require-effective-target ilp32 } */
+/* { dg-options "-O2 -mpowerpc64" } */
+/* { dg-require-effective-target has_arch_ppc64 } */
 /* { dg-final { scan-assembler-times "lwbrx" 2 { target { ! has_arch_pwr7 } } 
} } */
 /* { dg-final { scan-assembler-times "stwbrx" 2 { target { ! has_arch_pwr7 } } 
} } */
 /* { dg-final { scan-assembler-times "ldbrx" 1 { target has_arch_pwr7 } } } */
--
2.27.0

Patch ping ([PATCH] libstdc++: Outline the overlapping case of string _M_replace into a separate function [PR105329])

Hi!

On Wed, Aug 10, 2022 at 01:27:51PM +0200, Jakub Jelinek via Gcc-patches wrote:
> On Wed, Jul 27, 2022 at 11:33:29AM +0200, Jakub Jelinek via Gcc-patches wrote:
> > The following patch is partially a workaround for bogus warnings
> > when the compiler isn't able to fold _M_disjunct call into constant
> > false, but also an optimization attempt - assuming _M_disjunct (__s)
> > is rare, the patch should shrink code size for the common case and
> > use library or for non-standard instantiations an out of line
> > function to handle the rare case.
> 
> I'd like to ping this patch.

I'd like to ping this patch again.
https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598896.html

Thanks.

Jakub

Re: [PATCH] libstdc++: Add test for std::con/disjunction's short circuiting

On Tue, 30 Aug 2022 at 18:14, Patrick Palka via Libstdc++
 wrote:
>
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk?

Yes, thanks for adding this.

>
> libstdc++-v3/ChangeLog:
>
> * testsuite/20_util/logical_traits/requirements/short_circuit.cc: New 
> test.
> ---
>  .../requirements/short_circuit.cc | 32 +++
>  1 file changed, 32 insertions(+)
>  create mode 100644 
> libstdc++-v3/testsuite/20_util/logical_traits/requirements/short_circuit.cc
>
> diff --git 
> a/libstdc++-v3/testsuite/20_util/logical_traits/requirements/short_circuit.cc 
> b/libstdc++-v3/testsuite/20_util/logical_traits/requirements/short_circuit.cc
> new file mode 100644
> index 000..b6a8091cdb0
> --- /dev/null
> +++ 
> b/libstdc++-v3/testsuite/20_util/logical_traits/requirements/short_circuit.cc
> @@ -0,0 +1,32 @@
> +// { dg-do compile { target c++17 } }
> +
> +#include 
> +
> +template struct A { using type = typename T::type; };
> +using invalid = A;
> +
> +// [meta.logical]/3: For a specialization conjunction, if
> +// there is a template type argument B_i for which bool(B_i::value) is false,
> +// then instantiating conjunction::value does not require the
> +// instantiation of B_j::value for j > i.
> +
> +static_assert(!std::conjunction_v);
> +static_assert(!std::conjunction_v);
> +static_assert(!std::conjunction_v);
> +
> +static_assert(!std::conjunction_v);
> +static_assert(!std::conjunction_v invalid>);
> +static_assert(!std::conjunction_v);
> +
> +// [meta.logical]/8: For a specialization disjunction, if
> +// there is a template type argument B_i for which bool(B_i::value) is true,
> +// then instantiating disjunction::value does not require the
> +// instantiation of B_j::value for j > i.
> +
> +static_assert(std::disjunction_v);
> +static_assert(std::disjunction_v);
> +static_assert(std::disjunction_v);
> +
> +static_assert(std::disjunction_v);
> +static_assert(std::disjunction_v invalid>);
> +static_assert(std::disjunction_v);
> --
> 2.37.2.490.g6c8e4ee870
>

Re: [PATCH] x86: Handle V8BF in expand_vec_perm_broadcast_1

2022-08-31 Thread Hongtao Liu via Gcc-patches

On Wed, Aug 31, 2022 at 2:52 PM Kong, Lingling via Gcc-patches
 wrote:
>
> Hi,
>
> Handle E_V8BFmode in expand_vec_perm_broadcast_1 and 
> ix86_expand_vector_init_duplicate.
> Ok for trunk?
>
> gcc/ChangeLog:
>
> PR target/106742
> * config/i386/i386-expand.cc (ix86_expand_vector_init_duplicate):
> Handle V8BF mode.
> (expand_vec_perm_broadcast_1): Ditto.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/i386/pr106742.c: New test.
> ---
>  gcc/config/i386/i386-expand.cc   | 17 -
>  gcc/testsuite/gcc.target/i386/pr106742.c | 10 ++
>  2 files changed, 22 insertions(+), 5 deletions(-)  create mode 100644 
> gcc/testsuite/gcc.target/i386/pr106742.c
>
> diff --git a/gcc/config/i386/i386-expand.cc b/gcc/config/i386/i386-expand.cc 
> index 4b216308a18..a08222fe1b6 100644
> --- a/gcc/config/i386/i386-expand.cc
> +++ b/gcc/config/i386/i386-expand.cc
> @@ -15030,11 +15030,15 @@ ix86_expand_vector_init_duplicate (bool mmx_ok, 
> machine_mode mode,
>   dperm.op0 = dperm.op1 = gen_reg_rtx (mode);
>   dperm.one_operand_p = true;
>
> - if (mode == V8HFmode)
> + if (mode == V8HFmode || mode == V8BFmode)
> {
> - tmp1 = force_reg (HFmode, val);
> + rtx (*gen_vec_set_0) (rtx, rtx, rtx) = NULL;
> + tmp1 = mode == V8HFmode ? force_reg (HFmode, val)
> + : force_reg (BFmode, val);
tmp1 = force_reg (GET_MODE_INNER (mode), val);
>   tmp2 = gen_reg_rtx (mode);
> - emit_insn (gen_vec_setv8hf_0 (tmp2, CONST0_RTX (mode), tmp1));
> + gen_vec_set_0 = mode == V8HFmode ? gen_vec_setv8hf_0
> +  : gen_vec_setv8bf_0;
add @ to vec_set_0 as (define_insn "@vec_set_0" and pass
mode to vec_set_0 as
emit_insn (gen_vec_set_0 (mode, tmp2, CONST0_RTX (mode), tmp1));
> + emit_insn (gen_vec_set_0 (tmp2, CONST0_RTX (mode), tmp1));

>   tmp1 = gen_lowpart (mode, tmp2);
> }
>   else
> @@ -21822,17 +21826,20 @@ expand_vec_perm_broadcast_1 (struct 
> expand_vec_perm_d *d)
>return true;
>
>  case E_V8HFmode:
> +case E_V8BFmode:
>/* This can be implemented via interleave and pshufd.  */
>if (d->testing_p)
> return true;
>
>if (elt >= nelt2)
> {
> - gen = gen_vec_interleave_highv8hf;
> + gen = vmode == V8HFmode ? gen_vec_interleave_highv8hf
> + : gen_vec_interleave_highv8bf;
Similar, add @ to define_insn and pass gen_vec_interleave.
>   elt -= nelt2;
> }
>else
> -   gen = gen_vec_interleave_lowv8hf;
> +   gen = vmode == V8HFmode ? gen_vec_interleave_lowv8hf
> +   : gen_vec_interleave_lowv8bf;
>nelt2 /= 2;
>
>dest = gen_reg_rtx (vmode);
> diff --git a/gcc/testsuite/gcc.target/i386/pr106742.c 
> b/gcc/testsuite/gcc.target/i386/pr106742.c
> new file mode 100644
> index 000..4a53cd49902
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/i386/pr106742.c
> @@ -0,0 +1,10 @@
> +/* { dg-do compile } */
> +/* { dg-options " -msse2 -mno-avx2 -O1" } */
> +typedef __bf16 v8bf __attribute__ ((__vector_size__ (16)));
> +
> +v8bf
> +vec_init_dup_v8bf (__bf16 a1)
> +{
> +  return __extension__ (v8bf) { a1, a1, a1, a1, a1, a1, a1, a1 }; }
> +/* { dg-final { scan-assembler-times "punpcklwd" 1} } */
> --
> 2.18.2
>


-- 
BR,
Hongtao

Re: Modula-2: merge followup (brief update on the progress of the new linking implementation)

On 8/30/22 17:36, Gaius Mulley wrote:
> Martin Liška  writes:
> 
>> On 8/30/22 13:03, Gaius Mulley via Gcc-patches wrote:
>>>
>>> Another very brief update to say that I'm now tidying up the code and
>>> primary platform testing
>>>
>>> regards,
>>> Gaius
>>
>> Hello.
>>
>> As you may know I'm working on the documentation migration from texinfo to 
>> Sphinx
>> and I noticed you have quite some documentation written in Texinfo. Thus, I 
>> tried
>> using my conversion script, but ended with:
>>
>> $ m2/boot-bin/mc --olang=c++ --h-file-prefix=G
>> -I/home/marxin/Programming/gcc2/gcc/m2/gm2-libs
>> -I/home/marxin/Programming/gcc2/gcc/m2/gm2-compiler
>> -I/home/marxin/Programming/gcc2/gcc/m2/gm2-libiberty
>> -I/home/marxin/Programming/gcc2/gcc/m2/gm2-gcc --quiet
>> --gcc-config-system --extended-opaque
>> -o=m2/gm2-compiler-boot/M2GCCDeclare.c
>> /home/marxin/Programming/gcc2/gcc/m2/gm2-compiler/M2GCCDeclare.mod
>> /*  --extended-opaque seen therefore no #include will be used and everything 
>> will be declared in full.  */
>> terminate called after throwing an instance of 'unsigned int'
>> Aborted (core dumped)
>>
>> $ Program received signal SIGSEGV, Segmentation fault.
>> 0x0043771e in decl_isConst (n=0xbabababababababa) at 
>> /home/marxin/Programming/gcc2/gcc/m2/mc-boot/Gdecl.c:22530
>> 22530  return n->kind == const_;
>> (gdb) bt
>> #0  0x0043771e in decl_isConst (n=0xbabababababababa) at 
>> /home/marxin/Programming/gcc2/gcc/m2/mc-boot/Gdecl.c:22530
>> #1  0x00432526 in addEnumConst (n=0xbabababababababa) at 
>> /home/marxin/Programming/gcc2/gcc/m2/mc-boot/Gdecl.c:19914
>> #2  0x004313aa in visitNode (v=0x17cd5910, n=0xbabababababababa, 
>> p=...) at /home/marxin/Programming/gcc2/gcc/m2/mc-boot/Gdecl.c:19240
>> #3  0x00430ba9 in visitIntrinsic (v=0x17cd5910, n=0x5015c0, p=...) 
>> at /home/marxin/Programming/gcc2/gcc/m2/mc-boot/Gdecl.c:18871
>> #4  0x00430cc6 in visitDependants (v=0x17cd5910, n=0x5015c0, p=...) 
>> at /home/marxin/Programming/gcc2/gcc/m2/mc-boot/Gdecl.c:18923
>> #5  0x004313c1 in visitNode (v=0x17cd5910, n=0x5015c0, p=...) at 
>> /home/marxin/Programming/gcc2/gcc/m2/mc-boot/Gdecl.c:19241
>> #6  0x004325b8 in populateTodo (p=...) at 
>> /home/marxin/Programming/gcc2/gcc/m2/mc-boot/Gdecl.c:19938
>> #7  0x00432613 in topologicallyOut (c=..., t=..., v=..., tp=..., 
>> pc=..., pt=..., pv=...) at 
>> /home/marxin/Programming/gcc2/gcc/m2/mc-boot/Gdecl.c:19957
>> #8  0x00426ffb in outDeclsImpC (p=0x17cc39a0, s=...) at 
>> /home/marxin/Programming/gcc2/gcc/m2/mc-boot/Gdecl.c:13910
>> #9  0x00432f2f in outImpC (p=0x17cc39a0, n=0x541800) at 
>> /home/marxin/Programming/gcc2/gcc/m2/mc-boot/Gdecl.c:20142
>> #10 0x004337b5 in outC (p=0x17cc39a0, n=0x541800) at 
>> /home/marxin/Programming/gcc2/gcc/m2/mc-boot/Gdecl.c:20285
>> #11 0x0043bd9b in decl_out () at 
>> /home/marxin/Programming/gcc2/gcc/m2/mc-boot/Gdecl.c:26621
>> #12 0x0043eae6 in doCompile (s=0x50a190) at 
>> /home/marxin/Programming/gcc2/gcc/m2/mc-boot/GmcComp.c:223
>> #13 0x0043f646 in mcComp_compile (s=0x50a190) at 
>> /home/marxin/Programming/gcc2/gcc/m2/mc-boot/GmcComp.c:637
>> #14 0x00451d91 in init () at 
>> /home/marxin/Programming/gcc2/gcc/m2/mc-boot/Gtop.c:59
>> #15 0x00451da8 in _M2_top_init (argc=12, argv=0x7fffd9a8) at 
>> /home/marxin/Programming/gcc2/gcc/m2/mc-boot/Gtop.c:64
>> #16 0x0048b4c2 in main (argc=12, argv=0x7fffd9a8) at
>> m2/mc-boot/main.c:179
> 
> Hi Martin,
> 
> ah interesting - thanks for the trace will look into the above fault.

Hello.

Thanks.

> 
>> Have a couple of questions:
>>
>> 1) What's gcc/m2/www/tools/createhtml.py about? Will you need it once
>> the branch is merged to master?
> 
> no it will be purged.  It was part of the tool set used to generate
> https://www.nongnu.org/gm2/homepage.html from gm2.texi.  createhtml
> allowed gcc-10, 11, 12 documentation to coexist.
> 
> I've seen and like the demos of the documentation you are producing.
> I was curious is there provision for older gcc release documentation
> (say gcc-10 onwards) to be accessible via the Sphinx’s documentation?

No, only for the current master branch.

> 
>> 2) You generate some texi files on fly: ./gcc/m2/gm2-ebnf.texi, 
>> ./gcc/m2/Builtins.texi
>> Would it be possible emitting Sphinx in the future?
> 
> yes sure - I was meaning to email about this earlier.  Are there any
> do/don'ts you would advise when writing texinfo (or subset/template
> examples?).

How do you mean that? You should ideally generate .rst (Sphinx markup)
instead of the *.texi files. These will be then included in the converted
Sphinx manual similarly to how you include it now to the Texinfo manual.

Does it make sense?

Cheers,
Martin

> I'm keen to change the tools which generate gm2-ebnf.texi
> and Builtins.texi to accommodate Sphinx.
> 
> regards,
> Gaius

Re: [PATCH] [ranger] x == -0.0 does not mean we can replace x with -0.0

2022-08-31 Thread Aldy Hernandez via Gcc-patches

I think we can model the signed zero problem by keeping track of a
sign property, similar to how we keep track of a NAN property.  The
property can be yes, no, or unknown, and would apply to the entire
range.

[0.0, 0.0] SIGN => -0.0 singleton
[0.0, 0.0] !SIGN=> +0.0 singleton
[0.0, 0.0] VARYING  => [-0.0, +0.0] sign unknown

frange::singleton_p() would return the appropriate zero if the sign
bit is definitely known, otherwise it would return NULL, which would
keep VRP from propagating it.

This is a sample of how I envision it working with __builtin_signbit:

=== BB 2 
Imports: x_3(D)
Exports: _1  x_3(D)
 _1 : x_3(D)(I)
x_3(D)  [frange] float VARYING
 :
_1 = __builtin_signbit (x_3(D));
if (_1 == 0)
  goto ; [INV]
else
  goto ; [INV]

2->3  (T) _1 :  [irange] int [0, 0] NONZERO 0x0
2->3  (T) x_3(D) :  [frange] float [0.0,  Inf] !SIGN
2->4  (F) _1 :  [irange] int [-INF, -1][1, +INF]
2->4  (F) x_3(D) :  [frange] float [ -Inf, 0.0] SIGN

That is, on the TRUE side x_3 can be assumed to be positive, including
the zero.  On the FALSE side x_3 is negative, also including the zero.

We can keep the endpoints in sync with the sign bit for free, since we
have endpoints.  So, setting the sign bit on a range to either yes or
no, would automatically intersect it to [-INF, 0] or [0, +INF]
respectively.

With this in play, VRP could propagate a 0.0 if it knows the sign.  For example:

  if (x == 0.0 && __builtin_signbit (x) == 0)
bark(x);

...would generate:

=== BB 2 
Imports: x_3(D)
Exports: x_3(D)
x_3(D)  [frange] float VARYING
 :
if (x_3(D) == 0.0)
  goto ; [INV]
else
  goto ; [INV]

2->3  (T) x_3(D) :  [frange] float [0.0, 0.0] !NAN

=== BB 3 
Imports: x_3(D)
Exports: _1  x_3(D)
 _1 : x_3(D)(I)
x_3(D)  [frange] float [0.0, 0.0] !NAN
 :
_1 = __builtin_signbit (x_3(D));
if (_1 == 0)
  goto ; [INV]
else
  goto ; [INV]

3->4  (T) _1 :  [irange] int [0, 0] NONZERO 0x0
3->4  (T) x_3(D) :  [frange] float [0.0, 0.0] !NAN !SIGN
3->5  (F) _1 :  [irange] int [-INF, -1][1, +INF]
3->5  (F) x_3(D) :  [frange] float [0.0, 0.0] !NAN SIGN

=== BB 4 
x_3(D)  [frange] float [0.0, 0.0] !NAN !SIGN
 :
bark (0.0);

That is, on the 2->3 edge we know x_3 is 0.0 and !NAN, but have no
information on the sign bit.  Then out of BB3, we know both that x_3
is 0.0 as well as the appropriate sign.  Ultimately this leads us to
propagate +0.0 in BB4.

I have most^Wall of it coded without regressions, with the exception
of how to coerce the range-op machinery to play nice with builtins
(details below).  But I wanted to make sure we're all on the same
page.

A couple questions:

Can I safely assume that +0.0 in the source (say, x = 0.0) has the
sign bit cleared, and vice versa for -0.0?

What's the deal with __builtin_signbit?  Can I fold it to 0/1, or must
I return the actual signbit, because I see differing behavior whether
we fold a known value or not:

abulafia:~$ cat a.c
float nzero = -0.0;

main(){
printf("0x%x\n", __builtin_signbit(-0.0));
printf("0x%x\n", __builtin_signbit(nzero));
}
abulafia:~$ gcc a.c -w && ./a.out
0x1
0x8000

When Andrew comes back from PTO, we'll need to talk about propagating
builtins.  Currently range-ops' op1_range is used to unwind back from
conditionals.  For example:

_1 = x_9 + 5
if (_1 == 0)

On the TRUE side we use op1_range to solve:

0 = x_9 + 5;

We currently only handle assignments and conditionals.  We would need
to ability to wind back through builtins since __builtin_signbit is
not part of the IL:

_1 = __builtin_signbit (x_3(D));
if (_1 == 0)

We have no way to augment the range for x_3 when examining the
builtin.We do have a way of folding the builtin on a forward
analysis, but that's a separate thing.

Thoughts?
Aldy

On Mon, Aug 29, 2022 at 3:22 PM Jakub Jelinek  wrote:
>
> On Mon, Aug 29, 2022 at 03:13:21PM +0200, Aldy Hernandez wrote:
> > It seems to me we can do this optimization regardless, but then treat
> > positive and negative zero the same throughout the frange class.
> > Particularly, in frange::singleton_p().  We should never return TRUE
> > for any version of 0.0.  This will keep VRP from propagating an
> > incorrect 0.0, since all VRP does is propagate when a range is
> > provably a singleton.  Also, frange::zero_p() shall return true for
> > any version of 0.0.
>
> Well, I think for HONOR_SIGNED_ZEROS it would be nice if frange was able to
> differentiate between 0.0 and -0.0.
> One reason is e.g. to be able to optimize copysign/signbit - if we can
> prove that the sign bit on some value will be always cleared or always set,
> we can fold those.
> On the other side, with -fno-signed-zeros it is invalid to use
> copysign/signbit on values that could be zero (well, nothing guarantees
> whether the sign bit is set or clear), so for MODE_HAS_SIGNED_ZEROS &&
>

Re: [PATCH] Add _GLIBCXX_DEBUG backtrace generation

On Wed, 31 Aug 2022 at 06:05, François Dumont  wrote:
>
> After a second thought here is an even cleaner version. No more function
> rename, current pretty_print is fine.
>
>  libstdc++: [_GLIBCXX_DEBUG] Add backtrace generation on demand
>
>Add _GLIBCXX_DEBUG_BACKTRACE macro to activate backtrace
> generation on
>  _GLIBCXX_DEBUG assertions. Prerequisite is to have configure the
> lib with:
>
>  --enable-libstdcxx-backtrace=yes
>
>  libstdc++-v3/ChangeLog:
>
>  * include/debug/formatter.h
>  [_GLIBCXX_HAVE_STACKTRACE](__glibcxx_backtrace_state): Declare.
> [_GLIBCXX_HAVE_STACKTRACE](__glibcxx_backtrace_create_state): Declare.
> [_GLIBCXX_HAVE_STACKTRACE](__glibcxx_backtrace_full_callback): Define.
> [_GLIBCXX_HAVE_STACKTRACE](__glibcxx_backtrace_error_callback): Define.
> [_GLIBCXX_HAVE_STACKTRACE](__glibcxx_backtrace_full_func): Define.
>  [_GLIBCXX_HAVE_STACKTRACE](__glibcxx_backtrace_full): Declare.
> [_GLIBCXX_HAVE_STACKTRACE](_Error_formatter::_M_backtrace_state): New.
> [_GLIBCXX_HAVE_STACKTRACE](_Error_formatter::_M_backtrace_full): New.
>  * src/c++11/debug.cc
> [_GLIBCXX_HAVE_STACKTRACE](print_backtrace): New.
>  (_Error_formatter::_M_error()): Adapt.
>  * src/libbacktrace/Makefile.am: Add backtrace.c.
>  * src/libbacktrace/Makefile.in: Regenerate.
>  * src/libbacktrace/backtrace-rename.h (backtrace_full): New.
>  *
> testsuite/23_containers/vector/debug/assign4_backtrace_neg.cc: New test.
>  * doc/xml/manual/debug_mode.xml: Document
> _GLIBCXX_DEBUG_BACKTRACE.
>  * doc/xml/manual/using.xml: Likewise.
> Ok to commit ?

OK for trunk, thanks.

The small change to print_raw in this patch makes me wonder whether
that function is actually useful.

It supports two modes, print with max precision, and print without.
The only time we use it to print with max precision we pass a string
of exactly the right length, so the precision is not needed (but the
caller has to get the string length correct: if we increase _S_indent
and do not increase the "" literal passed to print_raw, the
effects would be wrong).

Wouldn't it be better to just use fprintf directly when we want to
print without precision, and use a minimum field width instead of
precision for indenting? i.e. ...

--- a/libstdc++-v3/src/c++11/debug.cc
+++ b/libstdc++-v3/src/c++11/debug.cc
@@ -608,15 +608,6 @@ namespace
print_literal(PrintContext& ctx, const char(&word)[Length])
{ print_word(ctx, word, Length - 1); }

-  void
-  print_raw(PrintContext& ctx, const char* str, ptrdiff_t nbc = -1)
-  {
-if (nbc >= 0)
-  ctx._M_column += fprintf(stderr, "%.*s", (int)nbc, str);
-else
-  ctx._M_column += fprintf(stderr, "%s", str);
-  }
-
  void
  print_word(PrintContext& ctx, const char* word, ptrdiff_t nbc = -1)
  {
@@ -643,12 +634,9 @@ namespace
   || (ctx._M_column + visual_length < ctx._M_max_length)
   || (visual_length >= ctx._M_max_length && ctx._M_column == 1))
  {
-   // If this isn't the first line, indent
+   // If this isn't the first line, indent.
   if (ctx._M_column == 1 && !ctx._M_first_line)
- {
-   const char spacing[PrintContext::_S_indent + 1] = "";
-   print_raw(ctx, spacing, PrintContext::_S_indent);
- }
+ ctx._M_column += fprintf(stderr, "%*c", PrintContext::_S_indent, ' ');

   int written = fprintf(stderr, "%.*s", (int)length, word);

@@ -1112,7 +1100,7 @@ namespace __gnu_debug
PrintContext ctx;
if (_M_file)
  {
-   print_raw(ctx, _M_file);
+   ctx._M_column += fprintf(stderr, "%s", _M_file);
   print_literal(ctx, ":");
   go_to_next_line = true;
  }

Re: [PATCH 3/3] libstdc++: Implement ranges::zip_view from P2321R2

On Fri, 26 Aug 2022 at 21:05, Jonathan Wakely wrote:
>
> On Tue, 23 Aug 2022 at 02:38, Patrick Palka via Libstdc++
>  wrote:
> > +template
> > +  constexpr void
> > +  __tuple_for_each(_Fp&& __f, _Tuple&& __tuple)
> > +  {
> > +   std::apply([&](_Ts&&... __elts) {
> > + (std::__invoke(__f, std::forward<_Ts>(__elts)), ...);
> > +   }, std::forward<_Tuple>(__tuple));
>
>
> Nicole Mazzuca noticed a problem with the definition of
> tuple-for-each, which I've just added to the issues list:
> https://cplusplus.github.io/LWG/issue3755

Ignore this. The __tuple_for_each function is only ever called by the
library, so there's no way for something like Evil to be passed to it.

Re: [PATCH 1/2] libstdc++: Implement ranges::adjacent_view from P2321R2

On Tue, 30 Aug 2022 at 18:14, Patrick Palka via Libstdc++
 wrote:
>
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk?

> +constexpr
> +_Iterator(__as_sentinel, iterator_t<_Base> __first, iterator_t<_Base> 
> __last)
> +{
> +  if constexpr (!bidirectional_range<_Base>)
> +   for (auto& __it : _M_current)
> + __it = __last;
> +  else
> +   for (ssize_t __i = _Nm-1; __i >= 0; --__i)

ssize_t is defined by POSIX in  but isn't in ISO C or
C++. It looks like MinGW defines it to ... something ... sometimes,
but I don't think we can rely on it for non-POSIX targets.

> +template
> +  struct _Adjacent : __adaptor::_RangeAdaptorClosure
> +  {
> +   template
> + requires (_Nm == 0) || __detail::__can_adjacent_view<_Nm, _Range>
> + [[nodiscard]]
> + constexpr auto
> + operator()(_Range&& __r) const

Does this attribute actually work here?

I thought we needed to use `operator() [[nodiscard]]` for functions
with a requires-clause, because otherwise the attribute gives a parse
error. Maybe I've misremembered the problem, and it just doesn't give
a -Wunused-result warning. The decl above is setting off my spidey
sense for some reason though.

Re: [PATCH] OpenMP, libgomp: Environment variable syntax extension.

2022-08-31 Thread Marcel Vollweiler


Hi Jakub,

Am 22.08.2022 um 17:35 schrieb Jakub Jelinek:

+/* Default values of ICVs according to the OpenMP standard.  */
+struct gomp_default_icv_t gomp_default_icv_values = {
+  .run_sched_var = GFS_DYNAMIC,
+  .run_sched_chunk_size = 1,
+  .max_active_levels_var = 1,
+  .bind_var = omp_proc_bind_false,
+  .nteams_var = 0,
+  .teams_thread_limit_var = 0,
+  .default_device_var = 0
+};


Why this var (and if it is really needed, why it isn't const)?
You seem to be using only 2 fields from it:
libgomp/libgomp.h:extern struct gomp_default_icv_t gomp_default_icv_values;
libgomp/env.c:struct gomp_default_icv_t gomp_default_icv_values = {
libgomp/target.c:new->icvs.nteams = gomp_default_icv_values.nteams_var;
libgomp/target.c:new->icvs.default_device = 
gomp_default_icv_values.default_device_var;


gomp_default_icv_values is used to store the default values of the ICVs as
defined in the OpenMP standard. Previously this was not necessary since there
were only host-related ICVs being initialized with the corresponding default
values in gomp_global_icv.

gomp_global_icv cannot be used to get the default values in general as they are
overwritten as soon as we parse an environment variable for a host-related ICV.
In contrast we need the default values not only at the very beginning when we
parse the environment variables, but also when we create device-specific ICV
structs. The point in time when a device-specific ICV struct is created can be
when a particular device is used first (as we don't know the device numbers
during parsing the environment variables).

I introduced gomp_default_icv_values in order to have the default ICV values
centralized (like in gomp_global_icv before) for a better readability and
maintanance.

As you stated correctly below, there were still multiple places using the
defaults directly. I modified that.




+
  bool gomp_cancel_var = false;
  enum gomp_target_offload_t gomp_target_offload_var
= GOMP_TARGET_OFFLOAD_DEFAULT;
@@ -104,86 +123,94 @@ int goacc_default_dims[GOMP_DIM_MAX];
  static int wait_policy;
  static unsigned long stacksize = GOMP_DEFAULT_STACKSIZE;

-/* Parse the OMP_SCHEDULE environment variable.  */
-
  static void
-parse_schedule (void)
+print_env_var_error (const char *env, const char *val)
  {
-  char *env, *end;
+  char name[val - env];
+  memcpy (name, env, val - env - 1);
+  name[val - env - 1] = '\0';
+  gomp_error ("Invalid value for environment variable %s: %s", name, val);


Why the temporary buffer (especially VLA)?
Just
   gomp_error ("Invalid value for environment variable %.*s: %s",
(int) (val - env - 1), env, val);
should do the job.


Good hint, thanks! (changed)




+/* Parse the OMP_SCHEDULE environment variable.  */
+static bool
+parse_schedule (const char *env, const char *val, void * const params[])


No space after *


Changed.




+#define ENTRY(NAME) NAME, sizeof (NAME) - 1
+static const struct envvar
+{
+  const char *name;
+  int name_len;
+  uint8_t flag_vars[3];
+  uint8_t flag;
+  bool (*parse_func) (const char *, const char *, void * const[]);
+} envvars[] = {
+  { ENTRY ("OMP_SCHEDULE"),
+{ GOMP_ICV_SCHEDULE, GOMP_ICV_SCHEDULE_CHUNK_SIZE },
+GOMP_ENV_SUFFIX_DEV | GOMP_ENV_SUFFIX_ALL | GOMP_ENV_SUFFIX_DEV_X,
+&parse_schedule },
+  { ENTRY ("OMP_NUM_TEAMS"),
+{ GOMP_ICV_NTEAMS },
+GOMP_ENV_SUFFIX_DEV | GOMP_ENV_SUFFIX_ALL | GOMP_ENV_SUFFIX_DEV_X,
+&parse_int },
+  { ENTRY ("OMP_DYNAMIC"),
+{ GOMP_ICV_DYNAMIC },
+GOMP_ENV_SUFFIX_DEV | GOMP_ENV_SUFFIX_ALL | GOMP_ENV_SUFFIX_DEV_X,
+&parse_boolean },
+  { ENTRY ("OMP_TEAMS_THREAD_LIMIT"),
+{ GOMP_ICV_TEAMS_THREAD_LIMIT },
+GOMP_ENV_SUFFIX_DEV | GOMP_ENV_SUFFIX_ALL | GOMP_ENV_SUFFIX_DEV_X,
+&parse_int },
+  { ENTRY ("OMP_THREAD_LIMIT"),
+{ GOMP_ICV_THREAD_LIMIT },
+GOMP_ENV_SUFFIX_DEV | GOMP_ENV_SUFFIX_ALL | GOMP_ENV_SUFFIX_DEV_X,
+&parse_unsigned_long },
+  { ENTRY ("OMP_NUM_THREADS"),
+{ GOMP_ICV_NTHREADS, GOMP_ICV_NTHREADS_LIST, GOMP_ICV_NTHREADS_LIST_LEN },
+GOMP_ENV_SUFFIX_DEV | GOMP_ENV_SUFFIX_ALL | GOMP_ENV_SUFFIX_DEV_X,
+&parse_unsigned_long_list },
+  { ENTRY ("OMP_PROC_BIND"),
+{ GOMP_ICV_BIND, GOMP_ICV_BIND_LIST, GOMP_ICV_BIND_LIST_LEN },
+GOMP_ENV_SUFFIX_DEV | GOMP_ENV_SUFFIX_ALL | GOMP_ENV_SUFFIX_DEV_X,
+&parse_bind_var },
+  { ENTRY ("OMP_MAX_ACTIVE_LEVELS"),
+{ GOMP_ICV_MAX_ACTIVE_LEVELS },
+GOMP_ENV_SUFFIX_DEV | GOMP_ENV_SUFFIX_ALL | GOMP_ENV_SUFFIX_DEV_X,
+&parse_unsigned_long },
+  { ENTRY ("OMP_WAIT_POLICY"),
+{ GOMP_ICV_WAIT_POLICY },
+GOMP_ENV_SUFFIX_DEV | GOMP_ENV_SUFFIX_ALL | GOMP_ENV_SUFFIX_DEV_X,
+&parse_wait_policy },
+  { ENTRY ("OMP_STACKSIZE"),
+{ GOMP_ICV_STACKSIZE },
+GOMP_ENV_SUFFIX_DEV | GOMP_ENV_SUFFIX_ALL | GOMP_ENV_SUFFIX_DEV_X,
+&parse_stacksize },
+  { ENTRY ("OMP_CANCELLATION"), { GOMP_ICV_CANCELLATION }, 0, &parse_boolean },
+  { ENTRY ("OMP_DISPLAY_AFFINITY"), { GOMP_ICV_DISPLAY_AFFINITY }, 0,
+&parse_boolean

[PATCH] tree-optimization/65244 - include asserts in predicates for uninit

When uninit computes the actual predicates from the control dependence
edges it currently skips those that are assert-like (where one edge
leads to a block which ends in a noreturn call).  That leads to
bogus uninit diagnostics when applied on the USE side.

Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.

PR tree-optimization/65244
* gimple-predicate-analysis.h (predicate::init_from_control_deps):
Add argument to specify whether the predicate is for the USE.
* gimple-predicate-analysis.cc (predicate::init_from_control_deps):
Also include predicates effective fallthru control edges when
the predicate is for the USE.

* gcc.dg/uninit-pr65244-2.c: New testcase.
---
 gcc/gimple-predicate-analysis.cc| 17 +++--
 gcc/gimple-predicate-analysis.h |  2 +-
 gcc/testsuite/gcc.dg/uninit-pr65244-2.c | 20 
 3 files changed, 32 insertions(+), 7 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/uninit-pr65244-2.c

diff --git a/gcc/gimple-predicate-analysis.cc b/gcc/gimple-predicate-analysis.cc
index 6b2e347536a..49500b77832 100644
--- a/gcc/gimple-predicate-analysis.cc
+++ b/gcc/gimple-predicate-analysis.cc
@@ -1666,7 +1666,7 @@ predicate::normalize (gimple *use_or_def, bool is_use)
 
 void
 predicate::init_from_control_deps (const vec *dep_chains,
-  unsigned num_chains)
+  unsigned num_chains, bool is_use)
 {
   gcc_assert (is_empty ());
 
@@ -1675,7 +1675,8 @@ predicate::init_from_control_deps (const vec 
*dep_chains,
 return;
 
   if (DEBUG_PREDICATE_ANALYZER && dump_file)
-fprintf (dump_file, "init_from_control_deps {%s}:\n",
+fprintf (dump_file, "init_from_control_deps [%s] {%s}:\n",
+is_use ? "USE" : "DEF",
 format_edge_vecs (dep_chains, num_chains).c_str ());
 
   /* Convert the control dependency chain into a set of predicates.  */
@@ -1711,8 +1712,12 @@ predicate::init_from_control_deps (const vec 
*dep_chains,
  if (is_gimple_call (cond_stmt) && EDGE_COUNT (e->src->succs) >= 2)
/* Ignore EH edge.  Can add assertion on the other edge's flag.  */
continue;
- /* Skip if there is essentially one succesor.  */
- if (EDGE_COUNT (e->src->succs) == 2)
+ /* Skip this edge if it is bypassing an abort - when the
+condition is not satisfied we are neither reaching the
+definition nor the use so it isn't meaningful.  Note if
+we are processing the use predicate the condition is
+meaningful.  See PR65244.  */
+ if (!is_use && EDGE_COUNT (e->src->succs) == 2)
{
  edge e1;
  edge_iterator ei1;
@@ -1941,7 +1946,7 @@ uninit_analysis::init_use_preds (predicate &use_preds, 
basic_block def_bb,
  condition under which the definition in DEF_BB is used in USE_BB.
  Each OR subexpression is represented by one element of DEP_CHAINS,
  where each element consists of a series of AND subexpressions.  */
-  use_preds.init_from_control_deps (dep_chains, num_chains);
+  use_preds.init_from_control_deps (dep_chains, num_chains, true);
   return !use_preds.is_empty ();
 }
 
@@ -2050,7 +2055,7 @@ uninit_analysis::init_from_phi_def (gphi *phi)
   /* Convert control dependence chains to the predicate in *THIS under
  which the PHI operands are defined to values for which M_EVAL is
  false.  */
-  m_phi_def_preds.init_from_control_deps (dep_chains, num_chains);
+  m_phi_def_preds.init_from_control_deps (dep_chains, num_chains, false);
   return !m_phi_def_preds.is_empty ();
 }
 
diff --git a/gcc/gimple-predicate-analysis.h b/gcc/gimple-predicate-analysis.h
index 48da8f70efd..bc0248d7a93 100644
--- a/gcc/gimple-predicate-analysis.h
+++ b/gcc/gimple-predicate-analysis.h
@@ -65,7 +65,7 @@ class predicate
 return m_preds;
   }
 
-  void init_from_control_deps (const vec *, unsigned);
+  void init_from_control_deps (const vec *, unsigned, bool);
 
   void dump (gimple *, const char *) const;
 
diff --git a/gcc/testsuite/gcc.dg/uninit-pr65244-2.c 
b/gcc/testsuite/gcc.dg/uninit-pr65244-2.c
new file mode 100644
index 000..a28893cdcb5
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/uninit-pr65244-2.c
@@ -0,0 +1,20 @@
+/* { dg-do compile } */
+/* { dg-options "-Og -Wuninitialized -ftree-bit-ccp -fno-thread-jumps 
-fdump-tree-uninit2" } */
+
+void exit(int __status) __attribute__ ((__noreturn__));
+int posix_memalign(void **__memptr, __SIZE_TYPE__ __alignment,
+  __SIZE_TYPE__ __size);
+
+void *f(void)
+{
+  void *ptr;
+
+  if (posix_memalign(&ptr, 16, 256) != 0)
+exit(1);
+
+  return ptr; /* { dg-bogus "uninitialized" } */
+}
+
+/* Make sure the uninit pass has something to do, add to the set of
+   disabled optimizations if not.  */
+/* { dg-final { scan-tree-dump "# ptr_. = PHI" "uninit2" } } */
-- 
2.35.3

[PATCH] tree-optimization/73550 - more switch handling improvements for uninit

The following makes predicate analysis handle case labels with
a non-singleton contiguous range.

Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.

PR tree-optimization/73550
* gimple-predicate-analysis.cc (predicate::init_from_control_deps):
Sanitize debug dumping.  Handle case labels with a CASE_HIGH.
(predicate::dump): Adjust for better readability.
---
 gcc/gimple-predicate-analysis.cc | 77 +---
 1 file changed, 50 insertions(+), 27 deletions(-)

diff --git a/gcc/gimple-predicate-analysis.cc b/gcc/gimple-predicate-analysis.cc
index 00c6bfc50a3..6b2e347536a 100644
--- a/gcc/gimple-predicate-analysis.cc
+++ b/gcc/gimple-predicate-analysis.cc
@@ -1674,6 +1674,10 @@ predicate::init_from_control_deps (const vec 
*dep_chains,
   if (num_chains == 0)
 return;
 
+  if (DEBUG_PREDICATE_ANALYZER && dump_file)
+fprintf (dump_file, "init_from_control_deps {%s}:\n",
+format_edge_vecs (dep_chains, num_chains).c_str ());
+
   /* Convert the control dependency chain into a set of predicates.  */
   m_preds.reserve (num_chains);
 
@@ -1740,7 +1744,8 @@ predicate::init_from_control_deps (const vec 
*dep_chains,
 
  if (DEBUG_PREDICATE_ANALYZER && dump_file)
{
- fprintf (dump_file, "one_pred = ");
+ fprintf (dump_file, "%d -> %d: one_pred = ",
+  e->src->index, e->dest->index);
  dump_pred_info (one_pred);
  fputc ('\n', dump_file);
}
@@ -1773,24 +1778,41 @@ predicate::init_from_control_deps (const vec 
*dep_chains,
}
}
  /* If more than one label reaches this block or the case
-label doesn't have a single value (like the default one)
-fail.  */
- if (!l
- || !CASE_LOW (l)
- || (CASE_HIGH (l)
- && !operand_equal_p (CASE_LOW (l), CASE_HIGH (l), 0)))
+label doesn't have a contiguous range of values (like the
+default one) fail.  */
+ if (!l || !CASE_LOW (l))
{
  has_valid_pred = false;
  break;
}
-
- pred_info one_pred;
- one_pred.pred_lhs = gimple_switch_index (gs);
- one_pred.pred_rhs = CASE_LOW (l);
- one_pred.cond_code = EQ_EXPR;
- one_pred.invert = false;
- t_chain.safe_push (one_pred);
- has_valid_pred = true;
+ else if (!CASE_HIGH (l)
+ || operand_equal_p (CASE_LOW (l), CASE_HIGH (l)))
+   {
+ pred_info one_pred;
+ one_pred.pred_lhs = gimple_switch_index (gs);
+ one_pred.pred_rhs = CASE_LOW (l);
+ one_pred.cond_code = EQ_EXPR;
+ one_pred.invert = false;
+ t_chain.safe_push (one_pred);
+ has_valid_pred = true;
+   }
+ else
+   {
+ /* Support a case label with a range with
+two predicates.  We're overcommitting on
+the MAX_CHAIN_LEN budget by at most a factor
+of two here.  */
+ pred_info one_pred;
+ one_pred.pred_lhs = gimple_switch_index (gs);
+ one_pred.pred_rhs = CASE_LOW (l);
+ one_pred.cond_code = GE_EXPR;
+ one_pred.invert = false;
+ t_chain.safe_push (one_pred);
+ one_pred.pred_rhs = CASE_HIGH (l);
+ one_pred.cond_code = LE_EXPR;
+ t_chain.safe_push (one_pred);
+ has_valid_pred = true;
+   }
}
  else
{
@@ -1803,22 +1825,24 @@ predicate::init_from_control_deps (const vec 
*dep_chains,
   if (!has_valid_pred)
break;
   else
-   m_preds.safe_push (t_chain);
+   m_preds.quick_push (t_chain);
 }
 
-  if (DEBUG_PREDICATE_ANALYZER && dump_file)
+  if (has_valid_pred)
 {
-  fprintf (dump_file, "init_from_control_deps {%s}:\n",
-  format_edge_vecs (dep_chains, num_chains).c_str ());
-  dump (NULL, "");
+  gcc_assert (m_preds.length () != 0);
+  if (DEBUG_PREDICATE_ANALYZER && dump_file)
+   dump (NULL, "");
 }
-
-  if (has_valid_pred)
-gcc_assert (m_preds.length () != 0);
   else
-/* Clear M_PREDS to indicate failure.  */
-m_preds.release ();
+{
+  if (DEBUG_PREDICATE_ANALYZER && dump_file)
+   fprintf (dump_file, "\tFAILED\n");
+  /* Clear M_PREDS to indicate failure.  */
+  m_preds.release ();
+}
 }
+
 /* Store a PRED in *THIS.  */
 
 void
@@ -1856,9 +1880,8 @@ predicate::dump (gimple *stmt, const char *msg) const
   else
fprintf (dump_file, "\t(");
   dump_pred_chain (m_preds[i]);
-

[PATCH] libcpp, v3: Add -Winvalid-utf8 warning [PR106655]

On Tue, Aug 30, 2022 at 05:51:26PM -0400, Jason Merrill wrote:
> This hunk now seems worth factoring out of the four places it occurs.
> 
> It also seems the comment for _cpp_valid_utf8 needs to be updated: it
> currently says it's not called when parsing a string.

Ok, so like this?

2022-08-31  Jakub Jelinek  

PR c++/106655
libcpp/
* include/cpplib.h (struct cpp_options): Implement C++23
P2295R6 - Support for UTF-8 as a portable source file encoding.
Add cpp_warn_invalid_utf8 and cpp_input_charset_explicit fields.
(enum cpp_warning_reason): Add CPP_W_INVALID_UTF8 enumerator.
* init.cc (cpp_create_reader): Initialize cpp_warn_invalid_utf8
and cpp_input_charset_explicit.
* charset.cc (_cpp_valid_utf8): Adjust function comment.
* lex.cc (UCS_LIMIT): Define.
(utf8_continuation): New const variable.
(utf8_signifier): Move earlier in the file.
(_cpp_warn_invalid_utf8, _cpp_handle_multibyte_utf8): New functions.
(_cpp_skip_block_comment): Handle -Winvalid-utf8 warning.
(skip_line_comment): Likewise.
(lex_raw_string, lex_string): Likewise.
gcc/
* doc/invoke.texi (-Winvalid-utf8): Document it.
gcc/c-family/
* c.opt (-Winvalid-utf8): New warning.
* c-opts.c (c_common_handle_option) :
Set cpp_opts->cpp_input_charset_explicit.
(c_common_post_options): If -finput-charset=UTF-8 is explicit
in C++23, enable -Winvalid-utf8 by default and if -pedantic
or -pedantic-errors, make it a pedwarn.
gcc/testsuite/
* c-c++-common/cpp/Winvalid-utf8-1.c: New test.
* c-c++-common/cpp/Winvalid-utf8-2.c: New test.
* g++.dg/cpp23/Winvalid-utf8-1.C: New test.
* g++.dg/cpp23/Winvalid-utf8-2.C: New test.
* g++.dg/cpp23/Winvalid-utf8-3.C: New test.
* g++.dg/cpp23/Winvalid-utf8-4.C: New test.
* g++.dg/cpp23/Winvalid-utf8-5.C: New test.
* g++.dg/cpp23/Winvalid-utf8-6.C: New test.
* g++.dg/cpp23/Winvalid-utf8-7.C: New test.
* g++.dg/cpp23/Winvalid-utf8-8.C: New test.

--- libcpp/include/cpplib.h.jj  2022-08-31 10:19:45.226452609 +0200
+++ libcpp/include/cpplib.h 2022-08-31 12:25:42.451125755 +0200
@@ -560,6 +560,13 @@ struct cpp_options
  cpp_bidirectional_level.  */
   unsigned char cpp_warn_bidirectional;

+  /* True if libcpp should warn about invalid UTF-8 characters in comments.
+ 2 if it should be a pedwarn.  */
+  unsigned char cpp_warn_invalid_utf8;
+
+  /* True if -finput-charset= option has been used explicitly.  */
+  bool cpp_input_charset_explicit;
+
   /* Dependency generation.  */
   struct
   {
@@ -666,7 +673,8 @@ enum cpp_warning_reason {
   CPP_W_CXX11_COMPAT,
   CPP_W_CXX20_COMPAT,
   CPP_W_EXPANSION_TO_DEFINED,
-  CPP_W_BIDIRECTIONAL
+  CPP_W_BIDIRECTIONAL,
+  CPP_W_INVALID_UTF8
 };

 /* Callback for header lookup for HEADER, which is the name of a
--- libcpp/init.cc.jj   2022-08-31 10:19:45.260452148 +0200
+++ libcpp/init.cc  2022-08-31 12:25:42.451125755 +0200
@@ -227,6 +227,8 @@ cpp_create_reader (enum c_lang lang, cpp
   CPP_OPTION (pfile, ext_numeric_literals) = 1;
   CPP_OPTION (pfile, warn_date_time) = 0;
   CPP_OPTION (pfile, cpp_warn_bidirectional) = bidirectional_unpaired;
+  CPP_OPTION (pfile, cpp_warn_invalid_utf8) = 0;
+  CPP_OPTION (pfile, cpp_input_charset_explicit) = 0;

   /* Default CPP arithmetic to something sensible for the host for the
  benefit of dumb users like fix-header.  */
--- libcpp/charset.cc.jj2022-08-26 16:06:10.578493272 +0200
+++ libcpp/charset.cc   2022-08-31 12:34:18.921176118 +0200
@@ -1742,9 +1742,9 @@ convert_ucn (cpp_reader *pfile, const uc
 case, no diagnostic is emitted, and the return value of FALSE should cause
 a new token to be formed.

-Unlike _cpp_valid_ucn, this will never be called when lexing a string; only
-a potential identifier, or a CPP_OTHER token.  NST is unused in the latter
-case.
+_cpp_valid_utf8 can be called when lexing a potential identifier, or a
+CPP_OTHER token or for the purposes of -Winvalid-utf8 warning in string or
+character literals.  NST is unused when not in a potential identifier.

 As in _cpp_valid_ucn, IDENTIFIER_POS is 0 when not in an identifier, 1 for
 the start of an identifier, or 2 otherwise.  */
--- libcpp/lex.cc.jj2022-08-31 10:19:45.327451236 +0200
+++ libcpp/lex.cc   2022-08-31 12:45:47.929906159 +0200
@@ -50,6 +50,9 @@ static const struct token_spelling token
 #define TOKEN_SPELL(token) (token_spellings[(token)->type].category)
 #define TOKEN_NAME(token) (token_spellings[(token)->type].name)

+/* ISO 10646 defines the UCS codespace as the range 0-0x10 inclusive.  */
+#define UCS_LIMIT 0x10
+
 static void add_line_note (cpp_buffer *, const uchar *, unsigned int);
 static int skip_line_comment (cpp_reader *);
 static void skip_whitespace (cpp_reader *, cppchar_t);
@@ -1704,6 +1707,148 @@ maybe_warn

Re: [PATCH] d: Fix #error You must define PREFERRED_DEBUGGING_TYPE if DWARF is not supported (PR105659)

2022-08-31 Thread Iain Buclaw via Gcc-patches

Excerpts from Joseph Myers's message of August 30, 2022 11:53 pm:
> On Fri, 26 Aug 2022, Richard Biener via Gcc-patches wrote:
> 
>> I was hoping Joseph would chime in here - I recollect debugging this kind
>> of thing and a thread about this a while back but unfortunately I do not
>> remember the details here (IIRC some things get included where they
>> better should not be).
> 
> See .  
> Is there some reason it's problematic to avoid having defaults.h or 
> ${cpu_type}/${cpu_type}.h included in tm_d.h, and instead have tm_d.h only 
> include D-specific headers?
> 

In targets such as arm-elf, we still need to pull in definitions from
${cpu_type}/${cpu_type}-d.cc into default-d.cc.

All I can think that might suffice is having D-specific prototype
headers in all targets as ${cpu_type}/${cpu_type}-d.h.

At this location:
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config.gcc;h=1104508488818ff589dbc0890cf3fc475ae5977a;hb=refs/heads/master#l560

if test -f ${srcdir}/config/${cpu_type}/${cpu_type}-d.h
then
tm_d_file=${cpu_type}/${cpu_type}-d.h
fi


Looks like RustFE ripped out their target support for now.

https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=1c8ebf66965509008329b6e0425ffda407265263
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=3cd9342634e38100a9fa6a4bec4d958ca3a4ab60
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=a15ee6c3e5d710556d145e6af499b09993c4ee64

Iain.

[PATCH (pushed)] fix -Winconsistent-missing-override clang warning

Fixes:
gcc/value-range.h:357:16: warning: 'set_nonnegative' overrides
a member function but is not marked 'override' [-Winconsistent-missing-override]

gcc/ChangeLog:

* value-range.h: Add override.
---
 gcc/value-range.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/value-range.h b/gcc/value-range.h
index 07379d58f88..b25dd30d88a 100644
--- a/gcc/value-range.h
+++ b/gcc/value-range.h
@@ -354,7 +354,7 @@ public:
   virtual bool nonzero_p () const;
   virtual void set_nonzero (tree type);
   virtual void set_zero (tree type);
-  virtual void set_nonnegative (tree type);
+  virtual void set_nonnegative (tree type) override;
   frange& operator= (const frange &);
   bool operator== (const frange &) const;
   bool operator!= (const frange &r) const { return !(*this == r); }
-- 
2.37.2

[PATCH (pushed)] fix clang warnings (-Winconsistent-missing-override)

Part 2.

gcc/ChangeLog:

* value-range.h: Add more override keywords.
---
 gcc/value-range.h | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/gcc/value-range.h b/gcc/value-range.h
index b25dd30d88a..f7f3665be07 100644
--- a/gcc/value-range.h
+++ b/gcc/value-range.h
@@ -350,10 +350,10 @@ public:
   virtual bool singleton_p (tree *result = NULL) const override;
   virtual bool supports_type_p (const_tree type) const override;
   virtual void accept (const vrange_visitor &v) const override;
-  virtual bool zero_p () const;
-  virtual bool nonzero_p () const;
-  virtual void set_nonzero (tree type);
-  virtual void set_zero (tree type);
+  virtual bool zero_p () const override;
+  virtual bool nonzero_p () const override;
+  virtual void set_nonzero (tree type) override;
+  virtual void set_zero (tree type) override;
   virtual void set_nonnegative (tree type) override;
   frange& operator= (const frange &);
   bool operator== (const frange &) const;
-- 
2.37.2

Re: [PATCH (pushed)] fix -Winconsistent-missing-override clang warning

2022-08-31 Thread Aldy Hernandez via Gcc-patches

Thanks.

On Wed, Aug 31, 2022 at 2:18 PM Martin Liška  wrote:
>
> Fixes:
> gcc/value-range.h:357:16: warning: 'set_nonnegative' overrides
> a member function but is not marked 'override' 
> [-Winconsistent-missing-override]
>
> gcc/ChangeLog:
>
> * value-range.h: Add override.
> ---
>  gcc/value-range.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/gcc/value-range.h b/gcc/value-range.h
> index 07379d58f88..b25dd30d88a 100644
> --- a/gcc/value-range.h
> +++ b/gcc/value-range.h
> @@ -354,7 +354,7 @@ public:
>virtual bool nonzero_p () const;
>virtual void set_nonzero (tree type);
>virtual void set_zero (tree type);
> -  virtual void set_nonnegative (tree type);
> +  virtual void set_nonnegative (tree type) override;
>frange& operator= (const frange &);
>bool operator== (const frange &) const;
>bool operator!= (const frange &r) const { return !(*this == r); }
> --
> 2.37.2
>

[PATCH (pushed)] remove unused function

PR tree-optimization/106789

gcc/ChangeLog:

* range-op-float.cc (default_frelop_fold_range): Remove the
  function.
---
 gcc/range-op-float.cc | 16 
 1 file changed, 16 deletions(-)

diff --git a/gcc/range-op-float.cc b/gcc/range-op-float.cc
index d859309f863..c30f2af391c 100644
--- a/gcc/range-op-float.cc
+++ b/gcc/range-op-float.cc
@@ -232,22 +232,6 @@ frange_drop_ninf (frange &r, tree type)
   r.intersect (tmp);
 }
 
-// Default implementation of fold_range for relational operators.
-// This amounts to passing on any known relations from the oracle, iff
-// we know the operands are not NAN or -ffinite-math-only holds.
-
-static inline bool
-default_frelop_fold_range (irange &r, tree type,
- const frange &op1, const frange &op2,
- relation_kind rel, relation_kind my_rel)
-{
-  if (frelop_early_resolve (r, type, op1, op2, rel, my_rel))
-return true;
-
-  r.set_varying (type);
-  return true;
-}
-
 // (X <= VAL) produces the range of [MIN, VAL].
 
 static void
-- 
2.37.2

[COMMITTED] Stream out endpoints for frange.

2022-08-31 Thread Aldy Hernandez via Gcc-patches

We only stream out the FP properties for global float ranges
(currently only NAN).  The following patch adds the endpoints as well.

gcc/ChangeLog:

* value-range-storage.cc (frange_storage_slot::set_frange): Save
endpoints.
(frange_storage_slot::get_frange): Restore endpoints.
* value-range-storage.h (class frange_storage_slot): Add endpoint
fields.
---
 gcc/value-range-storage.cc | 18 +++---
 gcc/value-range-storage.h  |  8 +---
 2 files changed, 12 insertions(+), 14 deletions(-)

diff --git a/gcc/value-range-storage.cc b/gcc/value-range-storage.cc
index 494392737ac..b7a23fa9825 100644
--- a/gcc/value-range-storage.cc
+++ b/gcc/value-range-storage.cc
@@ -253,6 +253,8 @@ frange_storage_slot::set_frange (const frange &r)
   gcc_checking_assert (fits_p (r));
   gcc_checking_assert (!r.undefined_p ());
 
+  m_min = r.m_min;
+  m_max = r.m_max;
   m_props = r.m_props;
 }
 
@@ -261,18 +263,12 @@ frange_storage_slot::get_frange (frange &r, tree type) 
const
 {
   gcc_checking_assert (r.supports_type_p (type));
 
-  // FIXME: NANs get special treatment, because we need [NAN, NAN] in
-  // the range to properly represent it, not just the NAN flag in the
-  // property bits.  This will go away when we stream out the
-  // endpoints.
-  if (m_props.get_nan ().yes_p ())
-{
-  r = frange_nan (type);
-  return;
-}
-
-  r.set_varying (type);
+  r.set_undefined ();
+  r.m_kind = VR_RANGE;
   r.m_props = m_props;
+  r.m_type = type;
+  r.m_min = m_min;
+  r.m_max = m_max;
   r.normalize_kind ();
 
   if (flag_checking)
diff --git a/gcc/value-range-storage.h b/gcc/value-range-storage.h
index 9cd6b9f7bec..f506789f3d1 100644
--- a/gcc/value-range-storage.h
+++ b/gcc/value-range-storage.h
@@ -113,9 +113,11 @@ class GTY (()) frange_storage_slot
   frange_storage_slot (const frange &r) { set_frange (r); }
   DISABLE_COPY_AND_ASSIGN (frange_storage_slot);
 
-  // We can get away with just storing the properties because the type
-  // can be gotten from the SSA, and UNDEFINED is unsupported, so it
-  // can only be a range.
+  // We can get away with just storing the properties and the
+  // endpoints because the type can be gotten from the SSA, and
+  // UNDEFINED is unsupported, so it can only be a VR_RANGE.
+  REAL_VALUE_TYPE m_min;
+  REAL_VALUE_TYPE m_max;
   frange_props m_props;
 };
 
-- 
2.37.1

Re: Modula-2: merge followup (brief update on the progress of the new linking implementation)

2022-08-31 Thread Gaius Mulley via Gcc-patches

Martin Liška  writes:

> How do you mean that? You should ideally generate .rst (Sphinx markup)
> instead of the *.texi files. These will be then included in the converted
> Sphinx manual similarly to how you include it now to the Texinfo manual.
>
> Does it make sense?
>
> Cheers,
> Martin

ah right - yes this makes sense.  I mistakenly thought the .rst files
could be automatically generated from texinfo sources.  In any case
generating .rst directly will likely contain advantages,

regards,
Gaius

[PATCH] tree-optimization/90994 - fix uninit diagnostics with EH

r12-3640-g94c12ffac234b2 sneaked in a hack to avoid the diagnostic
for the testcase in PR90994 which sees non-call EH control flow
confusing predicate analysis.  The following patch instead adjusts
the existing code handling EH to handle non-calls and do what I
think was intented.

Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.

PR tree-optimization/90994
* gimple-predicate-analysis.cc (): Ignore exceptional
control flow and skip the edge for the purpose of
predicate generation also for non-calls.

* g++.dg/torture/pr90994.C: New testcase.
---
 gcc/gimple-predicate-analysis.cc   | 13 +
 gcc/testsuite/g++.dg/torture/pr90994.C | 40 ++
 2 files changed, 48 insertions(+), 5 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/torture/pr90994.C

diff --git a/gcc/gimple-predicate-analysis.cc b/gcc/gimple-predicate-analysis.cc
index 49500b77832..58eade433dc 100644
--- a/gcc/gimple-predicate-analysis.cc
+++ b/gcc/gimple-predicate-analysis.cc
@@ -41,6 +41,7 @@
 #include "calls.h"
 #include "value-query.h"
 #include "cfganal.h"
+#include "tree-eh.h"
 
 #include "gimple-predicate-analysis.h"
 
@@ -1709,9 +1710,6 @@ predicate::init_from_control_deps (const vec 
*dep_chains,
}
  /* Get the conditional controlling the bb exit edge.  */
  gimple *cond_stmt = gsi_stmt (gsi);
- if (is_gimple_call (cond_stmt) && EDGE_COUNT (e->src->succs) >= 2)
-   /* Ignore EH edge.  Can add assertion on the other edge's flag.  */
-   continue;
  /* Skip this edge if it is bypassing an abort - when the
 condition is not satisfied we are neither reaching the
 definition nor the use so it isn't meaningful.  Note if
@@ -1819,10 +1817,15 @@ predicate::init_from_control_deps (const vec 
*dep_chains,
  has_valid_pred = true;
}
}
+ else if (stmt_can_throw_internal (cfun, cond_stmt)
+  && !(e->flags & EDGE_EH))
+   /* Ignore the exceptional control flow and proceed as if
+  E were a fallthru without a controlling predicate for
+  both the USE (valid) and DEF (questionable) case.  */
+   has_valid_pred = true;
  else
{
- /* Disabled.  See PR 90994.
-has_valid_pred = false;  */
+ has_valid_pred = false;
  break;
}
}
diff --git a/gcc/testsuite/g++.dg/torture/pr90994.C 
b/gcc/testsuite/g++.dg/torture/pr90994.C
new file mode 100644
index 000..8feb36f2361
--- /dev/null
+++ b/gcc/testsuite/g++.dg/torture/pr90994.C
@@ -0,0 +1,40 @@
+// { dg-do compile }
+// { dg-additional-options "-fnon-call-exceptions -Wuninitialized" }
+
+extern void printval(unsigned char v);
+
+inline int readbyte(unsigned char *__restrict presult,
+   unsigned char volatile *ptr)
+{
+  unsigned char v;
+  try {
+  v = *ptr;
+  } catch (...) {
+  return -1;
+  }
+  *presult = v;
+  return 0;
+}
+
+int incorrectWarning(unsigned char volatile *ptr)
+{
+  int error;
+  unsigned char first;
+  unsigned char second;
+
+  error = readbyte(&first, ptr);
+  asm("\n\n\n\n\n" : : "X" (error != 0));
+  if (error != 0)
+goto err;
+
+  error = readbyte(&second, ptr);
+  if (error != 0)
+goto err;
+
+  printval(first);   // { dg-bogus "uninitialized" }
+  printval(second);
+  return 0;
+
+err:
+  return error;
+}
-- 
2.35.3

Re: Modula-2: merge followup (brief update on the progress of the new linking implementation)

On 8/31/22 15:19, Gaius Mulley wrote:
> Martin Liška  writes:
> 
>> How do you mean that? You should ideally generate .rst (Sphinx markup)
>> instead of the *.texi files. These will be then included in the converted
>> Sphinx manual similarly to how you include it now to the Texinfo manual.
>>
>> Does it make sense?
>>
>> Cheers,
>> Martin
> 
> ah right - yes this makes sense.

Goo!

> I mistakenly thought the .rst files
> could be automatically generated from texinfo sources.  In any case
> generating .rst directly will likely contain advantages,

Yes, that's what I'm doing for the existing documentation, but the conversion
is not perfect and I had to make some manual changes to the emitted .rst 
content.

So please fix the crash I reported and I can convert GM2 texi manual.

Cheers,
Martin

> 
> regards,
> Gaius

Re: [PATCH 1/2] libstdc++: Implement ranges::adjacent_view from P2321R2

2022-08-31 Thread Patrick Palka via Gcc-patches

On Wed, 31 Aug 2022, Jonathan Wakely wrote:

> On Tue, 30 Aug 2022 at 18:14, Patrick Palka via Libstdc++
>  wrote:
> >
> > Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
> 
> 
> > +constexpr
> > +_Iterator(__as_sentinel, iterator_t<_Base> __first, iterator_t<_Base> 
> > __last)
> > +{
> > +  if constexpr (!bidirectional_range<_Base>)
> > +   for (auto& __it : _M_current)
> > + __it = __last;
> > +  else
> > +   for (ssize_t __i = _Nm-1; __i >= 0; --__i)
> 
> ssize_t is defined by POSIX in  but isn't in ISO C or
> C++. It looks like MinGW defines it to ... something ... sometimes,
> but I don't think we can rely on it for non-POSIX targets.

I see.  Using ssize_t makes the loop a little cleaner but it's hardly
necessary, so consider it rewritten into:

  for (size_t __i = 0; __i < _Nm; ++__i)
{
  _M_current[_Nm - 1 - __i] = __last;
  ranges::advance(__last, -1, __first);
}

> 
> 
> > +template
> > +  struct _Adjacent : __adaptor::_RangeAdaptorClosure
> > +  {
> > +   template
> > + requires (_Nm == 0) || __detail::__can_adjacent_view<_Nm, _Range>
> > + [[nodiscard]]
> > + constexpr auto
> > + operator()(_Range&& __r) const
> 
> Does this attribute actually work here?
> 
> I thought we needed to use `operator() [[nodiscard]]` for functions
> with a requires-clause, because otherwise the attribute gives a parse
> error. Maybe I've misremembered the problem, and it just doesn't give
> a -Wunused-result warning. The decl above is setting off my spidey
> sense for some reason though.

Oops yeah, it looks like this position of [[nodiscard]] works with
standard concepts, but it's a parse error with -fconcepts-ts due to the
different requires-clause grammar.

Here's v2 which avoids using ssize_t, and puts the [[nodiscard]] after
'operator()' (_Zip and _ZipTransform have the same issue which I can
fix separately):

-- >8 --

libstdc++-v3/ChangeLog:

* include/std/ranges (adjacent_view): Define.
(enable_borrowed_range): Define.
(__detail::__repeated_tuple): Define.
(adjacent_view::_Iterator): Define.
(adjacent_view::_Sentinel): Define.
(views::__detail::__can_adjacent_view): Define.
(views::_Adjacent): Define.
(views::adjacent): Define.
(views::pairwise): Define.
* testsuite/std/ranges/adaptors/adjacent/1.cc: New test.
---
 libstdc++-v3/include/std/ranges   | 358 ++
 .../std/ranges/adaptors/adjacent/1.cc | 110 ++
 2 files changed, 468 insertions(+)
 create mode 100644 libstdc++-v3/testsuite/std/ranges/adaptors/adjacent/1.cc

diff --git a/libstdc++-v3/include/std/ranges b/libstdc++-v3/include/std/ranges
index 6e2e561ed12..2352aad76fc 100644
--- a/libstdc++-v3/include/std/ranges
+++ b/libstdc++-v3/include/std/ranges
@@ -5081,6 +5081,364 @@ namespace views::__adaptor
 
 inline constexpr _ZipTransform zip_transform;
   }
+
+  template
+requires view<_Vp> && (_Nm > 0)
+  class adjacent_view : public view_interface>
+  {
+_Vp _M_base = _Vp();
+
+template class _Iterator;
+template class _Sentinel;
+
+struct __as_sentinel
+{ };
+
+  public:
+adjacent_view() requires default_initializable<_Vp> = default;
+
+constexpr explicit
+adjacent_view(_Vp __base)
+  : _M_base(std::move(__base))
+{ }
+
+constexpr auto
+begin() requires (!__detail::__simple_view<_Vp>)
+{ return _Iterator(ranges::begin(_M_base), ranges::end(_M_base)); }
+
+constexpr auto
+begin() const requires range
+{ return _Iterator(ranges::begin(_M_base), ranges::end(_M_base)); }
+
+constexpr auto
+end() requires (!__detail::__simple_view<_Vp>)
+{
+  if constexpr (common_range<_Vp>)
+   return _Iterator(__as_sentinel{}, ranges::begin(_M_base), 
ranges::end(_M_base));
+  else
+   return _Sentinel(ranges::end(_M_base));
+}
+
+constexpr auto
+end() const requires range
+{
+  if constexpr (common_range)
+   return _Iterator(__as_sentinel{}, ranges::begin(_M_base), 
ranges::end(_M_base));
+  else
+   return _Sentinel(ranges::end(_M_base));
+}
+
+constexpr auto
+size() requires sized_range<_Vp>
+{
+  using _ST = decltype(ranges::size(_M_base));
+  using _CT = common_type_t<_ST, size_t>;
+  auto __sz = static_cast<_CT>(ranges::size(_M_base));
+  __sz -= std::min<_CT>(__sz, _Nm - 1);
+  return static_cast<_ST>(__sz);
+}
+
+constexpr auto
+size() const requires sized_range
+{
+  using _ST = decltype(ranges::size(_M_base));
+  using _CT = common_type_t<_ST, size_t>;
+  auto __sz = static_cast<_CT>(ranges::size(_M_base));
+  __sz -= std::min<_CT>(__sz, _Nm - 1);
+  return static_cast<_ST>(__sz);
+}
+  };
+
+  template
+inline constexpr bool enable_borrowed_range>
+  = enable_borrowed_range<_Vp>;
+
+  namespace __detail
+  {
+// Yield

Re: [PATCH 1/2] libstdc++: Implement ranges::adjacent_view from P2321R2

On Wed, 31 Aug 2022 at 14:30, Patrick Palka  wrote:
>
> On Wed, 31 Aug 2022, Jonathan Wakely wrote:
>
> > On Tue, 30 Aug 2022 at 18:14, Patrick Palka via Libstdc++
> >  wrote:
> > >
> > > Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
> >
> >
> > > +constexpr
> > > +_Iterator(__as_sentinel, iterator_t<_Base> __first, 
> > > iterator_t<_Base> __last)
> > > +{
> > > +  if constexpr (!bidirectional_range<_Base>)
> > > +   for (auto& __it : _M_current)
> > > + __it = __last;
> > > +  else
> > > +   for (ssize_t __i = _Nm-1; __i >= 0; --__i)
> >
> > ssize_t is defined by POSIX in  but isn't in ISO C or
> > C++. It looks like MinGW defines it to ... something ... sometimes,
> > but I don't think we can rely on it for non-POSIX targets.
>
> I see.  Using ssize_t makes the loop a little cleaner but it's hardly
> necessary, so consider it rewritten into:
>
>   for (size_t __i = 0; __i < _Nm; ++__i)
> {
>   _M_current[_Nm - 1 - __i] = __last;
>   ranges::advance(__last, -1, __first);
> }
>
> >
> >
> > > +template
> > > +  struct _Adjacent : __adaptor::_RangeAdaptorClosure
> > > +  {
> > > +   template
> > > + requires (_Nm == 0) || __detail::__can_adjacent_view<_Nm, 
> > > _Range>
> > > + [[nodiscard]]
> > > + constexpr auto
> > > + operator()(_Range&& __r) const
> >
> > Does this attribute actually work here?
> >
> > I thought we needed to use `operator() [[nodiscard]]` for functions
> > with a requires-clause, because otherwise the attribute gives a parse
> > error. Maybe I've misremembered the problem, and it just doesn't give
> > a -Wunused-result warning. The decl above is setting off my spidey
> > sense for some reason though.
>
> Oops yeah, it looks like this position of [[nodiscard]] works with
> standard concepts, but it's a parse error with -fconcepts-ts due to the
> different requires-clause grammar.
>
> Here's v2 which avoids using ssize_t, and puts the [[nodiscard]] after
> 'operator()' (_Zip and _ZipTransform have the same issue which I can
> fix separately):

OK for trunk with those changes, thanks.

[committed] libstdc++: Improve comments in std::reference_wrapper tests

Tested x86_64-linux, pushed to trunk.

-- >8 --

libstdc++-v3/ChangeLog:

* testsuite/20_util/reference_wrapper/invoke-2.cc: Improve
comments.
* testsuite/20_util/reference_wrapper/invoke-3.cc: Likewise.
* testsuite/20_util/reference_wrapper/invoke.cc: Likewise.
---
 libstdc++-v3/testsuite/20_util/reference_wrapper/invoke-2.cc | 3 ++-
 libstdc++-v3/testsuite/20_util/reference_wrapper/invoke-3.cc | 3 ++-
 libstdc++-v3/testsuite/20_util/reference_wrapper/invoke.cc   | 2 ++
 3 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/libstdc++-v3/testsuite/20_util/reference_wrapper/invoke-2.cc 
b/libstdc++-v3/testsuite/20_util/reference_wrapper/invoke-2.cc
index 2741510e756..fd3430cf0a9 100644
--- a/libstdc++-v3/testsuite/20_util/reference_wrapper/invoke-2.cc
+++ b/libstdc++-v3/testsuite/20_util/reference_wrapper/invoke-2.cc
@@ -16,7 +16,7 @@
 // with this library; see the file COPYING3.  If not see
 // .
 
-// 20.6.4 function object return types [func.ret]
+// C++11 20.8.3.4 reference_wrapper invocation [refwrap.invoke]
 #include 
 
 struct X
@@ -27,6 +27,7 @@ struct X
 
 void test01()
 {
+  // PR libstdc++/48521 std::result_of doesn't work with pointer to member
   typedef int (X::*mfp)(int);
   typedef int X::*mp;
   mfp m = &X::f;
diff --git a/libstdc++-v3/testsuite/20_util/reference_wrapper/invoke-3.cc 
b/libstdc++-v3/testsuite/20_util/reference_wrapper/invoke-3.cc
index e4124c9b57c..c25315b6751 100644
--- a/libstdc++-v3/testsuite/20_util/reference_wrapper/invoke-3.cc
+++ b/libstdc++-v3/testsuite/20_util/reference_wrapper/invoke-3.cc
@@ -17,7 +17,7 @@
 // with this library; see the file COPYING3.  If not see
 // .
 
-// 20.8.3.4 reference_wrapper invocation [refwrap.invoke]
+// C++11 20.8.3.4 reference_wrapper invocation [refwrap.invoke]
 #include 
 
 struct ABC
@@ -33,4 +33,5 @@ struct Concrete : ABC
 Concrete c;
 ABC& abc = c;
 
+// PR libstdc++/57336 Cannot INVOKE a reference_wrapper around an abstract type
 auto b = std::cref(abc)();
diff --git a/libstdc++-v3/testsuite/20_util/reference_wrapper/invoke.cc 
b/libstdc++-v3/testsuite/20_util/reference_wrapper/invoke.cc
index cd884fe66eb..b2abc812b79 100644
--- a/libstdc++-v3/testsuite/20_util/reference_wrapper/invoke.cc
+++ b/libstdc++-v3/testsuite/20_util/reference_wrapper/invoke.cc
@@ -17,6 +17,8 @@
 // with this library; see the file COPYING3.  If not see
 // .
 
+// C++11 20.8.3.4 reference_wrapper invocation [refwrap.invoke]
+
 #include 
 #include 
 #include 
-- 
2.37.2

[committed] libstdc++: Add noexcept-specifier to std::reference_wrapper::operator()

Tested x86_64-linux, pushed to trunk.

-- >8 --

This isn't required by the standard, but there's an LWG issue suggesting
to add it.

Also use __invoke_result instead of result_of, to match the spec in
recent standards.

libstdc++-v3/ChangeLog:

* include/bits/refwrap.h (reference_wrapper::operator()): Add
noexcept-specifier and use __invoke_result instead of result_of.
* testsuite/20_util/reference_wrapper/invoke-noexcept.cc: New test.
---
 libstdc++-v3/include/bits/refwrap.h   |  3 ++-
 .../20_util/reference_wrapper/invoke-noexcept.cc  | 15 +++
 2 files changed, 17 insertions(+), 1 deletion(-)
 create mode 100644 
libstdc++-v3/testsuite/20_util/reference_wrapper/invoke-noexcept.cc

diff --git a/libstdc++-v3/include/bits/refwrap.h 
b/libstdc++-v3/include/bits/refwrap.h
index 8016f87478e..976902bc7bc 100644
--- a/libstdc++-v3/include/bits/refwrap.h
+++ b/libstdc++-v3/include/bits/refwrap.h
@@ -348,8 +348,9 @@ _GLIBCXX_MEM_FN_TRAITS(&& noexcept, false_type, true_type)
 
   template
_GLIBCXX20_CONSTEXPR
-   typename result_of<_Tp&(_Args&&...)>::type
+   typename __invoke_result<_Tp&, _Args...>::type
operator()(_Args&&... __args) const
+   noexcept(__is_nothrow_invocable<_Tp&, _Args...>::value)
{
 #if __cplusplus > 201703L
  if constexpr (is_object_v)
diff --git 
a/libstdc++-v3/testsuite/20_util/reference_wrapper/invoke-noexcept.cc 
b/libstdc++-v3/testsuite/20_util/reference_wrapper/invoke-noexcept.cc
new file mode 100644
index 000..91b5d097f08
--- /dev/null
+++ b/libstdc++-v3/testsuite/20_util/reference_wrapper/invoke-noexcept.cc
@@ -0,0 +1,15 @@
+// { dg-do compile { target c++11 } }
+
+// C++11 20.8.3.4 reference_wrapper invocation [refwrap.invoke]
+
+#include 
+
+struct F
+{
+  int operator()() noexcept(true) { return 1; }
+  int operator()() const noexcept(false) { return 2; }
+};
+
+F f;
+static_assert( noexcept(std::ref(f)()) );
+static_assert( ! noexcept(std::cref(f)()) );
-- 
2.37.2

[PATCH] Fortran: Add IEEE_SIGNBIT and IEEE_FMA functions

2022-08-31 Thread FX via Gcc-patches

Hi,

These functions were added in Fortran 2018: 
https://gcc.gnu.org/wiki/Fortran2018Status
When it comes to floating-point and IEEE compliance, gfortran fully implements 
the 2003 and 2008 standards. In a series of patch, as time permits, I would 
like to add all Fortran 2018 features before the GCC 13 release process begins.

Regarding this patch, the functions are added to the IEEE_ARITHMETIC module, 
but are entirely expanded in the front-end, using GCC built-ins. They will 
benefit fully from middle-end optimisation where relevant, and on many targets 
FMA will reduce to a single instruction (as expected).

Regression-tested on x86_64-pc-linux-gnu. OK to commit?

FX




0001-fortran-Add-IEEE_SIGNBIT-and-IEEE_FMA-functions.patch
Description: Binary data

Re: [PATCH] rs6000: Don't ICE when we disassemble an MMA variable [PR101322]

On 8/31/22 4:22 AM, Kewen.Lin wrote:
> on 2022/8/27 11:50, Peter Bergner via Gcc-patches wrote:
>> -  tree src_type = TREE_TYPE (src_ptr);
>> +  tree src_type = (fncode == RS6000_BIF_DISASSEMBLE_ACC)
>> +  ? build_pointer_type (vector_quad_type_node)
>> +  : build_pointer_type (vector_pair_type_node);
> 
> Nit: it seems we can use existing ptr_vector_quad_type_node and 
> ptr_vector_pair_type_node?
> I assume the const qualifier is fine since it's for disassembling.

That's actually what I started with, but I got some type of gimple
verification error which I can't remember what it said.  Let me put
that back temporarily and I'll grab the error message.

>> +  if (TREE_TYPE (TREE_TYPE (src_ptr)) != src_type)
> 
> This line looks unexpected, the former is type char while the latter is type 
> __vector_pair *.
> 
> I guess you meant to compare the type of pointer type like: 
>
>TREE_TYPE (TREE_TYPE (src_ptr)) != TREE_TYPE (src_type)
> 
> or even with mode like:
> 
>TYPE_MODE (TREE_TYPE (TREE_TYPE (src_ptr))) != TYPE_MODE (TREE_TYPE 
> (src_type))

Maybe?  However, if that is the case, how can it be working for me?
Let me throw this in the debugger and verify the types and I'll report
back with what I find.

>> +src_ptr = build1 (VIEW_CONVERT_EXPR, src_type, src_ptr);
> 
> Nit: NOP_EXPR seems to be better suited here for pointer conversion.

NOP_EXPR is new to me (I don't play in the middle-end that often).
Let me look around at some other uses of it and I'll give it a try.
Thanks!

Peter

Re: [[GCC13][Patch][V3] 1/2] Add a new option -fstrict-flex-array[=n] and new attribute strict_flex_array

Hi, Joseph,

Thanks a lot for your comment.

> On Aug 30, 2022, at 6:53 PM, Joseph Myers  wrote:
> 
> On Tue, 30 Aug 2022, Qing Zhao via Gcc-patches wrote:
> 
>> Hi, Joseph and Nathan,
>> 
>> Could you please review the C and C++ FE parts of the patch?
>> 
>> https://gcc.gnu.org/pipermail/gcc-patches/2022-August/599901.html
> 
> I think some work is still needed on the diagnostic wording.
> 
>> +  "%qE attribute may not be specified for a non array field",
> 
> "non-array" not "non array".

Okay.

> 
>> +   "not supported with a ISO C before C99", name);
> 
> "a ISO C" is not proper usage.  I think something like "by ISO C before 
> C99" would be better.  Likewise "a ISO C++".
> 
> "!flag_isoc99" is more usual than "flag_isoc99 == 0".

Okay.

> 
>> +   "not supported with a GNU extension GNU89", name);
> 
> "a GNU extension" suggests a particular language feature, but I think 
> you're actually referring here to a whole language version rather than an 
> individual feature.

Is “not supported by GNU extension GNU89” better?

> 
> In any case, -std=gnu89 supports flexible array members.

Yes, but only [0],[1] are supported as flexible array members.  The C99 
flexible array member [] is not supported by GNU89, right?

Then, -fstrict-flex-arrays=3 is not supported by -std=gnu89.


>  So I'd expect 
> them to have exactly the same semantics as in C99, so disallowing a 
> particular feature for gnu89 here seems suspect.
> 
> In the manual, any literal code should be enclosed in @code{} or @samp{}.  
> That replaces the use of ASCII quotes "" that you currently have in the 
> documentation (that should never be used outside of @code, @samp and 
> similar).

Okay. Will update those places.
> 
>> +When -std=gnu89 is specified or C++ with GNU extension, only zero-length 
>> array
> 
> And @option{} should be used around "-std=gnu89" here (except as noted 
> above, I think it's suspect to disallow parts of this feature for gnu89).

Okay. Will update.
> 
>> +language. FOR ISO C before C99 and ISO C++, no language support for the 
>> flexible
> 
> "FOR" should be "For".

Okay.

thanks.

Qing
> 
> -- 
> Joseph S. Myers
> jos...@codesourcery.com

Re: [PATCH] libcpp, v3: Add -Winvalid-utf8 warning [PR106655]


On 8/31/22 07:14, Jakub Jelinek wrote:

On Tue, Aug 30, 2022 at 05:51:26PM -0400, Jason Merrill wrote:

This hunk now seems worth factoring out of the four places it occurs.

It also seems the comment for _cpp_valid_utf8 needs to be updated: it
currently says it's not called when parsing a string.


Ok, so like this?


OK, thanks.


2022-08-31  Jakub Jelinek  

PR c++/106655
libcpp/
* include/cpplib.h (struct cpp_options): Implement C++23
P2295R6 - Support for UTF-8 as a portable source file encoding.
Add cpp_warn_invalid_utf8 and cpp_input_charset_explicit fields.
(enum cpp_warning_reason): Add CPP_W_INVALID_UTF8 enumerator.
* init.cc (cpp_create_reader): Initialize cpp_warn_invalid_utf8
and cpp_input_charset_explicit.
* charset.cc (_cpp_valid_utf8): Adjust function comment.
* lex.cc (UCS_LIMIT): Define.
(utf8_continuation): New const variable.
(utf8_signifier): Move earlier in the file.
(_cpp_warn_invalid_utf8, _cpp_handle_multibyte_utf8): New functions.
(_cpp_skip_block_comment): Handle -Winvalid-utf8 warning.
(skip_line_comment): Likewise.
(lex_raw_string, lex_string): Likewise.
gcc/
* doc/invoke.texi (-Winvalid-utf8): Document it.
gcc/c-family/
* c.opt (-Winvalid-utf8): New warning.
* c-opts.c (c_common_handle_option) :
Set cpp_opts->cpp_input_charset_explicit.
(c_common_post_options): If -finput-charset=UTF-8 is explicit
in C++23, enable -Winvalid-utf8 by default and if -pedantic
or -pedantic-errors, make it a pedwarn.
gcc/testsuite/
* c-c++-common/cpp/Winvalid-utf8-1.c: New test.
* c-c++-common/cpp/Winvalid-utf8-2.c: New test.
* g++.dg/cpp23/Winvalid-utf8-1.C: New test.
* g++.dg/cpp23/Winvalid-utf8-2.C: New test.
* g++.dg/cpp23/Winvalid-utf8-3.C: New test.
* g++.dg/cpp23/Winvalid-utf8-4.C: New test.
* g++.dg/cpp23/Winvalid-utf8-5.C: New test.
* g++.dg/cpp23/Winvalid-utf8-6.C: New test.
* g++.dg/cpp23/Winvalid-utf8-7.C: New test.
* g++.dg/cpp23/Winvalid-utf8-8.C: New test.

--- libcpp/include/cpplib.h.jj  2022-08-31 10:19:45.226452609 +0200
+++ libcpp/include/cpplib.h 2022-08-31 12:25:42.451125755 +0200
@@ -560,6 +560,13 @@ struct cpp_options
   cpp_bidirectional_level.  */
unsigned char cpp_warn_bidirectional;
  
+  /* True if libcpp should warn about invalid UTF-8 characters in comments.

+ 2 if it should be a pedwarn.  */
+  unsigned char cpp_warn_invalid_utf8;
+
+  /* True if -finput-charset= option has been used explicitly.  */
+  bool cpp_input_charset_explicit;
+
/* Dependency generation.  */
struct
{
@@ -666,7 +673,8 @@ enum cpp_warning_reason {
CPP_W_CXX11_COMPAT,
CPP_W_CXX20_COMPAT,
CPP_W_EXPANSION_TO_DEFINED,
-  CPP_W_BIDIRECTIONAL
+  CPP_W_BIDIRECTIONAL,
+  CPP_W_INVALID_UTF8
  };
  
  /* Callback for header lookup for HEADER, which is the name of a

--- libcpp/init.cc.jj   2022-08-31 10:19:45.260452148 +0200
+++ libcpp/init.cc  2022-08-31 12:25:42.451125755 +0200
@@ -227,6 +227,8 @@ cpp_create_reader (enum c_lang lang, cpp
CPP_OPTION (pfile, ext_numeric_literals) = 1;
CPP_OPTION (pfile, warn_date_time) = 0;
CPP_OPTION (pfile, cpp_warn_bidirectional) = bidirectional_unpaired;
+  CPP_OPTION (pfile, cpp_warn_invalid_utf8) = 0;
+  CPP_OPTION (pfile, cpp_input_charset_explicit) = 0;
  
/* Default CPP arithmetic to something sensible for the host for the

   benefit of dumb users like fix-header.  */
--- libcpp/charset.cc.jj2022-08-26 16:06:10.578493272 +0200
+++ libcpp/charset.cc   2022-08-31 12:34:18.921176118 +0200
@@ -1742,9 +1742,9 @@ convert_ucn (cpp_reader *pfile, const uc
  case, no diagnostic is emitted, and the return value of FALSE should cause
  a new token to be formed.
  
-Unlike _cpp_valid_ucn, this will never be called when lexing a string; only

-a potential identifier, or a CPP_OTHER token.  NST is unused in the latter
-case.
+_cpp_valid_utf8 can be called when lexing a potential identifier, or a
+CPP_OTHER token or for the purposes of -Winvalid-utf8 warning in string or
+character literals.  NST is unused when not in a potential identifier.
  
  As in _cpp_valid_ucn, IDENTIFIER_POS is 0 when not in an identifier, 1 for

  the start of an identifier, or 2 otherwise.  */
--- libcpp/lex.cc.jj2022-08-31 10:19:45.327451236 +0200
+++ libcpp/lex.cc   2022-08-31 12:45:47.929906159 +0200
@@ -50,6 +50,9 @@ static const struct token_spelling token
  #define TOKEN_SPELL(token) (token_spellings[(token)->type].category)
  #define TOKEN_NAME(token) (token_spellings[(token)->type].name)
  
+/* ISO 10646 defines the UCS codespace as the range 0-0x10 inclusive.  */

+#define UCS_LIMIT 0x10
+
  static void add_line_note (cpp_buffer *, const uchar *, unsigned int);
  static int skip_line_comment (cpp_reader *);
  sta

Re: [PATCH] rs6000/test: Fix bswap64-4.c with has_arch_ppc64 [PR106680]

On 8/31/22 4:33 AM, Kewen.Lin wrote:
> @@ -1,7 +1,8 @@
>  /* { dg-do compile { target { powerpc*-*-* } } } */
>  /* { dg-skip-if "" { powerpc*-*-aix* } } */
> -/* { dg-options "-O2 -mpowerpc64" } */
>  /* { dg-require-effective-target ilp32 } */
> +/* { dg-options "-O2 -mpowerpc64" } */
> +/* { dg-require-effective-target has_arch_ppc64 } */

With many of our recent patches moving the dg-options before any
dg-requires-effectice-target so it affects the results of the
dg-requires-effectice-target test, this looks like it's backwards
from that process.  I understand why, so I think an explicit comment
here in the test case explaining why it's after in this case.
Just so in a few years when we come back to this test case, we
won't accidentally undo this change.

The other option would be to introduce -mdejagnu-32 and -mdejagnu-64
options that operate like our -mdejagnu-cpu= options and override any
-m32/-m64 option given on the command line (eg, RUNTESTFLAGS=...).
To be honest, I'm not sure how I feel about this suggestion! :-)
Maybe we'd only use it on the test cases like this one that we know
are sensitive to be overridden???

Peter

[PATCH] libcpp, v4: Add -Winvalid-utf8 warning [PR106655]

On Wed, Aug 31, 2022 at 09:55:29AM -0400, Jason Merrill wrote:
> On 8/31/22 07:14, Jakub Jelinek wrote:
> > On Tue, Aug 30, 2022 at 05:51:26PM -0400, Jason Merrill wrote:
> > > This hunk now seems worth factoring out of the four places it occurs.
> > > 
> > > It also seems the comment for _cpp_valid_utf8 needs to be updated: it
> > > currently says it's not called when parsing a string.
> > 
> > Ok, so like this?
> 
> OK, thanks.

Actually, it isn't enough to diagnose this in comments and character/string
literals, sorry for finding that out only today.

We don't accept invalid UTF-8 in identifiers, it fails the checking in there
(most of the times without errors), what we do is create CPP_OTHER tokens
out of those and then typically diagnose it when it is used somewhere.
Except it doesn't have to be used anywhere, it can be omitted.

So if we have say
#define I(x)
I(���)
like in the Winvalid-utf8-3.c test, we silently accept it.

This updated version extends the diagnostics even to those cases.
I can't use _cpp_handle_multibyte_utf8 in that case because it needs
different treatment (no bidi stuff which is emitted already from
forms_identifier_p etc.).

Tested so far on the new tests, ok for trunk if it passes full
bootstrap/regtest?

2022-08-31  Jakub Jelinek  

PR c++/106655
libcpp/
* include/cpplib.h (struct cpp_options): Implement C++23
P2295R6 - Support for UTF-8 as a portable source file encoding.
Add cpp_warn_invalid_utf8 and cpp_input_charset_explicit fields.
(enum cpp_warning_reason): Add CPP_W_INVALID_UTF8 enumerator.
* init.cc (cpp_create_reader): Initialize cpp_warn_invalid_utf8
and cpp_input_charset_explicit.
* charset.cc (_cpp_valid_utf8): Adjust function comment.
* lex.cc (UCS_LIMIT): Define.
(utf8_continuation): New const variable.
(utf8_signifier): Move earlier in the file.
(_cpp_warn_invalid_utf8, _cpp_handle_multibyte_utf8): New functions.
(_cpp_skip_block_comment): Handle -Winvalid-utf8 warning.
(skip_line_comment): Likewise.
(lex_raw_string, lex_string): Likewise.
(_cpp_lex_direct): Likewise.
gcc/
* doc/invoke.texi (-Winvalid-utf8): Document it.
gcc/c-family/
* c.opt (-Winvalid-utf8): New warning.
* c-opts.c (c_common_handle_option) :
Set cpp_opts->cpp_input_charset_explicit.
(c_common_post_options): If -finput-charset=UTF-8 is explicit
in C++23, enable -Winvalid-utf8 by default and if -pedantic
or -pedantic-errors, make it a pedwarn.
gcc/testsuite/
* c-c++-common/cpp/Winvalid-utf8-1.c: New test.
* c-c++-common/cpp/Winvalid-utf8-2.c: New test.
* c-c++-common/cpp/Winvalid-utf8-3.c: New test.
* g++.dg/cpp23/Winvalid-utf8-1.C: New test.
* g++.dg/cpp23/Winvalid-utf8-2.C: New test.
* g++.dg/cpp23/Winvalid-utf8-3.C: New test.
* g++.dg/cpp23/Winvalid-utf8-4.C: New test.
* g++.dg/cpp23/Winvalid-utf8-5.C: New test.
* g++.dg/cpp23/Winvalid-utf8-6.C: New test.
* g++.dg/cpp23/Winvalid-utf8-7.C: New test.
* g++.dg/cpp23/Winvalid-utf8-8.C: New test.
* g++.dg/cpp23/Winvalid-utf8-9.C: New test.
* g++.dg/cpp23/Winvalid-utf8-10.C: New test.
* g++.dg/cpp23/Winvalid-utf8-11.C: New test.
* g++.dg/cpp23/Winvalid-utf8-12.C: New test.

--- libcpp/include/cpplib.h.jj  2022-08-31 10:19:45.226452609 +0200
+++ libcpp/include/cpplib.h 2022-08-31 12:25:42.451125755 +0200
@@ -560,6 +560,13 @@ struct cpp_options
  cpp_bidirectional_level.  */
   unsigned char cpp_warn_bidirectional;

+  /* True if libcpp should warn about invalid UTF-8 characters in comments.
+ 2 if it should be a pedwarn.  */
+  unsigned char cpp_warn_invalid_utf8;
+
+  /* True if -finput-charset= option has been used explicitly.  */
+  bool cpp_input_charset_explicit;
+
   /* Dependency generation.  */
   struct
   {
@@ -666,7 +673,8 @@ enum cpp_warning_reason {
   CPP_W_CXX11_COMPAT,
   CPP_W_CXX20_COMPAT,
   CPP_W_EXPANSION_TO_DEFINED,
-  CPP_W_BIDIRECTIONAL
+  CPP_W_BIDIRECTIONAL,
+  CPP_W_INVALID_UTF8
 };

 /* Callback for header lookup for HEADER, which is the name of a
--- libcpp/init.cc.jj   2022-08-31 10:19:45.260452148 +0200
+++ libcpp/init.cc  2022-08-31 12:25:42.451125755 +0200
@@ -227,6 +227,8 @@ cpp_create_reader (enum c_lang lang, cpp
   CPP_OPTION (pfile, ext_numeric_literals) = 1;
   CPP_OPTION (pfile, warn_date_time) = 0;
   CPP_OPTION (pfile, cpp_warn_bidirectional) = bidirectional_unpaired;
+  CPP_OPTION (pfile, cpp_warn_invalid_utf8) = 0;
+  CPP_OPTION (pfile, cpp_input_charset_explicit) = 0;

   /* Default CPP arithmetic to something sensible for the host for the
  benefit of dumb users like fix-header.  */
--- libcpp/charset.cc.jj2022-08-26 16:06:10.578493272 +0200
+++ libcpp/charset.cc   2022-08-31 12:34:18.921176118 +0200
@@ -1742,9 +1742,9 @@ convert_ucn (cpp_reader *pfile, const uc
 case, n

Re: [PATCH] c++, v2: Implement C++23 P2071R2 - Named universal character escapes [PR106648]


On 8/30/22 17:37, Jakub Jelinek wrote:

On Tue, Aug 30, 2022 at 11:18:20PM +0200, Jakub Jelinek via Gcc-patches wrote:

On Tue, Aug 30, 2022 at 09:10:37PM +, Joseph Myers wrote:

I'm seeing build failures of glibc for powerpc64, as illustrated by the
following C code:

#if 0
\NARG
#endif

(the actual sysdeps/powerpc/powerpc64/sysdep.h code is inside #ifdef
__ASSEMBLER__).

This shows some problems with this feature - and with delimited escape
sequences - as it affects C.  It's fine to accept it as an extension
inside string and character literals, because \N or \u{...} would be
invalid in the absence of the feature (i.e. the syntax for such literals
fails to match, meaning that the rule about undefined behavior for a
single ' or " as a pp-token applies).  But outside string and character
literals, the usual lexing rules apply, the \ is a pp-token on its own and
the code is valid at the preprocessing level, and with expansion of macros
appearing before or after the \ (e.g. u defined as a macro in the \u{...}
case) it may be valid code at the language level as well.  I don't know
what older C++ versions say about this, but for C this means e.g.

#define z(x) 0
#define a z(
int x = a\NARG);

needs to be accepted as expanding to "int x = 0;", not interpreted as
using the \N feature in an identifier and produce an error.


Thanks, will look at it tomorrow.


If
#define z(x) 0
#define a z(
int x = a\NARG);
is valid in C and C++ <= 20 then
#define z(x) 0
#define a z(
int x = a\N{LATIN SMALL LETTER A WITH ACUTE});
is too and shall preprocess to int x = 0; too.
Which would likely mean that we want to only handle it in identifiers if
in C++23 and not actually treat it as an extension except in literals.

Jason, your thoughts about that?


The problem in glibc is with \N that is not followed by {; it certainly 
seems that we need to not treat that as an ill-formed named universal 
char escape outside of a literal.  I think for an actual \N{...} 
sequence, we should treat it as an extension unless in strict 
conformance mode, kind of like we do with the ext_numeric_numerals flag.


Jason

Re: [PATCH] Fortran: Add IEEE_SIGNBIT and IEEE_FMA functions

2022-08-31 Thread FX via Gcc-patches

Hum, slightly amended patch, after checking 32-bit results on another linux 
machine.
The test for FMA has been made a bit less strict, because otherwise we have 
surprised on 387 arithmetic due to excess precision.

Final patch is attached. Regression-tested on x86_64-pc-linux-gnu, both 32- and 
64-bit.
OK to commit?

FX



0001-fortran-Add-IEEE_SIGNBIT-and-IEEE_FMA-functions.patch
Description: Binary data

Re: [PATCH] libcpp, v4: Add -Winvalid-utf8 warning [PR106655]


On 8/31/22 10:15, Jakub Jelinek wrote:

On Wed, Aug 31, 2022 at 09:55:29AM -0400, Jason Merrill wrote:

On 8/31/22 07:14, Jakub Jelinek wrote:

On Tue, Aug 30, 2022 at 05:51:26PM -0400, Jason Merrill wrote:

This hunk now seems worth factoring out of the four places it occurs.

It also seems the comment for _cpp_valid_utf8 needs to be updated: it
currently says it's not called when parsing a string.


Ok, so like this?


OK, thanks.


Actually, it isn't enough to diagnose this in comments and character/string
literals, sorry for finding that out only today.

We don't accept invalid UTF-8 in identifiers, it fails the checking in there
(most of the times without errors), what we do is create CPP_OTHER tokens
out of those and then typically diagnose it when it is used somewhere.
Except it doesn't have to be used anywhere, it can be omitted.

So if we have say
#define I(x)
I(���)
like in the Winvalid-utf8-3.c test, we silently accept it.

This updated version extends the diagnostics even to those cases.
I can't use _cpp_handle_multibyte_utf8 in that case because it needs
different treatment (no bidi stuff which is emitted already from
forms_identifier_p etc.).

Tested so far on the new tests, ok for trunk if it passes full
bootstrap/regtest?


OK.


2022-08-31  Jakub Jelinek  

PR c++/106655
libcpp/
* include/cpplib.h (struct cpp_options): Implement C++23
P2295R6 - Support for UTF-8 as a portable source file encoding.
Add cpp_warn_invalid_utf8 and cpp_input_charset_explicit fields.
(enum cpp_warning_reason): Add CPP_W_INVALID_UTF8 enumerator.
* init.cc (cpp_create_reader): Initialize cpp_warn_invalid_utf8
and cpp_input_charset_explicit.
* charset.cc (_cpp_valid_utf8): Adjust function comment.
* lex.cc (UCS_LIMIT): Define.
(utf8_continuation): New const variable.
(utf8_signifier): Move earlier in the file.
(_cpp_warn_invalid_utf8, _cpp_handle_multibyte_utf8): New functions.
(_cpp_skip_block_comment): Handle -Winvalid-utf8 warning.
(skip_line_comment): Likewise.
(lex_raw_string, lex_string): Likewise.
(_cpp_lex_direct): Likewise.
gcc/
* doc/invoke.texi (-Winvalid-utf8): Document it.
gcc/c-family/
* c.opt (-Winvalid-utf8): New warning.
* c-opts.c (c_common_handle_option) :
Set cpp_opts->cpp_input_charset_explicit.
(c_common_post_options): If -finput-charset=UTF-8 is explicit
in C++23, enable -Winvalid-utf8 by default and if -pedantic
or -pedantic-errors, make it a pedwarn.
gcc/testsuite/
* c-c++-common/cpp/Winvalid-utf8-1.c: New test.
* c-c++-common/cpp/Winvalid-utf8-2.c: New test.
* c-c++-common/cpp/Winvalid-utf8-3.c: New test.
* g++.dg/cpp23/Winvalid-utf8-1.C: New test.
* g++.dg/cpp23/Winvalid-utf8-2.C: New test.
* g++.dg/cpp23/Winvalid-utf8-3.C: New test.
* g++.dg/cpp23/Winvalid-utf8-4.C: New test.
* g++.dg/cpp23/Winvalid-utf8-5.C: New test.
* g++.dg/cpp23/Winvalid-utf8-6.C: New test.
* g++.dg/cpp23/Winvalid-utf8-7.C: New test.
* g++.dg/cpp23/Winvalid-utf8-8.C: New test.
* g++.dg/cpp23/Winvalid-utf8-9.C: New test.
* g++.dg/cpp23/Winvalid-utf8-10.C: New test.
* g++.dg/cpp23/Winvalid-utf8-11.C: New test.
* g++.dg/cpp23/Winvalid-utf8-12.C: New test.

--- libcpp/include/cpplib.h.jj  2022-08-31 10:19:45.226452609 +0200
+++ libcpp/include/cpplib.h 2022-08-31 12:25:42.451125755 +0200
@@ -560,6 +560,13 @@ struct cpp_options
   cpp_bidirectional_level.  */
unsigned char cpp_warn_bidirectional;
  
+  /* True if libcpp should warn about invalid UTF-8 characters in comments.

+ 2 if it should be a pedwarn.  */
+  unsigned char cpp_warn_invalid_utf8;
+
+  /* True if -finput-charset= option has been used explicitly.  */
+  bool cpp_input_charset_explicit;
+
/* Dependency generation.  */
struct
{
@@ -666,7 +673,8 @@ enum cpp_warning_reason {
CPP_W_CXX11_COMPAT,
CPP_W_CXX20_COMPAT,
CPP_W_EXPANSION_TO_DEFINED,
-  CPP_W_BIDIRECTIONAL
+  CPP_W_BIDIRECTIONAL,
+  CPP_W_INVALID_UTF8
  };
  
  /* Callback for header lookup for HEADER, which is the name of a

--- libcpp/init.cc.jj   2022-08-31 10:19:45.260452148 +0200
+++ libcpp/init.cc  2022-08-31 12:25:42.451125755 +0200
@@ -227,6 +227,8 @@ cpp_create_reader (enum c_lang lang, cpp
CPP_OPTION (pfile, ext_numeric_literals) = 1;
CPP_OPTION (pfile, warn_date_time) = 0;
CPP_OPTION (pfile, cpp_warn_bidirectional) = bidirectional_unpaired;
+  CPP_OPTION (pfile, cpp_warn_invalid_utf8) = 0;
+  CPP_OPTION (pfile, cpp_input_charset_explicit) = 0;
  
/* Default CPP arithmetic to something sensible for the host for the

   benefit of dumb users like fix-header.  */
--- libcpp/charset.cc.jj2022-08-26 16:06:10.578493272 +0200
+++ libcpp/charset.cc   2022-08-31 12:34:18.921176118 +0200
@@ -1742,9 +1742,9 @@ convert_ucn (cpp_rea

[PATCH] Avoid fatal fails in predicate::init_from_control_deps

When processing USE predicates we can drop from the AND chain,
when procsssing DEF predicates we can drop from the OR chain.  Do
that instead of giving up completely.  This also removes cases
that should never trigger.

Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.

* gimple-predicate-analysis.cc (predicate::init_from_control_deps):
Assert the guard_bb isn't empty and has more than one successor.
Drop appropriate parts of the predicate when an edge fails to
register a predicate.
(predicate::dump): Dump empty predicate as TRUE.
---
 gcc/gimple-predicate-analysis.cc | 119 ++-
 1 file changed, 55 insertions(+), 64 deletions(-)

diff --git a/gcc/gimple-predicate-analysis.cc b/gcc/gimple-predicate-analysis.cc
index 58eade433dc..eb1e11cead8 100644
--- a/gcc/gimple-predicate-analysis.cc
+++ b/gcc/gimple-predicate-analysis.cc
@@ -1671,7 +1671,6 @@ predicate::init_from_control_deps (const vec 
*dep_chains,
 {
   gcc_assert (is_empty ());
 
-  bool has_valid_pred = false;
   if (num_chains == 0)
 return;
 
@@ -1689,27 +1688,16 @@ predicate::init_from_control_deps (const vec 
*dep_chains,
 of the predicates.  */
   const vec &path = dep_chains[i];
 
-  has_valid_pred = false;
+  bool has_valid_pred = false;
   /* The chain of predicates guarding the definition along this path.  */
   pred_chain t_chain{ };
   for (unsigned j = 0; j < path.length (); j++)
{
  edge e = path[j];
  basic_block guard_bb = e->src;
- /* Ignore empty forwarder blocks.  */
- if (empty_block_p (guard_bb) && single_succ_p (guard_bb))
-   continue;
 
- /* An empty basic block here is likely a PHI, and is not one
-of the cases we handle below.  */
- gimple_stmt_iterator gsi = gsi_last_bb (guard_bb);
- if (gsi_end_p (gsi))
-   {
- has_valid_pred = false;
- break;
-   }
- /* Get the conditional controlling the bb exit edge.  */
- gimple *cond_stmt = gsi_stmt (gsi);
+ gcc_assert (!empty_block_p (guard_bb) && !single_succ_p (guard_bb));
+
  /* Skip this edge if it is bypassing an abort - when the
 condition is not satisfied we are neither reaching the
 definition nor the use so it isn't meaningful.  Note if
@@ -1730,8 +1718,13 @@ predicate::init_from_control_deps (const vec 
*dep_chains,
}
}
  if (skip)
-   continue;
+   {
+ has_valid_pred = true;
+ continue;
+   }
}
+ /* Get the conditional controlling the bb exit edge.  */
+ gimple *cond_stmt = last_stmt (guard_bb);
  if (gimple_code (cond_stmt) == GIMPLE_COND)
{
  /* The true edge corresponds to the uninteresting condition.
@@ -1757,37 +1750,29 @@ predicate::init_from_control_deps (const vec 
*dep_chains,
}
  else if (gswitch *gs = dyn_cast (cond_stmt))
{
- /* Avoid quadratic behavior.  */
- if (gimple_switch_num_labels (gs) > MAX_SWITCH_CASES)
-   {
- has_valid_pred = false;
- break;
-   }
- /* Find the case label.  */
  tree l = NULL_TREE;
- unsigned idx;
- for (idx = 0; idx < gimple_switch_num_labels (gs); ++idx)
-   {
- tree tl = gimple_switch_label (gs, idx);
- if (e->dest == label_to_block (cfun, CASE_LABEL (tl)))
-   {
- if (!l)
-   l = tl;
- else
-   {
- l = NULL_TREE;
- break;
-   }
-   }
-   }
+ /* Find the case label, but avoid quadratic behavior.  */
+ if (gimple_switch_num_labels (gs) <= MAX_SWITCH_CASES)
+   for (unsigned idx = 0;
+idx < gimple_switch_num_labels (gs); ++idx)
+ {
+   tree tl = gimple_switch_label (gs, idx);
+   if (e->dest == label_to_block (cfun, CASE_LABEL (tl)))
+ {
+   if (!l)
+ l = tl;
+   else
+ {
+   l = NULL_TREE;
+   break;
+ }
+ }
+ }
  /* If more than one label reaches this block or the case
 label doesn't have a contiguous range of values (like the
 default one) fail.  */
  if (!l || !CASE_LOW (l))
-   {
- has_valid_pred = false;
- break;
-   }
+   has_valid_pred = f

Re: [PATCH] c++, v2: Implement C++23 P2071R2 - Named universal character escapes [PR106648]

On Tue, Aug 30, 2022 at 11:37:07PM +0200, Jakub Jelinek via Gcc-patches wrote:
> If
> #define z(x) 0
> #define a z(
> int x = a\NARG);
> is valid in C and C++ <= 20 then
> #define z(x) 0
> #define a z(
> int x = a\N{LATIN SMALL LETTER A WITH ACUTE});
> is too and shall preprocess to int x = 0; too.
> Which would likely mean that we want to only handle it in identifiers if
> in C++23 and not actually treat it as an extension except in literals.
> 
> Jason, your toughts about that?

Trying to read again the current C++23 wording, I'm afraid that outside of
the literals both the delimited escape sequences and named universal
characters are a complete nightmare for diagnostics.
Because the wording is that only valid universal character names are
replaced by their corresponding characters.
Ill-formed is only if the hexadecimal digit sequences are valid but
represent a number that is not a UCS scalar value, or represent a control
character.
So, I think we can't reject even
#define z(x) 0
#define a z(
int b = a\u{});
int c = a\u{);
int d = a\N{});
int e = a\N{);
int f = a\u123);
int g = a\U1234567);
int h = a\N{LATIN SMALL LETTER A WITH ACUT});
Couldn't C++23 say at least that if a valid named-universal-character
doesn't designate any character then the program is ill-formed?
So, we could reject the int h case above and accept silently the others?

GCC 12 accepts all these without warning, current trunk rejects the h
case with error and accepts the rest without a warning, clang trunk
emits warnings on all cases but the last and rejects the h case with
an error.

Jakub

Re: [PATCH 6/6] Extend SLP permutation optimisations





On 8/30/2022 8:50 AM, Richard Sandiford wrote:

Jeff Law via Gcc-patches  writes:

On 8/25/2022 7:07 AM, Richard Sandiford via Gcc-patches wrote:

Currently SLP tries to force permute operations "down" the graph
from loads in the hope of reducing the total number of permutations
needed or (in the best case) removing the need for the permutations
entirely.  This patch tries to extend it as follows:

- Allow loads to take a different permutation from the one they
started with, rather than choosing between "original permutation"
and "no permutation".

- Allow changes in both directions, if the target supports the
reverse permutation.

- Treat the placement of permutations as a two-way dataflow problem:
after propagating information from leaves to roots (as now), propagate
information back up the graph.

- Take execution frequency into account when optimising for speed,
so that (for example) permutations inside loops have a higher
cost than permutations outside loops.

- Try to reduce the total number of permutations when optimising for
size, even if that increases the number of permutations on a given
execution path.

See the big block comment above vect_optimize_slp_pass for
a detailed description.

The original motivation for doing this was to add a framework that would
allow other layout differences in future.  The two main ones are:

- Make it easier to represent predicated operations, including
predicated operations with gaps.  E.g.:

   a[0] += 1;
   a[1] += 1;
   a[3] += 1;

could be a single load/add/store for SVE.  We could handle this
by representing a layout such as { 0, 1, _, 2 } or { 0, 1, _, 3 }
(depending on what's being counted).  We might need to move
elements between lanes at various points, like with permutes.

(This would first mean adding support for stores with gaps.)

- Make it easier to switch between an even/odd and unpermuted layout
when switching between wide and narrow elements.  E.g. if a widening
operation produces an even vector and an odd vector, we should try
to keep operations on the wide elements in that order rather than
force them to be permuted back "in order".

Very cool.  Richi and I discussed this a bit a year or so ago --
basically noting that bi-directional movement is really the way to go
and that the worst thing to do is push a permute down into the *middle*
of a computation chain since that will tend to break FMA generation.
Moving to the loads or stores or to another permute point ought to be
the goal.

Hmm, I hadn't thought specifically about the case of permutes
ending up in the middle of a fusable operation.  The series doesn't
address that directly.  If we have:

   permute(a) * permute(b) + c

then the tendency will still be to convert that into:

   permute(a * b) + c

Damn.  Another case to think about ;-)

I've pushed the series for now though (thanks to Richi for the reviews).
There's a simple testcase attached to PR101895 which shows an example 
where (in the gcc-11 era) we pushed a permute down in a problematic 
way.   It might be worth taking a looksie, though I think we're avoiding 
the problem behavior via a workaround on the trunk right now.


Jeff

[pushed] aarch64: Update sizeless tests for recent GNU C changes

2022-08-31 Thread Richard Sandiford via Gcc-patches

The tests for sizeless SVE types include checks that the types
are handled for initialisation purposes in the same way as scalars.
GNU C and C2x now allow scalars to be initialised using empty braces,
so this patch updates the SVE tests to match.

Tested on aarch64-linux-gnu & pushed.

Richard


gcc/testsuite/
* gcc.target/aarch64/sve/acle/general-c/gnu_vectors_1.c: Update
tests for empty initializers.
* gcc.target/aarch64/sve/acle/general-c/gnu_vectors_2.c: Likewise.
* gcc.target/aarch64/sve/acle/general-c/sizeless-1.c: Likewise.
* gcc.target/aarch64/sve/acle/general-c/sizeless-2.c: Likewise.
---
 .../gcc.target/aarch64/sve/acle/general-c/gnu_vectors_1.c | 4 ++--
 .../gcc.target/aarch64/sve/acle/general-c/gnu_vectors_2.c | 4 ++--
 .../gcc.target/aarch64/sve/acle/general-c/sizeless-1.c| 4 ++--
 .../gcc.target/aarch64/sve/acle/general-c/sizeless-2.c| 4 ++--
 4 files changed, 8 insertions(+), 8 deletions(-)

diff --git 
a/gcc/testsuite/gcc.target/aarch64/sve/acle/general-c/gnu_vectors_1.c 
b/gcc/testsuite/gcc.target/aarch64/sve/acle/general-c/gnu_vectors_1.c
index 285751eebc4..9db9535831a 100644
--- a/gcc/testsuite/gcc.target/aarch64/sve/acle/general-c/gnu_vectors_1.c
+++ b/gcc/testsuite/gcc.target/aarch64/sve/acle/general-c/gnu_vectors_1.c
@@ -12,7 +12,7 @@ f (svuint8_t sve_u1, svint8_t sve_s1,
   /* Initialization.  */
 
   svuint8_t init_sve_u1 = 0; /* { dg-error {incompatible types when 
initializing type 'svuint8_t' using type 'int'} } */
-  svuint8_t init_sve_u2 = {}; /* { dg-error {empty scalar initializer} } */
+  svuint8_t init_sve_u2 = {};
   svuint8_t init_sve_u3 = { sve_u1 };
   svuint8_t init_sve_u4 = { gnu_u1 };
   svuint8_t init_sve_u5 = { sve_s1 }; /* { dg-error {incompatible types when 
initializing type 'svuint8_t' using type 'svint8_t'} } */
@@ -31,7 +31,7 @@ f (svuint8_t sve_u1, svint8_t sve_s1,
 
   /* Compound literals.  */
 
-  (svuint8_t) {}; /* { dg-error {empty scalar initializer} } */
+  (svuint8_t) {};
   (svuint8_t) { 0 }; /* { dg-error {incompatible types when initializing type 
'svuint8_t' using type 'int'} } */
   (svuint8_t) { sve_u1 };
   (svuint8_t) { gnu_u1 };
diff --git 
a/gcc/testsuite/gcc.target/aarch64/sve/acle/general-c/gnu_vectors_2.c 
b/gcc/testsuite/gcc.target/aarch64/sve/acle/general-c/gnu_vectors_2.c
index 306fd478047..c05b16406a4 100644
--- a/gcc/testsuite/gcc.target/aarch64/sve/acle/general-c/gnu_vectors_2.c
+++ b/gcc/testsuite/gcc.target/aarch64/sve/acle/general-c/gnu_vectors_2.c
@@ -12,7 +12,7 @@ f (svuint8_t sve_u1, svint8_t sve_s1,
   /* Initialization.  */
 
   svuint8_t init_sve_u1 = 0; /* { dg-error {incompatible types when 
initializing type 'svuint8_t' using type 'int'} } */
-  svuint8_t init_sve_u2 = {}; /* { dg-error {empty scalar initializer} } */
+  svuint8_t init_sve_u2 = {};
   svuint8_t init_sve_u3 = { sve_u1 };
   svuint8_t init_sve_u4 = { gnu_u1 };
   svuint8_t init_sve_u5 = { sve_s1 };
@@ -31,7 +31,7 @@ f (svuint8_t sve_u1, svint8_t sve_s1,
 
   /* Compound literals.  */
 
-  (svuint8_t) {}; /* { dg-error {empty scalar initializer} } */
+  (svuint8_t) {};
   (svuint8_t) { 0 }; /* { dg-error {incompatible types when initializing type 
'svuint8_t' using type 'int'} } */
   (svuint8_t) { sve_u1 };
   (svuint8_t) { gnu_u1 };
diff --git a/gcc/testsuite/gcc.target/aarch64/sve/acle/general-c/sizeless-1.c 
b/gcc/testsuite/gcc.target/aarch64/sve/acle/general-c/sizeless-1.c
index 7fc51e7ad18..4b34a71c1fe 100644
--- a/gcc/testsuite/gcc.target/aarch64/sve/acle/general-c/sizeless-1.c
+++ b/gcc/testsuite/gcc.target/aarch64/sve/acle/general-c/sizeless-1.c
@@ -66,14 +66,14 @@ statements (int n)
 
   svint8_t init_sve_sc1 = sve_sc1;
   svint8_t init_sve_sc2 = sve_sh1; /* { dg-error {incompatible types when 
initializing type 'svint8_t' using type 'svint16_t'} } */
-  svint8_t init_sve_sc3 = {}; /* { dg-error {empty scalar initializer} } */
+  svint8_t init_sve_sc3 = {};
 
   int initi_a = sve_sc1; /* { dg-error {incompatible types when initializing 
type 'int' using type 'svint8_t'} } */
   int initi_b = { sve_sc1 }; /* { dg-error {incompatible types when 
initializing type 'int' using type 'svint8_t'} } */
 
   /* Compound literals.  */
 
-  (svint8_t) {}; /* { dg-error {empty scalar initializer} } */
+  (svint8_t) {};
   (svint8_t) { sve_sc1 };
 
   (int) { sve_sc1 }; /* { dg-error {incompatible types when initializing type 
'int' using type 'svint8_t'} } */
diff --git a/gcc/testsuite/gcc.target/aarch64/sve/acle/general-c/sizeless-2.c 
b/gcc/testsuite/gcc.target/aarch64/sve/acle/general-c/sizeless-2.c
index c575492c1f8..34dfd598e32 100644
--- a/gcc/testsuite/gcc.target/aarch64/sve/acle/general-c/sizeless-2.c
+++ b/gcc/testsuite/gcc.target/aarch64/sve/acle/general-c/sizeless-2.c
@@ -66,14 +66,14 @@ statements (int n)
 
   svint8_t init_sve_sc1 = sve_sc1;
   svint8_t init_sve_sc2 = sve_sh1; /* { dg-error {incompatible types when 
initializing type 'svint8_t' using type 'svint16_t'} } */
-  svint8

Re: [PATCH] c++, v2: Implement C++23 P2071R2 - Named universal character escapes [PR106648]


On 8/31/22 10:35, Jakub Jelinek wrote:

On Tue, Aug 30, 2022 at 11:37:07PM +0200, Jakub Jelinek via Gcc-patches wrote:

If
#define z(x) 0
#define a z(
int x = a\NARG);
is valid in C and C++ <= 20 then
#define z(x) 0
#define a z(
int x = a\N{LATIN SMALL LETTER A WITH ACUTE});
is too and shall preprocess to int x = 0; too.
Which would likely mean that we want to only handle it in identifiers if
in C++23 and not actually treat it as an extension except in literals.

Jason, your toughts about that?


Trying to read again the current C++23 wording, I'm afraid that outside of
the literals both the delimited escape sequences and named universal
characters are a complete nightmare for diagnostics.
Because the wording is that only valid universal character names are
replaced by their corresponding characters.
Ill-formed is only if the hexadecimal digit sequences are valid but
represent a number that is not a UCS scalar value, or represent a control
character.
So, I think we can't reject even
#define z(x) 0
#define a z(
int b = a\u{});
int c = a\u{);
int d = a\N{});
int e = a\N{);
int f = a\u123);
int g = a\U1234567);
int h = a\N{LATIN SMALL LETTER A WITH ACUT});
Couldn't C++23 say at least that if a valid named-universal-character
doesn't designate any character then the program is ill-formed?


It could be more explicit, but I think we can assume that from the 
existing wording; it says it designates the named character.  If there 
is no such character, that cannot be satisfied, so it must be ill-formed.



So, we could reject the int h case above and accept silently the others?


Why not warn on the others?


GCC 12 accepts all these without warning, current trunk rejects the h
case with error and accepts the rest without a warning, clang trunk
emits warnings on all cases but the last and rejects the h case with
an error.

Jakub

Re: [PATCH] rs6000/test: Fix typo in pr86731-fwrapv-longlong.c [PR106682]

On 8/31/22 4:33 AM, Kewen.Lin via Gcc-patches wrote:
> Commit r12-2266 updated the scanned assembly content from
> 
>   "{\mlvx\M|\mlxv\M|\mlxvd2x\M}"
> 
> to
> 
>   "{\mp?lxv\M|\mlxv\M|\mlxvd2x\M}"
> 
> for the test case pr86731-fwrapv-longlong.c unexpectedly.
> 
> It's meant to update "lxv" to "p?lxv" and should leave the
> "lvx" unchanged.  So this is to fix the typo accordingly.

I agree.  Thanks for catching this!

Peter

Re: [PATCH 2/2] RISC-V: remove CM_PIC as it doesn't do much

2022-08-31 Thread Palmer Dabbelt


On Tue, 30 Aug 2022 10:48:30 PDT (-0700), Vineet Gupta wrote:

CM_PIC is no longer doing anything directly. Removing it might
potentially affect USE_LOAD_ADDRESS_MACRO() but seems unlikely.


At least in the short term, there's kind of a mess here that needs to 
get sorted out but just removing CM_PIC doesn't really get us there.



Signed-off-by: Vineet Gupta 
---
 gcc/config/riscv/riscv-c.cc   | 4 
 gcc/config/riscv/riscv-opts.h | 3 +--
 gcc/config/riscv/riscv.cc | 2 +-
 3 files changed, 2 insertions(+), 7 deletions(-)

diff --git a/gcc/config/riscv/riscv-c.cc b/gcc/config/riscv/riscv-c.cc
index bba72cf77a82..7064fcf142fe 100644
--- a/gcc/config/riscv/riscv-c.cc
+++ b/gcc/config/riscv/riscv-c.cc
@@ -92,13 +92,9 @@ riscv_cpu_cpp_builtins (cpp_reader *pfile)
   builtin_define ("__riscv_cmodel_medlow");
   break;

-case CM_PIC:
-  /* FALLTHROUGH. */
-
 case CM_MEDANY:
   builtin_define ("__riscv_cmodel_medany");
   break;
-
 }

   if (TARGET_MIN_VLEN != 0)
diff --git a/gcc/config/riscv/riscv-opts.h b/gcc/config/riscv/riscv-opts.h
index 85e869e62e3a..ce3237beca7a 100644
--- a/gcc/config/riscv/riscv-opts.h
+++ b/gcc/config/riscv/riscv-opts.h
@@ -34,8 +34,7 @@ extern enum riscv_abi_type riscv_abi;

 enum riscv_code_model {
   CM_MEDLOW,
-  CM_MEDANY,
-  CM_PIC
+  CM_MEDANY
 };
 extern enum riscv_code_model riscv_cmodel;

diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index 7c120eaa8e33..a239fe43047c 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -5162,7 +5162,7 @@ riscv_option_override (void)
   init_machine_status = &riscv_init_machine_status;

   if (flag_pic)
-riscv_cmodel = CM_PIC;
+riscv_cmodel = CM_MEDANY;

   /* We get better code with explicit relocs for CM_MEDLOW, but
  worse code for the others (for now).  Pick the best default.  */


I'm fine either way on this one: having CM_PIC gone makes it a bit more 
likely to confuse CM_MEDANY with PIC, but flag_pic is overriding 
riscv_cmodel anyway so this isn't really used and deleting code is 
always a plus.

Re: [PATCH 1/2] RISC-V: remove deprecate pic code model macro

2022-08-31 Thread Palmer Dabbelt


On Tue, 30 Aug 2022 10:48:29 PDT (-0700), Vineet Gupta wrote:

Came across this deprecated symbol when looking around for
-mexplicit-relocs handling in code

Signed-off-by: Vineet Gupta 
---
 gcc/config/riscv/riscv-c.cc | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/gcc/config/riscv/riscv-c.cc b/gcc/config/riscv/riscv-c.cc
index eb7ef09297e9..bba72cf77a82 100644
--- a/gcc/config/riscv/riscv-c.cc
+++ b/gcc/config/riscv/riscv-c.cc
@@ -93,9 +93,6 @@ riscv_cpu_cpp_builtins (cpp_reader *pfile)
   break;

 case CM_PIC:
-  /* __riscv_cmodel_pic is deprecated, and will removed in next GCC 
release.
-see https://github.com/riscv/riscv-c-api-doc/pull/11  */
-  builtin_define ("__riscv_cmodel_pic");
   /* FALLTHROUGH. */

 case CM_MEDANY:


It looks like some of the tests
(gcc/testsuite/gcc.target/riscv/predef-3.c, for example) are checking
for __riscv_cmodel_pic.  From looking at them I'd expect them to fail,
but even if they're not we should clean them up.

Re: [PATCH] c++, v2: Implement C++23 P2071R2 - Named universal character escapes [PR106648]

On Wed, Aug 31, 2022 at 10:52:49AM -0400, Jason Merrill wrote:
> It could be more explicit, but I think we can assume that from the existing
> wording; it says it designates the named character.  If there is no such
> character, that cannot be satisfied, so it must be ill-formed.

Ok.

> > So, we could reject the int h case above and accept silently the others?
> 
> Why not warn on the others?

We were always silent for the cases like \u123X or \U12345X.
Do you think we should emit some warnings (but never pedwarns/errors in that
case) that it is universal character name like but not completely?

The following patch let's us silently accept:
#define z(x) 0
#define a z(
int b = a\u{});
int c = a\u{);
int d = a\N{});
int e = a\N{);
int f = a\u123);
int g = a\U1234567);
int h = a\N);
int i = a\NARG);
int j = a\N{abc});
int k = a\N{ABC.123});

The following 2 will be still rejected with errors:
int l = a\N{ABC});
int m = a\N{LATIN SMALL LETTER A WITH ACUTE});
the first one because ABC is not valid Unicode name and the latter because
it will be int m = aá); and will trigger other errors later.

Given what you said above, I think that is what we want for the last 2
for C++23, the question is if it is ok also for C++20/C17 etc. and whether
it should depend on -pedantic or -pedantic-errors or GNU vs. ISO mode
or not in that case.  We could handle those 2 also differently, just
warn instead of error for the \N{ABC} case if not in C++23 mode when
identifier_pos.

--- libcpp/charset.cc.jj2022-08-31 12:34:18.921176118 +0200
+++ libcpp/charset.cc   2022-08-31 16:50:48.862775486 +0200
@@ -1463,7 +1463,14 @@ _cpp_valid_ucn (cpp_reader *pfile, const
 {
   length = 4;
   if (str == limit || *str != '{')
-   cpp_error (pfile, CPP_DL_ERROR, "'\\N' not followed by '{'");
+   {
+ if (identifier_pos)
+   {
+ *cp = 0;
+ return false;
+   }
+ cpp_error (pfile, CPP_DL_ERROR, "'\\N' not followed by '{'");
+   }
   else
{
  str++;
@@ -1489,7 +1496,7 @@ _cpp_valid_ucn (cpp_reader *pfile, const

  if (str < limit && *str == '}')
{
- if (name == str && identifier_pos)
+ if (identifier_pos && (name == str || !strict))
{
  *cp = 0;
  return false;

Jakub

Re: [PATCH] rs6000/test: Fix typo in pr86731-fwrapv-longlong.c [PR106682]

On Wed, Aug 31, 2022 at 05:33:21PM +0800, Kewen.Lin wrote:
> It's meant to update "lxv" to "p?lxv" and should leave the
> "lvx" unchanged.  So this is to fix the typo accordingly.
> 
> I'll push this soon if no objections.

Please go ahead.  Out of interest, did you see failures from this, was
it just by visual inspection,  something else?

Thanks,

Segher

Re: [PATCH] Add support for floating point endpoints to frange.





On 8/29/2022 7:54 AM, Jakub Jelinek via Gcc-patches wrote:

On Mon, Aug 29, 2022 at 03:45:33PM +0200, Aldy Hernandez wrote:

For convenience, singleton_p() returns false for a NAN.  IMO, it makes
the implementation cleaner, but I'm not wed to the idea if someone
objects.

If singleton_p() is used to decide whether one can just replace a variable
with singleton range with a constant, then certainly.
If MODE_HAS_SIGNED_ZEROS, zero has 2 representations (-0.0 and 0.0) and
NaNs have lots of different representations (the sign bit is ignored
except for stuff like copysign/signbit, there are qNaNs and sNaNs and
except for the single case how Inf is represented, all other values of the
mantissa mean different representations of NaN).  So, unless we track which
exact form of NaN can appear, NaN or any [x, x] range with NaN property
set can't be a singleton.  There could be programs that propagate something
important in NaN mantissa and would be upset if frange kills that.
Of course, one needs to take into account that when a FPU creates NaN, it
will create the canonical qNaN.
I've always thought of singleton_p as having that purpose -- but in the 
integer world we never really had to think about multiple 
representations of the same value.  So it's entirely possible we're 
using singleton_p for multiple purposes.


Clearly if the representation has multiple representations for the same 
value, then we have to be more careful with propagation.  So we may need 
to separate the concept of "this has a value we can propagate" from 
"this has a constant value, but the value may have multiple 
represenatations".


I don't think it's worth trying to track the various NaN 
representations, but I do think it's worth tracking +-Inf and +-0.0.


jeff

Re: [PATCH] Add support for floating point endpoints to frange.





On 8/29/2022 8:15 AM, Aldy Hernandez via Gcc-patches wrote:

On Mon, Aug 29, 2022 at 4:08 PM Toon Moene  wrote:

On 8/29/22 15:54, Jakub Jelinek via Gcc-patches wrote:


On Mon, Aug 29, 2022 at 03:45:33PM +0200, Aldy Hernandez wrote:

For convenience, singleton_p() returns false for a NAN.  IMO, it makes
the implementation cleaner, but I'm not wed to the idea if someone
objects.

If singleton_p() is used to decide whether one can just replace a variable
with singleton range with a constant, then certainly.
If MODE_HAS_SIGNED_ZEROS, zero has 2 representations (-0.0 and 0.0) and
NaNs have lots of different representations (the sign bit is ignored
except for stuff like copysign/signbit, there are qNaNs and sNaNs and
except for the single case how Inf is represented, all other values of the
mantissa mean different representations of NaN).  So, unless we track which
exact form of NaN can appear, NaN or any [x, x] range with NaN property
set can't be a singleton.  There could be programs that propagate something
important in NaN mantissa and would be upset if frange kills that.
Of course, one needs to take into account that when a FPU creates NaN, it
will create the canonical qNaN.

   Jakub


But the NaNs are irrelevant with -ffinite-math-only, as are the various
Infs (I do not know offhand which MODE_ that is) ...

But even with -ffinite-math-only, is there any benefit to propagating
a known NAN?  For example:
In theory, yes, but I don't know if it's worth the headache in practice 
for NaNs, particularly given they can have many representations.


Jeff

Re: [PATCH] Add support for floating point endpoints to frange.





On 8/29/2022 8:42 AM, Toon Moene wrote:

On 8/29/22 16:36, Aldy Hernandez wrote:


On Mon, Aug 29, 2022 at 4:30 PM Toon Moene  wrote:


On 8/29/22 16:15, Aldy Hernandez wrote:


But even with -ffinite-math-only, is there any benefit to propagating
a known NAN?  For example:


The original intent (in 2002) for the option -ffinite-math-only was for
the optimizers to ignore all the various exceptions to common
optimizations because they might not work correctly when presented with
a NaN or an Inf.

I do not know what the effect for floating point range information 
would

be - offhand.

But in the *spirit* of this option would be to ignore that the range
[5.0, 5.0] would "also" contain NaN, for instance.


Hmm, this is somewhat similar to what Jakub suggested.  Perhaps we
could categorically set !NAN for !HONOR_NANS at frange construction
time?

For reference:
bool
HONOR_NANS (machine_mode m)
{
   return MODE_HAS_NANS (m) && !flag_finite_math_only;
}

Thanks.
Aldy



Yep, I think that would do it.

Agreed.
Jeff

Re: [PATCH] Add support for floating point endpoints to frange.





On 8/29/2022 8:30 AM, Aldy Hernandez via Gcc-patches wrote:

On Mon, Aug 29, 2022 at 4:27 PM Jakub Jelinek  wrote:

On Mon, Aug 29, 2022 at 04:20:16PM +0200, Aldy Hernandez wrote:

Sure, I can add the HONOR_NANS, but can we even "see" a NAN in the IL
for -ffinite-math-only?

Sure, you can, e.g. __builtin_nan{,s}{,f,l} etc. would do it.
It would be UB to use it at runtime in -ffinite-math-only code though.
Another question is, when making a range VARYING, do you set the NAN
property or not when !HONOR_NANS && MODE_HAS_NANS?

A range of VARYING sets the NAN property to unknown
(fp_prop::VARYING).  If you prefer we can set the property to
fp_prop::NO for !HONOR_NANS && MODE_HAS_NANS.


If the format doesn't have NaNs or the user explicitly disables them, 
then the state should be NO, otherwise YES.


Jeff

Re: [PATCH] rs6000/test: Fix bswap64-4.c with has_arch_ppc64 [PR106680]

On Wed, Aug 31, 2022 at 05:33:28PM +0800, Kewen.Lin wrote:
> Test case bswap64-4.c suffers the issue as its comments:
> 
> /* On some versions of dejagnu this test will fail when
>biarch testing with RUNTESTFLAGS="--target_board=unix
>'{-m64,-m32}'" due to -m32 being added on the command
>line after the dg-options -mpowerpc64.
>common/config/rs6000/rs6000-common.c:
>rs6000_handle_option disables -mpowerpc64 for -m32.  */
> 
> As tested, on test machine with dejaGnu 1.6.2, the compilation
> option order looks like: -m32 ... -mpowerpc64, option
> -mpowerpc64 still takes effect;  While on test machine with
> dejaGnu 1.5.1, the option order looks like: -mpowerpc64 ... -m32,
> option -mpowerpc64 is disabled by -m32, then the case fails.

*Should* -mpowerpc64  be disabled by -m32?  Should *any* explicit
command line flag ever be disabled like that?  (Not talking about things
like -m32 -m64, this should be supported for convenience).

-mpowerpc64 -m32 should always mean the same as -m32 -mpowerpc64, that's
the principle of least surprise.

Where then dg-options is placed does not matter in this testcase, both
-m32 -mno-powerpc64 and -m32 -mpowerpc64 are ilp32.


Segher

Re: [PATCH] c++, v2: Implement C++23 P2071R2 - Named universal character escapes [PR106648]

On Wed, Aug 31, 2022 at 05:07:29PM +0200, Jakub Jelinek via Gcc-patches wrote:
> Given what you said above, I think that is what we want for the last 2
> for C++23, the question is if it is ok also for C++20/C17 etc. and whether
> it should depend on -pedantic or -pedantic-errors or GNU vs. ISO mode
> or not in that case.  We could handle those 2 also differently, just
> warn instead of error for the \N{ABC} case if not in C++23 mode when
> identifier_pos.

Here is an incremental version of the patch which will make valid
\u{123} and \N{LATIN SMALL LETTER A WITH ACUTE} an extension in GNU
modes before C++23 and split it as separate tokens in ISO modes.

Testcase:
#define z(x) 0
#define a z(
int b = a\u{123});
int c = a\N{LATIN SMALL LETTER A WITH ACUTE});

--- libcpp/charset.cc.jj2022-08-31 16:50:48.862775486 +0200
+++ libcpp/charset.cc   2022-08-31 17:18:59.649257350 +0200
@@ -1448,7 +1448,11 @@ _cpp_valid_ucn (cpp_reader *pfile, const
   if (str[-1] == 'u')
 {
   length = 4;
-  if (str < limit && *str == '{')
+  if (str < limit
+  && *str == '{'
+  && (!identifier_pos
+ || CPP_OPTION (pfile, delimited_escape_seqs)
+ || !CPP_OPTION (pfile, std)))
{
  str++;
  /* Magic value to indicate no digits seen.  */
@@ -1462,6 +1466,13 @@ _cpp_valid_ucn (cpp_reader *pfile, const
   else if (str[-1] == 'N')
 {
   length = 4;
+  if (identifier_pos
+ && !CPP_OPTION (pfile, delimited_escape_seqs)
+ && CPP_OPTION (pfile, std))
+   {
+ *cp = 0;
+ return false;
+   }
   if (str == limit || *str != '{')
{
  if (identifier_pos)

Jakub

Re: [PATCH v2] Support --disable-fixincludes.

2022-08-31 Thread Alexandre Oliva via Gcc-patches

On Aug 31, 2022, Xi Ruoyao  wrote:

> On Sat, 2022-07-09 at 10:11 -0600, Jeff Law via Gcc-patches wrote:
>> Once Alex is OK with this patch, then it'll be good to go.
>> 
>> jeff

> Gentle ping as a distro maintainer :).

Oops, thanks, sorry, I seem to have missed it the first time around.

The patch looks good to me, thanks Martin,

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

Re: [PATCH 1/2] RISC-V: remove deprecate pic code model macro

2022-08-31 Thread Kito Cheng via Gcc-patches

Could you also clean up all __riscv_cmodel_pic checking in
gcc/testsuite/gcc.target/riscv/predef-*.c?

On Wed, Aug 31, 2022 at 10:58 PM Palmer Dabbelt  wrote:
>
> On Tue, 30 Aug 2022 10:48:29 PDT (-0700), Vineet Gupta wrote:
> > Came across this deprecated symbol when looking around for
> > -mexplicit-relocs handling in code
> >
> > Signed-off-by: Vineet Gupta 
> > ---
> >  gcc/config/riscv/riscv-c.cc | 3 ---
> >  1 file changed, 3 deletions(-)
> >
> > diff --git a/gcc/config/riscv/riscv-c.cc b/gcc/config/riscv/riscv-c.cc
> > index eb7ef09297e9..bba72cf77a82 100644
> > --- a/gcc/config/riscv/riscv-c.cc
> > +++ b/gcc/config/riscv/riscv-c.cc
> > @@ -93,9 +93,6 @@ riscv_cpu_cpp_builtins (cpp_reader *pfile)
> >break;
> >
> >  case CM_PIC:
> > -  /* __riscv_cmodel_pic is deprecated, and will removed in next GCC 
> > release.
> > -  see https://github.com/riscv/riscv-c-api-doc/pull/11  */
> > -  builtin_define ("__riscv_cmodel_pic");
> >/* FALLTHROUGH. */
> >
> >  case CM_MEDANY:
>
> It looks like some of the tests
> (gcc/testsuite/gcc.target/riscv/predef-3.c, for example) are checking
> for __riscv_cmodel_pic.  From looking at them I'd expect them to fail,
> but even if they're not we should clean them up.

Re: [PATCH][V3] 32-bit PA-RISC with HP-UX: remove deprecated ports





On 8/31/2022 1:21 AM, Martin Liška wrote:

Sending v3 of the patch that includes John's comments.

Ready to be installed?
Thanks,
Martin

ChangeLog:

* configure: Regenerate.
* configure.ac: Delete hpux9 and hpux10.

config/ChangeLog:

* mh-pa-hpux10: Removed.

contrib/ChangeLog:

* config-list.mk: Remove deprecated ports.

contrib/header-tools/ChangeLog:

* README: Remove deprecated ports.
* reduce-headers: Likewise.

gcc/ChangeLog:

* config.build: Remove deprecated ports.
* config.gcc: Likewise.
* config.host: Likewise.
* configure.ac: Likewise.
* configure: Regenerate.
* config/pa/pa-hpux10.h: Removed.
* config/pa/pa-hpux10.opt: Removed.
* config/pa/t-dce-thr: Removed.

gnattools/ChangeLog:

* configure.ac: Remove deprecated ports.
* configure: Regenerate.

libstdc++-v3/ChangeLog:

* configure: Regenerate.
* crossconfig.m4: Remove deprecated ports.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/lambda/lambda-conv.C: Remove useless test.
* gcc.c-torture/execute/ieee/hugeval.x: Likewise.
* gcc.dg/torture/pr47917.c: Likewise.
* lib/target-supports.exp: Likewise.

libgcc/ChangeLog:

* config.host: Remove hppa.

libitm/ChangeLog:

* configure: Regenerate.

fixincludes/ChangeLog:

* configure: Regenerate.

OK

It looks like you removed the pa-bsd and pa-osf targets too.  Those were 
so niche that I doubt anyone else would notice.




jeff

Re: [PATCH] sched1: Fix -fcompare-debug issue in schedule_region [PR105586]





On 8/23/2022 5:49 AM, Surya Kumari Jangala via Gcc-patches wrote:

sched1: Fix -fcompare-debug issue in schedule_region [PR105586]

In schedule_region(), a basic block that does not contain any real insns
is not scheduled and the dfa state at the entry of the bb is not copied
to the fallthru basic block. However a DEBUG insn is treated as a real
insn, and if a bb contains non-real insns and a DEBUG insn, it's dfa
state is copied to the fallthru bb. This was resulting in
-fcompare-debug failure as the incoming dfa state of the fallthru block
is different with -g. We should always copy the dfa state of a bb to
it's fallthru bb even if the bb does not contain real insns.

2022-08-22  Surya Kumari Jangala  

gcc/
PR rtl-optimization/105586
* sched-rgn.cc (schedule_region): Always copy dfa state to
fallthru block.

gcc/testsuite/
PR rtl-optimization/105586
* gcc.target/powerpc/pr105586.c: New test.
Interesting.    We may have stumbled over this bug internally a little 
while ago -- not from a compare-debug standpoint, but from a "why isn't 
the processor state copied to the fallthru block" point of view.   I had 
it on my to investigate list, but hadn't gotten around to it yet.


I think there were requests for ChangeLog updates and a function comment 
for save_state_for_fallthru_edge.  OK with those updates.


jeff

Re: [PATCH] nvptx: Silence unused variable warning





On 8/28/2022 5:09 AM, Jan-Benedict Glaw wrote:

Hi!

The nvptx backend defines ASM_OUTPUT_DEF along with
ASM_OUTPUT_DEF_FROM_DECLS.  Much like the rs6000 coff target, nvptx
triggers an unused variable warning:

/usr/lib/gcc-snapshot/bin/g++  -fno-PIE -c   -g -O2   -DIN_GCC  
-DCROSS_DIRECTORY_STRUCTURE   -fno-exceptions -fno-rtti 
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings 
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic 
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common 
 -DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. 
-I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include 
-I../../gcc/gcc/../libcody  -I../../gcc/gcc/../libdecnumber 
-I../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber 
-I../../gcc/gcc/../libbacktrace   -o varasm.o -MT varasm.o -MMD -MP -MF 
./.deps/varasm.TPo ../../gcc/gcc/varasm.cc
../../gcc/gcc/varasm.cc: In function 'void 
output_constant_pool_contents(rtx_constant_pool*)':
../../gcc/gcc/varasm.cc:4318:21: error: unused variable 'name' 
[-Werror=unused-variable]
  4318 | const char *name = XSTR (desc->sym, 0);
   | ^~~~
cc1plus: all warnings being treated as errors
make[1]: *** [Makefile:1145: varasm.o] Error 1


Fixed the same way:

diff --git a/gcc/config/nvptx/nvptx.h b/gcc/config/nvptx/nvptx.h
index ed72c253191..71297440566 100644
--- a/gcc/config/nvptx/nvptx.h
+++ b/gcc/config/nvptx/nvptx.h
@@ -321,6 +321,9 @@ struct GTY(()) machine_function
  #define ASM_OUTPUT_DEF(FILE,LABEL1,LABEL2)\
do  \
  { \
+  (void) (FILE);   \
+  (void) (LABEL1); \
+  (void) (LABEL2); \
gcc_unreachable (); \
  } \
while (0)


Ok for HEAD?

OK with a ChangeLog entry.

jeff

Re: [PATCH] rs6000/test: Fix bswap64-4.c with has_arch_ppc64 [PR106680]

On 8/31/22 10:24 AM, Segher Boessenkool wrote:
> Should *any* explicit command line flag ever be disabled like that?
> (Not talking about things like -m32 -m64, ...

In a general sense, I'd agree that the answer is no, but we do have
dependent options like -maltivec and -mvsx, etc., so a -mno-altivec
better disable any explicit -mvsx earlier on the command line.
Ditto for -msoft-float better disable any -maltivec and -mvsx, etc.
It's complicated...and that's a bad thing. :-(

> -mpowerpc64 -m32 should always mean the same as -m32 -mpowerpc64, that's
> the principle of least surprise.

I think I agree with this, since -mpowerpc64 doesn't mean or imply -m64.
I say "think", because I don't remember the history of why it behaves this
way and maybe there was a reason we did like this?  If there isn't a reason,
then I'm all for -m32 not overriding -mpowerpc64.

Peter

Re: [committed] Fix more problems with new linker warnings

On 8/22/2022 3:39 AM, Martin Liška wrote:

On 4/28/22 18:10, Jeff Law via Gcc-patches wrote:

As I mentioned in the original thread, my change to pr94157_0 was an attempt to
avoid these warnings by passing a magic flag to the linker. Of course we may
not be using GNU ld. Or we may be on a non-elf target where the flag I used
doesn't exist. Or we may even be on a ELF target where those bits weren't
added to the linker (frv). Furthermore, we need fixes to all the nested
function tests as well.

So even though I initially resisted pruning the warning, that seems like the
best course of action. So this patch removes my recent change to pr94157_0 and
instead uses our pruning facilities.

I'll be pushing this to the trunk and gcc-12 branch.

Jeff

Hello.

I noticed this patch during my GCC test-suite run with mold linker. As you
likely now, the linker defaults
to non-executable stack and so one sees test-suite crashes (not only warnings)
[1].

So the question is if we want to explicitly fix all tests that rely on
exectack? Or is it something
we can assume as it's what GNU linkers do?

List of affected tests:
https://gist.githubusercontent.com/marxin/aadb75408a5a7867bf9fb26e879ce4c4/raw/aff2a0e4559e2dba8ea358520ca836eda6e7dc70/gistfile1.txt
The problem I ran into was that there wasn't a good way to determine
what to do, even if we know the test was going to need execstack. We
can't just blindly pass the magic flag to the linker -- at the least
that would need to be conditional on the linker being used as well as
the target as some of the ELF targets don't have the linker
infrastructure. And given that the linker can vary across gnu-ld, gold,
mold, it's a rats nest.

jeff

Re: [PATCH] regenerate configure files and config.h.in files





On 8/25/2022 3:42 AM, Martin Liška wrote:

Hi.

I wrote a scipt that runs autoconf in all folders that have configure.ac
file and same for autoheader (where AC_CONFIG_HEADERS is present) and
this is the output.

The script can be seen here:
https://github.com/marxin/script-misc/blob/master/gcc-autoconf-all.py

I'm going to add the script to my daily Builbot tester.

Patch can bootstrap on x86_64-linux-gnu and survives regression tests.

Ready to be installed?
Thanks,
Martin

fixincludes/ChangeLog:

* config.h.in: Regenerate.
* configure: Regenerate.

libada/ChangeLog:

* configure: Regenerate.

libiberty/ChangeLog:

* configure: Regenerate.

libobjc/ChangeLog:

* configure: Regenerate.

liboffloadmic/ChangeLog:

* configure: Regenerate.
* plugin/configure: Regenerate.

libquadmath/ChangeLog:

* configure: Regenerate.

libssp/ChangeLog:

* configure: Regenerate.

libvtv/ChangeLog:

* configure: Regenerate.

zlib/ChangeLog:

* configure: Regenerate.
OK.  And ISTM that regeneration using the standard tools ought to be 
pre-approved for the future.

jeff

Re: [PATCH] rs6000: Don't ICE when we disassemble an MMA variable [PR101322]

Hi!

On Fri, Aug 26, 2022 at 10:50:00PM -0500, Peter Bergner wrote:
> When we expand an MMA disassemble built-in with C++ using a pointer that
> is casted to a valid MMA type, the type isn't passed down to the expand

(The perfect tense of cast is "cast").

> machinery and we end up using the base type of the pointer which leads to
> an ICE.  This patch enforces we always use the correct MMA type regardless
> of the pointer type being used.

> --- /dev/null
> +++ b/gcc/testsuite/g++.target/powerpc/pr101322.C
> @@ -0,0 +1,17 @@
> +/* PR target/101322 */
> +/* { dg-options "-O2 -mdejagnu-cpu=power10" } */
> +/* { dg-require-effective-target power10_ok } */

These should be the other way around.  It makes no sense to set option X
before testing if you can set option X.  Even if it would technically
work, the primary consumer of any source code is the humans who read it,
and humans read code top down.

Segher

Re: [PATCH] Support bitmap_copy across representations





On 8/17/2022 5:11 AM, Richard Biener via Gcc-patches wrote:

The following started as making the backward threader m_imports
use the tree representation.  Since that interfaces to a list
representation bitmap in ranger by copying rewriting the tree
to list to perform the copy is inefficient in that it loses
balancing.  The following adds bitmap_copy_tree_to_list and
integrates it with the generic bitmap_copy routine.  For symmetry
I also added list to tree copy, relying on auto-balancing, and
tree to tree copy which I didn't optimize to preserve the
source balancing but instead use bitmap_copy_tree_to_list and
have the result auto-balanced again.

I've only exercised the tree to list path and I won't actually
end up using it but it's at least worth posting.

Bootstrapped and tested on x86_64-unknown-linux-gnu.

Worth pushing?

* bitmap.h: Document set_copy aka bitmap_copy as usable
for tree representation.
* bitmap.cc (bitmap_copy_tree_to_list): New helper.
(bitmap_copy): Support copying all bitmap representation
combinations.
I'd lean against unless you expect to be using it.   But it's not a 
strongly held opinion.


jeff

Re: [PATCH] Always default to DWARF2_DEBUG if not specified, warn about deprecated STABS





On 8/29/2022 2:11 PM, Jan-Benedict Glaw wrote:

Hi Jeff!

On Sun, 2022-08-28 15:32:53 -0600, Jeff Law via Gcc-patches 
 wrote:

On 8/28/2022 1:50 AM, Jan-Benedict Glaw wrote:

On Tue, 2021-09-21 16:25:19 +0200, Richard Biener via Gcc-patches 
 wrote:

This makes defaults.h choose DWARF2_DEBUG if PREFERRED_DEBUGGING_TYPE
is not specified by the target and errors out if DWARF DWARF is not supported.

While I think the pdp11 bits arreved, the rest did not (yet). Just
checked my auto-builder logs. When building current HEAD as

../gcc/configure --prefix=... --enable-werror-always \
--enable-languages=all --disable-gcov \
--disable-shared --disable-threads --without-headers \
--target=...
make V=1 all-gcc

ALL of these targets won't build right now:

[...]

Umm, most of those -elf targets do build.  See:

http://law-sandy.freeddns.org:8080

Another builder. :)  Randomly picking xtensa-elf, you're configuring
as

+ ../../gcc/configure --disable-analyzer --with-system-libunwind
--with-newlib --without-headers --disable-threads --disable-shared
--enable-languages=c,c++
--prefix=/home/jlaw/jenkins/workspace/xtensa-elf/xtensa-elf-obj/gcc/../../xtensa-elf-installed
--target=xtensa-elf

I guess the main difference that lets my builds fail might be
--enable-languages=all (vs. c,c++ in your case.)

Maybe you'd give that a try? (...and I'll trigger a build with just
c,c++ on my builder.)
I can, particularly now that the tester builds everything in a docker 
container -- it really didn't like having Ada tests (for example) 
appearing and disappearing based on whether or not the host had an Ada 
compiler installed.  I've also brought the computing resources in-house 
(literally, in my house), so I'm not worried about running out of Amazon 
credits anymore.


Jeff

Re: [PATCH] rs6000/test: Fix bswap64-4.c with has_arch_ppc64 [PR106680]

On Wed, Aug 31, 2022 at 10:48:26AM -0500, Peter Bergner wrote:
> On 8/31/22 10:24 AM, Segher Boessenkool wrote:
> > Should *any* explicit command line flag ever be disabled like that?
> > (Not talking about things like -m32 -m64, ...
> 
> In a general sense, I'd agree that the answer is no, but we do have
> dependent options like -maltivec and -mvsx, etc., so a -mno-altivec
> better disable any explicit -mvsx earlier on the command line.

Yes, but those two flags are tightly related.  -m32/-m64 and -mpowerpc64
are not, code model and instruction set selection are orthogonal.

> Ditto for -msoft-float better disable any -maltivec and -mvsx, etc.

Oh?  Why should it disable -maltivec?  -mvsx makes a little sense on
one hand, but totally none on the other either.

> It's complicated...and that's a bad thing. :-(

Yes.  And most of it is caused by us, instead of being a fact of life.

> > -mpowerpc64 -m32 should always mean the same as -m32 -mpowerpc64, that's
> > the principle of least surprise.
> 
> I think I agree with this, since -mpowerpc64 doesn't mean or imply -m64.
> I say "think", because I don't remember the history of why it behaves this
> way and maybe there was a reason we did like this?  If there isn't a reason,
> then I'm all for -m32 not overriding -mpowerpc64.

As far as I always knew it does *not* override it, so this seems like
an accident to me, not detected before  because everyone always types
-m32 -mpowerpc64 (I know I do, anyway).

I think we should just fix this and see what breaks, if anything?


Segher

Re: [PATCH] middle-end: Add MULT_EXPR recognition for cond scalar reduction





On 8/25/2022 3:39 AM, Kong, Lingling via Gcc-patches wrote:

Hi,

The conditional mult reduction cannot be recognized with current GCC. The 
following loop cannot be vectorized.
Now add MULT_EXPR recognition for conditional scalar reduction.

float summa(int n, float *arg1, float *arg2)
{
 int i;
 float res1 = 1.0;
 for(i = 0; i < n; i++) {
   if(arg2[i])
 res1 *= arg1[i];
 }
 return res1;
}

gcc/ChangeLog:

* tree-if-conv.cc (is_cond_scalar_reduction): Add MULT_EXPR
recognition.

gcc/testsuite/ChangeLog:

* gcc.dg/tree-ssa/gen-vect-34.c: New test.
* gcc.dg/vect/vect-ifcvt-18.c: New test.

OK
jeff

Re: [PATCH] c++, v2: Implement C++23 P2071R2 - Named universal character escapes [PR106648]


On 8/31/22 11:07, Jakub Jelinek wrote:

On Wed, Aug 31, 2022 at 10:52:49AM -0400, Jason Merrill wrote:

It could be more explicit, but I think we can assume that from the existing
wording; it says it designates the named character.  If there is no such
character, that cannot be satisfied, so it must be ill-formed.


Ok.


So, we could reject the int h case above and accept silently the others?


Why not warn on the others?


We were always silent for the cases like \u123X or \U12345X.
Do you think we should emit some warnings (but never pedwarns/errors in that
case) that it is universal character name like but not completely?


I think that would be helpful, at least for \u{ and \N{.


The following patch let's us silently accept:
#define z(x) 0
#define a z(
int b = a\u{});
int c = a\u{);
int d = a\N{});
int e = a\N{);
int f = a\u123);
int g = a\U1234567);
int h = a\N);
int i = a\NARG);
int j = a\N{abc});
int k = a\N{ABC.123});

The following 2 will be still rejected with errors:
int l = a\N{ABC});
int m = a\N{LATIN SMALL LETTER A WITH ACUTE});
the first one because ABC is not valid Unicode name and the latter because
it will be int m = aá); and will trigger other errors later.

Given what you said above, I think that is what we want for the last 2
for C++23, the question is if it is ok also for C++20/C17 etc. and whether
it should depend on -pedantic or -pedantic-errors or GNU vs. ISO mode
or not in that case.  We could handle those 2 also differently, just
warn instead of error for the \N{ABC} case if not in C++23 mode when
identifier_pos.


That sounds right.


Here is an incremental version of the patch which will make valid
\u{123} and \N{LATIN SMALL LETTER A WITH ACUTE} an extension in GNU
modes before C++23 and split it as separate tokens in ISO modes.


Looks good.

Jason

Re: [PATCH][V3] 32-bit PA-RISC with HP-UX: remove deprecated ports

2022-08-31 Thread John David Anglin


On 2022-08-31 11:35 a.m., Jeff Law wrote:

It looks like you removed the pa-bsd and pa-osf targets too.  Those were so 
niche that I doubt anyone else would notice.

That should be okay.  I have never heard of anyone building these. There is no 
config for these in config.gcc.

hppa*-*-openbsd* and hppa*-*-netbsd* are still somewhat used.

Dave

--
John David Anglin  dave.ang...@bell.net

Re: [PATCH] rs6000/test: Fix bswap64-4.c with has_arch_ppc64 [PR106680]

On 8/31/22 11:05 AM, Segher Boessenkool wrote:
> On Wed, Aug 31, 2022 at 10:48:26AM -0500, Peter Bergner wrote:
>> Ditto for -msoft-float better disable any -maltivec and -mvsx, etc.
> 
> Oh?  Why should it disable -maltivec?  -mvsx makes a little sense on
> one hand, but totally none on the other either.

VSX has to be disabled, since VSX replies on the FP registers existing.

As for Altivec, I'm pretty sure there are some inherent dependencies
there, probably both in hardware and our GCC backend implementation.
I could be wrong, but my guess is things will fall over the ground
if as allow -maltivec along with -msoft-float.  Does the linux kernel
only build with -msoft-float assuming it disables altivec and vsx?
Or does it explicitly always also add -mno-altivec?

> As far as I always knew it does *not* override it, so this seems like
> an accident to me, not detected before  because everyone always types
> -m32 -mpowerpc64 (I know I do, anyway).
> 
> I think we should just fix this and see what breaks, if anything?

So in linux*.h, we have the following which came from a 2004 commit from Alan:

linux64.h:#define OS_MISSING_POWERPC64 !TARGET_64BIT

...and in rs6000.cc:rs6000_option_override_internal(), the following hunk is
basically from:

+2003-12-18  Geoffrey Keating  
+
+   * config/rs6000/aix.h (OS_MISSING_POWERPC64): Define.
+   (OS_MISSING_ALTIVEC): Define.
+   * config/rs6000/darwin.h (ASM_SPEC): Be generous about supplying
+   -force_cpusubtype_ALL.
+   * config/rs6000/rs6000.c (rs6000_override_options): Rearrange
+   CPU information table; now always set all CPU-specific values.
+   Also, use Altivec and powerpc64 when chip and OS supports them.

  /* Some OSs don't support saving the high part of 64-bit registers on context
 switch.  Other OSs don't support saving Altivec registers.  On those OSs,
 we don't touch the OPTION_MASK_POWERPC64 or OPTION_MASK_ALTIVEC settings;
 if the user wants either, the user must explicitly specify them and we
 won't interfere with the user's specification.  */

  set_masks = POWERPC_MASKS;
#ifdef OS_MISSING_POWERPC64
  if (OS_MISSING_POWERPC64)
set_masks &= ~OPTION_MASK_POWERPC64;
#endif
#ifdef OS_MISSING_ALTIVEC
  if (OS_MISSING_ALTIVEC)
set_masks &= ~(OPTION_MASK_ALTIVEC | OPTION_MASK_VSX
   | OTHER_VSX_VECTOR_MASKS);
#endif

...so I think there was no real reason, other than old 64-bit linux kernels 
didn't
save the upper register state in 32-bit mode binaries.  I believe that was 
"fixed"
a long time ago, so I agree we should just "fix" it and see what happens.
In this case, I think the fix is probably just to change the linux64.h define
to be "0" rather than "!TARGET_64".

Peter

Re: [PATCH] d: Fix #error You must define PREFERRED_DEBUGGING_TYPE if DWARF is not supported (PR105659)

On Wed, 31 Aug 2022, Iain Buclaw via Gcc-patches wrote:

> Excerpts from Joseph Myers's message of August 30, 2022 11:53 pm:
> > On Fri, 26 Aug 2022, Richard Biener via Gcc-patches wrote:
> > 
> >> I was hoping Joseph would chime in here - I recollect debugging this kind
> >> of thing and a thread about this a while back but unfortunately I do not
> >> remember the details here (IIRC some things get included where they
> >> better should not be).
> > 
> > See .  
> > Is there some reason it's problematic to avoid having defaults.h or 
> > ${cpu_type}/${cpu_type}.h included in tm_d.h, and instead have tm_d.h only 
> > include D-specific headers?
> > 
> 
> In targets such as arm-elf, we still need to pull in definitions from
> ${cpu_type}/${cpu_type}-d.cc into default-d.cc.
> 
> All I can think that might suffice is having D-specific prototype
> headers in all targets as ${cpu_type}/${cpu_type}-d.h.

As long as those prototypes don't involve any types that depend on an 
inclusion of tm.h, that should be fine.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [[GCC13][Patch][V3] 1/2] Add a new option -fstrict-flex-array[=n] and new attribute strict_flex_array

On Wed, 31 Aug 2022, Qing Zhao via Gcc-patches wrote:

> > "a GNU extension" suggests a particular language feature, but I think 
> > you're actually referring here to a whole language version rather than an 
> > individual feature.
> 
> Is “not supported by GNU extension GNU89” better?

There are no existing diagnostics referring to GNU89 at all.  I don't 
think "GNU extension" needs to be mentioned in that diagnostic, but I also 
think that having that diagnostic at all is ill-conceived.

> > In any case, -std=gnu89 supports flexible array members.
> 
> Yes, but only [0],[1] are supported as flexible array members.  The C99 
> flexible array member [] is not supported by GNU89, right?

C99 flexible array members are fully supported in GNU89 mode.  In general, 
any feature from a new language version that doesn't affect code that was 
valid in previous versions is likely to be accepted as an extension with 
options for older language versions.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH][V3] 32-bit PA-RISC with HP-UX: remove deprecated ports





On 8/31/2022 10:40 AM, John David Anglin wrote:

On 2022-08-31 11:35 a.m., Jeff Law wrote:
It looks like you removed the pa-bsd and pa-osf targets too.  Those 
were so niche that I doubt anyone else would notice.
That should be okay.  I have never heard of anyone building these. 
There is no config for these in config.gcc.
Right.  Those were used almost exclusively by my former colleagues at 
the U of Utah and their industry partners.  All the relevant projects 
and machines have long since been retired.




hppa*-*-openbsd* and hppa*-*-netbsd* are still somewhat used.

Right.   I mentally lump these in with the -linux port.

Jeff

[PATCH] Fortran 2018 rounding modes changes

2022-08-31 Thread FX via Gcc-patches

This adds new F2018 features, that are not really enabled (because their 
runtime support is optional).

1. Add the new IEEE_AWAY rounding mode. It is unsupported on all known targets, 
but could be supported by glibc and AIX as part of the C2x proposal. Testing 
for now is minimal, but once a target supports that rounding mode, the tests 
will fail and we can fix them by expanding them.

2. Add the optional RADIX argument to IEEE_SET_ROUNDING_MODE and 
IEEE_GET_ROUNDING_MODE. It is unused for now, because we do not support 
floating-point radices other than 2.


Regression-tested on x86_64-pc-linux-gnu, both 32- and 64-bit.
OK to commit?




0001-fortran-Fortran-2018-rounding-modes-changes.patch
Description: Binary data

Re: [PATCH] rs6000: Don't ICE when we disassemble an MMA variable [PR101322]

On 8/31/22 8:59 AM, Peter Bergner wrote:
> On 8/31/22 4:22 AM, Kewen.Lin wrote:
>> on 2022/8/27 11:50, Peter Bergner via Gcc-patches wrote:
>>> -  tree src_type = TREE_TYPE (src_ptr);
>>> +  tree src_type = (fncode == RS6000_BIF_DISASSEMBLE_ACC)
>>> + ? build_pointer_type (vector_quad_type_node)
>>> + : build_pointer_type (vector_pair_type_node);
>>
>> Nit: it seems we can use existing ptr_vector_quad_type_node and 
>> ptr_vector_pair_type_node?
>> I assume the const qualifier is fine since it's for disassembling.
> 
> That's actually what I started with, but I got some type of gimple
> verification error which I can't remember what it said.  Let me put
> that back temporarily and I'll grab the error message.

...and of course, now I can't recreate that issue at all and the
ptr_vector_*_type use work fine now.  Strange! ...so ok, changed.
Maybe the behavior changed since my PR106017 fix went in???



>>> +  if (TREE_TYPE (TREE_TYPE (src_ptr)) != src_type)
>>
>> This line looks unexpected, the former is type char while the latter is type 
>> __vector_pair *.
>>
>> I guess you meant to compare the type of pointer type like: 
>>
>>TREE_TYPE (TREE_TYPE (src_ptr)) != TREE_TYPE (src_type)
> 
> Maybe?  However, if that is the case, how can it be working for me?
> Let me throw this in the debugger and verify the types and I'll report
> back with what I find.

Ok, you are correct.  Thanks for catching that!  I don't think we need
those matching outer TREE_TYPE() uses.  I think just a simple:

if (TREE_TYPE (src_ptr) != src_type)

...should suffice.


>> or even with mode like:
>>
>>TYPE_MODE (TREE_TYPE (TREE_TYPE (src_ptr))) != TYPE_MODE (TREE_TYPE 
>> (src_type))

I'd rather not look at the mode here, since OOmode/XOmode doesn't necessarily
mean __vector_{pair,quad}, so I'll go with the modified test above.




>>> +   src_ptr = build1 (VIEW_CONVERT_EXPR, src_type, src_ptr);
>>
>> Nit: NOP_EXPR seems to be better suited here for pointer conversion.

Ok, this works too, so code changed to use it.  Thanks!

Question for my own education, when would you use VIEW_CONVERT_EXPR over 
NOP_EXPR?



FYI, here is the current code patch with all of the suggested changes 
incorporated:

diff --git a/gcc/config/rs6000/rs6000-builtin.cc 
b/gcc/config/rs6000/rs6000-builtin.cc
index 12afa86854c..61352fcd801 100644
--- a/gcc/config/rs6000/rs6000-builtin.cc
+++ b/gcc/config/rs6000/rs6000-builtin.cc
@@ -1085,7 +1085,11 @@ rs6000_gimple_fold_mma_builtin (gimple_stmt_iterator 
*gsi,
   unsigned nvec = (fncode == RS6000_BIF_DISASSEMBLE_ACC) ? 4 : 2;
   tree dst_ptr = gimple_call_arg (stmt, 0);
   tree src_ptr = gimple_call_arg (stmt, 1);
-  tree src_type = TREE_TYPE (src_ptr);
+  tree src_type = (fncode == RS6000_BIF_DISASSEMBLE_ACC)
+ ? ptr_vector_quad_type_node : ptr_vector_pair_type_node;
+  if (TREE_TYPE (src_ptr) != src_type)
+   src_ptr = build1 (NOP_EXPR, src_type, src_ptr);
+
   tree src = create_tmp_reg_or_ssa_name (TREE_TYPE (src_type));
   gimplify_assign (src, build_simple_mem_ref (src_ptr), &new_seq);
 

I'll fire off a new round of bootstrap and regtesting and resubmit if it's 
clean.
Thanks for the review!


Peter

Re: [[GCC13][Patch][V3] 1/2] Add a new option -fstrict-flex-array[=n] and new attribute strict_flex_array

> On Aug 31, 2022, at 1:21 PM, Joseph Myers  wrote:
> 
> On Wed, 31 Aug 2022, Qing Zhao via Gcc-patches wrote:
> 
>>> "a GNU extension" suggests a particular language feature, but I think 
>>> you're actually referring here to a whole language version rather than an 
>>> individual feature.
>> 
>> Is “not supported by GNU extension GNU89” better?
> 
> There are no existing diagnostics referring to GNU89 at all.  I don't 
> think "GNU extension" needs to be mentioned in that diagnostic, but I also 
> think that having that diagnostic at all is ill-conceived.
> 
>>> In any case, -std=gnu89 supports flexible array members.
>> 
>> Yes, but only [0],[1] are supported as flexible array members.  The C99 
>> flexible array member [] is not supported by GNU89, right?
> 
> C99 flexible array members are fully supported in GNU89 mode.  In general, 
> any feature from a new language version that doesn't affect code that was 
> valid in previous versions is likely to be accepted as an extension with 
> options for older language versions.

We have a previous discussion on this: 
(https://gcc.gnu.org/pipermail/gcc-patches/2022-July/599067.html)

And looks like that the previous conclusion was wrong… please see the following:

==

> How is level 3 (thus -fstrict-flex-array) interpreted when you specify 
> -std=c89?  How for -std=gnu89?

1. what’s the major difference between -std=c89 and -std=gnu89 on flexible 
array? (Checked online, cannot find a concrete answer on this).
** my understanding is:   -std=c89 will not support any flexible array 
(neither [], [0], [1]), but -std=gnu89 will support [0] and [1], but not [].
Is this correct?

If my answer to the first question is correct, then:

2. When -fstrict-flex-array=n and -std=c89 present at the same time, which one 
has the higher priority? 
** I think that -std=c89 should be honored over -fstrict-flex-array, 
therefore we should disable -fstrict-flex-array=n when n > 0  and issue 
warnings to the user.

3. how about -fstrict-flex-array=n and -std=gnu89 present at the same time? 
** When -std=gnu89 present, [] is not supported. So, we need to issue 
an warning to disable -fstrict-flex-array=3; but level 1 and level 2 is Okay.

We also need to document the above.

So, from my understanding from what you said so far, 

-std=c89 will not support any flexible array (neither [], [0], [1]),  but 
-std=gnu89 will support ALL flexible array including [0], [1], and [].

Is this understanding correct?

thanks.

Qing

> 
> -- 
> Joseph S. Myers
> jos...@codesourcery.com

Re: [PATCH] d: Fix #error You must define PREFERRED_DEBUGGING_TYPE if DWARF is not supported (PR105659)

2022-08-31 Thread Iain Buclaw via Gcc-patches

Excerpts from Joseph Myers's message of August 31, 2022 7:16 pm:
> On Wed, 31 Aug 2022, Iain Buclaw via Gcc-patches wrote:
> 
>> Excerpts from Joseph Myers's message of August 30, 2022 11:53 pm:
>> > On Fri, 26 Aug 2022, Richard Biener via Gcc-patches wrote:
>> > 
>> >> I was hoping Joseph would chime in here - I recollect debugging this kind
>> >> of thing and a thread about this a while back but unfortunately I do not
>> >> remember the details here (IIRC some things get included where they
>> >> better should not be).
>> > 
>> > See .  
>> > Is there some reason it's problematic to avoid having defaults.h or 
>> > ${cpu_type}/${cpu_type}.h included in tm_d.h, and instead have tm_d.h only 
>> > include D-specific headers?
>> > 
>> 
>> In targets such as arm-elf, we still need to pull in definitions from
>> ${cpu_type}/${cpu_type}-d.cc into default-d.cc.
>> 
>> All I can think that might suffice is having D-specific prototype
>> headers in all targets as ${cpu_type}/${cpu_type}-d.h.
> 
> As long as those prototypes don't involve any types that depend on an 
> inclusion of tm.h, that should be fine.
> 

Updated patch that does what I described.

Bootstrapped on x86_64-linux-gnu and built an aarch64-rtems
cross-compiler without any errors, will kick off config-list.mk as well for
sanity checking a big list of targets in a while.

Iain.
---
PR d/105659

gcc/ChangeLog:

* config.gcc: Set tm_d_file to ${cpu_type}/${cpu_type}-d.h.
* config/aarch64/aarch64-d.cc: Include tm_d.h.
* config/aarch64/aarch64-protos.h (aarch64_d_target_versions): Move to
config/aarch64/aarch64-d.h.
(aarch64_d_register_target_info): Likewise.
* config/aarch64/aarch64.h (TARGET_D_CPU_VERSIONS): Likewise.
(TARGET_D_REGISTER_CPU_TARGET_INFO): Likewise.
* config/arm/arm-d.cc: Include tm_d.h instead of tm_p.h.
* config/arm/arm-protos.h (arm_d_target_versions): Move to
config/arm/arm-d.h.
(arm_d_register_target_info): Likewise.
* config/arm/arm.h (TARGET_D_CPU_VERSIONS): Likewise.
(TARGET_D_REGISTER_CPU_TARGET_INFO): Likewise.
* config/default-d.cc: Remove memmodel.h include.
* config/freebsd-d.cc: Include tm_d.h instead of tm_p.h.
* config/glibc-d.cc: Likewise.
* config/i386/i386-d.cc: Include tm_d.h.
* config/i386/i386-protos.h (ix86_d_target_versions): Move to
config/i386/i386-d.h.
(ix86_d_register_target_info): Likewise.
(ix86_d_has_stdcall_convention): Likewise.
* config/i386/i386.h (TARGET_D_CPU_VERSIONS): Likewise.
(TARGET_D_REGISTER_CPU_TARGET_INFO): Likewise.
(TARGET_D_HAS_STDCALL_CONVENTION): Likewise.
* config/i386/winnt-d.cc: Include tm_d.h instead of tm_p.h.
* config/mips/mips-d.cc: Include tm_d.h.
* config/mips/mips-protos.h (mips_d_target_versions): Move to
config/mips/mips-d.h.
(mips_d_register_target_info): Likewise.
* config/mips/mips.h (TARGET_D_CPU_VERSIONS): Likewise.
(TARGET_D_REGISTER_CPU_TARGET_INFO): Likewise.
* config/netbsd-d.cc: Include tm_d.h instead of tm.h and memmodel.h.
* config/openbsd-d.cc: Likewise.
* config/pa/pa-d.cc: Include tm_d.h.
* config/pa/pa-protos.h (pa_d_target_versions): Move to
config/pa/pa-d.h.
(pa_d_register_target_info): Likewise.
* config/pa/pa.h (TARGET_D_CPU_VERSIONS): Likewise.
(TARGET_D_REGISTER_CPU_TARGET_INFO): Likewise.
* config/riscv/riscv-d.cc: Include tm_d.h.
* config/riscv/riscv-protos.h (riscv_d_target_versions): Move to
config/riscv/riscv-d.h.
(riscv_d_register_target_info): Likewise.
* config/riscv/riscv.h (TARGET_D_CPU_VERSIONS): Likewise.
(TARGET_D_REGISTER_CPU_TARGET_INFO): Likewise.
* config/rs6000/rs6000-d.cc: Include tm_d.h.
* config/rs6000/rs6000-protos.h (rs6000_d_target_versions): Move to
config/rs6000/rs6000-d.h.
(rs6000_d_register_target_info): Likewise.
* config/rs6000/rs6000.h (TARGET_D_CPU_VERSIONS) Likewise.:
(TARGET_D_REGISTER_CPU_TARGET_INFO) Likewise.:
* config/s390/s390-d.cc: Include tm_d.h.
* config/s390/s390-protos.h (s390_d_target_versions): Move to
config/s390/s390-d.h.
(s390_d_register_target_info): Likewise.
* config/s390/s390.h (TARGET_D_CPU_VERSIONS): Likewise.
(TARGET_D_REGISTER_CPU_TARGET_INFO): Likewise.
* config/sol2-d.cc: Include tm_d.h instead of tm.h and memmodel.h.
* config/sparc/sparc-d.cc: Include tm_d.h.
* config/sparc/sparc-protos.h (sparc_d_target_versions): Move to
config/sparc/sparc-d.h.
(sparc_d_register_target_info): Likewise.
* config/sparc/sparc.h (TARGET_D_CPU_VERSIONS): Likewise.
(TARGET_D_REGISTER_CPU_TARGET_INFO): Likewise.
* configure: Regene

Re: [[GCC13][Patch][V3] 1/2] Add a new option -fstrict-flex-array[=n] and new attribute strict_flex_array



> On Aug 31, 2022, at 2:55 PM, Qing Zhao via Gcc-patches 
>  wrote:
> 
> 
> 
>> On Aug 31, 2022, at 1:21 PM, Joseph Myers  wrote:
>> 
>> On Wed, 31 Aug 2022, Qing Zhao via Gcc-patches wrote:
>> 
 "a GNU extension" suggests a particular language feature, but I think 
 you're actually referring here to a whole language version rather than an 
 individual feature.
>>> 
>>> Is “not supported by GNU extension GNU89” better?
>> 
>> There are no existing diagnostics referring to GNU89 at all.  I don't 
>> think "GNU extension" needs to be mentioned in that diagnostic, but I also 
>> think that having that diagnostic at all is ill-conceived.
>> 
 In any case, -std=gnu89 supports flexible array members.
>>> 
>>> Yes, but only [0],[1] are supported as flexible array members.  The C99 
>>> flexible array member [] is not supported by GNU89, right?
>> 
>> C99 flexible array members are fully supported in GNU89 mode.  In general, 
>> any feature from a new language version that doesn't affect code that was 
>> valid in previous versions is likely to be accepted as an extension with 
>> options for older language versions.
> 
> 
> We have a previous discussion on this: 
> (https://gcc.gnu.org/pipermail/gcc-patches/2022-July/599067.html)
> 
> And looks like that the previous conclusion was wrong… please see the 
> following:
> 
> ==
> 
>> How is level 3 (thus -fstrict-flex-array) interpreted when you specify 
>> -std=c89?  How for -std=gnu89?
> 
> 1. what’s the major difference between -std=c89 and -std=gnu89 on flexible 
> array? (Checked online, cannot find a concrete answer on this).
>   ** my understanding is:   -std=c89 will not support any flexible array 
> (neither [], [0], [1]), but -std=gnu89 will support [0] and [1], but not [].
>Is this correct?
> 
> If my answer to the first question is correct, then:
> 
> 2. When -fstrict-flex-array=n and -std=c89 present at the same time, which 
> one has the higher priority? 
>   ** I think that -std=c89 should be honored over -fstrict-flex-array, 
> therefore we should disable -fstrict-flex-array=n when n > 0  and issue 
> warnings to the user.
> 
> 
> 3. how about -fstrict-flex-array=n and -std=gnu89 present at the same time? 
>   ** When -std=gnu89 present, [] is not supported. So, we need to issue 
> an warning to disable -fstrict-flex-array=3; but level 1 and level 2 is Okay.
> 
> We also need to document the above.
> 
> 
> So, from my understanding from what you said so far, 
> 
> -std=c89 will not support any flexible array (neither [], [0], [1]),  but 
> -std=gnu89 will support ALL flexible array including [0], [1], and [].
> 
> Is this understanding correct?

And also for C++:

-std=c++98 will not support any flexible array, but -std=gnu++98 will support 
ALL flexible array ([0],[1].[])?

Qing
> 
> thanks.
> 
> Qing
> 
> 
>> 
>> -- 
>> Joseph S. Myers
>> jos...@codesourcery.com

[PATCH] libstdc++: A few more minor cleanups

2022-08-31 Thread Patrick Palka via Gcc-patches

Tested on x86_64-pc-linux-gnu, does this look OK for trunk?

libstdc++-v3/ChangeLog:

* include/bits/ranges_base.h (__advance_fn::operator()): Add
parentheses in assert condition to avoid -Wparentheses warning.
* include/std/ranges: (take_view::take_view): Uglify 'base'.
(take_while_view::take_while_view): Likewise.
(elements_view::elements_view): Likewise.
(views::_Zip::operator()): Adjust position of [[nodiscard]] for
compatibility with -fconcepts-ts.
(zip_transform_view::_Sentinel): Uglify 'OtherConst'.
(views::_ZipTransform::operator()): Adjust position of
[[nodiscard]] for compatibilty with -fconcepts-ts.
---
 libstdc++-v3/include/bits/ranges_base.h |  2 +-
 libstdc++-v3/include/std/ranges | 40 -
 2 files changed, 20 insertions(+), 22 deletions(-)

diff --git a/libstdc++-v3/include/bits/ranges_base.h 
b/libstdc++-v3/include/bits/ranges_base.h
index 38db33fd2ce..866d7c56cbc 100644
--- a/libstdc++-v3/include/bits/ranges_base.h
+++ b/libstdc++-v3/include/bits/ranges_base.h
@@ -778,7 +778,7 @@ namespace ranges
else if (__n != 0) [[likely]]
  {
// n and bound must not lead in opposite directions:
-   __glibcxx_assert(__n < 0 == __diff < 0);
+   __glibcxx_assert((__n < 0) == (__diff < 0));
 
(*this)(__it, __n);
return 0;
diff --git a/libstdc++-v3/include/std/ranges b/libstdc++-v3/include/std/ranges
index 2352aad76fc..39822b71b94 100644
--- a/libstdc++-v3/include/std/ranges
+++ b/libstdc++-v3/include/std/ranges
@@ -2121,8 +2121,8 @@ namespace views::__adaptor
   take_view() requires default_initializable<_Vp> = default;
 
   constexpr
-  take_view(_Vp base, range_difference_t<_Vp> __count)
-   : _M_base(std::move(base)), _M_count(std::move(__count))
+  take_view(_Vp __base, range_difference_t<_Vp> __count)
+   : _M_base(std::move(__base)), _M_count(std::move(__count))
   { }
 
   constexpr _Vp
@@ -2355,8 +2355,8 @@ namespace views::__adaptor
= default;
 
   constexpr
-  take_while_view(_Vp base, _Pred __pred)
-   : _M_base(std::move(base)), _M_pred(std::move(__pred))
+  take_while_view(_Vp __base, _Pred __pred)
+   : _M_base(std::move(__base)), _M_pred(std::move(__pred))
   { }
 
   constexpr _Vp
@@ -3982,8 +3982,8 @@ namespace views::__adaptor
   elements_view() requires default_initializable<_Vp> = default;
 
   constexpr explicit
-  elements_view(_Vp base)
-   : _M_base(std::move(base))
+  elements_view(_Vp __base)
+   : _M_base(std::move(__base))
   { }
 
   constexpr _Vp
@@ -4753,9 +4753,8 @@ namespace views::__adaptor
 {
   template
requires (sizeof...(_Ts) == 0 || __detail::__can_zip_view<_Ts...>)
-   [[nodiscard]]
constexpr auto
-   operator()(_Ts&&... __ts) const
+   operator() [[nodiscard]] (_Ts&&... __ts) const
{
  if constexpr (sizeof...(_Ts) == 0)
return views::empty>;
@@ -5036,22 +5035,22 @@ namespace views::__adaptor
   : _M_inner(std::move(__i._M_inner))
 { }
 
-template
-  requires sentinel_for<__zentinel<_Const>, __ziperator>
+template
+  requires sentinel_for<__zentinel<_Const>, __ziperator<_OtherConst>>
 friend constexpr bool
-operator==(const _Iterator& __x, const _Sentinel& __y)
+operator==(const _Iterator<_OtherConst>& __x, const _Sentinel& __y)
 { return __x._M_inner == __y._M_inner; }
 
-template
-  requires sized_sentinel_for<__zentinel<_Const>, __ziperator>
-friend constexpr range_difference_t<__detail::__maybe_const_t>
-operator-(const _Iterator& __x, const _Sentinel& __y)
+template
+  requires sized_sentinel_for<__zentinel<_Const>, __ziperator<_OtherConst>>
+friend constexpr range_difference_t<__detail::__maybe_const_t<_OtherConst, 
_InnerView>>
+operator-(const _Iterator<_OtherConst>& __x, const _Sentinel& __y)
 { return __x._M_inner - __y._M_inner; }
 
-template
-  requires sized_sentinel_for<__zentinel<_Const>, __ziperator>
-friend constexpr range_difference_t<__detail::__maybe_const_t>
-operator-(const _Sentinel& __x, const _Iterator& __y)
+template
+  requires sized_sentinel_for<__zentinel<_Const>, __ziperator<_OtherConst>>
+friend constexpr range_difference_t<__detail::__maybe_const_t<_OtherConst, 
_InnerView>>
+operator-(const _Sentinel& __x, const _Iterator<_OtherConst>& __y)
 { return __x._M_inner - __y._M_inner; }
   };
 
@@ -5068,9 +5067,8 @@ namespace views::__adaptor
 {
   template
requires (sizeof...(_Ts) == 0) || 
__detail::__can_zip_transform_view<_Fp, _Ts...>
-   [[nodiscard]]
constexpr auto
-   operator()(_Fp&& __f, _Ts&&... __ts) const
+   operator() [[nodiscard]] (_Fp&& __f, _Ts&&... __ts) const
{
  if constexpr (sizeof...(_Ts) == 0)

Re: [[GCC13][Patch][V3] 1/2] Add a new option -fstrict-flex-array[=n] and new attribute strict_flex_array

On Wed, 31 Aug 2022, Qing Zhao via Gcc-patches wrote:

> > How is level 3 (thus -fstrict-flex-array) interpreted when you specify 
> > -std=c89?  How for -std=gnu89?
> 
> 1. what’s the major difference between -std=c89 and -std=gnu89 on flexible 
> array? (Checked online, cannot find a concrete answer on this).
>   ** my understanding is:   -std=c89 will not support any flexible array 
> (neither [], [0], [1]), but -std=gnu89 will support [0] and [1], but not [].
> Is this correct?

Flexible array members are supported in all C standard modes, since they 
don't affect the semantics of any valid pre-C99 program (only make valid 
programs that were previously erroneous).

With -std=c89 or -std=gnu89, -pedantic will give a warning "ISO C90 does 
not support flexible array members" and -pedantic-errors will change that 
to an error.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH] rs6000/test: Fix bswap64-4.c with has_arch_ppc64 [PR106680]

On Wed, Aug 31, 2022 at 12:00:14PM -0500, Peter Bergner wrote:
> On 8/31/22 11:05 AM, Segher Boessenkool wrote:
> > On Wed, Aug 31, 2022 at 10:48:26AM -0500, Peter Bergner wrote:
> >> Ditto for -msoft-float better disable any -maltivec and -mvsx, etc.
> > 
> > Oh?  Why should it disable -maltivec?  -mvsx makes a little sense on
> > one hand, but totally none on the other either.
> 
> VSX has to be disabled, since VSX replies on the FP registers existing.

It doesn't?  On a CPU supporting VSX the FP registers are overlaid on
the VSX registers, not the other way around.

GCC says
  cc1: warning: '-mvsx' requires hardware floating point
and that's okay with me of course, but it doesn't say why it is
required.  Implementation convenience coupled with lack of a use case
is my best guess :-)

OTOH VMX and hard float are completely orthogonal (the VMX FP things do
not even use the fpscr for example).

> As for Altivec, I'm pretty sure there are some inherent dependencies
> there, probably both in hardware and our GCC backend implementation.
> I could be wrong, but my guess is things will fall over the ground
> if as allow -maltivec along with -msoft-float.  Does the linux kernel
> only build with -msoft-float assuming it disables altivec and vsx?
> Or does it explicitly always also add -mno-altivec?

No.  Instead, it just works!

Try this:
===
typedef float vf __attribute__((vector_size(16)));
vf f(float x)
{
x *= 42;
return (vf){x, x, x, x};
}
===
with -maltivec -msoft-float.  It does not use the FPRs, and it does use
the VMX registers and VMX instructions.

> So in linux*.h, we have the following which came from a 2004 commit from Alan:
> 
> linux64.h:#define OS_MISSING_POWERPC64 !TARGET_64BIT

That macro returns 1 on OSes that do not properly support -mpowerpc64.

> ...so I think there was no real reason, other than old 64-bit linux kernels 
> didn't
> save the upper register state in 32-bit mode binaries.

And it is still not saved in 32-bit user mode (setjmp/longjmp and
getcontext/setcontext).  Most bigger programs will fail, and most
smaller programs (including everything in the GCC testsuite) work fine.
But we should not enable -mpowerpc64 on 32-bit Linux by default.

Segher

Re: [PATCH] Add _GLIBCXX_DEBUG backtrace generation

2022-08-31 Thread François Dumont via Gcc-patches


On 31/08/22 12:11, Jonathan Wakely wrote:

On Wed, 31 Aug 2022 at 06:05, François Dumont  wrote:

After a second thought here is an even cleaner version. No more function
rename, current pretty_print is fine.

  libstdc++: [_GLIBCXX_DEBUG] Add backtrace generation on demand

Add _GLIBCXX_DEBUG_BACKTRACE macro to activate backtrace
generation on
  _GLIBCXX_DEBUG assertions. Prerequisite is to have configure the
lib with:

  --enable-libstdcxx-backtrace=yes

  libstdc++-v3/ChangeLog:

  * include/debug/formatter.h
  [_GLIBCXX_HAVE_STACKTRACE](__glibcxx_backtrace_state): Declare.
[_GLIBCXX_HAVE_STACKTRACE](__glibcxx_backtrace_create_state): Declare.
[_GLIBCXX_HAVE_STACKTRACE](__glibcxx_backtrace_full_callback): Define.
[_GLIBCXX_HAVE_STACKTRACE](__glibcxx_backtrace_error_callback): Define.
[_GLIBCXX_HAVE_STACKTRACE](__glibcxx_backtrace_full_func): Define.
  [_GLIBCXX_HAVE_STACKTRACE](__glibcxx_backtrace_full): Declare.
[_GLIBCXX_HAVE_STACKTRACE](_Error_formatter::_M_backtrace_state): New.
[_GLIBCXX_HAVE_STACKTRACE](_Error_formatter::_M_backtrace_full): New.
  * src/c++11/debug.cc
[_GLIBCXX_HAVE_STACKTRACE](print_backtrace): New.
  (_Error_formatter::_M_error()): Adapt.
  * src/libbacktrace/Makefile.am: Add backtrace.c.
  * src/libbacktrace/Makefile.in: Regenerate.
  * src/libbacktrace/backtrace-rename.h (backtrace_full): New.
  *
testsuite/23_containers/vector/debug/assign4_backtrace_neg.cc: New test.
  * doc/xml/manual/debug_mode.xml: Document
_GLIBCXX_DEBUG_BACKTRACE.
  * doc/xml/manual/using.xml: Likewise.
Ok to commit ?

OK for trunk, thanks.

The small change to print_raw in this patch makes me wonder whether
that function is actually useful.

It supports two modes, print with max precision, and print without.
The only time we use it to print with max precision we pass a string
of exactly the right length, so the precision is not needed (but the
caller has to get the string length correct: if we increase _S_indent
and do not increase the "" literal passed to print_raw, the
effects would be wrong).

Wouldn't it be better to just use fprintf directly when we want to
print without precision, and use a minimum field width instead of
precision for indenting? i.e. ...

--- a/libstdc++-v3/src/c++11/debug.cc
+++ b/libstdc++-v3/src/c++11/debug.cc
@@ -608,15 +608,6 @@ namespace
 print_literal(PrintContext& ctx, const char(&word)[Length])
 { print_word(ctx, word, Length - 1); }

-  void
-  print_raw(PrintContext& ctx, const char* str, ptrdiff_t nbc = -1)
-  {
-if (nbc >= 0)
-  ctx._M_column += fprintf(stderr, "%.*s", (int)nbc, str);
-else
-  ctx._M_column += fprintf(stderr, "%s", str);
-  }
-
   void
   print_word(PrintContext& ctx, const char* word, ptrdiff_t nbc = -1)
   {
@@ -643,12 +634,9 @@ namespace
|| (ctx._M_column + visual_length < ctx._M_max_length)
|| (visual_length >= ctx._M_max_length && ctx._M_column == 1))
   {
-   // If this isn't the first line, indent
+   // If this isn't the first line, indent.
if (ctx._M_column == 1 && !ctx._M_first_line)
- {
-   const char spacing[PrintContext::_S_indent + 1] = "";
-   print_raw(ctx, spacing, PrintContext::_S_indent);
- }
+ ctx._M_column += fprintf(stderr, "%*c", PrintContext::_S_indent, ' ');

I did not know this syntax, it looks definitely better.


int written = fprintf(stderr, "%.*s", (int)length, word);

@@ -1112,7 +1100,7 @@ namespace __gnu_debug
 PrintContext ctx;
 if (_M_file)
   {
-   print_raw(ctx, _M_file);
+   ctx._M_column += fprintf(stderr, "%s", _M_file);
print_literal(ctx, ":");
go_to_next_line = true;
   }


Do you take care or you prefer I do ?

Re: [[GCC13][Patch][V3] 1/2] Add a new option -fstrict-flex-array[=n] and new attribute strict_flex_array



> On Aug 31, 2022, at 3:29 PM, Joseph Myers  wrote:
> 
> On Wed, 31 Aug 2022, Qing Zhao via Gcc-patches wrote:
> 
>>> How is level 3 (thus -fstrict-flex-array) interpreted when you specify 
>>> -std=c89?  How for -std=gnu89?
>> 
>> 1. what’s the major difference between -std=c89 and -std=gnu89 on flexible 
>> array? (Checked online, cannot find a concrete answer on this).
>>  ** my understanding is:   -std=c89 will not support any flexible array 
>> (neither [], [0], [1]), but -std=gnu89 will support [0] and [1], but not [].
>>Is this correct?
> 
> Flexible array members are supported in all C standard modes, since they 
> don't affect the semantics of any valid pre-C99 program (only make valid 
> programs that were previously erroneous).
> 
> With -std=c89 or -std=gnu89, -pedantic will give a warning "ISO C90 does 
> not support flexible array members" and -pedantic-errors will change that 
> to an error.

A little confused here…

With both -std=c89 and -std=gnu89, -pedantic will warning on “[]” (C99 flexible 
array member):

[opc@qinzhao-ol8u3-x86 ~]$ gcc -std=c89 t.c  -pedantic
t.c:5:7: warning: ISO C90 does not support flexible array members [-Wpedantic]
5 |   int b[];
  |   ^
[opc@qinzhao-ol8u3-x86 ~]$ gcc -std=gnu89 t.c  -pedantic
t.c:5:7: warning: ISO C90 does not support flexible array members [-Wpedantic]
5 |   int b[];
  |   ^

Does the above mean that -std=gnu89 does not support C99 flexible array member, 
 then

When -std=gnu89 + -fstrict-flex-array=3  (ONLY C99 flexible array member [] is 
treated as a valid flexible array) present together, 

It should be reasonable to issue warning on this?  (-fstrict-flex-arrays=3 
is not supported by GNU extension GNU89, ignored)

Right?

Qing




> 
> -- 
> Joseph S. Myers
> jos...@codesourcery.com

Re: [[GCC13][Patch][V3] 1/2] Add a new option -fstrict-flex-array[=n] and new attribute strict_flex_array

On Wed, 31 Aug 2022, Qing Zhao wrote:

> Does the above mean that -std=gnu89 does not support C99 flexible array 
> member, then

No.

Flexible array members are supported by GCC in all C standards modes.  The 
C90 standard doesn't support them, but that's irrelevant to what GCC 
supports; it just means a diagnostic is required for strict conformance in 
pre-C99 modes.

> When -std=gnu89 + -fstrict-flex-array=3 (ONLY C99 flexible array member 
> [] is treated as a valid flexible array) present together,

That seems reasonable enough without a warning.  If people want a warning 
for flexible array members in older language modes, they can use 
-pedantic; I don't think we need to warn for any particular 
-fstrict-flex-array modes there.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH] rs6000/test: Fix bswap64-4.c with has_arch_ppc64 [PR106680]

On 8/31/22 2:28 PM, Segher Boessenkool wrote:
> On Wed, Aug 31, 2022 at 12:00:14PM -0500, Peter Bergner wrote:
> No.  Instead, it just works!
> 
> Try this:
> ===
> typedef float vf __attribute__((vector_size(16)));
> vf f(float x)
> {
>   x *= 42;
>   return (vf){x, x, x, x};
> }
> ===
> with -maltivec -msoft-float.  It does not use the FPRs, and it does use
> the VMX registers and VMX instructions.

Well color me surprised!

>> linux64.h:#define OS_MISSING_POWERPC64 !TARGET_64BIT
> 
> That macro returns 1 on OSes that do not properly support -mpowerpc64.

Right, but haven't the 64-bit Linux kernels been fixed forever to always
save/restore the full 64-bit hardware registers on a context switch/signal?
If not, them this whole thing is moot and the current behavior of disabling
-mpower64 if we use -m32 later on the command line is the correct thing to do.

> But we should not enable -mpowerpc64 on 32-bit Linux by default.

I didn't imply we should do that.  I was only agreeing with you that
we should try not disabling an explicit -mpowerpc64 when -m32 is used
later on the command line.

I only meant to say is that the code in rs6000_option_override_internal() is 
what
seems to remove the OPTION_MASK_POWERPC64 from our cpu mask when -m32 is used
later on the command line... and that is controlled by OS_MISSING_POWERPC64.
Changing OS_MISSING_POWERPC64 as I mentioned would not add OPTION_MASK_POWERPC64
to our cpu masks when -m32 is used.

Peter

Re: [[GCC13][Patch][V3] 1/2] Add a new option -fstrict-flex-array[=n] and new attribute strict_flex_array




> On Aug 31, 2022, at 3:52 PM, Joseph Myers  wrote:
> 
> On Wed, 31 Aug 2022, Qing Zhao wrote:
> 
>> Does the above mean that -std=gnu89 does not support C99 flexible array 
>> member, then
> 
> No.
> 
> Flexible array members are supported by GCC in all C standards modes.  The 
> C90 standard doesn't support them, but that's irrelevant to what GCC 
> supports; it just means a diagnostic is required for strict conformance in 
> pre-C99 modes.

Okay.

> 
>> When -std=gnu89 + -fstrict-flex-array=3 (ONLY C99 flexible array member 
>> [] is treated as a valid flexible array) present together,
> 
> That seems reasonable enough without a warning.  If people want a warning 
> for flexible array members in older language modes, they can use 
> -pedantic; I don't think we need to warn for any particular 
> -fstrict-flex-array modes there.

So, you mean,

1. GCC with -std=gnu89 support all [0], [1], and [] as Flexible array member;
2. Therefore. -std=gnu89 + -fstrict-flex-array=3 does not need a warning;

?

Then, how about:

-std=c89:

1. GCC with -std=c89 also support all [0], [1], and [] as Flexible array member;
2, therefore, -std=c89 + -fstrict-flex-array does not need a warning too.

?


Qing
> 
> -- 
> Joseph S. Myers
> jos...@codesourcery.com

Re: [PATCH] Add _GLIBCXX_DEBUG backtrace generation

On Wed, 31 Aug 2022 at 20:33, François Dumont  wrote:
>
> On 31/08/22 12:11, Jonathan Wakely wrote:
> > On Wed, 31 Aug 2022 at 06:05, François Dumont  wrote:
> >> After a second thought here is an even cleaner version. No more function
> >> rename, current pretty_print is fine.
> >>
> >>   libstdc++: [_GLIBCXX_DEBUG] Add backtrace generation on demand
> >>
> >> Add _GLIBCXX_DEBUG_BACKTRACE macro to activate backtrace
> >> generation on
> >>   _GLIBCXX_DEBUG assertions. Prerequisite is to have configure the
> >> lib with:
> >>
> >>   --enable-libstdcxx-backtrace=yes
> >>
> >>   libstdc++-v3/ChangeLog:
> >>
> >>   * include/debug/formatter.h
> >>   [_GLIBCXX_HAVE_STACKTRACE](__glibcxx_backtrace_state): 
> >> Declare.
> >> [_GLIBCXX_HAVE_STACKTRACE](__glibcxx_backtrace_create_state): Declare.
> >> [_GLIBCXX_HAVE_STACKTRACE](__glibcxx_backtrace_full_callback): Define.
> >> [_GLIBCXX_HAVE_STACKTRACE](__glibcxx_backtrace_error_callback): Define.
> >> [_GLIBCXX_HAVE_STACKTRACE](__glibcxx_backtrace_full_func): Define.
> >>   [_GLIBCXX_HAVE_STACKTRACE](__glibcxx_backtrace_full): 
> >> Declare.
> >> [_GLIBCXX_HAVE_STACKTRACE](_Error_formatter::_M_backtrace_state): New.
> >> [_GLIBCXX_HAVE_STACKTRACE](_Error_formatter::_M_backtrace_full): New.
> >>   * src/c++11/debug.cc
> >> [_GLIBCXX_HAVE_STACKTRACE](print_backtrace): New.
> >>   (_Error_formatter::_M_error()): Adapt.
> >>   * src/libbacktrace/Makefile.am: Add backtrace.c.
> >>   * src/libbacktrace/Makefile.in: Regenerate.
> >>   * src/libbacktrace/backtrace-rename.h (backtrace_full): New.
> >>   *
> >> testsuite/23_containers/vector/debug/assign4_backtrace_neg.cc: New test.
> >>   * doc/xml/manual/debug_mode.xml: Document
> >> _GLIBCXX_DEBUG_BACKTRACE.
> >>   * doc/xml/manual/using.xml: Likewise.
> >> Ok to commit ?
> > OK for trunk, thanks.
> >
> > The small change to print_raw in this patch makes me wonder whether
> > that function is actually useful.
> >
> > It supports two modes, print with max precision, and print without.
> > The only time we use it to print with max precision we pass a string
> > of exactly the right length, so the precision is not needed (but the
> > caller has to get the string length correct: if we increase _S_indent
> > and do not increase the "" literal passed to print_raw, the
> > effects would be wrong).
> >
> > Wouldn't it be better to just use fprintf directly when we want to
> > print without precision, and use a minimum field width instead of
> > precision for indenting? i.e. ...
> >
> > --- a/libstdc++-v3/src/c++11/debug.cc
> > +++ b/libstdc++-v3/src/c++11/debug.cc
> > @@ -608,15 +608,6 @@ namespace
> >  print_literal(PrintContext& ctx, const char(&word)[Length])
> >  { print_word(ctx, word, Length - 1); }
> >
> > -  void
> > -  print_raw(PrintContext& ctx, const char* str, ptrdiff_t nbc = -1)
> > -  {
> > -if (nbc >= 0)
> > -  ctx._M_column += fprintf(stderr, "%.*s", (int)nbc, str);
> > -else
> > -  ctx._M_column += fprintf(stderr, "%s", str);
> > -  }
> > -
> >void
> >print_word(PrintContext& ctx, const char* word, ptrdiff_t nbc = -1)
> >{
> > @@ -643,12 +634,9 @@ namespace
> > || (ctx._M_column + visual_length < ctx._M_max_length)
> > || (visual_length >= ctx._M_max_length && ctx._M_column == 1))
> >{
> > -   // If this isn't the first line, indent
> > +   // If this isn't the first line, indent.
> > if (ctx._M_column == 1 && !ctx._M_first_line)
> > - {
> > -   const char spacing[PrintContext::_S_indent + 1] = "";
> > -   print_raw(ctx, spacing, PrintContext::_S_indent);
> > - }
> > + ctx._M_column += fprintf(stderr, "%*c", PrintContext::_S_indent, 
> > ' ');
> I did not know this syntax, it looks definitely better.
> >
> > int written = fprintf(stderr, "%.*s", (int)length, word);
> >
> > @@ -1112,7 +1100,7 @@ namespace __gnu_debug
> >  PrintContext ctx;
> >  if (_M_file)
> >{
> > -   print_raw(ctx, _M_file);
> > +   ctx._M_column += fprintf(stderr, "%s", _M_file);
> > print_literal(ctx, ":");
> > go_to_next_line = true;
> >}
> >
> Do you take care or you prefer I do ?


I can do it.

Re: [PATCH] libstdc++: A few more minor cleanups

On Wed, 31 Aug 2022 at 20:27, Patrick Palka via Libstdc++
 wrote:
>
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk?

OK, thanks.

Re: [[GCC13][Patch][V3] 1/2] Add a new option -fstrict-flex-array[=n] and new attribute strict_flex_array

On Wed, 31 Aug 2022, Qing Zhao wrote:

> >> When -std=gnu89 + -fstrict-flex-array=3 (ONLY C99 flexible array member 
> >> [] is treated as a valid flexible array) present together,
> > 
> > That seems reasonable enough without a warning.  If people want a warning 
> > for flexible array members in older language modes, they can use 
> > -pedantic; I don't think we need to warn for any particular 
> > -fstrict-flex-array modes there.
> 
> So, you mean,
> 
> 1. GCC with -std=gnu89 support all [0], [1], and [] as Flexible array member;
> 2. Therefore. -std=gnu89 + -fstrict-flex-array=3 does not need a warning;
> 
> ?

Yes.

> Then, how about:
> 
> -std=c89:
> 
> 1. GCC with -std=c89 also support all [0], [1], and [] as Flexible array 
> member;
> 2, therefore, -std=c89 + -fstrict-flex-array does not need a warning too.
> 
> ?

Yes.

-- 
Joseph S. Myers
jos...@codesourcery.com

[committed] testsuite: Fix warning regression due to std::string changes [PR106795]