RE: [PATCH, ARM, ping1] Fix gcc.c-torture/execute/loop-2b.c execution failure on cortex-m0

Ping? > -Original Message- > From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches- > ow...@gcc.gnu.org] On Behalf Of Thomas Preud'homme > Sent: Wednesday, December 16, 2015 5:11 PM > To: gcc-patches@gcc.gnu.org; Richard Earnshaw; Ramana Radhakrishnan; > Kyrylo Tkachov > Subject:

[AArch32][NEON] Implementing vmaxnmQ_ST and vminnmQ_ST intrinsics.

This patch implements the vmaxnmQ_ST and vminnmQ_ST intrinsics. The current builtin registration code is deficient since it can't access standard pattern names, to which vmaxnmQ_ST and vminnmQ_ST map directly. Thus, to enable the vectoriser to have access to these intrinsics, we implement them

Re: [PATCH, GCC] Fix PR67781: wrong code generation for partial load on big endian targets

On Tue, 5 Jan 2016, Thomas Preud'homme wrote: > Hi, > > bswap optimization pass generate wrong code on big endian targets when the > result of a bit operation it analyzed is a partial load of the range of > memory > accessed by the original expression (when one or more bytes at lowest address

Re: [PATCH] Fix incorrect gimple_build arguments in gimple-fold.c (PR tree-optimization/69172)

On Thu, 7 Jan 2016, Jakub Jelinek wrote: > Hi! > > gimple_build wants the type after POINTER_PLUS_EXPR, but > gimple_fold_builtin_memory_chk wasn't passing it. > > Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for > trunk? Oops, yes. Thanks, Richard. > 2016-01-07

Re: [PATCH, testsuite] Fix g++.dg/pr67989.C test failure when running with -march or -mcpu

On Thursday, January 07, 2016 10:26:28 AM Richard Earnshaw wrote: > On 07/01/16 09:15, Kyrill Tkachov wrote: > > In this case perhaps we should go the route of just removing the > > target-specific option > > altogether. > > > > Richard, that's the approach you recommended, right? > > Yes. > >

Re: [PATCH] Handle BUILT_IN_GOACC_PARALLEL in ipa-pta

On Wed, 16 Dec 2015, Tom de Vries wrote: > On 10/12/15 14:14, Tom de Vries wrote: > > [ copy-pasting-with-quote from > > https://gcc.gnu.org/ml/gcc-patches/2015-12/msg00420.html , for some > > reason I didn't get this email ] > > > > > On Thu, 3 Dec 2015, Tom de Vries wrote: > > > > The flag is

Re: [PATCH 5/5] Fix intransitive comparison in dr_group_sort_cmp

On Sat, 19 Dec 2015, Yuri Gribov wrote: > On Fri, Dec 18, 2015 at 11:20 PM, Yury Gribov wrote: > > On 12/17/2015 03:51 PM, Richard Biener wrote: > >> > >> On Thu, 17 Dec 2015, Yury Gribov wrote: > >> > >>> On 12/17/2015 02:57 PM, Richard Biener wrote: > > On Thu,

RE: Fix 61441 [5/5] Disable various transformations for signaling NaN operands

Hi, > If you have access to x86_64-linux, you can easily test it yourself with: > make -C gcc check-gcc RUNTESTFLAGS='--target_board=unix\{-m64,-m32/- > march=i386\} dg.exp=pr61441.c' > > Your patch does help. Thanks, I tested the changes and it worked fine. > issignalling is a GNU extension

Re: [PATCH] Fix (ab) SSA_NAME issue in gimple folding (PR tree-optimization/69167)

On Thu, 7 Jan 2016, Jakub Jelinek wrote: > Hi! > > Various places check that (ab) SSA_NAMEs that weren't referenced on a stmt > before don't appear on it, but all the checking is done on the gimple tuple > operands, while in this case it is added to operands of a comparison of >

Re: [PATCH] Fix ICE with va_arg (PR tree-optimization/69162)

On Thu, 7 Jan 2016, Jakub Jelinek wrote: > Hi! > > The addition of IFN_VA_ARG which is only during stdarg pass lowered > introduced ICE on the following testcase. The problem is that > we expected that the type the first argument of the internal call points > to will remain the one that used to

Re: [RFA] [PATCH][PR tree-optimization/64910] Fix reassociation of binary bitwise operations with 3 operands

On Tue, Dec 22, 2015 at 12:39 AM, Jeff Law wrote: > > As outlined in the BZ, given > > (x & y) & C > > reassociation will turn that into > > (x & C) & y > > Which inhibits bit operations on various targets. > > Associating as > > (x & y) & C > > is what we want. > > My original

[patch] libstdc++/14608 Add C++-conforming wrappers for stdlib.h and math.h

This resolves the longstanding issue that #include uses the C library header, which on most targets doesn't declare the additional overloads required by C++11 26.8 [c.math], and similarly for . With this patch libstdc++ provides its own and wrappers, which are equivalent to or followed by

Re: C++ PATCH for c++/68449 (segv with compound statement)

On Fri, Jan 08, 2016 at 12:56:15PM -0500, Jason Merrill wrote: > On 01/08/2016 12:48 PM, Marek Polacek wrote: > > if (tree *p = ctx->values->get (r)) > > r = *p; > >- if (DECL_P (r)) > >+ if (r == NULL_TREE || DECL_P (r)) > > I think it would be a bit better not to change r if

C++ PATCH for c++/68449 (segv with compound statement)

An attempt to fix c++/68449. We ICEd because pointer returned from ctx->values->get points to NULL, so checking DECL_P on that is no no. Fixed along the lines Jakub suggested in the PR. Bootstrapped/regtested on x86_64-linux, ok for trunk? 2016-01-08 Marek Polacek

Re: C PATCH to rectify warning for character types (PR c/23087)

On 01/07/2016 10:19 PM, Joseph Myers wrote: I don't think it's desirable to raise the warning for this case under different conditions from the warning for other signedness cases. The targets do differ in signedness - it's just that the difference is between "plain" and "signed" or "plain" and

Re: C PATCH to rectify warning for character types (PR c/23087)

On Fri, Jan 08, 2016 at 06:54:32PM +0100, Bernd Schmidt wrote: > On 01/07/2016 10:19 PM, Joseph Myers wrote: > > >I don't think it's desirable to raise the warning for this case under > >different conditions from the warning for other signedness cases. The > >targets do differ in signedness -

Re: C PATCH to rectify warning for character types (PR c/23087)

On 01/07/2016 02:19 PM, Joseph Myers wrote: On Thu, 7 Jan 2016, Marek Polacek wrote: This PR points out that we issue a wrong warning message when assigning two pointers when one of them is plain char. In that case, the compiler currently says that pointer targets differ in signedness. But

Re: [PATCH] Remove PTX link option

On 01/08/2016 10:32 AM, Jakub Jelinek wrote: On Fri, Jan 08, 2016 at 10:21:16AM -0600, James Norris wrote: And CU_JIT_TARGET / CU_TARGET_COMPUTE_30 requests JITting only on sm_30 and nothing else, or just on sm_30 or later, something else? This really should be reviewed by somebody familiar

Re: C++ PATCH for c++/68449 (segv with compound statement)

On 01/08/2016 12:48 PM, Marek Polacek wrote: if (tree *p = ctx->values->get (r)) r = *p; - if (DECL_P (r)) + if (r == NULL_TREE || DECL_P (r)) I think it would be a bit better not to change r if *p is null. OK with that change. Jason

[PATCH] Fix X % -Y => X % Y optimization (PR tree-optimization/69097, PR middle-end/50865)

Hi! As mentioned in the PRs, the X % -Y to X % Y optimization for signed modulo is not valid unless we can prove that it won't be INT_MIN % -(-1), which is valid, but where INT_MIN % -1 is invalid. The following patch use range info to figure that out. Bootstrapped/regtested on x86_64-linux and

[PATCH] Handle inter-block notes before BARRIER in rtl merge_blocks (PR target/69175)

Hi! As mentioned in the PR, sched1 and reload add NOTE_INSN_DELETED notes that are moved by shrink-wrapping in between some basic blocks and later on we end up with a barrier after the notes. From comments above cleanup_barriers pass I think it isnot invalid, and various other places deal with

Re: [PATCH] Fix memory alignment on AVX512VL masked floating point stores (PR target/69198)

On Fri, Jan 8, 2016 at 12:44 PM, Jakub Jelinek wrote: > On Fri, Jan 08, 2016 at 12:39:50PM -0800, H.J. Lu wrote: >> > p is not misaligned, it has just unknown alignment. >> >> And it may be 8 byte aligned. > > Yes. But if you call the routine with just 8 byte aligned p, > you

[PATCH] PR preprocessor/69177 and PR c++/68819: libcpp fallbacks and -Wmisleading-indentation (v2)

On Mon, 2015-12-21 at 14:10 -0700, Jeff Law wrote: > On 12/18/2015 01:21 PM, David Malcolm wrote: > > > I don't think there's a way to fix -Wmisleading-indentation if we're > > in this state, so the first part of the following patch detects if > > this has happened, and effectively turns off

Re: [PR ipa/66616] Fix artificial thunk ABI issues

> Hi, > > i386 -m32 failure of the PR 66616 testcase was caused by the fact > that, on the callee side, the calling conventions of a thunk are > decided according to the properties of the function it is associated > with, but on the caller side, the actual thunk is examined. Since > they depend

C++ PATCH for c++/69113 (ICE with -fno-weak)

Looking at the second Jason's patch here it seems that we should never set DECL_COMDAT on a decl that is !TREE_PUBLIC. The following test was breaking with -fno-weak, because there we set DECL_COMDAT on something that was !TREE_PUBLIC

Re: [PATCH] Fix memory alignment on AVX512VL masked floating point stores (PR target/69198)

On Fri, Jan 08, 2016 at 12:28:43PM -0800, H.J. Lu wrote: > gcc.target/i386/avx512vl-vmovapd-1.c has > > --- > include > > double *p; > volatile __m256d yy, y2; > volatile __m128d xx, x2; > volatile __mmask8 m; > > void extern > avx512vl_test (void) > { > yy = _mm256_mask_mov_pd (yy, m, y2);

Re: [PATCH] Fix memory alignment on AVX512VL masked floating point stores (PR target/69198)

On Fri, Jan 08, 2016 at 12:46:01PM -0800, H.J. Lu wrote: > On Fri, Jan 8, 2016 at 12:44 PM, Jakub Jelinek wrote: > > On Fri, Jan 08, 2016 at 12:39:50PM -0800, H.J. Lu wrote: > >> > p is not misaligned, it has just unknown alignment. > >> > >> And it may be 8 byte aligned. > > >

Re: [PATCH] Fix memory alignment on AVX512VL masked floating point stores (PR target/69198)

On Fri, Jan 8, 2016 at 12:48 PM, Jakub Jelinek wrote: > On Fri, Jan 08, 2016 at 12:46:01PM -0800, H.J. Lu wrote: >> On Fri, Jan 8, 2016 at 12:44 PM, Jakub Jelinek wrote: >> > On Fri, Jan 08, 2016 at 12:39:50PM -0800, H.J. Lu wrote: >> >> > p is not misaligned,

Re: [PATCH] Fix memory alignment on AVX512VL masked floating point stores (PR target/69198)

On Fri, Jan 08, 2016 at 01:27:08PM -0800, H.J. Lu wrote: > > That is just wrong and will severely pessimize correct code. > > Please don't waste time on that. > > > > Do you have an example to show it will pessimize correct code? Anything where the compiler can't figure out alignment info and

Re: [ARM][PR69194] Fix ICE in in extract_insn

On Fri, Jan 08, 2016 at 11:43:34AM -0800, Jim Wilson wrote: > Here is a smaller simpler testcase. Only the first four args get > passed in regs, so the fifth one has address equal to the virtual > incoming args reg which triggers the failure. > > typedef __simd128_float32_t float32x4_t; >

[PATCH] Fix memory alignment on AVX512VL masked floating point stores (PR target/69198)

Hi! This patch fixes FAIL: gcc.target/i386/avx512vl-vmovapd-1.c scan-assembler-times vmovapd[ t]+[^{\\n]*%xmm[0-9]+[^\\n]*){%k[1-7]}(?:\\n|[ t]+#) 1 FAIL: gcc.target/i386/avx512vl-vmovapd-1.c scan-assembler-times vmovapd[ t]+[^{\\n]*%ymm[0-9]+[^\\n]*){%k[1-7]}(?:\\n|[

Re: [PATCH] Fix memory alignment on AVX512VL masked floating point stores (PR target/69198)

On Fri, Jan 8, 2016 at 12:20 PM, Jakub Jelinek wrote: > Hi! > > This patch fixes > FAIL: gcc.target/i386/avx512vl-vmovapd-1.c scan-assembler-times vmovapd[ > t]+[^{\\n]*%xmm[0-9]+[^\\n]*){%k[1-7]}(?:\\n|[ t]+#) 1 > FAIL: gcc.target/i386/avx512vl-vmovapd-1.c

Re: [PATCH] Fix memory alignment on AVX512VL masked floating point stores (PR target/69198)

On Fri, Jan 8, 2016 at 12:35 PM, Jakub Jelinek wrote: > On Fri, Jan 08, 2016 at 12:28:43PM -0800, H.J. Lu wrote: >> gcc.target/i386/avx512vl-vmovapd-1.c has >> >> --- >> include >> >> double *p; >> volatile __m256d yy, y2; >> volatile __m128d xx, x2; >> volatile __mmask8 m; >>

Re: [PATCH] Fix (ab) SSA_NAME issue in gimple folding (PR tree-optimization/69167, take 2)

On January 8, 2016 9:08:36 PM GMT+01:00, Jakub Jelinek wrote: >Hi! > >On Fri, Jan 08, 2016 at 10:12:09AM +0100, Richard Biener wrote: >> On Thu, 7 Jan 2016, Jakub Jelinek wrote: >> >> > Hi! >> > >> > Various places check that (ab) SSA_NAMEs that weren't referenced on >a stmt

FIx ipa-icf ICE during libreoffice build

Hi, this patch fixes an ICE on artificial VAR_DECL that has no DECL_NAME set. unit size align 16 symtab 0 alias set -1 canonical type 0x2bdd9738 precision 16 min max pointer_to_this reference_to_this > HI size unit size align 16

Re: [ARM][PR69194] Fix ICE in in extract_insn

Here is a smaller simpler testcase. Only the first four args get passed in regs, so the fifth one has address equal to the virtual incoming args reg which triggers the failure. typedef __simd128_float32_t float32x4_t; float32x4_t sub (float32x4_t a, float32x4_t b, float32x4_t c, float32x4_t d,

[PATCH] Fix (ab) SSA_NAME issue in gimple folding (PR tree-optimization/69167, take 2)

Hi! On Fri, Jan 08, 2016 at 10:12:09AM +0100, Richard Biener wrote: > On Thu, 7 Jan 2016, Jakub Jelinek wrote: > > > Hi! > > > > Various places check that (ab) SSA_NAMEs that weren't referenced on a stmt > > before don't appear on it, but all the checking is done on the gimple tuple > >

[C++ PATCH] Fix ICE with bitfields (PR c++/69164, take 2)

On Fri, Jan 08, 2016 at 09:02:34AM -0500, Jason Merrill wrote: > On 01/08/2016 07:58 AM, Jakub Jelinek wrote: > >On Fri, Jan 08, 2016 at 01:46:47PM +0100, Bernd Schmidt wrote: > >>On 01/07/2016 10:43 PM, Jakub Jelinek wrote: > >>> > >>> PR c++/69164 > >>> * class.c (layout_class_type): Also

Re: [PATCH] Fix memory alignment on AVX512VL masked floating point stores (PR target/69198)

On Fri, Jan 08, 2016 at 12:39:50PM -0800, H.J. Lu wrote: > > p is not misaligned, it has just unknown alignment. > > And it may be 8 byte aligned. Yes. But if you call the routine with just 8 byte aligned p, you invoke undefined behavior. So, there is nothing wrong on the testcase, it tests

Re: [PATCH] Handle inter-block notes before BARRIER in rtl merge_blocks (PR target/69175)

On 01/08/2016 09:17 PM, Jakub Jelinek wrote: As mentioned in the PR, sched1 and reload add NOTE_INSN_DELETED notes that are moved by shrink-wrapping in between some basic blocks and later on we end up with a barrier after the notes. From comments above cleanup_barriers pass I think it isnot

[PATCH] Fix ICE due to invalid CONST_INT in DEBUG_INSN (PR target/69071)

Hi! The following testcase ICEs, because move_plus_up attempts to optimize (subreg:HI (plus:SI (...) (const_int 0xff78)) 0) into (plus:HI (subreg:HI (...) 0) (const_int 0xff78)) which is incorrect, HImode CONST_INT with MSB set should be (const_int -136) instead. The patch also punts if the

Re: [PATCH] Fix memory alignment on AVX512VL masked floating point stores (PR target/69198)

On Fri, Jan 08, 2016 at 01:14:04PM -0800, H.J. Lu wrote: > I think the testcase should be changed to > > double __attribute__ ((aligned (32))) *p; No. > > and I am testing a different patch by removing the whole > aligned_mem stuff. That is just wrong and will severely pessimize correct code.

Re: [PATCH] Handle inter-block notes before BARRIER in rtl merge_blocks (PR target/69175)

On Fri, Jan 08, 2016 at 10:09:37PM +0100, Bernd Schmidt wrote: > On 01/08/2016 09:17 PM, Jakub Jelinek wrote: > >As mentioned in the PR, sched1 and reload add NOTE_INSN_DELETED notes > >that are moved by shrink-wrapping in between some basic blocks and > >later on we end up with a barrier after

Re: [PATCH] Fix memory alignment on AVX512VL masked floating point stores (PR target/69198)

On Fri, Jan 8, 2016 at 1:23 PM, Jakub Jelinek wrote: > On Fri, Jan 08, 2016 at 01:14:04PM -0800, H.J. Lu wrote: >> I think the testcase should be changed to >> >> double __attribute__ ((aligned (32))) *p; FYI, gcc.target/i386/avx512vl-vmovaps-1.c has float __attribute__

Re: [PATCH] Fix memory alignment on AVX512VL masked floating point stores (PR target/69198)

On Fri, Jan 8, 2016 at 1:43 PM, H.J. Lu wrote: > On Fri, Jan 8, 2016 at 1:38 PM, Jakub Jelinek wrote: >> On Fri, Jan 08, 2016 at 01:27:08PM -0800, H.J. Lu wrote: >>> > That is just wrong and will severely pessimize correct code. >>> > Please don't waste

Re: Ping: [Patch, fortran] Bug 68241 - [meta-bug] Deferred-length character - PRs50221, 68216, 63932, 66408, 67674 and 49954

Dear All, As promised, please find attached the version of this patch for 5-branch. The changes are small enough that I couldn't immediately see any changes required in the text of the ChangeLog. I will look more carefully tomorrow, add the "backported from trunk"s and the current date. I intend

Re: C PATCH to rectify warning for character types (PR c/23087)

Signedness of char (and of bit-fields) is a tristate, "signed", "unsigned" and "". My claim is that a difference between any two of those three values is essentially the same kind of difference. And so at most the wording should be adjusted (or maybe an inform ("% and % are different

Re: C PATCH to rectify warning for character types (PR c/23087)

On Fri, 8 Jan 2016, Martin Sebor wrote: > > Signedness of char (and of bit-fields) is a tristate, "signed", "unsigned" > > and "". My claim is that a difference between any two of those three > > values is essentially the same kind of difference. And so at most the > > wording should be

Re: [PR 69044] Do not clone for parameter removal when !can_change_signature

On 01/08/2016 11:01 AM, Martin Jambor wrote: Hi, we generally do not have ther ability to propagate constants to and clone CHKP instrumented functions. Therefore we do not propagate stuff into their lattices but since Honza changed cloning for all contexts heuristics a few weeks ago, we might

Re: Handle Octeon 3 not supporting MIPS paired-single instructions

On Fri, Jan 8, 2016 at 4:05 PM, Joseph Myers wrote: > The Octeon 3 processor does not support the MIPS paired-single > instructions. This results in illegal instruction errors in the > testsuite when vectorization tests try to use those instructions. > > This patch

[PATCH] PR testsuite/69181: ensure expected multiline outputs is cleared per-test

The root cause here is that the logic to reset the list of expected multiline outputs was being run from: handle-multiline-outputs, called by prune.exp's prune_gcc_output and none of that happens if the test is skipped by a target exclusion in dg-do. This patch moves the clearing of the

Re: C PATCH to rectify warning for character types (PR c/23087)

The point of this warning is that there are certain cases of incompatible types that are less serious than others - namely, those where the only aspect of the type that is different is its signedness. Those get a more specific warning, which is given under more restrictive conditions. I see.

Handle Octeon 3 not supporting MIPS paired-single instructions

The Octeon 3 processor does not support the MIPS paired-single instructions. This results in illegal instruction errors in the testsuite when vectorization tests try to use those instructions. This patch teaches the compiler about that lack of support, so that warnings are given when

Re: RFA: PR 68913: Provide weak version of __fread_chk for PR61886 test

On 01/08/2016 05:01 AM, Nick Clifton wrote: Hi Guys, OK - how about this reformulation of the pr61886 test ? The patch changes references to __fread_chk with references to just fread, which I assume will be present in all target runtime libraries. I had to add some preprocessor trickery

Re: [gomp4] private reductions

On 01/06/2016 07:55 PM, Cesar Philippidis wrote: > @@ -1384,26 +1331,9 @@ build_outer_var_ref (tree var, omp_context *ctx, bool > lastprivate = false) > x = build_simple_mem_ref (x); > } > } > - else if (is_oacc_parallel (ctx)) > -x = var; >else if (ctx->outer) > -

Re: [PATCH] Fix memory alignment on AVX512VL masked floating point stores (PR target/69198)

On Fri, Jan 8, 2016 at 1:59 PM, H.J. Lu wrote: > On Fri, Jan 8, 2016 at 1:53 PM, H.J. Lu wrote: >> On Fri, Jan 8, 2016 at 1:43 PM, H.J. Lu wrote: >>> On Fri, Jan 8, 2016 at 1:38 PM, Jakub Jelinek wrote: On

Re: [PATCH] Handle inter-block notes before BARRIER in rtl merge_blocks (PR target/69175)

On 01/08/2016 02:23 PM, Jakub Jelinek wrote: 4) compgotos moves things around even further: ... (jump_insn 118 99 91 5 (simple_return) -1 (nil) -> simple_return) ;; succ: EXIT [100.0%] ;; lr out 0 [r0] 2 [r2] 4 [r4] 13 [sp] 14 [lr] ;; live out 0 [r0] 2 [r2] 4 [r4] 13

Re: [PATCH] Handle inter-block notes before BARRIER in rtl merge_blocks (PR target/69175)

On 01/08/2016 10:23 PM, Jakub Jelinek wrote: Now, the merge_if_block caller removes the simple_return from the then_bb in preparation of the merge and expects the two bbs to be merged together, I'd be tempted to remove the barrier as well at this point. It does look like the cfgrtl code tries

Re: C PATCH to rectify warning for character types (PR c/23087)

On Fri, 8 Jan 2016, Martin Sebor wrote: > > I don't think it's desirable to raise the warning for this case under > > different conditions from the warning for other signedness cases. The > > targets do differ in signedness - it's just that the difference is between > > "plain" and "signed" or

Re: [PR tree-optimization/64946] Push integer type conversion to ABS_EXPR argument when possible.

On Fri, 8 Jan 2016, Matthew Wahab wrote: > Hello, > > The C/C++ front-ends apply type conversions to expressions using ABS > with integral arguments of type smaller than int. This means that, for > short x, ABS(x) becomes something like (short)ABS((int)x)). When the > argument is the result of

Re: [PATCH] Handle inter-block notes before BARRIER in rtl merge_blocks (PR target/69175)

On 01/08/2016 01:17 PM, Jakub Jelinek wrote: Hi! As mentioned in the PR, sched1 and reload add NOTE_INSN_DELETED notes that are moved by shrink-wrapping in between some basic blocks and later on we end up with a barrier after the notes. From comments above cleanup_barriers pass I think it

[gomp4] teach the lto driver to error for missing decls

In openacc there are situations where a user may fail to mark a variable or function as offloadable (either using declare or routine). This patch makes the lto wrapper reduce the missing decl assertion to an error. I've applied this patch to gomp-4_0-branch. Cesar 2016-01-08 Cesar Philippidis

Re: [PATCH 2/4][AArch64] Increase the loop peeling limit

On 12/16/2015 02:11 PM, Evandro Menezes wrote: On 12/16/2015 05:24 AM, Richard Earnshaw (lists) wrote: On 15/12/15 23:34, Evandro Menezes wrote: On 12/14/2015 05:26 AM, James Greenhalgh wrote: On Thu, Dec 03, 2015 at 03:07:43PM -0600, Evandro Menezes wrote: On 11/20/2015 05:53 AM, James

Re: [RFA] [PATCH][PR tree-optimization/64910] Fix reassociation of binary bitwise operations with 3 operands

On 01/08/2016 02:36 AM, Richard Biener wrote: My original patch did this for all binary operations. However, reviewing the assembly code & dump files before/after it was pretty clear that doing this for arithmetic was losing (mostly in that we were missing CSE opportunities). The missed CSE

[PR 69044] Do not clone for parameter removal when !can_change_signature

Hi, we generally do not have ther ability to propagate constants to and clone CHKP instrumented functions. Therefore we do not propagate stuff into their lattices but since Honza changed cloning for all contexts heuristics a few weeks ago, we might attempt to clone them for unused parameter

Re: [PATCH 2/4] Equate MEM_REFs and ARRAY_REFs in tree-ssa-scopedtables.c

On Tue, Jan 5, 2016 at 5:36 PM, Jeff Law wrote: > On 01/05/2016 09:29 AM, Alan Lawrence wrote: >>> >>> Without looking at the patch, ARRAY_REFs can have non-constant indices >>> which get_ref_base_and_extend handles conservative. You should make >>> sure to not regress here. >>

[PATCH] libitm: Fix HTM fastpath.

This patch fixes a thinko in the HTM fastpath implementation. In a nutshell, we also need to monitor the HTM fastpath control (ie, htm_fastpath) variable from within a HW transaction on the HTM fastpath, so that such a HW transaciton will only execute if the HTM hastpath is still enabled. We

Re: RFA (tree-cfg): PATCH for 68983 (ICE in copy constructor)

On Fri, Jan 8, 2016 at 8:22 AM, Eric Botcazou wrote: >> But it occurs to me that since the real problem I was trying to catch is >> creation of temporaries of TREE_ADDRESSABLE type in the back end, we >> should guard that instead. So this patch moves the assert into

Re: [PATCH, middle-end]: Fix PR68999, gfortran.fortran-torture/execute/save_1.f90 execution failure on alpha

On Fri, Jan 8, 2016 at 11:41 AM, Uros Bizjak wrote: > Hello! > > This patch includes part of [1] that trivially renumbers a return > value, so the follow-up part of a patch that fixes aliasing issues can > be much smaller and more focused. > > 2016-01-08 Uros Bizjak

[PATCH] Fix PR68707

Here's an alternative patch, using the hunk from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68707#c16, which 'improves' (heh, we think) on the previous by allowing SLP to proceed where the loads are strided, for example, slp-perm-11.c. Also I fix the testsuite failures (looking for SLP where

Re: [PR69123] fix VTA dataflow oscillation

On January 9, 2016 5:08:51 AM GMT+01:00, Alexandre Oliva wrote: >Here are two patches related with PR69123, an infinite dataflow loop in >VTA. > >The first non-comment hunk in var-tracking.c:drop_overlapping_mem_locs >is what fixes the problem, but the other changes in the

Re: [PATCH] Fix X % -Y => X % Y optimization (PR tree-optimization/69097, PR middle-end/50865)

On January 8, 2016 9:07:11 PM GMT+01:00, Jakub Jelinek wrote: >Hi! > >As mentioned in the PRs, the X % -Y to X % Y optimization for signed >modulo is not valid unless we can prove that it won't be INT_MIN % >-(-1), >which is valid, but where INT_MIN % -1 is invalid. > >The

Re: [PR69123] fix VTA dataflow oscillation

On Sat, Jan 09, 2016 at 02:08:51AM -0200, Alexandre Oliva wrote: > Here are two patches related with PR69123, an infinite dataflow loop in > VTA. > > The first non-comment hunk in var-tracking.c:drop_overlapping_mem_locs > is what fixes the problem, but the other changes in the first patch fix >

Re: [PATCH 6/6] [DJGPP] configure.ac: enable LTO

On 01/09/2016 01:29 AM, Jeff Law wrote: On 12/21/2015 11:22 PM, Andris Pavenis wrote: 12/21/2015, 10:00 PM, Jeff Law kirjoitti: On 12/17/2015 10:51 PM, Andris Pavenis wrote: On 12/13/2015 08:12 PM, DJ Delorie wrote: You can list me as your sponsor. I've been wanting him to be a djgpp

C++ patch ping

Hi! I'd like to ping the PR c++/66808, PR c++/69000 http://gcc.gnu.org/ml/gcc-patches/2015-12/msg02019.html patch, fixing ICE with GNU __thread vars in templates. Thanks Jakub

Re: [PATCH] Fix memory alignment on AVX512VL masked floating point stores (PR target/69198)

On Fri, Jan 8, 2016 at 1:38 PM, Jakub Jelinek wrote: > On Fri, Jan 08, 2016 at 01:27:08PM -0800, H.J. Lu wrote: >> > That is just wrong and will severely pessimize correct code. >> > Please don't waste time on that. >> > >> >> Do you have an example to show it will pessimize

Re: [PATCH] Fix memory alignment on AVX512VL masked floating point stores (PR target/69198)

On Fri, Jan 8, 2016 at 1:53 PM, H.J. Lu wrote: > On Fri, Jan 8, 2016 at 1:43 PM, H.J. Lu wrote: >> On Fri, Jan 8, 2016 at 1:38 PM, Jakub Jelinek wrote: >>> On Fri, Jan 08, 2016 at 01:27:08PM -0800, H.J. Lu wrote: > That is just

Re: RFA: PR 68913: Provide weak version of __fread_chk for PR61886 test

On 01/07/2016 10:31 AM, Nick Clifton wrote: I did have one idea though - we could change the name of the function being tested from one that might not exist (__fread_chk) to one that definitely should exist (eg malloc). Not a bad idea. Does it make sense to just limit this test to

Re: [PATCH] Handle inter-block notes before BARRIER in rtl merge_blocks (PR target/69175)

On 01/08/2016 11:05 PM, Bernd Schmidt wrote: On 01/08/2016 10:23 PM, Jakub Jelinek wrote: Now, the merge_if_block caller removes the simple_return from the then_bb in preparation of the merge and expects the two bbs to be merged together, I'd be tempted to remove the barrier as well at this

Re: [PATCH, middle-end]: Fix PR68999, gfortran.fortran-torture/execute/save_1.f90 execution failure on alpha

On 12/23/2015 02:39 AM, Uros Bizjak wrote: Hello! There is a logic error in Honza's patch "Transparent alias suport part 10" [1]. The part in memrefs_conflict_p should be changed to: - /* If decls are different or we know by offsets that there is no overlap, - we win. */ - if (!cmp

C++ PATCH for c++/69158 (ICE with self-initializing array)

In this testcase, cxx_fold_indirect_ref was failing to fold away the *& implied in (IdHdr) because the result type and the type of the variable were different: the result type was an array of unknown bound, because the expression was built before the length of the initializer was known, but

Re: C++ PATCH for c++/69113 (ICE with -fno-weak)

OK. Jason

Re: [C++ PATCH] Fix ICE with bitfields (PR c++/69164, take 2)

OK. Jason

[PR69123] fix VTA dataflow oscillation

Here are two patches related with PR69123, an infinite dataflow loop in VTA. The first non-comment hunk in var-tracking.c:drop_overlapping_mem_locs is what fixes the problem, but the other changes in the first patch fix similar problems that might cause other such oscillations. The second patch

Re: [PATCH] PR testsuite/69181: ensure expected multiline outputs is cleared per-test

On 01/09/2016 01:51 AM, David Malcolm wrote: The root cause here is that the logic to reset the list of expected multiline outputs was being run from: handle-multiline-outputs, called by prune.exp's prune_gcc_output and none of that happens if the test is skipped by a target exclusion in

Re: RFA: Fix ICE compiling gcc.dg/lto/pr55113_0.c for x86/x86_64

On Tue, Dec 22, 2015 at 10:55 AM, Nick Clifton wrote: > Hi Richard, > >>> The patch below is a fix for this problem, although I am not sure if >>> it is the correct fix. The patch selects the corresponding SFmode >>> variant of the DFmode vector type when

Re: varpool/constpool bug

On Mon, Jan 4, 2016 at 7:53 PM, Jeff Law wrote: > On 01/04/2016 08:57 AM, Nathan Sidwell wrote: >> >> My patch to stop constant pool objects accidentally ending up in the >> varpool caused problems with (at least) powerpc. >>

Re: [PATCH, middle-end]: Fix PR68999, gfortran.fortran-torture/execute/save_1.f90 execution failure on alpha

Hello! This patch includes part of [1] that trivially renumbers a return value, so the follow-up part of a patch that fixes aliasing issues can be much smaller and more focused. 2016-01-08 Uros Bizjak * symtab.c (symtab_node::equal_address_to): Return -1 instead of 2

Re: [PATCH, PR target/69010] Fix expand for constant boolean vectors with a scalar mode

On Wed, Dec 23, 2015 at 10:14 AM, Ilya Enkovich wrote: > Hi, > > Currently boolean vector constant is expanded incorrectly when > it has a scalar mode. Generated constant is incorrect and also > its mode (which is VOIDmode) is used for roce_reg which causes > ICE. This

Re: [PATCH] Fix -Wmisleading indentation false-positive for do-while statement

On Tue, Dec 22, 2015 at 12:33:51PM -0500, Patrick Palka wrote: > We are emitting a bogus warning for the code > > do foo (0); while (flagA); > ^--- NEXT > ^ BODY > ^--- GUARD > > In general I don't think we can get any useful indentation warning out

[patch] Use -std options to test C99 classification macros in C++

The 26_numerics/headers/cmath/c99_classification_macros_c++.cc test was written for C++98 mode (we have a separate test that uses -std=gnu++11) but with the GCC 6 switch to -std=gnu++14 by default we now check it in C++14 mode. That's pointless, as the relevant parts of are equivalent in C++11

Re: [ARM][PR69194] Fix ICE in in extract_insn

Hi Kugan, On 08/01/16 12:07, Kugan wrote: neon_vld1 pattern does not accept eliminable registers and due to this, testcase in PR ICE. The problem is in arm_expand_neon_args, in the NEON_ARG_MEMORY case, where it call force_reg. Since an eliminable reg is already a reg, it just returns that

Re: [ARM][PR69194] Fix ICE in in extract_insn

On Fri, Jan 08, 2016 at 11:07:17PM +1100, Kugan wrote: > gcc/ChangeLog: > > 2016-01-08 Kugan Vivekanandarajah > Jim Wilson > > PR target/69194 > * config/arm/arm-builtins.c (arm_expand_neon_args): Call >copy_to_mode_reg

Re: [C++ PATCH] Fix ICE with bitfields (PR c++/69164)

On Fri, Jan 08, 2016 at 01:46:47PM +0100, Bernd Schmidt wrote: > On 01/07/2016 10:43 PM, Jakub Jelinek wrote: > > > > PR c++/69164 > > * class.c (layout_class_type): Also copy DEC_SIZE_UNIT, DECL_BIT_FIELD > > and DEC_BIT_FIELD_TYPE. > > Any reason this isn't using copy_node? No

[patch] libstdc++/48891 Use ::isinf and ::isnan if libc defines them

Glibc defines obsolete isinf(double) and isnan(double) functions from Unix98. For C99 these are hidden by the type-generic isinf and isnan macros, but in C++11 #undefs those macros, exposing the Unix98 functions. They then conflict with our own std::isinf(double) and std::isnan(double) if users

Re: [patch] libstdc++/69105, 69106, 69114 use std::addressof

On 08/01/16 13:17 +, Kyrill Tkachov wrote: Hi Jonathan, On 08/01/16 13:13, Jonathan Wakely wrote: On 07/01/16 15:01 +, Jonathan Wakely wrote: A bumper crop of addressof bugs where I was using & but should have used std::addressof. This caused a regression, fixed like so. Tested

[PATCH] arc/gcc: Fix help text for some options.

The following minor patch fixes up the command line option help text for arc. This resolves one test failure in help.exp. I don't have GCC write access, so if this is approved, please could someone apply it for me. Thanks, Andrew --- Add missing period to the end of the sentences for a couple

Re: RFA: Fix ICE compiling gcc.dg/lto/pr55113_0.c for x86/x86_64

On 01/08/2016 10:41 AM, Richard Biener wrote: On Tue, Dec 22, 2015 at 10:55 AM, Nick Clifton wrote: Hi Richard, The patch below is a fix for this problem, although I am not sure if it is the correct fix. The patch selects the corresponding SFmode variant of the

Re: [PATCH][RTL-ifcvt] PR rtl-optimization/68841: Make sure one basic block doesn't clobber CC reg usage of the other

On 07/01/16 14:00, Kyrill Tkachov wrote: On 07/01/16 13:47, Bernd Schmidt wrote: On 01/07/2016 02:45 PM, Kyrill Tkachov wrote: On 07/01/16 11:52, Bernd Schmidt wrote: I looked and this is indeed the case. Still slightly scary. Should the MEM be rtx_equal_p to TO_RENAME? It would be good to

Re: [C++ PATCH] Fix ICE with bitfields (PR c++/69164)

On 01/08/2016 07:58 AM, Jakub Jelinek wrote: On Fri, Jan 08, 2016 at 01:46:47PM +0100, Bernd Schmidt wrote: On 01/07/2016 10:43 PM, Jakub Jelinek wrote: PR c++/69164 * class.c (layout_class_type): Also copy DEC_SIZE_UNIT, DECL_BIT_FIELD and DEC_BIT_FIELD_TYPE. Any

  1   2   >