On 10/31/11 19:20, Jonathan Wakely wrote:
> On 31 October 2011 17:38, Rainer Orth wrote:
>> Dennis Clarke writes:
>>
> I'm uncertain if Solaris 8/x86 still supports bare i386 machines, so it
> might be better to keep the default of pentiumpro instead.
Solaris 8 won't run on anyt
From: David Miller
Date: Fri, 28 Oct 2011 01:05:54 -0400 (EDT)
> So should expand_vector_broadcast() really provide this invariant to
> the vec_init expander, or does the vec_init expander need to tidy
> things up with gen_lowpart() etc. calls?
Richard I don't know if you had a chance to look in
2011/11/1 Richard Guenther :
> 2011/11/1 杜越海 :
>> Hi all
>>
>> I found IVopts rewrite a memory access with a weird iv candidate,
>> which make it lost its original memory attribute.
>> a non-local memory access' base pointer was rewrite into a local one,
>> and it was deleted in pass_cd_dce sinc
While I really like machine-readable (and searchable) text online for the GCC
internals, there's still an atavistic streak in me that wants hard copy that I
can put post-it notes on, run a highlighter over relevant passages or read when
I'm not near a computer screen.
I have two bound hard-copi
On Mon, Oct 31, 2011 at 10:58:03AM -0500, Moffett, Kyle D wrote:
> I have not yet been able to figure out if it's a libgcc issue or an
> actual compiler issue.
It is a gcc bug. I've added a comment to the PR.
--
Alan Modra
Australia Development Lab, IBM
Snapshot gcc-4.4-2001 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-2001/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
I'd like to see some breakdown into subsystem patches. Can someone provide
those together with changelog entries?
I am doing another merge from trunk->branch, and will post a series of
patches by subsystem. I will do so after the merge is complete and tested.
Please, when replying, also send to me, not just the list.
On Tue, 1 Nov 2011, Paulo J. Matos wrote:
> On 01/11/11 02:43, Hans-Peter Nilsson wrote:
> >
> > Not obvious or maybe I was unclear as to what I alluded?
> > In the below insn-bodies, "sub" is the insn that sets cc0 as a
> > side-effect.
>
On Tue, Nov 1, 2011 at 5:59 PM, David Edelsohn wrote:
> On Tue, Nov 1, 2011 at 5:49 AM, Richard Guenther
> wrote:
>
>> Given that you only recently merged with trunk again are you really
>> sure this is a great
>> idea at this point in time? Does the GCC 4.7 user community benefit from
>> this
Hi!
As the vgather* insns are designed to support both
unconditional and conditional gather loads, the current
pattern consume the previous content of the destination
register, so we end up with code like:
vmovaps .LC0(%rip), %ymm0
vmovdqa .LC1(%rip), %ymm5
vmovdqa .LC2(%ri
Have you looked at those diffs, there's a fair amount of unrelated
Will clean up.
crud in there... It might help to break the blob into more easily
understood hunks for actual submissions. ie, runtime bits (libitm),
changes to existing runtime stuff, compiler proper, testsuite bits, etc.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/01/11 12:44, Aldy Hernandez wrote:
>
>> Aldy, Richard, is there a patchset or master patch I could read?
>
> I have made current diff as of today:
>
> http://quesejoda.com/tm-branch-latest.bz2
Umm,
Have you looked at those diffs, there's a f
On 11-11-01 14:44 , Aldy Hernandez wrote:
Aldy, Richard, is there a patchset or master patch I could read?
I have made current diff as of today:
http://quesejoda.com/tm-branch-latest.bz2
Thanks.
Diego.
Aldy, Richard, is there a patchset or master patch I could read?
I have made current diff as of today:
http://quesejoda.com/tm-branch-latest.bz2
Richard who? There are two Richards in this thread, and they seem to
have opposing views.
I am confused by the multiple levels of quotes I think (the feature
in mailers of easily allowing you to include an entire earlier thread
is evil! :-)
Anyway, I support merging this in ...
Diego.
On Tue, Nov 1, 2011 at 17:19, Robert Dewar wrote:
> On 11/1/2011 12:59 PM, David Edelsohn wrote:
>>
>> On Tue, Nov 1, 2011 at 5:49 AM, Richard Guenther
>> wrote:
>>
>>> Given that you only recently merged with trunk again are you really
>>> sure this is a great
>>> idea at this point in time? D
On 11/1/2011 12:59 PM, David Edelsohn wrote:
On Tue, Nov 1, 2011 at 5:49 AM, Richard Guenther
wrote:
Given that you only recently merged with trunk again are you really
sure this is a great
idea at this point in time? Does the GCC 4.7 user community benefit from this
in any way (or rather ho
On Tue, Nov 1, 2011 at 5:49 AM, Richard Guenther
wrote:
> Given that you only recently merged with trunk again are you really
> sure this is a great
> idea at this point in time? Does the GCC 4.7 user community benefit from this
> in any way (or rather how much percentage of it)?
GCC has a hist
On 11-11-01 11:23 , Jeff Law wrote:
This stuff is fairly isolated in terms of what it touches and I'm sure
if anything goes wrong, Aldy, Richard& Torvald will be available to
fix it.
The request to merge came in before the end of stage1, I don't see a
reason to delay things another 6-9 months.
I've put gcc-patches@ back in the CC list and removed gcc@
On 1 November 2011 15:35, niXman wrote:
>> Er, the macro _GLIBCXX_NPROCS already handles
>> the case sysconf(_SC_NPROCESSORS_ONLN).
>> It looks like you actually want to remove the macro
>> _GLIBCXX_NPROCS completely.
>
> Fixed.
No, this
> Er, the macro _GLIBCXX_NPROCS already handles
> the case sysconf(_SC_NPROCESSORS_ONLN).
> It looks like you actually want to remove the macro
> _GLIBCXX_NPROCS completely.
Fixed.
diff --git a/libstdc++-v3/src/thread.cc b/libstdc++-v3/src/thread.cc
index 09e7fc5..6feda4d 100644
--- a/libstdc++-v
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/01/11 03:49, Richard Guenther wrote:
>
> Given that you only recently merged with trunk again are you
> really sure this is a great idea at this point in time? Does the
> GCC 4.7 user community benefit from this in any way (or rather how
> muc
On 11/01/2011 01:52 PM, Torvald Riegel wrote:
> Yes, we think so. Transactional Memory (TM) is a very easy-to-use
> synchronization mechanism, which does not burden the programmer with
> having to consider issues such as deadlocks or having to rely on
> conventions regarding which locks cover which
On Tue, 2011-11-01 at 10:49 +0100, Richard Guenther wrote:
> On Mon, Oct 31, 2011 at 11:33 PM, Aldy Hernandez wrote:
> > This is somewhat of a me-too message for the transactional-memory work. We
> > would also like it to be considered for merging with mainline before the end
> > of stage1.
[sni
On 01/11/11 02:43, Hans-Peter Nilsson wrote:
Not obvious or maybe I was unclear as to what I alluded?
In the below insn-bodies, "sub" is the insn that sets cc0 as a
side-effect.
Supposed canonical form :
(parallel
[(set cc_reg) (compare ...))
(set destreg) (sub ...))])
and:
(parallel
[(
"Bingfeng Mei" wrote on 01/11/2011 01:25:14 PM:
> Ira,
> Thank you very much for quick answer. I will check 4.7 x86-64
> to see difference from our port. Is there significant change
> between 4.5 & 4.7 regarding SLP?
Yes, I think so. 4.5 can't SLP data accesses with unknown alignment that
you
Ira,
Thank you very much for quick answer. I will check 4.7 x86-64
to see difference from our port. Is there significant change
between 4.5 & 4.7 regarding SLP?
Cheers,
Bingfeng
> -Original Message-
> From: Ira Rosen [mailto:i...@il.ibm.com]
> Sent: 01 November 2011 11:13
> To: Bingfeng
gcc-ow...@gcc.gnu.org wrote on 01/11/2011 12:41:32 PM:
> Hello,
> I have one example with two very similar loops. cunrolli pass
> unrolls one loop completely
> but not the other based on slightly different cost estimations. The
> not-unrolled loop
> get SLP-vectorized, then unrolled by "cunroll"
Hello,
I have one example with two very similar loops. cunrolli pass unrolls one loop
completely
but not the other based on slightly different cost estimations. The
not-unrolled loop
get SLP-vectorized, then unrolled by "cunroll" pass, whereas the other unrolled
loop cannot
be vectorized since
2011/11/1 杜越海 :
> Hi all
>
> I found IVopts rewrite a memory access with a weird iv candidate,
> which make it lost its original memory attribute.
> a non-local memory access' base pointer was rewrite into a local one,
> and it was deleted in pass_cd_dce since
> it was recognized as a local memo
On Mon, Oct 31, 2011 at 11:33 PM, Aldy Hernandez wrote:
> This is somewhat of a me-too message for the transactional-memory work. We
> would also like it to be considered for merging with mainline before the end
> of stage1.
>
> We have a kept a wiki here:
>
> http://gcc.gnu.org/wiki/Transactiona
David Miller wrote:
> From: Konrad Eisele
> Date: Tue, 01 Nov 2011 10:19:04 +0100
>
>> David Miller wrote:
>>>
>>> Please post binutils patches with the binutils development list CC:'d.
>>>
>>>
>>
>> Is the binutils development list bug-binut...@gnu.org ?
>
> No, it's binut...@sourceware.org
>
From: Konrad Eisele
Date: Tue, 01 Nov 2011 10:19:04 +0100
> David Miller wrote:
>>
>> Please post binutils patches with the binutils development list CC:'d.
>>
>>
>
> Is the binutils development list bug-binut...@gnu.org ?
No, it's binut...@sourceware.org
David Miller wrote:
>
> GCC patches are to be posted to gcc-patches, not gcc.
>
>
I have sent it there.
David Miller wrote:
>
> Please post binutils patches with the binutils development list CC:'d.
>
>
Is the binutils development list bug-binut...@gnu.org ?
GCC patches are to be posted to gcc-patches, not gcc.
Please post binutils patches with the binutils development list CC:'d.
Use -Aleon to enable binutils sparc-leon architecture. The leon-arch
binutils GAS has umul/smul and casa enabled.
Signed-off-by: Konrad Eisele
---
gcc/config/sparc/sparc.h |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/gcc/config/sparc/sparc.h b/gcc/config/sparc/spar
Add -Aleon architecture selection to GAS. -Aleon supports [umul,smul] and
[casa,casl].
Signed-off-by: Konrad Eisele
---
gas/config/tc-sparc.c |3 ++-
include/opcode/sparc.h |1 +
opcodes/sparc-opc.c| 16 +---
3 files changed, 12 insertions(+), 8 deletions(-)
diff --gi
Here are the new patches for adding -Aleon to binutils and to add -Aleon
as default asm-switch to gcc:
- [PATCH 1/1] sparc leon: add -Aleon architecture to GAS:
Binutils patch
- [PATCH 1/1] sparc leon: Use -Aleon assembler switch for -mcpu=leon arch
Gcc patch
I'll send new patches as a reply.
Eric Botcazou wrote:
> [CCing David Miller, the SPARC binutils maintainer]
> OK, so you're proposing a new 'leon' sub-architecture for binutils.
Yes.
>
>> The appended 2 patches do:
>> 1. 0001-sparc-leon-Use-Aleon-assembler-switch-for-mcpu-leon-.patch
>>Ap
Hi all
I found IVopts rewrite a memory access with a weird iv candidate,
which make it lost its original memory attribute.
a non-local memory access' base pointer was rewrite into a local one,
and it was deleted in pass_cd_dce since
it was recognized as a local memory access.
here is the case
42 matches
Mail list logo
