Hello Rask,
On Wednesday 19 July 2006 13:24, Rask Ingemann Lambertsen wrote:
> I've spotted a function named emit_set_insn() in arm.c. It might be
> the problem, because it uses gen_rtx_SET() directly.
But it's not the only function which uses gen_rtx_SET. There are also
much places with
> e
On Jul 19, 2006, at 3:08 AM, jacob navia wrote:
This is just to tell you that now it is working.
Yeah. Glad to hear it, and thanks for the update.
Hi Zdenek,
I can't seem to reproduce this on 4.1.x with any other port. Maybe I need a sync
up with the latest svn of 4.1.x . I'll try looking at 4.2 head also to spot
differences if any.
Thanks for your time
cheers
Ramana
Ramana Radhakrishnan
GNU Tools
Celunite Inc
On Wed Jul 19 8:09 , Zde
Hello,
> I am upgrading a port from 3.4.5 to 4.1.x .In course of this I see some
> regressions in terms of performance in memcpy . I have narrowed down the test
> case to the function below.
>
> ivopts generates ivtmps for each of the address calculations as shown in the
> attached log inste
On Wed, Jul 19, 2006 at 02:12:09PM +0100, Saajan Singh Chana wrote:
> I have defined GO_IF_LEGITIMATE_ADDRESS() to only accept indexed
> addresses where the index is HImode,
I was trying to get you to copy and paste your definition og
GO_IF_LEGITIMATE_ADDRESS() into your message. :-)
> and then
On Wed, Jul 19, 2006 at 02:49:18PM +0100, Abid Ghufran wrote:
> I am using thread in my application.
>
> When i try to compile the code, the gcc says that the "pthread_create"
> is an undefined reference. I have included the library pthread.h. Is
> there something else that i need to do.
>
> What
I am using thread in my application.
When i try to compile the code, the gcc says that the "pthread_create"
is an undefined reference. I have included the library pthread.h. Is
there something else that i need to do.
What options do I have to use when compiling my code?
Is there any document on
Rask Ingemann Lambertsen wrote:
You are not making it easy to help you. Please tell us what makes you
conclude that it isn't working reliably (error messages, code which is
slower and/or larger than expected, etc) and how you tried to make it work,
such as: Your definition of GO_IF_LEGITIMATE_AD
On Wed, Jul 19, 2006 at 01:24:59PM +0200, Rask Ingemann Lambertsen wrote:
>
> The function named emit_move_insn() ought to do the trick here, but
> is perhaps a bit heavyweight for this purpose. Anyway, try this patch
> (untested), which should plug this particular hole:
There was an unbalanced p
On Fri, Jun 23, 2006 at 03:23:04PM -0400, Andrew MacLeod wrote:
> A new register allocator written from scratch is a very long term
> project (measured in years), and there is no guarantee after all that
> work that we'd end up with something which is remarkably better. One
> would hope that it is
> The attached patch moves the basic installation of the compiler
> drivers from gcc/*/Make-lang.in to gcc/Makefile.in. The Make-lang.in
> has only to inform the driver's name.
What about Ada ? Will things still work after your change ?
It would seem cleaner (if not mandatory) to take all language
On Wed, Jul 19, 2006 at 09:44:12AM +0100, [EMAIL PROTECTED] wrote:
> We are trying to write a new backend for GCC. The target machine is
> 16-bit, with 24-bit pointers. However, the indexed addressing mode has a
> 24-bit base and a 16-bit index, so we want to generate RTXs such as
>
> (mem:QI (
On Wed, Jul 19, 2006 at 07:52:32AM +0200, Wolfgang Mües wrote:
> Hello,
>
> after getting a "working" version of the gcc 4.0.2 with the Nintendo
> 8-bit-write problem, I was busy the last weeks trying to adapt the
> linux system (replacing I/O with writeb() macros, removing strb
> assembler cal
Hi,
I am upgrading a port from 3.4.5 to 4.1.x .In course of this I see some
regressions in terms of performance in memcpy . I have narrowed down the test
case to the function below.
ivopts generates ivtmps for each of the address calculations as shown in the
attached log instead of coalescing the
Andrew Haley a écrit :
jacob navia writes:
> This is just to tell you that now it is working.
>
> I have suceeded in making my JIT generate the right tables for gcc
Excellent.
> As it seems, both gcc 4.1 and gcc 3.3 seem to work OK.
> Can anyone confirm this?
That they work OK? No, you are
jacob navia writes:
> This is just to tell you that now it is working.
>
> I have suceeded in making my JIT generate the right tables for gcc
Excellent.
> As it seems, both gcc 4.1 and gcc 3.3 seem to work OK.
> Can anyone confirm this?
That they work OK? No, you are the only person who h
This is just to tell you that now it is working.
I have suceeded in making my JIT generate the right tables for gcc
As it seems, both gcc 4.1 and gcc 3.3 seem to work OK.
Can anyone confirm this?
There isn't any difference between gcc-3.x and gcc4.x at this
level isn't it?
jacob
Hello,
We are trying to write a new backend for GCC. The target machine is
16-bit, with 24-bit pointers. However, the indexed addressing mode has a
24-bit base and a 16-bit index, so we want to generate RTXs such as
(mem:QI (plus:SI (reg:HI )
(reg:SI )))
(mem:HI (plus:SI (mul
Hello,
We are trying to write a new backend for GCC. The target machine is
16-bit, with 24-bit pointers. However, the indexed addressing mode has a
24-bit base and a 16-bit index, so we want to generate RTXs such as
(mem:QI (plus:SI (reg:HI )
(reg:SI )))
(mem:HI (plus:SI (mul
On 7/19/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Folks,
I'm currently looking at substantively revamping synth_mult(), the gcc
routine for reducing multiplicative constants to shift/add/sub sequences.
My perception here, from experimentation, is that synth_mult() is:
1. slow (deeply re
20 matches
Mail list logo
