Re: bootstrap failure while compiling gcc/tree.c (ICE)

On Tue, 28 Aug 2007, Brian Sidebotham wrote: > > 2007-08-26 Kaveh R. Ghazi <[EMAIL PROTECTED]> > > > > * system.h (CONST_CAST): Avoid union for gcc-4.0.x. > > > > diff -rup orig/egcc-SVN20070825/gcc/system.h egcc-SVN20070825/gcc/system.h > > --- orig/egcc-SVN20070825/gcc/system.h 2007-0

Re: question about rtl loop-iv analysis

On 8/28/07, Zdenek Dvorak <[EMAIL PROTECTED]> wrote: ... > that obviously is not the case here, though. Do you (or someone else > responsible for df) have time to have a look at this problem? > Otherwise, we may discuss it forever, but we will not get anywhere. > > Zdenek Open a PR and assign it

Re: question about rtl loop-iv analysis

Hello, > And finally at the stage of rtl unrolling it looks like this: > [6] r186 = r2 + C; > r318 = r186 + 160; > loop: > r186 = r186 + 16 > if (r186 != r318) then goto loop else exit > > Then, in loop-unroll.c we call iv_number_of

Re: question about rtl loop-iv analysis

On Tue, 28 Aug 2007, Kenneth Zadeck wrote: > And finally at the stage of rtl unrolling it looks like this: > [6] r186 = r2 + C; > r318 = r186 + 160; > loop: > r186 = r186 + 16 > if (r186 != r318) then goto loop else exit > > > > > regard

Re: question about rtl loop-iv analysis

Zdenek Dvorak wrote: > Hello, > > And finally at the stage of rtl unrolling it looks like this: [6] r186 = r2 + C; r318 = r186 + 160; loop: r186 = r186 + 16 if (r186 != r318) then goto loop else exit Then, in loop-unroll.c we call

Re: question about rtl loop-iv analysis

Hello, > >> And finally at the stage of rtl unrolling it looks like this: > >> [6] r186 = r2 + C; > >> r318 = r186 + 160; > >> loop: > >> r186 = r186 + 16 > >> if (r186 != r318) then goto loop else exit > >> > >> Then, in loop-unroll.c we call iv_number_of_iterations, whi

Re: question about rtl loop-iv analysis

Zdenek Dvorak wrote: > Hello, > > >> And finally at the stage of rtl unrolling it looks like this: >> [6] r186 = r2 + C; >> r318 = r186 + 160; >> loop: >> r186 = r186 + 16 >> if (r186 != r318) then goto loop else exit >> >> Then, in loop-unroll.c we call iv_number_of_it

Re: question about rtl loop-iv analysis

Hello, > And finally at the stage of rtl unrolling it looks like this: > [6] r186 = r2 + C; > r318 = r186 + 160; > loop: > r186 = r186 + 16 > if (r186 != r318) then goto loop else exit > > Then, in loop-unroll.c we call iv_number_of_iterations, which eventually > calls i

Re: ICE in langhooks.c on SPU

On 8/28/07, Dave Korn <[EMAIL PROTECTED]> wrote: > On 28 August 2007 15:57, Revital1 Eres wrote: > > >> Wow, you mean SPU has more builtins than x86_64? Up the bitfield > >> width of tree.h tree_function_decl.function_code until it no longer ICEs. I checked in a fix. Richard.

RE: ICE in langhooks.c on SPU

On 28 August 2007 15:57, Revital1 Eres wrote: >> Wow, you mean SPU has more builtins than x86_64? Up the bitfield >> width of tree.h tree_function_decl.function_code until it no longer ICEs. >> > > Changing the following indeed solves the problem: > > Index: tree.h > ==

Re: ICE in langhooks.c on SPU

> Wow, you mean SPU has more builtins than x86_64? Up the bitfield > width of tree.h tree_function_decl.function_code until it no longer ICEs. > Changing the following indeed solves the problem: Index: tree.h === --- tree.h (r

Re: ICE in langhooks.c on SPU

[EMAIL PROTECTED] wrote on 28/08/2007 17:31:08: > On 8/28/07, Dave Korn <[EMAIL PROTECTED]> wrote: > > On 28 August 2007 15:10, Richard Guenther wrote: > > > > > > > > Or maybe on ppc/spu enum bitfields are signed and the following > > > > > > DECL_FUNCTION_CODE (decl) = -1; > > > gcc_asser

Re: ICE in langhooks.c on SPU

On 8/28/07, Dave Korn <[EMAIL PROTECTED]> wrote: > On 28 August 2007 15:10, Richard Guenther wrote: > > > > > Or maybe on ppc/spu enum bitfields are signed and the following > > > > DECL_FUNCTION_CODE (decl) = -1; > > gcc_assert (DECL_FUNCTION_CODE (decl) >= function_code); > > > > doesnt work

RE: ICE in langhooks.c on SPU

On 28 August 2007 15:10, Richard Guenther wrote: > > Or maybe on ppc/spu enum bitfields are signed and the following > > DECL_FUNCTION_CODE (decl) = -1; > gcc_assert (DECL_FUNCTION_CODE (decl) >= function_code); > > doesnt work? I saw what you did there, and thought it slightly peculiar

Re: ICE in langhooks.c on SPU

On 8/28/07, Richard Guenther <[EMAIL PROTECTED]> wrote: > On 8/28/07, Revital1 Eres <[EMAIL PROTECTED]> wrote: > > > > Hello, > > > > I get the following ICE with trunk r127857 running the testsuite on SPU: > > > > :0: internal compiler error: in add_builtin_function, at > > langhooks.c:485^M > > P

Re: ICE in langhooks.c on SPU

On 8/28/07, Revital1 Eres <[EMAIL PROTECTED]> wrote: > > Hello, > > I get the following ICE with trunk r127857 running the testsuite on SPU: > > :0: internal compiler error: in add_builtin_function, at > langhooks.c:485^M > Please submit a full bug report,^M > with preprocessed source if appropriat

ICE in langhooks.c on SPU

Hello, I get the following ICE with trunk r127857 running the testsuite on SPU: :0: internal compiler error: in add_builtin_function, at langhooks.c:485^M Please submit a full bug report,^M with preprocessed source if appropriate.^M See for instructions.^M compiler

question about rtl loop-iv analysis

Hi, I have a question about a loop that when vectorized does not get unrolled (by the rtl-level unroller), whereas the same loop when not vectorized does get unrolled. This is the testcase: #define N 40 #define M 10 float in[N+M], coeff[M], out[N]; void fir (){ int i,j,k; float diff; for (

Re: bootstrap failure while compiling gcc/tree.c (ICE)

Kaveh R. GHAZI wrote: On Fri, 24 Aug 2007, Brian Sidebotham wrote: This ICE is caused by the following patch: 2007-08-10 Kaveh R. Ghazi <[EMAIL PROTECTED]> * system.h (CONST_CAST): New. * c-decl.c (c_make_fname_decl): Use it. * c-lex.c (cb_ident, lex_string): Likewis

Re: PING SC members [was RE: RFA: GCC 4.2.1: Stabalizing coalesce_list's qsort]

Dave Korn wrote: > On 23 August 2007 22:34, Mark Mitchell wrote: > >> I do think that generating the same code, independent of host system, is >> a very important property of GCC's design, just like generating the same >> code independent of whether or not we're compiling with -g. > > Hear, h