* 4 days week (still some times spent at university).
== Issues ==
* none
== Progress ==
* LRA on AArch32:
o TCWG-343 : Make LRA the default for the ARM backend (3/10)
- Most of the issues fixed or about to be fixed by Vladimir :
* iWMMXT issue and Thumb1 udivmoddi4 : fixed.
* Thumb1 code size issue : partial patch proposed.
- Looking backend places (ARM and AArch64) where reload_in_progress
is used to verify if lra_in_progress is needed as well.
Validation ongoing.
o TCWG-345 : Analyse performance of LRA for ARM. (0/10)
- No progress this week.
* Loop specialisation patch review: (1/10)
o Sent feedback to Samsung.
* 2014.01 release: (1/10)
o Branch merge review
* [Bug 1258013] Re: Cannot build arm64 kernel with CONFIG_DEBUG_INFO=y (1/10)
o Issue due to a wrong .align directive in an assembly source file which is
already fixed upstream.
* GMP library sAArch64 port review: (1/10)
o Started to review Anil work.
* Misc. (1/10)
o Various meetings.
== Next ==
* Still some time spend at university
* Continue on LRA and lib GMP.
- 2014.01 releases: (2/10)
* 4.7 ready, 4.8 needed a short daily to include our multilib patch
to support our binary releases.
* retried cbuildv2 and sent feedback. Should be mostly OK by now.
- cross-validations: (2/10)
* followup-up, bugzilla
* thinking about short term Neon intrinsics testsuite use without dejagnu
- libsanitizer (2/10)
* resumed work for aarch64
- misc (2/10): conf-call and meetings
- internal support (2/10)
* issue:
boards used for benchmarking have been off for several weeks. Pending
jobs disappeared from the list, but I got no log.
== Progress ==
* Implement fork over HW breaks support for arm native targets.
[TCWG-177] [6/10]
* ARM Process Record:
- All patches accepted and upstream.
- Spent time making changes to VFP, SIMD etc patch. [2/10]
- Configuration and Git ssh setup for gdb commit rights . [1/10]
* Submitted a new fix and worked with community for the fix. [1/10]
== Plan ==
* Continue to work on fork over HW breaks support for arm native
targets. [TCWG-177]
* Patch updates and submission to all in progress upstream submissions.
* Travel to Islamabad for Macau visa application.
== Progress ==
* Libc probes support for Aarch64.
Testing the patch for "libc" probes support to "__longjump".
Native compiling in openemebedded.
Obtained a Linaro open embedded image with system tap enabled.
Getting Assembler Error during "malloc" module linking in "glibc"
configured with --enable-systemtap.
In libc_mallopt invalid "asm", invalid expression as operand for
LIBC_PROBE call.
Cross compiling.
Tried copying header files from system tap source to SYSROOT for cross
compiling glibc. The cross compiled GCC does not recognize the header
files.
* Investigate "PGO" for Aarch64.
Started bootstap testing GCC with PGO for GCC.
Stage 1 completed. stage profile in progress.
== Plan ==
- Run EMBCC benchmark with -PGO enabled.
- Work on "glibc" probe.
== Issues ==
Waiting for feedback on "libssp" machine descriptions changes.
Misc
------
14-Jan-2014 Local holiday.
== Issues ==
* None.
== Progress ==
* Test Linaro cbuildv2.
- Write a reference script to support windows installer in cbuildv2.
- Do some basic validation work against the binaries built from cbuildv2.
* Reproduce and work out a patch for "ICE when building
linux-linaro-tracking" (lp:1268893, PR59837) .
* Test to merge Linaro local armv4t multilib patch to Linaro 4.8.
* Investigate CCMP chance by taking a Bool_ var as var != 0.
== Plans ==
* cbuildv2 validation
* Tuning ccmp performance
== Planed leaves ==
* Jan. 31 - Feb. 9.
== This week ==
- Completed merge of crypto backports 206128, 206130, 206131, 206132 and
206149 from trunk to Linaro 4.8 branch
- Out sick Friday
== Next week ==
- Build and test crypto backports
- Begin merging aarch64 crypto backport to Linaro 4.8 branch
== Future ==
== Progress ==
* Cbuildv2 fix for *_release() functions which were changing out of
the build directory but then not changing back to the builddir, which
caused problems with paths relative to the builddir. (1/10)
* TCWG-340 Enable Glibc remote testsuite integration - (7/10)
- Working with upstream community on scoping and designing remote
testsuite integration.
- Setting up arm chroot environment on chromebook with documentation
on how to make this reproduceable.
* TCWG-352 AArch64 clone is missing some CFI markup - (2/10)
- Setup aarch64 environment for testing and built static clone tests
to test the patch.
== Plan ==
* Start implementing (code) for glibc remote testsuite integration.
== Issues ==
None
== Progress ==
* Buildbots
- Odroid U2 died after a few days on USB stick, too. (I guess we're stuck
with Chromebooks)
- Upgrading chromebooks (to Saucy) due to a new GCC/libstdc++ 4.7+
restriction
- Shuffling chromebooks, we now have three buildbots:
- llvm-chrome-01: quick-build+check
- llvm-chrome-02: self-host+check
- llvm-chrome-03: test-suite
* MCJIT Remote
- Re-factored the communication protocol of MCJIT for remote processes
- Still seeing one random failure on ARM, investigating
* Compiler-rt
- Investigating how to get it compiling all libraries and sanitizers on ARM
* Background
- Patch reviews, especially IAS and EH
* Time
- CARD-862 8/10
- Others 2/10
== Plan ==
* Continue MCJIT and Compiler-RT investigations
* Continue reviewing IAS and EH patches
* Try to run the EH tests on the test-suite with the current changes
== Progress ==
* Add support for AArch32 ARMv8 VRINT to QEMU (4/10, TCWG-50)
* Add support for AArch32 ARMv8 VCVT to QEMU (4/10, TCWG-49)
* Add support for AArch32 ARMv8 16<->64bit VCVT to QEMU (1/10, TCWG-51)
* Fixed gas ARM VCVT encoding bug (1/10)
== Issues ==
* None
== Plan ==
* Complete outstanding QEMU work
* ARM setjmp/longjmp SystemTap probes
* malloc
--
Will Newton
Toolchain Working Group, Linaro
Hi,
I've been playing with linux-linaro-tracking and the 2013.12 (and
2013.10, 2013.11) toolchain release and when turning on the NEON in
kernel option I get:
CC lib/raid6/neon4.o
lib/raid6/neon4.c: In function 'raid6_neon4_gen_syndrome_real':
lib/raid6/neon4.c:113:1: internal compiler error: in
dwarf2out_frame_debug_adjust_cfa, at dwarf2cfi.c:1078
}
^
Use the attached .txt as .config and do 'make zImage' to replicate the
problem. You will probably need to attached patch as well since some of
the linaro patches break namespace support :(
regards,
--
Koen Kooi
Builds and Baselines | Release Manager
Linaro.org | Open source software for ARM SoCs
* Two days week (due to compilation courses given at university).
== Issues ==
* none
== Progress ==
* LRA on AArch32:
o TCWG-343 : Make LRA the default for the ARM backend (1/10)
- iWMMXT issue : back on the issue.
- Thumb1 issues : looked at bugzilla's reports.
o TCWG-345 : Analyse performance of LRA for ARM. (0/10)
- No progress this week.
* Loop specialization patch review: (1/10)
o Back on the task.
* [Bug 1258013] Re: Cannot build arm64 kernel with CONFIG_DEBUG_INFO=y (1/10)
o Tried to reproduce the issue.
* Misc. (1/10)
o Catching up with email, etc
o Meeting
== Next ==
* Still some time spend at university
* Continue the ongoing tasks.
* Branch merge reviews.
== Progress ==
* ARM Process Record:
- Follow up on patches, almost all patches accepted. [0.5/10]
- Got GDB committ rights and set up git for pushing patches. [0.5/10]
* Spent time to read through fortran functions prologue to find a new fix
for TCWG-267. [1/10]
* Initial investigation of handling breakpoint over fork [TCWG-177] [1/10]
* Getting documentation ready for Macau visa application [2/10]
== Plan ==
* Update and send patches where required and committ all approved patches.
* Work on breakpoints issues [TCWG-177] and reverse stepping through solib
issue [TCWG-315]
* Apply for Macau visa, given all documents get ready.
== Progress ==
* Libc probes support for Aarch64.
Posted patch for "libc" probes support to "__longjump". Worked on
review comments from Maintainers. Upstream discussions in progress.
Working on testing "glibc" by using --enable-systemtap.
* Experimented with "Cbuildv2" native building.
== Plan ==
- Continue Cbuildv2.
- Investigate "PGO" for Aarch64.
- Work on "glibc" probe.
== Issues ==
Waiting for feedback on "libssp" machine descriptions changes.
misc
===
14-Jan-2014 leave.
== Progress ==
* Draft wiki page (under ACL--let me know if you want to see) for
instructions for setting up chroots on chromebooks for glibc testing:
https://collaborate.linaro.org/display/~ryan.arnold@linaro.org/Configuring+…
* Investigated expanding remote testing possibilities in glibc.
* RFC email to libc-alpha discussing proposal for glibc host testsuite
in chroots:
https://sourceware.org/ml/libc-alpha/2014-01/msg00222.html
== Issues ==
* Shortened week (3-days) because of unplanned school closures on
Monday and Tuesday due to freezing temperatures, during which I had to
watch my kids.
== Plan ==
* Start code scaffolding for glibc host testsuite in chroot.
* Start cbuild2 scaffolding for building remote chroots for glibc testing.
* Add glibc multi-lib builds and IFUNC system libraries.
* Work on cbuild2 support for local tar files.
== Progress ==
* Two day week
* Catching up on email etc. after break (0.5/10)
* Investigate setjmp/longjmp SystemTap probe support in ARM glibc
(1/10, TCWG-378)
* Investigate toolchain bug reports for ARM and AArch64 (0.5/10)
== Issues ==
* None
== Plan ==
* Resume QEMU ARMv8 AArch32 work
* Hopefully push glibc ARM pointer encryption fix for 2.19
--
Will Newton
Toolchain Working Group, Linaro
- 2013.12 releases (1/10)
* Sent announcements for 4.7 and 4.8 releases.
- 2014.01 releases (2/10)
* Created 4.7 and 4.8 branch merge requests (had handle some conflicts in 4.8)
* Looked at backporting the crypto intrinsics support into 4.8, but
there are dependencies with several other patches we haven't
backported yet.
- cross validation (4/10)
* Restarted them since I had to stop them during the holidays. Still
catching up with the backlog, should be OK during the week-end.
* Analyzed and reported several regressions or new tests failing in
some configurations.
- Neon intrinsics tests (1/10)
* Looked at Rob's neon-intrinsics branch and sent him some feedback.
- misc (2/10): conf-calls and meetings.
== Next ==
- 2014.01 releases
- cross-validation: look at results and report regressions if any
- resume libsanitizer work for AArch64
== Progress ==
* Release 3.4 went out
* Buildbots
- Using powered USB hub for the external harddrive, but all boards fail
one time or another...
- Maybe it's the hard-drive type (mobile, power-saving), reverting to USB
sticks for now
- Leaving an odroid U2 running on USB stick for a week, used to work...
- C++11 features will need GCC 4.7+, looking for an easy way to upgrade
the Chromebooks
* MCJIT
- Finished work on remote MCJIT to re-enable the failing tests
- http://llvm-reviews.chandlerc.com/D2527
* Pragma Vectorize
- New discussions hint that my parser patch is moot, for now
- Agreement is to use C++11 attributes for now, and add pragmas later
- I can't continue implementing them, though...
* Background
- Huge number of patch reviews during holidays & this week
- Good progress on new features for the IAS
- More progress on EHABI, including IAS support
* Time
- CARD-862 8/10
- Others 2/10
== Plan ==
* Continue reviewing IAS features, maybe implement some
* Work out how to create a libcxx bot
* re-introduce llvm-chrome-01 as second self-host
* Migrate all buildbots to GCC 4.7+
* Check out EHABI tests and assess progress
Hi,
I filed this on bugzilla:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59744 but I thought I'd
mention it here too.
This slightly strangely written program (it's distilled down from
frame_offset_overflow in the gcc source itself) should print "bigger" if
the first argument is bigger than 10 (or negative, but let's ignore that
please):
#include <stdlib.h>
#include <stdio.h>
int a[2] = { 10, 20 };
int
is_bigger (long offset, int index)
{
unsigned long size = -offset;
if (size > a[index])
{
printf("bigger\n");
return 1;
}
return 0;
}
int
main (int argc, char** argv)
{
long v;
v = atol(argv[1]);
is_bigger(-v, 0);
return 0;
}
When compiled at -O1 or above (and with inlining disabled at -O2 and
above), though, it bungles the 0 case:
(t-doko)mwhudson@arm64:~$ gcc-4.9 -O3 test.c -o test -fno-inline -Wall
(t-doko)mwhudson@arm64:~$ ./test 1
(t-doko)mwhudson@arm64:~$ ./test 11
bigger
(t-doko)mwhudson@arm64:~$ ./test 0
bigger
(t-doko)mwhudson@arm64:~$ gcc-4.9 -O0 test.c -o test -Wall
(t-doko)mwhudson@arm64:~$ ./test 1
(t-doko)mwhudson@arm64:~$ ./test 11
bigger
(t-doko)mwhudson@arm64:~$ ./test 0
(t-doko)mwhudson@arm64:~$
What's going on? Here's the disassembly of is_bigger (at O3):
0000000000400608 <is_bigger>:
400608: b0000082 adrp x2, 411000 <_GLOBAL_OFFSET_TABLE_+0x28>
40060c: 91010042 add x2, x2, #0x40
400610: a9bf7bfd stp x29, x30, [sp,#-16]!
400614: 52800003 mov w3, #0x0 // #0
400618: 910003fd mov x29, sp
40061c: b8a1d841 ldrsw x1, [x2,w1,sxtw #2]
400620: ab00003f cmn x1, x0
400624: 540000a2 b.cs 400638 <is_bigger+0x30>
400628: 90000000 adrp x0, 400000 <_init-0x3f8>
40062c: 911b6000 add x0, x0, #0x6d8
400630: 97ffff90 bl 400470 <puts@plt>
400634: 52800023 mov w3, #0x1 // #1
400638: 2a0303e0 mov w0, w3
40063c: a8c17bfd ldp x29, x30, [sp],#16
400640: d65f03c0 ret
Basically it seems that the condition "-offset > val" is being compiled
as "val + offset does not overflow", which is not valid for offset == 0.
This seems to me to be the underlying cause behind
https://bugs.launchpad.net/ubuntu/+source/gcc-4.8/+bug/1263806 ("gccgo
fails to compile tomb.go on arm64").
Cheers,
mwh
Hi,
We are trying to build android Kitkat (for our own platform) using
linaro android toolchain version
4.7.4 from 13.12 release. We are observing following while compiling
some shared libraries:
~arm-linux-androideabi-4.7/bin/../libexec/gcc/arm-linux-androideabi/4.7.4/real-ld:
warning: shared library text segment is not shareable
~arm-linux-androideabi-4.7/bin/../libexec/gcc/arm-linux-androideabi/4.7.4/real-ld:
error: treating warnings as errors
We tried to suppress thisn warning by setting LDFLAGS but the
tool-chain does not seem to identify this flag:
LOCAL_LDFLAGS := --no-warn-shared-textrel
We need some help to fix this, so posting on both android and
tool-chain mailing lists.
Thanks,
Sandeepa
Hi folks,
As most of you are on the GNU side of the fence, I believe this is the
right crowd to first ask this question, before attempting a wider audience.
For a while, Clang/LLVM wasn't in any position to add unheard-of features,
and most of what we needed would be covered by something GCC already did.
But in the last year or so, there were a number of "features" we'd like to
add that aren't present in GCC (like pragmas, attributes, asm directives)
which is neither part of the language specifications, nor something that
another standard (like OpenMP or ABIs) already support.
As a concrete example, we're trying to come up with some vectorisation
annotation and there is a heated discussion on whether it should be C++11
attributes, pragmas, or changing the __attribute__ semantics to allow it to
be used in lexical blocks, not just declarations. Any of that, but most
strikingly the latter, would add Clang-specific behaviour which GCC
probably won't implement, and we all know how that feels.
In this discussion, and others regarding ARM-specific behaviour (notably
about assembly directives), I have used the same argument twice already, so
it's time to ask the GCC crowd once and for all:
For non-standard, domain or platform specific changes, do we want to have a
joint task force, GCC+LLVM, to homogenize the efforts in extending the
languages we support in the same say, so that we can call it the "OSS
Compiler Extensions" (or whatever) instead of two separate GCC-extensions
and Clang-extensions?
Historically, GCC has *a lot* more extensions, so this new standard would
probably be 99% GCC, but the goals of such a task force for the future
would be to:
1. Make sure all OSS compilers implement the same extensions, when they so
chose. So, extensions to the language should go in a shared forum, and not
to Clang/GCC lists.
2. Document each extension and record all discussions (threads, bugs, etc),
so that new compilers can have an easier time implementing them.
3. Reason about the existing hazardous or redundant extensions, and mark
them for deprecation.
This is also pertinent to the Linux kernel, which is driving its own task
force to compiler the kernel with Clang, so that it can rid itself from
outdated GNU extensions that lingered for far too long in their code.
I appreciate the size of this proposal, the political issues and the
endless discussions, but this is the same on every standard committee, and
I'd rather have something than nothing at all.
Perhaps, as it happened before, some of these changes could be more easily
persuaded to move back to the language standards and platforms ABIs, than
if it's just implemented, undocumented, by one compiler.
So, ignoring just for a moment the political side of it, would that make
technical sense for the GCC community as well?
cheers,
--renato
Folks,
Since LLVM is moving on to C++11, I need to replace our buildbot GCCs with
4.7+ (the new minimum requirement), but I'd like to use whatever is the
most stable and modern GCC version for native compilation. I could get the
latest and greatest on our repository, but I know how compilers are
written, and pardon me if I don't trust new releases... ;)
Does any one have an opinion on which is the most stable, preferably 4.8,
release of native ARMv7 GCC binaries?
For some odd reason, we just release cross-compilers, so, in that case,
where would I look for a native GCC, other than in my Ubuntu/Arch
repositories? ARM? CodeSourcery?
I *really* don't want to compile it myself... My lack of available fast ARM
hardware is disturbing, and I don't want to spend a week cross-compiling
GCC.
cheers,
--renato
