Re: [doc PATCH] document when GCC ignores attribute aligned

[Sandra Loosemore]

On 12/3/18 8:23 PM, Martin Sebor wrote:

Last week we agreed to clarify that attribute aligned on a function
can decrease its alignment if it hasn't been previously declared
with one.  Attached is this change.

Besides the above, I also mention that the attribute specifies
the alignment of the first instruction of the function (in case
that wasn't obvious) , and that it has no effect in the absence
of a definition.

I wrote some tests to convince myself this actually works as
I expected.  Where it does I add those tests to the testsuite
via this patch.  Where it doesn't I opened a bug (PR 88345).

Martin



Index: gcc/doc/extend.texi
===
--- gcc/doc/extend.texi (revision 266766)
+++ gcc/doc/extend.texi (working copy)
@@ -2386,16 +2386,20 @@ and may not be available on all targets.
 @itemx aligned (@var{alignment})
 @cindex @code{aligned} function attribute
 The @code{aligned} attribute specifies a minimum alignment for
-the function, measured in bytes.  When specified, @var{alignment} must
-be an integer constant power of 2.  Specifying no @var{alignment} argument
-implies the maximum alignment for the target, which is often, but by no
-means always, 8 or 16 bytes.
+the first instruction of the function, measured in bytes.  When specified,
+@var{alignment} must be an integer constant power of 2.  Specifying no
+@var{alignment} argument implies the ideal alignment for the target,
+which is often, but by no means always, 8 or 16 bytes.  The attribute


I think you might as well delete the end of the sentence starting with 
"which is often...".  It adds words but no useful information.  (Maybe 
it's 8 bytes, maybe it's 16 bytes, maybe it's something else)



+has no effect when a definition for the function is not provided in
+the same translation unit.
 
-You cannot use this attribute to decrease the alignment of a function,

-only to increase it.  However, when you explicitly specify a function
-alignment this overrides the effect of the
-@option{-falign-functions} (@pxref{Optimize Options}) option for this
-function.
+The attribute cannot be used to decrease the alignment of a function
+previously declared with a more restrictive alignment; only to increase
+it.  Attempts to do otherwise are diagnosed.  Some targets specify
+a minimum default alignment for functions that is greater than 1.  On
+such targets, specifying a less restrictive alignment is silently ignored.
+Using the attribute overrides the effect of the @option{-falign-functions}
+(@pxref{Optimize Options}) option for this function.
 
 Note that the effectiveness of @code{aligned} attributes may be
 limited by inherent limitations in the system linker 


This patch is OK with the above nit fixed.

-Sandra

Re: [doc PATCH] update attribute docs for C++

[Sandra Loosemore]

On 12/3/18 4:23 PM, Martin Sebor wrote:


gcc/ChangeLog:

* doc/extend.texi (attribute const, pure): Clarify.

Index: gcc/doc/extend.texi
===
--- gcc/doc/extend.texi (revision 266766)
+++ gcc/doc/extend.texi (working copy)
@@ -2276,12 +2276,13 @@ the enclosing block.
 @cindex @code{volatile} applied to function
 @cindex @code{const} applied to function
 
-In GNU C, you can use function attributes to declare certain things

-about functions called in your program which help the compiler
-optimize calls and check your code more carefully.  For example, you
+In GNU C and C++, you can use function attributes to declare certain
+function properties that may help the compiler optimize calls or
+check code more carefully for correctness.  For example, you
 can use attributes to declare that a function never returns
-(@code{noreturn}), returns a value depending only on its arguments
-(@code{pure}), or has @code{printf}-style arguments (@code{format}).
+(@code{noreturn}), returns a value depending only on the values of
+its arguments (@code{const}), or has @code{printf}-style arguments
+(@code{format}).
 
 You can also use attributes to control memory placement, code

 generation options or call/return conventions within the function
@@ -2288,12 +2289,15 @@ generation options or call/return conventions with
 being annotated.  Many of these attributes are target-specific.  For
 example, many targets support attributes for defining interrupt
 handler functions, which typically must follow special register usage
-and return conventions.
+and return conventions.  Such attributes are described in the subsection
+for each target.  However, a considerable number of attributes are
+supported by most, if not all targets.  Those are described in
+the @ref{Common Function Attributes} section.
 
 Function attributes are introduced by the @code{__attribute__} keyword

-on a declaration, followed by an attribute specification inside double
-parentheses.  You can specify multiple attributes in a declaration by
-separating them by commas within the double parentheses or by
+on a declaration, followed by an attribute specification enclosed in
+double parentheses.  You can specify multiple attributes in a declaration
+by separating them by commas within the double parentheses or by
 immediately following an attribute declaration with another attribute
 declaration.  @xref{Attribute Syntax}, for the exact rules on attribute
 syntax and placement.  Compatible attribute specifications on distinct
@@ -2301,6 +2305,15 @@ declarations of the same function are merged.  An
 that is not compatible with attributes already applied to a declaration
 of the same function is ignored with a warning.
 
+Unless specified otherwise, function attributes that apply to function

+parameters of pointer types also apply to the implicit C++ @code{this}
+argument in non-constant member functions, and to parameters of reference


I'm confused by this.  Function attributes apply to functions, not 
parameters.  Even if they did apply to parameters, why the restriction 
against constant member functions?



+type.  In attributes that refer to function parameters by their position
+in the argument list the first pararameter is at position one.  In C++


s/pararameter/parameter

Again, I'm confused.  Is this about the format attribute?  It would be 
far less obscure to just move this explanation to the discussion of that 
attribute, because nobody trying to understand how the format attribute 
works would be able to tie this discussion in another section into it.



+non-static member functions position one refers to the implicit @code{this}
+pointer.  The same restrictions and effects apply to function attributes
+used with ordinary functions or C++ member functions.
+
 GCC also supports attributes on
 variable declarations (@pxref{Variable Attributes}),
 labels (@pxref{Label Attributes}),
@@ -6067,18 +6080,23 @@ when this attribute is present.
 @cindex attribute of variables
 @cindex variable attributes
 
-The keyword @code{__attribute__} allows you to specify special

-attributes of variables or structure fields.  This keyword is followed
-by an attribute specification inside double parentheses.  Some
-attributes are currently defined generically for variables.
-Other attributes are defined for variables on particular target
-systems.  Other attributes are available for functions
-(@pxref{Function Attributes}), labels (@pxref{Label Attributes}),
+The keyword @code{__attribute__} allows you to specify special properties
+of variables, function parameters, or structure, union, and, in C++, class
+members.  This @code{__attribute__} keyword is followed by an attribute
+specification enclosed in double parentheses.  Some attributes are currently
+defined generically for variables. Other attributes are defined for
+variables on particular target systems.  Other attributes are available
+for 

Fix move_if_noexcept usages in _Hashtable

[François Dumont]

Hi

  This patch fix a minor problem with usage of std::move_if_noexcept. 
We use it to move node content if move construtor is noexcept but we 
eventually use the allocator_type::construct method which might be 
slightly different. I think it is better to check for this method 
noexcept qualification.


  Moreover I have added a special overload for nodes containing a 
std::pair. It is supposed to allow move semantic in associative 
containers where Key is stored as const deleting std::pair move 
constructor. In this case we should still move the Value part.


  It doesn't work for the moment because the std::pair piecewise 
constructor has no noexcept qualification. Is there any plan to add it ? 
I think adding it will force including  in stl_pair.h, is it fine ?


  If this evolution is accepted I'll adapt it for _Rb_tree that has the 
same problem.


  Working on this I also notice that content of initialization_list is 
not moved. Is there a plan to make initialization_list iterator type 
like move_iterator ? Should containers use 
__make_move_iterator_if_noexcept ?


  Tested under Linux x86_64 normal mode.

  Ok to commit this first step ?

    * include/bits/stl_construct.h (__construct_object_a): New.
    (struct _Construct_object_a): New, use latter.
    (__move_construct_object_a): New.
    (struct _Move_construct_object_a): New, use latter.
    (struct _Move_construct_if_noexcept_a): New.
    * include/std/tuple (__move_construct_object_a): New overload for
    std::pair.
    * include/ext/throw_allocator.h
    (throw_allocator_base<>::construct<_Up, _Args...>): Add noexcept
    qualification.
    * testsuite/util/testsuite_allocator.h
    (tracker_allocator<>::construct<_Up, _Args...>): Likewise.
    * include/bits/hashtable_policy.h: Include 
    (_Hashtable_alloc<>::_M_allocate_node_f): New.
    (_Hashtable_alloc<>::_M_allocate_node): Adapt, use latter.
    (_AllocNode<>::operator()<_Args...>): Likewise.
    (_AllocNode<_NodeAlloc, _ConstructF>): Inherit from _ConstructF.
    (_AllocNode<>::_M_construct_f()): New.
    (_ReuseOrAllocNode<>): Inherits from _AllocNode.
    * include/bits/hashtable.h:
    (_Hashtable<>::__alloc_node_gen_t): New template alias to _NodeAlloc.
    (_Hashtable<>::__reuse_or_alloc_node_type): Replace with...
    (_Hashtable<>::__reuse_or_alloc_node_gen_t): ...that.
    (_Hashtable<>::_M_assign_elements<>): Remove _NodeGenerator parameter.
    (_Hashtable<>::operator=(initializer_list<>)): Adapt.
    (_Hashtable<>::operator=(const _Hashtable&)): Adapt.
    (_Hashtable<>::_M_move_assign(_Hashtable&&, false_type)): Adapt.
    (_Hashtable<>::_Hashtable(const _Hashtable&)): Adapt.
    (_Hashtable<>::_Hashtable(const _Hashtable&, const allocator_type&)):
    Adapt.
    (_Hashtable<>::_Hashtable(_Hashtable&&, const allocator_type&)): Adapt.
    * testsuite/23_containers/unordered_map/allocator/move_assign.cc:
    (test01): Add checks.
    (test02): Likewise.
    * testsuite/23_containers/unordered_set/allocator/move_assign.cc:
    (test04): New.

François

diff --git a/libstdc++-v3/include/bits/hashtable.h b/libstdc++-v3/include/bits/hashtable.h
index 9a12ad399dc..dfb756cec07 100644
--- a/libstdc++-v3/include/bits/hashtable.h
+++ b/libstdc++-v3/include/bits/hashtable.h
@@ -266,8 +266,13 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 	_Equal, _H1, _H2, _Hash,
 	_RehashPolicy, _Traits>;
 
-  using __reuse_or_alloc_node_type =
-	__detail::_ReuseOrAllocNode<__node_alloc_type>;
+  template
+	using __alloc_node_gen_t =
+	  __detail::_AllocNode<__node_alloc_type, _ConstructF>;
+
+  template
+	using __reuse_or_alloc_node_gen_t =
+	  __detail::_ReuseOrAllocNode<__node_alloc_type, _ConstructF>;
 
   // Metaprogramming for picking apart hash caching.
   template
@@ -400,9 +405,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
   // Assign *this using another _Hashtable instance. Either elements
   // are copy or move depends on the _NodeGenerator.
-  template
+  template
 	void
-	_M_assign_elements(_Ht&&, const _NodeGenerator&);
+	_M_assign_elements(_Ht&&);
 
   template
 	void
@@ -500,7 +505,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   _Hashtable&
   operator=(initializer_list __l)
   {
-	__reuse_or_alloc_node_type __roan(_M_begin(), *this);
+	__reuse_or_alloc_node_gen_t<_Construct_object_a>
+	  __roan(*this, _M_begin());
 	_M_before_begin._M_nxt = nullptr;
 	clear();
 	this->_M_insert_range(__l.begin(), __l.end(), __roan, __unique_keys());
@@ -1047,9 +1053,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 	  _M_rehash_policy = __ht._M_rehash_policy;
 	  __try
 		{
-		  _M_assign(__ht,
-			[this](const __node_type* __n)
-			{ return this->_M_allocate_node(__n->_M_v()); });
+		  __alloc_node_gen_t<_Construct_object_a> __ang(*this);
+		  _M_assign(__ht, __ang);
 		}
 	  __catch(...)
 		{
@@ -1064,9 +1069,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 	}
 
   // Reuse allocated buckets and nodes.
-  _M_assign_elements(__ht,
-	

Re: [doc,committed] clarify docs for function attribute "const"

[Sandra Loosemore]

On 12/3/18 2:47 PM, Martin Sebor wrote:

[snip]

Attached is my proposed update.  The user's email suggested going
into a lot of detail that I'm not sure would be helpful.  I think
it's safer to keep it simple than to try to carefully outline tricky
conditions under which some const or pure functions might get away
with modifying program state.  At the same time, I tried not to
outright prohibit it so I phrased the restrictions in terms of
observable program state (as opposed to reading or writing
"global" variables and such).

I also made a few other changes, like move the example of
the square function from pure to const (since the function is
much more likely const), and made the const restrictions stand
on their own, rather than depending on pure.



Index: /ssd/src/gcc/svn/gcc/doc/extend.texi
===
--- /ssd/src/gcc/svn/gcc/doc/extend.texi(revision 266760)
+++ /ssd/src/gcc/svn/gcc/doc/extend.texi(working copy)
@@ -2518,25 +2518,45 @@ are automatically detected and this attribute is i
 @item const
 @cindex @code{const} function attribute
 @cindex functions that have no side effects
-Many functions do not examine any values except their arguments, and
-have no effects except to return a value.  Calls to such functions lend
-themselves to optimization such as common subexpression elimination.
-The presence of the @code{const} attribute on a function declaration 
-allows GCC to emit more efficient code for some calls to the function.  
+Calls to functions whose return value is not affected by changes to

+the observable state of the program and that have no observable effects
+on such state other than to return a value may lend themselves to
+optimizations such as common subexpression elimination.  Declaring such
+functions with the @code{const} attribute allows GCC to emit more efficient
+code for consecutive calls to the function.


I don't think the calls have to be consecutive for GCC to emit more 
efficient code.  I'd kill that last bit.



+The @code{const} attribute prohibits a function from reading objects
+that affect its return value between successive invocations.  However,
+functions declared with the attribute can safely read objects that do
+not affect their return value, such as non-volatile constants.
 The @code{const} attribute imposes greater restrictions on a function's
-definition than the similar @code{pure} attribute below because it
-additionally prohibits the function from reading memory except for
-constant global variables.  Decorating the same function with
-both the @code{const} and the @code{pure} attribute is diagnosed.
+definition than the similar @code{pure} attribute.  Declaring the same
+function with both the @code{const} and the @code{pure} attribute is
+diagnosed.  Because a const function cannot have any observable side


@code{const}


+effects it does not make sense for it to return @code{void}.  Declaring
+such a function is diagnosed.
 
+For example,

+
+@smallexample
+int square (int) __attribute__ ((const));
+@end smallexample
+
+@noindent
+tells GCC that subsequent calls to function @code{square} with the same
+argument value can be replaced by the result of the first call regardless
+of the statements in between.
+


I think it would be better to move this example immediately after the 
first paragraph, before you digress about the diagnostics and such like.



 @cindex pointer arguments
 Note that a function that has pointer arguments and examines the data
-pointed to must @emph{not} be declared @code{const}.  Likewise, a
-function that calls a non-@code{const} function usually must not be
-@code{const}.  Because a @code{const} function cannot have any side
-effects it does not make sense for such a function to return @code{void}.
-Declaring such a function is diagnosed.
+pointed to must @emph{not} be declared @code{const} if the pointed-to
+data might change between successive invocations of the function.  In
+general, since a function cannot distinguish data that might change
+from data that cannot, @code{const} functions should never be
+pass-by-reference.  Likewise, a function that calls a non-@code{const}


I don't understand what a pass-by-reference function might be.  Do you 
mean it should not have reference parameters in C++?



+function usually must not be @code{const}.  Because a @code{const}
+function cannot have any side effects it does not make sense for such
+a function to return @code{void}. Declaring such a function is diagnosed.


The last two sentences duplicate what you say a couple paragraphs 
earlier.  We only need to say this once.  :-)


 
 @item constructor

 @itemx destructor
@@ -3301,34 +3321,51 @@ to prevent recursion.
 @item pure
 @cindex @code{pure} function attribute
 @cindex functions that have no side effects
-Many functions have no effects except the return value and their
-return value depends only on the parameters and/or global variables.

Re: [Patch, ppc/darwin 1/2] Fix bootstrap.

[Alan Modra]

On Mon, Dec 03, 2018 at 07:14:36PM +, Iain Sandoe wrote:
> 
> > On 3 Dec 2018, at 06:18, Alan Modra  wrote:
> > 
> > On Mon, Dec 03, 2018 at 01:26:48AM +, Iain Sandoe wrote:
> 
> >> The first patch makes Darwin share the sysv lowering, up until late in the 
> >> process when we still use the macho_call_template.  This means we need to 
> >> preserve the CALL_LONG flag for Darwin.
> >> 
> >> In order to match this for Darwin64, the sysv patterns needed the clobber 
> >> mode to follow that of the pattern.  It seems that this might be a typo - 
> >> since it’s not obvious how it would work for powerpc64 sysv as things 
> >> stand (AIX and ELFv2 already follow the mode).
> > 
> > Hmm, yes, and I think there may be some more modes to fix.
> > call_local64, call_value_local64, call_nonlocal_sysv splitter,
> > call_value_nonlocal_sysv splitter, call_value_nonlocal_sysv_secure.
> 
> I’m slightly twitchy about patches I can’t fully test ..

I'm running a powerpc64-linux -m64/-m32 regression test now.  If
anything turns up I'll let you know.

-- 
Alan Modra
Australia Development Lab, IBM

Re: [RFC][AArch64] Add support for system register based stack protector canary access

[Wilco Dijkstra]

Hi,

Florian wrote:
> For userland, I would like to eventually copy the OpenBSD approach for
> architectures which have some form of PC-relative addressing: we can
> have multiple random canaries in (RELRO) .rodata in sufficiently close
> to the code that needs them (assuming that we have split .rodata).  At
> least for x86-64, I expect this to be a small win.  It's also a slight
> hardening improvement if the reference canary is not stored in writable
> memory.

On AArch64 hardware pointer signing already provides a free and more robust
implementation of stack canaries, so we could change -fstack-protector to
use that when pointer signing is enabled.

Wilco

[doc PATCH] document when GCC ignores attribute aligned

[Martin Sebor]

Last week we agreed to clarify that attribute aligned on a function
can decrease its alignment if it hasn't been previously declared
with one.  Attached is this change.

Besides the above, I also mention that the attribute specifies
the alignment of the first instruction of the function (in case
that wasn't obvious) , and that it has no effect in the absence
of a definition.

I wrote some tests to convince myself this actually works as
I expected.  Where it does I add those tests to the testsuite
via this patch.  Where it doesn't I opened a bug (PR 88345).

Martin
gcc/ChangeLog:

	* doc/extend.texi (attribute aligned): Expand.

gcc/testsuite/ChangeLog:

	* gcc.target/i386/attr-aligned-2.c: New test.
	* gcc.target/i386/falign-functions-3.c: New test.

Index: gcc/doc/extend.texi
===
--- gcc/doc/extend.texi	(revision 266766)
+++ gcc/doc/extend.texi	(working copy)
@@ -2386,16 +2386,20 @@ and may not be available on all targets.
 @itemx aligned (@var{alignment})
 @cindex @code{aligned} function attribute
 The @code{aligned} attribute specifies a minimum alignment for
-the function, measured in bytes.  When specified, @var{alignment} must
-be an integer constant power of 2.  Specifying no @var{alignment} argument
-implies the maximum alignment for the target, which is often, but by no
-means always, 8 or 16 bytes.
+the first instruction of the function, measured in bytes.  When specified,
+@var{alignment} must be an integer constant power of 2.  Specifying no
+@var{alignment} argument implies the ideal alignment for the target,
+which is often, but by no means always, 8 or 16 bytes.  The attribute
+has no effect when a definition for the function is not provided in
+the same translation unit.
 
-You cannot use this attribute to decrease the alignment of a function,
-only to increase it.  However, when you explicitly specify a function
-alignment this overrides the effect of the
-@option{-falign-functions} (@pxref{Optimize Options}) option for this
-function.
+The attribute cannot be used to decrease the alignment of a function
+previously declared with a more restrictive alignment; only to increase
+it.  Attempts to do otherwise are diagnosed.  Some targets specify
+a minimum default alignment for functions that is greater than 1.  On
+such targets, specifying a less restrictive alignment is silently ignored.
+Using the attribute overrides the effect of the @option{-falign-functions}
+(@pxref{Optimize Options}) option for this function.
 
 Note that the effectiveness of @code{aligned} attributes may be
 limited by inherent limitations in the system linker 
Index: gcc/testsuite/gcc.target/i386/attr-aligned-2.c
===
--- gcc/testsuite/gcc.target/i386/attr-aligned-2.c	(nonexistent)
+++ gcc/testsuite/gcc.target/i386/attr-aligned-2.c	(working copy)
@@ -0,0 +1,28 @@
+/* Verify that valid alignment on either a function declaration
+   or a definition has the expected effect and overrides -Os.
+   { dg-do compile }
+   { dg-options "-Os" }  */
+
+#define ALIGN(n) __attribute__ ((aligned (n)))
+
+/* No alignment specified (to cause the subsequent instruction
+   to be at an odd boundary due to -Os).  */
+void f (void) { }
+
+void f4 (void);
+
+ALIGN (4)
+void f4 (void) { }
+
+/* { dg-final { scan-assembler ".align 4\n\t.globl\tf4" } } */
+
+
+void g (void) { }
+
+
+ALIGN (4)
+void g4 (void);
+
+void g4 (void) { }
+
+/* { dg-final { scan-assembler ".align 4\n\t.globl\tg4" } } */
Index: gcc/testsuite/gcc.target/i386/falign-functions-3.c
===
--- gcc/testsuite/gcc.target/i386/falign-functions-3.c	(nonexistent)
+++ gcc/testsuite/gcc.target/i386/falign-functions-3.c	(working copy)
@@ -0,0 +1,23 @@
+/* Verify that attribute aligned overrides the effect of -falign-functions.
+   (But see PR 88345 showing that -Os overrides -falign-functions.)
+   The test may need to be adjusted if/when GCC implements PR 88231.
+  { dg-do compile }
+  { dg-options "-O2 -falign-functions=32" } */
+
+#define ALIGN(n) __attribute__ ((aligned (n)))
+
+ALIGN (4)
+void f4 (void) { }
+
+/* { dg-final { scan-assembler ".align 4\n\t.globl\tf4" } } */
+
+
+void f32 (void) { }
+
+/* { dg-final { scan-assembler ".p2align 5\n\t.globl\tf32" } } */
+
+
+ALIGN (64)
+void f64 (void) { }
+
+/* { dg-final { scan-assembler ".align 64\n\t.globl\tf64" } } */

Re: [PATCH v3] Make function clone name numbering independent.

[Michael Ploujnikov]

On 2018-12-03 12:00 p.m., Michael Ploujnikov wrote:
> On 2018-12-01 11:29 a.m., H.J. Lu wrote:
>> This caused:
>>
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88297
>>
> 
> Sorry about that. Looks like I should have been testing with
> --with-build-config=bootstrap-lto rather than just --enable-bootstrap.
> 
> The quick fix would be to undo the patch to create_virtual_clone or to
> just change clone_num_suffixes to key off of DECL_ASSEMBLER_NAME
> (node->decl) instead of node pointers. Any preferences?
> 
> The harder fix would be to figure out why some nodes share the same
> names and fix that, but maybe that's just inevitable with LTO?
> 
> - Michael
> 

Here's a quick fix while the issue is being investigated.

Bootstrapped (--with-build-config=bootstrap-lto) and regtested on x86_64.

Ok for trunk?
From f5e2500f30ad337e85e0b53eaa15c724657966a2 Mon Sep 17 00:00:00 2001
From: Michael Ploujnikov 
Date: Mon, 3 Dec 2018 18:19:18 -0500
Subject: [PATCH] PR ipa/88297

gcc/ChangeLog:

2018-12-03  Michael Ploujnikov  

	PR ipa/88297
	* ipa-cp.c (create_specialized_node): Store clone counters by
	node assembler names.
	(ipcp_driver): Change type of clone_num_suffixes key type to
	const char*.
---
 gcc/ipa-cp.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git gcc/ipa-cp.c gcc/ipa-cp.c
index e0cd1bc45b..f82473e37c 100644
--- gcc/ipa-cp.c
+++ gcc/ipa-cp.c
@@ -376,8 +376,8 @@ static profile_count max_count;
 
 static long overall_size, max_new_size;
 
-/* Node to unique clone suffix number map.  */
-static hash_map *clone_num_suffixes;
+/* Node name to unique clone suffix number map.  */
+static hash_map *clone_num_suffixes;
 
 /* Return the param lattices structure corresponding to the Ith formal
parameter of the function described by INFO.  */
@@ -3831,7 +3831,9 @@ create_specialized_node (struct cgraph_node *node,
 	}
 }
 
-  unsigned _counter = clone_num_suffixes->get_or_insert (node);
+  unsigned _counter = clone_num_suffixes->get_or_insert (
+			   IDENTIFIER_POINTER (DECL_ASSEMBLER_NAME (
+ node->decl)));
   new_node = node->create_virtual_clone (callers, replace_trees,
 	 args_to_skip, "constprop",
 	 suffix_counter);
@@ -5049,7 +5051,7 @@ ipcp_driver (void)
 
   ipa_check_create_node_params ();
   ipa_check_create_edge_args ();
-  clone_num_suffixes = new hash_map;
+  clone_num_suffixes = new hash_map;
 
   if (dump_file)
 {
-- 
2.19.1



signature.asc
Description: OpenPGP digital signature

Re: [patch,opencc] Don't mark OpenACC auto loops as independent inside acc parallel regions

[Julian Brown]

On Thu, 20 Sep 2018 09:49:43 -0700
Cesar Philippidis  wrote:

> OpenACC as a concept of loop independence, in which independent loops
> may be executed in parallel across gangs, workers and vectors. Inside
> acc parallel regions, if a loop isn't explicitly marked seq or auto,
> it is predetermined to be independent.
> 
> This patch corrects a bug where acc loops marked as auto were being
> mistakenly promoted to independent. That's bad because it can generate
> bogus results if a dependency exist.
> 
> Note that this patch depends on the following patches for
> -fnote-info-omp-optimized which is used in a test case.
> 
>   * Add user-friendly OpenACC diagnostics regarding detected
> parallelism.
> https://gcc.gnu.org/ml/gcc-patches/2018-07/msg01652.html
> 
>   * Correct the reported line number in fortran combined OpenACC
> directives
> https://gcc.gnu.org/ml/gcc-patches/2018-07/msg01554.html
> 
>   * Correct the reported line number in c++ combined OpenACC
> directives https://gcc.gnu.org/ml/gcc-patches/2018-07/msg01552.html
> 
> Is this OK for trunk? I bootstrapped and regtested on x86_64 Linux
> with nvptx offloading.

LGTM, FWIW.

Thanks,

Julian

Re: [patch,openacc] Set safelen to INT_MAX for oacc independent pragma

[Julian Brown]

On Thu, 20 Sep 2018 11:21:28 -0700
Cesar Philippidis  wrote:

> This is another old gomp4 OpenACC patch which impacts targets that use
> simd vectorization, such as the host and AMD GCN, rather than nvptx.
> Basically, as the subject states, it sets safelen to INT_MAX for
> independent acc loops, which I believe is already being done for
> OpenMP in certain situations.
> 
> The original discussion for this patch can be found here
> .
> 
> Is this patch OK for trunk? I bootstrapped and regtested it for x86_64
> Linux with nvptx offloading.

I believe this is conservatively safe, although I understand that a
safelen of INT_MAX does not correspond strictly to the way a GPU will
execute greater-than-warp-size numbers of independent loop iterations.
This isn't a problem for NVPTX (which IIUC does not use the information
carried by the safelen setting at present) or the host, but may need
attention for e.g. AMD GCN or other GPUs that use a similar execution
scheme.

This may need merging with the non-marked_independent parts of:

  https://gcc.gnu.org/ml/gcc-patches/2018-12/msg00140.html

Julian

Re: [patch,openacc] Propagate independent clause for OpenACC kernels pass

[Julian Brown]

On Thu, 20 Sep 2018 11:06:40 -0700
Cesar Philippidis  wrote:

> This is another old patch teaches the omp expansion pass how to
> propagate the acc loop independent clause to the later stages
> throughout compilation. Unfortunately, it didn't include any test
> cases. I'm not sure how effective this will be with the existing
> kernel parloops pass. But as I noted in my Cauldron talk, we would
> like to convert acc kernels regions to acc parallel regions, and this
> patch could help in that regard.
> 
> Chung-Lin, do you have anymore state on this patch?
> 
> Anyway, I bootstrapped and regtested it for x86_64 Linux with nvptx
> offloading and it didn't introduce any regressions. We do have a
> couple of other standalone kernels patches in og8, but those depend
> on other patches.

It's not surprising that there are no new tests and no regressions: the
new "marked_independent" field is not used anywhere, either within this
patch, or on the gomp4 branch where it originated, nor currently on the
og8 branch! It looks like the planned use by the parloops pass (etc.)
has not materialised so far.

Jakub asked in the following email at the time of the patch submission
for the gomp4 branch what the difference was between the new
marked_independent flag and safelen == INT_MAX:

  https://gcc.gnu.org/ml/gcc-patches/2015-07/msg01100.html

If I understand the followup correctly,

  https://gcc.gnu.org/ml/gcc-patches/2015-07/msg01117.html

a setting of safelen > 1 means that up to that number of loop
iterations can run together in lockstep (as if each insn in the loop
was blindly rewritten to a safelen-width SIMD equivalent) -- but
anything that happens in iteration N + 1 cannot happen before something
that happens in iteration N. Chung-Lin pointed out that OpenACC's
semantics are even less strict (allowing iterations to proceed fully
independently in an arbitrary order), so the marked_independent flag
does carry non-redundant information -- even with safelen set to
INT_MAX.

Actually I think that given the above, setting safelen to a value
greater than 32 (the warp size) may not be safe for NVPTX on OpenACC,
depending on the vagaries of warp scheduling. But that's not the
subject of this patch.

Anyway: given that the information recorded by this patch is not used
at present, and further work on the kernels pass may head in a
different direction, I'm not sure that it makes sense to commit it
at this point.

Also, it occurs to me that if the independent flag is set on loops
within kernels regions with an explicit "independent" clause, it should
also be set by default on loops in parallel regions without clauses
that disable the independent-iteration semantics.

Julian

[doc PATCH] update attribute docs for C++

[Martin Sebor]

In a recent discussion a user asked us to clarify the effects
of attributes const and pure on member functoons of trivial
structs vs. non-trivial classes, and functions with pointer
vs. reference arguments.

I think this is worth explaining in some general statement
rather than for individual attributes.  The attached patch
adds words to document this for all function (and variable)
attributes.

While discussing C++ specifics I thought it would also be
helpful to mention in the same context that in C++ positional
arguments include the this pointer.

Finally, since in a separate change we are tweaking attributes
const and pure, I thought it would be appropriate to replace
the reference to attribute pure as one denoting a function
that "returns a value depending only its arguments" with one
to attribute const.  I think that's more accurate -- a pure
function may depend on the global state of the program.

Martin

gcc/ChangeLog:

	* doc/extend.texi (attribute const, pure): Clarify.

Index: gcc/doc/extend.texi
===
--- gcc/doc/extend.texi	(revision 266766)
+++ gcc/doc/extend.texi	(working copy)
@@ -2276,12 +2276,13 @@ the enclosing block.
 @cindex @code{volatile} applied to function
 @cindex @code{const} applied to function
 
-In GNU C, you can use function attributes to declare certain things
-about functions called in your program which help the compiler
-optimize calls and check your code more carefully.  For example, you
+In GNU C and C++, you can use function attributes to declare certain
+function properties that may help the compiler optimize calls or
+check code more carefully for correctness.  For example, you
 can use attributes to declare that a function never returns
-(@code{noreturn}), returns a value depending only on its arguments
-(@code{pure}), or has @code{printf}-style arguments (@code{format}).
+(@code{noreturn}), returns a value depending only on the values of
+its arguments (@code{const}), or has @code{printf}-style arguments
+(@code{format}).
 
 You can also use attributes to control memory placement, code
 generation options or call/return conventions within the function
@@ -2288,12 +2289,15 @@ generation options or call/return conventions with
 being annotated.  Many of these attributes are target-specific.  For
 example, many targets support attributes for defining interrupt
 handler functions, which typically must follow special register usage
-and return conventions.
+and return conventions.  Such attributes are described in the subsection
+for each target.  However, a considerable number of attributes are
+supported by most, if not all targets.  Those are described in
+the @ref{Common Function Attributes} section.
 
 Function attributes are introduced by the @code{__attribute__} keyword
-on a declaration, followed by an attribute specification inside double
-parentheses.  You can specify multiple attributes in a declaration by
-separating them by commas within the double parentheses or by
+on a declaration, followed by an attribute specification enclosed in
+double parentheses.  You can specify multiple attributes in a declaration
+by separating them by commas within the double parentheses or by
 immediately following an attribute declaration with another attribute
 declaration.  @xref{Attribute Syntax}, for the exact rules on attribute
 syntax and placement.  Compatible attribute specifications on distinct
@@ -2301,6 +2305,15 @@ declarations of the same function are merged.  An
 that is not compatible with attributes already applied to a declaration
 of the same function is ignored with a warning.
 
+Unless specified otherwise, function attributes that apply to function
+parameters of pointer types also apply to the implicit C++ @code{this}
+argument in non-constant member functions, and to parameters of reference
+type.  In attributes that refer to function parameters by their position
+in the argument list the first pararameter is at position one.  In C++
+non-static member functions position one refers to the implicit @code{this}
+pointer.  The same restrictions and effects apply to function attributes
+used with ordinary functions or C++ member functions.
+
 GCC also supports attributes on
 variable declarations (@pxref{Variable Attributes}),
 labels (@pxref{Label Attributes}),
@@ -6067,18 +6080,23 @@ when this attribute is present.
 @cindex attribute of variables
 @cindex variable attributes
 
-The keyword @code{__attribute__} allows you to specify special
-attributes of variables or structure fields.  This keyword is followed
-by an attribute specification inside double parentheses.  Some
-attributes are currently defined generically for variables.
-Other attributes are defined for variables on particular target
-systems.  Other attributes are available for functions
-(@pxref{Function Attributes}), labels (@pxref{Label Attributes}),
+The keyword @code{__attribute__} allows you to specify special properties
+of 

Re: [PATCH 1/2] asm qualifiers (PR55681)

[Joseph Myers]

On Sun, 2 Dec 2018, Segher Boessenkool wrote:

> PR55681 observes that currently only one qualifier is allowed for
> inline asm, so that e.g. "volatile asm" is allowed, "const asm" is also
> okay (with a warning), but "const volatile asm" gives an error.  Also
> "goto" has to be last.
> 
> This patch changes things so that only "asm-qualifiers" are allowed,
> that is "volatile" and "goto", in any combination, in any order, but
> without repetitions.

The C front-end changes are OK.

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

Re: [PATCH] v4: C/C++: add fix-it hints for missing '&' and '*' (PR c++/87850)

[Joseph Myers]

On Sat, 1 Dec 2018, Jason Merrill wrote:

> Hmm, it looks like the C front-end comptypes will return 1 for e.g. enum and
> int.  It seems to me that what you want for this warning is actually to check
> for the same type.  Perhaps you want to use comptypes_check_different_types?
> Joseph would know better what's correct for the C front-end.

Well, it's valid to pass a pointer to enum where a pointer to the 
compatible integer type is required, or vice versa, but I don't have 
advice on which cases you want to accept for this particular fix-it.

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

Re: [PING] Re: [PATCH 1/2] C++: more location wrapper nodes (PR c++/43064, PR c++/43486)

[Jeff Law]

On 11/19/18 9:51 AM, David Malcolm wrote:
> Ping, for these patches:
> 
> [PATCH 1/2] C++: more location wrapper nodes (PR c++/43064, PR c++/43486)
>   https://gcc.gnu.org/ml/gcc-patches/2018-11/msg00304.html
> 
> [PATCH 2/2] C++: improvements to binary operator diagnostics (PR c++/87504)
>   https://gcc.gnu.org/ml/gcc-patches/2018-11/msg00303.html
> 
> 
> Thanks
> Dave
> 

>>
>> [1] I've split them up for ease of review; they could be reworked to
>> be
>> fully independent, but there's some churn in the results for
>> -Wtautological-compare introduced by the 1st patch which the 2nd
>> patch addresses.
>>
>> gcc/ChangeLog:
>>  PR c++/43064
>>  PR c++/43486
>>  * convert.c: Include "selftest.h".
>>  (preserve_any_location_wrapper): New function.
>>  (convert_to_pointer_maybe_fold): Update to handle location
>>  wrappers.
>>  (convert_to_real_maybe_fold): Likewise.
>>  (convert_to_integer_1): Handle location wrappers when checking
>> for
>>  INTEGER_CST.
>>  (convert_to_integer_maybe_fold): Update to handle location
>>  wrappers.
>>  (convert_to_complex_maybe_fold): Likewise.
>>  (selftest::test_convert_to_integer_maybe_fold): New functions.
>>  (selftest::convert_c_tests): New function.
>>  * fold-const.c (operand_equal_p): Strip any location wrappers.
>>  * selftest-run-tests.c (selftest::run_tests): Call
>>  selftest::convert_c_tests.
>>  * selftest.h (selftest::convert_c_tests): New decl.
>>  * tree.c (tree_int_cst_equal): Strip any location wrappers.
>>  (maybe_wrap_with_location): Don't create wrappers if any
>>  auto_suppress_location_wrappers are active.
>>  (suppress_location_wrappers): New variable.
>>  * tree.h (CONSTANT_CLASS_OR_WRAPPER_P): New macro.
>>  (suppress_location_wrappers): New decl.
>>  (class auto_suppress_location_wrappers): New class.
>>
>> gcc/c-family/ChangeLog:
>>  PR c++/43064
>>  PR c++/43486
>>  * c-common.c (unsafe_conversion_p): Strip any location wrapper.
>>  (verify_tree): Handle location wrappers.
>>  (c_common_truthvalue_conversion): Strip any location wrapper.
>>  Handle CONST_DECL.
>>  (fold_offsetof): Strip any location wrapper.
>>  (complete_array_type): Likewise for initial_value.
>>  (convert_vector_to_array_for_subscript): Call fold_for_warn on
>> the
>>  index before checking for INTEGER_CST.
>>  * c-pretty-print.c (c_pretty_printer::primary_expression):
>> Don't
>>  print parentheses around location wrappers.
>>  * c-warn.c (warn_logical_operator): Call fold_for_warn on
>> op_right
>>  before checking for INTEGER_CST.
>>  (warn_tautological_bitwise_comparison): Call
>>  tree_strip_any_location_wrapper on lhs, rhs, and bitop's
>> operand
>>  before checking for INTEGER_CST.
>>  (readonly_error): Strip any location wrapper.
>>  (warn_array_subscript_with_type_char): Strip location wrappers
>>  before checking for INTEGER_CST.  Use the location of the index
>> if
>>  available.
>>
>> gcc/cp/ChangeLog:
>>  PR c++/43064
>>  PR c++/43486
>>  * call.c (build_conditional_expr_1): Strip location wrappers
>> when
>>  checking for CONST_DECL.
>>  (conversion_null_warnings): Use location of "expr" if
>> available.
>>  * class.c (fixed_type_or_null): Handle location wrappers.
>>  * constexpr.c (potential_constant_expression_1): Likewise.
>>  * cvt.c (ignore_overflows): Strip location wrappers when
>>  checking for INTEGER_CST, and re-wrap the result if present.
>>  (ocp_convert): Call fold_for_warn before checking for
>> INTEGER_CST.
>>  * decl.c (reshape_init_r): Strip any location wrapper.
>>  (undeduced_auto_decl): Likewise.
>>  * decl2.c (grokbitfield): Likewise for width.
>>  * expr.c (mark_discarded_use): Likewise for expr.
>>  * init.c (build_aggr_init): Likewise before checking init for
>>  DECL_P.
>>  (warn_placement_new_too_small): Call fold_for_warn on adj
>> before
>>  checking for CONSTANT_CLASS_P, and on nelts.  Strip any
>> location
>>  wrapper from op0 and on oper before checking for VAR_P.
>>  * lambda.c (add_capture): Strip any location from initializer.
>>  * name-lookup.c (handle_namespace_attrs): Strip any location
>> from
>>  x before checking for STRING_CST.
>>  * parser.c (cp_parser_primary_expression): Call
>>  maybe_add_location_wrapper on numeric and string literals.
>>  (cp_parser_postfix_expression): Strip any location wrapper when
>>  checking for DECL_IS_BUILTIN_CONSTANT_P.
>>  (cp_parser_binary_expression): Strip any location wrapper when
>>  checking for DECL_P on the lhs.
>>  (cp_parser_decltype_expr): Suppress location wrappers in the
>>  id-expression.
>>  (cp_parser_mem_initializer): Add location wrappers to the
>>  parenthesized expression list.
>>  (cp_parser_template_parameter_list): Don't create wrapper nodes
>>  

[PATCH v2] C++: improvements to diagnostics using %P (more PR c++/85110)

[David Malcolm]

I was going to ping this patch:
  https://gcc.gnu.org/ml/gcc-patches/2018-11/msg00875.html
but it has bit-rotted somewhat, so here's a refreshed version of it.

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

OK for trunk?

Thanks
Dave


Blurb from v1:

This patch is based on grepping the C++ frontend for %P
i.e. diagnostics that refer to a parameter number.  It fixes up
these diagnostics to highlight the pertinent param where appropriate
(and possible), along with various other tweaks, as described in the
ChangeLog.

gcc/cp/ChangeLog:
PR c++/85110
* call.c (conversion_null_warnings): Try to use the location of
the expression for the warnings.  Add notes showing the parameter
of the function decl, where available.
(get_fndecl_argument_location): Gracefully reject
non-FUNCTION_DECLs.  For implicitly-declared functions, use the
fndecl location rather than that of the param.
(maybe_inform_about_fndecl_for_bogus_argument_init): New function.
(convert_like_real): Use it in various places to avoid repetition.
* cp-tree.h (maybe_inform_about_fndecl_for_bogus_argument_init):
New declaration.
* decl2.c: Include "gcc-rich-location.h".
(check_default_args): Use the location of the parameter when
complaining about parameters with missing default arguments in
preference to that of the fndecl.
Attempt to record the location of first parameter with a default
argument and add it as a secondary range to such errors.
* typeck.c (convert_arguments): When complaining about parameters
with incomplete types, attempt to use the location of the
argument.  Where available, add a note showing the pertinent
parameter in the fndecl.
(convert_for_assignment): When complaining about bad conversions
at function calls, use the location of the unstripped argument.
(convert_for_initialization): When checking for bogus references,
add an auto_diagnostic_group, and update the note to use the
location of the pertinent parameter, rather than just the callee.

gcc/testsuite/ChangeLog:
PR c++/85110
* g++.dg/diagnostic/missing-default-args.C: New test.
* g++.dg/diagnostic/param-type-mismatch-3.C: New test.
* g++.dg/diagnostic/param-type-mismatch.C: Add tests for invalid
references and incomplete types.
* g++.dg/warn/Wconversion-null-4.C: New test.
---
 gcc/cp/call.c  | 88 ++
 gcc/cp/cp-tree.h   |  1 +
 gcc/cp/decl2.c | 16 +++-
 gcc/cp/typeck.c| 22 --
 .../g++.dg/diagnostic/missing-default-args.C   | 53 +
 .../g++.dg/diagnostic/param-type-mismatch-3.C  | 26 +++
 .../g++.dg/diagnostic/param-type-mismatch.C| 41 ++
 gcc/testsuite/g++.dg/warn/Wconversion-null-4.C | 43 +++
 8 files changed, 251 insertions(+), 39 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/diagnostic/missing-default-args.C
 create mode 100644 gcc/testsuite/g++.dg/diagnostic/param-type-mismatch-3.C
 create mode 100644 gcc/testsuite/g++.dg/warn/Wconversion-null-4.C

diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index ee099cc..cfc5641 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -6681,16 +6681,24 @@ conversion_null_warnings (tree totype, tree expr, tree 
fn, int argnum)
   if (null_node_p (expr) && TREE_CODE (totype) != BOOLEAN_TYPE
   && ARITHMETIC_TYPE_P (totype))
 {
-  location_t loc =
-   expansion_point_location_if_in_system_header (input_location);
-
   if (fn)
-   warning_at (loc, OPT_Wconversion_null,
-   "passing NULL to non-pointer argument %P of %qD",
-   argnum, fn);
+   {
+ location_t loc = EXPR_LOC_OR_LOC (expr, input_location);
+ loc = expansion_point_location_if_in_system_header (loc);
+ auto_diagnostic_group d;
+ if (warning_at (loc, OPT_Wconversion_null,
+ "passing NULL to non-pointer argument %P of %qD",
+ argnum, fn))
+   inform (get_fndecl_argument_location (fn, argnum),
+   "  declared here");
+   }
   else
-   warning_at (loc, OPT_Wconversion_null,
-   "converting to non-pointer type %qT from NULL", totype);
+   {
+ location_t loc
+   = expansion_point_location_if_in_system_header (input_location);
+ warning_at (loc, OPT_Wconversion_null,
+ "converting to non-pointer type %qT from NULL", totype);
+   }
 }
 
   /* Issue warnings if "false" is converted to a NULL pointer */
@@ -6698,9 +6706,15 @@ conversion_null_warnings (tree totype, tree expr, tree 
fn, int argnum)
   && TYPE_PTR_P (totype))
 {
   if (fn)
-   

Re: [PATCH 2/9]: C++ P0482R5 char8_t: Core language support

[Jason Merrill]

On 12/3/18 4:51 PM, Jason Merrill wrote:

On 11/5/18 2:39 PM, Tom Honermann wrote:
This patch adds support for the P0482R5 core language changes.  This 
includes:

- The -fchar8_t and -fno_char8_t command line options.
- char8_t as a keyword.
- The char8_t builtin type as a non-aliasing unsigned integral
   character type of size 1.
- Use of char8_t as a simple type specifier.
- u8 character literals with type char8_t.
- u8 string literals with type array of const char8_t.
- User defined literal operators that accept char8_1 and char8_t pointer
   types.
- New __cpp_char8_t predefined feature test macro.
- New __CHAR8_TYPE__ and __GCC_ATOMIC_CHAR8_T_LOCK_FREE predefined
   macros .
- Name mangling and demangling for char8_t (using Du).

gcc/ChangeLog:

2018-11-04  Tom Honermann  

  * defaults.h: Define CHAR8_TYPE.

gcc/c-family/ChangeLog:

2018-11-04  Tom Honermann  
  * c-family/c-common.c (c_common_reswords): Add char8_t.
  (fix_string_type): Use char8_t for the type of u8 string literals.
  (c_common_get_alias_set): char8_t doesn't alias.
  (c_common_nodes_and_builtins): Define char8_t as a builtin type in
  C++.
  (c_stddef_cpp_builtins): Add __CHAR8_TYPE__.
  (keyword_begins_type_specifier): Add RID_CHAR8.
  * gcc/c-family/c-common.h (rid): Add RID_CHAR8.
  (c_tree_index): Add CTI_CHAR8_TYPE and CTI_CHAR8_ARRAY_TYPE.
  Define D_CXX_CHAR8_T and D_CXX_CHAR8_T_FLAGS.
  Define char8_type_node and char8_array_type_node.
  * c-family/c-cppbuiltin.c (cpp_atomic_builtins): Predefine
  __GCC_ATOMIC_CHAR8_T_LOCK_FREE.
  (c_cpp_builtins): Predefine __cpp_char8_t.
  * c-family/c-lex.c (lex_string): Use char8_array_type_node as the
  type of CPP_UTF8STRING.
  (lex_charconst): Use char8_type_node as the type of CPP_UTF8CHAR.
  * c-family/c.opt: Add the -fchar8_t command line option.

gcc/c/ChangeLog:

2018-11-04  Tom Honermann  

  * c/c-typeck.c (char_type_p): Add char8_type_node.
  (digest_init): Handle initialization by a u8 string literal of
  char8_t type.

gcc/cp/ChangeLog:

2018-11-04  Tom Honermann  

  * cp/cvt.c (type_promotes_to): Handle char8_t promotion.
  * cp/decl.c (grokdeclarator): Handle invalid type specifier
  combinations involving char8_t.
  * cp/lex.c (init_reswords): Add char8_t as a reserved word.
  * cp/mangle.c (write_builtin_type): Add name mangling for char8_t
  (Du).
  * cp/parser.c (cp_keyword_starts_decl_specifier_p,
  cp_parser_simple_type_specifier): Recognize char8_t as a simple
  type specifier.
  (cp_parser_string_literal): Use char8_array_type_node for the type
  of CPP_UTF8STRING.
  (cp_parser_set_decl_spec_type): Tolerate char8_t typedefs in system
  headers.
  * cp/rtti.c (emit_support_tinfos): type_info support for char8_t.
  * cp/tree.c (char_type_p): Recognize char8_t as a character type.
  * cp/typeck.c (string_conv_p): Handle conversions of u8 string
  literals of char8_t type.
  (check_literal_operator_args): Handle UDLs with u8 string literals
  of char8_t type.
  * cp/typeck2.c (digest_init_r): Disallow initializing a char array
  with a u8 string literal.

libiberty/ChangeLog:

2018-10-31  Tom Honermann  
  * cp-demangle.c (cplus_demangle_builtin_types,
  cplus_demangle_type): Add name demangling for char8_t (Du).
  * cp-demangle.h: Increase D_BUILTIN_TYPE_COUNT to accommodate the
  new char8_t type.



@@ -3543,6 +3556,10 @@ c_common_get_alias_set (tree t)
   if (!TYPE_P (t))
 return -1;



+  /* Unlike char, char8_t doesn't alias. */
+  if (flag_char8_t && t == char8_type_node)
+    return -1;


This seems unnecessary; doesn't the existing code have the same effect? 
I think we could do with just an adjustment to the existing comment.



+  else if (flag_char8_t && TREE_TYPE (value) == char8_array_type_node)
+  || (flag_char8_t && type == char8_type_node)
+  bool char8_array = (flag_char8_t && !!comptypes (typ1, 
char8_type_node));

+   || (flag_char8_t && type == char8_type_node
In many places you check the flag and then for one of the char8 types. 
Since the types won't be used without the flag, checking the flag seems 
redundant?



-  if (TYPE_PRECISION (typ1) == BITS_PER_UNIT)
+  if (TYPE_PRECISION (typ1) == BITS_PER_UNIT
+  && (typ1 == char_type_node || !flag_char8_t))


This looks wrong, or at least incomplete; we want to complain about 
mismatched types here even with -fchar8-t.  Perhaps we should replace 
all of this if/else with simply comparing typ1 and char_type, and 
complaining if they're different.  Talking about wide and non-wide isn't 
as useful as the actual types would be.


Well, I suppose it isn't quite that simple, since we still need to treat 
the ordinary character types as interchangeable.


Jason

Re: RFA/RFC: Add stack recursion limit to libiberty's demangler

[Joseph Myers]

On Sat, 1 Dec 2018, Cary Coutant wrote:

> In order to handle arbitrary user input without crashing, perhaps the
> demangler should switch from recursive descent parsing to a state
> machine, where exhaustion of resources can be handled gracefully.

I've wondered if a GCC C/C++ extension could be defined that means 
"convert this set of mutually recursive functions into a single function 
with a state machine that allocates the equivalent of the stack manually".  
But such an extension would certainly be nontrivial to define.  (One use 
for such an extension would be to avoid the GCC bugs that occasionally get 
reported of the form "expressions with a million nested pairs of 
parentheses make the compiler segfault", by using it to avoid recursion in 
the parsers.)

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

Re: [C++ PATCH] Fix xvalue COND_EXPR handling (PR c++/88103)

[Jason Merrill]

On Mon, Dec 3, 2018 at 4:36 PM Jakub Jelinek  wrote:
>
> On Mon, Dec 03, 2018 at 02:44:32PM -0500, Jason Merrill wrote:
> > > > Is there a reason not to use the 'move' function here?
> > >
> > > That doesn't work at all.  move doesn't call cp_convert, but
> > > build_static_cast (though for the same reference && type).
> > > But while cp_convert only adds NOP_EXPR around it, build_static_cast adds
> > > a target_expr, addr_expr around that, nop_expr cast to the reference && 
> > > type
> > > and finally indirect_ref that the caller doesn't expect, because it adds 
> > > it
> > > by itself, e.g. in
> > > 2424if (temp)
> > > 2425  object = cp_build_fold_indirect_ref (temp);
> >
> > So the caller is trying to take the address of the COND_EXPR, which should
> > have POINTER_TYPE.  And then indirecting that gives an lvalue, as it should.
> > The bug is in the caller, build_class_member_access_expr.
>
> So like this then (if it passes bootstrap/regtest)?  Seems to fix the
> testcase.
>
> 2018-12-03  Jakub Jelinek  
>
> PR c++/88103
> * typeck.c (build_class_member_access_expr): If unary_complex_lvalue
> turned xvalue_p into non-xvalue_p, call move on it.
>
> * g++.dg/cpp0x/rv-cond3.C: New test.

OK, thanks.

Jason

Re: [PATCH v3][C][ADA] use function descriptors instead of trampolines in C

[Jeff Law]

On 11/4/18 1:48 PM, Uecker, Martin wrote:
> Hi Joseph,
> 
> here is a new version of this patch which adds a warning
> for targets which do not support -fno-trampolines  and
> only runs the test case on architectures where this is
> supported. It seems that documentation for this general
> feature has improved in the meantime so I only mention
> C as supported.
> 
> 
> Best,
> Martin
> 
> diff --git a/gcc/ada/gcc-interface/trans.c b/gcc/ada/gcc-interface/trans.c
> index ce2d43f989e..b79f2373c63 100644
> --- a/gcc/ada/gcc-interface/trans.c
> +++ b/gcc/ada/gcc-interface/trans.c
> @@ -1753,7 +1753,8 @@ Attribute_to_gnu (Node_Id gnat_node, tree 
> *gnu_result_type_p, int attribute)
>     if ((attribute == Attr_Access
>      || attribute == Attr_Unrestricted_Access)
>     && targetm.calls.custom_function_descriptors > 0
> -   && Can_Use_Internal_Rep (Etype (gnat_node)))
> +   && Can_Use_Internal_Rep (Etype (gnat_node))
> +  && (flag_trampolines != 1))
>   FUNC_ADDR_BY_DESCRIPTOR (gnu_expr) = 1;
You've got an extraneous set of parenthesis around your flag_trampolines
check.  Please remove them.


>  
>     /* Otherwise, we need to check that we are not violating the
> @@ -4330,7 +4331,8 @@ Call_to_gnu (Node_Id gnat_node, tree 
> *gnu_result_type_p, tree gnu_target,
>    /* If the access type doesn't require foreign-compatible 
> representation,
>    be prepared for descriptors.  */
>    if (targetm.calls.custom_function_descriptors > 0
> -   && Can_Use_Internal_Rep (Etype (Prefix (Name (gnat_node)
> +   && Can_Use_Internal_Rep (Etype (Prefix (Name (gnat_node
> +  && (flag_trampolines != 1))
Similarly here.


> diff --git a/gcc/c/c-objc-common.h b/gcc/c/c-objc-common.h
> index 78e768c2366..ef039560eb9 100644
> --- a/gcc/c/c-objc-common.h
> +++ b/gcc/c/c-objc-common.h
> @@ -110,4 +110,7 @@ along with GCC; see the file COPYING3.  If not see
>  
>  #undef LANG_HOOKS_TREE_INLINING_VAR_MOD_TYPE_P
>  #define LANG_HOOKS_TREE_INLINING_VAR_MOD_TYPE_P c_vla_unspec_p
> +
> +#undef LANG_HOOKS_CUSTOM_FUNCTION_DESCRIPTORS
> +#define LANG_HOOKS_CUSTOM_FUNCTION_DESCRIPTORS true
>  #endif /* GCC_C_OBJC_COMMON */
I wonder if we even need the lang hook anymore.  ISTM that a front-end
that wants to use the function descriptors can just set
FUNC_ADDR_BY_DESCRIPTOR and we'd use the function descriptor, else we'll
use the trampoline.  Thoughts?


> diff --git a/gcc/c/c-typeck.c b/gcc/c/c-typeck.c
> index 9d09b8d65fd..afae9de41e7 100644
> --- a/gcc/c/c-typeck.c
> +++ b/gcc/c/c-typeck.c
> @@ -1912,7 +1912,13 @@ function_to_pointer_conversion (location_t loc, tree 
> exp)
>    if (TREE_NO_WARNING (orig_exp))
>  TREE_NO_WARNING (exp) = 1;
>  
> -  return build_unary_op (loc, ADDR_EXPR, exp, false);
> +  tree r = build_unary_op (loc, ADDR_EXPR, exp, false);
> +
> +  if ((TREE_CODE(r) == ADDR_EXPR)
> +  && (flag_trampolines == 0))
> + FUNC_ADDR_BY_DESCRIPTOR (r) = 1;
> +
> +  return r;
Extraneous parens here too.

>  }
>  
>  /* Mark EXP as read, not just set, for set but not used -Wunused
> @@ -3134,6 +3140,11 @@ build_function_call_vec (location_t loc, 
> vec arg_loc,
>    else
>  result = build_call_array_loc (loc, TREE_TYPE (fntype),
>      function, nargs, argarray);
> +
> +  if ((TREE_CODE (result) == CALL_EXPR)
> +  && (flag_trampolines == 0))
> +CALL_EXPR_BY_DESCRIPTOR (result) = 1;
> +
And here too.


> diff --git a/gcc/testsuite/lib/target-supports.exp 
> b/gcc/testsuite/lib/target-supports.exp
> index fd74c04d092..a34e966b7c4 100644
> --- a/gcc/testsuite/lib/target-supports.exp
> +++ b/gcc/testsuite/lib/target-supports.exp
> @@ -916,6 +916,14 @@ proc check_effective_target_scheduling {} {
>  } "-fschedule-insns"]
>  }
>  
> +# Return 1 if it is possible to use function descriptors instead of 
> trampolines, 0 otherwise.
> +
> +proc check_effective_target_notrampolines {} {
> +return [check_no_compiler_messages notrampolines assembly {
> +void foo (void) { }
> +} "-fno-trampolines"]
> +}
> +
I think this needs documenting in sourcebuild.texi.   Look for
"Effective-target" to find the appropriate section.


Jeff

Re: [PATCH 2/9]: C++ P0482R5 char8_t: Core language support

[Jason Merrill]

On 11/5/18 2:39 PM, Tom Honermann wrote:
This patch adds support for the P0482R5 core language changes.  This 
includes:

- The -fchar8_t and -fno_char8_t command line options.
- char8_t as a keyword.
- The char8_t builtin type as a non-aliasing unsigned integral
   character type of size 1.
- Use of char8_t as a simple type specifier.
- u8 character literals with type char8_t.
- u8 string literals with type array of const char8_t.
- User defined literal operators that accept char8_1 and char8_t pointer
   types.
- New __cpp_char8_t predefined feature test macro.
- New __CHAR8_TYPE__ and __GCC_ATOMIC_CHAR8_T_LOCK_FREE predefined
   macros .
- Name mangling and demangling for char8_t (using Du).

gcc/ChangeLog:

2018-11-04  Tom Honermann  

  * defaults.h: Define CHAR8_TYPE.

gcc/c-family/ChangeLog:

2018-11-04  Tom Honermann  
  * c-family/c-common.c (c_common_reswords): Add char8_t.
  (fix_string_type): Use char8_t for the type of u8 string literals.
  (c_common_get_alias_set): char8_t doesn't alias.
  (c_common_nodes_and_builtins): Define char8_t as a builtin type in
  C++.
  (c_stddef_cpp_builtins): Add __CHAR8_TYPE__.
  (keyword_begins_type_specifier): Add RID_CHAR8.
  * gcc/c-family/c-common.h (rid): Add RID_CHAR8.
  (c_tree_index): Add CTI_CHAR8_TYPE and CTI_CHAR8_ARRAY_TYPE.
  Define D_CXX_CHAR8_T and D_CXX_CHAR8_T_FLAGS.
  Define char8_type_node and char8_array_type_node.
  * c-family/c-cppbuiltin.c (cpp_atomic_builtins): Predefine
  __GCC_ATOMIC_CHAR8_T_LOCK_FREE.
  (c_cpp_builtins): Predefine __cpp_char8_t.
  * c-family/c-lex.c (lex_string): Use char8_array_type_node as the
  type of CPP_UTF8STRING.
  (lex_charconst): Use char8_type_node as the type of CPP_UTF8CHAR.
  * c-family/c.opt: Add the -fchar8_t command line option.

gcc/c/ChangeLog:

2018-11-04  Tom Honermann  

  * c/c-typeck.c (char_type_p): Add char8_type_node.
  (digest_init): Handle initialization by a u8 string literal of
  char8_t type.

gcc/cp/ChangeLog:

2018-11-04  Tom Honermann  

  * cp/cvt.c (type_promotes_to): Handle char8_t promotion.
  * cp/decl.c (grokdeclarator): Handle invalid type specifier
  combinations involving char8_t.
  * cp/lex.c (init_reswords): Add char8_t as a reserved word.
  * cp/mangle.c (write_builtin_type): Add name mangling for char8_t
  (Du).
  * cp/parser.c (cp_keyword_starts_decl_specifier_p,
  cp_parser_simple_type_specifier): Recognize char8_t as a simple
  type specifier.
  (cp_parser_string_literal): Use char8_array_type_node for the type
  of CPP_UTF8STRING.
  (cp_parser_set_decl_spec_type): Tolerate char8_t typedefs in system
  headers.
  * cp/rtti.c (emit_support_tinfos): type_info support for char8_t.
  * cp/tree.c (char_type_p): Recognize char8_t as a character type.
  * cp/typeck.c (string_conv_p): Handle conversions of u8 string
  literals of char8_t type.
  (check_literal_operator_args): Handle UDLs with u8 string literals
  of char8_t type.
  * cp/typeck2.c (digest_init_r): Disallow initializing a char array
  with a u8 string literal.

libiberty/ChangeLog:

2018-10-31  Tom Honermann  
  * cp-demangle.c (cplus_demangle_builtin_types,
  cplus_demangle_type): Add name demangling for char8_t (Du).
  * cp-demangle.h: Increase D_BUILTIN_TYPE_COUNT to accommodate the
  new char8_t type.



@@ -3543,6 +3556,10 @@ c_common_get_alias_set (tree t)
   if (!TYPE_P (t))
 return -1;



+  /* Unlike char, char8_t doesn't alias. */
+  if (flag_char8_t && t == char8_type_node)
+return -1;


This seems unnecessary; doesn't the existing code have the same effect? 
I think we could do with just an adjustment to the existing comment.



+  else if (flag_char8_t && TREE_TYPE (value) == char8_array_type_node)
+ || (flag_char8_t && type == char8_type_node)
+  bool char8_array = (flag_char8_t && !!comptypes (typ1, char8_type_node));
+  || (flag_char8_t && type == char8_type_node
In many places you check the flag and then for one of the char8 types. 
Since the types won't be used without the flag, checking the flag seems 
redundant?



- if (TYPE_PRECISION (typ1) == BITS_PER_UNIT)
+ if (TYPE_PRECISION (typ1) == BITS_PER_UNIT
+ && (typ1 == char_type_node || !flag_char8_t))


This looks wrong, or at least incomplete; we want to complain about 
mismatched types here even with -fchar8-t.  Perhaps we should replace 
all of this if/else with simply comparing typ1 and char_type, and 
complaining if they're different.  Talking about wide and non-wide isn't 
as useful as the actual types would be.


Jason

Re: [PATCH] Delete powerpcspe

[Jakub Jelinek]

On Mon, Dec 03, 2018 at 02:40:12PM -0700, Jeff Law wrote:
> > 2018-12-03  Segher Boessenkool  
> > 
> > * contrib/config-list.mk: Remove powerpc-eabispe and powerpc-linux_spe.
> > * gcc/config.gcc (Obsolete configurations): Delete powerpc*-*-*spe*.
> > (Unsupported targets): Add powerpc*-*-*spe*.
> > (powerpc*-*-*spe*): Delete.
> > (powerpc-*-eabispe*): Delete.
> > (powerpc-*-rtems*spe*): Delete.
> > (powerpc*-*-linux*spe*): Delete.
> > (powerpc*-*-linux*): Do not handle the linux*spe* targets.
> > (powerpc-wrs-vxworks*spe): Delete.
> > (with_cpu setting code): Delete powerpc*-*-*spe* handling.
> > * gcc/config.host (target powerpc*-*-*spe*): Delete.
> > * gcc/doc/invoke.texi (PowerPC SPE Options): Delete.
> > (PowerPC SPE Options): Delete.
> > * gcc/config/powerpcspe: Delete.
> I'm all for it.  Let's give Jakub and Richi and chance to chime in though.

I'd give the maintainers the last week to act if they don't want this
to happen and if nothing happens, commit it.  PR81084 lists all the reasons
why it should be removed when it is totally unmaintained.
Just make sure to put stuff that belongs there to gcc/ChangeLog and without
gcc/ prefixes.

Jakub

Re: [doc,committed] clarify docs for function attribute "const"

[Martin Sebor]

On 11/26/18 8:45 PM, Sandra Loosemore wrote:

On 11/26/18 8:32 PM, Martin Sebor wrote:

On 11/26/18 11:13 AM, Sandra Loosemore wrote:

On 11/26/18 10:17 AM, Martin Sebor wrote:

On 11/25/18 6:40 PM, Sandra Loosemore wrote:

I've checked in the attached patch for PR79738.


I think we have lost something important with the clarification
of attribute const:

   The @code{const} attribute imposes greater restrictions on
   a function's definition than the similar @code{pure} attribute
   below because it additionally prohibits the function from reading
   memory except for constant global variables.

Permitting a const function to only read global constants means
it can't read local variables (including static const locals).
Something like the following should fix that:

   The @code{const} attribute prohibits a function from accessing
   objects whose value can change between successive invocations of
   the function.  Functions declared with the @code{const} attribute
   may access non-volatile constant objects with any storage duration.
   The attribute imposes greater restrictions on a function's 
definition

   than the similar @code{pure} attribute.

I have also removed the mention of global variables (since objects
at other scopes, including static locals or thread-local variables,
are also included) and instead of "reading" used the term "accessing"
since const functions can neither read nor write such objects.
  Finally, I've avoided describing the attribute in terms of pure
("additionally") and instead only mentioned pure for reference.

Let me know how this sounds.


Hmmm.  If we go with this wording, then the description of "pure" 
needs to be updated too, since it also uses the "constant global 
variables" language now to describe how it differs from "pure".  I 
think we do need some succinct summary of exactly how the two 
attributes differ to explain why it is an error to provide both 
attributes and help users choose which is more appropriate.  Using 
parallel language except in the particulars that differ is one way to 
accomplish that.


I admit I really struggled with the wording in coming up with the 
previous patch  :-(  I thought I understood the difference, but I 
guess not.  :-(


I agree that both const and pure should be updated as well.  Let
me put together a patch for both.


Thanks.  I was going to take another stab at it myself after finishing 
some other stuff in my queue, but I'll wait and see what you suggest.


Attached is my proposed update.  The user's email suggested going
into a lot of detail that I'm not sure would be helpful.  I think
it's safer to keep it simple than to try to carefully outline tricky
conditions under which some const or pure functions might get away
with modifying program state.  At the same time, I tried not to
outright prohibit it so I phrased the restrictions in terms of
observable program state (as opposed to reading or writing
"global" variables and such).

I also made a few other changes, like move the example of
the square function from pure to const (since the function is
much more likely const), and made the const restrictions stand
on their own, rather than depending on pure.

Martin
PR 79738 - Documentation for __attribute__((const)) slightly misleading

	* doc/extend.texi (attribute const, pure): Clarify.

Index: /ssd/src/gcc/svn/gcc/doc/extend.texi
===
--- /ssd/src/gcc/svn/gcc/doc/extend.texi	(revision 266760)
+++ /ssd/src/gcc/svn/gcc/doc/extend.texi	(working copy)
@@ -2518,25 +2518,45 @@ are automatically detected and this attribute is i
 @item const
 @cindex @code{const} function attribute
 @cindex functions that have no side effects
-Many functions do not examine any values except their arguments, and
-have no effects except to return a value.  Calls to such functions lend
-themselves to optimization such as common subexpression elimination.
-The presence of the @code{const} attribute on a function declaration 
-allows GCC to emit more efficient code for some calls to the function.  
+Calls to functions whose return value is not affected by changes to
+the observable state of the program and that have no observable effects
+on such state other than to return a value may lend themselves to
+optimizations such as common subexpression elimination.  Declaring such
+functions with the @code{const} attribute allows GCC to emit more efficient
+code for consecutive calls to the function.
 
+The @code{const} attribute prohibits a function from reading objects
+that affect its return value between successive invocations.  However,
+functions declared with the attribute can safely read objects that do
+not affect their return value, such as non-volatile constants.
 The @code{const} attribute imposes greater restrictions on a function's
-definition than the similar @code{pure} attribute below because it
-additionally prohibits the function from reading memory except for

Re: [PATCH] Delete powerpcspe

[Jeff Law]

On 12/3/18 1:50 PM, Segher Boessenkool wrote:
> This deletes powerpcspe, which was deprecated for GCC 8.
> 
> I'm not including the  rm -r gcc/config/powerpcspe  part in the patch,
> see the diffstat summary for why.
> 
> This does not change the testsuite, or libgcc for rs6000 (which still
> is shared code with powerpcspe, so can use some cleanup after this).
> 
> Tested building a powerpc-linux_spe target; it now is refused.
> 
> Is this okay for trunk?
> 
> 
> Segher
> 
> 
> 2018-12-03  Segher Boessenkool  
> 
>   * contrib/config-list.mk: Remove powerpc-eabispe and powerpc-linux_spe.
>   * gcc/config.gcc (Obsolete configurations): Delete powerpc*-*-*spe*.
>   (Unsupported targets): Add powerpc*-*-*spe*.
>   (powerpc*-*-*spe*): Delete.
>   (powerpc-*-eabispe*): Delete.
>   (powerpc-*-rtems*spe*): Delete.
>   (powerpc*-*-linux*spe*): Delete.
>   (powerpc*-*-linux*): Do not handle the linux*spe* targets.
>   (powerpc-wrs-vxworks*spe): Delete.
>   (with_cpu setting code): Delete powerpc*-*-*spe* handling.
>   * gcc/config.host (target powerpc*-*-*spe*): Delete.
>   * gcc/doc/invoke.texi (PowerPC SPE Options): Delete.
>   (PowerPC SPE Options): Delete.
>   * gcc/config/powerpcspe: Delete.
I'm all for it.  Let's give Jakub and Richi and chance to chime in though.

Jeff

Re: [C++ PATCH] Fix xvalue COND_EXPR handling (PR c++/88103)

[Jakub Jelinek]

On Mon, Dec 03, 2018 at 02:44:32PM -0500, Jason Merrill wrote:
> > > Is there a reason not to use the 'move' function here?
> > 
> > That doesn't work at all.  move doesn't call cp_convert, but
> > build_static_cast (though for the same reference && type).
> > But while cp_convert only adds NOP_EXPR around it, build_static_cast adds
> > a target_expr, addr_expr around that, nop_expr cast to the reference && type
> > and finally indirect_ref that the caller doesn't expect, because it adds it
> > by itself, e.g. in
> > 2424if (temp)
> > 2425  object = cp_build_fold_indirect_ref (temp);
> 
> So the caller is trying to take the address of the COND_EXPR, which should
> have POINTER_TYPE.  And then indirecting that gives an lvalue, as it should.
> The bug is in the caller, build_class_member_access_expr.

So like this then (if it passes bootstrap/regtest)?  Seems to fix the
testcase.

2018-12-03  Jakub Jelinek  

PR c++/88103
* typeck.c (build_class_member_access_expr): If unary_complex_lvalue
turned xvalue_p into non-xvalue_p, call move on it.

* g++.dg/cpp0x/rv-cond3.C: New test.

--- gcc/cp/typeck.c.jj  2018-12-02 21:41:09.824475721 +0100
+++ gcc/cp/typeck.c 2018-12-03 22:06:04.425357227 +0100
@@ -2422,7 +2422,13 @@ build_class_member_access_expr (cp_expr
   {
 tree temp = unary_complex_lvalue (ADDR_EXPR, object);
 if (temp)
-  object = cp_build_fold_indirect_ref (temp);
+  {
+   temp = cp_build_fold_indirect_ref (temp);
+   if (xvalue_p (object) && !xvalue_p (temp))
+ /* Preserve xvalue kind.  */
+ temp = move (temp);
+   object = temp;
+  }
   }
 
   /* In [expr.ref], there is an explicit list of the valid choices for
--- gcc/testsuite/g++.dg/cpp0x/rv-cond3.C.jj2018-12-03 22:04:14.064144468 
+0100
+++ gcc/testsuite/g++.dg/cpp0x/rv-cond3.C   2018-12-03 22:04:14.064144468 
+0100
@@ -0,0 +1,22 @@
+// PR c++/88103
+// { dg-do compile { target c++11 } }
+
+struct A {
+  A (int);
+  A&& foo () &&;
+  int i;
+};
+void free (A&&);
+
+void test_xvalue (A a){
+  A&& ref = true ? static_cast (a) : static_cast (a); 
+  free (true ? static_cast (a) : static_cast (a));
+  (true ? static_cast (a) : static_cast (a)).foo ();
+  int&& k = (true ? static_cast (a) : static_cast (a)).i;
+}
+void test_prvalue (A a){
+  A&& ref = true ? static_cast (a) : 1; 
+  free (true ? static_cast (a) : 1);
+  (true ? static_cast (a) : 1).foo ();
+  int&& k = (true ? static_cast (a) : 1).i;
+}


Jakub

Re: [patch,openacc] C, C++ OpenACC wait diagnostic change

[Julian Brown]

On Fri, 30 Nov 2018 16:25:42 +0100
Thomas Schwinge  wrote:

> In addition to your "(1" token sequence (and similar ones), I suppose
> what these code paths in C and C++ are supposed to catch the "wait ()"
> case (see line 149 of gcc/testsuite/c-c++-common/goacc/asyncwait-1.c).
> 
> I suppose in C, we do diagnose an "error: expected expression before
> ')' token" in "c_parser_expr_list"/"c_parser_expr_no_commas", and
> then return a list with an "error_mark_node", right?  (I have not
> verified that.)
> 
> > So, we can elide the
> > diagnostic with no change to compiler behaviour.  
> 
> In that case, yes.

[...]

> Right, one single error diagnostic is enough.
> 
> But please make sure that the "wait ()" case continues to be diagnosed
> correctly -- similarly to C, I suggest "expected expression before ')'
> token" (or whatever is natural to the C++ parser), and then
> accordingly tidy up that "dg-error" regular expression on line 149 of
> gcc/testsuite/c-c++-common/goacc/asyncwait-1.c.
> 
> In C++, this is the case that: "args != NULL && args->length () ==
> 0", I suppose?  (I have not verified that.)
> 
> Oh, and next to "wait ()" please also add test coverage for "wait (".

I've made those changes in the attached, thank you. OK?

Julian

ChangeLog

2018-XX-YY  James Norris  
Cesar Philippidis  
Julian Brown  

gcc/c/
* c-parser.c (c_parser_oacc_wait_list): Remove dead diagnostic
code.

gcc/cp/
* parser.c (cp_parser_oacc_wait_list): Fix error message and avoid
duplicate diagnostic.

gcc/testsuite/
* c-c++-common/goacc/asyncwait-1: Update expected errors and add a
test for "wait (".

Reviewed-by: Thomas Schwinge  
Reviewed-by: Joseph Myers  
commit e3f9a5935e9ec3062017602a580139a0bccf1f4c
Author: Julian Brown 
Date:   Fri Sep 28 05:52:55 2018 -0700

OpenACC wait list diagnostic change

2018-XX-YY  James Norris  
	Cesar Philippidis  
	Julian Brown  

	gcc/c/
	* c-parser.c (c_parser_oacc_wait_list): Remove dead diagnostic
	code.

	gcc/cp/
	* parser.c (cp_parser_oacc_wait_list): Fix error message and avoid
	duplicate diagnostic.

	gcc/testsuite/
	* c-c++-common/goacc/asyncwait-1: Update expected errors and add a
	test for "wait (".

diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c
index afc4071..0d7fcc0 100644
--- a/gcc/c/c-parser.c
+++ b/gcc/c/c-parser.c
@@ -11801,14 +11801,6 @@ c_parser_oacc_wait_list (c_parser *parser, location_t clause_loc, tree list)
 return list;
 
   args = c_parser_expr_list (parser, false, true, NULL, NULL, NULL, NULL);
-
-  if (args->length () == 0)
-{
-  c_parser_error (parser, "expected integer expression before ')'");
-  release_tree_vector (args);
-  return list;
-}
-
   args_tree = build_tree_list_vec (args);
 
   for (t = args_tree; t; t = TREE_CHAIN (t))
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index ab6d237..ac19cb4 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -32605,9 +32605,11 @@ cp_parser_oacc_wait_list (cp_parser *parser, location_t clause_loc, tree list)
 
   if (args == NULL || args->length () == 0)
 {
-  cp_parser_error (parser, "expected integer expression before ')'");
   if (args != NULL)
-	release_tree_vector (args);
+	{
+	  cp_parser_error (parser, "expected integer expression list");
+	  release_tree_vector (args);
+	}
   return list;
 }
 
diff --git a/gcc/testsuite/c-c++-common/goacc/asyncwait-1.c b/gcc/testsuite/c-c++-common/goacc/asyncwait-1.c
index e1840af..2f5d476 100644
--- a/gcc/testsuite/c-c++-common/goacc/asyncwait-1.c
+++ b/gcc/testsuite/c-c++-common/goacc/asyncwait-1.c
@@ -116,7 +116,6 @@ f (int N, float *a, float *b)
 }
 
 #pragma acc parallel copyin (a[0:N]) copy (b[0:N]) wait (1 /* { dg-error "expected '\\\)' before end of line" } */
-/* { dg-error "expected integer expression before '\\\)'" "" { target c++ } .-1 } */
 {
 for (ii = 0; ii < N; ii++)
 b[ii] = a[ii];
@@ -152,6 +151,12 @@ f (int N, float *a, float *b)
 b[ii] = a[ii];
 }
 
+#pragma acc parallel copyin (a[0:N]) copy (b[0:N]) wait ( /* { dg-error "expected (primary-|)expression before" } */
+{
+for (ii = 0; ii < N; ii++)
+b[ii] = a[ii];
+}
+
 #pragma acc parallel copyin (a[0:N]) copy (b[0:N]) wait
 {
 for (ii = 0; ii < N; ii++)
@@ -171,7 +176,6 @@ f (int N, float *a, float *b)
 #pragma acc wait (1,2,,) /* { dg-error "expected (primary-|)expression before" } */
 
 #pragma acc wait (1 /* { dg-error "expected '\\\)' before end of line" } */
-/* { dg-error "expected integer expression before '\\\)'" "" { target c++ } .-1 } */
 
 #pragma acc wait (1,*) /* { dg-error "expected (primary-|)expression before" } */
 

Re: [PATCH, i386]: Correct vec_concatv2df alternative

[Jakub Jelinek]

On Mon, Dec 03, 2018 at 09:47:48PM +0100, Uros Bizjak wrote:
> All avx512f registers support DFmode.
> 
> 2018-12-03  Uros Bizjak  
> 
> * config/i386/sse.md (vec_concatv2df): Change (v,xm,C)
> alternative to (v,vm,c).
> 
> Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.
> 
> Committed to mainline SVN.

Thanks for doing that.

> Index: config/i386/sse.md
> ===
> --- config/i386/sse.md(revision 266745)
> +++ config/i386/sse.md(working copy)
> @@ -9526,7 +9526,7 @@
>  (define_insn "vec_concatv2df"
>[(set (match_operand:V2DF 0 "register_operand" "=x,x,v,x,v,x,x, v,x,x")
>   (vec_concat:V2DF
> -   (match_operand:DF 1 "nonimmediate_operand" " 0,x,v,m,m,0,x,xm,0,0")
> +   (match_operand:DF 1 "nonimmediate_operand" " 0,x,v,m,m,0,x,vm,0,0")
> (match_operand:DF 2 "nonimm_or_0_operand"  " x,x,v,1,1,m,m, C,x,m")))]
>"TARGET_SSE
> && (!(MEM_P (operands[1]) && MEM_P (operands[2]))

Jakub

[PATCH] Delete powerpcspe

[Segher Boessenkool]

This deletes powerpcspe, which was deprecated for GCC 8.

I'm not including the  rm -r gcc/config/powerpcspe  part in the patch,
see the diffstat summary for why.

This does not change the testsuite, or libgcc for rs6000 (which still
is shared code with powerpcspe, so can use some cleanup after this).

Tested building a powerpc-linux_spe target; it now is refused.

Is this okay for trunk?


Segher


2018-12-03  Segher Boessenkool  

* contrib/config-list.mk: Remove powerpc-eabispe and powerpc-linux_spe.
* gcc/config.gcc (Obsolete configurations): Delete powerpc*-*-*spe*.
(Unsupported targets): Add powerpc*-*-*spe*.
(powerpc*-*-*spe*): Delete.
(powerpc-*-eabispe*): Delete.
(powerpc-*-rtems*spe*): Delete.
(powerpc*-*-linux*spe*): Delete.
(powerpc*-*-linux*): Do not handle the linux*spe* targets.
(powerpc-wrs-vxworks*spe): Delete.
(with_cpu setting code): Delete powerpc*-*-*spe* handling.
* gcc/config.host (target powerpc*-*-*spe*): Delete.
* gcc/doc/invoke.texi (PowerPC SPE Options): Delete.
(PowerPC SPE Options): Delete.
* gcc/config/powerpcspe: Delete.

---
 151 files changed, 3 insertions(+), 112988 deletions(-)

diff --git a/contrib/config-list.mk b/contrib/config-list.mk
index cbb9e28b..5acd766 100644
--- a/contrib/config-list.mk
+++ b/contrib/config-list.mk
@@ -73,9 +73,9 @@ LIST = aarch64-elf aarch64-linux-gnu aarch64-rtems \
   pdp11-aout \
   powerpc-darwin8 \
   powerpc-darwin7 powerpc64-darwin powerpc-freebsd6 powerpc-netbsd \
-  powerpc-eabispe powerpc-eabisimaltivec powerpc-eabisim ppc-elf \
+  powerpc-eabisimaltivec powerpc-eabisim ppc-elf \
   powerpc-eabialtivec powerpc-xilinx-eabi powerpc-eabi \
-  powerpc-rtems powerpc-linux_spe \
+  powerpc-rtems \
   powerpc64-linux_altivec \
   powerpc-wrs-vxworks powerpc-wrs-vxworksae powerpc-wrs-vxworksmils \
   powerpc-lynxos powerpcle-elf \
diff --git a/gcc/config.gcc b/gcc/config.gcc
index cbabd21..d35103e 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -248,7 +248,6 @@ md_file=
 # Obsolete configurations.
 case ${target} in
   *-*-solaris2.10* \
-  | powerpc*-*-*spe*   \
   | tile*-*-*  \
  )
 if test "x$enable_obsolete" != xyes; then
@@ -279,6 +278,7 @@ case ${target} in
  | mips64orion*-*-rtems*   \
  | pdp11-*-bsd \
  | powerpc*-*-linux*paired*\
+ | powerpc*-*-*spe*\
  | sparc-hal-solaris2* \
  | thumb-*-*   \
  | *-*-freebsd[12] | *-*-freebsd[1234].* \
@@ -488,16 +488,6 @@ nvptx-*-*)
 or1k*-*-*)
cpu_type=or1k
;;
-powerpc*-*-*spe*)
-   cpu_type=powerpcspe
-   extra_headers="ppc-asm.h altivec.h spe.h ppu_intrinsics.h paired.h 
spu2vmx.h vec_types.h si2vmx.h htmintrin.h htmxlintrin.h"
-   case x$with_cpu in
-   
xpowerpc64|xdefault64|x6[23]0|x970|xG5|xpower[3456789]|xpower6x|xrs64a|xcell|xa2|xe500mc64|xe5500|xe6500)
-   cpu_is_64bit=yes
-   ;;
-   esac
-   extra_options="${extra_options} g.opt fused-madd.opt 
powerpcspe/powerpcspe-tables.opt"
-   ;;
 powerpc*-*-*)
cpu_type=rs6000
extra_objs="rs6000-string.o rs6000-p8swap.o"
@@ -2588,12 +2578,6 @@ powerpc-*-netbsd*)
tmake_file="${tmake_file} rs6000/t-netbsd"
extra_options="${extra_options} rs6000/sysv4.opt"
;;
-powerpc-*-eabispe*)
-   tm_file="${tm_file} dbxelf.h elfos.h freebsd-spec.h newlib-stdint.h 
${cpu_type}/sysv4.h ${cpu_type}/eabi.h ${cpu_type}/e500.h ${cpu_type}/eabispe.h"
-   extra_options="${extra_options} ${cpu_type}/sysv4.opt"
-   tmake_file="${cpu_type}/t-spe ${cpu_type}/t-ppccomm"
-   use_gcc_stdint=wrap
-   ;;
 powerpc-*-eabisimaltivec*)
tm_file="${tm_file} dbxelf.h elfos.h gnu-user.h freebsd-spec.h 
newlib-stdint.h rs6000/sysv4.h rs6000/eabi.h rs6000/eabisim.h 
rs6000/eabialtivec.h"
extra_options="${extra_options} rs6000/sysv4.opt"
@@ -2623,26 +2607,11 @@ powerpc-*-eabi*)
tmake_file="rs6000/t-fprules rs6000/t-ppcgas rs6000/t-ppccomm"
use_gcc_stdint=wrap
;;
-powerpc-*-rtems*spe*)
-   tm_file="${tm_file} dbxelf.h elfos.h freebsd-spec.h newlib-stdint.h 
powerpcspe/sysv4.h powerpcspe/eabi.h powerpcspe/e500.h powerpcspe/rtems.h 
rtems.h"
-   extra_options="${extra_options} powerpcspe/sysv4.opt"
-   tmake_file="${tmake_file} powerpcspe/t-fprules powerpcspe/t-rtems 
powerpcspe/t-ppccomm"
-   ;;
 powerpc-*-rtems*)
tm_file="rs6000/biarch64.h ${tm_file} dbxelf.h elfos.h gnu-user.h 
freebsd-spec.h newlib-stdint.h rs6000/sysv4.h rs6000/rtems.h rtems.h"
extra_options="${extra_options} rs6000/sysv4.opt rs6000/linux64.opt"
tmake_file="${tmake_file} rs6000/t-fprules rs6000/t-rtems 
rs6000/t-ppccomm"
;;
-powerpc*-*-linux*spe*)
-   tm_file="${tm_file} dbxelf.h elfos.h gnu-user.h freebsd-spec.h 

[PATCH, i386]: Correct vec_concatv2df alternative

[Uros Bizjak]

All avx512f registers support DFmode.

2018-12-03  Uros Bizjak  

* config/i386/sse.md (vec_concatv2df): Change (v,xm,C)
alternative to (v,vm,c).

Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.

Committed to mainline SVN.

Uros.
Index: config/i386/sse.md
===
--- config/i386/sse.md  (revision 266745)
+++ config/i386/sse.md  (working copy)
@@ -9526,7 +9526,7 @@
 (define_insn "vec_concatv2df"
   [(set (match_operand:V2DF 0 "register_operand" "=x,x,v,x,v,x,x, v,x,x")
(vec_concat:V2DF
- (match_operand:DF 1 "nonimmediate_operand" " 0,x,v,m,m,0,x,xm,0,0")
+ (match_operand:DF 1 "nonimmediate_operand" " 0,x,v,m,m,0,x,vm,0,0")
  (match_operand:DF 2 "nonimm_or_0_operand"  " x,x,v,1,1,m,m, C,x,m")))]
   "TARGET_SSE
&& (!(MEM_P (operands[1]) && MEM_P (operands[2]))

libgo patch committed: Allow buildmode c-archive on ppc64

[Ian Lance Taylor]

This libgo patch by Lynn Boger changes the go tool to allow buildmode
c-archive for gccgo on ppc64.  In buildmodeinit, the c-archive
buildmode is flagged as invalid on GNU/Linux ppc64 for gccgo when it
should be valid. This happens because the check against the gccgo flag
is done after the checks for valid GOOS/GOARCH pairs instead of before
as is done for all other buildmode cases in this switch. This corrects
the problem and allows several of the gccgo gotools testcases to pass
on GNU/Linux ppc64.  This is for https://golang.org/issue/29046.
Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.  Committed
to mainline.

Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 266573)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-a8f768d68760768da5e86a8e63ef1ad5691c3ae8
+9e016dfe198152f870005ac844fe22c02e5349e3
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
Index: libgo/go/cmd/go/internal/work/init.go
===
--- libgo/go/cmd/go/internal/work/init.go   (revision 266510)
+++ libgo/go/cmd/go/internal/work/init.go   (working copy)
@@ -85,23 +85,24 @@ func buildModeInit() {
pkgsFilter = pkgsNotMain
case "c-archive":
pkgsFilter = oneMainPkg
-   switch platform {
-   case "darwin/arm", "darwin/arm64":
-   codegenArg = "-shared"
-   default:
-   switch cfg.Goos {
-   case "dragonfly", "freebsd", "linux", "netbsd", 
"openbsd", "solaris":
-   if platform == "linux/ppc64" {
-   base.Fatalf("-buildmode=c-archive not 
supported on %s\n", platform)
-   }
-   // Use -shared so that the result is
-   // suitable for inclusion in a PIE or
-   // shared library.
-   codegenArg = "-shared"
-   }
-   }
if gccgo {
codegenArg = "-fPIC"
+   } else {
+   switch platform {
+   case "darwin/arm", "darwin/arm64":
+   codegenArg = "-shared"
+   default:
+   switch cfg.Goos {
+   case "dragonfly", "freebsd", "linux", "netbsd", 
"openbsd", "solaris":
+   if platform == "linux/ppc64" {
+   
base.Fatalf("-buildmode=c-archive not supported on %s\n", platform)
+   }
+   // Use -shared so that the result is
+   // suitable for inclusion in a PIE or
+   // shared library.
+   codegenArg = "-shared"
+   }
+   }
}
cfg.ExeSuffix = ".a"
ldBuildmode = "c-archive"

Re: [PATCH 1/9]: C++ P0482R5 char8_t: Documentation updates

[Jason Merrill]

On 11/5/18 2:39 PM, Tom Honermann wrote:

This patch adds documentation for new -fchar8_t and -fno-char8_t options.

gcc/ChangeLog:

2018-11-04  Tom Honermann  
  * doc/invoke.texi (-fchar8_t): Document new option.



+Enable support for the P0482 proposal including the addition of a
+new @code{char8_t} fundamental type, changes to the types of UTF-8


Now that the proposal has been accepted, I'd refer to C++2a instead.

Jason

Re: [C++ PATCH] Fix xvalue COND_EXPR handling (PR c++/88103)

[Jason Merrill]

On 12/2/18 8:07 AM, Jakub Jelinek wrote:

On Sat, Dec 01, 2018 at 07:11:08PM -0500, Jason Merrill wrote:

On the following testcase, build_conditional_expr_1 tries hard to make sure
that if both arguments are xvalue_p (or one is and the other throw) the
result is still xvalue_p.  But, later on we call unary_complex_lvalue,
which does rationalize_conditional_expr which changes it from
cond ? x : y to *(cond ?  : ) and that change turns something formerly
xvalue_p into newly lvalue_p.

Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
ok for trunk?

2018-11-29  Jakub Jelinek  

PR c++/88103
* typeck.c (unary_complex_lvalue): If a COND_EXPR is xvalue_p, make
sure the result is as well.

* g++.dg/cpp0x/rv-cond3.C: New test.

--- gcc/cp/typeck.c.jj  2018-11-27 09:48:58.506103668 +0100
+++ gcc/cp/typeck.c 2018-11-29 21:00:33.900636750 +0100
@@ -6503,7 +6503,16 @@ unary_complex_lvalue (enum tree_code cod
 /* Handle (a ? b : c) used as an "lvalue".  */
 if (TREE_CODE (arg) == COND_EXPR
 || TREE_CODE (arg) == MIN_EXPR || TREE_CODE (arg) == MAX_EXPR)
-return rationalize_conditional_expr (code, arg, tf_warning_or_error);
+{
+  tree ret = rationalize_conditional_expr (code, arg, tf_warning_or_error);
+  /* Preserve xvalue kind.  */
+  if (xvalue_p (arg))
+   {
+ tree reftype = cp_build_reference_type (TREE_TYPE (arg), true);
+ ret = cp_convert (reftype, ret, tf_warning_or_error);


Is there a reason not to use the 'move' function here?


That doesn't work at all.  move doesn't call cp_convert, but
build_static_cast (though for the same reference && type).
But while cp_convert only adds NOP_EXPR around it, build_static_cast adds
a target_expr, addr_expr around that, nop_expr cast to the reference && type
and finally indirect_ref that the caller doesn't expect, because it adds it
by itself, e.g. in
2424if (temp)
2425  object = cp_build_fold_indirect_ref (temp);


So the caller is trying to take the address of the COND_EXPR, which 
should have POINTER_TYPE.  And then indirecting that gives an lvalue, as 
it should.  The bug is in the caller, build_class_member_access_expr.


Jason

Re: [RFC][PATCH]Merge VEC_COND_EXPR into MASK_STORE after loop vectorization

[Jeff Law]

On 11/20/18 7:57 AM, Renlin Li wrote:
> Hi Richard,
> 
> On 11/14/2018 02:59 PM, Richard Biener wrote:
>> On Fri, Nov 9, 2018 at 4:49 PM Renlin Li  wrote:
>>>
>>> Hi Richard,
>>>
>>> On 11/09/2018 11:48 AM, Richard Biener wrote:
 On Thu, Nov 8, 2018 at 5:55 PM Renlin Li  wrote:

>
> Hi Richard,
>
>
>> I don't see the masked load here on x86_64 btw. (I don't see
>> if-conversion generating a load).
>> I guess that's again when store-data-races are allowed that it uses a
>> RMW cycle and vectorization
>> generating the masked variants for the loop-mask.  Which means for SVE
>> if-conversion should
>> prefer the masked-store variant even when store data races are allowed?
> 
> Yes, it looks like, for SVE, masked-store variant is preferred even when 
> store data races are allowed.
> 
> This decision is made in if-cvt.
> 
> mask_store need a pointer, and if it is created from an array access, we need 
> to make sure the data reference analysis
> 
> could properly analysis relationship between array reference and pointer 
> reference.
> 
> So that no versioned loop is generated during loop vectorization.
> (This is a general improvement, and could be done in a different patch?)
> 
>>
>>>

 I was wondering whether we can implement

 l = [masked]load;
 tem = cond ? x : l;
 masked-store = tem;

 pattern matching in a regular pass - forwprop for example.  Note the
 load doesn't need to be masked,
 correct?  In fact if it is masked you need to make sure the
 conditional never accesses parts that
 are masked in the load, no?  Or require the mask to be the same as
 that used by the store.  But then
 you still cannot simply replace the store mask with a new mask
 generated from the conditional?
>>>
>>> Yes, this would require the mask for load and store is the same.
>>> This matches the pattern before loop vectorization.
>>> The mask here is loop mask, to ensure we are bounded by the number of 
>>> iterations.
>>>
>>>
>>> The new mask is the (original mask & condition mask) (example shown above).
>>>
>>> In this case, less lanes will be stored.
>>>
>>> It is possible we do that in forwprop.
>>> I could try to integrate the change into it if it is the correct place to 
>>> go.
>>>
>>>
>>> As the pattern is initially generated by loop vectorizer, I did the change 
>>> right after it before it got
>>>
>>> converted into other forms. For example, forwprop will transform the 
>>> original code into:
>>>
>>>
>>> vect__2.4_29 = vect_cst__27 + { 1, ... };
>>> _16 = (void *) ivtmp.13_25;
>>> _2 = [base: _16, offset: 0B];
>>> vect__ifc__24.7_33 = .MASK_LOAD (_2, 4B, loop_mask_32);
>>> _28 = vect_cst__34 != { 0, ... };
>>> _35 = .COND_ADD (_28, vect_cst__27, { 1, ... }, vect__ifc__24.7_33);
>>> vect__ifc__26.8_36 = _35;
>>> .MASK_STORE (_2, 4B, loop_mask_32, vect__ifc__26.8_36);
>>> ivtmp_41 = ivtmp_40 + POLY_INT_CST [4, 4];
>>> next_mask_43 = .WHILE_ULT (ivtmp_41, 16, { 0, ... });
>>> ivtmp.13_15 = ivtmp.13_25 + POLY_INT_CST [16, 16];
>>>
>>> This make the pattern matching not straight forward.
>>
>> Ah, that's because of the .COND_ADDs (I wonder about the copy that's
>> left - forwprop should eliminate copies).  Note the pattern-matching
>> could go in the
>>
>>    /* Apply forward propagation to all stmts in the basic-block.
>>   Note we update GSI within the loop as necessary.  */
>>
>> loop which comes before the match.pd pattern matching so you'd
>> still see the form without the .COND_ADD I think.
>>
>> There _is_ precedence for some masked-store post-processing
>> in the vectorizer (optimize_mask_stores), not that I like that
>> very much either.  Eventually those can be at least combined...
> Thanks for your suggestion, indeed .COND_ADD is generated later in fold_stmt 
> function.
> 
> 
> I update the patch with the style of "forward-propagation". It starts from
> VEC_COND, and forward propagate it into MASK_STORE when specific pattern is 
> found.
> 
> 
>  X = MASK_LOAD (PTR, -, MASK)
>  VAL = ...
>  Y = VEC_COND (cond, VAL, X)
>  MASK_STORE (PTR, -, MASK, Y)
>>
>> That said, I prefer the forwprop place for any pattern matching
>> and the current patch needs more comments to understand
>> what it is doing (the DCE it does is IMHO premature).  You
>> should also modify the masked store in-place rather than
>> building a new one.  I don't like how you need to use
>> find_data_references_in_stmt, can't you simply compare
>> the address and size arguments?  
> 
> find_data_references_in_stmt is used because the two data reference are 
> created
> 
> as two new SSA_NAMEs from same scalar pointer by loop vectorizer.
> I can not directly compare the address as the are complicated with loop 
> information.
> 
> 
> By moving the functionality into forwprop, the complications are removed by 
> the optimizers in between.
> 
> This makes a simple comparison 

[PATCH] Disallow configuring for powerpc*-*-linux*paired

[Segher Boessenkool]

The proper way, that is.

Committing to trunk.


Segher


2018-12-03  Segher Boessenkool  

* gcc/config.gcc (Unsupported targets): Add powerpc*-*-linux*paired*.
(powerpc*-*-linux*): Don't handle it here.

---
 gcc/config.gcc | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/gcc/config.gcc b/gcc/config.gcc
index f6162ed..cbabd21 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -278,6 +278,7 @@ case ${target} in
  | m68k-*-uclinuxoldabi*   \
  | mips64orion*-*-rtems*   \
  | pdp11-*-bsd \
+ | powerpc*-*-linux*paired*\
  | sparc-hal-solaris2* \
  | thumb-*-*   \
  | *-*-freebsd[12] | *-*-freebsd[1234].* \
@@ -2660,7 +2661,7 @@ powerpc*-*-linux*)
all) maybe_biarch=yes ;;
esac
case ${target} in
-   powerpc64*-*-linux*spe* | powerpc*-*-linux*paired*)
+   powerpc64*-*-linux*spe*)
echo "*** Configuration ${target} not supported" 1>&2
exit 1
;;
-- 
1.8.3.1

Re: [PATCH 2/9][GCC][AArch64][middle-end] Add rules to strip away unneeded type casts in expressions

[Jeff Law]

On 11/28/18 10:57 AM, Tamar Christina wrote:
> Hi Joseph,
> 
> This is an updated version of my first patch which moves part of the type 
> conversion code
> from convert.c to match.pd because match.pd is able to apply this 
> transformation in the
> presence of intermediate temporary variables.
> 
> I couldn't move the error parts as match.pd doesn't seem to have access to 
> the diagnostics
> bits and also I feel like this may be a bit against the philosophy of 
> match.pd. 
> 
> Regtested and bootstrapped on aarch64-none-linux-gnu and no issues.
> 
> Ok for trunk?
> 
> Thanks,
> Tamar
> 
> Concretely it makes both these cases behave the same
> 
>   float e = (float)a * (float)b;
>   *c = (_Float16)e;
> 
> and 
> 
>   *c = (_Float16)((float)a * (float)b);
> 
> Thanks,
> Tamar
> 
> gcc/ChangeLog:
> 
> 2018-11-28  Tamar Christina  
> 
>   * convert.c (convert_to_real_1): Move part of conversion code...
>   * match.pd: ...To here.
> 
> gcc/testsuite/ChangeLog:
> 
> 2018-11-28  Tamar Christina  
> 
>   * gcc.dg/type-convert-var.c: New test.
OK.

Re: [Patch, ppc/darwin 2/2] Make Darwin's call handling follow the style of AIX/ELFv2/sysv.

[Iain Sandoe]

> On 3 Dec 2018, at 01:28, Iain Sandoe  wrote:

> The second patch normalises Darwin’s call handling to follow the same pattern 
> that Alan introduced recently.

revised version, on top of the revised patch 1 attached.  I’ve taken the 
opportunity to reduce the number of TARGET_MACHO conditionals in rs6000.md 
(handle in rs6000.c instead)

Iain

> Hopefully it makes it clearer where there are differences (actually quite 
> small in this case, but enough to make it better to separate the lowering).  
> It isn’t needed to fix bootstrap, but it was a good time to figure it out 
> when dealing with this.
> 
> OK for trunk / next stage #1 / comments?
> Iain
> 
> gcc/
> 
>   * config/rs6000/rs6000-protos.h (rs6000_call_darwin, 
> rs6000_sibcall_darwin): New.
>   (macho_call_template): remove.
>   * config/rs6000/rs6000.c (get_prev_label): Forward declaration. 
>   (rs6000_call_template_1): Handle Darwin. (macho_call_template): Remove.
>   (rs6000_call_sysv): Remove handling for Darwin, save cookie value.
>   (rs6000_call_darwin_1, rs6000_call_darwin, rs6000_sibcall_darwin): New.
>   * config/rs6000/rs6000.md (define_expand “call”): Handle Darwin with 
> its own
>   expander. (define_expand “call_value”): Likewise. (define_expand 
> “sibcall”): Likewise.
>   (define_expand “sibcall_value”): Likewise.  (call_nonlocal_sysv): 
> Remove 
>   Darwin special-casing.  (call_value_nonlocal_sysv): Likewise.
> 
> From cf45459dc7f317bcf5f415219884e6b846fe01a1 Mon Sep 17 00:00:00 2001
> From: Iain Sandoe 
> Date: Sat, 1 Dec 2018 16:23:20 +
> Subject: [PATCH] [darwin,ppc] Update call expansions to follow the new scheme.
> 
> This also makes it a bit more apparent what we can remove when the
> mlongcall optimisation is removed.
> ---
> gcc/config/rs6000/rs6000-protos.h |   8 +-
> gcc/config/rs6000/rs6000.c| 195 +-
> gcc/config/rs6000/rs6000.md   |  47 +--
> 3 files changed, 180 insertions(+), 70 deletions(-)
> 
> diff --git a/gcc/config/rs6000/rs6000-protos.h 
> b/gcc/config/rs6000/rs6000-protos.h
> index dfee1f28aa..6d2b7ed917 100644
> --- a/gcc/config/rs6000/rs6000-protos.h
> +++ b/gcc/config/rs6000/rs6000-protos.h
> @@ -199,6 +199,10 @@ extern void rs6000_call_aix (rtx, rtx, rtx, rtx);
> extern void rs6000_sibcall_aix (rtx, rtx, rtx, rtx);
> extern void rs6000_call_sysv (rtx, rtx, rtx, rtx);
> extern void rs6000_sibcall_sysv (rtx, rtx, rtx, rtx);
> +#if TARGET_MACHO
> +extern void rs6000_call_darwin (rtx, rtx, rtx, rtx);
> +extern void rs6000_sibcall_darwin (rtx, rtx, rtx, rtx);
> +#endif
> extern void rs6000_aix_asm_output_dwarf_table_ref (char *);
> extern void get_ppc476_thunk_name (char name[32]);
> extern bool rs6000_overloaded_builtin_p (enum rs6000_builtins);
> @@ -226,10 +230,6 @@ extern void (*rs6000_target_modify_macros_ptr) (bool, 
> HOST_WIDE_INT,
> /* Declare functions in rs6000-d.c  */
> extern void rs6000_d_target_versions (void);
> 
> -#if TARGET_MACHO
> -char *macho_call_template (rtx_insn *, rtx *, int, int);
> -#endif
> -
> #ifdef NO_DOLLAR_IN_LABEL
> const char * rs6000_xcoff_strip_dollar (const char *);
> #endif
> diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
> index bce968516c..5fef3fa036 100644
> --- a/gcc/config/rs6000/rs6000.c
> +++ b/gcc/config/rs6000/rs6000.c
> @@ -1364,6 +1364,7 @@ static rtx rs6000_darwin64_record_arg (CUMULATIVE_ARGS 
> *, const_tree,
>  bool, bool);
> #if TARGET_MACHO
> static void macho_branch_islands (void);
> +static tree get_prev_label (tree);
> #endif
> static rtx rs6000_legitimize_reload_address (rtx, machine_mode, int, int,
>int, int *);
> @@ -21513,13 +21514,39 @@ rs6000_call_template_1 (rtx *operands, unsigned int 
> funop, bool sibcall)
>   ? "+32768" : ""));
> 
>   static char str[32];  /* 2 spare */
> -  if (DEFAULT_ABI == ABI_AIX || DEFAULT_ABI == ABI_ELFv2
> -  || DEFAULT_ABI == ABI_DARWIN)
> +  if (DEFAULT_ABI == ABI_AIX || DEFAULT_ABI == ABI_ELFv2)
> sprintf (str, "b%s %s%s%s", sibcall ? "" : "l", z, arg,
>sibcall ? "" : "\n\tnop");
>   else if (DEFAULT_ABI == ABI_V4)
> sprintf (str, "b%s %s%s%s", sibcall ? "" : "l", z, arg,
>flag_pic ? "@plt" : "");
> +#if TARGET_MACHO
> +  /* If/when we remove the mlongcall opt, we can share the AIX/ELFv2 case. */
> +   else if (DEFAULT_ABI == ABI_DARWIN)
> +{
> +  /* The cookie is in operand func+2.  */
> +  gcc_checking_assert (GET_CODE (operands[funop + 2]) == CONST_INT);
> +  int cookie = INTVAL (operands[funop + 2]);
> +  if (cookie & CALL_LONG)
> + {
> +   tree funname = get_identifier (XSTR (operands[funop], 0));
> +   tree labelname = get_prev_label (funname);
> +   gcc_checking_assert (labelname && !sibcall);
> +
> +   /* "jbsr foo, L42" is Mach-O for "Link as 'bl foo' if a 'bl'
> +  instruction will reach 'foo', otherwise link as 'bl 

Re: [Patch, ppc/darwin 1/2] Fix bootstrap.

[Iain Sandoe]

> On 3 Dec 2018, at 06:18, Alan Modra  wrote:
> 
> On Mon, Dec 03, 2018 at 01:26:48AM +, Iain Sandoe wrote:

>> The first patch makes Darwin share the sysv lowering, up until late in the 
>> process when we still use the macho_call_template.  This means we need to 
>> preserve the CALL_LONG flag for Darwin.
>> 
>> In order to match this for Darwin64, the sysv patterns needed the clobber 
>> mode to follow that of the pattern.  It seems that this might be a typo - 
>> since it’s not obvious how it would work for powerpc64 sysv as things stand 
>> (AIX and ELFv2 already follow the mode).
> 
> Hmm, yes, and I think there may be some more modes to fix.
> call_local64, call_value_local64, call_nonlocal_sysv splitter,
> call_value_nonlocal_sysv splitter, call_value_nonlocal_sysv_secure.

I’m slightly twitchy about patches I can’t fully test ..

… but
> 
>> ;; Call and call_value insns
>> +;; For the purposes of expanding calls, Darwin is very similar to SYSV.
>> (define_expand "call"
>>   [(parallel [(call (mem:SI (match_operand 0 "address_operand"))
>>  (match_operand 1 ""))
>> @@ -10288,7 +10289,7 @@
>>   DONE;
>> }
>> 
>> -  if (DEFAULT_ABI == ABI_V4)
>> +  if (DEFAULT_ABI == ABI_V4 || DEFAULT_ABI == ABI_DARWIN)
> 
> Better yet, replace this line with "else" and tidy a little.  There's
> some dead code and the "DONE" can move out of the conditional blocks.
> 
>> {
>>   rs6000_call_sysv (NULL_RTX, operands[0], operands[1], operands[2]);
>>   DONE;
> 
> 
>> @@ -10321,7 +10322,7 @@
>>   DONE;
>> }
>> 
>> -  if (DEFAULT_ABI == ABI_V4)
>> +  if (DEFAULT_ABI == ABI_V4 || DEFAULT_ABI == ABI_DARWIN)
> 
> Similarly here,
> 
>> @@ -10765,7 +10766,7 @@
>>   DONE;
>> }
>> 
>> -  if (DEFAULT_ABI == ABI_V4)
>> +  if (DEFAULT_ABI == ABI_V4 || DEFAULT_ABI == ABI_DARWIN)
> 
> and here,
> 
>> {
>>   rs6000_sibcall_sysv (NULL_RTX, operands[0], operands[1], operands[2]);
>>   DONE;
>> @@ -10796,7 +10797,7 @@
>>   DONE;
>> }
>> 
>> -  if (DEFAULT_ABI == ABI_V4)
>> +  if (DEFAULT_ABI == ABI_V4 || DEFAULT_ABI == ABI_DARWIN)
> 
> and here.
> 
>> {
>>   rs6000_sibcall_sysv (operands[0], operands[1], operands[2], 
>> operands[3]);
>>   DONE;
>> -- 
>> 2.17.1

those are nice tidyups - done. as attached..

bootstrapped w/out issues on gcc110 (Darwin will take a longer to regstrap)..

Iain

>> 
> 
> -- 
> Alan Modra
> Australia Development Lab, IBM

From 3e9b487495807f1ba5c6709785536176b6540fd1 Mon Sep 17 00:00:00 2001
From: Iain Sandoe 
Date: Fri, 30 Nov 2018 09:10:43 +
Subject: [PATCH] [PATCH,PPC] Fix up revised call handling for Darwin.

---
 gcc/config/rs6000/darwin.md | 60 -
 gcc/config/rs6000/rs6000.c  | 13 +--
 gcc/config/rs6000/rs6000.md | 75 +
 3 files changed, 35 insertions(+), 113 deletions(-)

diff --git a/gcc/config/rs6000/darwin.md b/gcc/config/rs6000/darwin.md
index a1c07702d6..ff8062c110 100644
--- a/gcc/config/rs6000/darwin.md
+++ b/gcc/config/rs6000/darwin.md
@@ -300,66 +300,6 @@ You should have received a copy of the GNU General Public 
License
   "addis %0,%1,ha16(%2-%3)\n\taddi %0,%0,lo16(%2-%3)"
   [(set_attr "length" "8")])
 
-(define_insn "*call_indirect_nonlocal_darwin64"
-  [(call (mem:SI (match_operand:DI 0 "register_operand" "c,*l,c,*l"))
-(match_operand 1))
-   (use (match_operand:SI 2 "immediate_operand" "O,O,n,n"))
-   (clobber (reg:SI LR_REGNO))]
-  "DEFAULT_ABI == ABI_DARWIN && TARGET_64BIT"
-{
-  return "b%T0l";
-}
-  [(set_attr "type" "jmpreg,jmpreg,jmpreg,jmpreg")
-   (set_attr "length" "4,4,8,8")])
-
-(define_insn "*call_nonlocal_darwin64"
-  [(call (mem:SI (match_operand:DI 0 "symbol_ref_operand" "s,s"))
-(match_operand 1))
-   (use (match_operand:SI 2 "immediate_operand" "O,n"))
-   (clobber (reg:SI LR_REGNO))]
-  "(DEFAULT_ABI == ABI_DARWIN)
-   && (INTVAL (operands[2]) & CALL_LONG) == 0"
-{
-#if TARGET_MACHO
-  return output_call(insn, operands, 0, 2);
-#else
-  gcc_unreachable ();
-#endif
-}
-  [(set_attr "type" "branch,branch")
-   (set_attr "length" "4,8")])
-
-(define_insn "*call_value_indirect_nonlocal_darwin64"
-  [(set (match_operand 0 "" "")
-   (call (mem:SI (match_operand:DI 1 "register_operand" "c,*l,c,*l"))
- (match_operand 2)))
-   (use (match_operand:SI 3 "immediate_operand" "O,O,n,n"))
-   (clobber (reg:SI LR_REGNO))]
-  "DEFAULT_ABI == ABI_DARWIN"
-{
-  return "b%T1l";
-}
-  [(set_attr "type" "jmpreg,jmpreg,jmpreg,jmpreg")
-   (set_attr "length" "4,4,8,8")])
-
-(define_insn "*call_value_nonlocal_darwin64"
-  [(set (match_operand 0 "" "")
-   (call (mem:SI (match_operand:DI 1 "symbol_ref_operand" "s,s"))
- (match_operand 2)))
-   (use (match_operand:SI 3 "immediate_operand" "O,n"))
-   (clobber (reg:SI LR_REGNO))]
-  "(DEFAULT_ABI == ABI_DARWIN)
-   && (INTVAL (operands[3]) & CALL_LONG) == 0"
-{
-#if TARGET_MACHO
-  return output_call(insn, operands, 1, 3);
-#else
-  

Re: [PATCH] Fix PR64242

[Jeff Law]

On 12/3/18 9:25 AM, Jakub Jelinek wrote:
> Hi!
> 
> Here is a fix for the testcase, so that it doesn't FAIL pretty much
> everywhere.
> 
> On Fri, Nov 30, 2018 at 04:07:31PM -0700, Jeff Law wrote:
>>> PR middle-end/64242
>>> * gcc.c-torture/execute/pr64242.c: New test.
>> THanks for tracking this down.  I'd like to have this run through my
>> next testing cycle, so I went ahead and installed  it for you.
> 
> What I've tested:
> 1) x86_64-linux {-m32,-m64} - without the testcase patch, the testcase FAILs
>without or with the builtins.c change; with the testcase patch and
>witout the builtins.c change, there is
> FAIL: gcc.c-torture/execute/pr64242.c   -O2  execution test
> FAIL: gcc.c-torture/execute/pr64242.c   -O3 -g  execution test
> FAIL: gcc.c-torture/execute/pr64242.c   -Os  execution test
>for -m32 and no FAILs for -m64, with the builtins.c change the tests
>passes on both -m32 and -m64
> 2) powerpc64-linux {-m32,-m64} - without the testcase patch, the testcase
>FAILs without and with the builtins.c change for -m32.  With the testcase
>patch and without the builtins.c change, there is
> FAIL: gcc.c-torture/execute/pr64242.c   -O0  execution test
> FAIL: gcc.c-torture/execute/pr64242.c   -O1  execution test
> FAIL: gcc.c-torture/execute/pr64242.c   -O2  execution test
> FAIL: gcc.c-torture/execute/pr64242.c   -O3 -g  execution test
> FAIL: gcc.c-torture/execute/pr64242.c   -Os  execution test
>for -m32 and
> FAIL: gcc.c-torture/execute/pr64242.c   -O0  execution test
> FAIL: gcc.c-torture/execute/pr64242.c   -O1  execution test
>for -m64, with the builtins.c change everything passes
> 3) aarch64-linux - both without and with the testcase patch, the
>testcase FAILs without the builtins.c change and passes with it
> 
> Ok for trunk?
> 
> 2018-12-03  Jakub Jelinek  
> 
>   PR middle-end/64242
>   * gcc.c-torture/execute/pr64242.c (foo, bar): New functions.
>   (p): Make it void *volatile instead of volatile void *.
>   (q): New variable.
>   (main): Add a dummy 32-byte aligned variable and escape its address.
>   Don't require that the two __builtin_alloca (0) calls return the
>   same address, just require that their difference is smaller than
>   1024 bytes.
Yea,  my tester fell over the new test on multiple targets.  THanks for
fixing it up.

OK
jeff

Re: RFA/RFC: Add stack recursion limit to libiberty's demangler [v3]

[Ian Lance Taylor via gcc-patches]

On Mon, Dec 3, 2018 at 6:45 AM, Nick Clifton  wrote:
> Hi Richard,
>
>>>   * The description of the DMGL_RECURSE_LIMIT option in demangle.h has
>>> been enhanced to add a note that if the option is not used, then
>>> bug reports about stack overflows in the demangler will be rejected.
>>
>> Shouldn't we make it fool-proof by instead introducing a 
>> DMGL_NO_RECURSION_LIMIT
>> flag and when not set default to limiting recursion?
>
> Well I wanted the patch to be backwards compatible. Just on the
> general principle of not surprising users/programmers by changing
> things without telling them first.
>
> I could change this of course, but I would rather have Ian's blessing
> first.

You don't need my blessing--I wrote that code ages ago--but I agree
with Richard that in practice it's OK to limit recursion depth by
default.  Real symbols have very limited recursion requirements.

Ian

Re: [doc, rfc] document __builtin_setjmp and __builtin_longjmp

[Jeff Law]

On 11/30/18 9:57 PM, Sandra Loosemore wrote:
> I have written a new patch for PR 59039 to address more of the comments
> there, as well as my own complaints about the draft patch attached to
> the issue.  I'd like to get some feedback on this one before I commit it.
It looks pretty good to me.  It contains the most important info,
specifically that the builtin setjmp/longjmp are really for internal
purposes.

jeff

Re: PR fortran/87919 patch for -fno-dec-structure

[Fritz Reese]

On Mon, Dec 3, 2018 at 12:12 PM Jakub Jelinek  wrote:
>
> On Mon, Dec 03, 2018 at 04:58:51PM +0100, Jakub Jelinek wrote:
> > > but I just committed r266745 adjusted for -fdec-include.
> >
> > Thanks, though it seems what you've committed in options.c is incomplete.
> > In the patch you've posted earlier, you've changed also
> > gfc_init_options and gfc_handle_option, to call the new functions
> > (set_init_local_zero, post_dec_options) and use SET_FLAG and undefine it at
> > the end.
> > None of those changes appears in
> > https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/fortran/options.c?limit_changes=0=266745=266744=266745
> > all changes stop at the newly added set_init_local_zero, so
> > set_init_local_zero and post_dec_options are now unused functions.
>
> I've committed the remaining options.c changes in r266761 now
> to unbreak the FAILs.
>
> Jakub

Thanks, and sorry...

[committed] Minor H8 warning bugfix

[Jeff Law]

I've been seeing the "... reaches end of non-void function ..." warning
during my h8 test builds.  I wanted to make sure it wasn't a real issue
and it isn't.  Having done the RCA, the fix is trivial, so we might as
well go ahead and fix it :-)

This just adds a suitable gcc_unreachable to the problematic pattern.

Committing to the trunk momentarily.

Jeff
commit 065ec66a719f19bb9fffd951bd2d433fc33e18b7
Author: Jeff Law 
Date:   Mon Dec 3 10:09:57 2018 -0700

* config/h8300/h8300.md (qi3_1): Add gcc_unreachable to keep
warnings quiet.

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index be0aab2c876..36906e314b7 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,5 +1,8 @@
 2018-12-03  Jeff Law  
 
+   * config/h8300/h8300.md (qi3_1): Add gcc_unreachable to keep
+   warnings quiet.
+
* config/h8300/h8300.md (low byte masking peepholes): Only accept
nonimmediate_operand for the to-be-masked operand.
 
diff --git a/gcc/config/h8300/h8300.md b/gcc/config/h8300/h8300.md
index 9e8f7159846..84b2e4f2bf9 100644
--- a/gcc/config/h8300/h8300.md
+++ b/gcc/config/h8300/h8300.md
@@ -1629,6 +1629,7 @@
   return  == IOR ? "bset\\t%V2,%R0" : "bnot\\t%V2,%R0"; 
 else if (which_alternative == 1)
   return  == IOR ? "or\\t%X2,%X0" : "xor\\t%X2,%X0";
+gcc_unreachable ();
   }
   [(set_attr "length" "8,*")
(set_attr "length_table" "*,logicb")

Re: PR fortran/87919 patch for -fno-dec-structure

[Jakub Jelinek]

On Mon, Dec 03, 2018 at 04:58:51PM +0100, Jakub Jelinek wrote:
> > but I just committed r266745 adjusted for -fdec-include.
> 
> Thanks, though it seems what you've committed in options.c is incomplete.
> In the patch you've posted earlier, you've changed also
> gfc_init_options and gfc_handle_option, to call the new functions
> (set_init_local_zero, post_dec_options) and use SET_FLAG and undefine it at
> the end.
> None of those changes appears in
> https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/fortran/options.c?limit_changes=0=266745=266744=266745
> all changes stop at the newly added set_init_local_zero, so
> set_init_local_zero and post_dec_options are now unused functions.

I've committed the remaining options.c changes in r266761 now
to unbreak the FAILs.

Jakub

Re: [PATCH] OpenACC 2.6 manual deep copy support (attach/detach)

[Julian Brown]

On Fri, 30 Nov 2018 03:41:09 -0800
Julian Brown  wrote:

> This is a new version of the patch incorporating
> several improvements/bugfixes made on the og8 branch:

I released I forgot (again!) to incorporate the changes suggested by
Bernhard in:

https://gcc.gnu.org/ml/gcc-patches/2018-11/msg00861.html

I've folded those into my copy of the local patch now, but I'll hold
off resubmitting until the rest of the patch is reviewed.

Thanks,

Julian

Re: [PATCH v3] Make function clone name numbering independent.

[Michael Ploujnikov]

On 2018-12-01 11:29 a.m., H.J. Lu wrote:
> This caused:
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88297
> 

Sorry about that. Looks like I should have been testing with
--with-build-config=bootstrap-lto rather than just --enable-bootstrap.

The quick fix would be to undo the patch to create_virtual_clone or to
just change clone_num_suffixes to key off of DECL_ASSEMBLER_NAME
(node->decl) instead of node pointers. Any preferences?

The harder fix would be to figure out why some nodes share the same
names and fix that, but maybe that's just inevitable with LTO?

- Michael



signature.asc
Description: OpenPGP digital signature

[PATCH, og8] Add OpenACC 2.6 `acc_get_property' support

[Maciej W. Rozycki]

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 a minimal handler for the HSA 
offload target.

Include test cases for both C/C++ and Fortran support, both producing:

OpenACC vendor: GNU
OpenACC name: GOMP
OpenACC driver: 1.0

with the host driver and output like:

OpenACC vendor: Nvidia
OpenACC total memory: 12651462656
OpenACC free memory: 12202737664
OpenACC name: TITAN V
OpenACC driver: 9.1

with the NVPTX driver.

include/
* gomp-constants.h (GOMP_DEVICE_CURRENT): New macro.
(GOMP_DEVICE_PROPERTY_MEMORY, GOMP_DEVICE_PROPERTY_FREE_MEMORY)
(GOMP_DEVICE_PROPERTY_NAME, GOMP_DEVICE_PROPERTY_VENDOR)
(GOMP_DEVICE_PROPERTY_DRIVER): Likewise.
(GOMP_DEVICE_PROPERTY_STRING_MASK): Likewise.

libgomp/
* libgomp.h (gomp_device_descr): Add `get_property_func' member.
* libgomp-plugin.h (gomp_device_property_value): New union.
(gomp_device_property_value): New prototype.
* openacc.h (acc_device_t): Add `acc_device_current' enumeration
constant.
(acc_device_property_t): New enum.
(acc_get_property, acc_get_property_string): New prototypes.
* oacc-init.c (acc_get_device_type): Also assert on
`!acc_device_current' result.
(get_property_any, acc_get_property, acc_get_property_string): 
New functions.
* openacc.f90 (openacc_kinds): From `iso_fortran_env' also 
import `int64'.  Add `acc_device_current' and 
`acc_property_memory', `acc_property_free_memory', 
`acc_property_name', `acc_property_vendor' and
`acc_property_driver' constants.  Add `acc_device_property' data
type.
(openacc_internal): Add `acc_get_property' and 
`acc_get_property_string' interfaces.  Add `acc_get_property_h',
`acc_get_property_string_h', `acc_get_property_l' and 
`acc_get_property_string_l'.
(openacc_c_string): New module.
* oacc-host.c (host_get_property): New function.
(host_dispatch): Wire it.
* target.c (gomp_load_plugin_for_device): Handle `get_property'.
* libgomp.map (OACC_2.6): Add `acc_get_property', 
`acc_get_property_h_', `acc_get_property_string' and 
`acc_get_property_string_h_' symbols.
* libgomp.texi (OpenACC Runtime Library Routines): Add 
`acc_get_property'.
(acc_get_property): New node.

* plugin/plugin-hsa.c (GOMP_OFFLOAD_get_property): New function.
* plugin/plugin-nvptx.c (CUDA_CALLS): Add `cuDeviceGetName', 
`cuDeviceTotalMem', `cuDriverGetVersion' and `cuMemGetInfo' 
calls.
(GOMP_OFFLOAD_get_property): New function.

* testsuite/libgomp.oacc-c-c++-common/acc-get-property.c: New 
test.
* testsuite/libgomp.oacc-fortran/acc-get-property.f: New test.
---
Hi,

 This has passed regression-testing with the `x86_64-linux-gnu' target and 
the `nvptx-none' offload target.  I will appreciate feedback and if none 
has been given in a couple of days' time, then I will commit this change 
to the og8 branch.

  Maciej
---
 include/gomp-constants.h   |   14 +
 libgomp/libgomp-plugin.h   |8 
 libgomp/libgomp.h  |1 
 libgomp/libgomp.map|4 
 libgomp/libgomp.texi   |   39 +++
 libgomp/oacc-host.c|   22 +
 libgomp/oacc-init.c|   99 
 libgomp/openacc.f90|  116 
+-
 libgomp/openacc.h  |   15 +
 libgomp/plugin/plugin-hsa.c|   26 ++
 libgomp/plugin/plugin-nvptx.c  |   91 +++
 libgomp/target.c   |1 
 libgomp/testsuite/libgomp.oacc-c-c++-common/acc-get-property.c |   37 +++
 libgomp/testsuite/libgomp.oacc-fortran/acc-get-property.f  |   33 ++
 14 files changed, 504 insertions(+), 2 deletions(-)

gcc-openacc-acc-get-property.diff
Index: gcc-openacc-gcc-8-branch/include/gomp-constants.h
===
--- gcc-openacc-gcc-8-branch.orig/include/gomp-constants.h
+++ gcc-openacc-gcc-8-branch/include/gomp-constants.h
@@ -215,10 +215,24 @@ enum gomp_map_kind
 #define GOMP_DEVICE_NVIDIA_PTX 5
 #define GOMP_DEVICE_INTEL_MIC  6
 #define GOMP_DEVICE_HSA7
+#define GOMP_DEVICE_CURRENT8
 
 #define GOMP_DEVICE_ICV-1
 #define GOMP_DEVICE_HOST_FALLBACK  -2
 
+/* Device property codes.  Keep in sync with
+   

Re: [wwwdocs] Add D language to news, frontends, release notes, and readings.

[Iain Buclaw]

On Sun, 2 Dec 2018 at 22:34, Gerald Pfeifer  wrote:
>
> On Sun, 2 Dec 2018, Iain Buclaw wrote:
> > I assume that the notes on the about.html page are all that are
> > needed to commit and push?
>
> Yes, they *should*.
>
> If you run into anything that's missing or have any questions,
> just let me know and I'll (a) help directly and (b) see how to
> improve the docs.
>

No worries, this is just a "never used cvs before" question.  So beg
my pardon if I approach it with extreme caution.

-- 
Iain

Re: [RFC][AArch64] Add support for system register based stack protector canary access

[Ard Biesheuvel]

On Mon, 3 Dec 2018 at 10:55, Ramana Radhakrishnan
 wrote:
>
> For quite sometime the kernel guys, (more specifically Ard) have been
> talking about using a system register (sp_el0) and an offset from that
> for a canary based access. This patchset adds support for a new set of
> command line options similar to how powerpc has done this.
>
> I don't intend to change the defaults in userland, we've discussed this
> for user-land in the past and as far as glibc and userland is concerned
> we stick to the options as currently existing. The system register
> option is really for the kernel to use along with an offset as they
> control their ABI and this is a decision for them to make.
>
> I did consider sticking this all under a mcmodel=kernel-small option but
> thought that would be a bit too aggressive. There is very little error
> checking I can do in terms of the system register being used and really
> the assembler would barf quite quickly in case things go wrong. I've
> managed to rebuild Ard's kernel tree with an additional patch that
> I will send to him. I haven't managed to boot this kernel.
>
> There was an additional question asked about the performance
> characteristics of this but it's a security feature and the kernel
> doesn't have the luxury of a hidden symbol. Further since the kernel
> uses sp_el0 for access everywhere and if they choose to use the same
> register I don't think the performance characteristics would be too bad,
> but that's a decision for the kernel folks to make when taking in the
> feature into the kernel.
>
> I still need to add some tests and documentation in invoke.texi but
> this is at the stage where it would be nice for some other folks
> to look at this.
>
> The difference in code generated is as below.
>
> extern void bar (char *);
> int foo (void)
> {
>char a[100];
>bar ();
> }
>
> $GCC -O2  -fstack-protector-strong  vs
> -mstack-protector-guard-reg=sp_el0 -mstack-protector-guard=sysreg
> -mstack-protector-guard-offset=1024 -fstack-protector-strong
>
>
> --- tst.s   2018-12-03 09:46:21.174167443 +
> +++ tst.s.1 2018-12-03 09:46:03.546257203 +
> @@ -15,15 +15,14 @@
> mov x29, sp
> str x19, [sp, 16]
> .cfi_offset 19, -128
> -   adrpx19, __stack_chk_guard
> -   add x19, x19, :lo12:__stack_chk_guard
> -   ldr x0, [x19]
> -   str x0, [sp, 136]
> -   mov x0,0
> +   mrs x19, sp_el0
> add x0, sp, 32
> +   ldr x1, [x19, 1024]
> +   str x1, [sp, 136]
> +   mov x1,0
> bl  bar
> ldr x0, [sp, 136]
> -   ldr x1, [x19]
> +   ldr x1, [x19, 1024]
> eor x1, x0, x1
> cbnzx1, .L5
>
>
>
>
> I will be afk tomorrow and day after but this is to elicit some comments
> and for Ard to try this out with his kernel patches.
>

Thanks Ramana. I managed to build and run a complete kernel (including
modules) on a bare metal system, and everything works as expected.

The only thing I'd like to confirm with you is the logic wrt the
command line arguments, more specifically, if/when all 3 arguments
have to appear, and whether they are permitted to appear if
-fstack-protector is not set.

This is relevant given that we invoke the compiler in 3 different ways:
- at the configure stage, we invoke the compiler with some/all of
these options to decide whether the feature is supported, but the
actual offset is not known, but also irrelevant
- we invoke the compiler to build the header file that actually gives
us the offset to pass to later invocations
- finally, all kernel objects are built with all 3 arguments passed on
the command line

It looks like your code permits -mstack-protector-guard-reg at any
time, but only permits -mstack-protector-guard-offset if
-mstack-protector-guard is set to sysreg (and thus set explicitly,
since the default is global). Is that intentional? Can we expect this
to remain like that?

Re: [PATCH] Fix PR64242

[Jakub Jelinek]

Hi!

Here is a fix for the testcase, so that it doesn't FAIL pretty much
everywhere.

On Fri, Nov 30, 2018 at 04:07:31PM -0700, Jeff Law wrote:
> > PR middle-end/64242
> > * gcc.c-torture/execute/pr64242.c: New test.
> THanks for tracking this down.  I'd like to have this run through my
> next testing cycle, so I went ahead and installed  it for you.

What I've tested:
1) x86_64-linux {-m32,-m64} - without the testcase patch, the testcase FAILs
   without or with the builtins.c change; with the testcase patch and
   witout the builtins.c change, there is
FAIL: gcc.c-torture/execute/pr64242.c   -O2  execution test
FAIL: gcc.c-torture/execute/pr64242.c   -O3 -g  execution test
FAIL: gcc.c-torture/execute/pr64242.c   -Os  execution test
   for -m32 and no FAILs for -m64, with the builtins.c change the tests
   passes on both -m32 and -m64
2) powerpc64-linux {-m32,-m64} - without the testcase patch, the testcase
   FAILs without and with the builtins.c change for -m32.  With the testcase
   patch and without the builtins.c change, there is
FAIL: gcc.c-torture/execute/pr64242.c   -O0  execution test
FAIL: gcc.c-torture/execute/pr64242.c   -O1  execution test
FAIL: gcc.c-torture/execute/pr64242.c   -O2  execution test
FAIL: gcc.c-torture/execute/pr64242.c   -O3 -g  execution test
FAIL: gcc.c-torture/execute/pr64242.c   -Os  execution test
   for -m32 and
FAIL: gcc.c-torture/execute/pr64242.c   -O0  execution test
FAIL: gcc.c-torture/execute/pr64242.c   -O1  execution test
   for -m64, with the builtins.c change everything passes
3) aarch64-linux - both without and with the testcase patch, the
   testcase FAILs without the builtins.c change and passes with it

Ok for trunk?

2018-12-03  Jakub Jelinek  

PR middle-end/64242
* gcc.c-torture/execute/pr64242.c (foo, bar): New functions.
(p): Make it void *volatile instead of volatile void *.
(q): New variable.
(main): Add a dummy 32-byte aligned variable and escape its address.
Don't require that the two __builtin_alloca (0) calls return the
same address, just require that their difference is smaller than
1024 bytes.

--- gcc/testsuite/gcc.c-torture/execute/pr64242.c.jj2018-12-01 
00:25:08.082009500 +0100
+++ gcc/testsuite/gcc.c-torture/execute/pr64242.c   2018-12-03 
16:51:51.869797742 +0100
@@ -3,7 +3,7 @@
 extern void abort (void);
 
 __attribute ((noinline)) void
-broken_longjmp(void *p)
+broken_longjmp (void *p)
 {
   void *buf[5];
   __builtin_memcpy (buf, p, 5 * sizeof (void*));
@@ -11,20 +11,41 @@ broken_longjmp(void *p)
   __builtin_longjmp (buf, 1);
 }
 
+__attribute ((noipa)) __UINTPTR_TYPE__
+foo (void *p)
+{
+  return (__UINTPTR_TYPE__) p;
+}
+
+__attribute ((noipa)) void
+bar (void *p)
+{
+  asm volatile ("" : : "r" (p));
+}
+
 volatile int x = 0;
-volatile void *p;
+void *volatile p;
+void *volatile q;
+
 int
-main (void)
+main ()
 {
   void *buf[5];
+  struct __attribute__((aligned (32))) S { int a[4]; } s;
+  bar ();
   p = __builtin_alloca (x);
-
   if (!__builtin_setjmp (buf))
 broken_longjmp (buf);
 
   /* Fails if stack pointer corrupted.  */
-  if (p != __builtin_alloca (x))
-abort();
+  q = __builtin_alloca (x);
+  if (foo (p) < foo (q))
+{
+  if (foo (q) - foo (p) >= 1024)
+   abort ();
+}
+  else if (foo (p) - foo (q) >= 1024)
+abort ();
 
   return 0;
 }

Jakub

Re: [committed] C++ PATCH to add test for c++/83856

[Marek Polacek]

On Mon, Dec 03, 2018 at 10:14:11AM +0100, Christophe Lyon wrote:
> This new test fails on arm and other targets according to
> gcc-testresults. On arm, I can see:
> /gcc/testsuite/g++.dg/cpp1y/lambda-generic-83856.C:6:27: fatal error:
> definition of 'class std::initializer_list<_E>' does not match
> '#include '
> compilation terminated.
> compiler exited with status 1
> FAIL: g++.dg/cpp1y/lambda-generic-83856.C  -std=c++14 (test for excess errors)

Ah, again.  Sorry about that, I'm fixing it with this.

2018-12-03  Marek Polacek  

* g++.dg/cpp1y/lambda-generic-83856.C: Use __SIZE_TYPE__.

diff --git gcc/testsuite/g++.dg/cpp1y/lambda-generic-83856.C 
gcc/testsuite/g++.dg/cpp1y/lambda-generic-83856.C
index ab82b6241aa..e1f139406ca 100644
--- gcc/testsuite/g++.dg/cpp1y/lambda-generic-83856.C
+++ gcc/testsuite/g++.dg/cpp1y/lambda-generic-83856.C
@@ -7,7 +7,7 @@ template  class initializer_list {
   _E *_M_len;
 
 public:
-  unsigned long size;
+  __SIZE_TYPE__ size;
   _E begin();
 };
 template  struct array { void operator[](long); };

Re: [committed] Clean up Fortran OpenACC wait clause handling

[Julian Brown]

On Fri, 30 Nov 2018 21:48:20 +0100
Thomas Schwinge  wrote:

> Hi!
> 
> commit 3e3de40a5ab21d72f08071a7a40120dd05608cc1
> Author: tschwinge 
> Date:   Fri Nov 30 20:39:18 2018 +
> 
> Clean up Fortran OpenACC wait clause handling
> 
> "wait" can be deduced from "wait_list".
> 
> gcc/fortran/
> * gfortran.h (struct gfc_omp_clauses): Remove "wait".
> Adjust all users.

This appears to conflict with Chung-Lin's uncommitted patch ("Properly
handle wait clause with no arguments"):

https://gcc.gnu.org/ml/gcc-patches/2018-08/msg01973.html

I'm not sure if such waits have a "wait_list" or not -- I guess not
though? If so this patch might need to be reverted.

Thanks,

Julian

Re: PR fortran/87919 patch for -fno-dec-structure

[Jakub Jelinek]

On Mon, Dec 03, 2018 at 10:52:18AM -0500, Fritz Reese wrote:
> > I think more than enough time passed, do you plan to commit to trunk now?
> > Note, small adjustment will be needed for the addition of flag_dec_include
> > in set_dec_flags.
> 
> Jakub- Sorry, yes. I've had other priorities the past few weeks here,

Np.

> but I just committed r266745 adjusted for -fdec-include.

Thanks, though it seems what you've committed in options.c is incomplete.
In the patch you've posted earlier, you've changed also
gfc_init_options and gfc_handle_option, to call the new functions
(set_init_local_zero, post_dec_options) and use SET_FLAG and undefine it at
the end.
None of those changes appears in
https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/fortran/options.c?limit_changes=0=266745=266744=266745
all changes stop at the newly added set_init_local_zero, so
set_init_local_zero and post_dec_options are now unused functions.

Jakub

[Ada] Spurious error on dependent expression that is an array

[Pierre-Marie de Rodat]

This patch fixes a spurious error on a array expression that is a
dependent expression of an if-expression, when the length of the array
matches that imposed by the context, but the bounds of both differ, in
particular when the expression and the context are both null arrays with
different bounds.

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

2018-12-03  Ed Schonberg  

gcc/ada/

* sem_res.adb (Apply_Check): For array types, apply a length
check rather than a qualification, to avoid spurious errors when
the value of a dependend expression has a matching length but
different bounds from those of the type of the contect.

gcc/testsuite/

* gnat.dg/array33.adb: New testcase.--- gcc/ada/sem_res.adb
+++ gcc/ada/sem_res.adb
@@ -8461,7 +8461,9 @@ package body Sem_Res is
   --  When a dependent expression is of a subtype different from
   --  the context subtype, then insert a qualification to ensure
   --  the generation of a constraint check. This was previously
-  --  done only for scalar types.
+  --  for scalar types. For array types apply a length check, given
+  --  that the context in general allows sliding, while a qualified
+  --  expression forces equality of bounds.
 
   -
   -- Apply_Check --
@@ -8472,12 +8474,18 @@ package body Sem_Res is
  Loc  : constant Source_Ptr := Sloc (Expr);
 
   begin
- if Expr_Typ /= Typ
-   and then not Is_Tagged_Type (Typ)
-   and then not Is_Access_Type (Typ)
-   and then Is_Constrained (Typ)
-   and then not Inside_A_Generic
+ if Expr_Typ = Typ
+   or else Is_Tagged_Type (Typ)
+   or else Is_Access_Type (Typ)
+   or else not Is_Constrained (Typ)
+   or else Inside_A_Generic
  then
+null;
+
+ elsif Is_Array_Type (Typ) then
+Apply_Length_Check (Expr, Typ);
+
+ else
 Rewrite (Expr,
   Make_Qualified_Expression (Loc,
 Subtype_Mark => New_Occurrence_Of (Typ, Loc),

--- /dev/null
new file mode 100644
+++ gcc/testsuite/gnat.dg/array33.adb
@@ -0,0 +1,85 @@
+--  { dg-do run }
+
+procedure Array33 is
+  generic
+type Item_T is private; -- The type of which the interval is made of.
+type Bound_T is private;
+None_Bound : Bound_T;
+Bounds_Are_Static : Boolean := False;
+type Value_T is private;
+type Base_Index_T is range <>;
+  package General_Interval_Partition_G is
+subtype Length_T is Base_Index_T range 0 .. Base_Index_T'Last;
+subtype Index_T  is Base_Index_T range 1 .. Base_Index_T'Last;
+type T is private;
+function Single (First, Last : Bound_T; Value : Value_T) return T;
+function Single1 (First, Last : Bound_T; Value : Value_T) return T;
+  private
+type Bounds_Array_T is array (Length_T range <>) of Bound_T;
+type Values_Array_T is array (Index_T  range <>) of Value_T;
+
+First_Bounds_Index : constant Length_T
+:= 2 * Boolean'Pos (Bounds_Are_Static);
+-- See below explanation on indexing the bounds.
+
+
+type Obj_T (Length : Length_T) is
+  record
+Bounds : Bounds_Array_T (First_Bounds_Index .. Length)
+   := (others => None_Bound);
+-- This is tricky. If Bounds_Are_Static is true, the array does not
+--  store the lower or upper bound.
+-- This lowers memory requirements for the data structure at the cost
+--  of slightly more complex indexing.
+--
+-- Bounds as seen internally depending on the parameter:
+--
+-- Bounds_Are_Static | Lower_Bound | Inbetween Bounds (if any) | Upper_Bound
+-- True => Max_First   & Bounds (2 .. Length)  & Min_Last
+-- False=> Bounds (0)  & Bounds (1 .. Length - 1)  & Bounds (Length)
+--
+Values : Values_Array_T (1 .. Length);
+  end record;
+
+type T is access Obj_T;
+--@@ if ccf:defined(debug_pool) then
+--@@! for T'Storage_Pool use Pool_Selection_T'Storage_Pool;
+--@@ end if
+
+  end General_Interval_Partition_G;
+
+  package body General_Interval_Partition_G is
+
+function Single (First, Last : Bound_T; Value : Value_T) return T is
+begin
+  return new Obj_T'(Length => 1,
+Bounds => (if Bounds_Are_Static
+   then (2 .. 0 => None_Bound) 
+--  Now raises constraint error here
+   else (0 => First, 1 => Last)),
+Values => (1 => Value));
+end Single;
+function Single1 (First, Last : Bound_T; Value : Value_T) return T is
+begin
+  return new Obj_T'( 1,
+ (if Bounds_Are_Static
+   then (2 .. 0 => None_Bound) 
+--  Now raises constraint error here
+   else (0 => First, 1 => 

[Ada] Fixes for various wrong and missing error messages on ACATS B85100[567]

[Pierre-Marie de Rodat]

GNAT was missing errors as well as issuing messages on legal lines in
new ACATS tests for illegal renamings of discriminant-dependent
components. Cases that are fixed include object names involving
qualified expressions, dereference cases, and generic formal access and
formal derived types. Better implements the "known to be constrained"
rules in the Ada RM.

Tested by new ACATS tests B85100[567] that are soon to be released.

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

2018-12-03  Gary Dismukes  

gcc/ada/

* sem_aux.adb (Object_Type_Has_Constrained_Partial_View): Return
True for an untagged discriminated formal derived type when
referenced within a generic body (augments existing test for
formal private types).
* sem_util.adb (Is_Dependent_Component_Of_Mutable_Type): If the
prefix of the name is a qualified expression, retrieve the
operand of that. Add a test of whether the (possible)
dereference prefix is a variable, and also test whether that
prefix might just be of an access type (occurs in some implicit
dereference cases) rather than being an explicit dereference.
Retrieve the Original_Node of the object name's main prefix and
handle the possibility of that being a qualified expression.
Remove special-case code for explicit dereferences that don't
come from source. Add test for the renaming not being within a
generic body for proper determination of whether a formal access
type is known to be constrained (it is within a generic spec,
but not in the body).  Fix an existing incorrect test for
renaming of a discriminant-dependent component of a untagged
generic formal type being within a generic body, adding test of
taggedness and calling In_Generic_Body (now properly checks for
cases where the renaming is in a nongeneric body nested within a
generic).  Return False in cases where the selector is not a
component (or discriminant), which can occur for
prefixed-notation calls.--- gcc/ada/sem_aux.adb
+++ gcc/ada/sem_aux.adb
@@ -1472,7 +1472,8 @@ package body Sem_Aux is
   return Has_Constrained_Partial_View (Typ)
 or else (In_Generic_Body (Scop)
   and then Is_Generic_Type (Base_Type (Typ))
-  and then Is_Private_Type (Base_Type (Typ))
+  and then (Is_Private_Type (Base_Type (Typ))
+ or else Is_Derived_Type (Base_Type (Typ)))
   and then not Is_Tagged_Type (Typ)
   and then not (Is_Array_Type (Typ)
  and then not Is_Constrained (Typ))

--- gcc/ada/sem_util.adb
+++ gcc/ada/sem_util.adb
@@ -14123,6 +14123,15 @@ package body Sem_Util is
  Deref := Prefix (Deref);
   end loop;
 
+  --  If the prefix is a qualified expression of a variable, then function
+  --  Is_Variable will return False for that because a qualified expression
+  --  denotes a constant view, so we need to get the name being qualified
+  --  so we can test below whether that's a variable (or a dereference).
+
+  if Nkind (Deref) = N_Qualified_Expression then
+ Deref := Expression (Deref);
+  end if;
+
   --  Ada 2005: If we have a component or slice of a dereference,
   --  something like X.all.Y (2), and the type of X is access-to-constant,
   --  Is_Variable will return False, because it is indeed a constant
@@ -14130,13 +14139,42 @@ package body Sem_Util is
   --  following condition to be True in that case.
 
   if Is_Variable (Object)
+or else Is_Variable (Deref)
 or else (Ada_Version >= Ada_2005
-  and then Nkind (Deref) = N_Explicit_Dereference)
+  and then (Nkind (Deref) = N_Explicit_Dereference
+ or else Is_Access_Type (Etype (Deref
   then
  if Nkind (Object) = N_Selected_Component then
-P := Prefix (Object);
+
+--  If the selector is not a component, then we definitely return
+--  False (it could be a function selector in a prefix form call
+--  occurring in an iterator specification).
+
+if not
+  Ekind_In
+(Entity (Selector_Name (Object)), E_Component, E_Discriminant)
+then
+   return False;
+end if;
+
+--  Get the original node of the prefix in case it has been
+--  rewritten, which can occur, for example, in qualified
+--  expression cases. Also, a discriminant check on a selected
+--  component may be expanded into a dereference when removing
+--  side effects, and the subtype of the original node may be
+--  unconstrained.
+
+P := Original_Node (Prefix (Object));
 Prefix_Type := Etype (P);
 
+--  If 

[Ada] Fix recent regression on array aggregate with dynamic subtype

[Pierre-Marie de Rodat]

This prevents either a crash or an assertion failure in gigi on an array
with dynamic subtype that is wrongly flagged as static by the front-end
because of a recent improvement made in the handling of nested
aggregates.

The patch reuses the existing Static_Array_Aggregate predicate instead
of fixing the problematic test, pluging a few loopholes in the process.
The predicate is conservatively correct but should be good enough in
practice.

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

2018-12-03  Eric Botcazou  

gcc/ada/

* exp_aggr.adb (Convert_To_Positional): Use
Static_Array_Aggregate to decide whether to set
Compile_Time_Known_Aggregate on an already flat aggregate.
(Expand_Array_Aggregate): Remove test on
Compile_Time_Known_Aggregate that turns out to be dead and
simplify.
(Is_Static_Component): New predicate extracted from...
(Static_Array_Aggregate): ...here.  Test neither Is_Tagged_Type
nor Is_Controlled for the type, but test whether the component
type has discriminants.  Use the Is_Static_Component predicate
consistently for the positional and named cases.

gcc/testsuite/

* gnat.dg/array32.adb, gnat.dg/array32.ads: New testcase.--- gcc/ada/exp_aggr.adb
+++ gcc/ada/exp_aggr.adb
@@ -4759,17 +4759,8 @@ package body Exp_Aggr is
   --  initial value of a thread-local variable.
 
   if Is_Flat (N, Number_Dimensions (Typ)) then
- Check_Static_Components;
- if Static_Components then
-if Is_Packed (Etype (N))
-  or else
-(Is_Record_Type (Component_Type (Etype (N)))
-  and then Has_Discriminants (Component_Type (Etype (N
-then
-   null;
-else
-   Set_Compile_Time_Known_Aggregate (N);
-end if;
+ if Static_Array_Aggregate (N) then
+Set_Compile_Time_Known_Aggregate (N);
  end if;
 
  return;
@@ -6205,15 +6196,8 @@ package body Exp_Aggr is
 or else (Parent_Kind = N_Assignment_Statement
   and then Inside_Init_Proc)
   then
- if Static_Array_Aggregate (N)
-   or else Compile_Time_Known_Aggregate (N)
- then
-Set_Expansion_Delayed (N, False);
-return;
- else
-Set_Expansion_Delayed (N);
-return;
- end if;
+ Set_Expansion_Delayed (N, not Static_Array_Aggregate (N));
+ return;
   end if;
 
   --  STEP 4
@@ -8506,20 +8490,48 @@ package body Exp_Aggr is

 
function Static_Array_Aggregate (N : Node_Id) return Boolean is
+
+  function Is_Static_Component (N : Node_Id) return Boolean;
+  --  Return True if N has a compile-time known value and can be passed as
+  --  is to the back-end without further expansion.
+
+  ---
+  --  Is_Static_Component  --
+  ---
+
+  function Is_Static_Component (N : Node_Id) return Boolean is
+  begin
+ if Nkind_In (N, N_Integer_Literal, N_Real_Literal) then
+return True;
+
+ elsif Is_Entity_Name (N)
+   and then Present (Entity (N))
+   and then Ekind (Entity (N)) = E_Enumeration_Literal
+ then
+return True;
+
+ elsif Nkind (N) = N_Aggregate
+   and then Compile_Time_Known_Aggregate (N)
+ then
+return True;
+
+ else
+return False;
+ end if;
+  end Is_Static_Component;
+
   Bounds : constant Node_Id := Aggregate_Bounds (N);
 
   Typ   : constant Entity_Id := Etype (N);
-  Comp_Type : constant Entity_Id := Component_Type (Typ);
   Agg   : Node_Id;
   Expr  : Node_Id;
   Lo: Node_Id;
   Hi: Node_Id;
 
+   --  Start of processing for Static_Array_Aggregate
+
begin
-  if Is_Tagged_Type (Typ)
-or else Is_Controlled (Typ)
-or else Is_Packed (Typ)
-  then
+  if Is_Packed (Typ) or else Has_Discriminants (Component_Type (Typ)) then
  return False;
   end if;
 
@@ -8533,11 +8545,11 @@ package body Exp_Aggr is
 
  if No (Component_Associations (N)) then
 
---  Verify that all components are static integers
+--  Verify that all components are static
 
 Expr := First (Expressions (N));
 while Present (Expr) loop
-   if Nkind (Expr) /= N_Integer_Literal then
+   if not Is_Static_Component (Expr) then
   return False;
end if;
 
@@ -8567,17 +8579,7 @@ package body Exp_Aggr is
--  component type. We also limit the size of a static aggregate
--  to prevent runaway static expressions.
 
-   if Is_Array_Type (Comp_Type)
- or else Is_Record_Type (Comp_Type)
-   then
-

Re: PR fortran/87919 patch for -fno-dec-structure

[Fritz Reese]

> I think more than enough time passed, do you plan to commit to trunk now?
> Note, small adjustment will be needed for the addition of flag_dec_include
> in set_dec_flags.

Jakub- Sorry, yes. I've had other priorities the past few weeks here,
but I just committed r266745 adjusted for -fdec-include.

> I'm currently using this patch (pending it being committed) and have
> some pending patches that use it.
>
> I can use the old method of setting dec options for the time being and
> PR fortran/87919 will have to be modified accordingly.

Sorry again for the delay. It is committed now, so you may use the
new-style option setting. Thanks in advance for your upcoming patches.

> I note that in gcc/fortran/options the comment preceding
> set_default_std_flags it says:
>
> "Keep in sync with libgfortran/runtime/compile_options.c
> (init_compile_options)."
>
> and in libgfortran/runtime/compile_options.c preceding
> init_compile_options it says:
>
> "Keep in sync with gcc/fortran/options.c (gfc_init_options)."
>
> I think this should have (set_default_std_flags) instead of
> (gfc_init_options) and they are not in sync.

The first comment (above set_default_std_flags) is also present before
gfc_init_options, which is technically the routine that should mirror
init_compile_options. Since set_default_std_flags is a subroutine of
gfc_init_options, it should also sync with the std flags setting in
init_compile_options, so I don't think any of the comments are
incorrect. However the symmetry may be more obvious if the std flags
setting from init_compile_options was in a subroutine (named similarly
to set_default_std_flags), then the comments on the default standard
flags could reference each other.

That being said, it does appear the default standard flags are out of
sync, as you mentioned... Not sure if this is worth a PR but it's
certainly worth fixing. Seems it was introduced when f2015 was renamed
to f2018 in r255761.


Fritz

[Ada] Add leap seconds for 2015 and 2016

[Pierre-Marie de Rodat]

The following patch updates Ada.Calendar and helper utility Xleaps to
include the leap seconds for years 2015 and 2016.

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

2018-12-03  Hristian Kirtchev  

gcc/ada/

* libgnat/a-calend.adb: Update the number of leap seconds. Add
the hard time values for year 2015 and 2016.--- gcc/ada/libgnat/a-calend.adb
+++ gcc/ada/libgnat/a-calend.adb
@@ -38,7 +38,6 @@ with System.OS_Primitives;
 package body Ada.Calendar with
   SPARK_Mode => Off
 is
-
--
-- Implementation Notes --
--
@@ -157,7 +156,7 @@ is
Leap_Support : constant Boolean := (Flag = 1);
--  Flag to controls the usage of leap seconds in all Ada.Calendar routines
 
-   Leap_Seconds_Count : constant Natural := 25;
+   Leap_Seconds_Count : constant Natural := 27;
 
-
-- Local Constants --
@@ -236,7 +235,9 @@ is
   -47651327790,
   -45442079780,
   -44495135770,
-  -43391807760);
+  -43391807760,
+  -42445727750,
+  -41970527740);
 
-
-- "+" --

[Ada] Fix internal error on package instantiation on private type

[Pierre-Marie de Rodat]

This fixes an assertion failure in gigi triggered by the instantiation
of a generic package, in a visible part of another package, done on a
private type whose full view is a type derived from a scalar or an
access type.

The problem is that the front-end creates and inserts two different
freeze nodes in the expanded tree for the partial and the full views of
the private subtype created by the instantiation, which is not correct:
partial and full views of a given (sub)type must point to the same
freeze node, if any.

The patch also adds an assertion checking this property in the front-end
so as to catch the inconsistency higher in the chain.

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

2018-12-03  Eric Botcazou  

gcc/ada/

* freeze.adb (Freeze_Entity): Do not freeze the partial view of
a private subtype if its base type is also private with delayed
freeze before the full type declaration of the base type has
been seen.
* sem_ch7.adb (Preserve_Full_Attributes): Add assertion on
freeze node.

gcc/testsuite/

* gnat.dg/generic_inst2.adb, gnat.dg/generic_inst2.ads,
gnat.dg/generic_inst2_c.ads: New testcase.--- gcc/ada/freeze.adb
+++ gcc/ada/freeze.adb
@@ -6239,13 +6239,34 @@ package body Freeze is
 
goto Leave;
 
---  Case of no full view present. If entity is derived or subtype,
+--  Case of no full view present. If entity is subtype or derived,
 --  it is safe to freeze, correctness depends on the frozen status
 --  of parent. Otherwise it is either premature usage, or a Taft
 --  amendment type, so diagnosis is at the point of use and the
 --  type might be frozen later.
 
-elsif E /= Base_Type (E) or else Is_Derived_Type (E) then
+elsif E /= Base_Type (E) then
+   declare
+  Btyp : constant Entity_Id := Base_Type (E);
+
+   begin
+  --  However, if the base type is itself private and has no
+  --  (underlying) full view either, wait until the full type
+  --  declaration is seen and all the full views are created.
+
+  if Is_Private_Type (Btyp)
+and then No (Full_View (Btyp))
+and then No (Underlying_Full_View (Btyp))
+and then Has_Delayed_Freeze (Btyp)
+and then No (Freeze_Node (Btyp))
+  then
+ Set_Is_Frozen (E, False);
+ Result := No_List;
+ goto Leave;
+  end if;
+   end;
+
+elsif Is_Derived_Type (E) then
null;
 
 else

--- gcc/ada/sem_ch7.adb
+++ gcc/ada/sem_ch7.adb
@@ -2733,6 +2733,15 @@ package body Sem_Ch7 is
 Propagate_Concurrent_Flags (Priv, Base_Type (Full));
  end if;
 
+ --  As explained in Freeze_Entity, private types are required to point
+ --  to the same freeze node as their corresponding full view, if any.
+ --  But we ought not to overwrite a node already inserted in the tree.
+
+ pragma Assert (Serious_Errors_Detected /= 0
+   or else No (Freeze_Node (Priv))
+   or else No (Parent (Freeze_Node (Priv)))
+   or else Freeze_Node (Priv) = Freeze_Node (Full));
+
  Set_Freeze_Node (Priv, Freeze_Node (Full));
 
  --  Propagate Default_Initial_Condition-related attributes from the

--- /dev/null
new file mode 100644
+++ gcc/testsuite/gnat.dg/generic_inst2.adb
@@ -0,0 +1,5 @@
+--  { dg-do compile }
+
+package body Generic_Inst2 is
+   procedure Foo (X : not null access T) is null;
+end;

--- /dev/null
new file mode 100644
+++ gcc/testsuite/gnat.dg/generic_inst2.ads
@@ -0,0 +1,10 @@
+with Generic_Inst2_C;
+
+package Generic_Inst2 is
+   type T is private;
+   procedure Foo (X : not null access T);
+   package CI is new Generic_Inst2_C (T, Foo => Foo);
+private
+   type S is access Integer;
+   type T is new S;
+end;

--- /dev/null
new file mode 100644
+++ gcc/testsuite/gnat.dg/generic_inst2_c.ads
@@ -0,0 +1,5 @@
+generic
+   type T;
+   with procedure Foo (X : not null access T) is null;
+   with procedure Bar (X : not null access T) is null;
+package Generic_Inst2_C is end;

[Ada] A task not executing an entry call consumes an Entry_Call slot

[Pierre-Marie de Rodat]

This patch resolves the issue where the ATC Level of a task's first
Entry_Call slot corresponds to a task not currently making an entry
call. Consequently, the first slot is never used to record an entry
call. To resolve this, the ATC Level of a such a task is now one less
than the first index of the Entry_Call array (and as result, the ATC
level corresponding to a completed task is now two less than the first
index of this array).

To aid the maintainability of code using ATC levels new constants are
introduced to represent key ATC nesting levels and comments are
introduce for the ATC level definitions.

As a result of this change, the GNAT Extended Ravenscar Profile now
works with the full runtime. The restricted runtime had assumed that the
first Entry_Call slot would be the only slot used for entry calls and
would only initialise this slot (and
System.Tasking.Protected_Objects.Single_Entry was coded this way).
However, Extended Ravenscar uses the native implementation of
System.Tasking.Protected_Objects where this assumption doesn't hold
until the implementation of this patch. Aside from enabling an extra
nested level, this is main functional change of this patch.

The following should compile and execute quietly:

gprbuild -q main.adb
./main

-- main.adb

pragma Profile (GNAT_Extended_Ravenscar);
pragma Partition_Elaboration_Policy (Sequential);

with Tasks;
with GNAT.OS_Lib;
with Ada.Synchronous_Task_Control;

procedure Main is
   pragma Priority (30);
begin
   Ada.Synchronous_Task_Control.Suspend_Until_True (Tasks.A_SO);
   Ada.Synchronous_Task_Control.Suspend_Until_True (Tasks.B_SO);

   GNAT.OS_Lib.OS_Exit (0);
end Main;

-- tasks.ads

with Ada.Synchronous_Task_Control;

package Tasks is
   A_SO : Ada.Synchronous_Task_Control.Suspension_Object;
   B_SO : Ada.Synchronous_Task_Control.Suspension_Object;

   task A with Priority => 25;
   task B with Priority => 20;
end Tasks;

--  tasks.adb

with Obj;

package body Tasks is

   task body A is
   begin
  for J in 1 .. 5 loop
 Obj.PO.Wait;
  end loop;
  Ada.Synchronous_Task_Control.Set_True (Tasks.A_SO);
   end A;

   task body B is
   begin
  for J in 1 .. 5 loop
 Obj.PO.Put;
  end loop;
  Ada.Synchronous_Task_Control.Set_True (Tasks.B_SO);
   end B;
end Tasks;

-- obj.ads

package Obj is
   protected type PT is
  pragma Priority (30);
  entry Put;
  entry Wait;
   private
  Wait_Ready : Boolean := False;
  Put_Ready  : Boolean := True;
   end PT;

   PO : PT;
end Obj;

-- obj.adb

package body Obj is
   protected body PT is
  entry Put when Put_Ready is
  begin
 Wait_Ready := True;
 Put_Ready  := False;
  end Put;

  entry Wait when Wait_Ready is
  begin
 Wait_Ready := False;
 Put_Ready  := True;
  end Wait;
   end PT;
end Obj;

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

2018-12-03  Patrick Bernardi  

gcc/ada/

* libgnarl/s-taskin.ads (ATC_Level_Base): Redefine to span from
-1 to Max_ATC_Nesting so that 0 represents no ATC nesting and -1
represented a completed task. To increase readability, new
constants are introduced to represent key ATC nesting levels.
Consequently, Level_No_Pending_Abort replaces
ATC_Level_Infinity.  ATC_Level related definitions now
documented.
(Ada_Task_Control_Block): The default initialization of
components ATC_Nesting_Level and Pending_ATC_Level now use new
ATC_Level_Base constants.  Comments improved
* libgnarl/s-taskin.adb (Initialize): Improve the initialisation
of the first element of the Entry_Calls array to facilitate
better maintenance.
* libgnarl/s-taasde.ads: Update comment.
* libgnarl/s-taasde.adb, libgnarl/s-taenca.adb,
libgnarl/s-tasren.adb, libgnarl/s-tassta.adb,
libgnarl/s-tasuti.ads, libgnarl/s-tasuti.adb: Use new
ATC_Level_Base constants.
* libgnarl/s-tarest.adb (Create_Restricted_Task): Improve the
initialisation of the first element of the task's Entry_Calls
array to facilitate better maintenance.
* libgnarl/s-tasini.ads (Locked_Abort_To_Level): Update
signature to accept ATC_Level_Base.
* libgnarl/s-tasini.adb (Locked_Abort_To_Level): Update
signature to accept ATC_Level_Base.  Use new ATC_Level_Base
constants and only modify the aborting task's Entry_Calls array
if any entry call is happening.
* libgnarl/s-tposen.adb (Protected_Single_Entry_Call): Reference
the first element of the task's Entry_Calls array via 'First
attribute to facilitate better maintenance.--- gcc/ada/libgnarl/s-taasde.adb
+++ gcc/ada/libgnarl/s-taasde.adb
@@ -96,6 +96,7 @@ package body System.Tasking.Async_Delays is
--  for an async. select statement with delay statement as trigger. The
--  effect should be to remove the delay from the timer queue, and exit one

[Ada] Fix problematic overloading of operator in Ada 95 mode

[Pierre-Marie de Rodat]

The change reverts the test deciding whether an initialization procedure
can be inherited from parent to derived type to the original
implementation, which allowed inheriting a null procedure.

This prevents the creation of another null initialization procedure for
the derived type, which in turn can avoid an artificial overloading
which can wreak havoc in the analysis of private declarations of a
package.

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

2018-12-03  Eric Botcazou  

gcc/ada/

* exp_ch3.adb (Build_Record_Init_Proc): Inherit an
initialization procedure if it is present, even if it is null.

gcc/testsuite/

* gnat.dg/overload2.adb, gnat.dg/overload2_p.adb,
gnat.dg/overload2_p.ads, gnat.dg/overload2_q.adb,
gnat.dg/overload2_q.ads: New testcase.--- gcc/ada/exp_ch3.adb
+++ gcc/ada/exp_ch3.adb
@@ -3712,7 +3712,7 @@ package body Exp_Ch3 is
 and then not Is_Unchecked_Union (Rec_Type)
 and then not Has_New_Non_Standard_Rep (Rec_Type)
 and then not Parent_Subtype_Renaming_Discrims
-and then Has_Non_Null_Base_Init_Proc (Etype (Rec_Type))
+and then Present (Base_Init_Proc (Etype (Rec_Type)))
   then
  Copy_TSS (Base_Init_Proc (Etype (Rec_Type)), Rec_Type);
 

--- /dev/null
new file mode 100644
+++ gcc/testsuite/gnat.dg/overload2.adb
@@ -0,0 +1,13 @@
+--  { dg-do compile }
+--  { dg-options "-gnat95" }
+
+with Overload2_P; use Overload2_P;
+with text_io; use text_io;
+procedure overload2 is
+  this, that: t;
+  yes : boolean := this /= that;
+begin
+  if not yes then
+ put_line ("FAILED");
+  end if;
+end;

--- /dev/null
new file mode 100644
+++ gcc/testsuite/gnat.dg/overload2_p.adb
@@ -0,0 +1,6 @@
+--  { dg-options "-gnat95 -gnatws" }
+
+package body overload2_p is
+   function "=" (this, that: t) return boolean is begin return True; end;
+   this, that : t;
+end;

--- /dev/null
new file mode 100644
+++ gcc/testsuite/gnat.dg/overload2_p.ads
@@ -0,0 +1,6 @@
+with overload2_q;
+package overload2_p is
+   type t is new overload2_q.t;
+private
+   function "=" (this, that: t) return boolean;
+end;

--- /dev/null
new file mode 100644
+++ gcc/testsuite/gnat.dg/overload2_q.adb
@@ -0,0 +1,5 @@
+--  { dg-options "-gnat95" }
+
+package body overload2_q is
+  function "=" (this, that: t) return boolean is begin return False; end;
+end;

--- /dev/null
new file mode 100644
+++ gcc/testsuite/gnat.dg/overload2_q.ads
@@ -0,0 +1,4 @@
+package overload2_q is
+  type t is null record;
+  function "=" (this, that: t) return boolean;
+end;

[Ada] Fix assertion failures with -gnatde and -gnatdv

[Pierre-Marie de Rodat]

This fixes a couple of assertion failures when using -gnatde and -gnatdv
on a compiler built with assertions enabled.  No functional changes.

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

2018-12-03  Eric Botcazou  

gcc/ada/

* einfo.adb (Write_Entity_Info): Don't take Scope of Standard
package.
* sem_ch4.adb (Remove_Abstract_Operations): Add missing blank
lines to -gnatdv output.
* sem_type.adb (Write_Overloads): Take Entity of entity names
only.--- gcc/ada/einfo.adb
+++ gcc/ada/einfo.adb
@@ -10032,7 +10032,9 @@ package body Einfo is
   Write_Eol;
   Write_Attribute ("   Type", Etype (Id));
   Write_Eol;
-  Write_Attribute ("   Scope   ", Scope (Id));
+  if Id /= Standard_Standard then
+ Write_Attribute ("   Scope   ", Scope (Id));
+  end if;
   Write_Eol;
 
   case Ekind (Id) is

--- gcc/ada/sem_ch4.adb
+++ gcc/ada/sem_ch4.adb
@@ -7509,7 +7509,7 @@ package body Sem_Ch4 is
begin
   if Is_Overloaded (N) then
  if Debug_Flag_V then
-Write_Str ("Remove_Abstract_Operations: ");
+Write_Line ("Remove_Abstract_Operations: ");
 Write_Overloads (N);
  end if;
 
@@ -7704,7 +7704,7 @@ package body Sem_Ch4 is
  end if;
 
  if Debug_Flag_V then
-Write_Str ("Remove_Abstract_Operations done: ");
+Write_Line ("Remove_Abstract_Operations done: ");
 Write_Overloads (N);
  end if;
   end if;

--- gcc/ada/sem_type.adb
+++ gcc/ada/sem_type.adb
@@ -3608,8 +3608,10 @@ package body Sem_Type is
   Print_Node_Briefly (N);
 
   if not Is_Overloaded (N) then
- Write_Line ("Non-overloaded entity ");
- Write_Entity_Info (Entity (N), " ");
+ if Is_Entity_Name (N) then
+Write_Line ("Non-overloaded entity ");
+Write_Entity_Info (Entity (N), " ");
+ end if;
 
   elsif Nkind (N) not in N_Has_Entity then
  Get_First_Interp (N, I, It);

[Ada] Gigi support for OpenACC pragmas

[Pierre-Marie de Rodat]

Matching front-end bits to support Acc_Kernels, Acc_Parallel,
Acc_Loop and Acc_Data.

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

2018-12-03  Olivier Hainque  

gcc/ada/

* gcc-interface/lang.opt (fopenacc): New option for Ada.
* gcc-interface/misc.c (gnat_handle_option): Handle it.
* gcc-interface/trans.c (struct loop_info_d): Add OMP
attributes.
(Iterate_Acc_Clause_Arg, Acc_gnat_to_gnu): New functions,
helpers for OpenACC pragmas processing in Pragma_to_gnu.
(Acc_Var_to_gnu, Acc_Reduc_Var_to_gnu, Acc_Reduc_to_gnu):
Likewise.
(Acc_Size_Expr_to_gnu, Acc_Size_List_to_gnu): Likewise.
(Pragma_Acc_Data_to_gnu): Likewise.
(Pragma_to_gnu): Handle Pragma_Acc_Loop, Pragma_Acc_Data,
Pragma_Acc_Kernels and Pragma_Acc_Parallel.
(Acc_Loop_to_gnu, Regular_Loop_to_gnu): New functions. Helpers
for ...
(Loop_Statement_to_gnu): Rework to handle OpenACC loops.--- gcc/ada/gcc-interface/lang.opt
+++ gcc/ada/gcc-interface/lang.opt
@@ -100,4 +100,8 @@ fbuiltin-printf
 Ada Undocumented
 Ignored.
 
+fopenacc
+Ada LTO
+; Documented in C but it should be: Enable OpenACC support
+
 ; This comment is to ensure we retain the blank line above.

--- gcc/ada/gcc-interface/misc.c
+++ gcc/ada/gcc-interface/misc.c
@@ -166,6 +166,7 @@ gnat_handle_option (size_t scode, const char *arg, HOST_WIDE_INT value,
   /* These are handled by the front-end.  */
   break;
 
+case OPT_fopenacc:
 case OPT_fshort_enums:
 case OPT_fsigned_char:
 case OPT_funsigned_char:

--- gcc/ada/gcc-interface/trans.c
+++ gcc/ada/gcc-interface/trans.c
@@ -47,6 +47,7 @@
 #include "gimplify.h"
 #include "opts.h"
 #include "common/common-target.h"
+#include "gomp-constants.h"
 #include "stringpool.h"
 #include "attribs.h"
 
@@ -196,6 +197,9 @@ struct GTY(()) loop_info_d {
   tree loop_var;
   tree low_bound;
   tree high_bound;
+  tree omp_loop_clauses;
+  tree omp_construct_clauses;
+  enum tree_code omp_code;
   vec *checks;
   bool artificial;
 };
@@ -1249,6 +1253,226 @@ Identifier_to_gnu (Node_Id gnat_node, tree *gnu_result_type_p)
   return gnu_result;
 }
 
+
+/* If GNAT_EXPR is an N_Identifier, N_Integer_Literal or N_Operator_Symbol,
+   call FN on it.  If GNAT_EXPR is an aggregate, call FN on each of its
+   elements.  In both cases, pass GNU_EXPR and DATA as additional arguments.
+
+   This function is used everywhere OpenAcc pragmas are processed if these
+   pragmas can accept aggregates.  */
+
+static tree
+Iterate_Acc_Clause_Arg (Node_Id gnat_expr, tree gnu_expr,
+			tree (*fn)(Node_Id, tree, void*),
+			void* data)
+{
+  switch (Nkind (gnat_expr))
+{
+case N_Aggregate:
+  if (Present (Expressions (gnat_expr)))
+	{
+	  for (Node_Id gnat_list_expr = First (Expressions (gnat_expr));
+	   Present (gnat_list_expr);
+	   gnat_list_expr = Next (gnat_list_expr))
+	gnu_expr = fn (gnat_list_expr, gnu_expr, data);
+	}
+  else if (Present (Component_Associations (gnat_expr)))
+	{
+	  for (Node_Id gnat_list_expr = First (Component_Associations
+	   (gnat_expr));
+	   Present (gnat_list_expr);
+	   gnat_list_expr = Next (gnat_list_expr))
+	gnu_expr = fn (Expression (gnat_list_expr), gnu_expr, data);
+	}
+  else
+	  gcc_unreachable();
+	break;
+case N_Identifier:
+case N_Integer_Literal:
+case N_Operator_Symbol:
+	gnu_expr = fn (gnat_expr, gnu_expr, data);
+	break;
+default:
+	gcc_unreachable();
+}
+  return gnu_expr;
+}
+
+/* Same as gnat_to_gnu for a GNAT_NODE referenced within an OpenAcc directive,
+   undoing transformations that are inappropriate for such context.  */
+
+tree
+Acc_gnat_to_gnu (Node_Id gnat_node)
+{
+  tree gnu_result = gnat_to_gnu (gnat_node);
+
+/* If gnat_node is an identifier for a boolean, gnat_to_gnu might have
+   turned it into `identifier != 0`.  Since arguments to OpenAcc pragmas
+   need to be writable, we need to return the identifier residing in such
+   expressions rather than the expression itself.  */
+if (Nkind (gnat_node) == N_Identifier
+	&& TREE_CODE (gnu_result) == NE_EXPR
+	&& TREE_CODE (TREE_TYPE (TREE_OPERAND (gnu_result, 0))) == BOOLEAN_TYPE
+	&& integer_zerop (TREE_OPERAND (gnu_result, 1)))
+  gnu_result = TREE_OPERAND (gnu_result, 0);
+
+  return gnu_result;
+}
+
+/* Turn GNAT_EXPR into a tree node representing an OMP data clause and chain
+   it to GNU_CLAUSES, a list of pre-existing OMP clauses.  GNAT_EXPR should be
+   a N_Identifier, this is enforced by the frontend.
+
+   This function is called every time translation of an argument for an OpenAcc
+   clause (e.g. Acc_Parallel(Copy => My_Identifier)) is needed.  */
+
+static tree
+Acc_Data_to_gnu (Node_Id gnat_expr, tree gnu_clauses, void* data)
+{
+  tree gnu_clause;
+  enum gomp_map_kind kind = *((enum gomp_map_kind*) data);
+  gnu_clause = build_omp_clause (EXPR_LOCATION(gnu_loop_stack->last ()->stmt),
+ OMP_CLAUSE_MAP);
+

[Ada] Adjust the default MALLOC_OBSERVABLE_ALIGNMENT to 2 * POINTER_SIZE

[Pierre-Marie de Rodat]

Instead of 2 * LONG_TYPE_SIZE. POINTER_SIZE is believed to be the
correct base on more configurations than LONG_TYPE_SIZE and this
adjustment prevents the need for local patches to compensate on
configurations where the latter is inappropriate, for example
x86_64-mingw.

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

2018-12-03  Olivier Hainque  

gcc/ada/

* gcc-interface/targtyps.c (MALLOC_OBSERVABLE_ALIGNMENT): Set to
2 * POINTER_SIZE.--- gcc/ada/gcc-interface/targtyps.c
+++ gcc/ada/gcc-interface/targtyps.c
@@ -6,7 +6,7 @@
  *  *
  *  Body*
  *  *
- *  Copyright (C) 1992-2015, Free Software Foundation, Inc. *
+ *  Copyright (C) 1992-2018, Free Software Foundation, Inc. *
  *  *
  * GNAT is free software;  you can  redistribute it  and/or modify it under *
  * terms of the  GNU General Public License as published  by the Free Soft- *
@@ -132,7 +132,7 @@ get_target_maximum_default_alignment (void)
 #ifdef MALLOC_OBSERVABLE_ALIGNMENT
 #define MALLOC_ALIGNMENT MALLOC_OBSERVABLE_ALIGNMENT
 #else
-#define MALLOC_OBSERVABLE_ALIGNMENT (2 * LONG_TYPE_SIZE)
+#define MALLOC_OBSERVABLE_ALIGNMENT (2 * POINTER_SIZE)
 #define MALLOC_ALIGNMENT \
   MAX (MALLOC_ABI_ALIGNMENT, MALLOC_OBSERVABLE_ALIGNMENT)
 #endif

[Ada] Missing check on if-expression

[Pierre-Marie de Rodat]

This patch fixes a constraint check on a dependent expression of an
if-expression, when the context if given by a slice or the 'Range of
an array. The constraint check is applied if the context is constrained,
but the corresponding flag was not set for the index subtype generated
for a slice (explicit or implicit).

Executing:
   gprbuild -P test -q main
   ./main

Must yield:
   raised CONSTRAINT_ERROR : foo.ads:13 range check failed


with Types;
generic
   Buffer : in out Types.Buffer;
package Foo
is
   function Get (Pos : Natural) return Integer;

private
   function Get (Pos : Natural) return Integer
   is (Buffer ((if Pos in Buffer'Range then Pos else Buffer'First)));
end Foo;

with Foo;
with Types;
with Usefoo;

procedure Main is
   Z : Types.Buffer := (Natural'Last .. Natural'Last - 1 => 0);
   R : Integer;
begin
   Usefoo.Do_Something (Z, R);
end Main;

pragma SPARK_Mode (On);
pragma Profile (Ravenscar);
pragma Partition_Elaboration_Policy (Sequential);

project Test is
  package Compiler is
for Default_Switches ("Ada") use ("-gnatws");
for Local_Configuration_Pragmas use "test.adc";
  end Compiler;
end Test;

package Types
is
   subtype Natural_Without_Last is Natural range 1 .. Natural'Last - 1;
   type Buffer is array (Natural_Without_Last range <>) of Integer;

end Types;

with Foo;

package body Usefoo
is

   procedure Do_Something (B : in out Types.Buffer;
   R : out Integer)
   is
  package F is new Foo (B (B'First .. B'First + B'Length / 2 - 1));
   begin
  R := F.Get (B'First + B'Length / 2 - 1);
   end Do_Something;

end Usefoo;

with Types;

package Usefoo
is

   procedure Do_Something (B : in out Types.Buffer;
   R : out Integer)
   with Pre => B'First > 0;

end Usefoo;

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

2018-12-03  Ed Schonberg  

gcc/ada/

* sem_res.adb (Set_Slice_Subtype): The index type of a slice is
constrained.--- gcc/ada/sem_res.adb
+++ gcc/ada/sem_res.adb
@@ -11855,11 +11855,12 @@ package body Sem_Res is
  --  for the subtype, but not in the context of a loop iteration
  --  scheme).
 
- Set_Scalar_Range (Index_Subtype, New_Copy_Tree (Drange));
- Set_Parent   (Scalar_Range (Index_Subtype), Index_Subtype);
- Set_Etype(Index_Subtype, Index_Type);
- Set_Size_Info(Index_Subtype, Index_Type);
- Set_RM_Size  (Index_Subtype, RM_Size (Index_Type));
+ Set_Scalar_Range   (Index_Subtype, New_Copy_Tree (Drange));
+ Set_Parent (Scalar_Range (Index_Subtype), Index_Subtype);
+ Set_Etype  (Index_Subtype, Index_Type);
+ Set_Size_Info  (Index_Subtype, Index_Type);
+ Set_RM_Size(Index_Subtype, RM_Size (Index_Type));
+ Set_Is_Constrained (Index_Subtype);
   end if;
 
   Slice_Subtype := Create_Itype (E_Array_Subtype, N);

[PATCH] Fix PR88315

[Richard Biener]

While working on improving x264 vectorization I noticed (via
enabling epilogue vectorization) that for SAD and DOT_PROD SLP
reductions with non-zero initial value we create wrong-code.

The following fixes this, removing the ugly backwards-creation
of the initial value.

Bootstrap & regtest running on x86_64-unknown-linux-gnu.

This seems to be broken since forever.

Richard.

2018-12-03  Richard Biener  

PR tree-optimization/88315
* tree-vect-loop.c (get_initial_defs_for_reduction): Simplify
and fix initialization vector for SAD and DOT_PROD SLP reductions.

* gcc.dg/vect/slp-reduc-sad.c: Adjust to provide non-trivial
initial value.

Index: gcc/tree-vect-loop.c
===
--- gcc/tree-vect-loop.c(revision 266744)
+++ gcc/tree-vect-loop.c(working copy)
@@ -4103,9 +4103,6 @@ get_initial_defs_for_reduction (slp_tree
   tree vop;
   int group_size = stmts.length ();
   unsigned int vec_num, i;
-  unsigned number_of_copies = 1;
-  vec voprnds;
-  voprnds.create (number_of_vectors);
   struct loop *loop;
   auto_vec permute_results;
 
@@ -4138,115 +4135,78 @@ get_initial_defs_for_reduction (slp_tree
   if (!TYPE_VECTOR_SUBPARTS (vector_type).is_constant ())
 nunits = group_size;
 
-  number_of_copies = nunits * number_of_vectors / group_size;
-
   number_of_places_left_in_vector = nunits;
   bool constant_p = true;
   tree_vector_builder elts (vector_type, nunits, 1);
   elts.quick_grow (nunits);
-  for (j = 0; j < number_of_copies; j++)
+  for (j = 0; j < nunits * number_of_vectors; ++j)
 {
-  for (i = group_size - 1; stmts.iterate (i, _vinfo); i--)
-{
- tree op;
- /* Get the def before the loop.  In reduction chain we have only
-one initial value.  */
- if ((j != (number_of_copies - 1)
-  || (reduc_chain && i != 0))
- && neutral_op)
-   op = neutral_op;
- else
-   op = PHI_ARG_DEF_FROM_EDGE (stmt_vinfo->stmt, pe);
-
-  /* Create 'vect_ = {op0,op1,...,opn}'.  */
-  number_of_places_left_in_vector--;
- elts[number_of_places_left_in_vector] = op;
- if (!CONSTANT_CLASS_P (op))
-   constant_p = false;
+  tree op;
+  i = j % group_size;
+  stmt_vinfo = stmts[i];
+
+  /* Get the def before the loop.  In reduction chain we have only
+one initial value.  Else we have as many as PHIs in the group.  */
+  if (reduc_chain)
+   op = i != 0 ? neutral_op : PHI_ARG_DEF_FROM_EDGE (stmt_vinfo->stmt, pe);
+  else if (((vec_oprnds->length () + 1) * nunits
+   - number_of_places_left_in_vector >= group_size)
+  && neutral_op)
+   op = neutral_op;
+  else
+   op = PHI_ARG_DEF_FROM_EDGE (stmt_vinfo->stmt, pe);
 
-  if (number_of_places_left_in_vector == 0)
-{
- gimple_seq ctor_seq = NULL;
- tree init;
- if (constant_p && !neutral_op
- ? multiple_p (TYPE_VECTOR_SUBPARTS (vector_type), nunits)
- : known_eq (TYPE_VECTOR_SUBPARTS (vector_type), nunits))
-   /* Build the vector directly from ELTS.  */
-   init = gimple_build_vector (_seq, );
- else if (neutral_op)
+  /* Create 'vect_ = {op0,op1,...,opn}'.  */
+  number_of_places_left_in_vector--;
+  elts[nunits - number_of_places_left_in_vector - 1] = op;
+  if (!CONSTANT_CLASS_P (op))
+   constant_p = false;
+
+  if (number_of_places_left_in_vector == 0)
+   {
+ gimple_seq ctor_seq = NULL;
+ tree init;
+ if (constant_p && !neutral_op
+ ? multiple_p (TYPE_VECTOR_SUBPARTS (vector_type), nunits)
+ : known_eq (TYPE_VECTOR_SUBPARTS (vector_type), nunits))
+   /* Build the vector directly from ELTS.  */
+   init = gimple_build_vector (_seq, );
+ else if (neutral_op)
+   {
+ /* Build a vector of the neutral value and shift the
+other elements into place.  */
+ init = gimple_build_vector_from_val (_seq, vector_type,
+  neutral_op);
+ int k = nunits;
+ while (k > 0 && elts[k - 1] == neutral_op)
+   k -= 1;
+ while (k > 0)
{
- /* Build a vector of the neutral value and shift the
-other elements into place.  */
- init = gimple_build_vector_from_val (_seq, vector_type,
-  neutral_op);
- int k = nunits;
- while (k > 0 && elts[k - 1] == neutral_op)
-   k -= 1;
- while (k > 0)
-   {
- k -= 1;
- init = gimple_build (_seq, CFN_VEC_SHL_INSERT,
- 

[PATCH] Fix epilogue vectorization niter more

[Richard Biener]

Previous patch exposes another issue with the code - LOOP_VINFO_INT_NITERS
is already adjusted for prologue peeling.

Bootstrap and regtest running on x86_64-unknown-linux-gnu.

Richard.

2018-12-03  Richard Biener  

* tree-vect-loop.c (vect_transform_loop): Fix epilogue iterations
for epilogue vectorization.

Index: gcc/tree-vect-loop.c
===
--- gcc/tree-vect-loop.c(revision 266739)
+++ gcc/tree-vect-loop.c(working copy)
@@ -8542,13 +8500,13 @@ vect_transform_loop (loop_vec_info loop_
   targetm.vectorize.autovectorize_vector_sizes (_sizes);
   unsigned int next_size = 0;
 
+  /* Note LOOP_VINFO_NITERS_KNOWN_P and LOOP_VINFO_INT_NITERS work
+ on niters already ajusted for the iterations of the prologue.  */
   if (LOOP_VINFO_NITERS_KNOWN_P (loop_vinfo)
- && LOOP_VINFO_PEELING_FOR_ALIGNMENT (loop_vinfo) >= 0
  && known_eq (vf, lowest_vf))
{
- unsigned int eiters
+ unsigned HOST_WIDE_INT eiters
= (LOOP_VINFO_INT_NITERS (loop_vinfo)
-  - LOOP_VINFO_PEELING_FOR_ALIGNMENT (loop_vinfo)
   - LOOP_VINFO_PEELING_FOR_GAPS (loop_vinfo));
  eiters
= eiters % lowest_vf + LOOP_VINFO_PEELING_FOR_GAPS (loop_vinfo);

Re: [RFC][AArch64] Add support for system register based stack protector canary access

[Florian Weimer]

* Ramana Radhakrishnan:

> I don't intend to change the defaults in userland, we've discussed this 
> for user-land in the past and as far as glibc and userland is concerned 
> we stick to the options as currently existing. The system register 
> option is really for the kernel to use along with an offset as they 
> control their ABI and this is a decision for them to make.

For userland, I would like to eventually copy the OpenBSD approach for
architectures which have some form of PC-relative addressing: we can
have multiple random canaries in (RELRO) .rodata in sufficiently close
to the code that needs them (assuming that we have split .rodata).  At
least for x86-64, I expect this to be a small win.  It's also a slight
hardening improvement if the reference canary is not stored in writable
memory.

Thanks,
Florian

Re: PR fortran/87919 patch for -fno-dec-structure

[Mark Eggleston]

On 12/11/2018 20:28, Fritz Reese wrote:

Attached is the latest version, which builds and regtests cleanly on
x86_64-redhat-linux. OK for trunk, 7-branch, and 8-branch?


I'm currently using this patch (pending it being committed) and have 
some pending patches that use it.


I can use the old method of setting dec options for the time being and 
PR fortran/87919 will have to be modified accordingly.


I note that in gcc/fortran/options the comment preceding 
set_default_std_flags it says:


"Keep in sync with libgfortran/runtime/compile_options.c 
(init_compile_options)."


and in libgfortran/runtime/compile_options.c preceding 
init_compile_options it says:


"Keep in sync with gcc/fortran/options.c (gfc_init_options)."

I think this should have (set_default_std_flags) instead of 
(gfc_init_options) and they are not in sync.


Mark


Fritz


--
https://www.codethink.co.uk/privacy.html

[committed] Fix ICE due to bogus operand predicate in H8 port peepholes

[Jeff Law]

This is a bit more interesting than the last H8 fix.

The H8 has peepholes to optimize masking a value down to a byte.  They
rely on using gen_lowpart to extract the low byte value of the source
operand which works well on the H8 because accessing the low byte of a
reg is particularly cheap.  THey also work on memory operands.

These peepholes don't really work on symbolic operands.  And if one
makes it into the peephole we'll abort in gen_lowpart.

Anyway, the peepholes currently accept "general_operand", which of
course allows those problematical symbolic operands.  Changing the
operand to "nonimmediate_operand" resolves the issue.  Note that
compile-time constants aren't really a concern here as the expression
would have already been simplified.

This fixes a half-dozen failures in the H8 testsuite.  More importantly
it makes it less likely that a test will suddenly fail because of
improvements to constant propagation or forward propagation.

Installing on the trunk.

Jeff
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index bde3cd4f042..be0aab2c876 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,8 @@
+2018-12-03  Jeff Law  
+
+   * config/h8300/h8300.md (low byte masking peepholes): Only accept
+   nonimmediate_operand for the to-be-masked operand.
+
 2018-12-03  Richard Biener  
 
* tree-ssa-sccvn.c (eliminate_dom_walker::eliminate_stmt): Only
diff --git a/gcc/config/h8300/h8300.md b/gcc/config/h8300/h8300.md
index b3ba7e0f719..9e8f7159846 100644
--- a/gcc/config/h8300/h8300.md
+++ b/gcc/config/h8300/h8300.md
@@ -4647,7 +4647,7 @@
 
 (define_peephole2
   [(set (match_operand:SI 0 "register_operand" "")
-   (match_operand:SI 1 "general_operand" ""))
+   (match_operand:SI 1 "nonimmediate_operand" ""))
(set (match_dup 0)
(and:SI (match_dup 0)
(const_int 255)))]
@@ -4666,7 +4666,7 @@
 
 (define_peephole2
   [(set (match_operand 0 "register_operand" "")
-   (match_operand 1 "general_operand" ""))
+   (match_operand 1 "nonimmediate_operand" ""))
(set (match_operand:SI 2 "register_operand" "")
(and:SI (match_dup 2)
(match_operand:SI 3 "const_int_qi_operand" "")))]

[committed] Make some test names unique

[Jeff Law]

The introduction relative line number support in the dg framework was
absolutely a good thing in terms of testsuite maintenance.  However, it
also made it possible to have duplicated testnames.

The duplicated names cause our summary analysis scripts major headaches
if one of the tests pass and the other fails.  This patch fixes a couple
of instances that have have caused problems in my tester. This is by no
means comprehensive, in fact, it's likely just a drop in the bucket.

Installing on the trunk,

Jeff
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index f38b209ff07..9713cdaefed 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,8 @@
+2018-12-03  Jeff Law  
+
+   * gcc.dg/pr59963-2.c: Make testnames unique.
+   * gcc.dg/tree-ssa/builtin-sprintf-warn-18.c: Likewise.
+
 2018-12-03  Richard Biener  
 
PR tree-optimization/88301
diff --git a/gcc/testsuite/gcc.dg/pr59963-2.c b/gcc/testsuite/gcc.dg/pr59963-2.c
index 286a5f9e1eb..f54a3126960 100644
--- a/gcc/testsuite/gcc.dg/pr59963-2.c
+++ b/gcc/testsuite/gcc.dg/pr59963-2.c
@@ -32,6 +32,6 @@ foo (int i)
   -7, /* { dg-warning "15:-Wsign-conversion" } */
-8); /* { dg-warning "16:-Wsign-conversion" } */
   bazu (i, i); /* { dg-warning "9:conversion" } */
-  bazi (0x8, 0x8000); /* { dg-warning "14:-Wsign-conversion" "" { xfail 
int16 } } */
- /* { dg-warning "overflow in conversion from" "" { 
target int16 } .-1 } */
+  bazi (0x8, 0x8000); /* { dg-warning "14:-Wsign-conversion" "first" { 
xfail int16 } } */
+ /* { dg-warning "overflow in conversion from" 
"second" { target int16 } .-1 } */
 }
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-18.c 
b/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-18.c
index 7064f8a6d58..2203e5263f7 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-18.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-18.c
@@ -117,10 +117,10 @@ void test_width_and_precision_out_of_range (char *d)
 {
   /* The range here happens to be a property of the compiler, not
  one of the target.  */
-  T ("%9223372036854775808i", 0);/* { dg-warning "width out of range" } */
-  /* { dg-warning "result to exceed .INT_MAX." "" { target *-*-* } .-1 } */
-  T ("%.9223372036854775808i", 0);   /* { dg-warning "precision out of range" 
} */
-  /* { dg-warning "causes result to exceed .INT_MAX." "" { target *-*-* } .-1 
} */
+  T ("%9223372036854775808i", 0);/* { dg-warning "width out of range" 
"first" } */
+  /* { dg-warning "result to exceed .INT_MAX." "second" { target *-*-* } .-1 } 
*/
+  T ("%.9223372036854775808i", 0);   /* { dg-warning "precision out of range" 
"first" } */
+  /* { dg-warning "causes result to exceed .INT_MAX." "second" { target *-*-* 
} .-1 } */
 
   /* The following is diagnosed by -Wformat (disabled here).  */
   /* T ("%9223372036854775808$i", 0); */

[PATCH] Tighten PRE/FRE elimination

[Richard Biener]

It happily inserted int->float casts if sth goes wrong in VN or
elimination.  The following restricts it to the expected
re-instantiation of function pointer casts.

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

Richard.

2018-12-03  Richard Biener  

* tree-ssa-sccvn.c (eliminate_dom_walker::eliminate_stmt): Only
allow expected function-pointer cast re-instantiation.

Index: gcc/tree-ssa-sccvn.c
===
--- gcc/tree-ssa-sccvn.c(revision 266733)
+++ gcc/tree-ssa-sccvn.c(working copy)
@@ -4984,10 +4984,6 @@ eliminate_dom_walker::eliminate_stmt (ba
return;
 
  /* Else replace its RHS.  */
- bool can_make_abnormal_goto
- = is_gimple_call (stmt)
- && stmt_can_make_abnormal_goto (stmt);
-
  if (dump_file && (dump_flags & TDF_DETAILS))
{
  fprintf (dump_file, "Replaced ");
@@ -4997,12 +4993,23 @@ eliminate_dom_walker::eliminate_stmt (ba
  fprintf (dump_file, " in ");
  print_gimple_stmt (dump_file, stmt, 0);
}
-
  eliminations++;
+
+ bool can_make_abnormal_goto = (is_gimple_call (stmt)
+&& stmt_can_make_abnormal_goto (stmt));
  gimple *orig_stmt = stmt;
  if (!useless_type_conversion_p (TREE_TYPE (lhs),
  TREE_TYPE (sprime)))
-   sprime = fold_convert (TREE_TYPE (lhs), sprime);
+   {
+ /* We preserve conversions to but not from function or method
+types.  This asymmetry makes it necessary to re-instantiate
+conversions here.  */
+ if (POINTER_TYPE_P (TREE_TYPE (lhs))
+ && FUNC_OR_METHOD_TYPE_P (TREE_TYPE (TREE_TYPE (lhs
+   sprime = fold_convert (TREE_TYPE (lhs), sprime);
+ else
+   gcc_unreachable ();
+   }
  tree vdef = gimple_vdef (stmt);
  tree vuse = gimple_vuse (stmt);
  propagate_tree_value_into_stmt (gsi, sprime);

Re: [PATCH] S/390: Add support for section anchors

[Andreas Krebbel]

On 29.11.18 13:47, Ilya Leoshkevich wrote:
> Bootstrapped and regtested on s390x-redhat-linux and
> x86_64-redhat-linux.
> 
> gcc/ChangeLog:
> 
> 2018-09-12  Ilya Leoshkevich  
> 
>   * common/config/s390/s390-common.c (s390_option_init_struct):
>   Use section anchors by default.
>   * config/s390/s390.c (s390_check_symref_alignment): Handle
>   anchors.
>   (TARGET_MAX_ANCHOR_OFFSET): Use short displacement.
>   * output.h (assemble_align): Pass `align' as unsigned int, so
>   that the value 0x8000, which corresponds to `aligned(1 <<
>   28)', would pass the `align > BITS_PER_UNIT' check.
>   * varasm.c (assemble_align): Likewise.
> 
> gcc/testsuite/ChangeLog:
> 
> 2018-09-12  Ilya Leoshkevich  
> 
>   * gcc.target/s390/nodatarel-1.c: Expect .LANCHOR0@GOTENT instead
>   of a@GOTENT.
>   * gcc.target/s390/section-anchors.c: New test.
>   * gcc.target/s390/section-anchors2.c: New test.
>   * gcc.target/s390/section-anchors3.c: New test.

Ok. Thanks!

Andreas

Re: RFA/RFC: Add stack recursion limit to libiberty's demangler

[Nick Clifton]

Hi Cary,

> In order to handle arbitrary user input without crashing, perhaps the
> demangler should switch from recursive descent parsing to a state
> machine, where exhaustion of resources can be handled gracefully.

I think that that would be a better long term fix for the problem,
but it is not one that I have time to work on right now.

My main goal with this patch submission is to stop the flood of PR 
and CVEs about mangled inputs that trigger stack exhaustion.  Being 
able to properly demangle such inputs would be nice, but not something
that I think should be a priority.  I think that in real life no 
program is ever going to generate a mangled name that is sufficiently 
complex to trigger a seg-fault this way, so the only real purpose of
the patch is to resolve these PRs and stop more from being filed.

Cheers
  Nick

Re: RFA/RFC: Add stack recursion limit to libiberty's demangler [v3]

[Nick Clifton]

Hi Richard,

>>   * The description of the DMGL_RECURSE_LIMIT option in demangle.h has
>> been enhanced to add a note that if the option is not used, then
>> bug reports about stack overflows in the demangler will be rejected.
> 
> Shouldn't we make it fool-proof by instead introducing a 
> DMGL_NO_RECURSION_LIMIT
> flag and when not set default to limiting recursion?

Well I wanted the patch to be backwards compatible. Just on the
general principle of not surprising users/programmers by changing 
things without telling them first.

I could change this of course, but I would rather have Ian's blessing
first.

Cheers
  Nick

Re: [Darwin] Fix build warnings for libstdc++ [NFC]

[Jonathan Wakely]

On 03/12/18 00:37 +, Iain Sandoe wrote:

Hi,

GCC does not export construction vtable symbols from shared libraries**.

The symbols are marked hidden in the objects; for Darwin that makes them also 
external (“private_extern” is Darwin’s hidden) which means that they show up in 
the list of possible symbols for export from libstdc++, and there are 
sufficiently relaxed match conditions that they reach the exports list.   When 
Darwin’s static linker encounters them it generates a warning that they cannot 
be exported.  This patch prunes them from the list of symbols to be considered, 
thus eliminating the warnings.

OK for trunk?


Yes, OK.


Iain

**  This seems a design decision, rather than an ABI mandate - note that, on 
Darwin at least, these symbols *are* visible in libc++.

libstdc++-v3/

* scripts/make_exports.pl (check names): Don’t try to export 
construction
vtable symbols.


diff --git a/libstdc++-v3/scripts/make_exports.pl 
b/libstdc++-v3/scripts/make_exports.pl
index 7c9e4e31d4..93100e17dd 100644
--- a/libstdc++-v3/scripts/make_exports.pl
+++ b/libstdc++-v3/scripts/make_exports.pl
@@ -103,6 +103,14 @@ NAME: while () {
# Ignore undefined and local symbols.
next if (/^([^ ]+) [Ua-z] /);

+# GCC does not export construction vtables from shared libraries.
+# However the symbols are marked hidden, for Darwin that makes them
+# also external "private_extern", which means that they show up in
+# this list.  When ld64 encounters them it generates a warning that
+# they cannot be exported, so trim them from the set now.
+next if (/^construction vtable.*$/);
+next if (/^__ZTC.*$/);
+

Re: [PATCH] i386; Add -mmanual-endbr and cf_check function attribute

[H.J. Lu]

On Mon, Jun 18, 2018 at 2:20 AM Richard Biener
 wrote:
>
> On Fri, Jun 15, 2018 at 2:59 PM H.J. Lu  wrote:
> >
> > Currently GCC inserts ENDBR instruction at entries of all non-static
> > functions, unless LTO compilation is used.  Marking all functions,
> > which are not called indirectly with nocf_check attribute, is not
> > ideal since 99% of functions in a program may be of this kind.
> >
> > This patch adds -mmanual-endbr and cf_check function attribute.  They
> > can be used together with -fcf-protection such that ENDBR instruction
> > is inserted only at entries of functions with cf_check attribute.  It
> > can limit number of ENDBR instructions to reduce program size.
> >
> > OK for trubk?
>
> I wonder if the linker could assist with ENDBR creation by
> redirecting all non-direct call relocs to a linker-generated
> stub with ENBR and a direct branch?
>

The goal of this patch is to add as few as ENDBR as possible
to reduce program size as much as possible.   Also there is no
relocation for indirect branch via register.

-- 
H.J.

Re: [PATCH] Fix PR64242

[Christophe Lyon]

On Mon, 3 Dec 2018 at 14:35, Richard Biener  wrote:
>
> On Sat, Dec 1, 2018 at 12:07 AM Jeff Law  wrote:
> >
> > On 11/29/18 12:26 PM, Wilco Dijkstra wrote:
> > > Fix PR64242 - the middle end expansion for long jmp updates the
> > > hard frame pointer before it reads the new stack pointer.  This
> > > results in a corrupted stack pointer if the jmp buffer is a local.
> > > The obvious fix is to insert a temporary.
> > >
> > > AArch64 bootstrap & regress pass. OK to commit?
> > >
> > > ChangeLog:
> > > 2018-11-29  Wilco Dijkstra  
> > >
> > > gcc/
> > >   PR middle-end/64242
> > >   * builtins.c (expand_builtin_longjmp): Use a temporary when 
> > > restoring
> > >   the frame pointer.
> > >   (expand_builtin_nonlocal_goto): Likewise.
> > >
> > > testsuite/
> > >   PR middle-end/64242
> > >   * gcc.c-torture/execute/pr64242.c: New test.
> > THanks for tracking this down.  I'd like to have this run through my
> > next testing cycle, so I went ahead and installed  it for you.
>
> The testcase runfails on x86_64 with -m32 and -m64.
>
And on some arm targets, as I mentioned in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64242#c7

> Richard.
>
> > Thanks again,
> > Jeff

[PATCH] Fix PR88301

[Richard Biener]

This fixes a missed optimization in EVRP by teaching the code
figuring out conditional asserts about conversions that preserve
the converted value.

Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk 
sofar.

Richard.

2018-12-03  Richard Biener  

PR tree-optimization/88301
* tree-vrp.c (register_edge_assert_for_2): Handle conversions
that do not change the value by registering the same assert
for the operand.

* gcc.dg/tree-ssa/evrp13.c: New testcase.

Index: gcc/tree-vrp.c
===
--- gcc/tree-vrp.c  (revision 266733)
+++ gcc/tree-vrp.c  (working copy)
@@ -2966,6 +2966,23 @@ register_edge_assert_for_2 (tree name, e
add_assert_info (asserts, name2, tmp, new_comp_code, new_val);
}
 
+  /* If we have a conversion that doesn't change the value of the source
+ simply register the same assert for it.  */
+  if (CONVERT_EXPR_CODE_P (rhs_code))
+   {
+ wide_int rmin, rmax;
+ tree rhs1 = gimple_assign_rhs1 (def_stmt);
+ if (INTEGRAL_TYPE_P (TREE_TYPE (rhs1))
+ && int_fits_type_p (val, TREE_TYPE (rhs1))
+ && ((TYPE_PRECISION (TREE_TYPE (name))
+  > TYPE_PRECISION (TREE_TYPE (rhs1)))
+ || (get_range_info (rhs1, , ) == VR_RANGE
+ && wi::fits_to_tree_p (rmin, TREE_TYPE (name))
+ && wi::fits_to_tree_p (rmax, TREE_TYPE (name)
+   add_assert_info (asserts, rhs1, rhs1,
+comp_code, fold_convert (TREE_TYPE (rhs1), val));
+   }
+
   /* Add asserts for NAME cmp CST and NAME being defined as
 NAME = NAME2 & CST2.
 
Index: gcc/testsuite/gcc.dg/tree-ssa/evrp13.c
===
--- gcc/testsuite/gcc.dg/tree-ssa/evrp13.c  (revision 0)
+++ gcc/testsuite/gcc.dg/tree-ssa/evrp13.c  (working copy)
@@ -0,0 +1,7 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-evrp" } */
+
+#define ADD_NW(A,B) (__extension__({ __typeof(A+B) R; 
if(__builtin_add_overflow(A,B,)) __builtin_unreachable(); R ;}))
+_Bool a_b2(unsigned A,  unsigned B) { return ADD_NW(A,B) >= B; }
+
+/* { dg-final { scan-tree-dump "return 1;" "evrp" } } */

[committed] Add testcase from PR tree-optimization/71109

[Jakub Jelinek]

Hi!

This testcase broke on x86_64-linux with -O3 with r227775
and got fixed or went latent with r236372.  I've just committed the
testcase to the testsuite as obvious, let's close the PR now.

2018-12-03  Jakub Jelinek  

PR tree-optimization/71109
* gcc.c-torture/compile/pr71109.c: New test.

--- gcc/testsuite/gcc.c-torture/compile/pr71109.c.jj2018-12-03 
14:28:42.678952260 +0100
+++ gcc/testsuite/gcc.c-torture/compile/pr71109.c   2018-12-03 
14:28:38.928013113 +0100
@@ -0,0 +1,31 @@
+/* PR tree-optimization/71109 */
+
+struct S { int g, h; signed char i; int j; signed char k; int l[4]; } a, c;
+struct T { signed char g; } e;
+int *b, d;
+static void foo ();
+
+void
+bar (void)
+{
+  while (d)
+{
+  int k;
+  struct T f[3];
+  foo (bar, a);
+  for (k = 0;; k++)
+   f[k] = e;
+}
+}
+
+static inline void
+foo (int x, struct S y, struct T z)
+{
+  for (z.g = 2; z.g; z.g--)
+{
+  c = a = y;
+  *b |= 6;
+  if (y.g)
+   break;
+}
+}

Jakub

Re: [PATCH] Fix PR64242

[Richard Biener]

On Sat, Dec 1, 2018 at 12:07 AM Jeff Law  wrote:
>
> On 11/29/18 12:26 PM, Wilco Dijkstra wrote:
> > Fix PR64242 - the middle end expansion for long jmp updates the
> > hard frame pointer before it reads the new stack pointer.  This
> > results in a corrupted stack pointer if the jmp buffer is a local.
> > The obvious fix is to insert a temporary.
> >
> > AArch64 bootstrap & regress pass. OK to commit?
> >
> > ChangeLog:
> > 2018-11-29  Wilco Dijkstra  
> >
> > gcc/
> >   PR middle-end/64242
> >   * builtins.c (expand_builtin_longjmp): Use a temporary when restoring
> >   the frame pointer.
> >   (expand_builtin_nonlocal_goto): Likewise.
> >
> > testsuite/
> >   PR middle-end/64242
> >   * gcc.c-torture/execute/pr64242.c: New test.
> THanks for tracking this down.  I'd like to have this run through my
> next testing cycle, so I went ahead and installed  it for you.

The testcase runfails on x86_64 with -m32 and -m64.

Richard.

> Thanks again,
> Jeff

[PATCH] Fix epilogue upper bound for epilogue vectorization

[Richard Biener]

I figured the epilogue vectorization code doesn't compute the correct
number of iterations for the epilogue when peeling for gaps is in
effect.  This prevents epilogue vectorization in some cases and
given the code also sets nb_iterations_upper_bound, causes possible
wrong-code (I think we probably want to remove that code since it
should be redundant).

Boostrapped and tested on x86_64-unknown-linux-gnu, I also ran
SPEC 2k6 with epilogue vectorization enabled on a core-avx2
machine successfully.

Applied to trunk.
Richard.

2018-12-03  Richard Biener  

* tree-vect-loop.c (vect_transform_loop): Properly compute
upper bound for the epilogue when doing epilogue vectorization.

Index: gcc/tree-vect-loop.c
===
--- gcc/tree-vect-loop.c(revision 25)
+++ gcc/tree-vect-loop.c(working copy)
@@ -8548,9 +8548,12 @@ vect_transform_loop (loop_vec_info loop_
{
  unsigned int eiters
= (LOOP_VINFO_INT_NITERS (loop_vinfo)
-  - LOOP_VINFO_PEELING_FOR_ALIGNMENT (loop_vinfo));
- eiters = eiters % lowest_vf;
+  - LOOP_VINFO_PEELING_FOR_ALIGNMENT (loop_vinfo)
+  - LOOP_VINFO_PEELING_FOR_GAPS (loop_vinfo));
+ eiters
+   = eiters % lowest_vf + LOOP_VINFO_PEELING_FOR_GAPS (loop_vinfo);
  epilogue->nb_iterations_upper_bound = eiters - 1;
+ epilogue->any_upper_bound = true;
 
  unsigned int ratio;
  while (next_size < vector_sizes.length ()

Re: Add a loop versioning pass

[Richard Biener]

On Wed, 28 Nov 2018, Richard Sandiford wrote:

> Thanks for the review and sorry for the long time replying.

Likewise ...

> Richard Biener  writes:
> >> This patch adds a pass that versions loops with variable index strides
> >> for the case in which the stride is 1.  E.g.:
> >> 
> >> for (int i = 0; i < n; ++i)
> >>   x[i * stride] = ...;
> >> 
> >> becomes:
> >> 
> >> if (stepx == 1)
> >>   for (int i = 0; i < n; ++i)
> >> x[i] = ...;
> >> else
> >>   for (int i = 0; i < n; ++i)
> >> x[i * stride] = ...;
> >> 
> >> This is useful for both vector code and scalar code, and in some cases
> >> can enable further optimisations like loop interchange or pattern
> >> recognition.
> >> 
> >> The pass gives a 7.6% improvement on Cortex-A72 for 554.roms_r at -O3
> >> and a 2.4% improvement for 465.tonto.  I haven't found any SPEC tests
> >> that regress.
> >> 
> >> Sizewise, there's a 10% increase in .text for both 554.roms_r and
> >> 465.tonto.  That's obviously a lot, but in tonto's case it's because
> >> the whole program is written using assumed-shape arrays and pointers,
> >> so a large number of functions really do benefit from versioning.
> >> roms likewise makes heavy use of assumed-shape arrays, and that
> >> improvement in performance IMO justifies the code growth.
> >
> > Ouch.  I know that at least with LTO IPA-CP can do "quite" some
> > propagation of constant strides.  Not sure if we're aggressive
> > enough in actually doing the cloning for all cases we figure out
> > strides though.  But my question is how we can avoid doing the
> > versioning for loops in the copy that did not have the IPA-CPed
> > stride of one?  Ideally we'd be able to mark individual references
> > as {definitely,likely,unlikely,not}-unit-stride?
> 
> This is a more elaborate version of what I was trying to do with
> the IFN I'd mentioned on IRC a few weeks back.  It would be a bit
> like a long-living ASSERT_EXPR that provides hints about the value
> of the SSA name.  Another alternative would be to annotate the
> SSA name itself, but then we'd easily lose the information during
> optimisation.
> 
> But will IPA-CP conditionally use a clone for a stride of 1 for
> calls that pass a variable stride that might or might not be 1?
> E.g. if it clones foo as foo.1 for calls in which a stride parameter
> is 1 at compile time, does it also make foo call foo.1 when the stride
> parameter is 1 at runtime?  If not, that sounds like a missed optimisation.
> If so, prune_conditions should stop us from versioning.

Martin answered that.

> >> The next biggest .text increase is 4.5% for 548.exchange2_r.  I did see
> >> a small (0.4%) speed improvement there, but although both 3-iteration runs
> >> produced stable results, that might still be noise.  There was a slightly
> >> larger (non-noise) improvement for a 256-bit SVE model.
> >> 
> >> 481.wrf and 521.wrf_r .text grew by 2.8% and 2.5% respectively, but
> >> without any noticeable improvement in performance.  No other test grew
> >> by more than 2%.
> >> 
> >> Although the main SPEC beneficiaries are all Fortran tests, the
> >> benchmarks we use for SVE also include some C and C++ tests that
> >> benefit.
> >
> > Did you see any slowdown, for example because versioning was forced
> > to be on an innermost loop?  I'm thinking of the testcase in
> > PR87561 where we do have strided accesses in the innermost loop.
> 
> Not so far.
> 
> > Since you cite performance numbers how did you measure them?
> > I assume -Ofast -march=native but did you check with -flto?
> 
> -O3 -march=native.  No, didn't check LTO, will do that.
> 
> >> Using -frepack-arrays gives the same benefits in many Fortran cases.
> >> The problem is that using that option inappropriately can force a full
> >> array copy for arguments that the function only reads once, and so it
> >> isn't really something we can turn on by default.  The new pass is
> >> supposed to give most of the benefits of -frepack-arrays without
> >> the risk of unnecessary repacking.
> >> 
> >> The patch therefore enables the pass by default at -O3.
> >
> > I think that's reasonable.
> >
> > One possible enhancement would be to add a value-profile for the
> > strides so we can guide this optimization better.
> >
> > The pass falls foul of C++ class make small methods of everything.
> > That makes following the code very hard.  Please inline single-used
> > methods in callers wherever possible to make the code read
> > more like GCC code (using GCC API).
> 
> I'll bite my tongue on this one :-)
> 
> > The pass contains an awful lot of heuristics :/  Like last year
> > with the interchange pass I would suggest to rip most of it out
> > and first lay infrastructure with the cases you can positively
> > identify without applying heuristics or "hacks" like stripping
> > semantically required casts.  That makes it also clear which
> > testcases test which code-path.  That said, all the analyze
> > 

[committed] Adjust aarch64/vcond_1.C testcase (PR target/88287)

[Jakub Jelinek]

Hi!

The
x <= -CST   =>  x < -CST + 1
x > -CST=>  x >= -CST + 1
x >= CST=>  x > CST - 1
x < CST =>  x <= CST - 1
match.pd canonicalizations which are newly done also for uniform
vector constants changed the generated instructions in vcond_1.C testcase
slightly.

I've committed as obvious following patch to adjust the scan-assembler regexps.
Tested by Christophe.

2018-12-03  Jakub Jelinek  

PR target/88287
* g++.target/aarch64/sve/vcond_1.C: Adjust for comparison
canonicalization.

--- gcc/testsuite/g++.target/aarch64/sve/vcond_1.C.jj   2018-05-08 
13:56:37.874929888 +0200
+++ gcc/testsuite/g++.target/aarch64/sve/vcond_1.C  2018-12-03 
13:23:48.754036090 +0100
@@ -154,15 +154,15 @@ TEST_IMM_ALL (DEF_VCOND_IMM)
 /* { dg-final { scan-assembler {\tcmpgt\tp[0-7]\.s, p[0-7]/z, z[0-9]+\.s, 
#15\n} } } */
 /* { dg-final { scan-assembler {\tcmpgt\tp[0-7]\.d, p[0-7]/z, z[0-9]+\.d, 
#15\n} } } */
 
-/* { dg-final { scan-assembler {\tcmplt\tp[0-7]\.b, p[0-7]/z, z[0-9]+\.b, 
#15\n} } } */
-/* { dg-final { scan-assembler {\tcmplt\tp[0-7]\.h, p[0-7]/z, z[0-9]+\.h, 
#15\n} } } */
-/* { dg-final { scan-assembler {\tcmplt\tp[0-7]\.s, p[0-7]/z, z[0-9]+\.s, 
#15\n} } } */
-/* { dg-final { scan-assembler {\tcmplt\tp[0-7]\.d, p[0-7]/z, z[0-9]+\.d, 
#15\n} } } */
-
-/* { dg-final { scan-assembler {\tcmpge\tp[0-7]\.b, p[0-7]/z, z[0-9]+\.b, 
#15\n} } } */
-/* { dg-final { scan-assembler {\tcmpge\tp[0-7]\.h, p[0-7]/z, z[0-9]+\.h, 
#15\n} } } */
-/* { dg-final { scan-assembler {\tcmpge\tp[0-7]\.s, p[0-7]/z, z[0-9]+\.s, 
#15\n} } } */
-/* { dg-final { scan-assembler {\tcmpge\tp[0-7]\.d, p[0-7]/z, z[0-9]+\.d, 
#15\n} } } */
+/* { dg-final { scan-assembler {\tcmple\tp[0-7]\.b, p[0-7]/z, z[0-9]+\.b, 
#14\n} } } */
+/* { dg-final { scan-assembler {\tcmple\tp[0-7]\.h, p[0-7]/z, z[0-9]+\.h, 
#14\n} } } */
+/* { dg-final { scan-assembler {\tcmple\tp[0-7]\.s, p[0-7]/z, z[0-9]+\.s, 
#14\n} } } */
+/* { dg-final { scan-assembler {\tcmple\tp[0-7]\.d, p[0-7]/z, z[0-9]+\.d, 
#14\n} } } */
+
+/* { dg-final { scan-assembler {\tcmpgt\tp[0-7]\.b, p[0-7]/z, z[0-9]+\.b, 
#14\n} } } */
+/* { dg-final { scan-assembler {\tcmpgt\tp[0-7]\.h, p[0-7]/z, z[0-9]+\.h, 
#14\n} } } */
+/* { dg-final { scan-assembler {\tcmpgt\tp[0-7]\.s, p[0-7]/z, z[0-9]+\.s, 
#14\n} } } */
+/* { dg-final { scan-assembler {\tcmpgt\tp[0-7]\.d, p[0-7]/z, z[0-9]+\.d, 
#14\n} } } */
 
 /* { dg-final { scan-assembler {\tcmple\tp[0-7]\.b, p[0-7]/z, z[0-9]+\.b, 
#15\n} } } */
 /* { dg-final { scan-assembler {\tcmple\tp[0-7]\.h, p[0-7]/z, z[0-9]+\.h, 
#15\n} } } */
@@ -179,10 +179,10 @@ TEST_IMM_ALL (DEF_VCOND_IMM)
 /* { dg-final { scan-assembler {\tcmpne\tp[0-7]\.s, p[0-7]/z, z[0-9]+\.s, 
#15\n} } } */
 /* { dg-final { scan-assembler {\tcmpne\tp[0-7]\.d, p[0-7]/z, z[0-9]+\.d, 
#15\n} } } */
 
-/* { dg-final { scan-assembler {\tcmpgt\tp[0-7]\.b, p[0-7]/z, z[0-9]+\.b, 
#-16\n} } } */
-/* { dg-final { scan-assembler {\tcmpgt\tp[0-7]\.h, p[0-7]/z, z[0-9]+\.h, 
#-16\n} } } */
-/* { dg-final { scan-assembler {\tcmpgt\tp[0-7]\.s, p[0-7]/z, z[0-9]+\.s, 
#-16\n} } } */
-/* { dg-final { scan-assembler {\tcmpgt\tp[0-7]\.d, p[0-7]/z, z[0-9]+\.d, 
#-16\n} } } */
+/* { dg-final { scan-assembler {\tcmpge\tp[0-7]\.b, p[0-7]/z, z[0-9]+\.b, 
#-15\n} } } */
+/* { dg-final { scan-assembler {\tcmpge\tp[0-7]\.h, p[0-7]/z, z[0-9]+\.h, 
#-15\n} } } */
+/* { dg-final { scan-assembler {\tcmpge\tp[0-7]\.s, p[0-7]/z, z[0-9]+\.s, 
#-15\n} } } */
+/* { dg-final { scan-assembler {\tcmpge\tp[0-7]\.d, p[0-7]/z, z[0-9]+\.d, 
#-15\n} } } */
 
 /* { dg-final { scan-assembler {\tcmplt\tp[0-7]\.b, p[0-7]/z, z[0-9]+\.b, 
#-16\n} } } */
 /* { dg-final { scan-assembler {\tcmplt\tp[0-7]\.h, p[0-7]/z, z[0-9]+\.h, 
#-16\n} } } */
@@ -194,10 +194,10 @@ TEST_IMM_ALL (DEF_VCOND_IMM)
 /* { dg-final { scan-assembler {\tcmpge\tp[0-7]\.s, p[0-7]/z, z[0-9]+\.s, 
#-16\n} } } */
 /* { dg-final { scan-assembler {\tcmpge\tp[0-7]\.d, p[0-7]/z, z[0-9]+\.d, 
#-16\n} } } */
 
-/* { dg-final { scan-assembler {\tcmple\tp[0-7]\.b, p[0-7]/z, z[0-9]+\.b, 
#-16\n} } } */
-/* { dg-final { scan-assembler {\tcmple\tp[0-7]\.h, p[0-7]/z, z[0-9]+\.h, 
#-16\n} } } */
-/* { dg-final { scan-assembler {\tcmple\tp[0-7]\.s, p[0-7]/z, z[0-9]+\.s, 
#-16\n} } } */
-/* { dg-final { scan-assembler {\tcmple\tp[0-7]\.d, p[0-7]/z, z[0-9]+\.d, 
#-16\n} } } */
+/* { dg-final { scan-assembler {\tcmplt\tp[0-7]\.b, p[0-7]/z, z[0-9]+\.b, 
#-15\n} } } */
+/* { dg-final { scan-assembler {\tcmplt\tp[0-7]\.h, p[0-7]/z, z[0-9]+\.h, 
#-15\n} } } */
+/* { dg-final { scan-assembler {\tcmplt\tp[0-7]\.s, p[0-7]/z, z[0-9]+\.s, 
#-15\n} } } */
+/* { dg-final { scan-assembler {\tcmplt\tp[0-7]\.d, p[0-7]/z, z[0-9]+\.d, 
#-15\n} } } */
 
 /* { dg-final { scan-assembler {\tcmpeq\tp[0-7]\.b, p[0-7]/z, z[0-9]+\.b, 
#-16\n} } } */
 /* { dg-final { scan-assembler {\tcmpeq\tp[0-7]\.h, p[0-7]/z, z[0-9]+\.h, 
#-16\n} } } */
@@ -211,15 +211,15 @@ TEST_IMM_ALL 

Re: [wwwdocs] readings.html -- two broken z/Architecture links

[Ulrich Weigand]

Hi Gerald,

> I've been getting
> 
>   "A possible equivalent for dz9zr002 was not found." (or similar)
> 
> for these two pages for a while.
> 
> If you have suitable links to cover these, please go ahead and add
> them; for the time being I committed the patch below.

I've committed the following patch to update those links.

Bye,
Ulrich

Index: readings.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/readings.html,v
retrieving revision 1.308
diff -u -r1.308 readings.html
--- readings.html   2 Dec 2018 10:55:41 -   1.308
+++ readings.html   3 Dec 2018 12:32:00 -
@@ -309,7 +309,10 @@
 
  z/Architecture (S/390)
   Manufacturer: IBM
+  http://publibfp.dhe.ibm.com/epubs/pdf/dz9zr011.pdf;>z/Architecture 
Principles of Operation
+  http://publibfp.dhe.ibm.com/epubs/pdf/dz9ar008.pdf;>ESA/390 
Principles of Operation
   http://refspecs.linuxbase.org/ELF/zSeries/lzsabi0_zSeries.html;>Linux for 
z Systems ABI
+  http://refspecs.linuxbase.org/ELF/zSeries/lzsabi0_s390.html;>Linux for 
S/390 ABI
  
 
 


-- 
  Dr. Ulrich Weigand
  GNU/Linux compilers and toolchain
  ulrich.weig...@de.ibm.com

Re: [PATCH v3][C][ADA] use function descriptors instead of trampolines in C

[Uecker, Martin]

Is there a change that we can move forward with this?

I think this is a very useful feature and might be especially
important if GCC is going to activate -Wtrampoline  with 
-Wall on some architectures.

Best,
Martin


Am Sonntag, den 04.11.2018, 21:48 +0100 schrieb Martin Uecker:
> Hi Joseph,
> 
> here is a new version of this patch which adds a warning
> for targets which do not support -fno-trampolines  and
> only runs the test case on architectures where this is
> supported. It seems that documentation for this general
> feature has improved in the meantime so I only mention
> C as supported.
> 
> 
> Best,
> Martin
> 
> diff --git a/gcc/ChangeLog b/gcc/ChangeLog
> index 5cf291da2d5..e75500c647a 100644
> --- a/gcc/ChangeLog
> +++ b/gcc/ChangeLog
> @@ -1,3 +1,13 @@
> +2018-11-03  Martin Uecker  
> +
> + * common.opt (flag_trampolines): Change default.
> + * calls.c (prepare_call_address): Remove check for
> + flag_trampolines.  Decision is now made in FEs.
> + * tree-nested.c (convert_tramp_reference_op): Likewise.
> + * toplev.c (process_options): Add warning for -fno-
> trampolines on
> + unsupported targets.
> + * doc/invoke.texi (-fno-trampolines): Document support for
> C.
> +
>  2018-11-02  Aaron Sawdey  
>  
>   * config/rs6000/rs6000-string.c
> (expand_strncmp_gpr_sequence): Pay
> diff --git a/gcc/ada/ChangeLog b/gcc/ada/ChangeLog
> index 73666129f55..a7462edfc71 100644
> --- a/gcc/ada/ChangeLog
> +++ b/gcc/ada/ChangeLog
> @@ -1,3 +1,8 @@
> +2018-11-03  Martin Uecker  
> +
> + * gcc-interface/trans.c (Attribute_to_gnu): Add check for
> + flag_trampolines.
> +
>  2018-10-22  Eric Botcazou  
>  
>   * gcc-interface/utils.c (unchecked_convert): Use local
> variables for
> diff --git a/gcc/ada/gcc-interface/trans.c b/gcc/ada/gcc-
> interface/trans.c
> index ce2d43f989e..b79f2373c63 100644
> --- a/gcc/ada/gcc-interface/trans.c
> +++ b/gcc/ada/gcc-interface/trans.c
> @@ -1753,7 +1753,8 @@ Attribute_to_gnu (Node_Id gnat_node, tree
> *gnu_result_type_p, int attribute)
>     if ((attribute == Attr_Access
>      || attribute == Attr_Unrestricted_Access)
>     && targetm.calls.custom_function_descriptors > 0
> -   && Can_Use_Internal_Rep (Etype (gnat_node)))
> +   && Can_Use_Internal_Rep (Etype (gnat_node))
> +  && (flag_trampolines != 1))
>   FUNC_ADDR_BY_DESCRIPTOR (gnu_expr) = 1;
>  
>     /* Otherwise, we need to check that we are not
> violating the
> @@ -4330,7 +4331,8 @@ Call_to_gnu (Node_Id gnat_node, tree
> *gnu_result_type_p, tree gnu_target,
>    /* If the access type doesn't require foreign-compatible
> representation,
>    be prepared for descriptors.  */
>    if (targetm.calls.custom_function_descriptors > 0
> -   && Can_Use_Internal_Rep (Etype (Prefix (Name
> (gnat_node)
> +   && Can_Use_Internal_Rep (Etype (Prefix (Name
> (gnat_node
> +  && (flag_trampolines != 1))
>   by_descriptor = true;
>  }
>    else if (Nkind (Name (gnat_node)) == N_Attribute_Reference)
> diff --git a/gcc/c/ChangeLog b/gcc/c/ChangeLog
> index 708ef5d7da2..62823ccf5c7 100644
> --- a/gcc/c/ChangeLog
> +++ b/gcc/c/ChangeLog
> @@ -1,3 +1,10 @@
> +2018-11-03  Martin Uecker  
> +
> + * c-objc-common.h: Define
> LANG_HOOKS_CUSTOM_FUNCTION_DESCRIPTORS.
> + * c-typeck.c (function_to_pointer_conversion): If using
> descriptors
> + instead of trampolines, amend function address with
> + FUNC_ADDR_BY_DESCRIPTOR and calls with
> ALL_EXPR_BY_DESCRIPTOR.
> +
>  2018-10-29  David Malcolm  
>  
>   * c-decl.c (implicit_decl_warning): Update "is there a
> suggestion"
> diff --git a/gcc/c/c-objc-common.h b/gcc/c/c-objc-common.h
> index 78e768c2366..ef039560eb9 100644
> --- a/gcc/c/c-objc-common.h
> +++ b/gcc/c/c-objc-common.h
> @@ -110,4 +110,7 @@ along with GCC; see the file COPYING3.  If not
> see
>  
>  #undef LANG_HOOKS_TREE_INLINING_VAR_MOD_TYPE_P
>  #define LANG_HOOKS_TREE_INLINING_VAR_MOD_TYPE_P c_vla_unspec_p
> +
> +#undef LANG_HOOKS_CUSTOM_FUNCTION_DESCRIPTORS
> +#define LANG_HOOKS_CUSTOM_FUNCTION_DESCRIPTORS true
>  #endif /* GCC_C_OBJC_COMMON */
> diff --git a/gcc/c/c-typeck.c b/gcc/c/c-typeck.c
> index 9d09b8d65fd..afae9de41e7 100644
> --- a/gcc/c/c-typeck.c
> +++ b/gcc/c/c-typeck.c
> @@ -1912,7 +1912,13 @@ function_to_pointer_conversion (location_t
> loc, tree exp)
>    if (TREE_NO_WARNING (orig_exp))
>  TREE_NO_WARNING (exp) = 1;
>  
> -  return build_unary_op (loc, ADDR_EXPR, exp, false);
> +  tree r = build_unary_op (loc, ADDR_EXPR, exp, false);
> +
> +  if ((TREE_CODE(r) == ADDR_EXPR)
> +  && (flag_trampolines == 0))
> + FUNC_ADDR_BY_DESCRIPTOR (r) = 1;
> +
> +  return r;
>  }
>  
>  /* Mark EXP as read, not just set, for set but not used -Wunused
> @@ -3134,6 +3140,11 @@ build_function_call_vec (location_t loc,
> vec arg_loc,
>    else
>  result = build_call_array_loc (loc, TREE_TYPE (fntype),
>   

Re: RFA/RFC: Add stack recursion limit to libiberty's demangler [v3]

[Richard Biener]

On Fri, Nov 30, 2018 at 6:41 PM Nick Clifton  wrote:
>
> Hi Guys,
>
> >> I think it would be fine to have a large fixed limit plus a flag to
> >> disable the limit.
>
> Great - in which case please may I present version 3 of the patch.  In
> this version:
>
>   * The cplus_demangle_set_recursion_limit() function has been removed
> and instead a new constant - DEMANGLE_RECURSION_LIMIT - is defined in
> demangle.h.
>
>   * The recursion counters in cp-demangle.c have been merged into one
> counter, now contained in the d_info structure.
>
>   * In cplus-dem.c the recursion counter has been moved into the work
> structure.
>
>   * The description of the DMGL_RECURSE_LIMIT option in demangle.h has
> been enhanced to add a note that if the option is not used, then
> bug reports about stack overflows in the demangler will be rejected.

Shouldn't we make it fool-proof by instead introducing a DMGL_NO_RECURSION_LIMIT
flag and when not set default to limiting recursion?

>   * The binutils patch has been updated to reflect these changes.  The
> addr2line, cxxfilt, nm and objdump programs now have two new options
> --recurse-limit and --no-recurse-limit, with --recurse-limit being
> the default.  The documentation is updated to describe these options
> and to also add a note about bug reports being rejected if
> --no-recurse-limit is used.
>
> What do you think, is this version acceptable ?
>
> Cheers
>   Nick
>
> libiberty/ChangeLog
> 2018-11-29  Nick Clifton  
>
> PR 87681
> PR 87675
> PR 87636
> PR 87335
> * cp-demangle.h (struct d_info): Add recursion_limit field.
> * cp-demangle.c (d_function_type): If the recursion limit is
> enabled and reached, return with a failure result.
> (d_demangle_callback): If the recursion limit is enabled, check
> for a mangled string that is so long that there is not enough
> stack space for the local arrays.
> * cplus-dem.c (struct work): Add recursion_level field.
> (demangle_nested_args): If the recursion limit is enabled and
> reached, return with a failure result.
>
> include/ChangeLog
> 2018-11-29  Nick Clifton  
>
> * demangle.h (DMGL_RECURSE_LIMIT): Define.
> (DEMANGLE_RECURSION_LIMIT): Prototype.
>
> binutils/ChangeLog
> 2018-11-29  Nick Clifton  
>
> * addr2line.c (demangle_flags): New static variable.
> (long_options): Add --recurse-limit and --no-recurse-limit.
> (translate_address): Pass demangle_flags to bfd_demangle.
> (main): Handle --recurse-limit and --no-recurse-limit options.
> * cxxfilt.c (flags): Add DMGL_RECURSE_LIMIT.
> (long_options): Add --recurse-limit and --no-recurse-limit.
> (main): Handle new options.
> * dlltool.c (gen_def_file): Include DMGL_RECURSE_LIMIT in flags
> passed to cplus_demangle.
> * nm.c (demangle_flags): New static variable.
> (long_options): Add --recurse-limit and --no-recurse-limit.
> (main): Handle new options.
> * objdump.c (demangle_flags): New static variable.
> (usage): Add --recurse-limit and --no-recurse-limit.
> (long_options): Likewise.
> (objdump_print_symname): Pass demangle_flags to bfd_demangle.
> (disassemble_section): Likewise.
> (dump_dymbols): Likewise.
> (main): Handle new options.
> * prdbg.c (demangle_flags): New static variable.
> (tg_variable): Pass demangle_flags to demangler.
> (tg_start_function): Likewise.
> * stabs.c (demangle_flags): New static variable.
> (stab_demangle_template): Pass demangle_flags to demangler.
> (stab_demangle_v3_argtypes): Likewise.
> (stab_demangle_v3_arg): Likewise.
> * doc/binutuls.texi: Document new command line options.
> * NEWS: Mention the new feature.
> * testsuite/config/default.exp (CXXFILT): Define if not already
> defined.
> (CXXFILTFLAGS): Likewise.
> * testsuite/binutils-all/cxxfilt.exp: New file.  Runs a few
> simple tests of the cxxfilt program.

Re: [RFC][AArch64] Add support for system register based stack protector canary access

[Ramana Radhakrishnan]

On 03/12/2018 09:59, Jakub Jelinek wrote:
> On Mon, Dec 03, 2018 at 09:55:36AM +, Ramana Radhakrishnan wrote:
>> +  if (aarch64_stack_protector_guard == SSP_GLOBAL
>> +  && opts->x_aarch64_stack_protector_guard_offset_str)
>> +{
>> +  error ("Incompatible options -mstack-protector-guard=global and"
> 
> Diagnostic messages shouldn't start with capital letters (3 times in the
> patch), unless it is something that is capitalized always, even in the
> middle of sentences (say GNU etc.).
> 
>   Jakub
> 
Sorry - will fix in next iteration.

Ramana

Re: [RFC][AArch64] Add support for system register based stack protector canary access

[Jakub Jelinek]

On Mon, Dec 03, 2018 at 09:55:36AM +, Ramana Radhakrishnan wrote:
> +  if (aarch64_stack_protector_guard == SSP_GLOBAL
> +  && opts->x_aarch64_stack_protector_guard_offset_str)
> +{
> +  error ("Incompatible options -mstack-protector-guard=global and"

Diagnostic messages shouldn't start with capital letters (3 times in the
patch), unless it is something that is capitalized always, even in the
middle of sentences (say GNU etc.).

Jakub

[RFC][AArch64] Add support for system register based stack protector canary access

[Ramana Radhakrishnan]

For quite sometime the kernel guys, (more specifically Ard) have been 
talking about using a system register (sp_el0) and an offset from that 
for a canary based access. This patchset adds support for a new set of
command line options similar to how powerpc has done this.

I don't intend to change the defaults in userland, we've discussed this 
for user-land in the past and as far as glibc and userland is concerned 
we stick to the options as currently existing. The system register 
option is really for the kernel to use along with an offset as they 
control their ABI and this is a decision for them to make.

I did consider sticking this all under a mcmodel=kernel-small option but
thought that would be a bit too aggressive. There is very little error
checking I can do in terms of the system register being used and really
the assembler would barf quite quickly in case things go wrong. I've
managed to rebuild Ard's kernel tree with an additional patch that
I will send to him. I haven't managed to boot this kernel.

There was an additional question asked about the performance 
characteristics of this but it's a security feature and the kernel 
doesn't have the luxury of a hidden symbol. Further since the kernel 
uses sp_el0 for access everywhere and if they choose to use the same 
register I don't think the performance characteristics would be too bad, 
but that's a decision for the kernel folks to make when taking in the 
feature into the kernel.

I still need to add some tests and documentation in invoke.texi but
this is at the stage where it would be nice for some other folks
to look at this.

The difference in code generated is as below.

extern void bar (char *);
int foo (void)
{
   char a[100];
   bar ();
}

$GCC -O2  -fstack-protector-strong  vs 
-mstack-protector-guard-reg=sp_el0 -mstack-protector-guard=sysreg 
-mstack-protector-guard-offset=1024 -fstack-protector-strong


--- tst.s   2018-12-03 09:46:21.174167443 +
+++ tst.s.1 2018-12-03 09:46:03.546257203 +
@@ -15,15 +15,14 @@
mov x29, sp
str x19, [sp, 16]
.cfi_offset 19, -128
-   adrpx19, __stack_chk_guard
-   add x19, x19, :lo12:__stack_chk_guard
-   ldr x0, [x19]
-   str x0, [sp, 136]
-   mov x0,0
+   mrs x19, sp_el0
add x0, sp, 32
+   ldr x1, [x19, 1024]
+   str x1, [sp, 136]
+   mov x1,0
bl  bar
ldr x0, [sp, 136]
-   ldr x1, [x19]
+   ldr x1, [x19, 1024]
eor x1, x0, x1
cbnzx1, .L5




I will be afk tomorrow and day after but this is to elicit some comments 
and for Ard to try this out with his kernel patches.

Thoughts ?

regards
Ramana

gcc/ChangeLog:

2018-11-23  Ramana Radhakrishnan  

 * config/aarch64/aarch64-opts.h (enum stack_protector_guard): New
 * config/aarch64/aarch64.c (aarch64_override_options_internal): 
Handle
 and put in error checks for stack protector guard options.
 (aarch64_stack_protect_guard): New.
 (TARGET_STACK_PROTECT_GUARD): Define.
 * config/aarch64/aarch64.md (UNSPEC_SSP_SYSREG): New.
 (reg_stack_protect_address): New.
 (stack_protect_set): Adjust for SSP_GLOBAL.
 (stack_protect_test): Likewise.
 * config/aarch64/aarch64.opt (-mstack-protector-guard-reg): New.
 (-mstack-protector-guard): Likewise.
 (-mstack-protector-guard-offset): Likewise.
 * doc/invoke.texi: Document new AArch64 options.
commit 9febaa23c114e598ddc9a2406ad96d8fa3ebe0c6
Author: Ramana Radhakrishnan 
Date:   Mon Nov 19 10:12:12 2018 +


diff --git a/gcc/config/aarch64/aarch64-opts.h 
b/gcc/config/aarch64/aarch64-opts.h
index 7a5c6d7664f..2f06f3e0e5a 100644
--- a/gcc/config/aarch64/aarch64-opts.h
+++ b/gcc/config/aarch64/aarch64-opts.h
@@ -91,4 +91,10 @@ enum aarch64_sve_vector_bits_enum {
   SVE_2048 = 2048
 };
 
+/* Where to get the canary for the stack protector.  */
+enum stack_protector_guard {
+  SSP_SYSREG,  /* per-thread canary in special system register 
*/
+  SSP_GLOBAL   /* global canary */
+};
+
 #endif
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 0d89ba27e4a..a56b2166542 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -10955,6 +10955,41 @@ aarch64_override_options_internal (struct gcc_options 
*opts)
   if (opts->x_flag_strict_volatile_bitfields < 0 && abi_version_at_least (2))
 opts->x_flag_strict_volatile_bitfields = 1;
 
+  if (aarch64_stack_protector_guard == SSP_GLOBAL
+  && opts->x_aarch64_stack_protector_guard_offset_str)
+{
+  error ("Incompatible options -mstack-protector-guard=global and"
+"-mstack-protector-guard-offset=%qs",
+aarch64_stack_protector_guard_offset_str);
+}
+
+  if (aarch64_stack_protector_guard == SSP_SYSREG
+  && 

Re: [ARM/FDPIC v4 00/20] FDPIC ABI for ARM

[Christophe Lyon]

Ping?

The series started here:
https://gcc.gnu.org/ml/gcc-patches/2018-11/msg01464.html

Thanks,

Christophe

On Mon, 26 Nov 2018 at 11:14, Christophe Lyon
 wrote:
>
> Ping?
>
> Thanks
>
> On Fri, 16 Nov 2018 at 16:48, Christophe Lyon  wrote:
> >
> > From: Christophe Lyon 
> >
> > Hello,
> >
> > This patch series implements the GCC contribution of the FDPIC ABI for
> > ARM targets.
> >
> > This ABI enables to run Linux on ARM MMU-less cores and supports
> > shared libraries to reduce the memory footprint.
> >
> > Without MMU, text and data segments relative distances are different
> > from one process to another, hence the need for a dedicated FDPIC
> > register holding the start address of the data segment. One of the
> > side effects is that function pointers require two words to be
> > represented: the address of the code, and the data segment start
> > address. These two words are designated as "Function Descriptor",
> > hence the "FD PIC" name.
> >
> > On ARM, the FDPIC register is r9 [1], and the target name is
> > arm-uclinuxfdpiceabi. Note that arm-uclinux exists, but uses another
> > ABI and the BFLAT file format; it does not support code sharing.
> > The -mfdpic option is enabled by default, and -mno-fdpic should be
> > used to build the Linux kernel.
> >
> > This work was developed some time ago by STMicroelectronics, and was
> > presented during Linaro Connect SFO15 (September 2015). You can watch
> > the discussion and read the slides [2].
> > This presentation was related to the toolchain published on github [3],
> > which is based on binutils-2.22, gcc-4.7, uclibc-0.9.33.2, gdb-7.5.1
> > and qemu-2.3.0, and for which pre-built binaries are available [3].
> >
> > The ABI itself is described in details in [1].
> >
> > Our Linux kernel patches have been updated and committed by Nicolas
> > Pitre (Linaro) in July 2017. They are required so that the loader is
> > able to handle this new file type. Indeed, the ELF files are tagged
> > with ELFOSABI_ARM_FDPIC. This new tag has been allocated by ARM, as
> > well as the new relocations involved.
> >
> > The binutils, QEMU and uclibc-ng patch series have been merged
> > recently. [4][5][6]
> >
> > This series provides support for architectures that support ARM and/or
> > Thumb-2 and has been tested on arm-linux-gnueabi without regression,
> > as well as arm-uclinuxfdpiceabi, using QEMU. arm-uclinuxfdpiceabi has
> > more failures than arm-linux-gnueabi, but is quite functional.
> >
> > Are the GCC patches OK for inclusion in master?
> >
> > Changes between v3 and v4:
> >
> > - improved documentation (patch 1)
> > - emit an error message (sorry) if the target architecture does not
> >   support arm nor thumb-2 modes (patch 4)
> > - handle Richard's comments on patch 4 (comments, unspec)
> > - added .align directive (patch 5)
> > - fixed use of kernel helpers (__kernel_cmpxchg, __kernel_dmb) (patch 6)
> > - code factorization in patch 7
> > - typos/internal function name in patch 8
> > - improved patch 12
> > - dropped patch 16
> > - patch 20 introduces arm_arch*_thumb_ok effective targets to help
> >   skip some tests
> > - I tested patch 2 on xtensa-buildroot-uclinux-uclibc, it adds many
> >   new tests, but a few regressions
> >   (https://gcc.gnu.org/ml/gcc-patches/2018-11/msg00713.html)
> > - I compiled and executed several LTP tests to exercise pthreads and signals
> > - I wrote and executed a simple testcase to change the interaction
> >   with __kernel_cmpxchg (ie. call the kernel helper rather than use an
> >   implementation in libgcc as requested by Richard)
> >
> > Changes between v2 and v3:
> > - added doc entry for -mfdpic new option
> > - took Kyrill's comments into account (use "Armv7" instead of "7",
> >   code factorization, use preprocessor instead of hard-coding "r9",
> >   remove leftover code for thumb1 support, fixed comments)
> > - rebase over recent trunk
> > - patches with changes: 1, 2 (commit message), 3 (rebase), 4, 6, 7, 9,
> >   14 (rebase), 19 (rebase)
> >
> > Changes between v1 and v2:
> > - fix GNU coding style
> > - exit with an error for pre-Armv7
> > - use ACLE __ARM_ARCH and remove dead code for pre-Armv4
> > - remove unsupported attempts of pre-Armv7/thumb1 support
> > - add instructions in comments next to opcodes
> > - merge patches 11 and 13
> > - fixed protected visibility handling in patch 8
> > - merged legitimize_tls_address_fdpic and
> >   legitimize_tls_address_not_fdpic as requested
> >
> > Thanks,
> >
> > Christophe.
> >
> >
> > [1] https://github.com/mickael-guene/fdpic_doc/blob/master/abi.txt
> > [2] 
> > http://connect.linaro.org/resource/sfo15/sfo15-406-arm-fdpic-toolset-kernel-libraries-for-cortex-m-cortex-r-mmuless-cores/
> > [3] https://github.com/mickael-guene/fdpic_manifest
> > [4] 
> > https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=f1ac0afe481e83c9a33f247b81fa7de789edc4d9
> > [5] 
> > https://git.qemu.org/?p=qemu.git;a=commit;h=e8fa72957419c11984608062c7dcb204a6003a06
> > 

Re: [committed] C++ PATCH to add test for c++/83856

[Christophe Lyon]

On Sat, 1 Dec 2018 at 23:01, Marek Polacek  wrote:
>
> Tested x86_64-linux, applying to trunk.
>
> 2018-12-01  Marek Polacek  
>
> PR c++/83856
> * g++.dg/cpp1y/lambda-generic-83856.C: New test.
>
> diff --git gcc/testsuite/g++.dg/cpp1y/lambda-generic-83856.C 
> gcc/testsuite/g++.dg/cpp1y/lambda-generic-83856.C
> new file mode 100644
> index 000..ab82b6241aa
> --- /dev/null
> +++ gcc/testsuite/g++.dg/cpp1y/lambda-generic-83856.C
> @@ -0,0 +1,30 @@
> +// PR c++/83856
> +// { dg-do compile { target c++14 } }
> +
> +namespace std {
> +template  _Tp declval();
> +template  class initializer_list {
> +  _E *_M_len;
> +
> +public:
> +  unsigned long size;
> +  _E begin();
> +};
> +template  struct array { void operator[](long); };
> +} // namespace std
> +
> +template  struct simd {
> +  static int size();
> +  template  simd(F, decltype(std::declval()(0)) * = nullptr) {}
> +};
> +template 
> +void test_tuples(std::initializer_list> data,
> + F... fun_pack) {
> +  auto it = data.begin();
> +  const int remaining = V::size();
> +  [](...) {}((fun_pack([&](auto) { it[remaining]; }), 0)...);
> +}
> +
> +void f() {
> +  test_tuples>({}, [](simd) {});
> +}

Hi,

This new test fails on arm and other targets according to
gcc-testresults. On arm, I can see:
/gcc/testsuite/g++.dg/cpp1y/lambda-generic-83856.C:6:27: fatal error:
definition of 'class std::initializer_list<_E>' does not match
'#include '
compilation terminated.
compiler exited with status 1
FAIL: g++.dg/cpp1y/lambda-generic-83856.C  -std=c++14 (test for excess errors)


Christophe