Hi
I have a question about the impact of a binutils bug to do with parsing the .align assembler directive, which may appear soon in a Linaro GCC release. The bug was first discovered by Jérôme Forissier when building ARM Trusted Firmware with a non-Linaro toolchain:
https://lists.linaro.org/pipermail/linaro-toolchain/2016-June/005768.html
As Jim Wilson helpfully noted later in that thread:
> This patch isn't present in the binutils-2.25 that tcwg is using. The patch is present in binutils-2.26.
The bug is now fixed in binutils mainline:
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=7ea12e5…
But this was too late to be in the binutils-2_27 tag (3rd August)
I'm concerned that this bug may appear in the upcoming Linaro GCC 6 stable release, which may have a significant lifetime. Can anyone comment on the binutils version to be used in the Linaro GCC 6 release? If a binutils version containing the bug is used, is it possible for this to be patched with the fix? I need to know whether we need to provide an interim solution in ARM Trusted Firmware.
Regards
Dan.
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.
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.
