[PATCH] libsanitizer: enable libubsan and libasan for loongarch64-*-linux*

[Xi Ruoyao via Gcc-patches]

The LoongArch support for libubsan and libasan has been added in:

- https://reviews.llvm.org/D129371
- https://reviews.llvm.org/D129418

and we've merged them in r13-2269.  It's time to enable them.

No unexpected failures in GCC asan.exp and ubsan.exp tests.

libsanitizer/ChangeLog:

* configure.tgt: Allow loongarch64-*-linux*.
---
 libsanitizer/configure.tgt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/libsanitizer/configure.tgt b/libsanitizer/configure.tgt
index fb89df4935c..87d8a2c3820 100644
--- a/libsanitizer/configure.tgt
+++ b/libsanitizer/configure.tgt
@@ -72,6 +72,8 @@ case "${target}" in
;;
   riscv64-*-linux*)
;;
+  loongarch64-*-linux*)
+   ;;
   *)
UNSUPPORTED=1
;;
-- 
2.37.2

Re: [PATCH] Add _GLIBCXX_DEBUG backtrace generation

[François Dumont via Gcc-patches]

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


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

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


    --enable-libstdcxx-backtrace=yes

    libstdc++-v3/ChangeLog:

    * include/debug/formatter.h
    [_GLIBCXX_HAVE_STACKTRACE](__glibcxx_backtrace_state): Declare.
[_GLIBCXX_HAVE_STACKTRACE](__glibcxx_backtrace_create_state): Declare.
[_GLIBCXX_HAVE_STACKTRACE](__glibcxx_backtrace_full_callback): Define.
[_GLIBCXX_HAVE_STACKTRACE](__glibcxx_backtrace_error_callback): Define.
[_GLIBCXX_HAVE_STACKTRACE](__glibcxx_backtrace_full_func): Define.
    [_GLIBCXX_HAVE_STACKTRACE](__glibcxx_backtrace_full): Declare.
[_GLIBCXX_HAVE_STACKTRACE](_Error_formatter::_M_backtrace_state): New.
[_GLIBCXX_HAVE_STACKTRACE](_Error_formatter::_M_backtrace_full): New.
    * src/c++11/debug.cc 
[_GLIBCXX_HAVE_STACKTRACE](print_backtrace): New.

    (_Error_formatter::_M_error()): Adapt.
    * src/libbacktrace/Makefile.am: Add backtrace.c.
    * src/libbacktrace/Makefile.in: Regenerate.
    * src/libbacktrace/backtrace-rename.h (backtrace_full): New.
    * 
testsuite/23_containers/vector/debug/assign4_backtrace_neg.cc: New test.
    * doc/xml/manual/debug_mode.xml: Document 
_GLIBCXX_DEBUG_BACKTRACE.

    * doc/xml/manual/using.xml: Likewise.
Ok to commit ?

François

On 09/08/22 10:07, François Dumont wrote:

On 08/08/22 15:29, Jonathan Wakely wrote:

On Wed, 13 Jul 2022 at 18:28, François Dumont via Libstdc++
 wrote:

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

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

    --enable-libstdcxx-backtrace=yes

    libstdc++-v3/ChangeLog:

    * include/debug/formatter.h
    [_GLIBCXX_HAVE_STACKTRACE](__glibcxx_backtrace_state): Declare.
[_GLIBCXX_HAVE_STACKTRACE](__glibcxx_backtrace_create_state): Declare.
[_GLIBCXX_HAVE_STACKTRACE](__glibcxx_backtrace_full_callback): Define.
[_GLIBCXX_HAVE_STACKTRACE](__glibcxx_backtrace_error_callback): Define.
    [_GLIBCXX_HAVE_STACKTRACE](__glibcxx_backtrace_full_func): Define.
    [_GLIBCXX_HAVE_STACKTRACE](__glibcxx_backtrace_full): Declare.
[_GLIBCXX_HAVE_STACKTRACE](_Error_formatter::_M_backtrace_state): New.
[_GLIBCXX_HAVE_STACKTRACE](_Error_formatter::_M_backtrace_full): New.
    * src/c++11/debug.cc (pretty_print): Rename into...
    (print_function): ...that.

This does more than just rename it, what are the other changes for?


Nothing, I'm starting to remember what you did on this, reverted.






[_GLIBCXX_HAVE_STACKTRACE](print_backtrace): New.
    (_Error_formatter::_M_error()): Adapt.
    * src/libbacktrace/Makefile.am: Add backtrace.c.
    * src/libbacktrace/Makefile.in: Regenerate.
    * src/libbacktrace/backtrace-rename.h (backtrace_full): New.
    * testsuite/23_containers/vector/debug/assign4_neg.cc: Add 
backtrace

  generation.
    * doc/xml/manual/debug_mode.xml: Document _GLIBCXX_DEBUG_BACKTRACE.
    * doc/xml/manual/using.xml: Likewise.

Tested under Linux x86_64 normal and _GLIBCXX_DEBUG modes.

Ok to commit ?



--- a/libstdc++-v3/testsuite/23_containers/vector/debug/assign4_neg.cc
+++ b/libstdc++-v3/testsuite/23_containers/vector/debug/assign4_neg.cc
@@ -16,6 +16,7 @@
// .
//
// { dg-do run { xfail *-*-* } }
+// { dg-options "-D_GLIBCXX_DEBUG_BACKTRACE -lstdc++_libbacktrace" }

#include 
#include 

This will fail to link if the static lib isn't available.

Good point ! So I am introducing a new test case with the necessary dg 
directive.


It is a 'run' test case even if what is really tested is only the 
compilation/link part. For the run part someone has to look at the log 
file.


François


diff --git a/libstdc++-v3/doc/xml/manual/debug_mode.xml b/libstdc++-v3/doc/xml/manual/debug_mode.xml
index 988c4a93601..dadc0cd1bb4 100644
--- a/libstdc++-v3/doc/xml/manual/debug_mode.xml
+++ b/libstdc++-v3/doc/xml/manual/debug_mode.xml
@@ -161,6 +161,12 @@ which always works correctly.
   GLIBCXX_DEBUG_MESSAGE_LENGTH can be used to request a
   different length.
 
+Note that libstdc++ is able to produce backtraces on error.
+  It requires that you configure libstdc++ build with
+  --enable-libstdcxx-backtrace=yes.
+  Use -D_GLIBCXX_DEBUG_BACKTRACE to activate it.
+  You'll then have to link with libstdc++_libbacktrace static library
+  (-lstdc++_libbacktrace) to build your application.
 
 
 Using a Specific Debug Container
diff --git a/libstdc++-v3/doc/xml/manual/using.xml b/libstdc++-v3/doc/xml/manual/using.xml
index 0b9a0c98518..0acdba6b3bd 100644
--- a/libstdc++-v3/doc/xml/manual/using.xml
+++ b/libstdc++-v3/doc/xml/manual/using.xml
@@ -1144,6 +1144,15 @@ 

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

[François Dumont via Gcc-patches]

If I got your point correctly here is this patch again with just the 
change on '0' becoming 'nullptr' in assertions.


    libstdc++: [_GLIBCXX_DEBUG] Review nullptr assertion diagnostics

    Review null string checks to show:
    _String != nullptr

    rather than:
    _String != 0

    libstdc++-v3/ChangeLog:

    * include/debug/debug.h: Use nullptr rather than '0' in 
checks in post-C++11.

    * include/debug/string: Likewise.
    * 
testsuite/21_strings/basic_string/operations/ends_with/char.cc: Use 
__gnu_test::string.
    * 
testsuite/21_strings/basic_string/operations/ends_with/nonnull.cc: Likewise.
    * 
testsuite/21_strings/basic_string/operations/ends_with/wchar_t.cc: Likewise.
    * 
testsuite/21_strings/basic_string/operations/starts_with/wchar_t.cc: 
Likewise.
    * 
testsuite/21_strings/basic_string/operations/starts_with/nonnull.cc: 
Likewise.
    * 
testsuite/21_strings/basic_string/operations/starts_with/char.cc: Likewise..


Ok to commit ?

François

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

On Sun, 14 Aug 2022 at 16:34, François Dumont via Libstdc++
 wrote:

I think we can add those checks.

Note that I wonder if it was needed as in basic_string_view I see usages
of __attribute__((__nonnull__)). But running the test I saw no impact
even after I try to apply this attribute to the starts_with/ends_with
methods themselves.

That should cause warnings, and does when I try it.

As you say, the relevant string_view constructor already has that anyway:

   __attribute__((__nonnull__)) constexpr
   basic_string_view(const _CharT* __str) noexcept

And so does string_view::find. The problem is that those only help if
the compiler inlines the calls to those functions and so can propagate
the null value all the way down to a function with the attribute.
Adding the attribute to the relevant starts_with, ends_with and
contains functions makes the diagnostics more likely to be emitted
without optimization.


Also note that several checks like the ones I am adding here are XFAILS
when using 'make check' because of the segfault rather than on a proper
debug checks. Would you prefer to add dg-require-debug-mode to those ?

  libstdc++: [_GLIBCXX_DEBUG] Add basic_string::starts_with/ends_with
checks

  Add simple checks on C string parameters which should not be null.

  Review null string checks to show:
  _String != nullptr

  rather than:
  _String != 0

I don't really like the extra complexity in the macros, but this does
seem like a nice improvement for what users see.

We could use __null for C++98, which is a compiler keyword that
expands to a null pointer constant, but I'm not sure if that would be
clear to all users or not. Maybe 0 is better.

.


diff --git a/libstdc++-v3/include/debug/debug.h b/libstdc++-v3/include/debug/debug.h
index 28e250f0c50..f4233760426 100644
--- a/libstdc++-v3/include/debug/debug.h
+++ b/libstdc++-v3/include/debug/debug.h
@@ -118,10 +118,17 @@ namespace __gnu_debug
   __glibcxx_check_heap(_First,_Last)
 # define __glibcxx_requires_heap_pred(_First,_Last,_Pred)	\
   __glibcxx_check_heap_pred(_First,_Last,_Pred)
-# define __glibcxx_requires_string(_String)	\
+# if __cplusplus < 201103L
+#  define __glibcxx_requires_string(_String)	\
   _GLIBCXX_DEBUG_PEDASSERT(_String != 0)
-# define __glibcxx_requires_string_len(_String,_Len)	\
+#  define __glibcxx_requires_string_len(_String,_Len)	\
   _GLIBCXX_DEBUG_PEDASSERT(_String != 0 || _Len == 0)
+# else
+#  define __glibcxx_requires_string(_String)	\
+  _GLIBCXX_DEBUG_PEDASSERT(_String != nullptr)
+#  define __glibcxx_requires_string_len(_String,_Len)	\
+  _GLIBCXX_DEBUG_PEDASSERT(_String != nullptr || _Len == 0)
+# endif
 # define __glibcxx_requires_irreflexive(_First,_Last)	\
   __glibcxx_check_irreflexive(_First,_Last)
 # define __glibcxx_requires_irreflexive2(_First,_Last)	\
diff --git a/libstdc++-v3/include/debug/string b/libstdc++-v3/include/debug/string
index c32eb41eacd..574a78e3dac 100644
--- a/libstdc++-v3/include/debug/string
+++ b/libstdc++-v3/include/debug/string
@@ -50,14 +50,25 @@
 #endif
 
 #ifdef _GLIBCXX_DEBUG_PEDANTIC
-# define __glibcxx_check_string(_String)\
+# if __cplusplus < 201103L
+#  define __glibcxx_check_string(_String)			\
   _GLIBCXX_DEBUG_VERIFY_STR_COND_AT(_String != 0,		\
 __FILE__, __LINE__,		\
 __PRETTY_FUNCTION__);
-# define __glibcxx_check_string_len(_String,_Len)		\
+#  define __glibcxx_check_string_len(_String,_Len)		\
   _GLIBCXX_DEBUG_VERIFY_STR_COND_AT(_String != 0 || _Len == 0,	\
 __FILE__, __LINE__,		\
 __PRETTY_FUNCTION__);
+# else
+#  define __glibcxx_check_string(_String)			\
+  _GLIBCXX_DEBUG_VERIFY_STR_COND_AT(_String != nullptr,		\
+__FILE__, __LINE__,		\
+__PRETTY_FUNCTION__);
+#  define __glibcxx_check_string_len(_String,_Len)		\
+  _GLIBCXX_DEBUG_VERIFY_STR_COND_AT(_String != nullptr || _Len == 0,	\
+__FILE__, 

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

[Xi Ruoyao via Gcc-patches]

On Sat, 2022-07-09 at 10:11 -0600, Jeff Law via Gcc-patches wrote:

> Once Alex is OK with this patch, then it'll be good to go.
> 
> jeff

Gentle ping as a distro maintainer :).

-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

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

[John David Anglin]

On 2022-08-30 8:13 p.m., Jeff Law wrote:



On 8/28/2022 10:34 AM, John David Anglin wrote:

On 2022-08-26 3:15 a.m., Martin Liška wrote:

Removes the deprecated ports. If I'm correct all hpux9,hpux10 should be removed
as they only provide 32-bit targets. On the contrary, hpux11 supports hppa64 
that
we still do support.

It is my understanding that the 32-bit hppa hpux targets were deprecated 
because they don't
support ELF and the DWARF debug format (.stabs is to be removed). Some of the 
changes to
libtool.m4 affect the 32-bit ia64 hpux target.  As far as I know, it supports 
ELF and the DWARF
debug format.

If someone really cared, they could support dwarf on the 32bit PA SOM targets 
-- but I'm not going to lose any sleep over 32bit PA SOM:-)

Yes.  I thought about working on it.  However, although 32bit hppa-hpux lives 
on in qemu, my main focus is linux.
I also had to shutdown my dedicated hpux machine.

Dave

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

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

[Jeff Law via Gcc-patches]

On 8/28/2022 10:34 AM, John David Anglin wrote:

On 2022-08-26 3:15 a.m., Martin Liška wrote:
Removes the deprecated ports. If I'm correct all hpux9,hpux10 should 
be removed
as they only provide 32-bit targets. On the contrary, hpux11 supports 
hppa64 that

we still do support.
It is my understanding that the 32-bit hppa hpux targets were 
deprecated because they don't
support ELF and the DWARF debug format (.stabs is to be removed). Some 
of the changes to
libtool.m4 affect the 32-bit ia64 hpux target.  As far as I know, it 
supports ELF and the DWARF

debug format.
If someone really cared, they could support dwarf on the 32bit PA SOM 
targets -- but I'm not going to lose any sleep over 32bit PA SOM:-)





Possibly, the removal of ia64-hpux should be considered but I think 
it's a separate issue.
Definitely separate.  I'd support at least deprecation if we haven't 
deprecated it already.


jeff

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

[Joseph Myers]

On Tue, 30 Aug 2022, Qing Zhao via Gcc-patches wrote:

> Hi, Joseph and Nathan,
> 
> Could you please review the C and C++ FE parts of the patch?
> 
> https://gcc.gnu.org/pipermail/gcc-patches/2022-August/599901.html

I think some work is still needed on the diagnostic wording.

> +  "%qE attribute may not be specified for a non array field",

"non-array" not "non array".

> +   "not supported with a ISO C before C99", name);

"a ISO C" is not proper usage.  I think something like "by ISO C before 
C99" would be better.  Likewise "a ISO C++".

"!flag_isoc99" is more usual than "flag_isoc99 == 0".

> +   "not supported with a GNU extension GNU89", name);

"a GNU extension" suggests a particular language feature, but I think 
you're actually referring here to a whole language version rather than an 
individual feature.

In any case, -std=gnu89 supports flexible array members.  So I'd expect 
them to have exactly the same semantics as in C99, so disallowing a 
particular feature for gnu89 here seems suspect.

In the manual, any literal code should be enclosed in @code{} or @samp{}.  
That replaces the use of ASCII quotes "" that you currently have in the 
documentation (that should never be used outside of @code, @samp and 
similar).

> +When -std=gnu89 is specified or C++ with GNU extension, only zero-length 
> array

And @option{} should be used around "-std=gnu89" here (except as noted 
above, I think it's suspect to disallow parts of this feature for gnu89).

> +language. FOR ISO C before C99 and ISO C++, no language support for the 
> flexible

"FOR" should be "For".

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

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

[Joseph Myers]

On Mon, 29 Aug 2022, Jakub Jelinek via Gcc-patches wrote:

> On Mon, Aug 29, 2022 at 03:45:33PM +0200, Aldy Hernandez wrote:
> > For convenience, singleton_p() returns false for a NAN.  IMO, it makes
> > the implementation cleaner, but I'm not wed to the idea if someone
> > objects.
> 
> If singleton_p() is used to decide whether one can just replace a variable
> with singleton range with a constant, then certainly.
> If MODE_HAS_SIGNED_ZEROS, zero has 2 representations (-0.0 and 0.0) and

Note also for decimal floating point that many real numbers - if they 
don't require the full precision of the type to represent the number - can 
be represented with different quantum exponents (so compare equal but 
can't be used to replace each other).

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

Re: [PATCH V3] Add warning options -W[no-]compare-distinct-pointer-types

[Joseph Myers]

On Sat, 27 Aug 2022, Jose E. Marchesi via Gcc-patches wrote:

> +  if (metadata + 1 > data) /* { dg-warning "comparison of distinct pointer 
> types" } */

> +  if (metadata + 1 > data) /* { dg-warning "comparison of distinct pointer 
> types" } */

> +  if (metadata + 1 > data) /* There shouldn't be a warning here.  */

It seems the tests are only testing the '>' comparison operator.  I think 
all six comparison operators should be tested (in particular, you're 
changing two pedwarns - separate code paths for ordered and equality 
comparisons - but the tests only appear to cover one of the two).

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

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

[Joseph Myers]

On Fri, 26 Aug 2022, Richard Biener via Gcc-patches wrote:

> I was hoping Joseph would chime in here - I recollect debugging this kind
> of thing and a thread about this a while back but unfortunately I do not
> remember the details here (IIRC some things get included where they
> better should not be).

See .  
Is there some reason it's problematic to avoid having defaults.h or 
${cpu_type}/${cpu_type}.h included in tm_d.h, and instead have tm_d.h only 
include D-specific headers?

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

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

[Jason Merrill via Gcc-patches]

On 8/30/22 11:20, Jakub Jelinek wrote:

On Mon, Aug 29, 2022 at 11:31:54PM -0400, Jason Merrill wrote:

The pedwarn on -std=c++23 -finput-charset=UTF-8 or just documenting that
"conforming" UTF-8 is only -finput-charset=UTF-8 -Werror=invalid-utf8 ?


The former.


Ok.

So, here is an updated patch that implements that, and also warns/pedwarns
about invalid UTF-8 in string/character literals.
For these, we'd sometimes get errors on conversion to execution charset
(e.g. in [uU]['"] literals), but e.g. for 0x11  0x7FFF there
was no diagnostics and similarly nothing for u8" or " literals (when we
were doing a noop conversion).

So far only tested on the new testcases, ok for trunk if it passes full
bootstrap/regtest?

2022-08-30  Jakub Jelinek  

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

--- libcpp/include/cpplib.h.jj  2022-08-29 14:58:32.645982297 +0200
+++ libcpp/include/cpplib.h 2022-08-30 13:38:46.618815415 +0200
@@ -560,6 +560,13 @@ struct cpp_options
   cpp_bidirectional_level.  */
unsigned char cpp_warn_bidirectional;
  
+  /* True if libcpp should warn about invalid UTF-8 characters in comments.

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

--- libcpp/init.cc.jj   2022-08-29 14:58:32.646982284 +0200
+++ libcpp/init.cc  2022-08-30 13:39:49.784965506 +0200
@@ -227,6 +227,8 @@ cpp_create_reader (enum c_lang lang, cpp
CPP_OPTION (pfile, ext_numeric_literals) = 1;
CPP_OPTION (pfile, warn_date_time) = 0;
CPP_OPTION (pfile, cpp_warn_bidirectional) = bidirectional_unpaired;
+  CPP_OPTION (pfile, cpp_warn_invalid_utf8) = 0;
+  CPP_OPTION (pfile, cpp_input_charset_explicit) = 0;
  
/* Default CPP arithmetic to something sensible for the host for the

   benefit of dumb users like fix-header.  */
--- libcpp/lex.cc.jj2022-08-29 14:58:32.669981977 +0200
+++ libcpp/lex.cc   2022-08-30 16:56:12.793868707 +0200
@@ -50,6 +50,9 @@ static const struct token_spelling token
  #define TOKEN_SPELL(token) (token_spellings[(token)->type].category)
  #define TOKEN_NAME(token) (token_spellings[(token)->type].name)
  
+/* ISO 10646 defines the UCS codespace as the range 0-0x10 inclusive.  */

+#define UCS_LIMIT 0x10
+
  static void add_line_note (cpp_buffer *, const uchar *, unsigned int);
  static int skip_line_comment (cpp_reader *);
  static void skip_whitespace (cpp_reader *, cppchar_t);
@@ -1704,6 +1707,116 @@ maybe_warn_bidi_on_char (cpp_reader *pfi
bidi::on_char (kind, ucn_p, loc);
  }
  
+static const cppchar_t utf8_continuation = 0x80;

+static const cppchar_t utf8_signifier = 0xC0;
+
+/* Emit -Winvalid-utf8 warning on invalid UTF-8 character starting
+   at PFILE->buffer->cur.  Return a pointer after the diagnosed
+   invalid character.  */
+
+static const uchar *
+_cpp_warn_invalid_utf8 (cpp_reader *pfile, bool comment_p)
+{
+  cpp_buffer *buffer = 

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

[Jakub Jelinek via Gcc-patches]

On Tue, Aug 30, 2022 at 11:18:20PM +0200, Jakub Jelinek via Gcc-patches wrote:
> On Tue, Aug 30, 2022 at 09:10:37PM +, Joseph Myers wrote:
> > I'm seeing build failures of glibc for powerpc64, as illustrated by the 
> > following C code:
> > 
> > #if 0
> > \NARG
> > #endif
> > 
> > (the actual sysdeps/powerpc/powerpc64/sysdep.h code is inside #ifdef 
> > __ASSEMBLER__).
> > 
> > This shows some problems with this feature - and with delimited escape 
> > sequences - as it affects C.  It's fine to accept it as an extension 
> > inside string and character literals, because \N or \u{...} would be 
> > invalid in the absence of the feature (i.e. the syntax for such literals 
> > fails to match, meaning that the rule about undefined behavior for a 
> > single ' or " as a pp-token applies).  But outside string and character 
> > literals, the usual lexing rules apply, the \ is a pp-token on its own and 
> > the code is valid at the preprocessing level, and with expansion of macros 
> > appearing before or after the \ (e.g. u defined as a macro in the \u{...} 
> > case) it may be valid code at the language level as well.  I don't know 
> > what older C++ versions say about this, but for C this means e.g.
> > 
> > #define z(x) 0
> > #define a z(
> > int x = a\NARG);
> > 
> > needs to be accepted as expanding to "int x = 0;", not interpreted as 
> > using the \N feature in an identifier and produce an error.
> 
> Thanks, will look at it tomorrow.

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

Jason, your toughts about that?

Jakub

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

[Jakub Jelinek via Gcc-patches]

On Tue, Aug 30, 2022 at 09:10:37PM +, Joseph Myers wrote:
> I'm seeing build failures of glibc for powerpc64, as illustrated by the 
> following C code:
> 
> #if 0
> \NARG
> #endif
> 
> (the actual sysdeps/powerpc/powerpc64/sysdep.h code is inside #ifdef 
> __ASSEMBLER__).
> 
> This shows some problems with this feature - and with delimited escape 
> sequences - as it affects C.  It's fine to accept it as an extension 
> inside string and character literals, because \N or \u{...} would be 
> invalid in the absence of the feature (i.e. the syntax for such literals 
> fails to match, meaning that the rule about undefined behavior for a 
> single ' or " as a pp-token applies).  But outside string and character 
> literals, the usual lexing rules apply, the \ is a pp-token on its own and 
> the code is valid at the preprocessing level, and with expansion of macros 
> appearing before or after the \ (e.g. u defined as a macro in the \u{...} 
> case) it may be valid code at the language level as well.  I don't know 
> what older C++ versions say about this, but for C this means e.g.
> 
> #define z(x) 0
> #define a z(
> int x = a\NARG);
> 
> needs to be accepted as expanding to "int x = 0;", not interpreted as 
> using the \N feature in an identifier and produce an error.

Thanks, will look at it tomorrow.

Jakub

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

[Joseph Myers]

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

#if 0
\NARG
#endif

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

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

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

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

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

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

[Marek Polacek via Gcc-patches]

This looks good to me, one thing though:

On Thu, Aug 11, 2022 at 09:38:12PM -0400, David Malcolm via Gcc-patches wrote:
> --- a/gcc/c-family/c.opt
> +++ b/gcc/c-family/c.opt
> @@ -1439,6 +1439,10 @@ Wwrite-strings
>  C ObjC C++ ObjC++ Var(warn_write_strings) Warning
>  In C++, nonzero means warn about deprecated conversion from string literals 
> to 'char *'.  In C, similar warning, except that the conversion is of course 
> not deprecated by the ISO C standard.
>  
> +Wxor-used-as-pow
> +C C++ Common Var(warn_xor_used_as_pow) Warning Init(1)

This doesn't include ObjC/ObjC++, but...

> --- a/gcc/doc/invoke.texi
> +++ b/gcc/doc/invoke.texi
> @@ -414,6 +414,7 @@ Objective-C and Objective-C++ Dialects}.
>  -Wvector-operation-performance @gol
>  -Wvla  -Wvla-larger-than=@var{byte-size}  -Wno-vla-larger-than @gol
>  -Wvolatile-register-var  -Wwrite-strings @gol
> +-Wxor-used-as-pow @gol
>  -Wzero-length-bounds}
>  
>  @item Static Analyzer Options
> @@ -9661,6 +9662,20 @@ modifier does not inhibit all optimizations that may 
> eliminate reads
>  and/or writes to register variables.  This warning is enabled by
>  @option{-Wall}.
>  
> +@item -Wxor-used-as-pow @r{(C, C++, Objective-C and Objective-C++ only)}

...here it includes Objective-C and Objective-C++.

Marek

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

[Qing Zhao via Gcc-patches]

Hi, Joseph and Nathan,

Could you please review the C and C++ FE parts of the patch?

https://gcc.gnu.org/pipermail/gcc-patches/2022-August/599901.html

The middle-end changes have been approved by Richard already.

https://gcc.gnu.org/pipermail/gcc-patches/2022-August/600379.html

Thanks.



Begin forwarded message:

From: Qing Zhao mailto:qing.z...@oracle.com>>
Subject: [[GCC13][Patch][V3] 1/2] Add a new option -fstrict-flex-array[=n] and 
new attribute strict_flex_array
Date: August 17, 2022 at 10:40:41 AM EDT
To: gcc-patches@gcc.gnu.org
Cc: rguent...@suse.de, 
ja...@redhat.com, 
mse...@gmail.com, 
keesc...@chromium.org, 
jos...@codesourcery.com, Qing Zhao 
mailto:qing.z...@oracle.com>>

Add the following new option -fstrict-flex-array[=n] and a corresponding
attribute strict_flex_array to GCC:

'-fstrict-flex-array'
Treat the trailing array of a structure as a flexible array member
in a stricter way.  The positive form is equivalent to
'-fstrict-flex-array=3', which is the strictest.  A trailing array
is treated as a flexible array member only when it is declared as a
flexible array member per C99 standard onwards.  The negative form
is equivalent to '-fstrict-flex-array=0', which is the least
strict.  All trailing arrays of structures are treated as flexible
array members.

'-fstrict-flex-array=LEVEL'
Treat the trailing array of a structure as a flexible array member
in a stricter way.  The value of LEVEL controls the level of
strictness.

The possible values of LEVEL are the same as for the
'strict_flex_array' attribute (*note Variable Attributes::).

You can control this behavior for a specific trailing array field
of a structure by using the variable attribute 'strict_flex_array'
attribute (*note Variable Attributes::).

This option is only valid when flexible array member is supported in the
language. FOR ISO C before C99 and ISO C++, no language support for the 
flexible
array member at all, this option will be invalid and a warning will be 
issued.
When -std=gnu89 is specified or C++ with GNU extension, only zero-length 
array
extension and one-size array are supported, as a result, LEVEL=3 will be
invalid and a warning will be issued.

'strict_flex_array (LEVEL)'
The 'strict_flex_array' attribute should be attached to the
trailing array field of a structure.  It specifies the level of
strictness of treating the trailing array field of a structure as a
flexible array member.  LEVEL must be an integer betwen 0 to 3.

LEVEL=0 is the least strict level, all trailing arrays of
structures are treated as flexible array members.  LEVEL=3 is the
strictest level, only when the trailing array is declared as a
flexible array member per C99 standard onwards ([]), it is treated
as a flexible array member.

There are two more levels in between 0 and 3, which are provided to
support older codes that use GCC zero-length array extension ([0])
or one-size array as flexible array member ([1]): When LEVEL is 1,
the trailing array is treated as a flexible array member when it is
declared as either [], [0], or [1]; When LEVEL is 2, the trailing
array is treated as a flexible array member when it is declared as
either [], or [0].

This attribute can be used with or without '-fstrict-flex-array'.
When both the attribute and the option present at the same time,
the level of the strictness for the specific trailing array field
is determined by the attribute.

This attribute is only valid when flexible array member is supported in the
language. For ISO C before C99 and ISO C++, no language support for the 
flexible
array member at all, this attribute will be invalid and a warning is issued.
When -std=gnu89 is specified or C++ with GNU extension, only zero-length 
array
extension and one-size array are supported, as a result, LEVEL=3 will be
invalid and a warning is issued.

gcc/c-family/ChangeLog:

* c-attribs.cc (handle_strict_flex_arrays_attribute): New 
function.
(c_common_attribute_table): New item for strict_flex_array.
* c-opts.cc (c_common_post_options): Handle the combination of
-fstrict-flex-arrays and -std specially.
* c.opt: (fstrict-flex-array): New option.
(fstrict-flex-array=): New option.

gcc/c/ChangeLog:

* c-decl.cc (flexible_array_member_type_p): New function.
(one_element_array_type_p): Likewise.
(zero_length_array_type_p): Likewise.
(add_flexible_array_elts_to_size): Call new utility
routine flexible_array_member_type_p.
(is_flexible_array_member_p): New function.
(finish_struct): Set the new DECL_NOT_FLEXARRAY flag.

gcc/cp/ChangeLog:

* module.cc 

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

[Jason Merrill via Gcc-patches]

On 8/11/22 21:38, David Malcolm via Gcc-patches wrote:

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?


Looks good to me, but a C maintainer should sign off on the C front-end 
changes.



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

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

[John David Anglin]

On 2022-08-29 10:06 a.m., Martin Liška wrote:

Thanks for the feedback, can you please check the updated version of the patch?

@@ -353,9 +347,6 @@ proc check_weak_available { } {
 # return 1 if weak undefined symbols are supported.

 proc check_effective_target_weak_undefined { } {
-    if { [istarget hppa*-*-hpux*] } {
-   return 0
-    }

This code needs to be retained for hppa64.

@@ -562,7 +553,6 @@ proc check_effective_target_trampolines { } {
 if { [istarget avr-*-*]
 || [istarget msp430-*-*]
 || [istarget nvptx-*-*]
-    || [istarget hppa2.0w-hp-hpux11.23]
 || [istarget hppa64-hp-hpux11.23]
 || [istarget pru-*-*]
 || [istarget bpf-*-*] } {

The above looks odd.  As far as I know, support for trampolines doesn't depend 
in any way on hpux11.23.
I suspect the hppa64 line can be removed as well.

@@ -1,4 +0,0 @@
-# The ada virtual array implementation requires that indexing be disabled on
-# hosts such as hpux that use a segmented memory architecture. Both the c
-# and ada files need to be compiled with this option for correct operation.
-ADA_CFLAGS = -mdisable-indexing -D_X_HPUX10
diff --git a/config/mmap.m4 b/config/mmap.m4
index fba0d9d3657..53e5215d833 100644
--- a/config/mmap.m4
+++ b/config/mmap.m4
@@ -42,7 +42,7 @@ else
    # Systems known to be in this category are Windows (all variants),
    # VMS, and Darwin.
    case "$host_os" in
- *vms* | cygwin* | pe | mingw* | darwin* | ultrix* | hpux10* | hpux11.00)
+ *vms* | cygwin* | pe | mingw* | darwin* | ultrix* | hpux11.00)
 gcc_cv_func_mmap_dev_zero=no ;;
  *)
 gcc_cv_func_mmap_dev_zero=yes;;

Strictly, all hpux versions up to and including hpux11.00 don't have /dev/zero.

Dave

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

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

[John David Anglin]

On 2022-08-29 10:06 a.m., Martin Liška wrote:

Thanks for the feedback, can you please check the updated version of the patch?

The changes to the libffi directory are not necessary and incorrect.  libffi is 
a separate project.

Dave

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

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

[John David Anglin]

On 2022-08-29 10:06 a.m., Martin Liška wrote:

Thanks for the feedback, can you please check the updated version of the patch?


hppa64-hp-hpux11.11 built successfully with the updated patch:
https://gcc.gnu.org/pipermail/gcc-testresults/2022-August/767508.html


Dave

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

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

[Vineet Gupta]

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

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

diff --git a/gcc/config/riscv/riscv-c.cc b/gcc/config/riscv/riscv-c.cc
index bba72cf77a82..7064fcf142fe 100644
--- a/gcc/config/riscv/riscv-c.cc
+++ b/gcc/config/riscv/riscv-c.cc
@@ -92,13 +92,9 @@ riscv_cpu_cpp_builtins (cpp_reader *pfile)
   builtin_define ("__riscv_cmodel_medlow");
   break;
 
-case CM_PIC:
-  /* FALLTHROUGH. */
-
 case CM_MEDANY:
   builtin_define ("__riscv_cmodel_medany");
   break;
-
 }
 
   if (TARGET_MIN_VLEN != 0)
diff --git a/gcc/config/riscv/riscv-opts.h b/gcc/config/riscv/riscv-opts.h
index 85e869e62e3a..ce3237beca7a 100644
--- a/gcc/config/riscv/riscv-opts.h
+++ b/gcc/config/riscv/riscv-opts.h
@@ -34,8 +34,7 @@ extern enum riscv_abi_type riscv_abi;
 
 enum riscv_code_model {
   CM_MEDLOW,
-  CM_MEDANY,
-  CM_PIC
+  CM_MEDANY
 };
 extern enum riscv_code_model riscv_cmodel;
 
diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index 7c120eaa8e33..a239fe43047c 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -5162,7 +5162,7 @@ riscv_option_override (void)
   init_machine_status = _init_machine_status;
 
   if (flag_pic)
-riscv_cmodel = CM_PIC;
+riscv_cmodel = CM_MEDANY;
 
   /* We get better code with explicit relocs for CM_MEDLOW, but
  worse code for the others (for now).  Pick the best default.  */
-- 
2.32.0

[PATCH 0/2] PIC cleanup

[Vineet Gupta]

Hi,

A couple of cleanup patches when trying to understand -mexplicit-relocs
and code model.

 - 1/2 should be strightfwd
 - 2/2 might be slightly controversial.

Tested with a bunch of rv32/rv64 configs: same results before after,
granted pic might not really be getting tested here.

   = Summary of gcc testsuite =
| # of unexpected case / # of unique unexpected case
|  gcc |  g++ | gfortran |
 rv64imafdc/  lp64d/ medlow |   12 /10 |11016 /  2776 |0 / 0 |
 rv32imafdc/ ilp32d/ medlow |9 / 7 |10959 /  2764 |0 / 0 |
   rv32imac/  ilp32/ medlow |9 / 7 |10959 /  2764 |0 / 0 |
   rv64imac/   lp64/ medlow |   13 /11 |11016 /  2776 |0 / 0 |

Thx,
-Vineet

Vineet Gupta (2):
  RISC-V: remove deprecate pic code model macro
  RISC-V: remove CM_PIC as it doesn't do much

 gcc/config/riscv/riscv-c.cc   | 7 ---
 gcc/config/riscv/riscv-opts.h | 3 +--
 gcc/config/riscv/riscv.cc | 2 +-
 3 files changed, 2 insertions(+), 10 deletions(-)

-- 
2.32.0

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

[Vineet Gupta]

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

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

diff --git a/gcc/config/riscv/riscv-c.cc b/gcc/config/riscv/riscv-c.cc
index eb7ef09297e9..bba72cf77a82 100644
--- a/gcc/config/riscv/riscv-c.cc
+++ b/gcc/config/riscv/riscv-c.cc
@@ -93,9 +93,6 @@ riscv_cpu_cpp_builtins (cpp_reader *pfile)
   break;
 
 case CM_PIC:
-  /* __riscv_cmodel_pic is deprecated, and will removed in next GCC 
release.
-see https://github.com/riscv/riscv-c-api-doc/pull/11  */
-  builtin_define ("__riscv_cmodel_pic");
   /* FALLTHROUGH. */
 
 case CM_MEDANY:
-- 
2.32.0

Re: [COMMITTED] bpf: define __bpf__ as well as __BPF__ as a target macro

[Fangrui Song via Gcc-patches]

On Tue, Aug 30, 2022 at 9:46 AM Jose E. Marchesi
 wrote:
>
>
> > On Mon, Aug 29, 2022 at 1:16 PM Jose E. Marchesi via Gcc-patches
> >  wrote:
> >>
> >>
> >> LLVM defines both __bpf__ and __BPF_ as target macros.
> >> GCC was defining only __BPF__.
> >>
> >> This patch defines __bpf__ as a target macro for BPF.
> >> Tested in bpf-unknown-none.
> >>
> >> gcc/ChangeLog:
> >>
> >> * config/bpf/bpf.cc (bpf_target_macros): Define __bpf__ as a
> >> target macro.
> >> ---
> >>  gcc/config/bpf/bpf.cc | 1 +
> >>  1 file changed, 1 insertion(+)
> >>
> >> diff --git a/gcc/config/bpf/bpf.cc b/gcc/config/bpf/bpf.cc
> >> index 7e37e080808..9cb56cfb287 100644
> >> --- a/gcc/config/bpf/bpf.cc
> >> +++ b/gcc/config/bpf/bpf.cc
> >> @@ -291,6 +291,7 @@ void
> >>  bpf_target_macros (cpp_reader *pfile)
> >>  {
> >>builtin_define ("__BPF__");
> >> +  builtin_define ("__bpf__");
> >>
> >>if (TARGET_BIG_ENDIAN)
> >>  builtin_define ("__BPF_BIG_ENDIAN__");
> >> --
> >> 2.30.2
> >>
> >
> > Having multiple choices in this case seems to just add confusion to
> > users and making code search slightly more inconvenient.
> >
> > How much code uses LLVM specific __bpf__? Can it be migrated? Should
> > LLVM undefine the macro instead?
>
> I agree that it would be better to support just one form of the target
> macro.  Having two alternative forms can only lead to problems.
>
> But I think the train left the station long ago to do any better: there
> are files in the kernel tree that rely on __bpf__ and there may be BPF
> programs around doing the same thing.

Ok, thanks.

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

[Peter Bergner via Gcc-patches]

I'd like to ping the following patch.

Peter


https://gcc.gnu.org/pipermail/gcc-patches/2022-August/600451.html


Message-ID: 

>When we expand an MMA disassemble built-in with C++ using a pointer that
>is casted to a valid MMA type, the type isn't passed down to the expand
>machinery and we end up using the base type of the pointer which leads to
>an ICE.  This patch enforces we always use the correct MMA type regardless
>of the pointer type being used.
>
>This passed bootstrap and regtesting on powerpc64le-linux with no regressions.
>Ok for trunk and backports after some burn-in time?
>
>Peter
>
>gcc/
>   PR target/101322
>   * config/rs6000/rs6000-builtin.cc (rs6000_gimple_fold_mma_builtin):
>   Enforce the use of a valid MMA pointer type.
>
>gcc/testsuite/
>   PR target/101322
>   * g++.target/powerpc/pr101322.C: New test.
>
>diff --git a/gcc/config/rs6000/rs6000-builtin.cc 
>b/gcc/config/rs6000/rs6000-builtin.cc
>index 12afa86854c..e796e74f072 100644
>--- a/gcc/config/rs6000/rs6000-builtin.cc
>+++ b/gcc/config/rs6000/rs6000-builtin.cc
>@@ -1085,7 +1085,12 @@ rs6000_gimple_fold_mma_builtin (gimple_stmt_iterator 
>*gsi,
>   unsigned nvec = (fncode == RS6000_BIF_DISASSEMBLE_ACC) ? 4 : 2;
>   tree dst_ptr = gimple_call_arg (stmt, 0);
>   tree src_ptr = gimple_call_arg (stmt, 1);
>-  tree src_type = TREE_TYPE (src_ptr);
>+  tree src_type = (fncode == RS6000_BIF_DISASSEMBLE_ACC)
>+? build_pointer_type (vector_quad_type_node)
>+: build_pointer_type (vector_pair_type_node);
>+  if (TREE_TYPE (TREE_TYPE (src_ptr)) != src_type)
>+  src_ptr = build1 (VIEW_CONVERT_EXPR, src_type, src_ptr);
>+
>   tree src = create_tmp_reg_or_ssa_name (TREE_TYPE (src_type));
>   gimplify_assign (src, build_simple_mem_ref (src_ptr), _seq);
> 
>diff --git a/gcc/testsuite/g++.target/powerpc/pr101322.C 
>b/gcc/testsuite/g++.target/powerpc/pr101322.C
>new file mode 100644
>index 000..59e71e8eb89
>--- /dev/null
>+++ b/gcc/testsuite/g++.target/powerpc/pr101322.C
>@@ -0,0 +1,17 @@
>+/* PR target/101322 */
>+/* { dg-options "-O2 -mdejagnu-cpu=power10" } */
>+/* { dg-require-effective-target power10_ok } */
>+
>+/* Verify we don't ICE on the following test cases.  */
>+
>+void
>+foo (char *resp, char *vpp)
>+{
>+  __builtin_vsx_disassemble_pair (resp, (__vector_pair *) vpp);
>+}
>+
>+void
>+bar (char *resp, char *vpp)
>+{
>+  __builtin_mma_disassemble_acc (resp, (__vector_quad *)vpp);
>+}

[PATCH 2/2] libstdc++: Implement ranges::adjacent_transform_view from P2321R2

[Patrick Palka via Gcc-patches]

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

libstdc++-v3/ChangeLog:

* include/std/ranges (__detail::__unarize): Define.
(adjacent_view::_Iterator): Befriend adjacent_transform_view.
(adjacent_transform_view): Define.
(adjacent_transform_view::_Iterator): Define.
(adjacent_transform_view::_Sentinel): Define.
(views::__detail::__can_adjacent_transform_view): Define.
(views::_AdjacentTransform): Define.
(views::adjacent_transform): Define.
(views::pairwise): Define.
* testsuite/std/ranges/adaptors/adjacent_transform/1.cc: New test.
---
 libstdc++-v3/include/std/ranges   | 342 ++
 .../ranges/adaptors/adjacent_transform/1.cc   | 106 ++
 2 files changed, 448 insertions(+)
 create mode 100644 
libstdc++-v3/testsuite/std/ranges/adaptors/adjacent_transform/1.cc

diff --git a/libstdc++-v3/include/std/ranges b/libstdc++-v3/include/std/ranges
index 4fb879a088c..3a7f0545030 100644
--- a/libstdc++-v3/include/std/ranges
+++ b/libstdc++-v3/include/std/ranges
@@ -5158,6 +5158,20 @@ namespace views::__adaptor
 // Yields tuple<_Tp, ..., _Tp> with _Nm elements.
 template
   using __repeated_tuple = decltype(std::tuple_cat(std::declval>()));
+
+// For a functor F that takes N arguments, the expression 
declval<__unarize>(x)
+// is equivalent to declval(x, ..., x).
+template
+  struct __unarize
+  {
+   template
+ static invoke_result_t<_Fp, _Ts...>
+ __tuple_apply(const tuple<_Ts...>&); // not defined
+
+   template
+ decltype(__tuple_apply(std::declval<__repeated_tuple<_Tp, _Nm>>()))
+ operator()(_Tp&&); // not defined
+  };
   }
 
   template
@@ -5205,6 +5219,13 @@ namespace views::__adaptor
 
 friend class adjacent_view;
 
+template
+  requires view<_Wp> && (_Mm > 0) && is_object_v<_Fp>
+&& regular_invocable<__detail::__unarize<_Fp&, _Mm>, 
range_reference_t<_Wp>>
+&& 
std::__detail::__can_reference,
+
range_reference_t<_Wp>>>
+  friend class adjacent_transform_view;
+
   public:
 using iterator_category = input_iterator_tag;
 using iterator_concept = decltype(_S_iter_concept());
@@ -5440,6 +5461,327 @@ namespace views::__adaptor
 
 inline constexpr auto pairwise = adjacent<2>;
   }
+
+  template
+   requires view<_Vp> && (_Nm > 0) && is_object_v<_Fp>
+ && regular_invocable<__detail::__unarize<_Fp&, _Nm>, 
range_reference_t<_Vp>>
+ && 
std::__detail::__can_reference,
+  range_reference_t<_Vp>>>
+  class adjacent_transform_view : public 
view_interface>
+  {
+[[no_unique_address]] __detail::__box<_Fp> _M_fun;
+adjacent_view<_Vp, _Nm> _M_inner;
+
+using _InnerView = adjacent_view<_Vp, _Nm>;
+
+template
+  using _InnerIter = iterator_t<__detail::__maybe_const_t<_Const, 
_InnerView>>;
+
+template
+  using _InnerSent = sentinel_t<__detail::__maybe_const_t<_Const, 
_InnerView>>;
+
+template class _Iterator;
+template class _Sentinel;
+
+  public:
+adjacent_transform_view() = default;
+
+constexpr explicit
+adjacent_transform_view(_Vp __base, _Fp __fun)
+  : _M_fun(std::move(__fun)), _M_inner(std::move(__base))
+{ }
+
+constexpr auto
+begin()
+{ return _Iterator(*this, _M_inner.begin()); }
+
+constexpr auto
+begin() const
+  requires range
+   && regular_invocable<__detail::__unarize,
+range_reference_t>
+{ return _Iterator(*this, _M_inner.begin()); }
+
+constexpr auto
+end()
+{
+  if constexpr (common_range<_InnerView>)
+return _Iterator(*this, _M_inner.end());
+  else
+return _Sentinel(_M_inner.end());
+}
+
+constexpr auto
+end() const
+  requires range
+   && regular_invocable<__detail::__unarize,
+range_reference_t>
+{
+  if constexpr (common_range)
+return _Iterator(*this, _M_inner.end());
+  else
+return _Sentinel(_M_inner.end());
+}
+
+constexpr auto
+size() requires sized_range<_InnerView>
+{ return _M_inner.size(); }
+
+constexpr auto
+size() const requires sized_range
+{ return _M_inner.size(); }
+  };
+
+  template
+   requires view<_Vp> && (_Nm > 0) && is_object_v<_Fp>
+ && regular_invocable<__detail::__unarize<_Fp&, _Nm>, 
range_reference_t<_Vp>>
+ && 
std::__detail::__can_reference,
+  range_reference_t<_Vp>>>
+  template
+  class adjacent_transform_view<_Vp, _Fp, _Nm>::_Iterator
+  {
+using _Parent = __detail::__maybe_const_t<_Const, adjacent_transform_view>;
+using _Base = __detail::__maybe_const_t<_Const, _Vp>;
+
+_Parent* _M_parent = nullptr;
+_InnerIter<_Const> _M_inner;
+
+constexpr
+_Iterator(_Parent& __parent, 

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

[Patrick Palka via Gcc-patches]

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

libstdc++-v3/ChangeLog:

* testsuite/20_util/logical_traits/requirements/short_circuit.cc: New 
test.
---
 .../requirements/short_circuit.cc | 32 +++
 1 file changed, 32 insertions(+)
 create mode 100644 
libstdc++-v3/testsuite/20_util/logical_traits/requirements/short_circuit.cc

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

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

[Patrick Palka via Gcc-patches]

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

libstdc++-v3/ChangeLog:

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

diff --git a/libstdc++-v3/include/std/ranges b/libstdc++-v3/include/std/ranges
index 6e2e561ed12..4fb879a088c 100644
--- a/libstdc++-v3/include/std/ranges
+++ b/libstdc++-v3/include/std/ranges
@@ -5081,6 +5081,365 @@ namespace views::__adaptor
 
 inline constexpr _ZipTransform zip_transform;
   }
+
+  template
+requires view<_Vp> && (_Nm > 0)
+  class adjacent_view : public view_interface>
+  {
+_Vp _M_base = _Vp();
+
+template class _Iterator;
+template class _Sentinel;
+
+struct __as_sentinel
+{ };
+
+  public:
+adjacent_view() requires default_initializable<_Vp> = default;
+
+constexpr explicit
+adjacent_view(_Vp __base)
+  : _M_base(std::move(__base))
+{ }
+
+constexpr auto
+begin() requires (!__detail::__simple_view<_Vp>)
+{ return _Iterator(ranges::begin(_M_base), ranges::end(_M_base)); }
+
+constexpr auto
+begin() const requires range
+{ return _Iterator(ranges::begin(_M_base), ranges::end(_M_base)); }
+
+constexpr auto
+end() requires (!__detail::__simple_view<_Vp>)
+{
+  if constexpr (common_range<_Vp>)
+   return _Iterator(__as_sentinel{}, ranges::begin(_M_base), 
ranges::end(_M_base));
+  else
+   return _Sentinel(ranges::end(_M_base));
+}
+
+constexpr auto
+end() const requires range
+{
+  if constexpr (common_range)
+   return _Iterator(__as_sentinel{}, ranges::begin(_M_base), 
ranges::end(_M_base));
+  else
+   return _Sentinel(ranges::end(_M_base));
+}
+
+constexpr auto
+size() requires sized_range<_Vp>
+{
+  using _ST = decltype(ranges::size(_M_base));
+  using _CT = common_type_t<_ST, size_t>;
+  auto __sz = static_cast<_CT>(ranges::size(_M_base));
+  __sz -= std::min<_CT>(__sz, _Nm - 1);
+  return static_cast<_ST>(__sz);
+}
+
+constexpr auto
+size() const requires sized_range
+{
+  using _ST = decltype(ranges::size(_M_base));
+  using _CT = common_type_t<_ST, size_t>;
+  auto __sz = static_cast<_CT>(ranges::size(_M_base));
+  __sz -= std::min<_CT>(__sz, _Nm - 1);
+  return static_cast<_ST>(__sz);
+}
+  };
+
+  template
+inline constexpr bool enable_borrowed_range>
+  = enable_borrowed_range<_Vp>;
+
+  namespace __detail
+  {
+// Yields tuple<_Tp, ..., _Tp> with _Nm elements.
+template
+  using __repeated_tuple = decltype(std::tuple_cat(std::declval>()));
+  }
+
+  template
+requires view<_Vp> && (_Nm > 0)
+  template
+  class adjacent_view<_Vp, _Nm>::_Iterator
+  {
+using _Base = __detail::__maybe_const_t<_Const, _Vp>;
+array, _Nm> _M_current = array, _Nm>();
+
+constexpr
+_Iterator(iterator_t<_Base> __first, sentinel_t<_Base> __last)
+{
+  for (auto& __i : _M_current)
+   {
+ __i = __first;
+ ranges::advance(__first, 1, __last);
+   }
+}
+
+constexpr
+_Iterator(__as_sentinel, iterator_t<_Base> __first, iterator_t<_Base> 
__last)
+{
+  if constexpr (!bidirectional_range<_Base>)
+   for (auto& __it : _M_current)
+ __it = __last;
+  else
+   for (ssize_t __i = _Nm-1; __i >= 0; --__i)
+ {
+   _M_current[__i] = __last;
+   ranges::advance(__last, -1, __first);
+ }
+}
+
+static auto
+_S_iter_concept()
+{
+  if constexpr (random_access_range<_Base>)
+   return random_access_iterator_tag{};
+  else if constexpr (bidirectional_range<_Base>)
+   return bidirectional_iterator_tag{};
+  else
+   return forward_iterator_tag{};
+}
+
+friend class adjacent_view;
+
+  public:
+using iterator_category = input_iterator_tag;
+using iterator_concept = decltype(_S_iter_concept());
+using value_type = conditional_t<_Nm == 2,
+pair, 
range_value_t<_Base>>,
+
__detail::__repeated_tuple, _Nm>>;
+using difference_type = range_difference_t<_Base>;
+
+_Iterator() = default;
+
+constexpr
+_Iterator(_Iterator __i)
+  requires _Const && convertible_to, iterator_t<_Base>>
+{
+  for (size_t __j = 0; __j < _Nm; ++__j)
+   _M_current[__j] 

[PATCH 2/2] ipa-cp: Better representation of aggregate values in call contexts

[Martin Jambor]

Hi

this patch extends the previous one by using the same data structure
to represent aggregate values in classes ipa_auto_call_arg_values and
ipa_call_arg_values.

This usually simplifies handling and makes allocations of memory much
cheaper because only a single vectore is needed, as opposed to vectors
with each element pointing at other vecs.  The only functions which
unfortunately are a bit more complec are estimate_local_effects in
ipa-cp.cc and ipa_call_context::equal_to but I hope not too much - the
latter could probably be shorteneed at the expense of readability.

The patch removes types ipa_agg_value ipa_agg_value_set which is no
longer used with it.  This means that we could replace the "_argagg_"
part of the types introduced by the previous patches with more
reasonable "_agg_" - possibly as a follow-up patch.

Bootstrapped, LTO-bootstrapped and tested on x86_64-linux (and a
slightly older version also on aarch64-linux).  LTO-profiledbootstrap is
currently underway.  Given the size of the patch I assume there will be
concerns/questions but I'm looking for an approval to commit a version
of this.

Thanks,

Martin


gcc/ChangeLog:

2022-08-26  Martin Jambor  

* ipa-prop.h (ipa_agg_value): Remove type.
(ipa_agg_value_set): Likewise.
(ipa_copy_agg_values): Remove function.
(ipa_release_agg_values): Likewise.
(ipa_auto_call_arg_values) Add a forward declaration.
(ipa_call_arg_values): Likewise.
(class ipa_argagg_value_list): New constructors, added member function
value_for_index_p.
(class ipa_auto_call_arg_values): Removed the destructor and member
function safe_aggval_at.  Use ipa_argagg_values for m_known_aggs.
(class ipa_call_arg_values): Removed member function safe_aggval_at.
Use ipa_argagg_values for m_known_aggs.
(ipa_get_indirect_edge_target): Removed declaration.
(ipa_find_agg_cst_for_param): Likewise.
(ipa_find_agg_cst_from_init): New declaration.
(ipa_agg_value_from_jfunc): Likewise.
(ipa_agg_value_set_from_jfunc): Removed declaration.
(ipa_push_agg_values_from_jfunc): New declaration.
* ipa-cp.cc (ipa_agg_value_from_node): Renamed to
ipa_agg_value_from_jfunc, made public.
(ipa_agg_value_set_from_jfunc): Removed.
(ipa_push_agg_values_from_jfunc): New function.
(ipa_get_indirect_edge_target_1): Removed known_aggs parameter, use
avs for this purpose too.
(ipa_get_indirect_edge_target): Removed the overload working on
ipa_auto_call_arg_values, use ipa_argagg_value_list in the remaining
one.
(devirtualization_time_bonus): Use ipa_argagg_value_list and
ipa_get_indirect_edge_target_1 instead of
ipa_get_indirect_edge_target.
(context_independent_aggregate_values): Removed function.
(gather_context_independent_values): Work on ipa_argagg_value_list.
(estimate_local_effects): Likewise, define some iterator variables
only in the construct where necessary.
(ipcp_discover_new_direct_edges): Adjust the call to
ipa_get_indirect_edge_target_1.
(push_agg_values_for_index_from_edge): Adjust the call
ipa_agg_value_from_node which has been renamed to
ipa_agg_value_from_jfunc.
* ipa-fnsummary.cc (evaluate_conditions_for_known_args): Work on
ipa_argagg_value_list.
(evaluate_properties_for_edge): Replace manual filling in aggregate
values with call to ipa_push_agg_values_from_jfunc.
(estimate_calls_size_and_time): Work on ipa_argagg_value_list.
(ipa_cached_call_context::duplicate_from): Likewise.
(ipa_cached_call_context::release): Likewise.
(ipa_call_context::equal_to): Likewise.
* ipa-prop.cc (ipa_find_agg_cst_from_init): Make public.
(ipa_find_agg_cst_for_param): Removed function.
(ipa_find_agg_cst_from_jfunc_items): New function.
(try_make_edge_direct_simple_call): Replace calls to
ipa_agg_value_set_from_jfunc and ipa_find_agg_cst_for_param with
ipa_find_agg_cst_from_init and ipa_find_agg_cst_from_jfunc_items.
(try_make_edge_direct_virtual_call): Replace calls to
ipa_agg_value_set_from_jfunc and ipa_find_agg_cst_for_param with
simple query of constant jump function and a call to
ipa_find_agg_cst_from_jfunc_items.
(ipa_auto_call_arg_values::~ipa_auto_call_arg_values): Removed.
---
 gcc/ipa-cp.cc| 234 +--
 gcc/ipa-fnsummary.cc | 105 ++-
 gcc/ipa-prop.cc  | 110 ++--
 gcc/ipa-prop.h   | 172 +++
 4 files changed, 218 insertions(+), 403 deletions(-)

diff --git a/gcc/ipa-cp.cc b/gcc/ipa-cp.cc
index 024f8c06b5d..098392d9b90 100644
--- a/gcc/ipa-cp.cc
+++ b/gcc/ipa-cp.cc
@@ -1973,10 +1973,9 @@ ipa_value_range_from_jfunc (ipa_node_params *info, 

[PATCH 1/2] ipa-cp: Better representation of aggregate values we clone for

[Martin Jambor]

Hi,

this patch replaces linked lists of ipa_agg_replacement_value with
vectors of similar structures called ipa_argagg_value and simplifies
how we compute them in the first place.  Having a vector should also
result in less overhead when allocating and because we keep it sorted,
it leads to logarithmic searches.

The slightly obnoxious "argagg" bit in the name can be changed into
"agg" after the next patch removes our current ipa_agg_value type.

The patch also introduces type ipa_argagg_value_list which serves as a
common view into a vector of ipa_argagg_value structures regardless
whether they are stored in GC memory (required for IPA-CP
transformation summary because we store trees) or in an auto_vec which
is hopefully usually only allocated on stack.

The calculation of aggreagete costant values for a given subsert of
callers is then rewritten to compute known constants for each
edge (some pruning to skip obviously not needed is still employed and
should not be really worse than what I am replacing) and these vectors
are there intersected, which can be done linearly since they are
sorted.  The patch also removes a lot of heap allocations of small
lists of aggregate values and replaces them with stack based
auto_vecs.

As Richard Sandiford suggested, I use std::lower_bound from
 rather than re-implementing bsearch for array_slice.  The
patch depends on the patch which adds the ability to construct
array_slices from gc-allocated vectors.

Bootstrapped, LTO-bootstrapped and tested on x86_64-linux (and a
slightly older version also on aarch64-linux).  LTO-profiledbootstrap is
currently underway.  Given the size of the patch I assume there will be
concerns/questions but I'm looking for an approval to commit a version
of this.

Thanks,

Martin



gcc/ChangeLog:

2022-08-26  Martin Jambor  

* ipa-prop.h (IPA_PROP_ARG_INDEX_LIMIT_BITS): New.
(ipcp_transformation): Added forward declaration.
(ipa_argagg_value): New type.
(ipa_argagg_value_list): New type.
(ipa_agg_replacement_value): Removed type.
(ipcp_transformation): Switch from using ipa_agg_replacement_value
to ipa_argagg_value_list.
(ipa_get_agg_replacements_for_node): Removed.
(ipa_dump_agg_replacement_values): Removed declaration.
* ipa-cp.cc: Include .
(values_equal_for_ipcp_p): Moved up in the file.
(ipa_argagg_value_list::dump): Likewise.
(ipa_argagg_value_list::debug): Likewise.
(ipa_argagg_value_list::get_elt): Likewise.
(ipa_argagg_value_list::get_elt_for_index): Likewise.
(ipa_argagg_value_list::get_value): New overloaded functions.
(ipa_argagg_value_list::superset_of_p): New function.
(new ipa_argagg_value_list::push_adjusted_values): Likewise.
(push_agg_values_from_plats): Likewise.
(intersect_argaggs_with): Likewise.
(get_clone_agg_value): Removed.
(ipa_agg_value_from_node): Make last parameter const, use
ipa_argagg_value_list to search values coming from clones.
(ipa_get_indirect_edge_target_1): Use ipa_argagg_value_list to search
values coming from clones.
(ipcp_discover_new_direct_edges): Pass around a vector of
ipa_argagg_values rather than a link list of replacement values.
(cgraph_edge_brings_value_p): Use ipa_argagg_value_list to search
values coming from clones.
(create_specialized_node): Work with a vector of ipa_argagg_values
rather than a link list of replacement values.
(self_recursive_agg_pass_through_p): Make the pointer parameters
const.
(copy_plats_to_inter): Removed.
(intersect_with_plats): Likewise.
(agg_replacements_to_vector): Likewise.
(intersect_with_agg_replacements): Likewise.
(intersect_aggregates_with_edge): Likewise.
(push_agg_values_for_index_from_edge): Likewise.
(push_agg_values_from_edge): Likewise.
(find_aggregate_values_for_callers_subset): Rewrite.
(cgraph_edge_brings_all_agg_vals_for_node): Likewise.
(ipcp_val_agg_replacement_ok_p): Use ipa_argagg_value_list to search
aggregate values.
(decide_about_value): Work with a vector of ipa_argagg_values rather
than a link list of replacement values.
(decide_whether_version_node): Likewise.
(ipa_analyze_node): Check number of parameters, assert that there
are no descriptors when bailing out.
* ipa-prop.cc (ipa_set_node_agg_value_chain): Switch to a vector of
ipa_argagg_value.
(ipa_node_params_t::duplicate): Removed superfluous handling of
ipa_agg_replacement_values.  Name of src parameter removed because
it is no longer used.
(ipcp_transformation_t::duplicate): Replaced duplication of
ipa_agg_replacement_values with copying vector m_agg_values.
(ipa_dump_agg_replacement_values): Removed.

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

[Rainer Orth]

Hi Andrew,

> On 26/08/2022 12:04, Jakub Jelinek wrote:
>>> gcc/ChangeLog:
>>>
>>> * doc/tm.texi: Regenerate.
>>> * omp-simd-clone.cc (simd_clone_adjust_return_type): Allow zero
>>> vecsize.
>>> (simd_clone_adjust_argument_types): Likewise.
>>> * target.def (compute_vecsize_and_simdlen): Document the new
>>> vecsize_int and vecsize_float semantics.
>> LGTM, except for a formatting nit.
> diff --git a/gcc/omp-simd-clone.cc b/gcc/omp-simd-clone.cc
> index 58bd68b129b..68ee4c2c3b0 100644
> --- a/gcc/omp-simd-clone.cc
> +++ b/gcc/omp-simd-clone.cc
> @@ -504,7 +504,10 @@ simd_clone_adjust_return_type (struct cgraph_node *node)
>  veclen = node->simdclone->vecsize_int;
>else
>  veclen = node->simdclone->vecsize_float;
> -  veclen = exact_div (veclen, GET_MODE_BITSIZE (SCALAR_TYPE_MODE (t)));
> +  if (known_eq (veclen, 0))
> +veclen = node->simdclone->simdlen;
> +  else
> +veclen = exact_div (veclen, GET_MODE_BITSIZE (SCALAR_TYPE_MODE (t)));
>if (multiple_p (veclen, node->simdclone->simdlen))
>  veclen = node->simdclone->simdlen;
>if (POINTER_TYPE_P (t))

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

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

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

Rainer

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

Re: [COMMITTED] bpf: define __bpf__ as well as __BPF__ as a target macro

[Jose E. Marchesi via Gcc-patches]

> On Mon, Aug 29, 2022 at 1:16 PM Jose E. Marchesi via Gcc-patches
>  wrote:
>>
>>
>> LLVM defines both __bpf__ and __BPF_ as target macros.
>> GCC was defining only __BPF__.
>>
>> This patch defines __bpf__ as a target macro for BPF.
>> Tested in bpf-unknown-none.
>>
>> gcc/ChangeLog:
>>
>> * config/bpf/bpf.cc (bpf_target_macros): Define __bpf__ as a
>> target macro.
>> ---
>>  gcc/config/bpf/bpf.cc | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/gcc/config/bpf/bpf.cc b/gcc/config/bpf/bpf.cc
>> index 7e37e080808..9cb56cfb287 100644
>> --- a/gcc/config/bpf/bpf.cc
>> +++ b/gcc/config/bpf/bpf.cc
>> @@ -291,6 +291,7 @@ void
>>  bpf_target_macros (cpp_reader *pfile)
>>  {
>>builtin_define ("__BPF__");
>> +  builtin_define ("__bpf__");
>>
>>if (TARGET_BIG_ENDIAN)
>>  builtin_define ("__BPF_BIG_ENDIAN__");
>> --
>> 2.30.2
>>
>
> Having multiple choices in this case seems to just add confusion to
> users and making code search slightly more inconvenient.
>
> How much code uses LLVM specific __bpf__? Can it be migrated? Should
> LLVM undefine the macro instead?

I agree that it would be better to support just one form of the target
macro.  Having two alternative forms can only lead to problems.

But I think the train left the station long ago to do any better: there
are files in the kernel tree that rely on __bpf__ and there may be BPF
programs around doing the same thing.

[COMMITTED] Improve union of ranges containing NAN.

[Aldy Hernandez via Gcc-patches]

Previously [5,6] U NAN would just drop to VARYING.  With this patch,
the resulting range becomes [5,6] with the NAN bit set to unknown.

[I still have yet to decide what to do with intersections.  ISTM, the
intersection of a known NAN with anything else should be a NAN, but it
could also be undefined (the empty set).  I'll have to run some tests
and see.  Currently, we drop to VARYING cause well... it's always safe
to give up;-).]

gcc/ChangeLog:

* value-range.cc (early_nan_resolve): Change comment.
(frange::union_): Handle union when one side is a NAN.
(range_tests_nan): Add tests for NAN union.
---
 gcc/value-range.cc | 44 ++--
 1 file changed, 34 insertions(+), 10 deletions(-)

diff --git a/gcc/value-range.cc b/gcc/value-range.cc
index b6d6c62c06c..473139c6dbd 100644
--- a/gcc/value-range.cc
+++ b/gcc/value-range.cc
@@ -403,7 +403,7 @@ early_nan_resolve (frange , const frange )
   // There's nothing to do for both NANs.
   if (r.get_nan ().yes_p () == other.get_nan ().yes_p ())
 return false;
-  // But only one NAN complicates things.
+  // ?? Perhaps the intersection of a NAN and anything is a NAN ??.
   r.set_varying (r.type ());
   return true;
 }
@@ -420,10 +420,22 @@ frange::union_ (const vrange )
   *this = r;
   return true;
 }
-  // ?? We could do better here.  [5,6] U NAN should be [5,6] with the
-  // NAN maybe bits set.  For now, this is conservatively correct.
-  if (get_nan ().yes_p () || r.get_nan ().yes_p ())
-return early_nan_resolve (*this, r);
+
+  // If one side has a NAN, the union is just the other side plus the
+  // NAN bit.
+  if (get_nan ().yes_p ())
+{
+  *this = r;
+  // NOP if NAN already set.
+  set_nan (fp_prop::VARYING);
+  return true;
+}
+  if (r.get_nan ().yes_p ())
+{
+  // NOP if NAN already set.
+  set_nan (fp_prop::VARYING);
+  return true;
+}
 
   bool changed = m_props.union_ (r.m_props);
 
@@ -3520,6 +3532,7 @@ static void
 range_tests_nan ()
 {
   frange r0, r1;
+  REAL_VALUE_TYPE q, r;
 
   // Equal ranges but with differing NAN bits are not equal.
   r1 = frange_float ("10", "12");
@@ -3537,13 +3550,24 @@ range_tests_nan ()
   ASSERT_FALSE (r0 == r0);
   ASSERT_TRUE (r0 != r0);
 
-  // Make sure that combining NAN and INF doesn't give any crazy results.
+  // [5,6] U NAN is [5,6] with an unknown NAN bit.
+  r0 = frange_float ("5", "6");
+  r0.set_nan (fp_prop::NO);
+  r1 = frange_nan (float_type_node);
+  r0.union_ (r1);
+  real_from_string (, "5");
+  real_from_string (, "6");
+  ASSERT_TRUE (real_identical (, _bound ()));
+  ASSERT_TRUE (real_identical (, _bound ()));
+  ASSERT_TRUE (r0.get_nan ().varying_p ());
+
+  // NAN U NAN = NAN
   r0 = frange_nan (float_type_node);
-  ASSERT_TRUE (r0.get_nan ().yes_p ());
-  r1 = frange_float ("+Inf", "+Inf");
+  r1 = frange_nan (float_type_node);
   r0.union_ (r1);
-  // [INF, INF] U NAN = VARYING
-  ASSERT_TRUE (r0.varying_p ());
+  ASSERT_TRUE (real_isnan (_bound ()));
+  ASSERT_TRUE (real_isnan (_bound ()));
+  ASSERT_TRUE (r0.get_nan ().yes_p ());
 
   // [INF, INF] ^ NAN = VARYING
   r0 = frange_nan (float_type_node);
-- 
2.37.1

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

[Gaius Mulley via Gcc-patches]

Martin Liška  writes:

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

Hi Martin,

ah interesting - thanks for the trace will look into the above fault.

> Have a couple of questions:
>
> 1) What's gcc/m2/www/tools/createhtml.py about? Will you need it once
> the branch is merged to master?

no it will be purged.  It was part of the tool set used to generate
https://www.nongnu.org/gm2/homepage.html from gm2.texi.  createhtml
allowed gcc-10, 11, 12 documentation to coexist.

I've seen and like the demos of the documentation you are producing.
I was curious is there provision for older gcc release documentation
(say gcc-10 onwards) to be accessible via the Sphinx’s documentation?

> 2) You generate some texi files on fly: ./gcc/m2/gm2-ebnf.texi, 
> ./gcc/m2/Builtins.texi
> Would it be possible emitting Sphinx in the future?

yes sure - I was meaning to email about this earlier.  Are there any
do/don'ts you would advise when writing texinfo (or subset/template
examples?).  I'm keen to change the tools which generate gm2-ebnf.texi
and Builtins.texi to accommodate Sphinx.

regards,
Gaius

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

[Jakub Jelinek via Gcc-patches]

On Mon, Aug 29, 2022 at 11:31:54PM -0400, Jason Merrill wrote:
> > The pedwarn on -std=c++23 -finput-charset=UTF-8 or just documenting that
> > "conforming" UTF-8 is only -finput-charset=UTF-8 -Werror=invalid-utf8 ?
> 
> The former.

Ok.

So, here is an updated patch that implements that, and also warns/pedwarns
about invalid UTF-8 in string/character literals.
For these, we'd sometimes get errors on conversion to execution charset
(e.g. in [uU]['"] literals), but e.g. for 0x11  0x7FFF there
was no diagnostics and similarly nothing for u8" or " literals (when we
were doing a noop conversion).

So far only tested on the new testcases, ok for trunk if it passes full
bootstrap/regtest?

2022-08-30  Jakub Jelinek  

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

--- libcpp/include/cpplib.h.jj  2022-08-29 14:58:32.645982297 +0200
+++ libcpp/include/cpplib.h 2022-08-30 13:38:46.618815415 +0200
@@ -560,6 +560,13 @@ struct cpp_options
  cpp_bidirectional_level.  */
   unsigned char cpp_warn_bidirectional;
 
+  /* True if libcpp should warn about invalid UTF-8 characters in comments.
+ 2 if it should be a pedwarn.  */
+  unsigned char cpp_warn_invalid_utf8;
+
+  /* True if -finput-charset= option has been used explicitly.  */
+  bool cpp_input_charset_explicit;
+
   /* Dependency generation.  */
   struct
   {
@@ -666,7 +673,8 @@ enum cpp_warning_reason {
   CPP_W_CXX11_COMPAT,
   CPP_W_CXX20_COMPAT,
   CPP_W_EXPANSION_TO_DEFINED,
-  CPP_W_BIDIRECTIONAL
+  CPP_W_BIDIRECTIONAL,
+  CPP_W_INVALID_UTF8
 };
 
 /* Callback for header lookup for HEADER, which is the name of a
--- libcpp/init.cc.jj   2022-08-29 14:58:32.646982284 +0200
+++ libcpp/init.cc  2022-08-30 13:39:49.784965506 +0200
@@ -227,6 +227,8 @@ cpp_create_reader (enum c_lang lang, cpp
   CPP_OPTION (pfile, ext_numeric_literals) = 1;
   CPP_OPTION (pfile, warn_date_time) = 0;
   CPP_OPTION (pfile, cpp_warn_bidirectional) = bidirectional_unpaired;
+  CPP_OPTION (pfile, cpp_warn_invalid_utf8) = 0;
+  CPP_OPTION (pfile, cpp_input_charset_explicit) = 0;
 
   /* Default CPP arithmetic to something sensible for the host for the
  benefit of dumb users like fix-header.  */
--- libcpp/lex.cc.jj2022-08-29 14:58:32.669981977 +0200
+++ libcpp/lex.cc   2022-08-30 16:56:12.793868707 +0200
@@ -50,6 +50,9 @@ static const struct token_spelling token
 #define TOKEN_SPELL(token) (token_spellings[(token)->type].category)
 #define TOKEN_NAME(token) (token_spellings[(token)->type].name)
 
+/* ISO 10646 defines the UCS codespace as the range 0-0x10 inclusive.  */
+#define UCS_LIMIT 0x10
+
 static void add_line_note (cpp_buffer *, const uchar *, unsigned int);
 static int skip_line_comment (cpp_reader *);
 static void skip_whitespace (cpp_reader *, cppchar_t);
@@ -1704,6 +1707,116 @@ maybe_warn_bidi_on_char (cpp_reader *pfi
   bidi::on_char (kind, ucn_p, loc);
 }
 
+static const cppchar_t utf8_continuation = 0x80;
+static const cppchar_t utf8_signifier = 0xC0;
+
+/* Emit -Winvalid-utf8 warning on invalid UTF-8 character starting
+   at PFILE->buffer->cur.  Return a pointer after the diagnosed
+   invalid character.  */
+
+static const uchar *
+_cpp_warn_invalid_utf8 (cpp_reader *pfile, bool comment_p)
+{
+  cpp_buffer *buffer = pfile->buffer;
+  const uchar *cur = buffer->cur;
+  bool pedantic = 

Re: -Wformat-overflow handling for %b and %B directives in C2X standard

[Marek Polacek via Gcc-patches]

On Mon, Aug 15, 2022 at 07:42:39PM +0300, Frolov Daniil wrote:
> вт, 12 апр. 2022 г. в 00:56, Marek Polacek :
> 
> >
> > On Thu, Apr 07, 2022 at 02:10:48AM +0500, Frolov Daniil wrote:
> > > Hello! Thanks for your feedback. I've tried to take into account your
> > > comments. New patch applied to the letter.
> >
> > Thanks.
> >
> > > The only thing I have not removed is the check_std_c2x () function. From 
> > > my
> > > point of view -Wformat-overflow shouldn't be thrown if the standard < C2X.
> > > So it's protection for false triggering.
> >
> > Sorry but I still think that is the wrong behavior.  If you want to warn
> > about C2X constructs in pre-C2X modes, use -Wpedantic.  But if you want
> > to use %b/%B as an extension in older dialects, that's OK too, so I don't
> > know why users would want -Wformat-overflow disabled in that case.  But
> > perhaps other people disagree with me.
> >
> Hi! Sorry for the late reply. If we want to look at it as on extension
> then I am agreed with you.
> Removed this function in new patch.

Thanks, the patch looks good to me (I have one comment though), but I can't
approve it.

> @@ -1229,6 +1231,10 @@ format_integer (const directive , tree arg, 
> pointer_query _qry)
>  case 'u':
>base = 10;
>break;
> +case 'b':
> +case 'B':
> +  base = 2;
> +  break;
>  case 'o':
>base = 8;
>break;
> @@ -1348,13 +1354,12 @@ format_integer (const directive , tree arg, 
> pointer_query _qry)
>   }
>  
>res.range.unlikely = res.range.max;
> +  unsigned adj = (sign | maybebase) + (base == 2 || base == 16);

We have this same line here and ...
  
>/* Bump up the counters if WIDTH is greater than LEN.  */
> -  res.adjust_for_width_or_precision (dir.width, dirtype, base,
> -  (sign | maybebase) + (base == 16));
> +  res.adjust_for_width_or_precision (dir.width, dirtype, base, adj);
>/* Bump up the counters again if PRECision is greater still.  */
> -  res.adjust_for_width_or_precision (dir.prec, dirtype, base,
> -  (sign | maybebase) + (base == 16));
> +  res.adjust_for_width_or_precision (dir.prec, dirtype, base, adj);
>  
>return res;
>  }
> @@ -1503,17 +1508,16 @@ format_integer (const directive , tree arg, 
> pointer_query _qry)
> if (res.range.min == 1)
>   res.range.likely += base == 8 ? 1 : 2;
> else if (res.range.min == 2
> -&& base == 16
> +&& (base == 16 || base == 2)
>  && (dir.width[0] == 2 || dir.prec[0] == 2))
>   ++res.range.likely;
>   }
>  }
>  
> +  unsigned adj = (sign | maybebase) + (base == 2 || base == 16);

... here, but sign, maybebase, and base couldn't have changed meanwhile.

So can we compute 'adj' just once after we've determined the base and sign,
and make it const?  And I think that if 'maybebase' is never changed in the
function, it ought to be made const as well.

Thanks,

Marek

Re: [PATCH 2/3] amdgcn: OpenMP SIMD routine support

[Andrew Stubbs]

On 09/08/2022 14:23, Andrew Stubbs wrote:


Enable and configure SIMD clones for amdgcn.  This affects both the __simd__
function attribute, and the OpenMP "declare simd" directive.

Note that the masked SIMD variants are generated, but the middle end doesn't
actually support calling them yet.

gcc/ChangeLog:

* config/gcn/gcn.cc (gcn_simd_clone_compute_vecsize_and_simdlen): New.
(gcn_simd_clone_adjust): New.
(gcn_simd_clone_usable): New.
(TARGET_SIMD_CLONE_ADJUST): New.
(TARGET_SIMD_CLONE_COMPUTE_VECSIZE_AND_SIMDLEN): New.
(TARGET_SIMD_CLONE_USABLE): New.

gcc/testsuite/ChangeLog:

* gcc.dg/vect/vect-simd-clone-1.c: Add dg-warning.
* gcc.dg/vect/vect-simd-clone-2.c: Add dg-warning.
* gcc.dg/vect/vect-simd-clone-3.c: Add dg-warning.
* gcc.dg/vect/vect-simd-clone-4.c: Add dg-warning.
* gcc.dg/vect/vect-simd-clone-5.c: Add dg-warning.
* gcc.dg/vect/vect-simd-clone-8.c: Add dg-warning.


The dependency was approved, so this is now committed.

Andrew

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

[Andrew Stubbs]

On 26/08/2022 12:04, Jakub Jelinek wrote:

gcc/ChangeLog:

* doc/tm.texi: Regenerate.
* omp-simd-clone.cc (simd_clone_adjust_return_type): Allow zero
vecsize.
(simd_clone_adjust_argument_types): Likewise.
* target.def (compute_vecsize_and_simdlen): Document the new
vecsize_int and vecsize_float semantics.


LGTM, except for a formatting nit.


Here's what I pushed.

Andrew
omp-simd-clone: Allow fixed-lane vectors

The vecsize_int/vecsize_float has an assumption that all arguments will use
the same bitsize, and vary the number of lanes according to the element size,
but this is inappropriate on targets where the number of lanes is fixed and
the bitsize varies (i.e. amdgcn).

With this change the vecsize can be left zero and the vectorization factor will
be the same for all types.

gcc/ChangeLog:

* doc/tm.texi: Regenerate.
* omp-simd-clone.cc (simd_clone_adjust_return_type): Allow zero
vecsize.
(simd_clone_adjust_argument_types): Likewise.
* target.def (compute_vecsize_and_simdlen): Document the new
vecsize_int and vecsize_float semantics.

diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi
index 92bda1a7e14..c3001c6ded9 100644
--- a/gcc/doc/tm.texi
+++ b/gcc/doc/tm.texi
@@ -6253,6 +6253,9 @@ stores.
 This hook should set @var{vecsize_mangle}, @var{vecsize_int}, 
@var{vecsize_float}
 fields in @var{simd_clone} structure pointed by @var{clone_info} argument and 
also
 @var{simdlen} field if it was previously 0.
+@var{vecsize_mangle} is a marker for the backend only. @var{vecsize_int} and
+@var{vecsize_float} should be left zero on targets where the number of lanes is
+not determined by the bitsize (in which case @var{simdlen} is always used).
 The hook should return 0 if SIMD clones shouldn't be emitted,
 or number of @var{vecsize_mangle} variants that should be emitted.
 @end deftypefn
diff --git a/gcc/omp-simd-clone.cc b/gcc/omp-simd-clone.cc
index 58bd68b129b..68ee4c2c3b0 100644
--- a/gcc/omp-simd-clone.cc
+++ b/gcc/omp-simd-clone.cc
@@ -504,7 +504,10 @@ simd_clone_adjust_return_type (struct cgraph_node *node)
 veclen = node->simdclone->vecsize_int;
   else
 veclen = node->simdclone->vecsize_float;
-  veclen = exact_div (veclen, GET_MODE_BITSIZE (SCALAR_TYPE_MODE (t)));
+  if (known_eq (veclen, 0))
+veclen = node->simdclone->simdlen;
+  else
+veclen = exact_div (veclen, GET_MODE_BITSIZE (SCALAR_TYPE_MODE (t)));
   if (multiple_p (veclen, node->simdclone->simdlen))
 veclen = node->simdclone->simdlen;
   if (POINTER_TYPE_P (t))
@@ -618,8 +621,12 @@ simd_clone_adjust_argument_types (struct cgraph_node *node)
veclen = sc->vecsize_int;
  else
veclen = sc->vecsize_float;
- veclen = exact_div (veclen,
- GET_MODE_BITSIZE (SCALAR_TYPE_MODE (parm_type)));
+ if (known_eq (veclen, 0))
+   veclen = sc->simdlen;
+ else
+   veclen
+ = exact_div (veclen,
+  GET_MODE_BITSIZE (SCALAR_TYPE_MODE (parm_type)));
  if (multiple_p (veclen, sc->simdlen))
veclen = sc->simdlen;
  adj.op = IPA_PARAM_OP_NEW;
@@ -669,8 +676,11 @@ simd_clone_adjust_argument_types (struct cgraph_node *node)
veclen = sc->vecsize_int;
   else
veclen = sc->vecsize_float;
-  veclen = exact_div (veclen,
- GET_MODE_BITSIZE (SCALAR_TYPE_MODE (base_type)));
+  if (known_eq (veclen, 0))
+   veclen = sc->simdlen;
+  else
+   veclen = exact_div (veclen,
+   GET_MODE_BITSIZE (SCALAR_TYPE_MODE (base_type)));
   if (multiple_p (veclen, sc->simdlen))
veclen = sc->simdlen;
   if (sc->mask_mode != VOIDmode)
diff --git a/gcc/target.def b/gcc/target.def
index 2a7fa68f83d..4d49ffc2c88 100644
--- a/gcc/target.def
+++ b/gcc/target.def
@@ -1629,6 +1629,9 @@ DEFHOOK
 "This hook should set @var{vecsize_mangle}, @var{vecsize_int}, 
@var{vecsize_float}\n\
 fields in @var{simd_clone} structure pointed by @var{clone_info} argument and 
also\n\
 @var{simdlen} field if it was previously 0.\n\
+@var{vecsize_mangle} is a marker for the backend only. @var{vecsize_int} and\n\
+@var{vecsize_float} should be left zero on targets where the number of lanes 
is\n\
+not determined by the bitsize (in which case @var{simdlen} is always used).\n\
 The hook should return 0 if SIMD clones shouldn't be emitted,\n\
 or number of @var{vecsize_mangle} variants that should be emitted.",
 int, (struct cgraph_node *, struct cgraph_simd_clone *, tree, int), NULL)

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

[Richard Sandiford via Gcc-patches]

Jeff Law via Gcc-patches  writes:
> On 8/25/2022 7:07 AM, Richard Sandiford via Gcc-patches wrote:
>> Currently SLP tries to force permute operations "down" the graph
>> from loads in the hope of reducing the total number of permutations
>> needed or (in the best case) removing the need for the permutations
>> entirely.  This patch tries to extend it as follows:
>>
>> - Allow loads to take a different permutation from the one they
>>started with, rather than choosing between "original permutation"
>>and "no permutation".
>>
>> - Allow changes in both directions, if the target supports the
>>reverse permutation.
>>
>> - Treat the placement of permutations as a two-way dataflow problem:
>>after propagating information from leaves to roots (as now), propagate
>>information back up the graph.
>>
>> - Take execution frequency into account when optimising for speed,
>>so that (for example) permutations inside loops have a higher
>>cost than permutations outside loops.
>>
>> - Try to reduce the total number of permutations when optimising for
>>size, even if that increases the number of permutations on a given
>>execution path.
>>
>> See the big block comment above vect_optimize_slp_pass for
>> a detailed description.
>>
>> The original motivation for doing this was to add a framework that would
>> allow other layout differences in future.  The two main ones are:
>>
>> - Make it easier to represent predicated operations, including
>>predicated operations with gaps.  E.g.:
>>
>>   a[0] += 1;
>>   a[1] += 1;
>>   a[3] += 1;
>>
>>could be a single load/add/store for SVE.  We could handle this
>>by representing a layout such as { 0, 1, _, 2 } or { 0, 1, _, 3 }
>>(depending on what's being counted).  We might need to move
>>elements between lanes at various points, like with permutes.
>>
>>(This would first mean adding support for stores with gaps.)
>>
>> - Make it easier to switch between an even/odd and unpermuted layout
>>when switching between wide and narrow elements.  E.g. if a widening
>>operation produces an even vector and an odd vector, we should try
>>to keep operations on the wide elements in that order rather than
>>force them to be permuted back "in order".
> Very cool.  Richi and I discussed this a bit a year or so ago -- 
> basically noting that bi-directional movement is really the way to go 
> and that the worst thing to do is push a permute down into the *middle* 
> of a computation chain since that will tend to break FMA generation.  
> Moving to the loads or stores or to another permute point ought to be 
> the goal.

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

  permute(a) * permute(b) + c

then the tendency will still be to convert that into:

  permute(a * b) + c

Damn.  Another case to think about ;-)

I've pushed the series for now though (thanks to Richi for the reviews).

Richard

Re: [PATCH v2] ipa-visibility: Optimize TLS access [PR99619]

[Alexander Monakov via Gcc-patches]

> I see, thank you for explaining the issue, and sorry if I was a bit stubborn.
> 
> Does the attached patch (incremental change below) look better? It no longer
> has the 'shortcut' where iterating over referrers is avoided for the common
> case of plain 'gcc -O2' and no 'optimize' attributes, but fortunately TLS
> variables are not so numerous to make chasing that worthwhile.

... and of course I forgot to add the attachment.  Revised patch below.

---8<---

>From b245015ec465604799aef60b224b1e1e264d4cb8 Mon Sep 17 00:00:00 2001
From: Artem Klimov 
Date: Wed, 6 Jul 2022 17:02:01 +0300
Subject: [PATCH] ipa-visibility: Optimize TLS access [PR99619]

Fix PR99619, which asks to optimize TLS model based on visibility.
The fix is implemented as an IPA optimization: this allows to take
optimized visibility status into account (as well as avoid modifying
all language frontends).

2022-04-17  Artem Klimov  

gcc/ChangeLog:

* ipa-visibility.cc (function_and_variable_visibility): Promote
TLS access model afer visibility optimizations.
* varasm.cc (have_optimized_refs): New helper.
(optimize_dyn_tls_for_decl_p): New helper. Use it ...
(decl_default_tls_model): ... here in place of 'optimize' check.

gcc/testsuite/ChangeLog:

* gcc.dg/tls/vis-attr-gd.c: New test.
* gcc.dg/tls/vis-attr-hidden-gd.c: New test.
* gcc.dg/tls/vis-attr-hidden.c: New test.
* gcc.dg/tls/vis-flag-hidden-gd.c: New test.
* gcc.dg/tls/vis-flag-hidden.c: New test.
* gcc.dg/tls/vis-pragma-hidden-gd.c: New test.
* gcc.dg/tls/vis-pragma-hidden.c: New test.

Co-Authored-By:  Alexander Monakov  
Signed-off-by: Artem Klimov 
---
 gcc/ipa-visibility.cc | 19 +++
 gcc/testsuite/gcc.dg/tls/vis-attr-gd.c| 12 +++
 gcc/testsuite/gcc.dg/tls/vis-attr-hidden-gd.c | 13 
 gcc/testsuite/gcc.dg/tls/vis-attr-hidden.c| 12 +++
 gcc/testsuite/gcc.dg/tls/vis-flag-hidden-gd.c | 13 
 gcc/testsuite/gcc.dg/tls/vis-flag-hidden.c| 12 +++
 .../gcc.dg/tls/vis-pragma-hidden-gd.c | 17 ++
 gcc/testsuite/gcc.dg/tls/vis-pragma-hidden.c  | 16 ++
 gcc/varasm.cc | 32 ++-
 9 files changed, 145 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.dg/tls/vis-attr-gd.c
 create mode 100644 gcc/testsuite/gcc.dg/tls/vis-attr-hidden-gd.c
 create mode 100644 gcc/testsuite/gcc.dg/tls/vis-attr-hidden.c
 create mode 100644 gcc/testsuite/gcc.dg/tls/vis-flag-hidden-gd.c
 create mode 100644 gcc/testsuite/gcc.dg/tls/vis-flag-hidden.c
 create mode 100644 gcc/testsuite/gcc.dg/tls/vis-pragma-hidden-gd.c
 create mode 100644 gcc/testsuite/gcc.dg/tls/vis-pragma-hidden.c

diff --git a/gcc/ipa-visibility.cc b/gcc/ipa-visibility.cc
index 8a27e7bcd..3ed2b7cf6 100644
--- a/gcc/ipa-visibility.cc
+++ b/gcc/ipa-visibility.cc
@@ -873,6 +873,25 @@ function_and_variable_visibility (bool whole_program)
}
 }
 
+  if (symtab->state >= IPA_SSA)
+{
+  FOR_EACH_VARIABLE (vnode)
+   {
+ tree decl = vnode->decl;
+
+ /* Upgrade TLS access model based on optimized visibility status,
+unless it was specified explicitly or no references remain.  */
+ if (DECL_THREAD_LOCAL_P (decl)
+ && !lookup_attribute ("tls_model", DECL_ATTRIBUTES (decl))
+ && vnode->ref_list.referring.length ())
+   {
+ enum tls_model new_model = decl_default_tls_model (decl);
+ gcc_checking_assert (new_model >= decl_tls_model (decl));
+ set_decl_tls_model (decl, new_model);
+   }
+   }
+}
+
   if (dump_file)
 {
   fprintf (dump_file, "\nMarking local functions:");
diff --git a/gcc/varasm.cc b/gcc/varasm.cc
index 4db8506b1..ffc559431 100644
--- a/gcc/varasm.cc
+++ b/gcc/varasm.cc
@@ -6679,6 +6679,36 @@ init_varasm_once (void)
 #endif
 }
 
+/* Determine whether SYMBOL is used in any optimized function.  */
+
+static bool
+have_optimized_refs (struct symtab_node *symbol)
+{
+  struct ipa_ref *ref;
+
+  for (int i = 0; symbol->iterate_referring (i, ref); i++)
+{
+  cgraph_node *cnode = dyn_cast  (ref->referring);
+
+  if (cnode && opt_for_fn (cnode->decl, optimize))
+   return true;
+}
+
+  return false;
+}
+
+/* Check if promoting general-dynamic TLS access model to local-dynamic is
+   desirable for DECL.  */
+
+static bool
+optimize_dyn_tls_for_decl_p (const_tree decl)
+{
+  if (cfun)
+return optimize;
+  return symtab->state >= IPA && have_optimized_refs (symtab_node::get (decl));
+}
+
+
 enum tls_model
 decl_default_tls_model (const_tree decl)
 {
@@ -6696,7 +6726,7 @@ decl_default_tls_model (const_tree decl)
 
   /* Local dynamic is inefficient when we're not combining the
  parts of the address.  */
-  else if (optimize && is_local)
+  else if (is_local && optimize_dyn_tls_for_decl_p (decl))
 kind = TLS_MODEL_LOCAL_DYNAMIC;

Re: C++: add -std={c,gnu}++{current,future}

[Marek Polacek via Gcc-patches]

On Tue, Aug 30, 2022 at 09:22:14AM -0400, Jason Merrill via Gcc-patches wrote:
> On 7/13/22 15:29, Nathan Sidwell wrote:
> > Inspired by a user question.  Jason, thoughts?
> > 
> > Since C++ is such a moving target, Microsoft have /std:c++latest
> > (AFAICT clang does not), to select the currently implemented version
> > of the working paper.  But the use of 'std:latest' is somewhat
> > ambiguous -- the current std is C++20 -- that's the latest std, the
> > next std will more than likely but not necessarily be C++23.  So this
> > adds:
> > 
> >    -std=c++current -- the current std (c++20)
> >    -std=c++future -- the working paper (c++2b)
> > 
> > also adds gnu++current and gnu++future to select the gnu-extended
> > variants.
> 
> I like this direction.
> 
> I imagine people using these to mean roughly beta and alpha, respectively.
> 
> Perhaps we also want -std=c++stable, which would currently be equivalent to
> the default (c++17) but might not always be.

I wonder how these new switches would be useful in older releases.  If
I use -std=c++current with gcc 5 years old, that's probably not very
useful?  Should there be a way to know what these options map to?

Also, I suppose that if we switch the default to gnu++20, then there may
be a window when -std=gnu++current == the default.

Marek

[PING^7] nvptx: Allow '--with-arch' to override the default '-misa' (was: nvptx multilib setup)

[Thomas Schwinge]

Hi Tom!

Ping.


Grüße
 Thomas


On 2022-08-16T17:13:42+0200, I wrote:
> Hi Tom!
>
> Ping.
>
>
> Grüße
>  Thomas
>
>
> On 2022-08-06T21:20:38+0200, I wrote:
>> Hi Tom!
>>
>> Ping.
>>
>>
>> Grüße
>>  Thomas
>>
>>
>> On 2022-07-27T17:48:58+0200, I wrote:
>>> Hi Tom!
>>>
>>> Ping.
>>>
>>>
>>> Grüße
>>>  Thomas
>>>
>>>
>>> On 2022-07-20T14:46:03+0200, I wrote:
 Hi Tom!

 Ping.


 Grüße
  Thomas


 On 2022-07-13T10:42:44+0200, I wrote:
> Hi Tom!
>
> Ping.
>
>
> Grüße
>  Thomas
>
>
> On 2022-07-05T16:59:23+0200, I wrote:
>> Hi Tom!
>>
>> Ping.
>>
>>
>> Grüße
>>  Thomas
>>
>>
>> On 2022-06-15T23:18:10+0200, I wrote:
>>> Hi Tom!
>>>
>>> On 2022-05-13T16:20:14+0200, I wrote:
 On 2022-02-04T13:09:29+0100, Tom de Vries via Gcc  
 wrote:
> On 2/4/22 08:21, Thomas Schwinge wrote:
>> On 2022-02-03T13:35:55+, "vries at gcc dot gnu.org via Gcc-bugs" 
>>  wrote:
>>> I've tested this using (recommended) driver 470.94 on boards:

>>> while iterating over dimensions { -mptx=3.1 , -mptx=6.3 } x { 
>>> GOMP_NVPTX_JIT=-O0,  }.
>>
>> Do you use separate (nvptx-none offload target only?) builds for
>> different '-mptx' variants (likewise: '-misa'), or have you hacked 
>> up the
>> multilib configuration?
>
> Neither, I'm using --target_board=unix/foffload= for that.

 ACK, I see.  So these flags then only affect GCC/nvptx code generation
 for the actual user code (here: GCC libgomp test cases), but for the
 GCC/nvptx target libraries (such as: libc, libm, libgfortran, libgomp 
 --
 the latter especially relevant for OpenMP), it uses PTX code from one 
 of
 the two "pre-compiled" GCC/nvptx multilibs: default or '-mptx=3.1'.

 Meaning, one can't just use such a flag for "completely building code"
 for a specific configuration.  Random example,
 '-foffload-options=nvptx-none=-march=sm_75': as GCC/nvptx target
 libraries aren't being built for '-march=sm_75' multilib,
 '-foffload-options=nvptx-none=-march=sm_75' uses the default multilib,
 which isn't '-march=sm_75'.


>   ('gcc/config/nvptx/t-nvptx:MULTILIB_OPTIONS'
>> etc., I suppose?)  Should we add a few representative configurations 
>> to
>> be built by default?  And/or, should we have a way to 'configure' per
>> user needs (I suppose: '--with-multilib-list=[...]', as supported 
>> for a
>> few other targets?)?  (I see there's also a new
>> '--with-multilib-generator=[...]', haven't looked in detail.)  No 
>> matter
>> which way: again, combinatorial explosion is a problem, of course...
>
> As far as I know, the gcc build doesn't finish when switching default 
> to
> higher than sm_35, so there's little point to go to a multilib setup 
> at
> this point.  But once we fix that, we could reconsider, otherwise,
> things are likely to regress again.

 As far as I remember, several issues have been fixed.  Still waiting 
 for
 Roger's "middle-end: Support ABIs that pass FP values as wider 
 integers"
 or something similar, but that PR104489 issue is being worked around by
 "Limit HFmode support to mexperimental", if I got that right.

 Now I'm not suggesting we should now enable all or any random GCC/nvptx
 multilibs, to get all these variants of GCC/nvptx target libraries 
 built;
 especially also given that GCC/nvptx code generation currently doesn't
 make too much use of the new capabilities.

 However, we do have a specific request that a customer would like to be
 able to change at GCC 'configure' time the GCC/nvptx default multilib
 (including that being used for building corresponding GCC/nvptx target
 libraries).

 Per 'gcc/doc/install.texi', I do see that some GCC targets allow for
 GCC 'configure'-time '--with-multilib-list=[...]', or
 '--with-multilib-generator=[...]', and I suppose we could be doing
 something similar?  But before starting implementing, I'd like your
 input, as you'll be the one to approve in the end.  And/or, maybe 
 you've
 already made up your own ideas about that?
>>>
>>> So, instead of "random GCC/nvptx multilib configuration" (last
>>> paragraph), I've come up with a way to implement our customer's request
>>> (second last paragraph): 'configure' GCC/nvptx '--with-arch=sm_70'.
>>>
>>> I think I've implemented this in a way so that "random GCC/nvptx 
>>> multilib
>>> configuration" may 

[PING^8] nvptx: forward '-v' command-line option to assembler, linker

[Thomas Schwinge]

Hi Tom!

Ping.


Grüße
 Thomas


On 2022-08-16T17:12:47+0200, I wrote:
> Hi Tom!
>
> Ping.
>
>
> Grüße
>  Thomas
>
>
> On 2022-08-06T21:20:23+0200, I wrote:
>> Hi Tom!
>>
>> Ping.
>>
>>
>> Grüße
>>  Thomas
>>
>>
>> On 2022-07-27T17:48:46+0200, I wrote:
>>> Hi Tom!
>>>
>>> Ping.
>>>
>>>
>>> Grüße
>>>  Thomas
>>>
>>>
>>> On 2022-07-20T14:44:36+0200, I wrote:
 Hi Tom!

 Ping.


 Grüße
  Thomas


 On 2022-07-13T10:41:23+0200, I wrote:
> Hi Tom!
>
> Ping.
>
>
> Grüße
>  Thomas
>
>
> On 2022-07-05T16:58:54+0200, I wrote:
>> Hi Tom!
>>
>> Ping.
>>
>>
>> Grüße
>>  Thomas
>>
>>
>> On 2022-06-07T17:41:16+0200, I wrote:
>>> Hi!
>>>
>>> On 2022-05-30T09:06:21+0200, Tobias Burnus  
>>> wrote:
 On 29.05.22 22:49, Thomas Schwinge wrote:
> Not sure if that's what you had in mind, but what do you think about 
> the
> attached "nvptx: forward '-v' command-line option to assembler, 
> linker"?
> OK to push to GCC master branch (after merging
> 
> "Put '-v' verbose output onto stderr instead of stdout")?

 I was mainly thinking of some way to have it available — which
 '-foffload-options=-Wa,-v' already permits on the GCC side. (Once the
 nvptx-tools patch actually makes use of the '-v'.)
>>>
>>> (Merged a week ago.)
>>>
 If I understand your patch correctly, this patch now causes 'gcc -v' to
 imply 'gcc -v -Wa,-v'. I think that's okay, since 'gcc -v' already
 outputs a lot of lines and those lines can be helpful to understand 
 what
 happens and what not.
>>>
>>> ACK.
>>>
 Tom, your thoughts on this?
>>>
>>> Ping.
>>>
>>>
>>> Grüße
>>>  Thomas


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
>From 17c35607d4927299b0c4bd19dd6fd205c85c4a4b Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Sun, 29 May 2022 22:31:43 +0200
Subject: [PATCH] nvptx: forward '-v' command-line option to assembler, linker

For example, for offloading compilation with '-save-temps -v', before vs. after
word-diff then looks like:

[...]
 [...]/build-gcc-offload-nvptx-none/gcc/as {+-v -v+} -o ./a.xnvptx-none.mkoffload.o ./a.xnvptx-none.mkoffload.s
{+Verifying sm_30 code with sm_35 code generation.+}
{+ ptxas -c -o /dev/null ./a.xnvptx-none.mkoffload.o --gpu-name sm_35 -O0+}
[...]
 [...]/build-gcc-offload-nvptx-none/gcc/collect2 {+-v -v+} -o ./a.xnvptx-none.mkoffload [...] @./a.xnvptx-none.mkoffload.args.1 -lgomp -lgcc -lc -lgcc
{+collect2 version 12.0.1 20220428 (experimental)+}
{+[...]/build-gcc-offload-nvptx-none/gcc/collect-ld -v -v -o ./a.xnvptx-none.mkoffload [...] ./a.xnvptx-none.mkoffload.o -lgomp -lgcc -lc -lgcc+}
{+Linking ./a.xnvptx-none.mkoffload.o as 0+}
{+trying lib libc.a+}
{+trying lib libgcc.a+}
{+trying lib libgomp.a+}
{+Resolving abort+}
{+Resolving acc_on_device+}
{+Linking libgomp.a::oacc-init.o/ as 1+}
{+Linking libc.a::lib_a-abort.o/   as 2+}
[...]

(This depends on 
"Put '-v' verbose output onto stderr instead of stdout".)

	gcc/
	* config/nvptx/nvptx.h (ASM_SPEC, LINK_SPEC): Define.
---
 gcc/config/nvptx/nvptx.h | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/gcc/config/nvptx/nvptx.h b/gcc/config/nvptx/nvptx.h
index ed72c253191..b184f1d0150 100644
--- a/gcc/config/nvptx/nvptx.h
+++ b/gcc/config/nvptx/nvptx.h
@@ -27,6 +27,13 @@
 
 /* Run-time Target.  */
 
+/* Assembler supports '-v' option; handle similar to
+   '../../gcc.cc:asm_options', 'HAVE_GNU_AS'.  */
+#define ASM_SPEC "%{v}"
+
+/* Linker supports '-v' option.  */
+#define LINK_SPEC "%{v}"
+
 #define STARTFILE_SPEC "%{mmainkernel:crt0.o}"
 
 #define TARGET_CPU_CPP_BUILTINS() nvptx_cpu_cpp_builtins ()
-- 
2.25.1

Re: [PATCH] m32c-rtems: remove obsoleted port

[Richard Biener via Gcc-patches]

On Thu, Aug 25, 2022 at 10:37 AM Martin Liška  wrote:
>
> Remove the port that has been marked obsolete in GCC 12 change notes.
>
> Ready to be installed?

OK.

> Thanks,
> Martin
>
> contrib/ChangeLog:
>
> * config-list.mk: Remove the port.
>
> gcc/ChangeLog:
>
> * config.gcc: Remove the port.
> * config/m32c/rtems.h: Removed.
>
> libgcc/ChangeLog:
>
> * config.host: Remove the port.
> ---
>  contrib/config-list.mk  |  2 +-
>  gcc/config.gcc  |  6 --
>  gcc/config/m32c/rtems.h | 38 --
>  libgcc/config.host  |  2 +-
>  4 files changed, 2 insertions(+), 46 deletions(-)
>  delete mode 100644 gcc/config/m32c/rtems.h
>
> diff --git a/contrib/config-list.mk b/contrib/config-list.mk
> index c4db8dc849a..015f3a83bc6 100644
> --- a/contrib/config-list.mk
> +++ b/contrib/config-list.mk
> @@ -59,7 +59,7 @@ LIST = aarch64-elf aarch64-linux-gnu aarch64-rtems \
>ia64-freebsd6 ia64-linux ia64-hpux ia64-hp-vms iq2000-elf lm32-elf \
>lm32-rtems lm32-uclinux \
>loongarch64-linux-gnuf64 loongarch64-linux-gnuf32 loongarch64-linux-gnusf \
> -  m32c-rtems m32c-elf m32r-elf m32rle-elf \
> +  m32c-elf m32r-elf m32rle-elf \
>m68k-elf m68k-netbsdelf \
>m68k-uclinux m68k-linux m68k-rtems \
>mcore-elf microblaze-linux microblaze-elf \
> diff --git a/gcc/config.gcc b/gcc/config.gcc
> index 02f58970db0..8e8e1d0513f 100644
> --- a/gcc/config.gcc
> +++ b/gcc/config.gcc
> @@ -251,7 +251,6 @@ case ${target} in
>   cr16-*-*  \
>   | hppa[12]*-*-hpux10* \
>   | hppa[12]*-*-hpux11* \
> - | m32c-*-rtems*   \
>   )
>  if test "x$enable_obsolete" != xyes; then
>echo "*** Configuration ${target} is obsolete." >&2
> @@ -3555,11 +3554,6 @@ am33_2.0-*-linux*)
> gas=yes gnu_ld=yes
> use_collect2=no
> ;;
> -m32c-*-rtems*)
> -   tm_file="elfos.h ${tm_file} m32c/rtems.h rtems.h newlib-stdint.h"
> -   c_target_objs="m32c-pragma.o"
> -   cxx_target_objs="m32c-pragma.o"
> -   ;;
>  m32c-*-elf*)
> tm_file="elfos.h newlib-stdint.h ${tm_file}"
> c_target_objs="m32c-pragma.o"
> diff --git a/gcc/config/m32c/rtems.h b/gcc/config/m32c/rtems.h
> deleted file mode 100644
> index 553f77cfd4d..000
> --- a/gcc/config/m32c/rtems.h
> +++ /dev/null
> @@ -1,38 +0,0 @@
> -/* Definitions for rtems targeting a M32C using ELF.
> -   Copyright (C) 2008-2022 Free Software Foundation, Inc.
> -   Contributed by Joel Sherrill (j...@oarcorp.com).
> -
> -   This file is part of GCC.
> -
> -   GCC is free software; you can redistribute it and/or modify it
> -   under the terms of the GNU General Public License as published
> -   by the Free Software Foundation; either version 3, or (at your
> -   option) any later version.
> -
> -   GCC is distributed in the hope that it will be useful, but WITHOUT
> -   ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
> -   or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public
> -   License for more details.
> -
> -   Under Section 7 of GPL version 3, you are granted additional
> -   permissions described in the GCC Runtime Library Exception, version
> -   3.1, as published by the Free Software Foundation.
> -
> -   You should have received a copy of the GNU General Public License and
> -   a copy of the GCC Runtime Library Exception along with this program;
> -   see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
> -   .  */
> -
> -/* Target OS builtins.  */
> -#undef TARGET_OS_CPP_BUILTINS
> -#define TARGET_OS_CPP_BUILTINS()   \
> -  do   \
> -{  \
> -   builtin_define ("__rtems__");   \
> -   builtin_define ("__USE_INIT_FINI__");   \
> -   builtin_assert ("system=rtems");\
> -}  \
> -  while (0)
> -
> -/* Use the default */
> -#undef LINK_GCC_C_SEQUENCE_SPEC
> diff --git a/libgcc/config.host b/libgcc/config.host
> index b2a0a8e1aa9..974de349653 100644
> --- a/libgcc/config.host
> +++ b/libgcc/config.host
> @@ -1516,7 +1516,7 @@ am33_2.0-*-linux*)
> extra_parts="crtbegin.o crtend.o crtbeginS.o crtendS.o"
> tmake_file="$tmake_file t-fdpbit"
> ;;
> -m32c-*-elf*|m32c-*-rtems*)
> +m32c-*-elf*)
> tmake_file="$tmake_file m32c/t-m32c"
> ;;
>  nvptx-*)
> --
> 2.37.2
>

Re: LoongArch: add model attribute

[Richard Sandiford via Gcc-patches]

Xi Ruoyao via Gcc-patches  writes:
> Another attempt to make kernel module happy.
>
> One remaining issue: the patch cannot diagnostic some insane thing like
>
> int x __attribute__((model("normal")));
> int x __attribute__((model("extreme")));
>
> It seems incredibly difficult to diagnose such thing: I can't figure out
> any solution w/o invasion into the frontend.  IA-64 model() only accepts
> small so this is not a problem for them, and M32R model() also cannot
> diagnose such error.
>
> Any suggestion is welcomed.

You might be able to detect this in the merge_decl_attributes hook.

Thanks,
Richard

[PATCH] Improve uninit pass dumping

[Richard Biener via Gcc-patches]

This produces less redundancy and more complete info dumping
the control dependence chains.

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

* gimple-predicate-analysis.cc (format_edge_vec): Dump
both source and destination.
(dump_dep_chains): Remove.
(uninit_analysis::init_use_preds): Remove redundant
dumping of chains.
---
 gcc/gimple-predicate-analysis.cc | 34 
 1 file changed, 4 insertions(+), 30 deletions(-)

diff --git a/gcc/gimple-predicate-analysis.cc b/gcc/gimple-predicate-analysis.cc
index 62a13c39d7a..f9ae8910a26 100644
--- a/gcc/gimple-predicate-analysis.cc
+++ b/gcc/gimple-predicate-analysis.cc
@@ -122,10 +122,10 @@ format_edge_vec (const vec )
 {
   char es[32];
   const_edge e = ev[i];
-  sprintf (es, "%u", e->src->index);
+  sprintf (es, "%u -> %u", e->src->index, e->dest->index);
   str += es;
   if (i + 1 < n)
-   str += " -> ";
+   str += ", ";
 }
   return str;
 }
@@ -180,28 +180,6 @@ dump_pred_chain (const pred_chain )
 }
 }
 
-/* Dump the first NCHAINS elements of the DEP_CHAINS array into DUMP_FILE.  */
-
-static void
-dump_dep_chains (const auto_vec dep_chains[], unsigned nchains)
-{
-  if (!dump_file)
-return;
-
-  for (unsigned i = 0; i != nchains; ++i)
-{
-  const auto_vec  = dep_chains[i];
-  unsigned n = v.length ();
-  for (unsigned j = 0; j != n; ++j)
-   {
- fprintf (dump_file, "%u", v[j]->src->index);
- if (j + 1 < n)
-   fprintf (dump_file, " -> ");
-   }
-  fputc ('\n', dump_file);
-}
-}
-
 /* Return the 'normalized' conditional code with operand swapping
and condition inversion controlled by SWAP_COND and INVERT.  */
 
@@ -1922,12 +1900,8 @@ uninit_analysis::init_use_preds (predicate _preds, 
basic_block def_bb,
 }
 
   if (DEBUG_PREDICATE_ANALYZER && dump_file)
-{
-  fprintf (dump_file, "predicate::predicate (def_bb = %u, use_bb = %u, 
func_t) "
-  "initialized from %u dep_chains:\n\t",
-  def_bb->index, use_bb->index, num_chains);
-  dump_dep_chains (dep_chains, num_chains);
-}
+fprintf (dump_file, "init_use_preds (def_bb = %u, use_bb = %u)\n",
+def_bb->index, use_bb->index);
 
   /* From the set of edges computed above initialize *THIS as the OR
  condition under which the definition in DEF_BB is used in USE_BB.
-- 
2.35.3

[PATCH] tree-optimization/73550 - apply MAX_NUM_CHAINS consistently

[Richard Biener via Gcc-patches]

The MAX_NUM_CHAINS is applied once with <= and once with < which
results in the chains not limited but analyis dropped completely.
That's one issue in the PR.

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

PR tree-optimization/73550
* gimple-predicate-analysis.cc (predicate::init_from_control_deps):
Do not apply MAX_NUM_CHAINS again.
---
 gcc/gimple-predicate-analysis.cc | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/gcc/gimple-predicate-analysis.cc b/gcc/gimple-predicate-analysis.cc
index f9ae8910a26..6f30d729df2 100644
--- a/gcc/gimple-predicate-analysis.cc
+++ b/gcc/gimple-predicate-analysis.cc
@@ -1674,13 +1674,6 @@ predicate::init_from_control_deps (const vec 
*dep_chains,
   if (num_chains == 0)
 return;
 
-  if (num_chains >= MAX_NUM_CHAINS)
-{
-  if (dump_file)
-   fprintf (dump_file, "MAX_NUM_CHAINS exceeded: %u\n", num_chains);
-  return;
-}
-
   /* Convert the control dependency chain into a set of predicates.  */
   m_preds.reserve (num_chains);
 
-- 
2.35.3

Re: C++: add -std={c,gnu}++{current,future}

[Koning, Paul via Gcc-patches]

> On Aug 30, 2022, at 9:22 AM, Jason Merrill via Gcc-patches 
>  wrote:
> 
> On 7/13/22 15:29, Nathan Sidwell wrote:
>> Inspired by a user question.  Jason, thoughts?
>> Since C++ is such a moving target, Microsoft have /std:c++latest
>> (AFAICT clang does not), to select the currently implemented version
>> of the working paper.  But the use of 'std:latest' is somewhat
>> ambiguous -- the current std is C++20 -- that's the latest std, the
>> next std will more than likely but not necessarily be C++23.  So this
>> adds:
>>   -std=c++current -- the current std (c++20)
>>   -std=c++future -- the working paper (c++2b)
>> also adds gnu++current and gnu++future to select the gnu-extended
>> variants.
> 
> I like this direction.
> 
> I imagine people using these to mean roughly beta and alpha, respectively.
> 
> Perhaps we also want -std=c++stable, which would currently be equivalent to 
> the default (c++17) but might not always be.
> 
> Jason

I'm not so sure.

In general, switches have a fixed meaning.  These do not.  "Current" has an 
intuitive meaning, but the actual meaning is "whatever what current when the 
version you happen to be invoking was released".  "Future" is like that only 
stranger.

If I create a software package that uses one of these switches in its Makefile, 
what will happen?  In a few years, perhaps sooner, the outcome will change 
without any changes to my code.  The answer would be "don't use those 
switches", and that is a good answer, but if so why add these switches?

paul

Re: [Patch] add more C++ name hints. v2

[Jason Merrill via Gcc-patches]

On 8/22/22 15:09, Ulrich Drepper via Gcc-patches wrote:

This is the second version of the proposed patch to add more identifiers to
the known list to give hints about #include and version numbers.

Marek looked through the first version and found it acceptable but remarked
that the list is getting long and the sequential search performed by the
current code might not be adequate.  Especially because I offered to add
even more known names to the list.

This second version replaces the current lookup implementation with a
gperf-generated hash function.  Since gperf is already a dependency for
maintainers the use of the tool itself shouldn't be a problem.

I followed the existing practice for the cfns.gperf file and its use so, if
the handling of that file works, so should the handling of the new file,
std-name-hint.gperf.

Please let me know if this is acceptable.  I built a compiler with this
code and tested the hinting.


OK, thanks.


contrib/ChangeLog
 * gcc_update (files_and_dependencies): Add gcc/cp/std-name-hint.h
 depend on gcc/cp/std-name-hint.gperf.

gcc/cp/ChangeLog
 * Make-lang.in: Add rule to build std-name-hint.h.
 * name-lookup.cc (struct std_name_hint): Remove definition.
Instead...
 Include "std-name-hint.h".
 (get_std_name_hint): Remove hints array and lookup code.  Instead
call
 std_name_hint_lookup::find.
 * std-name-hint.gperf: New file.
 * std-name-hint.h: New file.

Re: C++: add -std={c,gnu}++{current,future}

[Jason Merrill via Gcc-patches]

On 7/13/22 15:29, Nathan Sidwell wrote:

Inspired by a user question.  Jason, thoughts?

Since C++ is such a moving target, Microsoft have /std:c++latest
(AFAICT clang does not), to select the currently implemented version
of the working paper.  But the use of 'std:latest' is somewhat
ambiguous -- the current std is C++20 -- that's the latest std, the
next std will more than likely but not necessarily be C++23.  So this
adds:

   -std=c++current -- the current std (c++20)
   -std=c++future -- the working paper (c++2b)

also adds gnu++current and gnu++future to select the gnu-extended
variants.


I like this direction.

I imagine people using these to mean roughly beta and alpha, respectively.

Perhaps we also want -std=c++stable, which would currently be equivalent 
to the default (c++17) but might not always be.


Jason

Re: [PATCH v2] ipa-visibility: Optimize TLS access [PR99619]

[Alexander Monakov via Gcc-patches]

On Tue, 30 Aug 2022, Martin Jambor wrote:

> There is still the optimize attribute so in fact no, even in non-LTO
> mode if there is no current function, you cannot trust the "global"
> "optimize" thing.
> 
> Ideally we would assert that no "analysis" phase of an IPA pass reads
> the global optimization flags, so please don't add new places where we
> do.
> 
> You can either add a parameter to decl_default_tls_model to tell it
> what context it is called from and IMHO it would also be acceptable to
> check whether we have a non-NULL cfun and decide based on that (but here
> I only hope it is not something others might object to).

I see, thank you for explaining the issue, and sorry if I was a bit stubborn.

Does the attached patch (incremental change below) look better? It no longer
has the 'shortcut' where iterating over referrers is avoided for the common
case of plain 'gcc -O2' and no 'optimize' attributes, but fortunately TLS
variables are not so numerous to make chasing that worthwhile.

--- a/gcc/varasm.cc
+++ b/gcc/varasm.cc
@@ -6703,8 +6703,8 @@ have_optimized_refs (struct symtab_node *symbol)
 static bool
 optimize_dyn_tls_for_decl_p (const_tree decl)
 {
-  if (optimize)
-return true;
+  if (cfun)
+return optimize;
   return symtab->state >= IPA && have_optimized_refs (symtab_node::get (decl));
 }

Alexander

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

[Martin Liška]

On 8/30/22 13:03, Gaius Mulley via Gcc-patches wrote:
> 
> Another very brief update to say that I'm now tidying up the code and
> primary platform testing
> 
> regards,
> Gaius

Hello.

As you may know I'm working on the documentation migration from texinfo to 
Sphinx
and I noticed you have quite some documentation written in Texinfo. Thus, I 
tried
using my conversion script, but ended with:

$ m2/boot-bin/mc --olang=c++ --h-file-prefix=G 
-I/home/marxin/Programming/gcc2/gcc/m2/gm2-libs 
-I/home/marxin/Programming/gcc2/gcc/m2/gm2-compiler 
-I/home/marxin/Programming/gcc2/gcc/m2/gm2-libiberty 
-I/home/marxin/Programming/gcc2/gcc/m2/gm2-gcc --quiet  --gcc-config-system 
--extended-opaque -o=m2/gm2-compiler-boot/M2GCCDeclare.c 
/home/marxin/Programming/gcc2/gcc/m2/gm2-compiler/M2GCCDeclare.mod
/*  --extended-opaque seen therefore no #include will be used and everything 
will be declared in full.  */
terminate called after throwing an instance of 'unsigned int'
Aborted (core dumped)

$ Program received signal SIGSEGV, Segmentation fault.
0x0043771e in decl_isConst (n=0xbabababababababa) at 
/home/marxin/Programming/gcc2/gcc/m2/mc-boot/Gdecl.c:22530
22530 return n->kind == const_;
(gdb) bt
#0  0x0043771e in decl_isConst (n=0xbabababababababa) at 
/home/marxin/Programming/gcc2/gcc/m2/mc-boot/Gdecl.c:22530
#1  0x00432526 in addEnumConst (n=0xbabababababababa) at 
/home/marxin/Programming/gcc2/gcc/m2/mc-boot/Gdecl.c:19914
#2  0x004313aa in visitNode (v=0x17cd5910, n=0xbabababababababa, p=...) 
at /home/marxin/Programming/gcc2/gcc/m2/mc-boot/Gdecl.c:19240
#3  0x00430ba9 in visitIntrinsic (v=0x17cd5910, n=0x5015c0, p=...) at 
/home/marxin/Programming/gcc2/gcc/m2/mc-boot/Gdecl.c:18871
#4  0x00430cc6 in visitDependants (v=0x17cd5910, n=0x5015c0, p=...) at 
/home/marxin/Programming/gcc2/gcc/m2/mc-boot/Gdecl.c:18923
#5  0x004313c1 in visitNode (v=0x17cd5910, n=0x5015c0, p=...) at 
/home/marxin/Programming/gcc2/gcc/m2/mc-boot/Gdecl.c:19241
#6  0x004325b8 in populateTodo (p=...) at 
/home/marxin/Programming/gcc2/gcc/m2/mc-boot/Gdecl.c:19938
#7  0x00432613 in topologicallyOut (c=..., t=..., v=..., tp=..., 
pc=..., pt=..., pv=...) at 
/home/marxin/Programming/gcc2/gcc/m2/mc-boot/Gdecl.c:19957
#8  0x00426ffb in outDeclsImpC (p=0x17cc39a0, s=...) at 
/home/marxin/Programming/gcc2/gcc/m2/mc-boot/Gdecl.c:13910
#9  0x00432f2f in outImpC (p=0x17cc39a0, n=0x541800) at 
/home/marxin/Programming/gcc2/gcc/m2/mc-boot/Gdecl.c:20142
#10 0x004337b5 in outC (p=0x17cc39a0, n=0x541800) at 
/home/marxin/Programming/gcc2/gcc/m2/mc-boot/Gdecl.c:20285
#11 0x0043bd9b in decl_out () at 
/home/marxin/Programming/gcc2/gcc/m2/mc-boot/Gdecl.c:26621
#12 0x0043eae6 in doCompile (s=0x50a190) at 
/home/marxin/Programming/gcc2/gcc/m2/mc-boot/GmcComp.c:223
#13 0x0043f646 in mcComp_compile (s=0x50a190) at 
/home/marxin/Programming/gcc2/gcc/m2/mc-boot/GmcComp.c:637
#14 0x00451d91 in init () at 
/home/marxin/Programming/gcc2/gcc/m2/mc-boot/Gtop.c:59
#15 0x00451da8 in _M2_top_init (argc=12, argv=0x7fffd9a8) at 
/home/marxin/Programming/gcc2/gcc/m2/mc-boot/Gtop.c:64
#16 0x0048b4c2 in main (argc=12, argv=0x7fffd9a8) at 
m2/mc-boot/main.c:179

Have a couple of questions:

1) What's gcc/m2/www/tools/createhtml.py about? Will you need it once the 
branch is merged to master?
2) You generate some texi files on fly: ./gcc/m2/gm2-ebnf.texi, 
./gcc/m2/Builtins.texi
Would it be possible emitting Sphinx in the future?

Thanks,
Martin

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

[Richard Sandiford via Gcc-patches]

Surya Kumari Jangala via Gcc-patches  writes:
> sched1: Fix -fcompare-debug issue in schedule_region [PR105586]
>
> In schedule_region(), a basic block that does not contain any real insns
> is not scheduled and the dfa state at the entry of the bb is not copied
> to the fallthru basic block. However a DEBUG insn is treated as a real
> insn, and if a bb contains non-real insns and a DEBUG insn, it's dfa
> state is copied to the fallthru bb. This was resulting in
> -fcompare-debug failure as the incoming dfa state of the fallthru block
> is different with -g. We should always copy the dfa state of a bb to
> it's fallthru bb even if the bb does not contain real insns.
>
> 2022-08-22  Surya Kumari Jangala  
>
> gcc/
>   PR rtl-optimization/105586
>   * sched-rgn.cc (schedule_region): Always copy dfa state to
>   fallthru block.
>
> gcc/testsuite/
>   PR rtl-optimization/105586
>   * gcc.target/powerpc/pr105586.c: New test.
>
>
> diff --git a/gcc/sched-rgn.cc b/gcc/sched-rgn.cc
> index 0dc2a8f2851..6c9202c0b2b 100644
> --- a/gcc/sched-rgn.cc
> +++ b/gcc/sched-rgn.cc
> @@ -3082,6 +3082,24 @@ free_bb_state_array (void)
>bb_state = NULL;
>  }
>  
> +static void
> +save_state_for_fallthru_edge (basic_block last_bb, state_t state)

The convention (not always followed) is to have a comment above each
function explaining what it does.  How about something like:

/* If LAST_BB falls through to another block B, record that B should
   start with DFA start STATE.  */

OK for trunk with that change (and with the new changelog).

Thanks,
Richard

> +{
> +  edge f = find_fallthru_edge (last_bb->succs);
> +  if (f
> +  && (!f->probability.initialized_p ()
> +   || (f->probability.to_reg_br_prob_base () * 100
> +   / REG_BR_PROB_BASE
> +   >= param_sched_state_edge_prob_cutoff)))
> +  {
> +memcpy (bb_state[f->dest->index], state,
> + dfa_state_size);
> +if (sched_verbose >= 5)
> +  fprintf (sched_dump, "saving state for edge %d->%d\n",
> +f->src->index, f->dest->index);
> +  }
> +}
> +
>  /* Schedule a region.  A region is either an inner loop, a loop-free
> subroutine, or a single basic block.  Each bb in the region is
> scheduled after its flow predecessors.  */
> @@ -3155,6 +3173,7 @@ schedule_region (int rgn)
>if (no_real_insns_p (head, tail))
>   {
> gcc_assert (first_bb == last_bb);
> +   save_state_for_fallthru_edge (last_bb, bb_state[first_bb->index]);
> continue;
>   }
>  
> @@ -3173,26 +3192,13 @@ schedule_region (int rgn)
>curr_bb = first_bb;
>if (dbg_cnt (sched_block))
>  {
> -   edge f;
> int saved_last_basic_block = last_basic_block_for_fn (cfun);
>  
> schedule_block (_bb, bb_state[first_bb->index]);
> gcc_assert (EBB_FIRST_BB (bb) == first_bb);
> sched_rgn_n_insns += sched_n_insns;
> realloc_bb_state_array (saved_last_basic_block);
> -   f = find_fallthru_edge (last_bb->succs);
> -   if (f
> -   && (!f->probability.initialized_p ()
> -   || (f->probability.to_reg_br_prob_base () * 100
> -   / REG_BR_PROB_BASE
> -   >= param_sched_state_edge_prob_cutoff)))
> - {
> -   memcpy (bb_state[f->dest->index], curr_state,
> -   dfa_state_size);
> -   if (sched_verbose >= 5)
> - fprintf (sched_dump, "saving state for edge %d->%d\n",
> -  f->src->index, f->dest->index);
> - }
> +   save_state_for_fallthru_edge (last_bb, curr_state);
>  }
>else
>  {
> diff --git a/gcc/testsuite/gcc.target/powerpc/pr105586.c 
> b/gcc/testsuite/gcc.target/powerpc/pr105586.c
> new file mode 100644
> index 000..bd397f58bc0
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/powerpc/pr105586.c
> @@ -0,0 +1,19 @@
> +/* { dg-options "-mdejagnu-tune=power4 -O2 -fcompare-debug 
> -fno-if-conversion -fno-guess-branch-probability" } */
> +
> +extern int bar(int i);
> +
> +typedef unsigned long u64;
> +int g;
> +
> +__int128 h;
> +
> +void
> +foo(int a, int b) {
> +  int i;
> +  char u8_1 = g, u8_3 = a;
> +  u64 u64_1 = bar(0), u64_3 = u8_3 * u64_1;
> +  __int128 u128_1 = h ^ __builtin_expect(i, 0);
> +  u64 u64_4 = u64_1 << ((__builtin_sub_overflow_p(0, u8_1, (u64)0) ^ u128_1) 
> & 8);
> +  u64 u64_r = b + u64_3 + u64_4;
> +  bar((short)u64_r + u8_3);
> +}

[COMMITTED] Force a [NAN, NAN] range when the definite NAN property is set.

[Aldy Hernandez via Gcc-patches]

Setting the definite NAN property should also force a [NAN, NAN]
range, otherwise we'd have two ways of representing a NAN: with the
endpoints or with the property.  In the ranger world we avoid at all
costs having more than one representation for a range.

In doing this, I removed the FRANGE_PROP_ACCESSOR macro, since it
looks like setting a property may have repercurssions in the range
itself, so it's best for the client to definte its own setter.

gcc/ChangeLog:

* value-range-storage.cc (frange_storage_slot::get_frange): Use
frange_nan.
* value-range.cc (frange::set_nan): New.
(frange_nan): Move to header file.
(range_tests_nan): Adjust frange_nan callers to pass type.
New test.
* value-range.h (FRANGE_PROP_ACCESSOR): Remove.
(frange_nan): New.
---
 gcc/value-range-storage.cc |  4 +--
 gcc/value-range.cc | 55 +-
 gcc/value-range.h  | 26 +-
 3 files changed, 51 insertions(+), 34 deletions(-)

diff --git a/gcc/value-range-storage.cc b/gcc/value-range-storage.cc
index adf23c39f0d..494392737ac 100644
--- a/gcc/value-range-storage.cc
+++ b/gcc/value-range-storage.cc
@@ -267,9 +267,7 @@ frange_storage_slot::get_frange (frange , tree type) const
   // endpoints.
   if (m_props.get_nan ().yes_p ())
 {
-  REAL_VALUE_TYPE rv;
-  real_nan (, "", 1, TYPE_MODE (type));
-  r.set (type, rv, rv);
+  r = frange_nan (type);
   return;
 }
 
diff --git a/gcc/value-range.cc b/gcc/value-range.cc
index bcc6651701b..b6d6c62c06c 100644
--- a/gcc/value-range.cc
+++ b/gcc/value-range.cc
@@ -267,6 +267,29 @@ tree_compare (tree_code code, tree op1, tree op2)
   return !integer_zerop (fold_build2 (code, integer_type_node, op1, op2));
 }
 
+// Set the NAN property.  Adjust the range if appopriate.
+
+void
+frange::set_nan (fp_prop::kind k)
+{
+  if (k == fp_prop::YES)
+{
+  gcc_checking_assert (!undefined_p ());
+  *this = frange_nan (m_type);
+  return;
+}
+
+  // Setting NO on an obviously NAN range is nonsensical.
+  gcc_checking_assert (k != fp_prop::NO || !real_isnan (_min));
+
+  // Setting VARYING on an obviously NAN range is a no-op.
+  if (k == fp_prop::VARYING && real_isnan (_min))
+return;
+
+  m_props.set_nan (k);
+  normalize_kind ();
+}
+
 // Setter for franges.
 
 void
@@ -3493,17 +3516,6 @@ frange_float (const char *lb, const char *ub, tree type 
= float_type_node)
   return frange (type, min, max);
 }
 
-// Build a NAN of type TYPE.
-
-static inline frange
-frange_nan (tree type = float_type_node)
-{
-  REAL_VALUE_TYPE r;
-
-  gcc_assert (real_nan (, "", 1, TYPE_MODE (type)));
-  return frange (type, r, r);
-}
-
 static void
 range_tests_nan ()
 {
@@ -3517,18 +3529,16 @@ range_tests_nan ()
   ASSERT_NE (r0, r1);
   r0.set_nan (fp_prop::YES);
   ASSERT_NE (r0, r1);
-  r0.set_nan (fp_prop::VARYING);
-  ASSERT_EQ (r0, r1);
 
   // NAN ranges are not equal to each other.
-  r0 = frange_nan ();
+  r0 = frange_nan (float_type_node);
   r1 = r0;
   ASSERT_FALSE (r0 == r1);
   ASSERT_FALSE (r0 == r0);
   ASSERT_TRUE (r0 != r0);
 
   // Make sure that combining NAN and INF doesn't give any crazy results.
-  r0 = frange_nan ();
+  r0 = frange_nan (float_type_node);
   ASSERT_TRUE (r0.get_nan ().yes_p ());
   r1 = frange_float ("+Inf", "+Inf");
   r0.union_ (r1);
@@ -3536,22 +3546,29 @@ range_tests_nan ()
   ASSERT_TRUE (r0.varying_p ());
 
   // [INF, INF] ^ NAN = VARYING
-  r0 = frange_nan ();
+  r0 = frange_nan (float_type_node);
   r1 = frange_float ("+Inf", "+Inf");
   r0.intersect (r1);
   ASSERT_TRUE (r0.varying_p ());
 
   // NAN ^ NAN = NAN
-  r0 = frange_nan ();
-  r1 = frange_nan ();
+  r0 = frange_nan (float_type_node);
+  r1 = frange_nan (float_type_node);
   r0.intersect (r1);
   ASSERT_TRUE (r0.get_nan ().yes_p ());
 
   // VARYING ^ NAN = NAN.
-  r0 = frange_nan ();
+  r0 = frange_nan (float_type_node);
   r1.set_varying (float_type_node);
   r0.intersect (r1);
   ASSERT_TRUE (r0.get_nan ().yes_p ());
+
+  // Setting the NAN bit to yes, forces to range to [NAN, NAN].
+  r0.set_varying (float_type_node);
+  r0.set_nan (fp_prop::YES);
+  ASSERT_TRUE (r0.get_nan ().yes_p ());
+  ASSERT_TRUE (real_isnan (_bound ()));
+  ASSERT_TRUE (real_isnan (_bound ()));
 }
 
 static void
diff --git a/gcc/value-range.h b/gcc/value-range.h
index 43b231b8fe0..07379d58f88 100644
--- a/gcc/value-range.h
+++ b/gcc/value-range.h
@@ -323,16 +323,6 @@ private:
   } u;
 };
 
-// Accessors for getting/setting all FP properties at once.
-
-#define FRANGE_PROP_ACCESSOR(NAME) \
-  fp_prop get_##NAME () const { return m_props.get_##NAME (); }\
-  void set_##NAME (fp_prop::kind f)\
-  {\
-m_props.set_##NAME (f);\
-normalize_kind (); \
-  }
-
 // A floating 

Re: C++: add -std={c,gnu}++{current,future}

[Marek Polacek via Gcc-patches]

On Wed, Jul 13, 2022 at 03:29:04PM -0400, Nathan Sidwell via Gcc-patches wrote:
> Inspired by a user question.  Jason, thoughts?

FWIW, this makes sense.  I mean, how could I be against a patch
quoting Macbeth?!
 
> Since C++ is such a moving target, Microsoft have /std:c++latest
> (AFAICT clang does not), to select the currently implemented version
> of the working paper.  But the use of 'std:latest' is somewhat
> ambiguous -- the current std is C++20 -- that's the latest std, the
> next std will more than likely but not necessarily be C++23.  So this
> adds:
> 
>   -std=c++current -- the current std (c++20)
>   -std=c++future -- the working paper (c++2b)
> 
> also adds gnu++current and gnu++future to select the gnu-extended
> variants.
> 
> nathan
> 
> -- 
> Nathan Sidwell

> From 9671f4d5e7efa130280b6d50fb4e9e8492d5b587 Mon Sep 17 00:00:00 2001
> From: Nathan Sidwell 
> Date: Wed, 13 Jul 2022 12:11:40 -0700
> Subject: [PATCH] C++: add -std={c,gnu}++{current,future}
> 
> Since C++ is such a moving target, Microsoft have /std:c++latest
> (AFAICT clang does not), to select the currently implemented version
> of the working paper.  But the use of 'std:latest' is somewhat
> ambiguous -- the current std is C++20 -- that's the latest std, the
> next std will more than likely but not necessarily be C++23.  So this
> adds:
> 
>   -std=c++current -- the current std (c++20)
>   -std=c++future -- the working paper (c++2b)
> 
> also adds gnu++current and gnu++future to select the gnu-extended
> variants.
> 
>   gcc/
>   * doc/invoke.texi (-std=): Document new c++ current & future
>   options.
>   gcc/c-family/
>   * c.opt (-std={c,gnu}++{current,future}: New alias options.
>   gcc/testsuite/
>   * g++.dg/gnu-current.C: New.
>   * g++.dg/gnu-future.C: New.
>   * g++.dg/std-current.C: New.
>   * g++.dg/std-future.C: New.
> ---
>  gcc/c-family/c.opt | 16 
>  gcc/doc/invoke.texi| 23 +++
>  gcc/testsuite/g++.dg/gnu-current.C |  7 +++
>  gcc/testsuite/g++.dg/gnu-future.C  |  7 +++
>  gcc/testsuite/g++.dg/std-current.C | 11 +++
>  gcc/testsuite/g++.dg/std-future.C  |  8 
>  6 files changed, 72 insertions(+)
>  create mode 100644 gcc/testsuite/g++.dg/gnu-current.C
>  create mode 100644 gcc/testsuite/g++.dg/gnu-future.C
>  create mode 100644 gcc/testsuite/g++.dg/std-current.C
>  create mode 100644 gcc/testsuite/g++.dg/std-future.C
> 
> diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
> index 44e1a60ce24..9292029a967 100644
> --- a/gcc/c-family/c.opt
> +++ b/gcc/c-family/c.opt
> @@ -2321,6 +2321,14 @@ std=c++23
>  C++ ObjC++ Undocumented
>  Conform to the ISO 2023 C++ draft standard (experimental and incomplete 
> support).
>  
> +std=c++current
> +C++ ObjC++ Alias(std=c++20) Undocumented
> +Conform to the current ISO C++ standard (C++20).
> +
> +std=c++future
> +C++ ObjC++ Alias(std=c++23) Undocumented
> +Conform to a future ISO C++ standard (C++2b, experimentatl and incomplete 
> support).

Since the option says 23, why not use 23 here as well instead of 2b?
And below too.

> +
>  std=c11
>  C ObjC
>  Conform to the ISO 2011 C standard.
> @@ -2407,6 +2415,14 @@ std=gnu++23
>  C++ ObjC++ Undocumented
>  Conform to the ISO 2023 C++ draft standard with GNU extensions (experimental 
> and incomplete support).
>  
> +std=gnu++current
> +C++ ObjC++ Alias(std=gnu++20) Undocumented
> +Conform to the current ISO C++ standard with GNU extensions (C++20).
> +
> +std=gnu++future
> +C++ ObjC++ Alias(std=gnu++23) Undocumented
> +Conform to a future ISO C++ standard with GNU extensions (C++2b, 
> experimentatl and incomplete support).
> +
>  std=gnu11
>  C ObjC
>  Conform to the ISO 2011 C standard with GNU extensions.
> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
> index d5ff1018372..1c0edb9df68 100644
> --- a/gcc/doc/invoke.texi
> +++ b/gcc/doc/invoke.texi
> @@ -2462,6 +2462,17 @@ GNU dialect of @option{-std=c++17}.
>  This is the default for C++ code.
>  The name @samp{gnu++1z} is deprecated.
>  
> +@item gnu++current
> +@itemx gnu++current
> +GNU dialect of the current C++ standard, currently @option{-std=gnu++20}.
> +The C++ version selected by this option is a moving target.
> +
> +@item gnu++future
> +@itemx gnu++future
> +GNU dialect of the next C++ standard, currently @option{-std=gnu++2b}.
> +The C++ version selected by this option is a moving target (as are the
> +semantics of that proposed version).
> +
>  @item c++20
>  @itemx c++2a
>  The 2020 ISO C++ standard plus amendments.
> @@ -2487,6 +2498,18 @@ change in incompatible ways in future releases.
>  GNU dialect of @option{-std=c++2b}.  Support is highly experimental,
>  and will almost certainly change in incompatible ways in future
>  releases.
> +
> +@item c++current
> +@itemx c++current
> +The current C++ standard, currently @option{-std=gnu++20}.
> +The C++ version selected by this option is a moving target.
> +
> +@item 

Re: [PATCH v2] ipa-visibility: Optimize TLS access [PR99619]

[Martin Jambor]

On Fri, Aug 26 2022, Alexander Monakov wrote:
> On Fri, 26 Aug 2022, Martin Jambor wrote:
>
>> > +/* Check if promoting general-dynamic TLS access model to local-dynamic is
>> > +   desirable for DECL.  */
>> > +
>> > +static bool
>> > +optimize_dyn_tls_for_decl_p (const_tree decl)
>> > +{
>> > +  if (optimize)
>> > +return true;
>> 
>> ...this.  This is again an access to optimize which in LTO IPA phase is
>> not really meaningful.  Can the test be simply removed?  If not (but
>> please look at why), I'd suggest to test the overall optimize level only
>> if there is a non-NULL cfun.
>
> I'd prefer to keep it. This code is also called from the front-ends when
> assigning initial TLS access model (during parsing, at the point where
> visibility attributes, if present, have not been processed yet). There
> we don't have IPA structures, but 'optimize' is set up.
>
> I also want to avoid iterating over referring functions in non-LTO mode
> where trusting 'optimize' should be fine during this IPA pass I think?

There is still the optimize attribute so in fact no, even in non-LTO
mode if there is no current function, you cannot trust the "global"
"optimize" thing.

Ideally we would assert that no "analysis" phase of an IPA pass reads
the global optimization flags, so please don't add new places where we
do.

You can either add a parameter to decl_default_tls_model to tell it
what context it is called from and IMHO it would also be acceptable to
check whether we have a non-NULL cfun and decide based on that (but here
I only hope it is not something others might object to).

Martin

[PATCH] tree-optimization/67196 - normalize use predicates earlier

[Richard Biener via Gcc-patches]

The following makes sure to have use predicates simplified and
normalized before doing uninit_analysis::overlap because that
otherwise cannot pick up all flag setting cases.  This fixes
half of the issue in PR67196 and conveniently resolves the
XFAIL in gcc.dg/uninit-pred-7_a.c.

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

PR tree-optimization/67196
* gimple-predicate-analysis.cc (uninit_analysis::is_use_guarded):
Simplify and normalize use prediates before first use.

* gcc.dg/uninit-pred-7_a.c: Un-XFAIL.
---
 gcc/gimple-predicate-analysis.cc   | 6 +++---
 gcc/testsuite/gcc.dg/uninit-pred-7_a.c | 2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/gcc/gimple-predicate-analysis.cc b/gcc/gimple-predicate-analysis.cc
index ffdd8a15fe7..62a13c39d7a 100644
--- a/gcc/gimple-predicate-analysis.cc
+++ b/gcc/gimple-predicate-analysis.cc
@@ -2087,6 +2087,9 @@ uninit_analysis::is_use_guarded (gimple *use_stmt, 
basic_block use_bb,
   if (!init_use_preds (use_preds, def_bb, use_bb))
 return false;
 
+  use_preds.simplify (use_stmt, /*is_use=*/true);
+  use_preds.normalize (use_stmt, /*is_use=*/true);
+
   /* Try to prune the dead incoming phi edges.  */
   if (!overlap (phi, opnds, visited, use_preds))
 {
@@ -2106,9 +2109,6 @@ uninit_analysis::is_use_guarded (gimple *use_stmt, 
basic_block use_bb,
   m_phi_def_preds.normalize (phi);
 }
 
-  use_preds.simplify (use_stmt, /*is_use=*/true);
-  use_preds.normalize (use_stmt, /*is_use=*/true);
-
   /* Return true if the predicate guarding the valid definition (i.e.,
  *THIS) is a superset of the predicate guarding the use (i.e.,
  USE_PREDS).  */
diff --git a/gcc/testsuite/gcc.dg/uninit-pred-7_a.c 
b/gcc/testsuite/gcc.dg/uninit-pred-7_a.c
index 434d90ac570..c2ba2a4248d 100644
--- a/gcc/testsuite/gcc.dg/uninit-pred-7_a.c
+++ b/gcc/testsuite/gcc.dg/uninit-pred-7_a.c
@@ -23,7 +23,7 @@ int foo (int n, int l, int m, int r)
   blah(v); /* { dg-bogus "uninitialized" "bogus warning" } */
 
   if ( l )
-  blah(v); /* { dg-bogus "uninitialized" "bogus warning" { xfail *-*-* } } 
*/
+  blah(v); /* { dg-bogus "uninitialized" "bogus warning" } */
 
   return 0;
 }
-- 
2.35.3

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

[Gaius Mulley via Gcc-patches]

Another very brief update to say that I'm now tidying up the code and
primary platform testing

regards,
Gaius

Re: [Patch] add more C++ name hints. v2

[Ulrich Drepper via Gcc-patches]

Ping!  Anyone interested in this.  I'm bootstrapping my trunk builds with
this patch without problems.

On Mon, Aug 22, 2022 at 9:09 PM Ulrich Drepper  wrote:

> This is the second version of the proposed patch to add more identifiers
> to the known list to give hints about #include and version numbers.
>
> Marek looked through the first version and found it acceptable but
> remarked that the list is getting long and the sequential search performed
> by the current code might not be adequate.  Especially because I offered to
> add even more known names to the list.
>
> This second version replaces the current lookup implementation with a
> gperf-generated hash function.  Since gperf is already a dependency for
> maintainers the use of the tool itself shouldn't be a problem.
>
> I followed the existing practice for the cfns.gperf file and its use so,
> if the handling of that file works, so should the handling of the new file,
> std-name-hint.gperf.
>
> Please let me know if this is acceptable.  I built a compiler with this
> code and tested the hinting.
>
> contrib/ChangeLog
> * gcc_update (files_and_dependencies): Add gcc/cp/std-name-hint.h
> depend on gcc/cp/std-name-hint.gperf.
>
> gcc/cp/ChangeLog
> * Make-lang.in: Add rule to build std-name-hint.h.
> * name-lookup.cc (struct std_name_hint): Remove definition.
> Instead...
> Include "std-name-hint.h".
> (get_std_name_hint): Remove hints array and lookup code.  Instead
> call
> std_name_hint_lookup::find.
> * std-name-hint.gperf: New file.
> * std-name-hint.h: New file.
>

Re: libsanitizer: merge from upstream

[Martin Liška]

On 5/4/22 10:59, Martin Liška wrote:
> Hello.
> 
> I'm going to do merge from upstream.
> 
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests. I've 
> also tested
> on ppc64le-linux-gnu and verified the ABI.
> 
> The only real change is a small change in
> gcc/testsuite/c-c++-common/asan/alloca_loop_unpoisoning.c
> where we need --param=asan-use-after-return=0.
> 
> I'm going to push the patches.
> 
> Thanks,
> Martin

Hi.

I've just done one more merge from upstream.
Upstream revision: 84a71d5259c2682403cdbd8710592410a2f128ab.

Cheers,
Martin

Re: [PATCH][committed]middle-end intialize regnum in store_bit_field_1

[Richard Biener via Gcc-patches]

On Tue, 30 Aug 2022, Richard Sandiford wrote:

> Richard Biener via Gcc-patches  writes:
> > On Tue, 30 Aug 2022, Tamar Christina wrote:
> >
> >> Hi All,
> >> 
> >> This initializes regnum to 0 for when undefined_p.
> >> 0 is the right default as it's supposed to get the lowpart
> >> when undefined.
> >> 
> >> Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
> >> 
> >> Ok for master?
> >
> > OK.
> 
> I'm not sure this is the right fix.  We were still supposed to use the
> correct byte offset in the undefined case.
> 
> Is the attached OK?  Tested on aarch64-linux-gnu.

OK.

Thanks,
Richard.

> Thanks,
> Richard
> 
> --
> 
> store_bit_field_1 tries to convert a field assignment into a subreg
> assignment.  Normally it must check that the field occupies a full
> word (or more specifically, a full REGMODE_NATURAL_SIZE chunk),
> so that writing to the subreg doesn't clobber any other fields.
> But it can skip that check if the structure is known to be in
> an undefined state.
> 
> The idea was that, in the undefined case, we could rely on
> simplify_gen_subreg to do the check for a valid subreg, rather
> than having to repeat the required endianness logic in the caller.
> 
> Before the addition of the undefined case, the code could use
> regnum * regsize to get the byte offset, where regnum came from
> checking that the start was word-aligned.  In the undefined case
> we need to calculate the byte offset explicitly.
> 
> gcc/
>   * expmed.cc (store_bit_field_1): Fix byte offset calculation
>   for undefined structures.
> ---
>  gcc/expmed.cc | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/gcc/expmed.cc b/gcc/expmed.cc
> index 8d7418be418..6c02c3bb850 100644
> --- a/gcc/expmed.cc
> +++ b/gcc/expmed.cc
> @@ -794,7 +794,7 @@ store_bit_field_1 (rtx str_rtx, poly_uint64 bitsize, 
> poly_uint64 bitnum,
>words or to cope with mode punning between equal-sized modes.
>In the latter case, use subreg on the rhs side, not lhs.  */
>rtx sub;
> -  HOST_WIDE_INT regnum;
> +  poly_uint64 bytenum;
>poly_uint64 regsize = REGMODE_NATURAL_SIZE (GET_MODE (op0));
>if (known_eq (bitnum, 0U)
> && known_eq (bitsize, GET_MODE_BITSIZE (GET_MODE (op0
> @@ -808,13 +808,13 @@ store_bit_field_1 (rtx str_rtx, poly_uint64 bitsize, 
> poly_uint64 bitnum,
> return true;
>   }
>   }
> -  else if (((constant_multiple_p (bitnum, regsize * BITS_PER_UNIT, 
> )
> -  && multiple_p (bitsize, regsize * BITS_PER_UNIT))
> - || undefined_p)
> +  else if (multiple_p (bitnum, BITS_PER_UNIT, )
> +&& (undefined_p
> +|| (multiple_p (bitnum, regsize * BITS_PER_UNIT)
> +&& multiple_p (bitsize, regsize * BITS_PER_UNIT)))
>  && known_ge (GET_MODE_BITSIZE (GET_MODE (op0)), bitsize))
>   {
> -   sub = simplify_gen_subreg (fieldmode, op0, GET_MODE (op0),
> -  regnum * regsize);
> +   sub = simplify_gen_subreg (fieldmode, op0, GET_MODE (op0), bytenum);
> if (sub)
>   {
> if (reverse)
> 

-- 
Richard Biener 
SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg,
Germany; GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman;
HRB 36809 (AG Nuernberg)

[PATCH] Remove GENERIC expr building from predicate analysis, improve dumps

[Richard Biener via Gcc-patches]

The following removes duplicate dumping and makes the predicate
dumping more readable.  That makes the GENERIC predicate build
routines unused which is also nice.

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

* gimple-predicate-analysis.cc (dump_pred_chain): Fix
parentizing and AND prepending.
(predicate::dump): Do not dump the GENERIC expanded
predicate, properly parentize and prepend ORs to the
piecewise predicate dump.
(build_pred_expr): Remove.
---
 gcc/gimple-predicate-analysis.cc | 77 +---
 1 file changed, 10 insertions(+), 67 deletions(-)

diff --git a/gcc/gimple-predicate-analysis.cc b/gcc/gimple-predicate-analysis.cc
index dcecbb5a581..ffdd8a15fe7 100644
--- a/gcc/gimple-predicate-analysis.cc
+++ b/gcc/gimple-predicate-analysis.cc
@@ -169,16 +169,14 @@ static void
 dump_pred_chain (const pred_chain )
 {
   unsigned np = chain.length ();
-  if (np > 1)
-fprintf (dump_file, "AND (");
-
   for (unsigned j = 0; j < np; j++)
 {
+  if (j > 0)
+   fprintf (dump_file, " AND (");
+  else
+   fputc ('(', dump_file);
   dump_pred_info (chain[j]);
-  if (j < np - 1)
-   fprintf (dump_file, ", ");
-  else if (j > 0)
-   fputc (')', dump_file);
+  fputc (')', dump_file);
 }
 }
 
@@ -579,51 +577,6 @@ uninit_analysis::collect_phi_def_edges (gphi *phi, 
basic_block cd_root,
 }
 }
 
-/* Return an expression corresponding to the predicate PRED.  */
-
-static tree
-build_pred_expr (const pred_info )
-{
-  tree_code cond_code = pred.cond_code;
-  tree lhs = pred.pred_lhs;
-  tree rhs = pred.pred_rhs;
-
-  if (pred.invert)
-cond_code = invert_tree_comparison (cond_code, false);
-
-  return build2 (cond_code, TREE_TYPE (lhs), lhs, rhs);
-}
-
-/* Return an expression corresponding to PREDS.  */
-
-static tree
-build_pred_expr (const pred_chain_union , bool invert = false)
-{
-  tree_code code = invert ? TRUTH_AND_EXPR : TRUTH_OR_EXPR;
-  tree_code subcode = invert ? TRUTH_OR_EXPR : TRUTH_AND_EXPR;
-
-  tree expr = NULL_TREE;
-  for (unsigned i = 0; i != preds.length (); ++i)
-{
-  tree subexpr = NULL_TREE;
-  for (unsigned j = 0; j != preds[i].length (); ++j)
-   {
- const pred_info  = preds[i][j];
- tree cond = build_pred_expr (pi);
-if (invert)
-  cond = invert_truthvalue (cond);
- subexpr = subexpr ? build2 (subcode, boolean_type_node,
- subexpr, cond) : cond;
-   }
-  if (expr)
-   expr = build2 (code, boolean_type_node, expr, subexpr);
-  else
-   expr = subexpr;
-}
-
-  return expr;
-}
-
 /* Return a bitset of all PHI arguments or zero if there are too many.  */
 
 unsigned
@@ -1907,24 +1860,14 @@ predicate::dump (gimple *stmt, const char *msg) const
   return;
 }
 
-  {
-tree expr = build_pred_expr (m_preds);
-char *str = print_generic_expr_to_str (expr);
-fprintf (dump_file, "\t%s (expanded)\n", str);
-free (str);
-  }
-
-  if (np > 1)
-fprintf (dump_file, "\tOR (");
-  else
-fputc ('\t', dump_file);
   for (unsigned i = 0; i < np; i++)
 {
+  if (i > 0)
+   fprintf (dump_file, "\tOR (");
+  else
+   fprintf (dump_file, "\t(");
   dump_pred_chain (m_preds[i]);
-  if (i < np - 1)
-   fprintf (dump_file, ", ");
-  else if (i > 0)
-   fputc (')', dump_file);
+  fputc (')', dump_file);
 }
   fputc ('\n', dump_file);
 }
-- 
2.35.3

Re: [PATCH][committed]middle-end intialize regnum in store_bit_field_1

[Richard Sandiford via Gcc-patches]

Richard Biener via Gcc-patches  writes:
> On Tue, 30 Aug 2022, Tamar Christina wrote:
>
>> Hi All,
>> 
>> This initializes regnum to 0 for when undefined_p.
>> 0 is the right default as it's supposed to get the lowpart
>> when undefined.
>> 
>> Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
>> 
>> Ok for master?
>
> OK.

I'm not sure this is the right fix.  We were still supposed to use the
correct byte offset in the undefined case.

Is the attached OK?  Tested on aarch64-linux-gnu.

Thanks,
Richard

--

store_bit_field_1 tries to convert a field assignment into a subreg
assignment.  Normally it must check that the field occupies a full
word (or more specifically, a full REGMODE_NATURAL_SIZE chunk),
so that writing to the subreg doesn't clobber any other fields.
But it can skip that check if the structure is known to be in
an undefined state.

The idea was that, in the undefined case, we could rely on
simplify_gen_subreg to do the check for a valid subreg, rather
than having to repeat the required endianness logic in the caller.

Before the addition of the undefined case, the code could use
regnum * regsize to get the byte offset, where regnum came from
checking that the start was word-aligned.  In the undefined case
we need to calculate the byte offset explicitly.

gcc/
* expmed.cc (store_bit_field_1): Fix byte offset calculation
for undefined structures.
---
 gcc/expmed.cc | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/gcc/expmed.cc b/gcc/expmed.cc
index 8d7418be418..6c02c3bb850 100644
--- a/gcc/expmed.cc
+++ b/gcc/expmed.cc
@@ -794,7 +794,7 @@ store_bit_field_1 (rtx str_rtx, poly_uint64 bitsize, 
poly_uint64 bitnum,
 words or to cope with mode punning between equal-sized modes.
 In the latter case, use subreg on the rhs side, not lhs.  */
   rtx sub;
-  HOST_WIDE_INT regnum;
+  poly_uint64 bytenum;
   poly_uint64 regsize = REGMODE_NATURAL_SIZE (GET_MODE (op0));
   if (known_eq (bitnum, 0U)
  && known_eq (bitsize, GET_MODE_BITSIZE (GET_MODE (op0
@@ -808,13 +808,13 @@ store_bit_field_1 (rtx str_rtx, poly_uint64 bitsize, 
poly_uint64 bitnum,
  return true;
}
}
-  else if (((constant_multiple_p (bitnum, regsize * BITS_PER_UNIT, )
-&& multiple_p (bitsize, regsize * BITS_PER_UNIT))
-   || undefined_p)
+  else if (multiple_p (bitnum, BITS_PER_UNIT, )
+  && (undefined_p
+  || (multiple_p (bitnum, regsize * BITS_PER_UNIT)
+  && multiple_p (bitsize, regsize * BITS_PER_UNIT)))
   && known_ge (GET_MODE_BITSIZE (GET_MODE (op0)), bitsize))
{
- sub = simplify_gen_subreg (fieldmode, op0, GET_MODE (op0),
-regnum * regsize);
+ sub = simplify_gen_subreg (fieldmode, op0, GET_MODE (op0), bytenum);
  if (sub)
{
  if (reverse)
-- 
2.25.1

[PATCH]rs6000: remove unused splitter on const_scalar_int_operand

[Jiufu Guo via Gcc-patches]

Hi,

There are two splitters, both are calling rs6000_emit_set_const to emit
instructions for constant building.
One splitter checks `const_int_operand`, this splitter is always used.
Another spitter checks `const_scalar_int_operand`, this one is never
used now.

Checking the history, that splitter is introduced around 1999 for
HOST_BITS_PER_WIDE_INT=32, as below:

(define_split
  [(set (match_operand:DI 0 "gpc_reg_operand" "")
(match_operand:DI 1 "const_double_operand" ""))]
  "HOST_BITS_PER_WIDE_INT == 32 && TARGET_POWERPC64
   && num_insns_constant (operands[1], DImode) > 1"

And `HOST_BITS_PER_WIDE_INT == 32` is eliminated later, since it is
`const_double_operand` can cover it.
When wide_int is introduced, `const_double_operand` is replaced by
`const_scalar_int_operand`.

Now, HOST_BITS_PER_WIDE_INT is forced to 64, this splitter is safe
to remove.

Bootstrap and regtest pass on ppc64 and ppc64le.
Is this ok for trunk?

BR,
Jeff

gcc/ChangeLog:

* config/rs6000/rs6000.md (const_scalar_int splitter): Remove.

---
 gcc/config/rs6000/rs6000.md | 13 -
 1 file changed, 13 deletions(-)

diff --git a/gcc/config/rs6000/rs6000.md b/gcc/config/rs6000/rs6000.md
index e9e5cd1e54d..2a177936689 100644
--- a/gcc/config/rs6000/rs6000.md
+++ b/gcc/config/rs6000/rs6000.md
@@ -9717,19 +9717,6 @@ (define_split
 FAIL;
 })
 
-(define_split
-  [(set (match_operand:DI 0 "int_reg_operand_not_pseudo")
-   (match_operand:DI 1 "const_scalar_int_operand"))]
-  "TARGET_POWERPC64 && num_insns_constant (operands[1], DImode) > 1"
-  [(set (match_dup 0) (match_dup 2))
-   (set (match_dup 0) (plus:DI (match_dup 0) (match_dup 3)))]
-{
-  if (rs6000_emit_set_const (operands[0], operands[1]))
-DONE;
-  else
-FAIL;
-})
-
 (define_split
   [(set (match_operand:DI 0 "altivec_register_operand")
(match_operand:DI 1 "s5bit_cint_operand"))]
-- 
2.17.1

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

[Aldy Hernandez via Gcc-patches]

OK, I'm good to go.

As the patch was getting rather large, I have split it into two parts.
The first is the core endpoints support to frange along with removal
of the +-INF markers (since they are no longer needed).  The second
part is the FP relational operators.  Splitting it up should help in
reviewing/improving the code for readers.  Also, it always helps
regression hunting to have smaller pieces ;-).

Retested on x86-64 Linux.

Pushed.




On Mon, Aug 29, 2022 at 4:42 PM Toon Moene  wrote:
>
> On 8/29/22 16:36, Aldy Hernandez wrote:
>
> > On Mon, Aug 29, 2022 at 4:30 PM Toon Moene  wrote:
> >>
> >> On 8/29/22 16:15, Aldy Hernandez wrote:
> >>
> >>> But even with -ffinite-math-only, is there any benefit to propagating
> >>> a known NAN?  For example:
> >>
> >> The original intent (in 2002) for the option -ffinite-math-only was for
> >> the optimizers to ignore all the various exceptions to common
> >> optimizations because they might not work correctly when presented with
> >> a NaN or an Inf.
> >>
> >> I do not know what the effect for floating point range information would
> >> be - offhand.
> >>
> >> But in the *spirit* of this option would be to ignore that the range
> >> [5.0, 5.0] would "also" contain NaN, for instance.
> >
> > Hmm, this is somewhat similar to what Jakub suggested.  Perhaps we
> > could categorically set !NAN for !HONOR_NANS at frange construction
> > time?
> >
> > For reference:
> > bool
> > HONOR_NANS (machine_mode m)
> > {
> >return MODE_HAS_NANS (m) && !flag_finite_math_only;
> > }
> >
> > Thanks.
> > Aldy
> >
>
> Yep, I think that would do it.
>
> Thanks,
>
> --
> Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
> Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
>
From 7ded1c025a44d9e3e141bd1c7694aef3931acb69 Mon Sep 17 00:00:00 2001
From: Aldy Hernandez 
Date: Tue, 30 Aug 2022 08:23:33 +0200
Subject: [PATCH] Add support for floating point endpoints to frange.

The current implementation of frange is just a type with some bits to
represent NAN and INF.  We can do better and represent endpoints to
ultimately solve longstanding PRs such as PR24021.  This patch adds
these endpoints.  In follow-up patches I will add support for a bare
bones PLUS_EXPR range-op-float entry to solve the PR.

I have chosen to use REAL_VALUE_TYPEs for the endpoints, since that's
what we use underneath the trees.  This will be somewhat analogous to
our eventual use of wide-ints in the irange.  No sense going through
added levels of indirection if we can avoid it.  That, plus real.*
already has a nice API for dealing with floats.

With this patch, ranges will be closed float point intervals, which
make the implementation simpler, since we don't have to keep track of
open/closed intervals.  This is conservative enough for use in the
ranger world, as we'd rather err on the side of more elements in a
range, than less.

For example, even though we cannot precisely represent the open
interval (3.0, 5.0) with this approach, it is perfectably reasonable
to represent it as [3.0, 5.0] since the closed interval is a super set
of the open one.  In the VRP/ranger world, it is always better to
err on the side of more information in a range, than not.  After all,
when we don't know anything about a range, we just use VARYING which
is a fancy term for a range spanning the entire domain.

Since REAL_VALUE_TYPEs have properly defined infinity and NAN
semantics, all the math can be made to work:

[-INF, 3.0] !NAN=> Numbers <= 3.0 (NAN cannot happen)
[3.0, 3.0]  		=> 3.0 or NAN.
[3.0, +INF] => Numbers >= 3.0 (NAN is possible)
[-INF, +INF]=> VARYING (NAN is possible)
[-INF, +INF] !NAN   => Entire domain.  NAN cannot happen.

Also, since REAL_VALUE_TYPEs can represent the minimum and maximum
representable values of a TYPE_MODE, we can disambiguate between them
and negative and positive infinity (see get_max_float in real.cc).

This also makes the math all work.  For example, suppose we know
nothing about x and y (VARYING).  On the TRUE side of x > y, we can
deduce that:

(a) x cannot be NAN
(b) y cannot be NAN
(c) y cannot be +INF.

(c) means that we can drop the upper bound of "y" from +INF to the
maximum representable value for its type.

Having endpoints with different representation for infinity and the
maximum representable values, means we can drop the +-INF properties
we currently have in the frange.

gcc/ChangeLog:

	* range-op-float.cc (frange_set_nan): New.
	(frange_drop_inf): New.
	(frange_drop_ninf): New.
	(foperator_equal::op1_range): Adjust for endpoints.
	(foperator_lt::op1_range): Same.
	(foperator_lt::op2_range): Same.
	(foperator_gt::op1_range): Same.
	(foperator_gt::op2_range): Same.
	(foperator_unordered::op1_range): Same.
	* value-query.cc (range_query::get_tree_range): Same.
	* value-range-pretty-print.cc (vrange_printer::visit): Same.
	* value-range-storage.cc (frange_storage_slot::get_frange): Same.
	* value-range.cc 

[PATCH][pushed] s390: fix build on 32-bit hosts

[Martin Liška]

Pushed as obvious.

Fixes build on i686:

gcc/config/s390/s390.cc: In function 'bool s390_rtx_costs(rtx, machine_mode, 
int, int, int*, bool)':
gcc/config/s390/s390.cc:3728:63: error: cannot convert 'long int*' to 'long 
long int*'

gcc/ChangeLog:

* config/s390/s390.cc (s390_rtx_costs): Use proper type as
  argument.
---
 gcc/config/s390/s390.cc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/config/s390/s390.cc b/gcc/config/s390/s390.cc
index 076c97a8b22..3ae586c60eb 100644
--- a/gcc/config/s390/s390.cc
+++ b/gcc/config/s390/s390.cc
@@ -3724,7 +3724,7 @@ s390_rtx_costs (rtx x, machine_mode mode, int outer_code,
case MEM: {
  rtx address = XEXP (dest, 0);
  rtx tmp;
- long tmp2;
+ HOST_WIDE_INT tmp2;
  if (s390_loadrelative_operand_p (address, , ))
*total = COSTS_N_INSNS (1);
  else
-- 
2.37.2

[PATCH] Use reachability analysis to improve uninit diagnostic

[Richard Biener via Gcc-patches]

This patch does what the comment in uninit diagnostic suggests.
When the value-numbering run done without optimizing figures there's
a fallthru path, consider blocks on it as always executed.

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

* tree-ssa-uninit.cc (warn_uninitialized_vars): Pre-compute
the set of fallthru reachable blocks from function entry
and use that to determine wlims.always_executed.
---
 gcc/tree-ssa-uninit.cc | 47 ++
 1 file changed, 38 insertions(+), 9 deletions(-)

diff --git a/gcc/tree-ssa-uninit.cc b/gcc/tree-ssa-uninit.cc
index 0bd567f237c..c25fbe6381e 100644
--- a/gcc/tree-ssa-uninit.cc
+++ b/gcc/tree-ssa-uninit.cc
@@ -988,10 +988,43 @@ warn_uninitialized_vars (bool wmaybe_uninit)
   wlimits wlims = { };
   wlims.wmaybe_uninit = wmaybe_uninit;
 
-  gimple_stmt_iterator gsi;
-  basic_block bb;
+  auto_bb_flag ft_reachable (cfun);
+
+  /* Mark blocks that are always executed when we ignore provably
+ not executed edges.  */
+  basic_block bb = single_succ (ENTRY_BLOCK_PTR_FOR_FN (cfun));
+  while (!(bb->flags & ft_reachable))
+{
+  bb->flags |= ft_reachable;
+  /* Find a single executable edge.  */
+  edge_iterator ei;
+  edge e, ee = NULL;
+  FOR_EACH_EDGE (e, ei, bb->succs)
+   if (e->flags & EDGE_EXECUTABLE)
+ {
+   if (!ee)
+ ee = e;
+   else
+ {
+   ee = NULL;
+   break;
+ }
+ }
+  if (ee)
+   bb = ee->dest;
+  else
+   {
+ bb = get_immediate_dominator (CDI_POST_DOMINATORS, bb);
+ if (!bb || bb->index == EXIT_BLOCK)
+   break;
+   }
+}
+
   FOR_EACH_BB_FN (bb, cfun)
 {
+  wlims.always_executed = (bb->flags & ft_reachable);
+  bb->flags &= ~ft_reachable;
+
   edge_iterator ei;
   edge e;
   FOR_EACH_EDGE (e, ei, bb->preds)
@@ -1002,14 +1035,10 @@ warn_uninitialized_vars (bool wmaybe_uninit)
   if (!e)
continue;
 
-  basic_block succ = single_succ (ENTRY_BLOCK_PTR_FOR_FN (cfun));
-  /* ???  This could be improved when we use a greedy walk and have
-some edges marked as not executable.  */
-  wlims.always_executed = dominated_by_p (CDI_POST_DOMINATORS, succ, bb);
-
   if (wlims.always_executed)
warn_uninit_phi_uses (bb);
 
+  gimple_stmt_iterator gsi;
   for (gsi = gsi_start_bb (bb); !gsi_end_p (gsi); gsi_next ())
{
  gimple *stmt = gsi_stmt (gsi);
@@ -1030,7 +1059,7 @@ warn_uninitialized_vars (bool wmaybe_uninit)
  FOR_EACH_SSA_USE_OPERAND (use_p, stmt, op_iter, SSA_OP_USE)
{
  /* BIT_INSERT_EXPR first operand should not be considered
-a use for the purpose of uninit warnings.  */
+a use for the purpose of uninit warnings.  */
  if (gassign *ass = dyn_cast  (stmt))
{
  if (gimple_assign_rhs_code (ass) == BIT_INSERT_EXPR
@@ -1041,7 +1070,7 @@ warn_uninitialized_vars (bool wmaybe_uninit)
  if (wlims.always_executed)
warn_uninit (OPT_Wuninitialized, use,
 SSA_NAME_VAR (use), stmt);
- else if (wmaybe_uninit)
+ else if (wlims.wmaybe_uninit)
warn_uninit (OPT_Wmaybe_uninitialized, use,
 SSA_NAME_VAR (use), stmt);
}
-- 
2.35.3

[PATCH] tree-optimization/63660 - testcase for fixed PR

[Richard Biener via Gcc-patches]

This adds a testcase for the PR which was fixed with r13-2155-gbaa3ffb19c54fa

Pushed.

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

diff --git a/gcc/testsuite/gcc.dg/uninit-pr63660.c 
b/gcc/testsuite/gcc.dg/uninit-pr63660.c
new file mode 100644
index 000..eab7c7401b9
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/uninit-pr63660.c
@@ -0,0 +1,58 @@
+/* { dg-do compile } */
+/* { dg-options "-O -Wuninitialized" } */
+
+typedef struct
+{
+ int a;
+ int b;
+ int c;
+ int d;
+ int e;
+ int f;
+ int g;
+ int h;
+ int i;
+ int j;
+} X;
+
+X *XX(int);
+
+int G();
+
+static void F()
+{
+ X *x;
+ int m, n;
+ int xa, xb, xc, xd, xe, xf, xg, xh, xi, xj;
+
+ m = G();
+ n = G();
+ if ( n & 1 ) xa = G();
+ if ( n & 2 ) xb = G();
+ if ( n & 4 ) xc = G();
+ if ( n & 32 ) xd = G();
+ if ( n & 16 ) xe = G();
+ if ( n & 64 ) xf = G();
+ if ( n & 256 ) xg = G();
+ if ( n & 512 ) xh = G();
+ if ( n & 1024 ) xi = G();
+ if ( n & 2048 ) xj = G();
+
+ if ( m >= 64 ) return;
+ x = XX(m);
+ if ( n & 1 ) x->a = xa;
+ if ( n & 2 ) x->b = xb;
+ if ( n & 4 ) x->c = xc;
+ if ( n & 32 ) x->d = xd;
+ if ( n & 16 ) x->e = xe;
+ if ( n & 64 ) x->f = xf;
+ if ( n & 256 ) x->g = xg;
+ if ( n & 512 ) x->h = xh;
+ if ( n & 1024 ) x->i = xi;
+ if ( n & 2048 ) x->j = xj; /* { dg-bogus "uninitialized" } */
+}
+
+void H()
+{
+ F();
+}
-- 
2.35.3

Re: [PATCH 1/2] vec: Add array_slice constructors from non-const and gc vectors

[Richard Sandiford via Gcc-patches]

Richard Biener  writes:
> On Mon, 29 Aug 2022, Martin Jambor wrote:
>
>> Hi,
>> 
>> On Mon, Aug 29 2022, Richard Biener wrote:
>> > On Mon, 29 Aug 2022, Martin Jambor wrote:
>> >
>> >> Hi again,
>> >> 
>> >> On Mon, Aug 29 2022, Richard Biener wrote:
>> >> > On Fri, 26 Aug 2022, Martin Jambor wrote:
>> >> >
>> >> >> Hi,
>> >> >> 
>> >> >> On Fri, Aug 26 2022, Richard Biener wrote:
>> >> >> >> Am 26.08.2022 um 18:39 schrieb Martin Jambor :
>> >> >> >>
>> >> >> >> Hi,
>> >> >> >>
>> >> >> >> This patch adds constructors of array_slice that are required to
>> >> >> >> create them from non-const (heap or auto) vectors or from GC 
>> >> >> >> vectors.
>> >> >> >>
>> >> >> >> The use of non-const array_slices is somewhat limited, as creating 
>> >> >> >> one
>> >> >> >> from const vec still leads to array_slice> >> >> >> some_type>,
>> >> >> >> so I eventually also only resorted to having read-only array_slices.
>> >> >> >> But I do need the constructor from the gc vector.
>> >> >> >>
>> >> >> >> Bootstrapped and tested along code that actually uses it on
>> >> >> >> x86_64-linux.  OK for trunk?
>> >> >> >>
>> >> >> >> Thanks,
>> >> >> >>
>> >> >> >> Martin
>> >> >> >>
>> >> >> >>
>> >> >> >> gcc/ChangeLog:
>> >> >> >>
>> >> >> >> 2022-08-08  Martin Jambor  
>> >> >> >>
>> >> >> >>* vec.h (array_slice): Add constructors for non-const reference 
>> >> >> >> to
>> >> >> >>heap vector and pointers to heap vectors.
>> >> >> >> ---
>> >> >> >> gcc/vec.h | 12 
>> >> >> >> 1 file changed, 12 insertions(+)
>> >> >> >>
>> >> >> >> diff --git a/gcc/vec.h b/gcc/vec.h
>> >> >> >> index eed075addc9..b0477e1044c 100644
>> >> >> >> --- a/gcc/vec.h
>> >> >> >> +++ b/gcc/vec.h
>> >> >> >> @@ -2264,6 +2264,18 @@ public:
>> >> >> >>   array_slice (const vec )
>> >> >> >> : m_base (v.address ()), m_size (v.length ()) {}
>> >> >> >>
>> >> >> >> +  template
>> >> >> >> +  array_slice (vec )
>> >> >> >> +: m_base (v.address ()), m_size (v.length ()) {}
>> >> >> >> +
>> >> >> >> +  template
>> >> >> >> +  array_slice (const vec *v)
>> >> >> >> +: m_base (v ? v->address () : nullptr), m_size (v ? v->length 
>> >> >> >> () : 0) {}
>> >> >> >> +
>> >> >> >> +  template
>> >> >> >> +  array_slice (vec *v)
>> >> >> >> +: m_base (v ? v->address () : nullptr), m_size (v ? v->length 
>> >> >> >> () : 0) {}
>> >> >> >> +
>> >> >> >
>> >> >> > I don?t quite understand why the generic ctor doesn?t cover the GC 
>> >> >> > case.  It looks more like reference vs pointer?
>> >> >> >
>> >> >> 
>> >> >> If you think that this should work:
>> >> >> 
>> >> >>   vec *heh = cfun->local_decls;
>> >> >>   array_slice arr_slice (*heh);
>> >> >> 
>> >> >> then it does not:
>> >> >> 
>> >> >>   /home/mjambor/gcc/mine/src/gcc/ipa-cp.cc:6693:36: error: no matching 
>> >> >> function for call to 
>> >> >> ?array_slice::array_slice(vec&)?
>> >> >>6693 |   array_slice arr_slice (*heh);
>> >> >> |^
>> >> >>   In file included from 
>> >> >> /home/mjambor/gcc/mine/src/gcc/hash-table.h:248,
>> >> >>from /home/mjambor/gcc/mine/src/gcc/coretypes.h:486,
>> >> >>from /home/mjambor/gcc/mine/src/gcc/ipa-cp.cc:105:
>> >> >>   /home/mjambor/gcc/mine/src/gcc/vec.h:2264:3: note: candidate: 
>> >> >> ?template array_slice::array_slice(const 
>> >> >> vec&) [with T = tree_node*]?
>> >> >>2264 |   array_slice (const vec )
>> >> >> |   ^~~
>> >> >>   /home/mjambor/gcc/mine/src/gcc/vec.h:2264:3: note:   template 
>> >> >> argument deduction/substitution failed:
>> >> >>   /home/mjambor/gcc/mine/src/gcc/ipa-cp.cc:6693:36: note:   mismatched 
>> >> >> types ?va_heap? and ?va_gc?
>> >> >>6693 |   array_slice arr_slice (*heh);
>> >> >> |^
>> >> >> 
>> >> >>   [... I trimmed notes about all other candidates...]
>> >> >> 
>> >> >> Or did you mean something else?
>> >> >
>> >> > Hmm, so what if you change
>> >> >
>> >> >   template
>> >> >   array_slice (const vec )
>> >> > : m_base (v.address ()), m_size (v.length ()) {}
>> >> >
>> >> > to
>> >> >
>> >> >   template
>> >> >   array_slice (const vec )
>> >> > : m_base (v.address ()), m_size (v.length ()) {}
>> >> >
>> >> > instead?  Thus allow any allocation / placement template arg?
>> >> >
>> >> 
>> >> So being fully awake helps, the issue was of course in how I tested the
>> >> code, the above works fine and I can adapt my code to use that.
>> >> 
>> >> However, is it really preferable?
>> >> 
>> >> We often use NULL as to mean zero-length vector, which my code handled
>> >> gracefully:
>> >> 
>> >> +  template
>> >> +  array_slice (const vec *v)
>> >> +: m_base (v ? v->address () : nullptr), m_size (v ? v->length () : 
>> >> 0) {}
>> >> 
>> >> whereas using the generic method will mean that users constructing the
>> >> vector will have to special case it - and I bet most will end up using
>> >> the above sequence and the constructor 

Re: [PATCH] Make uninit PHI processing more consistent

[Richard Biener via Gcc-patches]

On Mon, 29 Aug 2022, Richard Biener wrote:

> On Mon, 29 Aug 2022, Richard Biener wrote:
> 
> [...]
> 
> > The patch correctly diagnoses an uninitalized use of 'regnum'
> > in store_bit_field_1 but also diagnoses an uninitialized use of
> > best_match::m_best_candidate_len which I've chosen to silence
> > without analyzing it in detail (I'm doing that right now).
> 
> To followup myself this is
> 
>   cpp_hashnode *best_macro = bmm.get_best_meaningful_candidate ();
>   /* If a macro is the closest so far to NAME, use it, creating an 
>  identifier tree node for it.  */
>   if (best_macro)
> {
>   const char *id = (const char *)best_macro->ident.str;
>   tree macro_as_identifier
> = get_identifier_with_length (id, best_macro->ident.len);
>   bm.set_best_so_far (macro_as_identifier,
>   bmm.get_best_distance (),
>   bmm.get_best_candidate_length ());
> 
> and
> 
>   edit_distance_t get_cutoff (size_t candidate_len) const
>   {
> return ::get_edit_distance_cutoff (m_goal_len, candidate_len);
>   }
>
>   candidate_t get_best_meaningful_candidate () const
>   {
> /* If the edit distance is too high, the suggestion is likely to be
>meaningless.  */
> if (m_best_candidate)
>   {
> edit_distance_t cutoff = get_cutoff (m_best_candidate_len);
> if (m_best_distance > cutoff)
>   return NULL;
> }
> 
> where the connection between m_best_candidate_len being initialized
> when m_best_candidate is not NULL is not visible.  I think it's
> OK to initialize the member together with m_best_candidate here.
> 
> I'm reducing a testcase, but not sure where that will go.

I've done that an the testcase shows the patch exactly working as
intended, uncovering this previous false negative.  False negative
as far as GCC can see which doesn't get to see the connection of
m_best_candidate != NULL meaning m_best_candidate_len being
initialized.

I've pushed the following with an added testcase and omitting the
meanwhile fixed expmed.cc hunk.

Richard.

>From da1558c957799b4a46ddc2e7496150bf7a9926b5 Mon Sep 17 00:00:00 2001
From: Richard Biener 
Date: Mon, 29 Aug 2022 12:20:10 +0200
Subject: [PATCH] Make uninit PHI processing more consistent
To: gcc-patches@gcc.gnu.org

Currently the main working of the maybe-uninit pass is to scan over
all PHIs with possibly undefined arguments, diagnosing whether there's
a direct not guarded use.  For not guarded uses in PHIs those are queued for
later processing and to make the uninit analysis PHI def handling work,
mark the PHI def as possibly uninitialized.  But this happens only
for those PHI uses that happen to be seen before a direct not guarded
use and whether all arguments of a PHI node which are defined by a PHI
are properly marked as maybe uninitialized depends on the processing
order.

The following changes the uninit pass to perform an RPO walk over
the function, ensuring that PHI argument defs are visited before
the PHI node (besides backedge uses which we ignore already),
getting rid of the worklist.  It also makes sure to process all
PHI uses, but recording those that are properly guarded so they
are not treated as maybe undefined when processing the PHI use
later.

Overall this should make behavior more consistent, avoid some
false negative because of the previous early out and order issue,
and avoid some false positive because of the missed recording
of guarded PHI uses.

The patch correctly diagnoses an uninitalized use of 'regnum'
in store_bit_field_1 but also diagnoses an uninitialized use of
best_match::m_best_candidate_len which I've chosen to silence
without analyzing it in detail.

* gimple-predicate-analysis.h (uninit_analysis::operator()):
Remove.
* gimple-predicate-analysis.cc
(uninit_analysis::collect_phi_def_edges): Use phi_arg_set,
simplify a bit.
* tree-ssa-uninit.cc (defined_args): New global.
(compute_uninit_opnds_pos): Mask with the recorded set
of guarded maybe-uninitialized uses.
(uninit_undef_val_t::operator()): Remove.
(find_uninit_use): Process all PHI uses, recording the
guarded ones and marking the PHI result as uninitialized
consistently.
(warn_uninitialized_phi): Adjust.
(execute_late_warn_uninitialized): Get rid of the PHI worklist
and instead walk the function in RPO order.

* expmed.cc (store_bit_field_1): Initialize regnum.
* spellcheck.h (best_match::m_best_candidate_len): Initialize.
---
 gcc/expmed.cc|   2 +-
 gcc/gimple-predicate-analysis.cc |  49 +-
 gcc/gimple-predicate-analysis.h  |   2 -
 gcc/spellcheck.h |   3 +-
 gcc/tree-ssa-uninit.cc   | 149 +--
 5 files changed, 83 insertions(+), 122 deletions(-)

diff --git a/gcc/expmed.cc b/gcc/expmed.cc
index 8d7418be418..cdc0adb3892 100644
--- 

Re: [PATCH] A == 0 ? A : -A same as -A (when A is 0.0)

[Richard Biener via Gcc-patches]

On Tue, Aug 30, 2022 at 9:07 AM Aldy Hernandez  wrote:
>
> On Tue, Aug 30, 2022 at 9:03 AM Richard Biener
>  wrote:
> >
> > On Mon, Aug 29, 2022 at 10:45 PM Aldy Hernandez via Gcc-patches
> >  wrote:
> > >
> > > The upcoming work for frange triggers a regression in
> > > gcc.dg/tree-ssa/phi-opt-24.c.
> > >
> > > For -O2 -fno-signed-zeros, we fail to transform the following into -A:
> > >
> > > float f0(float A)
> > > {
> > >   // A == 0? A : -Asame as -A
> > >   if (A == 0)  return A;
> > >   return -A;
> > > }
> > >
> > > This is because the abs/negative match.pd pattern here:
> > >
> > > /* abs/negative simplifications moved from fold_cond_expr_with_comparison,
> > >Need to handle (A - B) case as fold_cond_expr_with_comparison does.
> > >Need to handle UN* comparisons.
> > >...
> > >...
> > >
> > > Sees IL that has the 0.0 propagated.
> > >
> > > Instead of:
> > >
> > >[local count: 1073741824]:
> > >   if (A_2(D) == 0.0)
> > > goto ; [34.00%]
> > >   else
> > > goto ; [66.00%]
> > >
> > >[local count: 708669601]:
> > >   _3 = -A_2(D);
> > >
> > >[local count: 1073741824]:
> > >   # _1 = PHI 
> > >
> > > It now sees:
> > >
> > >[local count: 1073741824]:
> > >   # _1 = PHI <0.0(2), _3(3)>
> > >
> > > which it leaves untouched, causing the if conditional to survive.
> > >
> > > Adding a variant to the pattern that for real_zerop fixes the problem.
> > >
> > > I am a match.pd weenie, and am avoiding touching more patterns that
> > > may also benefit from handling real constants.  So please use simple
> > > words if what I'm doing isn't correct ;-).
> > >
> > > I did not include a testcase, as it's just phi-opt-24.c which will get
> > > triggered when I commit the frange with endpoints work.
> > >
> > > Tested on x86-64 & ppc64le Linux.
> > >
> > > OK?
> > >
> > > gcc/ChangeLog:
> > >
> > > * match.pd ((cmp @0 zerop) real_zerop (negate@1 @0)): Add variant
> > > for real zero.
> > > ---
> > >  gcc/match.pd | 4 
> > >  1 file changed, 4 insertions(+)
> > >
> > > diff --git a/gcc/match.pd b/gcc/match.pd
> > > index 1bb936fc401..5bdea300f94 100644
> > > --- a/gcc/match.pd
> > > +++ b/gcc/match.pd
> > > @@ -4803,6 +4803,10 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
> > > (cnd (cmp @0 zerop) @0 (negate@1 @0))
> > >  (if (!HONOR_SIGNED_ZEROS (type))
> > >   @1))
> > > +  (simplify
> > > +   (cnd (cmp @0 zerop) real_zerop (negate@1 @0))
> > > +(if (!HONOR_SIGNED_ZEROS (type))
> > > + @1))
> > >(simplify
> > > (cnd (cmp @0 zerop) integer_zerop (negate@1 @0))
> > >  (if (!HONOR_SIGNED_ZEROS (type))
> >
> > Looking at zerop:
> >
> > bool
> > zerop (const_tree expr)
> > {
> >   return (integer_zerop (expr)
> >   || real_zerop (expr)
> >   || fixed_zerop (expr));
> > }
> >
> > your patch is equivalent to changing the integer_zerop one to use zerop?
> > (well, with the exception of also covering fixed_zerop).
>
> Heh.  That was my first instinct, but I thought fixed_zerop didn't
> apply?  No clue...I'm happy to change it.

Well, it already applies when the constant is not propagated, so ...

> Thanks.
> Aldy
>
> >
> > OK if doing it that way.
> >
> > Thanks,
> > Richard.
> >
> > > --
> > > 2.37.1
> > >
> >
>

Re: [PATCH] A == 0 ? A : -A same as -A (when A is 0.0)

[Aldy Hernandez via Gcc-patches]

On Tue, Aug 30, 2022 at 9:03 AM Richard Biener
 wrote:
>
> On Mon, Aug 29, 2022 at 10:45 PM Aldy Hernandez via Gcc-patches
>  wrote:
> >
> > The upcoming work for frange triggers a regression in
> > gcc.dg/tree-ssa/phi-opt-24.c.
> >
> > For -O2 -fno-signed-zeros, we fail to transform the following into -A:
> >
> > float f0(float A)
> > {
> >   // A == 0? A : -Asame as -A
> >   if (A == 0)  return A;
> >   return -A;
> > }
> >
> > This is because the abs/negative match.pd pattern here:
> >
> > /* abs/negative simplifications moved from fold_cond_expr_with_comparison,
> >Need to handle (A - B) case as fold_cond_expr_with_comparison does.
> >Need to handle UN* comparisons.
> >...
> >...
> >
> > Sees IL that has the 0.0 propagated.
> >
> > Instead of:
> >
> >[local count: 1073741824]:
> >   if (A_2(D) == 0.0)
> > goto ; [34.00%]
> >   else
> > goto ; [66.00%]
> >
> >[local count: 708669601]:
> >   _3 = -A_2(D);
> >
> >[local count: 1073741824]:
> >   # _1 = PHI 
> >
> > It now sees:
> >
> >[local count: 1073741824]:
> >   # _1 = PHI <0.0(2), _3(3)>
> >
> > which it leaves untouched, causing the if conditional to survive.
> >
> > Adding a variant to the pattern that for real_zerop fixes the problem.
> >
> > I am a match.pd weenie, and am avoiding touching more patterns that
> > may also benefit from handling real constants.  So please use simple
> > words if what I'm doing isn't correct ;-).
> >
> > I did not include a testcase, as it's just phi-opt-24.c which will get
> > triggered when I commit the frange with endpoints work.
> >
> > Tested on x86-64 & ppc64le Linux.
> >
> > OK?
> >
> > gcc/ChangeLog:
> >
> > * match.pd ((cmp @0 zerop) real_zerop (negate@1 @0)): Add variant
> > for real zero.
> > ---
> >  gcc/match.pd | 4 
> >  1 file changed, 4 insertions(+)
> >
> > diff --git a/gcc/match.pd b/gcc/match.pd
> > index 1bb936fc401..5bdea300f94 100644
> > --- a/gcc/match.pd
> > +++ b/gcc/match.pd
> > @@ -4803,6 +4803,10 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
> > (cnd (cmp @0 zerop) @0 (negate@1 @0))
> >  (if (!HONOR_SIGNED_ZEROS (type))
> >   @1))
> > +  (simplify
> > +   (cnd (cmp @0 zerop) real_zerop (negate@1 @0))
> > +(if (!HONOR_SIGNED_ZEROS (type))
> > + @1))
> >(simplify
> > (cnd (cmp @0 zerop) integer_zerop (negate@1 @0))
> >  (if (!HONOR_SIGNED_ZEROS (type))
>
> Looking at zerop:
>
> bool
> zerop (const_tree expr)
> {
>   return (integer_zerop (expr)
>   || real_zerop (expr)
>   || fixed_zerop (expr));
> }
>
> your patch is equivalent to changing the integer_zerop one to use zerop?
> (well, with the exception of also covering fixed_zerop).

Heh.  That was my first instinct, but I thought fixed_zerop didn't
apply?  No clue...I'm happy to change it.

Thanks.
Aldy

>
> OK if doing it that way.
>
> Thanks,
> Richard.
>
> > --
> > 2.37.1
> >
>

Re: [PATCH] A == 0 ? A : -A same as -A (when A is 0.0)

[Richard Biener via Gcc-patches]

On Mon, Aug 29, 2022 at 10:45 PM Aldy Hernandez via Gcc-patches
 wrote:
>
> The upcoming work for frange triggers a regression in
> gcc.dg/tree-ssa/phi-opt-24.c.
>
> For -O2 -fno-signed-zeros, we fail to transform the following into -A:
>
> float f0(float A)
> {
>   // A == 0? A : -Asame as -A
>   if (A == 0)  return A;
>   return -A;
> }
>
> This is because the abs/negative match.pd pattern here:
>
> /* abs/negative simplifications moved from fold_cond_expr_with_comparison,
>Need to handle (A - B) case as fold_cond_expr_with_comparison does.
>Need to handle UN* comparisons.
>...
>...
>
> Sees IL that has the 0.0 propagated.
>
> Instead of:
>
>[local count: 1073741824]:
>   if (A_2(D) == 0.0)
> goto ; [34.00%]
>   else
> goto ; [66.00%]
>
>[local count: 708669601]:
>   _3 = -A_2(D);
>
>[local count: 1073741824]:
>   # _1 = PHI 
>
> It now sees:
>
>[local count: 1073741824]:
>   # _1 = PHI <0.0(2), _3(3)>
>
> which it leaves untouched, causing the if conditional to survive.
>
> Adding a variant to the pattern that for real_zerop fixes the problem.
>
> I am a match.pd weenie, and am avoiding touching more patterns that
> may also benefit from handling real constants.  So please use simple
> words if what I'm doing isn't correct ;-).
>
> I did not include a testcase, as it's just phi-opt-24.c which will get
> triggered when I commit the frange with endpoints work.
>
> Tested on x86-64 & ppc64le Linux.
>
> OK?
>
> gcc/ChangeLog:
>
> * match.pd ((cmp @0 zerop) real_zerop (negate@1 @0)): Add variant
> for real zero.
> ---
>  gcc/match.pd | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/gcc/match.pd b/gcc/match.pd
> index 1bb936fc401..5bdea300f94 100644
> --- a/gcc/match.pd
> +++ b/gcc/match.pd
> @@ -4803,6 +4803,10 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
> (cnd (cmp @0 zerop) @0 (negate@1 @0))
>  (if (!HONOR_SIGNED_ZEROS (type))
>   @1))
> +  (simplify
> +   (cnd (cmp @0 zerop) real_zerop (negate@1 @0))
> +(if (!HONOR_SIGNED_ZEROS (type))
> + @1))
>(simplify
> (cnd (cmp @0 zerop) integer_zerop (negate@1 @0))
>  (if (!HONOR_SIGNED_ZEROS (type))

Looking at zerop:

bool
zerop (const_tree expr)
{
  return (integer_zerop (expr)
  || real_zerop (expr)
  || fixed_zerop (expr));
}

your patch is equivalent to changing the integer_zerop one to use zerop?
(well, with the exception of also covering fixed_zerop).

OK if doing it that way.

Thanks,
Richard.

> --
> 2.37.1
>

Re: [PATCH]middle-end: fix min/max phiopts reduction [PR106744]

[Richard Biener via Gcc-patches]

On Tue, 30 Aug 2022, Tamar Christina wrote:

> Hi All,
> 
> This corrects the argument usage to use them in the order that they occur in
> the comparisons in gimple.
> 
> This was tested by disabling the pass, adding the runtime checks and 
> re-enabling
> the pass and verifying the tests still pass.
> 
> Also tested that the runtime test caught the issue by updating the tests on an
> unpatched tree and observing that some fail.
> 
> Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
> 
> Ok for master?

OK.
 
> Thanks,
> Tamar
> 
> gcc/ChangeLog:
> 
>   PR tree-optimization/106744
>   * tree-ssa-phiopt.cc (minmax_replacement): Correct arguments.
> 
> gcc/testsuite/ChangeLog:
> 
>   PR tree-optimization/106744
>   * gcc.dg/tree-ssa/minmax-10.c: Make runtime test.
>   * gcc.dg/tree-ssa/minmax-11.c: Likewise.
>   * gcc.dg/tree-ssa/minmax-12.c: Likewise.
>   * gcc.dg/tree-ssa/minmax-13.c: Likewise.
>   * gcc.dg/tree-ssa/minmax-14.c: Likewise.
>   * gcc.dg/tree-ssa/minmax-15.c: Likewise.
>   * gcc.dg/tree-ssa/minmax-16.c: Likewise.
>   * gcc.dg/tree-ssa/minmax-3.c: Likewise.
>   * gcc.dg/tree-ssa/minmax-4.c: Likewise.
>   * gcc.dg/tree-ssa/minmax-5.c: Likewise.
>   * gcc.dg/tree-ssa/minmax-6.c: Likewise.
>   * gcc.dg/tree-ssa/minmax-7.c: Likewise.
>   * gcc.dg/tree-ssa/minmax-8.c: Likewise.
>   * gcc.dg/tree-ssa/minmax-9.c: Likewise.
> 
> --- inline copy of patch -- 
> diff --git a/gcc/testsuite/gcc.dg/tree-ssa/minmax-10.c 
> b/gcc/testsuite/gcc.dg/tree-ssa/minmax-10.c
> index 
> 589953684416a9d263084deb58f6cde7094dd517..c9322a17a4af8e01add2f04176805c812af62e07
>  100644
> --- a/gcc/testsuite/gcc.dg/tree-ssa/minmax-10.c
> +++ b/gcc/testsuite/gcc.dg/tree-ssa/minmax-10.c
> @@ -1,8 +1,9 @@
> -/* { dg-do compile } */
> +/* { dg-do run } */
>  /* { dg-options "-O -fdump-tree-optimized" } */
>  
>  #include 
>  
> +__attribute__ ((noipa, noinline))
>  uint8_t three_max (uint8_t xc, uint8_t xm, uint8_t xy) {
>  uint8_t   xk;
>  xc=~xc;
> @@ -16,5 +17,16 @@ uint8_t three_max (uint8_t xc, uint8_t xm, uint8_t xy) {
>  return xk;
>  }
>  
> +int
> +main (void)
> +{
> +  volatile uint8_t xy = 255;
> +  volatile uint8_t xm = 0;
> +  volatile uint8_t xc = 127;
> +  if (three_max (xc, xm, xy) != 255)
> +__builtin_abort ();
> +  return 0;
> +}
> +
>  /* { dg-final { scan-tree-dump-times "MIN_EXPR" 2 "optimized" } } */
>  /* { dg-final { scan-tree-dump-times "= ~" 1 "optimized" } } */
> diff --git a/gcc/testsuite/gcc.dg/tree-ssa/minmax-11.c 
> b/gcc/testsuite/gcc.dg/tree-ssa/minmax-11.c
> index 
> 1c2ef01b5d1e639fbf95bb5ca473b63cc98e9df1..b1da41712b342cd7344167a0da91ffd419491391
>  100644
> --- a/gcc/testsuite/gcc.dg/tree-ssa/minmax-11.c
> +++ b/gcc/testsuite/gcc.dg/tree-ssa/minmax-11.c
> @@ -1,8 +1,10 @@
> -/* { dg-do compile } */
> +/* { dg-do run } */
>  /* { dg-options "-O -fdump-tree-optimized" } */
>  
>  #include 
>  
> +
> +__attribute__ ((noipa, noinline))
>  uint8_t three_minmax1 (uint8_t xc, uint8_t xm, uint8_t xy) {
>   uint8_t  xk;
>  xc=~xc;
> @@ -16,6 +18,17 @@ uint8_t three_minmax1 (uint8_t xc, uint8_t xm, uint8_t xy) 
> {
>  return xk;
>  }
>  
> +int
> +main (void)
> +{
> +  volatile uint8_t xy = 255;
> +  volatile uint8_t xm = 0;
> +  volatile uint8_t xc = 127;
> +  if (three_minmax1 (xc, xm, xy) != 0)
> +__builtin_abort ();
> +  return 0;
> +}
> +
>  /* { dg-final { scan-tree-dump-times "MIN_EXPR" 1 "optimized" } } */
>  /* { dg-final { scan-tree-dump-times "MAX_EXPR" 1 "optimized" } } */
>  /* { dg-final { scan-tree-dump-times "= ~" 1 "optimized" } } */
> diff --git a/gcc/testsuite/gcc.dg/tree-ssa/minmax-12.c 
> b/gcc/testsuite/gcc.dg/tree-ssa/minmax-12.c
> index 
> 3d0c07d9b57dd689bcb89653937727ab441e7f2b..cb9188f90e8e12c6244d559e63723177102177ee
>  100644
> --- a/gcc/testsuite/gcc.dg/tree-ssa/minmax-12.c
> +++ b/gcc/testsuite/gcc.dg/tree-ssa/minmax-12.c
> @@ -1,8 +1,9 @@
> -/* { dg-do compile } */
> +/* { dg-do run } */
>  /* { dg-options "-O -fdump-tree-phiopt" } */
>  
>  #include 
>  
> +__attribute__ ((noinline, noipa))
>  uint8_t three_minmax3 (uint8_t xc, uint8_t xm, uint8_t xy) {
>  uint8_t  xk;
>  xc=~xc;
> @@ -16,5 +17,16 @@ uint8_t three_minmax3 (uint8_t xc, uint8_t xm, uint8_t xy) 
> {
>  return xk;
>  }
>  
> +int
> +main (void)
> +{
> +  volatile uint8_t xy = 255;
> +  volatile uint8_t xm = 0;
> +  volatile uint8_t xc = 127;
> +  if (three_minmax3 (xc, xm, xy) != 0)
> +__builtin_abort ();
> +  return 0;
> +}
> +
>  /* { dg-final { scan-tree-dump-times "MIN_EXPR" 1 "phiopt1" } } */
>  /* { dg-final { scan-tree-dump-times "MAX_EXPR" 1 "phiopt1" } } */
> diff --git a/gcc/testsuite/gcc.dg/tree-ssa/minmax-13.c 
> b/gcc/testsuite/gcc.dg/tree-ssa/minmax-13.c
> index 
> c0d0f27c8027ae87654532d1b919cfeccf4413e0..62ba71e8c3f21f1cb33ae2473fd2b30bfdc13c81
>  100644
> --- a/gcc/testsuite/gcc.dg/tree-ssa/minmax-13.c
> +++ b/gcc/testsuite/gcc.dg/tree-ssa/minmax-13.c
> @@ 

Re: [PATCH][committed]middle-end intialize regnum in store_bit_field_1

[Richard Biener via Gcc-patches]

On Tue, 30 Aug 2022, Tamar Christina wrote:

> Hi All,
> 
> This initializes regnum to 0 for when undefined_p.
> 0 is the right default as it's supposed to get the lowpart
> when undefined.
> 
> Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
> 
> Ok for master?

OK.

> Thanks,
> Tamar
> 
> gcc/ChangeLog:
> 
>   * expmed.cc (store_bit_field_1): Initialize regnum to 0.
> 
> --- inline copy of patch -- 
> diff --git a/gcc/expmed.cc b/gcc/expmed.cc
> index 
> 8d7418be418406e72a895ecddf2dc7fdb950c76c..cdc0adb389202a5cab79a8d89056ddc347fb28cb
>  100644
> --- a/gcc/expmed.cc
> +++ b/gcc/expmed.cc
> @@ -794,7 +794,7 @@ store_bit_field_1 (rtx str_rtx, poly_uint64 bitsize, 
> poly_uint64 bitnum,
>words or to cope with mode punning between equal-sized modes.
>In the latter case, use subreg on the rhs side, not lhs.  */
>rtx sub;
> -  HOST_WIDE_INT regnum;
> +  HOST_WIDE_INT regnum = 0;
>poly_uint64 regsize = REGMODE_NATURAL_SIZE (GET_MODE (op0));
>if (known_eq (bitnum, 0U)
> && known_eq (bitsize, GET_MODE_BITSIZE (GET_MODE (op0

[PATCH]middle-end: fix min/max phiopts reduction [PR106744]

[Tamar Christina via Gcc-patches]

Hi All,

This corrects the argument usage to use them in the order that they occur in
the comparisons in gimple.

This was tested by disabling the pass, adding the runtime checks and re-enabling
the pass and verifying the tests still pass.

Also tested that the runtime test caught the issue by updating the tests on an
unpatched tree and observing that some fail.

Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.

Ok for master?

Thanks,
Tamar

gcc/ChangeLog:

PR tree-optimization/106744
* tree-ssa-phiopt.cc (minmax_replacement): Correct arguments.

gcc/testsuite/ChangeLog:

PR tree-optimization/106744
* gcc.dg/tree-ssa/minmax-10.c: Make runtime test.
* gcc.dg/tree-ssa/minmax-11.c: Likewise.
* gcc.dg/tree-ssa/minmax-12.c: Likewise.
* gcc.dg/tree-ssa/minmax-13.c: Likewise.
* gcc.dg/tree-ssa/minmax-14.c: Likewise.
* gcc.dg/tree-ssa/minmax-15.c: Likewise.
* gcc.dg/tree-ssa/minmax-16.c: Likewise.
* gcc.dg/tree-ssa/minmax-3.c: Likewise.
* gcc.dg/tree-ssa/minmax-4.c: Likewise.
* gcc.dg/tree-ssa/minmax-5.c: Likewise.
* gcc.dg/tree-ssa/minmax-6.c: Likewise.
* gcc.dg/tree-ssa/minmax-7.c: Likewise.
* gcc.dg/tree-ssa/minmax-8.c: Likewise.
* gcc.dg/tree-ssa/minmax-9.c: Likewise.

--- inline copy of patch -- 
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/minmax-10.c 
b/gcc/testsuite/gcc.dg/tree-ssa/minmax-10.c
index 
589953684416a9d263084deb58f6cde7094dd517..c9322a17a4af8e01add2f04176805c812af62e07
 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/minmax-10.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/minmax-10.c
@@ -1,8 +1,9 @@
-/* { dg-do compile } */
+/* { dg-do run } */
 /* { dg-options "-O -fdump-tree-optimized" } */
 
 #include 
 
+__attribute__ ((noipa, noinline))
 uint8_t three_max (uint8_t xc, uint8_t xm, uint8_t xy) {
 uint8_t xk;
 xc=~xc;
@@ -16,5 +17,16 @@ uint8_t three_max (uint8_t xc, uint8_t xm, uint8_t xy) {
 return xk;
 }
 
+int
+main (void)
+{
+  volatile uint8_t xy = 255;
+  volatile uint8_t xm = 0;
+  volatile uint8_t xc = 127;
+  if (three_max (xc, xm, xy) != 255)
+__builtin_abort ();
+  return 0;
+}
+
 /* { dg-final { scan-tree-dump-times "MIN_EXPR" 2 "optimized" } } */
 /* { dg-final { scan-tree-dump-times "= ~" 1 "optimized" } } */
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/minmax-11.c 
b/gcc/testsuite/gcc.dg/tree-ssa/minmax-11.c
index 
1c2ef01b5d1e639fbf95bb5ca473b63cc98e9df1..b1da41712b342cd7344167a0da91ffd419491391
 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/minmax-11.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/minmax-11.c
@@ -1,8 +1,10 @@
-/* { dg-do compile } */
+/* { dg-do run } */
 /* { dg-options "-O -fdump-tree-optimized" } */
 
 #include 
 
+
+__attribute__ ((noipa, noinline))
 uint8_t three_minmax1 (uint8_t xc, uint8_t xm, uint8_t xy) {
uint8_t  xk;
 xc=~xc;
@@ -16,6 +18,17 @@ uint8_t three_minmax1 (uint8_t xc, uint8_t xm, uint8_t xy) {
 return xk;
 }
 
+int
+main (void)
+{
+  volatile uint8_t xy = 255;
+  volatile uint8_t xm = 0;
+  volatile uint8_t xc = 127;
+  if (three_minmax1 (xc, xm, xy) != 0)
+__builtin_abort ();
+  return 0;
+}
+
 /* { dg-final { scan-tree-dump-times "MIN_EXPR" 1 "optimized" } } */
 /* { dg-final { scan-tree-dump-times "MAX_EXPR" 1 "optimized" } } */
 /* { dg-final { scan-tree-dump-times "= ~" 1 "optimized" } } */
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/minmax-12.c 
b/gcc/testsuite/gcc.dg/tree-ssa/minmax-12.c
index 
3d0c07d9b57dd689bcb89653937727ab441e7f2b..cb9188f90e8e12c6244d559e63723177102177ee
 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/minmax-12.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/minmax-12.c
@@ -1,8 +1,9 @@
-/* { dg-do compile } */
+/* { dg-do run } */
 /* { dg-options "-O -fdump-tree-phiopt" } */
 
 #include 
 
+__attribute__ ((noinline, noipa))
 uint8_t three_minmax3 (uint8_t xc, uint8_t xm, uint8_t xy) {
 uint8_t  xk;
 xc=~xc;
@@ -16,5 +17,16 @@ uint8_t three_minmax3 (uint8_t xc, uint8_t xm, uint8_t xy) {
 return xk;
 }
 
+int
+main (void)
+{
+  volatile uint8_t xy = 255;
+  volatile uint8_t xm = 0;
+  volatile uint8_t xc = 127;
+  if (three_minmax3 (xc, xm, xy) != 0)
+__builtin_abort ();
+  return 0;
+}
+
 /* { dg-final { scan-tree-dump-times "MIN_EXPR" 1 "phiopt1" } } */
 /* { dg-final { scan-tree-dump-times "MAX_EXPR" 1 "phiopt1" } } */
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/minmax-13.c 
b/gcc/testsuite/gcc.dg/tree-ssa/minmax-13.c
index 
c0d0f27c8027ae87654532d1b919cfeccf4413e0..62ba71e8c3f21f1cb33ae2473fd2b30bfdc13c81
 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/minmax-13.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/minmax-13.c
@@ -1,8 +1,9 @@
-/* { dg-do compile } */
+/* { dg-do run } */
 /* { dg-options "-O -fdump-tree-phiopt" } */
 
 #include 
 
+__attribute__ ((noipa, noinline))
 uint8_t three_minmax2 (uint8_t xc, uint8_t xm, uint8_t xy) {
uint8_t  xk;
 xc=~xc;
@@ -15,5 +16,17 @@ uint8_t three_minmax2 (uint8_t xc, uint8_t xm, uint8_t xy) {
 }

[PATCH][committed]middle-end intialize regnum in store_bit_field_1

[Tamar Christina via Gcc-patches]

Hi All,

This initializes regnum to 0 for when undefined_p.
0 is the right default as it's supposed to get the lowpart
when undefined.

Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.

Ok for master?

Thanks,
Tamar

gcc/ChangeLog:

* expmed.cc (store_bit_field_1): Initialize regnum to 0.

--- inline copy of patch -- 
diff --git a/gcc/expmed.cc b/gcc/expmed.cc
index 
8d7418be418406e72a895ecddf2dc7fdb950c76c..cdc0adb389202a5cab79a8d89056ddc347fb28cb
 100644
--- a/gcc/expmed.cc
+++ b/gcc/expmed.cc
@@ -794,7 +794,7 @@ store_bit_field_1 (rtx str_rtx, poly_uint64 bitsize, 
poly_uint64 bitnum,
 words or to cope with mode punning between equal-sized modes.
 In the latter case, use subreg on the rhs side, not lhs.  */
   rtx sub;
-  HOST_WIDE_INT regnum;
+  HOST_WIDE_INT regnum = 0;
   poly_uint64 regsize = REGMODE_NATURAL_SIZE (GET_MODE (op0));
   if (known_eq (bitnum, 0U)
  && known_eq (bitsize, GET_MODE_BITSIZE (GET_MODE (op0




-- 
diff --git a/gcc/expmed.cc b/gcc/expmed.cc
index 
8d7418be418406e72a895ecddf2dc7fdb950c76c..cdc0adb389202a5cab79a8d89056ddc347fb28cb
 100644
--- a/gcc/expmed.cc
+++ b/gcc/expmed.cc
@@ -794,7 +794,7 @@ store_bit_field_1 (rtx str_rtx, poly_uint64 bitsize, 
poly_uint64 bitnum,
 words or to cope with mode punning between equal-sized modes.
 In the latter case, use subreg on the rhs side, not lhs.  */
   rtx sub;
-  HOST_WIDE_INT regnum;
+  HOST_WIDE_INT regnum = 0;
   poly_uint64 regsize = REGMODE_NATURAL_SIZE (GET_MODE (op0));
   if (known_eq (bitnum, 0U)
  && known_eq (bitsize, GET_MODE_BITSIZE (GET_MODE (op0

[PATCH] RISC-V: Add RVV registers in TARGET_CONDITION_AL_REGISTER_USAGE

[juzhe . zhong]

From: zhongjuzhe 

gcc/ChangeLog:

* config/riscv/riscv.cc (riscv_conditional_register_usage): Add RVV 
registers.

---
 gcc/config/riscv/riscv.cc | 9 +
 1 file changed, 9 insertions(+)

diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index 50de6a83cba..aebe3c0ab6b 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -5439,6 +5439,15 @@ riscv_conditional_register_usage (void)
   for (int regno = FP_REG_FIRST; regno <= FP_REG_LAST; regno++)
call_used_regs[regno] = 1;
 }
+
+  if (!TARGET_VECTOR)
+{
+  for (int regno = V_REG_FIRST; regno <= V_REG_LAST; regno++)
+   fixed_regs[regno] = call_used_regs[regno] = 1;
+
+  fixed_regs[VTYPE_REGNUM] = call_used_regs[VTYPE_REGNUM] = 1;
+  fixed_regs[VL_REGNUM] = call_used_regs[VL_REGNUM] = 1;
+}
 }
 
 /* Return a register priority for hard reg REGNO.  */
-- 
2.36.1

[PATCH] RISC-V: Add csrr vlenb instruction.

[juzhe . zhong]

From: zhongjuzhe 

gcc/ChangeLog:

* config/riscv/riscv.cc (riscv_const_insns): Add cost of poly_int.
(riscv_output_move): Add csrr vlenb assembly.
* config/riscv/riscv.md (move_type): Add csrr vlenb type.
(ext): New attribute.
(ext_enabled): Ditto.
(enabled): Ditto.

---
 gcc/config/riscv/riscv.cc | 13 +++
 gcc/config/riscv/riscv.md | 79 ---
 2 files changed, 70 insertions(+), 22 deletions(-)

diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index ef606f33983..50de6a83cba 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -1136,6 +1136,12 @@ riscv_const_insns (rtx x)
 case LABEL_REF:
   return riscv_symbol_insns (riscv_classify_symbol (x));
 
+/* TODO: In RVV, we get CONST_POLY_INT by using csrr vlenb
+   instruction and several scalar shift or mult instructions,
+   it is so far unknown. We set it to 4 temporarily.  */
+case CONST_POLY_INT:
+  return 4;
+
 default:
   return 0;
 }
@@ -2507,6 +2513,13 @@ riscv_output_move (rtx dest, rtx src)
return "fld\t%0,%1";
  }
 }
+  if (dest_code == REG && GP_REG_P (REGNO (dest)) && src_code == 
CONST_POLY_INT)
+{
+  /* we only want a single full vector register vlen
+read after reload. */
+  gcc_assert (known_eq (rtx_to_poly_int64 (src), BYTES_PER_RISCV_VECTOR));
+  return "csrr\t%0,vlenb";
+}
   gcc_unreachable ();
 }
 
diff --git a/gcc/config/riscv/riscv.md b/gcc/config/riscv/riscv.md
index 63bb3c8debc..2bfab198370 100644
--- a/gcc/config/riscv/riscv.md
+++ b/gcc/config/riscv/riscv.md
@@ -148,7 +148,7 @@
 ;; scheduling type to be "multi" instead.
 (define_attr "move_type"
   "unknown,load,fpload,store,fpstore,mtc,mfc,move,fmove,
-   const,logical,arith,andi,shift_shift"
+   const,logical,arith,andi,shift_shift,rdvlenb"
   (const_string "unknown"))
 
 ;; Main data type used by the insn
@@ -166,6 +166,35 @@
 (const_string "yes")]
(const_string "no")))
 
+;; ISA attributes.
+(define_attr "ext" "base,f,d,vector"
+  (const_string "base"))
+
+;; True if the extension is enabled.
+(define_attr "ext_enabled" "no,yes"
+  (cond [(eq_attr "ext" "base")
+(const_string "yes")
+   
+(and (eq_attr "ext" "f")
+ (match_test "TARGET_HARD_FLOAT"))
+(const_string "yes")
+
+(and (eq_attr "ext" "d")
+ (match_test "TARGET_DOUBLE_FLOAT"))
+(const_string "yes")
+
+(and (eq_attr "ext" "vector")
+ (match_test "TARGET_VECTOR"))
+(const_string "yes")
+   ]
+   (const_string "no")))
+
+;; Attribute to control enable or disable instructions.
+(define_attr "enabled" "no,yes"
+  (cond [(eq_attr "ext_enabled" "no")
+(const_string "no")]
+   (const_string "yes")))
+
 ;; Classification of each insn.
 ;; branch  conditional branch
 ;; jumpunconditional jump
@@ -326,7 +355,8 @@
  (eq_attr "dword_mode" "yes"))
   (const_string "multi")
 (eq_attr "move_type" "move") (const_string "move")
-(eq_attr "move_type" "const") (const_string "const")]
+(eq_attr "move_type" "const") (const_string "const")
+(eq_attr "move_type" "rdvlenb") (const_string "rdvlenb")]
(const_string "unknown")))
 
 ;; Length of instruction in bytes.
@@ -1633,24 +1663,26 @@
 })
 
 (define_insn "*movdi_32bit"
-  [(set (match_operand:DI 0 "nonimmediate_operand" "=r,r,r,m,  *f,*f,*r,*f,*m")
-   (match_operand:DI 1 "move_operand" " 
r,i,m,r,*J*r,*m,*f,*f,*f"))]
+  [(set (match_operand:DI 0 "nonimmediate_operand" "=r,r,r,m,  
*f,*f,*r,*f,*m,r")
+   (match_operand:DI 1 "move_operand" " 
r,i,m,r,*J*r,*m,*f,*f,*f,vp"))]
   "!TARGET_64BIT
&& (register_operand (operands[0], DImode)
|| reg_or_0_operand (operands[1], DImode))"
   { return riscv_output_move (operands[0], operands[1]); }
-  [(set_attr "move_type" "move,const,load,store,mtc,fpload,mfc,fmove,fpstore")
-   (set_attr "mode" "DI")])
+  [(set_attr "move_type" 
"move,const,load,store,mtc,fpload,mfc,fmove,fpstore,rdvlenb")
+   (set_attr "mode" "DI")
+   (set_attr "ext" "base,base,base,base,d,d,d,d,d,vector")])
 
 (define_insn "*movdi_64bit"
-  [(set (match_operand:DI 0 "nonimmediate_operand" "=r,r,r, m,  
*f,*f,*r,*f,*m")
-   (match_operand:DI 1 "move_operand" " 
r,T,m,rJ,*r*J,*m,*f,*f,*f"))]
+  [(set (match_operand:DI 0 "nonimmediate_operand" "=r,r,r, m,  
*f,*f,*r,*f,*m,r")
+   (match_operand:DI 1 "move_operand" " 
r,T,m,rJ,*r*J,*m,*f,*f,*f,vp"))]
   "TARGET_64BIT
&& (register_operand (operands[0], DImode)
|| reg_or_0_operand (operands[1], DImode))"
   { return riscv_output_move (operands[0], operands[1]); }
-  [(set_attr "move_type" "move,const,load,store,mtc,fpload,mfc,fmove,fpstore")
-   (set_attr "mode" "DI")])
+  [(set_attr "move_type" 

[PATCH] RISC-V: Add RVV constraints.

[juzhe . zhong]

From: zhongjuzhe 

gcc/ChangeLog:

* config/riscv/constraints.md (TARGET_VECTOR ? V_REGS : NO_REGS): Add 
"vr" constraint.
(TARGET_VECTOR ? VD_REGS : NO_REGS): Add "vd" constraint.
(TARGET_VECTOR ? VM_REGS : NO_REGS): Add "vm" constraint.
(vp): Add poly constraint.

---
 gcc/config/riscv/constraints.md | 20 
 1 file changed, 20 insertions(+)

diff --git a/gcc/config/riscv/constraints.md b/gcc/config/riscv/constraints.md
index 2873d533cb5..669e5ed734b 100644
--- a/gcc/config/riscv/constraints.md
+++ b/gcc/config/riscv/constraints.md
@@ -108,3 +108,23 @@
A constant @code{move_operand}."
   (and (match_operand 0 "move_operand")
(match_test "CONSTANT_P (op)")))
+
+;; Vector constraints.
+
+(define_register_constraint "vr" "TARGET_VECTOR ? V_REGS : NO_REGS"
+  "A vector register (if available).")
+
+(define_register_constraint "vd" "TARGET_VECTOR ? VD_REGS : NO_REGS"
+  "A vector register except mask register (if available).")
+
+(define_register_constraint "vm" "TARGET_VECTOR ? VM_REGS : NO_REGS"
+  "A vector mask register (if available).")
+
+;; This constraint is used to match instruction "csrr %0, vlenb" which is 
generated in "mov".
+;; VLENB is a run-time constant which represent the vector register length in 
bytes.
+;; BYTES_PER_RISCV_VECTOR represent runtime invariant of vector register 
length in bytes.
+;; We should only allow the poly equal to BYTES_PER_RISCV_VECTOR.
+(define_constraint "vp"
+  "POLY_INT"
+  (and (match_code "const_poly_int")
+   (match_test "known_eq (rtx_to_poly_int64 (op), 
BYTES_PER_RISCV_VECTOR)")))
\ No newline at end of file
-- 
2.36.1