Re: [RFC PATCH] avoid applying attributes to explicit specializations (PR 83871)

[Martin Sebor]

While reviewing other related bugs I noticed 83502.  This patch
doesn't fix the first test case in the bug (attribute noinline
vs always_inline).  Somehow those are still copied from
the primary to the specialization and can cause conflicts.


Hmm, that's odd.  Why is that?


Because duplicate_decl calls diagnose_mismatched_attributes()
on the NEWDECL and OLDDECL.  (Attribute optimize would do the
same thing.)  I was trying to keep the fix small but it makes
sense to take care of this as well so I have in this revision.


It does fix the second test case but with the noreturn change
it would issue a bogus -Wmissing-attributes warning for the
explicit specialization below.  Adding the warn_unused_result
attribute to it would then make GCC complain about a conflict
between the added attribute and noreturn, while removing it
would lead to worse code.

   template 
   int __attribute__ ((warn_unused_result)) f (T) { return 0; }

   template <>
   int __attribute__ ((noreturn)) f (int) { throw 0; }

   void fi () { f (0); }


I continue to disagree with this use of attribute noreturn.

+  /* Merge the function-has-side-effects bit.  */
+  if (TREE_THIS_VOLATILE (newdecl))
+TREE_THIS_VOLATILE (olddecl) = 1;
+
+  if (merge_attr)


TREE_THIS_VOLATILE means attribute noreturn, not whether the function
has side-effects; it should be handled in the blocks controlled by
merge_attr.


Whoops.  That was a silly goof.  I must have misread the comment
above the macro definition.  I also didn't have a test for it (or
some of the other changes I've made) so I didn't see the problem.

Attached is an enhanced version of the patch that handles (and
tests) more of the commonly used attributes.  I'm not sure why
in the merge_attr block I have to merge TREE_THIS_VOLATILE and
TREE_NOTHROW back and forth but not also READONLY, PURE, or
MALLOC, but without it tests fail.

Martin

PS Would it be possible to add a new macro with "noreturn" in
the name to make it more intuitive?  (And ditto perhaps also
for TREE_READONLY for "const" functions, though for whatever
reason that seems easier to decipher.  I know you're all used
to it but it's far from intuitive.)

PPS Duplicate_decls is over 1,400 lines long.  If there is more
work to do here in stage 1 (I suspect there might be), would you
mind if I broke it up into two or more, say one for functions,
another for types, or whatever grouping makes most sense to make
it easier to follow?
PR c++/83871 - wrong code for attribute const and pure on distinct template specializations
PR c++/83503 - [8 Regression] bogus -Wattributes for const and pure on function template specialization

gcc/ChangeLog:

	PR c++/83871
	* gcc/doc/invoke.texi (-Wmissing-attributes): New option.

gcc/c-family/ChangeLog:

	PR c++/83871
	* c.opt (-Wmissing-attributes): New option.

gcc/cp/ChangeLog:

	PR c++/83871
	PR c++/83503
	* cp-tree.h (warn_spec_missing_attributes): New function.
	((check_explicit_specialization): Add an argument.  Call the above
	function.
	* decl.c (duplicate_decls): Avoid applying primary function template's
	attributes to its explicit specializations.
	cp/pt.c (warn_spec_missing_attributes): Define.

gcc/testsuite/ChangeLog:

	PR c++/83871
	PR c++/83503
	* g++.dg/Wmissing-attributes.C: New test.
	* g++.dg/ext/attr-const-pure.C: New test.
	* g++.dg/ext/attr-const.C: New test.
	* g++.dg/ext/attr-deprecated-2.C: New test.
	* g++.dg/ext/attr-malloc-2.C: New test.
	* g++.dg/ext/attr-malloc.C: New test.
	* g++.dg/ext/attr-noinline-2.C: New test.
	* g++.dg/ext/attr-noinline.C: New test.
	* g++.dg/ext/attr-nonnull.C: New test.
	* g++.dg/ext/attr-noreturn-2.C: New test.
	* g++.dg/ext/attr-noreturn.C: New test.
	* g++.dg/ext/attr-nothrow-2.C: New test.
	* g++.dg/ext/attr-nothrow.C: New test.
	* g++.dg/ext/attr-optimize.C: New test.
	* g++.dg/ext/attr-pure.C: New test.
	* g++.dg/ext/attr-returns-nonnull.C: New test.
	* g++.dg/ext/attr-warning.C: New test.

diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
index 421b146..a4c8c8f 100644
--- a/gcc/c-family/c.opt
+++ b/gcc/c-family/c.opt
@@ -781,6 +781,11 @@ Wtemplates
 C++ ObjC++ Var(warn_templates) Warning
 Warn on primary template declaration.
 
+Wmissing-attributes
+C ObjC C++ ObjC++ Var(warn_missing_attributes) Warning LangEnabledBy(C ObjC C++ ObjC++,Wall)
+Warn about declarations of entities that may be missing attributes
+that related entities have been declared with it.
+
 Wmissing-format-attribute
 C ObjC C++ ObjC++ Warning Alias(Wsuggest-attribute=format)
 ;
diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index aef022f..abcd1a6 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -6463,7 +6463,8 @@ extern void end_specialization			(void);
 extern void begin_explicit_instantiation	(void);
 extern void end_explicit_instantiation		(void);
 extern void check_unqualified_spec_or_inst	(tree, location_t);
-extern tree check_explicit_specialization	(tree, tree, int, int);
+extern tree check_explicit_specialization	(tree, tree, 

Re: [PATCH PR other/77609] Let the assembler choose ELF section types for miscellaneous named sections

[Ian Lance Taylor via gcc-patches]

On Sat, Feb 24, 2018 at 1:54 AM, Roland McGrath via gcc-patches
 wrote:
> Anybody want to look at this?
>
> It rebases identically on today's trunk.  I'd like to commit it to
> trunk and gcc-7-branch and gcc-6-branch ideally.

You are recreating the conditions used in
default_elf_asm_named_section, so I think you ought to have comments
referring back and forth between them.

This is OK with the two additional comments.

Ian



> On Thu, Sep 22, 2016 at 1:15 PM, Roland McGrath  wrote:
>> ping?
>>
>> On Thu, Sep 15, 2016 at 4:09 PM, Roland McGrath  wrote:
>>> This fixes https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77609 (which I've
>>> just filed).
>>>
>>> OK for trunk?
>>>
>>> I'm not sure if this kind of fix is appropriate for gcc-6-branch or not,
>>> but I'd like to backport it there too if it is acceptable.
>>>
>>>
>>> Thanks,
>>> Roland
>>>
>>>
>>> gcc/
>>> 2016-09-15  Roland McGrath  <
>>>
>>> PR other/77609
>>> * varasm.c (default_section_type_flags): Set SECTION_NOTYPE for
>>> any section for which we don't know a specific type it should have,
>>> regardless of name.  Previously this was done only for the exact
>>> names ".init_array", ".fini_array", and ".preinit_array".
>>>
>>> diff --git a/gcc/varasm.c b/gcc/varasm.c
>>> index 00a9b30..0d7ea38 100644
>>> --- a/gcc/varasm.c
>>> +++ b/gcc/varasm.c
>>> @@ -6210,15 +6210,20 @@ default_section_type_flags (tree decl, const
>>> char *name, int reloc)
>>>|| strncmp (name, ".gnu.linkonce.tb.", 17) == 0)
>>>  flags |= SECTION_TLS | SECTION_BSS;
>>>
>>> -  /* These three sections have special ELF types.  They are neither
>>> - SHT_PROGBITS nor SHT_NOBITS, so when changing sections we don't
>>> - want to print a section type (@progbits or @nobits).  If someone
>>> - is silly enough to emit code or TLS variables to one of these
>>> - sections, then don't handle them specially.  */
>>> -  if (!(flags & (SECTION_CODE | SECTION_BSS | SECTION_TLS))
>>> -  && (strcmp (name, ".init_array") == 0
>>> - || strcmp (name, ".fini_array") == 0
>>> - || strcmp (name, ".preinit_array") == 0))
>>> +  /* Various sections have special ELF types that the assembler will
>>> + assign by default based on the name.  They are neither SHT_PROGBITS
>>> + nor SHT_NOBITS, so when changing sections we don't want to print a
>>> + section type (@progbits or @nobits).  Rather than duplicating the
>>> + assembler's knowledge of what those special name patterns are, just
>>> + let the assembler choose the type if we don't know a specific
>>> + reason to set it to something other than the default.  SHT_PROGBITS
>>> + is the default for sections whose name is not specially known to
>>> + the assembler, so it does no harm to leave the choice to the
>>> + assembler when @progbits is the best thing we know to use.  If
>>> + someone is silly enough to emit code or TLS variables to one of
>>> + these sections, then don't handle them specially.  */
>>> +  if (!(flags & (SECTION_CODE | SECTION_BSS | SECTION_TLS | 
>>> SECTION_ENTSIZE))
>>> +  && !(HAVE_COMDAT_GROUP && (flags & SECTION_LINKONCE)))
>>>  flags |= SECTION_NOTYPE;
>>>
>>>return flags;

C++ PATCH for c++/84560, ICE capturing multi-dimensional VLA

[Jason Merrill]

The code was already there to give an error for this case, we just
weren't hitting it because array_of_runtime_bound_p was incorrectly
returning true.

Tested x86_64-pc-linux-gnu, applying to trunk.
commit 1106dfa9e9df6e4dddb75c50db57cff953017fc7
Author: Jason Merrill 
Date:   Mon Feb 26 20:42:13 2018 -0500

PR c++/84560 - ICE capturing multi-dimensional VLA.

* tree.c (array_of_runtime_bound_p): False if the element is
variably-modified.

diff --git a/gcc/cp/tree.c b/gcc/cp/tree.c
index 41d9002d8f9..9b9e36a1173 100644
--- a/gcc/cp/tree.c
+++ b/gcc/cp/tree.c
@@ -1043,6 +1043,8 @@ array_of_runtime_bound_p (tree t)
 {
   if (!t || TREE_CODE (t) != ARRAY_TYPE)
 return false;
+  if (variably_modified_type_p (TREE_TYPE (t), NULL_TREE))
+return false;
   tree dom = TYPE_DOMAIN (t);
   if (!dom)
 return false;
diff --git a/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-vla2.C 
b/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-vla2.C
new file mode 100644
index 000..d4de131fc23
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-vla2.C
@@ -0,0 +1,12 @@
+// PR c++/84560
+// { dg-do compile { target c++11 } }
+// { dg-options "" }
+
+void f() {
+  int n = 1;
+  int m = 1;
+  int d[n][m];
+  [&]() {
+return d[1];   // { dg-error "variabl" }
+  }();
+}

C++ PATCH for c++/84441, ICE with base initialized from ?:

[Jason Merrill]

A while back I added unsafe_copy_elision_p to catch cases where we
don't want to initialize a base subobject directly from a call because
it might clobber data packed into the tail padding of the base.  Later
I extended that function to look into COMPOUND_EXPR.  This patch
further adjusts it to look into COND_EXPR.

Tested x86_64-pc-linux-gnu, applying to trunk/7/6.
commit 145aa5adf95adfa581f663e9a799f5fe0c6418cb
Author: Jason Merrill 
Date:   Mon Feb 26 18:23:30 2018 -0500

PR c++/84441 - ICE with base initialized from ?:

* call.c (unsafe_copy_elision_p): Handle COND_EXPR.

diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index c47befdbf7f..11fe28292fb 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -7580,6 +7580,15 @@ unsafe_copy_elision_p (tree target, tree exp)
   /* build_compound_expr pushes COMPOUND_EXPR inside TARGET_EXPR.  */
   while (TREE_CODE (init) == COMPOUND_EXPR)
 init = TREE_OPERAND (init, 1);
+  if (TREE_CODE (init) == COND_EXPR)
+{
+  /* We'll end up copying from each of the arms of the COND_EXPR directly
+into the target, so look at them. */
+  if (tree op = TREE_OPERAND (init, 1))
+   if (unsafe_copy_elision_p (target, op))
+ return true;
+  return unsafe_copy_elision_p (target, TREE_OPERAND (init, 2));
+}
   return (TREE_CODE (init) == AGGR_INIT_EXPR
  && !AGGR_INIT_VIA_CTOR_P (init));
 }
diff --git a/gcc/testsuite/g++.dg/cpp0x/elision3.C 
b/gcc/testsuite/g++.dg/cpp0x/elision3.C
new file mode 100644
index 000..7c5c8b9f0b9
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/elision3.C
@@ -0,0 +1,21 @@
+// PR c++/84441
+// { dg-do compile { target c++11 } }
+
+struct B {
+  int *b;
+};
+struct A {
+  B b;
+  A (A &&);
+};
+struct C {
+  A c;
+  int d;
+};
+C bar ();
+struct D : C {
+  D ()
+: C (0 ? bar () : bar ())
+  {}
+};
+D d;

C++ PATCH for c++/84520, ICE with generic lambda in NSDMI

[Jason Merrill]

lambda_expr_this_capture assumes that we can find the fake 'this'
inserted while parsing an NSDMI, but it isn't there if we are
instantiating, rather than parsing, a generic lambda.

Tested x86_64-pc-linux-gnu, applying to trunk/7/6.
commit 9c64c953f0595e88cd911d488a415c8568934864
Author: Jason Merrill 
Date:   Mon Feb 26 18:01:05 2018 -0500

PR c++/84520 - ICE with generic lambda in NSDMI.

* lambda.c (lambda_expr_this_capture): Don't look for fake NSDMI
'this' in a generic lambda instantiation.

diff --git a/gcc/cp/lambda.c b/gcc/cp/lambda.c
index 6a798266f12..3f77df037a2 100644
--- a/gcc/cp/lambda.c
+++ b/gcc/cp/lambda.c
@@ -758,11 +758,14 @@ lambda_expr_this_capture (tree lambda, bool add_capture_p)
 lambda_stack);
 
  if (LAMBDA_EXPR_EXTRA_SCOPE (tlambda)
+ && !COMPLETE_TYPE_P (LAMBDA_EXPR_CLOSURE (tlambda))
  && TREE_CODE (LAMBDA_EXPR_EXTRA_SCOPE (tlambda)) == FIELD_DECL)
{
  /* In an NSDMI, we don't have a function to look up the decl in,
 but the fake 'this' pointer that we're using for parsing is
-in scope_chain.  */
+in scope_chain.  But if the closure is already complete, we're
+in an instantiation of a generic lambda, and the fake 'this'
+is gone.  */
  init = scope_chain->x_current_class_ptr;
  gcc_checking_assert
(init && (TREE_TYPE (TREE_TYPE (init))
diff --git a/gcc/testsuite/g++.dg/cpp1y/lambda-generic-nsdmi1.C 
b/gcc/testsuite/g++.dg/cpp1y/lambda-generic-nsdmi1.C
new file mode 100644
index 000..89ce519d812
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1y/lambda-generic-nsdmi1.C
@@ -0,0 +1,8 @@
+// PR c++/84520
+// { dg-do compile { target c++14 } }
+
+struct A
+{
+  static void foo(int);
+  void (*f)(int) = [](auto i) { foo(i); };
+};

Re: [PATCH] Correct debug for -mcall-ms2sysv-xlogues stubs (PR target/83917, take 2)

[Daniel Santos]

On 02/26/2018 02:20 AM, Jakub Jelinek wrote:
> On Sun, Feb 25, 2018 at 05:56:28PM -0600, Daniel Santos wrote:
>>> --- libgcc/config/i386/i386-asm.h.jj2018-01-03 10:42:56.317763517 
>>> +0100
>>> +++ libgcc/config/i386/i386-asm.h   2018-02-22 15:33:43.812922298 +0100
>>> @@ -27,8 +27,47 @@ see the files COPYING3 and COPYING.RUNTI
>>>  #define I386_ASM_H
>>>  
>>>  #include "auto-target.h"
>>> +#undef PACKAGE_VERSION
>>> +#undef PACKAGE_NAME
>>> +#undef PACKAGE_STRING
>>> +#undef PACKAGE_TARNAME
>>> +#undef PACKAGE_URL
>> This is a beautiful, temporary(?) fix to an ugly problem!
>>
>>>  #include "auto-host.h"
>>> --- libgcc/config/i386/cygwin.S.jj  2018-01-03 10:42:56.309763515 +0100
>>> +++ libgcc/config/i386/cygwin.S 2018-02-22 15:30:34.597925496 +0100
>>> @@ -23,31 +23,13 @@
>>>   * .
>>>   */
>>>  
>>> -#include "auto-host.h"
>> The following include should be here.
>>
>> +#include "i386-asm.h"
> I don't understand this.  i386-asm.h needs (both before my patch and after
> it) both auto-host.h and auto-target.h, as it tests
> HAVE_GAS_SECTIONS_DIRECTIVE (this one newly, comes from cygwin.S)

The problem is that HAVE_GAS_SECTIONS_DIRECTIVE gets defined (or not) in
../../gcc/auto-host.h, but you are testing it before including
auto-host.h, either directly or via i386-asm.h.  So if i386-asm.h
depends upon HAVE_GAS_SECTIONS_DIRECTIVE first being defined then it is
a circular dependency.

In its current form, cygwin.S would never define USE_GAS_CFI_DIRECTIVES
prior to including i386-asm.h and also never emit
    .cfi_sections    .debug_frame
and rather or not USE_GAS_CFI_DIRECTIVES ends up being defined to 1 or 0
depends upon the test of __GCC_HAVE_DWARF2_CFI_ASM in i386-asm.h.

So this area is new for me, but I don't understand why we're testing
HAVE_GAS_SECTIONS_DIRECTIVE in cygwin.S and __GCC_HAVE_DWARF2_CFI_ASM
when included from one of the stubs.  Is this an error, or a lack of my
understanding or both? :)

> HAVE_GAS_HIDDEN
> macros defined in auto-host.h
> and
> HAVE_AS_AVX
> macro defined in auto-target.h.
> Including auto-host.h when i386-asm.h will include it again just doesn't
> work, these headers don't have multiple inclusion guards.  And only including
> auto-target.h will work only if the
> .hidden
> and
> .cfi_sections .debug_frame
> tests are duplicated from gcc/configure.ac to libgcc/configure.ac, then we
> could include just auto-target.h in i386-asm.h.
> I've just followed what i386-asm.h has been doing.

And it's possible that I failed to test something correctly before
presuming it to be available, although I *think* the test for .hidden is
good.

>
>   Jakub
>

Thanks for your work on this.  If we need to test for CFI directives
differently when being included from cygwin.S, maybe we can just define
a simple cpp macro to indicate this and let i386-asm.h encapsulate the
implementation of it (e.g., testing HAVE_GAS_SECTIONS_DIRECTIVE or
__GCC_HAVE_DWARF2_CFI_ASM as appropriate).

Ultimately, the proper cleanup will be moving these tests out of
{gcc,libgcc}/configure.ac and into .m4 files in the root config
directory so that we don't uglify them with massive copy & pastes. 
These tests are also fairly complex as there are a lot of dependencies. 
m4 isn't my strong suite, but I can look at this after we're out of code
freeze.

Daniel

Re: [PING] [PATCH] consider successor blocks when avoiding -Wstringop-truncation (PR 84468)

[Martin Sebor]

On 02/26/2018 12:13 PM, Jeff Law wrote:

On 02/24/2018 05:11 PM, Martin Sebor wrote:

Attached is an updated patch with a fix for a bad assumption
exposed by building the linux kernel.

On 02/19/2018 07:50 PM, Martin Sebor wrote:

PR 84468 points out a false positive in -Wstringop-truncation
in code like this:

  struct A { char a[4]; };

  void f (struct A *p, const struct A *q)
  {
if (p->a)
  strncpy (p->a, q->a, sizeof p->a - 1);   // warning here

p->a[3] = '\0';
  }

The warning is due to the code checking only the same basic block
as the one with the strncpy call for an assignment to the destination
to avoid it, but failing to check the successor basic block if there
is no subsequent statement in the current block.  (Eliminating
the conditional is being tracked in PR 21474.)

The attached test case adds logic to avoid this false positive.
I don't know under what circumstances there could be more than
one successor block here so I don't handle that case.

So this is feeling more and more like we need to go back to the ideas
behind checking the virtual operand chains.

The patch as-written does not properly handle the case where BB has
multiple outgoing edges.  For gcc-8 you could probably get away with
checking that you have precisely one outgoing edge without EDGE_ABNORMAL
set in its flags in addition to the checks you're already doing.

But again, it's feeling more and more like the right fix is to go back
and walk the virtual operands.


I intentionally kept the patch as simple as possible to minimize
risk at this late stage.

Attached is a more robust version that handles multiple outgoing
edges and avoids those with the EDGE_ABNORMAL bit set.  Retested
on x86_64 and with the Linux kernel.

Enhancing this code to handle more complex cases is on my to-do
list for stage 1 (e.g., to handle bug 84561 where MEM_REF defeats
the detection of the nul assignment).

Martin
PR tree-optimization/84468 - bogus -Wstringop-truncation despite assignment after conditional strncpy

gcc/ChangeLog:

	PR tree-optimization/84468
	* tree-ssa-strlen.c (suppress_stringop_trunc): New function to also
	consider successor basic blocks.
	(maybe_diag_stxncpy_trunc): Call it.
gcc/testsuite/ChangeLog:

	PR tree-optimization/84468
	* gcc.dg/Wstringop-truncation.c: New test.
	* gcc.dg/Wstringop-truncation-2.c: New test.

Index: gcc/tree-ssa-strlen.c
===
--- gcc/tree-ssa-strlen.c	(revision 258016)
+++ gcc/tree-ssa-strlen.c	(working copy)
@@ -1781,6 +1781,83 @@ is_strlen_related_p (tree src, tree len)
   return false;
 }
 
+/* Return true if -Wstringop-truncation for statement STMT should be
+   suppressed.  GSI is an interator initially pointing at STMT and
+   set to subsequent statements on recursive calls by the function.
+   REF refers to the object being referred to.  VISITED is a bitmap
+   of visited basic blocks to prevent infinite recursion.  */
+
+static bool
+suppress_stringop_trunc (gimple *stmt, gimple_stmt_iterator gsi, tree ref,
+			 bitmap visited)
+{
+  if (gsi_end_p (gsi))
+return false;
+
+  gimple *cur_stmt = gsi_stmt (gsi);
+  if (is_gimple_debug (cur_stmt) || stmt == cur_stmt)
+  gsi_next_nondebug ();
+
+  gimple *next_stmt = gsi_stmt (gsi);
+  if (!next_stmt)
+{
+  /* When there is no statement in the same basic block check
+	 the immediate successor block.  */
+  if (basic_block bb = gimple_bb (cur_stmt))
+	{
+	  /* Return if the basic block has already been visited.  */
+	  if (!bitmap_set_bit (visited, bb->index))
+	return false;
+
+	  edge e;
+	  edge_iterator ei;
+	  FOR_EACH_EDGE (e, ei, bb->succs)
+	{
+	  if (e->flags & EDGE_ABNORMAL)
+		continue;
+
+	  basic_block nextbb = e->dest;
+	  gimple_stmt_iterator it = gsi_start_bb (nextbb);
+	  if (suppress_stringop_trunc (stmt, it, ref, visited))
+		return true;
+	}
+	}
+
+  return false;
+}
+
+  if (!is_gimple_assign (next_stmt))
+return false;
+
+  tree lhs = gimple_assign_lhs (next_stmt);
+  tree_code code = TREE_CODE (lhs);
+  if (code == ARRAY_REF || code == MEM_REF)
+lhs = TREE_OPERAND (lhs, 0);
+
+  tree func = gimple_call_fndecl (stmt);
+  if (DECL_FUNCTION_CODE (func) == BUILT_IN_STPNCPY)
+{
+  tree ret = gimple_call_lhs (stmt);
+  if (ret && operand_equal_p (ret, lhs, 0))
+	return true;
+}
+
+  /* Determine the base address and offset of the reference,
+ ignoring the innermost array index.  */
+  if (TREE_CODE (ref) == ARRAY_REF)
+ref = TREE_OPERAND (ref, 0);
+
+  poly_int64 dstoff;
+  tree dstbase = get_addr_base_and_unit_offset (ref, );
+
+  poly_int64 lhsoff;
+  tree lhsbase = get_addr_base_and_unit_offset (lhs, );
+  return (lhsbase
+	  && dstbase
+	  && known_eq (dstoff, lhsoff)
+	  && operand_equal_p (dstbase, lhsbase, 0));
+}
+
 /* Called by handle_builtin_stxncpy and by gimple_fold_builtin_strncpy
in gimple-fold.c.
Check to see if the specified bound is a) equal to 

Re: [PATCH] [Microblaze]: PIC Data Text Relative

[Michael Eager]

On 02/25/2018 11:44 PM, Andrew Guirguis wrote:

Dears,

Kindly find attached the patch bundle for Microblaze 
'-mpic-data-text-relative' feature.


Description of the feature in the following link:
https://github.com/andrewsadek/microblaze-pic-data-text-rel/blob/pic_data_text_rel/README.md 



Bundle includes:
1) Change logs for GCC, binutils
2) GCC Test results and comparison with the original.
3) New Test case (picdtr.c)
4) The Patches (against current heads)


Hi Andrew --

Thanks for the submission.  I have the following recommendations:

Submit each patch to the appropriate project mailing list.  Only submit
the patch for the specific project, without patches for other projects.

Include a description of the changes with each patch as well as the
changelog.  Include the patch in your email or as an attachment.

It isn't clear why you sent your submission to the gdb-patches mailing
list, since there don't appear to be any GDB changes.  Conversely, it is
not clear why you did not include the binutils mailing list, since you
include a patch to that project.

Be sure to follow GNU coding conventions,  Check brace placement,
indent, maximum line length, if statements, etc.  I noticed a number
of places where these conventions are not followed in your patches.

GCC regression tests should include all tests (e.g., gcc.dg), not just 
the limited number of MicroBlaze-specific tests.


--
Michael Eagerea...@eagerm.com
1960 Park Blvd., Palo Alto, CA 94306

[PATCH] PR c/46921 Lost side effect when struct initializer expression uses comma operator

[dave . pagan]

This patch fixes improper handling of comma operator expression in a 
struct field initializer as described in:


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

Currently, function output_init_element () does not evaluate the left 
hand expression in a comma operator that's used for a struct initializer 
field if the right hand side is zero-sized. However, the left hand 
expression must be evaluated if it's found to have side effects (for 
example, a function call).


Patch was successfully bootstrapped and tested on x86_64-linux.

--Dave


/c
2018-02-26  David Pagan  

PR c/46921
* c-typeck.c (output_init_element): Ensure field initializer 
expression is always evaluated if there are side effects.

/testsuite
2018-02-26  David Pagan  

PR c/46921
* gcc.dg/pr46921.c: New test.
Index: gcc/c/c-typeck.c
===
--- gcc/c/c-typeck.c(revision 257975)
+++ gcc/c/c-typeck.c(working copy)
@@ -9208,12 +9208,14 @@ output_init_element (location_t loc, tree value, t
  "enum conversion in initialization is invalid in C++");
 }
 
-  /* If this field is empty (and not at the end of structure),
- don't do anything other than checking the initializer.  */
+  /* If this field is empty and does not have side effects (and is not at 
+ the end of structure), don't do anything other than checking the 
+ initializer.  */
   if (field
   && (TREE_TYPE (field) == error_mark_node
  || (COMPLETE_TYPE_P (TREE_TYPE (field))
  && integer_zerop (TYPE_SIZE (TREE_TYPE (field)))
+ && !TREE_SIDE_EFFECTS (new_value)
  && (TREE_CODE (constructor_type) == ARRAY_TYPE
  || DECL_CHAIN (field)
 return;
Index: gcc/testsuite/gcc.dg/pr46921.c
===
--- gcc/testsuite/gcc.dg/pr46921.c  (revision 0)
+++ gcc/testsuite/gcc.dg/pr46921.c  (working copy)
@@ -0,0 +1,40 @@
+/* PR c/46921  lost side effect when struct initializer expr uses comma
+  operator  */
+
+/* { dg-do run } */
+/* { dg-options "" } */
+
+extern int printf(const char *, ...);
+extern void abort (void);
+
+typedef struct __uws_0 { } uw_unit;
+uw_unit uw_unit_v = {};
+
+struct __uws_1 
+{
+  struct __uws_0 __uwf_1;
+  struct __uws_1* __uwf_2;
+};
+
+static int left_hand_eval = 0;
+
+static void
+foo (const char *s)
+{
+  ++left_hand_eval;
+  printf("%s", s);
+}
+
+int
+main ()
+{
+  struct __uws_1 tmp = {(foo("Inner\n"), uw_unit_v)};
+  
+  printf("Outer\n");
+  /* left hand expression in comma operator initializer must always be
+ evaluated if there are side effects.  */
+  if (!left_hand_eval)
+abort ();
+  
+  return 0;
+}

[PATCH/testsuite] avoid test failures with -fpic

[Martin Sebor]

Compiling a number of tests with -fpic results in failures
because the tests make use of non-inline, extern helper
functions defined within, and these helpers must be assumed
to have been superimposed elsewhere.

For example:
https://gcc.gnu.org/ml/gcc-testresults/2018-02/msg01762.html

I took a quick pass through the failures and declared
the helpers static to avoid them.  I only did this in failure
tests I recognized because I introduced them myself being unaware
that building the tests with -fpic was expected to work.

This should make the -fpic test results a lot cleaner than
they currently are, although I don't think it brings them
up to par with non-fpic results.

Unless there are objections in the next day or so I'll commit
the fixes as obvious.

Martin

gcc/testsuite/ChangeLog:

	* c-c++-common/Warray-bounds-2.c: Declare helper static to avoid
	-fpic test failures.
	* c-c++-common/Wrestrict-2.c: Same.
	* c-c++-common/Wstringop-truncation.c: Same.
	* gcc.dg/Warray-bounds-22.c: Same.
	* gcc.dg/Wstringop-overflow.c: Same.
	* gcc.dg/attr-alloc_size-3.c (unsigned_range): Same.
	(signed_range): Same.
	(unsigned_anti_range): Same.
	* gcc.dg/attr-alloc_size-4.c (unsigned_range): Same.
	(signed_range): Same.
	(unsigned_anti_range): Same.
	* gcc.dg/attr-alloc_size-7.c: Same.
	* gcc.dg/attr-alloc_size-8.c: Same.
	* gcc.dg/builtin-alloc-size.c: Same.
	* gcc.dg/builtin-stpncpy.c: Same.
	* gcc.dg/builtins-nonnull.c: Same.
	* gcc.dg/nonnull-4.c (g16_1_3_5_7_11_13): Same.
	* gcc.dg/pr79214.c: Same.
	* gcc.dg/tree-ssa/builtin-snprintf-warn-1.c: Same.
	* gcc.dg/tree-ssa/builtin-snprintf-warn-2.c: Same.
	* gcc.dg/tree-ssa/builtin-sprintf-5.c: Same.
	* gcc.dg/tree-ssa/builtin-sprintf-warn-11.c: Same.
	* gcc.dg/tree-ssa/builtin-sprintf-warn-12.c: Same.
	* gcc.dg/tree-ssa/builtin-sprintf-warn-13.c: Same.
	* gcc.dg/tree-ssa/builtin-sprintf-warn-14.c: Same.
	* gcc.dg/tree-ssa/builtin-sprintf-warn-15.c: Same.
	* gcc.dg/tree-ssa/builtin-sprintf-warn-19.c: Same.
	* gcc.dg/tree-ssa/builtin-sprintf-warn-3.c: Same.
	* gcc.dg/tree-ssa/builtin-sprintf-warn-9.c: Same.


diff --git a/gcc/testsuite/c-c++-common/Warray-bounds-2.c b/gcc/testsuite/c-c++-common/Warray-bounds-2.c
index becb3d4..db05f04 100644
--- a/gcc/testsuite/c-c++-common/Warray-bounds-2.c
+++ b/gcc/testsuite/c-c++-common/Warray-bounds-2.c
@@ -24,7 +24,8 @@ struct __attribute__ ((packed)) Array
 
 /* Exercise memcpy out-of-bounds offsets with an array of known size.  */
 
-void wrap_memcpy_src_xsize (char *d, const char *s, ptrdiff_t i, size_t n)
+static void
+wrap_memcpy_src_xsize (char *d, const char *s, ptrdiff_t i, size_t n)
 {
   memcpy (d, s + i, n);   /* { dg-warning "offset 46 is out of the bounds \\\[0, 45] of object .ar. with type .(struct )?Array." "memcpy" } */
 }
@@ -39,7 +40,8 @@ void call_memcpy_src_xsize (char *d, size_t n)
 
 /* Exercise memcpy out-of-bounds offsets with an array of unknown size.  */
 
-void wrap_memcpy_src_diff_max (char *d, const char *s, ptrdiff_t i, size_t n)
+static void
+wrap_memcpy_src_diff_max (char *d, const char *s, ptrdiff_t i, size_t n)
 {
   memcpy (d, s + i, n);   /* { dg-warning "pointer overflow between offset \[0-9\]+ and size 3" "memcpy" } */
 }
@@ -49,7 +51,8 @@ void call_memcpy_src_diff_max (char *d, const char *s, size_t n)
   wrap_memcpy_src_diff_max (d, s, MAX, 3);
 }
 
-void wrap_memcpy_dst_xsize (char *d, const char *s, ptrdiff_t i, size_t n)
+static void
+wrap_memcpy_dst_xsize (char *d, const char *s, ptrdiff_t i, size_t n)
 {
   memcpy (d + i, s, n);   /* { dg-warning "offset 47 is out of the bounds \\\[0, 45] of object .ar1. with type .(struct )?Array." "memcpy" } */
 }
@@ -62,7 +65,8 @@ void call_memcpy_dst_xsize (const char *s, size_t n)
   sink ();
 }
 
-void wrap_memcpy_dst_diff_max (char *d, const char *s, ptrdiff_t i, size_t n)
+static void
+wrap_memcpy_dst_diff_max (char *d, const char *s, ptrdiff_t i, size_t n)
 {
   memcpy (d + i, s, n);   /* { dg-warning "offset -?\[0-9\]+ is out of the bounds \\\[0, 45] of object .ar2. with type .(struct )?Array." "memcpy" } */
 }
@@ -76,7 +80,7 @@ void call_memcpy_dst_diff_max (const char *s, size_t n)
 }
 
 
-void wrap_strcat_src_xsize (char *d, const char *s, ptrdiff_t i)
+static void wrap_strcat_src_xsize (char *d, const char *s, ptrdiff_t i)
 {
   strcat (d, s + i);   /* { dg-warning "offset 46 is out of the bounds \\\[0, 45] of object .ar3. with type .(struct )?Array." "strcat" } */
 }
@@ -89,7 +93,7 @@ void call_strcat_src_xsize (char *d)
   sink ();
 }
 
-void wrap_strcat_dst_xsize (char *d, const char *s, ptrdiff_t i)
+static void wrap_strcat_dst_xsize (char *d, const char *s, ptrdiff_t i)
 {
   strcat (d + i, s);   /* { dg-warning "offset 47 is out of the bounds \\\[0, 45] of object .ar4. with type .(struct )?Array." "strcat" } */
 }
@@ -103,7 +107,7 @@ void call_strcat_dst_xsize (const char *s)
 }
 
 
-void wrap_strcpy_src_xsize (char *d, const char *s, ptrdiff_t i)
+static void wrap_strcpy_src_xsize (char *d, const char *s, ptrdiff_t i)
 {
   strcpy 

Re: [v3 PATCH] Implement the missing bits of LWG 2769

[Ville Voutilainen]

On 26 February 2018 at 22:52, Jonathan Wakely  wrote:
> But those are just stylistic issues, the technical side of the patch
> is fine. I had to look up why we had two overloads for any_cast(any&&)
> and that seems to be a leftover from experimental::any, so thanks for
> cleaning that up too.


It was added by me when we (well, I) decided to support
copyable-but-not-movable types.
See, the current specification doesn't allow getting those types out
of an rvalue any by value.
Such an operation will perform an ill-formed move, with the
two-overload solution it would've
fallen back on copying.
Weird as such types are, I thought it not-too-much-trouble to
SFINAE-hack it to work. The specification
has since been made stricter so that it doesn't leave any
implementation leeway to allow that,
so hence the removal of that lenience.

Re: [PATCH][AArch64] PR84114: Avoid reassociating FMA

[James Greenhalgh]

On Thu, Feb 22, 2018 at 11:38:03AM +, Wilco Dijkstra wrote:
> As discussed in the PR, the reassociation phase runs before FMAs are formed
> and so can significantly reduce FMA opportunities.  Although reassociation
> could be switched off, it helps in many cases, so a better alternative is to
> only avoid reassociation of floating point additions.  This fixes the testcase
> and gives 1% speedup on SPECFP2017, fixing the performance regression.
> 
> OK for commit?

This is OK as a fairly safe fix for stage 4. We should fix reassociation
properly in GCC 9.

Thanks,
James

> 
> ChangeLog:
> 2018-02-23  Wilco Dijkstra  
> 
>   PR tree-optimization/84114
>   * config/aarch64/aarch64.c (aarch64_reassociation_width)
>   Avoid reassociation of FLOAT_MODE addition.
> --
> 
> diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
> index 
> b3d5fde171920e5759046a4bd61cfcf9eb78d7dd..5f9541cf700aaf18c1f1ac73054614e2932781e4
>  100644
> --- a/gcc/config/aarch64/aarch64.c
> +++ b/gcc/config/aarch64/aarch64.c
> @@ -1109,15 +1109,16 @@ aarch64_min_divisions_for_recip_mul (machine_mode 
> mode)
>return aarch64_tune_params.min_div_recip_mul_df;
>  }
>  
> +/* Return the reassociation width of treeop OPC with mode MODE.  */
>  static int
> -aarch64_reassociation_width (unsigned opc ATTRIBUTE_UNUSED,
> -  machine_mode mode)
> +aarch64_reassociation_width (unsigned opc, machine_mode mode)
>  {
>if (VECTOR_MODE_P (mode))
>  return aarch64_tune_params.vec_reassoc_width;
>if (INTEGRAL_MODE_P (mode))
>  return aarch64_tune_params.int_reassoc_width;
> -  if (FLOAT_MODE_P (mode))
> +  /* Avoid reassociating floating point addition so we emit more FMAs.  */
> +  if (FLOAT_MODE_P (mode) && opc != PLUS_EXPR)
>  return aarch64_tune_params.fp_reassoc_width;
>return 1;
>  }

C++ PATCH for c++/84559, ICE with constexpr VLA

[Jason Merrill]

Clang rejects this testcase saying that the VLA is a non-literal type,
but I think we don't want that; we want to allow VLAs in a constexpr
function, where the length can be constant during constexpr
evaluation.

In this case, however, we are dealing with a constexpr variable rather
than a variable in a constexpr function, so we want to reject the VLA.

Tested x86_64-pc-linux-gnu, applying to trunk.
commit d63c30c86d45831f20c4dc35f4ffaac2cfdd2588
Author: Jason Merrill 
Date:   Mon Feb 26 15:32:32 2018 -0500

PR c++/84559 - ICE with constexpr VLA.

* constexpr.c (ensure_literal_type_for_constexpr_object): Check
for constexpr variable with VLA type.

diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
index 26d0d099a05..92b13219215 100644
--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -112,6 +112,13 @@ ensure_literal_type_for_constexpr_object (tree decl)
  cp_function_chain->invalid_constexpr = true;
}
}
+  else if (DECL_DECLARED_CONSTEXPR_P (decl)
+  && variably_modified_type_p (type, NULL_TREE))
+   {
+ error ("% variable %qD has variably-modified type %qT",
+decl, type);
+ decl = error_mark_node;
+   }
 }
   return decl;
 }
diff --git a/gcc/testsuite/g++.dg/ext/constexpr-vla5.C 
b/gcc/testsuite/g++.dg/ext/constexpr-vla5.C
new file mode 100644
index 000..565d40ab077
--- /dev/null
+++ b/gcc/testsuite/g++.dg/ext/constexpr-vla5.C
@@ -0,0 +1,7 @@
+// PR c++/84559
+// { dg-do compile { target c++11 } }
+
+void foo(int i)
+{
+  constexpr char x[i] = "";// { dg-error "" }
+}

Re: [C++ PATCH] Fix ICE in cxx_eval_vec_init_1 (PR c++/84558)

[Jason Merrill]

OK.

On Mon, Feb 26, 2018 at 2:57 PM, Jakub Jelinek  wrote:
> Hi!
>
> The PR70001 optimization in cxx_eval_vec_init_1 uses
> initializer_constant_valid_p (eltinit, TREE_TYPE (eltinit))
> which doesn't work if eltinit is NULL.  This can happen if
> *non_constant_p is true, but ctx->quiet is true as well (for
> *non_constant_p && !ctx->quiet we break the cycle early).
> No initializer can be treated like a valid initializer and will
> have the advantage that we don't repeat the body for every array element
> and just do it once.  The caller will ignore the return value anyway
> when *non_constant_p.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> 2018-02-26  Jakub Jelinek  
>
> PR c++/84558
> * constexpr.c (cxx_eval_vec_init_1): For reuse, treat NULL eltinit 
> like
> a valid constant initializer.  Formatting fixes.
>
> * g++.dg/cpp1y/pr84558.C: New test.
>
> --- gcc/cp/constexpr.c.jj   2018-02-26 10:46:02.162316172 +0100
> +++ gcc/cp/constexpr.c  2018-02-26 14:07:38.705532369 +0100
> @@ -2959,9 +2959,8 @@ cxx_eval_vec_init_1 (const constexpr_ctx
>   if (!lvalue_p (init))
> eltinit = move (eltinit);
>   eltinit = force_rvalue (eltinit, tf_warning_or_error);
> - eltinit = (cxx_eval_constant_expression
> -(_ctx, eltinit, lval,
> - non_constant_p, overflow_p));
> + eltinit = cxx_eval_constant_expression (_ctx, eltinit, lval,
> + non_constant_p, overflow_p);
> }
>if (*non_constant_p && !ctx->quiet)
> break;
> @@ -2974,12 +2973,13 @@ cxx_eval_vec_init_1 (const constexpr_ctx
>else
> CONSTRUCTOR_APPEND_ELT (*p, idx, eltinit);
>/* Reuse the result of cxx_eval_constant_expression call
> - from the first iteration to all others if it is a constant
> - initializer that doesn't require relocations.  */
> +from the first iteration to all others if it is a constant
> +initializer that doesn't require relocations.  */
>if (reuse
>   && max > 1
> - && (initializer_constant_valid_p (eltinit, TREE_TYPE (eltinit))
> - == null_pointer_node))
> + && (eltinit == NULL_TREE
> + || (initializer_constant_valid_p (eltinit, TREE_TYPE (eltinit))
> + == null_pointer_node)))
> {
>   if (new_ctx.ctor != ctx->ctor)
> eltinit = new_ctx.ctor;
> --- gcc/testsuite/g++.dg/cpp1y/pr84558.C.jj 2018-02-26 14:33:56.575318295 
> +0100
> +++ gcc/testsuite/g++.dg/cpp1y/pr84558.C2018-02-26 14:33:33.142318527 
> +0100
> @@ -0,0 +1,6 @@
> +// PR c++/84558
> +// { dg-do compile { target c++14 } }
> +
> +struct A { static int i; constexpr A () { i = 0; } };
> +struct B { A a[2][3][4]; };
> +B b;
>
> Jakub

Re: [PATCH] expand description of poly_int conversions

[Richard Sandiford]

Martin Sebor  writes:
> On 02/26/2018 12:45 PM, Richard Sandiford wrote:
>> Martin Sebor  writes:
>>> Richard,
>>>
>>> If you agree, I'd like to update the conversion section of
>>> the poly_int manual to make the conversion to make it clearer
>>> that the to_constant() function can be used even with class
>>> types like offset_int besides scalars.
>>>
>>> Also, when testing this I also tried converting poly64_int
>>> into wide_int but that doesn't work.  Is there a way to do
>>> that?
>>
>> Not in one go, because you have to specify the intended precision
>> of the wide_int when constructing it from something like HOST_WIDE_INT.
>> (That's deliberate.)
>>
>>>
>>> Thanks
>>> Martin
>>>
>>> gcc/ChangeLog:
>>>
>>> * doc/poly-int.texi (is_constant): Expand.
>>>
>>> Index: gcc/doc/poly-int.texi
>>> ===
>>> --- gcc/doc/poly-int.texi   (revision 258004)
>>> +++ gcc/doc/poly-int.texi   (working copy)
>>> @@ -836,9 +836,24 @@ Return true if @code{poly_int} @var{value} is a co
>>>
>>>  @item @var{value}.is_constant (&@var{c1})
>>>  Return true if @code{poly_int} @var{value} is a compile-time constant,
>>> -storing it in @var{c1} if so.  @var{c1} must be able to hold all
>>> -constant values of @var{value} without loss of precision.
>>> +storing it in @var{c1} if so.  @var{c1} may be a scalar or a wide int
>>> +class type capable of holding all constant values of @var{value} without
>>
>> Not sure about "a scalar or a wide int", since that implies that wide ints
>> aren't scalar.  Even more pedantic, sorry, but c1 is an object rather than
>> a type.
>>
>> At a higher level, I'm a bit nervous about singling this out as a special
>> case, since all the poly_int stuff allows HOST_WIDE_INT, offset_int and
>> wide_int to be combined in the (hopefully) natural way.  E.g. you can
>> add offset_ints to poly_int64s, assign HOST_WIDE_INTs to poly_offset_ints,
>> and so on.
>>
>> But if we do keep it like this, how about:
>>
>>   @var{c1} must be some form of integer object that can hold all constant
>>   values of @var{value} without loss of precision; it can be either a normal
>>   C++ integer or a wide-int class like @code{offset_int}.
>>
>> ?
>
> Sure.  Attached is an update with your change.

LGTM (but I can't approve).

Thanks,
Richard

Re: [PATCH] libstdc++-v3: Check for TLS support on mingw

[Jonathan Wakely]

Apologies if you get this mail multiple times, I'm having some trouble
sending mail to @gcc.gnu.org lists.



On 19/02/18 09:59 +0100, Hugo Beauzée-Luyssen wrote:
> libstdc++-v3: Check for TLS support on mingw
>
> 2018-02-16  Hugo Beauzée-Luyssen  
>
>* crossconfig.m4: Check for TLS support on mignw

Typo "minwg"

>* configure: regenerate
>
> Index: libstdc++-v3/crossconfig.m4
> ===
> --- libstdc++-v3/crossconfig.m4 (revision 257730)
> +++ libstdc++-v3/crossconfig.m4 (working copy)
> @@ -197,6 +197,7 @@ case "${host}" in
> GLIBCXX_CHECK_LINKER_FEATURES
> GLIBCXX_CHECK_MATH_SUPPORT
> GLIBCXX_CHECK_STDLIB_SUPPORT
> +GCC_CHECK_TLS
> ;;
>   *-netbsd*)
> SECTION_FLAGS='-ffunction-sections -fdata-sections'

Hi, thanks for the patch. I don't think we can apply it now, as the
GCC trunk is only open for regression fixes until GCC 8 is released.

How was this tested? Will it work for all versions of mingw that we
support? Is TLS enabled for native builds? (If so we definitely need
this, because otherwise mingw cross-compilers are not ABI compatibnle
with native ones).

Re: [v3 PATCH] Implement the missing bits of LWG 2769

[Jonathan Wakely]

On 25/02/18 23:22 +0200, Ville Voutilainen wrote:

Tested partially on Linux-x64, will test with the full suite on Linux-PPC64.
Ok for trunk and the gcc-7 branch? This is theoretically a breaking change
for the branch, but the committee has decided that they don't want
the support for copyable-but-not-movable types.

2018-02-25  Ville Voutilainen  

   Implement the missing bits of LWG 2769
   * include/std/any (any_cast(const any&)): Add static_assert.
   (any_cast(any&)): Likewise.
   (any_cast(any&&)): Likewise, and remove the handling
   for copyable-but-not-movable type.
   * testsuite/20_util/any/misc/any_cast.cc: Adjust.
   * testsuite/20_util/any/misc/any_cast_neg.cc: Likewise, and
   add new tests.



diff --git a/libstdc++-v3/include/std/any b/libstdc++-v3/include/std/any
index 466b7ca..e0aba3c 100644
--- a/libstdc++-v3/include/std/any
+++ b/libstdc++-v3/include/std/any
@@ -455,6 +455,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
{
  static_assert(any::__is_valid_cast<_ValueType>(),
  "Template argument must be a reference or CopyConstructible type");
+  static_assert(is_constructible_v<_ValueType,
+   const _AnyCast<_ValueType>&>,


This template argument should be aligned with "_ValueType" on the
previous line, not with "is_constructible".

Looking at that file, I'm also wondering if we want the alias _AnyCast
to be defined at namespace scope. It's only used in a few function
bodies, and its name is a bit misleading.

Could you just do:

 using _Up = remove_cv_t>;

in the four functions that use it?

Then I think the is_constructible specializations would fit on one line
anyway.

But those are just stylistic issues, the technical side of the patch
is fine. I had to look up why we had two overloads for any_cast(any&&)
and that seems to be a leftover from experimental::any, so thanks for
cleaning that up too.

[PATCH] i386: Don't generate alias for function return thunk

[H.J. Lu]

Function return thunks shouldn't be aliased to indirect branch thunks
since indirect branch thunks are placed in COMDAT section and a COMDAT
section with indirect branch may not have function return thunk.  This
patch generates function return thunks directly.

Tested on i686 and x86-64.  OK for trunk?

H.J.
---
gcc/

PR target/84574
* config/i386/i386.c (indirect_thunk_needed): Update comments.
(indirect_thunk_bnd_needed): Likewise.
(indirect_thunks_used): Likewise.
(indirect_thunks_bnd_used): Likewise.
(indirect_return_needed): New.
(indirect_return_bnd_needed): Likewise.
(output_indirect_thunk_function): Add a bool argument for
function return.
(output_indirect_thunk_function): Don't generate alias for
function return thunk.
(ix86_code_end): Call output_indirect_thunk_function to generate
function return thunks.
(ix86_output_function_return): Set indirect_return_bnd_needed
and indirect_return_needed instead of indirect_thunk_bnd_needed
and indirect_thunk_needed.

gcc/testsuite/

PR target/84574
* gcc.target/i386/ret-thunk-9.c: Expect __x86_return_thunk
label instead of __x86_indirect_thunk label.
---
 gcc/config/i386/i386.c  | 95 +++--
 gcc/testsuite/gcc.target/i386/ret-thunk-9.c |  2 +-
 2 files changed, 36 insertions(+), 61 deletions(-)

diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 49f872d103f..9041485bd61 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -10799,19 +10799,23 @@ ix86_setup_frame_addresses (void)
labels in call and return thunks.  */
 static int indirectlabelno;
 
-/* True if call and return thunk functions are needed.  */
+/* True if call thunk function is needed.  */
 static bool indirect_thunk_needed = false;
-/* True if call and return thunk functions with the BND prefix are
-   needed.  */
+/* True if call thunk function with the BND prefix is needed.  */
 static bool indirect_thunk_bnd_needed = false;
 
 /* Bit masks of integer registers, which contain branch target, used
-   by call and return thunks functions.  */
+   by call thunk functions.  */
 static int indirect_thunks_used;
 /* Bit masks of integer registers, which contain branch target, used
-   by call and return thunks functions with the BND prefix.  */
+   by call thunk functions with the BND prefix.  */
 static int indirect_thunks_bnd_used;
 
+/* True if return thunk function is needed.  */
+static bool indirect_return_needed = false;
+/* True if return thunk function with the BND prefix is needed.  */
+static bool indirect_return_bnd_needed = false;
+
 /* True if return thunk function via CX is needed.  */
 static bool indirect_return_via_cx;
 /* True if return thunk function via CX with the BND prefix is
@@ -11007,17 +11011,18 @@ output_indirect_thunk (enum indirect_thunk_prefix 
need_prefix,
 /* Output a funtion with a call and return thunk for indirect branch.
If BND_P is true, the BND prefix is needed.  If REGNO != UNVALID_REGNUM,
the function address is in REGNO.  Otherwise, the function address is
-   on the top of stack.  */
+   on the top of stack.  Thunk is used for function return if RET_P is
+   true.  */
 
 static void
 output_indirect_thunk_function (enum indirect_thunk_prefix need_prefix,
-   unsigned int regno)
+   unsigned int regno, bool ret_p)
 {
   char name[32];
   tree decl;
 
   /* Create __x86_indirect_thunk/__x86_indirect_thunk_bnd.  */
-  indirect_thunk_name (name, regno, need_prefix, false);
+  indirect_thunk_name (name, regno, need_prefix, ret_p);
   decl = build_decl (BUILTINS_LOCATION, FUNCTION_DECL,
 get_identifier (name),
 build_function_type_list (void_type_node, NULL_TREE));
@@ -11060,50 +11065,6 @@ output_indirect_thunk_function (enum 
indirect_thunk_prefix need_prefix,
ASM_OUTPUT_LABEL (asm_out_file, name);
   }
 
-  /* Create alias for __x86_return_thunk/__x86_return_thunk_bnd or
- __x86_return_thunk_ecx/__x86_return_thunk_ecx_bnd.  */
-  bool need_alias;
-  if (regno == INVALID_REGNUM)
-need_alias = true;
-  else if (regno == CX_REG)
-{
-  if (need_prefix == indirect_thunk_prefix_bnd)
-   need_alias = indirect_return_via_cx_bnd;
-  else
-   need_alias = indirect_return_via_cx;
-}
-  else
-need_alias = false;
-
-  if (need_alias)
-{
-  char alias[32];
-
-  indirect_thunk_name (alias, regno, need_prefix, true);
-#if TARGET_MACHO
-  if (TARGET_MACHO)
-   {
- fputs ("\t.weak_definition\t", asm_out_file);
- assemble_name (asm_out_file, alias);
- fputs ("\n\t.private_extern\t", asm_out_file);
- assemble_name (asm_out_file, alias);
- putc ('\n', asm_out_file);
- ASM_OUTPUT_LABEL (asm_out_file, alias);
-   }
-#else
-  

[PATCH] Fix ICE with -mforce-indirect-call (PR target/84564)

[Jakub Jelinek]

Hi!

While this isn't a regression, it is ICE in newly added feature and
so should be fixed too.  The problem is that with -mforce-indirect-call
even direct calls are emitted as indirect, and if we have in 32-bit
mode a direct call to a regparm(3) function or a direct call to a function
we've optimized using regparm(3) convention internally, we can't really
tail call it, as there aren't any registers left for the address of the
function in the indirect call, eax/ecx/edx are used to pass arguments, esp
has fixed role and the rest needs to be already restored.

The following patch refuses to tail call in that case, similarly how we
reject to tail call an indirect call to a regparm(3) function.

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

2018-02-26  Jakub Jelinek  

PR target/84564
* config/i386/i386.c (ix86_function_ok_for_sibcall): Check for
regparm >= 3 with no arg reg available also for calls with
flag_force_indirect_call.  Pass decl to ix86_function_regparm.

* gcc.target/i386/pr84564.c: New test.

--- gcc/config/i386/i386.c.jj   2018-02-22 22:25:57.109993153 +0100
+++ gcc/config/i386/i386.c  2018-02-26 15:14:11.786294313 +0100
@@ -6411,7 +6411,8 @@ ix86_function_ok_for_sibcall (tree decl,
 function via GOT slot are indirect.  */
   if (!decl
  || (bind_global && flag_pic && !flag_plt)
- || (TARGET_DLLIMPORT_DECL_ATTRIBUTES && DECL_DLLIMPORT_P (decl)))
+ || (TARGET_DLLIMPORT_DECL_ATTRIBUTES && DECL_DLLIMPORT_P (decl))
+ || flag_force_indirect_call)
{
  /* Check if regparm >= 3 since arg_reg_available is set to
 false if regparm == 0.  If regparm is 1 or 2, there is
@@ -6420,7 +6421,7 @@ ix86_function_ok_for_sibcall (tree decl,
 ??? The symbol indirect call doesn't need a call-clobbered
 register.  But we don't know if this is a symbol indirect
 call or not here.  */
- if (ix86_function_regparm (type, NULL) >= 3
+ if (ix86_function_regparm (type, decl) >= 3
  && !cfun->machine->arg_reg_available)
return false;
}
--- gcc/testsuite/gcc.target/i386/pr84564.c.jj  2018-02-26 15:10:02.981296789 
+0100
+++ gcc/testsuite/gcc.target/i386/pr84564.c 2018-02-26 14:57:38.287304183 
+0100
@@ -0,0 +1,21 @@
+/* PR target/84564 */
+/* { dg-do compile } */
+/* { dg-options "-O2 -mforce-indirect-call" } */
+
+int a, b, c, d;
+int foo (void);
+
+static int
+bar (int x, int y, int z)
+{
+  while (a)
+if (foo ())
+  bar (x, y, z);
+  return 0;
+}
+
+int
+baz (void)
+{
+  return bar (b, c, d);
+}

Jakub

Re: [PATCH] fix ICE in generic_overlap (PR 84526)

[Jakub Jelinek]

On Mon, Feb 26, 2018 at 10:32:27AM -0700, Martin Sebor wrote:
> That attached revision updates the pass to directly convert
> the poly64_int into offset_int using the API suggested by
> Richard (thanks again).  As discussed below, I've made no
> other changes.
> 
> Jakub, if you still have concerns that the false positive
> suppression logic isn't sufficiently effective please post
> a test case (or open a new bug).  I will look into it when
> I get a chance.

Yes, I still have major concerns, I explained what I'd like to see
(differentiate clearly between what base is, either by adding a flag or
having separate base and base_addr, then in the users you can easily find
out what is what and can decide based on that).

> Until then, I'd like to get the ICE fix committed. Please
> confirm that the attached patch is good to go in.

Due to the above concerns, I don't think the patch is good to go in.
If you find somebody else who thinks the patch is ok, I won't fight against
it though.

Jakub

Re: [PATCH] expand description of poly_int conversions

[Martin Sebor]

On 02/26/2018 12:45 PM, Richard Sandiford wrote:

Martin Sebor  writes:

Richard,

If you agree, I'd like to update the conversion section of
the poly_int manual to make the conversion to make it clearer
that the to_constant() function can be used even with class
types like offset_int besides scalars.

Also, when testing this I also tried converting poly64_int
into wide_int but that doesn't work.  Is there a way to do
that?


Not in one go, because you have to specify the intended precision
of the wide_int when constructing it from something like HOST_WIDE_INT.
(That's deliberate.)



Thanks
Martin

gcc/ChangeLog:

* doc/poly-int.texi (is_constant): Expand.

Index: gcc/doc/poly-int.texi
===
--- gcc/doc/poly-int.texi   (revision 258004)
+++ gcc/doc/poly-int.texi   (working copy)
@@ -836,9 +836,24 @@ Return true if @code{poly_int} @var{value} is a co

 @item @var{value}.is_constant (&@var{c1})
 Return true if @code{poly_int} @var{value} is a compile-time constant,
-storing it in @var{c1} if so.  @var{c1} must be able to hold all
-constant values of @var{value} without loss of precision.
+storing it in @var{c1} if so.  @var{c1} may be a scalar or a wide int
+class type capable of holding all constant values of @var{value} without


Not sure about "a scalar or a wide int", since that implies that wide ints
aren't scalar.  Even more pedantic, sorry, but c1 is an object rather than
a type.

At a higher level, I'm a bit nervous about singling this out as a special
case, since all the poly_int stuff allows HOST_WIDE_INT, offset_int and
wide_int to be combined in the (hopefully) natural way.  E.g. you can
add offset_ints to poly_int64s, assign HOST_WIDE_INTs to poly_offset_ints,
and so on.

But if we do keep it like this, how about:

  @var{c1} must be some form of integer object that can hold all constant
  values of @var{value} without loss of precision; it can be either a normal
  C++ integer or a wide-int class like @code{offset_int}.

?


Sure.  Attached is an update with your change.

Martin

gcc/ChangeLog:

	* doc/poly-int.texi (is_constant): Expand.

Index: gcc/doc/poly-int.texi
===
--- gcc/doc/poly-int.texi	(revision 258004)
+++ gcc/doc/poly-int.texi	(working copy)
@@ -836,8 +836,23 @@ Return true if @code{poly_int} @var{value} is a co
 
 @item @var{value}.is_constant (&@var{c1})
 Return true if @code{poly_int} @var{value} is a compile-time constant,
-storing it in @var{c1} if so.  @var{c1} must be able to hold all
-constant values of @var{value} without loss of precision.
+storing it in @var{c1} if so.  @var{c1} must be some form of integer
+object that can hold all constant values of @var{value} without loss
+of precision; it can be either a normal C++ integer or a wide-int class
+like @code{offset_int}.  The following example illustrates using
+the function to convert a @code{poly_int64} to @code{HOST_WIDE_INT}
+and to @code{offset_int}.
+@smallexample
+void f (poly_int64 pi)
+@{
+  HOST_WIDE_INT hwi;
+  if (pi.is_constant ())
+; // Use hwi...
+  offset_int off;
+  if (pi.is_constant ())
+; // Use off...
+@}
+@end smallexample
 
 @item @var{value}.to_constant ()
 Assert that @var{value} is a compile-time constant and return its value.

[PATCH] PR fortran/51434 -- ICE in gfc_simplify_transfer

[Steve Kargl]

All,

The attached patch fixes an ICE that occurs in gfc_simplify_tranfer.
The code that causes the problem is

  if (!gfc_is_constant_expr (source)
|| (gfc_init_expr_flag && !gfc_is_constant_expr (mold))
|| !gfc_is_constant_expr (size))
return NULL;

in particular gfc_is_constant_expr (mold) leads to segfault.  Removing
the 2nd line allows the testcase to compile, but leads to several
regressions.  I went down the rabbit with gdb-8.0.1 to see why this
was dying a horrible death, and came away with a large headache.
After conferring with F95 and F2018, I concluded (and I coudl be
wrong) that mold simply needs to available as a scalar or an
array and it's actual value was not needed.  So, I decided to 
use gfc_reduce_expr (mold) to see if this would fix up some 
rogue pointer, and well it worked.  So, OK to commit?

2018-02-26  Steven G. Kargl  

PF fortran/51434
* simplify.c (gfc_simplify_transfer): Reduce mold.

2018-02-26  Steven G. Kargl  

PF fortran/51434
* gfortran.dg/pr51434.f90: New test.

-- 
Steve
Index: gcc/fortran/simplify.c
===
--- gcc/fortran/simplify.c	(revision 258006)
+++ gcc/fortran/simplify.c	(working copy)
@@ -25,6 +25,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "gfortran.h"
 #include "arith.h"
 #include "intrinsic.h"
+#include "match.h"
 #include "target-memory.h"
 #include "constructor.h"
 #include "version.h"	/* For version_string.  */
@@ -7370,10 +7371,12 @@ gfc_simplify_transfer (gfc_expr *source, gfc_expr *mol
   unsigned char *buffer;
   size_t result_length;
 
+  if (!gfc_is_constant_expr (source) || !gfc_is_constant_expr (size))
+return NULL;
 
-  if (!gfc_is_constant_expr (source)
-	|| (gfc_init_expr_flag && !gfc_is_constant_expr (mold))
-	|| !gfc_is_constant_expr (size))
+  if (!gfc_resolve_expr (mold))
+return NULL;
+  if (gfc_init_expr_flag && !gfc_is_constant_expr (mold))
 return NULL;
 
   if (!gfc_calculate_transfer_sizes (source, mold, size, _size,
Index: gcc/testsuite/gfortran.dg/pr51434.f90
===
--- gcc/testsuite/gfortran.dg/pr51434.f90	(nonexistent)
+++ gcc/testsuite/gfortran.dg/pr51434.f90	(working copy)
@@ -0,0 +1,19 @@
+! { dg-do run }
+! PR fortran/51434
+module foo
+   implicit none
+   integer, parameter :: n = 5
+   character(len=1), parameter :: s(n) = 'a'
+   type :: a
+  integer :: m = n
+  character(len=1):: t(n) = transfer('abcde ', s)
+   end type a
+end module foo
+
+program bar
+   use foo
+   implicit none
+   type(a) c
+   if (c%m /= n) stop 1
+   if (any(c%t /= ['a', 'b', 'c', 'd', 'e'])) stop 2
+end program bar

[committed] Fix C++ OpenMP parsing ICE (PR c++/84557)

[Jakub Jelinek]

Hi!

In C++, the OpenMP variable lists are lists of id-expressions, which
include template-ids; for those cp_parser_lookup_name_simple ICEs though,
so this patch just calls that for identifiers similarly to other
cp_parser_lookup_name_simple callers.

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

2018-02-26  Jakub Jelinek  

PR c++/84557
* parser.c (cp_parser_omp_var_list_no_open): Only call
cp_parser_lookup_name_simple on names satisfying identifier_p.
(cp_parser_oacc_routine): Likewise.

* g++.dg/gomp/pr84557.C: New test.

--- gcc/cp/parser.c.jj  2018-02-22 14:35:34.194215675 +0100
+++ gcc/cp/parser.c 2018-02-26 13:03:56.398478515 +0100
@@ -31339,7 +31339,10 @@ cp_parser_omp_var_list_no_open (cp_parse
  if (name == error_mark_node)
goto skip_comma;
 
- decl = cp_parser_lookup_name_simple (parser, name, token->location);
+ if (identifier_p (name))
+   decl = cp_parser_lookup_name_simple (parser, name, token->location);
+ else
+   decl = name;
  if (decl == error_mark_node)
cp_parser_name_lookup_error (parser, name, decl, NLE_NULL,
 token->location);
@@ -37843,7 +37846,9 @@ cp_parser_oacc_routine (cp_parser *parse
   /*template_p=*/NULL,
   /*declarator_p=*/false,
   /*optional_p=*/false);
-  tree decl = cp_parser_lookup_name_simple (parser, name, name_loc);
+  tree decl = (identifier_p (name)
+  ? cp_parser_lookup_name_simple (parser, name, name_loc)
+  : name);
   if (name != error_mark_node && decl == error_mark_node)
cp_parser_name_lookup_error (parser, name, decl, NLE_NULL, name_loc);
 
--- gcc/testsuite/g++.dg/gomp/pr84557.C.jj  2018-02-26 13:04:34.074472152 
+0100
+++ gcc/testsuite/g++.dg/gomp/pr84557.C 2018-02-26 13:04:17.014475036 +0100
@@ -0,0 +1,14 @@
+// PR c++/84557
+// { dg-do compile }
+
+template struct A {};
+template struct B {};
+
+void
+foo ()
+{
+  #pragma omp parallel firstprivate (A)// { dg-error "is not a 
variable in clause" }
+  ;
+  #pragma omp parallel firstprivate (B<0>) // { dg-error "is not a 
variable in clause" }
+  ;
+}

Jakub

Re: [PATCH][committed][PR tree-optimization/82123] 01/06 Do nothing in EVRP analyzer is not optimizing

[Jeff Law]

On 02/26/2018 05:27 AM, Richard Biener wrote:
> On Tue, Feb 20, 2018 at 7:49 PM, Jeff Law  wrote:
>> This is part #1 of the patches to fix 81592/82123.  The changes aren't
>> particularly large or invasive, but I already had them broken down
>> internally into distinct chunks, so I'm going to send them out that way.
>>
>> This patch allows the EVRP range analyzer to be safely called even when
>> not optimizing.  It does no analysis in that case.   This prevents
>> problems if we were to ask for sprintf warnings but not have the
>> optimizer enabled.
> 
> I don't really understand the issue -- when called from sprintf warnings
> the evrp analyzer shouldn't "optimize" anything, it only does analysis.
> How is that ever a problem when not optimizing?
When not optimizing we can have _DECL nodes showing in in places we
don't expect them.  We also don't consistently canonicalize conditions.
There may be other issues as well, I didn't dig deeply into all of them.

This causes all kinds of grief when we try to analyze statements.

Ideally we'll fix this stuff in gcc-9.  Until then it seems far better
to have the analyzer protect itself from this cruft than forcing every
consumer to guard calls into the analyzer.

Jeff

Re: [PATCH] expand description of poly_int conversions

[Richard Sandiford]

Martin Sebor  writes:
> Richard,
>
> If you agree, I'd like to update the conversion section of
> the poly_int manual to make the conversion to make it clearer
> that the to_constant() function can be used even with class
> types like offset_int besides scalars.
>
> Also, when testing this I also tried converting poly64_int
> into wide_int but that doesn't work.  Is there a way to do
> that?

Not in one go, because you have to specify the intended precision
of the wide_int when constructing it from something like HOST_WIDE_INT.
(That's deliberate.)

>
> Thanks
> Martin
>
> gcc/ChangeLog:
>
>   * doc/poly-int.texi (is_constant): Expand.
>
> Index: gcc/doc/poly-int.texi
> ===
> --- gcc/doc/poly-int.texi (revision 258004)
> +++ gcc/doc/poly-int.texi (working copy)
> @@ -836,9 +836,24 @@ Return true if @code{poly_int} @var{value} is a co
>  
>  @item @var{value}.is_constant (&@var{c1})
>  Return true if @code{poly_int} @var{value} is a compile-time constant,
> -storing it in @var{c1} if so.  @var{c1} must be able to hold all
> -constant values of @var{value} without loss of precision.
> +storing it in @var{c1} if so.  @var{c1} may be a scalar or a wide int
> +class type capable of holding all constant values of @var{value} without

Not sure about "a scalar or a wide int", since that implies that wide ints
aren't scalar.  Even more pedantic, sorry, but c1 is an object rather than
a type.

At a higher level, I'm a bit nervous about singling this out as a special
case, since all the poly_int stuff allows HOST_WIDE_INT, offset_int and
wide_int to be combined in the (hopefully) natural way.  E.g. you can
add offset_ints to poly_int64s, assign HOST_WIDE_INTs to poly_offset_ints,
and so on.

But if we do keep it like this, how about:

  @var{c1} must be some form of integer object that can hold all constant
  values of @var{value} without loss of precision; it can be either a normal
  C++ integer or a wide-int class like @code{offset_int}.

?

> +loss of precision.  The following example illustrates using the function
> +to convert a @code{poly64_int} to @code{HOST_WIDE_INT} and to
> +@code{offset_int}.
> +@smallexample
> +void f (poly64_int pi)

poly_int64

> +@{
> +  HOST_WIDE_INT hwi;
> +  if (pi.is_constant ())
> +; // Use hwi...
> +  offset_int off;
> +  if (pi.is_constant ())
> +; // Use off...
> +@}
> +@end smallexample
>  
> +
>  @item @var{value}.to_constant ()
>  Assert that @var{value} is a compile-time constant and return its value.
>  When using this function, please add a comment explaining why the

No need for the extra blank line.

Thanks,
Richard

Re: [PATCH] Correct debug for -mcall-ms2sysv-xlogues stubs (PR target/83917, take 2)

[Jeff Law]

On 02/22/2018 07:56 AM, Jakub Jelinek wrote:
> Hi!
> 
> On Sat, Jan 20, 2018 at 06:01:16PM -0600, Daniel Santos wrote:
>> Thanks.  I like the idea of commonizing the macros for consistency.
> 
> Didn't see a progress on this P3 for a while, so I've written this
> version of the patch; no tests though, what I've been using in testing was:
> /* { dg-do compile { target lp64 } } */
> /* { dg-options "-mno-avx -msse2 -mcall-ms2sysv-xlogues -O2" } */
> 
> void __attribute__((sysv_abi, noipa))
> foo (void)
> {
> }
> 
> static void __attribute__((sysv_abi)) (*volatile foop) () = foo;
> 
> void __attribute__((ms_abi, noipa))
> bar (void)
> {
>   foop ();
> }
> 
> int
> main ()
> {
>   bar ();
>   return 0;
> }
> 
> with/without -fno-omit-frame-pointer, disas bar; b on the tail
> call in there, stepi; bt (which before the patch failed, now works),
> also up; p $rbp to see if %rbp has been properly declared to be saved.
> There is no need to cfi_startproc/cfi_endproc for every single entrypoint in
> there, it is enough if the whole range is covered.  On the other side
> we need the cfi_offset for the frame pointer case, otherwise up; p/x $rbp
> doesn't work properly.
> 
> Ok for trunk if it passes bootstrap/regtest on x86_64-linux and i686-linux?
> 
> 2018-02-22  Jakub Jelinek  
> 
>   PR debug/83917
>   * config/i386/i386-asm.h (PACKAGE_VERSION, PACKAGE_NAME,
>   PACKAGE_STRING, PACKAGE_TARNAME, PACKAGE_URL): Undefine between
>   inclusion of auto-target.h and auto-host.h.
>   (USE_GAS_CFI_DIRECTIVES): Define if not defined already based on
>   __GCC_HAVE_DWARF2_CFI_ASM.
>   (cfi_startproc, cfi_endproc, cfi_adjust_cfa_offset,
>   cfi_def_cfa_register, cfi_def_cfa, cfi_register, cfi_offset, cfi_push,
>   cfi_pop): Define.
>   * config/i386/cygwin.S: Don't include auto-host.h here, just
>   define USE_GAS_CFI_DIRECTIVES to 1 or 0 and include i386-asm.h.
>   (cfi_startproc, cfi_endproc, cfi_adjust_cfa_offset,
>   cfi_def_cfa_register, cfi_register, cfi_push, cfi_pop): Remove.
>   * config/i386/resms64fx.h: Add cfi_* directives.
>   * config/i386/resms64x.h: Likewise.
It's a bit ugly.  But OK.  We can refine further if needed.

jeff

Re: [PING] [PATCH] consider successor blocks when avoiding -Wstringop-truncation (PR 84468)

[Jeff Law]

On 02/24/2018 05:11 PM, Martin Sebor wrote:
> Attached is an updated patch with a fix for a bad assumption
> exposed by building the linux kernel.
> 
> On 02/19/2018 07:50 PM, Martin Sebor wrote:
>> PR 84468 points out a false positive in -Wstringop-truncation
>> in code like this:
>>
>>   struct A { char a[4]; };
>>
>>   void f (struct A *p, const struct A *q)
>>   {
>>     if (p->a)
>>   strncpy (p->a, q->a, sizeof p->a - 1);   // warning here
>>
>>     p->a[3] = '\0';
>>   }
>>
>> The warning is due to the code checking only the same basic block
>> as the one with the strncpy call for an assignment to the destination
>> to avoid it, but failing to check the successor basic block if there
>> is no subsequent statement in the current block.  (Eliminating
>> the conditional is being tracked in PR 21474.)
>>
>> The attached test case adds logic to avoid this false positive.
>> I don't know under what circumstances there could be more than
>> one successor block here so I don't handle that case.
So this is feeling more and more like we need to go back to the ideas
behind checking the virtual operand chains.

The patch as-written does not properly handle the case where BB has
multiple outgoing edges.  For gcc-8 you could probably get away with
checking that you have precisely one outgoing edge without EDGE_ABNORMAL
set in its flags in addition to the checks you're already doing.

But again, it's feeling more and more like the right fix is to go back
and walk the virtual operands.

Jeff

C++ PATCH for c++/84551, ICE with concepts and DEBUG_BEGIN_STMT

[Jason Merrill]

DEBUG_BEGIN_STMT was confusing the concepts machinery, and it isn't
useful in concepts, which are never expanded.

Tested x86_64-pc-linux-gnu, applying to trunk.
commit 8a2a7e8672b17af0231c82b6f3d4429efddec0d6
Author: Jason Merrill 
Date:   Mon Feb 26 13:48:34 2018 -0500

PR c++/84551 - ICE with concepts and -g.

* parser.c (add_debug_begin_stmt): Do nothing in a concept.

diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 4fa546a086c..f305c9c7eba 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -10699,6 +10699,9 @@ add_debug_begin_stmt (location_t loc)
 {
   if (!MAY_HAVE_DEBUG_MARKER_STMTS)
 return;
+  if (DECL_DECLARED_CONCEPT_P (current_function_decl))
+/* A concept is never expanded normally.  */
+return;
 
   tree stmt = build0 (DEBUG_BEGIN_STMT, void_type_node);
   SET_EXPR_LOCATION (stmt, loc);
diff --git a/gcc/testsuite/g++.dg/concepts/debug1.C 
b/gcc/testsuite/g++.dg/concepts/debug1.C
new file mode 100644
index 000..eeb63654243
--- /dev/null
+++ b/gcc/testsuite/g++.dg/concepts/debug1.C
@@ -0,0 +1,10 @@
+// PR c++/84551
+// { dg-options "-g -O -std=c++17 -fconcepts" }
+
+template concept bool C() { return true; }
+
+template