[PATCH] Fix PR c++/70106 (type of parenthesized qualified-id has wrong cv-qualifiers)

Here's another force_paren_expr issue. Hopefully I described the issue adequately in the inline comments that are part of the patch. The relevant function that builds the temporary SCOPE_REF is finish_non_static_data_member. Does this patch look OK to commit after bootstrap + regtest?

[RFA][PATCH][PR tree-optimization/64058] Improve and stabilize sorting of coalesce pairs

As discussed in the BZ, we have multiple problems with how we sort the coalesce list during out-of-ssa coalescing. First, the sort is not stable. If the cost of two coalesce pairs is the same, we break the tie by looking at the underlying SSA_NAME_VERSION of the first, then the second

Re: Wonly-top-basic-asm

So, we have been discussing this issue for 4 months now. Over that time, I have tried to incorporate everyone's feedback. As a result we have gone from a tiny doc patch (just describe the current semantics), to a big doc patch (completely deprecate basic asm when used in a function) to a

Re: [PATCH] Turn some compile-time tests into run-time tests

On Thu, Mar 10, 2016 at 6:38 PM, Patrick Palka wrote: > I ran the command > > git grep -l "dg-do compile" | xargs grep -l __builtin_abort | xargs grep > -lw main > > to find tests marked as compile-time tests that likely ought to instead > be marked as run-time tests, by

[PATCH] Turn some compile-time tests into run-time tests

I ran the command git grep -l "dg-do compile" | xargs grep -l __builtin_abort | xargs grep -lw main to find tests marked as compile-time tests that likely ought to instead be marked as run-time tests, by the rationale that they use __builtin_abort and they also define main(). (I also then

Re: [PATCH, rs6000] Fix PR target/70168

On Thu, Mar 10, 2016 at 6:10 PM, Ulrich Weigand wrote: > Hello, > > this patch fixes PR target/70168, a wrong code generation problem > caused by rs6000_expand_atomic_compare_and_swap not properly handling > the case where changing retval clobbers newval due to a register

[PATCH, rs6000] Fix PR target/70168

Hello, this patch fixes PR target/70168, a wrong code generation problem caused by rs6000_expand_atomic_compare_and_swap not properly handling the case where changing retval clobbers newval due to a register overlap. Tested with no regressions on powerpc64le-linux on mainline and gcc-5-branch.

[PATCH] Fix PR c++/70121 (premature folding of const var that was implicitly captured)

Within a lambda we should implicitly capture an outer const variable only if it's odr-used in the body of the lambda. But we are currently making the decision of whether to capture such a variable, or else to fold it to a constant, too early -- before we can know whether it's being odr-used or

[PATCH] Fix PR7001

This patch updates a libgomp test case which was expecting char to be signed when that's not guaranteed to be the case. Jakub pre-approved this patch in the PR. I'll apply this patch to trunk and backport it to gomp-4_0-branch shortly. Cesar 2016-03-10 Cesar Philippidis

Re: [RFC][PR69708] IPA inline not working for function reference in static const struc

On 11/03/16 03:39, Martin Jambor wrote: Hi, On Tue, Mar 01, 2016 at 09:04:25AM +1100, kugan wrote: Hi, As discussed in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69708 and corresponding mailing list discussion, IPA CP is not detecting a jump-function with the sq function as value.

Re: [AArch64] Emit square root using the Newton series

On 03/10/16 13:10, Wilco Dijkstra wrote: frsqrte s1, s0 fmul s2, s1, s1 frsqrts s2, s0, s2 fcmp s0, 0.0 fmul s1, s1, s2 fmul s2, s1, s1 fmul s1, s0, s1 frsqrts s2, s0, s2 fcsels1, s0, s1, eq fmul s0, s1, s2 That's

Re: [C++ PATCH] Reuse certain cxx_eval_constant_expression results in cxx_eval_vec_init_1 (PR c++/70001)

On Thu, Mar 10, 2016 at 07:39:57PM +0100, Jakub Jelinek wrote: > Is this also ok, if it passes bootstrap/regtest? > > 2016-03-10 Jakub Jelinek > > PR c++/70001 > * constexpr.c (cxx_eval_vec_init_1): Reuse CONSTRUCTOR initializers > for 1..max even for

Re: [AArch64] Emit square root using the Newton series

On 03/10/16 10:52, Wilco Dijkstra wrote: > Hi Evandro, > >> I have however encountered precision issues with DF, namely some benchmarks >> in the SPECfp CPU2000 suite would fail to validate. > Accuracy is not an issue, the computation is extremely accurate. The issue is > that your patch

Re: [C++ PATCH] Reuse certain cxx_eval_constant_expression results in cxx_eval_vec_init_1 (PR c++/70001)

On Thu, Mar 10, 2016 at 01:32:10PM -0500, Patrick Palka wrote: > Looks fine to me :) On a closer look, this doesn't handle the multi-dimensional array cases, and even for single-dimensional ones will not share the CONSTRUCTOR if init_subob_ctx created one, and call init_subob_ctx many times and

Re: [C++ PATCH] Reuse certain cxx_eval_constant_expression results in cxx_eval_vec_init_1 (PR c++/70001)

OK. Jason

Re: [C++ PATCH] Reuse certain cxx_eval_constant_expression results in cxx_eval_vec_init_1 (PR c++/70001)

On Thu, Mar 10, 2016 at 12:56 PM, Jakub Jelinek wrote: > On Thu, Mar 10, 2016 at 06:37:32PM +0100, Jakub Jelinek wrote: >> On Thu, Mar 10, 2016 at 12:34:40PM -0500, Patrick Palka wrote: >> > Doesn't this mean that we call initializer_constant_valid_p at each >> > iteration?

LRA remat issue with hard regs (PR70123)

When I submitted my previous lra-remat patch, I mentioned I had some concerns about the way we dealt with register number comparisons, but I didn't want to change things blindly without a testcase. PR70123 has now provided such a testcase where we are trying to rematerialize a hard register

Re: [C++ PATCH] Reuse certain cxx_eval_constant_expression results in cxx_eval_vec_init_1 (PR c++/70001)

On Thu, Mar 10, 2016 at 06:37:32PM +0100, Jakub Jelinek wrote: > On Thu, Mar 10, 2016 at 12:34:40PM -0500, Patrick Palka wrote: > > Doesn't this mean that we call initializer_constant_valid_p at each > > iteration? This would slow down the non-constant case even further. > > So I wonder if the

Re: Fix 70083, lra-induced crash

On 03/10/2016 03:26 AM, Bernd Schmidt wrote: This crash happens because LRA tries to save an AVX hard reg in a large mode, and it only appears in the function in smaller modes. Stack alignment isn't set up to support the larger mode. Currently, biggest_mode for hard registers is set up from

Re: [C++ PATCH] Reuse certain cxx_eval_constant_expression results in cxx_eval_vec_init_1 (PR c++/70001)

On Thu, Mar 10, 2016 at 12:34:40PM -0500, Patrick Palka wrote: > Doesn't this mean that we call initializer_constant_valid_p at each > iteration? This would slow down the non-constant case even further. > So I wonder if the return value of initializer_constant_valid_p could > be cached or

Re: [C++ PATCH] Reuse certain cxx_eval_constant_expression results in cxx_eval_vec_init_1 (PR c++/70001)

On Thu, Mar 10, 2016 at 12:03 PM, Jakub Jelinek wrote: > Hi! > > As mentioned in the PR, the compile time and compile memory are wasted > if a large array is is using value or default initialization, and > if the resulting initializer value is simple enough, we can just share >

Re: RFA: PR 70044: Catch a second call to aarch64_override_options_after_change

Hi James, >> OK to apply ? > > OK, thanks. Thanks - applied. >>> Note that this patch would expose a bug in >>> common/config/aarch64/aarch64-common.c >>> where there's a thinko in the handling of OPT_momit_leaf_frame_pointer. >>> That's my bad and I'll propose a patch for it soon. > > I

Re: [C++ PATCH] Reuse certain cxx_eval_constant_expression results in cxx_eval_vec_init_1 (PR c++/70001)

OK. Jason

Re: [C++ RFC] magic_varargs_p issues (PR c++/70144)

On Wed, Mar 09, 2016 at 06:18:31PM +0100, Jakub Jelinek wrote: > So, what approach do you prefer? I've so far bootstrapped/regtested the > second patch, which showed those > +FAIL: g++.dg/cilk-plus/AN/builtin_fn_custom_tplt.cc > +UNRESOLVED: g++.dg/cilk-plus/AN/builtin_fn_custom_tplt.cc > +FAIL:

[C++ PATCH] Reuse certain cxx_eval_constant_expression results in cxx_eval_vec_init_1 (PR c++/70001)

Hi! As mentioned in the PR, the compile time and compile memory are wasted if a large array is is using value or default initialization, and if the resulting initializer value is simple enough, we can just share it by all the elements. Bootstrapped/regtested on x86_64-linux and i686-linux, ok

Re: [AArch64] Emit square root using the Newton series

On 03/10/16 10:52, Wilco Dijkstra wrote: Hi Evandro, I have however encountered precision issues with DF, namely some benchmarks in the SPECfp CPU2000 suite would fail to validate. Accuracy is not an issue, the computation is extremely accurate. The issue is that your patch doesn't support

Re: [AArch64] Emit square root using the Newton series

Hi Evandro, > I have however encountered precision issues with DF, namely some benchmarks > in the SPECfp CPU2000 suite would fail to validate. Accuracy is not an issue, the computation is extremely accurate. The issue is that your patch doesn't support sqrt(0.0) - it returns NaN rather than

Re: [RFC][PR69708] IPA inline not working for function reference in static const struc

Hi, On Tue, Mar 01, 2016 at 09:04:25AM +1100, kugan wrote: > Hi, > > As discussed in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69708 and > corresponding mailing list discussion, IPA CP is not detecting a > jump-function with the sq function as value. > > sorry it took so long for me to

Re: [PATCH][AArch64] Replace insn to zero up DF register

On Thu, Mar 10, 2016 at 10:32:15AM -0600, Evandro Menezes wrote: > >I agree to postpone until GCC 7. > > > >[AArch64] Replace insn to zero up SIMD registers > > > >gcc/ > >* config/aarch64/aarch64.md > >(*movhf_aarch64): Add "movi %0, #0" to zero up

Re: Fix ICE in initialize_node_lattices

> On Thu, Mar 10, 2016 at 05:12:59PM +0100, Jan Hubicka wrote: > > --- testsuite/g++.dg/lto/pr69589_0.C(revision 0) > > +++ testsuite/g++.dg/lto/pr69589_0.C(working copy) > > @@ -0,0 +1,26 @@ > > +// { dg-lto-do link } > > +// { dg-lto-options "-O2 -rdynamic" } > > Shouldn't this

Re: [PATCH][AArch64] Replace insn to zero up DF register

On 03/10/16 10:27, Evandro Menezes wrote: On 03/10/16 07:23, James Greenhalgh wrote: On Wed, Mar 09, 2016 at 03:35:43PM -0600, Evandro Menezes wrote: On 03/01/16 13:08, Evandro Menezes wrote: On 03/01/16 13:02, Wilco Dijkstra wrote: Evandro Menezes wrote: The meaning of these attributes are

Re: [PATCH][AArch64] Replace insn to zero up DF register

On 03/10/16 07:23, James Greenhalgh wrote: On Wed, Mar 09, 2016 at 03:35:43PM -0600, Evandro Menezes wrote: On 03/01/16 13:08, Evandro Menezes wrote: On 03/01/16 13:02, Wilco Dijkstra wrote: Evandro Menezes wrote: The meaning of these attributes are not clear to me. Is there a reference

Re: [PATCH][AArch64] Fix thinko in handling of -momit-leaf-frame-pointer option

On Thu, Mar 10, 2016 at 03:42:38PM +, Kyrill Tkachov wrote: > Hi all, > > When extending the aarch64_handle_option function for GCC 6 I introduced a > thinko > when handling the -momit-leaf-frame-pointer option and had it set the variable > for -fomit-frame-pointer instead. This hasn't been

Re: Fix ICE in initialize_node_lattices

On Thu, Mar 10, 2016 at 05:12:59PM +0100, Jan Hubicka wrote: > --- testsuite/g++.dg/lto/pr69589_0.C (revision 0) > +++ testsuite/g++.dg/lto/pr69589_0.C (working copy) > @@ -0,0 +1,26 @@ > +// { dg-lto-do link } > +// { dg-lto-options "-O2 -rdynamic" } Shouldn't this have // {

Re: [PATCH] Add -funconstrained-commons to work around PR/69368 (and others) in SPEC2006

Alan, The test gfortran.dg/unconstrained_commons.f fails in the 32 bit mode. It needs some regexp capturing mycommon.x[j_1] = _5; as in " mycommon\.x\[.?_[0-9]+\] = _[0-9]+;" TIA Dominique

Fix ICE in initialize_node_lattices

Hi, this patch fixes ICE in ipa-cp that detects local function that is dead. The issue is that virutal functions may have no address taken but still may be virtual call targets. This patch makes remove_unreachable_nodes to handle this and not mark them local (since they are not) Honza *

Better fix for PR69630

Hi, my first fix was just partial and fixed ICE in one branch not in other. The issue is that code does not expect cxa_pure_virtual in target list and ICEs handling it as a method while checking whether it should suggest final. Bootstrapped/regtested x86_64-linux, comitted. ipa/69630

Re: RFA: PR 70044: Catch a second call to aarch64_override_options_after_change

On 10/03/16 15:23, James Greenhalgh wrote: On Mon, Mar 07, 2016 at 01:12:16PM +, Nick Clifton wrote: Hi Kyrill, This is missing a second hunk from the patch you attached in the PR that I think is necessary for this to work (setting to x_flag_omit_frame_pointer)... Doh! Silly me -

[PATCH][AArch64] Fix thinko in handling of -momit-leaf-frame-pointer option

Hi all, When extending the aarch64_handle_option function for GCC 6 I introduced a thinko when handling the -momit-leaf-frame-pointer option and had it set the variable for -fomit-frame-pointer instead. This hasn't been particularly impactful because -momit-leaf-frame-pointer is on by default

Re: Add C++ special math functions to C++17

On 03/10/2016 05:24 AM, Tobias Burnus wrote: Ed Smith-Rowland wrote: --- include/bits/specfun.h (svn+ssh://e...@gcc.gnu.org/svn/gcc/trunk/libstdc++-v3/include) (working copy) +++ svn+ssh://e...@gcc.gnu.org/svn/gcc/trunk/libstdc++-v3/include (revision 234098) @@ -1,6 +1,6 @@ //

Re: RFA: PR 70044: Catch a second call to aarch64_override_options_after_change

On Mon, Mar 07, 2016 at 01:12:16PM +, Nick Clifton wrote: > Hi Kyrill, > > > This is missing a second hunk from the patch you attached in the PR that I > > think is necessary > > for this to work (setting to x_flag_omit_frame_pointer)... > > Doh! Silly me - there was a snafu restoring the

Re: C++ PATCH for c++/70153 (unhandled UNARY_PLUS_EXPR causes stack overflow)

On Thu, Mar 10, 2016 at 09:59:07AM -0500, Jason Merrill wrote: > On 03/10/2016 09:53 AM, Marek Polacek wrote: > >+case UNARY_PLUS_EXPR: > >+ op0 = cp_fold_maybe_rvalue (TREE_OPERAND (x, 0), rval_ops); > > You can just use cp_fold_rvalue here. OK with that change. Thanks. Final patch

Re: C++ PATCH for c++/70153 (unhandled UNARY_PLUS_EXPR causes stack overflow)

On 03/10/2016 09:53 AM, Marek Polacek wrote: +case UNARY_PLUS_EXPR: + op0 = cp_fold_maybe_rvalue (TREE_OPERAND (x, 0), rval_ops); You can just use cp_fold_rvalue here. OK with that change. Jason

Re: C++ PATCH for c++/70153 (unhandled UNARY_PLUS_EXPR causes stack overflow)

On Thu, Mar 10, 2016 at 09:34:17AM -0500, Jason Merrill wrote: > On 03/10/2016 08:07 AM, Marek Polacek wrote: > >On Thu, Mar 10, 2016 at 01:56:41PM +0100, Jakub Jelinek wrote: > >>On Thu, Mar 10, 2016 at 01:46:45PM +0100, Marek Polacek wrote: > >>>2016-03-10 Marek Polacek >

Re: [PATCH][AArch64] PR target/70002: Make aarch64_set_current_function play nice with pragma resetting

On Thu, Mar 03, 2016 at 11:38:11AM +, Kyrill Tkachov wrote: > Hi all, > > This patch fixes the ICE that was introduced by my earlier patch to > aarch64_set_current_function: > FAIL: gcc.dg/torture/pr52429.c -O2 -flto -fno-use-linker-plugin > -flto-partition=none (internal compiler error) >

Re: C++ PATCH for c++/70153 (unhandled UNARY_PLUS_EXPR causes stack overflow)

On 03/10/2016 08:07 AM, Marek Polacek wrote: On Thu, Mar 10, 2016 at 01:56:41PM +0100, Jakub Jelinek wrote: On Thu, Mar 10, 2016 at 01:46:45PM +0100, Marek Polacek wrote: 2016-03-10 Marek Polacek PR c++/70153 * cp-gimplify.c (cp_fold): Handle

Re: [committed, libffi] Match upstream soname

On Thu, Mar 10, 2016 at 3:03 PM, Matthias Klose wrote: > On 07.03.2016 12:59, Richard Henderson wrote: >> >> On 03/06/2016 07:24 PM, Matthias Klose wrote: >>> >>> On 05.03.2016 19:28, Richard Henderson wrote: When I went to apply my symbol versioning patch to upstream,

Re: [committed, libffi] Match upstream soname

On 07.03.2016 12:59, Richard Henderson wrote: On 03/06/2016 07:24 PM, Matthias Klose wrote: On 05.03.2016 19:28, Richard Henderson wrote: When I went to apply my symbol versioning patch to upstream, I discovered that upstream had already bumped their soname to 6.4.0, beyond the bump that I'd

[arm-embedded][PATCH][ARM] Make Cortex-R8 use ARMv7 multilib

On 09/03/16 16:55, Andre Vieira (lists) wrote: > Hi there, > > This patch adds cortex-r8 to the list of cores using the armv7 multilib. > > This patch is based on Thomas' multilib patch series: > https://gcc.gnu.org/ml/gcc-patches/2015-12/msg01584.html >

[Patch, avr]Fix multiple ICE fallout of PR 69764

Hi, This patch fixes ~230 internal compiler errors that showed up after the fix for PR 69764. After the patch, target backends need to explicitly specify mode for operand 2 of shift and rotate patterns - see md.texi mod at

[arm-embedded][PATCH 2/2][GCC][ARM] Fix testcases after introduction of Cortex-R8

On 09/03/16 16:57, Andre Vieira (lists) wrote: > On 08/03/16 14:56, Kyrill Tkachov wrote: >> Hi Andre, >> >> On 08/03/16 11:05, Andre Vieira (lists) wrote: >>> On 03/03/16 11:28, Kyrill Tkachov wrote: Hi Andre, On 02/03/16 12:21, Andre Vieira (lists) wrote: > Hi, > >

[arm-embedded][PATCH 1/2][GCC][ARM] Add support for Cortex-R8

On 02/03/16 12:20, Andre Vieira (lists) wrote: > > gcc/ChangeLog: > > 2016-03-02 Andre Vieira > > * config/arm/arm-cores.def (cortex-r8): New. > * config/arm/arm-tables.opt (cortex-r8): New. > * config/arm/arm-tune.md: Regenerate. > *

[arm-embedded][PATCH 2/2][GCC][ARM] Fix testcases after introduction of Cortex-R8

On 02/03/16 12:21, Andre Vieira (lists) wrote: > Hi, > > Tests used to check for "r8" which will not work because cortex-r8 > string is now included in the assembly. Fixed by checking for "[^\-]r8". > > Is this Ok? > > Cheers, > Andre > > gcc/testsuite/ChangeLog: > > 2016-03-02 Andre Vieira

Re: [AArch64] Disable pcrelative_literal_loads with fix-cortex-a53-843419

On Thu, Mar 10, 2016 at 01:37:50PM +0100, Christophe Lyon wrote: > On 10 March 2016 at 12:43, James Greenhalgh wrote: > > On Tue, Jan 26, 2016 at 03:43:36PM +0100, Christophe Lyon wrote: > >> With the attachment > >> > >> > >> On 26 January 2016 at 15:42, Christophe

Re: [PATCH][AArch64] Replace insn to zero up DF register

On Wed, Mar 09, 2016 at 03:35:43PM -0600, Evandro Menezes wrote: > On 03/01/16 13:08, Evandro Menezes wrote: > >On 03/01/16 13:02, Wilco Dijkstra wrote: > >>Evandro Menezes wrote: > >>>The meaning of these attributes are not clear to me. Is there a > >>>reference somewhere about which insns are

Re: [ptx] debug info

On Thu, 10 Mar 2016, Nathan Sidwell wrote: > Hm, something must have changed since I found that sorry neccessary. As I already said in my opening sentence (not quoted in your response), you removed the unnecessary override. This is exactly what lets toplevel code see requested debug format now,

Re: [ptx] debug info

On 03/10/16 07:52, Alexander Monakov wrote: On Wed, 9 Mar 2016, Nathan Sidwell wrote: Furthermore, this is not useful without support in libgomp/plugin-nvptx.c and nvptx-none-run.c (PTX JIT does not propagate lineinfo by default). Would you like me to submit patches for those? please.

Re: C++ PATCH for c++/70153 (unhandled UNARY_PLUS_EXPR causes stack overflow)

On Thu, Mar 10, 2016 at 01:56:41PM +0100, Jakub Jelinek wrote: > On Thu, Mar 10, 2016 at 01:46:45PM +0100, Marek Polacek wrote: > > 2016-03-10 Marek Polacek > > > > PR c++/70153 > > * cp-gimplify.c (cp_fold): Handle UNARY_PLUS_EXPR. > > > > *

Re: [ptx] debug info

On 03/09/16 11:41, Alexander Monakov wrote: :|x86_64-pc-linux-gnu-accel-nvptx-none-gcc -xc - -S -o- -gstabs :1:0: sorry, unimplemented: stabs debug format not supported cc1: error: target system does not support the ‘stabs’ debug format :|x86_64-pc-linux-gnu-accel-nvptx-none-gcc -xc - -S -o-

Re: C++ PATCH for c++/70153 (unhandled UNARY_PLUS_EXPR causes stack overflow)

On Thu, Mar 10, 2016 at 01:46:45PM +0100, Marek Polacek wrote: > 2016-03-10 Marek Polacek > > PR c++/70153 > * cp-gimplify.c (cp_fold): Handle UNARY_PLUS_EXPR. > > * g++.dg/delayedfold/unary-plus1.C: New test. > > diff --git gcc/cp/cp-gimplify.c

Re: [ptx] debug info

On Wed, 9 Mar 2016, Nathan Sidwell wrote: > > Furthermore, this is not useful without support in libgomp/plugin-nvptx.c > > and nvptx-none-run.c (PTX JIT does not propagate lineinfo by default). > > Would you like me to submit patches for those? > > please. Here's the pull request for

C++ PATCH for c++/70153 (unhandled UNARY_PLUS_EXPR causes stack overflow)

Here, we got ourselves into infinite recursion in fold, resulting in a stack overflow. I believe the crux is that we're passing UNARY_PLUS_EXPR, a C++-only code, into fold which can't really fold e.g. 1 + UNARY_PLUS_EXPR <1>. I think cp_fold should be able to fold this to 2, but currently is

Re: [AArch64] Disable pcrelative_literal_loads with fix-cortex-a53-843419

On 10 March 2016 at 12:43, James Greenhalgh wrote: > On Tue, Jan 26, 2016 at 03:43:36PM +0100, Christophe Lyon wrote: >> With the attachment >> >> >> On 26 January 2016 at 15:42, Christophe Lyon >> wrote: >> > Hi, >> > >> > This is a

Re: [PATCH][AArch64] PR target/70002: Make aarch64_set_current_function play nice with pragma resetting

Ping. https://gcc.gnu.org/ml/gcc-patches/2016-03/msg00237.html Thanks, Kyrill On 03/03/16 11:38, Kyrill Tkachov wrote: Hi all, This patch fixes the ICE that was introduced by my earlier patch to aarch64_set_current_function: FAIL: gcc.dg/torture/pr52429.c -O2 -flto -fno-use-linker-plugin

Re: [AArch64] Disable pcrelative_literal_loads with fix-cortex-a53-843419

On Tue, Jan 26, 2016 at 03:43:36PM +0100, Christophe Lyon wrote: > With the attachment > > > On 26 January 2016 at 15:42, Christophe Lyon > wrote: > > Hi, > > > > This is a followup to PR63304. > > > > As discussed in bugzilla, this patch disables

Re: [AArch64] Fix dependency of gcc-plugin.h

On Tue, Mar 08, 2016 at 03:20:52PM +0100, Christophe Lyon wrote: > Hi, > > Our bug report https://bugs.linaro.org/show_bug.cgi?id=2123 > complains about aarch64's missing plugin dependency. > > IFAIT, the problem is present on trunk too, and the small attached > patch fixes it. > OK? This is

Re: [PATCH] Additional check for mask type in masked load/store vectorization

On Thu, Mar 10, 2016 at 11:12 AM, Ilya Enkovich wrote: > Hi, > > Curently when vectorizing masked load/store we don't check > mask and value have the same number of elements. Usually > conversion patterns apply and we don't have such case but > conversion patterns may

Re: [PATCH] Add -funconstrained-commons to work around PR/69368 (and others) in SPEC2006

On Wed, Mar 9, 2016 at 6:54 PM, Alan Lawrence wrote: > On 07/03/16 11:02, Alan Lawrence wrote: >> >> On 04/03/16 13:27, Richard Biener wrote: >>> >>> I think to make it work with LTO you need to mark it 'Optimization'. >>> Also it's about >>> arrays so maybe >>> >>>

Re: Add C++ special math functions to C++17

Ed Smith-Rowland wrote: > --- include/bits/specfun.h > (svn+ssh://e...@gcc.gnu.org/svn/gcc/trunk/libstdc++-v3/include) (working copy) > +++ svn+ssh://e...@gcc.gnu.org/svn/gcc/trunk/libstdc++-v3/include > (revision 234098) > @@ -1,6 +1,6 @@ > // Mathematical Special Functions for -*- C++

[PATCH] Additional check for mask type in masked load/store vectorization

Hi, Curently when vectorizing masked load/store we don't check mask and value have the same number of elements. Usually conversion patterns apply and we don't have such case but conversion patterns may fail to properly determine mask type and we shouldn't rely on it so hard. Unfortunately I

Re: [PATCH 2/2][GCC][ARM] Fix testcases after introduction of Cortex-R8

On 09/03/16 17:03, Mike Stump wrote: > On Mar 9, 2016, at 8:57 AM, Andre Vieira (lists) > wrote: >>> I'm seeing a DejaGNU error while testing >>> RUNTESTFLAGS="arm.exp=pr45701-*.c": >>> ERROR: (DejaGnu) proc "^-" does not exist. > >> 2016-03-09 Andre Vieira

Re: [PATCH] PR69195, Reload confused by invalid reg equivs

On 03/10/2016 10:18 AM, Alan Modra wrote: Doing the indirect jump optimization turned out to be quite easy. Bootstrapped and regression tested powerpc64le-linux, gcc-6, gcc-5 and gcc-4.9. Bootstrap and regression test x86_64-linux still running. OK to apply? So much nicer. Ok, and thanks.

[PATCH] PR69195, Reload confused by invalid reg equivs

Doing the indirect jump optimization turned out to be quite easy. Bootstrapped and regression tested powerpc64le-linux, gcc-6, gcc-5 and gcc-4.9. Bootstrap and regression test x86_64-linux still running. OK to apply? gcc/ PR rtl-optimization/69195 PR rtl-optimization/47992

Re: [PATCH 2/2][GCC][ARM] Fix testcases after introduction of Cortex-R8

On 09/03/16 16:57, Andre Vieira (lists) wrote: On 08/03/16 14:56, Kyrill Tkachov wrote: Hi Andre, On 08/03/16 11:05, Andre Vieira (lists) wrote: On 03/03/16 11:28, Kyrill Tkachov wrote: Hi Andre, On 02/03/16 12:21, Andre Vieira (lists) wrote: Hi, Tests used to check for "r8" which will

Re: [RFC] dump_varmap in tree-ssa-structalias.c

On Thu, 10 Mar 2016, Tom de Vries wrote: > Hi, > > I wrote attached patch to print the actual contents of the varmap variable in > tree-ssa-structalias.c. > > Does it make sense to rewrite this into a dump_varmap/debug_varmap patch? Yes (but please not dump it by default) and I'd rather have a

Re: Add C++ special math functions to C++17

On 03/10/2016 03:48 AM, Jakub Jelinek wrote: On Thu, Mar 10, 2016 at 03:44:26AM -0500, Ed Smith-Rowland wrote: Here is a small patch to allow the special maths functions that came in with TR29124 into C++17 in Jacksonville. I am leaving the TR29124 access with __STDCPP_WANT_MATH_SPEC_FUNCS__

Re: Add C++ special math functions to C++17

On Thu, Mar 10, 2016 at 03:44:26AM -0500, Ed Smith-Rowland wrote: > Here is a small patch to allow the special maths functions that came in with > TR29124 into C++17 in Jacksonville. > I am leaving the TR29124 access with __STDCPP_WANT_MATH_SPEC_FUNCS__ for C++ > < 17. > > I added the SD-6

Add C++ special math functions to C++17

Here is a small patch to allow the special maths functions that came in with TR29124 into C++17 in Jacksonville. I am leaving the TR29124 access with __STDCPP_WANT_MATH_SPEC_FUNCS__ for C++ < 17. I added the SD-6 feature macro: #define __cpp_lib_math_special_functions 20163L Passes testing on

Fix 69650, bogus line numbers from libcpp

This is a case where bogus #line directives can confuse libcpp into producing nonsensical line numbers, even leading to a crash later on in LTO. The following patch moves the test earlier to a point where we can more easily recover from the error condition. I should note that I changed the

[committed][testsuite] Xfail pr46032.c scan if alignment requirements not met

Hi, this patch fixes re-opened PR68915 on sparc. It xfails a scan line that's not applicable for sparc. Committed to trunk. Thanks, - Tom Xfail pr46032.c scan if alignment requirements not met 2016-03-10 Tom de Vries PR testsuite/68915 * gcc.dg/vect/pr46032.c:

Fix 70083, lra-induced crash

This crash happens because LRA tries to save an AVX hard reg in a large mode, and it only appears in the function in smaller modes. Stack alignment isn't set up to support the larger mode. Currently, biggest_mode for hard registers is set up from regno_reg_rtx, set up to a large mode for

[PATCH] Fix PR70128

The following fixes a miscompilation of the linux kernel which does patching of instructions by accessing memory relative to function addresses (that's undefined in C and won't work for targets using function descriptors but hey - those guys say they know what they are doing). Thus the following