== This week ==
* Sprint recovery day (2/10)
* TCWG-140 - Transform end of loop conditions to min_expr (6/10)
- Investigated match.pd change added by Andrew Pinski
* TCWG-734 - GCC Autovectorization (1/10)
- EPIC Review
* Misc (1/10)
- Conference calls
== Next week ==
- Call with Charles and Prathamesh for Autovectorization planning
- Begin developing patch for TCWG-140
- Benchmark TCWG-146 patch
- TCWG-832 investigation
== This week ==
* cfgloop.h flatten (2/10)
- Rebased and tested on top of Andrew's patch
- bootstrapped on x86_64-unknown-linux-gnu
- building on all targets in config-list.mk in progress
* TCWG-777 (2/10)
- Problem is still present on trunk
- Original test-case: http://pastebin.com/UTv8g3aA
- Original test-case assembly for -O1: http://pastebin.com/815TgDjV
- Possibly reduced test-case: http://pastebin.com/UGUteX4a
- Assembly for reduced test-case for -O1: http://pastebin.com/edKu6CxH
- x86 assembly for reduced test-case for -O1: http://pastebin.com/9APbJeLr
- Workaround: To disable CSE in branch conditions make flags volatile.
This prevents
storing result of ands to temporary but leads to worse code-gen.
- Possible approaches from (https://bugs.launchpad.net/gcc-linaro/+bug/851258):
a) teach PRE not to fold in such cases ? I don't know how.
b) Write a new tree-ssa pass that "unfolds" cse on result of test conditions.
Check if operand in if (operand != 0) is a result of test condition.
eg:
_8 = flags & 1;
if (_8 != 0)
goto true_branch
else
goto false_branch
In this case we could add an attribute to _8 say "unfold".
If we again come across if (_8 != 0) at a later point,
and it's marked with "unfold",
we can create a new ssa var with definition of _8.
so it becomes:
_9 = flags & 1;
if (_9 != 0)
...
which will "undo" CSE on test conditions.
Does this sounds reasonable ?
Should we do it on all test conditions ?
I don't understand "suitable compare insn" a target should have in above link.
* TCWG-145 (2/10)
- Optimization is already implemented in PRE pass.
- Verified for various test-cases in eembc.
- Currently gcc does not convert global statics to locals
- remove-local-statics-7.c not handled currently by gcc:
(https://gcc.gnu.org/ml/gcc-patches/2008-07/msg01007.html)
- Desirable to have ipa dead-store analysis to avoid stores to static vars:
https://gcc.gnu.org/ml/gcc-patches/2008-07/msg01609.htmlhttps://gcc.gnu.org/ml/gcc-patches/2008-07/msg01602.html
- continuing to look for cases where static-to-locals wins over PRE.
* Misc (4/10)
- Built firefox on x86 non-LTO
- Read thru tree-ssa-dse.c, IPA, LTO doc
- US Visa application
- Setting up home office
== Issues ==
Not able to connect to #linaro-tcwg thru ircproxy.linaro.org , password invalid.
== Next Week ==
- TCWG-830
- TCWG-835
- TCWG-844
- continue investigating branch out of range error issue.
- Work towards committing cfgloop.h patch
== Progress ==
Sprint recovery [2/10]
(TCWG-775) NEON intrinsics error messages [7/10]
. familiarisation with differences between ARM and AArch64 NEON/SIMD backends
. started porting error reporting changes to ARM NEON backend
. pinged patch for AArch64 work
Misc [1/10]
== Plans ==
continue NEON error messages
vectorization work discussions
== 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.
- Reviewing more stride vectorizer patches (back-end)
== Plan ==
* Try to get some development going back again...
# Progress #
* Linaro GDB [7/10]
** TCWG-805, aarch64 native debugging multi-arch support.
Aarch64 GDB works well debugging Aarch32 programs, except on handling
fork/vfork and watchpoint. Test harness uses ldd which doesn't
handle aarch32 too.
Report a kernel issue that it doesn't get TLS base right through
ptrace in compat mode. Got a patch to fix it.
* FSF GDB [3/10]
** Push in a fix to unbreak arm native gdb build.
** Post a patch to fix a bug on using PTRACE_GETREGSET on arm-linux.
** GDB 7.10 release. Branch isn't created. Test results of arm
and aarch64 look good.
# Plan #
* TCWG-805, start to push some preparatory patches upstream.
* Off on Thu.
--
Yao
Hello toolchain people,
I created a patch on top of upstream binutils for a feature I need which
should be universally useful as well. Now I have 3 questions for you:
1) Does it look sane enough?
2) If so, could you integrate it in the Linaro release?
3) Would you be willing to promote it upstream?
Comments appreciated.
Here's the patch:
----- >8
Subject: [PATCH] gas: introduce section name substitution support
When gas is invoked with --sectname-subst, the occurrence of %S in a section
name will be substituted by the name of the current section. For example:
.macro exception_code
.pushsection %S.exception
[exception code here]
.popsection
.endm
.text
[code]
exception_code
[...]
.section .init
[init code]
exception_code
[...]
In the first exception_code invocation the .text.exception section is
created while in the second invocation it is the .init.exception section
that is created. This is useful e.g. to discriminate between anciliary
sections that are tied to .init code and can be discarded at run time when
initialization is over vs anciliary sections tied to .text sections that
need to stay resident.
This would also allow for actually omitting __exit sections from the Linux
kernel binary when modules are configured in even when exit marked code
generates exception table entries.
Signed-off-by: Nicolas Pitre <nico(a)linaro.org>
diff --git a/gas/ChangeLog b/gas/ChangeLog
index 57fc30a..0189bb2 100644
--- a/gas/ChangeLog
+++ b/gas/ChangeLog
@@ -1,3 +1,11 @@
+2015-06-03 Nicolas Pitre <nico(a)linaro.org>
+
+ * as.c (show_usage): Document --sectname-subst.
+ (parse_args): Add --sectname-subst.
+ * as.h (flag_sectname_subst): New.
+ * config/obj-elf.c (obj_elf_section_name): Add %S substitution.
+ * doc/as.texinfo: Document it.
+
2015-06-03 Matthew Wahab <matthew.wahab(a)arm.com>
* config/tc-arm.c (arm_archs): Add "armv8.1-a".
diff --git a/gas/as.c b/gas/as.c
index 2a8923f..fecfcd2 100644
--- a/gas/as.c
+++ b/gas/as.c
@@ -284,6 +284,8 @@ Options:\n\
fprintf (stream, _("\
--size-check=[error|warning]\n\
ELF .size directive check (default --size-check=error)\n"));
+ fprintf (stream, _("\
+ --sectname-subst enable section name substitution sequences\n"));
#endif
fprintf (stream, _("\
-f skip whitespace and comment preprocessing\n"));
@@ -447,6 +449,7 @@ parse_args (int * pargc, char *** pargv)
OPTION_EXECSTACK,
OPTION_NOEXECSTACK,
OPTION_SIZE_CHECK,
+ OPTION_SECTNAME_SUBST,
OPTION_ALTERNATE,
OPTION_AL,
OPTION_HASH_TABLE_SIZE,
@@ -481,6 +484,7 @@ parse_args (int * pargc, char *** pargv)
,{"execstack", no_argument, NULL, OPTION_EXECSTACK}
,{"noexecstack", no_argument, NULL, OPTION_NOEXECSTACK}
,{"size-check", required_argument, NULL, OPTION_SIZE_CHECK}
+ ,{"sectname-subst", no_argument, NULL, OPTION_SECTNAME_SUBST}
#endif
,{"fatal-warnings", no_argument, NULL, OPTION_WARN_FATAL}
,{"gdwarf-2", no_argument, NULL, OPTION_GDWARF2}
@@ -848,6 +852,10 @@ This program has absolutely no warranty.\n"));
else
as_fatal (_("Invalid --size-check= option: `%s'"), optarg);
break;
+
+ case OPTION_SECTNAME_SUBST:
+ flag_sectname_subst = 1;
+ break;
#endif
case 'Z':
flag_always_generate_output = 1;
diff --git a/gas/as.h b/gas/as.h
index 6de319e..635b2c5 100644
--- a/gas/as.h
+++ b/gas/as.h
@@ -589,6 +589,9 @@ COMMON enum
size_check_warning
}
flag_size_check;
+
+/* If section name substitution sequences should be honored */
+COMMON int flag_sectname_subst;
#endif
#ifndef DOLLAR_AMBIGU
diff --git a/gas/config/obj-elf.c b/gas/config/obj-elf.c
index 4d7a8a7..78dc6d9 100644
--- a/gas/config/obj-elf.c
+++ b/gas/config/obj-elf.c
@@ -917,6 +917,27 @@ obj_elf_section_name (void)
name = (char *) xmalloc (end - input_line_pointer + 1);
memcpy (name, input_line_pointer, end - input_line_pointer);
name[end - input_line_pointer] = '\0';
+
+ while (flag_sectname_subst)
+ {
+ char *subst = strchr (name, '%');
+ if (subst && subst[1] == 'S')
+ {
+ int oldlen = strlen (name);
+ int substlen = strlen (now_seg->name);
+ int newlen = oldlen - 2 + substlen;
+ char *newname = (char *) xmalloc (newlen + 1);
+ int headlen = subst - name;
+ memcpy (newname, name, headlen);
+ strcpy (newname + headlen, now_seg->name);
+ strcat (newname + headlen, subst + 2);
+ xfree (name);
+ name = newname;
+ }
+ else
+ break;
+ }
+
#ifdef tc_canonicalize_section_name
name = tc_canonicalize_section_name (name);
#endif
diff --git a/gas/doc/as.texinfo b/gas/doc/as.texinfo
index 5710e1c..be13b6a 100644
--- a/gas/doc/as.texinfo
+++ b/gas/doc/as.texinfo
@@ -6259,6 +6259,36 @@ For ELF targets, the @code{.section} directive is used like this:
.section @var{name} [, "@var{flags}"[, @@@var{type}[,@var{flag_specific_arguments}]]]
@end smallexample
+@cindex --sectname-subst
+If the @samp{--sectname-subst} command-line option is provided, the @var{name}
+argument may contain a substitution sequence. Only @code{%S} is supported
+at the moment, and substitutes the current section name. For example:
+
+@smallexample
+.macro exception_code
+.section %S.exception
+[exception code here]
+.previous
+.endm
+
+.text
+[code]
+exception_code
+[...]
+
+.section .init
+[init code]
+exception_code
+[...]
+@end smallexample
+
+The two @code{exception_code} invocations above would create the
+(a)code{.text.exception} and @code{.init.exception} sections respectively.
+This is useful e.g. to discriminate between anciliary sections that are
+tied to setup code to be discarded after use from anciliary sections that
+need to stay resident without having to define two @code{exception_code}
+macros just for that purpose.
+
The optional @var{flags} argument is a quoted string which may contain any
combination of the following characters:
@table @code
Nicolas
* 1 day off (2/10)
== Progress ==
* Neon intrinsics tests
- committed last batch of tests
- need to think about tests for vget_lane which are still missing,
but not high priority
* linaro-gcc-5.1-2015.06 snapshot (4/10)
- committed branch merge with upstream gcc-5-branch
- prepared snapshot & updated release scripts
* Upstream maintenance (1/10)
- backported a fix from Michael to 4.8 and 4.9 branches
- backported fix for PR62308 to 4.9 branch
- most of the time spent on bootstrapping on aarch64 HW
- started looking at some recent new tests having trouble dealing
with some multilib variants
* Misc (3/10)
- meetings, conf-calls, emails, ...
== Next ==
* linaro-gcc-5.1-2015.06 snapshot
- build release notes
- create a proper tag
* backports, release, validation:
- update doc according to our new process
* validation:
- take unstable tests into account
* upstream maintenance:
- check recent regressions
== 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 meetings about infrastructure...
- LLVM status and plan for next half
* Sprint Week in Grenoble
== Plan ==
* Continue with CMake LNT changes
* Carry on with ADD/SUB change
* Revive ASM warnings discussion
Holiday [2/10]
Benchmark Automation - TCWG-360 [4/10]
* Learned about central Jenkins instance
* Considered ways of integrating benchmark scripts with said instance
* Considered alternative way for benchmark scripts to interoperate with LAVA
Misc [4/10]
* Large mail backlog
* Travel prep
=Plan=
Team sprint
# Progress #
* Linaro GDB [4/10]
** TCWG-805, aarch64 native debugging multi-arch support.
aarch64 native gdb is able to debug arm program now, but with some
problems on coredump. Patches are not posted.
** Give my input on GDB kernel awareness too, and the proposal finally
is posted upstream.
* FSF GDB [1/10]
** Patches review.
* Misc [5/10]
** Attend an internal ARM Debug/Tracing summit.
** Prepare for the France travel.
# Plan #
* Sprint in Grenoble.
--
Yao
Hi Linaro Toolchain Group,
I am trying to build a cross-native toolchain for AARCH64 using ABE build
framework.
By cross native I mean that toolchain will be build on 0x86 (Red hat
Santiago 6.4), it will run on AARCH64 (Juno) and
will produce binaries to be run on AARCH64 (Juno)
(If I am not mistaked) --build=0x86, --host=AARCH64, --target=AARCH64
Steps followed:
1. I built a cross toolchain first
../abe/configure
../abe/abe.sh --target aarch64-linux-gnu --build all --release 2015.05.29
--tarbin --disable update
2. Added the above cross toolchain (bin path) in the PATH
3. To build to cross-native
../abe/configure
../abe/abe.sh --host aarch64-linux-gnu --target aarch64-linux-gnu --build
all --release 2015.06.01.native --tarbin --disable update
But after some time, I got following error and compilation hanged.
make: Leaving directory
`/home/user_name/vpathak/build_abe/builds/aarch64-linux-gnu/aarch64-linux-gnu/gcc.git~linaro-4.9-branch-stage1'
RUN: copy_gcc_libs_to_sysroot
"/home/user_name/vpathak/build_abe/builds/destdir/aarch64-linux-gnu/bin/aarch64-linux-gnu-gcc
--sysroot=/home/user_name/vpathak/build_abe/sysroots/aarch64-linux-gnu"
/home/user_name/vpathak/abe/lib/make.sh: line 962:
./builds/destdir/aarch64-linux-gnu/bin/aarch64-linux-gnu-gcc: cannot
execute binary file
Am I missing something ? Please help.
However with the following hack in the abe, I am able to compile
cross-native toolchain for aarch64-linux-gnu.
In the abe code base:
-------------------------------------------------------------------------------------------------------
lib/make.sh
Function copy_gcc_libs_to_sysroot()
gcc_exe="`find -name ${target}-gcc`"
- libgcc="`${gcc_exe} -print-file-name=${libgcc}`"
+ #libgcc="`${gcc_exe} -print-file-name=${libgcc}`"
+
libgcc="/home/user_name/vpathak/build_abe/builds/destdir/aarch64-linux-gnu/lib/gcc/aarch64-linux-gnu/4.9.3/libgcc.a"
Since './builds/destdir/aarch64-linux-gnu/bin/aarch64-linux-gnu-gcc' is
native toolchain it will not run on 0x86. Thus libgcc will be empty.
Therefore I hard-coded libgcc path.
-------------------------------------------------------------------------------------------------------
I had to disable gdb compilation. This error I faced while compiling
cross-native compilation only.
Cross compilation is successful on the same 0x86 machine.
checking for library containing waddstr... no
configure: error: no enhanced curses library found; disable TUI
make: *** [configure-gdb] Error 1
make: Leaving directory
`/home/user_name/vpathak/build_abe/builds/aarch64-linux-gnu/aarch64-linux-gnu/binutils-gdb.git~linaro_gdb-7.8-branch-gdb'
WARNING: Make had failures!
ERROR (#159): build_all (Failed building .)
hacked patch
--- a/lib/make.sh
+++ b/lib/make.sh
@@ -31,10 +31,10 @@ build_all()
# to rebuilt the sysroot.
local builds="infrastructure binutils libc stage2 gdb"
else
- local builds="infrastructure binutils stage1 libc stage2 gdb"
+ local builds="infrastructure binutils stage1 libc stage2"
fi
if test "`echo ${target} | grep -c -- -linux-`" -eq 1; then
- local builds="${builds} gdbserver"
+ local builds="${builds}"
fi
---------------------------------------------------------------------------------------------------------------
Thanks.
--
with regards,
Virendra Kumar Pathak
Hi Linaro Toolchain Group,
Is there any tool for checking coding style of the patches submitted to the
Linaro Toolchain ?
In other word is there any equivalent of Linux checkpatch.pl in Linaro
Toolchain (GCC, Binutils etc) ?
If yes, please let me know.
If not, then in general how people check the coding style of the patches
they submit to Linaro Toolchain (GCC, Binutils etc).
I assume manual inspection (line by line) may be very tedious thing to do.
Thanks.
--
with regards,
Virendra Kumar Pathak
== Progress ==
* Upstream GCC (8/10)
- TCWG-486 - Optimize Constant Uses in Loops.
- Jeff reviewed it and asked for some minor changes
- Rebased and redid full testing and posted it
- TCWG-555 - Complete re-write of widening pass based on review comments
- Getting ready to post for review
* Misc (2/10)
- Reading TACT User Manual
- gcc-patches, gcc-bugs list
- Meetings
== Plan ==
- Continue with gcc stage1 activities
== This week ==
* Bug 539 - .LTHUNK symbols are surviving (2/10)
- Built Qt 4.8 using 4.9 and 4.9 toolchain and verified fix
identified by Jim Wilson
- Plan to close as fixed
* Bug 535 - static cast from float to int not working on ARM hardfp (2/10)
- Investigation
* TCWG-140 - Transform end of loop conditions to min_expr (1/10)
- Investigation into blueprint and patch
* TCWG-146 - Detect smin/umin idiom (2/10)
- After investigation no patch deemed necessary for aarch64
* Misc (1/10)
- Conference calls
* US Holiday - Memorial Day, May 25th (2/10)
== Next week ==
- Submit Aarch32 patch for TCWG-146 upstream
- TCWG-140 investigation
== This week ==
* TCWG-619 (4/10)
- Chromium builds with LTO single-partition with gold by changing
arm_is_long_call_p() to always return true, thereby disabling short
calls.
- Fails to build with ld.bfd for single partiition with the following error:
obj/third_party/webrtc/base/rtc_base.ipaddress.o: In function
`rtc::IPAddress::IPAddress(unsigned int)':
ipaddress.cc:(.text._ZN3rtc9IPAddressC2Ej[_ZN3rtc9IPAddressC5Ej]+0x28):
undefined reference to `vtable for rtc::IPAddress'
- gas debug for "Thumb2 branch out of range" in config/tc-arm.c:
Fails in md_apply_fix at following condition:
if ((value & ~0x3fffff) && ((value & ~0x3fffff) != ~0x3fffff))
{
if (!(ARM_CPU_HAS_FEATURE (cpu_variant, arm_arch_t2)))
as_bad_where (fixP->fx_file, fixP->fx_line, BAD_RANGE);
else if ((value & ~0x1ffffff)
&& ((value & ~0x1ffffff) != ~0x1ffffff))
as_bad_where (fixP->fx_file, fixP->fx_line,
_("Thumb2 branch out of range"));
}
The condition became true for value == fffffda
Backtrace: http://pastebin.com/QZqbwNCy
Options passed to as: -march=armv7-a -march=armv7-a -mfloat-abi=hard
-mfloat-abi=hard -mfpu=neon -mfpu=neon -meabi=5
- Disabling the above condition results in:
arm-linux-gnueabihf-g++: internal compiler error: Killed (program lto1)
* PR49551 (2/10)
- Modified patch and retested on x86 and arm.
- Submitted patch upstream for review.
* Misc (4/10)
- Exams ended on Monday.
- College Annual day.
== Next Week ==
- Work towards getting the patch approved.
- Continue investigating "Thumb2 branch out of range" error.
- Begin with TCWG-777.
- Submit cfgloop.h flattening patch upstream.
Hi Linaro Toolchain Group,
I am going through the binutils code base specific to arm & aarch64. Please
give some insight on below questions.
1. In the struct bfd_arch_info {...} (in bfd/bfd-in2.h) there are two
fields 'enum bfd_architecture arch' and 'unsigned long mach'.
I went trough the binutils porting guide (by MR.Swami.Reddy(a)nsc.com) which
says 'arch' is for architecture & 'mach' is for machine value.
At present in the bfd/bfd-in2.h :- arch = bfd_arch_aarch64 and mach =
bfd_mach_aarch64 or bfd_mach_aarch64_ilp32.
But what these fields really means ? What is the difference between 'arch'
and 'mach'?
Lets say instruction set architecture is ARMv8 (also known as aarch64 for
64 bit- if I am not wrong). Then we have specific implementation of this
like cortex53, cortex57, Cavium ThunderX etc. With respect to this what
will be the value of arch = ? and mach = ?
2. In the include/opcode/arm.h the 'arm_feature_set' is defined as a
structure where as in include/opcode/aarch64.h 'aarch64_feature_set' is
defined as unsigned long. Is there any specific reason for this? Why
structure definition was not followed in aarch64 ?
typedef struct
{
unsigned long core;
unsigned long coproc;
} arm_feature_set;
typedef unsigned long aarch64_feature_set;
3. Also I see that in the case of arm, 'mach' values are derived from cpu
extension value specified in that 'arm_feature_set' structure.
For example.
if (ARM_CPU_HAS_FEATURE (cpu_variant, arm_cext_iwmmxt2))
mach = bfd_mach_arm_iWMMXt2;
Whereas in aarch64 mach is derived based on API type (64 or 32). Any
reason for this ?
mach = ilp32_p ? bfd_mach_aarch64_ilp32 : bfd_mach_aarch64;
Thanks in advance.
--
with regards,
Virendra Kumar Pathak
== Progress ==
TCWG-775 NEON error messages (2/10)
. wrote new patch for Aarch64
. tried to test it, but GCC testsuite stopped working on my laptop
(random failures with "test for errors, tests randomly being marked
UNSUPPORTED)
Bank Holiday [2/10]
Bug #1599 [1/10]
. reproduced bug on Linaro GCC 4.9
, bisected both the cause and the trunk fix
Misc [5/10]
. attempted to diagnose GCC testsuite problems. Seems to be related to
kernel version somehow.
. Erratum workaround stuff (bug 1550, bug 1596)
== Plans ==
Find working kernel for laptop
Cleanup/submit patch for TCWG-775
Create JIRA cards following vectorization study (TCWG-735)
Bank holiday on Monday. [2/10]
# Issue #
No. Ubuntu is successfully installed on my chromebook.
# Progress #
* Linaro GDB [4/10]
** TCWG-517, GDB AAarch64 record/replay. Done.
Patches are committed upstream. Fix one build failure caused
these patches.
** TCWG-805, aarch64 native debugging multi-arch support.
*** Switch to PTRACE_GETREGSET and PTRACE_SETREGSET. Patches are posted
upstreams.
*** Get ubuntun 14.02 running on chrombook successfully.
** Give my input on GDB kernel awareness too.
* FSF GDB [3/10]
** PR 18392, review the fix and understand the code about tail call
unwinding.
** Approve and commit some tiny patches.
* Misc [1/10]
** Prepare for incoming France travel.
** Book flight and hotel for GNU Tools Cauldron.
Next week:
* TCWG-805, aarch64 native debugging multi-arch support.
--
Yao
== 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 on ASM warnings
* Move a few left-overs in ARMAsmParser to use ARMTargetParser
If time allows...
* Check the ADD -> SUB change in the assembler
* Try to get the test-suite running on a CMake buildbot
Background
* Check the progress of some Android bugs
* 1 day off
* Neon intrinsics tests (4/10)
- submitted last set for review
* Misc (4/10)
- meetings, conf-calls, emails, ...
- checks for our new GCC mirror
== Next ==
* Neon intrinsics tests: work on vget_lane test.
* linaro-gcc-5.1-2015.06 release:
- start working on backports
* TCWG-619 (2/10)
- "branch out of range" error disappears by disabling sibling call optimization
- using gold results in internal error at arm.cc:4192
- using ld.bfd results in tons of same errors message during LINK
chrome - "thumb2 branch out of range"
- building with "-dp" option shows the error comes for function calls,
generated from pattern call_value_symbol.
* PR49551 (2/10)
- Bootstrapped on x86, tested on x86 and arm.
- added test-case.
* Misc (6/10)
- Exams
== Next Week ==
- Submit patch to PR49551 upstream
- Continue investigating "branch out of range" error.
- Rebase and submit cfgloop.h flattening patch upstream.
== Progress ==
* Upstream GCC (8/10)
- vector cost (TCWG-779)
- benchmarking complete and analysed
- Committed after full testing (bootstrap and regression testing)
- Started working on widening pass based on review comments (TCWG-555)
- Completed re-factoring with the new ideas
- ran into many ICEs with the patch and making progress
* Misc (2/10)
- Looked at http://ctuning.org/wiki/index.php?title=CTools:MilepostGCC
again
- gcc-patches, gcc-bugs list
- Meetings
== Plan ==
- Continue with gcc stage1 activities
== 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 thumbv7a
* Background (2/10)
- Code review, meetings, discussions, etc.
- More stride vectorizer reviews (D9368)
- Setting up boards for developers
== Plan ==
* Finish the parser FIXMEs, get on with ASM warnings
* Check some Android bugs and see if I can reduce their numbers
* Probably a bit more infrastructure discussions
# Issues #
* Don't have arm board to run native gdb testsuite (my pandaboard is
too slow to run native tests). Get a chromebook, but takes a lot
of time installing ubuntu on it. Network still doesn't work, don't
know how much time are still needed to fix networking issues.
# Progress #
* Linaro GDB
** TCWG-517, GDB AAarch64 record/replay. [3/10]
These bits are finally posted upstream. The review looks good.
** TCWG-805, aarch64 native debugging multi-arch support. [4/10]
*** Switch to PTRACE_GETREGSET and PTRACE_SETREGSET. Patches are done,
but takes much time to set up GDB native testing env, as linaro
tcwglab is still unreachable.
Install ubuntun 14.02 on chrombook. Done, but network driver
doesn't work.
** Give my input on GDB kernel awareness.
** Tweak pandaboard for native gdb testing. Done.
** AArch64 debugging on different ELs, a meeting is scheduled
in the sprint but I ask more details before that meeting.
* FSF GDB [1/10]
** Review a patch about arm abi detection for ELFOSABI_GNU. Approve it.
** Review a patch about compile feature in GDB.
* Misc [2/10]
** Go to London for France Visa application on Monday and get visa on
Thu.
# Plan #
* TCWG-517, GDB AAarch64 record/replay.
Address review comments and push them in.
* TCWG-805, aarch64 native debugging multi-arch support.
Set up chromebook and test my patches on it.
--
Yao
Holiday Thursday afternoon and Friday [3/10]
Benchmark automation - TCWG-360 [4/10]
* CPU2006 patches cleaned up, submitted
* A few other small fixes
Misc [3/10]
* ~1/10 getting a Juno running
=Plan=
Holiday next week, then:
Pick a direction on streaming vs listeners, write down the reasoning
Follow up (close out?) results storage and restricted targets
Write more tests, refactoring where appropriate
Investigate running benchmarks through ci.linaro.org
If time, and it looks sane, wrap a LAVA job around benchmark scripts
== Progress ==
LLDB development
-- Submitted and committed AArch64 hardware watchpoint/breakpoint
support [2/10] [TCWG-771]
-- Submitted Arm hardware watchpoint/breakpoint support [1/10] [TCWG-770]
-- Debugged arm watchpoints on Nexus 7 Android device. [2/10] [TCWG-651]
Miscellaneous [5/10]
-- Submitted AArch64 gdb record-replay patches
-- Travel to Islamabad for interview at French Embassy
-- Meetings, emails, discussions etc.
== Plan ==
LLDB development
-- Fix issues with hardware watchpoints and try to run tests on Nexus 7
-- Update and resubmit Arm hardware watchpoint patch.
== This week ==
* TCWG-619 (2/10)
- Disabling seccomp-bpf, works with LTO build for chromium for
multiple partitions (-flto-partitions={balanced, 1to1})
- disabling fPIC does not prevent the error - "branch out of range"
for single or no partition (--param lto-partitions=1 / -flto-partitions=none )
- The docs say there is option to disable PLT (-fno-plt),
https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html#Code-Gen-Options
but using it results in unrecognized command line option.
* PR49551 (2/10)
- Found out why r221297 prevents the ICE:
merge_decl() calls make_decl_rtl() upon condtion DECL_RTL_SET_P (olddecl),
which causes the ICE. Before r221297, in merge_decls() DECL_RTL_SET_P
(olddecl) was true which resulted in call to make_decl_rtl() causing
ICE. After r221297, DECL_RTL_SET_P (olddecl) is 0, which doesn't
result in call to make_decl_rtl() so no ICE is produced. However,
DECL_COMMON is still incorrectly set in merge_decls() because it
copies newdecl into olddecl.
- Will post upstream for review after final testing on x86 and ARM.
* Misc (6/10)
- Exams
Short week (2 days off)
== Progress ==
o Upstream GCC (3/6)
* Flags for Cortex-a53 erratum #84341 workaround:
- Backported into FSF 4.9 and 5 branches
* Some cleanup to avoid format-security warnings
* TCWG-786 (LRA and PIC): Look for potential improvements
- nothing found so far.
o Linaro GCC release (2/6)
* Reviewed FSF branch merge into 4.8 branch
* Look at differences between our actual source tarball, and
the ones that can be created by ABE.
o Misc (1/6)
* Various meetings
== Plan ==
- Continue ongoing tasks
Benchmark automation - TCWG-360 [7/10]
* Convinced benchmark scripts to run entirely within LAVA
* Did a couple of benchmark runs for Kugan
* Cleaned up my CPU2000 patches and committed to central repository
Misc [3/10]
=Plan=
Clean up, commit CPU2006 patches
Pick a direction on streaming vs listeners, write down the reasoning
Follow up (close out?) results storage and restricted targets
Write more tests, refactoring where appropriate
If time, and it looks sane, wrap a LAVA job around benchmark scripts
== Progress ==
* Upstream GCC (5/10)
- committed delaying constant splitting in arm after full testing
(TCWG-486)
- Spec benchmarking is still an issue (TCWG-779)
- Bernie agreed to kindly help benchmark it
- taking time due to long lava queue
- Started working on widening pass based on review comments (TCWG-555)
- Wilco from ARM provided some test-cases and looking into it as well
* GCC bootstrap/build issues (4/10)
- Looked at bare-metal
- aarch-elf-none issue
- gcc bootstrap issue with ARM
- middle-end error
- Thanks to all, all now fixed in mainline.
* Misc (1/10)
- gcc-patches, gcc-bugs list
- Meetings
== Plan ==
- Continue with gcc stage1 activities
- Look at register allocation
# Progress #
* TCWG-517, GDB AAarch64 record/replay. Ongoing. [3/10]
Takes over from Omair, complete test cases and update patches.
Rewrite the test case using gcc inline assembly.
Happen to see that AAarch64 doesn't have CPSR register but
GDB thinks it has. This should be fixed separately later.
* Think about GDB version in next linaro toolchain release. [3/10]
The next linaro release is on July/Aug and the next GDB FSF release
7.10 will be on mid of June. I prefer to picking up 7.10, but need
Ryan or Maxim to make a decision.
* Exchange emails with Peter to push GDB kernel awareness work forward,
and think about how do that in next step. [1/10]
* Misc [3/10]
** Print and photocopy documents needed for France visa application.
# Plan #
* Go to France Embassy in London on Monday.
* GDB AAarch64 record/replay test and upstream submission.
--
Yao
Hi,
I tried on abe 'stable' branch and with below configuration build was
successful.
../abe/configure --with-fileserver=148.251.136.42 --with-remote-snapshots=
http://148.251.136.42/snapshots-ref
../abe/abe.sh --target aarch64-linux-gnu --build all
(Additionally I had to increase the wget_timeout=100)
But on master branch, with below commands (as suggested in above mail)
following error were observed.
../abe/configure --with-fileserver=148.251.136.42
--with-remote-snapshots=/snapshots-ref
../abe/abe.sh --target aarch64-linux-gnu --build all
ERROR (#144): fetch_http (md5sums doesn't exist and you disabled updating.)
Looks like following commit is causing problem on the abe master branch.
On removing it, build successfully downloaded the packages from
148.251.136.42.
commit 5a5ab3582851d52d903846d34c79850f5d7ebda5
don't try to fetch anything is updates are disabled.
Thanks
Virendra
On 6 May 2015 at 17:30, <linaro-toolchain-request(a)lists.linaro.org> wrote:
> Send linaro-toolchain mailing list submissions to
> linaro-toolchain(a)lists.linaro.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.linaro.org/mailman/listinfo/linaro-toolchain
> or, via email, send a message with subject or body 'help' to
> linaro-toolchain-request(a)lists.linaro.org
>
> You can reach the person managing the list at
> linaro-toolchain-owner(a)lists.linaro.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of linaro-toolchain digest..."
>
>
> Today's Topics:
>
> 1. Re: 502 connecting to abe.tcwglab.linaro.org (Tim Entinger)
> 2. Re: 502 connecting to abe.tcwglab.linaro.org (Victor Chong)
> 3. [ANNOUNCE] Linaro GCC 4.9 2015.04 snapshot re-spin (Yvan Roux)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 5 May 2015 12:44:44 +0000 (UTC)
> From: Tim Entinger <timothy.entinger(a)jci.com>
> To: linaro-toolchain(a)lists.linaro.org
> Subject: Re: 502 connecting to abe.tcwglab.linaro.org
> Message-ID: <loom.20150505T143929-367(a)post.gmane.org>
> Content-Type: text/plain; charset=us-ascii
>
> Rob Savoye <rob.savoye@...> writes:
>
> >
> > On 04/21/2015 04:23 PM, Christopher Covington wrote:
> > > abe$ ./abe.sh --target aarch64-linux-gnu
> > > NOTE: Downloading md5sums to abe/snapshots
> > > RUN: /usr/bin/wget --timeout=10 --tries=2 --directory-
> prefix=abe/snapshots/ http://abe.tcwglab.linaro.org/snapshots/md5sums
> >
> > We're having a major security related issue, so the entire TCWG lab
> > got taken offline yesterday till this is fixed and more secured. No
> idea
> > what the ETA is for all of that. ABE will work regardless other than
> > some warning messages about not being able to download the md5sums
> file,
> > or anything under 'infrastructure'. Most of what ABE needs is at
> > git.linaro.org, and that's still online. The only files ABE downloads
> > from abe.tcwglab.linaro.org are source tarballs, which don't change
> very
> > often. As long as you have them already downloaded, you can build a
> > toolchain still. I work offline pretty frequently, so have tried to
> make
> > ABE work without the upstream access to anything.
> >
> > Try adding '--disable update' to your command line for abe.sh, and
> > it'll stop trying.
> >
> > - rob -
> >
> > _______________________________________________
> > linaro-toolchain mailing list
> > linaro-toolchain <at> lists.linaro.org
> > https://lists.linaro.org/mailman/listinfo/linaro-toolchain
> >
>
>
> Is there any update for when the TCWG lab will be back online? I was
> trying to use ABE for the first time and got the 503 Service Unavailable
> message. Is there a way to specify different locations for the source
> tarballs in the meantime? I'm hoping to work around the issue if a
> timeline is still unknown.
>
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 5 May 2015 23:12:28 +0900
> From: Victor Chong <victor.chong(a)linaro.org>
> To: Tim Entinger <timothy.entinger(a)jci.com>
> Cc: Linaro Toolchain Mailman List <linaro-toolchain(a)lists.linaro.org>
> Subject: Re: 502 connecting to abe.tcwglab.linaro.org
> Message-ID:
> <CAHqM-QhhZw9hw33Mzf8iFtSDEdiX3NnLUMqvLt=v9JKHZgfa=
> Q(a)mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi Tim,
>
> On Tue, May 5, 2015 at 9:44 PM, Tim Entinger <timothy.entinger(a)jci.com>
> wrote:
>
> > Rob Savoye <rob.savoye@...> writes:
> >
> > >
> > > On 04/21/2015 04:23 PM, Christopher Covington wrote:
> > > > abe$ ./abe.sh --target aarch64-linux-gnu
> > > > NOTE: Downloading md5sums to abe/snapshots
> > > > RUN: /usr/bin/wget --timeout=10 --tries=2 --directory-
> > prefix=abe/snapshots/ http://abe.tcwglab.linaro.org/snapshots/md5sums
> > >
> > > We're having a major security related issue, so the entire TCWG lab
> > > got taken offline yesterday till this is fixed and more secured. No
> > idea
> > > what the ETA is for all of that. ABE will work regardless other than
> > > some warning messages about not being able to download the md5sums
> > file,
> > > or anything under 'infrastructure'. Most of what ABE needs is at
> > > git.linaro.org, and that's still online. The only files ABE downloads
> > > from abe.tcwglab.linaro.org are source tarballs, which don't change
> > very
> > > often. As long as you have them already downloaded, you can build a
> > > toolchain still. I work offline pretty frequently, so have tried to
> > make
> > > ABE work without the upstream access to anything.
> > >
> > > Try adding '--disable update' to your command line for abe.sh, and
> > > it'll stop trying.
> > >
> > > - rob -
> > >
> > > _______________________________________________
> > > linaro-toolchain mailing list
> > > linaro-toolchain <at> lists.linaro.org
> > > https://lists.linaro.org/mailman/listinfo/linaro-toolchain
> > >
> >
> >
> > Is there any update for when the TCWG lab will be back online? I was
> > trying to use ABE for the first time and got the 503 Service Unavailable
> > message. Is there a way to specify different locations for the source
> > tarballs in the meantime? I'm hoping to work around the issue if a
> > timeline is still unknown.
> >
>
> We've setup an alternate server for the source tarballs for now. Configure
> master with '--with-fileserver=148.251.136.42
> --with-remote-snapshots=/snapshots-ref' to use it.
>
>
> >
> > _______________________________________________
> > linaro-toolchain mailing list
> > linaro-toolchain(a)lists.linaro.org
> > https://lists.linaro.org/mailman/listinfo/linaro-toolchain
> >
>
Hi Guys,
I have two questions:
(1) I have download gcc-4.9 tool chain from
http://releases.linaro.org/14.08/components/toolchain/binaries.
The kernel for the release
(http://releases.linaro.org/14.08/components/kernel/linux-linaro) is
3.16. So can we assume the kernel headers found in the tool chain
installation from the link above belongs to linux version 3.16?
(2) Also, I ubuntu wiki indicates that starting with Ubuntu 12.04 they
are using linaro gcc packages for arm64
(https://wiki.ubuntu.com/ToolChain). Is there an easy way to find what
linaro-release (for tool chain) will be compatible with Ubuntu 14.10
aarch64 image?
Thanks,
Aravind
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
Short week (off Thu/Fri - 4/10)
== Progress ==
* GCC trunk (1/10)
- investigated bare-metal broken builds for aarch64 and arm
(--with-mode=thumb)
Setting LDFLAGS_FOR_TARGETS=-specs=rdimon.specs fixes the
libstdc++ build problem for aarch64. Not sure if that's expected.
* Neon intrinsics tests (2/10)
- submitted a new set of tests for review
* 4.8-2015.04
- branch merge committed after validation
* Validation (1/10)
- looking at tests instabilities
* Misc (2/10)
- meetings, conf-calls, emails, ....
== Next ==
* Neon intrinsics tests
* GCC trunk/bare metal
* Validation
== Progress ==
LLDB development
-- Finished most of work for ARM watchpoints and hardware breakpoints
[3/10] [TCWG-770]
-- Added hardware breakpoint handlers for AArch64 [1/10] [TCWG-771]
-- Debugging for ARM watchpoints not hitting the hardware watchpoint
Set/Clear handlers. [3/10] [TCWG-770]
-- Setting up development environment on Google Nexus 7 Android device. [1/10]
Miscellaneous [2/10]
-- Meetings, emails, discussions etc.
-- Submission of French visa application
== Plan ==
LLDB development
-- Submit ARM and AArch64 hardware breakpoint and watchpoints code for review
-- Fix issues with hardware watchpoints and try to run tests on Nexus 7
-- Figure out debugging using gdb on Nexus 7
Miscellaneous
-- Travel to Islamabad for visa interview, out of office on
wednesday 13th May 2015.
-- Half day out of office on Monday 11th and Tuesday 12th May due to
power outage in the area.
Short week: Friday off
== Progres ==
* Linaro-GCC 4.8-2015.04
- have to redo the fsf-4.8 branch merge
- results stability issue, probably caused by a race condition in
the testsuite similar to one already fixed by Maxim
* Validation
- a few updates to our jobs on ci.linaro.org
* Neon intrinsics tests
- resumed port of existing testsuite to GCC
* Misc
- meetings, conf-calls, emails, ....
== Next ==
Short week (Thu/Fri off)
* Linaro-GCC-4.8-2015.04
* Neon intrinsics tests
Friday off (WWII Memorial Day)
== Issue ==
* none
== Progress ==
o Upstream GCC (4/8)
* [TCWG-762] - GCC Maintenance
- PR64208 (iWMMXT LRA bug):
Committed in trunk.
- PR65924 (ICE on arm-none-eabi):
Fixed and committed at rev. 22572
* Flags for Cortex-a53 erratum #84341 workaround:
- Committed in trunk
- To be backported into FSF 5.1 and 4.9 branches
o 2015.04 re-spin (2/8)
* Snapshot tarball deployed
o Misc (2/8)
* Various meetings
* Reviewed and validated a libunwind ARM patch
* Played a bit with docker AArch64 image (based on UMEQ)
https://registry.hub.docker.com/u/mickaelguene/arm64-debian/
== Plan ==
- Short week (off Thu, and Fri)
- Continue upstream pending work
(Public) Holiday [2/10]
Benchmark automation - TCWG-360 [6/10]
* More unit tests
* Refactoring - test writing is an effective spotlight
* Experimented with LAVA log streaming as a 'listener' replacement
** Reduces complexity, for (possibly insignificant) costs in
generality and scalability
* Gave some thought to results storage, benchmarking of restricted targets
Misc [2/10]
=Plan=
Pick a direction on streaming vs listeners, write down the reasoning
Follow up (close out?) results storages and restricted targets
Write more tests, refactoring where appropriate
Holiday [2/10]
Benchmark automation - TCWG-360 [5/10]
* Finished rolling backbench patches into review
* Submitted some test suite patches to reduce the number of untested cases
* Began writing tests for benchmarking in general
Misc [3/10]
== Progress ==
* Upstream GCC (4/10)
- TCWG-779 Vector rtx costs for AArch64 ACKed to commit.
- Asked to do fresh regression and benchmarking
- re-based to latest trunk
- Trunk is broken and narrowed down the failure to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66066
- Fixed and regression testing finished. Setting up benchmarking for
spec2k before committing.
* IRA (5/10)
- Looked at https://bugs.linaro.org/show_bug.cgi?id=540 (TCWG-773
Median of three has unneeded register moves)
- https://bugs.linaro.org/show_bug.cgi?id=1532
* Misc (1/10)
- gcc-patches, gcc-bugs list
- Meetings
== Plan ==
- Continue with gcc stage1 activities
- Look at register allocation
== This week ==
* PR49551 (2/10)
- Created new patch: http://pastebin.com/PsLTgvp7
- merge_decls() calls memcpy to copy newdecl into olddecl thus
overriding DECL_COMMON in olddecl which is the source of the bug.
If newdecl has common/nocommon attribute set, honor it,
else DECL_COMMON would be set if both olddecl and newdecl have DECL_COMMON set.
- Bootstrapped on x86, tested on x86, arm
- Not yet figured out why r221297 masks this bug.
* TCWG-619 (4/10)
- managed to build chromium LTO on ARM, requires disabling components
enabled by variable 'chromium_code'. Size of chrome executable reduces
by 8 mb.
- the bug: "error out of range" appears only during LTO build of
components enabled by chromium_code. Results in very few instances of
the same error message when LTO build for chromium_code components.
- Disabling LTO in sandbox.gyp and passing -flto results in following error:
/tmp/ccYJJbUK.ltrans25.ltrans.o:<artificial>:vtable for
blink::WebDocument [clone .lto_priv.89343]: warning: relocation refers
to discarded section
/home/prathamesh.kulkarni/fsf-toolchain/lib/gcc/x86_64-unknown-linux-gnu/6.0.0/../../../../x86_64-unknown-linux-gnu/bin/ld.gold:
error: hidden symbol '_ZN5blink11WebDocumentD1Ev' is not defined
locally
Also present for x86.
The workaround is to pass -flto --param lto-partitions=1 as mentioned
in PR57703.
- gold ICE with v8 LTO build for ARM not reproducible with master branch.
- Trying to use Martin Liska's scripts for gathering build stats:
https://github.com/marxin/script-misc/blob/master/system_top.pyhttps://github.com/marxin/script-misc/blob/master/vmstat_parser.py
* Misc (4/10)
- Exams preparation
- Visa application
== Next Week ==
- PR49551: figure out why r221297 masks the bug, write test-cases and
submit patch upstream
- chromium/v8 build stats
- exams
* UK bank holiday on Monday [2/10]
# Progress #
* arm/aarch64 gdb bug fixing [1/10].
** TCWG-765 fails in gdb.base/coredump-filter.exp. Patch is
pushed it in.
** TCWG-767, patch is pushed it in.
* TCWG-805, aarch64 native debugging multi-arch support. [2/10].
Let arm use newer ptrace PTRACE_GETREGSET in order to align with
aarch64. Ongoing.
* Think about debugging programs on different exception levels
(EL3, EL2 and EL1). Read doc about EL in aarch64.
Looks they need multi-inferior debugging. Request more details.
[2/10]
* Misc [3/10]
** Book travel and get travel insurance. It is my first travel in ARM,
familiarise myself with the travel process.
** Visa application.
# Plan #
* TCWG-805, aarch64 native debugging multi-arch support.
* Other things needed for visa application.
--
Yao
Hi Linaro Toolchain Group,
I am new to gcc development. I am trying to write a new md file describing
pipeline information for a processor.
Please suggest some good reference document for understanding machine
description file.
Few questions from cortex-a53.md file:
For first integer pipeline following is defined - (define_cpu_unit
"cortex_a53_slot0" "cortex_a53")
Is name cortex_a53_slot0 is a keyword or it is any general string?
Is there any convention in choosing names for cpu units?
If ‘cortex_a53_slot0’ a general string, how assembler knows it is first
integer pipeline?
How these *.md files are used? When they are compiled and how they are used?
How to verify an md file for a processor is written correctly or not? How
to test it?
What other design consideration must be kept in mind while writing a new md
file?
Thanks.
with regards,
Virendra Kumar Pathak
This is a re-spin of the Linaro GCC 4.9 2015.04 source package snapshot.
The re-spin of this snapshot includes a new configure-time option to enable by
default a workaround for Cortex-A53 erratum number 843419 and options to
explicitly disable or enable it during compilation.
This snapshot tarball is available on:
http://snapshots.linaro.org/components/toolchain/gcc-linaro/4.9-2015.04-1
Original release notes for GCC 4.9 2015.04 snapshot:
The Linaro Toolchain Working Group (TCWG) is pleased to announce the 2015.04
snapshot of the Linaro GCC 4.9 source package.
Linaro GCC 4.9 2015.04 is the first Linaro GCC source package snapshot in the
4.9 series. It is based on FSF GCC 4.9.3-pre+svn222035 and includes performance
improvements and bug fixes.
With the imminent release of ARMv8 hardware and the recent release of the
GCC 4.9 compiler the Linaro TCWG will be focusing on stabilization and
performance of the compiler as the FSF GCC compiler. The Linaro TCWG provides
stable[1] quarterly releases and monthly snapshots[2].
Interesting changes in this GCC source package snapshot include:
* Linaro bugzilla PR fixed: #415, #1382, #1391
* Updates to GCC 4.9.3-pre+svn222035
* Backport of instruction scheduler improvements
* Backport of [AArch64,Neon] Add patterns + builtins for vld[234](q?)_lane_*
intrinsics
* Backport of [AArch64] Implement fusion adrp+add/movk+movk
* Backport of [AArch32] Cortex-A17 support
* Backport of [AArch64] Fix __builtin_aarch64_absdi, must not fold to ABS_EXPR
* Backport of PR rtl-optimization/63917
* Backport of PR tree-optimization/62178 tree-ssa-loop-ivopts
* Backport of [AArch64] Add TARGET_MIN_DIVISIONS_FOR_RECIP_MUL
* Backport of [AArch64] Simplify patterns for sshr_n_[us]64 intrinsic
* Backport of [AArch64] Simplify+improve patterns for ushr(d?)_n_u64 intrinsic
* Backport of [AArch32] Fix reservation pattern in cortex-a9-neon.md
* Backport of [AArch64] Don't disparage add/sub in SIMD registers
* Backport of [AArch64] Add SIMD-reg variants of logical operators
and/ior/xor/not
* Backport of [AArch64] Fix XOR_one_cmpl pattern; add SIMD-reg variants for
BIC,ORN,EON
* Backport of [AArch32] Use Cortex-A17 tuning parameters for Cortex-A12
* Backport of [AArch32] Make CLZ_DEFINED_VALUE_AT_ZERO and
CTZ_DEFINED_VALUE_AT_ZERO return 2.
* Backport of [AArch32] Minor optimization on thumb2 tail call
* Backport of [AArch64] Update APM/XGene-1
* Backport of [AArch64] Add a new scheduling description for the ARM Cortex-A57
processor
* Backport of [AArch64] Fix PR 64263: Do not try to split constants when
destination is SIMD reg
* Backport of [AArch64] Add support for -mcpu=cortex-a72
This snapshot tarball is available on:
http://snapshots.linaro.org/components/toolchain/gcc-linaro/4.9-2015.04
Feedback and Support
Subscribe to the important Linaro mailing lists and join our IRC channels to
stay on top of Linaro development.
** Linaro Toolchain Development "mailing list":
http://lists.linaro.org/mailman/listinfo/linaro-toolchain
** Linaro Toolchain IRC channel on irc.freenode.net at @#linaro-tcwg@
* Bug reports should be filed in bugzilla against GCC product:
http://bugs.linaro.org/enter_bug.cgi?product=GCC
* Interested in commercial support? inquire at "Linaro support":
mailto:support@linaro.org
[1] Stable source package releases are defined as releases where the full Linaro
Toolchain validation plan is executed.
[2] Source package snapshots are defined when the compiler is only put through
unit-testing and full validation is not performed.
Hi,
We've had trouble using ABE recently.
abe$ ./abe.sh --target aarch64-linux-gnu
NOTE: Downloading md5sums to abe/snapshots
RUN: /usr/bin/wget --timeout=10 --tries=2 --directory-prefix=abe/snapshots/ http://abe.tcwglab.linaro.org/snapshots/md5sums
--2015-04-21 16:02:33-- http://abe.tcwglab.linaro.org/snapshots/md5sums
Resolving abe.tcwglab.linaro.org (abe.tcwglab.linaro.org)... 81.128.185.43
Connecting to abe.tcwglab.linaro.org (abe.tcwglab.linaro.org)|81.128.185.43|:80... connected.
HTTP request sent, awaiting response... 502 cannotconnect
2015-04-21 16:02:42 ERROR 502: cannotconnect.
Thanks,
Chris
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
== Progress ==
LLDB development
-- Wrote hardware breakpoint handlers for NativeLinuxRegisterContext
ARM [2/10] [TCWG-770]
-- Debugging for issues and code cleanup AArch64 LLDB watchpoint
support [2/10] [TCWG-771]
-- Fix, test, debug, cleanup and patch re-submission. [1/10]
-- Resubmitted, update and commited ARM SysV ABI implementation.
[TCWG-643]
-- Resubmitted, update and commit AArch64 SysV ABI
implementation. [TCWG-715]
-- Setting up android test environment [TCWG-651]
GDB development [1/10] [TCWG-677]
-- Clean-up arm-linux record replay test cases
Miscellaneous [2/10]
-- Meetings, emails, discussions etc.
-- Toolchain Sprint travel bookings and visa application preparation.
Public Holiday [2/10]
-- Friday 1st May 2015 (Labor Day)
== Plan ==
LLDB development
-- Complete work on AArch64 watchpoints and hardware breakpoints
-- Hopefully submit ARM watchpoint work may be later in the week.
-- Figure out android development
Miscellaneous
-- Complete and submit France visa application
GDB development
-- Gather ARM/AArch64 record-replay testsuite work and submit patches for yao.
- Public holiday (2/10)
== Progress ==
* Upstream GCC (3/10)
- TCWG-796 Zero/sign extension elimination with vrp.
- TCWG-555 posted patch for compiler pass to widen computation to
back-end promoted mode
* IRA (4/10)
- Looked at https://bugs.linaro.org/show_bug.cgi?id=540 (TCWG-773
Median of three has unneeded register moves)
* Misc (1/10)
- gcc-patches, gcc-bugs list
- Meetings
== Plan ==
- Continue with gcc stage1 activities
- Look at register allocation
== This week ==
* TCWG-619 (8/10)
PR65858
- workaround: add explicit casts in the file cld_generated_cjk_uni_prop_80.cc
- created reduced test case: http://pastebin.com/WJvKRjn2
- commit r222249 introduced the issue
- patch submitted upstream:
https://gcc.gnu.org/ml/gcc-patches/2015-04/msg02063.html
- Paolo Carlini pointed out it doesn't work with -w option, instead of testing
on warn_narrowing flag, he modified it to check on pedwarn()'s return
value, which
covers up for both -Wno-narrowing and -w, and committed with
this modification (r222700).
PR65837
- patch to lto-wrapper rejected.
- Another hack to pass driver's argv to lto-wrapper via another
environment variable
COLLECT_GCC_OPTIONS_DRIVER rejected by Richard.
- Ramana and Richard pointed out the proper fix would be to handle
target attributes in ARM backend.
- I could try extending Christian Bruel's target attribute patches for
fpu options
after they're checked in which would then fix the PR.
chromium LTO build
- Many instances of same error message during LINK chrome:
chrome.ltrans0.s:18399164: Error: Thumb2 branch out of range
chrome.ltrans0.s:9671243: Error: branch out of range
works fine for non-lto.
A similar issue, occurred for v8 LTO build - PR65778, but
it was marked resolved invalid.
- chromium builds with LTO for chrome component.
- ld.bfd segfault while building chromium with LTO not reproducible with master.
- non-LTO build undefined reference to libattr1 functions not reproducible with
ld.bfd master. This probably was sysroot/libc issue than issue with ld.bfd.
* PR49551 (2/10)
- reverting r221297 reproduces the ICE
- tried to fix with following patch:
http://pastebin.com/knuWeY0C
- fixes the ICE but following regressions observed on arm-linux-gnueabihf:
http://pastebin.com/E1zLtq8s
== Issues ==
- Can't login to cards.linaro.org (was able to before).
I get error - "You do not have permission to login".
== Next Week ==
- Investigate testsuite failures for PR49551
- Selectively enable LTO on components in chromium.
- exams preparation
* Half day leave on Thu, [1/10].
# Progress #
* arm/aarch64 gdb bug fixing. [3/10]
** TCWG-765, fails in gdb.base/coredump-filter.exp. No progress, as no
one reviews the patch.
** TCWG-672, fails in gdb.base/relativedebug.exp, fixed.
** TCWG-567, fails in gdb.base/break-idempotent.exp, fixed.
** TCWG-767, Propose to disable target-side evaluation of breakpoint
condition for software single step targets. Patch is posted.
* TCWG-805, aarch64 gdb multi-arch support, [2/10]
* TCWG-729, investigate GDB multi-target support, [2/10]
* TCWG-757, upstream patch review, [1/10]
* Misc [1/10]
** Meeting,
** Fill online forms for France visa application,
** Book travel to Grenoble.
# Plan #
* Public holiday on Monday.
* TCWG-805, aarch64 gdb multi-arch support,
* TCWG-729, investigate GDB multi-target support,
* other arm/aarch64 gdb test fails fixing.
--
Yao
benchmark automation - TCWG-360 [3/10]
* Shifted more generic patches from backport branch to review
* One complete run of backport benchmarking before lab went down
Misc [7/10]
* Most of this (4 or 5 tenths) is reaction to lab downtime
=Plan=
Benchmarking test suite
Fish out, finish off thoughts about benchmark access control
NB Next Monday (4th May) is a public holiday in UK
== Progress ==
LLDB development
-- Debugging test code for hardware breakpoint/watchpoint issues on
chromebook for ARM LLDB support [4/10] [TCWG-770]
-- Wrote native process linux helpers for arm and aarch64 hardware
breakpoints [2/10] [TCWG-770] [TCWG-771]
-- Fix, test, debug, cleanup and patch re-submission. [3/10]
-- LLDB ARM SysV ABI implementation. [TCWG-643]
-- LLDB AArch64 SysV ABI implementation. [TCWG-715]
-- Native process linux bug fixes [TCWG-651]
Miscellaneous [1/10]
-- Upstream reviews
-- Meetings, emails, discussions etc.
== Plan ==
LLDB development
-- At least submit lldb arm hardware breakpoint native process linux
helper functions
-- Resubmit register read/write bug fix after changes
-- Resubmit LLDB ARM SysV ABI implementation.
-- Resubmit LLDB AArch64 SysV ABI implementation.
-- Bug fixing, patch reviews etc
== This Week ==
* TCWG-619:
* abe sysroot/libc issue
While building chromium with development build of toolchain on
arm-linux-gnueabihf, I get the following error:
undefined reference to clock_gettime()
Builds fine with release toolchain build.
Symlinking libc in toolchain install directory to
sysroots/arm-linux-gnueabihf appears to work (which is what --tarbin
did).
* PR65778 - v8 fails to build with LTO
- Resolved Invalid
* PR65837 - target specific builtin not available
- created a reduced test case
- There's a weird issue: looks like for lto1, translation unit command
line options,
precede the default ones rather than overriding them.
Assume test.c contains a neon intrinsic:
arm-linux-gnueabihf-gcc -flto -c test.c -mfpu=neon
arm-linux-gnueabihf-gcc -flto test.o
results in target specific builtin not available,
because both -mfpu=neon and -mfpu=vfpv3-d16 is passed
and -mfpu=vfpv3-d16 overrides earlier -mfpu=neon
Passing -mfpu=neon at link time correctly overrides -mfpu=vfpv3-d16.
* PR6778 - ICE in varpool_node::get_constructor.
- Looks like PR65776 appears due to same issue as well.
- It appears error_mark_node gets streamed that causes ICE.
- Triage went wrong, thought it was an error in typeck2.c:check_narrowing().
* PR49551
- The C front-end c/c-decl.c:merge_decls still incorrectly marks the
variable as 'common' for the test-case:
int x = 5;
int x;
However it's not reproducible anymore on trunk (maybe latent?)
- I have an untested patch that resolves the issue in merge_decls().
* Issues
- abe built native gcc on x8_64-unknown-linux-gnu fails to build code
when passed -m32 option (bug 1508).
* Misc
- exams on 20th and 24th april.
* Next week
- Continue working on PR65837, PR65778
- Test patch for PR49551
== Issue ==
* none
== Progress ==
o Upstream GCC (8/10)
* [TCWG-785] ARM backend insn cleanup
- Validate and re-worked the patch
- About to be submitted upstream
* [TCWG-762] - GCC Maintenance
- PR64208 (iWMMXT LRA bug):
Found hardware to validate the fix (Thanks Riku :)
Validation ongoing
* Lot of time wasted due to lab compromisation
o Misc (2/10)
* Various meetings
* GCC git repository branches cleanup
== Plan ==
- Continue cleaning GCC git repo to prepare our migration
- Continue upstream pending work
== Progress ==
* Upstream GCC (9/10)
- TCWG-780 - Improve register allocation for
aarch64_*_sisd_or_int<mode>3 patterns.
- TCWG-486 - Optimize Constant Uses in Loops. Posted the arm part of
the patch that addresses review comments after full testing. Waiting for
the cprop review.
- TCWG-796 Zero/sign extension elimination with vrp. Posted the new set
of patches for review. Looking at the testcases H.J.L. pointed me to.
- TCWG-779 Vector rtx costs for AArch64. Posted the patch that
addresses review comments after full testing.
* Misc (1/10)
- gcc-patches, gcc-bugs list
- Meetings
== Plan ==
- Continue with gcc stage1 activities
- Monday public holiday
# Progress #
* arm/aarch64 gdb bug fixing. [5/10]
** PR 18208 (TCWG-765) fails in gdb.base/coredump-filter.exp. Workaround
tricky quote issue with dejagnu/tcl/ssh/bash. A RFC is posted out.
** Fails in gdb.base/relativedebug.exp (TCWG-672), patch is posted out
review.
** Fails in gdb.base/break-idempotent.exp. Skip some tests in it which
require more than one HW watchpoint registers, while arm-linux only
has one. Patch is posted out.
** TCWG-793, do experiment with showing LSB of address in thumb mode inside GDB,
in order to align with MIPS(microMIPS/MIPS16). It needs more work
than expected, and even out the scope of GDB. It is paused.
* FSF GDB patch review. [4/10]
** Review "all stop on top of non stop" V3, done.
** Review "memory-mapped register browsing" patch. Requested more
information from the author.
* Misc, meeting. [1/10] # Plan # * Fix test fails for arm and aarch64 gdb.
* Continue my HW watchpoint resource counting patches once linaro boxes
are online. These boxes don't have HW watchpoint support, and GDB
doesn't handle this case well.
* Upstream patches review.
--
Yao Qi
== Progress ==
LLDB development
-- Some progress on hardware watchpoint support for lldb arm linux.
[1/10] [TCWG-770]
-- Some progress on hardware watchpoint support for lldb aarch64
linux. [1/10] [TCWG-771]
-- LLDB ARM SysV ABI implementation. [4/10] [TCWG-643]
- Testing and updates with upstream suggestion
- Figuring out a method to handle thumb functions unwind information.
-- LLDB ARM: Bug fixes. [3/10] [TCWG-651]
Miscellaneous [1/10]
-- Upstream reviews
-- Meetings, emails, discussions etc.
== Plan ==
LLDB development
-- Progress towards hardware watchpoint support for lldb arm linux.
-- Progress towards hardware watchpoint support for lldb aarch64 linux.
-- Bug fixing, patch reviews etc
Hi all,
I have built our customized u-boot (u-boot-2012.10-rc3), with two Linaro toolchain, but have no luck with the latest toolchain.
The u-boot built with gcc-linaro-arm-none-eabi-4.9-2014.09_linux can boot on the development board. This toolchain was pre-built toolchain from Linaro, built with crosstool-NG. The version is gcc version 4.9.2 20140904 (prerelease) (crosstool-NG linaro-1.13.1-4.9-2014.09 - Linaro GCC 4.9-2014.09)
With the same u-boot source, the binary built with the Linaro gcc 4.9 2015.04 hang on the same board. The 2nd toolchain was compiled locally on RHEL6, built with ABE tool. We build it locally to avoid "GLIBC_2.14 not found" issue on the pre-built toolchain. The version is gcc version 4.9.3 20150413 (prerelease) (Linaro GCC 2015.04)
Does anyone have an idea what happen? Is it a regression bug in gcc4.9?
Thanks,
Joel
--------------------------------------------------------
[joelz@ldt-joelz]:$ /projects/broadcom-linux/shared/toolchains/gcc-linaro-arm-none-eabi-4.9-2014.09_linux/bin/arm-none-eabi-gcc -v
Using built-in specs.
COLLECT_GCC=/projects/broadcom-linux/shared/toolchains/gcc-linaro-arm-none-eabi-4.9-2014.09_linux/bin/arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/projects/broadcom-linux/shared/toolchains/gcc-linaro-arm-none-eabi-4.9-2014.09_linux/bin/../libexec/gcc/arm-none-eabi/4.9.2/lto-wrapper
Target: arm-none-eabi
Configured with: /cbuild/slaves/oorts/crosstool-ng/builds/arm-none-eabi-linux/.build/src/gcc-linaro-4.9-2014.09/configure --build=i686-build_pc-linux-gnu --host=i686-build_pc-linux-gnu --target=arm-none-eabi --prefix=/cbuild/slaves/oorts/crosstool-ng/builds/arm-none-eabi-linux/install --with-local-prefix=/cbuild/slaves/oorts/crosstool-ng/builds/arm-none-eabi-linux/install/arm-none-eabi --without-headers --with-newlib --enable-threads=no --disable-shared --with-pkgversion='crosstool-NG linaro-1.13.1-4.9-2014.09 - Linaro GCC 4.9-2014.09' --with-bugurl=https://bugs.launchpad.net/gcc-linaro --disable-__cxa_atexit --with-gmp=/cbuild/slaves/oorts/crosstool-ng/builds/arm-none-eabi-linux/.build/arm-none-eabi/build/static --with-mpfr=/cbuild/slaves/oorts/crosstool-ng/builds/arm-none-eabi-linux/.build/arm-none-eabi/build/static --with-mpc=/cbuild/slaves/oorts/crosstool-ng/builds/arm-none-eabi-linux/.build/arm-none-eabi/build/static --with-isl=/cbuild/slaves/oorts/crosstool-ng/builds/arm-none-eabi-linux/.build/arm-none-eabi/build/static --with-cloog=/cbuild/slaves/oorts/crosstool-ng/builds/arm-none-eabi-linux/.build/arm-none-eabi/build/static --with-libelf=/cbuild/slaves/oorts/crosstool-ng/builds/arm-none-eabi-linux/.build/arm-none-eabi/build/static --enable-lto --enable-linker-build-id --enable-libmudflap --disable-libgomp --enable-libssp --disable-libstdcxx-pch --enable-multilib --enable-languages=c,c++,fortran --with-multilib-list=aprofile
Thread model: single
gcc version 4.9.2 20140904 (prerelease) (crosstool-NG linaro-1.13.1-4.9-2014.09 - Linaro GCC 4.9-2014.09)
---------------------------------------------
[joelz@ldt-joelz]:$ /projects/toolchains/gcc-4.9-rhel6-local-build/bin/arm-linux-gnueabi-gcc -v
Using built-in specs.
COLLECT_GCC=/projects/toolchains/gcc-4.9-rhel6-local-build/bin/arm-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=/projects/toolchains/abe/_build/builds/destdir/x86_64-unknown-linux-gnu/libexec/gcc/arm-linux-gnueabi/4.9.3/lto-wrapper
Target: arm-linux-gnueabi
Configured with: '/projects/toolchains/abe/_build/snapshots/gcc.git~linaro-4.9-branch/configure' SHELL=/bin/sh --with-bugurl=https://bugs.linaro.org --with-mpc=/projects/toolchains/abe/_build/builds/destdir/x86_64-unknown-linux-gnu --with-mpfr=/projects/toolchains/abe/_build/builds/destdir/x86_64-unknown-linux-gnu --with-gmp=/projects/toolchains/abe/_build/builds/destdir/x86_64-unknown-linux-gnu --with-gnu-as --with-gnu-ld --disable-libstdcxx-pch --disable-libmudflap --with-cloog=no --with-ppl=no --with-isl=no --disable-nls --enable-multiarch --disable-multilib --enable-c99 --with-tune=cortex-a9 --with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=softfp --with-mode=thumb --with-build-sysroot=/projects/toolchains/abe/_build/sysroots/arm-linux-gnueabi --enable-lto --enable-linker-build-id --enable-long-long --enable-shared --with-sysroot=/projects/toolchains/abe/_build/builds/sysroot-arm-linux-gnueabi --enable-languages=c,c++,fortran,lto --enable-fix-cortex-a53-835769 --enable-checking=yes --disable-bootstrap --with-bugurl=https://bugs.linaro.org --with-pkgversion='Linaro GCC 2015.04' --build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu --target=arm-linux-gnueabi --prefix=/projects/toolchains/abe/_build/builds/destdir/x86_64-unknown-linux-gnu
Thread model: posix
gcc version 4.9.3 20150413 (prerelease) (Linaro GCC 2015.04)
Hi,
I am using the linaro tolchain to create a root-filesystem for an embedded
Linux system.
I would like to copy the essential include files and libraries(libc) from
the toolchain to the rootFS of the embedded system.
Is there any explanation of the folder structure of the toolchain so I know
which folder to copy?
How do I know which files to copy and where those files are located in the
toolchain?
Thanks,
Robert
Hello,
In an effort to provide a longer quality control window for quarterly
releases the Linaro Toolchain Working Group will be making some changes to
the release process starting with the forthcoming 2015.04 products.
Little will change for the consumers of TCWG products.
The current monthly source release of the 'stable' Linaro GCC source
archives posted to releases.linaro.org will move to snapshots.linaro.org
and will be designated 'monthly snapshots'.
The exact location will be announced when the 2015.04 Toolchain component
source archive release notes are posted to this mailing list.
These monthly snapshots will continue to have branch merges, performance
fixes, security fixes, and correctness fixes applied on a monthly basis.
They will also continue to have validation across a variety of common ARM
targets performed (per backport) against them.
TCWG will introduce the concept of a 'release candidate source archive' and
'release candidate binary toolchain archive' six weeks before the projected
release date of the Quarterly Binary Toolchain Release. For example, the
2015.05 Quarterly Binary Toolchain and Quarterly Source Archive will be
based upon the 2015.04 source archive snapshot.
Release candidate source and binary archives will be posted to
snapshots.linaro.org.
This release candidate will receive the scrutiny of internal and external
stakeholders for six weeks and give an opportunity to evaluate the
forth-coming Quarterly Binary Toolchain Archive and Source Archive
Release. Problems found with the release candidates will result in the
availability of incremental release candidate archives.
The official quarterly release will be posted to releases.linaro.org.
Please direct any questions or concerns to this mailing list or to me
directly.
--
Ryan S. Arnold
Linaro Toolchain Working Group - Engineering Manager
www.linaro.org
Benchmark automation - TCWG-360 [5/10]
* Flushed the rest of the easy stuff from my 'small fixups' to my
'staging' branch
* Started rolling generic patches from my backport-benchmark branch into gerrit
* Prodded at the prototype backport-benchmark job until the pieces worked
** Ran out of time to try an end-to-end run
* Thought a little about permissions for access to source/results
* Use of nc.traditional appears to have introduced a race condition
catomics - TCWG-436 [2/10]
* Tried a run on A15 - same story as A57, good improvement on g8 libc
ubenchmark that doesn't translate into SPEC subset
* Performance counting the ubenchmark suggests variation around cache
accesses on the catomic vs not-catomic code, didn't have any time to
think about what, if anything, this means
Misc [3/10]
* Featuring an unusual level of ARM interruption
* Especially concerns about change from multiarch to non-multiarch
sysroot in binary releases
=Plan=
Confirm backport benchmarking working, roll remaining generic patches
into gerrit
Investigate the nc.traditional race
Add a retry loop around LAVA boot (occasionally see LAVA-fail here)
Create unit tests
Follow up on (non-)multiarch sysroot issue
=== Progress ===
* Get TSAN building for Aarch64 on 42-bit VMA systems. (4/10) (-pie mode only)
Expected Passes : 253
Expected Failures : 2
Unsupported Tests : 1
Unexpected Failures: 13
The failures are categorized into three types.
(1) setjmp and longjmp implementation in assembly needs to written for Aarch64 .
ThreadSanitizer :: longjmp.cc
ThreadSanitizer :: longjmp2.cc
ThreadSanitizer :: longjmp3.cc
ThreadSanitizer :: longjmp4.cc
ThreadSanitizer :: signal_longjmp.cc
(2) FATAL: ThreadSanitizer: failed to intercept pthread_cond_init. I
need to debug and see why this happens.
ThreadSanitizer :: bench_mutex.cc
ThreadSanitizer :: cond.c
ThreadSanitizer :: cond_cancel.c
ThreadSanitizer :: cond_race.cc
ThreadSanitizer :: cond_version.c
ThreadSanitizer-Unit :: rtl/TsanRtlTest/Posix.CondBasic
(3) TLS descriptions ThreadDescriptorSize (), GetTls () and ThreadSelf
() defintions are needed for aarch64.
tls_race.cc
tls_race2.cc
Some ptrace defintions are needed PTRACE_GETREGS, PTRACE_SETREGS
PTRACE_GETFPREGS, PTRACE_SETFPREGS for sanitizer, but they are not
implemented for Aarch64. I am planning to switch off that code in
TSAN.
* ASAN/TSAN documentation. ASAN documentation complete. TSAN in progress. (4/10)
* Emails, meetings. (2/10)
* Linaro 1-1 with christophe, Ryan.
* AMD meetings/event, 1-1 with AMD manager, status meeting.
* GCC mailing list.
===Plan ===
Complete TSAN documentation.
Analyze remaining failures for TSAN.
Push LLVM tree to git.linaro.org for handover.
* Backports (3/10)
- Backports validated and commited to SVN for April release
- 219724 - Add a new scheduling description for the ARM
Cortex-A57 processor
- 219746 - Fix broken 219724
- 220103 - A57 pipeline model
- 220399 - Add support for -mcpu=cortex-a72 and
-mcpu=cortex-a72.cortex-a53
- 220413 - Add support for -mcpu=cortex-a72
* Illness (6/10)
* Misc (1/10)
- Conference calls
== Next week ==
- Begin backports for May release
- Continue TCWG 110 investigation
== This Week ==
TCWG-619:
* Compiled chromium on ARM without LTO with following hack to resolve
error: undefined reference to 'clock_gettime', version 'GLIBC_2.17'
- chromium uses prebuilt sysroot in
src/chrome/installer/linux/debian_wheezy_arm-sysroot
and it has libc-2.13.so, libc.so.6 is symbolic link to libc-2.13.so in
the sysroot. However it appears minimum libc-2.17 is required (version
'GLIBC_2.17'). I replaced libc-2.13.so by abe-built
libc-2.20-2014.11-1-git.so, and symlinked libc.so.6 to
libc-2.20-2014.11-1-git.so and that worked (for non LTO build).
Curiously I didn't require to do this for building chromium with
linaro prebuilt toolchain.
* Found a way to disable LTO for building lib/libblink_web.so by manually
removing -flto from web_blink.ninja and Webkit/source/core/*.ninja,
which worked.
* Chromium non LTO build issues on ARM:
a) Fails with gcc-5 due to error in chromium:
https://code.google.com/p/chromium/issues/detail?id=340312
To compile chromium, I applied a patch to cp/typeck2.c to shut
narrowing conversion errors (ideally the fix should be to chromium).
b) ld.bfd (linaro branch) fails with undefined references to many functions
in libattr1: http://pastebin.com/ju4SCDSE
Not sure if this is ld.bfd bug, or me building it wrongly.
Haven't tested yet with trunk ld.bfd.
Works fine with gold.
* Target independent Chromium LTO issues with trunk
a) Top-level asm and LTO (PR57703) - This appears to be not supported.
* Chromium LTO issues on ARM with trunk:
a) ICE in lib/libblink_web.so (PR65576).
b) Target specific builtin not available: http://pastebin.com/2ANsEyMn
Seems related to:
https://code.google.com/p/chromium/issues/detail?id=408997
c) ICE during LINK chrome: http://pastebin.com/DpjJ5M7g
d) GNU ld appears to segfault compiling in LTO mode.
* Chromium LTO issues with linaro-4.9 branch:
a) ICE elf section out of range (PR57208) - fixed in trunk
b) gold - Ran out of file descriptors: fixed in trunk.
Seems the following patch which is in trunk but not in linaro branch fixes it:
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blobdiff;f=gold/…
I tried to backport it but got errors, possibly depends on other commits.
* v8 ARM LTO issues:
- Assembly error - offset out of range (PR65778). Possibly invalid bug.
== Next Week ==
- Create reduced test case for PR65576
- Figure out how to disable LTO for building lib/libblink_web.so in .gyp files
- PR49551
- Exams on 20th and 24th April.
# Progress #
* arm gdb, [6/10] many fails are fixed in the last two weeks.
1034->153 FAILs of -marm, 1008->143 FAILs of -mthumb, and 627->71
FAILs of -mfloat-abi=soft/-marm/-march=armv4t. There are 367 FAILs
in total, and 205 FAILs are about reverse debugging, which has been
broken for many years.
** TCWG-769, patch is committed upstream.
** TCWG-567, two patches are committed, and another two patches are in
progress. Existing HW watchpoint resource counting in GDB doesn't
work well on arm boards which doesn't have HW watchpoint support.
** TCWG-509, many arm gdb test fails are fixed. In progress.
* FSF GDB patch review. [3/10]
Test Pedro's "all-stop on top of non-stop" patch series V3 on both arm
and aarch64. Results are much better.
* Misc, meeting. [1/10]
# Plan #
* Fix test fails for arm and aarch64 gdb.
* Upstream patches review.
--
Yao
Hi,
I (and several other people) am (are) having trouble to build busybox with the latest aarch64-linux-gnu 2014.11 binaries we got from linaro.org.
It seems none of the built-in library search paths (gcc -print-search-dirs) allow to find crt[1i].o. They seem to be expected in a multiarch location but aren't (libc/usr/lib64). We're working around this with a symlink. Is this a bug? Have you seen similar issues?
Here's a failing command-line and the associated error message:
/path/to/gcc-linaro-4.9-2014.11-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu-gcc -Wall -Wshadow -Wwrite-strings -Wundef -Wstrict-prototypes -Wunused -Wunused-parameter -Wunused-function -Wunused-value -Wmissing-prototypes -Wmissing-declarations -Wno-format-security -Wdeclaration-after-statement -Wold-style-definition -fno-builtin-strlen -finline-limit=0 -fomit-frame-pointer -ffunction-sections -fdata-sections -fno-guess-branch-probability -funsigned-char -static-libgcc -falign-functions=1 -falign-jumps=1 -falign-labels=1 -falign-loops=1 -fno-unwind-tables -fno-asynchronous-unwind-tables -Os -static -o busybox_unstripped -Wl,--start-group applets/built-in.o archival/lib.a archival/libarchive/lib.a console-tools/lib.a coreutils/lib.a coreutils/libcoreutils/lib.a debianutils/lib.a e2fsprogs/lib.a editors/lib.a findutils/lib.a init/lib.a libbb/lib.a libpwdgrp/lib.a loginutils/lib.a mailutils/lib.a miscutils/lib.a modutils/lib.a networking/lib.a networking/libiproute/lib.a networking/udhcp/lib.a printutils/lib.a procps/lib.a runit/lib.a selinux/lib.a shell/lib.a sysklogd/lib.a util-linux/lib.a util-linux/volume_id/lib.a archival/built-in.o archival/libarchive/built-in.o console-tools/built-in.o coreutils/built-in.o coreutils/libcoreutils/built-in.o debianutils/built-in.o e2fsprogs/built-in.o editors/built-in.o findutils/built-in.o init/built-in.o libbb/built-in.o libpwdgrp/built-in.o loginutils/built-in.o mailutils/built-in.o miscutils/built-in.o modutils/built-in.o networking/built-in.o networking/libiproute/built-in.o networking/udhcp/built-in.o printutils/built-in.o procps/built-in.o runit/built-in.o selinux/built-in.o shell/built-in.o sysklogd/built-in.o util-linux/built-in.o util-linux/volume_id/built-in.o -Wl,--end-group -Wl,--start-group -lm -Wl,--end-group
==========
/work/integration/envs/latest/tools/gcc/gcc-linaro-4.9-2014.11-x86_64_aarch64-linux-gnu/bin/../lib/gcc/aarch64-linux-gnu/4.9.3/../../../../aarch64-linux-gnu/bin/ld: cannot find crt1.o: No such file or directory
/work/integration/envs/latest/tools/gcc/gcc-linaro-4.9-2014.11-x86_64_aarch64-linux-gnu/bin/../lib/gcc/aarch64-linux-gnu/4.9.3/../../../../aarch64-linux-gnu/bin/ld: cannot find crti.o: No such file or directory
collect2: error: ld returned 1 exit status
make: *** [busybox_unstripped] Error 1
Thank you!
Regards,
Kévin
-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782
== Progress ==
Bank Holiday [2/10]
Backports [2/10]
. started and abandoned backport of 217440 due to unbackported dependent patch
. FSF 4.9 branch is missing from our git mirror - this is still
wasting time after 7 months
Vectorization (TCWG-735) [3/10]
Benchmarking [1/10]
. started 2015.03 benchmarking
Misc [2/10]
raspberry pi config
calls/mailing lists
== Progress ==
LLDB development
-- Patch update, test and re-submission native Linux register context
for Arm. [1/10] [TCWG-650]
-- Patch update, test and re-submission POSIX register context for
Arm. [1/10] [TCWG-755]
-- Tested lldb armhf native build on ubuntu utopic, build fine but
lacks of VFP support is a blocker. [1/10] [TCWG-647]
-- Initial investigation on hardware watchpoint support for lldb arm
linux. [2/10] [TCWG-770]
-- Initial investigation on hardware watchpoint support for lldb
aarch64 linux. [2/10] [TCWG-771]
-- Fix lldb build and test environment for arm and aarch64. [2/10] [TCWG-651]
Miscellaneous [1/10]
-- Meetings, emails, discussions etc.
== Plan ==
LLDB development
-- Progress towards hardware watchpoint support for lldb arm linux.
-- Progress towards hardware watchpoint support for lldb aarch64 linux.
-- Bug fixing, patch reviews etc
== Issue ==
* none
== Progress ==
* [TCWG-762] - GCC Maintenance (9/10)
- PR65648 (ARMv6 IRA clobbering issue): Worked on a testcase that exhibit
the issue and don't conflict with various multilib configs.
Generic part of the
patch accepted, ARM related part needs to be reviewed by a ARM maintainer.
- PR65710 (LRA ICE in Thumb1): Proposed a quick workaround for this bug,
Proper fix was committed by Vlad.
- PR65729 (LRA ICE on arm-linux-gnueabhif): Proposed a fix, which is a stage1
material. Issue workarounded on trunk to avoid extensive
validation for the RC.
* [TCWG-702] Merge FSF 4.9 branch
- Merged up to revision 221939
- Will do another one to include needed LRA fixes.
* Misc (1/10)
- Various meetings
== Plan ==
- FSF branch merge #2
- Back on a Thumb2 insn fix
catomics - TCWG-436 [4/10]
* Fiddled with SPEC runs with unstripped binaries on tiny Juno discs
* Got a run for the interesting subset of SPEC, non-atomic catomics
still show no effect
* Tried a few catomics variations with the glibc malloc
microbenchmark, here non-atomic catomics show a significant effect
* Tried firing a perf shotgun at the malloc microbenchmark to see if
it suggests anything - results pending
Benchmark automation - TCWG-360 [3/10]
* Fixed Jira benchmarking
* Flushed some of the backlog out of my 'small fixups' branch
Misc [1/10]
Holiday [2/10]
catomics - TCWG-436 [4/10]
* Fiddled catomics to not use atomics at all, set off a new SPEC run
* Not using atomics seems wrong in general, but OK for malloc/free
Benchmark automation - TCWG-360 [1/10]
* Quick look at Tyler's LAVA console streamer
* Ported benchmark scripts to work on Debian
** Turns out there are two versions of netcat and Debian and Ubuntu
default to different ones
* Checked lab transition plan for benchmark-affecting points
Misc [1/10]
Holiday [4/10]
== Progress ==
* Public holiday (2/10)
* Sick (2/10)
* TCWG-620 (4/10)
- regression tested a version of patch
- few regressions lead to reworked it
- have a version that passes regression
* TCWG-753 and Bug 1373 (1/10)
- Al the Back-ports committed
- closing the card
* Misc (1/10)
- gcc-patchs and gcc-bugs list
== Plan ==
* Start with the RA issue during vectorization
* TCWG-521
== This Week ==
* TCWG-619
* V8
- aarch64 v8 LTO build with different options
- found workaround for v8 LTO build on ARM
* Chromium
- statically linking libstdc++ works for building chromium with
linaro-4.9-branch
- patched cp/typeck2.c to shut up on narrowing conversion errors to build
chromium with master branch.
- weird issue, chromium build hangs consistently at:
AR obj/components/libomnibox.a
due to patch to WebGLRenderingContextBase.idl, reverting that worked fine.
* PR49551
- git bisect shows ICE cannot be reproduced after r221297.
* Misc
- Preparatory Leave from college, semester ended.
== Issues ==
- ABE bugs: 1362, 1439, 665
- Can't access BlueJeans from Firefox on pc, gets stuck on
"Initialization" window.
== Next Week ==
- Complete LTO build v8 with different options on ARM, AArch64 and x86.
- Chromium LTO build on x86 with different LTO options.
- Chromium LTO and non LTO build on ARM.
- PR 49551.
UK Holiday on 06 April [2/10].
# Progress #
* arm gdb test fail fixing. [4/10]
** TCWG-767, patch is committed.
** TCWG-769, patch is posted upstream for review.
** TCWG-765, triaged this issue. It is a test case or test harness
bug, rather GDB's. Need more time to investigate how to run "echo"
command on remote target through dejagnu.
** Fix a bug in my ARM displaced stepping code written in 2011.
** TCWG-509, patch is approved upstream, but will be combined into
other's patches.
** TCWG-567, Skip incorrect tests in gdb.base/watchpoint-reuse-slot.exp
for arm. Patch is committed.
* FSF GDB patch review. [3/10]
Test Pedro's "all-stop on top of non-stop" patch series on both arm
and aarch64. Some regressions are found and exchange thoughts on
them.
* meeting, [1/10]
# Plan #
* Test fails fixing for arm and aarch64 gdb.
* Upstream patches review.
--
Yao
== Progress ==
* Public holiday (2/10)
* zero/sign extension - TCWG-521 (2/10)
- Looked at profile results
- Starting aarch64 benchmarking
* TCWG-620 (2/10)
- Ran into missing pattern issue
- Discussed it with Maxim and Jim
* TCWG-753 (2/10)
- orted few issues with my backporting set-up after talking to Yvan
- Started all the backports
- Backport testing in progress
* Bug 1373 (1/10)
- Backport testing in progress
* Misc (1/10)
- gcc-patchs and gcc-bugs list
== Plan ==
* TCWG-620 and TCWG-521
Holiday: 03/04 [2/10]
# Progress #
* aarch64 gdb, 8 FAILs are fixed but 6 FAILs are introduced by the new
test case. [2/10]
** KFAIL two tests in gdb.threads/no-unwaited-for-left.exp for remote
target. Done.
* TCWG-509, arm gdb, 1034 FAILs of -marm, 1008 FAILs of -mthumb, and
627 FAILs of -mfloat-abi=soft/-marm/-march=armv4t. [4/10]
** Look at fails in gdb.threads/non-stop-fair-events.exp. Root cause is
almost identified, and patches are being tested.
* TCWG-757, FSF GDB, [1/10]
** Review two committed patches causing some problems for arm. Will
raise questions on them later. Looks I need to allocate more time on
upstream reviewing to prevent these arm-unfriendly patches go in.
* meeting, [1/10]
# Plan #
* Take more care on arm gdb.
* Upstream patches review, especially on all-stop-on-top-of-non-stop
patch set.
* Fix the rest of 10+ fails in aarch64 gdb.
--
Yao
== Issue ==
* none
== Progress ==
* [TCWG-762] - GCC Maintenance (9/10)
- Linaro bugzilla 1399 identified as an upstream bug (PR65647)
Now fixed on trunk and backported in FSF 4.9, will be in our
branch in the coming branch merge.
* [TCWG-699] Backports
- Committed them into our SVN FSF repo.
* Misc (1/10)
- Various meetings
== Plan ==
- FSF branch merge
- Back on a Thumb2 insn fix
== Progress ==
LLDB development
-- Completed implementation and submited native Linux register context
for Arm upstream [3/10] [TCWG-650]
-- Completed implementation and submitted POSIX register context for
Arm upstream [3/10] [TCWG-755]
-- Fixing LLDB build and dev environment issues [1/10]
Miscellaneous [3/10]
-- 3rd April Swap day for 23rd March Public Holiday
-- Meetings, emails, discussions etc.
== Plan ==
LLDB development
-- Bug Fixing and Test result improvement.
-- Patch reviews and upstream commits.
Miscellaneous
-- Try LLDB armhf builds and figure out a way to do gcc 4.8 softfloat build.
4 day work week (03-Apr good Friday) (2/10)
* ASAN 32bit allocator failures on amd-01 (4/10)
Completed analyzing failures. Sent a patch to Address sanitizes
community for review. Applied patch to latest LLVM trunk and ran
tests. found one failure. But it was due to the test case assuming
that return value from "getpwnam_r" all is always zero. Fixed the
test case by removing the assert and all LLVM tests passes.
[ Renato tested the patch on APM (39 bit VA) ].
* Again there is some discussion in GCC bugzilla on deciding which
allocators to use for Aarch64 42 bit VA*.
I have a patches for both allocators and posted it to ASAN group
64 bit allocators wont work on juno. So for ASAN there is a need to
have some kind of dynamic address space detection mechanism. Set the
allocators type and required mappings at runtime for Aarch64.
But that needs to be decided by ASAN group whether to do that or use
my 32 bit allocator patch . I am planning to stop it here and wait as
suggested by renato.
* Get TSAN building for Aarch64 on 42-bit VMA systems. (2/10) (-pie mode only)
Applied patch that I had on GCC tree on LLVM trunk. Build failed need
to set kVdsoBeg and kMadviseRangeBeg. I set some default value to
allow TSAN build to complete. right now clang does not recognize
aarch64 target for aarch64 although I enabled it under TSAN. looking
at the issue.
* Emails, meetings. (2/10)
* Linaro 1-1 with christophe, Ryan, status meet
* AMD meetings/event, 1-1 with AMD manager, status meeting.
* GCC mailing list.
== Plan ==
* Get TSAN building for Aarch64 on 42-bit VMA systems. (-pie mode only)
* Document TSAN/ASAN work and patch details in wiki.
== Issues ==
* ASAN patch cannot be up streamed unless we decide on allocator to use.