Re: [PATCH] add -Wmismatched-tags (PR 61339)

2019-12-16 Thread Martin Sebor

On 12/16/19 3:51 PM, Jason Merrill wrote:

On 12/9/19 7:29 PM, Martin Sebor wrote:

Just a few nits:


+/* A mapping between a TYPE_DECL for a class and the class_decl_loc_t
+   description above.  */
+typedef hash_map class_to_loc_map_t;
+static class_to_loc_map_t class2loc;


I think we can make these members of class_decl_loc_t, now that we 
aren't marking them with GTY.



+  class_decl_loc_t *rdl = class2loc.get (type_decl);
+  if (!rdl)
+    {
+  tree type = TREE_TYPE (type_decl);
+  if (def_p || !COMPLETE_TYPE_P (type))
+    {
+  /* TYPE_DECL is the first declaration or definition of the type
+ (outside precompiled headers -- see below).  Just create
+ a new entry for it.  */
+  class2loc.put (type_decl, class_decl_loc_t (class_key, false, 
def_p));

+  return;
+    }
+
+  /* TYPE was previously defined in some unknown precompiled 
hdeader.

+ Simply add a record of its definition at an unknown location and
+ proceed below to add a reference to it at the current location.
+ (Declarations in precompiled headers that are not definitions
+ are ignored.)  */
+  tag_types def_key
+    = CLASSTYPE_DECLARED_CLASS (type) ? class_type : record_type;
+  location_t def_loc = DECL_SOURCE_LOCATION (type_decl);
+  rdl = _or_insert (type_decl);
+  *rdl = class_decl_loc_t (def_key, false, true, def_loc);
+    }


It seems that you could use get_or_insert at the top, since you always 
end up creating an element if there wasn't one already.



+  /* A prior declaration of TYPE_DECL has been seen.  */
+
+  if (rdl->idxdef != UINT_MAX && rdl->def_class_key == class_key)
+    /* Do nothing if the class-key in this declaration matches
+   the definition.  */
+    return;

...

I still think that the rest of this function could be a non-static 
member function to avoid so many "rdl->".


Attached is another revision with these changes.

Martin
PR c++/61339 - add warning for mismatch between struct and class

gcc/c-family/ChangeLog:

	PR c++/61339
	* c.opt (-Wmismatched-tags, -Wredundant-tags): New options.

gcc/cp/ChangeLog:

	PR c++/61339
	* parser.c (cp_parser_maybe_warn_enum_key): New function.
	(class_decl_loc_t): New class.
	(cp_parser_elaborated_type_specifier): Call
	cp_parser_maybe_warn_enum_key.
	(cp_parser_class_head): Call cp_parser_check_class_key.
	(cp_parser_check_class_key): Add arguments.  Call class_decl_loc_t::add.
	(c_parse_file): Call class_decl_loc_t::diag_mismatched_tags.

gcc/testsuite/ChangeLog:

	PR c++/61339
	* g++.dg/warn/Wmismatched-tags.C: New test.
	* g++.dg/warn/Wredundant-tags.C: New test.
	* g++.dg/pch/Wmismatched-tags.C: New test.
	* g++.dg/pch/Wmismatched-tags.Hs: New test header.

gcc/ChangeLog:

	PR c++/61339
	* doc/invoke.texi (-Wmismatched-tags, -Wredundant-tags): Document
	new C++ options.

diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
index 914a2f0ef44..4f3d3cf0d43 100644
--- a/gcc/c-family/c.opt
+++ b/gcc/c-family/c.opt
@@ -755,6 +755,10 @@ Wmisleading-indentation
 C C++ Common Var(warn_misleading_indentation) Warning LangEnabledBy(C C++,Wall)
 Warn when the indentation of the code does not reflect the block structure.
 
+Wmismatched-tags
+C++ Objc++ Var(warn_mismatched_tags) Warning
+Warn when a class is redeclared or referenced using a mismatched class-key.
+
 Wmissing-braces
 C ObjC C++ ObjC++ Var(warn_missing_braces) Warning LangEnabledBy(C ObjC,Wall)
 Warn about possibly missing braces around initializers.
@@ -783,6 +787,10 @@ Wpacked-not-aligned
 C ObjC C++ ObjC++ Var(warn_packed_not_aligned) Warning LangEnabledBy(C ObjC C++ ObjC++,Wall)
 Warn when fields in a struct with the packed attribute are misaligned.
 
+Wredundant-tags
+C++ Objc++ Var(warn_redundant_tags) Warning
+Warn when a class or enumerated type is referenced using a redundant class-key.
+
 Wsized-deallocation
 C++ ObjC++ Var(warn_sized_deallocation) Warning EnabledBy(Wextra)
 Warn about missing sized deallocation functions.
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 16d1359c47d..d02a4afd736 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -2599,8 +2599,9 @@ static enum tag_types cp_parser_token_is_class_key
   (cp_token *);
 static enum tag_types cp_parser_token_is_type_parameter_key
   (cp_token *);
+static void cp_parser_maybe_warn_enum_key (cp_parser *, location_t, tree, rid);
 static void cp_parser_check_class_key
-  (enum tag_types, tree type);
+(cp_parser *, location_t, enum tag_types, tree type, bool, bool);
 static void cp_parser_check_access_in_redeclaration
   (tree type, location_t location);
 static bool cp_parser_optional_template_keyword
@@ -18498,6 +18499,11 @@ cp_parser_elaborated_type_specifier (cp_parser* parser,
   tree globalscope;
   cp_token *token = NULL;
 
+  /* For class and enum types the location of the class-key or enum-key.  */
+  location_t key_loc = cp_lexer_peek_token (parser->lexer)->location;
+  /* For a scoped enum, the 'class' or 'struct' keyword id.  */
+  rid scoped_key = 

[PING^4][PATCH 0/4] Fix library testsuite compilation for build sysroot

2019-12-16 Thread Maciej W. Rozycki
On Mon, 11 Nov 2019, Maciej W. Rozycki wrote:

>  This patch series addresses a problem with the testsuite compiler being 
> set up across libatomic, libffi, libgo, libgomp with no correlation 
> whatsoever to the target compiler being used in GCC compilation.  
> Consequently there in no arrangement made to set up the compilation 
> sysroot according to the build sysroot specified for GCC compilation, 
> causing a catastrophic failure across the testsuites affected from the 
> inability to link executables.

 Ping for:





  Maciej


[PING^2][PATCH v2 2/2] testsuite: Fix run-time tracking down of `libgcc_s'

2019-12-16 Thread Maciej W. Rozycki
On Fri, 29 Nov 2019, Maciej W. Rozycki wrote:

> Fix a catastrophic libgo testsuite failure in cross-compilation where 
> the shared `libgcc_s' library cannot be found by the loader at run time 
> in build-tree testing and consequently all test cases fail the execution 
> stage, giving output (here with the `x86_64-linux-gnu' host and the 
> `riscv64-linux-gnu' target, with RISC-V QEMU in the Linux user emulation 
> mode as the target board) like:
> 
> spawn qemu-riscv64 -E 
> LD_LIBRARY_PATH=.:.../riscv64-linux-gnu/lib64/lp64d/libgo/.libs ./a.exe
> ./a.exe: error while loading shared libraries: libgcc_s.so.1: cannot open 
> shared object file: No such file or directory
> FAIL: archive/tar

 Ping for:



  Maciej


Re: [PATCH] Fix attribute((section)) for templates

2019-12-16 Thread Jason Merrill

On 11/29/19 6:23 PM, Strager Neds wrote:

I discovered an issue with my patch. I need help resolving it.

Take the following code for example:

 template
 struct s
 {
   static inline int __attribute__((section(".testsection"))) var = 1;
 };

 struct public_symbol {};

 namespace {
 struct internal_symbol {};
 }

 int *
 f(bool which)
 {
   if (which)
 return ::var;
   else
 return ::var;
 }

With my patch, compiling this code fails with the following error:

 example.C:4:62: error: 's<{anonymous}::internal_symbol>::var'
causes a section type conflict with 's::var'
 example.C:4:62: note: 's::var' was declared here

The error is reported by gcc/varasm.c (get_section) because
s::var has the following section flags:

 SECTION_NAMED | SECTION_NOTYPE | SECTION_WRITE
 (flags == 0x280200)

but s::var has the following section flags:

 SECTION_NAMED | SECTION_LINKONCE | SECTION_WRITE
 (sect->common.flags == 0x200a00)

and a section can't have both of these flag at the same time. In
particular, SECTION_LINKONCE conflicts with not-SECTION_LINKONCE.

How can we solve this problem? Some ideas (none of which I like):

* Disallow this code, possibly with an improved diagnostic.
* Silently make the section SECTION_LINKONCE if there is a conflict.
* Silently make the section not-SECTION_LINKONCE if there is a conflict.
* Silently make the section not-SECTION_LINKONCE unconditionally (even
   if there is no conflict).
* Make two sections with the same name, one with SECTION_LINKONCE and
   one with not-SECTION_LINKONCE. This is what Clang does. Clang seems to
   Do What I Mean for ELF; the .o file has one COMDAT section and another
   non-COMDAT section.
* Extend attribute((section())) to allow specifying different section
   names for different section flags.

Thanks in advance for your feedback!


s::var should probably go into its own COMDAT section 
named something like .gnu.linkonce.testsection.. 
Currently resolve_unique_section does nothing if DECL_SECTION_NAME is set.


Jason



[C++ Patch] Improve throw, sizeof, and alignof locations & more

2019-12-16 Thread Paolo Carlini

Hi,

another batch of work. Primarily, more of the idea of moving up the 
construction of the compound location thus passing it to the 
cxx_sizeof_or_alignof* and build_throw functions to obtain better 
locations for all the diagnostics issued by the latter. During the work 
a few mildly interesting nits (eg, for sizeof and alignof we want to set 
whenever possible the location inside the cxx_* functions and that 
allows to avoid set_location in cp_parser_unary_expression, but 
minimally we have to pass it to the cp_expr constructor, otherwise 
plugin testcases badly fail; noticed that in cxx_sizeof_expr and 
cxx_alignof_expr having a single cp_expr_loc_or_input_loc on top 
actually implies better locations (4 testcases) because below, before 
the diagnostic calls, we have STRIP_ANY_LOCATION_WRAPPER uses; in fact I 
changed those cp_expr_loc_or_input_loc to cp_expr_loc_or_loc because for 
expressions we still want to try fetching the locations but we do have a 
meaningful fallback in the location argument of the function; in 
build_throw, an error should be an inform, because in such cases we 
already issued an error (tested in ctor1.C)) but nothing major. The 
below includes a few other minor changes, like two additional uses of 
DECL_SOURCE_LOCATION, cp_expr_loc_or_input_loc, removal of an unused 
function.


Tested x86_64-linux.

Thanks, Paolo.

//

/gcc/cp
2019-12-16  Paolo Carlini  

* typeck.c (cxx_sizeof_or_alignof_type): Add location_t parameter
and use it throughout.
(cxx_sizeof_expr): Likewise.
(cxx_alignof_expr): Likewise.
(cxx_sizeof_or_alignof_expr): Likewise.
(cxx_alignas_expr): Update call.
* decl.c (fold_sizeof_expr): Likewise.
* pt.c (tsubst_copy): Likewise.
(tsubst_copy_and_build): Likewise.
* except.c (build_throw): Add location_t parameter and use it.
(expand_end_catch_block): Update call.
* parser.c (cp_parser_unary_expression): Update
cxx_sizeof_or_alignof_type and cxx_sizeof_or_alignof_expr calls,
pass the compound location.
(cp_parser_throw_expression): Likewise pass the combined location
to build_throw.
* cp-tree.h: Update declarations.

* semantics.c (finish_handler_parms): Use DECL_SOURCE_LOCATION.
* decl2.c (check_classfn): Likewise.

* except.c (is_admissible_throw_operand_or_catch_parameter):
Exploit cp_expr_loc_or_input_loc in one place.

* except.c (create_try_catch_expr): Remove, unused.

/libcc1
2019-12-16  Paolo Carlini  

* libcp1plugin.cc (plugin_build_unary_expr): Update build_throw
and cxx_sizeof_or_alignof_expr calls.
(plugin_build_unary_type_expr): Likewise for
cxx_sizeof_or_alignof_type.

/gcc/testsuite
2019-12-16  Paolo Carlini  

* g++.dg/diagnostic/alignof2.C: New.
* g++.dg/diagnostic/alignof3.C: Likewise.
* g++.dg/diagnostic/incomplete-type-1.C: Likewise.
* g++.dg/warn/Wcatch-value-3b.C: Likewise.
* g++.dg/cpp0x/alignof3.C: Check location(s) too.
* g++.dg/cpp1z/decomp-bitfield1.C: Likewise.
* g++.dg/cpp1z/has-unique-obj-representations2.C: Likewise.
* g++.dg/expr/sizeof3.C: Likewise.
* g++.dg/ext/flexary6.C: Likewise.
* g++.dg/ext/vla4.C: Likewise.
* g++.dg/template/sizeof11.C: Likewise.
* g++.dg/warn/Wcatch-value-1.C: Likewise.
* g++.dg/warn/Wcatch-value-2.C: Likewise.
* g++.dg/warn/Wcatch-value-3.C: Likewise.
* g++.old-deja/g++.brendan/sizeof1.C: Likewise.
* g++.old-deja/g++.brendan/sizeof3.C: Likewise.
* g++.old-deja/g++.brendan/sizeof4.C: Likewise.
* g++.old-deja/g++.eh/ctor1.C: Likewise.
* g++.old-deja/g++.jason/ambig1.C: Likewise.
* g++.old-deja/g++.other/sizeof4.C: Likewise.
Index: gcc/cp/cp-tree.h
===
--- gcc/cp/cp-tree.h(revision 279371)
+++ gcc/cp/cp-tree.h(working copy)
@@ -6657,7 +6657,7 @@ extern void init_exception_processing (void);
 extern tree expand_start_catch_block   (tree);
 extern void expand_end_catch_block (void);
 extern tree build_exc_ptr  (void);
-extern tree build_throw(tree);
+extern tree build_throw(location_t, tree);
 extern int nothrow_libfn_p (const_tree);
 extern void check_handlers (tree);
 extern tree finish_noexcept_expr   (tree, tsubst_flags_t);
@@ -6674,7 +6674,6 @@ extern tree begin_eh_spec_block   (void);
 extern void finish_eh_spec_block   (tree, tree);
 extern tree build_eh_type_type (tree);
 extern tree cp_protect_cleanup_actions (void);
-extern tree create_try_catch_expr   (tree, tree);
 extern tree template_parms_to_args

[C++ PATCH] PR c++/91165 - verify_gimple ICE with cached constexpr.

2019-12-16 Thread Jason Merrill
It seems we need to unshare even non-CONSTRUCTOR expressions that we are
going to stick in the constexpr_call_table, so we don't end up sharing the
same e.g. ADDR_EXPR between two different functions.  I now think I
understand why unsharing CONSTRUCTOR arguments was improving memory
performance: separating the arguments from the caller function allows the
caller function to be GC'd better.  But it occurs to me that we don't need
to unshare until we decide that we're evaluating and caching this call, so
we can avoid the CONSTRUCTOR unshare/free pair for tentative arguments.
Freeing the tentative TREE_VEC still seems worth doing, so free_bindings
isn't going away entirely.

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

* constexpr.c (cxx_bind_parameters_in_call): Don't unshare.
(cxx_eval_call_expression): Unshare all args if we're caching.
---
 gcc/cp/constexpr.c| 32 +--
 .../g++.dg/cpp0x/constexpr-string2.C  | 13 
 2 files changed, 29 insertions(+), 16 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/constexpr-string2.C

diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
index 19e09c74760..f3f03e7d621 100644
--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -1441,9 +1441,6 @@ cxx_bind_parameters_in_call (const constexpr_ctx *ctx, 
tree t,
 
   if (!*non_constant_p)
{
- /* Unsharing here isn't necessary for correctness, but it
-significantly improves memory performance for some reason.  */
- arg = unshare_constructor (arg);
  /* Make sure the binding has the same type as the parm.  But
 only for constant args.  */
  if (!TYPE_REF_P (type))
@@ -1959,19 +1956,11 @@ cxx_eval_call_expression (const constexpr_ctx *ctx, 
tree t,
  this function exits.  */
   class free_bindings
   {
+tree *bindings;
   public:
-tree 
-bool do_free;
-free_bindings (tree ): bindings (b), do_free(true) { }
-void preserve () { do_free = false; }
-~free_bindings () {
-  if (do_free)
-   {
- for (int i = 0; i < TREE_VEC_LENGTH (bindings); ++i)
-   free_constructor (TREE_VEC_ELT (bindings, i));
- ggc_free (bindings);
-   }
-}
+free_bindings (tree ): bindings () { }
+~free_bindings () { if (bindings) ggc_free (*bindings); }
+void preserve () { bindings = NULL; }
   } fb (new_call.bindings);
 
   if (*non_constant_p)
@@ -2074,7 +2063,18 @@ cxx_eval_call_expression (const constexpr_ctx *ctx, tree 
t,
  for (int i = 0; i < TREE_VEC_LENGTH (bound); ++i)
{
  tree arg = TREE_VEC_ELT (bound, i);
- /* Don't share a CONSTRUCTOR that might be changed.  */
+ if (entry)
+   {
+ /* Unshare args going into the hash table to separate them
+from the caller's context, for better GC and to avoid
+problems with verify_gimple.  */
+ arg = unshare_expr (arg);
+ TREE_VEC_ELT (bound, i) = arg;
+   }
+ /* Don't share a CONSTRUCTOR that might be changed.  This is not
+redundant with the unshare just above; we also don't want to
+change the argument values in the hash table.  XXX Could we
+unshare lazily in cxx_eval_store_expression?  */
  arg = unshare_constructor (arg);
  if (TREE_CODE (arg) == CONSTRUCTOR)
vec_safe_push (ctors, arg);
diff --git a/gcc/testsuite/g++.dg/cpp0x/constexpr-string2.C 
b/gcc/testsuite/g++.dg/cpp0x/constexpr-string2.C
new file mode 100644
index 000..a64d815a7ba
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/constexpr-string2.C
@@ -0,0 +1,13 @@
+// PR c++/91165
+// { dg-do compile { target c++11 } }
+// { dg-additional-options -O }
+
+template  constexpr T bar (T c) { return c; }
+template  struct S {
+  T f;
+  U g;
+};
+template 
+constexpr S foo (T &, U h) { return S {c, bar (h)}; }
+void baz (int a) { foo (a, ""); }
+void qux () { foo (0, ""); }

base-commit: b82dc579862c8c67e7781af89be3391ad1cee28a
-- 
2.18.1



Re: [PATCH][RFC] Introduce BIT_FIELD_INSERT

2019-12-16 Thread Andrew Pinski
On Mon, Dec 16, 2019 at 6:32 PM Andrew Pinski  wrote:
>
> On Thu, Nov 15, 2018 at 12:31 AM Richard Biener  wrote:
> >
> > On Thu, 15 Nov 2018, Richard Biener wrote:
> >
> > > On Wed, 14 Nov 2018, Andrew Pinski wrote:
> > >
> > > > On Fri, May 13, 2016 at 3:51 AM Richard Biener  
> > > > wrote:
> > > > >
> > > > >
> > > > > The following patch adds BIT_FIELD_INSERT, an operation to
> > > > > facilitate doing bitfield inserts on registers (as opposed
> > > > > to currently where we'd have a BIT_FIELD_REF store).
> > > > >
> > > > > Originally this was developed as part of bitfield lowering
> > > > > where bitfield stores were lowered into read-modify-write
> > > > > cycles and the modify part, instead of doing shifting and masking,
> > > > > be kept in a more high-level form to ease combining them.
> > > > >
> > > > > A second use case (the above is still valid) is vector element
> > > > > inserts which we currently can only do via memory or
> > > > > by extracting all components and re-building the vector using
> > > > > a CONSTRUCTOR.  For this second use case I added code
> > > > > re-writing the BIT_FIELD_REF stores the C family FEs produce
> > > > > into BIT_FIELD_INSERT when update-address-taken can otherwise
> > > > > re-write a decl into SSA form (the testcase shows we miss
> > > > > a similar opportunity with the MEM_REF form of a vector insert,
> > > > > I plan to fix that for the final submission).
> > > > >
> > > > > One speciality of BIT_FIELD_INSERT as opposed to BIT_FIELD_REF
> > > > > is that the size of the insertion is given implicitely via the
> > > > > type size/precision of the value to insert.  That avoids
> > > > > introducing ways to have quaternary ops in folding and GIMPLE stmts.
> > > > >
> > > > > Bootstrapped and tested on x86_64-unknown-linux-gnu.
> > > > >
> > > > > Richard.
> > > > >
> > > > > 2011-06-16  Richard Guenther  
> > > > >
> > > > > PR tree-optimization/29756
> > > > > * tree.def (BIT_FIELD_INSERT): New tcc_expression tree code.
> > > > > * expr.c (expand_expr_real_2): Handle BIT_FIELD_INSERT.
> > > > > * fold-const.c (operand_equal_p): Likewise.
> > > > > (fold_ternary_loc): Add constant folding of BIT_FIELD_INSERT.
> > > > > * gimplify.c (gimplify_expr): Handle BIT_FIELD_INSERT.
> > > > > * tree-inline.c (estimate_operator_cost): Likewise.
> > > > > * tree-pretty-print.c (dump_generic_node): Likewise.
> > > > > * tree-ssa-operands.c (get_expr_operands): Likewise.
> > > > > * cfgexpand.c (expand_debug_expr): Likewise.
> > > > > * gimple-pretty-print.c (dump_ternary_rhs): Likewise.
> > > > > * gimple.c (get_gimple_rhs_num_ops): Handle BIT_FIELD_INSERT.
> > > > > * tree-cfg.c (verify_gimple_assign_ternary): Verify 
> > > > > BIT_FIELD_INSERT.
> > > > >
> > > > > * tree-ssa.c (non_rewritable_lvalue_p): We can rewrite
> > > > > vector inserts using BIT_FIELD_REF on the lhs.
> > > > > (execute_update_addresses_taken): Do it.
> > > > >
> > > > > * gcc.dg/tree-ssa/vector-6.c: New testcase.
> > > > >
> > > > > Index: trunk/gcc/expr.c
> > > > > ===
> > > > > *** trunk.orig/gcc/expr.c   2016-05-12 13:40:30.704262951 +0200
> > > > > --- trunk/gcc/expr.c2016-05-12 15:40:32.481225744 +0200
> > > > > *** expand_expr_real_2 (sepops ops, rtx targ
> > > > > *** 9358,9363 
> > > > > --- 9358,9380 
> > > > > target = expand_vec_cond_expr (type, treeop0, treeop1, 
> > > > > treeop2, target);
> > > > > return target;
> > > > >
> > > > > + case BIT_FIELD_INSERT:
> > > > > +   {
> > > > > +   unsigned bitpos = tree_to_uhwi (treeop2);
> > > > > +   unsigned bitsize;
> > > > > +   if (INTEGRAL_TYPE_P (TREE_TYPE (treeop1)))
> > > > > + bitsize = TYPE_PRECISION (TREE_TYPE (treeop1));
> > > > > +   else
> > > > > + bitsize = tree_to_uhwi (TYPE_SIZE (TREE_TYPE (treeop1)));
> > > > > +   rtx op0 = expand_normal (treeop0);
> > > > > +   rtx op1 = expand_normal (treeop1);
> > > > > +   rtx dst = gen_reg_rtx (mode);
> > > > > +   emit_move_insn (dst, op0);
> > > > > +   store_bit_field (dst, bitsize, bitpos, 0, 0,
> > > > > +TYPE_MODE (TREE_TYPE (treeop1)), op1, false);
> > > > > +   return dst;
> > > > > +   }
> > > > > +
> > > > >   default:
> > > > > gcc_unreachable ();
> > > > >   }
> > > > > Index: trunk/gcc/fold-const.c
> > > > > ===
> > > > > *** trunk.orig/gcc/fold-const.c 2016-05-12 13:40:30.704262951 +0200
> > > > > --- trunk/gcc/fold-const.c  2016-05-13 09:41:13.509812127 +0200
> > > > > *** operand_equal_p (const_tree arg0, const_
> > > > > *** 3163,3168 
> > > > > --- 3163,3169 
> > > > >
> > > > > case VEC_COND_EXPR:
> > > > > case 

Re: [C++ PATCH] Make same_type_p return false for gnu_vector_type_p differences (PR 92789)

2019-12-16 Thread Jason Merrill

On 12/12/19 10:16 AM, Richard Sandiford wrote:

As Jason pointed out in the review of the C++ gnu_vector_type_p patch:

 https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00173.html

the real fix for the XFAILs in acle/general-c++/gnu_vectors_*.C is to
make same_type_p return false for two types if one is gnu_vector_type_p
and the other isn't.  This patch does that and fixes the fallout in the
way Jason suggested above.

I'd said at the time that some of the tests require:

   /* If the constructor already has the array type, it's been through
 digest_init, so we shouldn't try to do anything more.  */
   bool digested = same_type_p (atype, TREE_TYPE (init));

(build_vec_init) to be true for gnu vectors built from non-gnu vectors.
I can no longer reproduce that, maybe because my original same_type_p
change was bogus or because something in the later sizeless type
support made it moot (or something else :-)).

This means that sve-sizeless-2.C (the length-specific test) now reports
some errors for comparisons and pointer differences that sve-sizeless-1.C
(the length-agnostic test) already had.  I think requiring a cast is OK
for those cases, since there's no reason to mix GNU and non-GNU versions
of the same vector in the same object.  Even -flax-vector-conversions
would require a cast for different vector types here, for both C and C++.

same_type_p had:

   else if (strict == COMPARE_STRUCTURAL)
 return structural_comptypes (t1, t2, COMPARE_STRICT);
   else
 return structural_comptypes (t1, t2, strict);

Since structural_comptypes ignored the COMPARE_STRUCTURAL bit of "strict"
before the patch, the "else if" was harmless but AFAICT unnecessary.


The comment in cp-tree.h has

#define COMPARE_STRUCTURAL8 /* The comparison is intended to be
   structural. The actual comparison   
   will be identical to
   COMPARE_STRICT.  */


So introducing differences between COMPARE_STRUCTURAL and COMPARE_STRICT 
other than that the first always calls structural_comptypes and the 
second sometimes compares TYPE_CANONICAL instead is to be avoided.


Do you want to use vector_types_convertible_p in similar_type_p?

Jason



[PING^2][PATCH v3] Add `--with-toolexeclibdir=' configuration option

2019-12-16 Thread Maciej W. Rozycki
On Mon, 2 Dec 2019, Maciej W. Rozycki wrote:

> Provide means, in the form of a `--with-toolexeclibdir=' configuration 
> option, to override the default installation directory for target 
> libraries, otherwise known as $toolexeclibdir.  This is so that it is 
> possible to get newly-built libraries, particularly the shared ones, 
> installed in a common place, so that they can be readily used by the 
> target system as their host libraries, possibly over NFS, without a need 
> to manually copy them over from the currently hardcoded location they 
> would otherwise be installed in.

 Ping for:



  Maciej


[committed] avoid assuming array indices are zero-based (PR 92952)

2019-12-16 Thread Martin Sebor

The gfortran.dg/lto/pr87689 test fails as a result of
a -Wstringop-overflow warning.  The warning is only enabled for
the C family of languages and LTO but it looks like LTO obviates
this distinction.  Last week's enhancement to compute_objsize
seems like the most likely culprit, although the root cause of
the problem -- assuming array indices begin with zero, was
probably latent before then.  In r279445 I have committed
the attached patch to remove the assumption that array indices
are zero-based to let the test pass again.

Martin
PR middle-end/92952 - gfortran.dg/lto/pr87689 FAILs

gcc/ChangeLog:

	PR middle-end/92952
	* builtins.c (compute_objsize): Adjust offset by the array low bound.

Index: gcc/builtins.c
===
--- gcc/builtins.c	(revision 279443)
+++ gcc/builtins.c	(working copy)
@@ -3999,6 +3999,16 @@ compute_objsize (tree dest, int ostype, tree *pdec
 	 above.  */
 	  if (TREE_CODE (dest) == ARRAY_REF)
 	{
+	  tree lowbnd = array_ref_low_bound (dest);
+	  if (!integer_zerop (lowbnd) && tree_fits_uhwi_p (lowbnd))
+		{
+		  /* Adjust the offset by the low bound of the array
+		 domain (normally zero but 1 in Fortran).  */
+		  unsigned HOST_WIDE_INT lb = tree_to_uhwi (lowbnd);
+		  offrng[0] -= lb;
+		  offrng[1] -= lb;
+		}
+
 	  /* Convert the array index into a byte offset.  */
 	  tree eltype = TREE_TYPE (dest);
 	  tree tpsize = TYPE_SIZE_UNIT (eltype);


Re: [committed] avoid assuming array indices are zero-based (PR 92952)

2019-12-16 Thread Jakub Jelinek
On Mon, Dec 16, 2019 at 03:28:29PM -0700, Martin Sebor wrote:
> PR middle-end/92952 - gfortran.dg/lto/pr87689 FAILs
> 
> gcc/ChangeLog:
> 
>   PR middle-end/92952
>   * builtins.c (compute_objsize): Adjust offset by the array low bound.
> 
> Index: gcc/builtins.c
> ===
> --- gcc/builtins.c(revision 279443)
> +++ gcc/builtins.c(working copy)
> @@ -3999,6 +3999,16 @@ compute_objsize (tree dest, int ostype, tree *pdec
>above.  */
> if (TREE_CODE (dest) == ARRAY_REF)
>   {
> +   tree lowbnd = array_ref_low_bound (dest);
> +   if (!integer_zerop (lowbnd) && tree_fits_uhwi_p (lowbnd))
> + {
> +   /* Adjust the offset by the low bound of the array
> +  domain (normally zero but 1 in Fortran).  */
> +   unsigned HOST_WIDE_INT lb = tree_to_uhwi (lowbnd);
> +   offrng[0] -= lb;
> +   offrng[1] -= lb;
> + }

I don't understand why uhwi is used.  offrng is an array of wide_int with
precision of sizetype, so why not instead:
  if (!integer_zerop (lowbnd) && TREE_CODE (lowbnd) == INTEGER_CST)
{
  /* Adjust the offset by the low bound of the array
 domain (normally zero but 1 in Fortran).  */
  wide_int lb = wi::to_wide (lowbnd, sizprec);
  offrng[0] -= lb;
  offrng[1] -= lb;
}
?

Jakub



Re: [PATCH] Add OpenACC 2.6 `acc_get_property' support

2019-12-16 Thread Thomas Schwinge
Hi Frederik!

On 2019-11-14T16:35:31+0100, Frederik Harwath  wrote:
> this patch implements OpenACC 2.6 "acc_get_property" and related functions.

I'm attaching a version rebased on top of current GCC trunk, as well as
an incremental patch; please review these changes, and merge into yours.


> There is no AMD GCN support yet. This will be added later on.

ACK, just to note that there now is a 'libgomp/plugin/plugin-gcn.c' that
at least needs to get a stub implementation (can mostly copy from
'libgomp/plugin/plugin-hsa.c'?) as otherwise the build will fail.


Tobias has generally reviewed the Fortran bits, correct?


As I mentioned before ("thinking aloud"):

| Before Frederik starts working on integrating this into GCC trunk, do you
| (Jakub) agree with the libgomp plugin interface changes as implemented by
| Maciej?  For example, top-level 'GOMP_OFFLOAD_get_property' function in
| 'struct gomp_device_descr' instead of stuffing this into its
| 'acc_dispatch_t openacc'.  (I never understood why the OpenACC functions
| need to be segregated like they are.)

Jakub didn't answer, but I now myself decided that we should group this
with the other OpenACC libgomp-plugin functions, as this interface is
defined in terms of OpenACC-specific stuff such as 'acc_device_t'.
Frederik, please work on that, also try to move function definitions etc.
into appropriate places in case they aren't; ask if you need help.


> Add generic support for the OpenACC 2.6 `acc_get_property' and
> `acc_get_property_string' routines, as well as full handlers for the
> host and the NVPTX offload targets and minimal handlers for the HSA
> and Intel MIC offload targets.
>
> Included are C/C++ and Fortran tests that, in particular, print
> the property values for acc_property_vendor, acc_property_memory,
> acc_property_free_memory, acc_property_name, and acc_property_driver.
> The output looks as follows:
>
> Vendor: GNU
> Name: GOMP
> Total memory: 0
> Free memory: 0
> Driver: 1.0
>
> with the host driver (where the memory related properties are not
> supported for the host device and yield 0, conforming to the standard)
> and output like:
>
> OpenACC vendor: Nvidia
> OpenACC total memory: 12651462656
> OpenACC free memory: 12202737664
> OpenACC name: TITAN V
> OpenACC driver: CUDA Driver 9.1
>
> with the NVPTX driver.

That needs to be updated.


>  .../acc-get-property-2.c  |  68 +
>  .../acc-get-property-3.c  |  19 +++
>  .../acc-get-property-aux.c|  60 
>  .../acc-get-property.c|  75 ++
>  .../libgomp.oacc-fortran/acc-get-property.f90 |  80 ++

Please name all these 'acc_get_property*', which is the name of the
interface tested.


> --- a/include/gomp-constants.h
> +++ b/include/gomp-constants.h
> @@ -178,6 +178,20 @@ enum gomp_map_kind
>  
>  #define GOMP_DEVICE_ICV  -1
>  #define GOMP_DEVICE_HOST_FALLBACK-2
> +#define GOMP_DEVICE_CURRENT  -3

As I mentioned before ("thinking aloud"):

| This is used for 'acc_device_current', relevant only for
| 'acc_get_property', to return "the value of the property for the current
| device".  This [now has a] special (negative?) value
| [...], so that when additional real device types are added
| later on, we can just add them with increasing numbers, and keep the
| scanning code simple.

Not should if this should be grouped with 'GOMP_DEVICE_ICV',
'GOMP_DEVICE_HOST_FALLBACK', for it is not related to there.

Should this actually get value '-1' instead of '-3'?  Or, is the OpenACC
'acc_device_t' code already paying special attention to negative values
'-1', '-2'?  (I don't think so.)

| (Use of 'acc_device_current' as an argument to other functions taking an
| 'acc_device_t' is undefined, and should be rejected with 'gomp_fatal'?)

That should now be implemented; r278937 "Validate acc_device_t uses".

| Also, 'acc_device_current' is a libgomp-internal thing (doesn't interface
| with the compiler proper), so strictly speaking 'GOMP_DEVICE_CURRENT'
| isn't needed in 'include/gomp-constants.h'.  But probably still a good
| idea to list it there, in this canonical place, to keep the several lists
| of device types coherent.

I still wonder about that...  ;-)

| (I have not checked how 'acc_device_current' is actually implemented in
| the following.)

> +/* Device property codes.  Keep in sync with
> +   libgomp/{openacc.h,openacc.f90,openacc_lib.h}:acc_device_property_t

| Same thing, libgomp-internal, not sure whether to list these here?

> +   as well as libgomp/libgomp-plugin.h.  */

(Not sure why 'libgomp/libgomp-plugin.h' is relevant here?)

> +/* Start from 1 to catch uninitialized use.  */

| Hmm, not sure about that either.  Don't think we're generally doing that?
|
| (But I see PGI have 'acc_property_none = 0', oh well.)

> +#define GOMP_DEVICE_PROPERTY_MEMORY  1
> +#define GOMP_DEVICE_PROPERTY_FREE_MEMORY 2
> +#define 

Re: [committed] avoid assuming array indices are zero-based (PR 92952)

2019-12-16 Thread Martin Sebor

On 12/16/19 3:44 PM, Jakub Jelinek wrote:

On Mon, Dec 16, 2019 at 03:28:29PM -0700, Martin Sebor wrote:

PR middle-end/92952 - gfortran.dg/lto/pr87689 FAILs

gcc/ChangeLog:

PR middle-end/92952
* builtins.c (compute_objsize): Adjust offset by the array low bound.

Index: gcc/builtins.c
===
--- gcc/builtins.c  (revision 279443)
+++ gcc/builtins.c  (working copy)
@@ -3999,6 +3999,16 @@ compute_objsize (tree dest, int ostype, tree *pdec
 above.  */
  if (TREE_CODE (dest) == ARRAY_REF)
{
+ tree lowbnd = array_ref_low_bound (dest);
+ if (!integer_zerop (lowbnd) && tree_fits_uhwi_p (lowbnd))
+   {
+ /* Adjust the offset by the low bound of the array
+domain (normally zero but 1 in Fortran).  */
+ unsigned HOST_WIDE_INT lb = tree_to_uhwi (lowbnd);
+ offrng[0] -= lb;
+ offrng[1] -= lb;
+   }


I don't understand why uhwi is used.  offrng is an array of wide_int with
precision of sizetype, so why not instead:
  if (!integer_zerop (lowbnd) && TREE_CODE (lowbnd) == INTEGER_CST)
{
  /* Adjust the offset by the low bound of the array
 domain (normally zero but 1 in Fortran).  */
  wide_int lb = wi::to_wide (lowbnd, sizprec);
  offrng[0] -= lb;
  offrng[1] -= lb;
}
?


I don't see what difference it makes.  They should both do the same
thing.  If you just prefer your alternative, feel free to change it.

Martin


Re: [PATCH][RFC] Introduce BIT_FIELD_INSERT

2019-12-16 Thread Andrew Pinski
On Thu, Nov 15, 2018 at 12:31 AM Richard Biener  wrote:
>
> On Thu, 15 Nov 2018, Richard Biener wrote:
>
> > On Wed, 14 Nov 2018, Andrew Pinski wrote:
> >
> > > On Fri, May 13, 2016 at 3:51 AM Richard Biener  wrote:
> > > >
> > > >
> > > > The following patch adds BIT_FIELD_INSERT, an operation to
> > > > facilitate doing bitfield inserts on registers (as opposed
> > > > to currently where we'd have a BIT_FIELD_REF store).
> > > >
> > > > Originally this was developed as part of bitfield lowering
> > > > where bitfield stores were lowered into read-modify-write
> > > > cycles and the modify part, instead of doing shifting and masking,
> > > > be kept in a more high-level form to ease combining them.
> > > >
> > > > A second use case (the above is still valid) is vector element
> > > > inserts which we currently can only do via memory or
> > > > by extracting all components and re-building the vector using
> > > > a CONSTRUCTOR.  For this second use case I added code
> > > > re-writing the BIT_FIELD_REF stores the C family FEs produce
> > > > into BIT_FIELD_INSERT when update-address-taken can otherwise
> > > > re-write a decl into SSA form (the testcase shows we miss
> > > > a similar opportunity with the MEM_REF form of a vector insert,
> > > > I plan to fix that for the final submission).
> > > >
> > > > One speciality of BIT_FIELD_INSERT as opposed to BIT_FIELD_REF
> > > > is that the size of the insertion is given implicitely via the
> > > > type size/precision of the value to insert.  That avoids
> > > > introducing ways to have quaternary ops in folding and GIMPLE stmts.
> > > >
> > > > Bootstrapped and tested on x86_64-unknown-linux-gnu.
> > > >
> > > > Richard.
> > > >
> > > > 2011-06-16  Richard Guenther  
> > > >
> > > > PR tree-optimization/29756
> > > > * tree.def (BIT_FIELD_INSERT): New tcc_expression tree code.
> > > > * expr.c (expand_expr_real_2): Handle BIT_FIELD_INSERT.
> > > > * fold-const.c (operand_equal_p): Likewise.
> > > > (fold_ternary_loc): Add constant folding of BIT_FIELD_INSERT.
> > > > * gimplify.c (gimplify_expr): Handle BIT_FIELD_INSERT.
> > > > * tree-inline.c (estimate_operator_cost): Likewise.
> > > > * tree-pretty-print.c (dump_generic_node): Likewise.
> > > > * tree-ssa-operands.c (get_expr_operands): Likewise.
> > > > * cfgexpand.c (expand_debug_expr): Likewise.
> > > > * gimple-pretty-print.c (dump_ternary_rhs): Likewise.
> > > > * gimple.c (get_gimple_rhs_num_ops): Handle BIT_FIELD_INSERT.
> > > > * tree-cfg.c (verify_gimple_assign_ternary): Verify 
> > > > BIT_FIELD_INSERT.
> > > >
> > > > * tree-ssa.c (non_rewritable_lvalue_p): We can rewrite
> > > > vector inserts using BIT_FIELD_REF on the lhs.
> > > > (execute_update_addresses_taken): Do it.
> > > >
> > > > * gcc.dg/tree-ssa/vector-6.c: New testcase.
> > > >
> > > > Index: trunk/gcc/expr.c
> > > > ===
> > > > *** trunk.orig/gcc/expr.c   2016-05-12 13:40:30.704262951 +0200
> > > > --- trunk/gcc/expr.c2016-05-12 15:40:32.481225744 +0200
> > > > *** expand_expr_real_2 (sepops ops, rtx targ
> > > > *** 9358,9363 
> > > > --- 9358,9380 
> > > > target = expand_vec_cond_expr (type, treeop0, treeop1, treeop2, 
> > > > target);
> > > > return target;
> > > >
> > > > + case BIT_FIELD_INSERT:
> > > > +   {
> > > > +   unsigned bitpos = tree_to_uhwi (treeop2);
> > > > +   unsigned bitsize;
> > > > +   if (INTEGRAL_TYPE_P (TREE_TYPE (treeop1)))
> > > > + bitsize = TYPE_PRECISION (TREE_TYPE (treeop1));
> > > > +   else
> > > > + bitsize = tree_to_uhwi (TYPE_SIZE (TREE_TYPE (treeop1)));
> > > > +   rtx op0 = expand_normal (treeop0);
> > > > +   rtx op1 = expand_normal (treeop1);
> > > > +   rtx dst = gen_reg_rtx (mode);
> > > > +   emit_move_insn (dst, op0);
> > > > +   store_bit_field (dst, bitsize, bitpos, 0, 0,
> > > > +TYPE_MODE (TREE_TYPE (treeop1)), op1, false);
> > > > +   return dst;
> > > > +   }
> > > > +
> > > >   default:
> > > > gcc_unreachable ();
> > > >   }
> > > > Index: trunk/gcc/fold-const.c
> > > > ===
> > > > *** trunk.orig/gcc/fold-const.c 2016-05-12 13:40:30.704262951 +0200
> > > > --- trunk/gcc/fold-const.c  2016-05-13 09:41:13.509812127 +0200
> > > > *** operand_equal_p (const_tree arg0, const_
> > > > *** 3163,3168 
> > > > --- 3163,3169 
> > > >
> > > > case VEC_COND_EXPR:
> > > > case DOT_PROD_EXPR:
> > > > +   case BIT_FIELD_INSERT:
> > > >   return OP_SAME (0) && OP_SAME (1) && OP_SAME (2);
> > > >
> > > > default:
> > > > *** fold_ternary_loc (location_t loc, enum t
> > > > *** 11870,11875 
> > > > --- 

Re: [PATCH] add -Wmismatched-tags (PR 61339)

2019-12-16 Thread Jason Merrill

On 12/9/19 7:29 PM, Martin Sebor wrote:

Just a few nits:


+/* A mapping between a TYPE_DECL for a class and the class_decl_loc_t
+   description above.  */
+typedef hash_map class_to_loc_map_t;
+static class_to_loc_map_t class2loc;


I think we can make these members of class_decl_loc_t, now that we 
aren't marking them with GTY.



+  class_decl_loc_t *rdl = class2loc.get (type_decl);
+  if (!rdl)
+{
+  tree type = TREE_TYPE (type_decl);
+  if (def_p || !COMPLETE_TYPE_P (type))
+   {
+ /* TYPE_DECL is the first declaration or definition of the type
+(outside precompiled headers -- see below).  Just create
+a new entry for it.  */
+ class2loc.put (type_decl, class_decl_loc_t (class_key, false, def_p));
+ return;
+   }
+
+  /* TYPE was previously defined in some unknown precompiled hdeader.
+Simply add a record of its definition at an unknown location and
+proceed below to add a reference to it at the current location.
+(Declarations in precompiled headers that are not definitions
+are ignored.)  */
+  tag_types def_key
+   = CLASSTYPE_DECLARED_CLASS (type) ? class_type : record_type;
+  location_t def_loc = DECL_SOURCE_LOCATION (type_decl);
+  rdl = _or_insert (type_decl);
+  *rdl = class_decl_loc_t (def_key, false, true, def_loc);
+}


It seems that you could use get_or_insert at the top, since you always 
end up creating an element if there wasn't one already.



+  /* A prior declaration of TYPE_DECL has been seen.  */
+
+  if (rdl->idxdef != UINT_MAX && rdl->def_class_key == class_key)
+/* Do nothing if the class-key in this declaration matches
+   the definition.  */
+return;

...

I still think that the rest of this function could be a non-static 
member function to avoid so many "rdl->".


Jason



Re: 'find_group_last' (was: [PATCH] OpenACC reference count overhaul)

2019-12-16 Thread Julian Brown
On Sat, 14 Dec 2019 00:19:04 +
Julian Brown  wrote:

> On Fri, 13 Dec 2019 16:25:25 +0100
> Thomas Schwinge  wrote:
> 
> > Hi Julian!
> > 
> > On 2019-10-29T12:15:01+, Julian Brown 
> > wrote:  
> > >  static int
> > > -find_pointer (int pos, size_t mapnum, unsigned short *kinds)
> > > +find_group_last (int pos, size_t mapnum, unsigned short *kinds)
> > >  {
> > > -  if (pos + 1 >= mapnum)
> > > -return 0;
> > > +  unsigned char kind0 = kinds[pos] & 0xff;
> > > +  int first_pos = pos, last_pos = pos;
> > >  
> > > -  unsigned char kind = kinds[pos+1] & 0xff;
> > > -
> > > -  if (kind == GOMP_MAP_TO_PSET)
> > > -return 3;
> > > -  else if (kind == GOMP_MAP_POINTER)
> > > -return 2;
> > > +  if (kind0 == GOMP_MAP_TO_PSET)
> > > +{
> > > +  while (pos + 1 < mapnum && (kinds[pos + 1] & 0xff) ==
> > > GOMP_MAP_POINTER)
> > > + last_pos = ++pos;
> > > +  /* We expect at least one GOMP_MAP_POINTER after a
> > > GOMP_MAP_TO_PSET.  */
> > > +  assert (last_pos > first_pos);
> > > +}
> > > +  else
> > > +{
> > > +  /* GOMP_MAP_ALWAYS_POINTER can only appear directly after
> > > some other
> > > +  mapping.  */
> > > +  if (pos + 1 < mapnum
> > > +   && (kinds[pos + 1] & 0xff) == GOMP_MAP_ALWAYS_POINTER)
> > > + return pos + 1;
> > > +
> > > +  /* We can have one or several GOMP_MAP_POINTER mappings
> > > after a to/from
> > > +  (etc.) mapping.  */
> > > +  while (pos + 1 < mapnum && (kinds[pos + 1] & 0xff) ==
> > > GOMP_MAP_POINTER)
> > > + last_pos = ++pos;
> > > +}
> > >  
> > > -  return 0;
> > > +  return last_pos;
> > >  }
> > 
> > So I ran a simple experiment where I did:
> > 
> > assert (find_group_last (i, mapnum, kinds) == i + pointer);
> > 
> > ... where 'pointer' is the current 'find_pointer' function.  (That
> > is, compare that the old and new way are doing the same things,
> > given the current GCC code generation/test cases.)
> > 
> > This 'assert' triggers for a few test cases:
> > 'libgomp.oacc-fortran/allocatable-array-1.f90',
> > 'libgomp.oacc-fortran/data-2.f90',
> > 'libgomp.oacc-fortran/data-3.f90',
> > 'libgomp.oacc-fortran/data-4-2.f90',
> > 'libgomp.oacc-fortran/data-4.f90',
> > 'libgomp.oacc-fortran/data-5.f90', 'libgomp.oacc-fortran/if-1.f90',
> > 'libgomp.oacc-fortran/optional-data-enter-exit.f90'.  (Maybe those
> > are the only ones actually using that stuff?)
> > 
> > I looked into the first one
> > ('libgomp.oacc-fortran/allocatable-array-1.f90'), and for:
> > 
> > integer, parameter :: n = 40
> > integer, allocatable :: ar(:,:,:)
> > 
> > allocate (ar(1:n,0:n-1,0:n-1))
> > !$acc enter data copyin (ar)
> > 
> > ... found:
> > 
> > (gdb) print mapnum
> > $2 = 3
> > (gdb) print kinds[0]
> > $3 = 1 // GOMP_MAP_TO
> > (gdb) print kinds[1]
> > $4 = 773
> > (gdb) print kinds[1] & 0xff
> > $5 = 5 // GOMP_MAP_TO_PSET
> > (gdb) print kinds[2]
> > $6 = 772
> > (gdb) print kinds[2] & 0xff
> > $7 = 4 // GOMP_MAP_POINTER
> > 
> > Current behavior: 'find_pointer (0, mapnum, kinds) == 3', so all
> > three get mapped as one group.
> > 
> > New behavior: 'find_group_last (0, mapnum, kinds) == 0', so the
> > 'GOMP_MAP_TO' gets mapped alone.  Then, 'find_group_last (1, mapnum,
> > kinds) == 2', so the 'GOMP_MAP_TO_PSET', 'GOMP_MAP_POINTER' get
> > mapped as one group.
> > 
> > Is that intentional?  
> 
> Yes. In a previous iteration of the refcount overhaul patch, we had
> the "magic" code fragment:
> 
> > + for (int j = 0; j < 2; j++)  
> > +   gomp_map_vars_async (acc_dev, aq,
> > +(j == 0 || pointer == 2) ?
> > 1 : 2,
> > +[i + j], NULL,
> > +[i + j], [i + j],
> > true,
> > +
> > GOMP_MAP_VARS_OPENACC_ENTER_DATA);
> 
> The "pointer == 3" case here will do precisely the same thing as the
> current iteration of the patch: pass the GOMP_MAP_TO to one
> gomp_map_vars_async call, and pass the GOMP_MAP_TO_PSET +
> GOMP_MAP_POINTER as a pair in a second call.
> 
> The "pointer == 2" case (i.e. with a GOMP_MAP_TO and a
> GOMP_MAP_POINTER) will also handle the mappings separately in both the
> earlier patch iteration and this one.
> 
> That's different from the current behaviour, because we don't want all
> three mappings to be bound together. The problematic cases of doing
> so might only appear with the manual deep copy patch applied also,
> though (and/or with the refcount-checking patch applied/enabled). (I
> don't remember exactly which test cases this affected, but I can
> check.)

To follow up from this: the change in this patch is really to ensure
that reference counts are correct/consistent for *all* mappings at all
times. Contrast the behaviour described in the following comment in the
existing code (goacc_insert_pointer):

   /* ...

   Only the first mapping is considered in reference counting; the
   following ones implicitly follow suit.  */

This 

Re: [PATCH] PR C++/92739

2019-12-16 Thread Jason Merrill

On 12/2/19 9:30 AM, Andrew Sutton wrote:

Find attached.

gcc/cp/
 * parser.c (cp_parser_constraint_requires_parens): Exclude
attributes
 as postfix expressions.

 gcc/testsuite/
 * g++.dg/concepts-pr92739.C: New test.


The testcase didn't come through in this patch.


Jason



[PATCH] Fix symver attribute with LTO

2019-12-16 Thread Xi Ruoyao
Hi,
with Jan's patch commited in r278878 we can use symver attribute for functions
and variables.  The symver attribute is designed for replacing toplevel asm
statements containing ".symver" which may be removed by LTO.  Unfortunately,
a quick test shown GCC still generates buggy so file with LTO and new symver
attribute.

Two issues:

1. The symver node in symtab is marked as PREVAILING_DEF_IRONLY (no EXP) and
   then removed by LTO.
2. The actual function body implementing the symver-ed function is also marked
   as PREVAILING_DEF_IRONLY and then removed or marked as local.  So no ".globl"
   directive is outputed for it.

Both issue cause symbols with symver missing in DSO (with LTO enabled).

I modified fuse-3.9.0 code to use new symver attribute and tried to build it
with GCC trunk and LTO.  The result is a buggy DSO.  With this patch applied,
fuse-3.9.0 can be built with LTO enabled and no problem.

I'll test symver patch and this patch with more packages.

Bootstrapped/regtested x86_64-linux.  I'm not a maintainer.

gcc/ChangeLog:

2019-12-17  Xi Ruoyao  

* cgraph.h (symtab_node::used_from_object_file_p): Symver nodes are
part of DSO ABI so always used by non-LTO object files.
* ipa-visibility.c (cgraph_externally_visible_p): Functions with symver
attributes should always be visible.

Index: gcc/cgraph.h
===
--- gcc/cgraph.h(revision 279452)
+++ gcc/cgraph.h(working copy)
@@ -2682,7 +2682,7 @@ symtab_node::used_from_object_file_p (vo
 {
   if (!TREE_PUBLIC (decl) || DECL_EXTERNAL (decl))
 return false;
-  if (resolution_used_from_other_file_p (resolution))
+  if (symver || resolution_used_from_other_file_p (resolution))
 return true;
   return false;
 }
Index: gcc/ipa-visibility.c
===
--- gcc/ipa-visibility.c(revision 279452)
+++ gcc/ipa-visibility.c(working copy)
@@ -216,6 +216,8 @@ cgraph_externally_visible_p (struct cgra
 return true;
   if (lookup_attribute ("noipa", DECL_ATTRIBUTES (node->decl)))
 return true;
+  if (lookup_attribute ("symver", DECL_ATTRIBUTES (node->decl)))
+return true;
   if (TARGET_DLLIMPORT_DECL_ATTRIBUTES
   && lookup_attribute ("dllexport",
   DECL_ATTRIBUTES (node->decl)))
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University



[Committed] Fix PR92950: Wrong code emitted for movv1qi

2019-12-16 Thread Andreas Krebbel
The backend emits 16 bit memory loads for single element character
vector.  As a result the character will not be right justified in the
GPR.

gcc/ChangeLog:

2019-12-16  Andreas Krebbel  

PR target/92950
* config/s390/vector.md ("mov" for V_8): Replace lh, lhy,
and lhrl with llc.

gcc/testsuite/ChangeLog:

2019-12-16  Andreas Krebbel  

PR target/92950
* gcc.target/s390/vector/pr92950.c: New test.
---
 gcc/config/s390/vector.md | 12 --
 .../gcc.target/s390/vector/pr92950.c  | 24 +++
 2 files changed, 29 insertions(+), 7 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/s390/vector/pr92950.c

diff --git a/gcc/config/s390/vector.md b/gcc/config/s390/vector.md
index d40e310f9e7..1e591ba31b6 100644
--- a/gcc/config/s390/vector.md
+++ b/gcc/config/s390/vector.md
@@ -291,9 +291,9 @@
 ; However, this would probably be slower.
 
 (define_insn "mov"
-  [(set (match_operand:V_8 0 "nonimmediate_operand" "=v,v,d,v,R,  v,  v,  v,  
v,d,  Q,  S,  Q,  S,  d,  d,d,d,d,R,T")
-(match_operand:V_8 1 "general_operand"  " 
v,d,v,R,v,j00,jm1,jyy,jxx,d,j00,j00,jm1,jm1,j00,jm1,R,T,b,d,d"))]
-  ""
+  [(set (match_operand:V_8 0 "nonimmediate_operand" "=v,v,d,v,R,  v,  v,  v,  
v,d,  Q,  S,  Q,  S,  d,  d,d,R,T")
+(match_operand:V_8 1 "general_operand"  " 
v,d,v,R,v,j00,jm1,jyy,jxx,d,j00,j00,jm1,jm1,j00,jm1,T,d,d"))]
+  "TARGET_VX"
   "@
vlr\t%v0,%v1
vlvgb\t%v0,%1,0
@@ -311,12 +311,10 @@
mviy\t%0,-1
lhi\t%0,0
lhi\t%0,-1
-   lh\t%0,%1
-   lhy\t%0,%1
-   lhrl\t%0,%1
+   llc\t%0,%1
stc\t%1,%0
stcy\t%1,%0"
-  [(set_attr "op_type"  
"VRR,VRS,VRS,VRX,VRX,VRI,VRI,VRI,VRI,RR,SI,SIY,SI,SIY,RI,RI,RX,RXY,RIL,RX,RXY")])
+  [(set_attr "op_type"  
"VRR,VRS,VRS,VRX,VRX,VRI,VRI,VRI,VRI,RR,SI,SIY,SI,SIY,RI,RI,RXY,RX,RXY")])
 
 (define_insn "mov"
   [(set (match_operand:V_16 0 "nonimmediate_operand" "=v,v,d,v,R,  v,  v,  v,  
v,d,  Q,  Q,  d,  d,d,d,d,R,T,b")
diff --git a/gcc/testsuite/gcc.target/s390/vector/pr92950.c 
b/gcc/testsuite/gcc.target/s390/vector/pr92950.c
new file mode 100644
index 000..9c7ed127e61
--- /dev/null
+++ b/gcc/testsuite/gcc.target/s390/vector/pr92950.c
@@ -0,0 +1,24 @@
+/* { dg-do run } */
+/* { dg-options "-O3 -mzarch -march=z13 --save-temps" } */
+
+struct a {
+  int b;
+  char c;
+};
+struct a d = {1, 16};
+struct a *e = 
+
+int f = 0;
+
+int main() {
+  struct a g = {0, 0 };
+  f = 0;
+
+  for (; f <= 1; f++) {
+g = d;
+*e = g;
+  }
+
+  if (d.c != 16)
+__builtin_abort();
+}
-- 
2.23.0



[Ada] Fix couple of oversights in the implementation of AI12-0128

2019-12-16 Thread Pierre-Marie de Rodat
This fixes a couple of oversights in the implementation of the new
legality rules added to the C.6(13) clause by AI12-0128:

  1. the new code does not properly deal with an Atomic_Components
 aspect/pragma put directly on an array object declaration,

  2. the new Is_Subcomponent_Of_Atomic_Object predicate does not
 properly deal with access value prefixes in -gnatc mode.

Tested on x86_64-pc-linux-gnu, committed on trunk

2019-12-16  Eric Botcazou  

gcc/ada/

* sem_prag.adb (Atomic_Components): Remove local variable and
fix consistency issues.  Call Component_Type on the Etype of E.
(Independent_Components): Remove local variable.
* sem_util.adb (Is_Subcomponent_Of_Atomic_Object): Properly deal
with prefixes that are access values.
* gcc-interface/trans.c (atomic_acces_t): New enumeral type.
(node_is_atomic) : Test the prefix.
(node_has_volatile_full_access): Rename into...
(node_is_volatile_full_access): ...this.
(node_is_component): New predicare.
(gnat_strip_type_conversion): Delete.
(outer_atomic_access_required_p): Likewise.
(atomic_access_required_p): Rename into...
(get_atomic_access): ...this.  Implement the 3 different semantics
of Atomic and Volatile_Full_Access.
(simple_atomic_access_required_p): New predicate.
(Call_to_gnu): Remove outer_atomic_access parameter and change the
type of atomic_access parameter to atomic_acces_t.  Replace call to
atomic_access_required_p with simple_atomic_access_required_p for
the in direction and call get_atomic_access for the out direction
instead of [outer_]atomic_access_required_p.
(lhs_or_actual_p): Constify local variables.
(present_in_lhs_or_actual_p): Likewise.
(gnat_to_gnu) : Replace call to atomic_access_required_p
with simple_atomic_access_required_p.
: Likewise.
: Likewise.
: Likewise.
: Call get_atomic_access for the name instead
of [outer_]atomic_access_required_p.  Adjust call to Call_to_gnu.
: Adjust call to Call_to_gnu.
(get_controlling_type): Fix typo in comment.--- gcc/ada/gcc-interface/trans.c
+++ gcc/ada/gcc-interface/trans.c
@@ -3976,7 +3976,7 @@ Loop_Statement_to_gnu (Node_Id gnat_node)
   return gnu_result;
 }
 
-/* This page implements a form of Named Return Value optimization modelled
+/* This page implements a form of Named Return Value optimization modeled
on the C++ optimization of the same name.  The main difference is that
we disregard any semantical considerations when applying it here, the
counterpart being that we don't try to apply it to semantically loaded
@@ -4792,7 +4792,13 @@ Subprogram_Body_to_gnu (Node_Id gnat_node)
 rest_of_subprog_body_compilation (gnu_subprog_decl);
 }
 
-/* Return true if GNAT_NODE references an Atomic entity.  */
+/* The type of an atomic access.  */
+
+typedef enum { NOT_ATOMIC, SIMPLE_ATOMIC, OUTER_ATOMIC } atomic_acces_t;
+
+/* Return true if GNAT_NODE references an Atomic entity.  This is modeled on
+   the Is_Atomic_Object predicate of the front-end, but additionally handles
+   explicit dereferences.  */
 
 static bool
 node_is_atomic (Node_Id gnat_node)
@@ -4809,17 +4815,14 @@ node_is_atomic (Node_Id gnat_node)
   return Is_Atomic (gnat_entity) || Is_Atomic (Etype (gnat_entity));
 
 case N_Selected_Component:
-  gnat_entity = Entity (Selector_Name (gnat_node));
-  return Is_Atomic (gnat_entity) || Is_Atomic (Etype (gnat_entity));
+  return Is_Atomic (Etype (gnat_node))
+	 || Is_Atomic (Entity (Selector_Name (gnat_node)));
 
 case N_Indexed_Component:
-  if (Has_Atomic_Components (Etype (Prefix (gnat_node
-	return true;
-  if (Is_Entity_Name (Prefix (gnat_node))
-	  && Has_Atomic_Components (Entity (Prefix (gnat_node
-	return true;
-
-  /* ... fall through ... */
+  return Is_Atomic (Etype (gnat_node))
+	 || Has_Atomic_Components (Etype (Prefix (gnat_node)))
+	 || (Is_Entity_Name (Prefix (gnat_node))
+		 && Has_Atomic_Components (Entity (Prefix (gnat_node;
 
 case N_Explicit_Dereference:
   return Is_Atomic (Etype (gnat_node));
@@ -4831,10 +4834,12 @@ node_is_atomic (Node_Id gnat_node)
   return false;
 }
 
-/* Return true if GNAT_NODE references a Volatile_Full_Access entity.  */
+/* Return true if GNAT_NODE references a Volatile_Full_Access entity.  This is
+   modeled on the Is_VFA_Object predicate of the front-end, but additionally
+   handles explicit dereferences.  */
 
 static bool
-node_has_volatile_full_access (Node_Id gnat_node)
+node_is_volatile_full_access (Node_Id gnat_node)
 {
   Entity_Id gnat_entity;
 
@@ -4849,9 +4854,8 @@ node_has_volatile_full_access (Node_Id gnat_node)
 	 || Is_Volatile_Full_Access (Etype (gnat_entity));
 
 case N_Selected_Component:
-  gnat_entity = Entity (Selector_Name (gnat_node));
-  

[Ada] Do not set a bogus Esize on subtype built for Component_Size clause

2019-12-16 Thread Pierre-Marie de Rodat
This fixes a small glitch in the handling of Component_Size clauses:
when the component type is a biased integer type, the compiler builds
a subtype with the size prescribed by the clause, but sets it both as
the Esize and the RM_Size of this subtype.  Now this size might not be
a multiple of the storage unit, which is problematic for the Esize.

Tested on x86_64-pc-linux-gnu, committed on trunk

2019-12-16  Eric Botcazou  

gcc/ada/

* sem_ch13.adb (Analyze_Attribute_Definition_Clause): Set only
the RM_Size on the subtype built for a Component_Size clause
when the component type is a biased integer type.--- gcc/ada/sem_ch13.adb
+++ gcc/ada/sem_ch13.adb
@@ -5476,7 +5476,7 @@ package body Sem_Ch13 is
   Analyze (Decl, Suppress => All_Checks);
 
   Set_Has_Delayed_Freeze(New_Ctyp, False);
-  Set_Esize (New_Ctyp, Csize);
+  Init_Esize(New_Ctyp);
   Set_RM_Size   (New_Ctyp, Csize);
   Init_Alignment(New_Ctyp);
   Set_Is_Itype  (New_Ctyp, True);



*ping* Re: [Patch, Fortran] OpenMP/OpenACC – fix more issues with OPTIONAL

2019-12-16 Thread Tobias Burnus

Ping.

On 12/10/19 6:54 PM, Tobias Burnus wrote:
Nonallocatable, nonpointer array arguments (of assumed shape) are 
special as they get a get an array descriptor ('arg') as argument but 
create a local variable which accesses the actual data ('arg.0 = 
arg->data').


With OPTIONAL, there are/were two outstanding issues:

(A) If the argument is not present, 'arg.0' is/was never assigned to.

(B) The optional-arg-is-present check is not just 'if (arg)' but 'if 
(arg && arg->data)' as passing an unallocated 
allocatable/disassociated pointer (i.e. 'arg->data = NULL') to a 
nonpointer, nonallocatable optional dummy argument counts as absent 
argument; this affects (A).


Solution: 


Re: [patch] Guard aarch64/aapcs64 tests using abitest.S by check_weak_available

2019-12-16 Thread Andrew Pinski
On Mon, Dec 16, 2019 at 1:25 AM Olivier Hainque  wrote:
>
> Hello,
>
> Some tests from  gcc/testsuite/gcc.target/aarch64/aapcs64
> resort to the abitest.S source, which defines a few weak symbols:
>
>   ...
>   .weak   testfunc
>   .weak   testfunc_ptr
>   .weak   saved_return_address
>
> The attached patch is a proposal to prevent the execution of
> those tests in configurations where weak symbols are advertised
> as not supported.
>
> This cures a significant number of failures on VxWorks and bootstrap
> + regress tests fine on aarch64-linux.
>
> Is this ok to commit ?

Why does VxWorks not have weak symbol support when it is an elf
target?  I can understand it not having support in a loader but these
symbols should all be resolved at build time.

Thanks,
Andrew Pinski

>
> Thanks in advance!
>
> With Kind Regards,
>
> Olivier
>
> 2019-12-16  Joel Brobecker  
> Olivier Hainque  
>
> testsuite/
>
> * gcc.target/aarch64/aapcs64/aapcs64.exp: Guard tests using
> abitest.S by check_weak_available.
>


[Ada] Implement RM C.6(19) clause entirely in the front-end

2019-12-16 Thread Pierre-Marie de Rodat
This merges the implementation of the C.6(19) clause present for In Out
and Out parameters in the front-end (without warning) with that present
in gigi (with a warning), and puts the result in the front-end with a
warning.  This means that the compiler will now warn in all cases.

Tested on x86_64-pc-linux-gnu, committed on trunk

2019-12-16  Eric Botcazou  

gcc/ada/

* exp_ch6.adb (Requires_Atomic_Or_Volatile_Copy): New predicate.
(Expand_Actuals): Use it to decide whether to add call by copy
code as per the RM C.6(19) clause.
* fe.h (Is_Atomic_Object): Remove.
(Is_Volatile_Object): Likewise.
* sem_util.ads (Is_Atomic_Object): Remove WARNING note.
(Is_Volatile_Object): Likewise.
* gcc-interface/trans.c (atomic_or_volatile_copy_required_p): Delete.
(Call_to_gnu): Do not implement the  RM C.6(19) clause.--- gcc/ada/exp_ch6.adb
+++ gcc/ada/exp_ch6.adb
@@ -1287,6 +1287,10 @@ package body Exp_Ch6 is
   --  the context of a call. Now we need to complete the expansion, so we
   --  unmark the analyzed bits in all prefixes.
 
+  function Requires_Atomic_Or_Volatile_Copy return Boolean;
+  --  Returns whether a copy is required as per RM C.6(19) and gives a
+  --  warning in this case.
+
   ---
   -- Add_Call_By_Copy_Code --
   ---
@@ -1938,6 +1942,43 @@ package body Exp_Ch6 is
  end loop;
   end Reset_Packed_Prefix;
 
+  
+  --  Requires_Atomic_Or_Volatile_Copy  --
+  
+
+  function Requires_Atomic_Or_Volatile_Copy return Boolean is
+  begin
+ --  If the formal is already passed by copy, no need to do anything
+
+ if Is_By_Copy_Type (E_Formal) then
+return False;
+ end if;
+
+ --  Check for atomicity mismatch
+
+ if Is_Atomic_Object (Actual) and then not Is_Atomic (E_Formal)
+ then
+if Comes_From_Source (N) then
+   Error_Msg_N
+ ("?atomic actual passed by copy (RM C.6(19))", Actual);
+end if;
+return True;
+ end if;
+
+ --  Check for volatility mismatch
+
+ if Is_Volatile_Object (Actual) and then not Is_Volatile (E_Formal)
+ then
+if Comes_From_Source (N) then
+   Error_Msg_N
+ ("?volatile actual passed by copy (RM C.6(19))", Actual);
+end if;
+return True;
+ end if;
+
+ return False;
+  end Requires_Atomic_Or_Volatile_Copy;
+
--  Start of processing for Expand_Actuals
 
begin
@@ -2125,27 +2166,10 @@ package body Exp_Ch6 is
 then
Add_Call_By_Copy_Code;
 
---  If the actual is not a scalar and is marked for volatile
---  treatment, whereas the formal is not volatile, then pass
---  by copy unless it is a by-reference type.
+--  We may need to force a copy because of atomicity or volatility
+--  considerations.
 
---  Note: we use Is_Volatile here rather than Treat_As_Volatile,
---  because this is the enforcement of a language rule that applies
---  only to "real" volatile variables, not e.g. to the address
---  clause overlay case.
-
-elsif Is_Entity_Name (Actual)
-  and then Is_Volatile (Entity (Actual))
-  and then not Is_By_Reference_Type (E_Actual)
-  and then not Is_Scalar_Type (Etype (Entity (Actual)))
-  and then not Is_Volatile (E_Formal)
-then
-   Add_Call_By_Copy_Code;
-
-elsif Nkind (Actual) = N_Indexed_Component
-  and then Is_Entity_Name (Prefix (Actual))
-  and then Has_Volatile_Components (Entity (Prefix (Actual)))
-then
+elsif Requires_Atomic_Or_Volatile_Copy then
Add_Call_By_Copy_Code;
 
 --  Add call-by-copy code for the case of scalar out parameters
@@ -2323,6 +2347,12 @@ package body Exp_Ch6 is
 elsif Is_Possibly_Unaligned_Slice (Actual) then
Add_Call_By_Copy_Code;
 
+--  We may need to force a copy because of atomicity or volatility
+--  considerations.
+
+elsif Requires_Atomic_Or_Volatile_Copy then
+   Add_Call_By_Copy_Code;
+
 --  An unusual case: a current instance of an enclosing task can be
 --  an actual, and must be replaced by a reference to self.
 

--- gcc/ada/fe.h
+++ gcc/ada/fe.h
@@ -281,17 +281,13 @@ extern Boolean Is_OK_Static_Expression	(Node_Id);
 
 #define Defining_Entity			sem_util__defining_entity
 #define First_Actual			sem_util__first_actual
-#define Is_Atomic_Object		sem_util__is_atomic_object
 #define Is_Variable_Size_Record 	sem_util__is_variable_size_record

[Ada] Suppress unused warnings in the presence of errors

2019-12-16 Thread Pierre-Marie de Rodat
The compiler no longer warns about unused use clauses, unused
declarations, and the like, if errors were already detected. This is an
improvement, because the errors can hide the relevant uses, and thus
cause things to look "unused" when they are not.

Tested on x86_64-pc-linux-gnu, committed on trunk

2019-12-16  Bob Duff  

gcc/ada/

* errout.adb (Handle_Serious_Error): Disable the above-mentioned
warnings.--- gcc/ada/errout.adb
+++ gcc/ada/errout.adb
@@ -861,6 +861,14 @@ package body Errout is
end if;
 end;
  end if;
+
+ --  Disable warnings on unused use clauses and the like. Otherwise, an
+ --  error might hide a reference to an entity in a used package, so
+ --  after fixing the error, the use clause no longer looks like it was
+ --  unused.
+
+ Check_Unreferenced := False;
+ Check_Unreferenced_Formals := False;
   end Handle_Serious_Error;
 
--  Start of processing for Error_Msg_Internal



[Ada] Do not issue restriction violations on ignored ghost code

2019-12-16 Thread Pierre-Marie de Rodat
Ignored ghost code should only be semantically analyzed, but as it is
not contributing to any executable code, no restriction violation should
result from analyzing such code. Add protections to that effect in the
analysis of subprogram calls.

Tested on x86_64-pc-linux-gnu, committed on trunk

2019-12-16  Yannick Moy  

gcc/ada/

* exp_ch6.adb: Fix comment.
* sem_res.adb (Resolve_Call): Do not check No_Recursion
restriction or indirectly No_Secondary_Stack restriction, when
inside an ignored ghost subprogram.--- gcc/ada/exp_ch6.adb
+++ gcc/ada/exp_ch6.adb
@@ -6934,8 +6934,8 @@ package body Exp_Ch6 is
   elsif Is_Thunk (Current_Scope) and then Is_Incomplete_Type (Exptyp) then
  return;
 
-  --  A return statement from a Ghost function does not use the secondary
-  --  stack (or any other one).
+  --  A return statement from an ignored Ghost function does not use the
+  --  secondary stack (or any other one).
 
   elsif not Requires_Transient_Scope (R_Type)
 or else Is_Ignored_Ghost_Entity (Scope_Id)

--- gcc/ada/sem_res.adb
+++ gcc/ada/sem_res.adb
@@ -6675,7 +6675,9 @@ package body Sem_Res is
   --  checkable, the case of calling an immediately containing
   --  subprogram is easy to catch.
 
-  Check_Restriction (No_Recursion, N);
+  if not Is_Ignored_Ghost_Entity (Nam) then
+ Check_Restriction (No_Recursion, N);
+  end if;
 
   --  If the recursive call is to a parameterless subprogram,
   --  then even if we can't statically detect infinite
@@ -6820,9 +6822,13 @@ package body Sem_Res is
   then
  null;
 
+  --  A return statement from an ignored Ghost function does not use the
+  --  secondary stack (or any other one).
+
   elsif Expander_Active
 and then Ekind_In (Nam, E_Function, E_Subprogram_Type)
 and then Requires_Transient_Scope (Etype (Nam))
+and then not Is_Ignored_Ghost_Entity (Nam)
   then
  Establish_Transient_Scope (N, Manage_Sec_Stack => True);
 



[Ada] Validate_Access_Subprogram_Instance: check if not null types match

2019-12-16 Thread Pierre-Marie de Rodat
The Ada RM states that "For a formal access-to-subprogram subtype, the
designated profiles of the formal and the actual shall be subtype
conformant." (section 12.5.4). This requires checking if both types can
or can't be null.

Tested on x86_64-pc-linux-gnu, committed on trunk

2019-12-16  Ghjuvan Lacambre  

gcc/ada/

* sem_ch12.adb (Validate_Access_Subprogram_Instance): Add
Can_Never_Be_Null checks.--- gcc/ada/sem_ch12.adb
+++ gcc/ada/sem_ch12.adb
@@ -12303,6 +12303,12 @@ package body Sem_Ch12 is
 Error_Msg_NE
   ("actual for formal & must have convention %", Actual, Gen_T);
  end if;
+
+ if Can_Never_Be_Null (A_Gen_T) /= Can_Never_Be_Null (Act_T) then
+Error_Msg_NE
+   ("non null exclusion of actual and formal & do not match",
+   Actual, Gen_T);
+ end if;
   end Validate_Access_Subprogram_Instance;
 
   ---



[Ada] Better error message for "is null" subunit

2019-12-16 Thread Pierre-Marie de Rodat
The syntax rules do not allow a null procedure as a subunit, and the
compiler was correctly rejecting that. This patch improves the error
message.

Tested on x86_64-pc-linux-gnu, committed on trunk

2019-12-16  Bob Duff  

gcc/ada/

* sem_ch10.adb (Analyze_Subunit): Give an error if the subunit
is not a proper body. This hides the confusing "duplicate body"
message that was previously given.--- gcc/ada/sem_ch10.adb
+++ gcc/ada/sem_ch10.adb
@@ -2433,6 +2433,20 @@ package body Sem_Ch10 is
 
   Install_Elaboration_Model (Par_Unit);
 
+  --  The syntax rules require a proper body for a subprogram subunit
+
+  if Nkind (Proper_Body (Sinfo.Unit (N))) = N_Subprogram_Declaration then
+ if Null_Present (Specification (Proper_Body (Sinfo.Unit (N then
+Error_Msg_N
+  ("null procedure not allowed as subunit",
+   Proper_Body (Unit (N)));
+ else
+Error_Msg_N
+  ("subprogram declaration not allowed as subunit",
+   Defining_Unit_Name (Specification (Proper_Body (Unit (N);
+ end if;
+  end if;
+
   Analyze (Proper_Body (Unit (N)));
   Remove_Context (N);
 



[Ada] Export the Ada version through the C interface

2019-12-16 Thread Pierre-Marie de Rodat
This just exports the version of the language internally used in the
front-end of the compiler through the C interface.

Tested on x86_64-pc-linux-gnu, committed on trunk

2019-12-16  Eric Botcazou  

gcc/ada/

* fe.h (Ada_Version_Type): New typedef.
(Ada_Version): Declare.
* opt.ads (Ada_Version_Type): Add Convention C and WARNING line.
(Ada_Version): Add WARNING line.
(Exception_Mechanism_Type): Likewise.--- gcc/ada/fe.h
+++ gcc/ada/fe.h
@@ -36,7 +36,7 @@
 
"WARNING: There is a matching C declaration of this  in fe.h"
 
-   where  is either "subprogram" or "variable".
+   where  is either "subprogram" or "variable" or "type".
 
WARNING: functions taking String_Pointer parameters must abide by the rule
documented alongside the definition of String_Pointer in types.h.  */
@@ -187,6 +187,7 @@ extern Boolean In_Extended_Main_Code_Unit	(Entity_Id);
 
 /* opt: */
 
+#define Ada_Version			opt__ada_version
 #define Back_End_Inlining		opt__back_end_inlining
 #define Debug_Generated_Code		opt__debug_generated_code
 #define Exception_Extra_Info		opt__exception_extra_info
@@ -199,9 +200,14 @@ extern Boolean In_Extended_Main_Code_Unit	(Entity_Id);
 #define Suppress_Checks			opt__suppress_checks
 
 typedef enum {
+  Ada_83, Ada_95, Ada_2005, Ada_2012, Ada_2020
+} Ada_Version_Type;
+
+typedef enum {
   Front_End_SJLJ, Back_End_ZCX, Back_End_SJLJ
 } Exception_Mechanism_Type;
 
+extern Ada_Version_Type Ada_Version;
 extern Boolean Back_End_Inlining;
 extern Boolean Debug_Generated_Code;
 extern Boolean Exception_Extra_Info;

--- gcc/ada/opt.ads
+++ gcc/ada/opt.ads
@@ -124,11 +124,14 @@ package Opt is
 
type Ada_Version_Type is (Ada_83, Ada_95, Ada_2005, Ada_2012, Ada_2020);
pragma Ordered (Ada_Version_Type);
+   pragma Convention (C, Ada_Version_Type);
--  Versions of Ada for Ada_Version below. Note that these are ordered,
--  so that tests like Ada_Version >= Ada_95 are legitimate and useful.
--  Think twice before using "="; Ada_Version >= Ada_2012 is more likely
--  what you want, because it will apply to future versions of the language.
 
+   --  WARNING: There is a matching C declaration of this type in fe.h
+
Ada_Version_Default : constant Ada_Version_Type := Ada_2012;
pragma Warnings (Off, Ada_Version_Default);
--  GNAT
@@ -141,6 +144,8 @@ package Opt is
--  compiler switches, or implicitly (to Ada_Version_Runtime) when a
--  predefined or internal file is compiled.
 
+   --  WARNING: There is a matching C declaration of this variable in fe.h
+
Ada_Version_Pragma : Node_Id := Empty;
--  Reflects the Ada_xxx pragma that resulted in setting Ada_Version. Used
--  to specialize error messages complaining about the Ada version in use.
@@ -629,9 +634,10 @@ package Opt is
   --  Similar to Back_End_ZCX with respect to the front-end processing
   --  of regular and AT-END handlers. A setjmp/longjmp scheme is used to
   --  propagate and setup handler contexts on regular execution paths.
-
pragma Convention (C, Exception_Mechanism_Type);
 
+   --  WARNING: There is a matching C declaration of this type in fe.h
+
Exception_Mechanism : Exception_Mechanism_Type := Front_End_SJLJ;
--  GNAT
--  Set to the appropriate value depending on the flags in system.ads



[Ada] Fully propagate representation aspects through renaming

2019-12-16 Thread Pierre-Marie de Rodat
This makes sure that the 4 representation aspects defined (or not) in
C.6 and supported by GNAT, that is to say Atomic, Independent, Volatile
and Volatile_Full_Access, are fully propagated through renaming
declarations.

This also overhauls the implementation of the 4 associated predicates
Is_[Aspect_Name]_Object in Sem_Util to make them equivalent, modulo the
specific details of the semantics of each aspect.

Tested on x86_64-pc-linux-gnu, committed on trunk

2019-12-16  Eric Botcazou  

gcc/ada/

* sem_ch8.adb (Analyze_Object_Renaming): Set Atomic, Independent
and Volatile_Full_Access aspects on the entity of the renaming
the same way as the Volatile aspect is set.
* sem_util.ads (Is_Atomic_Object_Entity): Move declaration to...
(Is_Independent_Object): New function.
(Is_Volatile_Full_Access_Object): Likewise.
* sem_util.adb (Is_Atomic_Object_Entity): ...here.
(Prefix_Has_Atomic_Components): Minor tweak.
(Is_Atomic_Object): Test Is_Atomic on the Etype uniformly.
(Is_Atomic_Or_VFA_Object): Call Is_Volatile_Full_Access_Object.
(Is_Independent_Object): New predicate.
(Is_Subcomponent_Of_Atomic_Object): Remove redundant test.
(Is_Volatile_Full_Access_Object): New predicate.
(Is_Volatile_Prefix): Rename into...
(Prefix_Has_Volatile_Components): ... and call
Is_Volatile_Object.
(Object_Has_Volatile_Components): Delete.
(Is_Volatile_Object): Simplify.
* gcc-interface/trans.c (node_is_volatile_full_access): Adjust
comment.--- gcc/ada/gcc-interface/trans.c
+++ gcc/ada/gcc-interface/trans.c
@@ -4835,8 +4835,8 @@ node_is_atomic (Node_Id gnat_node)
 }
 
 /* Return true if GNAT_NODE references a Volatile_Full_Access entity.  This is
-   modeled on the Is_VFA_Object predicate of the front-end, but additionally
-   handles explicit dereferences.  */
+   modeled on the Is_Volatile_Full_Access_Object predicate of the front-end,
+   but additionally handles explicit dereferences.  */
 
 static bool
 node_is_volatile_full_access (Node_Id gnat_node)

--- gcc/ada/sem_ch8.adb
+++ gcc/ada/sem_ch8.adb
@@ -1358,19 +1358,13 @@ package body Sem_Ch8 is
   end if;
 
   --  The entity of the renaming declaration needs to reflect whether the
-  --  renamed object is volatile. Is_Volatile is set if the renamed object
-  --  is volatile in the RM legality sense.
+  --  renamed object is atomic, independent, volatile or VFA. These flags
+  --  are set on the renamed object in the RM legality sense.
 
-  Set_Is_Volatile (Id, Is_Volatile_Object (Nam));
-
-  --  Also copy settings of Atomic/Independent/Volatile_Full_Access
-
-  if Is_Entity_Name (Nam) then
- Set_Is_Atomic   (Id, Is_Atomic  (Entity (Nam)));
- Set_Is_Independent  (Id, Is_Independent (Entity (Nam)));
- Set_Is_Volatile_Full_Access (Id,
-   Is_Volatile_Full_Access (Entity (Nam)));
-  end if;
+  Set_Is_Atomic   (Id, Is_Atomic_Object (Nam));
+  Set_Is_Independent  (Id, Is_Independent_Object (Nam));
+  Set_Is_Volatile (Id, Is_Volatile_Object (Nam));
+  Set_Is_Volatile_Full_Access (Id, Is_Volatile_Full_Access_Object (Nam));
 
   --  Treat as volatile if we just set the Volatile flag
 

--- gcc/ada/sem_util.adb
+++ gcc/ada/sem_util.adb
@@ -122,6 +122,10 @@ package body Sem_Util is
--  T is a derived tagged type. Check whether the type extension is null.
--  If the parent type is fully initialized, T can be treated as such.
 
+   function Is_Atomic_Object_Entity (Id : Entity_Id) return Boolean;
+   --  Determine whether arbitrary entity Id denotes an atomic object as per
+   --  RM C.6(7).
+
function Is_Fully_Initialized_Variant (Typ : Entity_Id) return Boolean;
--  Subsidiary to Is_Fully_Initialized_Type. For an unconstrained type
--  with discriminants whose default values are static, examine only the
@@ -13724,16 +13728,16 @@ package body Sem_Util is
--
 
function Is_Atomic_Object (N : Node_Id) return Boolean is
-  function Prefix_Has_Atomic_Components (Pref : Node_Id) return Boolean;
-  --  Determine whether prefix Pref of an indexed component has atomic
-  --  components.
+  function Prefix_Has_Atomic_Components (P : Node_Id) return Boolean;
+  --  Determine whether prefix P has atomic components. This requires the
+  --  presence of an Atomic_Components aspect/pragma.
 
   -
   -- Prefix_Has_Atomic_Components --
   -
 
-  function Prefix_Has_Atomic_Components (Pref : Node_Id) return Boolean is
- Typ : constant Entity_Id := Etype (Pref);
+  function Prefix_Has_Atomic_Components (P : Node_Id) return Boolean is
+ Typ : constant Entity_Id := Etype (P);
 
   begin
  if Is_Access_Type (Typ) then
@@ 

[Ada] Remove new strict-alignment check added by AI12-0001

2019-12-16 Thread Pierre-Marie de Rodat
This removes the check on aliased components recently added to the
Check_Strict_Alignment procedure as part of the implementation of
AI12-0001 because it causes a build failure for Florist on 32-bit
platforms and might also affect other legacy codebases.

Tested on x86_64-pc-linux-gnu, committed on trunk

2019-12-16  Eric Botcazou  

gcc/ada/

* freeze.adb (Check_Strict_Alignment): Remove new check on
Has_Aliased_Components for array types.--- gcc/ada/freeze.adb
+++ gcc/ada/freeze.adb
@@ -1614,24 +1614,22 @@ package body Freeze is
  Set_Strict_Alignment (E);
 
   elsif Is_Array_Type (E) then
- if Has_Aliased_Components (E)
-   or else Strict_Alignment (Component_Type (E))
- then
-Set_Strict_Alignment (E);
- end if;
+ Set_Strict_Alignment (E, Strict_Alignment (Component_Type (E)));
 
-  elsif Is_Record_Type (E) then
- --  ??? If the type has convention C_Pass_By_Copy, we consider
- --  that it may be packed even if it contains aliased parts.
- --  Such types are very unlikely to be misaligned in practice
- --  and this makes the compiler accept dubious representation
- --  clauses used in Florist on types containing arrays with
- --  aliased components.
-
- if C_Pass_By_Copy (E) then
-return;
- end if;
+ --  ??? AI12-001: Any component of a packed type that contains an
+ --  aliased part must be aligned according to the alignment of its
+ --  subtype (RM 13.2(7)). This means that the following test:
+
+ --if Has_Aliased_Components (E) then
+ --  Set_Strict_Alignment (E);
+ --end if;
 
+ --  should be implemented here. Unfortunately it would break Florist,
+ --  which has the bad habit of overaligning all the types it declares
+ --  on 32-bit platforms. Other legacy codebases could also be affected
+ --  because this check has historically been missing in GNAT.
+
+  elsif Is_Record_Type (E) then
  Comp := First_Component (E);
  while Present (Comp) loop
 if not Is_Type (Comp)



[Ada] Expand renamings of subcomponents of an atomic or VFA object

2019-12-16 Thread Pierre-Marie de Rodat
This change makes sure that the front-end expands the renamings of
subcomponents of atomic or Volatile_Full_Access objects, i.e. the
references in the renamed object are elaborated and the result is
substituted for the renaming in the expanded code.

This means that code generators implementing renaming by means of a
pointer can keep doing it in the presence of atomic (in Ada 2020) or
Volatile_Full_Access (in any version) objects in the source code.

Tested on x86_64-pc-linux-gnu, committed on trunk

2019-12-16  Eric Botcazou  

gcc/ada/

* exp_ch8.adb (Expand_N_Object_Renaming_Declaration): Document
third special case of renamings requiring special handling.
(Evaluation_Required): Return true for an atomic or VFA prefix.--- gcc/ada/exp_ch8.adb
+++ gcc/ada/exp_ch8.adb
@@ -72,7 +72,14 @@ package body Exp_Ch8 is
--  clause applies (that can specify an arbitrary bit boundary), or where
--  the enclosing record itself has a non-standard representation.
 
-   --  In these two cases, we pre-evaluate the renaming expression, by
+   --  In Ada 2020, a third case arises when the renamed object is a nonatomic
+   --  subcomponent of an atomic object, because reads of or writes to it must
+   --  access the enclosing atomic object. That's also the case for an object
+   --  subject to the Volatile_Full_Access GNAT aspect/pragma in any language
+   --  version. For the sake of simplicity, we treat any subcomponent of an
+   --  atomic or Volatile_Full_Access object in any language version this way.
+
+   --  In these three cases, we pre-evaluate the renaming expression, by
--  extracting and freezing the values of any subscripts, and then we
--  set the flag Is_Renaming_Of_Object which means that any reference
--  to the object will be handled by macro substitution in the front
@@ -102,10 +109,10 @@ package body Exp_Ch8 is
   --  Determines whether it is necessary to do static name evaluation for
   --  renaming of Nam. It is considered necessary if evaluating the name
   --  involves indexing a packed array, or extracting a component of a
-  --  record to which a component clause applies. Note that we are only
-  --  interested in these operations if they occur as part of the name
-  --  itself, subscripts are just values that are computed as part of the
-  --  evaluation, so their form is unimportant.
+  --  record to which a component clause applies, or a subcomponent of an
+  --  atomic object. Note that we are only interested in these operations
+  --  if they occur as part of the name itself, subscripts are just values
+  --  that are computed as part of the evaluation, so they are unimportant.
   --  In addition, always return True for Modify_Tree_For_C since the
   --  code generator doesn't know how to handle renamings.
 
@@ -121,6 +128,10 @@ package body Exp_Ch8 is
  elsif Nkind_In (Nam, N_Indexed_Component, N_Slice) then
 if Is_Packed (Etype (Prefix (Nam))) then
return True;
+
+elsif Is_Atomic_Or_VFA_Object (Prefix (Nam)) then
+   return True;
+
 else
return Evaluation_Required (Prefix (Nam));
 end if;
@@ -141,6 +152,9 @@ package body Exp_Ch8 is
then
   return True;
 
+   elsif Is_Atomic_Or_VFA_Object (Prefix (Nam)) then
+  return True;
+
else
   return Evaluation_Required (Prefix (Nam));
end if;



[Ada] AI12-0234/321 atomic operations

2019-12-16 Thread Pierre-Marie de Rodat
This patch adds support for Ada 202x new packages adding support for
atomic operations (Exchange, Test and Set, Fetch Add/Sub).

Tested on x86_64-pc-linux-gnu, committed on trunk

2019-12-16  Arnaud Charlet  

gcc/ada/

* libgnat/s-aotase.adb, libgnat/s-aotase.ads,
libgnat/s-atoope.ads, libgnat/s-atopar.adb,
libgnat/s-atopar.ads, libgnat/s-atopex.adb,
libgnat/s-atopex.ads: New files.
* libgnat/s-atopri.ads: Add new intrinsics.
* Makefile.rtl: Add new runtime files.
* impunit.adb: Add new units to Ada 2020 list.

patch.diff.gz
Description: application/gzip


[Ada] AI12-0001: Independence and Representation clauses for atomic objects

2019-12-16 Thread Pierre-Marie de Rodat
This implements the aforementioned AI in all versions of the language
since it is classified as a Binding Interpretation.  The main visible
effects are to turn errors given for the Pack aspect/pragma into mere
warnings and to give new errors for representation clauses that do not
abide by the alignment of some by-reference types, typically record
types that are either volatile or contain a volatile subcomponent.

Tested on x86_64-pc-linux-gnu, committed on trunk

2019-12-16  Eric Botcazou  

gcc/ada/

* gcc-interface/decl.c (gnat_to_gnu_entity): Adjust calls to
validate_size.
(gnat_to_gnu_component_type): Likewise.
(gnat_to_gnu_field): Likewise and pass string for error messages.
(components_need_strict_alignment): Remove test on Is_Aliased and
add test for the independence of the component.
(validate_size): Add S1 and S2 string parameters and use them to
give better error messages for fields.  Tweak a couple of messages.
* einfo.ads (Has_Independent_Components): Document more cases.
(Is_Independent): Likewise.
(Strict_Alignment): Document new semantics.
* exp_ch9.adb (Install_Private_Data_Declarations): Also set the
Is_Independent flag along with Is_Aliased on the renaming
entity.
* freeze.adb (Size_Known): Remove always-false test and add test
for the strict-alignment on the record type.  Remove redundant
tests and add test for the strict-alignment on the component
type.
(Check_Strict_Alignment): Set the flag if the type is by-ref and
remove now redundant conditions.  Set the flag on an array type
if it has aliased components.  In the record type case, do not
set type for C_Pass_By_Copy convention.
(Freeze_Array_Type): Move code checking for conflicts between
representation aspects and clauses to before specific handling
of packed array types. Give a warnind instead of an error for a
conflict with pragma Pack.  Do not test Has_Pragma_Pack for the
specific handling of packed array types.
(Freeze_Record_Type): Move error checking of representation
clause to...
(Freeze_Entity): ...here after Check_Strict_Alignment is called.
* sem_aggr.adb (Array_Aggr_Subtype): Also set the Is_Independent
flag along with Is_Aliased on the Itype.
* sem_ch13.adb (Check_Record_Representation_Clause): Do not set
the RM size for a strict-alignment type.
* sem_ch3.adb (Add_Interface_Tag_Components): Also set the
Is_Independent flag along with Is_Aliased on the tag.
(Add_Interface_Tag_Components): Likewise on the offset.
(Analyze_Component_Declaration): Likewise on the component.
(Analyze_Object_Declaration): Likewise on the object.
(Constrain_Array): Likewise on the array.
(Record_Type_Declaration: Likewise on the tag.
(Array_Type_Declaration): Also set the
Has_Independent_Components flag along with
Has_Aliased_Components on the array.
(Copy_Array_Base_Type_Attributes): Copy
Has_Independent_Components.
(Copy_Array_Subtype_Attributes): Copy Is_Atomic, Is_Independent
and Is_Volatile_Full_Access.
(Analyze_Iterator_Specification): Set Is_Independent on the loop
variable according to Independent_Components on the array.
* sem_ch5.adb: Likewise.
* sem_ch6.adb (Process_Formals): Also set the Is_Independent
flag along with Is_Aliased on the formal.

gcc/testsuite/

* gnat.dg/specs/clause_on_volatile.ads,
gnat.dg/specs/size_clause3.ads: Update expected diagnostics.

patch.diff.gz
Description: application/gzip


[Ada] Syntax error on improperly indented imported subprogram

2019-12-16 Thread Pierre-Marie de Rodat
This patch fixes an incorrect syntax error. In particular, in an example
like the following:

procedure Main is
procedure Imported with Import;
begin
   null;
end;

where there is a subprogram declaration with an Import aspect
specification, and the declaration is indented the same as a following
"begin", the compiler was giving incorrect syntax errors:

main.adb:2:31: ";" should be "is"
main.adb:5:01: "end Imported;" expected
main.adb:5:01: missing "begin" for procedure "Main" at line 1

The problem was that the mechanisms described under "Handling Semicolon
Used in Place of IS" in par.adb were not updated to handle Import
aspect.

Tested on x86_64-pc-linux-gnu, committed on trunk

2019-12-16  Bob Duff  

gcc/ada/

* par.adb: Add Scopes function to do range checking on the scope
stack.  Call Scopes all over the parser.  Add
SIS_Aspect_Import_Seen flag.
* par-ch6.adb (P_Subprogram): Initialize SIS_Aspect_Import_Seen
to False at the start, and check it at the end.
* par-ch13.adb (Get_Aspect_Specifications): Set
SIS_Aspect_Import_Seen to True when appropriate.
* par-ch10.adb, par-ch12.adb, par-ch2.adb, par-ch3.adb,
par-ch5.adb, par-ch7.adb, par-ch9.adb, par-endh.adb,
par-util.adb: Call Scopes.

patch.diff.gz
Description: application/gzip


[PATCH] get source line for diagnostic from preprocessed file / PR preprocessor/79106

2019-12-16 Thread Bader, Lucas
Hello,

within a compile cluster, only the preprocessed output of GCC is transferred to 
remote nodes for compilation. 
When GCC produces advanced diagnostics (with -fdiagnostics-show-caret), e.g. 
prints out the affected source
line and fixit hints, it attempts to read the source file again, even when 
compiling a preprocessed file (-fpreprocessed). 
This leads to wrong diagnostics when building with a compile cluster, or, more 
generally, when changing or deleting the original source file.

This patch attempts to alter the behavior by implementing a 
location_get_source_line_preprocessed 
function that can be used in diagnostic-show-locus.c in case a preprocessed 
file is compiled.
There was some previous discussion on this behavior on PR preprocessor/79106.

This is my first patch to GCC, so in case something is wrong with the format, 
please let me know.

Best regards
Lucas

2019-12-16  Lucas Bader  

PR preprocessor/79106
* c-opts.c (c_common_handle_option): pass -fpreprocessed 
option value to global diagnostic configuration

* diagnostic-show-locus.c (layout::layout): read line from source or 
preprocessed
file based on -fpreprocessed value
(source_line::source_line): read line from source or preprocessed
file based on -fpreprocessed value
(layout::print_line): read line from source or preprocessed
file based on -fpreprocessed value

* diagnostic.h (diagnostic_context): new members for reading
source lines from preprocessed files
* diagnostic.c (diagnostic_initialize): initialize new members

* input.c (location_get_source_line_preprocessed): new function
to read source lines from preprocessed files
(test_reading_source_line_preprocessed): new test case
(input_c_tests): execute new test case

* opts-global.c (read_cmdline_options): pass input filename to global
diagnostic context

---

diff --git a/gcc/c-family/c-opts.c b/gcc/c-family/c-opts.c
index c913291c07c..8634de6eb3f 100644
--- a/gcc/c-family/c-opts.c
+++ b/gcc/c-family/c-opts.c
@@ -485,6 +485,7 @@ c_common_handle_option (size_t scode, const char *arg, 
HOST_WIDE_INT value,
 
 case OPT_fpreprocessed:
   cpp_opts->preprocessed = value;
+  global_dc->is_preprocessed = value;
   break;
 
 case OPT_fdebug_cpp:
diff --git a/gcc/diagnostic-show-locus.c b/gcc/diagnostic-show-locus.c
index cb920f6b9d0..3a4838605de 100644
--- a/gcc/diagnostic-show-locus.c
+++ b/gcc/diagnostic-show-locus.c
@@ -896,7 +896,12 @@ layout::layout (diagnostic_context * context,
  Center the primary caret to fit in max_width; all columns
  will be adjusted accordingly.  */
   size_t max_width = m_context->caret_max_width;
-  char_span line = location_get_source_line (m_exploc.file, m_exploc.line);
+  char_span line (NULL, 0);
+  if (global_dc->main_input_file_path != NULL && global_dc->is_preprocessed)
+line = location_get_source_line_preprocessed (
+   m_exploc.file, global_dc->main_input_file_path, m_exploc.line);
+  else
+line = location_get_source_line (m_exploc.file, m_exploc.line);
   if (line && (size_t)m_exploc.column <= line.length ())
 {
   size_t right_margin = CARET_LINE_MARGIN;
@@ -1913,7 +1918,12 @@ public:
 
 source_line::source_line (const char *filename, int line)
 {
-  char_span span = location_get_source_line (filename, line);
+  char_span span (NULL, 0);
+  if (global_dc->main_input_file_path != NULL && global_dc->is_preprocessed)
+span = location_get_source_line_preprocessed (
+   filename, global_dc->main_input_file_path, line);
+  else
+span = location_get_source_line (filename, line);
   chars = span.get_buffer ();
   width = span.length ();
 }
@@ -2237,7 +2247,13 @@ layout::show_ruler (int max_column) const
 void
 layout::print_line (linenum_type row)
 {
-  char_span line = location_get_source_line (m_exploc.file, row);
+  char_span line (NULL, 0);
+  if (global_dc->main_input_file_path != NULL && global_dc->is_preprocessed)
+line = location_get_source_line_preprocessed (
+   m_exploc.file, global_dc->main_input_file_path, row);
+  else
+line = location_get_source_line (m_exploc.file, row);
+
   if (!line)
 return;
 
diff --git a/gcc/diagnostic.c b/gcc/diagnostic.c
index a29bcf155e2..6ef99d0e8f1 100644
--- a/gcc/diagnostic.c
+++ b/gcc/diagnostic.c
@@ -218,6 +218,8 @@ diagnostic_initialize (diagnostic_context *context, int 
n_opts)
   context->begin_group_cb = NULL;
   context->end_group_cb = NULL;
   context->final_cb = default_diagnostic_final_cb;
+  context->main_input_file_path = NULL;
+  context->is_preprocessed = false;
 }
 
 /* Maybe initialize the color support. We require clients to do this
diff --git a/gcc/diagnostic.h b/gcc/diagnostic.h
index 91e4c509605..f233057fbbe 100644
--- a/gcc/diagnostic.h
+++ b/gcc/diagnostic.h
@@ -158,6 +158,12 @@ struct diagnostic_context
   /* Maximum number of 

[patch] Guard aarch64/aapcs64 tests using abitest.S by check_weak_available

2019-12-16 Thread Olivier Hainque
Hello,

Some tests from  gcc/testsuite/gcc.target/aarch64/aapcs64
resort to the abitest.S source, which defines a few weak symbols:

  ...
  .weak   testfunc
  .weak   testfunc_ptr
  .weak   saved_return_address

The attached patch is a proposal to prevent the execution of
those tests in configurations where weak symbols are advertised
as not supported.

This cures a significant number of failures on VxWorks and bootstrap
+ regress tests fine on aarch64-linux.

Is this ok to commit ?

Thanks in advance!

With Kind Regards,

Olivier

2019-12-16  Joel Brobecker  
Olivier Hainque  

testsuite/

* gcc.target/aarch64/aapcs64/aapcs64.exp: Guard tests using
abitest.S by check_weak_available.

 .../gcc.target/aarch64/aapcs64/aapcs64.exp| 36 ---
 1 file changed, 23 insertions(+), 13 deletions(-)

diff --git a/gcc/testsuite/gcc.target/aarch64/aapcs64/aapcs64.exp 
b/gcc/testsuite/gcc.target/aarch64/aapcs64/aapcs64.exp
index c17af6c3084..36687800ecd 100644
--- a/gcc/testsuite/gcc.target/aarch64/aapcs64/aapcs64.exp
+++ b/gcc/testsuite/gcc.target/aarch64/aapcs64/aapcs64.exp
@@ -29,12 +29,16 @@ torture-init
 set-torture-options $C_TORTURE_OPTIONS
 set additional_flags "-W -Wall -Wno-abi"
 
-# Test parameter passing.
-foreach src [lsort [glob -nocomplain $srcdir/$subdir/test_*.c]] {
-if {[runtest_file_p $runtests $src]} {
+# Test parameter passing.  This uses abitest.S which relies on weak
+# symbols.
+
+if { [check_weak_available] } {
+foreach src [lsort [glob -nocomplain $srcdir/$subdir/test_*.c]] {
+   if {[runtest_file_p $runtests $src]} {
c-torture-execute [list $src \
$srcdir/$subdir/abitest.S] \
$additional_flags
+   }
 }
 }
 
@@ -48,25 +52,31 @@ foreach src [lsort [glob -nocomplain 
$srcdir/$subdir/rec_*.c]] {
 }
 }
 
-# Test unnamed argument retrieval via the va_arg macro.
-foreach src [lsort [glob -nocomplain $srcdir/$subdir/va_arg-*.c]] {
-if {[runtest_file_p $runtests $src]} {
+# Test unnamed argument retrieval via the va_arg macro.  This uses abitest.S
+# which relies on weak symbols.
+if { [check_weak_available] } {
+foreach src [lsort [glob -nocomplain $srcdir/$subdir/va_arg-*.c]] {
+   if {[runtest_file_p $runtests $src]} {
c-torture-execute [list $src \
$srcdir/$subdir/abitest.S] \
$additional_flags
+   }
 }
 }
 
-# Test function return value.
-#   Disable -fipa-ra to prevent the compiler from generating
-#   conflicting code.
-set additional_flags_for_func_ret $additional_flags
-append additional_flags_for_func_ret " -fno-ipa-ra"
-foreach src [lsort [glob -nocomplain $srcdir/$subdir/func-ret-*.c]] {
-if {[runtest_file_p $runtests $src]} {
+# Test function return value.  This uses abitest.S which relies on
+# weak symbols.
+if { [check_weak_available] } {
+#   Disable -fipa-ra to prevent the compiler from generating
+#   conflicting code.
+set additional_flags_for_func_ret $additional_flags
+append additional_flags_for_func_ret " -fno-ipa-ra"
+foreach src [lsort [glob -nocomplain $srcdir/$subdir/func-ret-*.c]] {
+   if {[runtest_file_p $runtests $src]} {
c-torture-execute [list $src \
$srcdir/$subdir/abitest.S] \
$additional_flags_for_func_ret
+   }
 }
 }
 
-- 
2.17.1



Re: [patch] Guard aarch64/aapcs64 tests using abitest.S by check_weak_available

2019-12-16 Thread Richard Sandiford
Olivier Hainque  writes:
> Hello,
>
> Some tests from  gcc/testsuite/gcc.target/aarch64/aapcs64
> resort to the abitest.S source, which defines a few weak symbols:
>
>   ...
>   .weak   testfunc
>   .weak   testfunc_ptr
>   .weak   saved_return_address
>
> The attached patch is a proposal to prevent the execution of
> those tests in configurations where weak symbols are advertised
> as not supported.
>
> This cures a significant number of failures on VxWorks and bootstrap
> + regress tests fine on aarch64-linux.
>
> Is this ok to commit ?
>
> Thanks in advance!
>
> With Kind Regards,
>
> Olivier
>
> 2019-12-16  Joel Brobecker  
> Olivier Hainque  
>
>   testsuite/
>
>   * gcc.target/aarch64/aapcs64/aapcs64.exp: Guard tests using
>   abitest.S by check_weak_available.

OK, thanks.

Richard

>
>  .../gcc.target/aarch64/aapcs64/aapcs64.exp| 36 ---
>  1 file changed, 23 insertions(+), 13 deletions(-)
>
> diff --git a/gcc/testsuite/gcc.target/aarch64/aapcs64/aapcs64.exp 
> b/gcc/testsuite/gcc.target/aarch64/aapcs64/aapcs64.exp
> index c17af6c3084..36687800ecd 100644
> --- a/gcc/testsuite/gcc.target/aarch64/aapcs64/aapcs64.exp
> +++ b/gcc/testsuite/gcc.target/aarch64/aapcs64/aapcs64.exp
> @@ -29,12 +29,16 @@ torture-init
>  set-torture-options $C_TORTURE_OPTIONS
>  set additional_flags "-W -Wall -Wno-abi"
>  
> -# Test parameter passing.
> -foreach src [lsort [glob -nocomplain $srcdir/$subdir/test_*.c]] {
> -if {[runtest_file_p $runtests $src]} {
> +# Test parameter passing.  This uses abitest.S which relies on weak
> +# symbols.
> +
> +if { [check_weak_available] } {
> +foreach src [lsort [glob -nocomplain $srcdir/$subdir/test_*.c]] {
> + if {[runtest_file_p $runtests $src]} {
>   c-torture-execute [list $src \
>   $srcdir/$subdir/abitest.S] \
>   $additional_flags
> + }
>  }
>  }
>  
> @@ -48,25 +52,31 @@ foreach src [lsort [glob -nocomplain 
> $srcdir/$subdir/rec_*.c]] {
>  }
>  }
>  
> -# Test unnamed argument retrieval via the va_arg macro.
> -foreach src [lsort [glob -nocomplain $srcdir/$subdir/va_arg-*.c]] {
> -if {[runtest_file_p $runtests $src]} {
> +# Test unnamed argument retrieval via the va_arg macro.  This uses abitest.S
> +# which relies on weak symbols.
> +if { [check_weak_available] } {
> +foreach src [lsort [glob -nocomplain $srcdir/$subdir/va_arg-*.c]] {
> + if {[runtest_file_p $runtests $src]} {
>   c-torture-execute [list $src \
>   $srcdir/$subdir/abitest.S] \
>   $additional_flags
> + }
>  }
>  }
>  
> -# Test function return value.
> -#   Disable -fipa-ra to prevent the compiler from generating
> -#   conflicting code.
> -set additional_flags_for_func_ret $additional_flags
> -append additional_flags_for_func_ret " -fno-ipa-ra"
> -foreach src [lsort [glob -nocomplain $srcdir/$subdir/func-ret-*.c]] {
> -if {[runtest_file_p $runtests $src]} {
> +# Test function return value.  This uses abitest.S which relies on
> +# weak symbols.
> +if { [check_weak_available] } {
> +#   Disable -fipa-ra to prevent the compiler from generating
> +#   conflicting code.
> +set additional_flags_for_func_ret $additional_flags
> +append additional_flags_for_func_ret " -fno-ipa-ra"
> +foreach src [lsort [glob -nocomplain $srcdir/$subdir/func-ret-*.c]] {
> + if {[runtest_file_p $runtests $src]} {
>   c-torture-execute [list $src \
>   $srcdir/$subdir/abitest.S] \
>   $additional_flags_for_func_ret
> + }
>  }
>  }


[Ada] Small consistency fix for Volatile_Full_Access objects

2019-12-16 Thread Pierre-Marie de Rodat
This fixes a small oversight in the part of the Is_Atomic_Or_VFA_Object
predicate which detects the Volatile_Full_Access aspect/pragma.  This
aspect/pragma can also be put on individual components in record types
and, more generally, components of arrays or records whose type is
subject to the aspect/pragma are Volatile_Full_Access objects too.

This is simply modelled on the Is_Atomic_Object predicate, modulo the
handling of Atomic_Components whose counterpart doesn't exist for the
Volatile_Full_Access aspect/pragma.

Tested on x86_64-pc-linux-gnu, committed on trunk

2019-12-16  Eric Botcazou  

gcc/ada/

* sem_util.adb (Is_Atomic_Or_VFA_Object): Also return true for
components whose type is Volatile_Full_Access or which are
subject to the aspect/pragma individually.
* sem_util.ads (Is_Atomic_Object_Entity): Small comment fix.--- gcc/ada/sem_util.adb
+++ gcc/ada/sem_util.adb
@@ -13788,13 +13788,50 @@ package body Sem_Util is
-
 
function Is_Atomic_Or_VFA_Object (N : Node_Id) return Boolean is
+  function Is_VFA_Object (N : Node_Id) return Boolean;
+  --  Determine whether arbitrary node N denotes a reference to an object
+  --  which is Volatile_Full_Access. Modelled on Is_Atomic_Object above.
+
+  function Is_VFA_Object_Entity (Id : Entity_Id) return Boolean;
+  --  Determine whether arbitrary entity Id denotes an object which is
+  --  Volatile_Full_Access. Modelled on Is_Atomic_Object_Entity above.
+
+  -
+  --  Is_VFA_Object  --
+  -
+
+  function Is_VFA_Object (N : Node_Id) return Boolean is
+  begin
+ if Is_Entity_Name (N) then
+return Is_VFA_Object_Entity (Entity (N));
+
+ elsif Nkind (N) = N_Indexed_Component then
+return Is_Volatile_Full_Access (Etype (N));
+
+ elsif Nkind (N) = N_Selected_Component then
+return
+  Is_Volatile_Full_Access (Etype (N))
+or else Is_Volatile_Full_Access (Entity (Selector_Name (N)));
+ end if;
+
+ return False;
+  end Is_VFA_Object;
+
+  
+  --  Is_VFA_Object_Entity  --
+  
+
+  function Is_VFA_Object_Entity (Id : Entity_Id) return Boolean is
+  begin
+ return
+   Is_Object (Id)
+ and then (Is_Volatile_Full_Access (Id)
+ or else
+   Is_Volatile_Full_Access (Etype (Id)));
+  end Is_VFA_Object_Entity;
+
begin
-  return Is_Atomic_Object (N)
-or else (Is_Entity_Name (N)
-   and then Is_Object (Entity (N))
-   and then (Is_Volatile_Full_Access (Entity (N))
-or else
- Is_Volatile_Full_Access (Etype (Entity (N);
+  return Is_Atomic_Object (N) or else Is_VFA_Object (N);
end Is_Atomic_Or_VFA_Object;
 
--

--- gcc/ada/sem_util.ads
+++ gcc/ada/sem_util.ads
@@ -1535,7 +1535,7 @@ package Sem_Util is
 
function Is_Atomic_Object_Entity (Id : Entity_Id) return Boolean;
--  Determine whether arbitrary entity Id denotes an atomic object as per
-   --  Ada RM C.6(12).
+   --  Ada RM C.6(7).
 
function Is_Atomic_Or_VFA_Object (N : Node_Id) return Boolean;
--  Determine whether arbitrary node N denotes a reference to an object



[Ada] Implement new legality rules introduced in C.6(13) by AI12-0128

2019-12-16 Thread Pierre-Marie de Rodat
This implements the new 4 legality rules added to C.6(13) by AI12-0128
and pertaining to nonatomic subcomponents of atomic types and objects.

This also implements the counterpart of the last 2 rules for the GNAT
specific aspect/pragma Volatile_Full_Access (they were only partially
implemented before for it).

Finally this beefs up the error messages given for related legality
rules in C.6(12) and adds explicit references to these RM clauses.

Tested on x86_64-pc-linux-gnu, committed on trunk

2019-12-16  Eric Botcazou  

gcc/ada/

* doc/gnat_rm/implementation_defined_pragmas.rst (VFA): Document
extension of the no-aliasing rule to any subcomponent.
* freeze.adb (Freeze_Object_Declaration): Small comment tweak.
(Freeze_Record_Type): Do not deal with delayed aspect
specifications for components here but...
(Freeze_Entity): ...here instead.
* sem_ch12.adb (Instantiate_Object): Improve wording of errors
given for legality rules in C.6(12) and implement the new rule
in C.6(13).
* sem_res.adb (Resolve_Actuals): Likewise.
* sem_prag.adb (Check_Atomic_VFA): New procedure implementing
the new legality rules in C.6(13).
(Process_Atomic_Independent_Shared_Volatile): Call
Check_Atomic_VFA to check the legality rules.  Factor out code
marking types into...
(Mark_Type): ...this new procedure.
(Check_VFA_Conflicts): Do not check the legality rules here.
(Pragma_Atomic_Components): Call Check_Atomic_VFA on component
type.
* sem_util.ads (Is_Subcomponent_Of_Atomic_Object): Declare.
* sem_util.adb (Is_Subcomponent_Of_Atomic_Object): New
predicate.
* gnat_rm.texi: Regenerate.--- gcc/ada/doc/gnat_rm/implementation_defined_pragmas.rst
+++ gcc/ada/doc/gnat_rm/implementation_defined_pragmas.rst
@@ -7443,7 +7443,7 @@ It is not permissible to specify ``Atomic`` and ``Volatile_Full_Access`` for
 the same type or object.
 
 It is not permissible to specify ``Volatile_Full_Access`` for a composite
-(record or array) type or object that has at least one ``Aliased`` component.
+(record or array) type or object that has an ``Aliased`` subcomponent.
 
 .. _Pragma-Volatile_Function:
 

--- gcc/ada/freeze.adb
+++ gcc/ada/freeze.adb
@@ -3569,7 +3569,8 @@ package body Freeze is
 Error_Msg_N ("\??use explicit size clause to set size", E);
  end if;
 
- --  Declaring a too-big array in disabled ghost code is OK
+ --  Declaring too big an array in disabled ghost code is OK
+
  if Is_Array_Type (Typ) and then not Is_Ignored_Ghost_Entity (E) then
 Check_Large_Modular_Array (Typ);
  end if;
@@ -3998,11 +3999,6 @@ package body Freeze is
  --  clause (used to warn about useless Bit_Order pragmas, and also
  --  to detect cases where Implicit_Packing may have an effect).
 
- Rec_Pushed : Boolean := False;
- --  Set True if the record type scope Rec has been pushed on the scope
- --  stack. Needed for the analysis of delayed aspects specified to the
- --  components of Rec.
-
  Sized_Component_Total_RM_Size : Uint := Uint_0;
  --  Accumulates total RM_Size values of all sized components. Used
  --  for processing of Implicit_Packing.
@@ -4141,47 +4137,6 @@ package body Freeze is
   --  Start of processing for Freeze_Record_Type
 
   begin
- --  Deal with delayed aspect specifications for components. The
- --  analysis of the aspect is required to be delayed to the freeze
- --  point, thus we analyze the pragma or attribute definition
- --  clause in the tree at this point. We also analyze the aspect
- --  specification node at the freeze point when the aspect doesn't
- --  correspond to pragma/attribute definition clause.
-
- Comp := First_Entity (Rec);
- while Present (Comp) loop
-if Ekind (Comp) = E_Component
-  and then Has_Delayed_Aspects (Comp)
-then
-   if not Rec_Pushed then
-  Push_Scope (Rec);
-  Rec_Pushed := True;
-
-  --  The visibility to the discriminants must be restored in
-  --  order to properly analyze the aspects.
-
-  if Has_Discriminants (Rec) then
- Install_Discriminants (Rec);
-  end if;
-   end if;
-
-   Analyze_Aspects_At_Freeze_Point (Comp);
-end if;
-
-Next_Entity (Comp);
- end loop;
-
- --  Pop the scope if Rec scope has been pushed on the scope stack
- --  during the delayed aspect analysis process.
-
- if Rec_Pushed then
-if Has_Discriminants (Rec) then
-   Uninstall_Discriminants (Rec);
-end if;
-
-Pop_Scope;
- end if;
-
  --  

[Ada] Bad warning: Size in Compile_Time_Error in nested instance

2019-12-16 Thread Pierre-Marie de Rodat
This patch fixes a bug in which if a Size attribute occurs in a pragma
Compile_Time_Error, and the pragma occurs in a generic unit that is
instantiated in another generic unit, and that other generic unit is
instantiated, then the compiler does not know the value of Size at
compile time. It issues a warning in the nested instance:

warning: in instantiation at ...
warning: in instantiation at ...
warning: condition is not known at compile time

Tested on x86_64-pc-linux-gnu, committed on trunk

2019-12-16  Bob Duff  

gcc/ada/

* sem_attr.adb (Analyze_Attribute): Use Known_RM_Size. But we
still need Size_Known_At_Compile_Time, because when the size
really is known, sometimes only one or the other of these is
True.--- gcc/ada/sem_attr.adb
+++ gcc/ada/sem_attr.adb
@@ -5841,13 +5841,16 @@ package body Sem_Attr is
  --  Time_Errors after the back end has been called and this occurrence
  --  of 'Size is known at compile time then it is safe to perform this
  --  evaluation. Needed to perform the static evaluation of the full
- --  boolean expression of these pragmas.
+ --  boolean expression of these pragmas. Note that Known_RM_Size is
+ --  sometimes True when Size_Known_At_Compile_Time is False, when the
+ --  back end has computed it.
 
  if In_Compile_Time_Warning_Or_Error
and then Is_Entity_Name (P)
and then (Is_Type (Entity (P))
   or else Ekind (Entity (P)) = E_Enumeration_Literal)
-   and then Size_Known_At_Compile_Time (Entity (P))
+   and then (Known_RM_Size (Entity (P))
+   or else Size_Known_At_Compile_Time (Entity (P)))
  then
 declare
Siz : Uint;



[Ada] AI12-0208 Support for Ada.Numerics.Big_Numbers.Big_Integers and Big_Reals

2019-12-16 Thread Pierre-Marie de Rodat
This change implements Ada 2020 AI12-0208 which adds support for
infinite precision integers and rationals via new packages in the
Ada.Numerics.Big_Numbers hierarchy. A default implementation using
System.Generic_Bignum (made generic out of the existing System.Bignum)
is enabled everywhere, and an alternate implementation based on GMP
(libgnat/a-nbnbin__gmp.adb) is also provided, for now not enabled on any
configuration.

Tested on x86_64-pc-linux-gnu, committed on trunk

2019-12-16  Arnaud Charlet  

gcc/ada/

* impunit.adb: Add a-nbnbin, a-nbnbre, a-nubinu to Ada 2020
units.
* Makefile.rtl: Enable new file.
* libgnat/a-nbnbin.adb, libgnat/a-nbnbin.ads,
libgnat/a-nbnbre.adb, libgnat/a-nbnbre.ads,
libgnat/a-nubinu.ads: New files. Provide default standalone
implementation of Ada.Numerics.Big_Numbers.Big_* based on
System.Generic_Bignum.
* libgnat/a-nbnbin__gmp.adb: Alternate implementation of
Ada.Numerics.Big_Numbers.Big_Integers based on GMP. Not enabled
for now.
* libgnat/s-bignum.ads, libgnat/s-bignum.adb: Now a simple
wrapper on top of s-genbig.ads.
* libgnat/s-genbig.ads, libgnat/s-genbig.adb: New files, making
s-bignum generic for reuse in Ada.Numerics.Big_Numbers.

patch.diff.gz
Description: application/gzip


Re: [PATCH] Add abs pattern to handle {si,di} mode abs to avoid pmax/cmove conversion (PR92651)

2019-12-16 Thread Uros Bizjak
On Wed, Dec 11, 2019 at 4:24 AM 玩还有  wrote:
>
> Hi:
>   Currently smax/smin pattern added by r274481 cause some regression
> in 525.x264_r by 8% with -O2 -march=corei7. The reason is some IA
> backends (contain TARGET_SSE4_1) will do transform for simple abs
> (using rshift, xor and sub) to pmax/pmin if smax/smin pattern exists,
> which generate unnecessary sse instruction. This patch adds abs
> patterns to generate simple abs for integer mode to recover the
> regression.
>
>   Bootstrap ok, regression test on i386 backend is ok.
>   Ok for trunk?
>
> Changelog
> gcc/
> PR target/92651
> * config/i386/i386.h (TARGET_USE_SIMPLE_ABS_PATTERN): New macro.
> * config/i386/x86-tune.def (X86_TUNE_USE_SIMPLE_ABS_PATTERN): New
> * config/i386/i386.md (abs2): New define_expand.
>
> gcc/testsuite
> * gcc.target/i386/pr92651.c: New testcase.

OK, but please name new macro TARGET_EXPAND_ABS and corresponding tune
X86_TUNE_EXPAND_ABS.

Thanks,
Uros.

> Regards,
> Hongyu, Wang


Re: [PATCH] i386: Use add for a = a + b and a = b + a when possible

2019-12-16 Thread Uros Bizjak
> ince except for Bonnell,
>
> 01 fbadd%edi,%ebx
>
> is faster and shorter than
>
> 8d 1c 1f  lea(%rdi,%rbx,1),%ebx
>
> we should use add for a = a + b and a = b + a when possible if not
> optimizing for Bonnell.
>
> Tested on x86-64.
>
> gcc/
>
> PR target/92807
> * config/i386/i386.c (ix86_lea_outperforms): Check !TARGET_BONNELL.
> (ix86_avoid_lea_for_addr): When not optimizing for Bonnell, use add
> for a = a + b and a = b + a.
>
> gcc/testsuite/
>
> PR target/92807
> * gcc.target/i386/pr92807-1.c: New test.

LGTM.

Thanks,
Uros.


Re: [PATCH 7/X] [libsanitizer] Add tests

2019-12-16 Thread Matthew Malcomson
I just remembered that the run tests all fail on cross builds.
This patch includes the effective target check to determine whether a hwasan
binary can be run on a given target.

We then add that target requirement to all tests which need to run.



Adding hwasan tests.

Only interesting thing here is that we have to make sure the tagging mechanism
is deterministic to avoid flaky tests.

gcc/testsuite/ChangeLog:

2019-12-16  Matthew Malcomson  

* c-c++-common/hwasan/aligned-alloc.c: New test.
* c-c++-common/hwasan/alloca-array-accessible.c: New test.
* c-c++-common/hwasan/alloca-gets-different-tag.c: New test.
* c-c++-common/hwasan/alloca-outside-caught.c: New test.
* c-c++-common/hwasan/arguments.c: New test.
* c-c++-common/hwasan/arguments-1.c: New test.
* c-c++-common/hwasan/arguments-2.c: New test.
* c-c++-common/hwasan/arguments-3.c: New test.
* c-c++-common/hwasan/asan-pr63316.c: New test.
* c-c++-common/hwasan/asan-pr70541.c: New test.
* c-c++-common/hwasan/asan-pr78106.c: New test.
* c-c++-common/hwasan/asan-pr79944.c: New test.
* c-c++-common/hwasan/asan-rlimit-mmap-test-1.c: New test.
* c-c++-common/hwasan/bitfield-1.c: New test.
* c-c++-common/hwasan/bitfield-2.c: New test.
* c-c++-common/hwasan/builtin-special-handling.c: New test.
* c-c++-common/hwasan/check-interface.c: New test.
* c-c++-common/hwasan/halt_on_error-1.c: New test.
* c-c++-common/hwasan/heap-overflow.c: New test.
* c-c++-common/hwasan/hwasan-poison-optimisation.c: New test.
* c-c++-common/hwasan/hwasan-thread-access-parent.c: New test.
* c-c++-common/hwasan/hwasan-thread-basic-failure.c: New test.
* c-c++-common/hwasan/hwasan-thread-clears-stack.c: New test.
* c-c++-common/hwasan/hwasan-thread-success.c: New test.
* c-c++-common/hwasan/kernel-defaults.c: New test.
* c-c++-common/hwasan/large-aligned-0.c: New test.
* c-c++-common/hwasan/large-aligned-1.c: New test.
* c-c++-common/hwasan/large-aligned-untagging-0.c: New test.
* c-c++-common/hwasan/large-aligned-untagging-1.c: New test.
* c-c++-common/hwasan/macro-definition.c: New test.
* c-c++-common/hwasan/no-sanitize-attribute.c: New test.
* c-c++-common/hwasan/param-instrument-reads-and-writes.c: New test.
* c-c++-common/hwasan/param-instrument-reads.c: New test.
* c-c++-common/hwasan/param-instrument-writes.c: New test.
* c-c++-common/hwasan/param-memintrin.c: New test.
* c-c++-common/hwasan/random-frame-tag.c: New test.
* c-c++-common/hwasan/sanity-check-pure-c.c: New test.
* c-c++-common/hwasan/setjmp-longjmp-0.c: New test.
* c-c++-common/hwasan/setjmp-longjmp-1.c: New test.
* c-c++-common/hwasan/stack-tagging-basic-0.c: New test.
* c-c++-common/hwasan/stack-tagging-basic-1.c: New test.
* c-c++-common/hwasan/stack-tagging-disable.c: New test.
* c-c++-common/hwasan/unprotected-allocas-0.c: New test.
* c-c++-common/hwasan/unprotected-allocas-1.c: New test.
* c-c++-common/hwasan/use-after-free.c: New test.
* c-c++-common/hwasan/vararray-outside-caught.c: New test.
* c-c++-common/hwasan/vararray-stack-restore-correct.c: New test.
* c-c++-common/hwasan/very-large-objects.c: New test.
* g++.dg/hwasan/hwasan.exp: New file.
* g++.dg/hwasan/rvo-handled.C: New test.
* gcc.dg/hwasan/hwasan.exp: New file.
* gcc.dg/hwasan/nested-functions-0.c: New test.
* gcc.dg/hwasan/nested-functions-1.c: New test.
* gcc.dg/hwasan/nested-functions-2.c: New test.
* lib/hwasan-dg.exp: New file.



### Attachment also inlined for ease of reply###


diff --git a/gcc/testsuite/c-c++-common/hwasan/aligned-alloc.c 
b/gcc/testsuite/c-c++-common/hwasan/aligned-alloc.c
new file mode 100644
index 
..d38b1f3f62d97dc3f5c3882137c370700fd4f9a0
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/hwasan/aligned-alloc.c
@@ -0,0 +1,16 @@
+/* { dg-do run } */
+/* { dg-require-effective-target hwaddress_exec } */
+/* { dg-shouldfail "hwasan" } */
+/* This program fails at runtime in the libhwasan library.
+   The allocator can't handle the requested invalid alignment.  */
+
+int
+main ()
+{
+  void *p = __builtin_aligned_alloc (17, 100);
+  if (((unsigned long long)p & 0x10) == 0)
+return 0;
+  return 1;
+}
+
+/* { dg-output "HWAddressSanitizer: invalid alignment requested in 
aligned_alloc: 17" } */
diff --git a/gcc/testsuite/c-c++-common/hwasan/alloca-array-accessible.c 
b/gcc/testsuite/c-c++-common/hwasan/alloca-array-accessible.c
new file mode 100644
index 
..5e4c168f77efac5c9335768fb5b76fb3752783e9
--- /dev/null
+++ 

Re: [PATCH 00/49] RFC: Add a static analysis framework to GCC

2019-12-16 Thread David Malcolm
On Tue, 2019-12-03 at 18:17 +0100, Jakub Jelinek wrote:
> On Tue, Dec 03, 2019 at 11:52:13AM -0500, David Malcolm wrote:
> > > > Our plugin "interface" as such is very broad.
> > > 
> > > Just to sneak in here I don't like exposing our current plugin
> > > "non-
> > > API"
> > > more.  In fact I'd just build the analyzer into GCC with maybe an
> > > option to disable its build (in case it is very fat?).
> > 
> > My aim here is to provide a way for distributors to be able to
> > disable
> > its build - indeed, for now, for it to be disabled by default,
> > requiring opting-in.
> > 
> > My reasoning here is that the analyzer is middle-end code, but
> > isn't as
> > mature as the rest of the middle-end (but I'm working on getting it
> > more mature).
> > 
> > I want some way to label the code as a "technology preview", that
> > people may want to experiment with, but to set expectations that
> > this
> > is a lot of new code and there will be bugs - but to make it
> > available
> > to make it easier for adventurous users to try it out.
> > 
> > I hope that makes sense.
> > 
> > I went down the "in-tree plugin" path by seeing the analogy with
> > frontends, but yes, it would probably be simpler to just build it
> > into
> > GCC, guarded with a configure-time variable.  It's many thousand
> > lines
> > of non-trivial C++ code, and associated selftests and DejaGnu
> > tests.
> 
> I think it is enough to document it as tech preview in the
> documentation,
> no need to have it as an in-tree plugin.  We have lots of options
> that had
> such a state (perhaps undeclared) over the years, I'd consider
> -fvtable-verify= to be such an option, or in the past e.g.
> -fipa-matrix-reorg or -fipa-struct-reorg.  And 2.5% code growth isn't
> that
> bad.  So, as long as the option isn't enabled by default, I think
> we'd be
> fine.

FWIW I did some testing of v4 of the patch kit [1], which drops the in-
tree plugin idea in favor of simply building the analyzer into the
compiler as a regular IPA pass.  The pass is disabled by default
(enabled by -fanalyzer).  There is also a configure-time option to
disable building it (it's built by default).

I did 3 bootstraps of a release build of x86_64-pc-linux-gnu:
- unpatched,
- with the kit but with --disable-analyzer, and
- with the kit, with the analyzer enabled.

Here are the sizes of cc1 and cc1plus in bytes in each build, after
stripping debuginfo (and showing the change relative to the unpatched
build:

  Unpatched:   With kit:
   Disabled  change: Enabled   change:
cc1   25778720 25815672  +36952 (+0.1%)  26270328  +491608 (+1.9%)
cc1plus   27355296 27388152  +32856 (+0.1%)  27842808  +487512 (+1.8%)


So it's a little less than 2% code growth.

Dave

[1] see https://gcc.gnu.org/wiki/DavidMalcolm/StaticAnalyzer for the
various links



[patch] Test setrlimit with c++ in libstdc++/configure

2019-12-16 Thread Jérôme Lambourg
Hello,

In libstdc++, the test for the presence of setrlimit on the target is currently
performed in C as opposed to the other similar tests there. This leads on only a
warning being issued during configure as opposed to the expected error, and thus
improper definition of _GLIBCXX_RES_LIMITS.

This happens in particular on VxWorks where the standard header files are
available and the "struct rlimit" type definition is there. During configure,
only the setrlimit function prototype is missing so the compilation in C only
yield warnings and the test passes.

This patch fixes that by switching to C++ before testing setrlimit. It was
implemented first on gcc-8 for our internal needs, then ported to gcc-9 and now
mainline for contribution.

This change shouldn't impact targets where setrlimit is actually defined. I
tested the change on Linux to check that the result of the configure stage is
not changed by this patch.

Best regards,
Jerome


2019-12-16  Corentin Gay  
   Jerome Lambourg  

libstdc++
* acinclude.m4 (GLIBCXX_CHECK_SETRLIMIT): Test with AC_LANG_CPLUSPLUS.
* configure: Regenerate.



setrlimit_libstdcxx_configure.patch
Description: Binary data


Re: Move -Wmaybe-uninitialized to -Wextra

2019-12-16 Thread Martin Jambor
Hi,

On Tue, Nov 26 2019, Michael Witten wrote:
> [...]
> From  what  I've  read,  `-Wmaybe-uninitialized'  is  essentially
> customized for `-O2',

I don't think that is true.  It can be perfectly useful -O1 and there
are many nasty false positives at -O2 too.

> [...]
> * If `-Wmaybe-uninitialized' is enabled  by the user, then it
>   implies `-O2' computations.
>
>   That is to say, when the user specifies:
>
> -Og -Wmaybe-uninitialized
>
>   or:
>
> -Og -Wextra
>
>   then the user is explicitly  telling the compiler to do all
>   the optimizations  of `-O2',  but ONLY  for the  purpose of
>   implementing `-Wmaybe-uninitialized'

If you try to implement this proposal, you'll quickly find that there is
no such thing as like "do all optimizations only for purposes of a
warning."  You either perform a transformation or not and subsequent
passes, such as pass_late_warn_uninitialized, start work where the
previous ones left off.

Martin


Re: [patch] Guard aarch64/aapcs64 tests using abitest.S by check_weak_available

2019-12-16 Thread Olivier Hainque
Hi Andrew,

> On 16 Dec 2019, at 10:54, Andrew Pinski  wrote:
> 
> Why does VxWorks not have weak symbol support when it is an elf
> target?  I can understand it not having support in a loader but these
> symbols should all be resolved at build time.

VxWorks has so called "Dynamic Kernel Modules", which are
partially linked aggregations of object files that one would
download and link dynamically with a running kernel on a target.

We don't support weak symbols in this mode.

Olivier






[PATCH][AArch64] ACLE 8-bit integer matrix multiply-accumulate intrinsics

2019-12-16 Thread Dennis Zhang
Hi all,

This patch is part of a series adding support for Armv8.6-A features.
It depends on the Armv8.6-A effective target checking patch, 
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00857.html.

This patch adds intrinsics for matrix multiply-accumulate operations 
including vmmlaq_s32, vmmlaq_u32, and vusmmlaq_s32.

ACLE documents are at https://developer.arm.com/docs/101028/latest
ISA documents are at https://developer.arm.com/docs/ddi0596/latest

Regtested & bootstrapped for aarch64-none-linux-gnu.

Is it OK for trunk please?

Thanks
Dennis

gcc/ChangeLog:

2019-12-13  Dennis Zhang  

* config/aarch64/aarch64-builtins.c (TYPES_TERNOP_SSUS): New macro.
* config/aarch64/aarch64-simd-builtins.def (simd_smmla): New.
(simd_ummla, simd_usmmla): New.
* config/aarch64/aarch64-simd.md (aarch64_simd_mmlav16qi): New.
* config/aarch64/arm_neon.h (vmmlaq_s32, vmmlaq_u32): New.
(vusmmlaq_s32): New.
* config/aarch64/iterators.md (unspec): Add UNSPEC_SMATMUL,
UNSPEC_UMATMUL, and UNSPEC_USMATMUL.
(sur): Likewise.
(MATMUL): New.

gcc/testsuite/ChangeLog:

2019-12-13  Dennis Zhang  

* gcc.target/aarch64/advsimd-intrinsics/vmmla.c: New test.
diff --git a/gcc/config/aarch64/aarch64-builtins.c b/gcc/config/aarch64/aarch64-builtins.c
index c35a1b1f029..5b048dc9402 100644
--- a/gcc/config/aarch64/aarch64-builtins.c
+++ b/gcc/config/aarch64/aarch64-builtins.c
@@ -173,6 +173,10 @@ aarch64_types_ternopu_imm_qualifiers[SIMD_MAX_BUILTIN_ARGS]
   = { qualifier_unsigned, qualifier_unsigned,
   qualifier_unsigned, qualifier_immediate };
 #define TYPES_TERNOPUI (aarch64_types_ternopu_imm_qualifiers)
+static enum aarch64_type_qualifiers
+aarch64_types_ternop_ssus_qualifiers[SIMD_MAX_BUILTIN_ARGS]
+  = { qualifier_none, qualifier_none, qualifier_unsigned, qualifier_none };
+#define TYPES_TERNOP_SSUS (aarch64_types_ternop_ssus_qualifiers)
 
 
 static enum aarch64_type_qualifiers
diff --git a/gcc/config/aarch64/aarch64-simd-builtins.def b/gcc/config/aarch64/aarch64-simd-builtins.def
index f4ca35a5970..744f880c450 100644
--- a/gcc/config/aarch64/aarch64-simd-builtins.def
+++ b/gcc/config/aarch64/aarch64-simd-builtins.def
@@ -682,3 +682,8 @@
   BUILTIN_VSFDF (UNOP, frint32x, 0)
   BUILTIN_VSFDF (UNOP, frint64z, 0)
   BUILTIN_VSFDF (UNOP, frint64x, 0)
+
+  /* Implemented by aarch64_simd_mmlav16qi.  */
+  VAR1 (TERNOP, simd_smmla, 0, v16qi)
+  VAR1 (TERNOPU, simd_ummla, 0, v16qi)
+  VAR1 (TERNOP_SSUS, simd_usmmla, 0, v16qi)
\ No newline at end of file
diff --git a/gcc/config/aarch64/aarch64-simd.md b/gcc/config/aarch64/aarch64-simd.md
index ad4676bc167..fc0c8d21599 100644
--- a/gcc/config/aarch64/aarch64-simd.md
+++ b/gcc/config/aarch64/aarch64-simd.md
@@ -7025,3 +7025,15 @@
   "xtn\t%0., %1."
   [(set_attr "type" "neon_shift_imm_narrow_q")]
 )
+
+;; 8-bit integer matrix multiply-accumulate
+(define_insn "aarch64_simd_mmlav16qi"
+  [(set (match_operand:V4SI 0 "register_operand" "=w")
+	(plus:V4SI (match_operand:V4SI 1 "register_operand" "0")
+		   (unspec:V4SI [(match_operand:V16QI 2 "register_operand" "w")
+ (match_operand:V16QI 3 "register_operand" "w")]
+		MATMUL)))]
+  "TARGET_I8MM"
+  "mmla\\t%0.4s, %2.16b, %3.16b"
+  [(set_attr "type" "neon_mla_s_q")]
+)
\ No newline at end of file
diff --git a/gcc/config/aarch64/arm_neon.h b/gcc/config/aarch64/arm_neon.h
index 8b861601a48..e6af2c2960d 100644
--- a/gcc/config/aarch64/arm_neon.h
+++ b/gcc/config/aarch64/arm_neon.h
@@ -34606,6 +34606,36 @@ vrnd64xq_f64 (float64x2_t __a)
 
 #pragma GCC pop_options
 
+/* AdvSIMD 8-bit Integer Matrix Multiply (I8MM) intrinsics.  */
+
+#pragma GCC push_options
+#pragma GCC target ("arch=armv8.2-a+i8mm")
+
+/* Matrix Multiply-Accumulate.  */
+
+__extension__ extern __inline int32x4_t
+__attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
+vmmlaq_s32 (int32x4_t __r, int8x16_t __a, int8x16_t __b)
+{
+  return __builtin_aarch64_simd_smmlav16qi (__r, __a, __b);
+}
+
+__extension__ extern __inline uint32x4_t
+__attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
+vmmlaq_u32 (uint32x4_t __r, uint8x16_t __a, uint8x16_t __b)
+{
+  return __builtin_aarch64_simd_ummlav16qi_ (__r, __a, __b);
+}
+
+__extension__ extern __inline int32x4_t
+__attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
+vusmmlaq_s32 (int32x4_t __r, uint8x16_t __a, int8x16_t __b)
+{
+  return __builtin_aarch64_simd_usmmlav16qi_ssus (__r, __a, __b);
+}
+
+#pragma GCC pop_options
+
 #undef __aarch64_vget_lane_any
 
 #undef __aarch64_vdup_lane_any
diff --git a/gcc/config/aarch64/iterators.md b/gcc/config/aarch64/iterators.md
index 83a0d156e84..f2a9298fbf8 100644
--- a/gcc/config/aarch64/iterators.md
+++ b/gcc/config/aarch64/iterators.md
@@ -650,6 +650,9 @@
 UNSPEC_UMULHS	; Used in aarch64-sve2.md.
 UNSPEC_UMULHRS	; Used in aarch64-sve2.md.
 UNSPEC_ASRD		; Used in aarch64-sve.md.
+UNSPEC_SMATMUL	; Used in aarch64-simd.md.
+

Re: [patch] Guard aarch64/aapcs64 tests using abitest.S by check_weak_available

2019-12-16 Thread Richard Sandiford
Olivier Hainque  writes:
>> On 16 Dec 2019, at 11:19, Richard Sandiford  
>> wrote:
>
>>> * gcc.target/aarch64/aapcs64/aapcs64.exp: Guard tests using
>>> abitest.S by check_weak_available.
>> 
>> OK, thanks.
>
> Great, thanks for your prompt feedback Richard!
>
> As a side question, we have quite a few failures or aarch64
> specific tests caused by the use of -fpic or -fPIC in dg-options,
> also not supported by the VxWorks compilers in kernel mode.
>
> We have local patches adding
>
>   dg-require-effective-target fpic
>
> directives to these.
>
> Is that the correct thing to do ?

Yeah.  Adding that to tests that use -fpic or -fPIC is OK/preapproved.

Personally, I don't think people can be expected to remember to use
this whenever they add a new -fpic or -fPIC test, so it's probably
going to be a constant fight to get clean results without PIC support.

Maybe we should have a programmatic fix.  E.g. we could override
dg-options in gcc-dg.exp and make it do the equivalent of:

  { dg-require-effective-target fpic }

whenever -fpic or -fPIC is used.  We override it in a few test harnesses
already (e.g. mips.exp, which does something more complicated) so it
wouldn't be entirely new ground.

Thanks,
Richard


Re: [patch] Guard aarch64/aapcs64 tests using abitest.S by check_weak_available

2019-12-16 Thread Olivier Hainque


> On 16 Dec 2019, at 11:19, Richard Sandiford  wrote:

>>  * gcc.target/aarch64/aapcs64/aapcs64.exp: Guard tests using
>>  abitest.S by check_weak_available.
> 
> OK, thanks.

Great, thanks for your prompt feedback Richard!

As a side question, we have quite a few failures or aarch64
specific tests caused by the use of -fpic or -fPIC in dg-options,
also not supported by the VxWorks compilers in kernel mode.

We have local patches adding

  dg-require-effective-target fpic

directives to these.

Is that the correct thing to do ?

Thanks in advance,

Regards,

Olivier



[PATCH][Arm] ACLE 8-bit integer matrix multiply-accumulate intrinsics

2019-12-16 Thread Dennis Zhang
Hi all,

This patch is part of a series adding support for Armv8.6-A features.
It depends on the Arm Armv8.6-A CLI patch, 
https://gcc.gnu.org/ml/gcc-patches/2019-11/msg02195.html.
It also depends on the Armv8.6-A effective target checking patch, 
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00857.html.
It also depends on the ARMv8.6-A I8MM dot product patch for using the 
same builtin qualifier 
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00945.html.

This patch adds intrinsics for matrix multiply-accumulate operations 
including vmmlaq_s32, vmmlaq_u32, and vusmmlaq_s32.

ACLE documents are at https://developer.arm.com/docs/101028/latest
ISA documents are at https://developer.arm.com/docs/ddi0596/latest

Regtested for arm-none-linux-gnueabi-armv8.2-a.

Is it OK for trunk please?

Thanks,
Dennis

gcc/ChangeLog:

2019-12-10  Dennis Zhang  

* config/arm/arm_neon.h (vmmlaq_s32, vmmlaq_u32, vusmmlaq_s32): New.
* config/arm/arm_neon_builtins.def (smmla, ummla, usmmla): New.
* config/arm/iterators.md (MATMUL): New.
(sup): Add UNSPEC_MATMUL_S, UNSPEC_MATMUL_U, and UNSPEC_MATMUL_US.
(mmla_sfx): New.
* config/arm/neon.md (neon_mmlav16qi): New.
* config/arm/unspecs.md (UNSPEC_MATMUL_S): New.
(UNSPEC_MATMUL_U, UNSPEC_MATMUL_US): New.

gcc/testsuite/ChangeLog:

2019-12-10  Dennis Zhang  

* gcc.target/arm/simd/vmmla_1.c: New test.
diff --git a/gcc/config/arm/arm_neon.h b/gcc/config/arm/arm_neon.h
index 1f200d491d1..7beab449e4c 100644
--- a/gcc/config/arm/arm_neon.h
+++ b/gcc/config/arm/arm_neon.h
@@ -18741,6 +18741,34 @@ vcmlaq_rot270_laneq_f32 (float32x4_t __r, float32x4_t __a, float32x4_t __b,
 #pragma GCC pop_options
 #endif
 
+/* AdvSIMD 8-bit Integer Matrix Multiply (I8MM) intrinsics.  */
+
+#pragma GCC push_options
+#pragma GCC target ("arch=armv8.2-a+i8mm")
+
+__extension__ extern __inline int32x4_t
+__attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
+vmmlaq_s32 (int32x4_t __r, int8x16_t __a, int8x16_t __b)
+{
+  return __builtin_neon_smmlav16qi (__r, __a, __b);
+}
+
+__extension__ extern __inline uint32x4_t
+__attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
+vmmlaq_u32 (uint32x4_t __r, uint8x16_t __a, uint8x16_t __b)
+{
+  return __builtin_neon_ummlav16qi_ (__r, __a, __b);
+}
+
+__extension__ extern __inline int32x4_t
+__attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
+vusmmlaq_s32 (int32x4_t __r, uint8x16_t __a, int8x16_t __b)
+{
+  return __builtin_neon_usmmlav16qi_ssus (__r, __a, __b);
+}
+
+#pragma GCC pop_options
+
 #ifdef __cplusplus
 }
 #endif
diff --git a/gcc/config/arm/arm_neon_builtins.def b/gcc/config/arm/arm_neon_builtins.def
index bcccf93f7fa..bc0d06c8bc7 100644
--- a/gcc/config/arm/arm_neon_builtins.def
+++ b/gcc/config/arm/arm_neon_builtins.def
@@ -373,3 +373,7 @@ VAR2 (MAC_LANE_PAIR, vcmlaq_lane0, v4sf, v8hf)
 VAR2 (MAC_LANE_PAIR, vcmlaq_lane90, v4sf, v8hf)
 VAR2 (MAC_LANE_PAIR, vcmlaq_lane180, v4sf, v8hf)
 VAR2 (MAC_LANE_PAIR, vcmlaq_lane270, v4sf, v8hf)
+
+VAR1 (TERNOP, smmla, v16qi)
+VAR1 (UTERNOP, ummla, v16qi)
+VAR1 (USTERNOP, usmmla, v16qi)
\ No newline at end of file
diff --git a/gcc/config/arm/iterators.md b/gcc/config/arm/iterators.md
index c412851843f..ece8cc2acea 100644
--- a/gcc/config/arm/iterators.md
+++ b/gcc/config/arm/iterators.md
@@ -471,6 +471,8 @@
 (define_int_iterator VCADD [UNSPEC_VCADD90 UNSPEC_VCADD270])
 (define_int_iterator VCMLA [UNSPEC_VCMLA UNSPEC_VCMLA90 UNSPEC_VCMLA180 UNSPEC_VCMLA270])
 
+(define_int_iterator MATMUL [UNSPEC_MATMUL_S UNSPEC_MATMUL_U UNSPEC_MATMUL_US])
+
 ;;
 ;; Mode attributes
 ;;
@@ -883,6 +885,7 @@
   (UNSPEC_VMLSL_S_LANE "s") (UNSPEC_VMLSL_U_LANE "u")
   (UNSPEC_VMULL_S "s") (UNSPEC_VMULL_U "u") (UNSPEC_VMULL_P "p")
   (UNSPEC_VMULL_S_LANE "s") (UNSPEC_VMULL_U_LANE "u")
+  (UNSPEC_MATMUL_S "s") (UNSPEC_MATMUL_U "u") (UNSPEC_MATMUL_US "us")
   (UNSPEC_VSUBL_S "s") (UNSPEC_VSUBL_U "u")
   (UNSPEC_VSUBW_S "s") (UNSPEC_VSUBW_U "u")
   (UNSPEC_VHSUB_S "s") (UNSPEC_VHSUB_U "u")
@@ -1089,6 +1092,9 @@
 			(UNSPEC_SMUADX "smuadx") (UNSPEC_SSAT16 "ssat16")
 			(UNSPEC_USAT16 "usat16")])
 
+(define_int_attr mmla_sfx [(UNSPEC_MATMUL_S "s8") (UNSPEC_MATMUL_U "u8")
+			   (UNSPEC_MATMUL_US "s8")])
+
 ;; Both kinds of return insn.
 (define_code_iterator RETURNS [return simple_return])
 (define_code_attr return_str [(return "") (simple_return "simple_")])
diff --git a/gcc/config/arm/neon.md b/gcc/config/arm/neon.md
index 6a0ee28efc9..260202a8fb7 100644
--- a/gcc/config/arm/neon.md
+++ b/gcc/config/arm/neon.md
@@ -6552,3 +6552,14 @@ if (BYTES_BIG_ENDIAN)
  "vabd. %0, %1, %2"
  [(set_attr "type" "neon_fp_abd_s")]
 )
+
+(define_insn "neon_mmlav16qi"
+  [(set (match_operand:V4SI 0 "register_operand" "=w")
+	(plus:V4SI (match_operand:V4SI 1 "register_operand" "0")
+		   

Re: Move -Wmaybe-uninitialized to -Wextra

2019-12-16 Thread Martin Jambor
Hi Jeff,

On Sat, Dec 07 2019, Jeff Law wrote:
> [...]
> The whole point behind the uninitialized warning is to capture cases
> where objects may not be properly initialized.  For modern code the
> simple cases typically "just work".  What is by far the most
> interesting cases are those with complex flow control, often
> interacting with inline functions, address-of stripping, etc.  These
> are precisely the cases that humans aren't particularly good at
> catching and having the compiler analyze those paths and issue warnings
> that humans fix ultimately results in better quality code.

Or "fixes" like:

https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/expmed.c?r1=277864=277863=277864

if even we cannot deal with the false positive in our own compiler, how
can we expect our users to do so?

>
> Experience has shown that if you put something in -Wall, people will
> pay attention to it, and that is good for the long term quality of code
> bases.  If the diagnostic is outside of -Wall, it's largely ignored.  I
> think the pain of dealing with the Wuninitialized warts is smaller than
> the pain of allowing these errors to persist.

I'm afraid I that -Wmaybe-uninitialized is getting out of hand.  I bet
that some users regularly get these warnings coming from c++ header
"libraries" (like they sometimes come out our vec.h which recently
"broke" bootstrap) which they sometimes even cannot change and they then
conclude that our -Wall is "unusable" and stop paying attention to all
warnings.

Martin


[patch,avr, 1/3] Support 64-bit (long) double: The gcc part.

2019-12-16 Thread Georg-Johann Lay

Am 16.12.19 um 17:40 schrieb Georg-Johann Lay:
Patch 1/3 is the GCC changes: Documentation and new avr-specific
configure options:

--with-libf7 selects to which level double support from libf7 is added
to libgcc.

--with-double-comparison select what FLOAT_LIB_COMPARE_RETURNS_BOOL
returns.

Johann

gcc/
* config.gcc (tm_defines) [target=avr]: Support --with-libf7,
--with-double-comparison.
* doc/install.texi: Document them.
* config/avr/avr-c.c (avr_cpu_cpp_builtins)

: New built-in defines.
* doc/invoke.texi (AVR Built-in Macros): Document them.
* config/avr/avr-protos.h (avr_float_lib_compare_returns_bool): New.
* config/avr/avr.c (avr_float_lib_compare_returns_bool): New function.
* config/avr/avr.h (FLOAT_LIB_COMPARE_RETURNS_BOOL): New macro.
Index: gcc/config/avr/avr-c.c
===
--- gcc/config/avr/avr-c.c	(revision 278667)
+++ gcc/config/avr/avr-c.c	(working copy)
@@ -390,6 +390,20 @@ start address.  This macro shall be used
   cpp_define (pfile, "__WITH_AVRLIBC__");
 #endif /* WITH_AVRLIBC */
 
+  // From configure --with-libf7={|libgcc|math|math-symbols|yes|no}
+
+#ifdef WITH_LIBF7_LIBGCC
+  cpp_define (pfile, "__WITH_LIBF7_LIBGCC__");
+#endif /* WITH_LIBF7_LIBGCC */
+
+#ifdef WITH_LIBF7_MATH
+  cpp_define (pfile, "__WITH_LIBF7_MATH__");
+#endif /* WITH_LIBF7_MATH */
+
+#ifdef WITH_LIBF7_MATH_SYMBOLS
+  cpp_define (pfile, "__WITH_LIBF7_MATH_SYMBOLS__");
+#endif /* WITH_LIBF7_MATH_SYMBOLS */
+
   // From configure --with-double={|32|32,64|64,32|64}
 
 #ifdef HAVE_DOUBLE_MULTILIB
@@ -438,7 +452,23 @@ start address.  This macro shall be used
 #error "align this with config.gcc"
 #endif
 
-  
+  // From configure --with-double-comparison={2|3} --with-libf7.
+
+#if defined (WITH_DOUBLE_COMPARISON)
+#if WITH_DOUBLE_COMPARISON == 2 || WITH_DOUBLE_COMPARISON == 3
+  /* The number of states a DFmode comparison libcall might take and
+ reflects what avr.c:FLOAT_LIB_COMPARE_RETURNS_BOOL returns for
+ DFmode.  GCC's default is 3-state, but some libraries like libf7
+ implement true / false (2-state).  */
+  cpp_define_formatted (pfile, "__WITH_DOUBLE_COMPARISON__=%d",
+			WITH_DOUBLE_COMPARISON);
+#else
+#error "align this with config.gcc"
+#endif
+#else
+#error "align this with config.gcc"
+#endif
+
   /* Define builtin macros so that the user can easily query whether
  non-generic address spaces (and which) are supported or not.
  This is only supported for C.  For C++, a language extension is needed
Index: gcc/config/avr/avr-protos.h
===
--- gcc/config/avr/avr-protos.h	(revision 278667)
+++ gcc/config/avr/avr-protos.h	(working copy)
@@ -128,6 +128,8 @@ extern bool avr_xload_libgcc_p (machine_
 extern rtx avr_eval_addr_attrib (rtx x);
 extern bool avr_casei_sequence_check_operands (rtx *xop);
 
+extern bool avr_float_lib_compare_returns_bool (machine_mode, enum rtx_code);
+
 static inline unsigned
 regmask (machine_mode mode, unsigned regno)
 {
Index: gcc/config/avr/avr.c
===
--- gcc/config/avr/avr.c	(revision 278667)
+++ gcc/config/avr/avr.c	(working copy)
@@ -14575,6 +14575,23 @@ avr_fold_builtin (tree fndecl, int n_arg
   return NULL_TREE;
 }
 
+
+/* Worker function for `FLOAT_LIB_COMPARE_RETURNS_BOOL'.  */
+
+bool
+avr_float_lib_compare_returns_bool (machine_mode mode, enum rtx_code)
+{
+  if (mode == DFmode)
+{
+#if WITH_DOUBLE_COMPARISON == 2
+  return true;
+#endif
+}
+
+  // This is the GCC default and also what AVR-LibC implements.
+  return false;
+}
+
 
 
 /* Initialize the GCC target structure.  */
Index: gcc/config/avr/avr.h
===
--- gcc/config/avr/avr.h	(revision 278667)
+++ gcc/config/avr/avr.h	(working copy)
@@ -107,6 +107,9 @@ These two properties are reflected by bu
 #define BYTES_BIG_ENDIAN 0
 #define WORDS_BIG_ENDIAN 0
 
+#define FLOAT_LIB_COMPARE_RETURNS_BOOL(mode, comparison) \
+  avr_float_lib_compare_returns_bool (mode, comparison)
+
 #ifdef IN_LIBGCC2
 /* This is to get correct SI and DI modes in libgcc2.c (32 and 64 bits).  */
 #define UNITS_PER_WORD 4
Index: gcc/config.gcc
===
--- gcc/config.gcc	(revision 278552)
+++ gcc/config.gcc	(working copy)
@@ -1303,6 +1303,46 @@ avr-*-*)
 	tm_file="${tm_file} ${cpu_type}/avrlibc.h"
 	tm_defines="${tm_defines} WITH_AVRLIBC"
 	fi
+	# Work out avr_double_comparison which is 2 or 3 and is used in
+	# target hook FLOAT_LIB_COMPARE_RETURNS_BOOL to determine whether
+	# DFmode comparisons return 3-state or 2-state results.
+	case y${with_double_comparison} in
+	y | ytristate)
+		avr_double_comparison=3
+		;;
+	ybool | ylibf7)
+		avr_double_comparison=2
+		;;
+	*)
+		echo "Error: --with-double-comparison= 

Re: Add a compatible_vector_types_p target hook

2019-12-16 Thread Richard Sandiford
Richard Biener  writes:
> On December 14, 2019 11:43:48 AM GMT+01:00, Richard Sandiford 
>  wrote:
>>Richard Biener  writes:
>>> On December 13, 2019 10:12:40 AM GMT+01:00, Richard Sandiford
>> wrote:
Richard Biener  writes:
The AArch64 port emits an error if calls pass values of SVE type
>>to
>>an
unprototyped function.  To do that we need to know whether the
value
really is an SVE type rathr than a plain vector.

For varags the ABI is the same for 256 bits+.  But we'll have the
same problem there once we support -msve-vector-bits=128, since
>>the
layout of SVE and Advanced SIMD vectors differ for big-endian.
>>>
>>> But then why don't you have different modes?
>>
>>Yeah, true, modes will probably help for the Advanced SIMD/SVE
>>difference.  But from a vector value POV, a vector of 4 ints is a
>>vector
>>of 4 ints, so even distinguishing based on the mode is artificial.
>
> True. 
>
>>SVE is AFAIK the first target to have different modes for
>>potentially
>>the "same" vector type, and I had to add new infrastructure to
>>allow
>>targets to define multiple modes of the same size.  So the fact
>>that
>>gimple distinguishes otherwise identical vectors based on mode is a
>>relatively recent thing.  AFAIK it just fell out in the wash rather
>>than being deliberately planned.  It happens to be convenient in
>>this
>>context, but it hasn't been important until now.
>>
>>The hook doesn't seem any worse than distinguishing based on the
mode.
>>Another way to avoid this would have been to define separate SVE
modes
>>for the predefined vectors.  The big downside of that is that we'd
end
>>up doubling the number of SVE patterns.
>>
>>Extra on-the-side metadata is going to be easy to drop
>>accidentally,
>>and this is something we need for correctness rather than
optimisation.
>
> Still selecting the ABI during call expansion only and based on
values types at that point is fragile.

Agreed.  But it's fragile in general, not just for this case. 
>>Changing
something as fundamental as that would be a lot of work and seems
likely
to introduce accidental ABI breakage.

> The frontend are in charge of specifying the actual argument type
>>and
> at that point the target may fix the ABI. The ABI can be recorded
>>in
> the calls fntype, either via its TYPE_ARG_TYPES or in more awkward
> ways for varargs functions (in full generality that would mean
> attaching varargs ABI meta to each call).
>
> The alternative is to have an actual argument type vector
>>associated
> with each call.

I think multiple pieces of gimple code would then have to cope with
that
as a special case.  E.g. if:

   void foo (int, ...);

   type1 a;
   b = VIEW_CONVERT_EXPR (a);
   if (a)
 foo (1, a);
   else
 foo (1, b);

gets converted to:

   if (a)
 foo (1, a);
   else
 foo (1, a);

on the basis that type1 and type2 are "the same" despite having
different calling conventions, we have to be sure that the calls
are not treated as equivalent:

   foo (1, a);

Things like IPA clones would also need to handle this specially.
Anything that generates new calls based on old ones will need
to copy this information too.

This also sounds like it would be fragile and seems a bit too
invasive for stage 3.
>>>
>>> But we are already relying on this to work (fntype non-propagation)
>>because function pointer conversions are dropped on the floor. 
>>>
>>> The real change would be introducing (per call) fntype for calls to
>>unprototyped functions and somehow dealing with varargs. 
>>
>>It looks like this itself relies on useless_type_conversion_p,
>>is that right?  E.g. we have things like:
>>
>>bool
>>func_checker::compare_gimple_call (gcall *s1, gcall *s2)
>>{
>>  ...
>>  tree fntype1 = gimple_call_fntype (s1);
>>  tree fntype2 = gimple_call_fntype (s2);
>>  if ((fntype1 && !fntype2)
>>  || (!fntype1 && fntype2)
>>  || (fntype1 && !types_compatible_p (fntype1, fntype2)))
>>return return_false_with_msg ("call function types are not
>>compatible");
>>
>>and useless_type_conversion_p has:
>>
>>  else if ((TREE_CODE (inner_type) == FUNCTION_TYPE
>>  || TREE_CODE (inner_type) == METHOD_TYPE)
>> && TREE_CODE (inner_type) == TREE_CODE (outer_type))
>>{
>>  tree outer_parm, inner_parm;
>>
>>  /* If the return types are not compatible bail out.  */
>>  if (!useless_type_conversion_p (TREE_TYPE (outer_type),
>>TREE_TYPE (inner_type)))
>>  return false;
>>
>>  /* Method types should belong to a compatible base class.  */
>>  if (TREE_CODE (inner_type) == METHOD_TYPE
>>&& 

[PATCH] Prevent IPA-SRA from creating calls to local comdats (PR 92676)

2019-12-16 Thread Martin Jambor
Hi,

since r278669 (fix for PR ipa/91956), IPA-SRA makes sure that the clone
it creates is put into the same same_comdat as the original cgraph_node,
so that it can call private comdats (such as the ipa-split bits of a
comdat that is private).

However, that means that if there is non-comdat caller of a public
comdat that is modified by IPA-SRA, it now finds itself calling a
private comdat, which call graph verifier does not like (and for a
reason, in theory it can disappear and since it is private it would not
be available from other CUs).

The patch fixes this by performing the fix for PR 91956 only when the
node in question actually calls a local comdat and when it does, also
making sure that no callers come from a different same_comdat (disabling
IPA-SRA if both conditions are true), so that it plays by the rules in
both modes, does not violate the private comdat calling rule and at the
same time does not disable the transformation unnecessarily.

The patch also fixes up the calls_comdat_local of callers of the
modified node, despite that not triggering any known issues.  It has
passed LTO-bootstrap and testing.  What do you think?

Thanks,

Martin


2019-12-16  Martin Jambor  

PR ipa/92676
* ipa-sra.c (struct caller_issues): New fields candidate and
call_from_outside_comdat.
(check_for_caller_issues): Check for calls from outsied of
candidate's same_comdat_group.
(check_all_callers_for_issues): Set up issues.candidate, check result
of the new check.
(process_isra_node_results): Set calls_comdat_local of callers if
appropriate.
---
 gcc/ipa-sra.c | 27 +--
 1 file changed, 25 insertions(+), 2 deletions(-)

diff --git a/gcc/ipa-sra.c b/gcc/ipa-sra.c
index 421c0899e11..8612c8fc920 100644
--- a/gcc/ipa-sra.c
+++ b/gcc/ipa-sra.c
@@ -2895,10 +2895,14 @@ ipa_sra_ipa_function_checks (cgraph_node *node)
 
 struct caller_issues
 {
+  /* The candidate being considered.  */
+  cgraph_node *candidate;
   /* There is a thunk among callers.  */
   bool thunk;
   /* Call site with no available information.  */
   bool unknown_callsite;
+  /* Call from outside the the candidate's comdat group.  */
+  bool call_from_outside_comdat;
   /* There is a bit-aligned load into one of non-gimple-typed arguments. */
   bool bit_aligned_aggregate_argument;
 };
@@ -2920,6 +2924,13 @@ check_for_caller_issues (struct cgraph_node *node, void 
*data)
 thunks.  */
  return true;
}
+  if (issues->candidate->calls_comdat_local
+ && issues->candidate->same_comdat_group
+ && !issues->candidate->in_same_comdat_group_p (cs->caller))
+   {
+ issues->call_from_outside_comdat = true;
+ return true;
+   }
 
   isra_call_summary *csum = call_sums->get (cs);
   if (!csum)
@@ -2942,6 +2953,7 @@ check_all_callers_for_issues (cgraph_node *node)
 {
   struct caller_issues issues;
   memset (, 0, sizeof (issues));
+  issues.candidate = node;
 
   node->call_for_symbol_and_aliases (check_for_caller_issues, , true);
   if (issues.unknown_callsite)
@@ -2960,6 +2972,13 @@ check_all_callers_for_issues (cgraph_node *node)
 node->dump_name ());
   return true;
 }
+  if (issues.call_from_outside_comdat)
+{
+  if (dump_file)
+   fprintf (dump_file, "Function would become private comdat called "
+"outside of its comdat group.\n");
+  return true;
+}
 
   if (issues.bit_aligned_aggregate_argument)
 {
@@ -3759,8 +3778,12 @@ process_isra_node_results (cgraph_node *node,
 = node->create_virtual_clone (callers, NULL, new_adjustments, "isra",
  suffix_counter);
   suffix_counter++;
-  if (node->same_comdat_group)
-new_node->add_to_same_comdat_group (node);
+  if (node->calls_comdat_local && node->same_comdat_group)
+{
+  new_node->add_to_same_comdat_group (node);
+  for (cgraph_edge *cs = new_node->callers; cs; cs = cs->next_caller)
+   cs->caller->calls_comdat_local = true;
+}
   new_node->calls_comdat_local = node->calls_comdat_local;
 
   if (dump_file)
-- 
2.24.0



[PATCH] rs6000: Use symbolic names for the CR fields in more cases

2019-12-16 Thread Segher Boessenkool
It turns out we still used hardcoded register numbers for the CR fields
in some cases, and they now use the wrong numbers since we renumbered
most of the registers.  So let's use the symbolic names, instead.

Committing to trunk.


Segher


2019-12-16  Segher Boessenkool  

* config/rs6000/rs6000.md (movsi_to_cr_one): Use CR0_REGNO instead of
hardcoding the (old, expired) register number.
(*mtcrfsi): Ditto.

---
 gcc/config/rs6000/rs6000.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/config/rs6000/rs6000.md b/gcc/config/rs6000/rs6000.md
index 4c44c1f..4a6416e 100644
--- a/gcc/config/rs6000/rs6000.md
+++ b/gcc/config/rs6000/rs6000.md
@@ -13132,7 +13132,7 @@ (define_expand "movsi_to_cr_one"
 (unspec:CC [(match_operand:SI 1 "gpc_reg_operand")
(match_dup 2)] UNSPEC_MOVESI_TO_CR))]
   ""
-  "operands[2] = GEN_INT (1 << (75 - REGNO (operands[0])));")
+  "operands[2] = GEN_INT (1 << (7 - (REGNO (operands[0]) - CR0_REGNO)));")
 
 (define_insn "*movsi_to_cr"
   [(match_parallel 0 "mtcrf_operation"
@@ -13159,7 +13159,7 @@ (define_insn "*mtcrfsi"
   "REG_P (operands[0])
&& CR_REGNO_P (REGNO (operands[0]))
&& CONST_INT_P (operands[2])
-   && INTVAL (operands[2]) == 1 << (75 - REGNO (operands[0]))"
+   && INTVAL (operands[2]) == 1 << (7 - (REGNO (operands[0]) - CR0_REGNO))"
   "mtcrf %R0,%1"
   [(set_attr "type" "mtcr")])
 
-- 
1.8.3.1



Re: [PATCH] add -Wmismatched-tags (PR 61339)

2019-12-16 Thread Martin Sebor

Ping: https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00642.html

Jason, I'm on PTO until 1/6 starting this Thursday, with no
connectivity.  If there are any further changes to make to
the patch I will need to make them before then, or otherwise
after I get back in January.

On 12/9/19 5:29 PM, Martin Sebor wrote:

On 12/6/19 12:08 PM, Jason Merrill wrote:

On 12/5/19 6:47 PM, Jakub Jelinek wrote:

On Thu, Dec 05, 2019 at 04:33:10PM -0700, Martin Sebor wrote:
It's hard to distinguish between this type and the previous one by 
name;

this one should probably have "map" in its name.


+static GTY (()) record_to_locs_t *rec2loc;

...

+    rec2loc = new record_to_locs_t ();


If this isn't GC-allocated, marking it with GTY(()) seems wrong. 
How do

you imagine this warning interacting with PCH?


I have to confess I know too little about PCH to have an idea how
it might interact.  Is there something you suggest I try testing?


For your patch, obviously some struct/class forward declarations or
definitions in a header that you compile into PCH and then the main 
testcase

that contains the mismatched pairs.

If there is something that you need to record during parsing of the
precompiled header and use later on, everything needs to be GGC 
allocated.

So, the hash_map needs to be created with something like
hash_map::create_ggc (nnn)
and it really can't use pointer hashing, but has to use some 
different one
(say on DECL_UID, TYPE_UID etc.), because the addresses are remapped 
during

PCH save/restore cycle, but hash tables aren't rehashed.
See e.g. PR92458.


Alternately you can decide that this information will not be saved to 
PCH, and rely on CLASSTYPE_DECLARED_CLASS for classes loaded from a PCH.


This seems like the right approach to me.  Mismatches in
a precompiled header should be diagnosed when the header is
being compiled, so the only ones involving its uses should
be between classes defined in it and declared or referenced
outside it.  I've implemented this in the attached revision.

Martin




Re: [patch,avr, 2/3] Support 64-bit (long) double: The libgcc changes.

2019-12-16 Thread Georg-Johann Lay

Am 16.12.19 um 17:40 schrieb Georg-Johann Lay:

Patch 2/3 is the libgcc additions:

--with-libf7 selects which makefile-snips from libf7 to use.

libgcc/
* config.host (tmake_file) [target=avr]: Add t-libf7,
t-libf7-math, t-libf7-math-symbols as specified by --with-libf7=.
* config/avr/t-avrlibc: Don't copy libgcc.a if there are modules
depending on sizeof (double) or sizeof (long double).
* config/avr/libf7: New folder.
Index: libgcc/config.host
===
--- libgcc/config.host	(revision 278552)
+++ libgcc/config.host	(working copy)
@@ -514,6 +514,29 @@ arm*-*-eabi* | arm*-*-symbianelf* | arm*
 avr-*-*)
 	# Make HImode functions for AVR
 	tmake_file="${cpu_type}/t-avr t-fpbit"
+	# Make some DFmode functions from libf7, part of avr-libgcc.
+	# This must be prior to adding t-avrlibc.
+	case "y${with_libf7}" in
+	yno)
+	# No libf7 support.
+	;;
+	ylibgcc)
+		tmake_file="$tmake_file ${cpu_type}/libf7/t-libf7"
+		;;
+	ymath)
+		tmake_file="$tmake_file ${cpu_type}/libf7/t-libf7-math"
+		tmake_file="$tmake_file ${cpu_type}/libf7/t-libf7"
+		;;
+	ymath-symbols | yyes | y)
+		tmake_file="$tmake_file ${cpu_type}/libf7/t-libf7-math-symbols"
+		tmake_file="$tmake_file ${cpu_type}/libf7/t-libf7-math"
+		tmake_file="$tmake_file ${cpu_type}/libf7/t-libf7"
+		;;
+	*)
+		echo "Error: --with-libf7=${with_libf7} but can only be used with: 'libgcc', 'math', 'math-symbols', 'yes', 'no'" 1>&2
+		exit 1
+		;;
+	esac
 	if test x${with_avrlibc} != xno; then
 	tmake_file="$tmake_file ${cpu_type}/t-avrlibc"
 	fi
Index: libgcc/config/avr/t-avrlibc
===
--- libgcc/config/avr/t-avrlibc	(revision 278992)
+++ libgcc/config/avr/t-avrlibc	(working copy)
@@ -65,6 +65,12 @@ LIB2FUNCS_EXCLUDE += \
 	_fixunssfdi \
 	_floatdisf _floatundisf
 
+ifeq (,$(WITH_LIBF7_MATH_SYMBOLS))
+
+# No modules depend on __SIZEOF_LONG_DOUBLE__ or __SIZEOF_DOUBLE__
+# which means we might have an opportunity to copy libgcc.a.
+# WITH_LIBF7_MATH_SYMBOLS is set by libf7/t-libf7-math-symbols.
+
 ifneq (,$(findstring avr,$(MULTISUBDIR)))
 
 # We are not in the avr2 (default) subdir, hence copying will work.
@@ -95,3 +101,4 @@ Makefile: t-copy-libgcc.dep
 
 endif
 endif
+endif


[patch,avr, 0/3] Support 64-bit (long) double.

2019-12-16 Thread Georg-Johann Lay
Now that the avr backend can support 64-bit floats by means of 
configure-options --with-double= and --with-long-double=, this patch 
series adds some routines to support it.


It's an ad-hoc, avr-specific implementation in assembly and GNU-C which 
is added as a new subfolder in libgcc/config/avr/libf7.


Patch 1/3 is the GCC changes: Documentation and new avr-specific 
configure options:


--with-libf7 selects to which level double support from libf7 is added 
to libgcc.


--with-double-comparison select what FLOAT_LIB_COMPARE_RETURNS_BOOL returns.

I wrote the libf7 code from scratch and put it under GPL v3 + library 
exception, so it should be no problem to have it as part of libgcc.


Patch 2/3 is the libgcc additions:

--with-libf7 selects which makefile-snips from libf7 to use.

Patch 3/3 is the actual libf7 implementation.  A great deal of which is 
assembly, together with C + inline assembly for higher routines.


Ok for trunk?

Johann


Re: [PATCH, GCC/ARM, 2/10] Add command line support for Armv8.1-M Mainline

2019-12-16 Thread Mihail Ionescu

Hi Kyrill

On 11/06/2019 03:59 PM, Kyrill Tkachov wrote:

Hi Mihail,

On 11/4/19 4:49 PM, Kyrill Tkachov wrote:

Hi Mihail,

On 10/23/19 10:26 AM, Mihail Ionescu wrote:
> [PATCH, GCC/ARM, 2/10] Add command line support
>
> Hi,
>
> === Context ===
>
> This patch is part of a patch series to add support for Armv8.1-M
> Mainline Security Extensions architecture. Its purpose is to add
> command-line support for that new architecture.
>
> === Patch description ===
>
> Besides the expected enabling of the new value for the -march
> command-line option (-march=armv8.1-m.main) and its extensions (see
> below), this patch disables support of the Security Extensions for this
> newly added architecture. This is done both by not including the cmse
> bit in the architecture description and by throwing an error message
> when user request Armv8.1-M Mainline Security Extensions. Note that
> Armv8-M Baseline and Mainline Security Extensions are still enabled.
>
> Only extensions for already supported instructions are implemented in
> this patch. Other extensions (MVE integer and float) will be added in
> separate patches. The following configurations are allowed for 
Armv8.1-M

> Mainline with regards to FPU and implemented in this patch:
> + no FPU (+nofp)
> + single precision VFPv5 with FP16 (+fp)
> + double precision VFPv5 with FP16 (+fp.dp)
>
> ChangeLog entry are as follow:
>
> *** gcc/ChangeLog ***
>
> 2019-10-23  Mihail-Calin Ionescu 
> 2019-10-23  Thomas Preud'homme 
>
>     * config/arm/arm-cpus.in (armv8_1m_main): New feature.
>     (ARMv4, ARMv4t, ARMv5t, ARMv5te, ARMv5tej, ARMv6, ARMv6j, 
ARMv6k,
>     ARMv6z, ARMv6kz, ARMv6zk, ARMv6t2, ARMv6m, ARMv7, ARMv7a, 
ARMv7ve,

>     ARMv7r, ARMv7m, ARMv7em, ARMv8a, ARMv8_1a, ARMv8_2a, ARMv8_3a,
>     ARMv8_4a, ARMv8_5a, ARMv8m_base, ARMv8m_main, ARMv8r): 
Reindent.

>     (ARMv8_1m_main): New feature group.
>     (armv8.1-m.main): New architecture.
>     * config/arm/arm-tables.opt: Regenerate.
>     * config/arm/arm.c (arm_arch8_1m_main): Define and default
> initialize.
>     (arm_option_reconfigure_globals): Initialize arm_arch8_1m_main.
>     (arm_options_perform_arch_sanity_checks): Error out when 
targeting

>     Armv8.1-M Mainline Security Extensions.
>     * config/arm/arm.h (arm_arch8_1m_main): Declare.
>
> *** gcc/testsuite/ChangeLog ***
>
> 2019-10-23  Mihail-Calin Ionescu 
> 2019-10-23  Thomas Preud'homme 
>
>     * lib/target-supports.exp
> (check_effective_target_arm_arch_v8_1m_main_ok): Define.
>     (add_options_for_arm_arch_v8_1m_main): Likewise.
> (check_effective_target_arm_arch_v8_1m_main_multilib): Likewise.
>
> Testing: bootstrapped on arm-linux-gnueabihf and arm-none-eabi; 
testsuite

> shows no regression.
>
> Is this ok for trunk?
>
Ok.



Something that I remembered last night upon reflection...

New command-line options (or arguments to them) need documentation in 
invoke.texi.


Please add some either as part of this patch or as a separate patch if 
you prefer.



I've added the missing cli options in invoke.texi.

Here's the updated ChangeLog:

2019-12-06  Mihail-Calin Ionescu  
2019-12-16  Thomas Preud'homme  

* config/arm/arm-cpus.in (armv8_1m_main): New feature.
(ARMv4, ARMv4t, ARMv5t, ARMv5te, ARMv5tej, ARMv6, ARMv6j, ARMv6k,
ARMv6z, ARMv6kz, ARMv6zk, ARMv6t2, ARMv6m, ARMv7, ARMv7a, ARMv7ve,
ARMv7r, ARMv7m, ARMv7em, ARMv8a, ARMv8_1a, ARMv8_2a, ARMv8_3a,
ARMv8_4a, ARMv8_5a, ARMv8m_base, ARMv8m_main, ARMv8r): Reindent.
(ARMv8_1m_main): New feature group.
(armv8.1-m.main): New architecture.
* config/arm/arm-tables.opt: Regenerate.
* config/arm/arm.c (arm_arch8_1m_main): Define and default initialize.
(arm_option_reconfigure_globals): Initialize arm_arch8_1m_main.
(arm_options_perform_arch_sanity_checks): Error out when targeting
Armv8.1-M Mainline Security Extensions.
* config/arm/arm.h (arm_arch8_1m_main): Declare.
* doc/invoke.texi: Document armv8.1-m.main.

*** gcc/testsuite/ChangeLog ***

2019-12-16  Mihail-Calin Ionescu  
2019-12-16  Thomas Preud'homme  

* lib/target-supports.exp
(check_effective_target_arm_arch_v8_1m_main_ok): Define.
(add_options_for_arm_arch_v8_1m_main): Likewise.
(check_effective_target_arm_arch_v8_1m_main_multilib): Likewise.


Regards,
Mihail


Thanks,

Kyrill



Thanks,

Kyrill


> Best regards,
>
> Mihail
>
>
> ### Attachment also inlined for ease of reply
> ###
>
>
> diff --git a/gcc/config/arm/arm-cpus.in b/gcc/config/arm/arm-cpus.in
> index
> 
f8a3b3db67a537163bfe787d78c8f2edc4253ab3..652f2a4be9388fd7a74f0ec4615a292fd1cfcd36 


> 100644
> --- a/gcc/config/arm/arm-cpus.in
> +++ b/gcc/config/arm/arm-cpus.in
> @@ -126,6 +126,9 @@ define feature armv8_5
>  # M-Profile security extensions.
>  define feature cmse
>
> +# Architecture rel 8.1-M.
> +define feature armv8_1m_main
> +

Re: [PATCH, GCC/ARM, 3/10] Save/restore FPCXTNS in nsentry functions

2019-12-16 Thread Mihail Ionescu


Hi Kyrill,

On 11/06/2019 04:12 PM, Kyrill Tkachov wrote:

Hi Mihail,

On 10/23/19 10:26 AM, Mihail Ionescu wrote:

[PATCH, GCC/ARM, 3/10] Save/restore FPCXTNS in nsentry functions

Hi,

=== Context ===

This patch is part of a patch series to add support for Armv8.1-M
Mainline Security Extensions architecture. Its purpose is to enable
saving/restoring of nonsecure FP context in function with the
cmse_nonsecure_entry attribute.

=== Motivation ===

In Armv8-M Baseline and Mainline, the FP context is cleared on return 
from

nonsecure entry functions. This means the FP context might change when
calling a nonsecure entry function. This patch uses the new VLDR and
VSTR instructions available in Armv8.1-M Mainline to save/restore the FP
context when calling a nonsecure entry functionfrom nonsecure code.

=== Patch description ===

This patch consists mainly of creating 2 new instruction patterns to
push and pop special FP registers via vldm and vstr and using them in
prologue and epilogue. The patterns are defined as push/pop with an
unspecified operation on the memory accessed, with an unspecified
constant indicating what special FP register is being saved/restored.

Other aspects of the patch include:
  * defining the set of special registers that can be saved/restored and
    their name
  * reserving space in the stack frames for these push/pop
  * preventing return via pop
  * guarding the clearing of FPSCR to target architecture not having
    Armv8.1-M Mainline instructions.

ChangeLog entry is as follows:

*** gcc/ChangeLog ***

2019-10-23  Mihail-Calin Ionescu 
2019-10-23  Thomas Preud'homme 

    * config/arm/arm.c (fp_sysreg_names): Declare and define.
    (use_return_insn): Also return false for Armv8.1-M Mainline.
    (output_return_instruction): Skip FPSCR clearing if Armv8.1-M
    Mainline instructions are available.
    (arm_compute_frame_layout): Allocate space in frame for FPCXTNS
    when targeting Armv8.1-M Mainline Security Extensions.
    (arm_expand_prologue): Save FPCXTNS if this is an Armv8.1-M
    Mainline entry function.
    (cmse_nonsecure_entry_clear_before_return): Clear IP and r4 if
    targeting Armv8.1-M Mainline or successor.
    (arm_expand_epilogue): Fix indentation of caller-saved register
    clearing.  Restore FPCXTNS if this is an Armv8.1-M Mainline
    entry function.
    * config/arm/arm.h (TARGET_HAVE_FP_CMSE): New macro.
    (FP_SYSREGS): Likewise.
    (enum vfp_sysregs_encoding): Define enum.
    (fp_sysreg_names): Declare.
    * config/arm/unspecs.md (VUNSPEC_VSTR_VLDR): New volatile unspec.
    * config/arm/vfp.md (push_fpsysreg_insn): New define_insn.
    (pop_fpsysreg_insn): Likewise.

*** gcc/testsuite/Changelog ***

2019-10-23  Mihail-Calin Ionescu 
2019-10-23  Thomas Preud'homme 

    * gcc.target/arm/cmse/bitfield-1.c: add checks for VSTR and VLDR.
    * gcc.target/arm/cmse/bitfield-2.c: Likewise.
    * gcc.target/arm/cmse/bitfield-3.c: Likewise.
    * gcc.target/arm/cmse/cmse-1.c: Likewise.
    * gcc.target/arm/cmse/struct-1.c: Likewise.
    * gcc.target/arm/cmse/cmse.exp: Run existing Armv8-M Mainline 
tests
    from mainline/8m subdirectory and new Armv8.1-M Mainline tests 
from

    mainline/8_1m subdirectory.
    * gcc.target/arm/cmse/mainline/bitfield-4.c: Move into ...
    * gcc.target/arm/cmse/mainline/8m/bitfield-4.c: This.
    * gcc.target/arm/cmse/mainline/bitfield-5.c: Move into ...
    * gcc.target/arm/cmse/mainline/8m/bitfield-5.c: This.
    * gcc.target/arm/cmse/mainline/bitfield-6.c: Move into ...
    * gcc.target/arm/cmse/mainline/8m/bitfield-6.c: This.
    * gcc.target/arm/cmse/mainline/bitfield-7.c: Move into ...
    * gcc.target/arm/cmse/mainline/8m/bitfield-7.c: This.
    * gcc.target/arm/cmse/mainline/bitfield-8.c: Move into ...
    * gcc.target/arm/cmse/mainline/8m/bitfield-8.c: This.
    * gcc.target/arm/cmse/mainline/bitfield-9.c: Move into ...
    * gcc.target/arm/cmse/mainline/8m/bitfield-9.c: This.
    * gcc.target/arm/cmse/mainline/bitfield-and-union-1.c: Move 
and rename

    into ...
    * gcc.target/arm/cmse/mainline/8m/bitfield-and-union.c: This.
    * gcc.target/arm/cmse/mainline/hard-sp/cmse-13.c: Move into ...
    * gcc.target/arm/cmse/mainline/8m/hard-sp/cmse-13.c: This. 
Clean up

    dg-skip-if directive for float ABI.
    * gcc.target/arm/cmse/mainline/hard-sp/cmse-5.c: Move into ...
    * gcc.target/arm/cmse/mainline/8m/hard-sp/cmse-5.c: This. 
Clean up

    dg-skip-if directive for float ABI.
    * gcc.target/arm/cmse/mainline/hard-sp/cmse-7.c: Move into ...
    * gcc.target/arm/cmse/mainline/8m/hard-sp/cmse-7.c: This. 
Clean up

    dg-skip-if directive for float ABI.
    * gcc.target/arm/cmse/mainline/hard-sp/cmse-8.c: Move into ...
    * gcc.target/arm/cmse/mainline/8m/hard-sp/cmse-8.c: This. 
Clean 

Re: [PATCH 05/45] Add pp_write_text_as_html_like_dot_to_stream

2019-12-16 Thread David Malcolm
On Fri, 2019-12-13 at 13:10 -0500, David Malcolm wrote:
> gcc/ChangeLog:
>   * pretty-print.c (pp_write_text_as_html_like_dot_to_stream):
> New
>   function.
>   * pretty-print.h (pp_write_text_as_html_like_dot_to_stream):
> New decl.
> ---
>  gcc/pretty-print.c | 48
> ++
>  gcc/pretty-print.h |  3 +++
>  2 files changed, 51 insertions(+)

I've self-approved this one and committed it to trunk as r279444
(with usual bootstrap testing)

Dave




[OpenACC, patch] Fix implicit mapping in enclosed 'acc data' constructions

2019-12-16 Thread Tobias Burnus
Currently, GCC uses *implicit 'copy'* for variables in a 
parallel/kernels construct, even though they are in a data clause of the 
enclosing *data construct*.


Example – will currently yield an an implicit 'copy(var)' in the 'parallel 
construct':
   … acc data copyout(var)
   … acc parallel
   var = 5

In the spec for OpenACC 2.6 or 2.7, one can find in the 'kernels 
Construction' and 'parallel Construction' towards the end of the 
'Description', the following wording:


"If there is no default(none) clause on the construct, the compiler will 
implicitly determine data attributes for variables that are referenced 
in the compute construct that do not have predetermined data attributes 
and do not appear in a data clause on the compute construct, a lexically 
containing data construct, or a visible declare directive. […] A scalar 
variable referenced in the kernels construct that does not appear in a 
data clause for the construct or any enclosing data construct will be 
treated as if it appeared in a copy clause."


(OpenACC 2+6 and 2.7 for kernels; for parallel, read as 
s/kernels/parallel/ and s/copy clause/firstprivate clause/ in the last 
sentence.)


That GCC uses a 'copy (or 'map(tofrom:') is an effect of the commit 
commit r230169 (GIT: b656be3a5e5d499ed45dba75943861a14d3aec55; Wed Nov 
11 14:24:09 2015 +), see 
https://gcc.gnu.org/ml/gcc-patches/2015-11/msg00809.html


The issue with the copy was noted by Thomas in 
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00147.html


This patch simply avoids the mapping in this case – while keeping the 
host data part.


OK for the trunk? Or have I missed some fine print/corner cases?

Cheers,

Tobias

	gcc/
	* gimplify.c (omp_notice_variable): For OpenACC, don't imply copy clause
	for variables which appear in a data clause of the enclosing target/data
	context.
	
	gcc/testsuite/
	* c-c++-common/goacc/default-4.c: Update expected tree dump.
	* c-c++-common/goacc/deviceptr-4.c: Likewise.
	* gfortran.dg/goacc/default-4.f: Likewise.

	libgomp/
	* testsuite/libgomp.oacc-fortran/implicit-mapping.F90: New.

diff --git a/gcc/gimplify.c b/gcc/gimplify.c
index 9073680cb31..22e92393e7f 100644
--- a/gcc/gimplify.c
+++ b/gcc/gimplify.c
@@ -7471,37 +7471,48 @@ omp_notice_variable (struct gimplify_omp_ctx *ctx, tree decl, bool in_code)
 	  if ((ctx->region_type & ORT_ACC) && octx)
 	{
 	  /* Look in outer OpenACC contexts, to see if there's a
 		 data attribute for this variable.  */
 	  omp_notice_variable (octx, decl, in_code);
 
 	  for (; octx; octx = octx->outer_context)
 		{
 		  if (!(octx->region_type & (ORT_TARGET_DATA | ORT_TARGET)))
 		break;
 		  splay_tree_node n2
 		= splay_tree_lookup (octx->variables,
 	 (splay_tree_key) decl);
 		  if (n2)
 		{
 		  if (octx->region_type == ORT_ACC_HOST_DATA)
 		error ("variable %qE declared in enclosing "
 			   "% region", DECL_NAME (decl));
-		  nflags |= GOVD_MAP;
+		  /* Already mapped in outer context; hence, no implicit
+			 mapping. For 'acc data', we still need to add a
+			 present() to associate the identifier with the
+			 device data. */
+		  if (octx->region_type & ORT_TARGET
+			  && n2->value & (GOVD_FIRSTPRIVATE | GOVD_MAP))
+			return ret;
+		  if (octx->region_type & ORT_TARGET_DATA
+			  && n2->value & GOVD_MAP)
+			nflags |= GOVD_MAP | GOVD_MAP_FORCE_PRESENT;
+		  else
+			nflags |= GOVD_MAP;
 		  if (octx->region_type == ORT_ACC_DATA
 			  && (n2->value & GOVD_MAP_0LEN_ARRAY))
 			nflags |= GOVD_MAP_0LEN_ARRAY;
 		  goto found_outer;
 		}
 		}
 	}
 
 	  if ((nflags & ~(GOVD_MAP_TO_ONLY | GOVD_MAP_FROM_ONLY
 			  | GOVD_MAP_ALLOC_ONLY)) == flags)
 	{
 	  tree type = TREE_TYPE (decl);
 
 	  if (gimplify_omp_ctxp->target_firstprivatize_array_bases
 		  && lang_hooks.decls.omp_privatize_by_reference (decl))
 		type = TREE_TYPE (type);
 	  if (!lang_hooks.types.omp_mappable_type (type))
 		{
diff --git a/gcc/testsuite/c-c++-common/goacc/default-4.c b/gcc/testsuite/c-c++-common/goacc/default-4.c
index 867175d4847..76deaf36d25 100644
--- a/gcc/testsuite/c-c++-common/goacc/default-4.c
+++ b/gcc/testsuite/c-c++-common/goacc/default-4.c
@@ -1,66 +1,66 @@
 /* OpenACC default clause inside data construct.  */
 
 /* { dg-additional-options "-fdump-tree-gimple" } */
 
 void f1 ()
 {
   int f1_a = 2;
   float f1_b[2];
 
 #pragma acc data copyin (f1_a) copyout (f1_b)
   /* { dg-final { scan-tree-dump-times "omp target oacc_data map\\(from:f1_b \[^\\)\]+\\) map\\(to:f1_a" 1 "gimple" } } */
   {
 #pragma acc kernels
-/* { dg-final { scan-tree-dump-times "omp target oacc_kernels map\\(tofrom:f1_b \[^\\)\]+\\) map\\(tofrom:f1_a" 1 "gimple" } } */
+/* { dg-final { scan-tree-dump-times "omp target oacc_kernels map\\(force_present:f1_b \[^\\)\]+\\) map\\(force_present:f1_a" 1 "gimple" } } */
 {
   f1_b[0] = f1_a;
 }
 #pragma acc parallel
-/* { dg-final { scan-tree-dump-times "omp target 

Re: [PATCH, GCC/ARM, 4/10] Clear GPR with CLRM

2019-12-16 Thread Mihail Ionescu

Hi Kyrill,

On 11/12/2019 09:55 AM, Kyrill Tkachov wrote:

Hi Mihail,

On 10/23/19 10:26 AM, Mihail Ionescu wrote:

[PATCH, GCC/ARM, 4/10] Clear GPR with CLRM

Hi,

=== Context ===

This patch is part of a patch series to add support for Armv8.1-M
Mainline Security Extensions architecture. Its purpose is to improve
code density of functions with the cmse_nonsecure_entry attribute and
when calling function with the cmse_nonsecure_call attribute by using
CLRM to do all the general purpose registers clearing as well as
clearing the APSR register.

=== Patch description ===

This patch adds a new pattern for the CLRM instruction and guards the
current clearing code in output_return_instruction() and thumb_exit()
on Armv8.1-M Mainline instructions not being present.
cmse_clear_registers () is then modified to use the new CLRM instruction
when targeting Armv8.1-M Mainline while keeping Armv8-M register
clearing code for VFP registers.

For the CLRM instruction, which does not mandated APSR in the register
list, checking whether it is the right volatile unspec or a clearing
register is done in clear_operation_p.

Note that load/store multiple were deemed sufficiently different in
terms of RTX structure compared to the CLRM pattern for a different
function to be used to validate the match_parallel.

ChangeLog entries are as follows:

*** gcc/ChangeLog ***

2019-10-23  Mihail-Calin Ionescu 
2019-10-23  Thomas Preud'homme 

    * config/arm/arm-protos.h (clear_operation_p): Declare.
    * config/arm/arm.c (clear_operation_p): New function.
    (cmse_clear_registers): Generate clear_multiple instruction 
pattern if

    targeting Armv8.1-M Mainline or successor.
    (output_return_instruction): Only output APSR register 
clearing if

    Armv8.1-M Mainline instructions not available.
    (thumb_exit): Likewise.
    * config/arm/predicates.md (clear_multiple_operation): New 
predicate.

    * config/arm/thumb2.md (clear_apsr): New define_insn.
    (clear_multiple): Likewise.
    * config/arm/unspecs.md (VUNSPEC_CLRM_APSR): New volatile unspec.

*** gcc/testsuite/ChangeLog ***

2019-10-23  Mihail-Calin Ionescu 
2019-10-23  Thomas Preud'homme 

    * gcc.target/arm/cmse/bitfield-1.c: Add check for CLRM.
    * gcc.target/arm/cmse/bitfield-2.c: Likewise.
    * gcc.target/arm/cmse/bitfield-3.c: Likewise.
    * gcc.target/arm/cmse/struct-1.c: Likewise.
    * gcc.target/arm/cmse/cmse-14.c: Likewise.
    * gcc.target/arm/cmse/cmse-1.c: Likewise.  Restrict checks for 
Armv8-M

    GPR clearing when CLRM is not available.
    * gcc.target/arm/cmse/mainline/8_1m/bitfield-4.c: Likewise.
    * gcc.target/arm/cmse/mainline/8_1m/bitfield-5.c: Likewise.
    * gcc.target/arm/cmse/mainline/8_1m/bitfield-6.c: Likewise.
    * gcc.target/arm/cmse/mainline/8_1m/bitfield-7.c: Likewise.
    * gcc.target/arm/cmse/mainline/8_1m/bitfield-8.c: Likewise.
    * gcc.target/arm/cmse/mainline/8_1m/bitfield-9.c: Likewise.
    * gcc.target/arm/cmse/mainline/8_1m/hard-sp/cmse-13.c: Likewise.
    * gcc.target/arm/cmse/mainline/8_1m/hard-sp/cmse-5.c: Likewise.
    * gcc.target/arm/cmse/mainline/8_1m/hard-sp/cmse-7.c: Likewise.
    * gcc.target/arm/cmse/mainline/8_1m/hard-sp/cmse-8.c: Likewise.
    * gcc.target/arm/cmse/mainline/8_1m/hard/cmse-13.c: Likewise.
    * gcc.target/arm/cmse/mainline/8_1m/hard/cmse-5.c: likewise.
    * gcc.target/arm/cmse/mainline/8_1m/hard/cmse-7.c: likewise.
    * gcc.target/arm/cmse/mainline/8_1m/hard/cmse-8.c: likewise.
    * gcc.target/arm/cmse/mainline/8_1m/soft/cmse-13.c: Likewise.
    * gcc.target/arm/cmse/mainline/8_1m/soft/cmse-5.c: Likewise.
    * gcc.target/arm/cmse/mainline/8_1m/soft/cmse-7.c: Likewise.
    * gcc.target/arm/cmse/mainline/8_1m/soft/cmse-8.c: Likewise.
    * gcc.target/arm/cmse/mainline/8_1m/softfp-sp/cmse-5.c: Likewise.
    * gcc.target/arm/cmse/mainline/8_1m/softfp-sp/cmse-7.c: Likewise.
    * gcc.target/arm/cmse/mainline/8_1m/softfp-sp/cmse-8.c: Likewise.
    * gcc.target/arm/cmse/mainline/8_1m/softfp/cmse-13.c: Likewise.
    * gcc.target/arm/cmse/mainline/8_1m/softfp/cmse-5.c: Likewise.
    * gcc.target/arm/cmse/mainline/8_1m/softfp/cmse-7.c: Likewise.
    * gcc.target/arm/cmse/mainline/8_1m/softfp/cmse-8.c: Likewise.
    * gcc.target/arm/cmse/mainline/8_1m/union-1.c: Likewise.
    * gcc.target/arm/cmse/mainline/8_1m/union-2.c: Likewise.

Testing: bootstrapped on arm-linux-gnueabihf and testsuite shows no
regression.

Is this ok for trunk?

Best regards,

Mihail


### Attachment also inlined for ease of reply 
###



diff --git a/gcc/config/arm/arm-protos.h b/gcc/config/arm/arm-protos.h
index 
f995974f9bb89ab3c7ff0888c394b0dfaf7da60c..1a948d2c97526ad7e67e8d4a610ac74cfdb13882 
100644

--- a/gcc/config/arm/arm-protos.h
+++ b/gcc/config/arm/arm-protos.h
@@ -77,6 +77,7 @@ extern int 

Re: [patch] libgomp/openacc.f90 – clean-up public/private attributes

2019-12-16 Thread Thomas Schwinge
Hi Tobias!

On 2019-12-11T13:47:51+0100, Tobias Burnus  wrote:
> This patch cleans up the public/private handling in libgomp/openacc.f90:
>
> * module openacc_kinds marked symbols explicitly as public and private 
> (but default is public). Make this explicit by a 'PUBLIC' and remove the 
> (redundant) explicit 'public :: ' lines.
>
> * 'module openacc' had a bunch of 'public :: ' lines but the default was 
> already 'public'. Changed this to 'private' and marked the 
> use-associated 'openacc_kinds' symbols as 'public' and added 'public' 
> statements for the two missing items. (Net effect: this will hide all 
> openacc_internal symbols.)
>
> I think this patch is rather obvious. Nonetheless: are the comments?

Sounds good, don't have any comments on the Fortran details ;-) -- but
I'll point out there also exists 'libgomp/config/accel/openacc.f90',
which probably needs similar treatment?

> (If not, I will commit it in the next days.)

(Got committed in r279337.)

> PS: I found the two missing symbols by looking at the 'interface ' 
> lines; 'module openacc' has only those + the version symbol.

Ouch.  Ah, no: you said "the default was already 'public'" -- so there's
no need to backport that to gcc-9-branch, so that 'acc_copyout_finalize',
'acc_delete_finalize' will be available for OpenACC Fortran users.

(These functions are, what would you expect, no covered by any test case
in 'libgomp.oacc-fortran/'...)


A few comments anyway:

> --- a/libgomp/openacc.f90
> +++ b/libgomp/openacc.f90
> @@ -31,13 +31,12 @@ module openacc_kinds
>use iso_fortran_env, only: int32
>implicit none
>  
> +  public
>private :: int32
> -  public :: acc_device_kind
>  
> -  integer, parameter :: acc_device_kind = int32
> +  ! When adding items, also update 'public' setting in 'module openmp' below.

This isn't "'module openmp'".  ;-)

>  
> -  public :: acc_device_none, acc_device_default, acc_device_host
> -  public :: acc_device_not_host, acc_device_nvidia

(So this was missing 'acc_device_gcn' -- but 'public' was the default.)

> +  integer, parameter :: acc_device_kind = int32
>  
>! Keep in sync with include/gomp-constants.h.
>integer (acc_device_kind), parameter :: acc_device_none = 0
> @@ -48,16 +47,11 @@ module openacc_kinds
>integer (acc_device_kind), parameter :: acc_device_nvidia = 5
>integer (acc_device_kind), parameter :: acc_device_gcn = 8
>  
> -  public :: acc_handle_kind
> -
>integer, parameter :: acc_handle_kind = int32
>  
> -  public :: acc_async_noval, acc_async_sync
> -
>! Keep in sync with include/gomp-constants.h.
>integer (acc_handle_kind), parameter :: acc_async_noval = -1
>integer (acc_handle_kind), parameter :: acc_async_sync = -2
> -
>  end module
>  
>  module openacc_internal
> @@ -717,6 +711,13 @@ module openacc
>use openacc_internal
>implicit none
>  
> +  private
> +  ! From openacc_kinds
> +  public :: acc_device_kind, acc_handle_kind
> +  public :: acc_device_none, acc_device_default, acc_device_host
> +  public :: acc_device_not_host, acc_device_nvidia, acc_device_gcn
> +  public :: acc_async_noval, acc_async_sync
> +

Some vertical space before the "From openacc_kinds" comment, and before
the 'acc_async_*' ones?

>public :: openacc_version
>  
>public :: acc_get_num_devices, acc_set_device_type, acc_get_device_type
> @@ -730,6 +731,7 @@ module openacc
>public :: acc_update_device, acc_update_self, acc_is_present
>public :: acc_copyin_async, acc_create_async, acc_copyout_async
>public :: acc_delete_async, acc_update_device_async, acc_update_self_async
> +  public :: acc_copyout_finalize, acc_delete_finalize

Put these into the place where they really belong, after 'acc_copyout,
and 'acc_delete', respectively?


Grüße
 Thomas


signature.asc
Description: PGP signature


Re: [Patch, fortran] PR92753 - [9/10 Regression] ICE in gfc_trans_call, at fortran/trans-stmt.c:392

2019-12-16 Thread Thomas Koenig

Hi Paul,


Regtested on FC31/x86_64 - OK for 9- and 10- branches?


OK. Thanks for the patch!

Regards

Thomas


Re: [PING^4] Re: [PATCH 1/2] Add a pass to automatically add ptwrite instrumentation

2019-12-16 Thread Andi Kleen
Andi Kleen  writes:

Ping!

> Andi Kleen  writes:
>
> Ping!
>
>> Andi Kleen  writes:
>>
>> Ping!
>>
>>> Andi Kleen  writes:
>>>
>>> Ping!
>>>
 From: Andi Kleen 

 [v4: Rebased on current tree. Avoid some redundant log statements
 for locals and a few other fixes.  Fix some comments. Improve
 documentation. Did some studies on the debug information quality,
 see below]

 Add a new pass to automatically instrument changes to variables
 with the new PTWRITE instruction on x86. PTWRITE writes a 4 or 8 byte
 field into an Processor Trace log, which allows low over head
 logging of information. Essentially it's a hardware accelerated
 printf.


Re: C++ PATCH for c++/88337 - Implement P1327R1: Allow dynamic_cast in constexpr

2019-12-16 Thread Jason Merrill

On 12/14/19 4:25 PM, Marek Polacek wrote:

On Fri, Dec 13, 2019 at 05:56:57PM -0500, Jason Merrill wrote:

On 12/13/19 3:20 PM, Marek Polacek wrote:

+  /* Given dynamic_cast(v),
+
+ [expr.dynamic.cast] If C is the class type to which T points or refers,
+ the runtime check logically executes as follows:
+
+ If, in the most derived object pointed (referred) to by v, v points
+ (refers) to a public base class subobject of a C object, and if only
+ one object of type C is derived from the subobject pointed (referred)
+ to by v the result points (refers) to that C object.
+
+ In this case, HINT >= 0.  */
+  if (hint >= 0)


Won't this code work for hint == -3 as well?


Yes, it does.  In fact, none of the tests was testing the hint == -3 case, so
I've fixed the code up and added constexpr-dynamic15.C to test it.


+{
+  /* Look for a component with type TYPE.  */
+  obj = get_component_with_type (obj, type);


You don't seem to use mdtype at all in this case.  Shouldn't
get_component_with_type stop at mdtype if it hasn't found type yet?


It was used for diagnostics but not in get_component_with_type.  It makes
sense to stop at MDTYPE; I've adjusted the code to do so.  E.g., if
we have OBJ in the form of g.D.2121.D.2122.D.2123.D.2124, usually the
component with the most derived type is "g", but in a 'tor, it can be
a different component too.


+  /* If not found or not accessible, give an error.  */
+  if (obj == NULL_TREE || obj == error_mark_node)
+   {
+ if (reference_p)
+   {
+ if (!ctx->quiet)
+   {
+ error_at (loc, "reference % failed");
+ if (obj == NULL_TREE)
+   inform (loc, "dynamic type %qT of its operand does not "
+   "have an unambiguous public base class %qT",
+   mdtype, type);
+ else
+   inform (loc, "static type %qT of its operand is a "
+   "non-public base class of dynamic type %qT",
+   objtype, type);
+
+   }
+ *non_constant_p = true;
+   }
+ return integer_zero_node;
+   }
+  else
+   /* The result points to the TYPE object.  */
+   return cp_build_addr_expr (obj, complain);
+}
+  /* Otherwise, if v points (refers) to a public base class subobject of the
+ most derived object, and the type of the most derived object has a base
+ class, of type C, that is unambiguous and public, the result points
+ (refers) to the C subobject of the most derived object.
+
+ But it can also be an invalid case.  */


And I think we need to fall through to this code if the hint turns out to be
wrong, i.e. V is a public base of C, but v is not that subobject, but rather
a sibling base of C, like


True.  HINT is really just an optimization hint, nothing more.  I've adjusted
the code to fall through to the normal processing if the HINT >= 0 or -3 case
doesn't succeed.


struct A { virtual void f(); };
struct B1: A { };
struct B2: A { };
struct C: B1, B2 { };
int main()
{
   C c;
   A* ap = (B1*)c;
   constexpr auto p = dynamic_cast(ap); // should succeed
}


Whew, there's always One More Case. :/  New constexpr-dynamic16.c covers it.


--- /dev/null
+++ gcc/testsuite/g++.dg/cpp2a/constexpr-dynamic11.C
@@ -0,0 +1,34 @@
+// PR c++/88337 - Implement P1327R1: Allow dynamic_cast/typeid in constexpr.
+// { dg-do compile { target c++2a } }
+
+// dynamic_cast in a constructor.
+
+struct V {
+  virtual void f();
+};
+
+struct A : V { };
+
+struct B : V {
+  constexpr B(V*, A*);
+};
+
+struct D : A, B {
+  constexpr D() : B((A*)this, this) { } // { dg-message "in 'constexpr' expansion 
of" }
+};
+
+constexpr B::B(V* v, A* a)
+{
+  // well-defined: v of type V*, V base of B results in B*
+  B* b = dynamic_cast(v);
+  if (b != nullptr)
+__builtin_abort ();
+
+  B& br = dynamic_cast(*v); // { dg-error "reference .dynamic_cast. 
failed" }
+// { dg-message "dynamic type .A. of its operand does not have an unambiguous public base 
class .B." "" { target *-*-* } .-1 }
+
+  // FIXME: UB in constexpr should be detected.
+  dynamic_cast(a);  // undefined behavior, a has type A*, A not a 
base of B


What undefined behavior?  Seems to me the dynamic_cast should just fail and
return a null pointer.


This is :
"If the operand of the dynamic_cast refers to the object under construction
or destruction and the static type of the operand is not a pointer to or
object of the constructor or destructor's own class or one of its bases, the
dynamic_cast results in undefined behavior."

Clang++ doesn't detect this either.


Ah, interesting.  That text goes back to C++98.  I guess the reason for 
that was that the vtable pointer might give problematic answers in that 
situation.  It should be straightforward to detect this in constexpr 

Re: C++ PATCH for c++/88337 - Implement P1327R1: Allow dynamic_cast in constexpr

2019-12-16 Thread Jason Merrill

On 12/16/19 3:55 PM, Jason Merrill wrote:

On 12/14/19 4:25 PM, Marek Polacek wrote:

On Fri, Dec 13, 2019 at 05:56:57PM -0500, Jason Merrill wrote:

On 12/13/19 3:20 PM, Marek Polacek wrote:

+  /* Given dynamic_cast(v),
+
+ [expr.dynamic.cast] If C is the class type to which T points 
or refers,

+ the runtime check logically executes as follows:
+
+ If, in the most derived object pointed (referred) to by v, v 
points
+ (refers) to a public base class subobject of a C object, and 
if only
+ one object of type C is derived from the subobject pointed 
(referred)

+ to by v the result points (refers) to that C object.
+
+ In this case, HINT >= 0.  */
+  if (hint >= 0)


Won't this code work for hint == -3 as well?


Yes, it does.  In fact, none of the tests was testing the hint == -3 
case, so

I've fixed the code up and added constexpr-dynamic15.C to test it.


+    {
+  /* Look for a component with type TYPE.  */
+  obj = get_component_with_type (obj, type);


You don't seem to use mdtype at all in this case.  Shouldn't
get_component_with_type stop at mdtype if it hasn't found type yet?


It was used for diagnostics but not in get_component_with_type.  It makes
sense to stop at MDTYPE; I've adjusted the code to do so.  E.g., if
we have OBJ in the form of g.D.2121.D.2122.D.2123.D.2124, usually the
component with the most derived type is "g", but in a 'tor, it can be
a different component too.


+  /* If not found or not accessible, give an error.  */
+  if (obj == NULL_TREE || obj == error_mark_node)
+    {
+  if (reference_p)
+    {
+  if (!ctx->quiet)
+    {
+  error_at (loc, "reference % failed");
+  if (obj == NULL_TREE)
+    inform (loc, "dynamic type %qT of its operand does not "
+    "have an unambiguous public base class %qT",
+    mdtype, type);
+  else
+    inform (loc, "static type %qT of its operand is a "
+    "non-public base class of dynamic type %qT",
+    objtype, type);
+
+    }
+  *non_constant_p = true;
+    }
+  return integer_zero_node;
+    }
+  else
+    /* The result points to the TYPE object.  */
+    return cp_build_addr_expr (obj, complain);
+    }
+  /* Otherwise, if v points (refers) to a public base class 
subobject of the
+ most derived object, and the type of the most derived object 
has a base
+ class, of type C, that is unambiguous and public, the result 
points

+ (refers) to the C subobject of the most derived object.
+
+ But it can also be an invalid case.  */


And I think we need to fall through to this code if the hint turns 
out to be
wrong, i.e. V is a public base of C, but v is not that subobject, but 
rather

a sibling base of C, like


True.  HINT is really just an optimization hint, nothing more.  I've 
adjusted
the code to fall through to the normal processing if the HINT >= 0 or 
-3 case

doesn't succeed.


struct A { virtual void f(); };
struct B1: A { };
struct B2: A { };
struct C: B1, B2 { };
int main()
{
   C c;
   A* ap = (B1*)c;
   constexpr auto p = dynamic_cast(ap); // should succeed
}


Whew, there's always One More Case. :/  New constexpr-dynamic16.c 
covers it.



--- /dev/null
+++ gcc/testsuite/g++.dg/cpp2a/constexpr-dynamic11.C
@@ -0,0 +1,34 @@
+// PR c++/88337 - Implement P1327R1: Allow dynamic_cast/typeid in 
constexpr.

+// { dg-do compile { target c++2a } }
+
+// dynamic_cast in a constructor.
+
+struct V {
+  virtual void f();
+};
+
+struct A : V { };
+
+struct B : V {
+  constexpr B(V*, A*);
+};
+
+struct D : A, B {
+  constexpr D() : B((A*)this, this) { } // { dg-message "in 
'constexpr' expansion of" }

+};
+
+constexpr B::B(V* v, A* a)
+{
+  // well-defined: v of type V*, V base of B results in B*
+  B* b = dynamic_cast(v);
+  if (b != nullptr)
+    __builtin_abort ();
+
+  B& br = dynamic_cast(*v); // { dg-error "reference 
.dynamic_cast. failed" }
+// { dg-message "dynamic type .A. of its operand does not have an 
unambiguous public base class .B." "" { target *-*-* } .-1 }

+
+  // FIXME: UB in constexpr should be detected.
+  dynamic_cast(a);  // undefined behavior, a has type 
A*, A not a base of B


What undefined behavior?  Seems to me the dynamic_cast should just 
fail and

return a null pointer.


This is :
"If the operand of the dynamic_cast refers to the object under 
construction

or destruction and the static type of the operand is not a pointer to or
object of the constructor or destructor's own class or one of its 
bases, the

dynamic_cast results in undefined behavior."

Clang++ doesn't detect this either.


Ah, interesting.  That text goes back to C++98.  I guess the reason for 
that was that the vtable pointer might give problematic answers in that 
situation.  It should be straightforward to detect this in constexpr 
evaluation; if mdtype is not the actual complete 

Re: [PATCH 4/7 libgomp,amdgcn] GCN libgomp port

2019-12-16 Thread Thomas Schwinge
Hi Andrew!

On 2019-11-12T13:29:13+, Andrew Stubbs  wrote:
> Most of these changes are simply based on the model already defined for
> NVPTX, adapted for GCN as appropriate.

> --- a/libgomp/openacc.f90
> +++ b/libgomp/openacc.f90
> @@ -46,6 +46,7 @@ module openacc_kinds
>! integer (acc_device_kind), parameter :: acc_device_host_nonshm = 3 
> removed.
>integer (acc_device_kind), parameter :: acc_device_not_host = 4
>integer (acc_device_kind), parameter :: acc_device_nvidia = 5
> +  integer (acc_device_kind), parameter :: acc_device_gcn = 8

Note that as an alternative to the Fortran 'openacc' module, there also
exists 'openacc_lib.h', which you didn't update here.

As of OpenACC 2.5, 'openacc_lib.h' has been deprecated ("no longer
supported"), but so far, we continued to support it, and it's strange
when that one now works for all but 'acc_device_gcn'?


Grüße
 Thomas


signature.asc
Description: PGP signature