* TCWG-72 (2/10)
- Added new target hook to generate target-specific divmod libfunc
- Builds cleanly now on x86_64, arm and arm-linux-gnueabihf
- Sent to tcwg list for review
* LTO spec2k6 build (2/10)
- Built speck26 with LTO
* Target hook (4/10)
- Completed with ASM_OUTPUT_LABEL_REF
- In progress - SIZE_ASM_OP to data hook, ASM_OUTPUT_SIZE_DIRECTIVE,
ASM_OUTPUT_MEASURED_SIZE
* Benchmarking (1/10)
- tcwg-319: Job in progress for fp benchmarks with patch
- tcwg-310 (loop peeling): Submitted job for running 252.eon
- Both the jobs failed due to lab downtime, need to be re-run.
- Received job template from Bernie for running benchmarks on cortex-a15.
* Misc (1/10)
- Meetings
== Next Week ==
- Continue benchmarking spec2k6 with LTO
- Look at bugs exposed by speck2k6 LTO build
- Benchmarking tcwg-319, tcwg-310
== This week ==
* TCWG-317 - Exploit wide add operations when appropriate for Aarch32 (0/10)
- No comments/review upstream will ping for update
* TCWG-316 - Exploit vector multiply by scalar instructions (4/10)
- Code improvements will require standard name for vectorizer and new
patterns
- On hold until GCC 6 is released
* Bugzilla 68543 - [AArch64] Implement overflow arithmetic standard
names (3/10)
- Initial investigation
* Bugzilla 68532 - [ARM] Incorrect code result on arm big endian (2/10)
- Investigation into understanding how vectorizer represents lanes vs
arm big endian back end
- Solution suspended until I can coordinate with Charlie
* Misc (1/10)
- Conference calls
== Next week ==
* Bugzilla 68543 - Implement add and subtract overflow operations and test
* TCWG-317 - Ping upstream and respond to upstream feedback
* Bugzilla 68532 - Coordinate with Charlie
== 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 libc++ prototypes on local master
- Bisecting broken test-suite
- Another power cut in the office sent all the bots down... :(
* Background (2/10)
- Code review, meetings, discussions, general support, etc.
- Validating some old sanitizer bugs
- FOSDEM admin
* One day off on Monday.
# Progress #
* Answer ST questions about supporting multi-arch with ST jtag probe.
[1/10]
* TCWG-171, Enable gdb core file tests when testing remotely, [3/10].
Ongoing.
* Run gdb.base/sizeof.exp with board having gdb,noinferiorio. Done.
[1/10]
* TCWG-460, mutli-arch follow-up work, teach AArch64 GDBserver
understand ARM breakpoint instructions. Patch is approved. [2/10].
* TCWG-424, fail in gdb.base/random-signal.exp. [1/10] Root cause is
identified, need to figure out how to fix it in next step.
* Review ARM GDBserver software single step patch V4.
# Plan #
* TCWG-171, TCWG-156, TCWG-424.
* Review ARM GDBserver software single step patch V5, which should be
the final version, I hope.
--
Yao
== Progress ==
* Validation
- a few cleanup patches in the comparison scripts
- contribute to debug of ptys allocation problems:
the tests pass when executed outside of our schroots.
- improvements in the reports from the validation
done in the ST Compute Farm
- reported a few regressions
* GCC
- cleanup patch for target attributes tests,
- pr68620 (fp16 transfers in big-endian mode)
* Misc (conf calls, meetings, emails, ....)
== Next ==
* Validation: monitoring, improvements
* GCC: bug fixes, cleanup
Hi Linaro Toolchian Group,
I am new to GCC development and have some basic question on its development
process.
Could you please give some insight on below questions. (Apology if they are
very trivial).
I have read https://gcc.gnu.org/develop.html
If I am correct, gcc trunk is on gcc 6.0.0 (stage 3) at present and will
becomes 6.0.1 (regression fix only) in January 2016.
gcc 6.0.1 will be released as gcc 6.1.0 in April, 2016 and from there
onwards gcc 6 release branch will start.
However, There is also a gcc 5 branch in parallel whose current version is
5.2.1 and will be released as gcc 5.3 soon.
Hopefully gcc 5.3 would be the last release in gcc 5 series. (Please
correct me if I am wrong).
[Questions]
1. What is the difference between experimental(gcc 6.0.0 stage 3) & gcc
release branch (gcc 5.2.1)?
Is there any rule which decides which changes will go where?
In case, I have some patches for new aarch64 processor at present, in
which branch these changes would be merged (assuming they passes reviews)?
2. How is the subversion of release branches are decided? Is it correct to
say that there will be always 3 subversion of any release branch (e.g. gcc
5.1, gcc 5.2 & gcc 5.3)?
3. What is the working model between GNU GCC and Linaro GCC? Does Linaro
directly accept patches? or they need to go to GNU GCC first?
Thanks in advance for your time.
with regards,
Virendra Kumar Pathak
--
with regards,
Virendra Kumar Pathak
Keeping linaro-toolchain in the loop.
Robert
---------- Forwarded message ----------
From: Robert Schiele <rschiele(a)gmail.com>
Date: Thu, Dec 3, 2015 at 4:44 PM
Subject: Re: Lost upstream patch in merge from gcc-5-branch to
linaro/gcc-5-branch
To: Yvan Roux <yvan.roux(a)linaro.org>
Hi Yvan,
On Thu, Dec 3, 2015 at 1:25 PM, Yvan Roux <yvan.roux(a)linaro.org> wrote:
> This fix on gcc-5-branch doesn't apply on Linaro 5 branch, because we
> have backported trunk revision 222624 (which renames maybe_fma to
> coumpound_p) into it. So, our branch as the same code as trunk one
> regarding aarch64_rtx_costs. Do you experiment any issues related to
> this change ?
No issues. This was just a theoretical thought and through our CI
build I learned exactly what you just told me the hard way now.
Sorry for the noise.
Robert
abe.sh in the ABE framework accepts a parameter to set the wget timeout
when it fetches snapshots (default 10s); however that parameter has an
upper threshold of 10 seconds (condition at line 996 only sets timeout
to specified value if < 11). Is this intentional? It seems like it would
make more sense to give it a floor instead of a ceiling or perhaps not
limit the range of potential values at all.
Best regards,
Chris Roberts
hi guys,
sorry maybe my question is stupid as i am not a toolchain guy.
i have no idea why ld.so search so many paths. for example, put
"-rpath" with /home/cnb1szh/test in a simple test program. then during
dynamic linking at runtime, we get the below linking debug
information:
30693: find library=libmytest.so [0]; searching
30693: search path=/home/cnb1szh/test/tls/v7l/neon/vfp:/home/cnb1szh/test/tls/v7l/neon:/home/cnb1szh/test/tls/v7l/vfp:/home/cnb1szh/test/tls/v7l:/home/cnb1szh/test/tls/neon/vfp:/home/cnb1szh/test/tls/neon:/home/cnb1szh/test/tls/vfp:/home/cnb1szh/test/tls:/home/cnb1szh/test/v7l/neon/vfp:/home/cnb1szh/test/v7l/neon:/home/cnb1szh/test/v7l/vfp:/home/cnb1szh/test/v7l:/home/cnb1szh/test/neon/vfp:/home/cnb1szh/test/neon:/home/cnb1szh/test/vfp:/home/cnb1szh/test
(RPATH from file ./hello)
30693: trying file=/home/cnb1szh/test/tls/v7l/neon/vfp/libmytest.so
30693: trying file=/home/cnb1szh/test/tls/v7l/neon/libmytest.so
30693: trying file=/home/cnb1szh/test/tls/v7l/vfp/libmytest.so
30693: trying file=/home/cnb1szh/test/tls/v7l/libmytest.so
30693: trying file=/home/cnb1szh/test/tls/neon/vfp/libmytest.so
30693: trying file=/home/cnb1szh/test/tls/neon/libmytest.so
30693: trying file=/home/cnb1szh/test/tls/vfp/libmytest.so
30693: trying file=/home/cnb1szh/test/tls/libmytest.so
30693: trying file=/home/cnb1szh/test/v7l/neon/vfp/libmytest.so
30693: trying file=/home/cnb1szh/test/v7l/neon/libmytest.so
30693: trying file=/home/cnb1szh/test/v7l/vfp/libmytest.so
30693: trying file=/home/cnb1szh/test/v7l/libmytest.so
30693: trying file=/home/cnb1szh/test/neon/vfp/libmytest.so
30693: trying file=/home/cnb1szh/test/neon/libmytest.so
30693: trying file=/home/cnb1szh/test/vfp/libmytest.so
30693: trying file=/home/cnb1szh/test/libmytest.so
but we don't have /home/cnb1szh/test/tls/, /home/cnb1szh/test/v7l/,
/home/cnb1szh/test/vfp/, /home/cnb1szh/test/neon/, why does the ld.so
search so many paths?
-barry
Hi,
I found that with the merge
commit ac19ac6481a3f326d9f41403f5dadab548b2c8a6
Author: Yvan Roux <yvan.roux(a)linaro.org>
Date: Wed Sep 16 10:57:42 2015 +0200
Merge branches/gcc-5-branch rev 227732.
Change-Id: I2f59904b28323b1c72a8cf1bd62c9e460d95bcea
the following branch that was within merge range on gcc-5-branch was
lost on the linaro branch:
commit b45a5cf7c1544f95578e823e25402b58fb3fbedd
Author: nsz <nsz@138bc75d-0d04-0410-961f-82ee72b054a4>
Date: Tue Aug 4 16:49:54 2015 +0000
Fix broken backport patch.
gcc:
Backport from mainline:
2015-08-04 Szabolcs Nagy <szabolcs.nagy(a)arm.com>
PR target/66731
* config/aarch64/aarch64.c (aarch64_rtx_costs): Fix NEG cost for FNMUL.
(aarch64_rtx_mult_cost): Fix MULT cost with -frounding-math.
git-svn-id:
svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-5-branch@226588
138bc75d-0d04-0410-961f-82ee72b054a4
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 691874b..eebc9c3 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -5250,7 +5250,7 @@ aarch64_rtx_mult_cost (rtx x, int code, int
outer, bool speed)
which case FNMUL is different than FMUL with operand negation. */
bool neg0 = GET_CODE (op0) == NEG;
bool neg1 = GET_CODE (op1) == NEG;
- if (compound_p || !flag_rounding_math || (neg0 && neg1))
+ if (maybe_fma || !flag_rounding_math || (neg0 && neg1))
{
if (neg0)
op0 = XEXP (op0, 0);
Since this was a fix to the patch one commit ahead and also merged in
the same operation and there is no further comment on why this fix was
skipped, may I assume that this happened by accident and you probably
want to fix that merge flaw by reapplying the missing patch? Or is
there an information detail I don't have that requires this fix to be
skipped on the Linaro branch?
Robert
Controlled image builds - TCWG-360 [1/10]
* Tried, failed to generate bootable images
Jenkins benchmarking job - TCWG-348 [5/10]
* Jenkins job functional on kvms in main instance
* Wrote job-dispatch script for non-Jenkins use cases
Juno crashdump [1/10]
* Struggled with, worked around network problems
* Juno running, waiting for it to crash
SPEC-on-Android [1/10]
* Helped Qian to find root cause of a problem
Misc [2/10]
=Plan=
Review security with shared uinstance/main instance code
Expose more data, benchmarks to bundles
Debug/test Jenkins job in microinstance
Create bootable image for at least 1 target, or know what the problems are
Write up noise control report (if time)
Probably more support for SPEC-on-Android
# Progress #
* Fix timeout in random-signal.exp. TCWG-424. Ongoing. [4/10]
I know the cause of the problem but can't figure out why it can
happen. Can only reproduce the fail in every 20~30 runs.
* TCWG-423, support gnu vector in inferior call in AArch64 GDB. Done.
[1/10]
* Build native ARM and AArch64 GDB in C++. No regression in test.
Done. TCWG-446. Done. [1/10].
* Fix GDB internal error in gdb.thread/watchpoint-fork.exp on AArch64.
[2/10]
* Upstream patches review [2/10]
** Review patches on arm gdbserver software single step V3. Some
patches are approved, but V4 is also needed for the rest.
** Review all-stop on non-stop patches.
** Discuss whether we need single step in fast tracepoint. Ongoing.
# Plan #
* One day off on Monday.
* Understand ST's jtag probe and help them to make use of multi-arch
in GDB.
* Look into timeout in random-signal.exp.
* TCWG-156, GDB test parity between AArch64 and X86_64.
* TCWG-460, follow up on the AArch64 GDBserver multi-arch work.
--
Yao
== Progress ==
- tree re-assoc regression (2/10)
- Found a test-case to reproduce it.
- working on a patch
- LuaJIT issue (6/10)
* Setup luajit on aarch64 and tried it
* tried to reproduce nginx issue with various configs without success
- LTO (1/10)
* aarch64 bootstrap
* ran into an uninit warning issues looking into it
- Misc (1/10)
* gcc/bug list
== Plan ==
* tree re-assoc
* LTO
== 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 ==
o Linaro GCC (4/10)
* Found and backported missing dependencies
* More backports
o Upstream work (4/10)
* Reviewed some patches
* Tried to reproduced an LRA issue (fixed in the meantime)
* Continue on sanitizing gfortran testsuite
o Misc (2/10)
* Various meetings
== Plan ==
o Continue on-going tasks
== This Week ==
* Target conversion to hook (2/10)
- Completed build and test for ASM_FORMAT_PRIVATE_NAME, ASM_LABEL_OUTPUT_LABEL
to hook
- Converted ASM_OUTPUT_LABEL_REF to hook
* Holidays (8/10)
- 3 days leave and public holiday (Guru nanak Jayanti)
== Next Week ==
- Send updated patch upstream for tcwg-72
- LTO benchmarking with SPEC for correctness on arm and aarch64
- Target hook conversion
The Linaro Toolchain Working Group is pleased to announce the availability
of the Linaro Stable Binary Toolchain GCC 5.2-2015.11 Release Archives.
http://releases.linaro.org/components/toolchain/binaries/5.2-2015.11/http://releases.linaro.org/components/toolchain/gcc-linaro/5.2-2015.11/
These archives provide cross-toolchain executables (compiler, debugger,
linker, etc.) and shared libraries (libstdc++, libc, etc.) that target ARM
or Aarch64 GNU/Linux and bare-metal environments. The cross-toolchain
binaries execute on a Linux or MS Windows (under mingw32) host
operating-system.
Please evaluate this release-candidate for correctness. Linaro will
shortly spin the Linaro GCC 5.2-2015.11 release if this release-candidate
passes stakeholder validation.
For bugs related to this release-candidate please email
linaro-toolchain(a)lists.linaro.org or file a bug at
https://bugs.linaro.org/enter_bug.cgi?product=Linux%20Binary%20toolchain
NEWS
* GCC 5.2 2015.11
The Linaro GCC 5.2 2015.11 binary toolchain release is built from the
Linaro GCC-5.2-2015.11 release source archive. The Linaro GCC-5.2-2015.11
release source archive is derived from the same sources as the Linaro
GCC-5.2-2015.10 snapshot source archive.
* GCC 5.2 2015.11-rc1
The Linaro GCC 5.2 2015.11-rc1 binary toolchain release-candidate is built
from the Linaro GCC-5.2-2015.11 release-candidate source archive. The
Linaro GCC-5.2-2015.11-rc1 release-candidate source archive is derived from
the same sources as the Linaro GCC-5.2-2015.10 snapshot source archive.
--
Ryan S. Arnold
Linaro Toolchain Working Group - Engineering Manager
www.linaro.org
Hello,
I am trying to create gcc 4.9.x toolchains for ARM v7 and v8 based on Linaro's sources. At first Linaro's 4.9-2015.05 binary release looked suitable, but then one of my colleagues noticed that that it had an incompatibility with Red Hat Enterprise Linux 6. Linaro has decided not to fix this incompatibility (see https://bugs.linaro.org/show_bug.cgi?id=1869 ).
So, I tried to work around that bug by rebuilding the toolchains myself on RHEL6 using Linaro's new ABE script. I initially tried to recreate the builds by using ABE's --manifest <manifest_file> command line option. I experienced problems with that, though, including it building gcc version 6.x instead of 4.9.x. I eventually gave up on that approach. Instead, I extracted the required branches and revisions from the manifest files and put them into ABE command line options, like this:
abe.sh --target aarch64-elf --build all --parallel --dump --tarball --release fsl-2015.11.16 --set libc=newlib binutils=binutils-gdb.git~linaro_binutils-2_24-branch@a93e252ee5250dba831e54f98336b40c7210dac7 gcc=gcc-linaro-4.9-2015.05 gmp=5.1.3 gdb=binutils-gdb.git~gdb-7.10-branch@ef5fa52ac9ab68b505b52acb2d2068b366ba8bf2 mpfr=3.1.2 mpc=1.0.1 newlib=newlib.git~linaro_newlib-branch@136b66e404df41435bdec4630c0787b0bc7e7580
abe.sh --target aarch64-linux-gnu --build all --parallel --dump --tarball --release fsl-2015.11.16 --set libc=glibc binutils=binutils-gdb.git~linaro_binutils-2_24-branch@a93e252ee5250dba831e54f98336b40c7210dac7 gcc=gcc-linaro-4.9-2015.05 gmp=5.1.3 gdb=binutils-gdb.git~gdb-7.10-branch@ef5fa52ac9ab68b505b52acb2d2068b366ba8bf2 mpfr=3.1.2 mpc=1.0.1 glibc=glibc-linaro-2.20-2014.11.tar.xz
abe.sh --target arm-eabi --build all --parallel --dump --tarball --release fsl-2015.11.16 --set libc=newlib binutils=binutils-gdb.git~linaro_binutils-2_24-branch@a93e252ee5250dba831e54f98336b40c7210dac7 gcc=gcc-linaro-4.9-2015.05 gmp=5.1.3 gdb=binutils-gdb.git~gdb-7.10-branch@ef5fa52ac9ab68b505b52acb2d2068b366ba8bf2 mpfr=3.1.2 mpc=1.0.1 newlib=newlib.git~linaro_newlib-branch@136b66e404df41435bdec4630c0787b0bc7e7580
abe.sh --target arm-linux-gnueabihf --build all --parallel --dump --tarball --release fsl-2015.11.16 --set libc=glibc binutils=binutils-gdb.git~linaro_binutils-2_24-branch@a93e252ee5250dba831e54f98336b40c7210dac7 gcc=gcc-linaro-4.9-2015.05 gmp=5.1.3 gdb=binutils-gdb.git~gdb-7.10-branch@ef5fa52ac9ab68b505b52acb2d2068b366ba8bf2 mpfr=3.1.2 mpc=1.0.1 glibc=glibc-linaro-2.20-2014.11.tar.xz
That worked, and the resulting toolchains ran without error under RHEL6. Note that I deliberately chose to switch to glibc in the *-linux-* toolchains, whereas the manifest files had them using eglibc.
At least one serious problem remained. The toolchains supported different multilibs than previous releases. For example, arm-eabi-gcc reported that it supported only three sets of libraries:
$ arm-eabi-gcc -print-multi-lib
.;
thumb;@mthumb
fpu;@mfloat-abi=hard
Linaro's 2015.05 build of the toolchain gives the same output. However, previous releases of this toolchain supported a much larger set of multilibs. A build from 2014.08 reports:
$ arm-none-eabi-gcc --print-multi-lib
.;
thumb;@mthumb
v7-a;@march=armv7-a
v7ve;@march=armv7ve
v8-a;@march=armv8-a
v7-a/fpv3/softfp;@march=armv7-a@mfpu=vfpv3-d16@mfloat-abi=softfp
v7-a/fpv3/hard;@march=armv7-a@mfpu=vfpv3-d16@mfloat-abi=hard
v7-a/simdv1/softfp;@march=armv7-a@mfpu=neon@mfloat-abi=softfp
v7-a/simdv1/hard;@march=armv7-a@mfpu=neon@mfloat-abi=hard
v7ve/fpv4/softfp;@march=armv7ve@mfpu=vfpv4-d16@mfloat-abi=softfp
v7ve/fpv4/hard;@march=armv7ve@mfpu=vfpv4-d16@mfloat-abi=hard
v7ve/simdvfpv4/softfp;@march=armv7ve@mfpu=neon-vfpv4@mfloat-abi=softfp
v7ve/simdvfpv4/hard;@march=armv7ve@mfpu=neon-vfpv4@mfloat-abi=hard
v8-a/simdv8/softfp;@march=armv8-a@mfpu=neon-fp-armv8@mfloat-abi=softfp
v8-a/simdv8/hard;@march=armv8-a@mfpu=neon-fp-armv8@mfloat-abi=hard
thumb/v7-a;@mthumb@march=armv7-a
thumb/v7ve;@mthumb@march=armv7ve
thumb/v8-a;@mthumb@march=armv8-a
thumb/v7-a/fpv3/softfp;@mthumb@march=armv7-a@mfpu=vfpv3-d16@mfloat-abi=softfp
thumb/v7-a/fpv3/hard;@mthumb@march=armv7-a@mfpu=vfpv3-d16@mfloat-abi=hard
thumb/v7-a/simdv1/softfp;@mthumb@march=armv7-a@mfpu=neon@mfloat-abi=softfp
thumb/v7-a/simdv1/hard;@mthumb@march=armv7-a@mfpu=neon@mfloat-abi=hard
thumb/v7ve/fpv4/softfp;@mthumb@march=armv7ve@mfpu=vfpv4-d16@mfloat-abi=softfp
thumb/v7ve/fpv4/hard;@mthumb@march=armv7ve@mfpu=vfpv4-d16@mfloat-abi=hard
thumb/v7ve/simdvfpv4/softfp;@mthumb@march=armv7ve@mfpu=neon-vfpv4@mfloat-abi=softfp
thumb/v7ve/simdvfpv4/hard;@mthumb@march=armv7ve@mfpu=neon-vfpv4@mfloat-abi=hard
thumb/v8-a/simdv8/softfp;@mthumb@march=armv8-a@mfpu=neon-fp-armv8@mfloat-abi=softfp
thumb/v8-a/simdv8/hard;@mthumb@march=armv8-a@mfpu=neon-fp-armv8@mfloat-abi=hard
I found that the file that encodes this older set of multilib mappings is gcc-linaro-4.9-2015.05/gcc/config/arm/t-aprofile. Based on some comments in gcc-linaro-4.9-2015.05/gcc/config.gcc, I guessed that ABE should have configured gcc with "--with-multilib-list=aprofile", and without "--with-arch=armv7-a" or "--with-fpu=vfpv3-d16". I quickly hacked these changes into abe/config/gcc.conf like this:
diff --git a/config/gcc.conf b/config/gcc.conf
index 19c44ca..4cc5eaf
--- a/config/gcc.conf
+++ b/config/gcc.conf
@@ -111,9 +111,9 @@ if test x"${build}" != x"${target}"; then
default_configure_flags="${default_configure_flags} --with-tune=cortex-a9"
fi
if test x"${override_arch}" = x -a x"${override_cpu}" = x; then
- default_configure_flags="${default_configure_flags} --with-arch=armv7-a"
+ default_configure_flags="${default_configure_flags}"
fi
- default_configure_flags="${default_configure_flags} --enable-threads=no --with-fpu=vfpv3-d16 --enable-multilib --disable-multiarch"
+ default_configure_flags="${default_configure_flags} --enable-threads=no --with-multilib-list=aprofile --enable-multilib --disable-multiarch"
languages="c,c++,lto"
;;
aarch64*-*elf)
After rebuilding the toolchain, I found it had the desired older set of multilibs.
I hope that this mail will help anyone who experiences similar problems. I have filed a bug report for the multilib issue. See https://bugs.linaro.org/show_bug.cgi?id=1920 .
While validating the toolchains, dejagnu reports a few unexpected failures. Does the TCWG publish their validation results anywhere for comparison? That would be very helpful.
Thanks,
Fred Peterson
Freescale Developer Tools
== Progress ==
o Valfidation and Infra (2/10)
* Some fixes in our release script
* look at refactoring our publishing snapshot job
o Linaro GCC (4/10)
* Start backports for 2015.12
* Tracking dependencies
o Upstream work (1/10)
* Continue on sanitizing gfortran testsuite
o Misc (3/10)
* Various meetings
* Internal support
== Plan ==
o Continue on-going tasks
Controlled image builds - TCWG-360 [2/10]
* A few more test/debug cycles with ci-loop-built image
Jenkins benchmarking job - TCWG-348 [3/10]
* YAML-ised Jenkins job, more test/debug cycles
Juno crashdump [1/10]
* Got a usable dump (via alt-sysrq-c) with latest patches plus some fiddling
SPEC-on-Android [1/10]
* Looked at Qian's work to date, didn't come up with any bright ideas
Misc [3/10]
=Plan=
Review security with shared uinstance/main instance code
Expose more data, benchmarks to bundles
Continue debug/test of Jenkins job
Create bootable image for at least 1 target, or know what the problems are
Write up noise control report (if time)
Set Juno off, try to get a dump of my crash
Probably more support for SPEC-on-Android
=Absences=
'ARM Day' next Monday (30th)
== This week ==
* TCWG-317 - Exploit wide add operations when appropriate for Aarch32 (5/10)
- Blocked as I have not yet determined why the pattern fails on big
endian targets
* TCWG-369 - Exploit wide add operations when appropriate for Aarch64 (1/10)
- Modified code based on minor code style comments
* TCWG-316 - Exploit vector multiply by scalar instructions (3/10)
- Discovered relevant previous RFC:
https://gcc.gnu.org/ml/gcc/2013-09/msg00061.html
- Coded subset of vector patterns
- Debugging combine phase to determine why patterns are not
being utilized
* Misc (1/10)
- Conference calls
== Next week ==
- TCWG-369 - Submit modified patch upstream for final approval
- TCWG-316 - Determine if rtl patterns can be used by combine
- TCWG-317 - Need feedback
- USA Thanksgiving Holidays (November 26-27)
== This Week ==
* TCWG-72 (2/10)
- Rebased patch
- Fixed ICE for x86-gcc with -m32 following Jim's suggestions.
* Target hook conversion (6/10)
- Converted ASM_FORMAT_PRIVATE_NAME, ASM_LABEL_OUTPUT_LABEL,
ASM_OUTPUT_LABELREF to hook
* TCWG-319 (1/10)
- Benchmark jobs for fp in progress on a53, a57.
* Misc (1/10)
- Meetings
== Next Week ==
- Test and send updated patch upstream for tcwg-72
- TCWG-319 benchmarking on cortex-a15
- Holidays from 23-25th November (Mon-Wed).