On 04/22/2015 12:13 PM, David Malcolm wrote:
Conditional compilation was a major PITA when doing the rtx->rtx_insn *
work last year, so I'm very pleased to see these cleanups go in.
Yup. It also got in Andrew's way last year and we regularly see cases
where small patches which work fine on th
Hi,
This patch is an attempt to fix some potential race conditions with
accesses to shared data structures from multiple concurrent threads in
libgomp's OpenACC entry points. The main change is to move locking out
of lookup_host and lookup_dev in oacc-mem.c and into their callers
(which can then h
This patch adjusts the testcase to work with the now slightly different
ordering of DIEs in the branch.
Brought to you by the letter "N" for "nightmare".
Committed to branch.
Aldy
commit 7996af2f984f42a9694c466ee05d5067696503cc
Author: Aldy Hernandez
Date: Wed Apr 22 12:20:10 2015 -0700
Hello
Here is a rather trivial patch, just code cleanup. Since we export
_Prime_rehash_policy we do not need to expose the _S_n_primes anymore.
* include/bits/hashtable_policy.h (_Prime_rehash_policy::_S_n_primes):
Delete.
* src/c++11/hashtable_c++0x.cc (_Prime_rehash_policy::_
On April 13, 2015 3:12:48 PM GMT+02:00, Jeff Law wrote:
>On 04/11/2015 04:27 PM, Bernhard Reutner-Fischer wrote:
>> Hi,
>>
>> I'd like to ask an RM or global reviewer to kindly consider the
>> following patches preventing one or the other target in
>config-list.mk
>> to build:
>>
>> [PATCH, bfin]
Hello
I don't know if I am missing something but I think __niter_base
could be simplified to remove usage of _Iter_base. Additionally I
overload it to also remove __normal_iterator layer even if behind a
reverse_iterator or move_iterator, might help compiler to optimize code,
no ? If not,
With the patch this time.
On 22/04/2015 21:39, François Dumont wrote:
Hello
Here is a rather trivial patch, just code cleanup. Since we export
_Prime_rehash_policy we do not need to expose the _S_n_primes anymore.
* include/bits/hashtable_policy.h
(_Prime_rehash_policy::_S_n_primes
On Wed, Apr 22, 2015 at 09:39:48PM +0200, François Dumont wrote:
> Hello
>
> Here is a rather trivial patch, just code cleanup. Since we export
> _Prime_rehash_policy we do not need to expose the _S_n_primes anymore.
>
> * include/bits/hashtable_policy.h (_Prime_rehash_policy::_S_n_primes
On Wed, Apr 22, 2015 at 12:36:58PM -0600, Jeff Law wrote:
> On 04/22/2015 12:13 PM, David Malcolm wrote:
>
> >
> >Conditional compilation was a major PITA when doing the rtx->rtx_insn *
> >work last year, so I'm very pleased to see these cleanups go in.
> Yup. It also got in Andrew's way last yea
On 04/22/2015 02:46 PM, Trevor Saunders wrote:
yeah, its irritated me on a number of occasions too. I'd really like it
if building config-list.mk could be faster, but that's a much bigger
project, but at least if everything is target hooks maybe ccache can
kick in some.
I don't see ccache kickin
Hi Kirill,
On 21.04.15 10:28, Kirill Yukhin wrote:
On 19 Apr 21:56, Andreas Tobler wrote:
Done so and tested on FreeBSD amd64-unknown-freebsd11.0 and CentOS7.1.
Ok for trunk?
The patch is OK for trunk and for gcc-5 branch (when it is open).
Thanks for fixing this!
Done on trunk and gcc-5.
On 19/01/15 22:28, Richard Biener wrote:
> On Sat, 17 Jan 2015, Kugan wrote:
>
>>
>> This patch propagate value range wrapps attribute and save this to
>> SSA_NAME.
>
> diff --git a/gcc/tree-vrp.c b/gcc/tree-vrp.c
> index 9b7695d..832c35d 100644
> --- a/gcc/tree-vrp.c
> +++ b/gcc/tree-vrp.c
> @@
On 17/01/15 13:06, Kugan wrote:
> Freeing a spare-bit to store wrapped attribute by going back to
> representing VR_ANTI_RANGE as [max + 1, min - 1] in SSA_NAME.
>
Now that stage-1 is open, rebased it and regression tested on
x86-64-none-linux-gnu with no new regressions.
Is this OK for trunk?
On 17/01/15 13:11, Kugan wrote:
>
> Re-enable zero/sign extension elimination using value range that
> includes wrapped attribute.
>
Now that stage-1 is open, rebased it and regression tested on
x86-64-none-linux-gnu with no new regressions.
Is this OK for trunk?
Thanks,
Kugan
gcc/ChangeLog:
On Wed, Apr 22, 2015 at 5:34 PM, H.J. Lu wrote:
> Normally, with PIE, GCC accesses globals that are extern to the module
> using GOT. This is two instructions, one to get the address of the global
> from GOT and the other to get the value. Examples:
>
> ---
> extern int a_glob;
> int
> main ()
>
On Wed, Apr 22, 2015 at 08:43:10AM -0500, Peter Bergner wrote:
> > Maybe you can fold tabortdc with tabortwc now? Use one UNSPEC name
> > for both, :GPR and ?
>
> Wouldn't that change the tabortwc pattern to use DImode rather
> than SImode when compiled with -m64 or -m32 -mpowerpc64?
> I'm not su
On Wed, Apr 22, 2015 at 3:15 PM, Ramana Radhakrishnan
wrote:
> On Wed, Apr 22, 2015 at 5:34 PM, H.J. Lu wrote:
>> Normally, with PIE, GCC accesses globals that are extern to the module
>> using GOT. This is two instructions, one to get the address of the global
>> from GOT and the other to get t
On Wed, 2015-04-22 at 17:16 -0500, Segher Boessenkool wrote:
> On Wed, Apr 22, 2015 at 08:43:10AM -0500, Peter Bergner wrote:
> > > Maybe you can fold tabortdc with tabortwc now? Use one UNSPEC name
> > > for both, :GPR and ?
> >
> > Wouldn't that change the tabortwc pattern to use DImode rather
On Tue, Apr 07, 2015 at 12:59:20PM -0700, Steve Kargl wrote:
> On Tue, Mar 31, 2015 at 10:17:14AM -0700, Jerry DeLisle wrote:
> > On 03/29/2015 09:25 AM, Steve Kargl wrote:
> > > On Sat, Mar 28, 2015 at 01:01:57AM +0100, Dominique Dhumieres wrote:
> > >>
> > >> AFAICT your test succeeds without you
On Wed, Apr 22, 2015 at 3:15 PM, Kugan
wrote:
> On 17/01/15 13:11, Kugan wrote:
>>
>> Re-enable zero/sign extension elimination using value range that
>> includes wrapped attribute.
>>
>
> Now that stage-1 is open, rebased it and regression tested on
> x86-64-none-linux-gnu with no new regressions
The attached patch fixes
gcc/testsuite/g++.dg/debug/dwarf2/template-func-params-7.C.
The problem is that DW_TAG_GNU_formal_parameter_pack DIEs are generated
multiple times (once for early dwarf and once for late dwarf). Fixed by
only outputting in early dwarf.
Tested with GCC and GDB testsu
On 23/04/15 09:48, H.J. Lu wrote:
> On Wed, Apr 22, 2015 at 3:15 PM, Kugan
> wrote:
>> On 17/01/15 13:11, Kugan wrote:
>>>
>>> Re-enable zero/sign extension elimination using value range that
>>> includes wrapped attribute.
>>>
>>
>> Now that stage-1 is open, rebased it and regression tested on
Hi,
this patch strenghtens ipa-icf to allow merging non-inline function to
inline function. This is safe because inline flag does not affect function
itself. It only affects way the function is used, so we need to compare the
flag only when comparing references. (inline flag mismatch is one of com
On Wed, Apr 22, 2015 at 06:08:26PM -0500, Peter Bergner wrote:
> > > > > + case HTM_BUILTIN_TTEST: /* Alias for: tabortwci. 0,r0,0 */
> > > > > + op[nopnds++] = GEN_INT (0);
> > > > > + op[nopnds++] = gen_rtx_REG (SImode, 0);
> > > > > + op[nopnds++] = GEN_INT (0);
>
Hi there,
This patch is to correct options in arm test case pr65710.c. I reused
some existing test case as template to produce this case, but forgot
to update the options. Is it OK to trunk?
BR,
Terry
2015-04-23 Terry Guo
* gcc.target/arm/pr65710.c: Update the options.
diff --git a/gcc/te
On Wed, 2015-04-22 at 20:55 -0500, Segher Boessenkool wrote:
> Using a hard reg in the RTL like this has a few problems:
> a) It might hinder register allocation. Maybe it doesn't, not sure;
> b) It does hinder scheduling;
> c) It can make things ICE, maybe with register asm.
Ahh, I see what you
On Tue, Apr 21, 2015 at 04:24:44PM +0100, Trevor Saunders wrote:
> On Tue, Apr 21, 2015 at 04:14:01PM +0200, Richard Biener wrote:
> > On Tue, Apr 21, 2015 at 3:24 PM, wrote:
> > > From: Trevor Saunders
> > >
> > > gcc/ChangeLog:
> > >
> > > 2015-04-21 Trevor Saunders
> > >
> > > * co
On Thu, Apr 23, 2015 at 04:27:59AM +0100, James Greenhalgh wrote:
> On Tue, Apr 21, 2015 at 04:24:44PM +0100, Trevor Saunders wrote:
> > On Tue, Apr 21, 2015 at 04:14:01PM +0200, Richard Biener wrote:
> > > On Tue, Apr 21, 2015 at 3:24 PM, wrote:
> > > > From: Trevor Saunders
> > > >
> > > > gcc
101 - 128 of 128 matches
Mail list logo
