Hi,
I have already finished CPU port named RICE. The previous version
I did is on gcc 4.0.2. it can be compiled. Now I wanna move it to
v4.3.0. I added the config script just as the CRX architechture.
But when run the configure,
export TARGET=rice-elf
export PREFIX=/usr/local/cross/$TARGE
daniel tian wrote:
> /home/daniel.tian/gcc_rice_dev/rice-binutils/build-gcc-debug/./gcc/xgcc
> -B/home/daniel.tian/gcc_rice_dev/rice-binutils/build-gcc-debug/./gcc/
> -B/usr/local/cross/rice-elf/rice-elf/bin/
> -B/usr/local/cross/rice-elf/rice-elf/lib/ -isystem
> /usr/local/cross/rice-elf/rice-elf
Hi All,
Our project is to optimize instruction scheduling in gcc. It
requires us to specify architecture information
(basically number of cycles per instruction, stall and branch delays)
to gcc, to optimize structural hazard detection.
Problem: Is there any specific format in which we ca
The bug:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40092
has been around for a while (since May). A patch was
submitted in a gcc-patches post about 1 month ago:
http://gcc.gnu.org/ml/gcc-patches/2009-08/msg01217.html
; yet, no one has even confirmed that it's a bug.
Would someone mind d
>
> You've got to get in there with gdb and find out why
> compute_frame_pointer_to_fb_displacement()
> is erroring. There's no way to avoid this.
>
Thank you.
But I don't know how. I mean which execute file, even I can't find the
"conftest.c" file.
Sorry for asking this simple question.
You should check how to construct DFA for your target architecture.
Look at "Specifying processor pipeline description" in GCC internal
manual and checked out how other architectures do it.
-Bingfeng
> -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On
>
Hi ,
Follow this wiki " http://gcc.gnu.org/wiki/DebuggingGCC"; to know
how to debug gcc.
As far as I know compute_frame_pointer_to_fb_displacement is the
displacement between your
frame pointer and the frame base ( mostly stack pointer's location
after your prologue code - depend
2009/9/21 sumanth :
> Hi ,
> Follow this wiki " http://gcc.gnu.org/wiki/DebuggingGCC"; to know how to
> debug gcc.
> As far as I know compute_frame_pointer_to_fb_displacement is the
> displacement between your
> frame pointer and the frame base ( mostly stack pointer's location after
> yo
daniel tian wrote:
> 2009/9/21 sumanth :
>> Hi ,
>>Follow this wiki " http://gcc.gnu.org/wiki/DebuggingGCC"; to know how to
>> debug gcc.
>>As far as I know compute_frame_pointer_to_fb_displacement is the
>> displacement between your
>> frame pointer and the frame base ( mostly stack po
I am pleased to announce that the GCC Steering Committee has
accepted the Lattice Mico32 port for inclusion in GCC. The initial
patch needs approval from a GCC GWP maintainer before it may be committed.
Happy hacking!
David
2009/9/21 Andrew Haley :
> daniel tian wrote:
>> 2009/9/21 sumanth :
>>> Hi ,
>>> Follow this wiki " http://gcc.gnu.org/wiki/DebuggingGCC"; to know how to
>>> debug gcc.
>>> As far as I know compute_frame_pointer_to_fb_displacement is the
>>> displacement between your
>>> frame pointer an
Hi Alexandre,
I was having some trouble with dwarf sections in picochip port. I am not
a dwarf expert, but when i looked at the changes in r151312, file
dwarf2out.c, function dwarf2out_var_location on line 17965, we have
sprintf (loclabel, "%s-1", last_label);
...
What is la
On Mon, Sep 21, 2009 at 05:04:27PM +0100, Hariharan wrote:
> Hi Alexandre,
> I was having some trouble with dwarf sections in picochip port. I am not
> a dwarf expert, but when i loo...@the changes in r151312, file
> dwarf2out.c, function dwarf2out_var_location on line 17965, we have
>
>
"Joseph S. Myers" writes:
> It has been proposed (and not rejected, but not yet implemented)
I'm still working on it...
On 09/14/2009 11:54 AM, Jason Merrill wrote:
I think the way to go with this is to revert the compiler bits of
r149964, not mess with mangle.c at all, and insert the initial * if the
typeinfo name won't have TREE_PUBLIC set, since that's precisely the
property we want to mirror in comparison.
T
What version of GCC will build for a cross --target=armv4t-linux-eabi,
which I believe is the right code for an ixp425 processor? The host
compiler is gcc-4.3.3 on a Linux-debian-test system. I have also tried
unsuccessfully tried the armv5t target, with similar results.
I have tried numerous ver
On Mon, Sep 21, 2009 at 11:54:17AM -0600, Kevin Handy wrote:
> What version of GCC will build for a cross --target=armv4t-linux-eabi,
> which I believe is the right code for an ixp425 processor? The host
> compiler is gcc-4.3.3 on a Linux-debian-test system. I have also tried
> unsuccessfully tried
>> So aren't we now likely to lose the first few days of what little remains
>> of
>> stage 1 waiting for trunk to start working again, then have a mad rush of
>> people falling all over each other to get their new features in in the last
>> couple of days? One of which will inevitably break tr
On Mon, 2009-09-21 at 13:06 -0400, Jason Merrill wrote:
> On 09/14/2009 11:54 AM, Jason Merrill wrote:
> > I think the way to go with this is to revert the compiler bits of
> > r149964, not mess with mangle.c at all, and insert the initial * if the
> > typeinfo name won't have TREE_PUBLIC set, sinc
daniel tian writes:
>I have already finished CPU port named RICE. The previous version
> I did is on gcc 4.0.2. it can be compiled. Now I wanna move it to
> v4.3.0. I added the config script just as the CRX architechture.
> configure:2379: $? = 1
> configure:2398:
> /home/daniel.tian/gcc_
On Mon, Sep 21, 2009 at 11:23:11AM -0700, Cary Coutant wrote:
> >> So aren't we now likely to lose the first few days of what little
> >> remains of
> >> stage 1 waiting for trunk to start working again, then have a mad rush of
> >> people falling all over each other to get their new features in
On 09/21/2009 02:43 PM, Jerry Quinn wrote:
Another approach could be to use 2 different names for anonymous
namespaces that should and should not be compared by pointer. I don't
like the speed implications, but it might work.
Any type that involves the anonymous namespace should be compared by
It turns out that IRIX and OSF have not managed to keep Rainer Orth
sufficiently busy after I sent
http://gcc.gnu.org/ml/gcc/2006-07/msg00654.html
so I am pleased to announce that the steering committee is appointing
him maintainer for our Solaris ports as well. :-)
Please update MAINTAINERS
On Mon, Sep 21, 2009 at 05:04:27PM +0100, Hariharan wrote:
> Hi Alexandre,
> I was having some trouble with dwarf sections in picochip port. I am not
> a dwarf expert, but when i looked at the changes in r151312, file
> dwarf2out.c, function dwarf2out_var_location on line 17965, we have
>
>
Hi,
What is the proper type to use in an Ada binding
for a C method that returns a C99 bool?
This appears to be an issue in s-stchop-rtems.adb
where it binds to the C routine:
bool rtems_stack_checker_is_blown( void )
Thanks.
--
Joel Sherrill, Ph.D. Director of Research & Developm
> Are you saying that current gcc trunk should require -gdwarf-4
> to issue dwarf4 commands? I ask because r151815...
>
> http://gcc.gnu.org/ml/gcc-patches/2009-09/msg00220.html
>
> causes dwarf4 by default. Is there a consistent policy on this?
> Currently in PR41405, there is a proposal for a -
> extensibility, this isn't a problem for these extensions, as older
> DWARF readers will simply ignore the location expressions that use the
> extensions -- which produces the same behavior as DWARF-2 without
> those extensions.
I said "will simply ignore" when I guess I should have said "should
Florian Weimer writes:
> G++ currently accepts the following code:
>
> char *
> alloc(unsigned a, unsigned b)
> {
> typedef char array[a];
> return &**(new array[b]);
> }
>
> Is this intentional? The equivalent "new char[a][b]" is rejected (as
> required by the C++ standard).
Is there any r
"Amker.Cheng" writes:
>In function new_ready, it calls to min_insn_conflict_delay with
> "min_insn_conflict_delay (curr_state, next, next)".
> But the function's comments say that it returns minimal delay of issue of
> the 2nd insn after issuing the 1st in given state.
> Why the last two para
On Mon, Sep 21, 2009 at 4:56 PM, Ian Lance Taylor wrote:
> Florian Weimer writes:
>
>> G++ currently accepts the following code:
>>
>> char *
>> alloc(unsigned a, unsigned b)
>> {
>> typedef char array[a];
>> return &**(new array[b]);
>> }
>>
>> Is this intentional? The equivalent "new char[
Thanks for the pointer, Jakub.
Cheers
Hari
Jakub Jelinek wrote:
On Mon, Sep 21, 2009 at 05:04:27PM +0100, Hariharan wrote:
Hi Alexandre,
I was having some trouble with dwarf sections in picochip port. I am not
a dwarf expert, but when i looked at the changes in r151312, file
dwarf2out.c
On Sun, Sep 20, 2009 at 01:49:39PM -0400, Andrew Hutchinson wrote:
All,
I have been debugging AVR port to see why we fail to match so many bit
test opportunities.
When dealing with longer modes I have come across a problem I can not solve.
Expansion in RTL for a bit test can produce two styles
Thank you so much for your information!
I will investigate your patch.
(I just hacked lowpart_for_combine to allow lowering something larger
than word and the subreg matched no problem.)
It looks like RTL generation is somewhat odd and not helping.
My test used
extern long x;
if (x & 1)
I
Why doesn't combine try matching "unsimplified" expressions when it fails?
This would at least permit creating patterns based on explicit format
of input RTL without the added vagaries of simplification
Andy
Joern Rennecke wrote:
On Sun, Sep 20, 2009 at 01:49:39PM -0400, Andrew Hutchinson
Quoting Andrew Hutchinson :
Why doesn't combine try matching "unsimplified" expressions when it fails?
This would at least permit creating patterns based on explicit format
of input RTL without the added vagaries of simplification
Actually, that was my first attempt to approach the issue, bu
35 matches
Mail list logo
