Re: Official GCC git repository

[Rafael Espindola]

>> 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. When I do "git branch lto
origin/lto" the generated config entry says:

[branch "lto"]
remote = origin
merge = refs/heads/lto

and "git pull" will fail.  Manually updating it to

[branch "lto"]
remote = origin
merge = refs/remotes/lto

solves the problem

>
> Andreas.
>

Cheers,
-- 
Rafael Avila de Espindola

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

Makefile support requested - enabling multilib for target

[NightStrike]

Currently, gcc doesn't support a multilib build for win64.  I have
been looking at how to do this, and have so far come up with a
beginning to a solution.  The work done thus far is part of this PR:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38294

The current blocker is in building libgcc.  At some point in building
libgcc, it gets down to the final compilation.  In doing so, gcc is
invoked with a -B option pointing to the 32-bit lib directory instead
of the 64-bit lib directory.  This works for building the 32-bit
libgcc, but not the 64-bit default version.

>From what I can tell, the -B option pointing to the 32-bit lib
directory is in $(GCC_FOR_TARGET).  Is that where it's supposed to be?
 Is there a way to make gcc search the right directory first (or at
all)?  What steps am I missing for enabling the multilib build?

For reference, the system root and all of its libraries are installed into:

$prefix/$target/lib and $prefix/$target/lib64, the latter of course
being the 64-bit version of all the libs.

Re: GCC 4.4.0 Status Report (2008-11-27)

[Hans-Peter Nilsson]

On Tue, 9 Dec 2008, Jeff Law wrote:
> Hans-Peter Nilsson wrote:
> > Vladimir, have you had chance to look at supporting
> > LOAD_EXTEND_OP (implicit sign-extension) in IRA?
> >
> > 
> >
> > I'm guessing no, but hope it's not forgotten.
> >
> > I intend to write a PR this weekend if you need specific
> > information.
> Yes, please create a PR to track this issue so that it doens't get completely
> lost.

FWIW, some change after 141361 hid it: I can't repeat it with
neither 142609 nor 142857 (no regressions comparing an
unmodified baseline w.o. the IRA patch).  I created PR38603
anyway.  I intend to fill in details and investigate and triage
what change hid it.

brgds, H-P

Re: Official GCC git repository

[Paolo Bonzini]

Rafael Espindola wrote:
>>> 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. When I do "git branch lto
> origin/lto" the generated config entry says:
> 
> [branch "lto"]
> remote = origin
> merge = refs/heads/lto
> 
> and "git pull" will fail.  Manually updating it to
> 
> [branch "lto"]
> remote = origin
> merge = refs/remotes/lto

Because the right one should have been

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

?

Paolo