>In a message dated 7/7/2007 4:04:01 A.M. Pacific Daylight Time, Rob1weld
writes:
>This page http://deputy.cs.berkeley.edu/ has a link to this document
http://hal.cs.berkeley.edu/cil/
>which describes a means to obtain three-address code here
http://hal.cs.berkeley.edu/cil/ext.html#toc24 .
> Since we have no reason to believe that the backend should not
> create new pseudo-registers before register allocation, and since we
> have no reason to believe that after register allocation starts it
> will be possible for the backend to create new pseudo-registers, I
> believe that you are in
On Jul 9, 2007, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> Alexandre Oliva <[EMAIL PROTECTED]> writes:
>> On Jul 8, 2007, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
>>
>> > But since these aspects of the register allocator are not at all
>> > likely to change, wouldn't it be a waste of time
> Now, it is true that the overspecification of the comment above its
> declaration may have led people to use it for different purposes.
> While some may have used it to test whether new pseudos can be
> created, others may have used it to test whether we're on or past life
> analysis. Whether th
Hi,
On Fri, 6 Jul 2007, Richard Guenther wrote:
> Btw, is there a bug-report about the issue you are facing? Please
> let's take this issue there.
There's now (32698), I kinda hoped it would be easier to fix. :)
bye, Roman
Richard Kenner wrote:
>> Now, it is true that the overspecification of the comment above its
>> declaration may have led people to use it for different purposes.
>> While some may have used it to test whether new pseudos can be
>> created, others may have used it to test whether we're on or past li
> just as a small point, at least the ppc does behave differently with my
> patch then without it. Apparently there areplaces, at least in the ppc
> backend that did not generate pseudos before reload because of the
> abstraction that are now able to generate them.
I'm sure that's true.
Richard Kenner wrote:
>> just as a small point, at least the ppc does behave differently with my
>> patch then without it. Apparently there areplaces, at least in the ppc
>> backend that did not generate pseudos before reload because of the
>> abstraction that are now able to generate them.
>>
On Jul 9, 2007, Kenneth Zadeck <[EMAIL PROTECTED]> wrote:
> Apparently there areplaces, at least in the ppc backend that did not
> generate pseudos before reload because of the abstraction that are
> now able to generate them.
I don't understand what you mean by 'because of the abstraction'.
It
On 7/9/07, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
It's true that, before your patch, one couldn't create new pseudos
after flow analysis, and after your patch, one can create them all the
way until reload. 'no_new_pseudos' would still mean the same: it's
true if it's too late to create new
I am going to argue that it was a bug that we did not allow new
pseudos after flow had ran. And that we should have always allowed
pseudos before the register allocator. Since flow was so broken, we
could not, we added the hack no_new_pseudos get around that problem.
Now we are saying it is a
Paolo Bonzini <[EMAIL PROTECTED]> writes:
> > I am going to argue that it was a bug that we did not allow new
> > pseudos after flow had ran. And that we should have always allowed
> > pseudos before the register allocator. Since flow was so broken, we
> > could not, we added the hack no_new_pse
This discussion has gotten far too abstract for me.
Alexandre, please write your own patch, and we will approve it or not.
Or tell us how you think my patch should be changed.
Give us code, not discussion. I have already spent more time writing
e-mail messages than I've spent writing the patch.
On Mon, 2007-07-09 at 09:30 -0700, Ian Lance Taylor wrote:
> Paolo Bonzini <[EMAIL PROTECTED]> writes:
>
> > > I am going to argue that it was a bug that we did not allow new
> > > pseudos after flow had ran. And that we should have always allowed
> > > pseudos before the register allocator. Sin
On Jul 9, 2007, "Andrew Pinski" <[EMAIL PROTECTED]> wrote:
> Since flow was so broken, we
> could not, we added the hack no_new_pseudos get around that problem.
> Now we are saying it is a nice abstraction but I am saying this
> abstraction should never have happened in the first place.
You're c
On Jul 9, 2007, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> Or tell us how you think my patch should be changed.
#define no_new_pseudos (reload_in_progress || reload_completed)
if you want to reword it into a functional macro without a negative,
then it would take modifying back-ends as well.
Hello,
I'm at my wits end. I'm building a C++ application for an embedded
device, but I'm having trouble catching exceptions within the embedded
environment. The exact same code works fine on my regular desktop
environment, with the same version of GCC (4.1.2).
I've been able to boil this down to
Joshua ChaitinPollak wrote:
Hello,
I'm at my wits end. I'm building a C++ application for an embedded
device, but I'm having trouble catching exceptions within the embedded
environment. The exact same code works fine on my regular desktop
environment, with the same version of GCC (4.1.2).
I've
> I am going to argue that it was a bug that we did not allow new pseudos
> after flow had ran. And that we should have always allowed pseudos
> before the register allocator. Since flow was so broken, we could not,
> we added the hack no_new_pseudos get around that problem. Now we are
> saying
> The bad abstraction was causing quirks in *when* no_new_pseudos was set
> to 1. But no_new_pseudos is a good abstraction in itself, people are
> arguing on whether it is a better abstraction as "reload_in_progress ||
> reload_completed".
I argue that because both have historically been misused,
On Jul 9, 2007, at 1:43 PM, David Daney wrote:
You don't say what version of uclibc you are using.
The last time I checked, exception handling on uClibc was foobar.
I am not sure if it is true for the versions you are using. There
may be patches floating around that make things work (I kn
> Note that I spent less time writing this patch than I did replying to
> the e-mail messages on this thread.
You're probably going to hit the roof :-) but could you rename the predicate
to can_create_pseudo_p? "may" is somewhat ambiguous for non-native speakers.
--
Eric Botcazou
Joshua ChaitinPollak wrote:
On Jul 9, 2007, at 1:43 PM, David Daney wrote:
You don't say what version of uclibc you are using.
The last time I checked, exception handling on uClibc was foobar. I
am not sure if it is true for the versions you are using. There may
be patches floating around
> We've moved past that option, now we're arguing about using
> regalloc_started_p ().
I'm against that. Why are we hardwiring that as the point at which no new
pseudos can be created? It seems right for now, but suppose we later have
some mechanism for doing regalloc "on the fly"?
If you want
On Jul 9, 2007, at 11:04 AM, Ian Lance Taylor wrote:
OK, what do you think of this patch?
In hopes of ending this thread, I like this color of red... :-)
On 09 July 2007 19:24, Eric Botcazou wrote:
>> Note that I spent less time writing this patch than I did replying to
>> the e-mail messages on this thread.
>
> You're probably going to hit the roof :-) but could you rename the predicate
> to can_create_pseudo_p? "may" is somewhat ambiguous for n
On Jul 9, 2007, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> Alexandre Oliva <[EMAIL PROTECTED]> writes:
>> On Jul 9, 2007, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
>>
>> > Or tell us how you think my patch should be changed.
>>
>> #define no_new_pseudos (reload_in_progress || reload_compl
Eric Botcazou <[EMAIL PROTECTED]> writes:
> > Note that I spent less time writing this patch than I did replying to
> > the e-mail messages on this thread.
>
> You're probably going to hit the roof :-) but could you rename the predicate
> to can_create_pseudo_p? "may" is somewhat ambiguous for
Ian Lance Taylor wrote:
> Eric Botcazou <[EMAIL PROTECTED]> writes:
>
>
>>> Note that I spent less time writing this patch than I did replying to
>>> the e-mail messages on this thread.
>>>
>> You're probably going to hit the roof :-) but could you rename the predicate
>> to can_create_p
Am I the only one who completely fails to see the point of the
spelling change? I realize that you have said you find negative
predicates confusing - I don't, but I do find changing predicates
confusing. I applaud cleaning up the definition and/or replacing it
with a macro, and I'd applaud adding
> Am I the only one who completely fails to see the point of the
> spelling change? I realize that you have said you find negative
> predicates confusing - I don't, but I do find changing predicates
> confusing. I applaud cleaning up the definition and/or replacing it
> with a macro, and I'd appl
Daniel Jacobowitz wrote:
Am I the only one who completely fails to see the point of the
spelling change? I realize that you have said you find negative
predicates confusing - I don't, but I do find changing predicates
confusing. I applaud cleaning up the definition and/or replacing it
with a ma
Alexandre Oliva <[EMAIL PROTECTED]> writes:
> > Note that I spent less time writing this patch than I did replying to
> > the e-mail messages on this thread.
>
> Yes, it's frustrating, but my experience has been that getting
> consensus is generally much more difficult than implementing an
> agre
On Mon, Jul 09, 2007 at 02:54:49PM -0400, Richard Kenner wrote:
> > Am I the only one who completely fails to see the point of the
> > spelling change? I realize that you have said you find negative
> > predicates confusing - I don't, but I do find changing predicates
> > confusing. I applaud cle
Kenneth Zadeck <[EMAIL PROTECTED]> writes:
> Ian Lance Taylor wrote:
> > Eric Botcazou <[EMAIL PROTECTED]> writes:
> >
> >
> >>> Note that I spent less time writing this patch than I did replying to
> >>> the e-mail messages on this thread.
> >>>
> >> You're probably going to hit the roo
> Shouldn't we see this as a teachable moment for correct English
> grammar?
That would be overloading the predicate. :-)
More seriously:
[EMAIL PROTECTED]:~/svn/gcc/gcc> grep "^may_" *.c
fold-const.c:may_negate_without_overflow_p (tree t)
haifa-sched.c:may_trap_exp (rtx x, int is_store)
loop-in
On Mon, Jul 09, 2007 at 11:54:39AM -0700, Ian Lance Taylor wrote:
> Kenneth Zadeck <[EMAIL PROTECTED]> writes:
>
> > Ian Lance Taylor wrote:
> > > Eric Botcazou <[EMAIL PROTECTED]> writes:
> > >
> > >
> > >>> Note that I spent less time writing this patch than I did replying to
> > >>> the e-ma
On Jul 9, 2007, at 2:22 PM, David Daney wrote:
Joshua ChaitinPollak wrote:
On Jul 9, 2007, at 1:43 PM, David Daney wrote:
You don't say what version of uclibc you are using.
The last time I checked, exception handling on uClibc was
foobar. I am not sure if it is true for the versions you a
Hi!
On the AMD64 / x86-64Bit architecture, some arguments of a functions
are passed using registers, but there seem to be two different
conventions out there. The standard ABI uses 6 registers, but
Microsoft compilers use only 4. Because of that, code compiled with
gcc cannot call code co
On Mon, Jul 09, 2007 at 12:48:10PM -0700, Nicolas Alt wrote:
> Hi!
>
> On the AMD64 / x86-64Bit architecture, some arguments of a functions
> are passed using registers, but there seem to be two different
> conventions out there. The standard ABI uses 6 registers, but
> Microsoft compilers u
On 09 July 2007 20:48, Nicolas Alt wrote:
> Hi!
>
> On the AMD64 / x86-64Bit architecture, some arguments of a functions
> are passed using registers, but there seem to be two different
> conventions out there. The standard ABI uses 6 registers, but
> Microsoft compilers use only 4. Because of th
Thanks for your reply. The gcc compiler uses %rdi, %rsi, %rdx, %rcx
with -mregparm=4, but MS uses %rcx, %rdx, %r8, %r9, so that won't be
enough. Also MS requires some space on the stack to be reserved for
the 4 regs.
Someone has written a wrapper:
http://people.freebsd.org/~wpaul/winx64_wra
Yea, __attribute__ should be the way to go - however, I have not
found any attribute like msabi or so. It still needs to be
implemented in the compiler. Most of the ia32 attributes are ignored
anyway.
On Jul 9, 2007, at 12:55 , H.J. Lu wrote:
On Mon, Jul 09, 2007 at 12:48:10PM -0700, Nico
Eric Botcazou <[EMAIL PROTECTED]> writes:
> tree-ssa-loop-im.c:may_move_till (tree ref, tree *index, void *data)
> tree-ssa-loop-prefetch.c:may_use_storent_in_loop_p (struct loop *loop)
So there are some existing cases of asking permission using "may".
Joe Buck <[EMAIL PROTECTED]> writes:
> "Ma
Eric Botcazou <[EMAIL PROTECTED]> writes:
> tree-ssa-loop-im.c:may_move_till (tree ref, tree *index, void *data)
> tree-ssa-loop-prefetch.c:may_use_storent_in_loop_p (struct loop *loop)
So there are some existing cases of asking permission using "may".
Joe Buck <[EMAIL PROTECTED]> writes:
> "Ma
"Joe can open the door during the meeting" could mean "Joe is able to
open the door (e.g., he has the keys)" or "from time to time, Joe will
open the door during the meeting (e.g., it has been known to happen)."
But I agree that it doesn't seem to be used that way in gcc.
And in compilers in
On 7/9/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>In a message dated 7/7/2007 4:04:01 A.M. Pacific Daylight Time, Rob1weld
writes:
>This page http://deputy.cs.berkeley.edu/ has a link to this document
http://hal.cs.berkeley.edu/cil/
>which describes a means to obtain three-address code
Peace be unto you my good friend. I am the only surviving child of the Abdullah
Öcalan.The leader of the Kurdistan Workers Party (PKK).My father actively
fought for the liberation and unification of our people (The Kurds) under one
sovereign nation which earned him the support of many and bein
Peace be unto you my good friend. I am the only surviving child of the Abdullah
Öcalan.The leader of the Kurdistan Workers Party (PKK).My father actively
fought for the liberation and unification of our people (The Kurds) under one
sovereign nation which earned him the support of many and being
Bernd Schmidt <[EMAIL PROTECTED]> writes:
> Daniel Jacobowitz wrote:
> > Am I the only one who completely fails to see the point of the
> > spelling change? I realize that you have said you find negative
> > predicates confusing - I don't, but I do find changing predicates
> > confusing. I appla
On Mon, Jul 09, 2007 at 05:26:00PM -0400, Paolo Bonzini wrote:
>
> >"Joe can open the door during the meeting" could mean "Joe is able to
> >open the door (e.g., he has the keys)" or "from time to time, Joe will
> >open the door during the meeting (e.g., it has been known to happen)."
> >
> >But I
Gregory B. Prokopski wrote:
I reorder the basic blocks in passes.c, right after compute_alignmnets ().
I added a call to shorten_branches(NULL_RTX) right after my BB reordering,
but it didn't change a thing, and I am still getting as errors:
shorten_branches does this:
/* Compute initial leng
Snapshot gcc-4.1-20070709 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20070709/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.1 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Ying Yi wrote:
The generated codes do the following operations: 1) extend variable a_HI
(HImode) to temp variable SImode, and do abs operation with SImode
operators. I find the gimple intermedia represention as shown below:
abs is a standard library function that takes an int as an argument.
54 matches
Mail list logo
