Re: [RFC, LRA] Repeated looping over subreg reloads.

2013-12-05 Thread Tejas Belagod
Vladimir Makarov wrote: On 12/4/2013, 6:15 AM, Tejas Belagod wrote: Hi, I'm trying to relax CANNOT_CHANGE_MODE_CLASS for aarch64 to allow all mode changes on FP_REGS as aarch64 does not have register-packing, but I'm running into an LRA ICE. A test case generates an RTL subreg of the following

Remove spam in GCC mailing list

2013-12-05 Thread Tae Wong
Here's some spam posts in mailing lists: http://gcc.gnu.org/ml/gcc-bugs/2013-07/msg01127.html http://gcc.gnu.org/ml/gcc/2013-04/msg00190.html http://gcc.gnu.org/ml/gcc/2013-04/msg00276.html http://gcc.gnu.org/ml/gcc/2013-04/msg00143.html The mailing list administrators needs to clean up spam.

Re: Dependency confusion in sched-deps

2013-12-05 Thread Michael Matz
Hi, On Thu, 5 Dec 2013, Maxim Kuvyrkov wrote: > Output dependency is the right type (write after write). Anti > dependency is write after read, and true dependency is read after write. > > Dependency type plays a role for estimating costs and latencies between > instructions (which affects pe

Libbacktrace backtrace_vector_finish

2013-12-05 Thread Jakub Jelinek
Hi! I'm trying to understand how the backtrace_vector_* APIs are meant to work and used, but at least for alloc.c don't see how it can work properly: Both backtrace_vector_grow and backtrace_vector_release use base = realloc (vec->base, alc); or vec->base = realloc (vec->base, vec->size);

Re: C++ std headers and malloc, realloc poisoning

2013-12-05 Thread Jason Merrill
On 12/04/2013 04:03 PM, Jakub Jelinek wrote: I think the most important reason is that we want to handle out of mem cases consistently, so instead of malloc etc. we want users to use xmalloc etc. that guarantee non-NULL returned value, or fatal error and never returning. For operator new that is

Re: C++ std headers and malloc, realloc poisoning

2013-12-05 Thread Oleg Endo
On Thu, 2013-12-05 at 10:45 -0500, Jason Merrill wrote: > On 12/04/2013 04:03 PM, Jakub Jelinek wrote: > > I think the most important reason is that we want to handle out of mem > > cases consistently, so instead of malloc etc. we want users to use xmalloc > > etc. that guarantee non-NULL returned

Re: Truncate optimisation question

2013-12-05 Thread Eric Botcazou
> The comment says that we're trying to match: > > 1. (set (reg:SI) (zero_extend:SI (plus:QI (mem:QI) (const_int > 2. (set (reg:QI) (plus:QI (mem:QI) (const_int))) > 3. (set (reg:QI) (plus:QI (subreg:QI) (const_int))) > 4. (set (reg:CC) (compare:CC (subreg:QI) (const_int))) > 5. (set (reg:CC)

Re: C++ std headers and malloc, realloc poisoning

2013-12-05 Thread Jason Merrill
On 12/05/2013 10:59 AM, Oleg Endo wrote: On Thu, 2013-12-05 at 10:45 -0500, Jason Merrill wrote: A simple workaround would be to disable poisoning of malloc/realloc on OS X (or when the build machine uses libc++, if that's easy to detect). Whether libc++ uses malloc/realloc/free in some implem

Re: C++ std headers and malloc, realloc poisoning

2013-12-05 Thread Jakub Jelinek
On Thu, Dec 05, 2013 at 12:05:23PM -0500, Jason Merrill wrote: > On 12/05/2013 10:59 AM, Oleg Endo wrote: > >On Thu, 2013-12-05 at 10:45 -0500, Jason Merrill wrote: > >>A simple workaround would be to disable poisoning of malloc/realloc on > >>OS X (or when the build machine uses libc++, if that's

Re: C++ std headers and malloc, realloc poisoning

2013-12-05 Thread Oleg Endo
On Thu, 2013-12-05 at 18:11 +0100, Jakub Jelinek wrote: > On Thu, Dec 05, 2013 at 12:05:23PM -0500, Jason Merrill wrote: > > On 12/05/2013 10:59 AM, Oleg Endo wrote: > > >On Thu, 2013-12-05 at 10:45 -0500, Jason Merrill wrote: > > >>A simple workaround would be to disable poisoning of malloc/reallo

Re: Truncate optimisation question

2013-12-05 Thread Richard Sandiford
Eric Botcazou writes: >> The comment says that we're trying to match: >> >> 1. (set (reg:SI) (zero_extend:SI (plus:QI (mem:QI) (const_int >> 2. (set (reg:QI) (plus:QI (mem:QI) (const_int))) >> 3. (set (reg:QI) (plus:QI (subreg:QI) (const_int))) >> 4. (set (reg:CC) (compare:CC (subreg:QI) (con

Re: Libbacktrace backtrace_vector_finish

2013-12-05 Thread Ian Lance Taylor
On Thu, Dec 5, 2013 at 7:32 AM, Jakub Jelinek wrote: > > I'm trying to understand how the backtrace_vector_* APIs are meant to work > and used, but at least for alloc.c don't see how it can work properly: > > Both backtrace_vector_grow and backtrace_vector_release use > base = realloc (vec->

Re: Dependency confusion in sched-deps

2013-12-05 Thread shmeel gutl
On 05-Dec-13 02:39 AM, Maxim Kuvyrkov wrote: Dependency type plays a role for estimating costs and latencies between instructions (which affects performance), but using wrong or imprecise dependency type does not affect correctness. On multi-issue architectures it does make a difference. Anti d

gcc-4.8-20131205 is now available

2013-12-05 Thread gccadmin
Snapshot gcc-4.8-20131205 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.8-20131205/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.8 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches

Re: Dependency confusion in sched-deps

2013-12-05 Thread Maxim Kuvyrkov
On 6/12/2013, at 4:25 am, Michael Matz wrote: > Hi, > > On Thu, 5 Dec 2013, Maxim Kuvyrkov wrote: > >> Output dependency is the right type (write after write). Anti >> dependency is write after read, and true dependency is read after write. >> >> Dependency type plays a role for estimating c

Re: Dependency confusion in sched-deps

2013-12-05 Thread Maxim Kuvyrkov
On 6/12/2013, at 8:44 am, shmeel gutl wrote: > On 05-Dec-13 02:39 AM, Maxim Kuvyrkov wrote: >> Dependency type plays a role for estimating costs and latencies between >> instructions (which affects performance), but using wrong or imprecise >> dependency type does not affect correctness. > On m

Re: Hmmm, I think we've seen this problem before (lto build):

2013-12-05 Thread Trevor Saunders
On Mon, Dec 02, 2013 at 12:16:18PM +0100, Richard Biener wrote: > On Sun, Dec 1, 2013 at 12:30 PM, Toon Moene wrote: > > http://gcc.gnu.org/ml/gcc-testresults/2013-12/msg1.html > > > > FAILED: Bootstrap (build config: lto; languages: fortran; trunk revision > > 205557) on x86_64-unknown-linux-