[Bug rtl-optimization/106590] [12/13 Regression] x86-64 miscompilation starting with r12-8233-g1ceddd7497e15d w/ mtune=skylake

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

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

--- Comment #5 from Andrew Pinski  ---
Created attachment 53442
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53442=edit
testcase that should be ready for gcc.c-torture/execute

[Bug rtl-optimization/106590] [12/13 Regression] x86-64 miscompilation starting with r12-8233-g1ceddd7497e15d w/ mtune=skylake

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

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

--- Comment #4 from Andrew Pinski  ---
So the IR is slightly different entering CE1. The two BB for the sides of the
if are swapped. But that is the only difference.

This is definitely a latent bug that got exposed, it is not the first latent
bug in CE1 recently either.

[Bug rtl-optimization/106590] [12/13 Regression] x86-64 miscompilation starting with r12-8233-g1ceddd7497e15d w/ mtune=skylake

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2022-08-12
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
  Component|target  |rtl-optimization

--- Comment #3 from Andrew Pinski  ---
CE goes bad:
IF-CASE-2 found, start 6, else 8
verify found no changes in insn with uid = 35.
changing bb of uid 5
  from 8 to 6
deleting block 8
Conversion succeeded on pass 1.

[Bug target/106590] [12/13 Regression] x86-64 miscompilation starting with "i386: Improve ix86_expand_int_movcc" w/ mtune=skylake

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

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

--- Comment #2 from Andrew Pinski  ---
r12-8233-g1ceddd7497e15d

[Bug target/106590] [12/13 Regression] x86-64 miscompilation starting with "i386: Improve ix86_expand_int_movcc" w/ mtune=skylake

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |12.2

[Bug target/106590] x86-64 miscompilation starting with "i386: Improve ix86_expand_int_movcc" w/ mtune=skylake

[andres at anarazel dot de via Gcc-bugs]

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

--- Comment #1 from Andres Freund  ---
Created attachment 53441
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53441=edit
reproducer

[Bug target/106590] New: x86-64 miscompilation starting with "i386: Improve ix86_expand_int_movcc" w/ mtune=skylake

[andres at anarazel dot de via Gcc-bugs]

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

Bug ID: 106590
   Summary: x86-64 miscompilation starting with "i386: Improve
ix86_expand_int_movcc" w/ mtune=skylake
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andres at anarazel dot de
  Target Milestone: ---

Hi,

The attached reproducer shows a miscompilation I found building postgres. I've
bisected postgres' failure to 1ceddd7497e, but it's of course possible it's
just surfacing a prior issue.

In my reproducer, and in postgres, the problem only occurs with -mtune=skylake
or higher, but I'm not sure how related that actually is.

$ /home/andres/build/gcc-master/install/bin/gcc --version
gcc (GCC) 12.0.1 20220423 (experimental)
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ gcc-11 --version
gcc-11 (Debian 11.3.0-5) 11.3.0
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ /home/andres/build/gcc-master/install/bin/gcc -Wall -Wextra -O1
-mtune=skylake /tmp/test.i -o /tmp/test
$ /tmp/test
wrong results: procform->prorettype: 23, restype: 20

$ /home/andres/build/gcc-master/install/bin/gcc -Wall -Wextra -O1
-mtune=broadwell /tmp/test.i -o /tmp/test
$ /tmp/test
everything ok: procform->prorettype: 23, restype: 23

$ gcc-11 -Wall -Wextra -O1 -mtune=skylake /tmp/test.i -o /tmp/test
$ /tmp/test
everything ok: procform->prorettype: 23, restype: 23

I think it's pretty obvious that the code should never be able to result in
restype == 20.

Regards,

Andres

[Bug libstdc++/106589] visit rejects lambdas that do not return void

[hewillk at gmail dot com via Gcc-bugs]

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

--- Comment #1 from 康桓瑋  ---
variant#L1730:

  if constexpr (sizeof...(_Variants) == 0)
return std::forward<_Visitor>(__visitor)();

In this branch, we seem to need to detect if _Result_type is void and
explicitly cast the return type to void.

[Bug libstdc++/106589] New: visit rejects lambdas that do not return void

[hewillk at gmail dot com via Gcc-bugs]

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

Bug ID: 106589
   Summary: visit rejects lambdas that do not return void
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hewillk at gmail dot com
  Target Milestone: ---

#include 

int main() {
  std::visit([]{ return 0; });
}

https://godbolt.org/z/G3Penchbx

[Bug target/99888] Add powerpc ELFv2 support for -fpatchable-function-entry*

[amodra at gmail dot com via Gcc-bugs]

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

--- Comment #8 from Alan Modra  ---
(In reply to Segher Boessenkool from comment #7)
> '-fpatchable-function-entry=N[,M]'
>  Generate N NOPs right at the beginning of each function, with the
>  function entry point before the Mth NOP.

Bad doco.  Should be "after the Mth NOP" I think.  Or better written to avoid
the concept of a 0th nop.  Default for M is zero, placing all nops after the
function entry and before normal function prologue code.

> The nops have to be consecutive.

I hope you are making this statement based on an analysis of the purpose of
having M nops before the entry point and N-M after the entry point, because the
documentation you are quoting doesn't take into account the fact that ELFv2
functions have two entry points.  We don't have "the" entry point.

I admit I didn't analyse -fpatchable-function-entry usage in any depth before
writing the patches in PR98125.  All I did was look at the linux kernel to the
point of deciding that we want a patchable area after the local entry point to
catch all calls to the function.  That would be what
-fpatchable-function-entry=n does for ELFv2, and I think we all agree on that.

Why would someone want nops before a function entry?  Perhaps as space for a
pointer.  Or perhaps as the main patch area branched to from patched code after
the entry, to limit number of nops executed in an unpatched function.  Or
perhaps so that the function can be called by a trampoline or via function
pointer, to select either some extra code replacing those nops or the normal
function entry.  I think that means M nops go before the global entry point. 
(Note that the patch area before a function could well duplicate the normal
global entry code.)

I agree with comment #5.  nops *inside* the global entry code are a daft idea.

[Bug middle-end/102316] Unexpected stringop-overflow Warnings on POWER CPU

[sergiodj at sergiodj dot net via Gcc-bugs]

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

Sergio Durigan Junior  changed:

   What|Removed |Added

 CC||sergiodj at sergiodj dot net

--- Comment #3 from Sergio Durigan Junior  ---
I can confirm this bug.  We're facing the problem when compiling NSS on Ubuntu
Kinetic (development version) on ppc64el, because the build uses -O3.

[Bug middle-end/106016] [PowerPC] crash with attempt to initialize array of MMA accumulators

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

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

Peter Bergner  changed:

   What|Removed |Added

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

--- Comment #14 from Peter Bergner  ---
Fixed everywhere.

[Bug middle-end/106016] [PowerPC] crash with attempt to initialize array of MMA accumulators

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

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

--- Comment #13 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Peter Bergner
:

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

commit r11-10201-gdf8567535a1f3eaa20b700be62374b2fb4f09204
Author: Peter Bergner 
Date:   Fri Jun 17 23:43:23 2022 -0500

c: Handle initializations of opaque types [PR106016]

The initial commit that added opaque types thought that there couldn't
be any valid initializations for variables of these types, but the test
case in the bug report shows that isn't true.  The solution is to handle
OPAQUE_TYPE initializations like the other scalar types.

2022-06-17  Peter Bergner  

gcc/
PR c/106016
* expr.c (count_type_elements): Handle OPAQUE_TYPE.

gcc/testsuite/
PR c/106016
* gcc.target/powerpc/pr106016.c: New test.

(cherry picked from commit 975658b782f36dcf6eb190966d5b705977bfd5eb)

[Bug target/106586] riscv32 still broke with zba_zbb_zbc_zbs, ICE in do_SUBST in C++ code

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

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

--- Comment #8 from Andrew Pinski  ---
(In reply to jiawei from comment #7)
> I had roll back the RISC-V commit and found that this modification cause
> this building failure.
> 
> https://gcc.gnu.org/git/?p=gcc.git;a=blobdiff;f=gcc/config/riscv/riscv.h;
> h=6f7f4d3fbdcfa6c8ca03604fbe5817aad6278e2e;
> hp=5083a1c24b08233810dd3b2aa4278b3ef8a75791;
> hb=4e72ccad80d69a76d149fba59603b8173fffe8fe;
> hpb=d19b4342c19e5a7fd84888aa06ebc106438d0c46
> 
> But I am not sure what's wrong with it, any suggestions?

Yes the problem is a bit complex, the problem is representation of INT_MIN is
sign extended (always) and HOST_WIDE_INT is always 64bit.
Anyways the fix is to improve the predicate to be correct and fix the
constraints too. I am working towards that but I am doing some other cleanups
along the way to the backend so the riscv backend looks more like a modern
backend.

[Bug target/106586] riscv32 still broke with zba_zbb_zbc_zbs, ICE in do_SUBST in C++ code

[jiawei at iscas dot ac.cn via Gcc-bugs]

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

jiawei  changed:

   What|Removed |Added

 CC||jiawei at iscas dot ac.cn

--- Comment #7 from jiawei  ---
I had roll back the RISC-V commit and found that this modification cause this
building failure.

https://gcc.gnu.org/git/?p=gcc.git;a=blobdiff;f=gcc/config/riscv/riscv.h;h=6f7f4d3fbdcfa6c8ca03604fbe5817aad6278e2e;hp=5083a1c24b08233810dd3b2aa4278b3ef8a75791;hb=4e72ccad80d69a76d149fba59603b8173fffe8fe;hpb=d19b4342c19e5a7fd84888aa06ebc106438d0c46

But I am not sure what's wrong with it, any suggestions?

[Bug c/90885] GCC should warn about 2^16 and 2^32 and 2^64 [-Wxor-used-as-pow]

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

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

David Malcolm  changed:

   What|Removed |Added

   Keywords||patch
 Status|ASSIGNED|WAITING

--- Comment #26 from David Malcolm  ---
I implemented a better version of the patch; I've posted it for review here:
  https://gcc.gnu.org/pipermail/gcc-patches/2022-August/599609.html

[PATCH] c/c++: new warning: -Wxor-used-as-pow [PR90885]

[David Malcolm via Gcc-patches]

PR c/90885 notes various places in real-world code where people have
written C/C++ code that uses ^ (exclusive or) where presumbably they
meant exponentiation.

For example
  https://codesearch.isocpp.org/cgi-bin/cgi_ppsearch?q=2%5E32=Search
currently finds 11 places using "2^32", and all of them appear to be
places where the user means 2 to the power of 32, rather than 2
exclusive-orred with 32 (which is 34).

This patch adds a new -Wxor-used-as-pow warning to the C and C++
frontends to complain about ^ when the left-hand side is the decimal
constant 2 or the decimal constant 10.

This is the same name as the corresponding clang warning:
  https://clang.llvm.org/docs/DiagnosticsReference.html#wxor-used-as-pow

As per the clang warning, the warning suggests converting the left-hand
side to a hexadecimal constant if you really mean xor, which suppresses
the warning (and this patch implements a fix-it hint for that, whereas
the clang implementation only has a fix-it hint for the initial
suggestion of exponentiation).

I initially tried implementing this without checking for decimals, but
this version had lots of false positives.  Checking for decimals
requires extending the lexer to capture whether or not a CPP_NUMBER
token was decimal.  I added a new DECIMAL_INT flag to cpplib.h for this.
Unfortunately, c_token and cp_tokens both have only an unsigned char for
their flags (as captured by c_lex_with_flags), whereas this would add
the 12th flag to cpp_tokens.  Of the first 8 flags, all but BOL are used
in the C or C++ frontends, but BOL is not, so I moved that to a higher
position, using its old value for the new DECIMAL_INT flag, so that it
is representable within an unsigned char.

Example output:

demo.c:5:13: warning: result of '2^8' is 10; did you mean '1 << 8' (256)? 
[-Wxor-used-as-pow]
5 | int t2_8 = 2^8;
  | ^
  |--
  |1<<
demo.c:5:12: note: you can silence this warning by using a hexadecimal constant 
(0x2 rather than 2)
5 | int t2_8 = 2^8;
  |^
  |0x2
demo.c:21:15: warning: result of '10^6' is 12; did you mean '1e6'? 
[-Wxor-used-as-pow]
   21 | int t10_6 = 10^6;
  |   ^
  | ---
  | 1e
demo.c:21:13: note: you can silence this warning by using a hexadecimal 
constant (0xa rather than 10)
   21 | int t10_6 = 10^6;
  | ^~
  | 0xa

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.

OK for trunk?

Thanks
Dave


gcc/c-family/ChangeLog:
PR c/90885
* c-common.h (check_for_xor_used_as_pow): New decl.
* c-lex.cc (c_lex_with_flags): Add DECIMAL_INT to flags as appropriate.
* c-warn.cc (check_for_xor_used_as_pow): New.
* c.opt (Wxor-used-as-pow): New.

gcc/c/ChangeLog:
PR c/90885
* c-parser.cc (c_parser_string_literal): Clear ret.m_decimal.
(c_parser_expr_no_commas): Likewise.
(c_parser_conditional_expression): Likewise.
(c_parser_binary_expression): Clear m_decimal when popping the
stack.
(c_parser_unary_expression): Clear ret.m_decimal.
(c_parser_has_attribute_expression): Likewise for result.
(c_parser_predefined_identifier): Likewise for expr.
(c_parser_postfix_expression): Likewise for expr.
Set expr.m_decimal when handling a CPP_NUMBER that was a decimal
token.
* c-tree.h (c_expr::m_decimal): New bitfield.
* c-typeck.cc (parser_build_binary_op): Clear result.m_decimal.
(parser_build_binary_op): Call check_for_xor_used_as_pow.

gcc/cp/ChangeLog:
PR c/90885
* cp-tree.h (class cp_expr): Add bitfield m_decimal.  Clear it in
existing ctors.  Add ctor that allows specifying its value.
(cp_expr::decimal_p): New accessor.
* parser.cc (cp_parser_expression_stack_entry::flags): New field.
(cp_parser_primary_expression): Set m_decimal of cp_expr when
handling numbers.
(cp_parser_binary_expression): Extract flags from token when
populating stack.  Call check_for_xor_used_as_pow.

gcc/ChangeLog:
PR c/90885
* doc/invoke.texi (Warning Options): Add -Wxor-used-as-pow.

gcc/testsuite/ChangeLog:
PR c/90885
* c-c++-common/Wxor-used-as-pow-1.c: New test.
* c-c++-common/Wxor-used-as-pow-fixits.c: New test.
* g++.dg/parse/expr3.C: Convert 2 to 0x2 to suppress
-Wxor-used-as-pow.
* g++.dg/warn/Wparentheses-10.C: Likewise.
* g++.dg/warn/Wparentheses-18.C: Likewise.
* g++.dg/warn/Wparentheses-19.C: Likewise.
* g++.dg/warn/Wparentheses-9.C: Likewise.
* g++.dg/warn/Wxor-used-as-pow-named-op.C: New test.
* gcc.dg/Wparentheses-6.c: Convert 2 to 0x2 to suppress
-Wxor-used-as-pow.
* gcc.dg/Wparentheses-7.c: Likewise.
* gcc.dg/precedence-1.c: Likewise.

libcpp/ChangeLog:
PR c/90885
* 

[COMMITTED] [AARCH64] Remove reference to MD_INCLUDES

[apinski--- via Gcc-patches]

From: Andrew Pinski 

The comment reference to MD_INCLUDES is not needed
as it is auto generated for long time now even before
aarch64 target was added.

MD_INCLUDES has been auto generated since r0-64489.
Note some targets still manually set MD_INCLUDES and
I suspect those can be changed but I don't have access
to those targets.

Committed as obvious.

Thanks,
Andrew Pinski

gcc/ChangeLog:

* config/aarch64/aarch64.md: Remove comment
about MD_INCLUDES as it is out of date and not needed.
---
 gcc/config/aarch64/aarch64.md | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
index ef0aed25c6b..3ea16dbc255 100644
--- a/gcc/config/aarch64/aarch64.md
+++ b/gcc/config/aarch64/aarch64.md
@@ -347,9 +347,6 @@ (define_constants
; must not operate on inactive inputs if doing so could induce a fault.
(SVE_STRICT_GP 1)])
 
-;; If further include files are added the defintion of MD_INCLUDES
-;; must be updated.
-
 (include "constraints.md")
 (include "predicates.md")
 (include "iterators.md")
-- 
2.17.1

[Bug middle-end/106016] [PowerPC] crash with attempt to initialize array of MMA accumulators

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

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

--- Comment #12 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Peter Bergner
:

https://gcc.gnu.org/g:6aaaf20ee4ad9c85f3099ef425720547644fb08d

commit r12-8682-g6aaaf20ee4ad9c85f3099ef425720547644fb08d
Author: Peter Bergner 
Date:   Fri Jun 17 23:43:23 2022 -0500

c: Handle initializations of opaque types [PR106016]

The initial commit that added opaque types thought that there couldn't
be any valid initializations for variables of these types, but the test
case in the bug report shows that isn't true.  The solution is to handle
OPAQUE_TYPE initializations like the other scalar types.

2022-06-17  Peter Bergner  

gcc/
PR c/106016
* expr.cc (count_type_elements): Handle OPAQUE_TYPE.

gcc/testsuite/
PR c/106016
* gcc.target/powerpc/pr106016.c: New test.

(cherry picked from commit 975658b782f36dcf6eb190966d5b705977bfd5eb)

Re: [PATCH 1/1 v2] c++/106423: Fix pragma suppression of -Wc++20-compat diagnostics.

[Jason Merrill via Gcc-patches]

Sorry for the delay, I'm travelling with limited internet. I will commit it
early next week if no one beats me to it.

On Thu, Aug 11, 2022, 2:45 PM Tom Honermann via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:

> If there are no further concerns, could a C++ or libcpp maintainer
> please commit this for me?
>
> Thank you!
>
> Tom.
>
> On 8/4/22 12:42 PM, Tom Honermann via Gcc-patches wrote:
> > Are there any further concerns with this patch? If not, I extend my
> > gratitude to anyone so kind as to commit this for me as I don't have
> > commit access.
> >
> > I just noticed that I neglected to add a ChangeLog entry for the
> > comment addition to gcc/cp/parser.cc. Noted inline below. I can
> > re-send the patch with that update if desired.
> >
> > Tom.
> >
> > On 8/1/22 2:49 PM, Tom Honermann wrote:
> >> Gcc's '#pragma GCC diagnostic' directives are processed in "early mode"
> >> (see handle_pragma_diagnostic_early) for the C++ frontend and, as such,
> >> require that the target diagnostic option be enabled for the
> >> preprocessor
> >> (see c_option_is_from_cpp_diagnostics).  This change modifies the
> >> -Wc++20-compat option definition to register it as a preprocessor option
> >> so that its associated diagnostics can be suppressed.  The changes also
> >> implicitly disable the option in C++20 and later modes.  These changes
> >> are consistent with the definition of the -Wc++11-compat option.
> >>
> >> This support is motivated by the need to suppress the following
> >> diagnostic
> >> otherwise issued in C++17 and earlier modes due to the char8_t typedef
> >> present in the uchar.h header file in glibc 2.36.
> >>warning: identifier ‘char8_t’ is a keyword in C++20 [-Wc++20-compat]
> >>
> >> Tests are added to validate suppression of both -Wc++11-compat and
> >> -Wc++20-compat related diagnostics (fixes were only needed for the C++20
> >> case).
> >>
> >> Fixeshttps://gcc.gnu.org/PR106423.
> >>
> >> gcc/c-family/ChangeLog:
> >> * c-opts.cc (c_common_post_options): Disable -Wc++20-compat
> >> diagnostics
> >> in C++20 and later.
> >> * c.opt (Wc++20-compat): Enable hooks for the preprocessor.
> >
> > gcc/cp/ChangeLog:
> > * parser.cc (cp_lexer_saving_tokens): Add comment regarding
> > diagnostic requirements.
> >
> >>
> >> gcc/testsuite/ChangeLog:
> >> * g++.dg/cpp0x/keywords2.C: New test.
> >> * g++.dg/cpp2a/keywords2.C: New test.
> >>
> >> libcpp/ChangeLog:
> >> * include/cpplib.h (cpp_warning_reason): Add CPP_W_CXX20_COMPAT.
> >> * init.cc (cpp_create_reader): Add cpp_warn_cxx20_compat.
> >> ---
> >>   gcc/c-family/c-opts.cc |  7 +++
> >>   gcc/c-family/c.opt |  2 +-
> >>   gcc/cp/parser.cc   |  5 -
> >>   gcc/testsuite/g++.dg/cpp0x/keywords2.C | 16 
> >>   gcc/testsuite/g++.dg/cpp2a/keywords2.C | 13 +
> >>   libcpp/include/cpplib.h|  4 
> >>   libcpp/init.cc |  1 +
> >>   7 files changed, 46 insertions(+), 2 deletions(-)
> >>   create mode 100644 gcc/testsuite/g++.dg/cpp0x/keywords2.C
> >>   create mode 100644 gcc/testsuite/g++.dg/cpp2a/keywords2.C
> >>
> >> diff --git a/gcc/c-family/c-opts.cc b/gcc/c-family/c-opts.cc
> >> index b9f01a65ed7..1ea37ba9742 100644
> >> --- a/gcc/c-family/c-opts.cc
> >> +++ b/gcc/c-family/c-opts.cc
> >> @@ -1046,6 +1046,13 @@ c_common_post_options (const char **pfilename)
> >> else if (warn_narrowing == -1)
> >>   warn_narrowing = 0;
> >>   +  if (cxx_dialect >= cxx20)
> >> +{
> >> +  /* Don't warn about C++20 compatibility changes in C++20 or
> >> later.  */
> >> +  warn_cxx20_compat = 0;
> >> +  cpp_opts->cpp_warn_cxx20_compat = 0;
> >> +}
> >> +
> >> /* C++17 has stricter evaluation order requirements; let's use
> >> some of them
> >>for earlier C++ as well, so chaining works as expected. */
> >> if (c_dialect_cxx ()
> >> diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
> >> index 44e1a60ce24..dfdebd596ef 100644
> >> --- a/gcc/c-family/c.opt
> >> +++ b/gcc/c-family/c.opt
> >> @@ -455,7 +455,7 @@ Wc++2a-compat
> >>   C++ ObjC++ Warning Alias(Wc++20-compat) Undocumented
> >> Wc++20-compat
> >> -C++ ObjC++ Var(warn_cxx20_compat) Warning LangEnabledBy(C++
> >> ObjC++,Wall)
> >> +C++ ObjC++ Var(warn_cxx20_compat) Warning LangEnabledBy(C++
> >> ObjC++,Wall) Init(0) CPP(cpp_warn_cxx20_compat)
> >> CppReason(CPP_W_CXX20_COMPAT)
> >>   Warn about C++ constructs whose meaning differs between ISO C++
> >> 2017 and ISO C++ 2020.
> >> Wc++11-extensions
> >> diff --git a/gcc/cp/parser.cc b/gcc/cp/parser.cc
> >> index 4f67441eeb1..c3584446827 100644
> >> --- a/gcc/cp/parser.cc
> >> +++ b/gcc/cp/parser.cc
> >> @@ -924,7 +924,10 @@ cp_lexer_saving_tokens (const cp_lexer* lexer)
> >>   /* Store the next token from the preprocessor in *TOKEN. Return true
> >>  if we reach EOF.  If LEXER is NULL, assume we are handling an
> >>  initial #pragma 

[Bug c++/101976] When constructing object, calling function and performing co_await in same statement, temporary is erroneously moved trivially

[dprokoptsev at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Dmitry Prokoptsev  ---
I believe I stumbled on this one as well -- see
https://godbolt.org/z/or31cz6eW, although it's not as trivial as the snippet
provided here.

Reproduces in 10.3 and all subsequent versions.

Re: [PATCH 1/1 v2] c++/106423: Fix pragma suppression of -Wc++20-compat diagnostics.

[Tom Honermann via Gcc-patches]

If there are no further concerns, could a C++ or libcpp maintainer 
please commit this for me?


Thank you!

Tom.

On 8/4/22 12:42 PM, Tom Honermann via Gcc-patches wrote:
Are there any further concerns with this patch? If not, I extend my 
gratitude to anyone so kind as to commit this for me as I don't have 
commit access.


I just noticed that I neglected to add a ChangeLog entry for the 
comment addition to gcc/cp/parser.cc. Noted inline below. I can 
re-send the patch with that update if desired.


Tom.

On 8/1/22 2:49 PM, Tom Honermann wrote:

Gcc's '#pragma GCC diagnostic' directives are processed in "early mode"
(see handle_pragma_diagnostic_early) for the C++ frontend and, as such,
require that the target diagnostic option be enabled for the 
preprocessor

(see c_option_is_from_cpp_diagnostics).  This change modifies the
-Wc++20-compat option definition to register it as a preprocessor option
so that its associated diagnostics can be suppressed.  The changes also
implicitly disable the option in C++20 and later modes.  These changes
are consistent with the definition of the -Wc++11-compat option.

This support is motivated by the need to suppress the following 
diagnostic

otherwise issued in C++17 and earlier modes due to the char8_t typedef
present in the uchar.h header file in glibc 2.36.
   warning: identifier ‘char8_t’ is a keyword in C++20 [-Wc++20-compat]

Tests are added to validate suppression of both -Wc++11-compat and
-Wc++20-compat related diagnostics (fixes were only needed for the C++20
case).

Fixeshttps://gcc.gnu.org/PR106423.

gcc/c-family/ChangeLog:
* c-opts.cc (c_common_post_options): Disable -Wc++20-compat 
diagnostics

in C++20 and later.
* c.opt (Wc++20-compat): Enable hooks for the preprocessor.


gcc/cp/ChangeLog:
    * parser.cc (cp_lexer_saving_tokens): Add comment regarding 
diagnostic requirements.




gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/keywords2.C: New test.
* g++.dg/cpp2a/keywords2.C: New test.

libcpp/ChangeLog:
* include/cpplib.h (cpp_warning_reason): Add CPP_W_CXX20_COMPAT.
* init.cc (cpp_create_reader): Add cpp_warn_cxx20_compat.
---
  gcc/c-family/c-opts.cc |  7 +++
  gcc/c-family/c.opt |  2 +-
  gcc/cp/parser.cc   |  5 -
  gcc/testsuite/g++.dg/cpp0x/keywords2.C | 16 
  gcc/testsuite/g++.dg/cpp2a/keywords2.C | 13 +
  libcpp/include/cpplib.h    |  4 
  libcpp/init.cc |  1 +
  7 files changed, 46 insertions(+), 2 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/cpp0x/keywords2.C
  create mode 100644 gcc/testsuite/g++.dg/cpp2a/keywords2.C

diff --git a/gcc/c-family/c-opts.cc b/gcc/c-family/c-opts.cc
index b9f01a65ed7..1ea37ba9742 100644
--- a/gcc/c-family/c-opts.cc
+++ b/gcc/c-family/c-opts.cc
@@ -1046,6 +1046,13 @@ c_common_post_options (const char **pfilename)
    else if (warn_narrowing == -1)
  warn_narrowing = 0;
  +  if (cxx_dialect >= cxx20)
+    {
+  /* Don't warn about C++20 compatibility changes in C++20 or 
later.  */

+  warn_cxx20_compat = 0;
+  cpp_opts->cpp_warn_cxx20_compat = 0;
+    }
+
    /* C++17 has stricter evaluation order requirements; let's use 
some of them

   for earlier C++ as well, so chaining works as expected. */
    if (c_dialect_cxx ()
diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
index 44e1a60ce24..dfdebd596ef 100644
--- a/gcc/c-family/c.opt
+++ b/gcc/c-family/c.opt
@@ -455,7 +455,7 @@ Wc++2a-compat
  C++ ObjC++ Warning Alias(Wc++20-compat) Undocumented
    Wc++20-compat
-C++ ObjC++ Var(warn_cxx20_compat) Warning LangEnabledBy(C++ 
ObjC++,Wall)
+C++ ObjC++ Var(warn_cxx20_compat) Warning LangEnabledBy(C++ 
ObjC++,Wall) Init(0) CPP(cpp_warn_cxx20_compat) 
CppReason(CPP_W_CXX20_COMPAT)
  Warn about C++ constructs whose meaning differs between ISO C++ 
2017 and ISO C++ 2020.

    Wc++11-extensions
diff --git a/gcc/cp/parser.cc b/gcc/cp/parser.cc
index 4f67441eeb1..c3584446827 100644
--- a/gcc/cp/parser.cc
+++ b/gcc/cp/parser.cc
@@ -924,7 +924,10 @@ cp_lexer_saving_tokens (const cp_lexer* lexer)
  /* Store the next token from the preprocessor in *TOKEN. Return true
 if we reach EOF.  If LEXER is NULL, assume we are handling an
 initial #pragma pch_preprocess, and thus want the lexer to return
-   processed strings.  */
+   processed strings.
+
+   Diagnostics issued from this function must have their controlling 
option (if
+   any) in c.opt annotated as a libcpp option via the CppReason 
property.  */

    static void
  cp_lexer_get_preprocessor_token (unsigned flags, cp_token *token)
diff --git a/gcc/testsuite/g++.dg/cpp0x/keywords2.C 
b/gcc/testsuite/g++.dg/cpp0x/keywords2.C

new file mode 100644
index 000..d67d01e31ed
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/keywords2.C
@@ -0,0 +1,16 @@
+// { dg-do compile { target c++98_only } }
+// { dg-options "-Wc++11-compat" }
+
+// Validate suppression of -Wc++11-compat 

gcc-10-20220811 is now available

[GCC Administrator via Gcc]

Snapshot gcc-10-20220811 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/10-20220811/
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 60580e350c1a20459dd4726284fef848dd512d08

You'll find:

 gcc-10-20220811.tar.xz   Complete GCC

  SHA256=3c1284ce32d6dead25b3ad8f52f857787ea7eae5d6c09ac525110fe10e087bd3
  SHA1=2e5ce0f6dbea9d500ea2c2ad8a20d0fe6e693fe2

Diffs from 10-20220804 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: [PATCH v2] c-family: Honor -Wno-init-self for cv-qual vars [PR102633]

[Jason Merrill via Gcc-patches]

On 8/8/22 12:06, Marek Polacek wrote:

On Sat, Aug 06, 2022 at 03:29:05PM -0700, Jason Merrill wrote:

On 7/26/22 14:31, Marek Polacek wrote:

On Tue, Jul 26, 2022 at 04:24:18PM -0400, Jason Merrill wrote:

On 7/26/22 15:03, Marek Polacek wrote:

Since r11-5188-g32934a4f45a721, we drop qualifiers during l-to-r
conversion by creating a NOP_EXPR.  For e.g.

 const int i = i;

that means that the DECL_INITIAL is '(int) i' and not 'i' anymore.
Consequently, we don't suppress_warning here:

711 case DECL_EXPR:
715   if (VAR_P (DECL_EXPR_DECL (*expr_p))
716   && !DECL_EXTERNAL (DECL_EXPR_DECL (*expr_p))
717   && !TREE_STATIC (DECL_EXPR_DECL (*expr_p))
718   && (DECL_INITIAL (DECL_EXPR_DECL (*expr_p)) == DECL_EXPR_DECL 
(*expr_p))
719   && !warn_init_self)
720 suppress_warning (DECL_EXPR_DECL (*expr_p), OPT_Winit_self);

because of the check on line 718 -- (int) i is not i.  So -Wno-init-self
doesn't disable the warning as it's supposed to.

The following patch fixes it...except it doesn't, for volatile variables
in C++.  The problem is that for

 volatile int k = k;

we see that the initializer has TREE_SIDE_EFFECTS, so we perform dynamic
initialization.  So there's no DECL_INITIAL and the suppress_warning
call above is never done.  I suppose we could amend get_no_uninit_warning
to return true for volatile-qualified expressions.  I mean, can we ever
say for a fact that a volatile variable is uninitialized?

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

PR middle-end/102633

gcc/c-family/ChangeLog:

* c-gimplify.cc (c_gimplify_expr): Strip NOPs of DECL_INITIAL.


I wonder if we want to handle this i = i case earlier, like in finish_decl.


I could, something like

@@ -5381,7 +5381,14 @@ finish_decl (tree decl, location_t init_loc, tree init,
   init = NULL_TREE;

 if (init)
-store_init_value (init_loc, decl, init, origtype);
+{
+  /* In the self-init case, undo the artificial NOP_EXPR we may have
+added in convert_lvalue_to_rvalue so that c_gimplify_expr/DECL_EXPR
+can perform suppress_warning.  */
+  if (TREE_CODE (init) == NOP_EXPR && TREE_OPERAND (init, 0) == decl)
+   init = TREE_OPERAND (init, 0);
+  store_init_value (init_loc, decl, init, origtype);
+}

but then I'd have to do the same thing in cp_finish_decl because
decay_conversion also adds a NOP_EXPR for cv-qualified non-class prvalues.
Is that what we want?  To me that seems less clean than having c_gimplify_expr
see through NOP_EXPRs.


I was thinking of checking the form of the initializer before
decay_conversion or anything else messes with it, and calling
suppress_warning at that point instead of in c_gimplify_expr.


Aaah, okay.  Here's a patch that does it.  In the C FE it has to
happen really early.  Now both front ends behave the same wrt volatiles!

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


LGTM.


-- >8 --
Since r11-5188-g32934a4f45a721, we drop qualifiers during l-to-r
conversion by creating a NOP_EXPR.  For e.g.

   const int i = i;

that means that the DECL_INITIAL is '(int) i' and not 'i' anymore.
Consequently, we don't suppress_warning here:

711 case DECL_EXPR:
715   if (VAR_P (DECL_EXPR_DECL (*expr_p))
716   && !DECL_EXTERNAL (DECL_EXPR_DECL (*expr_p))
717   && !TREE_STATIC (DECL_EXPR_DECL (*expr_p))
718   && (DECL_INITIAL (DECL_EXPR_DECL (*expr_p)) == DECL_EXPR_DECL 
(*expr_p))
719   && !warn_init_self)
720 suppress_warning (DECL_EXPR_DECL (*expr_p), OPT_Winit_self);

because of the check on line 718 -- (int) i is not i.  So -Wno-init-self
doesn't disable the warning as it's supposed to.

The following patch fixes it by moving the suppress_warning call from
c_gimplify_expr to the front ends, at points where we haven't created
the NOP_EXPR yet.

PR middle-end/102633

gcc/c-family/ChangeLog:

* c-gimplify.cc (c_gimplify_expr) : Don't call
suppress_warning here.

gcc/c/ChangeLog:

* c-parser.cc (c_parser_initializer): Add new tree parameter.  Use it.
Call suppress_warning.
(c_parser_declaration_or_fndef): Pass d down to c_parser_initializer.
(c_parser_omp_declare_reduction): Pass omp_priv down to
c_parser_initializer.

gcc/cp/ChangeLog:

* decl.cc (cp_finish_decl): Call suppress_warning.

gcc/testsuite/ChangeLog:

* c-c++-common/Winit-self1.c: New test.
* c-c++-common/Winit-self2.c: New test.
---
  gcc/c-family/c-gimplify.cc   | 12 -
  gcc/c/c-parser.cc| 19 ---
  gcc/cp/decl.cc   |  8 ++
  gcc/testsuite/c-c++-common/Winit-self1.c | 31 
  gcc/testsuite/c-c++-common/Winit-self2.c | 31 
  5 files changed, 85 insertions(+), 16 deletions(-)
  create mode 100644 gcc/testsuite/c-c++-common/Winit-self1.c
  create mode 100644 

Re: [PATCH v2] c++: Extend -Wpessimizing-move for class prvalues [PR106276]

[Jason Merrill via Gcc-patches]

On 8/8/22 12:27, Marek Polacek wrote:

On Sat, Aug 06, 2022 at 04:07:54PM -0700, Jason Merrill wrote:

On 8/6/22 15:49, Jason Merrill wrote:

On 7/27/22 17:14, Marek Polacek wrote:

We already have a warning that warns about pessimizing std::move
in a return statement, when it prevents the NRVO:

    T fn()
    {
  T t;
  return std::move (t); // warning \o/
    }

However, the warning doesn't warn when what we are returning is a class
prvalue, that is, when std::move prevents the RVO:

    T fn()
    {
  T t;
  return std::move (T{}); // no warning :-(
    }

This came up recently in GCC:
.

This patch fixes that.  I would like to extend the warning further, so
that it warns in more contexts, e.g.:

    T t = std::move(T());

or

    void foo (T);
    foo (std::move(T()));

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

 PR c++/106276

gcc/cp/ChangeLog:

 * typeck.cc (can_do_rvo_p): New.
 (maybe_warn_pessimizing_move): Warn when moving a temporary object
 in a return statement prevents copy elision.

gcc/testsuite/ChangeLog:

 * g++.dg/cpp0x/Wpessimizing-move7.C: New test.
---
   gcc/cp/typeck.cc  | 31 -
   .../g++.dg/cpp0x/Wpessimizing-move7.C | 63 +++
   2 files changed, 91 insertions(+), 3 deletions(-)
   create mode 100644 gcc/testsuite/g++.dg/cpp0x/Wpessimizing-move7.C

diff --git a/gcc/cp/typeck.cc b/gcc/cp/typeck.cc
index 6e4f23af982..9500c4e2fe8 100644
--- a/gcc/cp/typeck.cc
+++ b/gcc/cp/typeck.cc
@@ -10287,12 +10287,29 @@ can_do_nrvo_p (tree retval, tree functype)
     /* The cv-unqualified type of the returned value must be the
    same as the cv-unqualified return type of the
    function.  */
-  && same_type_p ((TYPE_MAIN_VARIANT (TREE_TYPE (retval))),
-  (TYPE_MAIN_VARIANT (functype)))
+  && same_type_p (TYPE_MAIN_VARIANT (TREE_TYPE (retval)),
+  TYPE_MAIN_VARIANT (functype))
     /* And the returned value must be non-volatile.  */
     && !TYPE_VOLATILE (TREE_TYPE (retval)));
   }
+/* Like can_do_nrvo_p, but we check if we're trying to move a class
+   prvalue.  */
+
+static bool
+can_do_rvo_p (tree retval, tree functype)
+{
+  if (functype == error_mark_node)
+    return false;
+  if (retval)
+    STRIP_ANY_LOCATION_WRAPPER (retval);
+  return (retval != NULL_TREE
+  && TREE_CODE (retval) == TARGET_EXPR


Maybe use !glvalue_p instead of specifically checking for TARGET_EXPR? I
don't feel strongly about this.


OK, this version uses !glvalue_p.


+  && same_type_p (TYPE_MAIN_VARIANT (TREE_TYPE (retval)),
+  TYPE_MAIN_VARIANT (functype))
+  && !TYPE_VOLATILE (TREE_TYPE (retval)));
+}
+
   /* If we should treat RETVAL, an expression being returned, as if
it were
  designated by an rvalue, returns it adjusted accordingly;
otherwise, returns
  NULL_TREE.  See [class.copy.elision].  RETURN_P is true if this
is a return
@@ -10401,12 +10418,20 @@ maybe_warn_pessimizing_move (tree retval,
tree functype)
     "prevents copy elision"))
   inform (loc, "remove % call");
   }
+  else if (can_do_rvo_p (arg, functype))
+    {
+  auto_diagnostic_group d;
+  if (warning_at (loc, OPT_Wpessimizing_move,
+  "moving a temporary object in a return statement "
+  "prevents copy elision"))


It doesn't just prevent copy elision, it produces a dangling reference.
  This is a special case of the warning we talked about passing a
temporary to a function that returns a reference argument unchanged, and
should probably use a different warning flag.


Wait, no, I'm confused, the temporary does live long enough to get copied.

I still don't think we want to suppress this warning in the other patch.


Yeah, that makes sense.  I'll change it there.

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


OK.


-- >8 --
We already have a warning that warns about pessimizing std::move
in a return statement, when it prevents the NRVO:

   T fn()
   {
 T t;
 return std::move (t); // warning \o/
   }

However, the warning doesn't warn when what we are returning is a class
prvalue, that is, when std::move prevents the RVO:

   T fn()
   {
 T t;
 return std::move (T{}); // no warning :-(
   }

This came up recently in GCC:
.

This patch fixes that.  I would like to extend the warning further, so
that it warns in more contexts, e.g.:

   T t = std::move(T());

or

   void foo (T);
   foo (std::move(T()));

PR c++/106276

gcc/cp/ChangeLog:

* typeck.cc (can_do_rvo_p): New.
(maybe_warn_pessimizing_move): Warn when moving a temporary object
in a return statement prevents copy elision.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/Wpessimizing-move7.C: New test.

Re: [PATCH v2] c++: Tweak for -Wpessimizing-move in templates [PR89780]

[Jason Merrill via Gcc-patches]

On 8/8/22 12:51, Marek Polacek wrote:

On Sat, Aug 06, 2022 at 04:02:13PM -0700, Jason Merrill wrote:

On 8/4/22 11:46, Marek Polacek wrote:

In my previous patches I've been extending our std::move warnings,
but this tweak actually dials it down a little bit.  As reported in
bug 89780, it's questionable to warn about expressions in templates
that were type-dependent, but aren't anymore because we're instantiating
the template.  As in,

template 
Dest withMove() {
  T x;
  return std::move(x);
}

template Dest withMove(); // #1
template Dest withMove(); // #2

Saying that the std::move is pessimizing for #1 is not incorrect, but
it's not useful, because removing the std::move would then pessimize #2.
So the user can't really win.  At the same time, disabling the warning
just because we're in a template would be going too far, I still want to
warn for

template 
Dest withMove() {
  Dest x;
  return std::move(x);
}

because the std::move therein will be pessimizing for any instantiation.

So I'm using the suppress_warning machinery to that effect.
Problem: I had to add a new group to nowarn_spec_t, otherwise
suppressing the -Wpessimizing-move warning would disable a whole bunch
of other warnings, which we really don't want.

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

PR c++/89780

gcc/cp/ChangeLog:

* pt.cc (tsubst_copy_and_build) : Maybe suppress
-Wpessimizing-move.
* typeck.cc (maybe_warn_pessimizing_move): Don't issue warnings
if they are suppressed.
(check_return_expr): Disable -Wpessimizing-move when returning
a dependent expression.

gcc/ChangeLog:

* diagnostic-spec.cc (nowarn_spec_t::nowarn_spec_t): Handle
OPT_Wpessimizing_move and OPT_Wredundant_move.
* diagnostic-spec.h (nowarn_spec_t): Add NW_REDUNDANT enumerator.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/Wpessimizing-move3.C: Remove dg-warning.
* g++.dg/cpp0x/Wpessimizing-move7.C: Likewise.
* g++.dg/cpp0x/Wredundant-move2.C: Likewise.
* g++.dg/cpp0x/Wpessimizing-move9.C: New test.
---
   gcc/cp/pt.cc  |  3 +
   gcc/cp/typeck.cc  | 20 +++--
   gcc/diagnostic-spec.cc|  7 +-
   gcc/diagnostic-spec.h |  4 +-
   .../g++.dg/cpp0x/Wpessimizing-move3.C |  2 +-
   .../g++.dg/cpp0x/Wpessimizing-move7.C |  2 +-
   .../g++.dg/cpp0x/Wpessimizing-move9.C | 89 +++
   gcc/testsuite/g++.dg/cpp0x/Wredundant-move2.C |  4 +-
   8 files changed, 119 insertions(+), 12 deletions(-)
   create mode 100644 gcc/testsuite/g++.dg/cpp0x/Wpessimizing-move9.C

diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
index 6c581fe0fb7..fe7e809fc2d 100644
--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -21215,6 +21215,9 @@ tsubst_copy_and_build (tree t,
  CALL_EXPR_ORDERED_ARGS (call) = ord;
  CALL_EXPR_REVERSE_ARGS (call) = rev;
}
+   if (warning_suppressed_p (t, OPT_Wpessimizing_move))
+ /* This also suppresses -Wredundant-move.  */
+ suppress_warning (ret, OPT_Wpessimizing_move);
  }
RETURN (ret);
diff --git a/gcc/cp/typeck.cc b/gcc/cp/typeck.cc
index 2650beb780e..70a5efc45de 100644
--- a/gcc/cp/typeck.cc
+++ b/gcc/cp/typeck.cc
@@ -10430,9 +10430,10 @@ maybe_warn_pessimizing_move (tree expr, tree type, 
bool return_p)
  if (can_do_rvo_p (arg, type))
{
  auto_diagnostic_group d;
- if (warning_at (loc, OPT_Wpessimizing_move,
- "moving a temporary object prevents copy "
- "elision"))
+ if (!warning_suppressed_p (expr, OPT_Wpessimizing_move)


I don't think we ever want to suppress this warning; moving it to a
different warning flag (as I suggested on the other patch) would accomplish
that.


Agreed.  I just removed the warning_suppressed_p check though, a new flag would
need another NW_ group etc.
  

+ && warning_at (loc, OPT_Wpessimizing_move,
+"moving a temporary object prevents copy "
+"elision"))
inform (loc, "remove % call");
}
  /* The rest of the warnings is only relevant for when we are
@@ -10443,14 +10444,16 @@ maybe_warn_pessimizing_move (tree expr, tree type, 
bool return_p)
  else if (can_do_nrvo_p (arg, type))
{
  auto_diagnostic_group d;
- if (warning_at (loc, OPT_Wpessimizing_move,
- "moving a local object in a return statement "
- "prevents copy elision"))
+ if (!warning_suppressed_p (expr, OPT_Wpessimizing_move)
+ && warning_at (loc, OPT_Wpessimizing_move,
+"moving a local object in a 

[Bug target/106586] riscv32 still broke with zba_zbb_zbc_zbs, ICE in do_SUBST in C++ code

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

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

--- Comment #6 from Andrew Pinski  ---
There is much more changes needed for ZBS support to work correctly for 32bit.
And some to get it to good state for 64bits.
I will be fixing all of them but first I need to setup a test env.

[Bug middle-end/106582] Wrong code generation resulting in HardFault

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

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

--- Comment #7 from Andrew Pinski  ---
It is address 12, that is offset 12 from address 0.
And yes there is a path where pQueryChunk can still be null pointer.

If pPage->dwOptions & (0x2000) is false and (pQuery is nulll or *pQuery !=
'?'), pQueryChunk can be a null pointer when pParser it true.

[Bug target/106574] gcc 12 with O3 leads to failures in glibc's y1f128 tests

[michael.hudson at canonical dot com via Gcc-bugs]

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

--- Comment #12 from Michael Hudson-Doyle  
---
Ah OK, yes that fixes the failure. Does this mean all uses of
SET_RESTORE_ROUND* should be using math_opt_barrier / math_force_eval to avoid
this issue? Sounds awkward. I guess having a macro to call an always_inline
function with a given rounding mode would be less error prone but also make
code harder to read... anyway back to the glibc tracker I guess.

[Bug middle-end/106582] Wrong code generation resulting in HardFault

[jankowski938 at gmail dot com via Gcc-bugs]

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

Piotr  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #6 from Piotr  ---
(In reply to Andrew Pinski from comment #4)
> >
> 080157fe:   movsr3, #0
> 08015800:   ldr.w   r2, [r9, #20]
> 08015804:   str r2, [r3, #12]
> 
> This is doing a store at the address 12 which is invalid normally.
> I suspect for your code you need -fno-delete-null-pointer-checks .
> 
> Or you are missing a null pointer check.
> 
> The code does:
>if (pQueryChunk && ioIsValid(pRawChunk))
>{
> pQueryChunk->pSrcDriver = pRawChunk->pSrcDriver;
>}
>else
>{
> if (pParser)
> {
>  pQueryChunk->pSrcDriver = pParser->pSourceDriver;
> }
>}
> 
> But the store for "pQueryChunk->pSrcDriver" is not checked to see if
> pQueryChunk was a non-null pointer before doing the store after the check
> that pParser was a non-null pointer.
> 
> 
> That is I don't think this is a bug in GCC.

Thank you for debugging our code :) 

1. that chunk was vetted earlier in this function, so there is no need to check
it again here.
2. Offset 12 is not invalid as it is a 32bits (not 64) platform and it is
natively aligned

[Bug middle-end/106582] Wrong code generation resulting in HardFault

[jankowski938 at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Piotr  ---
(In reply to Andrew Pinski from comment #4)
> >
> 080157fe:   movsr3, #0
> 08015800:   ldr.w   r2, [r9, #20]
> 08015804:   str r2, [r3, #12]
> 
> This is doing a store at the address 12 which is invalid normally.
> I suspect for your code you need -fno-delete-null-pointer-checks .
> 
> Or you are missing a null pointer check.
> 
> The code does:
>if (pQueryChunk && ioIsValid(pRawChunk))
>{
> pQueryChunk->pSrcDriver = pRawChunk->pSrcDriver;
>}
>else
>{
> if (pParser)
> {
>  pQueryChunk->pSrcDriver = pParser->pSourceDriver;
> }
>}
> 
> But the store for "pQueryChunk->pSrcDriver" is not checked to see if
> pQueryChunk was a non-null pointer before doing the store after the check
> that pParser was a non-null pointer.
> 
> 
> That is I don't think this is a bug in GCC.

Thank you for debugging our code :) 

1. that chunk was vetted earlier in this function, so there is no need to check
it again here.
2. Offset 12 is not invalid as it is a 32bits (not 64) platform and it is
natively aligned

Re: [PATCH 0/5] IEEE 128-bit built-in overload support.

[Joseph Myers]

On Thu, 11 Aug 2022, Michael Meissner via Gcc-patches wrote:

> In looking at it, I now believe that the type for _Float128 and __float128
> should always be the same within the compiler.  Whether we would continue to
> use the same type for long double and _Float128/__float128 remains to be seen.

long double and _Float128 must always be different types; that's how it's 
defined in C23.

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

[Bug fortran/106579] ieee_signaling_nan problem in fortran on powerpc64

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

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

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #53438|0   |1
is obsolete||

--- Comment #7 from Jakub Jelinek  ---
Created attachment 53440
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53440=edit
gcc13-builtin-issignaling.patch

Another WIP version, the i386.md expander needs some more work but otherwise it
looks good on x86_64/i686.

[Bug target/106574] gcc 12 with O3 leads to failures in glibc's y1f128 tests

[joseph at codesourcery dot com via Gcc-bugs]

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

--- Comment #11 from joseph at codesourcery dot com  ---
On Wed, 10 Aug 2022, michael.hudson at canonical dot com via Gcc-bugs wrote:

> I just changed
> 
>   z = xx * xx;
> 
> to
> 
>   z = math_opt_barrier(xx * xx);
> 
> which perhaps isn't sufficient.

That wouldn't prevent the multiplication being moved before 
SET_RESTORE_ROUNDL, though it should suffice for the later computations as 
they all depend on z.

> But my reading of the assembly is that the issue is that some of the math code
> is being moved _after_ the restore of the fpu state implied by
> SET_RESTORE_ROUNDL (FE_TONEAREST).

To avoid code being moved after the restore, "math_force_eval (p);" just 
before the return would be appropriate.

Re: [PATCH 0/5] IEEE 128-bit built-in overload support.

[Michael Meissner via Gcc-patches]

On Wed, Aug 10, 2022 at 12:03:16PM -0500, Segher Boessenkool wrote:
> On Wed, Aug 10, 2022 at 02:23:27AM -0400, Michael Meissner wrote:
> > On Fri, Aug 05, 2022 at 01:19:05PM -0500, Segher Boessenkool wrote:
> > > On Thu, Jul 28, 2022 at 12:43:49AM -0400, Michael Meissner wrote:
> > > > These patches lay the foundation for a set of follow-on patches that 
> > > > will
> > > > change the internal handling of 128-bit floating point types in GCC.  
> > > > In the
> > > > future patches, I hope to change the compiler to always use KFmode for 
> > > > the
> > > > explicit _Float128/__float128 types, to always use TFmode for the long 
> > > > double
> > > > type, no matter which 128-bit floating point type is used, and IFmode 
> > > > for the
> > > > explicit __ibm128 type.
> > > 
> > > Making TFmode different from KFmode and IFmode is not an improvement.
> > > NAK.
> > 
> > First of all, it already IS different from KFmode and IFmode, as we've 
> > talked
> > about.
> 
> It always is the same as either IFmode or KFmode in the end.  It is a
> separate mode, yes, because generic code always wants to use TFmode.
> 
> > I'm trying to clean this mess up.  Having explicit __float128's being
> > converted to TFmode if -mabi=ieeelongdouble is just as bad, and it means 
> > that
> > _Float128 and __float128 are not the same type.
> 
> What do types have to do with this at all?

I believe the issue is with these two tests:

gcc.dg/torture/float128-nan.c
gcc.target/powerpc/nan128-1.c

In particular, both use nansq to create a signaling NaN.  The nansq function is
defined as nansf128 (i.e. it returns a _Float128 type).

However, at present, __float128 uses the long double type if the
-mabi=ieeelongdouble option is used, not the _Float128 type.  Even though these
both use TFmode in that scenario, the gimple code sees a _Float128 type that is
stored into a long double type.  The machine independent support sees that you
are changing types, and it silently converts the signaling NaN into a quiet
NaN.

An earlier patch was to just change nanq and nansq to resolve to nanl and nansl
in the case -mabi=ieeelongdouble, which you did not like.

In looking at it, I now believe that the type for _Float128 and __float128
should always be the same within the compiler.  Whether we would continue to
use the same type for long double and _Float128/__float128 remains to be seen.

But in doing the change, there are several places that need to be changed as
well.

> If TFmode means IEEE QP float, TFmode and KFmode can be used
> interchangeably.  When TFmode means double-double, TFmode and IFmode can
> be used interchangeably.  We should never depend on TFmode being
> different from both underlying modes, that way madness lies.

No, this is not supported without conversions being done (even if the
conversions are eventually nop conversions).  GCC firmly believes that there are
no modes that are equivalant and can be used interchangeably.

For example, in the float128-odd.c test case we have:

__float128
f128_fms (__float128 a, __float128 b, __float128 c)
{
  return __builtin_fmaf128_round_to_odd (a, b, -c);
}

by default if we just use the KFmode functions (because that is how they are
defined in the built-in tables) on a system where __float128 uses the long
double type and uses the TFmode, and remove the code in rs6000_expand_builtin
that changes the built-in (i.e. overloading by another name) right now the
compiler will trap because it calls copy_to_mode_reg if the predicate fails,
and the mode being copied is different from the operand.

The predicate fails because the type in the insn (i.e. KFmode) is not the same
as the type of the operand (i.e. TFmode), and the default predicate
(i.e. register_operand, altivec_register_operand, or vsx_register_operand)
checks the mode.

But that can be fixed by using convert_move's instead of copy_to_mode_reg, and
possibly with new predicates that support either TFmode or KFmode.

However, then GCC will insert convert's going from TFmode to KFmode.  Which
avoids the crash, but the converts mean that the combiner won't combine the
negate and __builtin_fmaf128_round_to_od and produce the single "xsmsubqpo"
instruction.  Instead it will generate a negate and then a "xsmaddqpo"
instruction.

I've played with adding new predicates that recognize either IEEE 128-bit type
and a separate one that recognizes either IBM 128-bit type.


This is why I proposed to have overload support so that the built-in functions
will automatically use a TFmode built-in or a KFmode built-in depending on what
the mode.

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

[Bug target/106588] New: The constraints on most of the patterns in bitmanip.md are broken

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

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

Bug ID: 106588
   Summary: The constraints on most of the patterns in bitmanip.md
are broken
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code, internal-improvement, wrong-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---
Target: riscv

Take:
(define_insn "*bseti"
  [(set (match_operand:X 0 "register_operand" "=r")
(ior:X (match_operand:X 1 "register_operand" "r")
   (match_operand 2 "single_bit_mask_operand" "i")))]
  "TARGET_ZBS"
  "bseti\t%0,%1,%S2"
  [(set_attr "type" "bitmanip")])

That is if something after reload decides to change operand 2, it will be
accepted and then crash while emitting %S2.

Re: [PATCH 2/2 v2] analyzer: out-of-bounds checker [PR106000]

[David Malcolm via Gcc-patches]

On Thu, 2022-08-11 at 19:24 +0200, Tim Lange wrote:
> This patch adds an experimental out-of-bounds checker to the
> analyzer.
> 
> The checker was tested on coreutils, curl, httpd and openssh. It is
> mostly
> accurate but does produce false-positives on yacc-generated files and
> sometimes when the analyzer misses an invariant. These cases will be
> documented in bugzilla.
> Regression-tested on Linux x86-64, further ran the analyzer tests
> with
> the -m32 option.

[...snip...]


Thanks for the updated patch.  This version is OK for trunk [1].

Dave

[1] as I mentioned before, I plan to reword the diagnostic once it's in
trunk, but I'll do that myself, rather than be a backseat driver.

Re: [PATCH 1/2 v2] analyzer: consider that realloc could shrink the buffer [PR106539]

[David Malcolm via Gcc-patches]

On Thu, 2022-08-11 at 19:24 +0200, Tim Lange wrote:
> This patch adds the "shrinks buffer" case to the success_with_move
> modelling of realloc.

Thanks for the updated patch.

> 
> Regression-tested on Linux x86-64, further ran the analyzer tests
> with
> the -m32 option.

[...snip...]

> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/analyzer/realloc-5.c
> @@ -0,0 +1,45 @@
> +#include "analyzer-decls.h"
> +
> +typedef __SIZE_TYPE__ size_t;
> +
> +#define NULL ((void *)0)
> +
> +extern void *malloc (size_t __size)
> +  __attribute__ ((__nothrow__ , __leaf__))
> +  __attribute__ ((__malloc__))
> +  __attribute__ ((__alloc_size__ (1)));
> +extern void *realloc (void *__ptr, size_t __size)
> +  __attribute__ ((__nothrow__ , __leaf__))
> +  __attribute__ ((__warn_unused_result__))
> +  __attribute__ ((__alloc_size__ (2)));
> +extern void free (void *__ptr)
> +  __attribute__ ((__nothrow__ , __leaf__));
> +extern void *memset (void *__ptr, int __value, size_t __size);
> +
> +/* realloc where the region shrinks on success_with_move.  */
> +
> +void test_1 ()
> +{
> +  char *p = malloc (16);
> +  if (!p)
> +    return;
> +  memset (p, 1, 16);
> +
> +  char *q = realloc (p, 8);
> +  if (!q)
> +    {
> +  free (p);
> +  return;
> +    }
> +  else if (p != q)
> +    {
> +  __analyzer_dump_capacity (q); /* { dg-warning "capacity:
> '\\(\[^\n\r\]*\\)8'" } */
> +  __analyzer_eval (q[8] == 1); /* { dg-line eval } */
> +    
> +  /* { dg-warning "UNKNOWN" "warning" { target *-*-* } eval } */
> +  /* { dg-warning "overread" "warning" { target *-*-* } eval }
> */

Strictly speaking, this "overread" warning is dependent on the followup
patch, but assuming that that patch is OK, this patch is also OK.

Thanks
Dave

> +  /* { dg-warning "use of uninitialized value" "warning" {
> target *-*-* } eval } */
> +    }
> +
> +  free (q);
> +}

[Bug target/106586] riscv32 still broke with zba_zbb_zbc_zbs, ICE in do_SUBST in C++ code

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2022-08-11

--- Comment #5 from Andrew Pinski  ---
Mine. The problem here is INT_MIN is always sign extended to HWI. So there
needs to be a mask setting. Looking into how to handle INT_MIN better for
32bits.

[Bug target/106586] riscv32 still broke with zba_zbb_zbc_zbs, ICE in do_SUBST in C++ code

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

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

--- Comment #4 from Andrew Pinski  ---
diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index 5a0adffb5ce..b4a08de6b93 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -426,7 +426,9 @@ riscv_build_integer_1 (struct riscv_integer_op
codes[RISCV_MAX_INTEGER_OPS],
 sign-extended (negative) representation (-1 << 31) for the
 value, if we want to build (1 << 31) in SImode.  This will
 then expand to an LUI instruction.  */
-  if (mode == SImode && value == (HOST_WIDE_INT_1U << 31))
+  if (TARGET_64BIT
+ && mode == SImode
+ && value == (HOST_WIDE_INT_1U << 31))
codes[0].value = (HOST_WIDE_INT_M1U << 31);

   return 1;


Fixes that ICE but there is still another ICE with the same reduced testcase:
0xd9898c wi::int_traits >::decompose(long*,
unsigned int, std::pair const&)
../../src/gcc/rtl.h:2288
0x1136bf7 wide_int_ref_storage::wide_int_ref_storage
>(std::pair const&, unsigned int)
../../src/gcc/wide-int.h:1034
0x1136bf7 generic_wide_int
>::generic_wide_int >(std::pair const&, unsigned int)
../../src/gcc/wide-int.h:790
0x1136bf7 wi::binary_traits,
std::pair, wi::int_traits >::precision_type, wi::int_traits >::precision_type>::result_type wi::add, std::pair >(std::pair const&, std::pair const&)
../../src/gcc/wide-int.h:2442
0x1136bf7 simplify_const_binary_operation(rtx_code, machine_mode, rtx_def*,
rtx_def*)
../../src/gcc/simplify-rtx.cc:5004
0x113de58 simplify_context::simplify_binary_operation(rtx_code, machine_mode,
rtx_def*, rtx_def*)
../../src/gcc/simplify-rtx.cc:2569
0x10d1b75 simplify_binary_operation(rtx_code, machine_mode, rtx_def*, rtx_def*)
../../src/gcc/rtl.h:3475
0x10d1b75 simplify_while_replacing
../../src/gcc/recog.cc:686
0x10d1b75 validate_replace_rtx_1
../../src/gcc/recog.cc:890
0x10fefb4 note_uses(rtx_def**, void (*)(rtx_def**, void*), void*)
../../src/gcc/rtlanal.cc:2065
0x10cd9b2 validate_replace_src_group(rtx_def*, rtx_def*, rtx_insn*)
../../src/gcc/recog.cc:979
0x1945e30 try_replace_reg
../../src/gcc/cprop.cc:752
0x1946509 constprop_register
../../src/gcc/cprop.cc:1023
0x194688b do_local_cprop
../../src/gcc/cprop.cc:1208
0x194688b local_cprop_pass
../../src/gcc/cprop.cc:1271
0x194688b one_cprop_pass
../../src/gcc/cprop.cc:1772
0x194688b execute_rtl_cprop
../../src/gcc/cprop.cc:1926
0x194688b execute
../../src/gcc/cprop.cc:1966
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.

Still debugging this.

[Bug target/106587] New: RISCV invalid jump address when compiled with -fcall-saved-reg and TCO

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

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

Bug ID: 106587
   Summary: RISCV invalid jump address when compiled with
-fcall-saved-reg and TCO
   Product: gcc
   Version: 11.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: michael.hale48 at gmail dot com
  Target Milestone: ---

Description of bug: When compiling with -fcall-saved on temporary registers,
program will perform a jump to a register after it has been restored from the
stack.

GCC version: gcc version 11.1.0 (GCC)

System type: 5.4.0-81-generic #91~18.04.1-Ubuntu SMP x86_64

GCC configuration: 
```
/home/mhale/github/riscv-gnu-toolchain/riscv-gcc/configure
--target=riscv32-unknown-elf --prefix=/opt/riscv --disable-shared
--disable-threads --enable-languages=c,c++ --with-system-zlib --enable-tls
--with-newlib --with-sysroot=/opt/riscv/riscv32-unknown-elf
--with-native-system-header-dir=/include --disable-libmudflap --disable-libssp
--disable-libquadmath --disable-libgomp --disable-nls
--disable-tm-clone-registry --src=.././riscv-gcc --disable-multilib
--with-abi=ilp32d --with-arch=rv32imfdc --with-tune=rocket
'CFLAGS_FOR_TARGET=-Os   -mcmodel=medlow' 'CXXFLAGS_FOR_TARGET=-Os  
-mcmodel=medlow' 
```

GCC command:
```
riscv32-unknown-elf-gcc -nostartfiles -Wall -Wextra -fcall-saved-t{1..6}
clobber.c -save-temps -v -o clobber
```

Compiler output:
```
Using built-in specs.
COLLECT_GCC=/opt/riscv/bin/riscv32-unknown-elf-gcc
COLLECT_LTO_WRAPPER=/opt/riscv/libexec/gcc/riscv32-unknown-elf/11.1.0/lto-wrapper
Target: riscv32-unknown-elf
Configured with: /home/mhale/github/riscv-gnu-toolchain/riscv-gcc/configure
--target=riscv32-unknown-elf --prefix=/opt/riscv --disable-shared
--disable-threads --enable-languages=c,c++ --with-system-zlib --enable-tls
--with-newlib --with-sysroot=/opt/riscv/riscv32-unknown-elf
--with-native-system-header-dir=/include --disable-libmudflap --disable-libssp
--disable-libquadmath --disable-libgomp --disable-nls
--disable-tm-clone-registry --src=.././riscv-gcc --disable-multilib
--with-abi=ilp32d --with-arch=rv32imfdc --with-tune=rocket
'CFLAGS_FOR_TARGET=-Os   -mcmodel=medlow' 'CXXFLAGS_FOR_TARGET=-Os  
-mcmodel=medlow'
Thread model: single
Supported LTO compression algorithms: zlib
gcc version 11.1.0 (GCC) 
COLLECT_GCC_OPTIONS='-nostartfiles' '-Wall' '-Wextra' '-fcall-saved-t1'
'-fcall-saved-t2' '-fcall-saved-t3' '-fcall-saved-t4' '-fcall-saved-t5'
'-fcall-saved-t6' '-save-temps' '-v' '-o' 'clobber' '-mtune=rocket'
'-march=rv32imfdc' '-mabi=ilp32d' '-march=rv32imfdc'
 /opt/riscv/libexec/gcc/riscv32-unknown-elf/11.1.0/cc1 -E -quiet -v clobber.c
-mtune=rocket -march=rv32imfdc -mabi=ilp32d -march=rv32imfdc -Wall -Wextra
-fcall-saved-t1 -fcall-saved-t2 -fcall-saved-t3 -fcall-saved-t4 -fcall-saved-t5
-fcall-saved-t6 -fpch-preprocess -o clobber.i
ignoring nonexistent directory
"/opt/riscv/riscv32-unknown-elf/usr/local/include"
ignoring duplicate directory "/opt/riscv/riscv32-unknown-elf/include"
#include "..." search starts here:
#include <...> search starts here:
 /opt/riscv/lib/gcc/riscv32-unknown-elf/11.1.0/include
 /opt/riscv/lib/gcc/riscv32-unknown-elf/11.1.0/include-fixed

/opt/riscv/lib/gcc/riscv32-unknown-elf/11.1.0/../../../../riscv32-unknown-elf/include
End of search list.
COLLECT_GCC_OPTIONS='-nostartfiles' '-Wall' '-Wextra' '-fcall-saved-t1'
'-fcall-saved-t2' '-fcall-saved-t3' '-fcall-saved-t4' '-fcall-saved-t5'
'-fcall-saved-t6' '-save-temps' '-v' '-o' 'clobber' '-mtune=rocket'
'-march=rv32imfdc' '-mabi=ilp32d' '-march=rv32imfdc'
 /opt/riscv/libexec/gcc/riscv32-unknown-elf/11.1.0/cc1 -fpreprocessed clobber.i
-quiet -dumpbase clobber.c -dumpbase-ext .c -mtune=rocket -march=rv32imfdc
-mabi=ilp32d -march=rv32imfdc -Wall -Wextra -version -fcall-saved-t1
-fcall-saved-t2 -fcall-saved-t3 -fcall-saved-t4 -fcall-saved-t5 -fcall-saved-t6
-o clobber.s
GNU C17 (GCC) version 11.1.0 (riscv32-unknown-elf)
compiled by GNU C version 7.5.0, GMP version 6.1.2, MPFR version 4.0.1,
MPC version 1.1.0, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C17 (GCC) version 11.1.0 (riscv32-unknown-elf)
compiled by GNU C version 7.5.0, GMP version 6.1.2, MPFR version 4.0.1,
MPC version 1.1.0, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: aecc75e33d037bca1725d62ef4fb2c89
COLLECT_GCC_OPTIONS='-nostartfiles' '-Wall' '-Wextra' '-fcall-saved-t1'
'-fcall-saved-t2' '-fcall-saved-t3' '-fcall-saved-t4' '-fcall-saved-t5'
'-fcall-saved-t6' '-save-temps' '-v' '-o' 'clobber' '-mtune=rocket'
'-march=rv32imfdc' '-mabi=ilp32d' '-march=rv32imfdc'

/opt/riscv/lib/gcc/riscv32-unknown-elf/11.1.0/../../../../riscv32-unknown-elf/bin/as
-v --traditional-format -march=rv32imfdc -march=rv32imfdc -mabi=ilp32d -o
clobber.o clobber.s
GNU 

[Bug target/106586] riscv32 still broke with zba_zbb_zbc_zbs, ICE in do_SUBST in C++ code

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

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

--- Comment #3 from Andrew Pinski  ---
Reduced testcase:
void f(int);
void g(long long __off)
{
  const int max = (1u << 31) - 1;
  while (__off > max)
{
  f(max);
}
}

[Bug c++/89780] -Wpessimizing-move is too agressive with templates and recommends pessimization

[herring at lanl dot gov via Gcc-bugs]

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

--- Comment #8 from S. Davis Herring  ---
I looked at P2266R3 again; it claims that the conversion function case (in #7)
is actually covered by P1825R0.  I think that case is questionable, since it
still refers to "overload resolution to select the constructor for the copy"
and there's no constructor involved when a conversion function is used.  (In
particular, it isn't the case that the A object is converted to a Dest
temporary that is then used as the argument to Dest(Dest&&), since that would
be a second user-defined conversion.)  If we consider the intent in P1155R3,
though, it's pretty clear that that's just a wording oversight, so it's not
unreasonable that GCC and Clang (but not ICC) accept

  template Dest withMove();

in C++20 mode.  That means that we don't have to distinguish C++20 and C++23
for this discussion (at least outside of weirder cases like returning a
reference).

Re: [PATCH] tree-optimization/106514 - revisit m_import compute in backward threading

[Andrew MacLeod via Gcc-patches]

On 8/10/22 06:46, Richard Biener wrote:


I see the solver itself adds relations from edges on the path so
the cruical item here seems to be to add imports for the path
entry conditional, but those would likely be GORI imports for that
block?  Unfortunately that fails to add t[012], the GORI exports
seem to cover all that's needed but then exports might be too much


the GORI export list is the list of names which which GORi thinks might 
be different on the outgoing edges from a block.


The GORI import list is the list of names which GORI thinks can affect 
those ranges from outside the block.  It doesnt try to look at 
individual PHI aguments, so IIRC it treats a PHI def as originating 
outside the block for import purposes.  This should be a subset of the 
export list.


GORI info is only every concerned ONLY with the basic block... all 
external influences are considrered to be in the import list. And all 
GORI calculations utilize a range_of_expr query from a range_query to 
resolve the incoming value of an import in order to calculate an 
outgoing edge.


outgoing_edge_range_p () has some additional smarts in it which allows 
for recomputations. You may have noticed the depend1/depend2 fields in 
the range_def_chain structure.  These are quick and dirty caches which 
represent the first 2 ssa-names encountered on the stmt when it was 
processed.  so for PHIs, the first 2 ssa names encountered, and for 
simple range-op qualifying stmts, the 1 or 2 ssanames in the def stmt 
for an ssa-name.


If you ask for the range of a_32 on an outgoing edge, and it is not in 
the export list, GORI would not be able to provide a range. 
Outgoing_edge_range_p utilizes those 2 depend fields as a quick check to 
see if a recomputation may give us a better range.  if either depend1 or 
depend2 asociated with a_32 IS i the export list, then it performs a 
recompuation of a_32 instead of a GORI calculation.  ie  from the 
example in my previous note:


  a_32 = f_16 + 10
<...>
bb88:
  if (f_16 < 20)
bb89:
     b_8 = a_32 + 8

depend1 for a_32 will be f_16.
during rangers evaluation of b_8 in bb89, it will ask for the range of 
a_32 on the edge 88->89.  a_32 is not an export, but it sees that 
depend1 (f_16) is in the export list, so it does a recalculation of a_32 
on the edge, coming up with f_16 being [0, 19] and returning a_32 as 
[10, 29].


This is why you may see outgoing_edge_range_p coming up with things that 
GORI itself doesnt actually provide...


your example:

void foo (int nest, int print_nest)
{
  _Bool t0 = nest != 0;
  _Bool t1 = nest == print_nest;
  _Bool t2 = t0 & t1;
  if (t2)
    __builtin_puts ("x");
  nest++;
  if (nest > 2)
    __builtin_abort ();
  if (print_nest == nest)
    __builtin_puts ("y");
}


if (nest > 2) , : nest is the only import and export in that block, but 
outgoing_edge_range_p would be able to recompute t1 and t0 on those 
edges as nest is used in defining them. Likewise, print_nest is used in 
defining t1, so it can also be recomputed. on the final edges.     This 
could be why adding some dependencies from outside the block sometimes 
gets a better result.


the recomputation information is not rolled into the GORI exports, as it 
is more dynamic.  we don't know which order this will be seen in, so we 
dont know what ssa_names in advance use 'nest' in their calculations.   
we could add them as they are seen, but then the bitmaps could explode 
in size.. so leaving it in this dynamic quick check seemed more practical.


There is no mapping from a name to the other ssanames that depend on it 
in either..  ie, given 'nest', there is no mechaism to see that t0 and 
t1 use it.   I had considered building this list as well, but at the 
moment didnt have a lot of use for it and thought a use map might get 
large quickly.


I wonder if what might help is to loop thru all the interesting names 
that have been calculated, and adding  the GORI export names from the 
original block which occur in either a depend1 or depend2 field of those 
names..   That would be more concise than the entire gori export list. 
if it is just the entry path exports that are relevant, then perhaps as 
names are added to the interesting list we could check if either of its 
'depend's fields is in the entry blocks export list, and add it then.




here?  At least that's what the code in compute_imports effectively
does (also for the entry block).  But I do wonder why compute_ranges
does not add relations computed by the entry conditional ...
That's probably because of

void
path_range_query::compute_outgoing_relations (basic_block bb, basic_block
next)
{
   gimple *stmt = last_stmt (bb);

   if (stmt
   && gimple_code (stmt) == GIMPLE_COND
   && (import_p (gimple_cond_lhs (stmt))
   || import_p (gimple_cond_rhs (stmt

where for a condition like above the names in the imports are not
in the condition itself.  The gori.outgoing_edge_range_p compute
of the import ranges is appearantly 

[Bug target/106586] riscv32 still broke with zba_zbb_zbc_zbs, ICE in do_SUBST in C++ code

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

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

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

[Bug target/106586] riscv32 still broke with zba_zbb_zbc_zbs, ICE in do_SUBST in C++ code

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

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

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

Re: [PATCH v3] Modify combine pattern by a pseudo AND with its nonzero bits [PR93453]

[Segher Boessenkool]

Hi!

On Thu, Aug 11, 2022 at 10:11:45AM +0800, HAO CHEN GUI wrote:
> On 11/8/2022 上午 1:38, Segher Boessenkool wrote:
> > On Fri, Jul 22, 2022 at 03:07:55PM +0800, HAO CHEN GUI wrote:
> >>   This patch creates a new function - change_pseudo_and_mask. If recog 
> >> fails,
> >> the function converts a single pseudo to the pseudo AND with a mask if the
> >> outer operator is IOR/XOR/PLUS and inner operator is ASHIFT or AND. The
> >> conversion helps pattern to match rotate and mask insn on some targets.
> > 
> > The name isn't so clear.  It isn't changing a mask, to start with.
> How about setting function name to change_pseudo? It converts a pseudo to
> the pseudo AND with a mask in a particular situation.

Change pseudo to what?  It remains a pseudo, the same pseudo even.

"add_mask_to_pseudo"...  Well, that says "add", which is like "plus",
not a great name either -- but something in that direction?

> >> +/* When the outer code of set_src is IOR/XOR/PLUS and the inner code is
> >> +   ASHIFT/AND,
> > 
> > "When the outercode of the SET_SRC of PAT is ..."
> Yeah, I will change it.

"outer code" of course, sorry, I typed it wrong :-/

> >> convert a pseudo to pseudo AND with a mask if its nonzero_bits
> >> +   is less than its mode mask.  The nonzero_bits in later passes is not a
> >> +   superset of what is known in combine pass.  So an insn with 
> >> nonzero_bits
> >> +   can't be recoged later.  */
> > 
> > Can this not be done with a splitter in the machine description?
> > 
> Sorry, I don't quite understand it. Do you mean if the conversion can be done 
> in
> split pass?

In any splitter, also during combine for example.  Is this common enough
to warrant special code in combine to handle all tens of cases, or is it
better handled in separate patterns?

> If a pseudo has DImode and stem from a char, we get nonzero_bits as 0xff in 
> combine
> pass. But in split pass, it's nonzero_bits is 0x. So the 
> conversion
> can only be done in combine pass.

Yes, but combine will use splitters as well.

You can use nonzero_bits in the split condition (the second condition in
a define_split, or the sole condition in a define_split) just fine, as
long as the replacement RTL does not rely on the nonzero_bits itself.
You cannot use it in the insn condition (the first condition in a
define_insn_and_split, or the one condition in a define_insn) because
that RTL will survive past combine, and then nonzero_bits can have bits
cleared that were set before (that were determined to be always zero
during combine, but that knowledge is gone later).

(Insns can also be split in thread_pro_and_epilogue, during reorg, and
in final of course).


Segher

[Bug target/106586] New: riscv32 still broke with zba_zbb_zbc_zbs, ICE in do_SUBST in C++ code

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

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

Bug ID: 106586
   Summary: riscv32 still broke with zba_zbb_zbc_zbs, ICE in
do_SUBST in C++ code
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---
Target: riscv

/home/apinski/src/toolchain-riscv/riscv-build/./gcc/xgcc -shared-libgcc
-B/home/apinski/src/toolchain-riscv/riscv-build/./gcc -nostdinc++
-L/home/apinski/src/toolchain-riscv/riscv-build/riscv32-marvelldpu-elf/libstdc++-v3/src
-L/home/apinski/src/toolchain-riscv/riscv-build/riscv32-marvelldpu-elf/libstdc++-v3/src/.libs
-L/home/apinski/src/toolchain-riscv/riscv-build/riscv32-marvelldpu-elf/libstdc++-v3/libsupc++/.libs
-nostdinc
-B/home/apinski/src/toolchain-riscv/riscv-build/riscv32-marvelldpu-elf/newlib/
-isystem
/home/apinski/src/toolchain-riscv/riscv-build/riscv32-marvelldpu-elf/newlib/targ-include
-isystem /home/apinski/src/toolchain-riscv/src/newlib/libc/include
-B/home/apinski/src/toolchain-riscv/riscv-build/riscv32-marvelldpu-elf/libgloss/riscv32
-L/home/apinski/src/toolchain-riscv/riscv-build/riscv32-marvelldpu-elf/libgloss/libnosys
-L/home/apinski/src/toolchain-riscv/src/libgloss/riscv32
-B/home/apinski/src/toolchain-riscv/riscv-build/../marvelldpu-tools/riscv32-marvelldpu-elf/bin/
-B/home/apinski/src/toolchain-riscv/riscv-build/../marvelldpu-tools/riscv32-marvelldpu-elf/lib/
-isystem
/home/apinski/src/toolchain-riscv/riscv-build/../marvelldpu-tools/riscv32-marvelldpu-elf/include
-isystem
/home/apinski/src/toolchain-riscv/riscv-build/../marvelldpu-tools/riscv32-marvelldpu-elf/sys-include
-L/home/apinski/src/toolchain-riscv/riscv-build/./ld
-I/home/apinski/src/toolchain-riscv/src/libstdc++-v3/../libgcc
-I/home/apinski/src/toolchain-riscv/riscv-build/riscv32-marvelldpu-elf/libstdc++-v3/include/riscv32-marvelldpu-elf
-I/home/apinski/src/toolchain-riscv/riscv-build/riscv32-marvelldpu-elf/libstdc++-v3/include
-I/home/apinski/src/toolchain-riscv/src/libstdc++-v3/libsupc++ -std=gnu++11
-fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi=2
-fdiagnostics-show-location=once -ffunction-sections -fdata-sections
-frandom-seed=cow-sstream-inst.lo -g -O2 -c
../../../../../src/libstdc++-v3/src/c++11/cow-sstream-inst.cc -o
cow-sstream-inst.o -freport-bug
during RTL pass: combine
In file included from
/home/apinski/src/toolchain-riscv/riscv-build/riscv32-marvelldpu-elf/libstdc++-v3/include/sstream:1218,
 from
../../../../../src/libstdc++-v3/src/c++11/sstream-inst.cc:34,
 from
../../../../../src/libstdc++-v3/src/c++11/cow-sstream-inst.cc:30:
/home/apinski/src/toolchain-riscv/riscv-build/riscv32-marvelldpu-elf/libstdc++-v3/include/bits/sstream.tcc:
In member function ‘void std::basic_stringbuf<_CharT, _Traits,
_Alloc>::_M_pbump(char_type*, char_type*, off_type) [with _CharT = char;
_Traits = std::char_traits; _Alloc = std::allocator]’:
/home/apinski/src/toolchain-riscv/riscv-build/riscv32-marvelldpu-elf/libstdc++-v3/include/bits/sstream.tcc:286:5:
internal compiler error: in do_SUBST, at combine.cc:701
  286 | }
  | ^
0x8e268f do_SUBST
../../src/gcc/combine.cc:700
0x1918186 subst
../../src/gcc/combine.cc:5579
0x191807a subst
../../src/gcc/combine.cc:5532
0x191807a subst
../../src/gcc/combine.cc:5532
0x191b4e7 try_combine
../../src/gcc/combine.cc:3299
0x1921c2b combine_instructions
../../src/gcc/combine.cc:1410
0x1921c2b rest_of_handle_combine
../../src/gcc/combine.cc:14978
0x1921c2b execute
../../src/gcc/combine.cc:15023
Please submit a full bug report, with preprocessed source.
Please include the complete backtrace with any bug report.
See  for instructions.
Preprocessed source stored into /tmp/ccozqEz0.out file, please attach this to
your bugreport.

Will attach the preprocessed source in a few minutes.

[PATCH 2/2 v2] analyzer: out-of-bounds checker [PR106000]

[Tim Lange]

This patch adds an experimental out-of-bounds checker to the analyzer.

The checker was tested on coreutils, curl, httpd and openssh. It is mostly
accurate but does produce false-positives on yacc-generated files and
sometimes when the analyzer misses an invariant. These cases will be
documented in bugzilla.
Regression-tested on Linux x86-64, further ran the analyzer tests with
the -m32 option.

2022-08-11  Tim Lange  

gcc/analyzer/ChangeLog:

PR analyzer/106000
* analyzer.opt: Add Wanalyzer-out-of-bounds.
* region-model.cc (class out_of_bounds): Diagnostics base class
for all out-of-bounds diagnostics.
(class past_the_end): Base class derived from out_of_bounds for
the buffer_overflow and buffer_overread diagnostics.
(class buffer_overflow): Buffer overflow diagnostics.
(class buffer_overread): Buffer overread diagnostics.
(class buffer_underflow): Buffer underflow diagnostics.
(class buffer_underread): Buffer overread diagnostics.
(region_model::check_region_bounds): New function to check region
bounds for out-of-bounds accesses.
(region_model::check_region_access):
Add call to check_region_bounds.
(region_model::get_representative_tree): New function that accepts
a region instead of an svalue.
* region-model.h (class region_model):
Add region_model::check_region_bounds.
* region.cc (region::symbolic_p): New predicate.
(offset_region::get_byte_size_sval): Only return the remaining
byte size on offset_regions.
* region.h: Add region::symbolic_p.
* store.cc (byte_range::intersects_p):
Add new function equivalent to bit_range::intersects_p.
(byte_range::exceeds_p): New function.
(byte_range::falls_short_of_p): New function.
* store.h (struct byte_range): Add byte_range::intersects_p,
byte_range::exceeds_p and byte_range::falls_short_of_p.

gcc/ChangeLog:

PR analyzer/106000
* doc/invoke.texi: Add Wanalyzer-out-of-bounds.

gcc/testsuite/ChangeLog:

PR analyzer/106000
* g++.dg/analyzer/pr100244.C: Disable out-of-bounds warning.
* gcc.dg/analyzer/allocation-size-3.c:
Disable out-of-bounds warning.
* gcc.dg/analyzer/memcpy-2.c: Disable out-of-bounds warning.
* gcc.dg/analyzer/pr101962.c: Add dg-warning.
* gcc.dg/analyzer/pr96764.c: Disable out-of-bounds warning.
* gcc.dg/analyzer/pr97029.c:
Add dummy buffer to prevent an out-of-bounds warning.
* gcc.dg/analyzer/test-setjmp.h:
Add dummy buffer to prevent an out-of-bounds warning.
* gcc.dg/analyzer/zlib-3.c: Add dg-bogus.
* g++.dg/analyzer/out-of-bounds-placement-new.C: New test.
* gcc.dg/analyzer/out-of-bounds-1.c: New test.
* gcc.dg/analyzer/out-of-bounds-2.c: New test.
* gcc.dg/analyzer/out-of-bounds-3.c: New test.
* gcc.dg/analyzer/out-of-bounds-container_of.c: New test.
* gcc.dg/analyzer/out-of-bounds-coreutils.c: New test.
* gcc.dg/analyzer/out-of-bounds-curl.c: New test.

---
 gcc/analyzer/analyzer.opt |   4 +
 gcc/analyzer/region-model.cc  | 422 ++
 gcc/analyzer/region-model.h   |   3 +
 gcc/analyzer/region.cc|  32 ++
 gcc/analyzer/region.h |   4 +
 gcc/analyzer/store.cc |  67 +++
 gcc/analyzer/store.h  |   9 +
 gcc/doc/invoke.texi   |  15 +
 .../analyzer/out-of-bounds-placement-new.C|  19 +
 gcc/testsuite/g++.dg/analyzer/pr100244.C  |   5 +-
 .../gcc.dg/analyzer/allocation-size-3.c   |   2 +
 gcc/testsuite/gcc.dg/analyzer/memcpy-2.c  |   2 +-
 .../gcc.dg/analyzer/out-of-bounds-1.c | 120 +
 .../gcc.dg/analyzer/out-of-bounds-2.c |  83 
 .../gcc.dg/analyzer/out-of-bounds-3.c |  91 
 .../analyzer/out-of-bounds-container_of.c |  51 +++
 .../gcc.dg/analyzer/out-of-bounds-coreutils.c |  29 ++
 .../gcc.dg/analyzer/out-of-bounds-curl.c  |  41 ++
 gcc/testsuite/gcc.dg/analyzer/pr101962.c  |   6 +-
 gcc/testsuite/gcc.dg/analyzer/pr96764.c   |   2 +
 gcc/testsuite/gcc.dg/analyzer/pr97029.c   |   4 +-
 gcc/testsuite/gcc.dg/analyzer/test-setjmp.h   |   4 +-
 gcc/testsuite/gcc.dg/analyzer/zlib-3.c|   4 +-
 23 files changed, 1012 insertions(+), 7 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/analyzer/out-of-bounds-placement-new.C
 create mode 100644 gcc/testsuite/gcc.dg/analyzer/out-of-bounds-1.c
 create mode 100644 gcc/testsuite/gcc.dg/analyzer/out-of-bounds-2.c
 create mode 100644 gcc/testsuite/gcc.dg/analyzer/out-of-bounds-3.c
 create mode 100644 gcc/testsuite/gcc.dg/analyzer/out-of-bounds-container_of.c
 create mode 100644 gcc/testsuite/gcc.dg/analyzer/out-of-bounds-coreutils.c
 create mode 100644 

[PATCH 1/2 v2] analyzer: consider that realloc could shrink the buffer [PR106539]

[Tim Lange]

This patch adds the "shrinks buffer" case to the success_with_move
modelling of realloc.

Regression-tested on Linux x86-64, further ran the analyzer tests with
the -m32 option.

2022-08-11  Tim Lange  

gcc/analyzer/ChangeLog:

PR analyzer/106539
* region-model-impl-calls.cc (region_model::impl_call_realloc):
Use the result of get_copied_size as the size for the
sized_regions in realloc.
(success_with_move::get_copied_size): New function.

gcc/testsuite/ChangeLog:

PR analyzer/106539
* gcc.dg/analyzer/pr106539.c: New test.
* gcc.dg/analyzer/realloc-5.c: New test.

---
 gcc/analyzer/region-model-impl-calls.cc   | 48 ---
 gcc/testsuite/gcc.dg/analyzer/pr106539.c  | 15 +++
 gcc/testsuite/gcc.dg/analyzer/realloc-5.c | 45 +
 3 files changed, 102 insertions(+), 6 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/analyzer/pr106539.c
 create mode 100644 gcc/testsuite/gcc.dg/analyzer/realloc-5.c

diff --git a/gcc/analyzer/region-model-impl-calls.cc 
b/gcc/analyzer/region-model-impl-calls.cc
index 8c38e9206fa..fa0ec88b1f4 100644
--- a/gcc/analyzer/region-model-impl-calls.cc
+++ b/gcc/analyzer/region-model-impl-calls.cc
@@ -732,15 +732,17 @@ region_model::impl_call_realloc (const call_details )
  const svalue *old_size_sval = model->get_dynamic_extents (freed_reg);
  if (old_size_sval)
{
- const region *sized_old_reg
+ const svalue *copied_size_sval
+   = get_copied_size (old_size_sval, new_size_sval);
+ const region *copied_old_reg
= model->m_mgr->get_sized_region (freed_reg, NULL,
- old_size_sval);
+ copied_size_sval);
  const svalue *buffer_content_sval
-   = model->get_store_value (sized_old_reg, cd.get_ctxt ());
- const region *sized_new_reg
+   = model->get_store_value (copied_old_reg, cd.get_ctxt ());
+ const region *copied_new_reg
= model->m_mgr->get_sized_region (new_reg, NULL,
- old_size_sval);
- model->set_value (sized_new_reg, buffer_content_sval,
+ copied_size_sval);
+ model->set_value (copied_new_reg, buffer_content_sval,
cd.get_ctxt ());
}
  else
@@ -774,6 +776,40 @@ region_model::impl_call_realloc (const call_details )
   else
return true;
 }
+
+  private:
+/* Return the lesser of OLD_SIZE_SVAL and NEW_SIZE_SVAL.
+   If either one is symbolic, the symbolic svalue is returned.  */
+const svalue *get_copied_size (const svalue *old_size_sval,
+  const svalue *new_size_sval) const
+{
+  tree old_size_cst = old_size_sval->maybe_get_constant ();
+  tree new_size_cst = new_size_sval->maybe_get_constant ();
+
+  if (old_size_cst && new_size_cst)
+   {
+ /* Both are constants and comparable.  */
+ tree cmp = fold_binary (LT_EXPR, boolean_type_node,
+ old_size_cst, new_size_cst);
+
+ if (cmp == boolean_true_node)
+   return old_size_sval;
+ else
+   return new_size_sval;
+   }
+  else if (new_size_cst)
+   {
+ /* OLD_SIZE_SVAL is symbolic, so return that.  */
+ return old_size_sval;
+   }
+  else
+   {
+ /* NEW_SIZE_SVAL is symbolic or both are symbolic.
+Return NEW_SIZE_SVAL, because implementations of realloc
+probably only moves the buffer if the new size is larger.  */
+ return new_size_sval;
+   }
+}
   };
 
   /* Body of region_model::impl_call_realloc.  */
diff --git a/gcc/testsuite/gcc.dg/analyzer/pr106539.c 
b/gcc/testsuite/gcc.dg/analyzer/pr106539.c
new file mode 100644
index 000..fd270868e36
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/analyzer/pr106539.c
@@ -0,0 +1,15 @@
+#include 
+
+void *test (void)
+{
+  void **p = (void **)malloc (sizeof (void *) * 2);
+  if (!p)
+return NULL;
+  p[0] = malloc(10);
+  p[1] = malloc(20); /* { dg-message "allocated here" }  */
+  void *q = realloc (p, sizeof (void *)); /* { dg-message "when 'realloc' 
succeeds, moving buffer" } */
+  if (!q)
+  /* { dg-warning "leak of ''" "leak of unknown" { target *-*-* } .-1 
} */
+return p;
+  return q;
+}
diff --git a/gcc/testsuite/gcc.dg/analyzer/realloc-5.c 
b/gcc/testsuite/gcc.dg/analyzer/realloc-5.c
new file mode 100644
index 000..2efe3371e12
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/analyzer/realloc-5.c
@@ -0,0 +1,45 @@
+#include "analyzer-decls.h"
+
+typedef __SIZE_TYPE__ size_t;
+
+#define NULL ((void *)0)
+
+extern void *malloc (size_t __size)
+  __attribute__ ((__nothrow__ , __leaf__))
+  __attribute__ 

[Bug target/106585] RISC-V: Mis-optimized code gen for zbs

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2022-08-11
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #6 from Andrew Pinski  ---
(In reply to Kito Cheng from comment #5)
> bset generated after change X to GPR for most zbs pattern:

Most likely most of bitmanip.md patterns should be changed to GPR instead of X.
 Just someone will need to do the work there.
(changing *bclr pattern to GPR should improve this one to bclr too).

[Bug target/106585] RISC-V: Mis-optimized code gen for zbs

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

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

--- Comment #5 from Kito Cheng  ---
bset generated after change X to GPR for most zbs pattern:

```
foo:
bseta1,x0,a1
andna0,a0,a1
sext.w  a0,a0
ret

```

[Bug fortran/106579] ieee_signaling_nan problem in fortran on powerpc64

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

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

--- Comment #6 from Jakub Jelinek  ---
Created attachment 53438
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53438=edit
gcc13-builtin-issignaling.patch

Current WIP on the __builtin_issignaling.
Still need to look at decimal arguments (if we need/want to deal with those)
and add i386 issignalingxf2 optab so that it also handles pseudo numbers and
add test coverage.

[Bug analyzer/106551] [13 Regression] dup2 causes -fanalyzer ICE in valid_to_unchecked_state, at analyzer/sm-fd.cc:751

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Immad Mir :

https://gcc.gnu.org/g:837142257cbde3cc03ee0dacd1d7b2fb4fa48bae

commit r13-2023-g837142257cbde3cc03ee0dacd1d7b2fb4fa48bae
Author: Immad Mir 
Date:   Thu Aug 11 21:45:54 2022 +0530

analyzer: fix ICE casued by dup2 in sm-fd.cc[PR106551]

This patch fixes the ICE caused by valid_to_unchecked_state,
at analyzer/sm-fd.cc by handling the m_start state in
check_for_dup.

Tested lightly on x86_64.

gcc/analyzer/ChangeLog:
PR analyzer/106551
* sm-fd.cc (check_for_dup): handle the m_start
state when transitioning the state of LHS
of dup, dup2 and dup3 call.

gcc/testsuite/ChangeLog:
* gcc.dg/analyzer/fd-dup-1.c: New testcases.
* gcc.dg/analyzer/fd-uninit-1.c: Remove bogus
warning.
Signed-off-by: Immad Mir 

[Bug target/106585] RISC-V: Mis-optimized code gen for zbs

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

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

--- Comment #4 from Kito Cheng  ---
> It uses X iterator here instead of GPR, hmmm ...

I think that because we have w-variant before, so use X rather than GPR here,
but apparently we should revise this.

[Bug c++/89780] -Wpessimizing-move is too agressive with templates and recommends pessimization

[herring at lanl dot gov via Gcc-bugs]

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

--- Comment #7 from S. Davis Herring  ---
> In the withMove case, in C++20, we issue:
> warning: moving a local object in a return statement prevents copy elision
> for
> template Dest withMove();
> and:
> warning: redundant move in return statement
> for
> template Dest withMove();

Each of these in isolation is of course correct (which was of course never in
question).

> With my patch, we won't issue any warnings, because I'm not sure if we
> can say that in *any* instantiation of withMove the std::move is
> wrong.  Am I mistaken?

P1825R0 makes it much less likely that removing the std::move is ever a
problem.  There are cases that still need it, like

  struct A {
operator Dest() &&;
  };
  template Dest withMove();

That said, P2266R3 makes even that case work without std::move in C++23, and
GCC and Clang already accept it without std::move in C++20 mode (even though
it's not listed as a defect report).  I think that in these modes it's
impossible to need the std::move, so it's reasonable to issue the warning,
although it might make the most sense to issue a single, generic warning like
"std::move is either useless or harmful here depending on instantiation".

> Thanks for your comments and sorry if I'm still not getting your point.

Thank you for trying to work past my first unclear explanation.

[Bug target/106585] RISC-V: Mis-optimized code gen for zbs

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

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

--- Comment #3 from Andrew Pinski  ---
(define_insn "*bset"
  [(set (match_operand:X 0 "register_operand" "=r")
(ior:X (ashift:X (const_int 1)
 (match_operand:QI 2 "register_operand" "r"))
   (match_operand:X 1 "register_operand" "r")))]
  "TARGET_ZBS"
  "bset\t%0,%1,%2"
  [(set_attr "type" "bitmanip")])

It uses X iterator here instead of GPR, hmmm ...

[Bug target/106585] RISC-V: Mis-optimized code gen for zbs

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

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

--- Comment #2 from Andrew Pinski  ---
One issue is RV32i_zbb produces:
(insn 8 4 9 2 (set (reg:SI 78)
(ashift:SI (const_int 1 [0x1])
(subreg:QI (reg/v:SI 76 [ rs2 ]) 0))) "t6.c":3:20 323 {*bsetsi_1}
 (expr_list:REG_DEAD (reg/v:SI 76 [ rs2 ])
(nil)))


While RV64i_zbb does not match:
(insn 7 4 8 2 (set (reg:SI 79)
(const_int 1 [0x1])) "t6.c":3:20 140 {*movsi_internal}
 (nil))
(insn 8 7 9 2 (set (reg:SI 78)
(ashift:SI (reg:SI 79)
(subreg:QI (reg/v:DI 76 [ rs2 ]) 0))) "t6.c":3:20 154 {ashlsi3}
 (expr_list:REG_DEAD (reg:SI 79)
(expr_list:REG_DEAD (reg/v:DI 76 [ rs2 ])
(expr_list:REG_EQUAL (ashift:SI (const_int 1 [0x1])
(subreg:QI (reg/v:DI 76 [ rs2 ]) 0))
(nil)

[Bug target/106585] RISC-V: Mis-optimized code gen for zbs

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

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

--- Comment #1 from Andrew Pinski  ---
Interesting rv32i_zbb produces:
foo:
bclra0,a0,a1
ret

[Bug target/106585] RISC-V: Mis-optimized code gen for zbs

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug target/106532] riscv fails to build enabling ZBA/ZBB/ZBC/ZBS by default for 32bit

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

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

Kito Cheng  changed:

   What|Removed |Added

 CC||kito at gcc dot gnu.org

--- Comment #9 from Kito Cheng  ---
HI Andrew:

That's would be great if you can back port to GCC 12 branch, and thanks for
your quick fix :)

[Bug c++/106584] g++ not showing correct line number in "use of deleted function" error

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

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

--- Comment #4 from Andrew Pinski  ---
Actually clang references the call:
f(cl);

When it comes to the copy constructor.

[Bug c++/106584] g++ not showing correct line number in "use of deleted function" error

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||diagnostic

--- Comment #3 from Andrew Pinski  ---
clang prints out the similar message (even with libc++).

[Bug target/106585] New: RISC-V: Mis-optimized code gen for zbs

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

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

Bug ID: 106585
   Summary: RISC-V: Mis-optimized code gen for zbs
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kito at gcc dot gnu.org
  Target Milestone: ---
Target: riscv

Command:
$ riscv64-unknown-elf-gcc foo.c -o - -S -O3 -march=rv64imafdc_zbb_zbs

```c
int foo(int rs1, int rs2) {
  return (rs1 & ~(1<

[Bug target/99888] Add powerpc ELFv2 support for -fpatchable-function-entry*

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

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

--- Comment #7 from Segher Boessenkool  ---
'-fpatchable-function-entry=N[,M]'
 Generate N NOPs right at the beginning of each function, with the
 function entry point before the Mth NOP.

The nops have to be consecutive.

RE: [PATCH][AArch64] Implement ACLE Data Intrinsics

[Kyrylo Tkachov via Gcc-patches]

> -Original Message-
> From: Andre Vieira (lists) 
> Sent: Thursday, August 11, 2022 4:11 PM
> To: gcc-patches@gcc.gnu.org; Kyrylo Tkachov ;
> Richard Sandiford ; Richard Biener
> 
> Subject: Re: [PATCH][AArch64] Implement ACLE Data Intrinsics
> 
> OK to backport this to gcc-12? Applies cleanly and did a bootstrat and
> regression test on aarch64-linux-gnu

Ok as long as it's before the branch freeze.
Thanks,
Kyrill

> 
> Regards,
> Andre
> 
> On 01/07/2022 12:26, Richard Sandiford wrote:
> > "Andre Vieira (lists)"  writes:
> >> On 29/06/2022 08:18, Richard Sandiford wrote:
>  +  break;
>  +case AARCH64_RBIT:
>  +case AARCH64_RBITL:
>  +case AARCH64_RBITLL:
>  +  if (mode == SImode)
>  +icode = CODE_FOR_aarch64_rbitsi;
>  +  else
>  +icode = CODE_FOR_aarch64_rbitdi;
>  +  break;
>  +default:
>  +  gcc_unreachable ();
>  +}
>  +  expand_insn (icode, 2, ops);
>  +  return target;
> >>> This needs to return ops[0].value instead, since "target" just suggests
> >>> a possible location.
> >>>
> >>> Could you add tests for a memory source and memory destination, e.g.:
> >>>
> >>> void test_clz_mem (uint32_t *a)
> >>> {
> >>> *a = __clz (*a);
> >>> }
> >>>
> >>> Without tests like that, these comments probably just sound like a paper
> >>> exercise, but they should make a difference for memory sources
> (previous
> >>> review) and memory destinations (this round).
> >> I had locally tested it (with rev though because clz doesn't use that
> >> code) and strangely it does seem to work for the memory destinations,
> >> but that's just a simple test.
> >> It could very well go wrong with some more complex codegen, so I'll just
> >> take your word and use ops[0].value.
> >>
> >> And yeah I didn't add the tests at the time, don't really know why, I'll
> >> chuck it down to laziness :P
>  diff --git a/gcc/config/aarch64/arm_acle.h
> b/gcc/config/aarch64/arm_acle.h
>  index
> 9775a48c65825b424d3eb442384f5ab87b734fd7..a044bc74553fcf2a49b71290
> 083f3f072fd5a2ce 100644
>  --- a/gcc/config/aarch64/arm_acle.h
>  +++ b/gcc/config/aarch64/arm_acle.h
>  @@ -28,6 +28,7 @@
> #define _GCC_ARM_ACLE_H
> 
> #include 
>  +#include 
> 
> #pragma GCC aarch64 "arm_acle.h"
> 
>  @@ -35,6 +36,58 @@
> extern "C" {
> #endif
> 
>  +#define _GCC_ARM_ACLE_ROR_FN(NAME, TYPE)
> \
>  +__extension__ extern __inline TYPE
> \
>  +__attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
> \
>  +NAME (TYPE __value, uint32_t __rotate)
> \
>  +{   
>    \
>  +  size_t __size = sizeof (TYPE) * __CHAR_BIT__;
> \
>  +  __rotate = __rotate % __size;
> \
>  +  return __value >> __rotate | __value << ((__size - __rotate) % 
>  __size);
> \
>  +}
>  +
>  +_GCC_ARM_ACLE_ROR_FN (__ror, uint32_t)
>  +_GCC_ARM_ACLE_ROR_FN (__rorl, unsigned long)
>  +_GCC_ARM_ACLE_ROR_FN (__rorll, uint64_t)
>  +
>  +#undef _GCC_ARM_ACLE_ROR_FN
>  +
>  +#define _GCC_ARM_ACLE_DATA_FN(NAME, BUILTIN, ITYPE, RTYPE)
>   \
>  +__extension__ extern __inline RTYPE \
>  +__attribute__ ((__always_inline__, __gnu_inline__, __artificial__)) \
>  +__##NAME (ITYPE __value)\
>  +{   \
>  +  return __builtin_##BUILTIN (__value); \
>  +}
>  +
>  +_GCC_ARM_ACLE_DATA_FN (clz, clz, uint32_t, unsigned int)
>  +_GCC_ARM_ACLE_DATA_FN (clzl, clzl, unsigned long, unsigned int)
>  +_GCC_ARM_ACLE_DATA_FN (clzll, clzll, uint64_t, unsigned int)
>  +_GCC_ARM_ACLE_DATA_FN (cls, clrsb, uint32_t, unsigned int)
>  +_GCC_ARM_ACLE_DATA_FN (clsl, clrsbl, unsigned long, unsigned int)
>  +_GCC_ARM_ACLE_DATA_FN (clsll, clrsbll, uint64_t, unsigned int)
>  +_GCC_ARM_ACLE_DATA_FN (rev16, aarch64_rev16, uint32_t,
> uint32_t)
>  +_GCC_ARM_ACLE_DATA_FN (rev16l, aarch64_rev16l, unsigned long,
> unsigned long)
>  +_GCC_ARM_ACLE_DATA_FN (rev16ll, aarch64_rev16ll, uint64_t,
> uint64_t)
>  +_GCC_ARM_ACLE_DATA_FN (rbit, aarch64_rbit, uint32_t, uint32_t)
>  +_GCC_ARM_ACLE_DATA_FN (rbitl, aarch64_rbitl, unsigned long,
> unsigned long)
>  +_GCC_ARM_ACLE_DATA_FN (rbitll, aarch64_rbitll, uint64_t, uint64_t)
>  +_GCC_ARM_ACLE_DATA_FN (revsh, bswap16, int16_t, uint16_t)
> >>> The return type should be int16_t.
> >> Nice catch!
> >>> The clz and cls tests have the old return types (same as the argument
> >>> types), but I guess that's a good thing, since it shows that we avoid
> >>> the redundant zero-extend in clzll and clsll.
> >> Yeah I noticed that too when I was adding the 

[Bug c++/106584] g++ not showing correct line number in "use of deleted function" error

[accelerator0099 at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Devourer Station  ---
Created attachment 53437
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53437=edit
compiler's output

[Bug c++/106584] g++ not showing correct line number in "use of deleted function" error

[accelerator0099 at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Devourer Station  ---
Created attachment 53436
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53436=edit
Preprocessed source file

compile with g++ example.cpp -c

[Bug c++/106584] New: g++ not showing correct line number in "use of deleted function" error

[accelerator0099 at gmail dot com via Gcc-bugs]

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

Bug ID: 106584
   Summary: g++ not showing correct line number in "use of deleted
function" error
   Product: gcc
   Version: 12.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: accelerator0099 at gmail dot com
  Target Milestone: ---

Example code:

#include 
#include 

using int_map = std::map>;

void f(int_map cl);

void f2() {
int_map cl;
f(cl);
}


The actual error is that int_map is not copiable, so line 10 is ill-formed
But the compiler doesn't tell you anything about line 10, it just prints tons
of waste

This is unreasonable. You may make such a careless mistake (missing a '&') in
thousands of lines, the compiler should locate where the error is for you.

Re: [PATCH][AArch64] Implement ACLE Data Intrinsics

[Andre Vieira (lists) via Gcc-patches]

OK to backport this to gcc-12? Applies cleanly and did a bootstrat and 
regression test on aarch64-linux-gnu


Regards,
Andre

On 01/07/2022 12:26, Richard Sandiford wrote:

"Andre Vieira (lists)"  writes:

On 29/06/2022 08:18, Richard Sandiford wrote:

+  break;
+case AARCH64_RBIT:
+case AARCH64_RBITL:
+case AARCH64_RBITLL:
+  if (mode == SImode)
+   icode = CODE_FOR_aarch64_rbitsi;
+  else
+   icode = CODE_FOR_aarch64_rbitdi;
+  break;
+default:
+  gcc_unreachable ();
+}
+  expand_insn (icode, 2, ops);
+  return target;

This needs to return ops[0].value instead, since "target" just suggests
a possible location.

Could you add tests for a memory source and memory destination, e.g.:

void test_clz_mem (uint32_t *a)
{
*a = __clz (*a);
}

Without tests like that, these comments probably just sound like a paper
exercise, but they should make a difference for memory sources (previous
review) and memory destinations (this round).

I had locally tested it (with rev though because clz doesn't use that
code) and strangely it does seem to work for the memory destinations,
but that's just a simple test.
It could very well go wrong with some more complex codegen, so I'll just
take your word and use ops[0].value.

And yeah I didn't add the tests at the time, don't really know why, I'll
chuck it down to laziness :P

diff --git a/gcc/config/aarch64/arm_acle.h b/gcc/config/aarch64/arm_acle.h
index 
9775a48c65825b424d3eb442384f5ab87b734fd7..a044bc74553fcf2a49b71290083f3f072fd5a2ce
 100644
--- a/gcc/config/aarch64/arm_acle.h
+++ b/gcc/config/aarch64/arm_acle.h
@@ -28,6 +28,7 @@
   #define _GCC_ARM_ACLE_H
   
   #include 

+#include 
   
   #pragma GCC aarch64 "arm_acle.h"
   
@@ -35,6 +36,58 @@

   extern "C" {
   #endif
   
+#define _GCC_ARM_ACLE_ROR_FN(NAME, TYPE)  \

+__extension__ extern __inline TYPE   \
+__attribute__ ((__always_inline__, __gnu_inline__, __artificial__))  \
+NAME (TYPE __value, uint32_t __rotate)   \
+{\
+  size_t __size = sizeof (TYPE) * __CHAR_BIT__;
  \
+  __rotate = __rotate % __size;
  \
+  return __value >> __rotate | __value << ((__size - __rotate) % __size); \
+}
+
+_GCC_ARM_ACLE_ROR_FN (__ror, uint32_t)
+_GCC_ARM_ACLE_ROR_FN (__rorl, unsigned long)
+_GCC_ARM_ACLE_ROR_FN (__rorll, uint64_t)
+
+#undef _GCC_ARM_ACLE_ROR_FN
+
+#define _GCC_ARM_ACLE_DATA_FN(NAME, BUILTIN, ITYPE, RTYPE) \
+__extension__ extern __inline RTYPE\
+__attribute__ ((__always_inline__, __gnu_inline__, __artificial__)) \
+__##NAME (ITYPE __value)   \
+{  \
+  return __builtin_##BUILTIN (__value);\
+}
+
+_GCC_ARM_ACLE_DATA_FN (clz, clz, uint32_t, unsigned int)
+_GCC_ARM_ACLE_DATA_FN (clzl, clzl, unsigned long, unsigned int)
+_GCC_ARM_ACLE_DATA_FN (clzll, clzll, uint64_t, unsigned int)
+_GCC_ARM_ACLE_DATA_FN (cls, clrsb, uint32_t, unsigned int)
+_GCC_ARM_ACLE_DATA_FN (clsl, clrsbl, unsigned long, unsigned int)
+_GCC_ARM_ACLE_DATA_FN (clsll, clrsbll, uint64_t, unsigned int)
+_GCC_ARM_ACLE_DATA_FN (rev16, aarch64_rev16, uint32_t, uint32_t)
+_GCC_ARM_ACLE_DATA_FN (rev16l, aarch64_rev16l, unsigned long, unsigned long)
+_GCC_ARM_ACLE_DATA_FN (rev16ll, aarch64_rev16ll, uint64_t, uint64_t)
+_GCC_ARM_ACLE_DATA_FN (rbit, aarch64_rbit, uint32_t, uint32_t)
+_GCC_ARM_ACLE_DATA_FN (rbitl, aarch64_rbitl, unsigned long, unsigned long)
+_GCC_ARM_ACLE_DATA_FN (rbitll, aarch64_rbitll, uint64_t, uint64_t)
+_GCC_ARM_ACLE_DATA_FN (revsh, bswap16, int16_t, uint16_t)

The return type should be int16_t.

Nice catch!

The clz and cls tests have the old return types (same as the argument
types), but I guess that's a good thing, since it shows that we avoid
the redundant zero-extend in clzll and clsll.

Yeah I noticed that too when I was adding the mem tests, but I did
change them though because at the time it just felt like an oversight,
though I too was pleasantly surprised GCC was managing to avoid the
zero-extending :)
I then saw your comment and made me wonder whether I should keep the
wrong return types in... I haven't but happy to change them back if you
think it's a nice 'test' to have.

I thought it was OK/useful as it was, but I don't mind either way.

BTW, while trying it out locally, I noticed:

   aarch64_init_data_intrinsics

was called from the wrong place.  Since it's adding normal __builtin
functions, it should be called from aarch64_general_init_builtins
instead of handle_arm_acle_h.

handle_arm_acle_h is instead for cases where we want to simulate
C/C++ definitions of the ACLE intrinsics themselves (i.e. so that
the intrinsics themselves are built-in functions, rather than
inline 

Re: [PATCH] Tame path_range_query::compute_imports

[Aldy Hernandez via Gcc-patches]

On Thu, Aug 11, 2022 at 3:59 PM Andrew MacLeod  wrote:
>
>
> On 8/11/22 07:42, Richard Biener wrote:
> > This avoids going BBs outside of the path when adding def chains
> > to the set of imports.  It also syncs the code with
> > range_def_chain::get_def_chain to not miss out on some imports
> > this function would identify.
> >
> > Bootstrap / regtest pending on x86_64-unknown-linux-gnu.
> >
> > The question still stands on what the path_range_query::compute_ranges
> > actually needs in its m_imports - at least I don't easily see how
> > the range-folds will use the path range cache or be path sensitive
> > at all.
>
> All the range folding code is in gimple_range_fold.{h,cc}, and its
> driven by the mystical FUR_source classes.  fur_source stands for
> Fold_Using_Range source, and its basically just an API class which all
> the folding routines use to make queries. it is used by all the fold
> routines to ask any questions about valueizing relations,  ssa name,
> etc..   but abstracts the actual source of the information. Its the
> distillation from previous incarnations where I use to pass an edge, a
> stmt and other stuff to each routine that it might need, and decided to
> abstract since it was very unwieldy.  The base class requires only a
> range_query which is then used for all queries.

Note that not only is ranger and path_query a range_query, so is
vr_values from legacy land.  It all shares the same API.  And the
simplify_using_ranges class takes a range_query, so it can work with
legacy or ranger, or even (untested) the path_query class.

>
> Then I derive fur_stmt which is instantiated additionally with the stmt
> you wish to fold at, and it will perform queries using that stmt as the
> context source..   Any requests for ranges/relations/etc will occur as
> if that stmt location is the source.  If folding a particular stmt, you
> use that stmt as the fur_stmt source.  This is also how I do
> recalculations..  when we see
> bb4:
>a_32 = f_16 + 10
> <...>
> bb88:
>if (f_16 < 20)
>   b_8 = a_32 + 8
> and there is sufficient reason to think that a_32 would have a different
> value , we can invoke a re-fold of a_32's defintion stmt at the use
> point in b_8..  using that stmt as the fur_source. Ranger will take into
> account the range of f_16 being [0,19] at that spot, and recalculate
> a_32 as [10,29].  Its expensive to do this at every use point, so we
> only do it if we think there is a good reason at this point.
>
> The point is that the fur_source mechanism is how we provide a context,
> and that class talkes care of the details of what the source actually is.
>
> There are other fur_sources.. fur_edge allows all the same questions to
> be answered, but using an edge as the source. Meaning we can calculate
> an arbitrary stmt/expressions as if it occurs on an edge.
>
> There are also a couple of specialized fur_sources.. there is an
> internal one in ranger which communicates some other information called
> fur_depend which acts like range_of_stmt, but with additional
> functionality to register dependencies in GORI as they are seen.

This is a really good explanation.  I think you should save it and
included it in the documentation when you/we get around to writing it
;-).

>
> Aldy overloads the fur_depend class (called jt_fur_source--  Im not sure
> the origination of the name) to work with the values in the path_query
> class.   You will note that the path_range_query class inherits from a
> range_query, so it supports all the range_of_expr, range_of_stmt, and
> range_on_edge aspect of rangers API.

The name comes from "jump thread" fur_source.  I should probably
rename that to path_fur_source.  Note that even though the full
range_query API is available in path_range_query, only range_of_expr
and range_of_stmt are supported (or tested).  As I mention in the
comment for the class:

// This class is a basic block path solver.  Given a set of BBs
// indicating a path through the CFG, range_of_expr and range_of_stmt
// will calculate the range of an SSA or STMT as if the BBs in the
// path would have been executed in order.

So using range_on_edge would probably give unexpected results, using
stuff in the cache as it would appear at the end of the path, or some
such.  We could definitely harden this class and make it work solidly
across the entire API, but we've had no uses so far for anything but
range_of_expr and range_of_stmt-- and even those are only supported
for a range as it would appear at the end of the path.  So if you call
range_of_expr with a statement anywhere but the end of the path,
you're asking for trouble.

>
> I believe all attempts are first made to pick up the value from the path
> cache, and failing that, a query is made from ranger at the start of the
> path.  So as the walk thru the path happens, and edges are taken/chosen,
> all the context information local to the path should be placed into the
> path cache, and used in any future queries using the 

[Bug sanitizer/106558] ASan failed to detect a global-buffer-overflow

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

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

--- Comment #9 from Jakub Jelinek  ---
If maybe_get_single_definition returns a SSA_NAME or is_gimple_min_invariant,
then it is ok as is and doesn't need anything new.
Otherwise I think we need to ask the alias oracle.

[Bug c/106582] Wrong code generation resulting in HardFault

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

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

--- Comment #4 from Andrew Pinski  ---
>
080157fe:   movsr3, #0
08015800:   ldr.w   r2, [r9, #20]
08015804:   str r2, [r3, #12]

This is doing a store at the address 12 which is invalid normally.
I suspect for your code you need -fno-delete-null-pointer-checks .

Or you are missing a null pointer check.

The code does:
   if (pQueryChunk && ioIsValid(pRawChunk))
   {
pQueryChunk->pSrcDriver = pRawChunk->pSrcDriver;
   }
   else
   {
if (pParser)
{
 pQueryChunk->pSrcDriver = pParser->pSourceDriver;
}
   }

But the store for "pQueryChunk->pSrcDriver" is not checked to see if
pQueryChunk was a non-null pointer before doing the store after the check that
pParser was a non-null pointer.


That is I don't think this is a bug in GCC.

[Bug sanitizer/106558] ASan failed to detect a global-buffer-overflow

[tetra2005 at gmail dot com via Gcc-bugs]

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

--- Comment #8 from Yuri Gribov  ---
(In reply to Jakub Jelinek from comment #7)

I've started work on this but I'll probly only have enough time to cook a patch
on weekend.

> Perhaps either a quick check that for base ptrs that live in memory

A silly question, such cases (base_addrs living in memory) can be identified by
  gimple *g = SSA_NAME_DEF_STMT (t);
in maybe_get_single_definition having vuses?

[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
Bug 24639 depends on bug 102633, which changed state.

Bug 102633 Summary: [11/12 Regression] warning for self-initialization despite 
-Wno-init-self
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102633

   What|Removed |Added

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

[Bug middle-end/102633] [11/12 Regression] warning for self-initialization despite -Wno-init-self

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

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

Marek Polacek  changed:

   What|Removed |Added

 Resolution|--- |FIXED
Summary|[11/12/13 Regression]   |[11/12 Regression] warning
   |warning for |for self-initialization
   |self-initialization despite |despite -Wno-init-self
   |-Wno-init-self  |
 Status|ASSIGNED|RESOLVED

--- Comment #9 from Marek Polacek  ---
Fixed on trunk.  Not sure about backporting this.

[Bug middle-end/102633] [11/12/13 Regression] warning for self-initialization despite -Wno-init-self

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

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

--- Comment #8 from CVS Commits  ---
The trunk branch has been updated by Marek Polacek :

https://gcc.gnu.org/g:04ce2400b35225302e0d6883bb0817378180f5d7

commit r13-2022-g04ce2400b35225302e0d6883bb0817378180f5d7
Author: Marek Polacek 
Date:   Tue Jul 26 13:55:58 2022 -0400

c-family: Honor -Wno-init-self for cv-qual vars [PR102633]

Since r11-5188-g32934a4f45a721, we drop qualifiers during l-to-r
conversion by creating a NOP_EXPR.  For e.g.

  const int i = i;

that means that the DECL_INITIAL is '(int) i' and not 'i' anymore.
Consequently, we don't suppress_warning here:

711 case DECL_EXPR:
715   if (VAR_P (DECL_EXPR_DECL (*expr_p))
716   && !DECL_EXTERNAL (DECL_EXPR_DECL (*expr_p))
717   && !TREE_STATIC (DECL_EXPR_DECL (*expr_p))
718   && (DECL_INITIAL (DECL_EXPR_DECL (*expr_p)) == DECL_EXPR_DECL
(*expr_p))
719   && !warn_init_self)
720 suppress_warning (DECL_EXPR_DECL (*expr_p), OPT_Winit_self);

because of the check on line 718 -- (int) i is not i.  So -Wno-init-self
doesn't disable the warning as it's supposed to.

The following patch fixes it by moving the suppress_warning call from
c_gimplify_expr to the front ends, at points where we haven't created
the NOP_EXPR yet.

PR middle-end/102633

gcc/c-family/ChangeLog:

* c-gimplify.cc (c_gimplify_expr) : Don't call
suppress_warning here.

gcc/c/ChangeLog:

* c-parser.cc (c_parser_initializer): Add new tree parameter.  Use
it.
Call suppress_warning.
(c_parser_declaration_or_fndef): Pass d down to
c_parser_initializer.
(c_parser_omp_declare_reduction): Pass omp_priv down to
c_parser_initializer.

gcc/cp/ChangeLog:

* decl.cc (cp_finish_decl): Call suppress_warning.

gcc/testsuite/ChangeLog:

* c-c++-common/Winit-self1.c: New test.
* c-c++-common/Winit-self2.c: New test.

[Bug c/90885] GCC should warn about 2^16 and 2^32 and 2^64 [-Wxor-used-as-pow]

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

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

--- Comment #25 from David Malcolm  ---
Created attachment 53435
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53435=edit
v1 of a patch to implement -Wxor-used-as-pow

This patch implements the warning, but doesn't work well; as noted in the text
it's implemented in the parser, when I think it might have to be implemented in
the lexer.

Attaching it here for reference (and as a backup for my hard drive).

Re: [PATCH] analyzer: fix ICE casued by dup2 in sm-fd.cc[PR106551]

[David Malcolm via Gcc-patches]

On Thu, 2022-08-11 at 14:41 +0530, Immad Mir wrote:
> This patch fixes the ICE caused by valid_to_unchecked_state,
> at analyzer/sm-fd.cc by handling the m_start state in
> check_for_dup.
> 
> Tested lightly on x86_64.
> 
> gcc/analyzer/ChangeLog:
> PR analyzer/106551
> * sm-fd.cc (check_for_dup): handle the m_start
> state when transitioning the state of LHS
> of dup, dup2 and dup3 call.
> 
> gcc/testsuite/ChangeLog:
> * gcc.dg/analyzer/fd-dup-1.c: New testcases.
> * gcc.dg/analyzer/fd-uninit-1.c: Remove bogus
> warning.
> Signed-off-by: Immad Mir 

Thanks for the updated patch; looks ready for trunk.

Dave

☺ Buildbot (GNU Toolchain): gccrust - build successful (master)

[builder--- via Gcc-rust]

A passing build has been detected on builder gccrust-opensusetw-x86_64 while 
building gccrust.

Full details are available at:
https://builder.sourceware.org/buildbot/#builders/103/builds/171

Build state: build successful
Revision: 113b830ca0f80cf02d2db993fb3850b1f8c3293e
Worker: bb1-1
Build Reason: (unknown)
Blamelist: Philip Herron 

Steps:

- 0: worker_preparation ( success )

- 1: git checkout ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/103/builds/171/steps/1/logs/stdio

- 2: rm -rf gccrs-build ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/103/builds/171/steps/2/logs/stdio

- 3: configure ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/103/builds/171/steps/3/logs/stdio

- 4: make ( warnings )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/103/builds/171/steps/4/logs/stdio
- warnings (27): 
https://builder.sourceware.org/buildbot/#builders/103/builds/171/steps/4/logs/warnings__27_

- 5: make check ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/103/builds/171/steps/5/logs/stdio
- rust.sum: 
https://builder.sourceware.org/buildbot/#builders/103/builds/171/steps/5/logs/rust_sum
- rust.log: 
https://builder.sourceware.org/buildbot/#builders/103/builds/171/steps/5/logs/rust_log

- 6: grep unexpected rust.sum ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/103/builds/171/steps/6/logs/stdio

- 7: prep ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/103/builds/171/steps/7/logs/stdio

- 8: build bunsen.cpio.gz ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/103/builds/171/steps/8/logs/stdio

- 9: fetch bunsen.cpio.gz ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/103/builds/171/steps/9/logs/stdio

- 10: unpack bunsen.cpio.gz ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/103/builds/171/steps/10/logs/stdio

- 11: pass .bunsen.source.gitname ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/103/builds/171/steps/11/logs/stdio

- 12: pass .bunsen.source.gitbranch ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/103/builds/171/steps/12/logs/stdio

- 13: pass .bunsen.source.gitrepo ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/103/builds/171/steps/13/logs/stdio

- 14: upload to bunsen ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/103/builds/171/steps/14/logs/stdio

- 15: clean up ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/103/builds/171/steps/15/logs/stdio

- 16: rm -rf gccrs-build_1 ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/103/builds/171/steps/16/logs/stdio

-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

Re: [PATCH] Tame path_range_query::compute_imports

[Andrew MacLeod via Gcc-patches]

On 8/11/22 07:42, Richard Biener wrote:

This avoids going BBs outside of the path when adding def chains
to the set of imports.  It also syncs the code with
range_def_chain::get_def_chain to not miss out on some imports
this function would identify.

Bootstrap / regtest pending on x86_64-unknown-linux-gnu.

The question still stands on what the path_range_query::compute_ranges
actually needs in its m_imports - at least I don't easily see how
the range-folds will use the path range cache or be path sensitive
at all.


All the range folding code is in gimple_range_fold.{h,cc}, and its 
driven by the mystical FUR_source classes.  fur_source stands for 
Fold_Using_Range source, and its basically just an API class which all 
the folding routines use to make queries. it is used by all the fold 
routines to ask any questions about valueizing relations,  ssa name, 
etc..   but abstracts the actual source of the information. Its the 
distillation from previous incarnations where I use to pass an edge, a 
stmt and other stuff to each routine that it might need, and decided to 
abstract since it was very unwieldy.  The base class requires only a 
range_query which is then used for all queries.


Then I derive fur_stmt which is instantiated additionally with the stmt 
you wish to fold at, and it will perform queries using that stmt as the 
context source..   Any requests for ranges/relations/etc will occur as 
if that stmt location is the source.  If folding a particular stmt, you 
use that stmt as the fur_stmt source.  This is also how I do 
recalculations..  when we see

bb4:
  a_32 = f_16 + 10
<...>
bb88:
  if (f_16 < 20)
     b_8 = a_32 + 8
and there is sufficient reason to think that a_32 would have a different 
value , we can invoke a re-fold of a_32's defintion stmt at the use 
point in b_8..  using that stmt as the fur_source. Ranger will take into 
account the range of f_16 being [0,19] at that spot, and recalculate 
a_32 as [10,29].  Its expensive to do this at every use point, so we 
only do it if we think there is a good reason at this point.


The point is that the fur_source mechanism is how we provide a context, 
and that class talkes care of the details of what the source actually is.


There are other fur_sources.. fur_edge allows all the same questions to 
be answered, but using an edge as the source. Meaning we can calculate 
an arbitrary stmt/expressions as if it occurs on an edge.


There are also a couple of specialized fur_sources.. there is an 
internal one in ranger which communicates some other information called 
fur_depend which acts like range_of_stmt, but with additional 
functionality to register dependencies in GORI as they are seen.


Aldy overloads the fur_depend class (called jt_fur_source--  Im not sure 
the origination of the name) to work with the values in the path_query 
class.   You will note that the path_range_query class inherits from a 
range_query, so it supports all the range_of_expr, range_of_stmt, and 
range_on_edge aspect of rangers API.


I believe all attempts are first made to pick up the value from the path 
cache, and failing that, a query is made from ranger at the start of the 
path.  So as the walk thru the path happens, and edges are taken/chosen, 
all the context information local to the path should be placed into the 
path cache, and used in any future queries using the path_range_query.  
Ranger will only be invoked if there is no entry in the path query, and 
it would provide the range as it would appear at entry to the path.


Thats my high level understanding of how the path_query class provides 
context.


So I think to answer the other question, the m_imports list Is probably 
the list of ssa-names that may have relevant context information which 
the path_query would provide ranges during the walk instead of ranger?  
I think Aldy pre-calculates all those during the walk, and then uses 
this pre-filled cache to answer questions at the thread exit?   Thats my 
guess



K?

Thanks,
Richard.

* gimple-range-path.cc (path_range_query::compute_imports):
Restrict walking SSA defs to blocks inside the path.  Track
the same operands as range_def_chain::get_def_chain does.
---
  gcc/gimple-range-path.cc | 39 ---
  1 file changed, 28 insertions(+), 11 deletions(-)

diff --git a/gcc/gimple-range-path.cc b/gcc/gimple-range-path.cc
index 5ae374df3a2..5ff2c733b4e 100644
--- a/gcc/gimple-range-path.cc
+++ b/gcc/gimple-range-path.cc
@@ -575,18 +575,11 @@ path_range_query::compute_imports (bitmap imports, const 
vec )
  {
tree name = worklist.pop ();
gimple *def_stmt = SSA_NAME_DEF_STMT (name);
+  if (SSA_NAME_IS_DEFAULT_DEF (name)
+ || !path.contains (gimple_bb (def_stmt)))
+   continue;
  
-  if (is_gimple_assign (def_stmt))

-   {
- add_to_imports (gimple_assign_rhs1 (def_stmt), imports);
- tree rhs = gimple_assign_rhs2 (def_stmt);
- 

Re: [PATCH] rs6000: Enable generate const through pli+pli+rldimi

[Segher Boessenkool]

Hi!

On Thu, Aug 11, 2022 at 08:52:49PM +0800, Jiufu Guo wrote:
> Segher Boessenkool  writes:
> > On Wed, Aug 10, 2022 at 03:11:23PM +0800, Jiufu Guo wrote:
> >> @@ -9659,7 +9659,7 @@ (define_split
> >>  ;; When non-easy constants can go in the TOC, this should use
> >>  ;; easy_fp_constant predicate.
> >>  (define_split
> >> -  [(set (match_operand:DI 0 "int_reg_operand_not_pseudo")
> >> +  [(set (match_operand:DI 0 "gpc_reg_operand")
> >>(match_operand:DI 1 "const_int_operand"))]
> >>"TARGET_POWERPC64 && num_insns_constant (operands[1], DImode) > 1"
> >>[(set (match_dup 0) (match_dup 2))
> >
> > This is a huge change.  Do you have some indication that it helps /
> > hurts / is neutral?  Some reasoning why it is a good idea?
> Thanks for this concern! I would do more check/test for this.
> 
> The 'int_reg_operand_not_pseudo' cause this splitter only work after RA.
> Using 'int_reg_operand_not_pseudo', the code sequence "pli+sldi+paddi"
> can be used.

Yes.  Splitting early and to allowing pseudos is all good -- but this
was disallowed for a reason, supposedly.

Changing this now and then changing it back in a few weeks or months
isn't progress :-/


Segher

[PATCH] arm: unified syntax for libgcc clear_cache

[Seija Kijin via Gcc-patches]

The patch to convert all thumb1 code in libgcc to unified syntax
omitted changing all swi instructions to the current name: svc.

This patch fixes this case.

---
 libgcc/config/arm/lib1funcs.S | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libgcc/config/arm/lib1funcs.S b/libgcc/config/arm/lib1funcs.S
index 8c39c9f20a2b..19fa1462ccf3 100644
--- a/libgcc/config/arm/lib1funcs.S
+++ b/libgcc/config/arm/lib1funcs.S
@@ -1522,7 +1522,7 @@ LSYM(Lover12):
  add r7, r7, #2
 #endif
  mov r2, #0
- swi 0
+ svc 0
  do_pop {r7}
  RET
  FUNC_END clear_cache

Re: [GCC13][Patch][PR106457]improve array_at_struct_end_p for array objects (PR106457)

[Qing Zhao via Gcc-patches]

> On Aug 11, 2022, at 3:40 AM, Richard Biener  wrote:
> 
> On Wed, 10 Aug 2022, Qing Zhao wrote:
> 
>> Hi,
>> 
>> As mentioned in the bug report, I reopened this bug since the previous patch:
>> 
>> commit r13-1875-gff26f0ba68fe6e870f315d0601b596f889b89680
>> Author: Richard Biener 
>> Date:   Thu Jul 28 10:07:32 2022 +0200
>> 
>>middle-end/106457 - improve array_at_struct_end_p for array objects
>>Array references to array objects are never at struct end.
>> 
>> 
>> Didn’t resolve this bug.
>> 
>> This is a new patch, and my current work on -fstrict-flex-array depends on 
>> this patch.
>> 
>> Please take a look at the patch and let me know whether it’s good for 
>> committing.
>> 
>> Thanks.
>> 
>> Qing.
>> 
>> 
>> ==
>> 
>> [PATCH] middle-end/106457 - improve array_at_struct_end_p for array
>> objects (PR106457)
>> 
>> Array references are not handled correctly by current array_at_struct_end_p,
>> for the following array references:
>> 
>> Example 1: (from gcc/testsuite/gcc.dg/torture/pr50067-[1|2].c):
>> 
>> short a[32] = { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16,
>> 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31 };
>> ... = (*((char(*)[32])[0]))[i+8];  // this array reference
> 
> For this one we have
> 
> (gdb) p debug_generic_expr (ref_to_array)
> MEM[(char[32] *)]
> 
> at the
> 
> 12782 if (DECL_P (ref_to_array))
> 
> check.  The array referenced (char[32]) isn't the decl (which is 
> short[32]), so the referenced array (char[32]) _is_ at struct end
> since accessing index 48 is OK - it won't exceed the decl boundary.

> In fact that -Waggressive-loop-optimizations triggers with your
> patch shows it is wrong in this case - the code is perfectly
> OK, no out-of-bound access occurs.  When this warning triggers it
> hints at the code being miscompiled (we usually elide the exit
> test).

Okay, I see. 
> 
>> Example 2: (from gcc/testsuite/gcc.target/aarch64/vadd_reduc-2.c):
>> 
>> int test (uint8_t *p, uint32_t t[1][1], int n) {
>>  for (int i = 0; i < 4; i++, p++)
>>t[i][0] = ...;  // this array reference
>> ...
>> }
> 
> The parameter declaration uint32_t t[1][1] doesn't guarantee
> anything - it's just a pointer.  So we cannot reasonably
> constrain accesses to sizeof(uint32_t).  That means
> array_at_struct_end_p has to return true.

Okay.  Then again, the name of the routine “array_at_struct_end_p” is really 
confusing. -:)
> 
>> Example 3: (from gcc/testsuite/g++.dg/debug/debug5.C):
>> 
>>  int a = 1;
>>  int b = 1;
>>  int e[a][b];
>>  e[0][0] = 0;  // this array reference
> 
> That might be the only case we'd be allowed to say false.  I see
> a single call with
> 
> MEM[(int[0:D.1989][0:D.1986] *)][0]{lb: 0 sz: 4}
> 
> that is, the caller has stripped the outermost [0] already.
> The issue here is unfortunate lowering of the alloca
> with constant size we originally have here.  The array typed
> decl has type int[1] but we access it with type
> int[0:D.1989][0:D.1986].  We'd now have to prove that
> D.1989 and D.1986 are '1' (and not less).  That doesn't look
> possible in general.  Not sure if it is worth the trobble here.

Okay. 
> 
> Eventually array_at_struct_end_p isn't the correct vehicle for
> diagnostics if you desparately need to avoid 'true' for the above
> cases.  Note for the first case it's more about treating
> pointer to array with bounds in a stricter way than we do
> at the moment, not so much about arrays at struct end.  But
> array_at_struct_end_p is used to query whether we have to assume
> there's storage beyond the declared bound of an array that is
> "valid" to access (and it's valid from the middle-end point of
> view in this case).

Then, this is really NOT “array_at_struct_end_p”, it’s “array_is_flexible_p”, 
which mixes the concept of “array_at_struct_end” and array is flexible (or 
extendable).
I am Okay with the name right now in this patch, I will update the comments of 
this routine in the current patch. And update the name of the routine in a 
later cleanup patch.


Since the new FIELD DECL_NOT_FLEXARRAY for the patch -fstrict-flex-arrays:

+/* Used in a FIELD_DECL to indicate whether this field is not a flexible
+   array member.  */
+#define DECL_NOT_FLEXARRAY(NODE) \
+  (FIELD_DECL_CHECK (NODE)->decl_common.decl_not_flexarray)
+

Is ONLY for field in a structure, so it will NOT control the result for such 
flexible array access.  i.e, for all the flexible array access similar as in 
the Example 1, 2, or 3, 
They are always flexible,  -fstrict-flex-arrays should NOT control them, right?

Thanks

Qing

> 
> Richard.
> 
>> All the above array references are identified as TRUE by the current
>> array_at_struct_end_p, therefore treated as flexible array members.
>> Obviously, they are just simple array references, not an array refs
>> to the last field of a struture. The current array_at_struct_end_p handles
>> such array references incorrectly.
>> 
>> In order 

Re: ICE after folding svld1rq to vec_perm_expr duing forwprop

[Prathamesh Kulkarni via Gcc-patches]

On Tue, 9 Aug 2022 at 18:42, Richard Biener  wrote:
>
> On Tue, Aug 9, 2022 at 12:10 PM Prathamesh Kulkarni
>  wrote:
> >
> > On Mon, 8 Aug 2022 at 14:27, Richard Biener  
> > wrote:
> > >
> > > On Mon, Aug 1, 2022 at 5:17 AM Prathamesh Kulkarni
> > >  wrote:
> > > >
> > > > On Thu, 21 Jul 2022 at 12:21, Richard Biener 
> > > >  wrote:
> > > > >
> > > > > On Wed, Jul 20, 2022 at 5:36 PM Prathamesh Kulkarni
> > > > >  wrote:
> > > > > >
> > > > > > On Mon, 18 Jul 2022 at 11:57, Richard Biener 
> > > > > >  wrote:
> > > > > > >
> > > > > > > On Fri, Jul 15, 2022 at 3:49 PM Prathamesh Kulkarni
> > > > > > >  wrote:
> > > > > > > >
> > > > > > > > On Thu, 14 Jul 2022 at 17:22, Richard Sandiford
> > > > > > > >  wrote:
> > > > > > > > >
> > > > > > > > > Richard Biener  writes:
> > > > > > > > > > On Thu, Jul 14, 2022 at 9:55 AM Prathamesh Kulkarni
> > > > > > > > > >  wrote:
> > > > > > > > > >>
> > > > > > > > > >> On Wed, 13 Jul 2022 at 12:22, Richard Biener 
> > > > > > > > > >>  wrote:
> > > > > > > > > >> >
> > > > > > > > > >> > On Tue, Jul 12, 2022 at 9:12 PM Prathamesh Kulkarni via 
> > > > > > > > > >> > Gcc-patches
> > > > > > > > > >> >  wrote:
> > > > > > > > > >> > >
> > > > > > > > > >> > > Hi Richard,
> > > > > > > > > >> > > For the following test:
> > > > > > > > > >> > >
> > > > > > > > > >> > > svint32_t f2(int a, int b, int c, int d)
> > > > > > > > > >> > > {
> > > > > > > > > >> > >   int32x4_t v = (int32x4_t) {a, b, c, d};
> > > > > > > > > >> > >   return svld1rq_s32 (svptrue_b8 (), [0]);
> > > > > > > > > >> > > }
> > > > > > > > > >> > >
> > > > > > > > > >> > > The compiler emits following ICE with -O3 
> > > > > > > > > >> > > -mcpu=generic+sve:
> > > > > > > > > >> > > foo.c: In function ‘f2’:
> > > > > > > > > >> > > foo.c:4:11: error: non-trivial conversion in 
> > > > > > > > > >> > > ‘view_convert_expr’
> > > > > > > > > >> > > 4 | svint32_t f2(int a, int b, int c, int d)
> > > > > > > > > >> > >   |   ^~
> > > > > > > > > >> > > svint32_t
> > > > > > > > > >> > > __Int32x4_t
> > > > > > > > > >> > > _7 = VIEW_CONVERT_EXPR<__Int32x4_t>(_8);
> > > > > > > > > >> > > during GIMPLE pass: forwprop
> > > > > > > > > >> > > dump file: foo.c.109t.forwprop2
> > > > > > > > > >> > > foo.c:4:11: internal compiler error: verify_gimple 
> > > > > > > > > >> > > failed
> > > > > > > > > >> > > 0xfda04a verify_gimple_in_cfg(function*, bool)
> > > > > > > > > >> > > ../../gcc/gcc/tree-cfg.cc:5568
> > > > > > > > > >> > > 0xe9371f execute_function_todo
> > > > > > > > > >> > > ../../gcc/gcc/passes.cc:2091
> > > > > > > > > >> > > 0xe93ccb execute_todo
> > > > > > > > > >> > > ../../gcc/gcc/passes.cc:2145
> > > > > > > > > >> > >
> > > > > > > > > >> > > This happens because, after folding svld1rq_s32 to 
> > > > > > > > > >> > > vec_perm_expr, we have:
> > > > > > > > > >> > >   int32x4_t v;
> > > > > > > > > >> > >   __Int32x4_t _1;
> > > > > > > > > >> > >   svint32_t _9;
> > > > > > > > > >> > >   vector(4) int _11;
> > > > > > > > > >> > >
> > > > > > > > > >> > >:
> > > > > > > > > >> > >   _1 = {a_3(D), b_4(D), c_5(D), d_6(D)};
> > > > > > > > > >> > >   v_12 = _1;
> > > > > > > > > >> > >   _11 = v_12;
> > > > > > > > > >> > >   _9 = VEC_PERM_EXPR <_11, _11, { 0, 1, 2, 3, ... }>;
> > > > > > > > > >> > >   return _9;
> > > > > > > > > >> > >
> > > > > > > > > >> > > During forwprop, simplify_permutation simplifies 
> > > > > > > > > >> > > vec_perm_expr to
> > > > > > > > > >> > > view_convert_expr,
> > > > > > > > > >> > > and the end result becomes:
> > > > > > > > > >> > >   svint32_t _7;
> > > > > > > > > >> > >   __Int32x4_t _8;
> > > > > > > > > >> > >
> > > > > > > > > >> > > ;;   basic block 2, loop depth 0
> > > > > > > > > >> > > ;;pred:   ENTRY
> > > > > > > > > >> > >   _8 = {a_2(D), b_3(D), c_4(D), d_5(D)};
> > > > > > > > > >> > >   _7 = VIEW_CONVERT_EXPR<__Int32x4_t>(_8);
> > > > > > > > > >> > >   return _7;
> > > > > > > > > >> > > ;;succ:   EXIT
> > > > > > > > > >> > >
> > > > > > > > > >> > > which causes the error duing verify_gimple since 
> > > > > > > > > >> > > VIEW_CONVERT_EXPR
> > > > > > > > > >> > > has incompatible types (svint32_t, int32x4_t).
> > > > > > > > > >> > >
> > > > > > > > > >> > > The attached patch disables simplification of 
> > > > > > > > > >> > > VEC_PERM_EXPR
> > > > > > > > > >> > > in simplify_permutation, if lhs and rhs have non 
> > > > > > > > > >> > > compatible types,
> > > > > > > > > >> > > which resolves ICE, but am not sure if it's the 
> > > > > > > > > >> > > correct approach ?
> > > > > > > > > >> >
> > > > > > > > > >> > It for sure papers over the issue.  I think the error 
> > > > > > > > > >> > happens earlier,
> > > > > > > > > >> > the V_C_E should have been built with the type of the 
> > > > > > > > > >> > VEC_PERM_EXPR
> > > > > > > > > >> > which is the type of the LHS.  But then you probably run 
> > > > > > > > > >> > into the
> > > > > > > > > >> > 

[Bug c++/53164] Undefined reference to template function instantiation

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

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

Patrick Palka  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |12.2

--- Comment #6 from Patrick Palka  ---
Fixed for GCC 12.2/13

Re: [PATCH] Tame path_range_query::compute_imports

[Aldy Hernandez via Gcc-patches]

OK

On Thu, Aug 11, 2022, 13:42 Richard Biener  wrote:

> This avoids going BBs outside of the path when adding def chains
> to the set of imports.  It also syncs the code with
> range_def_chain::get_def_chain to not miss out on some imports
> this function would identify.
>
> Bootstrap / regtest pending on x86_64-unknown-linux-gnu.
>
> The question still stands on what the path_range_query::compute_ranges
> actually needs in its m_imports - at least I don't easily see how
> the range-folds will use the path range cache or be path sensitive
> at all.
>
> OK?
>
> Thanks,
> Richard.
>
> * gimple-range-path.cc (path_range_query::compute_imports):
> Restrict walking SSA defs to blocks inside the path.  Track
> the same operands as range_def_chain::get_def_chain does.
> ---
>  gcc/gimple-range-path.cc | 39 ---
>  1 file changed, 28 insertions(+), 11 deletions(-)
>
> diff --git a/gcc/gimple-range-path.cc b/gcc/gimple-range-path.cc
> index 5ae374df3a2..5ff2c733b4e 100644
> --- a/gcc/gimple-range-path.cc
> +++ b/gcc/gimple-range-path.cc
> @@ -575,18 +575,11 @@ path_range_query::compute_imports (bitmap imports,
> const vec )
>  {
>tree name = worklist.pop ();
>gimple *def_stmt = SSA_NAME_DEF_STMT (name);
> +  if (SSA_NAME_IS_DEFAULT_DEF (name)
> + || !path.contains (gimple_bb (def_stmt)))
> +   continue;
>
> -  if (is_gimple_assign (def_stmt))
> -   {
> - add_to_imports (gimple_assign_rhs1 (def_stmt), imports);
> - tree rhs = gimple_assign_rhs2 (def_stmt);
> - if (rhs && add_to_imports (rhs, imports))
> -   worklist.safe_push (rhs);
> - rhs = gimple_assign_rhs3 (def_stmt);
> - if (rhs && add_to_imports (rhs, imports))
> -   worklist.safe_push (rhs);
> -   }
> -  else if (gphi *phi = dyn_cast  (def_stmt))
> +  if (gphi *phi = dyn_cast  (def_stmt))
> {
>   for (size_t i = 0; i < gimple_phi_num_args (phi); ++i)
> {
> @@ -599,6 +592,30 @@ path_range_query::compute_imports (bitmap imports,
> const vec )
> worklist.safe_push (arg);
> }
> }
> +  else if (gassign *ass = dyn_cast  (def_stmt))
> +   {
> + tree ssa[3];
> + if (range_op_handler (ass))
> +   {
> + ssa[0] = gimple_range_ssa_p (gimple_range_operand1 (ass));
> + ssa[1] = gimple_range_ssa_p (gimple_range_operand2 (ass));
> + ssa[2] = NULL_TREE;
> +   }
> + else if (gimple_assign_rhs_code (ass) == COND_EXPR)
> +   {
> + ssa[0] = gimple_range_ssa_p (gimple_assign_rhs1 (ass));
> + ssa[1] = gimple_range_ssa_p (gimple_assign_rhs2 (ass));
> + ssa[2] = gimple_range_ssa_p (gimple_assign_rhs3 (ass));
> +   }
> + else
> +   continue;
> + for (unsigned j = 0; j < 3; ++j)
> +   {
> + tree rhs = ssa[j];
> + if (rhs && add_to_imports (rhs, imports))
> +   worklist.safe_push (rhs);
> +   }
> +   }
>  }
>// Exported booleans along the path, may help conditionals.
>if (m_resolve)
> --
> 2.35.3
>
>

Re: Possible C++ method signature warning feature?

[Paul Koning via Gcc]

> On Aug 10, 2022, at 9:25 PM, Andrew Pinski  wrote:
> 
> On Wed, Aug 10, 2022 at 6:20 PM Paul Koning via Gcc  wrote:
>> 
>> There's a C++ problem I keep running into, in a very large body of software 
>> with lots of subclassing.
>> 
>> There's a base class that defines a set of interface methods, not all pure 
>> virtual (some define the default behavior).  A number of subclasses override 
>> some but not all of these.
>> 
>> Now I find myself changing the argument list of some of these methods, so I 
>> have to change the base class definitions and also track down all the 
>> subclass redefinitions.  If I miss one of the latter, that subclass method 
>> is no longer called (it now just looks like an unrelated method with a 
>> different argument list that isn't used anywhere).  Finding these things can 
>> be hard and time consuming.
>> 
>> It would be helpful to have some way to mark a method as "this is supposed 
>> to be an override of a base class method", in other words "warn me if this 
>> method doesn't override some method in a base class".
> 
> C++11's overload keyword sounds exactly what you want.
> https://en.cppreference.com/w/cpp/language/override

Perfect!  Thanks much.

paul

[Bug tree-optimization/106514] [12/13 Regression] ranger slowness in path query

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

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

--- Comment #8 from CVS Commits  ---
The master branch has been updated by Richard Biener :

https://gcc.gnu.org/g:16b013c9d9b4d950f89821476e791bf18c1295df

commit r13-2020-g16b013c9d9b4d950f89821476e791bf18c1295df
Author: Richard Biener 
Date:   Tue Aug 9 13:37:26 2022 +0200

tree-optimization/106514 - revisit m_import compute in backward threading

This revisits how we compute imports later used for the ranger path
query during backwards threading.  The compute_imports function
of the path solver ends up pulling the SSA def chain of regular
stmts without limit and since it starts with just the gori imports
of the path exit it misses some interesting names to translate
during path discovery.  In fact with a still empty path this
compute_imports function looks like not the correct tool.

The following instead implements what it does during the path discovery
and since we add the exit block we seed the initial imports and
interesting names from just the exit conditional.  When we then
process interesting names (aka imports we did not yet see the definition
of) we prune local defs but add their uses in a similar way as
compute_imports would have done.

compute_imports also is lacking in its walking of the def chain
compared to range_def_chain::get_def_chain which for example
handles &_1->x specially through range_op_handler and
gimple_range_operand1, so the code copies this.  A fix for
compute_imports will be done separately, also fixing the unbound
walk there.

The patch also properly unwinds m_imports during the path discovery
backtracking and from a debugging session I have verified the two
sets evolve as expected now while previously behaving slightly erratic.

Fortunately the m_imports set now also is shrunken significantly for
the PR69592 testcase (aka PR106514) so that there's overall speedup
when increasing --param max-jump-thread-duplication-stmts as
15 -> 30 -> 60 -> 120 from 1s -> 2s -> 13s -> 27s to with the patch
1s -> 2s -> 4s -> 8s.

This runs into a latent issue in X which doesn't seem to expect
any PHI nodes with a constant argument on an edge inside the path.
But we now have those as interesting, for example for the ICEing
g++.dg/torture/pr100925.C which just has sth like

  if (i)
x = 1;
  else
x = 5;
  if (x == 1)
...

where we now have the path from if (i) to if (x) and the PHI for x
in the set of imports to consider for resolving x == 1 which IMHO
looks exactly like what we want.  The path_range_query::ssa_range_in_phi
papers over the issue and drops the range to varying instead of
crashing.  I didn't want to mess with this any further in this patch
(but I couldn't resist replacing the loop over PHI args with
PHI_ARG_DEF_FROM_EDGE, so mind the re-indenting).

PR tree-optimization/106514
* tree-ssa-threadbackward.cc (back_threader::find_paths_to_names):
Compute and unwind both m_imports and interesting on the fly during
path discovery.
(back_threader::find_paths): Compute the original m_imports
from just the SSA uses of the exit conditional.  Drop
handling single_succ_to_potentially_threadable_block.
* gimple-range-path.cc (path_range_query::ssa_range_in_phi): Handle
constant PHI arguments without crashing.  Use
PHI_ARG_DEF_FROM_EDGE.

* gcc.dg/tree-ssa/ssa-thread-19.c: Un-XFAIL.
* gcc.dg/tree-ssa/ssa-thread-20.c: New testcase.

[PATCH][pushed] tree-optimization/106514 - revisit m_import compute in backward threading

[Richard Biener via Gcc-patches]

FYI - this is what I pushed after re-testing.  Changed from the
previous patch is mostly the way imports are computed, see the
separate patch to fixup path_range_query::compute_imports.

The XFAILed testcase from the previous change is un-XFAILed with
this and I added a new testcase covering the difference wrt
GORI import computes.

Statistics on this patch look good.

Richard.

--

This revisits how we compute imports later used for the ranger path
query during backwards threading.  The compute_imports function
of the path solver ends up pulling the SSA def chain of regular
stmts without limit and since it starts with just the gori imports
of the path exit it misses some interesting names to translate
during path discovery.  In fact with a still empty path this
compute_imports function looks like not the correct tool.

The following instead implements what it does during the path discovery
and since we add the exit block we seed the initial imports and
interesting names from just the exit conditional.  When we then
process interesting names (aka imports we did not yet see the definition
of) we prune local defs but add their uses in a similar way as
compute_imports would have done.

compute_imports also is lacking in its walking of the def chain
compared to range_def_chain::get_def_chain which for example
handles &_1->x specially through range_op_handler and
gimple_range_operand1, so the code copies this.  A fix for
compute_imports will be done separately, also fixing the unbound
walk there.

The patch also properly unwinds m_imports during the path discovery
backtracking and from a debugging session I have verified the two
sets evolve as expected now while previously behaving slightly erratic.

Fortunately the m_imports set now also is shrunken significantly for
the PR69592 testcase (aka PR106514) so that there's overall speedup
when increasing --param max-jump-thread-duplication-stmts as
15 -> 30 -> 60 -> 120 from 1s -> 2s -> 13s -> 27s to with the patch
1s -> 2s -> 4s -> 8s.

This runs into a latent issue in X which doesn't seem to expect
any PHI nodes with a constant argument on an edge inside the path.
But we now have those as interesting, for example for the ICEing
g++.dg/torture/pr100925.C which just has sth like

  if (i)
x = 1;
  else
x = 5;
  if (x == 1)
...

where we now have the path from if (i) to if (x) and the PHI for x
in the set of imports to consider for resolving x == 1 which IMHO
looks exactly like what we want.  The path_range_query::ssa_range_in_phi
papers over the issue and drops the range to varying instead of
crashing.  I didn't want to mess with this any further in this patch
(but I couldn't resist replacing the loop over PHI args with
PHI_ARG_DEF_FROM_EDGE, so mind the re-indenting).

PR tree-optimization/106514
* tree-ssa-threadbackward.cc (back_threader::find_paths_to_names):
Compute and unwind both m_imports and interesting on the fly during
path discovery.
(back_threader::find_paths): Compute the original m_imports
from just the SSA uses of the exit conditional.  Drop
handling single_succ_to_potentially_threadable_block.
* gimple-range-path.cc (path_range_query::ssa_range_in_phi): Handle
constant PHI arguments without crashing.  Use PHI_ARG_DEF_FROM_EDGE.

* gcc.dg/tree-ssa/ssa-thread-19.c: Un-XFAIL.
* gcc.dg/tree-ssa/ssa-thread-20.c: New testcase.
---
 gcc/gimple-range-path.cc  |  52 
 gcc/testsuite/gcc.dg/tree-ssa/ssa-thread-19.c |   2 +-
 gcc/testsuite/gcc.dg/tree-ssa/ssa-thread-20.c |  15 +++
 gcc/tree-ssa-threadbackward.cc| 115 ++
 4 files changed, 131 insertions(+), 53 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/ssa-thread-20.c

diff --git a/gcc/gimple-range-path.cc b/gcc/gimple-range-path.cc
index 389faec260c..5ae374df3a2 100644
--- a/gcc/gimple-range-path.cc
+++ b/gcc/gimple-range-path.cc
@@ -276,8 +276,6 @@ void
 path_range_query::ssa_range_in_phi (vrange , gphi *phi)
 {
   tree name = gimple_phi_result (phi);
-  basic_block bb = gimple_bb (phi);
-  unsigned nargs = gimple_phi_num_args (phi);
 
   if (at_entry ())
 {
@@ -287,6 +285,7 @@ path_range_query::ssa_range_in_phi (vrange , gphi *phi)
   // Try to fold the phi exclusively with global or cached values.
   // This will get things like PHI <5(99), 6(88)>.  We do this by
   // calling range_of_expr with no context.
+  unsigned nargs = gimple_phi_num_args (phi);
   Value_Range arg_range (TREE_TYPE (name));
   r.set_undefined ();
   for (size_t i = 0; i < nargs; ++i)
@@ -303,36 +302,31 @@ path_range_query::ssa_range_in_phi (vrange , gphi *phi)
   return;
 }
 
+  basic_block bb = gimple_bb (phi);
   basic_block prev = prev_bb ();
   edge e_in = find_edge (prev, bb);
-
-  for (size_t i = 0; i < nargs; ++i)
-if (e_in == gimple_phi_arg_edge (phi, i))
-  {
-   tree arg = gimple_phi_arg_def 

Re: [PATCH] rs6000: Enable generate const through pli+pli+rldimi

[Jiufu Guo via Gcc-patches]

Hi,

Segher Boessenkool  writes:
> Hi!
>
> On Wed, Aug 10, 2022 at 03:11:23PM +0800, Jiufu Guo wrote:
>> As mentioned in PR106550, since pli could support 34bits immediate, we could
>> use less instructions(3insn would be ok) to build 64bits constant with pli.
>> 
>> For example, for constant 0x020805006106003, we could generate it with:
>> asm code1:
>> pli 9,101736451 (0x6106003)
>> sldi 9,9,32
>> paddi 9,9, 213 (0x0208050)
>> 
>> or asm code2:
>> pli 10, 213
>> pli 9, 101736451
>> rldimi 9, 10, 32, 0
>> 
>> If there is only one register can be used, then the asm code1 is ok. 
>> Otherwise
>> asm code2 may be better.
>
> It is significantly better yes.  That code with sldi is perhaps what we
> have to do after reload, but all those three insns are sequential,
> expensive.

>
>> This patch re-enable the constant building(splitter) before RA by updating 
>> the
>> constrains from int_reg_operand_not_pseudo to gpc_reg_operand.  And then, we
>> could use two different pseduo for two pli(s), and asm code2 can be 
>> generated.
>
>> This patch also could generate asm code1 if hard register is allocated for 
>> the
>> constant.
>
>> +  else if (TARGET_PREFIXED)
>> +{
>> +  /* pli 9,high32 + pli 10,low32 + rldimi 9,10,32,0.  */
>> +  if (can_create_pseudo_p ())
>> +{
>> +  temp = gen_reg_rtx (DImode);
>> +  rtx temp1 = gen_reg_rtx (DImode);
>> +  emit_move_insn (copy_rtx (temp), GEN_INT ((ud4 << 16) | ud3));
>> +  emit_move_insn (copy_rtx (temp1), GEN_INT ((ud2 << 16) | ud1));
>> +
>> +  rtx one = gen_rtx_AND (DImode, temp1, GEN_INT (0x));
>
> Why do you meed to mask the value here?  That is a nop, no?
As you mentioned, this is not needed if using gen_rotldi3_insert_3.
>
>> +  rtx two = gen_rtx_ASHIFT (DImode, temp, GEN_INT (32));
>> +  emit_move_insn (dest, gen_rtx_IOR (DImode, one, two));
>
> But you can call gen_rotldi3_insert_3 explicitly, a better idea if this
> code can run late (so we cannot rely on other optimisations to clean
> things up).
Thanks! Using gen_rotldi3_insert_3 would indicate the rotate behavior
explicitly.

emit_insn (gen_rotldi3_insert_3 (dest, temp, GEN_INT (32), temp1,
GEN_INT (0x)));

>
>> --- a/gcc/config/rs6000/rs6000.md
>> +++ b/gcc/config/rs6000/rs6000.md
>> @@ -9659,7 +9659,7 @@ (define_split
>>  ;; When non-easy constants can go in the TOC, this should use
>>  ;; easy_fp_constant predicate.
>>  (define_split
>> -  [(set (match_operand:DI 0 "int_reg_operand_not_pseudo")
>> +  [(set (match_operand:DI 0 "gpc_reg_operand")
>>  (match_operand:DI 1 "const_int_operand"))]
>>"TARGET_POWERPC64 && num_insns_constant (operands[1], DImode) > 1"
>>[(set (match_dup 0) (match_dup 2))
>
> This is a huge change.  Do you have some indication that it helps /
> hurts / is neutral?  Some reasoning why it is a good idea?
Thanks for this concern! I would do more check/test for this.

The 'int_reg_operand_not_pseudo' cause this splitter only work after RA.
Using 'int_reg_operand_not_pseudo', the code sequence "pli+sldi+paddi"
can be used.

>
> I am not against it, but some more rationale would be good :-)
>
> Btw, this splitter uses operands[2] and [3] in the replacement, and
> neither of those exists.  The replacement never is used of course.
> Instead, rs6000_emit_set_const is called always.  It would be less
> misleading if the replacement text was just "(pc)" or such.

Right, "(pc)" would be better to avoid misleading.

BR,
Jeff(Jiufu)
>
>
> Segher

[PATCH] LoongArch: Get __tls_get_addr address through got table when disable plt.

[Lulu Cheng]

thread.c:

__attribute__ ((tls_model ("global-dynamic"))) __thread int a;

void
test (void)
{
  a = 10;
}

Compile the tests with -fno-plt, error message is as follows:

thread.c: In function 'test':
thread.c:7:1: error: unrecognizable insn:
7 | }
  | ^
(call_insn/u 7 6 8 2 (parallel [
(set (reg:DI 4 $r4)
(call (mem:SI (symbol_ref:DI ("__tls_get_addr") [flags 0x41] 
) [0  S4 A8])
(const_int 0 [0])))
(clobber (reg:SI 1 $r1))
]) "thread.c":5:5 -1
 (expr_list:REG_EH_REGION (const_int -2147483648 [0x8000])
(nil))
(expr_list (use (reg:DI 4 $r4))
(nil)))
during RTL pass: vregs
thread.c:7:1: internal compiler error: in extract_insn, at recog.cc:2791


-

Fix bug, ICE with tls gd var with -fno-plt.

gcc/ChangeLog:

* config/loongarch/loongarch.cc (loongarch_call_tls_get_addr):
Get __tls_get_addr address through got table when disable plt.

gcc/testsuite/ChangeLog:

* gcc.target/loongarch/tls-gd-noplt.c: New test.
---
 gcc/config/loongarch/loongarch.cc | 14 --
 gcc/testsuite/gcc.target/loongarch/tls-gd-noplt.c | 12 
 2 files changed, 24 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/loongarch/tls-gd-noplt.c

diff --git a/gcc/config/loongarch/loongarch.cc 
b/gcc/config/loongarch/loongarch.cc
index 5c9a33c14f7..8d8232e5805 100644
--- a/gcc/config/loongarch/loongarch.cc
+++ b/gcc/config/loongarch/loongarch.cc
@@ -2297,8 +2297,18 @@ loongarch_call_tls_get_addr (rtx sym, enum 
loongarch_symbol_type type, rtx v0)
   else
 gcc_unreachable ();
 
-  insn = emit_call_insn (gen_call_value_internal (v0, loongarch_tls_symbol,
- const0_rtx));
+  if (flag_plt)
+insn = emit_call_insn (gen_call_value_internal (v0, loongarch_tls_symbol,
+   const0_rtx));
+  else
+{
+  rtx dest = gen_reg_rtx (Pmode);
+  rtx high = gen_reg_rtx (Pmode);
+  loongarch_emit_move (high, gen_rtx_HIGH (Pmode, loongarch_tls_symbol));
+  emit_insn (gen_ld_from_got (Pmode, dest, high, loongarch_tls_symbol));
+  insn = emit_call_insn (gen_call_value_internal (v0, dest, const0_rtx));
+}
+
   RTL_CONST_CALL_P (insn) = 1;
   use_reg (_INSN_FUNCTION_USAGE (insn), a0);
   insn = get_insns ();
diff --git a/gcc/testsuite/gcc.target/loongarch/tls-gd-noplt.c 
b/gcc/testsuite/gcc.target/loongarch/tls-gd-noplt.c
new file mode 100644
index 000..a71bb48676d
--- /dev/null
+++ b/gcc/testsuite/gcc.target/loongarch/tls-gd-noplt.c
@@ -0,0 +1,12 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fno-plt" } */
+/* { dg-final { scan-assembler "pcalau12i\t.*%got_pc_hi20\\(__tls_get_addr\\)" 
} } */
+
+__attribute__ ((tls_model ("global-dynamic"))) __thread int a;
+
+void
+test (void)
+{
+  a = 10;
+}
+
-- 
2.31.1

[PATCH] Tame path_range_query::compute_imports

[Richard Biener via Gcc-patches]

This avoids going BBs outside of the path when adding def chains
to the set of imports.  It also syncs the code with
range_def_chain::get_def_chain to not miss out on some imports
this function would identify.

Bootstrap / regtest pending on x86_64-unknown-linux-gnu.

The question still stands on what the path_range_query::compute_ranges
actually needs in its m_imports - at least I don't easily see how
the range-folds will use the path range cache or be path sensitive
at all.

OK?

Thanks,
Richard.

* gimple-range-path.cc (path_range_query::compute_imports):
Restrict walking SSA defs to blocks inside the path.  Track
the same operands as range_def_chain::get_def_chain does.
---
 gcc/gimple-range-path.cc | 39 ---
 1 file changed, 28 insertions(+), 11 deletions(-)

diff --git a/gcc/gimple-range-path.cc b/gcc/gimple-range-path.cc
index 5ae374df3a2..5ff2c733b4e 100644
--- a/gcc/gimple-range-path.cc
+++ b/gcc/gimple-range-path.cc
@@ -575,18 +575,11 @@ path_range_query::compute_imports (bitmap imports, const 
vec )
 {
   tree name = worklist.pop ();
   gimple *def_stmt = SSA_NAME_DEF_STMT (name);
+  if (SSA_NAME_IS_DEFAULT_DEF (name)
+ || !path.contains (gimple_bb (def_stmt)))
+   continue;
 
-  if (is_gimple_assign (def_stmt))
-   {
- add_to_imports (gimple_assign_rhs1 (def_stmt), imports);
- tree rhs = gimple_assign_rhs2 (def_stmt);
- if (rhs && add_to_imports (rhs, imports))
-   worklist.safe_push (rhs);
- rhs = gimple_assign_rhs3 (def_stmt);
- if (rhs && add_to_imports (rhs, imports))
-   worklist.safe_push (rhs);
-   }
-  else if (gphi *phi = dyn_cast  (def_stmt))
+  if (gphi *phi = dyn_cast  (def_stmt))
{
  for (size_t i = 0; i < gimple_phi_num_args (phi); ++i)
{
@@ -599,6 +592,30 @@ path_range_query::compute_imports (bitmap imports, const 
vec )
worklist.safe_push (arg);
}
}
+  else if (gassign *ass = dyn_cast  (def_stmt))
+   {
+ tree ssa[3];
+ if (range_op_handler (ass))
+   {
+ ssa[0] = gimple_range_ssa_p (gimple_range_operand1 (ass));
+ ssa[1] = gimple_range_ssa_p (gimple_range_operand2 (ass));
+ ssa[2] = NULL_TREE;
+   }
+ else if (gimple_assign_rhs_code (ass) == COND_EXPR)
+   {
+ ssa[0] = gimple_range_ssa_p (gimple_assign_rhs1 (ass));
+ ssa[1] = gimple_range_ssa_p (gimple_assign_rhs2 (ass));
+ ssa[2] = gimple_range_ssa_p (gimple_assign_rhs3 (ass));
+   }
+ else
+   continue;
+ for (unsigned j = 0; j < 3; ++j)
+   {
+ tree rhs = ssa[j];
+ if (rhs && add_to_imports (rhs, imports))
+   worklist.safe_push (rhs);
+   }
+   }
 }
   // Exported booleans along the path, may help conditionals.
   if (m_resolve)
-- 
2.35.3

[Bug fortran/106579] ieee_signaling_nan problem in fortran on powerpc64

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

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2022-08-11

--- Comment #5 from Francois-Xavier Coudert  ---
Previous discussion on the list:

- when I first implemented it in 2013:
https://gcc.gnu.org/legacy-ml/gcc/2013-11/msg00109.html
- more recent: https://www.mail-archive.com/gcc@gcc.gnu.org/msg97340.html

I think Joseph pointed (either in another bugzilla issue, or on the list) to a
first tentative implementation of __builtin_issignaling in the middle-end by
Sandra Loosemore, which had to be reversed because it caused trouble on some
targets. The difficulty that was cited (and why I didn't get to it myself) is
the large number of floating-point formats to be handled.

That said, having __builtin_issignaling() would be great and we could emit a
lot more of the IEEE functions in the front-end, if it were available.

[Bug c/106582] Wrong code generation resulting in HardFault

[jankowski938 at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Piotr  ---
(In reply to Richard Biener from comment #1)
> Can you provide preprocessed source of the file where the crash occurs and
> the compiler commandline?  Can you also try GCC 10.4 (or a compiler built
> from
> the GCC 10 branch head) or possibly even GCC 12.1 to see if the issue still
> reproduces there?

Attached preprocessed file. 

The compiler comes with STMCubeIDE and I would not manually change it. Full
command line is in the original post (excluding include and library files and
paths)

[Bug c/106582] Wrong code generation resulting in HardFault

[jankowski938 at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Piotr  ---
Created attachment 53434
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53434=edit
Preprocessed file

[Bug fortran/106579] ieee_signaling_nan problem in fortran on powerpc64

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

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

--- Comment #4 from Jakub Jelinek  ---
Ok, I'll first implement __builtin_issignaling and then
conv_intrinsic_ieee_{value,class}.

[Bug c/106582] Wrong code generation resulting in HardFault

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

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

Richard Biener  changed:

   What|Removed |Added

 Target||arm-none-eabi
   Last reconfirmed||2022-08-11
Version|10.3.0  |10.3.1
 Ever confirmed|0   |1
 Status|UNCONFIRMED |WAITING

--- Comment #1 from Richard Biener  ---
Can you provide preprocessed source of the file where the crash occurs and the
compiler commandline?  Can you also try GCC 10.4 (or a compiler built from
the GCC 10 branch head) or possibly even GCC 12.1 to see if the issue still
reproduces there?

[Bug middle-end/106578] spurious -Wuse-after-free=2 after conditional free() when not optimizing

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

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

--- Comment #4 from Gökçe Aydos  ---
Just to clarify my entry:

In my opinion gcc should not fire a warning in my first example. In case
`realloc` was not successful, then `realloc` does not touch its argument. I
should be able to use its argument in this case.

[Bug debug/100960] var-tracking: parameter location in subregister not tracked

[stefansf at linux dot ibm.com via Gcc-bugs]

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

--- Comment #6 from Stefan Schulze Frielinghaus  
---
Created attachment 53433
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53433=edit
a-t2.c.325r.vartrack