Re: [PATCH, Fortran, Coarray, v1] Add support for failed images

2017-03-04 Thread Jerry DeLisle 
On 03/04/2017 09:58 AM, Andre Vehreschild wrote:
> Hi all,
> 
> attached patch polishes the one begun by Alessandro. It adds documentation and
> fixes the style issues. Furthermore did I try to interpret the standard
> according to the FAIL IMAGE statement. IMHO should it just quit the executable
> without any error code. The caf_single library emits "FAIL IMAGE" to stderr,
> while in coarray=single mode it just quits. What do you think?
> 
> Bootstraps and regtests ok on x86_64-linux/f25. Ok for trunk? (May be later).
> 
> Gruß,
>   Andre
> 

>From my read:

"A failed image is usually associated with a hardware failure of the processor,
memory system, or interconnection network"

Since the FAIL IMAGE statement is intended to simulate such failure, I agree
with your interpretation as well, it just stops execution.

Yes OK for trunk now.

Jerry

[wwwdocs] Shorten intro in gcc-7/porting_to.html

2017-03-04 Thread Gerald Pfeifer 
While creating gcc-8/porting_to.html I noticed the introduction
we've been using is really a bit verbose.  This makes it a little
shorter and is aligned with what I put in gcc-8/porting.html.

Committed.

Gerald

Index: gcc-7/porting_to.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-7/porting_to.html,v
retrieving revision 1.9
diff -u -r1.9 porting_to.html
--- gcc-7/porting_to.html   25 Feb 2017 16:38:29 -  1.9
+++ gcc-7/porting_to.html   4 Mar 2017 20:24:19 -
@@ -18,10 +18,9 @@
 
 
 
-However, some of these changes are visible, and can cause grief to
-users porting to GCC 7. This document is an effort to identify major
-issues and provide clear solutions in a quick and easily searched
-manner. Additions and suggestions for improvement are welcome.
+However, some of these changes are user visible and can cause grief when
+porting to GCC 7. This document is an effort to identify common issues
+and provide solutions. Let us know if you have suggestions for improvements!

Re: [PATCH, Fortran, Coarray, v1] Add support for failed images

2017-03-04 Thread Andre Vehreschild 
Hi Alessandro,

Yes of course. I planned to. Sorry that I forgot.

- Andre

Am 4. März 2017 20:51:58 MEZ schrieb Alessandro Fanfarillo 
:
>Hi Andre,
>thanks for your work on the patch. I agree with you about exit(0)
>statement in libcaf_single.
>Could you please add my name and contact (Alessandro Fanfarillo
>) below yours in the changelog?
>
>Thanks,
>Alessandro
>
>
>2017-03-04 10:58 GMT-07:00 Andre Vehreschild :
>> Hi all,
>>
>> attached patch polishes the one begun by Alessandro. It adds
>documentation and
>> fixes the style issues. Furthermore did I try to interpret the
>standard
>> according to the FAIL IMAGE statement. IMHO should it just quit the
>executable
>> without any error code. The caf_single library emits "FAIL IMAGE" to
>stderr,
>> while in coarray=single mode it just quits. What do you think?
>>
>> Bootstraps and regtests ok on x86_64-linux/f25. Ok for trunk? (May be
>later).
>>
>> Gruß,
>> Andre
>> --
>> Andre Vehreschild * Email: vehre ad gmx dot de

-- 
Andre Vehreschild * Kreuzherrenstr. 8 * 52062 Aachen
Tel.: +49 241 929 10 18 * ve...@gmx.de

Re: [PATCH, Fortran, Coarray, v1] Add support for failed images

2017-03-04 Thread Alessandro Fanfarillo 
Hi Andre,
thanks for your work on the patch. I agree with you about exit(0)
statement in libcaf_single.
Could you please add my name and contact (Alessandro Fanfarillo
) below yours in the changelog?

Thanks,
Alessandro


2017-03-04 10:58 GMT-07:00 Andre Vehreschild :
> Hi all,
>
> attached patch polishes the one begun by Alessandro. It adds documentation and
> fixes the style issues. Furthermore did I try to interpret the standard
> according to the FAIL IMAGE statement. IMHO should it just quit the executable
> without any error code. The caf_single library emits "FAIL IMAGE" to stderr,
> while in coarray=single mode it just quits. What do you think?
>
> Bootstraps and regtests ok on x86_64-linux/f25. Ok for trunk? (May be later).
>
> Gruß,
> Andre
> --
> Andre Vehreschild * Email: vehre ad gmx dot de

New French PO file for 'gcc' (version 7.1-b20170226)

2017-03-04 Thread 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 French team of translators.  The file is available at:

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

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

[PATCH, Fortran, Coarray, v1] Add support for failed images

2017-03-04 Thread Andre Vehreschild 
Hi all,

attached patch polishes the one begun by Alessandro. It adds documentation and
fixes the style issues. Furthermore did I try to interpret the standard
according to the FAIL IMAGE statement. IMHO should it just quit the executable
without any error code. The caf_single library emits "FAIL IMAGE" to stderr,
while in coarray=single mode it just quits. What do you think?

Bootstraps and regtests ok on x86_64-linux/f25. Ok for trunk? (May be later).

Gruß,
Andre
-- 
Andre Vehreschild * Email: vehre ad gmx dot de 
gcc/fortran/ChangeLog:

2017-03-04  Andre Vehreschild  

* check.c (positive_check): Add new function checking constant for
being greater then zero.
(gfc_check_image_status): Add checking of image_status arguments.
(gfc_check_failed_or_stopped_images): Same but for failed_- and
stopped_images function.
* dump-parse-tree.c (show_code_node): Added output of FAIL IMAGE.
* gfortran.h (enum gfc_statement): Added FAIL_IMAGE_ST.
(enum gfc_isym_id): Added new intrinsic symbols.
(enum gfc_exec_op): Added EXEC_FAIL_IMAGE.
* gfortran.texi: Added description for the new API functions. Updated
coverage of gfortran of TS18508.
* intrinsic.c (add_functions): Added symbols to resolve new intrinsic
functions. 
* intrinsic.h: Added prototypes.
* iresolve.c (gfc_resolve_failed_images): Resolve the failed_images
intrinsic.
(gfc_resolve_image_status): Same for image_status.
(gfc_resolve_stopped_images): Same for stopped_images.
* libgfortran.h: Added prototypes.
* match.c (gfc_match_if): Added matching of FAIL IMAGE statement.
(gfc_match_fail_image): Match a FAIL IMAGE statement.
* match.h: Added prototype.
* parse.c (decode_statement): Added matching for FAIL IMAGE.
(next_statement): Same.
(gfc_ascii_statement): Same.
* resolve.c: Same.
* simplify.c (gfc_simplify_failed_or_stopped_images): For COARRAY=
single a constant result can be returne.d
(gfc_simplify_image_status): For COARRAY=single the result is constant.
* st.c (gfc_free_statement): Added FAIL_IMAGE handling.
* trans-decl.c (gfc_build_builtin_function_decls): Added decls of the
new intrinsics.
* trans-expr.c (gfc_conv_procedure_call): This is first time all
arguments of a function are optional, which is now handled here
correctly.
* trans-intrinsic.c (conv_intrinsic_image_status): Translate
image_status.
(gfc_conv_intrinsic_function): Add support for image_status.
(gfc_is_intrinsic_libcall): Add support for the remaining new
intrinsics.
* trans-stmt.c (gfc_trans_fail_image): Trans a fail image.
* trans-stmt.h: Add the prototype for the above.
* trans.c (trans_code): Dispatch for fail_image.
* trans.h: Add the trees for the new intrinsics.

libgfortran/ChangeLog:

2017-03-04  Andre Vehreschild  

* caf/libcaf.h: Added prototypes and stat codes for failed and stopped
images.
* caf/single.c (void _gfortran_caf_fail_image): Add the routine.
(int _gfortran_caf_image_status): Same.
(_gfortran_caf_failed_images): Same.
(_gfortran_caf_stopped_images): Same.


gcc/testsuite/ChangeLog:

2017-03-04  Andre Vehreschild  

* gfortran.dg/coarray/fail_image_1.f08: New test.
* gfortran.dg/coarray/fail_image_2.f08: New test.
* gfortran.dg/coarray/failed_images_1.f08: New test.
* gfortran.dg/coarray/failed_images_2.f08: New test.
* gfortran.dg/coarray/image_status_1.f08: New test.
* gfortran.dg/coarray/image_status_2.f08: New test.
* gfortran.dg/coarray/stopped_images_1.f08: New test.
* gfortran.dg/coarray/stopped_images_2.f08: New test.
* gfortran.dg/coarray_fail_st.f90: New test.
* gfortran.dg/coarray_failed_images_1.f08: New test.
* gfortran.dg/coarray_image_status_1.f08: New test.
* gfortran.dg/coarray_stopped_images_1.f08: New test.

diff --git a/gcc/fortran/check.c b/gcc/fortran/check.c
index c22bfa9..45bc68e 100644
--- a/gcc/fortran/check.c
+++ b/gcc/fortran/check.c
@@ -295,6 +295,29 @@ nonnegative_check (const char *arg, gfc_expr *expr)
 }
 
 
+/* If expr is a constant, then check to ensure that it is greater than zero.  */
+
+static bool
+positive_check (int n, gfc_expr *expr)
+{
+  int i;
+
+  if (expr->expr_type == EXPR_CONSTANT)
+{
+  gfc_extract_int (expr, );
+  if (i <= 0)
+	{
+	  gfc_error ("%qs argument of %qs intrinsic at %L must be positive",
+		 gfc_current_intrinsic_arg[n]->name, gfc_current_intrinsic,
+		 >where);
+	  return false;
+	}
+}
+
+  return true;
+}
+
+
 /* If expr2 is constant, then check that the value is less than
(less than or equal to, if 'or_equal' is true)

i386-unknown-freebsd -> i586-unknown-freebsd (was: [Patch wwwdocs] Add aarch64-none-linux-gnu as a primary platform for GCC-7)

2017-03-04 Thread Gerald Pfeifer 
On Tue, 24 May 2016, Richard Biener wrote:
> Can we update to a non-marketing name then, like i586-unknown-freebsd 
> please? config.gcc accepts i[34567]86-*-freebsd*.  It at least confused 
> me.

Of course, once I hacked config.gcc, I realized that the simple
patch below is all you actually may have had in mind. ;-)

Applied.  

But let's still consider the config.guess change for GCC 7 as
well, or people might not be _appearing_ to use it, even if it
is practically the same?

Gerald

Index: gcc-7/criteria.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-7/criteria.html,v
retrieving revision 1.2
diff -u -r1.2 criteria.html
--- gcc-7/criteria.html 1 Mar 2017 16:07:23 -   1.2
+++ gcc-7/criteria.html 4 Mar 2017 16:41:02 -
@@ -103,7 +103,7 @@
 
 aarch64-none-linux-gnu
 arm-linux-gnueabi
-i386-unknown-freebsd
+i586-unknown-freebsd
 i686-pc-linux-gnu
 mipsisa64-elf
 powerpc64-unknown-linux-gnu

i386-unknown-freebsd -> i586-unknown-freebsd (was: [Patch wwwdocs] Add aarch64-none-linux-gnu as a primary platform for GCC-7)

2017-03-04 Thread Gerald Pfeifer 
On Tue, 24 May 2016, Richard Biener wrote:
>> As Jeff noted, i386 actually is the "marketing" name used for the
>> platform, GCC has been defaulting to i486 for ages, and I upgraded
>> to i586 last year:
>>
>> 2015-11-15  Gerald Pfeifer  
>>
>> * config/i386/freebsd.h (SUBTARGET32_DEFAULT_CPU): Change to i586.
>> Remove support for FreeBSD 5 and earlier.
> Can we update to a non-marketing name then, like i586-unknown-freebsd please?
> config.gcc accepts i[34567]86-*-freebsd*.  It at least confused me.

Sooo, I finally got to submitting the patch below to the config.guess 
maintainers.

When/if this has been accepted, is it okay to pull the latest config.guess
into GCC even at this stage of the release process?  (We're only looking
at this change and the addition of nsx-tandem compared to what we have
right now.)

Gerald


2017-03-04  Gerald Pfeifer  

* config.guess (*:FreeBSD:*:*): Refactor CPU handling.
Canonicalize i386-*-freebsd* to i586-*-freebsd*.

diff --git a/config.guess b/config.guess
index 1000e2b..180375c 100755
--- a/config.guess
+++ b/config.guess
@@ -837,10 +837,11 @@ EOF
UNAME_PROCESSOR=`/usr/bin/uname -p`
case ${UNAME_PROCESSOR} in
amd64)
-   echo x86_64-unknown-freebsd`echo ${UNAME_RELEASE}|sed -e 
's/[-(].*//'` ;;
-   *)
-   echo ${UNAME_PROCESSOR}-unknown-freebsd`echo 
${UNAME_RELEASE}|sed -e 's/[-(].*//'` ;;
+   UNAME_PROCESSOR=x86_64 ;;
+   i386)
+   UNAME_PROCESSOR=i586 ;;
esac
+   echo ${UNAME_PROCESSOR}-unknown-freebsd`echo ${UNAME_RELEASE}|sed -e 
's/[-(].*//'`
exit ;;
 i*:CYGWIN*:*)
echo ${UNAME_MACHINE}-pc-cygwin

Re: [wwwdocs] Update changes.html for LTO and IPA

2017-03-04 Thread Gerald Pfeifer 
On Tue, 28 Feb 2017, Jan Hubicka wrote:
>> And one question: "declaration linking" is used in the description
>> of Link-time optimization improvements, alas that string does not 
>> appear anywhere in either the source tree or documentation?
> It is my own name indeed. lto-symtab.c does merge declarations
> when they refer to same symbol name. Newly we do not merge when 
> the symbol names does not appear semantically similar enough.
> We can also call it declaration merging, but it is internal name 
> anyway and most link-time optimization papers reffer to these merging 
> processes as linking.

Thanks for the explanation, Honza.

In that case, I guess leave it as is unless someone else wants to
see this changed.


As another note, "declaration merging" once occurs in our codebase,
in varpool.c:

  /* When doing declaration merging we have duplicate
 entries for given decl.  Do not attempt to remove
 the boides, or we will end up remiving
 wrong one.  */

Should this read "Do not attempt to address this, or we risk removing
the wrong one" or something like that?

Unless

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

2017-03-04 Thread 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-b20170226.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.

[wwwdocs] gcc-8/porting_to.html (was: [PATCH, GCC/x86 mingw32] Add configure option to force wildcard behavior on Windows)

2017-03-04 Thread Gerald Pfeifer 
On Thu, 2 Mar 2017, Thomas Preudhomme wrote:
>> This should be mentioned in the "porting to" page when it eventually 
>> goes in, as it may be surprising behavior.
> Will do once the file is created for gcc-8. Thanks for the suggestion

Here we go. :-)  Applied.

Gerald

Index: porting_to.html
===
RCS file: porting_to.html
diff -N porting_to.html
--- /dev/null   1 Jan 1970 00:00:00 -
+++ porting_to.html 4 Mar 2017 14:20:46 -
@@ -0,0 +1,37 @@
+
+
+
+Porting to GCC 8
+
+
+
+Porting to GCC 8
+
+
+The GCC 8 release series differs from previous GCC releases in
+a number of ways. Some of these are a result
+of bug fixing, and some old behaviors have been intentionally changed
+to support new standards, or relaxed in standards-conforming ways to
+facilitate compilation or run-time performance.
+
+
+
+Some of these changes are user visible and can cause grief when
+porting to GCC 8. This document is an effort to identify common issues
+and provide solutions. Let us know if you have suggestions for improvements!
+
+
+
+Preprocessor issues
+
+
+C language issues
+
+
+C++ language issues
+
+
+Links
+
+
+

C PATCH to add missing space in diagnostic (PR c/79847)

2017-03-04 Thread Marek Polacek 
There should be a space after the semicolon.

Bootstrapped/regtested on x86_64-linux, applying to trunk.

2017-03-04  Marek Polacek  

PR c/79847
* c-decl.c (implicit_decl_warning): Add missing space.

diff --git gcc/c/c-decl.c gcc/c/c-decl.c
index f46ca11..645304a 100644
--- gcc/c/c-decl.c
+++ gcc/c/c-decl.c
@@ -3147,7 +3147,7 @@ implicit_decl_warning (location_t loc, tree id, tree 
olddecl)
richloc.add_fixit_replace (hint);
warned = warning_at_rich_loc
  (, OPT_Wimplicit_function_declaration,
-  G_("implicit declaration of function %qE;did you mean %qs?"),
+  G_("implicit declaration of function %qE; did you mean %qs?"),
   id, hint);
  }
else

Marek

Re: [PATCH] Add " && !(MEM_P (operands[0]) && MEM_P (operands[1]))" to condition of some sse.md instructions

2017-03-04 Thread Uros Bizjak 
On Fri, Mar 3, 2017 at 8:44 PM, Jakub Jelinek  wrote:
> On Fri, Mar 03, 2017 at 12:18:09PM +0100, Uros Bizjak wrote:
>> Yes. Although expander takes care not to generate two memory
>> references, combine can propagate memory to the other operand,
>> creating semi-invalid RTX that is later resolved by RA.
>
> Here is a patch which does that.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> 2017-03-03  Jakub Jelinek  
>
> * config/i386/sse.md (sse_storehps, sse_storelps,
> avx__,
> avx512f__,
> avx512f__256): Require
> in condition that at least one operand is not a MEM.

OK.

Thanks,
Uros.

> --- gcc/config/i386/sse.md.jj   2017-03-03 17:08:53.0 +0100
> +++ gcc/config/i386/sse.md  2017-03-03 17:39:05.907871328 +0100
> @@ -6637,7 +6637,7 @@ (define_insn "sse_storehps"
> (vec_select:V2SF
>   (match_operand:V4SF 1 "nonimmediate_operand" "v,v,o")
>   (parallel [(const_int 2) (const_int 3)])))]
> -  "TARGET_SSE"
> +  "TARGET_SSE && !(MEM_P (operands[0]) && MEM_P (operands[1]))"
>"@
> %vmovhps\t{%1, %0|%q0, %1}
> %vmovhlps\t{%1, %d0|%d0, %1}
> @@ -6690,7 +6690,7 @@ (define_insn "sse_storelps"
> (vec_select:V2SF
>   (match_operand:V4SF 1 "nonimmediate_operand" " v,v,m")
>   (parallel [(const_int 0) (const_int 1)])))]
> -  "TARGET_SSE"
> +  "TARGET_SSE && !(MEM_P (operands[0]) && MEM_P (operands[1]))"
>"@
> %vmovlps\t{%1, %0|%q0, %1}
> %vmovaps\t{%1, %0|%0, %1}
> @@ -18661,7 +18661,7 @@ (define_insn_and_split "avx_ (unspec:AVX256MODE2P
>   [(match_operand: 1 "nonimmediate_operand" "xm,x")]
>   UNSPEC_CAST))]
> -  "TARGET_AVX"
> +  "TARGET_AVX && !(MEM_P (operands[0]) && MEM_P (operands[1]))"
>"#"
>"&& reload_completed"
>[(set (match_dup 0) (match_dup 1))]
> @@ -19575,7 +19575,7 @@ (define_insn_and_split "avx512f_ (unspec:AVX512MODE2P
>   [(match_operand: 1 "nonimmediate_operand" "xm,x")]
>   UNSPEC_CAST))]
> -  "TARGET_AVX512F"
> +  "TARGET_AVX512F && !(MEM_P (operands[0]) && MEM_P (operands[1]))"
>"#"
>"&& reload_completed"
>[(set (match_dup 0) (match_dup 1))]
> @@ -19592,7 +19592,7 @@ (define_insn_and_split "avx512f_ (unspec:AVX512MODE2P
>   [(match_operand: 1 "nonimmediate_operand" "xm,x")]
>   UNSPEC_CAST))]
> -  "TARGET_AVX512F"
> +  "TARGET_AVX512F && !(MEM_P (operands[0]) && MEM_P (operands[1]))"
>"#"
>"&& reload_completed"
>[(set (match_dup 0) (match_dup 1))]
>
>
> Jakub

C++ PATCH to overload resolution for inherited constructors

2017-03-04 Thread Jason Merrill 
In committee review of the rule to restore effective hiding in
overload resolution between a base constructor with a default argument
and a derived constructor without, it was observed that what we were
doing doesn't properly handle the case where both constructors are
from bases, just one more derived.  This patch fixes that.

Tested x86_64-pc-linux-gnu, applying to trunk.
commit ae6d87429550f4354730e17113d4b0fb32d96571
Author: Jason Merrill 
Date:   Fri Mar 3 14:47:09 2017 -1000

Core issues 2273 and 2277

* call.c (joust): Adjust using-declaration tiebreaker to handle
the intermediate base case.
* method.c (strip_inheriting_ctors): Just return the argument if
!flag_new_inheriting_ctors.

diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index dc629b96..5afec4f 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -9735,20 +9735,26 @@ joust (struct z_candidate *cand1, struct z_candidate 
*cand2, bool warn,
}
 }
 
-  /* or, if not that, F2 is from a using-declaration, F1 is not, and the
- conversion sequences are equivalent.
- (proposed in http://lists.isocpp.org/core/2016/10/1142.php) */
+  /* F1 is a member of a class D, F2 is a member of a base class B of D, and
+ for all arguments the corresponding parameters of F1 and F2 have the same
+ type (CWG 2273/2277). */
   if (DECL_P (cand1->fn) && DECL_CLASS_SCOPE_P (cand1->fn)
   && !DECL_CONV_FN_P (cand1->fn)
   && DECL_P (cand2->fn) && DECL_CLASS_SCOPE_P (cand2->fn)
   && !DECL_CONV_FN_P (cand2->fn))
 {
-  bool used1 = (DECL_INHERITED_CTOR (cand1->fn)
-   || (BINFO_TYPE (cand1->access_path)
-   != DECL_CONTEXT (cand1->fn)));
-  bool used2 = (DECL_INHERITED_CTOR (cand2->fn)
-   || (BINFO_TYPE (cand2->access_path)
-   != DECL_CONTEXT (cand2->fn)));
+  tree base1 = DECL_CONTEXT (strip_inheriting_ctors (cand1->fn));
+  tree base2 = DECL_CONTEXT (strip_inheriting_ctors (cand2->fn));
+
+  bool used1 = false;
+  bool used2 = false;
+  if (base1 == base2)
+   /* No difference.  */;
+  else if (DERIVED_FROM_P (base1, base2))
+   used1 = true;
+  else if (DERIVED_FROM_P (base2, base1))
+   used2 = true;
+
   if (int diff = used2 - used1)
{
  for (i = 0; i < len; ++i)
diff --git a/gcc/cp/method.c b/gcc/cp/method.c
index beb0a24..f6024cd 100644
--- a/gcc/cp/method.c
+++ b/gcc/cp/method.c
@@ -498,7 +498,8 @@ forward_parm (tree parm)
 tree
 strip_inheriting_ctors (tree dfn)
 {
-  gcc_assert (flag_new_inheriting_ctors);
+  if (!flag_new_inheriting_ctors)
+return dfn;
   tree fn = dfn;
   while (tree inh = DECL_INHERITED_CTOR (fn))
 {
diff --git a/gcc/testsuite/g++.dg/overload/using5.C 
b/gcc/testsuite/g++.dg/overload/using5.C
new file mode 100644
index 000..ad17c78
--- /dev/null
+++ b/gcc/testsuite/g++.dg/overload/using5.C
@@ -0,0 +1,28 @@
+// Core issues 2273, 2277
+// { dg-do compile { target c++11 } }
+
+struct A
+{
+  A(int, int = 0);
+  static void f(int = 0);
+};
+
+struct B: A
+{
+  using A::A;
+  B(int);
+
+  using A::f;
+  static void f();
+};
+
+struct C: B {
+  using B::B;
+  using B::f;
+};
+  
+int main()
+{
+  C c (42);
+  c.f();
+}

C++ PATCH to add -Wno-noexcept-type

2017-03-04 Thread Jason Merrill 
Along with the C++17 change to make noexcept part of the type I added
a warning for situations where this changes the mangled name of a
symbol, as part of -Wc++1z-compat.  This is troublesome since there's
no way to adjust your code to avoid it, so this patch gives it a
separate flag.

Tested x86_64-pc-linux-gnu, applying to trunk.
commit aba02f8c8b29b8355e3c72c0ba6bc000768a8939
Author: Jason Merrill 
Date:   Fri Mar 3 15:07:31 2017 -1000

* c.opt (Wnoexcept-type): New.

gcc/cp/
* mangle.c (mangle_decl): Check -Wnoexcept-type instead of
-Wc++1z-compat.

diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
index cf459ab..78fea61 100644
--- a/gcc/c-family/c.opt
+++ b/gcc/c-family/c.opt
@@ -780,6 +780,10 @@ Wnoexcept
 C++ ObjC++ Var(warn_noexcept) Warning
 Warn when a noexcept expression evaluates to false even though the expression 
can't actually throw.
 
+Wnoexcept-type
+C++ ObjC++ Warning Var(warn_noexcept_type) LangEnabledBy(C++ ObjC++,Wabi || 
Wc++1z-compat)
+Warn if C++1z noexcept function type will change the mangled name of a symbol.
+
 Wnon-template-friend
 C++ ObjC++ Var(warn_nontemplate_friend) Init(1) Warning
 Warn when non-templatized friend functions are declared within a template.
diff --git a/gcc/cp/mangle.c b/gcc/cp/mangle.c
index 8b30f42..6f7e21c 100644
--- a/gcc/cp/mangle.c
+++ b/gcc/cp/mangle.c
@@ -3856,7 +3856,7 @@ mangle_decl (const tree decl)
 
   if (G.need_cxx1z_warning
   && (TREE_PUBLIC (decl) || DECL_REALLY_EXTERN (decl)))
-warning_at (DECL_SOURCE_LOCATION (decl), OPT_Wc__1z_compat,
+warning_at (DECL_SOURCE_LOCATION (decl), OPT_Wnoexcept_type,
"mangled name for %qD will change in C++17 because the "
"exception specification is part of a function type",
decl);
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 68174a1..15eb0e0 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -215,7 +215,7 @@ in the following sections.
 -Wabi=@var{n}  -Wabi-tag  -Wconversion-null  -Wctor-dtor-privacy @gol
 -Wdelete-non-virtual-dtor  -Wliteral-suffix  -Wmultiple-inheritance @gol
 -Wnamespaces  -Wnarrowing @gol
--Wnoexcept  -Wnon-virtual-dtor  -Wreorder  -Wregister @gol
+-Wnoexcept  -Wnoexcept-type  -Wnon-virtual-dtor  -Wreorder  -Wregister @gol
 -Weffc++  -Wstrict-null-sentinel  -Wtemplates @gol
 -Wno-non-template-friend  -Wold-style-cast @gol
 -Woverloaded-virtual  -Wno-pmf-conversions @gol
@@ -2897,6 +2897,20 @@ to a function that does not have a non-throwing exception
 specification (i.e. @code{throw()} or @code{noexcept}) but is known by
 the compiler to never throw an exception.
 
+@item -Wnoexcept @r{(C++ and Objective-C++ only)}
+@opindex Wnoexcept-type
+@opindex Wno-noexcept-type
+Warn if the C++1z feature making @code{noexcept} part of a function
+type changes the mangled name of a symbol relative to C++14.  Enabled
+by @option{-Wabi} and @option{-Wc++1z-compat}.
+
+@smallexample
+template  void f(T t) @{ t(); @};
+void g() noexcept;
+void h() @{ f(g); @} // in C++14 calls f, in C++1z calls 
f
+@end smallexample
+
+
 @item -Wnon-virtual-dtor @r{(C++ and Objective-C++ only)}
 @opindex Wnon-virtual-dtor
 @opindex Wno-non-virtual-dtor
diff --git a/gcc/testsuite/g++.dg/cpp1z/noexcept-type11a.C 
b/gcc/testsuite/g++.dg/cpp1z/noexcept-type11a.C
new file mode 100644
index 000..f5028d2
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1z/noexcept-type11a.C
@@ -0,0 +1,3 @@
+// { dg-options "-Wall -Wno-noexcept-type -std=c++14" }
+
+void f(int(*)() noexcept) { }