Re: Validity of __asm__ transformation with "m" reference

2011-07-04 Thread Paulo César Pereira de Andrade
Jakub Jelinek wrote: > On Mon, Jul 04, 2011 at 03:49:58PM +0200, Michael Matz wrote: >> > But you said the operand is an int sized memory, while you expect >> > 4 times as big data with different alignment. >> > So you want "m"(*(__m128d *)) (or "m"(*(__m128i *)) ). >> >> Right. But even

Re: Long paths with ../../../../ throughout

2011-07-04 Thread Jon Grant
Ian Lance Taylor wrote, On 03/07/11 05:27: Jon Grant writes: [.] Another reply for this old thread. I wondered, if collect2 is possibly not needed in normal use on GNU/Linux, could GCC be configured to call ld directly in those cases to save launching another binary. collect2 is needed if y

[pph] Running a single test in pph.exp

2011-07-04 Thread Diego Novillo
So, I thought this was not working, but it is: $ make check-g++ RUNTESTFLAGS=pph.exp='c1eabi1.*' will run all the tests for c1eabi1.cc and c1eabi1.h. Diego.

Re: Validity of __asm__ transformation with "m" reference

2011-07-04 Thread Michael Matz
Hi, On Mon, 4 Jul 2011, Jakub Jelinek wrote: > No, what you can get out of that is e.g. optimizing away otherwise unneeded > large variable. > Consider: > static const int i[131072] = { 1, 2, 3, 4, 5 }; > void foo (void) > { > __asm volatile ("" : : "m" (i[0])); > } > By giving the asm just add

Re: Is libiberty's splay-tree.c really a splay tree?

2011-07-04 Thread Michael Matz
Hi, On Mon, 4 Jul 2011, Michael Matz wrote: > > There were other people pointing out issues with the splay tree (but > > all w/o copyright assignment and much larger patches). > > > > I know I did the last re-write of this piece of code but it's been a > > long time ... in any case, previous r

Re: Validity of __asm__ transformation with "m" reference

2011-07-04 Thread Jakub Jelinek
On Mon, Jul 04, 2011 at 03:49:58PM +0200, Michael Matz wrote: > > But you said the operand is an int sized memory, while you expect > > 4 times as big data with different alignment. > > So you want "m"(*(__m128d *)) (or "m"(*(__m128i *)) ). > > Right. But even then the replacement of a m

Re: Is libiberty's splay-tree.c really a splay tree?

2011-07-04 Thread Michael Matz
Hi, On Mon, 4 Jul 2011, Richard Guenther wrote: > There were other people pointing out issues with the splay tree (but all > w/o copyright assignment and much larger patches). > > I know I did the last re-write of this piece of code but it's been a > long time ... in any case, previous reports

Re: Validity of __asm__ transformation with "m" reference

2011-07-04 Thread Michael Matz
Hi, On Fri, 1 Jul 2011, Jakub Jelinek wrote: > > GCC turns this into: > > "movaps%0, %%xmm0 > > shufps$27, %%xmm0, %%xmm0 > > movaps%1, %%xmm5 > > movaps%%xmm5, %%xmm6 > > " : : "m" costab_mmx[24], *"m" -2147483648*); > > > > The new constant might e

Re: Is libiberty's splay-tree.c really a splay tree?

2011-07-04 Thread Richard Guenther
On Mon, Jul 4, 2011 at 2:23 PM, Richard Sandiford wrote: > OK, I know I'm embarrassing myself here, but is libiberty's splay-tree.c > doing the right thing for the zig-zig and zag-zag cases?  The code reads: > >    /* Now we have the four cases of double-rotation.  */ >    if (cmp1 < 0 && cmp2 < 0

Is libiberty's splay-tree.c really a splay tree?

2011-07-04 Thread Richard Sandiford
OK, I know I'm embarrassing myself here, but is libiberty's splay-tree.c doing the right thing for the zig-zig and zag-zag cases? The code reads: /* Now we have the four cases of double-rotation. */ if (cmp1 < 0 && cmp2 < 0) { rotate_left (&n->left, c, c->left); rot