Re: Official GCC git repository

[Rafael Espindola]

> Because the right one should have been
>
> $ git config --add remote.origin.fetch '+refs/heads/*:refs/remotes/origin/*'
>

That is what "git clone" adds, but with that "git branch -r" will not
list the remote branches.

>
> Paolo
>

Cheers,
-- 
Rafael Avila de Espindola

Google | Gordon House | Barrow Street | Dublin 4 | Ireland
Registered in Dublin, Ireland | Registration Number: 368047

Re: Official GCC git repository

[Paolo Bonzini]

Rafael Espindola wrote:
>> Because the right one should have been
>>
>> $ git config --add remote.origin.fetch '+refs/heads/*:refs/remotes/origin/*'
>>
> 
> That is what "git clone" adds, but with that "git branch -r" will not
> list the remote branches.

Uhm, it does here (I don't have a GCC repo, it's another one):

$ git branch -r
  mirror/cpp
  mirror/exc-handling-alternate-fix
  mirror/filesystem
  mirror/ipv6
  mirror/magritte
  mirror/master
  mirror/omnibrowser
  mirror/opengl
  mirror/opengl-nurbs
  mirror/poll-for-win32
  mirror/pool-resolution
  mirror/roe
  mirror/sdl
  mirror/seaside
  mirror/stable-2.1
  mirror/stable-2.2
  mirror/stable-2.3
  mirror/stable-3.0
  origin/HEAD
  origin/master
  origin/stable-2.1
  origin/stable-2.2
  origin/stable-2.3
  origin/stable-3.0
  stephen/master
  stephen/pool-resolution
  stephen/stable-3.0

You can see that it also lists branches for different remotes (with
distributed version control you need many of them, maybe one per
contributor).

Have you tried (after changing the .git/config line for
remote.origin.fetch) doing a "git fetch origin" to refresh the list of
available branches for the origin remote?  If it works now, you probably
want to remove the files in .git/refs/remotes/*.

Paolo

Re: Official GCC git repository

[Rafael Espindola]

> Uhm, it does here (I don't have a GCC repo, it's another one):

I think the problem is that the GCC repo is set up in some unusual way.

> $ git branch -r
>  mirror/cpp
>  mirror/exc-handling-alternate-fix
>  mirror/filesystem
>  mirror/ipv6
>  mirror/magritte
>  mirror/master
>  mirror/omnibrowser
>  mirror/opengl
>  mirror/opengl-nurbs
>  mirror/poll-for-win32
>  mirror/pool-resolution
>  mirror/roe
>  mirror/sdl
>  mirror/seaside
>  mirror/stable-2.1
>  mirror/stable-2.2
>  mirror/stable-2.3
>  mirror/stable-3.0
>  origin/HEAD
>  origin/master
>  origin/stable-2.1
>  origin/stable-2.2
>  origin/stable-2.3
>  origin/stable-3.0
>  stephen/master
>  stephen/pool-resolution
>  stephen/stable-3.0
>
> You can see that it also lists branches for different remotes (with
> distributed version control you need many of them, maybe one per
> contributor).
>
> Have you tried (after changing the .git/config line for
> remote.origin.fetch) doing a "git fetch origin" to refresh the list of
> available branches for the origin remote?  If it works now, you probably
> want to remove the files in .git/refs/remotes/*.

I need a new "git clone" just to be sure. It has the line you
suggested. I am using

fetch = +refs/remotes/*:refs/remotes/origin/*

for now.

A small manual edit for each new branch is not too much work.

> Paolo
>

Cheers,
-- 
Rafael Avila de Espindola

Google | Gordon House | Barrow Street | Dublin 4 | Ireland
Registered in Dublin, Ireland | Registration Number: 368047

Re: Official GCC git repository

[Andreas Schwab]

Rafael Espindola  writes:

>>> git config --add remote.origin.fetch '+refs/remotes/*:refs/remotes/*'
>>
>> This will put the remote branch heads in refs/remotes, you might want to
>> put them in refs/remotes/origin instead.
>>
>> $ git config --add remote.origin.fetch 
>> '+refs/remotes/*:refs/remotes/origin/*'
>
> One small problem I have with this.

As I wrote in a followup, this is not really a good idea.  You should
put the other remote heads under a different directory, perhaps like
this:

$ git config --add remote.origin.fetch '+refs/remotes/*:refs/remotes/gcc/*'

This tells git to fetch the remote heads matching refs/remotes/* and to
make them availble locally under refs/remotes/gcc.

Andreas.

-- 
Andreas Schwab, SuSE Labs, sch...@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Official GCC git repository

[Andreas Schwab]

Paolo Bonzini  writes:

> Rafael Espindola wrote:
>>> Because the right one should have been
>>>
>>> $ git config --add remote.origin.fetch '+refs/heads/*:refs/remotes/origin/*'
>>>
>> 
>> That is what "git clone" adds, but with that "git branch -r" will not
>> list the remote branches.
>
> Uhm, it does here (I don't have a GCC repo, it's another one):

The gcc repo is special because it has most of its heads in refs/remotes
instead of refs/heads.  A git clone sets the repo up such that only
remote heads matching refs/heads/* are fetched.

Andreas.

-- 
Andreas Schwab, SuSE Labs, sch...@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

new MPFR-2.4.0 Release Candidate (rc2)

[Vincent Lefevre]

- Forwarded message from Paul Zimmermann  -

From: Paul Zimmermann 
To: m...@loria.fr
Date: Mon, 22 Dec 2008 12:52:14 +0100
Subject: [MPFR] new MPFR-2.4.0 Release Candidate (rc2)

   Hi,

thank you to all of you who gave feedback to the 1st release candidate.
We have prepared a 2nd release candidate which should solve most issues:

http://www.mpfr.org/mpfr-2.4.0/mpfr-2.4.0-rc2.tar.gz
http://www.mpfr.org/mpfr-2.4.0/mpfr-2.4.0-rc2.tar.bz2
http://www.mpfr.org/mpfr-2.4.0/mpfr-2.4.0-rc2.tar.lzma
http://www.mpfr.org/mpfr-2.4.0/mpfr-2.4.0-rc2.zip

The MD5's:
d889b6decee524df32c89c6cd593066c  mpfr-2.4.0-rc2.tar.bz2
1b0c0dc5fa6d877fea36ed110bd056f1  mpfr-2.4.0-rc2.tar.gz
ee983b505e35a2dde4a29ab4da120f98  mpfr-2.4.0-rc2.tar.lzma
b3f2a07a77c3bc74350c8b9c14447b82  mpfr-2.4.0-rc2.zip

The signatures:
http://www.mpfr.org/mpfr-2.4.0/mpfr-2.4.0-rc2.tar.lzma.asc
http://www.mpfr.org/mpfr-2.4.0/mpfr-2.4.0-rc2.tar.bz2.asc
http://www.mpfr.org/mpfr-2.4.0/mpfr-2.4.0-rc2.tar.gz.asc
http://www.mpfr.org/mpfr-2.4.0/mpfr-2.4.0-rc2.zip.asc

Please send success and failure reports with "./config.guess" output
to . 

We will collect all feedback until early January. Don't worry if you don't
get an immediate feedback.

In the meantime, we wish you Merry Christmas and Happy New Year!

Paul Zimmermann

- End forwarded message -

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

gcc.c-torture/compile/limits-exprparen.c Out of stack space.

[Jack Howarth]

   The regress tester for powerpc-apple-darwin8.5.0 has been failing...

FAIL: gcc.c-torture/compile/limits-exprparen.c  -O0  (test for excess errors)
FAIL: gcc.c-torture/compile/limits-exprparen.c  -O1  (test for excess errors)
FAIL: gcc.c-torture/compile/limits-exprparen.c  -O2  (test for excess errors)
FAIL: gcc.c-torture/compile/limits-exprparen.c  -O3 -fomit-frame-pointer  (test 
for excess errors)
FAIL: gcc.c-torture/compile/limits-exprparen.c  -O3 -g  (test for excess errors)
FAIL: gcc.c-torture/compile/limits-exprparen.c  -Os  (test for excess error

since http://gcc.gnu.org/ml/gcc-testresults/2008-07/msg02753.html (r138218).
Unfortunately there was a large gap in the regress builds before this (from the 
tuples
merge perhaps). The last build without the errors was 
http://gcc.gnu.org/ml/gcc-testresults/2008-07/msg00727.html
of 137613. Geoff Keating suggests the fact that the 
gcc.c-torture/compile/limits-exprparen.c
now produces the error...

Executing on host: /Users/regress/tbox/native/build/gcc/xgcc 
-B/Users/regress/tbox/native/build/gcc/   -O0  -w -c  -o limits-exprparen.o 
/Users/regress/tbox/svn-gcc/gcc/testsuite/gcc.c-torture/compile/limits-exprparen.c
(timeout = 300)
Out of stack space.
Try running 'ulimit -S -s unlimited' in the shell to raise its limit.
compiler exited with status 1
output is:
Out of stack space.
Try running 'ulimit -S -s unlimited' in the shell to raise its limit.

FAIL: gcc.c-torture/compile/limits-exprparen.c  -O0  (test for excess errors)

...indicates that it is no longer checking that GCC's stack space is
reasonable. I'll open a PR for this against 4.4.0.
  Jack
ps I don't see this myself on a dual G5 with 4 GB running darwin9
but regress is a G4 running darwin8 with, I assume, much less memory than that.

Odd performance regression with -Os

[Andrew Haley]

Here's a strange case of poor code generation with -Os.

unsigned short foo2 (unsigned char on_off, unsigned short *puls)
{
  return puls[on_off-1];
}

With -O2, it's fine:

movzbl  %dil, %edi
movzwl  -2(%rsi,%rdi,2), %eax
ret

With -Os it's really weird:

movzbl  %dil, %eax
movl$1, %edi
subq%rax, %rdi
imulq   $-2, %rdi, %rdi
movw(%rdi,%rsi), %ax
ret

The problem here seems to be that the FE (or the GIMPLE generation)
transforms

addr + ((on_off-1)*2)

into

addr + ((1-on_off)*-2)

and nothing in -Os has the wit to recover.  This badly affects targets
with no hardware multiplier, which end up calling libgcc to do the
multiply.

Is this a well-known problem?

Andrew.

Re: Odd performance regression with -Os

[Eric Botcazou]

> The problem here seems to be that the FE (or the GIMPLE generation)
> transforms
>
> addr + ((on_off-1)*2)
>
> into
>
> addr + ((1-on_off)*-2)
>
> and nothing in -Os has the wit to recover.  This badly affects targets
> with no hardware multiplier, which end up calling libgcc to do the
> multiply.
>
> Is this a well-known problem?

We very recently ran into it, although it's quite old.  It comes from:

2005-11-19  Richard Guenther  

PR middle-end/23294
* fold-const.c (fold_plusminus_mult_expr): New function.
(fold_binary): Use to canonicalize PLUS_EXPR and MINUS_EXPR
cases, remove now unnecessary code.

which has changed the canonicalization of addresses as well, without anyone 
apparently noticing.  In particular, 

  [...]
   We also canonicalize (X + 7) * 4 into X * 4 + 28 in the hope that either
   the machine has a multiply-accumulate insn or that this is part of an
   addressing calculation.
  [...]

static tree
extract_muldiv (tree t, tree c, enum tree_code code, tree wide_type,
bool *strict_overflow_p)

is now wrong since it's undone by fold_plusminus_mult_expr.


I've attached the patch (against the 4.3 branch) we use locally.


* fold-const.c (extract_muldiv): Remove obsolete comment.
(fold_plusminus_mult_expr): Use only positive power-of-two factors.
* expr.c (get_inner_reference): Canonicalize offset.


-- 
Eric Botcazou
*** gcc/fold-const.c.0	2008-12-11 10:47:40.0 +0100
--- gcc/fold-const.c	2008-12-11 20:08:18.0 +0100
*** optimize_minmax_comparison (enum tree_co
*** 6010,6019 
 expression would not overflow or that overflow is undefined for the type
 in the language in question.
  
-We also canonicalize (X + 7) * 4 into X * 4 + 28 in the hope that either
-the machine has a multiply-accumulate insn or that this is part of an
-addressing calculation.
- 
 If we return a non-null expression, it is an equivalent form of the
 original computation, but need not be in the original type.
  
--- 6010,6015 
*** fold_plusminus_mult_expr (enum tree_code
*** 7459,7497 
else if (operand_equal_p (arg01, arg10, 0))
  same = arg01, alt0 = arg00, alt1 = arg11;
  
!   /* No identical multiplicands; see if we can find a common
!  power-of-two factor in non-power-of-two multiplies.  This
!  can help in multi-dimensional array access.  */
!   else if (host_integerp (arg01, 0)
! 	   && host_integerp (arg11, 0))
! {
!   HOST_WIDE_INT int01, int11, tmp;
!   bool swap = false;
!   tree maybe_same;
!   int01 = TREE_INT_CST_LOW (arg01);
!   int11 = TREE_INT_CST_LOW (arg11);
  
/* Move min of absolute values to int11.  */
!   if ((int01 >= 0 ? int01 : -int01)
! 	  < (int11 >= 0 ? int11 : -int11))
! {
  	  tmp = int01, int01 = int11, int11 = tmp;
! 	  alt0 = arg00, arg00 = arg10, arg10 = alt0;
! 	  maybe_same = arg01;
  	  swap = true;
  	}
else
! 	maybe_same = arg11;
  
!   if (exact_log2 (abs (int11)) > 0 && int01 % int11 == 0)
! {
  	  alt0 = fold_build2 (MULT_EXPR, TREE_TYPE (arg00), arg00,
  			  build_int_cst (TREE_TYPE (arg00),
! 	 int01 / int11));
! 	  alt1 = arg10;
! 	  same = maybe_same;
  	  if (swap)
! 	maybe_same = alt0, alt0 = alt1, alt1 = maybe_same;
  	}
  }
  
--- 7455,7497 
else if (operand_equal_p (arg01, arg10, 0))
  same = arg01, alt0 = arg00, alt1 = arg11;
  
!   /* No identical multiplicands; see if we can find a common positive
!  power-of-two factor.  This can help in multi-dim array accesses.  */
!   else if (host_integerp (arg01, 0) && host_integerp (arg11, 0))
! {
!   HOST_WIDE_INT int01 = TREE_INT_CST_LOW (arg01);
!   HOST_WIDE_INT int11 = TREE_INT_CST_LOW (arg11);
!   HOST_WIDE_INT factor, tmp;
!   tree tmp_tree;
!   bool swap;
  
/* Move min of absolute values to int11.  */
!   if ((int01 >= 0 ? int01 : -int01) < (int11 >= 0 ? int11 : -int11))
! 	{
  	  tmp = int01, int01 = int11, int11 = tmp;
! 	  tmp_tree = arg00, arg00 = arg10, arg10 = tmp_tree;
  	  swap = true;
  	}
else
! 	swap = false;
  
!   if (int11 < 0)
! 	factor = -int11;
!   else
! 	factor = int11;
! 
!   if (exact_log2 (factor) > 0 && (int01 % factor) == 0)
! 	{
  	  alt0 = fold_build2 (MULT_EXPR, TREE_TYPE (arg00), arg00,
  			  build_int_cst (TREE_TYPE (arg00),
! 	 int01 / factor));
! 	  if (int11 < 0)
! 	alt1 = fold_build1 (NEGATE_EXPR, TREE_TYPE (arg10), arg10);
! 	  else
! 	alt1 = arg10;
  	  if (swap)
! 	tmp_tree = alt0, alt0 = alt1, alt1 = tmp_tree;
! 	  same = build_int_cst (TREE_TYPE (arg10), factor);
  	}
  }
  
*** gcc/expr.c.0	2008-12-11 10:54:49.0 +0100
--- gcc/expr.c	2008-12-11 20:29:28.0 +0100
*** get_inner_reference (tree exp, HOST_WIDE
*** 6042,6047 
--- 6042,6066 
  {
*pbitpos = tree_low_cst (bit_offs

Re: Odd performance regression with -Os

[Eric Botcazou]

> Thanks.  Are you holding this because we're in Stage 3?

The patch was written very recently so I wanted to let it go through a good 
deal of internal testing.  Moveover I haven't measured its impact on anything 
else than Ada benchmarks (and on a patched 4.3 branch).  If people think that
it would be worth having for the 4.4 release, I can port it and conduct basic 
testing with it on the mainline, but that's pretty much it.

-- 
Eric Botcazou

GNU compiler for Linux

[J.BALAJI]

Dear Sir / Madam

Please kindly help me to have the website link to download the
GNU compiler for Linux

Thanks and Regards

J.BALAJI
Assistant Manager (R&D)
Trinity Comnet Pvt Ltd
PH:9789273624