Re: Handle CONSTRUCTOR in operand_equal_p

On October 15, 2015 1:55:09 AM GMT+02:00, Jan Hubicka wrote: >> On October 14, 2015 6:27:02 PM GMT+02:00, Jan Hubicka > wrote: >> >Hi, >> >this patch adds the CONSTRUCTOR case discussed while back. Only >empty >> >constructors are matched, as those are only appearing in gimple >> >operand. >> >I

Re: Move some bit and binary optimizations in simplify and match

Hi, Thanks for all the suggestions. Please find attached the modified patch as per your suggestions. I had missed a mail as pointed by Marc Glisse. Now I have implemented everything suggested. Please review the patch and let me know if any further modifications are required. I have some queries

Re: [2/7] Add new type promotion pass

On 07/09/15 12:56, Kugan wrote: > > This pass applies type promotion to SSA names in the function and > inserts appropriate truncations to preserve the semantics. Idea of this > pass is to promote operations such a way that we can minimize generation > of subreg in RTL, that intern results in r

Re: [1/7] Add new tree code SEXT_EXPR

On 12/10/15 23:21, Richard Biener wrote: > On Sun, Oct 11, 2015 at 12:35 PM, Kugan > wrote: >> >> >> On 15/09/15 23:18, Richard Biener wrote: >>> On Mon, Sep 7, 2015 at 4:55 AM, Kugan >>> wrote: This patch adds support for new tree code SEXT_EXPR. >>> >>> diff --git a/gcc/cfgexpand.c

Re: [5/7] Allow gimple debug stmt in widen mode

On 15/09/15 22:57, Richard Biener wrote: > On Tue, Sep 8, 2015 at 2:00 AM, Kugan > wrote: >> >> Thanks for the review. >> >> On 07/09/15 23:20, Michael Matz wrote: >>> Hi, >>> >>> On Mon, 7 Sep 2015, Kugan wrote: >>> Allow GIMPLE_DEBUG with values in promoted register. >>> >>> Patch does m

Re: [PATCH 2/6] always define SETUP_FRAME_ADDRESSES

On Mon, Oct 12, 2015 at 12:19:08PM +0200, Bernd Schmidt wrote: > On 10/11/2015 02:25 AM, tbsaunde+...@tbsaunde.org wrote: > >From: Trevor Saunders > > > >gcc/ChangeLog: > > > >2015-10-10 Trevor Saunders > > > > * defaults.h (SETUP_FRAME_ADDRESSES): New default definition. > > * builtins

Re: [PATCH] c/67925 - update documentation on `inline'

On 10/14/2015 03:42 PM, Arkadiusz Drabczyk wrote: On Wed, Oct 14, 2015 at 08:36:43AM -0600, Martin Sebor wrote: On 10/13/2015 04:47 PM, Arkadiusz Drabczyk wrote: * gcc/doc/extend.texi: documentation says that functions declared `inline' would not be integrated if they are called before they are

Re: Handle CONSTRUCTOR in operand_equal_p

> On October 14, 2015 6:27:02 PM GMT+02:00, Jan Hubicka wrote: > >Hi, > >this patch adds the CONSTRUCTOR case discussed while back. Only empty > >constructors are matched, as those are only appearing in gimple > >operand. > >I tested that during bootstrap about 7500 matches are for empty ctors. >

Re: [PATCH] print help for undocumented options

On 10/14/2015 01:40 PM, Joseph Myers wrote: On Wed, 14 Oct 2015, Martin Sebor wrote: IMO, printing the aliased option's help text makes using the output easier for users who find the undocumented option first, in that they don't then have to go look for the one that does have documentation, so

Re: [PATCH 1/3] [ARM] PR63870 Add qualifiers for NEON builtins

On 12 October 2015 at 11:58, Alan Lawrence wrote: > On 07/10/15 00:59, charles.bay...@linaro.org wrote: >> >> diff --git a/gcc/config/arm/arm-builtins.c b/gcc/config/arm/arm-builtins.c > > ... >> >> case NEON_ARG_MEMORY: >> /* Check if expand failed. */ >>

Re: [PATCH, rs6000] Add memory barriers to tbegin, tend, etc.

On Fri, 2015-10-09 at 22:19 +0200, Torvald Riegel wrote: > On Fri, 2015-10-09 at 11:52 -0500, Peter Bergner wrote: >> Thanks for the review! I've attached the changes to the documentation below. >> Is this better? > > Yes, thanks! Great, thanks! This is committed a revision 228827. I'm just st

Re: [PATCH, mips]: Use ROUND_UP and ROUND_DOWN macros

On Wed, Oct 14, 2015 at 11:38 PM, Matthew Fortune wrote: > Uros Bizjak writes: >> Fairly trivial patch that introduces no functional changes. >> >> * config/mips/mips.h (MIPS_STACK_ALIGN): Implement using >> ROUND_UP macro. >> * config/mips/mips.c (mips_setup_incoming_varargs): Use >>

Re: [PATCH] c/67925 - update documentation on `inline'

On Wed, Oct 14, 2015 at 08:36:43AM -0600, Martin Sebor wrote: > On 10/13/2015 04:47 PM, Arkadiusz Drabczyk wrote: > >* gcc/doc/extend.texi: documentation says that functions declared > >`inline' would not be integrated if they are called before they are > >defined or if they are recursive. Both of

RE: [PATCH, mips]: Use ROUND_UP and ROUND_DOWN macros

Uros Bizjak writes: > Fairly trivial patch that introduces no functional changes. > > * config/mips/mips.h (MIPS_STACK_ALIGN): Implement using > ROUND_UP macro. > * config/mips/mips.c (mips_setup_incoming_varargs): Use > ROUND_DOWN to calculate off. > (mips_gimplify_va_arg_exp

Re: [PATCH] New attribute to create target clones

Bootstrap and make check for x86 passed. No new fails. Please ignore an empty line added to omp-low.c in the patch, the misprint will be removed prior to a commit. Thanks, Evgeny On Tue, Oct 13, 2015 at 2:35 AM, Evgeny Stupachenko wrote: > Hi All, > > Here is a new version of patch (attached). >

[PATCH, i386]: Fix PR 67967, ICE in i386_pe_seh_unwind_emit

Attached patch fixes PR 67967, where we emit REG_CFA_EXPRESSION, attached to aligned SSE store. This is unnecessary, and confuses SEH targets. 2015-10-14 Uros Bizjak PR target/67967 * config/i386/i386.c (ix86_emit_save_reg_using_mov): Do not add REG_CFA_EXPRESSION to aligned SSE st

Re: [PATCH 8/9] Add TARGET_ADDR_SPACE_ZERO_ADDRESS_VALID

On 10/14/2015 08:22 PM, Richard Biener wrote: I think you could trigger bogus CSE of dereferences of literal addresses from different address-spaces. Good catch. You're spot on with that. r~ int test(void) { int __seg_fs *f = (int __seg_fs *)16; int __seg_gs *g = (int __seg_gs *)16;

Re: [patch] Minor adjustment to gimplify_addr_expr

On 10/14/2015 02:57 PM, Eric Botcazou wrote: Can you use the TMR_OFFSET macro rather than TREE_OPERAND (op0, 1)? It also seems that you need a stronger check here. Essentially you have to verify that STEP * INDEX + INDEX2 + OFFSET == 0 Right? No, it's MEM_REF, not TARGET_MEM_REF, see build_f

Re: [patch] Minor adjustment to gimplify_addr_expr

> Can you use the TMR_OFFSET macro rather than TREE_OPERAND (op0, 1)? > > It also seems that you need a stronger check here. > > Essentially you have to verify that > STEP * INDEX + INDEX2 + OFFSET == 0 > > Right? No, it's MEM_REF, not TARGET_MEM_REF, see build_fold_addr_expr_with_type_loc. --

Re: Do not use TYPE_CANONICAL in useless_type_conversion

On Oct 14, 2015, Jan Hubicka wrote: >> On Oct 13, 2015, Eric Botcazou wrote: >> >> > Note that this is PR middle-end/67912. >> >> Thanks. I added this piece of information to the ChangeLog entry, and >> checked the patch in. > Thanks, Alexandre. That indeed looks better than my variant of th

Re: [PATCH] print help for undocumented options

On Wed, 14 Oct 2015, Martin Sebor wrote: > IMO, printing the aliased option's help text makes using the output > easier for users who find the undocumented option first, in that > they don't then have to go look for the one that does have > documentation, so I left that part in place. If you or s

Re: [PATCH 1/7] Libsanitizer merge from upstream r249633.

On Wed, Oct 14, 2015 at 12:15 PM, Renato Golin wrote: > On 14 October 2015 at 20:00, Andrew Pinski wrote: >> Then until that happens I think we should disable asan and tsan for >> AARCH64 for GCC. > > I can't comment on that, but we'll continue running the tests on our > side on both 39 and 42 VM

Re: using scratchpads to enhance RTL-level if-conversion: revised patch

On 10/14/2015 07:43 PM, Jeff Law wrote: Obviously some pessimization relative to current code is necessary to fix some of the problems WRT thread safety and avoiding things like introducing faults in code which did not previously fault. Huh? This patch is purely an (attempt at) optimization, no

Re: [PATCH 1/7] Libsanitizer merge from upstream r249633.

On 14 October 2015 at 20:00, Andrew Pinski wrote: > Then until that happens I think we should disable asan and tsan for > AARCH64 for GCC. I can't comment on that, but we'll continue running the tests on our side on both 39 and 42 VMA configurations, to make sure we don't regress until we actuall

Re: [PATCH 1/7] Libsanitizer merge from upstream r249633.

On Wed, Oct 14, 2015 at 11:38 AM, Renato Golin wrote: > On 14 October 2015 at 19:21, Evgenii Stepanov > wrote: >> Wait. As Jakub correctly pointed out in the other thread, there is no >> obvious reason why there could not be a single shadow offset value >> that would work for all 3 possible VMA

Re: [PATCH] Fix wrong-code when folding X - (X / Y) * Y (PR tree-optimization/67953)

On Wed, 14 Oct 2015, Marek Polacek wrote: Evidently, the X - (X / Y) * Y -> X % Y pattern can't change the signedness of X from signed to unsigned, otherwise we'd generate wrong code. (But unsigned -> signed should be fine.) Does anyone see a better fix than this? I was wondering about produ

Re: [PATCH] Fix wrong-code when folding X - (X / Y) * Y (PR tree-optimization/67953)

On October 14, 2015 8:27:31 PM GMT+02:00, Marek Polacek wrote: >Evidently, the X - (X / Y) * Y -> X % Y pattern can't change the >signedness of X from signed to unsigned, otherwise we'd generate >wrong code. (But unsigned -> signed should be fine.) > >Does anyone see a better fix than this? > >B

Re: Handle CONSTRUCTOR in operand_equal_p

On October 14, 2015 6:27:02 PM GMT+02:00, Jan Hubicka wrote: >Hi, >this patch adds the CONSTRUCTOR case discussed while back. Only empty >constructors are matched, as those are only appearing in gimple >operand. >I tested that during bootstrap about 7500 matches are for empty ctors. >There are co

Re: [PATCH 1/7] Libsanitizer merge from upstream r249633.

On 14 October 2015 at 19:21, Evgenii Stepanov wrote: > Wait. As Jakub correctly pointed out in the other thread, there is no > obvious reason why there could not be a single shadow offset value > that would work for all 3 possible VMA settings. I suggest figuring > this out first. We are. cheers

[PATCH] Fix wrong-code when folding X - (X / Y) * Y (PR tree-optimization/67953)

Evidently, the X - (X / Y) * Y -> X % Y pattern can't change the signedness of X from signed to unsigned, otherwise we'd generate wrong code. (But unsigned -> signed should be fine.) Does anyone see a better fix than this? Bootstrapped/regtested on x86_64-linux, ok for trunk? 2015-10-14 Marek

Re: [PATCH] print help for undocumented options

On 10/14/2015 11:24 AM, Joseph Myers wrote: On Wed, 14 Oct 2015, Martin Sebor wrote: + /* For undocumented options that are aliases for other +options that are documented, print the other option's +help and name. */ + help = cl_options [o

Re: [PATCH 1/7] Libsanitizer merge from upstream r249633.

On Wed, Oct 14, 2015 at 11:03 AM, Adhemerval Zanella wrote: > > > On 14-10-2015 04:54, Jakub Jelinek wrote: >> On Tue, Oct 13, 2015 at 07:54:33PM +0300, Maxim Ostapenko wrote: >>> On 13/10/15 14:15, Maxim Ostapenko wrote: This is the raw merge itself. I'm bumping SONAME to libasan.so.3.

Re: [PATCH 1/7] Libsanitizer merge from upstream r249633.

On 14-10-2015 04:54, Jakub Jelinek wrote: > On Tue, Oct 13, 2015 at 07:54:33PM +0300, Maxim Ostapenko wrote: >> On 13/10/15 14:15, Maxim Ostapenko wrote: >>> This is the raw merge itself. I'm bumping SONAME to libasan.so.3. >>> >>> -Maxim >> >> I have just noticed that I've misused autoconf stuff

[PATCH] Fix accounting for num_threaded_edges

tree-ssa-threadupdate.c keeps running total of the number of edges it threads. Those totals are useful debugging tools and are also examined by the testsuite. While looking at the effects of using the FSM threader on ssa-dom-thread-2?.c I noticed the counters weren't being updated properl

Re: using scratchpads to enhance RTL-level if-conversion: revised patch

On 10/14/2015 02:28 AM, Eric Botcazou wrote: If you're using one of the switches that checks for stack overflow at the start of the function, you certainly don't want to do any such stores. There is a protection area for -fstack-check (STACK_CHECK_PROTECT bytes) so you can do stores just below

Re: using scratchpads to enhance RTL-level if-conversion: revised patch

On 10/13/2015 02:16 PM, Bernd Schmidt wrote: _Potentially_ so, yes. However, GCC is free to put the allocation into an otherwise-unused part of the stack frame. Well, I looked at code generation changes, and it usually seems to come with an increase in stack frame size - sometimes causing extr

Re: Handle CONSTRUCTOR in operand_equal_p

> On 10/14/2015 10:27 AM, Jan Hubicka wrote: > >Hi, > >this patch adds the CONSTRUCTOR case discussed while back. Only empty > >constructors are matched, as those are only appearing in gimple operand. > >I tested that during bootstrap about 7500 matches are for empty ctors. > >There are couple hun

Re: [Patch PR target/67366 2/2] [gimple-fold.c] Support movmisalign optabs in gimple-fold.c

On 10/08/2015 08:10 AM, Ramana Radhakrishnan wrote: This patch by Richard allows for movmisalign optabs to be supported in gimple-fold.c. This caused a bit of pain in the testsuite with strlenopt-8.c in conjunction with the ARM support for movmisalign_optabs as the test was coded up to do differe

Re: [patch] Minor adjustment to gimplify_addr_expr

NAT BUG DETECTED==+ | Pro 7.4.0w (20151014-60) (x86_64-suse-linux) GCC error: | | tree check: expected class 'expression', have | | 'exceptional' (ssa_name) in tree_operand_check, at tree.h:3431| | Error detected a

Re: Handle CONSTRUCTOR in operand_equal_p

On 10/14/2015 10:27 AM, Jan Hubicka wrote: Hi, this patch adds the CONSTRUCTOR case discussed while back. Only empty constructors are matched, as those are only appearing in gimple operand. I tested that during bootstrap about 7500 matches are for empty ctors. There are couple hundred for non-em

Re: [PATCH] print help for undocumented options

On Wed, 14 Oct 2015, Martin Sebor wrote: > + /* For undocumented options that are aliases for other > +options that are documented, print the other option's > +help and name. */ > + help = cl_options [option->alias_target].help; > + > +

Re: [PATCH] PR middle-end/67220: GCC fails to properly handle libcall symbol visibility of built functions

On Wed, Oct 14, 2015 at 5:51 PM, H.J. Lu wrote: > On Wed, Oct 14, 2015 at 9:46 AM, Ramana Radhakrishnan > wrote: >> On Wed, Oct 14, 2015 at 5:21 PM, H.J. Lu wrote: >> >>> --- >>> gcc/c/ >>> >>> PR middle-end/67220 >>> * c-decl.c (diagnose_mismatched_decls): Copy explicit visibili

[PATCH] print help for undocumented options

Gcc's online help (the output of gcc --help -v) includes a large number of undocumented options (197 in 5.1.0). For example, the section listing language-related options starts with the following and another 44 or so undocumented options: The following options are language-related: --all-w

[PATCH] Split ssa-dom-thread-2.c into separate files/tests

ssa-dom-thread-2.c is actually 6 distinct tests crammed into a single file. That's normally not a huge problem, but it can make tests hard to write when we're scanning dumps. This patch splits it into 6 distinct tests. ssa-dom-thread-2[a-f].c. It also tightens the expected output slightly

[gomp4] remove dead code

I've committed this to gomp4 branch. It removes some now unreachable code and removes the now bogus description about OpenACC. nathan 2015-10-14 Nathan Sidwell * omp-low.c (lower_reduction_clauses): Correct comment, remove unreachable code. Index: gcc/omp-low.c ==

[PATCH] [PR testsuite/67959]Minor cleanup for ssa-thread-13.c

The enum rtx_code bitfield causes grief for arm-eabi. Given the test doesn't actually care about the size of that field, the easiest fix was just to make it a simple integer. Tested on both x86_64-linux-gnu and arm-eabi to ensure the updated test passes on both targets. Installed on the t

Re: [PATCH] PR middle-end/67220: GCC fails to properly handle libcall symbol visibility of built functions

On Wed, Oct 14, 2015 at 9:46 AM, Ramana Radhakrishnan wrote: > On Wed, Oct 14, 2015 at 5:21 PM, H.J. Lu wrote: > >> --- >> gcc/c/ >> >> PR middle-end/67220 >> * c-decl.c (diagnose_mismatched_decls): Copy explicit visibility >> to builtin function. >> >> gcc/ >> >>

PR67945: Fix oscillation between pow representations

This patch fixes some fallout from my patch to move the sqrt and cbrt folding rules to match.pd. The rules included canonicalisations like: sqrt(sqrt(x))->pow(x,1/4) which in the original code was only ever done at the generic level. My patch meant that we'd do it whenever we tried to fold a

Re: [PATCH] PR middle-end/67220: GCC fails to properly handle libcall symbol visibility of built functions

On Wed, Oct 14, 2015 at 5:21 PM, H.J. Lu wrote: > --- > gcc/c/ > > PR middle-end/67220 > * c-decl.c (diagnose_mismatched_decls): Copy explicit visibility > to builtin function. > > gcc/ > > PR middle-end/67220 > * expr.c (init_block_move_fn): Copy visibilit

Add VIEW_CONVERT_EXPR to operand_equal_p

Hi, this patch adds VIEW_CONVERT_EXPR which is another code omitted in operand_equal_p. During bootstrap there are about 1000 matches. Bootstrapped/regtested x86_64-linux, OK? Honza * fold-const.c (operand_equal_p): Handle VIEW_CONVERT_EXPR. Index: fold-const.c =

Handle CONSTRUCTOR in operand_equal_p

Hi, this patch adds the CONSTRUCTOR case discussed while back. Only empty constructors are matched, as those are only appearing in gimple operand. I tested that during bootstrap about 7500 matches are for empty ctors. There are couple hundred for non-empty probably used on generic. Bootstrapped/

Re: [PATCH 5/7] Libsanitizer merge from upstream r249633.

On 14/10/15 10:37, Jakub Jelinek wrote: On Tue, Oct 13, 2015 at 02:20:06PM +0300, Maxim Ostapenko wrote: This patch removes UBSan stubs from ASan and TSan code. We don't embed UBSan to ASan and UBSan because that would lead to undefined references to C++ stuff when linking with -static-libasan.

[PATCH] PR middle-end/67220: GCC fails to properly handle libcall symbol visibility of built functions

By default, there is no visibility on builtin functions. When there is explicitly declared visibility on the C library function which a builtin function fall back on, we should honor the explicit visibility on the the C library function. There are 2 issues: 1. We never update visibility of the f

Re: [vec-cmp, patch 4/6] Support vector mask invariants

On 14 Oct 13:50, Ilya Enkovich wrote: > 2015-10-14 11:49 GMT+03:00 Richard Biener : > > On Tue, Oct 13, 2015 at 4:52 PM, Ilya Enkovich > > wrote: > >> I don't understand what you mean. vect_get_vec_def_for_operand has two > >> changes made. > >> 1. For boolean invariants use build_same_sized_trut

Re: [vec-cmp, patch 3/6] Vectorize comparison

On 14 Oct 15:06, Ilya Enkovich wrote: > > Will send an updated version after testing. > > Thanks, > Ilya > Here is an updated patch version. Thanks, Ilya -- gcc/ 2015-10-14 Ilya Enkovich * tree-vect-data-refs.c (vect_get_new_vect_var): Support vect_mask_var. (vect_create_d

[patch] Minor adjustment to gimplify_addr_expr

TED==+ | Pro 7.4.0w (20151014-60) (x86_64-suse-linux) GCC error: | | tree check: expected class 'expression', have | | 'exceptional' (ssa_name) in tree_operand_check, at tree.h:3431| | Error detected around c37213k.adb:95:37 It's recompute_

Re: [PATCH] Allow FSM to thread single block cases too

On 10/14/2015 09:43 AM, Jan Hubicka wrote: I think he asked for trivial forward threads though due to repeated tests. I hacked FRE to do this (I think), but maybe some trivial cleanup opportunities are still left here. Honza? Well, unthreaded jumps quite confuse profile prediction and create p

[gomp4.5] Support for monotonic and nonmonotonic schedule modifiers

Hi! I've created gomp-4_5-branch in svn, where further OpenMP 4.5 development will happen. The following patch which I've committed there (and after a while plan to merge to trunk together with other smaller changes) adds support for monotonic and nonmonotonic schedule modifiers. The older versi

Re: [PATCH] Allow FSM to thread single block cases too

> >>> I think he asked for trivial forward threads though due to repeated > >>> tests. > >>> I hacked FRE to do this (I think), but maybe some trivial cleanup > >>> opportunities > >>> are still left here. Honza? Well, unthreaded jumps quite confuse profile prediction and create profiles that we

Re: [patch 0/6] scalar-storage-order merge (2)

On 10/14/2015 09:25 AM, Trevor Saunders wrote: I haven't looked at the C++ changes, but I tend to think they mat may be the language where this is the least useful. I expect it would be pretty "trivial" to write some wrapper classes that use bswap in operators so you could say things like struc

Re: [PATCH 8/9] Add TARGET_ADDR_SPACE_ZERO_ADDRESS_VALID

On 10/14/2015 03:19 AM, Richard Biener wrote: On Tue, Oct 13, 2015 at 10:59 PM, Richard Henderson wrote: On 10/14/2015 02:49 AM, Jeff Law wrote: The problem here is we don't know what address space the *0 is going to hit, right? Correct, not before we do the walk of stmt to see what's pres

Re: [AArch64] --with-arch in config.gcc support "."

Jiong Wang writes: > diff --git a/gcc/config.gcc b/gcc/config.gcc > index 5818663..215ad9a 100644 > --- a/gcc/config.gcc > +++ b/gcc/config.gcc > @@ -3544,7 +3544,7 @@ case "${target}" in > > eval "val=\$with_$which" > base_val=`echo $val | sed -e 's/

Re: [patch 0/6] scalar-storage-order merge (2)

On Tue, Oct 13, 2015 at 07:32:08PM +0200, Eric Botcazou wrote: > > My main question about this series is - how generally useful do you > > expect it to be? I know of some different projects that would like > > bi-endian capability, but it looks like this series implements something > > that is a li

Re: [PATCH 8/9] Add TARGET_ADDR_SPACE_ZERO_ADDRESS_VALID

On 10/13/2015 02:59 PM, Richard Henderson wrote: On 10/14/2015 02:49 AM, Jeff Law wrote: The problem here is we don't know what address space the *0 is going to hit, right? Correct, not before we do the walk of stmt to see what's present. So the address space information isn't part of the addr

Re: [PATCH] Fix pr67963

On Wed, Oct 14, 2015 at 8:15 AM, H.J. Lu wrote: > On Wed, Oct 14, 2015 at 8:08 AM, Yulia Koval wrote: >> Hi, >> >> This patch fixes the issue: >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67963 >> >> gcc/config/i386/i386.c (ix86_option_override_internal) Disable >> 80387 mask if lakemont

Re: [PATCH] Fix pr67963

On Wed, Oct 14, 2015 at 8:08 AM, Yulia Koval wrote: > Hi, > > This patch fixes the issue: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67963 > > gcc/config/i386/i386.c (ix86_option_override_internal) Disable > 80387 mask if lakemont target is set. > > diff --git a/gcc/config/i386/i386.c b/

Re: [patch 4/3] Header file reduction - Tools for contrib - second cut

Here's the latest version of the tools for a sub directory in contrib. I've handled all the feedback, except I have not fully commented the python code in the tools, nor followed any particular coding convention... Documentation has been handled, and I've added some additional comments to t

[PATCH] Fix pr67963

Hi, This patch fixes the issue: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67963 gcc/config/i386/i386.c (ix86_option_override_internal) Disable 80387 mask if lakemont target is set. diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c index 4c25c9e..db722aa 100644 --- a/gcc/confi

[AArch64] --with-arch in config.gcc support "."

Since armv8.1 added, we need to improve --with-arch recognition sed pattern to catch the new "." in the architecture base name. OK for trunk? 2015-10-14 Jiong Wang gcc/ * config.gcc: Recognize "." in architecture base name for AArch64. diff --git a/gcc/config.gcc b/gcc/config.gcc index 58

[gomp4, committed] Backported param parloops-schedule

[ was: Re: [PATCH, 3/5] Handle original loop tree in expand_omp_for_generic ] On 13/10/15 23:48, Thomas Schwinge wrote: Hi Tom! On Mon, 12 Oct 2015 18:56:29 +0200, Tom de Vries wrote: >Handle original loop tree in expand_omp_for_generic > >2015-09-12 Tom de Vries > >PR tree-optimization

Re: [PATCH] c/67925 - update documentation on `inline'

On 10/13/2015 04:47 PM, Arkadiusz Drabczyk wrote: * gcc/doc/extend.texi: documentation says that functions declared `inline' would not be integrated if they are called before they are defined or if they are recursive. Both of these statements is now false as shown in examples on Bugzilla. It mi

[committed] Improve reassoc-39.c test

Jakub suggested that I improve a testcase I've added a while ago. Done in the following. Tested on x86_64-linux, applying to trunk. 2015-10-14 Marek Polacek * gcc.dg/tree-ssa/reassoc-39.c: Use -g. Adjust dg-final. (f6): New. (f7): New. (f8): New. (f9):

Re: [patch] header file re-ordering.

On 10/12/2015 04:04 AM, Jeff Law wrote: <...> raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:423 ../gcc-interface/Makefile:311: recipe for target 's-regpat.o' failed However, the tool has been run, and I've made the minor adjustments required to the source files to make it work. (ie, a few m

[PATCH] More vectorizer TLC

This removes superfluous parameters from some analysis helpers. Bootstrapped and tested on x86_64-unknown-linux-gnu, applied. Richard. 2015-10-14 Richard Biener * tree-vectorizer.h (vect_is_simple_use): Remove unused parameters. (vect_is_simple_use_1): Likewise. Make overlo

Re: [PATCH, VECTOR ABI] Add __attribute__((__simd__)) to GCC.

On Wed, 14 Oct 2015, Kirill Yukhin wrote: > Is it ok for trunk? This patch has no documentation. Documentation for new attributes must be added to extend.texi. > Enables creation of one or more versions that can process multiple > arguments using SIMD instructions from a single invocation fro

Re: [PATCH v2] PR rtl-optimization/66790: uninitialized registers handling in REE

On 10/13/2015 05:17 PM, Pierre-Marie de Rodat wrote: The first attached patch is the second attempt to fix PR rtl-optimization/66790 (see ). The second one is a fix for some inconsistency noticed while working on the original bug. This specific

[gomp4] More deferral of partitioning to target

I've committed this to gomp4 branch. It is another step towards deferring partitioned execution choices to the target compiler -- though sadly not the last step. At early omp lowering, we now attach partitioning flags to the HEAD_MARK function I introduced yesterday, and adjust the partitio

Re: [PATCH] Allow FSM to thread single block cases too

On 10/14/2015 06:46 AM, Richard Biener wrote: This or other related patches in the range r228731:228774 has caused a quite big jump in SPEC CPU 2000 binary sizes (notably 176.gcc - so maybe affecting bootstrap as well, at -O3). Are you sure this doesn't re-introduce DOM effectively peeling all l

[PATCH] Fix PR67915

The following removes GENERIC folding from cleanup_control_expr_graph in favor of GIMPLE one. This likely doesn't solve the underlying issue of PR67915 fully but using const_binop as I originally wanted doesn't catch all cases fold_binary did because stmts that were previously folded get non-fold

Re: Benchmarks of v2 (was Re: [PATCH 0/5] RFC: Overhaul of diagnostics (v2))

Hi, On Wed, 14 Oct 2015, Richard Biener wrote: > The compile-time and memory-usage impact for the adhocloc at every token > patchkit is quite big. Remember that gaining 1% in compile-time is hard > and 20-40% memory increase for influence.i looks too much. Yes. OTOH the compile time and memo

Re: [PATCH] Allow FSM to thread single block cases too

On Wed, Oct 14, 2015 at 2:42 PM, Jeff Law wrote: > On 10/14/2015 04:16 AM, Richard Biener wrote: >> >> On Tue, Oct 13, 2015 at 2:52 PM, Richard Biener >> wrote: >>> >>> On Tue, Oct 13, 2015 at 2:21 PM, Jeff Law wrote: One of the cases that was missing in the FSM support is threadi

Re: [PATCH] Optimize const1 * copysign (const2, y) in reassoc (PR tree-optimization/67815)

On Wed, 14 Oct 2015, Marek Polacek wrote: > On Wed, Oct 14, 2015 at 11:10:38AM +0200, Richard Biener wrote: > > > + FOR_EACH_VEC_ELT (*ops, i, oe) > > > +{ > > > + if (TREE_CODE (oe->op) == SSA_NAME) > > > > I think you need to check whether the SSA_NAME has a single use only > > as you

Re: [PATCH] Allow FSM to thread single block cases too

On 10/14/2015 04:16 AM, Richard Biener wrote: On Tue, Oct 13, 2015 at 2:52 PM, Richard Biener wrote: On Tue, Oct 13, 2015 at 2:21 PM, Jeff Law wrote: One of the cases that was missing in the FSM support is threading when the path is a single block. ie, a control statement's output can be st

Re: [PATCH, VECTOR ABI] Add __attribute__((__simd__)) to GCC.

Hello, On 07 Oct 11:09, Jeff Law wrote: > On 10/05/2015 07:24 AM, Joseph Myers wrote: > >On Mon, 5 Oct 2015, Kirill Yukhin wrote: > > > >>To enable vectorization of loops w/ calls to math functions it is reasonable > >>to enable parsing of attribute vector for functions unconditionally and > >>chan

[PATCH][AArch64] Enable fusion of AES instructions

Enable instruction fusion of dependent AESE; AESMC and AESD; AESIMC pairs. This can give up to 2x speedup on many AArch64 implementations. Also model the crypto instructions on Cortex-A57 according to the Optimization Guide. Passes regression tests. ChangeLog: 2015-10-14 Wilco Dijkstra

[PATCH][ARM][4.9/5 Backport] PR target/67929 Tighten vfp3_const_double_for_bits checks

Hi all, This is the 4.9 and GCC 5 version of the patch I posted earlier to fix the referenced PR. Bootstrapped and tested arm-none-linux-gnueabihf on those branches. Ok for the branches? Thanks, Kyrill 2015-10-12 Kyrylo Tkachov PR target/67929 * config/arm/arm.c (vfp3_const_double

[PATCH][ARM] PR target/67929 Tighten vfp3_const_double_for_bits checks

Hi all, This patch fixes the referenced PR by rewriting the vfp3_const_double_for_bits function in arm.c The function is supposed to accept positive CONST_DOUBLE rtxes whose value is an exact power of 2 and whose log2 is between 1 and 32. That is values like 2.0, 4.0, 8.9, 16.0 etc... The cur

Re: [PATCH] Optimize const1 * copysign (const2, y) in reassoc (PR tree-optimization/67815)

On Wed, Oct 14, 2015 at 11:10:38AM +0200, Richard Biener wrote: > > + FOR_EACH_VEC_ELT (*ops, i, oe) > > +{ > > + if (TREE_CODE (oe->op) == SSA_NAME) > > I think you need to check whether the SSA_NAME has a single use only > as you are changing its value. Which also means you shouldn't

Re: [PATCH 7/7] Libsanitizer merge from upstream r249633.

On Wed, Oct 14, 2015 at 03:02:22PM +0300, Maxim Ostapenko wrote: > On 14/10/15 14:06, Jakub Jelinek wrote: > >On Wed, Oct 14, 2015 at 01:51:44PM +0300, Maxim Ostapenko wrote: > >>Ok, got it. The first solution would require changes in libsanitizer because > >>heuristic doesn't work for GCC, so perh

Re: [PR libgomp/65437, libgomp/66518] Initialize runtime in acc_update_device, acc_update_self

On 10/09/2015 05:14 PM, Thomas Schwinge wrote: Hi! On Fri, 19 Jun 2015 09:47:41 +0200, I wrote: On Tue, 5 May 2015 11:43:20 +0200, I wrote: On Mon, 4 May 2015 10:20:14 -0400, John David Anglin wrote: FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/lib-42.c -DACC_DEVICE_TYPE_hos t=1 -DACC_

Re: [vec-cmp, patch 3/6] Vectorize comparison

2015-10-13 16:45 GMT+03:00 Richard Biener : > On Thu, Oct 8, 2015 at 5:03 PM, Ilya Enkovich wrote: >> Hi, >> >> This patch supports comparison statements vectrization basing on introduced >> optabs. >> >> Thanks, >> Ilya >> -- >> gcc/ >> >> 2015-10-08 Ilya Enkovich >> >> * tree-vect-da

Re: libgomp testsuite: Remove some explicit acc_device_nvidia usage

On 10/09/2015 05:11 PM, Thomas Schwinge wrote: On Wed, 22 Jul 2015 16:39:54 +0200, I wrote: [...] cleanup; committed to gomp-4_0-branch in r226072: [...] OK for trunk? I think all three patches here look OK. Bernd

Re: [PATCH 7/7] Libsanitizer merge from upstream r249633.

On 14/10/15 14:06, Jakub Jelinek wrote: On Wed, Oct 14, 2015 at 01:51:44PM +0300, Maxim Ostapenko wrote: Ok, got it. The first solution would require changes in libsanitizer because heuristic doesn't work for GCC, so perhaps new UBSan entry point should go upstream, right? Or this may be impleme

Re: [gomp4] privatize internal array variables introduced by the fortran FE

Dear Cesar, > > Is there any reason why only certain arrays have array descriptors? The > arrays with descriptors don't have this problem. It's only the ones > without descriptors that leak new internal variables that cause errors > with default(none). > This is an obvious question to which there

Re: Move some bit and binary optimizations in simplify and match

On Wed, 14 Oct 2015, Richard Biener wrote: On Wed, Oct 14, 2015 at 12:45 PM, Marc Glisse wrote: On Wed, 14 Oct 2015, Richard Biener wrote: +/* Fold (a * (1 << b)) into (a << b) */ +(simplify + (mult:c @0 (convert? (lshift integer_onep@1 @2))) + (if (! FLOAT_TYPE_P (type) +&& tree_n

Re: [vec-cmp, patch 2/6] Vectorization factor computation

2015-10-13 16:37 GMT+03:00 Richard Biener : > On Thu, Oct 8, 2015 at 4:59 PM, Ilya Enkovich wrote: >> Hi, >> >> This patch handles statements with boolean result in vectorization factor >> computation. For comparison its operands type is used instead of restult >> type to compute VF. Other boo

Re: [PATCH 7/7] Libsanitizer merge from upstream r249633.

On Wed, Oct 14, 2015 at 01:51:44PM +0300, Maxim Ostapenko wrote: > Ok, got it. The first solution would require changes in libsanitizer because > heuristic doesn't work for GCC, so perhaps new UBSan entry point should go > upstream, right? Or this may be implemented as local patch for GCC? No. Th

Re: Move some bit and binary optimizations in simplify and match

On Wed, Oct 14, 2015 at 12:45 PM, Marc Glisse wrote: > On Wed, 14 Oct 2015, Richard Biener wrote: > >>> +/* Fold (a * (1 << b)) into (a << b) */ >>> +(simplify >>> + (mult:c @0 (convert? (lshift integer_onep@1 @2))) >>> + (if (! FLOAT_TYPE_P (type) >>> +&& tree_nop_conversion_p (type, TR

Re: [PATCH 7/7] Libsanitizer merge from upstream r249633.

On 14/10/15 10:48, Jakub Jelinek wrote: On Tue, Oct 13, 2015 at 02:22:36PM +0300, Maxim Ostapenko wrote: This is the final patch. Force libsanitizer to use an old ABI for ubsan float cast data descriptors, because for some exprs (e.g. that type of tcc_declaration) we can't get the right location

Re: [vec-cmp, patch 4/6] Support vector mask invariants

2015-10-14 11:49 GMT+03:00 Richard Biener : > On Tue, Oct 13, 2015 at 4:52 PM, Ilya Enkovich wrote: >> I don't understand what you mean. vect_get_vec_def_for_operand has two >> changes made. >> 1. For boolean invariants use build_same_sized_truth_vector_type >> instead of get_vectype_for_scalar_ty

  1   2   >