== This week ==
* TCWG-316 -Exploit vector multiply by scalar instructions when multiple
scalars are used as
coefficients in a loop (5/10)
- Wrote patterns to allow combine pass to mergenon-standard multiply
by lane patterns.
* Bugzilla 57195 (mode iterator bug) blocked compiling new pattern (1/10)
- Updated patch based on upstream comments and re-sent upstream
* TCWG-77 - Transform end of loop conditions to min_expr (1/10)
- Writing dejagnu test case.
- Writing function to check for min expr support on target
* Misc (1/10)
- Conference calls
* Holiday (2/10)
== Next week ==
- Complete TCWG-77 and send upstream
- Continued investigation into TCWG-316
== This week ==
* TCWG-80 (1/10)
- PRE and dead-store elimination ipa pass (WIP upstream) already
handles optimization
* TCWG-120 (2/10)
- Investigating 3 possible approaches:
a) fold arm_andsi3_insn/arm_cmpsi_insn to
zeroextractsi_compare0_scratch/andsi3_compare0_scratch
b) Undo cse in test conditions, and modify arm_rtx_costs to fold
arm_andsi3_insn/arm_cmpsi_insn to
zeroextractsi_compare0_scratch/andsi3_compare0_scratch
c) Expand directly to zeroextractsi_compare0_scratch/andsi3_compare0_scratch
- Not sure whether the generated assembly is better (in terms of
speed) than with trunk.
asm diff at -O1: http://pastebin.com/yXBHHkhM
* TCWG-72 (2/10)
- Rebased Kugan's patch
* TCWG-299 (3/10)
- Simple workaround for PR65837 - configure gcc with --with-fpu=neon
- Firefox trunk doesn't build with gcc for arm, using apt-get source firefox
- LTO build fails with out-of-memory on my laptop in qemu-arm chroot
* TCWG-319 (1/10)
- Benchmarking setup with Bernie on Juno for running SPEC.
- SPEC Runs without error on Juno-{a53,a57} and APM
* Misc (1/10)
- Meetings
== Next Week ==
- Continue with TCWG-120, TCWG-72, TCWG-319
Hi!
The pre-built version of the stable version of Linaro Toolchain (Linaro
GDB 2015.02-3) for Windows is shipped with GDB 7.8-2014.09-1-git. GDB
was built with the following options:
(gdb) show configuration
This GDB was configured as follows:
configure --host=i686-w64-mingw32 --target=arm-linux-gnueabihf
--with-auto-load-dir=$debugdir:$datadir/auto-load
--with-auto-load-safe-path=$debugdir:$datadir/auto-load
--without-expat
--with-gdb-datadir=/home/buildslave/workspace/BinaryRelease/label/hetzner/target/arm-linux-gnueabihf/_build/builds/destdir/i686-w64-mingw32/share/gdb
(relocatable)
--with-jit-reader-dir=/home/buildslave/workspace/BinaryRelease/label/hetzner/target/arm-linux-gnueabihf/_build/builds/destdir/i686-w64-mingw32/lib/gdb
(relocatable)
--without-libunwind-ia64
--without-lzma
--without-guile
--with-separate-debug-dir=/home/buildslave/workspace/BinaryRelease/label/hetzner/target/arm-linux-gnueabihf/_build/builds/destdir/i686-w64-mingw32/lib/debug
(relocatable)
--without-zlib
--without-babeltrace
As you can see in the output GDB was built without expat support. This
is a major problem for widely used micro controllers like ARM Cortex A8
(e.g. used in Beaglebone Black), because the technical description of
this microcontroller is loaded out of xml files (arm-with-neon.xml part
of GDB). It's also possible to do that manually with "set tdesc filename
<xml-file>, before connecting to the target.
Without having the expat option enabled the g package, which is sent
from gdbserver during establishing a connection to gdb, can't be parsed
correctly. The result is in the first step a warning because of the
missing xml support and later on a error regarding the unexpected
content of the g package:
warning: Can not parse XML target description; XML support was disabled
at compile time
Remote 'g' packet reply is too long:
00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000f0fcffbe00000000407afdb6300000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
Old GDB versions of Linaro Toolchain like 7.6.1-2013.10 doesn't have
that problem because they were compiled with enabled expat support.
In my opinion there can be two root causes regarding that missing expat
support:
a) Expat support was explicitly disabled with --without-expat option
during the built of GDB.
b) On the build machine there wasn't a expat library available when gdb
was built.
Best regards,
Andreas Schmidl
== 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, discussions, general support, etc.
- Connect stuff
== Plan ==
* Look a bit more on the library issues, try to upstream the bot changes
* Check instability in SciMark2
* Change HD from a D01
* Continue discussion about the sanitizer's multiple VMA problem
* Prepare for Connect, travel arrangements, etc.
# Progress #
* TCWG-857, [7/10]
One patch is upstreamed. The rest of them are in the queue.
Upgrade juno board linux kernel to 4.2.0-rc4+ to test some
multi-arch kernel patches. It isn't easy to run that new kernel
on juno board, takes much time on this.
* Misc [3/10]. Meetings, online trainings, etc.
# Plan #
* Continue to upstream multi-arch patches.
* Some upstream patch reviews on tracepoint.
--
Yao
Hello guys,
I am newbie here and need your kindly help:)
When trying to use gcc-linaro-4.9 to build u-boot for ls1021atwr (ARM Cortex-A7 MPCore compliant with ARMv7-A architecture), we face issue. U-boot hangs at PCI-E.
After tracing the code, the issue is located at the line "*val = readl(addr);".
u-boot/drivers/pci/pcie_layerscape.c: ls_pcie_read_config():
if (PCI_BUS(d) == hose->first_busno) {
...
} else {
...
if (PCI_BUS(d) == hose->first_busno + 1) { #PCI_BUS(d) 1, hose->first_busno 0
ls_pcie_cfg0_set_busdev(pcie, busdev);
addr = pcie->va_cfg0 + (where & ~0x3); #pcie->va_cfg0 0x24000000, where 0xc
} else {
....
}
}
*val = readl(addr);
The gcc source we used is gcc-linaro-4.9-2015.02.tar.xz<https://releases.linaro.org/15.02/components/toolchain/gcc-linaro/4.9/gcc-l…> (link<https://releases.linaro.org/15.02/components/toolchain/gcc-linaro/4.9/>) which is based on FSF GCC 4.9.3-pre+svn220525.
Meanwhile, gcc-linaro-4.9-2015.01.tar.xz<https://releases.linaro.org/15.02/components/toolchain/gcc-linaro/4.9/gcc-l…> does not have this issue.
After Bisecting, we tracked down a gcc commit:
https://git.linaro.org/toolchain/gcc.git/commitdiff/e4f9e85e8152379aef37377…
2015-01-23 Jakub Jelinek <jakub(a)redhat.com>
PR rtl-optimization/63637
PR rtl-optimization/60663
* cse.c (merge_equiv_classes): Set new_elt->cost to MAX_COST
if elt->cost is MAX_COST for ASM_OPERANDS.
(find_sets_in_insn): Fix up comment typo.
(cse_insn): Don't set src_volatile for all non-volatile
ASM_OPERANDS in PARALLELs, but just those with multiple outputs
or with "memory" clobber. Set elt->cost to MAX_COST
for ASM_OPERANDS in PARALLEL. Set src_elt->cost to MAX_COST
if new_src is ASM_OPERANDS and elt->cost is MAX_COST.
* gcc.dg/pr63637-1.c: New test.
* gcc.dg/pr63637-2.c: New test.
* gcc.dg/pr63637-3.c: New test.
* gcc.dg/pr63637-4.c: New test.
* gcc.dg/pr63637-5.c: New test.
* gcc.dg/pr63637-6.c: New test.
* gcc.target/i386/pr63637-1.c: New test.
* gcc.target/i386/pr63637-2.c: New test.
* gcc.target/i386/pr63637-3.c: New test.
* gcc.target/i386/pr63637-4.c: New test.
* gcc.target/i386/pr63637-5.c: New test.
* gcc.target/i386/pr63637-6.c: New test.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-4_9-branch@220323 138bc75d<https://git.linaro.org/toolchain/gcc.git/object/138bc75d>-0d04-0410-961f-82ee72b054a4<https://git.linaro.org/toolchain/gcc.git/object/82ee72b054a4>
Before this commit, u-boot can boot up.
So any hint/suggestion? if more details needed, please feel free to tell us.
Thank you in advance.
-Ting
== Progress ==
LLDB development
-- Testing and bug fixing lldb on hikey AArch64 [TCWG-231] [4/10]
-- Looking into multi-threaded watchpoint test failures on
AArch64 highkey board.
-- Fixed watchpoint installation lag and unexpected behaviour.
Submitted http://reviews.llvm.org/D12522
-- Start work to add support for un-alinged watchpoints on AArch64
[TCWG-367] [3/10]
Miscellaneous [3/10]
-- Meetings, emails, discussions etc.
-- Laptop LCD screen malfunctioned, found a temporary replacement.
== Plan ==
LLDB development
-- Progress towards un-allinged watchpoint support on AArch64 LLDB
-- Fix broken parts of LLDB testsuite on AArch64.
== Progress ==
o Linaro GCC validation (8/10)
* Reviewed, validated and committed more backports
* New stability issues after executor number increased
* Started to script branch merge
* Developed a new tool to avoid wasting time in gerrit/jenkins/logs
navigation
o Upstream GCC (1/10)
* Looked at and updated some bugzillas
o Misc (1/10)
* Various meetings
== Plan ==
o Continue backports/validation/branch merge
== Progress ==
* Widening pass (TCWG-547) – 6/10
- Looked at “Error: unaligned opcodes detected in executable segment”
* Spent lot of time trying to understand the root cause.
* Got some suggestions from Jim and looking into it.
- Posted some of the important patches for review.
* https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00399.html
* https://bugs.linaro.org/show_bug.cgi?id=1318 (2/10)
- Tried reproducing with the source provided without success.
- Could build and reproduce with emacs-24.4 release.
- Trunk GCC version 6.0.0 20150902 works.
- GCC version 4.9.3 20150209 (Linaro GCC 4.9-2015.02) fails.
* Misc - 2/10
- gcc-patches, gcc-bugs list
== Plan ==
* Continue with widening pass
* Fix Bug1318
