- 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
== Progress ==
* Pointer mangling Aarch64 glibc.
Worked on review comments from Maintainer. Rebased and posted the patch.
Upstream completed and closed the card.
https://cards.linaro.org/browse/TCWG-373
* Experimented with Cbuildv2 native building.
== Plan ==
- Continue Cbuildv2.
- Investigate PGO for Aarch64.
== Issues ==
Waiting for feedback on libssp machine descriptions changes.
== Issues ==
* None
== Progress ==
* One day off (Jan. 1)
* Do some basic validations for 2013.12 toolchain binaries release.
* R/M Mac toolchain validation
* Branch-cost related tuning for Cortex-M.
== Plans ==
* Continue on branch-cost related tuning.
== Progress ==
- Short week (4 Days)
- TCWG-291 zero/sign extension elimination 4/10
- made re-factoring and ran the regression
- benchmarking in progress
- TCWG-134 divmod 4/10
- converted into latest pass structure and re-based the patch
- found some regression failures and fixed them
- regression testing ongoing
== Plan ==
- post divmod and vrp patches
