On 2017.12.14 at 21:32 +0100, Christophe Lyon wrote:
> On 14 December 2017 at 09:56, Paulo Matos wrote:
> > I got an email suggesting I add some aarch64 workers so I did:
> > 4 workers from CF (gcc113, gcc114, gcc115 and gcc116);
> >
> Great, I thought the CF machines were reserved for developpers
Hi Vladimir,
Thanks for your kind and very detailed response!
在 2017年12月15日 12:40, Vladimir Makarov 写道:
On 12/14/2017 10:18 PM, Leslie Zhai wrote:
Hi GCC and LLVM developers,
I am learning Register Allocation algorithms and I am clear that:
* Unlimited VirtReg (pseudo) -> limited or fixed
On 12/14/2017 10:18 PM, Leslie Zhai wrote:
Hi GCC and LLVM developers,
I am learning Register Allocation algorithms and I am clear that:
* Unlimited VirtReg (pseudo) -> limited or fixed or alias[1] PhysReg
(hard)
* Memory (20 - 100 cycles) is expensive than Register (1 cycle), but
it has
Hi GCC and LLVM developers,
I am learning Register Allocation algorithms and I am clear that:
* Unlimited VirtReg (pseudo) -> limited or fixed or alias[1] PhysReg (hard)
* Memory (20 - 100 cycles) is expensive than Register (1 cycle), but it
has to spill code when PhysReg is unavailable
* Fo
Joseph Myers :
> * There's an older ChangeLog style that the code doesn't handle but which
> can be found in older GCC commits, with header lines such as:
>
> Tue Dec 9 01:16:06 1997 Jeffrey A Law (l...@cygnus.com)
>
> This format sometimes has the email address surrounded by (), sometimes by
Snapshot gcc-7-20171214 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/7-20171214/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 7 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-7
On Thu, 14 Dec 2017, Eric S. Raymond wrote:
> There's a fair amount of surgery to be done still. You have 151
> mid-branch deletealls. This usually indicates that a Subversion tag or
> branch was created by mistake, and someone later tried to undo the
Some may be mistakes - I think some are del
On 14 December 2017 at 09:56, Paulo Matos wrote:
> Hello,
>
> Apologies for the delay on the update. It was my plan to do an update on
> a monthly basis but it slipped by a couple of weeks.
>
Hi,
Thanks for the update!
> The current status is:
>
> *Workers:*
>
> - x86_64
>
> 2 workers from CF (
The TZ project, which maintains the timezone database, would be a good place to
find pointers. They don't actually manage that information, but pointers to
"shape files" that translate map coordinates into the timezone identifier are
available.
paul
> On Dec 14, 2017, at 2:44 PM, Eric
For a slightly higher-quality conversion, the attribution entries in
the map file should have a third field: timezone. IANA zones are
acceptable.
This wouldn't change how commit times are stored internally, but the
Git tools use it for display in local time.
--
http://www.
It took a couple of days of struggling, but I have succeeded in
getting the GCC repo to load into reposurgeon on a 64GB machine.
In only 6 hours. :-)
In the process I found a couple of optimizations to reposurgeon that
dramatically increased its read speed and somewhat reduced maximimum
working se
On Thu, 2017-12-14 at 09:56 +0100, Paulo Matos wrote:
> Hello,
>
> Apologies for the delay on the update. It was my plan to do an update
> on
> a monthly basis but it slipped by a couple of weeks.
Thanks for working on this.
> The current status is:
>
> *Workers:*
[...snip...]
> *Builds:*
[.
Hello,
Apologies for the delay on the update. It was my plan to do an update on
a monthly basis but it slipped by a couple of weeks.
The current status is:
*Workers:*
- x86_64
2 workers from CF (gcc16 and gcc20) up and running;
1 worker from my farm (jupiter-F26) up and running;
2 broken CF (
13 matches
Mail list logo
