C++ PATCH for CWG2233

In Core working group discussions today we were looking at this testcase, which caused the compiler to ICE because it assumed that once we had seen one default argument, all following parameters would have them as well. This is no longer true now that we allow a parameter pack to follow default

C++ PATCH for _Complex and constexpr

The constexpr code was treating __real/__imag as always producing an rvalue, which is incorrect. Tested x86_64-pc-linux-gnu, applying to trunk. commit b61d1ce84c2e66dde4662dab41ccd99dd360a02f Author: Jason Merrill Date: Sat Nov 12 10:45:14 2016 -0800 Fix constexpr lvalue

C++ PATCH for DR 374 (specialization outside of namespace)

In C++11 it's OK to declare a specialization for the first time outside of the template's namespace, so long as the specialization is explicitly qualified. Conversely, C++11 puts the same restrictions on explicit instantiations, whereas C++98 didn't say anything about where they needed to go. So

[PATCH], Add PowerPC ISA 3.0 support for xxinsertw, vinserth, and vinsertb instructions

I modified the vec_insert built-in so that it generates the insert word, half-word, and byte instructions (XXINSERTW, VINSERTH, and VINSERTB) on ISA 3.0 (power9). I did the usual bootstrap and make check with no regressions. In addition, I ran a program on the simulator that verified that the

Re: [Patch, Fortran, OOP] PR 66366: ICE on invalid with non-allocatable CLASS variable

On Sat, Nov 12, 2016 at 09:13:26PM +0100, Janus Weil wrote: > > this patch fixes an ICE on invalid code involving class component > declarations. The ICE is avoided by moving forward the error check > from resolution to parsing stage. For class components this is > possible, because the

Re: [PATCH] Add std::future_error constructor from future_errc

On 12/11/16 02:34 -0500, Tim Song wrote: On Fri, Nov 11, 2016 at 10:39 PM, Jonathan Wakely wrote: making the existing not-required-by-the-standard constructor private. + public: +explicit +future_error(error_code __ec) +: logic_error("std::future_error: " +

Re: [Patch, Fortran, F03] PR 77501: ICE in gfc_match_generic, at fortran/decl.c:9429

2016-11-12 20:15 GMT+01:00 Mikael Morin : [Btw, speaking of gfc_get_tbp_symtree: Can anyone tell me by chance why it is necessary to nullify 'result->n.tb' on a newly-created symtree?] >>> >>> >>> Removing the corresponding line does not do any harm to the

Re: [PATCH] Five patches for std::experimental::filesystem

On 10/11/16 17:29 +, Chris Fairles wrote: "cannot check is file is empty" -> *if This patch fixes the typo. I haven't looked at the failure yet. Will commit to trunk shortly. commit 9882c567342019c9561b44e611af9d42cdf23f3b Author: Jonathan Wakely Date: Sat Nov 12

[Patch, Fortran, OOP] PR 66366: ICE on invalid with non-allocatable CLASS variable

Hi all, this patch fixes an ICE on invalid code involving class component declarations. The ICE is avoided by moving forward the error check from resolution to parsing stage. For class components this is possible, because the attributes have to be specified in the same line (in contrast to class

[Patch] Remove variant, variant<T&> and variant<>

At Issaquah we decided to remove the supports above. Bootstrapped and tested on x86_64-linux-gnu. Thanks! -- Regards, Tim Shen Index: libstdc++-v3/include/std/variant === --- libstdc++-v3/include/std/variant (revision 242337) +++

[v3 PATCH] Implement P0504R0 (Revisiting in-place tag types for any/optional/variant).

Tested on Linux-x64. We need to get this in before we ship std::any, std::variant or std::optional. 2016-11-12 Ville Voutilainen Implement P0504R0 (Revisiting in-place tag types for any/optional/variant). * include/std/any (any(_ValueType&& __value)):

Re: [Patch, Fortran, F03] PR 77501: ICE in gfc_match_generic, at fortran/decl.c:9429

Le 11/11/2016 à 19:30, Steve Kargl a écrit : On Fri, Nov 11, 2016 at 03:05:06PM +0100, Janus Weil wrote: 2016-11-11 14:38 GMT+01:00 Janus Weil : [Btw, speaking of gfc_get_tbp_symtree: Can anyone tell me by chance why it is necessary to nullify 'result->n.tb' on a

Re: [Patch 4/5] OpenACC tile clause support, Fortran front-end parts

On 11/11/2016 02:34 AM, Jakub Jelinek wrote: > On Thu, Nov 10, 2016 at 06:46:46PM +0800, Chung-Lin Tang wrote: And here's the patch. Cesar >> 2016-XX-XX Cesar Philippidis >> >> fortran/ >> * openmp.c (resolve_oacc_positive_int_expr): Promote the warning >>

Re: [PATCH] rs6000: Don't forget to initialize the TOC (PR77957)

On Sat, Nov 12, 2016 at 10:07 AM, Segher Boessenkool wrote: > The code generating traceback tables mistakenly does an early return > if !optional_tbtab, which causes it to miss the code generating the TOC > section. This only matters if the TOC will be empty since

[PATCH] rs6000: Don't forget to initialize the TOC (PR77957)

The code generating traceback tables mistakenly does an early return if !optional_tbtab, which causes it to miss the code generating the TOC section. This only matters if the TOC will be empty since otherwise the section is created elsewhere. This patch fixes it. It will need a backport to 6 as

[PATCH] microMIPS/GCC: Fix PIC call relaxation

Fix `-mrelax-pic-calls' support for microMIPS code where the relocation produced is supposed to be R_MICROMIPS_JALR rather than R_MIPS_JALR. The lack of short delay support comes from a missed update to this code for microMIPS support and can be relieved as JALRS and JRS instructions can be

Re: Fix PR77881: combine improvement

Hi Michael, On Thu, Oct 20, 2016 at 04:20:09PM +0200, Michael Matz wrote: > PR missed-optimization/77881 > * combine.c (simplify_comparison): Remove useless subregs > also inside the loop, not just after it. > > testsuite/ > * gcc.target/i386/pr77881.c: New test. This

New Spanish PO file for 'gcc' (version 6.2.0)

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 Spanish team of translators. The file is available at: http://translationproject.org/latest/gcc/es.po (This file, 'gcc-6.2.0.es.po', has

Re: [Patch, Fortran, F03] PR 77501: ICE in gfc_match_generic, at fortran/decl.c:9429

2016-11-11 19:21 GMT+01:00 Steve Kargl : > On Fri, Nov 11, 2016 at 02:38:25PM +0100, Janus Weil wrote: >> >> 2016-11-11 Janus Weil >> >> PR fortran/77501 >> * decl.c (gfc_match_decl_type_spec): Use gfc_get_tbp_symtree, >> fix

Re: [PATCH, RFC] Improve ivopts group costs

On 2016-11-10 13:30, Bin.Cheng wrote: Hi, I see the cost problem with your test now. When computing an address type iv_use with a candidate, the computation consists of two parts, for computation can be represented by addressing mode, it is done in memory reference; for computation cannot be

[PATCH] df: Change defs in entry and uses in exit block during separate shrink-wrapping

So far all target implementations of the separate shrink-wrapping hooks use the DF LIVE info to figure out around which basic blocks the non- volatile registers need to be saved. This is done by looking at the IN+GEN+KILL sets of the basic blocks. However, that doesn't work for registers that DF