Re: git mirror at gcc.gnu.org
On 06/10/09 02:43, Ian Lance Taylor wrote: > fche has already installed git 1.6.3.2 in /usr/local/bin on sourceware. > That is now the one you will get if you connect to port "git". Hope > nothing breaks. Thanks. I made a few changes that hopefully won't compromise existing clones: 0) Since when Daniel disabled his cron job to update the repository, mine had not actually been running because the crontab line was commented out. I enabled it. 1) Set UseDeltaBaseOffset=true for slightly smaller packs The downside is that we loose compatibility with git versions older than 1.4.4. Moreover, people fetching from dumb protocols will probably have to refetch from scratch. 2) Remove the local checkout and configure the repository as "bare=true" 3) I stupidly ran a "git gc" on the repository without specifying any parameters, which made the pack jump to a whopping 3.4GB. People fetching over git-aware protocols shouldn't notice anything unusual except, maybe, longer server-side packing time. Those stuck with http:// will have a bad surprise. /me ducks. I've now configured the default window and depth both to 100, and ran another repack from scratch which will take a long, long, long, long time. 4) I noticed we weren't actually doing "git update-server-info" anywhere, which means that those stuck with http:// are probably unable to be annoyed by my careless mistake anyway. I've now added it as the last step of my cron job ~bernie/bin/git-update-toolchain.sh 5) The repository was configured with HEAD pointing at the local branch "master", which git-svn doesn't know (or care) about. To make changes appear there too, Daniel's update script did a "git rebase" after every fetch, which does not work in bare repositories. Now I made HEAD point at branch "trunk" instead, and make "trunk" just be an indirect ref for "remotes/trunk", which is what git-svn actually updates. Hopefully this change won't break existing checkouts, but one might still have to perform some manual trickery to rename their local branch "master" to "trunk", or map it to remotes/trunk in their fetch configuration. 6) As Daniel said, we are indeed already mirroring all branches from the SVN repository. But those go to remotes/foo rather than foo, which most likely *your* git fetches aren't configured to consider. And gitweb doesn't show them either. As a workaround, I manually added a few local branches pointing directly to the remote ones. I arbitrarily chose to export all those gcc-4_x-branch tags, but we could add them all with a script, and maybe rename them to cull that "-branch" postfix which has been quite redundant since when we switched to svn. I sincerely apologize if these changes happen to hamper someone's productivity for a while. Cheer up! Your temporary suffering is for the long-term good! :-) Local to remote branch mapping is one of the least understood design aspects in git [*], and probably the steepest point of git's steep learning curve. It is especially unfortunate that git-svn exposes it even more than usual. [*] the git haters would simply call it "lack of design in git" -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/
Complex numbers in c++0x
In , GCC defines an additional overload of conj(x)
for non-complex arithmetic types, as specified in 26.3.9 [cmplx.over]
of the upcoming C++ Standard (Working Draft).
The Draft mandates certain type promotion of x.
In the (experimental) GCC implementation, conj(x) returns x as a
complex value (with imaginary part zero).
I strongly suggest to return x as a non-complex type
(specifically, the required promoted argument type).
As I read the Draft, this should satisfy the requirement of an
/effectively/ promoted argument: if needed, the returned real
will transparently be converted to complex.
(Actually I find a real return type so essential that it should be
/mandated/ by the standard. Is such a change still possible?)
Rationale:
Mathematically, complex conjugation (like the transcendental functions)
is complex-valued in general but maps the (extended) real line to itself.
A typical user will expect conj() to preserve this mathematical property,
just like exp(), sin(), etc. do.
A typical use of conj() is the generic scalar product of n-vectors:
template
inline T
scalar_product(size_t n, T const* x, T const* y)
{
T result = 0;
for (size_t i = 0; i < n; ++i)
result += std::conj(x[i]) * y[i];
return result;
}
This will work equally well for real and complex floating-point types T
if conj() returns T. It will not work with real types if conj() returns
complex values. Instead, a less efficient and unnecessarily complicated
scalar product implementation will be needed, e.g., using a complex
type for the temporary variable result.
Any use of conj() I can think of will benefit in this way from the proposed
change. I cannot think of any case where it would do any harm.
In contrast, I find the current overload conj() not only useless
but actually troublesome.
Or do I miss some important point?
PS: all this applies similarly to proj(x), except that it is not yet
provided by GCC.
Re: Complex numbers in c++0x
On Thu, Jun 11, 2009 at 2:27 AM, Marc Steinbach wrote: > In , GCC defines an additional overload of conj(x) > for non-complex arithmetic types, as specified in 26.3.9 [cmplx.over] > of the upcoming C++ Standard (Working Draft). > The Draft mandates certain type promotion of x. > > In the (experimental) GCC implementation, conj(x) returns x as a > complex value (with imaginary part zero). > > I strongly suggest to return x as a non-complex type > (specifically, the required promoted argument type). > > As I read the Draft, this should satisfy the requirement of an > /effectively/ promoted argument: if needed, the returned real > will transparently be converted to complex. > (Actually I find a real return type so essential that it should be > /mandated/ by the standard. Is such a change still possible?) The best place to address this issue is to take it to the C++ standards committee or post your message to the Usenet group comp.std.c++ -- Gaby
Re: Complex numbers in c++0x
Marc Steinbach wrote: > PS: all this applies similarly to proj(x), except that it is not yet > provided by GCC. > It is, for C++0x. Note that the end user is not supposed to use tr1_impl files directly. Paolo.
Re: git mirror at gcc.gnu.org
On Thu, Jun 11, 2009 at 3:07 AM, Bernie Innocenti wrote: > On 06/10/09 02:43, Ian Lance Taylor wrote: >> fche has already installed git 1.6.3.2 in /usr/local/bin on sourceware. >> That is now the one you will get if you connect to port "git". Hope >> nothing breaks. > > Thanks. > > I made a few changes that hopefully won't compromise existing clones: > > 0) Since when Daniel disabled his cron job to update the repository, > mine had not actually been running because the crontab line was > commented out. I enabled it. > > 1) Set UseDeltaBaseOffset=true for slightly smaller packs > The downside is that we loose compatibility with git versions > older than 1.4.4. Moreover, people fetching from dumb protocols > will probably have to refetch from scratch. > > 2) Remove the local checkout and configure the repository as > "bare=true" > Yeah, this i had forgotten to do ;) > 3) I stupidly ran a "git gc" on the repository without specifying > any parameters, which made the pack jump to a whopping 3.4GB. > People fetching over git-aware protocols shouldn't notice > anything unusual except, maybe, longer server-side packing time. > Those stuck with http:// will have a bad surprise. /me ducks. > I've now configured the default window and depth both to 100, > and ran another repack from scratch which will take a long, > long, long, long time. It may be faster for my to rsync it to a 32 core machine, pack it, then rsync it back now that delta compression is threaded. Does it get large enough speedups these days to be worth it?
Re: git mirror at gcc.gnu.org
On 06/11/09 14:03, Daniel Berlin wrote: > It may be faster for my to rsync it to a 32 core machine, pack it, > then rsync it back now that delta compression is threaded. > Does it get large enough speedups these days to be worth it? It's done, and the pack came out 553MB. Perhaps packing with an even larger window and depth of 250 might squeeze a few more MBs off... Worth a try :-) -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/
Re: git mirror at gcc.gnu.org
On 06/11/09 15:18, Bernie Innocenti wrote: > On 06/11/09 14:03, Daniel Berlin wrote: >> It may be faster for my to rsync it to a 32 core machine, pack it, >> then rsync it back now that delta compression is threaded. >> Does it get large enough speedups these days to be worth it? > > It's done, and the pack came out 553MB. > > Perhaps packing with an even larger window and depth of 250 might > squeeze a few more MBs off... Worth a try :-) BTW, I'd be curious to see how much 32 cores can speed up packing. By default, git-repack autodetects the number of CPUs and spawns threads accordingly, so it shouldn't require any tuning. You just need a recent version of git implementing this optimization. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/
Re: [RFC] enabling -fshow-column by default
2009/6/5 Jonathan Wakely:
> 2009/6/5 Aldy Hernandez:
>>
>> Which test is this? Can you send it to me?
>
> It tests a header that isn't checked in yet, so sending the test alone
> wouldn't help much :)
>
> I'll try to come up with a self-contained example tomorrow.
The attached test will FAIL with a trunk build from yesterday, with
the output in the second attachment.
The test for errors on line 11 fails because the error is at :11:9:
which matches the test for errors on line 9.
Jonathan
// { dg-do compile }
struct X
{
};
int main()
{
X x1(0); // { dg-error "no match" }
X x2(0); // { dg-error "no match" }
return 0;
}
// { dg-excess-errors "note" }
fail.log
Description: Binary data
Re: [RFC] enabling -fshow-column by default
On Thu, Jun 11, 2009 at 03:09:48PM +0100, Jonathan Wakely wrote:
> 2009/6/5 Jonathan Wakely:
> > 2009/6/5 Aldy Hernandez:
> >>
> >> Which test is this? ?Can you send it to me?
> >
> > It tests a header that isn't checked in yet, so sending the test alone
> > wouldn't help much :)
> >
> > I'll try to come up with a self-contained example tomorrow.
>
> The attached test will FAIL with a trunk build from yesterday, with
> the output in the second attachment.
>
> The test for errors on line 11 fails because the error is at :11:9:
> which matches the test for errors on line 9.
>
> Jonathan
> // { dg-do compile }
>
> struct X
> {
> };
>
> int main()
> {
> X x1(0); // { dg-error "no match" }
>
> X x2(0); // { dg-error "no match" }
>
> return 0;
> }
> // { dg-excess-errors "note" }
The libstdc++ testsuite doesn't use the overrides for dg-error et al. I
believe Janis is looking into this.
In the meantime, can you just put the column number in the dg-error
message? i.e:
// { dg-error "XX:no match" }
This will match the message correctly, and eventually all error messages
should have matching columns.
Aldy
Re: [RFC] enabling -fshow-column by default
2009/6/11 Aldy Hernandez:
>
> In the meantime, can you just put the column number in the dg-error
> message? i.e:
>
> // { dg-error "XX:no match" }
>
> This will match the message correctly, and eventually all error messages
> should have matching columns.
That works great, thanks, Aldy.
Jonathan
Re: Expanding a load instruction
Thanks, I've pretty much finished this part of the implementation and it seems to be working well. Thank you all very much for your help, Jc On Wed, Jun 10, 2009 at 11:12 AM, Dave Korn wrote: > Jean Christophe Beyler wrote: > >> It seems that I should do the same as them no for my solution. First >> implement the legitimate_address function and then probably define it >> in both macros. > > Sounds about right. > >> As for the target hook, we are using GCC 4.3.2 for the moment and, >> sadly, have not yet any plans to move forward to the latest version of >> GCC. > > Don't need to worry about it until you go to GCC 4.5.0 or above, then. > > cheers, > DaveK > >
Re: Code optimization only in loops
I've gone back to this problem (since I've solved another one ;-)).
And I've moved forward a bit:
It seems that if I consider an array of characters, there are no
longer any shifts and therefore I do get my two loads with the use of
an offset:
Code:
char data[1312];
uint64_t goo (uint64_t i)
{
return data[i] - data[i+13];
}
generates the right code with two loads with the same base but
different offsets.
If I use anything else than a char type, I get the problem in
generation. This seems to confirm that somehow, the way things are
generated blocks the subsequent optimization passes in seeing that the
addresses are linked.
Right now, I'm trying to figure out why I'm getting shifts and is this
the problem instead of a multiply. Since this was one of the
differences between what I get and what the i386 port gets.
If you've got any ideas, thanks again,
Jean Christophe
On Wed, May 13, 2009 at 4:58 PM, Jean Christophe
Beyler wrote:
> Ok, for the i386 port, I use uint32_t instead of uint64_t because
> otherwise the assembly code generated is a bit complicated (I'm on a
> 32 bit machine).
>
> The tree dump from final_cleanup are the same for the goo function:
> goo (i)
> {
> :
> return data[i + 13] + data[i];
>
> }
>
>
> However, the first RTL dump from expand gives this for the i386 port:
>
> (insn 6 5 7 3 ld.c:17 (parallel [
> (set (reg:SI 61)
> (plus:SI (reg/v:SI 59 [ i ])
> (const_int 13 [0xd])))
> (clobber (reg:CC 17 flags))
> ]) -1 (nil))
>
> (insn 7 6 8 3 ld.c:17 (set (reg/f:SI 62)
> (symbol_ref:SI ("data") )) -1 (nil))
>
> (insn 8 7 9 3 ld.c:17 (set (reg/f:SI 63)
> (symbol_ref:SI ("data") )) -1 (nil))
>
> (insn 9 8 10 3 ld.c:17 (set (reg:SI 64)
> (mem/s:SI (plus:SI (mult:SI (reg/v:SI 59 [ i ])
> (const_int 4 [0x4]))
> (reg/f:SI 63)) [3 data S4 A32])) -1 (nil))
>
> (insn 10 9 11 3 ld.c:17 (set (reg:SI 65)
> (mem/s:SI (plus:SI (mult:SI (reg:SI 61)
> (const_int 4 [0x4]))
> (reg/f:SI 62)) [3 data S4 A32])) -1 (nil))
>
> (insn 11 10 12 3 ld.c:17 (parallel [
> (set (reg:SI 60)
> (plus:SI (reg:SI 65)
> (reg:SI 64)))
> (clobber (reg:CC 17 flags))
> ]) -1 (expr_list:REG_EQUAL (plus:SI (mem/s:SI (plus:SI
> (mult:SI (reg:SI 61)
> (const_int 4 [0x4]))
> (reg/f:SI 62)) [3 data S4 A32])
> (mem/s:SI (plus:SI (mult:SI (reg/v:SI 59 [ i ])
> (const_int 4 [0x4]))
> (reg/f:SI 63)) [3 data S4 A32]))
> (nil)))
>
> As we can see, the compiler moves 13, and the @ of data, then
> muliplies the 13 with 4 to get the right size and then performs the 2
> loads and finally has a plus.
>
> In my port, I get:
>
> (insn 6 5 7 3 ld.c:17 (set (reg:DI 75)
> (plus:DI (reg/v:DI 73 [ i ])
> (const_int 13 [0xd]))) -1 (nil))
>
> (insn 7 6 8 3 ld.c:17 (set (reg/f:DI 76)
> (symbol_ref:DI ("data") )) -1 (nil))
>
> (insn 8 7 9 3 ld.c:17 (set (reg:DI 78)
> (const_int 3 [0x3])) -1 (nil))
>
> (insn 9 8 10 3 ld.c:17 (set (reg:DI 77)
> (ashift:DI (reg:DI 75)
> (reg:DI 78))) -1 (nil))
>
> (insn 10 9 11 3 ld.c:17 (set (reg/f:DI 79)
> (plus:DI (reg/f:DI 76)
> (reg:DI 77))) -1 (nil))
>
> (insn 11 10 12 3 ld.c:17 (set (reg/f:DI 80)
> (symbol_ref:DI ("data") )) -1 (nil))
>
> (insn 12 11 13 3 ld.c:17 (set (reg:DI 82)
> (const_int 3 [0x3])) -1 (nil))
>
> (insn 13 12 14 3 ld.c:17 (set (reg:DI 81)
> (ashift:DI (reg/v:DI 73 [ i ])
> (reg:DI 82))) -1 (nil))
>
> (insn 14 13 15 3 ld.c:17 (set (reg/f:DI 83)
> (plus:DI (reg/f:DI 80)
> (reg:DI 81))) -1 (nil))
>
> (insn 15 14 16 3 ld.c:17 (set (reg:DI 84)
> (mem/s:DI (reg/f:DI 79) [2 data S8 A64])) -1 (nil))
>
> (insn 16 15 17 3 ld.c:17 (set (reg:DI 85)
> (mem/s:DI (reg/f:DI 83) [2 data S8 A64])) -1 (nil))
>
> (insn 17 16 18 3 ld.c:17 (set (reg:DI 74)
> (plus:DI (reg:DI 84)
> (reg:DI 85))) -1 (nil))
>
>
> Which seems to be the same idea, except that constant 3 gets load up
> and a shift is performed. Is it possible that it's that that is
> causing my problem in code generation?
>
> I'm trying to figure out why my port is generating a shift instead of
> simply a mult. I actually changed the cost of shift to a large value
> and then it uses adds instead of simply a mult. I seem to think that
> this is then an rtx_cost problem where I'm not telling the compiler
> that a multiplication in this case is correct.
>
> I've been playing with rtx_cost but have been unable to really get it
> to generate the right code.
>
> Thanks again for your help and insight,
> Jc
>
> On Fri, May 8, 2009 at 5:18 AM, Paolo Bonzini wrote:
>>
>>> It seems that when set in a loop, the program is able to perform some
>>> type of optimization to actually get the use of the
gcc-4.5-20090611 is now available
Snapshot gcc-4.5-20090611 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20090611/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.5 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 148399 You'll find: gcc-4.5-20090611.tar.bz2 Complete GCC (includes all of below) gcc-core-4.5-20090611.tar.bz2 C front end and core compiler gcc-ada-4.5-20090611.tar.bz2 Ada front end and runtime gcc-fortran-4.5-20090611.tar.bz2 Fortran front end and runtime gcc-g++-4.5-20090611.tar.bz2 C++ front end and runtime gcc-java-4.5-20090611.tar.bz2 Java front end and runtime gcc-objc-4.5-20090611.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.5-20090611.tar.bz2The GCC testsuite Diffs from 4.5-20090604 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.5 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: git mirror at gcc.gnu.org
On 06/11/2009 03:07 AM, Bernie Innocenti wrote: 6) As Daniel said, we are indeed already mirroring all branches from the SVN repository. But those go to remotes/foo rather than foo, which most likely *your* git fetches aren't configured to consider. Mine are. I ignore all heads in gcc.git, and just map its remotes into my remotes by manually specifying remote.origin.fetch. Not very pretty, but it seems to produce the optimal result. See my stuff in the lower section of http://gcc.gnu.org/wiki/GitMirror for more details. Jason
