[pushed] c++: don't predeclare std::type_info [PR48396]

[Jason Merrill via Gcc-patches]

We've always predeclared std::type_info, which has been wrong for a while,
but now with modules it becomes more of a practical problem, if we want to
declare it in the purview of a module.  So don't predeclare it.  For
building up the type_info information to write out with the vtable, we can
use void* instead of type_info*, since they already aren't the real types.

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

PR c++/48396

gcc/cp/ChangeLog:

* cp-tree.h (enum cp_tree_index): Remove CPTI_TYPE_INFO_PTR_TYPE.
(type_info_ptr_type): Remove.
* rtti.c (init_rtti_processing): Don't predeclare std::type_info.
(typeid_ok_p): Check for null const_type_info_type_node.
(type_info_ptr_type, get_void_tinfo_ptr): New fns.
(get_tinfo_decl_dynamic, get_tinfo_ptr): Use them.
(ptr_initializer, ptm_initializer, get_pseudo_ti_init): Use them.
(get_tinfo_desc): Use const_ptr_type_node.

gcc/testsuite/ChangeLog:

* g++.dg/rtti/undeclared1.C: New test.
---
 gcc/cp/cp-tree.h|  4 +-
 gcc/cp/rtti.c   | 95 ++---
 gcc/testsuite/g++.dg/rtti/undeclared1.C |  5 ++
 3 files changed, 58 insertions(+), 46 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/rtti/undeclared1.C

diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index a82747ca627..060d1a0a3db 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -204,12 +204,11 @@ enum cp_tree_index
 /* These are created at init time, but the library/headers provide
definitions.  */
 CPTI_ALIGN_TYPE,
-CPTI_CONST_TYPE_INFO_TYPE,
-CPTI_TYPE_INFO_PTR_TYPE,
 CPTI_TERMINATE_FN,
 CPTI_CALL_UNEXPECTED_FN,
 
 /* These are lazily inited.  */
+CPTI_CONST_TYPE_INFO_TYPE,
 CPTI_GET_EXCEPTION_PTR_FN,
 CPTI_BEGIN_CATCH_FN,
 CPTI_END_CATCH_FN,
@@ -251,7 +250,6 @@ extern GTY(()) tree cp_global_trees[CPTI_MAX];
 #define abi_node   cp_global_trees[CPTI_ABI]
 #define global_namespace   cp_global_trees[CPTI_GLOBAL]
 #define const_type_info_type_node  
cp_global_trees[CPTI_CONST_TYPE_INFO_TYPE]
-#define type_info_ptr_type cp_global_trees[CPTI_TYPE_INFO_PTR_TYPE]
 #define conv_op_marker cp_global_trees[CPTI_CONV_OP_MARKER]
 #define abort_fndecl   cp_global_trees[CPTI_ABORT_FNDECL]
 #define current_aggr   cp_global_trees[CPTI_AGGR_TAG]
diff --git a/gcc/cp/rtti.c b/gcc/cp/rtti.c
index fcb33088a21..9c5066bcacc 100644
--- a/gcc/cp/rtti.c
+++ b/gcc/cp/rtti.c
@@ -125,7 +125,6 @@ static tree tinfo_name (tree, bool);
 static tree build_dynamic_cast_1 (location_t, tree, tree, tsubst_flags_t);
 static tree throw_bad_cast (void);
 static tree throw_bad_typeid (void);
-static tree get_tinfo_ptr (tree);
 static bool typeid_ok_p (void);
 static int qualifier_flags (tree);
 static bool target_incomplete_p (tree);
@@ -142,22 +141,11 @@ static bool typeinfo_in_lib_p (tree);
 
 static int doing_runtime = 0;
 
-/* Declare language defined type_info type and a pointer to const
-   type_info.  This is incomplete here, and will be completed when
-   the user #includes .  There are language defined
-   restrictions on what can be done until that is included.  Create
-   the internal versions of the ABI types.  */
+/* Create the internal versions of the ABI types.  */
 
 void
 init_rtti_processing (void)
 {
-  push_nested_namespace (std_node);
-  tree type_info_type = xref_tag (class_type, get_identifier ("type_info"));
-  pop_nested_namespace (std_node);
-  const_type_info_type_node
-= cp_build_qualified_type (type_info_type, TYPE_QUAL_CONST);
-  type_info_ptr_type = build_pointer_type (const_type_info_type_node);
-
   vec_alloc (unemitted_tinfo_decls, 124);
 
   create_tinfo_types ();
@@ -238,6 +226,33 @@ throw_bad_typeid (void)
   return build_cxx_call (fn, 0, NULL, tf_warning_or_error);
 }
 
+/* const type_info*.  */
+
+inline tree
+type_info_ptr_type ()
+{
+  return build_pointer_type (const_type_info_type_node);
+}
+
+/* Return a pointer to a type_info object describing TYPE, suitably
+   cast to the language defined type (for typeid) or void (for building
+   up the descriptors).  */
+
+static tree
+get_tinfo_ptr (tree type, bool voidp = false)
+{
+  tree decl = get_tinfo_decl (type);
+  mark_used (decl);
+
+  tree ptype = voidp ? const_ptr_type_node : type_info_ptr_type ();
+  return build_nop (ptype, build_address (decl));
+}
+static inline tree
+get_void_tinfo_ptr (tree type)
+{
+  return get_tinfo_ptr (type, true);
+}
+
 /* Return an lvalue expression whose type is "const std::type_info"
and whose value indicates the type of the expression EXP.  If EXP
is a reference to a polymorphic class, return the dynamic type;
@@ -278,7 +293,7 @@ get_tinfo_decl_dynamic (tree exp, tsubst_flags_t complain)
   index = build_int_cst (NULL_TREE,
 -1 * TARGET_VTABLE_DATA_ENTRY_DISTANCE);
   t = 

[pushed] c++: correct object scope handling

[Jason Merrill via Gcc-patches]

The way cp_parser_lookup_name handles object scope (i.e. the scope on the
RHS of a . or -> expression) is a bit subtle: before the lookup it's in
parser->context->object type, and after the lookup it's in
parser->object_scope.  But a couple of places that elide lookups were
failing to do the same transform.

I'm not aware of this breaking anything currently.

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

gcc/cp/ChangeLog:

* parser.c (cp_parser_template_name): Move object type.
(cp_parser_pre_parsed_nested_name_specifier): Likewise.
---
 gcc/cp/parser.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index ab1dc81b997..7a0b6234350 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -18405,6 +18405,7 @@ cp_parser_template_name (cp_parser* parser,
{
  /* We're optimizing away the call to cp_parser_lookup_name, but
 we still need to do this.  */
+ parser->object_scope = parser->context->object_type;
  parser->context->object_type = NULL_TREE;
  return identifier;
}
@@ -33575,7 +33576,8 @@ cp_parser_pre_parsed_nested_name_specifier (cp_parser 
*parser)
   /* Set the scope from the stored value.  */
   parser->scope = saved_checks_value (check_value);
   parser->qualifying_scope = check_value->qualifying_scope;
-  parser->object_scope = NULL_TREE;
+  parser->object_scope = parser->context->object_type;
+  parser->context->object_type = NULL_TREE;
 }
 
 /* Consume tokens up through a non-nested END token.  Returns TRUE if we

base-commit: bd55fa102715c7442c050b193dadfdb5337e2377
prerequisite-patch-id: 6aead84b2823eea91fa3886a64c032aa4882cec3
-- 
2.27.0

[pushed] c++: tweak C++20 destructor template-id rule

[Jason Merrill via Gcc-patches]

While working on a larger change to destructor lookup I noticed that this
rule talks about declarators, but we weren't limiting the error to the case
where we're parsing a declarator.  I don't know if this actually broke
anything, since a CPP_TEMPLATE_ID would have to have been parsed once
before, but it's more correct this way.

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

gcc/cp/ChangeLog:

* parser.c (cp_parser_unqualified_id): Only complain about ~A in
a declarator.
---
 gcc/cp/parser.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index e44c5c6b57c..ab1dc81b997 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -6379,7 +6379,8 @@ cp_parser_unqualified_id (cp_parser* parser,
 
/* DR 2237 (C++20 only): A simple-template-id is no longer valid as the
   declarator-id of a constructor or destructor.  */
-   if (token->type == CPP_TEMPLATE_ID && cxx_dialect >= cxx20)
+   if (token->type == CPP_TEMPLATE_ID && declarator_p
+   && cxx_dialect >= cxx20)
  {
if (!cp_parser_simulate_error (parser))
  error_at (tilde_loc, "template-id not allowed for destructor");

base-commit: bd55fa102715c7442c050b193dadfdb5337e2377
-- 
2.27.0

[COMMITTED] gcc: xtensa: fix PR target/102336

[Max Filippov via Gcc-patches]

2021-09-14  Max Filippov  
gcc/
PR target/102336
* config/xtensa/t-xtensa (TM_H): Add include/xtensa-config.h.
---
 gcc/config/xtensa/t-xtensa | 1 +
 1 file changed, 1 insertion(+)

diff --git a/gcc/config/xtensa/t-xtensa b/gcc/config/xtensa/t-xtensa
index 973815c8c2d6..d06e49280545 100644
--- a/gcc/config/xtensa/t-xtensa
+++ b/gcc/config/xtensa/t-xtensa
@@ -16,4 +16,5 @@
 # along with GCC; see the file COPYING3.  If not see
 # .
 
+TM_H += $(srcdir)/../include/xtensa-config.h
 $(out_object_file): gt-xtensa.h
-- 
2.20.1

[PATCH] Output vextract{i, f}{32x4, 64x2} for (vec_select:(reg:Vmode) idx) when byte_offset of idx % 16 == 0.

[liuhongt via Gcc-patches]

Hi:
  As describled in PR, use vextract instead on valign when
byte_offset % 16 == 0.

  Bootstrapped and regtest on x86_64-linux-gnu{-m32,}.
  Pushed to trunk.

2020-09-13  Hongtao Liu  
Peter Cordes  
gcc/ChangeLog:

PR target/91103
* config/i386/sse.md (extract_suf): Add V8SF/V8SI/V4DF/V4DI.
(*vec_extract_valign): Output
vextract{i,f}{32x4,64x2} instruction when byte_offset % 16 ==
0.

gcc/testsuite/ChangeLog:

PR target/91103
* gcc.target/i386/pr91103-1.c: Add extract tests.
* gcc.target/i386/pr91103-2.c: Ditto.
---
 gcc/config/i386/sse.md| 21 +
 gcc/testsuite/gcc.target/i386/pr91103-1.c |  7 ++-
 gcc/testsuite/gcc.target/i386/pr91103-2.c |  4 
 3 files changed, 27 insertions(+), 5 deletions(-)

diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
index 516eb4544bc..5f96016c947 100644
--- a/gcc/config/i386/sse.md
+++ b/gcc/config/i386/sse.md
@@ -9031,7 +9031,8 @@ (define_mode_attr extract_type
   [(V16SF "avx512f") (V16SI "avx512f") (V8DF "avx512dq") (V8DI "avx512dq")])
 
 (define_mode_attr extract_suf
-  [(V16SF "32x4") (V16SI "32x4") (V8DF "64x2") (V8DI "64x2")])
+  [(V16SF "32x4") (V16SI "32x4") (V8DF "64x2") (V8DI "64x2")
+   (V8SF "32x4") (V8SI "32x4") (V4DF "64x2") (V4DI "64x2")])
 
 (define_mode_iterator AVX512_VEC
   [(V8DF "TARGET_AVX512DQ") (V8DI "TARGET_AVX512DQ") V16SF V16SI])
@@ -10603,9 +10604,21 @@ (define_insn 
"*vec_extract_valign"
  (match_operand:V48_256_512_AVX512VL 1 "register_operand" "v")
  (parallel [(match_operand 2 "")])))]
   "TARGET_AVX512F
-   && INTVAL(operands[2]) >= 16 / GET_MODE_SIZE (mode)"
-  "valign\t{%2, %1, %1, %0|%0, %1, %1, %2}";
-  [(set_attr "prefix" "evex")
+   && INTVAL(operands[2]) * GET_MODE_SIZE (mode) >= 16"
+{
+  int byte_offset = INTVAL (operands[2]) * GET_MODE_SIZE (mode);
+  if (byte_offset % 16 == 0)
+{
+  operands[2] = GEN_INT (byte_offset / 16);
+  if (byte_offset / 16 == 1)
+   return "vextract\t{%2, %t1, %x0|%x0, %t1, 
%2}";
+  else
+   return "vextract\t{%2, %1, %x0|%x0, %1, %2}";
+}
+  else
+return "valign\t{%2, %1, %1, %0|%0, %1, 
%1, %2}";
+}
+  [(set_attr "prefix" "maybe_evex")
(set_attr "mode" "")])
 
 (define_expand "avx512f_shufps512_mask"
diff --git a/gcc/testsuite/gcc.target/i386/pr91103-1.c 
b/gcc/testsuite/gcc.target/i386/pr91103-1.c
index 11caaa8bd1b..2d78a6da0f3 100644
--- a/gcc/testsuite/gcc.target/i386/pr91103-1.c
+++ b/gcc/testsuite/gcc.target/i386/pr91103-1.c
@@ -1,6 +1,7 @@
 /* { dg-do compile } */
 /* { dg-options "-mavx512vl -O2" } */
-/* { dg-final { scan-assembler-times "valign\[dq\]" 16 } } */
+/* { dg-final { scan-assembler-times "valign\[dq\]" 8 } } */
+/* { dg-final { scan-assembler-times "vextract" 12 } } */
 
 typedef float v8sf __attribute__((vector_size(32)));
 typedef float v16sf __attribute__((vector_size(64)));
@@ -23,9 +24,13 @@ EXTRACT (v8sf, float, 4);
 EXTRACT (v8sf, float, 7);
 EXTRACT (v8si, int, 4);
 EXTRACT (v8si, int, 7);
+EXTRACT (v16sf, float, 4);
 EXTRACT (v16sf, float, 8);
+EXTRACT (v16sf, float, 12);
 EXTRACT (v16sf, float, 15);
+EXTRACT (v16si, int, 4);
 EXTRACT (v16si, int, 8);
+EXTRACT (v16si, int, 12);
 EXTRACT (v16si, int, 15);
 EXTRACT (v4df, double, 2);
 EXTRACT (v4df, double, 3);
diff --git a/gcc/testsuite/gcc.target/i386/pr91103-2.c 
b/gcc/testsuite/gcc.target/i386/pr91103-2.c
index 010e4775723..a928d87f99a 100644
--- a/gcc/testsuite/gcc.target/i386/pr91103-2.c
+++ b/gcc/testsuite/gcc.target/i386/pr91103-2.c
@@ -61,9 +61,13 @@ RUNCHECK (f2, v8sf, float, 4);
 RUNCHECK (f2, v8sf, float, 7);
 RUNCHECK (di2, v8si, int, 4);
 RUNCHECK (di2, v8si, int, 7);
+RUNCHECK (f1, v16sf, float, 4);
 RUNCHECK (f1, v16sf, float, 8);
+RUNCHECK (f1, v16sf, float, 12);
 RUNCHECK (f1, v16sf, float, 15);
+RUNCHECK (di1, v16si, int, 4);
 RUNCHECK (di1, v16si, int, 8);
+RUNCHECK (di1, v16si, int, 12);
 RUNCHECK (di1, v16si, int, 15);
 RUNCHECK (d2, v4df, double, 2);
 RUNCHECK (d2, v4df, double, 3);
-- 
2.27.0

Re: [PATCH, Fortran] Revert to non-multilib-specific ISO_Fortran_binding.h

[Joseph Myers]

On Tue, 14 Sep 2021, Andreas Schwab wrote:

> On Sep 14 2021, Jakub Jelinek wrote:
> 
> > But, wonder why it didn't work with the float.h include then, because
> > https://github.com/lattera/freebsd/blob/master/sys/x86/include/float.h
> > seems to define LDBL_MANT_DIG to 64, LDBL_MIN_EXP to (-16381) and
> > LDBL_MAX_EXP to 16384 and that case was handled in ISO_Fortran_binding.h.
> 
> Doesn't gcc always use its own float.h?

Subject to USER_H (i.e., except on OpenBSD, where GCC tests for newer 
float.h features would probably fail unless OpenBSD's version exactly 
matches the GCC testsuite expectations for those features).

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

[PATCH 2/2] jit: Add support for complex types

[Petter Tomner via Gcc-patches]

>From a833639e6dfe9ff44b1084b5a5cbbf477d023cf5 Mon Sep 17 00:00:00 2001
From: Petter Tomner 
Date: Tue, 14 Sep 2021 23:52:06 +0200
Subject: [PATCH 2/2] jit: Testcases and documentation for complex types

Will squash with path 1

Signed-off-by:
2021-09-15  Petter Tomner   

gcc/jit/docs/topics/
* gcc/jit/docs/topics/contexts.rst Updated docs
* gcc/jit/docs/topics/expressions.rst
* gcc/jit/docs/topics/types.rst
* test-complex-builtins.c New
* test-complex-literals.c New
* test-complex-misc.c New
* test-complex-operators.c New
* test-complex-types.c New
---
 gcc/jit/docs/topics/contexts.rst  |  20 +
 gcc/jit/docs/topics/expressions.rst   |  89 ++-
 gcc/jit/docs/topics/types.rst |  12 +-
 gcc/testsuite/jit.dg/all-non-failing-tests.h  |  30 +
 gcc/testsuite/jit.dg/test-complex-builtins.c  | 217 ++
 gcc/testsuite/jit.dg/test-complex-literals.c  | 145 
 gcc/testsuite/jit.dg/test-complex-misc.c  | 206 ++
 gcc/testsuite/jit.dg/test-complex-operators.c | 353 +
 gcc/testsuite/jit.dg/test-complex-types.c | 677 ++
 9 files changed, 1720 insertions(+), 29 deletions(-)
 create mode 100644 gcc/testsuite/jit.dg/test-complex-builtins.c
 create mode 100644 gcc/testsuite/jit.dg/test-complex-literals.c
 create mode 100644 gcc/testsuite/jit.dg/test-complex-misc.c
 create mode 100644 gcc/testsuite/jit.dg/test-complex-operators.c
 create mode 100644 gcc/testsuite/jit.dg/test-complex-types.c

diff --git a/gcc/jit/docs/topics/contexts.rst b/gcc/jit/docs/topics/contexts.rst
index 00fb17e155d..42fdef7c654 100644
--- a/gcc/jit/docs/topics/contexts.rst
+++ b/gcc/jit/docs/topics/contexts.rst
@@ -489,6 +489,26 @@ Boolean options
 
   #ifdef LIBGCCJIT_HAVE_gcc_jit_context_set_bool_use_external_driver
 
+.. function:: void\
+ gcc_jit_context_set_bool_enable_complex_types (gcc_jit_context 
*ctxt, \
+  int bool_value);
+
+   This option can enable complex type support in libgccjit. By default,
+   no complex types can be used.
+
+   If you use complex types, it is recommended to use builtin functions
+   `creal`, `cimag` and `conj` etc. with the correct type suffix, since
+   those are inlined into the code, rather then imported functions from
+   the math lib which are not. See :ref:`gcc_jit_context_get_builtin_function`.
+
+   This entrypoint was added in :ref:`LIBGCCJIT_ABI_16`; you can test for
+   its presence using
+
+   .. code-block:: c
+
+  #ifdef LIBGCCJIT_HAVE_COMPLEX
+
+  
 Integer options
 ***
 
diff --git a/gcc/jit/docs/topics/expressions.rst 
b/gcc/jit/docs/topics/expressions.rst
index 396259ef07e..fc0345c3e1d 100644
--- a/gcc/jit/docs/topics/expressions.rst
+++ b/gcc/jit/docs/topics/expressions.rst
@@ -98,6 +98,15 @@ Simple expressions
Given a numeric type (integer or floating point), build an rvalue for
the given constant :c:type:`double` value.
 
+.. function:: gcc_jit_rvalue *\
+ gcc_jit_context_new_rvalue_from_complex_double (gcc_jit_context 
*ctxt, \
+  gcc_jit_type 
*numeric_type, \
+  _Complex double 
value)
+
+   Given a floating point type, build an rvalue for
+   the given constant :c:type:`_Complex double`. When the result type is
+   non-complex, the imaginary part is discarded.
+
 .. function:: gcc_jit_rvalue *\
   gcc_jit_context_new_rvalue_from_ptr (gcc_jit_context *ctxt, \
gcc_jit_type *pointer_type, 
\
@@ -168,14 +177,14 @@ 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` `abs (EXPR)`
-==  
+==    
==
+Unary Operation C equivalent  Supported types
+==    
==
+:c:macro:`GCC_JIT_UNARY_OP_MINUS`   `-(EXPR)` integer, real, 
complex
+:c:macro:`GCC_JIT_UNARY_OP_BITWISE_NEGATE`  `~(EXPR)` integer
+:c:macro:`GCC_JIT_UNARY_OP_LOGICAL_NEGATE`  `!(EXPR)` integer
+:c:macro:`GCC_JIT_UNARY_OP_ABS` `abs (EXPR)`  integer, real
+==    
==
 
 .. c:macro:: GCC_JIT_UNARY_OP_MINUS
 
@@ -235,22 +244,23 @@ Binary Operations
 
 The available binary operations 

[PATCH 1/2] jit: Add support for complex types

[Petter Tomner via Gcc-patches]

>From ff47bbec5a833b4470cae7cb636a5fbf31c6432e Mon Sep 17 00:00:00 2001
From: Petter Tomner 
Date: Tue, 14 Sep 2021 23:51:41 +0200
Subject: [PATCH 1/2] jit: Support for complex types

The patch adds support of complex floating point types to libgccjit.
A new binary operator 'COMPLEX' is added to create complex values
from real values. Aswell as a function to create a complex double
literal.

To notify users if a binary linking to libgccjit depends on complex
types, complex type support most be enabled with a new option function.

Signed-off-by:
2021-09-15  Petter Tomner   

gcc/jit/
* jit-common.h (INNER_BOOL_OPTION_ENABLE_COMPLEX_TYPES): new
* jit-playback.c Create imaginary literals, conversions
* jit-recording.c Reproducer, debug strings, forwarding
* jit-recording.h
  (float_size_qual): Poll size qualifier of float types
  (is_complex): Poll if type is complex
* libgccjit++.h New entrypoints, see below
* libgccjit.c Implementation of new entry points
  (gcc_jit_context_get_type): Extend range check, validation
  (valid_binary_op_p): Extend range check
  (gcc_jit_context_new_binary_op): Validation
  (gcc_jit_context_new_unary_op): Validation
  (gcc_jit_context_new_comparison): Validation
* libgccjit.h
  (gcc_jit_context_new_rvalue_from_complex_double): New
  (GCC_JIT_BINARY_OP_COMPLEX): New
  (LIBGCCJIT_HAVE_COMPLEX): New
  (gcc_jit_context_set_bool_enable_complex_types): New
* libgccjit.map Added new entrypoints
  (LIBGCCJIT_ABI_16): New
---
 gcc/jit/jit-common.h|   1 +
 gcc/jit/jit-playback.c  | 165 ++--
 gcc/jit/jit-recording.c | 116 +++-
 gcc/jit/jit-recording.h |  28 +++
 gcc/jit/libgccjit++.h   |  23 +-
 gcc/jit/libgccjit.c |  97 ++-
 gcc/jit/libgccjit.h |  45 ++-
 gcc/jit/libgccjit.map   |   6 ++
 8 files changed, 468 insertions(+), 13 deletions(-)

diff --git a/gcc/jit/jit-common.h b/gcc/jit/jit-common.h
index f88e6755b00..bc0453fba05 100644
--- a/gcc/jit/jit-common.h
+++ b/gcc/jit/jit-common.h
@@ -198,6 +198,7 @@ enum inner_bool_option
 {
   INNER_BOOL_OPTION_ALLOW_UNREACHABLE_BLOCKS,
   INNER_BOOL_OPTION_USE_EXTERNAL_DRIVER,
+  INNER_BOOL_OPTION_ENABLE_COMPLEX_TYPES,
 
   NUM_INNER_BOOL_OPTIONS
 };
diff --git a/gcc/jit/jit-playback.c b/gcc/jit/jit-playback.c
index 59399dee251..8e4971958c3 100644
--- a/gcc/jit/jit-playback.c
+++ b/gcc/jit/jit-playback.c
@@ -40,6 +40,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "gcc.h"
 #include "diagnostic.h"
 #include "stmt.h"
+#include "complex.h"
 
 #include 
 
@@ -78,6 +79,8 @@ convert (tree dst_type, tree expr)
 case INTEGER_TYPE:
 case ENUMERAL_TYPE:
   return fold (convert_to_integer (dst_type, expr));
+case REAL_TYPE:
+  return fold (convert_to_real (dst_type, expr));
 
 default:
   gcc_assert (gcc::jit::active_playback_ctxt);
@@ -679,6 +682,24 @@ new_global_initialized (location *loc,
 namespace playback
 {
 
+/* Return the corrensponding not complex float type of a
+   float type. I.e. complex float -> float */
+static tree
+complex_real_to_real (tree complex_type)
+{
+  if (TYPE_CANONICAL (complex_type) ==
+TYPE_CANONICAL (complex_float_type_node))
+return float_type_node;
+  else if (TYPE_CANONICAL (complex_type) ==
+   TYPE_CANONICAL (complex_double_type_node))
+return double_type_node;
+  else if (TYPE_CANONICAL (complex_type) ==
+   TYPE_CANONICAL (complex_long_double_type_node))
+return long_double_type_node;
+  else
+gcc_unreachable();
+}
+
 /* Specialization of making an rvalue from a const, for host .  */
 
 template <>
@@ -694,6 +715,25 @@ new_rvalue_from_const  (type *type,
   tree inner = build_int_cst (inner_type, value);
   return new rvalue (this, inner);
 }
+  else if (COMPLEX_FLOAT_TYPE_P (inner_type))
+{
+  tree tree_real;
+  tree tree_imag;
+  tree real_type;
+  REAL_VALUE_TYPE real_value;
+  REAL_VALUE_TYPE imag_value;
+
+  real_type = complex_real_to_real (inner_type);
+
+  real_from_integer (_value, VOIDmode, value, SIGNED);
+  real_from_integer (_value, VOIDmode, 0, SIGNED);
+
+  tree_real = build_real (real_type, real_value);
+  tree_imag = build_real (real_type, imag_value);
+
+  tree inner = build_complex (inner_type, tree_real, tree_imag);
+  return new rvalue (this, inner);
+}
   else
 {
   REAL_VALUE_TYPE real_value;
@@ -718,6 +758,25 @@ new_rvalue_from_const  (type *type,
   tree inner = build_int_cst (inner_type, value);
   return new rvalue (this, inner);
 }
+  else if (COMPLEX_FLOAT_TYPE_P (inner_type))
+{
+  tree tree_real;
+  tree tree_imag;
+  tree real_type;
+  REAL_VALUE_TYPE real_value;
+  REAL_VALUE_TYPE imag_value;
+
+  real_type = 

[PATCH 0/2] jit: Add support for complex types

[Petter Tomner via Gcc-patches]

Hi!


The following two patches adds support for complex types in libgccjit.

The complex types already are in the types enum, however they are not usable.

In the patch, to use complex types, the user need to call a option function 
enabling 
support. In this way, there will be a linking error if someone tries to use 
complex types
and a too old libgccjit.so, instead of a cryptic out of range enum error 
message at runtime. 

Since the types already are in the enum, I saw no better way that wouldn't be 
confusing.  

Patch 1 is implementation and patch 2 is docs and testcases. 

check-jit runs fine on x64 Debian.

Regards,
Petter
   

Re: [PATCH 03/18] rs6000: Handle gimple folding of target built-ins

[Bill Schmidt via Gcc-patches]

Hi Will,

On 9/13/21 1:42 PM, will schmidt wrote:

On Wed, 2021-09-01 at 11:13 -0500, Bill Schmidt via Gcc-patches wrote:

This is another patch that looks bigger than it really is.  Because we
have a new namespace for the builtins, allowing us to have both the old
and new builtin infrastructure supported at once, we need versions of
these functions that use the new builtin namespace.  Otherwise the code is
unchanged.

2021-08-31  Bill Schmidt  

gcc/
* config/rs6000/rs6000-call.c (rs6000_gimple_fold_new_builtin):
New forward decl.
(rs6000_gimple_fold_builtin): Call rs6000_gimple_fold_new_builtin.
(rs6000_new_builtin_valid_without_lhs): New function.
(rs6000_gimple_fold_new_mma_builtin): Likewise.
(rs6000_gimple_fold_new_builtin): Likewise.
---
  gcc/config/rs6000/rs6000-call.c | 1165 +++
  1 file changed, 1165 insertions(+)

diff --git a/gcc/config/rs6000/rs6000-call.c b/gcc/config/rs6000/rs6000-call.c
index 2c68aa3580c..eae4e15df1e 100644
--- a/gcc/config/rs6000/rs6000-call.c
+++ b/gcc/config/rs6000/rs6000-call.c
@@ -190,6 +190,7 @@ static tree builtin_function_type (machine_mode, 
machine_mode,
  static void rs6000_common_init_builtins (void);
  static void htm_init_builtins (void);
  static void mma_init_builtins (void);
+static bool rs6000_gimple_fold_new_builtin (gimple_stmt_iterator *gsi);


  /* Hash table to keep track of the argument types for builtin functions.  */
@@ -12024,6 +12025,9 @@ rs6000_gimple_fold_mma_builtin (gimple_stmt_iterator 
*gsi)
  bool
  rs6000_gimple_fold_builtin (gimple_stmt_iterator *gsi)
  {
+  if (new_builtins_are_live)
+return rs6000_gimple_fold_new_builtin (gsi);
+
gimple *stmt = gsi_stmt (*gsi);
tree fndecl = gimple_call_fndecl (stmt);
gcc_checking_assert (fndecl && DECL_BUILT_IN_CLASS (fndecl) == BUILT_IN_MD);

ok


@@ -12971,6 +12975,35 @@ rs6000_gimple_fold_builtin (gimple_stmt_iterator *gsi)
return false;
  }

+/*  Helper function to sort out which built-ins may be valid without having
+a LHS.  */
+static bool
+rs6000_new_builtin_valid_without_lhs (enum rs6000_gen_builtins fn_code,
+ tree fndecl)
+{
+  if (TREE_TYPE (TREE_TYPE (fndecl)) == void_type_node)
+return true;

Is that a better or improved version of the code as seen in
rs6000_builtin_valid_without_lhs ?
That is

  if (rs6000_builtin_info[fn_code].attr & RS6000_BTC_VOID)
return true;

ok either way.


It's a required change, because the old attr field has gone away. Good eye.

+
+  switch (fn_code)
+{
+case RS6000_BIF_STVX_V16QI:
+case RS6000_BIF_STVX_V8HI:
+case RS6000_BIF_STVX_V4SI:
+case RS6000_BIF_STVX_V4SF:
+case RS6000_BIF_STVX_V2DI:
+case RS6000_BIF_STVX_V2DF:
+case RS6000_BIF_STXVW4X_V16QI:
+case RS6000_BIF_STXVW4X_V8HI:
+case RS6000_BIF_STXVW4X_V4SF:
+case RS6000_BIF_STXVW4X_V4SI:
+case RS6000_BIF_STXVD2X_V2DF:
+case RS6000_BIF_STXVD2X_V2DI:
+  return true;
+default:
+  return false;
+}
+}
+
  /* Check whether a builtin function is supported in this target
 configuration.  */
  bool
@@ -13024,6 +13057,1138 @@ rs6000_new_builtin_is_supported (enum 
rs6000_gen_builtins fncode)
gcc_unreachable ();
  }

+/* Expand the MMA built-ins early, so that we can convert the pass-by-reference
+   __vector_quad arguments into pass-by-value arguments, leading to more
+   efficient code generation.  */
+static bool
+rs6000_gimple_fold_new_mma_builtin (gimple_stmt_iterator *gsi,
+   rs6000_gen_builtins fn_code)
+{
+  gimple *stmt = gsi_stmt (*gsi);
+  size_t fncode = (size_t) fn_code;
+
+  if (!bif_is_mma (rs6000_builtin_info_x[fncode]))
+return false;
+
+  /* Each call that can be gimple-expanded has an associated built-in
+ function that it will expand into.  If this one doesn't, we have
+ already expanded it!  */
+  if (rs6000_builtin_info_x[fncode].assoc_bif == RS6000_BIF_NONE)
+return false;
+
+  bifdata *bd = _builtin_info_x[fncode];
+  unsigned nopnds = bd->nargs;
+  gimple_seq new_seq = NULL;
+  gimple *new_call;
+  tree new_decl;
+
+  /* Compatibility built-ins; we used to call these
+ __builtin_mma_{dis,}assemble_pair, but now we call them
+ __builtin_vsx_{dis,}assemble_pair.  Handle the old versions.  */
+  if (fncode == RS6000_BIF_ASSEMBLE_PAIR)
+fncode = RS6000_BIF_ASSEMBLE_PAIR_V;
+  else if (fncode == RS6000_BIF_DISASSEMBLE_PAIR)
+fncode = RS6000_BIF_DISASSEMBLE_PAIR_V;
+
+  if (fncode == RS6000_BIF_DISASSEMBLE_ACC
+  || fncode == RS6000_BIF_DISASSEMBLE_PAIR_V)
+{
+  /* This is an MMA disassemble built-in function.  */
+  push_gimplify_context (true);
+  unsigned nvec = (fncode == RS6000_BIF_DISASSEMBLE_ACC) ? 4 : 2;
+  tree dst_ptr = gimple_call_arg (stmt, 0);
+  tree src_ptr = gimple_call_arg (stmt, 1);
+  tree src_type = TREE_TYPE (src_ptr);
+  tree src = create_tmp_reg_or_ssa_name 

[PATCH][RFC] pru: Named address space for R30/R31 I/O access

[Dimitar Dimitrov]

Hi,

I'm sending this patch to get feedback for a new PRU CPU port feature.
My intention is to push it to master by end of September, so that it gets
included in GCC 12.

The PRU architecture provides single-cycle access to GPIO pins via
special designated CPU registers - R30 and R31. These two registers can
of course be accessed in C code using inline assembly, but that can be
intimidating to users.

The TI proprietary compiler [1] can expose these I/O registers as global
volatile registers:
  volatile register unsigned int __R31;

Consequently, accessing them in user programs is as straightforward as
using a regular global variable:
  __R31 |= (1 << 2);

Unfortunately, global volatile registers are not supported by GCC [2].
I decided to implement convenient access to __R30 and __R31 using a new
named address space:
  extern volatile __regio_symbol unsigned int __R30;

Unlike global registers, volatile global memory variables are well
supported in GCC.  Memory writes and reads to the __regio_symbol address
space are converted to writes and reads to R30 and R31 CPU registers.
The declared variable name determines which of the two registers it is
representing.

With an ifdef for the __R30/__R31 declarations, user programs can now
be source-compatible with both TI and GCC toolchains.

[1] https://www.ti.com/lit/ug/spruhv7c/spruhv7c.pdf , "Global Register 
Variables"
[2] https://gcc.gnu.org/ml/gcc-patches/2015-01/msg02241.html

gcc/ChangeLog:

* config/pru/constraints.md (Rrio): New constraint.
* config/pru/predicates.md (regio_operand): New predicate.
* config/pru/pru-pragma.c (pru_register_pragmas): Register
the __regio_symbol address space.
* config/pru/pru-protos.h (pru_symref2ioregno): Declaration.
* config/pru/pru.c (pru_symref2ioregno): New helper function.
(pru_legitimate_address_p): Remove.
(pru_addr_space_legitimate_address_p): Use the address space
aware hook variant.
(pru_nongeneric_pointer_addrspace): New helper function.
(pru_insert_attributes): New function to validate __regio_symbol
usage.
(TARGET_INSERT_ATTRIBUTES): New macro.
(TARGET_LEGITIMATE_ADDRESS_P): Remove.
(TARGET_ADDR_SPACE_LEGITIMATE_ADDRESS_P): New macro.
* config/pru/pru.h (enum reg_class): Add REGIO_REGS class.
* config/pru/pru.md (*regio_readsi): New pattern to read I/O
registers.
(*regio_nozext_writesi): New pattern to write to I/O registers.
(*regio_zext_write_r30): Ditto.
* doc/extend.texi: Document the new PRU Named Address Space.

gcc/testsuite/ChangeLog:

* gcc.target/pru/regio-as-pointer.c: New negative test.
* gcc.target/pru/regio-as-pointer2.c: New negative test.
* gcc.target/pru/regio-decl-2.c: New negative test.
* gcc.target/pru/regio-decl-3.c: New negative test.
* gcc.target/pru/regio-decl-4.c: New negative test.
* gcc.target/pru/regio-decl.c: New negative test.
* gcc.target/pru/regio-di.c: New negative test.
* gcc.target/pru/regio-hi.c: New negative test.
* gcc.target/pru/regio-qi.c: New negative test.
* gcc.target/pru/regio.c: New test.
* gcc.target/pru/regio.h: New helper header.

Signed-off-by: Dimitar Dimitrov 
---
 gcc/config/pru/constraints.md |   5 +
 gcc/config/pru/predicates.md  |  19 +++
 gcc/config/pru/pru-pragma.c   |   2 +
 gcc/config/pru/pru-protos.h   |   3 +
 gcc/config/pru/pru.c  | 155 +-
 gcc/config/pru/pru.h  |   5 +
 gcc/config/pru/pru.md | 102 +++-
 gcc/doc/extend.texi   |  19 ++-
 .../gcc.target/pru/regio-as-pointer.c |  11 ++
 .../gcc.target/pru/regio-as-pointer2.c|  11 ++
 gcc/testsuite/gcc.target/pru/regio-decl-2.c   |  13 ++
 gcc/testsuite/gcc.target/pru/regio-decl-3.c   |  19 +++
 gcc/testsuite/gcc.target/pru/regio-decl-4.c   |  17 ++
 gcc/testsuite/gcc.target/pru/regio-decl.c |  15 ++
 gcc/testsuite/gcc.target/pru/regio-di.c   |   9 +
 gcc/testsuite/gcc.target/pru/regio-hi.c   |   9 +
 gcc/testsuite/gcc.target/pru/regio-qi.c   |   9 +
 gcc/testsuite/gcc.target/pru/regio.c  |  58 +++
 gcc/testsuite/gcc.target/pru/regio.h  |   7 +
 19 files changed, 477 insertions(+), 11 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/pru/regio-as-pointer.c
 create mode 100644 gcc/testsuite/gcc.target/pru/regio-as-pointer2.c
 create mode 100644 gcc/testsuite/gcc.target/pru/regio-decl-2.c
 create mode 100644 gcc/testsuite/gcc.target/pru/regio-decl-3.c
 create mode 100644 gcc/testsuite/gcc.target/pru/regio-decl-4.c
 create mode 100644 gcc/testsuite/gcc.target/pru/regio-decl.c
 create mode 100644 gcc/testsuite/gcc.target/pru/regio-di.c
 create mode 100644 gcc/testsuite/gcc.target/pru/regio-hi.c
 create mode 100644 

Re: [PATCH, Fortran] Revert to non-multilib-specific ISO_Fortran_binding.h

[Gerald Pfeifer]

On Tue, 14 Sep 2021, Tobias Burnus wrote:
> And, related, does the following make sense and fixes the issue?
> 
> --- a/libgfortran/ISO_Fortran_binding.h
> +++ b/libgfortran/ISO_Fortran_binding.h
> @@ -228,5 +228,5 @@ extern int CFI_setpointer (CFI_cdesc_t *, CFI_cdesc_t *,
> const CFI_index_t []);
> 
>  /* This is the 80-bit encoding on x86; Fortran assigns it kind 10.  */
> -#elif (LDBL_MANT_DIG == 64 \
> +#elif ((LDBL_MANT_DIG == 64 || LDBL_MANT_DIG == 53) \
> && LDBL_MIN_EXP == -16381 \
> && LDBL_MAX_EXP == 16384)

Yes, with this patch (on top of current trunk) i586-freebsd-* is back
in bootstrap land. :)

On Tue, 14 Sep 2021, Jakub Jelinek wrote:
>> That looks like range of extended float, but rounded to double float
>> precision.
> Yeah.
> real.c has:
> /* The following caters to i386 systems that set the rounding precision
>to 53 bits instead of 64, e.g. FreeBSD.  */
> const struct real_format ieee_extended_intel_96_round_53_format =
> But, wonder why it didn't work with the float.h include then, because
> https://github.com/lattera/freebsd/blob/master/sys/x86/include/float.h
> seems to define LDBL_MANT_DIG to 64, LDBL_MIN_EXP to (-16381) and
> LDBL_MAX_EXP to 16384 and that case was handled in ISO_Fortran_binding.h.

A friendly soul reminded me off-list "that on i585-*-freebsd, the FPU 
is put into a mode where long double has only 53 bits of precision instead 
of 64 bits. [ /usr/include/x86/fpu.h has ]

/*
 * The hardware default control word for i387's and later coprocessors is
 * 0x37F, giving:
 *
 *  round to nearest
 *  64-bit precision
 *  all exceptions masked.
 *
 * FreeBSD/i386 uses 53 bit precision for things like fadd/fsub/fsqrt etc
 * because of the difference between memory and fpu register stack arguments.
 * If its using an intermediate fpu register, it has 80/64 bits to work
 * with.  If it uses memory, it has 64/53 bits to work with.  However,
 * gcc is aware of this and goes to a fair bit of trouble to make the
 * best use of it.
 *
 * This is mostly academic for AMD64, because the ABI prefers the use
 * SSE2 based math.  For FreeBSD/amd64, we go with the default settings.
 */
#define __INITIAL_FPUCW__   0x037F
#define __INITIAL_FPUCW_I386__  0x127F
#define __INITIAL_NPXCW__   __INITIAL_FPUCW_I386__
#define __INITIAL_MXCSR__   0x1F80
#define __INITIAL_MXCSR_MASK__  0xFFBF "

(end quote)


Thanks for looking into this together!

Gerald

[PATCH] c++: default ctor that's also a list ctor [PR102050]

[Patrick Palka via Gcc-patches]

In grok_special_member_properties we need to set TYPE_HAS_COPY_CTOR,
TYPE_HAS_DEFAULT_CONSTRUCTOR and TYPE_HAS_LIST_CTOR independently
from each other because a single constructor can be both a default and
list constructor (as in the first testcase), or both a default and copy
constructor (as in the second testcase).

Bootstrapped and regtested on x86_64-pc-linux-gsu, does this look OK for
trunk?

PR c++/102050

gcc/cp/ChangeLog:

* decl.c (grok_special_member_properties): Set
TYPE_HAS_COPY_CTOR, TYPE_HAS_DEFAULT_CONSTRUCTOR
and TYPE_HAS_LIST_CTOR independently from each other.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/initlist125.C: New test.
* g++.dg/cpp0x/initlist126.C: New test.
---
 gcc/cp/decl.c|  6 --
 gcc/testsuite/g++.dg/cpp0x/initlist125.C | 10 ++
 gcc/testsuite/g++.dg/cpp0x/initlist126.C | 17 +
 3 files changed, 31 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/initlist125.C
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/initlist126.C

diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index 1a2925b4108..76e4e6e8a26 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -14843,9 +14843,11 @@ grok_special_member_properties (tree decl)
  if (ctor > 1)
TYPE_HAS_CONST_COPY_CTOR (class_type) = 1;
}
-  else if (sufficient_parms_p (FUNCTION_FIRST_USER_PARMTYPE (decl)))
+
+  if (sufficient_parms_p (FUNCTION_FIRST_USER_PARMTYPE (decl)))
TYPE_HAS_DEFAULT_CONSTRUCTOR (class_type) = 1;
-  else if (is_list_ctor (decl))
+
+  if (is_list_ctor (decl))
TYPE_HAS_LIST_CTOR (class_type) = 1;
 
   if (DECL_DECLARED_CONSTEXPR_P (decl)
diff --git a/gcc/testsuite/g++.dg/cpp0x/initlist125.C 
b/gcc/testsuite/g++.dg/cpp0x/initlist125.C
new file mode 100644
index 000..08ae3741c67
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/initlist125.C
@@ -0,0 +1,10 @@
+// PR c++/102050
+// { dg-do compile { target c++11 } }
+
+#include 
+
+struct A { A(std::initializer_list = {}); };
+
+A x{0};
+A y{1, 2, 3};
+A z;
diff --git a/gcc/testsuite/g++.dg/cpp0x/initlist126.C 
b/gcc/testsuite/g++.dg/cpp0x/initlist126.C
new file mode 100644
index 000..0a8fb998be6
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/initlist126.C
@@ -0,0 +1,17 @@
+// PR c++/102050
+// { dg-do compile { target c++11 } }
+
+#include 
+
+extern struct A a;
+
+struct A {
+  A(const A& = a);
+  A(std::initializer_list) = delete;
+};
+
+void f(A);
+
+int main() {
+  f({}); // { dg-bogus "deleted" }
+}
-- 
2.33.0.328.g8b7c11b866

[PATCH] PR fortran/102287 - optional allocatable array arguments (intent out) of derived types with allocatable components are not properly passed to subroutines

[Harald Anlauf via Gcc-patches]

As nicely described in the PR, we mishandled the case of passing
optional allocatable DT arguments with allocatable components
when the INTENT was declared as INTENT(OUT), as we unconditionally
tried to deallocate these components even when the argument was not
present.  The obvious solution is to wrap the code for deallocation
by a check for presence.

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

As this is a potentially nasty wrong-code bug, I'd like to backport
to at least 11-branch.

Thanks,
Harald


Fortran - fix handling of optional allocatable DT arguments with INTENT(OUT)

gcc/fortran/ChangeLog:

PR fortran/102287
* trans-expr.c (gfc_conv_procedure_call): Wrap deallocation of
allocatable components of optional allocatable derived type
procedure arguments with INTENT(OUT) into a presence check.

gcc/testsuite/ChangeLog:

PR fortran/102287
* gfortran.dg/intent_out_14.f90: New test.

diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c
index 18d665192f0..4a81f4695d9 100644
--- a/gcc/fortran/trans-expr.c
+++ b/gcc/fortran/trans-expr.c
@@ -6548,6 +6548,17 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * sym,
 		// deallocate the components first
 		tmp = gfc_deallocate_alloc_comp (fsym->ts.u.derived,
 		 parmse.expr, e->rank);
+		/* But check whether dummy argument is optional.  */
+		if (tmp != NULL_TREE
+			&& fsym->attr.optional
+			&& e->expr_type == EXPR_VARIABLE
+			&& e->symtree->n.sym->attr.optional)
+		  {
+			tree present;
+			present = gfc_conv_expr_present (e->symtree->n.sym);
+			tmp = build3_v (COND_EXPR, present, tmp,
+	build_empty_stmt (input_location));
+		  }
 		if (tmp != NULL_TREE)
 		  gfc_add_expr_to_block (>pre, tmp);
 		  }
diff --git a/gcc/testsuite/gfortran.dg/intent_out_14.f90 b/gcc/testsuite/gfortran.dg/intent_out_14.f90
new file mode 100644
index 000..e5994635008
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/intent_out_14.f90
@@ -0,0 +1,24 @@
+! { dg-do run }
+! PR fortran/102287 - optional allocatable DT array arguments (intent out)
+
+module m
+  type t
+ integer, allocatable :: a
+  end type t
+contains
+  subroutine a (x, v)
+type(t), optional, allocatable, intent(out) :: x(:)
+type(t), optional,  intent(out) :: v(:)
+call b (x, v)
+  end subroutine a
+
+  subroutine b (y, w)
+type(t), optional, allocatable, intent(out) :: y(:)
+type(t), optional,  intent(out) :: w(:)
+  end subroutine b
+end module m
+
+program p
+  use m
+  call a ()
+end

[PATCH, committed] PR fortran/102311 - fix ICE during error recovery checking entry characteristics

[Harald Anlauf via Gcc-patches]

Committed as obvious as r12-3533.

The fix to PR87737 did work for the given testcase, but could lead
to a bad internal compiler state for a variation of the testcase.
(Found by Gerhard...)

The solution was to not return too early after emitting the error
message but going through a 'cleanup' instead.

Regtested on x86_64-pc-linux-gnu, and checked the testcase also
with valgrind (to be on the safer side).

Thanks,
Harald


Fortran - fix ICE during error recovery checking entry characteristics

gcc/fortran/ChangeLog:

PR fortran/102311
* resolve.c (resolve_entries): Attempt to recover cleanly after
rejecting mismatched function entries.

gcc/testsuite/ChangeLog:

PR fortran/102311
* gfortran.dg/entry_25.f90: New test.

diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index 8e5ed1c032c..30b96b2f597 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -811,7 +811,7 @@ resolve_entries (gfc_namespace *ns)
 	  gfc_error ("Function %s at %L has entry %s with mismatched "
 			 "characteristics", ns->entries->sym->name,
 			 >entries->sym->declared_at, el->sym->name);
-	  return;
+	  goto cleanup;
 	}
 	  else if (ts->type == BT_CHARACTER && ts->u.cl && fts->u.cl
 		   && (((ts->u.cl->length && !fts->u.cl->length)
@@ -917,6 +917,8 @@ resolve_entries (gfc_namespace *ns)
 	}
 	}
 }
+
+cleanup:
   proc->attr.access = ACCESS_PRIVATE;
   proc->attr.entry_master = 1;

diff --git a/gcc/testsuite/gfortran.dg/entry_25.f90 b/gcc/testsuite/gfortran.dg/entry_25.f90
new file mode 100644
index 000..518560aa198
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/entry_25.f90
@@ -0,0 +1,13 @@
+! { dg-do compile }
+! PR fortran/102311 - ICE during error recovery checking entry characteristics
+
+module m
+contains
+  function f() ! { dg-error "mismatched characteristics" }
+character(:), allocatable :: f
+character(1)  :: g
+f = 'f'
+  entry g()
+g = 'g'
+  end
+end

Re: [PATCH] c++tools : Add a simple handler for ModuleCompiledRequest.

[Iain Sandoe]

> On 9 Sep 2021, at 17:15, Jason Merrill  wrote:
> 
> On 8/18/21 3:13 PM, Iain Sandoe wrote:
>> Hi,
>> I have found it useful when working with modules stuff to have the completed
>> set of command/responses available (some people working with the interfaces
>> for more sophisticated tools are using them).  This message is a hand-shake
>> telling the server that a CMI has been built, and for the simplistic server
>> implementation doesn’t need to do anything.
>> This just replies with "OK”.
>> Tested on x86_64-darwin.
>> OK for master?
>> thanks
>> Iain
>> c++tools/ChangeLog:
>>  * resolver.cc (module_resolver::ModuleCompiledRequest):
>>  Add a simple handler.
>>  * resolver.h: Declare handler for ModuleCompiledRequest.
>> ---
>>  c++tools/resolver.cc | 7 +++
>>  c++tools/resolver.h  | 4 
>>  2 files changed, 11 insertions(+)
>> diff --git a/c++tools/resolver.cc b/c++tools/resolver.cc
>> index edd4624b121..f862161095d 100644
>> --- a/c++tools/resolver.cc
>> +++ b/c++tools/resolver.cc
>> @@ -307,3 +307,10 @@ module_resolver::IncludeTranslateRequest (Cody::Server 
>> *s, Cody::Flags,
>>return 0;
>>  }
> 
> Could use a comment here.  OK with that added.

this is what I pushed,
thanks
Iain

[PATCH] c++tools : Add a simple handler for ModuleCompiledRequest.

This just replies with "OK".

c++tools/ChangeLog:

* resolver.cc (module_resolver::ModuleCompiledRequest):
Add a simple handler.
* resolver.h: Declare handler for ModuleCompiledRequest.
---
 c++tools/resolver.cc | 11 +++
 c++tools/resolver.h  |  4 
 2 files changed, 15 insertions(+)

diff --git a/c++tools/resolver.cc b/c++tools/resolver.cc
index edd4624b121..421fdaa55fe 100644
--- a/c++tools/resolver.cc
+++ b/c++tools/resolver.cc
@@ -307,3 +307,14 @@ module_resolver::IncludeTranslateRequest (Cody::Server *s, 
Cody::Flags,
   return 0;
 }
 
+/* This handles a client notification to the server that a CMI has been
+   produced for a module.  For this simplified server, we just accept
+   the transaction and respond with "OK".  */
+
+int
+module_resolver::ModuleCompiledRequest (Cody::Server *s, Cody::Flags,
+ std::string &)
+{
+  s->OKResponse();
+  return 0;
+}
diff --git a/c++tools/resolver.h b/c++tools/resolver.h
index b2f4381b4fa..c1ce9564e7f 100644
--- a/c++tools/resolver.h
+++ b/c++tools/resolver.h
@@ -96,6 +96,10 @@ public:
   std::string )
 override;
 
+  using parent::ModuleCompiledRequest;
+  virtual int ModuleCompiledRequest (Cody::Server *s, Cody::Flags Flags,
+std::string ) override;
+
 private:
   using parent::GetCMISuffix;
   virtual char const *GetCMISuffix () override;
-- 

Re: [PATCH] libstdc++-v3: Optimize 'to_string' with numeric_limits instead of __to_chars_len

[Jonathan Wakely via Gcc-patches]

Please CC libstdc++ patches to the libstdc++ list, or they won't get
reviewed (because I don't subscribe to gcc-patches).

GCC 5 does implement SSO but it's only used conditionally. Your patch
uses numeric_limits unconditionally, which will result in
over-allocation for COW strings.

There also seems to be a syntax error in the unsigned overload, was
this patch tested?

Minor: the "component" tag in the subject should be just "libstdc++:"
without the "-v3" part.

Re: [PATCH, Fortran] Revert to non-multilib-specific ISO_Fortran_binding.h

[Gerald Pfeifer]

On Mon, 13 Sep 2021, Sandra Loosemore wrote:
> Here's a patch.  Gerald, can you check that this fixes your bootstrap 
> problem on i586-unknown-freebsd11?

I does not change the bootstrap failure on i586-unknown-freebsd11
- though looking at the discussion here still looks like a good 
change to make?


And I just kicked off testing Tobias' suggestion on top of an
unpatched tree and will let you know:

   /* This is the 80-bit encoding on x86; Fortran assigns it kind 10.  */
  -#elif (LDBL_MANT_DIG == 64 \
  +#elif ((LDBL_MANT_DIG == 64 || LDBL_MANT_DIG == 53) \
  && LDBL_MIN_EXP == -16381 \
  && LDBL_MAX_EXP == 16384)

Gerald

Re: Regression with recent change

[Jeff Law via Gcc-patches]

On 9/14/2021 8:53 AM, Aldy Hernandez wrote:



On 9/14/21 4:13 PM, Michael Matz wrote:

Hello,

On Mon, 13 Sep 2021, Aldy Hernandez via Gcc-patches wrote:

The testcase still tests what it's supposed to test with ...


typedef unsigned short uint16_t;

uint16_t a, b;

int *j_global;
uint16_t f(void)
{
    int c, **p;
    short d = 2, e = 4;



... "c = a;" added here (i.e. it still hangs before the pr55107 change).


    for (;; b++)
  {
    int *j = j_global, k = 0;

    for (; *j; j++)
   {
 for(; c; c++)
   for(; k < 1; k++)
 {
   short *f = 

   if(b)
 return *f;
 }
   }

    if(!c)
   d *= e;

    a = d;
    if ((a ? b = 0 : (**p ? : 1) != (d != 1 ? 1 : (b = 0))) != 
((k ? a

: 0)

 < (a * (c = k
   **p = 0;
  }
}



Thanks for getting rid of the noise here.

I've simplified the above to show what's going on in the warning on
nds32-elf:

int george, *global;
int stuff(), readme();

int
f (void)
{
    int store;

    for (;;)
  {
    int k = 0;

    while (global)
 {
   for (; store; ++store)


Yeah, that seems a correct warning, your 'store' (the 'c' in the 
original

testcase) is really used uninitialized (when 'global' aka '*j_global' is
non-zero).  Sorry for not noticing earlier, I was only getting rid of
warnings, not carefully looking at the testcase itself.  I think with
above initialization of 'c' it's conforming, and still a correct test 
for

the original bug.


This is good news.  So far, every single warning/problem that has 
surfaced with the backward threader rewrite has been a latent bug 
elsewhere (or a bad test) :-).

Always good news :-)



Would you mind checking in your changes to the testcase?

Yes, please do.

jeff

Re: [PATCH] rs6000: Disable optimizing multiple xxsetaccz instructions into one xxsetaccz

[Peter Bergner via Gcc-patches]

On 9/13/21 7:17 PM, Segher Boessenkool wrote:
> On Mon, Sep 13, 2021 at 05:10:42PM -0500, Peter Bergner wrote:
>> It still has "a" match_operand...for operand 0.  The match_operand
>> for operand 1 was what was removed.  Want me to reword that as
>> "Remove source match_operand." or "Remove match_operand 1." or ???
> 
> Ah I see, I looked with my eyes close apparently.  "Remove operand 1"?

Ok, I'll use that.




>> ;; We can't have integer constants in XOmode so we wrap this in an
>> ;; UNSPEC_VOLATILE.
>>
>> ...to refer to the dummy zero for the source.  Let me know what you want.
> 
> The latter option adds information, so if you think that is useful to
> have here, let's go with that?

Sure will do.


I'll make the above changes and the ones from my previous reply and do one
last build before pushing.  Thanks for the review!


Peter

[PATCH] coroutines: Small cleanups to await_statement_walker [NFC].

[Iain Sandoe]

Hi

Some small code cleanups that allow us to have just one place that
we handle a statement with await expression(s) embedded.  Also we
can reduce the work done to figure out whether a statement contains
any such expressions.

tested on x86_64,powerpc64le-linux x86_64-darwin
OK for master?
thanks
Iain

-

There is no need to make a MODIFY_EXPR for any of the condition
vars that we synthesize.

Expansion of co_return can be carried out independently of any
co_awaits that might be contained which simplifies this.

Where we are rewriting statements to handle await expression
logic, there is no need to carry out any analysis - we just need
to detect the presence of any co_await.

Signed-off-by: Iain Sandoe 

gcc/cp/ChangeLog:

* coroutines.cc (await_statement_walker): Code cleanups.
---
 gcc/cp/coroutines.cc | 121 ---
 1 file changed, 56 insertions(+), 65 deletions(-)

diff --git a/gcc/cp/coroutines.cc b/gcc/cp/coroutines.cc
index d2cc2e73c89..27556723b71 100644
--- a/gcc/cp/coroutines.cc
+++ b/gcc/cp/coroutines.cc
@@ -3412,16 +3412,11 @@ await_statement_walker (tree *stmt, int *do_subtree, 
void *d)
   return NULL_TREE;
 }
 
-  /* We have something to be handled as a single statement.  */
-  bool has_cleanup_wrapper = TREE_CODE (*stmt) == CLEANUP_POINT_EXPR;
-  hash_set visited;
-  awpts->saw_awaits = 0;
-  hash_set truth_aoif_to_expand;
-  awpts->truth_aoif_to_expand = _aoif_to_expand;
-  awpts->needs_truth_if_exp = false;
-  awpts->has_awaiter_init = false;
+  /* We have something to be handled as a single statement.  We have to handle
+ a few statements specially where await statements have to be moved out of
+ constructs.  */
   tree expr = *stmt;
-  if (has_cleanup_wrapper)
+  if (TREE_CODE (*stmt) == CLEANUP_POINT_EXPR)
 expr = TREE_OPERAND (expr, 0);
   STRIP_NOPS (expr);
 
@@ -3437,6 +3432,8 @@ await_statement_walker (tree *stmt, int *do_subtree, void 
*d)
   transforms can be implemented.  */
case IF_STMT:
  {
+   tree *await_ptr;
+   hash_set visited;
/* Transform 'if (cond with awaits) then stmt1 else stmt2' into
   bool cond = cond with awaits.
   if (cond) then stmt1 else stmt2.  */
@@ -3444,10 +3441,8 @@ await_statement_walker (tree *stmt, int *do_subtree, 
void *d)
/* We treat the condition as if it was a stand-alone statement,
   to see if there are any await expressions which will be analyzed
   and registered.  */
-   if ((res = cp_walk_tree (_COND (if_stmt),
-   analyze_expression_awaits, d, )))
- return res;
-   if (!awpts->saw_awaits)
+   if (!(cp_walk_tree (_COND (if_stmt),
+ find_any_await, _ptr, )))
  return NULL_TREE; /* Nothing special to do here.  */
 
gcc_checking_assert (!awpts->bind_stack->is_empty());
@@ -3463,7 +3458,7 @@ await_statement_walker (tree *stmt, int *do_subtree, void 
*d)
/* We want to initialize the new variable with the expression
   that contains the await(s) and potentially also needs to
   have truth_if expressions expanded.  */
-   tree new_s = build2_loc (sloc, MODIFY_EXPR, boolean_type_node,
+   tree new_s = build2_loc (sloc, INIT_EXPR, boolean_type_node,
 newvar, cond_inner);
finish_expr_stmt (new_s);
IF_COND (if_stmt) = newvar;
@@ -3477,25 +3472,25 @@ await_statement_walker (tree *stmt, int *do_subtree, 
void *d)
  break;
case FOR_STMT:
  {
+   tree *await_ptr;
+   hash_set visited;
/* for loops only need special treatment if the condition or the
   iteration expression contain a co_await.  */
tree for_stmt = *stmt;
/* Sanity check.  */
-   if ((res = cp_walk_tree (_INIT_STMT (for_stmt),
-   analyze_expression_awaits, d, )))
- return res;
-   gcc_checking_assert (!awpts->saw_awaits);
-
-   if ((res = cp_walk_tree (_COND (for_stmt),
-   analyze_expression_awaits, d, )))
- return res;
-   bool for_cond_await = awpts->saw_awaits != 0;
-   unsigned save_awaits = awpts->saw_awaits;
-
-   if ((res = cp_walk_tree (_EXPR (for_stmt),
-   analyze_expression_awaits, d, )))
- return res;
-   bool for_expr_await = awpts->saw_awaits > save_awaits;
+   gcc_checking_assert
+ (!(cp_walk_tree (_INIT_STMT (for_stmt), find_any_await,
+  _ptr, )));
+
+   visited.empty ();
+   bool for_cond_await
+ = cp_walk_tree (_COND (for_stmt), find_any_await,
+ _ptr, );
+
+   visited.empty ();
+   bool for_expr_await
+ = cp_walk_tree (_EXPR (for_stmt), find_any_await,
+ 

Re: [PATCH, Fortran] Revert to non-multilib-specific ISO_Fortran_binding.h

[Andreas Schwab]

On Sep 14 2021, Jakub Jelinek wrote:

> But, wonder why it didn't work with the float.h include then, because
> https://github.com/lattera/freebsd/blob/master/sys/x86/include/float.h
> seems to define LDBL_MANT_DIG to 64, LDBL_MIN_EXP to (-16381) and
> LDBL_MAX_EXP to 16384 and that case was handled in ISO_Fortran_binding.h.

Doesn't gcc always use its own float.h?

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: [PATCH RFC] c++: don't call 'rvalue' in coroutines code

[Jason Merrill via Gcc-patches]

On 9/14/21 11:21 AM, Iain Sandoe wrote:

Hi Jason,

I was looking at handling some backports to 11.x and 10.x for coroutines
code-gen fixes ...


On 7 May 2021, at 04:11, Jason Merrill  wrote:

A change to check glvalue_p rather than specifically for TARGET_EXPR
revealed issues with the coroutines code's use of the 'rvalue' function,
which shouldn't be used on class glvalues, so I've removed those calls.

In build_co_await I just dropped them, because I don't see anything in the
co_await specification that indicates that we would want to move from an
lvalue result of operator co_await.  And simplified that code while I was
touching it; cp_build_modify_expr (...INIT_EXPR...) will call the
constructor.

In morph_fn_to_coro I changed the handling of the rvalue reference coroutine
frame field to use move, to treat the rval ref as an xvalue.  I used
forward_parm to pass the function parms to the constructor for the field.
And I simplified the return handling so we get the desired rvalue semantics
from the normal implicit move on return.


… this was eventually commited as 14ed21f8749 - do you think it should be
back-ported to 11? … 10? (I can handle it along with the ones I am doing, if
so).


To 11, sure.  I probably wouldn't bother backporting it to 10.

Jason

Re: [PATCH, Fortran] Revert to non-multilib-specific ISO_Fortran_binding.h

[Jakub Jelinek via Gcc-patches]

On Tue, Sep 14, 2021 at 05:17:04PM +0200, Andreas Schwab wrote:
> On Sep 14 2021, Gerald Pfeifer wrote:
> 
> >   #define __LDBL_MANT_DIG__ 53
> >   #define __LDBL_DIG__ 15
> >   #define __LDBL_MIN_EXP__ (-16381)
> >   #define __LDBL_MIN_10_EXP__ (-4931)
> >   #define __LDBL_MAX_EXP__ 16384
> >   #define __LDBL_MAX_10_EXP__ 4932
> >   #define __LDBL_DECIMAL_DIG__ 17
> >   #define __LDBL_MAX__ 1.18973149535723163299902939989638351e+4932L
> >   #define __LDBL_NORM_MAX__ 1.18973149535723163299902939989638351e+4932L
> >   #define __LDBL_MIN__ 3.36210314311209350626267781732175260e-4932L
> >   #define __LDBL_EPSILON__ 2.22044604925031308084726333618164062e-16L
> >   #define __LDBL_DENORM_MIN__ 7.46536864129530798597817535205257178e-4948L
> >   #define __LDBL_HAS_DENORM__ 1
> >   #define __LDBL_HAS_INFINITY__ 1
> >   #define __LDBL_HAS_QUIET_NAN__ 1
> >   #define __LDBL_IS_IEC_60559__ 2
> 
> That looks like range of extended float, but rounded to double float
> precision.

Yeah.
real.c has:
/* The following caters to i386 systems that set the rounding precision
   to 53 bits instead of 64, e.g. FreeBSD.  */
const struct real_format ieee_extended_intel_96_round_53_format =
But, wonder why it didn't work with the float.h include then, because
https://github.com/lattera/freebsd/blob/master/sys/x86/include/float.h
seems to define LDBL_MANT_DIG to 64, LDBL_MIN_EXP to (-16381) and
LDBL_MAX_EXP to 16384 and that case was handled in ISO_Fortran_binding.h.

Jakub

Re: [PATCH RFC] c++: don't call 'rvalue' in coroutines code

[Iain Sandoe]

Hi Jason,

I was looking at handling some backports to 11.x and 10.x for coroutines
code-gen fixes ...

> On 7 May 2021, at 04:11, Jason Merrill  wrote:
> 
> A change to check glvalue_p rather than specifically for TARGET_EXPR
> revealed issues with the coroutines code's use of the 'rvalue' function,
> which shouldn't be used on class glvalues, so I've removed those calls.
> 
> In build_co_await I just dropped them, because I don't see anything in the
> co_await specification that indicates that we would want to move from an
> lvalue result of operator co_await.  And simplified that code while I was
> touching it; cp_build_modify_expr (...INIT_EXPR...) will call the
> constructor.
> 
> In morph_fn_to_coro I changed the handling of the rvalue reference coroutine
> frame field to use move, to treat the rval ref as an xvalue.  I used
> forward_parm to pass the function parms to the constructor for the field.
> And I simplified the return handling so we get the desired rvalue semantics
> from the normal implicit move on return.

… this was eventually commited as 14ed21f8749 - do you think it should be
back-ported to 11? … 10? (I can handle it along with the ones I am doing, if
so).

thanks
Iain

Re: [PATCH, Fortran] Revert to non-multilib-specific ISO_Fortran_binding.h

[Andreas Schwab]

On Sep 14 2021, Gerald Pfeifer wrote:

>   #define __LDBL_MANT_DIG__ 53
>   #define __LDBL_DIG__ 15
>   #define __LDBL_MIN_EXP__ (-16381)
>   #define __LDBL_MIN_10_EXP__ (-4931)
>   #define __LDBL_MAX_EXP__ 16384
>   #define __LDBL_MAX_10_EXP__ 4932
>   #define __LDBL_DECIMAL_DIG__ 17
>   #define __LDBL_MAX__ 1.18973149535723163299902939989638351e+4932L
>   #define __LDBL_NORM_MAX__ 1.18973149535723163299902939989638351e+4932L
>   #define __LDBL_MIN__ 3.36210314311209350626267781732175260e-4932L
>   #define __LDBL_EPSILON__ 2.22044604925031308084726333618164062e-16L
>   #define __LDBL_DENORM_MIN__ 7.46536864129530798597817535205257178e-4948L
>   #define __LDBL_HAS_DENORM__ 1
>   #define __LDBL_HAS_INFINITY__ 1
>   #define __LDBL_HAS_QUIET_NAN__ 1
>   #define __LDBL_IS_IEC_60559__ 2

That looks like range of extended float, but rounded to double float
precision.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: [PATCH, Fortran] Revert to non-multilib-specific ISO_Fortran_binding.h

[Tobias Burnus]

Hi Gerald,

I note:

On 13.09.21 17:56, Gerald Pfeifer wrote:

% egrep -r '#define.*LDBL_(MANT_DIG|MIN_EXP|MAX_EXP)'/usr/include/
/usr/include/x86/float.h:#define LDBL_MANT_DIG  64
/usr/include/x86/float.h:#define LDBL_MIN_EXP   (-16381)
/usr/include/x86/float.h:#define LDBL_MAX_EXP   16384

This looks like it matches existing Linux case already in place?

On 14.09.21 16:50, Gerald Pfeifer wrote:

On Mon, 13 Sep 2021, Tobias Burnus wrote:

Can you run 'echo | cpp -E -g3|grep DBL' to (or in the build dir: echo |
./gcc/cc1 -E -g3 -dD|grep DBL) to check what's the output?

Thank you, Tobias, and I'm just testing the proposed patch, but still
wanted to follow up on your question:

   % echo | ./gcc/cc1 -E -g3 -dD | grep DBL
   #define __DBL_MANT_DIG__ 53
   #define __DBL_MIN_EXP__ (-1021)
   #define __DBL_MAX_EXP__ 1024

   #define __LDBL_MANT_DIG__ 53
   #define __LDBL_MIN_EXP__ (-16381)
   #define __LDBL_MAX_EXP__ 16384


I note that LDBL_MANT_DIG is 53 as for "double" – while Linux
and your header file has 64. On the other hand, MIN/MAX_EXP for
"long double" are larger than "double" – and match the values
from Linux and the size in your header file.

Thus, the first question is: why does DBL_MANT_DIG differ (64 vs. 53)?

And, related, does the following make sense and fixes the issue?

--- a/libgfortran/ISO_Fortran_binding.h
+++ b/libgfortran/ISO_Fortran_binding.h
@@ -228,5 +228,5 @@ extern int CFI_setpointer (CFI_cdesc_t *, CFI_cdesc_t *, 
const CFI_index_t []);

 /* This is the 80-bit encoding on x86; Fortran assigns it kind 10.  */
-#elif (LDBL_MANT_DIG == 64 \
+#elif ((LDBL_MANT_DIG == 64 || LDBL_MANT_DIG == 53) \
&& LDBL_MIN_EXP == -16381 \
&& LDBL_MAX_EXP == 16384)

Tobias

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

Re: [PATCH] c++: empty union member activation during constexpr [PR102163]

[Jason Merrill via Gcc-patches]

On 9/13/21 3:54 PM, Patrick Palka wrote:

Here, the union's constructor is defined to activate its empty data
member _M_rest, but during constexpr evaluation of this constructor the
subobject constructor call to O::O(&_M_rest, 42) produces no side
effects that actually activates the member, so the union still appears
uninitialized after the fact.  This patch fixes this by faking up a
dummy MODIFY_EXPR in this situation, whose evaluation ensures the member
gets activated.

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
for trunk?


OK.


PR c++/102163

gcc/cp/ChangeLog:

* constexpr.c (cxx_eval_call_expression): After evaluating a
constructor call for an empty union member, produce a side
effect that makes sure the member is activated.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/constexpr-empty17.C: New test.
---
  gcc/cp/constexpr.c| 34 +++
  .../g++.dg/cpp0x/constexpr-empty17.C  | 21 
  2 files changed, 49 insertions(+), 6 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/cpp0x/constexpr-empty17.C

diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
index 7772fe62d95..40b0b80b438 100644
--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -2787,12 +2787,34 @@ cxx_eval_call_expression (const constexpr_ctx *ctx, 
tree t,
_target);
  
  	  if (DECL_CONSTRUCTOR_P (fun))

-   /* This can be null for a subobject constructor call, in
-  which case what we care about is the initialization
-  side-effects rather than the value.  We could get at the
-  value by evaluating *this, but we don't bother; there's
-  no need to put such a call in the hash table.  */
-   result = lval ? ctx->object : ctx->ctor;
+   {
+ /* This can be null for a subobject constructor call, in
+which case what we care about is the initialization
+side-effects rather than the value.  We could get at the
+value by evaluating *this, but we don't bother; there's
+no need to put such a call in the hash table.  */
+ result = lval ? ctx->object : ctx->ctor;
+
+ if (!result && new_obj
+ && TREE_CODE (new_obj) == COMPONENT_REF
+ && TREE_CODE (TREE_TYPE
+   (TREE_OPERAND (new_obj, 0))) == UNION_TYPE
+ && is_really_empty_class (TREE_TYPE (new_obj),
+   /*ignore_vptr*/false))
+   {
+ /* This constructor call for an empty union member might not
+have produced a side effect that actually activated the
+member.  So produce such a side effect now to ensure the
+union appears initialized.  */
+ tree activate = build2 (MODIFY_EXPR, TREE_TYPE (new_obj),
+ new_obj,
+ build_constructor (TREE_TYPE 
(new_obj),
+NULL));
+ cxx_eval_constant_expression (ctx, activate, lval,
+   non_constant_p, overflow_p);
+ ggc_free (activate);
+   }
+   }
  else if (VOID_TYPE_P (TREE_TYPE (res)))
result = void_node;
  else
diff --git a/gcc/testsuite/g++.dg/cpp0x/constexpr-empty17.C 
b/gcc/testsuite/g++.dg/cpp0x/constexpr-empty17.C
new file mode 100644
index 000..9d753a3bb69
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/constexpr-empty17.C
@@ -0,0 +1,21 @@
+// PR c++/102163
+// { dg-do compile { target c++11 } }
+
+struct O {
+  constexpr O(int) { }
+};
+
+union _Variadic_union {
+  constexpr _Variadic_union(int __arg) : _M_rest(__arg) { }
+
+  int _M_first;
+  O _M_rest;
+};
+
+
+struct _Variant_storage {
+  constexpr _Variant_storage() : _M_u(42) {}
+  _Variadic_union _M_u;
+};
+
+constexpr _Variant_storage w;

Re: Regression with recent change

[Aldy Hernandez via Gcc-patches]

On 9/14/21 4:13 PM, Michael Matz wrote:

Hello,

On Mon, 13 Sep 2021, Aldy Hernandez via Gcc-patches wrote:

The testcase still tests what it's supposed to test with ...


typedef unsigned short uint16_t;

uint16_t a, b;

int *j_global;
uint16_t f(void)
{
int c, **p;
short d = 2, e = 4;



... "c = a;" added here (i.e. it still hangs before the pr55107 change).


for (;; b++)
  {
int *j = j_global, k = 0;

for (; *j; j++)
   {
 for(; c; c++)
   for(; k < 1; k++)
 {
   short *f = 

   if(b)
 return *f;
 }
   }

if(!c)
   d *= e;

a = d;
if ((a ? b = 0 : (**p ? : 1) != (d != 1 ? 1 : (b = 0))) != ((k ? a

: 0)

 < (a * (c = k
   **p = 0;
  }
}



Thanks for getting rid of the noise here.

I've simplified the above to show what's going on in the warning on
nds32-elf:

int george, *global;
int stuff(), readme();

int
f (void)
{
int store;

for (;;)
  {
int k = 0;

while (global)
 {
   for (; store; ++store)


Yeah, that seems a correct warning, your 'store' (the 'c' in the original
testcase) is really used uninitialized (when 'global' aka '*j_global' is
non-zero).  Sorry for not noticing earlier, I was only getting rid of
warnings, not carefully looking at the testcase itself.  I think with
above initialization of 'c' it's conforming, and still a correct test for
the original bug.


This is good news.  So far, every single warning/problem that has 
surfaced with the backward threader rewrite has been a latent bug 
elsewhere (or a bad test) :-).


Would you mind checking in your changes to the testcase?

Thanks.
Aldy

Re: [PATCH] c++: Fix __is_*constructible/assignable for templates [PR102305]

[Jason Merrill via Gcc-patches]

On 9/14/21 4:48 AM, Jakub Jelinek wrote:

is_xible_helper returns error_mark_node (i.e. false from the traits)
for abstract classes by testing ABSTRACT_CLASS_TYPE_P (to) early.
Unfortunately, as the testcase shows, that doesn't work on class templates
that haven't been instantiated yet, ABSTRACT_CLASS_TYPE_P for them is false
until it is instantiated, which is done when the routine later constructs
a dummy object with that type.

The following patch fixes this by calling complete_type first, so that
ABSTRACT_CLASS_TYPE_P test will work properly, while keeping the handling
of arrays with unknown bounds, or incomplete types where it is done
currently.

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


OK.


2021-09-14  Jakub Jelinek  

PR c++/102305
* method.c (is_xible_helper): Call complete_type on to.

* g++.dg/cpp0x/pr102305.C: New test.

--- gcc/cp/method.c.jj  2021-08-12 09:34:16.465241411 +0200
+++ gcc/cp/method.c 2021-09-13 12:29:05.398000237 +0200
@@ -2081,6 +2081,7 @@ constructible_expr (tree to, tree from)
  static tree
  is_xible_helper (enum tree_code code, tree to, tree from, bool trivial)
  {
+  to = complete_type (to);
deferring_access_check_sentinel acs (dk_no_deferred);
if (VOID_TYPE_P (to) || ABSTRACT_CLASS_TYPE_P (to)
|| (from && FUNC_OR_METHOD_TYPE_P (from)
--- gcc/testsuite/g++.dg/cpp0x/pr102305.C.jj2021-09-13 12:46:47.580332966 
+0200
+++ gcc/testsuite/g++.dg/cpp0x/pr102305.C   2021-09-13 12:49:00.072503394 
+0200
@@ -0,0 +1,39 @@
+// PR c++/102305
+// { dg-do compile { target c++11 } }
+
+namespace std
+{
+  template
+struct integral_constant
+{
+  static constexpr _Tp value = __v;
+  typedef integral_constant<_Tp, __v> type;
+};
+
+  template
+constexpr _Tp integral_constant<_Tp, __v>::value;
+
+  typedef integral_constant true_type;
+  typedef integral_constant false_type;
+
+  template
+using bool_constant = integral_constant;
+
+  template
+struct is_constructible
+: public bool_constant<__is_constructible(_Tp, _Args...)>
+{
+};
+}
+
+template
+struct A {
+  virtual ~A() = 0;
+};
+
+struct B {
+  virtual ~B() = 0;
+};
+
+static_assert(!std::is_constructible >::value, "");
+static_assert(!std::is_constructible::value, "");

Jakub

Re: [PATCH, Fortran] Revert to non-multilib-specific ISO_Fortran_binding.h

[Gerald Pfeifer]

On Mon, 13 Sep 2021, Tobias Burnus wrote:
> Can you run 'echo | cpp -E -g3|grep DBL' to (or in the build dir: echo |
> ./gcc/cc1 -E -g3 -dD|grep DBL) to check what's the output?

Thank you, Tobias, and I'm just testing the proposed patch, but still
wanted to follow up on your question:

  % echo | ./gcc/cc1 -E -g3 -dD | grep DBL
  #define __DBL_MANT_DIG__ 53
  #define __DBL_DIG__ 15
  #define __DBL_MIN_EXP__ (-1021)
  #define __DBL_MIN_10_EXP__ (-307)
  #define __DBL_MAX_EXP__ 1024
  #define __DBL_MAX_10_EXP__ 308
  #define __DBL_DECIMAL_DIG__ 17
  #define __DBL_MAX__ ((double)1.79769313486231570814527423731704357e+308L)
  #define __DBL_NORM_MAX__ ((double)1.79769313486231570814527423731704357e+308L)
  #define __DBL_MIN__ ((double)2.22507385850720138309023271733240406e-308L)
  #define __DBL_EPSILON__ ((double)2.22044604925031308084726333618164062e-16L)
  #define __DBL_DENORM_MIN__ 
((double)4.94065645841246544176568792868221372e-324L)
  #define __DBL_HAS_DENORM__ 1
  #define __DBL_HAS_INFINITY__ 1
  #define __DBL_HAS_QUIET_NAN__ 1
  #define __DBL_IS_IEC_60559__ 2
  #define __LDBL_MANT_DIG__ 53
  #define __LDBL_DIG__ 15
  #define __LDBL_MIN_EXP__ (-16381)
  #define __LDBL_MIN_10_EXP__ (-4931)
  #define __LDBL_MAX_EXP__ 16384
  #define __LDBL_MAX_10_EXP__ 4932
  #define __LDBL_DECIMAL_DIG__ 17
  #define __LDBL_MAX__ 1.18973149535723163299902939989638351e+4932L
  #define __LDBL_NORM_MAX__ 1.18973149535723163299902939989638351e+4932L
  #define __LDBL_MIN__ 3.36210314311209350626267781732175260e-4932L
  #define __LDBL_EPSILON__ 2.22044604925031308084726333618164062e-16L
  #define __LDBL_DENORM_MIN__ 7.46536864129530798597817535205257178e-4948L
  #define __LDBL_HAS_DENORM__ 1
  #define __LDBL_HAS_INFINITY__ 1
  #define __LDBL_HAS_QUIET_NAN__ 1
  #define __LDBL_IS_IEC_60559__ 2

Gerald

Re: [PATCH] c++: Update DECL_*SIZE for objects with flexible array members with initializers [PR102295]

[Jason Merrill via Gcc-patches]

On 9/14/21 5:02 AM, Jakub Jelinek wrote:

Hi!

The C FE updates DECL_*SIZE for vars which have initializers for flexible
array members for many years, but C++ FE kept DECL_*SIZE the same as the
type size (i.e. as if there were zero elements in the flexible array
member).  This results e.g. in ELF symbol sizes being too small.

The following patch fixes that, bootstrapped/regtested on x86_64-linux and
i686-linux, ok for trunk?


OK.


Note, if the flexible array member is initialized only with non-constant
initializers, we have a worse bug that this patch doesn't solve, the
splitting of initializers into constant and dynamic initialization removes
the initializer and we don't have just wrong DECL_*SIZE, but nothing is
emitted when emitting those vars into assembly either and so the dynamic
initialization clobbers other vars that may overlap the variable.
I think we need keep an empty CONSTRUCTOR elt in DECL_INITIAL for the
flexible array member in that case.


Makes sense.


2021-09-14  Jakub Jelinek  

PR c++/102295
* decl.c (layout_var_decl): For aggregates ending with a flexible
array member, add the size of the initializer for that member to
DECL_SIZE and DECL_SIZE_UNIT.

* g++.target/i386/pr102295.C: New test.

--- gcc/cp/decl.c.jj2021-09-09 10:40:26.063176136 +0200
+++ gcc/cp/decl.c   2021-09-13 18:23:01.131587057 +0200
@@ -6091,6 +6091,38 @@ layout_var_decl (tree decl)
  error_at (DECL_SOURCE_LOCATION (decl),
"storage size of %qD isn%'t constant", decl);
  TREE_TYPE (decl) = error_mark_node;
+ type = error_mark_node;
+   }
+}
+
+  /* If the final element initializes a flexible array field, add the size of
+ that initializer to DECL's size.  */
+  if (type != error_mark_node
+  && DECL_INITIAL (decl)
+  && TREE_CODE (DECL_INITIAL (decl)) == CONSTRUCTOR
+  && !vec_safe_is_empty (CONSTRUCTOR_ELTS (DECL_INITIAL (decl)))
+  && DECL_SIZE (decl) != NULL_TREE
+  && TREE_CODE (DECL_SIZE (decl)) == INTEGER_CST
+  && TYPE_SIZE (type) != NULL_TREE
+  && TREE_CODE (TYPE_SIZE (type)) == INTEGER_CST
+  && tree_int_cst_equal (DECL_SIZE (decl), TYPE_SIZE (type)))
+{
+  constructor_elt  = CONSTRUCTOR_ELTS (DECL_INITIAL (decl))->last ();
+  if (elt.index)
+   {
+ tree itype = TREE_TYPE (elt.index);
+ tree vtype = TREE_TYPE (elt.value);
+ if (TREE_CODE (itype) == ARRAY_TYPE
+ && TYPE_DOMAIN (itype) == NULL
+ && TREE_CODE (vtype) == ARRAY_TYPE
+ && COMPLETE_TYPE_P (vtype))
+   {
+ DECL_SIZE (decl)
+   = size_binop (PLUS_EXPR, DECL_SIZE (decl), TYPE_SIZE (vtype));
+ DECL_SIZE_UNIT (decl)
+   = size_binop (PLUS_EXPR, DECL_SIZE_UNIT (decl),
+ TYPE_SIZE_UNIT (vtype));
+   }
}
  }
  }
--- gcc/testsuite/g++.target/i386/pr102295.C.jj 2021-09-13 18:28:08.406370163 
+0200
+++ gcc/testsuite/g++.target/i386/pr102295.C2021-09-13 18:28:26.846117106 
+0200
@@ -0,0 +1,12 @@
+// PR c++/102295
+// { dg-do compile { target *-*-linux* } }
+// { dg-options "-Wno-pedantic" }
+
+struct S {
+  int a;
+  int b[];
+} S;
+
+struct S s = { 1, { 2, 3 } };
+
+/* { dg-final { scan-assembler ".size\[\t \]*s, 12" } } */

Jakub

Re: Regression with recent change

[Michael Matz via Gcc-patches]

Hello,

On Mon, 13 Sep 2021, Aldy Hernandez via Gcc-patches wrote:

The testcase still tests what it's supposed to test with ...

> > typedef unsigned short uint16_t;
> >
> > uint16_t a, b;
> >
> > int *j_global;
> > uint16_t f(void)
> > {
> >int c, **p;
> >short d = 2, e = 4;
> >

... "c = a;" added here (i.e. it still hangs before the pr55107 change).

> >for (;; b++)
> >  {
> >int *j = j_global, k = 0;
> >
> >for (; *j; j++)
> >   {
> > for(; c; c++)
> >   for(; k < 1; k++)
> > {
> >   short *f = 
> >
> >   if(b)
> > return *f;
> > }
> >   }
> >
> >if(!c)
> >   d *= e;
> >
> >a = d;
> >if ((a ? b = 0 : (**p ? : 1) != (d != 1 ? 1 : (b = 0))) != ((k ? a
> : 0)
> > < (a * (c = k
> >   **p = 0;
> >  }
> > }
> >
> 
> Thanks for getting rid of the noise here.
> 
> I've simplified the above to show what's going on in the warning on
> nds32-elf:
> 
> int george, *global;
> int stuff(), readme();
> 
> int
> f (void)
> {
>int store;
> 
>for (;;)
>  {
>int k = 0;
> 
>while (global)
> {
>   for (; store; ++store)

Yeah, that seems a correct warning, your 'store' (the 'c' in the original 
testcase) is really used uninitialized (when 'global' aka '*j_global' is 
non-zero).  Sorry for not noticing earlier, I was only getting rid of 
warnings, not carefully looking at the testcase itself.  I think with 
above initialization of 'c' it's conforming, and still a correct test for 
the original bug.

> This looks like a latent bug.  For that matter, the above snippet warns 
> with -fdisable-tree-thread2, even on x86-64 (and before my patch).


Ciao,
Michael.

Re: [PATCH v2] libgcc: Add a backchain fallback to _Unwind_Backtrace() on PowerPC

[Raphael M Zinsly via Gcc-patches]

Ping

On 26/08/2021 11:53, Raphael Moreira Zinsly wrote:

Without dwarf2 unwind tables available _Unwind_Backtrace() is not
able to return the full backtrace.
This patch adds a fallback function on powerpc to get the backtrace
by doing a backchain, this code was originally at glibc.

libgcc/ChangeLog:

* config/rs6000/linux-unwind.h (struct rt_sigframe): Move it to
outside of get_regs() in order to use it in another function,
this is done twice: for __powerpc64__ and for !__powerpc64__.
(struct trace_arg): New struct.
(struct layout): New struct.
(ppc_backchain_fallback): New function.
* unwind.inc (_Unwind_Backtrace): Look for _URC_NORMAL_STOP
code state and call MD_BACKCHAIN_FALLBACK.

gcc/testsuite/ChangeLog:

* gcc.target/powerpc/unwind-backchain.c: New test.
---
  .../gcc.target/powerpc/unwind-backchain.c |  22 
  libgcc/config/rs6000/linux-unwind.h   | 102 +++---
  libgcc/unwind.inc |  14 ++-
  3 files changed, 122 insertions(+), 16 deletions(-)
  create mode 100644 gcc/testsuite/gcc.target/powerpc/unwind-backchain.c

diff --git a/gcc/testsuite/gcc.target/powerpc/unwind-backchain.c 
b/gcc/testsuite/gcc.target/powerpc/unwind-backchain.c
new file mode 100644
index 000..fdce78a1f63
--- /dev/null
+++ b/gcc/testsuite/gcc.target/powerpc/unwind-backchain.c
@@ -0,0 +1,22 @@
+/* { dg-do run { target { powerpc*-*-linux* } } } */
+/* { dg-options "-fno-asynchronous-unwind-tables" } */
+
+#include 
+
+void
+test_backtrace()
+{
+  int addresses;
+  void *buffer[10];
+
+  addresses = backtrace(buffer, 10);
+  if(addresses != 4)
+__builtin_abort();
+}
+
+int
+main()
+{
+  test_backtrace();
+  return 0;
+}
diff --git a/libgcc/config/rs6000/linux-unwind.h 
b/libgcc/config/rs6000/linux-unwind.h
index acdc948f85d..8deccc1d650 100644
--- a/libgcc/config/rs6000/linux-unwind.h
+++ b/libgcc/config/rs6000/linux-unwind.h
@@ -94,6 +94,15 @@ struct gcc_ucontext
  
  enum { SIGNAL_FRAMESIZE = 128 };
  
+struct rt_sigframe {

+  char gap[SIGNAL_FRAMESIZE];
+  struct gcc_ucontext uc;
+  unsigned long pad[2];
+  int tramp[6];
+  void *pinfo;
+  struct gcc_ucontext *puc;
+};
+
  /* If PC is at a sigreturn trampoline, return a pointer to the
 regs.  Otherwise return NULL.  */
  
@@ -136,14 +145,7 @@ get_regs (struct _Unwind_Context *context)

  #endif
{
  /* This works for 2.4.21 and later kernels.  */
- struct rt_sigframe {
-   char gap[SIGNAL_FRAMESIZE];
-   struct gcc_ucontext uc;
-   unsigned long pad[2];
-   int tramp[6];
-   void *pinfo;
-   struct gcc_ucontext *puc;
- } *frame = (struct rt_sigframe *) context->cfa;
+ struct rt_sigframe *frame = (struct rt_sigframe *) context->cfa;
  return frame->uc.regs;
}
  }
@@ -154,6 +156,12 @@ get_regs (struct _Unwind_Context *context)
  
  enum { SIGNAL_FRAMESIZE = 64 };
  
+struct rt_sigframe {

+  char gap[SIGNAL_FRAMESIZE + 16];
+  char siginfo[128];
+  struct gcc_ucontext uc;
+};
+
  static struct gcc_regs *
  get_regs (struct _Unwind_Context *context)
  {
@@ -176,11 +184,7 @@ get_regs (struct _Unwind_Context *context)
  }
else if (pc[0] == 0x3800 || pc[0] == 0x38AC)
  {
-  struct rt_sigframe {
-   char gap[SIGNAL_FRAMESIZE + 16];
-   char siginfo[128];
-   struct gcc_ucontext uc;
-  } *frame = (struct rt_sigframe *) context->cfa;
+  struct rt_sigframe *frame = (struct rt_sigframe *) context->cfa;
return frame->uc.regs;
  }
return NULL;
@@ -203,7 +207,7 @@ ppc_fallback_frame_state (struct _Unwind_Context *context,
int i;
  
if (regs == NULL)

-return _URC_END_OF_STACK;
+return _URC_NORMAL_STOP;
  
new_cfa = regs->gpr[__LIBGCC_STACK_POINTER_REGNUM__];

fs->regs.cfa_how = CFA_REG_OFFSET;
@@ -352,3 +356,73 @@ frob_update_context (struct _Unwind_Context *context, 
_Unwind_FrameState *fs ATT
  }
  #endif
  }
+
+#define MD_BACKCHAIN_FALLBACK ppc_backchain_fallback
+
+struct trace_arg
+{
+  /* Stores the list of addresses.  */
+  void **array;
+  struct unwind_link *unwind_link;
+  _Unwind_Word cfa;
+  /* Number of addresses currently stored.  */
+  int count;
+  /* Maximum number of addresses.  */
+  int size;
+};
+
+/* This is the stack layout we see with every stack frame.
+   Note that every routine is required by the ABI to lay out the stack
+   like this.
+
+   +++-+
+%r1  -> | previous frame> | previous frame--->...  --> NULL
+   ||| |
+   | cr save|| cr save |
+   ||| |
+   | (unused)   || lr save |
+   +++-+
+
+  The CR save is only present on 64-bit ABIs.
+*/
+struct frame_layout
+{
+  

[committed] Fortran: Add missing ST_OMP_END_SCOPE handling [PR102313]

[Tobias Burnus]

Committed as obvious as r12-3524.

I have also re-checked openmp.c omp_code_to_statement (seems to be
complete, 'omp declare...' + 'omp requires' missing but it is
probably fine that those are absent).

And I checked gfc_ascii_statement – missing are some internally
used ones (like ST_SIMPLE_IF), which are probably never reachable.

Thus, it seems as if G. Steinmetz managed to find the only missing one.

I have created a testcase with all missing ST_OMP_END_* and ST_OACC_END_*;
I am not quite sure why a different code path is triggered for some, but
at least here is now a parse check for all.

Tobias

-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
commit 33fdbbe4ce6055eb858096d01720ccf94aa854ec
Author: Tobias Burnus 
Date:   Tue Sep 14 14:17:35 2021 +0200

Fortran: Add missing ST_OMP_END_SCOPE handling [PR102313]

PR fortran/102313

gcc/fortran/ChangeLog:

* parse.c (gfc_ascii_statement): Add missing ST_OMP_END_SCOPE.

gcc/testsuite/ChangeLog:

* gfortran.dg/goacc/unexpected-end.f90: New test.
* gfortran.dg/gomp/unexpected-end.f90: New test.
---
 gcc/fortran/parse.c|   3 +
 gcc/testsuite/gfortran.dg/goacc/unexpected-end.f90 |  23 
 gcc/testsuite/gfortran.dg/gomp/unexpected-end.f90  | 123 +
 3 files changed, 149 insertions(+)

diff --git a/gcc/fortran/parse.c b/gcc/fortran/parse.c
index d37a0b5a697..7d765a0866d 100644
--- a/gcc/fortran/parse.c
+++ b/gcc/fortran/parse.c
@@ -2406,6 +2406,9 @@ gfc_ascii_statement (gfc_statement st)
 case ST_OMP_END_DO_SIMD:
   p = "!$OMP END DO SIMD";
   break;
+case ST_OMP_END_SCOPE:
+  p = "!$OMP END SCOPE";
+  break;
 case ST_OMP_END_SIMD:
   p = "!$OMP END SIMD";
   break;
diff --git a/gcc/testsuite/gfortran.dg/goacc/unexpected-end.f90 b/gcc/testsuite/gfortran.dg/goacc/unexpected-end.f90
new file mode 100644
index 000..442724fea83
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/goacc/unexpected-end.f90
@@ -0,0 +1,23 @@
+! PR fortran/102313
+
+!$acc end ATOMIC  ! { dg-error "Unexpected !.ACC END ATOMIC" }
+
+!$acc end DATA  ! { dg-error "Unexpected !.ACC END DATA" }
+
+!$acc end HOST DATA  ! { dg-error "Unclassifiable OpenACC directive" }
+
+!$acc end KERNELS  ! { dg-error "Unexpected !.ACC END KERNELS" }
+
+!$acc end KERNELS LOOP  ! { dg-error "Unexpected !.ACC END KERNELS LOOP" }
+
+!$acc end LOOP  ! { dg-error "Unexpected !.ACC END LOOP" }
+
+!$acc end PARALLEL  ! { dg-error "Unexpected !.ACC END PARALLEL" }
+
+!$acc end PARALLEL LOOP  ! { dg-error "Unexpected !.ACC END PARALLEL LOOP" }
+
+!$acc end SERIAL  ! { dg-error "Unexpected !.ACC END SERIAL" }
+
+!$acc end SERIAL LOOP  ! { dg-error "Unexpected !.ACC END SERIAL LOOP" }
+
+end
diff --git a/gcc/testsuite/gfortran.dg/gomp/unexpected-end.f90 b/gcc/testsuite/gfortran.dg/gomp/unexpected-end.f90
new file mode 100644
index 000..d2e8daa3fde
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/gomp/unexpected-end.f90
@@ -0,0 +1,123 @@
+! PR fortran/102313
+
+!$omp end ATOMIC  ! { dg-error "Unexpected !.OMP END ATOMIC" }
+
+!$omp end CRITICAL  ! { dg-error "Unexpected !.OMP END CRITICAL" }
+
+!$omp end DISTRIBUTE  ! { dg-error "Unexpected !.OMP END DISTRIBUTE" }
+
+!$omp end DISTRIBUTE PARALLEL DO  ! { dg-error "Unexpected !.OMP END DISTRIBUTE PARALLEL DO" }
+
+!$omp end DISTRIBUTE PARALLEL DO SIMD  ! { dg-error "Unexpected !.OMP END DISTRIBUTE PARALLEL DO SIMD" }
+
+!$omp end DISTRIBUTE SIMD  ! { dg-error "Unexpected !.OMP END DISTRIBUTE SIMD" }
+
+!$omp end DO  ! { dg-error "Unexpected !.OMP END DO" }
+
+!$omp end DO SIMD  ! { dg-error "Unexpected !.OMP END DO SIMD" }
+
+!$omp end LOOP  ! { dg-error "Unclassifiable OpenMP directive" }
+
+!$omp parallel loop
+do i = 1, 5
+end do
+!$omp end LOOP  ! { dg-error "Unclassifiable OpenMP directive" }
+
+!$omp end MASKED  ! { dg-error "Unexpected !.OMP END MASKED" }
+
+!$omp end MASKED TASKLOOP  ! { dg-error "Unexpected !.OMP END MASKED TASKLOOP" }
+
+!$omp end MASKED TASKLOOP SIMD  ! { dg-error "Unexpected !.OMP END MASKED TASKLOOP SIMD" }
+
+!$omp end MASTER  ! { dg-error "Unexpected !.OMP END MASTER" }
+
+!$omp end MASTER TASKLOOP  ! { dg-error "Unexpected !.OMP END MASTER TASKLOOP" }
+
+!$omp end MASTER TASKLOOP SIMD  ! { dg-error "Unexpected !.OMP END MASTER TASKLOOP SIMD" }
+
+!$omp end ORDERED  ! { dg-error "Unexpected !.OMP END ORDERED" }
+
+!$omp end PARALLEL  ! { dg-error "Unexpected !.OMP END PARALLEL" }
+
+!$omp end PARALLEL DO  ! { dg-error "Unexpected !.OMP END PARALLEL DO" }
+
+!$omp end PARALLEL DO SIMD  ! { dg-error "Unexpected !.OMP END PARALLEL DO SIMD" }
+
+!$omp loop
+!$omp end PARALLEL LOOP  ! { dg-error "Unexpected junk" }
+
+!$omp end PARALLEL MASKED  ! { dg-error 

Re: [PATCH] Maintain (mis-)alignment info in the first element of a group

[Richard Sandiford via Gcc-patches]

Richard Biener via Gcc-patches  writes:
> This changes us to maintain and compute (mis-)alignment info for
> the first element of a group only rather than for each DR when
> doing interleaving and for the earliest, first, or first in the SLP
> node (or any pair or all three of those) when SLP vectorizing.
>
> For this to work out the easiest way I have changed the accessors
> DR_MISALIGNMENT and DR_TARGET_ALIGNMENT to do the indirection to
> the first element rather than adjusting all callers.
> dr_misalignment is moved out-of-line and I'm not too fond of the
> poly-int dances there (any hints?), but basically we are now
> adjusting the first elements misalignment based on the DR_INIT
> difference.
>
> Bootstrap & regtest running on x86_64-unknown-linux-gnu.
>
> Richard.
>
> 2021-09-13  Richard Biener  
>
>   * tree-vectorizer.h (dr_misalignment): Move out of line.
>   (dr_target_alignment): New.
>   (DR_TARGET_ALIGNMENT): Wrap dr_target_alignment.
>   (set_dr_target_alignment): New.
>   (SET_DR_TARGET_ALIGNMENT): Wrap set_dr_target_alignment.
>   * tree-vect-data-refs.c (dr_misalignment): Compute and
>   return the group members misalignment.
>   (vect_compute_data_ref_alignment): Use SET_DR_TARGET_ALIGNMENT.
>   (vect_analyze_data_refs_alignment): Compute alignment only
>   for the first element of a DR group.
>   (vect_slp_analyze_node_alignment): Likewise.
> ---
>  gcc/tree-vect-data-refs.c | 65 ---
>  gcc/tree-vectorizer.h | 24 ++-
>  2 files changed, 57 insertions(+), 32 deletions(-)
>
> diff --git a/gcc/tree-vect-data-refs.c b/gcc/tree-vect-data-refs.c
> index 66e76132d14..b53d6a0b3f1 100644
> --- a/gcc/tree-vect-data-refs.c
> +++ b/gcc/tree-vect-data-refs.c
> @@ -887,6 +887,36 @@ vect_slp_analyze_instance_dependence (vec_info *vinfo, 
> slp_instance instance)
>return res;
>  }
>  
> +/* Return the misalignment of DR_INFO.  */
> +
> +int
> +dr_misalignment (dr_vec_info *dr_info)
> +{
> +  if (STMT_VINFO_GROUPED_ACCESS (dr_info->stmt))
> +{
> +  dr_vec_info *first_dr
> + = STMT_VINFO_DR_INFO (DR_GROUP_FIRST_ELEMENT (dr_info->stmt));
> +  int misalign = first_dr->misalignment;
> +  gcc_assert (misalign != DR_MISALIGNMENT_UNINITIALIZED);
> +  if (misalign == DR_MISALIGNMENT_UNKNOWN)
> + return misalign;
> +  poly_offset_int diff = (wi::to_poly_offset (DR_INIT (dr_info->dr))
> +   - wi::to_poly_offset (DR_INIT (first_dr->dr)));
> +  poly_int64 mispoly = misalign + diff.to_constant ().to_shwi ();
> +  bool res = known_misalignment (mispoly,
> +  first_dr->target_alignment.to_constant (),
> +  );
> +  gcc_assert (res);
> +  return misalign;

Yeah, not too keen on the to_constants here.  The one on diff looks
redundant -- you could just use diff.force_shwi () instead, and
keep everything poly_int.

For the known_misalignment I think we should use:

   if (!can_div_trunc_p (mispoly, first_dr->target_alignment,
 , ))
 misalign = DR_MISALIGNMENT_UNKNOWN;
   return misalign;

There are then no to_constant assumptions.

Thanks,
Richard

[PATCH][PUSHED] testsuite: fix failing pytest tests

[Martin Liška]

Pushed as obvious.

Martin

gcc/testsuite/ChangeLog:

* g++.dg/gcov/gcov.py: Fix failing pytests as gcov.json.gz
  filename was changed in b777f228b481ae881a7fbb09de367a053740932c.
---
 gcc/testsuite/g++.dg/gcov/gcov.py | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/gcc/testsuite/g++.dg/gcov/gcov.py 
b/gcc/testsuite/g++.dg/gcov/gcov.py
index a8c4ea9ae71..5137f3a6872 100644
--- a/gcc/testsuite/g++.dg/gcov/gcov.py
+++ b/gcc/testsuite/g++.dg/gcov/gcov.py
@@ -5,6 +5,9 @@ import os
 
 def gcov_from_env():

 # return parsed JSON content a GCOV_PATH file
-json_filename = os.environ['GCOV_PATH'] + '.gcov.json.gz'
+json_filename = os.environ['GCOV_PATH']
+# strip extension
+json_filename = json_filename[:json_filename.rindex('.')]
+json_filename += '.gcov.json.gz'
 json_data = gzip.open(json_filename).read()
 return json.loads(json_data)
--
2.33.0

[Ada] Fix PR ada/101970

[Eric Botcazou]

This is a regression present on the mainline and 11 branch in the form of an 
ICE for an enumeration type with a full signed representation for its size.

Tested on x86-64/Linux, applied on the mainline and 11 branch.


2021-09-14  Eric Botcazou  

PR ada/101970
* exp_attr.adb (Expand_N_Attribute_Reference) :
Use an unchecked conversion instead of a regular conversion in the
enumeration case and remove Conversion_OK flag in the integer case.
: Remove superfluous test.


2021-09-14  Eric Botcazou  

* gnat.dg/enum_rep2.adb: New test.

-- 
Eric Botcazoudiff --git a/gcc/ada/exp_attr.adb b/gcc/ada/exp_attr.adb
index f074521e5f7..fc6b0ef8097 100644
--- a/gcc/ada/exp_attr.adb
+++ b/gcc/ada/exp_attr.adb
@@ -3252,14 +3252,15 @@ package body Exp_Attr is
  --  If not constant-folded, Enum_Type'Enum_Rep (X) or X'Enum_Rep
  --  expands to
 
- --target-type (X)
+ --target-type!(X)
 
- --  This is simply a direct conversion from the enumeration type to
- --  the target integer type, which is treated by the back end as a
- --  normal integer conversion, treating the enumeration type as an
- --  integer, which is exactly what we want. We set Conversion_OK to
- --  make sure that the analyzer does not complain about what otherwise
- --  might be an illegal conversion.
+ --  This is an unchecked conversion from the enumeration type to the
+ --  target integer type, which is treated by the back end as a normal
+ --  integer conversion, treating the enumeration type as an integer,
+ --  which is exactly what we want. Unlike for the Pos attribute, we
+ --  cannot use a regular conversion since the associated check would
+ --  involve comparing the converted bounds, i.e. would involve the use
+ --  of 'Pos instead 'Enum_Rep for these bounds.
 
  --  However the target type is universal integer in most cases, which
  --  is a very large type, so in the case of an enumeration type, we
@@ -3267,11 +3268,13 @@ package body Exp_Attr is
  --  the size information.
 
  if Is_Enumeration_Type (Ptyp) then
-Rewrite (N, OK_Convert_To (Get_Integer_Type (Ptyp), Expr));
+Rewrite (N, Unchecked_Convert_To (Get_Integer_Type (Ptyp), Expr));
 Convert_To_And_Rewrite (Typ, N);
 
+ --  Deal with integer types (replace by conversion)
+
  else
-Rewrite (N, OK_Convert_To (Typ, Expr));
+Rewrite (N, Convert_To (Typ, Expr));
  end if;
 
  Analyze_And_Resolve (N, Typ);
@@ -5420,7 +5423,7 @@ package body Exp_Attr is
 
  --  Deal with integer types (replace by conversion)
 
- elsif Is_Integer_Type (Etyp) then
+ else
 Rewrite (N, Convert_To (Typ, Expr));
  end if;
 
--  { dg-do compile }

with Ada.Integer_Text_IO;
with Ada.Text_IO;

procedure Enum_Rep2 is

   type T is
 (E80, E81, E82, E83, E84, E85, E86, E87, E88, E89, E8A, E8B, E8C, E8D, E8E, E8F,
  E90, E91, E92, E93, E94, E95, E96, E97, E98, E99, E9A, E9B, E9C, E9D, E9E, E9F,
  EA0, EA1, EA2, EA3, EA4, EA5, EA6, EA7, EA8, EA9, EAA, EAB, EAC, EAD, EAE, EAF,
  EB0, EB1, EB2, EB3, EB4, EB5, EB6, EB7, EB8, EB9, EBA, EBB, EBC, EBD, EBE, EBF,
  EC0, EC1, EC2, EC3, EC4, EC5, EC6, EC7, EC8, EC9, ECA, ECB, ECC, ECD, ECE, ECF,
  ED0, ED1, ED2, ED3, ED4, ED5, ED6, ED7, ED8, ED9, EDA, EDB, EDC, EDD, EDE, EDF,
  EE0, EE1, EE2, EE3, EE4, EE5, EE6, EE7, EE8, EE9, EEA, EEB, EEC, EED, EEE, EEF,
  EF0, EF1, EF2, EF3, EF4, EF5, EF6, EF7, EF8, EF9, EFA, EFB, EFC, EFD, EFE, EFF,
  E00, E01, E02, E03, E04, E05, E06, E07, E08, E09, E0A, E0B, E0C, E0D, E0E, E0F,
  E10, E11, E12, E13, E14, E15, E16, E17, E18, E19, E1A, E1B, E1C, E1D, E1E, E1F,
  E20, E21, E22, E23, E24, E25, E26, E27, E28, E29, E2A, E2B, E2C, E2D, E2E, E2F,
  E30, E31, E32, E33, E34, E35, E36, E37, E38, E39, E3A, E3B, E3C, E3D, E3E, E3F,
  E40, E41, E42, E43, E44, E45, E46, E47, E48, E49, E4A, E4B, E4C, E4D, E4E, E4F,
  E50, E51, E52, E53, E54, E55, E56, E57, E58, E59, E5A, E5B, E5C, E5D, E5E, E5F,
  E60, E61, E62, E63, E64, E65, E66, E67, E68, E69, E6A, E6B, E6C, E6D, E6E, E6F,
  E70, E71, E72, E73, E74, E75, E76, E77, E78, E79, E7A, E7B, E7C, E7D, E7E, E7F);
   for T use
 (E80 => -16#80#, E81 => -16#7F#, E82 => -16#7E#, E83 => -16#7D#,
  E84 => -16#7C#, E85 => -16#7B#, E86 => -16#7A#, E87 => -16#79#,
  E88 => -16#78#, E89 => -16#77#, E8A => -16#76#, E8B => -16#75#,
  E8C => -16#74#, E8D => -16#73#, E8E => -16#72#, E8F => -16#71#,
  
  E90 => -16#70#, E91 => -16#6F#, E92 => -16#6E#, E93 => -16#6D#,
  E94 => -16#6C#, E95 => -16#6B#, E96 => -16#6A#, E97 => -16#69#,
  E98 => -16#68#, E99 => -16#67#, E9A => -16#66#, E9B => -16#65#,
  E9C => -16#64#, E9D => -16#63#, E9E => -16#62#, E9F => -16#61#,
  
   

[committed] arc: Update ZOL pattern.

[Claudiu Zissulescu via Gcc-patches]

The ZOL pattern is missing modes which may lead to errors during
var_tracking. Add them.

gcc/
-xx-xx  Claudiu Zissulescu  

* config/arc/arc.md (doloop_end): Add missing mode.
(loop_end): Likewise.

Signed-off-by: Claudiu Zissulescu 
---
 gcc/config/arc/arc.md | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/gcc/config/arc/arc.md b/gcc/config/arc/arc.md
index 90ba85e274e..4919d275820 100644
--- a/gcc/config/arc/arc.md
+++ b/gcc/config/arc/arc.md
@@ -4966,8 +4966,8 @@ (define_expand "doloop_end"
(const_int 1))
(label_ref (match_operand 1 "" ""))
(pc)))
- (set (match_dup 0) (plus (match_dup 0) (const_int -1)))
- (unspec [(const_int 0)] UNSPEC_ARC_LP)
+ (set (match_dup 0) (plus:SI (match_dup 0) (const_int -1)))
+ (unspec:SI [(const_int 0)] UNSPEC_ARC_LP)
  (clobber (match_dup 2))])]
   ""
 {
@@ -4996,8 +4996,8 @@ (define_insn_and_split "loop_end"
  (const_int 1))
  (label_ref (match_operand 1 "" ""))
  (pc)))
-   (set (match_dup 0) (plus (match_dup 0) (const_int -1)))
-   (unspec [(const_int 0)] UNSPEC_ARC_LP)
+   (set (match_dup 0) (plus:SI (match_dup 0) (const_int -1)))
+   (unspec:SI [(const_int 0)] UNSPEC_ARC_LP)
(clobber (match_scratch:SI 2 "=X,"))]
   ""
   "@
-- 
2.31.1

[Ada] Fix inaccurate bounds in debug info for vector array types

[Eric Botcazou]

They should not be 0-based, unless the array type itself is.

Tested on x86-64/Linux, applied on the mainline, 11 and 10 branches.


2021-09-14  Eric Botcazou  

* gcc-interface/decl.c (gnat_to_gnu_entity): For vector types, make
the representative array the debug type.

-- 
Eric Botcazoudiff --git a/decl.c b/decl.c
index f7394b60..ebb33c97 100644
--- a/decl.c
+++ b/decl.c
@@ -4744,6 +4744,14 @@ gnat_to_gnu_entity (Entity_Id gnat_entity, tree gnu_expr, bool definition)
   else
 	gnu_decl = create_type_decl (gnu_entity_name, gnu_type, artificial_p,
  debug_info_p, gnat_entity);
+
+  /* For vector types, make the representative array the debug type.  */
+  if (VECTOR_TYPE_P (gnu_type))
+	{
+	  tree rep = TYPE_REPRESENTATIVE_ARRAY (gnu_type);
+	  TYPE_NAME (rep) = DECL_NAME (gnu_decl);
+	  SET_TYPE_DEBUG_TYPE (gnu_type, rep);
+	}
 }
 
   /* Otherwise, for a type reusing an existing DECL, back-annotate values.  */

[PATCH] c++: Update DECL_*SIZE for objects with flexible array members with initializers [PR102295]

[Jakub Jelinek via Gcc-patches]

Hi!

The C FE updates DECL_*SIZE for vars which have initializers for flexible
array members for many years, but C++ FE kept DECL_*SIZE the same as the
type size (i.e. as if there were zero elements in the flexible array
member).  This results e.g. in ELF symbol sizes being too small.

The following patch fixes that, bootstrapped/regtested on x86_64-linux and
i686-linux, ok for trunk?

Note, if the flexible array member is initialized only with non-constant
initializers, we have a worse bug that this patch doesn't solve, the
splitting of initializers into constant and dynamic initialization removes
the initializer and we don't have just wrong DECL_*SIZE, but nothing is
emitted when emitting those vars into assembly either and so the dynamic
initialization clobbers other vars that may overlap the variable.
I think we need keep an empty CONSTRUCTOR elt in DECL_INITIAL for the
flexible array member in that case.

2021-09-14  Jakub Jelinek  

PR c++/102295
* decl.c (layout_var_decl): For aggregates ending with a flexible
array member, add the size of the initializer for that member to
DECL_SIZE and DECL_SIZE_UNIT.

* g++.target/i386/pr102295.C: New test.

--- gcc/cp/decl.c.jj2021-09-09 10:40:26.063176136 +0200
+++ gcc/cp/decl.c   2021-09-13 18:23:01.131587057 +0200
@@ -6091,6 +6091,38 @@ layout_var_decl (tree decl)
  error_at (DECL_SOURCE_LOCATION (decl),
"storage size of %qD isn%'t constant", decl);
  TREE_TYPE (decl) = error_mark_node;
+ type = error_mark_node;
+   }
+}
+
+  /* If the final element initializes a flexible array field, add the size of
+ that initializer to DECL's size.  */
+  if (type != error_mark_node
+  && DECL_INITIAL (decl)
+  && TREE_CODE (DECL_INITIAL (decl)) == CONSTRUCTOR
+  && !vec_safe_is_empty (CONSTRUCTOR_ELTS (DECL_INITIAL (decl)))
+  && DECL_SIZE (decl) != NULL_TREE
+  && TREE_CODE (DECL_SIZE (decl)) == INTEGER_CST
+  && TYPE_SIZE (type) != NULL_TREE
+  && TREE_CODE (TYPE_SIZE (type)) == INTEGER_CST
+  && tree_int_cst_equal (DECL_SIZE (decl), TYPE_SIZE (type)))
+{
+  constructor_elt  = CONSTRUCTOR_ELTS (DECL_INITIAL (decl))->last ();
+  if (elt.index)
+   {
+ tree itype = TREE_TYPE (elt.index);
+ tree vtype = TREE_TYPE (elt.value);
+ if (TREE_CODE (itype) == ARRAY_TYPE
+ && TYPE_DOMAIN (itype) == NULL
+ && TREE_CODE (vtype) == ARRAY_TYPE
+ && COMPLETE_TYPE_P (vtype))
+   {
+ DECL_SIZE (decl)
+   = size_binop (PLUS_EXPR, DECL_SIZE (decl), TYPE_SIZE (vtype));
+ DECL_SIZE_UNIT (decl)
+   = size_binop (PLUS_EXPR, DECL_SIZE_UNIT (decl),
+ TYPE_SIZE_UNIT (vtype));
+   }
}
 }
 }
--- gcc/testsuite/g++.target/i386/pr102295.C.jj 2021-09-13 18:28:08.406370163 
+0200
+++ gcc/testsuite/g++.target/i386/pr102295.C2021-09-13 18:28:26.846117106 
+0200
@@ -0,0 +1,12 @@
+// PR c++/102295
+// { dg-do compile { target *-*-linux* } }
+// { dg-options "-Wno-pedantic" }
+
+struct S {
+  int a;
+  int b[];
+} S;
+
+struct S s = { 1, { 2, 3 } };
+
+/* { dg-final { scan-assembler ".size\[\t \]*s, 12" } } */

Jakub

[Ada] Strengthen compatibility warning for GCC builtins

[Eric Botcazou]

This is necessary for vector builtins, which are picky about the signedness of 
the element type.

Tested on x86-64/Linux, applied on the mainline.


2021-09-14  Eric Botcazou  

* libgnat/s-atopri.ads (bool): Delete.
(Atomic_Test_And_Set): Replace bool with Boolean.
(Atomic_Always_Lock_Free): Likewise.
* libgnat/s-aoinar.adb (Is_Lock_Free): Adjust.
* libgnat/s-aomoar.adb (Is_Lock_Free): Likewise.
* libgnat/s-aotase.adb (Atomic_Test_And_Set): Likewise.
* libgnat/s-atopex.adb (Atomic_Compare_And_Exchange): Likewise.
* gcc-interface/decl.c: Include gimple-expr.h.
(intrin_types_incompatible_p): Delete.
(intrin_arglists_compatible_p): Call types_compatible_p.
(intrin_return_compatible_p): Likewise.

-- 
Eric Botcazoudiff --git a/gcc/ada/gcc-interface/decl.c b/gcc/ada/gcc-interface/decl.c
index d37ed3d1b52..38a8bda02ce 100644
--- a/gcc/ada/gcc-interface/decl.c
+++ b/gcc/ada/gcc-interface/decl.c
@@ -28,6 +28,7 @@
 #include "coretypes.h"
 #include "target.h"
 #include "tree.h"
+#include "gimple-expr.h"
 #include "stringpool.h"
 #include "diagnostic-core.h"
 #include "alias.h"
@@ -9492,46 +9493,6 @@ check_ok_for_atomic_type (tree type, Entity_Id gnat_entity, bool component_p)
 		   gnat_error_point, gnat_entity);
 }
 
-
-/* Helper for the intrin compatibility checks family.  Evaluate whether
-   two types are definitely incompatible.  */
-
-static bool
-intrin_types_incompatible_p (tree t1, tree t2)
-{
-  enum tree_code code;
-
-  if (TYPE_MAIN_VARIANT (t1) == TYPE_MAIN_VARIANT (t2))
-return false;
-
-  if (TYPE_MODE (t1) != TYPE_MODE (t2))
-return true;
-
-  if (TREE_CODE (t1) != TREE_CODE (t2))
-return true;
-
-  code = TREE_CODE (t1);
-
-  switch (code)
-{
-case INTEGER_TYPE:
-case REAL_TYPE:
-  return TYPE_PRECISION (t1) != TYPE_PRECISION (t2);
-
-case POINTER_TYPE:
-case REFERENCE_TYPE:
-  /* Assume designated types are ok.  We'd need to account for char * and
-	 void * variants to do better, which could rapidly get messy and isn't
-	 clearly worth the effort.  */
-  return false;
-
-default:
-  break;
-}
-
-  return false;
-}
-
 /* Helper for intrin_profiles_compatible_p, to perform compatibility checks
on the Ada/builtin argument lists for the INB binding.  */
 
@@ -9577,8 +9538,8 @@ intrin_arglists_compatible_p (intrin_binding_t * inb)
 	}
 
   /* Otherwise, check that types match for the current argument.  */
-  argpos ++;
-  if (intrin_types_incompatible_p (ada_type, btin_type))
+  argpos++;
+  if (!types_compatible_p (ada_type, btin_type))
 	{
 	  post_error_ne_num ("??intrinsic binding type mismatch on argument ^!",
 			 inb->gnat_entity, inb->gnat_entity, argpos);
@@ -9609,7 +9570,7 @@ intrin_return_compatible_p (intrin_binding_t * inb)
 
   /* Check return types compatibility otherwise.  Note that this
  handles void/void as well.  */
-  if (intrin_types_incompatible_p (btin_return_type, ada_return_type))
+  if (!types_compatible_p (btin_return_type, ada_return_type))
 {
   post_error ("??intrinsic binding type mismatch on return value!",
 		  inb->gnat_entity);
diff --git a/gcc/ada/libgnat/s-aoinar.adb b/gcc/ada/libgnat/s-aoinar.adb
index df12b16b9e5..2f430ed4efe 100644
--- a/gcc/ada/libgnat/s-aoinar.adb
+++ b/gcc/ada/libgnat/s-aoinar.adb
@@ -203,7 +203,7 @@ package body System.Atomic_Operations.Integer_Arithmetic is
   pragma Unreferenced (Item);
   use type Interfaces.C.size_t;
begin
-  return Boolean (Atomic_Always_Lock_Free (Atomic_Type'Object_Size / 8));
+  return Atomic_Always_Lock_Free (Atomic_Type'Object_Size / 8);
end Is_Lock_Free;
 
 end System.Atomic_Operations.Integer_Arithmetic;
diff --git a/gcc/ada/libgnat/s-aomoar.adb b/gcc/ada/libgnat/s-aomoar.adb
index c955623897d..a6f4b0e61e8 100644
--- a/gcc/ada/libgnat/s-aomoar.adb
+++ b/gcc/ada/libgnat/s-aomoar.adb
@@ -209,7 +209,7 @@ package body System.Atomic_Operations.Modular_Arithmetic is
   pragma Unreferenced (Item);
   use type Interfaces.C.size_t;
begin
-  return Boolean (Atomic_Always_Lock_Free (Atomic_Type'Object_Size / 8));
+  return Atomic_Always_Lock_Free (Atomic_Type'Object_Size / 8);
end Is_Lock_Free;
 
 end System.Atomic_Operations.Modular_Arithmetic;
diff --git a/gcc/ada/libgnat/s-aotase.adb b/gcc/ada/libgnat/s-aotase.adb
index 53178892621..94b28dfa410 100644
--- a/gcc/ada/libgnat/s-aotase.adb
+++ b/gcc/ada/libgnat/s-aotase.adb
@@ -40,7 +40,7 @@ package body System.Atomic_Operations.Test_And_Set is
function Atomic_Test_And_Set
  (Item : aliased in out Test_And_Set_Flag) return Boolean is
begin
-  return Boolean (Atomic_Test_And_Set (Item'Address));
+  return Atomic_Test_And_Set (Item'Address);
end Atomic_Test_And_Set;
 
--
diff --git a/gcc/ada/libgnat/s-atopex.adb b/gcc/ada/libgnat/s-atopex.adb
index 501254e4f5f..b0aa9e593d1 100644
--- 

Re: [r12-3495 Regression] FAIL: 29_atomics/atomic_flag/test_and_set/explicit-hle.cc (test for excess errors) on Linux/x86_64

[Andreas Schwab]

On Sep 14 2021, Jakub Jelinek via Gcc-patches wrote:

> On Mon, Sep 13, 2021 at 03:08:01PM -0700, sunil.k.pandey via Gcc-patches 
> wrote:
>> FAIL: 29_atomics/atomic_flag/test_and_set/explicit-hle.cc (test for excess 
>> errors)
>
> Apparently all C++ compilations with
> -m32 -march={i386,i486,i586,pentium,pentiumpro,lakemont,pentium4}
> FAIL with:
> : warning: ‘--param constructive-interference-size=64’ is greater 
> than ‘--param l1-cache-line-size=0’ [-Winterference-size]
> So, either the C++ FE should not warn if param_l1_cache_line_size is 0
> (treat it as a don't know value), or the backend shouldn't overwrite
> the default generic param value of 32 with 0 when 
> ix86_tune_cost->prefetch_block
> is 0.

I'm also seeing this error during bootstrap on aarch64:

: error: '--param constructive-interference-size=64' is greater than 
'--param l1-cache-line-size=32' [-Werror=interference-size]

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

[PATCH] c++: Fix __is_*constructible/assignable for templates [PR102305]

[Jakub Jelinek via Gcc-patches]

Hi!

is_xible_helper returns error_mark_node (i.e. false from the traits)
for abstract classes by testing ABSTRACT_CLASS_TYPE_P (to) early.
Unfortunately, as the testcase shows, that doesn't work on class templates
that haven't been instantiated yet, ABSTRACT_CLASS_TYPE_P for them is false
until it is instantiated, which is done when the routine later constructs
a dummy object with that type.

The following patch fixes this by calling complete_type first, so that
ABSTRACT_CLASS_TYPE_P test will work properly, while keeping the handling
of arrays with unknown bounds, or incomplete types where it is done
currently.

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

2021-09-14  Jakub Jelinek  

PR c++/102305
* method.c (is_xible_helper): Call complete_type on to.

* g++.dg/cpp0x/pr102305.C: New test.

--- gcc/cp/method.c.jj  2021-08-12 09:34:16.465241411 +0200
+++ gcc/cp/method.c 2021-09-13 12:29:05.398000237 +0200
@@ -2081,6 +2081,7 @@ constructible_expr (tree to, tree from)
 static tree
 is_xible_helper (enum tree_code code, tree to, tree from, bool trivial)
 {
+  to = complete_type (to);
   deferring_access_check_sentinel acs (dk_no_deferred);
   if (VOID_TYPE_P (to) || ABSTRACT_CLASS_TYPE_P (to)
   || (from && FUNC_OR_METHOD_TYPE_P (from)
--- gcc/testsuite/g++.dg/cpp0x/pr102305.C.jj2021-09-13 12:46:47.580332966 
+0200
+++ gcc/testsuite/g++.dg/cpp0x/pr102305.C   2021-09-13 12:49:00.072503394 
+0200
@@ -0,0 +1,39 @@
+// PR c++/102305
+// { dg-do compile { target c++11 } }
+
+namespace std
+{
+  template
+struct integral_constant
+{
+  static constexpr _Tp value = __v;
+  typedef integral_constant<_Tp, __v> type;
+};
+
+  template
+constexpr _Tp integral_constant<_Tp, __v>::value;
+
+  typedef integral_constant true_type;
+  typedef integral_constant false_type;
+
+  template
+using bool_constant = integral_constant;
+
+  template
+struct is_constructible
+: public bool_constant<__is_constructible(_Tp, _Args...)>
+{
+};
+}
+
+template
+struct A {
+  virtual ~A() = 0;
+};
+
+struct B {
+  virtual ~B() = 0;
+};
+
+static_assert(!std::is_constructible >::value, "");
+static_assert(!std::is_constructible::value, "");

Jakub

[committed] testsuite: Use sync_long_long instead of sync_int_long for atomic-29.c test

[Jakub Jelinek via Gcc-patches]

Hi!

As discussed, the test tests atomics on doubles which are 64-bit and so we
should use sync_long_long effective target instead of sync_int_long that
covers 64-bit atomics only on 64-bit arches.  I've added -march=pentium
to follow what is documented for sync_long_long, I guess -march=zarch should
be added for s390* too, but haven't tested that.

And using sync_long_long found a syntax error in that effective target
implementation, so I've fixed that too.

Regtested on x86_64-linux and i686-linux, committed to trunk.

2021-09-14  Jakub Jelinek  

* c-c++-common/gomp/atomic-29.c: Add -march=pentium
dg-additional-options for ia32.  Use sync_long_long effective target
instead of sync_int_long.
* lib/target-supports.exp (check_effective_target_sync_long_long): Fix
a syntax error.

--- gcc/testsuite/c-c++-common/gomp/atomic-29.c.jj  2021-09-11 
09:33:37.897331795 +0200
+++ gcc/testsuite/c-c++-common/gomp/atomic-29.c 2021-09-13 16:52:39.212099370 
+0200
@@ -1,10 +1,11 @@
 /* { dg-do compile { target c } } */
 /* { dg-additional-options "-O2 -fdump-tree-ompexp" } */
-/* { dg-final { scan-tree-dump-times "\.ATOMIC_COMPARE_EXCHANGE \\\(\[^\n\r]*, 
8, 5, 5\\\);" 1 "ompexp" { target sync_int_long } } } */
-/* { dg-final { scan-tree-dump-times "\.ATOMIC_COMPARE_EXCHANGE \\\(\[^\n\r]*, 
8, 4, 2\\\);" 1 "ompexp" { target sync_int_long } } } */
-/* { dg-final { scan-tree-dump-times "\.ATOMIC_COMPARE_EXCHANGE \\\(\[^\n\r]*, 
264, 5, 0\\\);" 1 "ompexp" { target sync_int_long } } } */
-/* { dg-final { scan-tree-dump-times "\.ATOMIC_COMPARE_EXCHANGE \\\(\[^\n\r]*, 
8, 0, 0\\\);" 1 "ompexp" { target sync_int_long } } } */
-/* { dg-final { scan-tree-dump-not "__atomic_load_8 \\\(" "ompexp" { target 
sync_int_long } } } */
+/* { dg-additional-options "-march=pentium" { target ia32 } } */
+/* { dg-final { scan-tree-dump-times "\.ATOMIC_COMPARE_EXCHANGE \\\(\[^\n\r]*, 
8, 5, 5\\\);" 1 "ompexp" { target sync_long_long } } } */
+/* { dg-final { scan-tree-dump-times "\.ATOMIC_COMPARE_EXCHANGE \\\(\[^\n\r]*, 
8, 4, 2\\\);" 1 "ompexp" { target sync_long_long } } } */
+/* { dg-final { scan-tree-dump-times "\.ATOMIC_COMPARE_EXCHANGE \\\(\[^\n\r]*, 
264, 5, 0\\\);" 1 "ompexp" { target sync_long_long } } } */
+/* { dg-final { scan-tree-dump-times "\.ATOMIC_COMPARE_EXCHANGE \\\(\[^\n\r]*, 
8, 0, 0\\\);" 1 "ompexp" { target sync_long_long } } } */
+/* { dg-final { scan-tree-dump-not "__atomic_load_8 \\\(" "ompexp" { target 
sync_long_long } } } */
 
 double x;
 
--- gcc/testsuite/lib/target-supports.exp.jj2021-09-08 11:23:44.380036173 
+0200
+++ gcc/testsuite/lib/target-supports.exp   2021-09-14 09:56:11.240510238 
+0200
@@ -8074,7 +8074,7 @@ proc check_effective_target_sync_int_128
 # Note: 32bit s390 targets require -mzarch in dg-options.
 
 proc check_effective_target_sync_long_long { } {
-if { [istarget i?86-*-*] || [istarget x86_64-*-*])
+if { [istarget i?86-*-*] || [istarget x86_64-*-*]
 || [istarget aarch64*-*-*]
 || [istarget arm*-*-*]
 || [istarget alpha*-*-*]

Jakub

[committed] openmp: Add testing checks (whether lhs appears in operands at all) to more trees

[Jakub Jelinek via Gcc-patches]

Hi!

This patch adds testing checks (goa_stabilize_expr with NULL pre_p) for more
tree codes, so that we don't gimplify their operands individually unless lhs
appears in them.  Also, so that we don't have exponential compile time 
complexity
with the added checks, I've added a depth computation, we don't expect lhs
to be found in depth 8 or above as all the atomic forms must have x expression
in specific places in the expressions.

Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk.

2021-09-14  Jakub Jelinek  

* gimplify.c (goa_stabilize_expr): Add depth argument, propagate
it to recursive calls, for depth above 7 just gimplify or return.
Perform a test even for MODIFY_EXPR, ADDR_EXPR, COMPOUND_EXPR with
__builtin_clear_padding and TARGET_EXPR.
(gimplify_omp_atomic): Adjust goa_stabilize_expr callers.

--- gcc/gimplify.c.jj   2021-09-11 09:33:37.870332181 +0200
+++ gcc/gimplify.c  2021-09-13 11:26:28.937933092 +0200
@@ -13859,10 +13859,10 @@ goa_lhs_expr_p (tree expr, tree addr)
 
 static int
 goa_stabilize_expr (tree *expr_p, gimple_seq *pre_p, tree lhs_addr,
-   tree lhs_var, tree _expr, bool rhs)
+   tree lhs_var, tree _expr, bool rhs, int depth)
 {
   tree expr = *expr_p;
-  int saw_lhs;
+  int saw_lhs = 0;
 
   if (goa_lhs_expr_p (expr, lhs_addr))
 {
@@ -13873,17 +13873,22 @@ goa_stabilize_expr (tree *expr_p, gimple
   if (is_gimple_val (expr))
 return 0;
 
-  saw_lhs = 0;
+  /* Maximum depth of lhs in expression is for the
+ __builtin_clear_padding (...), __builtin_clear_padding (...),
+ __builtin_memcmp (_EXPR , ...) == 0 ? ... : lhs;  */
+  if (++depth > 7)
+goto finish;
+
   switch (TREE_CODE_CLASS (TREE_CODE (expr)))
 {
 case tcc_binary:
 case tcc_comparison:
   saw_lhs |= goa_stabilize_expr (_OPERAND (expr, 1), pre_p, lhs_addr,
-lhs_var, target_expr, true);
+lhs_var, target_expr, true, depth);
   /* FALLTHRU */
 case tcc_unary:
   saw_lhs |= goa_stabilize_expr (_OPERAND (expr, 0), pre_p, lhs_addr,
-lhs_var, target_expr, true);
+lhs_var, target_expr, true, depth);
   break;
 case tcc_expression:
   switch (TREE_CODE (expr))
@@ -13895,84 +13900,101 @@ goa_stabilize_expr (tree *expr_p, gimple
case TRUTH_XOR_EXPR:
case BIT_INSERT_EXPR:
  saw_lhs |= goa_stabilize_expr (_OPERAND (expr, 1), pre_p,
-lhs_addr, lhs_var, target_expr, true);
+lhs_addr, lhs_var, target_expr, true,
+depth);
  /* FALLTHRU */
case TRUTH_NOT_EXPR:
  saw_lhs |= goa_stabilize_expr (_OPERAND (expr, 0), pre_p,
-lhs_addr, lhs_var, target_expr, true);
+lhs_addr, lhs_var, target_expr, true,
+depth);
  break;
case MODIFY_EXPR:
+ if (pre_p && !goa_stabilize_expr (expr_p, NULL, lhs_addr, lhs_var,
+   target_expr, true, depth))
+   break;
  saw_lhs |= goa_stabilize_expr (_OPERAND (expr, 1), pre_p,
-lhs_addr, lhs_var, target_expr, true);
+lhs_addr, lhs_var, target_expr, true,
+depth);
+ saw_lhs |= goa_stabilize_expr (_OPERAND (expr, 0), pre_p,
+lhs_addr, lhs_var, target_expr, false,
+depth);
+ break;
  /* FALLTHRU */
case ADDR_EXPR:
+ if (pre_p && !goa_stabilize_expr (expr_p, NULL, lhs_addr, lhs_var,
+   target_expr, true, depth))
+   break;
  saw_lhs |= goa_stabilize_expr (_OPERAND (expr, 0), pre_p,
-lhs_addr, lhs_var, target_expr, false);
+lhs_addr, lhs_var, target_expr, false,
+depth);
  break;
case COMPOUND_EXPR:
- /* Special-case __builtin_clear_padding call before
-__builtin_memcmp.  */
- if (TREE_CODE (TREE_OPERAND (expr, 0)) == CALL_EXPR)
+ /* Break out any preevaluations from cp_build_modify_expr.  */
+ for (; TREE_CODE (expr) == COMPOUND_EXPR;
+  expr = TREE_OPERAND (expr, 1))
{
- tree fndecl = get_callee_fndecl (TREE_OPERAND (expr, 0));
- if (fndecl
- && fndecl_built_in_p (fndecl, BUILT_IN_CLEAR_PADDING)
- && VOID_TYPE_P (TREE_TYPE (TREE_OPERAND (expr, 0
+ /* Special-case __builtin_clear_padding call before

[PATCH v2] analyzer: Define INCLUDE_UNIQUE_PTR

[Maxim Blinov]

Un-break the build for AArch64 Darwin, see PR bootstrap/102242.  Build
fails with log below:

```
In file included from 
../../../gcc-master-wip-apple-si/gcc/analyzer/engine.cc:69:
In file included from 
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1/memory:678:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1/stdexcept:239:5:
 error: no member named 'fancy_abort' in namespace 'std::__1'; did you mean 
simply 'fancy_abort'?
_VSTD::abort();
^~~
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1/__config:852:15:
 note: expanded from macro '_VSTD'

../../../gcc-master-wip-apple-si/gcc/system.h:777:13: note: 'fancy_abort' 
declared here
extern void fancy_abort (const char *, int, const char *)
^
```

Judging from the following comment in gcc/system.h, we just need to
define INCLUDE_UNIQUE_PTR since commit eafa9d96923 added the inclusion
of :

```
/* Some of the headers included by  can use "abort" within a
   namespace, e.g. "_VSTD::abort();", which fails after we use the
   preprocessor to redefine "abort" as "fancy_abort" below.
   Given that unique-ptr.h can use "free", we need to do this after "free"
   is declared but before "abort" is overridden.  */

```

gcc/analyzer/ChangeLog:
* engine.cc: Define INCLUDE_UNIQUE_PTR.
---
 gcc/analyzer/engine.cc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/gcc/analyzer/engine.cc b/gcc/analyzer/engine.cc
index 24f0931197d..f21f8e5b78a 100644
--- a/gcc/analyzer/engine.cc
+++ b/gcc/analyzer/engine.cc
@@ -19,6 +19,7 @@ along with GCC; see the file COPYING3.  If not see
 .  */
 
 #include "config.h"
+#define INCLUDE_UNIQUE_PTR
 #include "system.h"
 #include "coretypes.h"
 #include "tree.h"
-- 
2.30.1 (Apple Git-130)

[Ada] Implement PR ada/101385

[Eric Botcazou]

For the sake of consistency with -Wall & -w, this makes -Werror imply -gnatwe.

Tested on x86-64/Linux, applied on the mainline.


2021-09-14  Eric Botcazou  

PR ada/101385
* doc/gnat_ugn/building_executable_programs_with_gnat.rst
(-Wall): Minor fixes.
(-w): Likewise.
(-Werror): Document that it also sets -gnatwe by default.
* gcc-interface/lang-specs.h (ada): Expand -gnatwe if -Werror is
passed and move expansion of -gnatw switches to before -gnatez.

-- 
Eric Botcazoudiff --git a/gcc/ada/doc/gnat_ugn/building_executable_programs_with_gnat.rst b/gcc/ada/doc/gnat_ugn/building_executable_programs_with_gnat.rst
index 07c38df6fa0..5a69967615f 100644
--- a/gcc/ada/doc/gnat_ugn/building_executable_programs_with_gnat.rst
+++ b/gcc/ada/doc/gnat_ugn/building_executable_programs_with_gnat.rst
@@ -4157,16 +4157,16 @@ of the pragma in the :title:`GNAT_Reference_manual`).
   This switch enables most warnings from the GCC back end.
   The code generator detects a number of warning situations that are missed
   by the GNAT front end, and this switch can be used to activate them.
-  The use of this switch also sets the default front end warning mode to
-  :switch:`-gnatwa`, that is, most front end warnings activated as well.
+  The use of this switch also sets the default front-end warning mode to
+  :switch:`-gnatwa`, that is, most front-end warnings are activated as well.
 
 
 .. index:: -w (gcc)
 
 :switch:`-w`
   Conversely, this switch suppresses warnings from the GCC back end.
-  The use of this switch also sets the default front end warning mode to
-  :switch:`-gnatws`, that is, front end warnings suppressed as well.
+  The use of this switch also sets the default front-end warning mode to
+  :switch:`-gnatws`, that is, front-end warnings are suppressed as well.
 
 
 .. index:: -Werror (gcc)
@@ -4175,6 +4175,9 @@ of the pragma in the :title:`GNAT_Reference_manual`).
   This switch causes warnings from the GCC back end to be treated as
   errors.  The warning string still appears, but the warning messages are
   counted as errors, and prevent the generation of an object file.
+  The use of this switch also sets the default front-end warning mode to
+  :switch:`-gnatwe`, that is, front-end warning messages and style check
+  messages are treated as errors as well.
 
 
 A string of warning parameters can be used in the same parameter. For example::
diff --git a/gcc/ada/gcc-interface/lang-specs.h b/gcc/ada/gcc-interface/lang-specs.h
index f5a7496ad5d..d26cc8d0534 100644
--- a/gcc/ada/gcc-interface/lang-specs.h
+++ b/gcc/ada/gcc-interface/lang-specs.h
@@ -36,7 +36,7 @@
"\
  %{pg:%{fomit-frame-pointer:%e-pg and -fomit-frame-pointer are incompatible}}\
  %{!S:%{!c:%e-c or -S required for Ada}}\
- gnat1 %{I*} %{k8:-gnatk8} %{Wall:-gnatwa} %{w:-gnatws} %{!Q:-quiet}\
+ gnat1 %{I*} %{k8:-gnatk8} %{!Q:-quiet}\
 %{nostdinc*} %{nostdlib*}\
 %{fcompare-debug-second:-gnatd_A} \
 %{O*} %{W*} %{w} %{p} %{pg:-p} " ADA_DUMPS_OPTIONS " \
@@ -44,8 +44,9 @@
 #if defined(TARGET_VXWORKS_RTP)
"%{fRTS=rtp|fRTS=rtp-smp|fRTS=ravenscar-cert-rtp:-mrtp} "
 #endif
-   "%{gnatea:-gnatez} %{g***} "
-   "%1 %{!S:%{o*:%w%*-gnatO}} \
+   "%{Wall:-gnatwa} %{Werror:-gnatwe} %{w:-gnatws} \
+%{gnatea:-gnatez} %{g***} \
+%1 %{!S:%{o*:%w%*-gnatO}} \
 %i %{S:%W{o*}%{!o*:-o %w%b.s}} \
 %{gnatc*|gnats*: -o %j} %{-param*} \
 %{!gnatc*:%{!gnats*:%(invoke_as)}}", 0, 0, 0},

Re: [PATCH] c++: fix wrong fixit hints for misspelled typedef [PR77565]

[Michel Morin via Gcc-patches]

On Tue, Sep 14, 2021 at 7:14 AM David Malcolm  wrote:
>
> On Tue, 2021-09-14 at 03:35 +0900, Michel Morin via Gcc-patches wrote:
> > Hi,
> >
> > PR77565 reports that, with the code `typdef int Int;`, GCC emits
> > "did you mean 'typeof'?" instead of "did you mean 'typedef'?".
> >
> > This happens because the typo corrector determines that `typeof` is a
> > candidate for suggestion (through
> > `cp_keyword_starts_decl_specifier_p`),
> > but `typedef` is not.
> >
> > This patch fixes the issue by adding `typedef` as a candidate. The
> > patch
> > additionally adds the `inline` specifier and cv-specifiers as a
> > candidate.
> > Here is a patch (tests `make check-gcc` pass on darwin):
>
> Thanks for this patch (and for reporting the bug in the first place).
>
> I notice that, as well as being used for fix-it hints by
> lookup_name_fuzzy (indirectly via suggest_rid_p),
> cp_keyword_starts_decl_specifier_p is also used by
> cp_lexer_next_token_is_decl_specifier_keyword, which is used by
> cp_parser_lambda_declarator_opt and cp_parser_constructor_declarator_p.

Ah, you're right! Thank you for pointing this out.
I failed to grep those functions somehow.

One thing that confuses me is that cp_keyword_starts_decl_specifier_p
misses many keywords that can start decl-specifiers (e.g.
typedef/inline/cv-qual and friend/explicit/virtual).
So let's wait C++ frontend maintainers ;)

Regards,
Michel


> So I'm not sure if this fix is exactly correct - hopefully one of the
> C++ frontend maintainers can chime in.  If
> cp_keyword_starts_decl_specifier_p isn't quite the right place for
> this, the fix could probably go in suggest_rid_p instead, which *is*
> specific to spelling corrections.
>
> Hope this is constructive; thanks again for the patch
> Dave
>
>
>
> >
> > 
> > c++: add typo corrections for typedef/inline/cv-qual [PR77565]
> >
> > PR c++/77565
> >
> > gcc/cp/ChangeLog:
> >
> > * parser.c (cp_keyword_starts_decl_specifier_p): Handle
> > typedef/inline specifiers and cv-qualifiers.
> >
> > gcc/testsuite/ChangeLog:
> >
> > * g++.dg/spellcheck-typenames.C: Add tests for decl-specs.
> >
> > --- a/gcc/cp/parser.c
> > +++ b/gcc/cp/parser.c
> > @@ -1051,6 +1051,12 @@ cp_keyword_starts_decl_specifier_p (enum rid
> > keyword)
> >  case RID_FLOAT:
> >  case RID_DOUBLE:
> >  case RID_VOID:
> > +  /* CV qualifiers.  */
> > +case RID_CONST:
> > +case RID_VOLATILE:
> > +  /* typedef/inline specifiers.  */
> > +case RID_TYPEDEF:
> > +case RID_INLINE:
> >/* GNU extensions.  */
> >  case RID_ATTRIBUTE:
> >  case RID_TYPEOF:
> > --- a/gcc/testsuite/g++.dg/spellcheck-typenames.C
> > +++ b/gcc/testsuite/g++.dg/spellcheck-typenames.C
> > @@ -76,3 +76,38 @@ singed char ch; // { dg-error "1: 'singed' does
> > not
> > name a type; did you mean 's
> >   ^~
> >   signed
> > { dg-end-multiline-output "" } */
> > +
> > +typdef int my_int; // { dg-error "1: 'typdef' does not name a type;
> > did you mean 'typedef'?" }
> > +/* { dg-begin-multiline-output "" }
> > + typdef int my_int;
> > + ^~
> > + typedef
> > +   { dg-end-multiline-output "" } */
> > +
> > +inlien int inline_func(); // { dg-error "1: 'inlien' does not name a
> > type; did you mean 'inline'?" }
> > +/* { dg-begin-multiline-output "" }
> > + inlien int inline_func();
> > + ^~
> > + inline
> > +   { dg-end-multiline-output "" } */
> > +
> > +coonst int ci = 0; // { dg-error "1: 'coonst' does not name a type;
> > did you mean 'const'?" }
> > +/* { dg-begin-multiline-output "" }
> > + coonst int ci = 0;
> > + ^~
> > + const
> > +   { dg-end-multiline-output "" } */
> > +
> > +voltil int vi; // { dg-error "1: 'voltil' does not name a type; did
> > you mean 'volatile'?" }
> > +/* { dg-begin-multiline-output "" }
> > + voltil int vi;
> > + ^~
> > + volatile
> > +   { dg-end-multiline-output "" } */
> > +
> > +statik int si; // { dg-error "1: 'statik' does not name a type; did
> > you mean 'static'?" }
> > +/* { dg-begin-multiline-output "" }
> > + statik int si;
> > + ^~
> > + static
> > +   { dg-end-multiline-output "" } */
> > 
> >
> > --
> > Regards,
> > Michel
>
>

Re: [r12-3495 Regression] FAIL: 29_atomics/atomic_flag/test_and_set/explicit-hle.cc (test for excess errors) on Linux/x86_64

[Jakub Jelinek via Gcc-patches]

On Mon, Sep 13, 2021 at 03:08:01PM -0700, sunil.k.pandey via Gcc-patches wrote:
> FAIL: 29_atomics/atomic_flag/test_and_set/explicit-hle.cc (test for excess 
> errors)

Apparently all C++ compilations with
-m32 -march={i386,i486,i586,pentium,pentiumpro,lakemont,pentium4}
FAIL with:
: warning: ‘--param constructive-interference-size=64’ is greater 
than ‘--param l1-cache-line-size=0’ [-Winterference-size]
So, either the C++ FE should not warn if param_l1_cache_line_size is 0
(treat it as a don't know value), or the backend shouldn't overwrite
the default generic param value of 32 with 0 when ix86_tune_cost->prefetch_block
is 0.

> FAIL: g++.dg/ext/sync-4.C  -std=gnu++14 (test for excess errors)
> FAIL: g++.dg/ext/sync-4.C  -std=gnu++17 (test for excess errors)
> FAIL: g++.dg/ext/sync-4.C  -std=gnu++2a (test for excess errors)
> FAIL: g++.dg/ext/sync-4.C  -std=gnu++98 (test for excess errors)
...

Jakub

Re: [PATCH RFC] c++: implement C++17 hardware interference size

[Christophe LYON via Gcc-patches]

On 10/09/2021 15:16, Jason Merrill via Gcc-patches wrote:

OK, time to finish this up.  The main change relative to the last patch I sent
to the list is dropping the -finterference-tune flag and making that behavior
the default.  Any more comments?



The last missing piece of the C++17 standard library is the hardware
intereference size constants.  Much of the delay in implementing these has
been due to uncertainty about what the right values are, and even whether
there is a single constant value that is suitable; the destructive
interference size is intended to be used in structure layout, so program
ABIs will depend on it.

In principle, both of these values should be the same as the target's L1
cache line size.  When compiling for a generic target that is intended to
support a range of target CPUs with different cache line sizes, the
constructive size should probably be the minimum size, and the destructive
size the maximum, unless you are constrained by ABI compatibility with
previous code.

 From discussion on gcc-patches, I've come to the conclusion that the
solution to the difficulty of choosing stable values is to give up on it,
and instead encourage only uses where ABI stability is unimportant: in
particular, uses where the ABI is shared at most between translation units
built at the same time with the same flags.

To that end, I've added a warning for any use of the constant value of
std::hardware_destructive_interference_size in a header or module export.
Appropriate uses within a project can disable the warning.

A previous iteration of this patch included an -finterference-tune flag to
make the value vary with -mtune; this iteration makes that the default
behavior, which should be appropriate for all reasonable uses of the
variable.  The previous default of "stable-ish" seems to me likely to have
been more of an attractive nuisance; since we can't promise actual
stability, we should instead make proper uses more convenient.

JF Bastien's implementation proposal is summarized at
https://github.com/itanium-cxx-abi/cxx-abi/issues/74

I implement this by adding new --params for the two sizes.  Targets can
override these values in targetm.target_option.override() to support a range
of values for the generic target; otherwise, both will default to the L1
cache line size.

64 bytes still seems correct for all x86.

I'm not sure why he proposed 64/64 for generic 32-bit ARM, since the Cortex
A9 has a 32-byte cache line, so I'd think 32/64 would make more sense.


While this works for an arm-linux-gnueabihf toolchain configured 
--with-mode=arm, it fails --with-mode=thumb (also using 
--with-cpu=cortex-a9):


: error: '--param constructive-interference-size=64' is 
greater than '--param l1-cache-line-size=32' [-Werror=interference-size]

cc1plus: all warnings being treated as errors
make[4]: *** [Makefile:678: alloc_c.lo] Error 1





He proposed 64/128 for generic AArch64, but since the A64FX now has a 256B
cache line, I've changed that to 64/256.



Similarly, for aarch64 I'm seeing:

: error: '--param constructive-interference-size=64' is 
greater than '--param l1-cache-line-size=32' [-Werror=interference-size]

cc1plus: all warnings being treated as errors
make[4]: *** [Makefile:678: alloc_c.lo] Error 1


So adjustment is needed for both arm and aarch64 targets


Christophe




With the above choice to reject stability as a goal, getting these values
"right" is now just a matter of what we want the default optimization to be,
and we can feel free to adjust them as CPUs with different cache lines
become more and less common.

gcc/ChangeLog:

* params.opt: Add destructive-interference-size and
constructive-interference-size.
* doc/invoke.texi: Document them.
* config/aarch64/aarch64.c (aarch64_override_options_internal):
Set them.
* config/arm/arm.c (arm_option_override): Set them.
* config/i386/i386-options.c (ix86_option_override_internal):
Set them.

gcc/c-family/ChangeLog:

* c.opt: Add -Winterference-size.
* c-cppbuiltin.c (cpp_atomic_builtins): Add __GCC_DESTRUCTIVE_SIZE
and __GCC_CONSTRUCTIVE_SIZE.

gcc/cp/ChangeLog:

* constexpr.c (maybe_warn_about_constant_value):
Complain about std::hardware_destructive_interference_size.
(cxx_eval_constant_expression): Call it.
* decl.c (cxx_init_decl_processing): Check
--param *-interference-size values.

libstdc++-v3/ChangeLog:

* include/std/version: Define __cpp_lib_hardware_interference_size.
* libsupc++/new: Define hardware interference size variables.

gcc/testsuite/ChangeLog:

* g++.dg/warn/Winterference.h: New file.
* g++.dg/warn/Winterference.C: New test.
* g++.target/aarch64/interference.C: New test.
* g++.target/arm/interference.C: New test.
* g++.target/i386/interference.C: New test.
---
  gcc/doc/invoke.texi   | 65 

[Ada] Give more informative error message for by-reference types

[Eric Botcazou]

Recent compilers enforce more strictly the RM C.6(18) clause, which says that 
volatile record types are by-reference types.  This changes the typical error 
message now given in these cases.

Tested on x86-64/Linux, applied on the mainline, 11 and 10 branches.


2021-09-14  Eric Botcazou  

* gcc-interface/decl.c (gnat_to_gnu_entity) : Declare new
constant.  Adjust error message issued by validate_size in the case
of by-reference types.
(validate_size): Always use the error strings passed by the caller.

-- 
Eric Botcazoudiff --git a/gcc/ada/gcc-interface/decl.c b/gcc/ada/gcc-interface/decl.c
index 5cedb740a2e..d37ed3d1b52 100644
--- a/gcc/ada/gcc-interface/decl.c
+++ b/gcc/ada/gcc-interface/decl.c
@@ -4279,6 +4279,8 @@ gnat_to_gnu_entity (Entity_Id gnat_entity, tree gnu_expr, bool definition)
  handling alignment and possible padding.  */
   if (is_type && (!gnu_decl || this_made_decl))
 {
+  const bool is_by_ref = Is_By_Reference_Type (gnat_entity);
+
   gcc_assert (!TYPE_IS_DUMMY_P (gnu_type));
 
   /* Process the attributes, if not already done.  Note that the type is
@@ -4293,15 +4295,18 @@ gnat_to_gnu_entity (Entity_Id gnat_entity, tree gnu_expr, bool definition)
 	 non-constant).  */
   if (!gnu_size && kind != E_String_Literal_Subtype)
 	{
+	  const char *size_s = "size for %s too small{, minimum allowed is ^}";
+	  const char *type_s = is_by_ref ? "by-reference type &" : "&";
+
 	  if (Known_Esize (gnat_entity))
 	gnu_size
 	  = validate_size (Esize (gnat_entity), gnu_type, gnat_entity,
-			   VAR_DECL, false, false, NULL, NULL);
+			   VAR_DECL, false, false, size_s, type_s);
 	  else
 	gnu_size
 	  = validate_size (RM_Size (gnat_entity), gnu_type, gnat_entity,
 			   TYPE_DECL, false, Has_Size_Clause (gnat_entity),
-			   NULL, NULL);
+			   size_s, type_s);
 	}
 
   /* If a size was specified, see if we can make a new type of that size
@@ -4614,7 +4619,7 @@ gnat_to_gnu_entity (Entity_Id gnat_entity, tree gnu_expr, bool definition)
 	TYPE_ALIGN_OK (gnu_type) = 1;
 
 	  /* Record whether the type is passed by reference.  */
-	  if (Is_By_Reference_Type (gnat_entity) && !VOID_TYPE_P (gnu_type))
+	  if (is_by_ref && !VOID_TYPE_P (gnu_type))
 	TYPE_BY_REFERENCE_P (gnu_type) = 1;
 
 	  /* Record whether an alignment clause was specified.  */
@@ -9184,7 +9189,7 @@ validate_size (Uint uint_size, tree gnu_type, Entity_Id gnat_object,
   char buf[128];
   const char *s;
 
-  if (kind == FIELD_DECL)
+  if (s1 && s2)
 	{
 	  snprintf (buf, sizeof (buf), s1, s2);
 	  s = buf;
@@ -9193,6 +9198,7 @@ validate_size (Uint uint_size, tree gnu_type, Entity_Id gnat_object,
 	s = "component size for& too small{, minimum allowed is ^}";
   else
 	s = "size for& too small{, minimum allowed is ^}";
+
   post_error_ne_tree (s, gnat_error_node, gnat_object, old_size);
 
   return NULL_TREE;

[PATCH #2] PR c/102245: Disable sign-changing optimization for shifts by zero.

[Roger Sayle]

Respecting Jakub's suggestion that it may be better to warn-on-valid for
"if (x << 0)" as the author might have intended "if (x < 0)" [which will
also warn when x is _Bool], the simplest way to resolve this regression
is to disable the recently added fold transformation for shifts by zero;
these will be optimized later (elsewhere).  Guarding against integer_zerop
is the simplest of three alternatives; the second being to only apply
this transformation to GIMPLE and not GENERIC, and the third (potentially)
being to explicitly handle shifts by zero here, with an (if cond then else),
optimizing the expression to a convert, but awkwardly duplicating the
more general transformation earlier in match.pd's shift simplifications.

This patch has been tested (against a recent snapshot without build issues)
on x86_64-pc-linux-gnu with "make bootstrap" and "make -k check" with no
new failures.  Note that test1 in the new testcase is changed from
dg-bogus to dg-warning compared with version #1.  Ok for mainline?

2021-09-14  Roger Sayle  

gcc/ChangeLog
PR c/102245
* match.pd (shift optimizations): Disable recent sign-changing
optimization for shifts by zero, these will be folded later.

gcc/testsuite/ChangeLog
PR c/102245
* gcc.dg/Wint-in-bool-context-4.c: New test case.


Roger

-Original Message-
From: Jakub Jelinek  
Sent: 13 September 2021 11:58
To: Roger Sayle 
Cc: 'GCC Patches' 
Subject: Re: [PATCH] PR c/102245: Don't warn that ((_Bool)x<<0) isn't a 
truthvalue.

On Mon, Sep 13, 2021 at 11:42:08AM +0100, Roger Sayle wrote:
> gcc/c-family/ChangeLog
>   PR c/102245
>   * c-common.c (c_common_truthvalue_conversion) [LSHIFT_EXPR]:
>   Special case (optimize) shifts by zero.
> 
> gcc/testsuite/ChangeLog
>   PR c/102245
>   * gcc.dg/Wint-in-bool-context-4.c: New test case.
> 
> Roger
> --
> 

> diff --git a/gcc/c-family/c-common.c b/gcc/c-family/c-common.c index 
> 017e415..44b5fcc 100644
> --- a/gcc/c-family/c-common.c
> +++ b/gcc/c-family/c-common.c
> @@ -3541,6 +3541,10 @@ c_common_truthvalue_conversion (location_t location, 
> tree expr)
>break;
>  
>  case LSHIFT_EXPR:
> +  /* Treat shifts by zero as a special case.  */
> +  if (integer_zerop (TREE_OPERAND (expr, 1)))
> + return c_common_truthvalue_conversion (location,
> +TREE_OPERAND (expr, 0));
>/* We will only warn on signed shifts here, because the majority of
>false positive warnings happen in code where unsigned arithmetic
>was used in anticipation of a possible overflow.

> /* PR c/102245 */
> /* { dg-options "-Wint-in-bool-context" } */
> /* { dg-do compile } */
> 
> _Bool test1(_Bool x)
> {
>   return !(x << 0);  /* { dg-bogus "boolean context" } */ }

While this exact case is unlikely a misspelling of !(x < 0) as no _Bool is less 
than zero and hopefully we get a warning for !(x < 0), what about _Bool 
test1a(int x) {
  return !(x << 0);
}
?  I think there is a non-zero chance this was meant to be !(x < 0) and the 
current
pr102245.c: In function ‘test1a’:
pr102245.c:3:14: warning: ‘<<’ in boolean context, did you mean ‘<’? 
[-Wint-in-bool-context]
3 |   return !(x << 0);
  |   ~~~^
warning seems to be useful.

Jakub

diff --git a/gcc/match.pd b/gcc/match.pd
index 008f775..c6cc967 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -3401,13 +3401,15 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
  (cmp @0 @2)
 
 /* Both signed and unsigned lshift produce the same result, so use
-   the form that minimizes the number of conversions.  */
+   the form that minimizes the number of conversions.  Postpone this
+   transformation until after shifts by zero have been folded.  */
 (simplify
  (convert (lshift:s@0 (convert:s@1 @2) INTEGER_CST@3))
  (if (INTEGRAL_TYPE_P (type)
   && tree_nop_conversion_p (type, TREE_TYPE (@0))
   && INTEGRAL_TYPE_P (TREE_TYPE (@2))
-  && TYPE_PRECISION (TREE_TYPE (@2)) <= TYPE_PRECISION (type))
+  && TYPE_PRECISION (TREE_TYPE (@2)) <= TYPE_PRECISION (type)
+  && !integer_zerop (@3))
   (lshift (convert @2) @3)))
 
 /* Simplifications of conversions.  */
/* PR c/102245 */
/* { dg-options "-Wint-in-bool-context" } */
/* { dg-do compile } */

_Bool test1(_Bool x)
{
  return !(x << 0);  /* { dg-warning "boolean context" } */
}

_Bool test2(_Bool x)
{
  return !(x << 1);  /* { dg-warning "boolean context" } */
}

_Bool test3(_Bool x, int y)
{
  return !(x << y);  /* { dg-warning "boolean context" } */
}

_Bool test4(int x, int y)
{
  return !(x << y);  /* { dg-warning "boolean context" } */
}

_Bool test5(int x, int y)
{
  return !((x << y) << 0);  /* { dg-warning "boolean context" } */
}

int test6(_Bool x)
{
  int v = 0;
  return (v & ~1L) | (1L & (x << 0));  /* { dg-bogus "boolean context" } */
}

Re: [PATCH, Fortran] Revert to non-multilib-specific ISO_Fortran_binding.h

[Tobias Burnus]

On 14.09.21 05:39, Sandra Loosemore wrote:

Here's a patch.  Gerald, can you check that this fixes your bootstrap
problem on i586-unknown-freebsd11?


LGTM – thanks!

Tobias


Fortran: Prefer GCC internal macros to float.h in ISO_Fortran_binding.h.

 2021-09-13  Sandra Loosemore

  libgfortran/
  * ISO_Fortran_binding.h: Only include float.h if the C compiler
  doesn't have predefined __LDBL_* and __DBL_* macros.

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

Re: [PATCH] tree-optimization/102155 - fix LIM fill_always_executed_in CFG walk

[Richard Biener via Gcc-patches]

On Tue, 14 Sep 2021, Xionghu Luo wrote:

> 
> 
> On 2021/9/13 16:17, Richard Biener wrote:
> > 
[...]
> > I don't understand - BB6 is the header block of loop 2 which is
> > always entered and thus BB6 is always executed at least once.
> > 
> > The important part is that BB4 which follows the inner loop is
> > _not_ always executed because we don't know if we will exit the
> > inner loop.
> > 
> > What am I missing?
> 
> Oh, I see.  I only noticed the functionality change of the patch on the case
> and no failure check of it, misunderstood it was a regression instead of an
> improvement to also hoisting invariants from infinite loop, sorry about that.
> 
> Finally, the function fill_always_executed_in_1 could mark all ALWAYS_EXECUTED
> bb both including and after all subloops' bb but break after exiting from
> infinite subloops with better performance, thanks.  The only thing to be
> worried is replacing get_loop_body_in_dom_order makes the code a bit more
> complicated for later readers as the loop depth and DOM order is not a problem
> here any more? ;)

Yeah, but embedding the DOM walk _does_ improve the runtime of the code
and it would in principle allow to avoid entering conditionally executed
loops that do not always terminate (that's something we could pre-compute
and propagate up the loop tree).  It's just it didn't seem worth adding
even more code given I couldn't make the function pop up on the radar...

Richard.

Re: [PATCH v2] ipa-inline: Add target info into fn summary [PR102059]

[Kewen.Lin via Gcc-patches]

Hi Bill,

on 2021/9/13 上午12:34, Bill Schmidt wrote:
> Hi Kewen,
> 
> I'll leave the continued review of the back-end parts of this to Segher, but 
> I do have one long-term comment.  The rs6000_builtin_info[code].mask field 
> that you're relying on is going away as part of the built-in function 
> rewrite.  There will be a "bifattrs" field that replaces this in the 
> table-driven data structures.  I'm including those below.  Please think about 
> whether what you're building will easily translate to using these data 
> structures in the near future.  I don't think there are any show-stoppers 
> here, but if the new table needs adjustment to make your changes easier, 
> let's discuss.
> 

Thanks for pointing this out and the detailed related information.  I installed 
your patch series
"[PATCHv5 00/18] Replace the Power target-specific builtin machinery" and found 
that the existing
interface bif_is_htm works perfectly and nothing need to be added for the HTM 
check here.
Thanks for the efforts!  btw, the diff I used for testing is listed below:

diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index f90a5f40e4a..eee04fc21f2 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -25495,13 +25495,26 @@ rs6000_update_ipa_fn_target_info (vec 
, const gimple *stmt)
   tree fndecl = gimple_call_fndecl (stmt);
   if (fndecl && fndecl_built_in_p (fndecl, BUILT_IN_MD))
{
- enum rs6000_builtins fcode =
-   (enum rs6000_builtins) DECL_MD_FUNCTION_CODE (fndecl);
- /* HTM bifs definitely exploit HTM insns.  */
- if (rs6000_fn_has_any_of_these_mask_bits (fcode, RS6000_BTM_HTM))
+ if (new_builtins_are_live)
{
- info[0] |= OPTION_MASK_HTM;
- return false;
+ enum rs6000_gen_builtins fcode =
+   (enum rs6000_gen_builtins) DECL_MD_FUNCTION_CODE (fndecl);
+ if (bif_is_htm (rs6000_builtin_info_x[fcode]))
+   {
+ info[0] |= OPTION_MASK_HTM;
+ return false;
+   }
+   }
+ else
+   {
+ enum rs6000_builtins fcode =
+   (enum rs6000_builtins) DECL_MD_FUNCTION_CODE (fndecl);
+ /* HTM bifs definitely exploit HTM insns.  */
+ if (rs6000_fn_has_any_of_these_mask_bits (fcode, RS6000_BTM_HTM))
+   {
+ info[0] |= OPTION_MASK_HTM;
+ return false;
+   }
}
}
 }


BR,
Kewen

> Thanks,
> Bill
> 
> #define PPC_MAXRESTROPNDS 3
> struct GTY((user)) bifdata
> {
>   const char *bifname;
>   bif_enable enable;
>   tree fntype;
>   insn_code icode;
>   int  nargs;
>   int  bifattrs;
>   int  restr_opnd[PPC_MAXRESTROPNDS];
>   restriction restr[PPC_MAXRESTROPNDS];
>   int  restr_val1[PPC_MAXRESTROPNDS];
>   int  restr_val2[PPC_MAXRESTROPNDS];
>   const char *attr_string;
>   rs6000_gen_builtins assoc_bif;
> };
> 
> #define bif_init_bit(0x0001)
> #define bif_set_bit (0x0002)
> #define bif_extract_bit (0x0004)
> #define bif_nosoft_bit  (0x0008)
> #define bif_ldvec_bit   (0x0010)
> #define bif_stvec_bit   (0x0020)
> #define bif_reve_bit(0x0040)
> #define bif_pred_bit(0x0080)
> #define bif_htm_bit (0x0100)
> #define bif_htmspr_bit  (0x0200)
> #define bif_htmcr_bit   (0x0400)
> #define bif_mma_bit (0x0800)
> #define bif_quad_bit(0x1000)
> #define bif_pair_bit(0x2000)
> #define bif_mmaint_bit  (0x4000)
> #define bif_no32bit_bit (0x8000)
> #define bif_32bit_bit   (0x0001)
> #define bif_cpu_bit (0x0002)
> #define bif_ldstmask_bit(0x0004)
> #define bif_lxvrse_bit  (0x0008)
> #define bif_lxvrze_bit  (0x0010)
> #define bif_endian_bit  (0x0020)
> 
> #define bif_is_init(x)  ((x).bifattrs & bif_init_bit)
> #define bif_is_set(x)   ((x).bifattrs & bif_set_bit)
> #define bif_is_extract(x)   ((x).bifattrs & bif_extract_bit)
> #define bif_is_nosoft(x)((x).bifattrs & bif_nosoft_bit)
> #define bif_is_ldvec(x) ((x).bifattrs & bif_ldvec_bit)
> #define bif_is_stvec(x) ((x).bifattrs & bif_stvec_bit)
> #define bif_is_reve(x)  ((x).bifattrs & bif_reve_bit)
> #define bif_is_predicate(x) ((x).bifattrs & bif_pred_bit)
> #define bif_is_htm(x)   ((x).bifattrs & bif_htm_bit)
> #define bif_is_htmspr(x)((x).bifattrs & bif_htmspr_bit)
> #define bif_is_htmcr(x) ((x).bifattrs & bif_htmcr_bit)
> #define bif_is_mma(x)   ((x).bifattrs & bif_mma_bit)
> #define bif_is_quad(x)  ((x).bifattrs & bif_quad_bit)
> #define bif_is_pair(x)  ((x).bifattrs & bif_pair_bit)
> #define bif_is_mmaint(x)((x).bifattrs &