* Jack Howarth wrote on Sat, Jul 16, 2011 at 10:40:22PM CEST:
>I have had a report of i386 darwin10 failing to build gcc 4.4.6 in fink
> which I've reproduced
> myself. The failure looks quite odd...
>
> /usr/bin/install -c -m 644 ./libiberty.a
> /sw/src/fink.build/root-gcc44-4.4.6-1001/sw/l
On Tue, Jul 19, 2011 at 5:04 PM, Jonathan Wakely wrote:
> This isn't the right list for that either. Questions about using gcc
> should go to gcc-help, bug reports should go to bugzilla.
I know how to use current gcc implementation correctly, I'm thinking
of a new feature in future gcc version,
e 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: &
On Tue, Jul 19, 2011 at 5:26 PM, H.J. Lu wrote:
> On Tue, Jul 19, 2011 at 11:33 AM, Ian Lance Taylor wrote:
>> Ian Lance Taylor 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,
>>> an
On Tue, Jul 19, 2011 at 11:33 AM, Ian Lance Taylor wrote:
> Ian Lance Taylor 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++ compile
On 20 July 2011 00:45, Cheng Renquan wrote:
> On Tue, Jul 19, 2011 at 4:18 PM, Jonathan Wakely
> 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,
T
On Tue, Jul 19, 2011 at 4:18 PM, Jonathan Wakely 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?
>
> What you want is
On 19 July 2011 23:57, Cheng Renquan wrote:
> On Tue, Jul 19, 2011 at 2:56 PM, Cheng Renquan 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 };
>>
>>
Quoting Richard Henderson :
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 could completely do
On Tue, Jul 19, 2011 at 2:56 PM, Cheng Renquan 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 int as
Anthony Foiani 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 standing.
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 registe
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
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
> e
Quoting Richard Henderson :
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 working size set sav
On Tue, Jul 19, 2011 at 1:33 PM, Ian Lance Taylor wrote:
> Ian Lance Taylor writes:
> I got agreement from two global reviewers and no objections.
>
> I have committed this patch.
Great!
-- Gaby
Ian Lance Taylor 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 done this, to
(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, game
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: pa
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/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,
> pa
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 transfo
Ian Lance Taylor 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 installed and
Khem Raj 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 that have been
Georg-Johann Lay 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 plugins
add
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
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 (mig
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 co
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.
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 regi
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 regist
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
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 ar
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 p
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, p
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 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
-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
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 op
> 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 instructi
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:S
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 wrote:
> From: Vladimir Makarov
> Subject: Re: Does IRA support spilling to registers instead of stack?
> To: dpadgett_mail-...@y
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
th
On Tue, Jul 19, 2011 at 00:09, Gabriel Charette 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
> files (as op
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 handli
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 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 n
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 codes,
On 18/07/11 17:58, Ian Lance Taylor wrote:
Look at add3_cc in gcc/config/i386/i386.md. Look at how
add3_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 look for ho
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 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 loo
On Mon, Jul 18, 2011 at 8:10 PM, Khem Raj wrote:
> On Mon, Jul 18, 2011 at 4:58 AM, Rohit Arul Raj
> 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"..
nux-gnu/tools/lib/gcc/powerpc-
52 matches
Mail list logo
