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 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 target/

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 > s

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 following patch use rang

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 first patch fix >simila

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

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 we'

[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 a

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: 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. I

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) > -

[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 rele

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 i

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 a

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 teaches the compiler about that

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 -mpaired-sin

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 adjusted

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 |

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 types" adde

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 specific

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 po

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 op

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 t

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 Green

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 isnot

[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: 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 "p

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 me

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: [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 [s

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 Fri, Jan 08, 2016 at 01:27:08PM -0800, H.J. Lu wrote: > > That is just wrong and

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 wrong and will severely pessimize correct code. > Please d

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 time on that. >>> > >>> >>> Do you have an

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 correct code? > > Anyt

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 you

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__ ((aligned (32))) *p; >

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. P

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 the

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 sym

[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 -Wmisl

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, it has just unknown alignment. >> >>

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 inva

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. > > > > Yes. But if you

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 invoke undefined beh

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 wha

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 >> > before don't ap

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; >> >> void extern >> a

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 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 scan-assembler-times vmovap

[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|[ t]+

[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 no

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 and

[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 secon

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 o

[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 cop

[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 > > operands

[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 i

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; > float32

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, fl

[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 us

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

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 - it'

[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 remov

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

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: [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 with

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 th

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 PR c++/68449

Re: [PATCH] Fix PR68707

On 08/01/16 11:45, Richard Biener wrote: > On Fri, 8 Jan 2016, Alan Lawrence wrote: > >> 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 ar

Re: [PATCH] Remove PTX link option

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 with CUDA more than > >myself. > > > > The

Re: [PATCH] Remove PTX link option

On 01/08/2016 04:44 PM, Jakub Jelinek 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 with CUDA more than myself. I'll defer to Nathan whether to ack t

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

Hello! Attached patch returns "unknown" from memrefs_conflict_p when realigned decls are processed. This is the same approach as is done at the end of memrefs_conflict_p. We still need early return for AND addresses in base_alias_check. 2016-01-08 Uros Bizjak PR middle-end/68999 * al

Re: [PATCH] Remove PTX link option

Jakub, On 01/08/2016 09:44 AM, Jakub Jelinek wrote: On Fri, Jan 08, 2016 at 09:39:11AM -0600, James Norris wrote: On 01/08/2016 09:30 AM, Jakub Jelinek wrote: On Fri, Jan 08, 2016 at 09:24:14AM -0600, James Norris wrote: This patch removes the constraint whereby the PTX emitted was only for s

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

On 01/08/2016 06:18 AM, Richard Biener wrote: 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 as

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

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 memory access, this restricts the vectorizer apparently

Re: [PATCH] Remove PTX link option

On Fri, Jan 08, 2016 at 09:39:11AM -0600, James Norris wrote: > On 01/08/2016 09:30 AM, Jakub Jelinek wrote: > >On Fri, Jan 08, 2016 at 09:24:14AM -0600, James Norris wrote: > >>This patch removes the constraint whereby the PTX > >>emitted was only for sm_30 GPU's. With this removal, > >>the PTX em

Re: varpool/constpool bug

On January 8, 2016 4:13:17 PM GMT+01:00, Jan Hubicka wrote: >> On 01/08/16 05:39, Richard Biener wrote: >> >> >Oh, and I _do_ belive that ultimatively we should have all constant >pool >> >entries (and CONST_DECLs) in the varpool. >> >> FWIW that certainly seems like the right goal. >Indeed it i

Re: [PATCH] Remove PTX link option

Jakub, On 01/08/2016 09:30 AM, Jakub Jelinek wrote: On Fri, Jan 08, 2016 at 09:24:14AM -0600, James Norris wrote: This patch removes the constraint whereby the PTX emitted was only for sm_30 GPU's. With this removal, the PTX emitted will be targeted for the current context, i.e., attached GPU.

Re: [PATCH] Remove PTX link option

On Fri, Jan 08, 2016 at 09:24:14AM -0600, James Norris wrote: > This patch removes the constraint whereby the PTX > emitted was only for sm_30 GPU's. With this removal, > the PTX emitted will be targeted for the current > context, i.e., attached GPU. > > Bootstrapped/regtested on x86_64-linux, ok

[PATCH] Remove PTX link option

Hi, This patch removes the constraint whereby the PTX emitted was only for sm_30 GPU's. With this removal, the PTX emitted will be targeted for the current context, i.e., attached GPU. Bootstrapped/regtested on x86_64-linux, ok for trunk? Thanks, Jim diff --git a/libgomp/plugin/plugin-nvptx.c b

[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 on the can_chan

Re: varpool/constpool bug

> On 01/08/16 05:39, Richard Biener wrote: > > >Oh, and I _do_ belive that ultimatively we should have all constant pool > >entries (and CONST_DECLs) in the varpool. > > FWIW that certainly seems like the right goal. Indeed it is on my TODO. I need to make CONST_DECLs to have visibility (so they

[patch] Avoid an unwanted decl re-map in copy_gimple_seq_and_replace_locals

Hi, I ran into an ICE when compiling the following function on the HSA branch: foo (int n, int m, int o, int (*a)[m][o]) { int i, j, k; #pragma omp target teams distribute parallel for shared(a) firstprivate(n, m, o) private(i,j,k) for (i = 0; i < n; i++) for (j = 0; j < m; j++) fo

[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 an

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

On 01/08/2016 03:43 AM, Jakub Jelinek wrote: 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

Re: [ping] fix VXWORKS_LIBGCC_SPEC not to include -lc_internal for shared rtps

> On Jan 8, 2016, at 15:17 , Nathan Sidwell wrote: >>> * config/vxworks.h (VXWORKS_LIBGCC_SPEC): Don't link shared RTPs with >>> libc_internal. > ok Great! Thanks for your prompt feedback Nathan :-)

Re: [ping] fix VXWORKS_LIBGCC_SPEC not to include -lc_internal for shared rtps

On 01/08/16 09:16, Olivier Hainque wrote: Hello, Ping for https://gcc.gnu.org/ml/gcc-patches/2015-12/msg02028.html * config/vxworks.h (VXWORKS_LIBGCC_SPEC): Don't link shared RTPs with libc_internal. Thanks in advance, ok

[ping] fix VXWORKS_LIBGCC_SPEC not to include -lc_internal for shared rtps

Hello, Ping for https://gcc.gnu.org/ml/gcc-patches/2015-12/msg02028.html > * config/vxworks.h (VXWORKS_LIBGCC_SPEC): Don't link shared RTPs with > libc_internal. Thanks in advance, With Kind Regards, Olivier

[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: varpool/constpool bug

On 01/08/16 05:39, Richard Biener wrote: Oh, and I _do_ belive that ultimatively we should have all constant pool entries (and CONST_DECLs) in the varpool. FWIW that certainly seems like the right goal. nathan

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 rea

[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 a

prevent "undef var" errors on gcc --help or --version

Hello, self-specs setup with configure --with-specs are allowed to contain %:getenv environment variable references. We are using this capability in a few cases for cross ports. In such configurations, gcc --help or gcc --version fail if the variables aren't defined, like so: gcc --version

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

On 01/08/2016 02:11 PM, Kyrill Tkachov wrote: How's this? Hmm. Almost there, but... - if (then_bb && else_bb && !a_simple && !b_simple - && (!bbs_ok_for_cmove_arith (then_bb, else_bb) - || !bbs_ok_for_cmove_arith (else_bb, then_bb))) + rtx orig_x = x; + if (then_bb && else_bb)

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 x86_

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

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 x86_64-linux, committed to trunk. You used "PR l

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

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 x86_64-linux, committed to trunk. commit 8f7a4cbf1cdae97578a6b4236af532879be15e9d Author: Jonathan Wakely

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: 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 DFmode vector type

  1   2   >