On 3/2/07, Andrey Belevantsev <[EMAIL PROTECTED]> wrote:
Steven Bosscher wrote:
> No. The condition you're checking is simply not true in cfglayout
> mode. The whole point of cfglayout mode is to get rid of the
> requirement that basic blocks are serial. That means a fallthru edge
> in cfglayout
The following suggestion is based on my understanding of
--with-sysroot, if there were any error, please correct me.
To my understanding, currently if cross-compile tool chain (including
gcc) is configured with --with-sysroot when installing them, then when
cross compiling, ld will look for librar
Steven Bosscher wrote:
> I don't understand this. You're saying there is a fallthrough edge
> from your e->src to EXIT_BLOCK. This case is explicitly allowed by
> the checking code. It is an exception from the rule: For a fallthrough
> edge to EXIT, e->src->next_bb != e->dest is OK.
Thanks! It'
Hello, recently I am porting the GCC backend to a DSP. The GCC
Internals document says that the unnamed insns are used to translate
RTL insns to the assembler insns, but I find that the unnamed insn
patterns can be used in combine phase to combine insns by reading the
"*arith_shiftsi" insn p
Grigory Zagorodnev wrote on 03/03/07 02:27:
> There are three checkins, candidates for the root of regression:
> http://gcc.gnu.org/viewcvs?view=rev&revision=122487
> http://gcc.gnu.org/viewcvs?view=rev&revision=122484
> http://gcc.gnu.org/viewcvs?view=rev&revision=122479
>
SPEC
> Grigory Zagorodnev wrote on 03/03/07 02:27:
>
> > There are three checkins, candidates for the root of regression:
> > http://gcc.gnu.org/viewcvs?view=rev&revision=122487
> > http://gcc.gnu.org/viewcvs?view=rev&revision=122484
> > http://gcc.gnu.org/viewcvs?view=rev&revision=122479
>
"redriver jiang" <[EMAIL PROTECTED]> writes:
> Hello, recently I am porting the GCC backend to a DSP. The GCC
> Internals document says that the unnamed insns are used to translate
> RTL insns to the assembler insns, but I find that the unnamed insn
> patterns can be used in combine phase t
Grigory Zagorodnev <[EMAIL PROTECTED]> writes:
> Trunk GCC shows massive (2 compile-time and 6 run-time) failures on
> SPEC CPU2000 and CPU2006 at i386 and x86_64 on -O2 optimization
> level. Regression introduced somewhere between revision 122487 and
> 122478.
>
> There are three checkins, candi
On 03 Mar 2007 11:00:11 -0800, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
Grigory Zagorodnev <[EMAIL PROTECTED]> writes:
> Trunk GCC shows massive (2 compile-time and 6 run-time) failures on
> SPEC CPU2000 and CPU2006 at i386 and x86_64 on -O2 optimization
> level. Regression introduced somewhe
Hi all,
I'd like to develop a tool able to do the following things:
1) to load all the .h and .c/.cpp files;
2) to analyze allo the data struct / unions and classes;
3) to give me for each data member of a struct or union and for each data
member of a class, the offset in bytes related to the base
On 03 March 2007 20:15, Fabio Giovagnini wrote:
> Hi all,
> I'd like to develop a tool able to do the following things:
> 1) to load all the .h and .c/.cpp files;
> 2) to analyze allo the data struct / unions and classes;
> 3) to give me for each data member of a struct or union and for each data
Thanks for the answer.
I go deeper in my thought so that maybe you can give me more infos about how I
have to investagte about gcc/gdb
We are developers of embedded software on board designed and build by us;
Generally we use 16 bit cisc and 32 bits risc cpu (Renesas h8/h8s; sh 2 / 3 ).
We write
On 3/3/07, Fabio Giovagnini <[EMAIL PROTECTED]> wrote:
Thanks for the answer.
I go deeper in my thought so that maybe you can give me more infos about how I
have to investagte about gcc/gdb
We are developers of embedded software on board designed and build by us;
Generally we use 16 bit cisc and
I noticed that gcc.dg/tree-ssa/loop-19.c was failing on both
powerpc-linux-gnu and powerpc64-linux-gnu:
FAIL: gcc.dg/tree-ssa/loop-19.c scan-tree-dump-times MEM.(base: &|symbol: )a, 2
FAIL: gcc.dg/tree-ssa/loop-19.c scan-tree-dump-times MEM.(base: &|symbol: )c, 2
The reason why they are failing i
On Sat, Mar 03, 2007 at 11:01:40AM -0500, Diego Novillo wrote:
> Grigory Zagorodnev wrote on 03/03/07 02:27:
>
> > There are three checkins, candidates for the root of regression:
> > http://gcc.gnu.org/viewcvs?view=rev&revision=122487
> > http://gcc.gnu.org/viewcvs?view=rev&revision=12248
On 3/3/07, H. J. Lu <[EMAIL PROTECTED]> wrote:
> [1] 176.gcc and 253.perlbmk usually miscompare for me. Not sure why.
176.gcc=default=default=default:
CPORTABILITY = -Dalloca=_alloca
EXTRA_LDFLAGS =
srcalt=64bitgcc40
For one, the 176.gcc in SPEC 2k has an aliasing violation in it so
that f
Hello,
> I noticed that gcc.dg/tree-ssa/loop-19.c was failing on both
> powerpc-linux-gnu and powerpc64-linux-gnu:
> FAIL: gcc.dg/tree-ssa/loop-19.c scan-tree-dump-times MEM.(base: &|symbol:
> )a, 2
> FAIL: gcc.dg/tree-ssa/loop-19.c scan-tree-dump-times MEM.(base: &|symbol:
> )c, 2
>
> The reas
On Sat, Mar 03, 2007 at 02:00:30PM -0800, Andrew Pinski wrote:
> On 3/3/07, H. J. Lu <[EMAIL PROTECTED]> wrote:
> >> [1] 176.gcc and 253.perlbmk usually miscompare for me. Not sure why.
>
> >176.gcc=default=default=default:
> >CPORTABILITY = -Dalloca=_alloca
> >EXTRA_LDFLAGS =
> >srcalt=64bitgcc
On 3/3/07, Zdenek Dvorak <[EMAIL PROTECTED]> wrote:
Hello,
only gimple_vals (name or invariant). However, the expressions are
matched in final_cleanup dump (after out-of-ssa and ter), so this no
longer is the case. I think just the regular expressions need to be
updated.
Then IV-OPTs has an
Fabio Giovagnini wrote:
Thanks for the answer.
I go deeper in my thought so that maybe you can give me more infos about how I
have to investagte about gcc/gdb
We are developers of embedded software on board designed and build by us;
Generally we use 16 bit cisc and 32 bits risc cpu (Renesas h8
20 matches
Mail list logo
