Status of trunk freeze

2007-06-28 Thread Steve Kargl
Mark, What's the status of the trunk freeze for going from stage 1 to stage 2? AFAICT, the number of regression on trunk has increased since you sent http://gcc.gnu.org/ml/gcc/2007-06/msg00411.html There have been a number of commits to trunk that do not address regressions. I've been holding

Re: PTR-PLUS merge into the mainline

2007-06-28 Thread Andrew_Pinski
Roman Zippel <[EMAIL PROTECTED]> wrote on 06/28/2007 07:54:43 PM: > Hi, > Notice that it generates the (i + 1) * 4 instead of (i * 4) + 4 as with > the other cases. While I tried to debug this I narrowed it down to the > changes in fold_binary(), but I don't really know how to fix this, so > I

Re: LTO reader support for MEMORY_PARTITION_TAG

2007-06-28 Thread Kenneth Zadeck
Mark Mitchell wrote: > Kenneth Zadeck wrote: > > >> now that we can compile, i will start looking inside today. >> > > At present, lto_read_function_body doesn't set DECL_SAVED_TREE for the > function body, so there's nothing for the back end to even try to > output. It doesn't look to me

Re: PTR-PLUS merge into the mainline

2007-06-28 Thread Roman Zippel
Hi, On Fri, 15 Jun 2007, [EMAIL PROTECTED] wrote: > This patch merges in the pointer_plus branch. Hopefully I did not mess > anything up. I found a small regression caused by this, e.g.: int g(void); void f(int *p, int i) { p[i] = g(); p[i + 2] = g(); p[i + 1] = g()

Re: LTO reader support for MEMORY_PARTITION_TAG

2007-06-28 Thread Mark Mitchell
Kenneth Zadeck wrote: > now that we can compile, i will start looking inside today. At present, lto_read_function_body doesn't set DECL_SAVED_TREE for the function body, so there's nothing for the back end to even try to output. It doesn't look to me like we've got code to try to read that back

Re: [ARM] Cirrus EP93xx Maverick Crunch Support - CC modes / condexec / CC_REGNUM

2007-06-28 Thread Hasjim Williams
On Thu, 28 Jun 2007 14:55:17 +0200, "Rask Ingemann Lambertsen" <[EMAIL PROTECTED]> said: > On Wed, Jun 27, 2007 at 11:26:41AM +1000, Hasjim Williams wrote: > > G'day all, > > > > As I wrote previously on gcc-patches ( > > http://gcc.gnu.org/ml/gcc-patches/2007-06/msg00244.html ), I'm working > >

Re: I'm sorry, but this is unacceptable (union members and ctors)

2007-06-28 Thread michael.a
mark-28 wrote: > >> Mark Mielke wrote "Why not This?": >> > class Rectangle { >> > Vector2d position; >> > Vector2d size; >> > }; >> > ... rectangle.position.x = ... ... > > On Thu, Jun 28, 2007 at 03:00:07AM -0700, michael.a wrote: >> My foremost personal requirement i

Re: I'm sorry, but this is unacceptable (union members and ctors)

2007-06-28 Thread mark
> Mark Mielke wrote "Why not This?": > > class Rectangle { > > Vector2d position; > > Vector2d size; > > }; > > ... rectangle.position.x = ... ... On Thu, Jun 28, 2007 at 03:00:07AM -0700, michael.a wrote: > My foremost personal requirement is that no code need change outsi

Re: combine corrupts insns + dumps with insn cost problems

2007-06-28 Thread Rask Ingemann Lambertsen
[One-liner alert!] On Wed, Jun 27, 2007 at 07:54:36PM +0200, Eric Botcazou wrote: > > Combine knows how to add clobbers to make insns recognizable. I'm guessing > > it accidentally clobbers the original insn in doing so. Where would I look? > > Anywhere in combine. :-) This is by design, see the

Re: Static const int as array bound inside class

2007-06-28 Thread Andrew Pinski
On 6/27/07, Torquil Macdonald Sørensen <[EMAIL PROTECTED]> wrote: Best regards, Torquil Sørensen / Example code (from the book): class X { static const int size; int array[size]; }; const int X::size = 100; It gives the error message "array bound is not an integer con

Re: Proposal: adding two zeros to the integer cost to calibrate better.

2007-06-28 Thread Rask Ingemann Lambertsen
On Wed, Jun 27, 2007 at 09:41:08PM +0200, J.C. Pizarro wrote: > I recommend to add 2 zeros to the integer costs as if those are 2 decimal > zeros, > for example, > > insn_cost 5: 1200 // it's 12.00 > insn_cost 6: 800 // it's 8.00 > insn_cost 7: 400 // it's 4.00 > insn_cost 8: 433

Re: [ARM] Cirrus EP93xx Maverick Crunch Support - condexec / bugfixing / "co-processor offset out of range"

2007-06-28 Thread Rask Ingemann Lambertsen
On Thu, Jun 28, 2007 at 01:55:24PM +1000, Hasjim Williams wrote: > > On Wed, 27 Jun 2007 12:31:42 +0200, "Rask Ingemann Lambertsen" > <[EMAIL PROTECTED]> said: > > Additionally, look at SELECT_CC_MODE and TARGET_CC_MODE_COMPATIBLE. That should be TARGET_CC_MODES_COMPATIBLE. > >The signi

Re: [ARM] Cirrus EP93xx Maverick Crunch Support - "bge" pattern

2007-06-28 Thread Rask Ingemann Lambertsen
On Wed, Jun 27, 2007 at 11:26:41AM +1000, Hasjim Williams wrote: > G'day all, > > As I wrote previously on gcc-patches ( > http://gcc.gnu.org/ml/gcc-patches/2007-06/msg00244.html ), I'm working > on code to get the MaverickCrunch Floating-Point Co-processor supported > on ARM. I mentioned previou

Re: I'm sorry, but this is unacceptable (union members and ctors)

2007-06-28 Thread michael.a
On Wed, Jun 27, 2007 at 11:36:23PM -0700, michael.a wrote: > mark-28 wrote: I agree with the sentiment, but not with the relevance. I don't see how having a four field structure automatically appear as a completley different two field structure, based only upon a match up between field types an

Re: I'm sorry, but this is unacceptable (union members and ctors)

2007-06-28 Thread mark
On Wed, Jun 27, 2007 at 11:36:23PM -0700, michael.a wrote: > mark-28 wrote: > > I don't understand what is being requested. Have one structure with > > four fields, and another with two, and allow them to be used > > automatically interchangeably? How is this a good thing? How will > > this prevent