Hello,
Trunk currently fails to bootstrap with SMS flags on ARM machine. (I'm
using -r175900. btw, -r175091 bootstrap OK)
Investigating the problem; it seems that the cause is not related to
SMS but rather to the doloop optimization which is enabled only when
SMS flags are set. (but that also
On Mon, Jul 18, 2011 at 8:10 PM, Khem Raj raj.k...@gmail.com wrote:
On Mon, Jul 18, 2011 at 4:58 AM, Rohit Arul Raj rohitarul...@gmail.com
wrote:
Is this expected behavior?
yes
Hello Khem,
1. Got in to another error while doing make [make csu/subdir_lib] of
eglibc default headers..
On 18/07/11 19:00, Richard Henderson wrote:
Specifically represent... the carry flag means using the CCmode
style of condition code handling, right?
Yes.
hummm, we are still using the old mode for condition code handling. From
what you're saying we need to use the new CCmode. I was
On 18/07/11 17:53, Richard Henderson wrote:
Therefore in order to expose the carry flag
before reload, you must have an add instruction that does not modify the
carry. Some processors have this in the form of a load-effective-address
instruction.
An add instruction that doesn't modify carry.
On 18/07/11 17:58, Ian Lance Taylor wrote:
Look at addmode3_cc in gcc/config/i386/i386.md. Look at how
adddwi3_doubleword splits to use it.
Thanks Ian, from what Richard said I need an add that doesn't modify
carry in order to follow the approach there. Since I don't I guess I
have to
On 19/07/11 09:21, Paulo J. Matos wrote:
hummm, we are still using the old mode for condition code handling. From
what you're saying we need to use the new CCmode. I was looking at the
internal documents and even though it doesn't seem required to have a
hard register to keep the condition
On 18/07/11 17:53, Richard Henderson wrote:
Otherwise, have a look at the mn10300 and rx ports.
Looking at rx.c, flag_from_code:
static unsigned int
flags_from_code (enum rtx_code code)
{
switch (code)
{
case LT:
case GE:
return CC_FLAG_S;
...
For GE, shouldn't you also
On 19/07/11 11:20, Paulo J. Matos wrote:
For GE, shouldn't you also need CC_FLAG_Z ?
I just got it! :) No need for CC_FLAG_Z!
--
PMatos
On Jul 19, 2011, at 4:21 AM, Paulo J. Matos wrote:
On 18/07/11 19:00, Richard Henderson wrote:
Specifically represent... the carry flag means using the CCmode
style of condition code handling, right?
Yes.
hummm, we are still using the old mode for condition code handling. From what
On Tue, Jul 19, 2011 at 00:09, Gabriel Charette gch...@google.com wrote:
There is also the case where different C files are compiled with different
flags, but using the same headers (in the current build system say). When
moving to pph we would need to recognize that and generate different pph
On 07/18/2011 05:20 PM, dpadgett_mail-...@yahoo.com wrote:
Hello,
Does gcc IRA provide a mechanism to support spilling to registers instead of
the stack? For the particular target I'm looking at, there are some
non-general-purpose registers that can be copied to and from more quickly than
Thanks. I'll pursue specifying a more detailed cost model using existing hooks
to see if I can get the desired behavior.
Don
--- On Tue, 7/19/11, Vladimir Makarov vmaka...@redhat.com wrote:
From: Vladimir Makarov vmaka...@redhat.com
Subject: Re: Does IRA support spilling to registers
On 18/07/11 17:53, Richard Henderson wrote:
Otherwise, have a look at the mn10300 and rx ports.
What's the idea behind the rx port *_flags alternative define_insn?
For example:
(define_insn abssi2
[(set (match_operand:SI 0 register_operand =r,r)
(abs:SI (match_operand:SI 1
What's the point of the second define insn? The first insn seems to
take us from expansion to asm generation so I can't see where the
second one will come into play except in an expansion after reload
but that doesn't happen, right?
IIRC it has to do with optimizing away compare
On 19/07/11 16:06, DJ Delorie wrote:
What's the point of the second define insn? The first insn seems to
take us from expansion to asm generation so I can't see where the
second one will come into play except in an expansion after reload
but that doesn't happen, right?
IIRC it has to do with
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/19/11 07:33, Vladimir Makarov wrote:
On 07/18/2011 05:20 PM, dpadgett_mail-...@yahoo.com wrote:
Hello,
Does gcc IRA provide a mechanism to support spilling to registers
instead of the stack? For the particular target I'm looking at, there
On 07/19/2011 08:08 AM, Paulo J. Matos wrote:
So, this seems to have to do with the post-reload comparison optimization
pass Richard mentioned.
Exactly.
But I am still confused as to how GCC matches them. Is *_flags any
special name GCC loops for (doubtful)?
No, and as you can see from the
On 07/19/2011 01:48 AM, Paulo J. Matos wrote:
I have been looking at the rx port. Seems to be very similar to mine
in that it has an add and adc where both set the flags and no
explicit hard register for cc. Mine is actually simpler in that there
is only CCmode since we don't have floating
On 19/07/11 16:36, Richard Henderson wrote:
But I am still confused as to how GCC matches them. Is *_flags any
special name GCC loops for (doubtful)?
No, and as you can see from the leading * in the name, the
name is not actually visible as a pattern.
Thought so... :)
As an experiment,
On 07/19/2011 11:21 AM, Jeff Law wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/19/11 07:33, Vladimir Makarov wrote:
On 07/18/2011 05:20 PM, dpadgett_mail-...@yahoo.com wrote:
Hello,
Does gcc IRA provide a mechanism to support spilling to registers
instead of the stack? For the
On 19/07/11 16:41, Richard Henderson wrote:
Note that while RX has one mode for floating-point, it has
two other modes to deal with instructions that fail to set
all of the flags (or fails to set the flags in a way that
is useful for the comparison).
Depending on how regular your instructions
On 19/07/11 16:41, Richard Henderson wrote:
(or fails to set the flags in a way that
is useful for the comparison).
I am not sure I understand the above. Could you give an example where
certain flags might be set but are not useful for comparison?
--
PMatos
Thanks. Yes, these registers for the target, which is MIPS16e, cannot be used
in arithmetic, logical, etc. They can only be used in copy instructions. More
specifically, the registers I'm referring to are the general-purpose MIPS32
registers, such as t0 and s2, that are not part of the 8
In the internals, there is no description of a backend
can add a new pass. And no backend uses
passes.c:register_pass (4.5 and 4.7), so here is the question:
How can a backend add a pass?
I tried this code in OVERRIDE_OPTIONS (simply because I
found no canonical place to put it).
struct
I just committed a merge from gcc-4_6-branch into google/gcc-4_6.
This brings google/gcc-4_6 up to rev 176416.
Diego.
On 07/19/2011 08:57 AM, Paulo J. Matos wrote:
On 19/07/11 16:41, Richard Henderson wrote:
(or fails to set the flags in a way that
is useful for the comparison).
I am not sure I understand the above. Could you give an example where
certain flags might be set but are not useful for
Hi
Le 19 juil. 2011 à 18:13, Georg-Johann Lay a écrit :
How can a backend add a pass?
I've never seen any warning about adding a backend pass in
the plugin documentation, which may also register passes thanks
to register_pass. I'm not a guru, but i think it's ok to add it as any
other pass
Romain Geissler schrieb:
Hi
Le 19 juil. 2011 à 18:13, Georg-Johann Lay a écrit :
How can a backend add a pass?
I've never seen any warning about adding a backend pass in
the plugin documentation, which may also register passes thanks
to register_pass. I'm not a guru, but i think it's ok
Georg-Johann Lay a...@gjlay.de writes:
In the internals, there is no description of a backend
can add a new pass. And no backend uses
passes.c:register_pass (4.5 and 4.7), so here is the question:
How can a backend add a pass?
I don't think anybody has ever done this. At the moment only
Khem Raj raj.k...@gmail.com writes:
I a script based on these instructions which is uptodate and builds eglibc
based toolchains
https://github.com/kraj/ct-scripts/blob/master/toolchain-eglibc.sh
Is there any particular reason that you're not taking advantage of the
many person-years of effort
Ian Lance Taylor i...@google.com writes:
I would like to propose this patch as a step toward building gcc using a
C++ compiler. This patch builds stage1 with the C compiler as usual,
and defaults to building stages 2 and 3 with a C++ compiler built during
stage 1. This means that the gcc
There are a number of problems with this code that affect
its ability to work with any non-x86-like target, that is,
anyone that doesn't define at least HAS_LONG_UNCOND_BRANCH
and possibly HAS_LONG_COND_BRANCH.
We begin, quite sensibly, with pass_partition_blocks which
performs a number of
On 07/19/11 23:33, Richard Henderson wrote:
But after pass_partition_blocks, we run into trouble. There
are no less than 4 other passes that add *new* crossing jumps
without doing *any* of the subsequent fixups for less capable
targets: pass_outof_cfg_layout_mode, pass_reorder_blocks,
Hi all,
From info gcc I know it accepts a series of `.FIELDNAME' and `[INDEX]'
designators,
like
struct point ptarray[10] = { [2].y = yv2, [2].x = xv2, [0].x = xv0 };
But in my case, I have a struct with array of int as members,
struct mbox {
int x[20];
int y[20];
On 07/19/2011 02:42 PM, Bernd Schmidt wrote:
On 07/19/11 23:33, Richard Henderson wrote:
But after pass_partition_blocks, we run into trouble. There
are no less than 4 other passes that add *new* crossing jumps
without doing *any* of the subsequent fixups for less capable
targets:
(If you got this email before, its an error and I'm apologize for that)
Hi
My Name is Rotem Hecht. I'm a music composer and sound designer.
I'm expanding my work area overseas,(I'm located in Israel now) so I'm sending
you this email.
I'm composing original music for movies, commercials,
Ian Lance Taylor i...@google.com writes:
I don't think anybody has ever done this. At the moment only plugins
add new passes. But I agree that backends clearly need to be able to do
this, and some passes need to move into the appropriate backends. I
would encourage you to fix this.
I've
On Tue, Jul 19, 2011 at 1:33 PM, Ian Lance Taylor i...@google.com wrote:
Ian Lance Taylor i...@google.com writes:
I got agreement from two global reviewers and no objections.
I have committed this patch.
Great!
-- Gaby
Quoting Richard Henderson r...@redhat.com:
Andrew Pinski points out that the feature could probably be
equivalently implemented via outlining and function calls
(I assume well back at the gimple level).
Function calls would mean that you'd have to deal with
call-clobbered registers - any
re. http://gcc.gnu.org/ml/gcc/2011-07/msg00349.html
Richard Henderson wrote:
After 3 days fighting with this code, I had a bit of a
cathartic whine on IRC. I got two votes to just rip the
whole thing out.
Add one more vote.
Andrew Pinski points out that the feature could probably be
Snapshot gcc-4.4-20110719 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20110719/
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
On 07/19/2011 03:24 PM, Joern Rennecke wrote:
Andrew Pinski points out that the feature could probably be
equivalently implemented via outlining and function calls
(I assume well back at the gimple level).
Function calls would mean that you'd have to deal with
call-clobbered registers - any
Anthony Foiani t...@scrye.com writes:
Is there any particular reason that you're not taking advantage of the
many person-years of effort that have been put into tools that do
exactly this?
It's been pointed out to me that Khem very much knows of crosstool and
its ilk, being a committer of some
On Tue, Jul 19, 2011 at 2:56 PM, Cheng Renquan crq...@gmail.com wrote:
Hi all,
From info gcc I know it accepts a series of `.FIELDNAME' and `[INDEX]'
designators,
like
struct point ptarray[10] = { [2].y = yv2, [2].x = xv2, [0].x = xv0 };
But in my case, I have a struct with array of
Quoting Richard Henderson r...@redhat.com:
Presumably your target does have at least long unconditional branches,
since otherwise one runs into a register allocation problem. If in
addition you've long unconditional branches as well as no
exception_receiver pattern, then it seems like you
On 19 July 2011 23:57, Cheng Renquan wrote:
On Tue, Jul 19, 2011 at 2:56 PM, Cheng Renquan crq...@gmail.com wrote:
Hi all,
From info gcc I know it accepts a series of `.FIELDNAME' and `[INDEX]'
designators,
like
struct point ptarray[10] = { [2].y = yv2, [2].x = xv2, [0].x = xv0 };
On Tue, Jul 19, 2011 at 4:18 PM, Jonathan Wakely jwakely@gmail.com wrote:
This question is more suitable for the gcc-help list, as it is a
question about using gcc not about developing it.
What I insist to discuss here is I think this may be a gcc's bug,
could be fixed in some future day?
On 20 July 2011 00:45, Cheng Renquan wrote:
On Tue, Jul 19, 2011 at 4:18 PM, Jonathan Wakely jwakely@gmail.com
wrote:
This question is more suitable for the gcc-help list, as it is a
question about using gcc not about developing it.
What I insist to discuss here is I think this may be a
On Tue, Jul 19, 2011 at 11:33 AM, Ian Lance Taylor i...@google.com wrote:
Ian Lance Taylor i...@google.com writes:
I would like to propose this patch as a step toward building gcc using a
C++ compiler. This patch builds stage1 with the C compiler as usual,
and defaults to building stages 2
On Tue, Jul 19, 2011 at 5:26 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Tue, Jul 19, 2011 at 11:33 AM, Ian Lance Taylor i...@google.com wrote:
Ian Lance Taylor i...@google.com writes:
I would like to propose this patch as a step toward building gcc using a
C++ compiler. This patch builds
of a separate problem with the infrastructure at IBM,
but I receive the following error during the first build of libstdc++:
In file included from /farm/dje/src/src/libstdc++-v3/src/debug.cc:30:0:
/tmp/20110719/powerpc-ibm-aix5.3.0.0/libstdc++-v3/include/debug/safe_local_iterator.h:91:50:
error: 'size_t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49771
--- Comment #6 from irar at gcc dot gnu.org 2011-07-19 06:25:11 UTC ---
Author: irar
Date: Tue Jul 19 06:25:07 2011
New Revision: 176434
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=176434
Log:
PR tree-optimization/49771
*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49781
--- Comment #1 from Uros Bizjak ubizjak at gmail dot com 2011-07-19 06:45:56
UTC ---
(In reply to comment #0)
Many lea insns can be combined with the load/store insn followed.
No, these are leal insns, they have inherent zero_extend from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49771
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49782
Summary: Missed optimization due to dependency analysis
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49140
--- Comment #10 from Richard Guenther rguenth at gcc dot gnu.org 2011-07-19
08:05:42 UTC ---
Can you attach preprocessed source of the Salsa20 testcase please?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18908
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49736
rsand...@gcc.gnu.org rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49145
rsand...@gcc.gnu.org rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36208
rsand...@gcc.gnu.org rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49783
Summary: GCC must bring ads and adb files after installation
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18908
--- Comment #15 from Richard Guenther rguenth at gcc dot gnu.org 2011-07-19
08:33:23 UTC ---
On x86_64 we have
f3:
.LFB2:
.cfi_startproc
xorb$1, (%rdi)
andb$1, (%rdi)
ret
already, thus only a truncation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43118
rsand...@gcc.gnu.org rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48835
--- Comment #28 from Mikael Pettersson mikpe at it dot uu.se 2011-07-19
09:12:01 UTC ---
Created attachment 24791
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24791
working patch for gcc-4.7-20110709
gcc-4.7-20110709 bootstrapped fine with
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49768
--- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2011-07-19
09:24:31 UTC ---
Author: jakub
Date: Tue Jul 19 09:24:28 2011
New Revision: 176437
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=176437
Log:
PR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49742
rsand...@gcc.gnu.org rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49768
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49768
--- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org 2011-07-19
09:40:05 UTC ---
Author: jakub
Date: Tue Jul 19 09:40:03 2011
New Revision: 176438
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=176438
Log:
PR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49784
Summary: GCC can't resolve a call which formed with using of
typedef and typename operators
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3746
Rainer Orth ro at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11398
Rainer Orth ro at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15065
Rainer Orth ro at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49784
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15174
Rainer Orth ro at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21954
Rainer Orth ro at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39788
Rainer Orth ro at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39951
Rainer Orth ro at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40947
Rainer Orth ro at gcc dot gnu.org changed:
What|Removed |Added
CC||ro at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40947
--- Comment #13 from Rainer Orth ro at gcc dot gnu.org 2011-07-19 12:11:27
UTC ---
One other possible problem: please avoid relative pathnames to configure and
an object directory that is a subdir of the source tree. Better do (say)
mkdir
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44424
Rainer Orth ro at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44476
Rainer Orth ro at gcc dot gnu.org changed:
What|Removed |Added
CC||ro at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44959
Rainer Orth ro at gcc dot gnu.org changed:
What|Removed |Added
CC||ro at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49708
--- Comment #7 from janus at gcc dot gnu.org 2011-07-19 12:39:02 UTC ---
Author: janus
Date: Tue Jul 19 12:38:59 2011
New Revision: 176447
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=176447
Log:
2011-07-19 Janus Weil ja...@gcc.gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45287
Rainer Orth ro at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49742
--- Comment #7 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org
2011-07-19 12:37:06 UTC ---
Author: rsandifo
Date: Tue Jul 19 12:37:03 2011
New Revision: 176446
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=176446
Log:
gcc/
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49039
--- Comment #14 from Jakub Jelinek jakub at gcc dot gnu.org 2011-07-19
12:44:49 UTC ---
Author: jakub
Date: Tue Jul 19 12:44:46 2011
New Revision: 176448
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=176448
Log:
Backport from mainline
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49742
rsand...@gcc.gnu.org rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48973
--- Comment #14 from Jakub Jelinek jakub at gcc dot gnu.org 2011-07-19
12:46:42 UTC ---
Author: jakub
Date: Tue Jul 19 12:46:39 2011
New Revision: 176449
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=176449
Log:
Backport from mainline
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45351
Rainer Orth ro at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49120
--- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2011-07-19
12:48:54 UTC ---
Author: jakub
Date: Tue Jul 19 12:48:50 2011
New Revision: 176450
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=176450
Log:
Backport from mainline
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49161
--- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2011-07-19
12:51:31 UTC ---
Author: jakub
Date: Tue Jul 19 12:51:29 2011
New Revision: 176451
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=176451
Log:
Backport from mainline
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49165
--- Comment #17 from Jakub Jelinek jakub at gcc dot gnu.org 2011-07-19
12:54:37 UTC ---
Author: jakub
Date: Tue Jul 19 12:54:34 2011
New Revision: 176452
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=176452
Log:
Backport from mainline
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49165
--- Comment #18 from Jakub Jelinek jakub at gcc dot gnu.org 2011-07-19
12:56:50 UTC ---
Author: jakub
Date: Tue Jul 19 12:56:48 2011
New Revision: 176453
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=176453
Log:
Backport from mainline
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49619
--- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org 2011-07-19
12:58:57 UTC ---
Author: jakub
Date: Tue Jul 19 12:58:54 2011
New Revision: 176454
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=176454
Log:
Backport from mainline
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32811
Christian Häggström gcc at kalvdans dot no-ip.org changed:
What|Removed |Added
CC||gcc at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32811
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49640
--- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2011-07-19
13:06:04 UTC ---
Author: jakub
Date: Tue Jul 19 13:06:00 2011
New Revision: 176455
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=176455
Log:
Backport from mainline
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49781
--- Comment #2 from H.J. Lu hjl.tools at gmail dot com 2011-07-19 13:06:19
UTC ---
(In reply to comment #1)
(In reply to comment #0)
Many lea insns can be combined with the load/store insn followed.
No, these are leal insns, they have
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49644
--- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org 2011-07-19
13:07:27 UTC ---
Author: jakub
Date: Tue Jul 19 13:07:23 2011
New Revision: 176456
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=176456
Log:
Backport from mainline
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49644
--- Comment #13 from Jakub Jelinek jakub at gcc dot gnu.org 2011-07-19
13:08:36 UTC ---
Author: jakub
Date: Tue Jul 19 13:08:33 2011
New Revision: 176457
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=176457
Log:
Backport from mainline
1 - 100 of 243 matches
Mail list logo
