== 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
