On 8 November 2017 at 17:30, Luis Machado wrote:
> FTR, i don't see any attached PDF's in this e-mail either.
It's possible that the pdf went to hpc-sig-dev and not toolchain.
maybe toolchain doesn't allow attachments?
___
linaro-toolchain mailing list
On 8 November 2017 at 17:19, Masaki Arai wrote:
> Hi,
>
> I am sorry for the inconvenience.
>
> #I'm not sure what is going on.
> #I can extract PDF from my first e-mail.!?
I could see the PDF on the first email, and on this one too. :)
--renato
___
l
On 29 August 2017 at 10:15, Masaki Arai wrote:
> Thank you very much for your comments and advice.
> I checked the URL．
> If there is no objection, I will consider proposing this function(and
> alternative
> appraoch) on the GCC mailing list (after improving print
> strings and actual patch files)
+linaro-toolchain, hoping to get more eyes into it.
cheers,
--renato
On 25 August 2017 at 17:59, Masaki Arai wrote:
> Hi,
>
> I extended GCC 7.1(or GCC 7.2) for `hcqc'.
> I would be grateful if you could give me a comment about whether
> this extension is acceptable and whether this extension sh
On 14 August 2017 at 10:27, Peter Smith wrote:
> Perhaps the most difficult decision is whether to support exceptions.
> For your own code, choosing not to support exceptions isn't a problem
> as both gcc and clang can compile without exception tables, however
> many C++ libraries, including the s
On 4 November 2016 at 10:56, Peter Smith wrote:
> [TCWG-901] Investigate lld as a system linker
> With downstream fixes, using lld as the system linker on a Chromebook I can :
> - Build llvm, lld and run the regression tests successfully
> - Use lld as the linker in the lnt tests successfully
W00
Hi Christophe,
Here are the commits, in order, that Adhemerval did to support 48-bit
VMA on AArch64.
r275792: [asan] Enable 48-bit VMA support on aarch64
r277137: tsan: Enable 48-bit VMA support on aarch64
r279752: msan: Enable 48-bit VMA support on aarch64
r279753: dfsan: Enable 48-bit VMA suppo
On 5 September 2016 at 19:05, wrote:
> What I need to confirm is if the Linaro 5.3 would generate such code from a
> normal block of C without any kind of asm in it? Detecting the code is part
> of the kernel...I need to figure out where it was generated. Is Linaro 5.3
> going to generate such co
On 3 June 2016 at 21:02, Rui Ueyama wrote:
>> Is the LLD community in agreement that a few core developers can and
>> will continue to block contributions, while doing all the work
>> themselves until such a day that it's deemed ready by the same
>> developers, in which time that everyone else wil
On 3 June 2016 at 18:47, Rui Ueyama wrote:
> Renato, it is not appropriate to call it my and Rafael's pet project.
Hi Rui,
I apologise, that was wrong in all levels.
I know how much other people have contributed, but these people are on
the inside already, so their contributions are more easily
On 3 June 2016 at 17:10, Rafael Espíndola wrote:
> Do keep in mind you are comparing a 11 year old project and a 11 month
> old one. There is a lot more churn on the 11 month old one.
LLD is at least 5 years old. Every time you re-write it doesn't reset history.
> Again, I am truly sorry we wer
On 3 June 2016 at 01:53, Rui Ueyama wrote:
> Not so fast to conclude that the community is not trustworthy, it doesn't
> consist of a single person or a single action.
This is not an isolated incident. This seems to be the general
behaviour around LLD, which is less so in the rest of the LLVM
pro
On 2 June 2016 at 23:22, Rafael Espíndola wrote:
> Because the patch includes way too much and doesn't explain what it is doing.
So let me get this straight: someone publishes a patch, you don't like
it, you do some private investigations and commit whatever you want
without even notifying the or
On 2 June 2016 at 20:49, Rafael Espindola via llvm-commits
wrote:
> Author: rafael
> Date: Thu Jun 2 14:49:53 2016
> New Revision: 271569
>
> URL: http://llvm.org/viewvc/llvm-project?rev=271569&view=rev
> Log:
> Start adding tlsdesc support for aarch64.
>
> This is mostly extracted from http://re
On 24 May 2016 at 18:13, Peter Smith wrote:
> I think that the bit missing from Gold is the endian reversal code for
> instructions, in ARMv7 BE8. If that is implemented then no additional
> support is needed for LTO. I would suspect that it would be much
> quicker to implement BE8 support in gold
On 24 May 2016 at 17:05, Jim Wilson wrote:
> Cisco is trying to use clang/lto on big-endian arm, which apparently
> requires gold, and gold does not support the --be8 option which is
> required for ARMv7 big-endian support. Does anyone here care about
> this?
Hi Jim,
Using Clang with LTO on ARM
== Progress ==
* Support (2/10)
- Closing some inline asm constraint bugs that were fixed or user error
- Finished PR16275
* Background (8/10)
- Code review, meetings, discussions, general support, etc.
- Lost track of how many meetings and email threads I had
- Mostly about helping newcomer
== Progress ==
* Support (2/10)
- Adding more tests to D18701, covering more cases
- Investigating PR27250 (user error)
* Buildbots (2/10)
- More work around LLDB buildbots
* Background (6/10)
- Code review, meetings, discussions, general support, etc.
- Android / AOSP discussions, meetings
== Progress ==
* Holiday (2/10)
* Support (1/10)
- Reapplying fix for PR16275 (D18701)
- Conclusion is that original approach will be the same as GCC
- Additional flags will have to be agreed upon across compilers
* Buildbot (2/10)
- Setting up LLDB buildbot with Omair
- Precarious infrastr
== Progress ==
* Support (2/10)
- Investigating a bit more PR16275, need some bigger changes in Clang/LLVM
* Background (6/10)
- Code review, meetings, discussions, general support, etc.
- Planning for a bigger team (git, Jenkins, infrastructure, documentation)
- Receiving new team members, p
= Progress ==
* Day off (2/10)
- After Connect, recuperating, jet lagging
* EuroLLVM (6/10)
- Flying Wed to Barcelona, attending conference
- Back on Saturday
* Background (2/10)
- Code review, meetings, discussions, general support, etc.
- Planning for a bigger team (git, Jenkins, infrastr
On 13 March 2016 at 18:42, Matthias Klose wrote:
> except for the LTS releases, which have a two year release cycle. 16.04 LTS
> will be the next LTS.
Damn it.
> As announced on debian-devel-announce, the freeze will be in Feb 2017.
Ok, less problematic in Debian's case.
> Ubuntu LTS users w
Hey,
Regarding the GCC ABI 5 issue, I was wondering what's the policy
behind updating packages on stable updates for both Debian and Ubuntu.
Our time frame is a bit constrained, and we definitely will have to
take some hard decisions in the next six months, so I'd like to
understand everything th
FYI,
http://lists.llvm.org/pipermail/llvm-dev/2016-March/096449.html
cheers,
--renato
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain
== Progress ==
* Support (5/10)
- Working on PR17193
- Continue review on D17141
* Background (5/10)
- Code review, meetings, discussions, general support, etc.
- Connect preparations
- GCC ABI 5 discussions
- Assessing Swift calling convention impact ARM back-end
- Interviews
On 2 March 2016 at 14:36, Edward Nevill wrote:
> It is doing cmp x2, 8 then a few instructions later, without modifying
> x2/w2 and without any intervening branch destinations it does cmp w2, 8.
> I assert the 2nd cmp w2, 8 and bls are redundant, because we know it is
> (unsigned) <= 8 already.
O
On 2 March 2016 at 11:35, Edward Nevill wrote:
> cmp x2, 8 <<< (1)
> (1) If count as a 64 bit unsigned is <= 8 then it is probably still <= 8 as a
> 32 bit unsigned.
You mean to use "cmp w2, 8" instead? Is there any difference?
> (2) Nowhere in the function does it store
== Progress ==
* Support (4/10)
- Updating patch D17141 for Darwin, resubmitting, discussions.
- Understanding PR21778, may need changes to SLP
- Benchmarking some scheduler choices for A17
* Release (1/10)
- 3.8.0 RC3 validation
* Background (5/10)
- Code review, meetings, discussions, gen
== Progress ==
* Conference (2/10)
- More EuroLLVM paper reviews, discussions
* Support (5/10)
- Looking at PR16275 (review D17141)
* Background (3/10)
- Code review, meetings, discussions, general support, etc.
- Buildbots broken, bisects, debugging
- Defining and posting Job ad (wanna wor
== Progress ==
* Conferences (4/10)
- Fosdem organisation, travel, video cutting (all lost)
- EuroLLVM paper review, schedule, meetings
* Buildbots (2/10)
- Bisecting test-suite regression
- Infrastructure clean up
- Reverting broken patches
* Support (1/10)
- Looking at some bugs, fixed P
== Progress ==
* Buildbots (2/10)
- Installing bisect tool on ARM and AArch64 bots
- SVN access broken in Austin
- Investigating failures on AArch64-only bots
* Release (2/10)
- Running 3.8.0 benchmarks
* Planning (2/10)
- Finalising the roadmap for 2016/17
* Conferences (2/10)
- Final ar
On 28 January 2016 at 22:20, Jim Wilson wrote:
> This is a minor arm port bug. Use both -mlong-calls and -pg and you get
> bl __gnu_mcount_nc
> instead of the long call to mcount that I expected. The MIPS port
> does get this right, and uses a longcall for mcount if longcalls are
> enabled.
== Progress ==
* Support (5/10)
- Bug triage: reviewing the 300+ bugs on ARM
- remaining 220 bugs are all still pertinent
* Release (2/10)
- Woes due to GCC ABI change may delay 3.8.0 release
- Tested on both ARM and AArch64 with old environment, all green.
* Background (3/10)
- Code revi
Hi Jim,
Thanks for your in-depth response!
If I got it right, the C++11 standard didn't mandate a new ABI, but
libstdc++'s ABI would break in the new standard. Our own libc++ was
created with C++11 in mind, so we required no alterations or ABI
changes.
On 20 January 2016 at 23:05, Jim Wilson w
Folks,
I'd like to know the general opinion on this:
https://llvm.org/bugs/show_bug.cgi?id=23529
From past experience, and my limited point of view, it seems that the
GCC community decided to change the ABI, plotted some runes, conjured
up a broken implementation (whose bugs people will exploit
== Progress ==
* Support (5/10)
- Bug triage: reviewing the 300+ bugs on ARM
- closing fixed ones (+35)
- adding deps for meta bugs (kernel, android, ias, chromium) (~15)
- moving to ARM/AArch64 components, etc. (~30)
- Checking a few more kernel patches for Clang support with Arnd
* P
== Progress ==
* Support (2/10)
- Having a go at PR25722, too hacky for a feature that can
be easily worked around.
- Reviewing some kernel issues with Arnd
* Planning (6/10)
- Drafting 2 year plans for LLVM
* Background (2/10)
- Code review, meetings, discussions, general support, etc.
expectations and overall usage are
completely different.
> 4. Certain links (e.g Roadmap) at
> https://wiki.linaro.org/WorkingGroups/ToolChain/LLVM
> ask for login credentials. Any comment on how to obtain the permission?
>
> You will need to ask either to Ryan Arnold or Renato
&g
== Progress ==
* Holiday (2/10)
* Release (1/20)
- 3.7.1 Final, all green
* Maintenance (5/10)
- Fixing PR25720
- Bug cleaning: PR18921, PR13259, PR13138, PR12926,
PR17963, PR18187, PR22692
- Checked strided vectorizer on ToT, EEMBC 2x geomean!
* Background (2/10)
- Code r
== Progress ==
* Ill (4/10)
* Support (1/10)
- Bugzilla issues (PR20490, PR24635, PR24350, PR20025, PR25720, PR25722)
* Benchmarks (1/10)
- Checking some previous benchmark results on A57
* Buildbots (2/10)
- Getting AArch64 full bot back to rotation, since it's stable now
- Re-enabling lib
== Progress ==
* Support (6/10)
- Trying to add ADRL support in the assembler: http://llvm.org/PR24350
* Buildbots (1/10)
- Some breakages, nothing serious
* Background (3/10)
- Code review, meetings, discussions, general support, etc.
- Working on 2016's plan
___
== Progress ==
* Buildbots (1/10)
- Bisecting breakages, testing ASAN patches
* Release (1/10)
- Testing 3.7.1-RC1, all green
* Benchmarks (3/10)
- Updating some benchmarks results, running EEMBC on HiKey
- Investigating old performance reports
* Background (5/10)
- Code review, meetings,
On 17 November 2015 at 22:10, Pinski, Andrew
wrote:
> Or better yet use ifunc directly to check on them.
I was going to say, this looks like the kind of thing IFUNC was designed for. :)
--renato
___
linaro-toolchain mailing list
linaro-toolchain@lists.
== Progress ==
* Buildbots (4/10)
- Found culprit for self-hosting breakages
- Bot didn't get right because of dirty builds
- Moving all self-hosting bots to clean builds (~3h)
- More work on MIPS patch breaking self-hosting
- Several breakages and bisections
- Adding first cloud (Scalew
== Progress ==
* Buildbots (5/10)
- Some broken bots, bisecting, etc
- Helping a MIPS patch pass on ARM bot
* Maintenance (2/10)
- SciMark2 seems not to be unstable or slow any more in ARM64
- Some more investigations on Loop Load Elimination
- Profiling bigfib on APM and HiKey
* Background
== Progress ==
* Infrastructure (4/10)
- Installing Ubuntu on APM (perf works!)
- Setting up a HiKey for in-order perf
- Helping Milosz with crashing HiKeys
* Maintenance (4/10)
- Helping ARM with test-suite patches (D14061)
- Investigating read-after-read dependency (D13259)
* Background (
== Progress ==
* Maintenance (5/10)
- Investigating some LivermoreLoops that don't vectorise
- Reducing cases to single specific causes
* Background (5/10)
- Code review, meetings, discussions, general support, etc.
- More code of conduct stuff, license change to Apache 2
- Following up on s
== Progress ==
* Libraries (3/10)
- Back investigating libc++ issues in AArch64 buildbot
-
http://buildmaster.tcwglab.linaro.org/builders/clang-cmake-aarch64-prototype
- Trying to solve the rt/unw/c++ library entanglement in the driver
* Buildbots (1/10)
- Trying to perf an application on
== Progress ==
* Maintenance (1/10)
- Removed redundant DefaultCPU in ARMTargetInfo
* Buildbots (4/10)
- Looong discussions upstream about stability of buildbots
- Trial with IFC6410 marginally successfull, still not good enough, aborting
- Moved benchmark buildbot to silent (avoid unnecessar
== Progress ==
* Monday off (2/10)
* Buildbot (6/10)
- Investigating sanitizer crash in Thumb2+NEON
- Testing IFC6410 with Linaro 15.09
- CPUs good, 1.7GHz on all cores, stable, cool
- Not enough space on local (fast) flash
- USB stick stable, but slow (3h vs 2h on Chrome 2)
- USB d
== Progress ==
* Buildbot (2/10)
- Investigating sanitizer crash in AArch64
- Found: 247264, reverted 247674
- Other sanitizer crashes
* Maintenance (4/10)
- More VMA investigations, discussions
- More TargetTuple discussions
- Investigating BLX bug on ARMv4 (PR24858)
* Background (4/10)
== Progress ==
* Libraries (1/10)
- Working on getting the libc++ tests green
* Maintenance (6/10)
- Working with Vinicius on the gnueabi memcpy issue
- More TargetTuple/TargetParser discussions
- More sanitizers discussions, patch reviews
* Background (3/10)
- Code review, meetings, discus
== Progress ==
* Holidays (4/10)
* Buildbots (2/10)
- Several breakages, Clang alignment issue sill breaking
self-hosted bots...
* Maintenance (2/10)
- Backtracks on the TargetParser, code heavily modified,
discussions ensued.
- Helping Vinicius with __aeabi_memcpy in the kernel
* Rele
== Progress ==
* Maintenance (CARD-1833 2/10)
- Fixing libc++abi build on AArch64
- Trying to remove a hack in ARMTargetInfo about default CPUs
- Bisecting PR24292
- Working with ARM to fix it, backport
* Buildbots (CARD-1823 8/10)
- Working with Adhemerval on VMA 42bits sanitizer
- Setting
== Progress ==
* Buildbots (CARD-1823 6/10)
- Setting up new APMs
- Running around for a decent UEFI, Kernel, Distro
- Testing different builds, configurations
- Managed to get one APM doing the test-suite *only*! sigh...
- http://buildmaster.tcwglab.linaro.org/builders/clang-cmake-aarch64-
== Progress ==
* Performance (CARD-1832 3/10)
- Profiling SPEC2k mesa, found some issues
- Investigating r232513, unlikely the culprit, but interesting case
* Releases (CARD-1431 1/10)
- Spinning 3.7.0 RC2
* Buildbots (CARD-1823 4/10)
- Setting up new APMs
- Dealing with ASAN/TSAN bot break
== Progress ==
* Performance (CARD-1832 1/10)
- Checking differences of PostRAListSched on OOO ARM cores
- Not many changes, ignoring for now
* Maintenance (CARD-1833 4/10)
- Building libc++/abi/unwind in LLVM/Clang tree
- Getting -Wa,-mfpu patches in, last important Clang driver ARM bug
-
== Progress ==
* Maintenance (CARD-1833 5/10)
- Building libc++/abi/unwind in LLVM/Clang tree
- Fixing some build errors (D11486)
- Addressing comments to submissions from last week
- Committing approved ones
- Re-working the others
* Releases (CARD-1431 1/10)
- Building 3.7.0-RC1 on
== Progress ==
* Maintenance (CARD-1833 4/10)
- Clang driver:
- Passing -Wa,-mfpu and friends to assembler (D11147, D11148)
- Passing -I to assembler (D11185)
- Don't include libgcc/asm if using libunwind/libc++abi (D11153)
- Asm warnings:
- Trying again to look for a way to disable asm
== Progress ==
* Releases (CARD-1431 1/10)
- Released 3.6.2-final
* Maintenance (CARD-1833 5/10)
- Reducing runtime of some benchmarks in LLVM's
test-suite by getting rid of millions of useless
fprintf calls.
- Working on https://llvm.org/PR20700 some more
* Background (4/10)
- Code re
== Progress ==
* Maintenance (CARD-1833 4/10)
- ADD/SUB with negative immediates solved by a year old
patch from ARM, sigh. On to the next bug... :(
- Working on https://llvm.org/PR20700
* Buildbots (CARD-1823 2/10)
- Moving benchmark bot to CMake, fixing deepcopy bug in
environment that
== Progress ==
* Maintenance (CARD-1833 4/10)
- Found the trail on the ADD/SUB with negative immediate
- Submitting RFC for discussion (http://llvm.org/PR20978)
- Bugzilla farming
- More LNT investigations (http://llvm.org/perf/ unstable)
* Releases (CARD-1431 1/10)
- Building, testing and u
On 24 June 2015 at 14:50, Adhemerval Zanella
wrote:
> I tried some of author advices getting very good results. Basically I
> moved to optimized clang build, changed to gold linker and used another
> memory allocator than system glibc one. Results in build time for all
> the clang/llvm toolchain
== Progress ==
* Maintenance (CARD-1833 1/10)
- Looking at AArch64 ADD->SUB a bit more
* Buildbots (CARD-1823 6/10)
- Moving LNT bot to CMake
- Setting up LLD and LLDB buildbots
- Investigating LNT instability / Perf buildbot
* Background (3/10)
- Code review, meetings, discussions, etc.
-
== Progress ==
* Maintenance (CARD-1833 2/10)
- Initial work on ADD<->SUB for negative imm in asm
* Buildbots (CARD-1823 6/10)
- Adding test-suite to CMake buildbot (D10244)
- Bisecting broken self-hosting vfp3 bots
* Background (2/10)
- Code review, meetings, discussions, etc.
- Some more
On 3 June 2015 at 10:24, Yury Gribov wrote:
> People have been pointing at clang-format recently but AFAIK support for GNU
> formatting (used in GCC and Binutils) is still infant.
Patches welcome! :)
More seriously, we also recommend clang-format on all LLVM projects,
though some formatting for
== Progress ==
* Bank Holiday (2/10)
* Maintenance (CARD-1833 6/10)
- Finished all FIXMEs in LLVM and Clang
- Working on ASM warnings
* Background (2/10)
- Code review, meetings, discussions, etc.
- Updated arm-bots.html to account for build num, commit range
== Plan ==
* Continue working
== Progress ==
* Releases (CARD-1431 1/10)
- Final ARM/AArch64 3.6.1
* Automation Framework (CARD-1378 1/10)
- More meetings with Lab about infrastructure
* Maintenance (CARD-1833 5/10)
- Working on FIXMEs to TargetParser
* Buildbots (CARD-1823 1/10)
- Bisecting self-hosting failure on thum
== Progress ==
* Releases (CARD-1431 4/10)
- Testing 3.6.1 on ARM, green
- Re-flashing LLVM APM due to crash
- Testing 3.6.1 on AArch64, green
* Maintenance (CARD-1833 2/10)
- Fixing enum vs. macro conflicts (PR23482)
- Working on FIXMEs to TargetParser (Triple)
* Background (4/10)
- Code
== Progress ==
* Public holiday on Monday (2/10)
* Automation Framework (CARD-1378 1/10)
- Debugging / Setting up VPN to the lab
- Investigating APM crash
* Releases (CARD-1431 1/10)
- Reviewing patches for 3.6.1, some failures
* Maintenance (CARD-1833 3/10)
- Unifying ARM target parser
*
== Progress ==
* Automation Framework (CARD-1378 2/10)
- Interface with the lab/system teams (plan, schedule)
- Saving the bridge's image into an SD card
* Maintenance (CARD-1833 6/10)
- Unifying target parser (PR20787 / D9435)
* Background (2/10)
- Code review, meetings, discussions, etc.
== Progress ==
* EuroLLVM (4/10)
* Buildbots (CARD-1823 4/10)
- Installing CMake 3.2 / Ninja 1.5 on all bots
- Fixing broken bots
- Investigating broken LNT in llvm.org
* Background (2/10)
- Code review, meetings, discussions, etc.
- Catching up after holidays
== Plan ==
* Continue target
== Progress ==
Friday holiday
* Automation Framework (CARD-1378 2/10)
- Power cut in the office
- Fixing gateway, rebooting machines
- Mob management
* LLVM ARM Maintenance (CARD-1833 2/10)
- ARMTargetParser review
* Background (4/10)
- Code review, meetings, discussions, etc.
- All L
== Progress ==
* Automation Framework (CARD-1378 5/10)
- Moving LLVM lab into llvm.tcwglab subnet
- Passing down my knowledge to the lab team
- Helping them set up the new builders
* Background (5/10)
- Code review, meetings, discussions, etc.
- Upgrading APM's compiler/binutils
- Writing L
== Progress ==
* Thursday off (2/10)
* Buildbots (CARD-1823 1/10)
- Fixing llvm-apm-01 (disk problem)
- Fixing llvm-d01-04 (my bad)
* Releases (CARD-1431 1/10)
- Spinning release 3.5.2 RC1, all green
* Automation Framework (CARD-1378 3/10)
- A lot of time wasted in infra shenanigans
* Back
Yeah, but we're not using that wiki anymore. Just move the stuff across and
link from the home page.
On 17 Mar 2015 19:26, "Omair Javaid" wrote:
> I am writing them here:
>
> https://wiki.linaro.org/WorkingGroups/ToolChain/LLDB
>
> Shouldnt these be public?
>
&g
On 17 March 2015 at 00:42, Omair Javaid wrote:
> -- Written wiki pages for LLDB developer process [1/10]
Where?
We need to move it here:
https://collaborate.linaro.org/display/LLVM/LLVM@Linaro
cheers,
--renato
___
linaro-toolchain mailing list
lin
== Progress ==
* Automation Framework (CARD-1378 4/10)
- Restarting more dead machines
- Discussing more infrastructure
- Investigating PDU deamon
* Maintenance (CARD-1833 4/10)
- Making the case for all table-gen files to be built
- This would allow us to create TargetDescription
- Which
== Progress ==
* Automation Framework (CARD-1378 5/10)
- Setting up new servers
* Background (5/10)
- Code review, meetings, discussions, etc.
- Updating some LLVM dev scripts
- Adding tools checks to LNT
- EuroLLVM Paper selection
- LLDB/ARM meetings
- Bisecting lots of failures in all bo
== Progress ==
* Releases (CARD-1431 2/10)
- Spinning RC4, final, all green
* Buildbots (CARD-1823 1/10)
- Adding new quick Thumb2 non-NEON bot
- Adding new full self-hosting Thumb2 bot
* Libraries (CARD-1831 1/10)
- Trying to build a soft-float compiler-rt test-suite
* Sanitizers for AArch
== Progress ==
* Rebooting brain after Connect (2/10)
* Friday off (2/10)
* Release 3.6 (CARD-1431 1/10)
- Spinning RC3, RC4
- Long discussions about Phoronix benchmark regressions
* Buildbots (CARD-1823 2/10)
- Buildbot cleanup and reshape
- Adding two new internal buildbots
- Investigatin
== Progress ==
* Automation Framework (CARD-1378 1/10)
- Restarting build-02
- Trying new way to setup juno-01, failed
- Moving gateway-config to new private git server
* Release 3.6 (CARD-1431 4/10)
- Found NEON regression, reverting patches
- Setting up more new NEON buildbots
* Libraries
== Progress ==
* Automation Framework (CARD-1378 1/10)
- Setting up new box
* Release 3.6 (CARD-1431 5/10)
- Looking for the patch that introduced a major NEON regression since December
* Background (4/10)
- Code review, meetings, discussions, etc.
- More Jira farming...
- Some EuroLLVM pap
== Progress ==
* Automation Framework (CARD-1378 2/10)
- Rebooting machines, again...
- Fiddling with bugzilla, wiki
* Release 3.6 (TCWG-575 5/10)
- Investigating ARMv7 bootstrapping failures
- Rebuilding manually with cmake, as autoconf build is bogus
- Turns out wasn't autoconf, but a NEON
== Progress ==
* Tuesday sick
* Automation Framework (CARD-1378 5/8)
- Fixing more crashed Junos
- Working on QEMU VMs on gateway (buildbot master, nagios)
- Finalising server purchase, building new rack
* Release 3.6 (TCWG-575 1/8)
- AArch64 built and tested, all green.
- ARM is broken, in
== Progress ==
* Automation Framework (CARD-1378 2/10)
- DNS requests (Hetzner, bridge), new APM
- Following up on purchase of new server, new rack, UPS
* Buildbots (TCWG-76 4/10)
- Enabling swap on dragon boards (local bots)
- Investigating AArch64 RT failure, XFAIL like ARM
- AARch64 full
== Progress ==
1 day week:
* Automation Framework (CARD-1378 1/2)
- Resetting APMs and Junos that fell during the holidays
* Release 3.5.1 (TCWG-477 1/2)
- Testing RC2, all good
== Plan ==
* improve buildbots (swap, verbose, libs)
* fix libc++abi NEON/VFPv3 unwinder
* purchase new builder, p
== Progress ==
* Friday off
* Automation Framework (CARD-1378 2/8)
- Writing up best practices, lab structure, etc
- Removing port forwards, private keys from the lab
- IT ticket to remove tcwg-sysadmin from public git
* Toolchain (CARD-862 1/8)
- Fixed compiler-rt problem on AArch64 build
== Progress ==
* Automation Framework (CARD-1378 5/10)
- Getting around fastboot issues on Dragon
- Upgrading Dragons to 3.17 / utopic
- Testing stability of Dragon boards once again
- Writing best practices, and lab setup documents
- Liaising with ST and Qualcomm to stress their boards
* Bu
On 11 December 2014 at 14:36, Nicolas Dechesne
wrote:
> and it's quite consistent over multiple runs. So it's much more than
> 40% actually.. if we apply these ratios we get theoretical numbers
> that makes more sense... the ifc6410 should definitely be faster than
> panda..
Nice!
So, we can do
Folks,
Me and Nick have been back and forth with the IFC6410, using Linaro's
utopic Ubuntu + 3.17 kernel, and I can now declare it stable enough to
run toolchain tests, maybe not yet builds.
The reason is that the kernel, although stable, is only just because
it throttles speed to a minimum. So,
On 7 December 2014 at 10:13, Christophe Lyon wrote:
> I was thinking about asking a single new mailing-list (eg
> tcwg-commits) and send commit emails to that list for all ours repos,
> instead of having a list per repo to which interested team members
> would have to subscribe.
I think it makes
== Progress ==
* Automation Framework (CARD-1378 5/8)
- Re-adding Junos and D01s to the rack
- Planning access from remote servers
- Following up new rack setup
- Moving lab bridge to a VM
- Re-checking all boards for stability
- Working on the dragon boards to get them stable
* Background
== Progress ==
* 2 days sick
* Lab move (2/6)
* Buildbots (TCWG-76 2/6)
- Created a buildmaster at Linaro to help local development
- Put a dragonboard as a slave, which lasted 2 days up
* Background (2/6)
- Code review, meetings, discussions, etc.
== Plan ==
* I have no idea
== Progress ==
Lab move (for the last 11 days non-stop)
== Plan ==
Sleep
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain
== Progress ==
Lab move
== Plan ==
Lab move
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain
== Progress ==
* Automation Framework (CARD-1378 4/8)
- Moving TCWG machines to the new office
- Setting up new rack, stacking boards, etc.
- Setting up Junos
* Buildbots (TCWG-76 2/8)
- Moving buildbots to the new office
- Checking libcxxabi failure, marking as XFAIL
- All bots green
* Ba
== Progress ==
* US LLVM Dev Mtg (4/6)
* Buildbots (TCWG-76 1/6)
- Fixing last bugs of the libcxx bot
- One last failure being looked at
* Background (1/6)
- Code review, meetings, discussions, etc.
- Meeting with Google/ARM/Qualcomm about Android+LLVM
* Two days off
== Plan ==
* Investig
== Progress ==
* Automation Framework (CARD-1378 1/10)
- Setting up Junos with ARM
* Toolchain (CARD-862 1/10)
- Some progress on fpu parser issue
- Produced a lot more work for the near future
* Buildbots (TCWG-76 4/10)
- Setting up a libc++ buildbot, working on reducing failures
- Some bo
== Progress ==
* Linux Plumbers (6/10)
- Attended conference, Android/Tools/LLVM tracks
- Presented 2 talks (GCC+LLVM and LLVM+ARM)
* Buildbots (TCWG-76 2/10)
- Made the Compiler-RT bot green! Now on to the libc++ one
* Background (2/10)
- Code review, meetings, discussions, etc.
- Internet
1 - 100 of 247 matches
Mail list logo
