On July 9, 2018 10:20:39 PM GMT+02:00, "Eric S. Raymond"
wrote:
>Richard Biener :
>> 12 hours from remote I guess? The subversion repository is available
>through rsync so you can create a local mirror to work from (we've been
>doing that at suse for years)
>
>I'm saying I see rsync plus local c
On 07/09/2018 07:22 PM, Soul Studios wrote:
On 07/05/2018 05:14 PM, Soul Studios wrote:
Simply because a struct has a constructor does not mean it isn't a
viable target/source for use with memcpy/memmove/memset.
As the documentation that Segher quoted explains, it does
mean exactly that.
Some
On 07/05/2018 05:14 PM, Soul Studios wrote:
Simply because a struct has a constructor does not mean it isn't a
viable target/source for use with memcpy/memmove/memset.
As the documentation that Segher quoted explains, it does
mean exactly that.
Some classes have user-defined copy and default c
On Jul 9, 2018, Jeff Law wrote:
> On 07/09/2018 01:57 PM, Eric S. Raymond wrote:
>> Jeff Law :
>>> I'm not aware of any such merges, but any that occurred most likely
>>> happened after mid-April when the trunk was re-opened for development.
>> I'm pretty certain things were still good at r2560
Richard Biener :
> 12 hours from remote I guess? The subversion repository is available through
> rsync so you can create a local mirror to work from (we've been doing that at
> suse for years)
I'm saying I see rsync plus local checkout take 10-12 hours. I asked Jason
about this and his respon
Jeff Law :
> > I'm pretty certain things were still good at r256000. I've started that
> > check running. Not expecting results in less than twelve hours.
> r256000 would be roughly Christmas 2017. I'd be very surprised if any
> merges to the trunk happened between that point and early April.
On July 9, 2018 9:19:11 PM GMT+02:00, e...@thyrsus.com wrote:
>Last time I did a comparison between SVN head and the git conversion
>tip they matched exactly. This time I have mismatches in the following
>files.
>
>libtool.m4
>libvtv/ChangeLog
>libvtv/configure
>libvtv/testsuite/lib/libvtv.exp
>lt
Florian Weimer :
> * Eric S. Raymond:
>
> > The bad news is that my last test run overran the memnory capacity of
> > the 64GB Great Beast. I shall have to find some way of reducing the
> > working set, as 128GB DD4 memory is hideously expensive.
>
> Do you need interactive access to the machine
On 07/09/2018 01:57 PM, Eric S. Raymond wrote:
> Jeff Law :
>>> There are brute-force ways to pin down such malformations, but none of
>>> them are practical at the huge scale of this repository. The main
>>> problem here wouldn't reposurgeon itself but the fact that Subversion
>>> checkouts on a
Bernd Schmidt :
> On 07/09/2018 09:19 PM, Eric S. Raymond wrote:
> > Last time I did a comparison between SVN head and the git conversion
> > tip they matched exactly. This time I have mismatches in the following
> > files.
>
> So what are the diffs? Are we talking about small differences (like o
Jeff Law :
> > There are brute-force ways to pin down such malformations, but none of
> > them are practical at the huge scale of this repository. The main
> > problem here wouldn't reposurgeon itself but the fact that Subversion
> > checkouts on a repo this large are very slow. I've seen a single
* Eric S. Raymond:
> The bad news is that my last test run overran the memnory capacity of
> the 64GB Great Beast. I shall have to find some way of reducing the
> working set, as 128GB DD4 memory is hideously expensive.
Do you need interactive access to the machine, or can we run the job
for you
On 07/09/2018 09:19 PM, Eric S. Raymond wrote:
> Last time I did a comparison between SVN head and the git conversion
> tip they matched exactly. This time I have mismatches in the following
> files.
So what are the diffs? Are we talking about small differences (like one
change missing) or large-
On 07/09/2018 01:19 PM, Eric S. Raymond wrote:
> Last time I did a comparison between SVN head and the git conversion
> tip they matched exactly. This time I have mismatches in the following
> files.
>
> libtool.m4
> libvtv/ChangeLog
> libvtv/configure
> libvtv/testsuite/lib/libvtv.exp
> ltmain.s
Last time I did a comparison between SVN head and the git conversion
tip they matched exactly. This time I have mismatches in the following
files.
libtool.m4
libvtv/ChangeLog
libvtv/configure
libvtv/testsuite/lib/libvtv.exp
ltmain.sh
lto-plugin/ChangeLog
lto-plugin/configure
lto-plugin/lto-plugin
On Mon, 2018-07-09 at 06:16 -0400, Eric S. Raymond wrote:
> Janus Weil :
> > > The bad news is that my last test run overran the memnory
> > > capacity of
> > > the 64GB Great Beast. I shall have to find some way of reducing
> > > the
> > > working set, as 128GB DD4 memory is hideously expensive.
On Mon, 2018-07-09 at 10:57 -0600, Jeff Law wrote:
> On 07/09/2018 10:53 AM, Janus Weil wrote:
> > 2018-07-09 18:35 GMT+02:00 Eric S. Raymond :
> > > David Edelsohn :
> > > > > The truth is we're near the bleeding edge of what conventional tools
> > > > > and hardware can handle gracefully. Most j
On Mon, Jul 9, 2018 at 12:35 PM Eric S. Raymond wrote:
>
> David Edelsohn :
> > > The truth is we're near the bleeding edge of what conventional tools
> > > and hardware can handle gracefully. Most jobs with working sets as
> > > big as this one's do only comparatively dumb operations that can be
On 07/09/2018 10:53 AM, Janus Weil wrote:
> 2018-07-09 18:35 GMT+02:00 Eric S. Raymond :
>> David Edelsohn :
The truth is we're near the bleeding edge of what conventional tools
and hardware can handle gracefully. Most jobs with working sets as
big as this one's do only comparativel
2018-07-09 18:35 GMT+02:00 Eric S. Raymond :
> David Edelsohn :
>> > The truth is we're near the bleeding edge of what conventional tools
>> > and hardware can handle gracefully. Most jobs with working sets as
>> > big as this one's do only comparatively dumb operations that can be
>> > parallelli
David Edelsohn :
> > The truth is we're near the bleeding edge of what conventional tools
> > and hardware can handle gracefully. Most jobs with working sets as
> > big as this one's do only comparatively dumb operations that can be
> > parallellized and thrown on a GPU or supercomputer. Most job
On Mon, Jul 9, 2018 at 6:16 AM Eric S. Raymond wrote:
>
> Janus Weil :
> > > The bad news is that my last test run overran the memnory capacity of
> > > the 64GB Great Beast. I shall have to find some way of reducing the
> > > working set, as 128GB DD4 memory is hideously expensive.
> >
> > Or ma
Janus Weil :
> > The bad news is that my last test run overran the memnory capacity of
> > the 64GB Great Beast. I shall have to find some way of reducing the
> > working set, as 128GB DD4 memory is hideously expensive.
>
> Or maybe you could use a machine from the GCC compile farm?
>
> Accordin
On 07/09/2018 02:27 AM, Eric S. Raymond wrote:
> The bad news is that my last test run overran the memnory capacity of
> the 64GB Great Beast. I shall have to find some way of reducing the
> working set, as 128GB DD4 memory is hideously expensive.
Hello.
I can help with by running a conversion o
On 07/09/2018 09:50 AM, Hrishikesh Kulkarni wrote:
> Hi,
>
> The command line option -gimple-stats will dump the statistics of
> gimple statements.
>
> For example:
>
> $ ../stage1-build/gcc/lto-dump test_hello.o -gimple-stats
>
> will dump:
>
> GIMPLE statements
> Kind Stmts
2018-07-09 2:27 GMT+02:00 Eric S. Raymond :
> There is good news bad news on the GCC repository conversion.
>
> The good news is that I have solved the only known remaining technical
> problem in reposurgeon blocking the conversion. I've fixed the bug
> that prevented execute permissions from bein
26 matches
Mail list logo
