[PATCH 7/7] jit,docs: remove :ref:`modindex`

2022-07-25 Thread Martin Liška
gcc/jit/ChangeLog:

* docs/index.rst: Remove reference to module index
as we don't emit any.
---
 gcc/jit/docs/index.rst | 1 -
 1 file changed, 1 deletion(-)

diff --git a/gcc/jit/docs/index.rst b/gcc/jit/docs/index.rst
index 21c3140e238..0f575966303 100644
--- a/gcc/jit/docs/index.rst
+++ b/gcc/jit/docs/index.rst
@@ -43,5 +43,4 @@ Indices and tables
 ==
 
 * :ref:`genindex`
-* :ref:`modindex`
 * :ref:`search`
-- 
2.37.1



Re: [PATCH 6/7] jit,docs: use :expr:`type *` for pointers to a type

2022-07-25 Thread Martin Liška
On 7/26/22 00:41, David Malcolm wrote:
> On Mon, 2022-07-25 at 14:39 +0200, Martin Liska wrote:
>> gcc/jit/ChangeLog:
>>
>> * docs/cp/intro/tutorial02.rst: Use :expr:`type *` for
>> pointers to a type
>> * docs/cp/topics/asm.rst: Likewise.
>> * docs/cp/topics/contexts.rst: Likewise.
>> * docs/cp/topics/expressions.rst: Likewise.
>> * docs/cp/topics/functions.rst: Likewise.
>> * docs/cp/topics/objects.rst: Likewise.
>> * docs/intro/tutorial02.rst: Likewise.
>> * docs/intro/tutorial03.rst: Likewise.
>> * docs/intro/tutorial04.rst: Likewise.
>> * docs/intro/tutorial05.rst: Likewise.
>> * docs/topics/compilation.rst: Likewise.
>> * docs/topics/contexts.rst: Likewise.
>> * docs/topics/objects.rst: Likewise.
> 
> As per patch 2/7, what's the motivation for this change?  The things
> being marked up are types rather than expressions.

Apparently, one can't reference a type pointer with :type:`type *` as I asked
in: https://github.com/sphinx-doc/sphinx/issues/10704

Fixes the following warnings:

/home/marxin/Programming/gcc/gcc/jit/docs/topics/objects.rst:25: WARNING: 
Unparseable C cross-reference: 'gcc_jit_context *'
Invalid C declaration: Expected end of definition. [error at 16]
  gcc_jit_context *
  ^

Cheers,
Martin

> 
> Dave
> 
>> ---
>>  gcc/jit/docs/cp/intro/tutorial02.rst   |  4 ++--
>>  gcc/jit/docs/cp/topics/asm.rst |  2 +-
>>  gcc/jit/docs/cp/topics/contexts.rst    |  6 +++---
>>  gcc/jit/docs/cp/topics/expressions.rst |  4 ++--
>>  gcc/jit/docs/cp/topics/functions.rst   |  2 +-
>>  gcc/jit/docs/cp/topics/objects.rst |  2 +-
>>  gcc/jit/docs/intro/tutorial02.rst  | 16 +++
>>  gcc/jit/docs/intro/tutorial03.rst  | 28 +---
>> --
>>  gcc/jit/docs/intro/tutorial04.rst  |  2 +-
>>  gcc/jit/docs/intro/tutorial05.rst  |  4 ++--
>>  gcc/jit/docs/topics/compilation.rst    |  8 
>>  gcc/jit/docs/topics/contexts.rst   |  6 +++---
>>  gcc/jit/docs/topics/objects.rst    |  6 +++---
>>  13 files changed, 45 insertions(+), 45 deletions(-)
>>
>> diff --git a/gcc/jit/docs/cp/intro/tutorial02.rst
>> b/gcc/jit/docs/cp/intro/tutorial02.rst
>> index 55675cc7398..9f9a7f3858e 100644
>> --- a/gcc/jit/docs/cp/intro/tutorial02.rst
>> +++ b/gcc/jit/docs/cp/intro/tutorial02.rst
>> @@ -39,7 +39,7 @@ First we need to include the relevant header:
>>  
>>  All state associated with compilation is associated with a
>>  :type:`gccjit::context`, which is a thin C++ wrapper around the C
>> API's
>> -:c:type:`gcc_jit_context *`.
>> +:c:expr:`gcc_jit_context *`.
>>  
>>  Create one using :func:`gccjit::context::acquire`:
>>  
>> @@ -194,7 +194,7 @@ OK, we've populated the context.  We can now
>> compile it using
>>     gcc_jit_result *result;
>>     result = ctxt.compile ();
>>  
>> -and get a :c:type:`gcc_jit_result *`.
>> +and get a :c:expr:`gcc_jit_result *`.
>>  
>>  We can now use :c:func:`gcc_jit_result_get_code` to look up a
>> specific
>>  machine code routine within the result, in this case, the function
>> we
>> diff --git a/gcc/jit/docs/cp/topics/asm.rst
>> b/gcc/jit/docs/cp/topics/asm.rst
>> index f7e4e952b10..0d63da3d59e 100644
>> --- a/gcc/jit/docs/cp/topics/asm.rst
>> +++ b/gcc/jit/docs/cp/topics/asm.rst
>> @@ -43,7 +43,7 @@ Adding assembler instructions within a function
>>     to outputs.
>>  
>>     :class:`gccjit::extended_asm` is a subclass of
>> :class:`gccjit::object`.
>> -   It is a thin wrapper around the C API's
>> :c:type:`gcc_jit_extended_asm *`.
>> +   It is a thin wrapper around the C API's
>> :c:expr:`gcc_jit_extended_asm *`.
>>  
>>     To avoid having an API entrypoint with a very large number of
>>     parameters, an extended ``asm`` statement is made in stages:
>> diff --git a/gcc/jit/docs/cp/topics/contexts.rst
>> b/gcc/jit/docs/cp/topics/contexts.rst
>> index f60f2102b3e..2f2456a9c0d 100644
>> --- a/gcc/jit/docs/cp/topics/contexts.rst
>> +++ b/gcc/jit/docs/cp/topics/contexts.rst
>> @@ -29,9 +29,9 @@ compilation.
>>  
>>  You can set up options on it, and add types, functions and code.
>>  Invoking :func:`gccjit::context::compile` on it gives you a
>> -:c:type:`gcc_jit_result *`.
>> +:c:expr:`gcc_jit_result *`.
>>  
>> -It is a thin wrapper around the C API's :c:type:`gcc_jit_context *`.
>> +It is a thin wrapper around the C API's :c:expr:`gcc_jit_context *`.
>>  
>>  Lifetime-management
>>  ---
>> @@ -48,7 +48,7 @@ cleanup of such objects is done for you when the
>> context is released.
>>  .. function:: void gccjit::context::release ()
>>  
>>    This function releases all resources associated with the given
>> context.
>> -  Both the context itself and all of its :c:type:`gccjit::object *`
>> +  Both the context itself and all of its :expr:`gccjit::object *`
>>    instances are cleaned up.  It should be called exactly once on a
>> given
>>    context.
>>  
>> diff --git 

Re: [PATCH 2/7] jit,docs: replace c:type:`int_type` with :expr:`int_type`

2022-07-25 Thread Martin Liška
On 7/26/22 00:37, David Malcolm wrote:
> On Mon, 2022-07-25 at 11:03 +0200, Martin Liska wrote:
>> Use expression that work fine for basic type.
> 
> What's the motivation for this change?  Surely the things being marked
> up are types, rather than expressions?

Problem is that one can't reference a type that is not defined by a :type: 
directive,
that's why I'm using :expr:

Fixes the following Sphinx warnings:

/home/marxin/Programming/gcc/gcc/jit/docs/topics/expressions.rst:70: WARNING: 
Unparseable C cross-reference: 'long'
Invalid C declaration: Expected identifier in nested name, got keyword: long 
[error at 4]
  long
  ^

Martin

> 
> Dave
> 
>>
>> gcc/jit/ChangeLog:
>>
>> * docs/cp/topics/expressions.rst: Use :expr: for basic types.
>> * docs/topics/compilation.rst: Likewise.
>> * docs/topics/expressions.rst: Likewise.
>> * docs/topics/function-pointers.rst: Likewise.
>> ---
>>  gcc/jit/docs/cp/topics/expressions.rst    | 6 +++---
>>  gcc/jit/docs/topics/compilation.rst   | 4 ++--
>>  gcc/jit/docs/topics/expressions.rst   | 6 +++---
>>  gcc/jit/docs/topics/function-pointers.rst | 2 +-
>>  4 files changed, 9 insertions(+), 9 deletions(-)
>>
>> diff --git a/gcc/jit/docs/cp/topics/expressions.rst
>> b/gcc/jit/docs/cp/topics/expressions.rst
>> index 239e004371e..003dbce8991 100644
>> --- a/gcc/jit/docs/cp/topics/expressions.rst
>> +++ b/gcc/jit/docs/cp/topics/expressions.rst
>> @@ -57,14 +57,14 @@ Simple expressions
>>     int value) const
>>  
>>     Given a numeric type (integer or floating point), build an rvalue
>> for
>> -   the given constant :c:type:`int` value.
>> +   the given constant :expr:`int` value.
>>  
>>  .. function:: gccjit::rvalue \
>>    gccjit::context::new_rvalue (gccjit::type
>> numeric_type, \
>>     long value) const
>>  
>>     Given a numeric type (integer or floating point), build an rvalue
>> for
>> -   the given constant :c:type:`long` value.
>> +   the given constant :expr:`long` value.
>>  
>>  .. function::  gccjit::rvalue \
>>     gccjit::context::zero (gccjit::type numeric_type)
>> const
>> @@ -91,7 +91,7 @@ Simple expressions
>>  double value) const
>>  
>>     Given a numeric type (integer or floating point), build an rvalue
>> for
>> -   the given constant :c:type:`double` value.
>> +   the given constant :expr:`double` value.
>>  
>>  .. function:: gccjit::rvalue \
>>    gccjit::context::new_rvalue (gccjit::type
>> pointer_type, \
>> diff --git a/gcc/jit/docs/topics/compilation.rst
>> b/gcc/jit/docs/topics/compilation.rst
>> index c5fa6eb0faf..91b9c2533cf 100644
>> --- a/gcc/jit/docs/topics/compilation.rst
>> +++ b/gcc/jit/docs/topics/compilation.rst
>> @@ -98,8 +98,8 @@ In-memory compilation
>>     If the global is found, the result will need to be cast to a
>>     pointer of the correct type before it can be called.
>>  
>> -   This is a *pointer* to the global, so e.g. for an :c:type:`int`
>> this is
>> -   an :c:type:`int *`.
>> +   This is a *pointer* to the global, so e.g. for an :expr:`int`
>> this is
>> +   an :expr:`int *`.
>>  
>>     For example, given an ``int foo;`` created this way:
>>  
>> diff --git a/gcc/jit/docs/topics/expressions.rst
>> b/gcc/jit/docs/topics/expressions.rst
>> index 49b7e14ae2b..00e2ec8cfeb 100644
>> --- a/gcc/jit/docs/topics/expressions.rst
>> +++ b/gcc/jit/docs/topics/expressions.rst
>> @@ -60,7 +60,7 @@ Simple expressions
>>     int value)
>>  
>>     Given a numeric type (integer or floating point), build an rvalue
>> for
>> -   the given constant :c:type:`int` value.
>> +   the given constant :expr:`int` value.
>>  
>>  .. function:: gcc_jit_rvalue *\
>>    gcc_jit_context_new_rvalue_from_long (gcc_jit_context
>> *ctxt, \
>> @@ -68,7 +68,7 @@ Simple expressions
>>  long value)
>>  
>>     Given a numeric type (integer or floating point), build an rvalue
>> for
>> -   the given constant :c:type:`long` value.
>> +   the given constant :expr:`long` value.
>>  
>>  .. function::  gcc_jit_rvalue *gcc_jit_context_zero (gcc_jit_context
>> *ctxt, \
>>   gcc_jit_type
>> *numeric_type)
>> @@ -96,7 +96,7 @@ Simple expressions
>>     double value)
>>  
>>     Given a numeric type (integer or floating point), build an rvalue
>> for
>> -   the given constant :c:type:`double` value.
>> +   the given constant :expr:`double` value.
>>  
>>  .. function:: gcc_jit_rvalue *\
>>    gcc_jit_context_new_rvalue_from_ptr (gcc_jit_context
>> *ctxt, \
>> diff --git a/gcc/jit/docs/topics/function-pointers.rst
>> b/gcc/jit/docs/topics/function-pointers.rst
>> index e6f9970a7a7..dde49215853 100644
>> --- 

Re: [PATCH 1/7] jit,docs: use enum directive for enumeral types

2022-07-25 Thread Martin Liška
On 7/26/22 00:35, David Malcolm wrote:
> On Mon, 2022-07-25 at 10:52 +0200, Martin Liska wrote:
>> gcc/jit/ChangeLog:
>>
>> * docs/conf.py: Add needs_sphinx = '3.0' where c:type was
>> added.
> 
> Looking at the footer of https://gcc.gnu.org/onlinedocs/jit/index.html
> I see we currently only have sphinx 1.7.6 installed.

Yep.

> 
> Have you been talking with the gcc.gnu.org admins about bumping this
> requirement?

Yes, working on that right now:

https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598771.html

Thanks,
Martin

> 
> Otherwise the patch looks OK
> 
> Dave
> 



Re: [PATCH 3/3] c++/106426: Treat u8 character literals as unsigned in char8_t modes.

2022-07-25 Thread Tom Honermann via Gcc-patches

On 7/25/22 2:05 PM, Andrew Pinski wrote:

On Mon, Jul 25, 2022 at 11:01 AM Tom Honermann via Gcc-patches
 wrote:

This patch corrects handling of UTF-8 character literals in preprocessing
directives so that they are treated as unsigned types in char8_t enabled
C++ modes (C++17 with -fchar8_t or C++20 without -fno-char8_t). Previously,
UTF-8 character literals were always treated as having the same type as
ordinary character literals (signed or unsigned dependent on target or use
of the -fsigned-char or -funsigned char options).

Fixes https://gcc.gnu.org/PR106426.

The above mention of the PR # should just be:
preprocessor/106426

And then when this patch gets committed, it will be recorded in bugzilla also.


Thank you. I resent the patch with a revised subject line and commit 
message to reflect the component change in Bugzilla.


Tom.



Thanks,
Andrew Pinski



Re: [PATCH 3/3 v2] preprocessor/106426: Treat u8 character literals as unsigned in char8_t modes.

2022-07-25 Thread Tom Honermann via Gcc-patches
This patch corrects handling of UTF-8 character literals in preprocessing
directives so that they are treated as unsigned types in char8_t enabled
C++ modes (C++17 with -fchar8_t or C++20 without -fno-char8_t). Previously,
UTF-8 character literals were always treated as having the same type as
ordinary character literals (signed or unsigned dependent on target or use
of the -fsigned-char or -funsigned char options).

PR preprocessor/106426

gcc/c-family/ChangeLog:
* c-opts.cc (c_common_post_options): Assign cpp_opts->unsigned_utf8char
subject to -fchar8_t, -fsigned-char, and/or -funsigned-char.

gcc/testsuite/ChangeLog:
* g++.dg/ext/char8_t-char-literal-1.C: Check signedness of u8 literals.
* g++.dg/ext/char8_t-char-literal-2.C: Check signedness of u8 literals.

libcpp/ChangeLog:
* charset.cc (narrow_str_to_charconst): Set signedness of CPP_UTF8CHAR
literals based on unsigned_utf8char.
* include/cpplib.h (cpp_options): Add unsigned_utf8char.
* init.cc (cpp_create_reader): Initialize unsigned_utf8char.
---
 gcc/c-family/c-opts.cc| 1 +
 gcc/testsuite/g++.dg/ext/char8_t-char-literal-1.C | 6 +-
 gcc/testsuite/g++.dg/ext/char8_t-char-literal-2.C | 4 
 libcpp/charset.cc | 4 ++--
 libcpp/include/cpplib.h   | 4 ++--
 libcpp/init.cc| 1 +
 6 files changed, 15 insertions(+), 5 deletions(-)

diff --git a/gcc/c-family/c-opts.cc b/gcc/c-family/c-opts.cc
index 108adc5caf8..02ce1e86cdb 100644
--- a/gcc/c-family/c-opts.cc
+++ b/gcc/c-family/c-opts.cc
@@ -1062,6 +1062,7 @@ c_common_post_options (const char **pfilename)
   /* char8_t support is implicitly enabled in C++20 and C2X.  */
   if (flag_char8_t == -1)
 flag_char8_t = (cxx_dialect >= cxx20) || flag_isoc2x;
+  cpp_opts->unsigned_utf8char = flag_char8_t ? 1 : cpp_opts->unsigned_char;
 
   if (flag_extern_tls_init)
 {
diff --git a/gcc/testsuite/g++.dg/ext/char8_t-char-literal-1.C 
b/gcc/testsuite/g++.dg/ext/char8_t-char-literal-1.C
index 8ed85ccfdcd..2994dd38516 100644
--- a/gcc/testsuite/g++.dg/ext/char8_t-char-literal-1.C
+++ b/gcc/testsuite/g++.dg/ext/char8_t-char-literal-1.C
@@ -1,6 +1,6 @@
 // Test that UTF-8 character literals have type char if -fchar8_t is not 
enabled.
 // { dg-do compile }
-// { dg-options "-std=c++17 -fno-char8_t" }
+// { dg-options "-std=c++17 -fsigned-char -fno-char8_t" }
 
 template
   struct is_same
@@ -10,3 +10,7 @@ template
   { static const bool value = true; };
 
 static_assert(is_same::value, "Error");
+
+#if u8'\0' - 1 > 0
+#error "UTF-8 character literals not signed in preprocessor"
+#endif
diff --git a/gcc/testsuite/g++.dg/ext/char8_t-char-literal-2.C 
b/gcc/testsuite/g++.dg/ext/char8_t-char-literal-2.C
index 7861736689c..db4fe70046d 100644
--- a/gcc/testsuite/g++.dg/ext/char8_t-char-literal-2.C
+++ b/gcc/testsuite/g++.dg/ext/char8_t-char-literal-2.C
@@ -10,3 +10,7 @@ template
   { static const bool value = true; };
 
 static_assert(is_same::value, "Error");
+
+#if u8'\0' - 1 < 0
+#error "UTF-8 character literals not unsigned in preprocessor"
+#endif
diff --git a/libcpp/charset.cc b/libcpp/charset.cc
index ca8b7cf7aa5..12e31632228 100644
--- a/libcpp/charset.cc
+++ b/libcpp/charset.cc
@@ -1960,8 +1960,8 @@ narrow_str_to_charconst (cpp_reader *pfile, cpp_string 
str,
   /* Multichar constants are of type int and therefore signed.  */
   if (i > 1)
 unsigned_p = 0;
-  else if (type == CPP_UTF8CHAR && !CPP_OPTION (pfile, cplusplus))
-unsigned_p = 1;
+  else if (type == CPP_UTF8CHAR)
+unsigned_p = CPP_OPTION (pfile, unsigned_utf8char);
   else
 unsigned_p = CPP_OPTION (pfile, unsigned_char);
 
diff --git a/libcpp/include/cpplib.h b/libcpp/include/cpplib.h
index 3eba6f74b57..f9c042db034 100644
--- a/libcpp/include/cpplib.h
+++ b/libcpp/include/cpplib.h
@@ -581,8 +581,8 @@ struct cpp_options
  ints and target wide characters, respectively.  */
   size_t precision, char_precision, int_precision, wchar_precision;
 
-  /* True means chars (wide chars) are unsigned.  */
-  bool unsigned_char, unsigned_wchar;
+  /* True means chars (wide chars, UTF-8 chars) are unsigned.  */
+  bool unsigned_char, unsigned_wchar, unsigned_utf8char;
 
   /* True if the most significant byte in a word has the lowest
  address in memory.  */
diff --git a/libcpp/init.cc b/libcpp/init.cc
index f4ab83d2145..0242da5f55c 100644
--- a/libcpp/init.cc
+++ b/libcpp/init.cc
@@ -231,6 +231,7 @@ cpp_create_reader (enum c_lang lang, cpp_hash_table *table,
   CPP_OPTION (pfile, int_precision) = CHAR_BIT * sizeof (int);
   CPP_OPTION (pfile, unsigned_char) = 0;
   CPP_OPTION (pfile, unsigned_wchar) = 1;
+  CPP_OPTION (pfile, unsigned_utf8char) = 1;
   CPP_OPTION (pfile, bytes_big_endian) = 1;  /* does not matter */
 
   /* Default to no charset conversion.  */
-- 
2.32.0



[PATCH] x86: Enable __bf16 type for TARGET_SSE2 and above

2022-07-25 Thread Kong, Lingling via Gcc-patches
Hi,

The patch is enable __bf16 scalar type for target sse2 and above according to 
psABI(https://gitlab.com/x86-psABIs/x86-64-ABI/-/merge_requests/35/diffs).
The __bf16 type is a storage type like arm.

OK for master?

gcc/ChangeLog:

* config/i386/i386-builtin-types.def (BFLOAT16): New primitive type.
* config/i386/i386-builtins.cc : Support __bf16 type for i386 backend.
(ix86_register_bf16_builtin_type): New function.
(ix86_bf16_type_node): New.
(ix86_bf16_ptr_type_node): Ditto.
(ix86_init_builtin_types): Add ix86_register_bf16_builtin_type function 
call.
* config/i386/i386-modes.def (FLOAT_MODE): Add BFmode.
(ADJUST_FLOAT_FORMAT): Ditto.
* config/i386/i386.cc (merge_classes): Handle BFmode.
(classify_argument): Ditto.
(examine_argument): Ditto.
(construct_container): Ditto.
(function_value_32): Return __bf16 by %xmm0.
(function_value_64): Return __bf16 by SSE register.
(ix86_print_operand): Handle CONST_DOUBLE BFmode.
(ix86_secondary_reload): Require gpr as intermediate register
to store __bf16 from sse register when sse4 is not available.
(ix86_scalar_mode_supported_p): Enable __bf16 under sse2.
(ix86_mangle_type): Add manlging for __bf16 type.
(ix86_invalid_conversion): New function for target hook.
(ix86_invalid_unary_op): Ditto.
(ix86_invalid_binary_op): Ditto.
(TARGET_INVALID_CONVERSION): New define for target hook.
(TARGET_INVALID_UNARY_OP): Ditto.
(TARGET_INVALID_BINARY_OP): Ditto.
* config/i386/i386.h (host_detect_local_cpu): Add BFmode.
* config/i386/i386.md (*pushhf_rex64): Change for BFmode.
(*push_rex64): Ditto.
(*pushhf): Ditto.
(*push): Ditto.
(*movhf_internal): Ditto.
(*mov_internal): Ditto.

gcc/testsuite/ChangeLog:

* g++.target/i386/bfloat_cpp_typecheck.C: New test.
* gcc.target/i386/bfloat16-1.c: Ditto.
* gcc.target/i386/sse2-bfloat16-1.c: Ditto.
* gcc.target/i386/sse2-bfloat16-2.c: Ditto.
* gcc.target/i386/sse2-bfloat16-scalar-typecheck.c: Ditto.
---
 gcc/config/i386/i386-builtin-types.def|   1 +
 gcc/config/i386/i386-builtins.cc  |  21 ++
 gcc/config/i386/i386-modes.def|   2 +
 gcc/config/i386/i386.cc   |  75 +-
 gcc/config/i386/i386.h|   4 +-
 gcc/config/i386/i386.md   |  32 +--
 .../g++.target/i386/bfloat_cpp_typecheck.C|  10 +
 gcc/testsuite/gcc.target/i386/bfloat16-1.c|  12 +
 .../gcc.target/i386/sse2-bfloat16-1.c |   8 +
 .../gcc.target/i386/sse2-bfloat16-2.c |  17 ++
 .../i386/sse2-bfloat16-scalar-typecheck.c | 215 ++
 11 files changed, 375 insertions(+), 22 deletions(-)  create mode 100644 
gcc/testsuite/g++.target/i386/bfloat_cpp_typecheck.C
 create mode 100644 gcc/testsuite/gcc.target/i386/bfloat16-1.c
 create mode 100644 gcc/testsuite/gcc.target/i386/sse2-bfloat16-1.c
 create mode 100644 gcc/testsuite/gcc.target/i386/sse2-bfloat16-2.c
 create mode 100644 
gcc/testsuite/gcc.target/i386/sse2-bfloat16-scalar-typecheck.c

diff --git a/gcc/config/i386/i386-builtin-types.def 
b/gcc/config/i386/i386-builtin-types.def
index 7a2da1db0b0..63a360b0f8b 100644
--- a/gcc/config/i386/i386-builtin-types.def
+++ b/gcc/config/i386/i386-builtin-types.def
@@ -69,6 +69,7 @@ DEF_PRIMITIVE_TYPE (UINT16, short_unsigned_type_node)  
DEF_PRIMITIVE_TYPE (INT64, long_long_integer_type_node)  DEF_PRIMITIVE_TYPE 
(UINT64, long_long_unsigned_type_node)  DEF_PRIMITIVE_TYPE (FLOAT16, 
ix86_float16_type_node)
+DEF_PRIMITIVE_TYPE (BFLOAT16, ix86_bf16_type_node)
 DEF_PRIMITIVE_TYPE (FLOAT, float_type_node)  DEF_PRIMITIVE_TYPE (DOUBLE, 
double_type_node)  DEF_PRIMITIVE_TYPE (FLOAT80, float80_type_node) diff --git 
a/gcc/config/i386/i386-builtins.cc b/gcc/config/i386/i386-builtins.cc
index fe7243c3837..6a04fb57e65 100644
--- a/gcc/config/i386/i386-builtins.cc
+++ b/gcc/config/i386/i386-builtins.cc
@@ -126,6 +126,9 @@ BDESC_VERIFYS (IX86_BUILTIN_MAX,  static GTY(()) tree 
ix86_builtin_type_tab[(int) IX86_BT_LAST_CPTR + 1];
 
 tree ix86_float16_type_node = NULL_TREE;
+tree ix86_bf16_type_node = NULL_TREE;
+tree ix86_bf16_ptr_type_node = NULL_TREE;
+
 /* Retrieve an element from the above table, building some of
the types lazily.  */
 
@@ -1366,6 +1369,22 @@ ix86_register_float16_builtin_type (void)
"_Float16");
 }
 
+static void
+ix86_register_bf16_builtin_type (void)
+{
+  ix86_bf16_type_node = make_node (REAL_TYPE);
+  TYPE_PRECISION (ix86_bf16_type_node) = 16;
+  SET_TYPE_MODE (ix86_bf16_type_node, BFmode);
+  layout_type (ix86_bf16_type_node);
+
+  if (!maybe_get_identifier ("__bf16") && TARGET_SSE2)
+{
+  lang_hooks.types.register_builtin_type (ix86_bf16_type_node,
+   

Re: [v2 PATCH] c++: ICE with erroneous template redeclaration [PR106311]

2022-07-25 Thread Jason Merrill via Gcc-patches

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

On Fri, Jul 22, 2022 at 05:21:58PM -0400, Jason Merrill wrote:

On 7/15/22 11:29, Marek Polacek wrote:

Here we ICE trying to get DECL_SOURCE_LOCATION of the parm that happens
to be error_mark_node in this ill-formed test.  I kept running into this
while reducing code, so it'd be good to have it fixed.

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

PR c++/106311

gcc/cp/ChangeLog:

* pt.cc (redeclare_class_template): Check DECL_P before accessing
DECL_SOURCE_LOCATION.

gcc/testsuite/ChangeLog:

* g++.dg/template/redecl5.C: New test.
---
   gcc/cp/pt.cc| 3 ++-
   gcc/testsuite/g++.dg/template/redecl5.C | 5 +
   2 files changed, 7 insertions(+), 1 deletion(-)
   create mode 100644 gcc/testsuite/g++.dg/template/redecl5.C

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


If we're checking DECL_P, probably we also should avoid passing it to %q#D
if it's false?


Right, I suppose printing "" isn't all that helpful.  How about
this?

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


OK.


-- >8 --
Here we ICE trying to get DECL_SOURCE_LOCATION of the parm that happens
to be error_mark_node in this ill-formed test.  I kept running into this
while reducing code, so it'd be good to have it fixed.

PR c++/106311

gcc/cp/ChangeLog:

* pt.cc (redeclare_class_template): Check DECL_P before accessing
DECL_SOURCE_LOCATION.

gcc/testsuite/ChangeLog:

* g++.dg/template/redecl5.C: New test.
---
  gcc/cp/pt.cc| 5 -
  gcc/testsuite/g++.dg/template/redecl5.C | 5 +
  2 files changed, 9 insertions(+), 1 deletion(-)
  create mode 100644 gcc/testsuite/g++.dg/template/redecl5.C

diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
index c415db304c9..6c581fe0fb7 100644
--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -6377,7 +6377,10 @@ redeclare_class_template (tree type, tree parms, tree 
cons)
{
  auto_diagnostic_group d;
  error ("template parameter %q+#D", tmpl_parm);
- inform (DECL_SOURCE_LOCATION (parm), "redeclared here as %q#D", parm);
+ if (DECL_P (parm))
+   inform (DECL_SOURCE_LOCATION (parm), "redeclared here as %q#D", 
parm);
+ else
+   inform (input_location, "redeclared here");
  return false;
}
  
diff --git a/gcc/testsuite/g++.dg/template/redecl5.C b/gcc/testsuite/g++.dg/template/redecl5.C

new file mode 100644
index 000..fb2d698e6bc
--- /dev/null
+++ b/gcc/testsuite/g++.dg/template/redecl5.C
@@ -0,0 +1,5 @@
+// PR c++/106311
+// { dg-do compile }
+
+template  struct array; // { dg-error "template parameter" }
+template  struct array { }; // { dg-error "declared" }

base-commit: 16aafa3194d4851a07cc204f56a5f0618f77e5d7




[pushed] c++: aggregate prvalue as for range [PR106230]

2022-07-25 Thread Jason Merrill via Gcc-patches
Since my PR94041 work on temporary lifetime in aggregate initialization, we
end up calling build_vec_init to initialize the reference-extended temporary
for the artificial __for_range variable.  And build_vec_init uses
finish_for_stmt to implement its loop.  That function assumes that if
__for_range is in current_binding_level, we're finishing a range-for, and we
should fix up the variable as it goes out of scope.  But when called from
build_vec_init we aren't finishing a range-for, and do_poplevel doesn't
remove the variable from scope because stmts_are_full_exprs_p is false.  So
let's check that here as well, and leave the DECL_NAME alone.

Tested x86_64-pc-linux-gnu, applying to trunk.

PR c++/106230

gcc/cp/ChangeLog:

* semantics.cc (finish_for_stmt): Check stmts_are_full_exprs_p.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/range-for38.C: New test.
---
 gcc/cp/semantics.cc  |  5 +
 gcc/testsuite/g++.dg/cpp0x/range-for38.C | 16 
 2 files changed, 21 insertions(+)
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/range-for38.C

diff --git a/gcc/cp/semantics.cc b/gcc/cp/semantics.cc
index 96037c21b85..16dea0593b0 100644
--- a/gcc/cp/semantics.cc
+++ b/gcc/cp/semantics.cc
@@ -1411,6 +1411,11 @@ finish_for_stmt (tree for_stmt)
 
   add_stmt (do_poplevel (scope));
 
+  /* If we're being called from build_vec_init, don't mess with the names of
+ the variables for an enclosing range-for.  */
+  if (!stmts_are_full_exprs_p ())
+return;
+
   for (int i = 0; i < 3; i++)
 if (range_for_decl[i])
   DECL_NAME (range_for_decl[i])
diff --git a/gcc/testsuite/g++.dg/cpp0x/range-for38.C 
b/gcc/testsuite/g++.dg/cpp0x/range-for38.C
new file mode 100644
index 000..39845b937c1
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/range-for38.C
@@ -0,0 +1,16 @@
+// PR c++/106230
+// { dg-do compile { target c++11 } }
+
+struct A {
+  A();
+  operator int();
+};
+template  struct array {
+  A elts[N];
+  A *begin();
+  A *end();
+};
+void fn() {
+  for (int i : array<4>{})
+;
+}

base-commit: 4c6567b4090d9363f90b5c68e238e7d0964b6e89
-- 
2.31.1



Re: [PATCH] libgccjit.h: Make the macro definition for testing gcc_jit_context_new_bitcast correctly available.

2022-07-25 Thread David Malcolm via Gcc-patches
On Sat, 2022-07-23 at 13:31 +0530, Vibhav Pant via Jit wrote:
> The macro definition for LIBGCCJIT_HAVE_gcc-jit_context_new_bitcast
> was earlier located in the documentation comment for
> gcc_jit_context_new_bitcast, making it unavailable to code that
> consumed libgccjit.h. This patch moves the definition out of the
> comment, making it effective.

Good catch!

Do you have push rights to the git repo, or should I push this?

Thanks
Dave



[PING][PATCH] c: Handle initializations of opaque types [PR106016] (need review of expr.cc hunk)

2022-07-25 Thread Peter Bergner via Gcc-patches
I'd like to ping the following patch.  Segher has approved the
test case change, so I just need a review for the expr.cc change.

Peter



Message-ID: <009c391d-3994-8755-0d22-9e80faf91...@linux.ibm.com>
Date: Fri, 17 Jun 2022 23:50:35 -0500
To: GCC Patches 
Subject: [PATCH] c: Handle initializations of opaque types [PR106016]


On 6/17/22 11:50 PM, Peter Bergner via Gcc-patches wrote:
> The initial commit that added opaque types thought that there couldn't
> be any valid initializations for variables of these types, but the test
> case in the bug report shows that isn't true.  The solution is to handle
> OPAQUE_TYPE initializations just like the other scalar types.
> 
> This passed bootstrap and regtesting with no regressions on powerpc64le-linux.
> Ok for trunk?  This is an issue in GCC 12 and 11 too.  Ok for the release
> branches after some burn-in on trunk?
> 
> Peter
> 
> gcc/
>   PR c/106016
>   * expr.cc (count_type_elements): Handle OPAQUE_TYPE.
> 
> gcc/testsuite/
>   PR c/106016
>   * gcc.target/powerpc/pr106016.c: New test.
> 
> diff --git a/gcc/expr.cc b/gcc/expr.cc
> index 78c839ab425..1675198a146 100644
> --- a/gcc/expr.cc
> +++ b/gcc/expr.cc
> @@ -6423,13 +6423,13 @@ count_type_elements (const_tree type, bool for_ctor_p)
>  case OFFSET_TYPE:
>  case REFERENCE_TYPE:
>  case NULLPTR_TYPE:
> +case OPAQUE_TYPE:
>return 1;
>  
>  case ERROR_MARK:
>return 0;
>  
>  case VOID_TYPE:
> -case OPAQUE_TYPE:
>  case METHOD_TYPE:
>  case FUNCTION_TYPE:
>  case LANG_TYPE:
> diff --git a/gcc/testsuite/gcc.target/powerpc/pr106016.c 
> b/gcc/testsuite/gcc.target/powerpc/pr106016.c
> new file mode 100644
> index 000..3db8345dcc6
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/powerpc/pr106016.c
> @@ -0,0 +1,14 @@
> +/* PR target/106016 */
> +/* { dg-require-effective-target power10_ok } */
> +/* { dg-options "-O2 -mdejagnu-cpu=power10" } */
> +
> +/* Make sure we do not ICE on the following test case.  */
> +
> +extern void bar (__vector_quad *);
> +
> +void
> +foo (__vector_quad *a, __vector_quad *b)
> +{
> +  __vector_quad arr[2] = {*a, *b};
> +  bar ([0]);
> +}



Re: [PATCH 6/7] jit,docs: use :expr:`type *` for pointers to a type

2022-07-25 Thread David Malcolm via Gcc-patches
On Mon, 2022-07-25 at 14:39 +0200, Martin Liska wrote:
> gcc/jit/ChangeLog:
> 
> * docs/cp/intro/tutorial02.rst: Use :expr:`type *` for
> pointers to a type
> * docs/cp/topics/asm.rst: Likewise.
> * docs/cp/topics/contexts.rst: Likewise.
> * docs/cp/topics/expressions.rst: Likewise.
> * docs/cp/topics/functions.rst: Likewise.
> * docs/cp/topics/objects.rst: Likewise.
> * docs/intro/tutorial02.rst: Likewise.
> * docs/intro/tutorial03.rst: Likewise.
> * docs/intro/tutorial04.rst: Likewise.
> * docs/intro/tutorial05.rst: Likewise.
> * docs/topics/compilation.rst: Likewise.
> * docs/topics/contexts.rst: Likewise.
> * docs/topics/objects.rst: Likewise.

As per patch 2/7, what's the motivation for this change?  The things
being marked up are types rather than expressions.

Dave

> ---
>  gcc/jit/docs/cp/intro/tutorial02.rst   |  4 ++--
>  gcc/jit/docs/cp/topics/asm.rst |  2 +-
>  gcc/jit/docs/cp/topics/contexts.rst    |  6 +++---
>  gcc/jit/docs/cp/topics/expressions.rst |  4 ++--
>  gcc/jit/docs/cp/topics/functions.rst   |  2 +-
>  gcc/jit/docs/cp/topics/objects.rst |  2 +-
>  gcc/jit/docs/intro/tutorial02.rst  | 16 +++
>  gcc/jit/docs/intro/tutorial03.rst  | 28 +---
> --
>  gcc/jit/docs/intro/tutorial04.rst  |  2 +-
>  gcc/jit/docs/intro/tutorial05.rst  |  4 ++--
>  gcc/jit/docs/topics/compilation.rst    |  8 
>  gcc/jit/docs/topics/contexts.rst   |  6 +++---
>  gcc/jit/docs/topics/objects.rst    |  6 +++---
>  13 files changed, 45 insertions(+), 45 deletions(-)
> 
> diff --git a/gcc/jit/docs/cp/intro/tutorial02.rst
> b/gcc/jit/docs/cp/intro/tutorial02.rst
> index 55675cc7398..9f9a7f3858e 100644
> --- a/gcc/jit/docs/cp/intro/tutorial02.rst
> +++ b/gcc/jit/docs/cp/intro/tutorial02.rst
> @@ -39,7 +39,7 @@ First we need to include the relevant header:
>  
>  All state associated with compilation is associated with a
>  :type:`gccjit::context`, which is a thin C++ wrapper around the C
> API's
> -:c:type:`gcc_jit_context *`.
> +:c:expr:`gcc_jit_context *`.
>  
>  Create one using :func:`gccjit::context::acquire`:
>  
> @@ -194,7 +194,7 @@ OK, we've populated the context.  We can now
> compile it using
>     gcc_jit_result *result;
>     result = ctxt.compile ();
>  
> -and get a :c:type:`gcc_jit_result *`.
> +and get a :c:expr:`gcc_jit_result *`.
>  
>  We can now use :c:func:`gcc_jit_result_get_code` to look up a
> specific
>  machine code routine within the result, in this case, the function
> we
> diff --git a/gcc/jit/docs/cp/topics/asm.rst
> b/gcc/jit/docs/cp/topics/asm.rst
> index f7e4e952b10..0d63da3d59e 100644
> --- a/gcc/jit/docs/cp/topics/asm.rst
> +++ b/gcc/jit/docs/cp/topics/asm.rst
> @@ -43,7 +43,7 @@ Adding assembler instructions within a function
>     to outputs.
>  
>     :class:`gccjit::extended_asm` is a subclass of
> :class:`gccjit::object`.
> -   It is a thin wrapper around the C API's
> :c:type:`gcc_jit_extended_asm *`.
> +   It is a thin wrapper around the C API's
> :c:expr:`gcc_jit_extended_asm *`.
>  
>     To avoid having an API entrypoint with a very large number of
>     parameters, an extended ``asm`` statement is made in stages:
> diff --git a/gcc/jit/docs/cp/topics/contexts.rst
> b/gcc/jit/docs/cp/topics/contexts.rst
> index f60f2102b3e..2f2456a9c0d 100644
> --- a/gcc/jit/docs/cp/topics/contexts.rst
> +++ b/gcc/jit/docs/cp/topics/contexts.rst
> @@ -29,9 +29,9 @@ compilation.
>  
>  You can set up options on it, and add types, functions and code.
>  Invoking :func:`gccjit::context::compile` on it gives you a
> -:c:type:`gcc_jit_result *`.
> +:c:expr:`gcc_jit_result *`.
>  
> -It is a thin wrapper around the C API's :c:type:`gcc_jit_context *`.
> +It is a thin wrapper around the C API's :c:expr:`gcc_jit_context *`.
>  
>  Lifetime-management
>  ---
> @@ -48,7 +48,7 @@ cleanup of such objects is done for you when the
> context is released.
>  .. function:: void gccjit::context::release ()
>  
>    This function releases all resources associated with the given
> context.
> -  Both the context itself and all of its :c:type:`gccjit::object *`
> +  Both the context itself and all of its :expr:`gccjit::object *`
>    instances are cleaned up.  It should be called exactly once on a
> given
>    context.
>  
> diff --git a/gcc/jit/docs/cp/topics/expressions.rst
> b/gcc/jit/docs/cp/topics/expressions.rst
> index dec5b477811..01eb2898d0d 100644
> --- a/gcc/jit/docs/cp/topics/expressions.rst
> +++ b/gcc/jit/docs/cp/topics/expressions.rst
> @@ -26,7 +26,7 @@ Rvalues
>  
>  A :class:`gccjit::rvalue` is an expression that can be computed.  It
> is a
>  subclass of :class:`gccjit::object`, and is a thin wrapper around
> -:c:type:`gcc_jit_rvalue *` from the C API.
> +:c:expr:`gcc_jit_rvalue *` from the C API.
>  
>  It can be simple, e.g.:
>  
> @@ -491,7 +491,7 @@ a storage area (such as a variable).  It is a

Re: [PATCH 5/7] jit,docs: use list-table instead of fixed table

2022-07-25 Thread David Malcolm via Gcc-patches
On Mon, 2022-07-25 at 12:35 +0200, Martin Liska wrote:
> Use rather list-table that is easible to maintainer and one
> does not have to wrap lines. Moreover, it provides great
> attribute :widths: that correctly works (tested for HTML and PDF).
> 
> gcc/jit/ChangeLog:
> 
> * docs/cp/intro/tutorial04.rst: Use list-table.
> * docs/intro/tutorial04.rst: Likewise.
> * docs/intro/tutorial05.rst: Likewise.
> * docs/topics/compilation.rst: Likewise.
> * docs/topics/expressions.rst: Likewise.
> * docs/topics/types.rst: Likewise.

OK; thanks
Dave




Re: [PATCH 4/7] jit,docs: compact function declarations

2022-07-25 Thread David Malcolm via Gcc-patches
On Mon, 2022-07-25 at 11:51 +0200, Martin Liska wrote:
> gcc/jit/ChangeLog:
> 
> * docs/cp/topics/expressions.rst: Compact so that the
> generated
> output is also more compact.

OK; thanks

Dave



Re: [PATCH 3/7] jit,docs: various fixes

2022-07-25 Thread David Malcolm via Gcc-patches
On Mon, 2022-07-25 at 11:15 +0200, Martin Liska wrote:
> gcc/jit/ChangeLog:
> 
> * docs/cp/intro/tutorial02.rst: Use proper reference.
> * docs/cp/topics/contexts.rst: Likewise.
> * docs/cp/topics/functions.rst: Put `class` directive before
> a
> function as it is not allowed declaring a class in a fn.
> * docs/cp/topics/types.rst: Add template keyword.
> * docs/examples/tut04-toyvm/toyvm.c (toyvm_function_compile):
> Add removed comment used for code snippet ending detection.
> * docs/intro/tutorial04.rst: Fix to match the real comment.

Thanks, looks good to me.

Dave



Re: [PATCH 2/7] jit,docs: replace c:type:`int_type` with :expr:`int_type`

2022-07-25 Thread David Malcolm via Gcc-patches
On Mon, 2022-07-25 at 11:03 +0200, Martin Liska wrote:
> Use expression that work fine for basic type.

What's the motivation for this change?  Surely the things being marked
up are types, rather than expressions?

Dave

> 
> gcc/jit/ChangeLog:
> 
> * docs/cp/topics/expressions.rst: Use :expr: for basic types.
> * docs/topics/compilation.rst: Likewise.
> * docs/topics/expressions.rst: Likewise.
> * docs/topics/function-pointers.rst: Likewise.
> ---
>  gcc/jit/docs/cp/topics/expressions.rst    | 6 +++---
>  gcc/jit/docs/topics/compilation.rst   | 4 ++--
>  gcc/jit/docs/topics/expressions.rst   | 6 +++---
>  gcc/jit/docs/topics/function-pointers.rst | 2 +-
>  4 files changed, 9 insertions(+), 9 deletions(-)
> 
> diff --git a/gcc/jit/docs/cp/topics/expressions.rst
> b/gcc/jit/docs/cp/topics/expressions.rst
> index 239e004371e..003dbce8991 100644
> --- a/gcc/jit/docs/cp/topics/expressions.rst
> +++ b/gcc/jit/docs/cp/topics/expressions.rst
> @@ -57,14 +57,14 @@ Simple expressions
>     int value) const
>  
>     Given a numeric type (integer or floating point), build an rvalue
> for
> -   the given constant :c:type:`int` value.
> +   the given constant :expr:`int` value.
>  
>  .. function:: gccjit::rvalue \
>    gccjit::context::new_rvalue (gccjit::type
> numeric_type, \
>     long value) const
>  
>     Given a numeric type (integer or floating point), build an rvalue
> for
> -   the given constant :c:type:`long` value.
> +   the given constant :expr:`long` value.
>  
>  .. function::  gccjit::rvalue \
>     gccjit::context::zero (gccjit::type numeric_type)
> const
> @@ -91,7 +91,7 @@ Simple expressions
>  double value) const
>  
>     Given a numeric type (integer or floating point), build an rvalue
> for
> -   the given constant :c:type:`double` value.
> +   the given constant :expr:`double` value.
>  
>  .. function:: gccjit::rvalue \
>    gccjit::context::new_rvalue (gccjit::type
> pointer_type, \
> diff --git a/gcc/jit/docs/topics/compilation.rst
> b/gcc/jit/docs/topics/compilation.rst
> index c5fa6eb0faf..91b9c2533cf 100644
> --- a/gcc/jit/docs/topics/compilation.rst
> +++ b/gcc/jit/docs/topics/compilation.rst
> @@ -98,8 +98,8 @@ In-memory compilation
>     If the global is found, the result will need to be cast to a
>     pointer of the correct type before it can be called.
>  
> -   This is a *pointer* to the global, so e.g. for an :c:type:`int`
> this is
> -   an :c:type:`int *`.
> +   This is a *pointer* to the global, so e.g. for an :expr:`int`
> this is
> +   an :expr:`int *`.
>  
>     For example, given an ``int foo;`` created this way:
>  
> diff --git a/gcc/jit/docs/topics/expressions.rst
> b/gcc/jit/docs/topics/expressions.rst
> index 49b7e14ae2b..00e2ec8cfeb 100644
> --- a/gcc/jit/docs/topics/expressions.rst
> +++ b/gcc/jit/docs/topics/expressions.rst
> @@ -60,7 +60,7 @@ Simple expressions
>     int value)
>  
>     Given a numeric type (integer or floating point), build an rvalue
> for
> -   the given constant :c:type:`int` value.
> +   the given constant :expr:`int` value.
>  
>  .. function:: gcc_jit_rvalue *\
>    gcc_jit_context_new_rvalue_from_long (gcc_jit_context
> *ctxt, \
> @@ -68,7 +68,7 @@ Simple expressions
>  long value)
>  
>     Given a numeric type (integer or floating point), build an rvalue
> for
> -   the given constant :c:type:`long` value.
> +   the given constant :expr:`long` value.
>  
>  .. function::  gcc_jit_rvalue *gcc_jit_context_zero (gcc_jit_context
> *ctxt, \
>   gcc_jit_type
> *numeric_type)
> @@ -96,7 +96,7 @@ Simple expressions
>     double value)
>  
>     Given a numeric type (integer or floating point), build an rvalue
> for
> -   the given constant :c:type:`double` value.
> +   the given constant :expr:`double` value.
>  
>  .. function:: gcc_jit_rvalue *\
>    gcc_jit_context_new_rvalue_from_ptr (gcc_jit_context
> *ctxt, \
> diff --git a/gcc/jit/docs/topics/function-pointers.rst
> b/gcc/jit/docs/topics/function-pointers.rst
> index e6f9970a7a7..dde49215853 100644
> --- a/gcc/jit/docs/topics/function-pointers.rst
> +++ b/gcc/jit/docs/topics/function-pointers.rst
> @@ -48,7 +48,7 @@ to it in :c:type:`gcc_jit_rvalue` form using
>  type obtained using :c:func:`gcc_jit_context_new_function_ptr_type`.
>  
>  Here's an example of creating a function pointer type corresponding
> to C's
> -:c:type:`void (*) (int, int, int)`:
> +:expr:`void (*) (int, int, int)`:
>  
>  .. code-block:: c
>  




Re: [PATCH 1/7] jit,docs: use enum directive for enumeral types

2022-07-25 Thread David Malcolm via Gcc-patches
On Mon, 2022-07-25 at 10:52 +0200, Martin Liska wrote:
> gcc/jit/ChangeLog:
> 
> * docs/conf.py: Add needs_sphinx = '3.0' where c:type was
> added.

Looking at the footer of https://gcc.gnu.org/onlinedocs/jit/index.html
I see we currently only have sphinx 1.7.6 installed.

Have you been talking with the gcc.gnu.org admins about bumping this
requirement?

Otherwise the patch looks OK

Dave



Re: [PATCH] match.pd: Add new division pattern [PR104992]

2022-07-25 Thread Andrew Pinski via Gcc-patches
On Mon, Jul 25, 2022 at 1:59 PM Sam Feifer  wrote:
>
>
>> I suspect for eq and mult you might want to add :c to them even though
>> in your testcase you don't need them, you might be able to get it via
>> using different statements and looking at the forwprop gimple dump.
>> Also, did you send the wrong patch as it looks like the function call
>> to build_zero_cst has been eaten ... (or is it just because TREE_TYPE
>> has parentheses inside the macro and it just accidently works :)).
>
>
> I got lucky and it works without parentheses :). I just added them in for 
> readability.
>
>> You might also want to make sure it does the right thing for vector
>> types and complex types (yes both are valid for trunc_div still).
>>
>
> I made a vector test case, but it's giving me errors when using " == " 
> between two vectors. I'm running it with the C++ front end and it's saying 
> the return value cannot be converted. Any tips for this?
>
> I'm not sure exactly what you mean by "complex types" in terms of testing 
> this patch. Could I get an example?

int f(_Complex int x, _Complex int y)
{
  return x == x / y * y;
}

For vector try (which works for both the C and C++ front-end):
#define vector __attribute__((vector_size(4*sizeof(int)) ))
vector int f(vector int x, vector int y)
{
  return x == x / y * y;
}

That is for the vector case, == still returns a vector type.

Thanks,
Andrew Pinski

>
> Thanks
> -Sam
>
>> Thanks,
>> Andrew Pinski
>>
>> > diff --git a/gcc/testsuite/gcc.dg/pr104992-1.c 
>> > b/gcc/testsuite/gcc.dg/pr104992-1.c
>> > new file mode 100644
>> > index 000..a80e5e180ce
>> > --- /dev/null
>> > +++ b/gcc/testsuite/gcc.dg/pr104992-1.c
>> > @@ -0,0 +1,30 @@
>> > +/* PR tree-optimization/104992 */
>> > +/* { dg-do run } */
>> > +/* { dg-options "-O2"} */
>> > +
>> > +#include "pr104992.c"
>> > +
>> > +int main () {
>> > +
>> > +/* Should be true.  */
>> > +if (!foo(6, 3)
>> > +|| !bar(12, 2)
>> > +|| !baz(34, 17)
>> > +|| !qux(50, 10)
>> > +|| !fred(16, 8)
>> > +|| !baz(-9, 3)
>> > +|| !baz(9, -3)
>> > +|| !baz(-9, -3)
>> > +) {
>> > +__builtin_abort();
>> > + }
>> > +
>> > +/* Should be false.  */
>> > +if (foo(5, 30)
>> > +|| bar(72, 27)
>> > +|| baz(42, 15)) {
>> > +__builtin_abort();
>> > +}
>> > +
>> > +return 0;
>> > +}
>> > diff --git a/gcc/testsuite/gcc.dg/pr104992.c 
>> > b/gcc/testsuite/gcc.dg/pr104992.c
>> > new file mode 100644
>> > index 000..b4b0ca53118
>> > --- /dev/null
>> > +++ b/gcc/testsuite/gcc.dg/pr104992.c
>> > @@ -0,0 +1,35 @@
>> > +/* PR tree-optimization/104992 */
>> > +/* { dg-do compile } */
>> > +/* { dg-options "-O2 -fdump-tree-optimized" } */
>> > +
>> > +/* Form from PR.  */
>> > +__attribute__((noipa)) unsigned foo(unsigned x, unsigned y)
>> > +{
>> > +return x / y * y == x;
>> > +}
>> > +
>> > +__attribute__((noipa)) unsigned bar(unsigned x, unsigned y) {
>> > +return x == x / y * y;
>> > +}
>> > +
>> > +/* Signed test case.  */
>> > +__attribute__((noipa)) unsigned baz (int x, int y) {
>> > +return x / y * y == x;
>> > +}
>> > +
>> > +/* Changed order.  */
>> > +__attribute__((noipa)) unsigned qux (unsigned x, unsigned y) {
>> > +return y * (x / y) == x;
>> > +}
>> > +
>> > +/* Wrong order.  */
>> > +__attribute__((noipa)) unsigned fred (unsigned x, unsigned y) {
>> > +return y * x / y == x;
>> > +}
>> > +
>> > +/* Wrong pattern.  */
>> > +__attribute__((noipa)) unsigned waldo (unsigned x, unsigned y, unsigned 
>> > z) {
>> > +return x / y * z == x;
>> > +}
>> > +
>> > +/* { dg-final {scan-tree-dump-times " % " 4 "optimized" } } */
>> >
>> > base-commit: 633e9920589ddfaf2d6da1c24ce99b18a2638db4
>> > --
>> > 2.31.1
>> >
>>


Re: [PATCH] match.pd: Add new division pattern [PR104992]

2022-07-25 Thread Sam Feifer via Gcc-patches
> I suspect for eq and mult you might want to add :c to them even though
> in your testcase you don't need them, you might be able to get it via
> using different statements and looking at the forwprop gimple dump.
> Also, did you send the wrong patch as it looks like the function call
> to build_zero_cst has been eaten ... (or is it just because TREE_TYPE
> has parentheses inside the macro and it just accidently works :)).
>

I got lucky and it works without parentheses :). I just added them in for
readability.

You might also want to make sure it does the right thing for vector
> types and complex types (yes both are valid for trunc_div still).
>
>
I made a vector test case, but it's giving me errors when using " == "
between two vectors. I'm running it with the C++ front end and it's saying
the return value cannot be converted. Any tips for this?

I'm not sure exactly what you mean by "complex types" in terms of testing
this patch. Could I get an example?

Thanks
-Sam

Thanks,
> Andrew Pinski
>
> > diff --git a/gcc/testsuite/gcc.dg/pr104992-1.c
> b/gcc/testsuite/gcc.dg/pr104992-1.c
> > new file mode 100644
> > index 000..a80e5e180ce
> > --- /dev/null
> > +++ b/gcc/testsuite/gcc.dg/pr104992-1.c
> > @@ -0,0 +1,30 @@
> > +/* PR tree-optimization/104992 */
> > +/* { dg-do run } */
> > +/* { dg-options "-O2"} */
> > +
> > +#include "pr104992.c"
> > +
> > +int main () {
> > +
> > +/* Should be true.  */
> > +if (!foo(6, 3)
> > +|| !bar(12, 2)
> > +|| !baz(34, 17)
> > +|| !qux(50, 10)
> > +|| !fred(16, 8)
> > +|| !baz(-9, 3)
> > +|| !baz(9, -3)
> > +|| !baz(-9, -3)
> > +) {
> > +__builtin_abort();
> > + }
> > +
> > +/* Should be false.  */
> > +if (foo(5, 30)
> > +|| bar(72, 27)
> > +|| baz(42, 15)) {
> > +__builtin_abort();
> > +}
> > +
> > +return 0;
> > +}
> > diff --git a/gcc/testsuite/gcc.dg/pr104992.c
> b/gcc/testsuite/gcc.dg/pr104992.c
> > new file mode 100644
> > index 000..b4b0ca53118
> > --- /dev/null
> > +++ b/gcc/testsuite/gcc.dg/pr104992.c
> > @@ -0,0 +1,35 @@
> > +/* PR tree-optimization/104992 */
> > +/* { dg-do compile } */
> > +/* { dg-options "-O2 -fdump-tree-optimized" } */
> > +
> > +/* Form from PR.  */
> > +__attribute__((noipa)) unsigned foo(unsigned x, unsigned y)
> > +{
> > +return x / y * y == x;
> > +}
> > +
> > +__attribute__((noipa)) unsigned bar(unsigned x, unsigned y) {
> > +return x == x / y * y;
> > +}
> > +
> > +/* Signed test case.  */
> > +__attribute__((noipa)) unsigned baz (int x, int y) {
> > +return x / y * y == x;
> > +}
> > +
> > +/* Changed order.  */
> > +__attribute__((noipa)) unsigned qux (unsigned x, unsigned y) {
> > +return y * (x / y) == x;
> > +}
> > +
> > +/* Wrong order.  */
> > +__attribute__((noipa)) unsigned fred (unsigned x, unsigned y) {
> > +return y * x / y == x;
> > +}
> > +
> > +/* Wrong pattern.  */
> > +__attribute__((noipa)) unsigned waldo (unsigned x, unsigned y, unsigned
> z) {
> > +return x / y * z == x;
> > +}
> > +
> > +/* { dg-final {scan-tree-dump-times " % " 4 "optimized" } } */
> >
> > base-commit: 633e9920589ddfaf2d6da1c24ce99b18a2638db4
> > --
> > 2.31.1
> >
>
>


[PATCH] Fortran: error recovery from calculation of storage size of a symbol [PR103504]

2022-07-25 Thread Harald Anlauf via Gcc-patches
Dear all,

we currently may ICE when array bounds of a dummy argument have
a non-integer type, and the procedure with the bad declaration is
referenced.  The same applies to bad character length of dummies.
We could simply punt in such a situation, as the causing error
seems to be reliably diagnosed, see testcase.

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

This is a really safe fix and potentially backportable to other
open branches.  Would that be fine?

Thanks,
Harald

From 04bea97afd7f17083774b4309ee4d3c45e278dd3 Mon Sep 17 00:00:00 2001
From: Harald Anlauf 
Date: Mon, 25 Jul 2022 22:29:50 +0200
Subject: [PATCH] Fortran: error recovery from calculation of storage size of a
 symbol [PR103504]

gcc/fortran/ChangeLog:

	PR fortran/103504
	* interface.cc (get_sym_storage_size): Array bounds and character
	length can only be of integer type.

gcc/testsuite/ChangeLog:

	PR fortran/103504
	* gfortran.dg/pr103504.f90: New test.
---
 gcc/fortran/interface.cc   |  7 +--
 gcc/testsuite/gfortran.dg/pr103504.f90 | 28 ++
 2 files changed, 33 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/gfortran.dg/pr103504.f90

diff --git a/gcc/fortran/interface.cc b/gcc/fortran/interface.cc
index 7ed6e13711f..71eec78259b 100644
--- a/gcc/fortran/interface.cc
+++ b/gcc/fortran/interface.cc
@@ -2792,7 +2792,8 @@ get_sym_storage_size (gfc_symbol *sym)
   if (sym->ts.type == BT_CHARACTER)
 {
   if (sym->ts.u.cl && sym->ts.u.cl->length
-  && sym->ts.u.cl->length->expr_type == EXPR_CONSTANT)
+	  && sym->ts.u.cl->length->expr_type == EXPR_CONSTANT
+	  && sym->ts.u.cl->length->ts.type == BT_INTEGER)
 	strlen = mpz_get_ui (sym->ts.u.cl->length->value.integer);
   else
 	return 0;
@@ -2809,7 +2810,9 @@ get_sym_storage_size (gfc_symbol *sym)
   for (i = 0; i < sym->as->rank; i++)
 {
   if (sym->as->upper[i]->expr_type != EXPR_CONSTANT
-	  || sym->as->lower[i]->expr_type != EXPR_CONSTANT)
+	  || sym->as->lower[i]->expr_type != EXPR_CONSTANT
+	  || sym->as->upper[i]->ts.type != BT_INTEGER
+	  || sym->as->lower[i]->ts.type != BT_INTEGER)
 	return 0;

   elements *= mpz_get_si (sym->as->upper[i]->value.integer)
diff --git a/gcc/testsuite/gfortran.dg/pr103504.f90 b/gcc/testsuite/gfortran.dg/pr103504.f90
new file mode 100644
index 000..607d1c6c8cc
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr103504.f90
@@ -0,0 +1,28 @@
+! { dg-do compile }
+! PR fortran/103504 - ICE in get_sym_storage_size, at fortran/interface.c:2800
+! Contributed by G.Steinmetz
+
+program p
+  implicit none
+  real  :: y(1)
+  character :: b
+  call s(y)
+  call t(y)
+  call u(y)
+  call c(b)
+contains
+  subroutine s(x)
+real :: x(abs(1.):1)! { dg-error "must be of INTEGER type" }
+  end
+  subroutine t(x)
+real :: x(abs(1.):1)! { dg-error "must be of INTEGER type" }
+  end
+  subroutine u(x)
+real :: x(1:abs(1.))! { dg-error "must be of INTEGER type" }
+  end
+  subroutine c(z)
+character(len=abs(1.)) :: z ! { dg-error "must be of INTEGER type" }
+  end subroutine c
+end
+
+! { dg-prune-output "must be of INTEGER type" }
--
2.35.3



Re: [PATCH] Fortran: fix invalid rank error in ASSOCIATED when rank is remapped [PR77652]

2022-07-25 Thread Harald Anlauf via Gcc-patches
Hi Mikael,

> > https://community.intel.com/t5/Intel-Fortran-Compiler/Intel-rejects-ASSOCIATED-pointer-target-for-non-equal-ranks/m-p/1402799/highlight/true#M162159
> > 
> 
> I disagree with the conclusion.  Quoting Steve Lionel’s post:
> > What you're missing is this:
> > 
> > TARGET (optional) shall be allowable as the data-target or proc-target in a 
> > pointer assignment statement (10.2.2) in which POINTER is 
> > data-pointer-object or proc-pointer-object.
> > 
> > We then go to 10.2.2 which says (emphasis mine):
> > 
> > C1019 (R1033) If bounds-remapping-list is not specified, the ranks of 
> > data-pointer-object and data-target shall be the same.
> > 
> > So... not valid Fortran 2018.
> 
> except, that there is also this:
> > C1018 (R1033) If bounds-remapping-list is specified, the number of 
> > bounds-remappings shall equal the rank of data-pointer-object.
> which practically imposes no conformance rule between 
> data-pointer-object and data-target.

this is also why I initially thought that rank remapping is fine.

> Note that in the syntax definition, bounds-remapping-list is not part of 
> data-pointer-object.  In other words, by collating a 
> bounds-remapping-list next to POINTER, one can construct an allowable 
> pointer assignment from TARGET to POINTER, which satisfies the 
> requirement, even if TARGET and POINTER don’t have the same rank.

I fully agree with you here.

My current state of - sort-of - knowledge:

- Crayftn 14.0 allows for rank remapping, accepts code the way you describe,
  including assumed-rank for the POINTER argument.

- Nvidia 22.5 allows for rank remapping, but does not handle assumed-rank.

- NAG 7.1 is said to reject non-equal rank.  NAG 7.0 does not accept it.

- Intel rejects non-equal rank.  Steve Lionel even thinks that assumed-rank
  should not be allowed here.  I believe he is wrong here.

I would normally trust NAG more than Intel and Cray.  If somebody else convinces
me to accept that NAG has it wrong this time, I would be happy to proceed.

Apart from the above discussion about what the compiler should accept,
the library side of gfortran seems to be fine...  :-)

Harald



[PATCH, V2] Do not enable -mblock-ops-vector-pair.

2022-07-25 Thread Michael Meissner via Gcc-patches
Do not enable -mblock-ops-vector-pair.

Testing has shown that using the load vector pair and store vector pair
instructions for block moves has some performance issues on power10.

A patch on June 11th modified the code so that GCC would not set
-mblock-ops-vector-pair by default if we are tuning for power10, but it
would set the option if we were tuning for a different machine and have
load and store vector pair instructions enabled.

This patch eliminates the code setting -mblock-ops-vector-pair.  If you
want to generate load vector pair and store vector pair instructions for
block moves, you must use -mblock-ops-vector-pair.

2022-07-25   Michael Meissner  

gcc/

* config/rs6000/rs6000.cc (rs6000_option_override_internal): Remove
code setting -mblock-ops-vector-pair.

---
 gcc/config/rs6000/rs6000.cc | 11 ---
 1 file changed, 11 deletions(-)

diff --git a/gcc/config/rs6000/rs6000.cc b/gcc/config/rs6000/rs6000.cc
index 3ff16b8ae04..667f83b1dfd 100644
--- a/gcc/config/rs6000/rs6000.cc
+++ b/gcc/config/rs6000/rs6000.cc
@@ -4139,17 +4139,6 @@ rs6000_option_override_internal (bool global_init_p)
rs6000_isa_flags &= ~OPTION_MASK_BLOCK_OPS_UNALIGNED_VSX;
 }
 
-  if (!(rs6000_isa_flags_explicit & OPTION_MASK_BLOCK_OPS_VECTOR_PAIR))
-{
-  /* Do not generate lxvp and stxvp on power10 since there are some
-performance issues.  */
-  if (TARGET_MMA && TARGET_EFFICIENT_UNALIGNED_VSX
- && rs6000_tune != PROCESSOR_POWER10)
-   rs6000_isa_flags |= OPTION_MASK_BLOCK_OPS_VECTOR_PAIR;
-  else
-   rs6000_isa_flags &= ~OPTION_MASK_BLOCK_OPS_VECTOR_PAIR;
-}
-
   /* Use long double size to select the appropriate long double.  We use
  TYPE_PRECISION to differentiate the 3 different long double types.  We map
  128 into the precision used for TFmode.  */
-- 
2.35.3


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


Re: [PATCH] match.pd: Add new division pattern [PR104992]

2022-07-25 Thread Andrew Pinski via Gcc-patches
On Mon, Jul 25, 2022 at 12:37 PM Sam Feifer via Gcc-patches
 wrote:
>
> This patch fixes a missed optimization in match.pd. It takes the pattern, x / 
> y * y == x, and optimizes it to x % y == 0. This produces fewer instructions.
>
> There are also tests for the optimizations to be added to the test suite.
>
> Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
>
> PR tree-optimization/104992
>
> gcc/ChangeLog:
>
> * match.pd x / y * y == x: New simplification.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.dg/pr104992-1.c: New test.
> * gcc.dg/pr104992.c: New test.
> ---
>  gcc/match.pd  |  5 +
>  gcc/testsuite/gcc.dg/pr104992-1.c | 30 ++
>  gcc/testsuite/gcc.dg/pr104992.c   | 35 +++
>  3 files changed, 70 insertions(+)
>  create mode 100644 gcc/testsuite/gcc.dg/pr104992-1.c
>  create mode 100644 gcc/testsuite/gcc.dg/pr104992.c
>
> diff --git a/gcc/match.pd b/gcc/match.pd
> index 9736393061a..f7ab2174b8a 100644
> --- a/gcc/match.pd
> +++ b/gcc/match.pd
> @@ -8054,3 +8054,8 @@ and,
>(if (TYPE_UNSIGNED (TREE_TYPE (@0)))
>  (bit_and @0 @1)
>(cond (le @0 @1) @0 (bit_and @0 @1))
> +
> +/* x / y * y == x -> x % y == 0.  */
> +(simplify
> +  (eq (mult (trunc_div @0 @1) @1) @0)
> +  (eq (trunc_mod @0 @1) { build_zero_cst TREE_TYPE(@0); }))

I suspect for eq and mult you might want to add :c to them even though
in your testcase you don't need them, you might be able to get it via
using different statements and looking at the forwprop gimple dump.
Also, did you send the wrong patch as it looks like the function call
to build_zero_cst has been eaten ... (or is it just because TREE_TYPE
has parentheses inside the macro and it just accidently works :)).

You might also want to make sure it does the right thing for vector
types and complex types (yes both are valid for trunc_div still).

Thanks,
Andrew Pinski

> diff --git a/gcc/testsuite/gcc.dg/pr104992-1.c 
> b/gcc/testsuite/gcc.dg/pr104992-1.c
> new file mode 100644
> index 000..a80e5e180ce
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/pr104992-1.c
> @@ -0,0 +1,30 @@
> +/* PR tree-optimization/104992 */
> +/* { dg-do run } */
> +/* { dg-options "-O2"} */
> +
> +#include "pr104992.c"
> +
> +int main () {
> +
> +/* Should be true.  */
> +if (!foo(6, 3)
> +|| !bar(12, 2)
> +|| !baz(34, 17)
> +|| !qux(50, 10)
> +|| !fred(16, 8)
> +|| !baz(-9, 3)
> +|| !baz(9, -3)
> +|| !baz(-9, -3)
> +) {
> +__builtin_abort();
> + }
> +
> +/* Should be false.  */
> +if (foo(5, 30)
> +|| bar(72, 27)
> +|| baz(42, 15)) {
> +__builtin_abort();
> +}
> +
> +return 0;
> +}
> diff --git a/gcc/testsuite/gcc.dg/pr104992.c b/gcc/testsuite/gcc.dg/pr104992.c
> new file mode 100644
> index 000..b4b0ca53118
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/pr104992.c
> @@ -0,0 +1,35 @@
> +/* PR tree-optimization/104992 */
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -fdump-tree-optimized" } */
> +
> +/* Form from PR.  */
> +__attribute__((noipa)) unsigned foo(unsigned x, unsigned y)
> +{
> +return x / y * y == x;
> +}
> +
> +__attribute__((noipa)) unsigned bar(unsigned x, unsigned y) {
> +return x == x / y * y;
> +}
> +
> +/* Signed test case.  */
> +__attribute__((noipa)) unsigned baz (int x, int y) {
> +return x / y * y == x;
> +}
> +
> +/* Changed order.  */
> +__attribute__((noipa)) unsigned qux (unsigned x, unsigned y) {
> +return y * (x / y) == x;
> +}
> +
> +/* Wrong order.  */
> +__attribute__((noipa)) unsigned fred (unsigned x, unsigned y) {
> +return y * x / y == x;
> +}
> +
> +/* Wrong pattern.  */
> +__attribute__((noipa)) unsigned waldo (unsigned x, unsigned y, unsigned z) {
> +return x / y * z == x;
> +}
> +
> +/* { dg-final {scan-tree-dump-times " % " 4 "optimized" } } */
>
> base-commit: 633e9920589ddfaf2d6da1c24ce99b18a2638db4
> --
> 2.31.1
>


[PATCH] match.pd: Add new division pattern [PR104992]

2022-07-25 Thread Sam Feifer via Gcc-patches
This patch fixes a missed optimization in match.pd. It takes the pattern, x / y 
* y == x, and optimizes it to x % y == 0. This produces fewer instructions.

There are also tests for the optimizations to be added to the test suite.

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

PR tree-optimization/104992

gcc/ChangeLog:

* match.pd x / y * y == x: New simplification.

gcc/testsuite/ChangeLog:

* gcc.dg/pr104992-1.c: New test.
* gcc.dg/pr104992.c: New test.
---
 gcc/match.pd  |  5 +
 gcc/testsuite/gcc.dg/pr104992-1.c | 30 ++
 gcc/testsuite/gcc.dg/pr104992.c   | 35 +++
 3 files changed, 70 insertions(+)
 create mode 100644 gcc/testsuite/gcc.dg/pr104992-1.c
 create mode 100644 gcc/testsuite/gcc.dg/pr104992.c

diff --git a/gcc/match.pd b/gcc/match.pd
index 9736393061a..f7ab2174b8a 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -8054,3 +8054,8 @@ and,
   (if (TYPE_UNSIGNED (TREE_TYPE (@0)))
 (bit_and @0 @1)
   (cond (le @0 @1) @0 (bit_and @0 @1))
+
+/* x / y * y == x -> x % y == 0.  */
+(simplify
+  (eq (mult (trunc_div @0 @1) @1) @0)
+  (eq (trunc_mod @0 @1) { build_zero_cst TREE_TYPE(@0); }))
diff --git a/gcc/testsuite/gcc.dg/pr104992-1.c 
b/gcc/testsuite/gcc.dg/pr104992-1.c
new file mode 100644
index 000..a80e5e180ce
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr104992-1.c
@@ -0,0 +1,30 @@
+/* PR tree-optimization/104992 */
+/* { dg-do run } */
+/* { dg-options "-O2"} */
+
+#include "pr104992.c"
+
+int main () {
+
+/* Should be true.  */
+if (!foo(6, 3)
+|| !bar(12, 2)
+|| !baz(34, 17)
+|| !qux(50, 10)
+|| !fred(16, 8)
+|| !baz(-9, 3)
+|| !baz(9, -3)
+|| !baz(-9, -3)
+) {
+__builtin_abort();
+ }
+
+/* Should be false.  */
+if (foo(5, 30)
+|| bar(72, 27)
+|| baz(42, 15)) {
+__builtin_abort();
+}
+
+return 0;
+}
diff --git a/gcc/testsuite/gcc.dg/pr104992.c b/gcc/testsuite/gcc.dg/pr104992.c
new file mode 100644
index 000..b4b0ca53118
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr104992.c
@@ -0,0 +1,35 @@
+/* PR tree-optimization/104992 */
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-optimized" } */
+
+/* Form from PR.  */
+__attribute__((noipa)) unsigned foo(unsigned x, unsigned y)
+{
+return x / y * y == x;
+}
+
+__attribute__((noipa)) unsigned bar(unsigned x, unsigned y) {
+return x == x / y * y;
+}
+
+/* Signed test case.  */
+__attribute__((noipa)) unsigned baz (int x, int y) {
+return x / y * y == x;
+}
+
+/* Changed order.  */
+__attribute__((noipa)) unsigned qux (unsigned x, unsigned y) {
+return y * (x / y) == x;
+}
+
+/* Wrong order.  */
+__attribute__((noipa)) unsigned fred (unsigned x, unsigned y) {
+return y * x / y == x;
+}
+
+/* Wrong pattern.  */
+__attribute__((noipa)) unsigned waldo (unsigned x, unsigned y, unsigned z) {
+return x / y * z == x;
+}
+
+/* { dg-final {scan-tree-dump-times " % " 4 "optimized" } } */

base-commit: 633e9920589ddfaf2d6da1c24ce99b18a2638db4
-- 
2.31.1



Re: [RFA] Implement basic range operators to enable floating point VRP.

2022-07-25 Thread Aldy Hernandez via Gcc-patches
I forgot to mention.  There's a regression in g++.dg/opt/pr94589-2.C,
where an early optimization by evrp causes phiopt to no longer
optimize a spaceship operator because it no longer sees the exact
sequence of conditionals.  I have included the analysis in the patch.
Hopefully a phiopt expert can opine.

Aldy

On Mon, Jul 25, 2022 at 8:50 PM Aldy Hernandez  wrote:
>
> Without further ado, here is the implementation for floating point
> range operators, plus the switch to enable all ranger clients to
> handle floats.
>
> These are bare bone implementations good enough for relation operators
> to work, while keeping the NAN bits up to date in the frange.  There
> is also minimal support for keeping track of +-INF when it is obvious.
>
> I have included some basic tests to help get a feel of what is
> ultimately handled.
>
> Since range-ops is the domain specific core of ranger, I think its
> best if a global maintainer or an FP expert could review this.
>
> OK for trunk?
>
> Tested on x86-64 Linux.
>
> p.s. I haven't done extensive testing in DOM, but with this we're mighty
> close for the forward threader there to be replaceable with the backward
> threader, thus removing the last use of the forward threader.
>
> gcc/ChangeLog:
>
> * range-op-float.cc (finite_operands_p): New.
> (frelop_early_resolve): New.
> (default_frelop_fold_range): New.
> (class foperator_equal): New.
> (class foperator_not_equal): New.
> (class foperator_lt): New.
> (class foperator_le): New.
> (class foperator_gt): New.
> (class foperator_ge): New.
> (class foperator_unordered): New.
> (class foperator_ordered): New.
> (class foperator_relop_unknown): New.
> (floating_op_table::floating_op_table): Add above classes to
> floating op table.
> * value-range.h (frange::supports_p): Enable.
>
> gcc/testsuite/ChangeLog:
>
> * g++.dg/opt/pr94589-2.C: Add notes.
> * gcc.dg/tree-ssa/vrp-float-1.c: New test.
> * gcc.dg/tree-ssa/vrp-float-11.c: New test.
> * gcc.dg/tree-ssa/vrp-float-3.c: New test.
> * gcc.dg/tree-ssa/vrp-float-4.c: New test.
> * gcc.dg/tree-ssa/vrp-float-6.c: New test.
> * gcc.dg/tree-ssa/vrp-float-7.c: New test.
> * gcc.dg/tree-ssa/vrp-float-8.c: New test.
> ---
>  gcc/range-op-float.cc| 564 +++
>  gcc/testsuite/g++.dg/opt/pr94589-2.C |  25 +
>  gcc/testsuite/gcc.dg/tree-ssa/vrp-float-1.c  |  19 +
>  gcc/testsuite/gcc.dg/tree-ssa/vrp-float-11.c |  26 +
>  gcc/testsuite/gcc.dg/tree-ssa/vrp-float-3.c  |  18 +
>  gcc/testsuite/gcc.dg/tree-ssa/vrp-float-4.c  |  16 +
>  gcc/testsuite/gcc.dg/tree-ssa/vrp-float-6.c  |  20 +
>  gcc/testsuite/gcc.dg/tree-ssa/vrp-float-7.c  |  14 +
>  gcc/testsuite/gcc.dg/tree-ssa/vrp-float-8.c  |  26 +
>  gcc/value-range.h|   3 +-
>  10 files changed, 729 insertions(+), 2 deletions(-)
>  create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/vrp-float-1.c
>  create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/vrp-float-11.c
>  create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/vrp-float-3.c
>  create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/vrp-float-4.c
>  create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/vrp-float-6.c
>  create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/vrp-float-7.c
>  create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/vrp-float-8.c
>
> diff --git a/gcc/range-op-float.cc b/gcc/range-op-float.cc
> index 8e9d83e3827..d94ff6f915a 100644
> --- a/gcc/range-op-float.cc
> +++ b/gcc/range-op-float.cc
> @@ -150,6 +150,50 @@ range_operator_float::op1_op2_relation (const irange 
>  ATTRIBUTE_UNUSED) cons
>return VREL_VARYING;
>  }
>
> +// Return TRUE if OP1 and OP2 are known to be free of NANs.
> +
> +static inline bool
> +finite_operands_p (const frange , const frange )
> +{
> +  return (flag_finite_math_only
> + || (op1.get_nan ().no_p ()
> + && op2.get_nan ().no_p ()));
> +}
> +
> +// Floating version of relop_early_resolve that takes into account NAN
> +// and -ffinite-math-only.
> +
> +inline bool
> +frelop_early_resolve (irange , tree type,
> + const frange , const frange ,
> + relation_kind rel, relation_kind my_rel)
> +{
> +  // If either operand is undefined, return VARYING.
> +  if (empty_range_varying (r, type, op1, op2))
> +return true;
> +
> +  // We can fold relations from the oracle when we know both operands
> +  // are free of NANs, or when -ffinite-math-only.
> +  return (finite_operands_p (op1, op2)
> + && relop_early_resolve (r, type, op1, op2, rel, my_rel));
> +}
> +
> +// Default implementation of fold_range for relational operators.
> +// This amounts to passing on any known relations from the oracle, iff
> +// we know the operands are not NAN or -ffinite-math-only holds.
> +
> +static inline bool
> +default_frelop_fold_range (irange , tree type,
> +  

[RFA] Implement basic range operators to enable floating point VRP.

2022-07-25 Thread Aldy Hernandez via Gcc-patches
Without further ado, here is the implementation for floating point
range operators, plus the switch to enable all ranger clients to
handle floats.

These are bare bone implementations good enough for relation operators
to work, while keeping the NAN bits up to date in the frange.  There
is also minimal support for keeping track of +-INF when it is obvious.

I have included some basic tests to help get a feel of what is
ultimately handled.

Since range-ops is the domain specific core of ranger, I think its
best if a global maintainer or an FP expert could review this.

OK for trunk?

Tested on x86-64 Linux.

p.s. I haven't done extensive testing in DOM, but with this we're mighty
close for the forward threader there to be replaceable with the backward
threader, thus removing the last use of the forward threader.

gcc/ChangeLog:

* range-op-float.cc (finite_operands_p): New.
(frelop_early_resolve): New.
(default_frelop_fold_range): New.
(class foperator_equal): New.
(class foperator_not_equal): New.
(class foperator_lt): New.
(class foperator_le): New.
(class foperator_gt): New.
(class foperator_ge): New.
(class foperator_unordered): New.
(class foperator_ordered): New.
(class foperator_relop_unknown): New.
(floating_op_table::floating_op_table): Add above classes to
floating op table.
* value-range.h (frange::supports_p): Enable.

gcc/testsuite/ChangeLog:

* g++.dg/opt/pr94589-2.C: Add notes.
* gcc.dg/tree-ssa/vrp-float-1.c: New test.
* gcc.dg/tree-ssa/vrp-float-11.c: New test.
* gcc.dg/tree-ssa/vrp-float-3.c: New test.
* gcc.dg/tree-ssa/vrp-float-4.c: New test.
* gcc.dg/tree-ssa/vrp-float-6.c: New test.
* gcc.dg/tree-ssa/vrp-float-7.c: New test.
* gcc.dg/tree-ssa/vrp-float-8.c: New test.
---
 gcc/range-op-float.cc| 564 +++
 gcc/testsuite/g++.dg/opt/pr94589-2.C |  25 +
 gcc/testsuite/gcc.dg/tree-ssa/vrp-float-1.c  |  19 +
 gcc/testsuite/gcc.dg/tree-ssa/vrp-float-11.c |  26 +
 gcc/testsuite/gcc.dg/tree-ssa/vrp-float-3.c  |  18 +
 gcc/testsuite/gcc.dg/tree-ssa/vrp-float-4.c  |  16 +
 gcc/testsuite/gcc.dg/tree-ssa/vrp-float-6.c  |  20 +
 gcc/testsuite/gcc.dg/tree-ssa/vrp-float-7.c  |  14 +
 gcc/testsuite/gcc.dg/tree-ssa/vrp-float-8.c  |  26 +
 gcc/value-range.h|   3 +-
 10 files changed, 729 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/vrp-float-1.c
 create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/vrp-float-11.c
 create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/vrp-float-3.c
 create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/vrp-float-4.c
 create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/vrp-float-6.c
 create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/vrp-float-7.c
 create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/vrp-float-8.c

diff --git a/gcc/range-op-float.cc b/gcc/range-op-float.cc
index 8e9d83e3827..d94ff6f915a 100644
--- a/gcc/range-op-float.cc
+++ b/gcc/range-op-float.cc
@@ -150,6 +150,50 @@ range_operator_float::op1_op2_relation (const irange  
ATTRIBUTE_UNUSED) cons
   return VREL_VARYING;
 }
 
+// Return TRUE if OP1 and OP2 are known to be free of NANs.
+
+static inline bool
+finite_operands_p (const frange , const frange )
+{
+  return (flag_finite_math_only
+ || (op1.get_nan ().no_p ()
+ && op2.get_nan ().no_p ()));
+}
+
+// Floating version of relop_early_resolve that takes into account NAN
+// and -ffinite-math-only.
+
+inline bool
+frelop_early_resolve (irange , tree type,
+ const frange , const frange ,
+ relation_kind rel, relation_kind my_rel)
+{
+  // If either operand is undefined, return VARYING.
+  if (empty_range_varying (r, type, op1, op2))
+return true;
+
+  // We can fold relations from the oracle when we know both operands
+  // are free of NANs, or when -ffinite-math-only.
+  return (finite_operands_p (op1, op2)
+ && relop_early_resolve (r, type, op1, op2, rel, my_rel));
+}
+
+// Default implementation of fold_range for relational operators.
+// This amounts to passing on any known relations from the oracle, iff
+// we know the operands are not NAN or -ffinite-math-only holds.
+
+static inline bool
+default_frelop_fold_range (irange , tree type,
+ const frange , const frange ,
+ relation_kind rel, relation_kind my_rel)
+{
+  if (frelop_early_resolve (r, type, op1, op2, rel, my_rel))
+return true;
+
+  r.set_varying (type);
+  return true;
+}
+
 class foperator_identity : public range_operator_float
 {
   using range_operator_float::fold_range;
@@ -172,6 +216,509 @@ class foperator_identity : public range_operator_float
 public:
 } fop_identity;
 
+class foperator_equal : public range_operator_float
+{
+  using range_operator_float::fold_range;
+  using 

[v2 PATCH] c++: ICE with erroneous template redeclaration [PR106311]

2022-07-25 Thread Marek Polacek via Gcc-patches
On Fri, Jul 22, 2022 at 05:21:58PM -0400, Jason Merrill wrote:
> On 7/15/22 11:29, Marek Polacek wrote:
> > Here we ICE trying to get DECL_SOURCE_LOCATION of the parm that happens
> > to be error_mark_node in this ill-formed test.  I kept running into this
> > while reducing code, so it'd be good to have it fixed.
> > 
> > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> > 
> > PR c++/106311
> > 
> > gcc/cp/ChangeLog:
> > 
> > * pt.cc (redeclare_class_template): Check DECL_P before accessing
> > DECL_SOURCE_LOCATION.
> > 
> > gcc/testsuite/ChangeLog:
> > 
> > * g++.dg/template/redecl5.C: New test.
> > ---
> >   gcc/cp/pt.cc| 3 ++-
> >   gcc/testsuite/g++.dg/template/redecl5.C | 5 +
> >   2 files changed, 7 insertions(+), 1 deletion(-)
> >   create mode 100644 gcc/testsuite/g++.dg/template/redecl5.C
> > 
> > diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
> > index 718dfa5bfa8..0a294e91a79 100644
> > --- a/gcc/cp/pt.cc
> > +++ b/gcc/cp/pt.cc
> > @@ -6377,7 +6377,8 @@ redeclare_class_template (tree type, tree parms, tree 
> > cons)
> > {
> >   auto_diagnostic_group d;
> >   error ("template parameter %q+#D", tmpl_parm);
> > - inform (DECL_SOURCE_LOCATION (parm), "redeclared here as %q#D", parm);
> > + inform (DECL_P (parm) ? DECL_SOURCE_LOCATION (parm) : input_location,
> > + "redeclared here as %q#D", parm);
> 
> If we're checking DECL_P, probably we also should avoid passing it to %q#D
> if it's false?

Right, I suppose printing "" isn't all that helpful.  How about
this?

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

-- >8 --
Here we ICE trying to get DECL_SOURCE_LOCATION of the parm that happens
to be error_mark_node in this ill-formed test.  I kept running into this
while reducing code, so it'd be good to have it fixed.

PR c++/106311

gcc/cp/ChangeLog:

* pt.cc (redeclare_class_template): Check DECL_P before accessing
DECL_SOURCE_LOCATION.

gcc/testsuite/ChangeLog:

* g++.dg/template/redecl5.C: New test.
---
 gcc/cp/pt.cc| 5 -
 gcc/testsuite/g++.dg/template/redecl5.C | 5 +
 2 files changed, 9 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/g++.dg/template/redecl5.C

diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
index c415db304c9..6c581fe0fb7 100644
--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -6377,7 +6377,10 @@ redeclare_class_template (tree type, tree parms, tree 
cons)
{
  auto_diagnostic_group d;
  error ("template parameter %q+#D", tmpl_parm);
- inform (DECL_SOURCE_LOCATION (parm), "redeclared here as %q#D", parm);
+ if (DECL_P (parm))
+   inform (DECL_SOURCE_LOCATION (parm), "redeclared here as %q#D", 
parm);
+ else
+   inform (input_location, "redeclared here");
  return false;
}
 
diff --git a/gcc/testsuite/g++.dg/template/redecl5.C 
b/gcc/testsuite/g++.dg/template/redecl5.C
new file mode 100644
index 000..fb2d698e6bc
--- /dev/null
+++ b/gcc/testsuite/g++.dg/template/redecl5.C
@@ -0,0 +1,5 @@
+// PR c++/106311
+// { dg-do compile }
+
+template  struct array; // { dg-error "template parameter" }
+template  struct array { }; // { dg-error "declared" }

base-commit: 16aafa3194d4851a07cc204f56a5f0618f77e5d7
-- 
2.37.1



Re: New LinkedIn Message..

2022-07-25 Thread Mkim via Gcc-patches

Dear sir,
I've tried to contact you via LinkedIn but wasn't successful.
Is there any number i can reach you?

*Michael Kim|CIC Canada*


Re: [PATCH] Fortran: fix invalid rank error in ASSOCIATED when rank is remapped [PR77652]

2022-07-25 Thread Mikael Morin

Le 25/07/2022 à 18:01, Harald Anlauf a écrit :

Hi Mikael, all,

a discussion in the Intel compiler forum suggests that the F2018
standard prohibits such use of the ASSOCIATED intrinsic.

https://community.intel.com/t5/Intel-Fortran-Compiler/Intel-rejects-ASSOCIATED-pointer-target-for-non-equal-ranks/m-p/1402799/highlight/true#M162159



I disagree with the conclusion.  Quoting Steve Lionel’s post:

What you're missing is this:

TARGET (optional) shall be allowable as the data-target or proc-target in a 
pointer assignment statement (10.2.2) in which POINTER is data-pointer-object 
or proc-pointer-object.

We then go to 10.2.2 which says (emphasis mine):

C1019 (R1033) If bounds-remapping-list is not specified, the ranks of 
data-pointer-object and data-target shall be the same.

So... not valid Fortran 2018.


except, that there is also this:

C1018 (R1033) If bounds-remapping-list is specified, the number of 
bounds-remappings shall equal the rank of data-pointer-object.
which practically imposes no conformance rule between 
data-pointer-object and data-target.


Note that in the syntax definition, bounds-remapping-list is not part of 
data-pointer-object.  In other words, by collating a 
bounds-remapping-list next to POINTER, one can construct an allowable 
pointer assignment from TARGET to POINTER, which satisfies the 
requirement, even if TARGET and POINTER don’t have the same rank.




[PATCH] Dispatch code for floating point range ops.

2022-07-25 Thread Aldy Hernandez via Gcc-patches
This modifies the range-op dispatch code to handle floats.  Also
provided are the stub routines for the floating point range-ops, as we
need something to dispatch to ;-).

I am not ecstatic about the dispatch code, but there's no getting
around having to switch on the tree code and type in some manner.  All
the other alternatives I played with ended up being slower, or harder
to maintain.  At least, this one is self-contained in the
range_op_handler API, and less than 0.16% slower for VRP in our
benchmarks.

I will push this once a final round of testing finishes on x86-64 Linux.

gcc/ChangeLog:

* Makefile.in (OBJS): Add range-op-float.o.
* range-op.cc (get_float_handler): New.
(range_op_handler::range_op_handler): Save code and type for
delayed querying.
(range_op_handler::oeprator bool): Move from header file, and
add support for floats.
(range_op_handler::fold_range): Add support for floats.
(range_op_handler::op1_range): Same.
(range_op_handler::op2_range): Same.
(range_op_handler::lhs_op1_relation): Same.
(range_op_handler::lhs_op2_relation): Same.
(range_op_handler::op1_op2_relation): Same.
* range-op.h (class range_operator_float): New.
(class floating_op_table): New.
* value-query.cc (range_query::get_tree_range): Add case for
REAL_CST.
* range-op-float.cc: New file.
---
 gcc/Makefile.in   |   1 +
 gcc/range-op-float.cc | 206 ++
 gcc/range-op.cc   | 153 ++-
 gcc/range-op.h|  69 +-
 gcc/value-query.cc|   1 +
 5 files changed, 407 insertions(+), 23 deletions(-)
 create mode 100644 gcc/range-op-float.cc

diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index 001506f8abf..203f0a15187 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -1548,6 +1548,7 @@ OBJS = \
profile-count.o \
range.o \
range-op.o \
+   range-op-float.o \
read-md.o \
read-rtl.o \
read-rtl-function.o \
diff --git a/gcc/range-op-float.cc b/gcc/range-op-float.cc
new file mode 100644
index 000..8e9d83e3827
--- /dev/null
+++ b/gcc/range-op-float.cc
@@ -0,0 +1,206 @@
+/* Floating point range operators.
+   Copyright (C) 2022 Free Software Foundation, Inc.
+   Contributed by Aldy Hernandez .
+
+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.
+
+You should have received a copy of the GNU General Public License
+along with GCC; see the file COPYING3.  If not see
+.  */
+
+#include "config.h"
+#include "system.h"
+#include "coretypes.h"
+#include "backend.h"
+#include "insn-codes.h"
+#include "rtl.h"
+#include "tree.h"
+#include "gimple.h"
+#include "cfghooks.h"
+#include "tree-pass.h"
+#include "ssa.h"
+#include "optabs-tree.h"
+#include "gimple-pretty-print.h"
+#include "diagnostic-core.h"
+#include "flags.h"
+#include "fold-const.h"
+#include "stor-layout.h"
+#include "calls.h"
+#include "cfganal.h"
+#include "gimple-iterator.h"
+#include "gimple-fold.h"
+#include "tree-eh.h"
+#include "gimple-walk.h"
+#include "tree-cfg.h"
+#include "wide-int.h"
+#include "value-relation.h"
+#include "range-op.h"
+
+// Default definitions for floating point operators.
+
+bool
+range_operator_float::fold_range (frange  ATTRIBUTE_UNUSED,
+ tree type ATTRIBUTE_UNUSED,
+ const frange  ATTRIBUTE_UNUSED,
+ const frange  ATTRIBUTE_UNUSED,
+ relation_kind rel ATTRIBUTE_UNUSED) const
+{
+  return false;
+}
+
+bool
+range_operator_float::fold_range (irange  ATTRIBUTE_UNUSED,
+ tree type ATTRIBUTE_UNUSED,
+ const frange  ATTRIBUTE_UNUSED,
+ const frange  ATTRIBUTE_UNUSED,
+ relation_kind rel ATTRIBUTE_UNUSED) const
+{
+  return false;
+}
+
+bool
+range_operator_float::op1_range (frange  ATTRIBUTE_UNUSED,
+tree type ATTRIBUTE_UNUSED,
+const frange  ATTRIBUTE_UNUSED,
+const frange  ATTRIBUTE_UNUSED,
+relation_kind rel ATTRIBUTE_UNUSED) const
+{
+  return false;
+}
+
+bool
+range_operator_float::op1_range (frange  ATTRIBUTE_UNUSED,
+tree type ATTRIBUTE_UNUSED,
+const irange  

Re: [PATCH 3/3] c++/106426: Treat u8 character literals as unsigned in char8_t modes.

2022-07-25 Thread Andrew Pinski via Gcc-patches
On Mon, Jul 25, 2022 at 11:01 AM Tom Honermann via Gcc-patches
 wrote:
>
> This patch corrects handling of UTF-8 character literals in preprocessing
> directives so that they are treated as unsigned types in char8_t enabled
> C++ modes (C++17 with -fchar8_t or C++20 without -fno-char8_t). Previously,
> UTF-8 character literals were always treated as having the same type as
> ordinary character literals (signed or unsigned dependent on target or use
> of the -fsigned-char or -funsigned char options).
>
> Fixes https://gcc.gnu.org/PR106426.

The above mention of the PR # should just be:
preprocessor/106426

And then when this patch gets committed, it will be recorded in bugzilla also.

Thanks,
Andrew Pinski

>
> gcc/c-family/ChangeLog:
> * c-opts.cc (c_common_post_options): Assign 
> cpp_opts->unsigned_utf8char
> subject to -fchar8_t, -fsigned-char, and/or -funsigned-char.
>
> gcc/testsuite/ChangeLog:
> * g++.dg/ext/char8_t-char-literal-1.C: Check signedness of u8 
> literals.
> * g++.dg/ext/char8_t-char-literal-2.C: Check signedness of u8 
> literals.
>
> libcpp/ChangeLog:
> * charset.cc (narrow_str_to_charconst): Set signedness of CPP_UTF8CHAR
> literals based on unsigned_utf8char.
> * include/cpplib.h (cpp_options): Add unsigned_utf8char.
> * init.cc (cpp_create_reader): Initialize unsigned_utf8char.
> ---
>  gcc/c-family/c-opts.cc| 1 +
>  gcc/testsuite/g++.dg/ext/char8_t-char-literal-1.C | 6 +-
>  gcc/testsuite/g++.dg/ext/char8_t-char-literal-2.C | 4 
>  libcpp/charset.cc | 4 ++--
>  libcpp/include/cpplib.h   | 4 ++--
>  libcpp/init.cc| 1 +
>  6 files changed, 15 insertions(+), 5 deletions(-)
>
> diff --git a/gcc/c-family/c-opts.cc b/gcc/c-family/c-opts.cc
> index 108adc5caf8..02ce1e86cdb 100644
> --- a/gcc/c-family/c-opts.cc
> +++ b/gcc/c-family/c-opts.cc
> @@ -1062,6 +1062,7 @@ c_common_post_options (const char **pfilename)
>/* char8_t support is implicitly enabled in C++20 and C2X.  */
>if (flag_char8_t == -1)
>  flag_char8_t = (cxx_dialect >= cxx20) || flag_isoc2x;
> +  cpp_opts->unsigned_utf8char = flag_char8_t ? 1 : cpp_opts->unsigned_char;
>
>if (flag_extern_tls_init)
>  {
> diff --git a/gcc/testsuite/g++.dg/ext/char8_t-char-literal-1.C 
> b/gcc/testsuite/g++.dg/ext/char8_t-char-literal-1.C
> index 8ed85ccfdcd..2994dd38516 100644
> --- a/gcc/testsuite/g++.dg/ext/char8_t-char-literal-1.C
> +++ b/gcc/testsuite/g++.dg/ext/char8_t-char-literal-1.C
> @@ -1,6 +1,6 @@
>  // Test that UTF-8 character literals have type char if -fchar8_t is not 
> enabled.
>  // { dg-do compile }
> -// { dg-options "-std=c++17 -fno-char8_t" }
> +// { dg-options "-std=c++17 -fsigned-char -fno-char8_t" }
>
>  template
>struct is_same
> @@ -10,3 +10,7 @@ template
>{ static const bool value = true; };
>
>  static_assert(is_same::value, "Error");
> +
> +#if u8'\0' - 1 > 0
> +#error "UTF-8 character literals not signed in preprocessor"
> +#endif
> diff --git a/gcc/testsuite/g++.dg/ext/char8_t-char-literal-2.C 
> b/gcc/testsuite/g++.dg/ext/char8_t-char-literal-2.C
> index 7861736689c..db4fe70046d 100644
> --- a/gcc/testsuite/g++.dg/ext/char8_t-char-literal-2.C
> +++ b/gcc/testsuite/g++.dg/ext/char8_t-char-literal-2.C
> @@ -10,3 +10,7 @@ template
>{ static const bool value = true; };
>
>  static_assert(is_same::value, "Error");
> +
> +#if u8'\0' - 1 < 0
> +#error "UTF-8 character literals not unsigned in preprocessor"
> +#endif
> diff --git a/libcpp/charset.cc b/libcpp/charset.cc
> index ca8b7cf7aa5..12e31632228 100644
> --- a/libcpp/charset.cc
> +++ b/libcpp/charset.cc
> @@ -1960,8 +1960,8 @@ narrow_str_to_charconst (cpp_reader *pfile, cpp_string 
> str,
>/* Multichar constants are of type int and therefore signed.  */
>if (i > 1)
>  unsigned_p = 0;
> -  else if (type == CPP_UTF8CHAR && !CPP_OPTION (pfile, cplusplus))
> -unsigned_p = 1;
> +  else if (type == CPP_UTF8CHAR)
> +unsigned_p = CPP_OPTION (pfile, unsigned_utf8char);
>else
>  unsigned_p = CPP_OPTION (pfile, unsigned_char);
>
> diff --git a/libcpp/include/cpplib.h b/libcpp/include/cpplib.h
> index 3eba6f74b57..f9c042db034 100644
> --- a/libcpp/include/cpplib.h
> +++ b/libcpp/include/cpplib.h
> @@ -581,8 +581,8 @@ struct cpp_options
>   ints and target wide characters, respectively.  */
>size_t precision, char_precision, int_precision, wchar_precision;
>
> -  /* True means chars (wide chars) are unsigned.  */
> -  bool unsigned_char, unsigned_wchar;
> +  /* True means chars (wide chars, UTF-8 chars) are unsigned.  */
> +  bool unsigned_char, unsigned_wchar, unsigned_utf8char;
>
>/* True if the most significant byte in a word has the lowest
>   address in memory.  */
> diff --git a/libcpp/init.cc b/libcpp/init.cc
> index f4ab83d2145..0242da5f55c 100644
> --- a/libcpp/init.cc
> +++ b/libcpp/init.cc
> @@ -231,6 

[PATCH 2/3] testsuite: Add tests for C2X N2653 char8_t and UTF-8 string literal changes

2022-07-25 Thread Tom Honermann via Gcc-patches
This change provides new tests for the core language and compiler
dependent library changes adopted for C2X via WG14 N2653.

gcc/testsuite/ChangeLog:
* gcc.dg/atomic/c2x-stdatomic-lockfree-char8_t.c: New test.
* gcc.dg/atomic/gnu2x-stdatomic-lockfree-char8_t.c: New test.
* gcc.dg/c2x-predefined-macros.c: New test.
* gcc.dg/c2x-utf8str-type.c: New test.
* gcc.dg/c2x-utf8str.c: New test.
* gcc.dg/gnu2x-predefined-macros.c: New test.
* gcc.dg/gnu2x-utf8str-type.c: New test.
* gcc.dg/gnu2x-utf8str.c: New test.
---
 .../atomic/c2x-stdatomic-lockfree-char8_t.c   | 42 +++
 .../atomic/gnu2x-stdatomic-lockfree-char8_t.c |  5 +++
 gcc/testsuite/gcc.dg/c2x-predefined-macros.c  | 11 +
 gcc/testsuite/gcc.dg/c2x-utf8str-type.c   |  6 +++
 gcc/testsuite/gcc.dg/c2x-utf8str.c| 34 +++
 .../gcc.dg/gnu2x-predefined-macros.c  |  5 +++
 gcc/testsuite/gcc.dg/gnu2x-utf8str-type.c |  5 +++
 gcc/testsuite/gcc.dg/gnu2x-utf8str.c  | 34 +++
 8 files changed, 142 insertions(+)
 create mode 100644 gcc/testsuite/gcc.dg/atomic/c2x-stdatomic-lockfree-char8_t.c
 create mode 100644 
gcc/testsuite/gcc.dg/atomic/gnu2x-stdatomic-lockfree-char8_t.c
 create mode 100644 gcc/testsuite/gcc.dg/c2x-predefined-macros.c
 create mode 100644 gcc/testsuite/gcc.dg/c2x-utf8str-type.c
 create mode 100644 gcc/testsuite/gcc.dg/c2x-utf8str.c
 create mode 100644 gcc/testsuite/gcc.dg/gnu2x-predefined-macros.c
 create mode 100644 gcc/testsuite/gcc.dg/gnu2x-utf8str-type.c
 create mode 100644 gcc/testsuite/gcc.dg/gnu2x-utf8str.c

diff --git a/gcc/testsuite/gcc.dg/atomic/c2x-stdatomic-lockfree-char8_t.c 
b/gcc/testsuite/gcc.dg/atomic/c2x-stdatomic-lockfree-char8_t.c
new file mode 100644
index 000..37ea4c8926c
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/atomic/c2x-stdatomic-lockfree-char8_t.c
@@ -0,0 +1,42 @@
+/* Test atomic_is_lock_free for char8_t.  */
+/* { dg-do run } */
+/* { dg-options "-std=c2x -D_ISOC2X_SOURCE -pedantic-errors" } */
+
+#include 
+#include 
+
+extern void abort (void);
+
+_Atomic __CHAR8_TYPE__ ac8a;
+atomic_char8_t ac8t;
+
+#define CHECK_TYPE(MACRO, V1, V2)  \
+  do   \
+{  \
+  int r1 = MACRO;  \
+  int r2 = atomic_is_lock_free ();  \
+  int r3 = atomic_is_lock_free ();  \
+  if (r1 != 0 && r1 != 1 && r1 != 2)   \
+   abort ();   \
+  if (r2 != 0 && r2 != 1)  \
+   abort ();   \
+  if (r3 != 0 && r3 != 1)  \
+   abort ();   \
+  if (r1 == 2 && r2 != 1)  \
+   abort ();   \
+  if (r1 == 2 && r3 != 1)  \
+   abort ();   \
+  if (r1 == 0 && r2 != 0)  \
+   abort ();   \
+  if (r1 == 0 && r3 != 0)  \
+   abort ();   \
+}  \
+  while (0)
+
+int
+main ()
+{
+  CHECK_TYPE (ATOMIC_CHAR8_T_LOCK_FREE, ac8a, ac8t);
+
+  return 0;
+}
diff --git a/gcc/testsuite/gcc.dg/atomic/gnu2x-stdatomic-lockfree-char8_t.c 
b/gcc/testsuite/gcc.dg/atomic/gnu2x-stdatomic-lockfree-char8_t.c
new file mode 100644
index 000..a017b134817
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/atomic/gnu2x-stdatomic-lockfree-char8_t.c
@@ -0,0 +1,5 @@
+/* Test atomic_is_lock_free for char8_t with -std=gnu2x.  */
+/* { dg-do run } */
+/* { dg-options "-std=gnu2x -D_GNU_SOURCE -pedantic-errors" } */
+
+#include "c2x-stdatomic-lockfree-char8_t.c"
diff --git a/gcc/testsuite/gcc.dg/c2x-predefined-macros.c 
b/gcc/testsuite/gcc.dg/c2x-predefined-macros.c
new file mode 100644
index 000..3456105563a
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/c2x-predefined-macros.c
@@ -0,0 +1,11 @@
+/* Test C2X predefined macros.  */
+/* { dg-do compile } */
+/* { dg-options "-std=c2x" } */
+
+#if !defined(__CHAR8_TYPE__)
+# error __CHAR8_TYPE__ is not defined!
+#endif
+
+#if !defined(__GCC_ATOMIC_CHAR8_T_LOCK_FREE)
+# error __GCC_ATOMIC_CHAR8_T_LOCK_FREE is not defined!
+#endif
diff --git a/gcc/testsuite/gcc.dg/c2x-utf8str-type.c 
b/gcc/testsuite/gcc.dg/c2x-utf8str-type.c
new file mode 100644
index 000..1ae86955516
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/c2x-utf8str-type.c
@@ -0,0 +1,6 @@
+/* Test C2X UTF-8 string literal type.  */
+/* { dg-do compile } */
+/* { dg-options "-std=c2x" } */
+
+_Static_assert (_Generic (u8"text", char*: 1, unsigned char*: 2) == 2, "UTF-8 
string literals have an unexpected type");
+_Static_assert (_Generic (u8"x"[0], char:  1, unsigned char:  2) == 2, "UTF-8 
string literal elements have an unexpected type");
diff --git a/gcc/testsuite/gcc.dg/c2x-utf8str.c 

[PATCH 1/3] C: Implement C2X N2653 char8_t and UTF-8 string literal changes

2022-07-25 Thread Tom Honermann via Gcc-patches
This patch implements the core language and compiler dependent library
changes adopted for C2X via WG14 N2653.  The changes include:
- Change of type for UTF-8 string literals from array of const char to
  array of const char8_t (unsigned char).
- A new atomic_char8_t typedef.
- A new ATOMIC_CHAR8_T_LOCK_FREE macro defined in terms of the existing
  __GCC_ATOMIC_CHAR8_T_LOCK_FREE predefined macro.

gcc/ChangeLog:

* ginclude/stdatomic.h (atomic_char8_t,
ATOMIC_CHAR8_T_LOCK_FREE): New typedef and macro.

gcc/c/ChangeLog:

* c-parser.c (c_parser_string_literal): Use char8_t as the type
of CPP_UTF8STRING when char8_t support is enabled.
* c-typeck.c (digest_init): Allow initialization of an array
of character type by a string literal with type array of
char8_t.

gcc/c-family/ChangeLog:

* c-lex.c (lex_string, lex_charconst): Use char8_t as the type
of CPP_UTF8CHAR and CPP_UTF8STRING when char8_t support is
enabled.
* c-opts.c (c_common_post_options): Set flag_char8_t if
targeting C2x.
---
 gcc/c-family/c-lex.cc| 13 +
 gcc/c-family/c-opts.cc   |  4 ++--
 gcc/c/c-parser.cc| 16 ++--
 gcc/c/c-typeck.cc|  2 +-
 gcc/ginclude/stdatomic.h |  8 
 5 files changed, 34 insertions(+), 9 deletions(-)

diff --git a/gcc/c-family/c-lex.cc b/gcc/c-family/c-lex.cc
index 8bfa4f4024f..0b6f94e18a8 100644
--- a/gcc/c-family/c-lex.cc
+++ b/gcc/c-family/c-lex.cc
@@ -1352,7 +1352,14 @@ lex_string (const cpp_token *tok, tree *valp, bool 
objc_string, bool translate)
default:
case CPP_STRING:
case CPP_UTF8STRING:
- value = build_string (1, "");
+ if (type == CPP_UTF8STRING && flag_char8_t)
+   {
+ value = build_string (TYPE_PRECISION (char8_type_node)
+   / TYPE_PRECISION (char_type_node),
+   "");  /* char8_t is 8 bits */
+   }
+ else
+   value = build_string (1, "");
  break;
case CPP_STRING16:
  value = build_string (TYPE_PRECISION (char16_type_node)
@@ -1425,9 +1432,7 @@ lex_charconst (const cpp_token *token)
 type = char16_type_node;
   else if (token->type == CPP_UTF8CHAR)
 {
-  if (!c_dialect_cxx ())
-   type = unsigned_char_type_node;
-  else if (flag_char8_t)
+  if (flag_char8_t)
 type = char8_type_node;
   else
 type = char_type_node;
diff --git a/gcc/c-family/c-opts.cc b/gcc/c-family/c-opts.cc
index b9f01a65ed7..108adc5caf8 100644
--- a/gcc/c-family/c-opts.cc
+++ b/gcc/c-family/c-opts.cc
@@ -1059,9 +1059,9 @@ c_common_post_options (const char **pfilename)
   if (flag_sized_deallocation == -1)
 flag_sized_deallocation = (cxx_dialect >= cxx14);
 
-  /* char8_t support is new in C++20.  */
+  /* char8_t support is implicitly enabled in C++20 and C2X.  */
   if (flag_char8_t == -1)
-flag_char8_t = (cxx_dialect >= cxx20);
+flag_char8_t = (cxx_dialect >= cxx20) || flag_isoc2x;
 
   if (flag_extern_tls_init)
 {
diff --git a/gcc/c/c-parser.cc b/gcc/c/c-parser.cc
index 92049d1a101..fa9395986de 100644
--- a/gcc/c/c-parser.cc
+++ b/gcc/c/c-parser.cc
@@ -7447,7 +7447,14 @@ c_parser_string_literal (c_parser *parser, bool 
translate, bool wide_ok)
default:
case CPP_STRING:
case CPP_UTF8STRING:
- value = build_string (1, "");
+ if (type == CPP_UTF8STRING && flag_char8_t)
+   {
+ value = build_string (TYPE_PRECISION (char8_type_node)
+   / TYPE_PRECISION (char_type_node),
+   "");  /* char8_t is 8 bits */
+   }
+ else
+   value = build_string (1, "");
  break;
case CPP_STRING16:
  value = build_string (TYPE_PRECISION (char16_type_node)
@@ -7472,9 +7479,14 @@ c_parser_string_literal (c_parser *parser, bool 
translate, bool wide_ok)
 {
 default:
 case CPP_STRING:
-case CPP_UTF8STRING:
   TREE_TYPE (value) = char_array_type_node;
   break;
+case CPP_UTF8STRING:
+  if (flag_char8_t)
+   TREE_TYPE (value) = char8_array_type_node;
+  else
+   TREE_TYPE (value) = char_array_type_node;
+  break;
 case CPP_STRING16:
   TREE_TYPE (value) = char16_array_type_node;
   break;
diff --git a/gcc/c/c-typeck.cc b/gcc/c/c-typeck.cc
index fd0a7f81a7a..231f4e980b6 100644
--- a/gcc/c/c-typeck.cc
+++ b/gcc/c/c-typeck.cc
@@ -8045,7 +8045,7 @@ digest_init (location_t init_loc, tree type, tree init, 
tree origtype,
 
  if (char_array)
{
- if (typ2 != char_type_node)
+ if (typ2 != char_type_node && typ2 != char8_type_node)
incompat_string_cst = true;
}
  else if (!comptypes (typ1, typ2))
diff --git a/gcc/ginclude/stdatomic.h b/gcc/ginclude/stdatomic.h
index bfcfdf664c7..75ed7965689 100644

[PATCH 3/3] c++/106426: Treat u8 character literals as unsigned in char8_t modes.

2022-07-25 Thread Tom Honermann via Gcc-patches
This patch corrects handling of UTF-8 character literals in preprocessing
directives so that they are treated as unsigned types in char8_t enabled
C++ modes (C++17 with -fchar8_t or C++20 without -fno-char8_t). Previously,
UTF-8 character literals were always treated as having the same type as
ordinary character literals (signed or unsigned dependent on target or use
of the -fsigned-char or -funsigned char options).

Fixes https://gcc.gnu.org/PR106426.

gcc/c-family/ChangeLog:
* c-opts.cc (c_common_post_options): Assign cpp_opts->unsigned_utf8char
subject to -fchar8_t, -fsigned-char, and/or -funsigned-char.

gcc/testsuite/ChangeLog:
* g++.dg/ext/char8_t-char-literal-1.C: Check signedness of u8 literals.
* g++.dg/ext/char8_t-char-literal-2.C: Check signedness of u8 literals.

libcpp/ChangeLog:
* charset.cc (narrow_str_to_charconst): Set signedness of CPP_UTF8CHAR
literals based on unsigned_utf8char.
* include/cpplib.h (cpp_options): Add unsigned_utf8char.
* init.cc (cpp_create_reader): Initialize unsigned_utf8char.
---
 gcc/c-family/c-opts.cc| 1 +
 gcc/testsuite/g++.dg/ext/char8_t-char-literal-1.C | 6 +-
 gcc/testsuite/g++.dg/ext/char8_t-char-literal-2.C | 4 
 libcpp/charset.cc | 4 ++--
 libcpp/include/cpplib.h   | 4 ++--
 libcpp/init.cc| 1 +
 6 files changed, 15 insertions(+), 5 deletions(-)

diff --git a/gcc/c-family/c-opts.cc b/gcc/c-family/c-opts.cc
index 108adc5caf8..02ce1e86cdb 100644
--- a/gcc/c-family/c-opts.cc
+++ b/gcc/c-family/c-opts.cc
@@ -1062,6 +1062,7 @@ c_common_post_options (const char **pfilename)
   /* char8_t support is implicitly enabled in C++20 and C2X.  */
   if (flag_char8_t == -1)
 flag_char8_t = (cxx_dialect >= cxx20) || flag_isoc2x;
+  cpp_opts->unsigned_utf8char = flag_char8_t ? 1 : cpp_opts->unsigned_char;
 
   if (flag_extern_tls_init)
 {
diff --git a/gcc/testsuite/g++.dg/ext/char8_t-char-literal-1.C 
b/gcc/testsuite/g++.dg/ext/char8_t-char-literal-1.C
index 8ed85ccfdcd..2994dd38516 100644
--- a/gcc/testsuite/g++.dg/ext/char8_t-char-literal-1.C
+++ b/gcc/testsuite/g++.dg/ext/char8_t-char-literal-1.C
@@ -1,6 +1,6 @@
 // Test that UTF-8 character literals have type char if -fchar8_t is not 
enabled.
 // { dg-do compile }
-// { dg-options "-std=c++17 -fno-char8_t" }
+// { dg-options "-std=c++17 -fsigned-char -fno-char8_t" }
 
 template
   struct is_same
@@ -10,3 +10,7 @@ template
   { static const bool value = true; };
 
 static_assert(is_same::value, "Error");
+
+#if u8'\0' - 1 > 0
+#error "UTF-8 character literals not signed in preprocessor"
+#endif
diff --git a/gcc/testsuite/g++.dg/ext/char8_t-char-literal-2.C 
b/gcc/testsuite/g++.dg/ext/char8_t-char-literal-2.C
index 7861736689c..db4fe70046d 100644
--- a/gcc/testsuite/g++.dg/ext/char8_t-char-literal-2.C
+++ b/gcc/testsuite/g++.dg/ext/char8_t-char-literal-2.C
@@ -10,3 +10,7 @@ template
   { static const bool value = true; };
 
 static_assert(is_same::value, "Error");
+
+#if u8'\0' - 1 < 0
+#error "UTF-8 character literals not unsigned in preprocessor"
+#endif
diff --git a/libcpp/charset.cc b/libcpp/charset.cc
index ca8b7cf7aa5..12e31632228 100644
--- a/libcpp/charset.cc
+++ b/libcpp/charset.cc
@@ -1960,8 +1960,8 @@ narrow_str_to_charconst (cpp_reader *pfile, cpp_string 
str,
   /* Multichar constants are of type int and therefore signed.  */
   if (i > 1)
 unsigned_p = 0;
-  else if (type == CPP_UTF8CHAR && !CPP_OPTION (pfile, cplusplus))
-unsigned_p = 1;
+  else if (type == CPP_UTF8CHAR)
+unsigned_p = CPP_OPTION (pfile, unsigned_utf8char);
   else
 unsigned_p = CPP_OPTION (pfile, unsigned_char);
 
diff --git a/libcpp/include/cpplib.h b/libcpp/include/cpplib.h
index 3eba6f74b57..f9c042db034 100644
--- a/libcpp/include/cpplib.h
+++ b/libcpp/include/cpplib.h
@@ -581,8 +581,8 @@ struct cpp_options
  ints and target wide characters, respectively.  */
   size_t precision, char_precision, int_precision, wchar_precision;
 
-  /* True means chars (wide chars) are unsigned.  */
-  bool unsigned_char, unsigned_wchar;
+  /* True means chars (wide chars, UTF-8 chars) are unsigned.  */
+  bool unsigned_char, unsigned_wchar, unsigned_utf8char;
 
   /* True if the most significant byte in a word has the lowest
  address in memory.  */
diff --git a/libcpp/init.cc b/libcpp/init.cc
index f4ab83d2145..0242da5f55c 100644
--- a/libcpp/init.cc
+++ b/libcpp/init.cc
@@ -231,6 +231,7 @@ cpp_create_reader (enum c_lang lang, cpp_hash_table *table,
   CPP_OPTION (pfile, int_precision) = CHAR_BIT * sizeof (int);
   CPP_OPTION (pfile, unsigned_char) = 0;
   CPP_OPTION (pfile, unsigned_wchar) = 1;
+  CPP_OPTION (pfile, unsigned_utf8char) = 1;
   CPP_OPTION (pfile, bytes_big_endian) = 1;  /* does not matter */
 
   /* Default to no charset conversion.  */
-- 
2.32.0



[PATCH 0/3] Implement C2X N2653 (char8_t) and correct UTF-8 character literal type in preprocessor directives for C++

2022-07-25 Thread Tom Honermann via Gcc-patches
This patch series provides an implementation and tests for the WG14 N2653
paper as adopted for C2X.

Additionally, a fix is included for the C++ preprocessor to treat UTF-8
character literals in preprocessor directives as an unsigned type in char8_t
enabled modes (in C++17 and earlier with -fchar8_t or in C++20 or later
without -fno-char8_t).

Tom Honermann (3):
  C: Implement C2X N2653 char8_t and UTF-8 string literal changes
  testsuite: Add tests for C2X N2653 char8_t and UTF-8 string literal
changes
  c++/106426: Treat u8 character literals as unsigned in char8_t modes.

 gcc/c-family/c-lex.cc | 13 --
 gcc/c-family/c-opts.cc|  5 ++-
 gcc/c/c-parser.cc | 16 ++-
 gcc/c/c-typeck.cc |  2 +-
 gcc/ginclude/stdatomic.h  |  8 
 .../g++.dg/ext/char8_t-char-literal-1.C   |  6 ++-
 .../g++.dg/ext/char8_t-char-literal-2.C   |  4 ++
 .../atomic/c2x-stdatomic-lockfree-char8_t.c   | 42 +++
 .../atomic/gnu2x-stdatomic-lockfree-char8_t.c |  5 +++
 gcc/testsuite/gcc.dg/c2x-predefined-macros.c  | 11 +
 gcc/testsuite/gcc.dg/c2x-utf8str-type.c   |  6 +++
 gcc/testsuite/gcc.dg/c2x-utf8str.c| 34 +++
 .../gcc.dg/gnu2x-predefined-macros.c  |  5 +++
 gcc/testsuite/gcc.dg/gnu2x-utf8str-type.c |  5 +++
 gcc/testsuite/gcc.dg/gnu2x-utf8str.c  | 34 +++
 libcpp/charset.cc |  4 +-
 libcpp/include/cpplib.h   |  4 +-
 libcpp/init.cc|  1 +
 18 files changed, 191 insertions(+), 14 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/atomic/c2x-stdatomic-lockfree-char8_t.c
 create mode 100644 
gcc/testsuite/gcc.dg/atomic/gnu2x-stdatomic-lockfree-char8_t.c
 create mode 100644 gcc/testsuite/gcc.dg/c2x-predefined-macros.c
 create mode 100644 gcc/testsuite/gcc.dg/c2x-utf8str-type.c
 create mode 100644 gcc/testsuite/gcc.dg/c2x-utf8str.c
 create mode 100644 gcc/testsuite/gcc.dg/gnu2x-predefined-macros.c
 create mode 100644 gcc/testsuite/gcc.dg/gnu2x-utf8str-type.c
 create mode 100644 gcc/testsuite/gcc.dg/gnu2x-utf8str.c

-- 
2.32.0



RE: [PATCH] analyzer: fix coding style in sm-fd.cc

2022-07-25 Thread Immad Mir via Gcc-patches
Thanks for this. I’ll keep this in mind for future patches.

Immad.


Sent from Mail for Windows 10

From: Martin Liška
Sent: 25 July 2022 12:14 PM
To: gcc-patches@gcc.gnu.org
Cc: mirim...@outlook.com; David 
Malcolm
Subject: [PATCH] analyzer: fix coding style in sm-fd.cc

Hi.

First, thanks Mir for your contribution. The following patch addresses
coding style issues I let you know in:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106003#c3

Most notably, I converted Windows endlines to Unix style, replace 8 spaces with 
tabs
and removed trailing whitespaces.

Please consider using our script that verifies that:
git show f8e6e2c046e1015697356ee7079fb39e0cb6add5 > diff && 
./contrib/check_GNU_style.py diff

Ready to be installed?
Thanks,
Martin


gcc/analyzer/ChangeLog:

* sm-fd.cc: Run dos2unix and fix coding style issues.
---
 gcc/analyzer/sm-fd.cc | 2114 -
 1 file changed, 1057 insertions(+), 1057 deletions(-)

diff --git a/gcc/analyzer/sm-fd.cc b/gcc/analyzer/sm-fd.cc
index c3dac48509e..56b0063ba42 100644
--- a/gcc/analyzer/sm-fd.cc
+++ b/gcc/analyzer/sm-fd.cc
@@ -1,1057 +1,1057 @@
-/* A state machine for detecting misuses of POSIX file descriptor APIs.
-   Copyright (C) 2019-2022 Free Software Foundation, Inc.
-   Contributed by Immad Mir .
-
-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.
-
-You should have received a copy of the GNU General Public License
-along with GCC; see the file COPYING3.  If not see
-.  */
-
-#include "config.h"
-#include "system.h"
-#include "coretypes.h"
-#include "tree.h"
-#include "function.h"
-#include "basic-block.h"
-#include "gimple.h"
-#include "options.h"
-#include "diagnostic-path.h"
-#include "diagnostic-metadata.h"
-#include "function.h"
-#include "json.h"
-#include "analyzer/analyzer.h"
-#include "diagnostic-event-id.h"
-#include "analyzer/analyzer-logging.h"
-#include "analyzer/sm.h"
-#include "analyzer/pending-diagnostic.h"
-#include "analyzer/function-set.h"
-#include "analyzer/analyzer-selftests.h"
-#include "tristate.h"
-#include "selftest.h"
-#include "stringpool.h"
-#include "attribs.h"
-#include "analyzer/call-string.h"
-#include "analyzer/program-point.h"
-#include "analyzer/store.h"
-#include "analyzer/region-model.h"
-#include "bitmap.h"
-
-#if ENABLE_ANALYZER
-
-namespace ana {
-
-namespace {
-
-/* An enum for distinguishing between three different access modes. */
-
-enum access_mode
-{
-  READ_WRITE,
-  READ_ONLY,
-  WRITE_ONLY
-};
-
-enum access_directions
-{
-  DIRS_READ_WRITE,
-  DIRS_READ,
-  DIRS_WRITE
-};
-
-class fd_state_machine : public state_machine
-{
-public:
-  fd_state_machine (logger *logger);
-
-  bool
-  inherited_state_p () const final override
-  {
-return false;
-  }
-
-  state_machine::state_t
-  get_default_state (const svalue *sval) const final override
-  {
-if (tree cst = sval->maybe_get_constant ())
-  {
-if (TREE_CODE (cst) == INTEGER_CST)
-  {
-int val = TREE_INT_CST_LOW (cst);
-if (val >= 0)
-  return m_constant_fd;
-else
-  return m_invalid;
-  }
-  }
-return m_start;
-  }
-
-  bool on_stmt (sm_context *sm_ctxt, const supernode *node,
-const gimple *stmt) const final override;
-
-  void on_condition (sm_context *sm_ctxt, const supernode *node,
- const gimple *stmt, const svalue *lhs, const tree_code op,
- const svalue *rhs) const final override;
-
-  bool can_purge_p (state_t s) const final override;
-  pending_diagnostic *on_leak (tree var) const final override;
-
-  bool is_unchecked_fd_p (state_t s) const;
-  bool is_valid_fd_p (state_t s) const;
-  bool is_closed_fd_p (state_t s) const;
-  bool is_constant_fd_p (state_t s) const;
-  bool is_readonly_fd_p (state_t s) const;
-  bool is_writeonly_fd_p (state_t s) const;
-  enum access_mode get_access_mode_from_flag (int flag) const;
-
-  /* State for a constant file descriptor (>= 0) */
-  state_t m_constant_fd;
-
-  /* States representing a file descriptor that hasn't yet been
-checked for validity after opening, for three different
-access modes.  */
-  state_t m_unchecked_read_write;
-
-  state_t m_unchecked_read_only;
-
-  state_t m_unchecked_write_only;
-
-  /* States for representing a file descriptor that is known to be valid (>=
-0), 

Re: [PATCH] Fortran: fix invalid rank error in ASSOCIATED when rank is remapped [PR77652]

2022-07-25 Thread Harald Anlauf via Gcc-patches
Hi Mikael, all,

a discussion in the Intel compiler forum suggests that the F2018
standard prohibits such use of the ASSOCIATED intrinsic.

https://community.intel.com/t5/Intel-Fortran-Compiler/Intel-rejects-ASSOCIATED-pointer-target-for-non-equal-ranks/m-p/1402799/highlight/true#M162159

As a consequence, the PR is likely invalid, as is the patch.
Withdrawing.

Sorry for the noise!

Harald


> Gesendet: Montag, 25. Juli 2022 um 12:43 Uhr
> Von: "Mikael Morin" 
> An: "Harald Anlauf" , "fortran" , 
> "gcc-patches" 
> Betreff: Re: [PATCH] Fortran: fix invalid rank error in ASSOCIATED when rank 
> is remapped [PR77652]
>
> Le 21/07/2022 à 22:12, Harald Anlauf via Fortran a écrit :
> > Dear all,
> > 
> > the rank check for ASSOCIATED (POINTER, TARGET) did not allow all
> > rank combinations that were allowed in pointer assignment for
> > newer versions of the Fortran standard (F2008+).  Fix the logic.
> > 
> So, if I understand correctly the (fixed) logic, it is:
>   f2008+=> no check
>   f2003 => check target’s rank different from 1
>   up to f95 => check pointer’s rank equals target’s
> 
> 
> I think one check is missing, that is when pointer is scalar and the 
> target is non-scalar (either rank 1 or not).  This case should also be 
> rejected for f2003+, not just up to f95.
> 
> Mikael
>


Re: [PATCH] analyzer: fix coding style in sm-fd.cc

2022-07-25 Thread David Malcolm via Gcc-patches
On Mon, 2022-07-25 at 08:44 +0200, Martin Liška wrote:
> Hi.
> 
> First, thanks Mir for your contribution. The following patch
> addresses
> coding style issues I let you know in:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106003#c3
> 
> Most notably, I converted Windows endlines to Unix style, replace 8
> spaces with tabs
> and removed trailing whitespaces.
> 
> Please consider using our script that verifies that:
> git show f8e6e2c046e1015697356ee7079fb39e0cb6add5 > diff &&
> ./contrib/check_GNU_style.py diff
> 
> Ready to be installed?

Yes, thanks
Dave

> Thanks,
> Martin
> 
> 
> gcc/analyzer/ChangeLog:
> 
> * sm-fd.cc: Run dos2unix and fix coding style issues.
> ---
>  gcc/analyzer/sm-fd.cc | 2114 ---
> --
>  1 file changed, 1057 insertions(+), 1057 deletions(-)
> 
> diff --git a/gcc/analyzer/sm-fd.cc b/gcc/analyzer/sm-fd.cc
> index c3dac48509e..56b0063ba42 100644
> --- a/gcc/analyzer/sm-fd.cc
> +++ b/gcc/analyzer/sm-fd.cc
> @@ -1,1057 +1,1057 @@
> -/* A state machine for detecting misuses of POSIX file descriptor
> APIs.
> -   Copyright (C) 2019-2022 Free Software Foundation, Inc.
> -   Contributed by Immad Mir .
> -
> -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.
> -
> -You should have received a copy of the GNU General Public License
> -along with GCC; see the file COPYING3.  If not see
> -.  */
> -
> -#include "config.h"
> -#include "system.h"
> -#include "coretypes.h"
> -#include "tree.h"
> -#include "function.h"
> -#include "basic-block.h"
> -#include "gimple.h"
> -#include "options.h"
> -#include "diagnostic-path.h"
> -#include "diagnostic-metadata.h"
> -#include "function.h"
> -#include "json.h"
> -#include "analyzer/analyzer.h"
> -#include "diagnostic-event-id.h"
> -#include "analyzer/analyzer-logging.h"
> -#include "analyzer/sm.h"
> -#include "analyzer/pending-diagnostic.h"
> -#include "analyzer/function-set.h"
> -#include "analyzer/analyzer-selftests.h"
> -#include "tristate.h"
> -#include "selftest.h"
> -#include "stringpool.h"
> -#include "attribs.h"
> -#include "analyzer/call-string.h"
> -#include "analyzer/program-point.h"
> -#include "analyzer/store.h"
> -#include "analyzer/region-model.h"
> -#include "bitmap.h"
> -
> -#if ENABLE_ANALYZER
> -
> -namespace ana {
> -
> -namespace {
> -
> -/* An enum for distinguishing between three different access modes.
> */
> -
> -enum access_mode
> -{
> -  READ_WRITE,
> -  READ_ONLY,
> -  WRITE_ONLY
> -};
> -
> -enum access_directions
> -{
> -  DIRS_READ_WRITE,
> -  DIRS_READ,
> -  DIRS_WRITE
> -};
> -
> -class fd_state_machine : public state_machine
> -{
> -public:
> -  fd_state_machine (logger *logger);
> -
> -  bool
> -  inherited_state_p () const final override
> -  {
> -    return false;
> -  }
> -
> -  state_machine::state_t
> -  get_default_state (const svalue *sval) const final override
> -  {
> -    if (tree cst = sval->maybe_get_constant ())
> -  {
> -    if (TREE_CODE (cst) == INTEGER_CST)
> -  {
> -    int val = TREE_INT_CST_LOW (cst);
> -    if (val >= 0)
> -  return m_constant_fd;
> -    else
> -  return m_invalid;
> -  }
> -  }
> -    return m_start;
> -  }
> -
> -  bool on_stmt (sm_context *sm_ctxt, const supernode *node,
> -    const gimple *stmt) const final override;
> -
> -  void on_condition (sm_context *sm_ctxt, const supernode *node,
> - const gimple *stmt, const svalue *lhs, const
> tree_code op,
> - const svalue *rhs) const final override;
> -
> -  bool can_purge_p (state_t s) const final override;
> -  pending_diagnostic *on_leak (tree var) const final override;
> -
> -  bool is_unchecked_fd_p (state_t s) const;
> -  bool is_valid_fd_p (state_t s) const;
> -  bool is_closed_fd_p (state_t s) const;
> -  bool is_constant_fd_p (state_t s) const;
> -  bool is_readonly_fd_p (state_t s) const;
> -  bool is_writeonly_fd_p (state_t s) const;
> -  enum access_mode get_access_mode_from_flag (int flag) const;
> -
> -  /* State for a constant file descriptor (>= 0) */
> -  state_t m_constant_fd;
> -
> -  /* States representing a file descriptor that hasn't yet been
> -    checked for validity after opening, for three different
> -    access modes.  */
> -  state_t m_unchecked_read_write;
> -
> -  state_t m_unchecked_read_only;
> -
> -  state_t m_unchecked_write_only;
> -
> -  /* States for representing a file descriptor that is known to be
> valid (>=
> -    0), for three different access 

Re: [PATCH] analyzer: convert tests with dos2unix

2022-07-25 Thread David Malcolm via Gcc-patches
On Mon, 2022-07-25 at 08:45 +0200, Martin Liška wrote:
> Ready for master?

Yes, thanks.
Dave


> Thanks,
> Martin
> 
> gcc/testsuite/ChangeLog:
> 
> * gcc.dg/analyzer/fd-2.c: Convert Windows endlines to Unix
> style.
> * gcc.dg/analyzer/fd-3.c: Likewise.
> * gcc.dg/analyzer/fd-4.c: Likewise.
> * gcc.dg/analyzer/fd-5.c: Likewise.
> * c-c++-common/attr-fd.c: Likewise.
> ---
>  gcc/testsuite/c-c++-common/attr-fd.c |  36 +++---
>  gcc/testsuite/gcc.dg/analyzer/fd-2.c |  96 +++
>  gcc/testsuite/gcc.dg/analyzer/fd-3.c | 168 +
> --
>  gcc/testsuite/gcc.dg/analyzer/fd-4.c | 142 +++---
>  gcc/testsuite/gcc.dg/analyzer/fd-5.c | 104 -
>  5 files changed, 273 insertions(+), 273 deletions(-)
> 
> diff --git a/gcc/testsuite/c-c++-common/attr-fd.c b/gcc/testsuite/c-
> c++-common/attr-fd.c
> index e4bb4ed0374..9f12093c04f 100644
> --- a/gcc/testsuite/c-c++-common/attr-fd.c
> +++ b/gcc/testsuite/c-c++-common/attr-fd.c
> @@ -1,18 +1,18 @@
> -
> -int not_a_fn __attribute__ ((fd_arg(1))); /* { dg-warning "'fd_arg'
> attribute only applies to function types" } */
> -
> -void f (char *p) __attribute__ ((fd_arg(1))); /* { dg-warning
> "'fd_arg' attribute argument value '1' refers to parameter type 'char
> ?\\\*'" } */
> -
> -
> -int not_a_fn_b __attribute__ ((fd_arg_read(1))); /* { dg-warning
> "'fd_arg_read' attribute only applies to function types" } */
> -
> -void g (char *p) __attribute__ ((fd_arg_read(1))); /* { dg-warning
> "'fd_arg_read' attribute argument value '1' refers to parameter type
> 'char ?\\\*'" } */
> -
> -
> -int not_a_fn_c __attribute__ ((fd_arg_write(1))); /* { dg-warning
> "'fd_arg_write' attribute only applies to function types" } */
> -
> -void f (char *p) __attribute__ ((fd_arg_write(1))); /* { dg-warning
> "'fd_arg_write' attribute argument value '1' refers to parameter type
> 'char ?\\\*'" } */
> -
> -
> -void fn_a (int fd) __attribute__ ((fd_arg(0))); /* { dg-warning
> "'fd_arg' attribute argument value '0' does not refer to a function
> parameter" } */
> -void fd_a_1 (int fd) __attribute__ ((fd_arg("notint"))); /* { dg-
> warning "'fd_arg' attribute argument has type ('char\\\[7\\\]'|'const
> char\\\*')" } */
> +
> +int not_a_fn __attribute__ ((fd_arg(1))); /* { dg-warning "'fd_arg'
> attribute only applies to function types" } */
> +
> +void f (char *p) __attribute__ ((fd_arg(1))); /* { dg-warning
> "'fd_arg' attribute argument value '1' refers to parameter type 'char
> ?\\\*'" } */
> +
> +
> +int not_a_fn_b __attribute__ ((fd_arg_read(1))); /* { dg-warning
> "'fd_arg_read' attribute only applies to function types" } */
> +
> +void g (char *p) __attribute__ ((fd_arg_read(1))); /* { dg-warning
> "'fd_arg_read' attribute argument value '1' refers to parameter type
> 'char ?\\\*'" } */
> +
> +
> +int not_a_fn_c __attribute__ ((fd_arg_write(1))); /* { dg-warning
> "'fd_arg_write' attribute only applies to function types" } */
> +
> +void f (char *p) __attribute__ ((fd_arg_write(1))); /* { dg-warning
> "'fd_arg_write' attribute argument value '1' refers to parameter type
> 'char ?\\\*'" } */
> +
> +
> +void fn_a (int fd) __attribute__ ((fd_arg(0))); /* { dg-warning
> "'fd_arg' attribute argument value '0' does not refer to a function
> parameter" } */
> +void fd_a_1 (int fd) __attribute__ ((fd_arg("notint"))); /* { dg-
> warning "'fd_arg' attribute argument has type ('char\\\[7\\\]'|'const
> char\\\*')" } */
> diff --git a/gcc/testsuite/gcc.dg/analyzer/fd-2.c
> b/gcc/testsuite/gcc.dg/analyzer/fd-2.c
> index 96ccf2f7ba8..d794b460a2e 100644
> --- a/gcc/testsuite/gcc.dg/analyzer/fd-2.c
> +++ b/gcc/testsuite/gcc.dg/analyzer/fd-2.c
> @@ -1,49 +1,49 @@
> -int open(const char *, int mode);
> -void close(int fd);
> -#define O_RDONLY 0
> -#define O_WRONLY 1
> -#define O_RDWR 2
> -#define STDIN 0
> -
> -void 
> -test_1 (const char *path)
> -{
> -    int fd = open (path, O_RDWR); /* { dg-message "\\(1\\) opened
> here" } */
> -    close (fd); /* { dg-message "\\(2\\) first 'close' here"
> "event1" } */
> -    close (fd); /* { dg-warning "double 'close' of file descriptor
> 'fd' \\\[CWE-1341\\\]" "warning" } */
> -    /* { dg-message "\\(3\\) second 'close' here; first 'close' was
> at \\(2\\)" "event2" { target *-*-* } .-1 } */
> -}
> -
> -void 
> -test_2 (const char *path)
> -{
> -    int fd = open (path, O_RDWR); /* { dg-message "\\(1\\) opened
> here" } */
> -    if (fd < 0) /* { dg-message "\\(2\\) assuming 'fd' is a valid
> file descriptor \\(>= 0\\)" "event1" } */
> -    /* { dg-message "\\(3\\) following 'false' branch \\(when 'fd >=
> 0'\\)..." "event2" { target *-*-* } .-1 } */
> -    return;
> -    close (fd); /* { dg-message "\\(4\\) ...to here" "event1" } */
> -    /* { dg-message "\\(5\\) first 'close' here" "event2" { target
> *-*-* } .-1 } */
> -    close (fd); /* { dg-warning "double 'close' of file descriptor
> 'fd' \\\[CWE-1341\\\]" "warning" } */
> -    /* {dg-message 

[COMMITTED] [PR middle-end/106432] Gracefully handle unsupported type in range_on_edge

2022-07-25 Thread Aldy Hernandez via Gcc-patches
A cleaner approach to fix this PR has been suggested by Andrew, which
is to just return false on range_on_edge for unsupported range types.

Tested on x86-64 Linux.

gcc/ChangeLog:

* gimple-range.cc (gimple_ranger::range_on_edge): Return false
  when the result range type is unsupported.
---
 gcc/gimple-range.cc | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/gcc/gimple-range.cc b/gcc/gimple-range.cc
index 7ac48303e4e..eb347eee45b 100644
--- a/gcc/gimple-range.cc
+++ b/gcc/gimple-range.cc
@@ -201,7 +201,9 @@ bool
 gimple_ranger::range_on_edge (vrange , edge e, tree name)
 {
   Value_Range edge_range (TREE_TYPE (name));
-  gcc_checking_assert (r.supports_type_p (TREE_TYPE (name)));
+
+  if (!r.supports_type_p (TREE_TYPE (name)))
+return false;
 
   // Do not process values along abnormal edges.
   if (e->flags & EDGE_ABNORMAL)
-- 
2.36.1



Re: [PATCH] tree-optimization/106379 - add missing ~(a ^ b) folding for _Bool

2022-07-25 Thread Richard Biener via Gcc-patches
On Mon, 25 Jul 2022, H.J. Lu wrote:

> On Fri, Jul 22, 2022 at 11:10 PM Richard Biener via Gcc-patches
>  wrote:
> >
> >
> >
> > > Am 22.07.2022 um 22:17 schrieb H.J. Lu via Gcc-patches 
> > > :
> > >
> > > On Thu, Jul 21, 2022 at 4:24 AM Richard Biener via Gcc-patches
> > >  wrote:
> > >>
> > >> The following makes sure to fold ~(a ^ b) to a == b for truth
> > >> values (but not vectors, we'd have to check for vector support of
> > >> equality).  That turns the PR106379 testcase into a ranger one.
> > >>
> > >> Note that while we arrive at ~(a ^ b) in a convoluted way from
> > >> original !a == !b one can eventually write the expression this
> > >> way directly as well.
> > >>
> > >> Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
> > >>
> > >>PR tree-optimization/106379
> > >>* match.pd (~(a ^ b) -> a == b): New pattern.
> > >>
> > >>* gcc.dg/pr106379-1.c: New testcase.
> > >> ---
> > >> gcc/match.pd  | 6 ++
> > >> gcc/testsuite/gcc.dg/pr106379-1.c | 9 +
> > >> 2 files changed, 15 insertions(+)
> > >> create mode 100644 gcc/testsuite/gcc.dg/pr106379-1.c
> > >>
> > >> diff --git a/gcc/match.pd b/gcc/match.pd
> > >> index 8bbc0dbd5cd..88a1a5aa9cc 100644
> > >> --- a/gcc/match.pd
> > >> +++ b/gcc/match.pd
> > >> @@ -1938,6 +1938,12 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
> > >>  (if (tree_nop_conversion_p (type, TREE_TYPE (@0)))
> > >>   (bit_not (bit_xor (view_convert @0) @1
> > >>
> > >> +/* ~(a ^ b) is a == b for truth valued a and b.  */
> > >> +(simplify
> > >> + (bit_not (bit_xor:s truth_valued_p@0 truth_valued_p@1))
> > >> + (if (!VECTOR_TYPE_P (type))
> > >> +  (convert (eq @0 @1
> > >
> > > For integers, isn't it wrong to convert ~(boolean exp) to boolean exp?
> >
> > That’s what the (convert. …) should compensate for?
> 
> Is ~(boolean exp) == ~((int) (boolean exp)) or (int) (~(boolean exp))?

Depends on what 'boolean exp' is, and as PR106414 shows I was wrong
because in C a == b has type 'int' and not type bool but we consider
it "boolean".  There of course ~(a == b) is not equal to a != b.

Richard.


Re: [PATCH] tree-optimization/106379 - add missing ~(a ^ b) folding for _Bool

2022-07-25 Thread H.J. Lu via Gcc-patches
On Fri, Jul 22, 2022 at 11:10 PM Richard Biener via Gcc-patches
 wrote:
>
>
>
> > Am 22.07.2022 um 22:17 schrieb H.J. Lu via Gcc-patches 
> > :
> >
> > On Thu, Jul 21, 2022 at 4:24 AM Richard Biener via Gcc-patches
> >  wrote:
> >>
> >> The following makes sure to fold ~(a ^ b) to a == b for truth
> >> values (but not vectors, we'd have to check for vector support of
> >> equality).  That turns the PR106379 testcase into a ranger one.
> >>
> >> Note that while we arrive at ~(a ^ b) in a convoluted way from
> >> original !a == !b one can eventually write the expression this
> >> way directly as well.
> >>
> >> Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
> >>
> >>PR tree-optimization/106379
> >>* match.pd (~(a ^ b) -> a == b): New pattern.
> >>
> >>* gcc.dg/pr106379-1.c: New testcase.
> >> ---
> >> gcc/match.pd  | 6 ++
> >> gcc/testsuite/gcc.dg/pr106379-1.c | 9 +
> >> 2 files changed, 15 insertions(+)
> >> create mode 100644 gcc/testsuite/gcc.dg/pr106379-1.c
> >>
> >> diff --git a/gcc/match.pd b/gcc/match.pd
> >> index 8bbc0dbd5cd..88a1a5aa9cc 100644
> >> --- a/gcc/match.pd
> >> +++ b/gcc/match.pd
> >> @@ -1938,6 +1938,12 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
> >>  (if (tree_nop_conversion_p (type, TREE_TYPE (@0)))
> >>   (bit_not (bit_xor (view_convert @0) @1
> >>
> >> +/* ~(a ^ b) is a == b for truth valued a and b.  */
> >> +(simplify
> >> + (bit_not (bit_xor:s truth_valued_p@0 truth_valued_p@1))
> >> + (if (!VECTOR_TYPE_P (type))
> >> +  (convert (eq @0 @1
> >
> > For integers, isn't it wrong to convert ~(boolean exp) to boolean exp?
>
> That’s what the (convert. …) should compensate for?

Is ~(boolean exp) == ~((int) (boolean exp)) or (int) (~(boolean exp))?

> Richard
>
> >
> >> /* (x & ~m) | (y & m) -> ((x ^ y) & m) ^ x */
> >> (simplify
> >>  (bit_ior:c (bit_and:cs @0 (bit_not @2)) (bit_and:cs @1 @2))
> >> diff --git a/gcc/testsuite/gcc.dg/pr106379-1.c 
> >> b/gcc/testsuite/gcc.dg/pr106379-1.c
> >> new file mode 100644
> >> index 000..7f2575e02dc
> >> --- /dev/null
> >> +++ b/gcc/testsuite/gcc.dg/pr106379-1.c
> >> @@ -0,0 +1,9 @@
> >> +/* { dg-do compile } */
> >> +/* { dg-options "-O -fdump-tree-forwprop1" } */
> >> +
> >> +_Bool foo (_Bool a, _Bool b)
> >> +{
> >> +  return !a == !b;
> >> +}
> >> +
> >> +/* { dg-final { scan-tree-dump "\[ab\]_\[0-9\]+\\(D\\) == 
> >> \[ba\]_\[0-9\]+\\(D\\)" "forwprop1" } } */
> >> --
> >> 2.35.3
> >
> >
> >
> > --
> > H.J.



-- 
H.J.


[PATCH] contrib: use sphinx-build from a venv

2022-07-25 Thread Martin Liška
Hi.

As you likely know, I'm still working on transition of the current docs to 
Sphinx.
But for now, I've sent a modernizing patches for the current libgccjit 
documentation
and I will need a more recent version of Sphinx.

Can please a maintainer install the package from pip?

Something like:
virtualenv /home/gcc/venv && /home/gcc/venv/bin/pip install Sphinx

or a similar location?

Thanks,
Martin

maintainer-scripts/ChangeLog:

* update_web_docs_git: Use sphinx-build from a venv so that
we can use a recent version.
---
 maintainer-scripts/update_web_docs_git | 21 ++---
 1 file changed, 6 insertions(+), 15 deletions(-)

diff --git a/maintainer-scripts/update_web_docs_git 
b/maintainer-scripts/update_web_docs_git
index 996d29bfb68..4b01b3dc1c0 100755
--- a/maintainer-scripts/update_web_docs_git
+++ b/maintainer-scripts/update_web_docs_git
@@ -176,23 +176,14 @@ for file in $MANUALS; do
   fi
 done
 
-# The jit is a special-case, using sphinx rather than texinfo.
-# Specifically, the jit docs need sphinx 1.0 or later.
+# The jit is a special-case, using Sphinx rather than texinfo.
+# Specifically, the jit docs need Sphinx 3.0 or later.
 #
-# The jit/docs Makefile uses the executable $(SPHINXBUILD),
-# defaulting to "sphinx-build".
-#
-# sphinx is packaged in Fedora and EPEL 6 within "python-sphinx",
-# in RHEL 8 within "python3-sphinx",
-# and in openSUSE within "python-Sphinx".
-#
-# For EPEL6, python-sphinx is sphinx 0.6.6, which is missing various
-# directives (e.g. ":c:macro:"), so we need the variant
-# python-sphinx10 package.  The latter installs its executable as
-#   /usr/bin/sphinx-1.0-build
-# so we needed to override SPHINXBUILD with this when invoking "make".
+# Use the Sphinx installed in a virtual environment so that
+# we don't depend on a system package.
+
 pushd gcc/gcc/jit/docs
-make html || true
+make html SPHINXBUILD=/home/gcc/venv/bin/sphinx-build || true
 popd
 cp -a gcc/gcc/jit/docs/_build/html jit
 mkdir -p $DOCSDIR/jit
-- 
2.37.1



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

2022-07-25 Thread Marcel Vollweiler

Hi Jakub,


I'm not sure we can rely on execv on all targets that do support libgomp.
Any reason why you actually need this, rather than using
dg-set-target-env-var directive(s) and perhaps return 0; if getenv doesn't
return the expected values?


Interesting topic. After some (internal) discussions I think the best way is to
set the environment variables explicitely instead using dg-set-target-env-var.
The reason is that dg-set-target-env-var does not work for remote testing (which
seems to be a common test environment). For remote testing dejagnu immediately
aborts the test case with UNSUPPORTED which is specified in the corresponding
extension and makes sence from my point of view as the test assumption cannot be
fulfilled (since the environment variables are not set on remote targets).
It also means that whenever dg-set-target-env-var is set in the test file, the
execution of the test case is not tested on remote targets.


The only reason why dg-set-target-env-var is supported on native only right
now is that I'm never doing remote testing myself and so couldn't test that.
There is no inherent reason why the env vars couldn't be propagated over to
the remote and set in the environment there.
So trying to work around that rather than at least trying to change
dg-set-target-env-var so that it works with the remote testing you do looks
wrong.
If dg-set-target-env-var can be made to work remotely, it will magically
improve those 130+ tests that use it already together with the newly added
tests.

So, I'd suggest to just use dg-set-target-env-var and incrementally work on
making it work for remote testing if that is important to whomever does
that kind of testing.  Could be e.g. a matter of invoking remotely
env VAR1=val1 VAR2=val2 program args
instead of program args.  If env is missing on the remote side, it could
be UNSUPPORTED then.


I agree. So I changed the tests using dg-set-target-env-var and removed the
execv parts.




+/* The initial ICV values for the host, which are configured with environment
+   variables without a suffix, e.g. OMP_NUM_TEAMS.  */
+struct gomp_initial_icvs gomp_initial_icvs_none;
+
+/* Initial ICV values that were configured for the host and for all devices by
+   using environment variables like OMP_NUM_TEAMS_ALL.  */
+struct gomp_initial_icvs gomp_initial_icvs_all;
+
+/* Initial ICV values that were configured only for devices (not for the host)
+   by using environment variables like OMP_NUM_TEAMS_DEV.  */
+struct gomp_initial_icvs gomp_initial_icvs_dev;


As I said last time, I don't like allocating these
all the time in the data section of libgomp when at least for a few upcoming
years, most users will never use those suffixes.
Can't *_DEV and *_ALL go into the gomp_initial_icv_dev_list
chain too, perhaps


gomp_initial_icvs_{none, all, dev} are now defined as pointers (as you proposed
previously). gomp_initial_icvs_{all, dev} are only instantiated if at least one
according environment variable is parsed. gomp_initial_icvs_none is always
initialized with the initial global ICV values.

All three structures are now also included in gomp_initial_icv_list (previously
named gomp_initial_icv_dev_list) with "magic device numbers" -1, -2, and -3.
The list items for _DEV, _ALL and no suffix are stored at the beginning of the
list whereas the device-specific list items are attached at the end.




+static const struct envvar
+{
+  const char *name;
+  int name_len;
+  unsigned char flag_vars[3];
+  unsigned char flag;
+  void *params[3];
+  bool (*parse_func) (const char *, const char *, void * const[]);
+} envvars[] = {
+  {ENTRY ("OMP_SCHEDULE_DEV"), {OMP_SCHEDULE_DEV_, OMP_SCHEDULE_CHUNK_SIZE_DEV_}, 
GOMP_ENV_VAR_SUFFIX_DEV, {_initial_icvs_dev.run_sched_var, 
_initial_icvs_dev.run_sched_chunk_size}, _schedule},
+  {ENTRY ("OMP_SCHEDULE_ALL"), {OMP_SCHEDULE_DEV_, OMP_SCHEDULE_CHUNK_SIZE_DEV_}, 
GOMP_ENV_VAR_SUFFIX_ALL, {_initial_icvs_all.run_sched_var, 
_initial_icvs_all.run_sched_chunk_size}, _schedule},
+  {ENTRY ("OMP_SCHEDULE"), {OMP_SCHEDULE_DEV_, OMP_SCHEDULE_CHUNK_SIZE_DEV_}, 
GOMP_ENV_VAR_SUFFIX_NONE, {_initial_icvs_none.run_sched_var, 
_initial_icvs_none.run_sched_chunk_size}, _schedule},
+
+  {ENTRY ("OMP_NUM_TEAMS_DEV"), {OMP_NUM_TEAMS_DEV_}, GOMP_ENV_VAR_SUFFIX_DEV , 
{_initial_icvs_dev.nteams_var, false}, _int},
+  {ENTRY ("OMP_NUM_TEAMS_ALL"), {OMP_NUM_TEAMS_DEV_}, GOMP_ENV_VAR_SUFFIX_ALL, 
{_initial_icvs_all.nteams_var, false}, _int},
+  {ENTRY ("OMP_NUM_TEAMS"), {OMP_NUM_TEAMS_DEV_}, GOMP_ENV_VAR_SUFFIX_NONE, 
{_initial_icvs_none.nteams_var, false}, _int},
+
+  {ENTRY ("OMP_DYNAMIC_DEV"), {OMP_DYNAMIC_DEV_}, GOMP_ENV_VAR_SUFFIX_DEV, 
{_initial_icvs_dev.dyn_var}, _boolean},
+  {ENTRY ("OMP_DYNAMIC_ALL"), {OMP_DYNAMIC_DEV_}, GOMP_ENV_VAR_SUFFIX_ALL, 
{_initial_icvs_all.dyn_var}, _boolean},
+  {ENTRY ("OMP_DYNAMIC"), {OMP_DYNAMIC_DEV_}, GOMP_ENV_VAR_SUFFIX_NONE, 
{_initial_icvs_none.dyn_var}, _boolean},
+
+  {ENTRY ("OMP_TEAMS_THREAD_LIMIT_DEV"), 

[PATCH V4] rs6000: Optimize cmp on rotated 16bits constant

2022-07-25 Thread Jiufu Guo via Gcc-patches
Hi,

When checking eq/neq with a constant which has only 16bits, it can be
optimized to check the rotated data.  By this, the constant building
is optimized.

As the example in PR103743:
For "in == 0x8000LL", this patch generates:
rotldi %r3,%r3,16
cmpldi %cr0,%r3,32768
instead:
li %r9,-1
rldicr %r9,%r9,0,0
cmpd %cr0,%r3,%r9

This is a new patch to optimize compare(eq/ne) on rotatable constant.
This patch would be more straitforward than previous patch, like:
https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595576.html.

This patch pass bootstrap and regtest on ppc64 and ppc64le.
Is it ok for trunk?  Thanks for comments!

BR,
Jeff(Jiufu)


PR target/103743

gcc/ChangeLog:

* config/rs6000/rs6000-protos.h (rotate_from_leading_zeros_const):
New decl.
* config/rs6000/rs6000.cc (rotate_from_leading_zeros_const): New
define for checking simply rotated constant.
* config/rs6000/rs6000.md (*rotate_on_cmpdi): New
define_insn_and_split to optimze comparing on rotated constant.

gcc/testsuite/ChangeLog:

* gcc.target/powerpc/pr103743.c: New test.
* gcc.target/powerpc/pr103743_1.c: New test.

---
 gcc/config/rs6000/rs6000-protos.h |  1 +
 gcc/config/rs6000/rs6000.cc   | 29 ++
 gcc/config/rs6000/rs6000.md   | 54 ++-
 gcc/testsuite/gcc.target/powerpc/pr103743.c   | 52 ++
 gcc/testsuite/gcc.target/powerpc/pr103743_1.c | 95 +++
 5 files changed, 230 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.target/powerpc/pr103743.c
 create mode 100644 gcc/testsuite/gcc.target/powerpc/pr103743_1.c

diff --git a/gcc/config/rs6000/rs6000-protos.h 
b/gcc/config/rs6000/rs6000-protos.h
index 3ea01023609..bc7f6ff64ef 100644
--- a/gcc/config/rs6000/rs6000-protos.h
+++ b/gcc/config/rs6000/rs6000-protos.h
@@ -35,6 +35,7 @@ extern bool xxspltib_constant_p (rtx, machine_mode, int *, 
int *);
 extern int vspltis_shifted (rtx);
 extern HOST_WIDE_INT const_vector_elt_as_int (rtx, unsigned int);
 extern bool macho_lo_sum_memory_operand (rtx, machine_mode);
+extern int rotate_from_leading_zeros_const (unsigned HOST_WIDE_INT, int);
 extern int num_insns_constant (rtx, machine_mode);
 extern int small_data_operand (rtx, machine_mode);
 extern bool mem_operand_gpr (rtx, machine_mode);
diff --git a/gcc/config/rs6000/rs6000.cc b/gcc/config/rs6000/rs6000.cc
index 3ff16b8ae04..9c0996603d0 100644
--- a/gcc/config/rs6000/rs6000.cc
+++ b/gcc/config/rs6000/rs6000.cc
@@ -14861,6 +14861,35 @@ rs6000_reverse_condition (machine_mode mode, enum 
rtx_code code)
 return reverse_condition (code);
 }
 
+/* Check if C can be rotated from an immediate which contains leading
+   zeros at least CLZ.
+
+   Return the number by which C can be rotated from the immediate.
+   Return -1 if C can not be rotated as from.  */
+
+int
+rotate_from_leading_zeros_const (unsigned HOST_WIDE_INT c, int clz)
+{
+  /* case. 0..0xxx: already at least clz zeros.  */
+  int lz = clz_hwi (c);
+  if (lz >= clz)
+return 0;
+
+  /* case a. 0..0xxx0..0: at least clz zeros.  */
+  int tz = ctz_hwi (c);
+  if (lz + tz >= clz)
+return tz;
+
+  /* xx0..0xx: rotate enough bits firstly, then check case a.  */
+  const int rot_bits = HOST_BITS_PER_WIDE_INT - clz + 1;
+  unsigned HOST_WIDE_INT rc = (c >> rot_bits) | (c << (clz - 1));
+  tz = ctz_hwi (rc);
+  if (clz_hwi (rc) + tz >= clz)
+return tz + rot_bits;
+
+  return -1;
+}
+
 /* Generate a compare for CODE.  Return a brand-new rtx that
represents the result of the compare.  */
 
diff --git a/gcc/config/rs6000/rs6000.md b/gcc/config/rs6000/rs6000.md
index 1367a2cb779..603781b29aa 100644
--- a/gcc/config/rs6000/rs6000.md
+++ b/gcc/config/rs6000/rs6000.md
@@ -7720,6 +7720,59 @@ (define_insn "*movsi_from_df"
   "xscvdpsp %x0,%x1"
   [(set_attr "type" "fp")])
 
+
+(define_code_iterator eqne [eq ne])
+
+;; "i == C" ==> "rotl(i,N) == rotl(C,N)"
+(define_insn_and_split "*rotate_on_cmpdi"
+  [(set (pc)
+ (if_then_else (eqne (match_operand:DI 1 "gpc_reg_operand" "r")
+(match_operand:DI 2 "const_int_operand" "n"))
+(label_ref (match_operand 0 ""))
+  (pc)))]
+  "TARGET_POWERPC64 && !reload_completed && can_create_pseudo_p ()
+   && num_insns_constant (operands[2], DImode) > 1
+   && (rotate_from_leading_zeros_const (~UINTVAL (operands[2]), 49) > 0
+   || rotate_from_leading_zeros_const (UINTVAL (operands[2]), 48) > 0)"
+   "#"
+   "&& 1"
+  [(pc)]
+{
+  rtx cnd = XEXP (SET_SRC (single_set (curr_insn)), 0);
+  bool ne = GET_CODE (cnd) == NE;
+
+  bool sgn = false;
+  unsigned HOST_WIDE_INT C = INTVAL (operands[2]);
+  int rot = rotate_from_leading_zeros_const (C, 48);
+  if (rot < 0)
+  {
+ sgn = true;
+ rot = rotate_from_leading_zeros_const (~C, 49);
+  }
+  rtx n = GEN_INT (HOST_BITS_PER_WIDE_INT - rot);
+
+  /* i' = rotl (i, n) */
+  

[pushed] c++: -Woverloaded-virtual false positive [PR87729]

2022-07-25 Thread Jason Merrill via Gcc-patches
My attempt to shortcut unnecessary checking after finding a match was
also wrong for multiple inheritance, so let's give up on it.

Tested x86_64-pc-linux-gnu, applying to trunk.

PR c++/87729

gcc/cp/ChangeLog:

* class.cc (warn_hidden): Remove shortcut.

gcc/testsuite/ChangeLog:

* g++.dg/warn/Woverloaded-virt4.C: New test.
---
 gcc/cp/class.cc   | 11 +++
 gcc/testsuite/g++.dg/warn/Woverloaded-virt4.C |  7 +++
 2 files changed, 14 insertions(+), 4 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/warn/Woverloaded-virt4.C

diff --git a/gcc/cp/class.cc b/gcc/cp/class.cc
index eb69e7f985c..a12d3673b96 100644
--- a/gcc/cp/class.cc
+++ b/gcc/cp/class.cc
@@ -3040,22 +3040,25 @@ warn_hidden (tree t)
bool seen_non_override = false;
for (tree fndecl : ovl_range (fns))
  {
+   bool any_override = false;
if (TREE_CODE (fndecl) == FUNCTION_DECL
&& DECL_VINDEX (fndecl))
  {
/* If the method from the base class has the same
   signature as the method from the derived class, it
-  has been overridden.  */
+  has been overridden.  Note that we can't move on
+  after finding one match: fndecl might override
+  multiple base fns.  */
for (size_t k = 0; k < base_fndecls.length (); k++)
  if (base_fndecls[k]
  && same_signature_p (fndecl, base_fndecls[k]))
{
  base_fndecls[k] = NULL_TREE;
- goto next;
+ any_override = true;
}
  }
-   seen_non_override = true;
- next:;
+   if (!any_override)
+ seen_non_override = true;
  }
 
if (!seen_non_override && warn_overloaded_virtual == 1)
diff --git a/gcc/testsuite/g++.dg/warn/Woverloaded-virt4.C 
b/gcc/testsuite/g++.dg/warn/Woverloaded-virt4.C
new file mode 100644
index 000..b4d86689cf5
--- /dev/null
+++ b/gcc/testsuite/g++.dg/warn/Woverloaded-virt4.C
@@ -0,0 +1,7 @@
+// PR c++/87729
+// { dg-additional-options -Woverloaded-virtual }
+
+struct S1 { virtual void f(); };
+struct S2: S1 {};
+struct S3: S1 {};
+struct S4: S2, S3 { void f(); };

base-commit: 718cf8d0bd32689192200d2156722167fd21a647
-- 
2.31.1



[PATCH 5/7] jit,docs: use list-table instead of fixed table

2022-07-25 Thread Martin Liska
Use rather list-table that is easible to maintainer and one
does not have to wrap lines. Moreover, it provides great
attribute :widths: that correctly works (tested for HTML and PDF).

gcc/jit/ChangeLog:

* docs/cp/intro/tutorial04.rst: Use list-table.
* docs/intro/tutorial04.rst: Likewise.
* docs/intro/tutorial05.rst: Likewise.
* docs/topics/compilation.rst: Likewise.
* docs/topics/expressions.rst: Likewise.
* docs/topics/types.rst: Likewise.
---
 gcc/jit/docs/cp/intro/tutorial04.rst |  73 --
 gcc/jit/docs/intro/tutorial04.rst|  73 --
 gcc/jit/docs/intro/tutorial05.rst|  37 +
 gcc/jit/docs/topics/compilation.rst  |  22 --
 gcc/jit/docs/topics/expressions.rst  |  97 ++-
 gcc/jit/docs/topics/types.rst| 111 +--
 6 files changed, 270 insertions(+), 143 deletions(-)

diff --git a/gcc/jit/docs/cp/intro/tutorial04.rst 
b/gcc/jit/docs/cp/intro/tutorial04.rst
index 45198ce3d7a..66dcce903c6 100644
--- a/gcc/jit/docs/cp/intro/tutorial04.rst
+++ b/gcc/jit/docs/cp/intro/tutorial04.rst
@@ -50,30 +50,55 @@ Naturally, a real interpreter would be much more 
complicated that this.
 
 The following operations are supported:
 
-==  === ==
-Operation  Meaning  Old Stack   New Stack
-==  === ==
-DUPDuplicate top of stack.  ``[..., x]````[..., x, x]``
-ROTSwap top two elements``[..., x, y]`` ``[..., y, x]``
-   of stack.
-BINARY_ADD Add the top two elements ``[..., x, y]`` ``[..., 
(x+y)]``
-   on the stack.
-BINARY_SUBTRACTLikewise, but subtract.  ``[..., x, y]`` ``[..., 
(x-y)]``
-BINARY_MULTLikewise, but multiply.  ``[..., x, y]`` ``[..., 
(x*y)]``
-BINARY_COMPARE_LT  Compare the top two  ``[..., x, y]`` ``[..., 
(x``  ``idx += 1``
-``<``  ``idx -= 1``
-``+``  ``data[idx] += 1``
-``-``  ``data[idx] -= 1``
-``.``  ``output (data[idx])``
-``,``  ``data[idx] = input ()``
-``[``  loop until ``data[idx] == 0``
-``]``  end of loop
-Anything else  ignored
-== =
+.. list-table::
+   :header-rows: 1
+
+   * - Character
+ - Meaning
+
+   * - ``>``
+ - ``idx += 1``
+   * - ``<``
+ - ``idx -= 1``
+   * - ``+``
+ - ``data[idx] += 1``
+   * - ``-``
+ - ``data[idx] -= 1``
+   * - ``.``
+ - ``output (data[idx])``
+   * - ``,``
+ - ``data[idx] = input ()``
+   * - ``[``
+ - loop until ``data[idx] == 0``
+   * - ``]``
+ - end of loop
+   * - Anything else
+ - ignored
 
 Unlike the previous example, we'll implement an ahead-of-time compiler,
 which reads ``.bf`` scripts and outputs executables (though it would
diff --git a/gcc/jit/docs/topics/compilation.rst 
b/gcc/jit/docs/topics/compilation.rst
index 91b9c2533cf..adcde8d8eb9 100644
--- a/gcc/jit/docs/topics/compilation.rst
+++ b/gcc/jit/docs/topics/compilation.rst
@@ -169,14 +169,20 @@ For linking in object files, use 
:c:func:`gcc_jit_context_add_driver_option`.
 
 The available kinds of output are:
 
-==  ==
-Output kind Typical suffix
-==  ==
-:c:macro:`GCC_JIT_OUTPUT_KIND_ASSEMBLER`.s
-:c:macro:`GCC_JIT_OUTPUT_KIND_OBJECT_FILE`  .o
-:c:macro:`GCC_JIT_OUTPUT_KIND_DYNAMIC_LIBRARY`  .so or .dll
-:c:macro:`GCC_JIT_OUTPUT_KIND_EXECUTABLE`   None, or .exe
-==  ==
+.. list-table::
+   :header-rows: 1
+
+   * - Output kind
+ - Typical suffix
+
+   * - :c:macro:`GCC_JIT_OUTPUT_KIND_ASSEMBLER`
+ - .s
+   * - :c:macro:`GCC_JIT_OUTPUT_KIND_OBJECT_FILE`
+ - .o
+   * - :c:macro:`GCC_JIT_OUTPUT_KIND_DYNAMIC_LIBRARY`
+ - .so or .dll
+   * - :c:macro:`GCC_JIT_OUTPUT_KIND_EXECUTABLE`
+ - None, or .exe
 
 .. c:macro:: GCC_JIT_OUTPUT_KIND_ASSEMBLER
 
diff --git a/gcc/jit/docs/topics/expressions.rst 
b/gcc/jit/docs/topics/expressions.rst
index 00e2ec8cfeb..ff1eec800ce 100644
--- a/gcc/jit/docs/topics/expressions.rst
+++ b/gcc/jit/docs/topics/expressions.rst
@@ -313,14 +313,20 @@ Unary Operations
 
 The available unary operations are:
 
-==  
-Unary Operation C equivalent
-==  
-:c:macro:`GCC_JIT_UNARY_OP_MINUS`   `-(EXPR)`
-:c:macro:`GCC_JIT_UNARY_OP_BITWISE_NEGATE`  `~(EXPR)`
-:c:macro:`GCC_JIT_UNARY_OP_LOGICAL_NEGATE`  `!(EXPR)`
-:c:macro:`GCC_JIT_UNARY_OP_ABS` 

[PATCH 3/7] jit,docs: various fixes

2022-07-25 Thread Martin Liska
gcc/jit/ChangeLog:

* docs/cp/intro/tutorial02.rst: Use proper reference.
* docs/cp/topics/contexts.rst: Likewise.
* docs/cp/topics/functions.rst: Put `class` directive before a
function as it is not allowed declaring a class in a fn.
* docs/cp/topics/types.rst: Add template keyword.
* docs/examples/tut04-toyvm/toyvm.c (toyvm_function_compile):
Add removed comment used for code snippet ending detection.
* docs/intro/tutorial04.rst: Fix to match the real comment.
---
 gcc/jit/docs/cp/intro/tutorial02.rst  |  2 +-
 gcc/jit/docs/cp/topics/contexts.rst   |  2 +-
 gcc/jit/docs/cp/topics/functions.rst  | 46 +++
 gcc/jit/docs/cp/topics/types.rst  |  2 +-
 gcc/jit/docs/examples/tut04-toyvm/toyvm.c |  1 +
 gcc/jit/docs/intro/tutorial04.rst |  2 +-
 6 files changed, 28 insertions(+), 27 deletions(-)

diff --git a/gcc/jit/docs/cp/intro/tutorial02.rst 
b/gcc/jit/docs/cp/intro/tutorial02.rst
index 2064f8e4dd9..55675cc7398 100644
--- a/gcc/jit/docs/cp/intro/tutorial02.rst
+++ b/gcc/jit/docs/cp/intro/tutorial02.rst
@@ -121,7 +121,7 @@ in this case just one:
   params.push_back (param_i);
 
 Now we can create the function, using
-:c:func:`gccjit::context::new_function`:
+:cpp:func:`gccjit::context::new_function`:
 
 .. code-block:: c++
 
diff --git a/gcc/jit/docs/cp/topics/contexts.rst 
b/gcc/jit/docs/cp/topics/contexts.rst
index e5bccfb807d..f60f2102b3e 100644
--- a/gcc/jit/docs/cp/topics/contexts.rst
+++ b/gcc/jit/docs/cp/topics/contexts.rst
@@ -141,7 +141,7 @@ Debugging
If "update_locations" is true, then also set up :class:`gccjit::location`
information throughout the context, pointing at the dump file as if it
were a source file.  This may be of use in conjunction with
-   :c:macro:`GCCJIT::BOOL_OPTION_DEBUGINFO` to allow stepping through the
+   :c:macro:`GCC_JIT_BOOL_OPTION_DEBUGINFO` to allow stepping through the
code in a debugger.
 
 .. function:: void\
diff --git a/gcc/jit/docs/cp/topics/functions.rst 
b/gcc/jit/docs/cp/topics/functions.rst
index 0e266abc70c..4e325ac3fef 100644
--- a/gcc/jit/docs/cp/topics/functions.rst
+++ b/gcc/jit/docs/cp/topics/functions.rst
@@ -243,6 +243,29 @@ Statements
 
   return;
 
+.. class:: gccjit::case_
+
+   A `gccjit::case_` represents a case within a switch statement, and
+   is created within a particular :class:`gccjit::context` using
+   :func:`gccjit::context::new_case`.  It is a subclass of
+   :class:`gccjit::object`.
+
+   Each case expresses a multivalued range of integer values.  You
+   can express single-valued cases by passing in the same value for
+   both `min_value` and `max_value`.
+
+.. function:: gccjit::case_ *\
+   gccjit::context::new_case (gccjit::rvalue min_value,\
+  gccjit::rvalue max_value,\
+  gccjit::block dest_block)
+
+Create a new gccjit::case for use in a switch statement.
+`min_value` and `max_value` must be constants of an integer type,
+which must match that of the expression of the switch statement.
+
+`dest_block` must be within the same function as the switch
+statement.
+
 .. function:: void\
   gccjit::block::end_with_switch (gccjit::rvalue expr,\
   gccjit::block default_block,\
@@ -292,29 +315,6 @@ Statements
 
   #ifdef LIBGCCJIT_HAVE_SWITCH_STATEMENTS
 
-   .. class:: gccjit::case_
-
-   A `gccjit::case_` represents a case within a switch statement, and
-   is created within a particular :class:`gccjit::context` using
-   :func:`gccjit::context::new_case`.  It is a subclass of
-   :class:`gccjit::object`.
-
-   Each case expresses a multivalued range of integer values.  You
-   can express single-valued cases by passing in the same value for
-   both `min_value` and `max_value`.
-
-   .. function:: gccjit::case_ *\
- gccjit::context::new_case (gccjit::rvalue min_value,\
-gccjit::rvalue max_value,\
-gccjit::block dest_block)
-
-  Create a new gccjit::case for use in a switch statement.
-  `min_value` and `max_value` must be constants of an integer type,
-  which must match that of the expression of the switch statement.
-
-  `dest_block` must be within the same function as the switch
-  statement.
-
Here's an example of creating a switch statement:
 
  .. literalinclude:: ../../../../testsuite/jit.dg/test-switch.cc
diff --git a/gcc/jit/docs/cp/topics/types.rst b/gcc/jit/docs/cp/topics/types.rst
index c695ceb3098..5d50a39b9d0 100644
--- a/gcc/jit/docs/cp/topics/types.rst
+++ b/gcc/jit/docs/cp/topics/types.rst
@@ -65,7 +65,7 @@ Standard types
 
Access the integer type of the given size.
 
-.. function:: gccjit::type \
+.. function:: template gccjit::type \
   gccjit::context::get_int_type  ()
 

[PATCH 4/7] jit,docs: compact function declarations

2022-07-25 Thread Martin Liska
gcc/jit/ChangeLog:

* docs/cp/topics/expressions.rst: Compact so that the generated
output is also more compact.
---
 gcc/jit/docs/cp/topics/expressions.rst | 42 +-
 1 file changed, 14 insertions(+), 28 deletions(-)

diff --git a/gcc/jit/docs/cp/topics/expressions.rst 
b/gcc/jit/docs/cp/topics/expressions.rst
index 003dbce8991..dec5b477811 100644
--- a/gcc/jit/docs/cp/topics/expressions.rst
+++ b/gcc/jit/docs/cp/topics/expressions.rst
@@ -236,48 +236,39 @@ operation:
   gccjit::context::new_plus (gccjit::type result_type, \
  gccjit::rvalue a, gccjit::rvalue b, \
  gccjit::location loc)
-
-.. function:: gccjit::rvalue \
+  gccjit::rvalue \
   gccjit::context::new_minus (gccjit::type result_type, \
   gccjit::rvalue a, gccjit::rvalue b, \
   gccjit::location loc)
-
-.. function:: gccjit::rvalue \
+  gccjit::rvalue \
   gccjit::context::new_mult (gccjit::type result_type, \
  gccjit::rvalue a, gccjit::rvalue b, \
  gccjit::location loc)
-
-.. function:: gccjit::rvalue \
+  gccjit::rvalue \
   gccjit::context::new_divide (gccjit::type result_type, \
gccjit::rvalue a, gccjit::rvalue b, 
\
gccjit::location loc)
-
-.. function:: gccjit::rvalue \
+  gccjit::rvalue \
   gccjit::context::new_modulo (gccjit::type result_type, \
gccjit::rvalue a, gccjit::rvalue b, 
\
gccjit::location loc)
-
-.. function:: gccjit::rvalue \
+  gccjit::rvalue \
   gccjit::context::new_bitwise_and (gccjit::type result_type, \
 gccjit::rvalue a, 
gccjit::rvalue b, \
 gccjit::location loc)
-
-.. function:: gccjit::rvalue \
+  gccjit::rvalue \
   gccjit::context::new_bitwise_xor (gccjit::type result_type, \
 gccjit::rvalue a, 
gccjit::rvalue b, \
 gccjit::location loc)
-
-.. function:: gccjit::rvalue \
+  gccjit::rvalue \
   gccjit::context::new_bitwise_or (gccjit::type result_type, \
gccjit::rvalue a, 
gccjit::rvalue b, \
gccjit::location loc)
-
-.. function:: gccjit::rvalue \
+  gccjit::rvalue \
   gccjit::context::new_logical_and (gccjit::type result_type, \
 gccjit::rvalue a, 
gccjit::rvalue b, \
 gccjit::location loc)
-
-.. function:: gccjit::rvalue \
+  gccjit::rvalue \
   gccjit::context::new_logical_or (gccjit::type result_type, \
gccjit::rvalue a, 
gccjit::rvalue b, \
gccjit::location loc)
@@ -375,24 +366,19 @@ operation:
 .. function:: gccjit::rvalue \
   gccjit::context::new_eq (gccjit::rvalue a, gccjit::rvalue b, \
gccjit::location loc)
-
-.. function:: gccjit::rvalue \
+  gccjit::rvalue \
   gccjit::context::new_ne (gccjit::rvalue a, gccjit::rvalue b, \
gccjit::location loc)
-
-.. function:: gccjit::rvalue \
+  gccjit::rvalue \
   gccjit::context::new_lt (gccjit::rvalue a, gccjit::rvalue b, \
gccjit::location loc)
-
-.. function:: gccjit::rvalue \
+  gccjit::rvalue \
   gccjit::context::new_le (gccjit::rvalue a, gccjit::rvalue b, \
gccjit::location loc)
-
-.. function:: gccjit::rvalue \
+  gccjit::rvalue \
   gccjit::context::new_gt (gccjit::rvalue a, gccjit::rvalue b, \
gccjit::location loc)
-
-.. function:: gccjit::rvalue \
+  gccjit::rvalue \
   gccjit::context::new_ge (gccjit::rvalue a, gccjit::rvalue b, \
gccjit::location loc)
 
-- 
2.37.1




[PATCH 1/7] jit,docs: use enum directive for enumeral types

2022-07-25 Thread Martin Liska
gcc/jit/ChangeLog:

* docs/conf.py: Add needs_sphinx = '3.0' where c:type was added.
* docs/index.rst: Remove note about it.
* docs/topics/compilation.rst: Use enum directive and reference.
* docs/topics/contexts.rst: Likewise.
* docs/topics/expressions.rst: Likewise.
* docs/topics/functions.rst: Likewise.
---
 gcc/jit/docs/conf.py|  3 +++
 gcc/jit/docs/index.rst  |  7 ---
 gcc/jit/docs/topics/compilation.rst |  4 ++--
 gcc/jit/docs/topics/contexts.rst|  6 +++---
 gcc/jit/docs/topics/expressions.rst | 10 +-
 gcc/jit/docs/topics/functions.rst   |  2 +-
 6 files changed, 14 insertions(+), 18 deletions(-)

diff --git a/gcc/jit/docs/conf.py b/gcc/jit/docs/conf.py
index 00f0e9887dd..062232ae280 100644
--- a/gcc/jit/docs/conf.py
+++ b/gcc/jit/docs/conf.py
@@ -39,6 +39,9 @@ source_suffix = '.rst'
 # The master toctree document.
 master_doc = 'index'
 
+# c:type directive is supported since 3.0
+needs_sphinx = '3.0'
+
 # General information about the project.
 project = u'libgccjit'
 copyright = u'2014-2022 Free Software Foundation, Inc.'
diff --git a/gcc/jit/docs/index.rst b/gcc/jit/docs/index.rst
index 3aff17d7a60..21c3140e238 100644
--- a/gcc/jit/docs/index.rst
+++ b/gcc/jit/docs/index.rst
@@ -45,10 +45,3 @@ Indices and tables
 * :ref:`genindex`
 * :ref:`modindex`
 * :ref:`search`
-
-.. Some notes:
-
-   The Sphinx C domain appears to lack explicit support for enum values,
-   so I've been using :c:macro: for them.
-
-   See https://sphinx-doc.org/domains.html#the-c-domain
diff --git a/gcc/jit/docs/topics/compilation.rst 
b/gcc/jit/docs/topics/compilation.rst
index 9b1eed2dede..c5fa6eb0faf 100644
--- a/gcc/jit/docs/topics/compilation.rst
+++ b/gcc/jit/docs/topics/compilation.rst
@@ -158,14 +158,14 @@ For linking in object files, use 
:c:func:`gcc_jit_context_add_driver_option`.
 
 :c:func:`gcc_jit_context_compile_to_file` ignores the suffix of
 ``output_path``, and insteads uses the given
-:c:type:`enum gcc_jit_output_kind` to decide what to do.
+:c:enum:`gcc_jit_output_kind` to decide what to do.
 
 .. note::
 
This is different from the ``gcc`` program, which does make use of the
suffix of the output file when determining what to do.
 
-.. type:: enum gcc_jit_output_kind
+.. enum:: gcc_jit_output_kind
 
 The available kinds of output are:
 
diff --git a/gcc/jit/docs/topics/contexts.rst b/gcc/jit/docs/topics/contexts.rst
index dfbe968e127..205b5f3dcf5 100644
--- a/gcc/jit/docs/topics/contexts.rst
+++ b/gcc/jit/docs/topics/contexts.rst
@@ -311,7 +311,7 @@ String Options
 
Set a string option of the context.
 
-   .. type:: enum gcc_jit_str_option
+   .. enum:: gcc_jit_str_option
 
The parameter ``value`` can be NULL.   If non-NULL, the call takes a
copy of the underlying string, so it is valid to pass in a pointer to
@@ -334,7 +334,7 @@ Boolean options
   Set a boolean option of the context.
   Zero is "false" (the default), non-zero is "true".
 
-  .. type:: enum gcc_jit_bool_option
+  .. enum:: gcc_jit_bool_option
 
   .. macro:: GCC_JIT_BOOL_OPTION_DEBUGINFO
 
@@ -513,7 +513,7 @@ Integer options
 
   Set an integer option of the context.
 
-  .. type:: enum gcc_jit_int_option
+  .. enum:: gcc_jit_int_option
 
   There is just one integer option specified this way:
 
diff --git a/gcc/jit/docs/topics/expressions.rst 
b/gcc/jit/docs/topics/expressions.rst
index 91ee8a9c74a..49b7e14ae2b 100644
--- a/gcc/jit/docs/topics/expressions.rst
+++ b/gcc/jit/docs/topics/expressions.rst
@@ -309,7 +309,7 @@ Unary Operations
 
The parameter ``result_type`` must be a numeric type.
 
-.. type:: enum gcc_jit_unary_op
+.. enum:: gcc_jit_unary_op
 
 The available unary operations are:
 
@@ -376,7 +376,7 @@ Binary Operations
 
The parameter ``result_type`` must be a numeric type.
 
-.. type:: enum gcc_jit_binary_op
+.. enum:: gcc_jit_binary_op
 
 The available binary operations are:
 
@@ -534,7 +534,7 @@ Comparisons
 
Build a boolean rvalue out of the comparison of two other rvalues.
 
-.. type:: enum gcc_jit_comparison
+.. enum:: gcc_jit_comparison
 
 ===  
 Comparison   C equivalent
@@ -711,7 +711,7 @@ where the rvalue is computed by reading from the storage 
area.
 
The "model" parameter determines the thread-local storage model of the 
"lvalue":
 
-   .. type:: enum gcc_jit_tls_model
+   .. enum:: gcc_jit_tls_model
 
.. c:macro:: GCC_JIT_TLS_MODEL_NONE
 
@@ -841,7 +841,7 @@ Global variables
The "kind" parameter determines the visibility of the "global" outside
of the :c:type:`gcc_jit_result`:
 
-   .. type:: enum gcc_jit_global_kind
+   .. enum:: gcc_jit_global_kind
 
.. c:macro:: GCC_JIT_GLOBAL_EXPORTED
 
diff --git a/gcc/jit/docs/topics/functions.rst 
b/gcc/jit/docs/topics/functions.rst
index 0845fe0f7d3..d6d4fe90834 100644
--- a/gcc/jit/docs/topics/functions.rst
+++ b/gcc/jit/docs/topics/functions.rst
@@ 

[PATCH 2/7] jit, docs: replace c:type:`int_type` with :expr:`int_type`

2022-07-25 Thread Martin Liska
Use expression that work fine for basic type.

gcc/jit/ChangeLog:

* docs/cp/topics/expressions.rst: Use :expr: for basic types.
* docs/topics/compilation.rst: Likewise.
* docs/topics/expressions.rst: Likewise.
* docs/topics/function-pointers.rst: Likewise.
---
 gcc/jit/docs/cp/topics/expressions.rst| 6 +++---
 gcc/jit/docs/topics/compilation.rst   | 4 ++--
 gcc/jit/docs/topics/expressions.rst   | 6 +++---
 gcc/jit/docs/topics/function-pointers.rst | 2 +-
 4 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/gcc/jit/docs/cp/topics/expressions.rst 
b/gcc/jit/docs/cp/topics/expressions.rst
index 239e004371e..003dbce8991 100644
--- a/gcc/jit/docs/cp/topics/expressions.rst
+++ b/gcc/jit/docs/cp/topics/expressions.rst
@@ -57,14 +57,14 @@ Simple expressions
int value) const
 
Given a numeric type (integer or floating point), build an rvalue for
-   the given constant :c:type:`int` value.
+   the given constant :expr:`int` value.
 
 .. function:: gccjit::rvalue \
   gccjit::context::new_rvalue (gccjit::type numeric_type, \
long value) const
 
Given a numeric type (integer or floating point), build an rvalue for
-   the given constant :c:type:`long` value.
+   the given constant :expr:`long` value.
 
 .. function::  gccjit::rvalue \
gccjit::context::zero (gccjit::type numeric_type) const
@@ -91,7 +91,7 @@ Simple expressions
 double value) const
 
Given a numeric type (integer or floating point), build an rvalue for
-   the given constant :c:type:`double` value.
+   the given constant :expr:`double` value.
 
 .. function:: gccjit::rvalue \
   gccjit::context::new_rvalue (gccjit::type pointer_type, \
diff --git a/gcc/jit/docs/topics/compilation.rst 
b/gcc/jit/docs/topics/compilation.rst
index c5fa6eb0faf..91b9c2533cf 100644
--- a/gcc/jit/docs/topics/compilation.rst
+++ b/gcc/jit/docs/topics/compilation.rst
@@ -98,8 +98,8 @@ In-memory compilation
If the global is found, the result will need to be cast to a
pointer of the correct type before it can be called.
 
-   This is a *pointer* to the global, so e.g. for an :c:type:`int` this is
-   an :c:type:`int *`.
+   This is a *pointer* to the global, so e.g. for an :expr:`int` this is
+   an :expr:`int *`.
 
For example, given an ``int foo;`` created this way:
 
diff --git a/gcc/jit/docs/topics/expressions.rst 
b/gcc/jit/docs/topics/expressions.rst
index 49b7e14ae2b..00e2ec8cfeb 100644
--- a/gcc/jit/docs/topics/expressions.rst
+++ b/gcc/jit/docs/topics/expressions.rst
@@ -60,7 +60,7 @@ Simple expressions
int value)
 
Given a numeric type (integer or floating point), build an rvalue for
-   the given constant :c:type:`int` value.
+   the given constant :expr:`int` value.
 
 .. function:: gcc_jit_rvalue *\
   gcc_jit_context_new_rvalue_from_long (gcc_jit_context *ctxt, \
@@ -68,7 +68,7 @@ Simple expressions
 long value)
 
Given a numeric type (integer or floating point), build an rvalue for
-   the given constant :c:type:`long` value.
+   the given constant :expr:`long` value.
 
 .. function::  gcc_jit_rvalue *gcc_jit_context_zero (gcc_jit_context *ctxt, \
  gcc_jit_type 
*numeric_type)
@@ -96,7 +96,7 @@ Simple expressions
double value)
 
Given a numeric type (integer or floating point), build an rvalue for
-   the given constant :c:type:`double` value.
+   the given constant :expr:`double` value.
 
 .. function:: gcc_jit_rvalue *\
   gcc_jit_context_new_rvalue_from_ptr (gcc_jit_context *ctxt, \
diff --git a/gcc/jit/docs/topics/function-pointers.rst 
b/gcc/jit/docs/topics/function-pointers.rst
index e6f9970a7a7..dde49215853 100644
--- a/gcc/jit/docs/topics/function-pointers.rst
+++ b/gcc/jit/docs/topics/function-pointers.rst
@@ -48,7 +48,7 @@ to it in :c:type:`gcc_jit_rvalue` form using
 type obtained using :c:func:`gcc_jit_context_new_function_ptr_type`.
 
 Here's an example of creating a function pointer type corresponding to C's
-:c:type:`void (*) (int, int, int)`:
+:expr:`void (*) (int, int, int)`:
 
 .. code-block:: c
 
-- 
2.37.1




[PATCH 6/7] jit,docs: use :expr:`type *` for pointers to a type

2022-07-25 Thread Martin Liska
gcc/jit/ChangeLog:

* docs/cp/intro/tutorial02.rst: Use :expr:`type *` for pointers to a 
type
* docs/cp/topics/asm.rst: Likewise.
* docs/cp/topics/contexts.rst: Likewise.
* docs/cp/topics/expressions.rst: Likewise.
* docs/cp/topics/functions.rst: Likewise.
* docs/cp/topics/objects.rst: Likewise.
* docs/intro/tutorial02.rst: Likewise.
* docs/intro/tutorial03.rst: Likewise.
* docs/intro/tutorial04.rst: Likewise.
* docs/intro/tutorial05.rst: Likewise.
* docs/topics/compilation.rst: Likewise.
* docs/topics/contexts.rst: Likewise.
* docs/topics/objects.rst: Likewise.
---
 gcc/jit/docs/cp/intro/tutorial02.rst   |  4 ++--
 gcc/jit/docs/cp/topics/asm.rst |  2 +-
 gcc/jit/docs/cp/topics/contexts.rst|  6 +++---
 gcc/jit/docs/cp/topics/expressions.rst |  4 ++--
 gcc/jit/docs/cp/topics/functions.rst   |  2 +-
 gcc/jit/docs/cp/topics/objects.rst |  2 +-
 gcc/jit/docs/intro/tutorial02.rst  | 16 +++
 gcc/jit/docs/intro/tutorial03.rst  | 28 +-
 gcc/jit/docs/intro/tutorial04.rst  |  2 +-
 gcc/jit/docs/intro/tutorial05.rst  |  4 ++--
 gcc/jit/docs/topics/compilation.rst|  8 
 gcc/jit/docs/topics/contexts.rst   |  6 +++---
 gcc/jit/docs/topics/objects.rst|  6 +++---
 13 files changed, 45 insertions(+), 45 deletions(-)

diff --git a/gcc/jit/docs/cp/intro/tutorial02.rst 
b/gcc/jit/docs/cp/intro/tutorial02.rst
index 55675cc7398..9f9a7f3858e 100644
--- a/gcc/jit/docs/cp/intro/tutorial02.rst
+++ b/gcc/jit/docs/cp/intro/tutorial02.rst
@@ -39,7 +39,7 @@ First we need to include the relevant header:
 
 All state associated with compilation is associated with a
 :type:`gccjit::context`, which is a thin C++ wrapper around the C API's
-:c:type:`gcc_jit_context *`.
+:c:expr:`gcc_jit_context *`.
 
 Create one using :func:`gccjit::context::acquire`:
 
@@ -194,7 +194,7 @@ OK, we've populated the context.  We can now compile it 
using
gcc_jit_result *result;
result = ctxt.compile ();
 
-and get a :c:type:`gcc_jit_result *`.
+and get a :c:expr:`gcc_jit_result *`.
 
 We can now use :c:func:`gcc_jit_result_get_code` to look up a specific
 machine code routine within the result, in this case, the function we
diff --git a/gcc/jit/docs/cp/topics/asm.rst b/gcc/jit/docs/cp/topics/asm.rst
index f7e4e952b10..0d63da3d59e 100644
--- a/gcc/jit/docs/cp/topics/asm.rst
+++ b/gcc/jit/docs/cp/topics/asm.rst
@@ -43,7 +43,7 @@ Adding assembler instructions within a function
to outputs.
 
:class:`gccjit::extended_asm` is a subclass of :class:`gccjit::object`.
-   It is a thin wrapper around the C API's :c:type:`gcc_jit_extended_asm *`.
+   It is a thin wrapper around the C API's :c:expr:`gcc_jit_extended_asm *`.
 
To avoid having an API entrypoint with a very large number of
parameters, an extended ``asm`` statement is made in stages:
diff --git a/gcc/jit/docs/cp/topics/contexts.rst 
b/gcc/jit/docs/cp/topics/contexts.rst
index f60f2102b3e..2f2456a9c0d 100644
--- a/gcc/jit/docs/cp/topics/contexts.rst
+++ b/gcc/jit/docs/cp/topics/contexts.rst
@@ -29,9 +29,9 @@ compilation.
 
 You can set up options on it, and add types, functions and code.
 Invoking :func:`gccjit::context::compile` on it gives you a
-:c:type:`gcc_jit_result *`.
+:c:expr:`gcc_jit_result *`.
 
-It is a thin wrapper around the C API's :c:type:`gcc_jit_context *`.
+It is a thin wrapper around the C API's :c:expr:`gcc_jit_context *`.
 
 Lifetime-management
 ---
@@ -48,7 +48,7 @@ cleanup of such objects is done for you when the context is 
released.
 .. function:: void gccjit::context::release ()
 
   This function releases all resources associated with the given context.
-  Both the context itself and all of its :c:type:`gccjit::object *`
+  Both the context itself and all of its :expr:`gccjit::object *`
   instances are cleaned up.  It should be called exactly once on a given
   context.
 
diff --git a/gcc/jit/docs/cp/topics/expressions.rst 
b/gcc/jit/docs/cp/topics/expressions.rst
index dec5b477811..01eb2898d0d 100644
--- a/gcc/jit/docs/cp/topics/expressions.rst
+++ b/gcc/jit/docs/cp/topics/expressions.rst
@@ -26,7 +26,7 @@ Rvalues
 
 A :class:`gccjit::rvalue` is an expression that can be computed.  It is a
 subclass of :class:`gccjit::object`, and is a thin wrapper around
-:c:type:`gcc_jit_rvalue *` from the C API.
+:c:expr:`gcc_jit_rvalue *` from the C API.
 
 It can be simple, e.g.:
 
@@ -491,7 +491,7 @@ a storage area (such as a variable).  It is a subclass of
 :class:`gccjit::rvalue`, where the rvalue is computed by reading from the
 storage area.
 
-It iss a thin wrapper around :c:type:`gcc_jit_lvalue *` from the C API.
+It iss a thin wrapper around :c:expr:`gcc_jit_lvalue *` from the C API.
 
 .. function:: gccjit::rvalue \
   gccjit::lvalue::get_address (gccjit::location loc)
diff --git a/gcc/jit/docs/cp/topics/functions.rst 

[PATCH 0/7] jit,docs: remove warnings and modernize the docs

2022-07-25 Thread Martin Liska
The patch set modernizes the documentation and removes most of the reported 
Sphinx
warnings.

Ready for master?
Thanks,
Martin

Martin Liska (7):
  jit,docs: use enum directive for enumeral types
  jit,docs: replace c:type:`int_type` with :expr:`int_type`
  jit,docs: various fixes
  jit,docs: compact function declarations
  jit,docs: use list-table instead of fixed table
  jit,docs: use :expr:`type *` for pointers to a type
  jit,docs: remove :ref:`modindex`

 gcc/jit/docs/conf.py  |   3 +
 gcc/jit/docs/cp/intro/tutorial02.rst  |   6 +-
 gcc/jit/docs/cp/intro/tutorial04.rst  |  73 +-
 gcc/jit/docs/cp/topics/asm.rst|   2 +-
 gcc/jit/docs/cp/topics/contexts.rst   |   8 +-
 gcc/jit/docs/cp/topics/expressions.rst|  52 --
 gcc/jit/docs/cp/topics/functions.rst  |  48 +-
 gcc/jit/docs/cp/topics/objects.rst|   2 +-
 gcc/jit/docs/cp/topics/types.rst  |   2 +-
 gcc/jit/docs/examples/tut04-toyvm/toyvm.c |   1 +
 gcc/jit/docs/index.rst|   8 --
 gcc/jit/docs/intro/tutorial02.rst |  16 ++--
 gcc/jit/docs/intro/tutorial03.rst |  28 +++---
 gcc/jit/docs/intro/tutorial04.rst |  77 ++-
 gcc/jit/docs/intro/tutorial05.rst |  41 +---
 gcc/jit/docs/topics/compilation.rst   |  38 
 gcc/jit/docs/topics/contexts.rst  |  12 +--
 gcc/jit/docs/topics/expressions.rst   | 111 ++
 gcc/jit/docs/topics/function-pointers.rst |   2 +-
 gcc/jit/docs/topics/functions.rst |   2 +-
 gcc/jit/docs/topics/objects.rst   |   6 +-
 gcc/jit/docs/topics/types.rst | 111 ++
 22 files changed, 379 insertions(+), 270 deletions(-)

-- 
2.37.1



[PATCH] middle-end/106414 - fix mistake in ~(x ^ y) -> x == y pattern

2022-07-25 Thread Richard Biener via Gcc-patches
When compares are integer typed the inversion with ~ isn't properly
preserved by the equality comparison even when converting the
result properly.  The following fixes this by restricting the
input precisions accordingly.

Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.

PR middle-end/106414
* match.pd (~(x ^ y) -> x == y): Restrict to single bit
precision types.

* gcc.dg/torture/pr106414-1.c: New testcase.
* gcc.dg/torture/pr106414-2.c: Likewise.
---
 gcc/match.pd  |  3 ++-
 gcc/testsuite/gcc.dg/torture/pr106414-1.c | 12 
 gcc/testsuite/gcc.dg/torture/pr106414-2.c | 12 
 3 files changed, 26 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.dg/torture/pr106414-1.c
 create mode 100644 gcc/testsuite/gcc.dg/torture/pr106414-2.c

diff --git a/gcc/match.pd b/gcc/match.pd
index 9736393061a..330c1db0c8e 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -1946,7 +1946,8 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
 /* ~(a ^ b) is a == b for truth valued a and b.  */
 (simplify
  (bit_not (bit_xor:s truth_valued_p@0 truth_valued_p@1))
- (if (!VECTOR_TYPE_P (type))
+ (if (INTEGRAL_TYPE_P (TREE_TYPE (@0))
+  && TYPE_PRECISION (TREE_TYPE (@0)) == 1)
   (convert (eq @0 @1
 
 /* (x & ~m) | (y & m) -> ((x ^ y) & m) ^ x */
diff --git a/gcc/testsuite/gcc.dg/torture/pr106414-1.c 
b/gcc/testsuite/gcc.dg/torture/pr106414-1.c
new file mode 100644
index 000..097471617b4
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/torture/pr106414-1.c
@@ -0,0 +1,12 @@
+/* { dg-do run } */
+
+int a, c, e;
+const int b = 1;
+char d;
+int main() {
+  a = ~(e || 0) ^ b & ~d;
+  d = ~(a | ~2);
+  if (d)
+__builtin_abort();
+  return 0;
+}
diff --git a/gcc/testsuite/gcc.dg/torture/pr106414-2.c 
b/gcc/testsuite/gcc.dg/torture/pr106414-2.c
new file mode 100644
index 000..bed6a40c61e
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/torture/pr106414-2.c
@@ -0,0 +1,12 @@
+/* { dg-do run } */
+
+int a, b, c, d;
+unsigned e;
+int main() {
+  c = e = -((a && 1) ^ ~(b || 0));
+  if (e < -1)
+d = c;
+  if (!d)
+__builtin_abort();
+  return 0;
+}
-- 
2.35.3


Re: [PATCH] Fortran: fix invalid rank error in ASSOCIATED when rank is remapped [PR77652]

2022-07-25 Thread Mikael Morin

Le 21/07/2022 à 22:12, Harald Anlauf via Fortran a écrit :

Dear all,

the rank check for ASSOCIATED (POINTER, TARGET) did not allow all
rank combinations that were allowed in pointer assignment for
newer versions of the Fortran standard (F2008+).  Fix the logic.


So, if I understand correctly the (fixed) logic, it is:
 f2008+=> no check
 f2003 => check target’s rank different from 1
 up to f95 => check pointer’s rank equals target’s


I think one check is missing, that is when pointer is scalar and the 
target is non-scalar (either rank 1 or not).  This case should also be 
rejected for f2003+, not just up to f95.


Mikael


Re: [PATCH 9/12 V2] arm: Make libgcc bti compatible

2022-07-25 Thread Richard Earnshaw via Gcc-patches




On 22/07/2022 16:09, Andrea Corallo via Gcc-patches wrote:

Richard Earnshaw  writes:


On 21/07/2022 10:17, Andrea Corallo via Gcc-patches wrote:

Richard Earnshaw  writes:


On 28/04/2022 10:48, Andrea Corallo via Gcc-patches wrote:

This change add bti instructions at the beginning of arm specific
libgcc hand written assembly routines.
2022-03-31  Andrea Corallo  
* libgcc/config/arm/crti.S (FUNC_START): Add bti instruction
if
necessary.
* libgcc/config/arm/lib1funcs.S (THUMB_FUNC_START, FUNC_START):
Likewise.



+#if defined(__ARM_FEATURE_BTI)

Wouldn't it be better to use __ARM_FEATURE_BTI_DEFAULT?  That way we
only get BTI instructions in multilib variants that have asked for
BTI.

R.

Hi Richard,
good point, yes I think so.
Please find attached the updated patch.
BR
Andrea



I've been pondering this patch.  The way it is implemented would put a
BTI instruction at the start of every assembler routine in libgcc.
But the vast majority of functions in libgcc cannot have their address
taken, so a BTI isn't needed (BTI is only needed when an indirect jump
could be used).  So I wonder if we really need to do this so
aggressively?

Perhaps a better approach would be to define a macro (eg MAYBEBTI)
which expands a BTI if the compilation requires it and nothing
otherwise), and then manually insert that in any functions that really
need this (if any).


I guess the main downside of this approach would be the maintanace
burden, we'll have to remember forever that every time an asm function
is called by function pointer we have to add the bti landing pad
manually, otherwise this will be broken when pacbti enabled. WDYT?

If we want to go this way I'll start reworking the patch in this
direction (tho this might not be trivial).



Yes, it's a trade-off.  The lazy way, however, costs all users even if a 
function is never addressed (which I think is the case for practically 
all functions in libgcc).


So I think in this case it's worth taking that extra development pain.

R.

BR

   Andrea


Re: [PATCH V1] HIGH part of symbol ref is invalid for constant pool

2022-07-25 Thread Kewen.Lin via Gcc-patches
Hi Jeff,

on 2022/7/19 22:30, Jiufu Guo wrote:
> Hi,
> 
> In patch https://gcc.gnu.org/pipermail/gcc-patches/2022-July/597712.html,
> test case was not added.  After more check, a testcase is added for it.
> 

Good to see that you constructed one actual test case, nice!  :)

> The high part of the symbol address is invalid for the constant pool.
> In function rs6000_cannot_force_const_mem, we already return true for
> "HIGH with UNSPEC" rtx.  Below are some examples also indicate the high
> part of a symbol_ref:
> (high:DI (const:DI (plus:DI (symbol_ref:DI ("xx") (const_int 12 [0xc])
> (high:DI (symbol_ref:DI ("var_1")..)))
> 
> This patch updates rs6000_cannot_force_const_mem to return true for
> rtx with HIGH code.
> 
> Bootstrapped and regtested on ppc64le and ppc64.
> Is it ok for trunk?

I think this patch is OK with some nits below tweaked.

> 
> BR,
> Jeff(Jiufu)
> 
> 
> gcc/ChangeLog:
> 
>   * config/rs6000/rs6000.cc (rs6000_cannot_force_const_mem):
>   Return true for HIGH code rtx.
> 
> gcc/testsuite/ChangeLog:
> 
>   * gcc.target/powerpc/constpoolcheck.c: New test.
> 
> ---
>  gcc/config/rs6000/rs6000.cc   |  7 +--
>  gcc/testsuite/gcc.target/powerpc/constpoolcheck.c | 11 +++
>  2 files changed, 16 insertions(+), 2 deletions(-)
>  create mode 100644 gcc/testsuite/gcc.target/powerpc/constpoolcheck.c
> 
> diff --git a/gcc/config/rs6000/rs6000.cc b/gcc/config/rs6000/rs6000.cc
> index 0af2085adc0..d56832ebbfc 100644
> --- a/gcc/config/rs6000/rs6000.cc
> +++ b/gcc/config/rs6000/rs6000.cc
> @@ -9704,8 +9704,11 @@ rs6000_init_stack_protect_guard (void)
>  static bool
>  rs6000_cannot_force_const_mem (machine_mode mode ATTRIBUTE_UNUSED, rtx x)
>  {
> -  if (GET_CODE (x) == HIGH
> -  && GET_CODE (XEXP (x, 0)) == UNSPEC)
> +  /* High part of a symbol ref/address can not be put into constant pool. 
> e.g.

Nit: two spaces after the period in "... pool.".

> + (high:DI (symbol_ref:DI ("var")..)) or

Nit: You have one "or" at the end of the above line, I think it's better to
keep the below line consistent by either removing the above " or" or adding
one "or" at the end of the below line.

> + (high:DI (unspec:DI [(symbol_ref/u:DI ("*.LC0")..)


> + (high:DI (const:DI (plus:DI (symbol_ref:DI ("xx")) (const_int 12.  
> */
> +  if (GET_CODE (x) == HIGH)
>  return true;
> 
>/* A TLS symbol in the TOC cannot contain a sum.  */
> diff --git a/gcc/testsuite/gcc.target/powerpc/constpoolcheck.c 
> b/gcc/testsuite/gcc.target/powerpc/constpoolcheck.c
> new file mode 100644
> index 000..ed7a994827b
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/powerpc/constpoolcheck.c

Maybe it's good to name it to "const-pool-check.c" or "not-force-const-mem.c".

> @@ -0,0 +1,11 @@
> +/* { dg-do compile { target powerpc*-*-* } } */

Nit: this "dg-do" line isn't needed since all here are default.

BR,
Kewen

> +/* { dg-options "-O1 -mdejagnu-cpu=power10" } */
> +/* (high:DI (symbol_ref:DI ("var_48")..))) should not cause ICE. */
> +extern short var_48;
> +void
> +foo (double *r)
> +{
> +  if (var_48)
> +*r = 1234.5678;
> +}
> +


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

2022-07-25 Thread Gaius Mulley via Gcc-patches
Rainer Orth  writes:

>> I think this just leaves:
>>
>>> * While this lets the build finish on all of i386-pc-solaris2.11,
>>>   sparcv9-sun-solaris2.11, and x86_64-pc-linux-gnu, I get thousands of
>>>   testsuite failures, all of the same kind:
>>>
>>> Undefined   first referenced
>>>  symbol in file
>>> RTco_signal 
>>> /var/gcc/modula-2/11.4-gcc-modula-2/i386-pc-solaris2.11/./libgm2/libm2pim/.libs/libm2pim.so
>>> RTco_select 
>>> /var/gcc/modula-2/11.4-gcc-modula-2/i386-pc-solaris2.11/./libgm2/libm2pim/.libs/libm2pim.so
>>> RTco_initSemaphore  
>>> /var/gcc/modula-2/11.4-gcc-modula-2/i386-pc-solaris2.11/./libgm2/libm2pim/.libs/libm2pim.so
>>> RTco_wait   
>>> /var/gcc/modula-2/11.4-gcc-modula-2/i386-pc-solaris2.11/./libgm2/libm2pim/.libs/libm2pim.so
>>> ld: fatal: symbol referencing errors
>>> collect2: error: ld returned 1 exit status
>>> compiler exited with status 1
>>> FAIL: gm2/exceptions/run/pass/libexcept.mod compilation,  -g
>>>
>>>   I haven't yet tried to fix those.
>>
>> which I'll try and reproduce,
>
> Excellent.  I've also seen this one on Linux/x86_64, so this isn't a
> Solaris-specific issue.

Hi Rainer,

I think these are now fixed

regards,
Gaius


PING: [PATCH] libsanitizer: don't enable for MIPS Linux without GNU libc [PR 106136]

2022-07-25 Thread Xi Ruoyao via Gcc-patches
Gentle ping :).

On Thu, 2022-06-30 at 12:22 +0800, Xi Ruoyao wrote:
> In libsanitizer code, the size of some GNU libc data structure
> (notably,
> struct stat) is hard coded.  These sizes may trigger a static assert
> buidling against another libc.
> 
> Just make non-GNU libc targets UNSUPPORTED now.  If someone really
> cares
> about those alternative libc implementations, please submit patch to
> LLVM project adding the support.
> 
> libsanitizer/ChangeLog
> 
> PR sanitizer/106136
> * configure.tgt: Change mips*-*-linux* to mips*-*-linux-gnu*
> because it fails to build with non-GNU libc.
> ---
>  libsanitizer/configure.tgt | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libsanitizer/configure.tgt b/libsanitizer/configure.tgt
> index fb89df4935c..54b74b60e2f 100644
> --- a/libsanitizer/configure.tgt
> +++ b/libsanitizer/configure.tgt
> @@ -54,7 +54,7 @@ case "${target}" in
> ;;
>    arm*-*-linux*)
> ;;
> -  mips*-*-linux*)
> +  mips*-*-linux-gnu*)
> ;;
>    aarch64*-*-linux*)
> if test x$ac_cv_sizeof_void_p = x8; then

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


Re: [PATCH] libsanitizer: Cherry-pick 2bfb0fcb51510f22723c8cdfefe from upstream

2022-07-25 Thread Xi Ruoyao via Gcc-patches
LGTM.  Requiring permission to push.

> +const unsigned struct_kernel_stat_sz =
> +    SANITIZER_ANDROID
> +    ? FIRST_32_SECOND_64(104, 128)
> +    : FIRST_32_SECOND_64((_MIPS_SIM == _ABIN32) ? 160 : 144, 216);

These values matches sizeof(struct stat) on gcc230, so should be
correct:

xry111@gcc230:~$ cat t.c
#include 
#include 

int main()
{
  printf("%d\n", sizeof(struct stat));
}
xry111@gcc230:~$ cc t.c -mabi=32 && ./a.out 
144
xry111@gcc230:~$ cc t.c -mabi=n32 && ./a.out 
160
xry111@gcc230:~$ cc t.c -mabi=64 && ./a.out 
216

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


[PATCH] docs: remove recently added trailing whitespaces

2022-07-25 Thread Martin Liška
Pushed as obvious.

Martin

gcc/ChangeLog:

* doc/extend.texi: Remove trailing whitespaces.
* doc/invoke.texi: Likewise.
---
 gcc/doc/extend.texi | 12 ++--
 gcc/doc/invoke.texi | 10 +-
 2 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 71897b84a1b..7fe7f8817cd 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -3007,15 +3007,15 @@ produced by @command{gold}.
 For other linkers that cannot generate resolution file,
 explicit @code{externally_visible} attributes are still necessary.
 
-@item fd_arg 
+@item fd_arg
 @itemx fd_arg (@var{N})
 @cindex @code{fd_arg} function attribute
-The @code{fd_arg} attribute may be applied to a function that takes an open 
+The @code{fd_arg} attribute may be applied to a function that takes an open
 file descriptor at referenced argument @var{N}.
 
 It indicates that the passed filedescriptor must not have been closed.
-Therefore, when the analyzer is enabled with @option{-fanalyzer}, the 
-analyzer may emit a @option{-Wanalyzer-fd-use-after-close} diagnostic 
+Therefore, when the analyzer is enabled with @option{-fanalyzer}, the
+analyzer may emit a @option{-Wanalyzer-fd-use-after-close} diagnostic
 if it detects a code path in which a function with this attribute is
 called with a closed file descriptor.
 
@@ -3040,8 +3040,8 @@ attribute is called on a file descriptor opened with 
@code{O_WRONLY}.
 @itemx fd_arg_write (@var{N})
 @cindex @code{fd_arg_write} function attribute
 The @code{fd_arg_write} is identical to @code{fd_arg_read} except that the
-analyzer may emit a @option{-Wanalyzer-access-mode-mismatch} diagnostic if 
-it detects a code path in which a function with this attribute is called on a 
+analyzer may emit a @option{-Wanalyzer-access-mode-mismatch} diagnostic if
+it detects a code path in which a function with this attribute is called on a
 file descriptor opened with @code{O_RDONLY}.
 
 @item flatten
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index b1a9f50bfc7..9a3f2d14c5a 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -9847,7 +9847,7 @@ This warning requires @option{-fanalyzer}, which enables 
it; use
 @option{-Wno-analyzer-fd-access-mode-mismatch}
 to disable it.
 
-This diagnostic warns for paths through code in which a 
+This diagnostic warns for paths through code in which a
 @code{read} on a write-only file descriptor is attempted, or vice versa.
 
 This diagnostic also warns for code paths in a which a function with attribute
@@ -9863,7 +9863,7 @@ This warning requires @option{-fanalyzer}, which enables 
it; use
 @option{-Wno-analyzer-fd-double-close}
 to disable it.
 
-This diagnostic warns for paths through code in which a 
+This diagnostic warns for paths through code in which a
 file descriptor can be closed more than once.
 
 @item -Wno-analyzer-fd-leak
@@ -9873,7 +9873,7 @@ This warning requires @option{-fanalyzer}, which enables 
it; use
 @option{-Wno-analyzer-fd-leak}
 to disable it.
 
-This diagnostic warns for paths through code in which an 
+This diagnostic warns for paths through code in which an
 open file descriptor is leaked.
 
 @item -Wno-analyzer-fd-use-after-close
@@ -9883,7 +9883,7 @@ This warning requires @option{-fanalyzer}, which enables 
it; use
 @option{-Wno-analyzer-fd-use-after-close}
 to disable it.
 
-This diagnostic warns for paths through code in which a 
+This diagnostic warns for paths through code in which a
 read or write is called on a closed file descriptor.
 
 This diagnostic also warns for paths through code in which
@@ -9898,7 +9898,7 @@ This warning requires @option{-fanalyzer}, which enables 
it; use
 @option{-Wno-analyzer-fd-use-without-check}
 to disable it.
 
-This diagnostic warns for paths through code in which a 
+This diagnostic warns for paths through code in which a
 file descriptor is used without being checked for validity.
 
 This diagnostic also warns for paths through code in which
-- 
2.37.1



[PATCH] libsanitizer: Cherry-pick 2bfb0fcb51510f22723c8cdfefe from upstream

2022-07-25 Thread Dimitrije Milosevic
2bfb0fcb51510f22723c8cdfefe [Sanitizer][MIPS] Fix stat struct size for the O32 
ABI.

Signed-off-by: Dimitrije Milosevic .

---
 .../sanitizer_common/sanitizer_platform_limits_posix.h | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h 
b/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h
index 89772a7e5c0..75c6cc7f285 100644
--- a/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h
+++ b/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h
@@ -81,9 +81,10 @@ const unsigned struct_kernel_stat64_sz = 104;
 const unsigned struct_kernel_stat_sz = 144;
 const unsigned struct_kernel_stat64_sz = 104;
 #elif defined(__mips__)
-const unsigned struct_kernel_stat_sz = SANITIZER_ANDROID
-   ? FIRST_32_SECOND_64(104, 128)
-   : FIRST_32_SECOND_64(144, 216);
+const unsigned struct_kernel_stat_sz =
+SANITIZER_ANDROID
+? FIRST_32_SECOND_64(104, 128)
+: FIRST_32_SECOND_64((_MIPS_SIM == _ABIN32) ? 160 : 144, 216);
 const unsigned struct_kernel_stat64_sz = 104;
 #elif defined(__s390__) && !defined(__s390x__)
 const unsigned struct_kernel_stat_sz = 64;
-- 
2.25.1

[COMMITTED] frange class to represent floating point ranges

2022-07-25 Thread Aldy Hernandez via Gcc-patches
This implements a basic frange class to represent floating point
ranges.  Although it is meant to be a base for further development, it
is enough to handle relations and propagate NAN and other properties.

For ranger clients to become floating point aware, we still need the
range-op entries, which I will submit later this week.  Since those
entries require specialized FP knowledge, I will ask for a review from
the FP experts before committing.

Once range-op entries come live, all ranger clients that have been
converted to the type agnostic vrange API will become FP aware: evrp,
DOM, the threaders, loop-ch, etc.  (Still missing is loop unswitching,
as a lot of the int_range* temporaries should be Value_Range.  I don't
have enough cycles to convert loop unswitching, but could gladly give
guidance.  It should be straightforward for those familiar with the
code ;-)).

Samples things we handle:

* We can set the FP properties (!NAN, !INF, etc) at assignment from
  constants (and propagate them throughout the CFG):

  float z = 0.0;
  if (__builtin_isnan (z))
link_error ();

* The relation oracle works in tandem with the FP ranges:

  if (x > y)
   ;
  else if (!__builtin_isnan (x) && !__builtin_isnan (y))
   {
 // If x and y are not NAN, the x <= y relationship holds, and the
 // following conditional can be folded away.
 if (x <= y)
   bar ();
   }

* We know the true side of all ordered conditionals (except !=)
  implies !NAN:

  if (x > y)
{
  if (__builtin_isnan (x) || __builtin_isnan (y))
link_error ();
}

Range-ops also works correctly with -ffinite-math-only, and avoids
checking for NANs, etc.

I believe this is enough to get a fully fleshed out floating point
support for evrp and friends, but doing so is beyond my limited FP
knowledge.  For example, frange could be enhanced to track constant
endpoints, and we could track other FP properties aside from NAN.
Further discussion is gladly welcome.

Tested on x86-64 Linux.

gcc/ChangeLog:

* value-range-pretty-print.cc (vrange_printer::visit): New.
(vrange_printer::print_frange_prop): New.
* value-range-pretty-print.h (class vrange_printer): Add visit and
print_frange_prop.
* value-range-storage.h (vrange_allocator::alloc_vrange): Handle frange.
(vrange_allocator::alloc_frange): New.
* value-range.cc (vrange::operator=): Handle frange.
(vrange::operator==): Same.
(frange::accept): New.
(frange::set): New.
(frange::normalize_kind): New.
(frange::union_): New.
(frange::intersect): New.
(frange::operator=): New.
(frange::operator==): New.
(frange::supports_type_p): New.
(frange::verify_range): New.
* value-range.h (enum value_range_discriminator): Handle frange.
(class fp_prop): New.
(FP_PROP_ACCESSOR): New.
(class frange_props): New.
(FRANGE_PROP_ACCESSOR): New.
(class frange): New.
(Value_Range::init): Handle frange.
(Value_Range::operator=): Same.
(Value_Range::supports_type_p): Same.
(frange_props::operator==): New.
(frange_props::union_): New.
(frange_props::intersect): New
(frange::frange): New.
(frange::type): New.
(frange::set_varying): New.
(frange::set_undefined): New.
---
 gcc/value-range-pretty-print.cc |  41 +++
 gcc/value-range-pretty-print.h  |   2 +
 gcc/value-range-storage.h   |  27 -
 gcc/value-range.cc  | 195 +++-
 gcc/value-range.h   | 194 ++-
 5 files changed, 452 insertions(+), 7 deletions(-)

diff --git a/gcc/value-range-pretty-print.cc b/gcc/value-range-pretty-print.cc
index b795e92d8fb..485612fe67c 100644
--- a/gcc/value-range-pretty-print.cc
+++ b/gcc/value-range-pretty-print.cc
@@ -109,3 +109,44 @@ vrange_printer::print_irange_bitmasks (const irange ) 
const
   print_hex (nz, buf);
   pp_string (pp, buf);
 }
+
+// Print an frange.
+
+void
+vrange_printer::visit (const frange ) const
+{
+  pp_string (pp, "[frange] ");
+  if (r.undefined_p ())
+{
+  pp_string (pp, "UNDEFINED");
+  return;
+}
+  dump_generic_node (pp, r.type (), 0, TDF_NONE, false);
+  pp_string (pp, " ");
+  if (r.varying_p ())
+{
+  pp_string (pp, "VARYING");
+  return;
+}
+  print_frange_prop ("NAN", r.get_nan ());
+  print_frange_prop ("INF", r.get_inf ());
+  print_frange_prop ("NINF", r.get_ninf ());
+}
+
+// Print the FP properties in an frange.
+
+void
+vrange_printer::print_frange_prop (const char *str, const fp_prop ) const
+{
+  if (prop.varying_p ())
+return;
+
+  if (prop.yes_p ())
+pp_string (pp, str);
+  else if (prop.no_p ())
+{
+  pp_character (pp, '!');
+  pp_string (pp, str);
+}
+  pp_character (pp, ' ');
+}
diff --git a/gcc/value-range-pretty-print.h 

[PATCH] analyzer: convert tests with dos2unix

2022-07-25 Thread Martin Liška
Ready for master?
Thanks,
Martin

gcc/testsuite/ChangeLog:

* gcc.dg/analyzer/fd-2.c: Convert Windows endlines to Unix
style.
* gcc.dg/analyzer/fd-3.c: Likewise.
* gcc.dg/analyzer/fd-4.c: Likewise.
* gcc.dg/analyzer/fd-5.c: Likewise.
* c-c++-common/attr-fd.c: Likewise.
---
 gcc/testsuite/c-c++-common/attr-fd.c |  36 +++---
 gcc/testsuite/gcc.dg/analyzer/fd-2.c |  96 +++
 gcc/testsuite/gcc.dg/analyzer/fd-3.c | 168 +--
 gcc/testsuite/gcc.dg/analyzer/fd-4.c | 142 +++---
 gcc/testsuite/gcc.dg/analyzer/fd-5.c | 104 -
 5 files changed, 273 insertions(+), 273 deletions(-)

diff --git a/gcc/testsuite/c-c++-common/attr-fd.c 
b/gcc/testsuite/c-c++-common/attr-fd.c
index e4bb4ed0374..9f12093c04f 100644
--- a/gcc/testsuite/c-c++-common/attr-fd.c
+++ b/gcc/testsuite/c-c++-common/attr-fd.c
@@ -1,18 +1,18 @@
-
-int not_a_fn __attribute__ ((fd_arg(1))); /* { dg-warning "'fd_arg' attribute 
only applies to function types" } */
-
-void f (char *p) __attribute__ ((fd_arg(1))); /* { dg-warning "'fd_arg' 
attribute argument value '1' refers to parameter type 'char ?\\\*'" } */
-
-
-int not_a_fn_b __attribute__ ((fd_arg_read(1))); /* { dg-warning 
"'fd_arg_read' attribute only applies to function types" } */
-
-void g (char *p) __attribute__ ((fd_arg_read(1))); /* { dg-warning 
"'fd_arg_read' attribute argument value '1' refers to parameter type 'char 
?\\\*'" } */
-
-
-int not_a_fn_c __attribute__ ((fd_arg_write(1))); /* { dg-warning 
"'fd_arg_write' attribute only applies to function types" } */
-
-void f (char *p) __attribute__ ((fd_arg_write(1))); /* { dg-warning 
"'fd_arg_write' attribute argument value '1' refers to parameter type 'char 
?\\\*'" } */
-
-
-void fn_a (int fd) __attribute__ ((fd_arg(0))); /* { dg-warning "'fd_arg' 
attribute argument value '0' does not refer to a function parameter" } */
-void fd_a_1 (int fd) __attribute__ ((fd_arg("notint"))); /* { dg-warning 
"'fd_arg' attribute argument has type ('char\\\[7\\\]'|'const char\\\*')" } */
+
+int not_a_fn __attribute__ ((fd_arg(1))); /* { dg-warning "'fd_arg' attribute 
only applies to function types" } */
+
+void f (char *p) __attribute__ ((fd_arg(1))); /* { dg-warning "'fd_arg' 
attribute argument value '1' refers to parameter type 'char ?\\\*'" } */
+
+
+int not_a_fn_b __attribute__ ((fd_arg_read(1))); /* { dg-warning 
"'fd_arg_read' attribute only applies to function types" } */
+
+void g (char *p) __attribute__ ((fd_arg_read(1))); /* { dg-warning 
"'fd_arg_read' attribute argument value '1' refers to parameter type 'char 
?\\\*'" } */
+
+
+int not_a_fn_c __attribute__ ((fd_arg_write(1))); /* { dg-warning 
"'fd_arg_write' attribute only applies to function types" } */
+
+void f (char *p) __attribute__ ((fd_arg_write(1))); /* { dg-warning 
"'fd_arg_write' attribute argument value '1' refers to parameter type 'char 
?\\\*'" } */
+
+
+void fn_a (int fd) __attribute__ ((fd_arg(0))); /* { dg-warning "'fd_arg' 
attribute argument value '0' does not refer to a function parameter" } */
+void fd_a_1 (int fd) __attribute__ ((fd_arg("notint"))); /* { dg-warning 
"'fd_arg' attribute argument has type ('char\\\[7\\\]'|'const char\\\*')" } */
diff --git a/gcc/testsuite/gcc.dg/analyzer/fd-2.c 
b/gcc/testsuite/gcc.dg/analyzer/fd-2.c
index 96ccf2f7ba8..d794b460a2e 100644
--- a/gcc/testsuite/gcc.dg/analyzer/fd-2.c
+++ b/gcc/testsuite/gcc.dg/analyzer/fd-2.c
@@ -1,49 +1,49 @@
-int open(const char *, int mode);
-void close(int fd);
-#define O_RDONLY 0
-#define O_WRONLY 1
-#define O_RDWR 2
-#define STDIN 0
-
-void 
-test_1 (const char *path)
-{
-int fd = open (path, O_RDWR); /* { dg-message "\\(1\\) opened here" } */
-close (fd); /* { dg-message "\\(2\\) first 'close' here" "event1" } */
-close (fd); /* { dg-warning "double 'close' of file descriptor 'fd' 
\\\[CWE-1341\\\]" "warning" } */
-/* { dg-message "\\(3\\) second 'close' here; first 'close' was at 
\\(2\\)" "event2" { target *-*-* } .-1 } */
-}
-
-void 
-test_2 (const char *path)
-{
-int fd = open (path, O_RDWR); /* { dg-message "\\(1\\) opened here" } */
-if (fd < 0) /* { dg-message "\\(2\\) assuming 'fd' is a valid file 
descriptor \\(>= 0\\)" "event1" } */
-/* { dg-message "\\(3\\) following 'false' branch \\(when 'fd >= 0'\\)..." 
"event2" { target *-*-* } .-1 } */
-return;
-close (fd); /* { dg-message "\\(4\\) ...to here" "event1" } */
-/* { dg-message "\\(5\\) first 'close' here" "event2" { target *-*-* } .-1 
} */
-close (fd); /* { dg-warning "double 'close' of file descriptor 'fd' 
\\\[CWE-1341\\\]" "warning" } */
-/* {dg-message "\\(6\\) second 'close' here; first was at \\(5\\)" "" { 
target *-*-* } .-1 } */
-}
-
-void
-test_3 ()
-{
-/* FD 0 is stdin at the entry to "main" and thus read-only, but we have no
-guarantees here that it hasn't been closed and then reopened for
-writing, so we can't issue a warning */
-
-int fd = 

[PATCH] analyzer: fix coding style in sm-fd.cc

2022-07-25 Thread Martin Liška
Hi.

First, thanks Mir for your contribution. The following patch addresses
coding style issues I let you know in:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106003#c3

Most notably, I converted Windows endlines to Unix style, replace 8 spaces with 
tabs
and removed trailing whitespaces.

Please consider using our script that verifies that:
git show f8e6e2c046e1015697356ee7079fb39e0cb6add5 > diff && 
./contrib/check_GNU_style.py diff

Ready to be installed?
Thanks,
Martin


gcc/analyzer/ChangeLog:

* sm-fd.cc: Run dos2unix and fix coding style issues.
---
 gcc/analyzer/sm-fd.cc | 2114 -
 1 file changed, 1057 insertions(+), 1057 deletions(-)

diff --git a/gcc/analyzer/sm-fd.cc b/gcc/analyzer/sm-fd.cc
index c3dac48509e..56b0063ba42 100644
--- a/gcc/analyzer/sm-fd.cc
+++ b/gcc/analyzer/sm-fd.cc
@@ -1,1057 +1,1057 @@
-/* A state machine for detecting misuses of POSIX file descriptor APIs.
-   Copyright (C) 2019-2022 Free Software Foundation, Inc.
-   Contributed by Immad Mir .
-
-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.
-
-You should have received a copy of the GNU General Public License
-along with GCC; see the file COPYING3.  If not see
-.  */
-
-#include "config.h"
-#include "system.h"
-#include "coretypes.h"
-#include "tree.h"
-#include "function.h"
-#include "basic-block.h"
-#include "gimple.h"
-#include "options.h"
-#include "diagnostic-path.h"
-#include "diagnostic-metadata.h"
-#include "function.h"
-#include "json.h"
-#include "analyzer/analyzer.h"
-#include "diagnostic-event-id.h"
-#include "analyzer/analyzer-logging.h"
-#include "analyzer/sm.h"
-#include "analyzer/pending-diagnostic.h"
-#include "analyzer/function-set.h"
-#include "analyzer/analyzer-selftests.h"
-#include "tristate.h"
-#include "selftest.h"
-#include "stringpool.h"
-#include "attribs.h"
-#include "analyzer/call-string.h"
-#include "analyzer/program-point.h"
-#include "analyzer/store.h"
-#include "analyzer/region-model.h"
-#include "bitmap.h"
-
-#if ENABLE_ANALYZER
-
-namespace ana {
-
-namespace {
-
-/* An enum for distinguishing between three different access modes. */
-
-enum access_mode
-{
-  READ_WRITE,
-  READ_ONLY,
-  WRITE_ONLY
-};
-
-enum access_directions
-{
-  DIRS_READ_WRITE,
-  DIRS_READ,
-  DIRS_WRITE
-};
-
-class fd_state_machine : public state_machine
-{
-public:
-  fd_state_machine (logger *logger);
-
-  bool
-  inherited_state_p () const final override
-  {
-return false;
-  }
-
-  state_machine::state_t
-  get_default_state (const svalue *sval) const final override
-  {
-if (tree cst = sval->maybe_get_constant ())
-  {
-if (TREE_CODE (cst) == INTEGER_CST)
-  {
-int val = TREE_INT_CST_LOW (cst);
-if (val >= 0)
-  return m_constant_fd;
-else
-  return m_invalid;
-  }
-  }
-return m_start;
-  }
-
-  bool on_stmt (sm_context *sm_ctxt, const supernode *node,
-const gimple *stmt) const final override;
-
-  void on_condition (sm_context *sm_ctxt, const supernode *node,
- const gimple *stmt, const svalue *lhs, const tree_code op,
- const svalue *rhs) const final override;
-
-  bool can_purge_p (state_t s) const final override;
-  pending_diagnostic *on_leak (tree var) const final override;
-
-  bool is_unchecked_fd_p (state_t s) const;
-  bool is_valid_fd_p (state_t s) const;
-  bool is_closed_fd_p (state_t s) const;
-  bool is_constant_fd_p (state_t s) const;
-  bool is_readonly_fd_p (state_t s) const;
-  bool is_writeonly_fd_p (state_t s) const;
-  enum access_mode get_access_mode_from_flag (int flag) const;
-
-  /* State for a constant file descriptor (>= 0) */
-  state_t m_constant_fd;
-
-  /* States representing a file descriptor that hasn't yet been
-checked for validity after opening, for three different
-access modes.  */
-  state_t m_unchecked_read_write;
-
-  state_t m_unchecked_read_only;
-
-  state_t m_unchecked_write_only;
-
-  /* States for representing a file descriptor that is known to be valid (>=
-0), for three different access modes.*/
-  state_t m_valid_read_write;
-
-  state_t m_valid_read_only;
-
-  state_t m_valid_write_only;
-
-  /* State for a file descriptor that is known to be invalid (< 0). */
-  state_t m_invalid;
-
-  /* State for a file descriptor that has been closed.*/
-  state_t m_closed;
-
-  /* State for a file descriptor that we do not want to track anymore . */
-  state_t m_stop;
-
-private:
-  void on_open 

[PATCH v2] rs6000/test: Fix empty TU in some cases of effective targets [PR106345]

2022-07-25 Thread Kewen.Lin via Gcc-patches
Hi,

As the failure of test case gcc.target/powerpc/pr92398.p9-.c in
PR106345 shows, some test sources for some powerpc effective
targets use empty translation unit wrongly.  The test sources
could go with options like "-ansi -pedantic-errors", then those
effective target checkings will fail unexpectedly with the
error messages like:

  error: ISO C forbids an empty translation unit [-Wpedantic]

This patch is to fix empty TUs with one dummy function definition
accordingly.

Excepting for the failures on gcc.target/powerpc/pr92398.p9-.c
fixed, I can see it helps to bring back some testing coverage like:

NA->PASS: gcc.target/powerpc/pr92398.p9+.c
NA->PASS: gcc.target/powerpc/pr93453-1.c

Tested as before.

v1: https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598602.html
v2: Use dummy function instead of dummy int as Segher suggested.

Segher, does this v2 look good to you?

BR,
Kewen
-
PR testsuite/106345

gcc/testsuite/ChangeLog:

* lib/target-supports.exp (check_effective_target_powerpc_sqrt): Add
a function definition to avoid pedwarn about empty translation unit.
(check_effective_target_has_arch_pwr5): Likewise.
(check_effective_target_has_arch_pwr6): Likewise.
(check_effective_target_has_arch_pwr7): Likewise.
(check_effective_target_has_arch_pwr8): Likewise.
(check_effective_target_has_arch_pwr9): Likewise.
(check_effective_target_has_arch_pwr10): Likewise.
(check_effective_target_has_arch_ppc64): Likewise.
(check_effective_target_ppc_float128): Likewise.
(check_effective_target_ppc_float128_insns): Likewise.
(check_effective_target_powerpc_vsx): Likewise.
---
 gcc/testsuite/lib/target-supports.exp | 33 +++
 1 file changed, 33 insertions(+)

diff --git a/gcc/testsuite/lib/target-supports.exp 
b/gcc/testsuite/lib/target-supports.exp
index 4ed7b25b9a4..06484330178 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -6259,9 +6259,12 @@ proc check_effective_target_powerpc_sqrt { } {
 }

 return [check_no_compiler_messages powerpc_sqrt object {
+   void test (void)
+   {
#ifndef _ARCH_PPCSQ
#error _ARCH_PPCSQ is not defined
#endif
+   }
 } {}]
 }

@@ -6369,71 +6372,92 @@ proc check_effective_target_powerpc_p9modulo_ok { } {
 # as provided by the test.
 proc check_effective_target_has_arch_pwr5 { } {
return [check_no_compiler_messages_nocache arch_pwr5 assembly {
+   void test (void)
+   {
#ifndef _ARCH_PWR5
#error does not have power5 support.
#else
/* "has power5 support" */
#endif
+   }
} [current_compiler_flags]]
 }

 proc check_effective_target_has_arch_pwr6 { } {
return [check_no_compiler_messages_nocache arch_pwr6 assembly {
+   void test (void)
+   {
#ifndef _ARCH_PWR6
#error does not have power6 support.
#else
/* "has power6 support" */
#endif
+   }
} [current_compiler_flags]]
 }

 proc check_effective_target_has_arch_pwr7 { } {
return [check_no_compiler_messages_nocache arch_pwr7 assembly {
+   void test (void)
+   {
#ifndef _ARCH_PWR7
#error does not have power7 support.
#else
/* "has power7 support" */
#endif
+   }
} [current_compiler_flags]]
 }

 proc check_effective_target_has_arch_pwr8 { } {
return [check_no_compiler_messages_nocache arch_pwr8 assembly {
+   void test (void)
+   {
#ifndef _ARCH_PWR8
#error does not have power8 support.
#else
/* "has power8 support" */
#endif
+   }
} [current_compiler_flags]]
 }

 proc check_effective_target_has_arch_pwr9 { } {
return [check_no_compiler_messages_nocache arch_pwr9 assembly {
+   void test (void)
+   {
#ifndef _ARCH_PWR9
#error does not have power9 support.
#else
/* "has power9 support" */
#endif
+   }
} [current_compiler_flags]]
 }

 proc check_effective_target_has_arch_pwr10 { } {
return [check_no_compiler_messages_nocache arch_pwr10 assembly {
+   void test (void)
+   {
#ifndef _ARCH_PWR10
#error does not have power10 support.
#else
/* "has power10 support" */
#endif
+   }
} [current_compiler_flags]]
 }

 proc check_effective_target_has_arch_ppc64 { } {
return [check_no_compiler_messages_nocache arch_ppc64 assembly {
+   

Re: [PATCH] rs6000/test: Update some cases with -mdejagnu-tune

2022-07-25 Thread Kewen.Lin via Gcc-patches
Hi Peter and Segher,

on 2022/7/23 03:28, Peter Bergner wrote:
> On 7/22/22 1:53 PM, Peter Bergner wrote:
>> So I think the way the code above *should* work is:
>>   1) Any -mdejagnu-cpu= usage should filter out all -mcpu= and -mtune= 
>> options.
>>   2) Any -mdejagnu-tune= usage should filter all -mtune= options.
>>  It should not filter out any -mcpu= options.
> 
> Like this:
> 
> diff --git a/gcc/config/rs6000/rs6000.h b/gcc/config/rs6000/rs6000.h
> index 3b8941a8658..26874943795 100644
> --- a/gcc/config/rs6000/rs6000.h
> +++ b/gcc/config/rs6000/rs6000.h
> @@ -86,7 +86,7 @@
> RUNTESTFLAGS override those set in the testcases; with this option,
> the testcase will always win.  Ditto for -mdejagnu-tune=.  */
>  #define DRIVER_SELF_SPECS \
> -  "%{mdejagnu-cpu=*: % +  "%{mdejagnu-cpu=*: %"%{mdejagnu-tune=*: %"%{mdejagnu-*: % SUBTARGET_DRIVER_SELF_SPECS
> 
> 
> Kewen, can you see if the above patch fixes the issues you're seeing?
> 

Thanks for the insightful comments and patch!

I confirmed that this proposed patch can fix those found test issues.

I adjusted the relevant comments and confirmed that it can be bootstrapped and
regtested on powerpc64-linux-gnu P7 and P8 and powerpc64le-linux-gnu P9 and P10.

Segher pre-approved it, I just committed it as r13-1818 as attached.

Will backport it to release branches in a week or so.  Thanks again.

BR,
KewenFrom 75d20d6c84c12bedd65a904e462f02f0b9eb3f77 Mon Sep 17 00:00:00 2001
From: Peter Bergner 
Date: Mon, 25 Jul 2022 00:51:44 -0500
Subject: [PATCH] rs6000: Adjust -mdejagnu-cpu to filter out -mtune [PR106345]

As PR106345 shows, when configuring compiler with an explicit
option --with-tune=, it would cause some test cases to
fail if their test points are sensitive to tune setting, such
as: group_ending_nop, loop align etc.  It doesn't help that
even to specify one explicit -mcpu=.

This patch is to adjust the behavior of -mdejagnu-cpu by
filtering out all -mcpu= and -mtune= options, then test cases
would use  as tune as the one specified by -mdejagnu-cpu.

2022-07-25  Peter Bergner  
Kewen Lin  

PR testsuite/106345

gcc/ChangeLog:

* config/rs6000/rs6000.h (DRIVER_SELF_SPECS): Adjust -mdejagnu-cpu
to filter out all -mtune options.
---
 gcc/config/rs6000/rs6000.h | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/gcc/config/rs6000/rs6000.h b/gcc/config/rs6000/rs6000.h
index 7d04556304a..ad9bf0f7358 100644
--- a/gcc/config/rs6000/rs6000.h
+++ b/gcc/config/rs6000/rs6000.h
@@ -81,12 +81,15 @@
 # define SUBTARGET_DRIVER_SELF_SPECS ""
 #endif
 
-/* Only for use in the testsuite: -mdejagnu-cpu= simply overrides -mcpu=.
+/* Only for use in the testsuite: -mdejagnu-cpu= filters out all
+   -mcpu= as well as -mtune= options then simply adds -mcpu=,
+   while -mdejagnu-tune= filters out all -mtune= options then
+   simply adds -mtune=.
With older versions of Dejagnu the command line arguments you set in
-   RUNTESTFLAGS override those set in the testcases; with this option,
-   the testcase will always win.  Ditto for -mdejagnu-tune=.  */
+   RUNTESTFLAGS override those set in the testcases; with these options,
+   the testcase will always win.  */
 #define DRIVER_SELF_SPECS \
-  "%{mdejagnu-cpu=*: %

Re: [PATCH 1/2] Allow subtarget customization of CC1_SPEC

2022-07-25 Thread Iain Sandoe via Gcc-patches
Hi Sebastian,

> On 25 Jul 2022, at 06:59, Sebastian Huber 
>  wrote:

> On 22/07/2022 16:02, Jose E. Marchesi wrote:
>> I find "subtarget" confusing in this context.
>> If it is about rtems.h, linux.h or sol2.h, wouldn't this be better
>> called OS_CC1_SPEC or similar?  These files specify configurations that
>> apply to a set of targets, not to a subset of a target...
> 
> Iain Sandoe told me that for the GCC implementation the OSs are sub-targets 
> of the architecture:
> 
> https://gcc.gnu.org/pipermail/gcc/2022-July/239158.html

There is, however, a precedent for the SUBTARGET_ use, however, I agree with 
Jose that it is somewhat confusing - since (as mentioned before) to the OS the 
arches are the sub-targets, so maybe OS_xxx would be more clear.

Perhaps Joseph (CC-d) would weigh in here.

Iain



Re: [PATCH 1/2] Allow subtarget customization of CC1_SPEC

2022-07-25 Thread Sebastian Huber

Hallo Jose,

On 22/07/2022 16:02, Jose E. Marchesi wrote:

I find "subtarget" confusing in this context.

If it is about rtems.h, linux.h or sol2.h, wouldn't this be better
called OS_CC1_SPEC or similar?  These files specify configurations that
apply to a set of targets, not to a subset of a target...


Iain Sandoe told me that for the GCC implementation the OSs are 
sub-targets of the architecture:


https://gcc.gnu.org/pipermail/gcc/2022-July/239158.html

--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/