Bugzilla host/build/target triplet fields too small

[Rask Ingemann Lambertsen]

   There's something wrong with the bugzilla fields for host/build/target
triplet:

 Build: 

 

 Host: 

 

Eh, -2? By definition, it is at least 0.

 Target: 

 

The string "pentiumpro-*-*" is 14 characters long. These fields all seem to
be coming up 2 characters short, so the first 2 characters are dropped (in
the browser that I use, at least). Upon seeing "64-unknown-linux-gnu", my
brain has to work that bit harder to figure out that it means
ia16-unknown-linux-gnu rather than powerpc64-unknown-linux-gnu or
x86_64-unknown-linux-gnu. Dropping the first two characters off of
"i686-pc-linux-gnu" means I have to enter that field and scroll to the
beginning to see if it says i386, i486, i586 or i686. It would be nice to
have this fixed.

-- 
Rask Ingemann Lambertsen

Re: top-level configure

[Ralf Wildenhues]

Hello,

a gentle reminder for:


:ADDPATCH configure:

> * Ben Elliston wrote on Sat, Jul 21, 2007 at 10:33:54PM CEST:
> 
> > It used to be the case that the Cygnus top-level configure script would
> > pass any configure options to all subdirectory `configure' invocations.
> > Now it doesn't seem to work as I expect when I pass --quiet to the
> > top-level configure script.
[...]

> ChangeLog:
> 2007-07-23  Ralf Wildenhues  <[EMAIL PROTECTED]>
> 
>   * configure.ac (TOPLEVEL_CONFIGURE_ARGUMENTS, baseargs):
>   Pass --silent if $silent.
> 
> Index: configure.ac
> ===
> --- configure.ac  (revision 126835)
> +++ configure.ac  (working copy)
> @@ -101,6 +102,9 @@
># Add the quoted argument to the list.
>TOPLEVEL_CONFIGURE_ARGUMENTS="$TOPLEVEL_CONFIGURE_ARGUMENTS $ac_arg"
>  done
> +if test "$silent" = yes; then
> +  TOPLEVEL_CONFIGURE_ARGUMENTS="$TOPLEVEL_CONFIGURE_ARGUMENTS --silent"
> +fi
>  # Remove the initial space we just introduced and, as these will be
>  # expanded by make, quote '$'.
>  TOPLEVEL_CONFIGURE_ARGUMENTS=`echo "x$TOPLEVEL_CONFIGURE_ARGUMENTS" | sed -e 
> 's/^x *//' -e 's,\\$,$$,g'`
> @@ -2178,6 +2183,9 @@
>  gcc_transform_name=`cat conftestsed.out`
>  rm -f conftestsed.out
>  baseargs="$baseargs --program-transform-name='${gcc_transform_name}'"
> +if test "$silent" = yes; then
> +  baseargs="$baseargs --silent"
> +fi
>  
>  # For the build-side libraries, we just need to pretend we're native,
>  # and not use the same cache file.  Multilibs are neither needed nor

Re: top-level configure

[Paolo Bonzini]

Ralf Wildenhues wrote:

Hello,

a gentle reminder for:



Ok.

Paolo

poor optimisation case

[Tristan Wibberley]

Hi

I've found a case which looks like it should be possible to optimise but
gcc (very recent trunk) isn't doing which could give improvements in
many cases - certainly in a case I've come across:

#ifdef NEW
unsigned int fn(unsigned int n, unsigned int dmax) throw()
{
  for (unsigned int d = 0; d < dmax; ++d) {
n += d?d:1;
  }
  return n;
}
#else
unsigned int fn(unsigned int n, unsigned int dmax) throw()
{
  unsigned int add = 1;
  for (unsigned int d = 0; d < dmax; add = ++d) {
n += add;
  }
  return n;
}
#endif

When compiled with -O3 -DOLD I get:

.p2align 4,,15
.globl _Z2fnjj
.type   _Z2fnjj, @function
_Z2fnjj:
.LFB2:
testl   %esi, %esi
je  .L2
movl$1, %edx
xorl%eax, %eax
.p2align 4,,10
.p2align 3
.L3:
addl$1, %eax
addl%edx, %edi
cmpl%esi, %eax
movl%eax, %edx
jne .L3
.L2:
movl%edi, %eax
ret
.LFE2:
.size   _Z2fnjj, .-_Z2fnjj

but with -DNEW I get:

.p2align 4,,15
.globl _Z2fnjj
.type   _Z2fnjj, @function
_Z2fnjj:
.LFB2:
testl   %esi, %esi
je  .L2
movl$1, %edx
xorl%eax, %eax
movl$1, %ecx
jmp .L7
.p2align 4,,10
.p2align 3
.L5:
testl   %eax, %eax
movl%ecx, %edx
cmovne  %eax, %edx
.L7:
addl$1, %eax
addl%edx, %edi
cmpl%esi, %eax
jne .L5
.L2:
movl%edi, %eax
ret
.LFE2:
.size   _Z2fnjj, .-_Z2fnjj

The performance difference is about 50% with -DNEW taking 1.5 times as
long as -DOLD (that was with dmax == 10).

The loop unfortunately can't always be written as in -DOLD as the
implementation of an iterator adapter might use ?: to special case the
first element of a sequence and when used in a generic algorithm which
just has the simple loop of -DNEW it ought to be optimised like -DOLD if
inlining occurs.

-- 
Tristan Wibberley

Any opinion expressed is mine (or else I'm playing devils advocate for
the sake of a good argument). My employer had nothing to do with this
communication.

Re: poor optimisation case

[Tim Prince]

[EMAIL PROTECTED] wrote:

Hi

I've found a case which looks like it should be possible to optimise but
gcc (very recent trunk) isn't doing which could give improvements in
many cases - certainly in a case I've come across:

#ifdef NEW
unsigned int fn(unsigned int n, unsigned int dmax) throw()
{
  for (unsigned int d = 0; d < dmax; ++d) {
n += d?d:1;
  }
  return n;
}
#else
unsigned int fn(unsigned int n, unsigned int dmax) throw()
{
  unsigned int add = 1;
  for (unsigned int d = 0; d < dmax; add = ++d) {
n += add;
  }
  return n;
}
#endif

When compiled with -O3 -DOLD I get:

.p2align 4,,15
.globl _Z2fnjj
.type   _Z2fnjj, @function
_Z2fnjj:
.LFB2:
testl   %esi, %esi
je  .L2
movl$1, %edx
xorl%eax, %eax
.p2align 4,,10
.p2align 3
.L3:
addl$1, %eax
addl%edx, %edi
cmpl%esi, %eax
movl%eax, %edx
jne .L3
.L2:
movl%edi, %eax
ret
.LFE2:
.size   _Z2fnjj, .-_Z2fnjj

but with -DNEW I get:


.p2align 4,,15
.globl _Z2fnjj
.type   _Z2fnjj, @function
_Z2fnjj:
.LFB2:
testl   %esi, %esi
je  .L2
movl$1, %edx
xorl%eax, %eax
movl$1, %ecx
jmp .L7
.p2align 4,,10
.p2align 3
.L5:
testl   %eax, %eax
movl%ecx, %edx
cmovne  %eax, %edx
.L7:
addl$1, %eax
addl%edx, %edi
cmpl%esi, %eax
jne .L5
.L2:
movl%edi, %eax
ret
.LFE2:
.size   _Z2fnjj, .-_Z2fnjj

The performance difference is about 50% with -DNEW taking 1.5 times as
long as -DOLD (that was with dmax == 10).

The loop unfortunately can't always be written as in -DOLD as the
implementation of an iterator adapter might use ?: to special case the
first element of a sequence and when used in a generic algorithm which
just has the simple loop of -DNEW it ought to be optimised like -DOLD if
inlining occurs.

I don't see why you special case the first iteration of a loop with ? 
inside the loop.  Simply write the first iteration separately, and begin 
the loop with the next iteration.  It should be a lot clearer both to us 
and to the compiler what is your intention.
Doesn't this belong on gcc-help?  Better peeling optimization needs more 
justification than this.

Re: poor optimisation case

[Tristan Wibberley]

On Sun, 2007-08-05 at 16:58 -0400, Tim Prince wrote: 
> [EMAIL PROTECTED] wrote:

[snip]

> > The loop unfortunately can't always be written as in -DOLD as the
> > implementation of an iterator adapter might use ?: to special case the
> > first element of a sequence and when used in a generic algorithm which
> > just has the simple loop of -DNEW it ought to be optimised like -DOLD if
> > inlining occurs.
> > 
> I don't see why you special case the first iteration of a loop with ? 
> inside the loop.  Simply write the first iteration separately, and begin 
> the loop with the next iteration.  It should be a lot clearer both to us 
> and to the compiler what is your intention.
> Doesn't this belong on gcc-help?  Better peeling optimization needs more 
> justification than this.

As above. When using C++ as it's supposed to be used this isn't
possible. If I've got a sequence of values and I want to sum them there
is a generic sum algorithm that I'm supposed to use (and which I
*should* use to avoid unmaintainable spaghetti code which soon turns up
when every thing has to be hand coded to be fast - I've read "numerical
recipes in C" and nearly killed myself by the end of it).

If I've got a 100 element sequence and want (on one thread) to
compare what would happen in my generic algorithm (such as std::sum) if
the first element is doubled but (on a second thread) with the sequence
as it is, I'm not supposed to be required to write two versions of a
large piece of code - I'm supposed to be able to just write an iterator
that returns a different value for the first element.

In the case of returning a different value for the first element, I'd
use something in operator* that after inlining would end up as
equivalent to d?d:1 and the compiler should optimise that if it can and
if it would reduce runtime by a massive 33% and text size by quite a
bit. Both of those are true in this case.

Basically, writing two versions of the loop is not an option in real
life because developing on spaghetti C code is costly while elegant C++
code is cheap.

For example, my real (big) case is that I've got an iterator that moves
around an image or video thusly (or 4,5,6 dimensional equivalent):

  it = it[1] + 6; // move 6 rows along the 2nd dimension

When I move in all dimensions at once I quite sensibly have a loop from
dimension zero to the top dimension adding
(amount-to-move*stride-of-dimension) to the pointer that the iterator is
implemented with for each one. The strides of the dimensions are
previously recorded in an array that the iterator holds a reference to -
except the first (because when you have a one dimensional image - a
signal - nothing needs to be stored) which is always 1. So everything
gets reduced down correctly by g++, except that this special case is not
moved out of the loop.

So this is not a programming problem that I need help with (I know how
to micro-optimise with C-style ugly-stuff). I'm just reporting a
significant missed optimisation opportunity that will help C++
developers even if not C or fortran developers. The only reason I didn't
reflect the C++ simple-vs-spaghetti code issue in my example is because
I wanted to keep it simple to target one of the problems very
specifically.

-- 
Tristan Wibberley

Any opinion expressed is mine (or else I'm playing devils advocate for
the sake of a good argument). My employer had nothing to do with this
communication.

Re: Address of template function bug (was: Overload resolution compilation error)

[Rodolfo Lima]

Rodolfo Schulz de Lima escreveu:
> Dave Korn escreveu:
>>   Thanks, and do drop a note back with a summary of what you find out
> over
>> there when you're done; if there's definitely a bug in gcc's
> understanding of
>> the resolution rules, obviously we'd like to open a PR and get it fixed.
> 
> I think we have finally a consensus at
> 
> http://groups.google.com/group/comp.lang.c++.moderated/browse_thread/thread/52087a72bdc5de5a

Hi, I'd like some feedback on this thread because if it's really a bug,
I'd fill a bug report.

Thanks,
Rodolfo Lima.

Re: Bugzilla host/build/target triplet fields too small

[Daniel Berlin]

On 8/5/07, Rask Ingemann Lambertsen <[EMAIL PROTECTED]> wrote:
>There's something wrong with the bugzilla fields for host/build/target
> triplet:
>
>  Build: 
> 
>  
>
>  Host: 
> 
>  
>
> Eh, -2? By definition, it is at least 0.
>
>  Target: 
> 
>  
>
> The string "pentiumpro-*-*" is 14 characters long. These fields all seem to
> be coming up 2 characters short, so the first 2 characters are dropped (in
> the browser that I use, at least). Upon seeing "64-unknown-linux-gnu", my
> brain has to work that bit harder to figure out that it means
> ia16-unknown-linux-gnu rather than powerpc64-unknown-linux-gnu or
> x86_64-unknown-linux-gnu. Dropping the first two characters off of
> "i686-pc-linux-gnu" means I have to enter that field and scroll to the
> beginning to see if it says i386, i486, i586 or i686. It would be nice to
> have this fixed.

There is no way to fix this that
a. works across browsers
b. doesn't fuck up the field layout

The real problem is b.  It used to simply be a fixed size, but if you
do this, you have to make it like 20-30 chars per field.  If you do
*that*, you completely fuck up the field layout when they don't
contain a lot of data.

I'm going to move us to bugzilla 3.0, which has custom fields, and
will sanely lay them out, but it is harder than expected due to our
currently custom schema and email handling features.

For now, i have made the fields not subtract two from the size (which
was done to fix a broken browser)