Hello linaro experts!
I'm using the stable version(gcc-linaro-4.9-2014.11) recommended on
https://wiki.linaro.org/WorkingGroups/ToolChain. I downloaded the
binary fromhttps://releases.linaro.org/14.11/components/toolchain/binaries/arm-lin….
But I found there is no libstdc++.so.6. Is that library missing in
that version?
What I need is just a tested stable version for an industry iot
project and the stability is the most important thing. And due to app
back-compatibility, I can not use hardware-float feature. So any
recommendation for a tested stable version of
_gcc-linaro-xxx-arm-linux-gnueabi_ toolchain?
Thanks!
dlw
o One day off (2/10)
== Progress ==
o Upstream GCC (3/10)
- AArch64 and ARM backend cleanup w/r to reload remaining hooks
rebasing and validation on-going
- Investigate guality test failures
o Misc (5/10)
* Various meetings and discussions.
* Catch up with mail/irc/upstream dev after holidays
== Plan ==
o Continue on-going tasks
== This Week ==
* LTO (5/10)
a) TCWG-666 (4/10)
- RFC Patch submitted upstream
- Committed r239212 to make extend_mask, extend bits based on sign.
- Addressed patch reviews
b) TCWG-548 (1/10)
- Resolved issue with chromebook
- Benchmarking with SPEC2k doesn't show much perf improvement.
* Bugs (3/10)
- Fixed regressions caused by my commits for PR70920 and PR71078
- PR57371: Submitted patch upstream
* Misc (2/10)
- UK visa application and appointment
== Next Week ==
- Continue with TCWG-666, TCWG-72, TCWG-548
# Progress #
* TCWG-685, GDB 7.12 release. [5/10]
Release branch is created. Finished the test and triage for aarch64
native.
Tests are good. Two patches are committed. Running regression tests
for cross for arm and aarch64.
Upgrade the native compiler to gcc mainline, and run aarch64 tests
with the new compiler.
* OpenOCD for aarch64. [3/10]
Investigate OpenOCD support for aarch64. There was an openocd patch
for aarch64 posted in Feb 2015, but never merged.
* Misc, [2/10]
# Plan #
* TCWG-685.
* Finish OpenOCD investigation.
* US visa interview on Wed.
--
Yao
== Progress ==
* LLVM 3.9.0 Release for AArch64 [TCWG-696] [3/10]
- Ran the tests on one of our APM boards
- Fixed an issue with some tests that are only supposed to be run
for the x86 target but were accidentally running for other targets too
- Wrote up some release notes for AArch64
* Enable MLx Expansion pass for non-Cortex-A9 targets [TCWG-674] [3/10]
- Did a few runs of the test-suite on one of our chromebooks (Cortex-A15)
- The pass is expanding > 2000 MLx instructions in the test-suite, so it
looks like we can use it for evaluation
* [AArch64] Keep merging consecutive stores in store sequences [TCWG-704] [2/10]
- When merging stores, we always start looking from the end of the store
sequence, and if the last store cannot be merged we stop; we should instead
keep looking through the rest of the sequence to see if we can merge any of
the previous stores
- Working on a fix
* Refactor SelectionDAGBuilder::visitInlineAsm [TCWG-643] [2/10]
- Made it shorter by about 100 LOC; it could still use some cleanup, but I've
sent the patch upstream to get an initial round of feedback
== Plan ==
* LLVM 3.9.0 Release for AArch64 [TCWG-696]
- Wait for the next release candidate
* [AArch64] Keep merging consecutive stores in store sequences [TCWG-704]
== Progress ==
* Validation
- reviews in Jenkins jobs/ABE
- checked that the new xenial builder works as expected
* GCC
- PR 67591 (ARM v8 Thumb IT blocks deprecated)
* misc (conf-calls, meetings, emails, ....)
- catching up after holidays
- Cauldron and Connect: booked flights and hotels
== Next ==
On holidays until Aug 22nd
== This Week ==
* LTO (4/10)
a) TCWG-666 (3/10)
- No idea where data corruption happens in ltrans with my patch,
tree value in ipa_bits gets corrupted for some reason.
- Started over with widest_int representing value and mask
- WIP new prototype patch:
http://people.linaro.org/~prathamesh.kulkarni/ipa-bits-0_1.diff
b) TCWG-548 (1/10)
- Benchmarking fails on my chromebook, input/output error,
no idea why.
* TCWG-72 (2/10)
- Rebased patch on trunk, bootstrapped on x86_64, cross tested on arm*-*-*
- Addressed comments from Ramana
- Strange issue with armv8l-unknown-linux-gnu which has hardware div
but produced call to __aeabi_idiv, maybe I screwed sth during the build.
Building from scratch doesn't reproduce the issue and patch does not
regress armv8l-unknown-linux-gnueabihf.
* Misc (4/10)
- PR70920: Fix committed upstream.
- PR71078: Fix committed upstream.
- Committed r238874 to restrict pr70929-4.c for lp64 targets to avoid
fallout caused by the test-case on ilp32 targets.
- Submitted RFC patch to warn for dead calls, rejected due
to potentially false positives.
- WIP patch to fold strlen (s) eq/ne 0 to *s eq/ne 0
== Next Week ==
- Continue with TCWG-72, TCWG-548 and TCWG-666
Hi Everyone,
I'm having trouble finding vreinterpretq_u64_p128 (and friends) to
help convert a polynomial. I can't find it in arm_neon.h or
arm_acle.h:
$ grep p128 /usr/lib/gcc/aarch64-linux-gnu/4.9/include/arm_acle.h
$ grep p128 /usr/lib/gcc/aarch64-linux-gnu/4.9/include/arm_neon.h
$ grep p64 /usr/lib/gcc/aarch64-linux-gnu/4.9/include/arm_acle.h
$ grep p64 /usr/lib/gcc/aarch64-linux-gnu/4.9/include/arm_neon.h
vmull_p64 (poly64_t a, poly64_t b)
vmull_high_p64 (poly64x2_t a, poly64x2_t b)
$
An RPI-3 with ARMv8/Aarch32 and GCC 4.9.2 has it in arm_neon.h:
$ cat /usr/lib/gcc/arm-linux-gnueabihf/4.9.2/include/arm_neon.h | grep
-A 4 vreinterpretq_u64_p128
vreinterpretq_u64_p128 (poly128_t __a)
{
return (uint64x2_t)__builtin_neon_vreinterpretv2diti
((__builtin_neon_ti) __a);
}
Is there another file that should be included for it? Or is there
something else I should be doing when I want to convert from a
polynomial to a type like uint64x2_t?
Thanks in advance.
Jeff
Hi Everyone,
I have a HiKey running Linaro. I'm trying to build out a test case
which tests Aarch32 on Aarch64.
When I attempt to build an Aarch32 binary I experience the compile
error below. The GCC folks helped me with the Aarch32 CFLAGS, so I
believe they are correct.
$ gcc -march=armv8-a+crc -mtune=cortex-a53
-mfpu=crypto-neon-fp-armv8 -mfloat-abi=hard test.cc -o test.exe
gcc: error: unrecognized command line option ‘-mfpu=crypto-neon-fp-armv8’
gcc: error: unrecognized command line option ‘-mfloat-abi=hard’
Trying an -m32:
$ gcc -march=armv8-a+crc -mtune=cortex-a53
-mfpu=crypto-neon-fp-armv8 -mfloat-abi=hard -m32 test.cc -o test.exe
gcc: error: unrecognized command line option ‘-mfpu=crypto-neon-fp-armv8’
gcc: error: unrecognized command line option ‘-mfloat-abi=hard’
gcc: error: unrecognized command line option ‘-m32’
And without the -mtune:
$ gcc -march=armv8-a+crc -mfpu=crypto-neon-fp-armv8
-mfloat-abi=hard test.cc -o test.exe
gcc: error: unrecognized command line option ‘-mfpu=crypto-neon-fp-armv8’
gcc: error: unrecognized command line option ‘-mfloat-abi=hard’
I'm obviously suffering a disconnect. I may have more problems after
the build when attempting to run the program, but I'll cross that
bridge when I encounter it.
How does one build an Aarch32 program on Aarch64?
Thanks in advance.
== Progress ==
* PR24234 - [AArch64] error in backend: fixup value out of range
[TCWG-681] [5/10]
- Wrong instruction size computed for TLS accesses
- Accepted upstream, will commit first thing next week
* [AArch64] Register all AArch64 passes [TCWG-687] [3/10]
- Cleanup that should enable us to run AArch64 passes in llc (incidentally,
this was useful for testing TCWG-681)
- Accepted upstream, will commit first thing next week
* Enable MLx Expansion pass for non-Cortex-A9 targets [TCWG-674] [2/10]
- Started playing with a code snippet so I can understand the pass better
== Plan ==
* Enable MLx Expansion pass for non-Cortex-A9 targets [TCWG-674]
- Brush up the code snippet and do some runs on a Cortex-A15 to see how it
behaves there
* Pick up another AArch64 bug from TCWG-678
