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.
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
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
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
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
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
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
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
"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
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
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
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
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
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
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 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
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
> 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
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
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
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
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
> 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
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
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
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
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
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, 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... :-)
> 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
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
> 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
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
> 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,
> 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
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
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
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.
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 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
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.
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
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
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
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
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.
>>
> 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:
>> 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
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
> 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
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
> 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
>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 .
54 matches
Mail list logo
