Re: [patch, libgomp, OpenACC] Additional enter/exit data map handling

Ping. On 2016/9/6 7:45 PM, Chung-Lin Tang wrote: > Ping. > > On 2016/8/29 03:46 PM, Chung-Lin Tang wrote: >> Hi Jakub, >> this patch is a port of some changes from gomp-4_0-branch, >> including adding additional map type handling in OpenACC enter/exit data >> directives, and some pointer set

Re: Early jump threading

On Mon, Sep 19, 2016 at 2:48 AM, Jan Hubicka wrote: > Hi, > this is the patch compensating testsuite I commited after re-testing > on x86_64-linux. > > Other placements of early_thread_jumps does not work veyr well (at least in > current implementation). Putting it before forwprop

Re: [f...@deneb.enyo.de: [PATCH] ada/77535: GNAT.Perfect_Hash_Generators for non-1-based strings]

> This patch fixes GNAT.Perfect_Hash_Generators for strings which are > not 1-based. It does this by introducing its own storage type which > fixes the first index as 1. This is also a minor optimization because > it avoids the need to store the index. > > Okay for trunk? > > Should I try to

Re: [RFC][IPA-VRP] Early VRP Implementation

Hi Richard, On 16/09/16 20:21, Richard Biener wrote: On Fri, Sep 16, 2016 at 7:59 AM, kugan wrote: Hi Richard, Thanks for the review. On 14/09/16 22:04, Richard Biener wrote: On Tue, Aug 23, 2016 at 4:11 AM, Kugan Vivekanandarajah

Re: [PR72835] Incorrect arithmetic optimization involving bitfield arguments

Hi Richard, On 14/09/16 21:31, Richard Biener wrote: On Fri, Sep 2, 2016 at 10:09 AM, Kugan Vivekanandarajah wrote: Hi Richard, On 25 August 2016 at 22:24, Richard Biener wrote: On Thu, Aug 11, 2016 at 1:09 AM, kugan

Re: Do not drom MEM_EXPR when accessing structure fields

> Hi, > > > when expanding code for > > struct a {short a,b,c,d;} *a; > > a->c; > > > > we first produce correct BLKmode MEM rtx representing the whole > > structure *a, > > then we use adjust_address to turn it into HImode MEM and finally > > extract_bitfield is used to offset it by 32

Re: Fortran, committed: segfault with allocate and stat for derived types with default initialization (pr 68078)

Two possibilities: 1. malloc() doesn't silently return NULL on Darwin when it runs out of memory; it always generates an error message. 2. setrlimit() doesn't work the same on Darwin as it does on Linux, and the test program is hitting a system limit. It so happens that when I first looked

Re: Early jump threading

Hi, this is the patch compensating testsuite I commited after re-testing on x86_64-linux. Other placements of early_thread_jumps does not work veyr well (at least in current implementation). Putting it before forwprop disables about 15% of threadings. Placing it after DCE makes inliner to not see

[v3 PATCH] PR libstdc++/77619

Tested on Linux-x64. 2016-09-19 Ville Voutilainen PR libstdc++/77619 * include/bits/stl_construct.h: (_Construct_novalue): New. (_Destroy_n_aux, _Destroy_n): New. * include/bits/stl_uninitialized.h: (type_traits): New include in C++11 mode.

Re: PR35503 - warn for restrict pointer

On 2 September 2016 at 23:14, David Malcolm wrote: > On Thu, 2016-09-01 at 14:55 +0530, Prathamesh Kulkarni wrote: > > [...] > >> The attached version passes bootstrap+test on ppc64le-linux-gnu. >> Given that it only looks if parameters are restrict qualified and not >> how

Re: Do not drom MEM_EXPR when accessing structure fields

Hi, > when expanding code for > struct a {short a,b,c,d;} *a; > a->c; > > we first produce correct BLKmode MEM rtx representing the whole > structure *a, > then we use adjust_address to turn it into HImode MEM and finally > extract_bitfield is used to offset it by 32 bits to get correct

Re: [PATCH, docs] invoke.texi: random copy-editing

On Mon, 5 Sep 2016, Sandra Loosemore wrote: >> I noticed you changed return-value and return-type to their >> variants without a dash. Would it make sense to add the >> following to https://gcc.gnu.org/codingconventions.html#Spelling ? > Perhaps add here that "return type" and "return value" are

Re: [PATCH, i386, AVX-512] Fix test expected result.

On 18 Sep 15:46, Kirill Yukhin wrote: > Hello, > Expected intrinsic result is wrong due two > misunderstanding of operands order. > Patch in the bottom fixes result. > Tes now pass under SDE. > > gcc/testsuite > * gcc.target/i386/pr68633.c: Fix expected result. Comitted to main trunk. > >

Do not drom MEM_EXPR when accessing structure fields

Hi, when expanding code for struct a {short a,b,c,d;} *a; a->c; we first produce correct BLKmode MEM rtx representing the whole structure *a, then we use adjust_address to turn it into HImode MEM and finally extract_bitfield is used to offset it by 32 bits to get correct value. The catch is

[PATCH, i386, AVX-512] Fix test expected result.

Hello, Expected intrinsic result is wrong due two misunderstanding of operands order. Patch in the bottom fixes result. Tes now pass under SDE. gcc/testsuite * gcc.target/i386/pr68633.c: Fix expected result. -- Thanks, K commit 122a8a1e77416d14f9d84f7a44241808dce6447e Author: Kirill

Make regcprop to eliminate noop moves better

Hi, while working on the GCN port I ended up with many redundant register copies of the form mov reg, exec do something mov reg, exec do something ... these copies are generated by LRA because exec is small register class and needs a lot of reloading (it could be improved too, but I do not

Re: Fortran, committed: segfault with allocate and stat for derived types with default initialization (pr 68078)

> Fixed in revision 240219. The test fails on x86_64-apple-darwin15 (at least): FAIL: gfortran.dg/pr68078.f90 -O0 output pattern test FAIL: gfortran.dg/pr68078.f90 -O1 output pattern test FAIL: gfortran.dg/pr68078.f90 -O2 output pattern test FAIL: gfortran.dg/pr68078.f90 -O3

[PATCH] Fix PR tree-optimization/77550

Hi, this PR shows that in vectorizable_store and vectorizable_load as well, the vector access always uses the first dr as the alias type for the whole access. But that is not right, if they are different types, like in this example. So I tried to replace all reference_alias_ptr_type (DR_REF

Fortran, committed: segfault with allocate and stat for derived types with default initialization (pr 68078)

Fixed in revision 240219.