Re: [PATCH 2/2] Support Intel prefetchit0/t1

[Hongtao Liu via Gcc-patches]

On Thu, Oct 20, 2022 at 11:46 AM H.J. Lu via Gcc-patches
 wrote:
>
> On Fri, Oct 14, 2022 at 1:38 AM Haochen Jiang via Gcc-patches
>  wrote:
> >
> > gcc/ChangeLog:
> >
> > * common/config/i386/cpuinfo.h (get_available_features):
> > Detect PREFETCHI.
> > * common/config/i386/i386-common.cc
> > (OPTION_MASK_ISA2_PREFETCHI_SET,
> > OPTION_MASK_ISA2_PREFETCHI_UNSET): New.
> > (ix86_handle_option): Handle -mprefetchi.
> > * common/config/i386/i386-cpuinfo.h (enum processor_features):
> > Add FEATURE_PREFETCHI.
> > * common/config/i386/i386-isas.h: Add ISA_NAME_TABLE_ENTRY for
> > prefetchi.
> > * config.gcc: Add prfchiintrin.h.
> > * config/i386/cpuid.h (bit_PREFETCHI): New.
> > * config/i386/i386-c.cc (ix86_target_macros_internal): Define
> > __PREFETCHI__.
> > * config/i386/i386-isa.def (PREFETCHI): Add DEF_PTA(PREFETCHI).
> > * config/i386/i386-options.cc (ix86_valid_target_attribute_inner_p):
> > Handle prefetchi.
> > * config/i386/i386.md (prefetch): Add handler for prefetchi
> > (*prefetch_i): New define_insn.
> > * config/i386/i386.opt: Add option -mprefetchi.
> > * config/i386/immintrin.h: Include prfchiintrin.h.
> > * config/i386/predicates.md (local_func_symbolic_operand):
> > New predicates.
> > * config/i386/xmmintrin.h (enum _mm_hint): New enum for prefetchi.
> > (_mm_prefetch): Handle the highest bit of enum.
> > * doc/extend.texi: Document prefetchi.
> > * doc/invoke.texi: Document -mprefetchi.
> > * doc/sourcebuild.texi: Document target prefetchi.
> > * config/i386/prfchiintrin.h: New file.
> >
> > gcc/testsuite/ChangeLog:
> >
> > * g++.dg/other/i386-2.C: Add -mprefetchi.
> > * g++.dg/other/i386-3.C: Ditto.
> > * gcc.misc-tests/i386-pf-3dnow-1.c: Add scan-assembler-not for
> > prefetchit0/t1.
> > * gcc.misc-tests/i386-pf-athlon-1.c: Ditto.
> > * gcc.misc-tests/i386-pf-sse-1.c: Ditto.
> > * gcc.target/i386/avx-1.c: Add -mprefetchi.
> > * gcc.target/i386/avx-2.c: Ditto.
> > * gcc.target/i386/funcspec-56.inc: Add new target attribute.
> > * gcc.target/i386/prefetchi-1.c: Rewrite testcase.
> > * gcc.target/i386/prefetchi-2.c: New test.
> > * gcc.target/i386/prefetchi-3.c: Ditto.
> > * gcc.target/i386/sse-12.c: Add -mprefetchi.
> > * gcc.target/i386/sse-13.c: Ditto.
> > * gcc.target/i386/sse-14.c: Ditto.
> > * gcc.target/i386/sse-22.c: Add prefetchi.
> > * gcc.target/i386/sse-23.c: Ditto.
> >
> > Co-authored-by: Hongtao Liu 
> > ---
> >  gcc/common/config/i386/cpuinfo.h  |  2 +
> >  gcc/common/config/i386/i386-common.cc | 15 
> >  gcc/common/config/i386/i386-cpuinfo.h |  1 +
> >  gcc/common/config/i386/i386-isas.h|  1 +
> >  gcc/config.gcc|  2 +-
> >  gcc/config/i386/cpuid.h   |  1 +
> >  gcc/config/i386/i386-c.cc |  2 +
> >  gcc/config/i386/i386-isa.def  |  1 +
> >  gcc/config/i386/i386-options.cc   |  4 +-
> >  gcc/config/i386/i386.md   | 90 +--
> >  gcc/config/i386/i386.opt  |  4 +
> >  gcc/config/i386/immintrin.h   |  2 +
> >  gcc/config/i386/predicates.md | 15 
> >  gcc/config/i386/prfchiintrin.h| 39 
> >  gcc/config/i386/xmmintrin.h   |  6 +-
> >  gcc/doc/extend.texi   |  5 ++
> >  gcc/doc/invoke.texi   | 10 ++-
> >  gcc/doc/sourcebuild.texi  |  3 +
> >  gcc/testsuite/g++.dg/other/i386-2.C   |  2 +-
> >  gcc/testsuite/g++.dg/other/i386-3.C   |  2 +-
> >  .../gcc.misc-tests/i386-pf-3dnow-1.c  |  2 +
> >  .../gcc.misc-tests/i386-pf-athlon-1.c |  2 +
> >  gcc/testsuite/gcc.misc-tests/i386-pf-sse-1.c  |  2 +
> >  gcc/testsuite/gcc.target/i386/avx-1.c |  2 +-
> >  gcc/testsuite/gcc.target/i386/avx-2.c |  2 +-
> >  gcc/testsuite/gcc.target/i386/funcspec-56.inc |  2 +
> >  gcc/testsuite/gcc.target/i386/prefetchi-1.c   | 36 ++--
> >  gcc/testsuite/gcc.target/i386/prefetchi-2.c   | 26 ++
> >  gcc/testsuite/gcc.target/i386/prefetchi-3.c   | 15 
> >  gcc/testsuite/gcc.target/i386/sse-12.c|  2 +-
> >  gcc/testsuite/gcc.target/i386/sse-13.c|  2 +-
> >  gcc/testsuite/gcc.target/i386/sse-14.c|  2 +-
> >  gcc/testsuite/gcc.target/i386/sse-22.c|  4 +-
> >  gcc/testsuite/gcc.target/i386/sse-23.c|  2 +-
> >  34 files changed, 259 insertions(+), 49 deletions(-)
> >  create mode 100644 gcc/config/i386/prfchiintrin.h
> >  create mode 100644 gcc/testsuite/gcc.target/i386/prefetchi-2.c
> >  create mode 100644 gcc/testsui

Re: [PATCH 2/2] Support Intel prefetchit0/t1

[H.J. Lu via Gcc-patches]

On Fri, Oct 14, 2022 at 1:38 AM Haochen Jiang via Gcc-patches
 wrote:
>
> gcc/ChangeLog:
>
> * common/config/i386/cpuinfo.h (get_available_features):
> Detect PREFETCHI.
> * common/config/i386/i386-common.cc
> (OPTION_MASK_ISA2_PREFETCHI_SET,
> OPTION_MASK_ISA2_PREFETCHI_UNSET): New.
> (ix86_handle_option): Handle -mprefetchi.
> * common/config/i386/i386-cpuinfo.h (enum processor_features):
> Add FEATURE_PREFETCHI.
> * common/config/i386/i386-isas.h: Add ISA_NAME_TABLE_ENTRY for
> prefetchi.
> * config.gcc: Add prfchiintrin.h.
> * config/i386/cpuid.h (bit_PREFETCHI): New.
> * config/i386/i386-c.cc (ix86_target_macros_internal): Define
> __PREFETCHI__.
> * config/i386/i386-isa.def (PREFETCHI): Add DEF_PTA(PREFETCHI).
> * config/i386/i386-options.cc (ix86_valid_target_attribute_inner_p):
> Handle prefetchi.
> * config/i386/i386.md (prefetch): Add handler for prefetchi
> (*prefetch_i): New define_insn.
> * config/i386/i386.opt: Add option -mprefetchi.
> * config/i386/immintrin.h: Include prfchiintrin.h.
> * config/i386/predicates.md (local_func_symbolic_operand):
> New predicates.
> * config/i386/xmmintrin.h (enum _mm_hint): New enum for prefetchi.
> (_mm_prefetch): Handle the highest bit of enum.
> * doc/extend.texi: Document prefetchi.
> * doc/invoke.texi: Document -mprefetchi.
> * doc/sourcebuild.texi: Document target prefetchi.
> * config/i386/prfchiintrin.h: New file.
>
> gcc/testsuite/ChangeLog:
>
> * g++.dg/other/i386-2.C: Add -mprefetchi.
> * g++.dg/other/i386-3.C: Ditto.
> * gcc.misc-tests/i386-pf-3dnow-1.c: Add scan-assembler-not for
> prefetchit0/t1.
> * gcc.misc-tests/i386-pf-athlon-1.c: Ditto.
> * gcc.misc-tests/i386-pf-sse-1.c: Ditto.
> * gcc.target/i386/avx-1.c: Add -mprefetchi.
> * gcc.target/i386/avx-2.c: Ditto.
> * gcc.target/i386/funcspec-56.inc: Add new target attribute.
> * gcc.target/i386/prefetchi-1.c: Rewrite testcase.
> * gcc.target/i386/prefetchi-2.c: New test.
> * gcc.target/i386/prefetchi-3.c: Ditto.
> * gcc.target/i386/sse-12.c: Add -mprefetchi.
> * gcc.target/i386/sse-13.c: Ditto.
> * gcc.target/i386/sse-14.c: Ditto.
> * gcc.target/i386/sse-22.c: Add prefetchi.
> * gcc.target/i386/sse-23.c: Ditto.
>
> Co-authored-by: Hongtao Liu 
> ---
>  gcc/common/config/i386/cpuinfo.h  |  2 +
>  gcc/common/config/i386/i386-common.cc | 15 
>  gcc/common/config/i386/i386-cpuinfo.h |  1 +
>  gcc/common/config/i386/i386-isas.h|  1 +
>  gcc/config.gcc|  2 +-
>  gcc/config/i386/cpuid.h   |  1 +
>  gcc/config/i386/i386-c.cc |  2 +
>  gcc/config/i386/i386-isa.def  |  1 +
>  gcc/config/i386/i386-options.cc   |  4 +-
>  gcc/config/i386/i386.md   | 90 +--
>  gcc/config/i386/i386.opt  |  4 +
>  gcc/config/i386/immintrin.h   |  2 +
>  gcc/config/i386/predicates.md | 15 
>  gcc/config/i386/prfchiintrin.h| 39 
>  gcc/config/i386/xmmintrin.h   |  6 +-
>  gcc/doc/extend.texi   |  5 ++
>  gcc/doc/invoke.texi   | 10 ++-
>  gcc/doc/sourcebuild.texi  |  3 +
>  gcc/testsuite/g++.dg/other/i386-2.C   |  2 +-
>  gcc/testsuite/g++.dg/other/i386-3.C   |  2 +-
>  .../gcc.misc-tests/i386-pf-3dnow-1.c  |  2 +
>  .../gcc.misc-tests/i386-pf-athlon-1.c |  2 +
>  gcc/testsuite/gcc.misc-tests/i386-pf-sse-1.c  |  2 +
>  gcc/testsuite/gcc.target/i386/avx-1.c |  2 +-
>  gcc/testsuite/gcc.target/i386/avx-2.c |  2 +-
>  gcc/testsuite/gcc.target/i386/funcspec-56.inc |  2 +
>  gcc/testsuite/gcc.target/i386/prefetchi-1.c   | 36 ++--
>  gcc/testsuite/gcc.target/i386/prefetchi-2.c   | 26 ++
>  gcc/testsuite/gcc.target/i386/prefetchi-3.c   | 15 
>  gcc/testsuite/gcc.target/i386/sse-12.c|  2 +-
>  gcc/testsuite/gcc.target/i386/sse-13.c|  2 +-
>  gcc/testsuite/gcc.target/i386/sse-14.c|  2 +-
>  gcc/testsuite/gcc.target/i386/sse-22.c|  4 +-
>  gcc/testsuite/gcc.target/i386/sse-23.c|  2 +-
>  34 files changed, 259 insertions(+), 49 deletions(-)
>  create mode 100644 gcc/config/i386/prfchiintrin.h
>  create mode 100644 gcc/testsuite/gcc.target/i386/prefetchi-2.c
>  create mode 100644 gcc/testsuite/gcc.target/i386/prefetchi-3.c
>
> diff --git a/gcc/common/config/i386/cpuinfo.h 
> b/gcc/common/config/i386/cpuinfo.h
> index 118f3a42abd..551e0483330 100644
> --- a/gcc/common/config/i386/cpuinfo.h
> +++ b/gcc/common/config/i386/cpuinfo.h
> @@ -797,6 +7

Re: [PATCH 1/2] Add a parameter for the builtin function of prefetch to align with LLVM

[Hongtao Liu via Gcc-patches]

On Thu, Oct 20, 2022 at 9:39 AM Hongtao Liu  wrote:
>
> On Thu, Oct 20, 2022 at 5:08 AM Segher Boessenkool
>  wrote:
> >
> > On Fri, Oct 14, 2022 at 04:34:05PM +0800, Haochen Jiang wrote:
> > >   * config/s390/s390.cc (s390_expand_cpymem): Generate fourth 
> > > parameter for
> >
> > (Many too long lines here, this is the first one.  Changelog lines are
> > max. 80 positions; a tab is eight).
> >
> > > +  /* Argument 3 must be either zero or one.  */
> > > +  if (INTVAL (op3) != 0 && INTVAL (op3) != 1)
> > > +{
> > > +  warning (0, "invalid fourth argument to %<__builtin_prefetch%>;"
> > > + " using one");
> >
> > "using 1" makes sense maybe, but "using one" reads as "using an
> > argument", not very sane.
> >
> > An error would be better here anyway?
> >
> > > --- a/gcc/config/rs6000/rs6000.md
> > > +++ b/gcc/config/rs6000/rs6000.md
> > > @@ -14060,10 +14060,25 @@
> > >DONE;
> > >  })
> > >
> > > -(define_insn "prefetch"
> > > +(define_expand "prefetch"
> > > +  [(prefetch (match_operand 0 "indexed_or_indirect_address")
> > > +  (match_operand:SI 1 "const_int_operand")
> > > +  (match_operand:SI 2 "const_int_operand")
> > > +  (match_operand:SI 3 "const_int_operand"))]
> > > +  ""
> > > +{
> > > +  if (INTVAL (operands[3]) == 0)
> > > +  {
> >
> > Broken indentation.
> >
> > > +warning (0, "instruction prefetch is not supported; using data 
> > > prefetch");
> >
> > Please use a separate pattern for this, and leave prefetch to mean data
> > prefetch, as documented!  Documentation you didn't change btw.  Call the
> > new one instruction_prefetch or something equally boring maybe :-)
Yes, Maybe we should add new rtl def named "iprefetch", so there will
be no need to change other backend.
> >
> > When you send an updated patch, please split it up better?  Generic
> > changes and documentation in one patch, target changes in a separate
> We'll split testcase into a separate patch.
> > patch or patches, and testsuite is distinct as well.  It isn't nice to
> > have to scroll through thousands of lines to see if there is anything
> > relevant to you.
>
> Yes, it's an inconvenience for review, sorry for that. But since we've
> changed rtl def for prefetch, moving the general part into a separate
> commit may break bootstrap when rtl-check is enabled.
> -DEF_RTL_EXPR(PREFETCH, "prefetch", "eee", RTX_EXTRA)
> +DEF_RTL_EXPR(PREFETCH, "prefetch", "", RTX_EXTRA)
>
> And we want to make each commit pass the bootstrap and regression test.
> >
> > Thanks,
> >
> >
> > Segher
>
>
>
> --
> BR,
> Hongtao



-- 
BR,
Hongtao

Re: Announcement: Porting the Docs to Sphinx - 9. November 2022

[Xi Ruoyao via Gcc-patches]

On Mon, 2022-10-17 at 15:28 +0200, Martin Liška wrote:
> Hello.
> 
> Based on the very positive feedback I was given at the Cauldron Sphinx 
> Documentation BoF,
> I'm planning migrating the documentation on 9th November. There are still 
> some minor comments
> from Sandra when it comes to the PDF output, but we can address that once the 
> conversion is done.
> 
> The reason I'm sending the email now is that I was waiting for latest Sphinx 
> release (5.3.0) that
> simplifies reference format for options and results in much simpler Option 
> summary section ([1])
> 
> The current GCC master (using Sphinx 5.3.0) converted docs can be seen here:
> https://splichal.eu/scripts/sphinx/
> 
> If you see any issues with the converted documentation, or have a feedback 
> about it,
> please reply to this email.

Ouch.  This will be very painful for Linux From Scratch.  We'll need to
add 23 Python modules to build the documentation, while we only have 88
packages in total currently...  And we don't want to omit GCC
documentation in our system.

Could generated man and info pages be provided as a tarball on
gcc.gnu.org or ftp.gnu.org?

[PATCH v4] btf: Add support to BTF_KIND_ENUM64 type

[Guillermo E. Martinez via Gcc-patches]

Hello,

The following is patch v4 to update BTF/CTF backend supporting
BTF_KIND_ENUM64 type. Changes from v3:

  + Remove `ctf_enum_binfo' structure.
  + Remove -m{little,big}-endian from dg-options in testcase.

Comments will be welcomed and appreciated!,

Kind regards,
guillermo
--

BTF supports 64-bits enumerators with following encoding:

  struct btf_type:
name_off: 0 or offset to a valid C identifier
info.kind_flag: 0 for unsigned, 1 for signed
info.kind: BTF_KIND_ENUM64
info.vlen: number of enum values
size: 1/2/4/8

The btf_type is followed by info.vlen number of:

struct btf_enum64
{
  uint32_t name_off;   /* Offset in string section of enumerator name.  */
  uint32_t val_lo32;   /* lower 32-bit value for a 64-bit value Enumerator 
*/
  uint32_t val_hi32;   /* high 32-bit value for a 64-bit value Enumerator */
};

So, a new btf_enum64 structure was added to represent BTF_KIND_ENUM64
and a new field dtd_enum_unsigned in ctf_dtdef structure to distinguish
when CTF enum is a signed or unsigned type, later that information is
used to encode the BTF enum type.

gcc/ChangeLog:

* btfout.cc (btf_calc_num_vbytes): Compute enumeration size depending of
enumerator type btf_enum{,64}.
(btf_asm_type): Update btf_kflag according to enumeration type sign
using dtd_enum_unsigned field for both:  BTF_KIND_ENUM{,64}.
(btf_asm_enum_const): New argument to represent the size of
the BTF enum type, writing the enumerator constant value for
32 bits, if it's 64 bits then explicitly writes lower 32-bits
value and higher 32-bits value.
(output_asm_btf_enum_list): Add enumeration size argument.
* ctfc.cc (ctf_add_enum): New argument to represent CTF enum
basic information.
(ctf_add_generic): Use of ei_{name. size, unsigned} to build the
dtd structure containing enumeration information.
(ctf_add_enumerator): Update comment mention support for BTF
enumeration in 64-bits.
* dwarf2ctf.cc (gen_ctf_enumeration_type): Extract signedness
for enumeration type and use it in ctf_add_enum.
* ctfc.h (ctf_dmdef): Update dmd_value to HOST_WIDE_INT to allow
use 32/64 bits enumerators.
information.
(ctf_dtdef): New field to describe enum signedness.

include/
* btf.h (btf_enum64): Add new definition and new symbolic
constant to BTF_KIND_ENUM64 and BTF_KF_ENUM_{UN,}SIGNED.

gcc/testsuite/ChangeLog:

* gcc.dg/debug/btf/btf-enum-1.c: Update testcase, with correct
info.kflags encoding.
* gcc.dg/debug/btf/btf-enum64-1.c: New testcase.
---
 gcc/btfout.cc | 30 ++---
 gcc/ctfc.cc   | 13 +++---
 gcc/ctfc.h|  5 ++-
 gcc/dwarf2ctf.cc  |  5 ++-
 gcc/testsuite/gcc.dg/debug/btf/btf-enum-1.c   |  2 +-
 gcc/testsuite/gcc.dg/debug/btf/btf-enum64-1.c | 44 +++
 include/btf.h | 19 ++--
 7 files changed, 100 insertions(+), 18 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/debug/btf/btf-enum64-1.c

diff --git a/gcc/btfout.cc b/gcc/btfout.cc
index 997a33fa089..aef9fd70a28 100644
--- a/gcc/btfout.cc
+++ b/gcc/btfout.cc
@@ -223,7 +223,9 @@ btf_calc_num_vbytes (ctf_dtdef_ref dtd)
   break;
 
 case BTF_KIND_ENUM:
-  vlen_bytes += vlen * sizeof (struct btf_enum);
+  vlen_bytes += (dtd->dtd_data.ctti_size == 0x8)
+   ? vlen * sizeof (struct btf_enum64)
+   : vlen * sizeof (struct btf_enum);
   break;
 
 case BTF_KIND_FUNC_PROTO:
@@ -622,6 +624,15 @@ btf_asm_type (ctf_container_ref ctfc, ctf_dtdef_ref dtd)
   btf_size_type = 0;
 }
 
+  if (btf_kind == BTF_KIND_ENUM)
+{
+  btf_kflag = dtd->dtd_enum_unsigned
+   ? BTF_KF_ENUM_UNSIGNED
+   : BTF_KF_ENUM_SIGNED;
+  if (dtd->dtd_data.ctti_size == 0x8)
+   btf_kind = BTF_KIND_ENUM64;
+   }
+
   dw2_asm_output_data (4, dtd->dtd_data.ctti_name, "btt_name");
   dw2_asm_output_data (4, BTF_TYPE_INFO (btf_kind, btf_kflag, btf_vlen),
   "btt_info: kind=%u, kflag=%u, vlen=%u",
@@ -634,6 +645,7 @@ btf_asm_type (ctf_container_ref ctfc, ctf_dtdef_ref dtd)
 case BTF_KIND_UNION:
 case BTF_KIND_ENUM:
 case BTF_KIND_DATASEC:
+case BTF_KIND_ENUM64:
   dw2_asm_output_data (4, dtd->dtd_data.ctti_size, "btt_size: %uB",
   dtd->dtd_data.ctti_size);
   return;
@@ -707,13 +719,19 @@ btf_asm_sou_member (ctf_container_ref ctfc, ctf_dmdef_t * 
dmd)
 }
 }
 
-/* Asm'out an enum constant following a BTF_KIND_ENUM.  */
+/* Asm'out an enum constant following a BTF_KIND_ENUM{,64}.  */
 
 static void
-btf_asm_enum_const (ctf_dmdef_t * dmd)
+btf_asm_enum_const (unsigned int size, ctf_dmdef_t * dmd)
 {
   dw2_asm_output_data (4, d

RE: [PATCH 1/2] Add a parameter for the builtin function of prefetch to align with LLVM

[Jiang, Haochen via Gcc-patches]

> -Original Message-
> From: Segher Boessenkool 
> Sent: Thursday, October 20, 2022 5:14 AM
> To: Andrew Pinski 
> Cc: Jiang, Haochen ; gcc-patches@gcc.gnu.org;
> aol...@gcc.gnu.org; richard.sandif...@arm.com; uweig...@de.ibm.com;
> li...@gcc.gnu.org; g...@amylaar.uk; dje@gmail.com;
> olege...@gcc.gnu.org; claz...@synopsys.com; mfort...@gmail.com;
> da...@redhat.com; dave.ang...@bell.net; hubi...@ucw.cz;
> richard.earns...@arm.com; rguent...@suse.de;
> marcus.shawcr...@arm.com; ramana.radhakrish...@arm.com; Liu, Hongtao
> 
> Subject: Re: [PATCH 1/2] Add a parameter for the builtin function of prefetch
> to align with LLVM
> 
> On Wed, Oct 19, 2022 at 10:14:28AM -0700, Andrew Pinski wrote:
> > Do the testcases really need to be changed rather than adding new
> testcases?
> > Usually it is better if the testcases not change unless really needed
> > to be. That is do these testcases pass without being changed? If not
> > this seems not backwards compatible change and is not something which
> > we should do.  Otherwise you should just add new testcases instead.
> 
> Yes, that is another reason why adding parameters to random builtins is not a
> good idea :-)  s/random/only vaguely related/, if you want.
> 
> This also makes all existing code using these builtins invalid.  If you need 
> such
> testcase changes, that is a red flag.
> 

Maybe the testcase change cause some misunderstanding and concern.

Actually, the patch did not disrupt the previous builtins, as the 
builtin_prefetch
uses vargs. I set the default value of the new parameter as data prefetch, which
means that if we are not using the fourth parameter, just like how we use
prefetch previously, it is still what it is.

The reason why I did the most of the testcase change is to make it looks more
completed at the parameter side. I could take back that change on adding
parameter in current testcases just add tests related to new parameter, which
is a minimal change to current test I suppose.

BRs,
Haochen

> 
> Segher

Re: [PATCH 1/2] Add a parameter for the builtin function of prefetch to align with LLVM

[Hongtao Liu via Gcc-patches]

On Thu, Oct 20, 2022 at 5:08 AM Segher Boessenkool
 wrote:
>
> On Fri, Oct 14, 2022 at 04:34:05PM +0800, Haochen Jiang wrote:
> >   * config/s390/s390.cc (s390_expand_cpymem): Generate fourth parameter 
> > for
>
> (Many too long lines here, this is the first one.  Changelog lines are
> max. 80 positions; a tab is eight).
>
> > +  /* Argument 3 must be either zero or one.  */
> > +  if (INTVAL (op3) != 0 && INTVAL (op3) != 1)
> > +{
> > +  warning (0, "invalid fourth argument to %<__builtin_prefetch%>;"
> > + " using one");
>
> "using 1" makes sense maybe, but "using one" reads as "using an
> argument", not very sane.
>
> An error would be better here anyway?
>
> > --- a/gcc/config/rs6000/rs6000.md
> > +++ b/gcc/config/rs6000/rs6000.md
> > @@ -14060,10 +14060,25 @@
> >DONE;
> >  })
> >
> > -(define_insn "prefetch"
> > +(define_expand "prefetch"
> > +  [(prefetch (match_operand 0 "indexed_or_indirect_address")
> > +  (match_operand:SI 1 "const_int_operand")
> > +  (match_operand:SI 2 "const_int_operand")
> > +  (match_operand:SI 3 "const_int_operand"))]
> > +  ""
> > +{
> > +  if (INTVAL (operands[3]) == 0)
> > +  {
>
> Broken indentation.
>
> > +warning (0, "instruction prefetch is not supported; using data 
> > prefetch");
>
> Please use a separate pattern for this, and leave prefetch to mean data
> prefetch, as documented!  Documentation you didn't change btw.  Call the
> new one instruction_prefetch or something equally boring maybe :-)
>
> When you send an updated patch, please split it up better?  Generic
> changes and documentation in one patch, target changes in a separate
We'll split testcase into a separate patch.
> patch or patches, and testsuite is distinct as well.  It isn't nice to
> have to scroll through thousands of lines to see if there is anything
> relevant to you.

Yes, it's an inconvenience for review, sorry for that. But since we've
changed rtl def for prefetch, moving the general part into a separate
commit may break bootstrap when rtl-check is enabled.
-DEF_RTL_EXPR(PREFETCH, "prefetch", "eee", RTX_EXTRA)
+DEF_RTL_EXPR(PREFETCH, "prefetch", "", RTX_EXTRA)

And we want to make each commit pass the bootstrap and regression test.
>
> Thanks,
>
>
> Segher



-- 
BR,
Hongtao

Re: [PATCH 1/2] Add a parameter for the builtin function of prefetch to align with LLVM

[Hongtao Liu via Gcc-patches]

On Thu, Oct 20, 2022 at 5:15 AM Segher Boessenkool
 wrote:
>
> On Wed, Oct 19, 2022 at 10:14:28AM -0700, Andrew Pinski wrote:
> > Do the testcases really need to be changed rather than adding new testcases?
> > Usually it is better if the testcases not change unless really needed
> > to be. That is do these testcases pass without being changed? If not
> > this seems not backwards compatible change and is not something which
> > we should do.  Otherwise you should just add new testcases instead.
>
> Yes, that is another reason why adding parameters to random builtins is
> not a good idea :-)  s/random/only vaguely related/, if you want.
>
> This also makes all existing code using these builtins invalid.  If you
> need such testcase changes, that is a red flag.
The default behavior is the same as before(default data prefetch,
we'll unchange those testcases.)
>
>
> Segher



-- 
BR,
Hongtao

Re: Adding a new thread model to GCC

[LIU Hao via Gcc-patches]

在 2022/10/20 03:53, Bernhard Reutner-Fischer 写道:


which has kernel32 twice, which might not be ideal for the speed of linking?
I'm not familiar with the content of ntdll so cannot judge if you'd put that in
MCFGTHREAD_SPEC and drop kernel32 there, though, and put the whole
MCFG spec simply before the kernel32 in the REAL_LIBGCC_SPEC.

i.e.
+#define MCFGTHREAD_SPEC  " -lmcfgthread -lntdll "
...
+   -lmoldname -lmingwex -lmsvcrt " MCFGTHREAD_SPEC " -lkernel32 "

I hope this is constructive.
thanks,


NTDLL is the user-mode syscall library i.e. it mainly provides syscalls as 
functions.

Putting `-lmcfgthread` before `-lkernel32` was what I did in the beginning. However, I had an 
impression that NTDLL and KERNEL32 may both export some functions (I believe this is no longer the 
case now). Since MSVCRT in mingw-w64 is not a 'pure' import library and contains some functions that 
we implement on top of KERNEL32, the ideal solution would be


   ```
   #define MCFGTHREAD_SPEC  " -lmcfgthread "
   #define MCFGTHREAD_NTDLL_SPEC  " -lntdll "
 ...
   -lmsvcrt " MCFGTHREAD_SPEC " -lkernel32 " MCFGTHREAD_NTDLL_SPEC
   ```

(NTDLL is only necessary when linking against the shared library.)

The committed patch inserted MCFGTHREAD after KERNEL32 for simplicity, but if you do think we had 
better not repeat KERNEL32 twice, I can propose another patch.



--
Best regards,
LIU Hao


OpenPGP_signature
Description: OpenPGP digital signature

Re: [PATCH 0/6] Add Intel Sierra Forest Instructions

[Hongtao Liu via Gcc-patches]

On Wed, Oct 19, 2022 at 7:09 PM Iain Sandoe  wrote:
>
> Hi Hongtao
>
> > On 17 Oct 2022, at 02:56, Hongtao Liu  wrote:
> >
> > On Mon, Oct 17, 2022 at 9:30 AM Bernhard Reutner-Fischer
> >  wrote:
> >>
> >> On 17 October 2022 03:02:22 CEST, Hongtao Liu via Gcc-patches
> >>
> >> Do you have this series as a branch somewhere that I can try on one of 
> >> the
> >> like affected platforms?
> >
> > Not yet.
> > Do we have any external place to put those patches so folks from the
> > community can validate before it's committed, HJ?
> >>
> >>
> >> https://gcc.gnu.org/gitwrite.html#vendor
> >>
> >> Not sure where in cgit the user branches are visible, though? But they can 
> >> certainly be cloned and worked with.
> > Thanks for the reminder, I've pushed to remotes/vendors/ix86/ise046.
> > * [new ref] refs/vendors/ix86/heads/ise046 ->
> > vendors/ix86/ise046
>
> thanks for pushing this branch, much better to test these things before 
> committing rather than a panic
> to fix after…
>
>
> with
> f90df941532 (HEAD -> ise046, vendors/ix86/ise046) Add m_CORE_ATOM for atom 
> cores
>
>  - on x86_64 Darwin19  I get the following bootstrap fail:
>
> In file included from /src-local/gcc-master/gcc/config/i386/driver-i386.cc:31:
> /src-local/gcc-master/gcc/common/config/i386/cpuinfo.h: In function ‘const 
> char* get_intel_cpu(__processor_model*, __processor_model2*, unsigned int*)’:
> /src-local/gcc-master/gcc/common/config/i386/cpuinfo.h:532:32: error: this 
> statement may fall through [-Werror=implicit-fallthrough=]
>   532 |   cpu_model->__cpu_subtype = INTEL_COREI7_GRANITERAPIDS;
>   |   ~^~~~
> /src-local/gcc-master/gcc/common/config/i386/cpuinfo.h:533:5: note: here
>   533 | case 0xb6:
>   | ^~~~
> cc1plus: all warnings being treated as errors
>
> 
> Will try to look later, if that does not immediately ring some bell.
This should a bug, thanks!
> thanks
> Iain
>


-- 
BR,
Hongtao

[COMMITTED] PR c++/106654 - Add assume support to VRP.

[Andrew MacLeod via Gcc-patches]

This patch adds basic support for ASSUME functions to VRP.

Based on the previous set of patches, Ive cleaned them up, and this 
provides the basic support from rangers generalized model. It does not 
support non-ssa name parameters, I think you might be on your own for that.


I modified Jakubs assumption pass to use GORI to query parameter rangers 
in assumption functions and set the global range for those, and then 
ranger's infer infrastructure is used to inject these rangers at assume 
call locations in VRP.


I also added an optimization testcase that tests the basic functionality 
in VRP2.  For instance it can reduce:


int
f2 (int x, int y, int z)
{
  [[assume (x+12 == 14 && y >= 0 && y + 10 < 13 && z + 4 >= 4 && z - 2 
< 18)]];

  unsigned q = x + y + z;
  if (q*2 > 46)
    return 0;
  return 1;
}

to:

return 1;


Its good to get us going, bt I think theres still lots of room for 
improvement.


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

Andrew

From 53e6d7a3102409f0f2a5a9ffbfbeaa62c135d991 Mon Sep 17 00:00:00 2001
From: Andrew MacLeod 
Date: Tue, 18 Oct 2022 16:29:49 -0400
Subject: [PATCH] Add assume support to VRP.

This provides an assume_query class using rangers GORI module to
determine what ranges would be applied to any SSA NAMES in the function
if the return value were [1, 1].  Any parameter ranges are stored in
the SSA_NAME_RANGE_INFO field, and ranger's inferred range machinery is
then used to look these up and match them to assume call parameteres
in the bodies of other functions..

PR c++/106654
	gcc/
	* gimple-range-gori.h (compute_operand_range): Make public.
	* gimple-range-infer.cc (gimple_infer_range::check_assume_func): New.
	(gimple_infer_range::gimple_infer_range): Check for assume calls.
	* gimple-range-infer.h (check_assume_func): Add prototype.
	* gimple-range.cc (assume_query::assume_range_p): New.
	(assume_query::range_of_expr): New.
	(assume_query::assume_query): New.
	(assume_query::calculate_op): New.
	(assume_query::calculate_phi): New.
	(assume_query::check_taken_edge): New.
	(assume_query::calculate_stmt): New.
	(assume_query::dump): New.
	* gimple-range.h (class assume_query): New.
	* tree-vrp.cc (pass_assumptions::execute): Add processing.

	gcc/testsuite/
	* g++.dg/cpp23/attr-assume-opt.C: New.
---
 gcc/gimple-range-gori.h  |   6 +-
 gcc/gimple-range-infer.cc|  54 ++
 gcc/gimple-range-infer.h |   1 +
 gcc/gimple-range.cc  | 190 +++
 gcc/gimple-range.h   |  18 ++
 gcc/testsuite/g++.dg/cpp23/attr-assume-opt.C |  42 
 gcc/tree-vrp.cc  |  34 
 7 files changed, 342 insertions(+), 3 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp23/attr-assume-opt.C

diff --git a/gcc/gimple-range-gori.h b/gcc/gimple-range-gori.h
index c7a32162a1b..6cc533b58b2 100644
--- a/gcc/gimple-range-gori.h
+++ b/gcc/gimple-range-gori.h
@@ -165,15 +165,15 @@ public:
   bool has_edge_range_p (tree name, basic_block bb = NULL);
   bool has_edge_range_p (tree name, edge e);
   void dump (FILE *f);
+  bool compute_operand_range (vrange &r, gimple *stmt, const vrange &lhs,
+			  tree name, class fur_source &src,
+			  value_relation *rel = NULL);
 private:
   bool refine_using_relation (tree op1, vrange &op1_range,
 			  tree op2, vrange &op2_range,
 			  fur_source &src, relation_kind k);
   bool may_recompute_p (tree name, edge e);
   bool may_recompute_p (tree name, basic_block bb = NULL);
-  bool compute_operand_range (vrange &r, gimple *stmt, const vrange &lhs,
-			  tree name, class fur_source &src,
-			  value_relation *rel = NULL);
   bool compute_operand_range_switch (vrange &r, gswitch *s, const vrange &lhs,
  tree name, fur_source &src);
   bool compute_operand1_range (vrange &r, gimple_range_op_handler &handler,
diff --git a/gcc/gimple-range-infer.cc b/gcc/gimple-range-infer.cc
index f0d66d047a6..010b34a6bde 100644
--- a/gcc/gimple-range-infer.cc
+++ b/gcc/gimple-range-infer.cc
@@ -35,6 +35,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "gimple-iterator.h"
 #include "gimple-walk.h"
 #include "cfganal.h"
+#include "tree-dfa.h"
 
 // Adapted from infer_nonnull_range_by_dereference and check_loadstore
 // to process nonnull ssa_name OP in S.  DATA contains a pointer to a
@@ -56,6 +57,54 @@ non_null_loadstore (gimple *, tree op, tree, void *data)
   return false;
 }
 
+// Process an ASSUME call to see if there are any inferred ranges available.
+
+void
+gimple_infer_range::check_assume_func (gcall *call)
+{
+  tree arg;
+  unsigned i;
+  tree assume_id = TREE_OPERAND (gimple_call_arg (call, 0), 0);
+  if (!assume_id)
+return;
+  struct function *fun = DECL_STRUCT_FUNCTION (assume_id);
+  if (!fun)
+return;
+  // Loop over arguments, matching them to the assume paramters.
+  for (arg = DECL_ARGUMENTS (assume_id), i = 1;
+   arg && i

[PATCH] libstdc++: Refactor implementation of operator+ for std::string

[Will Hawkins]

Sorry for the delay. Tested on x86-64 Linux.

-->8--

After consultation with Jonathan, it seemed like a good idea to create a
single function that performed one-allocation string concatenation that
could be used by various different version of operator+. This patch adds
such a function and calls it from the relevant implementations.

libstdc++-v3/ChangeLog:

* include/bits/basic_string.h:
Add common function that performs single-allocation string
concatenation. (__str_cat)
Use __str_cat to perform optimized operator+, where relevant.
* include/bits/basic_string.tcc::
Remove single-allocation implementation of operator+.

Signed-off-by: Will Hawkins 
---
 libstdc++-v3/include/bits/basic_string.h   | 66 --
 libstdc++-v3/include/bits/basic_string.tcc | 41 --
 2 files changed, 49 insertions(+), 58 deletions(-)

diff --git a/libstdc++-v3/include/bits/basic_string.h 
b/libstdc++-v3/include/bits/basic_string.h
index cd244191df4..9c2b57f5a1d 100644
--- a/libstdc++-v3/include/bits/basic_string.h
+++ b/libstdc++-v3/include/bits/basic_string.h
@@ -3485,6 +3485,24 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
 _GLIBCXX_END_NAMESPACE_CXX11
 #endif
 
+  template
+_GLIBCXX20_CONSTEXPR
+inline _Str
+__str_concat(typename _Str::value_type const* __lhs,
+typename _Str::size_type __lhs_len,
+typename _Str::value_type const* __rhs,
+typename _Str::size_type __rhs_len,
+typename _Str::allocator_type const& __a)
+{
+  typedef typename _Str::allocator_type allocator_type;
+  typedef __gnu_cxx::__alloc_traits _Alloc_traits;
+  _Str __str(_Alloc_traits::_S_select_on_copy(__a));
+  __str.reserve(__lhs_len + __rhs_len);
+  __str.append(__lhs, __lhs_len);
+  __str.append(__rhs, __rhs_len);
+  return __str;
+}
+
   // operator+
   /**
*  @brief  Concatenate two strings.
@@ -3494,13 +3512,14 @@ _GLIBCXX_END_NAMESPACE_CXX11
*/
   template
 _GLIBCXX_NODISCARD _GLIBCXX20_CONSTEXPR
-basic_string<_CharT, _Traits, _Alloc>
+inline basic_string<_CharT, _Traits, _Alloc>
 operator+(const basic_string<_CharT, _Traits, _Alloc>& __lhs,
  const basic_string<_CharT, _Traits, _Alloc>& __rhs)
 {
-  basic_string<_CharT, _Traits, _Alloc> __str(__lhs);
-  __str.append(__rhs);
-  return __str;
+  typedef basic_string<_CharT, _Traits, _Alloc> _Str;
+  return std::__str_concat<_Str>(__lhs.c_str(), __lhs.size(),
+__rhs.c_str(), __rhs.size(),
+__lhs.get_allocator());
 }
 
   /**
@@ -3511,9 +3530,16 @@ _GLIBCXX_END_NAMESPACE_CXX11
*/
   template
 _GLIBCXX_NODISCARD _GLIBCXX20_CONSTEXPR
-basic_string<_CharT,_Traits,_Alloc>
+inline basic_string<_CharT,_Traits,_Alloc>
 operator+(const _CharT* __lhs,
- const basic_string<_CharT,_Traits,_Alloc>& __rhs);
+ const basic_string<_CharT,_Traits,_Alloc>& __rhs)
+{
+  __glibcxx_requires_string(__lhs);
+  typedef basic_string<_CharT, _Traits, _Alloc> _Str;
+  return std::__str_concat<_Str>(__lhs, _Traits::length(__lhs),
+__rhs.c_str(), __rhs.size(),
+__rhs.get_allocator());
+}
 
   /**
*  @brief  Concatenate character and string.
@@ -3523,8 +3549,14 @@ _GLIBCXX_END_NAMESPACE_CXX11
*/
   template
 _GLIBCXX_NODISCARD _GLIBCXX20_CONSTEXPR
-basic_string<_CharT,_Traits,_Alloc>
-operator+(_CharT __lhs, const basic_string<_CharT,_Traits,_Alloc>& __rhs);
+inline basic_string<_CharT,_Traits,_Alloc>
+operator+(_CharT __lhs, const basic_string<_CharT,_Traits,_Alloc>& __rhs)
+{
+  typedef basic_string<_CharT, _Traits, _Alloc> _Str;
+  return std::__str_concat<_Str>(__builtin_addressof(__lhs), 1,
+__rhs.c_str(), __rhs.size(),
+__rhs.get_allocator());
+}
 
   /**
*  @brief  Concatenate string and C string.
@@ -3538,11 +3570,12 @@ _GLIBCXX_END_NAMESPACE_CXX11
 operator+(const basic_string<_CharT, _Traits, _Alloc>& __lhs,
  const _CharT* __rhs)
 {
-  basic_string<_CharT, _Traits, _Alloc> __str(__lhs);
-  __str.append(__rhs);
-  return __str;
+  __glibcxx_requires_string(__rhs);
+  typedef basic_string<_CharT, _Traits, _Alloc> _Str;
+  return std::__str_concat<_Str>(__lhs.c_str(), __lhs.size(),
+__rhs, _Traits::length(__rhs),
+__lhs.get_allocator());
 }
-
   /**
*  @brief  Concatenate string and character.
*  @param __lhs  First string.
@@ -3554,11 +3587,10 @@ _GLIBCXX_END_NAMESPACE_CXX11
 inline basic_string<_CharT, _Traits, _Alloc>
 operator+(const basic_string<_CharT, _Traits, _Alloc>& __lhs, _CharT __rhs)
 {
-  typedef basic_string<_C

[PATCH] diagnostics: Allow FEs to keep customizations for middle end [PR101551, PR106274]

[Lewis Hyatt via Gcc-patches]

Currently, the ipa-free-lang-data pass resets most of the frontend's
diagnostic customizations, such as the diagnostic_finalizer that prints macro
expansion information, which is the subject of the two PRs. In most cases,
however, there is no need to reset these customizations; they still work just
fine after the language-specific data has been freed. (Macro tracking
information, for instance, only depends on the line_maps instance and does not
use the tree data structures at all.)

Add an interface whereby frontends can convey which of their customizations
should be preserved by ipa-free-lang-data. Only the macro tracking behavior is
changed for now.  Subsequent patches will add further configurations for each
frontend.

gcc/ChangeLog:

PR lto/106274
PR middle-end/101551
* diagnostic.h (struct diagnostic_context): Add new customization
point diagnostic_context::preserve_on_reset.
* diagnostic.cc (diagnostic_initialize): Initialize it.
* tree-diagnostic.h (tree_diagnostics_defaults): Add new optional
argument enable_preserve.
* tree-diagnostic.cc (tree_diagnostics_defaults): Implement it.
* ipa-free-lang-data.cc (free_lang_data): Use it.

gcc/c-family/ChangeLog:

PR lto/106274
PR middle-end/101551
* c-opts.cc (c_common_diagnostics_set_defaults): Preserve
diagnostic finalizer for the middle end.

libgomp/ChangeLog:

PR lto/106274
PR middle-end/101551
* testsuite/libgomp.oacc-c-c++-common/reduction-5.c: Remove
now-unnecessary workaround.
* testsuite/libgomp.oacc-c-c++-common/vred2d-128.c: Likewise.

gcc/testsuite/ChangeLog:

PR lto/106274
PR middle-end/101551
* c-c++-common/diag-after-fld-1.c: New test.
---

Notes:
Hello-

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

PR101551 complains that when compiling with offloading enabled, diagnostics
output changes in several different ways. PR106274 notes the same thing 
(which
has the same cause) when compiling with -flto, for the specific case of 
macro
expansion tracking, which is no longer output for middle-end diagnostics 
when
-flto is present. Restoring the macro tracking information, at least, can be
done simply, which is the attached patch. This is straightforward because 
the
printing of macro tracking information is not really reliant on the sort of
language-specific data structures that are freed by ipa-free-lang-data... it
just needs the line-maps API, which is common to all languages and which is
not impacted by the work done by ipa-free-lang-data.

To be clear, this is not about diagnostics issued *by* the lto frontend. 
This
is just about diagnostics issued by the language frontends, in case they 
were
asked to stream the IL for later use by the lto frontend. I think from the
user's perspective, compiling with or without -flto should not change the
quality of diagnostics, since on the face of it, -flto seems to be just a
request for the compiler to do something extra (write out the IL in addition
to all the other stuff it does), and it's not clear why this should change 
the
way diagnostics look. (I understand there must be some good reasons, why 
it's
not the case.)  So anyway I was focusing on how to keep the diagnostics as
close as possible to their normal form after ipa-free-lang-data is done.

The approach I took was to add a new variable "preserve_on_reset" in the
diagnostic_context, allowing a frontend to specify whether its diagnostic
context customizations are safe to leave in place for the middle end. There
are currently four customizations for which preservation can be enabled:

* diagnostic starter
* diagnostic finalizer
* format decoder
* decl_printable_name langhook

Preserving the diagnostic finalizer is sufficient to restore the output of
macro tracking information, and that's what I did in this patch. But it 
seems
that it's possible to go a bit farther than this as well. Here are some
examples:

1. Fortran:
Consider the existing testcase
gfortran.dg/allocatable_uninitialized_1.f90. When compiled without 
-flto,
it outputs:

===
allocatable_uninitialized_1.f90:6:47:

6 |a(1)=2*b(1) ! { dg-warning "uninitialized" }
  |   ^
Warning: 'b.offset' is used uninitialized [-Wuninitialized]
allocatable_uninitialized_1.f90:4:30:

4 |   real,allocatable:: a(:),b(:)
  |  ^
note: 'b' declared here
allocatable_uninitialized_1.f90:6:47:

6 |a(1)=2*b(1) ! { dg-warning "uninitialized" }
 

[PATCH] bpf: add preserve_field_info builtin

[David Faust via Gcc-patches]

Add BPF __builtin_preserve_field_info. This builtin is used to extract
information to facilitate struct and union relocations performed by the
BPF loader, especially for bitfields.

The builtin has the following signature:

  unsigned int __builtin_preserve_field_info (EXPR, unsigned int KIND);

Where EXPR is an expression accessing a field of a struct or union.
Depending on KIND, different information is returned to the program. The
supported values for KIND are as follows:

  enum {
FIELD_BYTE_OFFSET = 0,
FIELD_BYTE_SIZE,
FIELD_EXISTENCE,
FIELD_SIGNEDNESS,
FIELD_LSHIFT_U64,
FIELD_RSHIFT_U64
  };

If -mco-re is in effect (explicitly or implicitly specified), a CO-RE
relocation is added for the access in EXPR recording the relevant
information according to KIND.

Tested on bpf-unknown-none, no known regressions.
OK?

Thanks

gcc/

* config/bpf/bpf.cc: Support __builtin_preserve_field_info.
(enum bpf_builtins): Add new builtin.
(bpf_init_builtins): Likewise.
(bpf_core_field_info): New function.
(bpf_expand_builtin): Accomodate new builtin. Refactor adding new
relocation to...
(maybe_make_core_relo): ... here. New function.
(bpf_resolve_overloaded_builtin): Accomodate new builtin.
(bpf_core_newdecl): Likewise.
(bpf_core_walk): Likewise.
(bpf_core_is_maybe_aggregate_access): Improve logic.
(struct core_walk_data): New.
* config/bpf/coreout.cc (bpf_core_reloc_add): Allow adding different
relocation kinds.
* config/bpf/coreout.h: Analogous change.
* doc/extend.texi: Document BPF __builtin_preserve_field_info.

gcc/testsuite/

* gcc.target/bpf/core-builtin-fieldinfo-existence-1.c: New test.
* gcc.target/bpf/core-builtin-fieldinfo-lshift-1-be.c: New test.
* gcc.target/bpf/core-builtin-fieldinfo-lshift-1-le.c: New test.
* gcc.target/bpf/core-builtin-fieldinfo-lshift-2.c: New test.
* gcc.target/bpf/core-builtin-fieldinfo-offset-1.c: New test.
* gcc.target/bpf/core-builtin-fieldinfo-rshift-1.c: New test.
* gcc.target/bpf/core-builtin-fieldinfo-rshift-2.c: New test.
* gcc.target/bpf/core-builtin-fieldinfo-sign-1.c: New test.
* gcc.target/bpf/core-builtin-fieldinfo-sign-2.c: New test.
* gcc.target/bpf/core-builtin-fieldinfo-size-1.c: New test.
---
 gcc/config/bpf/bpf.cc | 327 ++
 gcc/config/bpf/coreout.cc |   5 +-
 gcc/config/bpf/coreout.h  |   2 +-
 gcc/doc/extend.texi   |  21 ++
 .../bpf/core-builtin-fieldinfo-existence-1.c  |  34 ++
 .../bpf/core-builtin-fieldinfo-lshift-1-be.c  |  37 ++
 .../bpf/core-builtin-fieldinfo-lshift-1-le.c  |  37 ++
 .../bpf/core-builtin-fieldinfo-lshift-2.c |  37 ++
 .../bpf/core-builtin-fieldinfo-offset-1.c |  56 +++
 .../bpf/core-builtin-fieldinfo-rshift-1.c |  36 ++
 .../bpf/core-builtin-fieldinfo-rshift-2.c |  35 ++
 .../bpf/core-builtin-fieldinfo-sign-1.c   |  33 ++
 .../bpf/core-builtin-fieldinfo-sign-2.c   |  45 +++
 .../bpf/core-builtin-fieldinfo-size-1.c   |  43 +++
 14 files changed, 676 insertions(+), 72 deletions(-)
 create mode 100644 
gcc/testsuite/gcc.target/bpf/core-builtin-fieldinfo-existence-1.c
 create mode 100644 
gcc/testsuite/gcc.target/bpf/core-builtin-fieldinfo-lshift-1-be.c
 create mode 100644 
gcc/testsuite/gcc.target/bpf/core-builtin-fieldinfo-lshift-1-le.c
 create mode 100644 
gcc/testsuite/gcc.target/bpf/core-builtin-fieldinfo-lshift-2.c
 create mode 100644 
gcc/testsuite/gcc.target/bpf/core-builtin-fieldinfo-offset-1.c
 create mode 100644 
gcc/testsuite/gcc.target/bpf/core-builtin-fieldinfo-rshift-1.c
 create mode 100644 
gcc/testsuite/gcc.target/bpf/core-builtin-fieldinfo-rshift-2.c
 create mode 100644 gcc/testsuite/gcc.target/bpf/core-builtin-fieldinfo-sign-1.c
 create mode 100644 gcc/testsuite/gcc.target/bpf/core-builtin-fieldinfo-sign-2.c
 create mode 100644 gcc/testsuite/gcc.target/bpf/core-builtin-fieldinfo-size-1.c

diff --git a/gcc/config/bpf/bpf.cc b/gcc/config/bpf/bpf.cc
index 51055651707..41a506349b2 100644
--- a/gcc/config/bpf/bpf.cc
+++ b/gcc/config/bpf/bpf.cc
@@ -184,13 +184,13 @@ enum bpf_builtins
 
   /* Compile Once - Run Everywhere (CO-RE) support.  */
   BPF_BUILTIN_PRESERVE_ACCESS_INDEX,
+  BPF_BUILTIN_PRESERVE_FIELD_INFO,
 
   BPF_BUILTIN_MAX,
 };
 
 static GTY (()) tree bpf_builtins[(int) BPF_BUILTIN_MAX];
 
-
 void bpf_register_coreattr_pass (void);
 
 /* Initialize the per-function machine status.  */
@@ -966,6 +966,9 @@ bpf_init_builtins (void)
   def_builtin ("__builtin_preserve_access_index",
   BPF_BUILTIN_PRESERVE_ACCESS_INDEX,
   build_function_type_list (ptr_type_node, ptr_type_node, 0));
+  def_builtin ("__builtin_preserve_field_info",
+  BPF_BUILTIN_PRESERVE_FIELD_INFO,
+  build_function_type_list (unsigned_type_node, ptr

[committed] c: C2x %wN, %wfN format checking

[Joseph Myers]

C2x adds printf and scanf wN and wfN length modifiers (wN for
int_leastN_t / uint_leastN_t, also usable for intN_t and uintN_t which
are now required to be the same type as the "least" versions when both
are supported; wfN for int_fastN_t / uint_fastN_t).  Add corresponding
format checking support for those length modifiers, for all the
standard integer conversion speciciers plus the recommended integer
specifier %B.

Note that, as with the %b support, this only deals with format
checking, not other format handling elsewhere in the compiler (in
particular, it doesn't add any -Wformat-overflow support; cf. Frolov
Daniil's patch

adding such support for %b and %B, which I think is still pending
review).  And of course library support is a separate matter for each
library implementation (I hope to add corresponding glibc support in
due course).

None of the tables of format conversions for kinds of formats not
supporting the new length modifiers are updated; they don't need
updating because the entries not matching some length modifier listed
for that kind of format can never be accessed, and the tables
generally thus already only explicitly covered a sufficient initial
subsequence of the length modifiers, rather than listing a full 13
possibilities before this patch or 21 after it.  %w (as used for
HOST_WIDE_INT in GCC-internal formats) comes after the new modifiers
in the FMT_LEN_* enumeration, but that's not a problem because the
tables don't actually use FMT_LEN_w entries; rather, such entries get
rewritten at runtime once GCC knows the value of HOST_WIDE_INT in the
GCC it's compiling.

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

gcc/c-family/
* c-format.h (enum format_lengths): Add FMT_LEN_w8, FMT_LEN_w16,
FMT_LEN_w32, FMT_LEN_w64, FMT_LEN_wf8, FMT_LEN_wf16, FMT_LEN_wf32
and FMT_LEN_wf64.
(NOARGUMENTS, NOLENGTHS): Update definitions.
(T_I8, T2X_I8, T_I16, T2X_I16, T_I32, T2X_I32, T_I64, T2X_I64)
(T_U8, T2X_U8, T_U16, T2X_U16, T_U32, T2X_U32, T_U64, T2X_U64)
(T_IF8, T2X_IF8, T_IF16, T2X_IF16, T_IF32, T2X_IF32, T_IF64)
(T2X_IF64, T_UF8, T2X_UF8, T_UF16, T2X_UF16, T_UF32, T2X_UF32)
(T_UF64, T2X_UF64): New macros.
* c-format.cc (printf_length_specs, scanf_length_specs): Add wN
and wfN length modifiers.
(print_char_table, scan_char_table): Add entries using wN and wfN
length modifiers.

gcc/testsuite/
* gcc.dg/format/format.h (int_least8_t, int_least16_t)
(int_least32_t, int_least64_t, uint_least8_t, uint_least16_t)
(uint_least32_t, uint_least64_t, int_fast8_t, int_fast16_t)
(int_fast32_t, int_fast64_t, uint_fast8_t, uint_fast16_t)
(uint_fast32_t, uint_fast64_t): New typedefs.
* gcc.dg/format/c11-printf-1.c, gcc.dg/format/c11-scanf-1.c,
gcc.dg/format/c2x-printf-1.c, gcc.dg/format/c2x-scanf-1.c,
gcc.dg/format/ext-9.c: Add tests using wN and wfN length
modifiers.

diff --git a/gcc/c-family/c-format.cc b/gcc/c-family/c-format.cc
index a2026591ed1..01adea4ff41 100644
--- a/gcc/c-family/c-format.cc
+++ b/gcc/c-family/c-format.cc
@@ -488,6 +488,14 @@ static const format_length_info printf_length_specs[] =
   { "j", FMT_LEN_j, STD_C99, NO_FMT, 0 },
   { "H", FMT_LEN_H, STD_C2X, NO_FMT, 0 },
   { "D", FMT_LEN_D, STD_C2X, "DD", FMT_LEN_DD, STD_C2X, 0 },
+  { "w8", FMT_LEN_w8, STD_C2X, NO_FMT, 0 },
+  { "w16", FMT_LEN_w16, STD_C2X, NO_FMT, 0 },
+  { "w32", FMT_LEN_w32, STD_C2X, NO_FMT, 0 },
+  { "w64", FMT_LEN_w64, STD_C2X, NO_FMT, 0 },
+  { "wf8", FMT_LEN_wf8, STD_C2X, NO_FMT, 0 },
+  { "wf16", FMT_LEN_wf16, STD_C2X, NO_FMT, 0 },
+  { "wf32", FMT_LEN_wf32, STD_C2X, NO_FMT, 0 },
+  { "wf64", FMT_LEN_wf64, STD_C2X, NO_FMT, 0 },
   { NO_FMT, NO_FMT, 0 }
 };
 
@@ -525,6 +533,14 @@ static const format_length_info scanf_length_specs[] =
   { "j", FMT_LEN_j, STD_C99, NO_FMT, 0 },
   { "H", FMT_LEN_H, STD_C2X, NO_FMT, 0 },
   { "D", FMT_LEN_D, STD_C2X, "DD", FMT_LEN_DD, STD_C2X, 0 },
+  { "w8", FMT_LEN_w8, STD_C2X, NO_FMT, 0 },
+  { "w16", FMT_LEN_w16, STD_C2X, NO_FMT, 0 },
+  { "w32", FMT_LEN_w32, STD_C2X, NO_FMT, 0 },
+  { "w64", FMT_LEN_w64, STD_C2X, NO_FMT, 0 },
+  { "wf8", FMT_LEN_wf8, STD_C2X, NO_FMT, 0 },
+  { "wf16", FMT_LEN_wf16, STD_C2X, NO_FMT, 0 },
+  { "wf32", FMT_LEN_wf32, STD_C2X, NO_FMT, 0 },
+  { "wf64", FMT_LEN_wf64, STD_C2X, NO_FMT, 0 },
   { NO_FMT, NO_FMT, 0 }
 };
 
@@ -693,26 +709,26 @@ static const format_flag_pair strfmon_flag_pairs[] =
 static const format_char_info print_char_table[] =
 {
   /* C89 conversion specifiers.  */
-  { "di",  0, STD_C89, { T89_I,   T99_SC,  T89_S,   T89_L,   T9L_LL,  TEX_LL,  
T99_SST, T99_PD,  T99_IM,  BADLEN,  BADLEN,  BADLEN  }, "-wp0 +'I",  "i",  NULL 
},
-  { "oxX", 0, STD_C89, { T89_UI,  T99_UC,  T89_US,  T89_UL,  T9L_ULL, TEX_ULL, 
T99_ST,  T99_UPD, T99_UIM, BADLEN,  BADLEN,  BADLEN }, "-wp0#", "i",  NULL 

[COMMITTED] Always check result from build_ in range-op-float.cc

[Aldy Hernandez via Gcc-patches]

A result of false from build_ in range-ops means the result is
final and needs no further adjustments.  This patch documents this,
and changes all uses to check the result.  There should be no change
in functionality.

gcc/ChangeLog:

* range-op-float.cc (build_le): Document result.
(build_lt): Same.
(build_ge): Same.
(foperator_ge::op2_range): Check result of build_*.
(foperator_unordered_le::op1_range): Same.
(foperator_unordered_le::op2_range): Same.
(foperator_unordered_gt::op1_range): Same.
(foperator_unordered_gt::op2_range): Same.
(foperator_unordered_ge::op1_range): Same.
(foperator_unordered_ge::op2_range): Same.
---
 gcc/range-op-float.cc | 47 ---
 1 file changed, 26 insertions(+), 21 deletions(-)

diff --git a/gcc/range-op-float.cc b/gcc/range-op-float.cc
index e7334794b0d..0605a908684 100644
--- a/gcc/range-op-float.cc
+++ b/gcc/range-op-float.cc
@@ -239,7 +239,9 @@ frange_add_zeros (frange &r, tree type)
 }
 }
 
-// Build a range that is <= VAL and store it in R.
+// Build a range that is <= VAL and store it in R.  Return TRUE if
+// further changes may be needed for R, or FALSE if R is in its final
+// form.
 
 static bool
 build_le (frange &r, tree type, const frange &val)
@@ -255,7 +257,9 @@ build_le (frange &r, tree type, const frange &val)
   return true;
 }
 
-// Build a range that is < VAL and store it in R.
+// Build a range that is < VAL and store it in R.  Return TRUE if
+// further changes may be needed for R, or FALSE if R is in its final
+// form.
 
 static bool
 build_lt (frange &r, tree type, const frange &val)
@@ -277,7 +281,9 @@ build_lt (frange &r, tree type, const frange &val)
   return true;
 }
 
-// Build a range that is >= VAL and store it in R.
+// Build a range that is >= VAL and store it in R.  Return TRUE if
+// further changes may be needed for R, or FALSE if R is in its final
+// form.
 
 static bool
 build_ge (frange &r, tree type, const frange &val)
@@ -293,7 +299,9 @@ build_ge (frange &r, tree type, const frange &val)
   return true;
 }
 
-// Build a range that is > VAL and store it in R.
+// Build a range that is > VAL and store it in R.  Return TRUE if
+// further changes may be needed for R, or FALSE if R is in its final
+// form.
 
 static bool
 build_gt (frange &r, tree type, const frange &val)
@@ -979,11 +987,8 @@ foperator_ge::op2_range (frange &r, tree type,
   // The TRUE side of NAN >= x is unreachable.
   if (op1.known_isnan ())
r.set_undefined ();
-  else
-   {
- build_le (r, type, op1);
- r.clear_nan ();
-   }
+  else if (build_le (r, type, op1))
+   r.clear_nan ();
   break;
 
 case BRS_FALSE:
@@ -1354,8 +1359,8 @@ foperator_unordered_le::op1_range (frange &r, tree type,
   break;
 
 case BRS_FALSE:
-  build_gt (r, type, op2);
-  r.clear_nan ();
+  if (build_gt (r, type, op2))
+   r.clear_nan ();
   break;
 
 default:
@@ -1378,8 +1383,8 @@ foperator_unordered_le::op2_range (frange &r,
   break;
 
 case BRS_FALSE:
-  build_lt (r, type, op1);
-  r.clear_nan ();
+  if (build_lt (r, type, op1))
+   r.clear_nan ();
   break;
 
 default:
@@ -1437,8 +1442,8 @@ foperator_unordered_gt::op1_range (frange &r,
   break;
 
 case BRS_FALSE:
-  build_le (r, type, op2);
-  r.clear_nan ();
+  if (build_le (r, type, op2))
+   r.clear_nan ();
   break;
 
 default:
@@ -1461,8 +1466,8 @@ foperator_unordered_gt::op2_range (frange &r,
   break;
 
 case BRS_FALSE:
-  build_ge (r, type, op1);
-  r.clear_nan ();
+  if (build_ge (r, type, op1))
+   r.clear_nan ();
   break;
 
 default:
@@ -1520,8 +1525,8 @@ foperator_unordered_ge::op1_range (frange &r,
   break;
 
 case BRS_FALSE:
-  build_lt (r, type, op2);
-  r.clear_nan ();
+  if (build_lt (r, type, op2))
+   r.clear_nan ();
   break;
 
 default:
@@ -1543,8 +1548,8 @@ foperator_unordered_ge::op2_range (frange &r, tree type,
   break;
 
 case BRS_FALSE:
-  build_gt (r, type, op1);
-  r.clear_nan ();
+  if (build_gt (r, type, op1))
+   r.clear_nan ();
   break;
 
 default:
-- 
2.37.3

Re: [PATCH 1/2] Add a parameter for the builtin function of prefetch to align with LLVM

[Segher Boessenkool]

On Wed, Oct 19, 2022 at 10:14:28AM -0700, Andrew Pinski wrote:
> Do the testcases really need to be changed rather than adding new testcases?
> Usually it is better if the testcases not change unless really needed
> to be. That is do these testcases pass without being changed? If not
> this seems not backwards compatible change and is not something which
> we should do.  Otherwise you should just add new testcases instead.

Yes, that is another reason why adding parameters to random builtins is
not a good idea :-)  s/random/only vaguely related/, if you want.

This also makes all existing code using these builtins invalid.  If you
need such testcase changes, that is a red flag.


Segher

Re: [PATCH 1/2] Add a parameter for the builtin function of prefetch to align with LLVM

[Segher Boessenkool]

On Fri, Oct 14, 2022 at 04:34:05PM +0800, Haochen Jiang wrote:
>   * config/s390/s390.cc (s390_expand_cpymem): Generate fourth parameter 
> for

(Many too long lines here, this is the first one.  Changelog lines are
max. 80 positions; a tab is eight).

> +  /* Argument 3 must be either zero or one.  */
> +  if (INTVAL (op3) != 0 && INTVAL (op3) != 1)
> +{
> +  warning (0, "invalid fourth argument to %<__builtin_prefetch%>;"
> + " using one");

"using 1" makes sense maybe, but "using one" reads as "using an
argument", not very sane.

An error would be better here anyway?

> --- a/gcc/config/rs6000/rs6000.md
> +++ b/gcc/config/rs6000/rs6000.md
> @@ -14060,10 +14060,25 @@
>DONE;
>  })
>  
> -(define_insn "prefetch"
> +(define_expand "prefetch"
> +  [(prefetch (match_operand 0 "indexed_or_indirect_address")
> +  (match_operand:SI 1 "const_int_operand")
> +  (match_operand:SI 2 "const_int_operand")
> +  (match_operand:SI 3 "const_int_operand"))]
> +  ""
> +{
> +  if (INTVAL (operands[3]) == 0)
> +  {

Broken indentation.

> +warning (0, "instruction prefetch is not supported; using data 
> prefetch");

Please use a separate pattern for this, and leave prefetch to mean data
prefetch, as documented!  Documentation you didn't change btw.  Call the
new one instruction_prefetch or something equally boring maybe :-)

When you send an updated patch, please split it up better?  Generic
changes and documentation in one patch, target changes in a separate
patch or patches, and testsuite is distinct as well.  It isn't nice to
have to scroll through thousands of lines to see if there is anything
relevant to you.

Thanks,


Segher

[committed] analyzer: fix ICE on __builtin_ms_va_copy [PR105765]

[David Malcolm via Gcc-patches]

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r13-3390-gebe87edadc4a3f.

gcc/analyzer/ChangeLog:
PR analyzer/105765
* varargs.cc (get_BT_VALIST_ARG): Rename to...
(get_va_copy_arg): ...this, and update logic for determining level
of indirection of va_copy's argument to use type of argument,
rather than looking at va_list_type_node, to correctly handle
__builtin_ms_va_copy.
(get_stateful_BT_VALIST_ARG): Rename to...
(get_stateful_va_copy_arg): ...this.
(va_list_state_machine::on_va_copy): Update for renaming.
(region_model::impl_call_va_copy): Likewise.

gcc/testsuite/ChangeLog:
PR analyzer/105765
* gcc.dg/analyzer/stdarg-1-ms_abi.c: New test, based on stdarg-1.c.
* gcc.dg/analyzer/stdarg-1-sysv_abi.c: Likewise.

Signed-off-by: David Malcolm 
---
 gcc/analyzer/varargs.cc   |  39 +-
 .../gcc.dg/analyzer/stdarg-1-ms_abi.c | 437 ++
 .../gcc.dg/analyzer/stdarg-1-sysv_abi.c   | 437 ++
 3 files changed, 897 insertions(+), 16 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/analyzer/stdarg-1-ms_abi.c
 create mode 100644 gcc/testsuite/gcc.dg/analyzer/stdarg-1-sysv_abi.c

diff --git a/gcc/analyzer/varargs.cc b/gcc/analyzer/varargs.cc
index b2e6cd53c06..20c83dbbadc 100644
--- a/gcc/analyzer/varargs.cc
+++ b/gcc/analyzer/varargs.cc
@@ -132,7 +132,7 @@ namespace ana {
  __builtin_va_start (&ap, [...]);
 
except for the 2nd param of __builtin_va_copy, where the type
-   is already target-dependent (see the discussion of BT_VALIST_ARG
+   is already target-dependent (see the discussion of get_va_copy_arg
below).  */
 
 /* Get a tree for diagnostics.
@@ -147,26 +147,33 @@ get_va_list_diag_arg (tree va_list_tree)
   return va_list_tree;
 }
 
-/* Get argument ARG_IDX of type BT_VALIST_ARG (for use by va_copy).
+/* Get argument ARG_IDX of va_copy.
 
builtin-types.def has:
  DEF_PRIMITIVE_TYPE (BT_VALIST_ARG, va_list_arg_type_node)
 
and c_common_nodes_and_builtins initializes va_list_arg_type_node
based on whether TREE_CODE (va_list_type_node) is of ARRAY_TYPE or
-   not, giving either one or zero levels of indirection.  */
+   not, giving either one or zero levels of indirection.
+
+   Alternatively we could be dealing with __builtin_ms_va_copy or
+   __builtin_sysv_va_copy.
+
+   Handle this by looking at the types of the argument in question.  */
 
 static const svalue *
-get_BT_VALIST_ARG (const region_model *model,
-  region_model_context *ctxt,
-  const gcall *call,
-  unsigned arg_idx)
+get_va_copy_arg (const region_model *model,
+region_model_context *ctxt,
+const gcall *call,
+unsigned arg_idx)
 {
   tree arg = gimple_call_arg (call, arg_idx);
   const svalue *arg_sval = model->get_rvalue (arg, ctxt);
   if (const svalue *cast = arg_sval->maybe_undo_cast ())
 arg_sval = cast;
-  if (TREE_CODE (va_list_type_node) == ARRAY_TYPE)
+  /* Expect a POINTER_TYPE; does it point to an array type?  */
+  gcc_assert (TREE_CODE (TREE_TYPE (arg)) == POINTER_TYPE);
+  if (TREE_CODE (TREE_TYPE (TREE_TYPE (arg))) == ARRAY_TYPE)
 {
   /* va_list_arg_type_node is a pointer to a va_list;
 return *ARG_SVAL.  */
@@ -551,19 +558,19 @@ va_list_state_machine::check_for_ended_va_list 
(sm_context *sm_ctxt,
 usage_fnname));
 }
 
-/* Get the svalue with associated va_list_state_machine state for a
-   BT_VALIST_ARG for ARG_IDX of CALL, if SM_CTXT supports this,
+/* Get the svalue with associated va_list_state_machine state for
+   ARG_IDX of CALL to va_copy, if SM_CTXT supports this,
or NULL otherwise.  */
 
 static const svalue *
-get_stateful_BT_VALIST_ARG (sm_context *sm_ctxt,
-   const gcall *call,
-   unsigned arg_idx)
+get_stateful_va_copy_arg (sm_context *sm_ctxt,
+ const gcall *call,
+ unsigned arg_idx)
 {
   if (const program_state *new_state = sm_ctxt->get_new_program_state ())
 {
   const region_model *new_model = new_state->m_region_model;
-  const svalue *arg = get_BT_VALIST_ARG (new_model, NULL, call, arg_idx);
+  const svalue *arg = get_va_copy_arg (new_model, NULL, call, arg_idx);
   return arg;
 }
   return NULL;
@@ -576,7 +583,7 @@ va_list_state_machine::on_va_copy (sm_context *sm_ctxt,
   const supernode *node,
   const gcall *call) const
 {
-  const svalue *src_arg = get_stateful_BT_VALIST_ARG (sm_ctxt, call, 1);
+  const svalue *src_arg = get_stateful_va_copy_arg (sm_ctxt, call, 1);
   if (src_arg)
 check_for_ended_va_list (sm_ctxt, node, call, src_arg, "va_copy");
 
@@ -686,7 +693,7 @@ region_model::impl_call_va_copy (const call_details &cd

Re: [PATCH 0/2] Add a Fourth parameter for prefetch and Support Intel PREFETCHI

[Segher Boessenkool]

On Fri, Oct 14, 2022 at 04:34:04PM +0800, Haochen Jiang wrote:
> Sorry for the previous cover-letter stucking and disturbance and this
> is the right cover letter.

Hi!

Nothing in this cover letter tells me why you sent it to me?  Maybe you
shouldn't have at all, just one patch touches Power code, or such?


Segher

[PATCH] Fortran: error recovery with references of bad array constructors [PR105633]

[Harald Anlauf via Gcc-patches]

Dear Fortranners,

here's another patch that improves error receovery with references
of bad array constructors leading to an ICE after a NULL pointer
dereference.

Original patch by Steve, which I amended with a logic cleanup.

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

Thanks,
Harald

From 0da12c71a6ccbefa1456be5759974a4b450c78e6 Mon Sep 17 00:00:00 2001
From: Harald Anlauf 
Date: Wed, 19 Oct 2022 22:37:56 +0200
Subject: [PATCH] Fortran: error recovery with references of bad array
 constructors [PR105633]

gcc/fortran/ChangeLog:

	PR fortran/105633
	* expr.cc (find_array_section): Move check for NULL pointers so
	that both subscript triplets and vector subscripts are covered.

gcc/testsuite/ChangeLog:

	PR fortran/105633
	* gfortran.dg/pr105633.f90: New test.

Co-authored-by: Steven G. Kargl 
---
 gcc/fortran/expr.cc| 10 +++---
 gcc/testsuite/gfortran.dg/pr105633.f90 |  8 
 2 files changed, 15 insertions(+), 3 deletions(-)
 create mode 100644 gcc/testsuite/gfortran.dg/pr105633.f90

diff --git a/gcc/fortran/expr.cc b/gcc/fortran/expr.cc
index 290ddf360c8..69d0b57c688 100644
--- a/gcc/fortran/expr.cc
+++ b/gcc/fortran/expr.cc
@@ -1552,6 +1552,12 @@ find_array_section (gfc_expr *expr, gfc_ref *ref)
   lower = ref->u.ar.as->lower[d];
   upper = ref->u.ar.as->upper[d];

+  if (!lower || !upper)
+	{
+	  t = false;
+	  goto cleanup;
+	}
+
   if (ref->u.ar.dimen_type[d] == DIMEN_VECTOR)  /* Vector subscript.  */
 	{
 	  gfc_constructor *ci;
@@ -1594,9 +1600,7 @@ find_array_section (gfc_expr *expr, gfc_ref *ref)
 	{
 	  if ((begin && begin->expr_type != EXPR_CONSTANT)
 	  || (finish && finish->expr_type != EXPR_CONSTANT)
-	  || (step && step->expr_type != EXPR_CONSTANT)
-	  || !lower
-	  || !upper)
+	  || (step && step->expr_type != EXPR_CONSTANT))
 	{
 	  t = false;
 	  goto cleanup;
diff --git a/gcc/testsuite/gfortran.dg/pr105633.f90 b/gcc/testsuite/gfortran.dg/pr105633.f90
new file mode 100644
index 000..f2dbc5e742a
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr105633.f90
@@ -0,0 +1,8 @@
+! { dg-do compile }
+! PR fortran/105633 - ICE in find_array_section
+! Contributed by G.Steinmetz
+
+program p
+  integer, parameter :: a(:) = [1,2] ! { dg-error "deferred shape" }
+  print *, [a([1,2])]
+end
--
2.35.3

Re: Adding a new thread model to GCC

[Bernhard Reutner-Fischer via Gcc-patches]

On Wed, 19 Oct 2022 at 15:56, Jonathan Yong via Gcc-patches
 wrote:

> Just pushed to master branch.

Wouldn't you want to cut down on the libs respectively refine the
order of the libs, though?
You've now got:
+#define MCFGTHREAD_SPEC  " -lmcfgthread -lkernel32 -lntdll "
+#else
+#define MCFGTHREAD_SPEC  ""
+#endif
 #undef REAL_LIBGCC_SPEC
 #define REAL_LIBGCC_SPEC \
   "%{mthreads:-lmingwthrd} -lmingw32 \
" SHARED_LIBGCC_SPEC " \
-   -lmoldname -lmingwex -lmsvcrt -lkernel32"
+   -lmoldname -lmingwex -lmsvcrt -lkernel32 " MCFGTHREAD_SPEC

which has kernel32 twice, which might not be ideal for the speed of linking?
I'm not familiar with the content of ntdll so cannot judge if you'd put that in
MCFGTHREAD_SPEC and drop kernel32 there, though, and put the whole
MCFG spec simply before the kernel32 in the REAL_LIBGCC_SPEC.

i.e.
+#define MCFGTHREAD_SPEC  " -lmcfgthread -lntdll "
...
+   -lmoldname -lmingwex -lmsvcrt " MCFGTHREAD_SPEC " -lkernel32 "

I hope this is constructive.
thanks,

Re: [PATCH v2] c++: Mitigate -Wuseless-cast with classes [PR85043]

[Marek Polacek via Gcc-patches]

On Wed, Oct 19, 2022 at 02:37:23PM -0400, Jason Merrill wrote:
> On 10/19/22 12:38, Marek Polacek wrote:
> > On Wed, Oct 19, 2022 at 09:27:27AM -0400, Jason Merrill wrote:
> > > On 10/18/22 13:38, Marek Polacek wrote:
> > > > -Wuseless-cast (not part of -Wall/-Wextra) warns here:
> > > > 
> > > > struct S { };
> > > > void g (S&&);
> > > > void f (S&& arg)
> > > > {
> > > >   g (S(arg)); // warning: useless cast to type 'struct S'
> > > > }
> > > > 
> > > > which is wrong: the code will not compile without the cast because
> > > > "arg" is an lvalue which cannot bind to S&&.
> > > > 
> > > > I'd like to disable the warning when a class object is cast to
> > > > a non-reference type, which seems like a minimal patch that fixes the
> > > > problems reported in our Bugzilla.  Of course, the cast in "(int)i"
> > > > may not be useless, either, but I'm not changing that here.
> > > 
> > > As I commented on PR 14710, "I wouldn't warn about a cast that changes the
> > > type or value category of an expression at all"
> > 
> > Ah, I didn't see that comment.
> > 
> > > The code currently checks the value category when casting to a reference,
> > > but not when casting to a non-reference; that seems like the thing to fix.
> > 
> > OK, how about this?  The nice thing is that it handles non-classes as well,
> > while we still warn about truly useless casts as in "X(X{})".  Thanks,
> > 
> > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> > 
> > -- >8 --
> > -Wuseless-cast (not part of -Wall/-Wextra) warns here:
> > 
> >struct S { };
> >void g (S&&);
> >void f (S&& arg)
> >{
> >  g (S(arg)); // warning: useless cast to type 'struct S'
> >}
> > 
> > which is wrong: the code will not compile without the cast because
> > "arg" is an lvalue which cannot bind to S&&.
> > 
> > This patch disables the warning when an object that isn't a prvalue
> > is cast to a non-reference type.  Therefore we still warn about the
> > useless cast in "X(X{})".
> > 
> > PR c++/85043
> > 
> > gcc/cp/ChangeLog:
> > 
> > * typeck.cc (maybe_warn_about_useless_cast): Don't warn when
> > a glvalue is cast to a non-reference type.
> > 
> > gcc/ChangeLog:
> > 
> > * doc/invoke.texi: Update documentation of -Wuseless-cast.
> > 
> > gcc/testsuite/ChangeLog:
> > 
> > * g++.dg/warn/Wuseless-cast.C: Remove dg-warning.
> > * g++.dg/warn/Wuseless-cast3.C: New test.
> > ---
> >   gcc/cp/typeck.cc   |  4 ++-
> >   gcc/doc/invoke.texi| 13 +-
> >   gcc/testsuite/g++.dg/warn/Wuseless-cast.C  | 12 -
> >   gcc/testsuite/g++.dg/warn/Wuseless-cast3.C | 29 ++
> >   4 files changed, 50 insertions(+), 8 deletions(-)
> >   create mode 100644 gcc/testsuite/g++.dg/warn/Wuseless-cast3.C
> > 
> > diff --git a/gcc/cp/typeck.cc b/gcc/cp/typeck.cc
> > index da0e1427b97..8e1d14ee6b0 100644
> > --- a/gcc/cp/typeck.cc
> > +++ b/gcc/cp/typeck.cc
> > @@ -8108,7 +8108,9 @@ maybe_warn_about_useless_cast (location_t loc, tree 
> > type, tree expr,
> >&& (TYPE_REF_IS_RVALUE (type)
> >? xvalue_p (expr) : lvalue_p (expr))
> >&& same_type_p (TREE_TYPE (expr), TREE_TYPE (type)))
> > - || same_type_p (TREE_TYPE (expr), type))
> > + /* Don't warn when converting a class object to a non-reference type,
> > +because that's a common way to create a temporary.  */
> > + || (!glvalue_p (expr) && same_type_p (TREE_TYPE (expr), type)))
> 
> Might use ?: instead of || so we check this only when !TYPE_REF_P.  OK with
> that change.

Ah nice, pushed with this instead of the ||:

  if (TYPE_REF_P (type)
  ? ((TYPE_REF_IS_RVALUE (type)
  ? xvalue_p (expr) : lvalue_p (expr))
 && same_type_p (TREE_TYPE (expr), TREE_TYPE (type)))
  /* Don't warn when converting a class object to a non-reference type,
 because that's a common way to create a temporary.  */
  : (!glvalue_p (expr) && same_type_p (TREE_TYPE (expr), type)))


Thanks,

Marek

[PATCH] libstdc++: Enable _GLIBCXX_WEAK_DEFINITION on more platforms

[Arsen Arsenović via Gcc-patches]

This should permit redefining `operator new' where-ever that is
possible, and should allow libsupc++ to be more broadly useful in
freestanding.

libstdc++-v3/ChangeLog:

* acinclude.m4: Add link test for __attribute__ ((weak)).
* config.h.in: Regenerate.
* config/os/bsd/darwin/os_defines.h (_GLIBCXX_WEAK_DEFINITION):
Remove.  It's defined by configure.ac now, depending on a link
test and host configuration.
* configure.ac: Define _GLIBCXX_WEAK_DEFINITION according to
link test and configure.host/crossconfig.
* configure: Regenerate.
* configure.host: Set force_enable_attr_weak for ELF and Darwin
targets.
* include/bits/c++config: Remove redundant
_GLIBCXX_WEAK_DEFINITION default.
---
Evening,

This patch should permit more targets to redefine operators new and delete, and
any other function we might see fit in the future.
There's currently a few points of discussion/consideration here, most notably,
can giving a bunch of targets weak definitions of operators new and delete be
considered an ABI break?  If so, the link test should be dropped in favor of
targets enabling it explicitly (which is useful for new targets, e.g. a
kernel).  The only hypothetical I could think of ``going wrong'' is a link test
that attempts to detect whether operators new/delete can be redefined, and if
so, changes program behaviour in some way, but I've never observed this, and I
fail to come up with why a silent fallback would be useful in such a case.
Second (though, worthy of it's own patchset) point would be considering whether
any other functions in libsupc++ should be weak.

WDYT?

Thanks.

 libstdc++-v3/acinclude.m4  | 10 ++
 libstdc++-v3/config.h.in   |  3 +++
 libstdc++-v3/config/os/bsd/darwin/os_defines.h |  6 --
 libstdc++-v3/configure.ac  | 15 +++
 libstdc++-v3/configure.host| 12 
 libstdc++-v3/include/bits/c++config|  7 ---
 6 files changed, 40 insertions(+), 13 deletions(-)

diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4
index 6523ba9a816..f3976cf80f4 100644
--- a/libstdc++-v3/acinclude.m4
+++ b/libstdc++-v3/acinclude.m4
@@ -273,6 +273,16 @@ AC_DEFUN([GLIBCXX_CHECK_LINKER_FEATURES], [
 fi
   fi
 
+  # Detect weak function support.
+  AC_CACHE_CHECK([whether __attribute__ ((weak)) works],
+ [glibcxx_cv_can_use_attr_weak], [
+AC_LINK_IFELSE(
+  [AC_LANG_PROGRAM([__attribute__ ((weak)) void f() {}], [])],
+  [glibcxx_cv_can_use_attr_weak=yes],
+  [glibcxx_cv_can_use_attr_weak=no])
+  ])
+  AC_MSG_RESULT($glibcxx_cv_can_use_attr_weak)
+
   # Set -z,relro.
   # Note this is only for shared objects.
   ac_ld_relro=no
diff --git a/libstdc++-v3/config.h.in b/libstdc++-v3/config.h.in
index 2a3972eef54..11467d28417 100644
--- a/libstdc++-v3/config.h.in
+++ b/libstdc++-v3/config.h.in
@@ -1046,6 +1046,9 @@
 /* Define to 1 if a verbose library is built, or 0 otherwise. */
 #undef _GLIBCXX_VERBOSE
 
+/* Marks a definition as weak, if supported. */
+#undef _GLIBCXX_WEAK_DEFINITION
+
 /* Defined if as can handle rdrand. */
 #undef _GLIBCXX_X86_RDRAND
 
diff --git a/libstdc++-v3/config/os/bsd/darwin/os_defines.h 
b/libstdc++-v3/config/os/bsd/darwin/os_defines.h
index a8b6d4fa324..ac6dd0faaad 100644
--- a/libstdc++-v3/config/os/bsd/darwin/os_defines.h
+++ b/libstdc++-v3/config/os/bsd/darwin/os_defines.h
@@ -33,12 +33,6 @@
links to, so there's no need for weak-ness for that.  */
 #define _GLIBCXX_GTHREAD_USE_WEAK 0
 
-// On Darwin, in order to enable overriding of operator new and delete,
-// GCC makes the definition of these functions weak, relies on the
-// loader to implement weak semantics properly, and uses
-// -flat_namespace to work around the way that it doesn't.
-#define _GLIBCXX_WEAK_DEFINITION __attribute__ ((weak))
-
 // Static initializer macro is buggy in darwin, see libstdc++/51906
 #define _GTHREAD_USE_RECURSIVE_MUTEX_INIT_FUNC
 
diff --git a/libstdc++-v3/configure.ac b/libstdc++-v3/configure.ac
index 42c453099f2..81d914b434a 100644
--- a/libstdc++-v3/configure.ac
+++ b/libstdc++-v3/configure.ac
@@ -420,6 +420,21 @@ else
   fi
 fi
 
+# Now that we gave link tests and crossconfig a chance to set
+# glibcxx_cv_can_use_attr_weak, apply it.  Also, force it if configure.host
+# says so.
+should_use_attr_weak="$glibcxx_cv_can_use_attr_weak"
+if test x"$force_enable_attr_weak" != xdefault; then
+  should_use_attr_weak="$force_enable_attr_weak"
+fi
+
+if test x"$should_use_attr_weak" = xyes; then
+  AC_DEFINE([_GLIBCXX_WEAK_DEFINITION], [__attribute__ ((weak))],
+[Marks a definition as weak, if supported.])
+else
+  AC_DEFINE([_GLIBCXX_WEAK_DEFINITION], [])
+fi
+
 # Check for _Unwind_GetIPInfo.
 GCC_CHECK_UNWIND_GETIPINFO
 
diff --git a/libstdc++-v3/configure.host b/libstdc++-v3/configure.host
index ec32980aa0d..85afda61ee2 100644
---

Re: [PATCH] introduce C++ API data base and generator for C++ hints

[Jason Merrill via Gcc-patches]

On 10/18/22 11:06, Ulrich Drepper wrote:
I updated the patch based on the feedback from Jason and Martin.  It 
keeps the CSV file and the python script in the cp/ directory.  There 
also is still only one Python script.


If there is agreement that either of those should change despite the 
arguments I gave in the reply to Jason's email I'll change it.  
Otherwise I think the patch is ready to be applied.


There should be no change for the non-developer, I've adjusted the 
Makefile so that no file is generated based on time stamps unless the 
maintainer mode is selected.


I added the comment about the shared ownership only to the CSV file, not 
the Python script.  The latter shouldn't need frequent updates and 
therefore the issue is less critical.


OK?


OK.

2022-10-18  Jonathan Wakely   >
             Ulrich Drepper  >


contrib/
         * gcc_update: Add rule for gcc/cp/std-name-hint.gperf.

gcc/cp/
         * Make-lang.in: Add rules to generate std-name-hint.gperf.  Adjust
         rule to generate std-name-hint.h to allow chain rule.
         * std-name-hint.h: Regenerated.
         * std-name-hint.gperf: This file is now generated.
         * cxxapi-data-.csv: New file.  CSV file with C++ API data.
         * gen-cxxapi-file.py: New file.  Generate std-name-hint.gperf
         and module export source (in future).

Re: [PATCH v3] c++: parser - Support for target address spaces in C++

[Jason Merrill via Gcc-patches]

On 10/18/22 13:01, Paul Iannetta wrote:

Thank you very much for the detailed review.

On Tue, Oct 18, 2022 at 10:24:23AM -0400, Jason Merrill wrote:

On 10/18/22 03:37, Paul Iannetta wrote:

On Fri, Oct 14, 2022 at 11:19:50AM -0400, Jason Merrill wrote:

On 10/13/22 17:57, Paul Iannetta wrote:

On Thu, Oct 13, 2022 at 03:41:16PM -0400, Jason Merrill wrote:

On 10/13/22 12:02, Paul Iannetta wrote:

On Thu, Oct 13, 2022 at 11:47:42AM -0400, Jason Merrill wrote:

On 10/13/22 11:23, Paul Iannetta wrote:

On Thu, Oct 13, 2022 at 11:02:24AM -0400, Jason Merrill wrote:

On 10/12/22 20:52, Paul Iannetta wrote:

There are quite a few things I would like to clarify concerning some
implementation details.
- A variable with automatic storage (which is neither a pointer nor
  a reference) cannot be qualified with an address space.  I detect
  this by the combination of `sc_none' and `! toplevel_bindings_p ()',
  but I've also seen the use of `at_function_scope' at other places.
  And I'm unsure which one is appropriate here.
  This detection happens at the very end of grokdeclarator because I
  need to know that the type is a pointer, which is not know until
  very late in the function.


At that point you have the decl, and you can ask directly what its storage
duration is, perhaps using decl_storage_duration.

But why do you need to know whether the type is a pointer?  The attribute
applies to the target type of the pointer, not the pointer type.  I think
the problem is that you're looking at declspecs when you ought to be looking
at type_quals.


I need to know that the base type is a pointer to reject invalid
declarations such as:

 int f (__seg_fs int a) { } or int f () { __seg_fs int a; }

because parameters and auto variables can have an address space
qualifier only if they are pointer or reference type, which I can't
tell only from type_quals.


But "int *__seg_fs a" is just as invalid as the above; the difference is not
whether a is a pointer, but whether the address-space-qualified is the type
of a itself or some sub-type.


I agree that "int * __seg_fs a" is invalid but it is accepted by the C
front-end, and by clang (both C and C++), the behavior is that the
address-name is silently ignored.


Hmm, that sounds like a bug; in that case, presumably the user meant to
qualify the pointed-to type, and silently ignoring seems unlikely to give
the effect they want.



Well, actually, I'm re-reading the draft and "int * __seg_fs a" is
valid.  It means "pointer in address space __seg_fs pointing to an
object in the generic address space", whereas "__seg_fs int * a" means
"pointer in the generic address space pointing to an object in the
__seg_fs address-space".

Oddities such as, "__seg_fs int * __seg_gs a" are also perfectly
valid.


If a has static storage duration, sure; I was still thinking about
declarations with automatic storage duration such as in your example above.



Thanks, I only use type_quals now. I also took into account the style
recommendations from Jakub, and included the other template tests.
I rebased over trunk, bootstrapped the compiler and run the "make
check-gcc" with no regressions on x86.

Paul

#  >8 
Add support for custom address spaces in C++

gcc/
  * tree.h (ENCODE_QUAL_ADDR_SPACE): Missing parentheses.

gcc/c/
  * c-decl.cc: Remove c_register_addr_space.

gcc/c-family/
  * c-common.cc (c_register_addr_space): Imported from c-decl.cc
  (addr_space_superset): Imported from gcc/c/c-typecheck.cc
  * c-common.h: Remove the FIXME.
  (addr_space_superset): New declaration.

gcc/cp/
  * cp-tree.h (enum cp_decl_spec): Add addr_space support.
  (struct cp_decl_specifier_seq): Likewise.
  * decl.cc (get_type_quals): Likewise.
  (check_tag_decl): Likewise.
(grokdeclarator): Likewise.
  * parser.cc (cp_parser_type_specifier): Likewise.
  (cp_parser_cv_qualifier_seq_opt): Likewise.
  (cp_parser_postfix_expression): Likewise.
  (cp_parser_type_specifier): Likewise.
  (set_and_check_decl_spec_loc): Likewise.
  * typeck.cc (composite_pointer_type): Likewise
  (comp_ptr_ttypes_real): Likewise.
(same_type_ignoring_top_level_qualifiers_p): Likewise.
  * pt.cc (check_cv_quals_for_unify): Likewise.
  (unify): Likewise.
  * tree.cc: Remove c_register_addr_space stub.
  * mangle.cc (write_CV_qualifiers_for_type): Mangle address spaces
using the extended qualifier notation.

gcc/doc
  * extend.texi (Named Address Spaces): add a mention about C++
support.

gcc/testsuite/
  * g++.dg/abi/mangle-addr-space1.C: New test.
  * g++.dg/abi/mangle-addr-space2.C: New test.
  * g++.dg/parse/addr-space.C: New test.
  * g++.dg/parse/addr-space1.C: Ne

[r13-3360 Regression] FAIL: gcc.dg/c2x-enum-1.c (test for excess errors) on Linux/x86_64

[haochen.jiang via Gcc-patches]

On Linux/x86_64,

3b3083a598ca3f4b6203284e01ed39ab6ff0844f is the first bad commit
commit 3b3083a598ca3f4b6203284e01ed39ab6ff0844f
Author: Joseph Myers 
Date:   Tue Oct 18 14:07:27 2022 +

c: C2x enums wider than int [PR36113]

caused

FAIL: gcc.dg/c2x-enum-1.c (test for excess errors)

with GCC configured with

../../gcc/configure 
--prefix=/export/users/haochenj/src/gcc-bisect/master/master/r13-3360/usr 
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld 
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl 
--enable-libmpx x86_64-linux --disable-bootstrap

To reproduce:

$ cd {build_dir}/gcc && make check RUNTESTFLAGS="dg.exp=gcc.dg/c2x-enum-1.c 
--target_board='unix{-m32}'"
$ cd {build_dir}/gcc && make check RUNTESTFLAGS="dg.exp=gcc.dg/c2x-enum-1.c 
--target_board='unix{-m32\ -march=cascadelake}'"

(Please do not reply to this email, for question about this report, contact me 
at haochen dot jiang at intel.com)

Re: [PATCH v2] c++: Mitigate -Wuseless-cast with classes [PR85043]

[Jason Merrill via Gcc-patches]

On 10/19/22 12:38, Marek Polacek wrote:

On Wed, Oct 19, 2022 at 09:27:27AM -0400, Jason Merrill wrote:

On 10/18/22 13:38, Marek Polacek wrote:

-Wuseless-cast (not part of -Wall/-Wextra) warns here:

struct S { };
void g (S&&);
void f (S&& arg)
{
  g (S(arg)); // warning: useless cast to type 'struct S'
}

which is wrong: the code will not compile without the cast because
"arg" is an lvalue which cannot bind to S&&.

I'd like to disable the warning when a class object is cast to
a non-reference type, which seems like a minimal patch that fixes the
problems reported in our Bugzilla.  Of course, the cast in "(int)i"
may not be useless, either, but I'm not changing that here.


As I commented on PR 14710, "I wouldn't warn about a cast that changes the
type or value category of an expression at all"


Ah, I didn't see that comment.


The code currently checks the value category when casting to a reference,
but not when casting to a non-reference; that seems like the thing to fix.


OK, how about this?  The nice thing is that it handles non-classes as well,
while we still warn about truly useless casts as in "X(X{})".  Thanks,

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

-- >8 --
-Wuseless-cast (not part of -Wall/-Wextra) warns here:

   struct S { };
   void g (S&&);
   void f (S&& arg)
   {
 g (S(arg)); // warning: useless cast to type 'struct S'
   }

which is wrong: the code will not compile without the cast because
"arg" is an lvalue which cannot bind to S&&.

This patch disables the warning when an object that isn't a prvalue
is cast to a non-reference type.  Therefore we still warn about the
useless cast in "X(X{})".

PR c++/85043

gcc/cp/ChangeLog:

* typeck.cc (maybe_warn_about_useless_cast): Don't warn when
a glvalue is cast to a non-reference type.

gcc/ChangeLog:

* doc/invoke.texi: Update documentation of -Wuseless-cast.

gcc/testsuite/ChangeLog:

* g++.dg/warn/Wuseless-cast.C: Remove dg-warning.
* g++.dg/warn/Wuseless-cast3.C: New test.
---
  gcc/cp/typeck.cc   |  4 ++-
  gcc/doc/invoke.texi| 13 +-
  gcc/testsuite/g++.dg/warn/Wuseless-cast.C  | 12 -
  gcc/testsuite/g++.dg/warn/Wuseless-cast3.C | 29 ++
  4 files changed, 50 insertions(+), 8 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/warn/Wuseless-cast3.C

diff --git a/gcc/cp/typeck.cc b/gcc/cp/typeck.cc
index da0e1427b97..8e1d14ee6b0 100644
--- a/gcc/cp/typeck.cc
+++ b/gcc/cp/typeck.cc
@@ -8108,7 +8108,9 @@ maybe_warn_about_useless_cast (location_t loc, tree type, 
tree expr,
   && (TYPE_REF_IS_RVALUE (type)
   ? xvalue_p (expr) : lvalue_p (expr))
   && same_type_p (TREE_TYPE (expr), TREE_TYPE (type)))
- || same_type_p (TREE_TYPE (expr), type))
+ /* Don't warn when converting a class object to a non-reference type,
+because that's a common way to create a temporary.  */
+ || (!glvalue_p (expr) && same_type_p (TREE_TYPE (expr), type)))


Might use ?: instead of || so we check this only when !TYPE_REF_P.  OK 
with that change.



warning_at (loc, OPT_Wuseless_cast,
"useless cast to type %q#T", type);
  }
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index c176e2dc646..cd4d3c1d72c 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -4551,7 +4551,18 @@ pointers after reallocation.
  @item -Wuseless-cast @r{(C++ and Objective-C++ only)}
  @opindex Wuseless-cast
  @opindex Wno-useless-cast
-Warn when an expression is casted to its own type.
+Warn when an expression is cast to its own type.  This warning does not
+occur when a class object is converted to a non-reference type as that
+is a way to create a temporary:
+
+@smallexample
+struct S @{ @};
+void g (S&&);
+void f (S&& arg)
+@{
+  g (S(arg)); // make arg prvalue so that it can bind to S&&
+@}
+@end smallexample
  
  @item -Wno-conversion-null @r{(C++ and Objective-C++ only)}

  @opindex Wconversion-null
diff --git a/gcc/testsuite/g++.dg/warn/Wuseless-cast.C 
b/gcc/testsuite/g++.dg/warn/Wuseless-cast.C
index 2fd6bc45102..d7cb89930a6 100644
--- a/gcc/testsuite/g++.dg/warn/Wuseless-cast.C
+++ b/gcc/testsuite/g++.dg/warn/Wuseless-cast.C
@@ -62,11 +62,11 @@ A prvalue();
  
  void f()

  {
-  int n;
+  int n;
  
-  (int)(n);// { dg-warning "3:useless cast" }

-  static_cast(n); // { dg-warning "3:useless cast" }
-  reinterpret_cast(n);// { dg-warning "3:useless cast" }
+  (int)(n);
+  static_cast(n);
+  reinterpret_cast(n);
  
(int*)(&n);  // { dg-warning "3:useless cast" }

const_cast(&n);// { dg-warning "3:useless cast" }
@@ -100,8 +100,8 @@ void f()
  
A a;
  
-  (A)(a); // { dg-warning "3:useless cast" }

-  static_cast(a);  // { dg-warning "3:useless cast" }
+  (A)(a);
+  static_cast(a);
  
(A*

Re: [PATCH] libstdc++: Implement P2474R2 changes to views::take/drop

[Jonathan Wakely via Gcc-patches]

On Wed, 19 Oct 2022, 17:47 Patrick Palka via Libstdc++, <
libstd...@gcc.gnu.org> wrote:

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

OK



> libstdc++-v3/ChangeLog:
>
> * include/std/ranges (views::__detail::__is_repeat_view): Define
> and later define a partial specialization.
> (views::__detail::__take_of_repeat_view): Declare and later define.
> (views::__detail::__drop_of_repeat_view): Likewise.
> (views::_Take::operator()): Return a repeat_view if the argument
> is a repeat_view as per P2474R2.
> (views::_Drop::operator()): Likewise.
> (repeat_view): Befriend __take/drop_of_repeat_view.
> * testsuite/std/ranges/repeat/1.cc (test04): New test.
> ---
>  libstdc++-v3/include/std/ranges   | 56 +++
>  libstdc++-v3/testsuite/std/ranges/repeat/1.cc | 33 +++
>  2 files changed, 89 insertions(+)
>
> diff --git a/libstdc++-v3/include/std/ranges
> b/libstdc++-v3/include/std/ranges
> index b29264931cc..6de08244bd1 100644
> --- a/libstdc++-v3/include/std/ranges
> +++ b/libstdc++-v3/include/std/ranges
> @@ -2257,6 +2257,13 @@ namespace views::__adaptor
>template
> inline constexpr bool __is_iota_view> =
> true;
>
> +  template
> +   inline constexpr bool __is_repeat_view = false;
> +
> +  template
> +   constexpr auto
> +   __take_of_repeat_view(_Range&&, range_difference_t<_Range>); //
> defined later
> +
>template
> concept __can_take_view
>   = requires { take_view(std::declval<_Range>(),
> std::declval<_Dp>()); };
> @@ -2291,6 +2298,8 @@ namespace views::__adaptor
>   else
> return iota_view(*__begin, *__end);
> }
> + else if constexpr (__detail::__is_repeat_view<_Tp>)
> +   return
> __detail::__take_of_repeat_view(std::forward<_Range>(__r), __n);
>   else
> return take_view(std::forward<_Range>(__r), __n);
> }
> @@ -2527,6 +2536,10 @@ namespace views::__adaptor
>{
>  namespace __detail
>  {
> +  template
> +   constexpr auto
> +   __drop_of_repeat_view(_Range&&, range_difference_t<_Range>); //
> defined later
> +
>template
> concept __can_drop_view
>   = requires { drop_view(std::declval<_Range>(),
> std::declval<_Dp>()); };
> @@ -2568,6 +2581,8 @@ namespace views::__adaptor
>   else
> return _Tp(__begin, __end);
> }
> + else if constexpr (__detail::__is_repeat_view<_Tp>)
> +   return
> __detail::__drop_of_repeat_view(std::forward<_Range>(__r), __n);
>   else
> return drop_view(std::forward<_Range>(__r), __n);
> }
> @@ -7367,6 +7382,14 @@ namespace views::__adaptor
>
>  struct _Iterator;
>
> +template
> +  friend constexpr auto
> +  views::__detail::__take_of_repeat_view(_Range&&,
> range_difference_t<_Range>);
> +
> +template
> +  friend constexpr auto
> +  views::__detail::__drop_of_repeat_view(_Range&&,
> range_difference_t<_Range>);
> +
>public:
>  repeat_view() requires default_initializable<_Tp> = default;
>
> @@ -7540,6 +7563,9 @@ namespace views::__adaptor
>{
>  namespace __detail
>  {
> +  template
> +   inline constexpr bool __is_repeat_view> =
> true;
> +
>template
> concept __can_repeat_view
>   = requires { repeat_view(std::declval<_Tp>()); };
> @@ -7565,6 +7591,36 @@ namespace views::__adaptor
>  };
>
>  inline constexpr _Repeat repeat;
> +
> +namespace __detail
> +{
> +  template
> +   constexpr auto
> +   __take_of_repeat_view(_Range&& __r, range_difference_t<_Range> __n)
> +   {
> + using _Tp = remove_cvref_t<_Range>;
> + static_assert(__is_repeat_view<_Tp>);
> + if constexpr (sized_range<_Tp>)
> +   return views::repeat(*__r._M_value,
> std::min(ranges::distance(__r), __n));
> + else
> +   return views::repeat(*__r._M_value, __n);
> +   }
> +
> +  template
> +   constexpr auto
> +   __drop_of_repeat_view(_Range&& __r, range_difference_t<_Range> __n)
> +   {
> + using _Tp = remove_cvref_t<_Range>;
> + static_assert(__is_repeat_view<_Tp>);
> + if constexpr (sized_range<_Tp>)
> +   {
> + auto __sz = ranges::distance(__r);
> + return views::repeat(*__r._M_value, __sz - std::min(__sz,
> __n));
> +   }
> + else
> +   return __r;
> +   }
> +}
>}
>
>template
> diff --git a/libstdc++-v3/testsuite/std/ranges/repeat/1.cc
> b/libstdc++-v3/testsuite/std/ranges/repeat/1.cc
> index 3698ed12c14..542c8614f88 100644
> --- a/libstdc++-v3/testsuite/std/ranges/repeat/1.cc
> +++ b/libstdc++-v3/testsuite/std/ranges/repeat/1.cc
> @@ -84,10 +84,43 @@ test03()
>return true;
>  }
>
> +constexpr bool
> +test04()
> +{
> +  // Verify P2472R2 changes 

Re: [PATCH] middle-end, v4: IFN_ASSUME support [PR106654]

[Andrew MacLeod via Gcc-patches]

On 10/19/22 13:41, Jakub Jelinek wrote:

On Wed, Oct 19, 2022 at 07:39:05PM +0200, Jakub Jelinek via Gcc-patches wrote:

On Wed, Oct 19, 2022 at 12:55:12PM -0400, Andrew MacLeod via Gcc-patches wrote:

Not sure I understand this part.  op is whatever we pass as the ith
argument to IFN_ASSUME.  I'd expect that at this point one needs to
remap that to the (i-1)th PARM_DECL of assume_id (so e.g. when you
have the above loop you could as well start with DECL_ARGUMENTS and move
that to DECL_CHAIN at the end of every iteration.  And then
query ssa_default_def (DECL_STRUCT_FUNCTION (assume_id), parm)
in each case and get global range of what that returns.

OK, this is the bit of code I dont know how to write :-)

yes, op is the name of the value within this current function, and yes, that
needs to be mapped to the argument decl in the assume function.   Then we
need to query what range was given to that name during the assume pass.
when that is returned, the add_range (op, range) will inject it as a side
effect.

Can you write that loop?

I meant something like (untested code):
&& gimple_call_internal_fn (s) == IFN_ASSUME)
  {
tree assume_id = gimple_call_arg (s, 0);
-  for (unsigned i = 1; i < gimple_call_num_args (s); i++)
+  tree parm = DECL_ARGUMENTS (assume_id);
+  struct function *fun = DECL_STRUCT_FUNCTION (assume_id);
+  for (unsigned i = 1;
+  i < gimple_call_num_args (s) && parm;
+  i++, parm = DECL_CHAIN (parm))
{
  tree op = gimple_call_arg (s, i);
  tree type = TREE_TYPE (op);
+ tree arg = ssa_default_def (fun, parm);
+ if (arg == NULL_TREE)
+   continue;
  if (gimple_range_ssa_p (op) && Value_Range::supports_type_p (type))
{
  Value_Range assume_range (type);
and querying SSA_NAME_RANGE_INFO of arg rather than op.


Thanks, I had actually come to most of those conclusions already, except 
for the DECL_STRUCT_FUNCTION bit.. I was stuck on that :-)



So the SSA_NAMEs for default_defs are never disposed of?  so I can query 
them even though they are not in the current function decl?  huh. I did 
not know that.



OK, attached is the latest set of patches.  not bootstrapped or 
anything, but very interesting.



from.assumption  pass:

;; Function _Z3bari._assume.0 (_Z3bari._assume.0, funcdef_no=5, 
decl_uid=2184, cgraph_uid=7, symbol_order=7)


Assumptions :
--
x_1(D) -> [irange] int [42, 42] NONZERO 0x2a

__attribute__((no_icf, noclone, noinline, noipa))
bool _Z3bari._assume.0 (int x)
{
  bool _2;

;;   basic block 2, loop depth 0
;;    pred:   ENTRY
  _2 = x_1(D) == 42;
  return _2;
;;    succ:   EXIT

}


and in the VRP2 pass, I see:

_Z3bari._assume.0 assume inferred range of x_1(D) (param x) = [irange] 
int [42, 42] NONZERO 0x2a

int bar (int x)
{
   [local count: 1073741824]:
  .ASSUME (_Z3bari._assume.0, x_1(D));
  return 42;

}


Huh.  lookit that.


Anyway, let me clean this up a bit more, but so far so good.

I'll try bootstrapping and  such

Andrew

From 62cc63ca8d5cce3593cdb4b35e5fe96b0ecc77a8 Mon Sep 17 00:00:00 2001
From: Andrew MacLeod 
Date: Tue, 18 Oct 2022 16:29:49 -0400
Subject: [PATCH 1/3] Infer support

---
 gcc/gimple-range-infer.cc | 40 +++
 1 file changed, 40 insertions(+)

diff --git a/gcc/gimple-range-infer.cc b/gcc/gimple-range-infer.cc
index f0d66d047a6..3e376740796 100644
--- a/gcc/gimple-range-infer.cc
+++ b/gcc/gimple-range-infer.cc
@@ -35,6 +35,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "gimple-iterator.h"
 #include "gimple-walk.h"
 #include "cfganal.h"
+#include "tree-dfa.h"
 
 // Adapted from infer_nonnull_range_by_dereference and check_loadstore
 // to process nonnull ssa_name OP in S.  DATA contains a pointer to a
@@ -111,6 +112,45 @@ gimple_infer_range::gimple_infer_range (gimple *s)
   // Fallthru and walk load/store ops now.
 }
 
+  // Look for ASSUME calls, and call query_assume_call for each argument
+  // to determine if there is any inferred range to be had.
+  if (is_a (s) && gimple_call_internal_p (s)
+  && gimple_call_internal_fn (s) == IFN_ASSUME)
+{
+  tree arg;
+  unsigned i;
+  tree assume_id = TREE_OPERAND (gimple_call_arg (s, 0), 0);
+  struct function *fun = DECL_STRUCT_FUNCTION (assume_id);
+  for (arg = DECL_ARGUMENTS (assume_id), i = 1;
+	   arg && i < gimple_call_num_args (s);
+	   i++, arg = DECL_CHAIN (arg))
+	{
+	  tree op = gimple_call_arg (s, i);
+	  tree type = TREE_TYPE (op);
+	  tree def = ssa_default_def (fun, arg);
+	  if (type != TREE_TYPE (arg) || !def)
+	continue;
+	  if (gimple_range_ssa_p (op) && Value_Range::supports_type_p (type))
+	{
+	  Value_Range assume_range (type);
+	  global_ranges.range_of_expr (assume_range, def);
+		{
+		  add_range (op, assume_range);
+		  if (dump_file)
+		{
+		  print_generic_expr (dump_file, assume_id, TDF_SLIM);
+		  fpri

Re: [PATCH] middle-end, v4: IFN_ASSUME support [PR106654]

[Jakub Jelinek via Gcc-patches]

On Wed, Oct 19, 2022 at 07:39:05PM +0200, Jakub Jelinek via Gcc-patches wrote:
> On Wed, Oct 19, 2022 at 12:55:12PM -0400, Andrew MacLeod via Gcc-patches 
> wrote:
> > > Not sure I understand this part.  op is whatever we pass as the ith
> > > argument to IFN_ASSUME.  I'd expect that at this point one needs to
> > > remap that to the (i-1)th PARM_DECL of assume_id (so e.g. when you
> > > have the above loop you could as well start with DECL_ARGUMENTS and move
> > > that to DECL_CHAIN at the end of every iteration.  And then
> > > query ssa_default_def (DECL_STRUCT_FUNCTION (assume_id), parm)
> > > in each case and get global range of what that returns.
> > 
> > OK, this is the bit of code I dont know how to write :-)
> > 
> > yes, op is the name of the value within this current function, and yes, that
> > needs to be mapped to the argument decl in the assume function.   Then we
> > need to query what range was given to that name during the assume pass. 
> > when that is returned, the add_range (op, range) will inject it as a side
> > effect.
> > 
> > Can you write that loop?
> 
> I meant something like (untested code):
>&& gimple_call_internal_fn (s) == IFN_ASSUME)
>  {
>tree assume_id = gimple_call_arg (s, 0);
> -  for (unsigned i = 1; i < gimple_call_num_args (s); i++)
> +  tree parm = DECL_ARGUMENTS (assume_id);
> +  struct function *fun = DECL_STRUCT_FUNCTION (assume_id);
> +  for (unsigned i = 1;
> +i < gimple_call_num_args (s) && parm;
> +i++, parm = DECL_CHAIN (parm))
>   {
> tree op = gimple_call_arg (s, i);
> tree type = TREE_TYPE (op);
> +   tree arg = ssa_default_def (fun, parm);
> +   if (arg == NULL_TREE)
> + continue;
> if (gimple_range_ssa_p (op) && Value_Range::supports_type_p (type))
>   {
> Value_Range assume_range (type);
> and querying SSA_NAME_RANGE_INFO of arg rather than op.

Oops, the tree arg = ... stuff would need to be moved into the if 
(gimple_range...)
body, it won't work for aggregate PARM_DECLs etc., only PARM_DECLs with
is_gimple_reg_type (TREE_TYPE (arg)).

Jakub

Re: [PATCH] middle-end, v4: IFN_ASSUME support [PR106654]

[Jakub Jelinek via Gcc-patches]

On Wed, Oct 19, 2022 at 12:55:12PM -0400, Andrew MacLeod via Gcc-patches wrote:
> > Not sure I understand this part.  op is whatever we pass as the ith
> > argument to IFN_ASSUME.  I'd expect that at this point one needs to
> > remap that to the (i-1)th PARM_DECL of assume_id (so e.g. when you
> > have the above loop you could as well start with DECL_ARGUMENTS and move
> > that to DECL_CHAIN at the end of every iteration.  And then
> > query ssa_default_def (DECL_STRUCT_FUNCTION (assume_id), parm)
> > in each case and get global range of what that returns.
> 
> OK, this is the bit of code I dont know how to write :-)
> 
> yes, op is the name of the value within this current function, and yes, that
> needs to be mapped to the argument decl in the assume function.   Then we
> need to query what range was given to that name during the assume pass. 
> when that is returned, the add_range (op, range) will inject it as a side
> effect.
> 
> Can you write that loop?

I meant something like (untested code):
   && gimple_call_internal_fn (s) == IFN_ASSUME)
 {
   tree assume_id = gimple_call_arg (s, 0);
-  for (unsigned i = 1; i < gimple_call_num_args (s); i++)
+  tree parm = DECL_ARGUMENTS (assume_id);
+  struct function *fun = DECL_STRUCT_FUNCTION (assume_id);
+  for (unsigned i = 1;
+  i < gimple_call_num_args (s) && parm;
+  i++, parm = DECL_CHAIN (parm))
{
  tree op = gimple_call_arg (s, i);
  tree type = TREE_TYPE (op);
+ tree arg = ssa_default_def (fun, parm);
+ if (arg == NULL_TREE)
+   continue;
  if (gimple_range_ssa_p (op) && Value_Range::supports_type_p (type))
{
  Value_Range assume_range (type);
and querying SSA_NAME_RANGE_INFO of arg rather than op.
> 
> > 
> > > +  for (unsigned  x= 0; x < gimple_phi_num_args (phi); x++)
> >for (unsigned x = 0; ...
> > ?
> > 
> > > @@ -4345,6 +4345,30 @@ execute_ranger_vrp (struct function *fun, bool 
> > > warn_array_bounds_p)
> > > scev_initialize ();
> > > calculate_dominance_info (CDI_DOMINATORS);
> > > +  assume_query *r2 = new assume_query ();
> > > +  for (unsigned i = 0; i < num_ssa_names; i++)
> > > +{
> > > +  tree name = ssa_name (i);
> > > +  if (!name || !gimple_range_ssa_p (name))
> > > + continue;
> > > +  tree type = TREE_TYPE (name);
> > > +  if (!Value_Range::supports_type_p (type))
> > > + continue;
> > > +  Value_Range assume_range (type);
> > > +  if (r2->assume_range_p (assume_range, name))
> > > + {
> > > +   if (dump_file)
> > > + {
> > > +   fprintf (dump_file, "for an assume function, ");
> > > +   print_generic_expr (dump_file, name, TDF_SLIM);
> > > +   fprintf (dump_file, " would have a range of ");
> > > +   assume_range.dump (dump_file);
> > > +   fputc ('\n', dump_file);
> > > + }
> > > + }
> > > +}
> > > +  delete r2;
> > I have expected (but tell me if that isn't possible) this could be something
> > done in the new pass_assumptions::execute () rather than vrp and you'd
> > create the assume_query there (i.e. just for assume_functions) and then
> > query it solely for ssa_default_def of the parameters and save in
> > SSA_NAME_RANGE_INFO.
> 
> I just discovered the assumption pass, and I have moved it to there.
> 
> I dont know much about managing the parameters, but presumably yes, we'd
> only query it for the parameters...  I was showing the query for
> every name just to show what its producing.

Inside of the assume function (cfun->assume_function being true)
one could again walk DECL_ARGUMENTS and for arguments with types
which ranger is able to cope with and they are reg types,
ssa_default_def (cfun, parm) to get the SSA_NAME of the default def (if
any).

> --- a/gcc/tree-vrp.cc
> +++ b/gcc/tree-vrp.cc
> @@ -4465,6 +4465,35 @@ public:
>bool gate (function *fun) final override { return fun->assume_function; }

Regarding your second mail, see above gate, this pass is only run for
assume functions and nothing else.

>unsigned int execute (function *) final override
>  {
> +  assume_query query;
> +  if (dump_file)
> + fprintf (dump_file, "Assumptions :\n--\n");
> +  for (unsigned i = 0; i < num_ssa_names; i++)
> + {
> +   tree name = ssa_name (i);
> +   if (!name || !gimple_range_ssa_p (name))
> + continue;
> +   tree type = TREE_TYPE (name);
> +   if (!Value_Range::supports_type_p (type))
> + continue;
> +   Value_Range assume_range (type);
> +   if (query.assume_range_p (assume_range, name))
> + {
> +   set_range_info (name, assume_range);
> +   if (dump_file)
> + {
> +   print_generic_expr (dump_file, name, TDF_SLIM);
> +   fprintf (dump_file, " -> ");
> +   assume_range.dump (dump_file);
> +   fputc ('\n', dump_file);
> + }
> + }
> + }
> +

Re: [PATCH] Enable shrink wrapping for the RISC-V target.

[Jeff Law via Gcc-patches]

On 10/18/22 11:35, Palmer Dabbelt wrote:



I would have expected things to work fine with libcalls, perhaps with
the exception of the save/restore libcalls.  So that needs deeper
investigation.


The save/restore libcalls only support saving/restoring a handful of 
register configurations (just the saved X registers in the order 
they're usually saved in by GCC).  It should be OK for correctness to 
over-save registers, but it kind of just un-does the shrink wrapping 
so not sure it's worth worrying about at that point.


There's also some oddness around the save/restore libcall ABI, it's 
not the standard function ABI but instead a GCC-internal one.  IIRC it 
just uses the alternate link register (ie, t0 instead of ra) but I may 
have forgotten something else.


I hadn't really dug into it -- I was pretty sure they weren't following 
the standard ABI based on its name and how I've used similar routines to 
save space on some targets in the past.  So if we're having problems 
with shrink-wrapping and libcalls, those two might be worth investigating.



But I think the most important takeaway is that shrink wrapping should 
work with libcalls, there's nothing radically different about libcalls 
that would make them inherently interact poorly with shrink-wrapping.  
So that aspect of the shrink-wrapping patch needs deeper investigation.


Jeff

Re: [PATCH 1/2] Add a parameter for the builtin function of prefetch to align with LLVM

[Andrew Pinski via Gcc-patches]

On Fri, Oct 14, 2022 at 1:40 AM Haochen Jiang via Gcc-patches
 wrote:
>
> gcc/ChangeLog:
>
> * builtins.cc (expand_builtin_prefetch): Handle the fourth parameter 
> in
> expand function.
> * config/aarch64/aarch64-sve.md: Add default parameter value.
> * config/aarch64/aarch64.md (prefetch): New define_expand.
> (*prefetch): Add default parameter value.
> * config/alpha/alpha.md (prefetch): New define_expand.
> (*prefetch): Add default parameter value.
> * config/arc/arc.md: Add default parameter value.
> * config/arm/arm.md (prefetch): New define_expand.
> (*prefetch): Add default parameter value.
> * config/frv/frv.md: Ditto.
> * config/i386/i386.md: Ditto.
> * config/ia64/ia64.md (prefetch): New define_expand.
> (*prefetch): Add default parameter value.
> * config/mips/mips.md (prefetch): New define_expand.
> (*prefetch): Add default parameter value.
> * config/pa/pa.md: Ditto.
> * config/rs6000/rs6000.md (prefetch): New define_expand.
> (*prefetch): Add default parameter value.
> * config/s390/s390.cc (s390_expand_cpymem): Generate fourth parameter 
> for
> gen_prefetch call.
> (s390_expand_setmem): Ditto.
> (s390_expand_cmpmem): Ditto.
> * config/s390/s390.md (prefetch): New define_expand.
> (*prefetch): Add default parameter value.
> * config/sh/sh.md: Ditto.
> * config/sparc/sparc.md: Ditto.
> * doc/rtl.texi: Document cache variable for prefetch.
> * rtl.def (PREFETCH): Change prefetch DEF_RTL_EXPR to add fourth 
> parameter.
> * rtlanal.cc (setup_reg_subrtx_bounds): Change gcc_checking_assert for
> fourth parameter.
> * target-insns.def (prefetch): Add fourth rtx for prefetch.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.c-torture/execute/builtin-prefetch-1.c: Add fourth parameter for
> testcases.
> * gcc.c-torture/execute/builtin-prefetch-2.c: Ditto.
> * gcc.c-torture/execute/builtin-prefetch-3.c: Ditto.
> * gcc.c-torture/execute/builtin-prefetch-4.c: Ditto.
> * gcc.c-torture/execute/builtin-prefetch-5.c: Ditto.
> * gcc.c-torture/execute/builtin-prefetch-6.c: Ditto.
> * gcc.dg/builtin-prefetch-1.c: Ditto.
> * gcc.misc-tests/i386-pf-3dnow-1.c: Ditto.
> * gcc.misc-tests/i386-pf-athlon-1.c: Ditto.
> * gcc.misc-tests/i386-pf-none-1.c: Ditto.
> * gcc.misc-tests/i386-pf-sse-1.c: Ditto.
> * gcc.target/i386/avx-1.c: Change prefetch macro define to variable 
> args.
> * gcc.target/i386/sse-13.c: Ditto.
> * gcc.target/i386/sse-23.c: Ditto.
> * gcc.target/aarch64/prefetchi-1.c: New test.
> * gcc.target/alpha/prefetchi-1.c: Ditto.
> * gcc.target/arc/prefetchi-1.c: Ditto.
> * gcc.target/arm/prefetchi-1.c: Ditto.
> * gcc.target/hppa/prefetchi-1.c: Ditto.
> * gcc.target/i386/prefetchi-1.c: Ditto.
> * gcc.target/ia64/prefetchi-1.c: Ditto.
> * gcc.target/mips/prefetchi-1.c: Ditto.
> * gcc.target/powerpc/prefetchi-1.c: Ditto.
> * gcc.target/s390/prefetchi-1.c: Ditto.
> * gcc.target/sh/prefetchi-1.c: Ditto.
> * gcc.target/sparc/prefetchi-1.c: Ditto.


Do the testcases really need to be changed rather than adding new testcases?
Usually it is better if the testcases not change unless really needed
to be. That is do these testcases pass without being changed? If not
this seems not backwards compatible change and is not something which
we should do.  Otherwise you should just add new testcases instead.

Thanks,
Andrew

> ---
>  gcc/builtins.cc   |  34 --
>  gcc/config/aarch64/aarch64-sve.md |  15 ++-
>  gcc/config/aarch64/aarch64.md |  19 +++-
>  gcc/config/alpha/alpha.md |  19 +++-
>  gcc/config/arc/arc.md |  20 +++-
>  gcc/config/arm/arm.md |  19 +++-
>  gcc/config/frv/frv.md |   6 +-
>  gcc/config/i386/i386.md   |  17 ++-
>  gcc/config/ia64/ia64.md   |  19 +++-
>  gcc/config/mips/mips.md   |  22 +++-
>  gcc/config/pa/pa.md   |  12 +-
>  gcc/config/rs6000/rs6000.md   |  19 +++-
>  gcc/config/s390/s390.cc   |  10 +-
>  gcc/config/s390/s390.md   |  19 +++-
>  gcc/config/sh/sh.md   |  15 ++-
>  gcc/config/sparc/sparc.md |  15 ++-
>  gcc/doc/rtl.texi  |   6 +-
>  gcc/rtl.def   |   5 +-
>  gcc/rtlanal.cc|   2 +-
>  gcc/target-insns.def  |   2 +-
>  .../execute/builtin-prefetch-1.c  |  45 
>  .../execute

Re: [PATCH] middle-end, v4: IFN_ASSUME support [PR106654]

[Andrew MacLeod via Gcc-patches]

On 10/19/22 12:06, Jakub Jelinek wrote:


I have expected (but tell me if that isn't possible) this could be something
done in the new pass_assumptions::execute () rather than vrp and you'd
create the assume_query there (i.e. just for assume_functions) and then
query it solely for ssa_default_def of the parameters and save in
SSA_NAME_RANGE_INFO.

Oh, how do I know I'm processing an assume function?  presumable we 
could gate the pass on that so its not even invoked on non-assume functions?


Andrew

Re: [PATCH] middle-end, v4: IFN_ASSUME support [PR106654]

[Andrew MacLeod via Gcc-patches]

On 10/19/22 12:06, Jakub Jelinek wrote:

Hi!

On Tue, Oct 18, 2022 at 05:31:58PM -0400, Andrew MacLeod wrote:

Anyway, gives you something to experiement with.   If you would find a
different interface useful, let me know, or if there are limitations or
other expansions we might need.   This seems like something reasonable for
you to start working with?

Thanks for working on this.


+  // Look for ASSUME calls, and call query_assume_call for each argument
+  // to determine if there is any inferred range to be had.
+  if (is_a (s) && gimple_call_internal_p (s)
+  && gimple_call_internal_fn (s) == IFN_ASSUME)
+{
+  tree assume_id = gimple_call_arg (s, 0);
+  for (unsigned i = 1; i < gimple_call_num_args (s); i++)
+   {
+ tree op = gimple_call_arg (s, i);
+ tree type = TREE_TYPE (op);
+ if (gimple_range_ssa_p (op) && Value_Range::supports_type_p (type))
+   {
+ Value_Range assume_range (type);
+ if (query_assume_call (assume_range, assume_id, op))
+   {
+ add_range (op, assume_range);
+ if (dump_file)
+   {
+ print_generic_expr (dump_file, assume_id, TDF_SLIM);
+ fprintf (dump_file, " assume inferred range of ");
+ print_generic_expr (dump_file, op, TDF_SLIM);
+ fprintf (dump_file, " to ");
+ assume_range.dump (dump_file);
+ fputc ('\n', dump_file);
+   }
+   }

Not sure I understand this part.  op is whatever we pass as the ith
argument to IFN_ASSUME.  I'd expect that at this point one needs to
remap that to the (i-1)th PARM_DECL of assume_id (so e.g. when you
have the above loop you could as well start with DECL_ARGUMENTS and move
that to DECL_CHAIN at the end of every iteration.  And then
query ssa_default_def (DECL_STRUCT_FUNCTION (assume_id), parm)
in each case and get global range of what that returns.


OK, this is the bit of code I dont know how to write :-)

yes, op is the name of the value within this current function, and yes, 
that needs to be mapped to the argument decl in the assume function.   
Then we need to query what range was given to that name during the 
assume pass.  when that is returned, the add_range (op, range) will 
inject it as a side effect.


Can you write that loop?




+  for (unsigned  x= 0; x < gimple_phi_num_args (phi); x++)

   for (unsigned x = 0; ...
?


@@ -4345,6 +4345,30 @@ execute_ranger_vrp (struct function *fun, bool 
warn_array_bounds_p)
scev_initialize ();
calculate_dominance_info (CDI_DOMINATORS);
  
+  assume_query *r2 = new assume_query ();

+  for (unsigned i = 0; i < num_ssa_names; i++)
+{
+  tree name = ssa_name (i);
+  if (!name || !gimple_range_ssa_p (name))
+   continue;
+  tree type = TREE_TYPE (name);
+  if (!Value_Range::supports_type_p (type))
+   continue;
+  Value_Range assume_range (type);
+  if (r2->assume_range_p (assume_range, name))
+   {
+ if (dump_file)
+   {
+ fprintf (dump_file, "for an assume function, ");
+ print_generic_expr (dump_file, name, TDF_SLIM);
+ fprintf (dump_file, " would have a range of ");
+ assume_range.dump (dump_file);
+ fputc ('\n', dump_file);
+   }
+   }
+}
+  delete r2;

I have expected (but tell me if that isn't possible) this could be something
done in the new pass_assumptions::execute () rather than vrp and you'd
create the assume_query there (i.e. just for assume_functions) and then
query it solely for ssa_default_def of the parameters and save in
SSA_NAME_RANGE_INFO.


I just discovered the assumption pass, and I have moved it to there.

I dont know much about managing the parameters, but presumably yes, we'd 
only query it for the parameters...  I was showing the query for 
every name just to show what its producing.


As for storing it, SSA_NAME_RANGE_INFO is for the current function, that 
woud be easy.  if we store it there, how do we look up that range from 
another functi\on when we have the ASSUME_ID ? That was unclear to me.,



I've attached the replacement version of 0003* which uses the assume 
pass, and writes the global values out.  It still loops over all names 
at the moment


Andrew



From 655627144b8d8c02842d15ec83d720180231564a Mon Sep 17 00:00:00 2001
From: Andrew MacLeod 
Date: Mon, 17 Oct 2022 12:28:21 -0400
Subject: [PATCH 3/3] Show output in assume pass

---
 gcc/tree-vrp.cc | 29 +
 1 file changed, 29 insertions(+)

diff --git a/gcc/tree-vrp.cc b/gcc/tree-vrp.cc
index 1adb15c9934..3ec3d7daa74 100644
--- a/gcc/tree-vrp.cc
+++ b/gcc/tree-vrp.cc
@@ -4465,6 +4465,35 @@ public:
   bool gate (function *fun) final override { return fun->assume_function; }
   unsigned int execute (function *) final override
 {
+  assume_query query;

Re: [PATCH] libstdc++: Fix typo in stride_view's operator- [PR107313]

[Jonathan Wakely via Gcc-patches]

On Wed, 19 Oct 2022 at 15:33, Patrick Palka via Libstdc++
 wrote:
>
> PR libstdc++/107313

OK


>
> libstdc++-v3/ChangeLog:
>
> * include/std/ranges (stride_view::_Iterator::operator-): Fix typo.
> * testsuite/std/ranges/adaptors/stride/1.cc (test03): New test.
> ---
>  libstdc++-v3/include/std/ranges   |  2 +-
>  .../testsuite/std/ranges/adaptors/stride/1.cc | 20 +++
>  2 files changed, 21 insertions(+), 1 deletion(-)
>
> diff --git a/libstdc++-v3/include/std/ranges b/libstdc++-v3/include/std/ranges
> index d113cf19dc7..b29264931cc 100644
> --- a/libstdc++-v3/include/std/ranges
> +++ b/libstdc++-v3/include/std/ranges
> @@ -7874,7 +7874,7 @@ namespace views::__adaptor
>  friend constexpr difference_type
>  operator-(default_sentinel_t __y, const _Iterator& __x)
>requires sized_sentinel_for, iterator_t<_Base>>
> -{ return __detail::__div_ceil(__x._M_end, __x._M_current, 
> __x._M_stride); }
> +{ return __detail::__div_ceil(__x._M_end - __x._M_current, 
> __x._M_stride); }
>
>  friend constexpr difference_type
>  operator-(const _Iterator& __x, default_sentinel_t __y)
> diff --git a/libstdc++-v3/testsuite/std/ranges/adaptors/stride/1.cc 
> b/libstdc++-v3/testsuite/std/ranges/adaptors/stride/1.cc
> index 745d1a61c1b..37ae896014a 100644
> --- a/libstdc++-v3/testsuite/std/ranges/adaptors/stride/1.cc
> +++ b/libstdc++-v3/testsuite/std/ranges/adaptors/stride/1.cc
> @@ -64,10 +64,30 @@ test02()
>VERIFY( ranges::equal(v, (int[]){1, 4, 7}) );
>  }
>
> +void
> +test03()
> +{
> +  // PR libstdc++/107313
> +  int x[] = {1, 2, 3, 4, 5};
> +  __gnu_test::test_input_range rx(x);
> +  auto r = views::counted(rx.begin(), 4) | views::stride(2);
> +  auto i = r.begin();
> +  std::default_sentinel_t s = r.end();
> +  VERIFY( s != i );
> +  VERIFY( s - i == 2 && i - s == -2 );
> +  ++i;
> +  VERIFY( s != i );
> +  VERIFY( s - i == 1 && i - s == -1 );
> +  ++i;
> +  VERIFY( s == i );
> +  VERIFY( s - i == 0 && i - s == 0 );
> +}
> +
>  int
>  main()
>  {
>static_assert(test01());
>test02<__gnu_test::test_input_range>();
>test02<__gnu_test::test_forward_range>();
> +  test03();
>  }
> --
> 2.38.1.119.g9c32cfb49c
>

[PATCH] libstdc++: Implement P2474R2 changes to views::take/drop

[Patrick Palka via Gcc-patches]

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

libstdc++-v3/ChangeLog:

* include/std/ranges (views::__detail::__is_repeat_view): Define
and later define a partial specialization.
(views::__detail::__take_of_repeat_view): Declare and later define.
(views::__detail::__drop_of_repeat_view): Likewise.
(views::_Take::operator()): Return a repeat_view if the argument
is a repeat_view as per P2474R2.
(views::_Drop::operator()): Likewise.
(repeat_view): Befriend __take/drop_of_repeat_view.
* testsuite/std/ranges/repeat/1.cc (test04): New test.
---
 libstdc++-v3/include/std/ranges   | 56 +++
 libstdc++-v3/testsuite/std/ranges/repeat/1.cc | 33 +++
 2 files changed, 89 insertions(+)

diff --git a/libstdc++-v3/include/std/ranges b/libstdc++-v3/include/std/ranges
index b29264931cc..6de08244bd1 100644
--- a/libstdc++-v3/include/std/ranges
+++ b/libstdc++-v3/include/std/ranges
@@ -2257,6 +2257,13 @@ namespace views::__adaptor
   template
inline constexpr bool __is_iota_view> = true;
 
+  template
+   inline constexpr bool __is_repeat_view = false;
+
+  template
+   constexpr auto
+   __take_of_repeat_view(_Range&&, range_difference_t<_Range>); // defined 
later
+
   template
concept __can_take_view
  = requires { take_view(std::declval<_Range>(), std::declval<_Dp>()); 
};
@@ -2291,6 +2298,8 @@ namespace views::__adaptor
  else
return iota_view(*__begin, *__end);
}
+ else if constexpr (__detail::__is_repeat_view<_Tp>)
+   return __detail::__take_of_repeat_view(std::forward<_Range>(__r), 
__n);
  else
return take_view(std::forward<_Range>(__r), __n);
}
@@ -2527,6 +2536,10 @@ namespace views::__adaptor
   {
 namespace __detail
 {
+  template
+   constexpr auto
+   __drop_of_repeat_view(_Range&&, range_difference_t<_Range>); // defined 
later
+
   template
concept __can_drop_view
  = requires { drop_view(std::declval<_Range>(), std::declval<_Dp>()); 
};
@@ -2568,6 +2581,8 @@ namespace views::__adaptor
  else
return _Tp(__begin, __end);
}
+ else if constexpr (__detail::__is_repeat_view<_Tp>)
+   return __detail::__drop_of_repeat_view(std::forward<_Range>(__r), 
__n);
  else
return drop_view(std::forward<_Range>(__r), __n);
}
@@ -7367,6 +7382,14 @@ namespace views::__adaptor
 
 struct _Iterator;
 
+template
+  friend constexpr auto
+  views::__detail::__take_of_repeat_view(_Range&&, 
range_difference_t<_Range>);
+
+template
+  friend constexpr auto
+  views::__detail::__drop_of_repeat_view(_Range&&, 
range_difference_t<_Range>);
+
   public:
 repeat_view() requires default_initializable<_Tp> = default;
 
@@ -7540,6 +7563,9 @@ namespace views::__adaptor
   {
 namespace __detail
 {
+  template
+   inline constexpr bool __is_repeat_view> = true;
+
   template
concept __can_repeat_view
  = requires { repeat_view(std::declval<_Tp>()); };
@@ -7565,6 +7591,36 @@ namespace views::__adaptor
 };
 
 inline constexpr _Repeat repeat;
+
+namespace __detail
+{
+  template
+   constexpr auto
+   __take_of_repeat_view(_Range&& __r, range_difference_t<_Range> __n)
+   {
+ using _Tp = remove_cvref_t<_Range>;
+ static_assert(__is_repeat_view<_Tp>);
+ if constexpr (sized_range<_Tp>)
+   return views::repeat(*__r._M_value, std::min(ranges::distance(__r), 
__n));
+ else
+   return views::repeat(*__r._M_value, __n);
+   }
+
+  template
+   constexpr auto
+   __drop_of_repeat_view(_Range&& __r, range_difference_t<_Range> __n)
+   {
+ using _Tp = remove_cvref_t<_Range>;
+ static_assert(__is_repeat_view<_Tp>);
+ if constexpr (sized_range<_Tp>)
+   {
+ auto __sz = ranges::distance(__r);
+ return views::repeat(*__r._M_value, __sz - std::min(__sz, __n));
+   }
+ else
+   return __r;
+   }
+}
   }
 
   template
diff --git a/libstdc++-v3/testsuite/std/ranges/repeat/1.cc 
b/libstdc++-v3/testsuite/std/ranges/repeat/1.cc
index 3698ed12c14..542c8614f88 100644
--- a/libstdc++-v3/testsuite/std/ranges/repeat/1.cc
+++ b/libstdc++-v3/testsuite/std/ranges/repeat/1.cc
@@ -84,10 +84,43 @@ test03()
   return true;
 }
 
+constexpr bool
+test04()
+{
+  // Verify P2472R2 changes to views::take/drop.
+  auto r = views::repeat(42);
+
+  auto rt = r | views::take(10);
+  static_assert(views::__detail::__is_repeat_view);
+  VERIFY( ranges::equal(rt, views::repeat(42, 10)) );
+
+  auto rd = r | views::drop(10);
+  static_assert(std::same_as);
+
+  auto br = views::repeat(42, 37);
+
+  auto brt = br | views::take(10);
+  static_assert(std::same_as);
+  

Re: Announcement: Porting the Docs to Sphinx - 9. November 2022

[Joseph Myers]

On Wed, 19 Oct 2022, Martin Liška wrote:

> > Currently, there is a tarball with texinfo sources for all the manuals
> > for each version.
> 
> Well, then equivalent would be packaging all .rst files together with the 
> corresponding
> conf.py, logo.* and other files. But I don't see it much useful.

I think we should have such a source tarball when the sources are .rst, as 
the successor to the Texinfo source tarball.

(Unfortunately when I added that source tarball - 
https://gcc.gnu.org/legacy-ml/gcc-patches/2004-01/msg00140.html - I didn't 
give specific references to any of the individual requests that resulted 
in adding it.)

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

[PATCH v2] c++: Mitigate -Wuseless-cast with classes [PR85043]

[Marek Polacek via Gcc-patches]

On Wed, Oct 19, 2022 at 09:27:27AM -0400, Jason Merrill wrote:
> On 10/18/22 13:38, Marek Polacek wrote:
> > -Wuseless-cast (not part of -Wall/-Wextra) warns here:
> > 
> >struct S { };
> >void g (S&&);
> >void f (S&& arg)
> >{
> >  g (S(arg)); // warning: useless cast to type 'struct S'
> >}
> > 
> > which is wrong: the code will not compile without the cast because
> > "arg" is an lvalue which cannot bind to S&&.
> > 
> > I'd like to disable the warning when a class object is cast to
> > a non-reference type, which seems like a minimal patch that fixes the
> > problems reported in our Bugzilla.  Of course, the cast in "(int)i"
> > may not be useless, either, but I'm not changing that here.
> 
> As I commented on PR 14710, "I wouldn't warn about a cast that changes the
> type or value category of an expression at all"

Ah, I didn't see that comment.

> The code currently checks the value category when casting to a reference,
> but not when casting to a non-reference; that seems like the thing to fix.

OK, how about this?  The nice thing is that it handles non-classes as well,
while we still warn about truly useless casts as in "X(X{})".  Thanks,

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

-- >8 --
-Wuseless-cast (not part of -Wall/-Wextra) warns here:

  struct S { };
  void g (S&&);
  void f (S&& arg)
  {
g (S(arg)); // warning: useless cast to type 'struct S'
  }

which is wrong: the code will not compile without the cast because
"arg" is an lvalue which cannot bind to S&&.

This patch disables the warning when an object that isn't a prvalue
is cast to a non-reference type.  Therefore we still warn about the
useless cast in "X(X{})".

PR c++/85043

gcc/cp/ChangeLog:

* typeck.cc (maybe_warn_about_useless_cast): Don't warn when
a glvalue is cast to a non-reference type.

gcc/ChangeLog:

* doc/invoke.texi: Update documentation of -Wuseless-cast.

gcc/testsuite/ChangeLog:

* g++.dg/warn/Wuseless-cast.C: Remove dg-warning.
* g++.dg/warn/Wuseless-cast3.C: New test.
---
 gcc/cp/typeck.cc   |  4 ++-
 gcc/doc/invoke.texi| 13 +-
 gcc/testsuite/g++.dg/warn/Wuseless-cast.C  | 12 -
 gcc/testsuite/g++.dg/warn/Wuseless-cast3.C | 29 ++
 4 files changed, 50 insertions(+), 8 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/warn/Wuseless-cast3.C

diff --git a/gcc/cp/typeck.cc b/gcc/cp/typeck.cc
index da0e1427b97..8e1d14ee6b0 100644
--- a/gcc/cp/typeck.cc
+++ b/gcc/cp/typeck.cc
@@ -8108,7 +8108,9 @@ maybe_warn_about_useless_cast (location_t loc, tree type, 
tree expr,
   && (TYPE_REF_IS_RVALUE (type)
   ? xvalue_p (expr) : lvalue_p (expr))
   && same_type_p (TREE_TYPE (expr), TREE_TYPE (type)))
- || same_type_p (TREE_TYPE (expr), type))
+ /* Don't warn when converting a class object to a non-reference type,
+because that's a common way to create a temporary.  */
+ || (!glvalue_p (expr) && same_type_p (TREE_TYPE (expr), type)))
warning_at (loc, OPT_Wuseless_cast,
"useless cast to type %q#T", type);
 }
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index c176e2dc646..cd4d3c1d72c 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -4551,7 +4551,18 @@ pointers after reallocation.
 @item -Wuseless-cast @r{(C++ and Objective-C++ only)}
 @opindex Wuseless-cast
 @opindex Wno-useless-cast
-Warn when an expression is casted to its own type.
+Warn when an expression is cast to its own type.  This warning does not
+occur when a class object is converted to a non-reference type as that
+is a way to create a temporary:
+
+@smallexample
+struct S @{ @};
+void g (S&&);
+void f (S&& arg)
+@{
+  g (S(arg)); // make arg prvalue so that it can bind to S&&
+@}
+@end smallexample
 
 @item -Wno-conversion-null @r{(C++ and Objective-C++ only)}
 @opindex Wconversion-null
diff --git a/gcc/testsuite/g++.dg/warn/Wuseless-cast.C 
b/gcc/testsuite/g++.dg/warn/Wuseless-cast.C
index 2fd6bc45102..d7cb89930a6 100644
--- a/gcc/testsuite/g++.dg/warn/Wuseless-cast.C
+++ b/gcc/testsuite/g++.dg/warn/Wuseless-cast.C
@@ -62,11 +62,11 @@ A prvalue();
 
 void f()
 {
-  int n; 
+  int n;
 
-  (int)(n);// { dg-warning "3:useless cast" }
-  static_cast(n); // { dg-warning "3:useless cast" }
-  reinterpret_cast(n);// { dg-warning "3:useless cast" }
+  (int)(n);
+  static_cast(n);
+  reinterpret_cast(n);
 
   (int*)(&n);  // { dg-warning "3:useless cast" }
   const_cast(&n);// { dg-warning "3:useless cast" }
@@ -100,8 +100,8 @@ void f()
 
   A a;
 
-  (A)(a); // { dg-warning "3:useless cast" }
-  static_cast(a);  // { dg-warning "3:useless cast" }
+  (A)(a);
+  static_cast(a);
 
   (A*)(&a);   // { dg-warning "3:useless cast" }
   const_cast(&a); // { dg-warning "3:us

Re: Announcement: Porting the Docs to Sphinx - 9. November 2022

[Sandra Loosemore]

On 10/19/22 05:09, Martin Liška wrote:

On 10/18/22 00:26, Sandra Loosemore wrote:

On 10/17/22 07:28, Martin Liška wrote:

Hello.

Based on the very positive feedback I was given at the Cauldron Sphinx 
Documentation BoF,
I'm planning migrating the documentation on 9th November. There are still some 
minor comments
from Sandra when it comes to the PDF output, but we can address that once the 
conversion is done.


My main complaint about the PDF is that the blue color used for link text is so 
light it interferes with readability.  Few people are going to print the 
document on paper any more, but I did try printing a sample page on a grayscale 
printer and the blue link text came out so faint that it was barely visible at 
all.


Sure, I've just added support for monochromatic PDF output where one needs to 
use
MONOCHROMATIC=1 make latexpdf ...

and I linked the file here:
https://splichal.eu/scripts/sphinx/gcc/_build/latexmonochromatic/gcc.pdf

right now I build only one PDF in this mode and it's mentioned here:
https://splichal.eu/scripts/sphinx/

What do you think about it now?


Hmmm, removing *all* visual cues that something is a link does not seem 
so great either, especially since the new format has changed the link 
text for @xref to remove the page and section information.  E.g. we used 
to get "See Section 3.4 [Options Controlling C Dialect], page 44." and 
now it just reads "See Options Controlling C Dialect."


I realize there is a can of worms here involving philosophical issues 
about whether the PDF manual is intended to be formatted for reading as 
a book or is just a handy way to repackage the hyperlinked web 
presentation for offline reference.  Also there is another can of worms 
involving making the documentation accessible to people who have visual 
disabilities, specifically color blindness issues.  Just speaking for 
myself, I'd be happy if the PDF just used a darker blue color for links 
that is both distinguishing and higher contrast with the background than 
the current light blue, but I think it is one of the principles of 
accessible design that color really shouldn't be the *only* indication 
of something that initiates an action.  Maybe underlining, or a little 
link glyph, or restoring the section/page info to the link text?





   An E-ink reader device would probably have similar problems.


There ePUB would be likely better output format. What do you think?


Ooof, a lot of problems there.  I looked at your new generated .epub in 
both the "ebook-viewer" utility on my laptop and on my Kobo Forma.  The 
Kobo uses the default proportionally-spaced font for everything; even 
the code examples fail to come out in a fixed-width font.  ebook-viewer 
shows fixed-width fonts for code examples and inline references to e.g. 
command line options, but the names of options in the option tables 
sections are in the proportional body font.  Also in both viewers I see 
hyperlinks to https://splicha.eu/...  in place of internal links in some 
references to command-line options and the like, and the formatting of 
the option summary tables really sucks, with lines breaking at hyphens 
in the middle of option names.


I suggest we try to focus our efforts on the currently-supported formats 
before adding EPUB as a new format.


-Sandra

Re: [PATCH] testsuite: Fix up c2x-enum-1.c for 32-bit arches [PR107311]

[Joseph Myers]

On Wed, 19 Oct 2022, Jakub Jelinek wrote:

> Hi!
> 
> On Wed, Oct 19, 2022 at 02:57:59PM +, Joseph Myers wrote:
> > I think the type checked for e5a should be conditional on __LONG_MAX__ > 
> > __INT_MAX__; everything else there should be OK regardless.
> 
> So like this?
> Tested on x86_64-linux with -m32 and -m64, ok for trunk?
> 
> 2022-10-19  Jakub Jelinek  
> 
>   PR c/107311
>   * gcc.dg/c2x-enum-1.c (enum e5): Expect e5a type inside of
>   enum to be int rather than long if long isn't wider than int.

OK.

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

[PATCH] testsuite: Fix up c2x-enum-1.c for 32-bit arches [PR107311]

[Jakub Jelinek via Gcc-patches]

Hi!

On Wed, Oct 19, 2022 at 02:57:59PM +, Joseph Myers wrote:
> I think the type checked for e5a should be conditional on __LONG_MAX__ > 
> __INT_MAX__; everything else there should be OK regardless.

So like this?
Tested on x86_64-linux with -m32 and -m64, ok for trunk?

2022-10-19  Jakub Jelinek  

PR c/107311
* gcc.dg/c2x-enum-1.c (enum e5): Expect e5a type inside of
enum to be int rather than long if long isn't wider than int.

--- gcc/testsuite/gcc.dg/c2x-enum-1.c.jj2022-10-19 01:15:21.025186231 
+0200
+++ gcc/testsuite/gcc.dg/c2x-enum-1.c   2022-10-19 18:19:45.215215713 +0200
@@ -82,7 +82,12 @@ enum e5 { e5a = __LONG_MAX__,
  e5b, e5c, e5d = ((typeof (e5b)) -1) < 0,
  e5e = (unsigned long) -1,
  e5f, e5g = ((typeof (e5e)) -1) > 0,
- TYPE_CHECK (e5a, long), TYPE_CHECK (e5e, unsigned long) };
+#if __LONG_MAX__ > __INT_MAX__
+ TYPE_CHECK (e5a, long),
+#else
+ TYPE_CHECK (e5a, int),
+#endif
+ TYPE_CHECK (e5e, unsigned long) };
 extern enum e5 e5v;
 extern typeof (e5a) e5v;
 extern typeof (e5b) e5v;


Jakub

Re: [PATCH] libgomp: fix hang on fatal error

[Jakub Jelinek via Gcc-patches]

On Wed, Oct 19, 2022 at 03:27:52PM +0200, Jakub Jelinek via Gcc-patches wrote:
> > --- a/libgomp/error.c
> > +++ b/libgomp/error.c
> > @@ -77,7 +77,7 @@ void
> >  gomp_vfatal (const char *fmt, va_list list)
> >  {
> >gomp_verror (fmt, list);
> > -  exit (EXIT_FAILURE);
> > +  abort ();
> >  }
> >  
> >  void
> 
> I don't like this, abort has quite different user visible behavior
> from exit, e.g. the former often dumps core.
> 
> I believe in most places libgomp handles this by releasing locks before
> calling gomp_{,v}fatal:
>   gomp_mutex_unlock (®ister_lock);
>   gomp_fatal ("Out of memory allocating %lu bytes", (unsigned long) size);
> 
>   gomp_mutex_unlock (&devicep->lock);
>   gomp_fatal ("Copying of %s object [%p..%p) to %s object [%p..%p) 
> failed",
>   src, srcaddr, srcaddr + size, dst, dstaddr, dstaddr + size);
> 
> etc.
> I could live with a gomp_fatal/gomp_vfatal alternative that would
> use _exit/_Exit (but not sure if it is supported on all targets where
> libgomp is) for uses where releasing locks is for whatever reason
> not an option.

Or yet another possibility would be not use gomp_fatal from within the
plugins, but use gomp_error instead and through possibly adjusted plugin
APIs tell libgomp that there was a fatal error and let libgomp unlock
anything that needs unlocking and exit (EXIT_FAILURE); afterwards.

Jakub

Re: [PATCH] middle-end, v4: IFN_ASSUME support [PR106654]

[Jakub Jelinek via Gcc-patches]

Hi!

On Tue, Oct 18, 2022 at 05:31:58PM -0400, Andrew MacLeod wrote:
> Anyway, gives you something to experiement with.   If you would find a
> different interface useful, let me know, or if there are limitations or
> other expansions we might need.   This seems like something reasonable for
> you to start working with?

Thanks for working on this.

> +  // Look for ASSUME calls, and call query_assume_call for each argument
> +  // to determine if there is any inferred range to be had.
> +  if (is_a (s) && gimple_call_internal_p (s)
> +  && gimple_call_internal_fn (s) == IFN_ASSUME)
> +{
> +  tree assume_id = gimple_call_arg (s, 0);
> +  for (unsigned i = 1; i < gimple_call_num_args (s); i++)
> + {
> +   tree op = gimple_call_arg (s, i);
> +   tree type = TREE_TYPE (op);
> +   if (gimple_range_ssa_p (op) && Value_Range::supports_type_p (type))
> + {
> +   Value_Range assume_range (type);
> +   if (query_assume_call (assume_range, assume_id, op))
> + {
> +   add_range (op, assume_range);
> +   if (dump_file)
> + {
> +   print_generic_expr (dump_file, assume_id, TDF_SLIM);
> +   fprintf (dump_file, " assume inferred range of ");
> +   print_generic_expr (dump_file, op, TDF_SLIM);
> +   fprintf (dump_file, " to ");
> +   assume_range.dump (dump_file);
> +   fputc ('\n', dump_file);
> + }
> + }

Not sure I understand this part.  op is whatever we pass as the ith
argument to IFN_ASSUME.  I'd expect that at this point one needs to
remap that to the (i-1)th PARM_DECL of assume_id (so e.g. when you
have the above loop you could as well start with DECL_ARGUMENTS and move
that to DECL_CHAIN at the end of every iteration.  And then
query ssa_default_def (DECL_STRUCT_FUNCTION (assume_id), parm)
in each case and get global range of what that returns.

> +  for (unsigned  x= 0; x < gimple_phi_num_args (phi); x++)

  for (unsigned x = 0; ...
?

> @@ -4345,6 +4345,30 @@ execute_ranger_vrp (struct function *fun, bool 
> warn_array_bounds_p)
>scev_initialize ();
>calculate_dominance_info (CDI_DOMINATORS);
>  
> +  assume_query *r2 = new assume_query ();
> +  for (unsigned i = 0; i < num_ssa_names; i++)
> +{
> +  tree name = ssa_name (i);
> +  if (!name || !gimple_range_ssa_p (name))
> + continue;
> +  tree type = TREE_TYPE (name);
> +  if (!Value_Range::supports_type_p (type))
> + continue;
> +  Value_Range assume_range (type);
> +  if (r2->assume_range_p (assume_range, name))
> + {
> +   if (dump_file)
> + {
> +   fprintf (dump_file, "for an assume function, ");
> +   print_generic_expr (dump_file, name, TDF_SLIM);
> +   fprintf (dump_file, " would have a range of ");
> +   assume_range.dump (dump_file);
> +   fputc ('\n', dump_file);
> + }
> + }
> +}
> +  delete r2;

I have expected (but tell me if that isn't possible) this could be something
done in the new pass_assumptions::execute () rather than vrp and you'd
create the assume_query there (i.e. just for assume_functions) and then
query it solely for ssa_default_def of the parameters and save in
SSA_NAME_RANGE_INFO.

But my knowledge about ranger is fairly limited...

Jakub

[COMMITTED] Use Value_Range when applying inferred ranges.

[Andrew MacLeod via Gcc-patches]

Apply a non-integral inferred range could trap because I was using an 
int_range_max as the temp.  doh.   Fortunately there are no inferred 
floating points at this point in time.


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

Andrew
commit 69a233610f6b27cd4283561569d8ce0f35044dc4
Author: Andrew MacLeod 
Date:   Wed Oct 19 09:21:22 2022 -0400

Use Value_Range when applying inferred ranges.

Applying an inferred range is using int_range_ma as the
temporary rather than the general purpose Value_Range.  This causes it
to trap if we have a non-integral inferred range.

* gimple-range-cache.cc (ranger_cache::range_from_dom): Use
  Value_Range not int_range_max.

diff --git a/gcc/gimple-range-cache.cc b/gcc/gimple-range-cache.cc
index 0b9aa3639c5..f279371948a 100644
--- a/gcc/gimple-range-cache.cc
+++ b/gcc/gimple-range-cache.cc
@@ -1546,7 +1546,6 @@ ranger_cache::range_from_dom (vrange &r, tree name, basic_block start_bb,
 void
 ranger_cache::apply_inferred_ranges (gimple *s)
 {
-  int_range_max r;
   bool update = true;
 
   basic_block bb = gimple_bb (s);
@@ -1572,6 +1571,7 @@ ranger_cache::apply_inferred_ranges (gimple *s)
   m_exit.add_range (name, bb, infer.range (x));
   if (update)
 	{
+	  Value_Range r (TREE_TYPE (name));
 	  if (!m_on_entry.get_bb_range (r, name, bb))
 	exit_range (r, name, bb, RFD_READ_ONLY);
 	  if (r.intersect (infer.range (x)))

Re: [Patch][v5] libgomp/nvptx: Prepare for reverse-offload callback handling

[Alexander Monakov]

On Wed, 12 Oct 2022, Tobias Burnus wrote:

> On 11.10.22 13:12, Alexander Monakov wrote:
> > My understanding is such trickery should not be necessary with
> > the barrier-based approach, i.e. the sequence of PTX instructions
> >
> >st   % plain store
> >membar.sys
> >st.volatile
> >
> > should be enough to guarantee that the former store is visible on the host
> > before the latter, and work all the way back to sm_20.
> 
> If I understand it correctly, you mean:
> 
>   GOMP_REV_OFFLOAD_VAR->dev_num = GOMP_ADDITIONAL_ICVS.device_num;
> 
>   __sync_synchronize ();  /* membar.sys */
>   asm volatile ("st.volatile.global.u64 [%0], %1;"
> : : "r"(addr_struct_fn), "r" (fn) : "memory");
> 
> 
> And then directly followed by the busy wait:
> 
>   while (__atomic_load_n (&GOMP_REV_OFFLOAD_VAR->fn, __ATOMIC_ACQUIRE) != 0)
> ;  /* spin  */
> 
> which GCC expands to:
> 
>   /* ld.global.u64 %r64,[__gomp_rev_offload_var];
>  ld.u64 %r36,[%r64];
>  membar.sys;  */
> 
> The such updated patch is attached.

I think the topic for which I was Cc'ed (memory space and access method for
the synchronization variable) has been resolved nicely. I am not satisfied
with some other points raised in the conversation, I hope they are noted.

Alexander

> (This is the only change + removing the mkoffload.cc part is the only
> larger change. Otherwise, it only handles the minor comments by Jakub.
> The now removed CU_DEVICE_ATTRIBUTE_ASYNC_ENGINE_COUNT was used
> until commit r10-304-g1f4c5b9bb2eb81880e2bc725435d596fcd2bdfef i.e.
> it is a really old left over!)
> 
> Otherwise, tested* to work with sm_30 (error by mkoffload, unchanged),
> sm_35 and sm_70.
> 
> Tobias
> 
> *With some added code; until GOMP_OFFLOAD_get_num_devices accepts
> GOMP_REQUIRES_UNIFIED_SHARED_MEMORY and GOMP_OFFLOAD_load_image
> gets passed a non-NULL for rev_fn_table, the current patch is a no op.
> 
> Planned next is the related GCN patch – and the actual change
> in libgomp/target.c (+ accepting USM in GOMP_OFFLOAD_get_num_devices)

Re: [PATCH] testsuite: Default make check-g++ vs. tests for newest C++ standard

[Jason Merrill via Gcc-patches]

On 10/19/22 11:27, Jakub Jelinek wrote:

Hi!

On Wed, Oct 19, 2022 at 09:10:48AM -0400, Jason Merrill wrote:

The screw-up on my side with libstdc++ testing (tested normally rather
than in C++23 mode) makes me wonder if we couldn't tweak the default
testing.
Dunno what libstdc++ testing normally does (just C++17?), make check-g++
tests by default { 98, 14, 17, 20 } (and I regularly use
GXX_TESTSUITE_STDS=98,11,14,17,20,2b in environment but that doesn't
cover libstdc++ I guess).
When adding tests for upcoming C++ version, one always has a dilemma
whether to use explicit // { dg-options "-std=c++2b" }
or -std=gnu++2b and similar, then the test works in all modes, but it might
be forgotten later on to be converted into // { dg-do whatever { target c++23 } 
}
test so that when 23 is tested by default and say 26 or 29 appears too,
we test it also in those modes, or just go with
// { dg-do whatever { target c++23 } }
which has the disadvantage that it is skipped when testing by default and
one only tests it if he asks for the newer version.

I wonder if we couldn't for the default testing (when one doesn't
specify GXX_TESTSUITE_STDS or uses make check-c++-all and similar)
improve things a little bit by automatically treat those
// { dg-do whatever { target c++23 } }
tests as // { dg-options "-std=c++2b" }.


That would be great.


Here is a patch that implements it.
On make check-g++ RUNTESTFLAGS=dg.exp=cpp23/*.C
the vanilla vs. patched gcc difference is:
 === g++ Summary ===

# of expected passes1743
# of expected failures  2
# of unsupported tests  224
vs.
 === g++ Summary ===

# of expected passes1829
# of expected failures  2
# of unsupported tests  112

(g++.sum details attached).


OK, thanks.


2022-10-19  Jakub Jelinek  

* lib/g++-dg.exp (g++-dg-runtest): When using defaulted
std_list, if test has { dg-do * { target c++23 } } directive,
use { 23 } with which the test will run instead of { 98 14 17 20 }
which would make it UNSUPPORTED in all cases.

--- gcc/testsuite/lib/g++-dg.exp.jj 2022-03-30 09:11:53.306103969 +0200
+++ gcc/testsuite/lib/g++-dg.exp2022-10-19 17:10:51.574866364 +0200
@@ -53,7 +53,16 @@ proc g++-dg-runtest { testcases flags de
if { [llength $gpp_std_list] > 0 } {
set std_list $gpp_std_list
} else {
-   set std_list { 98 14 17 20 }
+   # If the test requires a newer C++ version than which
+   # is tested by default, use that C++ version for that
+   # single test.  This should be updated or commented
+   # out whenever the default std_list is updated or newer
+   # C++ effective target is added.
+   if [search_for $test "{ dg-do * { target c++23 } }"] {
+   set std_list { 23 }
+   } else {
+   set std_list { 98 14 17 20 }
+   }
}
set option_list { }
foreach x $std_list {


Jakub

[OG12][committed] Fix omp-expand.cc's expand_omp_target for OpenACC

[Tobias Burnus]

Fallout of my Fortran deep-mapping patch, which I somehow missed –
probably because being inundated by  the OG11 OpenACC fails back then.

Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
commit 0d6fc5032c7ba8a95301d0ccbc418875e73955ac
Author: Tobias Burnus 
Date:   Wed Oct 19 17:31:14 2022 +0200

Fix omp-expand.cc's expand_omp_target for OpenACC

In OG12 commit a6c1eccffb161130351d891dc87f5afe54f8075c,
"Fortran/OpenMP: Support mapping of DT with allocatable components"
the size of the addr/sizes/kind arrays was passed as 4th argument.
However, OpenACC uses >3 arguments for its own purpose, e.g. to
handle noncontiguous arrays by passing an array descriptor there.

This patch restores the previous behaviour for OpenACC, fixing
testcases like libgomp.oacc-c-c++-common/noncontig_array-1.c.

gcc/
* omp-expand.cc (expand_omp_target): Fix OpenACC in case there
are more than 3 arguments to the builtin function.
---
 gcc/ChangeLog.omp | 5 +
 gcc/omp-expand.cc | 2 +-
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/gcc/ChangeLog.omp b/gcc/ChangeLog.omp
index 527a9850dba..32a8c7b485f 100644
--- a/gcc/ChangeLog.omp
+++ b/gcc/ChangeLog.omp
@@ -1,3 +1,8 @@
+2022-10-19  Tobias Burnus  
+
+	* omp-expand.cc (expand_omp_target): Fix OpenACC in case there
+	are more than 3 arguments to the builtin function.
+
 2022-10-17  Thomas Schwinge  
 
 	Backported from master:
diff --git a/gcc/omp-expand.cc b/gcc/omp-expand.cc
index 92996685d41..6529f63362b 100644
--- a/gcc/omp-expand.cc
+++ b/gcc/omp-expand.cc
@@ -10456,7 +10456,7 @@ expand_omp_target (struct omp_region *region)
   t3 = t2;
   t4 = t2;
 }
-  else if (TREE_VEC_LENGTH (t) == 3)
+  else if (TREE_VEC_LENGTH (t) == 3 || is_gimple_omp_oacc (entry_stmt))
 {
   t1 = TYPE_MAX_VALUE (TYPE_DOMAIN (TREE_TYPE (TREE_VEC_ELT (t, 1;
   t1 = size_binop (PLUS_EXPR, t1, size_int (1));

commit 92b14810a2743594df945dc6479413a3d9d943aa
Author: Tobias Burnus 
Date:   Wed Oct 19 17:26:34 2022 +0200

ChangeLog for "Fortran: Fix delinearization regression"

Missed to update gcc/fortran/ChangeLog.omp and to include the
following in previous commit, i.e.
commit 76b773a4a2d1daf0b83e50cd999bc38f8dd047be.

gcc/fortran/ChangeLog:

* trans-array.cc (non_negative_strides_array_p): Fix handling
of GFC_DECL_SAVED_DESCRIPTOR.
(gfc_conv_array_ref): Use ARRAY_REF again when possible.

gcc/testsuite/ChangeLog:

* gfortran.dg/gomp/affinity-clause-1.f90: Revert to upsteam version,
update one scan-tree item.
* gfortran.dg/gomp/depend-4.f90: Revert to upstream version.
* gfortran.dg/gomp/depend-5.f90: Likewise.
* gfortran.dg/gomp/depend-6.f90: Likewise.
---
 gcc/fortran/ChangeLog.omp   | 6 ++
 gcc/testsuite/ChangeLog.omp | 8 
 2 files changed, 14 insertions(+)

diff --git a/gcc/fortran/ChangeLog.omp b/gcc/fortran/ChangeLog.omp
index 685fe68667a..189431df4eb 100644
--- a/gcc/fortran/ChangeLog.omp
+++ b/gcc/fortran/ChangeLog.omp
@@ -1,3 +1,9 @@
+2022-10-19  Tobias Burnus  
+
+	* trans-array.cc (non_negative_strides_array_p): Fix handling
+	of GFC_DECL_SAVED_DESCRIPTOR.
+	(gfc_conv_array_ref): Use ARRAY_REF again when possible.
+
 2022-10-17  Tobias Burnus  
 
 	Backport from mainline:
diff --git a/gcc/testsuite/ChangeLog.omp b/gcc/testsuite/ChangeLog.omp
index b2b4381e3ce..6928d520c0f 100644
--- a/gcc/testsuite/ChangeLog.omp
+++ b/gcc/testsuite/ChangeLog.omp
@@ -1,3 +1,11 @@
+2022-10-19  Tobias Burnus  
+
+	* gfortran.dg/gomp/affinity-clause-1.f90: Revert to upsteam version,
+	update one scan-tree item.
+	* gfortran.dg/gomp/depend-4.f90: Revert to upstream version.
+	* gfortran.dg/gomp/depend-5.f90: Likewise.
+	* gfortran.dg/gomp/depend-6.f90: Likewise.
+
 2022-10-17  Tobias Burnus  
 
 	Backport from mainline:

Re: [PATCH][AArch64] Improve immediate expansion [PR106583]

[Wilco Dijkstra via Gcc-patches]

ping



Hi Richard,

>>> Sounds good, but could you put it before the mode version,
>>> to avoid the forward declaration?
>>
>> I can swap them around but the forward declaration is still required as
>> aarch64_check_bitmask is 5000 lines before aarch64_bitmask_imm.
>
> OK, how about moving them both above aarch64_check_bitmask?

Sure I've moved them as well as all related helper functions - it makes the diff
quite large but they are all together now which makes sense. I also refactored
aarch64_mov_imm to handle the case of a 64-bit immediate being generated
by a 32-bit MOVZ/MOVN - this simplifies aarch64_internal_move_immediate
and movdi patterns even further.

Cheers,
Wilco

v3: move immediate code together and avoid forward declarations,
further cleanups and simplifications.

Improve immediate expansion of immediates which can be created from a
bitmask immediate and 2 MOVKs.  Simplify, refactor and improve 
efficiency of bitmask checks and move immediate. Move various immediate
handling functions together to avoid forward declarations.
Include 32-bit MOVZ/N as valid 64-bit immediates. Add new constraint so
the movdi pattern only needs a single alternative for move immediate.

This reduces the number of 4-instruction immediates in SPECINT/FP by 10-15%.

Passes bootstrap & regress, OK for commit?

gcc/ChangeLog:

    PR target/106583
    * config/aarch64/aarch64.cc (aarch64_internal_mov_immediate)
    Add support for a bitmask immediate with 2 MOVKs.
    (aarch64_check_bitmask): New function after refactorization.
    (aarch64_replicate_bitmask_imm): Remove function, merge into...
    (aarch64_bitmask_imm): Simplify replication of small modes.
    Split function into 64-bit only version for efficiency.
    (aarch64_zeroextended_move_imm): New function.
    (aarch64_move_imm): Refactor code.
    (aarch64_uimm12_shift): Move near other immediate functions.
    (aarch64_clamp_to_uimm12_shift): Likewise.
    (aarch64_movk_shift): Likewise.
    (aarch64_replicate_bitmask_imm): Likewise.
    (aarch64_and_split_imm1): Likewise.
    (aarch64_and_split_imm2): Likewise.
    (aarch64_and_bitmask_imm): Likewise.
    (aarch64_movw_imm): Remove.
    * config/aarch64/aarch64.md (movdi_aarch64): Merge 'N' and 'M'
    constraints into single 'O'.
    (mov_aarch64): Likewise.
    * config/aarch64/aarch64-protos.h (aarch64_move_imm): Use unsigned.
    (aarch64_bitmask_imm): Likewise.
    (aarch64_uimm12_shift): Likewise.
    (aarch64_zeroextended_move_imm): New prototype.
    * config/aarch64/constraints.md: Add 'O' for 32/64-bit immediates,
    limit 'N' to 64-bit only moves.

gcc/testsuite:
    PR target/106583
    * gcc.target/aarch64/pr106583.c: Add new test.

---

diff --git a/gcc/config/aarch64/aarch64-protos.h 
b/gcc/config/aarch64/aarch64-protos.h
index 
3e4005c9f4ff1f999f1811c6fb0b2252878dc4ae..b82f9ba7c2bb4cffa16abbf45f87061f72015083
 100644
--- a/gcc/config/aarch64/aarch64-protos.h
+++ b/gcc/config/aarch64/aarch64-protos.h
@@ -755,7 +755,7 @@ void aarch64_post_cfi_startproc (void);
 poly_int64 aarch64_initial_elimination_offset (unsigned, unsigned);
 int aarch64_get_condition_code (rtx);
 bool aarch64_address_valid_for_prefetch_p (rtx, bool);
-bool aarch64_bitmask_imm (HOST_WIDE_INT val, machine_mode);
+bool aarch64_bitmask_imm (unsigned HOST_WIDE_INT val, machine_mode);
 unsigned HOST_WIDE_INT aarch64_and_split_imm1 (HOST_WIDE_INT val_in);
 unsigned HOST_WIDE_INT aarch64_and_split_imm2 (HOST_WIDE_INT val_in);
 bool aarch64_and_bitmask_imm (unsigned HOST_WIDE_INT val_in, machine_mode 
mode);
@@ -792,7 +792,7 @@ bool aarch64_masks_and_shift_for_bfi_p (scalar_int_mode, 
unsigned HOST_WIDE_INT,
 unsigned HOST_WIDE_INT,
 unsigned HOST_WIDE_INT);
 bool aarch64_zero_extend_const_eq (machine_mode, rtx, machine_mode, rtx);
-bool aarch64_move_imm (HOST_WIDE_INT, machine_mode);
+bool aarch64_move_imm (unsigned HOST_WIDE_INT, machine_mode);
 machine_mode aarch64_sve_int_mode (machine_mode);
 opt_machine_mode aarch64_sve_pred_mode (unsigned int);
 machine_mode aarch64_sve_pred_mode (machine_mode);
@@ -842,8 +842,9 @@ bool aarch64_sve_float_arith_immediate_p (rtx, bool);
 bool aarch64_sve_float_mul_immediate_p (rtx);
 bool aarch64_split_dimode_const_store (rtx, rtx);
 bool aarch64_symbolic_address_p (rtx);
-bool aarch64_uimm12_shift (HOST_WIDE_INT);
+bool aarch64_uimm12_shift (unsigned HOST_WIDE_INT);
 int aarch64_movk_shift (const wide_int_ref &, const wide_int_ref &);
+bool aarch64_zeroextended_move_imm (unsigned HOST_WIDE_INT);
 bool aarch64_use_return_insn_p (void);
 const char *aarch64_output_casesi (rtx *);
 
diff --git a/gcc/config/aarch64/aarch64.cc b/gcc/config/aarch64/aarch64.cc
index 
4de55beb067ea8f0be0a90060a785c94bdee708b..785ec07692981d423582051ac0897e5dbc3a001f
 100644
--- a/gcc/config/aarch64/aarch64.cc
+++ b/gcc/config/

[PATCH] testsuite: Default make check-g++ vs. tests for newest C++ standard

[Jakub Jelinek via Gcc-patches]

Hi!

On Wed, Oct 19, 2022 at 09:10:48AM -0400, Jason Merrill wrote:
> > The screw-up on my side with libstdc++ testing (tested normally rather
> > than in C++23 mode) makes me wonder if we couldn't tweak the default
> > testing.
> > Dunno what libstdc++ testing normally does (just C++17?), make check-g++
> > tests by default { 98, 14, 17, 20 } (and I regularly use
> > GXX_TESTSUITE_STDS=98,11,14,17,20,2b in environment but that doesn't
> > cover libstdc++ I guess).
> > When adding tests for upcoming C++ version, one always has a dilemma
> > whether to use explicit // { dg-options "-std=c++2b" }
> > or -std=gnu++2b and similar, then the test works in all modes, but it might
> > be forgotten later on to be converted into // { dg-do whatever { target 
> > c++23 } }
> > test so that when 23 is tested by default and say 26 or 29 appears too,
> > we test it also in those modes, or just go with
> > // { dg-do whatever { target c++23 } }
> > which has the disadvantage that it is skipped when testing by default and
> > one only tests it if he asks for the newer version.
> > 
> > I wonder if we couldn't for the default testing (when one doesn't
> > specify GXX_TESTSUITE_STDS or uses make check-c++-all and similar)
> > improve things a little bit by automatically treat those
> > // { dg-do whatever { target c++23 } }
> > tests as // { dg-options "-std=c++2b" }.
> 
> That would be great.

Here is a patch that implements it.
On make check-g++ RUNTESTFLAGS=dg.exp=cpp23/*.C
the vanilla vs. patched gcc difference is:
=== g++ Summary ===

# of expected passes1743
# of expected failures  2
# of unsupported tests  224
vs.
=== g++ Summary ===

# of expected passes1829
# of expected failures  2
# of unsupported tests  112

(g++.sum details attached).

2022-10-19  Jakub Jelinek  

* lib/g++-dg.exp (g++-dg-runtest): When using defaulted
std_list, if test has { dg-do * { target c++23 } } directive,
use { 23 } with which the test will run instead of { 98 14 17 20 }
which would make it UNSUPPORTED in all cases.

--- gcc/testsuite/lib/g++-dg.exp.jj 2022-03-30 09:11:53.306103969 +0200
+++ gcc/testsuite/lib/g++-dg.exp2022-10-19 17:10:51.574866364 +0200
@@ -53,7 +53,16 @@ proc g++-dg-runtest { testcases flags de
if { [llength $gpp_std_list] > 0 } {
set std_list $gpp_std_list
} else {
-   set std_list { 98 14 17 20 }
+   # If the test requires a newer C++ version than which
+   # is tested by default, use that C++ version for that
+   # single test.  This should be updated or commented
+   # out whenever the default std_list is updated or newer
+   # C++ effective target is added.
+   if [search_for $test "{ dg-do * { target c++23 } }"] {
+   set std_list { 23 }
+   } else {
+   set std_list { 98 14 17 20 }
+   }
}
set option_list { }
foreach x $std_list {


Jakub
--- testsuite/g++/g++.sum   2022-10-19 17:06:38.351280055 +0200
+++ testsuite/g++/g++.sum   2022-10-19 17:11:15.948537868 +0200
@@ -647,56 +647,39 @@ PASS: g++.dg/cpp23/auto-array4.C  -std=g
 PASS: g++.dg/cpp23/auto-array4.C  -std=gnu++20  (test for warnings, line 12)
 PASS: g++.dg/cpp23/auto-array4.C  -std=gnu++20  at line 13 (test for warnings, 
line 12)
 PASS: g++.dg/cpp23/auto-array4.C  -std=gnu++20 (test for excess errors)
-UNSUPPORTED: g++.dg/cpp23/auto-fncast1.C  -std=c++98
-UNSUPPORTED: g++.dg/cpp23/auto-fncast1.C  -std=c++14
-UNSUPPORTED: g++.dg/cpp23/auto-fncast1.C  -std=c++17
-UNSUPPORTED: g++.dg/cpp23/auto-fncast1.C  -std=c++20
-UNSUPPORTED: g++.dg/cpp23/auto-fncast10.C  -std=c++98
-UNSUPPORTED: g++.dg/cpp23/auto-fncast10.C  -std=c++14
-UNSUPPORTED: g++.dg/cpp23/auto-fncast10.C  -std=c++17
-UNSUPPORTED: g++.dg/cpp23/auto-fncast10.C  -std=c++20
-UNSUPPORTED: g++.dg/cpp23/auto-fncast11.C  -std=c++98
-UNSUPPORTED: g++.dg/cpp23/auto-fncast11.C  -std=c++14
-UNSUPPORTED: g++.dg/cpp23/auto-fncast11.C  -std=c++17
-UNSUPPORTED: g++.dg/cpp23/auto-fncast11.C  -std=c++20
-UNSUPPORTED: g++.dg/cpp23/auto-fncast12.C  -std=c++98
-UNSUPPORTED: g++.dg/cpp23/auto-fncast12.C  -std=c++14
-UNSUPPORTED: g++.dg/cpp23/auto-fncast12.C  -std=c++17
-UNSUPPORTED: g++.dg/cpp23/auto-fncast12.C  -std=c++20
-UNSUPPORTED: g++.dg/cpp23/auto-fncast2.C  -std=c++98
-UNSUPPORTED: g++.dg/cpp23/auto-fncast2.C  -std=c++14
-UNSUPPORTED: g++.dg/cpp23/auto-fncast2.C  -std=c++17
-UNSUPPORTED: g++.dg/cpp23/auto-fncast2.C  -std=c++20
-UNSUPPORTED: g++.dg/cpp23/auto-fncast3.C  -std=c++98
-UNSUPPORTED: g++.dg/cpp23/auto-fncast3.C  -std=c++14
-UNSUPPORTED: g++.dg/cpp23/auto-fncast3.C  -std=c++17
-UNSUPPORTED: g++.dg/cpp23/auto-fncast3.C  -std=c++20
-UNSUPPORTED: g++.dg/cpp23/auto-fncast4.C  -std=c++98
-UNSUPPORTED: g++.dg/cpp23/auto-fncast4.C  -std=c++14
-UN

Re: [committed] c: C2x enums wider than int [PR36113]

[Joseph Myers]

On Wed, 19 Oct 2022, Jakub Jelinek wrote:

> > +/* Likewise, for overflow from long to long long.  */
> > +#if __LONG_LONG_MAX__ > __LONG_MAX__
> > +enum e5 { e5a = __LONG_MAX__,
> > + e5b, e5c, e5d = ((typeof (e5b)) -1) < 0,
> > + e5e = (unsigned long) -1,
> > + e5f, e5g = ((typeof (e5e)) -1) > 0,
> > + TYPE_CHECK (e5a, long), TYPE_CHECK (e5e, unsigned long) };
> 
> This fails on x86_64-linux with -m32 and I assume most other 32-bit
> targets, it works with
> TYPE_CHECK (e5a, int), TYPE_CHECK (e5e, unsigned long) };
> Haven't checked in detail, but if int and long have the same bitsize,
> doesn't __LONG_MAX__ fit into int and so this new handling of large
> enumerators doesn't apply?
> Can we just change that unconditionally, or shall it be conditional
> on #if __LONG_MAX__ > __INT_MAX__ (then use long, otherwise int)?

I think the type checked for e5a should be conditional on __LONG_MAX__ > 
__INT_MAX__; everything else there should be OK regardless.

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

[PATCH] libstdc++: Fix typo in stride_view's operator- [PR107313]

[Patrick Palka via Gcc-patches]

PR libstdc++/107313

libstdc++-v3/ChangeLog:

* include/std/ranges (stride_view::_Iterator::operator-): Fix typo.
* testsuite/std/ranges/adaptors/stride/1.cc (test03): New test.
---
 libstdc++-v3/include/std/ranges   |  2 +-
 .../testsuite/std/ranges/adaptors/stride/1.cc | 20 +++
 2 files changed, 21 insertions(+), 1 deletion(-)

diff --git a/libstdc++-v3/include/std/ranges b/libstdc++-v3/include/std/ranges
index d113cf19dc7..b29264931cc 100644
--- a/libstdc++-v3/include/std/ranges
+++ b/libstdc++-v3/include/std/ranges
@@ -7874,7 +7874,7 @@ namespace views::__adaptor
 friend constexpr difference_type
 operator-(default_sentinel_t __y, const _Iterator& __x)
   requires sized_sentinel_for, iterator_t<_Base>>
-{ return __detail::__div_ceil(__x._M_end, __x._M_current, __x._M_stride); }
+{ return __detail::__div_ceil(__x._M_end - __x._M_current, __x._M_stride); 
}
 
 friend constexpr difference_type
 operator-(const _Iterator& __x, default_sentinel_t __y)
diff --git a/libstdc++-v3/testsuite/std/ranges/adaptors/stride/1.cc 
b/libstdc++-v3/testsuite/std/ranges/adaptors/stride/1.cc
index 745d1a61c1b..37ae896014a 100644
--- a/libstdc++-v3/testsuite/std/ranges/adaptors/stride/1.cc
+++ b/libstdc++-v3/testsuite/std/ranges/adaptors/stride/1.cc
@@ -64,10 +64,30 @@ test02()
   VERIFY( ranges::equal(v, (int[]){1, 4, 7}) );
 }
 
+void
+test03()
+{
+  // PR libstdc++/107313
+  int x[] = {1, 2, 3, 4, 5};
+  __gnu_test::test_input_range rx(x);
+  auto r = views::counted(rx.begin(), 4) | views::stride(2);
+  auto i = r.begin();
+  std::default_sentinel_t s = r.end();
+  VERIFY( s != i );
+  VERIFY( s - i == 2 && i - s == -2 );
+  ++i;
+  VERIFY( s != i );
+  VERIFY( s - i == 1 && i - s == -1 );
+  ++i;
+  VERIFY( s == i );
+  VERIFY( s - i == 0 && i - s == 0 );
+}
+
 int
 main()
 {
   static_assert(test01());
   test02<__gnu_test::test_input_range>();
   test02<__gnu_test::test_forward_range>();
+  test03();
 }
-- 
2.38.1.119.g9c32cfb49c

[PATCH v4] testsuite: Sanitize fails for SP FPU on Arm

[Torbjörn SVENSSON via Gcc-patches]

This patch stops reporting fails for Arm targets with single
precision floating point unit for types wider than 32 bits (the width
of float on arm-none-eabi).

As reported in PR102017, fenv is reported as supported in recent
versions of newlib. At the same time, for some Arm targets, the
implementation in libgcc does not support exceptions and thus, the
test fails with a call to abort().

gcc/testsuite/ChangeLog:

* lib/target-supports.exp
(check_effective_target_fenv_exceptions_double): New.
(check_effective_target_fenv_exceptions_long_double): New.
* gcc.dg/c2x-float-7.c: Split into 3 tests...
* gcc.dg/c2x-float-7a.c: Float part of c2x-float-7.c.
* gcc.dg/c2x-float-7b.c: Double part of c2x-float-7.c.
* gcc.dg/c2x-float-7c.c: Long double part of c2x-float-7.c.
* gcc.dg/pr95115.c: Switch to fenv_exceptions_double.
* gcc.dg/torture/float32x-nan-floath.c: Likewise.
* gcc.dg/torture/float32x-nan.c: Likewise.
* gcc.dg/torture/float64-nan-floath.c: Likewise.
* gcc.dg/torture/float64-nan.c: Likewise.
* gcc.dg/torture/inf-compare-1.c: Likewise.
* gcc.dg/torture/inf-compare-2.c: Likewise.
* gcc.dg/torture/inf-compare-3.c: Likewise.
* gcc.dg/torture/inf-compare-4.c: Likewise.
* gcc.dg/torture/inf-compare-5.c: Likewise.
* gcc.dg/torture/inf-compare-6.c: Likewise.
* gcc.dg/torture/inf-compare-7.c: Likewise.
* gcc.dg/torture/inf-compare-8.c: Likewise.
* gcc.dg/torture/pr52451.c: Likewise.
* gcc.dg/torture/pr82692.c: Likewise.
* gcc.dg/torture/inf-compare-1-float.c: New test.
* gcc.dg/torture/inf-compare-2-float.c: New test.
* gcc.dg/torture/inf-compare-3-float.c: New test.
* gcc.dg/torture/inf-compare-4-float.c: New test.
* gcc.dg/torture/inf-compare-5-float.c: New test.
* gcc.dg/torture/inf-compare-6-float.c: New test.
* gcc.dg/torture/inf-compare-7-float.c: New test.
* gcc.dg/torture/inf-compare-8-float.c: New test.

Co-Authored-By: Yvan ROUX 
Signed-off-by: Torbjörn SVENSSON 
---
 gcc/testsuite/gcc.dg/c2x-float-7.c| 49 
 gcc/testsuite/gcc.dg/c2x-float-7a.c   | 32 
 gcc/testsuite/gcc.dg/c2x-float-7b.c   | 32 
 gcc/testsuite/gcc.dg/c2x-float-7c.c   | 32 
 gcc/testsuite/gcc.dg/pr95115.c|  2 +-
 .../gcc.dg/torture/float32x-nan-floath.c  |  2 +-
 gcc/testsuite/gcc.dg/torture/float32x-nan.c   |  2 +-
 .../gcc.dg/torture/float64-nan-floath.c   |  2 +-
 gcc/testsuite/gcc.dg/torture/float64-nan.c|  2 +-
 .../gcc.dg/torture/inf-compare-1-float.c  | 21 ++
 gcc/testsuite/gcc.dg/torture/inf-compare-1.c  |  2 +-
 .../gcc.dg/torture/inf-compare-2-float.c  | 21 ++
 gcc/testsuite/gcc.dg/torture/inf-compare-2.c  |  2 +-
 .../gcc.dg/torture/inf-compare-3-float.c  | 21 ++
 gcc/testsuite/gcc.dg/torture/inf-compare-3.c  |  2 +-
 .../gcc.dg/torture/inf-compare-4-float.c  | 21 ++
 gcc/testsuite/gcc.dg/torture/inf-compare-4.c  |  2 +-
 .../gcc.dg/torture/inf-compare-5-float.c  | 19 +
 gcc/testsuite/gcc.dg/torture/inf-compare-5.c  |  2 +-
 .../gcc.dg/torture/inf-compare-6-float.c  | 19 +
 gcc/testsuite/gcc.dg/torture/inf-compare-6.c  |  2 +-
 .../gcc.dg/torture/inf-compare-7-float.c  | 19 +
 gcc/testsuite/gcc.dg/torture/inf-compare-7.c  |  2 +-
 .../gcc.dg/torture/inf-compare-8-float.c  | 19 +
 gcc/testsuite/gcc.dg/torture/inf-compare-8.c  |  2 +-
 gcc/testsuite/gcc.dg/torture/pr52451.c|  2 +-
 gcc/testsuite/gcc.dg/torture/pr82692.c|  2 +-
 gcc/testsuite/lib/target-supports.exp | 74 +++
 28 files changed, 345 insertions(+), 64 deletions(-)
 delete mode 100644 gcc/testsuite/gcc.dg/c2x-float-7.c
 create mode 100644 gcc/testsuite/gcc.dg/c2x-float-7a.c
 create mode 100644 gcc/testsuite/gcc.dg/c2x-float-7b.c
 create mode 100644 gcc/testsuite/gcc.dg/c2x-float-7c.c
 create mode 100644 gcc/testsuite/gcc.dg/torture/inf-compare-1-float.c
 create mode 100644 gcc/testsuite/gcc.dg/torture/inf-compare-2-float.c
 create mode 100644 gcc/testsuite/gcc.dg/torture/inf-compare-3-float.c
 create mode 100644 gcc/testsuite/gcc.dg/torture/inf-compare-4-float.c
 create mode 100644 gcc/testsuite/gcc.dg/torture/inf-compare-5-float.c
 create mode 100644 gcc/testsuite/gcc.dg/torture/inf-compare-6-float.c
 create mode 100644 gcc/testsuite/gcc.dg/torture/inf-compare-7-float.c
 create mode 100644 gcc/testsuite/gcc.dg/torture/inf-compare-8-float.c

diff --git a/gcc/testsuite/gcc.dg/c2x-float-7.c 
b/gcc/testsuite/gcc.dg/c2x-float-7.c
deleted file mode 100644
index 0c90ff24165..000
--- a/gcc/testsuite/gcc.dg/c2x-float-7.c
+++ /dev/null
@@ -1,49 +0,0 @@
-/* Test SNAN macros.  Runtime exceptions test, to verify NaN is
-   signaling.  */
-/* { dg-do run } */
-/* { dg-require-effective-target fenv_exceptions } */
-/* { dg-options "-std

[OG12][committed] Fortran: Fix delinearization regression

[Tobias Burnus]

As mentioned in the patch submission for "Fortran: Fix
non_negative_strides_array_p", there were some issues on OG12 which uses
Sandra's delinearization patch (and was forward ported from OG11)

This patch fixes one issue, caused by a GCC 12 change.

At some point, we could think of using the delinearization patch in
mainline; on OG12 it is used together with some Graphite work to
parallelize loops in OpenACC's kernels construct. But at least in
principle, it could also offer better optimization options in general.

Tobias

PS: OG12 alias devel/omp/gcc-12 is a branch based on GCC 12 that
contains OpenMP, OpenACC and offloading commits not yet on GCC 12.
Several of those commits went first to mainline/GCC 13, but some are so
far only on OG12 – like this delinearization patch. The goal is to
eventually have all features in mainline.
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
commit 76b773a4a2d1daf0b83e50cd999bc38f8dd047be
Author: Tobias Burnus 
Date:   Wed Oct 19 15:53:25 2022 +0200

Fortran: Fix delinearization regression

The delinearization patch "Fortran: delinearize multi-dimensional array
accesses", OG12 commit 39a8c371fda6136cf77c74895a00b136409e0ba3 uses
gfc_build_array_ref for the non-delinearization path. The generated
code depends on whether there can be negative strides or not, an
addition to that function in r12-8230-g7964ab6c364 - adding a Boolean
argument.

The follow-up OG12 commit "Fix Fortran array-access regressions",
9fb0076b11eb2774b620bcf2171d55c7d1fb899f also added this argument
to the call in gfc_conv_array_ref, but always evaluating as false.

This commit changes it to a call to non_negative_strides_array_p
(Note: for 'se->expr' not 'base'; the former could be 'arraydesc'
while the later is then 'arraydesc.data' whose TREE_TYPE does not
contain information about the array type.)

However, doing so revealed a bug in non_negative_strides_array_p,
fixed in this commit but also submitted as "Fortran: Fix
non_negative_strides_array_p" to mainline,
https://gcc.gnu.org/pipermail/gcc-patches/2022-October/603883.html

As a side effect of this commit, several testcases now pass and the
OG12-only changes to depend-{4,5,6}.f90 and affinity-clause-1.f90
could be undone, except that the latter now uses the delinearized
array syntax in one case, which is an improvement (as honored in
the scan-dump-tree). Hence, this commit (partially) reverts the
commits:

21c806f73fc gfortran.dg/gomp/{depend-5,scope-6}.f90: Update scan-tree-dump
014fc7cd451 Fix dg- pattern for gomp/{affinity-clause-1.f90,uses_allocators-3.f90}
2d8aa5cc5d3 gfortran.dg/gomp/depend-6.f90: minor fix + dump update
d77133b29fc gfortran.dg/gomp/depend-4.f90: minor fix + dump update

The main testcase for non_negative_strides_array_p is
gfortran.dg/array_reference_3.f90, which now also passes as well.

Additionally, this changes prevents some unintended implicit
mapping such that libgomp.fortran/map-alloc-comp-{4,6}.f90 failed
before - and now passes again.
---
 gcc/fortran/trans-array.cc | 18 --
 .../gfortran.dg/gomp/affinity-clause-1.f90 |  6 +-
 gcc/testsuite/gfortran.dg/gomp/depend-4.f90| 74 +++---
 gcc/testsuite/gfortran.dg/gomp/depend-5.f90| 13 ++--
 gcc/testsuite/gfortran.dg/gomp/depend-6.f90| 72 ++---
 5 files changed, 91 insertions(+), 92 deletions(-)

diff --git a/gcc/fortran/trans-array.cc b/gcc/fortran/trans-array.cc
index bc2477e4aea..13d92c9fb1f 100644
--- a/gcc/fortran/trans-array.cc
+++ b/gcc/fortran/trans-array.cc
@@ -3703,11 +3703,16 @@ non_negative_strides_array_p (tree expr)
 
   /* If the array was originally a dummy with a descriptor, strides can be
  negative.  */
-  if (DECL_P (expr)
-  && DECL_LANG_SPECIFIC (expr)
-  && GFC_DECL_SAVED_DESCRIPTOR (expr)
-  && GFC_DECL_SAVED_DESCRIPTOR (expr) != expr)
-return non_negative_strides_array_p (GFC_DECL_SAVED_DESCRIPTOR (expr));
+  tree decl = expr;
+  STRIP_NOPS (decl);
+  if (TREE_CODE (decl) == INDIRECT_REF)
+decl = TREE_OPERAND (decl, 0);
+
+  if (DECL_P (decl)
+  && DECL_LANG_SPECIFIC (decl)
+  && GFC_DECL_SAVED_DESCRIPTOR (decl)
+  && GFC_DECL_SAVED_DESCRIPTOR (decl) != expr)
+return non_negative_strides_array_p (GFC_DECL_SAVED_DESCRIPTOR (decl));
 
   return true;
 }
@@ -4200,12 +4205,13 @@ gfc_conv_array_ref (gfc_se * se, gfc_array_ref * ar, gfc_expr *expr,
 {
   /* Build a linearized array reference using the offset from all
 	 dimensions.  */
+  bool non_neg = non_negative_strides_array_p (se->expr);
   if (!integer_zerop (cst_offset))
 	o

[committed] wwwdocs: codingconventions: Fix two typos

[Gerald Pfeifer]

I looked for some typos to test whether updating individual pages now 
works smoothly again after my mass update a few days ago ran into a 
problem on the server side and left the system in "twilight zone".

Pushed.

Gerald
---
 htdocs/codingconventions.html | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/htdocs/codingconventions.html b/htdocs/codingconventions.html
index c793058f..9d0a3f14 100644
--- a/htdocs/codingconventions.html
+++ b/htdocs/codingconventions.html
@@ -142,7 +142,7 @@ a large batch of changes.
 supported formats: a/b/c/ChangeLog, 
a/b/c/ChangeLog:, a/b/c/ (where ChangeLog file lives 
in the folder), \ta/b/c/ and a/b/c
 pr_entry - bug report reference 
 example: \tPR component/12345
-changelog_file - a modified file mentined in a ChangeLog:
+changelog_file - a modified file mentioned in a ChangeLog:
 supported formats: \t* a/b/c/file.c:, \t* 
a/b/c/file.c (function):, \t* a/b/c/file1.c, 
a/b/c/file2.c:
 changelog_file_comment - line that follows a 
changelog_file with description of changes in the file;
 must start with \t
@@ -154,7 +154,7 @@ a large batch of changes.
 Format rules
 
 
-git_description - optional; ends right before one of the 
other compoments is found
+git_description - optional; ends right before one of the 
other components is found
 committer_timestamp - optional; when found before a 
changelog_file, then it is added
 to each changelog entry
 additional_author - optional
-- 
2.38.0

[COMMITTED] [PR tree-optimization/107312] Make range_true_and_false work with 1-bit signed types.

[Aldy Hernandez via Gcc-patches]

range_true_and_false() returns a range of [0,1], which for a 1-bit
signed integer gets passed to the irange setter as [0, -1].  These
endpoints are out of order and cause an ICE.  Through some dumb luck,
the legacy code swaps out of order endpoints, because old VRP would
sometimes pass endpoints reversed, depending on the setter to fix
them.  This swapping does not happen for non-legacy, hence the ICE.

The right thing to do (apart from killing legacy and 1-bit signed
integers ;-)), is to avoid passing out of order endpoints for 1-bit
signed integers.  For that matter, a range of [-1, 0] (signed) or
[0, 1] (unsigned) is just varying.

PR tree-optimization/107312

gcc/ChangeLog:

* range.h (range_true_and_false): Special case 1-bit signed types.
* value-range.cc (range_tests_misc): New test.

gcc/testsuite/ChangeLog:

* gcc.target/i386/pr107312.c: New test.
---
 gcc/range.h  |  2 ++
 gcc/testsuite/gcc.target/i386/pr107312.c | 11 +++
 gcc/value-range.cc   |  2 ++
 3 files changed, 15 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/i386/pr107312.c

diff --git a/gcc/range.h b/gcc/range.h
index 8138d6f5515..ba3a6b2516f 100644
--- a/gcc/range.h
+++ b/gcc/range.h
@@ -50,6 +50,8 @@ static inline int_range<1>
 range_true_and_false (tree type)
 {
   unsigned prec = TYPE_PRECISION (type);
+  if (prec == 1)
+return int_range<2> (type);
   return int_range<2> (type, wi::zero (prec), wi::one (prec));
 }
 
diff --git a/gcc/testsuite/gcc.target/i386/pr107312.c 
b/gcc/testsuite/gcc.target/i386/pr107312.c
new file mode 100644
index 000..b4180e3bd7d
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr107312.c
@@ -0,0 +1,11 @@
+// { dg-do compile }
+// { dg-options "-mavx512vbmi -O1 -ftree-loop-vectorize" }
+
+void
+foo (_Float16 *r, short int *a)
+{
+  int i;
+
+  for (i = 0; i < 32; ++i)
+r[i] = !!a[i];
+}
diff --git a/gcc/value-range.cc b/gcc/value-range.cc
index 90d5e660684..511cd0ad767 100644
--- a/gcc/value-range.cc
+++ b/gcc/value-range.cc
@@ -3437,6 +3437,8 @@ range_tests_misc ()
 max.union_ (min);
 ASSERT_TRUE (max.varying_p ());
   }
+  // Test that we can set a range of true+false for a 1-bit signed int.
+  r0 = range_true_and_false (one_bit_type);
 
   // Test inversion of 1-bit signed integers.
   {
-- 
2.37.3

Re: [PATCH] c++ modules: verify_type failure with typedef enum [PR106848]

[Patrick Palka via Gcc-patches]

On Wed, 19 Oct 2022, Richard Biener wrote:

> On Tue, Oct 18, 2022 at 8:26 PM Patrick Palka  wrote:
> >
> > On Fri, 14 Oct 2022, Richard Biener wrote:
> >
> > > On Thu, Oct 13, 2022 at 5:40 PM Patrick Palka via Gcc-patches
> > >  wrote:
> > > >
> > > > Here during stream in we end up having created a type variant for the 
> > > > enum
> > > > before we read the enum's definition, and thus the variant inherited 
> > > > stale
> > > > TYPE_VALUES and TYPE_MIN/MAX_VALUES, which leads to an ICE (with -g).  
> > > > The
> > > > stale variant got created from set_underlying_type during earlier 
> > > > stream in
> > > > of the (redundant) typedef for the enum.
> > > >
> > > > This patch works around this by setting TYPE_VALUES and 
> > > > TYPE_MIN/MAX_VALUES
> > > > for all variants when reading in an enum definition.  Does this look 
> > > > like
> > > > the right approach?  Or perhaps we need to arrange that we read the enum
> > > > definition before reading in the typedef decl?  Note that seems to be an
> > > > issue only when the typedef name and enum names are the same (thus the
> > > > typedef is redundant), otherwise we seem to read the enum definition 
> > > > first
> > > > as desired.
> > > >
> > > > PR c++/106848
> > > >
> > > > gcc/cp/ChangeLog:
> > > >
> > > > * module.cc (trees_in::read_enum_def): Set the TYPE_VALUES,
> > > > TYPE_MIN_VALUE and TYPE_MAX_VALUE of all type variants.
> > > >
> > > > gcc/testsuite/ChangeLog:
> > > >
> > > > * g++.dg/modules/enum-9_a.H: New test.
> > > > * g++.dg/modules/enum-9_b.C: New test.
> > > > ---
> > > >  gcc/cp/module.cc| 9 ++---
> > > >  gcc/testsuite/g++.dg/modules/enum-9_a.H | 5 +
> > > >  gcc/testsuite/g++.dg/modules/enum-9_b.C | 6 ++
> > > >  3 files changed, 17 insertions(+), 3 deletions(-)
> > > >  create mode 100644 gcc/testsuite/g++.dg/modules/enum-9_a.H
> > > >  create mode 100644 gcc/testsuite/g++.dg/modules/enum-9_b.C
> > > >
> > > > diff --git a/gcc/cp/module.cc b/gcc/cp/module.cc
> > > > index 7ffeefa7c1f..97fb80bcd44 100644
> > > > --- a/gcc/cp/module.cc
> > > > +++ b/gcc/cp/module.cc
> > > > @@ -12303,9 +12303,12 @@ trees_in::read_enum_def (tree defn, tree 
> > > > maybe_template)
> > > >
> > > >if (installing)
> > > >  {
> > > > -  TYPE_VALUES (type) = values;
> > > > -  TYPE_MIN_VALUE (type) = min;
> > > > -  TYPE_MAX_VALUE (type) = max;
> > > > +  for (tree t = type; t; t = TYPE_NEXT_VARIANT (t))
> > > > +   {
> > > > + TYPE_VALUES (t) = values;
> > > > + TYPE_MIN_VALUE (t) = min;
> > > > + TYPE_MAX_VALUE (t) = max;
> > > > +   }
> > >
> > > it's definitely somewhat ugly but at least type_hash_canon doesn't hash
> > > these for ENUMERAL_TYPE (but it does compare them!  which in principle
> > > means it could as well hash them ...)
> > >
> > > I think that if you read both from the same module that you should arrange
> > > to read what you refer to first?  But maybe that's not the actual issue 
> > > here.
> >
> > *nod* reading in the enum before reading in the typedef seems like
> > the most direct solution, though not sure how to accomplish that :/
> 
> For LTO streaming we DFS walk tree edges from all entries into the tree
> graph we want to stream, collecting and streaming SCCs.  Not sure if
> doing similar for module streaming would help this case though.

FWIW I managed to obtain a more interesting reduction for this ICE, one
that doesn't use a typedef bound to the same name as the enum:

$ cat 106848_a.H
template
struct pair {
  using type = void(*)(const _T1&);
};
struct _ScannerBase {
  enum _TokenT { _S_token_anychar };
  pair<_TokenT> _M_token_tbl;
};

$ cat 106848_b.C
import "106848_a.H";

using type = _ScannerBase;

$ g++ -fmodules-ts -g 106848_a.H 106848_b.C
106848_b.C:3:14: error: type variant differs by TYPE_MAX_VALUE



Like in the less interesting testcase, the problem is ultimately that we
create a variant of the enum (as part of reading in pair<_TokenT>::type)
before reading the enum's definition, thus the variant inherits stale
TYPE_MIN/MAX_VALUE.

Perhaps pair<_TokenT>::type should indirectly depend on the definition
of _TokenT -- but IIUC we generally don't require a type to be defined
in order to refer to it, so enforcing such a dependency would be a
pessimization I think.

So ISTM this isn't a dependency issue (pair<_TokenT>::type already
implicitly depends on the ENUMERAL_TYPE, just not also the enum's
defining TYPE_DECL), and the true issue is that we're streaming
TYPE_MIN/MAX_VALUE only as part of an enum's definition, which the
linked patch fixes.

> 
> > A somewhat orthogonal issue (that incidentally fixes this testcase) is
> > that we stream TYPE_MIN/MAX_VALUE only for enums with a definition, but
> > the frontend sets these fields even for opaque enums.  If we make sure
> > to stream these fields for all ENUMERAL_TYPEs, then we won't have to
> > worry about these fields being stale 

Re: Adding a new thread model to GCC

[Jonathan Yong via Gcc-patches]

On 10/14/22 09:39, Jonathan Yong wrote:

On 10/11/22 13:22, LIU Hao wrote:

在 2022-10-10 23:56, LIU Hao 写道:

在 2022-10-04 20:44, LIU Hao 写道:

Attached are revised patches. These are exported from trunk.



Revised further. The patch for libgfortran has been committed to 
trunk today, so I include only the other two.


   * In the second patch, a space character has been inserted after
 `(int)` for clearness.

   * The macro controlling how to build GCC itself has been renamed to
 `TARGET_USING_MCFGTHREAD` for consistency.

   * Checks against `TARGET_USING_MCFGTHREAD` have been updated in a
 more friendly way.

   * When not using mcfgthread, NTDLL is no longer a default library.
 Although all recent Windows versions are based on the NT kernel,
 there could still be people who want to target 9x or CE; thus
 NTDLL is only added when it is potentially necessary, for example
 when linking against the static libgcc.




Attached is the (previous) third patch, with configure scripts 
regenerated.





Any more comments?


Just pushed to master branch.

[r13-3356 Regression] FAIL: libgomp.c++/loop-14.C (internal compiler error: verify_ssa failed) on Linux/x86_64

[haochen.jiang via Gcc-patches]

On Linux/x86_64,

92ef7822bfd4ea3393e0a1dd40b4abef9fce027f is the first bad commit
commit 92ef7822bfd4ea3393e0a1dd40b4abef9fce027f
Author: Richard Biener 
Date:   Tue Oct 18 10:01:45 2022 +0200

tree-optimization/107302 - fix vec_perm placement for recurrence vect

caused

FAIL: libgomp.c++/loop-13.C execution test
FAIL: libgomp.c++/loop-13.C (internal compiler error: verify_ssa failed)
FAIL: libgomp.c++/loop-13.C (test for excess errors)
FAIL: libgomp.c++/loop-14.C execution test
FAIL: libgomp.c++/loop-14.C (internal compiler error: verify_ssa failed)
FAIL: libgomp.c++/loop-14.C (test for excess errors)

with GCC configured with

../../gcc/configure 
--prefix=/export/users/haochenj/src/gcc-bisect/master/master/r13-3356/usr 
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld 
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl 
--enable-libmpx x86_64-linux --disable-bootstrap

To reproduce:

$ cd {build_dir}/x86_64-linux/libgomp/testsuite && make check 
RUNTESTFLAGS="c++.exp=libgomp.c++/loop-13.C --target_board='unix{-m32\ 
-march=cascadelake}'"
$ cd {build_dir}/x86_64-linux/libgomp/testsuite && make check 
RUNTESTFLAGS="c++.exp=libgomp.c++/loop-13.C --target_board='unix{-m64\ 
-march=cascadelake}'"
$ cd {build_dir}/x86_64-linux/libgomp/testsuite && make check 
RUNTESTFLAGS="c++.exp=libgomp.c++/loop-14.C --target_board='unix{-m32\ 
-march=cascadelake}'"
$ cd {build_dir}/x86_64-linux/libgomp/testsuite && make check 
RUNTESTFLAGS="c++.exp=libgomp.c++/loop-14.C --target_board='unix{-m64\ 
-march=cascadelake}'"

(Please do not reply to this email, for question about this report, contact me 
at haochen dot jiang at intel.com)

Re: [PATCH] libgomp: fix hang on fatal error

[Jakub Jelinek via Gcc-patches]

On Fri, Oct 14, 2022 at 06:04:06PM +0100, Andrew Stubbs wrote:
> This patch fixes a problem in which fatal errors inside mutex-locked regions
> (i.e. basically anything in the plugin) will cause it to hang up trying to
> take the lock to clean everything up.
> 
> Using abort() instead of exit(1) bypasses the atexit handlers and solves the
> problem.
> 
> OK for mainline?
> 
> Andrew

> libgomp: fix hang on fatal error
> 
> Don't try to clean up if a fatal error occurs in libgomp.  Typically the
> cleanup is not reentrant so we end up hung on a lock.
> 
> libgomp/ChangeLog:
> 
>   * error.c (gomp_vfatal): Use abort instead of exit.
> 
> diff --git a/libgomp/error.c b/libgomp/error.c
> index 50ed85eedb1..25548c14a82 100644
> --- a/libgomp/error.c
> +++ b/libgomp/error.c
> @@ -77,7 +77,7 @@ void
>  gomp_vfatal (const char *fmt, va_list list)
>  {
>gomp_verror (fmt, list);
> -  exit (EXIT_FAILURE);
> +  abort ();
>  }
>  
>  void

I don't like this, abort has quite different user visible behavior
from exit, e.g. the former often dumps core.

I believe in most places libgomp handles this by releasing locks before
calling gomp_{,v}fatal:
  gomp_mutex_unlock (®ister_lock);
  gomp_fatal ("Out of memory allocating %lu bytes", (unsigned long) size);

  gomp_mutex_unlock (&devicep->lock);
  gomp_fatal ("Copying of %s object [%p..%p) to %s object [%p..%p) failed",
  src, srcaddr, srcaddr + size, dst, dstaddr, dstaddr + size);

etc.
I could live with a gomp_fatal/gomp_vfatal alternative that would
use _exit/_Exit (but not sure if it is supported on all targets where
libgomp is) for uses where releasing locks is for whatever reason
not an option.

Jakub

Re: [PATCH] c++: Mitigate -Wuseless-cast with classes [PR85043]

[Jason Merrill via Gcc-patches]

On 10/18/22 13:38, Marek Polacek wrote:

-Wuseless-cast (not part of -Wall/-Wextra) warns here:

   struct S { };
   void g (S&&);
   void f (S&& arg)
   {
 g (S(arg)); // warning: useless cast to type 'struct S'
   }

which is wrong: the code will not compile without the cast because
"arg" is an lvalue which cannot bind to S&&.

I'd like to disable the warning when a class object is cast to
a non-reference type, which seems like a minimal patch that fixes the
problems reported in our Bugzilla.  Of course, the cast in "(int)i"
may not be useless, either, but I'm not changing that here.


As I commented on PR 14710, "I wouldn't warn about a cast that changes 
the type or value category of an expression at all"


The code currently checks the value category when casting to a 
reference, but not when casting to a non-reference; that seems like the 
thing to fix.



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

PR c++/85043

gcc/cp/ChangeLog:

* typeck.cc (maybe_warn_about_useless_cast): Don't warn when a class
object is cast to a non-reference type.

gcc/ChangeLog:

* doc/invoke.texi: Update documentation of -Wuseless-cast.

gcc/testsuite/ChangeLog:

* g++.dg/warn/Wuseless-cast.C: Remove dg-warning.
* g++.dg/warn/Wuseless-cast3.C: New test.
---
  gcc/cp/typeck.cc   |  5 +
  gcc/doc/invoke.texi| 13 ++-
  gcc/testsuite/g++.dg/warn/Wuseless-cast.C  |  4 ++--
  gcc/testsuite/g++.dg/warn/Wuseless-cast3.C | 25 ++
  4 files changed, 44 insertions(+), 3 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/warn/Wuseless-cast3.C

diff --git a/gcc/cp/typeck.cc b/gcc/cp/typeck.cc
index da0e1427b97..a7587f56720 100644
--- a/gcc/cp/typeck.cc
+++ b/gcc/cp/typeck.cc
@@ -8104,6 +8104,11 @@ maybe_warn_about_useless_cast (location_t loc, tree 
type, tree expr,
if (warn_useless_cast
&& complain & tf_warning)
  {
+  /* Don't warn when converting a class object to a non-reference type,
+because that's a common way to create a temporary.  */
+  if (!TYPE_REF_P (type) && CLASS_TYPE_P (TREE_TYPE (expr)))
+   return;
+
if ((TYPE_REF_P (type)
   && (TYPE_REF_IS_RVALUE (type)
   ? xvalue_p (expr) : lvalue_p (expr))
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index c176e2dc646..cd4d3c1d72c 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -4551,7 +4551,18 @@ pointers after reallocation.
  @item -Wuseless-cast @r{(C++ and Objective-C++ only)}
  @opindex Wuseless-cast
  @opindex Wno-useless-cast
-Warn when an expression is casted to its own type.
+Warn when an expression is cast to its own type.  This warning does not
+occur when a class object is converted to a non-reference type as that
+is a way to create a temporary:
+
+@smallexample
+struct S @{ @};
+void g (S&&);
+void f (S&& arg)
+@{
+  g (S(arg)); // make arg prvalue so that it can bind to S&&
+@}
+@end smallexample
  
  @item -Wno-conversion-null @r{(C++ and Objective-C++ only)}

  @opindex Wconversion-null
diff --git a/gcc/testsuite/g++.dg/warn/Wuseless-cast.C 
b/gcc/testsuite/g++.dg/warn/Wuseless-cast.C
index 2fd6bc45102..6084b4cef49 100644
--- a/gcc/testsuite/g++.dg/warn/Wuseless-cast.C
+++ b/gcc/testsuite/g++.dg/warn/Wuseless-cast.C
@@ -100,8 +100,8 @@ void f()
  
A a;
  
-  (A)(a); // { dg-warning "3:useless cast" }

-  static_cast(a);  // { dg-warning "3:useless cast" }
+  (A)(a);
+  static_cast(a);
  
(A*)(&a);   // { dg-warning "3:useless cast" }

const_cast(&a); // { dg-warning "3:useless cast" }
diff --git a/gcc/testsuite/g++.dg/warn/Wuseless-cast3.C 
b/gcc/testsuite/g++.dg/warn/Wuseless-cast3.C
new file mode 100644
index 000..2db07de731f
--- /dev/null
+++ b/gcc/testsuite/g++.dg/warn/Wuseless-cast3.C
@@ -0,0 +1,25 @@
+// PR c++/85043
+// { dg-do compile { target c++11 } }
+// { dg-options "-Wuseless-cast" }
+
+struct S { int s; void bump () { s++; } };
+
+void
+foo ()
+{
+  S s = { 1 };
+  s.bump ();
+  S (s).bump (); // { dg-bogus "useless" }
+  ((S) s).bump (); // { dg-bogus "useless" }
+  static_cast (s).bump (); // { dg-bogus "useless" }
+}
+
+struct X { };
+void g(X&&);
+
+void
+f (X&& arg)
+{
+  g(X(arg)); // { dg-bogus "useless" }
+  g(static_cast(arg));
+}

base-commit: 885b6660c17fb91980b5682514ef54668e544b02

[PATCH (pushed)] avr: remove useless @tie{} directives

[Martin Liška]

gcc/ChangeLog:

* doc/extend.texi: Remove useless @tie{} directives.
---
 gcc/doc/extend.texi | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index cfbe32afce9..04af0584d82 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -7900,7 +7900,7 @@ This attribute works similar to the @code{section} 
attribute
 but adds additional checking.
 
 @table @asis
-@item @bullet{}@tie{} Ordinary AVR cores with 32 general purpose registers:
+@item @bullet{} Ordinary AVR cores with 32 general purpose registers:
 @code{progmem} affects the location
 of the data but not how this data is accessed.
 In order to read data located with the @code{progmem} attribute
@@ -7925,7 +7925,7 @@ normally resides in the data memory (RAM).
 See also the @ref{AVR Named Address Spaces} section for
 an alternate way to locate and access data in flash memory.
 
-@item @bullet{}@tie{} AVR cores with flash memory visible in the RAM address 
range:
+@item @bullet{} AVR cores with flash memory visible in the RAM address range:
 On such devices, there is no need for attribute @code{progmem} or
 @ref{AVR Named Address Spaces,,@code{__flash}} qualifier at all.
 Just use standard C / C++.  The compiler will generate @code{LD*}
@@ -7938,7 +7938,7 @@ avoiding @code{progmem} and @code{__flash}.  This applies 
to devices from
 families @code{avrtiny} and @code{avrxmega3}, see @ref{AVR Options} for
 an overview.
 
-@item @bullet{}@tie{}Reduced AVR Tiny cores like ATtiny40:
+@item @bullet{} Reduced AVR Tiny cores like ATtiny40:
 The compiler adds @code{0x4000}
 to the addresses of objects and declarations in @code{progmem} and locates
 the objects in flash memory, namely in section @code{.progmem.data}.
-- 
2.38.0

[PATCH] libstdc++-v3: Some std::*float*_t charconv and i/ostream overloads

[Jakub Jelinek via Gcc-patches]

Hi!

The following patch adds the easy part of ,  and
 changes for extended floats.
In particular, for the first one only overloads where the _Float* has
the same format as float/double/long double and for the latter two
everything but the _GLIBCXX_HAVE_FLOAT128_MATH case.
For charconv, I'm not really familiar with it, I'm pretty sure
we need new libstdc++.so.6 side implementation of from_chars for
{,b}float16_t and for to_chars not really sure but for unspecified precision
if it should emit minimum characters that to_chars then can unambiguously
parse, I think it is less than in the float case.  For float128_t
{to,from}_chars I think we even have it on the library side already, just
ifdefed for powerpc64le only.
For i/o stream operator<>, not sure what is better, if not providing
anything at all, or doing what we in the end do if user doesn't override
the virtual functions, or use {to,from}_chars under the hood, something
else?
Besides this, the patch adds some further missed
// { dg-options "-std=gnu++2b" }
spots, I've also noticed I got the formatting wrong in some testcases
by not using spaces around VERIFY conditions and elsewhere by having
space before ( for calls.
The testsuite coverage is limited, I've added test for from_chars because
it was easy to port, but not really sure what to do about to_chars, it has
for float/double huge testcases which would be excessive to repeat.
And for i/ostream not really sure what exactly is worth testing.

Tested on x86_64-linux with --target_board=unix/-std=gnu++23, ok for trunk?

2022-10-19  Jakub Jelinek  

* include/std/charconv (from_chars, to_chars): Add _Float{32,64,128}
overloads for cases where those types match {float,double,long double}.
* include/std/istream (basic_istream::operator>>): Add
_Float{16,32,64,128} and __gnu_cxx::__bfloat16_t overloads.
* include/std/ostream (basic_ostream::operator<<): Add
_Float{16,32,64,128} and __gnu_cxx::__bfloat16_t overloads.
* testsuite/20_util/from_chars/8.cc: New test.
* testsuite/26_numerics/headers/cmath/nextafter_c++23.cc (test):
Formatting fixes.
* testsuite/26_numerics/headers/cmath/functions_std_c++23.cc: Add
dg-options "-std=gnu++2b".
(test_functions, main): Formatting fixes.
* 
testsuite/26_numerics/headers/cmath/c99_classification_macros_c++23.cc:
Add dg-options "-std=gnu++2b".

--- libstdc++-v3/include/std/charconv.jj2022-10-17 12:29:33.805012519 
+0200
+++ libstdc++-v3/include/std/charconv   2022-10-19 11:54:03.049992722 +0200
@@ -675,6 +675,45 @@ namespace __detail
   from_chars_result
   from_chars(const char* __first, const char* __last, long double& __value,
 chars_format __fmt = chars_format::general) noexcept;
+
+#if defined(__STDCPP_FLOAT32_T__) && defined(_GLIBCXX_FLOAT_IS_IEEE_BINARY32)
+  inline from_chars_result
+  from_chars(const char* __first, const char* __last, _Float32& __value,
+chars_format __fmt = chars_format::general) noexcept
+  {
+float __val;
+from_chars_result __res = from_chars(__first, __last, __val, __fmt);
+if (__res.ec == errc{})
+  __value = __val;
+return __res;
+  }
+#endif
+
+#if defined(__STDCPP_FLOAT64_T__) && defined(_GLIBCXX_DOUBLE_IS_IEEE_BINARY64)
+  inline from_chars_result
+  from_chars(const char* __first, const char* __last, _Float64& __value,
+chars_format __fmt = chars_format::general) noexcept
+  {
+double __val;
+from_chars_result __res = from_chars(__first, __last, __val, __fmt);
+if (__res.ec == errc{})
+  __value = __val;
+return __res;
+  }
+#endif
+
+#if defined(__STDCPP_FLOAT128_T__) && 
defined(_GLIBCXX_LDOUBLE_IS_IEEE_BINARY128)
+  inline from_chars_result
+  from_chars(const char* __first, const char* __last, _Float128& __value,
+chars_format __fmt = chars_format::general) noexcept
+  {
+long double __val;
+from_chars_result __res = from_chars(__first, __last, __val, __fmt);
+if (__res.ec == errc{})
+  __value = __val;
+return __res;
+  }
+#endif
 #endif
 
 #if defined __cpp_lib_to_chars
@@ -701,6 +740,53 @@ namespace __detail
   chars_format __fmt) noexcept;
   to_chars_result to_chars(char* __first, char* __last, long double __value,
   chars_format __fmt, int __precision) noexcept;
+
+#if defined(__STDCPP_FLOAT32_T__) && defined(_GLIBCXX_FLOAT_IS_IEEE_BINARY32)
+  inline to_chars_result
+  to_chars(char* __first, char* __last, _Float32 __value) noexcept
+  { return to_chars(__first, __last, float(__value)); }
+  inline to_chars_result
+  to_chars(char* __first, char* __last, _Float32 __value,
+  chars_format __fmt) noexcept
+  { return to_chars(__first, __last, float(__value), __fmt); }
+  inline to_chars_result
+  to_chars(char* __first, char* __last, _Float32 __value,
+  chars_format __fmt, int __precision) noexcept
+  { return to_chars(__first, __last, 

Re: [PATCH] pch: Fix streaming of strings with embedded null bytes

[Lewis Hyatt via Gcc-patches]

On Wed, Oct 19, 2022 at 8:23 AM Jakub Jelinek  wrote:
>
> On Wed, Oct 19, 2022 at 01:17:02PM +0100, Richard Sandiford wrote:
> > Jakub Jelinek  writes:
> > > On Wed, Oct 19, 2022 at 12:54:11PM +0100, Richard Sandiford via 
> > > Gcc-patches wrote:
> > >> Lewis Hyatt via Gcc-patches  writes:
> > >> > When a GTY'ed struct is streamed to PCH, any plain char* pointers it 
> > >> > contains
> > >> > (whether they live in GC-controlled memory or not) will be marked for 
> > >> > PCH
> > >> > output by the routine gt_pch_note_object in ggc-common.cc. This routine
> > >> > special-cases plain char* strings, and in particular it uses strlen() 
> > >> > to get
> > >> > their length. Thus it does not handle strings with embedded null 
> > >> > bytes, but it
> > >> > is possible for something PCH cares about (such as a string literal 
> > >> > token in a
> > >> > macro definition) to contain such embedded nulls. To fix that up, add 
> > >> > a new
> > >> > GTY option "string_length" so that gt_pch_note_object can be informed 
> > >> > the
> > >> > actual length it ought to use, and use it in the relevant libcpp 
> > >> > structs
> > >> > (cpp_string and ht_identifier) accordingly.
> > >>
> > >> This isn't really my area, as I'm about to demonstrate with this
> > >> question, but: regarding
> > >>
> > >>   if (note_ptr_fn == gt_pch_p_S)
> > >> (*slot)->size = strlen ((const char *)obj) + 1;
> > >>   else
> > >> (*slot)->size = ggc_get_size (obj);
> > >>
> > >> do you know why the PCH code goes out of its way to handle the sizes of
> > >> strings specially?  Are there enough garbage strings in the string pool
> > >> that it's worth optimising the size of the saved memory for strings but
> > >> not for other types of object?  Or is the gt_pch_p_S test needed for
> > >> correctness, rather than just being an optimisation?
> > >
> > > Just guessing, not all GC strings live in the stringpool.
> > > Isn't e.g. ggc_strdup just a GC allocation where the string length
> > > isn't stored anywhere?
> >
> > Is that different from other GC VLA allocations though?  I thought
> > ultimately we just tried to save and restore the containing pages.
>
> I think just the objects in it, not entire pages (ggc_get_size (obj)
> sized chunks for non-strings).
>
> > > And sometimes it isn't even GC allocated, e.g. ggc_strdup ("") just
> > > returns ""; I guess const char * pointers in GC memory can also point
> > > to string literals in .rodata and for PCH we move them.
> >
> > Ah, OK, that would definitely explain it, thanks.  In that case,
> > are you OK with the patch, as a way of continuing to support rodata
> > string pointers while also allowing embedded nuls?
>
> LGTM.
>

Thank you both very much, I will push that then.
My understanding is that a GTY()ed struct can contain arbitrary char*
pointers as a special case, they need not be in the string pool. They
will be silently ignored by GC marking routines if they are not within
ggc's pages (as opposed to any other pointer, which will abort if it
wasn't under ggc's control), and they will make it into PCH by the
gt_pch_note_object mechanism. For example, struct line_maps contains a
char* to store the file name for each map, which is just an ordinary
malloc()ed string owned by the cpp_reader object.

-Lewis

Re: Announcement: Porting the Docs to Sphinx - 9. November 2022

[Martin Liška]

On 10/19/22 13:09, Martin Liška wrote:
> There ePUB would be likely better output format. What do you think?

I've just included ePUB books:
https://splichal.eu/scripts/sphinx/#epub

Martin

Re: [PATCH] pch: Fix streaming of strings with embedded null bytes

[Jakub Jelinek via Gcc-patches]

On Wed, Oct 19, 2022 at 01:17:02PM +0100, Richard Sandiford wrote:
> Jakub Jelinek  writes:
> > On Wed, Oct 19, 2022 at 12:54:11PM +0100, Richard Sandiford via Gcc-patches 
> > wrote:
> >> Lewis Hyatt via Gcc-patches  writes:
> >> > When a GTY'ed struct is streamed to PCH, any plain char* pointers it 
> >> > contains
> >> > (whether they live in GC-controlled memory or not) will be marked for PCH
> >> > output by the routine gt_pch_note_object in ggc-common.cc. This routine
> >> > special-cases plain char* strings, and in particular it uses strlen() to 
> >> > get
> >> > their length. Thus it does not handle strings with embedded null bytes, 
> >> > but it
> >> > is possible for something PCH cares about (such as a string literal 
> >> > token in a
> >> > macro definition) to contain such embedded nulls. To fix that up, add a 
> >> > new
> >> > GTY option "string_length" so that gt_pch_note_object can be informed the
> >> > actual length it ought to use, and use it in the relevant libcpp structs
> >> > (cpp_string and ht_identifier) accordingly.
> >> 
> >> This isn't really my area, as I'm about to demonstrate with this
> >> question, but: regarding
> >> 
> >>   if (note_ptr_fn == gt_pch_p_S)
> >> (*slot)->size = strlen ((const char *)obj) + 1;
> >>   else
> >> (*slot)->size = ggc_get_size (obj);
> >> 
> >> do you know why the PCH code goes out of its way to handle the sizes of
> >> strings specially?  Are there enough garbage strings in the string pool
> >> that it's worth optimising the size of the saved memory for strings but
> >> not for other types of object?  Or is the gt_pch_p_S test needed for
> >> correctness, rather than just being an optimisation?
> >
> > Just guessing, not all GC strings live in the stringpool.
> > Isn't e.g. ggc_strdup just a GC allocation where the string length
> > isn't stored anywhere?
> 
> Is that different from other GC VLA allocations though?  I thought
> ultimately we just tried to save and restore the containing pages.

I think just the objects in it, not entire pages (ggc_get_size (obj)
sized chunks for non-strings).

> > And sometimes it isn't even GC allocated, e.g. ggc_strdup ("") just
> > returns ""; I guess const char * pointers in GC memory can also point
> > to string literals in .rodata and for PCH we move them.
> 
> Ah, OK, that would definitely explain it, thanks.  In that case,
> are you OK with the patch, as a way of continuing to support rodata
> string pointers while also allowing embedded nuls?

LGTM.

Jakub

Re: [PATCH] pch: Fix streaming of strings with embedded null bytes

[Richard Sandiford via Gcc-patches]

Jakub Jelinek  writes:
> On Wed, Oct 19, 2022 at 12:54:11PM +0100, Richard Sandiford via Gcc-patches 
> wrote:
>> Lewis Hyatt via Gcc-patches  writes:
>> > When a GTY'ed struct is streamed to PCH, any plain char* pointers it 
>> > contains
>> > (whether they live in GC-controlled memory or not) will be marked for PCH
>> > output by the routine gt_pch_note_object in ggc-common.cc. This routine
>> > special-cases plain char* strings, and in particular it uses strlen() to 
>> > get
>> > their length. Thus it does not handle strings with embedded null bytes, 
>> > but it
>> > is possible for something PCH cares about (such as a string literal token 
>> > in a
>> > macro definition) to contain such embedded nulls. To fix that up, add a new
>> > GTY option "string_length" so that gt_pch_note_object can be informed the
>> > actual length it ought to use, and use it in the relevant libcpp structs
>> > (cpp_string and ht_identifier) accordingly.
>> 
>> This isn't really my area, as I'm about to demonstrate with this
>> question, but: regarding
>> 
>>   if (note_ptr_fn == gt_pch_p_S)
>> (*slot)->size = strlen ((const char *)obj) + 1;
>>   else
>> (*slot)->size = ggc_get_size (obj);
>> 
>> do you know why the PCH code goes out of its way to handle the sizes of
>> strings specially?  Are there enough garbage strings in the string pool
>> that it's worth optimising the size of the saved memory for strings but
>> not for other types of object?  Or is the gt_pch_p_S test needed for
>> correctness, rather than just being an optimisation?
>
> Just guessing, not all GC strings live in the stringpool.
> Isn't e.g. ggc_strdup just a GC allocation where the string length
> isn't stored anywhere?

Is that different from other GC VLA allocations though?  I thought
ultimately we just tried to save and restore the containing pages.

> And sometimes it isn't even GC allocated, e.g. ggc_strdup ("") just
> returns ""; I guess const char * pointers in GC memory can also point
> to string literals in .rodata and for PCH we move them.

Ah, OK, that would definitely explain it, thanks.  In that case,
are you OK with the patch, as a way of continuing to support rodata
string pointers while also allowing embedded nuls?

Richard

Re: [PATCH] pch: Fix streaming of strings with embedded null bytes

[Jakub Jelinek via Gcc-patches]

On Wed, Oct 19, 2022 at 12:54:11PM +0100, Richard Sandiford via Gcc-patches 
wrote:
> Lewis Hyatt via Gcc-patches  writes:
> > When a GTY'ed struct is streamed to PCH, any plain char* pointers it 
> > contains
> > (whether they live in GC-controlled memory or not) will be marked for PCH
> > output by the routine gt_pch_note_object in ggc-common.cc. This routine
> > special-cases plain char* strings, and in particular it uses strlen() to get
> > their length. Thus it does not handle strings with embedded null bytes, but 
> > it
> > is possible for something PCH cares about (such as a string literal token 
> > in a
> > macro definition) to contain such embedded nulls. To fix that up, add a new
> > GTY option "string_length" so that gt_pch_note_object can be informed the
> > actual length it ought to use, and use it in the relevant libcpp structs
> > (cpp_string and ht_identifier) accordingly.
> 
> This isn't really my area, as I'm about to demonstrate with this
> question, but: regarding
> 
>   if (note_ptr_fn == gt_pch_p_S)
> (*slot)->size = strlen ((const char *)obj) + 1;
>   else
> (*slot)->size = ggc_get_size (obj);
> 
> do you know why the PCH code goes out of its way to handle the sizes of
> strings specially?  Are there enough garbage strings in the string pool
> that it's worth optimising the size of the saved memory for strings but
> not for other types of object?  Or is the gt_pch_p_S test needed for
> correctness, rather than just being an optimisation?

Just guessing, not all GC strings live in the stringpool.
Isn't e.g. ggc_strdup just a GC allocation where the string length
isn't stored anywhere?  And sometimes it isn't even GC allocated,
e.g. ggc_strdup ("") just returns "";
I guess const char * pointers in GC memory can also point to string literals
in .rodata and for PCH we move them.

Jakub

Re: [PATCH] pch: Fix streaming of strings with embedded null bytes

[Richard Sandiford via Gcc-patches]

Lewis Hyatt via Gcc-patches  writes:
> When a GTY'ed struct is streamed to PCH, any plain char* pointers it contains
> (whether they live in GC-controlled memory or not) will be marked for PCH
> output by the routine gt_pch_note_object in ggc-common.cc. This routine
> special-cases plain char* strings, and in particular it uses strlen() to get
> their length. Thus it does not handle strings with embedded null bytes, but it
> is possible for something PCH cares about (such as a string literal token in a
> macro definition) to contain such embedded nulls. To fix that up, add a new
> GTY option "string_length" so that gt_pch_note_object can be informed the
> actual length it ought to use, and use it in the relevant libcpp structs
> (cpp_string and ht_identifier) accordingly.

This isn't really my area, as I'm about to demonstrate with this
question, but: regarding

  if (note_ptr_fn == gt_pch_p_S)
(*slot)->size = strlen ((const char *)obj) + 1;
  else
(*slot)->size = ggc_get_size (obj);

do you know why the PCH code goes out of its way to handle the sizes of
strings specially?  Are there enough garbage strings in the string pool
that it's worth optimising the size of the saved memory for strings but
not for other types of object?  Or is the gt_pch_p_S test needed for
correctness, rather than just being an optimisation?

The special case has been there since the initial version, so there's
not much history to go from.

If using specific sizes for strings is still needed or worthwhile, then
the patch looks good to me.  (And I agree using a new option is better
than overloading "length".)  But since the patch involves adding an
extra argument to gt_pch_note_object, I just wanted to check that we
still had a good reason for handling strings differently.

Thanks,
Richard

> gcc/ChangeLog:
>
>   * gengtype.cc (output_escaped_param): Add missing const.
>   (get_string_option): Add missing check for option type.
>   (walk_type): Support new "string_length" GTY option.
>   (write_types_process_field): Likewise.
>   * ggc-common.cc (gt_pch_note_object): Add optional length argument.
>   * ggc.h (gt_pch_note_object): Adjust prototype for new argument.
>   (gt_pch_n_S2): Declare...
>   * stringpool.cc (gt_pch_n_S2): ...new function.
>   * doc/gty.texi: Document new GTY((string_length)) option.
>
> libcpp/ChangeLog:
>
>   * include/cpplib.h (struct cpp_string): Use new "string_length" GTY.
>   * include/symtab.h (struct ht_identifier): Likewise.
>
> gcc/testsuite/ChangeLog:
>
>   * g++.dg/pch/pch-string-nulls.C: New test.
>   * g++.dg/pch/pch-string-nulls.Hs: New test.
> ---
>
> Notes:
> Hello-
> 
> This fixes a small glitch with PCH files that I doubt matters in
> practice. However, the new GTY((string_length)) option I think should be 
> also
> useful for other things (including for another patch I am working on), 
> and it
> seems worth fixing to me anyway.  Please let me know if it looks OK, or 
> if you'd
> prefer another approach? I did consider reusing GTY((length)) for this 
> purpose
> but it seemed much more straightforward to do it with a new option, and 
> it's
> really about something different since it isn't related to marking of
> GC-controlled memory.
> 
> BTW, the testcase (pch-string-nulls.Hs) needs to have a literal null byte 
> in
> it. That wasn't emailing well so I temporarily have it as the string "^@" 
> in
> this patch, for illustration.
> 
> Bootstrap + regtest all languages looks good on x86-64 Linux. Thanks!
> 
> -Lewis
>
>  gcc/doc/gty.texi | 21 +++-
>  gcc/gengtype.cc  | 25 
>  gcc/ggc-common.cc|  7 --
>  gcc/ggc.h|  4 +++-
>  gcc/stringpool.cc|  7 ++
>  gcc/testsuite/g++.dg/pch/pch-string-nulls.C  |  3 +++
>  gcc/testsuite/g++.dg/pch/pch-string-nulls.Hs |  2 ++
>  libcpp/include/cpplib.h  |  6 -
>  libcpp/include/symtab.h  |  5 +++-
>  9 files changed, 70 insertions(+), 10 deletions(-)
>  create mode 100644 gcc/testsuite/g++.dg/pch/pch-string-nulls.C
>  create mode 100644 gcc/testsuite/g++.dg/pch/pch-string-nulls.Hs
>
> diff --git a/gcc/doc/gty.texi b/gcc/doc/gty.texi
> index 81aafd11ce3..4f791b300ba 100644
> --- a/gcc/doc/gty.texi
> +++ b/gcc/doc/gty.texi
> @@ -196,7 +196,26 @@ static GTY((length("reg_known_value_size"))) rtx 
> *reg_known_value;
>  Note that the @code{length} option is only meant for use with arrays of
>  non-atomic objects, that is, objects that contain pointers pointing to
>  other GTY-managed objects.  For other GC-allocated arrays and strings
> -you should use @code{atomic}.
> +you should use @code{atomic} or @code{string_length}.
> +
> +@findex string_length
> +@item string_length ("@var{expression}")
> +
> +In

Re: [PATCH v3] xtensa: Prepare the transition from Reload to LRA

[Max Filippov via Gcc-patches]

On Wed, Oct 19, 2022 at 1:16 AM Takayuki 'January June' Suwa
 wrote:
> This patch provides the first step in the transition from Reload to LRA
> in Xtensa.
>
> gcc/ChangeLog:
>
> * config/xtensa/xtensa-proto.h
> (xtensa_split1_finished_p, xtensa_split_DI_reg_imm): New prototypes.
> * config/xtensa/xtensa.cc
> (xtensa_split1_finished_p, xtensa_split_DI_reg_imm, xtensa_lra_p):
> New functions.
> (TARGET_LRA_P): Replace the dummy hook with xtensa_lra_p.
> (xt_true_regnum): Rework.
> * gcc/config/xtensa/xtensa.h (CALL_REALLY_USED_REGISTERS):
> Switch from CALL_USED_REGISTERS, and revise the comment.
> * gcc/config/xtensa/constraints.md (Y):
> Use !xtensa_split1_finished_p() instead of can_create_pseudo_p().
> * gcc/config/xtensa/predicates.md (move_operand): Ditto.
> * gcc/config/xtensa/xtensa.md: Add two new split patterns:
>   - splits DImode immediate load into two SImode ones
>   - puts out-of-constraint SImode constants into the constant pool
> * gcc/config/xtensa/xtensa.opt (-mlra): New target-specific option
> for testing purpose.
> ---
>  gcc/config/xtensa/constraints.md  |  2 +-
>  gcc/config/xtensa/predicates.md   |  2 +-
>  gcc/config/xtensa/xtensa-protos.h |  2 +
>  gcc/config/xtensa/xtensa.cc   | 69 ++-
>  gcc/config/xtensa/xtensa.h|  8 ++--
>  gcc/config/xtensa/xtensa.md   | 36 
>  gcc/config/xtensa/xtensa.opt  |  4 ++
>  7 files changed, 99 insertions(+), 24 deletions(-)

Regtested for target=xtensa-linux-uclibc, no new regressions.
Committed to master after fixing the changelog.

-- 
Thanks.
-- Max

[Patch] Fortran: Fix non_negative_strides_array_p

[Tobias Burnus]

First, I am woefully aware that there several patches pending. I hope to do a
couple of reviews later today or in the next days.

Otherwise, I did run into another issue in existing code which was exposed by
the delinearization patch on the OG12 branch, but could potentially lead to
wrong code on mainline as well, depending on how the return value is used.
Albeit I did fail to create a testcase for it.

OK for mainline?

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

The non_negative_strides_array_p function might return wrongly 'true', e.g.
for assumed-shape arrays, if the argument is '*a.0 ...' instead of 'a.0 ...'
as then the saved array descriptor for the PARAM_DECL 'a' is not found.

This potentially leads to wrong code - but I could not find a testcase
leading to wrong code on mainline. Asserts show that this happens with
CLASS; however, for those no ARRAY_REF seems to get used.

The issue show up when applying the delinearization patch as posted
at https://gcc.gnu.org/pipermail/gcc-patches/2020-December/562230.html
that has been applied to the OG12 alias devel/omp/gcc-12 vendor branch, as
commit 39a8c371fda6136cf77c74895a00b136409e0ba3. This patch calls
gfc_build_array_ref inside gfc_conv_array_ref. The issue mentioned
above show up with this patch in gfortran.dg/array_reference_3.f90,
a testcase added together with non_negative_strides_array_p in commit
r12-8230-g7964ab6c364 for PR 102043. Here, non_negative_strides_array_p
returns true for assumed_shape_x but assumed shape arrays may have
negative strides.

gcc/fortran/ChangeLog:

	* trans-array.cc (non_negative_strides_array_p): Fix handling
	of GFC_DECL_SAVED_DESCRIPTOR.

 gcc/fortran/trans-array.cc | 15 ++-
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/gcc/fortran/trans-array.cc b/gcc/fortran/trans-array.cc
index 795ce14af08..ca3503b7cae 100644
--- a/gcc/fortran/trans-array.cc
+++ b/gcc/fortran/trans-array.cc
@@ -3695,11 +3695,16 @@ non_negative_strides_array_p (tree expr)
 
   /* If the array was originally a dummy with a descriptor, strides can be
  negative.  */
-  if (DECL_P (expr)
-  && DECL_LANG_SPECIFIC (expr)
-  && GFC_DECL_SAVED_DESCRIPTOR (expr)
-  && GFC_DECL_SAVED_DESCRIPTOR (expr) != expr)
-return non_negative_strides_array_p (GFC_DECL_SAVED_DESCRIPTOR (expr));
+  tree decl = expr;
+  STRIP_NOPS (decl);
+  if (TREE_CODE (decl) == INDIRECT_REF)
+decl = TREE_OPERAND (decl, 0);
+
+  if (DECL_P (decl)
+  && DECL_LANG_SPECIFIC (decl)
+  && GFC_DECL_SAVED_DESCRIPTOR (decl)
+  && GFC_DECL_SAVED_DESCRIPTOR (decl) != expr)
+return non_negative_strides_array_p (GFC_DECL_SAVED_DESCRIPTOR (decl));
 
   return true;
 }

Re: Announcement: Porting the Docs to Sphinx - 9. November 2022

[Martin Liška]

On 10/18/22 00:26, Sandra Loosemore wrote:
> On 10/17/22 07:28, Martin Liška wrote:
>> Hello.
>>
>> Based on the very positive feedback I was given at the Cauldron Sphinx 
>> Documentation BoF,
>> I'm planning migrating the documentation on 9th November. There are still 
>> some minor comments
>> from Sandra when it comes to the PDF output, but we can address that once 
>> the conversion is done.
> 
> My main complaint about the PDF is that the blue color used for link text is 
> so light it interferes with readability.  Few people are going to print the 
> document on paper any more, but I did try printing a sample page on a 
> grayscale printer and the blue link text came out so faint that it was barely 
> visible at all.

Sure, I've just added support for monochromatic PDF output where one needs to 
use
MONOCHROMATIC=1 make latexpdf ...

and I linked the file here:
https://splichal.eu/scripts/sphinx/gcc/_build/latexmonochromatic/gcc.pdf

right now I build only one PDF in this mode and it's mentioned here:
https://splichal.eu/scripts/sphinx/

What do you think about it now?

>  An E-ink reader device would probably have similar problems.

There ePUB would be likely better output format. What do you think?

Martin

> 
> I'm generally not a fan of the other colors being used for formatting, 
> either.  To me it seems like they all interfere with readability, plus in 
> code samples it seems like random things get highlighted in random colors, 
> instead of focusing on the thing the example is trying to demonstrate.
> 
> I've been preferring to use the PDF form of the GNU manuals because it is 
> easier to search the whole document that way.  The search feature in the new 
> web version doesn't quite cut it  it gives you a list of web pages and 
> then you have to do a second browser search within each page to find the 
> reference.  So I hope we can continue to support the PDF as a canonical 
> format and better tune it for easy readability, instead of assuming that most 
> people will only care about the online web version.
> 
> -Sandra
> 
> 
> 
> 

Re: [PATCH 0/6] Add Intel Sierra Forest Instructions

[Iain Sandoe via Gcc-patches]

Hi Hongtao

> On 17 Oct 2022, at 02:56, Hongtao Liu  wrote:
> 
> On Mon, Oct 17, 2022 at 9:30 AM Bernhard Reutner-Fischer
>  wrote:
>> 
>> On 17 October 2022 03:02:22 CEST, Hongtao Liu via Gcc-patches
>> 
>> Do you have this series as a branch somewhere that I can try on one of 
>> the
>> like affected platforms?
> 
> Not yet.
> Do we have any external place to put those patches so folks from the
> community can validate before it's committed, HJ?
>> 
>> 
>> https://gcc.gnu.org/gitwrite.html#vendor
>> 
>> Not sure where in cgit the user branches are visible, though? But they can 
>> certainly be cloned and worked with.
> Thanks for the reminder, I've pushed to remotes/vendors/ix86/ise046.
> * [new ref] refs/vendors/ix86/heads/ise046 ->
> vendors/ix86/ise046

thanks for pushing this branch, much better to test these things before 
committing rather than a panic
to fix after…


with
f90df941532 (HEAD -> ise046, vendors/ix86/ise046) Add m_CORE_ATOM for atom cores

 - on x86_64 Darwin19  I get the following bootstrap fail:

In file included from /src-local/gcc-master/gcc/config/i386/driver-i386.cc:31:
/src-local/gcc-master/gcc/common/config/i386/cpuinfo.h: In function ‘const 
char* get_intel_cpu(__processor_model*, __processor_model2*, unsigned int*)’:
/src-local/gcc-master/gcc/common/config/i386/cpuinfo.h:532:32: error: this 
statement may fall through [-Werror=implicit-fallthrough=]
  532 |   cpu_model->__cpu_subtype = INTEL_COREI7_GRANITERAPIDS;
  |   ~^~~~
/src-local/gcc-master/gcc/common/config/i386/cpuinfo.h:533:5: note: here
  533 | case 0xb6:
  | ^~~~
cc1plus: all warnings being treated as errors


Will try to look later, if that does not immediately ring some bell.
thanks
Iain

Re: [PATCH] arm: Allow to override location of .gnu.sgstubs section

[Torbjorn SVENSSON via Gcc-patches]

Hi Christophe,

On 2022-10-19 11:52, Christophe Lyon wrote:

Hi Torbjörn,

This looks like a nice improvement to me ;-)

On 10/19/22 11:42, Torbjörn SVENSSON via Gcc-patches wrote:

Depending on the DejaGNU board definition, the .gnu.sgstubs section
might be placed on different locations in order to suite the target.

typo: suite -> suit


With this patch, the start location of the section is overrideable
from the board definition with the fallback of the previously
hardcoded location.

gcc/testsuite/ChangeLog:

* gcc.target/arm/cmse/bitfield-1.c: Use overridable location.
* gcc.target/arm/cmse/bitfield-2.c: Likewise.
* gcc.target/arm/cmse/bitfield-3.c: Likewise.
* gcc.target/arm/cmse/cmse-20.c: Likewise.
* gcc.target/arm/cmse/struct-1.c: Likewise.
* gcc.target/arm/cmse/cmse.exp (cmse_sgstubs): New.

Signed-off-by: Torbjörn SVENSSON 
---
  gcc/testsuite/gcc.target/arm/cmse/bitfield-1.c |  2 +-
  gcc/testsuite/gcc.target/arm/cmse/bitfield-2.c |  2 +-
  gcc/testsuite/gcc.target/arm/cmse/bitfield-3.c |  2 +-
  gcc/testsuite/gcc.target/arm/cmse/cmse-20.c    |  2 +-
  gcc/testsuite/gcc.target/arm/cmse/cmse.exp | 11 +++
  gcc/testsuite/gcc.target/arm/cmse/struct-1.c   |  2 +-
  6 files changed, 16 insertions(+), 5 deletions(-)

diff --git a/gcc/testsuite/gcc.target/arm/cmse/bitfield-1.c 
b/gcc/testsuite/gcc.target/arm/cmse/bitfield-1.c

index 5685f744435..c1221bef29f 100644
--- a/gcc/testsuite/gcc.target/arm/cmse/bitfield-1.c
+++ b/gcc/testsuite/gcc.target/arm/cmse/bitfield-1.c
@@ -1,5 +1,5 @@
  /* This test is executed only if the execution engine supports CMSE 
instructions.  */
-/* { dg-options "--save-temps -mcmse 
-Wl,--section-start,.gnu.sgstubs=0x0040" } */
+/* { dg-options "--save-temps -mcmse 
-Wl,--section-start,.gnu.sgstubs=[cmse_sgstubs]" } */

  typedef struct
  {
diff --git a/gcc/testsuite/gcc.target/arm/cmse/bitfield-2.c 
b/gcc/testsuite/gcc.target/arm/cmse/bitfield-2.c

index 7a794d44644..79e9a3efc93 100644
--- a/gcc/testsuite/gcc.target/arm/cmse/bitfield-2.c
+++ b/gcc/testsuite/gcc.target/arm/cmse/bitfield-2.c
@@ -1,5 +1,5 @@
  /* This test is executed only if the execution engine supports CMSE 
instructions.  */
-/* { dg-options "--save-temps -mcmse 
-Wl,--section-start,.gnu.sgstubs=0x0040" } */
+/* { dg-options "--save-temps -mcmse 
-Wl,--section-start,.gnu.sgstubs=[cmse_sgstubs]" } */

  typedef struct
  {
diff --git a/gcc/testsuite/gcc.target/arm/cmse/bitfield-3.c 
b/gcc/testsuite/gcc.target/arm/cmse/bitfield-3.c

index 5875f8dff48..d621a802ee1 100644
--- a/gcc/testsuite/gcc.target/arm/cmse/bitfield-3.c
+++ b/gcc/testsuite/gcc.target/arm/cmse/bitfield-3.c
@@ -1,5 +1,5 @@
  /* This test is executed only if the execution engine supports CMSE 
instructions.  */
-/* { dg-options "--save-temps -mcmse 
-Wl,--section-start,.gnu.sgstubs=0x0040" } */
+/* { dg-options "--save-temps -mcmse 
-Wl,--section-start,.gnu.sgstubs=[cmse_sgstubs]" } */

  typedef struct
  {
diff --git a/gcc/testsuite/gcc.target/arm/cmse/cmse-20.c 
b/gcc/testsuite/gcc.target/arm/cmse/cmse-20.c

index 08e89bff637..bbea9358870 100644
--- a/gcc/testsuite/gcc.target/arm/cmse/cmse-20.c
+++ b/gcc/testsuite/gcc.target/arm/cmse/cmse-20.c
@@ -1,5 +1,5 @@
  /* This test is executed only if the execution engine supports CMSE 
instructions.  */
-/* { dg-options "--save-temps -mcmse 
-Wl,--section-start,.gnu.sgstubs=0x0040" } */
+/* { dg-options "--save-temps -mcmse 
-Wl,--section-start,.gnu.sgstubs=[cmse_sgstubs]" } */

  #include 
  #include 
diff --git a/gcc/testsuite/gcc.target/arm/cmse/cmse.exp 
b/gcc/testsuite/gcc.target/arm/cmse/cmse.exp

index 436dd71ef89..1df5d56c6d5 100644
--- a/gcc/testsuite/gcc.target/arm/cmse/cmse.exp
+++ b/gcc/testsuite/gcc.target/arm/cmse/cmse.exp
@@ -44,6 +44,17 @@ if {[is-effective-target arm_cmse_hw]} then {
  set saved-lto_torture_options ${LTO_TORTURE_OPTIONS}
  set LTO_TORTURE_OPTIONS ""
+# Return the start address of the .gnu.sgstubs section.
+proc cmse_sgstubs {} {
+    # Allow to override the location of .gnu.sgstubs section.
+    set tboard [target_info name]
+    if {[board_info $tboard exists cmse_sgstubs]} {
+    return [board_info $tboard cmse_sgstubs]
+    }
+
+    return "0x0040"
+}
+


I am not sure if/where this new cmse_sgstubs target-board property needs 
to be documented?


I'm not sure either. Everytime I need to do something with the 
target-board properties, I just look at other examples in the tree and 
replicate what they do.
I'm also not sure if "cmse_sgstubs" is a good name, but I was unable to 
come up with a more meaningful name that was not a mile long... If there 
is any sugession on a better name, please speak up! :)


Kind regards,
Torbjörn

Re: [PATCH] arm: Allow to override location of .gnu.sgstubs section

[Christophe Lyon via Gcc-patches]

Hi Torbjörn,

This looks like a nice improvement to me ;-)

On 10/19/22 11:42, Torbjörn SVENSSON via Gcc-patches wrote:

Depending on the DejaGNU board definition, the .gnu.sgstubs section
might be placed on different locations in order to suite the target.

typo: suite -> suit


With this patch, the start location of the section is overrideable
from the board definition with the fallback of the previously
hardcoded location.

gcc/testsuite/ChangeLog:

* gcc.target/arm/cmse/bitfield-1.c: Use overridable location.
* gcc.target/arm/cmse/bitfield-2.c: Likewise.
* gcc.target/arm/cmse/bitfield-3.c: Likewise.
* gcc.target/arm/cmse/cmse-20.c: Likewise.
* gcc.target/arm/cmse/struct-1.c: Likewise.
* gcc.target/arm/cmse/cmse.exp (cmse_sgstubs): New.

Signed-off-by: Torbjörn SVENSSON 
---
  gcc/testsuite/gcc.target/arm/cmse/bitfield-1.c |  2 +-
  gcc/testsuite/gcc.target/arm/cmse/bitfield-2.c |  2 +-
  gcc/testsuite/gcc.target/arm/cmse/bitfield-3.c |  2 +-
  gcc/testsuite/gcc.target/arm/cmse/cmse-20.c|  2 +-
  gcc/testsuite/gcc.target/arm/cmse/cmse.exp | 11 +++
  gcc/testsuite/gcc.target/arm/cmse/struct-1.c   |  2 +-
  6 files changed, 16 insertions(+), 5 deletions(-)

diff --git a/gcc/testsuite/gcc.target/arm/cmse/bitfield-1.c 
b/gcc/testsuite/gcc.target/arm/cmse/bitfield-1.c
index 5685f744435..c1221bef29f 100644
--- a/gcc/testsuite/gcc.target/arm/cmse/bitfield-1.c
+++ b/gcc/testsuite/gcc.target/arm/cmse/bitfield-1.c
@@ -1,5 +1,5 @@
  /* This test is executed only if the execution engine supports CMSE 
instructions.  */
-/* { dg-options "--save-temps -mcmse 
-Wl,--section-start,.gnu.sgstubs=0x0040" } */
+/* { dg-options "--save-temps -mcmse 
-Wl,--section-start,.gnu.sgstubs=[cmse_sgstubs]" } */
  
  typedef struct

  {
diff --git a/gcc/testsuite/gcc.target/arm/cmse/bitfield-2.c 
b/gcc/testsuite/gcc.target/arm/cmse/bitfield-2.c
index 7a794d44644..79e9a3efc93 100644
--- a/gcc/testsuite/gcc.target/arm/cmse/bitfield-2.c
+++ b/gcc/testsuite/gcc.target/arm/cmse/bitfield-2.c
@@ -1,5 +1,5 @@
  /* This test is executed only if the execution engine supports CMSE 
instructions.  */
-/* { dg-options "--save-temps -mcmse 
-Wl,--section-start,.gnu.sgstubs=0x0040" } */
+/* { dg-options "--save-temps -mcmse 
-Wl,--section-start,.gnu.sgstubs=[cmse_sgstubs]" } */
  
  typedef struct

  {
diff --git a/gcc/testsuite/gcc.target/arm/cmse/bitfield-3.c 
b/gcc/testsuite/gcc.target/arm/cmse/bitfield-3.c
index 5875f8dff48..d621a802ee1 100644
--- a/gcc/testsuite/gcc.target/arm/cmse/bitfield-3.c
+++ b/gcc/testsuite/gcc.target/arm/cmse/bitfield-3.c
@@ -1,5 +1,5 @@
  /* This test is executed only if the execution engine supports CMSE 
instructions.  */
-/* { dg-options "--save-temps -mcmse 
-Wl,--section-start,.gnu.sgstubs=0x0040" } */
+/* { dg-options "--save-temps -mcmse 
-Wl,--section-start,.gnu.sgstubs=[cmse_sgstubs]" } */
  
  typedef struct

  {
diff --git a/gcc/testsuite/gcc.target/arm/cmse/cmse-20.c 
b/gcc/testsuite/gcc.target/arm/cmse/cmse-20.c
index 08e89bff637..bbea9358870 100644
--- a/gcc/testsuite/gcc.target/arm/cmse/cmse-20.c
+++ b/gcc/testsuite/gcc.target/arm/cmse/cmse-20.c
@@ -1,5 +1,5 @@
  /* This test is executed only if the execution engine supports CMSE 
instructions.  */
-/* { dg-options "--save-temps -mcmse 
-Wl,--section-start,.gnu.sgstubs=0x0040" } */
+/* { dg-options "--save-temps -mcmse 
-Wl,--section-start,.gnu.sgstubs=[cmse_sgstubs]" } */
  
  #include 

  #include 
diff --git a/gcc/testsuite/gcc.target/arm/cmse/cmse.exp 
b/gcc/testsuite/gcc.target/arm/cmse/cmse.exp
index 436dd71ef89..1df5d56c6d5 100644
--- a/gcc/testsuite/gcc.target/arm/cmse/cmse.exp
+++ b/gcc/testsuite/gcc.target/arm/cmse/cmse.exp
@@ -44,6 +44,17 @@ if {[is-effective-target arm_cmse_hw]} then {
  set saved-lto_torture_options ${LTO_TORTURE_OPTIONS}
  set LTO_TORTURE_OPTIONS ""
  
+# Return the start address of the .gnu.sgstubs section.

+proc cmse_sgstubs {} {
+# Allow to override the location of .gnu.sgstubs section.
+set tboard [target_info name]
+if {[board_info $tboard exists cmse_sgstubs]} {
+   return [board_info $tboard cmse_sgstubs]
+}
+
+return "0x0040"
+}
+


I am not sure if/where this new cmse_sgstubs target-board property needs 
to be documented?


Thanks,

Christophe


  # These are for both baseline and mainline.
  gcc-dg-runtest [lsort [glob $srcdir/$subdir/*.c]] \
"" $DEFAULT_CFLAGS
diff --git a/gcc/testsuite/gcc.target/arm/cmse/struct-1.c 
b/gcc/testsuite/gcc.target/arm/cmse/struct-1.c
index 75a99f487e7..bebd059b13f 100644
--- a/gcc/testsuite/gcc.target/arm/cmse/struct-1.c
+++ b/gcc/testsuite/gcc.target/arm/cmse/struct-1.c
@@ -1,5 +1,5 @@
  /* This test is executed only if the execution engine supports CMSE 
instructions.  */
-/* { dg-options "--save-temps -mcmse 
-Wl,--section-start,.gnu.sgstubs=0x0040" } */
+/* { dg-options "--save-temps -mcmse 
-Wl,--section-start,.gnu.sgstubs=[cmse_sgstubs]" } */
  
  typedef 

[PATCH] arm: Allow to override location of .gnu.sgstubs section

[Torbjörn SVENSSON via Gcc-patches]

Depending on the DejaGNU board definition, the .gnu.sgstubs section
might be placed on different locations in order to suite the target.
With this patch, the start location of the section is overrideable
from the board definition with the fallback of the previously
hardcoded location.

gcc/testsuite/ChangeLog:

* gcc.target/arm/cmse/bitfield-1.c: Use overridable location.
* gcc.target/arm/cmse/bitfield-2.c: Likewise.
* gcc.target/arm/cmse/bitfield-3.c: Likewise.
* gcc.target/arm/cmse/cmse-20.c: Likewise.
* gcc.target/arm/cmse/struct-1.c: Likewise.
* gcc.target/arm/cmse/cmse.exp (cmse_sgstubs): New.

Signed-off-by: Torbjörn SVENSSON 
---
 gcc/testsuite/gcc.target/arm/cmse/bitfield-1.c |  2 +-
 gcc/testsuite/gcc.target/arm/cmse/bitfield-2.c |  2 +-
 gcc/testsuite/gcc.target/arm/cmse/bitfield-3.c |  2 +-
 gcc/testsuite/gcc.target/arm/cmse/cmse-20.c|  2 +-
 gcc/testsuite/gcc.target/arm/cmse/cmse.exp | 11 +++
 gcc/testsuite/gcc.target/arm/cmse/struct-1.c   |  2 +-
 6 files changed, 16 insertions(+), 5 deletions(-)

diff --git a/gcc/testsuite/gcc.target/arm/cmse/bitfield-1.c 
b/gcc/testsuite/gcc.target/arm/cmse/bitfield-1.c
index 5685f744435..c1221bef29f 100644
--- a/gcc/testsuite/gcc.target/arm/cmse/bitfield-1.c
+++ b/gcc/testsuite/gcc.target/arm/cmse/bitfield-1.c
@@ -1,5 +1,5 @@
 /* This test is executed only if the execution engine supports CMSE 
instructions.  */
-/* { dg-options "--save-temps -mcmse 
-Wl,--section-start,.gnu.sgstubs=0x0040" } */
+/* { dg-options "--save-temps -mcmse 
-Wl,--section-start,.gnu.sgstubs=[cmse_sgstubs]" } */
 
 typedef struct
 {
diff --git a/gcc/testsuite/gcc.target/arm/cmse/bitfield-2.c 
b/gcc/testsuite/gcc.target/arm/cmse/bitfield-2.c
index 7a794d44644..79e9a3efc93 100644
--- a/gcc/testsuite/gcc.target/arm/cmse/bitfield-2.c
+++ b/gcc/testsuite/gcc.target/arm/cmse/bitfield-2.c
@@ -1,5 +1,5 @@
 /* This test is executed only if the execution engine supports CMSE 
instructions.  */
-/* { dg-options "--save-temps -mcmse 
-Wl,--section-start,.gnu.sgstubs=0x0040" } */
+/* { dg-options "--save-temps -mcmse 
-Wl,--section-start,.gnu.sgstubs=[cmse_sgstubs]" } */
 
 typedef struct
 {
diff --git a/gcc/testsuite/gcc.target/arm/cmse/bitfield-3.c 
b/gcc/testsuite/gcc.target/arm/cmse/bitfield-3.c
index 5875f8dff48..d621a802ee1 100644
--- a/gcc/testsuite/gcc.target/arm/cmse/bitfield-3.c
+++ b/gcc/testsuite/gcc.target/arm/cmse/bitfield-3.c
@@ -1,5 +1,5 @@
 /* This test is executed only if the execution engine supports CMSE 
instructions.  */
-/* { dg-options "--save-temps -mcmse 
-Wl,--section-start,.gnu.sgstubs=0x0040" } */
+/* { dg-options "--save-temps -mcmse 
-Wl,--section-start,.gnu.sgstubs=[cmse_sgstubs]" } */
 
 typedef struct
 {
diff --git a/gcc/testsuite/gcc.target/arm/cmse/cmse-20.c 
b/gcc/testsuite/gcc.target/arm/cmse/cmse-20.c
index 08e89bff637..bbea9358870 100644
--- a/gcc/testsuite/gcc.target/arm/cmse/cmse-20.c
+++ b/gcc/testsuite/gcc.target/arm/cmse/cmse-20.c
@@ -1,5 +1,5 @@
 /* This test is executed only if the execution engine supports CMSE 
instructions.  */
-/* { dg-options "--save-temps -mcmse 
-Wl,--section-start,.gnu.sgstubs=0x0040" } */
+/* { dg-options "--save-temps -mcmse 
-Wl,--section-start,.gnu.sgstubs=[cmse_sgstubs]" } */
 
 #include 
 #include 
diff --git a/gcc/testsuite/gcc.target/arm/cmse/cmse.exp 
b/gcc/testsuite/gcc.target/arm/cmse/cmse.exp
index 436dd71ef89..1df5d56c6d5 100644
--- a/gcc/testsuite/gcc.target/arm/cmse/cmse.exp
+++ b/gcc/testsuite/gcc.target/arm/cmse/cmse.exp
@@ -44,6 +44,17 @@ if {[is-effective-target arm_cmse_hw]} then {
 set saved-lto_torture_options ${LTO_TORTURE_OPTIONS}
 set LTO_TORTURE_OPTIONS ""
 
+# Return the start address of the .gnu.sgstubs section.
+proc cmse_sgstubs {} {
+# Allow to override the location of .gnu.sgstubs section.
+set tboard [target_info name]
+if {[board_info $tboard exists cmse_sgstubs]} {
+   return [board_info $tboard cmse_sgstubs]
+}
+
+return "0x0040"
+}
+
 # These are for both baseline and mainline.
 gcc-dg-runtest [lsort [glob $srcdir/$subdir/*.c]] \
"" $DEFAULT_CFLAGS
diff --git a/gcc/testsuite/gcc.target/arm/cmse/struct-1.c 
b/gcc/testsuite/gcc.target/arm/cmse/struct-1.c
index 75a99f487e7..bebd059b13f 100644
--- a/gcc/testsuite/gcc.target/arm/cmse/struct-1.c
+++ b/gcc/testsuite/gcc.target/arm/cmse/struct-1.c
@@ -1,5 +1,5 @@
 /* This test is executed only if the execution engine supports CMSE 
instructions.  */
-/* { dg-options "--save-temps -mcmse 
-Wl,--section-start,.gnu.sgstubs=0x0040" } */
+/* { dg-options "--save-temps -mcmse 
-Wl,--section-start,.gnu.sgstubs=[cmse_sgstubs]" } */
 
 typedef struct
 {
-- 
2.25.1

Re: Announcement: Porting the Docs to Sphinx - 9. November 2022

[Martin Liška]

On 10/19/22 10:13, Paul Iannetta wrote:
> On Wed, Oct 19, 2022 at 09:24:06AM +0200, Martin Liška wrote:
>> On 10/17/22 16:16, Paul Iannetta wrote:
>>> Hi Martin,
>>>
>>> Thank you very much for porting the documentation to Sphinx, it is
>>> very convenient to use, especially the menu on the left and the
>>> search bar.
>>
>> Thanks, I also like it!
>>
>>>
>>> However, I also regularly browse and search the documentation through
>>> info, especially when I want to use regexps to search or need to
>>> include a special character (eg.,+,-,_,(; this can happen when I
>>> search for '(define' ) for example) in the search string.
>>>
>>> Does the port to Sphinx means the end of texinfo? Or, will both be
>>> available as it is the case now with the official texinfo and your
>>> unofficial splichal.eu pages.
>>
>> It will be still available same as now where manual pages and info pages
>> are built if you compile GCC from sources. We haven't been publishing manual
>> pages and info pages on our web pages, people typically get these from
>> their distribution packages.
> 
> As long as it is possible to build the info manual with "make info", even 
> through
> something like rst2texinfo,  I would be happy.  Would it be possible
> to see the rst source of the port so as to try rst2texinfo on it?

Well, .rst source files can be seen right now here:
https://github.com/marxin/texi2rst-generated

And 'texinfo' is created with the standard Sphinx builder:
https://www.sphinx-doc.org/en/master/man/sphinx-build.html#cmdoption-sphinx-build-b

> 
>>
>> Does it help? Or do you expect any change regarding what we publish at:
>> https://gcc.gnu.org/onlinedocs/
>> ?
> Currently, there is a tarball with texinfo sources for all the manuals
> for each version.

Well, then equivalent would be packaging all .rst files together with the 
corresponding
conf.py, logo.* and other files. But I don't see it much useful.

Thanks,
Martin

> 
> Thanks,
> Paul
> 
>>
>> Cheers,
>> Martin
>>
>>>
>>> Paul
>>>
>>> On Mon, Oct 17, 2022 at 03:28:34PM +0200, Martin Liška wrote:
 Hello.

 Based on the very positive feedback I was given at the Cauldron Sphinx 
 Documentation BoF,
 I'm planning migrating the documentation on 9th November. There are still 
 some minor comments
 from Sandra when it comes to the PDF output, but we can address that once 
 the conversion is done.

 The reason I'm sending the email now is that I was waiting for latest 
 Sphinx release (5.3.0) that
 simplifies reference format for options and results in much simpler Option 
 summary section ([1])

 The current GCC master (using Sphinx 5.3.0) converted docs can be seen 
 here:
 https://splichal.eu/scripts/sphinx/

 If you see any issues with the converted documentation, or have a feedback 
 about it,
 please reply to this email.

 Cheers,
 Martin

 [1] https://github.com/sphinx-doc/sphinx/pull/10840
 [1] 
 https://splichal.eu/scripts/sphinx/gcc/_build/html/gcc-command-options/option-summary.html




>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
> 
> 
> 
> 

Re: [PATCH] i386: Fix up __bf16 handling on ia32

[Uros Bizjak via Gcc-patches]

On Wed, Oct 19, 2022 at 10:50 AM Jakub Jelinek  wrote:
>
> Hi!
>
> Last night's testing of the libstdc++ changes revealed a problem
> in the __bf16 backend registration (while _Float16 seems ok).
> The problem is that for both BFmode and HFmode we require TARGET_SSE2,
> the generic code creates {,b}float16_type_node only if that is true
> at the start of the TU and the builtins for the type are only
> created in that case (many __builtin_*f16 for HFmode and __builtin_nansf16b
> for BFmode).  Now, for _Float16 I've kept what the code did previously,
> if float16_type_node from generic code is NULL, create ix86_float16_type_node
> and register _Float16 for it, but for __bf16 I've changed it so that
> if bfloat16_type_node from generic code is NULL,
> ix86_register_bf16_builtin_type makes bfloat16_type_node non-NULL.
> This has an unfortunate consequence though, __STDCPP_BFLOAT16_T__ is
> predefined for C++23, __BFLT16_*__ macros are predefined as well, but
> the type doesn't really work (errors whenever it is used) and the builtin
> isn't defined.
>
> The following patch fixes that by going with what we do for HFmode,
> bfloat16_type_node stays as initialized by generic code and we have a local
> type for backend use.  On the other side, nothing used ix86_bf16_ptr_type_node
> so that is now dropped.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> 2022-10-19  Jakub Jelinek  
>
> * config/i386/i386-builtins.cc (ix86_bf16_ptr_type_node): Remove.
> (ix86_bf16_type_node): New variable.
> (ix86_register_bf16_builtin_type): If bfloat16_type_node is NULL
> from generic code, set only ix86_bf16_type_node to a new REAL_TYPE
> rather than bfloat16_type_node, otherwise set ix86_bf16_type_node
> to bfloat16_type_node.  Register __bf16 on ix86_bf16_type_node
> rather than bfloat16_type_node.  Don't initialize unused
> ix86_bf16_ptr_type_node.
> * config/i386/i386-builtin-types.def (BFLOAT16): Use
> ix86_bf16_type_node rather than bfloat16_type_node.

LGTM.

Thanks,
Uros.

> --- gcc/config/i386/i386-builtins.cc.jj 2022-10-14 22:32:30.088698145 +0200
> +++ gcc/config/i386/i386-builtins.cc2022-10-19 01:11:33.685164338 +0200
> @@ -126,7 +126,7 @@ BDESC_VERIFYS (IX86_BUILTIN_MAX,
>  static GTY(()) tree ix86_builtin_type_tab[(int) IX86_BT_LAST_CPTR + 1];
>
>  tree ix86_float16_type_node = NULL_TREE;
> -tree ix86_bf16_ptr_type_node = NULL_TREE;
> +tree ix86_bf16_type_node = NULL_TREE;
>
>  /* Retrieve an element from the above table, building some of
> the types lazily.  */
> @@ -1373,17 +1373,16 @@ ix86_register_bf16_builtin_type (void)
>  {
>if (bfloat16_type_node == NULL_TREE)
>  {
> -  bfloat16_type_node = make_node (REAL_TYPE);
> -  TYPE_PRECISION (bfloat16_type_node) = 16;
> -  SET_TYPE_MODE (bfloat16_type_node, BFmode);
> -  layout_type (bfloat16_type_node);
> +  ix86_bf16_type_node = make_node (REAL_TYPE);
> +  TYPE_PRECISION (ix86_bf16_type_node) = 16;
> +  SET_TYPE_MODE (ix86_bf16_type_node, BFmode);
> +  layout_type (ix86_bf16_type_node);
>  }
> +  else
> +ix86_bf16_type_node = bfloat16_type_node;
>
>if (!maybe_get_identifier ("__bf16") && TARGET_SSE2)
> -{
> -  lang_hooks.types.register_builtin_type (bfloat16_type_node, "__bf16");
> -  ix86_bf16_ptr_type_node = build_pointer_type (bfloat16_type_node);
> -}
> +lang_hooks.types.register_builtin_type (ix86_bf16_type_node, "__bf16");
>  }
>
>  static void
> --- gcc/config/i386/i386-builtin-types.def.jj   2022-10-14 22:32:30.088698145 
> +0200
> +++ gcc/config/i386/i386-builtin-types.def  2022-10-19 01:11:58.030845416 
> +0200
> @@ -69,7 +69,7 @@ DEF_PRIMITIVE_TYPE (UINT16, short_unsign
>  DEF_PRIMITIVE_TYPE (INT64, long_long_integer_type_node)
>  DEF_PRIMITIVE_TYPE (UINT64, long_long_unsigned_type_node)
>  DEF_PRIMITIVE_TYPE (FLOAT16, ix86_float16_type_node)
> -DEF_PRIMITIVE_TYPE (BFLOAT16, bfloat16_type_node)
> +DEF_PRIMITIVE_TYPE (BFLOAT16, ix86_bf16_type_node)
>  DEF_PRIMITIVE_TYPE (FLOAT, float_type_node)
>  DEF_PRIMITIVE_TYPE (DOUBLE, double_type_node)
>  DEF_PRIMITIVE_TYPE (FLOAT80, float80_type_node)
>
>
> Jakub
>

Re: [PATCH] libstdc++-v3: Implement {, b}float16_t nextafter and some fixes [PR106652]

[Jonathan Wakely via Gcc-patches]

On Wed, 19 Oct 2022 at 09:23, Jakub Jelinek wrote:
>
> Hi!
>
> The following patch implements nextafter for std::{,b}float16_t,
> though right now only without constexpr support, and adds a testcase for it.
> The testcase unfortunately relevealed I've screwed up testing of my last
> patch.  I've tested earlier version of the patch with
> --target_board=unix/-std=c++23
> but didn't test the final version with that RUNTESTFLAGS, so missed
> an invalid call to std::sph_neumann (too many arguments) in the test.
> And, I've made a typo in the guard for numeric_limits (the reason
> for the guard is I wanted to avoid defining a large macro that nothing
> will then use because the std::{,b}float*_t types are C++23 only) and
> so numeric_limits wasn't specialized for the types at all but
> testsuite/18_support/headers/limits/synopsis_cxx23.cc test didn't
> detect that.
> In the nextafter implementation I'm calling __builtin_nextafterf
> to get various required side-effects for nextafter from 0/-0, or from max
> to inf or from min to largest subnormal to avoid needing to set errno
> inline, or use inline asm specific for each processor to force math
> evaluation barriers.  Dunno if
> #ifdef __INT16_TYPE__
> using __float16_int_type = __INT16_TYPE__;
> #else
> using __float16_int_type = short int;
> #endif
> isn't too ugly, perhaps we could just blindly use short int and hope
> or even assert it has the same size as _Float16 or __gnu_cxx::__bfloat16_t?

I'm happy with the preprocessor conditions above, but using short int
and a static assert would be OK too.


> Only aarch64, arm, csky, gcn, x86, nvptx and riscv support these types
> and all of them have 16-bit short (I think the only target with some
> other short size is avr with certain command line switches where both
> short and int are 8-bit, but such mode isn't compatible with C and C++
> requirements).

It's not, but we do try to support avr, especially for something like
 which requires no OS support and has always been required for
freestanding. But will it have float16 anyway? I suppose it might do,
so maybe the preprocessor dance for __INT16_TYPE__ is better. It's
only needed in two places, so isn't too bad.



> --- libstdc++-v3/testsuite/26_numerics/headers/cmath/nextafter_c++23.cc.jj
>   2022-10-18 17:18:32.237061706 +0200
> +++ libstdc++-v3/testsuite/26_numerics/headers/cmath/nextafter_c++23.cc 
> 2022-10-18 18:51:21.465258133 +0200
> @@ -0,0 +1,124 @@
> +// Copyright (C) 2022 Free Software Foundation, Inc.
> +//
> +// This file is part of the GNU ISO C++ Library.  This library is free
> +// software; you can redistribute it and/or modify it under the
> +// terms of the GNU General Public License as published by the
> +// Free Software Foundation; either version 3, or (at your option)
> +// any later version.
> +
> +// This library is distributed in the hope that it will be useful,
> +// but WITHOUT ANY WARRANTY; without even the implied warranty of
> +// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> +// GNU General Public License for more details.
> +
> +// You should have received a copy of the GNU General Public License along
> +// with this library; see the file COPYING3.  If not see
> +// .
> +
> +// { dg-do run { target c++23 } }

This should have { dg-options "-std=gnu++2b" } before the dg-do.

OK with that change.

[PATCH] tree-optimization/106781 - adjust cgraph lhs removal

[Richard Biener via Gcc-patches]

The following matches up the cgraph code removing LHS of a noreturn
call with what fixup_noreturn_call does which gets along without
inserting a definition, fixing the ICE resulting from having no
place to actually insert that new def.

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

PR tree-optimization/106781
* cgraph.cc (cgraph_edge::redirect_call_stmt_to_callee): Copy
LHS removal from fixup_noreturn_call.

* gcc.dg/pr106781.c: New testcase.
---
 gcc/cgraph.cc   | 14 ++
 gcc/testsuite/gcc.dg/pr106781.c | 18 ++
 2 files changed, 24 insertions(+), 8 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/pr106781.c

diff --git a/gcc/cgraph.cc b/gcc/cgraph.cc
index 0417b059965..5851b2ffc6c 100644
--- a/gcc/cgraph.cc
+++ b/gcc/cgraph.cc
@@ -1411,7 +1411,6 @@ cgraph_edge::redirect_call_stmt_to_callee (cgraph_edge *e)
 {
   tree decl = gimple_call_fndecl (e->call_stmt);
   gcall *new_stmt;
-  gimple_stmt_iterator gsi;
 
   if (e->speculative)
 {
@@ -1572,18 +1571,17 @@ cgraph_edge::redirect_call_stmt_to_callee (cgraph_edge 
*e)
   && (VOID_TYPE_P (TREE_TYPE (gimple_call_fntype (new_stmt)))
  || should_remove_lhs_p (lhs)))
 {
+  gimple_call_set_lhs (new_stmt, NULL_TREE);
+  /* We need to fix up the SSA name to avoid checking errors.  */
   if (TREE_CODE (lhs) == SSA_NAME)
{
  tree var = create_tmp_reg_fn (DECL_STRUCT_FUNCTION (e->caller->decl),
TREE_TYPE (lhs), NULL);
- var = get_or_create_ssa_default_def
- (DECL_STRUCT_FUNCTION (e->caller->decl), var);
- gimple *set_stmt = gimple_build_assign (lhs, var);
- gsi = gsi_for_stmt (new_stmt);
- gsi_insert_before_without_update (&gsi, set_stmt, GSI_SAME_STMT);
- update_stmt_fn (DECL_STRUCT_FUNCTION (e->caller->decl), set_stmt);
+ SET_SSA_NAME_VAR_OR_IDENTIFIER (lhs, var);
+ SSA_NAME_DEF_STMT (lhs) = gimple_build_nop ();
+ set_ssa_default_def (DECL_STRUCT_FUNCTION (e->caller->decl),
+  var, lhs);
}
-  gimple_call_set_lhs (new_stmt, NULL_TREE);
   update_stmt_fn (DECL_STRUCT_FUNCTION (e->caller->decl), new_stmt);
 }
 
diff --git a/gcc/testsuite/gcc.dg/pr106781.c b/gcc/testsuite/gcc.dg/pr106781.c
new file mode 100644
index 000..339c28c41df
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr106781.c
@@ -0,0 +1,18 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -Wno-div-by-zero" } */
+
+int n;
+
+__attribute__ ((noinline, returns_twice)) static int
+bar (int)
+{
+  n /= 0;
+
+  return n;
+}
+
+int
+foo (int x)
+{
+  return bar (x);
+}
-- 
2.35.3

Re: [PATCH] vect: Try folding first for shifted value generation [PR107240]

[Kewen.Lin via Gcc-patches]

Hi Richi,

on 2022/10/19 15:43, Richard Biener wrote:
> On Wed, Oct 19, 2022 at 5:18 AM Kewen.Lin  wrote:
>>
>> Hi,
>>
>> As PR107240 shows, when both the value to be shifted and the
>> count used for shifting are constants, it doesn't actually
>> requires a target to support vector shift operations.
>>
>> This patch is to try fold_build2 for the generation of the
>> shifted value first, if it's folded, the shift is gone,
>> otherwise it's the same as before.
>>
>> It can help to make the failures of vect-bitfield-write-{2,3}.c
>> gone on Power.
>>
>> Bootstrapped and regtested on x86_64-redhat-linux,
>> aarch64-linux-gnu and powerpc64{,le}-linux-gnu.
>>
>> Is it ok for trunk?
>>
>> BR,
>> Kewen
>> -
>> PR tree-optimization/107240
>>
>> gcc/ChangeLog:
>>
>> * tree-vect-patterns.cc (vect_recog_bit_insert_pattern): Attempt to
>> fold shifted value.
>> ---
>>  gcc/tree-vect-patterns.cc | 4 +++-
>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/gcc/tree-vect-patterns.cc b/gcc/tree-vect-patterns.cc
>> index 6afd57a50c4..3beda774ec3 100644
>> --- a/gcc/tree-vect-patterns.cc
>> +++ b/gcc/tree-vect-patterns.cc
>> @@ -2098,9 +2098,11 @@ vect_recog_bit_insert_pattern (vec_info *vinfo, 
>> stmt_vec_info stmt_info,
>>tree shifted = value;
>>if (shift_n)
>>  {
>> +  tree shifted_tmp
>> +   = fold_build2 (LSHIFT_EXPR, container_type, value, shift);
>>pattern_stmt
>> = gimple_build_assign (vect_recog_temp_ssa_var (container_type),
>> -  LSHIFT_EXPR, value, shift);
>> +  shifted_tmp);
> 
> The canonical way would be to use
> 
>  gimple_seq stmts = NULL;
>  shifted = gimple_build (&stmts, LSHIFT_EXPR, container_type,
> value, shift);
>  if (!gimple_seq_empty_p (stmts))
>append_pattern_def_seq (vinfo, stmt_info,
> gimple_seq_first_stmt (stmts));
> 
> That also avoids the spurious val = constant; with your patch.
> 

Thanks for the suggestion!  This works well by testing those two
cases locally.

I searched around, it seems gimple_build doesn't provide one
interface for its users to specify a ssa name for the result,
previously we use vect_recog_temp_ssa_var for the shifted
result, but I think it's trivial.

I'll do a full testing further as before and push it if
everything goes well.  Thanks again.

BR,
Kewen

> OK if that works.
> 
> thanks,
> Richard.
> 
>>append_pattern_def_seq (vinfo, stmt_info, pattern_stmt);
>>shifted = gimple_get_lhs (pattern_stmt);
>>  }
>> --
>> 2.27.0

[PATCH] i386: Fix up __bf16 handling on ia32

[Jakub Jelinek via Gcc-patches]

Hi!

Last night's testing of the libstdc++ changes revealed a problem
in the __bf16 backend registration (while _Float16 seems ok).
The problem is that for both BFmode and HFmode we require TARGET_SSE2,
the generic code creates {,b}float16_type_node only if that is true
at the start of the TU and the builtins for the type are only
created in that case (many __builtin_*f16 for HFmode and __builtin_nansf16b
for BFmode).  Now, for _Float16 I've kept what the code did previously,
if float16_type_node from generic code is NULL, create ix86_float16_type_node
and register _Float16 for it, but for __bf16 I've changed it so that
if bfloat16_type_node from generic code is NULL,
ix86_register_bf16_builtin_type makes bfloat16_type_node non-NULL.
This has an unfortunate consequence though, __STDCPP_BFLOAT16_T__ is
predefined for C++23, __BFLT16_*__ macros are predefined as well, but
the type doesn't really work (errors whenever it is used) and the builtin
isn't defined.

The following patch fixes that by going with what we do for HFmode,
bfloat16_type_node stays as initialized by generic code and we have a local
type for backend use.  On the other side, nothing used ix86_bf16_ptr_type_node
so that is now dropped.

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

2022-10-19  Jakub Jelinek  

* config/i386/i386-builtins.cc (ix86_bf16_ptr_type_node): Remove.
(ix86_bf16_type_node): New variable.
(ix86_register_bf16_builtin_type): If bfloat16_type_node is NULL
from generic code, set only ix86_bf16_type_node to a new REAL_TYPE
rather than bfloat16_type_node, otherwise set ix86_bf16_type_node
to bfloat16_type_node.  Register __bf16 on ix86_bf16_type_node
rather than bfloat16_type_node.  Don't initialize unused
ix86_bf16_ptr_type_node.
* config/i386/i386-builtin-types.def (BFLOAT16): Use
ix86_bf16_type_node rather than bfloat16_type_node.

--- gcc/config/i386/i386-builtins.cc.jj 2022-10-14 22:32:30.088698145 +0200
+++ gcc/config/i386/i386-builtins.cc2022-10-19 01:11:33.685164338 +0200
@@ -126,7 +126,7 @@ BDESC_VERIFYS (IX86_BUILTIN_MAX,
 static GTY(()) tree ix86_builtin_type_tab[(int) IX86_BT_LAST_CPTR + 1];
 
 tree ix86_float16_type_node = NULL_TREE;
-tree ix86_bf16_ptr_type_node = NULL_TREE;
+tree ix86_bf16_type_node = NULL_TREE;
 
 /* Retrieve an element from the above table, building some of
the types lazily.  */
@@ -1373,17 +1373,16 @@ ix86_register_bf16_builtin_type (void)
 {
   if (bfloat16_type_node == NULL_TREE)
 {
-  bfloat16_type_node = make_node (REAL_TYPE);
-  TYPE_PRECISION (bfloat16_type_node) = 16;
-  SET_TYPE_MODE (bfloat16_type_node, BFmode);
-  layout_type (bfloat16_type_node);
+  ix86_bf16_type_node = make_node (REAL_TYPE);
+  TYPE_PRECISION (ix86_bf16_type_node) = 16;
+  SET_TYPE_MODE (ix86_bf16_type_node, BFmode);
+  layout_type (ix86_bf16_type_node);
 }
+  else
+ix86_bf16_type_node = bfloat16_type_node;
 
   if (!maybe_get_identifier ("__bf16") && TARGET_SSE2)
-{
-  lang_hooks.types.register_builtin_type (bfloat16_type_node, "__bf16");
-  ix86_bf16_ptr_type_node = build_pointer_type (bfloat16_type_node);
-}
+lang_hooks.types.register_builtin_type (ix86_bf16_type_node, "__bf16");
 }
 
 static void
--- gcc/config/i386/i386-builtin-types.def.jj   2022-10-14 22:32:30.088698145 
+0200
+++ gcc/config/i386/i386-builtin-types.def  2022-10-19 01:11:58.030845416 
+0200
@@ -69,7 +69,7 @@ DEF_PRIMITIVE_TYPE (UINT16, short_unsign
 DEF_PRIMITIVE_TYPE (INT64, long_long_integer_type_node)
 DEF_PRIMITIVE_TYPE (UINT64, long_long_unsigned_type_node)
 DEF_PRIMITIVE_TYPE (FLOAT16, ix86_float16_type_node)
-DEF_PRIMITIVE_TYPE (BFLOAT16, bfloat16_type_node)
+DEF_PRIMITIVE_TYPE (BFLOAT16, ix86_bf16_type_node)
 DEF_PRIMITIVE_TYPE (FLOAT, float_type_node)
 DEF_PRIMITIVE_TYPE (DOUBLE, double_type_node)
 DEF_PRIMITIVE_TYPE (FLOAT80, float80_type_node)


Jakub

[PATCH] libstdc++: Fix wide-character handling in std::filesystem::path [PR95048]

[Ulf Lorenz via Gcc-patches]

When using std::filesystem::path under Cygwin or Non-Windows with
wide-character strings,
there was an implicit conversion to/from ASCII, leading to errors when
dealing with Unicode filenames.

The attached patch fixes this behavior by using the correct
transformations to the internal representation
(from/to UTF16 for Cygwin, UTF32 for other non-Windows systems).

libstdc++-v3/ChangeLog:

* include/bits/fs_path.h: fixed Cygwin+Unix wide character handling
* testsuite/27_io/filesystem/path/construct/90281.cc: Moved to...
* testsuite/27_io/filesystem/path/construct/unicode_paths.cc: ...here.
added testcase
* testsuite/27_io/filesystem/path/native/string.cc: added testcase for
wide character output


Some notes:

I found the documentation on submissions in some respects unclear and
confusing, so please
correct me if I did something wrong. I assume that you also need a
copyright transfer from my company?
The definition of "small change" and the process for the copyright
transfer is one of the unclear issues.

Also, I did not fix the case of __GNUC_WIDE_EXECUTION_CHARSET_NAME
that is mentioned in the bug
discussion. This should be even more exotic, and is well outside my
current skill level and allotted time
budget.

Also, this being my only patch for the foreseeable future, I have not
subscribed to the mailing list.


Regards,
Ulf Lorenz
<>

[PATCH] libstdc++-v3: Implement {,b}float16_t nextafter and some fixes [PR106652]

[Jakub Jelinek via Gcc-patches]

Hi!

The following patch implements nextafter for std::{,b}float16_t,
though right now only without constexpr support, and adds a testcase for it.
The testcase unfortunately relevealed I've screwed up testing of my last
patch.  I've tested earlier version of the patch with
--target_board=unix/-std=c++23
but didn't test the final version with that RUNTESTFLAGS, so missed
an invalid call to std::sph_neumann (too many arguments) in the test.
And, I've made a typo in the guard for numeric_limits (the reason
for the guard is I wanted to avoid defining a large macro that nothing
will then use because the std::{,b}float*_t types are C++23 only) and
so numeric_limits wasn't specialized for the types at all but
testsuite/18_support/headers/limits/synopsis_cxx23.cc test didn't
detect that.
In the nextafter implementation I'm calling __builtin_nextafterf
to get various required side-effects for nextafter from 0/-0, or from max
to inf or from min to largest subnormal to avoid needing to set errno
inline, or use inline asm specific for each processor to force math
evaluation barriers.  Dunno if
#ifdef __INT16_TYPE__
using __float16_int_type = __INT16_TYPE__;
#else
using __float16_int_type = short int;
#endif
isn't too ugly, perhaps we could just blindly use short int and hope
or even assert it has the same size as _Float16 or __gnu_cxx::__bfloat16_t?
Only aarch64, arm, csky, gcn, x86, nvptx and riscv support these types
and all of them have 16-bit short (I think the only target with some
other short size is avr with certain command line switches where both
short and int are 8-bit, but such mode isn't compatible with C and C++
requirements).

Bootstrapped/regtested on x86_64-linux and i686-linux, additionally
tested with --target_board=unix/-std=c++23, ok for trunk?

2022-10-19  Jakub Jelinek  

PR c++/106652
* include/std/limits: Fix a typo, 202202L -> 202002L.
(numeric_limits::<_Float16>::radix, numeric_limits::<_Float32>::radix,
numeric_limits::<_Float64>::radix, numeric_limits::<_Float128>::radix,
numeric_limits::<__gnu_cxx::__bfloat16_t>::radix: Use __FLT_RADIX__
macro instead of type specific macros.
* include/c_global/cmath (nextafter(_Float16, _Float16)): New
overload.
(nextafter(__gnu_cxx::__bfloat16_t, __gnu_cxx::__bfloat16_t)):
Likewise.
* testsuite/26_numerics/headers/cmath/functions_std_c++23.cc
(test_functions): Uncomment nextafter test.  Fix up sph_neumann call.
* testsuite/26_numerics/headers/cmath/nextafter_c++23.cc: New test.

--- libstdc++-v3/include/std/limits.jj  2022-10-18 11:35:55.065871590 +0200
+++ libstdc++-v3/include/std/limits 2022-10-18 18:32:20.701757131 +0200
@@ -1890,7 +1890,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 #undef __glibcxx_long_double_traps
 #undef __glibcxx_long_double_tinyness_before
 
-#if __cplusplus > 202202L
+#if __cplusplus > 202002L
 
 #define __glibcxx_concat3_(P,M,S) P ## M ## S
 #define __glibcxx_concat3(P,M,S) __glibcxx_concat3_ (P,M,S)
@@ -1924,8 +1924,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   static constexpr bool is_signed = true;  \
   static constexpr bool is_integer = false;
\
   static constexpr bool is_exact = false;  \
-  static constexpr int radix   \
-   = __glibcxx_concat3 (__FLT, BITSIZE, _RADIX__); \
+  static constexpr int radix = __FLT_RADIX__;  \
\
   static constexpr _Float##BITSIZE \
   epsilon() noexcept   \
@@ -2023,7 +2022,7 @@ __glibcxx_float_n(128)
   static constexpr bool is_signed = true;
   static constexpr bool is_integer = false;
   static constexpr bool is_exact = false;
-  static constexpr int radix = __BFLT16_RADIX__;
+  static constexpr int radix = __FLT_RADIX__;
 
   static constexpr __gnu_cxx::__bfloat16_t
   epsilon() noexcept
--- libstdc++-v3/include/c_global/cmath.jj  2022-10-18 11:35:55.222869455 
+0200
+++ libstdc++-v3/include/c_global/cmath 2022-10-18 17:05:50.737347845 +0200
@@ -2755,7 +2755,52 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   nearbyint(_Float16 __x)
   { return _Float16(__builtin_nearbyintf(__x)); }
 
-  // nextafter not implemented so far.
+  inline _Float16
+  nextafter(_Float16 __x, _Float16 __y)
+  {
+#ifdef __INT16_TYPE__
+using __float16_int_type = __INT16_TYPE__;
+#else
+using __float16_int_type = short int;
+#endif
+__float16_int_type __hx, __hy, __ix, __iy;
+__builtin_memcpy(&__hx, &__x, sizeof(__x));
+__builtin_memcpy(&__hy, &__y, sizeof(__x));
+__ix = __hx & 0x7fff;  // |x|
+__iy = __hy & 0x7fff;  // |y|
+if (__ix > 0x7c00 || __iy > 0x7c00) // x or y is NaN
+  return __x + __y;
+if (__x == __y)

Re: [PATCH] expr: Fix ICE on BFmode -> SFmode conversion of constant [PR107262]

[Richard Biener via Gcc-patches]

> Am 19.10.2022 um 09:55 schrieb Jakub Jelinek via Gcc-patches 
> :
> 
> Hi!
> 
> I forgot to handle the case where lowpart_subreg returns a VOIDmode
> CONST_INT, in that case convert_mode_scalar obviously doesn't work.
> 
> The following patch fixes that.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

Ok.

Thanks,
Richard 


> 2022-10-19  Jakub Jelinek  
> 
>PR middle-end/107262
>* expr.cc (convert_mode_scalar): For BFmode -> SFmode conversions
>of constants, use simplify_unary_operation if fromi has VOIDmode
>instead of recursive convert_mode_scalar.
> 
>* gcc.dg/pr107262.c: New test.
> 
> --- gcc/expr.cc.jj2022-10-14 09:35:56.134991155 +0200
> +++ gcc/expr.cc2022-10-18 14:07:24.330512745 +0200
> @@ -416,8 +416,15 @@ convert_mode_scalar (rtx to, rtx from, i
>  rtx tof = NULL_RTX;
>  if (fromi)
>{
> -  rtx toi = gen_reg_rtx (toi_mode);
> -  convert_mode_scalar (toi, fromi, 1);
> +  rtx toi;
> +  if (GET_MODE (fromi) == VOIDmode)
> +toi = simplify_unary_operation (ZERO_EXTEND, toi_mode,
> +fromi, fromi_mode);
> +  else
> +{
> +  toi = gen_reg_rtx (toi_mode);
> +  convert_mode_scalar (toi, fromi, 1);
> +}
>  toi
>= maybe_expand_shift (LSHIFT_EXPR, toi_mode, toi,
>  GET_MODE_PRECISION (to_mode)
> --- gcc/testsuite/gcc.dg/pr107262.c.jj2022-10-18 14:09:44.114607505 +0200
> +++ gcc/testsuite/gcc.dg/pr107262.c2022-10-18 14:09:33.708749313 +0200
> @@ -0,0 +1,13 @@
> +/* PR middle-end/107262 */
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -ffast-math" } */
> +/* { dg-add-options bfloat16 } */
> +/* { dg-require-effective-target bfloat16_runtime } */
> +
> +__bf16
> +foo (__bf16 a)
> +{
> +  __bf16 b = 0;
> +  b /= a;
> +  return b;
> +}
> 
>Jakub
> 

Re: [PATCH] match.pd: Add 2 TYPE_OVERFLOW_SANITIZED checks [PR106990]

[Richard Biener via Gcc-patches]

> Am 19.10.2022 um 10:02 schrieb Jakub Jelinek :
> 
> Hi!
> 
> As requested in the PR, this adds 2 TYPE_OVERFLOW_SANITIZED checks
> and corresponding testcase.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

Ok.

Thanks,
Richard 

> 2022-10-19  Jakub Jelinek  
> 
>PR tree-optimization/106990
>* match.pd ((~X - ~Y) -> Y - X, -x & 1 -> x & 1): Guard with
>!TYPE_OVERFLOW_SANITIZED (type).
> 
>* c-c++-common/ubsan/pr106990.c: New test.
> 
> --- gcc/match.pd.jj2022-10-13 15:51:08.928071208 +0200
> +++ gcc/match.pd2022-10-18 16:01:12.145705958 +0200
> @@ -1331,8 +1331,9 @@ (define_operator_list SYNC_FETCH_AND_AND
> /* (~X - ~Y) -> Y - X.  */
> (simplify
>  (minus (bit_not @0) (bit_not @1))
> -  (with { tree utype = unsigned_type_for (type); }
> -   (convert (minus (convert:utype @1) (convert:utype @0)
> +  (if (!TYPE_OVERFLOW_SANITIZED (type))
> +   (with { tree utype = unsigned_type_for (type); }
> +(convert (minus (convert:utype @1) (convert:utype @0))
> 
> /* ~(X - Y) -> ~X + Y.  */
> (simplify
> @@ -8176,5 +8177,6 @@ and,
> 
> /* -x & 1 -> x & 1.  */
> (simplify 
> -  (bit_and (negate @0) integer_onep@1)
> -  (bit_and @0 @1))
> + (bit_and (negate @0) integer_onep@1)
> + (if (!TYPE_OVERFLOW_SANITIZED (type))
> +  (bit_and @0 @1)))
> --- gcc/testsuite/c-c++-common/ubsan/pr106990.c.jj2022-10-18 
> 15:56:20.260656260 +0200
> +++ gcc/testsuite/c-c++-common/ubsan/pr106990.c2022-10-18 
> 16:17:37.295403933 +0200
> @@ -0,0 +1,29 @@
> +/* PR tree-optimization/106990 */
> +/* { dg-do run { target int32 } } */
> +/* { dg-options "-fsanitize=signed-integer-overflow" } */
> +
> +__attribute__((noipa)) int
> +foo (void)
> +{
> +  int x = -1956816001;
> +  int y = 1999200512;
> +  return ~x - ~y;
> +}
> +
> +__attribute__((noipa)) int
> +bar (void)
> +{
> +  int x = -__INT_MAX__ - 1;
> +  return -x & 1;
> +}
> +
> +int
> +main ()
> +{
> +  foo ();
> +  bar ();
> +  return 0;
> +}
> +
> +/* { dg-output "signed integer overflow: 1956816000 - -1999200513 cannot be 
> represented in type 'int'\[^\n\r]*(\n|\r\n|\r)" } */
> +/* { dg-output "\[^\n\r]*negation of -2147483648 cannot be represented in 
> type 'int'; cast to an unsigned type to negate this value to itself" } */
> 
>Jakub
> 

Re: Announcement: Porting the Docs to Sphinx - 9. November 2022

[Paul Iannetta via Gcc-patches]

On Wed, Oct 19, 2022 at 09:24:06AM +0200, Martin Liška wrote:
> On 10/17/22 16:16, Paul Iannetta wrote:
> > Hi Martin,
> > 
> > Thank you very much for porting the documentation to Sphinx, it is
> > very convenient to use, especially the menu on the left and the
> > search bar.
> 
> Thanks, I also like it!
> 
> > 
> > However, I also regularly browse and search the documentation through
> > info, especially when I want to use regexps to search or need to
> > include a special character (eg.,+,-,_,(; this can happen when I
> > search for '(define' ) for example) in the search string.
> > 
> > Does the port to Sphinx means the end of texinfo? Or, will both be
> > available as it is the case now with the official texinfo and your
> > unofficial splichal.eu pages.
> 
> It will be still available same as now where manual pages and info pages
> are built if you compile GCC from sources. We haven't been publishing manual
> pages and info pages on our web pages, people typically get these from
> their distribution packages.

As long as it is possible to build the info manual with "make info", even 
through
something like rst2texinfo,  I would be happy.  Would it be possible
to see the rst source of the port so as to try rst2texinfo on it?

> 
> Does it help? Or do you expect any change regarding what we publish at:
> https://gcc.gnu.org/onlinedocs/
> ?
Currently, there is a tarball with texinfo sources for all the manuals
for each version.

Thanks,
Paul

> 
> Cheers,
> Martin
> 
> > 
> > Paul
> > 
> > On Mon, Oct 17, 2022 at 03:28:34PM +0200, Martin Liška wrote:
> >> Hello.
> >>
> >> Based on the very positive feedback I was given at the Cauldron Sphinx 
> >> Documentation BoF,
> >> I'm planning migrating the documentation on 9th November. There are still 
> >> some minor comments
> >> from Sandra when it comes to the PDF output, but we can address that once 
> >> the conversion is done.
> >>
> >> The reason I'm sending the email now is that I was waiting for latest 
> >> Sphinx release (5.3.0) that
> >> simplifies reference format for options and results in much simpler Option 
> >> summary section ([1])
> >>
> >> The current GCC master (using Sphinx 5.3.0) converted docs can be seen 
> >> here:
> >> https://splichal.eu/scripts/sphinx/
> >>
> >> If you see any issues with the converted documentation, or have a feedback 
> >> about it,
> >> please reply to this email.
> >>
> >> Cheers,
> >> Martin
> >>
> >> [1] https://github.com/sphinx-doc/sphinx/pull/10840
> >> [1] 
> >> https://splichal.eu/scripts/sphinx/gcc/_build/html/gcc-command-options/option-summary.html
> >>
> >>
> >>
> >>
> > 
> > 
> > 
> > 
> 
> 
> 
> 
> 

[PATCH] match.pd: Add 2 TYPE_OVERFLOW_SANITIZED checks [PR106990]

[Jakub Jelinek via Gcc-patches]

Hi!

As requested in the PR, this adds 2 TYPE_OVERFLOW_SANITIZED checks
and corresponding testcase.

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

2022-10-19  Jakub Jelinek  

PR tree-optimization/106990
* match.pd ((~X - ~Y) -> Y - X, -x & 1 -> x & 1): Guard with
!TYPE_OVERFLOW_SANITIZED (type).

* c-c++-common/ubsan/pr106990.c: New test.

--- gcc/match.pd.jj 2022-10-13 15:51:08.928071208 +0200
+++ gcc/match.pd2022-10-18 16:01:12.145705958 +0200
@@ -1331,8 +1331,9 @@ (define_operator_list SYNC_FETCH_AND_AND
 /* (~X - ~Y) -> Y - X.  */
 (simplify
  (minus (bit_not @0) (bit_not @1))
-  (with { tree utype = unsigned_type_for (type); }
-   (convert (minus (convert:utype @1) (convert:utype @0)
+  (if (!TYPE_OVERFLOW_SANITIZED (type))
+   (with { tree utype = unsigned_type_for (type); }
+(convert (minus (convert:utype @1) (convert:utype @0))
 
 /* ~(X - Y) -> ~X + Y.  */
 (simplify
@@ -8176,5 +8177,6 @@ and,
 
 /* -x & 1 -> x & 1.  */
 (simplify 
-  (bit_and (negate @0) integer_onep@1)
-  (bit_and @0 @1))
+ (bit_and (negate @0) integer_onep@1)
+ (if (!TYPE_OVERFLOW_SANITIZED (type))
+  (bit_and @0 @1)))
--- gcc/testsuite/c-c++-common/ubsan/pr106990.c.jj  2022-10-18 
15:56:20.260656260 +0200
+++ gcc/testsuite/c-c++-common/ubsan/pr106990.c 2022-10-18 16:17:37.295403933 
+0200
@@ -0,0 +1,29 @@
+/* PR tree-optimization/106990 */
+/* { dg-do run { target int32 } } */
+/* { dg-options "-fsanitize=signed-integer-overflow" } */
+
+__attribute__((noipa)) int
+foo (void)
+{
+  int x = -1956816001;
+  int y = 1999200512;
+  return ~x - ~y;
+}
+
+__attribute__((noipa)) int
+bar (void)
+{
+  int x = -__INT_MAX__ - 1;
+  return -x & 1;
+}
+
+int
+main ()
+{
+  foo ();
+  bar ();
+  return 0;
+}
+
+/* { dg-output "signed integer overflow: 1956816000 - -1999200513 cannot be 
represented in type 'int'\[^\n\r]*(\n|\r\n|\r)" } */
+/* { dg-output "\[^\n\r]*negation of -2147483648 cannot be represented in type 
'int'; cast to an unsigned type to negate this value to itself" } */

Jakub

[PATCH] c++: Fix up mangling ICE with void{} [PR106863]

[Jakub Jelinek via Gcc-patches]

Hi!

We ICE on the following testcase during mangling, finish_compound_literal
returns for void{} void_node and the mangler doesn't handle it.
Handling void_node in the mangler seems problematic to me, because
we don't know for which case it has been created.
The following patch arranges to mangle just void{} the same as void()
if that is what we want to use, by doing what we do for void() when
processing void{}.
The code does that only if processing_template_decl, because otherwise
build_functional_cast will return void_node, so calling it looks like
wasted effort to me.  But if you want to call it unconditionally,
I can certainly do that too.

Or do you want to mangle it differently?  How?

clang++ doesn't support DR2351, so I can't check what they are doing.

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

2022-10-19  Jakub Jelinek  

PR c++/106863
* semantics.cc (finish_compound_literal): For void{}, if
processing_template_decl return build_functional_cast of NULL_TREE
to VOID_TYPE rather than void_node.

* g++.dg/cpp0x/dr2351-2.C: New test.

--- gcc/cp/semantics.cc.jj  2022-10-10 09:31:57.410985121 +0200
+++ gcc/cp/semantics.cc 2022-10-18 15:24:08.726026118 +0200
@@ -3164,7 +3164,12 @@ finish_compound_literal (tree type, tree
 {
   /* DR2351 */
   if (VOID_TYPE_P (type) && CONSTRUCTOR_NELTS (compound_literal) == 0)
-   return void_node;
+   {
+ if (!processing_template_decl)
+   return void_node;
+ location_t loc = cp_expr_loc_or_input_loc (compound_literal);
+ return build_functional_cast (loc, type, NULL_TREE, complain);
+   }
   else if (VOID_TYPE_P (type)
   && processing_template_decl
   && maybe_zero_constructor_nelts (compound_literal))
--- gcc/testsuite/g++.dg/cpp0x/dr2351-2.C.jj2022-10-18 15:27:01.146690132 
+0200
+++ gcc/testsuite/g++.dg/cpp0x/dr2351-2.C   2022-10-18 15:27:39.909164970 
+0200
@@ -0,0 +1,16 @@
+// DR2351
+// { dg-do compile { target c++11 } }
+
+void bar (int);
+
+template 
+auto foo (T t) -> decltype (bar (t), void{})
+{
+  return bar (t);
+}
+
+int
+main ()
+{
+  foo (0);
+}

Jakub

[PATCH] expr: Fix ICE on BFmode -> SFmode conversion of constant [PR107262]

[Jakub Jelinek via Gcc-patches]

Hi!

I forgot to handle the case where lowpart_subreg returns a VOIDmode
CONST_INT, in that case convert_mode_scalar obviously doesn't work.

The following patch fixes that.

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

2022-10-19  Jakub Jelinek  

PR middle-end/107262
* expr.cc (convert_mode_scalar): For BFmode -> SFmode conversions
of constants, use simplify_unary_operation if fromi has VOIDmode
instead of recursive convert_mode_scalar.

* gcc.dg/pr107262.c: New test.

--- gcc/expr.cc.jj  2022-10-14 09:35:56.134991155 +0200
+++ gcc/expr.cc 2022-10-18 14:07:24.330512745 +0200
@@ -416,8 +416,15 @@ convert_mode_scalar (rtx to, rtx from, i
  rtx tof = NULL_RTX;
  if (fromi)
{
- rtx toi = gen_reg_rtx (toi_mode);
- convert_mode_scalar (toi, fromi, 1);
+ rtx toi;
+ if (GET_MODE (fromi) == VOIDmode)
+   toi = simplify_unary_operation (ZERO_EXTEND, toi_mode,
+   fromi, fromi_mode);
+ else
+   {
+ toi = gen_reg_rtx (toi_mode);
+ convert_mode_scalar (toi, fromi, 1);
+   }
  toi
= maybe_expand_shift (LSHIFT_EXPR, toi_mode, toi,
  GET_MODE_PRECISION (to_mode)
--- gcc/testsuite/gcc.dg/pr107262.c.jj  2022-10-18 14:09:44.114607505 +0200
+++ gcc/testsuite/gcc.dg/pr107262.c 2022-10-18 14:09:33.708749313 +0200
@@ -0,0 +1,13 @@
+/* PR middle-end/107262 */
+/* { dg-do compile } */
+/* { dg-options "-O2 -ffast-math" } */
+/* { dg-add-options bfloat16 } */
+/* { dg-require-effective-target bfloat16_runtime } */
+
+__bf16
+foo (__bf16 a)
+{
+  __bf16 b = 0;
+  b /= a;
+  return b;
+}

Jakub

[PATCH] c++: Don't shortcut TREE_CONSTANT vector type CONSTRUCTORs in cxx_eval_constant_expression [PR107295]

[Jakub Jelinek via Gcc-patches]

Hi!

The excess precision support broke building skia (dependency of firefox)
on ia32 (it has something like the a constexpr variable), but as the other
cases show, it is actually a preexisting problem if one uses casts from
constants with wider floating point types.
The problem is that cxx_eval_constant_expression tries to short-cut
processing of TREE_CONSTANT CONSTRUCTORs if they satisfy
reduced_constant_expression_p - instead of calling cxx_eval_bare_aggregate
on them it just verifies flags and if they are TREE_CONSTANT even after
that, just fold.
Now, on the testcase we have a TREE_CONSTANT CONSTRUCTOR containing
TREE_CONSTANT NOP_EXPR of REAL_CST.  And, fold, which isn't recursive,
doesn't optimize that into VECTOR_CST, while later on we are only able
to optimize VECTOR_CST arithmetics, not arithmetics with vector
CONSTRUCTORs.
The following patch fixes that by only returning what fold returned
if for vector types it returned VECTOR_CST, otherwise let us
call cxx_eval_bare_aggregate.  That function will try to constant
evaluate all the elements and if anything changes, return a CONSTRUCTOR,
in the vector type cases with fold called on it at the end.
Now, just calling cxx_eval_bare_aggregate for vector types doesn't work
either (e.g. constexpr-builtin4.C breaks), because cxx_eval_bare_aggregate
if nothing changes (like all elts are already REAL_CSTs or INTEGER_CSTs)
will return the old CONSTRUCTOR and nothing folds it into a VECTOR_CST.
Also, the reason for the short-cutting is I think trying to avoid
allocating a new CONSTRUCTOR when nothing changes and we just create
GC garbage by it.

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

2022-10-19  Jakub Jelinek  

PR c++/107295
* constexpr.cc (cxx_eval_constant_expression) :
Don't short-cut TREE_CONSTANT vector ctors if fold doesn't turn them
into VECTOR_CST.

* g++.dg/ext/vector42.C: New test.

--- gcc/cp/constexpr.cc.jj  2022-10-17 12:29:33.518016420 +0200
+++ gcc/cp/constexpr.cc 2022-10-19 01:29:28.761935708 +0200
@@ -7391,7 +7391,12 @@ cxx_eval_constant_expression (const cons
 VECTOR_CST if applicable.  */
  verify_constructor_flags (t);
  if (TREE_CONSTANT (t))
-   return fold (t);
+   {
+ r = fold (t);
+ if (TREE_CODE (TREE_TYPE (t)) != VECTOR_TYPE
+ || TREE_CODE (r) == VECTOR_CST)
+   return r;
+   }
}
   r = cxx_eval_bare_aggregate (ctx, t, lval,
   non_constant_p, overflow_p);
--- gcc/testsuite/g++.dg/ext/vector42.C.jj  2022-10-18 12:33:42.938510483 
+0200
+++ gcc/testsuite/g++.dg/ext/vector42.C 2022-10-18 12:32:27.448544476 +0200
@@ -0,0 +1,12 @@
+// PR c++/107295
+// { dg-do compile { target c++11 } }
+
+template  struct A {
+  typedef T __attribute__((vector_size (sizeof (int V;
+};
+template  using B = typename A::V;
+template  using V = B<4, T>;
+using F = V;
+constexpr F a = F () + 0.0f;
+constexpr F b = F () + (float) 0.0;
+constexpr F c = F () + (float) 0.0L;

Jakub

Re: [PATCH] vect: Try folding first for shifted value generation [PR107240]

[Richard Biener via Gcc-patches]

On Wed, Oct 19, 2022 at 5:18 AM Kewen.Lin  wrote:
>
> Hi,
>
> As PR107240 shows, when both the value to be shifted and the
> count used for shifting are constants, it doesn't actually
> requires a target to support vector shift operations.
>
> This patch is to try fold_build2 for the generation of the
> shifted value first, if it's folded, the shift is gone,
> otherwise it's the same as before.
>
> It can help to make the failures of vect-bitfield-write-{2,3}.c
> gone on Power.
>
> Bootstrapped and regtested on x86_64-redhat-linux,
> aarch64-linux-gnu and powerpc64{,le}-linux-gnu.
>
> Is it ok for trunk?
>
> BR,
> Kewen
> -
> PR tree-optimization/107240
>
> gcc/ChangeLog:
>
> * tree-vect-patterns.cc (vect_recog_bit_insert_pattern): Attempt to
> fold shifted value.
> ---
>  gcc/tree-vect-patterns.cc | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/gcc/tree-vect-patterns.cc b/gcc/tree-vect-patterns.cc
> index 6afd57a50c4..3beda774ec3 100644
> --- a/gcc/tree-vect-patterns.cc
> +++ b/gcc/tree-vect-patterns.cc
> @@ -2098,9 +2098,11 @@ vect_recog_bit_insert_pattern (vec_info *vinfo, 
> stmt_vec_info stmt_info,
>tree shifted = value;
>if (shift_n)
>  {
> +  tree shifted_tmp
> +   = fold_build2 (LSHIFT_EXPR, container_type, value, shift);
>pattern_stmt
> = gimple_build_assign (vect_recog_temp_ssa_var (container_type),
> -  LSHIFT_EXPR, value, shift);
> +  shifted_tmp);

The canonical way would be to use

 gimple_seq stmts = NULL;
 shifted = gimple_build (&stmts, LSHIFT_EXPR, container_type,
value, shift);
 if (!gimple_seq_empty_p (stmts))
   append_pattern_def_seq (vinfo, stmt_info,
gimple_seq_first_stmt (stmts));

That also avoids the spurious val = constant; with your patch.

OK if that works.

thanks,
Richard.

>append_pattern_def_seq (vinfo, stmt_info, pattern_stmt);
>shifted = gimple_get_lhs (pattern_stmt);
>  }
> --
> 2.27.0

Re: [PATCH] c++ modules: verify_type failure with typedef enum [PR106848]

[Richard Biener via Gcc-patches]

On Tue, Oct 18, 2022 at 8:26 PM Patrick Palka  wrote:
>
> On Fri, 14 Oct 2022, Richard Biener wrote:
>
> > On Thu, Oct 13, 2022 at 5:40 PM Patrick Palka via Gcc-patches
> >  wrote:
> > >
> > > Here during stream in we end up having created a type variant for the enum
> > > before we read the enum's definition, and thus the variant inherited stale
> > > TYPE_VALUES and TYPE_MIN/MAX_VALUES, which leads to an ICE (with -g).  The
> > > stale variant got created from set_underlying_type during earlier stream 
> > > in
> > > of the (redundant) typedef for the enum.
> > >
> > > This patch works around this by setting TYPE_VALUES and 
> > > TYPE_MIN/MAX_VALUES
> > > for all variants when reading in an enum definition.  Does this look like
> > > the right approach?  Or perhaps we need to arrange that we read the enum
> > > definition before reading in the typedef decl?  Note that seems to be an
> > > issue only when the typedef name and enum names are the same (thus the
> > > typedef is redundant), otherwise we seem to read the enum definition first
> > > as desired.
> > >
> > > PR c++/106848
> > >
> > > gcc/cp/ChangeLog:
> > >
> > > * module.cc (trees_in::read_enum_def): Set the TYPE_VALUES,
> > > TYPE_MIN_VALUE and TYPE_MAX_VALUE of all type variants.
> > >
> > > gcc/testsuite/ChangeLog:
> > >
> > > * g++.dg/modules/enum-9_a.H: New test.
> > > * g++.dg/modules/enum-9_b.C: New test.
> > > ---
> > >  gcc/cp/module.cc| 9 ++---
> > >  gcc/testsuite/g++.dg/modules/enum-9_a.H | 5 +
> > >  gcc/testsuite/g++.dg/modules/enum-9_b.C | 6 ++
> > >  3 files changed, 17 insertions(+), 3 deletions(-)
> > >  create mode 100644 gcc/testsuite/g++.dg/modules/enum-9_a.H
> > >  create mode 100644 gcc/testsuite/g++.dg/modules/enum-9_b.C
> > >
> > > diff --git a/gcc/cp/module.cc b/gcc/cp/module.cc
> > > index 7ffeefa7c1f..97fb80bcd44 100644
> > > --- a/gcc/cp/module.cc
> > > +++ b/gcc/cp/module.cc
> > > @@ -12303,9 +12303,12 @@ trees_in::read_enum_def (tree defn, tree 
> > > maybe_template)
> > >
> > >if (installing)
> > >  {
> > > -  TYPE_VALUES (type) = values;
> > > -  TYPE_MIN_VALUE (type) = min;
> > > -  TYPE_MAX_VALUE (type) = max;
> > > +  for (tree t = type; t; t = TYPE_NEXT_VARIANT (t))
> > > +   {
> > > + TYPE_VALUES (t) = values;
> > > + TYPE_MIN_VALUE (t) = min;
> > > + TYPE_MAX_VALUE (t) = max;
> > > +   }
> >
> > it's definitely somewhat ugly but at least type_hash_canon doesn't hash
> > these for ENUMERAL_TYPE (but it does compare them!  which in principle
> > means it could as well hash them ...)
> >
> > I think that if you read both from the same module that you should arrange
> > to read what you refer to first?  But maybe that's not the actual issue 
> > here.
>
> *nod* reading in the enum before reading in the typedef seems like
> the most direct solution, though not sure how to accomplish that :/

For LTO streaming we DFS walk tree edges from all entries into the tree
graph we want to stream, collecting and streaming SCCs.  Not sure if
doing similar for module streaming would help this case though.

> A somewhat orthogonal issue (that incidentally fixes this testcase) is
> that we stream TYPE_MIN/MAX_VALUE only for enums with a definition, but
> the frontend sets these fields even for opaque enums.  If we make sure
> to stream these fields for all ENUMERAL_TYPEs, then we won't have to
> worry about these fields being stale for variants that may have been
> created before reading in the enum definition (their TYPE_VALUES field
> will still be stale I guess, but verify_type doesn't worry about that
> it seems, so we avoid the ICE).
>
> patch to that effect is at
> https://gcc.gnu.org/pipermail/gcc-patches/2022-October/603831.html
>
> >
> > Richard.
> >
> > >
> > >rest_of_type_compilation (type, DECL_NAMESPACE_SCOPE_P (defn));
> > >  }
> > > diff --git a/gcc/testsuite/g++.dg/modules/enum-9_a.H 
> > > b/gcc/testsuite/g++.dg/modules/enum-9_a.H
> > > new file mode 100644
> > > index 000..fb7d10ad3b6
> > > --- /dev/null
> > > +++ b/gcc/testsuite/g++.dg/modules/enum-9_a.H
> > > @@ -0,0 +1,5 @@
> > > +// PR c++/106848
> > > +// { dg-additional-options -fmodule-header }
> > > +// { dg-module-cmi {} }
> > > +
> > > +typedef enum memory_order { memory_order_seq_cst } memory_order;
> > > diff --git a/gcc/testsuite/g++.dg/modules/enum-9_b.C 
> > > b/gcc/testsuite/g++.dg/modules/enum-9_b.C
> > > new file mode 100644
> > > index 000..63e81675d0a
> > > --- /dev/null
> > > +++ b/gcc/testsuite/g++.dg/modules/enum-9_b.C
> > > @@ -0,0 +1,6 @@
> > > +// PR c++/106848
> > > +// { dg-additional-options "-fmodules-ts -g" }
> > > +
> > > +import "enum-9_a.H";
> > > +
> > > +memory_order x = memory_order_seq_cst;
> > > --
> > > 2.38.0.68.ge85701b4af
> > >
> >
> >
>

Re: [PATCH 2/2] c++ modules: always stream TYPE_MIN/MAX_VALUE for enums [PR106848]

[Richard Biener via Gcc-patches]

On Tue, Oct 18, 2022 at 8:11 PM Patrick Palka via Gcc-patches
 wrote:
>
> We currently stream TYPE_MIN/MAX_VALUE of an enum only if the enum is
> defined rather than just declared.  But that seems inconsistent with
> what start_enum does, which always sets TYPE_MIN/MAX_VALUE on the
> ENUMERAL_TYPE (via copy_type_enum) even for an opaque enum that lacks a
> definition.
>
> This patch makes us stream TYPE_MIN/MAX_VALUE as part of the
> ENUMERAL_TYPE rather than as part of the defining TYPE_DECL so that
> TYPE_MIN/MAX_VALUE gets set even for opaque enums.
>
> Incidentally, this turns out to fix the below testcase in which during
> stream in we end up having created a type variant for the enum before we
> read the enum's definition, and thus the variant inherited stale
> TYPE_MIN/MAX_VALUE, which leads to an ICE from verify_type (with -g).
> (The stale variant got created from set_underlying_type during earlier
> stream in of the redundant typedef for the enum.)  By streaming these
> fields as part of the ENUMERAL_TYPE, we guarantee they won't be stale.
>
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk?

Looks reasonable to me.

Thanks,
Richard.

> PR c++/106848
>
> gcc/cp/ChangeLog:
>
> * module.cc (trees_out::core_vals): Stream TYPE_MAX_VALUE and
> TYPE_MIN_VALUE of ENUMERAL_TYPE.
> (trees_in::core_vals): Likewise.
> (trees_out::write_enum_def): Don't stream them here.
> (trees_in::read_enum_def): Likewise.
>
> gcc/testsuite/ChangeLog:
>
> * g++.dg/modules/enum-10_a.H: New test.
> * g++.dg/modules/enum-10_b.C: New test.
> ---
>  gcc/cp/module.cc | 29 
>  gcc/testsuite/g++.dg/modules/enum-10_a.H |  5 
>  gcc/testsuite/g++.dg/modules/enum-10_b.C |  6 +
>  3 files changed, 25 insertions(+), 15 deletions(-)
>  create mode 100644 gcc/testsuite/g++.dg/modules/enum-10_a.H
>  create mode 100644 gcc/testsuite/g++.dg/modules/enum-10_b.C
>
> diff --git a/gcc/cp/module.cc b/gcc/cp/module.cc
> index cc704817718..bb406a5cf01 100644
> --- a/gcc/cp/module.cc
> +++ b/gcc/cp/module.cc
> @@ -6016,9 +6016,14 @@ trees_out::core_vals (tree t)
>
>if (CODE_CONTAINS_STRUCT (code, TS_TYPE_NON_COMMON))
>  {
> +  if (code == ENUMERAL_TYPE)
> +   {
> + WT (t->type_non_common.maxval);
> + WT (t->type_non_common.minval);
> +   }
>/* Records and unions hold FIELDS, VFIELD & BINFO on these
>  things.  */
> -  if (!RECORD_OR_UNION_CODE_P (code) && code != ENUMERAL_TYPE)
> +  else if (!RECORD_OR_UNION_CODE_P (code))
> {
>   // FIXME: These are from tpl_parm_value's 'type' writing.
>   // Perhaps it should just be doing them directly?
> @@ -6529,9 +6534,14 @@ trees_in::core_vals (tree t)
>
>if (CODE_CONTAINS_STRUCT (code, TS_TYPE_NON_COMMON))
>  {
> +  if (code == ENUMERAL_TYPE)
> +   {
> + RT (t->type_non_common.maxval);
> + RT (t->type_non_common.minval);
> +   }
>/* Records and unions hold FIELDS, VFIELD & BINFO on these
>  things.  */
> -  if (!RECORD_OR_UNION_CODE_P (code) && code != ENUMERAL_TYPE)
> +  else if (!RECORD_OR_UNION_CODE_P (code))
> {
>   /* This is not clobbering TYPE_CACHED_VALUES, because this
>  is a type that doesn't have any.  */
> @@ -12217,8 +12227,6 @@ trees_out::write_enum_def (tree decl)
>tree type = TREE_TYPE (decl);
>
>tree_node (TYPE_VALUES (type));
> -  tree_node (TYPE_MIN_VALUE (type));
> -  tree_node (TYPE_MAX_VALUE (type));
>  }
>
>  void
> @@ -12242,8 +12250,6 @@ trees_in::read_enum_def (tree defn, tree 
> maybe_template)
>  {
>tree type = TREE_TYPE (defn);
>tree values = tree_node ();
> -  tree min = tree_node ();
> -  tree max = tree_node ();
>
>if (get_overrun ())
>  return false;
> @@ -12254,8 +12260,6 @@ trees_in::read_enum_def (tree defn, tree 
> maybe_template)
>if (installing)
>  {
>TYPE_VALUES (type) = values;
> -  TYPE_MIN_VALUE (type) = min;
> -  TYPE_MAX_VALUE (type) = max;
>
>rest_of_type_compilation (type, DECL_NAMESPACE_SCOPE_P (defn));
>  }
> @@ -12269,22 +12273,17 @@ trees_in::read_enum_def (tree defn, tree 
> maybe_template)
>   tree new_decl = TREE_VALUE (values);
>
>   if (DECL_NAME (known_decl) != DECL_NAME (new_decl))
> -   goto bad;
> +   break;
>
>   new_decl = maybe_duplicate (new_decl);
>
>   if (!cp_tree_equal (DECL_INITIAL (known_decl),
>   DECL_INITIAL (new_decl)))
> -   goto bad;
> +   break;
> }
>
>if (known || values)
> -   goto bad;
> -
> -  if (!cp_tree_equal (TYPE_MIN_VALUE (type), min)
> - || !cp_tree_equal (TYPE_MAX_VALUE (type), max))
> {
> -   bad:;
>   error_at (DECL_SOURCE_LOCATION (maybe_dup),
> "definition of %qD does not match", maybe_dup);
>   

Re: Announcement: Porting the Docs to Sphinx - 9. November 2022

[Martin Liška]

On 10/17/22 16:16, Paul Iannetta wrote:
> Hi Martin,
> 
> Thank you very much for porting the documentation to Sphinx, it is
> very convenient to use, especially the menu on the left and the
> search bar.

Thanks, I also like it!

> 
> However, I also regularly browse and search the documentation through
> info, especially when I want to use regexps to search or need to
> include a special character (eg.,+,-,_,(; this can happen when I
> search for '(define' ) for example) in the search string.
> 
> Does the port to Sphinx means the end of texinfo? Or, will both be
> available as it is the case now with the official texinfo and your
> unofficial splichal.eu pages.

It will be still available same as now where manual pages and info pages
are built if you compile GCC from sources. We haven't been publishing manual
pages and info pages on our web pages, people typically get these from
their distribution packages.

Does it help? Or do you expect any change regarding what we publish at:
https://gcc.gnu.org/onlinedocs/
?

Cheers,
Martin

> 
> Paul
> 
> On Mon, Oct 17, 2022 at 03:28:34PM +0200, Martin Liška wrote:
>> Hello.
>>
>> Based on the very positive feedback I was given at the Cauldron Sphinx 
>> Documentation BoF,
>> I'm planning migrating the documentation on 9th November. There are still 
>> some minor comments
>> from Sandra when it comes to the PDF output, but we can address that once 
>> the conversion is done.
>>
>> The reason I'm sending the email now is that I was waiting for latest Sphinx 
>> release (5.3.0) that
>> simplifies reference format for options and results in much simpler Option 
>> summary section ([1])
>>
>> The current GCC master (using Sphinx 5.3.0) converted docs can be seen here:
>> https://splichal.eu/scripts/sphinx/
>>
>> If you see any issues with the converted documentation, or have a feedback 
>> about it,
>> please reply to this email.
>>
>> Cheers,
>> Martin
>>
>> [1] https://github.com/sphinx-doc/sphinx/pull/10840
>> [1] 
>> https://splichal.eu/scripts/sphinx/gcc/_build/html/gcc-command-options/option-summary.html
>>
>>
>>
>>
> 
> 
> 
> 

Re: [PATCH RESEND 0/1] RFC: P1689R5 support

[Martin Liška]

On 10/18/22 14:22, Ben Boeckel wrote:
> On Thu, Oct 13, 2022 at 13:08:46 -0400, David Malcolm wrote:
>> On Mon, 2022-10-10 at 16:21 -0400, Jason Merrill wrote:
>>> David Malcolm would probably know best about JSON wrangling.
>>
>> Unfortunately our JSON output doesn't make any guarantees about the
>> ordering of keys within an object, so the precise textual output
>> changes from run to run.  I've coped with that in my test cases by
>> limiting myself to simple regexes of fragments of the JSON output.
>>
>> Martin Liska [CCed] went much further in
>> 4e275dccfc2467b3fe39012a3dd2a80bac257dd0 by adding a run-gcov-pytest
>> DejaGnu directive, allowing for test cases for gcov to be written in
>> Python, which can thus test much more interesting assertions about the
>> generated JSON.
> 
> Ok, if Python is acceptable, I'll use its stdlib to do "fancy" things.
> Part of this is because I want to assert that unnecessary fields don't
> exist and that sounds…unlikely to be possible in any maintainable way
> (assuming it is possible) with regexen. `jq` could help immensely, but
> that is probably a bridge too far :) .

Yes, please use Python if you have a more complicated output verification.

Examples I introduced:
./gcc/testsuite/g++.dg/gcov/test-pr98273.py
./gcc/testsuite/g++.dg/gcov/test-gcov-17.py

Martin

> 
> Thanks,
> 
> --Ben