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
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
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
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
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 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[
"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
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
> 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
> 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 -
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
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
>
>
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 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
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
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, 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
>> 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, 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
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 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
"Joseph S. Myers" writes:
> It has been proposed (and not rejected, but not yet implemented)
I'm still working on it...
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
>
>
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
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
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
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
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
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
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
>
>
> 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.
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
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
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,
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
35 matches
Mail list logo
