Re: [PATCH] c++: Add __reference_con{struc,ver}ts_from_temporary [PR104477]

[Jason Merrill via Gcc-patches]

On 7/14/22 13:43, Marek Polacek wrote:

On Tue, Jul 12, 2022 at 04:15:00PM -0400, Jason Merrill wrote:

On 7/12/22 16:10, Jason Merrill wrote:

On 7/8/22 13:41, Marek Polacek wrote:

This patch implements C++23 P2255R2, which adds two new type traits to
detect reference binding to a temporary.  They can be used to detect code
like

    std::tuple t("meow");

which is incorrect because it always creates a dangling reference,
because
the std::string temporary is created inside the selected constructor of
std::tuple, and not outside it.

There are two new compiler builtins,
__reference_constructs_from_temporary
and __reference_converts_from_temporary.  The former is used to simulate
direct- and the latter copy-initialization context.  But I had a
hard time
finding a test where there's actually a difference.  Under DR 2267, both
of these are invalid:

    struct A { } a;
    struct B { explicit B(const A&); };
    const B {a};
    const B (a);

so I had to peruse [over.match.ref], and eventually realized that the
difference can be seen here:

    struct G {
  operator int(); // #1
  explicit operator int&&(); // #2
    };

int&& r1(G{}); // use #2 (no temporary)
int&& r2 = G{}; // use #1 (a temporary is created to be bound to int&&)

The implementation itself was rather straightforward because we already
have conv_binds_ref_to_prvalue.  The main function here is
reference_from_temporary.  The renaming to ref_conv_binds_to_temporary_p
is because previously the function didn't distinguish between an invalid
conversion and one that binds to a prvalue.

The patch also adds the relevant class and variable templates to
.

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

 PR c++/104477

gcc/c-family/ChangeLog:

 * c-common.cc (c_common_reswords): Add
 __reference_constructs_from_temporary and
 __reference_converts_from_temporary.
 * c-common.h (enum rid): Add RID_REF_CONSTRUCTS_FROM_TEMPORARY and
 RID_REF_CONVERTS_FROM_TEMPORARY.

gcc/cp/ChangeLog:

 * call.cc (ref_conv_binds_directly_p): Rename to ...
 (ref_conv_binds_to_temporary_p): ... this.  Add a new bool
 parameter.  Return true only if the conversion is valid and
 conv_binds_ref_to_prvalue returns true.
 * constraint.cc (diagnose_trait_expr): Handle
 CPTK_REF_CONSTRUCTS_FROM_TEMPORARY and
CPTK_REF_CONVERTS_FROM_TEMPORARY.
 * cp-tree.h (enum cp_trait_kind): Add
CPTK_REF_CONSTRUCTS_FROM_TEMPORARY
 and CPTK_REF_CONVERTS_FROM_TEMPORARY.
 (ref_conv_binds_directly_p): Rename to ...
 (ref_conv_binds_to_temporary_p): ... this.
 (reference_from_temporary): Declare.
 * cxx-pretty-print.cc (pp_cxx_trait_expression): Handle
 CPTK_REF_CONSTRUCTS_FROM_TEMPORARY and
CPTK_REF_CONVERTS_FROM_TEMPORARY.
 * method.cc (reference_from_temporary): New.
 * parser.cc (cp_parser_primary_expression): Handle
 RID_REF_CONSTRUCTS_FROM_TEMPORARY and
RID_REF_CONVERTS_FROM_TEMPORARY.
 (cp_parser_trait_expr): Likewise.
 (warn_for_range_copy): Adjust to call ref_conv_binds_to_temporary_p.
 * semantics.cc (trait_expr_value): Handle
 CPTK_REF_CONSTRUCTS_FROM_TEMPORARY and
CPTK_REF_CONVERTS_FROM_TEMPORARY.
 (finish_trait_expr): Likewise.

libstdc++-v3/ChangeLog:

 * include/std/type_traits (reference_constructs_from_temporary,
 reference_converts_from_temporary): New class templates.
 (reference_constructs_from_temporary_v,
 reference_converts_from_temporary_v): New variable templates.
 (__cpp_lib_reference_from_temporary): Define for C++23.
 * include/std/version (__cpp_lib_reference_from_temporary):
Define for
 C++23.
 * testsuite/20_util/variable_templates_for_traits.cc: Test
 reference_constructs_from_temporary_v and
 reference_converts_from_temporary_v.
 * testsuite/20_util/reference_from_temporary/value.cc: New test.
 * testsuite/20_util/reference_from_temporary/value2.cc: New test.
 * testsuite/20_util/reference_from_temporary/version.cc: New test.

gcc/testsuite/ChangeLog:

 * g++.dg/ext/reference_constructs_from_temporary1.C: New test.
 * g++.dg/ext/reference_converts_from_temporary1.C: New test.
---
   gcc/c-family/c-common.cc  |   4 +
   gcc/c-family/c-common.h   |   2 +
   gcc/cp/call.cc    |  14 +-
   gcc/cp/constraint.cc  |   8 +
   gcc/cp/cp-tree.h  |   7 +-
   gcc/cp/cxx-pretty-print.cc    |   6 +
   gcc/cp/method.cc  |  28 +++
   gcc/cp/parser.cc  |  14 +-
   gcc/cp/semantics.cc   |   8 +
   .../reference_constructs_from_temporary1.C    | 214 ++
   .../ext/reference_converts_from_temporary1.C  | 214 ++
   libstdc++-v3/include/std/type_traits  |  39 
   libstdc++-v3/include/std/version  |   5 +-
   

Re: [PATCH] x86: Disable sibcall if indirect_return attribute doesn't match

[Hongtao Liu via Gcc-patches]

On Fri, Jul 15, 2022 at 1:44 AM H.J. Lu via Gcc-patches
 wrote:
>
> When shadow stack is enabled, function with indirect_return attribute
> may return via indirect jump.  In this case, we need to disable sibcall
> if caller doesn't have indirect_return attribute and indirect branch
> tracking is enabled since compiler won't generate ENDBR when calling the
> caller.
>
LGTM.
> gcc/
>
> PR target/85620
> * config/i386/i386.cc (ix86_function_ok_for_sibcall): Return
> false if callee has indirect_return attribute and caller
> doesn't.
>
> gcc/testsuite/
>
> PR target/85620
> * gcc.target/i386/pr85620-2.c: Updated.
> * gcc.target/i386/pr85620-5.c: New test.
> * gcc.target/i386/pr85620-6.c: Likewise.
> * gcc.target/i386/pr85620-7.c: Likewise.
> ---
>  gcc/config/i386/i386.cc   | 10 ++
>  gcc/testsuite/gcc.target/i386/pr85620-2.c |  3 ++-
>  gcc/testsuite/gcc.target/i386/pr85620-5.c | 13 +
>  gcc/testsuite/gcc.target/i386/pr85620-6.c | 14 ++
>  gcc/testsuite/gcc.target/i386/pr85620-7.c | 14 ++
>  5 files changed, 53 insertions(+), 1 deletion(-)
>  create mode 100644 gcc/testsuite/gcc.target/i386/pr85620-5.c
>  create mode 100644 gcc/testsuite/gcc.target/i386/pr85620-6.c
>  create mode 100644 gcc/testsuite/gcc.target/i386/pr85620-7.c
>
> diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc
> index 3a3c7299eb4..e03f86d4a23 100644
> --- a/gcc/config/i386/i386.cc
> +++ b/gcc/config/i386/i386.cc
> @@ -1024,6 +1024,16 @@ ix86_function_ok_for_sibcall (tree decl, tree exp)
>  return false;
>  }
>
> +  /* Disable sibcall if callee has indirect_return attribute and
> + caller doesn't since callee will return to the caller's caller
> + via an indirect jump.  */
> +  if (((flag_cf_protection & (CF_RETURN | CF_BRANCH))
> +   == (CF_RETURN | CF_BRANCH))
> +  && lookup_attribute ("indirect_return", TYPE_ATTRIBUTES (type))
> +  && !lookup_attribute ("indirect_return",
> +   TYPE_ATTRIBUTES (TREE_TYPE (cfun->decl
> +return false;
> +
>/* Otherwise okay.  That also includes certain types of indirect calls.  */
>return true;
>  }
> diff --git a/gcc/testsuite/gcc.target/i386/pr85620-2.c 
> b/gcc/testsuite/gcc.target/i386/pr85620-2.c
> index b2e680fa1fe..14ce0ffd1e1 100644
> --- a/gcc/testsuite/gcc.target/i386/pr85620-2.c
> +++ b/gcc/testsuite/gcc.target/i386/pr85620-2.c
> @@ -1,6 +1,7 @@
>  /* { dg-do compile } */
>  /* { dg-options "-O2 -fcf-protection" } */
> -/* { dg-final { scan-assembler-times {\mendbr} 1 } } */
> +/* { dg-final { scan-assembler-times {\mendbr} 2 } } */
> +/* { dg-final { scan-assembler-not "jmp" } } */
>
>  struct ucontext;
>
> diff --git a/gcc/testsuite/gcc.target/i386/pr85620-5.c 
> b/gcc/testsuite/gcc.target/i386/pr85620-5.c
> new file mode 100644
> index 000..04537702d09
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/i386/pr85620-5.c
> @@ -0,0 +1,13 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -fcf-protection" } */
> +/* { dg-final { scan-assembler-not "jmp" } } */
> +
> +struct ucontext;
> +
> +extern int (*bar) (struct ucontext *) __attribute__((__indirect_return__));
> +
> +int
> +foo (struct ucontext *oucp)
> +{
> +  return bar (oucp);
> +}
> diff --git a/gcc/testsuite/gcc.target/i386/pr85620-6.c 
> b/gcc/testsuite/gcc.target/i386/pr85620-6.c
> new file mode 100644
> index 000..0b6a64e8454
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/i386/pr85620-6.c
> @@ -0,0 +1,14 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -fcf-protection" } */
> +/* { dg-final { scan-assembler "jmp" } } */
> +
> +struct ucontext;
> +
> +extern int bar (struct ucontext *) __attribute__((__indirect_return__));
> +
> +__attribute__((__indirect_return__))
> +int
> +foo (struct ucontext *oucp)
> +{
> +  return bar (oucp);
> +}
> diff --git a/gcc/testsuite/gcc.target/i386/pr85620-7.c 
> b/gcc/testsuite/gcc.target/i386/pr85620-7.c
> new file mode 100644
> index 000..fa62d56decf
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/i386/pr85620-7.c
> @@ -0,0 +1,14 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -fcf-protection" } */
> +/* { dg-final { scan-assembler "jmp" } } */
> +
> +struct ucontext;
> +
> +extern int (*bar) (struct ucontext *) __attribute__((__indirect_return__));
> +extern int foo (struct ucontext *) __attribute__((__indirect_return__));
> +
> +int
> +foo (struct ucontext *oucp)
> +{
> +  return bar (oucp);
> +}
> --
> 2.36.1
>


-- 
BR,
Hongtao

[Bug tree-optimization/106297] stringop-overflow misbehaviour on atomic

[chipitsine at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Илья Шипицин  ---
I have provided repro steps, hope they can be used to find any answer.

I tried to add "-save-temps", but it gave another error (not seen without that
option):

  CC  src/slz.o
In file included from src/slz.c:29:
include/import/slz-tables.h: In function ‘dist_to_code’:
include/import/slz-tables.h:182:35: error: this statement may fall through
[-Werror=implicit-fallthrough=]
  182 | case 24577 ... 32768: code++; /* fall through */
  |   ^~
compilation terminated due to -Wfatal-errors.
cc1: all warnings being treated as errors
make: *** [Makefile:1004: src/slz.o] Error 1

[Bug target/106113] wrong codegen for _mm_[u]comineq_{ss,sd} and need to return PF result.

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Kong Lingling :

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

commit r13-1702-gae69e6f61b93dcb5b1e7ef609431f100c1b9b2e5
Author: konglin1 
Date:   Fri Jul 15 10:29:27 2022 +0800

i386: Fix _mm_[u]comixx_{ss,sd} codegen and add PF result. [PR106113]

gcc/ChangeLog:

PR target/106113
* config/i386/i386-builtin.def (BDESC): Fix [u]comi{ss,sd}
comparison due to intrinsics changed over time.
* config/i386/i386-expand.cc (ix86_ssecom_setcc):
Add unordered check and mode for sse comi codegen.
(ix86_expand_sse_comi): Add unordered check and check a different
CCmode.
(ix86_expand_sse_comi_round):Extract unordered check and mode part
in ix86_ssecom_setcc.

gcc/testsuite/ChangeLog:

PR target/106113
* gcc.target/i386/avx-vcomisd-pr106113-2.c: New test.
* gcc.target/i386/avx-vcomiss-pr106113-2.c: Ditto.
* gcc.target/i386/avx-vucomisd-pr106113-2.c: Ditto.
* gcc.target/i386/avx-vucomiss-pr106113-2.c: Ditto.
* gcc.target/i386/sse-comiss-pr106113-1.c: Ditto.
* gcc.target/i386/sse-comiss-pr106113-2.c: Ditto.
* gcc.target/i386/sse-ucomiss-pr106113-1.c: Ditto.
* gcc.target/i386/sse-ucomiss-pr106113-2.c: Ditto.
* gcc.target/i386/sse2-comisd-pr106113-1.c: Ditto.
* gcc.target/i386/sse2-comisd-pr106113-2.c: Ditto.
* gcc.target/i386/sse2-ucomisd-pr106113-1.c: Ditto.
* gcc.target/i386/sse2-ucomisd-pr106113-2.c: Ditto.

Re: [PATCH] i386: Fix _mm_[u]comixx_{ss,sd} codegen and add PF result. [PR106113]

[Hongtao Liu via Gcc-patches]

On Thu, Jul 14, 2022 at 2:11 PM Kong, Lingling via Gcc-patches
 wrote:
>
> Hi,
>
> The patch is to fix _mm_[u]comixx_{ss,sd} codegen and add PF result.  These 
> intrinsics have changed over time, like `_mm_comieq_ss ` old operation is 
> `RETURN ( a[31:0] == b[31:0] ) ? 1 : 0`, and new operation update is `RETURN 
> ( a[31:0] != NaN AND b[31:0] != NaN AND a[31:0] == b[31:0] ) ? 1 : 0`.
>
> OK for master?
All _mm_comiXX_ss uses order_compare except for mm_comine_ss which
uses unordered_compare, now it's aligned with intrinsic guide.
Ok for trunk.
>
> gcc/ChangeLog:
>
> PR target/106113
> * config/i386/i386-builtin.def (BDESC): Fix [u]comi{ss,sd}
> comparison due to intrinsics changed over time.
> * config/i386/i386-expand.cc (ix86_ssecom_setcc):
> Add unordered check and mode for sse comi codegen.
> (ix86_expand_sse_comi): Add unordered check and check a different
> CCmode.
> (ix86_expand_sse_comi_round):Extract unordered check and mode part
> in ix86_ssecom_setcc.
>
> gcc/testsuite/ChangeLog:
>
> PR target/106113
> * gcc.target/i386/avx-vcomisd-pr106113-2.c: New test.
> * gcc.target/i386/avx-vcomiss-pr106113-2.c: Ditto.
> * gcc.target/i386/avx-vucomisd-pr106113-2.c: Ditto.
> * gcc.target/i386/avx-vucomiss-pr106113-2.c: Ditto.
> * gcc.target/i386/sse-comiss-pr106113-1.c: Ditto.
> * gcc.target/i386/sse-comiss-pr106113-2.c: Ditto.
> * gcc.target/i386/sse-ucomiss-pr106113-1.c: Ditto.
> * gcc.target/i386/sse-ucomiss-pr106113-2.c: Ditto.
> * gcc.target/i386/sse2-comisd-pr106113-1.c: Ditto.
> * gcc.target/i386/sse2-comisd-pr106113-2.c: Ditto.
> * gcc.target/i386/sse2-ucomisd-pr106113-1.c: Ditto.
> * gcc.target/i386/sse2-ucomisd-pr106113-2.c: Ditto.
> ---
>  gcc/config/i386/i386-builtin.def  |  32 ++--
>  gcc/config/i386/i386-expand.cc| 140 +++---
>  .../gcc.target/i386/avx-vcomisd-pr106113-2.c  |   8 +
>  .../gcc.target/i386/avx-vcomiss-pr106113-2.c  |   8 +
>  .../gcc.target/i386/avx-vucomisd-pr106113-2.c |   8 +
>  .../gcc.target/i386/avx-vucomiss-pr106113-2.c |   8 +
>  .../gcc.target/i386/sse-comiss-pr106113-1.c   |  19 +++
>  .../gcc.target/i386/sse-comiss-pr106113-2.c   |  59 
>  .../gcc.target/i386/sse-ucomiss-pr106113-1.c  |  19 +++
>  .../gcc.target/i386/sse-ucomiss-pr106113-2.c  |  59 
>  .../gcc.target/i386/sse2-comisd-pr106113-1.c  |  19 +++
>  .../gcc.target/i386/sse2-comisd-pr106113-2.c  |  59 
>  .../gcc.target/i386/sse2-ucomisd-pr106113-1.c |  19 +++
>  .../gcc.target/i386/sse2-ucomisd-pr106113-2.c |  59 
>  14 files changed, 450 insertions(+), 66 deletions(-)
>  create mode 100644 gcc/testsuite/gcc.target/i386/avx-vcomisd-pr106113-2.c
>  create mode 100644 gcc/testsuite/gcc.target/i386/avx-vcomiss-pr106113-2.c
>  create mode 100644 gcc/testsuite/gcc.target/i386/avx-vucomisd-pr106113-2.c
>  create mode 100644 gcc/testsuite/gcc.target/i386/avx-vucomiss-pr106113-2.c
>  create mode 100644 gcc/testsuite/gcc.target/i386/sse-comiss-pr106113-1.c
>  create mode 100644 gcc/testsuite/gcc.target/i386/sse-comiss-pr106113-2.c
>  create mode 100644 gcc/testsuite/gcc.target/i386/sse-ucomiss-pr106113-1.c
>  create mode 100644 gcc/testsuite/gcc.target/i386/sse-ucomiss-pr106113-2.c
>  create mode 100644 gcc/testsuite/gcc.target/i386/sse2-comisd-pr106113-1.c
>  create mode 100644 gcc/testsuite/gcc.target/i386/sse2-comisd-pr106113-2.c
>  create mode 100644 gcc/testsuite/gcc.target/i386/sse2-ucomisd-pr106113-1.c
>  create mode 100644 gcc/testsuite/gcc.target/i386/sse2-ucomisd-pr106113-2.c
>
> diff --git a/gcc/config/i386/i386-builtin.def 
> b/gcc/config/i386/i386-builtin.def
> index fd160935e67..acb7e8ca64b 100644
> --- a/gcc/config/i386/i386-builtin.def
> +++ b/gcc/config/i386/i386-builtin.def
> @@ -35,30 +35,30 @@
>  IX86_BUILTIN__BDESC_##NEXT_KIND##_FIRST - 1.  */
>
>  BDESC_FIRST (comi, COMI,
> -   OPTION_MASK_ISA_SSE, 0, CODE_FOR_sse_comi, "__builtin_ia32_comieq", 
> IX86_BUILTIN_COMIEQSS, UNEQ, 0)
> -BDESC (OPTION_MASK_ISA_SSE, 0, CODE_FOR_sse_comi, "__builtin_ia32_comilt", 
> IX86_BUILTIN_COMILTSS, UNLT, 0)
> -BDESC (OPTION_MASK_ISA_SSE, 0, CODE_FOR_sse_comi, "__builtin_ia32_comile", 
> IX86_BUILTIN_COMILESS, UNLE, 0)
> +   OPTION_MASK_ISA_SSE, 0, CODE_FOR_sse_comi, "__builtin_ia32_comieq", 
> IX86_BUILTIN_COMIEQSS, EQ, 0)
> +BDESC (OPTION_MASK_ISA_SSE, 0, CODE_FOR_sse_comi, "__builtin_ia32_comilt", 
> IX86_BUILTIN_COMILTSS, LT, 0)
> +BDESC (OPTION_MASK_ISA_SSE, 0, CODE_FOR_sse_comi, "__builtin_ia32_comile", 
> IX86_BUILTIN_COMILESS, LE, 0)
>  BDESC (OPTION_MASK_ISA_SSE, 0, CODE_FOR_sse_comi, "__builtin_ia32_comigt", 
> IX86_BUILTIN_COMIGTSS, GT, 0)
>  BDESC (OPTION_MASK_ISA_SSE, 0, CODE_FOR_sse_comi, "__builtin_ia32_comige", 
> IX86_BUILTIN_COMIGESS, GE, 0)
> -BDESC (OPTION_MASK_ISA_SSE, 0, CODE_FOR_sse_comi, "__builtin_ia32_comineq", 
> 

Re: [PATCH, committed] Fortran: error recovery for bad initializers of implied-shape arrays [PR106209]

[Jerry D via Gcc-patches]

Hi Herald,

Looks good to me. I have always preferred informative messages.

Thanks,

Jerry
On 7/14/22 1:34 PM, Harald Anlauf via Fortran wrote:

Dear all,

the attached patch introduces error recovery for two cases of using
an invalid array in a declaration of an implied-shape array instead
of hitting internal errors.

Initial patch by Steve.  The final version was approved in the PR
by Steve.

Committed as:

https://gcc.gnu.org/g:748f8a8b145dde59c7b63aa68b5a59515b7efc49

Thanks,
Harald

[PATCH v2] powerpc: add documentation for HWCAPs

[Nicholas Piggin via Gcc]

Take the arm64 HWCAP documentation file and adjust it for powerpc.

Signed-off-by: Nicholas Piggin 
---
Thanks for the comments.

v2:
- Addition of "categories" paragraph.
- Change "features should not be probed via other means" to "HWCAP is
  preferred".
- Speling fix.
- 
 Documentation/powerpc/elf_hwcaps.rst | 234 +++
 1 file changed, 234 insertions(+)
 create mode 100644 Documentation/powerpc/elf_hwcaps.rst

diff --git a/Documentation/powerpc/elf_hwcaps.rst 
b/Documentation/powerpc/elf_hwcaps.rst
new file mode 100644
index ..5f28687d54f3
--- /dev/null
+++ b/Documentation/powerpc/elf_hwcaps.rst
@@ -0,0 +1,234 @@
+.. _elf_hwcaps_index:
+
+==
+POWERPC ELF HWCAPs
+==
+
+This document describes the usage and semantics of the powerpc ELF HWCAPs.
+
+
+1. Introduction
+---
+
+Some hardware or software features are only available on some CPU
+implementations, and/or with certain kernel configurations, but have no other
+discovery mechanism available to userspace code. The kernel exposes the
+presence of these features to userspace through a set of flags called HWCAPs,
+exposed in the auxiliary vector.
+
+Userspace software can test for features by acquiring the AT_HWCAP or
+AT_HWCAP2 entry of the auxiliary vector, and testing whether the relevant
+flags are set, e.g.::
+
+   bool floating_point_is_present(void)
+   {
+   unsigned long HWCAPs = getauxval(AT_HWCAP);
+   if (HWCAPs & PPC_FEATURE_HAS_FPU)
+   return true;
+
+   return false;
+   }
+
+Where software relies on a feature described by a HWCAP, it should check the
+relevant HWCAP flag to verify that the feature is present before attempting to
+make use of the feature.
+
+HWCAP is the preferred method to test for the presence of a feature rather
+than probing through other means, which may not be reliable or may cause
+unpredictable behaviour.
+
+Software that targets a particular platform does not necessarily have to
+test for required or implied features. For example if the program requires
+FPU, VMX, VSX, it is not necessary to test those HWCAPs, and it may be
+impossible to do so if the compiler generates code requiring those features.
+
+2. Facilities
+-
+
+The Power ISA uses the term "facility" to describe a class of instructions,
+registers, interrupts, etc. The presence or absence of a facility indicates
+whether this class is available to be used, but the specifics depend on the
+ISA version. For example, if the VSX facility is available, the VSX
+instructions that can be used differ between the v3.0B and v3.1B ISA
+versions.
+
+3. Categories
+-
+
+The Power ISA before v3.0 uses the term "category" to describe certain
+classes of instructions and operating modes which may be optional or
+mutually exclusive, the exact meaning of the HWCAP flag may depend on
+context, e.g., the presence of the BOOKE feature implies that the server
+category is not implemented.
+
+4. HWCAP allocation
+---
+
+HWCAPs are allocated as described in Power Architecture 64-Bit ELF V2 ABI
+Specification (which will be reflected in the kernel's uapi headers).
+
+5. The HWCAPs exposed in AT_HWCAP
+-
+
+PPC_FEATURE_32
+32-bit CPU
+
+PPC_FEATURE_64
+64-bit CPU (userspace may be running in 32-bit mode).
+
+PPC_FEATURE_601_INSTR
+The processor is PowerPC 601.
+Unused in the kernel since:
+  f0ed73f3fa2c ("powerpc: Remove PowerPC 601")
+
+PPC_FEATURE_HAS_ALTIVEC
+Vector (aka Altivec, VMX) facility is available.
+
+PPC_FEATURE_HAS_FPU
+Floating point facility is available.
+
+PPC_FEATURE_HAS_MMU
+Memory management unit is present and enabled.
+
+PPC_FEATURE_HAS_4xxMAC
+The processor is 40x or 44x family.
+
+PPC_FEATURE_UNIFIED_CACHE
+The processor has a unified L1 cache for instructions and data, as
+found in NXP e200.
+Unused in the kernel since:
+  39c8bf2b3cc1 ("powerpc: Retire e200 core (mpc555x processor)")
+
+PPC_FEATURE_HAS_SPE
+Signal Processing Engine facility is available.
+
+PPC_FEATURE_HAS_EFP_SINGLE
+Embedded Floating Point single precision operations are available.
+
+PPC_FEATURE_HAS_EFP_DOUBLE
+Embedded Floating Point double precision operations are available.
+
+PPC_FEATURE_NO_TB
+The timebase facility (mftb instruction) is not available.
+This is a 601 specific HWCAP, so if it is known that the processor
+running is not a 601, via other HWCAPs or other means, it is not
+required to test this bit before using the timebase.
+Unused in the kernel since:
+  f0ed73f3fa2c ("powerpc: Remove PowerPC 601")
+
+PPC_FEATURE_POWER4
+The processor is POWER4 or PPC970/FX/MP.
+POWER4 support dropped from the kernel since:
+  471d7ff8b51b ("powerpc/64s: Remove POWER4 support")
+
+PPC_FEATURE_POWER5
+The processor is POWER5.
+
+PPC_FEATURE_POWER5_PLUS
+The 

Re: kernel sparse annotations vs. compiler attributes and debug_annotate_{type, decl} WAS: Re: [PATCH 0/9] Add debug_annotate attributes

[Yonghong Song via Gcc-patches]

On 7/14/22 8:09 AM, Jose E. Marchesi wrote:


Hi Yonghong.


On 7/7/22 1:24 PM, Jose E. Marchesi wrote:

Hi Yonghong.


On 6/21/22 9:12 AM, Jose E. Marchesi wrote:



On 6/17/22 10:18 AM, Jose E. Marchesi wrote:

Hi Yonghong.


On 6/15/22 1:57 PM, David Faust wrote:


On 6/14/22 22:53, Yonghong Song wrote:



On 6/7/22 2:43 PM, David Faust wrote:

Hello,

This patch series adds support for:

- Two new C-language-level attributes that allow to associate (to "annotate" or
to "tag") particular declarations and types with arbitrary strings. As
explained below, this is intended to be used to, for example, 
characterize
certain pointer types.

- The conveyance of that information in the DWARF output in the form of a new
DIE: DW_TAG_GNU_annotation.

- The conveyance of that information in the BTF output in the form of two new
kinds of BTF objects: BTF_KIND_DECL_TAG and BTF_KIND_TYPE_TAG.

All of these facilities are being added to the eBPF ecosystem, and support for
them exists in some form in LLVM.

Purpose
===

1)  Addition of C-family language constructs (attributes) to specify free-text
  tags on certain language elements, such as struct fields.

  The purpose of these annotations is to provide additional information 
about
  types, variables, and function parameters of interest to the kernel. A
  driving use case is to tag pointer types within the linux kernel and 
eBPF
  programs with additional semantic information, such as '__user' or 
'__rcu'.

  For example, consider the linux kernel function do_execve with the
  following declaration:

static int do_execve(struct filename *filename,
   const char __user *const __user *__argv,
   const char __user *const __user *__envp);

  Here, __user could be defined with these annotations to record 
semantic
  information about the pointer parameters (e.g., they are 
user-provided) in
  DWARF and BTF information. Other kernel facilites such as the eBPF 
verifier
  can read the tags and make use of the information.

2)  Conveying the tags in the generated DWARF debug info.

  The main motivation for emitting the tags in DWARF is that the Linux 
kernel
  generates its BTF information via pahole, using DWARF as a source:

  ++  BTF  BTF   +--+
  | pahole |---> vmlinux.btf --->| verifier |
  ++ +--+
  ^^
  ||
DWARF |BTF |
  ||
   vmlinux  +-+
   module1.ko   | BPF program |
   module2.ko   +-+
 ...

  This is because:

  a)  Unlike GCC, LLVM will only generate BTF for BPF programs.

  b)  GCC can generate BTF for whatever target with -gbtf, but there is 
no
  support for linking/deduplicating BTF in the linker.

  In the scenario above, the verifier needs access to the pointer tags 
of
  both the kernel types/declarations (conveyed in the DWARF and 
translated
  to BTF by pahole) and those of the BPF program (available directly in 
BTF).

  Another motivation for having the tag information in DWARF, unrelated 
to
  BPF and BTF, is that the drgn project (another DWARF consumer) also 
wants
  to benefit from these tags in order to differentiate between different
  kinds of pointers in the kernel.

3)  Conveying the tags in the generated BTF debug info.

  This is easy: the main purpose of having this info in BTF is for the
  compiled eBPF programs. The kernel verifier can then access the tags
  of pointers used by the eBPF programs.


For more information about these tags and the motivation behind them, please
refer to the following linux kernel discussions:

https://lore.kernel.org/bpf/20210914223004.244411-1-...@fb.com/
https://lore.kernel.org/bpf/20211012164838.3345699-1-...@fb.com/
https://lore.kernel.org/bpf/2022012604.1504583-1-...@fb.com/


Implementation Overview
===

To enable these annotations, two new C language attributes are added:
__attribute__((debug_annotate_decl("foo"))) and
__attribute__((debug_annotate_type("bar"))). Both attributes accept a single
arbitrary string constant argument, which will be recorded in the generated
DWARF and/or BTF debug information. They have no effect on code generation.

Note that we are not using the same attribute names as LLVM (btf_decl_tag and
btf_type_tag, respectively). While these attributes 

Re: [PATCH Linux] powerpc: add documentation for HWCAPs

[Nicholas Piggin via Gcc]

Excerpts from Segher Boessenkool's message of May 25, 2022 4:32 am:
> On Tue, May 24, 2022 at 11:52:00AM +0200, Florian Weimer wrote:
>> * Nicholas Piggin:
>> 
>> > +2. Facilities
>> > +-
>> > +The Power ISA uses the term "facility" to describe a class of 
>> > instructions,
>> > +registers, interrupts, etc. The presence or absence of a facility 
>> > indicates
>> > +whether this class is available to be used, but the specifics depend on 
>> > the
>> > +ISA version. For example, if the VSX facility is available, the VSX
>> > +instructions that can be used differ between the v3.0B and v3.1B ISA
>> > +verstions.
>> 
>> The 2.07 ISA manual also has categories.  ISA 3.0 made a lot of things
>> mandatory.  It may make sense to clarify that feature bits for mandatory
>> aspects of the ISA are still set, to help with backwards compatibility.
> 
> Linux runs on ISA 1.xx and ISA 2.01 machines still.  "Category" wasn't
> invented for either yet either, but similar concepts did exist of
> course.

Not sure what to say about this. It now also has "Compliancy Subset"
although maybe that's more like a set of features rather than
incompatible features or modes such as some of the category stuff
seems to be. I'll try add something.

Thanks,
Nick

Re: [PATCH Linux] powerpc: add documentation for HWCAPs

[Nicholas Piggin via Gcc]

Finally got some details about the icache snoop question so just coming 
back to this now, sorry for the delay... (POWER10 does support the 
coherent icache flush sequence as expected, there was some updates to
the UM wording but that will be fixed).

Excerpts from Segher Boessenkool's message of May 25, 2022 3:38 am:
> Hi!
> 
> On Tue, May 24, 2022 at 07:38:28PM +1000, Nicholas Piggin wrote:
>> Thanks for all the comments and corrections. It should be nearing the
>> point where it is useful now. Yes I do think it would be useful to align
>> this more with OpenPOWER docs (and possibly eventually move it into the
>> ABI, given that's the allocator of these numbers) but that's not
>> done yet.
> 
> The auxiliary vector is a Linux/glibc thing, it should not be described
> in more generic ABI documents.  It is fine where you have it now afaics.

It is already in the ABI document. In fact that (not the kernel) had
been the allocator of the feature numbers, at least in the past I think.

> 
>> +Where software relies on a feature described by a HWCAP, it should check the
>> +relevant HWCAP flag to verify that the feature is present before attempting 
>> to
>> +make use of the feature.
>> +
>> +Features should not be probed through other means. When a feature is not
>> +available, attempting to use it may result in unpredictable behaviour, and
>> +may not be guaranteed to result in any reliable indication that the feature
>> +is unavailable.
> 

> Traditionally VMX was tested for by simply executing an instruction and
> catching SIGILL.  This is portable even.  This has worked fine for over
> two decades, it's a bit weird to declare this a forbidden practice
> now :-)

The statement does not override architectural specification, so
if an encoding does not exist then it should cause a trap and SIGILL.
I suppose in theory we could work around performance or correctness
issues in an implementation by clearing HWCAP even if the hardware does 
execute the instruction, so I would still say testing HWCAP is
preferred.

> 
> It certainly isn't recommended for more complex and/or newer things.
> 
>> +verstions.
> 
> (typo.  spellcheck maybe?)

Thanks,
Nick

[Bug c++/106311] [12/13 Regression] internal compiler error in redeclare_class_template

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

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Target Milestone|--- |12.2
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2022-07-15
Summary|internal compiler error in  |[12/13 Regression] internal
   |redeclare_class_template|compiler error in
   ||redeclare_class_template
   Keywords||ice-on-invalid-code
   Priority|P3  |P2

--- Comment #1 from Marek Polacek  ---
Started with r12-7562.  Patch:

--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -6377,7 +6377,8 @@ redeclare_class_template (tree type, tree parms, tree
cons)
{
  auto_diagnostic_group d;
  error ("template parameter %q+#D", tmpl_parm);
- inform (DECL_SOURCE_LOCATION (parm), "redeclared here as %q#D", parm);
+ inform (DECL_P (parm) ? DECL_SOURCE_LOCATION (parm) : input_location,
+ "redeclared here as %q#D", parm);
  return false;
}

[Bug c++/106311] New: internal compiler error in redeclare_class_template

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

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

Bug ID: 106311
   Summary: internal compiler error in redeclare_class_template
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

Found while reducing bug 106309.

template  struct array;
template  struct array { };

$ ./cc1plus -quiet p.C
p.C:2:21: error: ‘size_t’ has not been declared
2 | template  struct array { };
  | ^~
p.C:1:21: error: template parameter ‘long int ’
1 | template  struct array;
  | ^~~~
p.C:2:38: internal compiler error: tree check: expected tree that contains
‘decl minimal’ structure, have ‘error_mark’ in redeclare_class_template, at
cp/pt.cc:6380
2 | template  struct array { };
  |  ^
0x1bcc50c tree_contains_struct_check_failed(tree_node const*,
tree_node_structure_enum, char const*, int, char const*)
/home/mpolacek/src/gcc/gcc/tree.cc:8991
0xb06dc6 contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
/home/mpolacek/src/gcc/gcc/tree.h:3622
0xe136e1 redeclare_class_template(tree_node*, tree_node*, tree_node*)
/home/mpolacek/src/gcc/gcc/cp/pt.cc:6380
0xc40a20 xref_tag(tag_types, tree_node*, TAG_how, bool)
/home/mpolacek/src/gcc/gcc/cp/decl.cc:15869
0xdaafdd cp_parser_class_head
/home/mpolacek/src/gcc/gcc/cp/parser.cc:26785

[Bug c++/106310] [12/13 Regregression] lookup after this-> seems wrong for dependent lookup

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|Failure to resolve call to  |[12/13 Regregression]
   |template member function in |lookup after this-> seems
   |template base class.|wrong for dependent lookup
   Keywords||rejects-valid

--- Comment #3 from Andrew Pinski  ---
And yes there is a defect report in namelookup after this-> . I know there is a
resolution of it but I don't remember which way it went either.

Marking as a regression as GCC 11 and before accepted the code but it might be
invalid ...

[Bug c++/106310] Failure to resolve call to template member function in template base class.

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

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

--- Comment #2 from Andrew Pinski  ---
Reduced testcase:
template 
struct set{};

template< typename T >
struct Base
{
template< int > int set(T const &) { }
};

template< typename T >
struct Derived : Base< T >
{
void f(T const ) {
this->template set< 0 >(arg);
}
};

[Bug c++/106310] Failure to resolve call to template member function in template base class.

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

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

--- Comment #1 from Andrew Pinski  ---
There is a C++ defect report about this.

[Bug c++/106310] New: Failure to resolve call to template member function in template base class.

[lnicoara at thinkoid dot org via Gcc-bugs]

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

Bug ID: 106310
   Summary: Failure to resolve call to template member function in
template base class.
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lnicoara at thinkoid dot org
  Target Milestone: ---

The following test case fails to compile with gcc (and I believe it should
correctly resolve the call to Base< T >::set):

$ cat t.cc; g++ -c t.cc
#include 

using namespace std;

namespace X {

template< typename T >
struct Base
{
template< std::size_t > void set(T const &) { }
};

template< typename T >
struct Derived : Base< T >
{
void f(T const ) {
this->template set< 0 >(arg);
}
};

}
t.cc: In member function ‘void X::Derived::f(const T&)’:
t.cc:17:39: error: type/value mismatch at argument 1 in template parameter list
for ‘template class std::set’
   17 | this->template set< 0 >(arg);
  |   ^
t.cc:17:39: note:   expected a type, got ‘0’
t.cc:17:39: error: template argument 2 is invalid
t.cc:17:39: error: template argument 3 is invalid

[Bug c++/106309] ICE: error reporting routines re-entered

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

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-07-14
 Ever confirmed|0   |1
   Keywords||ice-on-invalid-code
 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
Confirmed, thanks.

I think the problem is ultimately that shorten_compare doesn't have the
'complain' parameter, so when it's called while we're outputting another
diagnostic and shorten_compare attempts to warn, we run into the crash above.

gcc-10-20220714 is now available

[GCC Administrator via Gcc]

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

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

You'll find:

 gcc-10-20220714.tar.xz   Complete GCC

  SHA256=b0ceec19ecf32d1e2a31734904149a49ad5b4741ada904500a3f4cb3870c203c
  SHA1=16f3f007c23eb903b9066c4e5beca546eb5ca8c2

Diffs from 10-20220707 are available in the diffs/ subdirectory.

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

Re: [GCC 12 backport] Disable generating load/store vector pairs for block copies.

[Segher Boessenkool]

On Thu, Jul 14, 2022 at 05:49:57PM -0400, Michael Meissner wrote:
> On Thu, Jul 14, 2022 at 04:12:14PM -0500, Segher Boessenkool wrote:
> > You never posted the trunk version of this, so that never was approved
> > either.
> 
> I did post the trunk version on June 10th, and your only comment was fix the
> commit message, which I thought I did in the commit.

I did not approve the patch.  Of course not, I didn't even get as far as
reading it.  You should have fixed it and sent again, I did not approve
anything.

> > > +  if (TARGET_MMA && TARGET_EFFICIENT_UNALIGNED_VSX
> > > +   && rs6000_tune != PROCESSOR_POWER10)
> > >   rs6000_isa_flags |= OPTION_MASK_BLOCK_OPS_VECTOR_PAIR;
> > >else
> > >   rs6000_isa_flags &= ~OPTION_MASK_BLOCK_OPS_VECTOR_PAIR;
> > 
> > The TARGET_MMA in that should not be there.  Please fix that (that
> > probably needs more changes).
> 
> All of the movoo and movxo support require TARGET_MMA as does the code in
> rs6000-string.cc that could possibly generate load/store vector pair.

And all that is wrong and should be fixed.

> To
> remove the check here would mean also fixing all of the vector load and store
> pairs in mma.md.

That is wha I said, yes,.

> > This statement does the opposite of what the comment says.
> > 
> > Please fix this.  On trunk, first.

This is the core problem with this patch: it is simply wrong.

It is a very roundabout way of saying "only enable vector pairs if
-mcpu=power10 but -mtune=somethingelse".  Which is not a sensible
thing to do, and not what the comment says either.


Segher

[Bug c++/106309] New: ICE: error reporting routines re-entered

[raffael at casagrande dot ch via Gcc-bugs]

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

Bug ID: 106309
   Summary: ICE: error reporting routines re-entered
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: raffael at casagrande dot ch
  Target Milestone: ---

I tried for over 2 hours to get a minimal test case but it is quite involved
and for now I give up. I've created a file with the preprocessed source using
`-freport-bug` and uploaded it to my dropbox:
https://www.dropbox.com/s/oxx299jhx7yi3b2/ccFsUsUT.out?dl=0 . Unfortunately the
file is 11Kb large so I cannot attach it here in bugzilla.

The error message that GCC produces is the following:
--
‘
internal compiler error: error reporting routines re-entered.
0x1b9ca82 warning_at(unsigned int, int, char const*, ...)
???:0
0x95317a shorten_compare(unsigned int, tree_node**, tree_node**, tree_node**,
tree_code*)
???:0
0x915581 cp_build_binary_op(op_location_t const&, tree_code, tree_node*,
tree_node*, int)
???:0
0x75f23c build_new_op(op_location_t const&, tree_code, int, tree_node*,
tree_node*, tree_node*, tree_node*, tree_node**, int)
???:0
0x90c45f build_x_binary_op(op_location_t const&, tree_code, tree_node*,
tree_code, tree_node*, tree_code, tree_node*, tree_node**, int)
???:0
0x8b00a7 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
???:0
0x78f993 constraints_satisfied_p(tree_node*, tree_node*)
???:0
0x8b9f69 tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0x1ba82ac pp_format(pretty_printer*, text_info*)
???:0
0x1ba9830 pp_verbatim(pretty_printer*, char const*, ...)
???:0
0x1b9bfa1 diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
???:0
0x1b9cd76 error(char const*, ...)
???:0
0x8ade04 do_auto_deduction(tree_node*, tree_node*, tree_node*, int,
auto_deduction_context, tree_node*, int)
???:0
0x924d0a build_functional_cast(unsigned int, tree_node*, tree_node*, int)
???:0
0x8b1c54 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
???:0
0x8c0d29 instantiate_decl(tree_node*, bool, bool)
???:0
0x8d575b instantiate_pending_templates(int)
???:0
0x7db28f c_parse_final_cleanups()
???:0
Please submit a full bug report, with preprocessed source.
Please include the complete backtrace with any bug report.
See  for instructions.
--

As far as I can tell, the file which I uploaded to Dropbox should contain all
the information which is necessary to reproduce the bug (e.g. command line and
precompiled sources).
If you need more information to reproduce the bug, please let me know.

[PATCH] stack-protector: Check stack canary for noreturn function

[H.J. Lu via Gcc-patches]

Check stack canary for noreturn function to catch stack corruption
before calling noreturn function.  For C++, check stack canary when
throwing exception or resuming stack unwind to avoid corrupted stack.

gcc/

PR middle-end/58245
* calls.cc (expand_call): Check stack canary for noreturn
function.

gcc/testsuite/

PR middle-end/58245
* c-c++-common/pr58245-1.c: New test.
* g++.dg/pr58245-1.C: Likewise.
* g++.dg/fstack-protector-strong.C: Adjusted.
---
 gcc/calls.cc   |  7 ++-
 gcc/testsuite/c-c++-common/pr58245-1.c | 12 
 gcc/testsuite/g++.dg/fstack-protector-strong.C |  2 +-
 gcc/testsuite/g++.dg/pr58245-1.C   | 10 ++
 4 files changed, 29 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/c-c++-common/pr58245-1.c
 create mode 100644 gcc/testsuite/g++.dg/pr58245-1.C

diff --git a/gcc/calls.cc b/gcc/calls.cc
index bc96aff38f0..7816c2c8d99 100644
--- a/gcc/calls.cc
+++ b/gcc/calls.cc
@@ -3154,7 +3154,12 @@ expand_call (tree exp, rtx target, int ignore)
   if (pass && (flags & ECF_MALLOC))
start_sequence ();
 
-  if (pass == 0
+  /* Check the canary value for sibcall or function which doesn't
+return.  */
+  if ((pass == 0
+  || ((flags & ECF_NORETURN) != 0
+  && (fndecl
+  != get_callee_fndecl (targetm.stack_protect_fail ()
  && crtl->stack_protect_guard
  && targetm.stack_protect_runtime_enabled_p ())
stack_protect_epilogue ();
diff --git a/gcc/testsuite/c-c++-common/pr58245-1.c 
b/gcc/testsuite/c-c++-common/pr58245-1.c
new file mode 100644
index 000..945acc53004
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/pr58245-1.c
@@ -0,0 +1,12 @@
+/* { dg-do compile { target i?86-*-* x86_64-*-* rs6000-*-* s390x-*-* } } */
+/* { dg-options "-O2 -fstack-protector-all" } */
+
+extern void foo (void) __attribute__ ((noreturn));
+
+void
+bar (void)
+{
+  foo ();
+}
+
+/* { dg-final { scan-assembler-times "stack_chk_fail" 1 } } */
diff --git a/gcc/testsuite/g++.dg/fstack-protector-strong.C 
b/gcc/testsuite/g++.dg/fstack-protector-strong.C
index ae6d2fdb8df..034af2ce9ab 100644
--- a/gcc/testsuite/g++.dg/fstack-protector-strong.C
+++ b/gcc/testsuite/g++.dg/fstack-protector-strong.C
@@ -85,4 +85,4 @@ int foo7 (B *p)
   return p->return_slot ().a1;
 }
 
-/* { dg-final { scan-assembler-times "stack_chk_fail" 7 } } */
+/* { dg-final { scan-assembler-times "stack_chk_fail" 8 } } */
diff --git a/gcc/testsuite/g++.dg/pr58245-1.C b/gcc/testsuite/g++.dg/pr58245-1.C
new file mode 100644
index 000..1439bc62e71
--- /dev/null
+++ b/gcc/testsuite/g++.dg/pr58245-1.C
@@ -0,0 +1,10 @@
+/* { dg-do compile { target i?86-*-* x86_64-*-* rs6000-*-* s390x-*-* } } */
+/* { dg-options "-O2 -fstack-protector-all" } */
+
+void
+bar (void)
+{
+  throw 1;
+}
+
+/* { dg-final { scan-assembler-times "stack_chk_fail" 1 } } */
-- 
2.36.1

[PATCH] libphobos: Fix instability in the parallelized testsuite

[Lewis Hyatt via Gcc-patches]

Hello-

I get a different number of test results from libphobos.unittest/unittest.exp,
depending on server load. I believe it's because this testsuite doesn't check
runtest_file_p:

$ make -j 1 RUNTESTFLAGS='unittest.exp' check-target-libphobos | grep '^#'
 # of expected passes   10

$ make -j 2 RUNTESTFLAGS='unittest.exp' check-target-libphobos | grep '^#'
 # of expected passes   10
 # of expected passes   10

$ make -j 4 RUNTESTFLAGS='unittest.exp' check-target-libphobos | grep '^#'
 # of expected passes   10
 # of expected passes   10
 # of expected passes   10
 # of expected passes   10

When running in parallel along with other tests, even at a fixed argument
for -j, the number of tests that actually execute will depend on how many of the
parallel sub-makes happened to start prior to the first one finishing, hence
it changes from run to run.

The attached patch fixes it for me, if it looks OK? Thanks, this would remove
some noise from before/after test comparisons.

-Lewis
libphobos: Fix instability in the parallelized testsuite

libphobos.unittest/unittest.exp calls bare dg-test rather than dg-runtest, and
so it should call runtest_file_p to determine whether to run each test or
not. Without that call, the tests run too many times in parallel mode (they will
run as many times, as the argument to make -j).

libphobos/ChangeLog:

* testsuite/libphobos.unittest/unittest.exp: Call runtest_file_p
prior to running each test.

diff --git a/libphobos/testsuite/libphobos.unittest/unittest.exp 
b/libphobos/testsuite/libphobos.unittest/unittest.exp
index 2a019caca8c..175decdc333 100644
--- a/libphobos/testsuite/libphobos.unittest/unittest.exp
+++ b/libphobos/testsuite/libphobos.unittest/unittest.exp
@@ -42,6 +42,9 @@ foreach unit_test $unit_test_list {
 set expected_fail [lindex $unit_test 1]
 
 foreach test $tests {
+   if {![runtest_file_p $runtests $test]} {
+continue
+}
 set shouldfail $expected_fail
 dg-test $test "" $test_flags
 }

Re: [GCC 12 backport] Disable generating load/store vector pairs for block copies.

[Michael Meissner via Gcc-patches]

On Thu, Jul 14, 2022 at 04:12:14PM -0500, Segher Boessenkool wrote:
> On Thu, Jul 14, 2022 at 11:20:56AM -0400, Michael Meissner wrote:
> > I have applied the patch to GCC 12.
> > 
> > | From 22736f3d0d4fb8ce4afb3230023f8accdb03a623 Mon Sep 17 00:00:00 2001
> > | From: Michael Meissner 
> > | Date: Thu, 14 Jul 2022 11:16:08 -0400
> > | Subject: [PATCH] [BACKPORT] Disable generating load/store vector pairs 
> > for block copies.
> > 
> > Testing has found that using load and store vector pair for block copies
> > can result in a slow down on power10.  This patch disables using the
> > vector pair instructions for block copies if we are tuning for power10.
> > 
> > 2022-06-11   Michael Meissner  
> > 
> > gcc/
> > 
> > * config/rs6000/rs6000.cc (rs6000_option_override_internal): Do
> > not generate block copies with vector pair instructions if we are
> > tuning for power10.  Back port from master branch.
> 
> You never posted the trunk version of this, so that never was approved
> either.

I did post the trunk version on June 10th, and your only comment was fix the
commit message, which I thought I did in the commit.

> > +++ b/gcc/config/rs6000/rs6000.cc
> > @@ -4151,7 +4151,10 @@ rs6000_option_override_internal (bool global_init_p)
> >  
> >if (!(rs6000_isa_flags_explicit & OPTION_MASK_BLOCK_OPS_VECTOR_PAIR))
> >  {
> > -  if (TARGET_MMA && TARGET_EFFICIENT_UNALIGNED_VSX)
> > +  /* Do not generate lxvp and stxvp on power10 since there are some
> > +performance issues.  */
> > +  if (TARGET_MMA && TARGET_EFFICIENT_UNALIGNED_VSX
> > + && rs6000_tune != PROCESSOR_POWER10)
> > rs6000_isa_flags |= OPTION_MASK_BLOCK_OPS_VECTOR_PAIR;
> >else
> > rs6000_isa_flags &= ~OPTION_MASK_BLOCK_OPS_VECTOR_PAIR;
> 
> The TARGET_MMA in that should not be there.  Please fix that (that
> probably needs more changes).


All of the movoo and movxo support require TARGET_MMA as does the code in
rs6000-string.cc that could possibly generate load/store vector pair.  To
remove the check here would mean also fixing all of the vector load and store
pairs in mma.md.

> This statement does the opposite of what the comment says.
> 
> Please fix this.  On trunk, first.

-- 
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meiss...@linux.ibm.com

Re: [PATCH] libcpp: Improve encapsulation of label_text

[David Malcolm via Gcc-patches]

On Thu, 2022-07-14 at 22:10 +0100, Jonathan Wakely wrote:

Thanks for the patch.

> I'm not sure if label_text::get () is the best name for the new
> accessor. Other options include buffer () and c_str () but I don't
> see a
> compelling reason to prefer either of those.

label_text::get should return a const char *, rather than a char *.

I don't think anything uses label_text::is_owner; do we need that?

> 
> As a follow-up patch we could change label_text::m_buffer (and
> pod_label_text::m_buffer) to be const char*, since those labels are
> never modified once a label_text takes ownership of it. That would
> make it clear to callers that they are not supposed to modify the
> contents, and would remove the const_cast currently used by
> label_text::borrow (), which is a code smell (returning a non-const
> char* makes it look like it's OK to write into it, which is
> definitely
> not true for a borrowed string that was originally a string literal).
> That would require using const_cast when passing the buffer to free
> for
> deallocation, but that's fine, and avoids the impression that the
> object
> holds a modifiable string buffer.

I'm not sure I agree with your reasoning about the proposed follow-up,
but the patch below is OK for trunk, with the above nits fixed.

Thanks
Dave

> 
> Tested x86_64-linux, OK for trunk?
> 
> 
> -- >8 --
> 
> This adjusts the API of label_text so that the data members are
> private
> and cannot be modified by callers.  Add accessors for them instead.
> Also rename moved_from () to the more idiomatic release ().  Also
> remove
> the unused take_or_copy () member function which has confusing
> ownership
> semantics.
> 
> gcc/analyzer/ChangeLog:
> 
> * call-info.cc (call_info::print): Adjust to new label_text
> API.
> * checker-path.cc (checker_event::dump): Likewise.
> (region_creation_event::get_desc): Likewise.
> (state_change_event::get_desc): Likewise.
> (superedge_event::should_filter_p): Likewise.
> (start_cfg_edge_event::get_desc): Likewise.
> (call_event::get_desc): Likewise.
> (return_event::get_desc): Likewise.
> (warning_event::get_desc): Likewise.
> (checker_path::dump): Likewise.
> (checker_path::debug): Likewise.
> * diagnostic-manager.cc
> (diagnostic_manager::prune_for_sm_diagnostic):
> Likewise.
> (diagnostic_manager::prune_interproc_events): Likewise.
> * engine.cc (feasibility_state::maybe_update_for_edge):
> Likewise.
> * program-state.cc (sm_state_map::to_json): Likewise.
> * region-model-impl-calls.cc
> (region_model::impl_call_analyzer_describe): Likewise.
> (region_model::impl_call_analyzer_dump_capacity): Likewise.
> * region.cc (region::to_json): Likewise.
> * sm-malloc.cc (inform_nonnull_attribute): Likewise.
> * store.cc (binding_map::to_json): Likewise.
> (store::to_json): Likewise.
> * supergraph.cc (superedge::dump): Likewise.
> * svalue.cc (svalue::to_json): Likewise.
> 
> gcc/c-family/ChangeLog:
> 
> * c-format.cc (class range_label_for_format_type_mismatch):
> Adjust to new label_text API.
> 
> gcc/ChangeLog:
> 
> * diagnostic-format-json.cc (json_from_location_range):
> Adjust
> to new label_text API.
> * diagnostic-format-sarif.cc
> (sarif_builder::make_location_object):
> Likewise.
> * diagnostic-show-locus.cc (struct pod_label_text): Likewise.
> (layout::print_any_labels): Likewise.
> * tree-diagnostic-path.cc (class path_label): Likewise.
> (struct event_range): Likewise.
> (default_tree_diagnostic_path_printer): Likewise.
> (default_tree_make_json_for_path): Likewise.
> 
> libcpp/ChangeLog:
> 
> * include/line-map.h (label_text::take_or_copy): Remove.
> (label_text::moved_from): Rename to release.
> (label_text::m_buffer, label_text::m_owned): Make private.
> (label_text::get, label_text::is_owned): New accessors.
> ---
>  gcc/analyzer/call-info.cc   |  2 +-
>  gcc/analyzer/checker-path.cc    | 46 ---
> --
>  gcc/analyzer/diagnostic-manager.cc  | 20 +--
>  gcc/analyzer/engine.cc  |  2 +-
>  gcc/analyzer/program-state.cc   |  2 +-
>  gcc/analyzer/region-model-impl-calls.cc |  4 +--
>  gcc/analyzer/region.cc  |  2 +-
>  gcc/analyzer/sm-malloc.cc   | 10 +++---
>  gcc/analyzer/store.cc   |  6 ++--
>  gcc/analyzer/supergraph.cc  |  4 +--
>  gcc/analyzer/svalue.cc  |  2 +-
>  gcc/c-family/c-format.cc    |  4 +--
>  gcc/diagnostic-format-json.cc   |  4 +--
>  gcc/diagnostic-format-sarif.cc  |  2 +-
>  gcc/diagnostic-show-locus.cc    |  6 ++--
>  gcc/tree-diagnostic-path.cc | 16 -
>  libcpp/include/line-map.h 

[Bug libstdc++/106308] New: Consider using statx(2) for std::filesystem

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

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

Bug ID: 106308
   Summary: Consider using statx(2) for std::filesystem
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---
Target: *-*-linux*

We don't need all the info that stat(2) provides.


Whenever we want to create a filesystem::file_status we only need st_mode. This
would speed up many operations that use filesystem::file_status or
filesystem::file_type.

filesystem::file_size only uses st_mode and st_size

filesystem::read_symlink only uses st_mode and st_size

filesystem::copy and filesystem::copy_file only use st_mode, st_dev, st_ino,
and st_size.

filesystem::equivalent only uses st_mode, st_dev, st_ino.

filesystem::last_write_time only uses st_mtim.


We never care about atim, ctim, uid, nlink, rdev, blocks, or blksize (although
maybe we should use blksize for filesystem::copy_file). Fetching those fields
for files on remote filesystems is wasteful.

Re: [GCC 12 backport] Disable generating load/store vector pairs for block copies.

[Segher Boessenkool]

On Thu, Jul 14, 2022 at 11:20:56AM -0400, Michael Meissner wrote:
> I have applied the patch to GCC 12.
> 
> | From 22736f3d0d4fb8ce4afb3230023f8accdb03a623 Mon Sep 17 00:00:00 2001
> | From: Michael Meissner 
> | Date: Thu, 14 Jul 2022 11:16:08 -0400
> | Subject: [PATCH] [BACKPORT] Disable generating load/store vector pairs for 
> block copies.
> 
> Testing has found that using load and store vector pair for block copies
> can result in a slow down on power10.  This patch disables using the
> vector pair instructions for block copies if we are tuning for power10.
> 
> 2022-06-11   Michael Meissner  
> 
> gcc/
> 
>   * config/rs6000/rs6000.cc (rs6000_option_override_internal): Do
>   not generate block copies with vector pair instructions if we are
>   tuning for power10.  Back port from master branch.

You never posted the trunk version of this, so that never was approved
either.

> +++ b/gcc/config/rs6000/rs6000.cc
> @@ -4151,7 +4151,10 @@ rs6000_option_override_internal (bool global_init_p)
>  
>if (!(rs6000_isa_flags_explicit & OPTION_MASK_BLOCK_OPS_VECTOR_PAIR))
>  {
> -  if (TARGET_MMA && TARGET_EFFICIENT_UNALIGNED_VSX)
> +  /* Do not generate lxvp and stxvp on power10 since there are some
> +  performance issues.  */
> +  if (TARGET_MMA && TARGET_EFFICIENT_UNALIGNED_VSX
> +   && rs6000_tune != PROCESSOR_POWER10)
>   rs6000_isa_flags |= OPTION_MASK_BLOCK_OPS_VECTOR_PAIR;
>else
>   rs6000_isa_flags &= ~OPTION_MASK_BLOCK_OPS_VECTOR_PAIR;

The TARGET_MMA in that should not be there.  Please fix that (that
probably needs more changes).

This statement does the opposite of what the comment says.

Please fix this.  On trunk, first.


Segher

[Bug tree-optimization/103798] memchr with a (small) constant string should be expanded inline.

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by H.J. Lu :

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

commit r13-1699-gc6cf555a88f8ffb8ec85c2b94fe656ab217260ea
Author: H.J. Lu 
Date:   Fri Jun 17 07:33:06 2022 -0700

Simplify memchr with small constant strings

When memchr is applied on a constant string of no more than the bytes of
a word, simplify memchr by checking each byte in the constant string.

int f (int a)
{
   return  __builtin_memchr ("AE", a, 2) != 0;
}

is simplified to

int f (int a)
{
  return ((char) a == 'A' || (char) a == 'E') != 0;
}

gcc/

PR tree-optimization/103798
* tree-ssa-forwprop.cc: Include "tree-ssa-strlen.h".
(simplify_builtin_call): Inline memchr with constant strings of
no more than the bytes of a word.
* tree-ssa-strlen.cc (use_in_zero_equality): Make it global.
* tree-ssa-strlen.h (use_in_zero_equality): New.

gcc/testsuite/

PR tree-optimization/103798
* c-c++-common/pr103798-1.c: New test.
* c-c++-common/pr103798-2.c: Likewise.
* c-c++-common/pr103798-3.c: Likewise.
* c-c++-common/pr103798-4.c: Likewise.
* c-c++-common/pr103798-5.c: Likewise.
* c-c++-common/pr103798-6.c: Likewise.
* c-c++-common/pr103798-7.c: Likewise.
* c-c++-common/pr103798-8.c: Likewise.
* c-c++-common/pr103798-9.c: Likewise.
* c-c++-common/pr103798-10.c: Likewise.

[PATCH] libcpp: Improve encapsulation of label_text

[Jonathan Wakely via Gcc-patches]

I'm not sure if label_text::get () is the best name for the new
accessor. Other options include buffer () and c_str () but I don't see a
compelling reason to prefer either of those.

As a follow-up patch we could change label_text::m_buffer (and
pod_label_text::m_buffer) to be const char*, since those labels are
never modified once a label_text takes ownership of it. That would
make it clear to callers that they are not supposed to modify the
contents, and would remove the const_cast currently used by
label_text::borrow (), which is a code smell (returning a non-const
char* makes it look like it's OK to write into it, which is definitely
not true for a borrowed string that was originally a string literal).
That would require using const_cast when passing the buffer to free for
deallocation, but that's fine, and avoids the impression that the object
holds a modifiable string buffer.

Tested x86_64-linux, OK for trunk?


-- >8 --

This adjusts the API of label_text so that the data members are private
and cannot be modified by callers.  Add accessors for them instead.
Also rename moved_from () to the more idiomatic release ().  Also remove
the unused take_or_copy () member function which has confusing ownership
semantics.

gcc/analyzer/ChangeLog:

* call-info.cc (call_info::print): Adjust to new label_text API.
* checker-path.cc (checker_event::dump): Likewise.
(region_creation_event::get_desc): Likewise.
(state_change_event::get_desc): Likewise.
(superedge_event::should_filter_p): Likewise.
(start_cfg_edge_event::get_desc): Likewise.
(call_event::get_desc): Likewise.
(return_event::get_desc): Likewise.
(warning_event::get_desc): Likewise.
(checker_path::dump): Likewise.
(checker_path::debug): Likewise.
* diagnostic-manager.cc (diagnostic_manager::prune_for_sm_diagnostic):
Likewise.
(diagnostic_manager::prune_interproc_events): Likewise.
* engine.cc (feasibility_state::maybe_update_for_edge):
Likewise.
* program-state.cc (sm_state_map::to_json): Likewise.
* region-model-impl-calls.cc 
(region_model::impl_call_analyzer_describe): Likewise.
(region_model::impl_call_analyzer_dump_capacity): Likewise.
* region.cc (region::to_json): Likewise.
* sm-malloc.cc (inform_nonnull_attribute): Likewise.
* store.cc (binding_map::to_json): Likewise.
(store::to_json): Likewise.
* supergraph.cc (superedge::dump): Likewise.
* svalue.cc (svalue::to_json): Likewise.

gcc/c-family/ChangeLog:

* c-format.cc (class range_label_for_format_type_mismatch):
Adjust to new label_text API.

gcc/ChangeLog:

* diagnostic-format-json.cc (json_from_location_range): Adjust
to new label_text API.
* diagnostic-format-sarif.cc (sarif_builder::make_location_object):
Likewise.
* diagnostic-show-locus.cc (struct pod_label_text): Likewise.
(layout::print_any_labels): Likewise.
* tree-diagnostic-path.cc (class path_label): Likewise.
(struct event_range): Likewise.
(default_tree_diagnostic_path_printer): Likewise.
(default_tree_make_json_for_path): Likewise.

libcpp/ChangeLog:

* include/line-map.h (label_text::take_or_copy): Remove.
(label_text::moved_from): Rename to release.
(label_text::m_buffer, label_text::m_owned): Make private.
(label_text::get, label_text::is_owned): New accessors.
---
 gcc/analyzer/call-info.cc   |  2 +-
 gcc/analyzer/checker-path.cc| 46 -
 gcc/analyzer/diagnostic-manager.cc  | 20 +--
 gcc/analyzer/engine.cc  |  2 +-
 gcc/analyzer/program-state.cc   |  2 +-
 gcc/analyzer/region-model-impl-calls.cc |  4 +--
 gcc/analyzer/region.cc  |  2 +-
 gcc/analyzer/sm-malloc.cc   | 10 +++---
 gcc/analyzer/store.cc   |  6 ++--
 gcc/analyzer/supergraph.cc  |  4 +--
 gcc/analyzer/svalue.cc  |  2 +-
 gcc/c-family/c-format.cc|  4 +--
 gcc/diagnostic-format-json.cc   |  4 +--
 gcc/diagnostic-format-sarif.cc  |  2 +-
 gcc/diagnostic-show-locus.cc|  6 ++--
 gcc/tree-diagnostic-path.cc | 16 -
 libcpp/include/line-map.h   | 27 ---
 17 files changed, 80 insertions(+), 79 deletions(-)

diff --git a/gcc/analyzer/call-info.cc b/gcc/analyzer/call-info.cc
index e1142d743a3..efc070b8bed 100644
--- a/gcc/analyzer/call-info.cc
+++ b/gcc/analyzer/call-info.cc
@@ -75,7 +75,7 @@ void
 call_info::print (pretty_printer *pp) const
 {
   label_text desc (get_desc (pp_show_color (pp)));
-  pp_string (pp, desc.m_buffer);
+  pp_string (pp, desc.get ());
 }
 
 /* Implementation of custom_edge_info::add_events_to_path vfunc for
diff --git a/gcc/analyzer/checker-path.cc b/gcc/analyzer/checker-path.cc
index 

Re: [PATCH v3] Simplify memchr with small constant strings

[H.J. Lu via Gcc-patches]

On Wed, Jul 13, 2022 at 11:42 PM Richard Biener
 wrote:
>
> On Wed, Jul 13, 2022 at 6:50 PM H.J. Lu  wrote:
> >
> > When memchr is applied on a constant string of no more than the bytes of
> > a word, simplify memchr by checking each byte in the constant string.
> >
> > int f (int a)
> > {
> >return  __builtin_memchr ("AE", a, 2) != 0;
> > }
> >
> > is simplified to
> >
> > int f (int a)
> > {
> >   return ((char) a == 'A' || (char) a == 'E') != 0;
> > }
> >
> > gcc/
> >
> > PR tree-optimization/103798
> > * tree-ssa-forwprop.cc: Include "tree-ssa-strlen.h".
> > (simplify_builtin_call): Inline memchr with constant strings of
> > no more than the bytes of a word.
> > * tree-ssa-strlen.cc (use_in_zero_equality): Make it global.
> > * tree-ssa-strlen.h (use_in_zero_equality): New.
> >
> > gcc/testsuite/
> >
> > PR tree-optimization/103798
> > * c-c++-common/pr103798-1.c: New test.
> > * c-c++-common/pr103798-2.c: Likewise.
> > * c-c++-common/pr103798-3.c: Likewise.
> > * c-c++-common/pr103798-4.c: Likewise.
> > * c-c++-common/pr103798-5.c: Likewise.
> > * c-c++-common/pr103798-6.c: Likewise.
> > * c-c++-common/pr103798-7.c: Likewise.
> > * c-c++-common/pr103798-8.c: Likewise.
> > * c-c++-common/pr103798-9.c: Likewise.
> > * c-c++-common/pr103798-10.c: Likewise.
> > ---
> >  gcc/testsuite/c-c++-common/pr103798-1.c  | 28 +
> >  gcc/testsuite/c-c++-common/pr103798-10.c | 10 
> >  gcc/testsuite/c-c++-common/pr103798-2.c  | 30 ++
> >  gcc/testsuite/c-c++-common/pr103798-3.c  | 28 +
> >  gcc/testsuite/c-c++-common/pr103798-4.c  | 28 +
> >  gcc/testsuite/c-c++-common/pr103798-5.c  | 26 +
> >  gcc/testsuite/c-c++-common/pr103798-6.c  | 27 +
> >  gcc/testsuite/c-c++-common/pr103798-7.c  | 27 +
> >  gcc/testsuite/c-c++-common/pr103798-8.c  | 27 +
> >  gcc/testsuite/c-c++-common/pr103798-9.c  | 10 
> >  gcc/tree-ssa-forwprop.cc | 73 
> >  gcc/tree-ssa-strlen.cc   |  4 +-
> >  gcc/tree-ssa-strlen.h|  2 +
> >  13 files changed, 318 insertions(+), 2 deletions(-)
> >  create mode 100644 gcc/testsuite/c-c++-common/pr103798-1.c
> >  create mode 100644 gcc/testsuite/c-c++-common/pr103798-10.c
> >  create mode 100644 gcc/testsuite/c-c++-common/pr103798-2.c
> >  create mode 100644 gcc/testsuite/c-c++-common/pr103798-3.c
> >  create mode 100644 gcc/testsuite/c-c++-common/pr103798-4.c
> >  create mode 100644 gcc/testsuite/c-c++-common/pr103798-5.c
> >  create mode 100644 gcc/testsuite/c-c++-common/pr103798-6.c
> >  create mode 100644 gcc/testsuite/c-c++-common/pr103798-7.c
> >  create mode 100644 gcc/testsuite/c-c++-common/pr103798-8.c
> >  create mode 100644 gcc/testsuite/c-c++-common/pr103798-9.c
> >
> > diff --git a/gcc/testsuite/c-c++-common/pr103798-1.c 
> > b/gcc/testsuite/c-c++-common/pr103798-1.c
> > new file mode 100644
> > index 000..cd3edf569fc
> > --- /dev/null
> > +++ b/gcc/testsuite/c-c++-common/pr103798-1.c
> > @@ -0,0 +1,28 @@
> > +/* { dg-do run } */
> > +/* { dg-options "-O2 -fdump-tree-optimized -save-temps" } */
> > +
> > +__attribute__ ((weak))
> > +int
> > +f (char a)
> > +{
> > +   return  __builtin_memchr ("a", a, 1) == 0;
> > +}
> > +
> > +__attribute__ ((weak))
> > +int
> > +g (char a)
> > +{
> > +  return a != 'a';
> > +}
> > +
> > +int
> > +main ()
> > +{
> > + for (int i = 0; i < 255; i++)
> > +   if (f (i) != g (i))
> > + __builtin_abort ();
> > +
> > + return 0;
> > +}
> > +
> > +/* { dg-final { scan-assembler-not "memchr" } } */
> > diff --git a/gcc/testsuite/c-c++-common/pr103798-10.c 
> > b/gcc/testsuite/c-c++-common/pr103798-10.c
> > new file mode 100644
> > index 000..4677e9539fa
> > --- /dev/null
> > +++ b/gcc/testsuite/c-c++-common/pr103798-10.c
> > @@ -0,0 +1,10 @@
> > +/* { dg-do compile } */
> > +/* { dg-options "-Os -fdump-tree-optimized -save-temps" } */
> > +
> > +int
> > +f (char a)
> > +{
> > +  return  __builtin_memchr ("ac", a, 1) == 0;
> > +}
> > +
> > +/* { dg-final { scan-assembler "memchr" } } */
> > diff --git a/gcc/testsuite/c-c++-common/pr103798-2.c 
> > b/gcc/testsuite/c-c++-common/pr103798-2.c
> > new file mode 100644
> > index 000..e7e99c3679e
> > --- /dev/null
> > +++ b/gcc/testsuite/c-c++-common/pr103798-2.c
> > @@ -0,0 +1,30 @@
> > +/* { dg-do run } */
> > +/* { dg-options "-O2 -fdump-tree-optimized -save-temps" } */
> > +
> > +#include 
> > +
> > +__attribute__ ((weak))
> > +int
> > +f (int a)
> > +{
> > +   return memchr ("aE", a, 2) != NULL;
> > +}
> > +
> > +__attribute__ ((weak))
> > +int
> > +g (char a)
> > +{
> > +  return a == 'a' || a == 'E';
> > +}
> > +
> > +int
> > +main ()
> > +{
> > + for (int i = 0; i < 255; i++)
> > +   if (f (i + 256) != g (i + 256))
> > + __builtin_abort ();
> > +
> > + return 0;
> > +}
> > +
> > +/* { dg-final { 

[Bug analyzer/106284] False positives from -Wanalyzer-tainted-array-index with optimized conditionals

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

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

David Malcolm  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2022-07-14

--- Comment #1 from David Malcolm  ---
I'm testing a fix for this.

Re: [PATCH] Revert "[PATCH] RISC-V: Use new linker emulations for glibc ABI."

[Fangrui Song via Gcc-patches]

On 2022-07-14, Palmer Dabbelt wrote:

On Mon, 20 Jun 2022 20:48:50 PDT (-0700), gcc-patches@gcc.gnu.org wrote:

On Mon, Jun 20, 2022 at 1:21 AM Kito Cheng  wrote:


Generally I agree we should fix that by GCC driver rather than ld
emulation, but I think this should be reverted with the -L path fix,
otherwise that will break multilib on GNU toolchain for linux
immediately?


IIUC just changing this will break even non-multlib systems, though 
it's possible that the symlinks work around that sufficiently.



Thanks for the good consideration. That said, I am unsure any distro
uses this currently.
I think some just work around the possibly non-existent paths by
creating symlinks.
Perhaps we should prioritize on fixing the scheme before distros start
to rely on the behavior.


I'm kind of torn on this one: this has been around for a while and 
dropping it would be an ABI break, but the feedback from distro folks 
is pretty consistently that multlib is broken on RISC-V.  If it's 
really unusably broken then I could buy the argument that there's no 
binaries (and thus no ABI to break), but there's at some base multilib 
functionality working -- I build multilib cross toolchains regularly, 
for example, and they can build simple stuff.


I always find making that "nobody's used it" argument really hard, 
there's just too many users to try and track everyone down.  We're in 
kind of a weird spot with RISC-V in general when it comes to ABI 
stuff: we were probably a bit overly optimistic about how fast any of 
this was going to get used when we committed to the ABI freeze, but 
any ABi break has such a huge potential for user headaches that I'm 
not sure it's going to be possible.  It means we're stuck with some 
baggage, and while it's a headache to keep around stuff that's 
probably not all that useful I think it's just what we've got to live 
with.


If multlib really is so broken it's not fixable without an ABI break 
then I guess there's no other option, but I think in this case we have 
some:


One option would be to add an ld argument that says to turn off the 
emulation-specific path resolution, which we could then add to 
LINK_SPEC when we get the library paths sorted out?  We'd still have 
the emulations and the subdirs, but at least we wouldn't need a flag 
day.


Another option would be to add new multlib paths that don't have the 
subdirectories, as last I checked that was an issue for distros 
(violates FHS, breaks build systems, etc).  If we're going to do that 
anyway then we could piggyback the new behavior on it and deprecate 
the old paths along with whatever behavior is associated with them.


Thanks for chiming in and providing the good consideration.  I don't do
much GNU development.  I just spotted something and think it should be
fixed.  If dropping -L is considered a risk, an alternative scheme is
that someone:

* create an alternative patch making GCC driver pass the -L to ld and use the 
plain emulation name.
* a configure option can possibly be added to guard whether the -L is added at 
all
* drop the excessive emulations in GNU ld.

This way an alternative linker implementation doesn't have to add a
compatibility no-op option.

I appreciate anyone who wants to step up and helps removing
eelf64lriscv_{lp64,ilp32f,...}. We will have "*64briscv*" variants and
it will then look really ugly.


On Wed, Jun 15, 2022 at 4:00 PM Fangrui Song via Gcc-patches
 wrote:


This reverts commit 37d57ac9a636f2235f9060e84fb8dd7968abd1dc.

The resolution to https://sourceware.org/bugzilla/show_bug.cgi?id=22962
let GCC pass -m emulation to ld and let the ld emulation configure
default library paths.  This scheme is problematic:

* It's not ld's business to specify default -L.  Different platforms have
different opinions on the hierarchy and all other arches work well without ld's
default -L.
* If some ABI derived library paths are desired, the compiler driver is in a
better position to make the decision and traditionally has done this.
* -m emulation is opaque to the compiler driver.  It doesn't affect -B, so
data files like crt*.o, libasan_preinit.o, and libtsan_preinit.o are not 
affected.

As is, many platforms just use symlinks to fake the lib64/{ilp32{,f},lp64{,f}}
hierarchies needed by the GNU ld emulation.  They can always specify -L
explicitly if they want some ABI derived library paths.  See also the rejected
https://reviews.llvm.org/D95755


I don't do a lot of LLVM stuff, but that has a green check mark that 
says "accepted" at the top.  Does that mean it was merged somewhere, 
or just that it was acked/reviewed and then dropped?


I could land it, but I realized that would be a mistake so I stopped.
There has since been no real need for this feature, either.  I wished
that some RISC-V folks stepped up and fixed it.  It took so long so I
ended up sending this patch myself, but I have no bandwidth to change this
patch to a form providing better compatibility



gcc/Changelog:

* 

Re: [PATCH] Revert "[PATCH] RISC-V: Use new linker emulations for glibc ABI."

[Palmer Dabbelt]

On Mon, 20 Jun 2022 20:48:50 PDT (-0700), gcc-patches@gcc.gnu.org wrote:

On Mon, Jun 20, 2022 at 1:21 AM Kito Cheng  wrote:


Generally I agree we should fix that by GCC driver rather than ld
emulation, but I think this should be reverted with the -L path fix,
otherwise that will break multilib on GNU toolchain for linux
immediately?


IIUC just changing this will break even non-multlib systems, though it's 
possible that the symlinks work around that sufficiently.



Thanks for the good consideration. That said, I am unsure any distro
uses this currently.
I think some just work around the possibly non-existent paths by
creating symlinks.
Perhaps we should prioritize on fixing the scheme before distros start
to rely on the behavior.


I'm kind of torn on this one: this has been around for a while and 
dropping it would be an ABI break, but the feedback from distro folks is 
pretty consistently that multlib is broken on RISC-V.  If it's really 
unusably broken then I could buy the argument that there's no binaries 
(and thus no ABI to break), but there's at some base multilib 
functionality working -- I build multilib cross toolchains regularly, 
for example, and they can build simple stuff.


I always find making that "nobody's used it" argument really hard, 
there's just too many users to try and track everyone down.  We're in 
kind of a weird spot with RISC-V in general when it comes to ABI stuff: 
we were probably a bit overly optimistic about how fast any of this was 
going to get used when we committed to the ABI freeze, but any ABi break 
has such a huge potential for user headaches that I'm not sure it's 
going to be possible.  It means we're stuck with some baggage, and while 
it's a headache to keep around stuff that's probably not all that useful 
I think it's just what we've got to live with.


If multlib really is so broken it's not fixable without an ABI break 
then I guess there's no other option, but I think in this case we have 
some:


One option would be to add an ld argument that says to turn off the 
emulation-specific path resolution, which we could then add to LINK_SPEC 
when we get the library paths sorted out?  We'd still have the 
emulations and the subdirs, but at least we wouldn't need a flag day.


Another option would be to add new multlib paths that don't have the 
subdirectories, as last I checked that was an issue for distros 
(violates FHS, breaks build systems, etc).  If we're going to do that 
anyway then we could piggyback the new behavior on it and deprecate the old 
paths along with whatever behavior is associated with them.



On Wed, Jun 15, 2022 at 4:00 PM Fangrui Song via Gcc-patches
 wrote:
>
> This reverts commit 37d57ac9a636f2235f9060e84fb8dd7968abd1dc.
>
> The resolution to https://sourceware.org/bugzilla/show_bug.cgi?id=22962
> let GCC pass -m emulation to ld and let the ld emulation configure
> default library paths.  This scheme is problematic:
>
> * It's not ld's business to specify default -L.  Different platforms have
> different opinions on the hierarchy and all other arches work well without 
ld's
> default -L.
> * If some ABI derived library paths are desired, the compiler driver is in a
> better position to make the decision and traditionally has done this.
> * -m emulation is opaque to the compiler driver.  It doesn't affect -B, so
> data files like crt*.o, libasan_preinit.o, and libtsan_preinit.o are not 
affected.
>
> As is, many platforms just use symlinks to fake the lib64/{ilp32{,f},lp64{,f}}
> hierarchies needed by the GNU ld emulation.  They can always specify -L
> explicitly if they want some ABI derived library paths.  See also the rejected
> https://reviews.llvm.org/D95755


I don't do a lot of LLVM stuff, but that has a green check mark that 
says "accepted" at the top.  Does that mean it was merged somewhere, or 
just that it was acked/reviewed and then dropped?



>
> gcc/Changelog:
>
> * config/riscv/linux.h (LD_EMUL_SUFFIX): Remove.
> (LINK_SPEC): Remove LD_EMUL_SUFFIX.
> ---
>  gcc/config/riscv/linux.h | 10 +-
>  1 file changed, 1 insertion(+), 9 deletions(-)
>
> diff --git a/gcc/config/riscv/linux.h b/gcc/config/riscv/linux.h
> index 38803723ba9..e0ff6e6a178 100644
> --- a/gcc/config/riscv/linux.h
> +++ b/gcc/config/riscv/linux.h
> @@ -49,16 +49,8 @@ along with GCC; see the file COPYING3.  If not see
>
>  #define CPP_SPEC "%{pthread:-D_REENTRANT}"
>
> -#define LD_EMUL_SUFFIX \
> -  "%{mabi=lp64d:}" \
> -  "%{mabi=lp64f:_lp64f}" \
> -  "%{mabi=lp64:_lp64}" \
> -  "%{mabi=ilp32d:}" \
> -  "%{mabi=ilp32f:_ilp32f}" \
> -  "%{mabi=ilp32:_ilp32}"
> -
>  #define LINK_SPEC "\
> --melf" XLEN_SPEC DEFAULT_ENDIAN_SPEC "riscv" LD_EMUL_SUFFIX " \
> +-melf" XLEN_SPEC DEFAULT_ENDIAN_SPEC "riscv \
>  %{mno-relax:--no-relax} \
>  %{mbig-endian:-EB} \
>  %{mlittle-endian:-EL} \
> --
> 2.36.1.476.g0c4daa206d-goog
>




--
宋方睿

[Bug fortran/106209] ICE in add_init_expr_to_sym, at fortran/decl.cc:2132

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from anlauf at gcc dot gnu.org ---
Fixed for gcc-13.

Thanks for the report!

[PATCH, committed] Fortran: error recovery for bad initializers of implied-shape arrays [PR106209]

[Harald Anlauf via Gcc-patches]

Dear all,

the attached patch introduces error recovery for two cases of using
an invalid array in a declaration of an implied-shape array instead
of hitting internal errors.

Initial patch by Steve.  The final version was approved in the PR
by Steve.

Committed as:

https://gcc.gnu.org/g:748f8a8b145dde59c7b63aa68b5a59515b7efc49

Thanks,
Harald

From 748f8a8b145dde59c7b63aa68b5a59515b7efc49 Mon Sep 17 00:00:00 2001
From: Harald Anlauf 
Date: Thu, 14 Jul 2022 22:24:55 +0200
Subject: [PATCH] Fortran: error recovery for bad initializers of implied-shape
 arrays [PR106209]

gcc/fortran/ChangeLog:

	PR fortran/106209
	* decl.cc (add_init_expr_to_sym): Handle bad initializers for
	implied-shape arrays.

gcc/testsuite/ChangeLog:

	PR fortran/106209
	* gfortran.dg/pr106209.f90: New test.

Co-authored-by: Steven G. Kargl 
---
 gcc/fortran/decl.cc| 15 +--
 gcc/testsuite/gfortran.dg/pr106209.f90 |  9 +
 2 files changed, 22 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/gfortran.dg/pr106209.f90

diff --git a/gcc/fortran/decl.cc b/gcc/fortran/decl.cc
index 339f8b15035..b6400514731 100644
--- a/gcc/fortran/decl.cc
+++ b/gcc/fortran/decl.cc
@@ -2129,10 +2129,21 @@ add_init_expr_to_sym (const char *name, gfc_expr **initp, locus *var_locus)
 	  /* The shape may be NULL for EXPR_ARRAY, set it.  */
 	  if (init->shape == NULL)
 	{
-	  gcc_assert (init->expr_type == EXPR_ARRAY);
+	  if (init->expr_type != EXPR_ARRAY)
+		{
+		  gfc_error ("Bad shape of initializer at %L", >where);
+		  return false;
+		}
+
 	  init->shape = gfc_get_shape (1);
 	  if (!gfc_array_size (init, >shape[0]))
-		  gfc_internal_error ("gfc_array_size failed");
+		{
+		  gfc_error ("Cannot determine shape of initializer at %L",
+			 >where);
+		  free (init->shape);
+		  init->shape = NULL;
+		  return false;
+		}
 	}

 	  for (dim = 0; dim < sym->as->rank; ++dim)
diff --git a/gcc/testsuite/gfortran.dg/pr106209.f90 b/gcc/testsuite/gfortran.dg/pr106209.f90
new file mode 100644
index 000..44f9233ec2f
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr106209.f90
@@ -0,0 +1,9 @@
+! { dg-do compile }
+! PR fortran/106209 - ICE in add_init_expr_to_sym
+! Contributed by G.Steinmetz
+
+program p
+  integer, parameter :: a(:) = 0   ! { dg-error "of deferred shape" }
+  integer, parameter :: b(*) = a   ! { dg-error "Bad shape of initializer" }
+  integer, parameter :: c(*) = [a] ! { dg-error "Cannot determine shape" }
+end
--
2.35.3

[Bug fortran/106209] ICE in add_init_expr_to_sym, at fortran/decl.cc:2132

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

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

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

https://gcc.gnu.org/g:748f8a8b145dde59c7b63aa68b5a59515b7efc49

commit r13-1698-g748f8a8b145dde59c7b63aa68b5a59515b7efc49
Author: Harald Anlauf 
Date:   Thu Jul 14 22:24:55 2022 +0200

Fortran: error recovery for bad initializers of implied-shape arrays
[PR106209]

gcc/fortran/ChangeLog:

PR fortran/106209
* decl.cc (add_init_expr_to_sym): Handle bad initializers for
implied-shape arrays.

gcc/testsuite/ChangeLog:

PR fortran/106209
* gfortran.dg/pr106209.f90: New test.

Co-authored-by: Steven G. Kargl 

[Bug fortran/106209] ICE in add_init_expr_to_sym, at fortran/decl.cc:2132

[sgk at troutmask dot apl.washington.edu via Gcc-bugs]

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

--- Comment #3 from Steve Kargl  ---
On Thu, Jul 14, 2022 at 07:35:21PM +, anlauf at gcc dot gnu.org wrote:
> 
> --- Comment #2 from anlauf at gcc dot gnu.org ---
> (In reply to kargl from comment #1)
> > Instead of an assert(), simply return false to give gfortran a chance to
> > emit an error.
> 
> Steve, your patch does fix z1, but not z2, which hits the
> 
>   gfc_internal_error ("gfc_array_size failed");

Sorry about that.  Your patch looks good to me.

Re: [PATCH 2/3] tree-cfg: do not duplicate returns_twice calls

[Alexander Monakov via Gcc-patches]

On Thu, 14 Jul 2022, Richard Biener wrote:

> Indeed.  Guess that's what __builtin_setjmp[_receiver] for SJLJ_EH got 
> "right".
> 
> When copying a block we do not copy labels so any "jumps" remain to the 
> original
> block and thus we are indeed able to isolate normal control flow.  Given that
> returns_twice functions _do_ seem to be special, and also special as to how
> we handle other abnormal receivers in duplicate_block.

We do? Sorry, I don't see what you mean here, can you point me to specific 
lines?

> So it might indeed make sense to special-case them in can_duplicate_block_p
> ... (sorry for going back-and-forth ...)
> 
> Note that I think this detail of duplicate_block (the function) and the hook
> needs to be better documented (the semantics on incoming edges, not 
> duplicating
> labels used for incoming control flow).
> 
> Can you see as to how to adjust the RTL side for this?  It looks like at least
> some places set a REG_SETJMP note on call_insns (emit_call_1), I wonder
> if in rtl_verify_flow_info[_1] (or its callees) we can check that such
> calls come
> first ... they might not since IIRC we do _not_ preserve abnormal edges when
> expanding RTL (there's some existing bug about this and how this breaks some
> setjmp tests) (but we try to recompute them?).

No, we emit arguments/return value handling before/after a REG_SETJMP call,
and yeah, we don't always properly recompute abnormal edges, so improving
RTL in this respect seems hopeless. For example, it is easy enough to create
a testcase where bb-reordering duplicates a returns_twice call, although it
runs so late that perhaps later passes don't care:

// gcc -O2 --param=max-grow-copy-bb-insns=100
__attribute__((returns_twice))
int rtwice(int);
int g1(int), g2(int);
void f(int i)
{
  do {
i = i%2 ? g1(i) : g2(i);
  } while (i = rtwice(i));
}

FWIW, I also investigated https://gcc.gnu.org/PR101347

> Sorry about the back-and-forth again ... your original patch looks OK for the
> GIMPLE side but can you amend the cfghooks.{cc,h} documentation to
> summarize our findings and
> the desired semantics of duplicate_block in this respect?

Like below?

---8<---

Subject: [PATCH v3] tree-cfg: do not duplicate returns_twice calls

A returns_twice call may have associated abnormal edges that correspond
to the "second return" from the call. If the call is duplicated, the
copies of those edges also need to be abnormal, but e.g. tracer does not
enforce that. Just prohibit the (unlikely to be useful) duplication.

gcc/ChangeLog:

* cfghooks.cc (duplicate_block): Expand comment.
* tree-cfg.cc (gimple_can_duplicate_bb_p): Reject blocks with
calls that may return twice.
---
 gcc/cfghooks.cc | 13 ++---
 gcc/tree-cfg.cc |  7 +--
 2 files changed, 15 insertions(+), 5 deletions(-)

diff --git a/gcc/cfghooks.cc b/gcc/cfghooks.cc
index e435891fa..c6ac9532c 100644
--- a/gcc/cfghooks.cc
+++ b/gcc/cfghooks.cc
@@ -1086,9 +1086,16 @@ can_duplicate_block_p (const_basic_block bb)
   return cfg_hooks->can_duplicate_block_p (bb);
 }
 
-/* Duplicates basic block BB and redirects edge E to it.  Returns the
-   new basic block.  The new basic block is placed after the basic block
-   AFTER.  */
+/* Duplicate basic block BB, place it after AFTER (if non-null) and redirect
+   edge E to it (if non-null).  Return the new basic block.
+
+   If BB contains a returns_twice call, the caller is responsible for 
recreating
+   incoming abnormal edges corresponding to the "second return" for the copy.
+   gimple_can_duplicate_bb_p rejects such blocks, while RTL likes to live
+   dangerously.
+
+   If BB has incoming abnormal edges for some other reason, their destinations
+   should be tied to label(s) of the original BB and not the copy.  */
 
 basic_block
 duplicate_block (basic_block bb, edge e, basic_block after, copy_bb_data *id)
diff --git a/gcc/tree-cfg.cc b/gcc/tree-cfg.cc
index f846dc2d8..5bcf78198 100644
--- a/gcc/tree-cfg.cc
+++ b/gcc/tree-cfg.cc
@@ -6346,12 +6346,15 @@ gimple_can_duplicate_bb_p (const_basic_block bb)
 {
   gimple *g = gsi_stmt (gsi);
 
-  /* An IFN_GOMP_SIMT_ENTER_ALLOC/IFN_GOMP_SIMT_EXIT call must be
+  /* Prohibit duplication of returns_twice calls, otherwise associated
+abnormal edges also need to be duplicated properly.
+An IFN_GOMP_SIMT_ENTER_ALLOC/IFN_GOMP_SIMT_EXIT call must be
 duplicated as part of its group, or not at all.
 The IFN_GOMP_SIMT_VOTE_ANY and IFN_GOMP_SIMT_XCHG_* are part of such a
 group, so the same holds there.  */
   if (is_gimple_call (g)
- && (gimple_call_internal_p (g, IFN_GOMP_SIMT_ENTER_ALLOC)
+ && (gimple_call_flags (g) & ECF_RETURNS_TWICE
+ || gimple_call_internal_p (g, IFN_GOMP_SIMT_ENTER_ALLOC)
  || gimple_call_internal_p (g, IFN_GOMP_SIMT_EXIT)
  || gimple_call_internal_p (g, IFN_GOMP_SIMT_VOTE_ANY)
  || gimple_call_internal_p (g, 

[Bug target/100799] Stackoverflow in optimized code on PPC

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

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

Peter Bergner  changed:

   What|Removed |Added

   Assignee|bergner at gcc dot gnu.org |jskumari at gcc dot 
gnu.org

--- Comment #9 from Peter Bergner  ---
(In reply to Peter Bergner from comment #8)
> I'm sorry, this is still on my TODO to debug.  I have worked on this, but
> got side tracked on other things.  I'll try and refresh myself with where I
> was at and continue working this.

Actually, Surya from my team will take over looking at this.  Reassigning the
bug to her.

Re: [PATCH] match.pd: Add new abs pattern [PR94290]

[Andrew Pinski via Gcc-patches]

On Thu, Jul 14, 2022 at 12:38 PM Sam Feifer  wrote:
>
>
>
> On Thu, Jul 14, 2022 at 1:24 PM Andrew Pinski  wrote:
>>
>> On Thu, Jul 14, 2022 at 7:09 AM Sam Feifer  wrote:
>> >
>> >
>> > On Wed, Jul 13, 2022 at 3:36 PM Andrew Pinski  wrote:
>> >>
>> >> On Wed, Jul 13, 2022 at 12:26 PM Sam Feifer via Gcc-patches
>> >>  wrote:
>> >> >
>> >> > This patch is intended to fix a missed optimization in match.pd. It 
>> >> > optimizes (x >= 0 ? x : 0) + (x <= 0 ? -x : 0) to just abs(x). I had to 
>> >> > write a second simplification in match.pd to handle the commutative 
>> >> > property as the match was not ocurring otherwise. Additionally, the 
>> >> > pattern (x <= 0 ? -x : 0) now gets optimized to max(-x, 0), which helps 
>> >> > with the other simplification rule.
>> >>
>> >> You could use :c for the commutative property instead and that should
>> >> simplify things.
>> >> That is:
>> >>
>> >> (simplify
>> >>   (plus:c (max @0 integer_zerop) (max (negate @0) integer_zerop))
>> >>   (abs @0))
>> >>
>> >> Also since integer_zerop works on vectors, it seems like you should
>> >> add a testcase or two for the vector case.
>> >> Also would be useful if you write a testcase that uses different
>> >> statements rather than one big one so it gets exercised in the
>> >> forwprop case.
>> >> Note also if either of the max are used more than just in this
>> >> simplification, it could increase the lifetime of @0, maybe you need
>> >> to add :s to the max expressions.
>> >>
>> >
>> > Thanks for the feedback. I'm not quite sure what a vector test case would 
>> > look like for this. Could I get some guidance on that?
>>
>> Yes this should produce the pattern at forwprop1 time (with the C++
>> front-end, the C front-end does not support vector selects):
>> typedef int __attribute__((vector_size(4*sizeof(int vint;
>>
>> vint foo(vint x) {
>> vint t = (x >= 0 ? x : 0) ;
>> vint xx = -x;
>> vint t1 =  (xx >= 0 ? xx : 0);
>> return t + t1;
>> }
>>
>> int foo(int x) {
>> int t = (x >= 0 ? x : 0) ;
>> int xx = -x;
>> int t1 =  (xx >= 0 ? xx : 0);
>> return t + t1;
>> }
>>
>> Thanks,
>> Andrew Pinski
>>
>
> Thanks for the help. I'm still having trouble with the vector test, though. 
> When I try to compile, I get an error saying "used vector type where scalar 
> is required", referring to the max expressions. How do I use the max 
> expression with two vectors as the inputs?

As I mentioned it only works with the C++ front-end :). The C
front-end does not support ?: with vectors types.

Thanks,
Andrew Pinski

>
> Thanks
> -Sam
>>
>>
>> >
>> > Thanks
>> > -Sam
>> >
>> >>
>> >> Thanks,
>> >> Andrew
>> >>
>> >> >
>> >> > Tests are also included to be added to the testsuite.
>> >> >
>> >> > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
>> >> >
>> >> > PR tree-optimization/94290
>> >> >
>> >> > gcc/ChangeLog:
>> >> >
>> >> > * match.pd (x >= 0 ? x : 0) + (x <= 0 ? -x : 0): New 
>> >> > simplification.
>> >> > * match.pd (x <= 0 ? -x : 0): New Simplification.
>> >> >
>> >> > gcc/testsuite/ChangeLog:
>> >> >
>> >> > * gcc.c-torture/execute/pr94290-1.c: New test.
>> >> > * gcc.dg/pr94290-2.c: New test.
>> >> > * gcc.dg/pr94290.c: New test.
>> >> > ---
>> >> >  gcc/match.pd  | 15 ++
>> >> >  .../gcc.c-torture/execute/pr94290-1.c | 16 +++
>> >> >  gcc/testsuite/gcc.dg/pr94290-2.c  | 15 ++
>> >> >  gcc/testsuite/gcc.dg/pr94290.c| 46 +++
>> >> >  4 files changed, 92 insertions(+)
>> >> >  create mode 100644 gcc/testsuite/gcc.c-torture/execute/pr94290-1.c
>> >> >  create mode 100644 gcc/testsuite/gcc.dg/pr94290-2.c
>> >> >  create mode 100644 gcc/testsuite/gcc.dg/pr94290.c
>> >> >
>> >> > diff --git a/gcc/match.pd b/gcc/match.pd
>> >> > index 45aefd96688..55ca79d7ac9 100644
>> >> > --- a/gcc/match.pd
>> >> > +++ b/gcc/match.pd
>> >> > @@ -7848,3 +7848,18 @@ and,
>> >> >(if (TYPE_UNSIGNED (TREE_TYPE (@0)))
>> >> >  (bit_and @0 @1)
>> >> >(cond (le @0 @1) @0 (bit_and @0 @1))
>> >> > +
>> >> > +/* (x >= 0 ? x : 0) + (x <= 0 ? -x : 0) -> abs x.  */
>> >> > +(simplify
>> >> > +  (plus (max @0 integer_zerop) (max (negate @0) integer_zerop))
>> >> > +  (abs @0))
>> >> > +
>> >> > +/* (x <= 0 ? -x : 0) + (x >= 0 ? x : 0) -> abs x.  */
>> >> > +(simplify
>> >> > +  (plus (max (negate @0) integer_zerop) (max @0 integer_zerop) )
>> >> > +  (abs @0))
>> >> > +
>> >> > +/* (x <= 0 ? -x : 0) -> max(-x, 0).  */
>> >> > +(simplify
>> >> > + (cond (le @0 integer_zerop@1) (negate @0) integer_zerop@1)
>> >> > + (max (negate @0) @1))
>> >> > diff --git a/gcc/testsuite/gcc.c-torture/execute/pr94290-1.c 
>> >> > b/gcc/testsuite/gcc.c-torture/execute/pr94290-1.c
>> >> > new file mode 100644
>> >> > index 000..93b80d569aa
>> >> > --- /dev/null
>> >> > +++ b/gcc/testsuite/gcc.c-torture/execute/pr94290-1.c
>> >> > @@ -0,0 +1,16 @@
>> >> > 

Re: [PATCH] match.pd: Add new abs pattern [PR94290]

[Sam Feifer via Gcc-patches]

On Thu, Jul 14, 2022 at 1:24 PM Andrew Pinski  wrote:

> On Thu, Jul 14, 2022 at 7:09 AM Sam Feifer  wrote:
> >
> >
> > On Wed, Jul 13, 2022 at 3:36 PM Andrew Pinski  wrote:
> >>
> >> On Wed, Jul 13, 2022 at 12:26 PM Sam Feifer via Gcc-patches
> >>  wrote:
> >> >
> >> > This patch is intended to fix a missed optimization in match.pd. It
> optimizes (x >= 0 ? x : 0) + (x <= 0 ? -x : 0) to just abs(x). I had to
> write a second simplification in match.pd to handle the commutative
> property as the match was not ocurring otherwise. Additionally, the pattern
> (x <= 0 ? -x : 0) now gets optimized to max(-x, 0), which helps with the
> other simplification rule.
> >>
> >> You could use :c for the commutative property instead and that should
> >> simplify things.
> >> That is:
> >>
> >> (simplify
> >>   (plus:c (max @0 integer_zerop) (max (negate @0) integer_zerop))
> >>   (abs @0))
> >>
> >> Also since integer_zerop works on vectors, it seems like you should
> >> add a testcase or two for the vector case.
> >> Also would be useful if you write a testcase that uses different
> >> statements rather than one big one so it gets exercised in the
> >> forwprop case.
> >> Note also if either of the max are used more than just in this
> >> simplification, it could increase the lifetime of @0, maybe you need
> >> to add :s to the max expressions.
> >>
> >
> > Thanks for the feedback. I'm not quite sure what a vector test case
> would look like for this. Could I get some guidance on that?
>
> Yes this should produce the pattern at forwprop1 time (with the C++
> front-end, the C front-end does not support vector selects):
> typedef int __attribute__((vector_size(4*sizeof(int vint;
>
> vint foo(vint x) {
> vint t = (x >= 0 ? x : 0) ;
> vint xx = -x;
> vint t1 =  (xx >= 0 ? xx : 0);
> return t + t1;
> }
>
> int foo(int x) {
> int t = (x >= 0 ? x : 0) ;
> int xx = -x;
> int t1 =  (xx >= 0 ? xx : 0);
> return t + t1;
> }
>
> Thanks,
> Andrew Pinski
>
>
Thanks for the help. I'm still having trouble with the vector test, though.
When I try to compile, I get an error saying "used vector type where scalar
is required", referring to the max expressions. How do I use the max
expression with two vectors as the inputs?

Thanks
-Sam

>
> >
> > Thanks
> > -Sam
> >
> >>
> >> Thanks,
> >> Andrew
> >>
> >> >
> >> > Tests are also included to be added to the testsuite.
> >> >
> >> > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> >> >
> >> > PR tree-optimization/94290
> >> >
> >> > gcc/ChangeLog:
> >> >
> >> > * match.pd (x >= 0 ? x : 0) + (x <= 0 ? -x : 0): New
> simplification.
> >> > * match.pd (x <= 0 ? -x : 0): New Simplification.
> >> >
> >> > gcc/testsuite/ChangeLog:
> >> >
> >> > * gcc.c-torture/execute/pr94290-1.c: New test.
> >> > * gcc.dg/pr94290-2.c: New test.
> >> > * gcc.dg/pr94290.c: New test.
> >> > ---
> >> >  gcc/match.pd  | 15 ++
> >> >  .../gcc.c-torture/execute/pr94290-1.c | 16 +++
> >> >  gcc/testsuite/gcc.dg/pr94290-2.c  | 15 ++
> >> >  gcc/testsuite/gcc.dg/pr94290.c| 46
> +++
> >> >  4 files changed, 92 insertions(+)
> >> >  create mode 100644 gcc/testsuite/gcc.c-torture/execute/pr94290-1.c
> >> >  create mode 100644 gcc/testsuite/gcc.dg/pr94290-2.c
> >> >  create mode 100644 gcc/testsuite/gcc.dg/pr94290.c
> >> >
> >> > diff --git a/gcc/match.pd b/gcc/match.pd
> >> > index 45aefd96688..55ca79d7ac9 100644
> >> > --- a/gcc/match.pd
> >> > +++ b/gcc/match.pd
> >> > @@ -7848,3 +7848,18 @@ and,
> >> >(if (TYPE_UNSIGNED (TREE_TYPE (@0)))
> >> >  (bit_and @0 @1)
> >> >(cond (le @0 @1) @0 (bit_and @0 @1))
> >> > +
> >> > +/* (x >= 0 ? x : 0) + (x <= 0 ? -x : 0) -> abs x.  */
> >> > +(simplify
> >> > +  (plus (max @0 integer_zerop) (max (negate @0) integer_zerop))
> >> > +  (abs @0))
> >> > +
> >> > +/* (x <= 0 ? -x : 0) + (x >= 0 ? x : 0) -> abs x.  */
> >> > +(simplify
> >> > +  (plus (max (negate @0) integer_zerop) (max @0 integer_zerop) )
> >> > +  (abs @0))
> >> > +
> >> > +/* (x <= 0 ? -x : 0) -> max(-x, 0).  */
> >> > +(simplify
> >> > + (cond (le @0 integer_zerop@1) (negate @0) integer_zerop@1)
> >> > + (max (negate @0) @1))
> >> > diff --git a/gcc/testsuite/gcc.c-torture/execute/pr94290-1.c
> b/gcc/testsuite/gcc.c-torture/execute/pr94290-1.c
> >> > new file mode 100644
> >> > index 000..93b80d569aa
> >> > --- /dev/null
> >> > +++ b/gcc/testsuite/gcc.c-torture/execute/pr94290-1.c
> >> > @@ -0,0 +1,16 @@
> >> > +/* PR tree-optimization/94290 */
> >> > +
> >> > +#include "../../gcc.dg/pr94290.c"
> >> > +
> >> > +int main() {
> >> > +
> >> > +if (foo(0) != 0
> >> > +|| foo(-42) != 42
> >> > +|| foo(42) != 42
> >> > +|| baz(-10) != 10
> >> > +|| baz(-10) != 10) {
> >> > +__builtin_abort();
> >> > +}
> >> > +
> >> > +return 0;
> >> > +}

[Bug fortran/106209] ICE in add_init_expr_to_sym, at fortran/decl.cc:2132

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org

--- Comment #2 from anlauf at gcc dot gnu.org ---
(In reply to kargl from comment #1)
> Instead of an assert(), simply return false to give gfortran a chance to
> emit an error.

Steve, your patch does fix z1, but not z2, which hits the

  gfc_internal_error ("gfc_array_size failed");

a few lines later...

The following adjusted patch fixes the latter, too, regtests cleanly,
and gives nicer error messages :)

diff --git a/gcc/fortran/decl.cc b/gcc/fortran/decl.cc
index 339f8b15035..b6400514731 100644
--- a/gcc/fortran/decl.cc
+++ b/gcc/fortran/decl.cc
@@ -2129,10 +2129,21 @@ add_init_expr_to_sym (const char *name, gfc_expr
**initp, locus *var_
locus)
  /* The shape may be NULL for EXPR_ARRAY, set it.  */
  if (init->shape == NULL)
{
- gcc_assert (init->expr_type == EXPR_ARRAY);
+ if (init->expr_type != EXPR_ARRAY)
+   {
+ gfc_error ("Bad shape of initializer at %L", >where);
+ return false;
+   }
+
  init->shape = gfc_get_shape (1);
  if (!gfc_array_size (init, >shape[0]))
- gfc_internal_error ("gfc_array_size failed");
+   {
+ gfc_error ("Cannot determine shape of initializer at %L",
+>where);
+ free (init->shape);
+ init->shape = NULL;
+ return false;
+   }
}

  for (dim = 0; dim < sym->as->rank; ++dim)

[Bug analyzer/106301] RFE: analyzer support of mmap

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

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #2 from Eric Gallager  ---
mmap has some portability issues to be aware of:
https://www.gnu.org/software/gnulib/manual/html_node/mmap.html
(besides the ones listed there, another one I've come across is sometimes some
headers shortening their name for MAP_ANONYMOUS to just MAP_ANON)

[Bug analyzer/106299] RFE: analyzer handling of fdopen

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

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

Eric Gallager  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=101550
 CC||egallager at gcc dot gnu.org

--- Comment #1 from Eric Gallager  ---
As with other ideas for special-casing certain functions, I'd just be aware of
certain portability issues, as gnulib describes for fdopen here:
https://www.gnu.org/software/gnulib/manual/html_node/fdopen.html

[Bug analyzer/106298] RFE: analyzer handling of dup, dup2, and dup3

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

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #1 from Eric Gallager  ---
Portability issues to be aware of with dup and dup2, per gnulib:
https://www.gnu.org/software/gnulib/manual/html_node/dup.html
https://www.gnu.org/software/gnulib/manual/html_node/dup2.html

Re: [PATCH] PR target/106278: Keep REG_EQUAL notes consistent during TImode STV.

[Uros Bizjak via Gcc-patches]

On Thu, Jul 14, 2022 at 6:58 PM Roger Sayle  wrote:
>
>
> This patch resolves PR target/106278 a regression on x86_64 caused by my
> recent TImode STV improvements.  Now that TImode STV can handle comparisons
> such as "(set (regs:CC) (compare:CC (reg:TI) ...))" the convert_insn method
> sensibly checks that the mode of the SET_DEST is TImode before setting
> it to V1TImode [to avoid V1TImode appearing on the hard reg CC_FLAGS.
>
> Hence the current code looks like:
>
>   if (GET_MODE (dst) == TImode)
> {
>   tmp = find_reg_equal_equiv_note (insn);
>   if (tmp && GET_MODE (XEXP (tmp, 0)) == TImode)
> PUT_MODE (XEXP (tmp, 0), V1TImode);
>   PUT_MODE (dst, V1TImode);
>   fix_debug_reg_uses (dst);
> }
>   break;
>
> which checks GET_MODE (dst) before calling PUT_MODE, and when a
> change is made updating the REG_EQUAL_NOTE tmp if it exists.
>
> The logical flaw (oversight) is that due to RTL sharing, the destination
> of this set may already have been updated to V1TImode, as this chain is
> being converted, but we still need to update any REG_EQUAL_NOTE that
> still has TImode.  Hence the correct code is actually:
>
>
>   if (GET_MODE (dst) == TImode)
> {
>   PUT_MODE (dst, V1TImode);
>   fix_debug_reg_uses (dst);
> }
>   if (GET_MODE (dst) == V1TImode)
> {
>   tmp = find_reg_equal_equiv_note (insn);
>   if (tmp && GET_MODE (XEXP (tmp, 0)) == TImode)
> PUT_MODE (XEXP (tmp, 0), V1TImode);
> }
>   break;
>
> While fixing this behavior, I noticed I had some indentation whitespace
> issues and some vestigial dead code in this function/method that I've
> taken the liberty of cleaning up (as obvious) in this patch.

While it is desired to fix cosmetic issues, those kinds of changes
unnecessarily make review of the patch more difficult.

> This patch has been tested on x86_64-pc-linux-gnu with make bootstrap
> and make -k check, both with and without --target_board=unix{-m32},
> with no new failures.  Ok for mainline?

OK, but please do not mix cleanups with the functional changes.
Cleanups should be separated to a follow-up patch.

Thanks,
Uros.

>
>
> 2022-07-14  Roger Sayle  
>
> gcc/ChangeLog
> PR target/106278
> * config/i386/i386-features.cc (general_scalar_chain::convert_insn):
> Fix indentation whitespace.
> (timode_scalar_chain::fix_debug_reg_uses): Likewise.
> (timode_scalar_chain::convert_insn): Delete dead code.
> Update TImode REG_EQUAL_NOTE even if the SET_DEST is already V1TI.
> Fix indentation whitespace.
> (convertible_comparison_p): Likewise.
> (timode_scalar_to_vector_candidate_p): Likewise.
>
> gcc/testsuite/ChangeLog
> PR target/106278
> * gcc.dg/pr106278.c: New test case.
>
>
> Thanks in advance,
> Roger
> --
>

Re: [PATCH] jit: Make recording::memento non-copyable

[David Malcolm via Gcc-patches]

On Thu, 2022-07-14 at 19:44 +0100, Jonathan Wakely wrote:
> These polymoprhic types don't appear to be copied anywhere. Rather
> than
> trying to reason about what it means to copy a polymoprhic base
> without
> copying the derived part, disable copies. This also avoids a
> potential
> double-free if a recorindg::string object does somehow get copied (it
> owns a pointer to dynamically allocated memory, but the implicit copy
> constructor will just make shallow copies).
> 
> Tested x86_64-linux with --enable-languages=c,c++,jit --enable-host-
> shared
> 
> OK for trunk?

[CCing jit mailing list]

Thanks; OK for trunk.

> 
> -- >8 --
> 
> gcc/jit/ChangeLog:
> 
> * jit-recording.h (recording::memento): Define copy
> constructor
> and copy assignment operator as deleted.
> (recording::string): Likewise.
> (recording::string::c_str): Add const qualifier.
> ---
>  gcc/jit/jit-recording.h | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/gcc/jit/jit-recording.h b/gcc/jit/jit-recording.h
> index 0dfb42f2676..8610ea988bd 100644
> --- a/gcc/jit/jit-recording.h
> +++ b/gcc/jit/jit-recording.h
> @@ -405,6 +405,9 @@ public:
>    virtual void write_reproducer (reproducer ) = 0;
>    virtual location *dyn_cast_location () { return NULL; }
>  
> +  memento (const memento&) = delete;
> +  memento& operator= (const memento&) = delete;
> +
>  protected:
>    memento (context *ctxt)
>    : m_ctxt (ctxt),
> @@ -436,13 +439,16 @@ public:
>    string (context *ctxt, const char *text, bool escaped);
>    ~string ();
>  
> -  const char *c_str () { return m_buffer; }
> +  const char *c_str () const { return m_buffer; }
>  
>    static string * from_printf (context *ctxt, const char *fmt, ...)
>  GNU_PRINTF(2, 3);
>  
>    void replay_into (replayer *) final override {}
>  
> +  string (const string&) = delete;
> +  string& operator= (const string&) = delete;
> +
>  private:
>    string * make_debug_string () final override;
>    void write_reproducer (reproducer ) final override;

[PATCH] jit: Make recording::memento non-copyable

[Jonathan Wakely via Gcc-patches]

These polymoprhic types don't appear to be copied anywhere. Rather than
trying to reason about what it means to copy a polymoprhic base without
copying the derived part, disable copies. This also avoids a potential
double-free if a recorindg::string object does somehow get copied (it
owns a pointer to dynamically allocated memory, but the implicit copy
constructor will just make shallow copies).

Tested x86_64-linux with --enable-languages=c,c++,jit --enable-host-shared

OK for trunk?

-- >8 --

gcc/jit/ChangeLog:

* jit-recording.h (recording::memento): Define copy constructor
and copy assignment operator as deleted.
(recording::string): Likewise.
(recording::string::c_str): Add const qualifier.
---
 gcc/jit/jit-recording.h | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/gcc/jit/jit-recording.h b/gcc/jit/jit-recording.h
index 0dfb42f2676..8610ea988bd 100644
--- a/gcc/jit/jit-recording.h
+++ b/gcc/jit/jit-recording.h
@@ -405,6 +405,9 @@ public:
   virtual void write_reproducer (reproducer ) = 0;
   virtual location *dyn_cast_location () { return NULL; }
 
+  memento (const memento&) = delete;
+  memento& operator= (const memento&) = delete;
+
 protected:
   memento (context *ctxt)
   : m_ctxt (ctxt),
@@ -436,13 +439,16 @@ public:
   string (context *ctxt, const char *text, bool escaped);
   ~string ();
 
-  const char *c_str () { return m_buffer; }
+  const char *c_str () const { return m_buffer; }
 
   static string * from_printf (context *ctxt, const char *fmt, ...)
 GNU_PRINTF(2, 3);
 
   void replay_into (replayer *) final override {}
 
+  string (const string&) = delete;
+  string& operator= (const string&) = delete;
+
 private:
   string * make_debug_string () final override;
   void write_reproducer (reproducer ) final override;
-- 
2.36.1

[Bug libfortran/106295] INQUIRE statement bus error at runtime

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

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

--- Comment #4 from anlauf at gcc dot gnu.org ---
I think the fix for PR83036 (INQUIRE specifier NEXTREC is a 4-byte integer,
should be 8), which changed the layout of struct st_parameter_inquire,
could explain what you observe.

I have no solution to your problem other than recommending not doing what
you did: mix vastly different compiler versions with legacy code.  You would
have been warned if you used modern Fortran with modules.

I bet that most other compilers require (recommend or advise) recompilation
of legacy code without explaining in detail which intrinsic might be affected.

[Bug libstdc++/63400] [C++11]precision of std::chrono::high_resolution_clock

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

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

--- Comment #8 from Jonathan Wakely  ---
(In reply to frankhb1989 from comment #4)
> With mingw-w64, the following program shows that the monotonic clock is far
> more precise:
> 
> #include 
> #include 
> 
> int main()
> {
>   using namespace std;
>   timespec ts;
> 
>   if(clock_getres(CLOCK_REALTIME, ) == 0)
>   cout << "CLOCK_REALTIME: " << ts.tv_sec << ',' << ts.tv_nsec << 
> endl;
>   if(clock_getres(CLOCK_MONOTONIC, ) == 0)
>   cout << "CLOCK_MONOTONIC: " << ts.tv_sec << ',' << ts.tv_nsec 
> << endl;
> }
> 
> The result on my machine:
> 
> CLOCK_REALTIME: 0,15625000
> CLOCK_MONOTONIC: 0,489

Is this still an issue in 2022?

Using a mingw-w64 cross-compiler and running under Wine I get:

CLOCK_REALTIME: 0,100
CLOCK_MONOTONIC: 0,100

Is that just because I'm using Wine not real Windows?

[Bug libstdc++/63400] [C++11]precision of std::chrono::high_resolution_clock

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

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

--- Comment #7 from Jonathan Wakely  ---
(In reply to frankhb1989 from comment #5)
> BTW, what if the clock_gettime call failed? The current implementation does
> nothing about error handling... (Though for QPC on Windows it should rarely
> fail for machines within a decade.)

None of the errors specified by POSIX or Linux are possible, because we don't
pass invalid clock IDs or invalid pointers to the function.

I don't know if the winpthreads wrapper has additional failure cases. It should
not be possible for it to fail when given valid arguments.

[Bug rtl-optimization/101347] [11/12/13 Regression] ICE in cfg_layout_initialize with __builtin_setjmp and -fprofile-generate -fprofile-use

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

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #4 from Alexander Monakov  ---
The label at __builtin_setjmp_receiver was added to
nonlocal_goto_handler_labels twice (because __builtin_setjmp_setup was
duplicated), but remove_node_from_insn_list removed only the first copy. A
simple check would have caught this early:

@@ -2928,6 +2899,7 @@ remove_node_from_insn_list (const rtx_insn *node,
rtx_insn_list **listp)
  else
*listp = temp->next ();

+ gcc_checking_assert (!in_insn_list_p (temp->next (), node));
  return;
}


I think a reasonable solution is to move registration of receiver label from
expansion of __builtin_setjmp_setup to expansion of __builtin_setjmp_receiver:

@@ -7467,15 +7467,7 @@ expand_builtin (tree exp, rtx target, rtx subtarget,
machine_mode mode,
  tree label = TREE_OPERAND (CALL_EXPR_ARG (exp, 1), 0);
  rtx_insn *label_r = label_rtx (label);

- /* This is copied from the handling of non-local gotos.  */
  expand_builtin_setjmp_setup (buf_addr, label_r);
- nonlocal_goto_handler_labels
-   = gen_rtx_INSN_LIST (VOIDmode, label_r,
-nonlocal_goto_handler_labels);
- /* ??? Do not let expand_label treat us as such since we would
-not want to be both on the list of non-local labels and on
-the list of forced labels.  */
- FORCED_LABEL (label) = 0;
  return const0_rtx;
}
   break;
@@ -7488,6 +7480,13 @@ expand_builtin (tree exp, rtx target, rtx subtarget,
machine_mode mode,
  rtx_insn *label_r = label_rtx (label);

  expand_builtin_setjmp_receiver (label_r);
+ nonlocal_goto_handler_labels
+   = gen_rtx_INSN_LIST (VOIDmode, label_r,
+nonlocal_goto_handler_labels);
+ /* ??? Do not let expand_label treat us as such since we would
+not want to be both on the list of non-local labels and on
+the list of forced labels.  */
+ FORCED_LABEL (label) = 0;
  return const0_rtx;
}
   break;

[Bug c/106307] New: error when I do a test on a pointer on Arduino 1.8.19

[helene.blanquier at laposte dot net via Gcc-bugs]

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

Bug ID: 106307
   Summary: error when I do a test on a pointer on Arduino 1.8.19
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: helene.blanquier at laposte dot net
  Target Milestone: ---

Hi,

Arduino : 1.8.19 (Windows Store 1.8.57.0) (Windows 10), Carte : "Arduino Uno"

C:\Program
Files\WindowsApps\ArduinoLLC.ArduinoIDE_1.8.57.0_x86__mdqgnx93n4wtt\arduino-builder
-dump-prefs -logger=machine -hardware C:\Program
Files\WindowsApps\ArduinoLLC.ArduinoIDE_1.8.57.0_x86__mdqgnx93n4wtt\hardware
-hardware C:\Users\Phil\Documents\ArduinoData\packages -tools C:\Program
Files\WindowsApps\ArduinoLLC.ArduinoIDE_1.8.57.0_x86__mdqgnx93n4wtt\tools-builder
-tools C:\Program
Files\WindowsApps\ArduinoLLC.ArduinoIDE_1.8.57.0_x86__mdqgnx93n4wtt\hardware\tools\avr
-tools C:\Users\Phil\Documents\ArduinoData\packages -built-in-libraries
C:\Program
Files\WindowsApps\ArduinoLLC.ArduinoIDE_1.8.57.0_x86__mdqgnx93n4wtt\libraries
-libraries D:\Data_Phil\Arduino_programmes\libraries -fqbn=arduino:avr:uno
-vid-pid=2341_0043 -ide-version=10819 -build-path
C:\Users\Phil\AppData\Local\Temp\arduino_build_500670 -warnings=none
-build-cache C:\Users\Phil\AppData\Local\Temp\arduino_cache_742775
-prefs=build.warn_data_percentage=75
-prefs=runtime.tools.arduinoOTA.path=C:\Users\Phil\Documents\ArduinoData\packages\arduino\tools\arduinoOTA\1.3.0
-prefs=runtime.tools.arduinoOTA-1.3.0.path=C:\Users\Phil\Documents\ArduinoData\packages\arduino\tools\arduinoOTA\1.3.0
-prefs=runtime.tools.avr-gcc.path=C:\Users\Phil\Documents\ArduinoData\packages\arduino\tools\avr-gcc\7.3.0-atmel3.6.1-arduino7
-prefs=runtime.tools.avr-gcc-7.3.0-atmel3.6.1-arduino7.path=C:\Users\Phil\Documents\ArduinoData\packages\arduino\tools\avr-gcc\7.3.0-atmel3.6.1-arduino7
-prefs=runtime.tools.avrdude.path=C:\Users\Phil\Documents\ArduinoData\packages\arduino\tools\avrdude\6.3.0-arduino17
-prefs=runtime.tools.avrdude-6.3.0-arduino17.path=C:\Users\Phil\Documents\ArduinoData\packages\arduino\tools\avrdude\6.3.0-arduino17
-verbose
D:\Data_Phil\Arduino_programmes\InMoove_2022_07_14\Arduino_Uno_EasyVR\Arduino_Uno_EasyVR.ino

C:\Program
Files\WindowsApps\ArduinoLLC.ArduinoIDE_1.8.57.0_x86__mdqgnx93n4wtt\arduino-builder
-compile -logger=machine -hardware C:\Program
Files\WindowsApps\ArduinoLLC.ArduinoIDE_1.8.57.0_x86__mdqgnx93n4wtt\hardware
-hardware C:\Users\Phil\Documents\ArduinoData\packages -tools C:\Program
Files\WindowsApps\ArduinoLLC.ArduinoIDE_1.8.57.0_x86__mdqgnx93n4wtt\tools-builder
-tools C:\Program
Files\WindowsApps\ArduinoLLC.ArduinoIDE_1.8.57.0_x86__mdqgnx93n4wtt\hardware\tools\avr
-tools C:\Users\Phil\Documents\ArduinoData\packages -built-in-libraries
C:\Program
Files\WindowsApps\ArduinoLLC.ArduinoIDE_1.8.57.0_x86__mdqgnx93n4wtt\libraries
-libraries D:\Data_Phil\Arduino_programmes\libraries -fqbn=arduino:avr:uno
-vid-pid=2341_0043 -ide-version=10819 -build-path
C:\Users\Phil\AppData\Local\Temp\arduino_build_500670 -warnings=none
-build-cache C:\Users\Phil\AppData\Local\Temp\arduino_cache_742775
-prefs=build.warn_data_percentage=75
-prefs=runtime.tools.arduinoOTA.path=C:\Users\Phil\Documents\ArduinoData\packages\arduino\tools\arduinoOTA\1.3.0
-prefs=runtime.tools.arduinoOTA-1.3.0.path=C:\Users\Phil\Documents\ArduinoData\packages\arduino\tools\arduinoOTA\1.3.0
-prefs=runtime.tools.avr-gcc.path=C:\Users\Phil\Documents\ArduinoData\packages\arduino\tools\avr-gcc\7.3.0-atmel3.6.1-arduino7
-prefs=runtime.tools.avr-gcc-7.3.0-atmel3.6.1-arduino7.path=C:\Users\Phil\Documents\ArduinoData\packages\arduino\tools\avr-gcc\7.3.0-atmel3.6.1-arduino7
-prefs=runtime.tools.avrdude.path=C:\Users\Phil\Documents\ArduinoData\packages\arduino\tools\avrdude\6.3.0-arduino17
-prefs=runtime.tools.avrdude-6.3.0-arduino17.path=C:\Users\Phil\Documents\ArduinoData\packages\arduino\tools\avrdude\6.3.0-arduino17
-verbose
D:\Data_Phil\Arduino_programmes\InMoove_2022_07_14\Arduino_Uno_EasyVR\Arduino_Uno_EasyVR.ino

Using board 'uno' from platform in folder:
C:\Users\Phil\Documents\ArduinoData\packages\arduino\hardware\avr\1.8.5

Using core 'arduino' from platform in folder:
C:\Users\Phil\Documents\ArduinoData\packages\arduino\hardware\avr\1.8.5

Detecting libraries used...

"C:\\Users\\Phil\\Documents\\ArduinoData\\packages\\arduino\\tools\\avr-gcc\\7.3.0-atmel3.6.1-arduino7/bin/avr-g++"
-c -g -Os -w -std=gnu++11 -fpermissive -fno-exceptions -ffunction-sections
-fdata-sections -fno-threadsafe-statics -Wno-error=narrowing -flto -w -x c++ -E
-CC -mmcu=atmega328p -DF_CPU=1600L -DARDUINO=10819 -DARDUINO_AVR_UNO
-DARDUINO_ARCH_AVR
"-IC:\\Users\\Phil\\Documents\\ArduinoData\\packages\\arduino\\hardware\\avr\\1.8.5\\cores\\arduino"
"-IC:\\Users\\Phil\\Documents\\ArduinoData\\packages\\arduino\\hardware\\avr\\1.8.5\\variants\\standard"

Re: [GCC 11 backport] Disable generating load/store vector pairs for block copies.

[Michael Meissner via Gcc-patches]

Back port patch (changing .cc to .c) from trunk to GCC 11 committed.

| From 3118d0856b030fe491a170354fed2df570df199f Mon Sep 17 00:00:00 2001
| From: Michael Meissner 
| Date: Thu, 14 Jul 2022 14:03:37 -0400
| Subject: [PATCH] [BACKPORT] Disable generating load/store vector pairs for 
block copies.

Testing has found that using load and store vector pair for block copies
can result in a slow down on power10.  This patch disables using the
vector pair instructions for block copies if we are tuning for power10.

2022-06-11   Michael Meissner  

gcc/

* config/rs6000/rs6000.c (rs6000_option_override_internal): Do
not generate block copies with vector pair instructions if we are
tuning for power10.  Back port from master branch.
---
 gcc/config/rs6000/rs6000.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index 8c89b45922f..73f90f134f8 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -4149,7 +4149,10 @@ rs6000_option_override_internal (bool global_init_p)
 
   if (!(rs6000_isa_flags_explicit & OPTION_MASK_BLOCK_OPS_VECTOR_PAIR))
 {
-  if (TARGET_MMA && TARGET_EFFICIENT_UNALIGNED_VSX)
+  /* Do not generate lxvp and stxvp on power10 since there are some
+performance issues.  */
+  if (TARGET_MMA && TARGET_EFFICIENT_UNALIGNED_VSX
+ && rs6000_tune != PROCESSOR_POWER10)
rs6000_isa_flags |= OPTION_MASK_BLOCK_OPS_VECTOR_PAIR;
   else
rs6000_isa_flags &= ~OPTION_MASK_BLOCK_OPS_VECTOR_PAIR;
-- 
2.35.3


-- 
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meiss...@linux.ibm.com

Re: [RFC] RISC-V: Add support for RV64E/lp64e

[Palmer Dabbelt]

On Tue, 12 Jul 2022 22:09:53 PDT (-0700), Palmer Dabbelt wrote:

gcc/ChangeLog

* config.gcc (riscv): Accept rv64e and lp64e.
* config/riscv/arch-canonicalize: Likewise.
* config/riscv/riscv-c.cc (riscv_cpu_cpp_builtins): Likewise.
* config/riscv/riscv-opts.h (riscv_abi_type): Likewise.
* config/riscv/riscv.cc (riscv_option_override): Likewise
* config/riscv/riscv.h (UNITS_PER_FP_ARG): Likewise.
(STACK_BOUNDARY): Likewise.
(ABI_STACK_BOUNDARY): Likewise.
(MAX_ARGS_IN_REGISTERS): Likewise.
(ABI_SPEC): Likewise.
* config/riscv/riscv.opt (abi_type): Likewise.
* doc/invoke.texi (RISC-V) <-mabi>: Likewise.
---
This is all still in flight, but evidently RV64E exists.  I haven't
tested this at all, but given that we don't even have the ABI docs lined
up yet it's likely a bit away from being mergable.
---
 gcc/config.gcc |  8 +---
 gcc/config/riscv/arch-canonicalize |  2 +-
 gcc/config/riscv/riscv-c.cc|  1 +
 gcc/config/riscv/riscv-opts.h  |  1 +
 gcc/config/riscv/riscv.cc  |  6 --
 gcc/config/riscv/riscv.h   | 11 +++
 gcc/config/riscv/riscv.opt |  3 +++
 gcc/doc/invoke.texi|  5 +++--
 8 files changed, 25 insertions(+), 12 deletions(-)

diff --git a/gcc/config.gcc b/gcc/config.gcc
index 4e3b15bb5e9..4617ecb8d9b 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -4637,7 +4637,7 @@ case "${target}" in

# Infer arch from --with-arch, --target, and --with-abi.
case "${with_arch}" in
-   rv32e* | rv32i* | rv32g* | rv64i* | rv64g*)
+   rv32e* | rv32i* | rv32g* | rv64e* | rv64i* | rv64g*)
# OK.
;;
"")
@@ -4645,12 +4645,13 @@ case "${target}" in
case "${with_abi}" in
ilp32e) with_arch="rv32e" ;;
ilp32 | ilp32f | ilp32d) with_arch="rv32gc" ;;
+   lp64e) with_arch="rv64e" ;;
lp64 | lp64f | lp64d) with_arch="rv64gc" ;;
*) with_arch="rv${xlen}gc" ;;
esac
;;
*)
-   echo "--with-arch=${with_arch} is not supported.  The argument must 
begin with rv32e, rv32i, rv32g, rv64i, or rv64g." 1>&2
+   echo "--with-arch=${with_arch} is not supported.  The argument must 
begin with rv32e, rv32i, rv32g, rv64e, rv64i, or rv64g." 1>&2
exit 1
;;
esac
@@ -4672,6 +4673,7 @@ case "${target}" in
rv32e*) with_abi=ilp32e ;;
rv32*) with_abi=ilp32 ;;
rv64*d* | rv64g*) with_abi=lp64d ;;
+   rv64e*) with_abi=lp64e ;;
rv64*) with_abi=lp64 ;;
esac
;;
@@ -4687,7 +4689,7 @@ case "${target}" in
ilp32,rv32* | ilp32e,rv32e* \
| ilp32f,rv32*f* | ilp32f,rv32g* \
| ilp32d,rv32*d* | ilp32d,rv32g* \
-   | lp64,rv64* \
+   | lp64,rv64* | lp64e,rv64e* \
| lp64f,rv64*f* | lp64f,rv64g* \
| lp64d,rv64*d* | lp64d,rv64g*)
;;
diff --git a/gcc/config/riscv/arch-canonicalize 
b/gcc/config/riscv/arch-canonicalize
index fd7651ac491..8db3e88ddd7 100755
--- a/gcc/config/riscv/arch-canonicalize
+++ b/gcc/config/riscv/arch-canonicalize
@@ -71,7 +71,7 @@ def arch_canonicalize(arch, isa_spec):
   new_arch = ""
   extra_long_ext = []
   std_exts = []
-  if arch[:5] in ['rv32e', 'rv32i', 'rv32g', 'rv64i', 'rv64g']:
+  if arch[:5] in ['rv32e', 'rv32i', 'rv32g', 'rv64e', 'rv64i', 'rv64g']:
 new_arch = arch[:5].replace("g", "i")
 if arch[:5] in ['rv32g', 'rv64g']:
   std_exts = ['m', 'a', 'f', 'd']
diff --git a/gcc/config/riscv/riscv-c.cc b/gcc/config/riscv/riscv-c.cc
index eb7ef09297e..4614dc6b6d9 100644
--- a/gcc/config/riscv/riscv-c.cc
+++ b/gcc/config/riscv/riscv-c.cc
@@ -67,6 +67,7 @@ riscv_cpu_cpp_builtins (cpp_reader *pfile)
   switch (riscv_abi)
 {
 case ABI_ILP32E:
+case ABI_LP64E:
   builtin_define ("__riscv_abi_rve");
   gcc_fallthrough ();

diff --git a/gcc/config/riscv/riscv-opts.h b/gcc/config/riscv/riscv-opts.h
index 1e153b3a6e7..70fe708cbae 100644
--- a/gcc/config/riscv/riscv-opts.h
+++ b/gcc/config/riscv/riscv-opts.h
@@ -27,6 +27,7 @@ enum riscv_abi_type {
   ABI_ILP32F,
   ABI_ILP32D,
   ABI_LP64,
+  ABI_LP64E,
   ABI_LP64F,
   ABI_LP64D
 };
diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index 2e83ca07394..51b7195c17b 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -5047,8 +5047,10 @@ riscv_option_override (void)
 error ("requested ABI requires %<-march%> to subsume the %qc extension",
   

Re: [PATCH] c++: Add __reference_con{struc,ver}ts_from_temporary [PR104477]

[Marek Polacek via Gcc-patches]

On Tue, Jul 12, 2022 at 04:15:00PM -0400, Jason Merrill wrote:
> On 7/12/22 16:10, Jason Merrill wrote:
> > On 7/8/22 13:41, Marek Polacek wrote:
> > > This patch implements C++23 P2255R2, which adds two new type traits to
> > > detect reference binding to a temporary.  They can be used to detect code
> > > like
> > > 
> > >    std::tuple t("meow");
> > > 
> > > which is incorrect because it always creates a dangling reference,
> > > because
> > > the std::string temporary is created inside the selected constructor of
> > > std::tuple, and not outside it.
> > > 
> > > There are two new compiler builtins,
> > > __reference_constructs_from_temporary
> > > and __reference_converts_from_temporary.  The former is used to simulate
> > > direct- and the latter copy-initialization context.  But I had a
> > > hard time
> > > finding a test where there's actually a difference.  Under DR 2267, both
> > > of these are invalid:
> > > 
> > >    struct A { } a;
> > >    struct B { explicit B(const A&); };
> > >    const B {a};
> > >    const B (a);
> > > 
> > > so I had to peruse [over.match.ref], and eventually realized that the
> > > difference can be seen here:
> > > 
> > >    struct G {
> > >  operator int(); // #1
> > >  explicit operator int&&(); // #2
> > >    };
> > > 
> > > int&& r1(G{}); // use #2 (no temporary)
> > > int&& r2 = G{}; // use #1 (a temporary is created to be bound to int&&)
> > > 
> > > The implementation itself was rather straightforward because we already
> > > have conv_binds_ref_to_prvalue.  The main function here is
> > > reference_from_temporary.  The renaming to ref_conv_binds_to_temporary_p
> > > is because previously the function didn't distinguish between an invalid
> > > conversion and one that binds to a prvalue.
> > > 
> > > The patch also adds the relevant class and variable templates to
> > > .
> > > 
> > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> > > 
> > > PR c++/104477
> > > 
> > > gcc/c-family/ChangeLog:
> > > 
> > > * c-common.cc (c_common_reswords): Add
> > > __reference_constructs_from_temporary and
> > > __reference_converts_from_temporary.
> > > * c-common.h (enum rid): Add RID_REF_CONSTRUCTS_FROM_TEMPORARY and
> > > RID_REF_CONVERTS_FROM_TEMPORARY.
> > > 
> > > gcc/cp/ChangeLog:
> > > 
> > > * call.cc (ref_conv_binds_directly_p): Rename to ...
> > > (ref_conv_binds_to_temporary_p): ... this.  Add a new bool
> > > parameter.  Return true only if the conversion is valid and
> > > conv_binds_ref_to_prvalue returns true.
> > > * constraint.cc (diagnose_trait_expr): Handle
> > > CPTK_REF_CONSTRUCTS_FROM_TEMPORARY and
> > > CPTK_REF_CONVERTS_FROM_TEMPORARY.
> > > * cp-tree.h (enum cp_trait_kind): Add
> > > CPTK_REF_CONSTRUCTS_FROM_TEMPORARY
> > > and CPTK_REF_CONVERTS_FROM_TEMPORARY.
> > > (ref_conv_binds_directly_p): Rename to ...
> > > (ref_conv_binds_to_temporary_p): ... this.
> > > (reference_from_temporary): Declare.
> > > * cxx-pretty-print.cc (pp_cxx_trait_expression): Handle
> > > CPTK_REF_CONSTRUCTS_FROM_TEMPORARY and
> > > CPTK_REF_CONVERTS_FROM_TEMPORARY.
> > > * method.cc (reference_from_temporary): New.
> > > * parser.cc (cp_parser_primary_expression): Handle
> > > RID_REF_CONSTRUCTS_FROM_TEMPORARY and
> > > RID_REF_CONVERTS_FROM_TEMPORARY.
> > > (cp_parser_trait_expr): Likewise.
> > > (warn_for_range_copy): Adjust to call ref_conv_binds_to_temporary_p.
> > > * semantics.cc (trait_expr_value): Handle
> > > CPTK_REF_CONSTRUCTS_FROM_TEMPORARY and
> > > CPTK_REF_CONVERTS_FROM_TEMPORARY.
> > > (finish_trait_expr): Likewise.
> > > 
> > > libstdc++-v3/ChangeLog:
> > > 
> > > * include/std/type_traits (reference_constructs_from_temporary,
> > > reference_converts_from_temporary): New class templates.
> > > (reference_constructs_from_temporary_v,
> > > reference_converts_from_temporary_v): New variable templates.
> > > (__cpp_lib_reference_from_temporary): Define for C++23.
> > > * include/std/version (__cpp_lib_reference_from_temporary):
> > > Define for
> > > C++23.
> > > * testsuite/20_util/variable_templates_for_traits.cc: Test
> > > reference_constructs_from_temporary_v and
> > > reference_converts_from_temporary_v.
> > > * testsuite/20_util/reference_from_temporary/value.cc: New test.
> > > * testsuite/20_util/reference_from_temporary/value2.cc: New test.
> > > * testsuite/20_util/reference_from_temporary/version.cc: New test.
> > > 
> > > gcc/testsuite/ChangeLog:
> > > 
> > > * g++.dg/ext/reference_constructs_from_temporary1.C: New test.
> > > * g++.dg/ext/reference_converts_from_temporary1.C: New test.
> > > ---
> > >   gcc/c-family/c-common.cc  |   4 +
> > >   gcc/c-family/c-common.h   |   2 +
> > >   gcc/cp/call.cc    |  14 +-
> > >   gcc/cp/constraint.cc  |   8 +
> > >   

[PATCH] x86: Disable sibcall if indirect_return attribute doesn't match

[H.J. Lu via Gcc-patches]

When shadow stack is enabled, function with indirect_return attribute
may return via indirect jump.  In this case, we need to disable sibcall
if caller doesn't have indirect_return attribute and indirect branch
tracking is enabled since compiler won't generate ENDBR when calling the
caller.

gcc/

PR target/85620
* config/i386/i386.cc (ix86_function_ok_for_sibcall): Return
false if callee has indirect_return attribute and caller
doesn't.

gcc/testsuite/

PR target/85620
* gcc.target/i386/pr85620-2.c: Updated.
* gcc.target/i386/pr85620-5.c: New test.
* gcc.target/i386/pr85620-6.c: Likewise.
* gcc.target/i386/pr85620-7.c: Likewise.
---
 gcc/config/i386/i386.cc   | 10 ++
 gcc/testsuite/gcc.target/i386/pr85620-2.c |  3 ++-
 gcc/testsuite/gcc.target/i386/pr85620-5.c | 13 +
 gcc/testsuite/gcc.target/i386/pr85620-6.c | 14 ++
 gcc/testsuite/gcc.target/i386/pr85620-7.c | 14 ++
 5 files changed, 53 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.target/i386/pr85620-5.c
 create mode 100644 gcc/testsuite/gcc.target/i386/pr85620-6.c
 create mode 100644 gcc/testsuite/gcc.target/i386/pr85620-7.c

diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc
index 3a3c7299eb4..e03f86d4a23 100644
--- a/gcc/config/i386/i386.cc
+++ b/gcc/config/i386/i386.cc
@@ -1024,6 +1024,16 @@ ix86_function_ok_for_sibcall (tree decl, tree exp)
 return false;
 }
 
+  /* Disable sibcall if callee has indirect_return attribute and
+ caller doesn't since callee will return to the caller's caller
+ via an indirect jump.  */
+  if (((flag_cf_protection & (CF_RETURN | CF_BRANCH))
+   == (CF_RETURN | CF_BRANCH))
+  && lookup_attribute ("indirect_return", TYPE_ATTRIBUTES (type))
+  && !lookup_attribute ("indirect_return",
+   TYPE_ATTRIBUTES (TREE_TYPE (cfun->decl
+return false;
+
   /* Otherwise okay.  That also includes certain types of indirect calls.  */
   return true;
 }
diff --git a/gcc/testsuite/gcc.target/i386/pr85620-2.c 
b/gcc/testsuite/gcc.target/i386/pr85620-2.c
index b2e680fa1fe..14ce0ffd1e1 100644
--- a/gcc/testsuite/gcc.target/i386/pr85620-2.c
+++ b/gcc/testsuite/gcc.target/i386/pr85620-2.c
@@ -1,6 +1,7 @@
 /* { dg-do compile } */
 /* { dg-options "-O2 -fcf-protection" } */
-/* { dg-final { scan-assembler-times {\mendbr} 1 } } */
+/* { dg-final { scan-assembler-times {\mendbr} 2 } } */
+/* { dg-final { scan-assembler-not "jmp" } } */
 
 struct ucontext;
 
diff --git a/gcc/testsuite/gcc.target/i386/pr85620-5.c 
b/gcc/testsuite/gcc.target/i386/pr85620-5.c
new file mode 100644
index 000..04537702d09
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr85620-5.c
@@ -0,0 +1,13 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fcf-protection" } */
+/* { dg-final { scan-assembler-not "jmp" } } */
+
+struct ucontext;
+
+extern int (*bar) (struct ucontext *) __attribute__((__indirect_return__));
+
+int
+foo (struct ucontext *oucp)
+{
+  return bar (oucp);
+}
diff --git a/gcc/testsuite/gcc.target/i386/pr85620-6.c 
b/gcc/testsuite/gcc.target/i386/pr85620-6.c
new file mode 100644
index 000..0b6a64e8454
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr85620-6.c
@@ -0,0 +1,14 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fcf-protection" } */
+/* { dg-final { scan-assembler "jmp" } } */
+
+struct ucontext;
+
+extern int bar (struct ucontext *) __attribute__((__indirect_return__));
+
+__attribute__((__indirect_return__))
+int
+foo (struct ucontext *oucp)
+{
+  return bar (oucp);
+}
diff --git a/gcc/testsuite/gcc.target/i386/pr85620-7.c 
b/gcc/testsuite/gcc.target/i386/pr85620-7.c
new file mode 100644
index 000..fa62d56decf
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr85620-7.c
@@ -0,0 +1,14 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fcf-protection" } */
+/* { dg-final { scan-assembler "jmp" } } */
+
+struct ucontext;
+
+extern int (*bar) (struct ucontext *) __attribute__((__indirect_return__));
+extern int foo (struct ucontext *) __attribute__((__indirect_return__));
+
+int
+foo (struct ucontext *oucp)
+{
+  return bar (oucp);
+}
-- 
2.36.1

[PATCH v3] c++: Add __reference_con{struc,ver}ts_from_temporary [PR104477]

[Marek Polacek via Gcc-patches]

On Tue, Jul 12, 2022 at 04:10:08PM -0400, Jason Merrill wrote:
> On 7/8/22 13:41, Marek Polacek wrote:
> > +bool
> > +reference_from_temporary (tree to, tree from, bool direct_init_p)
> > +{
> > +  /* Check is_reference.  */
> > +  if (!TYPE_REF_P (to))
> > +return false;
> > +  /* Check is_constructible.
> > + ??? This check doesn't seem to be necessary; if T isn't constructible
> > + from U, we won't be able to create a conversion.  */
> > +  if (!is_xible (INIT_EXPR, to, build_tree_list (NULL_TREE, from)))
> > +return false;
> 
> I agree with the comment, did you try leaving this out?  If it stays I'd
> think it needs to consider direct_init_p.

I did, it doesn't break anything, so in this version I dropped the is_xible
call entirely.
 
> > @@ -13811,7 +13821,7 @@ warn_for_range_copy (tree decl, tree expr)
> > if (TYPE_REF_P (type))
> >   {
> > -  if (glvalue_p (expr) && !ref_conv_binds_directly_p (type, expr))
> > +  if (glvalue_p (expr) && ref_conv_binds_to_temporary_p (type, expr))
> > {
> >   auto_diagnostic_group d;
> >   if (warning_at (loc, OPT_Wrange_loop_construct,
> > @@ -13842,7 +13852,7 @@ warn_for_range_copy (tree decl, tree expr)
> > tree rtype = cp_build_reference_type (type, /*rval*/false);
> > /* If we could initialize the reference directly, it wouldn't involve 
> > any
> >copies.  */
> > -  if (!ref_conv_binds_directly_p (rtype, expr))
> > +  if (ref_conv_binds_to_temporary_p (rtype, expr))
> >   return;
> 
> I think this case wants the old handling of invalid conversions you
> mentioned in your intro; we don't want to suggest changing to a reference if
> that's ill-formed.

Right.  I've changed the return type to 'tristate', so that we can properly
distinguish between true/false/dunno.
 
> In passing we might change the comment to "If we can initialize a reference
> directly, suggest that to avoid the copy." and move it above the rtype
> declaration.

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

-- >8 --
This patch implements C++23 P2255R2, which adds two new type traits to
detect reference binding to a temporary.  They can be used to detect code
like

  std::tuple t("meow");

which is incorrect because it always creates a dangling reference, because
the std::string temporary is created inside the selected constructor of
std::tuple, and not outside it.

There are two new compiler builtins, __reference_constructs_from_temporary
and __reference_converts_from_temporary.  The former is used to simulate
direct- and the latter copy-initialization context.  But I had a hard time
finding a test where there's actually a difference.  Under DR 2267, both
of these are invalid:

  struct A { } a;
  struct B { explicit B(const A&); };
  const B {a};
  const B (a);

so I had to peruse [over.match.ref], and eventually realized that the
difference can be seen here:

  struct G {
operator int(); // #1
explicit operator int&&(); // #2
  };

int&& r1(G{}); // use #2 (no temporary)
int&& r2 = G{}; // use #1 (a temporary is created to be bound to int&&)

The implementation itself was rather straightforward because we already
have the conv_binds_ref_to_prvalue function.  The main function here is
reference_from_temporary.
I've changed the return type of ref_conv_binds_directly to tristate, because
previously the function didn't distinguish between an invalid conversion and
one that binds to a prvalue.  Since it no longer returns a bool, I removed
the _p suffix.

The patch also adds the relevant class and variable templates to .

PR c++/104477

gcc/c-family/ChangeLog:

* c-common.cc (c_common_reswords): Add
__reference_constructs_from_temporary and
__reference_converts_from_temporary.
* c-common.h (enum rid): Add RID_REF_CONSTRUCTS_FROM_TEMPORARY and
RID_REF_CONVERTS_FROM_TEMPORARY.

gcc/cp/ChangeLog:

* call.cc (ref_conv_binds_directly_p): Rename to ...
(ref_conv_binds_directly): ... this.  Add a new bool parameter.  Change
the return type to tristate.
* constraint.cc (diagnose_trait_expr): Handle
CPTK_REF_CONSTRUCTS_FROM_TEMPORARY and CPTK_REF_CONVERTS_FROM_TEMPORARY.
* cp-tree.h: Include "tristate.h".
(enum cp_trait_kind): Add CPTK_REF_CONSTRUCTS_FROM_TEMPORARY
and CPTK_REF_CONVERTS_FROM_TEMPORARY.
(ref_conv_binds_directly_p): Rename to ...
(ref_conv_binds_directly): ... this.
(reference_from_temporary): Declare.
* cxx-pretty-print.cc (pp_cxx_trait_expression): Handle
CPTK_REF_CONSTRUCTS_FROM_TEMPORARY and CPTK_REF_CONVERTS_FROM_TEMPORARY.
* method.cc (reference_from_temporary): New.
* parser.cc (cp_parser_primary_expression): Handle
RID_REF_CONSTRUCTS_FROM_TEMPORARY and RID_REF_CONVERTS_FROM_TEMPORARY.
(cp_parser_trait_expr): Likewise.
(warn_for_range_copy): Adjust to call ref_conv_binds_directly.
* 

[Bug ipa/106061] [13 Regression] during GIMPLE pass: einline ICE: verify_cgraph_node failed (edge points to wrong declaration) with -Og since r13-1204-gd68d366425369649

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||zhendong.su at inf dot ethz.ch

--- Comment #2 from Andrew Pinski  ---
*** Bug 106305 has been marked as a duplicate of this bug. ***

[Bug ipa/106305] ICE on valid code at -O1 with -funreachable-traps: verify_cgraph_node failed

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Andrew Pinski  ---
Dup of bug 106061.

*** This bug has been marked as a duplicate of bug 106061 ***

[Bug tree-optimization/106249] [13 Regression] ICE in check_loop_closed_ssa_def, at tree-ssa-loop-manip.cc:645 since r13-1450-gd2a898666609452e

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||zhendong.su at inf dot ethz.ch

--- Comment #8 from Andrew Pinski  ---
*** Bug 106306 has been marked as a duplicate of this bug. ***

[Bug c/106306] ICE on valid code at -O1 with -funreachable-traps -floop-unroll-and-jam --param unroll-jam-min-percent=0: in execute_todo, at passes.cc:2140

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Andrew Pinski  ---
Dup of bug 106249.

*** This bug has been marked as a duplicate of bug 106249 ***

[Bug c/106306] New: ICE on valid code at -O1 with -funreachable-traps -floop-unroll-and-jam --param unroll-jam-min-percent=0: in execute_todo, at passes.cc:2140

[zhendong.su at inf dot ethz.ch via Gcc-bugs]

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

Bug ID: 106306
   Summary: ICE on valid code at -O1 with -funreachable-traps
-floop-unroll-and-jam --param
unroll-jam-min-percent=0: in execute_todo, at
passes.cc:2140
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhendong.su at inf dot ethz.ch
  Target Milestone: ---

Compiler Explorer: https://godbolt.org/z/doY9jPM54


[547] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/13.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--prefix=/local/suz-local/software/local/gcc-trunk --enable-sanitizers
--enable-languages=c,c++ --disable-werror --enable-multilib --with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.0.0 20220714 (experimental) [master r13-1696-g29f40a8047f] (GCC) 
[548] % 
[548] % gcctk -O1 -funreachable-traps -floop-unroll-and-jam --param
unroll-jam-min-percent=0 small.c
during GIMPLE pass: ivcanon
small.c: In function ‘main’:
small.c:2:5: internal compiler error: in execute_todo, at passes.cc:2140
2 | int main() {
  | ^~~~
0x719332 execute_todo
../../gcc-trunk/gcc/passes.cc:2140
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
[549] % 
[549] % cat small.c
int a[2], b, c;
int main() {
  for (c = 0; c < 3; c++)
for (b = 0; b < 2; b++)
  a[b] = 1;
  return 0;
}

Re: [PATCH] match.pd: Add new abs pattern [PR94290]

[Andrew Pinski via Gcc-patches]

On Thu, Jul 14, 2022 at 7:09 AM Sam Feifer  wrote:
>
>
> On Wed, Jul 13, 2022 at 3:36 PM Andrew Pinski  wrote:
>>
>> On Wed, Jul 13, 2022 at 12:26 PM Sam Feifer via Gcc-patches
>>  wrote:
>> >
>> > This patch is intended to fix a missed optimization in match.pd. It 
>> > optimizes (x >= 0 ? x : 0) + (x <= 0 ? -x : 0) to just abs(x). I had to 
>> > write a second simplification in match.pd to handle the commutative 
>> > property as the match was not ocurring otherwise. Additionally, the 
>> > pattern (x <= 0 ? -x : 0) now gets optimized to max(-x, 0), which helps 
>> > with the other simplification rule.
>>
>> You could use :c for the commutative property instead and that should
>> simplify things.
>> That is:
>>
>> (simplify
>>   (plus:c (max @0 integer_zerop) (max (negate @0) integer_zerop))
>>   (abs @0))
>>
>> Also since integer_zerop works on vectors, it seems like you should
>> add a testcase or two for the vector case.
>> Also would be useful if you write a testcase that uses different
>> statements rather than one big one so it gets exercised in the
>> forwprop case.
>> Note also if either of the max are used more than just in this
>> simplification, it could increase the lifetime of @0, maybe you need
>> to add :s to the max expressions.
>>
>
> Thanks for the feedback. I'm not quite sure what a vector test case would 
> look like for this. Could I get some guidance on that?

Yes this should produce the pattern at forwprop1 time (with the C++
front-end, the C front-end does not support vector selects):
typedef int __attribute__((vector_size(4*sizeof(int vint;

vint foo(vint x) {
vint t = (x >= 0 ? x : 0) ;
vint xx = -x;
vint t1 =  (xx >= 0 ? xx : 0);
return t + t1;
}

int foo(int x) {
int t = (x >= 0 ? x : 0) ;
int xx = -x;
int t1 =  (xx >= 0 ? xx : 0);
return t + t1;
}

Thanks,
Andrew Pinski


>
> Thanks
> -Sam
>
>>
>> Thanks,
>> Andrew
>>
>> >
>> > Tests are also included to be added to the testsuite.
>> >
>> > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
>> >
>> > PR tree-optimization/94290
>> >
>> > gcc/ChangeLog:
>> >
>> > * match.pd (x >= 0 ? x : 0) + (x <= 0 ? -x : 0): New 
>> > simplification.
>> > * match.pd (x <= 0 ? -x : 0): New Simplification.
>> >
>> > gcc/testsuite/ChangeLog:
>> >
>> > * gcc.c-torture/execute/pr94290-1.c: New test.
>> > * gcc.dg/pr94290-2.c: New test.
>> > * gcc.dg/pr94290.c: New test.
>> > ---
>> >  gcc/match.pd  | 15 ++
>> >  .../gcc.c-torture/execute/pr94290-1.c | 16 +++
>> >  gcc/testsuite/gcc.dg/pr94290-2.c  | 15 ++
>> >  gcc/testsuite/gcc.dg/pr94290.c| 46 +++
>> >  4 files changed, 92 insertions(+)
>> >  create mode 100644 gcc/testsuite/gcc.c-torture/execute/pr94290-1.c
>> >  create mode 100644 gcc/testsuite/gcc.dg/pr94290-2.c
>> >  create mode 100644 gcc/testsuite/gcc.dg/pr94290.c
>> >
>> > diff --git a/gcc/match.pd b/gcc/match.pd
>> > index 45aefd96688..55ca79d7ac9 100644
>> > --- a/gcc/match.pd
>> > +++ b/gcc/match.pd
>> > @@ -7848,3 +7848,18 @@ and,
>> >(if (TYPE_UNSIGNED (TREE_TYPE (@0)))
>> >  (bit_and @0 @1)
>> >(cond (le @0 @1) @0 (bit_and @0 @1))
>> > +
>> > +/* (x >= 0 ? x : 0) + (x <= 0 ? -x : 0) -> abs x.  */
>> > +(simplify
>> > +  (plus (max @0 integer_zerop) (max (negate @0) integer_zerop))
>> > +  (abs @0))
>> > +
>> > +/* (x <= 0 ? -x : 0) + (x >= 0 ? x : 0) -> abs x.  */
>> > +(simplify
>> > +  (plus (max (negate @0) integer_zerop) (max @0 integer_zerop) )
>> > +  (abs @0))
>> > +
>> > +/* (x <= 0 ? -x : 0) -> max(-x, 0).  */
>> > +(simplify
>> > + (cond (le @0 integer_zerop@1) (negate @0) integer_zerop@1)
>> > + (max (negate @0) @1))
>> > diff --git a/gcc/testsuite/gcc.c-torture/execute/pr94290-1.c 
>> > b/gcc/testsuite/gcc.c-torture/execute/pr94290-1.c
>> > new file mode 100644
>> > index 000..93b80d569aa
>> > --- /dev/null
>> > +++ b/gcc/testsuite/gcc.c-torture/execute/pr94290-1.c
>> > @@ -0,0 +1,16 @@
>> > +/* PR tree-optimization/94290 */
>> > +
>> > +#include "../../gcc.dg/pr94290.c"
>> > +
>> > +int main() {
>> > +
>> > +if (foo(0) != 0
>> > +|| foo(-42) != 42
>> > +|| foo(42) != 42
>> > +|| baz(-10) != 10
>> > +|| baz(-10) != 10) {
>> > +__builtin_abort();
>> > +}
>> > +
>> > +return 0;
>> > +}
>> > diff --git a/gcc/testsuite/gcc.dg/pr94290-2.c 
>> > b/gcc/testsuite/gcc.dg/pr94290-2.c
>> > new file mode 100644
>> > index 000..ea6e55755f5
>> > --- /dev/null
>> > +++ b/gcc/testsuite/gcc.dg/pr94290-2.c
>> > @@ -0,0 +1,15 @@
>> > +/* PR tree-optimization/94290 */
>> > +/* { dg-do compile } */
>> > +/* { dg-options "-O2 -fdump-tree-optimized" } */
>> > +
>> > +/* Form from PR.  */
>> > +__attribute__((noipa)) unsigned int foo(int x) {
>> > +return x <= 0 ? -x : 0;
>> > +}
>> > +
>> > +/* Changed order.  */
>> > +__attribute__((noipa)) 

[Bug ipa/106305] New: ICE on valid code at -O1 with -funreachable-traps: verify_cgraph_node failed

[zhendong.su at inf dot ethz.ch via Gcc-bugs]

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

Bug ID: 106305
   Summary: ICE on valid code at -O1 with -funreachable-traps:
verify_cgraph_node failed
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhendong.su at inf dot ethz.ch
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Compiler Explorer: https://godbolt.org/z/WdMsGaG3b


[525] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/13.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--prefix=/local/suz-local/software/local/gcc-trunk --enable-sanitizers
--enable-languages=c,c++ --disable-werror --enable-multilib --with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.0.0 20220714 (experimental) [master r13-1696-g29f40a8047f] (GCC) 
[526] % 
[526] % gcctk -O1 -funreachable-traps small.c
small.c:10:1: error: edge points to wrong declaration:
   10 | }
  | ^
 >
QI
size 
unit-size 
align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7f6e710c75e8
arg-types >>
volatile nothrow public external built-in decl_6 QI :0:0
align:8 warn_if_not_align:0 built-in: BUILT_IN_NORMAL:BUILT_IN_TRAP context

attributes 
chain 
chain 
chain >>>> chain
>
 Instead of: 
unit-size 
align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7f6e710b75e8 precision:32 min  max

pointer_to_this >
QI
size 
unit-size 
align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7f6e710e0498
attributes 
value >
chain 
value 
chain 
chain >>>>>
arg-types >
pointer_to_this >
addressable used public external built-in decl_3 decl_5 QI small.c:1:5
align:8 warn_if_not_align:0 built-in: BUILT_IN_NORMAL:BUILT_IN_PRINTF
context  chain >
b/4 (b) @0x7f6e71200330
  Type: function definition analyzed
  Visibility: semantic_interposition public
  next sharing asm name: 1
  References: a/0 (read) 
  Referring: 
  Function b/4 is inline copy in main/2
  Clone of b/1
  Availability: local
  Function flags: count:1073741824 (estimated locally) body local executed_once
  Called by: main/2 (inlined) (1073741824 (estimated locally),1.00 per call) 
  Calls: __builtin_trap/5 (0 (precise),0.00 per call) 
during IPA pass: inline
small.c:10:1: internal compiler error: verify_cgraph_node failed
0xa224a8 cgraph_node::verify_node()
../../gcc-trunk/gcc/cgraph.cc:3881
0xa112c4 symtab_node::verify()
../../gcc-trunk/gcc/symtab.cc:1359
0xa12507 symtab_node::verify_symtab_nodes()
../../gcc-trunk/gcc/symtab.cc:1387
0xcce301 symtab_node::checking_verify_symtab_nodes()
../../gcc-trunk/gcc/cgraph.h:682
0xcce301 symbol_table::remove_unreachable_nodes(_IO_FILE*)
../../gcc-trunk/gcc/ipa.cc:678
0xde8781 execute_todo
../../gcc-trunk/gcc/passes.cc:2159
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
[527] % 
[527] % cat small.c
int printf(const char *, ...);
char *a = "hello";
void b(int c) {
  if (c)
printf(a);
}
int main() {
  b(0);
  return 0;
}

[Bug c++/106304] New: [modules] ICE compiling dynamic_cast in constexpr function (in tree_node, at cp/module.cc:9183)

[johelegp at gmail dot com via Gcc-bugs]

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

Bug ID: 106304
   Summary: [modules] ICE compiling dynamic_cast in constexpr
function (in tree_node, at cp/module.cc:9183)
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: johelegp at gmail dot com
CC: johelegp at gmail dot com
  Target Milestone: ---

See https://godbolt.org/z/xz4Mhd8Wc, which Clang accepts:
https://godbolt.org/z/saachff5d.

mod.cpp:
```C++
export module mod;

template struct A : T {
  constexpr A(T v) : T{v} { }
  ~A() = default; // Fixes GCC.
};

struct B {
  virtual ~B() = default;
};

export inline constexpr auto x = A{B{}};

export constexpr const A* y(const B& b) {
  return dynamic_cast*>();
}
```

test.cpp:
```C++
import mod;
static_assert( == y(x));
int main() { }
```

Output:
```
[ 50%] Building CXX object CMakeFiles/mod.dir/mod.cpp.o
mod.cpp:1:8: internal compiler error: in tree_node, at cp/module.cc:9183
1 | export module mod;
  |^~
0x221f229 internal_error(char const*, ...)
???:0
0x74c10d fancy_abort(char const*, int, char const*)
???:0
0x8fd00f trees_out::tree_node(tree_node*)
???:0
0x8fde5f trees_out::core_vals(tree_node*)
???:0
0x902d6d trees_out::tree_value(tree_node*)
???:0
0x8fcf41 trees_out::tree_node(tree_node*)
???:0
0x8fde5f trees_out::core_vals(tree_node*)
???:0
0x902d6d trees_out::tree_value(tree_node*)
???:0
0x8fcf41 trees_out::tree_node(tree_node*)
???:0
0x8fde5f trees_out::core_vals(tree_node*)
???:0
0x902d6d trees_out::tree_value(tree_node*)
???:0
0x8fcf41 trees_out::tree_node(tree_node*)
???:0
0x8fde5f trees_out::core_vals(tree_node*)
???:0
0x902d6d trees_out::tree_value(tree_node*)
???:0
0x8fcf41 trees_out::tree_node(tree_node*)
???:0
0x8fde5f trees_out::core_vals(tree_node*)
???:0
0x902d6d trees_out::tree_value(tree_node*)
???:0
0x8fcf41 trees_out::tree_node(tree_node*)
???:0
0x8fde5f trees_out::core_vals(tree_node*)
???:0
0x902d6d trees_out::tree_value(tree_node*)
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.
```

Re: Adding file descriptor attribute(s) to gcc and glibc

[Paul Eggert]

On 7/14/22 08:22, David Malcolm via Libc-alpha wrote:

The analyzer now attempts to track both file descriptors and stdio
streams, so we probably need to special-case fdopen


You probably also need to special-case fileno, which goes the opposite 
direction.


If you're handling DIR *, fdopendir and dirfd would need similar treatment.

[Bug tree-optimization/106280] dom_oracle::register_transitives is expensive for deep dominator trees

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #1 from Andrew Macleod  ---
Created attachment 53300
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53300=edit
proposed patch

See if this helps.  

All of the lookup routines check to see first is there is an existing relation
for an SSA_NAME before deciding what to do.  I forgot to do that with the
transitive code.

So, this patch does 2 things. 
1) If a relation is being registered which already exist, the set routine now
returns NULL for the record as there will be no new work to do
2) IF this is a new relation, before calling register_transitives checks if
either operand was in a relation before (its just a quick bitmap check). If
neither was, there is no possibility of a transitive relation, so no need to
look.

This eliminates a lot of unnecessary work, and based on the pass times spits
out at the end, appears to save a lot of time in the various VRP passes (over
50% time reduction) in your test case.  It also makes some marginal
improvements in GCC source files compilation.

[PATCH] PR target/106278: Keep REG_EQUAL notes consistent during TImode STV.

[Roger Sayle]

This patch resolves PR target/106278 a regression on x86_64 caused by my
recent TImode STV improvements.  Now that TImode STV can handle comparisons
such as "(set (regs:CC) (compare:CC (reg:TI) ...))" the convert_insn method
sensibly checks that the mode of the SET_DEST is TImode before setting
it to V1TImode [to avoid V1TImode appearing on the hard reg CC_FLAGS.

Hence the current code looks like:

  if (GET_MODE (dst) == TImode)
{
  tmp = find_reg_equal_equiv_note (insn);
  if (tmp && GET_MODE (XEXP (tmp, 0)) == TImode)
PUT_MODE (XEXP (tmp, 0), V1TImode);
  PUT_MODE (dst, V1TImode);
  fix_debug_reg_uses (dst);
}
  break;

which checks GET_MODE (dst) before calling PUT_MODE, and when a
change is made updating the REG_EQUAL_NOTE tmp if it exists.

The logical flaw (oversight) is that due to RTL sharing, the destination
of this set may already have been updated to V1TImode, as this chain is
being converted, but we still need to update any REG_EQUAL_NOTE that
still has TImode.  Hence the correct code is actually:


  if (GET_MODE (dst) == TImode)
{
  PUT_MODE (dst, V1TImode);
  fix_debug_reg_uses (dst);
}
  if (GET_MODE (dst) == V1TImode)
{
  tmp = find_reg_equal_equiv_note (insn);
  if (tmp && GET_MODE (XEXP (tmp, 0)) == TImode)
PUT_MODE (XEXP (tmp, 0), V1TImode);
}
  break;

While fixing this behavior, I noticed I had some indentation whitespace
issues and some vestigial dead code in this function/method that I've
taken the liberty of cleaning up (as obvious) in this patch.

This patch has been tested on x86_64-pc-linux-gnu with make bootstrap
and make -k check, both with and without --target_board=unix{-m32},
with no new failures.  Ok for mainline?


2022-07-14  Roger Sayle  

gcc/ChangeLog
PR target/106278
* config/i386/i386-features.cc (general_scalar_chain::convert_insn):
Fix indentation whitespace.
(timode_scalar_chain::fix_debug_reg_uses): Likewise.
(timode_scalar_chain::convert_insn): Delete dead code.
Update TImode REG_EQUAL_NOTE even if the SET_DEST is already V1TI.
Fix indentation whitespace.
(convertible_comparison_p): Likewise.
(timode_scalar_to_vector_candidate_p): Likewise.

gcc/testsuite/ChangeLog
PR target/106278
* gcc.dg/pr106278.c: New test case.


Thanks in advance,
Roger
--

diff --git a/gcc/config/i386/i386-features.cc b/gcc/config/i386/i386-features.cc
index f1b03c3..813b203 100644
--- a/gcc/config/i386/i386-features.cc
+++ b/gcc/config/i386/i386-features.cc
@@ -1054,13 +1054,13 @@ general_scalar_chain::convert_insn (rtx_insn *insn)
   else if (REG_P (dst) && GET_MODE (dst) == smode)
 {
   /* Replace the definition with a SUBREG to the definition we
- use inside the chain.  */
+use inside the chain.  */
   rtx *vdef = defs_map.get (dst);
   if (vdef)
dst = *vdef;
   dst = gen_rtx_SUBREG (vmode, dst, 0);
   /* IRA doesn't like to have REG_EQUAL/EQUIV notes when the SET_DEST
- is a non-REG_P.  So kill those off.  */
+is a non-REG_P.  So kill those off.  */
   rtx note = find_reg_equal_equiv_note (insn);
   if (note)
remove_note (insn, note);
@@ -1246,7 +1246,7 @@ timode_scalar_chain::fix_debug_reg_uses (rtx reg)
 {
   rtx_insn *insn = DF_REF_INSN (ref);
   /* Make sure the next ref is for a different instruction,
- so that we're not affected by the rescan.  */
+so that we're not affected by the rescan.  */
   next = DF_REF_NEXT_REG (ref);
   while (next && DF_REF_INSN (next) == insn)
next = DF_REF_NEXT_REG (next);
@@ -1336,21 +1336,19 @@ timode_scalar_chain::convert_insn (rtx_insn *insn)
   rtx dst = SET_DEST (def_set);
   rtx tmp;
 
-  if (MEM_P (dst) && !REG_P (src))
-{
-  /* There are no scalar integer instructions and therefore
-temporary register usage is required.  */
-}
   switch (GET_CODE (dst))
 {
 case REG:
   if (GET_MODE (dst) == TImode)
{
+ PUT_MODE (dst, V1TImode);
+ fix_debug_reg_uses (dst);
+   }
+  if (GET_MODE (dst) == V1TImode)
+   {
  tmp = find_reg_equal_equiv_note (insn);
  if (tmp && GET_MODE (XEXP (tmp, 0)) == TImode)
PUT_MODE (XEXP (tmp, 0), V1TImode);
- PUT_MODE (dst, V1TImode);
- fix_debug_reg_uses (dst);
}
   break;
 case MEM:
@@ -1410,8 +1408,8 @@ timode_scalar_chain::convert_insn (rtx_insn *insn)
   if (MEM_P (dst))
{
  tmp = gen_reg_rtx (V1TImode);
-  emit_insn_before (gen_rtx_SET (tmp, src), insn);
-  src = tmp;
+ emit_insn_before (gen_rtx_SET (tmp, src), insn);
+ src = tmp;
}
   break;
 
@@ -1434,8 +1432,8 @@ timode_scalar_chain::convert_insn (rtx_insn *insn)
   if (MEM_P (dst))
{
  

Proposal: allow to extend C++ template argument deduction via plugins

[Dan Klishch via Gcc]

Hi,

As far as I understand the currently available plugin extension points, it is
not possible to modify template argument deduction algorithm (except the
theoretical possibility to completely override parsing step). However, such
opportunity might be beneficial for projects like libpqxx, for example, when
database schema and query text are available at compile-time, return types of
the query might be inferred by the plugin.

I propose to add something like PLUGIN_FUNCTION_CALL plugin_event which will
allow to modify function calls conditionally. Will a patch adding such
functionality be welcomed?

Thanks,
Dan Klishch

[Bug target/106303] [13 Regression] ICE on valid code at -O3 with -fno-inline-small-functions on x86_64-linux-gnu: in extract_insn, at recog.cc:2791

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

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

Andrew Pinski  changed:

   What|Removed |Added

Version|unknown |13.0
   Target Milestone|--- |13.0
Summary|ICE on valid code at -O3|[13 Regression] ICE on
   |with|valid code at -O3 with
   |-fno-inline-small-functions |-fno-inline-small-functions
   |on x86_64-linux-gnu: in |on x86_64-linux-gnu: in
   |extract_insn, at|extract_insn, at
   |recog.cc:2791   |recog.cc:2791
 Target||x86_64-linux-gnu

[Bug rtl-optimization/106303] New: ICE on valid code at -O3 with -fno-inline-small-functions on x86_64-linux-gnu: in extract_insn, at recog.cc:2791

[zhendong.su at inf dot ethz.ch via Gcc-bugs]

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

Bug ID: 106303
   Summary: ICE on valid code at -O3 with
-fno-inline-small-functions on x86_64-linux-gnu: in
extract_insn, at recog.cc:2791
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhendong.su at inf dot ethz.ch
  Target Milestone: ---

[557] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/13.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--prefix=/local/suz-local/software/local/gcc-trunk --enable-sanitizers
--enable-languages=c,c++ --disable-werror --enable-multilib --with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.0.0 20220714 (experimental) [master r13-1696-g29f40a8047f] (GCC)
[558] %
[558] % gcctk -O3 -fno-inline-small-functions small.c
small.c: In function ‘k’:
small.c:17:1: error: unrecognizable insn:
   17 | }
  | ^
(insn 55 58 66 7 (set (reg:V1TI 90 [ D.2002 ])
(mem/c:TI (symbol_ref:DI ("j") [flags 0x2] )
[2 j+0 S16 A128])) -1
 (nil))
during RTL pass: subreg3
small.c:17:1: internal compiler error: in extract_insn, at recog.cc:2791
0x722c42 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc-trunk/gcc/rtl-error.cc:108
0x722c5e _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../gcc-trunk/gcc/rtl-error.cc:116
0x721191 extract_insn(rtx_insn*)
../../gcc-trunk/gcc/recog.cc:2791
0x1d4e347 decompose_multiword_subregs
../../gcc-trunk/gcc/lower-subreg.cc:1555
0x1d4f1cd execute
../../gcc-trunk/gcc/lower-subreg.cc:1820
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
[559] %
[559] % cat small.c
struct a {
  int b;
  int c;
  int d;
  int e;
} i, j;
int f, g, h;
struct a k() {
  while (f)
i = j;
  if (g) {
for (; h; h++)
  i = j;
return j;
  }
  return i;
}
int main() {
  k();
  return 0;
}

RISC-V: Public review for Non-ISA Specification: psABI

[Kito Cheng]

We are delighted to announce the start of the public review period for psABI.

The review period begins today, 2022/07/14, and ends on 2022/08/29 (inclusive).

This Non-ISA specification is described in the PDF available at:
https://github.com/riscv-non-isa/riscv-elf-psabi-doc/releases/tag/v1.0-rc3


which was generated from the source available in the following GitHub repo:
https://github.com/riscv-non-isa/riscv-elf-psabi-doc


To respond to the public review, please either email comments to the
public isa-dev (isa-...@groups.riscv.org) mailing list or add issues
and/or pull requests (PRs) to the GitHub repo
(https://github.com/riscv-non-isa/riscv-elf-psabi-doc). We welcome all
input and appreciate your time and effort in helping us by reviewing
the specification.


During the public review period, corrections, comments, and
suggestions, will be gathered for review by the psABI Task Group. Any
minor corrections and/or uncontroversial changes will be incorporated
into the specification. Any remaining issues or proposed changes will
be addressed in the public review summary report. If there are no
issues that require incompatible changes to the public review
specification, the psABI Task Group will recommend the updated
specifications be approved and ratified by the RISC-V Technical
Steering Committee and the RISC-V Board of Directors.


Thanks to all the contributors for all their hard work.

Kito Cheng

[Bug middle-end/85620] Missing ENDBR after swapcontext

[hjl.tools at gmail dot com via Gcc-bugs]

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

--- Comment #11 from H.J. Lu  ---
Created attachment 53299
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53299=edit
A patch

[Bug target/106187] armhf: Miscompilation at O2 level (O0 / O1 are working)

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |UNCONFIRMED
 Ever confirmed|1   |0

[Bug tree-optimization/106297] stringop-overflow misbehaviour on atomic

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2022-07-14
 Ever confirmed|0   |1
 Status|UNCONFIRMED |WAITING

--- Comment #1 from Andrew Pinski  ---
Can you attach the preprocessed source as requested on
https://gcc.gnu.org/bugs/ ?

Re: [PATCH] analyzer PR 106003

[David Malcolm via Gcc]

On Thu, 2022-06-23 at 19:20 -0400, David Malcolm wrote:
> On Fri, 2022-06-24 at 00:00 +0530, Mir Immad wrote:

[...snip...]

> > +
> > +enum access_mode
> > +fd_state_machine::get_access_mode_from_flag (int flag) const
> > +{
> > +  /* FIXME: this code assumes the access modes on the host and
> > +  target are the same, which in practice might not be the
> > case. */
> 
> Thanks for moving this into a subroutine.
> 
> Joseph says we should introduce a target hook for this:
>   https://gcc.gnu.org/pipermail/gcc/2022-June/238961.html
> 
> You can see an example of adding a target hook in commit
> 8cdcea51c0fd753e6a652c9b236e91b3a6e0911c.
> 
> As noted above, I think we can leave adding the target hook until a
> followup patch, if this is only going to be an issue with cross-
> compilation between Hurd and non-Hurd systems.

FWIW, for reference, I've filed 
  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106302
about this; it strikes me that there are other flags we might
eventually want to test e.g. for mmap we'd want to look at
MAP_ANONYMOUS and the various PROT_* values.

Dave

[Bug analyzer/106302] New: RFE: provide a way for -fanalyzer to use target flags

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

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

Bug ID: 106302
   Summary: RFE: provide a way for -fanalyzer to use target flags
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
Blocks: 106003, 106301
  Target Milestone: ---

As noted in the discussion here:
  https://gcc.gnu.org/pipermail/gcc/2022-June/238954.html
-fanalyzer sometimes uses specific target flags when modeling the behavior of
functions, see e.g.: sm-fd.cc, which currently has:

enum access_mode
fd_state_machine::get_access_mode_from_flag (int flag) const
{
  /* FIXME: this code assumes the access modes on the host and
  target are the same, which in practice might not be the case. */

  if ((flag & O_ACCMODE) == O_RDONLY)
{
  return READ_ONLY;
}
  else if ((flag & O_ACCMODE) == O_WRONLY)
{
  return WRITE_ONLY;
}
  return READ_WRITE;
}

where we are using the values of O_ACCMODE, O_RDONLY, and O_WRONLY from the
host's headers, rather than those of the target.

See also bug 106301, where properly supporting mmap would mean looking at
values of MAP_ANONYMOUS, and of the various PROT_ values.

Joseph suggested adding a target hook for this, though I think we'd need an
enum for it, so that we can add various different "well known" values that we'd
want to query for on the host.  Alternatively, perhaps we could directly query
the preprocessor somehow, though that wouldn't work for the LTO case.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106003
[Bug 106003] RFE: -fanalyzer could complain about misuse of file-descriptors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106301
[Bug 106301] RFE: analyzer support of mmap

Re: Adding file descriptor attribute(s) to gcc and glibc

[David Malcolm via Gcc]

On Thu, 2022-07-14 at 09:30 +0100, Szabolcs Nagy wrote:
> The 07/13/2022 12:55, David Malcolm wrote:
> > On Wed, 2022-07-13 at 16:01 +0200, Florian Weimer wrote:
> > > * David Malcolm:
> > GCC trunk's -fanalyzer implements the new warnings via a state
> > machine
> > for file-descriptor values; it currently has rules for handling
> > "open",
> > "close", "read", and "write", and these functions are currently hard-
> > coded inside the analyzer.
> > 
> > Here are some examples on Compiler Explorer of what it can/cannot
> > detect:
> >   https://godbolt.org/z/nqPadvM4f
> > 
> > Probably the most important one IMHO is the leak detection.
> 
> nice.
> 
> > Would it be helpful to have some kind of attribute for "returns a new
> > open FD"?  Are there other ways to close a FD other than calling
> > "close" on it?  (Would converting that to some kind of "closes"
> > attribute be a good idea?)

Thanks, lots of good ideas here; I've filed various RFEs about these;
I'm posting the details below for reference.

> 
> dup2(oldfd, newfd)
> dup3(oldfd, newfd, flags)
> 
> closes newfd (and also opens it to be a dup of oldfd)
> unless the call fails.
dup and friends probably need special-casing; I've filed this as:
  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106298

> 
> close_range(first, last, flags)
close_range and closefrom would need special-casing, already filed as:
  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106283

> 
> fclose(fdopen(fd, mode))

The analyzer now attempts to track both file descriptors and stdio
streams, so we probably need to special-case fdopen to capture the
various possible interactions between these two leak detectors; I've
filed this as:
  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106299
with an implementation idea there.

> 
> but users can write all sorts of wrappers around close too.

Yeah.  If the -fanalyzer leak detectors see a value "escape" into
unknown code, then they don't report leaks; see e.g.:
  https://godbolt.org/z/n8fMhGTP5
where we don't report in test_2 about fd leaking due to the call to:

  might_close (fd);

which is extern, and so we conservatively assume that fd doesn't leak.

> 
> > 
> > Are there any other "magic" values for file-descriptors we should be
> > aware of?
> > 
> 
> mmap may require fd==-1 for anonymous maps.

mmap is its own can of worms, which I've filed as:
  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106301

You also reminded me that we need to track other ways in which the user
could obtain an fd that could leak, which I've filed as:
  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106300
(covering creat, pipe and friends, dup and friends, fcntl, and socket).


I've added all of these to the top-level RFE for -fanalyzer tracking
file descriptors:
  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=analyzer-fd

which is now a tracker-bug:
  https://gcc.gnu.org/bugzilla/showdependencytree.cgi?id=analyzer-fd


Thanks again for the ideas
Dave

Re: [GCC 12 backport] Disable generating load/store vector pairs for block copies.

[Michael Meissner via Gcc-patches]

I have applied the patch to GCC 12.

| From 22736f3d0d4fb8ce4afb3230023f8accdb03a623 Mon Sep 17 00:00:00 2001
| From: Michael Meissner 
| Date: Thu, 14 Jul 2022 11:16:08 -0400
| Subject: [PATCH] [BACKPORT] Disable generating load/store vector pairs for 
block copies.

Testing has found that using load and store vector pair for block copies
can result in a slow down on power10.  This patch disables using the
vector pair instructions for block copies if we are tuning for power10.

2022-06-11   Michael Meissner  

gcc/

* config/rs6000/rs6000.cc (rs6000_option_override_internal): Do
not generate block copies with vector pair instructions if we are
tuning for power10.  Back port from master branch.
---
 gcc/config/rs6000/rs6000.cc | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/gcc/config/rs6000/rs6000.cc b/gcc/config/rs6000/rs6000.cc
index 4030864aa1a..040487bd277 100644
--- a/gcc/config/rs6000/rs6000.cc
+++ b/gcc/config/rs6000/rs6000.cc
@@ -4151,7 +4151,10 @@ rs6000_option_override_internal (bool global_init_p)
 
   if (!(rs6000_isa_flags_explicit & OPTION_MASK_BLOCK_OPS_VECTOR_PAIR))
 {
-  if (TARGET_MMA && TARGET_EFFICIENT_UNALIGNED_VSX)
+  /* Do not generate lxvp and stxvp on power10 since there are some
+performance issues.  */
+  if (TARGET_MMA && TARGET_EFFICIENT_UNALIGNED_VSX
+ && rs6000_tune != PROCESSOR_POWER10)
rs6000_isa_flags |= OPTION_MASK_BLOCK_OPS_VECTOR_PAIR;
   else
rs6000_isa_flags &= ~OPTION_MASK_BLOCK_OPS_VECTOR_PAIR;
-- 
2.35.3


-- 
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meiss...@linux.ibm.com

Re: kernel sparse annotations vs. compiler attributes and debug_annotate_{type,decl} WAS: Re: [PATCH 0/9] Add debug_annotate attributes

[Jose E. Marchesi via Gcc-patches]

Hi Yonghong.

> On 7/7/22 1:24 PM, Jose E. Marchesi wrote:
>> Hi Yonghong.
>> 
>>> On 6/21/22 9:12 AM, Jose E. Marchesi wrote:

> On 6/17/22 10:18 AM, Jose E. Marchesi wrote:
>> Hi Yonghong.
>>
>>> On 6/15/22 1:57 PM, David Faust wrote:

 On 6/14/22 22:53, Yonghong Song wrote:
>
>
> On 6/7/22 2:43 PM, David Faust wrote:
>> Hello,
>>
>> This patch series adds support for:
>>
>> - Two new C-language-level attributes that allow to associate (to 
>> "annotate" or
>>to "tag") particular declarations and types with arbitrary 
>> strings. As
>>explained below, this is intended to be used to, for example, 
>> characterize
>>certain pointer types.
>>
>> - The conveyance of that information in the DWARF output in the form 
>> of a new
>>DIE: DW_TAG_GNU_annotation.
>>
>> - The conveyance of that information in the BTF output in the form 
>> of two new
>>kinds of BTF objects: BTF_KIND_DECL_TAG and BTF_KIND_TYPE_TAG.
>>
>> All of these facilities are being added to the eBPF ecosystem, and 
>> support for
>> them exists in some form in LLVM.
>>
>> Purpose
>> ===
>>
>> 1)  Addition of C-family language constructs (attributes) to specify 
>> free-text
>>  tags on certain language elements, such as struct fields.
>>
>>  The purpose of these annotations is to provide additional 
>> information about
>>  types, variables, and function parameters of interest to 
>> the kernel. A
>>  driving use case is to tag pointer types within the linux 
>> kernel and eBPF
>>  programs with additional semantic information, such as 
>> '__user' or '__rcu'.
>>
>>  For example, consider the linux kernel function do_execve 
>> with the
>>  following declaration:
>>
>>static int do_execve(struct filename *filename,
>>   const char __user *const __user *__argv,
>>   const char __user *const __user *__envp);
>>
>>  Here, __user could be defined with these annotations to 
>> record semantic
>>  information about the pointer parameters (e.g., they are 
>> user-provided) in
>>  DWARF and BTF information. Other kernel facilites such as 
>> the eBPF verifier
>>  can read the tags and make use of the information.
>>
>> 2)  Conveying the tags in the generated DWARF debug info.
>>
>>  The main motivation for emitting the tags in DWARF is that 
>> the Linux kernel
>>  generates its BTF information via pahole, using DWARF as a 
>> source:
>>
>>  ++  BTF  BTF   +--+
>>  | pahole |---> vmlinux.btf --->| verifier |
>>  ++ +--+
>>  ^^
>>  ||
>>DWARF |BTF |
>>  ||
>>   vmlinux  +-+
>>   module1.ko   | BPF program |
>>   module2.ko   +-+
>> ...
>>
>>  This is because:
>>
>>  a)  Unlike GCC, LLVM will only generate BTF for BPF 
>> programs.
>>
>>  b)  GCC can generate BTF for whatever target with -gbtf, 
>> but there is no
>>  support for linking/deduplicating BTF in the linker.
>>
>>  In the scenario above, the verifier needs access to the 
>> pointer tags of
>>  both the kernel types/declarations (conveyed in the DWARF 
>> and translated
>>  to BTF by pahole) and those of the BPF program (available 
>> directly in BTF).
>>
>>  Another motivation for having the tag information in DWARF, 
>> unrelated to
>>  BPF and BTF, is that the drgn project (another DWARF 
>> consumer) also wants
>>  to benefit from these tags in order to differentiate 
>> between different
>>  kinds of pointers in the kernel.
>>
>> 3)  Conveying the tags in the generated BTF debug info.

[Bug analyzer/106301] RFE: analyzer support of mmap

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

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

--- Comment #1 from David Malcolm  ---
Potentially we could also track the allocated region, and complain if it is
leaked.  I think this would require handling of mmap/munmap in sm-malloc.cc (so
that we can detect leaks), and support in the region-model code for
memory-mapped regions (for aliasing support)

[Bug analyzer/106301] New: RFE: analyzer support of mmap

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

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

Bug ID: 106301
   Summary: RFE: analyzer support of mmap
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
Blocks: 106003
  Target Milestone: ---

Now that the analyzer can track uses of file-descriptors, we may want to
special-case mmap:
  https://www.man7.org/linux/man-pages/man2/mmap.2.html

  void *mmap(void *addr, size_t length, int prot, int flags,
 int fd, off_t offset);

If (flags & MAP_ANONYMOUS) is false, then "fd" is required to be an open file
descriptor (and the access direction must match that expressed by "prot").

If (flags & MAP_ANONYMOUS) is true, then some implementations require "fd" to
be -1.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106003
[Bug 106003] RFE: -fanalyzer could complain about misuse of file-descriptors

[Bug analyzer/106300] New: RFE: analyzer support for more ways of obtaining an open file descriptor

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

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

Bug ID: 106300
   Summary: RFE: analyzer support for more ways of obtaining an
open file descriptor
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
Blocks: 106003
  Target Milestone: ---

Currently -fanalyzer special-cases "open" for obtaining a possibly-open file
descriptor (in sm-fd.cc).

We should probably support other ways of obtaining possibly-open file
descriptors, either by special-casing them, or via some new attribute:

creat()
  https://www.man7.org/linux/man-pages/man3/creat.3p.html

pipe() and friends:
  int pipe(int pipefd[2]);
  int pipe2(int pipefd[2], int flags);
  https://www.man7.org/linux/man-pages/man2/pipe.2.html

dup() and friends
  covered in bug 106298

fcntl()
  https://man7.org/linux/man-pages/man2/fcntl.2.html
  (though that's probably a deep rabbit-hole that we may not want to go down)

socket()
  https://www.man7.org/linux/man-pages/man3/socket.3p.html
  See also bug 106140.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106003
[Bug 106003] RFE: -fanalyzer could complain about misuse of file-descriptors

[Bug analyzer/106299] New: RFE: analyzer handling of fdopen

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

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

Bug ID: 106299
   Summary: RFE: analyzer handling of fdopen
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
Blocks: 106003
  Target Milestone: ---

Now that the analyzer supports checking both filedescriptor *and* FILE * usage,
we should probably add special-case handling of fdopen:

  https://www.man7.org/linux/man-pages/man3/fdopen.3p.html

I'm not quite sure how to model the interaction between the two state machines;
perhaps a successful fdopen on a fd should transition the fd from an open state
to the "stop" state (i.e. stop tracking state on this fd), and transition the
FILE * from the start state to the open state.

See also bug 101550, which has an example of using fdopen.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106003
[Bug 106003] RFE: -fanalyzer could complain about misuse of file-descriptors

[Bug analyzer/106298] New: RFE: analyzer handling of dup, dup2, and dup3

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

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

Bug ID: 106298
   Summary: RFE: analyzer handling of dup, dup2, and dup3
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
Blocks: 106003
  Target Milestone: ---

Now that -fanalyzer has warnings for file descriptors (especially leaks), we
should probably special-case the following functions (rather than attempt to
express them via attributes):

 int dup(int oldfd);
 int dup2(int oldfd, int newfd);
 int dup3(int oldfd, int newfd, int flags);

https://man7.org/linux/man-pages/man2/dup.2.html


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106003
[Bug 106003] RFE: -fanalyzer could complain about misuse of file-descriptors

[Bug analyzer/106286] fd_diagnostic should implement get_meaning_for_state_change vfunc

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

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

--- Comment #1 from David Malcolm  ---
Compare with e.g.:
  gcc/testsuite/gcc.dg/analyzer/file-meaning-1.c
which tests this for the sm-file.cc

Re: Creating a wrapper around a function at compile time

[Erick Ochoa via Gcc]

On Thu, 14 Jul 2022 at 16:10, Martin Liška  wrote:

> On 7/14/22 16:08, Erick Ochoa via Gcc wrote:
> > Last time I checked, value profiling can only track a single value per
> > statement.
>
> Hi.
>
> Take a look at HIST_TYPE_INDIR_CALL which we use for tracking at maximum 32
> (#define GCOV_TOPN_MAXIMUM_TRACKED_VALUES 32) and we use for indirect call
> speculative calls which you can see for instance here:
>
> ./gcc/testsuite/g++.dg/tree-prof/indir-call-prof.C
>

Thanks Martin,

I'll give it a read. However, I have mis-spoken. If my understanding is
correct: multiple values are tracked, but only the values of a single
variable/expression per statement are tracked. That means that for a gcall
(which is a single statement and) which has n argument expressions, I
believe that the naive way to track all argument expressions is not
possible without extending how histograms are associated to statements.
Perhaps canonicalizing how callsites work (i.e., only variables are allowed
as arguments in call sites and then associating a histogram to the
definition of the variables being used in call sites) would be enough, but
I haven't given it much thought for the consequences that might follow from
this.


>
> Cheers,
> Martin
>

[Bug c++/106086] ICE: trying to capture 'this' in instantiation of generic lambda

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

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

Patrick Palka  changed:

   What|Removed |Added

   Last reconfirmed||2022-07-14
 Status|UNCONFIRMED |NEW
 CC||ppalka at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Patrick Palka  ---
Reduced C++17 ICE-on-valid testcase:

template
struct foo {
  int operator()(...) const;
};

template
struct bar : foo {
  auto operator()() const {
return [&](auto x) {
  return foo::operator()(decltype(x){});
};
  }
};

bar b;
int i = b()(0);

Re: Creating a wrapper around a function at compile time

[Martin Liška]

On 7/14/22 16:08, Erick Ochoa via Gcc wrote:
> Last time I checked, value profiling can only track a single value per
> statement.

Hi.

Take a look at HIST_TYPE_INDIR_CALL which we use for tracking at maximum 32
(#define GCOV_TOPN_MAXIMUM_TRACKED_VALUES 32) and we use for indirect call
speculative calls which you can see for instance here:

./gcc/testsuite/g++.dg/tree-prof/indir-call-prof.C

Cheers,
Martin

Re: [PATCH] match.pd: Add new abs pattern [PR94290]

[Sam Feifer via Gcc-patches]

On Wed, Jul 13, 2022 at 3:36 PM Andrew Pinski  wrote:

> On Wed, Jul 13, 2022 at 12:26 PM Sam Feifer via Gcc-patches
>  wrote:
> >
> > This patch is intended to fix a missed optimization in match.pd. It
> optimizes (x >= 0 ? x : 0) + (x <= 0 ? -x : 0) to just abs(x). I had to
> write a second simplification in match.pd to handle the commutative
> property as the match was not ocurring otherwise. Additionally, the pattern
> (x <= 0 ? -x : 0) now gets optimized to max(-x, 0), which helps with the
> other simplification rule.
>
> You could use :c for the commutative property instead and that should
> simplify things.
> That is:
>
> (simplify
>   (plus:c (max @0 integer_zerop) (max (negate @0) integer_zerop))
>   (abs @0))
>
> Also since integer_zerop works on vectors, it seems like you should
> add a testcase or two for the vector case.
> Also would be useful if you write a testcase that uses different
> statements rather than one big one so it gets exercised in the
> forwprop case.
> Note also if either of the max are used more than just in this
> simplification, it could increase the lifetime of @0, maybe you need
> to add :s to the max expressions.
>
>
Thanks for the feedback. I'm not quite sure what a vector test case would
look like for this. Could I get some guidance on that?

Thanks
-Sam


> Thanks,
> Andrew
>
> >
> > Tests are also included to be added to the testsuite.
> >
> > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> >
> > PR tree-optimization/94290
> >
> > gcc/ChangeLog:
> >
> > * match.pd (x >= 0 ? x : 0) + (x <= 0 ? -x : 0): New
> simplification.
> > * match.pd (x <= 0 ? -x : 0): New Simplification.
> >
> > gcc/testsuite/ChangeLog:
> >
> > * gcc.c-torture/execute/pr94290-1.c: New test.
> > * gcc.dg/pr94290-2.c: New test.
> > * gcc.dg/pr94290.c: New test.
> > ---
> >  gcc/match.pd  | 15 ++
> >  .../gcc.c-torture/execute/pr94290-1.c | 16 +++
> >  gcc/testsuite/gcc.dg/pr94290-2.c  | 15 ++
> >  gcc/testsuite/gcc.dg/pr94290.c| 46 +++
> >  4 files changed, 92 insertions(+)
> >  create mode 100644 gcc/testsuite/gcc.c-torture/execute/pr94290-1.c
> >  create mode 100644 gcc/testsuite/gcc.dg/pr94290-2.c
> >  create mode 100644 gcc/testsuite/gcc.dg/pr94290.c
> >
> > diff --git a/gcc/match.pd b/gcc/match.pd
> > index 45aefd96688..55ca79d7ac9 100644
> > --- a/gcc/match.pd
> > +++ b/gcc/match.pd
> > @@ -7848,3 +7848,18 @@ and,
> >(if (TYPE_UNSIGNED (TREE_TYPE (@0)))
> >  (bit_and @0 @1)
> >(cond (le @0 @1) @0 (bit_and @0 @1))
> > +
> > +/* (x >= 0 ? x : 0) + (x <= 0 ? -x : 0) -> abs x.  */
> > +(simplify
> > +  (plus (max @0 integer_zerop) (max (negate @0) integer_zerop))
> > +  (abs @0))
> > +
> > +/* (x <= 0 ? -x : 0) + (x >= 0 ? x : 0) -> abs x.  */
> > +(simplify
> > +  (plus (max (negate @0) integer_zerop) (max @0 integer_zerop) )
> > +  (abs @0))
> > +
> > +/* (x <= 0 ? -x : 0) -> max(-x, 0).  */
> > +(simplify
> > + (cond (le @0 integer_zerop@1) (negate @0) integer_zerop@1)
> > + (max (negate @0) @1))
> > diff --git a/gcc/testsuite/gcc.c-torture/execute/pr94290-1.c
> b/gcc/testsuite/gcc.c-torture/execute/pr94290-1.c
> > new file mode 100644
> > index 000..93b80d569aa
> > --- /dev/null
> > +++ b/gcc/testsuite/gcc.c-torture/execute/pr94290-1.c
> > @@ -0,0 +1,16 @@
> > +/* PR tree-optimization/94290 */
> > +
> > +#include "../../gcc.dg/pr94290.c"
> > +
> > +int main() {
> > +
> > +if (foo(0) != 0
> > +|| foo(-42) != 42
> > +|| foo(42) != 42
> > +|| baz(-10) != 10
> > +|| baz(-10) != 10) {
> > +__builtin_abort();
> > +}
> > +
> > +return 0;
> > +}
> > diff --git a/gcc/testsuite/gcc.dg/pr94290-2.c
> b/gcc/testsuite/gcc.dg/pr94290-2.c
> > new file mode 100644
> > index 000..ea6e55755f5
> > --- /dev/null
> > +++ b/gcc/testsuite/gcc.dg/pr94290-2.c
> > @@ -0,0 +1,15 @@
> > +/* PR tree-optimization/94290 */
> > +/* { dg-do compile } */
> > +/* { dg-options "-O2 -fdump-tree-optimized" } */
> > +
> > +/* Form from PR.  */
> > +__attribute__((noipa)) unsigned int foo(int x) {
> > +return x <= 0 ? -x : 0;
> > +}
> > +
> > +/* Changed order.  */
> > +__attribute__((noipa)) unsigned int bar(int x) {
> > +return 0 >= x ? -x : 0;
> > +}
> > +
> > +/* { dg-final {scan-tree-dump-times " MAX_EXPR " 2 "optimized" } } */
> > diff --git a/gcc/testsuite/gcc.dg/pr94290.c
> b/gcc/testsuite/gcc.dg/pr94290.c
> > new file mode 100644
> > index 000..47617c36c02
> > --- /dev/null
> > +++ b/gcc/testsuite/gcc.dg/pr94290.c
> > @@ -0,0 +1,46 @@
> > +/* PR tree-optimization/94290 */
> > +/* { dg-do compile } */
> > +/* { dg-options "-O2 -fdump-tree-optimized" } */
> > +
> > +
> > +/* Same form as PR.  */
> > +__attribute__((noipa)) unsigned int foo(int x) {
> > +return (x >= 0 ? x : 0) + (x <= 0 ? -x : 0);
> > +}
> > +
> > +/* Signed function.  */
> > 

[Bug rtl-optimization/105041] '-fcompare-debug' failure w/ -mcpu=power6 -O2 -fharden-compares -frename-registers

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

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

--- Comment #10 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Surya Kumari Jangala
:

https://gcc.gnu.org/g:0380d008b1474373852fd2fc921886491304f854

commit r12-8568-g0380d008b1474373852fd2fc921886491304f854
Author: Surya Kumari Jangala 
Date:   Fri Jun 10 19:52:57 2022 +0530

regrename: Fix -fcompare-debug issue in check_new_reg_p [PR105041]

In check_new_reg_p, the nregs of a du chain is computed by obtaining the
MODE of the first element in the chain, and then calling
hard_regno_nregs() with the MODE. But the first element of the chain can
be a DEBUG_INSN whose mode need not be the same as the rest of the
elements in the du chain. This was resulting in fcompare-debug failure
as check_new_reg_p was returning a different result with -g for the same
candidate register. We can instead obtain nregs from the du chain
itself.

2022-06-10  Surya Kumari Jangala  

gcc/
PR rtl-optimization/105041
* regrename.cc (check_new_reg_p): Use nregs value from du chain.

gcc/testsuite/
PR rtl-optimization/105041
* gcc.target/powerpc/pr105041.c: New test.

(cherry picked from commit 3e16b4359e86b36676ed01219e6deafa95f3c16b)

[Bug c/106297] New: stringop-overflow misbehaviour on atomic

[chipitsine at gmail dot com via Gcc-bugs]

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

Bug ID: 106297
   Summary: stringop-overflow misbehaviour on atomic
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chipitsine at gmail dot com
  Target Milestone: ---

repro steps

git clone https://github.com/haproxy/haproxy
cd haproxy

export CC=/path/to/gcc
make CC=$CC ERR=1 TARGET=linux-glibc 

error reported:

src/haproxy.c: In function ‘run_poll_loop’:
include/haproxy/atomic.h:428:39: error: ‘__atomic_load_8’ writing 8 bytes into
a region of size 0 overflows the destination [-Werror=stringop-overflow=]
  428 | #define _HA_ATOMIC_LOAD(val)  __atomic_load_n(val,
__ATOMIC_RELAXED)
  |  
^~
src/haproxy.c:2843:46: note: in expansion of macro ‘_HA_ATOMIC_LOAD’
 2843 | if
((_HA_ATOMIC_LOAD(_tgroup_ctx[i].stopping_threads) &
ha_tgroup_info[i].threads_enabled) !=
  |  ^~~
compilation terminated due to -Wfatal-errors.




error was reviewed by Willy Tarreau in
https://github.com/haproxy/haproxy/issues/1767 and it is considered as false
positive.

I bisected gcc, breaking change is:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=88b504b7a8c5affb0ffa97990d22af2b199e36ed

Re: Creating a wrapper around a function at compile time

[Erick Ochoa via Gcc]

On Thu, 14 Jul 2022 at 15:51, Richard Biener 
wrote:

> With a value-profile it would be per call site and IPA-CP can use that
> to direct the cloning.  I'm not sure how many
> values a value histogram can track reliably here.
>

Last time I checked, value profiling can only track a single value per
statement. So that would need to be augmented if we wanted to specialize
for more than one parameter. However, this can also be a bad idea. Because
even if parameters a and b are quasi-constants, perhaps the cross product a
x b follows a more uniform distribution. This means that optimizing on a or
on b might be a good idea but optimizing on a x b is a bad idea. (There is
still some work to be done defining when specializing is a good idea or
not). Also, I do not believe that value profiling profiles arguments?
According to the comments only values regarding division and/or
indirect/virtual call specialization are tracked during value profiling.

However, even if value profiling would be a great addition to this, I would
like to explore the transformation independent of value profiling. There
are some heuristics that could be used, for example looking at the
callsites which do have constant arguments and which optimizations are
enabled by those constants.

You mention that: "IPA-CP can use that to direct the cloning". Can you
elaborate a bit further? I guess the idea here is augmenting ipa-cp with a
list of "likely values" and extend the infrastructure which deals with
speculation to support arguments. Am I following correctly? Any other
suggestions?

Re: Creating a wrapper around a function at compile time

[Richard Biener via Gcc]

On Thu, Jul 14, 2022 at 3:42 PM Erick Ochoa  wrote:
>
> Hi Richard,
>
>
>> >
>> > So instead of wrapping the function why not transform the original function
>> > to have a prologue doing a runtime check for the compile-time specialized
>> > versions and perform tail-calls to them?
>> >
>> > What I'm missing is who would call mul_test_param in your case?
>
>
> The idea is that all callsites to mul may call instead mul_test_param or only 
> those for which there is no known compile time constant. If we had some more 
> information about the distribution of the parameter values at runtime, then 
> we could even choose not to use the wrapper.
>
>>
>> Following your variant more closely would be doing value profiling
>> of function parameters and then "speculative IPA-CP".
>
>
> Yes, the idea of doing value profiling on function parameters certainly fits 
> this very well. I refrained from calling it "speculative IPA-CP" and instead 
> called it specialization with a parameter test but the idea I think is the 
> same. However, the main difference between "speculative IPA-CP" and this idea 
> is that (if I understand correctly how speculative IPA-CP works) is that 
> instead of changing the callsite C to the following version:
>
> C: mul_test_param (c, d);
>
> speculative IPA-CP will have the transformation
>
> C: if (a == 2) mul.constprop1 (a)
> else if (a == 4) mul.constprop2 (a)
> else mul (a, b)
>
> Which depending on how many non compile-time constant callsites there are, 
> will increase the size of the binary. That's why I prefer the wrapper around 
> the function. But this would be essentially inlining the wrapper.

With a value-profile it would be per call site and IPA-CP can use that
to direct the cloning.  I'm not sure how many
values a value histogram can track reliably here.

>
> As of now, the only "speculative IPA-CP" that I've seen is the speculation on 
> the target of the indirect edge. I could look into exactly how this mechanism 
> works to try to instead speculate on an arbitrary argument. Do you think that 
> would be a good first step instead of creating a wrapper and replacing the 
> edges to the wrapper?

Re: Creating a wrapper around a function at compile time

[Erick Ochoa via Gcc]

Hi Richard,


>
> > So instead of wrapping the function why not transform the original
> function
> > to have a prologue doing a runtime check for the compile-time specialized
> > versions and perform tail-calls to them?
> >
> > What I'm missing is who would call mul_test_param in your case?
>

The idea is that all callsites to mul may call instead mul_test_param or
only those for which there is no known compile time constant. If we had
some more information about the distribution of the parameter values at
runtime, then we could even choose not to use the wrapper.


> Following your variant more closely would be doing value profiling
> of function parameters and then "speculative IPA-CP".
>

Yes, the idea of doing value profiling on function parameters certainly
fits this very well. I refrained from calling it "speculative IPA-CP" and
instead called it specialization with a parameter test but the idea I think
is the same. However, the main difference between "speculative IPA-CP" and
this idea is that (if I understand correctly how speculative IPA-CP works)
is that instead of changing the callsite C to the following version:

C: mul_test_param (c, d);

speculative IPA-CP will have the transformation

C: if (a == 2) mul.constprop1 (a)
else if (a == 4) mul.constprop2 (a)
else mul (a, b)

Which depending on how many non compile-time constant callsites there are,
will increase the size of the binary. That's why I prefer the wrapper
around the function. But this would be essentially inlining the wrapper.

As of now, the only "speculative IPA-CP" that I've seen is the speculation
on the target of the indirect edge. I could look into exactly how this
mechanism works to try to instead speculate on an arbitrary argument. Do
you think that would be a good first step instead of creating a wrapper and
replacing the edges to the wrapper?

[PATCH] libstdc++: Make __from_chars_alnum_to_val conversion explicit

[Marco Falke via Gcc-patches]

>From 2d4e7cd1d476a065d824e11045c8dbc049d5f0a0 Mon Sep 17 00:00:00 2001
From: MacroFake 
Date: Thu, 14 Jul 2022 15:26:12 +0200
Subject: [PATCH] libstdc++: Make __from_chars_alnum_to_val conversion explicit

The optimizations from commit a54137c88061c7495728fc6b8dfd0474e812b2cb
introduced a clang integer sanitizer error.

Fix this with an explicit static_cast, similar to the fix in commit
074436cf8cdd2a9ce75cadd36deb8301f00e55b9.

libstdc++-v3/ChangeLog:

* include/std/charconv (__from_chars_alnum_to_val): Replace
  implicit conversions from int to unsigned char with explicit
  casts.
---
 libstdc++-v3/include/std/charconv | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libstdc++-v3/include/std/charconv
b/libstdc++-v3/include/std/charconv
index 218813e4797..bdf23e4a5ad 100644
--- a/libstdc++-v3/include/std/charconv
+++ b/libstdc++-v3/include/std/charconv
@@ -436,7 +436,7 @@ namespace __detail
 __from_chars_alnum_to_val(unsigned char __c)
 {
   if _GLIBCXX17_CONSTEXPR (_DecOnly)
-return __c - '0';
+   return static_cast(__c - '0');
   else
 {
   // This initializer is deliberately made dependent in order to work
-- 
2.35.3
From 2d4e7cd1d476a065d824e11045c8dbc049d5f0a0 Mon Sep 17 00:00:00 2001
From: MacroFake 
Date: Thu, 14 Jul 2022 15:26:12 +0200
Subject: [PATCH] libstdc++: Make __from_chars_alnum_to_val conversion explicit

The optimizations from commit a54137c88061c7495728fc6b8dfd0474e812b2cb
introduced a clang integer sanitizer error.

Fix this with an explicit static_cast, similar to the fix in commit
074436cf8cdd2a9ce75cadd36deb8301f00e55b9.

libstdc++-v3/ChangeLog:

* include/std/charconv (__from_chars_alnum_to_val): Replace
  implicit conversions from int to unsigned char with explicit
  casts.
---
 libstdc++-v3/include/std/charconv | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libstdc++-v3/include/std/charconv b/libstdc++-v3/include/std/charconv
index 218813e4797..bdf23e4a5ad 100644
--- a/libstdc++-v3/include/std/charconv
+++ b/libstdc++-v3/include/std/charconv
@@ -436,7 +436,7 @@ namespace __detail
 __from_chars_alnum_to_val(unsigned char __c)
 {
   if _GLIBCXX17_CONSTEXPR (_DecOnly)
-	return __c - '0';
+   return static_cast(__c - '0');
   else
 	{
 	  // This initializer is deliberately made dependent in order to work
-- 
2.35.3

[Bug libstdc++/106296] Consider using fsync or fdatasync in filesystem::copy_file

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

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

--- Comment #1 from Jonathan Wakely  ---
However, see https://github.com/boostorg/filesystem/issues/186

[Bug libstdc++/106296] New: Consider using fsync or fdatasync in filesystem::copy_file

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

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

Bug ID: 106296
   Summary: Consider using fsync or fdatasync in
filesystem::copy_file
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

Writing the file to disk might be slow and could be interrupted by a signal. If
we don't flush explicitly, it will happen when closing the file descriptor, but
if that's interrupted by a signal we don't know if the file was closed or not.

Consider using fsync to flush the data explicitly, looping on EINTR, so that
there's nothing more to do when closing the file.

Re: Creating a wrapper around a function at compile time

[Richard Biener via Gcc]

On Thu, Jul 14, 2022 at 3:27 PM Richard Biener
 wrote:
>
> On Thu, Jul 14, 2022 at 2:35 PM Erick Ochoa via Gcc  wrote:
> >
> > Hello,
> >
> > I'm looking for some help in how to create a new function at compile time /
> > link time. The idea is an alternative form of constant propagation.
> >
> > The current implementation of ipa-cp, may specialize functions for which
> > arguments may be known at compile time. Call graph edges from the caller to
> > the new specialized functions will replace the old call graph edges from
> > the caller to the original functions. Call graph edges which have no known
> > compile time constants will still point to the original unspecialized
> > function.
> >
> > I would like to explore a different approach to function specialization.
> > Instead of only specializing functions which are guaranteed to have a
> > compile time constant, I would like to also attempt to specialize the edges
> > which do not have compile time constants with a parameter test. In other
> > words, for call graph edges with non-constant arguments at compile time,
> > create a wrapper function around the original function and do a switch
> > statement around parameters.
> >
> > For example, let's say we have a function mul, which multiplies two
> > integers.
> >
> > int
> > mul (int a, int b) {
> >   return a * b;
> > }
> >
> > Function mul is called from three different callsites in the whole program:
> >
> > A: mul (a, 2);
> > B: mul (b, 4);
> > C: mul (c, d);
> >
> > At the moment, ipa-cp might specialize mul into 3 different versions:
> >
> > // unoptimized original mul
> > int
> > mul (int a, int b) {
> >   return a * b;
> > }
> >
> > // optimized for b = 2;
> > int
> > mul.constprop1 (int a) {
> >   // DEBUG b => 2
> >   return a << 1;
> > }
> >
> > // optimized for b = 4;
> > int
> > mul.constprop2 (int a) {
> >   // DEBUG b => 4
> >   return a << 2;
> > }
> >
> > and change the callsites to:
> >
> > A: mul.constprop1 (a);
> > B: mul.constprop2 (b);
> > C: mul (c, d);
> >
> > I would like instead to do the following:
> >
> > Create a function mul_test_param
> >
> > int
> > mul_test_param (int a, int b) {
> >   switch (b)
> >   {
> > case 2:
> >   return mul.constprop1 (a);
> >   break;
> > case 4:
> >   return mul.constprop2 (a);
> >   break;
> > default:
> >   return mul (a, b);
> >   break;
> >   }
> > }
> >
> > The function mul_test_param will test each parameter and then call the
> > specialized function. The callsites can either be changed to:
> >
> > A: mul.constprop1 (a);
> > B: mul.constprop2 (b);
> > C: mul_test_param (c, d);
> >
> > or
> >
> > A: mul_test_param (a, 2);
> > B: mul_test_param (b, 4);
> > C: mul_test_param (c, d);
> >
> > The idea is that there exist some class of functions for which the
> > parameter test and the specialized version is less expensive than the
> > original function version. And if, at runtime, d might be a quasi-constant
> > with a good likelihood of being either 2 or 4, then it makes sense to have
> > this parameter test.
> >
> > This is very similar to function tests for making direct to indirect
> > functions and to what could be done in value profiling.
> >
> > I already know how to achieve most of this, but I have never created a
> > function from scratch. That is the bit that is challenging to me at the
> > moment. Any help is appreciated.
>
> So instead of wrapping the function why not transform the original function
> to have a prologue doing a runtime check for the compile-time specialized
> versions and perform tail-calls to them?
>
> What I'm missing is who would call mul_test_param in your case?

Following your variant more closely would be doing value profiling
of function parameters and then "speculative IPA-CP".

Richard.

> >
> > Thanks!
> >
> > -Erick

Re: Creating a wrapper around a function at compile time

[Richard Biener via Gcc]

On Thu, Jul 14, 2022 at 2:35 PM Erick Ochoa via Gcc  wrote:
>
> Hello,
>
> I'm looking for some help in how to create a new function at compile time /
> link time. The idea is an alternative form of constant propagation.
>
> The current implementation of ipa-cp, may specialize functions for which
> arguments may be known at compile time. Call graph edges from the caller to
> the new specialized functions will replace the old call graph edges from
> the caller to the original functions. Call graph edges which have no known
> compile time constants will still point to the original unspecialized
> function.
>
> I would like to explore a different approach to function specialization.
> Instead of only specializing functions which are guaranteed to have a
> compile time constant, I would like to also attempt to specialize the edges
> which do not have compile time constants with a parameter test. In other
> words, for call graph edges with non-constant arguments at compile time,
> create a wrapper function around the original function and do a switch
> statement around parameters.
>
> For example, let's say we have a function mul, which multiplies two
> integers.
>
> int
> mul (int a, int b) {
>   return a * b;
> }
>
> Function mul is called from three different callsites in the whole program:
>
> A: mul (a, 2);
> B: mul (b, 4);
> C: mul (c, d);
>
> At the moment, ipa-cp might specialize mul into 3 different versions:
>
> // unoptimized original mul
> int
> mul (int a, int b) {
>   return a * b;
> }
>
> // optimized for b = 2;
> int
> mul.constprop1 (int a) {
>   // DEBUG b => 2
>   return a << 1;
> }
>
> // optimized for b = 4;
> int
> mul.constprop2 (int a) {
>   // DEBUG b => 4
>   return a << 2;
> }
>
> and change the callsites to:
>
> A: mul.constprop1 (a);
> B: mul.constprop2 (b);
> C: mul (c, d);
>
> I would like instead to do the following:
>
> Create a function mul_test_param
>
> int
> mul_test_param (int a, int b) {
>   switch (b)
>   {
> case 2:
>   return mul.constprop1 (a);
>   break;
> case 4:
>   return mul.constprop2 (a);
>   break;
> default:
>   return mul (a, b);
>   break;
>   }
> }
>
> The function mul_test_param will test each parameter and then call the
> specialized function. The callsites can either be changed to:
>
> A: mul.constprop1 (a);
> B: mul.constprop2 (b);
> C: mul_test_param (c, d);
>
> or
>
> A: mul_test_param (a, 2);
> B: mul_test_param (b, 4);
> C: mul_test_param (c, d);
>
> The idea is that there exist some class of functions for which the
> parameter test and the specialized version is less expensive than the
> original function version. And if, at runtime, d might be a quasi-constant
> with a good likelihood of being either 2 or 4, then it makes sense to have
> this parameter test.
>
> This is very similar to function tests for making direct to indirect
> functions and to what could be done in value profiling.
>
> I already know how to achieve most of this, but I have never created a
> function from scratch. That is the bit that is challenging to me at the
> moment. Any help is appreciated.

So instead of wrapping the function why not transform the original function
to have a prologue doing a runtime check for the compile-time specialized
versions and perform tail-calls to them?

What I'm missing is who would call mul_test_param in your case?

>
> Thanks!
>
> -Erick