Ping Re: [patch, doc] copy-edit ARC options documentation

[Sandra Loosemore]

On 02/13/2017 11:14 PM, Sandra Loosemore wrote:


2017-02-13  Sandra Loosemore  

gcc/
* doc/invoke.texi (ARC Options): Copy-edit to fix punctuation,
markup, and similar issues.  Remove @opindex entries for things
that aren't options.


Target maintainers, any comment on this patch?

-Sandra

C++ PATCH for c++/78282, auto template and pack expansion

[Jason Merrill]

When looking for parameter packs mentioned within an expression, we
were wrongly walking into the type of a TEMPLATE_DECL mentioned in the
expression.  We're only interested in packs in the type of a template
template-parameter, not other kinds of template.

Tested x86_64-pc-linux-gnu, applying to trunk.
commit 1835d19d99d5e89155c566d6305c878ca0c75678
Author: Jason Merrill 
Date:   Sun Feb 19 16:08:29 2017 -0800

PR c++/78282 - auto template and pack expansion

* pt.c (find_parameter_packs_r): Don't walk into the type of
templates other than template template-parameters.

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 0a9f5d5..2cac24f 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -3576,8 +3576,12 @@ find_parameter_packs_r (tree *tp, int *walk_subtrees, 
void* data)
   *walk_subtrees = 0;
   return NULL_TREE;
 
-case CONSTRUCTOR:
 case TEMPLATE_DECL:
+  if (!DECL_TEMPLATE_TEMPLATE_PARM_P (t))
+   return NULL_TREE;
+  gcc_fallthrough();
+
+case CONSTRUCTOR:
   cp_walk_tree (_TYPE (t),
_parameter_packs_r, ppd, ppd->visited);
   return NULL_TREE;
diff --git a/gcc/testsuite/g++.dg/cpp1y/auto-fn36.C 
b/gcc/testsuite/g++.dg/cpp1y/auto-fn36.C
new file mode 100644
index 000..f89c092
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1y/auto-fn36.C
@@ -0,0 +1,26 @@
+// PR c++/78282
+// { dg-do compile { target c++14 } }
+
+struct null_node
+{
+  null_node(const null_node&);
+};
+
+extern null_node null;
+
+template 
+auto get() { return null; }
+
+template 
+struct inheritor: Ts...
+{
+  inheritor(const inheritor& outer)
+: Ts(get())...
+{ }
+};
+
+void test()
+{
+  extern inheritor example;
+  inheritor result(example);
+}

C++ PATCH for c++/79606, ICE with this->base_member in NSDMI

[Jason Merrill]

build_base_path knows that it should limit what it tries to do within
a template, but that handling wasn't being used within an NSDMI, only
within a template function.

Tested x86_64-pc-linux-gnu, applying to trunk.
commit 7a11cba1268aa91df1bc253c43deb2dcbfd5b091
Author: Jason Merrill 
Date:   Sun Feb 19 15:55:10 2017 -0800

PR c++/79606 - ICE with this->base_member in NSDMI

* class.c (build_base_path): Check processing_template_decl.

diff --git a/gcc/cp/class.c b/gcc/cp/class.c
index 1442b55..9e4b4c4 100644
--- a/gcc/cp/class.c
+++ b/gcc/cp/class.c
@@ -375,6 +375,7 @@ build_base_path (enum tree_code code,
  set up properly yet, and the value doesn't matter there either; we're
  just interested in the result of overload resolution.  */
   if (cp_unevaluated_operand != 0
+  || processing_template_decl
   || in_template_function ())
 {
   expr = build_nop (ptr_target_type, expr);
diff --git a/gcc/testsuite/g++.dg/cpp0x/nsdmi-template16.C 
b/gcc/testsuite/g++.dg/cpp0x/nsdmi-template16.C
new file mode 100644
index 000..58dec7b
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/nsdmi-template16.C
@@ -0,0 +1,14 @@
+// PR c++/79606
+// { dg-do compile { target c++11 } }
+
+struct A
+{
+  int i = 0;
+};
+
+template struct B : A
+{
+  int j = this->i;
+};
+
+B<0> b;

C++ PATCH for c++/79607, ICE with T{} initializer

[Jason Merrill]

type_dependent_init_p was overlooking the possibility of a CONSTRUCTOR
with a dependent type, which we can get from T{}.

Tested x86_64-pc-linux-gnu, applying to trunk.
commit 060f95851e7f6d6737937b786c0a6b29cda3c454
Author: Jason Merrill 
Date:   Sun Feb 19 15:40:39 2017 -0800

PR c++/79607 - ICE with T{} initializer

* decl.c (type_dependent_init_p): Check the type of a CONSTRUCTOR.

diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index 70c44fb..e5c2bab 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -6662,6 +6662,9 @@ type_dependent_init_p (tree init)
   else if (TREE_CODE (init) == CONSTRUCTOR)
   /* A brace-enclosed initializer, e.g.: int i = { 3 }; ? */
 {
+  if (dependent_type_p (TREE_TYPE (init)))
+   return true;
+
   vec *elts;
   size_t nelts;
   size_t i;
diff --git a/gcc/testsuite/g++.dg/template/init11.C 
b/gcc/testsuite/g++.dg/template/init11.C
new file mode 100644
index 000..ef337c0
--- /dev/null
+++ b/gcc/testsuite/g++.dg/template/init11.C
@@ -0,0 +1,9 @@
+// PR c++/79607
+// { dg-do compile { target c++11 } }
+
+template struct A
+{
+  static const int i = int{T{}};
+};
+
+A a;

C++ PATCH for c++/79566, elaborated type-specifier in range for

[Jason Merrill]

In the parser, declares_class_or_enum is set to 1 for an elaborated
type-specifier, or 2 for a class or enum definition.  We only want to
complain about a type definition in the latter case.

Tested x86_64-pc-linux-gnu, applying to trunk.
commit 8b366b7f80be1f160bd31501aa436e4d300cd753
Author: Jason Merrill 
Date:   Sun Feb 19 14:52:03 2017 -0800

PR c++/79566 - elaborated-type-specifier in range for

* parser.c (cp_parser_simple_declaration): Fix check for type
definition.

diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 72597f3..0146596 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -12883,7 +12883,7 @@ cp_parser_simple_declaration (cp_parser* parser,
break;
   else if (maybe_range_for_decl)
{
- if (declares_class_or_enum && token->type == CPP_COLON)
+ if ((declares_class_or_enum & 2) && token->type == CPP_COLON)
permerror (decl_specifiers.locations[ds_type_spec],
   "types may not be defined in a for-range-declaration");
  break;
diff --git a/gcc/testsuite/g++.dg/cpp0x/range-for34.C 
b/gcc/testsuite/g++.dg/cpp0x/range-for34.C
new file mode 100644
index 000..2041848
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/range-for34.C
@@ -0,0 +1,16 @@
+// PR c++/79566
+// { dg-do compile { target c++11 } }
+
+struct X {
+  struct Y { };
+
+  Y* begin();
+  Y* end();
+};
+
+void f()
+{
+  X x;
+  for (struct X::Y& y : x)
+;
+}

C++ PATCH for c++/79400, confusing suggestion of 'noexcept'

[Jason Merrill]

It was pointed out that suggesting noexcept as an alternative to
throw(type) doesn't make much sense, since throw(type) would imply
noexcept(false), which is the default.  So let's just remove the
suggestion.

Tested x86_64-pc-linux-gnu, applying to trunk.
commit 41d5a30463d1f62dfb64ec953b662e1eda5faf74
Author: Jason Merrill 
Date:   Sun Feb 19 14:47:17 2017 -0800

PR c++/79400 - confusing suggestion of 'noexcept'

* parser.c (cp_parser_exception_specification_opt): Remove
suggestion for deprecated dynamic exception-specification.

diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 4656b4f..72597f3 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -23926,8 +23926,8 @@ cp_parser_exception_specification_opt (cp_parser* 
parser)
}
   else if (cxx_dialect >= cxx11 && !in_system_header_at (loc))
warning_at (loc, OPT_Wdeprecated,
-   "dynamic exception specifications are deprecated in C++11;"
-   " use % instead");
+   "dynamic exception specifications are deprecated in "
+   "C++11");
 }
   /* In C++17, throw() is equivalent to noexcept (true).  throw()
  is deprecated in C++11 and above as well, but is still widely used,

C++ PATCH for c++/79470, partial ordering with reference parameters

[Jason Merrill]

We have code in unify to handle the implicit indirection through a
reference, but it couldn't handle when that indirection was wrapped in
an EXPR_PACK_EXPANSION.

Tested x86_64-pc-linux-gnu, applying to trunk.
commit 75e6ade977ea2d229d5ccd4fdaaf812c634c4d41
Author: Jason Merrill 
Date:   Sun Feb 19 14:28:39 2017 -0800

PR c++/79470 - partial ordering with reference parameters

* pt.c (unify) [INDIRECT_REF]: Handle pack expansions.

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 46e6498..0a9f5d5 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -20918,8 +20918,13 @@ unify (tree tparms, tree targs, tree parm, tree arg, 
int strict,
 case INDIRECT_REF:
   if (REFERENCE_REF_P (parm))
{
+ bool pexp = PACK_EXPANSION_P (arg);
+ if (pexp)
+   arg = PACK_EXPANSION_PATTERN (arg);
  if (REFERENCE_REF_P (arg))
arg = TREE_OPERAND (arg, 0);
+ if (pexp)
+   arg = make_pack_expansion (arg);
  return unify (tparms, targs, TREE_OPERAND (parm, 0), arg,
strict, explain_p);
}
diff --git a/gcc/testsuite/g++.dg/cpp0x/variadic-ref1.C 
b/gcc/testsuite/g++.dg/cpp0x/variadic-ref1.C
new file mode 100644
index 000..441d386
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/variadic-ref1.C
@@ -0,0 +1,10 @@
+// PR c++/79470
+// { dg-do compile { target c++11 } }
+
+template < const int&... > struct AA;
+
+template < > struct AA<> { };
+
+template < const int& II, const int&... Is >
+struct AA { };
+

C++ PATCH for c++/79500, ICE with non-template deduction guide

[Jason Merrill]

DECL_TEMPLATE_RESULT doesn't work on a non-template, so let's use
STRIP_TEMPLATE instead.

Tested x86_64-pc-linux-gnu, applying to trunk.
commit 9f99104a12b72006253c0ce5f0b046ada82eb354
Author: Jason Merrill 
Date:   Sun Feb 19 14:01:51 2017 -0800

PR c++/79500 - ICE with non-template deduction guide

* pt.c (do_class_deduction): Use STRIP_TEMPLATE rather than
DECL_TEMPLATE_RESULT.

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 9e6ce8d..46e6498 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -25118,7 +25118,7 @@ do_class_deduction (tree ptype, tree tmpl, tree init, 
int flags,
 {
   tree t = cands;
   for (; t; t = OVL_NEXT (t))
-   if (DECL_NONCONVERTING_P (DECL_TEMPLATE_RESULT (OVL_CURRENT (t
+   if (DECL_NONCONVERTING_P (STRIP_TEMPLATE (OVL_CURRENT (t
  break;
   if (t)
{
@@ -25126,7 +25126,7 @@ do_class_deduction (tree ptype, tree tmpl, tree init, 
int flags,
  for (t = cands; t; t = OVL_NEXT (t))
{
  tree f = OVL_CURRENT (t);
- if (!DECL_NONCONVERTING_P (DECL_TEMPLATE_RESULT (f)))
+ if (!DECL_NONCONVERTING_P (STRIP_TEMPLATE (f)))
pruned = build_overload (f, pruned);
}
  cands = pruned;
diff --git a/gcc/testsuite/g++.dg/cpp1z/class-deduction29.C 
b/gcc/testsuite/g++.dg/cpp1z/class-deduction29.C
new file mode 100644
index 000..efffe3d
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1z/class-deduction29.C
@@ -0,0 +1,6 @@
+// PR c++/79500
+// { dg-options -std=c++1z }
+
+template struct A {};
+A(...) -> A;
+A a = {};

C++ PATCH for c++/79580, ICE with compound literal

[Jason Merrill]

We were treating a compound literal type defined in the initializer
for a static data member as though it were a member of the class.
Fixed by ignoring classes when defining a type from within an
expression.

Tested x86_64-pc-linux-gnu, applying to trunk.
commit 23c08aed737764678bbe1af31ddaa16b2d0a4061
Author: Jason Merrill 
Date:   Sun Feb 19 16:50:38 2017 -0500

PR c++/79580 - ICE with compound literal

* parser.c (cp_parser_class_head): If we're in the middle of an
expression, use ts_within_enclosing_non_class.

diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index feeafce..4656b4f 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -22771,7 +22771,10 @@ cp_parser_class_head (cp_parser* parser,
   /* If the class was unnamed, create a dummy name.  */
   if (!id)
id = make_anon_name ();
-  type = xref_tag (class_key, id, /*tag_scope=*/ts_current,
+  tag_scope tag_scope = (parser->in_type_id_in_expr_p
+? ts_within_enclosing_non_class
+: ts_current);
+  type = xref_tag (class_key, id, tag_scope,
   parser->num_template_parameter_lists);
 }
 
diff --git a/gcc/testsuite/g++.dg/ext/complit15.C 
b/gcc/testsuite/g++.dg/ext/complit15.C
new file mode 100644
index 000..f12752d
--- /dev/null
+++ b/gcc/testsuite/g++.dg/ext/complit15.C
@@ -0,0 +1,8 @@
+// PR c++/79580
+// { dg-options "-flto -std=c++98" }
+
+class a
+{
+  static const double b;
+};
+const double a::b ((union { double c; }){}.c);

C++ PATCH for c++/79503 (inherited ctor taking base class)

[Jason Merrill]

In the old inheriting constructor scheme, copy constructors were not
inherited.  In the new scheme we needed a rule to get a similar
effect; I proposed that an inherited constructor should not be viable
if it has a single parameter of a type reference-related to the
derived type.  Richard Smith proposed a further refinement that this
would apply only if the base type is also reference-related to the
parameter type.  This testcase demonstrates why this refinement is
needed.

Tested x86_64-pc-linux-gnu, applying to trunk.
commit 5e1645da2601d0c31a2fd0a5687224d6e3087824
Author: Jason Merrill 
Date:   Sun Feb 19 16:22:43 2017 -0500

PR c++/79503 - inherited ctor taking base class

* call.c (add_function_candidate): Also check that
DECL_INHERITED_CTOR_BASE is reference-related to the parameter type.

diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index 4ef444b..d6d3a8f 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -2057,7 +2057,9 @@ add_function_candidate (struct z_candidate **candidates,
 {
   tree ptype = non_reference (TREE_VALUE (parmlist));
   tree dtype = DECL_CONTEXT (fn);
-  if (reference_related_p (ptype, dtype))
+  tree btype = DECL_INHERITED_CTOR_BASE (fn);
+  if (reference_related_p (ptype, dtype)
+ && reference_related_p (btype, ptype))
{
  viable = false;
  reason = inherited_ctor_rejection ();
diff --git a/gcc/testsuite/g++.dg/cpp0x/inh-ctor26.C 
b/gcc/testsuite/g++.dg/cpp0x/inh-ctor26.C
new file mode 100644
index 000..e1e6b9e
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/inh-ctor26.C
@@ -0,0 +1,21 @@
+// PR c++/79503
+// { dg-do compile { target c++11 } }
+
+struct payload {};
+
+struct base: private payload {
+base(payload) {}
+};
+
+struct derived: base {
+using base::base;
+};
+
+int main()
+{
+payload data;
+// error: no matching function for call to 'derived::derived(payload&)'
+// note: candidate: base::base(payload)
+// note:   an inherited constructor is not a candidate for initialization 
from an expression of the same or derived type
+derived demo(data);
+}

Re: [wwwdocs] Document in changes.html -fcode-hoisting, -fipa-bit-cp, -fipa-vrp, -fsplit-loops, GCJ removal, x86 ISA additions, -fshrink-wrap-separate etc.

[Gerald Pfeifer]

That was quite a bit; thanks for doing that, Jakub!

In the patch below I try to streamline language a bit, document options 
being implied by -Os (in addition to -O2 or higher), fix grammar in a few 
places, and change a textual link to being a real one.

I have _not_ applied this yet, and would appreciate your feedback.

Gerald

Index: changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-7/changes.html,v
retrieving revision 1.65
diff -u -r1.65 changes.html
--- changes.html19 Feb 2017 21:55:56 -  1.65
+++ changes.html19 Feb 2017 22:00:59 -
@@ -50,41 +50,44 @@
 -fprintf-return-value option.
   A new store merging pass has been added.  It merges constant stores to
   adjacent memory locations into fewer, wider, stores.
-  It can be enabled by using the -fstore-merging option and is
+  It is enabled by the -fstore-merging option and is
   enabled by default at the -O2 optimization
-  level or higher (including -Os).
+  level or higher (and -Os).
 
   A new code hoisting optimization has been added to the partial
   redundancy elimination pass.  It attempts to move evaluation of
   expressions executed on all paths to the function exit as early as
   possible, which helps primarily for code size, but can be useful for
-  speed of generated code as well.  It can be enabled by using the
+  speed of generated code as well.  It is enabled by the
   -fcode-hoisting option and is enabled by default at
-  the -O2 optimization level or higher.
+  the -O2 optimization level or higher (and
+  -Os).
 
   A new interprocedural bitwise constant propagation optimization
   has been added, which propagates knowledge about which bits of variables
   are known to be zero (including pointer alignment information) across
-  the call graph.  It can be enabled by using the -fipa-bit-cp
+  the call graph.  It is enabled by the -fipa-bit-cp
   option if -fipa-cp is enabled as well, and is enabled by
-  default at the -O2 optimization level and higher.
+  default at the -O2 optimization level and higher (and
+  -Os).
 
   A new interprocedural value range propagation optimization has been
   added, which propagates integral ranges that variable values can be proven
-  to be within across the call graph.  It can be enabled by using the
+  to be within across the call graph.  It is enabled by the
   -fipa-vrp option and is enabled by default at the
-  -O2 optimization level and higher.
+  -O2 optimization level and higher (and
+  -Os).
 
   A new loop splitting optimization pass has been added.  It splits
   certain loops if they contain a condition that is always true on one
   side of the iteration space and always false on the other into two
   loops where each of the new two loops iterates just on one of the sides
   of the iteration space and the condition does not need to be checked
-  inside of the loop.  It can be enabled by using the
+  inside of the loop.  It is enabled by the
   -fsplit-loops option and is enabled by default at the
   -O3 optimization level or higher.
 
-  Shrink-wrapping optimization can now separate portions of
+  The shrink-wrapping optimization can now separate portions of
   prologues and epilogues to improve performance if some of the
   work done traditionally by prologues and epilogues is not needed
   on certain paths.  This is controlled by the
@@ -138,7 +141,7 @@
   
 
   The -fsanitize=signed-integer-overflow suboption of the
-  UndefinedBehavior Sanitizer now diagnose arithmetic overflows even on
+  UndefinedBehavior Sanitizer now diagnoses arithmetic overflows even on
   arithmetic operations with generic vectors.
 
   Version 5 of the New __builtin_add_overflow_p,
   __builtin_sub_overflow_p,
   __builtin_mul_overflow_p built-in functions have been added.
-  These work similarly to earlier added built-in functions without the
-  _p suffix, but don't actually store the result of the
+  These work similarly to their siblings without the
+  _p suffix, but do not actually store the result of the
   arithmetics anywhere, just return whether the operation would overflow.
   These builtins allow easy checking for overflows e.g. in C++
   constexpr contexts.
@@ -566,7 +569,7 @@
   (suffixed fN or fNx) for the
   new
   types: __builtin_copysign, __builtin_fabs, 
__builtin_huge_val, __builtin_inf, 
__builtin_nan, __builtin_nans.
-  Compilation with -fopenmp is now compatible with
+  Compilation with -fopenmp is now compatible with the
   C11 _Atomic keyword.
 
 
@@ -730,8 +733,8 @@
   
   Version 4.5 of the http://www.openmp.org/specifications/;
   >OpenMP specification is now partially supported also in the
-  Fortran compilers, largest missing support in the Fortran frontend
-  is structure element mapping.
+  Fortran compiler; the largest missing item is structure element
+  mapping.
   
   User-defined derived-type input/output (UDTIO) is added.
   
@@ -752,11 +755,13 @@
 
 
 

[wwwdocs] PATCH Re: DWARF Version 5 Standard Released

[Gerald Pfeifer]

On Wed, 15 Feb 2017, Michael Eager wrote:
> The DWARF Debugging Information Format Standards Committee is pleased 
> to announce the availability of Version 5 of the DWARF Debugging Format 
> Standard.

This patch, which I just applied, updates the GCC 7 release notes 
accordingly.

(Now it's only GCC 7 that is upcoming, not DWARF 5 as well. ;-)

Gerald

Index: changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-7/changes.html,v
retrieving revision 1.64
diff -u -r1.64 changes.html
--- changes.html16 Feb 2017 17:46:55 -  1.64
+++ changes.html19 Feb 2017 21:54:05 -
@@ -141,7 +141,7 @@
   UndefinedBehavior Sanitizer now diagnose arithmetic overflows even on
   arithmetic operations with generic vectors.
 
-  The upcoming version 5 of the Version 5 of the http://www.dwarfstd.org/Download.php;>DWARF debugging
   information standard is supported through the -gdwarf-5
   option.  The DWARF version 4 debugging information remains the

Re: [C++ RFC] Fix up attribute handling in templates (PR c++/79502)

[Martin Sebor]

On 02/17/2017 09:53 PM, Jason Merrill wrote:

On Thu, Feb 16, 2017 at 6:13 PM, Martin Sebor  wrote:

On 02/16/2017 12:49 PM, Jason Merrill wrote:


On Thu, Feb 16, 2017 at 11:33 AM, Jakub Jelinek  wrote:


PR c++/79502
* pt.c (apply_late_template_attributes): If there are
no dependent attributes, set *p to attributes.  If there were
some attributes in *p previously with or without dependent
attributes, chain them after the new attributes.



Here's the variant of your patch that I'm applying.



Sorry to butt in but I feel like I'm missing something basic.  Are
these attributes (nodiscard, noreturn, maybe_unused, and deprecated)
meant to apply to templates?  The text in for nodiscard suggests
they're not:

  The attribute-token nodiscard may be applied to the declarator-id
  in a function declaration or to the declaration of a class or
  enumeration.

Noreturn also doesn't mention templates:

  The attribute may be applied to the declarator-id in a function
  declaration.

Deprecated explicitly mentions template specializations but not
primary templates:

  The attribute may be applied to the declaration of a class,
   a typedef-name, a variable, a non-static data member, a function,
   a namespace, an enumeration, an enumerator, or a template
   specialization.

I can certainly see how applying attributes to the primary template
would be useful so it's puzzling to me that the standard seems to
preclude it.


I don't think it's precluded; a /template-declaration/ syntactically
includes a /declaration/, so in general any statement about e.g. a
function declaration also applies to a function template declaration.


I'm sure you're right that it's not meant to be precluded, otherwise
the standard library couldn't declare noreturn the throw_with_nested
function template (the only template declared noreturn in the library
I could find).

FWIW, a context where noreturn clearly is not applicable is function
pointers.  G++ accepts it there but then ignores it.  Clang rejects
it.  I would think accepting it on function pointers would be useful
as well.  GCC (in C mode) accepts __attribute__ noreturn on function
pointers and treats them as such (G++ does not).

Another interesting context is the explicit instantiation directive.
Again, the standard seems clear that noreturn isn't allowed but GCC
and Microsoft Visual C++ both accept it. Clang and EDG reject it.
I think rejecting it here makes sense and accepting is a bug.


I ask also because I was just looking at bug 79021 and scratching
my head about what to thing about it.   While trying to understand
how GCC handles attributes for the primary template I came across
what doesn't make sense to me.   Why would it apply the attribute
from the primary to the explicit specialization when the two are
distinct entities?  Is that a bug?


This seems like a Core issue; the standard says nothing about how
attributes on a template affect specializations.


Yes, I thought so as well.  Thanks for confirming that.  Unless
you would prefer to bring it up yourself let me post it to the
core reflector and suggest to open a new issue for it.


I think that as a general rule, not applying attributes from the
template to specializations makes sense.  There will be some
exceptions, such as the abi_tag attribute which is a property of the
name rather than a particular declaration.


That makes sense to me.

Thanks
Martin

Re: [Patch, fortran] PR79447 - [F08] gfortran rejects valid & accepts invalid internal subprogram in a submodule

[Paul Richard Thomas]

Hi Jerry,

Committed as revision 245582.

Thanks for the review.

Paul

On 16 February 2017 at 00:37, Jerry DeLisle  wrote:
> On 02/15/2017 10:01 AM, Paul Richard Thomas wrote:
>> Dear All,
>>
>> This patch is straightforward, verging on 'obvious'.
>>
>> Bootstraps and regtests on FC23/x86_64 - OK for trunk and 6 branch?
>>
> Yes, OK
>
> Jerry



-- 
"If you can't explain it simply, you don't understand it well enough"
- Albert Einstein

Re: [Ping, PATCH, Fortran, 79229, v1] [7 Regression] ICE in gfc_trans_assignment_1 with -fcheck=mem

[Andre Vehreschild]

Hi Jerry, hi all,

thanks for the review. Committed as r245581.

Regards,
Andre

On Sun, 19 Feb 2017 08:58:46 -0800
Jerry DeLisle  wrote:

> On 02/19/2017 08:42 AM, Andre Vehreschild wrote:
> > Ping!
> >
> > this time with correct PR number: 79229.
> >
> > On Tue, 7 Feb 2017 08:31:22 +0100
> > Andre Vehreschild  wrote:
> >  
> >> Hi all,
> >>
> >> attached patch fixes the issue of 79229 (which is not a regression).
> >> The issue was that the code generating the checking was expecting a
> >> pointer type, but got an indirect ref to it. This is fixed now.
> >>
> >> Bootstraps and regtests ok on x86_64-linux/f25. Ok for trunk?
> >>
> >> Regards,
> >>Andre  
> >
> >  
> 
> This is OK,
> 
> Jerry


-- 
Andre Vehreschild * Email: vehre ad gmx dot de 
Index: gcc/fortran/ChangeLog
===
--- gcc/fortran/ChangeLog	(Revision 245580)
+++ gcc/fortran/ChangeLog	(Arbeitskopie)
@@ -7,6 +7,12 @@
 
 2017-02-19  Andre Vehreschild  
 
+	PR fortran/79229
+	* trans-expr.c (gfc_trans_assignment_1): Deref indirect refs when
+	compiling with -fcheck=mem to check the pointer and not the data.
+
+2017-02-19  Andre Vehreschild  
+
 	PR fortran/79335
 	* trans-array.c (duplicate_allocatable_coarray): Ensure attributes
 	passed are properly initialized.
Index: gcc/fortran/trans-expr.c
===
--- gcc/fortran/trans-expr.c	(Revision 245580)
+++ gcc/fortran/trans-expr.c	(Arbeitskopie)
@@ -9961,13 +9961,16 @@
 	  tree cond;
 	  const char* msg;
 
+	  tmp = INDIRECT_REF_P (lse.expr)
+	  ? gfc_build_addr_expr (NULL_TREE, lse.expr) : lse.expr;
+
 	  /* We should only get array references here.  */
-	  gcc_assert (TREE_CODE (lse.expr) == POINTER_PLUS_EXPR
-		  || TREE_CODE (lse.expr) == ARRAY_REF);
+	  gcc_assert (TREE_CODE (tmp) == POINTER_PLUS_EXPR
+		  || TREE_CODE (tmp) == ARRAY_REF);
 
 	  /* 'tmp' is either the pointer to the array(POINTER_PLUS_EXPR)
 	 or the array itself(ARRAY_REF).  */
-	  tmp = TREE_OPERAND (lse.expr, 0);
+	  tmp = TREE_OPERAND (tmp, 0);
 
 	  /* Provide the address of the array.  */
 	  if (TREE_CODE (lse.expr) == ARRAY_REF)
Index: gcc/testsuite/ChangeLog
===
--- gcc/testsuite/ChangeLog	(Revision 245580)
+++ gcc/testsuite/ChangeLog	(Arbeitskopie)
@@ -1,3 +1,8 @@
+2017-02-19  Andre Vehreschild  
+
+	PR fortran/79229
+	* gfortran.dg/class_allocate_24.f90: New test.
+
 2017-02-19  Paul Thomas  
 
 	PR fortran/79402
Index: gcc/testsuite/gfortran.dg/class_allocate_24.f90
===
--- gcc/testsuite/gfortran.dg/class_allocate_24.f90	(nicht existent)
+++ gcc/testsuite/gfortran.dg/class_allocate_24.f90	(Arbeitskopie)
@@ -0,0 +1,16 @@
+! { dg-do compile }
+! { dg-options "-fcheck=mem" }
+! 
+! Compile time check only, to test that the ICE is fixed in the assignment of the
+! default initializer of the class to sf.
+
+implicit none
+
+type :: t
+  integer, pointer :: data => null ()
+end type
+
+class(t), dimension(:), allocatable :: sf
+allocate (t :: sf (1))
+end
+

Re: Ping [Patch, fortran] PR79402 - ICE with submodules: module procedure interface defined in parent module

[Paul Richard Thomas]

Hi Everybody,

With Jerry's OK for a commit to trunk, committed as revision 245580.

I will wait a few weeks before a commit to 6-branch.

Cheers


Paul

On 11 February 2017 at 13:24, Paul Richard Thomas
 wrote:
> Ping!
>
> On 8 February 2017 at 16:00, Paul Richard Thomas
>  wrote:
>> Dear All,
>>
>> The attached rework of the patch functions in the same way as
>> yesterday's but is based in resolve.c rather than trans-decl.c. It
>> looks to me to be by far cleaner.
>>
>> Bootstraps and regtests on FC23/x86_64 - OK for trunk?
>>
>> Cheers
>>
>> Paul
>>
>> 2017-02-08  Paul Thomas  
>>
>> PR fortran/79344
>> * resolve.c (fixup_unique_dummy): New function.
>> (gfc_resolve_expr): Call it for dummy variables with a unique
>> symtree name.
>>
>> 2017-02-08  Paul Thomas  
>>
>> PR fortran/79344
>> * gfortran.dg/submodule_23.f90: New test.
>>
>>
>>
>> On 7 February 2017 at 16:06, Paul Richard Thomas
>>  wrote:
>>> Dear All,
>>>
>>> This bug generates an ICE because the symbol for dummy 'n' in the
>>> specification expression for the result of 'fun1' is not the same as
>>> the symbol in the formal arglist. For some reason that I have been
>>> unable to uncover, this false dummy is associated with a unique
>>> symtree. The odd thing is that the dump of the parse tree for the
>>> failing module procedure case is identical to that where the interface
>>> is explcitely reproduced in the submodule. The cause of the ICE is
>>> that the false dummy has no backend_decl as it should.
>>>
>>> This patch hits the problem directly on the head by using the
>>> backend_decl from the symbol in the namespace of the formal arglist,
>>> as described in the comment in the patch. If it is deemed to be more
>>> hygenic, the chunk of code can be lifted out and deposited in a
>>> separate function.
>>>
>>> Bootstraps and regtests on FC23/x86_64 - OK for trunk?
>>>
>>> Cheers
>>>
>>> Paul
>>>
>>> 2017-02-07  Paul Thomas  
>>>
>>> PR fortran/79344
>>> * trans-decl.c (gfc_get_symbol_decl): If a dummy apparently has
>>> a null backend_decl, look for a replacement symbol in the
>>> namespace of the 1st formal argument and use its backend_decl.
>>>
>>> 2017-02-07  Paul Thomas  
>>>
>>> PR fortran/79344
>>> * gfortran.dg/submodule_23.f90: New test.
>>
>>
>>
>> --
>> "If you can't explain it simply, you don't understand it well enough"
>> - Albert Einstein
>
>
>
> --
> "If you can't explain it simply, you don't understand it well enough"
> - Albert Einstein



-- 
"If you can't explain it simply, you don't understand it well enough"
- Albert Einstein

Re: [RFC PATCH, i386]: Use "lock orl $0, -4(%esp)" in mfence_nosse

[Uros Bizjak]

On Fri, Feb 17, 2017 at 5:59 PM, Uros Bizjak  wrote:
> On Fri, Feb 17, 2017 at 5:30 PM, Jakub Jelinek  wrote:
>> On Sun, May 29, 2016 at 11:10:15PM +0200, Uros Bizjak wrote:
>>> As explained in PR71245, comment #3 [1], it is better to use offset -4
>>> to a %esp to implement a non-SSE memory fence instruction:
>>>
>>> -q-
>>>
>>> I guess it costs a code byte for a disp8 in the addressing mode, but
>>> it avoids adding a lot of latency to a critical path involving a
>>> spill/reload to (%esp), in functions where there is something at
>>> (%esp).
>>>
>>> If it's an object larger than 4B, the lock orl could even cause a
>>> store-forwarding stall when the object is reloaded.  (e.g. a double or
>>> a vector).
>>>
>>> Ideally we could do the  lock orl  on some padding between two locals,
>>> or on something in memory that wasn't going to be loaded soon, to
>>> avoid touching more stack memory (which might be in the next page
>>> down).  But we still want to do it on a cache line that's hot, so
>>> going way up above our own stack frame isn't good either.
>>
>> Unfortunately this makes valgrind unhappy about that:
>> https://bugzilla.redhat.com/show_bug.cgi?id=1423434
>> I assume it will complain now on anything pre-SSE2 that contains the memory
>> barrier in 32-bit code.
>> Perhaps we should decrement and increment %esp around it or something
>> similar (or push/pop)?  Of course, that would mean we need to take care
>> of async unwind info.
>
> Or, we can simply revert the patch? Not that the barrier performance
> of non-SSE 32bit targets matter...

Attached patch was committed to mainline to revert 2016-05-30 change.

2017-02-19  Uros Bizjak  

Revert:
2016-05-30  Uros Bizjak  

* config/i386/sync.md (mfence_nosse): Use "lock orl $0, -4(%esp)".

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

Uros.

--cut here--
Index: config/i386/sync.md
===
--- config/i386/sync.md (revision 245574)
+++ config/i386/sync.md (working copy)
@@ -98,7 +98,7 @@
(unspec:BLK [(match_dup 0)] UNSPEC_MFENCE))
(clobber (reg:CC FLAGS_REG))]
   "!(TARGET_64BIT || TARGET_SSE2)"
-  "lock{%;} or{l}\t{$0, -4(%%esp)|DWORD PTR [esp-4], 0}"
+  "lock{%;} or{l}\t{$0, (%%esp)|DWORD PTR [esp], 0}"
   [(set_attr "memory" "unknown")])

--cut here--

Re: [Ping, PATCH, Fortran, 79229, v1] [7 Regression] ICE in gfc_trans_assignment_1 with -fcheck=mem

[Jerry DeLisle]

On 02/19/2017 08:42 AM, Andre Vehreschild wrote:

Ping!

this time with correct PR number: 79229.

On Tue, 7 Feb 2017 08:31:22 +0100
Andre Vehreschild  wrote:


Hi all,

attached patch fixes the issue of 79229 (which is not a regression).
The issue was that the code generating the checking was expecting a
pointer type, but got an indirect ref to it. This is fixed now.

Bootstraps and regtests ok on x86_64-linux/f25. Ok for trunk?

Regards,
Andre





This is OK,

Jerry

Re: [Ping, PATCH, Fortran, 79229, v1] [7 Regression] ICE in gfc_trans_assignment_1 with -fcheck=mem

[Andre Vehreschild]

Ping!

this time with correct PR number: 79229.

On Tue, 7 Feb 2017 08:31:22 +0100
Andre Vehreschild  wrote:

> Hi all,
> 
> attached patch fixes the issue of 79229 (which is not a regression).
> The issue was that the code generating the checking was expecting a
> pointer type, but got an indirect ref to it. This is fixed now.
> 
> Bootstraps and regtests ok on x86_64-linux/f25. Ok for trunk?
> 
> Regards,
>   Andre


-- 
Andre Vehreschild * Email: vehre ad gmx dot de 
gcc/testsuite/ChangeLog:

2017-02-07  Andre Vehreschild  

PR fortran/79229
* gfortran.dg/class_allocate_24.f90: New test.


gcc/fortran/ChangeLog:

2017-02-07  Andre Vehreschild  

PR fortran/79229
* trans-expr.c (gfc_trans_assignment_1): Deref indirect refs when
compiling with -fcheck=mem to check the pointer and not the data.

diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c
index 138af56..fcd6f16 100644
--- a/gcc/fortran/trans-expr.c
+++ b/gcc/fortran/trans-expr.c
@@ -9959,13 +9959,16 @@ gfc_trans_assignment_1 (gfc_expr * expr1, gfc_expr * expr2, bool init_flag,
 	  tree cond;
 	  const char* msg;
 
+	  tmp = INDIRECT_REF_P (lse.expr)
+	  ? gfc_build_addr_expr (NULL_TREE, lse.expr) : lse.expr;
+
 	  /* We should only get array references here.  */
-	  gcc_assert (TREE_CODE (lse.expr) == POINTER_PLUS_EXPR
-		  || TREE_CODE (lse.expr) == ARRAY_REF);
+	  gcc_assert (TREE_CODE (tmp) == POINTER_PLUS_EXPR
+		  || TREE_CODE (tmp) == ARRAY_REF);
 
 	  /* 'tmp' is either the pointer to the array(POINTER_PLUS_EXPR)
 	 or the array itself(ARRAY_REF).  */
-	  tmp = TREE_OPERAND (lse.expr, 0);
+	  tmp = TREE_OPERAND (tmp, 0);
 
 	  /* Provide the address of the array.  */
 	  if (TREE_CODE (lse.expr) == ARRAY_REF)
diff --git a/gcc/testsuite/gfortran.dg/class_allocate_24.f90 b/gcc/testsuite/gfortran.dg/class_allocate_24.f90
new file mode 100644
index 000..883247d
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/class_allocate_24.f90
@@ -0,0 +1,16 @@
+! { dg-do compile }
+! { dg-options "-fcheck=mem" }
+! 
+! Compile time check only, to test that the ICE is fixed in the assignment of the
+! default initializer of the class to sf.
+
+implicit none
+
+type :: t
+  integer, pointer :: data => null ()
+end type
+
+class(t), dimension(:), allocatable :: sf
+allocate (t :: sf (1))
+end
+

Re: gcc.css colors

[Gerald Pfeifer]

Hi Markus,

On Wed, 1 Feb 2017, Markus Trippelsdorf wrote:
> Some colors on e.g. https://gcc.gnu.org/gcc-7/changes.html are nearly
> unreadable. So what about the following patch?
> 
> -.boldcyan{ font-weight:bold; color:cyan; }
> -.boldlime{ font-weight:bold; color:lime; }
> +.boldcyan{ font-weight:bold; color:#25a9a9; }
> +.boldlime{ font-weight:bold; color:green;}

just want to follow-up on this and the discussion that ensued.

Based on the feedback you got from Jakub and others, I am not
comfortable making this change (so if we had a patch tracker,
would label this as "declined").

Gerald

Re: [v3 PATCH] Implement C++17 GB50 resolution

[Jonathan Wakely]

On 18/02/17 20:48 +, Dinka Ranns wrote:

Comments addressed. Please find the new diff attached to this e-mail.

Changelog after review comments :

2017-02-18 Dinka Ranns 


GNU ChangeLog rules say two spaces after the date and after your name.


   C++17 GB50 resolution
   * include/std/chrono:
   (duration::operator++()): Add _GLIBCXX17_CONSTEXPR.
   (duration::operator++(int)): Likewise
   (duration::operator--()): Likewise
   (duration::operator--(int)): Likewise
   (duration::operator+=(const duration&)): Likewise
   (duration::operator-=(const duration&)): Likewise
   (duration::operator*=(const rep&)): Likewise
   (duration::operator/=(const rep&)): Likewise
   (duration::operator%=(const rep&)): Likewise
   (duration::operator%=(const duration&)): Likewise
   (time_point::operator+=(const duration&)): Likewise
   (time_point::operator-=(const duration&)): Likewise

   * testsuite/20_util/duration/arithmetic/constexpr_c++17.cc: new tests
   * testsuite/20_util/time_point/arithmetic/constexpr.cc: new tests


I also tweaked the ChangeLog entry to add some full stops.


@@ -401,7 +401,7 @@ _GLIBCXX_END_NAMESPACE_VERSION

// DR 934.
template
- typename enable_if::value,
+ _GLIBCXX17_CONSTEXPR typename 
enable_if::value,
 duration&>::type
  operator%=(const rep& __rhs)
  {
@@ -410,7 +410,7 @@ _GLIBCXX_END_NAMESPACE_VERSION
  }

template
- typename enable_if::value,
+ _GLIBCXX17_CONSTEXPR typename 
enable_if::value,
 duration&>::type
  operator%=(const duration& __d)
  {


I added line breaks to these two signatures to keep the line shorter
than 80 columns, and to keep the "duration&" lined up with the first
argument to enable_if. That meant 20_util/duration/literals/range.cc
started to FAIL because the expected error was on a different line, so
I adjusted that test. 


The attached patch includes those tweaks and is what I've tested and
committed. Thanks for your first contribution to libstdc++!


commit eac82ba48c414d10806453a68785225dc4f86971
Author: Jonathan Wakely 
Date:   Sun Feb 19 14:19:17 2017 +

C++17 GB50 resolution (P0505R0)

2017-02-19  Dinka Ranns  

	C++17 GB50 resolution
	* include/std/chrono (duration::operator++()): Add
	_GLIBCXX17_CONSTEXPR.
	(duration::operator++(int)): Likewise.
	(duration::operator--()): Likewise.
	(duration::operator--(int)): Likewise.
	(duration::operator+=(const duration&)): Likewise.
	(duration::operator-=(const duration&)): Likewise.
	(duration::operator*=(const rep&)): Likewise.
	(duration::operator/=(const rep&)): Likewise.
	(duration::operator%=(const rep&)): Likewise.
	(duration::operator%=(const duration&)): Likewise.
	(time_point::operator+=(const duration&)): Likewise.
	(time_point::operator-=(const duration&)): Likewise.
	* testsuite/20_util/duration/arithmetic/constexpr_c++17.cc: New test.
	* testsuite/20_util/duration/literals/range.cc: Adjust dg-error.
	* testsuite/20_util/time_point/arithmetic/constexpr.cc: New test.

diff --git a/libstdc++-v3/include/std/chrono b/libstdc++-v3/include/std/chrono
index 2c33be0..b3dc430 100644
--- a/libstdc++-v3/include/std/chrono
+++ b/libstdc++-v3/include/std/chrono
@@ -349,50 +349,50 @@ _GLIBCXX_END_NAMESPACE_VERSION
 	operator-() const
 	{ return duration(-__r); }
 
-	duration&
+	_GLIBCXX17_CONSTEXPR duration&
 	operator++()
 	{
 	  ++__r;
 	  return *this;
 	}
 
-	duration
+	_GLIBCXX17_CONSTEXPR duration
 	operator++(int)
 	{ return duration(__r++); }
 
-	duration&
+	_GLIBCXX17_CONSTEXPR duration&
 	operator--()
 	{
 	  --__r;
 	  return *this;
 	}
 
-	duration
+	_GLIBCXX17_CONSTEXPR duration
 	operator--(int)
 	{ return duration(__r--); }
 
-	duration&
+	_GLIBCXX17_CONSTEXPR duration&
 	operator+=(const duration& __d)
 	{
 	  __r += __d.count();
 	  return *this;
 	}
 
-	duration&
+	_GLIBCXX17_CONSTEXPR duration&
 	operator-=(const duration& __d)
 	{
 	  __r -= __d.count();
 	  return *this;
 	}
 
-	duration&
+	_GLIBCXX17_CONSTEXPR duration&
 	operator*=(const rep& __rhs)
 	{
 	  __r *= __rhs;
 	  return *this;
 	}
 
-	duration&
+	_GLIBCXX17_CONSTEXPR duration&
 	operator/=(const rep& __rhs)
 	{
 	  __r /= __rhs;
@@ -401,6 +401,7 @@ _GLIBCXX_END_NAMESPACE_VERSION
 
 	// DR 934.
 	template
+	  _GLIBCXX17_CONSTEXPR
 	  typename enable_if::value,
 			 duration&>::type
 	  operator%=(const rep& __rhs)
@@ -410,6 +411,7 @@ _GLIBCXX_END_NAMESPACE_VERSION
 	  }
 
 	template
+	  _GLIBCXX17_CONSTEXPR
 	  typename enable_if::value,
 			 duration&>::type
 	  operator%=(const duration& __d)
@@ -631,14 +633,14 @@ _GLIBCXX_END_NAMESPACE_VERSION
 	{ return __d; }
 
 	// arithmetic
-	time_point&
+	_GLIBCXX17_CONSTEXPR time_point&
 	

[v3 PATCH] Make optional's comparisons be two-parameter templates.

[Ville Voutilainen]

This has not been adopted by LEWG/LWG yet, but was submitted
as a proposed resolution for a new LWG issue; optional can't
current be compared to a T, and an optional can't be compared
to something non-T that is comparable to a T. This approach fixes
both of those problems, allowing optional's comparisons to actually
work like the comparisons of the underlying type.

Tested on Linux-x64.

2017-02-19  Ville Voutilainen  

Make optional's comparisons be two-parameter templates.
* include/std/optional
(operator==(const optional<_Tp>&, const optional<_Tp>&)):
Turn into operator==(const optional<_Tp>&, const optional<_Up>&).
(operator!=(const optional<_Tp>&, const optional<_Tp>&)):
Turn into operator!=(const optional<_Tp>&, const optional<_Up>&).
(operator<(const optional<_Tp>&, const optional<_Tp>&)):
Turn into operator<(const optional<_Tp>&, const optional<_Up>&.
(operator>(const optional<_Tp>&, const optional<_Tp>&)):
Turn into operator>(const optional<_Tp>&, const optional<_Up>&.
(operator<=(const optional<_Tp>&, const optional<_Tp>&)):
Turn into operator<=(const optional<_Tp>&, const optional<_Up>&).
(operator>=(const optional<_Tp>&, const optional<_Tp>&)):
Turn into operator>=(const optional<_Tp>&, const optional<_Up>&).
(operator==(const optional<_Tp>&, const _Tp&)):
Turn into operator==(const optional<_Tp>&, const _Up&).
(operator==(const _Tp&, const optional<_Tp>&)):
Turn into operator==(const _Up&, const optional<_Tp>&).
(operator!=(const optional<_Tp>&, const _Tp&)):
Turn into operator!=(const optional<_Tp>&, const _Up&).
(operator!=(const _Tp&, const optional<_Tp>&)):
Turn into operator!=(const _Up&, const optional<_Tp>&).
(operator<(const optional<_Tp>&, const _Tp&)):
Turn into operator<(const optional<_Tp>&, const _Up&).
(operator<(const _Tp&, const optional<_Tp>&)):
Turn into operator<(const _Up&, const optional<_Tp>&).
(operator>(const optional<_Tp>&, const _Tp&)):
Turn into operator>(const optional<_Tp>&, const _Up&).
(operator>(const _Tp&, const optional<_Tp>&)):
Turn into operator>(const _Up&, const optional<_Tp>&).
(operator<=(const optional<_Tp>&, const _Tp&)):
Turn into operator<=(const optional<_Tp>&, const _Up&).
(operator<=(const _Tp&, const optional<_Tp>&)):
Turn into operator<=(const _Up&, const optional<_Tp>&).
(operator>=(const optional<_Tp>&, const _Tp&)):
Turn into operator>=(const optional<_Tp>&, const _Up&).
(operator>=(const _Tp&, const optional<_Tp>&)):
Turn into operator>=(const _Up&, const optional<_Tp>&).
* testsuite/20_util/optional/relops/7.cc: New.
diff --git a/libstdc++-v3/include/std/optional 
b/libstdc++-v3/include/std/optional
index 905bc0a..c700515 100644
--- a/libstdc++-v3/include/std/optional
+++ b/libstdc++-v3/include/std/optional
@@ -737,52 +737,52 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 enable_if_t::value, bool>;
 
   // Comparisons between optional values.
-  template
+  template
 constexpr auto
-operator==(const optional<_Tp>& __lhs, const optional<_Tp>& __rhs)
--> __optional_relop_t() == declval<_Tp>())>
+operator==(const optional<_Tp>& __lhs, const optional<_Up>& __rhs)
+-> __optional_relop_t() == declval<_Up>())>
 {
   return static_cast(__lhs) == static_cast(__rhs)
 && (!__lhs || *__lhs == *__rhs);
 }
 
-  template
+  template
 constexpr auto
-operator!=(const optional<_Tp>& __lhs, const optional<_Tp>& __rhs)
--> __optional_relop_t() != declval<_Tp>())>
+operator!=(const optional<_Tp>& __lhs, const optional<_Up>& __rhs)
+-> __optional_relop_t() != declval<_Up>())>
 {
   return static_cast(__lhs) != static_cast(__rhs)
|| (static_cast(__lhs) && *__lhs != *__rhs);
 }
 
-  template
+  template
 constexpr auto
-operator<(const optional<_Tp>& __lhs, const optional<_Tp>& __rhs)
--> __optional_relop_t() < declval<_Tp>())>
+operator<(const optional<_Tp>& __lhs, const optional<_Up>& __rhs)
+-> __optional_relop_t() < declval<_Up>())>
 {
   return static_cast(__rhs) && (!__lhs || *__lhs < *__rhs);
 }
 
-  template
+  template
 constexpr auto
-operator>(const optional<_Tp>& __lhs, const optional<_Tp>& __rhs)
--> __optional_relop_t() > declval<_Tp>())>
+operator>(const optional<_Tp>& __lhs, const optional<_Up>& __rhs)
+-> __optional_relop_t() > declval<_Up>())>
 {
   return static_cast(__lhs) && (!__rhs || *__lhs > *__rhs);
 }
 
-  template
+  template
 constexpr auto
-operator<=(const optional<_Tp>& __lhs, const optional<_Tp>& __rhs)
--> __optional_relop_t() <= declval<_Tp>())>
+operator<=(const 

[wwwdocs] projects/cfg.html - use doi.org instead of citeseer.ist.psu.edu

[Gerald Pfeifer]

citeseer has been acting interestingly for a while, and now is
blocking clients based on geography (verified as blocking from 
three different systems/networks in Austria and Germany on the 
one hand¹, and working from the gcc.gnu.org host and another 
one in North America on the other).

So, based on Joseph's point earlier this month, I am converting 
a number of references to doi.org with this patch.

(I did not find a link for reference [3], which also does not
appear as crucial.)

Applied.

Gerald

¹ The error message is "This site has been blocked by the network 
administrator" which makes it appear to be on the user's end, which
alas is not the case.

Index: projects/cfg.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/projects/cfg.html,v
retrieving revision 1.21
diff -u -r1.21 cfg.html
--- projects/cfg.html   28 May 2016 12:59:43 -  1.21
+++ projects/cfg.html   19 Feb 2017 14:17:03 -
@@ -451,22 +451,20 @@
 
 [1]
 
-http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.43.6404;>Branch
+https://doi.org/10.1145/155090.155119;>Branch
 Prediction for Free; Ball and Larus; PLDI '93.
 
 [2]
 
-http://citeseer.ist.psu.edu/wu94static.html;>Static
+https://doi.org/10.1145/192724.192725;>Static
 Branch Frequency and Program Profile Analysis; Wu and Larus;
 MICRO-27.
 
 [3]
 
-http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.37.7180;>Design
-and Analysis of Profile-Based Optimization in Compaq's Compilation
-Tools for Alpha; Journal of Instruction-Level Parallelism 3 (2000)
-1-25
+Design and Analysis of Profile-Based Optimization in Compaq's
+Compilation Tools for Alpha; Journal of Instruction-Level Parallelism 3
+(2000) 1-25.
 
 [4]
 
@@ -477,20 +475,18 @@
 
 [5]
 
-http://citeseer.ist.psu.edu/young97nearoptimal.html;>Near-optimal
+https://doi.org/10.1145/258916.258932;>Near-optimal
 Intraprocedural Branch Alignment; Cliff Young, David S. Johnson,
 David R. Karger, Michael D. Smith, ACM 1997
 
 [6]
 
-http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.50.2235;>Software
+https://doi.org/10.1145/305138.305178;>Software
 Trace Cache; International Conference on Supercomputing, 1999
 
 [7]
 
-http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.14.4115;>Using
+https://doi.org/10.1002/spe.4380211204;>Using
 Profile Information to Assist Classic Code Optimizations; Pohua P.
 Chang, Scott A. Mahlke, and Wen-mei W. Hwu, 1991
 
@@ -503,8 +499,7 @@
 
 [9]
 
-http://citeseer.ist.psu.edu/warter93reverse.html;>Reverse
+https://doi.org/10.1145/173262.155118;>Reverse
 If-Conversion; Nancy J. Warter, Scott A. Mahlke, Wen-mei W. Hwu, B.
 Ramakrishna Rau; ACM SIGPLAN Notices, 1993
 

New German PO file for 'gcc' (version 7.1-b20170101)

[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 German team of translators.  The file is available at:

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

(This file, 'gcc-7.1-b20170101.de.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.

[libstdc++,doc] doc/xml/manual/debug.xml: Adjust link to ThreadSanitizer

[Gerald Pfeifer]

The site at code.google.com redirects to github now.

Applied.

Gerald

2017-02-19  Gerald Pfeifer  

* doc/xml/manual/debug.xml: Adjust link to ThreadSanitizer.

Index: doc/xml/manual/debug.xml
===
--- doc/xml/manual/debug.xml(revision 245571)
+++ doc/xml/manual/debug.xml(working copy)
@@ -234,7 +234,7 @@
   xlink:href="http://valgrind.org/docs/manual/hg-manual.html;> 
   Helgrind, and
   http://www.w3.org/1999/xlink; 
-  xlink:href="https://code.google.com/p/data-race-test/;> 
+  xlink:href="https://github.com/google/sanitizers;> 
   ThreadSanitizer (this refers to ThreadSanitizer v1, not the
   new "tsan" feature built-in to GCC itself).