C++ PATCH for c++/85215, C++17 ICE initializing from conversion function

[Jason Merrill]

conv_binds_ref_to_prvalue was expecting that if a user-defined
conversion uses a conversion function returning a reference, the
conversion will have reference type.  This wasn't the case, because
build_user_type_conversion_1 strips the reference from the return type
to get the type of the conversion.

It seems to me that in the case of direct binding to a reference, we
want the conversion to have reference type.

Tested x86_64-pc-linux-gnu, applying to trunk.
commit 819e3be84751834a5e70df910f1d1726ea1b82f5
Author: Jason Merrill 
Date:   Wed Apr 4 20:27:29 2018 -0400

PR c++/85215 - ICE with copy-init from conversion.

* call.c (merge_conversion_sequences): Fix type of direct binding
sequence.

diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index 7c99e8ad910..f2ada2768de 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -3642,6 +3642,12 @@ merge_conversion_sequences (conversion *user_seq, conversion *std_seq)
 	(*t)->bad_p = true;
 }
 
+  if ((*t)->rvaluedness_matches_p)
+/* We're binding a reference directly to the result of the conversion.
+   build_user_type_conversion_1 stripped the REFERENCE_TYPE from the return
+   type, but we want it back.  */
+user_seq->type = TREE_TYPE (TREE_TYPE (user_seq->cand->fn));
+
   /* Replace the identity conversion with the user conversion
  sequence.  */
   *t = user_seq;
diff --git a/gcc/testsuite/g++.dg/cpp1z/elide3.C b/gcc/testsuite/g++.dg/cpp1z/elide3.C
new file mode 100644
index 000..ca4d24708a8
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1z/elide3.C
@@ -0,0 +1,15 @@
+// PR c++/85215
+// { dg-do compile { target c++11 } }
+
+template  struct vector {
+  vector(vector &&) noexcept;
+};
+
+template  struct any_container {
+  operator vector &&();
+};
+
+void f (any_container c)
+{
+  vector shape (c);
+}

Re: [PATCH] c/55976 -Werror=return-type should error on returning a value from a void function

[Martin Sebor]

On 04/04/2018 05:50 PM, dave.pa...@oracle.com wrote:

On 04/04/2018 10:58 AM, Martin Sebor wrote:

On 04/04/2018 11:15 AM, Jakub Jelinek wrote:

On Tue, Apr 03, 2018 at 01:36:13PM -0600, Martin Sebor wrote:

On 04/03/2018 10:26 AM, dave.pa...@oracle.com wrote:

This patch fixes handlng of -Werror=return-type. Currently, even with
the flag specified, return type errors remain warnings.

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

Function c_finish_return (), when calling pedwarn, should specifiy
OPT_Wreturn_type as the diagnostic index if warn_return_type is set so
that the given diagnostic is generated as an error, not a warning.

Patch was successfully bootstrapped and tested on x86_64-linux.


I would expect the option to control the warning consistently so
that when the test case is compiled with just -Wno-return-type
(and no other options) the warning is not issued.  But that's not
what happens because pedwarn() is called with a zero argument as
the option.


I think we need to make sure we error out even with -Wno-return-type
when -pedantic-errors.


That would seem surprising to me.  Is there an existing
precedent for this in GCC? (Any other warnings or options
that are treated this way?)

It would also diverge from Clang, which would be particularly
unhelpful to users of both compilers.  I would suggest to
follow what Clang does in terms of controlling the warning
(though not necessarily in its severity).  It's consistent
and intuitive.  (Clang has -Werror=return-type by default;
that may be overly strict.)


I think these are both good points. While I tend to lean toward
consistency (both within GCC and with clang), if this sort of problem is
potentially worse in GCC 8 (as Jakub suggests) then perhaps it's worth
thinking about how to help prevent it. If we do choose to go this
direction with -pedantic-errors, and there isn't a precedent for it,
then the documentation would require an update to reflect the new behavior.


I actually don't think -Wpedantic is the appropriate option
to control the warning in the case Jakub is concerned about
(it may be appropriate for warning about returning a value
from a void function because that's a constraint violation).
-Wpedantic is meant for diagnostics that are required by
the C/C++ standards but that GCC may otherwise silently
accept as extensions.  Defining a non-void function that
doesn't return a value is valid in C is not incorrect and
does not require a diagnostic.  (Using the return value
is undefined, but when it isn't used there is no problem.)

(This is different in recent versions of C++ where a return
statement with no operand in a non-void function requires
a diagnostic, so the C++ handling may need to be different.)


Also, thoughts on this question from my last email?


Since this patch does fix the original problem, what do you recommend?
Scrap this patch? Or let it proceed and submit a new bug noting the
(existing) incorrect behavior of -Wno-return-type?


We could add the discussion in this email to any new bug we create for
-Wno-return-type.


I think for C, handling it under the same bug and in the same
patch would be best.  The C++ bits could come later if needed.

Martin



--Dave


Martin


Especially when issues this pedwarn warns about are
very hard to debug show stoppers for anybody calling such functions
in GCC 8
(because we turn such spots into __builtin_unreachable () and thus
randomly
can execute completely unrelated code).  So, I think consistency
isn't that
important here.

Jakub

[C++ Patch] PR 84792 ("[6/7/8 Regression] ICE with broken typedef of a struct")

[Paolo Carlini]

Hi,

I'm really happy to report that these 5 ugly lines are causing an actual 
bug. Seriously, not considering the formatting, the problem is that we 
really want to keep 'type' in sync, because we are using it below before 
returning. Note that we don't regress location-wise because either 
explicitly or implicitly we pass input_location anyway. Finishing 
testing on x86_64-linux.


Thanks, Paolo.



/cp
2018-04-04  Paolo Carlini  

PR c++/84792
* decl.c (grokdeclarator): Fix diagnostic about typedef name used
as nested-name-specifier, keep type and TREE_TYPE (decl) in sync.

/testsuite
2018-04-04  Paolo Carlini  

PR c++/84792
* g++.dg/other/pr84792-1.C: New.
* g++.dg/other/pr84792-2.C: Likewise.
Index: cp/decl.c
===
--- cp/decl.c   (revision 259104)
+++ cp/decl.c   (working copy)
@@ -11746,15 +11746,16 @@ grokdeclarator (const cp_declarator *declarator,
   if (reqs)
error_at (location_of (reqs), "requires-clause on typedef");
 
+  if (id_declarator && declarator->u.id.qualifying_scope)
+   {
+ error ("typedef name may not be a nested-name-specifier");
+ type = error_mark_node;
+   }
+
   if (decl_context == FIELD)
decl = build_lang_decl (TYPE_DECL, unqualified_id, type);
   else
decl = build_decl (input_location, TYPE_DECL, unqualified_id, type);
-  if (id_declarator && declarator->u.id.qualifying_scope) {
-   error_at (DECL_SOURCE_LOCATION (decl), 
- "typedef name may not be a nested-name-specifier");
-   TREE_TYPE (decl) = error_mark_node;
-  }
 
   if (decl_context != FIELD)
{
Index: testsuite/g++.dg/other/pr84792-1.C
===
--- testsuite/g++.dg/other/pr84792-1.C  (nonexistent)
+++ testsuite/g++.dg/other/pr84792-1.C  (working copy)
@@ -0,0 +1,6 @@
+struct A {};
+
+typedef struct
+{
+  virtual void foo() {}
+} A::B;  // { dg-error "typedef" }
Index: testsuite/g++.dg/other/pr84792-2.C
===
--- testsuite/g++.dg/other/pr84792-2.C  (nonexistent)
+++ testsuite/g++.dg/other/pr84792-2.C  (working copy)
@@ -0,0 +1,6 @@
+struct A {};
+
+typedef struct
+{
+  void foo() {}
+} A::B;  // { dg-error "typedef" }

C++ PATCH for c++/84938, ICE dividing by ~-1

[Jason Merrill]

set_up_extended_ref_temp does an abbreviated version of
cp_finish_decl, which didn't include the call to cp_fully_fold that
store_init_value does for user-declared variables.  Adding that fixes
this bug.

Tested x86_64-pc-linux-gnu, applying to trunk.
commit 03b96c95fd7b27fa99964741bd9cb771ad56c882
Author: Jason Merrill 
Date:   Wed Apr 4 17:18:28 2018 -0400

PR c++/84938 - ICE with division by ~-1.

* call.c (set_up_extended_ref_temp): Call cp_fully_fold.

diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index f81773157b6..7c99e8ad910 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -10869,6 +10869,8 @@ set_up_extended_ref_temp (tree decl, tree expr, vec **cleanups,
   /* If the initializer is constant, put it in DECL_INITIAL so we get
  static initialization and use in constant expressions.  */
   init = maybe_constant_init (expr);
+  /* As in store_init_value.  */
+  init = cp_fully_fold (init);
   if (TREE_CONSTANT (init))
 {
   if (literal_type_p (type) && CP_TYPE_CONST_NON_VOLATILE_P (type))
diff --git a/gcc/testsuite/g++.dg/expr/div-by-zero1.C b/gcc/testsuite/g++.dg/expr/div-by-zero1.C
new file mode 100644
index 000..63bef406408
--- /dev/null
+++ b/gcc/testsuite/g++.dg/expr/div-by-zero1.C
@@ -0,0 +1,3 @@
+// PR c++/84938
+
+const int &a = 1 / ~-1;		// { dg-warning "division by zero" }

C++ PATCH for c++/84936, ICE with unexpanded pack in mem-init

[Jason Merrill]

We already had code to deal with an unexpanded pack in the
initializer, but not in the member designator.  If we find one, let's
pretend it was expanded.

Tested x86_64-pc-linux-gnu, applying to trunk.
commit cb6bcd45b6bd3c1edc44ad0fbe164135cb17467b
Author: Jason Merrill 
Date:   Wed Apr 4 15:43:21 2018 -0400

PR c++/84936 - ICE with unexpanded pack in mem-initializer.

* parser.c (cp_parser_mem_initializer_list): Call
check_for_bare_parameter_packs.

diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index f6fbcf6185e..59eb8226112 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -14381,10 +14381,15 @@ cp_parser_mem_initializer_list (cp_parser* parser)
   /* Parse the mem-initializer.  */
   mem_initializer = cp_parser_mem_initializer (parser);
   /* If the next token is a `...', we're expanding member initializers. */
-  if (cp_lexer_next_token_is (parser->lexer, CPP_ELLIPSIS))
+  bool ellipsis = cp_lexer_next_token_is (parser->lexer, CPP_ELLIPSIS);
+  if (ellipsis
+	  || (mem_initializer != error_mark_node
+	  && check_for_bare_parameter_packs (TREE_PURPOSE
+		 (mem_initializer
 {
   /* Consume the `...'. */
-  cp_lexer_consume_token (parser->lexer);
+	  if (ellipsis)
+	cp_lexer_consume_token (parser->lexer);
 
   /* The TREE_PURPOSE must be a _TYPE, because base-specifiers
  can be expanded but members cannot. */
diff --git a/gcc/testsuite/g++.dg/cpp0x/variadic175.C b/gcc/testsuite/g++.dg/cpp0x/variadic175.C
new file mode 100644
index 000..969f4b0b152
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/variadic175.C
@@ -0,0 +1,10 @@
+// PR c++/84936
+// { dg-do compile { target c++11 } }
+
+struct A
+{
+  template A(T... t)
+: decltype(t)() {} // { dg-error "parameter pack" }
+};
+
+A a;

Re: [PATCH] c/55976 -Werror=return-type should error on returning a value from a void function

[dave . pagan]

On 04/04/2018 10:58 AM, Martin Sebor wrote:

On 04/04/2018 11:15 AM, Jakub Jelinek wrote:

On Tue, Apr 03, 2018 at 01:36:13PM -0600, Martin Sebor wrote:

On 04/03/2018 10:26 AM, dave.pa...@oracle.com wrote:

This patch fixes handlng of -Werror=return-type. Currently, even with
the flag specified, return type errors remain warnings.

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

Function c_finish_return (), when calling pedwarn, should specifiy
OPT_Wreturn_type as the diagnostic index if warn_return_type is set so
that the given diagnostic is generated as an error, not a warning.

Patch was successfully bootstrapped and tested on x86_64-linux.


I would expect the option to control the warning consistently so
that when the test case is compiled with just -Wno-return-type
(and no other options) the warning is not issued.  But that's not
what happens because pedwarn() is called with a zero argument as
the option.


I think we need to make sure we error out even with -Wno-return-type
when -pedantic-errors.


That would seem surprising to me.  Is there an existing
precedent for this in GCC? (Any other warnings or options
that are treated this way?)

It would also diverge from Clang, which would be particularly
unhelpful to users of both compilers.  I would suggest to
follow what Clang does in terms of controlling the warning
(though not necessarily in its severity).  It's consistent
and intuitive.  (Clang has -Werror=return-type by default;
that may be overly strict.)


I think these are both good points. While I tend to lean toward 
consistency (both within GCC and with clang), if this sort of problem is 
potentially worse in GCC 8 (as Jakub suggests) then perhaps it's worth 
thinking about how to help prevent it. If we do choose to go this 
direction with -pedantic-errors, and there isn't a precedent for it, 
then the documentation would require an update to reflect the new behavior.


Also, thoughts on this question from my last email?

Since this patch does fix the original problem, what do you recommend? 
Scrap this patch? Or let it proceed and submit a new bug noting the 
(existing) incorrect behavior of -Wno-return-type? 


We could add the discussion in this email to any new bug we create for 
-Wno-return-type.


--Dave


Martin


Especially when issues this pedwarn warns about are
very hard to debug show stoppers for anybody calling such functions 
in GCC 8
(because we turn such spots into __builtin_unreachable () and thus 
randomly
can execute completely unrelated code).  So, I think consistency 
isn't that

important here.

Jakub

Re: [wwwdocs] document new options in gcc-8/changes.html

[Paolo Carlini]

Hi Martin

On 05/04/2018 00:28, Martin Sebor wrote:

+ implementations do suppresses the warning.

suppress

Paolo.

[PATCH] Add -fcf-protection -mcet to STAGE4_CFLAGS

[H.J. Lu]

Since profiledbootstrap uses

STAGEfeedback_CFLAGS = $(STAGE4_CFLAGS) -fprofile-use

add

STAGE4_CFLAGS += -fcf-protection -mcet

to bootstrap-cet.mk to support profiledbootstrap with CET.

OK for trunk?


H.J.
---
---
 config/bootstrap-cet.mk | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/config/bootstrap-cet.mk b/config/bootstrap-cet.mk
index f09193a6dea..30e99f22fac 100644
--- a/config/bootstrap-cet.mk
+++ b/config/bootstrap-cet.mk
@@ -1,4 +1,5 @@
-# This option enables -fcf-protection -mcet for stage2 and stage3.
+# This option enables -fcf-protection -mcet for stage2, stage3 and stage4.
 
 STAGE2_CFLAGS += -fcf-protection -mcet
 STAGE3_CFLAGS += -fcf-protection -mcet
+STAGE4_CFLAGS += -fcf-protection -mcet
-- 
2.14.3

Re: [wwwdocs] document new options in gcc-8/changes.html

[Martin Sebor]

Attached is an updated diff rebased on top of the latest revision
of the file.  This new version fixes the typos Paolo pointed out
(thanks) and adds a few more options:

-Wmissing-attributes, -Wif-not-aligned, and -Wpacked-not-aligned.

I used a spell-checker this time to (hopefully) minimize the typos.

The rest of the changes are described here:
https://gcc.gnu.org/ml/gcc-patches/2018-04/msg00121.html

Martin
Index: changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-8/changes.html,v
retrieving revision 1.52
diff -u -r1.52 changes.html
--- changes.html	4 Apr 2018 17:43:03 -	1.52
+++ changes.html	4 Apr 2018 22:21:49 -
@@ -1,4 +1,4 @@
-
+
 
 
 GCC 8 Release Series — Changes, New Features, and Fixes
@@ -9,7 +9,7 @@
 -->
 
 
-GCC 8 Release SeriesChanges, New Features, and Fixes
+GCC 8 Release SeriesChanges, New Features, and Fixes
 
 
 This page is a "brief" summary of some of the huge number of improvements
@@ -113,6 +113,20 @@
 possible for the user to have a finer-grained control over the loop
 unrolling optimization.
   
+  
+GCC has been enhanced to detect more instances of meaningless or
+mutually exclusive attribute specifications and handle such conflicts
+more consistently.  Mutually exclusive attribute specifications are
+ignored with a warning regardless of whether they appear on the same
+declaration or on distinct declarations of the same entity.  For
+example, because the noreturn attribute on the second
+declaration below is mutually exclusive with the malloc
+attribute on the first, it is ignored and a warning is issued.
+
+  void* __attribute__ ((malloc)) f (unsigned);
+  void* __attribute__ ((noreturn)) f (unsigned);
+
+  warning: ignoring attribute 'noreturn' because it conflicts with attribute 'malloc' [-Wattributes]
 
 
 
@@ -172,10 +186,77 @@
 
 New command-line options have been added for the C and C++ compilers:
   
-	-Wmultistatement-macros warns about unsafe macros
-	expanding to multiple statements used as a body of a clause such
-	as if, else, while,
-	switch, or for.
+	https://gcc.gnu.org/onlinedocs/gcc-8.1.0/gcc/Warning-Options.html#index-Wmultistatement-macros";>-Wmultistatement-macros
+	  warns about unsafe macros expanding to multiple statements used
+	  as a body of a statement such as if, else,
+	  while, switch, or for.
+	https://gcc.gnu.org/onlinedocs/gcc-8.1.0/gcc/Warning-Options.html#index-Wstringop-truncation";>-Wstringop-truncation
+	  warns for calls to bounded string manipulation functions such as
+	  strncat, strncpy, and stpncpy
+	  that might either truncate the copied string or leave the destination
+	  unchanged.  For example, the following call to strncat
+	  is diagnosed because it appends just three of the four characters
+	  from the source string.
+	void append (char *buf, size_t bufsize)
+	{
+	strncat (buf, ".txt", 3);
+	}
+	warning: 'strncat' output truncated copying 3 bytes from a string of length 4 [-Wstringop-truncation]
+	  Similarly, in the following example, the call to strncpy
+	  specifies the size of the destination buffer as the bound.  If the
+	  length of the source string is equal to or greater than this size
+	  the result of the copy will not be NUL-terminated.  Therefore,
+	  the call is also diagnosed.  To avoid the warning, specify
+	  sizeof buf - 1 as the bound and set the last element of
+	  the buffer to NUL.
+	void copy (const char *s)
+	{
+	char buf[80];
+	strncpy (buf, s, sizeof buf);
+	…
+	}
+	warning: 'strncpy' specified bound 80 equals destination size [-Wstringop-truncation]
+	  The -Wstringop-truncation option is included in
+	  -Wall.
+	  Note that due to GCC bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82944"; title="missing -Wstringop-truncation on strncpy due to system header macro">82944, defining strncat, strncpy,
+	  or stpncpy as a macro in a system header as some
+	  implementations do suppresses the warning.
+	https://gcc.gnu.org/onlinedocs/gcc-8.1.0/gcc/Warning-Options.html#index-Wif-not-aligned";>-Wif-not-aligned controls warnings issued in response
+	  to invalid uses of objects declared with attribute
+	  https://gcc.gnu.org/onlinedocs/gcc-8.1.0/gcc/Common-Variable-Attributes.html#index-warn_005fif_005fnot_005faligned-variable-attribute";>warn_if_not_aligned.
+	  The -Wif-not-aligned option is included in
+	  -Wall.
+	https://gcc.gnu.org/onlinedocs/gcc-8.1.0/gcc/Warning-Options.html#index-Wmissing-attributes";>-Wmissing-attributes warns
+	  when a declaration of a function is missing one or more attributes
+	  that a related function is declared with and whose absence may
+	  adversely affect the correctness or efficiency of generated code.
+	  For example, in C++, the warning is issued when an explicit
+	  specialization of a primary template declared with attribute
+	  alloc_align, alloc_size,
+	  assume_

[C++ PATCH] Implement P0961

[Ville Voutilainen]

Tested on Linux-PPC64.

2018-04-05  Ville Voutilainen  

gcc/cp

Implement P0961
* decl.c (get_tuple_decomp_init): Check the templatedness
of a member get.

testsuite/

Implement P0961
* g++.dg/cpp1z/decomp10.C: Adjust.
* g++.dg/cpp1z/decomp37.C: New.
diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index 746084c..1a100c8 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -7432,7 +7432,24 @@ get_tuple_decomp_init (tree decl, unsigned i)
 
   tree fns = lookup_qualified_name (TREE_TYPE (e), get_id,
 /*type*/false, /*complain*/false);
-  if (fns != error_mark_node)
+  bool use_member_get = false;
+
+  for (lkp_iterator iter (MAYBE_BASELINK_FUNCTIONS (fns)); iter; ++iter)
+{
+  tree fn = *iter;
+  if (TREE_CODE (fn) == TEMPLATE_DECL)
+	{
+	  tree tparms = DECL_TEMPLATE_PARMS (fn);
+	  tree parm = TREE_VEC_ELT (TREE_VALUE (tparms), 0);
+	  if (TREE_CODE (TREE_VALUE (parm)) == PARM_DECL)
+	{
+	  use_member_get = true;
+	  break;
+	}
+	}
+}
+
+  if (use_member_get)
 {
   fns = lookup_template_function (fns, targs);
   return build_new_method_call (e, fns, /*args*/NULL,
diff --git a/gcc/testsuite/g++.dg/cpp1z/decomp10.C b/gcc/testsuite/g++.dg/cpp1z/decomp10.C
index 6ed9272..b4169d3 100644
--- a/gcc/testsuite/g++.dg/cpp1z/decomp10.C
+++ b/gcc/testsuite/g++.dg/cpp1z/decomp10.C
@@ -20,7 +20,7 @@ void f3() { auto [ x ] = a3; }	// { dg-error "get" }
 
 struct A3a { int i,j; int get(); } a3a;
 template<> struct std::tuple_size { enum { value = 1 }; };
-void f3a() { auto [ x ] = a3a; }	// { dg-error "get<0>" }
+void f3a() { auto [ x ] = a3a; }	// { dg-error "get" }
 
 struct A3b { int i,j; } a3b;
 int get(A3b&&);
diff --git a/gcc/testsuite/g++.dg/cpp1z/decomp37.C b/gcc/testsuite/g++.dg/cpp1z/decomp37.C
new file mode 100644
index 000..dc47908
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1z/decomp37.C
@@ -0,0 +1,62 @@
+// { dg-additional-options -std=c++17 }
+// { dg-do compile }
+
+#include 
+#include 
+#include 
+
+struct X : private std::shared_ptr
+{
+  std::string fun_payload;
+};
+
+template std::string& get(X& x)
+{
+  if constexpr(N==0) return x.fun_payload;
+}
+
+namespace std {
+  template<> class tuple_size : public std::integral_constant {};
+  template<> class tuple_element<0, X> {public: using type = std::string;};
+}
+
+struct X2 : private std::shared_ptr
+{
+  int fun_payload;
+  template  void get();
+};
+
+template int& get(X2& x)
+{
+  if constexpr(N==0) return x.fun_payload;
+}
+
+namespace std {
+  template<> class tuple_size : public std::integral_constant {};
+  template<> class tuple_element<0, X2> {public: using type = int;};
+}
+
+class X3
+{
+  double fun_payload;
+public:
+  template  double& get()
+  {
+if constexpr(N==0) return fun_payload;
+  }
+};
+
+namespace std {
+  template<> class tuple_size : public std::integral_constant {};
+  template<> class tuple_element<0, X3> {public: using type = double;};
+}
+
+int main()
+{
+  X x;
+  auto& [b1] = x;
+  X2 x2;
+  auto& [b2] = x2;
+  X3 x3;
+  auto& [b3] = x3;
+}

[PATCH] Fix BIT_FIELD_REF folding (PR middle-end/85195)

[Jakub Jelinek]

Hi!

On the following testcase because of the SCCVN limit we end up with a weird,
but valid, BIT_FIELD_REF - trying to extract V1TImode type out of a V1TImode
SSA_NAME, with 128 bits width and offset 0 (just SSA_NAME move would be
enough).  Not trying to address why we create it, rather fix how we handle
it.

The problem is that the BIT_FIELD_REF vector extraction is guarded with:
 (if (VECTOR_TYPE_P (TREE_TYPE (@0))
  && (types_match (type, TREE_TYPE (TREE_TYPE (@0)))
  || (VECTOR_TYPE_P (type)
  && types_match (TREE_TYPE (type), TREE_TYPE (TREE_TYPE (@0))
and thus we must handle vector type as result, but assume incorrectly that
if count is 1, then we must be asking for an element and thus not vector
type.  For the first hunk we could do what we do in the second hunk, do
a VIEW_CONVERT_EXPR, but it seems cleaner to just fall through into the
count > 1 code which builds a CONSTRUCTOR.

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

2018-04-04  Jakub Jelinek  

PR middle-end/85195
* match.pd (BIT_FIELD_REF CONSTRUCTOR@0 @1 @2): If count == 1, only
use elt value if type is not vector type, otherwise build CONSTRUCTOR.
For n == const_k, use view_convert.

* gcc.dg/pr85195.c: New test.

--- gcc/match.pd.jj 2018-03-28 21:15:00.0 +0200
+++ gcc/match.pd2018-04-04 14:35:10.424127155 +0200
@@ -4648,7 +4648,7 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
   (if (multiple_p (idx, k, &elt) && multiple_p (n, k, &count))
(if (CONSTRUCTOR_NELTS (ctor) == 0)
 { build_constructor (type, NULL); }
-   (if (count == 1)
+   (if (count == 1 && !VECTOR_TYPE_P (type))
 (if (elt < CONSTRUCTOR_NELTS (ctor))
  { CONSTRUCTOR_ELT (ctor, elt)->value; }
  { build_zero_cst (type); })
@@ -4668,7 +4668,7 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
(if (CONSTRUCTOR_NELTS (ctor) <= idx / const_k)
 { build_zero_cst (type); })
(if (n == const_k)
-{ CONSTRUCTOR_ELT (ctor, idx / const_k)->value; })
+(view_convert { CONSTRUCTOR_ELT (ctor, idx / const_k)->value; }))
(BIT_FIELD_REF { CONSTRUCTOR_ELT (ctor, idx / const_k)->value; }
   @1 { bitsize_int ((idx % const_k) * width); })
 
--- gcc/testsuite/gcc.dg/pr85195.c.jj   2018-04-04 14:38:29.233235494 +0200
+++ gcc/testsuite/gcc.dg/pr85195.c  2018-04-04 14:38:14.696227566 +0200
@@ -0,0 +1,19 @@
+/* PR middle-end/85195 */
+/* { dg-do compile { target int128 } } */
+/* { dg-options "-Wno-psabi -O -fno-tree-ccp --param=sccvn-max-scc-size=10" } 
*/
+
+typedef __int128 V __attribute__ ((vector_size (16)));
+
+extern int bar (V);
+
+V v;
+int i;
+
+V
+foo (void)
+{
+  do
+v *= bar (v & i);
+  while ((V){}[0]);
+  return v;
+}

Jakub

Re: [wwwdocs] gcc-8/changes.html additions

[Bernd Edlinger]

On 04/04/18 22:11, Martin Sebor wrote:
> On 04/04/2018 12:24 PM, Bernd Edlinger wrote:
>> Hi,
>>
>> this adds a few gcc command line options to gcc-8/changes.html which
>> I added for gcc-8.
> 
> Just a couple of suggestions:
> 
> 1) Use  to render sizeof in monospace:
> 
> +    -Wsizeof-pointer-div warns for suspicious divisions
> +    of two sizeof expressions that divide the pointer size by the element
> 
> 2) The verb in
> 
> +    -fprofile-abs-path create absolute path names...
> 
> should presumably be "creates" in keeping with the descriptive
> tone used for the other options.
> 

Done, thanks!
Attached is the updated patch.

Is it OK for wwwdocs?


Bernd.


Index: htdocs/gcc-8/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-8/changes.html,v
retrieving revision 1.52
diff -u -r1.52 changes.html
--- htdocs/gcc-8/changes.html	4 Apr 2018 17:43:03 -	1.52
+++ htdocs/gcc-8/changes.html	4 Apr 2018 21:24:15 -
@@ -177,6 +177,30 @@
 	as if, else, while,
 	switch, or for.
   
+  
+	-Wcast-function-type warns when a function pointer
+	is cast to an incompatible function pointer.  This warning is enabled
+	by -Wextra.
+  
+  
+	-Wsizeof-pointer-div warns for suspicious divisions
+	of two sizeof expressions that divide the pointer size by
+	the element size, which is the usual way to compute the array size but
+	won't work out correctly with pointers.
+	This warning is enabled by -Wall.
+  
+  
+	-Wcast-align=strict warns whenever a pointer is cast
+	such that the required alignment of the target is increased.  For
+	example, warn if a char * is cast to an int *
+	regardless of the target machine.
+  
+  
+	-fprofile-abs-path creates absolute path names in the
+	.gcno files.  This allows gcov to find the
+	correct sources in projects where compilations occur with different
+	working directories.
+  
 
 -fno-strict-overflow is now mapped to
  -fwrapv -fwrapv-pointer and signed integer overflow

Re: [PATCH, rtl] Fix PR84878: Segmentation fault in add_cross_iteration_register_deps

[Peter Bergner]

On 4/4/18 2:23 PM, Richard Biener wrote:
> On April 4, 2018 8:25:25 PM GMT+02:00, Peter Bergner  
> wrote:
>>> Nobody mentioned if this was a regression or not, so I did some testing
>>> and it ICEs on GCC 7 but not on GCC 6.  Is it ok to back port to GCC 7
>>> assuming bootstrap and regtesting are clean?
>
> Sure.

The backport testing showed no regressions, so I committed it to GCC 7.
Thanks!

Peter

Re: [PATCH, rs6000] Undefine vector, bool, pixel in xmmintrin.h

[Bill Schmidt]

On Apr 4, 2018, at 3:51 PM, Jakub Jelinek  wrote:
> 
> On Wed, Apr 04, 2018 at 03:47:18PM -0500, Bill Schmidt wrote:
>>> If we (for GCC9?) want to create a spot for target C++ tests, we should
>>> just add g++.target// directories and add all the needed infrastructure
>>> for those.
>>> 
>>> Can you please revert the powerpc.exp change and move the test to
>>> g++.dg/ext/ ?  Thanks.
>> 
>> Sure, I can -- I just want to point out that there is precedent here.  I 
>> noticed
> 
> Thanks.
> 
>> that gcc.target/s390/s390.exp allows .C suffixes and there is one such
>> (compile-only) test in that directory, so I assumed the framework was okay
>> for this.
> 
> Yes, and apparently aarch64 and arm have a couple of *.C tests too.
> Still it doesn't feel right, running C++ tests under make check-gcc rather
> than check-g++ is just weird.
> 
> I think we should just introduce g++.target/ in GCC9 and move those tests
> there, plus any g++.dg/ tests guarded for single targets only.  g++.target
> should do the -std=c++{98,11,14,17,2a} cycling etc.

Agreed.  I'll take a note about this for GCC9.

Thanks,
Bill

Re: [PATCH, rs6000] Undefine vector, bool, pixel in xmmintrin.h

[Bill Schmidt]

> On Apr 4, 2018, at 3:53 AM, Jakub Jelinek  wrote:
> 
> On Sun, Apr 01, 2018 at 08:24:32PM -0500, Bill Schmidt wrote:
>> I also updated the gcc.target/powerpc/powerpc.exp file to allow C++
>> tests to be placed in that directory (with a *.C suffix).
> 
> I think this is wrong.
> Historically, we've been putting target C++ tests into g++.dg/*/*.C
> with appropriate target guards, the gcc.target/ tests are compiled with the
> gcc driver rather than g++, so in your case it just happens to work because
> it is a compile time test only (and one that doesn't use any STL headers),
> e.g. dg-do run test would fail miserably.
> 
> If we (for GCC9?) want to create a spot for target C++ tests, we should
> just add g++.target// directories and add all the needed infrastructure
> for those.
> 
> Can you please revert the powerpc.exp change and move the test to
> g++.dg/ext/ ?  Thanks.

Sure, I can -- I just want to point out that there is precedent here.  I noticed
that gcc.target/s390/s390.exp allows .C suffixes and there is one such
(compile-only) test in that directory, so I assumed the framework was okay
for this.

Thanks,
Bill

> 
>   Jakub
> 

[C++ PATCH] Fix __builtin_constant_p constexpr handling (PR inline-asm/85172)

[Jakub Jelinek]

Hi!

As the following testcases show, potential_constant_expression_1 for some
builtins returns true no matter what their arguments contain (intentionally
so); the problem is that we call unconditionally
cxx_eval_constant_expression on those arguments and that creates a loophole;
normally potential_constant_expression_1 is a check what kind of expressions
we allow in and cxx_eval* can only handle what we accept by that; through
these builtins, anything else can appear there too.
The following patch checks if the expression is potential constant
expression before trying to call cxx_eval_constant_expression, but to avoid
exponential compile time it checks it only for those builtins where
potential_constant_expression_1 has not checked those arguments.

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

2018-04-04  Jakub Jelinek  

PR inline-asm/85172
* constexpr.c (cxx_eval_builtin_function_call): For calls to
builtin_valid_in_constant_expr_p functions, don't call
cxx_eval_constant_expression if argument is not
potential_constant_expression.

* g++.dg/ext/builtin13.C: New test.
* g++.dg/ext/atomic-4.C: New test.

--- gcc/cp/constexpr.c.jj   2018-04-03 23:39:16.535665285 +0200
+++ gcc/cp/constexpr.c  2018-04-04 12:25:32.290813343 +0200
@@ -1189,8 +1189,14 @@ cxx_eval_builtin_function_call (const co
   bool dummy1 = false, dummy2 = false;
   for (i = 0; i < nargs; ++i)
 {
-  args[i] = cxx_eval_constant_expression (&new_ctx, CALL_EXPR_ARG (t, i),
- false, &dummy1, &dummy2);
+  args[i] = CALL_EXPR_ARG (t, i);
+  /* If builtin_valid_in_constant_expr_p is true,
+potential_constant_expression_1 has not recursed into the arguments
+of the builtin, verify it here.  */
+  if (!builtin_valid_in_constant_expr_p (fun)
+ || potential_constant_expression (args[i]))
+   args[i] = cxx_eval_constant_expression (&new_ctx, args[i], false,
+   &dummy1, &dummy2);
   if (bi_const_p)
/* For __built_in_constant_p, fold all expressions with constant values
   even if they aren't C++ constant-expressions.  */
--- gcc/testsuite/g++.dg/ext/builtin13.C.jj 2018-04-04 12:11:03.566767129 
+0200
+++ gcc/testsuite/g++.dg/ext/builtin13.C2018-04-04 12:11:34.380768131 
+0200
@@ -0,0 +1,9 @@
+// PR inline-asm/85172
+// { dg-do compile }
+// { dg-options "" }
+
+int
+foo ()
+{
+  return !__builtin_constant_p (({ __asm (""); 0; }));
+}
--- gcc/testsuite/g++.dg/ext/atomic-4.C.jj  2018-04-04 12:10:54.239766822 
+0200
+++ gcc/testsuite/g++.dg/ext/atomic-4.C 2018-04-04 12:11:56.058768833 +0200
@@ -0,0 +1,9 @@
+// PR inline-asm/85172
+// { dg-do compile }
+// { dg-options "" }
+
+int
+foo (int *p)
+{
+  return !__atomic_always_lock_free (4, ({ __asm (""); p; }));
+}

Jakub

Re: [wwwdocs] gcc-8/changes.html additions

[Martin Sebor]

On 04/04/2018 12:24 PM, Bernd Edlinger wrote:

Hi,

this adds a few gcc command line options to gcc-8/changes.html which
I added for gcc-8.


Just a couple of suggestions:

1) Use  to render sizeof in monospace:

+   -Wsizeof-pointer-div warns for suspicious divisions
+   of two sizeof expressions that divide the pointer size by the element

2) The verb in

+   -fprofile-abs-path create absolute path names...

should presumably be "creates" in keeping with the descriptive
tone used for the other options.

Martin

Re: C++ PATCH for c++/84221, bogus -Wunused with unused attribute on template

[Martin Sebor]

On 04/04/2018 01:58 PM, Jason Merrill wrote:

On Wed, Apr 4, 2018 at 3:52 PM, Martin Sebor  wrote:

On 04/04/2018 01:04 PM, Jason Merrill wrote:


For bugs 54372 and 60063, we changed attributes used and unused to be
applied immediately in a template even if what they apply to is
dependent, to avoid bogus warnings from
maybe_warn_unused_local_typedefs.  But that's only an issue for
TYPE_DECL, so we can use the normal logic for other things.


In our discussion of attributes I thought we decided that explicit
specializations would not inherit attributes from the primary.
IIUC, this change does the opposite for class templates declared
unused so we end up with an inconsistency with function templates:


I thought about that as well, tested with the explicit specialization
removed, and found that still failed.  So that's the bug I fixed.

We do still warn on the testcase from the PR; I should add that to the
testcase I checked in.


Ah, good!  Thanks for clarifying!  Let me update the bug then
to reflect that.

Martin

Re: [committed 2/2] wwwdocs: Document my gcc 8 changes for the website (v2)

[Gerald Pfeifer]

On Wed, 4 Apr 2018, David Malcolm wrote:
> Yes, in the past I've added the bold/colorization markup by hand (ugh).
> Having a script to do this for our "screenshots" is a big time-saver.

I was afraid of that.  What you did here really is a great time
(and frustration) saver.  

And, of course, Python was part of the answer to my first review.
Why am I not surprised? :-)

Chapeau!
Gerald

Re: [wwwdocs] gcc-8/changes.html additions

[Gerald Pfeifer]

On Wed, 4 Apr 2018, Jakub Jelinek wrote:
> Following patch documents store merging improvements, 
> -fsanitize=builtin, -fsanitize=pointer-overflow and C++2A progress.

This is the week of release notes updates, it seems? :-)

> +The undefined behavior sanitizer gained two new options included in
> +-fsanitize=undefined: -fsanitize=builtin which
> +diagnoses at runtime invalid arguments to __builtin_clz or

I always end up looking it myself: codingconventions.html says to
use "run time" as the noun.

> +__builtin_ctz prefixed builtins, and
> +-fsanitize=pointer-overflow which performs cheap runtime
> +tests for pointer wrapping.

And that one as well.  (I think, unless we consider it an adjective
in which case it would be "run-time".)

> +For a full list of new features,
> +see https://gcc.gnu.org/projects/cxx-status.html#cxx2a";>the C++
> +status page.

For this page (changes.html) I _think_ relative links should work.


Okay with those changes (and the one I saw Martin suggest).  Thanks!

Gerald

Re: C++ PATCH for c++/84221, bogus -Wunused with unused attribute on template

[Jason Merrill]

On Wed, Apr 4, 2018 at 3:58 PM, Jason Merrill  wrote:
> On Wed, Apr 4, 2018 at 3:52 PM, Martin Sebor  wrote:
>> On 04/04/2018 01:04 PM, Jason Merrill wrote:
>>>
>>> For bugs 54372 and 60063, we changed attributes used and unused to be
>>> applied immediately in a template even if what they apply to is
>>> dependent, to avoid bogus warnings from
>>> maybe_warn_unused_local_typedefs.  But that's only an issue for
>>> TYPE_DECL, so we can use the normal logic for other things.
>>
>> In our discussion of attributes I thought we decided that explicit
>> specializations would not inherit attributes from the primary.
>> IIUC, this change does the opposite for class templates declared
>> unused so we end up with an inconsistency with function templates:
>
> I thought about that as well, tested with the explicit specialization
> removed, and found that still failed.  So that's the bug I fixed.
>
> We do still warn on the testcase from the PR; I should add that to the
> testcase I checked in.

Thus.
commit 2ddab1fb8b6b919ab8dc460efe96e1b114f90a2e
Author: Jason Merrill 
Date:   Wed Apr 4 15:58:11 2018 -0400

PR c++/84221
* g++.dg/warn/Wunused-var-32.C: Test explicit specialization.

diff --git a/gcc/testsuite/g++.dg/warn/Wunused-var-32.C b/gcc/testsuite/g++.dg/warn/Wunused-var-32.C
index 5558f9361fc..8aaf381ffa6 100644
--- a/gcc/testsuite/g++.dg/warn/Wunused-var-32.C
+++ b/gcc/testsuite/g++.dg/warn/Wunused-var-32.C
@@ -2,8 +2,10 @@
 // { dg-additional-options -Wunused }
 
 template  struct __attribute((unused)) A { };
+template <> struct A { };
 
 void f (void)
 {
   A a;   // shouldn't warn
+  A ac; // { dg-warning "unused" }
 }  

Re: C++ PATCH for c++/84221, bogus -Wunused with unused attribute on template

[Jason Merrill]

On Wed, Apr 4, 2018 at 3:52 PM, Martin Sebor  wrote:
> On 04/04/2018 01:04 PM, Jason Merrill wrote:
>>
>> For bugs 54372 and 60063, we changed attributes used and unused to be
>> applied immediately in a template even if what they apply to is
>> dependent, to avoid bogus warnings from
>> maybe_warn_unused_local_typedefs.  But that's only an issue for
>> TYPE_DECL, so we can use the normal logic for other things.
>
> In our discussion of attributes I thought we decided that explicit
> specializations would not inherit attributes from the primary.
> IIUC, this change does the opposite for class templates declared
> unused so we end up with an inconsistency with function templates:

I thought about that as well, tested with the explicit specialization
removed, and found that still failed.  So that's the bug I fixed.

We do still warn on the testcase from the PR; I should add that to the
testcase I checked in.

Jason

Re: [wwwdocs]Mention -ftree-loop-distribution

[Gerald Pfeifer]

On Wed, 4 Apr 2018, Bin.Cheng wrote:
> Thanks for the suggestions,  attachment is the updated change.

Ah, I thought (and would have been fine) you'd go ahead and commit
with those changes. ;-)

Yes, this is okay.  Thanks,
Gerald

Re: [PATCH 1/2] wwwdocs: Add bin/gcc-color-to-html.py

[Gerald Pfeifer]

On Wed, 4 Apr 2018, David Malcolm wrote:
> I've committed it to CVS, with the following changes:

Lovely, thank you!

Gerald

Re: C++ PATCH for c++/84221, bogus -Wunused with unused attribute on template

[Martin Sebor]

On 04/04/2018 01:04 PM, Jason Merrill wrote:

For bugs 54372 and 60063, we changed attributes used and unused to be
applied immediately in a template even if what they apply to is
dependent, to avoid bogus warnings from
maybe_warn_unused_local_typedefs.  But that's only an issue for
TYPE_DECL, so we can use the normal logic for other things.


In our discussion of attributes I thought we decided that explicit
specializations would not inherit attributes from the primary.
IIUC, this change does the opposite for class templates declared
unused so we end up with an inconsistency with function templates:

  namespace {

  template 
  [[gnu::unused]] void f ();

  template <>
  void f () { }

  template 
  struct [[gnu::unused]] A { };

  template <>
  struct A { };   // warning (expected)

  }

  void g ()
  {
A a;   // missing warning
  }

I would expect both to be treated consistently (i.e., same
as before your change).  I.e., I would think bug 84221 should
be resolved as invalid.)

Martin

PS This is also inconsistent in Clang and ICC, but differently
than in GCC.  Clang warns for the unused variable but not for
the unused function template specialization.  ICC doesn't warn
at all.

Re: [C++ PATCH] Fix __builtin_constant_p constexpr handling (PR inline-asm/85172)

[Jason Merrill]

OK.

On Wed, Apr 4, 2018 at 3:39 PM, Jakub Jelinek  wrote:
> Hi!
>
> As the following testcases show, potential_constant_expression_1 for some
> builtins returns true no matter what their arguments contain (intentionally
> so); the problem is that we call unconditionally
> cxx_eval_constant_expression on those arguments and that creates a loophole;
> normally potential_constant_expression_1 is a check what kind of expressions
> we allow in and cxx_eval* can only handle what we accept by that; through
> these builtins, anything else can appear there too.
> The following patch checks if the expression is potential constant
> expression before trying to call cxx_eval_constant_expression, but to avoid
> exponential compile time it checks it only for those builtins where
> potential_constant_expression_1 has not checked those arguments.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> 2018-04-04  Jakub Jelinek  
>
> PR inline-asm/85172
> * constexpr.c (cxx_eval_builtin_function_call): For calls to
> builtin_valid_in_constant_expr_p functions, don't call
> cxx_eval_constant_expression if argument is not
> potential_constant_expression.
>
> * g++.dg/ext/builtin13.C: New test.
> * g++.dg/ext/atomic-4.C: New test.
>
> --- gcc/cp/constexpr.c.jj   2018-04-03 23:39:16.535665285 +0200
> +++ gcc/cp/constexpr.c  2018-04-04 12:25:32.290813343 +0200
> @@ -1189,8 +1189,14 @@ cxx_eval_builtin_function_call (const co
>bool dummy1 = false, dummy2 = false;
>for (i = 0; i < nargs; ++i)
>  {
> -  args[i] = cxx_eval_constant_expression (&new_ctx, CALL_EXPR_ARG (t, i),
> - false, &dummy1, &dummy2);
> +  args[i] = CALL_EXPR_ARG (t, i);
> +  /* If builtin_valid_in_constant_expr_p is true,
> +potential_constant_expression_1 has not recursed into the arguments
> +of the builtin, verify it here.  */
> +  if (!builtin_valid_in_constant_expr_p (fun)
> + || potential_constant_expression (args[i]))
> +   args[i] = cxx_eval_constant_expression (&new_ctx, args[i], false,
> +   &dummy1, &dummy2);
>if (bi_const_p)
> /* For __built_in_constant_p, fold all expressions with constant 
> values
>even if they aren't C++ constant-expressions.  */
> --- gcc/testsuite/g++.dg/ext/builtin13.C.jj 2018-04-04 12:11:03.566767129 
> +0200
> +++ gcc/testsuite/g++.dg/ext/builtin13.C2018-04-04 12:11:34.380768131 
> +0200
> @@ -0,0 +1,9 @@
> +// PR inline-asm/85172
> +// { dg-do compile }
> +// { dg-options "" }
> +
> +int
> +foo ()
> +{
> +  return !__builtin_constant_p (({ __asm (""); 0; }));
> +}
> --- gcc/testsuite/g++.dg/ext/atomic-4.C.jj  2018-04-04 12:10:54.239766822 
> +0200
> +++ gcc/testsuite/g++.dg/ext/atomic-4.C 2018-04-04 12:11:56.058768833 +0200
> @@ -0,0 +1,9 @@
> +// PR inline-asm/85172
> +// { dg-do compile }
> +// { dg-options "" }
> +
> +int
> +foo (int *p)
> +{
> +  return !__atomic_always_lock_free (4, ({ __asm (""); p; }));
> +}
>
> Jakub

Re: [PATCH 1/2] wwwdocs: Add bin/gcc-color-to-html.py

[David Malcolm]

On Wed, 2018-04-04 at 21:01 +0200, Gerald Pfeifer wrote:
> On Wed, 4 Apr 2018, David Malcolm wrote:
> > Here's the new script I've been using for converting from 
> > diagnostic-color.c output to HTML spans that use gcc.css, 
> > via something like:
> > 
> > LANG=C gcc $@ -fdiagnostics-color=always 2>&1
> >   | ./bin/gcc-color-to-html.py
> > 
> > The script converts SGR_SEQ(COLOR_BOLD) to a
> >   
> > rather than
> >   
> > so that it can use
> >   
> > for all SGR_RESET, without needing to track the nesting.
> > 
> > OK to commit to the website (for reference)?
> 
> Oh, yes!
> 
> Really nice.  

Thanks.

> (You may want to identify yourself as the author, "Contributed by 
> David Malcolm, and would you like to contribute as "Copyright (C) 
> 2018 Free Software Foundation, Inc."?  Full GPL may be a bit of
> overkill, but of course also a good option.)

I've committed it to CVS, with the following changes:

 bin/gcc-color-to-html.py | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/bin/gcc-color-to-html.py b/bin/gcc-color-to-html.py
index 160d345..0d97ead 100755
--- a/bin/gcc-color-to-html.py
+++ b/bin/gcc-color-to-html.py
@@ -1,4 +1,23 @@
 #!/usr/bin/python3
+#
+# Copyright (C) 2018 Free Software Foundation, Inc.
+#
+# Contributed by David Malcolm
+#
+# GCC 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.
+#
+# GCC 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 GCC; see the file COPYING3.  If not see
+# .
+
 import html
 import re
 import sys
-- 
1.8.5.3

[C++ PATCH] Fix invalid structured binding range for parsing error recovery (PR c++/85194)

[Jakub Jelinek]

Hi!

The maybe_range_for_decl argument is documented on
cp_parser_simple_declaration as:
   If MAYBE_RANGE_FOR_DECL is not NULL, the pointed tree will be set to the
   parsed declaration if it is an uninitialized single declarator not followed
   by a `;', or to error_mark_node otherwise. Either way, the trailing `;',
   if present, will not be consumed.  */
but we initialize *maybe_range_for_decl to NULL_TREE at the beginning, to
detect if we saw more than one decl; in case of a structured binding, we
only set it to non-NULL on success and thus violate what the comment says,
and on testcase like below we return is_range_for from the callers because
it is followed by colon, yet range_decl is NULL and we ICE trying to
dereference it.  This patch ensures it is error_mark_node instead, it can
only happen in case of errors.

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

2018-04-04  Jakub Jelinek  

PR c++/85194
* parser.c (cp_parser_simple_declaration): For structured bindings,
if *maybe_range_for_decl is NULL after parsing it, set it to
error_mark_node.

* g++.dg/cpp1z/decomp37.C: New test.

--- gcc/cp/parser.c.jj  2018-04-03 18:05:26.0 +0200
+++ gcc/cp/parser.c 2018-04-04 14:59:53.562859572 +0200
@@ -12993,8 +12993,14 @@ cp_parser_simple_declaration (cp_parser*
/* The next token should be either a `,' or a `;'.  */
cp_token *token = cp_lexer_peek_token (parser->lexer);
/* If it's a `;', we are done.  */
-   if (token->type == CPP_SEMICOLON || maybe_range_for_decl)
+   if (token->type == CPP_SEMICOLON)
  goto finish;
+   else if (maybe_range_for_decl)
+ {
+   if (*maybe_range_for_decl == NULL_TREE)
+ *maybe_range_for_decl = error_mark_node;
+   goto finish;
+ }
/* Anything else is an error.  */
else
  {
--- gcc/testsuite/g++.dg/cpp1z/decomp37.C.jj2018-04-04 15:12:33.724191835 
+0200
+++ gcc/testsuite/g++.dg/cpp1z/decomp37.C   2018-04-04 15:13:40.803227382 
+0200
@@ -0,0 +1,14 @@
+// PR c++/85194
+// { dg-do compile { target c++11 } }
+// { dg-options "" }
+
+struct A { int i; };
+
+A x[2];
+
+void
+foo ()
+{
+  for (auto [i] = A () : x)// { dg-error "initializer in range-based 'for' 
loop" }
+;  // { dg-warning "structured bindings only 
available with" "" { target c++14_down } .-1 }
+}

Jakub

Re: [PATCH] Add -C when using -Wimplicit-fallthrough and --save-temps (PR preprocessor/78497).

[Marek Polacek]

On Tue, Apr 03, 2018 at 02:29:37PM +0200, Martin Liška wrote:
> Hi.
> 
> This helps the warning with --save-temps. Doing that one needs to preserve 
> comments
> in preprocessed source file.

Do we really want to only use -C when -Wimplicit-fallthrough is in effect?  I
mean, shouldn't we always use -C when -save-temps?

Marek

Re: [committed 2/2] wwwdocs: Document my gcc 8 changes for the website (v2)

[David Malcolm]

On Wed, 2018-04-04 at 21:02 +0200, Gerald Pfeifer wrote:
> On Wed, 4 Apr 2018, David Malcolm wrote:
> > I made this version using gcc-color-to-html.py from the previous
> > patch, 
> > to turn the SGR codes into spans for use with our gcc.css.
> 
> Nice.  Out of curiosity, did you do this manually in the past?

Yes, in the past I've added the bold/colorization markup by hand (ugh).
 Having a script to do this for our "screenshots" is a big time-saver.

Dave

Re: [PATCH, rtl] Fix PR84878: Segmentation fault in add_cross_iteration_register_deps

[Richard Biener]

On April 4, 2018 8:25:25 PM GMT+02:00, Peter Bergner  
wrote:
>On 4/4/18 10:43 AM, Peter Bergner wrote:
>> On 4/4/18 2:15 AM, Richard Biener wrote:
>>> On Tue, 3 Apr 2018, Peter Bergner wrote:
>>>
 On 4/3/18 1:40 PM, H.J. Lu wrote:
> On Tue, Apr 3, 2018 at 11:36 AM, Peter Bergner
> wrote:
>> gcc/testsuite/
>> PR rtl-optimization/84878
>> * gcc.dg/pr84878.c: New test.
>
> Wrong test filename.

 Ooops, thanks for spotting that!  Will fix.
>>>
>>> Patch is OK.
>> 
>> Ok, committed to trunk.  Thanks.
>> 
>> Nobody mentioned if this was a regression or not, so I did some
>testing
>> and it ICEs on GCC 7 but not on GCC 6.  Is it ok to back port to GCC
>7
>> assuming bootstrap and regtesting are clean?

Sure. 

>FYI, the GCC 7 bootstrap and regtesting completed with no regressions.
>
>Peter

C++ PATCH for c++/85006, concepts ICE with A return type

[Jason Merrill]

Here tsubst_pack_expansion assumes that we should have arguments for
all packs if we're not in a template, but we might not if there's an
auto pack.

Tested x86_64-pc-linux-gnu, applying to trunk.
commit 445cd04fd16f17dd499f2f7eb2ac8a723e9071a4
Author: Jason Merrill 
Date:   Wed Apr 4 14:53:08 2018 -0400

PR c++/85006 - -fconcepts ICE with A return type

* pt.c (tsubst_pack_expansion): Allow unsubstituted auto pack.

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 80670a4826b..dbbc7666721 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -11860,7 +11860,7 @@ tsubst_pack_expansion (tree t, tree args, tsubst_flags_t complain,
 	  /* We can't substitute for this parameter pack.  We use a flag as
 	 well as the missing_level counter because function parameter
 	 packs don't have a level.  */
-	  gcc_assert (processing_template_decl);
+	  gcc_assert (processing_template_decl || is_auto (parm_pack));
 	  unsubstituted_packs = true;
 	}
 }
diff --git a/gcc/testsuite/g++.dg/concepts/auto4.C b/gcc/testsuite/g++.dg/concepts/auto4.C
new file mode 100644
index 000..e80341ec038
--- /dev/null
+++ b/gcc/testsuite/g++.dg/concepts/auto4.C
@@ -0,0 +1,11 @@
+// PR c++/85006
+// { dg-additional-options "-std=c++17 -fconcepts" }
+
+template struct A {};
+
+template A foo() { return A{}; }
+
+void bar()
+{
+  foo();
+}

C++ PATCH for c++/84221, bogus -Wunused with unused attribute on template

[Jason Merrill]

For bugs 54372 and 60063, we changed attributes used and unused to be
applied immediately in a template even if what they apply to is
dependent, to avoid bogus warnings from
maybe_warn_unused_local_typedefs.  But that's only an issue for
TYPE_DECL, so we can use the normal logic for other things.

Tested x86_64-pc-linux-gnu, applying to trunk.
commit dac88137f97d9737fa2e0c5b27ec6431b2d29c7c
Author: Jason Merrill 
Date:   Wed Apr 4 13:43:26 2018 -0400

PR c++/84221 - bogus -Wunused with attribute and template.

* decl2.c (is_late_template_attribute): Handle unused and used
normally on non-TYPE_DECL.

diff --git a/gcc/cp/decl2.c b/gcc/cp/decl2.c
index 6ae6cef78dd..6078fb668a7 100644
--- a/gcc/cp/decl2.c
+++ b/gcc/cp/decl2.c
@@ -1145,10 +1145,11 @@ is_late_template_attribute (tree attr, tree decl)
   if (is_attribute_p ("weak", name))
 return true;
 
-  /* Attributes used and unused are applied directly, as they appertain to
- decls. */
-  if (is_attribute_p ("unused", name)
-  || is_attribute_p ("used", name))
+  /* Attributes used and unused are applied directly to typedefs for the
+ benefit of maybe_warn_unused_local_typedefs.  */
+  if (TREE_CODE (decl) == TYPE_DECL
+  && (is_attribute_p ("unused", name)
+	  || is_attribute_p ("used", name)))
 return false;
 
   /* Attribute tls_model wants to modify the symtab.  */
diff --git a/gcc/testsuite/g++.dg/warn/Wunused-var-32.C b/gcc/testsuite/g++.dg/warn/Wunused-var-32.C
new file mode 100644
index 000..5558f9361fc
--- /dev/null
+++ b/gcc/testsuite/g++.dg/warn/Wunused-var-32.C
@@ -0,0 +1,9 @@
+// PR c++/84221
+// { dg-additional-options -Wunused }
+
+template  struct __attribute((unused)) A { };
+
+void f (void)
+{
+  A a;   // shouldn't warn
+}  

Re: [committed 2/2] wwwdocs: Document my gcc 8 changes for the website (v2)

[Gerald Pfeifer]

On Wed, 4 Apr 2018, David Malcolm wrote:
> I made this version using gcc-color-to-html.py from the previous patch, 
> to turn the SGR codes into spans for use with our gcc.css.

Nice.  Out of curiosity, did you do this manually in the past?

Gerald

Re: [PATCH 1/2] wwwdocs: Add bin/gcc-color-to-html.py

[Gerald Pfeifer]

On Wed, 4 Apr 2018, David Malcolm wrote:
> Here's the new script I've been using for converting from 
> diagnostic-color.c output to HTML spans that use gcc.css, 
> via something like:
> 
> LANG=C gcc $@ -fdiagnostics-color=always 2>&1
>   | ./bin/gcc-color-to-html.py
> 
> The script converts SGR_SEQ(COLOR_BOLD) to a
>   
> rather than
>   
> so that it can use
>   
> for all SGR_RESET, without needing to track the nesting.
> 
> OK to commit to the website (for reference)?

Oh, yes!

Really nice.  

(You may want to identify yourself as the author, "Contributed by 
David Malcolm, and would you like to contribute as "Copyright (C) 
2018 Free Software Foundation, Inc."?  Full GPL may be a bit of
overkill, but of course also a good option.)

Gerald

C++ PATCH for c++/85200, ICE with constexpr if in generic lambda

[Jason Merrill]

Since, during partial instantiation of a generic lambda, we don't
substitute into the body of a constexpr if, we don't do lambda capture
as part of substitution.  But extract_locals_r is supposed to do it as
part of remembering the substitution context to be used later.

As it turns out, this was failing because walk_tree_1 expects the
DECL_INITIAL of a local variable to be walked in the context of the
BIND_EXPR, but we don't build BIND_EXPRs for compound-statements in a
template.  So in a template, let's walk the fields of a VAR_DECL from
its DECL_EXPR.

Tested x86_64-pc-linux-gnu, applying to trunk.
commit a99a47e6326b7278d660dcebba8ebcbec863f04a
Author: Jason Merrill 
Date:   Wed Apr 4 14:24:34 2018 -0400

PR c++/85200 - ICE with constexpr if in generic lambda.

* tree.c (cp_walk_subtrees): Walk into DECL_EXPR in templates.

diff --git a/gcc/cp/tree.c b/gcc/cp/tree.c
index 7ddc2cb5e2d..d0835cfaa29 100644
--- a/gcc/cp/tree.c
+++ b/gcc/cp/tree.c
@@ -4894,10 +4894,12 @@ cp_walk_subtrees (tree *tp, int *walk_subtrees_p, walk_tree_fn func,
   /* User variables should be mentioned in BIND_EXPR_VARS
 	 and their initializers and sizes walked when walking
 	 the containing BIND_EXPR.  Compiler temporaries are
-	 handled here.  */
+	 handled here.  And also normal variables in templates,
+	 since do_poplevel doesn't build a BIND_EXPR then.  */
   if (VAR_P (TREE_OPERAND (*tp, 0))
-	  && DECL_ARTIFICIAL (TREE_OPERAND (*tp, 0))
-	  && !TREE_STATIC (TREE_OPERAND (*tp, 0)))
+	  && (processing_template_decl
+	  || (DECL_ARTIFICIAL (TREE_OPERAND (*tp, 0))
+		  && !TREE_STATIC (TREE_OPERAND (*tp, 0)
 	{
 	  tree decl = TREE_OPERAND (*tp, 0);
 	  WALK_SUBTREE (DECL_INITIAL (decl));
diff --git a/gcc/testsuite/g++.dg/cpp1z/constexpr-if18.C b/gcc/testsuite/g++.dg/cpp1z/constexpr-if18.C
new file mode 100644
index 000..03ad620e8d9
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1z/constexpr-if18.C
@@ -0,0 +1,15 @@
+// PR c++/85200
+// { dg-additional-options -std=c++17 }
+
+template 
+void f(){
+  [](auto v, auto b){
+if constexpr (sizeof(v) == sizeof(int)) {
+	auto x = b;
+  }
+  }(0, 1);
+}
+
+int main(){
+  f();
+}

Re: [PATCH, rtl] Fix PR84878: Segmentation fault in add_cross_iteration_register_deps

[Peter Bergner]

On 4/4/18 10:43 AM, Peter Bergner wrote:
> On 4/4/18 2:15 AM, Richard Biener wrote:
>> On Tue, 3 Apr 2018, Peter Bergner wrote:
>>
>>> On 4/3/18 1:40 PM, H.J. Lu wrote:
 On Tue, Apr 3, 2018 at 11:36 AM, Peter Bergner  
 wrote:
> gcc/testsuite/
> PR rtl-optimization/84878
> * gcc.dg/pr84878.c: New test.

 Wrong test filename.
>>>
>>> Ooops, thanks for spotting that!  Will fix.
>>
>> Patch is OK.
> 
> Ok, committed to trunk.  Thanks.
> 
> Nobody mentioned if this was a regression or not, so I did some testing
> and it ICEs on GCC 7 but not on GCC 6.  Is it ok to back port to GCC 7
> assuming bootstrap and regtesting are clean?

FYI, the GCC 7 bootstrap and regtesting completed with no regressions.

Peter

[wwwdocs] gcc-8/changes.html additions

[Bernd Edlinger]

Hi,

this adds a few gcc command line options to gcc-8/changes.html which
I added for gcc-8.

I have validated as XHTML 1.0 Transitional.

Is it OK for wwwdocs?



Thanks
Bernd.
? patch-changes.diff
Index: htdocs/gcc-8/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-8/changes.html,v
retrieving revision 1.51
diff -u -r1.51 changes.html
--- htdocs/gcc-8/changes.html	3 Apr 2018 06:52:04 -	1.51
+++ htdocs/gcc-8/changes.html	4 Apr 2018 18:10:12 -
@@ -177,6 +177,29 @@
 	as if, else, while,
 	switch, or for.
   
+  
+	-Wcast-function-type warns when a function pointer
+	is cast to an incompatible function pointer.  This warning is enabled
+	by -Wextra.
+  
+  
+	-Wsizeof-pointer-div warns for suspicious divisions
+	of two sizeof expressions that divide the pointer size by the element
+	size, which is the usual way to compute the array size but won't work
+	out correctly with pointers.
+	This warning is enabled by -Wall.
+  
+  
+	-Wcast-align=strict warns whenever a pointer is cast
+	such that the required alignment of the target is increased.  For
+	example, warn if a char * is cast to an int *
+	regardless of the target machine.
+  
+  
+	-fprofile-abs-path create absolute path names in the
+	.gcno files.  This allows gcov to find the correct
+	sources in projects where compilations occur with different working directories.
+  
 
 -fno-strict-overflow is now mapped to
  -fwrapv -fwrapv-pointer and signed integer overflow

Re: [PATCH, testsuite, 2/2] Add scan-ltrans-tree-dump

[Bernhard Reutner-Fischer]

On 4 April 2018 at 10:59, Tom de Vries  wrote:
> On 04/03/2018 07:49 PM, Bernhard Reutner-Fischer wrote:
>>>
>>> This patch adds scan-ltrans-tree-dump.
>>
>>
>> Please check all error calls to talk about the correct function -- at
>> least scan-ltrans-tree-dump-times is wrong.
>>
>
> Hi,
>
> thanks for noticing that. I'll update the patches to fix that.
>
> But I wonder if it's not a better idea to get the function name using "info
> level", and to move the code that checks the number of arguments into a
> utility function, as done in the demonstrator patch below.

Right, good idea, that's even better IMHO.
As to where to load it, there are each */testsuite/config/default.exp
where you could load_lib something like a gcc/testsuite/lib/utils.exp

Oh, and there seem to be a min == max category of errors that want
e.g.  check_num_args 2 2 and in the min == max case want to emit
gcc/testsuite/lib/gcc-dg.exp:   error "dg-set-target-env-var: need two
arguments"
gcc/testsuite/lib/gcc-dg.exp:   error "dg-set-compiler-env-var: need
two arguments"

where i'd use the number of course.
Just a thought, though.

>
> Rainer, Mike, any comments? I can write a patch that uses check_num_args in
> testsuite/lib/*.exp (though I'm not yet sure where to move it such that it
> can be used everywhere).
>
> Thanks,
> - Tom

Re: [PATCH] c/55976 -Werror=return-type should error on returning a value from a void function

[Martin Sebor]

On 04/04/2018 11:15 AM, Jakub Jelinek wrote:

On Tue, Apr 03, 2018 at 01:36:13PM -0600, Martin Sebor wrote:

On 04/03/2018 10:26 AM, dave.pa...@oracle.com wrote:

This patch fixes handlng of -Werror=return-type. Currently, even with
the flag specified, return type errors remain warnings.

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

Function c_finish_return (), when calling pedwarn, should specifiy
OPT_Wreturn_type as the diagnostic index if warn_return_type is set so
that the given diagnostic is generated as an error, not a warning.

Patch was successfully bootstrapped and tested on x86_64-linux.


I would expect the option to control the warning consistently so
that when the test case is compiled with just -Wno-return-type
(and no other options) the warning is not issued.  But that's not
what happens because pedwarn() is called with a zero argument as
the option.


I think we need to make sure we error out even with -Wno-return-type
when -pedantic-errors.


That would seem surprising to me.  Is there an existing
precedent for this in GCC? (Any other warnings or options
that are treated this way?)

It would also diverge from Clang, which would be particularly
unhelpful to users of both compilers.  I would suggest to
follow what Clang does in terms of controlling the warning
(though not necessarily in its severity).  It's consistent
and intuitive.  (Clang has -Werror=return-type by default;
that may be overly strict.)

Martin


Especially when issues this pedwarn warns about are
very hard to debug show stoppers for anybody calling such functions in GCC 8
(because we turn such spots into __builtin_unreachable () and thus randomly
can execute completely unrelated code).  So, I think consistency isn't that
important here.

Jakub

[PATCH 1/2] wwwdocs: Add bin/gcc-color-to-html.py

[David Malcolm]

Here's the new script I've been using for converting from diagnostic-color.c
output to HTML spans that use gcc.css, via something like:

LANG=C gcc $@ -fdiagnostics-color=always 2>&1
  | ./bin/gcc-color-to-html.py

The script converts SGR_SEQ(COLOR_BOLD) to a
  
rather than
  
so that it can use
  
for all SGR_RESET, without needing to track the nesting.

OK to commit to the website (for reference)?

---
 bin/gcc-color-to-html.py | 98 
 1 file changed, 98 insertions(+)
 create mode 100755 bin/gcc-color-to-html.py

diff --git a/bin/gcc-color-to-html.py b/bin/gcc-color-to-html.py
new file mode 100755
index 000..160d345
--- /dev/null
+++ b/bin/gcc-color-to-html.py
@@ -0,0 +1,98 @@
+#!/usr/bin/python3
+import html
+import re
+import sys
+import unittest
+
+# Colors from gcc/color-macros.h:
+
+COLOR_SEPARATOR  = ";"
+COLOR_NONE   = "00"
+COLOR_BOLD   = "01"
+COLOR_UNDERSCORE = "04"
+COLOR_BLINK  = "05"
+COLOR_REVERSE= "07"
+COLOR_FG_BLACK   = "30"
+COLOR_FG_RED = "31"
+COLOR_FG_GREEN   = "32"
+COLOR_FG_YELLOW  = "33"
+COLOR_FG_BLUE= "34"
+COLOR_FG_MAGENTA = "35"
+COLOR_FG_CYAN= "36"
+COLOR_FG_WHITE   = "37"
+COLOR_BG_BLACK   = "40"
+COLOR_BG_RED = "41"
+COLOR_BG_GREEN   = "42"
+COLOR_BG_YELLOW  = "43"
+COLOR_BG_BLUE= "44"
+COLOR_BG_MAGENTA = "45"
+COLOR_BG_CYAN= "46"
+COLOR_BG_WHITE   = "47"
+
+SGR_START = "\33["
+SGR_END   = "m\33[K"
+
+def SGR_SEQ(str):
+return SGR_START + str + SGR_END
+
+SGR_RESET = SGR_SEQ("")
+
+def ansi_to_html(text):
+text = html.escape(text)
+pattern = ('(' + re.escape(SGR_START) + ')'
+   + '(.*?)'
+   + '(' + re.escape(SGR_END) + ')')
+while True:
+m = re.search(pattern, text)
+if not m:
+break
+sgr_seq = m.group(2)
+if sgr_seq == COLOR_BOLD:
+replacement = ''
+elif sgr_seq == COLOR_FG_RED:
+replacement = ''
+elif sgr_seq == COLOR_FG_GREEN:
+replacement = ''
+elif sgr_seq == COLOR_FG_BLUE:
+replacement = ''
+elif sgr_seq == '':
+replacement = ''
+elif sgr_seq == COLOR_BOLD + COLOR_SEPARATOR + COLOR_FG_RED:
+replacement = ''
+elif sgr_seq == COLOR_BOLD + COLOR_SEPARATOR + COLOR_FG_GREEN:
+replacement = ''
+elif sgr_seq == COLOR_BOLD + COLOR_SEPARATOR + COLOR_FG_CYAN:
+replacement = ''
+elif sgr_seq == COLOR_BOLD + COLOR_SEPARATOR + COLOR_FG_MAGENTA:
+replacement = ''
+else:
+raise ValueError('unknown SGR_SEQ code: %r' % sgr_seq)
+text = text[:m.start(1)] + replacement + text[m.end(3):]
+return text
+
+class AnsiToHtmlTests(unittest.TestCase):
+def assert_html(self, ansi_text, expected_html):
+html = ansi_to_html(ansi_text)
+self.assertMultiLineEqual(html, expected_html)
+
+def test_simple(self):
+self.assert_html('', '')
+self.assert_html('plain text', 'plain text')
+
+def test_filename(self):
+self.assert_html("\x1b[01m\x1b[Kfilename.c:\x1b[m\x1b[K In function 
'\x1b[01m\x1b[Ktest\x1b[m\x1b[K':\n",
+ 'filename.c: In function 
'test':\n')
+
+def test_error(self):
+self.assert_html("\x1b[01;31m\x1b[Kerror: 
\x1b[m\x1b[K'\x1b[01m\x1b[KNULL\x1b[m\x1b[K' undeclared",
+ 'error: 'NULL' undeclared')
+
+def test_escaping(self):
+self.assert_html("#include ", "#include ")
+
+if len(sys.argv) > 1:
+sys.exit(unittest.main())
+
+for line in sys.stdin:
+line = ansi_to_html(line)
+sys.stdout.write(line)
-- 
1.8.5.3

[committed 2/2] wwwdocs: Document my gcc 8 changes for the website (v2)

[David Malcolm]

This patch incorporates your review suggestions.
Successfully checked as XHTML 1.0 Transitional.
I've committed it to CVS.

I made this version using gcc-color-to-html.py from the previous patch, to
turn the SGR codes into spans for use with our gcc.css.

It adds various entries to the stylesheet to reflect the needs of
the examples.

---
 htdocs/gcc-8/changes.html | 263 +-
 htdocs/gcc.css|   5 +
 2 files changed, 267 insertions(+), 1 deletion(-)

diff --git a/htdocs/gcc-8/changes.html b/htdocs/gcc-8/changes.html
index 707cd4e..bc91156 100644
--- a/htdocs/gcc-8/changes.html
+++ b/htdocs/gcc-8/changes.html
@@ -183,11 +183,243 @@ a work-in-progress.
  is now undefined by default at all optimization levels.  Using
  -fsanitize=signed-integer-overflow is now the preferred
  way to audit code, -Wstrict-overflow is deprecated.
+When reporting mismatching argument types at a function call, the
+  C and C++ compilers now underline both the argument and the pertinent
+  parameter in the declaration.
+
+$ gcc arg-type-mismatch.cc
+arg-type-mismatch.cc: In function 'int caller(int, int, float)':
+arg-type-mismatch.cc:5:24: error: invalid conversion from 'int' to 'const 
char*' [-fpermissive]
+   return callee(first, second, third);
+^~
+arg-type-mismatch.cc:1:40: note:   initializing argument 2 of 'int callee(int, const char*, float)'
+ extern int callee(int one, const char *two, 
float three);
+^~~
+
+
+
+When reporting on unrecognized identifiers, the C and C++ compilers
+  will now emit fix-it hints suggesting #include directives
+  for various headers in the C and C++ standard libraries.
+
+$ gcc incomplete.c
+incomplete.c: In function 'test':
+incomplete.c:3:10: error: 
'NULL' undeclared (first use in this 
function)
+   return NULL;
+  ^~~~
+incomplete.c:3:10: note: 
'NULL' is defined in header 
''; did you forget to 
'#include '?
+incomplete.c:1:1:
++#include 
+ const char *test(void)
+incomplete.c:3:10:
+   return NULL;
+  ^~~~
+incomplete.c:3:10: note: 
each undeclared identifier is reported only once for each function it 
appears in
+
+
+
+$ gcc incomplete.cc
+incomplete.cc:1:6: error: 
'string' in namespace 'std' does not name a type
+ std::string s("hello world");
+  ^~
+incomplete.cc:1:1: note: 
'std::string' is defined in header 
''; did you forget to 
'#include '?
++#include 
+ std::string s("hello world");
+ ^~~
+
+
+
+The C and C++ compilers now use more intuitive locations when
+  reporting on missing semicolons, and offer fix-it hints:
+
+$ gcc t.c
+t.c: In function 'test':
+t.c:3:12: error: 
expected ';' before '}' token
+   return 42
+^
+;
+ }
+ ~
+
+
+
+When reporting on missing '}' and ')' tokens, the C and C++
+  compilers will now highlight the corresponding '{' and '(' token,
+  issuing a 'note' if it's on a separate line:
+
+$ gcc unclosed.c
+unclosed.c: In function 'log_when_out_of_range':
+unclosed.c:12:50: error: 
expected ')' before '{' token
+   && (temperature < MIN || temperature > MAX) {
+  ^~
+  )
+unclosed.c:11:6: note: 
to match this '('
+   if (logging_enabled && check_range ()
+  ^
+
+  or highlighting it directly if it's on the same line:
+
+$ gcc unclosed-2.c
+unclosed-2.c: In function 'test':
+unclosed-2.c:8:45: error: 
expected ')' before '{' token
+   if (temperature < MIN || temperature > 
MAX {
+  ~  ^~
+ )
+
+  They will also emit fix-it hints.
+
 
 
 C++
 
-  
+  When reporting on attempts to access private fields of a class or
+struct, the C++ compiler will now offer fix-it hints showing how to
+use an accessor function to get at the field in question, if one exists.
+
+$ gcc accessor.cc
+accessor.cc: In function 'void test(foo*)':
+accessor.cc:12:12: error: 
'double foo::m_ratio' is private 
within this context
+   if (ptr->m_ratio >= 0.5)
+^~~
+accessor.cc:7:10: note: 
declared private here
+   double m_ratio;
+  ^~~
+accessor.cc:12:12: note: 
field 'double foo::m_ratio' can be 
accessed via 'double foo::get_ratio() const'
+   if (ptr->m_ratio >= 0.5)
+^~~
+get_ratio()
+
+
+  
+  The C++ compiler can now give you a hint if you use a macro before it
+was defined (e.g. if you mess up the order of your #include
+directives):
+
+$ gcc ordering.cc
+ordering.cc:2:24: error: 
expected ';' at end of member 
declaration
+   virtual void clone() const OVERRIDE { }
+^
+ ;
+ordering.cc:2:30: error: 
'OVERRIDE' does not name a type
+   virtual void clone() const OVERRI

[PATCH 0/2] wwwdocs: Updates for gcc 8 changes (v2)

[David Malcolm]

On Mon, 2018-03-19 at 00:02 +0100, Gerald Pfeifer wrote:
> Hi David,
> 
> On Fri, 16 Mar 2018, David Malcolm wrote:
> > This patch kit is for the website; I generated it against a local
> > git mirror of the CVS repo.
> > 
> > It adds lots of examples of colorized output from GCC, which
> > I generated using ansi2html.sh, an LGPLv2 script for turning ANSI
> > color codes into HTML spans.  It also emits a .css file for mapping
> > the span classes into HTML colorization.
> 
> do we really need to import ansi2html.sh here?  It's only supposed
> to be used once, to generate the CSS file, I think, or do you expect
> to be further use?
> 
> As for the CSS, have you considered using more meaningful class names
> instead of those color codes (most of which aren't actually used in
> your patch to the website)?  I guess I'm really wondering about two
> things:
> 
>  (a) Can we only introduce those styles we actually use?, and
> 
>  (b) The question on class names.
> 
> (I can see that you possibly may want to keep the names as is, but
> in that case, could we prune and only keep what we use?)
> 
> Gerald

Thanks for the review.

I reworked things to avoid using ansi2html.sh and the new .css file

Instead, I wrote a Python 3 script (gcc-color-to-html.py) that "knows"
how to convert the various SGR codes used in GCC's diagnostic-color.c
into HTML spans that reuse our existing gcc.css.

I had to add a few entries to gcc.css to match diagnostic-color.c

Here's an updated version of the patches.

David Malcolm (2):
  Add bin/gcc-color-to-html.py
  Document my gcc 8 changes for the website (v2)

 bin/gcc-color-to-html.py  |  98 +
 htdocs/gcc-8/changes.html | 263 +-
 htdocs/gcc.css|   5 +
 3 files changed, 365 insertions(+), 1 deletion(-)
 create mode 100755 bin/gcc-color-to-html.py

-- 
1.8.5.3

Re: [PATCH] c/55976 -Werror=return-type should error on returning a value from a void function

[Jakub Jelinek]

On Tue, Apr 03, 2018 at 01:36:13PM -0600, Martin Sebor wrote:
> On 04/03/2018 10:26 AM, dave.pa...@oracle.com wrote:
> > This patch fixes handlng of -Werror=return-type. Currently, even with
> > the flag specified, return type errors remain warnings.
> > 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55976
> > 
> > Function c_finish_return (), when calling pedwarn, should specifiy
> > OPT_Wreturn_type as the diagnostic index if warn_return_type is set so
> > that the given diagnostic is generated as an error, not a warning.
> > 
> > Patch was successfully bootstrapped and tested on x86_64-linux.
> 
> I would expect the option to control the warning consistently so
> that when the test case is compiled with just -Wno-return-type
> (and no other options) the warning is not issued.  But that's not
> what happens because pedwarn() is called with a zero argument as
> the option.

I think we need to make sure we error out even with -Wno-return-type
when -pedantic-errors.  Especially when issues this pedwarn warns about are
very hard to debug show stoppers for anybody calling such functions in GCC 8
(because we turn such spots into __builtin_unreachable () and thus randomly
can execute completely unrelated code).  So, I think consistency isn't that
important here.

Jakub

Re: [PATCH 1/3] improve detection of attribute conflicts (PR 81544)

[Jakub Jelinek]

On Wed, Apr 04, 2018 at 06:51:00PM +0200, Andreas Krebbel wrote:
> > On targets enforcing a function alignment bigger than 4 bytes this triggers 
> > an error instead:
> > 
> > +inline int ATTR ((aligned (4)))
> > +finline_hot_noret_align (int);  /* { dg-warning "ignoring attribute 
> > .aligned \\(4\\). because it
> > conflicts with attribute .aligned \\(8\\)." } */
> > 
> > gcc/gcc/testsuite/c-c++-common/Wattributes.c:404:1: error: alignment for 
> > 'finline_hot_noret_align'
> > must be at least 8^M
> >
> 
> diff --git a/gcc/testsuite/c-c++-common/Wattributes.c 
> b/gcc/testsuite/c-c++-common/Wattributes.c
> index 902bcb61c30..a260d018dcf 100644
> --- a/gcc/testsuite/c-c++-common/Wattributes.c
> +++ b/gcc/testsuite/c-c++-common/Wattributes.c
> @@ -401,7 +401,8 @@ inline int ATTR ((warn_unused_result))
>  finline_hot_noret_align (int);  /* { dg-warning "ignoring attribute 
> .warn_unused_result. because it
> conflicts with attribute .noreturn." } */
> 
>  inline int ATTR ((aligned (4)))
> -finline_hot_noret_align (int);  /* { dg-warning "ignoring attribute .aligned 
> \\(4\\). because it
> conflicts with attribute .aligned \\(8\\)." } */
> +  finline_hot_noret_align (int);  /* { dg-warning "ignoring attribute 
> .aligned \\(4\\). because it
> conflicts with attribute .aligned \\(8\\)." "" { target { ! s390*-*-* } } } */
> +/* { dg-error "alignment for 'finline_hot_noret_align' must be at least 8" 
> "" { target s390*-*-* }
> .-1 } */
> 
>  inline int ATTR ((aligned (8)))
>  finline_hot_noret_align (int);
> 
> OK?

Wouldn't it be better to just use aligned (8) and aligned (16) instead of
aligned (4) and aligned (8)?

Jakub

New Ukrainian PO file for 'gcc' (version 8.1-b20180401)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'gcc' has been submitted
by the Ukrainian team of translators.  The file is available at:

http://translationproject.org/latest/gcc/uk.po

(This file, 'gcc-8.1-b20180401.uk.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

http://translationproject.org/latest/gcc/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

http://translationproject.org/domain/gcc.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

Re: [PATCH, GCC/ARM] Fix PR85203: cmse_nonsecure_caller returns wrong result

[Thomas Preudhomme]

Hi Kyrill,

On 04/04/18 18:19, Kyrill Tkachov wrote:

Hi Thomas,

On 04/04/18 18:03, Thomas Preudhomme wrote:

Hi,

__builtin_cmse_nonsecure_caller implementation returns true in almost
all cases due to 2 separate bugs:

* gen_addsi is used instead of gen_andsi to retrieve the lsb
* the lsb boolean value is not negated but the specification [1] says
   the intrinsic should return true for a nonsecure caller and a
   nonsecure caller is characterized with LR's lsb being 0

This was not caught due to (1) lack of runtime test and (2) the existing
RTL scan not taking into account that '.' matches newline in Tcl regular
expressions.

This patch fixes the implementation issues and improves testing of
cmse_nonsecure_caller by (1) adding a runtime test for the secure caller
case and (2) looking for an SET insn of an AND expression in the right
function. This leaves the nonsecure caller case only partly tested
since the exact value being AND and the negation are not covered by the
scan and the existing test infrastructure does not allow 2 separate
compilation and link to be performed. It is enough though to catch the
current incorrect behavior.

The patch also reorganize the scan directives in cmse-1.c to more easily
identify what function they are intended to test in the file.

ChangeLog entry is as follows:

*** gcc/ChangeLog ***

2018-04-04  Thomas Preud'homme 

    PR target/85203
    * config/arm/arm-builtins.c (arm_expand_builtin): Change
    expansion to perform a bitwise AND of the argument followed by a
    boolean negation of the result.

*** gcc/testsuite/ChangeLog ***

2018-04-04  Thomas Preud'homme 

    PR target/85203
    * gcc.target/arm/cmse/cmse-1.c: Tighten cmse_nonsecure_caller RTL scan
    to match a single insn of the baz function.  Move scan directives at
    the end of the file below the functions they are trying to test for
    better readability.
    * gcc.target/arm/cmse/cmse-16.c: New testcase.

Testing: No bootstrap since only M profile builtin code has been changed
but regression testing for arm-none-eabi targeting Arm Cortex-M23 and
Cortex-M33 shows no regression.

Is this ok for stage4?



Ok, thanks for fixing this.
Does this need backporting to the branches?


Yes to gcc-7-branch only.

Best regards,

Thomas

Re: [PATCH, GCC/ARM] Fix PR85203: cmse_nonsecure_caller returns wrong result

[Kyrill Tkachov]

Hi Thomas,

On 04/04/18 18:03, Thomas Preudhomme wrote:

Hi,

__builtin_cmse_nonsecure_caller implementation returns true in almost
all cases due to 2 separate bugs:

* gen_addsi is used instead of gen_andsi to retrieve the lsb
* the lsb boolean value is not negated but the specification [1] says
   the intrinsic should return true for a nonsecure caller and a
   nonsecure caller is characterized with LR's lsb being 0

This was not caught due to (1) lack of runtime test and (2) the existing
RTL scan not taking into account that '.' matches newline in Tcl regular
expressions.

This patch fixes the implementation issues and improves testing of
cmse_nonsecure_caller by (1) adding a runtime test for the secure caller
case and (2) looking for an SET insn of an AND expression in the right
function. This leaves the nonsecure caller case only partly tested
since the exact value being AND and the negation are not covered by the
scan and the existing test infrastructure does not allow 2 separate
compilation and link to be performed. It is enough though to catch the
current incorrect behavior.

The patch also reorganize the scan directives in cmse-1.c to more easily
identify what function they are intended to test in the file.

ChangeLog entry is as follows:

*** gcc/ChangeLog ***

2018-04-04  Thomas Preud'homme 

PR target/85203
* config/arm/arm-builtins.c (arm_expand_builtin): Change
expansion to perform a bitwise AND of the argument followed by a
boolean negation of the result.

*** gcc/testsuite/ChangeLog ***

2018-04-04  Thomas Preud'homme 

PR target/85203
* gcc.target/arm/cmse/cmse-1.c: Tighten cmse_nonsecure_caller RTL scan
to match a single insn of the baz function.  Move scan directives at
the end of the file below the functions they are trying to test for
better readability.
* gcc.target/arm/cmse/cmse-16.c: New testcase.

Testing: No bootstrap since only M profile builtin code has been changed
but regression testing for arm-none-eabi targeting Arm Cortex-M23 and
Cortex-M33 shows no regression.

Is this ok for stage4?



Ok, thanks for fixing this.
Does this need backporting to the branches?

Kyrill


Best regards,

Thomas

Re: [PATCH 1/3] improve detection of attribute conflicts (PR 81544)

[Martin Sebor]

On 04/04/2018 10:51 AM, Andreas Krebbel wrote:

On 04/04/2018 06:16 PM, Andreas Krebbel wrote:

On 10/03/2017 12:23 AM, Jeff Law wrote:

On 09/20/2017 12:04 PM, Martin Sebor wrote:

On 09/19/2017 03:00 PM, Joseph Myers wrote:

On Tue, 19 Sep 2017, Martin Sebor wrote:


In general, the data structures where you need to ensure manually that if

attribute A is listed in EXCL for B, then attribute B is also listed in
EXCL for A, seem concerning.  I'd expect either data structures that make

such asymmetry impossible, or a self-test that verifies that the tables in

use are in fact symmetric (unless there is some reason the symmetry is not

in fact required and symmetric diagnostics still result from asymmetric
tables - in which case the various combinations and orderings of
gnu_inline and noinline definitely need tests to show that the diagnostics

work).


If I understand correctly what you're concerned about then I don't
think there are any such cases in the updated version of the patch.


I don't see how you ensure that it's not possible to have such asymmetry.
My point wasn't so much "there was a bug in the previous patch version" as

"the choice of data structures for defining such exclusions is prone to
such bugs".  Which can be addressed either by using different data
structures (e.g. listing incompatible pairs in a single array) or by a
self-test to verify symmetry so a compiler with asymmetry doesn't build.


Okay, that's a useful thing to add.  It exposed a couple of missing
attribute exclusions that I had overlooked.  Thanks for the suggestion!
Attached is an incremental diff with just these changes to make review
easier and an updated patch.

As an aside, there are a number of other possible logic errors in
the attribute specifications that could be detected by self-tests.
The one I ran into is misspelled attribute names.  The added test
detects misspelled names in exclusions, but not in the main specs.

Martin

gcc-81544-1-inc.diff






gcc-81544-1.diff


PR c/81544 - attribute noreturn and warn_unused_result on the same function 
accepted

gcc/c/ChangeLog:

PR c/81544
* c-decl.c (c_decl_attributes): Look up existing declaration and
pass it to decl_attributes.

gcc/c-family/ChangeLog:

PR c/81544
* c-attribs.c (attr_aligned_exclusions): New array.
(attr_alloc_exclusions, attr_cold_hot_exclusions): Same.
(attr_common_exclusions, attr_const_pure_exclusions): Same.
(attr_gnu_inline_exclusions, attr_inline_exclusions): Same.
(attr_noreturn_exclusions, attr_returns_twice_exclusions): Same.
(attr_warn_unused_result_exclusions): Same.
(handle_hot_attribute, handle_cold_attribute): Simplify.
(handle_const_attribute): Warn on function returning void.
(handle_pure_attribute): Same.
* c-warn.c (diagnose_mismatched_attributes): Simplify.

gcc/ChangeLog:

PR c/81544
* attribs.c (empty_attribute_table): Initialize new member of
struct attribute_spec.
(decl_attributes): Add argument.  Handle mutually exclusive
combinations of attributes.
* attribs.h (decl_attributes): Add default argument.
* selftest.h (attribute_c_tests): Declare.
* selftest-run-tests.c (selftest::run_tests): Call attribute_c_tests.
* tree-core.h (attribute_spec::exclusions, exclude): New type and
member.
* doc/extend.texi (Common Function Attributes): Update const and pure.

gcc/testsuite/ChangeLog:

PR c/81544
* c-c++-common/Wattributes-2.c: New test.
* c-c++-common/Wattributes.c: New test.
* c-c++-common/attributes-3.c: Adjust.
* gcc.dg/attr-noinline.c: Adjust.
* gcc.dg/pr44964.c: Same.
* gcc.dg/torture/pr42363.c: Same.
* gcc.dg/tree-ssa/ssa-ccp-2.c: Same.

OK.
jeff



On targets enforcing a function alignment bigger than 4 bytes this triggers an 
error instead:

+inline int ATTR ((aligned (4)))
+finline_hot_noret_align (int);  /* { dg-warning "ignoring attribute .aligned 
\\(4\\). because it
conflicts with attribute .aligned \\(8\\)." } */

gcc/gcc/testsuite/c-c++-common/Wattributes.c:404:1: error: alignment for 
'finline_hot_noret_align'
must be at least 8^M



diff --git a/gcc/testsuite/c-c++-common/Wattributes.c 
b/gcc/testsuite/c-c++-common/Wattributes.c
index 902bcb61c30..a260d018dcf 100644
--- a/gcc/testsuite/c-c++-common/Wattributes.c
+++ b/gcc/testsuite/c-c++-common/Wattributes.c
@@ -401,7 +401,8 @@ inline int ATTR ((warn_unused_result))
 finline_hot_noret_align (int);  /* { dg-warning "ignoring attribute 
.warn_unused_result. because it
conflicts with attribute .noreturn." } */

 inline int ATTR ((aligned (4)))
-finline_hot_noret_align (int);  /* { dg-warning "ignoring attribute .aligned 
\\(4\\). because it
conflicts with attribute .aligned \\(8\\)." } */
+  finline_hot_noret_align (int);  /* { dg-warning "ignoring attribute .aligned 
\\(4\\). because it
conflicts with 

Re: [PATCH] Fix libbacktrace zdebug decompression on big endian (PR other/85161)

[Ian Lance Taylor]

On Tue, Apr 3, 2018 at 9:08 AM Jakub Jelinek  wrote:

> As mentioned in the PR, GCC (and clang) predefines
> {__BYTE_ORDER__,__ORDER_{LITTLE,BIG,PDP}_ENDIAN__}
> macros, and {,sys/,machine/}endian.h headers predefine
> {,__}{BYTE_ORDER,{LITTLE,BIG,PDP}_ENDIAN}
> macros (depending on which target and feature test macros).
> elf.c in GCC 8 used __BYTE_ORDER, which is endian.h macro, but
> didn't include that header and it on glibc just happened to be included
> indirectly because of default feature test macros from stdlib.h,
> and used non-existing __ORDER_BIG_ENDIAN macro; as __BYTE_ORDER is always
> non-zero when defined (1234, 4321 etc.), that means __builtin_bswap32
> was never used.

> The following patch just uses the GCC/clang predefined macros if known to
be
> big or little endian, and otherwise just falls back to portable code (that
> good compilers can still optimize).

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

> 2018-04-03  Jakub Jelinek  

>  PR other/85161
>  * elf.c (elf_zlib_fetch): Fix up predefined macro names in test
for
>  big endian, only use 32-bit loads if endianity macros are
predefined
>  and indicate big or little endian.

This is OK.  Thanks for sorting that out.

Ian

Re: [PATCH, GCC/ARM] Fix PR85203: cmse_nonsecure_caller returns wrong result

[Thomas Preudhomme]

Oops, forgot the link.

On 04/04/18 18:03, Thomas Preudhomme wrote:

Hi,

__builtin_cmse_nonsecure_caller implementation returns true in almost
all cases due to 2 separate bugs:

* gen_addsi is used instead of gen_andsi to retrieve the lsb
* the lsb boolean value is not negated but the specification [1] says
   the intrinsic should return true for a nonsecure caller and a
   nonsecure caller is characterized with LR's lsb being 0


[1] 
https://static.docs.arm.com/ecm0359818/10/ECM0359818_armv8m_security_extensions_reqs_on_dev_tools_1_0.pdf


Best regards,

Thomas



This was not caught due to (1) lack of runtime test and (2) the existing
RTL scan not taking into account that '.' matches newline in Tcl regular
expressions.

This patch fixes the implementation issues and improves testing of
cmse_nonsecure_caller by (1) adding a runtime test for the secure caller
case and (2) looking for an SET insn of an AND expression in the right
function. This leaves the nonsecure caller case only partly tested
since the exact value being AND and the negation are not covered by the
scan and the existing test infrastructure does not allow 2 separate
compilation and link to be performed. It is enough though to catch the
current incorrect behavior.

The patch also reorganize the scan directives in cmse-1.c to more easily
identify what function they are intended to test in the file.

ChangeLog entry is as follows:

*** gcc/ChangeLog ***

2018-04-04  Thomas Preud'homme  

 PR target/85203
 * config/arm/arm-builtins.c (arm_expand_builtin): Change
 expansion to perform a bitwise AND of the argument followed by a
 boolean negation of the result.

*** gcc/testsuite/ChangeLog ***

2018-04-04  Thomas Preud'homme  

 PR target/85203
 * gcc.target/arm/cmse/cmse-1.c: Tighten cmse_nonsecure_caller RTL scan
 to match a single insn of the baz function.  Move scan directives at
 the end of the file below the functions they are trying to test for
 better readability.
 * gcc.target/arm/cmse/cmse-16.c: New testcase.

Testing: No bootstrap since only M profile builtin code has been changed
but regression testing for arm-none-eabi targeting Arm Cortex-M23 and
Cortex-M33 shows no regression.

Is this ok for stage4?

Best regards,

Thomas

Re: [PATCH] c/55976 -Werror=return-type should error on returning a value from a void function

[dave . pagan]

Hi Martin,

Hadn't thought about, but you're right ... it should be consistent. 
Currently, -Wno-return-type has no effect on this warning, but it should.


Since this patch does fix the original problem, what do you recommend? 
Scrap this patch? Or let it proceed and submit a new bug noting the 
(existing) incorrect behavior of -Wno-return-type?


--Dave

On 04/03/2018 12:36 PM, Martin Sebor wrote:

On 04/03/2018 10:26 AM, dave.pa...@oracle.com wrote:

This patch fixes handlng of -Werror=return-type. Currently, even with
the flag specified, return type errors remain warnings.

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

Function c_finish_return (), when calling pedwarn, should specifiy
OPT_Wreturn_type as the diagnostic index if warn_return_type is set so
that the given diagnostic is generated as an error, not a warning.

Patch was successfully bootstrapped and tested on x86_64-linux.


I would expect the option to control the warning consistently so
that when the test case is compiled with just -Wno-return-type
(and no other options) the warning is not issued.  But that's not
what happens because pedwarn() is called with a zero argument as
the option.

Martin

[PATCH, GCC/ARM] Fix PR85203: cmse_nonsecure_caller returns wrong result

[Thomas Preudhomme]

Hi,

__builtin_cmse_nonsecure_caller implementation returns true in almost
all cases due to 2 separate bugs:

* gen_addsi is used instead of gen_andsi to retrieve the lsb
* the lsb boolean value is not negated but the specification [1] says
  the intrinsic should return true for a nonsecure caller and a
  nonsecure caller is characterized with LR's lsb being 0

This was not caught due to (1) lack of runtime test and (2) the existing
RTL scan not taking into account that '.' matches newline in Tcl regular
expressions.

This patch fixes the implementation issues and improves testing of
cmse_nonsecure_caller by (1) adding a runtime test for the secure caller
case and (2) looking for an SET insn of an AND expression in the right
function. This leaves the nonsecure caller case only partly tested
since the exact value being AND and the negation are not covered by the
scan and the existing test infrastructure does not allow 2 separate
compilation and link to be performed. It is enough though to catch the
current incorrect behavior.

The patch also reorganize the scan directives in cmse-1.c to more easily
identify what function they are intended to test in the file.

ChangeLog entry is as follows:

*** gcc/ChangeLog ***

2018-04-04  Thomas Preud'homme  

PR target/85203
* config/arm/arm-builtins.c (arm_expand_builtin): Change
expansion to perform a bitwise AND of the argument followed by a
boolean negation of the result.

*** gcc/testsuite/ChangeLog ***

2018-04-04  Thomas Preud'homme  

PR target/85203
* gcc.target/arm/cmse/cmse-1.c: Tighten cmse_nonsecure_caller RTL scan
to match a single insn of the baz function.  Move scan directives at
the end of the file below the functions they are trying to test for
better readability.
* gcc.target/arm/cmse/cmse-16.c: New testcase.

Testing: No bootstrap since only M profile builtin code has been changed
but regression testing for arm-none-eabi targeting Arm Cortex-M23 and
Cortex-M33 shows no regression.

Is this ok for stage4?

Best regards,

Thomas
diff --git a/gcc/config/arm/arm-builtins.c b/gcc/config/arm/arm-builtins.c
index 8940d1f6311bccf86664ab2eaa938735eec595f6..184eb2a934308717b6e1054e376487a297f8d5de 100644
--- a/gcc/config/arm/arm-builtins.c
+++ b/gcc/config/arm/arm-builtins.c
@@ -2600,7 +2600,9 @@ arm_expand_builtin (tree exp,
 case ARM_BUILTIN_CMSE_NONSECURE_CALLER:
   target = gen_reg_rtx (SImode);
   op0 = arm_return_addr (0, NULL_RTX);
-  emit_insn (gen_addsi3 (target, op0, const1_rtx));
+  emit_insn (gen_andsi3 (target, op0, const1_rtx));
+  op1 = gen_rtx_EQ (SImode, target, const0_rtx);
+  emit_insn (gen_cstoresi4 (target, op1, target, const0_rtx));
   return target;
 
 case ARM_BUILTIN_TEXTRMSB:
diff --git a/gcc/testsuite/gcc.target/arm/cmse/cmse-1.c b/gcc/testsuite/gcc.target/arm/cmse/cmse-1.c
index c13272eed683aa06db027cd4646e5fe67817212b..f764153cb17b796ccd0d20abb78d5cf56be52911 100644
--- a/gcc/testsuite/gcc.target/arm/cmse/cmse-1.c
+++ b/gcc/testsuite/gcc.target/arm/cmse/cmse-1.c
@@ -71,6 +71,20 @@ baz (void)
 {
   return cmse_nonsecure_caller ();
 }
+/* { dg-final { scan-assembler "baz:" } } */
+/* { dg-final { scan-assembler "__acle_se_baz:" } } */
+/* { dg-final { scan-assembler-not "\tcmse_nonsecure_caller" } } */
+/* Look for an andsi of 1 with a register in function baz, ie.
+
+;; Function baz
+
+(insn  (set (reg:SI )
+ (and:SI (reg:SI )
+	 (const_int 1 )
+   >
+(insn
+*/
+/* { dg-final { scan-rtl-dump "\n;; Function baz\[^\n\]*\[^(\]+\[^;\]*\n\\(insn \[^(\]+ \\(set \\(reg\[^:\]*:SI \[^)\]+\\)\[^(\]*\\(and:SI \\(reg\[^:\]*:SI \[^)\]+\\)\[^(\]*\\((const_int 1|reg\[^:\]*:SI) \[^)\]+\\)\[^(\]+(\\(nil\\)\[^(\]+)?\\(insn" expand } } */
 
 typedef int __attribute__ ((cmse_nonsecure_call)) (int_nsfunc_t) (void);
 
@@ -86,6 +100,11 @@ qux (int_nsfunc_t * callback)
 {
   fp = cmse_nsfptr_create (callback);
 }
+/* { dg-final { scan-assembler "qux:" } } */
+/* { dg-final { scan-assembler "__acle_se_qux:" } } */
+/* { dg-final { scan-assembler "bic" } } */
+/* { dg-final { scan-assembler "push\t\{r4, r5, r6" } } */
+/* { dg-final { scan-assembler "msr\tAPSR_nzcvq" } } */
 
 int call_callback (void)
 {
@@ -94,13 +113,4 @@ int call_callback (void)
   else
 return default_callback ();
 }
-/* { dg-final { scan-assembler "baz:" } } */
-/* { dg-final { scan-assembler "__acle_se_baz:" } } */
-/* { dg-final { scan-assembler "qux:" } } */
-/* { dg-final { scan-assembler "__acle_se_qux:" } } */
-/* { dg-final { scan-assembler-not "\tcmse_nonsecure_caller" } } */
-/* { dg-final { scan-rtl-dump "and.*reg.*const_int 1" expand } } */
-/* { dg-final { scan-assembler "bic" } } */
-/* { dg-final { scan-assembler "push\t\{r4, r5, r6" } } */
-/* { dg-final { scan-assembler "msr\tAPSR_nzcvq" } } */
 /* { dg-final { scan-assembler-times "bl\\s+__gnu_cmse_nonsecure_call" 1 } } */
diff --git a/gcc/testsuite/gcc.target/arm/cmse/cmse-16.c b/gcc/testsui

Re: [PATCH 1/3] improve detection of attribute conflicts (PR 81544)

[Andreas Krebbel]

On 04/04/2018 06:16 PM, Andreas Krebbel wrote:
> On 10/03/2017 12:23 AM, Jeff Law wrote:
>> On 09/20/2017 12:04 PM, Martin Sebor wrote:
>>> On 09/19/2017 03:00 PM, Joseph Myers wrote:
 On Tue, 19 Sep 2017, Martin Sebor wrote:

>> In general, the data structures where you need to ensure manually that if
>>
>> attribute A is listed in EXCL for B, then attribute B is also listed in
>> EXCL for A, seem concerning.  I'd expect either data structures that make
>>
>> such asymmetry impossible, or a self-test that verifies that the tables 
>> in
>>
>> use are in fact symmetric (unless there is some reason the symmetry is 
>> not
>>
>> in fact required and symmetric diagnostics still result from asymmetric
>> tables - in which case the various combinations and orderings of
>> gnu_inline and noinline definitely need tests to show that the 
>> diagnostics
>>
>> work).
>
> If I understand correctly what you're concerned about then I don't
> think there are any such cases in the updated version of the patch.

 I don't see how you ensure that it's not possible to have such asymmetry.
 My point wasn't so much "there was a bug in the previous patch version" as

 "the choice of data structures for defining such exclusions is prone to
 such bugs".  Which can be addressed either by using different data
 structures (e.g. listing incompatible pairs in a single array) or by a
 self-test to verify symmetry so a compiler with asymmetry doesn't build.
>>>
>>> Okay, that's a useful thing to add.  It exposed a couple of missing
>>> attribute exclusions that I had overlooked.  Thanks for the suggestion!
>>> Attached is an incremental diff with just these changes to make review
>>> easier and an updated patch.
>>>
>>> As an aside, there are a number of other possible logic errors in
>>> the attribute specifications that could be detected by self-tests.
>>> The one I ran into is misspelled attribute names.  The added test
>>> detects misspelled names in exclusions, but not in the main specs.
>>>
>>> Martin
>>>
>>> gcc-81544-1-inc.diff
>>>
>>>
>>
>>
>>> gcc-81544-1.diff
>>>
>>>
>>> PR c/81544 - attribute noreturn and warn_unused_result on the same function 
>>> accepted
>>>
>>> gcc/c/ChangeLog:
>>>
>>> PR c/81544
>>> * c-decl.c (c_decl_attributes): Look up existing declaration and
>>> pass it to decl_attributes.
>>>
>>> gcc/c-family/ChangeLog:
>>>
>>> PR c/81544
>>> * c-attribs.c (attr_aligned_exclusions): New array.
>>> (attr_alloc_exclusions, attr_cold_hot_exclusions): Same.
>>> (attr_common_exclusions, attr_const_pure_exclusions): Same.
>>> (attr_gnu_inline_exclusions, attr_inline_exclusions): Same.
>>> (attr_noreturn_exclusions, attr_returns_twice_exclusions): Same.
>>> (attr_warn_unused_result_exclusions): Same.
>>> (handle_hot_attribute, handle_cold_attribute): Simplify.
>>> (handle_const_attribute): Warn on function returning void.
>>> (handle_pure_attribute): Same.
>>> * c-warn.c (diagnose_mismatched_attributes): Simplify.
>>>
>>> gcc/ChangeLog:
>>>
>>> PR c/81544
>>> * attribs.c (empty_attribute_table): Initialize new member of
>>> struct attribute_spec.
>>> (decl_attributes): Add argument.  Handle mutually exclusive
>>> combinations of attributes.
>>> * attribs.h (decl_attributes): Add default argument.
>>> * selftest.h (attribute_c_tests): Declare.
>>> * selftest-run-tests.c (selftest::run_tests): Call attribute_c_tests.
>>> * tree-core.h (attribute_spec::exclusions, exclude): New type and
>>> member.
>>> * doc/extend.texi (Common Function Attributes): Update const and pure.
>>>
>>> gcc/testsuite/ChangeLog:
>>>
>>> PR c/81544
>>> * c-c++-common/Wattributes-2.c: New test.
>>> * c-c++-common/Wattributes.c: New test.
>>> * c-c++-common/attributes-3.c: Adjust.
>>> * gcc.dg/attr-noinline.c: Adjust.
>>> * gcc.dg/pr44964.c: Same.
>>> * gcc.dg/torture/pr42363.c: Same.
>>> * gcc.dg/tree-ssa/ssa-ccp-2.c: Same.
>> OK.
>> jeff
>>
> 
> On targets enforcing a function alignment bigger than 4 bytes this triggers 
> an error instead:
> 
> +inline int ATTR ((aligned (4)))
> +finline_hot_noret_align (int);  /* { dg-warning "ignoring attribute .aligned 
> \\(4\\). because it
> conflicts with attribute .aligned \\(8\\)." } */
> 
> gcc/gcc/testsuite/c-c++-common/Wattributes.c:404:1: error: alignment for 
> 'finline_hot_noret_align'
> must be at least 8^M
>

diff --git a/gcc/testsuite/c-c++-common/Wattributes.c 
b/gcc/testsuite/c-c++-common/Wattributes.c
index 902bcb61c30..a260d018dcf 100644
--- a/gcc/testsuite/c-c++-common/Wattributes.c
+++ b/gcc/testsuite/c-c++-common/Wattributes.c
@@ -401,7 +401,8 @@ inline int ATTR ((warn_unused_result))
 finline_hot_noret_align (int);  /* { dg-warning "ignoring attribute 
.warn_unused_result. because it
conflicts with attribute .noreturn." } */

 inline int ATTR

C++ PATCH for c++/85148, ICE with 'this' in array NSDMI

[Jason Merrill]

Here, when we're trying to find the matching object for a
PLACEHOLDER_EXPR, we need to look through ARRAY_REF.  Fixed by using
handled_component_p in the assert.

Tested x86_64-pc-linux-gnu, applying to trunk and 7.
commit 012c92312a0713370b54acaf3c9c7df3a03cae31
Author: Jason Merrill 
Date:   Tue Apr 3 15:21:30 2018 -0400

PR c++/85148 - ICE with 'this' in array NSDMI.

* tree.c (replace_placeholders_r): Use handled_component_p.

diff --git a/gcc/cp/tree.c b/gcc/cp/tree.c
index e75c88d6e8f..7ddc2cb5e2d 100644
--- a/gcc/cp/tree.c
+++ b/gcc/cp/tree.c
@@ -3145,7 +3145,7 @@ replace_placeholders_r (tree* t, int* walk_subtrees, void* data_)
 	for (; !same_type_ignoring_top_level_qualifiers_p (TREE_TYPE (*t),
 			   TREE_TYPE (x));
 	 x = TREE_OPERAND (x, 0))
-	  gcc_assert (TREE_CODE (x) == COMPONENT_REF);
+	  gcc_assert (handled_component_p (x));
 	*t = unshare_expr (x);
 	*walk_subtrees = false;
 	d->seen = true;
diff --git a/gcc/testsuite/g++.dg/cpp1y/nsdmi-aggr11.C b/gcc/testsuite/g++.dg/cpp1y/nsdmi-aggr11.C
new file mode 100644
index 000..09591df3807
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1y/nsdmi-aggr11.C
@@ -0,0 +1,12 @@
+// PR c++/85148
+// { dg-do compile { target c++14 } }
+
+template struct A
+{
+  T x[1]{(__PTRDIFF_TYPE__)this};
+};
+
+void foo()
+{
+  A> a{};
+}

C++ PATCH for c++/85141, ICE with compound assignment and static member function

[Jason Merrill]

Here the RHS has function type, so the stabilize_expr call in
cp_build_modify_expr was trying to generate a temporary of function
type, which is nonsensical.  Fixed by using decay_conversion instead
of rvalue, to turn it into a pointer.

Tested x86_64-pc-linux-gnu, applying to trunk.
commit 3a2cac966b15ae84a3ab54ee92ba54934ae70d4c
Author: Jason Merrill 
Date:   Tue Apr 3 15:34:32 2018 -0400

PR c++/85141 - ICE with compound assignment and static member fn.

* typeck.c (cp_build_modify_expr): Call decay_conversion for RHS of
compound assignment.

diff --git a/gcc/cp/typeck.c b/gcc/cp/typeck.c
index 2b7a771bbeb..e5ad54dbcd1 100644
--- a/gcc/cp/typeck.c
+++ b/gcc/cp/typeck.c
@@ -8083,7 +8083,7 @@ cp_build_modify_expr (location_t loc, tree lhs, enum tree_code modifycode,
 	 side effect associated with any single compound assignment
 	 operator. -- end note ]  */
 	  lhs = cp_stabilize_reference (lhs);
-	  rhs = rvalue (rhs);
+	  rhs = decay_conversion (rhs, complain);
 	  if (rhs == error_mark_node)
 	return error_mark_node;
 	  rhs = stabilize_expr (rhs, &init);
diff --git a/gcc/testsuite/g++.dg/expr/assign2.C b/gcc/testsuite/g++.dg/expr/assign2.C
new file mode 100644
index 000..759584af8d2
--- /dev/null
+++ b/gcc/testsuite/g++.dg/expr/assign2.C
@@ -0,0 +1,12 @@
+// PR c++/85141
+// { dg-options "-w -fpermissive" }
+
+struct A
+{
+  static int foo();
+};
+
+void bar(int i)
+{
+  i += A().foo;
+}
diff --git a/gcc/testsuite/g++.dg/parse/crash60.C b/gcc/testsuite/g++.dg/parse/crash60.C
index e515396771e..8e545a253c5 100644
--- a/gcc/testsuite/g++.dg/parse/crash60.C
+++ b/gcc/testsuite/g++.dg/parse/crash60.C
@@ -10,5 +10,5 @@ void foo()
   int result = 0;
   M m;
 
-  result += m.pop();  // { dg-error "invalid operands|in evaluation" }
+  result += m.pop();  // { dg-error "" }
 }

Re: [PATCH] [PR c++/84979] improve auto handling in explicit tmpl args for concepts

[Alexandre Oliva]

On Apr  4, 2018, Jason Merrill  wrote:

>> else
>> expr = lookup_template_function (expr, template_args);
>> +
>> +  /* We may be repeating a check already done during parsing, but
>> +if it was well-formed and passed then, it will pass again
>> +now, and if it didn't, we wouldn't have got here.  The case
>> +we want to catch is when we couldn't tell then, and can now,
>> +namely when templ prior to substitution was an
>> +identifier.  */
>> +  if (flag_concepts && check_auto_in_tmpl_args (expr, template_args))
>> +   return error_mark_node;

> I think we want this added code to go at the beginning of the block,

Uhh, it can't be too early, or we will still have an identifier, and
then the check function will just return.

> before we've wrapped the template in a TEMPLATE_ID_EXPR.  OK with that
> change.

Aah, maybe you mean the smaller block under 'if (is_template)', as in
the so-modified patch below?  Heh, yeah, lookup_template_function and
lookup_template_variable are very misleading function names!  They don't
perform any of the lookups I expected of them! ;-)

I'm testing this patch now, and if it passes I'll proceed to install it
under the assumption that this is what you approved.

Thanks!


[PR c++/84979] reject auto in explicit tmpl args for tmpl-fn

With concepts, we accept auto in explicit template arguments, but we
should only accept them for template classes.  Passing them to
template functions or variables is not allowed.  So, reject it, at
parse time if possible, at specialization time otherwise.


for  gcc/cp/ChangeLog

PR c++/84979
* pt.c (check_auto_in_tmpl_args): New.
(tsubst_qualified_id): Use it to reject template args
referencing auto for non-type templates.
* parser.c (cp_parser_template_id): Likewise.
* cp-tree.h (check_auto_in_tmpl_args): Declare.
* typeck2.c (build_functional_cast): Report correct location
for invalid use of auto.

for  gcc/testsuite/ChangeLog

PR c++/84979
* g++.dg/concepts/pr84979.C: New.
* g++.dg/concepts/pr84979-2.C: New.
* g++.dg/concepts/pr84979-3.C: New.
---
 gcc/cp/cp-tree.h  |1 +
 gcc/cp/parser.c   |   10 +-
 gcc/cp/pt.c   |   52 +
 gcc/cp/typeck2.c  |3 +-
 gcc/testsuite/g++.dg/concepts/pr84979-2.C |   41 +++
 gcc/testsuite/g++.dg/concepts/pr84979-3.C |   45 +
 gcc/testsuite/g++.dg/concepts/pr84979.C   |9 +
 7 files changed, 159 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/concepts/pr84979-2.C
 create mode 100644 gcc/testsuite/g++.dg/concepts/pr84979-3.C
 create mode 100644 gcc/testsuite/g++.dg/concepts/pr84979.C

diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index f7bacd08c8f8..c8f2b1696525 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -6500,6 +6500,7 @@ extern void maybe_show_extern_c_location (void);
 
 /* in pt.c */
 extern bool check_template_shadow  (tree);
+extern bool check_auto_in_tmpl_args (tree, tree);
 extern tree get_innermost_template_args(tree, int);
 extern void maybe_begin_member_template_processing (tree);
 extern void maybe_end_member_template_processing (void);
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index d526a4eb3652..af19f77acca3 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -15831,8 +15831,16 @@ cp_parser_template_id (cp_parser *parser,
   location_t combined_loc
 = make_location (token->location, token->location, finish_loc);
 
+  /* Check for concepts autos where they don't belong.  We could
+ identify types in some cases of idnetifier TEMPL, looking ahead
+ for a CPP_SCOPE, but that would buy us nothing: we accept auto in
+ types.  We reject them in functions, but if what we have is an
+ identifier, even with none_type we can't conclude it's NOT a
+ type, we have to wait for template substitution.  */
+  if (flag_concepts && check_auto_in_tmpl_args (templ, arguments))
+template_id = error_mark_node;
   /* Build a representation of the specialization.  */
-  if (identifier_p (templ))
+  else if (identifier_p (templ))
 template_id = build_min_nt_loc (combined_loc,
TEMPLATE_ID_EXPR,
templ, arguments);
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 80670a4826b6..4bc1f6e61e46 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -14903,6 +14903,15 @@ tsubst_qualified_id (tree qualified_id, tree args,
 
   if (is_template)
 {
+  /* We may be repeating a check already done during parsing, but
+if it was well-formed and passed then, it will pass again
+now, and if it didn't, we wouldn't have got here.  The case
+we want to catch is when we couldn't tell then, and can now,
+namely

C++ PATCH for c++/85118, wrong error with generic non-capturing lambda

[Jason Merrill]

Another problem caused by my change to consider template conversion
operators in calls to an object: in this case, the operator() is not a
viable candidate, so we try to use the conversion operator.  Which
ends up trying to instantiate the operator() to determine its return
type, which fails.

So, let's extend the 71117 fix and ignore the template conversion if
there are any call operator candidates, not just any viable ones.

Tested x86_64-pc-linux-gnu, applying to trunk.
commit 135b51494c6651a3c791941b6fabcbb1814a0942
Author: Jason Merrill 
Date:   Tue Apr 3 16:26:12 2018 -0400

PR c++/85118 - wrong error with generic lambda and std::bind.

* call.c (add_template_conv_candidate): Disable if there are any
call operators.

diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index 901f18c43e6..f81773157b6 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -3274,10 +3274,10 @@ add_template_conv_candidate (struct z_candidate **candidates, tree tmpl,
 			 tree return_type, tree access_path,
 			 tree conversion_path, tsubst_flags_t complain)
 {
-  /* Making this work broke PR 71117, so until the committee resolves core
- issue 2189, let's disable this candidate if there are any viable call
+  /* Making this work broke PR 71117 and 85118, so until the committee resolves
+ core issue 2189, let's disable this candidate if there are any call
  operators.  */
-  if (any_strictly_viable (*candidates))
+  if (*candidates)
 return NULL;
 
   return
diff --git a/gcc/testsuite/g++.dg/cpp1y/lambda-generic-variadic17.C b/gcc/testsuite/g++.dg/cpp1y/lambda-generic-variadic17.C
new file mode 100644
index 000..4a7392f93bc
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1y/lambda-generic-variadic17.C
@@ -0,0 +1,125 @@
+// PR c++/85118
+// { dg-do compile { target c++14 } }
+
+namespace std
+{
+  template
+struct remove_const
+{ typedef _Tp type; };
+
+  template
+struct remove_const<_Tp const>
+{ typedef _Tp type; };
+
+
+  template
+struct remove_volatile
+{ typedef _Tp type; };
+
+  template
+struct remove_volatile<_Tp volatile>
+{ typedef _Tp type; };
+
+
+  template
+struct remove_cv
+{
+  typedef typename
+  remove_const::type>::type type;
+};
+
+  template
+struct remove_reference
+{ typedef _Tp type; };
+
+  template
+struct remove_reference<_Tp&>
+{ typedef _Tp type; };
+
+  template
+struct remove_reference<_Tp&&>
+{ typedef _Tp type; };
+
+  template
+struct decay
+{
+  using type = typename remove_reference::type>::type;
+};
+
+  template
+_Tp&&
+declval() noexcept;
+
+  template
+constexpr _Tp&&
+forward(typename std::remove_reference<_Tp>::type& __t) noexcept
+{ return static_cast<_Tp&&>(__t); }
+
+
+  template
+struct _Mu
+{
+  template
+ _CVArg&&
+ operator()(_CVArg&& __arg, _Tuple&) const volatile
+ { return std::forward<_CVArg>(__arg); }
+};
+
+   template
+struct _Bind
+{
+  _Functor _M_f;
+  _Bound_args _M_bound_args;
+
+  template()(
+   _Mu<_Bound_args>()( std::declval<_Bound_args&>(),
+  std::declval<_Args&>() ) ) )>
+ _Result
+  operator()(_Args&& __args) { return {}; }
+
+  template()(
+   _Mu<_Bound_args>()( std::declval(),
+  std::declval<_Args&>() ) ) )>
+ _Result
+ operator()(_Args&& __args) volatile;
+
+};
+
+  template
+_Bind::type, typename decay<_BoundArgs>::type>
+bind(_Func&& __f, _BoundArgs&& __args)
+{
+  return {
+std::forward<_Func>(__f),
+  std::forward<_BoundArgs>(__args)
+  };
+}
+
+} // namespace std
+
+
+template 
+bool isOneOf(const T& )
+{
+return false;
+}
+
+template 
+bool isOneOf(const T& t, const FirstType& firstValue, const Tail&... tail)
+{
+return t == firstValue || isOneOf(t, tail...);
+}
+
+int main()
+{
+const auto isOneOfHelper = [](auto&&... params)
+{
+  return isOneOf(std::forward(params)...);
+};
+
+auto isO = std::bind(isOneOfHelper, 'o');
+
+isO('o');
+}

Re: [PATCH] [PR c++/85039] no type definitions in builtin offsetof

[Alexandre Oliva]

On Apr  4, 2018, Jason Merrill  wrote:

> On Tue, Apr 3, 2018 at 11:25 PM, Alexandre Oliva  wrote:
>> I still think we could attempt to retain the extension as it is, parsing
>> types introduced in data member initializers within the scope of the
>> class containing the data member, like we do, but, when the class is
>> already complete, recording it if not in TYPE_FIELDS, in some additional
>> field consulted for name mangling purposes and, in order to retain
>> compatibility, if the type is not a closure or anonymous, also recording
>> it in the enclosing namespace, so that it is found by lookup as in the
>> quoted snippet.
>> 
>> Is that a terrible idea?

> It sounds like a lot of work to support a very questionable pattern.

It's not so much work (the simple patch below does just that, and its
testing is almost done); I agree it's questionable, and it's limited (it
never worked in initializers of members of template classes, as the -4
testcase, so we don't have to worry about retaining temporary
compatibility with that), but it's there, so I think we'd be better off
deprecating it, if that's the direction we want to go.  The patch below
has just the right spot for a deprecation warning, even ;-)

We could recommend users to use a closure that returns the offsetof
instead of the unadorned offsetof.  That would work portably, but we
shouldn't make the transformation ourselves: it would change the
ABI-defined numbering of closure types.

> Perhaps we should just disallow defining a type in offsetof if the
> current scope is a class.

Even anonymous types?  I suspect this could break a lot of existing
code, with anonymous types hiding in macros.


Anyway, here's the patch.  I'm not quite proposing it for inclusion
(messing with TYPE_FIELDS directly was an experiment, and it worked, but
it could use some polishing ;-) but it shows it can be done without too
much trouble.  Presumably we'll want a deprecation notice in the patch
and in the tests.


[PR c++/85039] adjust context of new types in member initializers

Types defined in data member initializers of completed classes are
defined inconsistently: the context of the type and decl are set up so
that they seem to be members of the class containing the data member,
but the type decl is recorded in the enclosing namespace.

This is not a problem for named types, but anonymous types that have a
classtype as their context need to be able to find themselves in the
field list of the context type to be assigned an anon type count for
its mangled name.

This patch arranges for the context recorded in the type to match the
context in which its definition is introduced, namely that of the
class containing the data member, but preserving preexisting behavior
of making named types introduced in data member initializers visible
in the enclosing namespace.


for  gcc/cp/ChangeLog

PR c++/85039
* name-lookup.c (do_pushtag): Use correct context and scope
for types introduced in data member initializers of completed
classes, but retain visibility in enclosing namespace.

for  gcc/testsuite/ChangeLog

PR c++/85039
* g++.dg/pr85039-1.C: New.
* g++.dg/pr85039-2.C: New.
* g++.dg/pr85039-3.C: New.
* g++.dg/pr85039-4.C: New.
---
 gcc/cp/name-lookup.c |   30 --
 gcc/testsuite/g++.dg/pr85039-1.C |   17 +
 gcc/testsuite/g++.dg/pr85039-2.C |   10 ++
 gcc/testsuite/g++.dg/pr85039-3.C |   15 +++
 gcc/testsuite/g++.dg/pr85039-4.C |   12 
 5 files changed, 74 insertions(+), 10 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/pr85039-1.C
 create mode 100644 gcc/testsuite/g++.dg/pr85039-2.C
 create mode 100644 gcc/testsuite/g++.dg/pr85039-3.C
 create mode 100644 gcc/testsuite/g++.dg/pr85039-4.C

diff --git a/gcc/cp/name-lookup.c b/gcc/cp/name-lookup.c
index 9b5db3dc3aa7..02023b764324 100644
--- a/gcc/cp/name-lookup.c
+++ b/gcc/cp/name-lookup.c
@@ -6394,13 +6394,7 @@ do_pushtag (tree name, tree type, tag_scope scope)
view of the language.  */
 || (b->kind == sk_template_parms
 && (b->explicit_spec_p || scope == ts_global))
-|| (b->kind == sk_class
-&& (scope != ts_current
-/* We may be defining a new type in the initializer
-   of a static member variable. We allow this when
-   not pedantic, and it is particularly useful for
-   type punning via an anonymous union.  */
-|| COMPLETE_TYPE_P (b->this_entity
+|| (b->kind == sk_class && scope != ts_current))
 b = b->level_chain;
 
   gcc_assert (identifier_p (name));
@@ -6455,9 +6449,25 @@ do_pushtag (tree name, tree type, tag_scope scope)
{
  if (!TYPE_BEING_DEFINED (current_class_type)
  && !LAMBDA_TYPE_P (type))
-   return error_mark_node;
-
- if (!PROCESSING_REAL_TEMPLATE_DECL_P ())
+

Re: [PATCH 1/3] improve detection of attribute conflicts (PR 81544)

[Andreas Krebbel]

On 10/03/2017 12:23 AM, Jeff Law wrote:
> On 09/20/2017 12:04 PM, Martin Sebor wrote:
>> On 09/19/2017 03:00 PM, Joseph Myers wrote:
>>> On Tue, 19 Sep 2017, Martin Sebor wrote:
>>>
> In general, the data structures where you need to ensure manually that if
>
> attribute A is listed in EXCL for B, then attribute B is also listed in
> EXCL for A, seem concerning.  I'd expect either data structures that make
>
> such asymmetry impossible, or a self-test that verifies that the tables in
>
> use are in fact symmetric (unless there is some reason the symmetry is not
>
> in fact required and symmetric diagnostics still result from asymmetric
> tables - in which case the various combinations and orderings of
> gnu_inline and noinline definitely need tests to show that the diagnostics
>
> work).

 If I understand correctly what you're concerned about then I don't
 think there are any such cases in the updated version of the patch.
>>>
>>> I don't see how you ensure that it's not possible to have such asymmetry.
>>> My point wasn't so much "there was a bug in the previous patch version" as
>>>
>>> "the choice of data structures for defining such exclusions is prone to
>>> such bugs".  Which can be addressed either by using different data
>>> structures (e.g. listing incompatible pairs in a single array) or by a
>>> self-test to verify symmetry so a compiler with asymmetry doesn't build.
>>
>> Okay, that's a useful thing to add.  It exposed a couple of missing
>> attribute exclusions that I had overlooked.  Thanks for the suggestion!
>> Attached is an incremental diff with just these changes to make review
>> easier and an updated patch.
>>
>> As an aside, there are a number of other possible logic errors in
>> the attribute specifications that could be detected by self-tests.
>> The one I ran into is misspelled attribute names.  The added test
>> detects misspelled names in exclusions, but not in the main specs.
>>
>> Martin
>>
>> gcc-81544-1-inc.diff
>>
>>
> 
> 
>> gcc-81544-1.diff
>>
>>
>> PR c/81544 - attribute noreturn and warn_unused_result on the same function 
>> accepted
>>
>> gcc/c/ChangeLog:
>>
>>  PR c/81544
>>  * c-decl.c (c_decl_attributes): Look up existing declaration and
>>  pass it to decl_attributes.
>>
>> gcc/c-family/ChangeLog:
>>
>>  PR c/81544
>>  * c-attribs.c (attr_aligned_exclusions): New array.
>>  (attr_alloc_exclusions, attr_cold_hot_exclusions): Same.
>>  (attr_common_exclusions, attr_const_pure_exclusions): Same.
>>  (attr_gnu_inline_exclusions, attr_inline_exclusions): Same.
>>  (attr_noreturn_exclusions, attr_returns_twice_exclusions): Same.
>>  (attr_warn_unused_result_exclusions): Same.
>>  (handle_hot_attribute, handle_cold_attribute): Simplify.
>>  (handle_const_attribute): Warn on function returning void.
>>  (handle_pure_attribute): Same.
>>  * c-warn.c (diagnose_mismatched_attributes): Simplify.
>>
>> gcc/ChangeLog:
>>
>>  PR c/81544
>>  * attribs.c (empty_attribute_table): Initialize new member of
>>  struct attribute_spec.
>>  (decl_attributes): Add argument.  Handle mutually exclusive
>>  combinations of attributes.
>>  * attribs.h (decl_attributes): Add default argument.
>>  * selftest.h (attribute_c_tests): Declare.
>>  * selftest-run-tests.c (selftest::run_tests): Call attribute_c_tests.
>>  * tree-core.h (attribute_spec::exclusions, exclude): New type and
>>  member.
>>  * doc/extend.texi (Common Function Attributes): Update const and pure.
>>
>> gcc/testsuite/ChangeLog:
>>
>>  PR c/81544
>>  * c-c++-common/Wattributes-2.c: New test.
>>  * c-c++-common/Wattributes.c: New test.
>>  * c-c++-common/attributes-3.c: Adjust.
>>  * gcc.dg/attr-noinline.c: Adjust.
>>  * gcc.dg/pr44964.c: Same.
>>  * gcc.dg/torture/pr42363.c: Same.
>>  * gcc.dg/tree-ssa/ssa-ccp-2.c: Same.
> OK.
> jeff
> 

On targets enforcing a function alignment bigger than 4 bytes this triggers an 
error instead:

+inline int ATTR ((aligned (4)))
+finline_hot_noret_align (int);  /* { dg-warning "ignoring attribute .aligned 
\\(4\\). because it
conflicts with attribute .aligned \\(8\\)." } */

gcc/gcc/testsuite/c-c++-common/Wattributes.c:404:1: error: alignment for 
'finline_hot_noret_align'
must be at least 8^M

Re: [wwwdocs] gcc-8/changes.html additions

[Martin Sebor]

On 04/04/2018 01:43 AM, Jakub Jelinek wrote:

Hi!

Following patch documents store merging improvements, -fsanitize=builtin,
-fsanitize=pointer-overflow and C++2A progress.

Ok for wwwdocs?

--- changes.html3 Apr 2018 06:52:04 -   1.51
+++ changes.html4 Apr 2018 07:41:06 -
@@ -113,6 +113,21 @@ a work-in-progress.
 possible for the user to have a finer-grained control over the loop
 unrolling optimization.
   
+  
+The store merging pass has been enhanced to handle bitfields and not


Just a minor nit: I believe the established spelling is bit-fields
(as you used in the last hunk below).

Martin



+just constant stores, but also data copying from adjacent memory
+locations into other adjacent memory locations, including bitwise
+logical operations on the data.  The pass can also handle byte swapping
+into memory locations.
+  
+  
+The undefined behavior sanitizer gained two new options included in
+-fsanitize=undefined: -fsanitize=builtin which
+diagnoses at runtime invalid arguments to __builtin_clz or
+__builtin_ctz prefixed builtins, and
+-fsanitize=pointer-overflow which performs cheap runtime
+tests for pointer wrapping.
+  
 


@@ -187,7 +202,17 @@ a work-in-progress.

 C++
 
-  
+  
+The C++ front end has experimental support for some of the upcoming C++2a
+draft features with the -std=c++2a or 
-std=gnu++2a
+flags, including designated initializers, default member initializers for
+bit-fields, __VA_OPT__ (except that
+#__VA_OPT__ is unsupported), lambda [=, this]
+captures, etc.
+For a full list of new features,
+see https://gcc.gnu.org/projects/cxx-status.html#cxx2a";>the C++
+status page.
+  
 

 Fortran

Jakub

Re: [PATCH, rtl] Fix PR84878: Segmentation fault in add_cross_iteration_register_deps

[Peter Bergner]

On 4/4/18 2:15 AM, Richard Biener wrote:
> On Tue, 3 Apr 2018, Peter Bergner wrote:
> 
>> On 4/3/18 1:40 PM, H.J. Lu wrote:
>>> On Tue, Apr 3, 2018 at 11:36 AM, Peter Bergner  wrote:
 gcc/testsuite/
 PR rtl-optimization/84878
 * gcc.dg/pr84878.c: New test.
>>>
>>> Wrong test filename.
>>
>> Ooops, thanks for spotting that!  Will fix.
> 
> Patch is OK.

Ok, committed to trunk.  Thanks.

Nobody mentioned if this was a regression or not, so I did some testing
and it ICEs on GCC 7 but not on GCC 6.  Is it ok to back port to GCC 7
assuming bootstrap and regtesting are clean?

Peter

C++ PATCH for c++/85133, ICE with missing concept initializer

[Jason Merrill]

Making the concept always satisfied seems good for error recovery.

Tested x86_64-pc-linux-gnu, applying to trunk.
commit c2e6a2a7e163f285891620e64144b45e1418870a
Author: Jason Merrill 
Date:   Tue Apr 3 16:40:02 2018 -0400

PR c++/85133 - ICE with missing concept initializer.

* decl.c (cp_finish_decl): If a concept initializer is missing, use
true.

diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index 6ddbe2343f4..c8309979a4d 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -7010,7 +7010,10 @@ cp_finish_decl (tree decl, tree init, bool init_const_expr_p,
   if (!VAR_P (decl) || type_dependent_p)
 	/* We can't do anything if the decl has dependent type.  */;
   else if (!init && is_concept_var (decl))
-error ("variable concept has no initializer");
+	{
+	  error ("variable concept has no initializer");
+	  init = boolean_true_node;
+	}
   else if (init
 	   && init_const_expr_p
 	   && TREE_CODE (type) != REFERENCE_TYPE
diff --git a/gcc/testsuite/g++.dg/concepts/var-concept7.C b/gcc/testsuite/g++.dg/concepts/var-concept7.C
new file mode 100644
index 000..0df4a498a0d
--- /dev/null
+++ b/gcc/testsuite/g++.dg/concepts/var-concept7.C
@@ -0,0 +1,8 @@
+// PR c++/85133
+// { dg-additional-options "-std=c++17 -fconcepts" }
+
+template concept bool C; // { dg-error "no initializer" }
+
+template struct A {};
+
+A a;

[PATCH v2, rs6000] Tidy implementation of vec_ldl

[Kelvin Nilsen]

This is a second draft of a draft patch originally submitted on 3/29.  
This patch corrects inconsistencies in the supported prototypes for the 
vec_ldl built-in function.  Specifically, it removes support for:



  vector int vec_ldl (int, long int *)
  vector unsigned int vec_ldl (int, unsigned long int *)

and adds support for:

  vector bool char vec_ldl (int, bool char *)
  vector bool short vec_ldl (int, bool short *)
  vector bool int vec_ldl (int, bool int *)
  vector bool long long vec_ldl (int, bool long long *)
  vector long long vec_ldl (int, long long *)
  vector unsigned long long vec_ldl (int, unsigned long long *)

Thanks to Segher Boessenkool for his careful review and feedback on the 
first draft of this patch.  This second revision differs from the first 
in the following:


1. Removed support for the proposed new prototype: "vector pixel vec_ldl 
(int, pixel *)"


2. Removed an extraneous tab character in the ChangeLog.

3. Changed the mangling of the bool_long_long_type_node.

4. Removed leading * on comment continuation lines.

5. Added a comment to describe limitations on use of the pixel data type.

6. Removed requirement for lp64 on the new test program.


This patch has bootstrapped and tested without regressions on both 
powerpc64le-unknown-linux (P8) and on powerpc-linux (P7 big-endian, with 
both -m32 and -m64 target options).


Is this ok for trunk?

gcc/ChangeLog:

2018-04-03  Kelvin Nilsen  

    * config/rs6000/rs6000-c.c (altivec_overloaded_builtins): Remove
    erroneous entries for
    "vector int vec_ldl (int, long int *)", and
    "vector unsigned int vec_ldl (int, unsigned long int *)".
    Add comments and entries for
    "vector bool char vec_ldl (int, bool char *)",
    "vector bool short vec_ldl (int, bool short *)",
    "vector bool int vec_ldl (int, bool int *)",
    "vector bool long long vec_ldl (int, bool long long *)",
    "vector pixel vec_ldl (int, pixel *)",
    "vector long long vec_ldl (int, long long *)",
    "vector unsigned long long vec_ldl (int, unsigned long long *)".
    * config/rs6000/rs6000.c (rs6000_init_builtins): Initialize new
    type tree bool_long_long_type_node and correct definition of
    bool_V2DI_type_node to make reference to this new type tree.
    (rs6000_mangle_type): Replace erroneous reference to
    bool_long_type_node with bool_long_long_type_node.
    * config/rs6000/rs6000.h (enum rs6000_builtin_type_index): Add
    comments to emphasize sign distinctions for char and int types and
    replace RS6000_BTI_bool_long constant with
    RS6000_BTI_bool_long_long constant.  Also add comment to restrict
    use of RS6000_BTI_pixel.
    (bool_long_type_node): Remove this macro definition.
    (bool_long_long_type_node): New macro definition

gcc/testsuite/ChangeLog:

2018-04-03  Kelvin Nilsen  

    * gcc.target/powerpc/vec-ldl-1.c: New test.
    * gcc.dg/vmx/ops-long-1.c: Correct test programs to reflect
    corrections to ABI implementation.

Index: gcc/config/rs6000/rs6000-c.c
===
--- gcc/config/rs6000/rs6000-c.c    (revision 258800)
+++ gcc/config/rs6000/rs6000-c.c    (working copy)
@@ -1656,27 +1656,45 @@ const struct altivec_builtin_types altivec_overloa
 RS6000_BTI_V16QI, RS6000_BTI_INTSI, ~RS6000_BTI_INTQI, 0 },
   { ALTIVEC_BUILTIN_VEC_LVEBX, ALTIVEC_BUILTIN_LVEBX,
 RS6000_BTI_unsigned_V16QI, RS6000_BTI_INTSI, ~RS6000_BTI_UINTQI, 0 },
+
+  /* vector float vec_ldl (int, vector float *);
+ vector float vec_ldl (int, float *); */
   { ALTIVEC_BUILTIN_VEC_LDL, ALTIVEC_BUILTIN_LVXL_V4SF,
 RS6000_BTI_V4SF, RS6000_BTI_INTSI, ~RS6000_BTI_V4SF, 0 },
   { ALTIVEC_BUILTIN_VEC_LDL, ALTIVEC_BUILTIN_LVXL_V4SF,
 RS6000_BTI_V4SF, RS6000_BTI_INTSI, ~RS6000_BTI_float, 0 },
+
+  /* vector bool int vec_ldl (int, vector bool int *);
+ vector bool int vec_ldl (int, bool int *);
+  vector int vec_ldl (int, vector int *);
+  vector int vec_ldl (int, int *);
+ vector unsigned int vec_ldl (int, vector unsigned int *);
+ vector unsigned int vec_ldl (int, unsigned int *); */
   { ALTIVEC_BUILTIN_VEC_LDL, ALTIVEC_BUILTIN_LVXL_V4SI,
 RS6000_BTI_bool_V4SI, RS6000_BTI_INTSI, ~RS6000_BTI_bool_V4SI, 0 },
   { ALTIVEC_BUILTIN_VEC_LDL, ALTIVEC_BUILTIN_LVXL_V4SI,
+    RS6000_BTI_bool_V4SI, RS6000_BTI_INTSI, ~RS6000_BTI_bool_int, 0 },
+  { ALTIVEC_BUILTIN_VEC_LDL, ALTIVEC_BUILTIN_LVXL_V4SI,
 RS6000_BTI_V4SI, RS6000_BTI_INTSI, ~RS6000_BTI_V4SI, 0 },
   { ALTIVEC_BUILTIN_VEC_LDL, ALTIVEC_BUILTIN_LVXL_V4SI,
 RS6000_BTI_V4SI, RS6000_BTI_INTSI, ~RS6000_BTI_INTSI, 0 },
   { ALTIVEC_BUILTIN_VEC_LDL, ALTIVEC_BUILTIN_LVXL_V4SI,
-    RS6000_BTI_V4SI, RS6000_BTI_INTSI, ~RS6000_BTI_long, 0 },
-  { ALTIVEC_BUILTIN_VEC_LDL, ALTIVEC_BUILTIN_LVXL_V4SI,
 RS6000_BTI_unsigned_V4SI, RS6000_BTI_INTSI, 
~RS6000_BTI_unsigned_V4SI, 0 },

   { ALTIVEC_BUILTIN_VEC_LDL, ALTIVEC_BUILTIN_LVXL_V4SI,
 RS6000_BTI_unsigned_V4SI, RS6000_B

C++ PATCH for c++/85135, ICE with omitted template arguments

[Jason Merrill]

A deduced class type can't appear in a function return type; we
already check for that in a leading return type, but we weren't
checking in a trailing return type.  This fixes that, and return
error_mark_node.

Tested x86_64-pc-linux-gnu, applying to trunk.
commit d39ccab0e8762fc4d1dd03e079e2c4cf925337d7
Author: Jason Merrill 
Date:   Tue Apr 3 17:03:29 2018 -0400

PR c++/85135 - ICE with omitted template arguments.

* decl.c (grokdeclarator): Catch deduced class type in trailing
return type.

diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index c8309979a4d..dca903d9b68 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -11093,20 +11093,29 @@ grokdeclarator (const cp_declarator *declarator,
 			   name, type);
 			return error_mark_node;
 		  }
-		if (tree tmpl = CLASS_PLACEHOLDER_TEMPLATE (auto_node))
+		tree tmpl = CLASS_PLACEHOLDER_TEMPLATE (auto_node);
+		if (!tmpl)
+		  if (tree late_auto = type_uses_auto (late_return_type))
+			tmpl = CLASS_PLACEHOLDER_TEMPLATE (late_auto);
+		if (tmpl)
 		  {
-			if (!late_return_type)
+			if (!dguide_name_p (unqualified_id))
 			  {
-			if (dguide_name_p (unqualified_id))
-			  error_at (declarator->id_loc, "deduction guide "
-	"for %qT must have trailing return "
-	"type", TREE_TYPE (tmpl));
-			else
-			  error_at (declarator->id_loc, "deduced class "
-	"type %qT in function return type",
-	type);
+			error_at (declarator->id_loc, "deduced class "
+  "type %qD in function return type",
+  DECL_NAME (tmpl));
 			inform (DECL_SOURCE_LOCATION (tmpl),
 "%qD declared here", tmpl);
+			return error_mark_node;
+			  }
+			else if (!late_return_type)
+			  {
+			error_at (declarator->id_loc, "deduction guide "
+  "for %qT must have trailing return "
+  "type", TREE_TYPE (tmpl));
+			inform (DECL_SOURCE_LOCATION (tmpl),
+"%qD declared here", tmpl);
+			return error_mark_node;
 			  }
 			else if (CLASS_TYPE_P (late_return_type)
  && CLASSTYPE_TEMPLATE_INFO (late_return_type)
diff --git a/gcc/testsuite/g++.dg/cpp1z/class-deduction53.C b/gcc/testsuite/g++.dg/cpp1z/class-deduction53.C
new file mode 100644
index 000..6025dc47cf5
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1z/class-deduction53.C
@@ -0,0 +1,10 @@
+// PR c++/85135
+// { dg-do compile { target c++11 } }
+
+template struct A {};
+
+auto foo() -> A;		// { dg-error "A" }
+
+template struct B {};
+
+auto foo() -> A;		// { dg-error "A" }

Re: Fix -Wstringop-overflow regression

[Michael Matz]

Hi,

On Wed, 4 Apr 2018, Richard Biener wrote:

> Bootstrapped and tested ...?

Err, yes, on x86-64, with all languages and without regressions.

> OK.

r259083.


Ciao,
Michael.

Re: [PATCH] [PR c++/85039] no type definitions in builtin offsetof

[Jason Merrill]

On Tue, Apr 3, 2018 at 11:25 PM, Alexandre Oliva  wrote:
> On Apr  3, 2018, Alexandre Oliva  wrote:
>
>> On Apr  2, 2018, Jason Merrill  wrote:
>>> On Sat, Mar 31, 2018 at 7:12 AM, Alexandre Oliva  wrote:
 struct a {
 static int const z, i = __builtin_offsetof(struct b { int j; }, j);
 b c;
 };
 int const a::z = __builtin_offsetof(struct d { int k; }, k);
 d e;
>
 Since d is visible, I suppose the most conservative solution would be to
 name the global namespace as the context for type d, rather than
 defining it as a member of a.  Right?
>
>>> The global namespace would be a rather arbitrary choice; it seems to
>>> me that using the current scope is a natural interpretation.
>
>>> About d in the example, I'm not sure how you mean the global namespace
>>> is the current scope; we should be pushed into a when parsing the
>>> initializer for a::z.
>
>> I was just describing observed behavior.  The code above compiles.
>
>> The explanation is in do_pushtag.  It starts with a loop that, among
>> other things, skips COMPLETE_TYPE_P class scopes.  we then record the
>> new type in the namespace named by the resulting scope.  As the comment
>> says, this is meant to allow for types to be introduced in initializers
>> of static data members in spite of the class being already complete.
>
>> The problem, as I see it, is that we don't adjust the context to match,
>> so we introduce the type in one scope, but claim it to belong to
>> another.  Which sort of works for named types, but comes down in flames
>> (err, reenters like Tiangong-1? ;-) if the type is anonymous.
>
>>> But I would think we should reject the definition of d because a is
>>> already complete, so it's too late to add members to it.
>
>> The existing code in GCC sort of disagrees with your proposal, so, for
>> the sake of avoiding breaking code that we used to compile (like the
>> definition 'd e' above), I'll insist on something along the lines of the
>> following patch:
>
> That patch breaks various cases of lambdas in data member initializers
> that reference members of the class containing the data member.
>
> This suggested to me that we already have infrastructure for and
> expectations of introducing types within a class after the class is
> complete.  Using similar infrastructure to make types introduced within
> __builtin_offsetof, or even in type-casts under the extension I
> attempted to adjust in the proposed patch (the extension that Nathan
> mentioned he also ran into).
>
> I still think we could attempt to retain the extension as it is, parsing
> types introduced in data member initializers within the scope of the
> class containing the data member, like we do, but, when the class is
> already complete, recording it if not in TYPE_FIELDS, in some additional
> field consulted for name mangling purposes and, in order to retain
> compatibility, if the type is not a closure or anonymous, also recording
> it in the enclosing namespace, so that it is found by lookup as in the
> quoted snippet.
>
> Is that a terrible idea?

It sounds like a lot of work to support a very questionable pattern.

Perhaps we should just disallow defining a type in offsetof if the
current scope is a class.

Jason

Re: [C++ PATCH] PR c++/65923

[Jason Merrill]

On Wed, Apr 4, 2018 at 10:35 AM, Ville Voutilainen
 wrote:
> On 3 April 2018 at 17:19, Ville Voutilainen  
> wrote:
>> * parser.c (cp_parser_unqualified_id): Add a new parameter
>> and check it for the literal diagnostic.
>
>
> As discussed on irc, we can indeed do better. With this approach, we look at 
> function declarations
> only, so using-declarations are automatically ok, and we allow friend 
> declarations (that are not
> definitions) and local declarations. Tested locally/partially on Linux-x64, 
> will test with the full suite
> if this is ok. On that front.. ..where can this land? This isn't a 
> regression, but it's certainly a long-standing
> annoyance, but mostly only for -Werror users. I can argue it both ways.

> +   if (suffix[0] != '_' && !in_system_header_at (input_location)

This should use DECL_SOURCE_LOCATION (decl) rather than
input_location.  With that change, this seems safe enough for 8.

Jason

Re: [C++ PATCH] PR c++/65923

[Ville Voutilainen]

On 3 April 2018 at 17:19, Ville Voutilainen  wrote:
> * parser.c (cp_parser_unqualified_id): Add a new parameter
> and check it for the literal diagnostic.


As discussed on irc, we can indeed do better. With this approach, we
look at function declarations
only, so using-declarations are automatically ok, and we allow friend
declarations (that are not
definitions) and local declarations. Tested locally/partially on
Linux-x64, will test with the full suite
if this is ok. On that front.. ..where can this land? This isn't a
regression, but it's certainly a long-standing
annoyance, but mostly only for -Werror users. I can argue it both ways.

2018-04-04  Ville Voutilainen  

gcc/cp

 PR c++/65923
* decl.c (grokfndecl): Handle standard UDL diagnostics here..
* parser.c (cp_parser_unqualified_id): ..not here.

testsuite/

 PR c++/65923
* g++.dg/diagnostic/pr65923.C: New.
diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index ba45673..7ea90b4 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -8941,6 +8941,12 @@ grokfndecl (tree ctype,
 		warning (0, "floating point suffix %qs"
 			" shadowed by implementation", suffix);
 	}
+	  /* 17.6.3.3.5  */
+	  if (suffix[0] != '_' && !in_system_header_at (input_location)
+	  && !current_function_decl && !(friendp && !funcdef_flag))
+	warning (OPT_Wliteral_suffix,
+		 "literal operator suffixes not preceded by %<_%>"
+		 " are reserved for future standardization");
 	}
   else
 	{
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index d526a4e..f6fbcf6 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -6100,16 +6100,6 @@ cp_parser_unqualified_id (cp_parser* parser,
 	  /* If that didn't work, try a conversion-function-id.  */
 	  if (!cp_parser_parse_definitely (parser))
 	id = cp_parser_conversion_function_id (parser);
-	  else if (UDLIT_OPER_P (id))
-	{
-	  /* 17.6.3.3.5  */
-	  const char *name = UDLIT_OP_SUFFIX (id);
-	  if (name[0] != '_' && !in_system_header_at (input_location)
-		  && declarator_p)
-		warning (OPT_Wliteral_suffix,
-			 "literal operator suffixes not preceded by %<_%>"
-			 " are reserved for future standardization");
-	}
 
 	  return id;
 	}
diff --git a/gcc/testsuite/g++.dg/diagnostic/pr65923.C b/gcc/testsuite/g++.dg/diagnostic/pr65923.C
new file mode 100644
index 000..036f447
--- /dev/null
+++ b/gcc/testsuite/g++.dg/diagnostic/pr65923.C
@@ -0,0 +1,23 @@
+// { dg-do compile { target c++14 } }
+
+#include 
+
+using std::literals::chrono_literals::operator""s;
+
+struct X
+{
+  friend constexpr std::chrono::duration std::literals::chrono_literals::operator""s(long double);
+};
+
+struct X2
+{
+  friend constexpr X operator""foo(long double) {return {};} // { dg-warning "literal operator suffixes not preceded" }
+};
+
+namespace std
+{
+  template<> void swap(X&, X&)
+  {
+constexpr std::chrono::duration operator""s(long double);
+  }
+}

Re: [PATCH] [PR c++/84979] improve auto handling in explicit tmpl args for concepts

[Jason Merrill]

On Tue, Apr 3, 2018 at 10:38 PM, Alexandre Oliva  wrote:
> On Apr  3, 2018, Jason Merrill  wrote:
>
>> On Tue, Apr 3, 2018 at 3:54 AM, Alexandre Oliva  wrote:
>>> On Apr  2, 2018, Jason Merrill  wrote:
>>>
 On Sat, Mar 31, 2018 at 4:23 AM, Alexandre Oliva  wrote:
> On Mar 30, 2018, Jason Merrill  wrote:
> template 
> void foo(T t) {
> typename T::template C u = t;
> T::template C (t);
> T::template C::f (t, u);
> }
>>>
 We should be able to distinguish those cases based on tag_type.
>
>>> [...]
>>> And then, while we're parsing "template C", we haven't yet reached
>>> the '::' after the closing angle bracket that would tell us to regard
>>> the id necessarily as a typename, so I don't see how we'd get a
>>> scope_type in tag_type for the third case.
>
>> Ah, good point.  Then perhaps put the new function in pt.c and also
>> call it from tsubst_copy_and_build?
>
> I couldn't figure out how to trigger checks in tsubst_copy_and_build;
> the testcases I threw at it all went through tsubst_qualified_id.  I
> think we can only get an identifier_p in a TEMPLATE_ID_EXPR when it's a
> qualified id naming a member of another template; unqualified names that
> could possibly take explicit template arguments would have to have
> visible declarations, and then we'd get (an overload of) the
> declarations in the TEMPLATE_ID_EXPR.  I see evidence in pt.c that some
> cases of Koenig lookup may involve identifier_p template substitution,
> and I see evidence in the standard that the unqualified template-id
> could have explicit template args, but...  we won't regard  as
> a template arg list if it's not preceded by an id that names a template,
> be it a template-dependent qualified id preceded by the 'template'
> keyword, be a template found by name lookup.  If we find an unrelated
> template function (as in the snippet below), we'll stick to it.  So it
> seems to me that the patch below is all we need.  Am I missing anything?
>
> struct foo { template  friend void bar(T& t); };
> template  void bar();
> template  void f(T& x) { bar (x); }
> void g(foo& x) { f (x); }
>
>
> Regstrapping on i686- and x86_64-linux-gnu.  Ok to install if it passes?
>
>
> [PR c++/84979] reject auto in explicit tmpl args for tmpl-fn
>
> With concepts, we accept auto in explicit template arguments, but we
> should only accept them for template classes.  Passing them to
> template functions or variables is not allowed.  So, reject it, at
> parse time if possible, at specialization time otherwise.
>
>
> for  gcc/cp/ChangeLog
>
> PR c++/84979
> * pt.c (check_auto_in_tmpl_args): New.
> (tsubst_qualified_id): Use it to reject template args
> referencing auto for non-type templates.
> * parser.c (cp_parser_template_id): Likewise.
> * cp-tree.h (check_auto_in_tmpl_args): Declare.
> * typeck2.c (build_functional_cast): Report correct location
> for invalid use of auto.
>
> for  gcc/testsuite/ChangeLog
>
> PR c++/84979
> * g++.dg/concepts/pr84979.C: New.
> * g++.dg/concepts/pr84979-2.C: New.
> * g++.dg/concepts/pr84979-3.C: New.
> ---
>  gcc/cp/cp-tree.h  |1 +
>  gcc/cp/parser.c   |   10 +-
>  gcc/cp/pt.c   |   52 
> +
>  gcc/cp/typeck2.c  |3 +-
>  gcc/testsuite/g++.dg/concepts/pr84979-2.C |   41 +++
>  gcc/testsuite/g++.dg/concepts/pr84979-3.C |   45 +
>  gcc/testsuite/g++.dg/concepts/pr84979.C   |9 +
>  7 files changed, 159 insertions(+), 2 deletions(-)
>  create mode 100644 gcc/testsuite/g++.dg/concepts/pr84979-2.C
>  create mode 100644 gcc/testsuite/g++.dg/concepts/pr84979-3.C
>  create mode 100644 gcc/testsuite/g++.dg/concepts/pr84979.C
>
> diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
> index db79338035da..4777aa34cdbe 100644
> --- a/gcc/cp/cp-tree.h
> +++ b/gcc/cp/cp-tree.h
> @@ -6496,6 +6496,7 @@ extern void maybe_show_extern_c_location (void);
>
>  /* in pt.c */
>  extern bool check_template_shadow  (tree);
> +extern bool check_auto_in_tmpl_args (tree, tree);
>  extern tree get_innermost_template_args(tree, int);
>  extern void maybe_begin_member_template_processing (tree);
>  extern void maybe_end_member_template_processing (void);
> diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
> index e946d0b72292..40a1e5549f02 100644
> --- a/gcc/cp/parser.c
> +++ b/gcc/cp/parser.c
> @@ -15831,8 +15831,16 @@ cp_parser_template_id (cp_parser *parser,
>location_t combined_loc
>  = make_location (token->location, token->location, finish_loc);
>
> +  /* Check for concepts autos where they don't belong.  We could
> + identify types in some cases of idnetifier TEMPL, looking ahead
> + for a CPP_SCOPE, but that would buy us nothing: we accept auto in
> + types.  We reject them in functi

[committed] Fix g++.dg/inherit/override-attribs.C on ia32 (PR testsuite/85189)

[Jakub Jelinek]

Hi!

r258898 changed the wording and changed error to inform for the second
message and adjusted lots of testcases, but has not adjusted this one.

Fixed thusly, tested on x86_64-linux with -m32/-m64, committed to trunk.

2018-04-04  Jakub Jelinek  

PR testsuite/85189
* g++.dg/inherit/override-attribs.C: Use dg-message instead of dg-error
for the diagnostics of overridden functions.  Adjust for new wording.

--- gcc/testsuite/g++.dg/inherit/override-attribs.C.jj  2011-07-11 
10:39:37.0 +0200
+++ gcc/testsuite/g++.dg/inherit/override-attribs.C 2018-04-04 
16:11:21.212486074 +0200
@@ -5,7 +5,7 @@ class one
 {
 public:
   virtual void
-  test(void* value);  // { dg-error "overriding" }
+  test(void* value);  // { dg-message "overridden" }
 };
 
 class two : public one

Jakub

Re: Fix -Wstringop-overflow regression

[Richard Biener]

On Wed, Apr 4, 2018 at 3:34 PM, Michael Matz  wrote:
> Hi,
>
> we shouldn't claim string overflows for character arrays at
> end of structures; the code that tries to avoid these
> accidentally passed the address of the accessed member to
> array_at_struct_end_p(), but that one wants the component_ref
> or array_ref itself.  Needs updating of one testcase that
> incorrectly expected warning to occur in this situation.
> (The regression is that we warn about the testcase now, where we
> didn't warn before)

Bootstrapped and tested ...?

OK.

Thanks,
Richard.

>
> * builtins.c (compute_objsize): Pass correct operand
> to array_at_struct_end_p.
>
> testsuite/
> * gcc.dg/Wstringop-overflow-4.c: New test.
> * c-c++-common/Wstringop-truncation-4.c: Adjust.
>
> diff --git a/gcc/builtins.c b/gcc/builtins.c
> index 487d9d5..3554cdb 100644
> --- a/gcc/builtins.c
> +++ b/gcc/builtins.c
> @@ -3379,7 +3379,7 @@ compute_objsize (tree dest, int ostype)
>type = TYPE_MAIN_VARIANT (type);
>
>if (TREE_CODE (type) == ARRAY_TYPE
> -  && !array_at_struct_end_p (dest))
> +  && !array_at_struct_end_p (TREE_OPERAND (dest, 0)))
>  {
>/* Return the constant size unless it's zero (that's a zero-length
>  array likely at the end of a struct).  */
> diff --git a/gcc/testsuite/c-c++-common/Wstringop-truncation-4.c 
> b/gcc/testsuite/c-c++-common/Wstringop-truncation-4.c
> index c4ad4d6..c76f282 100644
> --- a/gcc/testsuite/c-c++-common/Wstringop-truncation-4.c
> +++ b/gcc/testsuite/c-c++-common/Wstringop-truncation-4.c
> @@ -23,7 +23,7 @@ void test_arrays (struct Arrays *p, const char *s)
>  {
>strncpy (p->a, s, sizeof p->a);   /* { dg-warning 
> "\\\[-Wstringop-truncation" } */
>strncpy ((char*)p->b, s, sizeof p->b);/* { dg-warning 
> "\\\[-Wstringop-truncation" } */
> -  strncpy ((char*)p->c, s, sizeof p->c);/* { dg-warning 
> "\\\[-Wstringop-truncation" } */
> +  strncpy ((char*)p->c, s, sizeof p->c);/* { dg-bogus 
> "\\\[-Wstringop-truncation" } */
>  }
>
>  struct Pointers
> @@ -51,7 +51,7 @@ void test_const_arrays (struct ConstArrays *p, const char 
> *s)
>  {
>strncpy ((char*)p->a, s, sizeof p->a);/* { dg-warning 
> "\\\[-Wstringop-truncation" } */
>strncpy ((char*)p->b, s, sizeof p->b);/* { dg-warning 
> "\\\[-Wstringop-truncation" } */
> -  strncpy ((char*)p->c, s, sizeof p->c);/* { dg-warning 
> "\\\[-Wstringop-truncation" } */
> +  strncpy ((char*)p->c, s, sizeof p->c);/* { dg-bogus 
> "\\\[-Wstringop-truncation" } */
>  }
>
>  struct ConstPointers
> @@ -79,7 +79,7 @@ void test_volatile_arrays (struct VolatileArrays *p, const 
> char *s)
>  {
>strncpy ((char*)p->a, s, sizeof p->a);/* { dg-warning 
> "\\\[-Wstringop-truncation" } */
>strncpy ((char*)p->b, s, sizeof p->b);/* { dg-warning 
> "\\\[-Wstringop-truncation" } */
> -  strncpy ((char*)p->c, s, sizeof p->c);/* { dg-warning 
> "\\\[-Wstringop-truncation" } */
> +  strncpy ((char*)p->c, s, sizeof p->c);/* { dg-bogus 
> "\\\[-Wstringop-truncation" } */
>  }
>
>  struct VolatilePointers
> @@ -107,7 +107,7 @@ void test_const_volatile_arrays (struct 
> ConstVolatileArrays *p, const char *s)
>  {
>strncpy ((char*)p->a, s, sizeof p->a);/* { dg-warning 
> "\\\[-Wstringop-truncation" } */
>strncpy ((char*)p->b, s, sizeof p->b);/* { dg-warning 
> "\\\[-Wstringop-truncation" } */
> -  strncpy ((char*)p->c, s, sizeof p->c);/* { dg-warning 
> "\\\[-Wstringop-truncation" } */
> +  strncpy ((char*)p->c, s, sizeof p->c);/* { dg-bogus 
> "\\\[-Wstringop-truncation" } */
>  }
>
>  struct ConstVolatilePointers
> diff --git a/gcc/testsuite/gcc.dg/Wstringop-overflow-4.c 
> b/gcc/testsuite/gcc.dg/Wstringop-overflow-4.c
> new file mode 100644
> index 000..5905b26
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/Wstringop-overflow-4.c
> @@ -0,0 +1,28 @@
> +/* { dg-do compile }
> +   { dg-options "-O2 -Wstringop-overflow" } */
> +
> +extern char* strchr (const char*, int);
> +extern char* strcpy (char*, const char*);
> +extern void* malloc (__SIZE_TYPE__);
> +extern __SIZE_TYPE__ strlen (const char *);
> +struct define_item {
> +int len;
> +char value[1];
> +};
> +
> +struct define_item * foo(char *name)
> +{
> +  char * p;
> +  char * value;
> +  struct define_item * ptr;
> +
> +  p = strchr (name, '=');
> +  if (1 && p) {
> +  value = p+1;
> +  } else
> +value = "1";
> +
> +  ptr = malloc(sizeof(struct define_item) + strlen(value));
> +  strcpy(ptr->value, value);  /* { dg-bogus "bytes into a region" } */
> +  return ptr;
> +}

Re: [C++ PATCH] Fix __direct_bases ICE (PR c++/85146, take 2)

[Jakub Jelinek]

On Wed, Apr 04, 2018 at 09:25:43AM -0400, Jason Merrill wrote:
> > -calculate_bases (tree type)
> > +calculate_bases (tree type, tsubst_flags_t complain)
> >  {
> > -  vec *vector = make_tree_vector();
> > +  vec *vector = make_tree_vector ();
> 
> While we're touching this line, let's move it down below the early
> return so we don't allocate a vec we aren't going to use.  OK with
> that change.

Ok, done that in both functions, and added one forgotten release_tree_vector
in calculate_direct_bases, so that we don't unnecessarily create extra GC
garbage.  Will regtest it tonight.

2018-04-04  Jakub Jelinek  

PR c++/85146
* cp-tree.h (calculate_bases, calculate_direct_bases): Add complain
argument.
* semantics.c (calculate_bases): Add complain argument.  Use
complete_type_or_maybe_complain instead of just complete_type and
return an empty vector if it fails.  Move make_tree_vector () call
after early return.  Formatting fixes.
(calculate_direct_bases): Likewise.  Call release_tree_vector at the
end.
(dfs_calculate_bases_post, calculate_bases_helper): Formatting fixes.
* pt.c (tsubst_pack_expansion): Adjust calculate_bases and
calculate_direct_bases callers, formatting fixes.

* g++.dg/ext/bases2.C: Expect extra error diagnostics.
* g++.dg/ext/bases3.C: New test.

--- gcc/cp/cp-tree.h.jj 2018-04-03 23:39:16.601665294 +0200
+++ gcc/cp/cp-tree.h2018-04-04 10:34:20.451307112 +0200
@@ -6870,9 +6870,9 @@ extern cp_expr finish_id_expression   (tr
  location_t);
 extern tree finish_typeof  (tree);
 extern tree finish_underlying_type (tree);
-extern tree calculate_bases (tree);
+extern tree calculate_bases (tree, tsubst_flags_t);
 extern tree finish_bases(tree, bool);
-extern tree calculate_direct_bases  (tree);
+extern tree calculate_direct_bases  (tree, tsubst_flags_t);
 extern tree finish_offsetof(tree, tree, location_t);
 extern void finish_decl_cleanup(tree, tree);
 extern void finish_eh_cleanup  (tree);
--- gcc/cp/semantics.c.jj   2018-04-03 23:39:16.559665288 +0200
+++ gcc/cp/semantics.c  2018-04-04 11:17:47.455507857 +0200
@@ -3885,49 +3885,36 @@ finish_underlying_type (tree type)
 }
 
 /* Implement the __direct_bases keyword: Return the direct base classes
-   of type */
+   of type.  */
 
 tree
-calculate_direct_bases (tree type)
+calculate_direct_bases (tree type, tsubst_flags_t complain)
 {
-  vec *vector = make_tree_vector();
-  tree bases_vec = NULL_TREE;
-  vec *base_binfos;
-  tree binfo;
-  unsigned i;
-
-  complete_type (type);
-
-  if (!NON_UNION_CLASS_TYPE_P (type))
+  if (!complete_type_or_maybe_complain (type, NULL_TREE, complain)
+  || !NON_UNION_CLASS_TYPE_P (type))
 return make_tree_vec (0);
 
-  base_binfos = BINFO_BASE_BINFOS (TYPE_BINFO (type));
+  vec *vector = make_tree_vector ();
+  vec *base_binfos = BINFO_BASE_BINFOS (TYPE_BINFO (type));
+  tree binfo;
+  unsigned i;
 
   /* Virtual bases are initialized first */
   for (i = 0; base_binfos->iterate (i, &binfo); i++)
-{
-  if (BINFO_VIRTUAL_P (binfo))
-   {
- vec_safe_push (vector, binfo);
-   }
-}
+if (BINFO_VIRTUAL_P (binfo))
+  vec_safe_push (vector, binfo);
 
   /* Now non-virtuals */
   for (i = 0; base_binfos->iterate (i, &binfo); i++)
-{
-  if (!BINFO_VIRTUAL_P (binfo))
-   {
- vec_safe_push (vector, binfo);
-   }
-}
+if (!BINFO_VIRTUAL_P (binfo))
+  vec_safe_push (vector, binfo);
 
-
-  bases_vec = make_tree_vec (vector->length ());
+  tree bases_vec = make_tree_vec (vector->length ());
 
   for (i = 0; i < vector->length (); ++i)
-{
-  TREE_VEC_ELT (bases_vec, i) = BINFO_TYPE ((*vector)[i]);
-}
+TREE_VEC_ELT (bases_vec, i) = BINFO_TYPE ((*vector)[i]);
+
+  release_tree_vector (vector);
   return bases_vec;
 }
 
@@ -3949,9 +3936,7 @@ dfs_calculate_bases_post (tree binfo, vo
 {
   vec **data = ((vec **) data_);
   if (!BINFO_VIRTUAL_P (binfo))
-{
-  vec_safe_push (*data, BINFO_TYPE (binfo));
-}
+vec_safe_push (*data, BINFO_TYPE (binfo));
   return NULL_TREE;
 }
 
@@ -3959,7 +3944,7 @@ dfs_calculate_bases_post (tree binfo, vo
 static vec *
 calculate_bases_helper (tree type)
 {
-  vec *vector = make_tree_vector();
+  vec *vector = make_tree_vector ();
 
   /* Now add non-virtual base classes in order of construction */
   if (TYPE_BINFO (type))
@@ -3969,26 +3954,25 @@ calculate_bases_helper (tree type)
 }
 
 tree
-calculate_bases (tree type)
+calculate_bases (tree type, tsubst_flags_t complain)
 {
-  vec *vector = make_tree_vector();
+  if (!complete_type_or_maybe_complain (type, NULL_TREE, complain)
+  || !NON_UNION_CLASS_TYPE_P (type))
+return make_tree_v

Re: [PATCH] Disable anchors and msdata for ASAN test-case (PR sanirizer/85174).

[Jakub Jelinek]

On Wed, Apr 04, 2018 at 12:14:43PM +0200, Martin Liška wrote:
> Hi.
> 
> It's test-case workaround, tested on x86_64 and powerpc with both -m64 and 
> -m32.
> 
> Ready for trunk?
> Thanks,
> Martin
> 
> gcc/testsuite/ChangeLog:
> 
> 2018-04-04  Martin Liska  
> 
>   PR sanirizer/85174
>   * c-c++-common/asan/pointer-compare-1.c: Disable section anchors
>   and msdata as a workaround for powerpc.
> ---
>  gcc/testsuite/c-c++-common/asan/pointer-compare-1.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> 

> diff --git a/gcc/testsuite/c-c++-common/asan/pointer-compare-1.c 
> b/gcc/testsuite/c-c++-common/asan/pointer-compare-1.c
> index cf67fe98bee..d4d7784785c 100644
> --- a/gcc/testsuite/c-c++-common/asan/pointer-compare-1.c
> +++ b/gcc/testsuite/c-c++-common/asan/pointer-compare-1.c
> @@ -2,6 +2,9 @@
>  /* { dg-set-target-env-var ASAN_OPTIONS 
> "detect_invalid_pointer_pairs=2:halt_on_error=0" } */
>  /* { dg-options "-fsanitize=address,pointer-compare" } */
>  
> +/* TODO: remove me after PR sanitizer/82501 is resolved.  */
> +/* { dg-additional-options "-fno-section-anchors -msdata=none" { target { 
> powerpc*-*-* } } } */

I'd suggest
/* { dg-additional-options "-fno-section-anchors" } */
and only -msdata=none for powerpc* only.  We have several other section
anchors targets, you can perhaps check gcc-testresults how the test looks
like there.  And use FIXME instead of TODO.

Ok with that change.

Jakub

Fix -Wstringop-overflow regression

[Michael Matz]

Hi,

we shouldn't claim string overflows for character arrays at
end of structures; the code that tries to avoid these
accidentally passed the address of the accessed member to
array_at_struct_end_p(), but that one wants the component_ref
or array_ref itself.  Needs updating of one testcase that
incorrectly expected warning to occur in this situation.
(The regression is that we warn about the testcase now, where we
didn't warn before)


* builtins.c (compute_objsize): Pass correct operand
to array_at_struct_end_p.

testsuite/
* gcc.dg/Wstringop-overflow-4.c: New test.
* c-c++-common/Wstringop-truncation-4.c: Adjust.

diff --git a/gcc/builtins.c b/gcc/builtins.c
index 487d9d5..3554cdb 100644
--- a/gcc/builtins.c
+++ b/gcc/builtins.c
@@ -3379,7 +3379,7 @@ compute_objsize (tree dest, int ostype)
   type = TYPE_MAIN_VARIANT (type);
 
   if (TREE_CODE (type) == ARRAY_TYPE
-  && !array_at_struct_end_p (dest))
+  && !array_at_struct_end_p (TREE_OPERAND (dest, 0)))
 {
   /* Return the constant size unless it's zero (that's a zero-length
 array likely at the end of a struct).  */
diff --git a/gcc/testsuite/c-c++-common/Wstringop-truncation-4.c 
b/gcc/testsuite/c-c++-common/Wstringop-truncation-4.c
index c4ad4d6..c76f282 100644
--- a/gcc/testsuite/c-c++-common/Wstringop-truncation-4.c
+++ b/gcc/testsuite/c-c++-common/Wstringop-truncation-4.c
@@ -23,7 +23,7 @@ void test_arrays (struct Arrays *p, const char *s)
 {
   strncpy (p->a, s, sizeof p->a);   /* { dg-warning 
"\\\[-Wstringop-truncation" } */
   strncpy ((char*)p->b, s, sizeof p->b);/* { dg-warning 
"\\\[-Wstringop-truncation" } */
-  strncpy ((char*)p->c, s, sizeof p->c);/* { dg-warning 
"\\\[-Wstringop-truncation" } */
+  strncpy ((char*)p->c, s, sizeof p->c);/* { dg-bogus 
"\\\[-Wstringop-truncation" } */
 }
 
 struct Pointers
@@ -51,7 +51,7 @@ void test_const_arrays (struct ConstArrays *p, const char *s)
 {
   strncpy ((char*)p->a, s, sizeof p->a);/* { dg-warning 
"\\\[-Wstringop-truncation" } */
   strncpy ((char*)p->b, s, sizeof p->b);/* { dg-warning 
"\\\[-Wstringop-truncation" } */
-  strncpy ((char*)p->c, s, sizeof p->c);/* { dg-warning 
"\\\[-Wstringop-truncation" } */
+  strncpy ((char*)p->c, s, sizeof p->c);/* { dg-bogus 
"\\\[-Wstringop-truncation" } */
 }
 
 struct ConstPointers
@@ -79,7 +79,7 @@ void test_volatile_arrays (struct VolatileArrays *p, const 
char *s)
 {
   strncpy ((char*)p->a, s, sizeof p->a);/* { dg-warning 
"\\\[-Wstringop-truncation" } */
   strncpy ((char*)p->b, s, sizeof p->b);/* { dg-warning 
"\\\[-Wstringop-truncation" } */
-  strncpy ((char*)p->c, s, sizeof p->c);/* { dg-warning 
"\\\[-Wstringop-truncation" } */
+  strncpy ((char*)p->c, s, sizeof p->c);/* { dg-bogus 
"\\\[-Wstringop-truncation" } */
 }
 
 struct VolatilePointers
@@ -107,7 +107,7 @@ void test_const_volatile_arrays (struct ConstVolatileArrays 
*p, const char *s)
 {
   strncpy ((char*)p->a, s, sizeof p->a);/* { dg-warning 
"\\\[-Wstringop-truncation" } */
   strncpy ((char*)p->b, s, sizeof p->b);/* { dg-warning 
"\\\[-Wstringop-truncation" } */
-  strncpy ((char*)p->c, s, sizeof p->c);/* { dg-warning 
"\\\[-Wstringop-truncation" } */
+  strncpy ((char*)p->c, s, sizeof p->c);/* { dg-bogus 
"\\\[-Wstringop-truncation" } */
 }
 
 struct ConstVolatilePointers
diff --git a/gcc/testsuite/gcc.dg/Wstringop-overflow-4.c 
b/gcc/testsuite/gcc.dg/Wstringop-overflow-4.c
new file mode 100644
index 000..5905b26
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/Wstringop-overflow-4.c
@@ -0,0 +1,28 @@
+/* { dg-do compile }
+   { dg-options "-O2 -Wstringop-overflow" } */
+
+extern char* strchr (const char*, int);
+extern char* strcpy (char*, const char*);
+extern void* malloc (__SIZE_TYPE__);
+extern __SIZE_TYPE__ strlen (const char *);
+struct define_item {
+int len;
+char value[1];
+};
+
+struct define_item * foo(char *name)
+{
+  char * p;
+  char * value;
+  struct define_item * ptr;
+
+  p = strchr (name, '=');
+  if (1 && p) {
+  value = p+1;
+  } else
+value = "1";
+
+  ptr = malloc(sizeof(struct define_item) + strlen(value));
+  strcpy(ptr->value, value);  /* { dg-bogus "bytes into a region" } */
+  return ptr;
+}

Re: [C++ PATCH] Fix __direct_bases ICE (PR c++/85146, take 2)

[Jason Merrill]

On Wed, Apr 4, 2018 at 5:28 AM, Jakub Jelinek  wrote:
> On Tue, Apr 03, 2018 at 12:23:11PM -0400, Jason Merrill wrote:
>> On Tue, Apr 3, 2018 at 12:06 PM, Jakub Jelinek  wrote:
>>
>> > From N2965 it is unclear to me what should the trait do on classes with
>> > incomplete types, but given that __bases already returns an empty pack,
>> > this patch does the same for __direct_bases.
>> >
>>
>> I think it should be ill-formed, i.e. call complete_type_or_maybe_complain
>> from tsubst_pack_expansion.
>
> calculate_*bases already calls complete_type, so it seems better to me
> to just pass complain down to those and handle it there.
>
> Ok for trunk if it passes bootstrap/regtest?
>
> I've also double-checked that it works with stuff like
> va_list ap;
> B<__typeof (*ap)> b;
> where __va_list_tag is RECORD_TYPE but not CLASS_TYPE_P.
>
> 2018-04-04  Jakub Jelinek  
>
> PR c++/85146
> * cp-tree.h (calculate_bases, calculate_direct_bases): Add complain
> argument.
> * semantics.c (calculate_direct_bases, calculate_bases): Add complain
> argument.  Use complete_type_or_maybe_complain instead of just
> complete_type and return an empty vector if it fails.  Formatting
> fixes.
> (dfs_calculate_bases_post, calculate_bases_helper): Formatting fixes.
> * pt.c (tsubst_pack_expansion): Adjust calculate_bases and
> calculate_direct_bases callers, formatting fixes.
>
> * g++.dg/ext/bases2.C: Expect extra error diagnostics.
> * g++.dg/ext/bases3.C: New test.
>
> --- gcc/cp/cp-tree.h.jj 2018-04-03 23:39:16.601665294 +0200
> +++ gcc/cp/cp-tree.h2018-04-04 10:34:20.451307112 +0200
> @@ -6870,9 +6870,9 @@ extern cp_expr finish_id_expression   (tr
>   location_t);
>  extern tree finish_typeof  (tree);
>  extern tree finish_underlying_type (tree);
> -extern tree calculate_bases (tree);
> +extern tree calculate_bases (tree, tsubst_flags_t);
>  extern tree finish_bases(tree, bool);
> -extern tree calculate_direct_bases  (tree);
> +extern tree calculate_direct_bases  (tree, tsubst_flags_t);
>  extern tree finish_offsetof(tree, tree, location_t);
>  extern void finish_decl_cleanup(tree, tree);
>  extern void finish_eh_cleanup  (tree);
> --- gcc/cp/semantics.c.jj   2018-04-03 23:39:16.559665288 +0200
> +++ gcc/cp/semantics.c  2018-04-04 11:17:47.455507857 +0200
> @@ -3885,49 +3885,38 @@ finish_underlying_type (tree type)
>  }
>
>  /* Implement the __direct_bases keyword: Return the direct base classes
> -   of type */
> +   of type.  */
>
>  tree
> -calculate_direct_bases (tree type)
> +calculate_direct_bases (tree type, tsubst_flags_t complain)
>  {
> -  vec *vector = make_tree_vector();
> +  vec *vector = make_tree_vector ();
>tree bases_vec = NULL_TREE;
>vec *base_binfos;
>tree binfo;
>unsigned i;
>
> -  complete_type (type);
> -
> -  if (!NON_UNION_CLASS_TYPE_P (type))
> +  if (!complete_type_or_maybe_complain (type, NULL_TREE, complain)
> +  || !NON_UNION_CLASS_TYPE_P (type))
>  return make_tree_vec (0);
>
>base_binfos = BINFO_BASE_BINFOS (TYPE_BINFO (type));
>
>/* Virtual bases are initialized first */
>for (i = 0; base_binfos->iterate (i, &binfo); i++)
> -{
> -  if (BINFO_VIRTUAL_P (binfo))
> -   {
> - vec_safe_push (vector, binfo);
> -   }
> -}
> +if (BINFO_VIRTUAL_P (binfo))
> +  vec_safe_push (vector, binfo);
>
>/* Now non-virtuals */
>for (i = 0; base_binfos->iterate (i, &binfo); i++)
> -{
> -  if (!BINFO_VIRTUAL_P (binfo))
> -   {
> - vec_safe_push (vector, binfo);
> -   }
> -}
> -
> +if (!BINFO_VIRTUAL_P (binfo))
> +  vec_safe_push (vector, binfo);
>
>bases_vec = make_tree_vec (vector->length ());
>
>for (i = 0; i < vector->length (); ++i)
> -{
> -  TREE_VEC_ELT (bases_vec, i) = BINFO_TYPE ((*vector)[i]);
> -}
> +TREE_VEC_ELT (bases_vec, i) = BINFO_TYPE ((*vector)[i]);
> +
>return bases_vec;
>  }
>
> @@ -3949,9 +3938,7 @@ dfs_calculate_bases_post (tree binfo, vo
>  {
>vec **data = ((vec **) data_);
>if (!BINFO_VIRTUAL_P (binfo))
> -{
> -  vec_safe_push (*data, BINFO_TYPE (binfo));
> -}
> +vec_safe_push (*data, BINFO_TYPE (binfo));
>return NULL_TREE;
>  }
>
> @@ -3959,7 +3946,7 @@ dfs_calculate_bases_post (tree binfo, vo
>  static vec *
>  calculate_bases_helper (tree type)
>  {
> -  vec *vector = make_tree_vector();
> +  vec *vector = make_tree_vector ();
>
>/* Now add non-virtual base classes in order of construction */
>if (TYPE_BINFO (type))
> @@ -3969,18 +3956,17 @@ calculate_bases_helper (tree type)
>  }
>
>  tree
> -calculate_bases (tree type)
> +calculate_bases (tree type, tsubst_flags_t complain)
>  {

[PATCH] libgo: Avoid clobbering shell history file in signal_cgo_test.go

[Andreas Schwab]

For some reason signal_cgo_test.go needs to run an interactive shell,
but suppresses reading the startup files.  This causes the shell history
file to be clobbered, by using different history settings than usual.
Avoid that by setting HOME to / so that the shell cannot write a history
file.

* libgo/go/os/signal/signal_cgo_test.go: Set HOME to / before
starting shell.
---
 libgo/go/os/signal/signal_cgo_test.go | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libgo/go/os/signal/signal_cgo_test.go 
b/libgo/go/os/signal/signal_cgo_test.go
index 84a2a08ce9..3c127378d2 100644
--- a/libgo/go/os/signal/signal_cgo_test.go
+++ b/libgo/go/os/signal/signal_cgo_test.go
@@ -88,6 +88,7 @@ func TestTerminalSignal(t *testing.T) {
// Start an interactive shell.
ctx, cancel := context.WithTimeout(context.Background(), 10*time.Second)
defer cancel()
+   os.Setenv("HOME", "/")
cmd := exec.CommandContext(ctx, bash, "--norc", "--noprofile", "-i")
cmd.Stdin = slave
cmd.Stdout = slave
-- 
2.17.0


-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: [PATCH][GCC][mid-end] Allow larger copies when target supports unaligned access [Patch (1/2)]

[Peter Bergner]

On 4/4/18 4:06 AM, Tamar Christina wrote:
> Now that I know how the loads are done, I have a patch should be both correct 
> and generate better code in most cases.
> It just calculates bitsize inside the loop and does the copying in the 
> largest mode possible that's equal or less than the bits
> That are to be copied. This avoids the issue with reading too much, honors 
> padding and alignment and still generates better code
> In most cases.
> 
> I'm running the regression tests and should have a final version soon.

If you give me your patch when it's ready, I'll do bootstrap and regression
testing on powerpc*-linux and verify it fixes the issues we hit.

Peter

[PATCH] Fix PR85176, LTO with -g1

[Richard Biener]

This fixes an issue with LTO handling DINFO_LEVEL_TERSE where we do
not generate DIEs for NAMESPACE_DECLs and thus reconstruction of the
DIE tree from DECL_CONTEXT at LTRANS time fails.  The fix is to
skip NAMESPACE_DECL contexts like we do for TYPE contexts.

[LTO with -g1] Bootstrapped on x86_64-unknown-linux-gnu, testing in
progress.

Richard.

2018-04-04  Richard Biener  

PR lto/85176
* dwarf2out.c (dwarf2out_register_external_die): Peel namespaces
from contexts for DINFO_LEVEL_TERSE and below.

* g++.dg/lto/pr85176_0.C: New testcase.

Index: gcc/dwarf2out.c
===
--- gcc/dwarf2out.c (revision 259069)
+++ gcc/dwarf2out.c (working copy)
@@ -5903,8 +5903,13 @@ dwarf2out_register_external_die (tree de
 }
   else
 ctx = DECL_CONTEXT (decl);
+  /* Peel types in the context stack.  */
   while (ctx && TYPE_P (ctx))
 ctx = TYPE_CONTEXT (ctx);
+  /* Likewise namespaces in case we do not want to emit DIEs for them.  */
+  if (debug_info_level <= DINFO_LEVEL_TERSE)
+while (ctx && TREE_CODE (ctx) == NAMESPACE_DECL)
+  ctx = DECL_CONTEXT (ctx);
   if (ctx)
 {
   if (TREE_CODE (ctx) == BLOCK)
Index: gcc/testsuite/g++.dg/lto/pr85176_0.C
===
--- gcc/testsuite/g++.dg/lto/pr85176_0.C(nonexistent)
+++ gcc/testsuite/g++.dg/lto/pr85176_0.C(working copy)
@@ -0,0 +1,10 @@
+// { dg-lto-do link }
+// { dg-lto-options { { -flto -g1 } } }
+// { dg-extra-ld-options "-r -nostdlib" }
+namespace a {
+template  class c;
+template  void e(c &);
+void operator<<(c &f, const char *) { e(f); }
+extern c cout;
+}
+int main() { a::cout << ""; }

[PATCH] Fix PR85191

[Richard Biener]

Typo...

Committed as obvious.

Richard.

2018-04-04  Richard Biener  

PR testsuite/85191
* lib/target-supports.exp (check_effective_target_vect_perm_short):
Fix typo.

Index: gcc/testsuite/lib/target-supports.exp
===
--- gcc/testsuite/lib/target-supports.exp   (revision 259069)
+++ gcc/testsuite/lib/target-supports.exp   (working copy)
@@ -5828,8 +5828,8 @@ proc check_effective_target_vect_perm_sh
 && ![check_effective_target_vect_variable_length])
 || [istarget powerpc*-*-*]
 || [istarget spu-*-*]
-|| (([istarget i?86-*-*] || [istarget x86_64-*-*]
-&& [check_ssse3_available]))
+|| (([istarget i?86-*-*] || [istarget x86_64-*-*])
+&& [check_ssse3_available])
 || ([istarget mips*-*-*]
  && [et-is-effective-target mips_msa])
 || ([istarget s390*-*-*]

Re: [PATCH] Disable anchors and msdata for ASAN test-case (PR sanirizer/85174).

[Martin Liška]

On 04/04/2018 12:29 PM, Segher Boessenkool wrote:
> On Wed, Apr 04, 2018 at 12:21:14PM +0200, Jakub Jelinek wrote:
>> On Wed, Apr 04, 2018 at 12:14:43PM +0200, Martin Liška wrote:
>>> It's test-case workaround, tested on x86_64 and powerpc with both -m64 and 
>>> -m32.
>>>
>>> 2018-04-04  Martin Liska  
>>>
>>> PR sanirizer/85174
> 
> (typo)

Thanks.

> 
>>> * c-c++-common/asan/pointer-compare-1.c: Disable section anchors
>>> and msdata as a workaround for powerpc.
>>> ---
>>>  gcc/testsuite/c-c++-common/asan/pointer-compare-1.c | 3 +++
>>>  1 file changed, 3 insertions(+)
>>>
>>>
>>
>>> diff --git a/gcc/testsuite/c-c++-common/asan/pointer-compare-1.c 
>>> b/gcc/testsuite/c-c++-common/asan/pointer-compare-1.c
>>> index cf67fe98bee..d4d7784785c 100644
>>> --- a/gcc/testsuite/c-c++-common/asan/pointer-compare-1.c
>>> +++ b/gcc/testsuite/c-c++-common/asan/pointer-compare-1.c
>>> @@ -2,6 +2,9 @@
>>>  /* { dg-set-target-env-var ASAN_OPTIONS 
>>> "detect_invalid_pointer_pairs=2:halt_on_error=0" } */
>>>  /* { dg-options "-fsanitize=address,pointer-compare" } */
>>>  
>>> +/* TODO: remove me after PR sanitizer/82501 is resolved.  */
>>> +/* { dg-additional-options "-fno-section-anchors -msdata=none" { target { 
>>> powerpc*-*-* } } } */
>>
>> I'd suggest
>> /* { dg-additional-options "-fno-section-anchors" } */
>> and only -msdata=none for powerpc* only.  We have several other section
>> anchors targets, you can perhaps check gcc-testresults how the test looks
>> like there.  And use FIXME instead of TODO.
> 
> Another option is to use -G10 or higher, or simply make the little_global
> array 8 bytes or less (the default is -G8).  That has the advantage
> that we do test sdata and will not have to remember to reenable things
> in this testcase.

Let's do now a quick workaround and fix that properly later.

Martin

> 
> 
> Segher
> 

Re: [PATCH, rs6000] Undefine vector, bool, pixel in xmmintrin.h

[Jakub Jelinek]

On Sun, Apr 01, 2018 at 08:24:32PM -0500, Bill Schmidt wrote:
> I also updated the gcc.target/powerpc/powerpc.exp file to allow C++
> tests to be placed in that directory (with a *.C suffix).

I think this is wrong.
Historically, we've been putting target C++ tests into g++.dg/*/*.C
with appropriate target guards, the gcc.target/ tests are compiled with the
gcc driver rather than g++, so in your case it just happens to work because
it is a compile time test only (and one that doesn't use any STL headers),
e.g. dg-do run test would fail miserably.

If we (for GCC9?) want to create a spot for target C++ tests, we should
just add g++.target// directories and add all the needed infrastructure
for those.

Can you please revert the powerpc.exp change and move the test to
g++.dg/ext/ ?  Thanks.

Jakub

Re: [PATCH] Disable anchors and msdata for ASAN test-case (PR sanirizer/85174).

[Segher Boessenkool]

On Wed, Apr 04, 2018 at 12:21:14PM +0200, Jakub Jelinek wrote:
> On Wed, Apr 04, 2018 at 12:14:43PM +0200, Martin Liška wrote:
> > It's test-case workaround, tested on x86_64 and powerpc with both -m64 and 
> > -m32.
> > 
> > 2018-04-04  Martin Liska  
> > 
> > PR sanirizer/85174

(typo)

> > * c-c++-common/asan/pointer-compare-1.c: Disable section anchors
> > and msdata as a workaround for powerpc.
> > ---
> >  gcc/testsuite/c-c++-common/asan/pointer-compare-1.c | 3 +++
> >  1 file changed, 3 insertions(+)
> > 
> > 
> 
> > diff --git a/gcc/testsuite/c-c++-common/asan/pointer-compare-1.c 
> > b/gcc/testsuite/c-c++-common/asan/pointer-compare-1.c
> > index cf67fe98bee..d4d7784785c 100644
> > --- a/gcc/testsuite/c-c++-common/asan/pointer-compare-1.c
> > +++ b/gcc/testsuite/c-c++-common/asan/pointer-compare-1.c
> > @@ -2,6 +2,9 @@
> >  /* { dg-set-target-env-var ASAN_OPTIONS 
> > "detect_invalid_pointer_pairs=2:halt_on_error=0" } */
> >  /* { dg-options "-fsanitize=address,pointer-compare" } */
> >  
> > +/* TODO: remove me after PR sanitizer/82501 is resolved.  */
> > +/* { dg-additional-options "-fno-section-anchors -msdata=none" { target { 
> > powerpc*-*-* } } } */
> 
> I'd suggest
> /* { dg-additional-options "-fno-section-anchors" } */
> and only -msdata=none for powerpc* only.  We have several other section
> anchors targets, you can perhaps check gcc-testresults how the test looks
> like there.  And use FIXME instead of TODO.

Another option is to use -G10 or higher, or simply make the little_global
array 8 bytes or less (the default is -G8).  That has the advantage
that we do test sdata and will not have to remember to reenable things
in this testcase.


Segher

[PATCH] Disable anchors and msdata for ASAN test-case (PR sanirizer/85174).

[Martin Liška]

Hi.

It's test-case workaround, tested on x86_64 and powerpc with both -m64 and -m32.

Ready for trunk?
Thanks,
Martin

gcc/testsuite/ChangeLog:

2018-04-04  Martin Liska  

PR sanirizer/85174
* c-c++-common/asan/pointer-compare-1.c: Disable section anchors
and msdata as a workaround for powerpc.
---
 gcc/testsuite/c-c++-common/asan/pointer-compare-1.c | 3 +++
 1 file changed, 3 insertions(+)


diff --git a/gcc/testsuite/c-c++-common/asan/pointer-compare-1.c b/gcc/testsuite/c-c++-common/asan/pointer-compare-1.c
index cf67fe98bee..d4d7784785c 100644
--- a/gcc/testsuite/c-c++-common/asan/pointer-compare-1.c
+++ b/gcc/testsuite/c-c++-common/asan/pointer-compare-1.c
@@ -2,6 +2,9 @@
 /* { dg-set-target-env-var ASAN_OPTIONS "detect_invalid_pointer_pairs=2:halt_on_error=0" } */
 /* { dg-options "-fsanitize=address,pointer-compare" } */
 
+/* TODO: remove me after PR sanitizer/82501 is resolved.  */
+/* { dg-additional-options "-fno-section-anchors -msdata=none" { target { powerpc*-*-* } } } */
+
 volatile int v;
 
 __attribute__((noipa)) void

Re: [PATCH] Prefer mempcpy to memcpy on x86_64 target (PR middle-end/81657).

[Martin Liška]

PING^1

On 03/29/2018 02:31 PM, Martin Liška wrote:
> On 03/29/2018 02:25 PM, Jakub Jelinek wrote:
>> On Thu, Mar 29, 2018 at 01:28:13PM +0200, Martin Liška wrote:
>>> On 03/28/2018 06:36 PM, Jakub Jelinek wrote:
 On Wed, Mar 28, 2018 at 06:30:21PM +0200, Martin Liška wrote:
> --- a/gcc/config/linux.c
> +++ b/gcc/config/linux.c
> @@ -37,3 +37,24 @@ linux_libc_has_function (enum function_class fn_class)
>  return false;
>    }
> +
> +/* This hook determines whether a function from libc has a fast 
> implementation
> +   FN is present at the runtime.  We override it for i386 and glibc C 
> library
> +   as this combination provides fast implementation of mempcpy function. 
>  */
> +
> +enum libc_speed
> +ix86_linux_libc_func_speed (int fn)

 Putting a ix86_ function into config/linux.c used by most linux targets is
 weird.  Either we multiple linux targets with mempcpy fast, then name it
 somehow cpu neutral and let all those CPUs pick it up in config/*/linux.h.
 And yes, we do care about i?86-linux.  Or it is for x86 only, and then
 it shouldn't be in config/linux.c, but either e.g. static inline in
 config/i386/linux.h, or we need config/i386/linux.c if we don't have it
 already.
>>>
>>> I'm fine with putting the implementation into gcc/config/i386/linux.c. Can 
>>> you please
>>
>> Can't you just put it into gcc/config/i386/linux-common.h as static inline,
>> so that it is optimized away whenever not needed?
> 
> I would like to put it there, but:
> 
> g++ -c   -g  -DIN_GCC -fno-exceptions -fno-rtti 
> -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings 
> -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic 
> -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common  
> -DHAVE_CONFIG_H -DGENERATOR_FILE -fno-PIE -I. -Ibuild -I../../gcc 
> -I../../gcc/build -I../../gcc/../include  -I../../gcc/../libcpp/include  \
> -o build/genpreds.o ../../gcc/genpreds.c
> In file included from ./tm.h:38:0,
>  from ../../gcc/genpreds.c:26:
> ../../gcc/config/i386/linux-common.h: In function ‘libc_speed 
> ix86_linux_libc_func_speed(int)’:
> ../../gcc/config/i386/linux-common.h:137:8: error: use of enum 
> ‘built_in_function’ without previous declaration
>    enum built_in_function f = (built_in_function)fn;
>     ^
> ../../gcc/config/i386/linux-common.h:137:31: error: ‘built_in_function’ was 
> not declared in this scope
>    enum built_in_function f = (built_in_function)fn;
>    ^
> ../../gcc/config/i386/linux-common.h:137:31: note: suggested alternative: 
> ‘machine_function’
>    enum built_in_function f = (built_in_function)fn;
>    ^
>    machine_function
> ../../gcc/config/i386/linux-common.h:144:12: error: ‘BUILT_IN_MEMPCPY’ was 
> not declared in this scope
>    case BUILT_IN_MEMPCPY:
>     ^~~~
> Martin
> 
>>
>> If you really want to add a c file, it better not be called linux.c, because
>> linux.o for it would clash with linux.o from gcc/config/linux.c.  And,
>> you'd need to add the whatever.o into extra_objs in gcc/config.gcc and add
>> rules for it into gcc/config/i386/t-linux (see linux.o in config.gcc and
>> config/t-linux).
>>
>>> help me how to conditionally build the file?
>>
>> Jakub
>>
> 

[C++ PATCH] Fix __direct_bases ICE (PR c++/85146, take 2)

[Jakub Jelinek]

On Tue, Apr 03, 2018 at 12:23:11PM -0400, Jason Merrill wrote:
> On Tue, Apr 3, 2018 at 12:06 PM, Jakub Jelinek  wrote:
> 
> > From N2965 it is unclear to me what should the trait do on classes with
> > incomplete types, but given that __bases already returns an empty pack,
> > this patch does the same for __direct_bases.
> >
> 
> I think it should be ill-formed, i.e. call complete_type_or_maybe_complain
> from tsubst_pack_expansion.

calculate_*bases already calls complete_type, so it seems better to me
to just pass complain down to those and handle it there.

Ok for trunk if it passes bootstrap/regtest?

I've also double-checked that it works with stuff like
va_list ap;
B<__typeof (*ap)> b;
where __va_list_tag is RECORD_TYPE but not CLASS_TYPE_P.

2018-04-04  Jakub Jelinek  

PR c++/85146
* cp-tree.h (calculate_bases, calculate_direct_bases): Add complain
argument.
* semantics.c (calculate_direct_bases, calculate_bases): Add complain
argument.  Use complete_type_or_maybe_complain instead of just
complete_type and return an empty vector if it fails.  Formatting
fixes.
(dfs_calculate_bases_post, calculate_bases_helper): Formatting fixes.
* pt.c (tsubst_pack_expansion): Adjust calculate_bases and
calculate_direct_bases callers, formatting fixes.

* g++.dg/ext/bases2.C: Expect extra error diagnostics.
* g++.dg/ext/bases3.C: New test.

--- gcc/cp/cp-tree.h.jj 2018-04-03 23:39:16.601665294 +0200
+++ gcc/cp/cp-tree.h2018-04-04 10:34:20.451307112 +0200
@@ -6870,9 +6870,9 @@ extern cp_expr finish_id_expression   (tr
  location_t);
 extern tree finish_typeof  (tree);
 extern tree finish_underlying_type (tree);
-extern tree calculate_bases (tree);
+extern tree calculate_bases (tree, tsubst_flags_t);
 extern tree finish_bases(tree, bool);
-extern tree calculate_direct_bases  (tree);
+extern tree calculate_direct_bases  (tree, tsubst_flags_t);
 extern tree finish_offsetof(tree, tree, location_t);
 extern void finish_decl_cleanup(tree, tree);
 extern void finish_eh_cleanup  (tree);
--- gcc/cp/semantics.c.jj   2018-04-03 23:39:16.559665288 +0200
+++ gcc/cp/semantics.c  2018-04-04 11:17:47.455507857 +0200
@@ -3885,49 +3885,38 @@ finish_underlying_type (tree type)
 }
 
 /* Implement the __direct_bases keyword: Return the direct base classes
-   of type */
+   of type.  */
 
 tree
-calculate_direct_bases (tree type)
+calculate_direct_bases (tree type, tsubst_flags_t complain)
 {
-  vec *vector = make_tree_vector();
+  vec *vector = make_tree_vector ();
   tree bases_vec = NULL_TREE;
   vec *base_binfos;
   tree binfo;
   unsigned i;
 
-  complete_type (type);
-
-  if (!NON_UNION_CLASS_TYPE_P (type))
+  if (!complete_type_or_maybe_complain (type, NULL_TREE, complain)
+  || !NON_UNION_CLASS_TYPE_P (type))
 return make_tree_vec (0);
 
   base_binfos = BINFO_BASE_BINFOS (TYPE_BINFO (type));
 
   /* Virtual bases are initialized first */
   for (i = 0; base_binfos->iterate (i, &binfo); i++)
-{
-  if (BINFO_VIRTUAL_P (binfo))
-   {
- vec_safe_push (vector, binfo);
-   }
-}
+if (BINFO_VIRTUAL_P (binfo))
+  vec_safe_push (vector, binfo);
 
   /* Now non-virtuals */
   for (i = 0; base_binfos->iterate (i, &binfo); i++)
-{
-  if (!BINFO_VIRTUAL_P (binfo))
-   {
- vec_safe_push (vector, binfo);
-   }
-}
-
+if (!BINFO_VIRTUAL_P (binfo))
+  vec_safe_push (vector, binfo);
 
   bases_vec = make_tree_vec (vector->length ());
 
   for (i = 0; i < vector->length (); ++i)
-{
-  TREE_VEC_ELT (bases_vec, i) = BINFO_TYPE ((*vector)[i]);
-}
+TREE_VEC_ELT (bases_vec, i) = BINFO_TYPE ((*vector)[i]);
+
   return bases_vec;
 }
 
@@ -3949,9 +3938,7 @@ dfs_calculate_bases_post (tree binfo, vo
 {
   vec **data = ((vec **) data_);
   if (!BINFO_VIRTUAL_P (binfo))
-{
-  vec_safe_push (*data, BINFO_TYPE (binfo));
-}
+vec_safe_push (*data, BINFO_TYPE (binfo));
   return NULL_TREE;
 }
 
@@ -3959,7 +3946,7 @@ dfs_calculate_bases_post (tree binfo, vo
 static vec *
 calculate_bases_helper (tree type)
 {
-  vec *vector = make_tree_vector();
+  vec *vector = make_tree_vector ();
 
   /* Now add non-virtual base classes in order of construction */
   if (TYPE_BINFO (type))
@@ -3969,18 +3956,17 @@ calculate_bases_helper (tree type)
 }
 
 tree
-calculate_bases (tree type)
+calculate_bases (tree type, tsubst_flags_t complain)
 {
-  vec *vector = make_tree_vector();
+  vec *vector = make_tree_vector ();
   tree bases_vec = NULL_TREE;
   unsigned i;
   vec *vbases;
   vec *nonvbases;
   tree binfo;
 
-  complete_type (type);
-
-  if (!NON_UNION_CLASS_TYPE_P (type))
+  if (!complete_type_or_maybe_complain (type, NULL_TRE

[patch, libfortran, committed] Implement stop_numeric for minimal targets

[Thomas König]

Hello world,

the recent patch to make the gfortran and libgomp testsuites more
standard conforming, by replacing CALL ABORT() with STOP N, led
to numerous testsuite failures on nvptx because stop_numeric
was not implemented in minimal.c.

I have committed the patch below in r259072 as obvious after Tom
de Vries had confirmed that it solves the problem.

Regards

Thomas

2018-04-04  Thomas Koenig  

PR libfortran/85166
* runtime/minimal.c (stop_numeric): Add new function in order to
implement numeric stop on minimal targets.
Index: runtime/minimal.c
===
--- runtime/minimal.c	(Revision 259055)
+++ runtime/minimal.c	(Arbeitskopie)
@@ -187,3 +187,17 @@
 
   abort();
 }
+
+/* A numeric STOP statement.  */
+
+extern _Noreturn void stop_numeric (int, bool);
+export_proto(stop_numeric);
+
+void
+stop_numeric (int code, bool quiet)
+{
+  if (!quiet)
+printf ("STOP %d\n", code);
+
+  exit (code);
+}

RE: [PATCH][GCC][mid-end] Allow larger copies when target supports unaligned access [Patch (1/2)]

[Tamar Christina]

> -Original Message-
> From: Alan Modra 
> Sent: Tuesday, April 3, 2018 14:16
> To: Richard Biener 
> Cc: Peter Bergner ; Tamar Christina
> ; gcc-patches@gcc.gnu.org; nd ;
> l...@redhat.com; i...@airs.com
> Subject: Re: [PATCH][GCC][mid-end] Allow larger copies when target
> supports unaligned access [Patch (1/2)]
> 
> On Tue, Apr 03, 2018 at 02:30:23PM +0200, Richard Biener wrote:
> > On Tue, 3 Apr 2018, Alan Modra wrote:
> >
> > > On Tue, Apr 03, 2018 at 01:01:23PM +0200, Richard Biener wrote:
> > > > On Fri, 30 Mar 2018, Peter Bergner wrote:
> > > >
> > > > > On 3/29/18 9:35 AM, Alan Modra wrote:
> > > > > > On Thu, Nov 16, 2017 at 03:27:01PM +, Tamar Christina wrote:
> > > > > >> --- a/gcc/expr.c
> > > > > >> +++ b/gcc/expr.c
> > > > > >> @@ -2769,7 +2769,9 @@ copy_blkmode_to_reg (machine_mode
> mode,
> > > > > >> tree src)
> > > > > >>
> > > > > >>n_regs = (bytes + UNITS_PER_WORD - 1) / UNITS_PER_WORD;
> > > > > >>dst_words = XALLOCAVEC (rtx, n_regs);
> > > > > >> -  bitsize = MIN (TYPE_ALIGN (TREE_TYPE (src)),
> > > > > >> BITS_PER_WORD);
> > > > > >> +  bitsize = BITS_PER_WORD;
> > > > > >> +  if (targetm.slow_unaligned_access (word_mode, TYPE_ALIGN
> (TREE_TYPE (src
> > > > > >> +bitsize = MIN (TYPE_ALIGN (TREE_TYPE (src)),
> > > > > >> + BITS_PER_WORD);
> > > > > >>
> > > > > >>/* Copy the structure BITSIZE bits at a time.  */
> > > > > >>for (bitpos = 0, xbitpos = padding_correction;
> > > > > >
> > > > > > I believe this patch is wrong.  Please revert.  See the PR84762
> testcase.
> > > > > >
> > > > > > There are two problems.  Firstly, if padding_correction is
> > > > > > non-zero, then xbitpos % BITS_PER_WORD is non-zero and in
> > > > > >
> > > > > >   store_bit_field (dst_word, bitsize, xbitpos % BITS_PER_WORD,
> > > > > >0, 0, word_mode,
> > > > > >extract_bit_field (src_word, bitsize,
> > > > > >   bitpos % BITS_PER_WORD, 1,
> > > > > >   NULL_RTX, word_mode,
> word_mode,
> > > > > >   false, NULL),
> > > > > >false);
> > > > > >
> > > > > > the stored bit-field exceeds the destination register size.
> > > > > > You could fix that by making bitsize the gcd of bitsize and
> padding_correction.
> > > > > >
> > > > > > However, that doesn't fix the second problem which is that the
> > > > > > extracted bit-field can exceed the source size.  That will
> > > > > > result in rubbish being read into a register.
> > > > >
> > > > > FYI, I received an automated response saying Tamar is away on
> > > > > vacation with no return date specified.  That means he won't be
> > > > > able to revert the patch.  What do we do now?
> > > >
> > > > The code before the change already looks fishy to me.
> > >
> > > Yes, it is fishy so far as the code in the loop relies on alignment
> > > determining a small enough bitsize.  Adding
> > >
> > >   if (bytes % UNITS_PER_WORD != 0)
> > > bitsize = gcd (bitsize, (bytes % UNITS_PER_WORD) *
> > > BITS_PER_UNIT);
> > >
> > > after bitsize is calculated from alignment would make the code
> > > correct, I believe.  But I think that will fail the testcase Tamar
> > > added.
> > >
> > > >   x = expand_normal (src);
> > > >
> > > > so what do we expect this to expand to in general?  Fortunately it
> > > > seems there are exactly two callers so hopefully a gcc_assert
> > > > (MEM_P (x)) would work?
> > > >
> > > > The fishy part is looking at TYPE_ALIGN (TREE_TYPE (src)).
> > > >
> > > > In case x is a MEM we should use MEM_ALIGN and if not then we
> > > > shouldn't do anything but just use word_mode here.
> > >
> > > No!  You can't use a bitsize of BITS_PER_WORD here.  See the code I
> > > quoted above.
> >
> > Ah, so it should possibly use TYPE_SIZE instead of TYPE_ALIGN
> 
> Not that either.  We already have a byte count..
> 
> > otherwise
> > it will handle the over-aligned case (align to 8 bytes, size 4 bytes)
> > incorrectly as well?
> 
> Yes, that case is mishandled too, even before Tamar's patch.  Peter's
> pr85123 testcase with vfloat1 aligned(8) is an example.
> 
> If we want correct code, then
> 
>   if (bytes % UNITS_PER_WORD != 0)
> bitsize = gcd (bitsize, (bytes % UNITS_PER_WORD) * BITS_PER_UNIT);
> 

If bitsize is still initially calculated based on alignment, unless you over 
align it's
still just going to do 8 bit copies as it did before, which isn't an 
improvement at all.

Now that I know how the loads are done, I have a patch should be both correct 
and generate better code in most cases.
It just calculates bitsize inside the loop and does the copying in the largest 
mode possible that's equal or less than the bits
That are to be copied. This avoids the issue with reading too much, honors 
padding and alignment and still generates better code
In most cases.

I'm running the regression tests and should have a final version soon.

> will fix th

Re: [wwwdocs]Mention -ftree-loop-distribution

[Bin.Cheng]

On Wed, Apr 4, 2018 at 8:08 AM, Gerald Pfeifer  wrote:
> On Tue, 3 Apr 2018, Bin Cheng wrote:
>> Option -ftree-loop-distribution is improved and enabled by default at
>> -O3 for GCC8. This patch describes the change, is it OK?
>
> Index: htdocs/gcc-8/changes.html
> ===
> +Classical loop nest optimization pass 
> -ftree-loop-distribution
>
> "The classic loop nest..." (i.e., add the article and I believe classic
> is more appropriate than classical which connotates the arts,...).
>
> +It supports loop nest distribution in some restricted scenarios; it also
> +supports cancellable innermost loop distribution with loop versioning
> +under runtime alias checks.
>
> I believe that would be "run-time" (per codingconventions.html)?
>
> Fine with the change above and considering the second comment.
Thanks for the suggestions,  attachment is the updated change.

Thanks,
bin
>
> Thank you,
> Gerald
Index: htdocs/gcc-8/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-8/changes.html,v
retrieving revision 1.51
diff -u -r1.51 changes.html
--- htdocs/gcc-8/changes.html   3 Apr 2018 06:52:04 -   1.51
+++ htdocs/gcc-8/changes.html   4 Apr 2018 08:55:11 -
@@ -101,6 +101,13 @@
 are enabled by default at -O3 and above.
   
   
+The classic loop nest optimization pass 
-ftree-loop-distribution
+has been improved and enabled by default at -O3 and above.
+It supports loop nest distribution in some restricted scenarios; it also
+supports cancellable innermost loop distribution with loop versioning
+under run-time alias checks.
+  
+  
 The new option -fstack-clash-protection causes the
 compiler to insert probes whenever stack space is allocated
 statically or dynamically to reliably detect stack overflows and

Re: [PATCH, testsuite, 2/2] Add scan-ltrans-tree-dump

[Tom de Vries]

On 04/03/2018 07:49 PM, Bernhard Reutner-Fischer wrote:

This patch adds scan-ltrans-tree-dump.


Please check all error calls to talk about the correct function -- at least 
scan-ltrans-tree-dump-times is wrong.



Hi,

thanks for noticing that. I'll update the patches to fix that.

But I wonder if it's not a better idea to get the function name using 
"info level", and to move the code that checks the number of arguments 
into a utility function, as done in the demonstrator patch below.


Rainer, Mike, any comments? I can write a patch that uses check_num_args 
in testsuite/lib/*.exp (though I'm not yet sure where to move it such 
that it can be used everywhere).


Thanks,
- Tom
diff --git a/gcc/testsuite/lib/scanltranstree.exp b/gcc/testsuite/lib/scanltranstree.exp
index c122abb..e4c5c90 100644
--- a/gcc/testsuite/lib/scanltranstree.exp
+++ b/gcc/testsuite/lib/scanltranstree.exp
@@ -19,6 +19,25 @@
 
 load_lib scandump.exp
 
+proc check_num_args { args } {
+set caller_args [lindex $args 0]
+set min_args [lindex $args 1]
+if { [lindex $args] >= 2 } {
+	set max_args [lindex $args 2]
+} else {
+	set max_args $min_args
+}
+set caller_fnname [lindex [info level -1] 0]
+if { [llength $caller_args] < $min_args } {
+	error "$caller_fnname: too few arguments"
+	return
+}
+if { [llength $caller_args] > $max_args } {
+	error "$caller_fnname: too many arguments"
+	return
+}
+}
+
 # Utility for scanning compiler result, invoked via dg-final.
 # Call pass if pattern is present, otherwise fail.
 #
@@ -52,14 +71,7 @@ proc scan-ltrans-tree-dump { args } {
 # Argument 3 handles expected failures and the like
 proc scan-ltrans-tree-dump-times { args } {
 
-if { [llength $args] < 3 } {
-	error "scan-ltrans-tree-dump: too few arguments"
-	return
-}
-if { [llength $args] > 4 } {
-	error "scan-ltrans-tree-dump: too many arguments"
-	return
-}
+check_num_args $args 3 4
 if { [llength $args] >= 4 } {
 	scan-dump-times "ltrans-tree" [lindex $args 0] [lindex $args 1] \
 			"\[0-9\]\[0-9\]\[0-9\]t.[lindex $args 2]" \

New template for 'gcc' made available

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.  (If you have
any questions, send them to .)

A new POT file for textual domain 'gcc' has been made available
to the language teams for translation.  It is archived as:

http://translationproject.org/POT-files/gcc-8.1-b20180401.pot

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

Below is the URL which has been provided to the translators of your
package.  Please inform the translation coordinator, at the address
at the bottom, if this information is not current:

https://gcc.gnu.org/pub/gcc/snapshots/8-20180401/gcc-8-20180401.tar.xz

Translated PO files will later be automatically e-mailed to you.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

[PATCH] Fix PR85168

[Richard Biener]

The following fixes a bad propagation of abnormals in VN valueization.

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

Richard.

2018-04-04  Richard Biener  

PR tree-optimization/85168
* tree-ssa-sccvn.c (vn_reference_maybe_forwprop_address): Avoid
propagating abnormals.

* gcc.dg/torture/pr85168.c: New testcase.

Index: gcc/tree-ssa-sccvn.c
===
--- gcc/tree-ssa-sccvn.c(revision 259024)
+++ gcc/tree-ssa-sccvn.c(working copy)
@@ -1249,7 +1249,9 @@ vn_reference_maybe_forwprop_address (vec
  return true;
}
   if (!addr_base
- || TREE_CODE (addr_base) != MEM_REF)
+ || TREE_CODE (addr_base) != MEM_REF
+ || (TREE_CODE (TREE_OPERAND (addr_base, 0)) == SSA_NAME
+ && SSA_NAME_OCCURS_IN_ABNORMAL_PHI (TREE_OPERAND (addr_base, 0
return false;
 
   off += addr_offset;
@@ -1262,6 +1264,7 @@ vn_reference_maybe_forwprop_address (vec
   ptr = gimple_assign_rhs1 (def_stmt);
   ptroff = gimple_assign_rhs2 (def_stmt);
   if (TREE_CODE (ptr) != SSA_NAME
+ || SSA_NAME_OCCURS_IN_ABNORMAL_PHI (ptr)
  || TREE_CODE (ptroff) != INTEGER_CST)
return false;
 
Index: gcc/testsuite/gcc.dg/torture/pr85168.c
===
--- gcc/testsuite/gcc.dg/torture/pr85168.c  (nonexistent)
+++ gcc/testsuite/gcc.dg/torture/pr85168.c  (working copy)
@@ -0,0 +1,30 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target indirect_jumps } */
+
+typedef struct {
+struct {
+   char a;
+} b;
+} c;
+
+int d, f;
+c *e;
+
+extern void i(void);
+extern void sejtmp () __attribute__((returns_twice));
+
+void g(void)
+{
+  c *h = e;
+  if (f)
+{
+  i();
+  h--;
+  if (d)
+   if (h->b.a)
+ i();
+}
+  if (h->b.a)
+sejtmp();
+  e = h;
+}

[wwwdocs] gcc-8/changes.html additions

[Jakub Jelinek]

Hi!

Following patch documents store merging improvements, -fsanitize=builtin,
-fsanitize=pointer-overflow and C++2A progress.

Ok for wwwdocs?

--- changes.html3 Apr 2018 06:52:04 -   1.51
+++ changes.html4 Apr 2018 07:41:06 -
@@ -113,6 +113,21 @@ a work-in-progress.
 possible for the user to have a finer-grained control over the loop
 unrolling optimization.
   
+  
+The store merging pass has been enhanced to handle bitfields and not
+just constant stores, but also data copying from adjacent memory
+locations into other adjacent memory locations, including bitwise
+logical operations on the data.  The pass can also handle byte swapping
+into memory locations.
+  
+  
+The undefined behavior sanitizer gained two new options included in
+-fsanitize=undefined: -fsanitize=builtin which
+diagnoses at runtime invalid arguments to __builtin_clz or
+__builtin_ctz prefixed builtins, and
+-fsanitize=pointer-overflow which performs cheap runtime
+tests for pointer wrapping.
+  
 
 
 
@@ -187,7 +202,17 @@ a work-in-progress.
 
 C++
 
-  
+  
+The C++ front end has experimental support for some of the upcoming C++2a
+draft features with the -std=c++2a or 
-std=gnu++2a
+flags, including designated initializers, default member initializers for
+bit-fields, __VA_OPT__ (except that
+#__VA_OPT__ is unsupported), lambda [=, this]
+captures, etc.
+For a full list of new features,
+see https://gcc.gnu.org/projects/cxx-status.html#cxx2a";>the C++
+status page.
+  
 
 
 Fortran

Jakub

Re: [PATCH, rtl] Fix PR84878: Segmentation fault in add_cross_iteration_register_deps

[Richard Biener]

On Tue, 3 Apr 2018, Peter Bergner wrote:

> On 4/3/18 1:40 PM, H.J. Lu wrote:
> > On Tue, Apr 3, 2018 at 11:36 AM, Peter Bergner  wrote:
> >> gcc/testsuite/
> >> PR rtl-optimization/84878
> >> * gcc.dg/pr84878.c: New test.
> > 
> > Wrong test filename.
> 
> Ooops, thanks for spotting that!  Will fix.

Patch is OK.

Thanks,
Richard.

Re: [wwwdocs]Mention -ftree-loop-distribution

[Gerald Pfeifer]

On Tue, 3 Apr 2018, Bin Cheng wrote:
> Option -ftree-loop-distribution is improved and enabled by default at 
> -O3 for GCC8. This patch describes the change, is it OK?

Index: htdocs/gcc-8/changes.html
===
+Classical loop nest optimization pass -ftree-loop-distribution

"The classic loop nest..." (i.e., add the article and I believe classic
is more appropriate than classical which connotates the arts,...).

+It supports loop nest distribution in some restricted scenarios; it also
+supports cancellable innermost loop distribution with loop versioning
+under runtime alias checks.

I believe that would be "run-time" (per codingconventions.html)?

Fine with the change above and considering the second comment.

Thank you,
GeraldIndex: htdocs/gcc-8/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-8/changes.html,v
retrieving revision 1.51
diff -u -r1.51 changes.html
--- htdocs/gcc-8/changes.html   3 Apr 2018 06:52:04 -   1.51
+++ htdocs/gcc-8/changes.html   3 Apr 2018 14:26:31 -
@@ -101,6 +101,13 @@
 are enabled by default at -O3 and above.
   
   
+Classical loop nest optimization pass -ftree-loop-distribution
+has been improved and enabled by default at -O3 and above.
+It supports loop nest distribution in some restricted scenarios; it also
+supports cancellable innermost loop distribution with loop versioning
+under runtime alias checks.
+  
+  
 The new option -fstack-clash-protection causes the
 compiler to insert probes whenever stack space is allocated
 statically or dynamically to reliably detect stack overflows and