[Bug fortran/85796] ICE: Floating point exception

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85796

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-16
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed from 4.3.1.

Re: LTO vs GCC 8

[Richard Biener]

On May 15, 2018 10:12:45 PM GMT+02:00, Freddie Chopin  
wrote:
>On Tue, 2018-05-15 at 21:39 +0200, Freddie Chopin wrote:
>> On Fri, 2018-05-11 at 18:51 +0200, Richard Biener wrote:
>> > As to a workaround for the ld bug you can try keeping all .debug_*
>> > sections. IIRC 2.30 has the bug fixed (on the branch). 
>> 
>> Indeed - "keeping" all the debug sections is a viable alternative.
>> I've
>> found out that it is enough to "keep" just these:
>> 
>>  /* DWARF 2 */
>>  .debug_info 0 : { KEEP(*(.debug_info .gnu.linkonce.wi.*)); }
>>   ...
>>  .debug_frame 0 : { KEEP(*(.debug_frame)); }
>> 
>> I have to check whether debugging something like that is actually
>> possible (; Thanks for the workaround!
>
>Nope, sent it too fast... With these two (three) sections "kept" --gc-
>sections stops working and the executable I get is almost identical to
>the case when I have no --gc-sections at all:
>- lto + --gc-sections, sections "kept" - 133504 ROM + 4196 RAM
>- lto + --gc-sections, sections not "kept" (causes previously mentioned
>errors) - 120288 ROM + 3676 RAM
>- lto, sections not "kept" - 133812 ROM + 4220 RAM
>
>So it seems I have to patiently wait for new binutils if I would like
>to use LTO (;

Build your own (patched) binutils :) 

Richard. 

>Regards,
>FCh

[Bug c++/85795] bad_alloc thrown from allocation function when bad_array_length is expected

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85795

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-16
 Ever confirmed|0   |1

--- Comment #1 from Jason Merrill  ---
Yes, if the expression is erroneous, we should avoid calling the allocation
function.

[Bug c/85800] New: A miscompilation bug with unsigned char

[juneyoung.lee at sf dot snu.ac.kr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85800

Bug ID: 85800
   Summary: A miscompilation bug with unsigned char
   Product: gcc
   Version: 7.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: juneyoung.lee at sf dot snu.ac.kr
  Target Milestone: ---

Created attachment 44136
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44136=edit
A source file that raises the bug.

```
$ cat test-main.c
#include 
#include 
#include 

// If f(A, B + 4) is given, and integer representation of A and B + 4
// are the same, c1 == c2 in the loop becomes true,
// so arr3 = arr1. Hence r = A, and *A should be 10.
// However, if compiled with -O3, *A is still 1.
void store_10_to_p(int *p, int *q) {
  unsigned char arr1[8];
  unsigned char arr2[8];
  unsigned char arr3[8];
  // Type punning with char* is allowed.
  memcpy((unsigned char*)arr1, (unsigned char *), sizeof(p));
  memcpy((unsigned char*)arr2, (unsigned char *), sizeof(q));
  // Now arr1 is p, arr2 is q.

  for (int i = 0; i < sizeof(q); i++) {
int c1 = (int)arr1[i], c2 = (int)arr2[i];
// Note that c1 == c2 is a comparison between _integers_ (not pointers).
if (c1 == c2)
  // Always true if p and q have same integer representation.
  arr3[i] = arr1[i];
else
  arr3[i] = arr2[i];
  }
  // Now arr3 is equivalent to arr1, which is p.
  int *r;
  memcpy(, (unsigned char *)arr3, sizeof(r));
  // Now r is p.
  *p = 1;
  *r = 10;
}

int main() {
  int B[4], A[4];
  printf("%p %p\n", A, [4]);
  store_10_to_p(A, [4]);
  printf("%d\n", A[0]);
  return 0;
}
$ gcc -O3 -o test-main test-main.c
$ ./test-main
0x7fffe5a0 0x7fffe5a0
1
$ gcc -O0 -o test-main test-main.c
$ ./test-main
0x7fffe5b0 0x7fffe5b0
10
```

The output should be 10 because the integral representation of A and B[4] are
the same, but compiling with -O3 gives 1.

[Bug tree-optimization/84774] [meta-bug] bogus/missing -Wrestrict

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84774
Bug 84774 depends on bug 85753, which changed state.

Bug 85753 Summary: missing -Wrestrict on memcpy into a member array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85753

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

[Bug tree-optimization/85753] missing -Wrestrict on memcpy into a member array

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85753

Martin Sebor  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
Version|8.0 |8.1.1
 Resolution|--- |FIXED

--- Comment #3 from Martin Sebor  ---
Fixed by r260280.

Re: [PATCH] improve -Wrestrict for struct members (PR 85753)

[Martin Sebor]

On 05/14/2018 03:21 PM, Jeff Law wrote:

On 05/11/2018 05:09 PM, Martin Sebor wrote:

The attached patch extends -Wrestrict to constrain valid offset
ranges into objects of struct types to the bounds of the object
type, the same way the warning already handles arrays.  This
makes it possible to detect overlapping accesses in cases like
the second call to memcpy below:

  char a[16];

  struct { char a[16]; } x;

  void f (int i, int j)
  {
memcpy ([i], [j], 9);   // -Wrestrict (good)

memcpy ([i], [j], 9);   // missing -Wrestrict
  }

These is no way to copy 9 bytes within a 16 byte array without
either overlap or without accessing memory outside the bounaries
of the object.

This is for GCC 9.

Thanks
Martin

gcc-85753.diff


PR tree-optimization/85753 - missing -Wrestrict on memcpy into a member array

gcc/ChangeLog:

PR tree-optimization/85753
* gimple-ssa-warn-restrict.c (builtin_memref::builtin_memref): Handle
RECORD_TYPE in addition to ARRAY_TYPE.

gcc/testsuite/ChangeLog:

PR tree-optimization/85753
* gcc.dg/Wrestrict-10.c: Adjust.
* gcc.dg/Wrestrict-16.c: New test.

OK.
jeff


It occurred to me that it doesn't matter if the type is an array,
struct, or a basic type like int.  They all should be treated
the same so after retesting I ended up committing a slightly
simplified version of the original: r260280.

Martin

[Bug tree-optimization/85753] missing -Wrestrict on memcpy into a member array

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85753

--- Comment #2 from Martin Sebor  ---
Author: msebor
Date: Wed May 16 02:30:38 2018
New Revision: 260280

URL: https://gcc.gnu.org/viewcvs?rev=260280=gcc=rev
Log:
PR tree-optimization/85753 - missing -Wrestrict on memcpy into a member array

gcc/ChangeLog:

PR tree-optimization/85753
* gimple-ssa-warn-restrict.c (builtin_memref::builtin_memref): Handle
RECORD_TYPE in addition to ARRAY_TYPE.

gcc/testsuite/ChangeLog:

PR tree-optimization/85753
* gcc.dg/Wrestrict-10.c: Adjust.
* gcc.dg/Wrestrict-16.c: New test.


Added:
trunk/gcc/testsuite/gcc.dg/Wrestrict-16.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-ssa-warn-restrict.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/Wrestrict-10.c

[Bug c++/58407] [C++11] Should warn about deprecated implicit generation of copy constructor/assignment

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58407

Jason Merrill  changed:

   What|Removed |Added

  Attachment #43637|0   |1
is obsolete||

--- Comment #14 from Jason Merrill  ---
Created attachment 44135
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44135=edit
updated patch

Here's an updated implementation, which is limited to -Wall, so it doesn't
affect the building or testing of the library.  I'm sure you will still want to
adjust the library to avoid warnings when users try to build with -Wall.

On looking more closely at some of the places I was getting warnings in the
compiler, I noticed that they often seemed to be actual errors.  For instance,
if someone copies an aa_tree and then destroys one of the aa_trees, the other
is left with a pointer to garbage.

I also realized that we want to avoid warning when the copy is elided,
particularly given C++17 mandatory copy elision; if the prvalue directly
initializes a variable, there's no problematic copying.

An interesting subcategory I noticed when I had the warning on by default is
classes with a virtual destructor, such as the exception hierarchy.  The
warning calls attention to potential slicing problems, and so I think we don't
want to add defaulted copy ops; it's good for users to be encouraged to e.g.
catch by reference.

[Bug c++/85714] -Wimplicit-fallthrough and nested exhaustive switch statements with enum classes and return

[rs2740 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85714

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #2 from TC  ---
A variable of scoped enumeration type can hold any value of its underlying type
(int in this case) and is not limited to the value of the enumerators. 

The warning seems reasonable.

RFA (tree.c): PATCH to make warn_deprecated_use return bool

[Jason Merrill]

The function "warning" returns bool to indicated whether or not any
diagnostic was actually emitted; warn_deprecated_use should as well.

It's also unnecessary to duplicate the warning code between the cases
of null or non-null "decl", since the actual warnings were the same.
The only thing that's different is whether we indicate the source
location of "decl".

Tested x86_64-pc-linux-gnu.  OK for trunk?
commit b49f292814693de97b218f6d8b32b20dd68fb8c8
Author: Jason Merrill 
Date:   Tue May 15 17:41:19 2018 -0400

* tree.c (warn_deprecated_use): Return bool.  Simplify logic.

diff --git a/gcc/tree.c b/gcc/tree.c
index 77a73b4495e..68165f4deed 100644
--- a/gcc/tree.c
+++ b/gcc/tree.c
@@ -12420,14 +12420,16 @@ typedef_variant_p (const_tree type)
   return is_typedef_decl (TYPE_NAME (type));
 }
 
-/* Warn about a use of an identifier which was marked deprecated.  */
-void
+/* Warn about a use of an identifier which was marked deprecated.  Returns
+   whether a warning was given.  */
+
+bool
 warn_deprecated_use (tree node, tree attr)
 {
   const char *msg;
 
   if (node == 0 || !warn_deprecated_decl)
-return;
+return false;
 
   if (!attr)
 {
@@ -12450,7 +12452,7 @@ warn_deprecated_use (tree node, tree attr)
   else
 msg = NULL;
 
-  bool w;
+  bool w = false;
   if (DECL_P (node))
 {
   if (msg)
@@ -12476,49 +12478,29 @@ warn_deprecated_use (tree node, tree attr)
 	what = DECL_NAME (TYPE_NAME (node));
 	}
 
-  if (decl)
+  if (what)
 	{
-	  if (what)
-	{
-	  if (msg)
-		w = warning (OPT_Wdeprecated_declarations,
-			 "%qE is deprecated: %s", what, msg);
-	  else
-		w = warning (OPT_Wdeprecated_declarations,
-			 "%qE is deprecated", what);
-	}
+	  if (msg)
+	w = warning (OPT_Wdeprecated_declarations,
+			 "%qE is deprecated: %s", what, msg);
 	  else
-	{
-	  if (msg)
-		w = warning (OPT_Wdeprecated_declarations,
-			 "type is deprecated: %s", msg);
-	  else
-		w = warning (OPT_Wdeprecated_declarations,
-			 "type is deprecated");
-	}
-	  if (w)
-	inform (DECL_SOURCE_LOCATION (decl), "declared here");
+	w = warning (OPT_Wdeprecated_declarations,
+			 "%qE is deprecated", what);
 	}
   else
 	{
-	  if (what)
-	{
-	  if (msg)
-		warning (OPT_Wdeprecated_declarations, "%qE is deprecated: %s",
-			 what, msg);
-	  else
-		warning (OPT_Wdeprecated_declarations, "%qE is deprecated", what);
-	}
+	  if (msg)
+	w = warning (OPT_Wdeprecated_declarations,
+			 "type is deprecated: %s", msg);
 	  else
-	{
-	  if (msg)
-		warning (OPT_Wdeprecated_declarations, "type is deprecated: %s",
-			 msg);
-	  else
-		warning (OPT_Wdeprecated_declarations, "type is deprecated");
-	}
+	w = warning (OPT_Wdeprecated_declarations,
+			 "type is deprecated");
 	}
+  if (w && decl)
+	inform (DECL_SOURCE_LOCATION (decl), "declared here");
 }
+
+  return w;
 }
 
 /* Return true if REF has a COMPONENT_REF with a bit-field field declaration
diff --git a/gcc/tree.h b/gcc/tree.h
index 74a0d1881a6..ef8bff405fe 100644
--- a/gcc/tree.h
+++ b/gcc/tree.h
@@ -4828,7 +4828,7 @@ extern tree tree_strip_sign_nop_conversions (tree);
 extern const_tree strip_invariant_refs (const_tree);
 extern tree lhd_gcc_personality (void);
 extern void assign_assembler_name_if_needed (tree);
-extern void warn_deprecated_use (tree, tree);
+extern bool warn_deprecated_use (tree, tree);
 extern void cache_integer_cst (tree);
 extern const char *combined_fn_name (combined_fn);
 

RFA (ipa-prop): PATCHes to avoid use of deprecated copy ctor and op=

[Jason Merrill]

In C++11 and up, the implicitly-declared copy constructor and
assignment operator are deprecated if one of them, or the destructor,
is user-provided.  Implementing that in G++ turned up a few dodgy uses
in the compiler.

In general it's unsafe to copy an ipa_edge_args, because if one of the
pointers is non-null you get two copies of a vec pointer, and when one
of the objects is destroyed it frees the vec and leaves the other
object pointing to freed memory.  This specific example is safe
because it only copies from an object with null pointers, but it would
be better to avoid the copy.  OK for trunk?

It's unsafe to copy a releasing_vec for the same reason.  There are a
few places where the copy constructor is nominally used to initialize
a releasing_vec variable from a temporary returned from a function; in
these cases no actual copy is done, and the function directly
initializes the variable, so it's safe.  I made this clearer by
declaring the copy constructor but not defining it, so uses that get
elided are accepted, but uses that actually want to copy will fail to
link.

In cp_expr we defined the copy constructor to do the same thing that
the implicit definition would do, causing the copy assignment operator
to be deprecated.  We don't need the copy constructor, so let's remove
it.

Tested x86_64-pc-linux-gnu.  Are the ipa-prop bits OK for trunk?
commit 560b104324b10814dcaaf65606943d4ca55647d6
Author: Jason Merrill 
Date:   Tue May 15 20:47:41 2018 -0400

* ipa-prop.h (ipa_edge_args::release): Factor out of destructor.

* ipa-prop.c (ipa_free_edge_args_substructures): Use it.

diff --git a/gcc/ipa-prop.c b/gcc/ipa-prop.c
index 38441cc49bc..11bbf356ce1 100644
--- a/gcc/ipa-prop.c
+++ b/gcc/ipa-prop.c
@@ -3714,8 +3714,7 @@ ipa_check_create_edge_args (void)
 void
 ipa_free_edge_args_substructures (struct ipa_edge_args *args)
 {
-  vec_free (args->jump_functions);
-  *args = ipa_edge_args ();
+  args->release ();
 }
 
 /* Free all ipa_edge structures.  */
diff --git a/gcc/ipa-prop.h b/gcc/ipa-prop.h
index a61e06135e3..08919acb46c 100644
--- a/gcc/ipa-prop.h
+++ b/gcc/ipa-prop.h
@@ -569,13 +569,18 @@ class GTY((for_user)) ipa_edge_args
   ipa_edge_args () : jump_functions (NULL), polymorphic_call_contexts (NULL)
 {}
 
-  /* Destructor.  */
-  ~ipa_edge_args ()
+  void release ()
 {
   vec_free (jump_functions);
   vec_free (polymorphic_call_contexts);
 }
 
+  /* Destructor.  */
+  ~ipa_edge_args ()
+{
+  release ();
+}
+
   /* Vectors of the callsite's jump function and polymorphic context
  information of each parameter.  */
   vec *jump_functions;
commit 648ffd02e23ac2695de04ab266b4f8862df6c2ed
Author: Jason Merrill 
Date:   Tue May 15 20:46:54 2018 -0400

* cp-tree.h (cp_expr): Remove copy constructor.

* mangle.c (struct releasing_vec): Declare copy constructor.

diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index 9a2eb3be4d1..cab926028b8 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -59,9 +59,6 @@ public:
   cp_expr (tree value, location_t loc):
 m_value (value), m_loc (loc) {}
 
-  cp_expr (const cp_expr ) :
-m_value (other.m_value), m_loc (other.m_loc) {}
-
   /* Implicit conversions to tree.  */
   operator tree () const { return m_value; }
   tree & operator* () { return m_value; }
diff --git a/gcc/cp/mangle.c b/gcc/cp/mangle.c
index 6a7df804caf..59a3111fba2 100644
--- a/gcc/cp/mangle.c
+++ b/gcc/cp/mangle.c
@@ -1555,6 +1555,10 @@ struct releasing_vec
   releasing_vec (vec_t *v): v(v) { }
   releasing_vec (): v(make_tree_vector ()) { }
 
+  /* Copy constructor is deliberately declared but not defined,
+ copies must always be elided.  */
+  releasing_vec (const releasing_vec &);
+
   vec_t * () const { return *v; }
   vec_t *operator-> () const { return v; }
   vec_t *get () const { return v; }

[Bug tree-optimization/78969] bogus snprintf truncation warning due to missing range info

[john at jlindgren dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78969

John Lindgren  changed:

   What|Removed |Added

 CC||john at jlindgren dot net

--- Comment #11 from John Lindgren  ---
I think I am hitting the same issue in 8.1.0.  Input ranges are thoroughly
checked in the below code, and there is no possibility of truncation, yet a
warning is emitted.

>From reading this and other reports, it seems to come down to random chance
whether -Wformat-truncation is reliable or not, as it depends on range data in
the optimizer that was never intended for error-checking diagnostics.

Can you please remove -Wformat-truncation from -Wall until it actually works?

#include 

void format_time (char buf[7], int time)
{
if (time < 0) time = 0;
if (time > 359) time = 359;

if (time < 6000)
snprintf (buf, 7, " %02d:%02d", time / 60, time % 60);
else if (time < 6)
snprintf (buf, 7, "%3d:%02d", time / 60, time % 60);
else
snprintf (buf, 7, "%3d:%02d", time / 3600, time / 60 % 60);
}

$ gcc -Wall -O2 -c test.c
test.c: In function ‘format_time’:
test.c:11:32: warning: ‘%02d’ directive output may be truncated writing 2 bytes
into a region of size between 1 and 3 [-Wformat-truncation=]
 snprintf (buf, 7, "%3d:%02d", time / 60, time % 60);
^~~~
test.c:11:27: note: directive argument in the range [0, 59]
 snprintf (buf, 7, "%3d:%02d", time / 60, time % 60);
   ^~
test.c:11:9: note: ‘snprintf’ output between 7 and 9 bytes into a destination
of size 7
 snprintf (buf, 7, "%3d:%02d", time / 60, time % 60);
 ^~~

C++ PATCH to make cxx_eval_vec_init_1 respect the quiet flag

[Jason Merrill]

While working on something else I noticed that this function was
generating warnings when it's supposed to be quiet.

Tested x86_64-pc-linux-gnu, applied to trunk.
commit ea990203b6a7562e399c22ffd70e7391106d6dc5
Author: Jason Merrill 
Date:   Tue May 15 15:30:43 2018 -0400

* constexpr.c (cxx_eval_vec_init_1): Pass tf_none if ctx->quiet.

diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
index 9ee37de88d3..8c6ec555ca9 100644
--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -2936,6 +2936,7 @@ cxx_eval_vec_init_1 (const constexpr_ctx *ctx, tree atype, tree init,
   vec **p = _ELTS (ctx->ctor);
   bool pre_init = false;
   unsigned HOST_WIDE_INT i;
+  tsubst_flags_t complain = ctx->quiet ? tf_none : tf_warning_or_error;
 
   /* For the default constructor, build up a call to the default
  constructor of the element type.  We only need to handle class types
@@ -2946,7 +2947,7 @@ cxx_eval_vec_init_1 (const constexpr_ctx *ctx, tree atype, tree init,
 /* We only do this at the lowest level.  */;
   else if (value_init)
 {
-  init = build_value_init (elttype, tf_warning_or_error);
+  init = build_value_init (elttype, complain);
   pre_init = true;
 }
   else if (!init)
@@ -2954,7 +2955,7 @@ cxx_eval_vec_init_1 (const constexpr_ctx *ctx, tree atype, tree init,
   vec *argvec = make_tree_vector ();
   init = build_special_member_call (NULL_TREE, complete_ctor_identifier,
 	, elttype, LOOKUP_NORMAL,
-	tf_warning_or_error);
+	complain);
   release_tree_vector (argvec);
   init = build_aggr_init_expr (TREE_TYPE (init), init);
   pre_init = true;
@@ -2981,8 +2982,7 @@ cxx_eval_vec_init_1 (const constexpr_ctx *ctx, tree atype, tree init,
 	  reuse = i == 0;
 	}
 	  else
-	eltinit = cp_build_array_ref (input_location, init, idx,
-	  tf_warning_or_error);
+	eltinit = cp_build_array_ref (input_location, init, idx, complain);
 	  eltinit = cxx_eval_vec_init_1 (_ctx, elttype, eltinit, value_init,
 	 lval,
 	 non_constant_p, overflow_p);
@@ -3000,11 +3000,10 @@ cxx_eval_vec_init_1 (const constexpr_ctx *ctx, tree atype, tree init,
 	  /* Copying an element.  */
 	  gcc_assert (same_type_ignoring_top_level_qualifiers_p
 		  (atype, TREE_TYPE (init)));
-	  eltinit = cp_build_array_ref (input_location, init, idx,
-	tf_warning_or_error);
+	  eltinit = cp_build_array_ref (input_location, init, idx, complain);
 	  if (!lvalue_p (init))
 	eltinit = move (eltinit);
-	  eltinit = force_rvalue (eltinit, tf_warning_or_error);
+	  eltinit = force_rvalue (eltinit, complain);
 	  eltinit = cxx_eval_constant_expression (_ctx, eltinit, lval,
 		  non_constant_p, overflow_p);
 	}

[Bug libstdc++/78870] Support std::filesystem on Windows

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78870

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
   Target Milestone|--- |9.0

Re: [PATCH, rs6000] Fix expected BE counts for vsx-vector-6.h

[Segher Boessenkool]

Hi Carl,

On Tue, May 15, 2018 at 01:43:18PM -0700, Carl Love wrote:
>   * gcc.target/powerpc/vsx-vector-6-be.c: Remove file

Full stop.

>   * gcc.target/powerpc/vsx-vector-6-be.p7.c (dg-final): New test file for
>   Power 7.

The whole file is new, so just
* gcc.target/powerpc/vsx-vector-6-be.p7.c: New test file for Power 7.
or even
* gcc.target/powerpc/vsx-vector-6-be.p7.c: New test.

>   * gcc.target/powerpc/vsx-vector-6-le.c (dg-final): Update counts for
>   .xvcmpeqdp., xvcmpgtdp., xvcmpgedp., xxlxor, xvrdpi.

Stray leading dot on this last line?

Okay for trunk, thanks!


Segher

Re: [PR63185][RFC] Improve DSE with branches

[Kugan Vivekanandarajah]

Hi Richard,

On 15 May 2018 at 19:20, Richard Biener  wrote:
> On Tue, 15 May 2018, Richard Biener wrote:
>
>> On Mon, 14 May 2018, Kugan Vivekanandarajah wrote:
>>
>> > Hi,
>> >
>> > Attached patch handles PR63185 when we reach PHI with temp != NULLL.
>> > We could see the PHI and if there isn't any uses for PHI that is
>> > interesting, we could ignore that ?
>> >
>> > Bootstrapped and regression tested on x86_64-linux-gnu.
>> > Is this OK?
>>
>> No, as Jeff said we can't do it this way.
>>
>> If we end up with multiple VDEFs in the walk of defvar immediate
>> uses we know we are dealing with a CFG fork.  We can't really
>> ignore any of the paths but we have to
>>
>>  a) find the merge point (and the associated VDEF)
>>  b) verify for each each chain of VDEFs with associated VUSEs
>> up to that merge VDEF that we have no uses of the to classify
>> store and collect (partial) kills
>>  c) intersect kill info and continue walking from the merge point
>>
>> in b) there's the optional possibility to find sinking opportunities
>> in case we have kills on some paths but uses on others.  This is why
>> DSE should be really merged with (store) sinking.
>>
>> So if we want to enhance DSEs handling of branches then we need
>> to refactor the simple dse_classify_store function.  Let me take
>> an attempt at this today.
>
> First (baby) step is the following - it arranges to collect the
> defs we need to continue walking from and implements trivial
> reduction by stopping at (full) kills.  This allows us to handle
> the new testcase (which was already handled in the very late DSE
> pass with the help of sinking the store).

Thanks for the explanation and thanks for working on this.

>
> I took the opportunity to kill the use_stmt parameter of
> dse_classify_store as the only user is only looking for whether
> the kills were all clobbers which I added a new parameter for.
>
> I didn't adjust the byte-tracking case fully (I'm not fully understanding
> the code in the case of a use and I'm not sure whether it's worth
> doing the def reduction with byte-tracking).

Since byte tracking is tracking the killed subset of bytes in the
original def, in your patch can we calculate the bytes killed by each
defs[i] and then find the intersection for the iteration. If we don't
have complete kill, we can use this to set live bytes and iterate till
all the live_bytes are cleared like it was done earlier.

Thanks,
Kugan

>
> Your testcase can be handled by reducing the PHI and the call def
> by seeing that the only use of a candidate def is another def
> we have already processed.  Not sure if worth special-casing though,
> I'd rather have a go at "recursing".  That will be the next
> patch.
>
> Bootstrap & regtest running on x86_64-unknown-linux-gnu.
>
> Richard.
>
> 2018-05-15  Richard Biener  
>
> * tree-ssa-dse.c (dse_classify_store): Remove use_stmt parameter,
> add by_clobber_p one.  Change algorithm to collect all defs
> representing uses we need to walk and try reducing them to
> a single one before failing.
> (dse_dom_walker::dse_optimize_stmt): Adjust.
>
> * gcc.dg/tree-ssa/ssa-dse-31.c: New testcase.
>
> diff --git a/gcc/testsuite/gcc.dg/tree-ssa/ssa-dse-31.c 
> b/gcc/testsuite/gcc.dg/tree-ssa/ssa-dse-31.c
> new file mode 100644
> index 000..9ea9268fe1d
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/tree-ssa/ssa-dse-31.c
> @@ -0,0 +1,16 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O -fdump-tree-dse1-details" } */
> +
> +void g();
> +void f(int n, char *p)
> +{
> +  *p = 0;
> +  if (n)
> +{
> +  *p = 1;
> +  g();
> +}
> +  *p = 2;
> +}
> +
> +/* { dg-final { scan-tree-dump-times "Deleted dead store" 1 "dse1" } } */
> diff --git a/gcc/tree-ssa-dse.c b/gcc/tree-ssa-dse.c
> index 9220fea7f2e..126592a1d13 100644
> --- a/gcc/tree-ssa-dse.c
> +++ b/gcc/tree-ssa-dse.c
> @@ -516,18 +516,21 @@ live_bytes_read (ao_ref use_ref, ao_ref *ref, sbitmap 
> live)
>  }
>
>  /* A helper of dse_optimize_stmt.
> -   Given a GIMPLE_ASSIGN in STMT that writes to REF, find a candidate
> -   statement *USE_STMT that may prove STMT to be dead.
> -   Return TRUE if the above conditions are met, otherwise FALSE.  */
> +   Given a GIMPLE_ASSIGN in STMT that writes to REF, classify it
> +   according to downstream uses and defs.  Sets *BY_CLOBBER_P to true
> +   if only clobber statements influenced the classification result.
> +   Returns the classification.  */
>
>  static dse_store_status
> -dse_classify_store (ao_ref *ref, gimple *stmt, gimple **use_stmt,
> -   bool byte_tracking_enabled, sbitmap live_bytes)
> +dse_classify_store (ao_ref *ref, gimple *stmt,
> +   bool byte_tracking_enabled, sbitmap live_bytes,
> +   bool *by_clobber_p = NULL)
>  {
>gimple *temp;
>unsigned cnt = 0;
>
> -  *use_stmt = NULL;
> +  if (by_clobber_p)
> +*by_clobber_p = true;
>
>/* Find 

[Bug c++/64372] [DR1560] Gratuitous lvalue-to-rvalue conversion in conditional-expression with throw-expression operand

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64372

--- Comment #10 from Jason Merrill  ---
Author: jason
Date: Tue May 15 21:56:29 2018
New Revision: 260272

URL: https://gcc.gnu.org/viewcvs?rev=260272=gcc=rev
Log:
PR c++/64372 - CWG 1560, gratuitous lvalue-rvalue conversion in ?:

* call.c (build_conditional_expr_1): Don't force_rvalue when one arm
is a throw-expression.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/dr1560.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c

C++ PATCH for c++/64372/DR 1560, value category of ?: with one throw

[Jason Merrill]

DR 1560 in C++14 fixed this rule to not do a gratuitous lvalue-rvalue
conversion in this case.

Tested x86_64-pc-linux-gnu, applying to trunk.
commit c7b8b79f72865740ead84aa602a6bc8651a60a93
Author: Jason Merrill 
Date:   Tue May 15 15:46:51 2018 -0400

PR c++/64372 - CWG 1560, gratuitous lvalue-rvalue conversion in ?:

* call.c (build_conditional_expr_1): Don't force_rvalue when one arm
is a throw-expression.

diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index f620c0d86e8..09a3618b007 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -4969,56 +4969,33 @@ build_conditional_expr_1 (location_t loc, tree arg1, tree arg2, tree arg3,
   arg3_type = unlowered_expr_type (arg3);
   if (VOID_TYPE_P (arg2_type) || VOID_TYPE_P (arg3_type))
 {
-  /* Do the conversions.  We don't these for `void' type arguments
-	 since it can't have any effect and since decay_conversion
-	 does not handle that case gracefully.  */
-  if (!VOID_TYPE_P (arg2_type))
-	arg2 = decay_conversion (arg2, complain);
-  if (!VOID_TYPE_P (arg3_type))
-	arg3 = decay_conversion (arg3, complain);
-  arg2_type = TREE_TYPE (arg2);
-  arg3_type = TREE_TYPE (arg3);
-
   /* [expr.cond]
 
 	 One of the following shall hold:
 
 	 --The second or the third operand (but not both) is a
-	   throw-expression (_except.throw_); the result is of the
-	   type of the other and is an rvalue.
+	   throw-expression (_except.throw_); the result is of the type
+	   and value category of the other.
 
 	 --Both the second and the third operands have type void; the
-	   result is of type void and is an rvalue.
-
-	 We must avoid calling force_rvalue for expressions of type
-	 "void" because it will complain that their value is being
-	 used.  */
+	   result is of type void and is a prvalue.  */
   if (TREE_CODE (arg2) == THROW_EXPR
 	  && TREE_CODE (arg3) != THROW_EXPR)
 	{
-	  if (!VOID_TYPE_P (arg3_type))
-	{
-	  arg3 = force_rvalue (arg3, complain);
-	  if (arg3 == error_mark_node)
-		return error_mark_node;
-	}
-	  arg3_type = TREE_TYPE (arg3);
 	  result_type = arg3_type;
+	  is_glvalue = glvalue_p (arg3);
 	}
   else if (TREE_CODE (arg2) != THROW_EXPR
 	   && TREE_CODE (arg3) == THROW_EXPR)
 	{
-	  if (!VOID_TYPE_P (arg2_type))
-	{
-	  arg2 = force_rvalue (arg2, complain);
-	  if (arg2 == error_mark_node)
-		return error_mark_node;
-	}
-	  arg2_type = TREE_TYPE (arg2);
 	  result_type = arg2_type;
+	  is_glvalue = glvalue_p (arg2);
 	}
   else if (VOID_TYPE_P (arg2_type) && VOID_TYPE_P (arg3_type))
-	result_type = void_type_node;
+	{
+	  result_type = void_type_node;
+	  is_glvalue = false;
+	}
   else
 	{
   if (complain & tf_error)
@@ -5037,7 +5014,6 @@ build_conditional_expr_1 (location_t loc, tree arg1, tree arg2, tree arg3,
 	  return error_mark_node;
 	}
 
-  is_glvalue = false;
   goto valid_operands;
 }
   /* [expr.cond]
@@ -5155,10 +5131,6 @@ build_conditional_expr_1 (location_t loc, tree arg1, tree arg2, tree arg3,
   && same_type_p (arg2_type, arg3_type))
 {
   result_type = arg2_type;
-  if (processing_template_decl)
-	/* Let lvalue_kind know this was a glvalue.  */
-	result_type = cp_build_reference_type (result_type, xvalue_p (arg2));
-
   arg2 = mark_lvalue_use (arg2);
   arg3 = mark_lvalue_use (arg3);
   goto valid_operands;
@@ -5352,6 +5324,13 @@ build_conditional_expr_1 (location_t loc, tree arg1, tree arg2, tree arg3,
 return error_mark_node;
 
  valid_operands:
+  if (processing_template_decl && is_glvalue)
+{
+  /* Let lvalue_kind know this was a glvalue.  */
+  tree arg = (result_type == arg2_type ? arg2 : arg3);
+  result_type = cp_build_reference_type (result_type, xvalue_p (arg));
+}
+
   result = build3_loc (loc, COND_EXPR, result_type, arg1, arg2, arg3);
 
   /* If the ARG2 and ARG3 are the same and don't have side-effects,
diff --git a/gcc/testsuite/g++.dg/cpp1y/dr1560.C b/gcc/testsuite/g++.dg/cpp1y/dr1560.C
new file mode 100644
index 000..b21ca98e279
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1y/dr1560.C
@@ -0,0 +1,14 @@
+// Core 1560
+// { dg-do compile { target c++14 } }
+
+struct A
+{
+  A();
+  A(const A&) = delete;
+};
+
+void f(bool b)
+{
+  A a;
+  b ? a : throw 42;
+}

[Bug middle-end/85643] attribute nonstring fails to squash -Wstringop-truncation warning at an offset

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85643

--- Comment #5 from Martin Sebor  ---
Committed into trunk in r260271.

[Bug middle-end/85643] attribute nonstring fails to squash -Wstringop-truncation warning at an offset

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85643

--- Comment #4 from Martin Sebor  ---
Author: msebor
Date: Tue May 15 21:52:16 2018
New Revision: 260271

URL: https://gcc.gnu.org/viewcvs?rev=260271=gcc=rev
Log:
PR middle-end/85643 - attribute nonstring fails to squash -Wstringop-truncation
warning

gcc/ChangeLog:

PR middle-end/85643
* calls.c (get_attr_nonstring_decl): Handle MEM_REF.

gcc/testsuite/ChangeLog:

PR middle-end/85643
* c-c++-common/attr-nonstring-7.c: New test.


Added:
trunk/gcc/testsuite/c-c++-common/attr-nonstring-7.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/calls.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/64372] [DR1560] Gratuitous lvalue-to-rvalue conversion in conditional-expression with throw-expression operand

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64372

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||jason at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org

Re: Auto-generated .rodata contents and __attribute__((section))

[Segher Boessenkool]

On Tue, May 15, 2018 at 12:56:22PM -0700, Julius Werner wrote:
> > I think you are asking for per-function constant pool sections.  Because
> > we generally cannot avoid the need of a constant pool and dependent
> > on the target that is always global.  Note with per-function constant
> > pools you will not benefit from constant pool entry merging across
> > functions.  I'm also not aware of any non-target-specific (and thus not
> > implemented on some targets) option to get these.
> 
> Thanks, yeah, that sounds like what I need. Is there any way to get that
> behavior today, even for a specific target? (I'm mostly interested in
> x86_64, armv7 and aarch64.) And are you saying that there are some targets
> for which it would be impossible to provide this behavior? Or just that
> it's not implemented for all targets today?

For aarch64 there is -mpc-relative-literal-loads, I think that will
do what you want.  This option is implied by -mcmodel=tiny which you
may want anyway, if your code is small enough.


Segher

Re: [PATCH, rs6000] Fix expected BE counts for vsx-vector-6.h

[Carl Love]

Segher:

I removed the Power 6 test file.  I also went back through the tests
and checked that each test had an instruction count check.  I found a
few that were missing the instruction check.  I added the instruction
checks and updated the expected instruction counts for the LE and BEcases.  The 
patch was retested on 

The patch was tested on 

powerpc64le-unknown-linux-gnu (Power 8 LE)   
    powerpc64le-unknown-linux-gnu (Power 9 LE)
    powerpc64-unknown-linux-gnu (Power 8 BE)  configured for power7
    powerpc64-unknown-linux-gnu (Power 8 BE)  configured for power8

Please let me know if the patch looks OK for GCC mainline.

 Carl Love
-
gcc/testsuite/ChangeLog:

2018-05-14 Carl Love  
* gcc.target/powerpc/vsx-vector-6-be.c: Remove file
* gcc.target/powerpc/vsx-vector-6-be.p7.c (dg-final): New test file for
Power 7.
* gcc.target/powerpc/vsx-vector-6-be.p8.c (dg-final): New test file for
Power 8.
* gcc.target/powerpc/vsx-vector-6-le.c (dg-final): Update counts for
.xvcmpeqdp., xvcmpgtdp., xvcmpgedp., xxlxor, xvrdpi.
---
 gcc/testsuite/gcc.target/powerpc/vsx-vector-6-be.c | 32 
 .../gcc.target/powerpc/vsx-vector-6-be.p7.c| 43 ++
 .../gcc.target/powerpc/vsx-vector-6-be.p8.c| 43 ++
 gcc/testsuite/gcc.target/powerpc/vsx-vector-6-le.c |  9 +
 4 files changed, 95 insertions(+), 32 deletions(-)
 delete mode 100644 gcc/testsuite/gcc.target/powerpc/vsx-vector-6-be.c
 create mode 100644 gcc/testsuite/gcc.target/powerpc/vsx-vector-6-be.p7.c
 create mode 100644 gcc/testsuite/gcc.target/powerpc/vsx-vector-6-be.p8.c

diff --git a/gcc/testsuite/gcc.target/powerpc/vsx-vector-6-be.c 
b/gcc/testsuite/gcc.target/powerpc/vsx-vector-6-be.c
deleted file mode 100644
index 3305781..000
--- a/gcc/testsuite/gcc.target/powerpc/vsx-vector-6-be.c
+++ /dev/null
@@ -1,32 +0,0 @@
-/* { dg-do compile { target { powerpc64-*-* && lp64 } } } */
-/* { dg-skip-if "" { powerpc*-*-darwin* } } */
-/* { dg-require-effective-target powerpc_vsx_ok } */
-/* { dg-options "-mvsx -O2" } */
-
-/* Expected instruction counts for Big Endian */
-
-/* { dg-final { scan-assembler-times "xvabsdp" 1 } } */
-/* { dg-final { scan-assembler-times "xvadddp" 1 } } */
-/* { dg-final { scan-assembler-times "xxlnor" 7 } } */
-/* { dg-final { scan-assembler-times "xvcmpeqdp" 6 } } */
-/* { dg-final { scan-assembler-times "xvcmpgtdp" 8 } } */
-/* { dg-final { scan-assembler-times "xvcmpgedp" 7 } } */
-/* { dg-final { scan-assembler-times "xvrdpim" 1 } } */
-/* { dg-final { scan-assembler-times "xvmaddadp" 1 } } */
-/* { dg-final { scan-assembler-times "xvmsubadp" 1 } } */
-/* { dg-final { scan-assembler-times "xvsubdp" 1 } } */
-/* { dg-final { scan-assembler-times "xvmaxdp" 1 } } */
-/* { dg-final { scan-assembler-times "xvmindp" 1 } } */
-/* { dg-final { scan-assembler-times "xvmuldp" 1 } } */
-/* { dg-final { scan-assembler-times "vperm" 1 } } */
-/* { dg-final { scan-assembler-times "xvrdpic" 1 } } */
-/* { dg-final { scan-assembler-times "xvsqrtdp" 1 } } */
-/* { dg-final { scan-assembler-times "xvrdpiz" 1 } } */
-/* { dg-final { scan-assembler-times "xvmsubasp" 1 } } */
-/* { dg-final { scan-assembler-times "xvnmaddasp" 1 } } */
-/* { dg-final { scan-assembler-times "vmsumshs" 1 } } */
-/* { dg-final { scan-assembler-times "xxland" 13 } } */
-/* { dg-final { scan-assembler-times "xxsel" 2 } } */
-
-/* Source code for the test in vsx-vector-6.h */
-#include "vsx-vector-6.h"
diff --git a/gcc/testsuite/gcc.target/powerpc/vsx-vector-6-be.p7.c 
b/gcc/testsuite/gcc.target/powerpc/vsx-vector-6-be.p7.c
new file mode 100644
index 000..835b24f
--- /dev/null
+++ b/gcc/testsuite/gcc.target/powerpc/vsx-vector-6-be.p7.c
@@ -0,0 +1,43 @@
+/* { dg-do compile { target { powerpc64-*-* && lp64 } } } */
+/* { dg-skip-if "" { powerpc*-*-darwin* } } */
+/* { dg-require-effective-target powerpc_vsx_ok } */
+/* { dg-options "-mvsx -O2 -mcpu=power7" } */
+/* { dg-skip-if "do not override -mcpu" { powerpc*-*-* } { "-mcpu=*" } { 
"-mcpu=power7" } } */
+
+
+/* Expected instruction counts for Big Endian */
+
+/* { dg-final { scan-assembler-times "xvabsdp" 1 } } */
+/* { dg-final { scan-assembler-times "xvadddp" 1 } } */
+/* { dg-final { scan-assembler-times "xxlnor" 7 } } */
+/* { dg-final { scan-assembler-times "xvcmpeqdp" 6 } } */
+/* { dg-final { scan-assembler-times "xvcmpeqdp." 6 } } */
+/* { dg-final { scan-assembler-times "xvcmpgtdp" 8 } } */
+/* { dg-final { scan-assembler-times "xvcmpgtdp." 8 } } */
+/* { dg-final { scan-assembler-times "xvcmpgedp" 7 } } */
+/* { dg-final { scan-assembler-times "xvcmpgedp." 7 } } */
+/* { dg-final { scan-assembler-times "xvrdpim" 1 } } */
+/* { dg-final { scan-assembler-times "xvmaddadp" 1 } } */
+/* { dg-final { scan-assembler-times "xvmsubadp" 1 } } */
+/* { dg-final { scan-assembler-times "xvsubdp" 1 } } 

Re: [PR63185][RFC] Improve DSE with branches

[Jeff Law]

On 05/15/2018 03:20 AM, Richard Biener wrote:
> 
> First (baby) step is the following - it arranges to collect the
> defs we need to continue walking from and implements trivial
> reduction by stopping at (full) kills.  This allows us to handle
> the new testcase (which was already handled in the very late DSE
> pass with the help of sinking the store).
Seems like a notable improvement.  They way we were handling defs to
continue walking forward from was, umm, fugly.


> 
> I didn't adjust the byte-tracking case fully (I'm not fully understanding
> the code in the case of a use and I'm not sure whether it's worth
> doing the def reduction with byte-tracking).
The byte tracking case is pretty simple.  We're tracking the bytes from
the original store that are still live.  If we encounter a subsequent
store that over-writes a subset of bytes, we consider those bytes from
the original store as "dead".

If we then encounter a load and the load only reads from "dead" bytes,
then we can ignore the load for the purposes of DSE.

It's something you suggested.  I did some instrumentation when working
on DSE for gcc6/gcc7 and while it triggers, it's not terribly often.



> 
> Your testcase can be handled by reducing the PHI and the call def
> by seeing that the only use of a candidate def is another def
> we have already processed.  Not sure if worth special-casing though,
> I'd rather have a go at "recursing".  That will be the next
> patch.
> 
> Bootstrap & regtest running on x86_64-unknown-linux-gnu.
> 
> Richard.
> 
> 2018-05-15  Richard Biener  
> 
>   * tree-ssa-dse.c (dse_classify_store): Remove use_stmt parameter,
>   add by_clobber_p one.  Change algorithm to collect all defs
>   representing uses we need to walk and try reducing them to
>   a single one before failing.
>   (dse_dom_walker::dse_optimize_stmt): Adjust.
> 
>   * gcc.dg/tree-ssa/ssa-dse-31.c: New testcase.
Seems quite reasonable to me as long as we're continuing with a forward
algorithm.

jeff

[Bug c++/85799] __builin_expect doesn't propagate through inlined functions

[redbeard0531 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85799

--- Comment #1 from Mathias Stearn  ---
LLVM bug: https://bugs.llvm.org/show_bug.cgi?id=37476

[Bug c++/85799] New: __builin_expect doesn't propagate through inlined functions

[redbeard0531 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85799

Bug ID: 85799
   Summary: __builin_expect doesn't propagate through inlined
functions
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redbeard0531 at gmail dot com
  Target Milestone: ---

It seems like __builtin_expect doesn't propagate to conditions when inlined.
This is unfortunate because in some cases it would be nice to be able to put
the expectation into methods so that every user doesn't need to do their own
hinting. Currently we need to use macros to achieve this.

See https://godbolt.org/g/MuPM77 for full example

inline bool expect_false(bool b) {
return __builtin_expect(b, false);
}

void inline_func_hint(bool b) {
if (expect_false(b)) {
unlikely(); // treated as more likely!!!
} else {
likely();
}
}


inline_func_hint(bool):
testdil, dil
je  .L11
jmp unlikely()
.L11:
jmp likely()

[Bug tree-optimization/85788] False positive of -Wstringop-overflow= warning

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85788

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-15
 Ever confirmed|0   |1
  Known to fail||7.3.0, 8.1.0

--- Comment #1 from Martin Sebor  ---
Confirmed at -O2 with GCC 8.1 but only at -O3 on trunk where the warning sees:

n ()
{
  int * c;
  int b.2_13;
  int b.2_16;
  int pretmp_25;
  int pretmp_26;
  int _28;
  int _31;
  long unsigned int _33;

   [local count: 1073741826]:
  c_3 = d;
  if (c_3 != 0B)
goto ; [89.00%]
  else
goto ; [11.00%]

   [local count: 1073741817]:
  pretmp_25 = m.g;
  pretmp_26 = m.h;
  _28 = pretmp_25 / 8;
  _31 = pretmp_26 * _28;
  _33 = (long unsigned int) _31;
  b.2_16 = b;
  __builtin___memset_chk (, b.2_16, _33, 64000); [tail call]
  return;

   [local count: 955630226]:
  c_4 = e;
  if (c_4 != 0B)
goto ; [89.00%]
  else
goto ; [11.00%]

   [local count: 955630226]:
  MEM[(int *)] = 140733193420799;
  b.2_13 = b;
  __builtin___memset_chk (, b.2_13, 134180865, 64000);
  goto ; [100.00%]

   [local count: 7731917263]:
  goto ; [100.00%]

   [local count: 8687547448]:
  goto ; [100.00%]

}


In function ‘a’,
inlined from ‘make_str_raster.constprop’ at t.c:17:3,
inlined from ‘n’ at t.c:22:12:
t.c:5:3: warning: ‘__builtin___memset_chk’ writing 134180865 bytes into a
region of size 64000 overflows the destination [-Wstringop-overflow=]
   __builtin___memset_chk(k, b, l, f);
   ^~

Re: [PATCH][AArch64] Improve register allocation of fma

[Wilco Dijkstra]

Hi,

James Greenhalgh wrote:
>
> This seems like a fairly horrible hack around the register allocator
> behaviour.

That is why I proposed to improve the register allocator so one can explicitly
specify the copy preference in the md syntax. However that wasn't accepted,
so we'll have to use a hack instead...

Wilco

[Bug other/85778] unexpected results with -O2, wrong code?

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85778

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #5 from Martin Sebor  ---
(In reply to Scott Emmons from comment #4)
> > glibc has stat annotated with nonnull(1, 2)
> 
> 1. Can you provide a reference to this code? This is helpful so that other
> people running into this (and it *will* happen, this ancient code no longer
> runs correctly). Thank you.

stat() is a POSIX function and (similarly to C) POSIX specifies (in 2.1.1 Use
and Implementation of Functions of XSH) that:

If an argument to a function has an invalid value (such as a value outside the
domain of the function, or a pointer outside the address space of the program,
or a null pointer), the behavior is undefined.

A link to the section in the latest spec:
pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_01_01

Re: Auto-generated .rodata contents and __attribute__((section))

[Joseph Myers]

This has been listed as a desirable feature for a long time: 
https://gcc.gnu.org/projects/optimize.html#putting_constants_in_special_sections

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

Re: LTO vs GCC 8

[Freddie Chopin]

On Tue, 2018-05-15 at 21:39 +0200, Freddie Chopin wrote:
> On Fri, 2018-05-11 at 18:51 +0200, Richard Biener wrote:
> > As to a workaround for the ld bug you can try keeping all .debug_*
> > sections. IIRC 2.30 has the bug fixed (on the branch). 
> 
> Indeed - "keeping" all the debug sections is a viable alternative.
> I've
> found out that it is enough to "keep" just these:
> 
>   /* DWARF 2 */
>   .debug_info 0 : { KEEP(*(.debug_info .gnu.linkonce.wi.*)); }
>...
>   .debug_frame 0 : { KEEP(*(.debug_frame)); }
> 
> I have to check whether debugging something like that is actually
> possible (; Thanks for the workaround!

Nope, sent it too fast... With these two (three) sections "kept" --gc-
sections stops working and the executable I get is almost identical to
the case when I have no --gc-sections at all:
- lto + --gc-sections, sections "kept" - 133504 ROM + 4196 RAM
- lto + --gc-sections, sections not "kept" (causes previously mentioned
errors) - 120288 ROM + 3676 RAM
- lto, sections not "kept" - 133812 ROM + 4220 RAM

So it seems I have to patiently wait for new binutils if I would like
to use LTO (;

Regards,
FCh

Re: LTO vs GCC 8

[Freddie Chopin]

On Mon, 2018-05-14 at 16:34 +0200, David Brown wrote:
> Interesting.  Making these sections and then using gc-sections should
> only remove code that is not used - LTO should do that anyway.

My guess - expressed in the other e-mail to the list - is that the
things LTO cannot remove but --gc-sections can are objects from
toolchain library.

> Have you tried with -ffunction-sections and not -fdata-sections?  It
> is
> the -fdata-sections that ruins -fsection-anchors - the
> -ffunction-sections doesn't have the same kind of cost.

Results:
- -ffunction-sections + -fdata-sections = 124396 ROM + 3484 RAM
- -ffunction-sections = 125168 ROM + 3676 RAM
- -ffunction-sections + -fsection-anchors = 125168 ROM + 3676 RAM
- -ffunction-sections + -fsection-anchors + -fno-common = 125168 ROM +
3676 RAM 

Generated executables for the second, third and fourth case are
identical - assembly listings for these three cases have no differences
at all.

I've also tried with -fno-section-anchors, and this makes a minor
(negative) difference - 125352 ROM + 3676 RAM.

> No, -fsection-anchors has plenty of use for fixed-position eabi code.
> ...
> The code is clearly bigger and slower, and uses more anchors in the
> code
> section.
> 
> Note that to get similar improvements with non-static data, you need
> "-fno-common" - a flag that I believe should be the default for the
> compiler.

I cannot reproduce this here ); Don't get me wrong - if there's a
"free" way to improve code size/speed with some compiler flags which I
did not use previously, then I'm very much interested, however in my
particular case the best result (size-wise) I get is with just
-ffunction-sections + -fdata-sections. The difference is not huge, but
it's also not negligible. Maybe this has to do with different compiler
versions we are comparing (4.8 vs 8.1)? I guess this is not LTO (which
I did not enable for these measurements), as you did not mention it in
your flags...

Regards,
FCh

Re: Auto-generated .rodata contents and __attribute__((section))

[Julius Werner]

> I think you are asking for per-function constant pool sections.  Because
> we generally cannot avoid the need of a constant pool and dependent
> on the target that is always global.  Note with per-function constant
> pools you will not benefit from constant pool entry merging across
> functions.  I'm also not aware of any non-target-specific (and thus not
> implemented on some targets) option to get these.

Thanks, yeah, that sounds like what I need. Is there any way to get that
behavior today, even for a specific target? (I'm mostly interested in
x86_64, armv7 and aarch64.) And are you saying that there are some targets
for which it would be impossible to provide this behavior? Or just that
it's not implemented for all targets today?

Are constant pool entries merged at compile time or at link time? I would
presume it should be done at link time because otherwise you're only
merging entries within a single compilation unit (which doesn't sound that
useful in a big project with hundreds of source files), right? So if
they're merged at link time, shouldn't it be possible to do that merging
after a linker script condensed all the per-function input sections that
are left after --gc-sections back into a single big .rodata output section?
(In my case, the linker script would instead condense all the constant pool
sections for marked functions into .special_area.rodata and all the others
into .rodata, and then it should be merging internally within those two
output sections.)

> Does it work better if you make this "static const"?

Yes, then I can declare an __attribute__((section)) for that specific
variable. However, that doesn't really seem like a safe and scalable
approach, especially since it's hard to notice when you missed a variable.
I'd like to have a way that I can annotate a function and that whole
function (with everything it needs, except for globals) gets put into a
special section (or a set of special sections with a common prefix or
suffix), without having to rewrite the source to accommodate for this every
time.

Re: LTO vs GCC 8

[Freddie Chopin]

On Fri, 2018-05-11 at 18:51 +0200, Richard Biener wrote:
> That's an interesting result. Do you have any non-LTO objects?
> Basically I'm curious what ld eliminates that gcc with LTO doesn't. 

Whole project is compiled with LTO, part of the project is provided as
a library (which is archived with arm-none-eabi-gcc-ar). Only non-LTO
stuff in the final executable are objects from standard toolchain
libraries and I suppose they are the culprit here - the toolchain is
compiled with -ffunction-sections -fdata-sections, but without -flto.
Maybe I should actually compile the whole toolchain with -flto -ffat-
lto-objects? Is this a sane idea?

> As to a workaround for the ld bug you can try keeping all .debug_*
> sections. IIRC 2.30 has the bug fixed (on the branch). 

Indeed - "keeping" all the debug sections is a viable alternative. I've
found out that it is enough to "keep" just these:

/* DWARF 2 */
.debug_info 0 : { KEEP(*(.debug_info .gnu.linkonce.wi.*)); }
 ...
.debug_frame 0 : { KEEP(*(.debug_frame)); }

I have to check whether debugging something like that is actually
possible (; Thanks for the workaround!

Regards,
FCh

[Bug fortran/85798] ICE in get_array_index, at fortran/data.c:69

[gs...@t-online.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85798

--- Comment #1 from G. Steinmetz  ---

For comparison :


$ cat z2.f90
program p
   integer, allocatable :: a(:)
   data a(1) / 789 /
end


$ gfortran-9-20180513 -c z2.f90
z2.f90:3:7:

data a(1) / 789 /
   1
Error: DATA attribute conflicts with ALLOCATABLE attribute in 'a' at (1)

[Bug fortran/85798] New: ICE in get_array_index, at fortran/data.c:69

[gs...@t-online.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85798

Bug ID: 85798
   Summary: ICE in get_array_index, at fortran/data.c:69
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

While wrapped in a type, hits versions down to at least 4.8 :


$ cat z1.f90
program p
   type t
  integer, allocatable :: a(:)
   end type
   type(t) :: z
   data z%a(1) / 789 /
end


$ gfortran-9-20180513 -c z1.f90
f951: internal compiler error: Segmentation fault
0xb9f4bf crash_signal
../../gcc/toplev.c:325
0x68e8da get_array_index
../../gcc/fortran/data.c:69
0x68e8da gfc_assign_data_value(gfc_expr*, gfc_expr*, __mpz_struct*,
__mpz_struct (*) [1])
../../gcc/fortran/data.c:282
0x711ee9 check_data_variable
../../gcc/fortran/resolve.c:15479
0x712232 traverse_data_var
../../gcc/fortran/resolve.c:15608
0x71cd01 resolve_data
../../gcc/fortran/resolve.c:15663
0x71cd01 resolve_types
../../gcc/fortran/resolve.c:16481
0x71839c gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.c:16570
0x701b6a resolve_all_program_units
../../gcc/fortran/parse.c:6060
0x701b6a gfc_parse_file()
../../gcc/fortran/parse.c:6310
0x748adf gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug fortran/85797] New: ICE in gfc_element_size, at fortran/target-memory.c:126

[gs...@t-online.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85797

Bug ID: 85797
   Summary: ICE in gfc_element_size, at
fortran/target-memory.c:126
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

With option -Wsurprising or -Wall, down to at least 4.8 :


$ cat z1.f90
subroutine a
   c = transfer(a, b)
end


$ cat z2.f90
subroutine a
   c = transfer(a, a)
end


$ cat z3.f90
subroutine a
   c = transfer(b, a)
end


$ cat z4.f90
recursive subroutine a
   c = transfer(a, b)
end


$ gfortran-9-20180513 -c z4.f90
$
$ gfortran-9-20180513 -c z1.f90
z1.f90:2:16:

c = transfer(a, b)
1
Warning: Non-RECURSIVE procedure 'a' at (1) is possibly calling itself
recursively.  Declare it RECURSIVE or use '-frecursive'


$ gfortran-9-20180513 -c z4.f90 -Wsurprising
f951: internal compiler error: Invalid expression in gfc_element_size.
0x6a7d3f gfc_internal_error(char const*, ...)
../../gcc/fortran/error.c:1358
0x73cdbb gfc_element_size(gfc_expr*)
../../gcc/fortran/target-memory.c:126
0x73ce01 gfc_target_expr_size(gfc_expr*)
../../gcc/fortran/target-memory.c:152
0x684a23 gfc_calculate_transfer_sizes(gfc_expr*, gfc_expr*, gfc_expr*, unsigned
long*, unsigned long*, unsigned long*)
../../gcc/fortran/check.c:5408
0x684b88 gfc_check_transfer(gfc_expr*, gfc_expr*, gfc_expr*)
../../gcc/fortran/check.c:5472
0x6baf24 check_specific
../../gcc/fortran/intrinsic.c:4545
0x6c4ee4 gfc_intrinsic_func_interface(gfc_expr*, int)
../../gcc/fortran/intrinsic.c:4781
0x70ee65 resolve_unknown_f
../../gcc/fortran/resolve.c:2870
0x70ee65 resolve_function
../../gcc/fortran/resolve.c:3179
0x70ef8a gfc_resolve_expr(gfc_expr*)
../../gcc/fortran/resolve.c:6719
0x715810 gfc_resolve_code(gfc_code*, gfc_namespace*)
../../gcc/fortran/resolve.c:11100
0x7182aa resolve_codes
../../gcc/fortran/resolve.c:16537
0x7183ae gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.c:16572
0x701b6a resolve_all_program_units
../../gcc/fortran/parse.c:6060
0x701b6a gfc_parse_file()
../../gcc/fortran/parse.c:6310
0x748adf gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug fortran/85796] New: ICE: Floating point exception

[gs...@t-online.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85796

Bug ID: 85796
   Summary: ICE: Floating point exception
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Invalid and supplementary to pr84134, ICEs down to at least 4.8 :


$ cat z1.f90
program p
   integer :: i, j, x(2,2)
   data ((x(i,j), i=1,2,j-1), j=1,2) /3*789/
end


$ gfortran-9-20180513 -c z1.f90
f951: internal compiler error: Floating point exception
0xb9f4bf crash_signal
../../gcc/toplev.c:325
0x7123ee traverse_data_list
../../gcc/fortran/resolve.c:15554
0x7123ee traverse_data_var
../../gcc/fortran/resolve.c:15606
0x712436 traverse_data_list
../../gcc/fortran/resolve.c:15564
0x712436 traverse_data_var
../../gcc/fortran/resolve.c:15606
0x71cd01 resolve_data
../../gcc/fortran/resolve.c:15663
0x71cd01 resolve_types
../../gcc/fortran/resolve.c:16481
0x71839c gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.c:16570
0x701b6a resolve_all_program_units
../../gcc/fortran/parse.c:6060
0x701b6a gfc_parse_file()
../../gcc/fortran/parse.c:6310
0x748adf gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug fortran/85786] [8/9 Regression] Segfault in associated intrinsic

[sgk at troutmask dot apl.washington.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85786

--- Comment #7 from Steve Kargl  ---
On Tue, May 15, 2018 at 06:47:49PM +, dominiq at lps dot ens.fr wrote:
> 
> --- Comment #6 from Dominique d'Humieres  ---
> Likely r251949.
> 

There are no changes within trans-intrinsic.c(gfc_conv_associated)
that correspond to that revision.  My best guess with looking at
'svn annotate' is the offending commit is r190641.  The function
has grown over time, the missing lines I inserted with my patch
may have at one time been present but code motion moved them to
a different block.

[Bug fortran/72714] [6/7/8/9 Regression] [Coarray] ICE in gfc_array_init_size, at fortran/trans-array.c:5235

[gs...@t-online.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72714

G. Steinmetz  changed:

   What|Removed |Added

 CC||gs...@t-online.de

--- Comment #4 from G. Steinmetz  ---
Simplified a bit :


$ cat z5.f90
program p
   integer, allocatable :: z[:,:]
   allocate (z[:2,*])
end


$ gfortran-9-20180513 -c z5.f90 -fcoarray=single
z5.f90:3:0:

allocate (z[:2,*])

internal compiler error: in gfc_array_init_size, at fortran/trans-array.c:5496
0x757ac0 gfc_array_init_size
../../gcc/fortran/trans-array.c:5496
0x757ac0 gfc_array_allocate(gfc_se*, gfc_expr*, tree_node*, tree_node*,
tree_node*, tree_node*, tree_node*, tree_node**, gfc_expr*, tree_node*, bool)
../../gcc/fortran/trans-array.c:5770
0x7bb737 gfc_trans_allocate(gfc_code*)
../../gcc/fortran/trans-stmt.c:6300
0x74b6e7 trans_code
../../gcc/fortran/trans.c:1996
0x772c49 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6507
0x701d40 translate_all_program_units
../../gcc/fortran/parse.c:6121
0x701d40 gfc_parse_file()
../../gcc/fortran/parse.c:6324
0x748adf gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug fortran/85786] [8/9 Regression] Segfault in associated intrinsic

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85786

Dominique d'Humieres  changed:

   What|Removed |Added

   Keywords||wrong-code
Summary|[regression] Segfault in|[8/9 Regression] Segfault
   |associated intrinsic|in associated intrinsic

--- Comment #6 from Dominique d'Humieres  ---
Likely r251949.

Note that on darwin I don't get any segfault but only

...
loc(cs%v(2)%p) = 140579551852496
 not associated

[Bug fortran/85786] [regression] Segfault in associated intrinsic

[sgk at troutmask dot apl.washington.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85786

--- Comment #5 from Steve Kargl  ---
On Tue, May 15, 2018 at 05:49:15PM +, kargl at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85786
> 
> kargl at gcc dot gnu.org changed:
> 
>What|Removed |Added
> 
>Priority|P3  |P4
>  Status|UNCONFIRMED |NEW
>Last reconfirmed||2018-05-15
>  CC||pault at gcc dot gnu.org
>   Known to work||6.4.1, 7.3.1
> Summary|Segfault in associated  |[regression] Segfault in
>|intrinsic   |associated intrinsic
>  Ever confirmed|0   |1
>   Known to fail||8.1.1, 9.0
> 

Seems I liekly found the issue.

Index: gcc/fortran/trans-intrinsic.c
===
--- gcc/fortran/trans-intrinsic.c   (revision 260235)
+++ gcc/fortran/trans-intrinsic.c   (working copy)
@@ -7903,6 +7903,8 @@ gfc_conv_associated (gfc_se *se, gfc_expr *expr)
   /* A pointer to an array, call library function _gfor_associated. 
*/
   arg1se.want_pointer = 1;
   gfc_conv_expr_descriptor (, arg1->expr);
+ gfc_add_block_to_block (>pre, );
+ gfc_add_block_to_block (>post, );

   arg2se.want_pointer = 1;
   gfc_conv_expr_descriptor (, arg2->expr);

[Bug c++/58407] [C++11] Should warn about deprecated implicit generation of copy constructor/assignment

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58407

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org
   Target Milestone|--- |9.0

Re: [Aarch64] Vector Function Application Binary Interface Specification for OpenMP

[Francesco Petrogalli]

> On Feb 9, 2018, at 3:47 PM, Steve Ellcey  wrote:
> 
> […]
> I was wondering if the function vector ABI has been published yet and
> if so, where I could find it.
> 

Hi Steve,

I am happy to let you know that the Vector Function ABI for AArch64 is now 
public and available via the link at [1].

Don’t hesitate to contact me in case you have any questions.

Kind regards,

Francesco

[1] 
https://developer.arm.com/products/software-development-tools/hpc/arm-compiler-for-hpc/vector-function-abi

> Steve Ellcey
> sell...@cavium.com

Re: [PATCH][AArch64] Unify vec_set patterns, support floating-point vector modes properly

[Richard Sandiford]

Kyrill  Tkachov  writes:
> Hi all,
>
> We've a deficiency in our vec_set family of patterns.  We don't
> support directly loading a vector lane using LD1 for V2DImode and all
> the vector floating-point modes.  We do do it correctly for the other
> integer vector modes (V4SI, V8HI etc) though.
>
> The alternatives on the relative floating-point patterns only allow a
> register-to-register INS instruction.  That means if we want to load a
> value into a vector lane we must first load it into a scalar register
> and then perform an INS, which is wasteful.
>
> There is also an explicit V2DI vec_set expander dangling around for no
> reason that I can see. It seems to do the exact same things as the
> other vec_set expanders. This patch removes that.  It now unifies all
> vec_set expansions into a single "vec_set" define_expand using
> the catch-all VALL_F16 iterator.
>
> I decided to leave two aarch64_simd_vec_set define_insns. One
> for the integer vector modes (that now include V2DI) and one for the
> floating-point vector modes. That is so that we can avoid specifying
> "w,r" alternatives for floating-point modes in case the
> register-allocator gets confused and starts gratuitously moving
> registers between the two banks.  So the floating-point pattern only
> two alternatives, one for SIMD-to-SIMD INS and one for LD1.

Did you see any cases in which this was necessary?  In some ways it
seems to run counter to Wilco's recent patches, which tended to remove
the * markers from the "unnatural" register class and trust the register
allocator to make a sensible decision.

I think our default position should be trust the allocator here.
If the consumers all require "w" registers then the RA will surely
try to use "w" registers if at all possible.  But if the consumers
don't care then it seems reasonable to offer both, since in those
cases it doesn't really make much difference whether the payload
happens to be SF or SI (say).

There are also cases in which the consumer could actively require
an integer register.  E.g. some code uses unions to bitcast floats
to ints and then do bitwise arithmetic on them.

> With this patch we avoid loading values into scalar registers and then
> doing an explicit INS on them to move them into the desired vector
> lanes. For example for:
>
> typedef float v4sf __attribute__ ((vector_size (16)));
> typedef long long v2di __attribute__ ((vector_size (16)));
>
> v2di
> foo_v2di (long long *a, long long *b)
> {
>v2di res = { *a, *b };
>return res;
> }
>
> v4sf
> foo_v4sf (float *a, float *b, float *c, float *d)
> {
>v4sf res = { *a, *b, *c, *d };
>return res;
> }
>
> we currently generate:
>
> foo_v2di:
>  ldr d0, [x0]
>  ldr x0, [x1]
>  ins v0.d[1], x0
>  ret
>
> foo_v4sf:
>  ldr s0, [x0]
>  ldr s3, [x1]
>  ldr s2, [x2]
>  ldr s1, [x3]
>  ins v0.s[1], v3.s[0]
>  ins v0.s[2], v2.s[0]
>  ins v0.s[3], v1.s[0]
>  ret
>
> but with this patch we generate the much cleaner:
> foo_v2di:
>  ldr d0, [x0]
>  ld1 {v0.d}[1], [x1]
>  ret
>
> foo_v4sf:
>  ldr s0, [x0]
>  ld1 {v0.s}[1], [x1]
>  ld1 {v0.s}[2], [x2]
>  ld1 {v0.s}[3], [x3]
>  ret

Nice!  The original reason for:

  /* FIXME: At the moment the cost model seems to underestimate the
 cost of using elementwise accesses.  This check preserves the
 traditional behavior until that can be fixed.  */
  if (*memory_access_type == VMAT_ELEMENTWISE
  && !STMT_VINFO_STRIDED_P (stmt_info)
  && !(stmt == GROUP_FIRST_ELEMENT (stmt_info)
   && !GROUP_NEXT_ELEMENT (stmt_info)
   && !pow2p_hwi (GROUP_SIZE (stmt_info
{
  if (dump_enabled_p ())
dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,
 "not falling back to elementwise accesses\n");
  return false;
}

was that we seemed to be too optimistic about how cheap it was to
construct a vector from scalars.  Maybe this patch brings the code
closer to the cost (for AArch64 only of course).

FWIW, the patch looks good to me bar the GPR/FPR split.

Thanks,
Richard

[Bug fortran/85786] [regression] Segfault in associated intrinsic

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85786

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-15
 CC||pault at gcc dot gnu.org
  Known to work||6.4.1, 7.3.1
Summary|Segfault in associated  |[regression] Segfault in
   |intrinsic   |associated intrinsic
 Ever confirmed|0   |1
  Known to fail||8.1.1, 9.0

--- Comment #4 from kargl at gcc dot gnu.org ---
This could be fallout from the recent change in the
internal representation of the array descriptor.

Re: [PR63185][RFC] Improve DSE with branches

[Richard Biener]

On May 15, 2018 5:04:53 PM GMT+02:00, Jeff Law  wrote:
>On 05/15/2018 02:15 AM, Richard Biener wrote:
>> On Mon, 14 May 2018, Kugan Vivekanandarajah wrote:
>> 
>>> Hi,
>>>
>>> Attached patch handles PR63185 when we reach PHI with temp != NULLL.
>>> We could see the PHI and if there isn't any uses for PHI that is
>>> interesting, we could ignore that ?
>>>
>>> Bootstrapped and regression tested on x86_64-linux-gnu.
>>> Is this OK?
>> 
>> No, as Jeff said we can't do it this way.
>> 
>> If we end up with multiple VDEFs in the walk of defvar immediate
>> uses we know we are dealing with a CFG fork.  We can't really
>> ignore any of the paths but we have to
>> 
>>  a) find the merge point (and the associated VDEF)
>>  b) verify for each each chain of VDEFs with associated VUSEs
>> up to that merge VDEF that we have no uses of the to classify
>> store and collect (partial) kills
>>  c) intersect kill info and continue walking from the merge point
>Which makes me come back to "why is this structured as a forward walk?"

Probably historic reasons. We _do_ have a backward walk DSE embedded inside DCE 
though but I had troubles making it as powerful as DSE. 

>DSE seems much more naturally structured as a walk of the
>post-dominator
>tree, walking instructions in reverse order.

DSE performs analysis for each possibly dead store and walks those in postdom 
order. But as the analysis decides whether a candidate is dead it needs to find 
later stores that makes it so. Thus a forward walk. The canonical way would 
possibly to find earlier stores that a store makes dead which would structure 
this more like a dataflow problem. (but the kill sets will be expensive to 
manage I'd guess) 

>Cases like 63185 would naturally fall out of that structure as the
>clobber at the end of the function post-dominates the memset and
>there's
>no intervening aliased loads.
>
>In fact, I thought that's how I initially structured DSE.I'm not
>sure when/why it changed.

IIRC it was improved, became too expensive and then ended up the current way. 

Richard. 

>Jeff

[Bug c++/85783] alloc-size-larger-than fires incorrectly with new[] and can't be disabled

[psmith at gnu dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85783

--- Comment #9 from Paul Smith  ---
Sorry; Andrew's original reply seemed to say that the use-case is
non-conforming so the issue was WONTFIX.  I also thought your comment #6 was
referring to my example in comment #5: I just wanted to clarify that that
example was conforming (although still, admittedly, very unrealistic).

If this issue is best left WONTFIX in deference to the more accurate/detailed
one you opened that's fine with me.

Cheers!

[Bug fortran/85786] Segfault in associated intrinsic

[sgk at troutmask dot apl.washington.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85786

--- Comment #3 from Steve Kargl  ---
On Tue, May 15, 2018 at 04:50:41AM +, angus at agibson dot me wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85786
> 
> --- Comment #2 from Angus Gibson  ---
> Changing the declaration of e to also be 'target', and associating the 
> pointer:
> 
> CS%v(2)%p => e
> if (query_ptr(e, CS)) then
> ...
> 
> still causes the segfault.  Perhaps I disconnected this from the original code
> too much! Even if CS%v(2)%p wasn't associated, I don't see why there should be
> a segfault?

Here's a slight rewrite with debugging print statements.
Certainly, seems like you've found a bug :(


program test

   implicit none

   type :: p2d
  real, pointer :: p(:,:) => null()
   end type p2d

   type :: test_cs
  type(p2d), pointer :: v(:) => null()
   end type test_cs

   type(test_cs), pointer :: cs
   real, allocatable, target :: e(:,:)

   allocate(cs)
   print '(A,L1)', 'associated(cs) = ', associated(cs)

   allocate(cs%v(2))
   print '(A,L1)', 'associated(cs%v) = ', associated(cs%v)

   allocate(e(2,2))
   e = 42
   print '(A,I0)', 'loc(e) = ', loc(e)
   print '(A,4F6.1)', 'e = ', e

   if (query_ptr(e, cs)) then
  print *, 'associated'
   else
  print *, 'not associated'
   end if

   contains

  logical function query_ptr(f_ptr, cs)

 real, target, intent(in) :: f_ptr(:,:)
 type(test_cs), pointer, intent(inout) :: cs

 print '(A,I0)','loc(f_ptr) = ', loc(f_ptr)
 print '(A,4F6.1)', 'f_ptr = ', f_ptr

 if (associated(cs)) then
print *, 'in query'
print '(A,L1)', 'associated(cs%v) = ', associated(cs%v)
cs%v(2)%p => f_ptr
print '(A,L1)', 'associated(cs%v(2)%p) = ', associated(cs%v(2)%p)
print '(A,I0)', 'loc(cs%v(2)%p) = ', loc(cs%v(2)%p)
query_ptr = associated(cs%v(2)%p, f_ptr)
 else
query_ptr = .false.
 end if
  end function query_ptr

end program test

Pretty good indication of why I don't use pointers.

[Bug c++/83400] g++ -O1 doesn't execute any code in destructors with a throw statement if it sees another throw

[redbeard0531 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83400

--- Comment #3 from Mathias Stearn  ---
This is related to https://wg21.link/CWG2219

[Bug c++/85783] alloc-size-larger-than fires incorrectly with new[] and can't be disabled

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85783

--- Comment #8 from Martin Sebor  ---
There is no standard way to say "don't inline this function."  It's up to the
compiler to decide what to inline just so long as it doesn't violate the
requirements.

There is also no requirement that the definition of the replacement operator
contain an explicit throw statement.  Your example in comment #5 is fine.

But I'm not sure what the point is of these questions.  I explained what causes
the warning, and what makes the original test case less than 100% conforming. 
I'm not disputing that the warning is unhelpful (with a conforming test case or
otherwise), or that it would be nice to avoid.  I just don't see a way to do it
in GCC (except by fixing bug 85795).  That's why I resolved this as WONTFIX and
not as INVALID, and why I opened bug 85795.  That's a separate conformance
issue that should be considered on its own.  If that happens to get rid of the
warning that's a bonus.

What would you prefer me to do instead?

Re: [PATCH][AArch64] Improve register allocation of fma

[James Greenhalgh]

On Tue, May 15, 2018 at 08:00:49AM -0500, Wilco Dijkstra wrote:
> 
> ping

This seems like a fairly horrible hack around the register allocator
behaviour.

BUt, OK.

James

> This patch improves register allocation of fma by preferring to update the
> accumulator register.  This is done by adding fma insns with operand 1 as the
> accumulator.  The register allocator considers copy preferences only in 
> operand
> order, so if the first operand is dead, it has the highest chance of being
> reused as the destination.  As a result code using fma often has a better
> register allocation.  Performance of SPECFP2017 improves by over 0.5% on some
> implementations, while it had no effect on other implementations.  Fma is more
> readable too, in a simple example we now generate:
> 
>     fmadd   s16, s2, s1, s16
>     fmadd   s7, s17, s16, s7
>     fmadd   s6, s16, s7, s6
>     fmadd   s5, s7, s6, s5
> 
> instead of:
> 
>     fmadd   s16, s16, s2, s1
>     fmadd   s7, s7, s16, s6
>     fmadd   s6, s6, s7, s5
>     fmadd   s5, s5, s6, s4
> 
> Bootstrap OK. OK for commit?
> 
> ChangeLog:
> 2018-01-04  Wilco Dijkstra  
> 
>     gcc/
>     * config/aarch64/aarch64.md (fma4): Change into expand pattern.
>     (fnma4): Likewise.
>     (fms4): Likewise.
>     (fnms4): Likewise.
>     (aarch64_fma4): Rename insn, reorder accumulator operand.
>     (aarch64_fnma4): Likewise.
>     (aarch64_fms4): Likewise.
>     (aarch64_fnms4): Likewise.
>     (aarch64_fnmadd4): Likewise.
  

Re: Auto-generated .rodata contents and __attribute__((section))

[Segher Boessenkool]

On Mon, May 14, 2018 at 04:38:09PM -0700, Julius Werner wrote:
> However, I just found an issue with this when the functions include local
> variables like this:
> 
>   const int some_array[] = { 1, 2, 3, 4, 5, 6 };

Does it work better if you make this "static const"?


Segher

[Bug c++/85783] alloc-size-larger-than fires incorrectly with new[] and can't be disabled

[psmith at gnu dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85783

--- Comment #7 from Paul Smith  ---
Is there a way (in standard C++) to force non-inline?  I'm not aware of one. 
So that means the only standard-conforming way to replace operator new is if
it's in its own compilation unit all by itself?  I don't have a copy of the
standard but cppreference says only that replacement operator new can't have an
inline specifier, that it can't be static, and that it has to be in the global
namespace, all of which requirements this example appears to meet.

Regarding throw, does the standard really say that the throw must be explicit
in the implementation of the function directly?  If my operator new[] invokes a
function to throw, rather than throwing directly, is that not
standard-conforming?  That seems bizarre to me: just because the compiler can't
prove to itself that my operator new will throw properly, the compiler is
allowed to assume the code is non-conforming?

Re: [PATCH][AArch64] Set SLOW_BYTE_ACCESS

[Wilco Dijkstra]

Hi,

> Which doesn't appear to have been approved.  Did you follow up with Jeff?

I'll get back to that one at some point - it'll take some time to agree on a way
forward with the callback.

Wilco

Re: [PATCH, v2] Recognize a missed usage of a sbfiz instruction

[James Greenhalgh]

On Mon, May 14, 2018 at 03:41:34PM -0500, Luis Machado wrote:
> On 05/11/2018 06:46 AM, Kyrill Tkachov wrote:
> > Hi Luis,
> > 
> > On 10/05/18 11:31, Luis Machado wrote:
> >>
> >> On 05/09/2018 10:44 AM, Kyrill Tkachov wrote:
> >>>
> >>> On 09/05/18 13:30, Luis Machado wrote:
>  Hi Kyrill,
> 
>  On 05/08/2018 11:09 AM, Kyrill Tkachov wrote:
> > Hi Luis,
> >
> > On 07/05/18 15:28, Luis Machado wrote:
> >> Hi,
> >>
> >> On 02/08/2018 10:45 AM, Luis Machado wrote:
> >>> Hi Kyrill,
> >>>
> >>> On 02/08/2018 09:48 AM, Kyrill Tkachov wrote:
>  Hi Luis,
> 
>  On 06/02/18 15:04, Luis Machado wrote:
> > Thanks for the feedback Kyrill. I've adjusted the v2 patch 
> > based on your
> > suggestions and re-tested the changes. Everything is still sane.
> 
>  Thanks! This looks pretty good to me.
> 
> > Since this is ARM-specific and fairly specific, i wonder if it 
> > would be
> > reasonable to consider it for inclusion at the current stage.
> 
>  It is true that the target maintainers can choose to take
>  such patches at any stage. However, any patch at this stage 
>  increases
>  the risk of regressions being introduced and these regressions
>  can come bite us in ways that are very hard to anticipate.
> 
>  Have a look at some of the bugs in bugzilla (or a quick scan of 
>  the gcc-bugs list)
>  for examples of the ways that things can go wrong with any of 
>  the myriad of GCC components
>  and the unexpected ways in which they can interact.
> 
>  For example, I am now working on what I initially thought was a 
>  one-liner fix for
>  PR 84164 but it has expanded into a 3-patch series with a midend 
>  component and
>  target-specific changes for 2 ports.
> 
>  These issues are very hard to catch during review and normal 
>  testing, and can sometimes take months of deep testing by
>  fuzzing and massive codebase rebuilds to expose, so the closer 
>  the commit is to a release
>  the higher the risk is that an obscure edge case will be 
>  unnoticed and unfixed in the release.
> 
>  So the priority at this stage is to minimise the risk of 
>  destabilising the codebase,
>  as opposed to taking in new features and desirable performance 
>  improvements (like your patch!)
> 
>  That is the rationale for delaying committing such changes until 
>  the start
>  of GCC 9 development. But again, this is up to the aarch64 
>  maintainers.
>  I'm sure the patch will be a perfectly fine and desirable commit 
>  for GCC 9.
>  This is just my perspective as maintainer of the arm port.
> >>>
> >>> Thanks. Your explanation makes the situation pretty clear and it 
> >>> sounds very reasonable. I'll put the patch on hold until 
> >>> development is open again.
> >>>
> >>> Regards,
> >>> Luis
> >>
> >> With GCC 9 development open, i take it this patch is worth 
> >> considering again?
> >>
> >
> > Yes, I believe the latest version is at:
> > https://gcc.gnu.org/ml/gcc-patches/2018-02/msg00239.html ?
> >
> > +(define_insn "*ashift_extv_bfiz"
> > +  [(set (match_operand:GPI 0 "register_operand" "=r")
> > +    (ashift:GPI (sign_extract:GPI (match_operand:GPI 1 
> > "register_operand" "r")
> > +  (match_operand 2 
> > "aarch64_simd_shift_imm_offset_" "n")
> > +  (match_operand 3 
> > "aarch64_simd_shift_imm_" "n"))
> > + (match_operand 4 "aarch64_simd_shift_imm_" "n")))]
> > +  ""
> > +  "sbfiz\\t%0, %1, %4, %2"
> > +  [(set_attr "type" "bfx")]
> > +)
> > +
> 
>  Indeed.
> 
> >
> > Can you give a bit more information about what are the values for 
> > operands 2,3 and 4 in your example testcases?
> 
>  For sbfiz32 we have 3, 0 and 19 respectively. For sbfiz64 we have 6, 
>  0 and 38.
> 
> > I'm trying to understand why the value of operand 3 (the bit 
> > position the sign-extract starts from) doesn't get validated
> > in any way and doesn't play any role in the output...
> 
>  This may be an oversight. It seems operand 3 will always be 0 in 
>  this particular case i'm covering. It starts from 0, gets shifted x 
>  bits to the left and then y < x bits to the right). The operation is 
>  essentially an ashift of the bitfield followed by a sign-extension 
>  of the msb of the bitfield being extracted.
> 
>  Having a non-zero operand 3 from RTL means the shift amount won't 
>  translate directly to operand 3 of sbfiz (the position). Then we'd 

[PATCH] libstdc++/85184 remove __glibcxx_assert assertions from

[Jonathan Wakely]

As I said in the bugzilla PR, these assertions are all to catch our
own mistakes, not user error.

If we're comfortable the code is correct then we should remove them.

Should we wait until near the end of stage 1, to get more time with
these checks in place?


diff --git a/libstdc++-v3/ChangeLog b/libstdc++-v3/ChangeLog
index 8359f4f5335..a3d74966435 100644
--- a/libstdc++-v3/ChangeLog
+++ b/libstdc++-v3/ChangeLog
@@ -1,3 +1,8 @@
+2018-05-15  Jonathan Wakely  
+
+	PR libstdc++/85184
+	* include/std/variant: Remove all uses of __glibcxx_assert.
+
 2018-05-15  Jonathan Wakely  
 
 	PR libstdc++/85749
diff --git a/libstdc++-v3/include/std/variant b/libstdc++-v3/include/std/variant
index c0212404bb2..efc1d3bf1e0 100644
--- a/libstdc++-v3/include/std/variant
+++ b/libstdc++-v3/include/std/variant
@@ -555,7 +555,6 @@ namespace __variant
 		__throw_exception_again;
 	  }
 	  }
-	__glibcxx_assert(this->_M_index == __rhs._M_index);
 	return *this;
   }
 
@@ -624,7 +623,6 @@ namespace __variant
 		__throw_exception_again;
 	  }
 	  }
-	__glibcxx_assert(this->_M_index == __rhs._M_index);
 	return *this;
   }
 
@@ -1105,7 +1103,7 @@ namespace __variant
 	noexcept(is_nothrow_constructible_v<__accepted_type<_Tp&&>, _Tp&&>)
 	: variant(in_place_index<__accepted_index<_Tp&&>>,
 		  std::forward<_Tp>(__t))
-	{ __glibcxx_assert(holds_alternative<__accepted_type<_Tp&&>>(*this)); }
+	{ }
 
   template
@@ -1114,7 +1112,7 @@ namespace __variant
 	variant(in_place_type_t<_Tp>, _Args&&... __args)
 	: variant(in_place_index<__index_of<_Tp>>,
 		  std::forward<_Args>(__args)...)
-	{ __glibcxx_assert(holds_alternative<_Tp>(*this)); }
+	{ }
 
   template
@@ -1125,7 +1123,7 @@ namespace __variant
 		_Args&&... __args)
 	: variant(in_place_index<__index_of<_Tp>>, __il,
 		  std::forward<_Args>(__args)...)
-	{ __glibcxx_assert(holds_alternative<_Tp>(*this)); }
+	{ }
 
   template, _Args&&... __args)
 	: _Base(in_place_index<_Np>, std::forward<_Args>(__args)...),
 	_Default_ctor_enabler(_Enable_default_constructor_tag{})
-	{ __glibcxx_assert(index() == _Np); }
+	{ }
 
   template,
@@ -1144,7 +1142,7 @@ namespace __variant
 		_Args&&... __args)
 	: _Base(in_place_index<_Np>, __il, std::forward<_Args>(__args)...),
 	_Default_ctor_enabler(_Enable_default_constructor_tag{})
-	{ __glibcxx_assert(index() == _Np); }
+	{ }
 
   template
 	enable_if_t<__exactly_once<__accepted_type<_Tp&&>>
@@ -1160,7 +1158,6 @@ namespace __variant
 	std::get<__index>(*this) = std::forward<_Tp>(__rhs);
 	  else
 	this->emplace<__index>(std::forward<_Tp>(__rhs));
-	  __glibcxx_assert(holds_alternative<__accepted_type<_Tp&&>>(*this));
 	  return *this;
 	}
 
@@ -1171,7 +1168,6 @@ namespace __variant
 	{
 	  auto& ret =
 	this->emplace<__index_of<_Tp>>(std::forward<_Args>(__args)...);
-	  __glibcxx_assert(holds_alternative<_Tp>(*this));
 	  return ret;
 	}
 
@@ -1184,7 +1180,6 @@ namespace __variant
 	  auto& ret =
 	this->emplace<__index_of<_Tp>>(__il,
 	   std::forward<_Args>(__args)...);
-	  __glibcxx_assert(holds_alternative<_Tp>(*this));
 	  return ret;
 	}
 
@@ -1207,7 +1202,6 @@ namespace __variant
 	  this->_M_index = variant_npos;
 	  __throw_exception_again;
 	}
-	  __glibcxx_assert(index() == _Np);
 	  return std::get<_Np>(*this);
 	}
 
@@ -1230,7 +1224,6 @@ namespace __variant
 	  this->_M_index = variant_npos;
 	  __throw_exception_again;
 	}
-	  __glibcxx_assert(index() == _Np);
 	  return std::get<_Np>(*this);
 	}
 

Re: [PATCH][AArch64] Set SLOW_BYTE_ACCESS

[Richard Earnshaw (lists)]

On 15/05/18 17:01, Wilco Dijkstra wrote:
> Hi,
>  
>> I see nothing about you addressing James' comment from 17th November...
> 
> I addressed that in a separate patch, see 
> https://patchwork.ozlabs.org/patch/839126/
> 
> Wilco
> 

Which doesn't appear to have been approved.  Did you follow up with Jeff?

R.

[Bug tree-optimization/85794] [8/9 Regression][AArch64] ICE in expand_vector_condition in GIMPLE pass: veclower2

[ktkachov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85794

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-15
 CC||ktkachov at gcc dot gnu.org
   Target Milestone|--- |8.2
 Ever confirmed|0   |1

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Confirmed.

[Bug libstdc++/85749] Possible -Wsign-conversion false negative with std::default_random_engine

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85749

Jonathan Wakely  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |9.0

--- Comment #4 from Jonathan Wakely  ---
Fixed on trunk.

Re: Possible bug in cse.c affecting pre/post-modify mem access

[A. Skrobov]

 That makes me wonder if there is a latent bug though.  Consider pushing
 args to a pure function.  Could we then try to CSE the memory reference
 and get it wrong because we haven't accounted for the autoinc?
>>>
>>> Can't know for sure but one would hope something would test for
>>> side_effects_p.
>>
>> If side_effects_p were checked in all the right places, then our port
>> (which is more liberal at generating auto-inc insns in early passes)
>> wouldn't have cse generate incorrect code, right?
>
> No, I'd expect you'd also need to make sure cse and other passes
> understand the side effects. I think it's best not to emit these insns
> early, unless you are prepared to put a lot of effort in to fix up the
> early passes. My recommendation is to change the port.

I understand that we should change our port; my point is, if cse
behaves incorrectly for _our_ auto-inc insns, wouldn't it also behave
incorrectly for _others'_ auto-inc insns such as stack pushes?

Re: [PATCH] PR libstdc++/85749 constrain seed sequences for random number engines

[Jonathan Wakely]

On 15/05/18 16:36 +0100, Jonathan Wakely wrote:

Constrain constructors and member functions of random number engines so
that functions taking seed sequences can only be called with types that
meet the seed sequence requirements.

PR libstdc++/85749
* include/bits/random.h (__detail::__is_seed_seq): New SFINAE helper.
(linear_congruential_engine, mersenne_twister_engine)
(subtract_with_carry_engine, discard_block_engine)
(independent_bits_engine, shuffle_order_engine): Use __is_seed_seq to
constrain function templates taking seed sequences.
* include/bits/random.tcc (linear_congruential_engine::seed(_Sseq&))
(mersenne_twister_engine::seed(_Sseq&))
(subtract_with_carry_engine::seed(_Sseq&)): Change return types to
match declarations.
* include/ext/random (simd_fast_mersenne_twister_engine): Use
__is_seed_seq to constrain function templates taking seed sequences.
* include/ext/random.tcc (simd_fast_mersenne_twister_engine::seed):
Change return type to match declaration.
* testsuite/26_numerics/random/discard_block_engine/cons/seed_seq2.cc:
New.
* testsuite/26_numerics/random/independent_bits_engine/cons/
seed_seq2.cc: New.
* testsuite/26_numerics/random/linear_congruential_engine/cons/
seed_seq2.cc: New.
* testsuite/26_numerics/random/mersenne_twister_engine/cons/
seed_seq2.cc: New.
* testsuite/26_numerics/random/pr60037-neg.cc: Adjust dg-error lineno.
* testsuite/26_numerics/random/shuffle_order_engine/cons/seed_seq2.cc:
New.
* testsuite/26_numerics/random/subtract_with_carry_engine/cons/
seed_seq2.cc: New.
* testsuite/ext/random/simd_fast_mersenne_twister_engine/cons/
seed_seq2.cc: New.

Tested powerpc64le-linux, committed to trunk.





commit 2197343e0cb9439687e453f37bf9ea2908bd499d
Author: Jonathan Wakely 
Date:   Sat May 12 00:22:23 2018 +0100

   PR libstdc++/85749 constrain seed sequences for random number engines
   
   Constrain constructors and member functions of random number engines so

   that functions taking seed sequences can only be called with types that
   meet the seed sequence requirements.
   
   PR libstdc++/85749

   * include/bits/random.h (__detail::__is_seed_seq): New SFINAE helper.
   (linear_congruential_engine, mersenne_twister_engine)
   (subtract_with_carry_engine, discard_block_engine)
   (independent_bits_engine, shuffle_order_engine): Use __is_seed_seq to
   constrain function templates taking seed sequences.
   * include/bits/random.tcc (linear_congruential_engine::seed(_Sseq&))
   (mersenne_twister_engine::seed(_Sseq&))
   (subtract_with_carry_engine::seed(_Sseq&)): Change return types to
   match declarations.
   * include/ext/random (simd_fast_mersenne_twister_engine): Use
   __is_seed_seq to constrain function templates taking seed sequences.
   * include/ext/random.tcc (simd_fast_mersenne_twister_engine::seed):
   Change return type to match declaration.
   * 
testsuite/26_numerics/random/discard_block_engine/cons/seed_seq2.cc:
   New.
   * testsuite/26_numerics/random/independent_bits_engine/cons/
   seed_seq2.cc: New.
   * testsuite/26_numerics/random/linear_congruential_engine/cons/
   seed_seq2.cc: New.
   * testsuite/26_numerics/random/mersenne_twister_engine/cons/
   seed_seq2.cc: New.
   * testsuite/26_numerics/random/pr60037-neg.cc: Adjust dg-error 
lineno.
   * 
testsuite/26_numerics/random/shuffle_order_engine/cons/seed_seq2.cc:
   New.
   * testsuite/26_numerics/random/subtract_with_carry_engine/cons/
   seed_seq2.cc: New.
   * testsuite/ext/random/simd_fast_mersenne_twister_engine/cons/
   seed_seq2.cc: New.

diff --git a/libstdc++-v3/include/bits/random.h 
b/libstdc++-v3/include/bits/random.h
index f812bbf18b1..b76cfbb558e 100644
--- a/libstdc++-v3/include/bits/random.h
+++ b/libstdc++-v3/include/bits/random.h
@@ -185,6 +185,21 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
_Engine& _M_g;
  };

+template
+  using __seed_seq_generate_t = decltype(
+ std::declval<_Sseq&>().generate(std::declval(),
+ std::declval()));
+
+// Detect whether _Sseq is a valid seed sequence for
+// a random number engine _Engine with result type _Res.
+template>
+  using __is_seed_seq = __and_<
+__not_, _Engine>>,
+   is_unsigned,
+   __not_>
+  >;
+
  } // namespace __detail


I'm considering backporting this, with a simpler constraint:

   // Detect whether _Sseq is a valid seed sequence for
   // a random number 

[Bug c++/85783] alloc-size-larger-than fires incorrectly with new[] and can't be disabled

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85783

--- Comment #6 from Martin Sebor  ---
Inlining happens automatically unless it's disabled.  The inlining of the
operator results in the excessive constant argument (created by the C++
front-end) to propagate to the call to malloc().  That's what triggers the
warning.  The GIMPLE for the function in my smaller test case (from the output
of -fdump-tree-gimple) shows this:

f (size_t n)
{
  void * D.6084;
  void * D.6059;
  size_t iftmp.1;
  long unsigned int n.2;
  struct A * retval.3;
  struct A * D.6060;
  struct A * D.6061;
  long int D.6062;
  size_t iftmp.4;

  if (n == 0) goto ; else goto ;
  :
  D.6084 = 0B;
  // predicted unlikely by early return (on trees) predictor.
  return D.6084;
  :
  n.2 = n;
  if (n.2 <= 9223372036854775800) goto ; else goto ;
  :
  iftmp.1 = n.2 + 8;
  goto ;
  :
  iftmp.1 = 18446744073709551615;   <<< SIZE_MAX
  :
  D.6059 = operator new [] (iftmp.1);   <<< call to replacement operator new
  MEM[(sizetype *)D.6059] = n.2;

(Adding attribute noinline to the operator eliminates the warning.)

As we discussed in the past, the C++ standard imposes a couple of requirements
on replacement operator new that your test case violates:

1) it must not be declared inline (there must be exactly one operator new in a
program)
2) it must either return valid new pointer or fail by throwing an exception

To make the test case strictly valid the replacement operator would either have
to throw, or it would have to be the nothrow form (taking const std::nothrow_t&
as an argument), and the call to it would have to pass it std::nothrow.

The warning doesn't trigger if the replacement operator throws.  It does
trigger for the nothrow operator, which is why I agree the warning in that case
is a false positive.  (But you're not replacing the nothrow operator.)

Having said that, the C++ standard requires compilers to avoid calling the
allocation function with an argument in excess of some implementation-defined
limit, but GCC calls it regardless (e.g., it calls it with N = SIZE_MAX for new
(nothrow) T[N] even when sizeof (T) > 1).  That's a bug, and (indirectly) the
reason for the warning.  I've raised bug 85795 for that.

[Bug lto/85583] [9 Regression] lto1: internal compiler error: in lto_balanced_map, at lto/lto-partition.c:833

[hubicka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85583

--- Comment #7 from Jan Hubicka  ---
Author: hubicka
Date: Tue May 15 16:39:43 2018
New Revision: 260266

URL: https://gcc.gnu.org/viewcvs?rev=260266=gcc=rev
Log:

PR lto/85583
* lto-partition.c (account_reference_p): Do not account
references from aliases; do not account refernces from
external initializers.

Modified:
trunk/gcc/lto/ChangeLog
trunk/gcc/lto/lto-partition.c

[Bug c++/85795] New: bad_alloc thrown from allocation function when bad_array_length is expected

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85795

Bug ID: 85795
   Summary: bad_alloc thrown from allocation function when
bad_array_length is expected
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

(This report was prompted by bug 85783.)

In [expr.new], p7, the C++ standard requires implementations to avoid calling
an allocation function when the non-constant size expression in a new
expression is in excess of some implementation-defined limit.  I can't find
this limit documented anywhere but it stands to reason it's no more than
SIZE_MAX.  The program below shows that G++ violates this requirement and calls
the allocation function regardless.  The code that causes this was added in
r190546 as a fix for bug 19351.  (Jason privately confirmed that this is a
likely bug.)

$ cat u.C && g++ -O2 -Wall u.C && ./a.out 
#include 

typedef __SIZE_TYPE__ size_t;

void* operator new[](size_t n)
{
  __builtin_printf ("%s (%zx)\n", __func__, n);

  if (void* p = __builtin_malloc (n))
return p;

  throw std::bad_alloc ();
}

struct A
{
  int i;

  A ();
  ~A ();
};

__attribute__ ((noipa)) A::A () { }
__attribute__ ((noipa)) A::~A () { }

size_t n = __SIZE_MAX__ / 2 - 1;

int main ()
{
  __builtin_printf ("calling new A[%zx]: expect bad_array_new_length\n", n);

  try {
void *p = new A[n];
__builtin_printf ("%p: failure\n", p);
  }
  catch (const std::bad_array_new_length&) {
__builtin_printf ("caught bad_array_new_length: success\n");
return 0;
  }
  catch (const std::bad_alloc&) {
__builtin_printf ("caught bad_alloc: failure\n");
  }
  catch (...) {
__builtin_printf ("caught unknown exception: failure\n");
  }

  __builtin_abort ();
}
calling new A[7ffe]: expect bad_array_new_length
operator new [] ()
caught bad_alloc: failure
Aborted (core dumped)

Re: [wwwdocs] Describe how to validate wwwdocs changes

[David Malcolm]

On Sun, 2018-05-13 at 22:19 -0600, Gerald Pfeifer wrote:
> This is triggered by a report from Martin who rightfully pointed 
> out that it's not straightforward to validate wwwdocs changes before 
> committing a change.
> 
> Martin, what do you think?  Would that have avoided the challenges
> your ran into?  Anything to better clarify or otherwise improve?

Possibly a silly question, but why can't we just change all the headers
in the site source to be this?

Is is something to do with the conversion toolchain?

> Gerald
> 
> Index: about.html
> ===
> RCS file: /cvs/gcc/wwwdocs/htdocs/about.html,v
> retrieving revision 1.28
> diff -u -r1.28 about.html
> --- about.html6 May 2018 16:19:24 -   1.28
> +++ about.html14 May 2018 04:11:25 -
> +Validating a change
> +
> +To validate any changes, you can use the  +href="https://validator.w3.org;>W3 Validator. Just replace the
> +html tag at the beginning of the document with the following
> +snippet and use the "Validate by File Upload" functionality.
> +
> +
> +?xml version="1.0" encoding="utf-8"?
> +!DOCTYPE html
> +  PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
> +  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";
> +html xmlns="http://www.w3.org/1999/xhtml; xml:lang="en"
> lang="en"
> +
> +
>  Checking in a change
>  
>  We recommend you list files explicitly to avoid accidental
> checkins

Re: [PATCH][AArch64] Set SLOW_BYTE_ACCESS

[Wilco Dijkstra]

Hi,
 
> I see nothing about you addressing James' comment from 17th November...

I addressed that in a separate patch, see 
https://patchwork.ozlabs.org/patch/839126/

Wilco

Fix partitioning ICE

[Jan Hubicka]

Hi,
this patch silences sanity check that makes sure that everything is in
partition 0 and thus boundary cost is 0 when there is only one partition.
In the testcase there is external initializer which does not get partitioned
and thus we end up with cost 1.  Fixed by not accounting references from
external initializers.

Bootstrapped/regtsted x86_64-linux, will commit it after finishing ltobootstrap.

Honza

* torture/pr85583.C: New testcase.

* lto-partition.c (account_reference_p): Do not account
references from aliases; do not account refernces from
external initializers.
Index: testsuite/g++.dg/torture/pr85583.C
===
--- testsuite/g++.dg/torture/pr85583.C  (nonexistent)
+++ testsuite/g++.dg/torture/pr85583.C  (working copy)
@@ -0,0 +1,13 @@
+/* { dg-do link } */
+class b {
+public:
+  virtual ~b();
+};
+template  class c : b {};
+class B {
+  c d;
+};
+extern template class c;
+int
+main(void) { B a; return 0; }
+
Index: lto/lto-partition.c
===
--- lto/lto-partition.c (revision 260258)
+++ lto/lto-partition.c (working copy)
@@ -439,13 +439,28 @@
 {
   if (cgraph_node *cnode = dyn_cast  (n1))
 n1 = cnode;
+  /* Do not account references from aliases - they are never split across
+ partitions.  */
+  if (n1->alias)
+return false;
   /* Do not account recursion - the code below will handle it incorrectly
- otherwise.  Also do not account references to external symbols.
- They will never become local.  */
+ otherwise.  Do not account references to external symbols: they will
+ never become local.  Finally do not account references to duplicated
+ symbols: they will be always local.  */
   if (n1 == n2 
-  || DECL_EXTERNAL (n2->decl)
-  || !n2->definition)
+  || !n2->definition
+  || n2->get_partitioning_class () != SYMBOL_PARTITION)
 return false;
+  /* If referring node is external symbol do not account it to boundary
+ cost. Those are added into units only to enable possible constant
+ folding and devirtulization.
+
+ Here we do not know if it will ever be added to some partition
+ (this is decided by compute_ltrans_boundary) and second it is not
+ that likely that constant folding will actually use the reference.  */
+  if (contained_in_symbol (n1)
+   ->get_partitioning_class () == SYMBOL_EXTERNAL)
+return false;
   return true;
 }
 

Re: [PATCH][AArch64] Set SLOW_BYTE_ACCESS

[Richard Earnshaw (lists)]

On 15/05/18 14:24, Wilco Dijkstra wrote:
> 
> ping
> 
> 

I see nothing about you addressing James' comment from 17th November...


> 
> 
> From: Wilco Dijkstra
> Sent: 17 November 2017 15:21
> To: GCC Patches
> Cc: nd
> Subject: [PATCH][AArch64] Set SLOW_BYTE_ACCESS
>   
> 
> Contrary to all documentation, SLOW_BYTE_ACCESS simply means accessing
> bitfields by their declared type, which results in better codegeneration on 
> practically
> any target.
> 
> I'm thinking we should completely remove all trace of SLOW_BYTE_ACCESS
> from GCC as it's confusing and useless.
> 
> OK for commit until we get rid of it?
> 
> ChangeLog:
> 2017-11-17  Wilco Dijkstra  
> 
>     gcc/
>     * config/aarch64/aarch64.h (SLOW_BYTE_ACCESS): Set to 1.
> --
> diff --git a/gcc/config/aarch64/aarch64.h b/gcc/config/aarch64/aarch64.h
> index 
> 056110afb228fb919e837c04aa5e5552a4868ec3..d8f4d129a02fb89eb00d256aba8c4764d6026078
>  100644
> --- a/gcc/config/aarch64/aarch64.h
> +++ b/gcc/config/aarch64/aarch64.h
> @@ -769,14 +769,9 @@ typedef struct
>     if given data not on the nominal alignment.  */
>  #define STRICT_ALIGNMENT    TARGET_STRICT_ALIGN
>  
> -/* Define this macro to be non-zero if accessing less than a word of
> -   memory is no faster than accessing a word of memory, i.e., if such
> -   accesses require more than one instruction or if there is no
> -   difference in cost.
> -   Although there's no difference in instruction count or cycles,
> -   in AArch64 we don't want to expand to a sub-word to a 64-bit access
> -   if we don't have to, for power-saving reasons.  */
> -#define SLOW_BYTE_ACCESS   0
> +/* Contrary to all documentation, this enables wide bitfield accesses,
> +   which results in better code when accessing multiple bitfields.  */
> +#define SLOW_BYTE_ACCESS   1
>  
>  #define NO_FUNCTION_CSE 1
> 
> 
> 

[Bug tree-optimization/85793] [8/9 Regression][AARCH64] ICE in verify_gimple during GIMPLE pass vect.

[amker at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85793

amker at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-15
 CC||amker at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from amker at gcc dot gnu.org ---
Confirmed.  I will have a look.

[Bug target/85791] multiply overflow (128 bit)

[glisse at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85791

--- Comment #4 from Marc Glisse  ---
(In reply to Ruslan Nikolaev from comment #0)
> 2. unsigned long long func(unsigned long long a, unsigned long long b)
> {
> __uint128_t c = (__uint128_t) a * b;
> if (c > (unsigned long long) -1LL) {

It should not be too hard to recognize in GIMPLE the case of a widening mul of
unsigned numbers that has only 2 uses, one narrowing, the other comparing to
this constant (or to a widened version of the narrowed value, or extracting the
high part and comparing it to 0, etc).

Independently, it may be possible to teach RTL/target that some mul+cmp+jump is
equivalent to mul+jmp.

[Bug other/85778] unexpected results with -O2, wrong code?

[sesail999 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85778

--- Comment #4 from Scott Emmons  ---
> glibc has stat annotated with nonnull(1, 2)

1. Can you provide a reference to this code? This is helpful so that other
people running into this (and it *will* happen, this ancient code no longer
runs correctly). Thank you.

2. The manpage for stat(2) should be updated to reflect that calling stat()
with a NULL pathname will result in unpredictable behavior.

3. I'll create a pull request against cronolog and work with Debian/Ubuntu to
at least get it fixed in those distributions.

Re: [PATCH GCC][4/6]Support regional coalesce and live range computation

[Bin.Cheng]

On Fri, May 11, 2018 at 1:53 PM, Richard Biener
 wrote:
> On Fri, May 4, 2018 at 6:23 PM, Bin Cheng  wrote:
>> Hi,
>> Following Jeff's suggestion, I am now using existing tree-ssa-live.c and
>> tree-ssa-coalesce.c to compute register pressure, rather than inventing
>> another live range solver.
>>
>> The major change is to record region's basic blocks in var_map and use that
>> information in computation, rather than FOR_EACH_BB_FN.  For now only loop
>> and function type regions are supported.  The default one is function type
>> region which is used in out-of-ssa.  Loop type region will be used in next
>> patch to compute information for a loop.
>>
>> Bootstrap and test on x86_64 and AArch64 ongoing.  Any comments?
>
> I believe your changes to create_outofssa_var_map should be done differently
> by simply only calling it from the coalescing context and passing in the
> var_map rather than initializing it therein and returning it.
>
> This also means the coalesce_vars_p flag in the var_map structure looks
> somewhat out-of-place.  That is, it looks you could do with many less
> changes if you refactored what calls what slightly?  For example
> the extra arg to gimple_can_coalesce_p looks unneeded.
>
> Just as a note I do have a CFG helper pending that computes RPO order
> for SEME regions (attached).  loops are SEME regions, so your RTYPE_SESE
> is somewhat odd - I guess RTYPE_LOOP exists only because of the
> convenience of passing in a loop * to the "constructor".  I'd rather
> drop this region_type thing and always assume a SEME region - at least
> I didn't see anything in the patch that depends on any of the forms
> apart from the initial BB gathering.

Hi Richard,

Thanks for reviewing.  I refactored tree-ssa-live.c and
tree-ssa-coalesce.c following your comments.
Basically I did following changes:
1) Remove region_type and only support loop region live range computation.
Also I added one boolean field in var_map indicating whether we
are computing
loop region live range or out-of-ssa.
2) Refactored create_outofssa_var_map into create_coalesce_list_for_region and
populate_coalesce_list_for_outofssa.  Actually the original
function name doesn't
quite make sense because it has nothing to do with var_map.
3) Hoist init_var_map up in call stack.  Now it's called by caller
(out-of-ssa or live range)
and the returned var_map is passed to coalesce_* stuff.
4) Move global functions to tree-outof-ssa.c and make them static.
5) Save/restore flag_tree_coalesce_vars in order to avoid updating
checks on the flag.

So how is this one?  Patch attached.

Thanks,
bin
2018-05-15  Bin Cheng  

* tree-outof-ssa.c (tree-ssa.h, tree-dfa.h): Include header files.
(create_default_def, for_all_parms): Moved from tree-ssa-coalesce.c.
(parm_default_def_partition_arg): Ditto.
(set_parm_default_def_partition): Ditto.
(get_parm_default_def_partitions): Ditto and make it static.
(get_undefined_value_partitions): Ditto and make it static.
(remove_ssa_form): Refactor call to init_var_map here.
* tree-ssa-coalesce.c (build_ssa_conflict_graph): Support live range
computation for loop region.
(coalesce_partitions, compute_optimized_partition_bases): Ditto.
(register_default_def): Delete.
(for_all_parms, create_default_def): Move to tree-outof-ssa.c.
(parm_default_def_partition_arg): Ditto.
(set_parm_default_def_partition): Ditto.
(get_parm_default_def_partitions): Ditto and make it static.
(get_undefined_value_partitions): Ditto and make it static.
(coalesce_with_default, coalesce_with_default): Update comment.
(create_coalesce_list_for_region): New func factored out from
create_outofssa_var_map.
(populate_coalesce_list_for_outofssa): New func factored out from
create_outofssa_var_map and coalesce_ssa_name.
(create_outofssa_var_map): Delete.
(coalesce_ssa_name): Refactor to support live range computation.
* tree-ssa-coalesce.h (coalesce_ssa_name): Change decl.
(get_parm_default_def_partitions): Delete.
(get_undefined_value_partitions): Ditto.
* tree-ssa-live.c (init_var_map, delete_var_map): Support live range
computation for loop region.
(new_tree_live_info, loe_visit_block): Ditto.
(live_worklist, set_var_live_on_entry): Ditto.
(calculate_live_on_exit, verify_live_on_entry): Ditto.
* tree-ssa-live.h (struct _var_map): New fields.
(init_var_map): Change decl.
(region_contains_p): New.
From 1043540cd5325c65e60df25cad22c343e4312fd4 Mon Sep 17 00:00:00 2001
From: Bin Cheng 
Date: Fri, 4 May 2018 09:39:17 +0100
Subject: [PATCH 4/6] liverange-support-region-20180504

---
 gcc/tree-outof-ssa.c| 102 +++-
 gcc/tree-ssa-coalesce.c | 317 +---
 gcc/tree-ssa-coalesce.h |   4 +-
 gcc/tree-ssa-live.c |  78 
 

[Bug tree-optimization/85794] New: [8/9 Regression][AArch64] ICE in expand_vector_condition in GIMPLE pass: veclower2

[sudi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85794

Bug ID: 85794
   Summary: [8/9 Regression][AArch64] ICE in
expand_vector_condition in GIMPLE pass: veclower2
   Product: gcc
   Version: 8.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sudi at gcc dot gnu.org
  Target Milestone: ---

The following code ICEs with -O3 with aarch64-none-linux-gnu

int a, b, *c, d, *e;
int *f[6];
void fn1() {
  b = 1;
  for (; b >= 0; b--) {
d = 0;
for (; d <= 3; d++) {
  int **g = 
  *g = 
  *e |= f[b * 5] != c;
}
  }
}

./build-aarch64-none-linux-gnu/install/bin/aarch64-none-linux-gnu-gcc f.c -O3
-S -fdump-tree-all
during GIMPLE pass: veclower2
dump file: f.c.173t.veclower21
f.c: In function ‘fn1’:
f.c:6:6: internal compiler error: Segmentation fault
 void fn1() {
  ^~~
0xbd57ff crash_signal
/work/trunk/src/gcc/gcc/toplev.c:325
0xe55d90 tree_class_check
/work/trunk/src/gcc/gcc/tree.h:3257
0xe55d90 expand_vector_condition
/work/trunk/src/gcc/gcc/tree-vect-generic.c:901
0xe587c1 expand_vector_operations_1
/work/trunk/src/gcc/gcc/tree-vect-generic.c:1582
0xe587c1 expand_vector_operations
/work/trunk/src/gcc/gcc/tree-vect-generic.c:1829
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug libstdc++/85749] Possible -Wsign-conversion false negative with std::default_random_engine

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85749

--- Comment #3 from Jonathan Wakely  ---
Author: redi
Date: Tue May 15 15:36:46 2018
New Revision: 260263

URL: https://gcc.gnu.org/viewcvs?rev=260263=gcc=rev
Log:
PR libstdc++/85749 constrain seed sequences for random number engines

Constrain constructors and member functions of random number engines so
that functions taking seed sequences can only be called with types that
meet the seed sequence requirements.

PR libstdc++/85749
* include/bits/random.h (__detail::__is_seed_seq): New SFINAE helper.
(linear_congruential_engine, mersenne_twister_engine)
(subtract_with_carry_engine, discard_block_engine)
(independent_bits_engine, shuffle_order_engine): Use __is_seed_seq to
constrain function templates taking seed sequences.
* include/bits/random.tcc (linear_congruential_engine::seed(_Sseq&))
(mersenne_twister_engine::seed(_Sseq&))
(subtract_with_carry_engine::seed(_Sseq&)): Change return types to
match declarations.
* include/ext/random (simd_fast_mersenne_twister_engine): Use
__is_seed_seq to constrain function templates taking seed sequences.
* include/ext/random.tcc (simd_fast_mersenne_twister_engine::seed):
Change return type to match declaration.
* testsuite/26_numerics/random/discard_block_engine/cons/seed_seq2.cc:
New.
* testsuite/26_numerics/random/independent_bits_engine/cons/
seed_seq2.cc: New.
* testsuite/26_numerics/random/linear_congruential_engine/cons/
seed_seq2.cc: New.
* testsuite/26_numerics/random/mersenne_twister_engine/cons/
seed_seq2.cc: New.
* testsuite/26_numerics/random/pr60037-neg.cc: Adjust dg-error lineno.
* testsuite/26_numerics/random/shuffle_order_engine/cons/seed_seq2.cc:
New.
* testsuite/26_numerics/random/subtract_with_carry_engine/cons/
seed_seq2.cc: New.
* testsuite/ext/random/simd_fast_mersenne_twister_engine/cons/
seed_seq2.cc: New.

Added:
   
trunk/libstdc++-v3/testsuite/26_numerics/random/discard_block_engine/cons/seed_seq2.cc
   
trunk/libstdc++-v3/testsuite/26_numerics/random/independent_bits_engine/cons/seed_seq2.cc
   
trunk/libstdc++-v3/testsuite/26_numerics/random/linear_congruential_engine/cons/seed_seq2.cc
   
trunk/libstdc++-v3/testsuite/26_numerics/random/mersenne_twister_engine/cons/seed_seq2.cc
   
trunk/libstdc++-v3/testsuite/26_numerics/random/shuffle_order_engine/cons/seed_seq2.cc
   
trunk/libstdc++-v3/testsuite/26_numerics/random/subtract_with_carry_engine/cons/seed_seq2.cc
   
trunk/libstdc++-v3/testsuite/ext/random/simd_fast_mersenne_twister_engine/cons/seed_seq2.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/random.h
trunk/libstdc++-v3/include/bits/random.tcc
trunk/libstdc++-v3/include/ext/random
trunk/libstdc++-v3/include/ext/random.tcc
trunk/libstdc++-v3/testsuite/26_numerics/random/pr60037-neg.cc

[PATCH] PR libstdc++/85749 constrain seed sequences for random number engines

[Jonathan Wakely]

Constrain constructors and member functions of random number engines so
that functions taking seed sequences can only be called with types that
meet the seed sequence requirements.

PR libstdc++/85749
* include/bits/random.h (__detail::__is_seed_seq): New SFINAE helper.
(linear_congruential_engine, mersenne_twister_engine)
(subtract_with_carry_engine, discard_block_engine)
(independent_bits_engine, shuffle_order_engine): Use __is_seed_seq to
constrain function templates taking seed sequences.
* include/bits/random.tcc (linear_congruential_engine::seed(_Sseq&))
(mersenne_twister_engine::seed(_Sseq&))
(subtract_with_carry_engine::seed(_Sseq&)): Change return types to
match declarations.
* include/ext/random (simd_fast_mersenne_twister_engine): Use
__is_seed_seq to constrain function templates taking seed sequences.
* include/ext/random.tcc (simd_fast_mersenne_twister_engine::seed):
Change return type to match declaration.
* testsuite/26_numerics/random/discard_block_engine/cons/seed_seq2.cc:
New.
* testsuite/26_numerics/random/independent_bits_engine/cons/
seed_seq2.cc: New.
* testsuite/26_numerics/random/linear_congruential_engine/cons/
seed_seq2.cc: New.
* testsuite/26_numerics/random/mersenne_twister_engine/cons/
seed_seq2.cc: New.
* testsuite/26_numerics/random/pr60037-neg.cc: Adjust dg-error lineno.
* testsuite/26_numerics/random/shuffle_order_engine/cons/seed_seq2.cc:
New.
* testsuite/26_numerics/random/subtract_with_carry_engine/cons/
seed_seq2.cc: New.
* testsuite/ext/random/simd_fast_mersenne_twister_engine/cons/
seed_seq2.cc: New.

Tested powerpc64le-linux, committed to trunk.


commit 2197343e0cb9439687e453f37bf9ea2908bd499d
Author: Jonathan Wakely 
Date:   Sat May 12 00:22:23 2018 +0100

PR libstdc++/85749 constrain seed sequences for random number engines

Constrain constructors and member functions of random number engines so
that functions taking seed sequences can only be called with types that
meet the seed sequence requirements.

PR libstdc++/85749
* include/bits/random.h (__detail::__is_seed_seq): New SFINAE helper.
(linear_congruential_engine, mersenne_twister_engine)
(subtract_with_carry_engine, discard_block_engine)
(independent_bits_engine, shuffle_order_engine): Use __is_seed_seq to
constrain function templates taking seed sequences.
* include/bits/random.tcc (linear_congruential_engine::seed(_Sseq&))
(mersenne_twister_engine::seed(_Sseq&))
(subtract_with_carry_engine::seed(_Sseq&)): Change return types to
match declarations.
* include/ext/random (simd_fast_mersenne_twister_engine): Use
__is_seed_seq to constrain function templates taking seed sequences.
* include/ext/random.tcc (simd_fast_mersenne_twister_engine::seed):
Change return type to match declaration.
* testsuite/26_numerics/random/discard_block_engine/cons/seed_seq2.cc:
New.
* testsuite/26_numerics/random/independent_bits_engine/cons/
seed_seq2.cc: New.
* testsuite/26_numerics/random/linear_congruential_engine/cons/
seed_seq2.cc: New.
* testsuite/26_numerics/random/mersenne_twister_engine/cons/
seed_seq2.cc: New.
* testsuite/26_numerics/random/pr60037-neg.cc: Adjust dg-error lineno.
* testsuite/26_numerics/random/shuffle_order_engine/cons/seed_seq2.cc:
New.
* testsuite/26_numerics/random/subtract_with_carry_engine/cons/
seed_seq2.cc: New.
* testsuite/ext/random/simd_fast_mersenne_twister_engine/cons/
seed_seq2.cc: New.

diff --git a/libstdc++-v3/include/bits/random.h b/libstdc++-v3/include/bits/random.h
index f812bbf18b1..b76cfbb558e 100644
--- a/libstdc++-v3/include/bits/random.h
+++ b/libstdc++-v3/include/bits/random.h
@@ -185,6 +185,21 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 	_Engine& _M_g;
   };
 
+template
+  using __seed_seq_generate_t = decltype(
+	  std::declval<_Sseq&>().generate(std::declval(),
+	  std::declval()));
+
+// Detect whether _Sseq is a valid seed sequence for
+// a random number engine _Engine with result type _Res.
+template>
+  using __is_seed_seq = __and_<
+__not_, _Engine>>,
+	is_unsigned,
+	__not_>
+  >;
+
   } // namespace __detail
 
   /**
@@ -233,6 +248,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   static_assert(__m == 0u || (__a < __m && __c < __m),
 		"template argument substituting __m out of bounds");
 
+  template
+	using _If_seed_seq 

[Bug tree-optimization/85720] bad codegen for looped assignment of primitives at -O2

[amker at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85720

--- Comment #6 from amker at gcc dot gnu.org ---
(In reply to Richard Biener from comment #5)
> (In reply to Mathias Stearn from comment #4)
> > (In reply to Marc Glisse from comment #3)
> > > Again, you are ignoring aliasing issues (just like in your other PR the
> > > function copy isn't equivalent to memmove). Does adding __restrict change
> > > the result? Also, B[i]=B[i]+1 doesn't look like a memset...
> > 
> > Sorry, I typoed. It was supposed to be B[i] = A[i] + 1. That still does
> > basically the same thing though: https://godbolt.org/g/dtmU5t. Good point
> > about aliasing though. I guess the right code gen in that case would
> > actually be something that detected the overlap and did the right calls to
> > memset to only set each byte once. Or just do the simple thing:
> > 
> > if (b > a && b < a + n) {
> >   memset(b, 1, n);
> >   memset(a, 0, n);
> > } else {
> >   memset(a, 0, n);
> >   memset(b, 1, n);
> > }
> > 
> > Yes, __restrict helps, but that isn't part of standard c++, and it seems
> > like it never will be.
> 
> GCC supports it since forever...  but yes, currently loop distribution
> doesn't consider runtime aliasing in this case (it can do it now but
This should be easy to improve for builtin distribution cases.
> is keyed to vectorization).  It also doesn't have a way to distinguish
> forward vs. backward dependence and split the case like you propose.
IMHO, this isn't optimizer's responsibility.  If break-conditions for
forward/backward dependence need to be supported, it seems more reasonable to
be supported in dependence analysis.

Re: [PR63185][RFC] Improve DSE with branches

[Jeff Law]

On 05/15/2018 02:15 AM, Richard Biener wrote:
> On Mon, 14 May 2018, Kugan Vivekanandarajah wrote:
> 
>> Hi,
>>
>> Attached patch handles PR63185 when we reach PHI with temp != NULLL.
>> We could see the PHI and if there isn't any uses for PHI that is
>> interesting, we could ignore that ?
>>
>> Bootstrapped and regression tested on x86_64-linux-gnu.
>> Is this OK?
> 
> No, as Jeff said we can't do it this way.
> 
> If we end up with multiple VDEFs in the walk of defvar immediate
> uses we know we are dealing with a CFG fork.  We can't really
> ignore any of the paths but we have to
> 
>  a) find the merge point (and the associated VDEF)
>  b) verify for each each chain of VDEFs with associated VUSEs
> up to that merge VDEF that we have no uses of the to classify
> store and collect (partial) kills
>  c) intersect kill info and continue walking from the merge point
Which makes me come back to "why is this structured as a forward walk?"
DSE seems much more naturally structured as a walk of the post-dominator
tree, walking instructions in reverse order.

Cases like 63185 would naturally fall out of that structure as the
clobber at the end of the function post-dominates the memset and there's
no intervening aliased loads.

In fact, I thought that's how I initially structured DSE.I'm not
sure when/why it changed.

Jeff

[Bug lto/85583] [9 Regression] lto1: internal compiler error: in lto_balanced_map, at lto/lto-partition.c:833

[hubicka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85583

--- Comment #6 from Jan Hubicka  ---
Problem is that we do not account correctly duplicated symbols because we do
not
add them into boundary
Index: lto/lto-partition.c
===
--- lto/lto-partition.c (revision 260258)
+++ lto/lto-partition.c (working copy)
@@ -439,13 +439,24 @@
 {
   if (cgraph_node *cnode = dyn_cast  (n1))
 n1 = cnode;
+  /* Do not account references from aliases - they are never split across
+ partitions.  */
+  if (n1->alias)
+return false;
   /* Do not account recursion - the code below will handle it incorrectly
- otherwise.  Also do not account references to external symbols.
- They will never become local.  */
+ otherwise.  Do not account references to external symbols: they will
+ never become local.  Finally do not account references to duplicated
+ symbols: they will be always local.  */
   if (n1 == n2 
-  || DECL_EXTERNAL (n2->decl)
-  || !n2->definition)
+  || !n2->definition
+  || n2->get_partitioning_class () != SYMBOL_PARTITION)
 return false;
+  /* If referring node is duplicated symbol, we can not compute the boundary
+ cost, because we do not know what partition will be added to until
+ the boundary is computed.  */
+  if (contained_in_symbol (n1)
+   ->get_partitioning_class () != SYMBOL_PARTITION)
+return false;
   return true;
 }

[PATCH] gdb/x86: Fix `-Wstrict-overflow' build error in `i387_collect_xsave'

[Maciej W. Rozycki]

Make `i' defined within `i387_collect_xsave' unsigned, removing a 
`-Werror=strict-overflow' compilation error:

.../gdb/i387-tdep.c: In function 'void i387_collect_xsave(const regcache*, int, 
void*, int)':
.../gdb/i387-tdep.c:1348:1: error: assuming signed overflow does not occur when 
assuming that (X + c) < X is always false [-Werror=strict-overflow]
 i387_collect_xsave (const struct regcache *regcache, int regnum,
 ^
cc1plus: all warnings being treated as errors
Makefile:1610: recipe for target 'i387-tdep.o' failed
make: *** [i387-tdep.o] Error 1

seen with GCC 5.4.0, a commit 8ee22052f690 ("gdb/x86: Handle kernels 
using compact xsave format") regression.  While `regnum' can be -1 on 
entry to the function, to mean all registers, `i' is only used with 
non-negative register numbers.

gdb/
* i387-tdep.c (i387_collect_xsave): Make `i' unsigned.
---
Hi,

 I believe this comes from register numbers being retrieved from the 
`tdep' structure at run time and therefore making the compiler unable to 
statically determine in loop expression processing that the calculations 
made on `i' will not cause a signed overflow.

 NB the error message pointing at the function definition rather than the 
declaration of `i' makes it rather difficult to determine what the actual 
cause might be.  I just hope it's only a peculiarity of the somewhat older 
version of the compiler and it has been fixed since.  Could someone from 
the GCC mailing list please comment on that?

 OK to apply?

  Maciej
---
 gdb/i387-tdep.c |7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

gdb-i387-collect-xsave-signed-overflow.diff
Index: gdb/gdb/i387-tdep.c
===
--- gdb.orig/gdb/i387-tdep.c2018-05-10 22:13:05.0 +0100
+++ gdb/gdb/i387-tdep.c 2018-05-13 23:27:46.194412211 +0100
@@ -1354,7 +1354,7 @@ i387_collect_xsave (const struct regcach
   gdb_byte *p, *regs = (gdb_byte *) xsave;
   gdb_byte raw[I386_MAX_REGISTER_SIZE];
   ULONGEST initial_xstate_bv, clear_bv, xstate_bv = 0;
-  int i;
+  unsigned int i;
   enum
 {
   x87_ctrl_or_mxcsr = 0x1,

Re: [PR63185][RFC] Improve DSE with branches

[Richard Biener]

On Tue, 15 May 2018, Richard Biener wrote:

> On Tue, 15 May 2018, Richard Biener wrote:
> 
> > On Tue, 15 May 2018, Richard Biener wrote:
> > 
> > > On Tue, 15 May 2018, Richard Biener wrote:
> > > 
> > > > On Mon, 14 May 2018, Kugan Vivekanandarajah wrote:
> > > > 
> > > > > Hi,
> > > > > 
> > > > > Attached patch handles PR63185 when we reach PHI with temp != NULLL.
> > > > > We could see the PHI and if there isn't any uses for PHI that is
> > > > > interesting, we could ignore that ?
> > > > > 
> > > > > Bootstrapped and regression tested on x86_64-linux-gnu.
> > > > > Is this OK?
> > > > 
> > > > No, as Jeff said we can't do it this way.
> > > > 
> > > > If we end up with multiple VDEFs in the walk of defvar immediate
> > > > uses we know we are dealing with a CFG fork.  We can't really
> > > > ignore any of the paths but we have to
> > > > 
> > > >  a) find the merge point (and the associated VDEF)
> > > >  b) verify for each each chain of VDEFs with associated VUSEs
> > > > up to that merge VDEF that we have no uses of the to classify
> > > > store and collect (partial) kills
> > > >  c) intersect kill info and continue walking from the merge point
> > > > 
> > > > in b) there's the optional possibility to find sinking opportunities
> > > > in case we have kills on some paths but uses on others.  This is why
> > > > DSE should be really merged with (store) sinking.
> > > > 
> > > > So if we want to enhance DSEs handling of branches then we need
> > > > to refactor the simple dse_classify_store function.  Let me take
> > > > an attempt at this today.
> > > 
> > > First (baby) step is the following - it arranges to collect the
> > > defs we need to continue walking from and implements trivial
> > > reduction by stopping at (full) kills.  This allows us to handle
> > > the new testcase (which was already handled in the very late DSE
> > > pass with the help of sinking the store).
> > > 
> > > I took the opportunity to kill the use_stmt parameter of
> > > dse_classify_store as the only user is only looking for whether
> > > the kills were all clobbers which I added a new parameter for.
> > > 
> > > I didn't adjust the byte-tracking case fully (I'm not fully understanding
> > > the code in the case of a use and I'm not sure whether it's worth
> > > doing the def reduction with byte-tracking).
> > > 
> > > Your testcase can be handled by reducing the PHI and the call def
> > > by seeing that the only use of a candidate def is another def
> > > we have already processed.  Not sure if worth special-casing though,
> > > I'd rather have a go at "recursing".  That will be the next
> > > patch.
> > > 
> > > Bootstrap & regtest running on x86_64-unknown-linux-gnu.
> > 
> > Applied.
> > 
> > Another intermediate one below, fixing the byte-tracking for
> > stmt with uses.  This also re-does the PHI handling by simply
> > avoiding recursion by means of a visited bitmap and stopping
> > at the DSE classify stmt when re-visiting it instead of failing.
> > This covers Pratamesh loop case for which I added ssa-dse-33.c.
> > For the do-while loop this still runs into the inability to
> > handle two defs to walk from.
> > 
> > Bootstrap & regtest running on x86_64-unknown-linux-gnu.
> 
> Ok, loop handling doesn't work in general since we run into the
> issue that SSA form across the backedge is not representing the
> same values.  Consider
> 
>  
>  # .MEM_22 = PHI <.MEM_12(D)(2), .MEM_13(4)>
>  # n_20 = PHI <0(2), n_7(4)>
>  # .MEM_13 = VDEF <.MEM_22>
>  bytes[n_20] = _4;
>  if (n_20 > 7)
>goto ;
> 
>  
>  n_7 = n_20 + 1;
>  # .MEM_15 = VDEF <.MEM_13>
>  bytes[n_20] = _5;
>  goto ;
> 
> then when classifying the store in bb4, visiting the PHI node
> gets us to the store in bb3 which appears to be killing.
> 
>if (gimple_code (temp) == GIMPLE_PHI)
> -   defvar = PHI_RESULT (temp);
> +   {
> + /* If we visit this PHI by following a backedge then reset
> +any info in ref that may refer to SSA names which we'd need
> +to PHI translate.  */
> + if (gimple_bb (temp) == gimple_bb (stmt)
> + || dominated_by_p (CDI_DOMINATORS, gimple_bb (stmt),
> +gimple_bb (temp)))
> +   /* ???  ref->ref may not refer to SSA names or it may only
> +  refer to SSA names that are invariant with respect to the
> +  loop represented by this PHI node.  */
> +   ref->ref = NULL_TREE;
> + defvar = PHI_RESULT (temp);
> + bitmap_set_bit (visited, SSA_NAME_VERSION (defvar));
> +   }
> 
> should be a workable solution for that.  I'm checking that, but
> eventually you can think of other things that might prevent us from
> handling backedges.  Note the current code tries to allow
> looking across loops but not handle backedges of loops the
> original stmt belongs to.

Just to mention before I leave for the day I think I've identified
a latent issue where I just fail to produce a 

[Bug tree-optimization/85793] [8/9 Regression][AARCH64] ICE in verify_gimple during GIMPLE pass vect.

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85793

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |8.2

[Bug c/85793] New: [8/9 Regression][AARCH64] ICE in verify_gimple during GIMPLE pass vect.

[sudi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85793

Bug ID: 85793
   Summary: [8/9 Regression][AARCH64] ICE in verify_gimple during
GIMPLE pass vect.
   Product: gcc
   Version: 8.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sudi at gcc dot gnu.org
  Target Milestone: ---

The following test case fails with aarch64-none-lunux-gnu-gcc -O3

int a, c, d;
long b[6];
void fn1() {
  for (; a < 2; a++) {
c = 0;
for (; c <= 5; c++)
  d &= b[a * 3];
  }
}

$ ./build-aarch64-none-linux-gnu/install/bin/aarch64-none-linux-gnu-gcc f.c -O3
-fdump-tree-all-all
f.c: In function ‘fn1’:
f.c:7:6: error: type mismatch in vector pack expression
 void fn1() {
  ^~~
vector(2) int
long int
long int
vect__3.16_63 = VEC_PACK_TRUNC_EXPR <_59, _61>;
during GIMPLE pass: vect
dump file: f.c.161t.vect
f.c:7:6: internal compiler error: verify_gimple failed
0xc2dcb8 verify_gimple_in_cfg(function*, bool)
/work/trunk/src/gcc/gcc/tree-cfg.c:5355
0xaee93a execute_function_todo
/work/trunk/src/gcc/gcc/passes.c:1994
0xaef385 execute_todo
/work/trunk/src/gcc/gcc/passes.c:2048
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c/53119] -Wmissing-braces wrongly warns about universal zero initializer {0}

[vincent-gcc at vinc17 dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53119

--- Comment #27 from Vincent Lefèvre  ---
(In reply to Waynem Ccollough from comment #26)
> Does the issue already fixed? 

For the simplest cases, it is. But complex cases still trigger a warning, see
e.g. PR 80454.

[Bug target/85791] multiply overflow (128 bit)

[nruslan_devel at yahoo dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85791

--- Comment #3 from Ruslan Nikolaev  ---
That is OK, I was talking about an extra 'cmp' instruction for the case when
the check is explicit

Fix PR85782: C++ ICE with continue statements inside acc loops

[Cesar Philippidis]

This patch resolves the issue in PR85782, which involves a C++ ICE
caused by OpenACC loops which contain continue statements. The problem
is that genericize_continue_stmt expects a continue label for the loop,
but that wasn't getting set up acc loops. This patch fixes that by
calling genericize_omp_for_stmt for OACC_LOOP statements, because
OACC_LOOP and OMP_FOR statements are almost identical at this point of
parsing.

I regression tested it on x86_64-linux with nvptx offloading.

Is this ok for trunk and the stable branches?  The patch for the stable
branches is slightly different, because cp_genericize_r uses if
statements to check for statement types instead of a huge switch statement.

Cesar
2018-05-15  Cesar Philippidis  

	PR c++/85782

	gcc/cp/
	* cp-gimplify.c (cp_genericize_r): Call genericize_omp_for_stmt for
	OACC_LOOPs.

	gcc/testsuite/
	* c-c++-common/goacc/pr85782.c: New test.

	libgomp/
	* testsuite/libgomp.oacc-c-c++-common/pr85782.c: New test.


diff --git a/gcc/cp/cp-gimplify.c b/gcc/cp/cp-gimplify.c
index eda5f05..55aef86 100644
--- a/gcc/cp/cp-gimplify.c
+++ b/gcc/cp/cp-gimplify.c
@@ -1463,6 +1463,7 @@ cp_genericize_r (tree *stmt_p, int *walk_subtrees, void *data)
 case OMP_FOR:
 case OMP_SIMD:
 case OMP_DISTRIBUTE:
+case OACC_LOOP:
   genericize_omp_for_stmt (stmt_p, walk_subtrees, data);
   break;
 
diff --git a/gcc/testsuite/c-c++-common/goacc/pr85782.c b/gcc/testsuite/c-c++-common/goacc/pr85782.c
new file mode 100644
index 000..f213a24
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/goacc/pr85782.c
@@ -0,0 +1,11 @@
+/* PR c++/85782 */
+
+void
+foo ()
+{
+  int i;
+  
+  #pragma acc parallel loop
+  for (i = 0; i < 100; i++)
+continue;
+}
diff --git a/libgomp/testsuite/libgomp.oacc-c-c++-common/pr85782.c b/libgomp/testsuite/libgomp.oacc-c-c++-common/pr85782.c
new file mode 100644
index 000..6f84dfc
--- /dev/null
+++ b/libgomp/testsuite/libgomp.oacc-c-c++-common/pr85782.c
@@ -0,0 +1,32 @@
+/* PR c++/85782 */
+
+#include 
+
+#define N 100
+
+int
+main ()
+{
+  int i, a[N];
+
+  for (i = 0; i < N; i++)
+a[i] = i+1;
+
+  #pragma acc parallel loop copy(a)
+  for (i = 0; i < N; i++)
+{
+  if (i % 2)
+	continue;
+  a[i] = 0;
+}
+
+  for (i = 0; i < N; i++)
+{
+  if (i % 2)
+	assert (a[i] == i+1);
+  else
+	assert (a[i] == 0);
+}
+
+return 0;
+}

[Bug c/53119] -Wmissing-braces wrongly warns about universal zero initializer {0}

[waynemccollough at gmx dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53119

Waynem Ccollough  changed:

   What|Removed |Added

 CC||waynemccollough at gmx dot com

--- Comment #26 from Waynem Ccollough  ---
Does the issue already fixed? 

Waynem Ccollough
https://amsterdamdiary.com/

[Bug libstdc++/84159] filesystem::path::operator/= with has root directory path

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84159

Jonathan Wakely  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Jonathan Wakely  ---
Fixed for 8.2, thanks for the report.

[Bug libstdc++/83891] std::filesystem::path::is_absolute for Windows

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83891

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |8.2

--- Comment #3 from Jonathan Wakely  ---
Fixed for 8.2, thanks for the report.

Re: [C++ Patch] Add DECL_MAYBE_IN_CHARGE_CDTOR_P

[Jason Merrill]

OK.

On Tue, May 15, 2018 at 8:07 AM, Paolo Carlini  wrote:
> Hi,
>
> noticed a few times while working on various issues, maybe we want to add
> the macro now? Tested x86_64-linux.
>
> Thanks, Paolo.
>
> 
>

[Bug libstdc++/83891] std::filesystem::path::is_absolute for Windows

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83891

--- Comment #2 from Jonathan Wakely  ---
Author: redi
Date: Tue May 15 13:51:03 2018
New Revision: 260260

URL: https://gcc.gnu.org/viewcvs?rev=260260=gcc=rev
Log:
PR libstdc++/83891 fix path::is_absolute() for non-POSIX targets

The correct definition seems to be has_root_directory() for all systems
we care about.

PR libstdc++/83891
* include/bits/fs_path.h (path::is_absolute()): Use same definition
for all operating systems.
* include/experimental/bits/fs_path.h (path::is_absolute()): Likewise.
* testsuite/27_io/filesystem/path/query/is_absolute.cc: New.
* testsuite/27_io/filesystem/path/query/is_relative.cc: Fix comment.
* testsuite/experimental/filesystem/path/query/is_absolute.cc: New.

Added:
   
branches/gcc-8-branch/libstdc++-v3/testsuite/27_io/filesystem/path/query/is_absolute.cc
   
branches/gcc-8-branch/libstdc++-v3/testsuite/experimental/filesystem/path/query/is_absolute.cc
Modified:
branches/gcc-8-branch/libstdc++-v3/ChangeLog
branches/gcc-8-branch/libstdc++-v3/include/bits/fs_path.h
branches/gcc-8-branch/libstdc++-v3/include/experimental/bits/fs_path.h
   
branches/gcc-8-branch/libstdc++-v3/testsuite/27_io/filesystem/path/query/is_relative.cc

[Bug libstdc++/83891] std::filesystem::path::is_absolute for Windows

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83891

--- Comment #1 from Jonathan Wakely  ---
Author: redi
Date: Tue May 15 13:50:49 2018
New Revision: 260259

URL: https://gcc.gnu.org/viewcvs?rev=260259=gcc=rev
Log:
PR libstdc++/83891 fix path::is_absolute() for non-POSIX targets

The correct definition seems to be has_root_directory() for all systems
we care about.

PR libstdc++/83891
* include/bits/fs_path.h (path::is_absolute()): Use same definition
for all operating systems.
* include/experimental/bits/fs_path.h (path::is_absolute()): Likewise.
* testsuite/27_io/filesystem/path/query/is_absolute.cc: New.
* testsuite/27_io/filesystem/path/query/is_relative.cc: Fix comment.
* testsuite/experimental/filesystem/path/query/is_absolute.cc: New.

Added:
trunk/libstdc++-v3/testsuite/27_io/filesystem/path/query/is_absolute.cc
   
trunk/libstdc++-v3/testsuite/experimental/filesystem/path/query/is_absolute.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/fs_path.h
trunk/libstdc++-v3/include/experimental/bits/fs_path.h
trunk/libstdc++-v3/testsuite/27_io/filesystem/path/query/is_relative.cc

[PATCH] PR libstdc++/83891 fix path::is_absolute() for non-POSIX targets

[Jonathan Wakely]

The correct definition seems to be has_root_directory() for all systems
we care about.

PR libstdc++/83891
* include/bits/fs_path.h (path::is_absolute()): Use same definition
for all operating systems.
* include/experimental/bits/fs_path.h (path::is_absolute()): Likewise.
* testsuite/27_io/filesystem/path/query/is_absolute.cc: New.
* testsuite/27_io/filesystem/path/query/is_relative.cc: Fix comment.
* testsuite/experimental/filesystem/path/query/is_absolute.cc: New.

Tested powerpc64le-linux and x86_64-linux, committed to trunk and
gcc-8-branch.


commit 82eb5d9bd748708bd0069e2045c2665f56c0e268
Author: Jonathan Wakely 
Date:   Tue May 15 14:32:43 2018 +0100

PR libstdc++/83891 fix path::is_absolute() for non-POSIX targets

The correct definition seems to be has_root_directory() for all systems
we care about.

PR libstdc++/83891
* include/bits/fs_path.h (path::is_absolute()): Use same definition
for all operating systems.
* include/experimental/bits/fs_path.h (path::is_absolute()): 
Likewise.
* testsuite/27_io/filesystem/path/query/is_absolute.cc: New.
* testsuite/27_io/filesystem/path/query/is_relative.cc: Fix comment.
* testsuite/experimental/filesystem/path/query/is_absolute.cc: New.

diff --git a/libstdc++-v3/include/bits/fs_path.h 
b/libstdc++-v3/include/bits/fs_path.h
index 53bf237b547..51af2891647 100644
--- a/libstdc++-v3/include/bits/fs_path.h
+++ b/libstdc++-v3/include/bits/fs_path.h
@@ -376,7 +376,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
 bool has_filename() const;
 bool has_stem() const;
 bool has_extension() const;
-bool is_absolute() const;
+bool is_absolute() const { return has_root_directory(); }
 bool is_relative() const { return !is_absolute(); }
 
 // generation
@@ -1071,16 +1071,6 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
 return ext.first && ext.second != string_type::npos;
   }
 
-  inline bool
-  path::is_absolute() const
-  {
-#ifdef _GLIBCXX_FILESYSTEM_IS_WINDOWS
-return has_root_name();
-#else
-return has_root_directory();
-#endif
-  }
-
   inline path::iterator
   path::begin() const
   {
diff --git a/libstdc++-v3/include/experimental/bits/fs_path.h 
b/libstdc++-v3/include/experimental/bits/fs_path.h
index 3b4011e6414..ada7c1791aa 100644
--- a/libstdc++-v3/include/experimental/bits/fs_path.h
+++ b/libstdc++-v3/include/experimental/bits/fs_path.h
@@ -368,7 +368,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
 bool has_filename() const;
 bool has_stem() const;
 bool has_extension() const;
-bool is_absolute() const;
+bool is_absolute() const { return has_root_directory(); }
 bool is_relative() const { return !is_absolute(); }
 
 // iterators
@@ -999,16 +999,6 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
 return ext.first && ext.second != string_type::npos;
   }
 
-  inline bool
-  path::is_absolute() const
-  {
-#ifdef _GLIBCXX_FILESYSTEM_IS_WINDOWS
-return has_root_name();
-#else
-return has_root_directory();
-#endif
-  }
-
   inline path::iterator
   path::begin() const
   {
diff --git a/libstdc++-v3/testsuite/27_io/filesystem/path/query/is_absolute.cc 
b/libstdc++-v3/testsuite/27_io/filesystem/path/query/is_absolute.cc
new file mode 100644
index 000..6b5c098489a
--- /dev/null
+++ b/libstdc++-v3/testsuite/27_io/filesystem/path/query/is_absolute.cc
@@ -0,0 +1,62 @@
+// { dg-options "-std=gnu++17 -lstdc++fs" }
+// { dg-do run { target c++17 } }
+// { dg-require-filesystem-ts "" }
+
+// Copyright (C) 2018 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3.  If not see
+// .
+
+// 30.11.7.4.9 path decomposition [fs.path.decompose]
+
+#include 
+#include 
+
+using std::filesystem::path;
+
+void
+test01()
+{
+  VERIFY( path("/").is_absolute() );
+  VERIFY( path("/foo").is_absolute() );
+  VERIFY( path("/foo/").is_absolute() );
+  VERIFY( path("/foo/bar").is_absolute() );
+  VERIFY( path("/foo/bar/").is_absolute() );
+  VERIFY( ! path("foo").is_absolute() );
+  VERIFY( ! path("foo/").is_absolute() );
+  VERIFY( ! path("foo/bar").is_absolute() );
+  VERIFY( ! path("foo/bar/").is_absolute() );
+  VERIFY( ! path("c:").is_absolute() );
+  VERIFY( ! path("c:foo").is_absolute() );
+  VERIFY( ! 

[Bug ipa/85655] [8/9 Regression] ICE with -flto and -O2 during IPA pass: cp lto1: internal compiler error: Segmentation fault

[jamborm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85655

--- Comment #8 from Martin Jambor  ---
The bug is latent on gcc7 and gcc6, I plan to commit the fix there at the end
of this week.

[Bug tree-optimization/85757] tree optimizers fail to fully clean up fixed-size memcpy

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85757

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

--- Comment #3 from Richard Biener  ---
Mine.  Working on some refactoring to make this possible.

[Bug c++/85776] ICE when compiling `boost::thread` with `-std=c++11` on mingw-w64

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85776

Richard Biener  changed:

   What|Removed |Added

 Status|WAITING |UNCONFIRMED
 Ever confirmed|1   |0

--- Comment #4 from Richard Biener  ---
Thanks.

Re: [PATCH][AArch64] Set SLOW_BYTE_ACCESS

[Wilco Dijkstra]

ping




From: Wilco Dijkstra
Sent: 17 November 2017 15:21
To: GCC Patches
Cc: nd
Subject: [PATCH][AArch64] Set SLOW_BYTE_ACCESS
  

Contrary to all documentation, SLOW_BYTE_ACCESS simply means accessing
bitfields by their declared type, which results in better codegeneration on 
practically
any target.

I'm thinking we should completely remove all trace of SLOW_BYTE_ACCESS
from GCC as it's confusing and useless.

OK for commit until we get rid of it?

ChangeLog:
2017-11-17  Wilco Dijkstra  

    gcc/
    * config/aarch64/aarch64.h (SLOW_BYTE_ACCESS): Set to 1.
--
diff --git a/gcc/config/aarch64/aarch64.h b/gcc/config/aarch64/aarch64.h
index 
056110afb228fb919e837c04aa5e5552a4868ec3..d8f4d129a02fb89eb00d256aba8c4764d6026078
 100644
--- a/gcc/config/aarch64/aarch64.h
+++ b/gcc/config/aarch64/aarch64.h
@@ -769,14 +769,9 @@ typedef struct
    if given data not on the nominal alignment.  */
 #define STRICT_ALIGNMENT    TARGET_STRICT_ALIGN
 
-/* Define this macro to be non-zero if accessing less than a word of
-   memory is no faster than accessing a word of memory, i.e., if such
-   accesses require more than one instruction or if there is no
-   difference in cost.
-   Although there's no difference in instruction count or cycles,
-   in AArch64 we don't want to expand to a sub-word to a 64-bit access
-   if we don't have to, for power-saving reasons.  */
-#define SLOW_BYTE_ACCESS   0
+/* Contrary to all documentation, this enables wide bitfield accesses,
+   which results in better code when accessing multiple bitfields.  */
+#define SLOW_BYTE_ACCESS   1
 
 #define NO_FUNCTION_CSE 1

[Bug target/85791] multiply overflow (128 bit)

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85791

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
  Component|c   |target

--- Comment #2 from Andrew Pinski  ---
Note on some x86, cmov is slower than using the conditional branch.

[Bug c/85791] multiply overflow (128 bit)

[nruslan_devel at yahoo dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85791

--- Comment #1 from Ruslan Nikolaev  ---
Optimization flags -O2 in all cases