Re: Constant folding and Constant propagation

2009-02-09 Thread Joern Rennecke
Ian Lance Taylor: that you are looking for. I'm not aware of any other processor which is able to load a large constant in a single instruction, but for which an add instruction is cheaper if there is a similar constant already available. Paul Brook: This is true for Arm/Thumb. You have limite

Re: GCC 4.4.0 Status Report (2009-02-09)

2009-02-09 Thread H.J. Lu
On Mon, Feb 9, 2009 at 1:57 PM, Joseph S. Myers wrote: > Status > == > > Trunk remains in Stage 4 (regression and documentation fixes mode). > > GCC 4.4 will be branched when there are no open P1 regressions for 4.4 > and the runtime library sources have been converted to GPLv3 with the > new

GCC 4.4.0 Status Report (2009-02-09)

2009-02-09 Thread Joseph S. Myers
Status == Trunk remains in Stage 4 (regression and documentation fixes mode). GCC 4.4 will be branched when there are no open P1 regressions for 4.4 and the runtime library sources have been converted to GPLv3 with the new licensing exception; the number of P1, P2 and P3 regressions has been

Re: Inline limits

2009-02-09 Thread Jan Hubicka
> On Thu, 5 Feb 2009, Paul Brook wrote: > > > For -Os it should be enough to set PARAM_STACK_FRAME_GROWTH > > > to zero. Inlining at -Os should already only happen if it decreases > > > (overall!) code-size. Thus, inlining a function that is called once and > > > that does not need to be emitted

Re: Constant folding and Constant propagation

2009-02-09 Thread Paul Brook
On Friday 06 February 2009, Ian Lance Taylor wrote: > Jean Christophe Beyler writes: > > All of these have an outer code of SET. Therefore, I'm not quite > > positive of how I'm supposed to implement my rtx_cost function. Since > > I don't seem to get a choice between a set 0xcb03 and a (plus 0xca

Re: Inline limits

2009-02-09 Thread Hans-Peter Nilsson
On Thu, 5 Feb 2009, Paul Brook wrote: > > For -Os it should be enough to set PARAM_STACK_FRAME_GROWTH > > to zero. Inlining at -Os should already only happen if it decreases > > (overall!) code-size. Thus, inlining a function that is called once and > > that does not need to be emitted will alway

Re[2]: gcc 3.3.6 and multilib

2009-02-09 Thread Sergey Anosov
Yes, of course. My gcc/config/mips/t-mips file: FPBIT = fp-bit.c DPBIT = dp-bit.c $(T)crti.o: $(srcdir)/config/mips/crti.asm $(GCC_PASSES) $(GCC_FOR_TARGET) $(GCC_CFLAGS) $(MULTILIB_CFLAGS) $(INCLUDES) \ -c -o $(T)crti.o -x assembler-with-cpp $(srcdir)/config/mips/crti.asm $(T)crtn.o: $

Re: gcc 3.3.6 and multilib

2009-02-09 Thread Daniel Jacobowitz
On Mon, Feb 09, 2009 at 03:15:20PM +0300, Sergey Anosov wrote: > [r...@st1 SPECS]# mips-vniins-linux-gcc -print-multi-lib > .; > el;@EL > > But output of > mips-unknown-linux-gcc --print-search-dirs > and > mips-unknown-linux-gcc -mel --print-search-dirs > is the same. Did you try mips-unknown-li

Re: Machine description question

2009-02-09 Thread Jean Christophe Beyler
Ok, I understand now. Thank you very much for your explanations, Jean Christophe Beyler On Sat, Feb 7, 2009 at 5:13 PM, Michael Meissner wrote: > On Sat, Feb 07, 2009 at 03:54:51PM -0500, Jean Christophe Beyler wrote: >> Dear all, >> >> I have a question about the way the machine description wor

gcc 3.3.6 and multilib

2009-02-09 Thread Sergey Anosov
Dear All, I want to use multilib (EL/EB) in mips-unknown-linux-gcc. So when I add some lines to gcc/config/mips/t-mips, it looks like gcc uses multilib. [r...@st1 SPECS]# mips-vniins-linux-gcc -print-multi-lib .; el;@EL But output of mips-unknown-linux-gcc --print-search-dirs and mips-unknown-li

Re: proposal for improved management bugzilla priorities/release criteria

2009-02-09 Thread Paolo Bonzini
>> - The more conservative one is to use more aggressively the release >> milestone field. Hard-to-fix bugs would be left as P2, but bumped to >> the next major release at the beginning of stage 3. >> >> Advantages: no need for churn in the bug database---very easy to implement >> Disadvantages: