[PR71408] - Fix wrong code at -Os and above

Hi All, For the testcase in PR71408 zero_one_operation seems still broken. In handling NEGATE_EXPR, as part of undistribute_ops_list, in zero_one_operation, we are doing propagate_op_to_single_use (op, stmt, def); This results in: - _14 = _5 * _12; _15 = (int) _11; _16 = ~_15; _17 =

Re: [PATCH][2/3] Vectorize inductions that are live after the loop

Alan Hayward writes: > * gcc.dg/vect/vect-live-2.c: New test. This test fails on powerpc64 (with -m64, but not with -m32): $ grep 'vectorized.*loops' ./vect-live-2.c.149t.vect ../gcc/testsuite/gcc.dg/vect/vect-live-2.c:10:1: note: vectorized 0 loops in function. ../gcc/testsuite/gcc.dg/v

Re: [PATCH] Selftest framework (v7)

On 06/03/2016 09:12 PM, David Malcolm wrote: It's not clear to me if these approvals still hold. I was willing to go with it; I had a look through some of these patches and didn't spot anything untoward. To make it clear, this patch is OK, with one tweak if possible: extend the namespace self

Re: Ping! [fortran, patch, pr69659, v1] [6/7 Regression] ICE on using option -frepack-arrays, in gfc_conv_descriptor_data_get

Ping! On Sun, 22 May 2016 18:51:22 +0200 Andre Vehreschild wrote: > Hi all, > > attached patch fixes a regression that occurred on some testcases when > doing a validation run with -frepack-arrays. The issue here was that > for class arrays the array descriptor is in the _data component and not

Re: Ping! [fortran, patch, pr69659, v1] [6/7 Regression] ICE on using option -frepack-arrays, in gfc_conv_descriptor_data_get

Hi Andre, That's verging on 'obvious' and even does the job :-) OK for trunk and 6-branch. Thanks for the patch Paul On 5 June 2016 at 16:13, Andre Vehreschild wrote: > Hi Paul, > > now with attachment. > > - Andre > > On Sun, 5 Jun 2016 16:06:09 +0200 > Paul Richard Thomas wrote: > >> Hi An

[PING] [PATCH] Make basic asm implicitly clobber memory

Ping... I think we all agreed on the general direction of this patch. The patch is basically unchanged from previous version, except one line in doc/extend.texi has been updated. So I would like to ask if it is OK for trunk. Thanks Bernd.gcc/ 2016-05-05 Bernd Edlinger PR c/24414

Silence bogus mismatched profile messages

Hi, calls to functions that will not return cause profile to look locally incorrect. (because the sum of outgoing frequencies does not match the BB frequency). Do not report that. This makes it easier to analyze C++ sources. On tramp3d we now have about 20 mismatches caused by loop unroling about

Avoid mutiple predictions out of loop predictors

Hi, this patch makes loop predictors to run smoother on exists which quits multiple loops. Currently we will place multiple predictors on each such exit that does not really work as expected: PRED_LOOP_ITERATIONS predictors does not really expect the exit to be inside of internal loop and will giv

[v3 PATCH] Support allocators in tuples of zero size.

All in all this is a bit inane, but the spec requires a zero-sized tuple to provide allocator overloads for constructors, even though they do absolutely nothing (they completely ignore the allocator). Presumably these are also useful for some metaprogrammers I haven't heard of. This takes us one sm

Re: Ping! [fortran, patch, pr69659, v1] [6/7 Regression] ICE on using option -frepack-arrays, in gfc_conv_descriptor_data_get

Hi Paul, thanks for quick review. Comitted as r237105 for trunk. And r237107 for branch-6. Thanks again and regards, Andre On Sun, 5 Jun 2016 17:44:19 +0200 Paul Richard Thomas wrote: > Hi Andre, > > That's verging on 'obvious' and even does the job :-) > > OK for trunk and 6-branch.

Re: [v3 PATCH] Support allocators in tuples of zero size.

On 5 June 2016 at 20:59, Ville Voutilainen wrote: > All in all this is a bit inane, but the spec requires a zero-sized tuple > to provide allocator overloads for constructors, even though they do > absolutely nothing (they completely ignore the allocator). Presumably > these are also useful for so

loop-ch tweek

Hi, both loop-ch and loop-ivcanon want to trottle down the heuristics on paths containing call. Testing for presence of GIMPLE_CALL is wrong for internal call and cheap builtins that are expanded inline. Bootstrapped/regtested x86_64-linux, OK? Honza * gimple.c: Include builtins.h.

[committed] Fix unused argument error in expr.c

The attached change fixes a build error on hppa-unknown-linux-gnu. Committed as obvious. Dave -- John David Anglin dave.ang...@bell.net 2016-06-05 John David Anglin * expr.c (move_by_pieces_d::generate): Mark mode parameter with ATTRIBUTE_UNUSED. Index: expr.c ==

Re: [patch, fortran] PR52393 I/O: "READ format" statement with parenthesized default-char-expr

On 06/03/2016 12:40 PM, H.J. Lu wrote: > On Wed, Jun 1, 2016 at 9:28 AM, Jerry DeLisle wrote: >> On 06/01/2016 12:25 AM, FX wrote: 2016-05-30 Jerry DeLisle PR fortran/52393 * io.c (match_io): For READ, try to match a default character expression. If found

[PATCH, i386]: Fix PR 71389, ICE on trunk gcc on ivybridge target (df_refs_verify)

Hello! As explained in the PR [1] Comment #4, this is a target problem with invalid RTL sharing. Invalid sharing is created by the misaligned expansion code in i386.c, when subregs are involved. vec_extract_hi_v32qi pattern is generated in loop2_invariant pass when misaligned V8SI move is generat

[patch committed FT32] use setup_incoming_varargs

The FT32 target now uses SETUP_INCOMING_VARARGS to handle varargs. This saves 24 byte per stack frame, because the caller no longer needs to allocate space on the stack for r0-r5 in the event of a varargs caller. * config/ft32/ft32.c (ft32_setup_incoming_varargs, ft32_expand_prolog

[PATCH] Fix PR71398

Bootstrapped and tested on x86_64-unknown-linux-gnu, applied. Richard. 2016-06-06 Richard Biener PR tree-optimization/71398 * tree-ssa-loop-ivcanon.c (unloop_loops): First unloop, then remove edges. * gcc.dg/torture/pr71398.c: New testcase. Index: gcc/tree-s